JSON-nettkryptering: Hvordan fungerer det, hvorfor er det viktig og når bør det brukes

Dette er en introduksjon til JSON Web Encryption: en standard som er utviklet for å holde dataene konfidensielle.

Hvis begreper som "JSON Web Token" og "JSON Web Signature" er nye for deg, kan du begynne med våre andre artikler:

• JWT-krav i OpenID Connect
• Forstå JWT-validering

Ellers er det bare å sette i gang!

Hva er JWE?

JSON Web Encryption (JWE) er en IETF-standard for å representere kryptert innhold i JSON-format. Den er en del av et bredere JOSE-rammeverk (JSON Object Signing and Encryption), som også omfatter JSON Web Token (JWT) og JSON Web Signature (JWS).

JWE beskytter informasjon og sikrer konfidensialitet. Kryptografien bak JWE gjør at bare autoriserte parter med riktig dekrypteringsnøkkel kan lese de krypterte dataene.

Alle typer innhold, inkludert en enkel setning, kan krypteres ved hjelp av JWE. Den vanligste anvendelsen er imidlertid kryptering av en JWT. Når en JWT både er signert (med JWS) og kryptert (med JWE), kalles den ofte en "nested" JWT. Nestede JWT-er kan brukes i autentiseringsscenarier med OAuth 2.0 og OpenID Connect, når det kreves et ekstra beskyttelseslag for sensitive data.

I dette blogginnlegget fokuserer vi på det vanligste bruksområdet: Nested JWT. Vi tar også kun for oss Compact Serialization-formatet, i motsetning til det mindre populære JSON Serialization.

Hvorfor bruke JWE?

Datasikkerhet er en stor utfordring for moderne applikasjoner, spesielt når man håndterer og overfører sensitiv informasjon som finansielle opplysninger, personopplysninger eller påloggingsinformasjon over Internett. JWE er uvurderlig når det gjelder å

• Sikre konfidensialitet av data: JWE holder sensitive data konfidensielle. Selv om en JWE-sikret melding blir snappet opp, forblir innholdet uleselig uten den riktige dekrypteringsnøkkelen.
  
  
• Overholdelse av forskrifter: Bransjer som helsevesenet og finanssektoren er underlagt strenge regler som krever at de beskytter kundedata ved hjelp av kryptering. JWE hjelper organisasjoner med å overholde disse kravene.

Vanlige bruksområder for JWE

JWE har flere praktiske bruksområder.

1. Sikring av API-er: API-er håndterer ofte utveksling av sensitive data mellom klienter og servere. Ved å bruke JWE til å kryptere API-forespørsler og -svar holdes denne informasjonsflyten privat. En autorisasjonsserver kan for eksempel bruke JWE til å kryptere token- og brukerinfo-svar, noe som gir et ekstra sikkerhetslag til OAuth 2.0-baserte autentiseringsflyter.
   
   
2. Beskyttelse av data under overføring: JWE er spesielt nyttig ved overføring av data over potensielt usikre nettverk.
   
   
3. Lagring av krypterte data i databaser: For applikasjoner som lagrer JWT-er i databaser for autentisering eller sesjonsadministrasjon, kan kryptering av disse tokens med JWE forhindre at sensitiv informasjon blir eksponert i tilfelle et databaseinnbrudd.

Forskjellen mellom JWT, JWS og JWE

JSON Web Tokens er en standardisert måte å overføre informasjon på. JWT-er bruker to beslektede spesifikasjoner:

• JSON Web Signature (JWS) for dataintegritet og autentisitet
• JSON Web Encryption (JWE) for konfidensialitet.

La oss ta en nærmere titt på hver av dem:

JSON Web Token (JWT)

En JWT er en kompakt, URL-sikker metode for å representere krav som skal overføres mellom to parter. Det er en utbredt standard for autentisering og autorisasjon, som ofte formidler detaljer om en autentisert bruker (som i OpenID Connect) eller tillatelsene som er gitt til klientapplikasjonen (som i OAuth 2.0).

EN JWT:

• Er bredt definert i RFC 7519 som en måte å representere krav som skal overføres mellom to parter. Den kan signeres (ved hjelp av JWS) eller krypteres (ved hjelp av JWE), eller til og med være usikret ("alg":"none").
• I praksis og for alle sikre brukstilfeller er en JWT praktisk talt alltid kryptografisk signert ved hjelp av JSON Web Signature (JWS). Signaturen sikrer integriteten og autentisiteten til dataene i JWT-en.
• En signert JWT består av tre deler: et hode, en nyttelast (påstandene) og en signatur.
• En signert JWT garanterer at dataene den inneholder, ikke har blitt tuklet med, men den sikrer ikke konfidensialitet - alle som har tokenet, kan lese innholdet.

JSON Web Signature (JWS)

JWS er en spesifikasjon for digital signering av JSON-data, som:

• Garanterer dataintegritet og autentisitet, og sikrer at de signerte dataene ikke har blitt tuklet med under transport. Mottakeren kan verifisere at dataene ikke har blitt endret ved å validere signaturen.
• Gjør dataene synlige, men manipulasjonssikre.
• Dette er standardmekanismen for signering av JWT-er.

JSON Web Encryption (JWE)

JWE er en spesifikasjon for å representere en kryptert og integritetsbeskyttet melding.

JWE:

• Krypterer dataene for å sikre konfidensialitet.
• Bygger på en klasse kryptografiske algoritmer som kalles AEAD (Authenticated Encryption with Associated Data). Disse algoritmene både krypterer dataene og sørger for en integritetskontroll.
• Brukes ofte til å kryptere JWT-er for autentisering og autorisasjon i sensitive miljøer (f.eks. finans- eller helsesektoren). De signerte og krypterte JWT-ene kalles nestede JWT-er.
• Nested JWT-er er vanlige, men JWE gjør det mulig å kryptere en vilkårlig verdi. Klarteksten som krypteres av JWE, trenger ikke å være en fullstendig, formelt strukturert JWT. Det kan ganske enkelt være et JSON-objekt som inneholder påstander (f.eks. {"user_id": "123", "role": "admin"}) kryptert direkte, uten JWT-hodet og signaturen.
• Består av fem deler: overskrift, kryptert nøkkel, initialiseringsvektor, chiffertekst og autentiseringsmerke.

Strukturen til en JWE

En faktisk JWE kan se omtrent slik ut:

eyJhbGciOiJSU0EtT0FFUCIsImVuYyI6IkEyNTZHQ00ifQ.
eyJpc3MiOiJqb2UiLCJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyLCJleHAiOjE1MTYyNDA5MjIsImF1ZCI6WyJodHRwOi8vbG9jYWxob3N0OjUwMDAiXSwianRpIjoiMTIzNDU2Nzg5MCJ9.
cZVhpnL47MivTYV7GfhHduRzUhHsxMSAwdpP4I4aFnk.
48V1_ALb6US04U3b.
5eym8TW_c8SuKKS-fv54EyXp10aJpE8rvCvIkDx9dXw

(Merk: Den faktiske JWE-en er en sammenhengende streng; nye linjer er bare lagt til for lesbarhetens skyld).

Dette eksemplet krypterer klarteksten "Det sanne tegnet på intelligens er ikke kunnskap, men fantasi." til mottakeren. Legg merke til at den består av fem deler, hver av dem base64url-kodet og atskilt med prikker. Hver del av en JWE spiller en spesifikk rolle i krypterings- og dekrypteringsprosessen.

Dette er et eksempel på en JWE Compact Serialization, som er det vanligste formatet for JWE. Et annet alternativ, som vi ikke kommer til å dekke i dette blogginnlegget, er en JWE JSON-serialisering.

De fem delene av en JWE er

JOSE Header

JOSE Header inneholder informasjon om krypteringsprosessen og selve JWE-en. Den spesifiserer algoritmene som brukes til både nøkkeladministrasjon og innholdskryptering, sammen med valgfrie tilleggsegenskaper. Den må inneholde følgende parametere:

• alg (Algorithm): spesifiserer nøkkelhåndteringsalgoritmen som brukes til å kryptere eller bestemme verdien av innholdskrypteringsnøkkelen (CEK). Vanlige algoritmer inkluderer RSA1_5, RSA-OAEP, A128KW, A256KW, osv.
  
  
• enc (Encryption Algorithm): spesifiserer AEAD-algoritmen (Authenticated Encryption with Associated Data) som brukes til å utføre den faktiske krypteringen av klarteksten. Denne algoritmen må ha en spesifisert nøkkellengde og gir i seg selv både kryptering og integritetsbeskyttelse. Eksempler inkluderer A128GCM, A256GCM (AES GCM), A128CBC-HS256 osv.
  

Valgfrie hodeparametere, som x5u (X.509 URL), kid (nøkkel-ID), cty (innholdstype) osv. kan inkluderes.

Et typisk JWE-header kan se slik ut:

{
  "alg": "RSA-OAEP",
  "enc": "A256GCM"
}

Dette overskriften spesifiserer at innholdskrypteringsnøkkelen krypteres til mottakeren ved hjelp av RSA-OAEP-algoritmen, og at godkjent kryptering utføres på klarteksten ved hjelp av AES GCM med en 256-biters nøkkel.

Kryptert nøkkel

Denne delen inneholder innholdskrypteringsnøkkelen (Content Encryption Key, CEK), , som er den symmetriske nøkkelen som brukes til å kryptere det faktiske innholdet i JWE. Alg-parameteren i JOSE-headeren angir hvordan denne CEK krypteres eller avtales.

Her er noen eksempler på hvordan CEK håndteres basert på alg-verdien:

• Hvis alg er RSA-OAEP, krypteres innholdskrypteringsnøkkelen ved hjelp av RSA-OAEP-algoritmen med mottakerens offentlige nøkkel.
• Hvis alg er A128KW eller A256KW (AES Key Wrap), blir CEK symmetrisk innpakket (kryptert) ved hjelp av en forhåndsdelt symmetrisk nøkkel.
• For algoritmer som ECDH-ES (Elliptic-curve Diffie-Hellman) utledes en delt hemmelighet ved hjelp av en nøkkelavtale. Denne avledede hemmeligheten brukes vanligvis til å pakke inn CEK (ECDH-ES kombineres ofte med A128KW), men den kan også brukes direkte som CEK.

Når CEK ikke overføres i JWE, for eksempel ved direkte kryptering eller når en ECDH-ES-avledet nøkkel fungerer direkte som CEK, vil denne delen være tom. Dette skjer fordi CEK er etablert på andre måter (forhåndsdelt eller avledet).

Du finner mer informasjon i delen Kryptografiske algoritmer for nøkkeladministrasjon i JSON Web Algorithms (JWA) RFC.

Initialiseringsvektor

Initialiseringsvektoren er en tilfeldig verdi som brukes ved kryptering av klarteksten (hvis den brukes av krypteringsalgoritmen). Den forbedrer sikkerheten ved å sørge for at den samme klarteksten krypteres forskjellig hver gang. Hvis en symmetrisk krypteringsalgoritme ikke krever en initialiseringsvektor, vil denne delen være tom.

Chiffertekst

Chifferteksten er den krypterte formen av den opprinnelige klarteksten. Den produseres ved å utføre autentisert kryptering ved hjelp av innholdskrypteringsnøkkelen (CEK), krypteringsalgoritmen (spesifisert av overskriftsparameteren enc ) og ytterligere autentiserte data. Krypteringsteksten er den sentrale delen av JWE, ettersom den inneholder de beskyttede dataene.

Autentiseringsmerke

Denne delen inneholder autentiseringsetiketten som genereres ved å utføre autentisert kryptering. Formålet er å sikre integriteten til den krypterte meldingen ved å oppdage eventuelle uautoriserte endringer. Hvis noen del av JWE endres etter kryptering, vil dekrypteringsprosessen oppdage manipulasjon fordi autentiseringsetiketten ikke stemmer overens. Denne delen forblir tom hvis en symmetrisk krypteringsalgoritme ikke bruker en autentiseringstag.

Krypterings- og dekrypteringsprosessen

JWE fungerer ved å kombinere ulike kryptografiske teknikker: Den bruker en nøkkelhåndteringsprosess for å beskytte innholdskrypteringsnøkkelen, som deretter brukes til å kryptere den faktiske klarteksten symmetrisk. Slik fungerer det:

Generering og administrasjon av nøkler

• Alg-parameteren i JWE-headeren bestemmer hvordan innholdskrypteringsnøkkelen (Content Encryption Key, CEK) krypteres, genereres eller avledes.
• Avsenderen genererer en tilfeldig symmetrisk CEK.
• Denne CEK-en sikres (krypteres) eller avledes basert på den valgte algoritmen (alg).

Kryptering av en melding

• Avsenderen forbereder klarteksten som skal krypteres.
• Avsenderen oppretter JWE-headeren og spesifiserer krypteringsalgoritmen(enc) og nøkkelhåndteringsalgoritmen (alg) som skal brukes.
• Avsenderen genererer en tilfeldig JWE Initialization Vector.
• Den base64url-kodede formen av JOSE Header brukes som Additional Authenticated Data (AAD).
• Autentiserte kryptering utføres på klarteksten ved hjelp av algoritmen som er spesifisert av enc-parameteren, med CEK som krypteringsnøkkel, initialiseringsvektoren og AAD. Denne prosessen produserer Ciphertext (det krypterte innholdet) og en Authentication Tag.
• De resulterende komponentene base64url-kodes og sammenkjedes med prikker (.), noe som danner den endelige JWE (Compact Serialization):

BASE64URL(UTF8(JWE Protected Header)) || '.' || BASE64URL(JWE Encrypted Key) || '.' || BASE64URL(JWE Initialization Vector) || '.' || BASE64URL(JWE Ciphertext) || '.' || BASE64URL(JWE Authentication Tag).

Dekryptering av en melding

• Mottakeren sjekker alg-parameteren. Basert på denne algoritmen bruker de sin private nøkkel (hvis CEK var asymmetrisk kryptert) eller en forhåndsdelt symmetrisk nøkkel (hvis nøkkelinnpakning ble brukt), eller utfører en nøkkelavtale for å få tak i CEK.
• Den dekrypterte CEK-en og JWE-initialiseringsvektoren brukes til å dekryptere chifferteksten.
• Mottakeren verifiserer integriteten til dataene ved hjelp av autentiseringstaggen og AAD-en. Hvis taggen ikke stemmer overens, indikerer det at meldingen er manipulert, og dekrypteringsforsøket mislykkes.

Konklusjon

JSON Web Encryption bidrar til å beskytte data i moderne webapplikasjoner. Når du vet hvordan den fungerer og hva den gjør, kan du bestemme når og hvordan du skal bruke den.

Nå som du er kjent med det grunnleggende om JWE, la oss utforske de praktiske bruksområdene. I neste artikkel skal vi se nærmere på hvordan JWE kan brukes til å kryptere brukerinformasjon og token-svar i autentiseringsflyter.