Názory k článku Šifrování SSD lze prolomit, ani BitLocker není v bezpečí

Defaultni sifrovani celeho disku je smutne. Za prve, 99% dat na disku sifrovat nepotrebuje, protoze jde o notoricky znama data (binarni soubory OS a aplikaci, audio, video).

Co by potrebovalo byt sifrovano, jsou vybrana citliva data, kde zpomaleni vykonu stoji za tu namahu, pak na disku ulozena virtualni pamet (pro swap a pripadne suspend), a pak, pokud jsou system a aplikace tak pitome, ze si docasne soubory vyrabi jinde nez v adresari s puvodnim souborem, i misto pro docasne soubory.

Zbyva vyresit zalohovani a sifrovani zaloh, protoze obnova sifrovaneho disku muze byt problematicka. Zejmena u software, ktery tvrdi, ze sifruje per blok a zvlada obnovu poskozeneho filesystemu obcas tato nefunguje, na rozdil od hardware sifrovani disku. U SSD ale obvykle k zadne obnove nedochazi, disk odejde komplet a typicky se uz ani radic nebavi s uzivatelem (cili data na pametovych cipech uz ani neni jak smazat/prepsat).

Windows na rozdil od linuxu docasnych kopii na ruznych mistech vyrabeji vice, nez je zdravo, o stupidni indexaci obsahu ani nemluve - ta by na citliva data nikdy nemela byt pouzita.

Software sifrovani na SSD, obdobne jako antivir na SSD, zpusobuji bohuzel nechutne zpomaleni a ztratu vykonu disku i OS a tak trochu popiraji smysl SSD. Cili rozhodne nutit vyrobce zvysit spolehlivost hardware sifrovani. Zaroven je nutit implementovat i secure erase jak jej ma u novejsich rad Intel, stejne to ve vysledku pouziva zahozeni a nevratnou zmenu sifrovaciho klice bez desifrovani/za­sifrovani dat plus zahozeni obsahu vsech nepouzitych bunek . Bohuzel, zatim ma k dispozici jen Intel, ostatni vyrobci implementovano bud nemaji vubec, nebo tam sice funkce je, ale nic nedela. Klasicky software wipe spusteny z OS jen snizi zivotnost SSD disku, ale vsechna data na nem stejne nikdy neprepise.

Osobne systemovy disk SSD, tamtez pripadne velke datove soubory pro hry a multimedia, ale citliva data idealne bud jiny disk, nebo sifrovany kontejner, ktery se ovsem pripojuje, jen pokud potrebuji se soubory pracovat. Na linuxu bez problemu, pro tmp svazek lze pouzit pamet OS, virtualni diskovou pamet lze zakazat, mate-li dost RAM, nebo sifrovat, nemate-li.

U windows vzhledem ke stupidnimu pristupu k vytvareni docasnych souboru je to bohuzel dost problem. Jestli a ktera data stoji za razantni snizeni vykonu SSD pri software sifrovani, je na zvazeni. Obvykle ale plati, ze takovych dat neni mnoho a nepotrebuji byt extra rychle ctena/zapisovana.

Ohledne VeraCrypt, pri srovnani s puvodnimi verzemi truecrypt mi prijde pomalejsi, a taky verit francouzskemu autorovi a francouzske firme IDRIX, kdyz pristup Francie k sifrovani a jeji legislativa je z pohledu povinnosti francouzskeho obcana a firmy je pomerne nekompromisni, mi prijde ponekud naivni. Vysledky auditu kodu obou bohuzel take ukazaly vice nedostatku u VeraCrypt (diky auditu snad opraveno), ale primarne mne zneklidnuje hlavne ta Francie jako zeme puvodu. Tam je bohuzel nelegalni i septat.

Softwarové šifrování ve Windows (=BitLocker) využívá AES-NI instrukce v procesorech, takže na většině počítačů (s novějšími CPU - cca max 4-6 let starými) k žádnému zpomalení nedojde při přepnutí z “HW” šifrování na “SW”.

Je vidět, že tomu nerozumíš.

Ano, máš pravdu, že moderní procesory toto umí urychlovat.
Ne, není pravda, že k žádnému zpomalení nedojde.
Už jsi slyšel o DMA přenosech?
Tj. vezmeš tento blok dat a předhodíš ho procesu, který ho chtěl?
A jak si myslíš, že to funguje s kryptovanými daty?
Nejprve je musíš načíst, pak rozšifrovat (což dělá programové vlákno) a nakonec přehodit procesu.
Takže ti minimálně narůstají latence.
A nepostřehnutelné to je jen v případě, kdy se jedná o malé soubory a procesor se fláká.

Je videt, ze jsi odbornik... moderni FDE sifruje bloky, je ji u zadele jestli tam mas maly soubor nebo veliky, veme xkb blok a udela nad nim danou operaci. Diky AES-NI mas treba u AES-256-CBC na treba Intel i5-2500K performance 522 Megabytes per Second. Ukaz mi ktery home SSD zvlada zapsat 522Megabytes za sekundu? Treba takovy Samsung 960 PRO 2TB ma cteni 3500 MB/s (438megabytes/s), zapis ma samozrejme pomalejsi. U PCIe karet ala SSD muzes narazit na vykonnostni limit CPU ale zase neni problem pouzit vykonnejsi CPU - treba takova i7 zvlada 1100 Megabytes per Second... A latence? Potrebujes 2-8 clock cycles (dle cpu).

Ty jsi osel, to snad není možný...

Ano, moderní ZCELA NEZATÍŽENÝ procesor skutečně zvládne "až" 500MB/s, jenže musí být ZCELA NEZATÍŽENÝ.

Nulo.

true MB/ps= 3500MBps=28000Mbps

VeraCrypt je pomalejsi pri derivaci klicu, protoze nasobne zvetsil pocet iteraci a pridal nove algoritmy, takze se pomalu montuje. To je ale kvuli bezpecnosti! Benchmarky disku ti asi budou ukazovat trochu horsi cisla, ale v praxi nemas sanci nic poznat. Jestli se ti disk zda pomalejsi, je to IMFAO jen tvuj dojem. A zadny audit VeraCrypt zadnou vaznou zranitelnost nikdy neodhalil.

BTW, zdrojaky se od puvodniho TrueCryptu moc nelisi. Pridali par novych algoritmu a zvedli pocet iteraci u derivace klicu, hrabou se v UI.

A tu Francii nechapu. Jakoze vlada ve Francii upravuje jejich git repo?

IDRIX dela na zakazkach pro francouzskou vladu (jestli se nemylim, jde o neco pro min. zahranici). Tato informace proflakla na jejich foru, a nekdo z firmy to taky potvrdil. Pozdeji pak cele vlakno "zmizelo"...

btw, zvlada veracrypt uz konecne desetinna cisla? Nevim jestli je to "feature" jeste z casu TC, ale posledne co sem to testoval, nebylo mozne zadat volume-size jako desetinne cislo, treba "2.5" GB. Je sice mozne prepnout zadani velikosti na "MB", jenze volne misto je porad reportovano v "GB" (a to jeste neni jasne, jestli VC pouziva binarni nebo decimalni "giga")...

Sofrware na sifrocani disku ma nejvetsi problem, ze v UI nemuzes zadavat gigabajty desetinym cislem?

Vis co znamena "btw"? Ne? Tak si to najdi! Mnohem vetsi problem sem popsal vyse...

Jo, a k tem gigabajtum: chci si udelat "traveller disk" na usb, tudiz nejdriv normalni formatovani, pak nainstalovat VC a zbytek volneho mista pro jeden sifrovanej soubor. Tak tedy spustim VC a chci udelat zasifrovanej kontejner. VC hlasi ze z myho "8GB" usb je volne "7.47GB". Prijde mi docela logicke na tom samym miste zadat velikost sifrovaneho kontejneru 7.47GB (nebo 7.4). Jenze ouhle, prave tohle nejde! Takze jenom "7GB", a zbytecne stracim temer pul giga jen proto, ze VC nekde na vstupu ceka integer misto real...

neda sa to definovat v MB? napr 2500MB?

Buď vám jde o výkon nebo bezpečnost. Šifrování celého disku přináší pohodlí pro uživatele, nemusí mapovat šifrovaný kontejner. Nemusíte řešit, že aplikace si ukládá dočasná data "někam". Uživatelé (ale správci také) jsou líní, jakýkoliv další krok navíc, tedy připojení šifrovaného kontejneru, bude dříve nebo později vynechán. Prostě se data uloží někam, kam není třeba se složitě přihlašovat. Nemyslím si, že uživatel jakkoliv pozná ztrátu výkonu šifrováním. Ano, budou určitě situace, kde opravdu bude záležet na smysluplném využití každého taktu, nebude se ale asi jednat o běžný spotřební hardware. U kompletního šifrování se lenost obejde tím, že počítač prostě nenastartuje.

Jak píšete, obnovení dat z SSD je více než problematické, pokud nemůžu přečíst z disku data, pak mi vlastně nevadí, že jsou šifrovaná a nejdou při havárii přečíst. Uživatelé notebooku navíc jsou více vystaveni riziku krádeže, taky data nemáme z čeho obnovit. A o to možná jde v testu nejvíce, spotřební SSD nechrání proti krádeži dat v případě odcizení disku. A to je ten největší problém.

Souhlasím, že Windows jsou z hlediska práce s diskem velmi stupidní a dokáží "utahat" disk k smrti. Opět, šifrování s tím nemá téměř nic společného, je jedno jestli je opotřebován SSD s výše uvedenými následky, nebo SSD s šifrováním. Data jsou ztracena tak jak tak.

Také souhlasím s tím, že pokud chcete disk bezpečně vymazat, pak většina klasických nástrojů stejně data nesmažou. Zásadní výhoda šifrování, vymažu hlavičku s klíčem a data, minimálně podle současných znalostí, nepůjdou obnovit. Můžou na disku zůstat. Bavíme se ale stále o spotřebním sektoru, ve firmách už většinou bezpečnost pochopili a vyřazené disky se fyzicky likvidují.

Pokud jde o obnovení, dost záleží, co a jak je domotaný. Zachránit se dá leccos. Já jsem se teda nejvíc zapotil jednou, když jsem si omylem smazal PV v LVM a pak mě docvaklo, že v něm byl LV s EXT4+LUKS a na tom nezálohovaný data... Sice to trvalo, ale data zachráněna.

A pořád platí, že data z havarovanýho disku se nejlíp zachraňují RSYNCem ještě před havárií. Bez ohledu na šifrování nebo na technologii.

> Co by potrebovalo byt sifrovano, jsou vybrana citliva data, (...)

Protože když ti jde o bezpečnost, není nic lepšího než říct "tohle zkus rozšifrovat, výsledek by za to mohl stát". Pokud šifruješ, abys uchránil disk v případě ukradení, tak hádám že v tu chvíli zvolíš to nejjednodušší řešení (šifrovat všechno). Na windows navíc nemůžeš říct, kde který program nechává jaká data, takže selektivní šifrování má za výsledek jen to, že někde se na disku bude válet nechráněná kopie.

Všimni si, že jsem nic neříkal o tom, kde ukládají data windows.

Nemluvě o "zapomenutém ladicím nástroji" v noťasech od HP, kde roky klávesnici poslouchal ovladač zvukovky, a co kdy bylo klofnuto, to pečlivě uložil do nešifrovaného debug.txt. A po "updatu" se jim to povedlo opravit tak, že to tam bylo furt :-) Odstranili to až asi na třetí pokus.

Jenomže tady jde o to, že šifrováním pouze některých dat akorát upozorníš na to, co je důležité, takže tím ostatním se útočník nemusí zabývat.

To jako ve windows muze neadministrator zapisovat mimo svuj domovsky adresar a temp?

Nejen to. Dokonce ještě relativně nedávno si většina autorů SW pro Windows myslela, že je naprosto normální předpokládat možnost zápisu do adresáře, kde je jejich úžasná aplikace instalovaná a vyžadovali ji - kamarád se dokonce nechal slyšet, že je úplně na ... jestli to v UNIXech normálně nejde.

Samo. Posledně jsem viděl nějakou cache adresářovýho stromu přímo v C:\ Stejně jako si můžeš spustit binárku z dokumentů a systém to vůbec netankuje.

Autoři softu jsou sice prasata, ale na druhou stranu, M$ ani nikdy nedefinoval jasný standard, ani neučinil nic pro ochranu systému před prasaty.

To sic, ale ze by v tomhle byla v Linuxu nejaka odlisnost...jo, sice jsou oficialni doporucene adresare, ale ochrana taktez nula.

Neblabol lulane, normalni user si predevsim muze muze cokoli spustit, coz si v tuxu nemuze, pokud to nejdriv neudela spustitelny, coz se mu da snadno zakazat, narozdil o zajebanejch widli.

Hele, to jsou zbytečný žabomyší války. "Tak sdělano", a když věci děláš správně, v ničem ti to nevadí. Navíc už od Vist taky není tak jednoduchý jako obyč.user psát kam nemáš, jako to šlo v 9x a XPčkách. Můžeš samozřejmě víc než v linu, ale není to už dávno tak zlý jak to bylo.
Hlavní mor je v tom, že v důsledku mnohaletý historie prasečin ze strany tvůrců aplikací si na windowsech všichni zvykli, že aby šlo používat to co potřebujou, musí každýho uživale udělat adminem, i když zrovna tohle už dávno není pravda.

Jiste, vis vo tom hovno ale to ti nebrani vo tom hovne zvanit, stejne jako lulan. U 100% vsech aplikaci je prvni odpoved v libovolnych faq "a kdyz vam to nefunguje, pustte to as admin". Hry spousta lidi ani nijak jinak nespousti, protoze vedi ze jim to jinak fungovat nebude.

A nezvan ty kokote o tom, ze za to muzou vyvojatri tretich stran, muzou za to vyhradne zmrdi z M$ ...

"c:\Users\...\Ap­pData\Local\Mi­crosoft\Micro­soft SQL Server\150\SSIS­\110\x86\applo­cal\DtsDebugHos­t.exe"
Tohle je sracka z jejich staje. A je jich tam mhohem vic.

EFS je i na W10 Home? BitLocker tam není... Obávám se, že Home-aři mají na výběr VeraCrypt, což je dost Hobsonova volba.

Promiň mi ten výraz, ale za sebe nevidím důvod se s*át s licenční politikou MS, když mě příležitostně na home stejnak downgradují :) Každý máme nastavené priority jinak. Ty máš vyšší edici, já mám VeraCrypt. A s ním jsem spokojený.

Houmy umí šifrovat na úrovni souboru a složky; má to drobnou nevýhodu, že je to vázáno na SID účtu, takže když si přenosný médium odneseš na jinou mašinu, tak soubory nepřečteš ani když se tam účet jmenuje stejně a má stejný heslo, protože nezaručíš že je to tentýž účet.

Můžeš mě navést?

Viete urobit cryptsetup benchmark? Zaujimalo by ma, ci rychlost citania/zapisu zodpoveda rychlostiam aes-xts z benchmarku (podla uvedenych rychlosti je pravdepodobne pouzivany aes-ni).

A ta příslušná aktualizace od MS asi vypíná tu HW podporu pro šifrování, ne? To budou mít v práci radost, že se jim to ještě víc zpomalí. :-)

Nezpomalí.

Proč by se jim to nemělo zpomalit?
Naopak bych řekl, že se jim to zpomalí a ještě se zvýší opotřebení disku.
Když je to dementně udělané, jako že to dementně dost často udělané je, nejprve se uloží originální blok na disk a pokud tam vydrží déle, než definovaná konstanta pracovního souboru, bude zašifrován. (To je v kompetenci OS i disku samotného, mohou to tak dělat oba.) Leda bys šel přímo přes fvevol.sys, který může dělat šifrování on-the-fly a hardwarové šifrování na disku úplně vypnul.

Protože to blbě čteš. Tam kde je HW šifrování aktivní, bez dalšího aktivní zůstane. Abys to překlopil na SW, musíš v politikách SW povolit, pak svazek dešifrovat, a znova zašifrovat.

Ano, tak trochu ztraceno v překladu.
Ve článku je poměrně dost nepřesností, ale jako upozornění na problém to docela funguje. Ale na druhou stranu i ta zpráva má pár poměrně výrazných chyb. Ani jedno zařízení, které popisují prostě není FIPS approved, jsou jen OPAL compliant a v tom je dost podstatný rozdíl. Druhá věc je že celý test zaměřili pouze na implikaci bezpečnosti Microsoft Bitlockerem, což je poměrně dost zavádějící, protože Microsoft se s ničím moc nepere. Chyby jsou u obou entit, jak u výrobců HW (úpravy firmware, otevřené funkce) tak i SW (a dělá si někdo vůbec iluze?). Ale Microsoft vede prim už jen tím, že si uživatel od Windows 8.1 v podstatě ani nemůže vybrat. Prostě spustí originál instalačku a má vymalováno. By default. Sranda by ještě byla pokud by se zjistilo že master klíč použitý pro definici vlastníka jednotky je univerzální. To by mne asi pobavilo nejvíc, ale rozhodně nepřekvapilo.
Možná bych mohl ještě napsat že TCG ještě do nedávna měla dceřinku, která na implikaci standardů TCG dohlížela a dokonce i vydávala podklady pro standardizaci a kontrolovala jejich plnění v praxi, ale to by tu firmu nesměl Microsoft utopit v krvi a potichu demontovat její vývoj (VSC).
I tak ale ve zprávě nenacházím základní informace o uvedených discích a pak ani revizích firmware, na kterých testy probíhaly. To by mne docela zajímalo, protože která z edic EVO má podobné problémy? Pak by mohla být zajímavá i varianta použít pro personalizaci disku jiný nástroj než Bitlocker. Microsoft prostě není jediný výrobce personalizace SED disku. Navíc se ve zprávě operuje se standardní historickou výtkou k OPAL standardu a tím je DEVSLP, jako by snad pravidlo, že na šifrovacích systémech se sleep režim prostě vypíná.
No a na závěr bych poopravil nadpis článku, protože technologie OPAL jako taková prolomena nebyla a v návrhu chyba nalezena taky nebyla. Problém je v implementaci technologie některými výrobci disků, navíc v kombinaci s Bitlockerem, který prostě za bezpečnostní nástroj považovat ani nelze. Nadpis by mohl znít spíš: Bitlocker čelí problémů s šifrovacím systémem TCG Opal na low-end discích Samsung a Crucial . Protože předjímat, že to je problém všech SSD disků standardu OPAL, si netroufají ani tvůrci zprávy. Nadruhou stranu Samsung i Crucial by se měli zamyslet nad tím co dělají. Některé informace ve zprávě považuji za celkem alarmující a to i za předpokladu že jde o disky, které prostě nejsou FIPS l2/l3 certified.

A přesně proto do zblbnutí opakuju: "Kdo od výrobců čehokoliv čeká cokoliv jiného, bude akorát neustále zklamán"

Specielne toho od M$ co?

Zase blabolis lulane? Kolik miliard bugu maj soudruzi z M$ v ovladacich ktery sami dodavaj? A vecma jako dos se v M$ ani nezabejvate, protoze dosnout cokoli na widlich zvladne i decko.

A vis blabole, jeste se mi nestalo, ze by mi kernel jen tak sam od sebe prepsal fotky na disku nebo mi zacal tvrdit, ze moje kopie systemu neni licencovana, coz widle delaj zcela pravidelne predevsim tem blaznum, ktery si je koupej.

Přesně tak, není. Přečetl jsem pár driverů SAMSUNGu a tak hnusně znásilňované Céčko jsem ještě neviděl.

Pekny clanok, ale pytam sa, ci by nebol lepsi nadpis: Opat chyba v HW sifrovani diskov, LUKS v bezpeci.

Takže mi chcete říct, že mají disk zašifrovaný klíčem uloženým na tom stejném disku a heslo se používá pouze v nějaké stupidní podmínce, kde se porovná s uloženým heslem...které lze navíc bez hesla změnit. A tomu se říká šifrování. Doprdele na co to tam je?? Vždyť to tam jenom mlátí...

Tak nějak bych řekl, že pokud lze zasáhnout do firmware disku tak nikdy nebude jeho interní šifrování bezpečné.

Stále používám truecrypt a jsem spokojen.

Tak jasně, u pumpy ti taky nikdo nebrání do benzíňáku natočit řepku. Je to tam čistě pro případ, že by výrobce tvýho auta, nebo pumpař, nebo rafinérka úmyslně lhali o tom, co teče ze stojanu.

Bitlocker nenív bezpečí, protože se MS zase snaží být chytřejší než uživatel a myslet za něho (aniž by to někomu řekl). Pokud Windows zjistí HW šifrovaný disk, nechá to defaultně pouze na něm. "Oprava" šifrovaných SSD podle MS spočívá ve vynucení SW šifrování i v případě, že je to šifrovaný disk. Možná jsem staromódní, ale tohle by měl být podle mě defaultní stav - hardwarové šifrování disku by operační sýstém vůbec nemělo zajímat.

A ty si u pumpy prostě natočíš do nádrže a spoléháš, že je to na stojanu napsaný správně, nebo si děláš pokaždé vlastní rozbory?

Spoléhat se na něco v odvětvích, kde je odpovědnost výrobců za výrobky naprosto normální, je něco úplně jiného, než slepě věřit marketingovým nálepkám v prostředí, kde Vás napřed každý donutí souhlasit, že Vám v maximální zákonem povolené míře neručí za absolutně nic.

Počkej, Samsung a Micron ti prodej SSD podmiňují podepsáním warranty waiveru? To nemyslíš vážně.

Například hned zde, strana 2.