Definition og idéen bag
Diffie-Hellman key exchange (DH) er en metode, hvor to parter kan blive enige om en fælles hemmelig værdi over en kanal, som en tredjepart kan lytte på. Pointen er, at parterne ikke behøver at sende selve den fælles hemmelighed direkte. I stedet kombinerer de deres egne hemmelige bidrag med offentlige oplysninger, og derefter kan de hver især beregne den samme fælles nøgle lokalt.
Det betyder samtidig en vigtig afgrænsning: DH i sig selv handler primært om nøgleetablering. Det løser ikke automatisk problemet med at bevise, at modparten faktisk er den, man tror, man har kontakt til.
Et simpelt model: offentlige tal og hemmelige bidrag
Tænk på DH som et “matematisk håndtryk”. Begge parter kender et fælles sæt offentlige parametre (for eksempel et matematisk grundlag og en gruppe). Derudover vælger hver part en privat hemmelig værdi.
- Part A vælger en hemmelig værdi og beregner et offentligt resultat ud fra den.
- Part B vælger en hemmelig værdi og beregner et offentligt resultat ud fra den.
- A sender sit offentlige resultat, B sender sit offentlige resultat.
- A bruger B’s offentlige resultat sammen med sin egen hemmelige værdi til at beregne den fælles hemmelighed.
- B bruger A’s offentlige resultat sammen med sin egen hemmelige værdi til at beregne den samme fælles hemmelighed.
Hvis tredjeparten kun kan se de offentlige værdier, er den praktiske sikkerhed afhængig af, at det er svært at udlede de private værdier eller den fælles hemmelighed ud fra de offentlige oplysninger. Hvilke matematiske antagelser og parametre der er involveret, afhænger af den konkrete DH-variant.
Hvad der gør den “sikker” – og hvorfor autentifikation betyder noget
DH kan gøre det svært for en passiv lytter at genskabe den fælles hemmelighed, hvis der bruges robust matematik og passende parametre/algoritmer. Men “svært at beregne hemmeligheden” er ikke det samme som “sikkert mod at blive narret”.
Den klassiske begrænsning er, at hvis parterne ikke kan autentificere hinanden, kan en aktiv angriber forsøge at udnytte det. I et angrebsmønster kan en angriber etablere to separate nøgleetableringer: én med A og én med B, og derefter relay’e/omlægge kommunikationen, så A tror, at nøglen kommer fra B, mens den i virkeligheden kommer fra angriberen (og omvendt for B).
Derfor er autentifikation en central “diffentie-Hellman-grænse”: Når DH bruges i praksis, kobles det typisk sammen med en mekanisme, der kan bekræfte identiteten eller integriteten af den nøgle, der forhandles. Ellers risikerer man, at fortrolighed ikke hjælper mod manipulation af hvem man taler med.
Forskelle og grænser: hvad DH er god til, og hvad det ikke dækker
DH kan give en fælles hemmelighed uden at sende den direkte, hvilket ofte forbindes med bedre modstand mod “optaget trafik” end metoder, hvor samme nøgle genbruges i lang tid. Men DH’s sikkerhed afhænger af flere faktorer, som ikke altid er synlige for en læser, der kun ser den overordnede idé.
Relevante grænser at kende:
- Autentifikation mangler som standardidé: DH alene adresserer ikke identitetsspoofing.
- Parametre og valg af algoritme betyder noget: Nogle opsætninger kan være svagere end andre, og sikkerheden kan falde, hvis man vælger dårlige parametre eller ældre varianter.
- Aktive angreb kan kræve mere end nøgleetablering: Hvis der ikke er beskyttelse mod manipulation af forhandlingens data, kan angriberen påvirke kommunikationen.
Den praktiske takeaway er at skelne mellem “hemmelighed etableres” og “parterne er ægte, og kommunikationen er integritetsbeskyttet”. De kan hænge sammen i en hel protokol, men de er ikke identiske.
Praktisk brug og kontrolpunkter
Hvis du vil forstå, hvordan DH påvirker sikkerheden i en konkret sammenhæng, kan du tjekke følgende, uden at det kræver dyb kryptografi:
- Er der autentifikation i løsningen? Hvis der ikke er en måde at bekræfte, hvem modparten er, er der en kendt begrænsning ved ren nøgleetablering.
- Hvilken variant og hvilke parametre bruges? Robusthed afhænger af, at den valgte DH-opsætning er passende. Hvis dokumentationen taler om sikre valg og fraråder ældre varianter, er det typisk et godt tegn.
- Bliver nøgleafledte værdier brugt til at beskytte både fortrolighed og integritet? Selv hvis en fælles hemmelighed dannes korrekt, er det relevant, om protokollen også beskytter mod ændringer undervejs.
- Er implementeringen moderne og konsistent? Kryptografiske løsninger er sjældent sikre “kun fordi de hedder DH”; det er samspillet mellem komponenter, der bestemmer niveauet.
Hvis din interesse er at placere emnet korrekt: DH er primært en metode til at etablere en fælles hemmelighed over en offentlig kanal. Den reelle sikkerhedsværdi kommer, når den indgår i en samlet løsning med autentifikation og integritetsbeskyttelse. Uden de omkringliggende mekanismer ændrer trusselsbilledet sig, og begrænsningerne bliver tydeligere.