Il y a trois jours, un
message de violation de masse a
été généré sur la liste de diffusion mozilla.dev.security.policy lors de la génération des certificats TLS. L'enquête a montré que plusieurs autorités de certification étaient concernées, notamment
GoDaddy ,
Apple et
Google . Le nombre total de certificats incorrects dépasse 1 million, et peut-être beaucoup plus. GoDaddy a initialement
nommé le chiffre de 1,8 million de certificats, puis a réduit la note de deux ordres de grandeur à 12 000. Un porte-parole d'Apple a nommé le chiffre de
558 000 certificats .
L'essentiel est que toutes les blessures CA ont utilisé la solution PKI open source
EJBCA avec des paramètres incorrects, à la suite de quoi des nombres aléatoires provenant d'un espace de 63 bits ont été utilisés pour les numéros de série des certificats, ce qui viole
les exigences d' entropie minimales
du CA / B Forum (64 bits).
La différence entre 2
63 et 2
64 dépasse 9 quintillions, soit 9 × 10
18 , c'est un nombre très important (bien que la différence ne soit que de moitié). Tous les certificats doivent être révoqués. Pour SSL.com et GoDaddy, la procédure prendra 30 jours, pour d'autres, elle peut prendre à peu près le même temps, bien que la norme RFC5280 exige que les certificats invalides soient révoqués dans les cinq jours. Mais ils n'ont évidemment pas le temps de respecter la norme.
Comment est-ce arrivé?
Une analyse préliminaire a montré que pour tous les certificats, la longueur du champ correspondant est exactement de 64 bits: ni plus ni moins. Si le RNG produit 64 bits d'entropie et que tous les certificats sont exactement 64 bits, à première vue, tout va bien. Mais le problème est que, selon la
RFC5280 :
Numéro de série
Le numéro de série doit être un entier positif attribué par l'AC à chaque certificat. Il doit être unique pour chaque certificat délivré par une autorité de certification particulière (c'est-à-dire que le nom de l'éditeur et le numéro de série identifient un certificat unique).
Les autorités de certification doivent contrôler strictement la procédure d'émission du CERT afin que le numéro de série ne soit jamais un entier négatif. Les exigences d'unicité présentées ci-dessus suggèrent que les nombres consécutifs peuvent être de longs entiers. Les utilisateurs CERT devraient être en mesure de traiter une valeur dans le sous-champ serialNumber d'une longueur allant jusqu'à 20 octets (inclus). Les autorités de certification suivant cette norme ne doivent pas utiliser de valeurs dans le sous-champ serialNumber supérieures à 20 octets.
Exiger un nombre positif signifie que le bit le plus significatif ne peut pas être défini. S'il est installé, il ne peut pas être utilisé directement comme numéro de série du certificat.
Le système PKI EJBCA populaire, qui est utilisé par de nombreuses autorités de certification, génère par défaut des nombres 64 bits et pour les numéros de certificat réinitialise simplement le bit le plus significatif. En fait, leur RNG produit des nombres de 63 bits, c'est pourquoi de nombreuses autorités de certification ont souffert.
L'exigence par défaut de 64 bits pour RNG n'a pas été formulée à partir de zéro, mais après le
piratage de 2008 , lorsqu'un cluster de 200 consoles de jeux PlayStation 3 a généré des collisions pour le hachage MD5, ce qui
permet de créer un faux centre d'authentification auquel tous les navigateurs et systèmes d'exploitation feront confiance .
En 2012,
la cyber-arme américaine Flame a utilisé cette astuce pour infiltrer le mécanisme de mise à jour de Windows Update.
Cependant, maintenant SHA256 est utilisé pour la génération, c'est un algorithme plus moderne par rapport à MD5, donc l'exigence minimale de 64 bits est adoptée davantage à des fins préventives. Les experts
disent que maintenant il n'y a aucune chance de trouver des collisions en 63 bits et d'exploiter en quelque sorte l'erreur trouvée avec des certificats incorrects.
Mais la révocation de millions de certificats est un casse-tête pour les administrateurs système de nombreuses entreprises.
La perte d'un bit d'entropie n'est pas si terrible, mais quelqu'un quelque part peut trouver une vulnérabilité qui vole encore 1-2 bits, et ainsi de suite. Toutes ces vulnérabilités doivent donc être corrigées immédiatement.
