Dotaz: Jak na nejlepší zabezpečení diskové oblasti?

[pVit]

Zdravím, potřeboval bych zjistit, jakým nejlepším způsobem lze zabezpečit nějaká partitiona. Zařízením je zde Raspberryčko, takže potřebuju ochranu přenositelnosti SD karty (že jedna karta půjde jen a pouze na jednom RPi). To se dá obstarat zakryptováním partitiony s tím, že do hesla zakomponuju třeba sériové číslo. Problém je jak pak disk dekryptovat a kryptovat, aby nikdo neodchytil algoritmus a nemohl si dosadit svoje údaje? Bashové skripty si každý dokáže přečíst za pár minut. Zároveň chci, aby se RPi doptávalo na server, zda má diskovou oblast zpřístupnit.

V podstatě tedy potřebuji při bootu mít zakryptovaný disk s heslem, které obsahuje sériové číslo. Při bootu také spouštět nějaký skript ve smyčce, který bude ověřovat, zda má zpřístupnit partition. Pokud ano, složí heslo a odkryptuje partition.

Otázkou je, jak to celé postavit, aby nikdo (nebo aspoň 99% lidí :) ) nezjistil algoritmus dekryptování diskové oblasti.

Odpovědi

[NN]

How can I protect software on the Pi for commercial use?

[j]

jj, takovyhle "reseni" zakaznici doslova zboznujou ... prestane fungovat net a vrata se neotevrou ...

[Peter Golis]

Na toto sa zvykol používať TPM, ale ten by mal mať podporu vo FW zariadenia. Ak sa to oplatí chrániť, tak cena za dosku s niečim takým bude to najmenej.

[VM]

To TPM tam je na zabránění brute force útoku proti tomu heslu, co se zadává z klávesnice?

[Peter Golis]

Kde?

[VM]

Uvažoval jsem scénář, kdy je soukromý klíč v TPM, a to ho vydá po zadání hesla z klávesnice. TPM má omezený počet pokusů o zadání hesla, takže by bránilo aspoň ukradení zaheslovaného klíče z disku a útoku hrubou silou na to heslo (ale pořád zbývá coldboot / získání roota, a vytažení klíče z paměti). Jiné rozumné použití TPM mě nenapadá..

[Peter Golis]

Takže na tú tvoju otázku si si odpovedal sám. Teraz si ešte doštuduj ostatné služby ktoré poskytuje TPM. Potom ťa napadne aj iné rozumné použitie TPM.

[VM]

TPM znám a ne, neodpověděl jsem si.

[Peter Golis]

V tom prípade si to môžeš kľudne doštudovať. Potom pochopíš že tvoja otázka bola zameraná len na jeden aspekt TPM, a zodpovedal si si ju sám. Aj keď si nepochopil ani tvoju otázku, a ani tvoju odpoveď. Na budúce podaj lotériu, s takým šťastím ako máš to vyhráš.

[VM]

Nic jiného tam není, beru to tak že jiné použití než co jsem napsal neznáš.

[petr_p]

Omezit počet přihlášení umí kdejaká čipová karta. Na to TPM netřeba.

Síla TPM je v tom, že má vlastní sériové číslo a vlastní tajný klíč. Klíč nelze přečíst, jen vygenerovat či zapsat. Kombinací těchto dvou hodnot vzniká jedinečný a nereplikovatelný iniciační vektor pro hashovací funkci. Ta potom řetězově hashuje spouštěný kód (firmware, zavadeč, jádro, initram disk atd.), čímž v kterékoliv fázi startu systému máme otisk kódu, který byl až dosud vykonán. Tento otisk pak funguje jako důkaz, že systém je v požadovaném (= nenapadnutém) stavu.

Když budete otisk držet v tajnosti, tak ho můžete použít jako heslo pro rozšifrování blokového zařízení.

Nebo můžete využít další funkci TPM, a to že na hodnotu otisku navážete vydání dalšího soukromého klíče z TPM. A blokové zařízení dešifrovat až tímto dalším soukromým klíčem.

Příště by to chtělo méně arogance a více studia.

[VM]

Chtělo, musel jsem se ptát čtyřikrát. Každopádně díky za popis. To by mohlo fungovat, budou-li tím klíčem šifrovány všechny klíčové části systému, které nejsou hashovány (v opačném případě vyndám kartu, upravím na ní třeba /etc/passwd, vrátím, naloguji se jako root, vytáhnu klíč z RAM, a TPM mě už nezajímá). Tedy pořád zbývají útoky na běžící systém, ale ty jsou těžší.

Ale tohle bude fungovat jen se secure bootem. Pokud by systém nabootoval jakoukoliv kartu, půjde tam dát program co tím TPM hashem prožene FW plus původní bootloader/kernel/initrd, a vytáhne soukromý klíč k těm datům.

[Peter Golis]

Tou prvou vetou rovno priznávaš že si sa musel štyrikrát pýtať aby si si nemusel sám pozrieť definíciu produktu na toto určenú. S tebou musia byť tvoji kolegovia veľmi spokojní.

Ale, už tomu začínaš pomaly chápať.

[VM]

Jdi prosím zvracet jinam.

[Peter Golis]

Ďakujem za ponuku, ale až tak zle mi z tvojho konania neprišlo. V práci mám dosť kolegov ktorí si s tebou môžu ruku podať, takže som voči takémuto tvojmu typu chovania imúnny.

[petr_p]

To by mohlo fungovat, budou-li tím klíčem šifrovány všechny klíčové části systému, které nejsou hashovány (v opačném případě vyndám kartu, upravím na ní třeba /etc/passwd, vrátím, naloguji se jako root, vytáhnu klíč z RAM, a TPM mě už nezajímá).

Ano. Klasický postup je mít vše kromě jádra a initramdisku v šifrovaném blokovém zařízení a v něm LVM a v něm všechny souborové a swapovací systémy. Tohle umožňuje zajistit integritu i utajení.

Jiný postup je, když stačí integrita. Pak místo šifrování se použije IMA na veškerý kód (jaderné moduly, spustitelné programy a dynamické knihovny) nebo i data (konfigurační soubory). V podstatě se posbírají otisky všech souborů a proženou se TPM. Při přístupu k souborům se pak kontroluje, že se jejich otisk nezměnil.

Tedy pořád zbývají útoky na běžící systém, ale ty jsou těžší.

Samozřejmě. Před chybou v ověřeném kódu (jako když na Mac OS stačilo dvakrát zadat prázdné heslo pro roota) vás neochrání nic.

Ale tohle bude fungovat jen se secure bootem. Pokud by systém nabootoval jakoukoliv kartu, půjde tam dát program co tím TPM hashem prožene FW plus původní bootloader/kernel/initrd, a vytáhne soukromý klíč k těm datům.

Nikoliv. Když systém nabootuje z jiné karty, tak se do TPM pošle jiný obsah zavaděče atd. a tudíž hash bude jiný.

Je třeba si uvědomit, že do TPM se posílá kód, který teprve bude spuštěn, a posílá jej tam kód, který již byl takto do TPM odeslán. Čili aby kód mohl podvádět (posílat do TPM jiný obsah, než který hodlá spustit), musel by se takový kód lišit od původního poctivého kódu. Jenže pokud takový kód běží, znamená to, že jeho odlišnost již změnila otisk v TPM ještě před tím, než nepoctivý kód byl spuštěn a mohl začít podvádět.

To samozřejmě přináší otázku, jak je to s úplně prvním kódem, který se posílá do TPM. Tedy s firmware. Správná implementace je, že při zapnutí počítače existuje neměnitelný kód (v ROM), který nejprve odešle obsah firmware do TPM a pak teprve spustí firmware.

Secure boot má podobný ale horší problém: Kdo ověřuje podpis firmwaru a jak má vědět, že kořenový klíč nebyl podvržen? Vzhledem k tomu, že kořenový klíč je možné importovat, obávám se, že secure boot je ve skutečnosti velká habaďůra. Je ještě možnost, že secure boot má dva kořenové klíče. Jeden importovatelný uživatelem a jeden neměnný. Ten neměnný se použije právě pro ověřený firmwaru. Jenže když jsou dva nezávislé kořeny, tak mezi nimi nemůže existovat důvěra a tudíž secure boot opět stojí na vodě. Aby secure boot byl důvěryhodný, kořenový klíč by musel být jen jeden a neměnitelný a nesměl by být vypnutelný.

[VM]

Kontrolovat všechny konfiguráky / binárky / knihovny znamená, že v takovém systému nemůžu nic změnit, ani provést aktualizaci systému. A stačí, když nějaký systémový nástroj na pozadí do nějakého konfiguráku zapíše třeba timestamp, a nenabootuji. Bude to i problém opravit, ledaže mám soukromý klíč zálohovaný někde vedle, jenže to zas snižuje bezpečnost. Takže pro většinu použití docela nešikovné.

Abych nemohl provést ten druhý útok, tak se každý kód musí do toho TPM hashování poslat ještě dřív než se spustí (v opačném případě lze nahradit jiným kódem co tam posílá ten původní kód), a musí s tím začít už BIOS. Pak je pro útok potřeba vyměnit BIOS, což by se mi na současném HW fakt nechtělo dělat.

To s tím secure bootem chápu tak, že admin připraví bootloader, a řekne secure bootu, že má pouštět právě tenhle jeden kód. Proto potřebuji importovat kořenový klíč, a smazat všechny ostatní co by tam byly od výrobce. Ano, celé to pak visí na heslu do setupu a nemožnosti ho smazat, ale aspoň odpadnou problémy s předdefinovaným kořenovými klíči od nedůvěryhodných třetích stran. Nevím, proč by to na nich mělo být závislé.

Neměnný klíč pro ověření FW by asi nefungoval, FW ověřuje sebe sama, stačí z FW vyhodit to ověření, ne?

[petr_p]

BIOS je dneska software jako každý jiný. Velký, modulární, plný chyb a aktualizovatelný. Samozřejmě že ověřování sám sebou není bezpečné.

Bezpečná metoda je mít neměnitelný zavaděč BIOSu. Protože jej nelze měnit, můžeme mu věřit. Ten může poslat BIOS do TPM, či může ověřit jeho podpis proti klíči, který má neměnitelný kód v sobě.

Takový neměnitelný kód opravdu existuje a používá se pro spuštění částí BIOSu, které inicializují plně procesor a chipset. Nicméně zdá se, že výrobci jej nepoužívají jako kořen důvěry.

Třeba IBM v OpenPower strojích má v secure boot dva kořenové klíče. Jedním ověřuje firmware a druhý si může uživatel změnit pro ověření operačního systému. Kořenové klíče jsou uloženy v paměti, do které lze nové kořenové klíče nahrát pouze skrze běžící firmware, který si již vynutí, aby nový firmwarový kořen byl podepsán starým kořenem (zrovna tak jako aktualizace firmwaru). (A uživatelský kořen pouze po předložení hesla, jehož otisk je pravděpodobně uložen v téže paměti). Čili se vychází z předpokladu, že první firmware neobsahuje žádnou bezpečnostní chybu. (Nějak takto byla zabezpečena PlayStation proti instalaci Linuxu a nějak tak si Microsoft představoval secure boot na zábavní technice s armovými procesory.)

Ve světě PC UEFI se TPM zapíná až ve fázi Pre EFI Inicialization. Sice UEFI se do TPM pošle celé, ale ten první neměnný kód, který provádí předešlou Security fázi, to nedělá. Asi se vsází na stejnou kartu jako u OpenPower ­­– že UEFI lze aktualizovat jen z běžícího UEFI.

Přijde mi to docela smutné, protože dobře udělané TPM umožňuje ochránit systém před off-line útokem. Secure boot to nedokáže, protože stačí restovat heslo do setupu, což standardní podporovaná operace.

[lertimir]

To že bash skript lze přečíst je jedno. minimálně 30 let je bezpečnost chápána tak, že algoritmus je znám a utajení je koncentrováno v klíči. Ale moc dotazu nerozumím. Co znamená "(že jedna karta půjde jen a pouze na jednom RPi)"? znamená to, že RPi nenabootuje? nebo po normálním bootu se nepřipojí nějaká datová oblast? pokud je potřeba "Při bootu také spouštět nějaký skript ve smyčce, který bude ověřovat, zda má zpřístupnit partition.", co to znamená? ověřuje se v initramfs nebo po najetí základního systému?

[pVit]

Jen a pouze na jednom RPi znamená druhá možnost - na jiném RPi nebude zpřístupněna datová oblast s veškerými firemními daty. Druhá otázka - spouští se po najetí základního systému (třeba nebude po bootu přístupný internet, tak to testuje, ale přitom je systém normálně přístupný pro práci (třeba na vzdálený přístup)).

[Matlák]

Sorry za off-topic, ale nechápu tyhle z komunity vzešlé DRM snahy. Popravdě doufám že je to jen zvrácený "business" požadavek. Chceš někomu dát RPi aby "bylo jeho a nebylo jeho" zároveň? Uvědomuješ si jaká je to pitomost?

Pokud na takovém DRM trváš, můžeš to nejsnáz udělat asi tak že celé milé RPi zavřeš do trezoru, který při pokusu o otevření svůj vnitřek zničí třeba kyselinou nebo termitem. Ani pak to ale jisté nebude.

[k3dAR]

chce vytvorit projekt ktery nebude opensource a nechce aby mu to nekdo ukradl/kopiroval, na tom neni nic zvraceneho...
muzes sice chtit aby to dal jako opensource a zkusil vydelavat na supportu, ale neni to (a jiste to chapes sam) tvoje vec

[Matlák]

Jasně, pokud je tam přidaná hodnota, tak prosím. Třeba si dokážu představit moduly pro domácí automatizaci, které by kontrolovaly že je k nim připojená ta "správná" malina (ačkoliv pořád je to jen iluze a samozřejmě to půjde s trochou snahy obejít, spíš bych to chápal jako ochranu před zloději a ne před vlastním majitelem). Ale pokud je to jen SW, tak je otázka proč stavět na něčem co je otevřené z principu (napadá mě snad jen cena, bohužel).

Jinak to s tím trezorem se pokud vím v bankovnictví snad pořád používá, přeci jen nejlepší TPM je takový zavřený v trezoru

[pVit]

Jedná se o pronajímání zařízení s firemním softwarem. V podstatě musíme ošetřit, aby tento prostředek, který může ovládat stroje za desítky milionů, nebylo možné zneužít tak, aby vznikaly škody dané konkurencí firem (když už se někdo do RPi nabourá a zjistí algoritmy, tak mu půjdou pouze na jeho vlastním zařízení, ale do jiného se nedostane).

Ano, z prvního pohledu je to zbytečné stejně jako hesla síťářů jk minimálně 30 znaků všech typů. Když se ale jedná o věci, při jejichž zneužití by byly škody desítky až stovky milionů, tak se nesmí nic podcenit.

[Peter Golis]

A čo vám bráni použiť dosku ktorá má v sebe nejaký spomínaný spôsob ochrany? Nepredpokladám že by to bola cena, alebo know-how viazané na výučbovú dosku pre deti na školách.

[jiwopene]

SW řešení

Četl jsem, že RPi umí bootovat po síti (nezkoušel jsem to), takže by šlo vzít nějaká data z desky (MAC adresa, ...) a karty (třeba pár bajtů na konci, karty, kde není žádná partition), udělat z toho heslo a tím to dešifrovat. Nezapomeňte, že se vždy dá najít způsob, jak to chytit "za běhu" (např. podstrčit jiné jádro).

HW řešení

Lepidlo přes slot na kartu. (Vypadá to na nejspolehlivější způsob)