Ende-til-ende-kryptering, forklaret for alvor

Hvad kryptering egentlig betyder

At kryptere en besked betyder at transformere den til noget, der ligner støj for enhver, der ikke besidder en bestemt information kaldet en nøgle. Operationen udføres på afsenderens enhed og føres tilbage på modtagerens enhed med den korrekte nøgle. Imellem de to rejser beskeden som en række bytes uden tilsyneladende betydning. Det er den enkle idé. Resten af artiklen beskæftiger sig med de nuancer, der alt efter tilfældet gør den til en reel garanti eller et marketingmærkat.

Adjektivet end-to-end (fra ende til anden) — forkortet E2EE — tilføjer en præcisering. Krypteringen udføres ikke for, at en mellemliggende server kan læse og levere den. Den udføres, så kun de to ender, afsenderens og modtagerens enhed, har nøglen. Enhver server, beskeden passerer igennem, ser støjen, ikke beskeden. Det er den tekniske forskel fra kryptering undervejs (in transit), hvor indholdet rejser krypteret fra en server til den næste, men hver server, den passerer, dekrypterer den for at videresende den og derved midlertidigt genskaber klarteksten.

Paradokset om den delte hemmelighed

Der er et indlysende problem. For at to personer kan kryptere og dekryptere beskeder indbyrdes, har de begge brug for den samme nøgle. Men hvordan bliver de enige om denne nøgle, hvis alt, hvad de sender til hinanden, per definition passerer gennem en kanal, hvor nogen kan lytte med? At aftale nøglen i den samme kanal, som de senere skal bruge den i, virker umuligt: hvis angriberen hører den ved aftalen, vil vedkommende kunne dekryptere alt efterfølgende. I årtier løste klassisk kryptografi dette på den hårde måde: nøglerne blev overleveret personligt, før de blev taget i brug, ved fysiske møder. Ambassadører bar kufferter med nøgler syet ind i foret på deres frakker.

I moderne e-mail kan denne løsning ikke skaleres. Hvis vi skulle gå fysisk hjem til hver person, som vi havde til hensigt at kommunikere krypteret med, ville vi aldrig komme til at tale med nogen. Spørgsmålet, som kryptografmiljøet stillede for halvtreds år siden, var dette: er det muligt for to personer, der ikke kender hinanden, og som kun deler en offentlig kanal, at aftale en hemmelighed i den samme offentlige kanal, som ingen, der lytter til kanalen, kan kende?

Elegancen i Diffie-Hellman

I 1976 demonstrerede to matematikere ved navn Whitfield Diffie og Martin Hellman noget tilsyneladende umuligt: at to personer, der kun taler via en offentlig kanal — en kanal, hvor alle kan høre alt, hvad de siger — kan blive enige om en hemmelig adgangskode, uden at nogen lytter kan opdage den. Det lyder som magi. Det er det ikke: det er matematik. Diffie-Hellman-nøgleudveksling, som det har været kendt siden da, er grundlaget for praktisk talt al krypteret kommunikation på internettet, og et halvt århundredes intensiv brug og global akademisk granskning bekræfter dets soliditet. Enhver, der ønsker at se den visuelle intuition eller matematikken, kan læse videre. Enhver, der foretrækker at stole på, at det virker, kan også fortsætte uden at miste tråden i artiklen.

For dem, der vil visualisere det, er der en velkendt analogi med farver. Forestil dig, at Alice og Bruno bliver enige om en grundfarve offentligt — lad os sige gul — for øjnene af Eva, der lytter til dem. Hver vælger en anden hemmelig farve privat og blander sin hemmelighed med den gule. Alice får en bestemt orange; Bruno får en bestemt grøn. De udveksler resultaterne for øjnene af Eva. Nu blander hver den modtagne farve med sin egen hemmelighed, og begge når frem til den samme slutfarve, fordi blandingsrækkefølgen ikke betyder noget. Eva har set den gule og de to mellemblandinger, men ikke hemmelighederne; uden en af hemmelighederne kan hun ikke nå frem til slutfarve. Den virkelige matematik erstatter farverne med eksponentieringer i modulære grupper eller elliptiske kurver, men idéen er den samme: den delte hemmelighed opbygges offentligt, uden at nogen i kanalen kan rekonstruere den.

Fra Diffie-Hellman til Signal-protokollen

Ende-til-ende-kryptering, som professionelle beskedapps bruger i dag, hviler næsten uden undtagelse på en elegant og hærdet version af Diffie-Hellman-udvekslingen. Signal-protokollen, designet af Trevor Perrin og Moxie Marlinspike mellem 2013 og 2016, er referencen. Den kombinerer to nøgleidéer. Den første er nøgleudveksling i elliptiske kurver (X25519), som skaber den oprindelige delte hemmelighed mellem to enheder. Den anden er den såkaldte Double Ratchet — dobbelt skralde — som fornyer nøglerne automatisk med hver besked, så kompromittering af enheden i dag ikke tillader dekryptering af tidligere beskeder, eller fremtidige beskeder, når skralden er blevet drejet.

I Zig fylder X25519-udvekslingen, der skaber den delte hemmelighed mellem to enheder, seks linjer ved hjælp af standardbiblioteket:

const std = @import("std");
const X25519 = std.crypto.dh.X25519;

// Alicia y Bruno generan cada uno un par (privada, pública).
const par_alicia = X25519.KeyPair.generate(io);
const par_bruno  = X25519.KeyPair.generate(io);

// Cada parte recibe la clave pública de la otra y deriva el mismo secreto.
const secreto_alicia = X25519.scalarmult(par_alicia.secret_key, par_bruno.public_key) catch unreachable;
const secreto_bruno  = X25519.scalarmult(par_bruno.secret_key,  par_alicia.public_key) catch unreachable;
// secreto_alicia == secreto_bruno  (32 bytes)

Og hvad er der præcist inde i std.crypto.dh.X25519? Ingen skjult magi. Det er to korte funktioner, der kan læses i deres helhed i selve Zigs standardbibliotek. Den første udleder den offentlige nøgle fra den private — udvekslingens «gᵃ»:

pub fn recoverPublicKey(secret_key: [secret_length]u8) IdentityElementError![public_length]u8 {
    const q = try Curve.basePoint.clampedMul(secret_key);
    return q.toBytes();
}

I artiklens sprog: Den private nøgle «ganges» — i elliptisk, ikke elementær aritmetisk forstand — med basispunktet for Curve25519-kurven, og resultatet serialiseres til toogtredive bytes. Operationen clampedMul er den hærdede version af denne skalære multiplikation: Den inkorporerer de sikkerhedsforanstaltninger, som det kryptografiske samfund har tilføjet gennem årene for at modstå kendte familier af angreb. To linjer funktionskrop.

Den anden funktion kombinerer din private nøgle med den offentlige nøgle, som den anden part sender dig. Det er udvekslingens «(gᵇ)ᵃ», der producerer den delte hemmelighed på toogtredive bytes, som ingen af jer nogensinde overførte:

pub fn scalarmult(secret_key: [secret_length]u8, public_key: [public_length]u8) IdentityElementError![shared_length]u8 {
    const q = try Curve.fromBytes(public_key).clampedMul(secret_key);
    return q.toBytes();
}

To linjer mere. Den modtagne offentlige nøgle tolkes som et punkt på kurven og «ganges» med ens egen private nøgle. På grund af den kommutative egenskab ved kurveoperationen — analog til kommutativiteten af multiplikationen af eksponenter, som vi så i det numeriske eksempel — ender begge parter med det samme serialiserede punkt: nøjagtig den delte hemmelighed, som artiklen taler om.

Hvad ende-til-ende-kryptering beskytter

Hvad E2EE beskytter godt, forudsat en korrekt implementering, er indholdet af beskeden under transit. En mellemliggende server, der modtager og videresender de krypterede data, vil se en række uforståelige bytes. En angriber med adgang til kablet, routeren, wifi-adgangspunktet vil se det samme. En tjenesteudbyder, der opbevarer kopier af trafikken, vil ikke kunne læse den efterfølgende. En regering, der beordrer tjenesteoperatøren til at udlevere indholdet, vil modtage de samme uforståelige bytes, som serveren havde i første omgang.

Dette er, i praktiske termer, meget. Det er forskellen på at skrive et brev i en uigennemsigtig konvolut og at skrive det på et postkort. Begge ankommer. Kun den ene bevarer indholdet over for postbuddet.

Hvad ende-til-ende-kryptering ikke beskytter

Det er værd at vide det lige så godt. E2EE beskytter ikke metadata: serveren ved stadig, at bruger A sender data til bruger B, på hvilket tidspunkt, med hvilken frekvens og hvorfra, selvom den ikke ved, hvad der bliver sagt. Disse metadata har vi allerede argumenteret for i Kryptering er ikke at være privat, er ofte mere afslørende end indholdet. At vide, at nogen ringede til et advokatfirma specialiseret i skilsmisser en fredag kl. 22:00 i tredive minutter, fortæller en historie, som indholdet af opkaldet aldrig fortalte. Det er den samme situation som at se en person gå ind og ud af en onkologisk klinik flere gange: man behøver ikke at høre noget af det, der bliver talt om indenfor, for at forestille sig, hvad der sker. Et enkelt metadata-punkt alene betyder måske ingenting; flere krydsrefererede tegner noget, der minder alt for meget om sandheden. E2EE beskytter ikke endepunkterne: hvis modtagerens enhed er kompromitteret af et ondsindet program, dekrypteres beskeden normalt for den modtager, og det ondsindede program læser den. E2EE beskytter ikke mod samtalepartnerens identitet i sig selv: hvis Alice tror, hun taler med Bruno, men en angriber har indskudt sig i starten (en man in the middle), og protokollen ikke inkluderer uafhængig verificering, ender de to parter med at tale med den indtrængende i den tro, at de taler med hinanden.

Der er en fjerde ting, der bør formuleres uden tvetydighed. E2EE forhindrer ikke en udbyder, der påstår at tilbyde det, i også at gemme en kopi af den ukrypterede besked i sine egne systemer. Påstanden "mine beskeder er ende-til-ende-krypterede" og påstanden "udbyderen gemmer ikke mit indhold" er ikke den samme. En app kan opfylde den første, mens den overtræder den anden; vi har set det i avisoverskrifter gentagne gange siden 2018. Brugeren har, medmindre klientens kode er verificerbar, ingen teknisk måde at skelne det ene tilfælde fra det andet uden ekspertundersøgelse. Det mest kendte tilfælde i den brede offentlighed: WhatsApp krypterer beskeder ende-til-ende under transit, men hvis brugeren aktiverer backup i iCloud eller Google Drive uden yderligere kryptering, gemmes den kopi læsbart i en tredjeparts infrastruktur, og krypteringen brydes i brugerens egen ende.

Spørgsmålet, operatøren ikke ønsker at høre

En app, der påstår at kryptere ende-til-ende, kan teknisk set gøre én af tre ting med hensyn til nøglerne:

1. Nøglerne findes kun på enhederne. De genereres og findes udelukkende på brugernes enheder; operatøren kender dem ikke og gemmer dem ikke. Det er det optimale tilfælde.
2. Operatøren kan få adgang, hvis de vil. Operatøren har brugernes nøgler (eller kan generere dem efter behag) og gemmer dem i sine databaser. Hvis de vil, eller tvinges til det, kan de læse indholdet. Dette er tilfældet for de fleste ”cloud”-tjenester.
3. Operatøren kan ikke få adgang ved design, men kontrollerer adgangen. Operatøren har ikke nøglerne, men har kontrol over den app, der genererer dem. Hvis de tvinges til det, kan de sende en ondsindet opdatering, der opsnapper nøglerne eller indholdet før kryptering. Dette er tilfældet for mange kommercielle E2EE-tjenester.

Det operationelle spørgsmål for den professionelle er, hvor nøglerne befinder sig, hvem der kontrollerer dem, og hvad der ville ske, hvis der i morgen ankom en retskendelse til operatøren, der anmodede om at dekryptere mine samtaler — ikke om udbyderen hævder at kryptere end-to-end. De tre svar på dette spørgsmål er fuldstændig forskellige, selvom de tre applikationer præsenterer sig selv i deres reklamer med den samme etiket.

Konvolutten og den anden nøgle

Den uigennemsigtige konvolut løser postbudets problem: ingen, der opfanger den på vejen, kan læse dens indhold. Den løser ikke et andet problem: hvem ellers der opbevarer en kopi af nøglen, og under hvilket diskret navn — kontogendannelse, sikkerhedskopi, synkronisering mellem enheder — denne kopi gemmes. De tre arkitekturer, der er beskrevet ovenfor, bruger den samme konvolut og lover det samme i deres markedsføring; hvad de gør med den anden nøgle, er præcis, hvad etiketten ikke fortæller.

En lukket konvolut med en kopi af nøglen gemt i en anden skuffe er i praksis en åben konvolut.

---

Ende-til-ende-kryptering, når det er gjort rigtigt, er en af de fineste konstruktioner, som moderne kryptografi har leveret til daglig praksis. Den oprindelige idé — at to personer kan blive enige om en hemmelighed via en offentlig kanal — tilhører Whitfield Diffie og Martin Hellman, 1976; et halvt århundrede senere lever vi stadig i konsekvensen af den. Men som med ethvert teknisk løfte afhænger dets værdi af reel overholdelse, ikke af mærkaten. Den ærlige fagpersons spørgsmål er ikke "er det krypteret?", men "hvem har nøglerne?". Svarene har forskellige konsekvenser. Det er værd at kende dem.