Autentiserad kryptering: AES-GCM och ChaCha20-Poly1305

Authenticated Encryption (AE) löser ett grundläggande problem: traditionell kryptering ger endast konfidentialitet – den håller data hemliga – men verifierar inte om chiffertexten har manipulerats. En angripare kan ändra bitar i chiffertexten, varpå mottagaren dekrypterar skräp utan att veta att datan har ändrats. Authenticated Encryption with Associated Data (AEAD) lägger samtidigt till en garanti för integritet och äkthet genom att generera både krypterad chiffertext och en authentication tag som upptäcker alla ändringar.

AES-GCM (Galois/Counter Mode) kombinerar två komponenter: AES-CTR (Counter Mode) för kryptering och GMAC (Galois Message Authentication Code) för integritet. AES-CTR genererar en keystream genom att kryptera ett räknarvärde och XOR:a det med klartexten – därför kan krypteringen parallelliseras, till skillnad från CBC mode. GMAC beräknar en authentication tag över chiffertexten och eventuella associerade data. Den resulterande taggen (128 bitar) skickas tillsammans med chiffertexten; en enda bitändring gör taggen ogiltig.

AES-GCM kräver en nonce (number used once), vanligtvis 96 bitar (12 byte). Noncevärdet måste vara unikt för varje enskild krypteringsoperation med samma nyckel — det behöver inte vara hemligt, men får aldrig upprepas. Återanvändning av noncevärden i AES-GCM är katastrofal: om två meddelanden krypteras med samma nyckel och nonce kan en angripare XOR:a chiffertexterna för att ta bort keystreamen och potentiellt återskapa båda klartexterna. Denna sårbarhet kallas ibland 'nonce misuse' och har lett till verkliga attacker där nycklar har återskapats.

När noncevärden återanvänds i AES-GCM kan angriparen beräkna C1 XOR C2 = P1 XOR P2 (XOR-resultatet av de båda klartexterna), eftersom samma keystream användes för båda. Dessutom gör återanvändning av noncevärden det möjligt att återskapa autentiseringsnyckeln H, vilket innebär att angriparen kan förfalska giltiga autentiseringstaggar för godtyckliga meddelanden — både konfidentialitet och integritet bryts då fullständigt. System som Sony PS3 utsattes för exakt denna attack. Försvaret är slumpmässiga noncevärden (genererade med en CSPRNG) eller en deterministisk räknare som aldrig återställs.

ChaCha20-Poly1305 är det andra AEAD-chiffret som krävs i TLS 1.3. ChaCha20 är ett strömkrypto som utvecklats av Daniel Bernstein och genererar en keystream med hjälp av ARX-operationer (add-rotate-XOR) — utan uppslagstabeller, helt i konstant tid och extremt snabbt på processorer utan hårdvaruacceleration för AES. Poly1305 är en engångs-MAC (message authentication code) som beräknar autentiseringstaggen över chiffertexten. Tillsammans ger de motsvarande säkerhet som AES-GCM, men är betydligt snabbare på mobila enheter och IoT-enheter.

Moderna x86- och ARM64-processorer för datorer och servrar har hårdvaruinstruktioner för AES-NI som gör AES-GCM extremt snabbt. Många processorer i mobila enheter och IoT-enheter saknar dock AES-NI, vilket gör AES-GCM i programvara relativt långsamt. ChaCha20-Poly1305 har utformats för att vara snabbt i programvara med hjälp av enkla aritmetiska operationer, så att mobila enheter får jämförbar prestanda utan hårdvaruacceleration. Google lade till ChaCha20-Poly1305 i TLS som ett alternativ just för Android-enheter, och det är nu en förstaklassig cipher suite i TLS 1.3.

'AD' i AEAD står för Associated Data — metadata i klartext som autentiseras men inte krypteras. På så sätt kan data som måste förbli läsbara (till exempel pakethuvuden eller fält för posttyp) autentiseras samtidigt som de skyddas mot manipulation. I TLS 1.3 inkluderas bytesen i postens header som associerade data i AEAD-beräkningen. Om en angripare ändrar headern (till exempel postens längd) misslyckas verifieringen av autentiseringstaggen och anslutningen avslutas.

Innan AEAD blev standard rekommenderade kryptografer Encrypt-then-MAC (EtM): kryptera klartexten och beräkna sedan en MAC över chiffertexten. Detta är säkert, men kräver två separata operationer med två separata nycklar. AEAD-scheman som AES-GCM kombinerar båda operationerna med en enda nyckel, vilket minskar komplexiteten i implementationen och eliminerar en hel klass av padding oracle-attacker som drabbade MAC-then-Encrypt (MtE) — den ordningsföljd som användes i äldre TLS-versioner (CBC + HMAC). TLS 1.3 med AEAD undviker dessa problem helt.

Både AES-128-GCM och AES-256-GCM är godkända av NIST och anses säkra mot klassiska datorer. AES-128 ger 128-bitars säkerhet med något bättre prestanda, medan AES-256 ger 256-bitars säkerhet och därmed större marginal mot framtida kryptoanalys och kvantdatorhot. För de flesta tillämpningar i dag är AES-128-GCM tillräckligt, men statliga system med sekretessbelagd information (NSA Suite B) kräver AES-256. TLS 1.3 erbjuder båda, och servrar kan prioritera dem utifrån sin säkerhetspolicy.

När AEAD-chiffertext dekrypteras måste mottagaren verifiera autentiseringstaggen innan dekryptering. Processen är följande: beräkna den förväntade taggen på nytt utifrån den mottagna chiffertexten, nyckeln och noncevärdet; jämför den med den mottagna taggen med en jämförelsefunktion i konstant tid; fortsätt med dekrypteringen endast om de matchar. Jämförelse i konstant tid är avgörande — om jämförelsen avbryts vid den första byte som inte matchar kan en angripare genomföra en timingbaserad sidokanalsattack för att förfalska giltiga taggar byte för byte. Alla AEAD-bibliotek som använder jämförelser med tidigt avbrott är sårbara.

AEAD-algoritmer används överallt i modern säkerhet: TLS 1.3 använder AES-GCM och ChaCha20-Poly1305 för kryptering av alla poster; WireGuard VPN använder enbart ChaCha20-Poly1305; Signal Protocol använder det för meddelandekryptering; QUIC protocol (som ligger till grund för HTTP/3) använder AES-GCM. När ni ser en cipher suite som TLS_AES_256_GCM_SHA384 syftar SHA384 på HKDF-hashfunktionen för nyckelavledning, inte på integritetsmekanismen — GCM-taggen hanterar integriteten.

I den här lektionen har ni lärt er att AEAD-algoritmer samtidigt ger konfidentialitet och integritet via en autentiseringstagg som upptäcker alla ändringar i chiffertexten, att återanvändning av noncevärden i AES-GCM är katastrofal — eftersom den möjliggör återskapande av keystreamen och förfalskning av autentiseringsnyckeln — så noncevärden måste vara unika för varje kryptering, samt att ChaCha20-Poly1305 är ett prestandaeffektivt alternativ till AES-GCM för enheter som saknar hårdvaruacceleration för AES. Härnäst går vi igenom nyckelavledningsfunktioner för säker lagring av lösenord.