Quels dommages pourraient être causés si un certificat malveillant avait un "identificateur de clé de sujet" identique?
Je regarde le Subject Key Identifier attribut d'un certificat CA et j'essaie de comprendre le rôle qu'il joue dans la validation et de déduire comment la validation du logiciel client pourrait se tromper.
Quel est le rôle de l'identificateur de clé de sujet dans la validation d'une autorité de certification ou d'un certificat de fin?
Toute connaissance de la façon dont il est implémenté des progiciels populaires serait utileQuel est le pire qu'un attaquant pourrait faire s'il pouvait générer une clé publique contenant également le même hachage?
En lisant RFC328 je vois que le Subject Key Identifier (SKI) est comme la colle qui est utilisée pour construire et vérifier la chaîne PKI. Le SKI semble également être une version plus sécurisée que le numéro de série et le nom du certificat qui ont également été utilisés pour lier deux certificats ensemble.
En ce qui concerne la validation client du hachage de certificat, les clients font-ils simplement une "correspondance de modèle" du SKI, ou le SKI de la chaîne est-il réellement calculé comme décrit ci-dessous:
Pour les certificats CA, les identificateurs de clé de sujet DEVRAIENT être dérivés de
la clé publique ou une méthode qui génère des valeurs uniques. Deux communs
Les méthodes pour générer des identificateurs de clé à partir de la clé publique sont les suivantes:(1) The keyIdentifier is composed of the 160-bit SHA-1 hash of the value of the BIT STRING subjectPublicKey (excluding the tag, length, and number of unused bits). (2) The keyIdentifier is composed of a four bit type field with the value 0100 followed by the least significant 60 bits of the SHA-1 hash of the value of the BIT STRING subjectPublicKey (excluding the tag, length, and number of unused bit string bits).
Un exemple de risque que j'essaie d'atténuer est un certificat de CA mal formé avec une clé publique qui ne hache pas un SKI correct (fait par l'édition manuelle de l'ASN.1 et la démission du certificat depuis la racine de l'attaquant)
Le Subject Key Identifier ne pas joue un rôle dans la validation, du moins pas dans l'algorithme qui constitue la section 6 de RFC 528 . Il est censé être une aide pour la construction de chemins , l'activité qui a lieu avant la validation: c'est lorsque l'entité qui veut valider un certificat assemble le potentiel chaînes de certificats qui seront ensuite traitées par l'algorithme de la section 6. La section 4.2.1.2 décrit cette extension et inclut ce texte:
Pour faciliter la construction du chemin de certification, cette extension DOIT apparaître dans tous les certificats CA conformes, c'est-à-dire tous les certificats, y compris l'extension des contraintes de base (section 4.2.1.9) où la valeur de cA est VRAIE. Dans les certificats CA conformes, la valeur de l'identificateur de clé sujet DOIT être la valeur placée dans le champ identificateur de clé de l'extension d'identificateur de clé d'autorité (section 4.2.1.1) des certificats émis par le sujet de ce certificat. Les applications ne sont pas tenues de vérifier que les identificateurs de clé correspondent lors de la validation du chemin de certification.
Ces "MUST" sont des obligations pour l'AC: pour se conformer au profil décrit dans la RFC 5280, l'AC doit prendre soin de faire correspondre le Authority Key Identifier des certificats qu'il délivre à son propre Subject Key Identifier. Prenez note de la dernière phrase: cette correspondance est pas partie de ce que la validation doit vérifier.
Il est recommandé par la RFC de calculer l'identifiant de clé via le hachage, car il minimisera les collisions, garantissant ainsi une efficacité maximale de cette extension pour la construction de chemins. Cependant, le hachage n'est pas obligatoire. L'AC peut choisir l'identifiant comme bon lui semble; et les vérificateurs font certainement pas recalculent les identificateurs. Il s'agit d'un test d'égalité d'octet à octet pur. En outre, je sais que l'implémentation de validation de chemin par Microsoft est prête à construire et essaie de valider les chemins où les identificateurs de clé ne correspondent pas.
Le pire qu'une AC malhonnête puisse faire en réutilisant des identificateurs de clé est de rendre la construction de chemins plus difficile; cela pourrait déclencher une sorte de déni de service pour les vérificateurs qui font la construction de chemin à travers des identificateurs de clé et sont trop paresseux pour essayer autrement. Dans la pratique, les vérificateurs ont tendance à créer des chemins en faisant correspondre le DN du sujet et de l'émetteur, et non les identificateurs de clé, donc l'impact pratique devrait être proche de zéro.
Les identificateurs de clé rouge empêcheraient la recherche de chemin sans ambiguïté.
Dans le pire des cas, plusieurs chemins potentiels doivent être vérifiés pour la validité. Mais auriez-vous quand même un certificat avec un identifiant rouge dans votre magasin de confiance? Si vous ne lui faites pas confiance, pas besoin de vérifier ce chemin. Et si vous y faites confiance, alors que chemin ne validerait pas.