AES-GCM kan de vertrouwelijkheid van een bericht beschermen en onbevoegde wijzigingen detecteren. Op zichzelf vertelt het de ontvanger niet of een verder geldig bericht al is verwerkt.
Drie eisen worden gemakkelijk door elkaar gehaald: unieke sleutel/nonce-paren voor versleuteling, authenticatie van het bericht en zijn context, en replayafhandeling op protocolniveau. HKDF kan helpen sleutels af te leiden, maar voldoet niet automatisch aan alle drie.
Noncehergebruik en replay zijn verschillende gebeurtenissen
| Gebeurtenis | Wat er gebeurt | Benodigde bescherming |
|---|---|---|
| Noncehergebruik tijdens versleuteling | Verschillende leesbare teksten worden met dezelfde GCM-sleutel en nonce versleuteld | Een betrouwbare strategie voor de toewijzing van sleutels en nonces |
| Manipulatie | De versleutelde tekst of geauthenticeerde context wordt gewijzigd | Geauthenticeerde ontsleuteling en afwijzing bij mislukking |
| Replay | Een eerder geldig versleuteld bericht wordt opnieuw afgeleverd | Toestand en toepassingsregels die duplicaten of verouderde berichten herkennen |
| Herschikking | Geldige berichten komen in een andere volgorde aan | Door het protocol vastgelegde volgorde en begrensde afhandeling buiten die volgorde |
Opnieuw afgeleverde versleutelde tekst kan nog steeds een geldige authenticatietag hebben. Er is niets gewijzigd. Het is daarom onjuist om te zeggen dat ieder duplicaat automatisch niet door de AES-GCM-authenticatie komt. RFC 5116 scheidt de AEAD-interface expliciet van antireplaydiensten.
Waarom het sleutel-nonce-paar niet mag worden herhaald
De nonce van GCM hoeft niet geheim te zijn, maar moet onder een bepaalde sleutel voldoen aan de uniciteitseisen van het schema. Een nonce van 96 bits, oftewel 12 bytes, is gebruikelijk; die lengte kiezen garandeert geen correcte generatie.
Hergebruik van dezelfde sleutel en nonce voor verschillende leesbare teksten hergebruikt de versleutelingssleutelstroom en legt verbanden tussen die teksten bloot. Het kan ook de authenticiteit ondermijnen en vervalsing mogelijk maken. De impact is ernstig, maar mag niet worden omschreven als het automatisch onthullen van alle oude sleutels of alle berichten in een account. De omvang van de gevolgen hangt af van de hergebruikte sleutel en het protocol.
NIST SP 800-38D definieert GCM en zijn eisen. Implementaties moeten de toepasselijke aanroeplimieten en regels voor noncegeneratie volgen, niet een simplistische vuistregel zoals ‘veilig tot zoveel berichten’.
Wat HKDF bijdraagt
HKDF, gespecificeerd in RFC 5869, leidt sleutelmateriaal af uit geheim invoermateriaal via extractie- en expansiestappen. Protocollen kunnen contextlabels en verschillende invoer gebruiken om sleutels voor verschillende doelen te scheiden.
HKDF is deterministisch. Als een gecrashte of naar een eerdere toestand teruggezette client dezelfde toestand en invoer herhaalt, kan die opnieuw dezelfde uitvoer afleiden. HKDF aan een ontwerp toevoegen maakt noncehergebruik dus niet onmogelijk.
Sleutels per bericht kunnen de hoeveelheid inhoud beperken die onder één sleutel wordt beschermd, maar veilige voortgang van de toestand, sleutelscheiding en verwijdering blijven belangrijk. Dezelfde noncewaarde onder werkelijk verschillende sleutels is niet dezelfde fout als het herhalen van een sleutel/nonce-paar; het protocol moet vaststellen dat de sleutels echt verschillend zijn.
Replaybescherming hoort in het protocol
Een ontvanger kan berichtidentificaties, volgordeposities, sessie-epochs of verbruikte ratchetsleutels bijhouden. Relevante velden moeten geauthenticeerd zijn, zodat een aanvaller een oud bericht niet als nieuw kan labelen.
De toepassing moet vervolgens bepalen wat een duplicaat betekent. Een dubbele chatballon tonen is hinderlijk; dezelfde actie tweemaal uitvoeren kan ernstiger zijn. Netwerkherhalingen zijn normaal, dus naast cryptografische controles is vaak idempotente verwerking nodig.
Eis niet dat ieder geldig bericht strikt op volgorde aankomt, tenzij het protocol dat gedrag voorschrijft. Mobiele clients maken regelmatig opnieuw verbinding, proberen verzendingen opnieuw en ontvangen vertraagde berichten. Veilige afhandeling onderscheidt een legitiem laat bericht van een al verbruikt bericht of een bericht met de verkeerde context.
Wat je moet testen voordat je bescherming claimt
- Herstart na het toewijzen van een nonce, maar vóór het vastleggen van de verzending: kan de toewijzing worden herhaald?
- Herstel een oudere momentopname van de toestand: kunnen sleutels, tellers of replayregistraties worden teruggedraaid?
- Verzend gelijktijdig vanaf twee werkprocessen of apparaten: zijn hun sleutel/nonce-domeinen gescheiden?
- Lever hetzelfde geldige bericht tweemaal af: wordt de toepassingsactie één keer uitgevoerd?
- Wijzig een sessie-identificatie of header: is de context cryptografisch gebonden?
- Lever geldige berichten buiten de volgorde af: worden ondersteunde vertragingen afgehandeld zonder verouderde toestand te accepteren?
API’s voor geauthenticeerde ontsleuteling moeten leesbare tekst pas na succesvolle verificatie aan de toepassing teruggeven. Dat is een interfacevereiste; het is geen bewering dat geen enkele implementatie ooit intern een tijdelijke buffer met leesbare tekst berekent.
Livara’s claims nauwkeurig lezen
Livara’s beveiligingsdocumentatie noemt AES-256-GCM, ketens per bericht en LVR1/LGS1-context. Deze bouwstenen bewijzen op zichzelf geen correct crashherstel, correcte noncetoewijzing of afwijzing van replays. Zulke claims vereisen protocolgegevens met versieaanduidingen en testbewijs.
Een sterk ontwerp wijst elke taak expliciet toe: sleutelafleiding maakt de bedoelde sleutels, AEAD authenticeert inhoud en context, en toestandhoudende protocollogica beslist of een geldig bericht nu aanvaardbaar is.
