10. Security Considerations (Sicherheitsüberlegungen)

Alle Sicherheitsüberlegungen, die für kryptografische Algorithmen im Allgemeinen gelten, und diejenigen, die speziell für die in dieser Spezifikation verwendeten Algorithmen gelten, gelten auch für diese Spezifikation.

Alle Sicherheitsüberlegungen in [JWA] (JSON Web Algorithms) gelten auch für diese Spezifikation. Implementierer sollten besonders auf die Sicherheitsüberlegungen zur Kryptografie achten, insbesondere auf die Warnungen bezüglich minimaler Schlüssellängen in Abschnitt 3.5 von [JWA].

Die folgenden Sicherheitsüberlegungen gelten für JSON Web Signature (JWS)-Objekte:

10.1 Key Entropy and Random Values (Schlüsselentropie und Zufallswerte)

Siehe Abschnitt 10.1 von [JWA] für Überlegungen zur Schlüsselentropie und Zufallswerten.

Die Stärke jeder Signatur oder jedes MAC hängt kritisch von der Entropie des verwendeten kryptografischen Schlüssels ab. Daher ist es von größter Wichtigkeit, dass Schlüssel mit ausreichender Entropie generiert werden. RFC 4086 [RFC4086] bietet Richtlinien zur Generierung von Zufallswerten mit ausreichender Entropie.

10.2 Key Protection (Schlüsselschutz)

Schlüssel müssen vor Offenlegung und unbefugter Verwendung geschützt werden. Insbesondere müssen private Schlüssel, die für digitale Signaturen verwendet werden, vor Offenlegung und unbefugter Verwendung geschützt werden. Geheime Schlüssel, die für MACs verwendet werden, müssen vor Offenlegung und unbefugter Verwendung geschützt werden.

Methoden zum Schutz von Schlüsseln umfassen:

• Speichern von Schlüsseln in Hardware-Sicherheitsmodulen (HSM)
• Verschlüsseln von Schlüsseln bei der Speicherung
• Beschränken des Zugriffs auf Schlüssel durch Zugriffskontrollmechanismen
• Verwendung geeigneter Schlüssel-Lifecycle-Management-Prozesse

10.3 Key Origin Authentication (Authentifizierung der Schlüsselherkunft)

Wenn ein Schlüssel zur Verifizierung einer Signatur oder eines MAC verwendet wird, muss der Empfänger darauf vertrauen können, dass der Schlüssel tatsächlich vom beabsichtigten Aussteller stammt. Mechanismen zur Etablierung des Vertrauens in die Schlüsselherkunft umfassen:

• Verwendung von X.509-Zertifikaten
• Verwendung von Schlüsseletablierungsprotokollen mit Authentifizierung
• Verwendung von vorab geteilten Schlüsseln mit Quellauthentifizierung
• Abrufen von Schlüsseln aus einem vertrauenswürdigen Schlüsselsatz (JWK Set)

10.4 Cryptographic Agility (Kryptografische Agilität)

Siehe Abschnitt 10.4 von [JWA] für Überlegungen zur kryptografischen Agilität.

Implementierungen sollten so konzipiert sein, dass sie die Migration zu neuen kryptografischen Algorithmen nach Bedarf ermöglichen. Dies kann erreicht werden durch:

• Unterstützung mehrerer Algorithmen
• Ermöglichung der einfachen Konfiguration unterstützter Algorithmen
• Bereitstellung klarer Upgrade-Mechanismen

10.5 Differences between Digital Signatures and MACs (Unterschiede zwischen digitalen Signaturen und MACs)

Digitale Signaturen bieten Authentifizierung und Nicht-Abstreitbarkeit; sie verwenden Public-Key-Kryptografie. MACs bieten Authentifizierung, aber keine Nicht-Abstreitbarkeit; sie verwenden gemeinsame geheime Schlüssel.

In Anwendungen, wo Nicht-Abstreitbarkeit erforderlich ist, müssen (MUST) digitale Signaturen verwendet werden. In Anwendungen, wo Nicht-Abstreitbarkeit nicht erforderlich ist, kann entweder verwendet werden, aber MACs sind oft effizienter.

10.6 Algorithm Validation (Algorithmusvalidierung)

Der Wert des "alg"-Header-Parameters (algorithm, Algorithmus) muss (MUST) überprüft werden, um sicherzustellen, dass er dem von der Anwendung erwarteten Algorithmus entspricht. Dies verhindert Angriffe, bei denen ein Angreifer den "alg"-Wert ändert, um den Empfänger zu veranlassen, einen schwächeren Algorithmus oder einen Algorithmus zu verwenden, den der Angreifer ausnutzen kann.

Implementierungen sollten:

• Unerwartete "alg"-Werte ablehnen
• Eine Whitelist akzeptabler Algorithmen führen
• Niemals blind dem empfangenen "alg"-Wert vertrauen

10.7 Algorithm Protection (Algorithmusschutz)

In Anwendungen, wo der zum Schutz des JWS verwendete Algorithmus für die Sicherheit kritisch ist, sollte (SHOULD) der Algorithmus im JWS Protected Header anstatt im JWS Unprotected Header enthalten sein. Auf diese Weise ist der Algorithmus integritätsgeschützt.

Siehe auch Abschnitt 10.6 von [JWA] und RFC 6211 [RFC6211] für weitere Informationen zum Algorithmusschutz.

10.8 Chosen Plaintext Attacks (Chosen-Plaintext-Angriffe)

JWS-Implementierungen können anfällig für Chosen-Plaintext-Angriffe sein, wenn ein Angreifer das System dazu veranlassen kann, beliebige Payloads zu signieren oder mit MAC zu schützen. Implementierungen sollten:

• Einschränken, welche Payloads signiert oder mit MAC geschützt werden können
• Payloads vor dem Signieren oder MAC-Schutz validieren
• Angemessene Zugriffskontrollmechanismen implementieren

10.9 Timing Attacks (Timing-Angriffe)

Implementierungen müssen so konzipiert sein, dass sie gegen Timing-Angriffe resistent sind. Insbesondere sollten Signatur- und MAC-Verifizierungsoperationen konstante Zeit benötigen, unabhängig davon, ob die Verifizierung erfolgreich ist oder fehlschlägt.

Techniken zur Abschwächung von Timing-Angriffen umfassen:

• Verwendung von Constant-Time-Algorithmen für Signatur-/MAC-Vergleiche
• Vermeidung von vorzeitigem Abbruch bei Verifizierungsfehlern
• Vermeidung von Verhaltensänderungen basierend auf Schlüsselwerten

10.10 Replay Protection (Replay-Schutz)

JWS bietet inhärent keinen Replay-Schutz. Anwendungen, die Replay-Schutz benötigen, müssen ihn auf Anwendungsebene implementieren. Mechanismen zur Verhinderung von Replay umfassen:

• Einbeziehung einer eindeutigen Nummer (Nonce) im Payload
• Einbeziehung eines Zeitstempels und Überprüfung der Frische
• Verwendung von Sliding-Window-Mechanismen
• Führen eines Caches kürzlich gesehener JWS

10.11 SHA-1 Certificate Thumbprints (SHA-1-Zertifikatsfingerabdrücke)

Der "x5t"-Header-Parameter (X.509 certificate SHA-1 thumbprint, X.509-Zertifikat-SHA-1-Fingerabdruck) ist nur aus Gründen der Abwärtskompatibilität enthalten und wird für neue Verwendungen nicht empfohlen. Implementierungen sollten stattdessen den "x5t#S256"-Header-Parameter (X.509 certificate SHA-256 thumbprint, X.509-Zertifikat-SHA-256-Fingerabdruck) verwenden.

10.12 JSON Security Considerations (JSON-Sicherheitsüberlegungen)

Implementierungen müssen sich der Sicherheitsprobleme im Zusammenhang mit der JSON-Verarbeitung bewusst sein, einschließlich:

• JSON-Injection-Angriffe
• Unicode-Normalisierungsprobleme
• JSON-Key-Duplizierungsprobleme
• JSON-Parsing-Probleme (z.B. sehr große Zahlen)

Siehe RFC 7159 [RFC7159] für weitere Informationen zur JSON-Sicherheit.

10.13 Unicode Comparison Security Issues (Unicode-Vergleichs-Sicherheitsprobleme)

Header-Parameter-Namen und String-Werte müssen unter Verwendung des exakten Unicode-String-Wertevergleichs verglichen werden. Implementierungen dürfen keine Unicode-Normalisierung oder andere Transformationen vor dem Vergleich durchführen, da dies zu Sicherheitsschwachstellen führen könnte.