it-swarm.com.de

Welchen Schaden könnte anrichten, wenn ein böswilliges Zertifikat eine identische "Betreff-Schlüssel-ID" hätte?

Ich schaue auf die Subject Key Identifier Attribut eines CA-Zertifikats und versuche zu verstehen, welche Rolle es bei der Validierung spielt, und daraus zu schließen, wie die Validierung von Client-Software zu Fehlern führen kann.

  • Welche Rolle spielt die Betreffschlüsselkennung bei der Validierung einer Zertifizierungsstelle oder eines Endzertifikats?
    Jedes Wissen darüber, wie es beliebte Softwarepakete implementiert, wäre hilfreich

  • Was ist das Schlimmste, was ein Angreifer tun könnte, wenn er einen öffentlichen Schlüssel generieren könnte, der auch denselben Hash enthält?

Beim Lesen von RFC328 sehe ich, dass der Subject Key Identifier (SKI) dem Klebstoff ähnelt, der zum Erstellen und Überprüfen der PKI-Kette verwendet wird. Die SKI scheint auch eine sicherere Version zu sein als die Seriennummer und der Name des Zertifikats, die auch zum Binden von zwei Zertifikaten verwendet wurden.

Führen Clients in Bezug auf die Client-Validierung des Zertifikat-Hashs einfach eine "Musterübereinstimmung" des SKI durch, oder wird der Ketten-SKI tatsächlich wie unten beschrieben berechnet:

Bei CA-Zertifikaten MÜSSEN Betreffschlüsselkennungen abgeleitet werden
der öffentliche Schlüssel oder eine Methode, die eindeutige Werte generiert. Zwei gemeinsame
Methoden zum Generieren von Schlüsselkennungen aus dem öffentlichen Schlüssel sind:

  (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).

Ein Beispiel für ein Risiko, das ich zu mindern versuche, ist ein fehlerhaftes CA-Zertifikat mit einem öffentlichen Schlüssel, der nicht mit einem korrekten SKI verknüpft ist (erfolgt durch manuelles Bearbeiten und Zurücktreten des Zertifikats durch ASN.1 aus dem Stammverzeichnis des Angreifers).

13

Das Subject Key Identifier spielt nicht eine Rolle bei der Validierung, zumindest nicht im Algorithmus, aus dem Abschnitt 6 von RFC 528 besteht. Es soll eine Hilfe für die Pfadbildung sein, die Aktivität, die vor der Validierung stattfindet: In diesem Fall sammelt die Entität, die ein Zertifikat validieren möchte, Potenziale Zertifikatsketten, die dann über den Algorithmus in Abschnitt 6 verarbeitet werden. Abschnitt 4.2.1.2 beschreibt diese Erweiterung und enthält diesen Text:

Um die Erstellung von Zertifizierungspfaden zu erleichtern, MUSS diese Erweiterung in allen konformen CA-Zertifikaten enthalten sein, dh in allen Zertifikaten, einschließlich der Erweiterung für grundlegende Einschränkungen (Abschnitt 4.2.1.9), in der der Wert von cA TRUE ist. Bei konformen CA-Zertifikaten MUSS der Wert der Betreffschlüsselkennung der Wert sein, der im Feld Schlüsselkennung der Erweiterung der Berechtigungsschlüsselkennung (Abschnitt 4.2.1.1) der vom Betreff dieses Zertifikats ausgestellten Zertifikate angegeben wird. Anwendungen müssen nicht überprüfen, ob die Schlüsselkennungen übereinstimmen, wenn die Validierung des Zertifizierungspfads durchgeführt wird.

Diese "MUSS" sind Verpflichtungen der Zertifizierungsstelle: Um dem von RFC 5280 beschriebenen Profil zu entsprechen, muss die Zertifizierungsstelle darauf achten, dass die Authority Key Identifier der Zertifikate, die es an seine eigenen ausstellt Subject Key Identifier. Beachten Sie den letzten Satz: Diese Übereinstimmung ist nicht Teil dessen, was die Validierung überprüfen muss.

Es wird vom RFC empfohlen, die Schlüsselkennung durch Hashing zu berechnen, da dadurch Kollisionen minimiert werden und somit die maximale Effizienz dieser Erweiterung für die Pfadbildung garantiert wird. Hashing ist jedoch nicht obligatorisch. CA kann die Kennung nach Belieben auswählen. und Verifizierer berechnen mit Sicherheit nicht Bezeichner neu. Dies ist ein reiner Byte-zu-Byte-Gleichheitstest. Ich weiß auch, dass die Implementierung der Pfadüberprüfung durch Microsoft bereit ist, Pfade zu erstellen und zu überprüfen, bei denen die Schlüsselkennungen nicht übereinstimmen.

Das Schlimmste, was eine betrügerische Zertifizierungsstelle durch die Wiederverwendung von Schlüsselkennungen tun könnte, besteht darin, die Pfaderstellung zu erschweren. Dies kann eine Art Denial-of-Service für Verifizierer auslösen, die die Pfadbildung über Schlüsselkennungen durchführen und zu faul sind, um es anders zu versuchen. In der Praxis tendieren Verifizierer dazu, Pfade zu erstellen, indem sie den Subjekt- und Emittenten-DN und nicht die Schlüsselkennungen abgleichen. Daher sollte die praktische Auswirkung nahe Null liegen.

19
Thomas Pornin

Rouge-Schlüsselkennungen würden die eindeutige Pfadfindung behindern.

Im schlimmsten Fall müssen mehrere mögliche Pfade auf ihre Gültigkeit überprüft werden. Aber hätten Sie trotzdem ein Zertifikat mit einer Rouge-ID in Ihrem Trust Store? Wenn Sie ihm nicht vertrauen, müssen Sie diesen Pfad nicht überprüfen. Und wenn Sie ihm vertrauen, wird dieser Pfad nicht validiert.

0
Robert Siemer