10. Sicherheitsbetrachtungen

JWS/JWE/JWK-Agenten müssen alle Sicherheitsfragen behandeln, die für jede kryptografische Anwendung relevant sind. Dazu gehören der Schutz asymmetrischer privater Schlüssel und symmetrischer geheimer Schlüssel des Benutzers sowie Gegenmaßnahmen gegen verschiedene Angriffe.

Alle Sicherheitsbetrachtungen in „XML Signature Syntax and Processing Version 2.0“ [W3C.NOTE-xmldsig-core2-20130411] gelten, mit Ausnahme der XML-spezifischen Aspekte, auch für diese Spezifikation. Ebenso gelten viele der in „XML Signature Best Practices“ [W3C.NOTE-xmldsig-bestpractices-20130411] dokumentierten bewährten Vorgehensweisen, mit Ausnahme der XML-spezifischen Aspekte, für diese Spezifikation.

10.1 Schlüsselentropie und Zufallswerte

Schlüssel sind nur so stark wie die Entropiemenge, die bei ihrer Erzeugung verwendet wird. Für alle Schlüssel SOLLTEN mindestens 128 Bit Entropie verwendet werden; je nach Anwendungskontext kann mehr erforderlich sein.

Implementierungen müssen öffentliche/private Schlüsselpaare, MAC-Schlüssel und Auffüllwerte zufällig erzeugen. Die Verwendung ungeeigneter Pseudozufallszahlengeneratoren (PRNGs) zur Erzeugung kryptografischer Schlüssel kann zu geringer oder keiner Sicherheit führen. Ein Angreifer kann die PRNG-Umgebung, die die Schlüssel erzeugt hat, möglicherweise wesentlich leichter nachbilden und die daraus resultierende kleine Menge an Möglichkeiten durchsuchen, als den gesamten Schlüsselraum durch Brute Force zu durchsuchen. Die Erzeugung hochwertiger Zufallszahlen ist schwierig. RFC 4086 [RFC4086] enthält wichtige Hinweise dazu.

10.2 Schlüsselschutz

Implementierungen müssen den privaten Schlüssel des Unterzeichners schützen. Die Kompromittierung dieses Schlüssels ermöglicht einem Angreifer, sich als Unterzeichner auszugeben.

Implementierungen müssen den MAC-Schlüssel schützen. Die Kompromittierung des MAC-Schlüssels kann zu nicht erkennbaren Änderungen am authentifizierten Inhalt führen.

10.3 Authentisierung der Schlüsselherkunft

Das zur Beschaffung öffentlicher Schlüssel verwendete Schlüsselverwaltungsverfahren muss die Herkunft des Schlüssels authentisieren; andernfalls ist nicht bekannt, welche Partei die Nachricht signiert hat.

Entsprechend muss das zum Verteilen von MAC-Schlüsseln verwendete Schlüsselverwaltungsverfahren eine Authentisierung der Datenherkunft bereitstellen; andernfalls werden die Inhalte zwar integer, aber aus einer unbekannten Quelle geliefert.

10.4 Kryptografische Agilität

Siehe Abschnitt 8.1 von [JWA] für Sicherheitsbetrachtungen zur kryptografischen Agilität.

10.5 Unterschiede zwischen digitalen Signaturen und MACs

MACs und digitale Signaturen können beide für Integritätsprüfungen eingesetzt werden, unterscheiden sich jedoch erheblich hinsichtlich der jeweils bereitgestellten Sicherheitseigenschaften. Diese Unterschiede müssen beim Entwurf von Protokollen und bei der Auswahl der darin verwendeten Algorithmen berücksichtigt werden.

Sowohl Signaturen als auch MACs ermöglichen Integritätsprüfungen, also die Verifikation, dass die Nachricht seit der Berechnung des Integritätswerts nicht geändert wurde. MACs bieten eine Herkunftsidentifikation jedoch nur unter bestimmten Umständen. Normalerweise kann angenommen werden, dass sich ein für eine Signatur verwendeter privater Schlüssel nur im Besitz einer einzigen Entität befindet, bei replizierten Servern gegebenenfalls einer verteilten Entität. Ein MAC-Schlüssel muss dagegen im Besitz aller Entitäten sein, die ihn zur Integritätsberechnung und -prüfung verwenden. Die Prüfung eines MAC bestätigt lediglich, dass die Nachricht von einer der Parteien erzeugt wurde, die den symmetrischen MAC-Schlüssel kennt. Die Herkunft lässt sich daher nur bestimmen, wenn ein MAC-Schlüssel ausschließlich zwei Entitäten bekannt ist und der Empfänger weiß, dass er die Nachricht nicht selbst erzeugt hat. Eine MAC-Prüfung kann gegenüber Dritten nicht als Herkunftsnachweis dienen.

10.6 Algorithmusvalidierung

Die digitalen Signaturdarstellungen einiger Algorithmen enthalten innerhalb des Signaturwerts Informationen über den verwendeten Algorithmus. Beispielsweise kodieren mit RSASSA-PKCS1-v1_5 [RFC3447] erzeugte Signaturen die verwendete Hash-Funktion, und viele Bibliotheken verwenden bei der Signaturprüfung tatsächlich den in der Signatur angegebenen Hash-Algorithmus. Bei Verwendung solcher Bibliotheken MÜSSEN Implementierungen im Rahmen der Algorithmusvalidierung sicherstellen, dass die in der Signatur kodierte Algorithmusinformation dem im Header-Parameter „alg“ angegebenen Algorithmus entspricht. Andernfalls könnte ein Angreifer behaupten, einen starken Hash-Algorithmus verwendet zu haben, obwohl im Signaturwert tatsächlich ein schwacher Algorithmus repräsentiert ist.

10.7 Algorithmusschutz

Bei einigen Verwendungen von JWS besteht das Risiko von Algorithmus-Substitutionsangriffen: Ein Angreifer kann einen vorhandenen digitalen Signaturwert mit einem anderen Signaturalgorithmus verwenden und dadurch den Anschein erwecken, ein Unterzeichner habe etwas signiert, was er nicht signiert hat. Diese Angriffe wurden im Kontext von Cryptographic Message Syntax (CMS) [RFC6211] ausführlich behandelt. Das Risiko entsteht, wenn alle folgenden Bedingungen erfüllt sind:

Prüfer einer Signatur unterstützen mehrere Algorithmen.
Ausgehend von einer vorhandenen Signatur kann ein Angreifer eine andere Nutzlast finden, die mit einem anderen Algorithmus denselben Signaturwert erzeugt.
Die vom Angreifer konstruierte Nutzlast ist im Anwendungskontext gültig.

Eine Anwendung kann Algorithmus-Substitutionsangriffe auf verschiedene Weise abmildern:

Es werden nur digitale Signaturalgorithmen verwendet, die nicht für Substitutionsangriffe anfällig sind. Solche Angriffe sind nur möglich, wenn ein Angreifer Urbilder für eine vom Empfänger akzeptierte Hash-Funktion berechnen kann. Alle in JWA definierten Signaturalgorithmen verwenden SHA-2-Hashes, für die zum Zeitpunkt dieses Dokuments keine Angriffe auf Urbilder bekannt sind.
Der Header-Parameter „alg“ wird im geschützten JWS-Header verlangt. Dies ist bei der JWS Compact Serialization stets der Fall und entspricht dem von CMS [RFC6211] verfolgten Ansatz.
Die Anwendungsnutzlast enthält ein Feld mit dem Algorithmus, und bei der Prüfung wird verlangt, dass es mit dem Header-Parameter „alg“ übereinstimmt. Dies entspricht dem von PKIX [RFC5280] verfolgten Ansatz.

10.8 Angriffe mit gewähltem Klartext

Ersteller von JWSs SOLLTEN Dritten nicht erlauben, beliebige Inhalte in die Nachricht einzufügen, ohne Entropie hinzuzufügen, die nicht von diesen Dritten kontrolliert wird.

10.9 Timing-Angriffe

Werden kryptografische Algorithmen so implementiert, dass erfolgreiche Operationen eine andere Zeit benötigen als erfolglose Operationen, können Angreifer den Zeitunterschied möglicherweise nutzen, um Informationen über die verwendeten Schlüssel zu erhalten. Solche Zeitunterschiede müssen daher vermieden werden.

10.10 Schutz vor Wiederholungsangriffen

Obwohl dies nicht unmittelbar Gegenstand dieser Spezifikation ist, können Anwendungen, die JWS- oder JWE-Objekte verwenden, Wiederholungsangriffe vereiteln, indem sie eine eindeutige Nachrichtenkennung als integritätsgeschützten Inhalt in die JWS- bzw. JWE-Nachricht aufnehmen und den Empfänger prüfen lassen, dass die Nachricht nicht bereits empfangen oder verarbeitet wurde.

10.11 SHA-1-Zertifikats-Fingerabdrücke

Bei der Berechnung von Werten für „x5t“ (SHA-1-Fingerabdruck eines X.509-Zertifikats) wird aus Kompatibilitätsgründen ein SHA-1-Hash verwendet. Sollte ein wirksames Verfahren zur Erzeugung von SHA-1-Kollisionen entwickelt werden und ein Angreifer die Verwendung eines bekannten Zertifikats auf einem bestimmten System beeinträchtigen wollen, könnte er ein anderes Zertifikat mit demselben SHA-1-Hashwert erzeugen und es dem vom vorgesehenen Opfer verwendeten Zertifikatsspeicher hinzufügen. Voraussetzung für den Erfolg dieses Angriffs ist Schreibzugriff des Angreifers auf den Zertifikatsspeicher des vorgesehenen Opfers.

Alternativ kann anstelle von „x5t“ der Header-Parameter „x5t#S256“ (SHA-256-Fingerabdruck eines X.509-Zertifikats) verwendet werden. Zum Zeitpunkt dieses Dokuments war jedoch keine Entwicklungsplattform bekannt, die SHA-256-Zertifikats-Fingerabdrücke unterstützt.

10.12 JSON-Sicherheitsbetrachtungen

Eine strikte JSON-Validierung nach [RFC7159] ist eine Sicherheitsanforderung. Wenn fehlerhaftes JSON empfangen wird, kann die Absicht des Erzeugers nicht zuverlässig festgestellt werden. Wenn der verwendete JSON-Parser fehlerhafte JSON-Syntax nicht zurückweist, können mehrdeutige und möglicherweise ausnutzbare Situationen entstehen. Insbesondere MÜSSEN JSON-Parser alle JSON-Eingaben vollständig zurückweisen, die nicht der in RFC 7159 definierten JSON-Text-Syntax entsprechen.

Abschnitt 4 von „The JavaScript Object Notation (JSON) Data Interchange Format“ [RFC7159] besagt: „The names within an object SHOULD be unique“, während diese Spezifikation Folgendes festlegt:

Die Namen der Header-Parameter innerhalb des JOSE-Headers MÜSSEN eindeutig sein. JWS-Parser MÜSSEN entweder JWSs mit doppelten Header-Parameternamen zurückweisen oder einen JSON-Parser verwenden, der nur den lexikalisch letzten doppelten Mitgliedsnamen zurückgibt, wie in Abschnitt 15.12 („The JSON Object“) von ECMAScript 5.1 [ECMAScript] angegeben.

Diese Spezifikation verlangt somit, dass Erzeuger das „SHOULD“ in Abschnitt 4 von [RFC7159] als „MUST“ behandeln und Verbraucher es entweder als „MUST“ behandeln oder entsprechend ECMAScript 5.1 verfahren. Wenn der verwendete JSON-Parser die Eindeutigkeit von Mitgliedsnamen nicht erzwingt oder für doppelte Mitgliedsnamen einen nicht vorhersehbaren Wert zurückgibt, können mehrdeutige und möglicherweise ausnutzbare Situationen entstehen.

Einige JSON-Parser weisen Eingaben mit zusätzlichen signifikanten Zeichen nach einer gültigen Eingabe möglicherweise nicht zurück. Beispielsweise enthält die Eingabe "{"tag":"value"}ABCD" ein gültiges JSON-Textobjekt, gefolgt von den zusätzlichen Zeichen „ABCD“. Implementierungen MÜSSEN JWSs, die solche Eingaben enthalten, als ungültig betrachten.

10.13 Unicode-Vergleiche: Sicherheitsbetrachtungen

Header-Parameternamen und Algorithmusnamen sind Unicode-Zeichenketten. Aus Sicherheitsgründen müssen die Darstellungen dieser Namen nach jeder Escape-Verarbeitung wortgetreu verglichen werden, wie in Abschnitt 8.3 von RFC 7159 [RFC7159] beschrieben. Das bedeutet beispielsweise, dass diese JSON-Zeichenketten als gleich verglichen werden müssen („sig“, „\u0073ig“), während diese Zeichenketten weder mit der ersten Menge noch untereinander gleich sein dürfen („SIG“, „Sig“, „si\u0047“).

JSON-Zeichenketten können Zeichen außerhalb der Unicode Basic Multilingual Plane enthalten. Beispielsweise kann das G-Schlüssel-Zeichen (U+1D11E) in einer JSON-Zeichenkette als „\uD834\uDD1E“ dargestellt werden. Idealerweise SOLLTEN JWS-Implementierungen sicherstellen, dass Zeichen außerhalb der Basic Multilingual Plane korrekt erhalten und verglichen werden. Ist dies wegen Einschränkungen der zugrunde liegenden JSON-Implementierung nicht möglich, MÜSSEN Eingaben, die solche Zeichen enthalten, zurückgewiesen werden.