Fórum Root.cz
Hlavní témata => Software => Téma založeno: Radek Zajíc 28. 11. 2016, 00:14:19
-
Ahoj,
Pouzivate nekdo nejaky loader (TrustedGrub nebo nejakou alternativu), ktery nabizi "measured boot", tedy udelat snimek sama sebe, snimek kernelu a initramdisku, snimek parametru kernelu, a to vse ulozit do TPM?
Rad bych zprovoznil automaticke odemykani LUKS rootfs pri bootu s vyuzitim measured bootu a TPM, coz by mohlo jit pomoci luks-tpm, ale problem je v rozumnem naplneni TPM registru (PCR) bootloaderem.
TrustedGrub (fork grub-legacy) by sice mel delat presne to, co potrebuji, ale nejde zkompilovat (resp. po heavy patchovani jde, ale produkuje >100 MB stage1 a stage2 soubory, coz na disk nejde nainstalovat :-))
TrustedGrub2 jde zkompilovat, nainstalovat a dokonce i nabootuje, ale staci jakakoli udalost v grub menu (stisk libovolne klavesy) a uz jsou hodnoty v PCR jine, nez kdyz grub menu vytimeoutuje a spusti prvni menuitem. To brani predpocitani hodnot PCR z beziciho systemu (nikdo nevi, kdo kolikrat zmackne klavesu...) a tim padem znemoznuje skutecne fungujici a nerozbijejici se boot.
Masina, kde to zkousim, nema EFI, takze jsem se ani nezabyval tim, jestli by pro muj ucel sel znasilnit secure boot.
Za jakoukoli ideu budu rad.
Diky.
-
PLS PLS ked to vyriesis podel sa o vysledok. Dlho som sa snazil o setup automatickeho odomykania luks s measured bootom vo vsetkych stageoch (od biosu), ale neuspel som.
-
:-)
Zatim jsem musel ohackovat trustedgrub2, aby mi do pcr-15 ukladal hash cmdline a do pcr-14 hash z vmlinuz+initrd, cimz simuluju chovani trustedgrub-legacy. Zvazuju poslat to jako pull request do repozitare trustedgrub2, imho by se to mohlo hodit i jinym.
Ted me ceka hackovani luks-tpm pro podporu trustedgrub2, protoze existujici verze je usita na miru trustedgrub-legacy a fedore/centosu.
Protoze to zkousim na Ubuntu, budu muset upravit/predelat i premount skripty cryptrootu.
Trosku me prekvapilo, jak spatne na tom je v oblasti measured bootu a FDE Linux oproti Windows a jejich Bitlockeru.
-
Ja to potrebujem na Alpine Linux, cize s manualnou pracou ratam. Uz ani neviem kde som skonl, vytesnil som tie spomienky.
Vobec sa mi vsak nepodarilo tlacit do TPM registrov hodnoty.
-
OK, takze to funguje a docela dobre.
TrustedGrub2 po opatchovani poslusne plni PCR registry sha1 hashem cmdline, vmlinuz a initrd
Luks-tpm po opatchovani funguje dobre s trousers, umi si brat hesla (TPM owner a TPM NVRAM) ze souboru s hesly
Dalsi skripty vycitaji hodnoty z TPM pri bootu a pokud narazi na takovou ulozenou hodnotu, ktera je overena v aktualnim PCR prostredi, tak ji pouzijou pro luksOpen
Jeste mi chybi doplnit do tpm-luks podporu pro checksum trustedgrub2, ale i bez tehle kontroly se pouzity pristup ukazuje jako funkcni...
Co s tim ovsem pak? Udelat fork vsech patricnych nastroju na githubu, udelat patche oproti aktualnim verzim, nebo z toho udelat *.deb baliky, ktere pujdou nejak rozumne nainstalovat?
Napsat clanek na root?
-
A cílem snažení je, že až ti někdo ukradne počítač, tak aby se nemusel obtěžovat s odemykáním? ::)
-
A cílem snažení je, že až ti někdo ukradne počítač, tak aby se nemusel obtěžovat s odemykáním? ::)
Souhlasím, také v tom moc nevidím smysl ::)
-
A cílem snažení je, že až ti někdo ukradne počítač, tak aby se nemusel obtěžovat s odemykáním? ::)
Souhlasím, také v tom moc nevidím smysl ::)
Jen tipuju: není cílem třeba to, aby zloděj sice mohl nabootovat, ovšem do systému ke kterému stejně nezíská přístup (a ani z něj nevytáhne šifrovací klíče, atd.)? To, že je systém schopný nabootovat konkrétní předem daný OS přece neznamená že je hacknutelný? Když použiju paralelu: pokud mi někdo šlohne mobil, taky mě netrápí že Android nabootuje a pak čeká na odemknutí. Hlavní je, že dotyčný nezíská přístup k datům ani kdyby ten mobil rozebral a vypájel flash čip s úložištěm dat. Nebo se pletu?
-
A cílem snažení je, že až ti někdo ukradne počítač, tak aby se nemusel obtěžovat s odemykáním? ::)
Souhlasím, také v tom moc nevidím smysl ::)
Jen tipuju: není cílem třeba to, aby zloděj sice mohl nabootovat, ovšem do systému ke kterému stejně nezíská přístup (a ani z něj nevytáhne šifrovací klíče, atd.)? To, že je systém schopný nabootovat konkrétní předem daný OS přece neznamená že je hacknutelný? Když použiju paralelu: pokud mi někdo šlohne mobil, taky mě netrápí že Android nabootuje a pak čeká na odemknutí. Hlavní je, že dotyčný nezíská přístup k datům ani kdyby ten mobil rozebral a vypájel flash čip s úložištěm dat. Nebo se pletu?
Cil je, aby se nedostal k datum. To se udela daleko snaze, kdyz ani nenabootuje.
U mobilu je to o neco slozitejsi, uz jen protoze chces nechat moznost volat nouzova cisla i bez hesla.
-
Cilem je full disk encryption na masine, ke ktere potencialne muze mit pristup dost lidi vcetne uklizecek (stroj pobezi v praci) a automaticke odemykani disku, aniz by klic mohl kdokoli vzit a disk si odemknout.
Roli samozrejme hraje i pohodli (automaticke odemceni disku bez nutnosti zadavani dlouheho hesla).
Pokud se k datum v pocitaci nekdo pokusi pristoupit, musel by zajistit pritomnost spravneho bootloaderu (hashe MBR a celeho grubu musi sedet), kernelu, initrd (hashe museji sedet) a kernelove cmdline (opet musi sedet hash).
Uplne jinou kapitolou je nastaveni systemu tak, aby se k datum v PC nikdo nedostal pomoci klavesnice, monitoru a dalsich periferii, pripadne po siti, v okamziku, kdy je uspesne nabootovano. :-)
-
Rozumím. Čili výsledek je víceméně stejný, jako kdyby tam žádné šifrování nebylo, ale zato hrozí asi 1000x víc možností, jak se to celé posere tak, že už se k datům nikdy nikdo nedostane.
-
@Radek Zajíc urcite chvalim, pred casem sem se pokousel (vzdalene) o neco podobneho, bez znalosti patchnout cokoliv jineho nez init script, dostal se se jen do stavu ze sem mohl ulozit klic to TPM, ale TrustedGrub mi ho nenacital, resil sem to na *buntu s tim ze v te dobe byl aktualni stav dostupnej jen pro Fedoru...
takze za me ucite diky, na otazku co dal? rozhodne udelat fork na github vseho co si upravil a napsat readme pro nasazeni v *buntu ze zdrojaku, pokud by si chtel vytrvaret deb, pak asi by bylo dobre skouknout automat na launchpadu a zalozit tomu ppa, zajimave by pak byl i clanek kterej by mohl nalakat i lidi co se toho jinak bojej, nebo je alespon trochu dostat do deje...
pro ostatni, princip je v tom ze klice jsou sice ve stroji, takze system se odemkne automaticky pri spusteni (ovsem zde prichazi samozrejme (narozdil od rucniho odemknuti luks uzivatelem pri startu) zakaz autologinu do desktopu/console)...
ale v pripade ze se nekdo pokusi vyndat disk, nebo nastartovat na tom livecd/usb, nebo podvrhnout vlastni initrd/kernel, nebo pridat kernel parametr, nebo proste udelat cokoliv jineho nez vlastnik dovoli, tak je proste smula a disk se neodemkne...
narozdil od toho kdy by byl system sifrovan a odemknut vyhradne rucne pri startu, je toto i vhodne proto aby system byl pri zapnuti zarizeni nastartovan a napr. v pripade ze nestartoval vlastnik, tak aby se spustili lokalizacni nastroje kterre odhali zlodeje a misto kde se nachazi atd...
-
Rozumím. Čili výsledek je víceméně stejný, jako kdyby tam žádné šifrování nebylo, ale zato hrozí asi 1000x víc možností, jak se to celé posere tak, že už se k datům nikdy nikdo nedostane.
Nerozumis, kdyby nebylo sifrovani tak si "vetrelec" nahodi LiveCD/USB a ma root a pristup ke vsemu na disku...
Tohle zaroven v pripade ze by automat neodemkl (to tve posere) muze umoznit rucni odemknuti tak jako je bezne u normalne full-disk luks-sifrovaneho disku...
-
Kdyby tam žádné šifrování nebylo, tak kdokoli nabootuje livecd (po vymazání hesla v BIOSu resetem CMOS) a k datům se dostane.
Kdyby byl klíč k LUKSu uložen na připojené flashce, tak jej dokáže kdokoli se schopností "číst v initramdisku" zkopírovat, disk si odemknout a k datům se dostat. Podobně (hůř) kdyby byl klíč přímo v initramdisku.
Rozdíl je v tom, že z TPM dostanete data jen tehdy, když bude systém v předem definovaném stavu. A to platí pro BIOS, kompletní zavaděč, linuxové jádro, initramdisk a cmdline.
Změna jakéhokoli byte v kterékoli fázi bootu způsobí odchylku od definovaného stavu a TPM klíč k odšifrování disku nevydá.
Oddíl s LUKSem má víc keyslotů a v jednom z nich je i dlouhé a složité heslo pro recovery, pokud by došlo k poškození TPM nebo rozbití "definovaného stavu systému".
-
Tak tu mame prvni balicky dostupny pres PPA. Zatim pro Ubuntu 16.10 a 17.04.
Grub2 (i pro UEFI) s podporou TPM a sada skriptu a nastroju pro automatizaci nasazeni jsou na https://launchpad.net/~radek-zajic/+archive/ubuntu/measuredluks
Zatim bez dokumentace. :-)
-
Zajímalo by mě to z pohledu útočníka. Napadá mě několik možností:
1) Coldboot na RAM. Díky automatickému odemykání mám nekonečně mnoho pokusů, takže nevadí, že se to občas nepovede. Pravděpodobně si ve stroji můžu i vyměnit paměťové moduly za svoje, protože se ví, že u některých značek/modelů jde coldboot udělat snáze než u jiných. V krajním případě si můžu vyrobit modul, který má přepínač, který ho přepojí na externí napájení a externí refresh a pak si ho můžu v klidu vyčítat jak dlouho chci. Protože RAMky jsou AFAIK identifikovatelné jenom pomocí onboard I2C flashky, po jejím přepisu systém ani nemá jak poznat, že se něco změnilo.
2) Jak TPM ověřuje, že ten hash je skutečně hash věcí v paměti? Přes jakou sběrnici to komunikuje s CPU/RAM? Jak dobře se dá tato komunikace sniffovat a podvrhnout?
-
Stejne jako u Windows je i tohle reseni jen omezene bezpecne. :-) Microsofti k tomu maji pekny diagram na https://technet.microsoft.com/en-us/library/ee706531(v=ws.10).aspx (https://technet.microsoft.com/en-us/library/ee706531(v=ws.10).aspx).
Zjednodusene:
1) je to samozrejme nachylne na cold boot attack a tam, kde jsou dost citliva data, je tohle pouziti samozrejme nedostacujici. Paranoici necht zustanou u rucniho zadavani hesla a duvere v to, ze jim dabelska pokojska nepodvrhla initrd.
2) Dal se da TPM teoreticky odposlechnout (je pripojen pres LPC https://en.m.wikipedia.org/wiki/Low_Pin_Count (https://en.m.wikipedia.org/wiki/Low_Pin_Count)). To se dela hur tam, kde je TPM primo na desce, ale jinak data poputuji po sbernici v cleartextu.
3) Je treba pohlidat, aby pouzivany initrd neskoncil NIKDY v shellu. Proc? No, pokud napr. prepisu LUKS header docasne nulami, selze odemykani. V takovem pripade by me system hodil do shellu, ve kterem si muzu data z tpm vycist. Debiani initramdisky v pripade, ze je kernelu pridan parametr panic=X, rovnou rebootuji a heslo k disku tak neni ohrozeno.
4) V bezicim systemu je treba provest alespon zakladni zabezpeceni (bezny uzivatel nesmi mit moznost cist data z NVRAM TPM; do systemu se nesmi prihlasit guest; a pod.)
5) Sitove sluzby toho taky muzou dost prozradit a dost dat vydat. Nabizi se moznost provest lockdown v okamziku, kdy bude system nabootovan na miste, ktere nebudu znat.
-
2) Dal se da TPM teoreticky odposlechnout (je pripojen pres LPC https://en.m.wikipedia.org/wiki/Low_Pin_Count (https://en.m.wikipedia.org/wiki/Low_Pin_Count)). To se dela hur tam, kde je TPM primo na desce, ale jinak data poputuji po sbernici v cleartextu.
Počkej, to jako fakt stačí jenom sniffnout? Sniffer na něco podobného jsem shodou okolností dělal minulý víkend, tady ta fotka (https://jenda.hrach.eu/brm/rad/tpol/lap2.jpg) je asi nejvýmluvnější - z kaptonu a mědi jsem vyrobil křidélko, na jednu stranu jsem připojil pin header a druhou stranu jsem napájel naprasáka přímo na nožičky čipu (jde to překvapivě snadno když už to člověk umí - doporučuji nejdřív natrénovat na nějakém tišťáku na vyhození). Zařízení kupodivu zůstalo funkční a po připojení logického analyzéru vidím co tam teče (https://jenda.hrach.eu/brm/rad/tpol/lap1.png).
-
S tim sniffovanim je to hodne teoreticky utok. Praktickou realizaci se mi najit nepodarilo, takze bud to nikdo neumi, nebo je to tak slozity, ze to nikdo nedela. (Tady muzou byt tezsi a lehci realizace v zavislosti na tom, kde je TPM - krome samostatnyho odpojitelnyho modulu, mezi kterej a desku muzes zapojit relativne univerzalni odposlouchavaci elektroniku, muze byt tekzy az nerealizovatelny delat odposlech u TPM napajenyho na desce, a pak prakticky nemozny u firmwareTPM, ktery jsou soucasti Intel TXT a TPM je tudiz v procesoru.)
Neco malo materialu k utokum, ovsem bez dukazu, ze z toho nekomu tecou data v podobe, ktera by byla citelna:
https://online.tugraz.at/tug_online/voe_main2.getvolltext?pCurrPk=59565
https://securingtomorrow.mcafee.com/business/security-connected/tpm-undressed/
-
muze byt tekzy az nerealizovatelny delat odposlech u TPM napajenyho na desce
Ano, taky mě zarazilo, kolika odborníkům na software moc nejde pájení a elektronika :)
Osobně si troufnu tvrdit, že bych zvládl takovýto sniffer i na BGA (odpájet, připájet na vlastní desku, vložit „proxy“), jen by holt hardware nestál pade, ale litr.
Pokud by ale TPM umělo nějaký DH nebo ještě lépe kdyby v procesoru byl klíč, kterým se autentizuje, tak data na sběrnici samozřejmě budou k ničemu.
a pak prakticky nemozny u firmwareTPM, ktery jsou soucasti Intel TXT a TPM je tudiz v procesoru.)
Samozřejmě.
Ale furt si myslím, že ten cold boot by měl jít. Teď chtěli šifrovat obsah RAMky, ale zatím se to myslím nepoužívá.
-
Cold boot nebo zneuziti DMA pomoci firewire a pod. jsou utoky, proti kterym pomuze jen uplne jina uroven zabezpeceni.
-
Cold boot nebo zneuziti DMA pomoci firewire a pod. jsou utoky, proti kterym pomuze jen uplne jina uroven zabezpeceni.
Rozdíl je v tom, že při použití normálního šifrování musí útočník dostat spuštěný počítač. Když se klíč tahá automaticky z TPM, stačí mu počítač vypnutý a má spoustu času si útok připravit a má spoustu pokusů.
-
Radku díky za dobrou práci! Právě řeším úkol, kde potřebuji totéž, co jsi vyřešil. Jsem systémák, ale těžko bych úspěšně programoval. Díky moc.
-
Neni zac :-)
Moc jsem tam toho nenaprogramoval a zatim je to porad spis alfaverze.
Nedavno jsem mel problem s UEFI na novem Dell XPS, pocital jinak hash pro PCR[5] a jeste jsem se nedostal k hlubsi analyze, jak (jen tusim). Takze pokud byste na to nekdo narazil, doporucuju vypnout sealing na PCR[5] v /etc/tpm-luks.conf.
EDIT: a taky se to nema uplne rado s disky jinde nez na /dev/sd* (tzn. treba /dev/vda prip. /dev/nvm*). Opet mam nejakou alfa opravu, ale hardware s NVMe diskem jsem vratil...
-
Pokud se juknu na stránky microsoftu, co jsi tu dal, tak tam píšou:
TPM only
The TPM validates early boot components. When using a TPM, this is the least secure unlock method for operating system drives.
Recommended for computers in a physically secure location and for situations where unattended restart is required, such as when Wake On LAN solutions are used or for servers in remote locations.
Takže je to pro tvůj případ, kde k počítači má přístup uklízečka, nevhodné.
-
Takže je to pro tvůj případ, kde k počítači má přístup uklízečka, nevhodné.
No vidíš, to nás pitomce napadlo (https://forum.root.cz/index.php?topic=14331.msg188710#msg188710) hned (https://forum.root.cz/index.php?topic=14331.msg188869#msg188869), ale jinak si holt každý tou metodou slepých uliček musí projít sám, no...
-
Takže je to pro tvůj případ, kde k počítači má přístup uklízečka, nevhodné.
No vidíš, to nás pitomce napadlo (https://forum.root.cz/index.php?topic=14331.msg188710#msg188710) hned (https://forum.root.cz/index.php?topic=14331.msg188869#msg188869), ale jinak si holt každý tou metodou slepých uliček musí projít sám, no...
souhlasim jen s polovickou a to ze jste pitomci ;) dejme si 2 situace:
1. myslenka vlakna: uklizecka zapne pc, samo se odemkne LUKS z TPM a nabehne do login screen
2. bez TPM unlock: uklizecka prijde k jiz zapnutemu PC s rucne odemknutej LUKS a kouka do login screenu
rozdil mezi situaci 1 a 2 neni z bezpecnostniho hlediska zadny v pripade ze PC bezi, pouze pokud nebezi se muzeme bavit o tom ze by mohla v situaci 1 teoreticky vyuzit prubehu nezabezpeceneho startovani, ale pouze na tom konkretnim HW a bez zmeny v konfiguraci protoze z TPM se LUKS odemkne jen kdyz sedi HW otisk...
-
Ano, jak správně píšeš, zabezpečili jsme velké hovno, zato jsme výrazně zvýšili nebezpečí ztráty dat. Noooo a to se wopravdu wyplatí!!!
;D ;D ;D
-
Ano, jak správně píšeš, zabezpečili jsme velké hovno, zato jsme výrazně zvýšili nebezpečí ztráty dat. Noooo a to se wopravdu wyplatí!!! ;D ;D ;D
mluv za sebe, ty zabezpecis velke hovno... a druhe si jeste s nadsenim rozpatlas po xichte a radostne se nad tim tlemis... ;) clovek co se nechova jako pitomec chape moznosti a okolnosti ktere s tim souvisi a ktere musi poresit...
-
Ano, opravdu nechápu úžasné "možnosti" "šifrování", které se samo rozšifruje. Jsem prostě blbec, no.
-
Ale furt si myslím, že ten cold boot by měl jít. Teď chtěli šifrovat obsah RAMky, ale zatím se to myslím nepoužívá.
OT: intel s vmware maji funkcni hw i hypervizor, ktery kompletne sifruje runtime virtualu. Netusim sice jak maji vyresene live migrace ale pry to maji na papire vyresene.
-
Ano, opravdu nechápu úžasné "možnosti" "šifrování", které se samo rozšifruje. Jsem prostě blbec, no.
Ocividne to nechapes, tak se zkuse jeste zamyslet:
- zmenis HW a nic se samo nerozsifruje
- pustis system z USBFlash, k datum se nedostanes
- vyndas DISK a prendas jinam, k datum se nedostanes
- kdyz je HW zapnutej tak je DISK rozsifrovanej nezavisle na tom jestli LUKS bylo pri startu zadane rucne nebo automat
-
Ano, opravdu nechápu úžasné "možnosti" "šifrování", které se samo rozšifruje. Jsem prostě blbec, no.
Tady musím souhlasit.
Můj příspěvek ale poukazoval na to, že sem zakladatel odeslal link/materiál, který mu sám říká že to co chce je blbost a né bezpečné, nechtěl jsem z nikoho dělat pitomce :P
-
Zakladatel sem zadny takovy link ("ze je to blbost") rozhodne nedaval. Je to bezpecne s tim, ze bezpecnost ma urcitou uroven. Ta se da ruznymi dalsimi opatrenimi zvysit (doplnujici/podpurne kontroly pro odemceni) i snizit (diry v konceptu).
-
Ano, bezpečnost je na té úrovni, že když sbalím bednu (typicky P&Ch), tak jako by tam žádné šífrování nebylo. Juch! ::)
-
Ano, bezpečnost je na té úrovni, že když sbalím bednu (typicky P&Ch), tak jako by tam žádné šífrování nebylo. Juch! ::)
ale nekecej ;) kdyz by nebylo sifrovani, tak vyndas HDD a das jinam, nebo na tom pustis z USB Flash system a mas pristup ke vsem datum na HDD jako root...
nekdo resi PC co mu nekdo ukradne a pri restartu jede pres celou republiku zadat LUKS heslo...
nekdo neresi co PC ktere by nekdo ukradl a heslo pri restartu chce zadavat automaticky, ale zaroven mit sifrovanej disk...
reseni hodit dropbear do initrd a pri restartu se vzdalene pripojit a zadat heslo rucne je neco mezi...
zkus se zamysle ze jsou ruzne potreby a ty tvoje nejsou potreby lidi celeho sveta, treba se tim tva omezenost a netolerance zmensi a budes mene otravnej ;)
-
Taky me hluboce dojima, jak tihle fundamentalisticky kecalisti jen hledaji duvod, proc neco nedelat. Ve finale prijdou na to, ze nejlepsi zpusob, jak ochranit data, je zadna nemit. Protoze jak neco mas, tak nejpozdeji po druhem odvrtanem kolenu reknes i co sis myslel, zes uz davno zapomnel.