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
Jean-Marc Desperrier
JJQ wrote:
Arjen Lenstra, Xiaoyun Wang et Benne de Weger ce premier mars 2005:
"Abstract. We announce the construction of a pair of valid X.509 certificates with identical signatures."
Voir http://eprint.iacr.org/2005/067
Félicitations ! La série continue.
La possibilité de ce genre d'attaque a été envisagée dès que l'on a annoncé les collisions sur MD5.
En pratique, la contrainte est que tout soit rigoureusement identique entre les deux certificats, sauf le module de la clé publique.
Cela peut paraître une très grosse restriction mais il existe une attaque pour laquelle c'est presque utile : le déni de signature.
Vous enregistrez le certificat A auprès d'une CA, mais vous signez avec le certificat B, toutes les vérifications marcheront. Si la personne qui vous demande de signer commet l'erreur de ne pas conserver le certificat, mais juste son identification auprès de la CA (une méthode standard est de stocker le nom de la CA ainsi que le numéro de série du certificat), vous pourrez plus tard nier avoir réaliser cette signature, et toutes les vérifications avec le certificat A échoueront, semblant indiquer que cette personne n'avait jamais vérifié la signature et est en tort d'avoir accepté une transaction frauduleuse.
Bon, avant d'affoler tout le monde, je préciserais - qu'il est en général très difficile d'arriver à prévoir de manière exacte le gabarit du certificat avant son émission (ce qui est indispensable pour l'attaque), - que c'est en tout cas impossible avec tous les certificats émis sur la plate-forme du prestataire Keynectis (ex-Certplus) utilisé par la majorité des CA publiques françaises puisque le numéro de série sur 16 octets est un haché d'info comprenant des aléas, - que les schémas de signature qui incluent le haché du certificat utilisé pour signer sont naturellement protégées contre cette attaque (c'est le cas de XAdES et de CAdES alias TS 101 733/RFC3126), - que dans les très grande majorité des cas, on conserve le certificat avec la signature. Il me semble anecdotique d'être dans la situation d'à la fois recevoir du signataire le certificat pour vérifier la signature, et finalement le jeter pour utiliser par la suite celui provenant d'un annuaire autre. En général, on fait toujours le premier cas, quelquefois toujours le second, le mélange des deux me semble rare.
Mais les gens qui se sentent potentiellement concernées ont intérêt à vérifier, je n'ai jamais vu avant une attaque crypto sur la PKI être aussi prêt de quelquechose qui est réellement faisable pratiquement.
JJQ wrote:
Arjen Lenstra, Xiaoyun Wang et Benne de Weger
ce premier mars 2005:
"Abstract. We announce the construction of a pair of valid X.509
certificates with identical signatures."
Voir http://eprint.iacr.org/2005/067
Félicitations ! La série continue.
La possibilité de ce genre d'attaque a été envisagée dès que l'on a
annoncé les collisions sur MD5.
En pratique, la contrainte est que tout soit rigoureusement identique
entre les deux certificats, sauf le module de la clé publique.
Cela peut paraître une très grosse restriction mais il existe une
attaque pour laquelle c'est presque utile : le déni de signature.
Vous enregistrez le certificat A auprès d'une CA, mais vous signez avec
le certificat B, toutes les vérifications marcheront.
Si la personne qui vous demande de signer commet l'erreur de ne pas
conserver le certificat, mais juste son identification auprès de la CA
(une méthode standard est de stocker le nom de la CA ainsi que le numéro
de série du certificat), vous pourrez plus tard nier avoir réaliser
cette signature, et toutes les vérifications avec le certificat A
échoueront, semblant indiquer que cette personne n'avait jamais vérifié
la signature et est en tort d'avoir accepté une transaction frauduleuse.
Bon, avant d'affoler tout le monde, je préciserais
- qu'il est en général très difficile d'arriver à prévoir de manière
exacte le gabarit du certificat avant son émission (ce qui est
indispensable pour l'attaque),
- que c'est en tout cas impossible avec tous les certificats émis sur la
plate-forme du prestataire Keynectis (ex-Certplus) utilisé par la
majorité des CA publiques françaises puisque le numéro de série sur 16
octets est un haché d'info comprenant des aléas,
- que les schémas de signature qui incluent le haché du certificat
utilisé pour signer sont naturellement protégées contre cette attaque
(c'est le cas de XAdES et de CAdES alias TS 101 733/RFC3126),
- que dans les très grande majorité des cas, on conserve le certificat
avec la signature. Il me semble anecdotique d'être dans la situation d'à
la fois recevoir du signataire le certificat pour vérifier la signature,
et finalement le jeter pour utiliser par la suite celui provenant d'un
annuaire autre. En général, on fait toujours le premier cas, quelquefois
toujours le second, le mélange des deux me semble rare.
Mais les gens qui se sentent potentiellement concernées ont intérêt à
vérifier, je n'ai jamais vu avant une attaque crypto sur la PKI être
aussi prêt de quelquechose qui est réellement faisable pratiquement.
Arjen Lenstra, Xiaoyun Wang et Benne de Weger ce premier mars 2005:
"Abstract. We announce the construction of a pair of valid X.509 certificates with identical signatures."
Voir http://eprint.iacr.org/2005/067
Félicitations ! La série continue.
La possibilité de ce genre d'attaque a été envisagée dès que l'on a annoncé les collisions sur MD5.
En pratique, la contrainte est que tout soit rigoureusement identique entre les deux certificats, sauf le module de la clé publique.
Cela peut paraître une très grosse restriction mais il existe une attaque pour laquelle c'est presque utile : le déni de signature.
Vous enregistrez le certificat A auprès d'une CA, mais vous signez avec le certificat B, toutes les vérifications marcheront. Si la personne qui vous demande de signer commet l'erreur de ne pas conserver le certificat, mais juste son identification auprès de la CA (une méthode standard est de stocker le nom de la CA ainsi que le numéro de série du certificat), vous pourrez plus tard nier avoir réaliser cette signature, et toutes les vérifications avec le certificat A échoueront, semblant indiquer que cette personne n'avait jamais vérifié la signature et est en tort d'avoir accepté une transaction frauduleuse.
Bon, avant d'affoler tout le monde, je préciserais - qu'il est en général très difficile d'arriver à prévoir de manière exacte le gabarit du certificat avant son émission (ce qui est indispensable pour l'attaque), - que c'est en tout cas impossible avec tous les certificats émis sur la plate-forme du prestataire Keynectis (ex-Certplus) utilisé par la majorité des CA publiques françaises puisque le numéro de série sur 16 octets est un haché d'info comprenant des aléas, - que les schémas de signature qui incluent le haché du certificat utilisé pour signer sont naturellement protégées contre cette attaque (c'est le cas de XAdES et de CAdES alias TS 101 733/RFC3126), - que dans les très grande majorité des cas, on conserve le certificat avec la signature. Il me semble anecdotique d'être dans la situation d'à la fois recevoir du signataire le certificat pour vérifier la signature, et finalement le jeter pour utiliser par la suite celui provenant d'un annuaire autre. En général, on fait toujours le premier cas, quelquefois toujours le second, le mélange des deux me semble rare.
Mais les gens qui se sentent potentiellement concernées ont intérêt à vérifier, je n'ai jamais vu avant une attaque crypto sur la PKI être aussi prêt de quelquechose qui est réellement faisable pratiquement.
Francois Grieu
Dans l'article <d048jd$ouk$, Jean-Marc Desperrier a écrit:
En pratique, la contrainte est que tout soit rigoureusement identique entre les deux certificats, sauf le module de la clé publique.
Oui. Et donc, de ce point de vue, l'attaque de Xiaoyun Wang est moins générale que la force brute, qui en 2^65 MD5 environ, permet de créer deux certificats où les "issuer distinguished name" sont différents et librement choisis par l'attaquant, et où c'est le module de la clé publique qui rétabli la collision.
Quoi qu'il en soit, et pour contrer toutes les attaques connues et leurs perfectionnements prévisibles, il faut (et il semble qu'il suffit) que les Authorités de Certification imposent un "serial number" imprévisible. Ce que ne faisait pas OpenSSL, quand j'ai regardé il y a presque un an. Il semble que même dans la version 0.9.7e [25 Oct 2004], le "serial number" est incrémental, donc prévisible, quoique initialisé au hasard sur 64 bits à la première utilisation de OpenSSL en AC.
François Grieu
Dans l'article <d048jd$ouk$1@reader1.imaginet.fr>,
Jean-Marc Desperrier <jmdesp@alussinan.org> a écrit:
En pratique, la contrainte est que tout soit rigoureusement
identique entre les deux certificats, sauf le module de la
clé publique.
Oui. Et donc, de ce point de vue, l'attaque de Xiaoyun Wang
est moins générale que la force brute, qui en 2^65 MD5
environ, permet de créer deux certificats où les
"issuer distinguished name" sont différents et librement
choisis par l'attaquant, et où c'est le module de la clé
publique qui rétabli la collision.
Quoi qu'il en soit, et pour contrer toutes les attaques
connues et leurs perfectionnements prévisibles, il faut
(et il semble qu'il suffit) que les Authorités de
Certification imposent un "serial number" imprévisible.
Ce que ne faisait pas OpenSSL, quand j'ai regardé il y a
presque un an. Il semble que même dans la version 0.9.7e
[25 Oct 2004], le "serial number" est incrémental, donc
prévisible, quoique initialisé au hasard sur 64 bits
à la première utilisation de OpenSSL en AC.
Dans l'article <d048jd$ouk$, Jean-Marc Desperrier a écrit:
En pratique, la contrainte est que tout soit rigoureusement identique entre les deux certificats, sauf le module de la clé publique.
Oui. Et donc, de ce point de vue, l'attaque de Xiaoyun Wang est moins générale que la force brute, qui en 2^65 MD5 environ, permet de créer deux certificats où les "issuer distinguished name" sont différents et librement choisis par l'attaquant, et où c'est le module de la clé publique qui rétabli la collision.
Quoi qu'il en soit, et pour contrer toutes les attaques connues et leurs perfectionnements prévisibles, il faut (et il semble qu'il suffit) que les Authorités de Certification imposent un "serial number" imprévisible. Ce que ne faisait pas OpenSSL, quand j'ai regardé il y a presque un an. Il semble que même dans la version 0.9.7e [25 Oct 2004], le "serial number" est incrémental, donc prévisible, quoique initialisé au hasard sur 64 bits à la première utilisation de OpenSSL en AC.
François Grieu
Jean-Marc Desperrier
Francois Grieu wrote:
Quoi qu'il en soit, et pour contrer toutes les attaques connues et leurs perfectionnements prévisibles, il faut (et il semble qu'il suffit) que les Authorités de Certification imposent un "serial number" imprévisible. Ce que ne faisait pas OpenSSL, quand j'ai regardé il y a presque un an. Il semble que même dans la version 0.9.7e [25 Oct 2004], le "serial number" est incrémental, donc prévisible, quoique initialisé au hasard sur 64 bits à la première utilisation de OpenSSL en AC.
Openssl a des tas de qualités, mais si on l'utilise directement en tant qu'AC, c'est un jouet qui a de graves problèmes.
D'après ce que tu dis, c'est maintenant corrigé, mais les anciennes version utilisait comme numéro de série initial 0, ce qui est illégal.
RFC 3280 4.1.2.2 Serial number
The serial number MUST be a positive integer assigned by the CA to each certificate. [...]
Note: Non-conforming CAs may issue certificates with serial numbers that are negative, or zero. [...]
Je me demande si il ne continue pas à le faire quand on lui demande de générer un certificat auto-signé, avec l'option x509 plutôt que celle CA.
Francois Grieu wrote:
Quoi qu'il en soit, et pour contrer toutes les attaques
connues et leurs perfectionnements prévisibles, il faut
(et il semble qu'il suffit) que les Authorités de
Certification imposent un "serial number" imprévisible.
Ce que ne faisait pas OpenSSL, quand j'ai regardé il y a
presque un an. Il semble que même dans la version 0.9.7e
[25 Oct 2004], le "serial number" est incrémental, donc
prévisible, quoique initialisé au hasard sur 64 bits
à la première utilisation de OpenSSL en AC.
Openssl a des tas de qualités, mais si on l'utilise directement en tant
qu'AC, c'est un jouet qui a de graves problèmes.
D'après ce que tu dis, c'est maintenant corrigé, mais les anciennes
version utilisait comme numéro de série initial 0, ce qui est illégal.
RFC 3280
4.1.2.2 Serial number
The serial number MUST be a positive integer assigned by the CA to
each certificate. [...]
Note: Non-conforming CAs may issue certificates with serial numbers
that are negative, or zero. [...]
Je me demande si il ne continue pas à le faire quand on lui demande de
générer un certificat auto-signé, avec l'option x509 plutôt que celle CA.
Quoi qu'il en soit, et pour contrer toutes les attaques connues et leurs perfectionnements prévisibles, il faut (et il semble qu'il suffit) que les Authorités de Certification imposent un "serial number" imprévisible. Ce que ne faisait pas OpenSSL, quand j'ai regardé il y a presque un an. Il semble que même dans la version 0.9.7e [25 Oct 2004], le "serial number" est incrémental, donc prévisible, quoique initialisé au hasard sur 64 bits à la première utilisation de OpenSSL en AC.
Openssl a des tas de qualités, mais si on l'utilise directement en tant qu'AC, c'est un jouet qui a de graves problèmes.
D'après ce que tu dis, c'est maintenant corrigé, mais les anciennes version utilisait comme numéro de série initial 0, ce qui est illégal.
RFC 3280 4.1.2.2 Serial number
The serial number MUST be a positive integer assigned by the CA to each certificate. [...]
Note: Non-conforming CAs may issue certificates with serial numbers that are negative, or zero. [...]
Je me demande si il ne continue pas à le faire quand on lui demande de générer un certificat auto-signé, avec l'option x509 plutôt que celle CA.
Erwann ABALEA
On Thu, 3 Mar 2005, Jean-Marc Desperrier wrote:
[... OpenSSL et les numéros de série de certif ...]
D'après ce que tu dis, c'est maintenant corrigé, mais les anciennes version utilisait comme numéro de série initial 0, ce qui est illégal.
Pas pour la norme, qui autorise même un nombre négatif...
-- Erwann ABALEA - RSA PGP Key ID: 0x2D0EABD5 ----- Press any key to continue or any other key to quit
On Thu, 3 Mar 2005, Jean-Marc Desperrier wrote:
[... OpenSSL et les numéros de série de certif ...]
D'après ce que tu dis, c'est maintenant corrigé, mais les anciennes
version utilisait comme numéro de série initial 0, ce qui est illégal.
Pas pour la norme, qui autorise même un nombre négatif...
--
Erwann ABALEA <erwann@abalea.com> - RSA PGP Key ID: 0x2D0EABD5
-----
Press any key to continue or any other key to quit
