Forum Debian Users Gang

olej to , reklama, marketing, propaganda zwał jak zwał, przemysłowe dyzie nie maja takich ficzerów to znaczy, że to po prostu tani chwyt reklamowy z dodaniem badziewnej chińszczyzny ala układ TPM :)

wsparcie sprzętowe dla AES w procesorach to chyba jest już od dawna oczywistość

a ja tam pierdole AES-a to nie wiem :)

Jak już pisałem polecam otwarte standardy

Ostatnio edytowany przez hi (2018-03-01 22:01:49)

hi napisał(-a):

Szyfrowanie AES metodą 256-bitową

Dyski SU700 obsługują szyfrowanie AES metodą 256-bitową

lepiej szukaj proca, który ma wsparcie dla AES (standard w nowych klocach) i szyfruj LUKS-em z wykorzystaniem AES-a (osobiście i tak wolę Twofish, mega wydajny i otwarty standard symetryka)

I drugie pytanie: co to jest "System reserved" w Windowsie (to zaznaczone czerwoną strzałką) ?  Czy to jest odpowiednik partycji /boot ?

taaa taaa to każdy windows od 7> robi sobie taką wydzieloną partycję, śmieszne no ale cóż windows to windows (w linuksie oddzielna partycja /boot jest zakładana tylko przy szyfrowaniu, masz tam initrd i bootloadera i jest to jedyny niezaszyfrowany obszar dyzia)

Mój laptop jak przyszedł do mnie to też miał tak dziwnie podzielony dysk, tj. miał dwie partycje pod win (małą i dużą). Ja to usunąłem i bez problemu się win zainstalował na jednej. Także ta mała jest pewnie opcjonalna ale wymagane jest by wtedy na dużej była flaga boot, inaczej się system nie zainstaluje.

Elizabeth napisał(-a):

I na marginesie: czy da się ominąć hasło biosu bez usunięcia go tak żeby ofiara nic nie zauważyła ?

Chyba się nie da, ale i tak zawsze można wyjac dysk i zbootowac z innego komputera wiec tak
czy inaczej lepiej przeniesc rozruch na dysk zewnetrzny.

Da się — wystarczy ustawić inne hasło i ofiara zawsze pomyśli, że zapomniała hasła i to zawsze działa. xD

Partycja recovery była osobno i jeszcze do tego była jakaś partycja z narzędziami HP. Więc w sumie było ich 4 (wszystkie podstawowe). Wywaliłem je i utworzyłem jedną na wina. xD Ja też mam obrazy recovery i HP tools zgrane ale nigdy z nich nie korzystałem.

a potem gdy juz caly system zostanie skompromitowany to najlepiej wziąść master key:

"6.10 How do I recover the master key from a mapped LUKS container?"

na wypadek gdyby okresowo było zmieniane hasło

LUKS2 ma to zabezpieczenie względem LUKS1, że keyring kernela nie tylko przechowuje już hasło do kontenera ale również i klucz główny i żaden użytkownik, nawet root, nie jest w stanie wydobyć klucza szyfrującego z działającej maszyny, no za wyjątkiem zrzutu pamięci. xD

Nigdy nie używałem skryptu decrypt_gnupg i nie mam pojęcia jak on działa i co ma robić. xD A crypttab to taki fstab tylko dla zaszyfrowanych kontenerów, by system wiedział w fazie initramfs/initrd co ma robić. Ten plik jest kopiowany do obrazu initramfs/initrd i później cryptsetup czy inne narzędzia Debiana wiedzą co mają ze zdefiniowanymi tam partycjami zrobić.

Nie rozumiem, przecie i tak musisz to hasło wpisać. Co za różnica czy będzie to hasło do kontenera czy do klucza gpg? Jak będzie keylogger to ci przechwyci hasło i później bez problemu będzie można odszyfrować kluczem ten keyfile i przy jego pomocy odblokować kontener. Dla mnie nie ma tu zbytnio różnicy, tylko proces jest bardziej skomplikowany i wydłużony. Wszystkie instrukcje jak odszyfrować dysk są w obrazie initrd, także dla mnie ta zabawa jest pozbawiona sensu. xD

No to po co się bawić w gpg, jak piszesz, że partycję rozruchową wyciągasz "tylko na moment na czas rozruchu lub aktualizacji"? Dalej moim zdaniem GPG jest zupełnie zbędny. xD

Da się,da się, tylko klucz powinien siedzieć nie  na partycji rozruchowej, ale na Pendraku.

No ale właśnie chodzi o to, że masz dwa przypadki:

1. hasło do gpg, które odszyfrowuje automatycznie keyfile i ten kefile jest używany do odblokowania kontenera
2. hasło do kontenera, które odblokowuje kontener (standardowe)

Nie widzisz tutaj, że tak czy inaczej masz to hasło, którego przechwycenie == kompromitacja zaszyfrowanych danych? xD

O to mi cały czas chodzi, że tak czy inaczej musisz podać hasło, tylko ty dodatkowo jeszcze GPG w to mieszasz czyniąc procedurę bardziej skomplikowaną ale nie dla keyloggera, którego zadaniem jest odczytać hasło. Jeśli atakujący uzyska hasło do klucza GPG, to będzie w stanie odszyfrować keyfile i użyć go do odblokowania kontenera, tak czy nie, czy mi coś ucieka? xD

A myślisz, że uzyskanie keyfile przy takiej konfiguracji jak ty masz jest jakimś problemem? xD Jeśli chcesz w miarę komfortowo otwierać system, to keyfile gdzieś musi leżeć a instrukcje do jego wydobycia/wskazania są zaszyte w initrd, także go nie schowasz, nie ważne jak bardzo tego chcesz. xD Keyfile przydaje się jedynie gdy nośnik danych, na którym on rezyduje jest bezpieczny (np. zaszyfrowana partycja), ty akurat korzystasz z zaszyfrowanego kluczem GPG keyfile, i bezpieczeństwo keyfile zależy tylko i wyłączenie od hasła do klucza GPG, jak je napastnik złamie, to masz i tak pozamiatane. Także nadal nie przekonuje mnie ten setup. xD

morfik napisał(-a):

Jeżeli zostawiasz kompa w domu a zaszyfrowany keyfile nosisz cały czas ze sobą to jest to poważne utrudnienie dla atakującego, ponieważ prosty keylogger sprzętowy na klawiature (albo np. nagranie kamerą jak wpisujesz hasło) nie wystarcza aby dostać się do danych.

Mówisz o policji? Bo akurat trzymanie nawet zaszyfrowanego keyfile przy sobie, gdy napastnik poznał hasło jest tylko ułatwieniem życia napastnikowi. xD

Ten pomysł sobie rozkmiń:
https://forum.dug.net.pl/viewtopic.php?pid=318130#p318130

Ostatnio edytowany przez morfik (2018-03-04 21:32:34)

Elizabeth napisał(-a):

Miałam tu na myśli raczej kogoś kto chce uzyskac dostęp do danych w sposób dyskretny gdy np. nie ma cię w domu. Ja np. często prodróżuje i nie mam wszystkich swoich komputerów zawsze przy sobie.

No jak uzyska hasło to zdobycie keyfile mu raczej nie zajmie dużo czasu, bo jakoś dał radę zdobyć to hasło (ma fizyczny dostęp do kompa).

Elizabeth napisał(-a):

i czemu "ułatwieniem", co to za różnica ?

No taka, że keyfile nie powinien być trzymany pod ręką, a jak ktoś zna twoje hasło to ma również ten twój keyfile. xD Lepiej sobie przerób fona na token uwierzytelniający, bo te nowe androidy (jeśli mają poprawnie wdrożone szyfrowanie sprzętowe) sprawią, że dostanie się do pliku nagłówka LUKS (czyli w ogóle samego klucza szyfrującego) jest prawie że nie możliwe i takie kombinacje jak ty robisz są jeszcze mniej podniecające. xD

Jak masz telefon, który jest wspierany przez otwartoźródłowy ROM, np. AOSP lub coś na jego bazie, gdzie nie masz bloatware od producenta telefonu, od producenta systemu (google) i od operatora GSM, to masz w zasadzie czystego linux'a dostosowanego do pracy z telefonem. Ten system niczym nie różni się od zwykłego linux'a, którego używasz na co dzień, a skoro używasz zwykłego linuxa, to raczej nic nie stoi na przeszkodzie by używać AOSP. Kluczowe w przypadku bezpieczeństwa są aktualizacje systemu, a to, że producenci telefonów tego nie robią, to nie znaczy, że możesz winić Androida za to. To mniej więcej tak, jakby wziąć płytkę z debian live, powiedzmy jakiś old-oldstable i czepiać się debiana, że system na tej płytce ma całą masę podatności np. w przeglądarce. xD

Idąc dalej, od androida 6.0 chyba każdy telefon musi wspierać sprzętowe szyfrowanie tego co się znajduje na partycji /data/ , czyli dane użytkownika. To jak jest zabezpieczony telefon, zależy już od producenta sprzętu. Mój telefon np. ma błędnie zaimplementowane sprzętowe szyfrowanie i nie bierze pod uwagę klucza użytkownika przy tworzeniu klucza głównego (tego, którym są szyfrowane dane) — jest tylko wykorzystywany klucz dedykowanego czipa w telefonie i fraza "default_password". Niemniej jednak, gdyby to szyfrowanie sprzętowe było poprawnie zaimplementowane, to bez hasła użytkownika nie można by się dobrać do danych na flash'u telefonu, gdy telefon jest wyłączony. Gdy telefon działa kolei, to chroni go blokada ekranu, a tu można zastosować np. biometrię w połączeniu z długim hasłem. Póki co biometria działa tak se  ja bym na niej się nie opierał zbytnio jeśli chodzi o zabezpieczenia ale to z czasem pewnie ulegnie poprawie. To co jednak można zrobić we własnym zakresie, to zaimplementować sobie coś na wzór "wrong pin shutdown", czyli wpisujesz powiedzmy 2x błędne hasło i telefon się wyłącza. To ma tę zaletę, że po uruchomieniu systemu nie działa biometria i odblokowanie ekranu/telefonu trzeba dokonać podając hasło, a to już może być długie. Póki co nie ma też możliwości określenia błędnych prób przy odcisku palca ale biometrię można sobie całkowicie wyłączyć.

Ta aplikacja USB Mountr udostępnia obraz tylko na żądanie i trzeba pierw odblokować telefon by ten obraz mógł być użyty do interakcji z innymi urządzeniami. Czyli obraz partycji boot z nagłówkami LUKS sobie rezyduje zaszyfrowany do momentu aż odblokujesz sobie telefon i w aplikacji załadujesz obraz. To z kolei sprawia, że nawet jak atakujący przechwyci telefon, to nie ma dostępu do nagłówków LUKS, hasła, keyfile i nawet bootloader'a. W ten sposób atak na komputer jest limitowany jedynie do zrzutu pamięci, bo uzyskanie hasła nic ludziom nie da, gdyż klucz szyfrujący dane nie znajduje się na dysku komputera, tylko siedzi sobie zaszyfrowany w obrazie na telefonie. xD Podobnie ataki na bootloader czy też initramfs/initrd również już nie przyniosą żadnego rezultatu.

Elizabeth napisał(-a):

chociaż wadą byłoby to że nie mogłabym tak łatwo zmienić klucza, gdybym podejrzewała że sam pendrive
został skompromitowany, bo trzebaby przeszyfrować cały dysk

Klucza zmienić nie możesz, możesz zmienić jedynie hasło. Jak ty sobie wyobrażasz zmienienie klucza szyfrującego dane "w trakcie", gdy już dane na dysku są zaszyfrowane? Jak zmienisz klucz, to nie odszyfrujesz tych danych, które zostały zaszyfrowane innym kluczem. Jedynie co to można skorzystać z cryptsetup-reencrypt ale to wymaga przeszyfrowania całego dysku i to nie ma znaczenia czy nagłówek LUKS jest na dysku czy leży sobie osobno gdzieś indziej. xD

Jacekalex napisał(-a):

Google do Andka stworzyło mechanizm ext4-crypt, jest te z ostatnio w Linuxie.

https://github.com/gdelugre/ext4-crypt

Warning: this kernel feature is very unstable and experimental at the moment. I managed to crash my kernel (4.1.2) a few times very easily just by playing with it. xD

Elizabeth napisał(-a):

Moim celem jest zmniejszanie powierzchni ataku a nie zwiekszanie jej.

No to ci pokazałem, że nagłówki LUKS wraz z całym initramfs/initrd leżą zaszyfrowane do momentu, gdy chcesz ich użyć — to limituje atak jedynie do zrzutu pamięci komputera po odszyfrowaniu dysku, czyli podczas pracy systemu.

Elizabeth napisał(-a):

W scenariuszu który proponujesz odszyfrowany master key może zostać bez problemu przechwycony przez:

a) developera aplikacji USB Mountr (sam developer tej apliakcji jest chyba w tym wypadku najmniej
zaufanym ogniwem, ale moze to subiektywna opinia, w kazym razie pierwszy raz o nim slysze)

b) dostawce systemu na ktorym dziala telefon (wprawdzie to jądro linuxa, ale na tej samej zasadzie malo ufam np. chińskiemu deepinowi czy innym dziwnym dystrybucjom - trojany mogą być w całej otoczce systemu dostarczanej w ramach dystrybucji)

c) producenta sprzętu na ktorym dziala telefon

d) producenta sprzętu i twórców systemu na ktorym dziala komputer

tak przy okazji: kontrola nad rozruchem daje też teoretycznie możliwość dowolnej ingerencji w dzialanie systemu wiec mowimy tu nie tylko o samym ryzyku przechwycenia klucza ale o znacznie wiekszym ryzyku (np. zdalnej kradziezy danych, podlaczenie do botnetu czy takie tam xD)[

Co do punktu A:
Obraz jest udostępniany ze smartfona, a dopiero na kompie cryptsetup odczytuje nagłówki LUKS i to na kompie wpisujesz hasło do odszyfrowania klucza głównego. W tych operacjach smartfon nie bierze żadnego udziału. A to, że przechowuje sobie nagłówek LUKS z zaszyfrowanym kluczem głównym, to jest dokładnie taka sama sytuacja jak twój komp/pendrive by przechowywał nagłówek LUKS, czyli tak 99,9% przypadków korzystania z FDE. W przypadku smartfona jednak, nośnik na którym jest przechowywany nagłówek jest szyfrowany z wykorzystaniem szyfrowania sprzętowego w przeciwieństwie do kompa/pendrive, gdzie nie ma żadnego szyfrowania i tym to rozwiązanie ze smartfonem wygrywa.

Reszta punktów jest oczywiście nieadekwatna, bo widać nie rozumiesz jak działa ten mechanizm ale chyba teraz masz już zarysowane światełko w tunelu. xD Idąc dalej, zainteresuj się AOSP/LOS:
https://source.android.com/
https://www.lineageos.org/

No i oczywiście zapraszam na GH, gdzie masz źródła Mountr, bo widać, to że ten projekt jest również opensource, też ci umknęło. xD
https://github.com/Streetwalrus/android_usb_msd

Elizabeth napisał(-a):

no wlasnie u mnie sie tak da, ja przy obecnej konfiguracji moge calkowicie zneutralizowac skutki skompromitowania partycji rozruchowej bez potrzeby przeszyfrowywania calego dysku...

Co się da? Zmienić klucz szyfrujący dane podczas, gdy już masz zaszyfrowane powiedzmy 100G na dysku? Naprawdę? Jak ty możesz to przez logikę przepuścić? xD Przecie te stare pliki są zaszyfrowane innym kluczem i jak wskażesz kernelowi by przemapował obszar partycji i "zdeszyfrował" te pliki na niej tym nowym kluczem, to ci syf zwróci. Naprawdę. xD

Elizabeth napisał(-a):

bo ten dodatkowy klucz (/boot/keyfile.gpg) moge w kazdej chwili zmienic :)

Eeee ale keyfile to nie jest klucz główny szyfrujący dane na dysku!!!!! To jest "plik klucz", który robi za hasło odszyfrowujące klucz główny, dokładnie w taki sam sposób działa hasło wpisywane z klawiatury, tylko że tu wskazujesz plik i masz częściową ochronę przed keyloggerem, bo po to ten mechanizm został wymyślony, no i by nie trzeba było wpisywać długich haseł, bo się można pomylić. xD