Názory k článku
Microsoft opravil zranitelnost YellowKey v BitLockeru

Ono je to účinné, jenom si to jaksi uživatel musí správně nastavit. Bez spolupráce uživatele nefunguje žádné bezpečnostní opatření.

Kdyby to byl backdoor, bude to nějak schované. Bude nutné zadat nějaké speciální heslo, spustit nějaký nedokumentovaný příkaz apod. Uvedený problém zjevně backdoor není.

> Ono je to účinné, jenom si to jaksi uživatel musí správně nastavit.

Nějaké tipy jak to správně nastavit? (představuji, že se při odemčení vezme tajemství z TPM, ale navíc se k němu ještě přimíchá to heslo, co uživatel zadal, a až tímto je zašifrovaný "master key" kterým se pak šifruje disk)

Dracut s LUKSem tohle umí. Druhá věc co se dá na Linuxu udělat je podepsat si kernel / EFI stub vlastním klíčem, nastavit secure boot tak aby bootoval jenom ty věci s vlastním klíčem a ten klíč v TPM envelopovat nastavením BIOSu. Potom, pokud v UEFI firmwaru není nějaká další díra, to odmítá bootovat cokoliv jiného než ten můj systém a pokud se ten secureboot vypne nebo přenastaví, tak už zase z TPM nevypadne klíč.

Jestli jsem to dobre pochopil, tak ta dira kterou tam MS ma ve WinRE, je jako kdyby jste meli v initrd monzost vyvolat bash prompt (single user mode, napr. u Gentoo kdyz delam initrd pres genkernel, tak se aktivuje takovej shell sam v pripade ze se nenajde realroot= jako pouzitelny device).

K uspesnemu reseni potrebujete 2 veci - jednak si podepsat spusteni jen duveryhodneho prostredi, a druhak v tom prostredi nesmite mit moznost vyvolat shell bez autentifikace, nebo moznost pustit jakykoliv prikaz.

Cely ten SB koncept root-of-trust pada na tom, ze cely retezec musi byt bezpecny - ale realne toho dosahnout nejde.

Osobne bych u SB napr. vyzadoval IOMMU. Ale takovou vec win tak dekadu+ co koketuji se SB ani nepodporoval.. takze cela ta saskarna je jedno velike faux pas.

25. 5. 2026, 12:18 editováno autorem komentáře

Nějaké tipy jak to správně nastavit?
Použít šifrování TPM+PIN.

"Použít šifrování TPM+PIN."

jisaku, uz minule ti vbylo opakovane receno, ze tohle vuibec nepomuze, protoze to vubec nefunguje jak by melo, takze nevim proc sem ten blabol cpes znova dokola.

Kdo chce bezpecnost, nesmi pouzivat absolutne nic od MS. Nikdy nikde a za zadnych okolnosti.

uz minule ti vbylo opakovane receno, ze tohle vuibec nepomuze, protoze to vubec nefunguje jak by melo
Je jedno, kolikrát se to zopakuje. Podstatné je, jestli je pro to nějaký důkaz – a v tomto případě jaksi jakýkoli důkaz chybí.

Problém je, že ono to alespoň z pohledu běžného uživatele moc nastavitelné není. Při zapnutí z GUI se to prostě nezeptá vůbec na nic a jediná vynucená akce je uložení recovery klíče. Ano, možná nějakou power shellovou magií a hrabáním se v registru a group politikách možná půjde docílit toho, že to třeba neuloží ten klíč do TPM, ale je to prostě zase klasická Microsoft way: v defaultním nastavení je to naprosto k ničemu, nikde to nevaruje, že je to naprosto k ničemu a člověk aby četl týden dokumentaci aby zjistil, jestli se to dá použít vůbec nějak normálně.

Chápu pointu že prostě Microsoft je špatný. Ale možná by bylo dobrý když se to snažíte podpořit rádoby objektivními argumenty si nejdřív něco o té chybě faktického přečíst . Hodně v tom děla i verze systému .

No z toho co jsem četl, tak verzí systému se liší akorát to, jestli na tom recovery médiu je ten bazmek, co mi dá do ruky administrátorský shell nebo ne. Fakt, že nějaké externí bootnuté médium dostane z TPM funkční dešifrovací klíč na disk, je prostě brutální designový fail a to se očividně děje ve všech verzích.

Fakt, že nějaké externí bootnuté médium dostane z TPM funkční dešifrovací klíč na disk, je prostě brutální designový fail a to se očividně děje ve všech verzích.
Jak byste si to představoval jinak v situaci, kdy si uživatel nenastavil žádné ověření pro přístup k TPM? Pokud bude vaše odpověď „vůbec nemá jít v TPM vytvořit klíč, pokud přístup není chráněn PINem“ – připadalo by vám lepší, když by spousta uživatelů neměla disk vůbec šifrovaný, než když je sice šifrovaný, ale klíč je uložen v TPM bez ochrany?

Jak jsem psal výše, ten klíč v TPM je chráněný obsahem těch PCR registrů, které se při ukládání vyberou. V nich jsou různé věci, třeba konfigurace toho co to bootuje. Na svém PC mám třeba v secure bootu vložený jen svůj klíč, kterým podepisuju svůj EFI stub (ve kterém je kernel a initrd) a klíč je chráněný konfigurací secure bootu => počítač v defaultním nastavení nenabootuje nic jiného než můj systém a pokud vypnu secure boot, abych mohl nabootovat jiné médium, tak nedostanu klíč z TPM. Takže možnosti jak to řešit tam rozhodně jsou a když navíc vezmu v úvahu, že Microsoft se zrovna rozhodně podílel na vzniku specifikací pro secure boot a TPM, tak mohli i tlačit na to, aby to mohlo fungovat bez zásahů uživatele a technologicky správně. Místo toho vytvořili zase další zpraseninu, kdy ty data fakticky vzato chráněná nejsou a zapnout je to dobré leda tak k tomu, aby se dalo auditorovi říct, že mají všichni šifrované disky.

Mne by ale zajímalo, jaké navrhujete praktické možnosti. Použitelné pro běžné uživatele. Kdyby výchozí nastavení počítače s Windows bylo, že tam nenabootuje nic jiného, než nainstalované Windows, a dokonce ani žádný záchranný režim, budou tady diskuse plné komentářů o tom, jak Microsoft hrozně bojuje proti Linuxu apod. Většině uživatelů by ty komentáře samozřejmě byly jedno, ale ten záchranný režim by jim už tak jedno nebyl.

Pokud chci nainstalovat něco jiného, stejně musím změnit boot konfiguraci. Takže by stačilo kdyby klíč byl envelopovaný tím. První nápad během asi 10 sekund co jsem nad tím přemýšlel. Že by uživatel někdy musel zadat ten recovery klíč, když to udělá kvůli něčemu jinému? To stejně běžně dělá, třeba zrovna ty Dell notebooky v rámci sys updatů občas updatnou i BIOS a pak se přesně tohle stane...

Ne nainstalovat něco jiného. Spustit záchranný systém z média. Pochybuju o tom, že domácí uživatelé běžně znají nějaký recovery klíč k Secure Bootu.

Pokud neznají recovery klíč k bitlockeru (ne k securebootu), tak o ty data stejně přijdou, protože jak jsem psal, po updatu BIOSu počítače, což u některých vendorů notebooků se děje automaticky, to stejně ten recovery klíč chce zadat, protože i na windows v tom defaultním nastavení to používá PCR registry, které se updatem BIOSu změní.

A ano, recovery medium, bootnuté z externího media, je přesně to, co by ten klíč z TPM na dešifrování prostě dostat nemělo, protože je to systémově úplně blbě pokud tohle jde. To fakt ty data potom šifrované být nemusí, protože je celkem očividné že tudy se k ním nějak dostat půjde.

Hm, tak to zkusíme aplikovat na výrobce OPAL certifikovaných SSD, která sice hlásila, že šifrují, ale nešifrovala a vesele ukládala v otevřeném tvaru, protože to v benchmarcích vypadalo dobře. A z těch co si pamatuju, se to týkalo v první řadě Samsungu a Sandisku.
Tam to byl taky podvod, nebo jen hloupost, protože šifrování na řadiči nedokázali před vydáním dostat do chodivýho stavu?
Ptám se pro kamaráda.

Ja si pamatuji jeste takove co si to heslo v plaintextu i ulozili ... a pak odemceni delali porovnanim. KDF hadr :D A podobne pristupovali k firmware, takze se to tam dalo najit, upravit..

Pro zajemce o tema, doporucuji paper:
"Self-encrypting deception: weaknesses in the encryption of solid state drives"

To se ta zapadni svoboda a demokracit po autorovi dozadovala zadnich vratek tak vehementne, ze vyvoj radsi ukoncil.
I tohle nepravděpodobné tvrzení vyžaduje výjimečné důkazy. Nebo alespoň nějaké důkazy.