Hva en VPN-nonce er, og hvorfor gjenbruk ødelegger tunnelen
En nonce er en verdi per melding som aldri må gjentas under én nøkkel, og den reiser vanligvis i klartekst. Å redigere den for hånd er feilen du bør unngå.
De fleste møter ordet nonce i en VPN-profil og antar at det er nok en delt hemmelighet som skal kopieres mellom parter. Det er det ikke. En nonce er en verdi som aldri må gjentas under samme nøkkel, og i de fleste nonce-baserte krypteringer reiser den i klartekst. Forvirringen er harmløs helt til noen redigerer den for hånd, og det er der den virkelige skaden begynner.
Hvor noncen faktisk kommer fra
Autentisert kryptering trenger en annen nonce for hver melding som krypteres under en nøkkel. Protokoller oppfyller dette kravet på ulike måter: en monotont økende teller, et salt kombinert med en pakkeidentifikator eller en tilstrekkelig lang tilfeldig verdi. IKEv2 utveksler noncer under den innledende utvekslingen, og de er offentlige innganger til nøkkelutledning, ikke hemmeligheter.
Unikhet kan være strukturell eller sannsynlighetsbasert. En teller kan ikke gjentas før den ruller over, og derfor definerer protokollen et nøkkelbyttepunkt lenge før. En tilfeldig verdi er avhengig av nok biter til at en kollisjon er usannsynlig innenfor meldingsgrensen, som er et annet argument med en annen feilmodus. Protokolldokumentasjonen angir hvilken metode som gjelder, og begge er bare trygge så lenge den oppgitte grensen respekteres.
| Design | Where uniqueness comes from | Exhaustion is handled by |
|---|---|---|
| AES-GCM records | An IV, typically a counter | Rekey before the counter wraps |
| ChaCha20-Poly1305 | A 96-bit nonce from a counter or generator | A message limit per key |
| WireGuard | A per-key 64-bit counter | Rekey at a message cap |
| OpenVPN AEAD | Packet identifier plus implicit key material | Rekey on the packet-id limit |
| IKEv2 | Fresh nonces per exchange | A new security association |
Hva gjenbruk faktisk koster
Å gjenbruke en nonce under én nøkkel er ikke et lite effektivitetsspørsmål. Med GCM lar to meldinger som deler en IV en observatør gjenopprette autentiseringsnøkkelen og beregne den eksklusive eller av de to klartekstene. Strømbaserte konstruksjoner gjenbruker nøkkelstrømmen på samme måte, noe som gjør chifferteksten til et puslespill i stedet for en hemmelighet.
Derfor bytter implementasjoner nøkkel før en teller ruller over, og derfor stopper de i stedet for å fortsette når tilstanden er usikker. En omstart som nullstiller en teller mens motparten fortsatt har den gamle nøkkelen, eller en virtuell maskin gjenopprettet fra et øyeblikksbilde tatt midt i en økt, er nettopp situasjonen grensene finnes for å forhindre. Ingen angriper er nødvendig; vanlige operasjoner er nok.
Hvorfor manuell redigering er feil løsning
Tellere, salter og pakkeidentifikatorer er tilstandsmaskiner som deles av begge ender. Å endre den ene siden desynkroniserer den andre, og tunnelen feiler på måter som ser ut som et ruteproblem. Den støttede spaken er en ny nøkkelutveksling, som nullstiller tilstanden på begge ender samtidig.
Passord og noncer spiller også forskjellige roller. Et passord er hemmelig inngang til nøkkelutledning; en nonce er offentlig inngang per melding. Et profilfelt merket nonce som ber om en lang hemmelighet, er vanligvis en statisk nøkkel eller en forhåndsdelt hemmelighet under et annet navn, så les dokumentasjonen for det feltet i stedet for å anta.
Når et sikkerhetsvarsel gjelder håndtering av nonce, er reparasjonen vedlikeholderens rettede versjon, ikke en annen chiffer eller en kortere nøkkel. Å bytte chiffer for å unngå ordet nonce flytter problemet i stedet for å løse det.
Å lese en advarsel uten å gjette
En logglinje om tellere eller noncer beskriver vanligvis tapt tilstand, ikke et angrep. Sjekk om en motpart er startet på nytt, om en klonet virtuell maskin har gjenbrukt samme identitet, og om de to endene er enige om nøkkelbytteinnstillingene. Etabler deretter en ny økt og se om meldingen kommer tilbake.
Hold diagnosen atskilt fra urelaterte feil. En side som ikke lastes, eller en påloggingsforespørsel som går i løkke, er ikke bevis på nonce-gjenbruk, og å behandle det som det sender deg ned i krypteringslaget når problemet ligger over det.
For vanlig bruk er den trygge regelen kort: la implementasjonen styre noncen, hold begge ender på støttede versjoner, og behandl enhver tilstandsnulstilling som en grunn til å bytte nøkkel i stedet for å redigere en verdi. Hvis et profilfelt ikke står i leverandørens dokumentasjon, ikke finn opp en verdi for det. Reparasjon av tunnelen begynner med å vite hvilket lag du ser på.