Mash enter HDD crypto bypass - TPM & LUKS & clevis & drakut & systemd

Linux-security

https://pulsesecurity.co.nz/advisories/tpm-luks-bypass

https://www.reddit.com/r/devuan/comments/16b170s/mash_enter_to_break_en…

  • 811 megtekintés

( zrubi v | 2023. 09. 06., sze – 10:31 )

Úgy tűnik ez a régi IT security 'végkövetkeztetés', csak nem akar megdőlni ;)

physical access = root.

zrubi.hu

Így van. Én mindig fejben tárolom a jelszót (jó a mesterjelszót az offline password manageremhez, ami saját megoldás), gépeknél mindenképpen a jelszót is. Nincs lementve TPM-be, sem felírva valami cetlire, se pendrive-ra kiírva. Ha elfelejtem, akkor bukta, nincs hack, oda az adatoknak. Vagyis van mindenről biztonsági másolat, de az LUKS XTS AES256, jelszó nincs hozzá leírva. Nem Bitlocker meg egyéb ellenőrizhetetlen megoldás.

Igen, kényelmetlen, hogy minden gépindításkor be kell körmölni egy hosszú jelszót (ATA jelszót, vagy LUKS, épp milyen gépről van/volt szó az évek során), de 1) tudok gépírni, 2) megszoktam, már fel sem tűnik. Sőt, a jelenlegi gépemen az NVMe sedutil hardveres titkosítás úgy működik, hogy újraindításkor nem kér jelszót, csak áramtalanítás után. Bár beállítható lenne, hogy mindig kérjen, vagy akár még azt is be lehetne állítani, hogy dektop zárolásakor, képernyőkímélő bekapcsolásakor is zárjon le, és kérje be újra. Ez a sedutil egy CLI linuxos megoldás, szinte bármit lehet rajta reszelni egy egyszerű scripttel. Bár az ATA jelszót jobban szerettem, egyszerűbb, az UEFI/BIOS gondoskodik róla, nem kell hack az initramfs-be, meg stb., de az ATA jelszó csak SATA HDD/SSD-nél, meg M.2 SATA/AHCI SSD-nél játszik csak sajnos. M.2 NVMe-nél nincs ilyen.

“Windows 95/98: 32 bit extension and a graphical shell for a 16 bit patch to an 8 bit operating system originally coded for a 4 bit microprocessor, written by a 2 bit company that can't stand 1 bit of competition.”

Nem lehet. Ez ezeknek a titkosításoknak a lényege, hogy nincs kerülő, meg hátsó kiskapu, alapból nem tárolja el kulcsot. Vagy megvan a kulcs, jelszó, vagy buktad az adatokat. Bár az is számít, hogy milyen kulcsot használtál LUKS-hoz, TPM-be mentettet, valami külső drive-ra írtat, vagy begépelős jelszót?

Ez egyébként a te érdeked szolgálja. Ha lenne valami kerülő megoldás rá, akkor akárki ki tudná játszani, és az egész titkosítás az értelmét vesztené, csak színjáték lenne, és nem lenne a titkosított adat biztonságban. Ha nem volt túl komplikált, túl hosszú jelszó, akkor valami bruteforce megoldás játszhat.

Ezért kell egyébként jelszókezelő, password manager programot használni. Akkor csak annak az adatbázisnak a jelszavát kell megjegyezni, és abban benne lehet akkor minden egyéb jelszó, amit ki tudsz nézni, ha elfelejtenéd. Ezt anno én se használtam, de az évek során beadtam a derekam. LUKS jelszót még nem felejtettem el, de webes szolgáltatások mobilon, út közben használva már komolyan megszivattak.

“Windows 95/98: 32 bit extension and a graphical shell for a 16 bit patch to an 8 bit operating system originally coded for a 4 bit microprocessor, written by a 2 bit company that can't stand 1 bit of competition.”

Köszi, válaszod után  másik rendszerről mountolva  végig próbálgattam emlékezetből jópár jelszót, és meglett.

 

Ha lenne valami kerülő megoldás rá, akkor akárki ki tudná játszani, és az egész titkosítás az értelmét vesztené, csak színjáték lenne, és nem lenne a titkosított adat biztonságban

 

Én is így gondolom, csak azt olvastam régebben, valahol - boot könyvtár/partício - eltárol valamit titkosítatlanul. Ezek szerint nincs ilyen.

Password manager programot használok, csak oda direkt nem írtam be ezt a jelszót.

"boot könyvtár/partício - eltárol valamit titkosítatlanul. Ezek szerint nincs ilyen."

Van, lehetett ilyesmit csinálni, csak erősen antipattern. Pontosabban valahogy úgy volt a megoldás, hogy a /boot titkosítva van, grub jelszóval oldod fel, majd a fő LUKS partíció kulcsa - hogy ne kelljen a / mountolása előtt külön mégegyszer jelszót beírni - rajta volt a /boot-on. Vagyis titkosítva van az, de csak amikor a gép áll. A már feloldott gépről meg lehet szerezni plaintextben. (Soha eszembe nem jutott így csinálni, engem is meglepett, hogy ez egy gyakorlatban használt megoldás volt.)

Régóta vágyok én, az androidok mezonkincsére már!

Alapvetoen nem, kiveve ha le van rakva a pancelba egy lezart boritekban a jelszo.

Valamint ha elkezdenek tuket szurkalni a kormod ala, az ellen sem ved.

Ennek a titkositasnak osszesen az a celja, hogy ha ellopjak a laptopot a vonaton, akkor csak a vas ara vesszen el, az par szazezer forint, es ne a rajta levo info, ami nagysagrendekkel jobban fajhat. Ezt a feladatat tokeletesen teljesiti, kiveve ha TPM-ben hagyod a kulcsot es a tamado az adatokra palyazik, es nem a vaterara akarja feltenni a vasat.

Nyilván az ellen semmi nem véd, ha a körmöd alá szurkálnak, meg élére fordított lapáttal ütnek. A széf egy köztes megoldás, bár szerintem nem olyan biztonságos, mint fejben tartani, de még nem is annyira gyenge, mint a monitorra kiragasztás, meg a fiókba a pendrive, és az ujjlenyomat-olvasó.

Igen, ha valaki a fel nem írt jelszót elfelejti, vagy sztrókot kap, akkor bukta. Ezt ennek tudatában kell mérlegelni, a titkosítás felelősséggel és kényelmetlenséggel jár, ez az ára a biztonságnak.

Ha ezt így ki lehetne magyarázni, hogy sztrók esetére oké, akkor menne a többi kifogás is kibúvóra, hogy mikor lehet a beépített hátsó kaput használni. Ha nincs kibúvó, nincs magyarázkodás, teljes a biztonság.

Nálam egyébként a titkosításnak a célja, hogy ne csak lopás ellen védjen, hanem bármilyen szitjuban az adataim. Persze, lopás ellen is véd, természetesen. Az ellen talán a TPM is jó.

“Windows 95/98: 32 bit extension and a graphical shell for a 16 bit patch to an 8 bit operating system originally coded for a 4 bit microprocessor, written by a 2 bit company that can't stand 1 bit of competition.”

Amúgy a mostani hibát pofonegyszerű kijavítani:

"rd.shell=0 rd.emergency=reboot" a kernel commandline-ba, és máris nincs fallback root useres initramfs promptra.

Mert ugye itt ez a baj, hogy van egy régi feltételezés, hogy az initramfs promptban autentikáció nélkül root usert adni "nem veszélyes", mert az igazi adatokat tartalmazó partició titkosítása nincs feloldva. Viszont ha a kulcs TPM-ben ott van, akkor mégiscsak veszélyes lesz. Egyszerűen nem gondoltak rá, hogy a korábbi feltételezés már nem áll meg.

Régóta vágyok én, az androidok mezonkincsére már!

Ez ellen vannak ezek a "measured PCR" vagy miafenék. Elvileg a TPM akkor adja csak ki a kulcsot, ha a grub, a kernel, az initramfs és a kernel commandline előtte össze volt bind-olva a TPM-mel. (Sose használtam, elég felületes a tudásom róla.)

Én azon gondolkodtam, milyen frankó unrecoverable módon ki tudod zárni magadat ezzel, ha bármi hiba miatt nem bootol a rendszer és nincs jelszavad a luks-hoz.

Régóta vágyok én, az androidok mezonkincsére már!

Én pontosan ezért preferálom a jó öreg jelszógépelést. Kényelmetlen, de megszokható, a kényelem amúgy is a biztonsággal ellentétes igény. A TPM-mel csak a gond van, meg a kulcs bekészítése a lábtörlő alá. Ugyanez a véleményem a külső meghajtón tárolt kulcsfájlról, meg az ujjlenyomat-olvasókról, Hello arcfelismerésről, stb..

“Windows 95/98: 32 bit extension and a graphical shell for a 16 bit patch to an 8 bit operating system originally coded for a 4 bit microprocessor, written by a 2 bit company that can't stand 1 bit of competition.”