tc-play, náhrada za truecrypt

25.10.2012 23:35 | Přečteno: 3576× | Linux |

Včera jsem narazil na projekt tc-play, a protože jsem si jeho základy už stihl osahat, je čas představit jej veleváženému publiku.

Začnu mírně zeširoka: před pár dny jsem si koupil externí disk na zálohování a začal přemýšlet, jak jej – nebo alespoň jeho část – šifrovat. Odbočka: úplně nejdřív jsem vybíral souborový systém: NTFS jsem zavrhl spolu s FAT32 (z ideologických i technických důvodů), ext[234] jsou zase dost blbě podporované ve windows. Zbyl mi UDF, s tím by si měly rozumět windows, Mac OS X a samozřejmě linux.

Mé nadšení z volby UDF vychladlo, když jsem zjistil v jakém stavu jsou UDF tools. Je to smutný stav. Souborový systém vytvořený pomocí mkudffs je pod windows nečitelný, zdrojový kód nástroje udffsck obsahuje následující sofistikovaný kód:

int main(int args, char *argv[])
{
  return 0;
}

Ale zpět k tc-play, truecryptu, šifrování a tak. Zadání znělo jasně: chci šifrovat pod linuxem a zároveň mít možnost přistupovat k datům i z windows. To, pokud vím, umí řešit jedině truecrypt. Ten má ale i pár nevýhod:

• poměrně restriktivní licenci, kvůli které je v Gentoo potřeba zdrojáky stahovat ručně,
• nutnost nainstalovat wxGTK,
• dokonce i s USE="-X" to pořád ještě chce nainstalovat wxGTK…

No, a pak jsem narazil na tc-play. Je to celkem plnohodnotná a kompatibilní náhrada za truecrypt určená pro Linux a DragonFly BSD. Nepotřebuje wxGTK. Umí pracovat se skrytými oddíly (používá to někdo?). Obejde se bez wxGTK! Kaskády šifer jsou podporované též. Už jsem se zmínil, že to nepotřebuje wxGTK?

Co je k potřeba

Potřeba je hlavně jádro s podporou device mapperu a šifrovacích a hashovacích algoritmů. Pokud máte takové to distribuční jádro s jedním milionem dvěma sty osmatřiceti tisíci čtyřmi sty padesáti moduly v /lib/modules, pak si nemusíte dělat starosti. Vy ostatní budete potřebovat mít zaškrtnuto Device Drivers → Multiple devices driver support (RAID and LVM) → Device mapper support. Pak ještě Cryptographic API → XTS support a používané šifrovací a hashovací algoritmy: třeba Whirlpool a AES. Dál bude třeba si tc-play přeložit, což (v prostředí linuxu) spočívá ve stažení (verze 0.10 je ke mání na githubu) a rozbalení zdrojáků a následném spuštění programu make. Pokud vám překlad spadne s chybou

io.c: In function ‘read_passphrase’:
io.c:388:3: warning: signed and unsigned type in conditional expression
io.c:388:3: warning: signed and unsigned type in conditional expression

pak v souboru Makefile najděte direktivu -Werror a odstraňte ji. Instalovat musíte svépomocí, žádný make install se nekoná.

Jak se tc-play používá

Vezme se blokové zařízení (třeba pokusná SD karta) a vytvoří se na ní šifrovaný oddíl. Jako hashovací funkci jem si zvolil whirlpool a jako šifrovací algoritmus AES s klíčem dlouhým 256 bitů a módem XTS:

tcplay -c -d /dev/mmcblk0p1 -a whirlpool -b AES-256-XTS -z
Passphrase: 
Repeat passphrase: 
Summary of actions:
 - Completely erase *EVERYTHING* on /dev/mmcblk0p1
 - Create volume on /dev/mmcblk0p1

 Are you sure you want to proceed? (y/n) y
Creating volume headers...
Depending on your system, this process may take a few minutes as it uses true random data which might take a while to refill
Writing volume headers to disk...
All done!

Pak se šifrovaný oddíl pomocí device mapperu namapuje na zvolené blokové zařízení (třeba na mmcblk0p1crypt):

tcplay -m mmcblk0p1crypt -d /dev/mmcblk0p1
Passphrase: 
All ok!

Zbývá vytvořit souborový systém:

mkfs.vfat /dev/mapper/mmcblk0p2crypt 
mkfs.vfat 3.0.12 (29 Oct 2011)
unable to get drive geometry, using default 255/63

a připojit:

mount /dev/mapper/mmcblk0p2crypt /mnt/sd

Takto vytvořený šifrovaný souborový systém lze pod windows připojit truecryptem a bez problémů tam použivat.        

Komentáře

[Michal Fecko]

TCHead a TCHunt compatible? :D

[finn]

To první je nástroj pro brute-force attack. Stačí zvolit dostatečně silné heslo a nemá reálnou šanci. Kdyby šlo mít před hlavičkou truecryptu nějak elegantně pohozených několik bloků opravdu náhodných dat, TCHead by byl úplně nahraný (-:

TCHunt jen hledá soubor s náhodně vypadajícím obsahem, takže mne nevzrušuje už vůbec – já chci chránit data, ne informaci o tom, že existují. Navíc TCHunt neříká: „tohle je zašifrované truecryptem“ – dokáže jen říct „tohle by asi mohlo být zašifrované truecryptem“.

[Jendа]

Kdyby šlo mít před hlavičkou truecryptu nějak elegantně pohozených několik bloků opravdu náhodných dat, TCHead by byl úplně nahraný (-:

Proč to? Prostě by těch prvních pár bloků přeskočil a začal crackovat až o kus dál.

[finn]

Myslel jsem to tak, že o těch počátečních blocích bych věděl jen já, jinak to samozřejmě nemá smysl. Takové uživatelské rozšíření truecryptu… (-:

[Jendа]

Aha, takže bys místo hesla zadával při připojování ještě offset a útočník by pak musel udělat pro každé heslo N pokusů (vyzkoušení možných offsetů). Počkat, nepomůžeme si úplně stejně, když jako heslo nastavíme "naše stávající heslo"+"nějaké náhodné číslo, které by bylo offset"?

(operátor + je zde concatenation stringů)

[finn]

Ano, cokoliv v tom smyslu. No, stejně nevím, jak to transparentně zařídit, takže to je asi planá debata (: Ani to zařídit asi nechci, stačí mi heslo dostatečně odolné proti slovníkovému útoku. Nepředpokládám, že by se o moje data zajímala CIA/FBI/NSA/BIS... A nějakej Franta Kedlubna se na na brute-force útok nezmůže.

[Jendа]

No, stejně nevím, jak to transparentně zařídit, takže to je asi planá debata (:

Offset pomocí parametrů dm-setup/losetup, concat stringů snad umíš v hlavě sám :).

Nejlepší je heslo odolné i proti bruteforce (myšlena výpočetní síla) třípísmenkových organizací. Tak 20 znaků z a-zA-Z0-9 by mohlo stačit.

[Radek Hladik]

Přiznám se, že úplně nechápu to s tím wxGTK... To to jako fakt nepotrebuje?

Ale ted vážně. Opravte mně, pokud se mýlím, ale měl jsem pocit, že se TC dá používat z command line, kompletně bez GUI. Tedy to wxGTK je tam potřeba mít jen kvůli překladu a pak jen jako "nepoužitou" knihovnu. A k tomu směřuje můj dotaz, opravdu vám tohle vadí tak moc, že radši místo toho použijete nějaký jiný projekt, který nemáte pořádně vyzkoušený, který může zlobit, být nekompatibilní, atd? Jako pochopil bych to třeba u prohlížeče fotek, browseru nebo media playeru, ale v tomto případě to já vidím tak, že riskujete důležitá data z podle mně naprosto nepodstatného důvodu. Dovedu si představit X způsobů, jak se ten tc-play pobouchá s klasickým truecryptem, jak něco zmrcosí, atd... A v nejhorším případě si toho ani nevšimnete a za rok zjistíte, že ty data jsou poškozený. V nejhoršim by se přeci ty wxGTK dali nainstalovat někam do /opt/tadyurcitenjsouwxgtk a nasmerovat tam jen a pouze truecrypt

[Michal Fecko]

Dobra pointa.. Fakt - kedze je command line binarka, musi ist skompilovat bez wxGTK a navyse tych moznosti kde sa moze tc-play s tc v implementacii rozchadzat je dost vela...

[finn]

No, tohle je reklama na zajímavý projekt. Když ho díky téhle reklamě začne používat víc lidí, zmenší se naděje, že projekt sejde na úbytě, a naopak se zvětší šance, že se vychytají případné chyby (na žádné jsem zatím nenarazil).

Nebojím se ani tak ztráty dat (data budu mít zálohovaná ještě na počítači), chci zabránit tomu, aby – když někde ztratím ten externí disk – se k nim dostal někdo cizí.

Líbí se mi, že tc-play je jednoduchý, zdrojáky mají pár kilobajtů, složitější věci (šifrování, hashování) dělá jádro a openssl. Taky nepotřebuje FUSE. A wxGTK mi u truecryptu opravdu docela vadí. Pokud je potřeba pro používání command-line verze truecryptu, naznačuje to něco o kvalitě kódu (jedním ze základů bezpečného programování je modularita). Je to prostě postavené na hlavu. Instalovat takového molocha (zdrojáky wxGTK jsou velké pomalu jako půlka firefoxích) jen kvůli programu, který budu spouštět z příkazové řadky...to tedy ne.

[Radek Hladik]

Ty výhody, co zmiňujete všechny chápu. A kdybych si měl vybrat projekt na šifrování jen na linuxu, tak bych o něm uvažoval. Ale z čeho mám strach je ta kompatibilita mezi tím a truecryptem...

Přiznám se, že nevím, jak moc command line od tc ty wxgtk vyžaduje. Jestli je to klasické slinkování s SO, bez kterého to systém nespustí nebo zda je tam něco hlubšího. A je přeci možné, když by to wxgtk bylo jen kvůli tomu tc, nainstalovat binárky a includy, přeložit a pak těch pár so, někam dát, kde o nich bude vědět jen ten tc, ne? Nebo udělat statickou binárku a je to...

[Jendа]

Umí pracovat se skrytými oddíly (používá to někdo?).

Ne, protože to saje.

A nepoužívá ani žádné lepší šifrování s takovou funkcí, protože moc dobře ví, že z něj v případě potřeby stejně vymlátí úplně všechno.

[Miloslav Ponkrác]

TrueCrypt je prověřený projekt. Je otestovaný, dokonce si vzaly na paškál i různé kryptografické autority a zjistily, že je opravdu bezpečný.

Licence TrueCryptu se mi velmi líbí, protože zaručuje, že kdokoli TrueCrypt forkne, tak z forku musí zmizet všechno, co by uživateli mylně dávalo najevo, že je to TrueCrypt. Tedy fork musí jasně dát najevo, že to není TrueCrypt, což je podstata licence.

Jinak řečeno, máte jistotu, že TrueCrypt je TrueCrypt a ne klon (samozřejmě za předpokladu, že fork ctí zákony a licence).

Data jsou to nejcennější co mám, a proto licenci TrueCryptu plně vítám a beru to jako bod pro něj.

Pochopil jsem, že hlavním důvodem tc-play je licence. To je mi ukradené. Navíc tc-play si může forkovat kdo chce jak chce, stejně tak jako si jej linuxové distribuce mohou upravovat jak chtějí – a žádná záruka na jeho funkčnost není.

Byly doby, kdy MySQL obsahovala chyby, které nikdy nebyly v originálních zdrojácích, ani v originálních binárkách, ale projevovaly se jen v určitých linuxových distribucích. Je iluze, že by baliči linuxových balíčků a upravovači udělali vše správně a lépe, než autoři projektu.

Jinak řečeno, právě licence tc-playe je důvod tento projekt nepoužívat na má data.

[cthulhu]

Odbočka: úplně nejdřív jsem vybíral souborový systém: NTFS jsem zavrhl spolu s FAT32 (z ideologických i technických důvodů)

mkfs.vfat /dev/mapper/mmcblk0p2crypt

WTF?

[finn]

Vezme se blokové zařízení (třeba pokusná SD karta)…

[Radek]

A jaký file system jste nakonec vybral?