TrueCrypt stał się praktycznie jednym ze standardów szyfrowania dysków. Nie wystarczy jednak z niego skorzystać, by zaszyfrowane dane automatycznie stały się bezpieczne. Trzeba jeszcze pamiętać o tym, by korzystać z niego w odpowiedni sposób.
Nie wiemy, czy Ross Ulbricht, założyciel serwisu Silk Road, korzystał z TrueCrypta. Wiemy jednak, że FBI celowo czekało z jego aresztowaniem na moment, kiedy w miejscu publicznym, ze swojego komputera, nawiąże komunikację z jednym ze swoich współpracowników. Dlaczego FBI na tym zależało i jakie wiąże się z tym ryzyko dla użytkowników TrueCrypta?
Gdzie leżą klucze
Program szyfrujący, umożliwiający dostęp do zabezpieczonych plików w sposób przezroczysty dla systemu operacyjnego, musi gdzieś przechowywać klucze, umożliwiające odszyfrowanie danych. Nie wykluczamy, że specjalistyczne oprogramowanie, używane przez np. służby specjalne, może korzystać z kluczy znajdujących się na kartach mikroprocesorowych czy w dedykowanych modułach kryptograficznych, jednak najpopularniejsze programy takie jak TrueCrypt, PGP, FileVault czy BitLocker klucze trzymają w pamięci RAM. A skoro klucze znajdują się w pamięci komputera, to można je stamtąd odzyskać.
Wyciąganie kluczy
Na rynku dostępne są komercyjne narzędzia takie jak Elcomsoft Forensic Disk Decryptor czy Passware Kit Forensic, które potrafią znaleźć klucze szyfrujące zarówno w plikach hibernacji jak i zrzutach pamięci systemu czy też odnaleźć je w działającym systemie poprzez port FireWire.
Ekran wyboru źródła danych (źródło: Elcomsoft)
Wkrótce jednak zostanie opublikowane darmowe narzędzie, znacznie ułatwiające śledczym zebranie informacji o wolumentach TrueCrypta.
Autorzy Volatility, darmowych skryptów w Pythonie służących do analizy pamięci, stworzyli nowy skrypt, którego efekt działania wygląda następująco:
$ python vol.py -f WIN-QBTA4959AO9.raw --profile=Win2012SP0x64 truecryptsummary
Volatility Foundation Volatility Framework 2.3.1 (T)
Process TrueCrypt.exe at 0xfffffa801af43980 pid 2096
Kernel Module truecrypt.sys at 0xfffff88009200000 - 0xfffff88009241000
Symbolic Link Volume{52b24c47-eb79-11e2-93eb-000c29e29398} -> \Device\TrueCryptVolumeZ mounted2013-10-11 03:51:08 UTC+0000
Symbolic Link Volume{52b24c50-eb79-11e2-93eb-000c29e29398} -> \Device\TrueCryptVolumeR mounted2013-10-11 03:55:13 UTC+0000
File Object \Device\TrueCryptVolumeR\$Directory at 0x7c2f7070
File Object \Device\TrueCryptVolumeR\$LogFile at 0x7c39d750
File Object \Device\TrueCryptVolumeR\$MftMirr at 0x7c67cd40
File Object \Device\TrueCryptVolumeR\$Mft at 0x7cf05230
File Object \Device\TrueCryptVolumeR\$Directory at 0x7cf50330
File Object \Device\TrueCryptVolumeR\$BitMap at 0x7cfa7a00
File Object \Device\TrueCryptVolumeR\Chats\Logs\bertha.xml at 0x7cdf4a00
Driver \Driver\truecrypt at 0x7c9c0530 range 0xfffff88009200000 - 0xfffff88009241000
Device TrueCryptVolumeR at 0xfffffa801b4be080 type FILE_DEVICE_DISK
Container Path: \Device\Harddisk1\Partition1
Device TrueCrypt at 0xfffffa801ae3f500 type FILE_DEVICE_UNKNOWN
Narzędzie to potrafi przeszukać plik zrzutu pamięci i odnaleźć w nim ślady użycia TrueCrypta. Znajduje zarówno datę podpięcia zaszyfrowanego dysku do systemu jak i ścieżkę, w której znajduje się plik lub napęd. Z kolei drugi skrypt potrafi zidentyfikować użyty w TrueCrypcie rodzaj szyfrowania i zlokalizować w pamięci odpowiedni klucz
$ python vol.py -f WIN-QBTA4.raw --profile=Win2012SP0x64 truecryptmaster -D . Volatility Foundation Volatility Framework 2.3.1 (T) Container: \Device\Harddisk1\Partition1 Hidden Volume: No Read Only: No Disk Length: 7743733760 (bytes) Host Length: 7743995904 (bytes) Encryption Algorithm: SERPENT Mode: XTS Master Key 0xfffffa8018eb71a8 bbe1dc7a8e87e9f1f7eef37e6bb30a25 ...z.......~k..% 0xfffffa8018eb71b8 90b8948fefee425e5105054e3258b1a7 ......B^Q..N2X.. 0xfffffa8018eb71c8 a76c5e96d67892335008a8c60d09fb69 .l^..x.3P......i 0xfffffa8018eb71d8 efb0b5fc759d44ec8c057fbc94ec3cc9 ....u.D.......<. Dumped 64 bytes to ./0xfffffa8018eb71a8_master.key
Problem znany, ale trudny do rozwiązania
Oczywiście przechowywanie kluczy w pamięci komputera jest znanym problemem, opisanym w dokumentacji TrueCrypta. Jak zaznaczają autorzy dokumentacji, w momencie odłączania dysków klucze szyfrujące są usuwane z pamięci komputera, jednak w momencie uruchomienia procesu hibernacji, nagłego odłączenia zasilenia lub wykonania resetu komputera program nie ma możliwości przeprowadzenia tej operacji, zatem klucze pozostają w RAMie.
Jak zabezpieczyć się przed atakiem na klucze szyfrujące? Po stronie samego bezpieczeństwa IT jedyną istotną rekomendacją jest wyłączenie funkcji hibernacji. Można także oczywiście ustawić automatyczne odłączanie dysków po minucie nieaktywności, jednak raz, że jest to bardzo uciążliwe (pewnie zmienicie na 10 minut następnego dnia), a dwa – rozsądny biegły na miejscu zdarzenia od razu podejmie czynności, zanim upłynie minuta. Warto w każdym razie rozważyć aktywowanie różnych opcji odłączania dysków.
Opcje odłączania dysków w TrueCrypcie
Co zatem pozostaje? Pewnie tylko bezpieczeństwo fizyczne, czyli nie podłączanie dysków w miejscu, gdzie ktoś może Was odciągnąć od komputera w ciągu kilku sekund i zadbanie o to, by włączony komputer z podłączonymi partycjami nie pozostawał ani na chwilę bez opieki (jak prawdopodobnie miało to miejsce w przypadku Anakaty z The Pirate Bay).
Silne hasło przegrywa z kluczem do kół
Jak wiadomo, silne hasło jest niezbędne, a najlepszym narzędziem do jego wydobycia jest klucz do kół. Co prawda nie wiemy, czy Syed Hussain, podejrzany w Wielkiej Brytanii o terroryzm faktycznie zapomniał swojego hasła do danych zaszyfrowanych na dysku USB (prawdopodobnie mógł korzystać z TrueCrypta), ale wiemy, że w jego zapewnienia nie uwierzył sędzia, który wsadził go na kilka miesięcy do więzienia, by odświeżyć mu pamięć. Wezwani eksperci z GCHQ nie podołali problemowi.
Kiedy po 11 miesiącach w areszcie Hussain usłyszał nowe zarzuty, tym razem o oszustwa finansowe, znienacka przypomniał sobie, że hasło brzmi $ur4ht4ub4h8. Na odszyfrowanym dysku nie znaleziono śladów związanych z terroryzmem, lecz były tam dane finansowe, stanowiące cenne dowody w zakresie zarzutów o oszustwa. Wniosek płynący z tego incydentu: $ur4ht4ub4h8 było dobrym hasłem, ale niestety teraz jest już w zbyt wielu słownikach.
Komentarze
Przecież osoby, którym naprawdę zależy na poufności swoich danych wiedzą o tym od dawna i hibernację wyłączają.
A ja tam nie wiem i mam hibernację włączoną. :] Ba, powiem więcej, ten artykuł mnie nie przekonał bym hibernację wyłączył? Niby po co?
A co z Windowsem 8? Z tego co czytałem ma on domyślnie włączoną hibernację plików systemowych dzięki czemu start Ósemki jest tak szybki.
Czegoś nie kumam. To jeżeli zrestartuje kompa przyciskiem reset to klucz dalej pozostaje w ramie ?
http://www.hotfix.pl/dane-z-pamieci-ram-mozna-odzyskac-nawet-po-wylaczeniu-komputera-n7315.htm
A to było dwa lata temu, wiec pewne jest ze ów technologia jest już bardziej dostępna i zapewne bardziej efektywna :)
owa technologia
To jeszcze zalezy od typu RAM. DDR3 jest „bezpieczniejszy” niż DDR2: http://www.deepdotweb.com/jolly-rogers-security-guide-for-beginners/cold-boot-attacks-unencrypted-ram-extraction/
Może to i fajnie na obrazku wygląda kiedy masz do czego się odnieść, teraz spróbuj zrekonstruować hasło i klucz szyfrujący, których nie znasz… Mi się wydaje, czy zmiana 1 bita w kluczu czyni dane nie do odzyskania? Ile bitów zostało zmienionych na obrazkach?
przy resecie haselko odczytasz ale przy shoutdown zostaje juz usuwane z pamieci
Przy resecie, to jest duże prawdopodobieństwo, że klucz i hasło zostaną nadpisane.
Śmieszne jest to powtarzanie mitów o odczycie kluczy z pamięci RAM. Gdyby ktoś przeczytał dokładnie przeprowadzone badania gdzie odzyskiwali dane z RAMu po odcięciu zasilania to by sobie zdał sprawę, że udawało im się to głownie ze względu na typ pamięci RAM jaki był używany w tych doświadczeniach. A były to pamięci RAM DDR II. Posiadają one właśnie tą wadę, że długo trzymają napięcie po odcięciu zasilania. Ten czas pozwalał na wyjęcie ich z MOBO, wsadzenie do ciekłego azotu i odczytu zawartości. W przypadku pamięci RAM DDR III, które mają znacznie krótszy czas pełnego rozładowania napięcia ( rzędu kilku sekund), proponowane rozwiązanie nie zdaje egzaminu.
Dlatego też sprawdzcie jakie macie pamięci RAM i w razie czego ciągnąc za kabel. W miejscu publicznym podpiąć lapcia do sieci elektrycznej i wyciagnać baterię ;)
żeby nie być gołosłownym – tu jest opisywana publikacja: http://citpsite.s3-website-us-east-1.amazonaws.com/oldsite-htdocs/pub/coldboot.pdf
Zajrzyjcie sobie do tabelek zawierających hardware platform testowych.
a to http://www.youtube.com/watch?v=erq4TO_a3z8 ?
hop plug? przecież to nie ma żadnego zwiazku z tematem. Hot plug służy do podtrzymania źródła zasilania by móc przenieść komputer lub zabezpieczyć go przed wyłączeniem. Mouse jigler dodatkowo by komputer nie wszedl w stan uśpienia. Ni jak sie to nie ma do sytuacji w której zdarze pociągnać za kabel.
Wczytaj się dokładnie w dokumentację przeprowadzonego ataku i z łatwością odkryjesz, że oprócz metody schładzania pamięci opisana została metoda korekcji takich błędów powstających po odłączeniu zasilania. Odtworzony został m. in. klucz AES, w którym siedem (a nie jeden) bitów się zmieniło i zajęło to 20 minut. Szacują, że odzyskanie klucza AES ze zmienionymi 11 bitami zajęłoby 10 dni. Całkiem nieźle biorąc pod uwagę, że 11 bitów w 2048-bitowym kluczu AES to 0,54%, a w badaniu uzyskali najwyżej 0,18% błędnych bitów po schłodzeniu pamięci.
to co zuca sie od razu to brak duzych liter co jeszcze jedynie 12 znakow, jesli jest sie w grupie ryzyka czyli podejrzanym o terroryzm to na bank nsa dalo bruttala i tutaj przy ich mocy obliczeniowej to 11 miesiecy to az nad to by sie do tego dokopac
Niby tylko 12 znaków i bez dużych liter a i tak taki słownik zajmuje 8388607 Terabajtów wordlista. Powodzenia w jego łamaniu (zakładając że zna się długość hasła i jakie znaki w nie wchodzą)
nie trzeba znac jego dlugosci , powyzej juz 8 znakow dlugosc lamania wzrasta symetrycznie ale majac dostep do centralnych jednostek w nsa zlamanie takowego w ciagu 11 miesiecy to pewnik
HOT KEY dla Force Dismount ALL, Wipe Cache & Exit.
np. ctrl win alt P albo aby zadziałało 1 ręką ctrl win alt Z
Ułamek sekundy jak jest się przy komputerze na odmontowanie wszystkiego
Liberte Linux ma wbudowaną taką funkcjonalność – czeka na odłączenie nośnika z którego został zbootowany – jeśli taka akcja wystąpi, to cały RAM jest nadpisywany:
https://github.com/mkdesu/liberte/blob/master/src/etc/init.d/memwipe
https://github.com/mkdesu/liberte/blob/master/src/usr/local/sbin/kexec-load
czyli teoretycznie aplikacja uruchomiona zdalnie na komputerze ofiary odczyta klucz z ram?
tak
a jak w kontekscie tych informacji trzyma sie LUKS?
Zaraz, przecież po zahibernowaniu jest wyłączana całość.
Jak odhibernowuję system, to i tak muszę podać klucz, bo zrzut pamięci (hiberfil.sys) jest na zaszyfrowanym dysku.
Czy to chodzi o sytuację, w której nie ma pełnego szyfrowania całego twardziela?
Są też inne tryby, np „hybrid sleep” albo standby, gdzie nie ma pełnego wyłączenia żeby powrót do trybu normalnej pracy był szybki.
Procesor jest zatrzymany, grafika i dyski powyłączane ale pamięć aktywna, tylko na obniżonym zegarze – więc potencjalnie można zamrozić i wydłubać sekrety.
Ja mam na myśli stricte kompletną hibernację, z wyłączeniem całego komputera.
Drogi Sekuraku, sporo się słyszy o TrueCrypcie, a czy można prosić o kompleksowy artykuł o jakości zabezpieczeń, podatnosci na złamanie i np o przechowywanie kluczy ale w aspekcie standaru LUKS ? dzieki i myślę ze więcej czytelników by było zainteresowane
Albo porównanie z OTRS i innymi podobnymi rozwiązaniami, bo może któreś jest wyraźnie lepsze?
WPISUJCIE MIASTA, KTURE SOM ZA!!!!11!
Litości! „Drogi Sekuraku?” – przecież to inna strona niż sekurak!
„Rośnie symetrycznie”? Chyba wykładniczo!
Jak tak dalej pójdzie to komentarze na onecie będą bardziej merytoryczne… :(
Chesteroni: Sodoma!
A tak w ogóle to po co się zastanawiacie jak długo klucz jest przechowywany w pamięci RAM, skoro służby nie mają powodu odciagania was od komputera?
Zacznijmy od tego, że osobę, która musi zabezpieczać swoje dane przez TC lub tym podobne, stać na jakiekolwiek inne rozwiązanie.
Klucz do sukcesu pokazało wam thepiratebay. Kupujecie magazyn danych w chmurze, szyfrujecie go, ustawiacie odpowiednie blacklist i whitelist. Następnie kupujecie serwer-router, który jako jedyny może przekierować połączenie do serwera z danymi. Połączenie szyfrujecie i tunelujecie. Do routera możecie sobie nawet podpiąć domenę. Nie musicie korzystać z TORa tylko z np. OpenVPNa aby utrudnić namierzenie połączenia. Ot i cała filozofia. Każdy może znaleźć router ale znalezienie serwerów jest już prawie nie możliwe (a przynajmniej jeszcze nikt nie odkrył lokalizacji serwerów TPB, założyciele się chwalą, że nawet serwerodawca nie wie, co znajduje się na jego serwerze). Możecie potem dodać serwer backupowy, na który serwer macierzysty prześle dane i podda się autodestrukcji jeśli np. nie wykonacie przy połączeniu odpowiedniej kombinacji ruchów myszką itp. Podobne mechanizmy opracowywałem kilka-kilkanaście lat temu i są one wyjątkowo skuteczne. Wystarczy wam wtedy tylko laptop z internetem, który nie ma żadnych danych. Brak danych brak dowodów. Nie potrzebne są wam klucze, nie potrzebna wam jest klawiatura (można na serwer wbudować klawiaturę ekranową bądź posłużyć się jeszcze innym wymyślnym mechanizmem – uruchomcie wyobraźnie).
czyli nowe jabłka są bezpieczne? (RAM wlutowany)
Niby czemu? zanurzasz jabłuszko w azocie, odkrecasz obudowe i podpinasz sie pod nózki. Nie trzeba wyjmować ;)
To się chyba nie uda. Pamięć w tych urządzeniach nie jest wlutowana w formie całych modułów SODIMM, tylko jako pojedyncze kostki SMD.(http://cdn1.appleinsider.com/teardown-120613-2.jpg) Złącza są pod kośćmi, nie ma opcji „podłączenia” się do nich. z wierzchu. Podłączanie się do pojedynczych ścieżek na płycie? Za dużo czasu.
Chyba, że masz dedykowane złącze, pasujące akurat to tego mobo.
A moim zdaniem, w dużej części, szukaniem kluczy zajmują się kopacze bitcoinów. Moc obliczeniowa jest ogromna i hasło odzyskiwane jest w kilka minut.