AES-GCM kan skydda ett meddelandes konfidentialitet och upptäcka obehöriga ändringar. Det talar inte i sig om för mottagaren huruvida ett i övrigt giltigt meddelande redan har behandlats.
Tre krav blandas lätt ihop: unika nyckel/nonce-par för kryptering, autentisering av meddelandet och dess kontext samt hantering av återuppspelning på protokollnivå. HKDF kan hjälpa till att härleda nycklar, men uppfyller inte automatiskt alla tre.
Återanvändning av nonce och återuppspelning är olika händelser
| Händelse | Vad som händer | Skydd som krävs |
|---|---|---|
| Återanvändning av nonce vid kryptering | Olika klartexter krypteras med samma GCM-nyckel och nonce | En tillförlitlig strategi för tilldelning av nyckel/nonce |
| Manipulering | Chiffertext eller autentiserad kontext ändras | Autentiserad dekryptering och avvisning vid fel |
| Återuppspelning | Ett tidigare giltigt krypterat meddelande levereras igen | Tillstånd och applikationsregler som känner igen dubbletter eller inaktuella meddelanden |
| Omordning | Giltiga meddelanden anländer i en annan ordning | Protokolldefinierad ordning och begränsad hantering av meddelanden ur ordning |
En återuppspelad chiffertext kan fortfarande ha en giltig autentiseringstagg. Inget har ändrats. Det är därför fel att säga att varje dubblett automatiskt underkänns av AES-GCM-autentisering. RFC 5116 skiljer uttryckligen AEAD-gränssnittet från tjänster mot återuppspelning.
Varför nyckel- och nonce-paret inte får upprepas
GCM:s nonce behöver inte vara hemlig, men måste uppfylla systemets unikhetskrav för en viss nyckel. En nonce på 96 bitar, eller 12 byte, är vanlig; att välja den längden garanterar inte korrekt generering.
Om samma nyckel och nonce återanvänds för olika klartexter återanvänds krypteringens nyckelström, vilket avslöjar samband mellan klartexterna. Det kan också undergräva autenticiteten och möjliggöra förfalskning. Konsekvenserna är allvarliga, men ska inte beskrivas som att varje gammal nyckel eller varje meddelande på ett konto automatiskt avslöjas. Omfattningen beror på den återanvända nyckeln och protokollet.
NIST SP 800-38D definierar GCM och dess krav. Implementeringar måste följa tillämpliga anropsgränser och regler för nonce-generering, inte en förenklad tumregel om att vara ”säker upp till så här många meddelanden”.
Vad HKDF bidrar med
HKDF, som specificeras i RFC 5869, härleder nyckelmaterial från hemligt indatamaterial genom extraktions- och expansionssteg. Protokoll kan använda kontextetiketter och skilda indata för att separera nycklar för olika ändamål.
HKDF är deterministisk. Om en kraschad eller återställd klient upprepar samma tillstånd och indata kan den härleda samma utdata igen. Att lägga till HKDF i en konstruktion gör därför inte nonce-återanvändning omöjlig.
Nycklar per meddelande kan minska mängden innehåll som skyddas av en enskild nyckel, men säkra tillståndsframsteg, nyckelseparation och radering är fortfarande viktiga. Samma nonce-värde under faktiskt olika nycklar är inte samma fel som att upprepa ett nyckel/nonce-par; protokollet måste fastställa att nycklarna verkligen är olika.
Skydd mot återuppspelning hör hemma i protokollet
En mottagare kan hålla reda på meddelandeidentifierare, sekvenspositioner, sessionsepoker eller förbrukade ratchet-nycklar. Relevanta fält måste autentiseras så att en angripare inte kan märka om ett gammalt meddelande till ett nytt.
Applikationen måste sedan avgöra vad en dubblett betyder. Att visa en dubblerad chattbubbla är besvärligt; att utföra samma åtgärd två gånger kan vara allvarligare. Nätverksomförsök är normala, så idempotent behandling behövs ofta vid sidan av kryptografiska kontroller.
Kräv inte att varje giltigt meddelande anländer i strikt ordning om inte protokollet anger det beteendet. Mobilklienter återansluter, gör omförsök och tar emot försenade meddelanden rutinmässigt. Säker hantering skiljer ett legitimt sent meddelande från ett redan förbrukat meddelande eller ett meddelande i fel kontext.
Vad som bör testas innan skydd utlovas
- Starta om efter att en nonce har tilldelats men innan sändningen registrerats: kan tilldelningen upprepas?
- Återställ en äldre tillståndsögonblicksbild: kan nycklar, räknare eller återuppspelningsregister rullas tillbaka?
- Skicka samtidigt från två arbetare eller enheter: är deras nyckel/nonce-domäner separerade?
- Leverera samma giltiga meddelande två gånger: utförs applikationsåtgärden en gång?
- Ändra en sessionsidentifierare eller ett huvudfält: är kontexten kryptografiskt bunden?
- Leverera giltiga meddelanden ur ordning: hanteras stödda fördröjningar utan att inaktuellt tillstånd accepteras?
API:er för autentiserad dekryptering bör lämna ut klartext till applikationen först efter lyckad verifiering. Det är ett gränssnittskrav, inte ett påstående om att ingen implementering någonsin beräknar en tillfällig klartextbuffert internt.
Att läsa Livaras påståenden korrekt
Livaras säkerhetsdokumentation nämner AES-256-GCM, kedjor per meddelande och LVR1/LGS1-kontext. Dessa primitiver bevisar inte i sig korrekt kraschåterställning, nonce-tilldelning eller avvisning av återuppspelning. Sådana påståenden kräver versionsangivna protokolldetaljer och testbevis.
En stark konstruktion tilldelar varje uppgift uttryckligen: nyckelhärledning skapar de avsedda nycklarna, AEAD autentiserar innehåll och kontext, och tillståndsbaserad protokollogik avgör om ett giltigt meddelande är godtagbart just nu.
