LUKS hasło przestało działać po rozładowaniu laptopa

[freeman]

Witam serdecznie,

mam bardzo bardzo duży problem. Zainstalowałem sobie system Ubuntu 14.04 (standardowa instalacja wraz z szyfrowaniem dysku).
Pewnego dnia wstrzymałem działanie systemu (suspend) i laptop w tym czasie się rozładował. Po ponownym uruchomieniu komputera hasło, które wpisywałem wielokrotnie i którego jestem pewny na 100% nie działa.
Co robić, szy jest szansa na odzyskanie danych?

Pewne dane, które mogą się przydać:

Kod: Zaznacz cały

freeman@freeman:~$ sudo cryptsetup -v luksDump /dev/sda5
LUKS header information for /dev/sda5

Version:        1
Cipher name:    aes
Cipher mode:    xts-plain64
Hash spec:      sha1
Payload offset: 4096
MK bits:        512
MK digest:      60 88 7c 28 18 69 31 42 ce 4d 64 a0 20 9f f1 95 fb 03 e6 9b 
MK salt:        26 e8 60 b4 55 7b bd c6 8a 0c 2c 23 a3 9a 38 b2 
                cd 5a 77 7e 45 ba 68 e1 ae 52 ce 8c f9 e9 70 8c 
MK iterations:  35250
UUID:           d7431ab7-c761-4e7f-a1b9-5d7bc77f20cd

Key Slot 0: ENABLED
        Iterations:             140968
        Salt:                   3b 86 ac 53 70 70 1e 84 06 fc 7f 9b 16 bc ac 14 
                                c0 6a 7f a6 18 10 3c 81 a7 9d d4 95 4d 3f 2a f8 
        Key material offset:    8
        AF stripes:             4000
Key Slot 1: DISABLED
Key Slot 2: DISABLED
Key Slot 3: DISABLED
Key Slot 4: DISABLED
Key Slot 5: DISABLED
Key Slot 6: DISABLED
Key Slot 7: DISABLED
Command successful.

Jakby coś trzeba było jeszcze udostępnić to piszcie

[infort]

Przede wszystkim, co to znaczy hasło przestało działać? Istotny jest komunikat błędu przy próbie otwarcia partycji za pomocą cryptsetup luksOpen wykonanej z systemu liveusb.

Uszkodzenie nagłówka szyfrowanej partycji może się zdarzyć w przypadku błędu zapisu na HDD. Jest to sprawa na tyle rzadka, że jeszcze się realnie z czymś takim w swojej pracy nie spotkałem, a szyfrowaniem zajmuję się już dobrych kilka lat. Niemniej jest to możliwe, dlatego bezwzględnym zaleceniem w przypadku szyfrowania dysku jest posiadanie aktualnej kopii zapasowej. No chyba, że dane są nieistotne.
Na 99% bład wynika ze złego wpisania hasła lub ustawienia niewłaściwej strony kodowej klawiatury. Pytanie zatem, czy używałeś w haśle jakichkolwiek nietypowych znaków, w tym polskich liter?

[freeman]

Nie używałem polskich znaków w haśle. Hasło ma tylko znaki łacińskie i cyfry.
MOje próby wpisania hasła:
1) po uruchomieniu komputera system prosi mnie o hasło, podaje je ale trzymuje błąd, że cryptsetup nie mógł odszyfrować danych, złe hasło (przepraszam ale dokładniego błędu nie potrafię przytoczyć)
2) udało mi się uruchomić ubuntu z innego dysku twardego. Na tym ubuntu próbuje podmonotwać zaszyfrowaną partycję poprzez krusadera lub domyślny manager plików oraz przez konsolę i zawsze otrzymuje ten sam błąd:
No key available with this passphrase.

[infort]

Próby podmontowania szyfrowanej partycji zawsze wykonuje się z liveusb systemu o zgodnym kernelu po zainstalowaniu tej samej wersji cryptsetup, która była użyta do utworzenia partycji.

Jako root:

Kod: Zaznacz cały

cryptsetup luksOpen /dev/sda5 mapowana_nazwa

i następnie:

Kod: Zaznacz cały

mount /dev/mapper/mapowana_nazwa pełna_ścieżka_do_mapowanego_folderu

Jeśli w odpowiedzi na pierwsze polecenie dostaniesz ponownie błąd No key available with this passphrase i jesteś pewny, że hasło jest dobre, to przy spełnieniu warunków wymienionych na początku albo masz niezgodność keyboard layout (ustaw taki, jaki był przy szyfrowaniu) albo uszkodził Ci się nagłówek LUKSa. W tym drugim przypadku szanse na odzyskanie danych są bliskie zeru (naprawa nagłówka wymaga wiedzy, cierpliwości i dużo szczęścia a i tak rzadko kiedy się udaje), prościej będzie je odtworzyć z kopii zapasowej.

Jak ktoś kiedyś mądrze powiedział, jesli dane są warte zaszyfrowania, tym bardziej są warte zrobienia backupu.

[freeman]

Chyba trace juz nadzieje na to, ze ten dane uda sie odzyskac. Dzisiaj rano zgralem na pendrive ubuntu 14.04 z iso z ktorego instalowalem system wiec cryptsetup i kernel powinien byc taki sam.
Niestety proba podmontowania dysku skonczyla sie tym samym bledem.

Co mnie zastanawia to to, ze polecenie repair zwrocilo mi bardzo ladny log informujacy mnie, ze wszystko jest OK. Czy moge gdzies znalezc dowod informujacy mnie, co zostalo uszkodzone?

Kod: Zaznacz cały

ubuntu@ubuntu:~$ sudo cryptsetup repair  /dev/sda5 --debug
# cryptsetup 1.6.1 processing "cryptsetup repair /dev/sda5 --debug"
# Running command repair.
# Locking memory.
# Installing SIGINT/SIGTERM handler.
# Unblocking interruption on signal.
# Allocating crypt device /dev/sda5 context.
# Trying to open and read device /dev/sda5.
# Initialising device-mapper backend library.
# Trying to load LUKS1 crypt type from device /dev/sda5.
# Crypto backend (gcrypt 1.5.3) initialized.
# Reading LUKS header of size 1024 from device /dev/sda5
# Key length 64, device size 499615744 sectors, header size 4036 sectors.
No known problems detected for LUKS header.
# Releasing crypt device /dev/sda5 context.
# Releasing device-mapper backend.
# Unlocking memory.
Command successful.

Oprocz suspend i rozladowania komputera to drugim podejrzanym jest to, ze przez ~okolo 1 miesiaca nie restartowalem systemu i przynajmniej dwukrotnie byl tam update jadra. Zastanawiam sie czy to tez moze byc przyczyna.

[enedil]

A nie aktualizowałeś jądra w systemie? W tym wypadku powinieneś zaktualizować kernel do tej samej wersji na Live CD, panie Bartłomieju.

[freeman]

@enedil
jądro było aktualizowane, ale nie był robiony restart systemu po jego aktualizacji. Stąd IMHO miałem taką wersję jądra jaką otrzymałem na instalacji. System za długo nie gościł na moim komputerze miał około 40 dni.

[infort]

W takim razie problemem jest zapewne niezgodność initramfs. W przypadku aktualizacji jądra wymagane jest powtórne utworzenie tego pliku. W szyfrowanych systemach aktualizacja poprzez update-initramfs jest kluczowa, jako że zawiera on niezbędne struktury obsługujące kryptografię. W przypadku niezgodności, w razie jakiejkolwiek manipulacji na nagłówku szyfrowanej partycji efekty są nie do przewidzenia. Jednym z nich wydaje się odrzucanie poprawnego hasła. Spróbuj zaktualizować to jądro i utwórz ponownie initramfs, jest wtedy jakaś szansa, że hasło zaskoczy.