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
6.2 Jak wykonać kopię zapasową nagłówka LUKS?
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.