Jak používáme formát JWE

Tato část popisuje, jak očekáváme, že JWE bude vytvořen jako vstup do zařízení, abyste si mohli vytvořit vlastní nástroj pro vytváření bloků z vašich certifikátů a klíčů.

Viz téma Šifrování webu JSON (JWE) https://datatracker.ietf.org/doc/html/rfc7516 a Podpis webu JSON (JWS) https://datatracker.ietf.org/doc/html/rfc7515.

K vytvoření blobů JWE používáme kompaktní serializaci dokumentu JSON. Parametry, které musíte zahrnout při vytváření bloků JWE, jsou:

• Záhlaví JOSE (chráněno). V záhlaví Podepisování a šifrování objektu JSON MUSÍTE zahrnout následující páry klíčových hodnot:

  • "alg":"dir"

    Přímý algoritmus je jediný, který podporujeme pro šifrování datové části. Musíte použít počáteční tajný klíč klienta zařízení.

  • "enc":"A128GCM" nebo "enc":"A256GCM"

    Tyto dva šifrovací algoritmy podporujeme.

  • "cisco-action": "add" nebo "cisco-action": "populate""cisco-action": "activate" nebo "cisco-action": "deactivate"

    Jedná se o proprietární klíč a čtyři hodnoty, které může mít. Tento klíč jsme zavedli pro signalizaci účelu zašifrovaných dat cílovému zařízení. Hodnoty se jmenují podle příkazů xAPI v zařízení, ve kterém používáte zašifrovaná data.

    Název platformy jsme pojmenovali cisco-action kvůli zmírnění potenciálních střetů s budoucími linkami JWE.

  • "cisco-kdf": { "version": "1", "salt": "base64URLEncodedRandom4+Bytes" }

    Další proprietární klíč. Hodnoty, které zadáte, používáme na zařízení jako vstupy pro derivaci klíčů. version musí být 1 (verze naší klíčové funkce derivace). Hodnota salt musí být posloupnost kódovaná pomocí URL base64 o velikosti nejméně 4 bajtů, kterou musíte vybrat náhodně.

• Šifrovaný klíč JWE. Toto pole je prázdné. Zařízení je odvozuje od počátečního prvku ClientSecret.

• Vektor inicializace JWE. Pro dešifrování užitečného zatížení musíte zadat vektor inicializace kódovaný v base64url. IV MUSÍ být náhodná hodnota 12 bajtů (používáme rodinu šifrování AES-GCM, která vyžaduje, aby iv byla 12 bajtů dlouhá).

• JWE AAD (další ověřená data). Toto pole je nutno vynechat, protože není podporováno v kompaktní serializaci.

• Šifrovací text JWE: Toto je zašifrovaná datová část, kterou chcete zachovat v tajnosti.

  Datová část MŮŽE být prázdná. Pokud chcete například obnovit tajný klíč klienta, musíte ho přepsat prázdnou hodnotou.

  Existují různé typy zatížení v závislosti na tom, co se pokoušíte na zařízení dělat. Různé příkazy xAPI očekávají různé datové části a je nutné určit účel datové části s klíčem cisco-action následovně:

  • S "cisco-action":"populate" šifrovacím textem je nový ClientSecret.

  • S ""cisco-action":"add" šifrovací text je PEM blob nesoucí certifikát a jeho soukromý klíč (propojený).

  • "Cifertext "cisco-action":"activate" je otisk prstu (hexadecimální reprezentace sha-1) certifikátu, který aktivujeme pro ověření identity zařízení.

  • ""cisco-action":"deactivate" Šifrovací text je otisk prstu (hexadecimální reprezentaci sha-1) certifikátu, který deaktivujeme z použití k ověření identity zařízení.

• Značka ověření JWE: Toto pole obsahuje ověřovací značku ke zjištění integrity celého kompaktně serializovaného blobu JWE

Jak odvozujeme šifrovací klíč od ClientSecret

Po první populaci tajemství nepřijímáme ani nevydáváme tajemství jako prostý text. To je proto, aby se zabránilo potenciálním útokům ze slovníku uživatelem, který by měl k zařízení přístup.

Software zařízení používá klientský tajný klíč jako vstup do funkce derivace klíče (kdf) a poté používá odvozený klíč pro dešifrování/šifrování obsahu zařízení.

To pro vás znamená, že váš nástroj pro tvorbu JWE blobs musí dodržovat stejný postup, aby odvodil stejný šifrovací/dešifrovací klíč z tajného klienta.

Zařízení používají scrypt pro derivaci klíče (viz https://en.wikipedia.org/wiki/Scrypt) s následujícími parametry:

• CostFactor (N) je 32768

• BlockSizeFactor (r) je 8

• ParallelizačníFaktor (p) je 1

• Salt je náhodná posloupnost o velikosti nejméně 4 bajtů. Totéž musíte zadat salt při zadávání cisco-kdf parametru.

• Délka klíče je buď 16 bajtů (pokud vyberete algoritmus AES-GCM 128), nebo 32 bajtů (pokud vyberete algoritmus AES-GCM 256).

• Maximální limit paměti je 64 MB.

Tato sada parametrů je jedinou konfigurací scrypt , která je kompatibilní s funkcí derivace klíče na zařízeních. Tento kdf se na zařízeních nazývá "version":"1", což je jediná verze, která je aktuálně používána parametrem cisco-kdf .

Zpracovaný příklad

Zde je příklad, který můžete použít k ověření, že váš proces šifrování JWE funguje stejně jako proces, který jsme vytvořili na zařízeních.

Příkladem je přidání blob PEM do zařízení (napodobuje přidání certifikátu s velmi krátkým řetězcem namísto úplného certifikátu + klíče). Tajný kód klienta v tomto příkladu je ossifrage.

1. Zvolte šifrování. Tento příklad používá A128GCM (AES s 128bitovými klíči v režimu čítače Galois). Pokud chcete, A256GCM můžete použít nástroj.

2. Zvolte salt (musí být náhodná posloupnost nejméně 4 bajtů). Tento příklad používá (hexadecimální bajty)E5 E6 53 08 03 F8 33 F6. Base64url zakóduje sekvenci pro získání 5eZTCAP4M_Y (odebrání base64 padding).

3. Zde je ukázkový hovor scrypt pro vytvoření šifrovacího klíče obsahu (cek):

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

   Odvozený klíč musí být 16 bajtů (šestnáctkové) takto:95 9e ba 6d d1 22 01 05 78 fe 6a 9d 22 78 ff ac se kterým base64url se kóduje na lZ66bdEiAQV4_mqdInj_rA.

4. Zvolte náhodnou posloupnost 12 bajtů, kterou chcete použít jako vektor inicializace. V tomto příkladu se používá hexadecimální kód 34 b3 5d dd 5f 53 7b af 2d 92 95 83 base64url na NLNd3V9Te68tkpWD.

5. Vytvořte hlavičku JOSE s kompaktní serializací (postupujte podle stejného pořadí parametrů, které používáme zde) a poté ji base64url zakódujte:

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

   Hlavička kódovaná v base64url JOSE je eyJhbGciOiJkaXIiLCJjaXNjby1hY3Rpb24iOiJhZGQiLCJjaXNjby1rZGYiOnsic2FsdCI6IjVlWlRDQVA0TV9ZIiwidmVyc2lvbiI6IjEifSwiZW5jIjoiQTEyOEdDTSJ9

   To bude první prvek JWE blob.

6. Druhý prvek blob JWE je prázdný, protože nedodáváme šifrovací klíč JWE.

7. Třetím prvkem blobu JWE je inicializační vektor NLNd3V9Te68tkpWD.

8. K vytvoření šifrovaného nákladu a značky použijte váš nástroj pro šifrování JWE. Například nešifrované datové zatížení bude falešné blob PEM this is a PEM file

   Používejte tyto parametry šifrování:

   • Datová část je this is a PEM file

   • Šifrování má AES 128 GCM

   • Hlavička base64url kódovaná JOSE jako další ověřená data (AAD)

   Base64url zakóduje zašifrované datové zatížení, což by mělo mít za následek f5lLVuWNfKfmzYCo1YJfODhQ

   Toto je čtvrtý prvek (JWE Ciphertext) v JWE blob.

9. Base64url kóduje značku, kterou jste vytvořili v kroku 8, což by mělo vést k PE-wDFWGXFFBeo928cfZ1Q

   Toto je pátý prvek v JWE blob.

10. Spojte pět prvků blobu JWE s tečky (JOSEheader..IV.Ciphertext.Tag), abyste získali:

    eyJhbGciOiJkaXIiLCJjaXNjby1hY3Rpb24iOiJhZGQiLCJjaXNjby1rZGYiOnsic2FsdCI6IjVlWlRDQVA0TV9ZIiwidmVyc2lvbiI6IjEifSwiZW5jIjoiQTEyOEdDTSJ..9NLNd3V9Te68tkpWD.f5lLVuWNfKfmzYCo1YJfODhQ.PE-wDFWGXFFBeo928cfZ1Q

11. Pokud jste odvodili stejné hodnoty kódované base64url jako zde, pomocí vlastních nástrojů jste připraveni použít je k zabezpečení šifrování E2E a ověřené identity vašich zařízení.

12. Tento příklad ve skutečnosti nebude fungovat, ale v zásadě vaším dalším krokem je použít JWE blob, který jste vytvořili výše jako vstup do xcommand v zařízení, které přidává certifikát:

    xCommand Security Certificates Add eyJhbGciOiJkaXIiLCJjaXNjby1hY3Rpb24iOiJhZGQiLCJjaXNjby1rZGYiOnsic2FsdCI6IjVlWlRDQVA0TV9ZIiwidmVyc2lvbiI6IjEifSwiZW5jIjoiQTEyOEdDTSJ..9NLNd3V9Te68tkpWD.f5lLVuWNfKfmzYCo1YJfODhQ.PE-wDFWGXFFBeo928cfZ1Q