Hvad er Diffie-Hellman?

Diffie-Hellman er en kryptografisk metode, der lader to parter oprette en fælles hemmelig nøgle, selv om de kommunikerer over en kanal, hvor en tredjepart kan lytte med. Idéen er, at parterne først udveksler offentlige værdier, og derefter bruger deres egne private værdier sammen med de offentlige værdier til at beregne den samme fælles hemmelighed.

Det vigtige er, at Diffie-Hellman primært løser nøgleudveksling. Den sørger ikke automatisk for, at du taler med den rigtige modpart, og den giver dermed ikke i sig selv “sikkerhed” mod alle typer angreb.

Grundidéen: offentlige oplysninger og private valg

Typisk foregår Diffie-Hellman ved, at begge parter vælger en privat hemmelig (en hemmelig eksponent eller tilsvarende privat nøglemateriale). Ud fra den private værdi beregnes en offentlig nøglekomponent, som sendes til den anden part. Når hver part modtager den andens offentlige komponent, kombinerer den sin egen private hemmelighed med den modtagne offentlige komponent for at udlede den fælles hemmelighed.

Angriberen kan ofte se de offentlige komponenter, fordi de sendes i klartekst. Men for at udlede den fælles hemmelighed kræves der adgang til den private hemmelighed (eller en sammenlignelig evne til at “omvende” den underliggende matematik). Hvilket angrebsmønster der teoretisk og praktisk er realistisk afhænger af den konkrete udgave og parametrene.

Bemærk: Der findes flere varianter (for eksempel klassisk eksponentiel Diffie-Hellman vs. elliptiske kurver i “Elliptic Curve Diffie-Hellman” som en almindelig variant i moderne systemer). Den generelle logik—privatvalg, offentlige komponenter, fælles beregning—er den samme, men sikkerhed og ydeevne afhænger af den konkrete variant.

Hvad Diffie-Hellman bruges til i praksis

Diffie-Hellman indgår ofte i protokoller, hvor parter skal etablere en sessionsnøgle til senere kryptering og/eller integritet. I sådanne opsætninger bliver den fælles hemmelighed typisk brugt som input til yderligere nøgleafledning (key derivation), som frembringer de konkrete nøgler til kryptering og integritetsbeskyttelse.

Derfor skal Diffie-Hellman ses som et byggesten til “nøgleetablering” snarere end som hele sikkerhedsløsningen. Den samlede beskyttelse afhænger af resten af protokollen: hvordan nøgler afledes, hvordan der verificeres, at modparten er rigtig, og hvordan data beskyttes efter nøgleetableringen.

En praktisk konsekvens for forståelse er: Selv hvis Diffie-Hellman i sig selv kan hjælpe med at skjule den fælles hemmelighed mod en passiv lytter, skal der stadig være en mekanisme til at forhindre aktiv indgriben.

Den vigtigste begrænsning: ingen indbygget identitetsgaranti

Den mest kendte begrænsning er, at Diffie-Hellman i sin grundform ikke automatisk beskytter mod en “man-in-the-middle”-situation. Hvis en angriber kan placere sig mellem de to parter, kan angriberen etablere separate fælles hemmeligheder med hver part og derefter videresende krypteret trafik mellem dem—uden nødvendigvis at kunne afsløre indholdet, men ofte med mulighed for at påvirke forbindelsen.

For at modvirke det kræves der autentificering, for eksempel ved at parterne kan verificere hinandens identitet eller en nøgle på en måde, der ikke selv kan manipuleres i forbindelsesforløbet. Hvordan den autentificering laves, afhænger af protokoldesignet.

Hvis autentificering mangler eller er svag, kan den realistiske sikkerhedsgevinst blive mindre, end man umiddelbart tror ud fra “hemmeligheden er ikke sendt”. Det er altså ikke kun nøgleudvekslingen, men helheden i protokollen, der afgør risikoniveauet.

Forskelle og nøglevalg: hvad kan påvirke sikkerheden

Sikkerheden ved Diffie-Hellman bygger på antagelser om, at bestemte beregningsproblemer er svære for en angriber. I praksis handler det blandt andet om:

  • Hvilken matematisk konstruktion der bruges (klassisk vs. elliptisk kurve).
  • Hvilke parametre der vælges (for eksempel størrelser, kurvevalg eller gruppevalg).
  • Om private hemmeligheder håndteres korrekt (tilfældighed, genbrug og implementeringsdetaljer).

Da ingen artikel kan dække alle konkrete protokoller og implementeringer fuldt, bør du vurdere sikkerheden ud fra det system, du faktisk bruger: protokolens version, hvordan den autentificerer, og hvordan nøglematerialet afledes og forvaltes.

Kontrolpunkter: sådan kan du selv tjekke om brugen er robust

Du kan gøre din vurdering mere konkret med få, målbare kontrolpunkter:

  1. Er der autentificering? Hvis der ikke er en måde at verificere modpartens identitet eller nøgle, kan “man-in-the-middle” være et reelt problem.

  2. Hvilken Diffie-Hellman-variant og parametre bruges? Find ud af om det er en elliptisk kurve-variant eller en klassisk variant, og om der er angivet passende parametre i konfigurationen.

  3. Hvordan afledes sessionsnøglen? Se efter om den fælles hemmelighed bruges gennem en nøgleafledningsfunktion (ofte for at opnå stærke, separate nøgler til forskellige formål).

  4. Er implementeringen opdateret og korrekt? Selv robuste kryptografiske idéer kan svækkes af implementeringsfejl eller dårlige tilfældigheds-/nøglehåndteringsvalg.

Hvis disse kontrolpunkter ikke kan besvares ud fra dokumentation eller konfigurationsdata, bør du behandle sikkerhedsvurderingen som mere usikker—fordi Diffie-Hellman alene ikke garanterer end-to-end beskyttelse.