[Grieu]
>> Ce papier (que j'avais lu) pr=E9sente deux certificats en collision,
>> mais ces deux certificats font r=E9f=E9rence au m=EAme titulaire.
[Pornin]
> Ah oui, en effet. J'=E9tais persuad=E9 d'avoir vu deux certificats en
> collision avec des noms de sujet distincts (car nous sommes d'accord,
> c'est bien =E7a qui est utile). =C7a n'a rien d'invraisemblable, puisque
> le nom du sujet est, dans un certificat classique, imm=E9diatement suivi
> de la cl=E9 publique (il y a juste l'OID rsaEncryption entre les deux).
Cf. http://www.win.tue.nl/hashclash/TargetCollidingCertificates/ et le
papier a =E9t=E9 accept=E9 =E0 Eurocrypt'07.
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Francois Grieu
Dans l'article , "Pascal Junod" écrit:
Trouvé dans un message datant de fin janvier:
[Grieu]
Ce papier (que j'avais lu) présente deux certificats en collision, mais ces deux certificats font référence au même titulaire.
[Pornin]
Ah oui, en effet. J'étais persuadé d'avoir vu deux certificats en collision avec des noms de sujet distincts (car nous sommes d'accord, c'est bien ça qui est utile). Ça n'a rien d'invraisemblable, puisque le nom du sujet est, dans un certificat classique, immédiatement suivi de la clé publique (il y a juste l'OID rsaEncryption entre les deux).
Merci, celui-ci je l'avais loupé, et c'est clairement, au moins, un net progrès vers une attaque réaliste ET meilleure que la force brute en 2^65 blocd MD5 (qui permet une attaque AMHA assez réaliste). Pour l'instant je n'ai pas exactement compris ce qui motive la réserve faite par les auteurs:
Though our current X.509 certificates construction, involving different Distinghuished Names, should have more attack potential than our previous one (with identical name fields), we have not been able to find truly convincing attack scenarios yet.
François Grieu
Dans l'article <1172130223.652585.11730@p10g2000cwp.googlegroups.com>,
"Pascal Junod" <pascal@junod.info> écrit:
Trouvé dans un message datant de fin janvier:
[Grieu]
Ce papier (que j'avais lu) présente deux certificats en collision,
mais ces deux certificats font référence au même titulaire.
[Pornin]
Ah oui, en effet. J'étais persuadé d'avoir vu deux certificats en
collision avec des noms de sujet distincts (car nous sommes d'accord,
c'est bien ça qui est utile). Ça n'a rien d'invraisemblable, puisque
le nom du sujet est, dans un certificat classique, immédiatement suivi
de la clé publique (il y a juste l'OID rsaEncryption entre les deux).
Merci, celui-ci je l'avais loupé, et c'est clairement, au moins,
un net progrès vers une attaque réaliste ET meilleure que la force
brute en 2^65 blocd MD5 (qui permet une attaque AMHA assez réaliste).
Pour l'instant je n'ai pas exactement compris ce qui motive la
réserve faite par les auteurs:
Though our current X.509 certificates construction, involving
different Distinghuished Names, should have more attack potential
than our previous one (with identical name fields), we have not
been able to find truly convincing attack scenarios yet.
Ce papier (que j'avais lu) présente deux certificats en collision, mais ces deux certificats font référence au même titulaire.
[Pornin]
Ah oui, en effet. J'étais persuadé d'avoir vu deux certificats en collision avec des noms de sujet distincts (car nous sommes d'accord, c'est bien ça qui est utile). Ça n'a rien d'invraisemblable, puisque le nom du sujet est, dans un certificat classique, immédiatement suivi de la clé publique (il y a juste l'OID rsaEncryption entre les deux).
Merci, celui-ci je l'avais loupé, et c'est clairement, au moins, un net progrès vers une attaque réaliste ET meilleure que la force brute en 2^65 blocd MD5 (qui permet une attaque AMHA assez réaliste). Pour l'instant je n'ai pas exactement compris ce qui motive la réserve faite par les auteurs:
Though our current X.509 certificates construction, involving different Distinghuished Names, should have more attack potential than our previous one (with identical name fields), we have not been able to find truly convincing attack scenarios yet.
François Grieu
Pascal Junod
Pour l'instant je n'ai pas exactement compris ce qui motive la réserve faite par les auteurs:
Though our current X.509 certificates construction, involving different Distinghuished Names, should have more attack potential than our previous one (with identical name fields), we have not been able to find truly convincing attack scenarios yet.
Le tout est de se mettre d'accord sur la signification du terme "truly convincing attack scenario" :-)
A+
pascal
Pour l'instant je n'ai pas exactement compris ce qui motive la
réserve faite par les auteurs:
Though our current X.509 certificates construction, involving
different Distinghuished Names, should have more attack potential
than our previous one (with identical name fields), we have not
been able to find truly convincing attack scenarios yet.
Le tout est de se mettre d'accord sur la signification du terme "truly
convincing attack scenario" :-)
Pour l'instant je n'ai pas exactement compris ce qui motive la réserve faite par les auteurs:
Though our current X.509 certificates construction, involving different Distinghuished Names, should have more attack potential than our previous one (with identical name fields), we have not been able to find truly convincing attack scenarios yet.
Le tout est de se mettre d'accord sur la signification du terme "truly convincing attack scenario" :-)
A+
pascal
Francois Grieu
Dans l'article , "Pascal Junod" a écrit:
François Grieu a écrit:
Pour l'instant je n'ai pas exactement compris ce qui motive la réserve faite par les auteurs:
Though our current X.509 certificates construction, involving different Distinghuished Names, should have more attack potential than our previous one (with identical name fields), we have not been able to find truly convincing attack scenarios yet.
Le tout est de se mettre d'accord sur la signification du terme "truly convincing attack scenario" :-)
J'ai davantage parcouru l'article http://eprint.iacr.org/2006/360 et il me semble bien que cette fois, il y a un scénario d'attaque qui peut exploiter certaines infrastructure d'émisson de certificat de manière que je qualifie de plausible, notamment certaines versions d'OpenSSL, *SANS* utiliser la force brute en 2^65 hash MD5. Et que c'est possible grâce à une extension majeure (et dont j'ai récemment écrit ici qu'elle me semblait improbable, ou autre grossière imprudence) de l'attaque de Wang et al contre MD5.
Le progrès majeur, c'est de transformer l'attaque d'origine qui permet de produire une collision entre deux messages de MEME début arbitrairement choisi, en une attaque qui permet de produire une collision entre deux messages de début DIFFERENT arbitrairement choisis.
Le scénario d'attaque que je vois est le suivant; il vise à obtenir un certificat pour la Banque X, et la clé privée correspondante, signée par une autorité de certification reconnue par la cible (par exemple le browser de monsieur tout le monde). Dans ce but, on localise une autorité de certification commerciale enrôlée dans la liste de confiance de la cible (dans le cas où la cible est l'internaute de base, il y a pléthore d'autorités de certification qui se battent pour trouver des clients), ET émettant des certificats X509 reconnus utilisant le format md5withRSAEncryption, ET utilisant pour émettre ces certificats un logiciel qui ne met dans les champs "serial number", "not valid before", "not valid after", "subject distinguished name", que des données prévisibles (ce qui inclu: fournie par le client dans sa requête, en particulier "subject distinguished name" avec le nom et l'adresse du titulaire du certificat). Connaissant d'avance ceci, et l'indentité souaitée (celle de la Banque X, peut-être avec une adresse internet sous contrôle de l'attaquant), la technique de l'article permet directement de produire une requète de certificat, pour une SARL Eve (sous contrôle de l'attaquant), qui va permettre d'obtenir de l'autorité (en justifiant que l'on représente la SARL Eve, et moyennant paiement d'une somme modique) un certificat pour la SARL Eve, qu'il sera possible de transformer en certificat valable pour la Banque X, avec connaissance de la clé privée correspondant au certificat contrefait.
Un examen en 2004 de quelques certificats en circulation montrait qu'il existait encore des autorités de certification enrôlées dans la liste de confiance par défaut de l'OS dominant et acceptant d'émettre des certificats utilisant md5withRSAEncryption, avec des champs "not valid before", "not valid after" manifestement parfaitement prévisibles; mais que, fort heureusement, toutes celles de l'échantillon qui procédaient ainsi utilisaient un champ "serial number" apparemment aléatoire, contrairement à OpenSSL (dans sa version 0.9.7e, la dernière à l'époque).
J'ai évoqué le risque d'une attaque similaire dans ce groupe à plusieurs reprises, par exemple http://groups.google.fr/group/fr.misc.cryptologie/msg/121220eb25207bd0 mais avec usage de la force brute (2^65 hash MD5) pour produire une collision. Marc Stevens a fait bien mieux. Chapeau bas.
J'espère que de nos jours, comme l'attaque par 2^65 hash MD5 était déjà assez crédible depuis longtemps, obsolument toutes les autorités de certification qui admettent encore de produire des certificats utilisant md5withRSAEncryption (et plus généralement md5) mettent de l'aléa (ou autre valeur imprévisible) dans "serial number". Cela me semble une précaution indispensable pour tous les hashs de moins de 256 bits.
Je n'ai pas le temps d'aller voir ce que fait le dernier OpenSSL, ni a fortiori la pratique actuelle des autorités de certification, mais si WinTerminator me lit..
François Grieu
Dans l'article <1172145610.335442.163050@k78g2000cwa.googlegroups.com>,
"Pascal Junod" <pascal@junod.info> a écrit:
François Grieu a écrit:
Pour l'instant je n'ai pas exactement compris ce qui motive la
réserve faite par les auteurs:
Though our current X.509 certificates construction, involving
different Distinghuished Names, should have more attack potential
than our previous one (with identical name fields), we have not
been able to find truly convincing attack scenarios yet.
Le tout est de se mettre d'accord sur la signification du terme
"truly convincing attack scenario" :-)
J'ai davantage parcouru l'article
http://eprint.iacr.org/2006/360
et il me semble bien que cette fois, il y a un scénario d'attaque
qui peut exploiter certaines infrastructure d'émisson de certificat
de manière que je qualifie de plausible, notamment certaines versions
d'OpenSSL, *SANS* utiliser la force brute en 2^65 hash MD5.
Et que c'est possible grâce à une extension majeure (et dont
j'ai récemment écrit ici qu'elle me semblait improbable, ou autre
grossière imprudence) de l'attaque de Wang et al contre MD5.
Le progrès majeur, c'est de transformer l'attaque d'origine qui
permet de produire une collision entre deux messages de MEME début
arbitrairement choisi, en une attaque qui permet de produire une
collision entre deux messages de début DIFFERENT arbitrairement
choisis.
Le scénario d'attaque que je vois est le suivant; il vise à obtenir
un certificat pour la Banque X, et la clé privée correspondante,
signée par une autorité de certification reconnue par la cible
(par exemple le browser de monsieur tout le monde).
Dans ce but, on localise une autorité de certification commerciale
enrôlée dans la liste de confiance de la cible (dans le cas où la
cible est l'internaute de base, il y a pléthore d'autorités de
certification qui se battent pour trouver des clients), ET émettant
des certificats X509 reconnus utilisant le format md5withRSAEncryption,
ET utilisant pour émettre ces certificats un logiciel qui ne met dans
les champs "serial number", "not valid before", "not valid after",
"subject distinguished name", que des données prévisibles (ce qui
inclu: fournie par le client dans sa requête, en particulier
"subject distinguished name" avec le nom et l'adresse du titulaire
du certificat).
Connaissant d'avance ceci, et l'indentité souaitée (celle de la
Banque X, peut-être avec une adresse internet sous contrôle de
l'attaquant), la technique de l'article permet directement de
produire une requète de certificat, pour une SARL Eve (sous contrôle
de l'attaquant), qui va permettre d'obtenir de l'autorité (en
justifiant que l'on représente la SARL Eve, et moyennant paiement
d'une somme modique) un certificat pour la SARL Eve, qu'il sera
possible de transformer en certificat valable pour la Banque X,
avec connaissance de la clé privée correspondant au certificat
contrefait.
Un examen en 2004 de quelques certificats en circulation
montrait qu'il existait encore des autorités de certification
enrôlées dans la liste de confiance par défaut de l'OS dominant
et acceptant d'émettre des certificats utilisant md5withRSAEncryption,
avec des champs "not valid before", "not valid after" manifestement
parfaitement prévisibles; mais que, fort heureusement, toutes celles
de l'échantillon qui procédaient ainsi utilisaient un champ
"serial number" apparemment aléatoire, contrairement à OpenSSL
(dans sa version 0.9.7e, la dernière à l'époque).
J'ai évoqué le risque d'une attaque similaire dans ce groupe à
plusieurs reprises, par exemple
http://groups.google.fr/group/fr.misc.cryptologie/msg/121220eb25207bd0
mais avec usage de la force brute (2^65 hash MD5) pour produire une
collision. Marc Stevens a fait bien mieux. Chapeau bas.
J'espère que de nos jours, comme l'attaque par 2^65 hash MD5
était déjà assez crédible depuis longtemps, obsolument toutes les
autorités de certification qui admettent encore de produire des
certificats utilisant md5withRSAEncryption (et plus généralement
md5) mettent de l'aléa (ou autre valeur imprévisible) dans
"serial number". Cela me semble une précaution indispensable
pour tous les hashs de moins de 256 bits.
Je n'ai pas le temps d'aller voir ce que fait le dernier OpenSSL,
ni a fortiori la pratique actuelle des autorités de certification,
mais si WinTerminator me lit..
Pour l'instant je n'ai pas exactement compris ce qui motive la réserve faite par les auteurs:
Though our current X.509 certificates construction, involving different Distinghuished Names, should have more attack potential than our previous one (with identical name fields), we have not been able to find truly convincing attack scenarios yet.
Le tout est de se mettre d'accord sur la signification du terme "truly convincing attack scenario" :-)
J'ai davantage parcouru l'article http://eprint.iacr.org/2006/360 et il me semble bien que cette fois, il y a un scénario d'attaque qui peut exploiter certaines infrastructure d'émisson de certificat de manière que je qualifie de plausible, notamment certaines versions d'OpenSSL, *SANS* utiliser la force brute en 2^65 hash MD5. Et que c'est possible grâce à une extension majeure (et dont j'ai récemment écrit ici qu'elle me semblait improbable, ou autre grossière imprudence) de l'attaque de Wang et al contre MD5.
Le progrès majeur, c'est de transformer l'attaque d'origine qui permet de produire une collision entre deux messages de MEME début arbitrairement choisi, en une attaque qui permet de produire une collision entre deux messages de début DIFFERENT arbitrairement choisis.
Le scénario d'attaque que je vois est le suivant; il vise à obtenir un certificat pour la Banque X, et la clé privée correspondante, signée par une autorité de certification reconnue par la cible (par exemple le browser de monsieur tout le monde). Dans ce but, on localise une autorité de certification commerciale enrôlée dans la liste de confiance de la cible (dans le cas où la cible est l'internaute de base, il y a pléthore d'autorités de certification qui se battent pour trouver des clients), ET émettant des certificats X509 reconnus utilisant le format md5withRSAEncryption, ET utilisant pour émettre ces certificats un logiciel qui ne met dans les champs "serial number", "not valid before", "not valid after", "subject distinguished name", que des données prévisibles (ce qui inclu: fournie par le client dans sa requête, en particulier "subject distinguished name" avec le nom et l'adresse du titulaire du certificat). Connaissant d'avance ceci, et l'indentité souaitée (celle de la Banque X, peut-être avec une adresse internet sous contrôle de l'attaquant), la technique de l'article permet directement de produire une requète de certificat, pour une SARL Eve (sous contrôle de l'attaquant), qui va permettre d'obtenir de l'autorité (en justifiant que l'on représente la SARL Eve, et moyennant paiement d'une somme modique) un certificat pour la SARL Eve, qu'il sera possible de transformer en certificat valable pour la Banque X, avec connaissance de la clé privée correspondant au certificat contrefait.
Un examen en 2004 de quelques certificats en circulation montrait qu'il existait encore des autorités de certification enrôlées dans la liste de confiance par défaut de l'OS dominant et acceptant d'émettre des certificats utilisant md5withRSAEncryption, avec des champs "not valid before", "not valid after" manifestement parfaitement prévisibles; mais que, fort heureusement, toutes celles de l'échantillon qui procédaient ainsi utilisaient un champ "serial number" apparemment aléatoire, contrairement à OpenSSL (dans sa version 0.9.7e, la dernière à l'époque).
J'ai évoqué le risque d'une attaque similaire dans ce groupe à plusieurs reprises, par exemple http://groups.google.fr/group/fr.misc.cryptologie/msg/121220eb25207bd0 mais avec usage de la force brute (2^65 hash MD5) pour produire une collision. Marc Stevens a fait bien mieux. Chapeau bas.
J'espère que de nos jours, comme l'attaque par 2^65 hash MD5 était déjà assez crédible depuis longtemps, obsolument toutes les autorités de certification qui admettent encore de produire des certificats utilisant md5withRSAEncryption (et plus généralement md5) mettent de l'aléa (ou autre valeur imprévisible) dans "serial number". Cela me semble une précaution indispensable pour tous les hashs de moins de 256 bits.
Je n'ai pas le temps d'aller voir ce que fait le dernier OpenSSL, ni a fortiori la pratique actuelle des autorités de certification, mais si WinTerminator me lit..
