Tak for din feedback.

Sådan bruger vi JWE-formatet

Dette afsnit beskriver, hvordan vi forventer, at JWE oprettes som input til enhederne, så du kan opbygge dit eget værktøj til at oprette blobs fra dine certifikater og nøgler.

Se J SON-webkryptering (JWE) https://datatracker.ietf.org/doc/html/rfc7516 og JSON Web Signature (JWS) https://datatracker.ietf.org/doc/html/rfc7515.

Vi bruger den kompakte serialisering af et JSON-dokument til at oprette JWE-blobs. De parametre, du skal medtage, når du opretter JWE-blobs, er:

• JOSE Overskrift (beskyttet). I overskriften JSON-objektsignering og kryptering SKAL du medtage følgende nøgle-værdipar:

  • „alg“ :"dir“

    Den direkte algoritme er den eneste, vi understøtter til kryptering af nyttelasten, og du skal bruge enhedens oprindelige klienthemmelighed.

  • „enc“: „A128GCM“ eller „enc“: „A256GCM“

    Vi understøtter disse to krypteringsalgoritmer.

  • „cisco-action“: „tilføj“ eller „cisco-handling“: „populate“ eller „cisco-action“: „aktiver“ eller „cisco-action“: „deaktiver“

    Dette er en proprietær nøgle og fire værdier, den kan tage. Vi introducerede denne nøgle for at signalere formålet med de krypterede data til målenheden. Værdierne er opkaldt efter xAPI-kommandoerne på den enhed, hvor du bruger de krypterede data.

    Vi kaldte det cisco-action for at afbøde potentielle sammenstød med fremtidige JWE-udvidelser.

  • „cisco-kdf“: {„version“: „1", „salt“: „base64URLEncodeDrandom4+bytes“}

    En anden proprietær nøgle. Vi bruger de værdier, du angiver, som input til nøgleafledning på enheden. Versionen skal være 1 (versionen af vores nøgleafledningsfunktion). Værdien af salt skal være en base64 URL-kodet sekvens på mindst 4 bytes, som du skal vælge tilfældigt.

• JWE krypteret nøgle. Dette felt er tomt. Enheden henter den fra den oprindelige ClientSecret.

• JWE Initialiseringsvektor. Du skal angive en base64url-kodet initialiseringsvektor til dekryptering af nyttelasten. IV'en SKAL være en tilfældig 12 byte værdi (vi bruger AES-GCM-chifferfamilien, som kræver, at IV er 12 bytes lang).

• JWE AAD (yderligere godkendte data). Du skal udelade dette felt, fordi det ikke understøttes i Compact Serialization.

• JWE Ciphertext: Dette er den krypterede nyttelast, som du vil holde hemmelig.

  Nyttelasten KAN være tom. For at nulstille klientens hemmelighed skal du for eksempel overskrive den med en tom værdi.

  Der er forskellige typer nyttelast, afhængigt af hvad du prøver at gøre på enheden. Forskellige xAPI-kommandoer forventer forskellige nyttelaster, og du skal angive formålet med nyttelasten med cisco-action-nøglen som følger:

  • Med „cisco-action“ :"populate“ er chifferteksten den nye ClientSecret.

  • Med "„cisco-action“ :"add“ er chifferteksten en PEM-blob, der bærer certifikatet og dets private nøgle (sammenkædet).

  • Med "„cisco-action“ :"activate“ er chifferteksten fingeraftrykket (hexadecimal repræsentation af sha-1) af det certifikat, vi aktiverer til verifikation af enhedens identitet.

  • Med "„cisco-action“ :"deaktiver“ er chifferteksten fingeraftrykket (hexadecimal repræsentation af sha-1) af det certifikat, vi deaktiverer, fra at blive brugt til enhedsidentitetsbekræftelse.

• JWE-godkendelsestag: Dette felt indeholder godkendelsesmærket for at fastslå integriteten af hele JWE-kompakt serialiserede blob

Hvordan vi udleder krypteringsnøglen fra ClientSecret

Efter den første population af hemmeligheden accepterer eller udsender vi ikke hemmeligheden som almindelig tekst. Dette er for at forhindre potentielle ordbogsangreb fra en person, der kunne få adgang til enheden.

Enhedssoftwaren bruger klientens hemmelighed som input til en nøgleafledningsfunktion (kdf) og bruger derefter den afledte nøgle til dekryptering/kryptering af indhold på enheden.

Hvad dette betyder for dig er, at dit værktøj til at producere JWE-blobs skal følge den samme procedure for at udlede den samme krypterings-/dekrypteringsnøgle fra klientens hemmelighed.

Enhederne bruger scrypt til nøgleafledning (se https://en.wikipedia.org/wiki/Scrypt) med følgende parametre:

• CostFactor (N) er 32768

• BlockSizeFactor (r) er 8

• ParallelizationFactor (p) er 1

• Salt er en tilfældig sekvens på mindst 4 bytes; du skal levere det samme salt, når du angiver cisco-kd f-parameteren.

• Nøglelængder er enten 16 bytes (hvis du vælger AES-GCM 128-algoritmen) eller 32 bytes (hvis du vælger AES-GCM 256-algoritmen)

• Maks. Hukommelseshætte er 64 MB

Dette sæt parametre er den eneste konfiguration af scrypt, der er kompatibel med nøgleafledningsfunktionen på enhederne. Denne kdf på enhederne kaldes „version“: „1", som er den eneste version, der i øjeblikket er taget af cisco-kdf-parameteren.

Arbejdet eksempel

Her er et eksempel, som du kan følge for at kontrollere, at din JWE-krypteringsproces fungerer på samme måde som den proces, vi oprettede på enhederne.

Eksempelscenariet er at tilføje en PEM-blob til enheden (efterligner tilføjelse af et certifikat med en meget kort streng i stedet for en fuld cert + nøgle). Klienthemmeligheden i eksemplet er ossifrage.

1. Vælg en krypteringskryptering. Dette eksempel bruger A128GCM (AES med 128-bit nøgler i Galois-tællertilstand). Dit værktøj kan bruge A256GCM, hvis du foretrækker det.

2. Vælg et salt (skal være en tilfældig sekvens på mindst 4 bytes). Dette eksempel bruger (hex bytes) E5 E6 53 08 03 F8 33 F 6. Base64URL koder sekvensen for at få 5eztcap4 m_y (fjern base64-polstring).

3. Her er et eksempel på et scrypt-opkald for at oprette indholdskrypteringsnøglen (cek):

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

   Den afledte nøgle skal være 16 bytes (hex) som følger: 95 9e ba 6d d1 22 01 05 78 fe 6a 9d 22 78 ff ac, som base64url koder til LZ66BDeiaqv4_mqdinj_ra.

4. Vælg en tilfældig sekvens på 12 bytes, der skal bruges som en initialiseringsvektor. Dette eksempel bruger (hex) 34 b3 5d dd 5f 53 7b af 2d 92 95 83 som base64url koder til nLnd3v9te68tkpwd.

5. Opret JOSE-headeren med kompakt serialisering (følg den samme rækkefølge af parametre, vi bruger her), og koder derefter base64url det:

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

   Den base64url-kodede JOSE-header er EyjhbGcioIJkAxiiLcJjaXnJBY1hy3rpb24ioiJhzgqILcJjaXnjby1rzGyionSiC2fsdCi6ijvLwLrdqVA0tV9ziiWIDmVyc2LvBii6iJEifsWiZw5jiJoiqTEyoeddTSj9

   Dette vil være det første element i JWE-blob.

6. Det andet element i JWE-blob er tomt, fordi vi ikke leverer en JWE-krypteringsnøgle.

7. Det tredje element i JWE-blob er initialiseringsvektoren NlnD3v9TE68tkpwd.

8. Brug dit JWE-krypteringsværktøj til at producere en krypteret nyttelast og tag. I dette eksempel vil den ukrypterede nyttelast være den falske PEM-blob, dette er en PEM-fil

   De krypteringsparametre, du skal bruge, er:

   • Nyttelast er dette er en PEM-fil

   • Krypteringskryptering er AES 128 GCM

   • Den base64url-kodede JOSE-header som yderligere godkendte data (AAD)

   Base64URL koder den krypterede nyttelast, hvilket skulle resultere i F5llVUWNfkfmzyco1yjFODHQ

   Dette er det fjerde element (JWE Ciphertext) i JWE-blob.

9. Base64URL koder det tag, du producerede i trin 8, hvilket skulle resultere i PE-wdfwgxffbeo928cfz1q

   Dette er det femte element i JWE-blob.

10. Sammenkæd de fem elementer i JWE-blob med prikker (JoseHeader.. iv.CipherText.tag) for at få:

    EYJhbgCIoIJkAXiiLCJaxnjbY1hy3rpb24ioiJhzgQiLcJjaXnJbY1RzgyiOnSiC2fsdCi6iVLrdQVA0tV9ZiiWiDMvYc2LvBiI6iJeiFsWiZw5jiJoiqTeyOeddTSj.. 9nLnd3v9TE68pWlLd.f5tKf5tKlLf9nLnd3v9tE68pWf5lLf5JiJoIQtEYoEDDtSj.. VUWNfkfmzyco1yjfodhq.pe-wdfwgxffbeo928cfz1q

11. Hvis du udledte de samme base64url-kodede værdier, som vi viser her, ved hjælp af dine egne værktøjer, er du klar til at bruge dem til at sikre E2E-kryptering og verificeret identitet på dine enheder.

12. Dette eksempel fungerer faktisk ikke, men i princippet ville dit næste trin være at bruge JWE-blob, du oprettede ovenfor, som input til xcommand på den enhed, der tilføjer certifikatet:

    XCommand-sikkerhedscertifikater Tilføj eyJhbgCIoIJkAxiiLcJjaXnjbY1hy3rpb24ioiJhzgQiLCJjaXnjby1rzGyIONSiC2fsdci6ijVLWLrdqVA0tV9ziiWIDmVyC2LvBiI6iJiIFsWiZw5jiJoiqTeyOeDdDtSj.. 9nLnND3v9Tk68TkJ.. PWD.F5LLVUWNfkfmzyco1yjfodhq.pe-wdfwg xffbeo928cfz1q