1

ProblemNested JWS + JWE vs JWE mit authentifizierte Verschlüsselung

ich signieren und verschlüsseln wollen (effektiv, verschleiern) einige Informationen ('token') auf meinem Server (eine vertrauenswürdige Umgebung) und senden Sie die Chiffriertext zu eine Client-Maschine (nicht sehr vertrauenswürdige Umgebung), die von meiner clientseitigen Software gelesen und verifiziert werden soll. Dieser Typ der Umgebung ermöglicht es mir, einen privaten Schlüssel auf dem Server für asymmetrisches Signieren zu haben, aber ich kann einen geheimen Schlüssel für symmetrisches Signieren auf einer Clientseite nicht "verstecken".

Alternativen

Ich wählte für die Signierung und Verschlüsselung JWT als Standard und Nimbus JOSE+JWT library als Implementierung zu verwenden. Nimbus Bibliothek bietet zwei Optionen für sign + encrypt: Verschachtelung von JWS in JWE oder Verwendung von JWE mit authentifiziertem Verschlüsselungsalgorithmus (A128CBC_HS256, A192CBC_HS384 oder A256CBC_HS512). Algorithm Selection Guide for Nimbus states:

Die Verschlüsselung in JOSE wird immer authentifiziert, was bedeutet, dass die Integrität des Chiffretexts vor Manipulationen geschützt ist. Authentifizierte Verschlüsselung macht das Verschachteln eines HMAC JWT innerhalb einer JSON Web Encryption (JWE) redundant; Verwenden Sie nur JWE-Verschlüsselung.

Die Verschlüsselungsmethoden AxxxCBC_HSxxx verwenden jedoch nur symmetrische Schlüssel. Darüber hinaus sollte der Ersatz des direkten JWE-Algorithmus durch den RSA-JWE-Algorithmus nicht helfen, da ein Missbraucher CEK (bestehend aus Verschlüsselungsschlüssel und Schlüssel für HMAC) selbst generieren und mit einem öffentlichen Schlüssel verschlüsseln kann.

Frage

Trotz des Zitat über die Redundanz von verschachtelten JWTs, schloss ich, dass für meinen Fall ist JWE + JWS Verschachtelung der einzige praktikable Ansatz. Habe ich recht?

Antwort

1

Clarifications

Alle Inhalte Verschlüsselungsalgorithmen (AxxxGCM und AxxxCBC_HSxxx) verwenden, um einen symmetrischen Schlüssel (CEK). Dieser Schlüssel wird durch den Schlüsselverschlüsselungsalgorithmus und seinen Schlüsselverwaltungsmodus (zufällige CEK, Schlüsselvereinbarung, Direktschlüssel ...) bestimmt.

Sie haben recht, im Gegensatz zu den AxxxGCM Algorithmen sind die AxxxCBC Algorithmen keine authentifizierten Verschlüsselungsalgorithmen. Die RFC7516 section 5.1 item 15. (Spezifikation für JWE) führt jedoch ein Tag ein, das es ermöglicht, den Chiffretext zu authentifizieren und die Integrität des geschützten Headers zu schützen (deshalb wird der AxxxCBC Algorithmus mit dem HSxxx verwendet).

Dies wird durch die Tabelle in der RFC7518 section 5.1 bestätigt. Details finden Sie im nächsten Abschnitt.

In jedem Fall müssen Sie zwei Algorithmen für JWE Berechnung:

  • Der Schlüssel Verschlüsselungsalgorithmus: Sie erwähnten Sie einen asymmetrischen Schlüssel haben, damit ich Sie erraten, wird ein RSA oder ein ECDH-ES Algorithmus wählte je nach Schlüsselart.
  • Der Inhaltsverschlüsselungsschlüssel: AxxxGCM oder AxxxCBC_HSxxx Algorithmen. Mit der JWE-Spezifikation bieten beide eine authentifizierte Verschlüsselung.Persönlich bevorzuge ich AxxxGCM Algorithmen, weil sie in meiner Umgebung schneller sind.

Antwort

Sie haben angegeben, dass Sie signieren und verschlüsseln wollen, aber Sie können nicht einen geheimen Schlüssel auf Client-Seite damit die Signatur verstecken nicht garantiert werden.

Wenn Sie nur verschlüsseln (nur JWE), kann Ihr Server den Aussteller des Tokens nicht überprüfen.

+0

Danke für die ausführliche Antwort. Nur zur Klarstellung: Ich muss mich auf einem Server anmelden und die Echtheit/den Aussteller auf einem Client überprüfen. Ich muss nicht auf einem Server überprüfen. Der Server wird einen privaten Schlüssel haben, und der Client kann relativ sicher einen öffentlichen Schlüssel haben. – Alexey

+0

OK, ja, es gibt kein Problem, wenn Ihr Server den öffentlichen Schlüssel mit Ihrem Client teilt –

Verwandte Themen