JSON Web Encryption: Hur det fungerar, varför det är viktigt och när man ska använda det

Det här är en introduktion till JSON Web Encryption: en standard som är utformad för att hålla data konfidentiella.

Om termer som "JSON Web Token" och "JSON Web Signature" är nya för dig, överväg att börja med våra andra artiklar:

• JWT-anspråk i OpenID Connect
• Förstå JWT-validering

Vad är JWE?

JSON Web Encryption (JWE) är en IETF-standard för att representera krypterat innehåll i JSON-format. Den är en del av ett bredare JOSE-ramverk (JSON Object Signing and Encryption), som även omfattar JSON Web Token (JWT ) och JSON Web Signature (JWS).

JWE skyddar information och säkerställer dess konfidentialitet. Kryptografin bakom JWE gör att endast auktoriserade parter med rätt dekrypteringsnyckel kan läsa de krypterade uppgifterna.

Alla typer av innehåll, inklusive en enkel mening, kan krypteras med JWE. Den vanligaste tillämpningen är dock kryptering av en JWT. När en JWT är både signerad (med JWS) och krypterad (med JWE) kallas den ofta för en Nested JWT. Nested JWT kan användas i autentiseringsscenarier med OAuth 2.0 och OpenID Connect, när ett extra lager av skydd krävs för känsliga data.

I det här blogginlägget fokuserar vi på det vanligaste användningsfallet: Nested JWT. Vi kommer också bara att täcka Compact Serialization-formatet, i motsats till den mindre populära JSON Serialization.

Varför använda JWE?

Datasäkerhet är en stor utmaning för moderna applikationer, särskilt när man hanterar och överför känslig information som finansiella detaljer, personuppgifter eller inloggningsuppgifter över internet. JWE är ovärderligt när det gäller att:

• Säkerställa datasekretess: JWE håller känsliga uppgifter konfidentiella. Även om ett JWE-säkrat meddelande fångas upp förblir innehållet oläsligt utan rätt dekrypteringsnyckel.
  
  
• Följa regleringar: Branscher som hälso- och sjukvård samt finanssektorn lyder under strikta regler som kräver att de skyddar kunddata genom kryptering. JWE hjälper organisationer att uppfylla dessa krav.

Vanliga användningsområden för JWE

JWE har flera praktiska tillämpningar.

1. Säkra API:er: API:er hanterar ofta utbyte av känslig data mellan klienter och servrar. Genom att använda JWE för att kryptera API-begäranden och -svar hålls informationsflödet privat. En auktoriseringsserver kan till exempel använda JWE för att kryptera token och userinfo endpoint-svar, vilket ger ett extra säkerhetslager till OAuth 2.0-baserade autentiseringsflöden.
   
   
2. Skydda data under transport: JWE är särskilt användbart när data överförs via potentiellt osäkra nätverk.
   
   
3. Lagring av krypterade data i databaser: För applikationer som lagrar JWT i databaser för autentisering eller sessionshantering, förhindrar kryptering av dessa tokens med JWE att känslig information exponeras i händelse av ett databasintrång.

Skillnaden mellan JWT, JWS och JWE

JSON Web Tokens tillhandahåller ett standardiserat sätt att överföra information. JWT utnyttjar två relaterade specifikationer:

• JSON Web Signature (JWS) för dataintegritet och äkthet
• JSON Web Encryption (JWE) för sekretess.

Låt oss ta en närmare titt på var och en:

JSON Web Token (JWT)

En JWT är en kompakt, URL-säker metod för att representera anspråk som ska överföras mellan två parter. Det är en allmänt antagen standard för autentisering och auktorisering, som ofta förmedlar detaljer om en autentiserad användare (som i OpenID Connect) eller de behörigheter som beviljas klientapplikationen (som i OAuth 2.0).

EN JWT:

• Definieras i stort av RFC 7519 som ett sätt att representera anspråk som ska överföras mellan två parter. Den kan signeras (med JWS) eller krypteras (med JWE), eller till och med vara osäker ("alg":"none").
• I praktiken och för alla säkra användningsfall är en JWT praktiskt taget alltid kryptografiskt signerad med JSON Web Signature (JWS). Signaturen säkerställer integriteten och äktheten hos de data som ingår i JWT.
• En signerad JWT består av tre delar: ett huvud, en nyttolast (anspråken) och en signatur.
• En signerad JWT garanterar att de data den innehåller inte har manipulerats, men garanterar inte sekretess - vem som helst som har token kan läsa innehållet.

JSON-webbsignatur (JWS)

JWS är en specifikation för digital signering av JSON-data, som:

• Garanterar dataintegritet och -autenticitet, vilket säkerställer att de signerade uppgifterna inte har manipulerats under transporten. Mottagaren kan verifiera att data inte har ändrats genom att validera signaturen.
• Lämnar data synliga men manipuleringssäkra.
• Är standardmekanismen för att signera JWT:er.

JSON webbkryptering (JWE)

JWE är en specifikation för att representera ett krypterat och integritetsskyddat meddelande.

JWE:

• Krypterar data för att ge konfidentialitet.
• Förlitar sig på en klass av kryptografiska algoritmer som kallas Authenticated Encryption with Associated Data (AEAD). Dessa algoritmer både krypterar data och tillhandahåller en integritetskontroll.
• Används ofta för att kryptera JWT:er för autentisering och auktorisering i känsliga miljöer (t.ex. finans eller sjukvård). De signerade och krypterade JWT:erna kallas för Nested JWT:er.
• Nested JWT är vanliga, men JWE gör det möjligt att kryptera godtyckliga värden. Den klartext som krypteras av JWE behöver inte vara en fullständig, formellt strukturerad JWT. Det kan helt enkelt vara ett JSON-objekt som innehåller anspråk (t.ex. {"user_id": "123", "role": "admin"}) som krypteras direkt, utan JWT-huvud och signatur.
• Består av fem delar: rubrik, krypterad nyckel, initialiseringsvektor, chiffertext och autentiseringstagg.

Strukturen för en JWE

En faktisk JWE kan se ut ungefär så här:

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

(Obs: Den faktiska JWE:n är en enda kontinuerlig sträng; nya rader läggs bara till för läsbarhetens skull).

I det här exemplet krypteras klartexten "Det sanna tecknet på intelligens är inte kunskap utan fantasi." till mottagaren. Lägg märke till att den består av fem delar, var och en base64url-kodad, åtskilda av punkter. Varje del av en JWE spelar en specifik roll i krypterings- och dekrypteringsprocessen.

Det här är ett exempel på en JWE Compact Serialization, som är det vanligaste formatet för JWE. Ett annat alternativ, som vi inte kommer att täcka i det här blogginlägget, är en JWE JSON Serialization.

De fem delarna av en JWE är:

JOSE-huvudet

JOSE Header innehåller information om krypteringsprocessen och själva JWE. Den specificerar de algoritmer som används för både nyckelhantering och innehållskryptering, tillsammans med valfria ytterligare egenskaper. Den måste innehålla följande parametrar:

• alg (Algorithm): anger den nyckelhanteringsalgoritm som används för att kryptera eller bestämma värdet på innehållskrypteringsnyckeln (CEK). Vanliga algoritmer är RSA1_5, RSA-OAEP, A128KW, A256KW etc.
  
  
• enc (Encryption Algorithm): anger den AEAD-algoritm (Authenticated Encryption with Associated Data) som används för att utföra den faktiska krypteringen av klartexten. Denna algoritm måste ha en specificerad nyckellängd och ger i sig själv både kryptering och integritetsskydd. Exempel är A128GCM, A256GCM (AES GCM), A128CBC-HS256 etc.
  

Valfria huvudparametrar som x5u (X.509 URL), kid (Key ID), cty (Content Type) etc. kan inkluderas.

Ett typiskt JWE-huvud kan se ut så här:

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

Detta huvud anger att innehållskrypteringsnyckeln krypteras till mottagaren med hjälp av RSA-OAEP-algoritmen och att autentiserad kryptering utförs på klartexten med hjälp av AES GCM med en 256-bitars nyckel.

Krypterad nyckel

Detta avsnitt innehåller CEK (Content Encryption Key), som är den symmetriska nyckel som används för att kryptera det faktiska innehållet i JWE. Parametern alg i JOSE Header anger hur denna CEK krypteras eller överenskoms.

Här följer exempel på hur CEK hanteras baserat på alg-värdet:

• Om alg är RSA-OAEP krypteras innehållskrypteringsnyckeln med RSA-OAEP-algoritmen med mottagarens publika nyckel.
• Om alg är A128KW eller A256KW (AES Key Wrap) är CEK symmetriskt omsluten (krypterad) med hjälp av en i förväg delad symmetrisk nyckel.
• För algoritmer som ECDH-ES (Elliptic-curve Diffie-Hellman) härleds en delad hemlighet via nyckelöverenskommelse. Denna härledda hemlighet används sedan vanligtvis för att omsluta CEK (ECDH-ES kombineras ofta med A128KW), men den kan också direkt fungera som CEK.

När CEK inte överförs inom JWE, t.ex. vid direktkryptering eller när en nyckel som härletts från ECDH-ES direkt fungerar som CEK, är detta avsnitt tomt. Detta inträffar eftersom CEK etableras på annat sätt (fördelad eller härledd).

Mer information finns i avsnittet Cryptographic Algorithms for Key Management i RFC:n JSON Web Algorithms (JWA).

Initialiseringsvektor

Initialiseringsvektorn är ett slumpmässigt värde som används vid kryptering av klartexten (om det används av krypteringsalgoritmen). Det förbättrar säkerheten genom att säkerställa att samma klartext krypteras på olika sätt varje gång. Om en symmetrisk krypteringsalgoritm inte kräver en initialiseringsvektor är detta avsnitt tomt.

Chiffertext

Chiffertexten är den krypterade formen av den ursprungliga klartexten. Den produceras genom att utföra autentiserad kryptering med hjälp av CEK (Content Encryption Key), krypteringsalgoritmen (som anges av enc-headerparametern ) och ytterligare autentiserade data. Ciphertext är den centrala delen av JWE eftersom den innehåller de skyddade uppgifterna.

Tagg för autentisering

Detta avsnitt innehåller den autentiseringstagg som genereras genom autentiserad kryptering. Dess syfte är att säkerställa det krypterade meddelandets integritet genom att upptäcka obehöriga ändringar. Om någon del av JWE ändras efter kryptering kommer dekrypteringsprocessen att upptäcka manipulering eftersom Authentication Tag inte kommer att matcha. Detta avsnitt förblir tomt om en symmetrisk krypteringsalgoritm inte använder någon autentiseringstagg.

Krypterings- och dekrypteringsprocessen

JWE fungerar genom att kombinera olika kryptografiska tekniker: Den använder en nyckelhanteringsprocess för att skydda innehållskrypteringsnyckeln, som sedan används för att symmetriskt kryptera den faktiska klartexten. Så här fungerar det:

Generering och hantering av nycklar

• Alg-parametern i JWE-headern anger hur innehållskrypteringsnyckeln (CEK) krypteras, genereras eller härleds.
• Avsändaren genererar en slumpmässig symmetrisk CEK.
• Denna CEK säkras (krypteras) eller härleds sedan baserat på denvalda algoritmen(alg).

Kryptering av ett meddelande

• Avsändaren förbereder klartexten som ska krypteras.
• Avsändaren skapar en JWE Header som anger den krypteringsalgoritm(enc) och den nyckelhanteringsalgoritm(alg) som ska användas.
• Avsändaren genererar en slumpmässig JWE Initialization Vector.
• Den base64url-kodade formen av JOSE Header används som Additional Authenticated Data (AAD).
• Autentiserad kryptering utförs på klartexten med hjälp av den algoritm som anges av enc-parametern, med CEK som krypteringsnyckel, initialiseringsvektorn och AAD. Denna process producerar Ciphertext (det krypterade innehållet) och en Authentication Tag.
• De resulterande komponenterna base64url-kodas och konkateneras med punkter (.), vilket bildar den slutliga JWE (Compact Serialization):

BASE64URL(UTF8(JWE-skyddad rubrik)) || '.' || BASE64URL(JWE Encrypted Key) || '.' || BASE64URL(JWE Encrypted Key) || '.' || BASE64URL(JWE Initialization Vector) || '.' || BASE64URL(JWE Ciphertext) || '.' || BASE64URL(JWE Ciphertext) || '.' || BASE64URL(JWE Authentication Tag).

Dekryptering av ett meddelande

• Mottagaren kontrollerar alg-parametern. Baserat på denna algoritm använder de sin privata nyckel (om CEK var asymmetriskt krypterat) eller en i förväg delad symmetrisk nyckel (om nyckelombrytning användes), eller utför en nyckelöverenskommelse för att erhålla CEK.
• Den dekrypterade CEK:n och JWE:s initialiseringsvektor används för att dekryptera chiffertexten.
• Mottagaren verifierar dataintegriteten med hjälp av Authentication Tag och AAD. Om taggen inte stämmer överens indikerar det att meddelandet har manipulerats och dekrypteringsförsöket misslyckas.

Slutsats

JSON Web Encryption hjälper till att hålla data säkra i moderna webbapplikationer. Att veta hur det fungerar och vad det gör gör att du kan bestämma när och hur du ska använda det.

Nu när du är bekant med grunderna i JWE, låt oss utforska dess praktiska tillämpningar. I nästa artikel kommer vi att gå igenom hur JWE kan användas för att kryptera användarinformation och token-svar i autentiseringsflöden.