Dotaz: FDE a TPM - od kdy šifrovat data?

[Deryl]

Ahoj,

mám funkční Full Disk Encryption (LVM on LUKS) kromě /boot (samostatný nešifrovaný oddíl), odemyká se heslem při startu počítače.

Jedná se o server běžící neustále, zadávání hesla je problém. Rád bych se vyhnul metodám:

• získávání klíče po síti
• z připojené USB flashky,
• nutnost vzdáleného přihlášení (SSH) a ručního odemknutí šifrované části.

Studuji tedy využití TPM 1.2 pro uložení klíčů. Pokud to dobře chápu, tak možnosti jsou:

1. /boot zůstává nešifrován na samostatném oddíle (grub + kernel + initramfs). Nacpat vlastní "hooks" do initramfs (integrita biosu, bootloaderu, kernelu + initramfs) a je-li vše ok, odemknout LUKS a pokračovat ve bootování. Popsáno zde . Dnes by již mělo být možné použít GRUB 2.X namísto TrustedGRUB.
2. /boot je součástí šifrovaného disku, ale je nutné zabalit jeho obsah do jedné binárky - uefi boot loaderu. Řekl bych, že z hlediska bezpečnosti to vypadá podobně jako bod 1. Popsáno zde.

U obou jsou potíže s aktualizací bootloaderu, kernelu a initramfs (používám Arch Linux, na žádnou automatizaci jsem nenarazil).

Neexistují ještě další postupy? Čistě paranoidně bych byl raději, kdyby ověření integrity proběhlo už v boot loaderu a kernel + initramfs by se načítal až z šifrovaného oddílu.

---

---

Odpovědi

[Teddy_cz]

Zdravím,

já používám dropbear což je malý SSH server. Při čekání na heslo se přihlásím pomocí SSH a toto heslo zadám. Pro přihlášení se použije SSH klíč. Po naběhnutí systému se dropbear vypne.

[petr_p]

Mám pocit, že Grub2 podporuje jen TPM2.

Psaní vlastního háčku do initramfs (pokud to už někdo neudělal), je nutnost. Ale v tom háčku vy žádnou integritu neměříte. To za vás udělá Grub. To, co v háčku budete dělat, že

• buďto si necháte pomocí TPM dešifrovat heslo k LUKS, přičemž TPM to provede, pouze když obsah registrů< TPM bude stejný jako při zašifrování hesla,
• nebo použijete obsah registrů PCR jako heslo k LUKS.

Já osobně používám druhou možnost, protože je jednodušší.

Dejte si ale pozor na to, kdo má přístup k TPM z korektně zavedeného systému. Registry TPM v Linuxu může číst kdokoliv, stačí ale chmod 0400 na patřičné soubory v sysfs. Jestli dešifrovat může kdokoliv, to netuším. Taky v druhém případě si dejte pozor, aby alespoň jeden registr měřil úplně vše od firmwaru až po initramfs. Jinak by útočník mohl pozměnit initramfs, a heslo k LUKS zkonstruovat jako zřetězení registrů, které initramfs neměří, a vypočítaných hodnot registrů, které initramfs měří, ale je znám jejich inicializační vektor.

Ano, aktualizace měřených souborů je problém. Jakákoliv jejich změna vede ke znevěrohodnění systému a systém nenastartuje, protože nedokáže dešifrovat kořenový systém. To je ale zároveň požadovaná vlastnost.

Já jádro měním vždy, když jsem fyzicky u stroje. V initramfs mám kód, který při selhání připojení kořene se zeptá na jiné heslo a po jeho zadání mi dá shell. Jiné heslo je v initramfs uložené jako otisk, takže přečtení initramfs ho neprozradí. Z shellu prostě odemknu LUKS dalším heslem, nechám boot doběhnout a po otestování nového jádra zaktualizuji slot v LUKS, který se pomocí TPM.

[Deryl]

Díky za užitečné poznámky. Jen doplním:

• Grub2 2.04 podporuje TPM 1.2 i 2 (funguje mi pro v1.2, zaplní PCR 08 a 09). Umí 'measurements', ale neumí číst nvram (nebo to není dokumentováno).
• TrustedGrub2 podporuje i příkazy pro manipulaci s TPM (asi jen v1.2) - tedy např. čtení nvram.  To bych mohl využít pro odemykání zašifrovaného /boot, ale vzhledem k tomu, že je 3 roky neudržovaný a nepodporuje UEFI boot, tak to asi nechám plavat.

Dále:

V initramfs mám kód, který při selhání připojení kořene se zeptá na jiné heslo a po jeho zadání mi dá shell. Jiné heslo je v initramfs uložené jako otisk, takže přečtení initramfs ho neprozradí. Z shellu prostě odemknu LUKS dalším heslem, nechám boot doběhnout a po otestování nového jádra zaktualizuji slot v LUKS,

Není to zbytečně komplikované?

Mám v plánu přidat do initramfs jen jeden hook - na přečtení klíče z TPM pro LUKS a jeho uložení do souboru. Existující hook 'sd-encrypt' podporuje otevření LUKS oddílu s paramatrem key-file, pokud klíč nenajde (nebo otevření selže), standardně se optá na heslo pro crypttab (na konsoli, vyzkoušeno). Tuším, že podobně by se mohl chovat i původní hook 'encrypt' (prostřednictvím konfigurace v /etc/crypttab).

[petr_p]

Je to zbytečně komplikované. Ale já mám ještě vespod diskové pole, takže možnost zjistit, co se přesně rozbilo, je k nezaplacení.

[Deryl]

A ohledně aktualizace:

buďto si necháte pomocí TPM dešifrovat heslo k LUKS, přičemž TPM to provede, pouze když obsah registrů< TPM bude stejný jako při zašifrování hesla,

Ten extra restart počítače při změně grub/kernel/... pro uložení klíče do TPM (seal) dost komplikuje automatizaci. Jedině, že bych jiný, dočasný, LUKS klíč uložil natvrdo do initramfs pro první restart a následně jej smazal a pro další restarty by se opět použil ten vytažený z TPM.

nebo použijete obsah registrů PCR jako heslo k LUKS.

Lze dopředu zjistit, jaké budou hodnoty PCR, aniž bych restartoval počítač? (Po aktualizaci kernelu atd..) Tj. mohl bych vyjít z předpokladu že např. PCR 00 - 03 zůstane beze změny, ostatní až po PCR 09 už by nějaký prográmek mohl přepočítat. Tyto hodnoty bych pak uložil jako aktualizovaný klíč pro LUKS.

[Deryl]

Tak na toto si asi odpovím sám: nástroje nejsou, mohl bych si to sám naskriptovat podle measurement logu Grub2 (ale dle bug reportů se neloguje vše) a modlit se, že Grub2 nezmění metodiku. Asi bude snazší upgradovat jednou za čas, abych nemusel monitor a klávesnici nosit do sklepa moc často kvůli heslu na konsoli

[Deryl]

Jenom doplním, že nejspíše zvolím variantu klíče uloženého v NVRAM.

Mělo by to výhodu pro aktualizaci:

• před restartem ponechám klíč v NVRAM, ale dočasne vypnu nutnost shody PCR se stavem při původním uložení ("seal" s nulovým heslem).
• Restartuju, TPM vydá klíč "komukoliv".
• Opět provedu "sealing", raději však nového, klíče na aktualizovaný stav PCR registrů.
• Pomodlím se a restartuji. Když to nenaběhne, poběžím s LCD a klávesnicí do sklepa k serveru...

[k3dAR]

z praxe LUKS+TPM neznam, pouze sem se parkrat zkousel chvili o tom neco najit, takze pridam jen 2 odkazy:
https://www.linuxdays.cz/2017/video/Radek_Zajic-FDE_bez_zadavani_hesla.pdf
https://github.com/zajdee/tpm-luks

[Deryl]

Díky. Čtu různé návody stále dokola, už to dává větší smysl.

Našel jsem detailní diplomku.

[Josef Kufner]

Už jsem to tu párkrát psal, zahoď Grub, nainstaluj SicherBoot a nech si upéct EFI binárku s kernelem a initrd. Tu pak můžeš bootovat rovnou bez Grubu, ale SicherBoot ti nastaví i jednoduchý EFI bootloader. Pak /boot přesuň na šifrovaný oddíl a nech venku jen EFI oddíl s tou EFI binárkou. Na závěr si ještě vygeneruj vlastní klíče pro Secure Boot a zapni ho (SicherBoot ti řekne jak). Teprve poté, co nabootuješ něco aspoň trochu důvěryhodného, má smysl řešit klíče k LUKS.

[petr_p]

Jestli pán má UEFI (nenapsal), tak žádný zavaděč nepotřebuje. Kernel změří firmware. initramfs možná taky (UEFI stub v jádře načítá initramfs skrze služby UEFI a ty by mohly měřit všechno, co skrze ně projde). V opačném případě může přilepit initrmfs k obrazu jádra už při kompilaci (CONFIG_INITRAMFS_SOURCE).

[Josef Kufner]

Však píšu, že to jádro se zapečeným initrd jde bootovat rovnou. Potíž je v tom, že integrace efibootmgr není a různé počítače mají všelijak více či méně použitelné bootovací menu, takže ten bootloader se docela hodí. Navíc ten bootloader umí takové hezké věci, jako že když to nenabootuje, tak to zkusí ještě párkrát a pak automaticky nabootuje starší jádro (viz bootctl a systemd-boot). U serveru za devatero horami se to docela hodí.

[k3dAR]

+ pridava si KeyTool na manipulaci s vlastnima klicema v/do EFI, umoznuje nastavit primo v Bootmenu vychozi polozku, timeout po ktery bue cekat nez ji pusti atd... jeste jednou diky za tip na sicherboot minule (na strojich kde mam SecureBoot uz sem na nej presel)

[Deryl]

No, podívám se na to. Arch Linux snad má nějakou automatizaci při upgradu (znovupodepsání).

[Josef Kufner]

V Debianu to plně automatické je.

[Deryl]

Tak Secure Boot nebude. Mám 11. generaci Dell PowerEdge. Podpora v UEFI je teprve od 12. generace.

[Josef Kufner]

Takže pokud útočník bude chtít dešifrovat disk, tak stačí upravit initramdisk, aby si uložil heslo a jednou to spustit, aby TPM dešifrovalo?

[petr_p]

To nestačí. Ještě musí přijít člověk a to heslo tam naťukat. Což člověk znalý neudělá, protože ví, že kromě poruchy to může být útok.

Spíše mi vysvětlete, jak by mě měl ochránit secure boot. Jako útočník přidám před váš postup jeden krok: Vypnu secure boot v nastavení firmwaru.

[Josef Kufner]

Do nastavení firmwaru se nedostaneš, protože je k němu nastavené heslo.

[Petr Fiedler]

A co když někdo rozebere stroj (jumper, baterie)?

[Josef Kufner]

To by mělo resetovat i TPM a zahodit tak klíče k disku úplně.

[Petr Fiedler]

Takže útočník se na disk nedostane a majitel, pokud má zazálohované klíče ano?

Slyšel jsem o nb (HP), u kterého prý nepomůže ani vytažení baterie. Pokud je firmware zaheslovaný, tak to prý nepomůže. Ale jak tu psal k3dAR. Stále se dá přeflešnout čip.

[Josef Kufner]

Takže útočník se na disk nedostane a majitel, pokud má zazálohované klíče ano?

V ideálním případě by to tak mělo být. Otázkou je, jak to je skutečně implementované a zda tam nejsou chyby.

Stále se dá přeflešnout čip.

S tím už toho moc nenaděláš. Také tím nevyřešíš obranu proti cold-boot útoku. Na to by byl potřeba nějaký destrukční mechanismus při fyzickém otevření počítače. Na cold-boot ještě pomůžou paměti připájené na desce, ale proti přeflashování firmwaru nenaděláš nic než to nějak pořešit fyzicky.

[Petr Fiedler]

V ideálním případě by to tak mělo být. Otázkou je, jak to je skutečně implementované a zda tam nejsou chyby.

Tak pokud to bude fungovat, tak je to dobré.

Já naneštěstí na obou strojích nemám TPM, ale jen PTT. Takže kdybych si nastavil sicherboot a někdo by pak vytáhnul baterii z MB, bude to potom fungovat stejně jako s TPM?

[petr_p]

TPM měří i kód firmwaru. Přeprogramování firmwaru tedy neunikne pozornosti.

Vyvstává otázka, co kód, který měří firmware. Ten by měl být skutečně v nepřepsatelné paměti. Je to ten kód, který startuje procesor a zavádí firmware, když ještě není nakonfigurovaná fyzická paměť. Kdysi tomu tak skutečně bylo. Nicméně jak je tohle implementované na dnešním překomplikovaném hardwaru, těžko říci. Poslední procesory implementují TPM samy, protože jej emulují v servisním procesoru velkého CPU (na Intelu to je nějaký ARM).

[petr_p]

TPM se sám magicky neresetuje. Ale správně implementované TPM měří i konfiguraci firwmaru. Respektive tu část, která má vliv na vykonávaný kód, což prakticky nemusí být žádná část konfigurace (pokud je člověku jedno, že ten samý kernel se načte z jiného zařízení než obvykle). Technicky vzato, že si útočník prohlédne nastavení firmwaru nebo změní jeho jazykové rozhraní na japonštinu, nijak neovlivňuje intergritu nabootovaného systému.