Danke für Ihr Feedback.

Wie wir das JWE-Format verwenden

In diesem Abschnitt wird beschrieben, wie wir erwarten, dass das JWE als Eingabe für die Geräte erstellt wird, sodass Sie Ihr eigenes Tool erstellen können, um die Blobs aus Ihren Zertifikaten und Schlüsseln zu erstellen.

Siehe JSON Web Encryption (JWE) https://datatracker.ietf.org/doc/html/rfc7516 und JSON Web Signature (JWS) https://datatracker.ietf.org/doc/html/rfc7515.

Wir verwenden die kompakte Serialisierung eines JSON-Dokuments, um JWE-Blobs zu erstellen. Die Parameter, die Sie bei der Erstellung der JWE-Blobs angeben müssen, sind:

• JOSE Header (geschützt). Im JSON Object Signing and Encryption-Header MÜSSEN Sie die folgenden Schlüssel-Wert-Paare angeben:

  • „alg“ :"dir“

    Der direkte Algorithmus ist der einzige, den wir für die Verschlüsselung der Nutzdaten unterstützen, und Sie müssen das anfängliche Client-Geheimnis des Geräts verwenden.

  • „enc“ :"A128GCM“ oder „enc“ :"A256GCM“

    Wir unterstützen diese beiden Verschlüsselungsalgorithmen.

  • „cisco-action“: „add“ oder „cisco-action“: „populate“ oder „cisco-action“: „activate“ oder „cisco-action“: „deaktivieren“

    Das ist ein proprietärer Schlüssel und vier Werte, die er annehmen kann. Wir haben diesen Schlüssel eingeführt, um dem Zielgerät den Zweck der verschlüsselten Daten zu signalisieren. Die Werte sind nach den xAPI-Befehlen auf dem Gerät benannt, auf dem Sie die verschlüsselten Daten verwenden.

    Wir haben es Cisco-Action genannt, um potenzielle Konflikte mit zukünftigen JWE-Erweiterungen zu mildern.

  • „cisco-kdf“: {„version“: „1", „salt“: „Base64UrlEncodedRandom4+Byte“}

    Ein weiterer proprietärer Schlüssel. Wir verwenden die von Ihnen angegebenen Werte als Eingaben für die Schlüsselableitung auf dem Gerät. Die Version muss 1 sein (die Version unserer wichtigsten Ableitungsfunktion). Der Wert von Salt muss eine Base64-URL-kodierte Sequenz von mindestens 4 Byte sein, die Sie zufällig auswählen müssen.

• JWE-verschlüsselter Schlüssel. Dieses Feld ist leer. Das Gerät leitet es vom ursprünglichen ClientSecret ab.

• JWE-Initialisierungsvektor. Sie müssen einen Base64Url-kodierten Initialisierungsvektor für die Entschlüsselung der Nutzlast angeben. Die IV MUSS ein zufälliger 12-Byte-Wert sein (wir verwenden die AES-GCM-Verschlüsselungsfamilie, weshalb die IV 12 Byte lang sein muss).

• JWE AAD (zusätzliche authentifizierte Daten). Sie müssen dieses Feld weglassen, da es in der Compact Serialization nicht unterstützt wird.

• JWE Ciphertext: Das ist die verschlüsselte Nutzlast, die Sie geheim halten möchten.

  Die Nutzlast KANN leer sein. Um zum Beispiel das Client-Geheimnis zurückzusetzen, müssen Sie es mit einem leeren Wert überschreiben.

  Es gibt verschiedene Arten von Payloads, je nachdem, was Sie auf dem Gerät zu tun versuchen. Verschiedene xAPI-Befehle erwarten unterschiedliche Nutzlasten, und Sie müssen den Zweck der Nutzlast mit dem Cisco-Action-Schlüssel wie folgt angeben:

  • Mit „cisco-action“ :"populate“ ist der Chiffretext das neue ClientSecret.

  • Mit "„cisco-action“ :"add“ ist der Chiffretext ein PEM-Blob, das das Zertifikat und seinen privaten Schlüssel (verkettet) enthält.

  • Mit "„cisco-action“ :"activate“ ist der Chiffretext der Fingerabdruck (hexadezimale Darstellung von sha-1) des Zertifikats, das wir für die Überprüfung der Geräteidentität aktivieren.

  • Mit "„cisco-action“ :"deactivate“ ist der Chiffretext der Fingerabdruck (hexadezimale Darstellung von sha-1) des Zertifikats, das wir deaktivieren, damit es nicht für die Geräteidentitätsprüfung verwendet wird.

• JWE-Authentifizierungs-Tag: Dieses Feld enthält das Authentifizierungs-Tag, um die Integrität des gesamten kompakt serialisierten JWE-Blobs zu überprüfen

Wie wir den Verschlüsselungsschlüssel aus dem ClientSecret ableiten

Nach der ersten Auffüllung des Geheimnisses akzeptieren wir das Geheimnis nicht und geben es nicht als Klartext aus. Dies dient dazu, potenzielle Wörterbuchangriffe durch jemanden zu verhindern, der auf das Gerät zugreifen könnte.

Die Gerätesoftware verwendet das Client-Geheimnis als Eingabe für eine Schlüsselableitungsfunktion (kdf) und verwendet dann den abgeleiteten Schlüssel für die Entschlüsselung/Verschlüsselung von Inhalten auf dem Gerät.

Für Sie bedeutet das, dass Ihr Tool zur Erzeugung von JWE-Blobs dasselbe Verfahren anwenden muss, um denselben Verschlüsselungs-/Entschlüsselungsschlüssel aus dem Client-Geheimnis abzuleiten.

Die Geräte verwenden Scrypt für die Schlüsselableitung (siehe https://en.wikipedia.org/wiki/Scrypt), mit den folgenden Parametern:

• CostFactor (N) ist 32768

• BlockSizeFactor (r) ist 8

• ParallelizationFactor (p) ist 1

• Salt ist eine zufällige Folge von mindestens 4 Byte; Sie müssen dasselbe Salt angeben, wenn Sie den Parameter cisco-kdf angeben.

• Die Schlüssellängen sind entweder 16 Byte (wenn Sie den AES-GCM-128-Algorithmus wählen) oder 32 Byte (wenn Sie den AES-GCM-256-Algorithmus wählen)

• Die maximale Speicherobergrenze beträgt 64 MB

Dieser Parametersatz ist die einzige Konfiguration von Scrypt, die mit der Schlüsselableitungsfunktion auf den Geräten kompatibel ist. Dieses KDF auf den Geräten heißt „Version“ :"1", was die einzige Version ist, die derzeit vom Parameter cisco-kdf verwendet wird.

Funktioniertes Beispiel

Hier ist ein Beispiel, dem Sie folgen können, um zu überprüfen, ob Ihr JWE-Verschlüsselungsprozess genauso funktioniert wie der Prozess, den wir auf den Geräten erstellt haben.

Das Beispielszenario ist das Hinzufügen eines PEM-Blobs zum Gerät (ahmt das Hinzufügen eines Zertifikats nach, mit einer sehr kurzen Zeichenfolge anstelle eines vollständigen Zertifikats + Schlüssel). Das Kundengeheimnis in dem Beispiel ist Ossifrage.

1. Wählen Sie eine Verschlüsselungschiffre. Dieses Beispiel verwendet A128GCM (AES mit 128-Bit-Schlüsseln im Galois-Zählermodus). Ihr Tool könnte A256GCM verwenden, wenn Sie es vorziehen.

2. Wählen Sie ein Salz (muss eine zufällige Folge von mindestens 4 Byte sein). Dieses Beispiel verwendet (Hex-Bytes) E5 E6 53 08 03 F8 33 F6. Base64URL kodieren Sie die Sequenz, um 5eztCap4M_Y zu erhalten (entfernen Sie das Base64-Auffüllen).

3. Hier ist ein Beispiel für einen Scrypt-Aufruf zur Erstellung des Inhaltsverschlüsselungsschlüssels (cek):

   cek=scrypt(password="ossifrage", salt=4-byte-sequence, N=32768, r=8, p=1, keylength=16)

   Der abgeleitete Schlüssel sollte 16 Byte (Hex) wie folgt lang sein: 95 9e ba 6d d1 22 01 05 78 fe 6a 9d 22 78 ff ac, was base64url für lz66bdeiaqv4_MQDINJ_RA kodiert.

4. Wählen Sie eine zufällige Folge von 12 Byte, die als Initialisierungsvektor verwendet werden soll. Dieses Beispiel verwendet (hex) 34 b3 5d dd 5f 53 7b af 2d 92 95 83, was base64url für nlnd3v9TE68tkpwd kodiert.

5. Erstellen Sie den JOSE-Header mit kompakter Serialisierung (folgen Sie der gleichen Reihenfolge der Parameter, die wir hier verwenden) und kodieren Sie ihn dann mit base64url:

   {"alg“ :"dir“, "cisco-action“ :"add“, "cisco-kdf“: {"salt“ :"5eztcap4m_Y“, "version“ :"1"}, "enc“ :"A128GCM "}

   Der Base64-URL-kodierte JOSE-Header ist EYJHBGCIOIJKAXIILCJJAXNJBY1HY3RPB24IOIJHZGQILCJJAXNJBY1RZGYIONSIC2FSDCI6IJVLWLRDQVA0TV9ZIIWIDMVYC2LVBII6IJEiFSWIZW5JIJOIQTEYOEDDTSJ9

   Dies wird das erste Element des JWE-Blobs sein.

6. Das zweite Element des JWE-Blobs ist leer, weil wir keinen JWE-Verschlüsselungsschlüssel angeben.

7. Das dritte Element des JWE-Blobs ist der Initialisierungsvektor NLND3V9TE68TKPWD.

8. Verwenden Sie Ihr JWE-Verschlüsselungstool, um eine verschlüsselte Nutzlast und ein Tag zu erstellen. Für dieses Beispiel wird die unverschlüsselte Nutzlast der gefälschte PEM-Blob sein, das ist eine PEM-Datei

   Die Verschlüsselungsparameter, die Sie verwenden sollten, sind:

   • Payload, ist das eine PEM-Datei?

   • Die Verschlüsselungschiffre ist AES 128 GCM

   • Der base64url-kodierte JOSE-Header als zusätzliche authentifizierte Daten (AAD)

   Base64URL kodieren die verschlüsselte Nutzlast, was zu F5llvuwnFKFMZYCO1YJFODHQ führen sollte

   Dies ist das vierte Element (JWE Ciphertext) im JWE-Blob.

9. Base64URL kodieren Sie das Tag, das Sie in Schritt 8 erzeugt haben, was zu pe-WDFWGXFFBEO928CFZ1Q führen sollte

   Das ist das fünfte Element im JWE-Blob.

10. Verketten Sie die fünf Elemente des JWE-Blobs mit Punkten (JoseHeader.. IV.CipherText.Tag), um zu erhalten:

    EYJHBGCIOIJKAXIILCJJAXNJBY1HY3RPB24IOIJHZGQILCJJAXNJBY1RZGYIONSIC2FSDCI6IJVLWLDQVA0TV9ZIIWIDMVYC2LVBII6IJEiFSWIZW5JIJOIQTEYOEDDTSJ.. 9NLND3V9TE68TKPWD.F ZYCO1YJFODHQ.PE-WDFWGXFFBEO928CFZ1Q

11. Wenn Sie dieselben Base64URL-kodierten Werte, wie wir sie hier zeigen, mit Ihren eigenen Tools abgeleitet haben, sind Sie bereit, sie zu verwenden, um die E2E-Verschlüsselung und die verifizierte Identität Ihrer Geräte zu sichern.

12. Dieses Beispiel wird eigentlich nicht funktionieren, aber im Prinzip wäre Ihr nächster Schritt, den JWE-Blob, den Sie oben erstellt haben, als Eingabe für den Befehl auf dem Gerät zu verwenden, das das Zertifikat hinzufügt:

    Befehlssicherheitszertifikate fügen Sie eyjhbgcioijkaxiilcjjaxnjby1hy3rpb24ioijhzgqilcjjaxnjby1rzgyionsic2fsdci6ijvlwlrdqva0tv9ziiwidmvyc2lvbii6ijeifswizw5jijoiqteyoeddtsj. 9NLND3V9TE68TKPWD.F5llvuwnfkfmzyco1yjfodhq.pe-wdfwgxffbeo928cfz1q