Hvorfor skal jeg bruke godkjent kryptering i stedet for bare kryptering?

Den avgjørende forskjellen mellom vanlig kryptering og autentisert kryptering (AE) er det AE i tillegg provi des autentisitet, mens ren kryptering bare gir konfidensialitet. La oss undersøke disse to forestillingene i detalj.

I den videre teksten antar vi at $ K $ er en hemmelig nøkkel, som er kjent til autoriserte parter, men ukjent for angripere.

Mål

Konfidensialitet (personvern) betyr at en angriper ikke kan få informasjon om ren tekst $ P $ fra krypteringsteksten $ E_K (P) $ bortsett fra muligens lengden. Med andre ord ser krypteringsteksten ut som en tilfeldig streng for de som ikke kjenner til $ K $ , selv om de har en viss kontroll over klarteksten. Alle folklore-krypteringsmetoder, fra engangspute til Enigma, gir konfidensialitet (under noen forutsetninger) og bare det.

Data ekthet (integritet) betyr at en autorisert part (mottaker), som eier $ K $ , kan sjekke om mottakeren ved data $ D $ er ekte, det vil si at de bare er konstruert av en avsender som kjenner til $ K $ . Dataene kan være klartekst eller krypteringstekst, og det er en subtil forskjell hva som er autentisk i hvert tilfelle: Hvis krypteringstekst er autentisert, så vet vi at nøkkelinnehaveren autoriserte krypteringsteksten, men ikke nødvendigvis klartekst. En tradisjonell måte å oppnå ekthet på er å bruke Message Authentication Code (MAC): $$ H_K (D) = T, $$ der $ T $ heter tag . I en verden av kryptografi med offentlig nøkkel oppnås det samme målet med digitale signaturer.

Det du trenger

En bruker kan vanligvis bestemme hvilke av disse egenskapene han leter etter. Hvis han for eksempel vet at en angriper ikke kan endre data, trenger han kanskje ikke å autentisere dem. Imidlertid, hvis han trenger begge deler, er det sikre og usikre måter å kombinere ordningene av to typer på. For eksempel er en naiv tilnærming til å bruke den samme nøkkelen $ K $ i begge ordningene farlig usikker for de fleste instantiations. Derfor anbefales en kombinert ordning.

Autentisert kryptering

Autentisert kryptering (AE) gir konfidensialitet og datautentisitet samtidig. En AE-ordning er vanligvis mer komplisert enn konfidensialitets- eller autentisitetsplaner. Imidlertid er det lettere å bruke, fordi det vanligvis bare trenger en enkelt nøkkel, og er mer robust, fordi det er mindre frihet for brukeren å gjøre noe galt (se også en mer utførlig svar ).

Som en egen funksjon kan et godkjent krypteringsskjema autentisere, men ikke kryptere, en del av inngangen, som kalles tilknyttede data . Vi kan for eksempel ønske å kryptere innholdet i en Internett-pakke, men vi må la overskriften være ukryptert, men fortsatt bundet til de interne dataene.

Sikkerhet

Vi har ennå ikke spesifisert hva vi mener med en sikker ordning. Tilsynelatende er det flere sikkerhetsoppfatninger, og brukeren må velge blant dem i henhold til mulighetene han forventer fra en motstander.

For kun konfidensialitet driftsmåter de mest populære sikkerhetsoppfatning handler om valgte angrep med vanlig tekst . La $ E $ være et krypteringsskjema. Vi antar at motstanderen ikke bare kjenner noen enkle tekster $ P $ , men også er i stand til å velge noen av dem for kryptering (dette er ganske praktisk).Derfor tillater vi motstanderen å velge hvilken som helst ren tekst for kryptering, og mange ganger på rad. Det vi fremdeles krever av en sikker ordning er at den sender ut tilfeldige krypteringstekster i hvert tilfelle: $$ E_K (P_1), E_K (P_2), \ ldots, E_K (P_n) \ sim RandomString (| P_1 | + | P_2 | + \ cdots + | P_n |) $$

Motstanderen kan ikke skille hele settet med krypteringstekster han får fra en utgang fra ekte tilfeldig bitgenerator på samme lengde, selv om motstanderen gjentar sine klare tekster. Det siste kravet innebærer at ordningen må være ikke-deterministisk, og de konfidensialitetsmodiene som tilfredsstiller disse kravene, er enten sannsynlige eller ikke-baserte.

Jeg bemerker at det er folklore sikkerhetsoppfatninger som forholder seg til sikkerheten til ordningen med muligheten til å gjenopprette nøkkelen $ K $ selv. Dette var relevant når nøkkelen kunne brukes andre steder, men dette er langt mindre vanlig nå, og sikkerhetsoppfatningen beskrevet ovenfor er utbredt.

Sikkerheten til autentisitetsmodus er definert i en annen måte. La $ H_K $ være en slik ordning med den hemmelige nøkkelen $ K $ . Vi krever at hvis motstanderen velger data $ D $ som ikke er autentisert ennå, så sjansene hans for å gjette tag $ T $ slik at $$ H_K (D) = T $$ er ubetydelige. Hvis han sender inn paret $ (D, T) $ til en verifikator, får han svaret $ \ perp $ (feil).

Merk at vi ikke har snakket om valgte ciphertext-angrep på konfidensialitetsmodus. Dette er angrep når motstanderen også er i stand til å sende sine egne krypteringstekster for dekryptering. Selv om denne innstillingen også vises i praksis (selv om det er sjeldnere enn valgte angrep med vanlig tekst), kan ikke de konfidensielle ordningene motstå slike angrep. For å etablere denne typen sikkerhet, må brukeren slå seg til autentisert kryptering .

Sikkerhet for autentiserte krypteringsordninger er definert i to deler. For det første, på samme måte som kun konfidensialitet, må motstanderen ikke kunne skille kryptertekstene fra tilfeldige strenger. For det andre, uansett falsk (ikke opprettet på $ K $ ) krypteringstekst hun sender for dekryptering, vil hun sannsynligvis få $ \ perp $ som svar.

De autentiserte krypteringsmodusene gir deg også sikkerhet mot valgte ciphertext-angrep hvis det er nødvendig.

Slik fungerer det

Det er mange integrerte autentiserte krypteringsordninger: CCM, GCM, OCB, EAX, etc , der mekanismer som etablerer konfidensialitet og ekthet, er tett sammenkoblet. Utformingen av disse ordningene er langt utenfor temaet. Imidlertid er det en enkel sammensatt ordning, kjent som Encrypt-then-MAC, som fungerer som følger. La $ K_1, K_2 $ være hemmelige nøkler, $ P $ være ren tekst, $ E $ være krypteringsmodus, og $ H $ være MAC. Deretter ordningen $$ \ Pi_ {K_1, K_2}: M \ rightarrow E_ {K_1} (M) || H_ {K_2} (E_ {K_1} (M)) $$ er et sikkert autentisert krypteringsskjema hvis $ E $ er en sikker konfidensialitetsmodus og $ H $ er en sikker autentisitetsmodus.

Ytterligere funksjoner i autentiserte krypteringsskjemaer

I tillegg til å gi både konfidensialitet og ekthet, kan autentiserte krypteringsopplegg ha en rekke tilleggsfunksjoner. Ingen ordninger har dem alle, derfor bestemmes det beste valget av brukerens innstillinger.

• Sikkerhetsnivå . En ordning garanterer konfidensialitet og datautentisitet bare opp til noen som er bundet av mengden krypterte data eller dekrypteringsforespørsler. Denne båndet er vanligvis mye lavere enn nøkkelområdet, og for AES-baserte modus overskrider vanligvis ikke $ 2 ^ {64} $ .

• Parallelisme Hvis det er mange ressurser tilgjengelig, kan det være lurt å kjøre kryptering, dekryptering eller bekreftelse parallelt. Modusene som bruker kjetting (som de som kommer fra CBC-kryptering eller svampkonstruksjonen), er vanskelige å parallellisere.

• Online kryptering Vi sier at en ordning er online, hvis den tillater kryptering umiddelbart når dataene er tilgjengelige, uten viten om lengden.

• Bruk av patenter . En av de mest interessante AE-ordningene, OCB-modus, er patentert og er mindre hyppig ble brukt og analysert på grunn av denne egenskapen.Det er ofte ønskelig at ordningen er patentfri.

• Tag oppdatering . De fleste av ordningene, med noen få unntak som GCM, krever å beregne nesten hele krypteringstekst hvis en liten del av ren tekst endres. Hvis krypteringsteksten kan oppdateres raskt, vil det tillate mye raskere behandling av store mengder kryptert data, f.eks. Kryptering av harddisken.

• Bruk av nonces eller tilfeldig IVs . Nonces og tilfeldige IV-er fører til forskjellige sikkerhetsmodeller, som ofte er inkompatible (ordninger kan være sikre med nonces, men ikke med tilfeldige IV-er med samme lengde, eller omvendt). Mens nonce-unikheten kan være vanskeligere å sikre, trenger tilfeldige IV-er en egen genereringsmekanisme for tilfeldig tall og fører til utvidelse av ciphertext.

• Variabel nøkkel, nonce, eller taglengde . Alle de tre parametrene er vanligvis begrenset av applikasjonen som bruker en AE-ordning. AE-ordninger har igjen sine egne, noen ganger uforenlige begrensninger. Jo mer variasjon ordningen har, jo flere applikasjoner passer den.

• Behandling av tilknyttede data . Alle de moderne ordningene tillater godkjenning av tilknyttede data, som ikke er kryptert. Noen av dem kan imidlertid ikke behandle AD før klarteksten er over, noe som kan være en straff for forestillingen.

Ytterligere lesing

teknisk rapport av Rogaway er en omfattende undersøkelse av konfidensialitet -Bare modi, MAC og noen autentiserte krypteringsmodi. Den inneholder også alle formelle detaljer om sikkerhetsoppfatninger.

Kommentarer

• Jeg kan legge til at valg av autentisert krypteringsskjema i stor grad er diktert ved passende konvensjon eller protokoller. Det er veldig vanlig at folk rynker pannen mot autentisert kryptering, men i praksis har jeg ‘ sett både tilpassede implementeringer av MAC-da-kryptere og kryptere-da-MAC for å ha feil enn bruksområder av autentisert kryptering. Dette er fordi det krever veldig mye oppmerksomhet for detaljer for å implementere kombinasjonen riktig.
• Når det gjelder tilleggsegenskaper, har det vært viktig å unngå å opprette sidekanaler (spesielt timing sidekanaler) for å vurdere sikkerheten av en AE (AD) krypteringssuite. Som en praktisk sak betyr dette at det er mulig å implementere krypteringen slik at den kjører i en tid som ikke er påvirket av nøkkelen eller inngangen ren tekst.

Når vi overfører informasjon over en usikker kanal, ønsker vi at dataene våre skal være sikre.

Så hva betyr dette? For å diskutere disse vil vi bruke den standard kryptografiske situasjonen til Alice og Bob. Alice ønsker å sende noe ( ren tekst ) over en usikker kanal (hva dette betyr vil bli diskutert) til Bob. Denne kanalen vil bli lyttet til av Eve (en avlytter) og Mallory (som prøver å forstyrre ondsinnet) – hva dette betyr vil bli diskutert etter hvert.

Konfidensialitet : Når Alice sender en melding til Bob, krever vi at en avlytter Eva som lytter til kommunikasjonen deres ikke kan lære noe om innholdet i meldingene.

Begrunnelse : Ellers kan Eve lære noe som Alice / Bob ikke vil dele

Løsning: Vi bruker kryptering , som forvandler klartekst til en krypteringstekst som (i en informasjonsteoretisk forstand ) inneholder bare informasjon om ren tekst som ikke er mulig å hente ut. Dette betyr at (parafrasering av Goldwasser ) noe ing Eve kan lære om ren tekst gitt hun kjenner krypteringsteksten, kan hun også utlede uten krypteringstekst.

Selv i dette tilfellet må vi være forsiktige. Bare fordi en ordning holder mot en passiv angriper (noen som bare lytter til meldingsstrømmen), gjør den ikke sterk mot en aktiv angriper. Tenk for eksempel på CBC -modus brukes. Det er sikkert under IND – CPA , som du kan føle at det er sikkert. I CCA -spillet tillater vi angriperen å be om dekryptering av meldinger (men ikke dekryptering av krypteringstekst) Det han kan gjøre, gitt ciphertext $ c = {\ small IV} \ mathbin \ | c_1 \ mathbin \ | \ dots \ mathbin \ | c_n $ er be om dekryptering av $ c «= a \ mathbin \ | c $, der $ a $ er en ikke-tom melding. Dette er ikke lik krypteringsteksten, derfor er det tillatt under spillet, og ved å ta bare de siste $ n $ blokkene kan han trekke ut dekrypteringen av krypteringsteksten.

Et slikt eksempel er ikke så konstruert som du kanskje tror, siden det vi modellerer som et dekrypteringsorakel kan godt eksistere ved at angriperen kanskje kan få strengene dekryptert, men at dataene de kan be om dekryptere må kanskje begynne med en bestemt streng (ligner ideen om en SQL-injeksjon).

Autentisitet : Når Bob mottar en melding, vet han at den definitivt var fra Alice.

Begrunnelse: Ellers kunne Mallory sende en melding til Bob og hevdet at den er fra Alice uten at Bob vet. «er veldig lempelig på hva det betyr for Mallory å lage en falsk melding – han vinner hvis han kan lage hvilken som helst melding som Bob godtar (selv om den nesten er den samme som en Alice allerede har sendt ham). Det er mange måter å gjøre dette på, for eksempel reprise, omorganisering eller bit-flipping-angrep.

Løsning: For å oppnå autentisering alene kan vi bruke en MAC .

Autentisitet og konfidensialitet : Alice og Bob kommuniserer konfidensielt, og hver melding er autentisk.

Begrunnelse: Hvis en strøm kun er konfidensiell (dvs. kryptering, men ikke godkjent kryptering), kan en avlytter kanskje være i stand til å endre meldingen under transport, selv om de ikke ville vite hva dette var. Anta for eksempel at Alice & Bob bruker perfekt sikker One Time Pad ( OTP ) med hemmelig nøkkel $ k $ og melding $ m $:

$$ A \ text {sender} c = m \ oplus k \ til B \\ \ prec M \ text {avlytter} c \ succ \\ M \ text {sender} c «= c \ oplus h \ til B \ text {(for en eller annen verdi} h) \\ B \ text {mottar} c» \ text {fra M, men tror det er} c \ text {sendt fra} A \\ B \ text {dekrypterer} m «= c» \ oplus k = c \ oplus h $$ Dette betyr at $ B $ har mottatt melding $ m «$, men han tror det er $ m $.

Så, anta at protokollen ikke er autentisert og Mallory vet at meldingen Alice skal sende Bob er» Jeg godtar å sende £ ??? til konto # ???? «for noen verdier av ???. Selv om de ikke kan finne ut nøyaktig hva kontoen er, og så kanskje de ikke kan sende betalingen til sin egen konto, kan de endre det så det ikke lenger er Alice-kontoen.

Løsning: Autentisert kryptering!

En god artikkel som forklarer behovet for AE er dette blogginnlegget av Matthew Green. En mer teknisk introduksjon til Modes of operation er denne artikkelen av Rogaway.

Kommentarer

• Det eneste krypteringsskjemaet som sikrer informasjonsteoretisk sikkerhet er engangsblokken. IND-CPA-krypteringsordninger garanterer bare at informasjonen ikke kan hentes ut fra krypteringsteksten av en sannsynlig poly-time motstander.
• Ah ja det var uklart (/ feil!) skrevet. Takk for at du redigerte det i – jeg skulle si det som ‘ inneholder ingen informasjon < som kan hentes ut > ‘
• Egentlig mange » bare konfidensialitet » moduser gir faktisk ikke ‘ t god konfidensialitet når de blir angrepet av en aktiv angriper (som kan endre meldingene eller montere valgt klartekst eller valgte ciphertext-angrep) . Derfor må disse modusene i praksis (for en kommunikasjonskanal) brukes sammen med noen MAC, selv for bare å oppnå den konfidensielle delen. En AE-modus kombinerer bare disse til en.
• @ PaŭloEbermann / Alle andre: Jeg tror virkelig ikke ‘ Jeg tror ikke jeg ‘ har skrevet et godt svar her (det er tross alt fredag kveld!), men jeg ville bare legge ned noen første tanker. Legg gjerne til dine egne svar / rediger dette / skriv dine egne av dette. Hvis folk tror svaret mitt er » nær nok » til en god en (som gjenleser det, gjør jeg ikke ‘ t) så er du ‘ velkommen til å bare redigere i, eller bruke mine ord på nytt i dine.
• Jeg tror AE også gir integritet ( en.wikipedia.org/wiki/Authenticated_encryption ) så kan det være lurt å legge til det også ..