Hlavní navigace

Proč a jak na šifrování disků v Linuxu?

Michal Dočekal 22. 5. 2008

Chtěli byste si v GNU/Linuxu zašifrovat celé disky či diskové oddíly a přemýšlíte, kudy na to vlastně jít? V tomto seriálu si představíme nativní linuxové řešení dm-crypt/LUKS. V prvním díle se podíváme na to, co je dm-crypt a LUKS a budeme se věnovat především teoretickému úvodu do diskového šifrování.

Ještě před nedávnem existovalo vedle sebe více implementací diskového šifrování v GNU/Linuxu (jmenovitě cryptoloop, loop-aes, dm-crypt), přičemž jednotlivé implementace různě bojovaly s některými problémy diskového šifrování v oblasti bezpečnosti. V současné době je standardem dm-crypt.

Dm-crypt je nativní součástí Linuxu, využívá linuxové CryptoAPI a device mapper. K práci s dm-cryptem slouží utilita cryptsetup. Dm-crypt má však sám o sobě stále několik nevýhod. Jedná se o nízkoúrovňový nástroj, který nezajišťuje správu hesel (jednomu zařízení tedy náleží pouze jedno heslo), neuchovává si informace o použité šifře, hashi a šifrovacím módu a neimplementuje žádný mechanismus pro zjištění, zda bylo zadáno správné heslo (což však může být v některých případech i výhodou).

Tyto problémy řeší LUKS, Linux Unified Key Setup, který je implementován jako upravený (avšak zpětně kompatibilní) cryptsetup (v některých distribucích je přítomen jako cryptsetup-luks, jinde je k dispozici jako cryptsetup). LUKS si můžeme představit jako nadstavbu dm-cryptu. Každý disk/oddíl, který zašifrujeme pomocí LUKS, je vybaven hlavičkou s použitou šifrou, hashí, šifrovacím módem a kontrolním součtem hlavního klíče (viz dále).

Správu hesel řeší LUKS prostřednictvím dvouúrovňového šifrování, kdy se disk/oddíl šifruje náhodně vygenerovaným silným klíčem (master key), který je pak zašifrován některým z (maximálně osmi) uživatelských klíčů. Tyto klíče se odvozují metodou PBKDF2, která zvyšuje bezpečnost slabších hesel. Tato metoda je v současné implementaci LUKS vázána na hashovací algoritmus SHA-1. To je v současné době asi jediné slabé místo LUKS. Ačkoliv se zdá, že o možnost použít pro odvození klíče i jiné algoritmy zájem je, dosud se nenašel nikdo, kdo by tuto funkci implementoval.

Pomocí LUKS můžeme snadno změnit heslo, aniž bychom museli oddíl přešifrovat. Stejně tak můžeme použít více hesel, a umožnit tak přístup na zašifrovaný disk/oddíl více uživatelům. Můžeme také používat klíče ze souborů (keyfiles), které pak můžeme umístit třeba na flashdisk nebo na jiný zašifrovaný oddíl. Možností je mnoho.

Diskové šifrování

Ještě než se pustíme do vlastního šifrování disků/oddílů, si povíme něco o diskovém šifrování. Předesílám, že nejsem kryptolog, takže ne všechno vím a ne všemu rozumím. Pokusím se říci to nejnutnější, co by bylo dobré vědět, abyste nebyli vystaveni falešnému pocitu bezpečí.

Předpokládám, že nemusím příliš rozvádět to, že diskové šifrování je nástrojem fyzického zabezpečení dat a uživatele nijak neochrání v situaci, kdy je šifrovaný disk/oddíl připojený a na váš stroj se zrovna proboural útočník ze sítě.

Diskové šifrování se od šifrování souborů či zpráv liší ve dvou rovinách. Předně, šifruje se řádově mnohem více dat (zejména v dnešní době, kdy už se běžně prodávají 1TB disky). Za druhé, šifrují se data a datové struktury (např. souborový systém), která mají jisté očekávatelné charakteristiky, které mohou usnadnit kryptoanalýzu, pokud se nepoužije ten správný šifrovací mód (viz dále), který pomůže tyto charakteristiky skrýt. Za třetí, pokud používáme šifrované a nešifrované souborové systémy pro různá data, musíme zajistit, aby data určená k šifrování „neprosakovala“ v nešifrované podobě mimo šifrované souborové systémy.

Šifry

Šifrovacích algoritmů je celá řada a výběr mezi nimi bývá spíše subjektivní otázkou. Rozhodně bych se vyhnul starším algoritmům (des, tripple-des, blowfish, apod.). Velmi často se pro diskové šifrování využívají AES (Rijndael) nebo AES finalisti (Twofish, Serpent, RC6 a MARS). V Linuxu nalezneme implementace všech zmíněných. Pokud je vaším kritériem rychlost, je nejvhodnější AES, jehož implementace je nejrychlejší. Je-li vaším primárním kritériem bezpečnost, doporučuji se na jednotlivé algoritmy podívat podrobněji a rozhodnout se, který z nich je pro vaše potřeby vhodnější.

Šifrovací módy

Jak už bylo řečeno, k diskovému šifrování se používají blokové šifry, tzn. data se šifrují po blocích o stejné velikosti. Zašifrujeme-li dva identické bloky stejným heslem, dostaneme dva identické bloky šifrového textu. Pokud bychom měli fragment souborového systému se samými nulami, po jejich zašifrování bychom tedy dostali několik stejných bloků šifrového textu. To by poskytlo útočníkovi cenné informace.

Abychom tomu zabránili, používáme šifrovací módy, které by měly zajistit, že útočník nebude schopen takto získat žádné informace. Běžným šifrovacím módem je CBC (Cipher Block Chaining), který se využívá i pro diskové šifrování. Naneštěstí není tento šifrovací mód navržen pro diskové šifrování. Časem byla nalezena nejedna zranitelnost tohoto šifrovacího módu. CBC tedy doporučuji se vyhnout, pokud můžete. Pokud z nějakého důvodu nemáte na výběr a musíte použít CBC, použijte alespoň ESSIV (cbc-essiv).

Pro diskové šifrování jsou vhodné především LRW a XTS, přičemž LRW se z důvodu objevené bezpečnostní slabiny v současnosti nahrazuje módem XTS. Oba šifrovací módy jsou k dispozici v linuxovém CryptoAPI. LRW je k dispozici v jádře 2.6.20 a výše, XTS je k dispozici od verze 2.6.24 výše. Nejbezpečnější z uvedených a mnou doporučovaný šifrovací mód je tedy XTS.

Únik šifrovaných dat

Zřejmě nejvíce podceňovaná oblast v rámci (nejenom) diskového šifrování je právě možnost úniku (de)šifrovaných dat (nebo informací o nich) mimo šifrované oddíly. To se může stát poměrně snadno, třeba pokud pro /tmp nepoužíváme ani tmpfs, ani šifrovaný oddíl. Stačí, aby si nějaký program do /tmp odložil nějaké dočasné soubory obsahující utajovaný materiál, se kterým zrovna pracujeme.

Kritickým místem je v každém případě swap, do kterého se mohou dostat kusy paměti s materiálem ze šifrovaných oddílů (v dešifrované podobě). Swap je tedy nutno buď vypnout, nebo také šifrovat, nejlépe náhodným heslem generovaným při každém startu systému.

Pokud máme šifrovaný oddíl na magnetickém médiu (např. pevném disku), musíme také uvažovat o možnosti rekonstruovat předchozí vrstvy záznamu. Pokud se rozhodneme zašifrovat nějaká data, která jsme měli dříve nešifrovaná na magnetickém médiu, bylo by vhodné provést bezpečný výmaz takového zařízení (k tomu se hodí třeba utilita  shred).

Zaplnění oddílu náhodnými daty

Před vlastním vytvořením zašifrovaného oddílu bývá vhodné příslušný oddíl zaplnit náhodnými daty, čímž se o něco zvýší bezpečnost celého řešení – útočník pak (v ideálním případě) není schopen odlišit, kde jsou zašifrovaná data a kde je pouze shluk náhodných bytů, což činí případný útok na zašifrovaný oddíl obtížnějším. Efekt tohoto kroku je pak přímo úměrný kvalitě generátoru náhodných čísel. Jak zaplnit oddíl náhodnými daty a jaké generátory náhodných čísel můžeme použít, to si řekneme později.

Zašifrování celého systému

Zašifrovat celý linuxový systém pomocí LUKS možné je, s výjimkou zavaděče, jádra a iniciálního ramdisku (který potřebujeme k zavedení potřebných modulů a skriptu, který nám umožní zpřístupnit šifrovaný root). S tím je spojená jedna možnost útoku na šifrovaný systém – modifikováním jádra či zaváděcích skriptů, které po úpravě útočníka zachytí heslo a někam ho uloží či odešlou.

Možnosti řešení této bezpečnostní hrozby jsou dvě. Buď umístíme nešifrovaný /boot na flashdisk, který budeme mít bezpečně uložený, nebo si vytvoříme skript, který spočte kontrolní součty příslušných souborů a upozorní nás v případě jejich změny. Tato opatření samozřejmě závisí na charakteru šifrovaných dat a úrovni naší paranoie.

Stinné stránky diskového šifrování

Diskové šifrování přináší kromě jistých výhod i řadu nevýhod. Předně, je velmi jednoduché přijít o šifrovaná data (stačí zapomenout heslo, nebo, v případě LUKS, přepsání hlavičky s úložištěm uživatelských klíčů). Diskové šifrování také zkomplikuje veškeré záchranné operace v případě HW problémů s médiem (silně tedy doporučuji zálohovat). Chyba v jediném bitu způsobí minimálně ztrátu celého bloku. V tomto kontextu je vhodné zmínit, že je možné použít šifrování nad jakýmkoliv RAID polem, třeba nad jedničkou (zrcadlení). Šifrování také o něco zpomaluje diskové operace (čtení/zápis), respektive činí je závislými na CPU. Vyšší zátěž CPU znamená větší spotřebu a vyšší teplotu, což se podepíše třeba na životnosti baterie laptopu nebo na účtu za elektřinu.

Aby naše snaha zabezpečit šifrovaná data nepřišla nazmar, musíme brát šifrování vždy v potaz. Pokud zálohujeme, určitě bychom měli vytvářet zálohy šifrované. Úplně nejhorší je nechat nešifrované zálohy na stole vedle počítače s šifrovaným systémem. V takovém případě šifrování nemá vůbec žádný smysl.

Dopad šifrování na diskové operace

Je jasné, že šifrování zatíží procesor, takže čím rychlejší procesor máte, tím méně budou diskové operace omezené. Různé šifrovací algoritmy jsou navíc různě rychlé, takže čím rychlejší algoritmus (resp. jeho implementaci) zvolíte, tím více MB/s zvládne procesor zpracovat. Aby to nebylo tak jednoduché, některé algoritmy (třeba Rijndael a Twofish) mají více implementací optimalizovaných na různé platformy (i586, x86_64). Je tedy vhodné zajistit, že se nahraje modul s těmi optimalizacemi, které vaše platforma zvládne.

Na mé sestavě s Athlonem 64 (s 32bitovým systémem) taktovaným na 2,0 GHz je pořadí algoritmů v závislosti na výkonu následující (hodnoty jsou průměrné získané řadou pokusů):

Výkon jednotlivých algoritmů
Algoritmus MB/s
Rjindael 37,35
Serpent 31,95
Twofish 26,25
Anubis 21,40
CAST6 20,9

Hodnoty je samozřejmě nutné brát čistě orientačně, neb jsou svázány s procesorem mé sestavy, ale lze z nich vyčíst, které algoritmy (resp. jejich implementace) jsou rychlejší než ostatní. Nejrychlejší z použitých algoritmů je, jak vidíme, Rijndael (AES), v těsném závěsu je Serpent, Twofish je na tom o něco hůře a šifry jako Anubis a CAST6 jsou spolehlivě nejpomalejší.

Vzhledem k charakteru pevných disků je jasné, že největší zátěž bude šifrování způsobovat při sekvenčním čtení/zápisu, tj. při kopírování velkých souborů (nejlépe z jednoho šifrovaného oddílu na jiný šifrovaný oddíl). Naopak ve chvíli, kdy bude pevný disk provádět náhodné čtení/zápis (při práci s velkým počtem malých souborů rozesetých po celém disku), bude zátěž způsobená šifrováním minimální (zdržovat bude pevný disk).

Co se týče provádění běžných úkonů, dopad šifrování není až tak kritický. Na výše zmíněné sestavě neregistruji dopad šifrování ani při hraní her jako Doom III a UT2004, natož při běžné kancelářské práci (prohlížeč, kancelářské balíky). Jediné místo, kde vidím potenciální problém, je při vypalování DVD, kdy se de facto provádí (téměř) sekvenční čtení, avšak i to má sestava utáhne (byť s poměrně zatíženým procesorem).

Našli jste v článku chybu?

22. 5. 2008 10:14

Doufám, že návod dostatečně podrobný je. Samozřejmě, pokud nebudete čemukoliv rozumět, zeptejte se a já rád dovysvětlím.

U převodu existujícího systému na šifrovaný bohužel o žádné snadné cestě nevím. Nějaký konvertor by mohl existovat pro jednotky šifrované dm-cryptem, ale ne pro LUKS (LUKS hlavička o něco šifrovanou jednotku zmenšuje). A i kdyby existoval, bylo by jeho použití velmi nebezpečné (výpadek proudu či SW chyba a konec). Nehledě na to, že pouhé zašifrování existujících dat by otev…

22. 5. 2008 15:28

Ne. Jenoduše ne. Respektive, nějak ručně by se vám to podařit mohlo, ale moc bych si s tím nehrál, abyste nepřišel o data.

Teoreticky, pro zmenšení kontejneru byste musel neprve změnit velikost souborového systému na dané šifrované jednotce. Pak byste musel odhadnout, kde přesně (v daném kontejneru) končí souborový systém a spočítat, o kolik můžete soubor oříznout (pozor na LUKS hlavičku). Pak byste soubor ořízl a doufal, že se k datům ještě někdy dostanete.

Zvětšení by bylo o něco…

Podnikatel.cz: Víme první výsledky doby odezvy #EET

Víme první výsledky doby odezvy #EET

Podnikatel.cz: Přehledná titulka, průvodci, responzivita

Přehledná titulka, průvodci, responzivita

Vitalia.cz: Manželka je bio, ale na sex moc není

Manželka je bio, ale na sex moc není

Lupa.cz: Na koho se v Křišťálové Lupě nedostalo?

Na koho se v Křišťálové Lupě nedostalo?

Měšec.cz: Zdravotní a sociální pojištění 2017: Připlatíte

Zdravotní a sociální pojištění 2017: Připlatíte

Lupa.cz: Google měl výpadek, nejel Gmail ani YouTube

Google měl výpadek, nejel Gmail ani YouTube

Lupa.cz: Proč firmy málo chrání data? Chovají se logicky

Proč firmy málo chrání data? Chovají se logicky

Vitalia.cz: Tesco: Chudá rodina si koupí levné polské kuře

Tesco: Chudá rodina si koupí levné polské kuře

Root.cz: Vypadl Google a rozbilo se toho hodně

Vypadl Google a rozbilo se toho hodně

Vitalia.cz: Dáte si jahody s plísní?

Dáte si jahody s plísní?

Podnikatel.cz: Chtějte údaje k dani z nemovitostí do mailu

Chtějte údaje k dani z nemovitostí do mailu

Podnikatel.cz: Podnikatelům dorazí varování od BSA

Podnikatelům dorazí varování od BSA

Podnikatel.cz: Prodává přes internet. Kdy platí zdravotko?

Prodává přes internet. Kdy platí zdravotko?

120na80.cz: Rakovina oka. Jak ji poznáte?

Rakovina oka. Jak ji poznáte?

Lupa.cz: Co se dá měřit přes Internet věcí

Co se dá měřit přes Internet věcí

Vitalia.cz: To není kašel! Správná diagnóza zachrání život

To není kašel! Správná diagnóza zachrání život

Lupa.cz: Avast po spojení s AVG propustí 700 lidí

Avast po spojení s AVG propustí 700 lidí

Vitalia.cz: Jsou čajové sáčky toxické?

Jsou čajové sáčky toxické?

Podnikatel.cz: Babiš: E-shopy z EET možná vyjmeme

Babiš: E-shopy z EET možná vyjmeme

120na80.cz: Jak oddálit Alzheimera?

Jak oddálit Alzheimera?