T450+Debian+LUKS+TPM működhet?

Linux-security

Adott egy Thinkpad T450 Debian Jessie-vel, amin backportolt 4.5-ös kernel szaladgál, egy LUKS-által titkosított LVM diszkről (a /boot és a /boot/efi nincs titkosítva). Ehhez gondoltam hozzápasszítani a gépben lévő TPM-chipet, amit a LUKS-kulcs tárolására használnék, ha ez megoldható.

TPM-el tapasztalatom az viszont nincs és amit gyors kereséssel találtam az sem tette egyértelműbbé a helyzetet. A leginkább használhatónak tűnő megoldást talán ez jelentette: https://github.com/shpedoikal/tpm-luks de ez is több, mint 3 éves és RHEL-re készült. Annyi biztos, hogy bizonyos dolgok máshogy mennek Debian alatt. Szóval valaki, aki próbálkozott már ilyennel megosztaná a tapasztalatait? Egyáltalán működhet ez így, vagy ne kaparjak miatta?

  • 7218 megtekintés

( vl v | 2016. 05. 17., k – 22:18 )

Mi a célod? Mit szeretnél elérni?

Azt leszögezhetjük, hogy LUKS esetén olyan, hogy a titkosításhoz használatos kulcsot a géped úgy tárolja, hogy azt onnan sehogyse lehessen kilopni, nem létezik. Ugyanis ahhoz az kellene, hogy HW végezze a CPU helyett a diszk titkosítását (ergó a kulcs sose kerüljön a CPU-hoz, a HW-en belül maradjon), márpedig a LUKS nem így működik.

Tudom, hogy nem így működik. A terv minden elméleti fejtegetést mellőzve, hogy a rendszer indulásakor a LUKS a feloldáshoz szükséges kulcsot a TPM-től megkapja, ehhez ha jól olvasom, akkor szükség lesz egy olyan bootloaderre is, ami támogatja a Trusted Boot-ot (TrustedGRUB, TrustedGRUB2).

A CPU trusted bootnál el tudja küldeni az épp betöltött kód (bootloader, kernel, stb.) hash-ét a TPM-nek, amit ő hozzáhash-el egy belső regiszterének (PCR) értékéhez, így a végén a regiszterek értéke jellemző lesz a boot chainre. A TPM-nek így megmondhatod, hogy a titkosított adatokat csak a PCR-ek egy adott értékénél fejtse vissza (ez a sealing). Lényegében a TPM azt tudja, hogy akkor fejti vissza a pl. lemeztitkosító kulcsot, ha a BIOS/bootloader/kernel megegyezik azzal, amivel seal-elted. Vagyis nem csak a titkosítási kulcsot védené, hanem azt is megakadályozná, hogy külső médiáról bootoljon a rendszer.

A fenti folyamathoz erősen ajánlott PIN hozzáadása, de jelen állapotában nem hiszem, hogy a PIN+TPM menni fog linux alatt. A fenti link alatti megoldás egy frissebb forkja itt: https://github.com/momiji/tpm-luks

Egyelőre nem sok mindent tudok viszont felmutatni, egyrészt át kellene nézni a fenti kódot, adaptálható-e debian-ra, valamint több tapasztalat kellene TrustedGRUB-al is...

Hát, majd számolj be, ha sikerült eredményre jutni :D

Igazából a use-case-t nem teljesen értem.

Ha a kulcs benne van a TPM-ben, akkor az a cél, hogy a titkos jelszó/passphrase ismerete nélkül is elindulhasson a gép?
Nálam laptopnál pont az lenne a cél, hogy nélkülem (a jelszó ismerete nélkül) ne lehessen hozzáférni se a géphez, se az adatokhoz. Ezt viszont el lehet érni úgy, hogy a LUKS jelszót a gép magától nem tudja (így még véletlenül sem fordulhat elő, hogy kinyerik belőle valahogy), tehát a TPM-nek elég annyit tudnia, hogy ne lehessen trójaira cserélni a boot loadert/kernelt/initramfst.

Ha a kulcs benne van a TPM-ben, akkor az a cél, hogy a titkos jelszó/passphrase ismerete nélkül is elindulhasson a gép?
Igen PIN nélkül a működése ez lenne. Nyilván az igazán jó megoldás az lenne, ha PIN-t is adhatnánk meg.

A use-case-ről csak annyit, van olyan eset, amikor nem garantálható a jelenlétem a gép indulásakor (wake-on lan, stb), és ekkor is szükséges lenne, hogy elinduljon. Most tekintsünk el attól az esettől hogy a PIN-t ekkor is meg kellene adnom (mert az egyébként a titkosítási kulcstól függetlenül cserélhető, legalábbis Windows-on).

TPM nélkül, tehetem a kulcsot titkosítatlan partícióra, pendrive-ra, memóriakártyára is, viszont ezekről nagyon könnyen megszerezhető a kulcs, illetve könnyen elveszthető az adathordozó. Nem állítom, hogy a TPM mennyivel jobb megoldás, de vannak előnyei.

Nem létfontosságú ez a funkció, csak hasznosnak gondoltam végigpróbálni a lehetőségeit. De valamiért az az érzésem, hogy ezt a technológiát az UEFI Secure Boot-al egy kaptafára tűzzel-vassal irtják a open source világban...

Erre a usecase-re van egy ötletem, mégpedig egy nem titkosított rendszer és egy titkosított adat partíció/container. A luks kötetnek megadsz egy keyfile-t _is_ (ha jól emlékszem 8 slot van), és ezt "elrejted" valahova, célszerűen több részletben több helyre.
Pl. egy webserver-en egy 234rewjofsdö9275zt8gbjdsdé nevű file ami csak https-en érhető el, vagy egy publikusan elérhető kép (flicker, picasa, stb.) 1532. byte-jától kezdve 1725 byte, de lehet a kulcs része pl. a default gw (ottoni nat-olós dobozod) mac address-e is, ilyesmi. Ezek letöltését (és ha szükséges összeállítását) boot után egy memdisk-en kényelmesen elvégezheted, majd a titkosított volume felcsatolása után ennek a tartalmát törlöd.

Hátránya ennek a módszernek, hogy az egész disk titkosítása nem lehetséges, viszont az "érzékeny" adatok titkosítva lesznek és a jelszó vagy a teljes kulcs kell a hozzáféréshez. Nyilván ott van a "megfejtés" a vinyón, de ha pl. ellopják a notit akkor valszeg nem az lesz az első dolguk, hogy átnyálazzák hogy rc.local-ból indított jól eldugott kis script-edet, ami érdemi munkát csak akkor végez ha az otthoni LAN körülményeit tapasztalja. Szóval ilyen esetben simán van időd megsemmisíteni a kulcsot, vagy annak legalább egy részét.

Persze ha kifejezetten rád utaznak az ellen nem véd, érzékeny céges adatokat se feltétlenül tárolnék így, de a "random tolvaj hozzáfér a home video-imhoz" kategóriában akár megfelelő is lehet.