Portál AbcLinuxu, 20. května 2024 13:26

Šifrování s TrueCrypt – 2 (skryté oddíly, výkon)

14. 8. 2009 | Jan Hrach
Články - Šifrování s TrueCrypt – 2 (skryté oddíly, výkon)  

Pod kapotou skrytých oddílů: Jak vznikají, jak jsou chráněny, jak je poškodit. TrueCrypt Hunt a odhalování skrytých oddílů. Měření výkonu, srovnání s dm-crypt.

Aktualizace

Aplikace TrueCrypt je již neudržovaná (od roku 2014). Jeho nástupcem je VeraCrypt.

Obsah

Pod kapotou skrytých oddílů

link

Pokusím se vám přiblížit, jak to pracuje uvnitř.

Když průvodce vytvoří vnější (zatím ještě normální) oddíl, vytvoří v něm filesystém VFAT a připojí ho. Uživatel si pak do něj nakopíruje rádobytajná data a v průvodci klikne na Next. Průvodce souborový systém odpojí a proskenuje. Pokusí se najít co nejdelší nepřerušované volné místo. (Což je docela jednoduché, protože na VFAT se bloky alokují od začátku – volné místo bude obvykle na konci. To je také důvod, proč se skrytý oddíl netvoří na ext2 – zálohy superbloků jsou různě po disku a data také.) V něm vytvoří skrytý oddíl (hlavičku přilepí hned za hlavičku vnějšího oddílu, v dokumentaci je obrázek, z toho je to snad lépe pochopitelné).

Skrytý oddíl už může být naformátován libovolným souborovým systémem, z důvodů uvedených dále se osvědčil ext2.

Pokud připojíme vnější oddíl se zapnutou ochranou skrytého oddílu, TrueCrypt si rozšifruje jeho hlavičku, zjistí, kde se nachází, a chrání jej. Ovšem problém je v tom, že skrytý oddíl je na místě, které souborový systém vnějšího oddílu považuje za své (což je dobře, protože zmenšení souborového systému vnějšího oddílu by bylo nápadné) a může na něm chtít alokovat bloky. Když TrueCrypt uvidí, že se ovladač souborového systému snaží alokovat blok skrytého oddílu, zabrání mu v tom (a překlopí se do read-only režimu, aby tím zabránil dalším pokusům o destrukci). To vyústí v I/O error a zároveň poškození souborového systému vnějšího oddílu. Pokud bude těchto poškození víc a vydáte heslo k vnějšímu oddílu, určitě někomu přijde divné, že jsou bloky určité spojité oblasti poškozené. Z toho plyne, že do vnějšího oddílu byste radši moc zapisovat neměli.

Pokud připojíme vnější oddíl bez ochrany a začneme do něj zapisovat, dřív nebo později přepíšeme nějaký blok skrytého oddílu.

Vytvořil jsem si pár skrytých oddílů, nakopíroval jsem do nich nějaká data a zkoušel jsem, co při připojení bez ochrany vydrží. Začal jsem s ext2. Ten je překvapivě odolný. Ovladač sice oznámí, že je filesystém opravdu hodně rozbitý a remountuje ho ro (read-only, pouze pro čtení), ale pokud už se nám ho podaří připojit, opravdu přečteme většinu toho, co tam ještě zbylo. Občas třeba chybí půlka souboru, nebo mají nesmyslná data změny, ale dá se to. Byl jsem překvapen, kolik toho ext2 vydrží.

FAT je na tom mnohem, ale mnohem hůř. Protože je vnější oddíl také FAT a plní se od začátku, hned, jak se zaplní až ke skrytému oddílu, přemázne jeho začátek. Bohužel na začátku je FAT tabulka a bez ní se oddíl nepřipojí. Před zkázou vás může zachránit snad jenom fragmentace na vnějším oddíle, ale i tak je to dost o ústa. Resuscitovat jednotlivé soubory můžete také zkusit programem photorec.

Takže několik postřehů k používání skrytých oddílů:

A ještě několik námětů k zamyšlení.

Paranoia…

TrueCrypt Hunt

link

Jedna laboratoř vydává program TCHunt, který prý umí detekovat truecryptové kontejnery. Bylo kolem toho docela haló, ale vypadá to, že to moc nefunguje. Program je closed-source (uzavřený), ale jednu dobu byla na jejich webu přístupná metodika měření. Už ji stáhli, ale někde ještě žije.

The Four TCHunt Attributes:
1. No File Header.
2. (File size % 512) = 0
3. Successful X2 and Arithmetic Mean tests on certain bytes.
4. File size greater than 19KB (Legacy) or 275KB (Current).

…takže pro zmatení by mělo stačit přilepit na konec šifrovaného souboru pár náhodných bajtů :-)

Udělal jsem si vlastní testy (program bohužel nefunguje pod Wine) a 6 ze 7 vzorků z /dev/urandom mi to detekovalo jako šifrované oddíly a 1 ze 3 šifrovaných oddílů to nedetekovalo.

Měření výkonu

link

A úplně nakonec se podíváme, jak si stojí TrueCrypt v porovnání s dm-cryptem z hlediska výkonu. Čekal jsem u TrueCryptu propad (FUSE), ale ten nakonec nebyl tak velký. Přístup na truecryptovou jednotku se zapnutou ochranou skrytého oddílu je ale pochopitelně pomalejší.

Testoval jsem na svém desktopu: Sempron 1,8 GHz, disk 80GB Seagate s 7200 otáčkami za minutu. Připojil jsem si tmpfs a nakopíroval do něj 256 MB z /dev/urandom. To jsem poté pomocí dd kopíroval na šifrované oddíly. V prvních dvou případech přímo na oddíl, ve třetím případě do souboru na VFAT. Souborový systém ale brzdou nebyl, zkoušel jsem kopírovat i do souborového systému s vypnutou ochranou skrytého oddílu a rychlost byla stejná jako u kopírování přímo na zařízení.

Ve všech případech bylo šifrováno šifrou AES s délkou klíče 256 bitů v módu XTS. Velikost bloku dd byla 512 bytů, zkoušel jsem to i s bs=1MB a rychlost byla u všech měření o 1-2 MB/s vyšší. dd bylo spouštěno s parametrem conv=fsync a před každým měřením byla vyprázdněna cache zápisem 3 do /proc/sys/vm/drop_caches.

truecrypt graf

Související články

Šifrování s TrueCrypt
Podepisování a šifrování s GnuPG
Šifrované filesystémy - I
Šifrované filesystémy - II
ProFTPD + MySQL + Quota + šifrování
IPSec v kernelu 2.6 - I
IPSec v kernelu 2.6 - II
OpenSSH - bezpečně a pohodlně
SSL - je vaše bezpečné připojení opravdu zabezpečené?
SSL - 1 (certifikáty)
SSL - 2 (elektronický podpis)
IPSec na Linuxu, krok za krokem - 1
IPSec na Linuxu, krok za krokem - 2
Reportáž: Smart Card Forum 2009

Odkazy a zdroje

truecrypt.org

Další články z této rubriky

V sobotu se uskuteční konference CryptoFest
Pozor na androidové aplikace
Silent Circle představil bezpečný smartphone Blackphone 2
Android je bezpečnější, řada hrozeb však stále přetrvává
Avast varuje před nebezpečnými aplikacemi v Google Play

ISSN 1214-1267, (c) 1999-2007 Stickfish s.r.o.