it-swarm-eu.dev

Poskytuje symetrické šifrování integritu dat?

Řekněme, že mám jeden server, který šifruje soubor symetrickým klíčem, např. AES-CBC a pošle jej klientům, kteří ji dešifrují. Poskytuje to integritu dat při dešifrování? Nebo je možné, aby někdo manipuloval se souborem, zatímco je stále šifrovaný, a později, když jej klient dešifruje, vytvoří upravený soubor?

Obvykle vidím integritu a autenticitu dat diskutovanou z hlediska používání digitálních podpisů nebo MAC, ale nikdy v souvislosti se šifrováním. Viděl jsem také měřítka, která ukazují, že šifrování je dražší než hašování, ale to není moje hlavní úvaha.

AKTUALIZACE

Vyzkoušel jsem experiment, kde jsem použil nástroj openssl v systému Linux k šifrování souboru. Poté jsem se pokusil soubor různými způsoby upravit (změnit bajt, odstranit bajt, připojit bajt). V každém případě, když jsem se pokusil o dešifrování, dostal bych zprávu „špatné dešifrování“. Příkazy, které jsem použil, byly:

openssl enc -aes-128-cbc -in test -out test.enc
openssl enc -d -aes-128-cbc -in test.enc -out test.dec
18
88keys

Symetrické šifrování neposkytuje integritu. Velikost kontroly, kterou může útočník mít na šifrovaných datech, závisí na typu šifrování; a některé konkrétní podrobnosti o některých režimech šifrování mohou útočníkovi ztěžovat život, pokud chce provést chirurgické úpravy. S CBC může útočník převrátit libovolný kousek, pokud mu nebude vadit, přeměnit tucet dalších bytů na náhodný haraburdí.

Existují nejnovější režimy šifrování , které kombinují symetrické šifrování a kontrolovanou integritu (s MAC ). Tyto režimy zajišťují důvěrnost a integritu. AES-CBC není jedním z nich. Pokud chcete šifrovací režim s integritou, doporučuji EAX .

Aktualizace: týkající se vašeho experimentu: CBC je režim, kdy délka zdrojových dat musí být násobkem délky bloku blokové šifry (16 bajtů, pro AES) . Protože libovolná vstupní zpráva může mít libovolnou délku, přidá se některé výplně : několik bajtů, se specifickým obsahem takovým, že je lze při dešifrování jednoznačně odstranit. Ve vašem případě si OpenSSL stěžuje, že při dešifrování nenajde správnou výplňovou strukturu. Pokud však útočník nezmění posledních 32 bajtů šifrovaných dat, padding bude nepoškozený, takže změny všech kromě posledních 32 bajtů zůstanou nezjištěny. A dokonce i za posledních 32 bajtů existují způsoby, jak se vyhnout detekci s tak malou pravděpodobností.

19
Tom Leek

Šifrování CBC neposkytuje integritu dat. Zde je proč:

Opravte nějaký klíč k (neznámý útočníkovi). Nechť E (k, -) a D (k, -) jsou holé šifrovací a dešifrovací funkce některé blokové šifry. Nechť p je nějaký jediný blok prostého textu. Označím XOR od +.) Po opravě některých IV zašifrujeme následovně:

c = E (k, p + IV).

Potom pošleme IV a c přes drát. Pro dešifrování počítáme

p = D (k, c) + IV.

(Všimněte si, že toto je ekvivalentní prohlášení D (k, c) = IV + p.)

Nyní předpokládejme, že útočník zná jeden pár prostého textu/šifrového textu. Označme je jako p a (IV, c), jak je uvedeno výše. Nyní předpokládejme, že by útočník chtěl vytvořit šifrový text, který bude dešifrovat do jiného bloku prostého textu podle svého výběru - řekněme p '. Tvrdím, že (IV + p + p ', c) se dešifruje na p'. Proč?

Jednoduše se řídíme výše uvedeným dešifrovacím postupem a nahrazujeme IV IV + p + p '. My máme

D (k, c) + (IV + p + p ') = (IV + p) + (IV + p + p') = p '.

Je zábavné, že režim ECB není tímto problémem zranitelný (i když jeho použití neschvaluji).

12
iamtheneal

Šifrování AES-CBC neposkytuje integritu. V závislosti na tom, jak je implementován a používán, se může stát, že odhalí některé náhodné úpravy ciphertext, ale brání proti škodlivému zásahu do ciphertext .

Šifrování bez ověřování je jednou z nejčastějších chyb při používání kryptografie . To vedlo k závažným zranitelnostem v mnoha systémech, včetně ASP.NET, šifrování XML, Amazon EC2, JavaServer Faces, Ruby na Rails, OWASP ESAPI, IPSEC a WEP. Viz předchozí odkaz pro více informací.

Oprava: Měli byste použít buď ověřené šifrovací schéma (nikoli AES-CBC), jako je EAX, nebo byste měli použít ověřovací kód zprávy, jako je CMAC, v režimu šifrování a autentizace.

Pokud se chystáte implementovat kryptografii sami, doporučujeme vám přečíst si otázku s názvem Poučení a mylné představy o šifrování a kryptologii , abyste se vyhnuli některým nejčastějším chybám. Použití šifrování bez ověřování je jedním z nich.

9
D.W.

Symetrické šifry samy o sobě neposkytují integritu, protože nezjistí škodlivé nebo náhodné úpravy ciphertext; dešifrování vydá něco jiného než původní prostý text a pokud to nepovede k narušení protokolu pro dešifrované užitečné zatížení, pak máte problém s integritou.

Řešením je zabalit obyčejný text do balíčků, které obsahují data, která lze použít k ověření integrity balíčku, obvykle kontrolní součet založený na hašiši ( editovat: ) klíčovaný HMAC). To se děje např. pro zabezpečení transportní vrstvy.

Zde je příklad schématu ochrany prostého textu použitého v zabezpečeném transportním protokolu bajtů Versile Platform (vyloučení odpovědnosti: Jsem zapojen do vývoje VP).

Úpravy: Uvědomil jsem si, že zapouzdření zpráv je pro váš scénář nadměrné, což zahrnuje kompletní soubor, takže je lepší začít přidávat pouze klíčový MAC do úplného souboru ciphertext. Pro formáty chráněné balíčky, jako D.W. poukazuje na podrobnosti a „kontrolní součet“ by měl být prováděn jako klíčový MAC.

5
Versile