Twitter iPhone pliant OnePlus 11 PS5 Disney+ Orange Livebox Windows 11

Tiers de confiance et signature

8 réponses
Avatar
yl
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

8 réponses

Avatar
Bruno Tréguier
*Bonjour*,

Le 26/12/2009 à 4:56, (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
Avatar
yl
In article <hh5r24$7f4$,
Bruno Tréguier writes:
*Bonjour*,



Bonsoir,


Le 26/12/2009 à 4:56, (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.


--
All truth passes through three stages :
First, it is ridiculed
Second, it is violently opposed
Third, it is accepted as being self-evident
Schopenhauer
Avatar
Bruno Tréguier
Le 26/12/2009 à 23:18, (Yves Lambert) a écrit :
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
Avatar
yl
Bonne nuit,

In article <hh63qp$at5$,
Bruno Tréguier 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.


--
All truth passes through three stages :
First, it is ridiculed
Second, it is violently opposed
Third, it is accepted as being self-evident
Schopenhauer
Avatar
Christophe Bachmann
Le 27/12/2009 02:35, Yves Lambert a écrit :

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 ;)



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
Avatar
Bruno Tréguier
Bonjour,

Le 27/12/2009 à 2:35, (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
Avatar
yl
In article <4b372cfa$0$899$,
Christophe Bachmann 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ù.


--
All truth passes through three stages :
First, it is ridiculed
Second, it is violently opposed
Third, it is accepted as being self-evident
Schopenhauer
Avatar
Bruno Tréguier
Bonsoir Yves,

Le 27/12/2009 à 15:23, (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