Authenticated encryption: AES-GCM en ChaCha20-Poly1305

Versleuteling met authenticatie (AE) lost een fundamenteel probleem op: traditionele versleuteling biedt alleen vertrouwelijkheid — de gegevens blijven geheim — maar controleert niet of de ciphertext is gemanipuleerd. Een aanvaller kan bits in de ciphertext wijzigen, waarna de ontvanger onbruikbare gegevens ontsleutelt zonder te weten dat deze zijn gewijzigd. Versleuteling met authenticatie en bijbehorende gegevens (AEAD) voegt tegelijkertijd een garantie voor integriteit en authenticiteit toe. Het resultaat bestaat uit versleutelde ciphertext en een authenticatietag die elke wijziging detecteert.

AES-GCM (Galois/Counter Mode) combineert twee onderdelen: AES-CTR (Counter Mode) voor versleuteling en GMAC (Galois Message Authentication Code) voor integriteit. AES-CTR genereert een sleutelstroom door een tellerwaarde te versleutelen en deze met de platte tekst te XOR'en — hierdoor kan de versleuteling parallel worden uitgevoerd, in tegenstelling tot de CBC-modus. GMAC berekent een authenticatietag over de ciphertext en eventuele bijbehorende gegevens. De resulterende tag (128 bits) wordt samen met de ciphertext verzonden; door één enkele bit te wijzigen wordt de tag ongeldig.

AES-GCM vereist een nonce (getal dat één keer wordt gebruikt), meestal 96 bits (12 bytes). De nonce moet uniek zijn voor elke afzonderlijke versleutelingsbewerking met dezelfde sleutel — hij hoeft niet geheim te zijn, maar mag nooit worden herhaald. Hergebruik van een nonce in AES-GCM is rampzalig: als twee berichten met dezelfde sleutel en nonce worden versleuteld, kan een aanvaller de cijferteksten XOR-en om de sleutelstroom weg te strepen, waardoor mogelijk beide oorspronkelijke teksten worden achterhaald. Deze kwetsbaarheid wordt soms 'nonce-misbruik' genoemd en heeft in de praktijk geleid tot aanvallen waarbij sleutels werden teruggewonnen.

Wanneer AES-GCM-nonces worden hergebruikt, kan de aanvaller C1 XOR C2 = P1 XOR P2 berekenen (de XOR van beide oorspronkelijke teksten), omdat voor beide dezelfde sleutelstroom is gebruikt. Daarnaast maakt hergebruik van een nonce het mogelijk om de authenticatiesleutel H terug te winnen. Daarmee kan de aanvaller geldige authenticatietags voor willekeurige berichten vervalsen — zowel de vertrouwelijkheid als de integriteit wordt volledig doorbroken. Systemen zoals de Sony PS3 waren het slachtoffer van precies deze aanval. De verdediging bestaat uit willekeurige nonces (gegenereerd met een CSPRNG) of een deterministische teller die nooit wordt gereset.

ChaCha20-Poly1305 is het andere AEAD-cijfer dat TLS 1.3 voorschrijft. ChaCha20 is een stroomcijfer, ontworpen door Daniel Bernstein, dat een sleutelstroom genereert met bewerkingen voor optellen, roteren en XOR-en (ARX) — zonder opzoektabellen, volledig in constante tijd en extreem snel op CPU's zonder hardwarematige AES-versnelling. Poly1305 is een eenmalige MAC (berichtauthenticatiecode) die de authenticatietag over de cijfertekst berekent. Samen bieden ze een gelijkwaardige beveiliging aan AES-GCM, maar ze zijn aanzienlijk sneller op mobiele apparaten en IoT-apparaten.

Moderne x86- en ARM64-processors voor desktops en servers bevatten AES-NI-hardware-instructies die AES-GCM extreem snel maken. Veel mobiele en IoT-processors hebben echter geen AES-NI, waardoor AES-GCM in software relatief langzaam is. ChaCha20-Poly1305 is ontworpen om snel in software te werken met eenvoudige rekenkundige bewerkingen. Daardoor krijgen mobiele apparaten vergelijkbare prestaties zonder hardwareversnelling. Google heeft ChaCha20-Poly1305 juist als alternatief aan TLS toegevoegd voor Android-apparaten, en het is nu een volwaardige cijferreeks in TLS 1.3.

De 'AD' in AEAD staat voor Associated Data — metagegevens in oorspronkelijke vorm die worden geauthenticeerd maar niet versleuteld. Zo kun je gegevens authenticeren die leesbaar moeten blijven (zoals pakketheaders of velden voor het recordtype) en ze toch tegen manipulatie beschermen. In TLS 1.3 worden de bytes van de recordheader als geassocieerde gegevens opgenomen in de AEAD-berekening. Als een aanvaller de header wijzigt (bijvoorbeeld de recordlengte), mislukt de verificatie van de authenticatietag en wordt de verbinding beëindigd.

Voordat AEAD de standaard werd, adviseerden cryptografen Encrypt-then-MAC (EtM): versleutel de oorspronkelijke tekst en bereken vervolgens een MAC over de cijfertekst. Dit is veilig, maar vereist twee afzonderlijke bewerkingen met twee afzonderlijke sleutels. AEAD-schema's zoals AES-GCM combineren beide bewerkingen met één sleutel. Dat vermindert de complexiteit van de implementatie en elimineert een hele categorie padding-oracle-aanvallen die MAC-then-Encrypt (MtE) teisterden — de volgorde die in oudere TLS-versies werd gebruikt (CBC + HMAC). TLS 1.3 voorkomt deze problemen volledig door AEAD te gebruiken.

Zowel AES-128-GCM als AES-256-GCM zijn goedgekeurd door NIST en worden als veilig beschouwd tegen klassieke computers. AES-128 biedt 128-bits beveiliging en iets betere prestaties; AES-256 biedt 256-bits beveiliging en daarmee een grotere marge tegen toekomstige cryptanalyse en kwantumdreigingen. Voor de meeste toepassingen is AES-128-GCM tegenwoordig voldoende, maar voor geheime overheidssystemen (NSA Suite B) is AES-256 vereist. TLS 1.3 biedt beide mogelijkheden en servers kunnen op basis van hun beveiligingsbeleid een voorkeur instellen.

Bij het ontsleutelen van AEAD-cijfertekst moet de ontvanger de authenticatietag verifiëren voordat hij ontsleutelt. Het proces is als volgt: bereken de verwachte tag opnieuw op basis van de ontvangen cijfertekst, sleutel en nonce; vergelijk deze met de ontvangen tag met behulp van een vergelijkingsfunctie met constante uitvoeringstijd; ga alleen verder met ontsleutelen als ze overeenkomen. Een vergelijking met constante uitvoeringstijd is cruciaal — als de vergelijking stopt bij de eerste afwijkende byte, kan een aanvaller een timingaanval via een zijkanaal uitvoeren om geldige tags byte voor byte te vervalsen. Elke AEAD-bibliotheek die een vergelijking gebruikt die voortijdig stopt, is kwetsbaar.

AEAD-algoritmen worden overal toegepast in moderne beveiliging: TLS 1.3 gebruikt AES-GCM en ChaCha20-Poly1305 voor de versleuteling van alle records; WireGuard VPN gebruikt uitsluitend ChaCha20-Poly1305; Signal Protocol gebruikt het voor berichtversleuteling; het QUIC-protocol (de basis van HTTP/3) gebruikt AES-GCM. Wanneer je een cijferreeks ziet zoals TLS_AES_256_GCM_SHA384, verwijst SHA384 naar de HKDF-hashfunctie voor sleutelafleiding, niet naar het integriteitsmechanisme — de GCM-tag zorgt voor de integriteit.

In deze les heb je geleerd dat AEAD-algoritmen vertrouwelijkheid en integriteit tegelijk bieden via een authenticatietag die elke wijziging van de cijfertekst detecteert, dat hergebruik van een AES-GCM-nonce rampzalig is — omdat dit het terugwinnen van de sleutelstroom en het vervalsen van de authenticatiesleutel mogelijk maakt — en dat ChaCha20-Poly1305 een prestatie-efficiënt alternatief voor AES-GCM is op apparaten zonder hardwarematige AES-versnelling. Hierna bekijken we sleutelafleidingsfuncties voor het beveiligen van wachtwoorden.