Miért használjam a hitelesített titkosítást a puszta titkosítás helyett?

Különböző működési módok léteznek a blokkos titkosításhoz, amelyek közül néhány “titkosítás”, és némelyik hitelesített titkosítást biztosít .

Miért használjam hitelesített titkosítás mód, nem csak titkosítási mód?

Ez a kérdés nem célja a hitelesített titkosítási vrs titkosítási módok különböző módjainak megvitatása (bár jó válasz választhat): célja annak indoklása, hogy miért / mikor jobb az AE, mint a “sima” titkosítás.

Megjegyzések

Válasz

A sima és a hitelesített titkosítás (AE) közötti alapvető különbség az, hogy az AE emellett provi des hitelesség, míg a sima titkosítás csak titoktartást biztosít. Vizsgáljuk meg részletesen ezt a két fogalmat.

A további szövegben feltételezzük, hogy a $ K $ titkos kulcs, ami ismert felhatalmazott feleknek, de a támadók számára ismeretlen.

Célok

Titoktartás (adatvédelem) azt jelenti, hogy a támadó nem szerezhet semmilyen információt a sima szöveg $ P $ -ról a $ E_K (P) $ , kivéve esetleg a hosszúságot. Más szavakkal, a rejtjelezett szöveg véletlenszerű karakterláncnak tűnik azok számára, akik nem ismerik a $ K $ , még akkor is, ha valamilyen irányítással rendelkeznek a sima szöveg felett. Az összes folklór-titkosítási módszer, az egyszeri típustól az Enigmáig, bizalmas jellegű (bizonyos feltételezések mellett) és csak azt.

Adatok hitelesség (integritás) azt jelenti, hogy egy $ K $ birtokában lévő felhatalmazott fél (fogadó) ellenőrizheti, hogy a A ved adatok $ D $ valódiak, azaz csak egy küldő állította össze, aki ismeri a $ K $ . Az adatok lehetnek átlátszó vagy rejtjelezett szövegek, és finom különbség van abban, hogy mi minden esetben hiteles: ha a titkosított szöveg hitelesített, akkor tudjuk, hogy a kulcs tulajdonosa engedélyezte a rejtjelezést, de nem feltétlenül egyszerű szöveg. A hitelesség elérésének hagyományos módja az Üzenet-hitelesítési kód (MAC) használata: $$ H_K (D) = T, $$ ahol $ T $ az úgynevezett címke . A nyilvános kulcsú rejtjelezés világában ugyanezt a célt érik el digitális aláírásokkal.

Amire szüksége van

A felhasználó általában el tudja dönteni, hogy ezek közül mely tulajdonságokat keresi. Például, ha tudja, hogy a támadó nem tudja módosítani az adatokat, akkor lehet, hogy nem kell hitelesítenie azokat. Ha azonban mindkettőre szüksége van, vannak biztonságos és nem biztonságos módszerek a kétféle rendszer ötvözésére. Például ugyanaz a $ K $ kulcs mindkét módszerben történő használata naiv módon veszélyes a legtöbb példány esetében. Ezért kombinált séma ajánlott.

Hitelesített titkosítás

A hitelesített titkosítás (AE) egyszerre biztosítja a titoktartást és az adatok hitelességét. Az AE sémák általában bonyolultabbak, mint a csak a titoktartás vagy a hitelesség csak sémák. Könnyebb azonban használni, mert általában csak egyetlen kulcsra van szükség, és robusztusabb, mert kevesebb szabadságot ad a felhasználó a rossz cselekedetekre (lásd még egy bonyolultabb válasz ).

Külön funkcióként a hitelesített titkosítási séma hitelesítheti, de nem titkosíthatja a bemenet egy részét, amelyet társított adatok nak neveznek. . Például szeretnénk titkosítani egy internetes csomag tartalmát, de a fejlécét titkosítatlanul, de továbbra is a belső adatokhoz kell kötni.

Biztonság

Még nem határoztuk meg, mit értünk biztonságos séma alatt. Nyilvánvalóan számos biztonsági elképzelés létezik, és a felhasználónak az ellenféltől elvárt képességek szerint kell választania közülük.

A csak titoktartási üzemmódok esetében a legnépszerűbb a biztonsági koncepció a választott egyszerű szöveges támadásokkal foglalkozik . Legyen $ E $ titkosítási séma. Feltételezzük, hogy az ellenfél nemcsak ismer néhány táblázatot $ P $ , hanem képes közülük néhányat kiválasztani a titkosításhoz (ez elég gyakorlati helyzet).Ezért megengedjük az ellenfélnek, hogy tetszőleges sima szöveget válasszon a titkosításhoz, és sokszor egymás után. Amit továbbra is megkövetelünk egy biztonságos sémától, az az, hogy véletlenszerűen kinéző rejtjeles szövegeket ad ki minden esetben: $$ E_K (P_1), E_K (P_2), \ ldots, E_K (P_n) \ sim RandomString (| P_1 | + | P_2 | + \ cdots + | P_n |) $$

Az ellenfél nem tudja megkülönböztetni a titkosított szövegek teljes készletét, amelyet a azonos hosszúságú, még akkor is, ha az ellenfél megismétli panaszait. Ez utóbbi követelmény azt jelenti, hogy a rendszernek nem determinisztikusnak kell lennie, sőt, a csak titoktartási módok, amelyek kielégítik ezeket a követelményeket, valószínűségi vagy nem alapúak.

Megjegyzem, hogy vannak folklór biztonsági fogalmak, a séma biztonsága azzal a képességgel, hogy visszaállíthatja a kulcsot, amely $ K $ . Ez akkor volt releváns, amikor a kulcsot másutt lehetett használni, de ez ma már jóval ritkábban fordul elő, és a fent leírt biztonsági koncepció érvényesül.

A hitelességi módok biztonságát a más módon. Legyen $ H_K $ ilyen séma a titkos kulccsal $ K $ . Megköveteljük, hogy ha az ellenfél olyan adatokat $ D $ választ, amelyek még nincsenek hitelesítve, akkor esélye van arra, hogy kitalálja a $ címkét T $ oly módon, hogy a $$ H_K (D) = T $$ elenyésző. Ha elküldi a $ (D, T) $ párost egy hitelesítőnek, megkapja a választ $ \ perp $ (hiba).

Ne feledje, hogy nem beszéltünk választott titkosítási szöveges támadásokról a csak titoktartási módokban. Ezek olyan támadások, amikor az ellenfél saját titkosító szövegeit is képes visszafejtésre küldeni. Bár ez a beállítás a gyakorlatban is megjelenik (bár ritkábban, mint a kiválasztott sima szövegű támadások), a csak a titoktartási sémák nem tudnak ellenállni az ilyen támadásoknak. Az ilyen jellegű biztonság létrehozásához a felhasználónak ismét a hitelesített titkosítás hoz kell fordulnia.

A hitelesített titkosítási sémák biztonságát két részben határozza meg. Először is, a csak a titoktartási módokhoz hasonlóan az ellenfélnek sem kell képesnek lennie megkülönböztetni a titkos szövegeket a véletlenszerű karakterláncoktól. Másodszor, bármilyen hamis (nem a $ K $ -on létrehozott) titkosítási szövegen is visszaküldi, valószínűleg megkapja a $ \ perp $ válaszként.

Ezért a hitelesített titkosítási módok biztonságot nyújtanak a választott titkosítási támadásokkal szemben is, ha erre szükség van.

Hogyan működik

Számos integrált hitelesített titkosítási séma létezik: CCM, GCM, OCB, EAX stb. , ahol a titoktartást és a hitelességet biztosító mechanizmusok szorosan összekapcsolódnak. Ezeknek a sémáknak a kialakítása messze túlmutat a témán. Van azonban egy egyszerű összeállított séma, közismert nevén Encrypt-then-MAC, amely a következőképpen működik. Legyen $ K_1, K_2 $ titkos kulcs, $ P $ legyen a sima szöveg, $ E $ legyen titkosítási mód, a $ H $ pedig valamilyen MAC. Ezután a $$ \ Pi_ {K_1, K_2} séma: M \ rightarrow E_ {K_1} (M) || A H_ {K_2} (E_ {K_1} (M)) $$ egy biztonságos hitelesített titkosítási séma, ha a $ E $ egy biztonságos titoktartási mód, és $ H $ egy biztonságos hitelességi mód.

A hitelesített titkosítási sémák további jellemzői

A titoktartás és a hitelesség biztosítása mellett a hitelesített titkosítási sémáknak számos további szolgáltatása lehet. Egyetlen séma sem tartalmazza mindet, ezért a legjobb választást a felhasználó beállításai határozzák meg.

  • Biztonsági szint . Egy séma csak a titoktartást és az adatok hitelességét garantálja. a titkosított adatok vagy a visszafejtési kérelmek mennyiségéhez kötődik. Ez a kötés általában jóval alacsonyabb, mint a kulcsterület, és AES-alapú módoknál általában nem haladja meg a $ 2 ^ {64} $ értéket .

  • Párhuzamosság Ha sok erőforrás áll rendelkezésre, akkor a titkosítást, a visszafejtést vagy az ellenőrzést párhuzamosan futtathatja. A láncolást használó módokat (például a CBC titkosításból vagy a szivacs felépítéséből származóakat) nehéz párhuzamosítani.

  • Online titkosítás . Azt mondjuk hogy egy séma online, ha lehetővé teszi az adatok titkosítását, amikor az adatok rendelkezésre állnak, annak hossza ismerete nélkül.

  • Szabadalmak használata . Az egyik legérdekesebb AE séma, az OCB mód szabadalmaztatott és ritkább Ezt a tulajdonságot használta és elemezte.Gyakran kívánatos, hogy a rendszer szabadalommentes legyen.

  • Címkefrissítés . A legtöbb séma – néhány kivételtől eltekintve, például a GCM-től – majdnem a teljes rejtjelszöveget újraszámolja, ha a sima szöveg kis részét módosítják. Ha a rejtjelszöveg gyorsan frissíthető, ez sokkal gyorsabb feldolgozást tesz lehetővé nagy mennyiségű titkosított adat, például a merevlemezes titkosítás érdekében.

  • Nonces vagy véletlenszerű használata IVs t. A nonces és véletlenszerű IV-k különálló biztonsági modellekhez vezetnek, amelyek gyakran nem kompatibilisek (a sémák lehetnek biztonságosak a nonces-ekkel, de nem azonos hosszúságú véletlenszerű IV-kkel, vagy fordítva). Noha a nonce egyediségét nehezebb biztosítani, a véletlenszerű IV-knek külön véletlenszám-generáló mechanizmusra van szükségük, és a titkosítási szöveg kibővítéséhez vezet.

  • Változó kulcs, nonce, vagy a címke hossza t. Mindhárom paramétert általában az AE sémát használó alkalmazás korlátozza. Viszont az AE rendszerek saját, néha összeférhetetlen korlátozásokkal rendelkeznek. Minél nagyobb a változatossága a rendszernek, annál több alkalmazás megfelel.

  • A társított adatok feldolgozása . Az összes modern séma lehetővé teszi a társított adatok hitelesítését, amely nincs titkosítva. Néhányuk azonban nem tudja az AD-t előre feldolgozni, mielőtt a sima szöveg vége lenne, ami büntetést jelenthet a teljesítményre nézve.

További olvasmány

A Rogaway műszaki jelentése a titoktartás átfogó felmérése -csak módok, MAC-ok és néhány hitelesített-titkosítási mód. Ez tartalmazza a biztonsági fogalmak összes formális részletét.

Megjegyzések

  • Hozzáteszem, hogy sok gyakorlati helyzetben a hitelesített titkosítási séma választása nagyrészt diktált megfelelő egyezmény vagy protokollok alapján. Nagyon gyakori, hogy az emberek elkomorodnak a hitelesített titkosítás miatt, de a gyakorlatban én ‘ láttam, hogy a MAC-majd titkosítás és a Titkosítás-majd-MAC egyedi megvalósításai hibákat mutatnak hitelesített titkosítás. Ennek oka, hogy a kombináció helyes megvalósításához nagyon nagy figyelmet kell fordítani a részletekre.
  • A további tulajdonságok szempontjából az oldalsó csatornák (különösen az oldalsó csatornák időzítésének) létrehozásának elkerülése kritikus jelentőségű volt a biztonság megítélésében. egy AE (AD) rejtjelkészletből. Gyakorlati szempontból ez azt jelenti, hogy a titkosítást úgy lehet megvalósítani, hogy az olyan időben futjon, amelyet a kulcs vagy a beviteli sima szöveg nem befolyásol.

Válasz

Ha egy információt nem biztonságos csatornán továbbítunk, azt kívánjuk, hogy adataink biztonságban legyenek.

Szóval, mit jelent ez? Ennek megvitatásához Alice és Bob szokásos kriptográfiai helyzetét használjuk. Alice valamit el akar küldeni (a sima szöveg et egy bizonytalan csatornán (mit jelent ez megvitatásra kerül) Bobnak. Ez a csatorna meghallgatja Eve (lehallgató) és Mallory (aki rosszindulatúan próbál beavatkozni) – ennek jelentését a megfelelő időben megbeszéljük.

Titoktartás : Amikor Alice üzenetet küld Bobnak, azt követeljük, hogy a kommunikációjukra figyelő Eve lehallgató ne tudjon meg semmit az üzeneteik tartalmáról.

Indokolás : Ellenkező esetben Eve megtanulhat valamit, amit Alice / Bob nem akar megosztani.

Megoldás: A titkosítást használjuk, amely a sima szöveget titkos szöveggé alakítja (információelméleti értelemben). ) csak a sima szöveggel kapcsolatos információkat tartalmaz, amelyeket nem lehet kivonni. Ez azt jelenti, hogy ( Goldwasser átfogalmazása) Eve megismerheti a sima szöveget, ha ismeri a rejtjelszöveget, következtethet a rejtjelszöveg nélkül is.

Még ebben az esetben is óvatosnak kell lennünk. Csak azért, mert egy séma ellenáll egy passzív támadónak (aki csak meghallgatja az üzenetfolyamot), nem lesz erős egy aktív támadóval szemben. Például fontolja meg a CBC-t módot használjuk. A IND CPA játék alatt biztonságos, amelyet biztonságosan érezhet. Azonban a CCA játékban megengedjük a támadónak, hogy kérje az üzenetek visszafejtését (bár nem a titkosított szöveg visszafejtését). . Amit tehet , a $ c = {\ small IV} \ mathbin \ | c_1 \ mathbin \ | \ dots \ mathbin \ | c_n $ rejtjelezési szöveg megadásakor kéri a $ c visszafejtését “= a \ mathbin \ | c $, ahol a $ a $ nem üres üzenet. Ez nem egyenlő a rejtjelszöveggel, ezért megengedett a játékban, és ha csak az utolsó $ n $ blokkot veszi ki, kibonthatja a titkosítás visszafejtését.

Egy ilyen példa nem annyira kitalált, mint gondolnád, mivel az, amit visszafejtő orákulaként modellezünk, jó eséllyel abban rejlik, hogy a támadó képes lehet visszafejteni a karakterláncokat, de hogy azok az adatok, amelyekre kérhetnek A visszafejtésnek egy adott karakterlánccal kell kezdődnie (hasonlóan az SQL-injekció elképzeléséhez).

Hitelesség : Amikor Bob üzenetet kap, tudja, hogy az mindenképpen Alice-től származik.

Indokolás: Ellenkező esetben Mallory üzenetet küldhetne Bobnak, és azt állítja Alice-től, hogy Bob nem tudná. Bizonyítható biztonságban mi “nagyon engedékeny, hogy mit jelent Mallory számára hamis üzenet létrehozása – akkor nyer, ha képes létrehozni bármilyen üzenetet, amelyet Bob elfogad (még akkor is, ha az majdnem ugyanaz, mint amit Alice már elküldött neki). Ennek sokféle módja van, például visszajátszás, átrendezés vagy bit-flipping támadások.

Megoldás: A hitelesítés önmagában történő eléréséhez használhatunk egy MAC .

Hitelesség és titoktartás : Alice és Bob bizalmasan kommunikálnak, és minden üzenet hiteles.

Indokolás: Ha egy adatfolyam csak bizalmas (azaz titkosítás, de nem hitelesített titkosítás), akkor egy lehallgató képes lehet módosítani az üzenetet közben, annak ellenére, hogy nem tudná, mi ez. Tegyük fel például, hogy Alice & Bob a tökéletesen biztonságos One Time Pad-t használja ( OTP ) titkos kulccsal $ k $ és $ m $ üzenettel:

$$ A \ text {sends} c = m \ oplus k \ to B \\ \ prec M \ text {intercepts} c \ succ \\ M \ text {sends} c “= c \ oplus h \ to B \ text {(bizonyos értékeknél h) \\ B \ text {fogadja} c” \ text {M-től, de azt gondolja, hogy ez} c \ text {küldve} A \\ B \ text {decrypts} m “= c” \ oplus k = c \ oplus h $$ Ez azt jelenti, hogy $ B $ megkapta a $ üzenetet m “$, de szerinte $ m $.

Tehát tegyük fel, hogy a protokoll nincs hitelesítve, és Mallory tudja, hogy Alice Bobnak fogja küldeni az üzenetet:” Elfogadom £ elküldését ??? a (z) # ???? “számlára a (z) ??? egyes értékeihez. Még akkor is, ha nem tudják megtudni, hogy pontosan mi a számla, és így talán nem tudják elküldeni a befizetést a saját számlájukra, megváltoztathatják így már nem az Alice-fiók.

Megoldás: Hitelesített titkosítás!


Egy jó cikk, amely elmagyarázza az AE szükségességét: ez a blogbejegyzés , Matthew Green. A működési módok technikaibb bevezetése ez a cikk , Rogaway.

Megjegyzések

  • Az egyetlen információs elméleti biztonságot biztosító titkosítási séma az egyszeri betét. Az IND-CPA titkosítási sémák csak azt garantálják, hogy az információkat nem lehet kinyerni a rejtjelezett szövegből egy valószínűségi többszörös ellenfél.
  • Ó, igen, ezt nem egyértelműen (/ helytelenül!) írták. Köszönöm, hogy szerkesztetted – nem tartalmaz olyan információt, <, amely kivonható > ‘
  • Valójában sok ” csak titoktartási ” módok valójában még csak nem is adják meg a megfelelő bizalmatlanságot, ha egy aktív támadó megtámadja őket (ami módosíthatja az üzeneteket, vagy csatolhatja a kiválasztott szöveges vagy választott rejtjeles támadásokat) . Ezért ezeket a módokat a gyakorlatban (egy kommunikációs csatornához) néhány MAC-mal együtt kell használni, még csak a bizalmas rész megszerzéséhez is. Az AE mód csak ezeket egyesíti egybe.
  • @ PaŭloEbermann / Bárki más: Nem igazán gondolom, hogy ‘ szerintem ‘ ve írtam itt egy jó választ (végül is péntek éjszakája!), de csak néhány első gondolatot szerettem volna megfogalmazni. Adja hozzá nyugodtan saját válaszait / szerkessze ezt / írja le erről a sajátját. Ha az emberek úgy gondolják, hogy a válaszom ” elég közel van ” egy jóhoz (amit újraolvasok, akkor nem ‘ t) akkor ‘ üdvözöljük, ha csak szerkesztem, vagy újból felhasználom a szavaimat.
  • Úgy gondolom, hogy az AE integritást is biztosít ( hu.wikipedia.org/wiki/Authenticated_encryption ), ezért érdemes ezt is hozzáadni.

Vélemény, hozzászólás?

Az email címet nem tesszük közzé. A kötelező mezőket * karakterrel jelöltük