Najnowsze badanie pokazuje, że sprzętowe szyfrowanie w wielu modelach dysków SSD jest niebezpieczną pułapką. Nie dość, że samo szyfrowanie można ominąć, uzyskując dostęp do treści, to BitLocker używa domyślnie właśnie wariantu sprzętowego!
Holenderscy naukowcy opublikowali właśnie wstępne wyniki swoich badań nad szyfrowaniem sprzętowym wbudowanym w niektóre modele dysków SSD. Wyniki tego badania są bardzo niepokojące – w większości przypadków byli w stanie uzyskać dostęp do zaszyfrowanych danych bez znajomości kluczy szyfrujących. Bardziej niepokojące jest jednak to, w jaki sposób z szyfrowanych dysków korzysta domyślne narzędzie do szyfrowania dysków w systemach Windows, czyli BitLocker.
Wiele scenariuszy, efekt ten sam
Naukowcy z uniwersytetu Radboud opublikowali wyniki swoich badań nad szyfrowaniem dysków SSD. To ważne badanie, ponieważ z punktu widzenia architektury bezpieczeństwa sprzętowe szyfrowanie dysku może mieć sporą przewagę nad szyfrowaniem programowym. W przypadku szyfrowania sprzętowego klucze szyfrujące nie muszą znajdować się w pamięci operacyjnej komputera, a jedynie w dedykowanym układzie kontrolera dysku (jednak najczęściej się znajdują, by łatwiej obsługiwać np. hibernację). Szyfrowanie sprzętowe jest dużo wydajniejsze, ponieważ odpowiada za nie układ znajdujący się w dysku, dzięki czemu nie obciąża systemu operacyjnego komputera. Nic więc dziwnego, że jest to preferowana metoda zabezpieczania danych. W przypadku BitLockera, który w wielu firmach pomaga zapewnić całodyskowe szyfrowanie (szczególnie popularne w dobie RODO), decyzja o tym, czy używać szyfrowania programowego, czy sprzętowego, jest podejmowana automatycznie. Jeśli dysk informuje system operacyjny, że wspiera szyfrowanie sprzętowe, to BitLocker wybiera ten wariant, nie używając wtedy szyfrowania programowego. I wszystko jest OK, dopóki szyfrowanie sprzętowe działa prawidłowo. No właśnie, dopóki…
Badacze przyjęli dość realistyczny model ataku, w którym atakujący ma fizyczny dostęp do dysku, a posiadacz hasła wie o tym fakcie i nie jest chętny wyjawić hasło (czyli wykluczamy ataki, w których atakujący podsłuchuje hasło użytkownika). Mamy zatem do czynienia z sytuacjami np. takimi jak kradzież lub zgubienie „zaszyfrowanego” komputera. Aby przeprowadzić analizę dysków, badacze pozyskali ich oprogramowanie wbudowane. Był to w niektórych przypadkach dość skomplikowany proces – po szczegóły odsyłamy do oryginalnej pracy. Po zdobyciu oprogramowania poddali je analizie wstecznej. Szukali podatności, które pozwolą na uzyskanie dostępu do zaszyfrowanej treści dysku bez znajomości hasła. Okazuje się, że znaleźli ich niepokojąco dużo, a przeprowadzenie poprawnej implementacji szyfrowania dysków przekroczyło umiejętności wielu firm je produkujących.
Temat szyfrowania dysków na poziomie sprzętowym jest ciekawy sam w sobie – miłośników szczegółów odsyłamy do pracy autorów. Osobom mającym mniej czasu lub chęci wskażemy tylko, że klucz szyfrujący dysku (DEK) nie jest tym samym, czym hasło odblokowujące dysk (zmiana hasła nie może powodować konieczności odszyfrowania i ponownego zaszyfrowania całego dysku). Powinny być one powiązane i nie powinno dać się odzyskać DEK bez znajomości hasła. Niestety nie zawsze tak jest. Oto jak radziły sobie z atakami konkretne dyski:
- Crucial MX100: dzięki dostępowi przez interfejs JTAG badacze zmodyfikowali procedury szyfrowania dysku i odczytali DEK, odszyfrowując dysk bez znajomości hasła. DEK nie był powiązany z hasłem.
- Crucial MX200: identycznie jak powyżej.
- Crucial MX300: JTAG był już wyłączony, polecenia producenta zabezpieczone odpowiednią kryptografią. Skuteczny atak wymagał znalezienia metody wykonania dowolnego kodu na urządzeniu (udało się) oraz analizy metod kryptograficznych chroniących główne hasło. Wymagało to wgrania własnego oprogramowania wbudowanego (po ominięciu kontroli integralności), ale pozwoliło na uzyskanie dostępu do zaszyfrowanych danych.
- Samsung 840 EVO: tu opis ataku przekroczył nasze możliwości analizy i jego opisania, możemy powiedzieć Wam jedynie tyle, że także się udało (w niektórych konfiguracjach) oraz odesłać do oryginalnego tekstu po szczegóły.
- Samsung 850 EVO: Podobnie jak w przypadku 840 EVO.
- Samsung T3 portable: Dzięki dostępowi przez JTAG atak polega na zmianie procedury weryfikacji hasła, by akceptowała dowolne. Pokonany.
- Samsung T5 portable: JTAG wyłączony, atak wymagał uzyskania możliwości wykonania kodu na urządzeniu, ale także się udał.
Podsumowanie
Wyniki badania są bardzo smutne. Szczególnie jednak są smutne dla firm, które pod rządami RODO nie zgłosiły incydentu zgubionego komputera, wychodząc z założenia, że „przecież dysk był zaszyfrowany, to nie trzeba”. Czas zatem przejrzeć wszystkie incydenty i sprawdzić, czy może jednak konieczna będzie korekta raportu… Współczujemy.
Dla zachowania pewności, że szyfrowanie faktycznie działa, warto najwyraźniej wymusić szyfrowanie programowe. Wydajność wydajnością, ale zarządzanie ryzykiem musi uwzględnić prawdopodobieństwo wpadek podobnych jak pokazane powyżej. Co prawda, producenci dysków opisane wyżej problemy usunęli lub są w trakcie ich usuwania, ale nie wiadomo, jakie jeszcze niespodzianki drzemią w oprogramowaniu wbudowanym.
Komentarze
Czy jeśli użyłem Veracrypt do szyfrowania dysku to on automatycznie używa sprzętowego szyfrowania czy programowego? Mam Cruciala MX100 i teraz zacząłem się bać po przeczytaniu tego artykułu.
Veracryot używa tylko szyfrowania programowego
VeraCrypt nie wspiera szyfrowania sprzętowego i nie jest zoptymalizowany do pracy z dyskami SSD, na co dowodem jest znaczny spadek wydajności. Deweloper otwarcie przyznaje, że nie dysponuje czasem, by zająć się problemem.
Od wersji 1.22 VerCrypt wspolpracuje z SSD. Ja mam na M2 SSD i dziala super. Przy Sepent-TW-AES 650 MB/s odczyt i zapis. System Windows 7.
VeraCrypt nie używa sprzętowego szyfrowania dysków. Nie używa też TPM.
https://sourceforge.net/p/veracrypt/discussion/general/thread/885ea79d/
Jeśli szyfrujesz Veracrypt to jest to w pełni programowe szyfrowanie i jest bezpieczne.
Wroc.!!Wydaje sie byc bezpieczne.Nigdy nie ma pewnosci.To tylko sprzet,program i standarty wymyslone przez czlowieka.
Jak zwykle osoby o najmniejszych zasobach wiedzy mają najwięcej do powiedzenia.
Veracrypt wydaje się nie używać typowego sprzętowego szyfrowania opartego o dysk. Jedynie domyślnie używa akcelerację sprzętową niektórych procesorów, ale też np. nie do tworzenia klucza.
Podłączam się pod pytanie.
Ciekawe jak dyski innych producentów. U siebie mam jeszcze starego Intela z serii 530, który wydajnością nie powala i szyfrowanie programowe mocno obniżało wydajność, więc zdecydowałem się włączyć w UEFI szyfrowanie sprzętowe, bo z tego co wyczytałem z jakiejś innej analizy, akurat kontrolery Intela były bezpieczne. Ale to było 4 lata temu, więc muszę na nono zweryfikować informacje. Może ktoś wie coś więcej na temat bezpieczeństwa szyfrowania w dyskach Intela?
Ech…. Jak się Was czyta to od razu człowiekowi kawa przestaje być potrzebna… A już byłem prawie przekonany do bitlocera :D:D:D veracrypt jest w porównaniu z nim dość mocno uciążliwy więc się zacząłem łamać a tu proszę. Znowu mój wrodzony pesymizm i fatalizm okazał się uzasadniony :D
Z drugiej strony patrząc jak dziurawe są procesory… Pewnie płyty główne z ich uefi dyski i inne elementy też nie grzeszą jakością projektów… Swoją droga czy korzystając z procesorów intela i tych dysków już trzeba zgłaszać incydenty do rodo? Bo w sumie to chyba zaczyna być mocno niewesoło.
Na czym polega wg ciebie „uciążliwość” VeraCrypt-a?
Jest kilka aspektów. Taki najbardziej namacalny to czas potrzebny na uruchomienie systemu. Wiem wiem bezpieczeństwo… Drugi to pewne problemy z szyfrowaniem 10 na nowych komputerach. Pewne problemy przy szyfrowaniu drugiej partycji.
Kolejna sprawa to to że nie masz opcji zdalnej administracji takim systemem. Chodzi mi dokładniej o zdalny restart.
Kolejny aspekt to uruchamianie przy użyciu klucza. Znowu VC tu nie daje nam narzędzia.
Z punktu wiedzenia użytkownika końcowego bl jest bardzo elegancki wprost może być przeźroczysty. Z punktu widzenia administratora bardzo ułatwia życie w wielu scenariuszach.
I nie lubię bl :D Z zasady po prostu nie do końca mu ufam ale nie mogę mu nie oddać że jest narzędziem bardzo dojrzałym i eleganckim. VC pomimo że go lubię i używam w wielu miejscach jest daleko za bl. Szczególnie to widać w zastosowaniach biznesowych.
> czas potrzebny na uruchomienie systemu.
> Wiem wiem bezpieczeństwo…
Używanie GPU do łamania haseł powoduje, że nawet zwiększona liczba iteracji funkcji SHA512 nie jest już mocnym zabezpieczeniem. Szkoda, że Veracrypt nie obsługuje funkcji haszującej argon albo chociaż bcrypt – łamać jest je znacznie trudniej, a system uruchamiałby się szybciej.
W BitLockerze możesz wymusić używanie tylko szyfrowanie software-owego (tzn. zabronić używania szyfrowania sprzętowego)
Polityka:
Computer Configuration\Administrative Templates\Windows Components\BitLocker Drive Encryption -> „Configure use of hardware-based encryption for fixed data drives” -> Disable
Ale wiesz, wystarczy uzywac TPM i nie ma problemu.
Nie rozumiem, problem dotyczy wszystkich wymienionych SSD czy tylko kombinacji SSD+Bitlocker (Windows)? Ew. jak sprawdzić podatność u siebie?
@fghj
Opisana podatność dotyczy szyfrowania sprzętowego wymienionych dysków. Jeśli używasz na takim dysku wyłącznie szyfrowania softwarowego, to ta konkretna podatność Cię nie dotyczy (być może jakaś inna, ale nie ta).
Natomiast warto sobie uświadomić, że inne modele dysków z szyfrowaniem sprzętowym też mogą być podatne, tylko jeszcze nie przebadane.
A co gdy szyfrujemy sprzętowo używając TPM?
Podpinam się pod pytanie? Jak sytuacje zmienia TPM?
TPM nie jest od przeprowadzania szyfrowania/deszyfrowania danuch. Jest czarną skrzynką pełniącą funkcję uwierzytelniania. TPM to element całkowicie opcjonalny nieważnie czy szyfrowanie jest sprzętowe (SED) czy programowe (chociaż nieco akcelerowane przez aes-ni).
Ja tam nie rozumiem tego co tu napisane bo według MS
https://docs.microsoft.com/en-us/windows/security/information-protection/encrypted-hard-drive
Encrypted Hard Drives utilize two encryption keys on the device to control the locking and unlocking of data on the drive. These are the Data Encryption Key (DEK) and the Authentication Key (AK).
The Data Encryption Key is the key used to encrypt all of the data on the drive. The drive generates the DEK and it never leaves the device. It is stored in an encrypted format at a random location on the drive. If the DEK is changed or erased, data encrypted using the DEK is irrecoverable.
The Authentication Key is the key used to unlock data on the drive. A hash of the key is stored on drive and requires confirmation to decrypt the DEK.
Czyli to AK odszyfrowuje DEK. A AK jest w przypadku TPM chroniony kluczem prywatnym z TPM. To albo MS kłamie albo niezgodnie z specyfikacją producenci dysków zrobili dodatkowy swój sposób szyfrowania DEK dla sobie znanych celów i powodów.
Na TPM nie warto w pełni polegać z innych przyczyn.
A ja powiem tak, mam Cruciala MX100 i na włączonym Bitlockerze komputer potrafił się wyłączyć, ot tak. Nawet bez bluescreena.
Też mam i nie mam, ani nie miałem nigdy takich problemów. Aktualny firmware masz?
To oddaj komputer do dobrego serwisu. Sorry ale jeśli to dysk jest przyczyną (wyłączanie komputera rzadko jest spowodowane samym dyskiem) to znaczy że za chwile stracisz dane. Chwile to pojęcie względne. Jeden delikwent któremu powiedziałem że za chwile straci dane przyszedł po dwóch latach :D Ale dane stracił bo kopie robił tylko przez pierwsze 6mc…
Takie wyłączanie ma się nijak do szyfrowania. Jak nie masz śladu w systemie po takim zdarzeniu należy szukać przyczyny w pądzie. Jak odepniesz na żywca od pracującego komputera dysk to system potrafi jeszcze nawet chwilę udawać że działa ;)
Tak, firmware aktualny.
Co ciekawe bez załączonego bitlockera już 2 miesiące bez takiego losowego wyłączenia. Potestuję jeszcze. Utraty danych się nie obawiam – robię regularnie backup.
Dodatkowo wrzucam dwa linki, które potwierdzają moją teorię:
https://forums.overclockers.com.au/threads/micron-ssd-win10-os-lock-kernel-power-41-enhancedstorage-ehstortcgdrv.1210045/
https://forums.crucial.com/t5/SSD-Archive-Read-Only/M500-Issues-with-locking-up-A-TCG-Command-has-returned-an-error/td-p/149506
Aktualizacja BIOSu mogłaby mi pomóc, ale problem polega na tym, że do mojego laptopa producent nie wydał nowego BIOSu od grudnia 2013. :(
U mnie w firmie randomowo się resetował serwer bez żadnego wpisu w logu. Po tygodniu okazało się, że w kablu zasilającym jedna z żył się przerwała i kabel przestawał łączyć pod wpływem losowych czynników zewnętrznych.
Hmmm to akurat potrafi każdy komputer, niezależnie od szyfrowania. Skoro u Ciebie obserwowałeś tylko z konkretnym oprogramowaniem i bez ekranu błędu, wstępnie obstawiałbym przegrzewanie się procka.
A LUKS korzysta z sprzętowego szyfrowania?
podbijam – co z LUKSem?
z softwarowego
Przypominam, że prawdopodobnie bitshit po cichu wysyla klucze do microsoftu.
Przypominam że prawdopodobnie jest to wierutne kłamstwo.
Windows baaardzo często kontaktuje się z serwerami M$, a 10 wręcz ciągle. Nikt nie wie, co tam jest przesyłane i bardzo dziwne, że akurat w tym miejscu M$ postarał się o solidne zabezpieczenia ;)
To już 13 lat, a nikt dalej nie rozgryzł co wysyła Windows.
nie jest. w firmach: BL backupuje klucze na serwer firmy, a priv – jeżeli logowałeś się kontem Microsoft – masz backup klucza na koncie M$. jest więc prawdopodobne, że jeżeli M$ chciałby klucz do twojego BL, to go sobie weźmie :)
polecam pooglądać requesty DNS wysyłane przez Win10 (telemetry, watson, nsatc, diagnostics, feedback, metaservices, vortex itp. itd.) – wszystko na WYŁĄCZONEJ diagnostyce i wył. raportowaniu w ustawieniach ;)
@adamh
Wiesz, technicznie to jest możliwe, a w takiej sytuacji trudno uwierzyć, że się nie odbywa.
Czyli znowu Apple wygrało:
– w starych makbukah szyfrownie softwar
– w nowych makbókach dysk nawet nie widzi plaintext – szyfrowanie robi T2 czy jak tam się ten terminator nazywa
Da się? Da się. Aha, hejterów odsyłam do prezentacji Ivana na blackhat i do iOS security guide.
Mniej inteligentnym mówię, że tu chodzi o pewien sposób myślenia o architekturze, nie o konkretny OS.
Ale sprawdzanie pisowni ciągle nie działa.
@Michal
Heh, poczekajmy na podatność w T2 :)
Sposób myślenia o architekturze Apple jest mniej więcej taki, jak polityka mieszkaniowa w byłym NRD. Każdemu „według potrzeb” identyczne mieszkanie z identycznymi sprzętami. Średnio nowoczesnymi, ale Sprawdzonymi i Gwarantowanymi przez Dostawcę. OK, niektórym taki standard i taka gwarancja wystarcza.
Ale Apple ma swój sprzęt; Microsoft musi współpracować z gratami wyprodukowanymi przez inne podmioty.
Jaki swój? Przecież oni używają procesorów intela więc są podatni na wszystkie błędy intelowskie. Dysków też nie używają swoich…. Pamięci tak samo nie są ich… Zresztą MB też nie do końca sa ich. Czasy kiedy był to ich sprzęt minęły wiele lat temu.
Napisałem to w kontekście układu T2, to chip który apple montuje do swoich kompów. Michał pisał, że T2, takie genialne jest. Może i jest dobre, ale jest w sprzęcie Apple… i trudno aby Microsoft coś takie sobie wymyślił – bo to firma od OS a nie od OS+HARDWARE (jak Apple)
Apple ma identyczne podzespoły na wszystkich komputerach które oferuje, dlatego macOS jest dokładnie przetestowany i zoptymalizowany pod ten jeden układ. Microsoft może przetestować Windowsa na tysiącach różnych podzespołów a i tak na sporej liczbie sprzętów coś będzie niekompatybilne
Ja korzystam z UseCrypta, szyfruje programowo i dodatkowo pliki przetrzymuje w chmurze, jak zgubię komputer to mogę odebrać dostęp do danych
https://www.wykop.pl/wpis/34502817/widze-ze-kampania-usecrypt-nie-ogranicza-sie-tylko/
I co tam przez te cztery lata? Mamy chociaż jeden model gdzie można zaufać w 100% sprzętowemu szyfrowaniu?
ja szukam za to hdd ktorego sprzetowemu szyfrowaniu mozna zaufac