Jak využíváme formát JWE

V této části je popsáno, jak očekáváme vytvoření souboru JWE jako vstupu pro zařízení, abyste si mohli sestavit vlastní nástroj k vytváření objektů BLOB z vašich certifikátů a klíčů.

Viz Šifrování JSON Web Encryption (JWE)https://datatracker.ietf.org/doc/html/rfc7516a Web podpis JSON (JWS)https://datatracker.ietf.org/doc/html/rfc7515.

Používáme Kompaktní serializace dokumentu JSON k vytváření objektů BLOB JWE. Při vytváření objektů BLOB JWE musíte zahrnout tyto parametry:

• Záhlaví JOSE (chráněno). Do hlavičky Podepisování a šifrování objektů JSON MUSÍTE zahrnout následující páry klíč–hodnota:

  • "alg":"dir"

    Tento přímý algoritmus je jediný, který podporujeme k šifrování datové části a je nutné použít počáteční tajný klíč klienta zařízení.

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

    Podporujeme tyto dva šifrovací algoritmy.

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

    Toto je patentovaný klíč, který může nabývat čtyř hodnot. Tento klíč jsme zavedli, abychom cílovému zařízení signalizovali účel šifrovaných dat. Hodnoty jsou pojmenovány podle příkazů xAPI na zařízení, ve kterém používáte zašifrovaná data.

    Pojmenovali jsme to cisco-action ke zmírnění potenciálních konfliktů s budoucími rozšířeními JWE.

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

    Další proprietární klíč. Zadané hodnoty používáme jako vstupy pro odvození klíče na zařízení. Soubor version musí být 1(verze naší funkce pro odvození klíče). Hodnota salt musí být posloupnost kódování URL ve formátu Base64 o délce nejméně 4 bajtů, kterou proveďte moštu vybrat náhodně.

• Šifrovaný klíč JWE . Toto pole je prázdné. Zařízení jej odvodí z iniciály ClientSecret.

• Inicializační vektor JWE . K dešifrování datové části je nutné zadat inicializační vektor kódování base64url. Událost IV MUSÍTE být náhodná hodnota o délce 12 bajtů (používáme skupinu šifer AES-GCM, která vyžaduje, aby byl kód IV dlouhý 12 bajtů).

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

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

  Užitná zátěž MŮŽE být prázdná. Chcete-li například resetovat tajný klíč klienta, musíte jej přepsat prázdnou hodnotou.

  Existují různé typy užitečné zátěže v závislosti na tom, co se na zařízení snažíte dělat. Různé příkazy xAPI očekávají různou datovou zátěž a vy je nutné zadat účel datové zátěže pomocí příkazu cisco-action klíče, a to takto:

  • S "cisco-action":"populate" šifrovaný text je nový ClientSecret.

  • S „ "cisco-action":"add" šifrovaný text je objekt blob PEM obsahující certifikát a jeho soukromý klíč (zřetězený).

  • S „ "cisco-action":"activate" šifrovaný text je otisk (šestnáctkové znázornění sha-1) certifikátu, který aktivujeme pro ověření identity zařízení.

  • S „ "cisco-action":"deactivate" šifrovaný text je otiskem prstu (šestnáctkové znázornění sha-1) certifikátu, u kterého deaktivujeme použití k ověření identity zařízení.

• Ověřovací značka JWE: Toto pole obsahuje ověřovací značku, která slouží k ověření integrity celého kompaktu serializovaného objektu BLOB JWE

Jak odvozujeme šifrovací klíč z ClientSecret

Po prvním naplnění tajného klíče nepřijímáme ani nevydáváme výstup jako prostý text. Toto má zabránit potenciálním slovníkovým útokům ze strany osoby, která by mohla mít přístup k zařízení.

Software zařízení použije tajný klíč klienta jako vstup pro funkci odvození klíče (kdf) a získaný klíč pak použije pro dešifrování/šifrování obsahu v zařízení.

Pro vás to znamená, že váš nástroj k vytváření objektů BLOB JWE musí používat stejný postup k odvození stejného šifrovacího/dešifrovacího klíče z tajného klíče klienta.

Zařízení používají šifrovat pro odvození klíče (vizhttps://en.wikipedia.org/wiki/Scrypt ) s následujícími parametry:

• Nákladový faktor (N) je 32768

• BlockSizeFactor (r) je 8

• ParallelizationFactor (p) je 1

• Sůl je náhodná posloupnost o délce nejméně 4 bajtů; totéž musíte zadat salt při zadávání cisco-kdf parametr.

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

• Maximální omezení paměti je 64 MB

Tato sada parametrů je jedinou konfigurací šifrovat která je kompatibilní s funkcí odvozování klíče na zařízeních. Tento kdf na zařízeních se nazývá "version":"1", což je jediná verze, kterou v současné době používá portál cisco-kdf parametr.

Fungující příklad

Zde je příklad, podle kterého si můžete ověřit, že proces šifrování JWE funguje stejně jako proces, který jsme v daných zařízeních vytvořili.

V ukázkovém scénáři je přidání objektu BLOB PEM na zařízení (napodobuje přidání certifikátu s velmi krátkým řetězcem místo úplného cert + klíče). Tajné heslo klienta v příkladu je ossifrage.

1. Zvolte šifrovací šifru. Tento příklad používá A128GCM(AES se 128bitovými klíči v režimu počitadla Galois). Váš nástroj by se mohl hodit A256GCM chcete-li.

2. Vyberte sůl (musí se jednat o náhodnou posloupnost nejméně 4 bajtů). V tomto příkladu je použita hodnota ( šestnáctkové bajty ) E5 E6 53 08 03 F8 33 F6. Base64url zakóduje sekvenci, kterou chcete získat 5eZTCAP4M_Y(odeberte polstrování base64).

3. Zde je ukázka scrypt volání vytvoření šifrovací klíč obsahu (cek):

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

   Odvozený klíč by měl mít 16 bajtů (šestnáctkových) a to následujícím způsobem: 95 9e ba 6d d1 22 01 05 78 fe 6a 9d 22 78 ff ac do kterého se kóduje base64url lZ66bdEiAQV4_mqdInj_rA.

4. Vyberte náhodnou posloupnost 12 bajtů, kterou chcete použít jako inicializační vektor. V tomto příkladu je použita hodnota (šestnáctková) 34 b3 5d dd 5f 53 7b af 2d 92 95 83 do kterého se kóduje base64url NLNd3V9Te68tkpWD.

5. Vytvořte hlavičku JOSE s kompaktní serializací (následujte stejné pořadí parametrů, jaké používáme zde) a pak ji zakódujte na base64url:

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

   V hlavičce JOSE je kódování base64url eyJhbGciOiJkaXIiLCJjaXNjby1hY3Rpb24iOiJhZGQiLCJjaXNjby1rZGYiOnsic2FsdCI6IjVlWlRDQVA0TV9ZIiwidmVyc2lvbiI6IjEifSwiZW5jIjoiQTEyOEdDTSJ9

   Toto bude první prvek objektu blob JWE.

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

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

8. K vytvoření zašifrované datové části a značky použijte svůj šifrovací nástroj JWE. V tomto příkladu bude nešifrovanou datovou částí falešný objekt blob PEM this is a PEM file

   Měli byste použít tyto parametry šifrování:

   • Užitečná zátěž je this is a PEM file

   • Šifrování je AES 128 GCM

   • Záhlaví JOSE s kódováním base64url jako dodatečná ověřená data (AAD)

   Base64url zakóduje zašifrovanou datovou část, což by mělo vést k f5lLVuWNfKfmzYCo1YJfODhQ

   Toto je čtvrtý prvek (JWE Šifrovaný text) v objektu BLOB JWE.

9. Base64url zakó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 objektu blob JWE.

10. Zřetězením pěti prvků objektu blob JWE s tečkami (JOSEheader..IV.Ciphertext.Tag), získáte:

    eyJhbGciOiJkaXIiLCJjaXNjby1hY3Rpb24iOiJhZGQiLCJjaXNjby1rZGYiOnsic2FsdCI6IjVlWlRDQVA0TV9ZIiwidmVyc2lvbiI6IjEifSwiZW5jIjoiQTEyOEdDTSJ..9NLNd3V9Te68tkpWD.f5lLVuWNfKfmzYCo1YJfODhQ.PE-wDFWGXFFBeo928cfZ1Q

11. Pokud jste odvodili stejné hodnoty v kódování base64url, jaké znázorňujeme zde, za použití vlastních nástrojů, jste připraveni je použít k zabezpečení šifrování E2E a ověřené identity svých zařízení.

12. Tento příklad nebude ve skutečnosti fungovat, ale v zásadě by bylo vaším dalším krokem použití výše vytvořeného objektu BLOB JWE jako vstupu pro příkaz xcommand na zařízení, které přidává certifikát:

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