Názory k článku Vzdálené odemykání šifrovaného disku na serveru s Debianem

"...Při startu se šifrovaná část připojí díky obsahu souboru /etc/crypttab..."

Jak je mozne precist obsah souboru /etc/crypttab (kterej je na zasifrovane casti disku) jeste driv, nez se zasifrovana cast disku pripoji?

Ak správne pamätám, /etc/crypttab je skopírovany pri generovani initramfs, tj nie je citany priamo /etc/crypttab na šifrovanom / ale kópia ktorá je v initramfs súbore na nesifrovanom /boot.

Opravte ma ak sa mýlim

Trochu problém vydím v tom, že až selžou záložní baterie a motorgenerátory, nebo se prostě stroj restartuje chybou hardwaru nebo lidskou chybou (např. chybou zaměstnanců datacentra) v nečekanou dobu, způsobíte se pravděpodobně místo krátkého výpadku v řádu minut výpadek dlouhý v řádu hodin, což především pro aplikace 24/7 není moc dobré. Ono se to určitě někdy stane, otázka jen je, jestli za rok, nebo za deset let. Dva zdroje ze dvou větví napájení, může pravděpodobnost snížit na polovinu.

V případě serveru bývají pro data (spíš pro kontejnery s virtuály) jiné disky než pro oparační systém, není tak problém šifrování použít jen na ty přídavné disky, život se tím zjednodušší především v příadě řešení potíží s bootováním. Na základním hostilským systému bez dat není nic tajného.a není třeba jej chránit.

"Na základním hostilským systému bez dat není nic tajného.a není třeba jej chránit."

Okrem šifrovacích kľúčov na šifrované disky. Pane bože prečo ešte aj s tadeto dali preč ten dislike button...

Tak ty klíče samozřejmě můžou být chráněny heslem. Není třeba kvůli 2 souborů šifrovat celý OS, po bootu se připojím na ssh a prostě si ty další disky odemknu.

Tady posílám hezkou písničku :-) https://www.youtube.com/watch?v=yxiQmTMT5Zs

Takže buď dáš klíče na tu nešifrovanou část, protože bez dat to stejně nenaběhne a nebo je nějak ochráníš a si tam kde si byl, jen s tím rozdílem, že máš nešifrovaný systém.

SSHčko v initrd při řešení potíží spíše pomůže než naopak.

Já tu obavu s nedostupností chápu, ale tak přece máme nástroje, co jsou schopny tenhle stav nadetekovat a to heslo tam poslat. Nebudu otevírat celý systém a modlit se, aby tam někdo něco citlivého neuložil, jen kvůli tomu, že při bootu to vyžaduje heslo.

Tím jste ale uvedený problém nevyřešil. Pořád budete muset zadávat heslo k těm diskům s kontejnery nebo obsahujícím jiná data, a bez zadání toho hesla systém nebude poskytovat ty služby, které má poskytovat v režimu 24/7.

Jenze pokud nabehne kompletni system, uz je mozne trebas poslat vam na smartfoun spravu ze server byl restartovan a ceka na heslo pro pripojeni disku kde ma data...

Ano, porad budete zadavat heslo, ale nebude to jiz jen o tom, kdy si konecne vsimnete, ze naka sluzba nefunguje (nebo se zacnou ozyvat uzivatele), a ze tedy server asi ceka.

To nemáš žádný monitoring, že server musí sám prosit, aby ho někdo odemknul? Na takové řešení se nedá vůbec spolehnout.

Proč by tu SMS nemohl poslat inicializační systém běžící z ramdisku? Síť tam je nakonfigurovaná a odeslání SMS může být jedno zavolání curl.

Může. Ale pokud by stav stroje sledoval někdo od jinud, pozná i jiné z zakázané stavy jako kousnutí nebo odpojení konektivity, nebo úplné selhání disku či bootování.

Ale server může odemykat klidně automatizovaně jiný server.

Pokud by jej někdo ukradl, nebude schopen jej dát na původní adresu aby došlo k odemčení. Tedy jediný způsob jak by se do něj někdo mohl dostat je vypnout ho, dát si tam nějaká zadní vrátka a pak jej zapnout, aby došlo k odemčení. Tohle ale hrozí i při ručním odemykání.
Vždy by ale může tam dát nástrahu, aby jste si mysleli, že odemykáte server vy ale místo toho vyzradíte heslo útočníkovi. Vše potřebné tam najde nezašifrované.

8. 12. 2021, 13:56 editováno autorem komentáře

Pokud by jej někdo ukradl, nebude schopen jej dát na původní adresu aby došlo k odemčení.
Řekl bych, že šifrování disků na vzdáleném serveru se dělá především pro to, aby se k datům nedostal provozovatel datového centra nebo někdo s jeho pomocí. Tudíž váš předpoklad není splněn.

Vždy by ale může tam dát nástrahu, aby jste si mysleli, že odemykáte server vy ale místo toho vyzradíte heslo útočníkovi. Vše potřebné tam najde nezašifrované.
Jistě. Ale přeci jen je rozdíl, zda jste server vědomě restartoval a teď po vás chce heslo, nebo zda víte, že vypadlo napájení a teď po vás server chce heslo – a nebo jestli váš server ochotně vyžvaní heslo hned, jak si o něj někdo řekne.

Čímž neříkám, že vzdálené automatické odemykání nemá žádný význam. Pokud se chci chránit před chybou nebo nedbalostí, třeba že někdo po výměně HDD nezajistí bezpečné smazání dat, je to odpovídající zabezpečení. Proti útočníkovi v datovém centru to ale nestačí.

Pokud se to ale restartuje či jakoby kousne samo, nevíte jestli to byl omyl, naschvál, záměr či porucha napájení, nebo jen obyčejná nestability hardware. Útočník může předstírat, že se vám server kousnul a vy si ho ještě restartujete na dálku sám. A heslo tam také dáte, aby jste nezdržoval. Všechny tyto jevy budou rozhodně častější, než že by se někdo fakt snažil vykrást ty data.

> Ale server může odemykat klidně automatizovaně jiný server.

Ano, stejně jako odemykání rootfs z ramdisku. echo heslo | ssh ramdisk cryptroot-unlock

Možná jsem hloupatej, ale k čemu že je dobrý zamknout si na ulici k lampě kolo zámkem, kterým si ke kolu přivážete i klíče?

Ani zmínka o šifrování boot partition? Možnosti bootloaderu takovou partition připojit. Cely disk se da šifrovat jen když mate ESP nešifrovaně někde jinde

Zmínka o kompletně šifrovaném disku je hned v prvním odstavci a je tam odkaz na článek, který to celé podrobně popisuje. Já to tak používám na desktopu. Ovšem není to kompatibilní se vzdáleným odemykáním, protože Grub neobsahuje SSH server.

Grub by mel podporovat ovladani pres serial, ale pred casem kdyz sem s tim laboroval se mi to kompletne zprovoznit nepodarilo :-)

Nicmene misto Grub pouzivam Sicherboot - ten zabali jadro + initramdisk do EFi binarny na EFI oddil, podepise vlasnima(=mejma) klicema, s tim ze na desce v EFI jsou pouze tyhle (nikoliv ty puvodni a microsofti) klice...
oddil /boot pak je sifrovanej, deska jine nez me EFI binarky nenatahne, a odemykam vzdalene pred dropbear...

varianta co mas s Grub nesifrovanej /boot kde je initramdisk lze snadno utocnikem zamenit za initramdisk s keylogerem ;-)

Tohle jsem zkousel rozbehat nekolikrat, ale neuspesne. Nebyl by podrobnejsi navod?
Navic pokud se nemejlim, tak tohle je principielne nekopatibilni s dual bootem. Protoze to vyuziva secure boot EFI a tam neni mozne mit MS klice pro win a vlastni pro linux zaroven.

@Jiri Dobry
trochu neucesane a je potreba cist i ty veci pod tim co doplnujou/opra­vujou, ale pred casem sem to psal tady:
https://www.abclinuxu.cz/poradna/linux/show/447760#48

To záleží, jak moc jste paranoidní. Já mám jak svůj počítač tak domácí server zašiforvaný, ale s nešifrovaným boot oddílem. Evil maid attack na moji osobu nepředpokládám - zase v tak závažných kšeftech nejedu.

Zdravim Petře,
ten odkazovaný článek je více jak 2 roky starý a postup šel replikovat jen na Debian 9. Už od Debian 10 (a např. *buntu odvozeninách) nebyl postup v článku aplikovatelný - tzn. cca 7 měsíců od článku.
Důvod byl zřejmě LUKS2 a jeho nepodpora v GRUBu. Proto s Debian 10/11 musel být /boot buď nešifrovaný nebo šifrované oddíly musely být LUKS1.
Nyní už je v (unstable větvi) Debianu Grub 2.06 který LUKS2 podporuje.
Až se dostane alespoň do testing větve Debianu (v řádu dní?) resp. *buntu 22.04, plánujete udělat aktualizaci odkazovaného článku?

kdyz si do authorized_keys na zacatek napisete:
command="/bin/cryp­troot-unlock"

tak je to jeste o trosku pohodlnejsi :)

Když se mluví o serveru, tak by se měla zmínit i řešení přes remote server management. HP ProLiant servery měly (a teď volitelně mají) vestavěné Integrated Lights-Out (iLO). To jsem používal. IBM a Dell mají něco podobného, ale jmenuje se to jinak. Prodávají se i PCI karty, které remote server management umí. V podstatě je to minipočítač s vlastním Ethernetovým portem a IP adresou, který umí se serverem manipulovat. Administrátoři, kteří s rack-mounted servery pracují, tuto technologii většinou znají. Kdo to nezná, tak se může podívat třeba na video New iLO 5 for ProLiant Gen10 demo, https://youtu.be/_rRdEekFgVA .

Při použití tohoto řešení není třeba zprovozňovat sshd pro zadání klíčů při bootování.

Je to tak, pak ovšem platí první článek, protože vlastně nejde o dálkové odemknutí po síti, ale lokální odemknutí přes KVM.

pokud už mám proliant, není jednoduší pořídit smartArray (pokud ho ještě nemám) a nešifrovat transparentně přes něj?

Asi ano.

Já to neřeším, protože šifrovat disk nepotřebuji. Navíc můj obstarožní ProLiant server má SmartArray P400 (pokud se nepletu), který to šifrování nepodporuje. HW podpora od HP mi skončila před lety, a tak jsem iLO radši odpojil sítě. Žádný expert na současná řešení nejsem.

Není, protože jednak nikdo nemůže věřit proprietárnímu neauditovatelnému šifrování, a jednak bude příšerné disaster recovery (nestačí disky přeskládat do libovolného jiného počítače; nelze udělat ekvivalent LUKS header backup a master key file -- takhle jsem už jednou osobně přišel o data)

Cituji: "Není, protože jednak nikdo nemůže věřit proprietárnímu neauditovatelnému šifrování".

Když se to napíše takhle, tak je to zavádějící. Pokud vím, tak některé instituce v USA vyžadují, aby šifrovací řešení splňovalo nějaká kritéria. To HP řešení je splňuje (předpokládám, že prošlo nějakým auditem), a proto je pro ty zákazníky přijatelné.

To samozřejmě neříká nic o tom, jestli jsou tam zadní vrátka od NSA nebo zda by to prošlo přísnějšími kritérii třeba pro přísně utajovaná data.

Souhlasím s tím, že si nemůžete udělat bezpečnostní audit, ale otázka je, jaké požadavky na bezpečnost dat mají zákazníci v praxi. Řekl bych, že větší část se spokojí se splněním nějakého bezpečnostního standardu.

HP uvádí:
HPE Smart Array Secure Encryption is designed to meet NIST-approved standards. By example, HPE Smart Array Secure Encryption utilizes the XTS AES 256 bit algorithm for data encryption specified by NIST. The HPE Smart Array Px3x and Px4x family of controllers have completed FIPS 140-2 Level 1 validation, Certificate #2506 (Px4x).

HPE Smart Array Secure Encryption enables enterprises to comply with the data privacy and protection requirements associated with the U.S. Health Insurance Portability and Accountability Act (HIPAA) and the Sarbanes-Oxley Act.

Jinak to HIPAA vyžaduje, aby zdravotní informace byly zabezpečené. Takže HP si nemůže dovolit to HW řešení neudržovat. Kdyby se objevila bezpečnostní díra, musí ji odstranit. Asi to bude dělat jen po dobu HW podpory, což může být velká nevýhoda.

> To samozřejmě neříká nic o tom, jestli jsou tam zadní vrátka od NSA nebo zda by to prošlo přísnějšími kritérii třeba pro přísně utajovaná data.

Nejde o zadní vrátka pro NSA (i když, proč ne), ale o všemožné průšvihy, které jsme viděli - nejčastěji je tím postižen RNG, hardwarové generátory měly chyby (slovenské a estonské občanky; někdy úmyslné - "Dual EC DRBG"), případně byl při implementaci neuvěřitelný diletantismus (1, 2, 3, 4, atd., od renomovaných výrobců a některé i různými způsoby certifikované).

> Kdyby se objevila bezpečnostní díra, musí ji odstranit.

To je k ničemu když zloděj už má ty disky ukradené a zkopírované a updaty instalovat nebude.

> Při použití tohoto řešení není třeba zprovozňovat sshd pro zadání klíčů při bootování.

Pokud používáte HTML5 videokonzoli, tak to bude strašný opruz dělat a musí se to ručně přes prohlížeč. Pokud používáte sériák a ten to umí někam bezpečně vystrčit a dokážete si nastavit autentizaci (podobně jako v ramdisku máte SSH host keys) a jde to naskriptovat, tak jo, ale přijde mi to také relativně složité, nepřenositelné se systémem a tak to moc výhod nepřináší.

Jeste by se sluselo doplnit, ze mezi openssh a dropbearem jde pomoci dropbearconvert klice zkonvertovat.

U jedneho zakaznika sifrujeme iba datove disky. Na rozsifrovanie sa pouziva USB kluc, ktory musia po restarte systemu dat do USB s privatnym klucom.

Je tam UDEV pravidlo, kde sa USB kluc pripoji, odsifruje sa disk, odpoji a pustia sa sluzby.

Toto sa neda praktizovat pokial to nie je on premise.

Pri tomto setupe treba riesit problem s SSH klucmi.
Bud je jeden zdielany, co je pre niekhoko bezpecnostny problem.
Alebo ma tam kazdy vlastny, potom treba riesit managment pri fluktuacii zamestnancov.

Kazdy sposob ma svoje vyhody a problemy, zalezi na nastaveni bezpecnosti. Predpokladam, ze SSH CA dropbear nevie, co by riesilo vsetky problemy.

Linuxy jsou v tomhle tezce pozadu. Staci porovnat schopnosti Bitlockeru v kombinaci s AD. Napr. Windows muzu zapnout/vypnou­t/pozastavit sifrovani podle potreby. Linux to potrebuje mit dopredu a pak je to staticky setup se slozitejsi administraci pri zmene.

Jinak clanek resi server, ale tak strasne teoreticky. Zapomina na rozdil mezi fyzickym a virtualnim serverem.

Kde to resi, jak je ten server vubec pripojeny k siti? Umi to zminovane reseni LACP, vlan atd.? Dnes typicky server casto neni pripojeny pouze k jedne vlan.

Nebo treba, pokud server neni na dhcp, kde je vztah initramfs vuci konfiguraci site?

Jinak treba zrovna HP od urcitych typu ma radice s moznosti HW sifrovani. A odemykani techto radicu lze bud lokalne (popr. pres ILO), nebo automaticky po siti pres vzdaleny controller.

Nejaka cast clanku Ti asi usla - ta, kde sa riesi nastavenie siete mimo DHCP.

Vyhoda tohto rieseina oproti Win/AD/BitL je ta, ze na odsifrovanie Ti staci ten kluc, da sa to tiez automatizovat a funguje to aj ked klakne AD. A napr. mozes na tom prevadzkovat takuto sluzbu (AD ekvivalent) bez toho, aby si mal kruhovu zavislost.

A zautomatizujete to jak?

Uz z toho popisu je videt, kolik extra kroku je potreba jen pro blbe zprozovneni toho sifrovani. Udrzovat tohle v ansible/puppet atd musi byt vyzivne.

A to sitovani je kriticke, k cemu mi bude, ze budu mit staticky nastavenou IP, kdyz ten server bude pripojeny pres LACP, ale ten sifrovaci modul nebude umet takovou sit nastavit?

> A zautomatizujete to jak?

Shell skriptem? :-)

> Uz z toho popisu je videt, kolik extra kroku je potreba jen pro blbe zprozovneni toho sifrovani.

Článek je extrémně detailní (to není výtka, je tak přístupný i lidem, co nejsou na problematiku experti).

> ale ten sifrovaci modul nebude umet takovou sit nastavit?

V tom initramdisku je busybox (a dá se tam dát i libovolná jiná utilita, ale je pak dost velký) a dá se tam dát custom skript, takže se dá nastavit úplně cokoli.

> Staci porovnat schopnosti Bitlockeru v kombinaci s AD.

Já tomu teda nerozumím, ale BitLocker mám spojený s tím, jak to natáhlo klíč z TPM a automaticky ho to nešifrovaný zapsalo do RAM.

> Napr. Windows muzu zapnout/vypnou­t/pozastavit sifrovani podle potreby.

Jak to funguje? Na Linuxu máme cryptsetup-reencrypt, který umí inplace zašifrovat či odšifrovat. Na Windows to myslím funguje tak, že se šifruje defaultně, ale pokud je šifrování „vypnuté“, tak se klíč automaticky nahrává při bootu bez hesla (z toho nešťastného TPM). To je ekvivalentní tomu mít Linux se šifrovaným diskem a vypínání/zapínání šifrování dělat tak, že se do initramdisku přidá keyfile.

> Umi to zminovane reseni LACP, vlan atd.? Nebo treba, pokud server neni na dhcp, kde je vztah initramfs vuci konfiguraci site?

LACP nevím co je :), VLAN to samozřejmě umí, je tam normální busybox s jeho implementací ip. DHCP se řeší v článku, doslova je tam napsáno "IP=192.168.2­.19::192.168.2­.254:255.255.255­.0:debian".

> Jinak treba zrovna HP od urcitych typu ma radice s moznosti HW sifrovani.

Jak je auditované a jak dobrý je disaster recovery?

Ja pracuji s premisou, ze kazdy sifrovaci system pro sifrovani disku pri pristupu k temto disku ulozi klic v RAM. Takze jestli to tak dela TPM, veracrypt, luks a janevimcojeste, pro mne neni tak dulezity.

Dulezity je pro mne schopnost fungovat v cele infrastrukture.

Cryptsetup-reencrypt - pokud zastavim/vypnu sifrovani na disku ve windows, nemusim delat zadne zasahy do konfigurace ohledne nazvu disku. Plati to i pro toto? Protoze kdyz se kouknu na svou konfiguraci luks2, tak v /etc/crypttab je uvedeno toto:

<target name> <source device> ...

Cili operuji s 2 jmeny zarizeni.

LACP, resp. bonding, to byste snad mel znat ne?

Ohledne auditu...mate audit na busybox? dropbear? na ty ruzny scripty. atd.? Vazne tu chcete mavat slovickem audit?
Jinak precist si o tom muzete napr. https://support.hpe.com/hpesc/public/docDisplay?docId=c04200141&docLocale=en_US - (HP Secure Encryption).

@czechsys

ses si jistej ze server s napr. 4xLAN a v OS nastaven Bond + v Switch (dle zvoledeho rezimu) nastaven Bond... ze server nastartovanej v initramdisku s nastavenim pouze 1 z tech 4x LAN a to bez Bondu, ze nebude z LAN dosatupnej? nebo dotupnej bude, Switch ty 3x zbyle LAN bude ignorovat...

jinak samozrejme Bond zprovoznit v initramdisku pujde...

EDIT: k ":vypnuti" sifrovani LUKS, v tom tvem /etc/crypttab pises ze mas:
<target name> <source device> ...
a v tech "..." je prave dalsi "none" tedy ses vyzvan k napsani hesla...
pokud bys chtel sifrovani vypnout, misto none tam bude cesta k keyfile, takze se to pres nej odemkne samo...

EDIT2: to "vypnout" je v kontextu vejs samozrejme mysleno to ze nejsi pouze dotazan na heslo, dale je disk sifrovan, pochybuju ze Windows pri "vypnuti" sifrovani bude realne prepisovat celej disk desifrovanejma datama...

9. 12. 2021, 15:46 editováno autorem komentáře

Ad LACP - zalezi na switchi. U HP Procurve jsem se setkal s tim, ze to fungovalo i bez LACP, pokud neprisly dane pakety (prepinano pres active/passive). U jinych znacek se zase bez LACP konfigurace sit nespojila.

Ad vypnout - pokud vypnu bitlocker (zejmena skrz tpm), tak se disk jednoznacne desifruje. Jak jinak by pak fungoval v jinem stroji? Ze by byl stale castecne sifrovany a klic by byl ulozeny na disku misto v tpm? Jako primo jsem to neoveroval, ale kdyz jsem se zapinanim/vypinanim manipuloval, tak bylo vzdy potreba cekat (i desitky minut na ssd), nez dobehne dana operace.

> Takze jestli to tak dela TPM, veracrypt, luks a janevimcojeste, pro mne neni tak dulezity.

Je důležitý. LUKS/Veracrypt při standardním použití (notebook/desktop) vyžadují, aby byl u toho uživatel a zadal heslo. Při odemykání přes SSH vyžadují, aby se k adminovi nedoneslo, že před chvílí vykradli serverovnu, a že už to nedělá popáté, zatímco se server vždycky magicky restartuje.

TPM ho vydá kdykoli a kdekoli.

> nemusim delat zadne zasahy do konfigurace ohledne nazvu disku

Možná ani ne, pokud je systém na LVM, protože to to LVM s rootfs najde a tak se nemusí ptát na heslo. Ale možná se to při nalezení již neplatného řádku v crypttabu kousne, to nevím.

> Ohledne auditu...mate audit na busybox? dropbear? na ty ruzny scripty. atd.? Vazne tu chcete mavat slovickem audit?

No dobře, audit nebylo správně zvolené slovo, jde o to, aby bylo všem na očích například to, jak se generují klíče - tam jsou neustále nějaké chyby, kdy to má zásadně nižší entropii, kdy se jako klíč použije timestamp okamžiku prvního spuštění atd.

Mě by zajímala jednodušší a důležitější záležitost: Dá se k tomu dropboxu v serveru připojit přes link local IPv6 bez těch zbytečných onanií s DHCP?

Ani autor článku k tomu nemá co říci???

Pěkné.
A dá se to nějak řešit, když je na síti nasazen protocol 802.1X?

Chápem to správne, že ak vypnem uvedený server, tak som schopný z disku prečítať kľúč pre SSH Dropbear? Následne tento kľúč použiť na dešifrovanie komunikácie po SSH, kde klient posiela na SSH Dropbear heslo na dešifrovanie systémového disku?

Teda teoreticky by som musel to odchytené heslo pre odomknutie HDD poslať pomocou SSH kľúča klienta, ale bráni mi niečo pridať do servera nový SSH klúč (nového klienta)?

8. 12. 2021, 12:41 editováno autorem komentáře

Ne, veřejný klíč vám nijak nepomůže dostat se k obsahu komunikace. To by postrádala celá asymetrická kryptografie smysl, já mám veřejné klíče vystavené na volně dostupném web serveru. K šifrování obsahu komunikace se používá jednorázový symetrický klíč, který ale neputuje vůbec po síti, takže ho nelze zachytit (klíčová slova: Diffie–Hellman key exchange a forward secrecy).

Pokud máte přístup k obsahu toho disku po vypnutí, máte jednodušší možnosti: třeba injektovat do ramdisku vlastní kód, který vám to heslo prostě pošle (klíčová slova: evil maid attack). Tomu zabrání jen podepsání potřebných částí a jejich ověřování v UEFI secure boot. Pak to po modifikaci nenabootuje.

8. 12. 2021, 12:50 editováno autorem komentáře

Už je to dávno čo som si schému Diffie–Hellman pozeral, budem si to musieť naštudovať znova... Mal som za to, že čo sa privátnym kľúčom zašifruje, dá sa verejným dešifrovať a naopak.

Podpísanie samotného kódu a overovanie pomocou UEFI by problém teoreticky riešilo. Nie som si ale istý, či tento mechanizmus je nejako ošetrený napríklad proti výmene základnej dosky za takú, ktorá by sa na to overenie proste vykašlala a kód spustila aj tak...

> Ne, veřejný klíč vám nijak nepomůže dostat se k obsahu komunikace.

To je čistě technicky pravda, ale může udělat MITM - díky znalosti veřejného klíče se SSH nebude bránit, že se klíč protistrany změnil.

S řešením pomocí backdooru souhlasím, osobně bych to taky tak dělal, zejména protože jsem na SSH nepotkal žádný dobrý MITM program.

Možná se zeptám blbě, ale proč to řešit takto složitě, když přesně k tomuto bylo vynalezeno TPM, které umí fungovat zcela automaticky? Samozřejmě se může objevit server, který TPM nemá, ale v dnešní době mi to příjde už jako standard.

Podpora TPM je v Linuxu...vselijaka. Navic je virtualnich serveru to jeste zavisi na schopnostech hypervizoru...

Pomocí TPM to lze řešít také, ale IIUC tam je problém, že to řeší jen scénář, kdy útočník ukradne disky a chce je přečíst, ne scénář, kdy ukradne (nebo si vypůjčí) celý počítač.

Není u TPM háček v tom, že když z jakéhokoli důvodu dojde ke zničení konkrétního TPM čipu, tak se k datům už nikdy nedostanete?

Nedostaneš se ke klíči, který byl v tom zničeném TPM. Ale LUKS umí přidat více klíčů, takže máš jeden v TPM a jeden záložní někde. Nebo třeba ve firmě můžeš dát další klíč CEO nebo do notářské úschovy nebo whatever.

Rozuměl jsem tomu až po to „whatever“.

Nebo třeba ve firmě můžeš dát další klíč CEO nebo do notářské úschovy nebo komukoli jinému jak to zrovna situace a firemní politika bude vyžadovat.

Klic v TPM se zalohuje do AD apod., pokud jsou to Win. K tomu lze vytvorit recovery key, ktery lze mit jako soubor/papir dle libosti.

Problém s TPM je, že:

1) TPM „první generace“ (tak to teď označuju, žádné oficiální číslování AFAIK není) byly samostatné čipy na desce, které klíč sdělovaly přes „nešifrované dráty“, kde šel snadno odposlechnout.

2) Nové TPM se jmenuje „firmwarové“ a je přímo „v procesoru“, takže tam je tenhle útok extrémně složitý. Stále ale platí to, že klíč vydají vždy při bootu a pak se používá pro šifrování v RAM. Díky tomu má útočník neomezený počet pokusů na cold-boot útok. Dokonce může vyměnit RAM moduly za jiné, na kterých se cold-boot útok dělá snadněji (RAM moduly jsou identifikovány pomocí I2C flashky, která není nijak kryptograficky zabezpečena).

2.1) Pomocí AES-NI se dá nějak šifrovat aniž by se klíče dostaly do RAM, to by mohlo pomoct.

2.2) V extrémním případě si lze ale představit speciální RAM modul, který umožňuje útočníkovi modifikaci obsahu za běhu (koukal jsem na to a přijde mi že potřebujete součástku jménem "DDR4 bus switch", FPGA s DDR4 nebo počítač s corebootem kde se dá rejpat v rutinách na memory training - nevím jestli takové s DDR4 existují, někdo mi o nich říkal v roce 2014 myslím tady kdy DDR4 ještě nebylo) a tak si změní kód a vyčte to.

3) Finálním řešením jsou CPU s šifrovanou RAM, to umí některé nejnovější Intely a AMD, ale není to moc rozšířené.

Samozřejmě některé z útoků se dají provést pří vzdáleném SSH unlocku, evil maid může backdoornout initramdisk. Dobré řešení by bylo používat SSH unlock a současně TPM (klíč rozdělený na půlky třeba), to pak vyžaduje překonat tohle i tamto a to třeba může trvat dlouho a někdo si toho všimne a heslo pak nezadá.

8. 12. 2021, 21:16 editováno autorem komentáře

Pouzivame jine reseni, ktere stahuje klce pro disky ze site, z ruznych mist, ktera jsou ruzne omezena a vyzaduji spravnou identifikaci.

Behem let pouzivani uz jsme ale nekolikrat narazili na ruzne problemy. zpusobene systemd, ktery cryptab zmrvil a ignoruje nektere parametry, takze se to muselo predelat do initramfs, kde systemd neni, pak se obejvuji ruzne zmeny v nastavovani site, kde proste prirozenym vyvojem jaksi zmizi zpetna kompatibilita, coz casto zjistite az pri restartu a to je pozde, nebo nejaky nastroj se zacne chovat jinak (napr. ssh najednou uz neprijma nektere klice, wget z busyboxu prestane fungovat s https apod.).

Takze ano, reseni pres cryptab je OK, ale doporucuju mit jeste testovaci stroj, ktery zkusite rebootovat predtim nez rebootujete ten "produkcni"..

Moc dekuji za clanek,

minimalne ten popis jak dostat do ramdisku sshd pouziji, protoze dosud sem to delal polorucne :-D

U nositelneho zarizeni, kde je nebezpeci fyzickeho pristupu k HW velmi vysoke je sifrovani celeho disku dost zasadni stupen ochrany, ale u serveru, ktery idealne 24x7 bezi a je za mnoha barierami, nejak nevidim ten vektor utoku, proti kteremu se chranim. Myslite, ze ma tento zpusob sifrovani smysl i v profesionalnim DC, nebo to je skutecne spis pro servery v kancelari atp?

Predem dekuji za vase nazory a pohledy...

Před nějakou dobou tady proběhla zprávička (nebo možná článek) o tom, že se tohle dá řešit automatizovane přes vzdálené KMS. Myslím, že se používaly balíky tang+clevis..

Když už se tu mluví o ramdisku.

Na Debianech, které adminuju, narůstají initramdisky do absurdních mezí - a samozřejmě dropbear z článku tomu nepomáhá. To má třeba i ten efekt, že boot trvá dlouho, když GRUB není úplně rychlý ve čtení z disku. A taky update initramdisku trvá.

Můžou za to moduly. Defaultně to dává do initramdisku moduly úplně na všechen hardware - síťovky, řadiče… A to má v aktuálních kernelech desítky mega.

Otevřeme /etc/initramfs-tools/initram­fs.conf a napíšeme tam MODULES=dep. To při generování osahá HW jaké moduly jsou potřeba a jen ty přiloží.

Samozřejmě pak přijdete o možnost nabootovat na _výrazně_ jiném hardwaru pouhým přehozením disku, to byste museli nabootovat z live a initramdisk sestavit znovu.

Zeptam se - zna autor Clevis/Tang?

Stručné a výstižné. Jen mé bystré oko si všimlo, že v tom dlouhém výpisu instalace&setupu generování je vidět, že se generuje SHA-1. Zatímco Při připojení se kontroluje sha-256. To je nějak rozbité nebo chyba nebo různé implementace? (logicky se dá připojovat jinou implementací, když je to vzdáleně, Putty, openssh, další neznám)

No a k minulému dílu (šifrofání na desktopu) by mě zajímalo, dalo by se to zařídit u systémů, kde se initramfs nepoužívá?

Jen poznámky: v části u překopírování veřejných klíčů(`scp`) by se mohlo doplnit, že jde o (jen a pouze veřejné) klíče těch vzdálených "terminálů"/klientů které se hodlají připojovat... Experti ti to samozřejmě ví...

+ by se pro DROPBEAR_OPTIONS mohl přidat parametr command=cryptsetup-unlock , když už jsem si proklikal ty linkované odkazy na manuály.

Dobrý den, v CZ.NICu jsme problematiku vzdáleného odemykání disků řešili a doplnil bych článek o dva poznatky.

1) V případě, že máte na serveru více připojených síťových rozhraní, je potřeba specifikovat síťové rozhraní, na který se má adresa pro dropbear nastavit. To se v Debianu provádí v souboru "/etc/initram­fs_config/ini­tramfs.conf" volbou DEVICE (DEVICE=eth0). Samozřejmě je poté opět potřeba vytvořit ramdisk (update-initramfs).

2) Vhodné je určitě také zmínit, že dropbear měl svoje bezpečnostní problémy, kdy umožňoval útočníkům spustit libovolný kód. Je dobré mít tohle na zřeteli a zároveň udržovat systémy s dropbearem aktuální. https://www.cvedetails.com/vulnerability-list/vendor_id-15806/Dropbear-Ssh-Project.html