Analiza APFS. Na co się przygotować?

forensictools.pl 6 lat temu

Analiza APFS potrafi przysporzyć nieco problemu, bo choć od premiery High Sierra, czyli macOS 10.13, minęło już kilka miesięcy, nowy system plików może być wyzwaniem. W tym krótkim tekście będziemy starali się podpowiedzieć co nieco na ten temat.

Na początek przyjrzyjmy się różnicom pomiędzy szyfrowaniem z wykorzystaniem Filevault 2 i HFS.

Analiza APFS i HFS a różnice w sposobie szyfrowania

HFS nie posiada natywnego wsparcia dla szyfrowania. Do zabezpieczania danych w wolumenach HFS wykorzystywana jest dodatkowa warstwa zwana CoreStorage. CoreStorage to logiczny system zarządzania wolumenami obecny w macOS, szyfrujący dane na poziomie bloków. jeżeli będziesz chciał je odblokować, CoreStorage stworzy nowe urządzenie logiczne zawierające cały, nieszyfrowany system plików HFS , w tym niezalokowaną przestrzeń, jako jeden ciągły blok. W momencie obrazowania odczytywane są wszystkie bloki woluminu HFS w stanie odszyfrowanym. APFS nie wymaga dodatkowej warstwy zabezpieczeń, czyli wykorzystania CoreStorage. Aktywowanie FileVault po prostu włącza wbudowaną w APFS obsługę szyfrowania i szyfruje dane na poziomie systemu plików. W związku z tym „odblokowanie” woluminów APFS nie powoduje utworzenia nowego urządzenia logicznego, które należy odczytać celem pozyskania odszyfrowanych danych. Dobrze radzi sobie z tym BlackLight. Zarówno CoreStorage jak i APFS wykorzystują szyfrowanie XTS-AES-128. Jednakże APFS używa losowo generowanych drugorzędnych kluczy szyfrujących, podczas gdy CoreStorage wykorzystuje identyfikator UUID. W związku z tym, iż UUID w CoreStorage nie jest losowy, można go zidentyfikować. Co za tym idzie APFS można uznać za odporniejszy na ataki kryptograficzne.

Mam hasło do FileVault 2 i nie mogę odszyfrować plików

Do odszyfrowania plików w APFS wymagane są następujące informacje:

  • 128 bitowy klucz szyfrowania wolumenu
  • 128 bitowy drugorzędny klucz szyfrowania
  • Oryginalny „numer bloku” danego pliku

Każdy wolumen w kontenerze APFS wykorzystuje unikatowe klucze szyfrujące wolumenu oraz drugorzędne. Gdy plik zostaje usunięty przez użytkownika, powiązane z nim bloki danych zostają zwolnione. Prowadzi to do sytuacji, w której nie jest możliwe przypisanie niezaalokowanego bloku danych z powrotem do jego oryginalnego wolumenu. Dlatego na tę chwilę ustalenie kluczy szyfrujących, które mogłyby zostać użyte przez informatyka śledczego do poprawnego odszyfrowania danych, jest niemożliwe.

Całość staje się jeszcze bardziej skomplikowana w przypadku przeniesienia zaszyfrowanych bloków danych w inne miejsce. W takim przypadku dane nie są szyfrowane na nowo, a oryginalny numer bloku musi być znany jeżeli chcielibyśmy je odszyfrować. Ponieważ nieprzydzielone bloki pozostają zaszyfrowane wewnątrz puli logicznego konteneru, carving danych będzie nieskuteczny bo nie będzie możliwe rozpoznanie sygnatur plików znajdujących się w ich nagłówkach. jeżeli rozpoczniemy carving danych, wynik z dużym prawdopodobieństwem będzie fałszywie dodatni bądź będzie to fragment pliku, który został utworzony przed zaszyfrowaniem woluminu.

A gdyby tak wyłączyć FileVault 2?

W APFS wyłączenie FileVault 2 odszyfrowuje metadane systemu plików i zaalokowane bloki w wolumenie. Nieprzydzielone bloki, które zostały już zwolnione do puli konteneru, nie zostaną odszyfrowane. Dzieje się to dlatego, iż bloki nie są już w tym momencie powiązane z woluminem, który je zaszyfrował. W CoreStorage wolumeny HFS są szyfrowane na poziomie bloku, a nie na poziomie systemu plików. Zatem wyłączenie FileVault pozwoli na odszyfrowanie wszystkich danych, również przestrzeni niezaalokowanej. Warto zwrócić uwagę, iż pliku usunięte już po wyłączeniu FileVault z wolumenów APFS, mogą zostać odzyskane ponieważ dane te nigdy szyfrowane nie były. Jak widzicie High Sierra niesie ze sobą sporo problemów. Zastanawia nas, jakie są Wasze doświadczenia. Mieliście już do czynienia z „makami” w wersji 10.13?

Idź do oryginalnego materiału