Autentisert kryptering: AES-GCM og ChaCha20-Poly1305

Authenticated Encryption (AE) løser et grunnleggende problem: Tradisjonell kryptering gir bare konfidensialitet – den holder dataene hemmelige – men verifiserer ikke om chifferteksten har blitt manipulert. En angriper kan endre biter i chifferteksten, slik at mottakeren dekrypterer uforståelige data uten å vite at de er endret. Authenticated Encryption with Associated Data (AEAD) legger samtidig til garantier for integritet og autentisitet, og produserer både en kryptert chiffertekst og en autentiseringstag som oppdager alle endringer.

AES-GCM (Galois/Counter Mode) kombinerer to komponenter: AES-CTR (Counter Mode) for kryptering og GMAC (Galois Message Authentication Code) for integritet. AES-CTR genererer en nøkkelstrøm ved å kryptere en tellerverdi og utføre XOR med klarteksten – dette gjør krypteringen parallelliserbar, i motsetning til CBC-modus. GMAC beregner en autentiseringstag over chifferteksten og eventuelle tilknyttede data. Den resulterende tagen (128 biter) sendes sammen med chifferteksten; én enkelt bitendring gjør tagen ugyldig.

AES-GCM krever en nonce (number used once), vanligvis på 96 biter (12 byte). Noncen må være unik for hver eneste krypteringsoperasjon med samme nøkkel — den trenger ikke være hemmelig, men den må aldri gjentas. Gjenbruk av nonce i AES-GCM er katastrofalt: Hvis to meldinger krypteres med samme nøkkel og nonce, kan en angriper bruke XOR på chiffertekstene for å kansellere keystreamen og potensielt gjenopprette begge klartekstene. Dette sikkerhetsproblemet kalles noen ganger «nonce misuse» og har ført til reelle angrep som har gjenopprettet nøkler.

Når AES-GCM-noncer gjenbrukes, kan angriperen beregne C1 XOR C2 = P1 XOR P2 (XOR-en av begge klartekstene), fordi den samme keystreamen ble brukt for begge. Gjenbruk av nonce gjør det dessuten mulig å gjenopprette autentiseringsnøkkelen H, noe som betyr at angriperen kan forfalske gyldige autentiseringstags for vilkårlige meldinger — og dermed fullstendig bryte både konfidensialitet og integritet. Systemer som Sony PS3 ble utsatt for akkurat dette angrepet. Forsvaret er tilfeldige noncer (generert med en CSPRNG) eller en deterministisk teller som aldri tilbakestilles.

ChaCha20-Poly1305 er det andre AEAD-chifferet som er påkrevd i TLS 1.3. ChaCha20 er et strømkrypteringschiffer utviklet av Daniel Bernstein som genererer en keystream ved hjelp av add-rotate-XOR-operasjoner (ARX) — uten oppslagstabeller, med fullstendig konstant kjøretid og svært høy hastighet på CPU-er uten maskinvareakselerasjon for AES. Poly1305 er en engangs-MAC (message authentication code) som beregner autentiseringstaggen over chifferteksten. Sammen gir de tilsvarende sikkerhet som AES-GCM, men er betydelig raskere på mobile enheter og IoT-enheter.

Moderne x86- og ARM64-prosessorer for skrivebordsmaskiner og servere har maskinvareinstruksjoner for AES-NI som gjør AES-GCM svært raskt. Mange mobile prosessorer og IoT-prosessorer mangler imidlertid AES-NI, noe som gjør AES-GCM i programvare relativt tregt. ChaCha20-Poly1305 er utviklet for å være rask i programvare ved hjelp av enkle aritmetiske operasjoner, og gir mobile enheter sammenlignbar ytelse uten maskinvareakselerasjon. Google la til ChaCha20-Poly1305 i TLS som et alternativ nettopp for Android-enheter, og det er nå en førsteklasses chifferpakke i TLS 1.3.

«AD» i AEAD står for Associated Data — klartekstmetadata som autentiseres, men ikke krypteres. Dette gjør det mulig å autentisere data som må forbli lesbare (for eksempel pakkeheadere eller felt for posttype), samtidig som de beskyttes mot manipulering. I TLS 1.3 inkluderes byte-ene i postheaderen som tilknyttede data i AEAD-beregningen. Hvis en angriper endrer headeren (for eksempel endrer postens lengde), mislykkes verifiseringen av autentiseringstaggen, og forbindelsen avsluttes.

Før AEAD ble standard, anbefalte kryptografer Encrypt-then-MAC (EtM): Krypter klarteksten, og beregn deretter en MAC over chifferteksten. Dette er sikkert, men krever to separate operasjoner med to separate nøkler. AEAD-skjemaer som AES-GCM kombinerer begge operasjonene med én enkelt nøkkel, noe som reduserer kompleksiteten i implementasjonen og eliminerer en hel klasse angrep med padding-orakler som rammet MAC-then-Encrypt (MtE) — rekkefølgen som ble brukt i eldre TLS-versjoner (CBC + HMAC). TLS 1.3 med AEAD unngår disse problemene fullstendig.

Både AES-128-GCM og AES-256-GCM er godkjent av NIST og regnes som sikre mot klassiske datamaskiner. AES-128 gir 128-biters sikkerhet med litt bedre ytelse, mens AES-256 gir 256-biters sikkerhet og dermed større sikkerhetsmargin mot fremtidig kryptoanalyse og kvantetrusler. For de fleste bruksområder i dag er AES-128-GCM tilstrekkelig, men offentlige systemer for klassifisert informasjon (NSA Suite B) krever AES-256. TLS 1.3 tilbyr begge, og servere kan prioritere basert på sikkerhetspolicyen sin.

Ved dekryptering av AEAD-chiffertekst må mottakeren verifisere autentiseringstaggen før dekryptering. Prosessen er som følger: Beregn den forventede taggen på nytt ut fra den mottatte chifferteksten, nøkkelen og noncen; sammenlign den med den mottatte taggen ved hjelp av en sammenligningsfunksjon med konstant kjøretid; fortsett med dekrypteringen bare hvis de samsvarer. Sammenligning med konstant kjøretid er avgjørende — hvis sammenligningen avsluttes ved den første byte-en som ikke samsvarer, kan en angriper utføre et tidsbasert sidekanalangrep for å forfalske gyldige tagger byte for byte. Alle AEAD-biblioteker som bruker en sammenligning med tidlig avslutning, er sårbare.

AEAD-algoritmer brukes overalt i moderne sikkerhet: TLS 1.3 bruker AES-GCM og ChaCha20-Poly1305 til kryptering av alle poster; WireGuard VPN bruker utelukkende ChaCha20-Poly1305; Signal Protocol bruker det til meldingskryptering; QUIC-protokollen (som HTTP/3 bygger på) bruker AES-GCM. Når du ser en chifferpakke som TLS_AES_256_GCM_SHA384, viser SHA384 til HKDF-hashfunksjonen for nøkkelavledning, ikke til integritetsmekanismen — GCM-taggen håndterer integriteten.

I denne leksjonen har De lært at AEAD-algoritmer gir konfidensialitet og integritet samtidig ved hjelp av en autentiseringstag som oppdager enhver endring i chifferteksten, at gjenbruk av AES-GCM-nonce er katastrofalt — fordi det kan gjøre det mulig å gjenopprette keystreamen og forfalske autentiseringsnøkkelen — og at noncer derfor må være unike for hver kryptering. De har også lært at ChaCha20-Poly1305 er et ytelseseffektivt alternativ til AES-GCM på enheter som mangler maskinvareakselerasjon for AES. Neste del handler om nøkkelavledningsfunksjoner for sikring av passord.