Jak odporne są zaszyfrowane woluminy VeraCrypt i LUKS na uszkodzenie danych?

Odpowiedź na pytanie częściowo została udzielona, ​​ale wciąż nie tego dokładnie szukam. Zobacz aktualizację 1 w dół

Planuję zaszyfrować niektóre systemy plików za pomocą VeraCrypt i LUKS, ale obawiam się, że jeśli wystąpi pojedynczy problem, nie będę mógł ponownie zamontować partycji, tracąc w ten sposób wszystkie dane w nich przechowywane. (z powodu uszkodzonych sektorów / bloków, awarii zasilania podczas operacji zapisu, błędów systemu plików itp.)

Ponadto VeraCrypt mógł rozwidlić narzędzia naprawcze TrueCrypt, ale nie liczę na to i nie szukam więcej o prawdziwych przypadkach.

Wiem także o RAID i kopiach zapasowych / skarbcach, ale nie tego szukam.

Pytanie brzmi: jak odporne są same zaszyfrowane partycje za pomocą VeraCrypt i LUKS?

Aktualizacja 1 :

Moje pytanie dotyczy raczej odporności zaszyfrowanej partycji i jej danych, a nie zapisywania klucza głównego, metadanych lub nagłówków. Problem jest podobny do solidnego archiwum 7zip: jeśli pojedynczy bit zostanie uszkodzony w środku, stracisz całe archiwum.

Czy zaszyfrowane partycje będą równie wrażliwe? (z wyłączeniem klucza głównego, metadanych i nagłówków)

PS: Przepraszam, jeśli nie odpowiem od razu, pracuję i podróżuję po całym świecie - dzięki czemu ten post jest powiązany - i często mam do czynienia z trudną sytuacją. Ale na pewno odpowiem na pewno.

W praktyce szyfrowanie jest prawie tak samo odporne, jak bez niego, o ile prawidłowo tworzy się kopię zapasową klucza głównego i metadanych .

Oprócz metadanych, uszkodzenie wpłynęłoby tylko na blok uszkodzonego bitu, w większości przypadków tylko 16 bajtów.

W większości przypadków uszkodzenia danych za pomocą klucza i narzędzi (takich jak hasło i Veracrypt / LUKS) masz taki sam dostęp jak nieszyfrowany dysk, tak jak zwykle w przypadku codziennego korzystania z szyfrowanego dysku. Szyfrowanie dodałoby tylko dodatkowy krok (otwarcie zaszyfrowanej partycji) niż zwykłe. Tak więc w tym przypadku zachowuje się jak dane niezaszyfrowane.

W Veracrypt lub Luks musisz przechowywać klucz główny na dysku, który jest zaszyfrowany Twoim hasłem. Uszkodzenie tego sektora spowoduje utratę trwałych danych. Można to łatwo rozwiązać za pomocą kopii zapasowej klucza głównego (kilka kilobajtów), co jest łatwe w obu programach i jest wysoce zalecane dla wszystkich.

Szczegóły dotyczące niemetadanych

Zarówno Veracrypt, jak i Luks korzystają dziś z XTS. W tym trybie jest obliczany klucz dla każdego bloku. Upraszczając, do zaszyfrowania bloku iużywasz klucza wygenerowanego za pomocą kluczy głównych i numeru bloku. Tak więc szyfrowanie jednego bloku jest niezależne od drugiego. Jeśli uszkodzisz niektóre informacje, będą one ograniczone do tego bloku.

W XTS dzieli blok na podbloki (zwykle 16 bajtów) i tworzy klucz, a następnie szyfruje nim ten podblok. Oznacza to, że jeśli trochę zmienimy, wpłynie to tylko na te 16 bajtów.

W ramach testu, zmiana jednego bitu w woluminie Luksa, zmienia 16 bajtów oryginalnego pliku na bełkot, ale pozostałe 496 nadal pozostają niezmienione. W pliku 7zip wykorzystuje metodę strumieniową, w której wszystkie bajty są powiązane, więc zmiana jednego bajtu wpłynie na wszystkie pozostałe - w tym przypadku tak nie jest.

Niektórzy uważają to za problem, ponieważ możesz wiedzieć z dokładnością do 16 bajtów, kiedy i gdzie zmieniasz zwykły tekst, porównując tylko zaszyfrowane dane.

Więcej interesujących informacji na ten temat można znaleźć pod tymi linkami:

https://crypto.stackexchange.com/questions/6185/what-is-a-tweakable-block-cipher

https://security.stackexchange.com/questions/39306/how-secure-is-ubuntus-default-full-disk-encryption

https://en.wikipedia.org/wiki/Disk_encryption_theory

Szczegóły dotyczące klucza głównego

ŁUKS

LUKS ma kilka sektorów na początku partycji (lub dysku) z metadanymi, przechowującymi metody szyfrowania, inne parametry i 8 miejsc na klucze. Do szyfrowania i deszyfrowania dysku używa klucza głównego , dużej liczby losowej generowanej podczas tworzenia kontenera LUKS. Aby go zapisać, szyfruje klucz główny za pomocą hasła, poprzez wielokrotne iterowanie kryptograficznej funkcji skrótu nad hasłem i generowanie określonego klucza dla tego gniazda. Możesz mieć 8 różnych haseł dla tego samego dysku, każde szyfrujące klucz główny za pomocą innego hasła w gnieździe. Po zmianie hasła jest to tak proste, jak zaszyfrowanie klucza głównego i nie zmiana całej partycji.

Tak więc, gdy te sloty i metadane są uszkodzone, nie można odzyskać klucza głównego, który jest naprawdę używany do odszyfrowywania, tracąc wszystkie dane na dysku. Jest to prosty sposób na szybkie zniszczenie wszystkich danych. Ale jeśli masz kopię zapasową Nagłówka woluminu, bardzo łatwo ją odzyskać.

Poniżej znajduje się kopia LUKS FAQ na temat kopii zapasowej wyodrębniona z https://gitlab.com/cryptsetup/cryptsetup/wikis/FrequentlyAskedQuestions#6-backup-and-data-recovery

Chociaż możesz po prostu skopiować odpowiednią liczbę bajtów z początku partycji LUKS, najlepszym sposobem jest użycie opcji polecenia „luksHeaderBackup” programu cryptsetup. Chroni to również przed błędami, gdy podczas tworzenia partycji LUKS zastosowano niestandardowe parametry. Przykład:

cryptsetup luksHeaderBackup --header-backup-file <file> <device>

Aby przywrócić, użyj polecenia odwrotnego, tj

cryptsetup luksHeaderRestore --header-backup-file <file> <device>

Jeśli nie masz pewności co do przywrócenia nagłówka, najpierw wykonaj kopię zapasową bieżącego! Możesz także przetestować plik nagłówka bez przywracania go, używając opcji --header dla odłączonego nagłówka w następujący sposób:

cryptsetup --header <file> luksOpen <device> </dev/mapper/ -name>

Jeśli to odblokuje twoje klucze, jesteś dobry. Nie zapomnij ponownie zamknąć urządzenia.

W niektórych okolicznościach (uszkodzony nagłówek) to się nie udaje. Następnie wykonaj następujące kroki:

Najpierw określ rozmiar klucza głównego:

cryptsetup luksDump <device>

daje linię formularza

MK bits:        <bits>

z bitami równymi 256 dla starych wartości domyślnych i 512 dla nowych wartości domyślnych. 256 bitów jest równe całkowitemu rozmiarowi nagłówka 1'052'672 bajtów, a 512 bitów jeden z 2MiB. (Zobacz także punkt 6.12) Jeśli luksDump zawiedzie, przyjmij 2MiB, ale pamiętaj, że jeśli to przywrócisz, możesz również przywrócić pierwszy 1M systemu plików. Nie zmieniaj systemu plików, jeśli nie możesz określić rozmiaru nagłówka! Dzięki temu przywracanie zbyt dużej kopii zapasowej nagłówka jest nadal bezpieczne.

Po drugie, zrzuć nagłówek do pliku. Można to zrobić na wiele sposobów, wolę następujące:

head -c 1052672 <device>  >  header_backup.dmp

lub

head -c 2M <device>  >  header_backup.dmp

dla nagłówka 2MiB. Sprawdź rozmiar pliku zrzutu, aby się upewnić. Aby przywrócić taką kopię zapasową, możesz wypróbować luksHeaderRestore lub zrobić bardziej podstawowy

cat header_backup.dmp  >  <device>

Veracrypt

Veracrypt jest podobny do LUKS. Nie jestem przyzwyczajony do tego, jak z Truecryptem, ale ogólny pomysł utrzymuje się.

Veracrypt ma tylko jedno gniazdo klucza, więc nie możesz mieć więcej niż jednego hasła w tym samym czasie. Ale możesz mieć ukryty wolumin: przechowuje metadane na końcu partycji (dysku lub pliku). Ukryty wolumin ma inny klucz główny i użyje końca partycji jako nakładającego się miejsca. Pomysł, że należy wykonać kopię zapasową, jest taki sam. Można to zrobić za pomocą Tools -> Backup Volume Headeri Tools -> Restore Volume Header. Dzięki szyfrowaniu systemowemu utworzono dysk rozruchowy z kopią zapasową klucza, która odzyskuje moduł ładujący i klucze Truecrypt w przypadku uszkodzenia. Dokonuje się tego, zanim cokolwiek zaszyfruje, i o ile wiem Veracrypt nadal robi to samo.

Aby uzyskać więcej informacji, zobacz ten link https://veracrypt.codeplex.com/wikipage?title=Program%20Menu

Zagadnienia bezpieczeństwa dotyczące kluczy zapasowych

Jeśli masz na przykład wyciekłe hasło i zmienisz hasło woluminu na nowe, mocne i bezpieczne, osoba z dostępem do kopii zapasowej nadal będzie w stanie odszyfrować pliki przy użyciu starego hasła. Kopia zapasowa jest w zasadzie kluczem głównym zaszyfrowanym (starym) hasłem. Tak więc przy zmianie haseł konieczne jest również utworzenie nowej kopii zapasowej i zniszczenie starszych. A trwałe niszczenie danych może być bardzo trudne.

Dla każdej kopii zapasowej z tym hasłem istnieje możliwość odszyfrowania danych przy użyciu tego hasła. Można tego użyć na przykład w Veracrypt, używając „uniwersalnego hasła” (jak w korporacji), tworząc kopię zapasową i zmieniając hasło. Więc dział IT. może odzyskać dostęp do tego woluminu, nawet jeśli ktoś zgubi hasło (pomyśl jako hasło główne, ale nie myl z kluczem głównym wcześniej).

Końcowe myśli (TL; DR)

Prawdopodobieństwo uszkodzenia określonego sektora za pomocą klucza głównego jest mniej prawdopodobne niż w przypadku całkowitej awarii dysku. Więc jeśli te dane są ważne, powinieneś mieć ich kopię zapasową zamiast samych nagłówków woluminów (klucz główny).

A uszkodzenie danych rozprzestrzenia się niewiele (16 bajtów), co jest akceptowalne dla większości zastosowań.

Tak więc zły blok na środku partycji lub dysku wpłynie tylko na ten blok. A kilka błędów bitowych w sektorze jest ograniczone do tego sektora i nawet nie wpłynie całkowicie na sektor 512 bajtów.

Aktualizacja (23.01.2017): dodaj więcej informacji na podstawie komentarzy PO.

Poniżej zebrałem kilka informacji na temat odporności kontenerów VeraCrypt / TrueCrypt.

Od uszkodzenia danych Veracrypt :

TC / VC przechowują nagłówek woluminu w dwóch miejscach: na początku i na końcu woluminu. Ten na początku jest główny, a ten na końcu służy do tworzenia kopii zapasowych. Ten mechanizm jest zwykle wystarczający, aby umożliwić dostęp, gdy część dysku jest uszkodzona lub uszkodzona, ponieważ uszkodzenie jest często lokalne. jeśli uszkodzenie nastąpi zarówno na początku, jak i na końcu dysku, wówczas dysk prawie na pewno jest martwy.

Pamiętaj, że w przypadku uszkodzenia lub uszkodzenia dysku nastąpi taka sama utrata danych, jak w przypadku braku szyfrowania. Oznacza to, że nawet jeśli jesteś w stanie zamontować wolumin, odczyt danych może być uszkodzony. Dlatego zawsze myśl o tworzeniu kopii zapasowych danych, ponieważ szyfrowanie nie chroni przed uszkodzeniem danych.

Z FAQ VeraCrypt :

Co się stanie, gdy część wolumenu VeraCrypt zostanie uszkodzona?

W zaszyfrowanych danych jeden uszkodzony bit zwykle psuje cały blok tekstu zaszyfrowanego, w którym wystąpił. Rozmiar bloku tekstu zaszyfrowanego używanego przez VeraCrypt wynosi 16 bajtów (tj. 128 bitów). Tryb pracy używany przez VeraCrypt zapewnia, że ​​jeśli uszkodzenie danych nastąpi w bloku, nie wpłynie to na pozostałe bloki.

Co mam zrobić, gdy zaszyfrowany system plików na moim wolumenie VeraCrypt jest uszkodzony?

System plików w wolumenie VeraCrypt może ulec uszkodzeniu w taki sam sposób, jak każdy normalny niezaszyfrowany system plików. Gdy tak się stanie, możesz użyć narzędzi do naprawy systemu plików dostarczonych z systemem operacyjnym, aby go naprawić. W systemie Windows jest to narzędzie „chkdsk”. VeraCrypt zapewnia łatwy sposób korzystania z tego narzędzia na wolumenie VeraCrypt: Kliknij prawym przyciskiem myszy zamontowany wolumin w głównym oknie VeraCrypt (na liście dysków) iz menu kontekstowego wybierz polecenie „Napraw system plików”.

Małe uszkodzenie danych powinno wtedy mieć jedynie efekt lokalny i nie zniszczy całego kontenera. Jednak odradzam szyfrowanie całego woluminu / partycji, a zwłaszcza dysku systemowego, ponieważ odzyskiwanie może być wtedy bardziej skomplikowane. Zrób dobre kopie zapasowe, szczególnie dla nagłówka woluminu. I pamiętaj, że tak jak w przypadku prawdziwego dysku lub folderu, uszkodzenie nagłówków dysku / pliku może utrudniać odzyskiwanie danych i może wymagać zaawansowanych narzędzi.

Uważam, że LUKS nie ma drugiego nagłówka na dysku, więc musisz być jeszcze bardziej ostrożny przy tworzeniu kopii zapasowej.

Dzięki wszystkim odpowiedziom udzielonym przez ludzi ostateczna odpowiedź jest w 100% kompletna.

Obecnie nie mam dużo czasu, więc później zmienię „własną” odpowiedź. Ponieważ wszystkie odpowiedzi udzielone przez ludzi są całkowicie przydatne, będzie to tylko podsumowanie tego, co powiedzieli, a także moich ustaleń.

Tak czy inaczej, oto jedno z moich ustaleń, które obalą wiele nieporozumień, które spotkałem, i dotyczyły głównie ... co oznacza blok, ponieważ jest to termin, który jest zbyt i błędnie używany:

https://sockpuppet.org/blog/2014/04/30/you-dont-want-xts/

Znajdziesz tu także „standardowy” sposób mówienia o różnych sprawach i unikanie zamieszania „blokowego”:

https://superuser.com/questions/1176839/what-are-every-possible-names-of-hard-drives-structure-parts

Krótko mówiąc, możesz zmienić zaszyfrowany blok zawierający słowo „400” na „800”. Oznacza to, że zaszyfrowana warstwa na poziomie bloku jest całkowicie niestabilna, zamiast wierzyć, że „będzie to działało jak normalny system plików” (np. FAQ Veracrypt).

Powinienem też natknąć się na ten link dwa miesiące temu:

https://unix.stackexchange.com/questions/321488/full-image-of-internal-hdd-drive-dd-dd-rescue-with-truecrypt-bad-sectors/

Ponieważ VeraCrypt jest widelcem TrueCrypt, z pewnością będzie działać tak samo.

PS:

Każda dodatkowa odpowiedź jest nadal mile widziana i zostanie dodana do mojej „własnej” odpowiedzi.