Hvad er Diffie-Hellman, og hvorfor handler det om identitet

Diffie-Hellman key exchange er en metode, hvor to parter kan etablere en fælles hemmelig nøgle over en kanal, som en tredjepart kan observere. Selve pointen er, at nøglen ikke behøver sendes direkte. Det er derfor relevant for identitetsbeskyttelse i den forstand, at den der etablerer nøglen ofte bruger den til efterfølgende kryptering og beskyttelse af fortrolighed.

Det er dog vigtigt at skelne mellem to ting:

  1. At modparten ikke kan læse indholdet (fortrolighed).
  2. At du sikkert ved, hvem modparten faktisk er (autentifikation).

Diffie-Hellman i sig selv fokuserer primært på punkt 1. Hvis du ikke har autentifikation, kan en angriber i praksis kunne påvirke, hvem der “kommunikerer med hvem”, selv om indholdet er krypteret. Det påvirker identitetens sikkerhed indirekte: kryptering beskytter mod læsning, men kan stadig give et falsk billede af, at du taler med den rigtige part.

En simpel model af nøgleudvekslingen

Forestil dig et møde mellem Part A og Part B, hvor begge gerne vil bruge samme hemmelige nøgle til senere kryptering. Ved Diffie-Hellman aftaler de i udgangspunktet offentlig viden om bestemte matematiske parametre (fx valg af gruppe/primtal), og derefter:

  • A vælger en privat hemmelig værdi og beregner en offentlig værdi ud fra den.
  • B vælger en privat hemmelig værdi og beregner en offentlig værdi.
  • A sender sin offentlige værdi til B, og B sender sin offentlige værdi til A.
  • Når A modtager B’s offentlige værdi, kan A udlede den fælles hemmelighed ved hjælp af sin egen private værdi.
  • Tilsvarende kan B udlede den samme fælles hemmelighed.

Hvis en tredjepart kun ser de offentlige værdier, burde den ikke kunne beregne den fælles hemmelighed uden at kunne “gætte” eller beregne de private værdier. Derfor kan kommunikation efterfølgende beskyttes med symmetrisk kryptering, hvor begge parter bruger den samme afledte nøgle.

Hvad Diffie-Hellman ikke gør af sig selv

Den centrale begrænsning er autentifikation. Uden at have en mekanisme, der binder “offentlig nøgle” til “rigtig identitet”, kan Diffie-Hellman blive udnyttet i en man-in-the-middle-situation.

I en sådan situation kan en aktiv angriber indsætte sig mellem A og B og etablere to separate nøgleaftaler: én med A og én med B. Resultatet kan være, at A krypterer til angriberen, og angriberen videresender krypteret til B. Rent indholdsmæssigt kan kommunikationen stadig fremstå beskyttet mod direkte aflæsning, men du har ikke reelt fået den identitetsgaranti, du troede.

Det er derfor en fejl at vurdere “identitetsbeskyttelse” alene ud fra, at Diffie-Hellman er til stede. For at identiteten skal beskyttes meningsfuldt, skal nøgleudvekslingen kobles til autentifikation, fx via certificater eller anden verifikation, som gør det vanskeligere for en tredjepart at udgive sig for en af parterne.

Forskelle og grænser: passiv vs. aktiv angreb

Det hjælper at tænke på trusselsmodel:

  • Ved passive angreb (kun overvågning) kan Diffie-Hellman være stærkt, fordi angriberen får offentlige værdier, men ikke den private hemmelighed.
  • Ved aktive angreb (indgreb, ombytning, videresendelse) kræver du typisk autentifikation og integritetsbeskyttelse, så modparten kan opdage, at noget er ændret.

Derudover afhænger sikkerheden af, at systemet bruger passende parametre og en korrekt, moderne implementering. Hvis nøgleaftalen eller parametervalg er svagt, kan den matematiske antagelse bag sikkerheden svækkes. Da konkrete detaljer afhænger af den konkrete protokol og opsætning, er det bedst at holde sig til princippet: sikkerheden er ikke “garanteret” af Diffie-Hellman alene, men af den samlede løsning.

Sådan kan du kontrollere, om det hjælper din identitetsbeskyttelse

Du kan teste forståelsen ved at kigge efter, om din anvendelse af krypteret kommunikation faktisk adresserer både “fortrolighed” og “identitet”. Konkret:

  1. Er der en autentifikationsmekanisme, der knytter modpartens offentlighed til en forventet identitet?

    • Hvis ja: Diffie-Hellman kan bidrage til, at nøgler ikke lækkes direkte, samtidig med at du har en rimelig garanti for, hvem der er i den anden ende.
    • Hvis nej: du får primært fortrolighed, og identiteten kan stadig være sårbar over for manipulerede forbindelser.

  2. Er der signaler om integritetsbeskyttelse?

    • Moderne protokoller bruger ofte integritetskontroller/AEAD-løsninger, så ændringer i trafikken opdages.

  3. Bruges der moderne nøgleaftalevarianter og parametre?

    • Du bør være opmærksom på, om systemet bruger ældre eller svage varianter. Her er den praktiske tommelfingerregel: opdaterede protokoller og biblioteker er typisk mindre tilbøjelige til kendte svagheder.

Hvis du vil vurdere en konkret situation, er det nyttigt at spørge: “Kan jeg rimeligt tro, at protokollen gør identiteten verificerbar, ikke kun hemmeligholder data?” Diffie-Hellman svarer primært på den sidste del.

Konkrete faldgruber at være opmærksom på

Selv med Diffie-Hellman kan følgende problemer opstå, hvis helheden ikke er korrekt sat sammen:

  • Forventet identitet bliver ikke verficeret, så du kan blive ført til en anden modpart.
  • Implementeringen kan have fejl, så den matematiske styrke ikke realiseres i praksis.
  • Brug af forældede indstillinger kan gøre nøgleafledningen mindre robust.

Det bedste udgangspunkt er derfor ikke at betragte Diffie-Hellman som en “identitetslås”, men som en byggesten for nøgleetablering, der bliver identitetsrelevant først, når den kombineres med autentifikation og integritetsbeskyttelse.