Waarom zou ik geverifieerde versleuteling gebruiken in plaats van alleen versleuteling?

Het cruciale verschil tussen gewone codering en geverifieerde codering (AE) is dat AE bovendien provi des authenticiteit, terwijl gewone codering alleen vertrouwelijkheid biedt. Laten we deze twee begrippen eens nader onderzoeken.

In de verdere tekst gaan we ervan uit dat $ K $ een geheime sleutel is, die bekend is voor geautoriseerde partijen, maar onbekend voor aanvallers.

Doelen

Vertrouwelijkheid (privacy) betekent dat een aanvaller geen informatie over de platte tekst $ P $ uit de cijfertekst $ E_K (P) $ behalve mogelijk de lengte. Met andere woorden, de cijfertekst ziet eruit als een willekeurige tekenreeks voor degenen die $ K $ , zelfs als ze enige controle hebben over de leesbare tekst. Alle folkloristische versleutelingsmethoden, van eenmalige pad tot Enigma, bieden vertrouwelijkheid (onder bepaalde veronderstellingen) en alleen deze.

Data authenticiteit (integriteit) betekent dat een bevoegde partij (ontvanger), die $ K $ bezit, kan controleren of de ontvanger ved-gegevens $ D $ zijn echt, dwz ze zijn alleen samengesteld door een afzender die $ K $ kent . De gegevens kunnen duidelijke tekst of cijfertekst zijn, en er is een subtiel verschil wat in elk geval authentiek is: als de cijfertekst is geauthenticeerd, dan weten we dat de sleuteleigenaar de cijfertekst heeft geautoriseerd, maar niet noodzakelijkerwijs platte tekst. Een traditionele manier om authenticiteit te bereiken, is door Message Authentication Code (MAC) te gebruiken: $$ H_K (D) = T, $$ waarbij $ T $ wordt tag genoemd. In de wereld van cryptografie met openbare sleutels wordt hetzelfde doel bereikt met digitale handtekeningen.

Wat je nodig hebt

Een gebruiker is meestal in staat om te beslissen welke van deze eigenschappen hij zoekt. Als hij bijvoorbeeld weet dat een aanvaller gegevens niet kan wijzigen, hoeft hij deze mogelijk niet te verifiëren. Als hij echter beide nodig heeft, zijn er zowel veilige als onzekere manieren om de schemas van twee soorten te combineren. Een naïeve benadering om dezelfde sleutel $ K $ in beide schemas te gebruiken, is bijvoorbeeld gevaarlijk onzeker voor de meeste instantiaties. Daarom wordt een gecombineerd schema aanbevolen.

Geverifieerde versleuteling

Geauthenticeerde versleuteling (AE) biedt tegelijkertijd vertrouwelijkheid en gegevensauthenticiteit. Een AE-schema is meestal ingewikkelder dan schemas met alleen vertrouwelijkheid of alleen authenticiteit. Het is echter gemakkelijker te gebruiken, omdat het meestal maar één sleutel nodig heeft, en robuuster is, omdat de gebruiker minder vrijheid heeft om iets verkeerds te doen (zie ook een uitgebreider antwoord ).

Als een afzonderlijke functie kan een geverifieerd versleutelingsschema een deel van zijn invoer verifiëren, maar niet versleutelen, dat bijbehorende gegevens wordt genoemd . We kunnen bijvoorbeeld de inhoud van een internetpakket willen versleutelen, maar we moeten de koptekst onversleuteld laten, maar wel gebonden aan de interne gegevens.

Beveiliging

We hebben nog niet gespecificeerd wat we bedoelen met een veilig schema. Blijkbaar zijn er verschillende beveiligingsconcepten, en de gebruiker moet er een kiezen op basis van de mogelijkheden die hij van een tegenstander verwacht.

Voor alleen vertrouwelijkheid werkingsmodi de meest populaire beveiligingsbegrip betreft selected-plaintext-aanvallen . Laat $ E $ een versleutelingsschema zijn. We gaan ervan uit dat de tegenstander niet alleen enkele leesbare teksten $ P $ kent, maar ook enkele daarvan kan kiezen voor de versleuteling (dit is een vrij praktische situatie).Daarom staan we de tegenstander toe om elke leesbare tekst voor de codering te kiezen, en vele keren achter elkaar. Wat we nog steeds nodig hebben van een beveiligd schema is dat het in elk geval willekeurig uitziende cijferteksten uitvoert: $$ E_K (P_1), E_K (P_2), \ ldots, E_K (P_n) \ sim RandomString (| P_1 | + | P_2 | + \ cdots + | P_n |) $$

De tegenstander kan de hele set cijferteksten die hij verkrijgt niet onderscheiden van een uitvoer van een echte willekeurige bitgenerator van dezelfde lengte, zelfs als de tegenstander zijn leesbare teksten herhaalt. De laatste vereiste impliceert dat het schema niet-deterministisch moet zijn, en inderdaad, de vertrouwelijkheidsmodi die aan deze vereisten voldoen, zijn ofwel probabilistisch ofwel nonce-gebaseerd.

Ik merk op dat er folklore veiligheidsconcepten zijn die verband houden de veiligheid van het schema met de mogelijkheid om de sleutel $ K $ zelf te herstellen. Dit was relevant toen de sleutel elders kon worden gebruikt, maar dit komt nu veel minder vaak voor, en het beveiligingsconcept dat hierboven wordt beschreven, heerst.

De beveiliging van authenticiteitsmodi wordt gedefinieerd in een andere manier. Laat $ H_K $ zon schema zijn met de geheime sleutel $ K $ . We eisen dat als de tegenstander gegevens $ D $ kiest die nog niet zijn geverifieerd, zijn kansen om tag $ te raden T $ zodanig dat $$ H_K (D) = T $$ verwaarloosbaar zijn. Als hij het paar $ (D, T) $ indient bij een verificateur, krijgt hij het antwoord $ \ perp $ (fout).

Merk op dat we niet hebben gesproken over gekozen-cijfertekstaanvallen op modi met alleen vertrouwelijkheid. Dit zijn aanvallen waarbij de tegenstander ook zijn eigen cijferteksten kan sturen voor ontsleuteling. Hoewel deze instelling ook in de praktijk voorkomt (hoewel minder vaak dan aanvallen met gekozen platte tekst), kunnen de schemas voor alleen vertrouwelijkheid dergelijke aanvallen niet weerstaan. Om dit soort beveiliging tot stand te brengen, moet de gebruiker zich weer wenden tot de geauthenticeerde encryptie .

De beveiliging van geauthenticeerde encryptieschemas wordt in twee delen gedefinieerd. Ten eerste moet de tegenstander, net als bij modi met alleen vertrouwelijkheid, de cijferteksten niet kunnen onderscheiden van willekeurige strings. Ten tweede, welke valse (niet gemaakt op $ K $ ) cijfertekst ze ook verzendt voor decodering, ze krijgt waarschijnlijk $ \ perp $ als reactie.

Daarom bieden de geverifieerde versleutelingsmodi u ook beveiliging tegen aanvallen met gekozen codetekst als dat nodig is.

Hoe het werkt

Er zijn talloze geïntegreerde geverifieerde versleutelingsschemas: CCM, GCM, OCB, EAX, enz. , waar mechanismen die vertrouwelijkheid en authenticiteit bewerkstelligen nauw met elkaar zijn verbonden. Het ontwerp van deze schemas gaat veel verder dan het onderwerp. Er is echter een eenvoudig samengesteld schema, bekend als Encrypt-then-MAC, dat als volgt werkt. Laat $ K_1, K_2 $ geheime sleutels zijn, $ P $ de platte tekst, $ E $ een coderingsmodus zijn, en $ H $ een MAC. Dan is het schema $$ \ Pi_ {K_1, K_2}: M \ rightarrow E_ {K_1} (M) || H_ {K_2} (E_ {K_1} (M)) $$ is een veilig geverifieerd versleutelingsschema als $ E $ een veilige vertrouwelijkheidsmodus is en $ H $ is een veilige authenticiteitsmodus.

Extra functies van geverifieerde versleutelingsschemas

Naast het bieden van zowel vertrouwelijkheid als authenticiteit, kunnen geverifieerde versleutelingsschemas een aantal extra functies hebben. Geen enkel schema heeft ze allemaal, daarom wordt de beste keuze bepaald door de gebruikersinstellingen.

• Beveiligingsniveau . Een schema garandeert vertrouwelijkheid en gegevensauthenticiteit alleen tot tot sommigen gebonden aan het aantal gecodeerde gegevens of decoderingsverzoeken. Deze grens is doorgaans veel lager dan de sleutelruimte en is voor op AES gebaseerde modi gewoonlijk niet groter dan $ 2 ^ {64} $ .

• Parallellisme Als er veel bronnen beschikbaar zijn, kan het wenselijk zijn om de codering, decodering of verificatie parallel uit te voeren. De modi die chaining gebruiken (zoals degene die zijn afgeleid van de CBC-codering of de sponsconstructie) zijn moeilijk te parallelliseren.

• Online codering . We zeggen dat een schema online is, als het toelaat om onmiddellijk te versleutelen wanneer de gegevens beschikbaar zijn, zonder de lengte ervan te kennen.

• Gebruik van octrooien . Een van de meest interessante AE-schemas, de OCB-modus, is gepatenteerd en komt minder vaak voor ly gebruikt en geanalyseerd vanwege deze eigenschap.Het is vaak wenselijk dat het schema patentvrij is.

• Tag-update . De meeste schemas, met een paar uitzonderingen zoals GCM, vereisen dat bijna de volledige cijfertekst opnieuw wordt berekend als een klein deel van de platte tekst wordt gewijzigd. Als de cijfertekst snel kan worden bijgewerkt, zou dit een veel snellere verwerking van grote hoeveelheden gecodeerde gegevens mogelijk maken, bijvoorbeeld versleuteling van de harde schijf.

• Gebruik van nonces of willekeurig IVs . Nonces en willekeurige IVs leiden tot verschillende beveiligingsmodellen, die vaak incompatibel zijn (schemas kunnen veilig zijn met nonces, maar niet met willekeurige IVs van dezelfde lengte, of vice versa). Hoewel de uniciteit van nonce misschien moeilijker te garanderen is, hebben de willekeurige IVs een afzonderlijk mechanisme voor het genereren van willekeurige getallen nodig en dit leidt tot uitbreiding van de cijfertekst.

• Variabele sleutel, nonce, of tag lengte . Alle drie de parameters worden meestal beperkt door de toepassing die een AE-schema gebruikt. AE-schemas hebben op hun beurt hun eigen, soms onverenigbare beperkingen. Hoe meer variabiliteit het schema heeft, des te meer toepassingen het geschikt is.

• Verwerking van bijbehorende gegevens . Alle moderne schemas maken authenticatie van bijbehorende gegevens mogelijk, die niet zijn gecodeerd. Sommigen van hen kunnen AD echter niet voorbewerken voordat de leesbare tekst voorbij is, wat een negatieve invloed kan hebben op de prestaties.

Aanvullende informatie

Het technische rapport van Rogaway is een uitgebreid onderzoek naar vertrouwelijkheid -alleen modi, MACs en sommige geverifieerde versleutelingsmodi. Het bevat ook alle formele details over beveiligingsbegrippen.

Opmerkingen

• Ik zou eraan kunnen toevoegen dat in veel praktische situaties de keuze van een geverifieerd versleutelingsschema grotendeels wordt bepaald door geschikte conventie of protocollen. Het is heel gebruikelijk dat mensen fronsen bij geauthenticeerde codering, maar in de praktijk heb ik ‘ gezien dat zowel aangepaste implementaties van MAC-dan-versleutelen als versleutelen-dan-MAC fouten vertonen dan gebruiken van geverifieerde versleuteling. Dit komt doordat het zeer veel aandacht voor detail vereist om de combinatie correct te implementeren.
• In termen van aanvullende eigenschappen, is het vermijden van het creëren van zijkanalen (met name timing zijkanalen) cruciaal geweest bij het beoordelen van de veiligheid van een AE (AD) coderingssuite. In de praktijk betekent dit dat het mogelijk is om het cijfer zo te implementeren dat het wordt uitgevoerd in een tijd die niet wordt beïnvloed door de sleutel of de invoer van platte tekst.

Wanneer we informatie verzenden via een onveilig kanaal, willen we dat onze gegevens veilig zijn.

Dus, wat betekent dit? Om deze te bespreken gebruiken we de standaard cryptografische situatie van Alice en Bob. Alice wil iets (de leesbare tekst ) via een onveilig kanaal (wat dit betekent wordt besproken) naar Bob sturen. Dit kanaal zal worden beluisterd door Eve (een afluisteraar) en Mallory (die probeert kwaadwillig tussenbeide te komen) – wat dit betekent zal te zijner tijd worden besproken.

Vertrouwelijkheid : Wanneer Alice een bericht naar Bob stuurt, eisen we dat een afluisteraar Eve die naar hun communicatie luistert, niets te weten kan komen over de inhoud van hun berichten.

Motivering : Anders zou Eve iets kunnen leren dat Alice / Bob niet willen delen.

Oplossing: we gebruiken encryptie , die de leesbare tekst omzet in een cijfertekst die (in informatietheoretische zin ) bevat alleen informatie over de platte tekst die niet haalbaar kan worden geëxtraheerd. Dit betekent dat (parafraseren van Goldwasser ) anyth ing Eve kan leren over de leesbare tekst, aangezien ze de cijfertekst kent, ze kan ook afleiden zonder de cijfertekst.

Zelfs in dit geval moeten we voorzichtig zijn. Alleen omdat een schema standhoudt tegen een passieve aanvaller (iemand die alleen maar naar de berichtenstroom luistert), maakt het het niet sterk tegen een actieve aanvaller. Overweeg bijvoorbeeld CBC -modus wordt gebruikt. Het is veilig onder het spel IND – CPA , wat het volgens u wellicht veilig maakt. In de game CCA staat de aanvaller echter toe om de decodering van berichten te vragen (maar niet de decodering van de cijfertekst) . Wat hij kan doen, gegeven cijfertekst $ c = {\ kleine IV} \ mathbin \ | c_1 \ mathbin \ | \ dots \ mathbin \ | c_n $ is om de decodering van $ c “= a \ mathbin \ | c $, waarbij $ a $ een niet-leeg bericht is. Dit is niet gelijk aan de cijfertekst, dus is toegestaan onder het spel, en door alleen de laatste $ n $ blokken te nemen, kan hij de decodering van de cijfertekst extraheren.

Zon voorbeeld is niet zo gekunsteld als je misschien denkt, aangezien wat wij modelleren als een decoderingsorakel heel goed zou kunnen bestaan in die zin dat de aanvaller strings kan laten ontsleutelen, maar dat de gegevens waar ze om kunnen vragen decoderen moet mogelijk beginnen met een specifieke string (vergelijkbaar met het idee van een SQL-injectie).

Authenticiteit : Wanneer Bob een bericht ontvangt, weet hij dat het zeker van Alice was.

Rechtvaardiging: Anders zou Mallory een bericht naar Bob kunnen sturen waarin hij beweert dat het van Alice is zonder dat Bob het weet. In bewijsbare zekerheid kunnen we “Wees erg mild over wat het betekent voor Mallory om een nepbericht te maken – hij wint als hij elk bericht kan maken dat Bob accepteert (zelfs als het bijna hetzelfde is als het bericht dat Alice hem al heeft gestuurd). Er zijn veel manieren om dit te doen, zoals opnieuw afspelen, opnieuw ordenen of bit-flipping-aanvallen.

Oplossing: om alleen authenticatie te bereiken, kunnen we een gebruiken MAC .

Authenticiteit en vertrouwelijkheid : Alice en Bob communiceren vertrouwelijk, en elk bericht is authentiek.

Rechtvaardiging: als een stream alleen vertrouwelijk is (dwz versleuteling maar geen geverifieerde versleuteling), kan een afluisteraar mogelijk het bericht tijdens de overdracht wijzigen, ook al zouden ze niet weten wat dit was. Stel dat Alice & Bob de perfect beveiligde One Time Pad ( OTP ) met geheime sleutel $ k $ en bericht $ m $:

$$ A \ text {sends} c = m \ oplus k \ naar B \\ \ prec M \ text {onderschept} c \ succ \\ M \ text {stuurt} c “= c \ oplus h \ naar B \ text {(voor een bepaalde waarde} h) \\ B \ text {ontvangt} c” \ text {van M, maar denkt dat het} c \ text {verzonden is van} A \\ B \ text {decodeert} m “= c” \ oplus k = c \ oplus h $$ Dit betekent dat $ B $ bericht $ heeft ontvangen m “$, maar hij denkt dat het $ m $ is.

Dus, stel dat het protocol niet geauthenticeerd is en Mallory weet dat het bericht dat Alice naar Bob gaat sturen is:” Ik ga ermee akkoord £ ??? naar rekening # ???? “voor sommige waarden van ???. Zelfs als ze niet precies kunnen achterhalen wat de rekening is, en dus misschien niet in staat zijn om de betaling naar hun eigen rekening te sturen, kunnen ze wijzigen het is dus niet langer het account van Alice.

Oplossing: geverifieerde versleuteling!

Een goed artikel dat de noodzaak van AE uitlegt is dit blogbericht door Matthew Green. Een meer technische inleiding tot de bedieningsmodi is dit artikel door Rogaway.

Reacties

• Het enige versleutelingsschema dat informatietheoretische beveiliging garandeert, is het eenmalige pad. IND-CPA-versleutelingsschemas garanderen alleen dat de informatie niet kan worden geëxtraheerd uit de cijfertekst door een probabilistische poly-time tegenstander.
• Ah ja, dat was onduidelijk (/ onjuist!) geschreven. Bedankt voor het bewerken ervan – ik wilde het plaatsen als ‘ bevat geen informatie < die kan worden geëxtraheerd > ‘
• Eigenlijk veel ” alleen vertrouwelijkheid ” -modi geven zelfs ‘ geen goede vertrouwelijkheid wanneer ze worden aangevallen door een actieve aanvaller (die de berichten kan wijzigen of gekozen platte tekst of gekozen cijfertekstaanvallen kan activeren) . Daarom moeten deze modi in de praktijk (voor een communicatiekanaal) samen met een bepaalde MAC worden gebruikt, zelfs om alleen het vertrouwelijke deel te verkrijgen. Een AE-modus combineert deze gewoon tot één.
• @ PaŭloEbermann / Iemand anders: ik denk echt niet dat ‘ niet denk dat ik ‘ heb hier een goed antwoord geschreven (het is tenslotte vrijdagavond!) maar ik wilde even een paar eerste gedachten neerzetten. Voel je vrij om je eigen antwoorden toe te voegen / deze te bewerken / je eigen antwoorden af te schrijven. Als mensen denken dat mijn antwoord ” dichtbij genoeg ” is voor een goed antwoord (wat ik herlees niet ‘ t), dan ben je ‘ welkom om mijn woorden gewoon in de jouwe te bewerken of opnieuw te gebruiken.
• Ik denk dat AE ook integriteit biedt ( en.wikipedia.org/wiki/Authenticated_encryption ) dus misschien wil je dat ook toevoegen ..