IKEv1 mot IKEv2 med forhåndsdelt nøkkel: hva som skiller autentiseringen

To gateways med samme forhåndsdelte nøkkel fullfører en håndtrykkutveksling, og en pakkefangst viser ingen hemmelighet som går over linjen. Det er den delen folk husker. Den interessante delen er hva hver versjon faktisk regner ut for å bevise at hemmeligheten er kjent, fordi IKEv1 og IKEv2 bygger beviset fra ulike inndata og avdekker ulik informasjon mens de gjør det. Les de to sporene side om side, og forskjellen slutter å være kosmetisk.

Hva beviset må oppnå

Diffie-Hellman gir begge parter en felles verdi der alle som ser på også kan regne ut de offentlige halvdelene. I seg selv beviser det ingenting om identitet: en angriper som fullfører en nøkkelutveksling har samme felles verdi som gatewayen din. Autentiseringstrinnet finnes for å binde utvekslingen til en hemmelighet som bare de tiltenkte partene har, og til identitetene og parameterne de ble enige om.

Den bindingen er grunnen til at hashen dekker mer enn nøkkelen. Dekket den bare hemmeligheten, kunne en angriper spille den av i en annen utveksling med andre identiteter eller forslag.

IKEv1 Main Mode: utled SKEYID og bevis den

Main Mode kjører seks meldinger. Det første paret forhandler sikkerhetsassosiasjonen, det andre utveksler offentlige Diffie-Hellman-verdier og nonces, og det tredje bærer identiteter plus autentiseringshasher under krypteringen som nettopp ble etablert. RFC 2409 definerer konstruksjonen: med forhåndsdelt nøkkel utledes SKEYID fra hemmeligheten og begge noncene, og det senere nøkkelmaterialet fra SKEYID, Diffie-Hellman-verdien, cookiene og konstanter.

Hashen i melding fem og seks beregnes over Diffie-Hellman-verdien, de to cookiene, forslaget og avsenderens identitet, med SKEYID som nøkkel. Mottakeren regner den ut på nytt med sin egen konfigurerte hemmelighet. Et avvik avslutter utvekslingen, og hemmeligheten er aldri en nyttelast.

Aggressive Mode presser samme arbeid ned i tre meldinger, noe som betyr at identiteter og autentiseringshash reiser før det finnes en kryptert kanal. Det er en reell eksponering for en gjettbar hemmelighet, og det er atskilt fra spørsmålet om hemmeligheten ble sendt. IKEv1 er avviklet av RFC 9395, så et gammelt spor er en diagnostisk øvelse og ikke et utrullingsmål.

IKEv2: en annen utledning og en annen AUTH-nyttelast

IKEv2 gjenbruker ikke nøkkelskjemaet fra IKEv1. De første IKE-nøklene kommer fra et seed bygget av noncene og Diffie-Hellman-verdien, og barnesikkerhetsassosiasjonene utledes derfra. Den forhåndsdelte nøkkelen mater ikke seedet i det hele tatt.

Autentiseringen vises så som en AUTH-nyttelast. For nøkkelautentisering angir RFC 7296 en paddet form av hemmeligheten, laget ved å hashe hemmeligheten med den faste strengen Key Pad for IKEv2, og deretter hashe de signerte utvekslingsdataene og identiteten med den paddede nøkkelen. Verifisereren kan bygge samme verdi på nytt; en observatør kan ikke, uten hemmeligheten.

Legg merke til hva som endret seg. I IKEv1 er hemmeligheten bakt inn i nøkkelskjemaet før autentiseringshashen finnes; i IKEv2 er nøkkelskjemaet uavhengig av hemmeligheten, og beviset er en egen nyttelast knyttet til de signerte oktettene. Samme begrepsmessige garanti, annet maskineri, og derfor mapper parameternavn og fangster ikke en til en.

Hva en observatør faktisk lærer

Offentlige Diffie-Hellman-verdier, forslag, nonces og cookies er synlige i begge versjoner. Identiteter er synlige i IKEv1 Aggressive Mode og beskyttet i de andre tilfellene. Hemmeligheten er aldri synlig.

Den siste setningen har en grense som er verdt å si. En svak, menneskevalgt hemmelighet kan angripes ved gjetting: angriperen regner ut hva autentiseringsverdien ville vært for en kandidat og sammenligner. IKEv1 Aggressive Mode gjør dette billigst fordi beviset står i klartekst, og standardene advarer generelt mot hemmeligheter med lav entropi. Å aldri sende hemmeligheten er ikke det samme som å gjøre en dårlig hemmelighet trygg.

Hva du gjør med sammenligningen

Bruk én unik hemmelighet per partspar, generer den fra en tilfeldig kilde og roter den gjennom samme provisjoneringsvei som distribuerte den. Hvis hemmeligheten ligger i en konfigurasjonsmal som sendes til hver filial, er et kompromiss på ett sted et kompromiss overalt.

Foretrekk sertifikatbasert autentisering der driftskostnaden er akseptabel, siden den fjerner gjetterproblemet med den delte hemmeligheten og gir hver part en egen identitet. Der en forhåndsdelt nøkkel blir værende, hold den lang, begrens omfanget og behandle IKE-versjonen som en sikkerhetsbeslutning, ikke en interoperabilitetsdetalj.