BestCrypt Volume Encryption v3
V průběhu ledna nebo února by měla vyjít třetí verze programu BestCrypt Volume Encryption (článek). Normálně o novinkách nepíšu, tahle ale obsahuje několik nových vlastností s různými zajímavými dopady, které buď mají obecnou platnost, nebo mohou být dost nepříjemné, proto udělám výjimku. Na své si tedy přijdou i uživatelé jiných šifrovacích nástrojů.
Pozn.: Oficiálně byl zveřejněn jen seznam novinek na uživatelské úrovni. Většina informací, které zde uvádím, pochází z mého zkoumání alpha verze a z komunikace s vývojáři, tzn. nemusí být úplně stoprocentně přesné (v některých oblastech se jen dohaduji).
Podpora pro šifrovací klíč uložený mimo kontejner
Tato funkce umožňuje fyzicky oddělit šifrovaná data a klíč k nim. Tím pádem případný útočník musí získat přístup k oběma komponentám – i kdyby znal heslo a měl kopii zašifrovaného disku, je mu to na nic, pokud zároveň nemá i flashdisk s klíčem, a naopak, flashdisk s klíčem mu nijak nepomůže, pokud k němu současně nezná heslo a nemá samotná zašifrovaná data. Útok se tak stává podstatně složitějším.
Starší verze BCVE k dosažení dvoufaktorové autentizace používaly tokeny od firmy SafeNet (dříve Aladdin); šifrovací klíč byl uložen na tokenu a z něj si ho BCVE vyžádal, pokud potřeboval (samozřejmě pokud byl token připojen k počítači a uživatel zadal správné heslo). Nová verze podporuje tokeny i nadále, nově přibyla možnost použít k umístění klíče i obyčejný flashdisk – nebude to možná tak bezpečné jako token*), ale je to mnohem dostupnější, protože nějaký flashdisk má snad každý, zatímco tokeny jsou spíš vzácností.
Není mi úplně jasné, jaká zařízení jde pro uložení klíče použít – klasická flashka zformátovaná na FAT32 jde, disketa nejde, disky připojené na SATA řadič nejdou. Flashku zformátovanou na NTFS jsem nezkoušel, eSATA nemám.
Příjemné je, že BCVE podporuje tuto funkčnost pro všechny typy svazků – datové i bootovací. Chování se podle toho liší – u datového svazku se prostě v kořenovém adresáři flashky vytvoří soubor key_storage.bin, ve kterém je uložena identifikace svazku a zašifrovaný šifrovací klíč, u bootovacího svazku BCVE vytvoří plný záchranný disk (tzn. zformátuje flashku pro podporu bootování a Rescue operací a pak tam nahraje klíč). Svazek pak jde přimountovat pouze tehdy, kdy je k počítači připojena klíčenka se správným souborem. Soubor můžete zkopírovat i na jinou flashku (nebo dokonce na jiný pevný disk k počítači připojený, akorát to bude tak trochu postrádat logiku) a BCVE si ho tam najde.
*) Bezpečnost tokenů je docela otázkou. Pokud platí předpoklad, že z tokenu nejde klíč dostat bez znalosti hesla, je token jistě bezpečnější řešení (už kvůli hardwarově vynucovanému omezení na počet pokusů o zadání hesla – zatímco do programu můžete hrnout hesla tak rychle, jak to procesor bude stíhat, token se po třech až deseti chybných pokusech smaže a útočník má smůlu). Pokud však k tomuto předpokladu nemáte důvěru (já ji nemám, to je ovšem dané primárně tím, že o vnitřním fungování tokenů nic nevím), může pro vás „netokenové“ řešení s velmi dlouhým heslem být přijatelnější.
Srovnání s TrueCryptem
TrueCrypt je v tomto ohledu tak trochu chytrá Horákyně: Umístění šifrovacího klíče na externí disk v zásadě nepodporuje, umožňuje však zazálohovat hlavičky kontejneru, čímž se dá dosáhnout téhož. Odstranit šifrovací klíč z kontenjeru nejde, ale jde do něj obnovit jinou (nesprávnou) hlavičku, čímž opět dosáhnete téhož. Takový kontejner však nejde bez dalšího zásahu přimountovat, leda že by šlo o bootovací disk – pak z něj TrueCryptovský Rescue disk umí systém nastartovat i v případě, že v kontejneru je špatná hlavička; pro datové soubory to ale nejde – musíte napřed obnovit správnou hlavičku. Požadavky na umožnění externích hlaviček zatím zůstávají nevyslyšeny.
Spuštění zašifrovaného počítače ze sítě
BCVE nově umí spustit počítač se zašifrovaným bootovacím diskem ze sítě. Funguje to na bázi PXE (Pre-boot Execution Environment), které se normálně používá u bezdiskových stanic nebo síťových instalací operačních systémů: Vy si někde na síti připravíte server s vhodným startovacím image souborem a TFTP serverem, který ten bootovací soubor předá počítači, který si o něj řekne. V kombinaci s BCVE to znamená, že image soubor obsahuje i šifrovací klíč k systémovému svazku (ovšem nezaheslovaný!), který si BCVE loader vytáhne a použije k přimountování systémového disku, ze kterého se spustí systém.
Jetico tuto funkci poměrně hlasitě propaguje jako podporu pro lepší zabezpečení firemních serverů, já bych ale byl opatrnější – pokud chcete jít touto cestou, je absolutně nezbytné dokonale fyzicky zabezpečit jak server, na kterém je image, tak samotný zašifrovaný počítač, a zejména zajistit, že nikdo nemůže do sítě připojit jiný počítač, který by se vydával za toho zašifrovaného chudáčka. Pokud kteroukoliv z těchto částí zanedbáte, získá útočník přístup k nijak nechráněnému šifrovacímu klíči, a s tím už by měla být hračka šifrovaný počítač odšifrovat. Přiznám se, že mám vážné pochybnosti, jestli je vůbec technicky realizovatelné tato zabezpečení zajistit.
Srovnání s TrueCryptem
TrueCrypt tuto funkčnost nemá vůbec, můžete ale využít jiný open-source nástroj – DiskCryptor, který je v řadě ohledů něco jako „TrueCrypt na steroidech“ – mimo jiné pracuje na bázi svazků (jako BCVE) a ne disků/partition (TrueCrypt) a třeba právě boot zašifrovaného počítače ze sítě umí už dávno.
Bezpečný bezzásahový restart
Pokud používáte počítač se zašifrovaným systémovým diskem, asi jste si všimli, že při každém restartu musíte zadat heslo. Což je vcelku pochopitelné z hlediska bezpečnosti, na druhou stranu ale nepříjemné z hlediska údržby. Protože preferuji první hledisko před druhým, dost mě vyděsilo, že se vývojáři Jetica rozhodli do nového BCVE implementovat podporu pro bezzásahový restart – že prostě není třeba zadávat heslo (což myslím podporuje už delší dobu PGP Whole Disk Encryption).
Naštěstí se ukázalo, že je to implementované velice šikovně, takže pokud nechcete, vůbec se vás to nebude týkat, a když to použít chtít budete, bude to vcelku bezpečné.
První důležitá informace: Pro bezzásahový reboot je vyžadován čip TPM (Trusted Platform Module). Tudíž pokud ho ve svém počítači nemáte, tak bezzásahový restart vůbec nebude fungovat. Důsledek 1: Pokud bezzásahový restart potřebujete, musíte koupit desku s TPM. Důsledek 2: Pokud se bezzásahového restartu bojíte, stačí mít desku bez TPM a můžete být v klidu.
Druhá důležitá informace: Osobně bych měl vážné výhrady k tomu, kdyby se šifrovací klíč měl někam na blíže nespecifikovanou dobu zapisovat, ale Jetico to implementovalo vážně moc pěkně: Klíč je normálně jenom v paměti (kde tak jako tak být musí, jinak by nešlo číst ani psát na zašifrovaný systémový disk), i když zapnete podporu bezzásahového rebootu. Když vypadne proud nebo zmáčknete tlačítko reset, máte tudíž smůlu a bezzásahový reboot neproběhne. Pokud ovšem ve Windows kliknete na Vypnout, BCVE detekuje událost „vypnutí Windows“, ověří si důvod (opravdové vypnutí, spánek, hibernace, reset…) a nastavení bezzásahového rebootu, a teprve když se ujiští, že jde o zamýšlený reboot a podpora je zapnutá, tak zapíše klíče do TPM. Po restartu se dostane ke slovu loader BCVE, ten načte klíč z TPM, smaže ho odtamtud, připojí systémový disk a pokračuje v bootování.
Tzn. klíče se někam zapisují pouze v případě, že jde o skutečný restart, a zapsané vydrží jen tu dobu, která uplyne od požadavku na vypnutí Windows do načtení loaderu z pevného disku – tedy normálně něco mezi sekundami až desítkami sekund. (Pokud zrovna nemáte v počítači hromadu pokročilých diskových řadičů, kterým testy po startu trvají hroznou dobu, nebo pokud vám nevypnou proud zrovna v tom krátkém mezičase…)
BCVE umožňuje podrobněji řídit, že se klíče mají zapisovat jen v určitém časovém intervalu (tzn. resety mimo tento interval budou ignorovány) nebo jen v omezeném množství. Nemohl jsem to vyzkoušet, protože TPM nedisponuji (ještě to tak!), ale moc bych na to nesázel – napsat program, který za uživatele hýbe myší a prostě si v BCVE nakliká potřebná nastavení, nemůže být zase tak moc složité.
Otázkou zůstává, nakolik je TPM skutečně „Trusted“, jak moc se mu dá důvěřovat, že z něj klíče může vyčíst jedině oprávněný kód.
Srovnání s TrueCryptem
TrueCrypt tuto funkci nemá a ačkoliv se každou chvíli vynoří nějaký firemní zákazník, který by ji chtěl, doufám, že ani mít nebude. Upřímně řečeno, byl bych radši, kdyby ji neměl ani BCVE, ale s aktuální implementací jsem ochoten se smířit.
Hardwarová akcelerace AES
Podpora pro instrukční sadu AES-NI v nových procesorech Intel znamená významné zvýšení výkonu šifrování a dešifrování algoritmu AES. Tedy, podle toho, jak to počítáte – pokud budete uvažovat hrubý výkon, je AES-NI super (TrueCrypt mi vykazoval cca pětinásobné zrychlení, BCVE tak asi dvouapůlnásobné – vyberte si podle svých sympatií, jestli je to proto, že programátoři TrueCryptu jsou lepší, nebo proto, že každý program používá jinou metodiku).
Jakmile začnete uvažovat reálný výkon „na disku“, není už situace tak veselá – diskové operace podstatně ovlivní dosažené výkony. Matematicky:
(Dá se k tomu dojít tak, že si vyjádříte celkový čas jako součet času šifrování (velikost bloku děleno výkon procesoru) a času zápisu na disk (velikost bloku děleno výkon disku), a uvědomíte si, že celkový čas se dá také vyjádřit jako velikost bloku děleno celkový výkon. Pak už je to jen o úpravách ze základní školy.)
Když si dosadíte odhadované výkonu CPU a disku s a bez HW akcelerace, zjistíte, že i výrazný nárůst rychlosti CPU se projeví jen v mírném nárůstu celkového výkonu, pokud se rychlost disku nezmění (a zůstane výrazně menší než rychlost CPU).
To aby vás nepřekvapil rozpor mezi tím, co píšou benchmarky, a tím, co vidíte v reálu.
A když už jsem nakousl benchmarky – BCVE v3 potěšil tím, že konečně ukazuje reálné údaje. Mimochodem je to zřejmě první program, který to dělá – ostatní, pokud vůbec zobrazují kolonku „výkon šifry při započítání výkonu disku“, používají pro disk nějaké úplně úchylné údaje, takže jejich výsledky jsou absolutně mimo realitu. Pro zajímavost srovnání BCVE v2 (jen softwarový AES, nesmyslné údaje pro rychlost disku) a BCVE v3 (sloupeček „Režim XTS + Diskový V/V“ ukazuje čísla, která odpovídají tomu, co si naměřím, když na ten disk zkusím zapisovat nebo z něj číst; jediný drobný problém je v tom, že mám v počítači víc různě rychlých disků a nevím, který z nich BCVE použil jako referenční):
BCVE v2
BCVE v3
TrueCrypt velmi optimisticky píše pro AES 1.6 GB/s 🙂
Rychlejší šifrování prázdných disků
Další výkonnostní změna se týká šifrování prázdných disků a je to tak trochu podfuk – ale v určitých situacích užitečný. Jde o to, že při prvotním šifrování svazku programy (nejen BCVE) načtou původní data, zašifrují je a zase zapíší na původní místo, a tohle celé dělají pro celý disk. Což může být dost zdlouhavé, pokud je ten disk velký.
BCVE proto přichází s fintou: Uživatel může říct, že mu na datech příslušného disku nezáleží, a BCVE v takovém případě jen označí celý disk jako zašifrovaný (to je skoro okamžité), zapíše do něj hlavičku (to taky) a nechá ho operačním systémem zformátovat (to jde taky rychle, pokud zvolíte rychlý formát). Všechno ostatní se nechá tak, jak to bylo – stejně se to postupně všechno přepíše, jak na nový zašifrovaný disk začnete zapisovat běžná data…
Tohle má samozřejmě dopad na soukromí: Pokud na disku už nějaká data byla, tak pravděpodobně zůstanou nepřepsána – a to možná i dost dlouho. Klidně je může někdo později najít, a to prosím bez hesla. Funkce je tedy vhodná tak akorát pro formátování úplně nových disků z výroby, případně už dříve zašifrovaných disků, ale absolutně se nehodí v případě, že chcete zašifrovat disk, který dříve nesl nezašifrovaná data. BCVE proto nabízí i jakýsi hybridní režim, kdy napřed celý disk přepíše a potom zrychleně zašifruje – ušetří tak asi polovinu času (čtení disku).
Srovnání s TrueCryptem
TrueCrypt tuto funkci nemá a pokud bych si měl vsadit, tak ani nikdy mít nebude – je absolutně neslučitelná s principem plausible deniability, a i když třeba většině uživatelů je plausible deniability lhostejné, pro tu menšinu, která ho potřebuje, je nesmírně důležité, aby TrueCrypt ve svém výchozím nastavení vytvářel „plausible deniability“-kompatibilní kontejnery (je trochu rozdíl, když svému útočníkovi řeknete, „Ne, nepoužívám skryté oddíly, prostě jsem nechal všechno ve výchozím nastavení a TrueCrypt udělal tohle“, než když ve stejné situace argumentujete něčím jako „Ne, skryté oddíly nepoužívám, podporu pro ně jsem sice omylem zapnul, ale žádný skrytý oddíl jsem nevytvořil“). Pro BCVE to není problém, protože skryté oddíly neumí, ale TrueCrypt – ani žádný jiný program, který skryté oddíly umožňuje – si nemůže tohle zrychlené formátování dovolit.
Čímž neříkám, že by to nebylo užitečné – když jsem si ještě myslel, že se pro síťové úložiště dá efektivně použít FreeNAS, tak by se mi funkce, která by zkrátila šifrování 9 TB oddílu (přes síť), zatraceně hodila (zvlášť když mi FreeNAS těsně před koncem, tj. asi po týdnu, řekl, že došlo místo).
Ochrana před snaživostí Windows
BCVE se chlubí schopností zablokovat některé iniciativní funkce Windows – třeba nabídku „Disk není zformátovaný, mám ho zformátovat?“, když v Průzkumníkovi kliknete na zašifrovaný, ale dosud nepřipojený disk. Jak moc by to bylo užitečné se můžete přesvědčit sami v diskusních fórech TrueCryptu v sekci Problems – na každé stránce najdete aspoň jednoho nešťastníka, který takhle přišel o celoživotní data, ke kterým pochopitelně nemá zálohu.
Jediný drobný problém je, že mi to ve virtuálním počítači nějak nechtělo fungovat. Jediným efektem, který jsem pozoroval, bylo, že se okno Průzkumníka čas od času bez zjevného důvodu (a bez jakékoliv chybové hlášky) zavřelo.
Robustnější metadata šifrovaných svazků
Další funkce, kterou jsem nevyzkoušel, jsou údajně robustější metadata šifrovaných svazků. Starší verze BCVE se totiž chovaly poněkud nevypočitatelně v případě, že uživatel něco měnil na tom, kde a jak je který svazek na disku umístěný. Pokud jste dělali nějaké záludné akce, třeba zvětšování nebo zmenšování svazků (ne nutně těch zašifrovaných!), tak jste o svá zašifrovaná data taky klidně mohli přijít. Já osobně jsem narazil dokonce i na případ, kdy jsem měl na jednom disku dva zašifrované svazky a ten první jsem rozšifroval – do druhého se nedalo dostat, dokud jsem zase nezašifroval ten první.
Tak to vše by prý teď mělo být minulostí. Šifrování svazků už by nemělo záviset na fyzickém umístění svazku na disku a mělo by tudíž být možné se na svazcích vyřádit po libosti – zvětšovat je a zmenšovat, rekonfigurovat softwarový RAID atd. Já si od toho slibuji hlavně větší jistotu při obnovách po pádu disku (od doby, co jsem přešel na RAID6, už mě to tolik nepálí, ale stejně…) – dosud byla otevřená otázka, co by se s šifrovaným svazkem stalo, kdybych ho bitově zkopíroval na jiný disk (asi by to nepřežil), a jak moc by byla kompatibilní bitová kopie nositelského disku. Neměl jsem příležitost to vyzkoušet a jsem za to rád, ale ještě radši jsem, že teď už snad tu obavu mohu pustit z hlavy.
Pozor ale na dvě věci!
Za prvé, tato změna metadat se neprovede sama od sebe. Momentálně si ji musíte vynutit tím, že disk dešifrujete (v libovolné verzi BCVE) a zase zašifrujete (ve verzi 3). Dokud to neuděláte, budou svazky stejně citlivé jako dosud.
Za druhé, změněné disky nejsou kompatibilní s BCVE verze 2. V aktuální alpha verzi, která doufám bude ještě změněna, dochází dokonce k skoro nejhorší možné situaci – svazek z verze 3 totiž jde přimountovat (tzn. přijme heslo, uzná, že je správné, a označí se jako připojený), ale použije pro dešifrování špatný klíč, takže na tom „připojeném“ disku uvidíte jenom náhodné smetí. Pokud v této situaci použijete nějaký nástroj na záchranu dat (GetDataBack apod.), což by bylo jen přirozené („Disk je normálně připojený, tak proč mi nic neukazuje? Třeba se jen poškodily systémové tabulky, pustím na to záchranné nástroje a bude.“), tak o svá data nejspíš navždy přijdete. Totéž, pokud si Windows i přes předchozí vylepšení prosadí svoji hlášku o formátování a vy ji odkliknete.
Nahlásil jsem tenhle problém Jeticu a snažil jsem se přitom zcela jednoznačně vysvětlit, proč je lepší nulová kompatibilita (BCVE nahlásí neplatné heslo) než aktuální stav, takže se to snad změní. Ale přesto si na to dejte pozor!
Což mi připomíná – pokud máte vytvořený BartPE disk s podporou BCVE, tak si ho nezapomeňte zaktualizovat na BCVE verze 3, ať se pak nedivíte…
Podpora pro novější hardware
Podpora pro nový model tokenů SafeNet eToken Pro Java. Z dokumentace není jasné, jestli se jedná o doplnění ke stávajícím tokenům Pro a R2 nebo o jejich náhradu, a moje tokeny se mi s BCVE nikdy nepodařilo uspokojivě zprovoznit, takže to nevyzkouším.
Přibyla také podpora pro pevné disky se sektory většími než 512 bajtů. To bude u moderních velkých disků čím dál aktuálnější.
No a to by mělo být zhruba všechno. Mě osobně těší hlavně podpora AES-NI a svazky odolné vůči přesunům, ostatní funkce pro mě vesměs nejsou až tak relevatní – ale třeba způsob, jak je vyřešena podpora pro bezzásahový restart, se mi velice líbí. Myslím, že je na co se těšit.
Ve verzi 3.00.25 (příští betaverze) bude mít BCVE funkci pro automatické odpojování svazků při uspávání počítače. Myšlenka je taková, že pokud je svazek připojený, není chráněný; tudíž má smysl v okamžiku, kdy lze očekávat delší nepoužívání svazku, ten svazek odpojit. Dosud jsem to řešil pomocí AutoHotKey a čekáním na zprávu WM_POWERBROADCAST, teď to ale půjde udělat přímo prostředky BCVE: pokud svazek označíte jako odpojitelný, tak těsně před tím, než počítač přejde do režimu spánku (Suspend), BCVE tento svazek odpojí.
Funkce bude aspoň zpočátku nedokumentovaná, protože náhlé odpojení svazku může vést ke ztrátě dat; je třeba, aby si uživatel sám ohlídal, že je bezpečné svazek odpojit. Zatím není jasné, jak to zařídit, aby si tohle uvědomili i méně zkušení uživatelé, tudíž funkce zatím určitě nedostane položku v menu a je otázka, jestli bude zmíněná v dokumentaci. Ale dostal jsem povolení návod napsat sem.
Zapnutí nebo vypnutí tohoto režimu se dělá na příkazové řádce programu
bcfmgr.exe. K dispozici jsou tři volání:1)
bcfmgr.exe -SetDOS D:– Zapne podporu pro „odpojení před uspáním“ pro svazekD:.2)
bcfmgr.exe -ResetDOS D:– Zruší pro svazekD:podporu pro „odpojení před uspáním“.3)
bcfmgr.exe -GetDOS– Zobrazí seznam svazků, pro které je podpora pro „odpojení před uspáním“ zapnutá.Dostal jsem předběžnou verzi s touto funkcí a na svém notebooku jsem ji zapnul. Zatím funguje bez chybičky.
Užitečná informace ke struktuře Rescue souborů (z mailu od Jetica):
Dnes ráno byla uvolněna veřejná betaverze. Zatím jsem neměl čas ji vyzkoušet, učiním o víkendu. Support Jetica mi psal, že přinejmenším některé z mnou hlášených chyb byly opraveny, tak uvidíme :-). Download si můžete vyžádat zde.
dobra prace…
dobré postřehy, díky!