Tiers de confiance et signature
Yves Lambert
Pour s�curiser une transaction endre deux agents (humains,
logiciels ou physiques) � travers un r�seau on fait appel
� la signature. Probl�me : la cl� priv�e peut etre perdue
(changement de serveur, ou de d�tenteur...) ou vol�e. De
plus, on fait appel � un tiers de confiance pour la
publication de la clef publique. Le tiers n'est pas mis
au courant de la transaction.
Je regarde comment �a se
passe si on fait appel � un tiers mais en lui donnant un
role diff�rent, et j'ai l'impression que le degr� de
confiance est au moins le meme et dans certaines circonstances
plus �lev�. Me trompe-je ?
La m�thodologie que je projette :
Avec une clef l�g�re, et un tiers choisi par les partenaires de la
transaction qui va d�tenir la signature (sans connaitre le contenu
de la transaction), est-ce qu'on n'obtient pas le meme niveau de
confiance ? Si c'est pas clair je ferais un sch�ma AUML.
Il me semble que le degr� de confiance est plus �lev� qu'avec une
signature PGP et que seul le tiers choisi par les partenaires
peut usurper le contractant.
Qu'en pensez vous ?
Exemple sur Usenet
Control poste des messages de cr�ation et de destructions
de newsgroups qui sont pris en compte par des serveurs Usenet
si la signature est correcte. Ils utilisent PGP et un nouveau
serveur peut s'inscrire, vu qu'il utilise la clef publique de
Control pour v�rifier la validit� de l'article de controle.
Je reprend l'exemple de Usenet, comment se d�roulerait le processus
si ce syst�me �tait employ� :
Control enverrait au tiers la signature du message (md5 sal�, par exemple
ou strong pgp, �a a peu d'importance). � L'identit� du tiers est
publique.
C'est une transaction en 1x1 tous les moyens de v�rification de l'identit�
de l'annonceur sont possibles. Parall�lement, control poserait l'article de
controle sur un serveur Usenet.
Les serveurs qui recevrait l'article compareraient la signature
avec celle que d�tient le tiers. Si c'est OK, ils proc�deraient
au rmgroup, au newgroup ou au checkgroup.
Si quelqu'un vole ou craque la cl� de Control, il ne peut pas se faire
passer pour Control aupr�s du tiers pour lui faire publier la signature.
Les serveurs usenet qui ne disposent pas de la signature du message sur
le serveur tiers ne peuvent pas faire la comparaison et rejettent
l'article de controle.
--
All truth passes through three stages :
First, it is ridiculed
Second, it is violently opposed
Third, it is accepted as being self-evident
Schopenhauer
Bruno Tréguier
Le 26/12/2009 � 4:56, y...@bidart.net (Yves Lambert) a �crit :
> Si quelqu'un vole ou craque la cl� de Control, il ne peut pas se faire
> passer pour Control aupr�s du tiers pour lui faire publier la signature.
Pourquoi ne le pourrait-il pas ? S'il vole la cl�, il est en mesure de
signer des messages avec, tout comme le ferait le d�tenteur l�gitime,
non ? Qu'est-ce qui le diff�rencierait de ce dernier ?
Je dois avouer (j'en suis d�sol�) que le reste de votre message m'a
sembl� assez n�buleux (d'o� peut-�tre ma mauvaise compr�hension de la
solution expos�e). Pourriez-vous me dire o� je me trompe (si c'est le cas) ?
Cordialement,
Bruno
Yves Lambert
Bruno Tr�guier <bruno.tregui...@nullepart.invalid> writes:
> *Bonjour*,
Bonsoir,
> Le 26/12/2009 � 4:56, y...@bidart.net (Yves Lambert) a �crit :
>> Si quelqu'un vole ou craque la cl� de Control, il ne peut pas se faire
>> passer pour Control aupr�s du tiers pour lui faire publier la signature.
>
> Pourquoi ne le pourrait-il pas ? S'il vole la cl�, il est en mesure de
> signer des messages avec, tout comme le ferait le d�tenteur l�gitime,
> non ? Qu'est-ce qui le diff�rencierait de ce dernier ?
Le fait que ce ne soit pas "tout le monde" aupr�s de qui
l'authentification se fait.
> Je dois avouer (j'en suis d�sol�) que le reste de votre message m'a
> sembl� assez n�buleux (d'o� peut-�tre ma mauvaise compr�hension de la
> solution expos�e). Pourriez-vous me dire o� je me trompe
> (si c'est le cas) ?
L'authentification du contractant aupr�s du tiers n'a pas besoin de se
faire avec une paire cl� publique/clef priv�e, elle peut se faire par
exemple avec un secret partag� ou tout m�canisme convenant � la transaction.
Il s'agit que le contractant soit reconnu par un seul partenaire et pas
par tout le monde.
Bruno Tréguier
> Bonsoir,
Bonsoir,
>> Je dois avouer (j'en suis d�sol�) que le reste de votre message m'a
>> sembl� assez n�buleux (d'o� peut-�tre ma mauvaise compr�hension de la
>> solution expos�e). Pourriez-vous me dire o� je me trompe
>> (si c'est le cas) ?
>
> L'authentification du contractant aupr�s du tiers n'a pas besoin de se
> faire avec une paire cl� publique/clef priv�e, elle peut se faire par
> exemple avec un secret partag� ou tout m�canisme convenant � la transaction.
Un secret partag� se vole tout autant qu'une clef priv�e. Et la
situation est m�me pire dans un tel cas, car une clef priv�e correspond
normalement � une clef publique, associ�e � une identit� et une date de
p�remption, � l'int�rieur d'un certificat. Dans le cas du secret partag�
vous ne b�n�ficiez m�me pas de la possibilit� de r�vocation offert par
le certificat.
> Il s'agit que le contractant soit reconnu par un seul partenaire et pas
> par tout le monde.
Votre m�canisme, si j'ai bien compris, repose sur l'id�e qu'il faudrait
voler 2 secrets diff�rents pour tromper le m�canisme, mais je doute que
cela puisse augmenter le niveau de confiance en quoi que ce soit:
- vous vous reposez sur un interm�diaire, sur qui finalement vous
reportez le probl�me, puisque lui aussi peut se faire voler ses clefs ou
secrets partag�s: 2 points d'entr�e au lieu d'1, bon plan pour un m�chant ;
- vous supposez que 2 secrets seront plus difficiles � voler qu'un seul,
mais cela n'est pas forc�ment le cas si c'est le "contractant", comme
vous l'appelez, qui les poss�de tous les deux (ou alors il faut que
cette info soit dispatch�e sur plusieurs machines, stock�es � diff�rents
endroits, etc., ce qui suppose quelqu'un de relativement prudent.
Pourquoi une telle personne se ferait-elle voler sa clef priv�e (dans le
sch�ma actuel) ?
Il y a un autre argument, certes un peu limite et pas forc�ment tr�s
flatteur pour vous (j'ai bien en t�te la signature de vos messages
usenet, n'ayez crainte ;-) ), mais: ne pensez-vous pas que si un
m�canisme tel que celui que vous d�crivez �tait effectivement plus s�r
que ceux actuellement en usage, il aurait �t� adopt� il y a bien
longtemps ? Mais encore une fois je me trompe peut-�tre...
Cordialement,
Bruno
Yves Lambert
In article <hh63qp$at5$1...@typhon.shom.fr>,
Bruno Tr�guier <bruno.tregui...@nullepart.invalid> writes:
>> Il s'agit que le contractant soit reconnu par un seul partenaire et pas
>> par tout le monde.
>
> Votre m�canisme, si j'ai bien compris, repose sur l'id�e qu'il faudrait
> voler 2 secrets diff�rents pour tromper le m�canisme,
Non, il repose sur un tiers de confiance.
> mais je doute que
> cela puisse augmenter le niveau de confiance en quoi que ce soit:
>
> - vous vous reposez sur un interm�diaire, sur qui finalement vous
> reportez le probl�me, puisque lui aussi peut se faire voler ses clefs
> ou secrets partag�s: 2 points d'entr�e au lieu d'1, bon plan pour un
> m�chant ;
Ben non : un attaquant n'a toujours aucun point d'entr�e. La force du
m�canisme en question repose sur une hypoth�se - qui est peut-etre fausse,
qu'il est possible de renforcer autant que n�cessaire la confiance entre
deux agents d�termin�s. Le seul point d'entr�e qu'aurait un attaquant
serait de se faire passser pour le requ�rant aupr�s du tiers.
> - vous supposez que 2 secrets seront plus difficiles � voler qu'un seul,
Je ne suppose rien de tel, je suppose juste que le tiers dispose d'un
m�canisme pour authentifier le requ�rant. La communication entre
ces deux l� peut etre synchrone, alors que les autres communications se
font par propagation de proche en proche et/ou sont publiques (que ce
soit le cas d'Usenet, d'un SGBD r�partie ou tout autre processus de
requete 1�N).
> mais cela n'est pas forc�ment le cas si c'est le "contractant", comme
> vous l'appelez, qui les poss�de tous les deux (ou alors il faut que
> cette info soit dispatch�e sur plusieurs machines, stock�es � diff�rents
> endroits, etc., ce qui suppose quelqu'un de relativement prudent.
> Pourquoi une telle personne se ferait-elle voler sa clef priv�e (dans le
> sch�ma actuel) ?
Je ne comprend pas bien o� vous voulez en venir. Le tiers a pour mission
de reconnaitre le requ�rant (Control-fr dans le cas de usenet-fr) et de
publier la signature du message authentifi� lorsque celui-ci le lui
demande. Ainsi quand le message parvient � un agent (un serveur usenet)
il v�rifie la signature (signature "faible" : elle ne sert qu'� assurer
que le message n'a pas �t� alt�r�, et pas � en authentifier l'auteur, les
calculs sont peu on�reux) et compare cette signature � celle publi�e par
le tiers. Si le tiers n'a rien publi�, le message n'est pas authentique
et si la signature est diff�rente, il est alt�r�. Inversement si la
signature est publi�e et est la meme que celle du message re�u, celui-ci
a de forte chance d'etre authentique.
> Il y a un autre argument, certes un peu limite et pas forc�ment tr�s
> flatteur pour vous (j'ai bien en t�te la signature de vos messages
> usenet, n'ayez crainte ;-) ), mais: ne pensez-vous pas que si un
> m�canisme tel que celui que vous d�crivez �tait effectivement plus s�r
> que ceux actuellement en usage, il aurait �t� adopt� il y a bien
> longtemps ?
Dans le cas d'Usenet-Fr le m�canisme utilis� actuellement est
probablement suffisant - sauf que les serveurs, s'ils ne sont pas sur
des machines surpuissntes sont mis � genous le temps de v�rifier la
signature PGP. C'est pas tr�s Copenhagen ;)
> Mais encore une fois je me trompe peut-�tre...
Je n'en sais rien - peut-etre pas. Je ne cherche pas non plus � r�inventer
la roue. Ce n'est pas moi qui ait invent� le tiers de confiance non plus.
Christophe Bachmann
>
> Dans le cas d'Usenet-Fr le m�canisme utilis� actuellement est
> probablement suffisant - sauf que les serveurs, s'ils ne sont pas sur
> signature PGP. C'est pas tr�s Copenhagen ;)
>
Le probl�me avec votre proposition est le rapport co�t/b�n�fice.
Etablir un tiers de confiance, assurer sa p�rennit�, sa s�curit�, et sa
confiance est une �uvre lourde et de longue haleine.
Faire en sorte que Control d'un c�t�, et tous les serveurs de France, de
Navarrre, et du monde entier, francophone ou non, modifient leurs
proc�dures d'authentification est une �uvre lourde et vou�e � l'�chec
dans ces temps de d�saffection pour le m�dia et de serveurs fonctionnant
en roue-libre dans un placard, oubli�s de leurs possesseurs. :-)
Et tout �a pour �conomiser quelques watts tous les quelques mois, et,
soyons fou, ajoutons-y trois minutes d'indisponibilit� des serveurs ?
J'ai bien peur qu'il faille des arguments autrement plus solides pour
justifier qu'on envisage s�rieusement votre proposition.
--
Greetings, Salutations,
Guiraud Belissen, Ch�teau du Ciel, Drachenwald,
Chris CII, Rennes, France
Bruno Tréguier
Le 27/12/2009 � 2:35, y...@bidart.net (Yves Lambert) a �crit :
>> Votre m�canisme, si j'ai bien compris, repose sur l'id�e qu'il faudrait
>> voler 2 secrets diff�rents pour tromper le m�canisme,
>
> Non, il repose sur un tiers de confiance.
Un de plus, donc: si le m�canisme utilis� sans votre variante est d�j�
bas� sur des certificats X.509, il y en a d�j� un � la base: l'autorit�
de certification qui a �mis (et sign�) le certificat du "contractant"...
Dans le cas de PGP, on est dans un mod�le de de type "web of trust",
mais l� aussi, il y a au moins 1 tiers de confiance (voire beaucoup plus).
> Ben non : un attaquant n'a toujours aucun point d'entr�e. La force du
> m�canisme en question repose sur une hypoth�se - qui est peut-etre fausse,
> qu'il est possible de renforcer autant que n�cessaire la confiance entre
> deux agents d�termin�s. Le seul point d'entr�e qu'aurait un attaquant
> serait de se faire passser pour le requ�rant aupr�s du tiers.
Ok, je comprends mieux, mais je ne suis pas s�r que votre hypoth�se soit
vraie, justement. Quel m�canisme pourrait �tre mis en oeuvre pour
augmenter de fa�on significative la confiance entre deux entit�s ? Pour
le moment, et toujours sauf erreur de ma part, on en est r�duit aux
m�mes solutions que pour les relations 1*N, et que vous �voquiez dans
votre 1er message: soit le secret partag� (plus facile � utiliser que
dans une relation 1*N, d'accord), soit un m�canisme bas� sur la crypto �
clef publique...
Il existe des chiffreurs bas�s sur les propri�t�s quantiques de la
lumi�re et qui permettent de chiffrer des liens 1*1 entre deux points
(�a fait un peu pl�onasme, �a ;-) ) avec l'assurance qu'il n'y aura pas
d'espionnage de la ligne (ou plus exactement avec l'assurance que toutee
tentative dans ce sens sera d�tect�e), mais leurs limitations sont
importantes: continuit� du lien optique, distance faible, co�t �lev�...
C'est tout sauf une solution universelle, donc. ;-)
En conclusion (de mon c�t� tout au moins), pour le cas g�n�ral, je ne
vois pas bien comment cette esp�ce de "s�questre" de la signature d'un
message par un tiers peut augmenter la confiance globalement, du point
de vue pratique en tout cas.
Bon dimanche !
Cordialement,
Bruno
Yves Lambert
Christophe Bachmann <Chri...@JMVD.Info> writes:
> J'ai bien peur qu'il faille des arguments autrement plus solides pour
> justifier qu'on envisage s�rieusement votre proposition.
Ce n'�tait pas une proposition, le processus de cr�ation/suppression de
forums usenet �tait donn� � titre d'exemple. Les cas o� le besoin de
v�rifier l'int�grit� et l'authenticit� des messages sans pouvoir en
controler l'origine sont l�gions, de la mise � jour d'une base de donn�e
r�partie au pilotage d'une application peer to peer, en passant par des
ordres boursiers etc.
Si je r�sume le point de vue de Bruno, l'hypoth�se que
je fais, qu'il est plus facile d'assurer un niveau de confiance donn�e
entre deux personnes/agents/entit�s ou whatever qu'entre N agents est
fausse ou du moins n'est pas prouv�e ou �tablie or la force du
m�canisme que je propose ne repose que sur �a. Le fait est que je n'y
vois pas d'autres faiblesses, peut-etre que je me trompe l� aussi mais
il faudrait me dire o�.
Bruno Tréguier
Le 27/12/2009 � 15:23, y...@bidart.net (Yves Lambert) a �crit :
> Si je r�sume le point de vue de Bruno, l'hypoth�se que
> je fais, qu'il est plus facile d'assurer un niveau de confiance donn�e
> entre deux personnes/agents/entit�s ou whatever qu'entre N agents est
> fausse ou du moins n'est pas prouv�e ou �tablie or la force du
> m�canisme que je propose ne repose que sur �a. Le fait est que je n'y
> vois pas d'autres faiblesses, peut-etre que je me trompe l� aussi mais
> il faudrait me dire o�.
Il me semble simplement que toute complexification d'un processus doit
�tre justifi�e par une valeur ajout�e claire (ce qui reste � prouver
dans le cas pr�sent), faute de quoi elle est inutile et doit �tre
�vit�e, car il existe toujours un risque qu'au contraire, elle
l'affaiblisse (m�me si cela �galement reste � prouver). Dans les 2 cas,
de toute fa�on, la "charge de la preuve" incombe � celui qui propose la
nouvelle m�thode:
- il doit prouver sa valeur ajout�e (et pas seulement supposer qu'elle
existe) ;
- il doit prouver qu'elle n'affaiblit pas le m�canisme initial.
Concernant les protocoles de communication, je ne suis pas un
sp�cialiste, mais je ne vois pas vraiment, dans l'�tat actuel des
choses, quel m�canisme pourrait �tre plus s�r dans une liaison 1*1 que
dans une liaison 1*N, sauf � utiliser des proc�d�s de chiffrement
habituellement employ�s au niveau gouvernemental (et donc inaccessibles
� la majorit� des gens), ou de la crypto quantique, ou un chiffre de
Vernam (le fameux "one time pad"), mais ces proc�d�s ont leurs
inconv�nients �galement, qui les rendent quasi-inutilisables en
pratique, dans l'immense majorit� des cas: soit ils ont des limitations
techniques, soit ils co�tent tr�s cher, soit les deux � la fois. ;-)
Maintenant, si quelqu'un a un avis plus �clair� que le mien sur la
question (ce qui doit �tre assez simple � trouver), je suis tout ou�e,
bien entendu.
Bonne fin de soir�e !
Cordialement,
Bruno