Principper for sikkert protokoldesign

Sikkert protokoldesign antager en modstander, der har fuld kontrol over netværket. Dolev-Yao-modellen (1983) specificerer, at modstanderen kan opsnappe, læse, forsinke, genafspille, slette og ændre enhver meddelelse under transport. Modstanderen kan generere meddelelser, der ikke kan skelnes fra meddelelser fra legitime parter. Modstanderen kan sammensætte nye meddelelser ud fra kendte meddelelseskomponenter. Modstanderen kan ikke bryde kryptografiske primitiver (dekryptere uden nøglen eller forfalske signaturer). Det afgørende er, at modstanderen er beregningsmæssigt begrænset — kan køre i polynomiel tid — men har kontrol over alle kommunikationskanaler. Protokolsikkerhed betyder, at man opnår autentifikations- og hemmeligholdelsesmål selv over for denne stærke modstander og kun er afhængig af de underliggende primitivers beregningsmæssige sværhedsgrad.

Abadi og Needham (1994) sammenfattede praktiske erfaringer med protokoldesign i en række principper. (1) Enhver meddelelse skal angive, hvad den betyder: Fortolkningen af en meddelelse skal være selvstændig og må ikke afhænge af konteksten. (2) Betingelserne for, at en part må handle, skal angives eksplicit i protokollen. (3) Hvis en parts identitet er vigtig, skal den angives eksplicit i meddelelsen. (4) Vær tydelig om, hvorfor kryptering bruges: Kryptering giver fortrolighed, mens signering giver autentifikation — brug ikke kryptering som erstatning for signering. (5) En meddelelse skal krypteres på det protokollag, hvor dens hemmeligholdelse er nødvendig. Disse principper forebyggede mange fejl af NS-typen.

Friskhedsmekanismer sikrer, at en modtaget meddelelse er genereret for nylig og ikke genafspillet fra en gammel session. Der er to tilgange: (1) Nonces (tal, der kun bruges ÉN GANG) — en udfordring-svar-udveksling, hvor modtageren sender en tilfældig værdi og forventer, at den gentages i svaret. Svaret skal indeholde den nonce, krypteret eller signeret, så en tidligere optagelse ikke kan opfylde udfordringen. (2) Tidsstempler — begge parter inkluderer det aktuelle klokkeslæt, og en meddelelse med et forældet tidsstempel afvises. Tidsstempler kræver synkroniserede ure (Kerberos tillader en tidsforskydning på 5 minutter). Nonces foretrækkes, når synkronisering af urene ikke er mulig, mens tidsstempler forenkler tilstandsløs verificering.

Brug af den samme kryptografiske nøgle til flere formål skaber farlige samspil. Hvis en nøgle K bruges til både kryptering og autentifikation, kan en modstander sende manipulerede kryptogrammer til autentifikationsmekanismen for at udlede oplysninger. TLS 1.3 undgår dette konsekvent via HKDF-Expand-Label med særskilte labels for hver afledt nøgle: "c hs traffic" (klienthåndtryk), "s hs traffic" (serverhåndtryk), "c ap traffic" (klientapplikation). Selv hvis håndtryksnøglen kompromitteres, forbliver applikationsnøgler, der er afledt fra en anden HKDF-gren, sikre. Protokoldesign skal kontrollere hver nøgle for risici ved flergangsbrug og aflede separate nøgler til separate formål.

Autentifikationsoplysninger skal være knyttet til den specifikke session, de bruges i. Uden denne tilknytning kan oplysninger, der er indhentet i én session, afspilles i en anden. Teknikker: (1) Inkludér sessionsidentifikatorer i signerede eller MAC-beskyttede data. (2) Inkludér DH-protokoltransskriptet i signaturen (STS-tilgangen). (3) Brug den HKDF-afledte sessionsnøgle til en MAC på identiteten (SIGMA-tilgangen). TLS 1.3 Finished-meddelelsen: MAC(server_finished_key, transcript_hash) — MAC'en dækker hele protokoltransskriptet, så det mislykkes at afspille en Finished-meddelelse fra en anden session. Det er denne tilknytning, der forhindrer angreb på tværs af sessioner som dem, der blev fundet i tidlige Kerberos- og NS-varianter.

Protokoller bør kun videregive de mindst mulige oplysninger, der er nødvendige for deres funktion. Afslør kun identiteter for dem, der har brug for dem. Inkludér ikke certifikatserienumre eller identifikatorer, der gør det muligt at forbinde sessioner med identiteter, medmindre det er nødvendigt. TLS 1.3 krypterer servercertifikatet (i modsætning til TLS 1.2, hvor det sendes i klartekst), hvilket reducerer den passive aflytters informationsgrundlag. ESNI (krypteret SNI, nu ECH — krypteret ClientHello) krypterer servernavneangivelsen for at skjule, hvilken server klienten opretter forbindelse til. Minimal videregivelse af oplysninger er også et princip ved udformning af tokens: JWT-felter bør kun indeholde det, der er nødvendigt for autorisation, ikke fuldstændige identitetsregistre.

Versionsforhandling er en almindelig angrebsflade: En modstander fjerner eller ændrer ClientHello for at tvinge begge parter til at bruge en ældre og svagere protokolversion. Forsvar: (1) Autentificeret versionsforhandling — inkludér den forhandlede version i det signerede protokoltransskript (TLS Finished dækker ClientHello inklusive versionen). (2) Nedgraderingsmarkører — TLS 1.3 sætter magiske bytes i ServerHello.Random ved nedgradering til TLS 1.2, så klienten kan opdage nedgraderingen. (3) Forebyggelse af versionsintolerance — servere skal afvise fejlformede ClientHello-meddelelser uden lydløst at vælge en ældre version. (4) SCSV — TLS_FALLBACK_SCSV signalerer til serveren, at klienten prøver igen med en lavere version, så serveren kan afvise uberettigede tilbagefald.

Protokolmeddelelser bør være forankret fra den første udveksling. Ikke-manipulerbarhed betyder, at en modstander ikke kan ændre en chiffertekst eller signatur og få den godkendt i en anden kontekst. AEAD giver ikke-manipulerbarhed for chiffertekst — enhver ændring gør autentifikationstagget ugyldigt. På protokolniveau sikrer hashing af protokoltransskriptet, at Finished-udvekslingen i slutningen af et håndtryk forankrer hver eneste sendte meddelelse. Det forhindrer klip-og-sæt-angreb: Meddelelser fra to forskellige sessioner kan ikke flettes sammen, så der opstår en gyldig Finished-værdi for nogen af sessionerne. Forankringsordninger (hashbaserede forankringer) udvider dette til protokolf​​orløb, der kræver forankring på forhånd inden afsløring.

Komplekse protokoller fejler ofte ved grænserne mellem tilstande. Hvis en tilstandsoverg​​ang er tvetydig — hvad sker der, hvis meddelelse 3 ankommer før meddelelse 2? Hvad hvis der ankommer en uventet meddelelsestype? — kan implementeringer udvikle sig forskelligt og skabe uoverensstemmelser, som en modstander kan udnytte. Protokolspecifikationer skal definere: den komplette tilstandsmaskine (alle tilstande og gyldige overgange), adfærden ved uventede inddata (afvisning med en specifik fejl eller lydløs ignorering), tidsudløb og grænser for genudsendelser samt oprydning af sessioner. SSL/TLS var historisk plaget af forskelle mellem implementeringernes tilstandsmaskiner — CVE-2014-0160 (Heartbleed) var grundlæggende en fejl i tilstandsmaskinen, hvor en heartbeat-anmodning blev behandlet i en tilstand, hvor hukommelsen ikke var begrænset korrekt.

Kryptografiske protokoller bruges sjældent alene. En AKE-protokol opretter en sessionsnøgle, som derefter bruges af en protokol på applikationslaget. Hvis AKE-protokollen og applikationsprotokollen udformes uafhængigt af hinanden uden hensyn til komponerbarhed, kan deres samspil svække sikkerheden. Universal Composability-rammeværket (UC) (Canetti, 2001) giver en stringent model for protokolsammensætning: En protokol er UC-sikker, hvis den forbliver sikker, når den sammensættes vilkårligt med andre UC-sikre protokoller. TLS 1.3, Signal og Noise sigter mod komponerbar sikkerhed. I praksis bør du bruge kanalbinding (eksportér protokoltransskriptets hash) til at knytte AKE-sessionen til efterfølgende applikationsautentifikation, så videresendelse af legitimationsoplysninger mellem sessioner, der er oprettet af den samme AKE-protokol, forhindres.

Protokoludviklere begår igen og igen de samme kategorier af fejl. (1) Selvbygget kryptografi: implementering af egne blokchifre, MAC'er eller nøgleafledningsfunktioner uden fagfællekontrol. (2) Implicit tillid: antagelse af en meddelelseskilde ud fra netværkskonteksten i stedet for kryptografisk bevis. (3) Valgfri sikkerhed: gør kryptering eller autentifikation konfigurerbar, hvilket uundgåeligt fører til nedgradering. (4) Langlivede tokens uden tilbagekaldelse: udstedelse af JWT'er eller sessionsnøgler med lang levetid og uden en tilbagekaldelsesmekanisme. (5) Ignorering af fejlkanalen: Hvis fejlmeddelelser ikke autentificeres, kan en modstander indsætte fejl for at påvirke protokollens adfærd. (6) Brug af kryptering til autentifikation: Kryptering af data autentificerer ikke kilden uden en MAC eller signatur.

Sikker protokoludformning bygger på etablerede principper: Dolev-Yao-angribernmodellen (en modstander, der kontrollerer netværket), Abadi-Needham-principperne (eksplicit identitet og selvstændige meddelelser), friskhed via nonces eller tidsstempler, nøgleadskillelse via HKDF med forskellige etiketter, tilknytning af autentifikationsoplysninger til sessioner, minimal videregivelse af oplysninger, forebyggelse af nedgradering via autentifikation af protokoltransskriptet, ikke-manipulerbarhed gennem AEAD og hashing af protokoltransskriptet, tydelige tilstandsmaskiner med defineret fejlhåndtering samt komponerbarhed via sikkerhedsbeviser i UC-modellen. Overtrædelser af disse principper er årsag til næsten alle kendte kryptografiske sårbarheder på protokolniveau.