Forum Debian Users Gang

[quote=Elizabeth]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.[/quote]
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).

[quote=Elizabeth]i czemu "ułatwieniem", co to za różnica ?[/quote]
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.

[quote=Elizabeth]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[/quote]
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

[quote=Jacekalex]Google do Andka stworzyło mechanizm ext4-crypt, jest te z ostatnio w Linuxie.

https://github.com/gdelugre/ext4-crypt[/quote]
[b]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.[/b] xD

[quote=Elizabeth]Moim celem jest zmniejszanie powierzchni ataku a nie zwiekszanie jej.[/quote]
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.

[quote=Elizabeth]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)[[/quote]
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

[quote=Elizabeth]no wlasnie u mnie sie tak da, ja przy obecnej konfiguracji moge calkowicie zneutralizowac skutki skompromitowania partycji rozruchowej bez potrzeby przeszyfrowywania calego dysku...[/quote]
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

[quote=Elizabeth]bo ten dodatkowy klucz (/boot/keyfile.gpg) moge w kazdej chwili zmienic :)[/quote]
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