Cold boot útok – popis, obrana

5. 11. 2010 | Jan Hrach | Bezpečnost | Návody | 22392×

Na konferenci LinuxAlt (6.-7. 11. 2010) předvede Petr Krčmář ve svém příspěvku Jak prolomit šifrování disku za dvě sekundy takzvaný cold boot útok. Pokusím se vysvětlit, o co se vlastně jedná, jaké jsou možnosti obrany a popíši ukázkovou implementaci zahazování klíče pomocí nového cryptsetupu.

Obsah

• Šifrování disku
  • Jak funguje šifrování
  • Takže klíč je v paměti
• Možnosti obrany
• Ukázka řešení
  • Výchozí stav
  • Ledové království
  • Provázání se systémem

Motto:

Když člověk zahesluje soubor s 50 znaky, tak ten obsah nebude pro jiné oči ani pro policii. Já bych řekl, že tam bylo něco hodně mimo zákon.

(Michal Jiřík, diskuze na Novinkách)

Šifrování disku

Kdekdo dnes šifruje disk nebo alespoň jeho část. Nemusí po vás zrovna jít třípísmenkové organizace; dnešní malé netbooky lidé nosí pořád s sebou a jak asi víme, na veřejnosti se bohužel cennější věci občas ztrácejí. Pro nového „majitele“ notebooku by pak naše SSH a PGP klíče, maily, údaje o internetovém bankovnictví, dokumenty, fotografie… byly takovým příjemným bonusem k nově nabytému hardwaru. Linuxové distribuce se tomuto smutnému trendu přizpůsobily a většina jich dnes již nabízí zapnutí šifrování disku (nebo alespoň domovského adresáře) jedním kliknutím. Když už vám někdo ukradne hardware, nemusí mít přece ještě všechna vaše data.

Jak funguje šifrování

Většina osobních počítačů nemá žádný specializovaný šifrovací koprocesor (např. technologie Padlock na deskách Via Epia) a když už má, tak buď nejsou ovladače pro Linux, nebo to stejně nikdo nenastaví. Proto se musí veškeré operace provádět na CPU. Jádro tedy při šifrování vezme data, která chce zašifrovat, pomocí klíče (který získalo ze zadaného hesla^*) je zašifruje a zapíše na disk. Při dešifrovaní se postupuje obdobně – přečtou se zašifrovaná data z disku, klíčem se dešifrují a dešifrovaná se předají uživatelskému prostoru. Všichni jsou šťastní.

^*Z praktických důvodů se ve skutečnosti k šifrování nepoužívá rovnou heslo. Jednak je obvykle krátké (AES256 by, pokud dobře počítám, potřebovala jako klíč 43 znaků z a-zA-Z0-9) a druhak by se při změně hesla musela přešifrovat všechna data. Proto se heslem zašifruje náhodný (a dlouhý) klíč a šifruje se až tímto klíčem. Při změně hesla se pak jenom přešifruje klíč novým heslem. Klíč může být navíc úmyslně šifrován nějakým zoufale pomalým algoritmem, a tak se ztěžuje útok hrubou výpočetní silou [brute-force]. Více info: PBKDF2

Takže klíč je v paměti

K šifrování je tedy potřeba klíč (obvykle o délce několika stovek bitů). A ten se musí při běhu systému někde uchovávat. Při šifrování CPU se klíč uchovává – jako většina ostatních pracovních dat – v RAM. Chytrý šifrovací software si samozřejmě dává pozor, aby se klíč omylem nezapsal do swapu, odkud by si ho mohl případný útočník snadno přečíst (pokud by byl swap nešifrovaný). Ale i v samotné RAM je klíč v nebezpečí.

Některé desky při startu obsah paměti nemažou. Pokud se útočník fyzicky dostane k počítači a bude mít možnost zavést vlastní operační systém (nezaheslovaný BIOS, jako první zařízení je nastavena CD mechanika…), počítač restartuje, nastartuje vlastní systém a přečte si zbylá data z paměti. Zkuste si: strings /proc/kcore | less.

Ovšem i když útočník nemůže zavést vlastní systém, jsou data v ohrožení. Pořád totiž může počítač rozdělat, paměť vyndat, přehodit ji do vlastního počítače (který má pod kontrolou) a přečíst tam. RAM sice neudrží data bez napájení moc dlouho, řádově zlomky sekund až sekundy, ale lze tomu pomoci ochlazením. Bombičky s butanem se prodávají jako plyn do zapalovačů a butan má teplotu varu lehce pod 0 °C. Dokonce ani tekutý dusík není pro obyčejné smrtelníky zcela nedostupný.

Tomuto typu útoků se říká cold boot attack. Po zadání sousloví do svého oblíbeného vyhledávače jistě naleznete spousty studií, prací a experimentů.

Poznámky: Podobný útok lze velmi jednoduše a nenápadně realizovat i pomocí FireWire, což je ale nad rámec článku a navíc to autor nemá kde vyzkoušet. Hledejte firewire dump memory. Možná se časem objeví něco podobného i pro USB 3.0. DMA pro Plug'n'Pray zařízení se musí vždy důsledně ošetřit, ale návrháři čipů se na to občas vykašlou.
Notebooky jsou na tom, co se týče vybavených útočníků, hůře. Protože mají akumulátor, lze je zapnuté přenést do dobře vybavené laboratoře a provést důkladnou forenzní analýzu až tam.

Možnosti obrany

Po rozvážení dojdeme k tomu, že se lze bránit třemi způsoby:

1. Nemít paměť tak na ráně. Například zařízení typu system-on-chip mají paměť spolu s procesorem v jednom BGA pouzdře, případně ji mají zalitou takovým tím hnusným asfaltem. To ovšem vyžaduje takový systém vlastnit. V případě zalití obyčejného notebooku epoxidem se vám zase podstatně sníží možnost výměny rozbitých komponent a pravděpodobně přijdete o záruku.
2. Detekovat průnik. Některé dražší skříně mají case-open switch, který detekuje otevření. V případě zjištění pokusu o otevření můžete klíč přepsat náhodnými daty. U notebooků vyžaduje hardwarovou modifikaci (a útočníka s rozbrušovačkou to stejně nezastaví).
3. Smazat klíč, když od počítače odcházíte. Čistě softwarové řešení. Ale zase je otrava, když musíte po každém příchodu k počítači zadávat dlouhé heslo k disku. Tímto bodem se budu dále zabývat.

Ukázka řešení

cryptsetup umí od verze 1.1 operace luksSuspend a inverzní luksResume. Ta první přepíše klíč v paměti a zablokuje I/O operace s diskem (proces, který se pokusí číst nebo zapsat, bude pozastaven). luksResume si vyžádá heslo a obnoví předchozí stav. Ale nemůžeme uspávat rovnou systémový oddíl, protože bychom pak neměli jak přečíst binárku programu cryptsetup. Proto budeme chránit pouze vybrané části domovského adresáře. A proč pouze části? Aby byl systém použitelný i po zahození klíče. Pro to potřebujeme například soubory .bashrc, konfiguraci desktopového prostředí a další.

Výchozí stav

Máme před sebou systém, který má v adresáři /home/jenda/moje připojený šifrovaný LUKS oddíl s citlivými daty. Protože citlivé jsou i konfigurace některých programů, vytvořili jsme si do tohoto šifrovaného adresáře symbolické odkazy takovéhoto typu:

# cd /home/jenda
# ln -s moje/.ssh .
# ln -s moje/.gnupg .
# ln -s moje/tmp .

Ledové království

Můžeme vyzkoušet odpojení souborového systému.

# cryptsetup luksSuspend home

Pokud se teď nějaký proces pokusí přistoupit na takto odpojený souborový systém, bude zablokován. Chytřejší GUI aplikace, které běží ve více vláknech (gedit), to obvykle jenom dají nějak najevo; ty hloupější (Firefox) úplně zatuhnou. Můžeme se podívat, že opravdu zatuhly při pokusu o přístup k souboru na uspaném zařízení.

~> strace feh tmp/hpscan001.png
…
open("tmp/hpscan001.png", O_RDONLY)     = 4
fstat64(4, {st_mode=S_IFREG|0644, st_size=486486, ...}) = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb786e000
read(4, 

Až se pokocháte zamrznutou půlkou systému, obnovíme činnost zařízení:

# cryptsetup luksResume home
Enter passphrase for /dev/sda2: nbusr123

Takže si můžete vytvořit skript, řekněme lock.sh, který zahodí klíč a pak se bude ptát na heslo, nastavit si ho na nějakou klávesovou zkratku a spouštět ho vždy při odchodu od počítače.

#!/bin/bash
echo Usínám
cryptsetup luksSuspend home
echo Probouzím
cryptsetup luksResume home

To je ale nepohodlné, například u notebooku bychom chtěli odpojovat zařízení vždy při uspání.

Provázání se systémem

Vytvoříme si, řekněme, adresář /opt/paranoid, a vytvoříme v něm skripty lid.sh, unlock.sh a unlock-sudo.sh.

#!/bin/bash
# lid.sh - spustí se po zavření víka notebooku
cryptsetup luksSuspend home

#!/bin/bash
# unlock.sh - spustí se po pokusu o autentizaci přes PAM
cat - | sudo /opt/paranoid/unlock-sudo.sh
exit $?

#!/bin/bash
# unlock-sudo.sh - je spouštěn z unlock.sh, protože se mi nepodařilo přinutit pam_exec, aby spouštěl přes sudo rovnou…
# poznámka: pokud bude návratový kód 0, obrazovka se odemkne
HESLO=`cat -`

if [ $HESLO = nbusr123 ]; then
  exit 0
fi

echo "$HESLO" | cryptsetup luksResume home
exit $?
# možné problémy: $HESLO se uloží do paměti, odkud ho lze cold boot útokem přečíst.
#  Naštěsí se po odemknutí disku vykonají nahromaděné I/O operace, takže se paměť zaplní vyrovnávací pamětí.

Proč je v unlock-sudo.sh to ověřování i proti jinému heslu? Aby bylo možné odemknout obrazovku i v případě, kdy nechcete zadávat heslo k disku (před policejní hlídkou…), ale chcete se například jenom podívat do sbírky zákonů.

Nyní ještě musíme zařídit, aby se ty skripty opravdu spouštěly tak, jak chceme. To jde celkem snadno. Nejdříve to odpojování při zavření víka notebooku: hned na začátek souboru /etc/acpi/actions/lid.sh přidáme náš skript:

#!/bin/sh

/opt/paranoid/lid.sh

(zde pokračuje původní skript)

A jak spouštět skripty pro odemknutí? Debian s Xfce zamyká při uspání obrazovku pomocí programu xscreensaver a ten při odemykání obrazovky provede PAM akci specifikovanou v /etc/pam.d/xscreensaver. Přidáme tedy na začátek následující řádek

             auth sufficient pam_exec.so expose_authtok quiet seteuid /opt/paranoid/unlock.sh
#vysvětlení:      postačující             zadané heslo                    cesta ke skriptu
#                 k autentizaci         se předá na stdin

A ještě, aby nám fungovalo sudo pro unlock-sudo.sh bez hesla, spustíme visudo a přidáme:

User_Alias  PD = jenda
Cmnd_Alias  PDCM = /opt/paranoid/unlock-sudo.sh

PD     ALL= NOPASSWD : PDCM

Ještě je možné po probuzení spustit webkameru a nahrávat, jestli se nám někdo nesnaží dostat do notebooku nebo použít klíč uložený na jednom šifrovaném oddílu k inicializaci druhého oddílu, a tak se zbavit potřeby zadávat při startu počítače dvě hesla, kteréžto funkce popíšeme dle zájmu čtenářstva jindy nebo nikdy.

       

Komentáře

[Viktor]

Clanok je skvely, ale nic konkretnejsie o /proc/kcore neviem najst. Co myslel autor clanku tym, ze su data aj v RAM v nebezpeci? Maximum co som tam nasiel je napr. tak bootovanie kernelu z GRUBu, pricom pri kerneli je UUID a LUKS_UUID. Ani po "strings /proc/kcore | grep md5" som nenasiel heslo, ktorym je sifrovany grub ( v menu.lst je to na 14. riadku mojho configu )

Podarilo sa mi z neho dostat napriklad toto:

a 1388693525 17 Enter the new password.
a 1388693527 1d Enter the new password again.
a 1388693523 17 Enter the old password.

Ale nic konkretne nie. Moze mi to autor objasnit? Vdaka

Samozrejme, nasiel som aj veci typu navstivene stranky a pod, ale to mi nepride nejak obzvlast zaujimave, predsa len, myslim, ze autor clanku nenarazal na data v podobe "zoznam navstivenych stranok" pri clanku ohladom bootovania.

[Jendа]

Můžeš zkusit zaplnit paměť nějakými řetězci (třeba napsat v bashi `yes ahoj`) a pak rebootnout. Po rebootu bys teoreticky měl vidět ty řetězce (ale jak říkám, funguje to jen na některých deskách).

[Zdenek]

Nehleda se plaintext heslo, ale z nej vypocteny klic. Coz napr. u AES jde u soucasnych implementaci velmi snadno.

[janskyj]

A jakým způsobem naleznu v té paměti ve všem tom bordelu ten klíč?

[nou]

myslim ze skusat len 2^32 hesiel je sakra rozdiel oproti 2^256. 4GB RAM vs 256-bitovy AES.

[Bilbo]

V praxi jeste mene nez 2^32 - pokud utocim vuci znamenu reseni, tak se muzu chytat jinych veci, napr. se podivam v dumpu pameti na moduly v kernelu a pak si akorat prectu na spravnem miste pointer na ten klic. Pripadne vim jaka znama data jsou v pameti okolo (napr. ID pouziteho algoritmu, velikost sifrovaneho disku, atd ...), ty pak najdu a vim ze klic je hned o par bajtu vedle.

Jinak uz se objevily pokusy o obranu vuci coldboot. Napr. jedna z moznosti je pomoci jistych triku zpusobit, ze klic zustane v cache procesoru a nedostane se do hlavni pameti. Problem je v tom, ze to funguje jen na nekterych procesorech (neni to moc portable) a ma to celkem znacny dopad na vykon (u sifrovani krom klcie je nekdy treba utajit i ruzne docasne tabulky, coz treba u AES je cca 48 KB dat.)

Dostat data z cache procesoru uz pak neni tak jednoduche jako je dostat z pameti.

[Grunt]

Clanok je skvely, ale nic konkretnejsie o /proc/kcore neviem najst.

Ne /proc/kcore, to drží odkaz na právě běžící jádro, ale něco jako /dev/mem ve kterém je celá paměť.

[Jan Kundrát (jkt)]

`echo $HESLO` je dost spatny napad, napriklad protoze to bude videt ve vypisu procesu.

[Michal Kubeček]

Bash má příkaz echo jako builtin.

[CET]

if [ $HESLO = nbusr123 ]; then

Proč je v unlock-sudo.sh to ověřování i proti jinému heslu?

To nbusr123 je v tomhle clanku heslo ke klici pro sifrovany disk. To jako myslis vazne, ze bych nekam do shell scriptu napsal heslo k sifrovanymu disku????

Jediny heslo v plaintextu mam heslo pro automount pro sambu k Windows AD uctu, je to citelny pouze pro roota (automount) a heslo k linuxu mam jiny nez to do Windows.

[samox86]

no je to v tom clanku hrozne zle vysvetlene (a zle zvolene prikalady hesiel). heslo k sifrovaniu disku a heslo v textaku sa nemaju zhodovat!

- ak pri otvoreni ntbk zadas heslo nbusr123, naloguje ta ale nepripoji disk

- ak zadas ine, bude sa s nim snazit pripojit disk. pokial bude OK, disk pripoji a naloguje ta. pokial zle, tak ta nenaloguje

[iq65535]

Nechali by ste se radeji mucit v Guantanamu nebo byste heslo prozradili?

Stejne nas maj vsechny uz zmaknuty.. Trackovat par miliard lidi to je snad uz dneska trivialni uloha pro deti z CIA/FBI/KGB skolky.. na co nejake sifrovani Maji nas ocipovane a oskenovane a geneticky zmapovane jako laboratorni mysi .-)

[samox86]

pochopil som to spravne ze v subore /opt/paranoid/unlock-sudo.sh na nekryptovanom oddieli je ulozene heslo???

[samox86]

otazku beriem s5 :), pochopil som

[Martin Beránek]

ne, přečtěte si ten článek (nebo alespoň to co říká o obsahu souboru /opt/paranoid/unlock-sudo.sh)

[CET]

No, heslo tam neni ulozene v promenne, ale je tam testovani toho hesla. Pokud je to heslo jine nez heslo k disku, tak se udela exit 0, to ale znamena, ze to heslo k disku tam musi byt napsane.

Aha, zda se mi, ze to testovani hesla v if se ma delat obracene ... testovat, zda HESLO neni heslo-k-disku. Tedy bude $HESLO != nbusr123 nebo testovat login heslo $HESLO = login-heslo. Pak to pri login heslu vyskoci a nebude resumovat luks.

Mozna by bylo lepsi tam testovat nejake non-luks a non-system heslo, cili uplne nejakej jine, pak ale ztraci to zadavani hesla trosku smysl. To by bylo mozna lepsi spis otevrit po prihlaseni k xscreensaveru pak nahodit jeste jedno pro zadani hesla k disku a nebo manualne nastartovat (kvuli policii, aby nevidela, ze tam chce dalsi heslo).

[samox86]

je dost nezmysel mat 3 hesla: 1 do systemu, druhe na unlock screenu bez pripojenia particie a tretie na unlock screenu a pripojenie particie. bolo by mozne pouzit heslo do systemu na unlock screenu (co je dost logicke; potom len 2 hesla spolu).

#!/bin/bash
# unlock.sh - spustí se po pokusu o autentizaci přes PAM
cat - | sudo /opt/paranoid/unlock-sudo.sh `whoami`
exit $?


#!/bin/bash
# unlock-sudo.sh - je spouštěn z unlock.sh, protože se mi nepodařilo přinutit pam_exec, aby spouštěl přes sudo rovnou…
# poznámka: pokud bude návratový kód 0, obrazovka se odemkne

HESLO=`cat -`
me=$1

if [[ `grep $me /etc/shadow | awk -F "$" -v heslo="$HESLO" '{print "echo " heslo " | openssl passwd -1 -salt " $3 " -stdin"}' | sh` = ` grep $me /etc/shadow | awk -F ":" '{print $2}'` ]]; then
exit 0;
fi

echo "$HESLO" | cryptsetup luksResume home
exit $?

[Jendа]

Kdepak! Nejsem zas tak blbej, abych dal na nechráněný disk heslo ke chráněnému disku. To by pak bylo poněkud k ničemu .

To heslo, které se tam testuje, je heslo, kterým můžu odemknout obrazovku bez resume chráněného oddílu. Pokud se zadané heslo s tímto shoduje, vrátí se rovnou návratová hodnota 0, což znamená, že se obrazovka odemkne. Až pokud se neshoduje, zkusí se jím probudit (resume) disk.

Mozna by bylo lepsi tam testovat nejake non-luks a non-system heslo

Osobně testuji systémové, ale jinak je celkem jedno, jestli systémové nebo nějaké jiné - pokud někdo dokáže ten soubor přečíst, znamená to, že už stejně má přístup do systému a systémové heslo je mu pak už k ničemu.

Pekné, ale aj tak si myslím, že je väčšia pravdepodobnosť na odchytenie hesla pri zadávaní (hw keylogger, alebo niekde schovaná kamerka), ak má niekto naozaj záujem sa do počítača dostať. A keď ten záujem nemá a ide "iba" o krádež, tak nebude prevádzať coldboot atack.

:(

[Sten]

Je daleko těžší notebook ukrást, upravit, vrátit a potom znovu ukrást než jej jednoduše ukrást jednou a pak zničit. Navíc naprostou většinu notebooků ukradených kvůli datům nekradou tajné služby (ty ta data většinou nezajímají, v případě nouze si je seženou jinak nebo jednoduše aplikují rubberhose cryptanalysis) ani policie (ta takové postupy odposlechu nesmí aplikovat), ale konkurence a ta si netroufne upravený notebook vracet, je to možný důkaz spojující je s takovou krádeží. Naopak cold boot útok by mohl začít být standardem pro takové krádeže, protože šifrování disků se (právě kvůli existenci takových krádeží) také stává standardem.

[Bilbo]

Není třeba vysloveně krást. Stačí se dostat k notebooku na dost dlouho, abych nabootoval ze speciálního USB. Na to stačí minuta.

Viz. http://theinvisiblethings.blogspot.com/2009/10/evil-maid-goes-after-truecrypt.html

[x]

Mno na standardne nastavenym firemnim notesu nenabootujes zniceho jinyho nez z disku. A nez ten vymenis, tak se ti data z pameti vypari. Ostatne i pri nejlepsich moznych podminkach pro tenhle typ utoku mas jen relativne malou pravdepodobnost (ale nenulovou samo), ze ziskas co hledas.

[Bilbo]

Tak evil maid attack predpoklada, ze se povede nabootovat z flashky (tahle moznost muze byt chranena heslem v BIOSu, i kdyz k nekterym BIOSum existuji univerzalni hesla, nebo jine moznosti jak to prekonat) - I kdyz to neni coldboot utok, ale to, ze flashka zameni truecrypt na disku jinym, co je backdoorovany (ulozi nekam heslo v plaintextu). Druhe strceni flashky o neco pozdeji pak muze plaintextove heslo co tam bylo ulozeno precit a dat ho na flashku. V tu chvili ma clovek i klic a muze si odnest notebook, data uz dokaze desifrovat. Alternativa (pokud clovek u pocitace pri druhem cteni neni alespon nekolik hodin) by mohla byt v tom obsah disku zkopirovat na pripojeny USB disk a pak vratit standardni truecrypt loader - clovek pak ani nepozna, ze mu nekdo ukradl data :)

Pokud se nepovede nabootovat z flashky, tak instalace backdooru znamena minimalne vyndani disku z notebooku, pripichnuti do jineho stroje, instalace backdooru a pak jeho opetovne namontovani. To neni nic tezkeho, ale narozdil od strceni flashky a nabootovani z ni to trva dele nez cca minutu.

[pavlix]

Mno na standardne nastavenym firemnim notesu nenabootujes zniceho jinyho nez z disku.

Což z jedné minuty dělá dvě, že :).

A nez ten vymenis, tak se ti data z pameti vypari.

Instalace backdooru pokud vím, data z paměti vůbec nepotřebuje.

Ostatne i pri nejlepsich moznych podminkach pro tenhle typ utoku mas jen relativne malou pravdepodobnost (ale nenulovou samo), ze ziskas co hledas.

Záleží o kterém typu se bavíme, pokud o nasazení backdooru, tak tím se dá v získat přístup k libovolným datům na počítači, která dotyčný odemkne.

[Ash]

A nez ten vymenis, tak se ti data z pameti vypari.

Vypařovat se bude hlavně dusík kterým budeš paměť mrazit :D

[Trained.Monkey]

A ta supertajna data pripojujete pri kazdem bootu? To mozna bude zakladni chyba.

[xkucf03]

SSH, GPG, x509 klíče jsou supertajná data nebo ne? Jejich krádež může způsobit vážné problémy, ale člověk je potřebuje celkem často, takže ten disk většinou připojený být musí.

[Jack]

Jejich krádež způsobí jen určité komplikace při nahrazování. Pochybuji, že by je byl útočník schopen bez hesla v horizontu několika let použít.

[Jendа]

Zadávat heslo při každém použití? To se mi nechce.

[Sten]

Zadávat heslo při každém použití je navíc nebezpečnější, nikdy nevíte, jestli vás v té kavárně nesleduje konkurence. Je lepší zadat heslo jednou a po celou dobu práce to heslo znovu nezadávat.

[LEA]

Ak ti niekto ukradne počítač, tak to bude zlodej, ktorému ide o počítač samotný a nie o dáta. Ak by si náhodou v počítači mal veľmi dôležité dáta, pre ktoré by sa oplatilo počítač ukradnúť a zorganizovať na ňom cold-boot attack seansu, potom sa treba obrátiť na IT oddelenie firmy, v ktorej pracuješ.

Mne z toho vychádza len to, že šíriš návod, ktorý je užitočný pedofilom a teroristom, ktorý sú prakticky jedinými skupinami, kde má cold boot attack zmysel.

Veď kto nerobí nič zlé, nemusí sa podobnými blbosťami zaoberať, pretože sa nemá čoho báť.

[JoHnY2]

Mne z toho vychádza len to, že šíriš návod, ktorý je užitočný pedofilom a teroristom, ktorý sú prakticky jedinými skupinami, kde má cold boot attack zmysel.

Veď kto nerobí nič zlé, nemusí sa podobnými blbosťami zaoberať, pretože sa nemá čoho báť.

Nemuzu si pomoct, ale z obou vet mi vstavaj vlasy hruzou na hlave. Ta prvni je blaznive paranoidni a ta druha zase blaznive idealisticka ... Kam na tyhle nazory ty lidi chodej.

[vercajch]

co ked sa tvoj nazor nezoduje s nazorom vacsiny? napr. nesuhlasis so sefom, rezimom, alebo tvoje data su citlive a nechces aby ich niekto videl? napriklad nejaky vyskum objav atd.? Neni zlo ako zlo.. ci? Moje sukromie znamena pre mna slobodu..

[Ondy]

Za predpokladu ze IT oddeleni neni banda neschopnych idiotu, tak ano. Ale nektere organizace primo pozaduji sifrovani dat na disku. A i kdyby ne, maly netbook je docela laciny takze kdyz mi ho ukradnou tak budu par dni nastvany, ale kdyz mi z nej jeste vyberou veci k pristupu do banky tak budu nastvany podstatne dele. A navic co ma ktery zlodej co delat s myma osobnima datama?

[x]

Z druhy pulky tvyho postu je videt, ze si jeste stale naivni decko. Jelikoz cajti muzou prijit kdykoli ke komukoli (duvod se dycky nakej najde) a HW mu sebrat na neomezene dlouho dobu, tak se mi rozhodne spi lip s vedomim, ze pravdepodobnost ze se dostanou k datum, je miziva.

Ty vazne vis o kazdem souboru co kde po disku mas ? Ja teda ne. A presto ze me napr DP a podobny chujoviny nezajimaj (zenskou musi byt za co chytit ;) ), tak nevylucuju, ze by nekdo moh tvrdit, ze "ty 20tce na tom videu je ve skutecnosti 12".

Nemluve o tom, ze tvoje pripadna pritulka jiste bude nadsena kdyz se jeji foto, ktery si delal ty, objevi nekde na netu ...

[imploder]

Výborný článek. Správný paranoik se s nabízeným zdánlivě bezpečným řešením ale nespokojí a ponoří se do paranoidních úvah...

Kudy všudy jde heslo

Heslo, co se zadává k ověření, projde v nějaké podobě nejmíň tímto vším:

• ovladač klávesnice
• x-window systém
• GUI toolkit (terminál, případně okýnko, kam zadávám heslo)
• roura (když předávám heslo ve skriptu, jako v článku)

Nejsem si jistý, jestli si všichni tihle promažou paměť, aby se z ní nedalo vytáhnout heslo, spíš bych řekl, že ne. Nic o tom nevím. Dokud nebudu mít tyhle komponenty pod kontrolou a záruku, že nikdo z nich v paměti heslo nenechal, nemůžu si být jistý.

Až si to všechno zabezpečím

Pokud jsem dřív měl hesla aj. v nešifrovaných souborech, tak po zabezpečení mi na disku žádné takové soubory nesmí zůstat. Po zabezpečení bych se měl ujistit, že se mi v žádném už nešifrované heslo neválí a vyčistit (několikrát přepsat náhodnými daty) všechen prostor na disku, který nepatří do žádného existujícího souboru. Na tohle by paranoik, co si zabezpečuje části už delší dobu existujícího filesystému, neměl zapomenout. Je nějaký šikovný program, co vymaže všechno, co je na disku mimo soubory? (technicky tohle není problém, mohlo být zmíněné v článku s odkazem na konkrétní řešení, pokud teda takový "čistič" existuje)

Můžu mít v komplu parazita

Někdo by mi mohl dát do počítače keylogger (nepozorovaně sebrat, nainstalovat - i třeba hardwarový - a vrátit; využít děravého softwaru co používám; může se mi nakazit u někoho - i nic netušícího - fleška bez R/W zámku; můžu si pustit nedůvěryhodný program - prostě nákaza virem) a pak je vymalováno.

Tohle poslední je teoreticky vždycky moje chyba že jsem lama (mám pouštět jen podepsané důvěryhodné programy, používat jediný správný (tm) bezpečný browser, nikdy si nenechat počítač ukrást (ehm.. "vypůjčit", když je to i s vrácením ), vrátit a pak ho dál používat, atd..). Prakticky tenhle druh útoku reálný a rozšířený, viz případy vykradených hesel z Total Commanderu, řešení "master heslo" to v principu neřeší, stačí dát do viru keylogger. Na Linux může tohle kdykoliv přijít taky (šířilo se to přes děravý Firefox), výhoda Linuxu tady je snad adress space randomization, které ve Windowsu chybí.

Na LinuxAlt se na mongoDB a na coldboot půjdu podívat, jsou to zajímavé věci.

[danc]

Je nějaký šikovný program, co vymaže všechno, co je na disku mimo soubory?

zkusil bych

dd if=/dev/urandom of=/tmp/bigfile

a az se zaplni disk, tak smazat /tmp/bigfile

[xkucf03]

Na Linux může tohle kdykoliv přijít taky (šířilo se to přes děravý Firefox), výhoda Linuxu tady je snad adress space randomization

Výhoda Linuxu je taky třeba AppArmor – pomocí něj můžeš „zabednit“ prohlížeč (jakýkoli, ne jen Firefox) tak, aby mohl dělat jen to, co nezbytně ke svojí činnosti potřebuje – takže se např. nepodívá do ~/.ssh, ~/.gnupg nebude fungovat jako server, nebude spouštět další procesy atd.

[imploder]

Sandboxy pro Windows existují taky a ne jen jeden - např. Sandboxie. Na Linuxu to jde taky (AppArmor), ale za výhodu Linuxu bych to nepovažoval.

[smazáno]

Standardni prednastavene reseni od dodavatele OS, ktere funguje i kdyz o nem vubec netusis ze tam je vs. nejaky uzavreny 3rd party software ... hmm ...

[Jendа]

Nejsem si jistý, jestli si všichni tihle promažou paměť, aby se z ní nedalo vytáhnout heslo, spíš bych řekl, že ne. Nic o tom nevím. Dokud nebudu mít tyhle komponenty pod kontrolou a záruku, že nikdo z nich v paměti heslo nenechal, nemůžu si být jistý.

Chápu, ale líp to asi udělat nejde. Správný paranoik by možná zadával heslo rovnou na virtuální konzoli a ne přes X, čímž by to omezil v podstatě jen na ten ovladač klávesnice. Nicméně je to zajímavý námět na experiment s virtuálním strojem.

Pokud jsem dřív měl hesla aj. v nešifrovaných souborech, tak po zabezpečení mi na disku žádné takové soubory nesmí zůstat.

Já to instaloval na panenský disk (respektive byla tam původně OEM Windows), nic svého jsem tam ještě neměl.

Je nějaký šikovný program, co vymaže všechno, co je na disku mimo soubory?

Ano, stačí zaplnit velkým souborem. Dělá se to i při zálohování obrazu disku, kdy se takhle vytvoří dlouhé sekvence nul, které se následně zkomprimují gzipem.

[Bilbo]

Chápu, ale líp to asi udělat nejde. Správný paranoik by možná zadával heslo rovnou na virtuální konzoli a ne přes X, čímž by to omezil v podstatě jen na ten ovladač klávesnice. Nicméně je to zajímavý námět na experiment s virtuálním strojem.

Tuším, že takhle se dá vytahat heslo k biosu - BIOS jede v "reálném módu" (16bit), kde na adrese 0040:001A až 0040:003D (segment : offset) je kruhový buffer na 16 kláves.

Ve chvíli, kdy nastartuje systém, tak ten si obvykle začne řešit klávesnici jinak (přes různé ovladače a něco jako kruhový buffer na stisknuté klávesy má někde jinde). Bohužel často ten systém zapomene ten původní BIOSový buffer promazat a pokud tu paměť nepoužije na nic jiného (vzhledem k tomu, že na takhle nízkých adresách je tabulka přerušení a další důležité věci, tak to tam spíš asi zůstane), tak v tom bufferu to naklofané heslo zůstane.

Je nějaký šikovný program, co vymaže všechno, co je na disku mimo soubory

dd if=/dev/zero of=/cesta/libovolne_jmeno_souboru && sync && rm /cesta/libovolne_jmeno_souboru

[Michal Fecko]

[iq65535]

[Jiří J.]

Obrana? Co takhle ten klíč prostě rozsekat na několik kousků, přidat mezi ně slušnej padding (třeba random data) a nechat OS, ať to nastránkuje na různá místa paměti? Stránka má myslím 4K (nebo už 8K?) a těch pár KB zbytečně zaplněné paměti navíc by se mohlo vyplatit.

[xkucf03]

Security through obscurity

[Jiří J.]

Já vím, jak ale jinak "schovat" klíč? To "řešení" s cache processoru je vlastně taky "obscurity". Šlo mi o to, že pokud by takto nějaký userspace program rozsekal klíč do spousty menších částí, sníží schopnost úspěšně rozluštit (pravděpodobně) poškozenou tabulku stránek a tudíž poskládat finální klíč.

[Jendа]

Já vím, jak ale jinak "schovat" klíč?

Takhle určitě ne. Ten program, který ho takhle rozstrká a pak zase zpětně sestaví, musí být v jádře. A jádro je natažené v paměti a nešifrované na disku (v /boot). Odradí to asi jenom script kiddies.

To "řešení" s cache processoru je vlastně taky "obscurity".

Ne, to se zakládá na tom, že cache procesoru zvenku nevyčteš, hardwarovým zásahem asi taky těžko a po resetu se okamžitě zaplní jinými daty. Je to podobné, jako kdybys měl system-on-chip nebo TPM (jak to bylo) mezi dvěma komorami s náhodným tlakem, takže když jednu provrtáš, čip se rozpadne na kousky.

[Jiří J.]

Má pointa byla čistě z pohledu userspace, to rozsekání by provedl program a jádro by to náhodně "fragmentovalo" na stránky, které by mohly být náhodně spojené/rozházené. Takový Firefox má těžko naalokováno 500MB vedle sebe ve fyzické (ne virtuální) paměti.

Na druhou stranu - je pravda, že kernel vývojáři v současnosti pracují na defragmentaci paměti, takže výsledný efekt by nemusel stát za to.

[Bilbo]

Mít klíč v extra šifrovacím chipu, který je postaven tak, že dobrovolně klíč prostě nevydá (možná by něco takového šlo docpat do systému jako PCI/PCI-e karta) je asi nejodolnější řešení, bohužel asi i nejdražší.

Jak mají některé procesory šifrovací instrukce (AES-NI, Via padlock ...), tak se někde mluvilo o možnosti, že by s těmito instrukcemi klíč držel přímo procesor (a rovnou by šifroval a dešifroval) a ta paměť by byla pro uživatele write-only. To by coldboot dost ztížilo (klíč není v ramce, ale v procesoru, který ho jen tak nevydá), ale nejsem si jist, jestli je něco takového implementováno, nebo jestli je to jen nějaký zatím nezrealizovaný návrh (AES potřebuje krom klíče dalších 240 bajtů na key schedule) a pak podle režimu šifrování (CBC, LRW, XTS ...) další pamět na citlivá data (IV, ...).

Vzhledem k tomu, že režimy šifrování se aplikaci od aplikace liší, tak by možná nebylo jednoduché ty instrukce navrhnout tak, aby všechna citlivá data mohla být na chipu a zároveň to bylo dost flexibilní.

[Sten]

Tohle všechno umí TPM. Anebo HW šifrovací karty (ty dražší, ty levnější většinou klíč při fyzickém útoku vydají).

[petr_p]

Ani TPM, ani jiné šifrovací karty neumí to, co potřebujeme – nemít otevřená data jinde než v procesoru. My nepotřebujeme černou krabičku, z které padá otevřený text. My potřebujeme procesor, z kterého lezou zašifrovaná data určená pro fyzickou paměť.

Dost to komplikuje architektura x86, která má do určitého bloku mapované I/O a která má DMA buffery v téže fyzické paměti, kterou chceme mít zašifrovanou.

[Bilbo]

Pokud je klíč v šifrovací kartě, která se stará o veškeré šifrování dat z/na disk, tak obsah celého disku se při čtení hlavní paměti prostě nezjistí. Bohužel, jelikož každý rozumný operační systém má nějakou diskovou cache, tak s trochou štěstí se v paměti najdou v plaintextu některé soubory co jsou na disku zašifrované a co je k nim klíč jen v té kartě, která ho nevydá.

A nasadit šifrování mezi hlavní pamět a procesor je nereálně, s dual channel DDR3 je rychlost čtení/zápisu do paměti asi 20-25 GB/sec, což je trochu mimo možnosti běžně dostupného hardware.

[Michal Fecko]

[1],[2]

[Milan Brož]

Když už je to tu tak hezky rozebráno, pár poznámek:

- ten prográmek na vyhledání klíče v paměti z citp.princeton.edu využívá specifické optimalizace pro AES. Takže nejen, že nebude fungovat na jiné algoritmy, ale dokonce nenajde i klíč, který je tam uložený přímo nebo v hexa zápisu (obojí se v paměti objevuje během konfigurace dm-cryptu).

- luksSuspend maže z paměti klíče používané v cryptoAPI (to je přesně to, co hledá ten prográmek) a klíč v interní mapovací tabulce dm-cryptu (jíž je klíč součástí, "dmsetup table --showkeys"). Pozor na to, že v paměti jsou stále stránky s odšifrovanými (plaintext) daty. Něco jde vypláchnout, ale některá data tam prostě zůstanou.

Jakýkoliv pokus o rozházení klíče po paměti tak, aby se "špatně hledal" nepomůže. Většinou je výsledkem přesný opak (přečtěte si tu analýzu výše a poznámku o loop-aes - pokus o přepisování kliče z jedné části paměti do druhé, ve snaze zabránít jistým efektům DRAM, vedl k tomu, že Coldboot našel klíč na více místech a mohl se tak bezpečně rekonstruovat i když již byl částečně poškozený.)

Pokud někdo spoléhá na luksSuspend, je třeba si také pohlídat, že se používá libdevmmaper, který důsledně maže po použití všechny buffery, které manipulují s mapovací tabulkou (1.02.46 a dál - je to to Library version v "lvm version").

Pokud někdo najde v systému nějaký buffer, který se nemaže, tak by to měl reportovat jako bug.(Tuším i ovladače terminálu v kernelu používaly takový buffer, takže všechny zadané sekvence tam zůstávaly, dokud se nepřepsaly dalším vstupem z klávesnice. Což je také materiál pro ColdBoot...) Tohle jde jednoduše testovat ve virtuálním stroji, který suspendnete a hledáte známou sekvenci - heslo zadané z klávesnice - v obrazu RAM na disku.

- Používání konstrukce echo "heslo" | cryptsetup je nešvar, který je všude. Přitom stačí jednoduchý plugin/wrapper používající libcryptsetup (nejlépe, který se celý zamyká v paměti) - tak jsou buffery relativně pod kontrolou.

- používání TPM nic neřeší, pokud vlastní šifrování provádí hlavní procesor - pak se prostě ten klíč musí dostat někam do paměti, kde ho kernel cryptoAPI použije. Přečtěte si Truecrypt FAQ - naprosto stejný postoj platí pro cryptsetup/dm-crypt (nehledě k tomu, že na Linuxu je backend k Truecryptu dm-crypt).

A co se týče utoků na hw jako keyloggery - viz konec zmiňované přednášky na LinuxAtu. (Slajdy Petrovy přednášky jsou tady. Já sem to zmiňoval už minulý rok vše je tady.

[Bilbo]

nehledě k tomu, že na Linuxu je backend k Truecryptu dm-crypt

Truecrypt má na linuxu jako backend dm-crypt? Měl jsem za to, že novější verze (tuším od 5.0 výše) už nemají modul do kernelu, ale fugují přes FUSE ...

Tohle jde jednoduše testovat ve virtuálním stroji, který suspendnete a hledáte známou sekvenci - heslo zadané z klávesnice - v obrazu RAM na disku

Tohle je trochu ztížené tím, že to heslo se tam nemusí objevit "v plaintextu" - pokud bude za každou klávesou pár bajtů pro flagy (v DOSu byl v 16znakovém buferu 2. bajt na extended flagy), případně bude navíc každá klávesa dvakrát (zmáčknuto + odmáčknuto) tak mezi jednotlivými znaky hela bude "nějaký bordel", v horším případě se tam ty klávesy objeví nějak "zakódované" (Q=1, W=2, E=3, R=4, T=5 ....) kdy to heslo takhle nebude vidět, v "nejhorším" případě tam může být např. nějaký spoják s ukazateli, takže to heslo tam nemusí být ani popořadě.

luksSuspend maže z paměti klíče používané v cryptoAPI (to je přesně to, co hledá ten prográmek) a klíč v interní mapovací tabulce dm-cryptu (jíž je klíč součástí, "dmsetup table --showkeys"). Pozor na to, že v paměti jsou stále stránky s odšifrovanými (plaintext) daty. Něco jde vypláchnout, ale některá data tam prostě zůstanou.

Teoreticky by to šlo řešit, že při suspend se vygeneruje náhodný klíč, tím se zašifruje skoro celá RAM včetně všech klíčů (tedy kromě suspend a téhle šifrovací/dešifrovací rutiny), pak se vygeneruje z hesla kterým má být prováděno resume další klíč, kterým se zašifruje ten náhodný (jehož originál se pak smaže, ale může se uložit jeho hash)

Při dešifrování se zadá heslo, dešifruje se klíč od paměti, pokud hash sedí, dešifruje se pamět, pokud ne, bylo zadáno blbé heslo (pokud by se pokračovalo v dešifrování paměti, byl by z toho akorát odpad)

Ve chvíli, kdy je to takhle suspendováno, tak by to mělo být rezistantní i vůči coldboot (klíče v paměti nejsou ...)

[Milan Brož]

Truecrypt má na linuxu jako backend dm-crypt? Měl jsem za to, že novější verze (tuším od 5.0 výše) už nemají modul do kernelu, ale fugují přes FUSE ...

Ano, IIRC verze 4 mela vlastni dm modul, 5 mela ciste FUSE, 6 a vyse pouziva dm-crypt (krome nejakych kompatibilnich konterjneru, takze FUSE tam je stale take).

Tohle je trochu ztížené tím, že to heslo se tam nemusí objevit "v plaintextu"

jiste. ale v nejake forme to tam bude. a pokud to nekomu stoji za to, urcite si da praci to poskladat. a s tom virtualni masinou si muzu udelat snapshot pred zadanim a po zadani a podivat se, co se kde zmenilo. jakmile vim, jake patterny to generuje, jde to automatizovat.

Teoreticky by to šlo řešit, že při suspend se vygeneruje náhodný klíč, tím se zašifruje skoro celá RAM včetně všech klíčů

dm-crypt je driver na blokove zarizeni, to by byl uplne jiny projekt, ktery by musel byt navazany na memory management. a nemyslim, ze by to k necemu bylo - proc to pak nehibernovat do sifrovaneho swapu radsi?

[Bilbo]

proc to pak nehibernovat do sifrovaneho swapu radsi?

Odswapovat 2 - 16 GB paměti (dle stroje) trvá ... dlouho, řádově minuty (dle RAM a rychlosti disku). To samé pak zpětné načtení z disku. Přešifrovat celou paměť sice také není úplně hned (dle Truecrypt benchmarku core 2 quad dosahuje s AES 344 MB/sec, rozumně rychlé harddisky mají řádově tak 80 - 100 MB/sec), ale je to o dost rychlejší (v obou případech šifruji tak jako tak celou paměť, jen to pak nemusím pak ukládat na disk :)

[Adam Pribyl]

Nejlepsi je zadna tajna data nemit.

[Bilbo]

To bohužel reálně moc nejde. Stačí libovolné heslo (k emailu, k internetbankingu) a už má člověk nějaká tajná data (vetšině lidí by asi dost vadilo, kdyby někdo vzal jejich heslo k emailu nebo na internetbanking a začal je šířit do světa)

A spousta lidí má tajných dat více (SSH klíče, firemní tajemství, atd ...) a možnost jejich zneužití ve špatných rukou je značná...

[HB]

obrana:

1. Pracovat jenom z živé distribuce.

2. Fleška zašifrovaná celkově tj. nenamontovaná, soubor pro TC je např. /dev/sda

3. Panic Keyboard (USB klávesnice bez kláves generující pouze jednu sekvenci na stisk ovladače pod stolem připojená KABELEM pro případy "vlítnutí" cold boot komanda. (WIFI, BT lze zarušit). Možná je i reakce Panic keyboard na uvolnění ovladače (Výzva "odejděte od PC").

4. Reakce živé distribuce na akci "Panic Keyboard": okamžitě přepsat celou fyzickou RAM nulami.

5. Používat jen vlastní PC nenápadně zapečetěné a vždy kontrolovat.

6. Pro přenos dat nepoužívat internet, wifi, GSM a BT.

PS: Panic Keyboard je můj okamžitý nápad inspirovaný diskuzi.

PS2: Má někdo nápad jak tuto obranu prolomit kromě fyzického vytlučení hesla z uživatele?

[Jiří J.]

PS2: Má někdo nápad jak tuto obranu prolomit kromě fyzického vytlučení hesla z uživatele?

Nenápadná neutralizace panic keyboard

[HB]

Lze nosit sebou, i tu živou distribuci. :-P

[Shadow]

Počkat, až usneš při zapnutém compu. A pokud neusneš, zařídit, abys usnul - plyn, "otrávení" zásoby vody či jídlo v lednici, atd. Použít sociální inženýrství. Nainstalovat monitorovací zařízení - kameru, odposlech, keylogger (a dívat se, co děláš). Vyřadit z činnosti panic keyboard a kvapně obsadit místnost. Atd.

Nejdůležitější na bezpečnostních opatřeních je jejich důsledné dodržování, i když třeba člověk spěchá a nemá čas. Tvoje schéma je sice hezké, ale chci vidět, jak používáš počítač výhradně bez Netu nebo jak PC vždy důsledně kontroluješ, jestli s ním někdo nemanipuloval.

A i když vše důsledně dodržuješ, pokud se někdo bude opravdu chtít dostat k tvým datům, pak se mu to s dostatkem času, trpělivosti a úsilí vždycky podaří. I bez rubberhose kryptoanalýzy.

[HB]

1. Přenášet data na šifrované klíčence (pešonet).

2. Kontrola fyzycké intergity PC vždy (jak tam tedy keyloger nepozorovaně dostat ?).

3. Panic Keyboard před každým přihlášením otestovat.

4. K PC sedat střízlivý, několik hodin před přihlášením do PC nic nepožít.

5. Dočasně sklopný kryt nad klávesnici při zadávání hesla.

6. Strop a zdi všude kolem čistě bílé a volné, nemít za zády dveře.

7. Být zticha a tiše pracovat.

8. PC pouze jako datový trezor s možností editace.

9. Nikde si nic nepsat.(ne jako teď já )

10.Na to vše musím mít větší trpělivost než všichni ostatní a kapsli kyanidu pod jazykem k rozkousnutí.

PS: Abych byl až tak paranoidní musim být buď pacient nebo....

PS2:Dané téma mě baví.

[Jendа]

Hele, větší magor než já.

[imploder]

Když jsem si to minulé četl, tak mě napadlo, že nejjistější by bylo mít na "Panic Keyboard" napojenou dostatečně silnou bombu, co spolehlivě zlikviduje počítač i uživatele, takže z něj už nikdo nic nevymlátí.

[Shadow]

Baví vás jen vymýšlení nebo něco takového opravdu praktikujete?

[HB]

Baví, naštěstí nemám potřebu něco takového praktikovat.

[HB]

Doplním další hyperparanoidní vychytávky.

1. Ostrej dobře vycvičenéj pes (nic nevykecá).

2. Kanárek v kleci s čidlem na dně klece (taky nic nevykecá).

3. Hluková čidla a čidla v PC.

-- aktivace v bodech 2. a 3. zpusobí přepsání RAM nulami.

4. Žádná okna.

Přeji happy paranoia

[Shadow]

Ještě mi tam chybí bunkr, ostnatý drát, kulometné věže, hlídky, útoční psi, minové pole, atd. A nebo ještě lépe - důvěrná data vůbec nesvěřovat počítačům a spoléhat se pouze na svou vlastní paměť.

Vymyslet nereálné paranoidní schéma zabezpečení není problém. Problém je přijít se schématem, které je reálné, proveditelné, udrží bezpečnost dostatečně vysoko, ale současně vyžaduje minimum vynaložených prostředků a času.

[Bilbo]

Místo panic keyboard by stačila vhodná sada senzorů - senzor vyražení oken a dveří, senzory na manipulaci s PC skříní ... fungují i tehdy, pokud člověk např. u PC usne.

Ale to záleži kdo po tobě jde a jak moc důležitý jsi cíl. Je rozdíl pokud člověka podezírají např. z toho, že nahrál někam na rapidshare 5 písniček (to u něj asi zaklepe policie a bude chtít dovnitř, ale nebudou hned pro jistotu vyrážet dveře), nebo pokud je podezřelý z miliardových podvodů a ví se o něm, že by mohl být ozbrojený. Nebo jestli po člověku nejde třeba mafie, která si s dodržováním zákonů hlavu lámat nebude.

V praxi by IMHO stačilo (pokud po těch datech nejde někdo opravdu moc důkladně) mít pár nenápadných senzorů v bedně, co při pokusu o otevření nebo odnesení bedny spustí přepisování paměti nulama. Ve chvíli kdy někdo po otevření bedny nebo jejím zvednutí objeví senzor, tak už je pozdě :)

[Grunt]

To by si měl přečíst Tom co poslal disk na reklamaci do Mironetu. Nebo aspoň něco o šifrování.

Jinak krom ColdBoot útoku mě napadl další způsob. Např. v takovém Ubuntu, pokud nainstaluješ kexec, tak ti automaticky bez jakéhokoliv ptaní přidá k parametrům jádra crashkernel=128M (vzhledem k tomu, že GRUB2 už nezobrazuje ani nabídku jsem si toho všiml až když mi ta paměť začala scházet). Pak si stačí jen vyčíhat okamžik, kdy bude klíč v paměti, pomocí klávesového komba Alt+SysRQ+C ručně navodit umělý Crash systému (Kernel Panic), počkat než jádro sletí a přebootuje pomocí kexecu nové (crash) jádro, které krom roota také nabídne v souboru /proc/vmcore, předchozí jádro jak vypadalo v okamžiku zmáčknutí zkratky. Stačí už jen někam zkopírovat, stáhnou k příslušnému jádru debugovací symboly (vzhledem k tomu, že většina běžících jader je distribučních to ani není moc namáhavé), podívat se jakým systémem byl zašifrovaný příslušný oddíl nebo adresář, mkrknout do zdrojáků v které proměnné nebo v kterém bufferu je držen klíč, spustit gdb a k němu příslučný dump, print jmeno_promenne a práce je hotová. Některé pokročilejší distra (jako Fedora) to jádro dokonnce pěkně pročistí a neservírují ho do /var/crash (schálně, kdo šifruje /var, tak nechť hodí kamenem) a nebo mají takové pokročilé featury jako přímý debuging spadeného jádra přímo z crashkernelu, takže člověk se nemusí ani namáhat s rebootem. Asi si něco zašifruju abych se mohl hrát.

A věřím, že každé distro obsahuje takových kachen několik. Vždyť např. v mém případě není neobvyklé abych přišel k počítači a u Fedory mi v rožku viselo upozornění na update balíků kvůli bezpečnostním chybám některých důležitých služeb (které většinou běží pod rootem) a u každé bezpečností chyby link na bugreport (holt chlapci z RedHatu jsou svědomití) kdy u některých nemusí být ani nemožné natrefit na demonstrační expolit. Se pak člověk nemusí babrat ani s rebootem a pokud se mu podaří dostat se do některého rootovského procesu, může si libovolně šmejdit po paměti a najít si ten klíč (nadruhou stranu, když je někdo rootem, tak se asi ani nemusí babrat s tím klíčem).

Nemít paměť tak na ráně. Například zařízení typu system-on-chip mají paměť spolu s procesorem v jednom BGA pouzdře, případně ji mají zalitou takovým tím hnusným asfaltem.

No, nevim. Ještě jsem teda na SoC s integrovanou pamětí nenarazil. Až takový najdeš, dej mi prosím vědět. Ihned odkoupím. Většina boardů ji má vyvednou do samotného čipu a se SoC pomocí plošňáku propojenou. Na druhou stranu je pravda, že většina jich je natvrdo na ten plošňák připájených a má to tak malé piny, že i ten epoxid je proti tomu hadr (ale jde to – buď s mikropájkou a pevnou rukou a nebo pomocí nějakých triků ke kterým klidně nabídnu link). No zas většina takových boardů má JTAG (ale to má skoro valná většina dnešních zařízení – vždyť Xboxy se už dneska pomalu ani jinak nehackují) a nebo rovnou eJTAG. Přes ten není problém přepnout procesor do debug módu a podstrčit mu libovolné instrukce. Já se teď např. hrabu v PrAcc kódu, který má za úkol dostat se skrze virtuální adresu na NAND a vytáhnout z ní do Test Data Out její obsah. No přepsat tu virtuální adresu z adresy NAND čipu na RAM čip je minimum. Takže není problém přijít, udělat si v rychlosti skrze JTAG dump celé paměti (novější mrchy skrze ten JTAG podporují už i DMA módy ) a pokud tomu procesoru pošleš resume instrukci, tak vyskočí z debugovacího módu tam kde skončil a nikdo ani nic nemusí poznat. JInak:

The industry standard finally became an IEEE standard in 1990 as IEEE Std. 1149.1-1990[1] after many years of initial use. That same year Intel released the first processor with JTAG: the 80486

takže bůh ví jak jsou na tom se zpětnou kompatibilitou Intelí procesory dnes. Ale všechny ostatní populární non-X86 ho mají určitě. I s dokumentací. A to včetně TouchBooku.

Na konferenci LinuxAlt (6.-7. 11. 2010) předvede Petr Krčmář ve svém příspěvku Jak prolomit šifrování disku za dvě sekundy takzvaný cold boot útok.

Sakra, to je mi docela líto že jsem nebyl přítomen. Mohla to být docela sranda. Doufám, že to bude někde dostupné.

[Grunt]

Příloha:

• system-config-kdump.png (354842 bytů)

Zas abych některé pokročilejší distra (no dobře, tak jmenovitě teda tu Fedoru) nehanil úplně, musím uvést že na obranu mají příslušné klikací parametry.

[omg]

firefox je hloupoucky az od verze 3.0 nahoru. do te doby mel plne paralelni gui.

[pepa_u]

A jak je klic pristupny, kdyz se pocitac hybernuje? Je ulozeny spolu s pameti v hybernacnim souboru?

[Jendа]

Ano, pokud je při hibernaci oddíl připojený, pak pochopitelně je. Ale hibernujeme (tedy já už nehibernuji, vystačím si s uspáváním do paměti) zásadně do šifrovaného swapu, takže to nevadí.

[spam]

Thanks for this great post, I find it very interesting and very well thought out and put together. I look forward to reading your work in the future Click here

[spam]

I really loved it here but are there any recent updates? Thanks fencecompanyshreveport.com

[spam]

Well this is great site! Would definitely recommend this to my friends. Love the read lubbock implant dentist

[spam]

Great site thanks admin. More power. quality painting

[Full Form List]

Really I enjoy your site with effective and useful information. It includes a very nice post with a lot of our resources. thanks for sharing. I enjoy this post.

PPE Full Form PSC Full Form GDP Full Form Toefl Full Form BTW Full Form ETL Full Form MNC CMO Full Form PTE Full Form Aissce Full Form

S.Gupta

[Meaninf Hindi]

I really liked these tips and it certainly helps a lot in ranking sites.

Desire Meaning In Hindi Humble Meaning In Hindi Patience Meaning In Hindi Where Are You From Meaning In Hindi Considered Meaning In Hindi Virtual Meaning In Hindi Resistance Meaning In Hindi Committed Meaning In hindi Quite Meaning In Hindi Hypocrisy Meaning In Hindi

S.Gupta

[A2Z List Of]

Thank you for such a big list. More important is: most of them are working till now.

Top 10 IMBD Movies Top 10 Freedom Fighters Top 10 Football Players Top 10 Engineering Colleges In Hyderabad Top 10 Richest Man 10 Direct Selling 10 Richest Country 10 Cryptocurrency List 10 Powerful Countries Top 10 Criminals

S.Gupta