Nie jesteś zalogowany.
Jeśli nie posiadasz konta, zarejestruj je już teraz! Pozwoli Ci ono w pełni korzystać z naszego serwisu. Spamerom dziękujemy!

Ogłoszenie

Prosimy o pomoc dla małej Julki — przekaż 1% podatku na Fundacji Dzieciom zdazyć z Pomocą.
Więcej informacji na dug.net.pl/pomagamy/.

#51  2018-03-01 21:43:26

  hi - Zbanowany

hi
Zbanowany
Zarejestrowany: 2016-03-24

Re: pełne transparentne szyfrowanie dysku z użyciem dm-crypt

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)


"Są drogi, którymi nie należy podążać, armie, których nie należy atakować, fortece, których nie należy oblegać, terytoria, o które nie należy walczyć, zarządzenia, których nie należy wykonywać" Sun Tzu

Offline

 

#52  2018-03-01 21:56:40

  Elizabeth - Użytkownik

Elizabeth
Użytkownik
Zarejestrowany: 2017-12-27

Re: pełne transparentne szyfrowanie dysku z użyciem dm-crypt

Za jakiś czas będę implementowała własną kryptografie jako drugą warstwę oprócz AES,

ale na razie nie mam czasu.


GPG Key ID: 0x8D55F13761AF5230
Fingerprint: B884 468A D6DC 0516 2B43 6675 8D55 F137 61AF 5230

Offline

 

#53  2018-03-01 22:46:23

  morfik - Cenzor wirtualnego świata

morfik
Cenzor wirtualnego świata
Skąd: ze WSI
Zarejestrowany: 2011-09-15
Serwis

Re: pełne transparentne szyfrowanie dysku z użyciem dm-crypt

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

Offline

 

#54  2018-03-01 23:16:33

  Elizabeth - Użytkownik

Elizabeth
Użytkownik
Zarejestrowany: 2017-12-27

Re: pełne transparentne szyfrowanie dysku z użyciem dm-crypt

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.

A to nie bylo recovery ? Bo gdy komp jest z fabrycznym systemem to jest jeszcze recovery.

Ja sobie obraz recovery zgralam na dysk zewentrzny, bo przy tym co robie z tym kompem jest wielce
prawdopodobne ze uwale wszystko.

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

To skoro i tak trzeba rozkręcać kompa żeby zresetować bios to równie dobrze można odpiąć dysk

mniej kłopotu dla siebie i dla ofiary :)




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


GPG Key ID: 0x8D55F13761AF5230
Fingerprint: B884 468A D6DC 0516 2B43 6675 8D55 F137 61AF 5230

Offline

 

#55  2018-03-02 07:56:51

  morfik - Cenzor wirtualnego świata

morfik
Cenzor wirtualnego świata
Skąd: ze WSI
Zarejestrowany: 2011-09-15
Serwis

Re: pełne transparentne szyfrowanie dysku z użyciem dm-crypt

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

Offline

 

#56  2018-03-03 17:22:44

  Elizabeth - Użytkownik

Elizabeth
Użytkownik
Zarejestrowany: 2017-12-27

Re: pełne transparentne szyfrowanie dysku z użyciem dm-crypt

mam taką zawartosc pliku /etc/crypttab:

sdxx_crypt UUID=xxxxx(...)xxxxx /boot/keyfile.gpg luks,keyscript=/lib/cryptsetup/srcipts/decrypt_gnupg

Czy ja dobrze rozumiem, że zawartość /etc/crypttab jak i plików do których odwoluje sie powyzsza linia (zaszyfrowany keyfile i skrypt)

jest wykorzystywana tylko podczas wywołania update-initramfs -u ?



Pytam bo zmienialam hasla,

na dyskach zewnetrznych normalnie nowy slot i kill slot,

natomiast do systemow mam zaszyfrowany klucz na partycji boot (/boot/keyfile.gpg) i na poczatku myslalam ze wystarczy jedynie przeszyfrowac ten klucz na partycji boot innym haslem (i oczywiscie zamazac stary)


ale to chyba tak nie dziala,

ten klucz nie jest wykorzystywany bezposrednio tylko podczas tworzenia initramfs i on jest potem zaszyty w intitrd.img ?

dobrze mysle ?

Ostatnio edytowany przez Elizabeth (2018-03-03 17:30:11)


GPG Key ID: 0x8D55F13761AF5230
Fingerprint: B884 468A D6DC 0516 2B43 6675 8D55 F137 61AF 5230

Offline

 

#57  2018-03-03 18:58:01

  morfik - Cenzor wirtualnego świata

morfik
Cenzor wirtualnego świata
Skąd: ze WSI
Zarejestrowany: 2011-09-15
Serwis

Re: pełne transparentne szyfrowanie dysku z użyciem dm-crypt

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ć.

Offline

 

#58  2018-03-04 16:12:15

  Elizabeth - Użytkownik

Elizabeth
Użytkownik
Zarejestrowany: 2017-12-27

Re: pełne transparentne szyfrowanie dysku z użyciem dm-crypt

morfik napisał(-a):

Nigdy nie używałem skryptu decrypt_gnupg i nie mam pojęcia jak on działa i co ma robić. xD

Ja to stosuje, bo taki scenariusz szyfrowania to częściowo ochrona przed prostymi sprzętowymi keyloggerami, nie wystarczy zdobycie danych z klawiatury, bo potrzebny jest jest jeszcze klucz z partycji rozruchowej (podwójna autoryzacja)

więc albo potrzebny jest dodatkowy dostęp do partycji rozruchowej (którą wyciągam tylko na moment na czas rozruchu lub aktualizacji) albo bardzo zaawasowany keylogger


GPG Key ID: 0x8D55F13761AF5230
Fingerprint: B884 468A D6DC 0516 2B43 6675 8D55 F137 61AF 5230

Offline

 

#59  2018-03-04 18:22:27

  morfik - Cenzor wirtualnego świata

morfik
Cenzor wirtualnego świata
Skąd: ze WSI
Zarejestrowany: 2011-09-15
Serwis

Re: pełne transparentne szyfrowanie dysku z użyciem dm-crypt

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

Offline

 

#60  2018-03-04 18:38:01

  Elizabeth - Użytkownik

Elizabeth
Użytkownik
Zarejestrowany: 2017-12-27

Re: pełne transparentne szyfrowanie dysku z użyciem dm-crypt

morfik napisał(-a):

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.

No więc o tym piszę, włamywacz musiałby uzyskać jeszcze dostęp do partycji rozruchowej żeby to zrobić.

A więc samo hasło nie wystarczy tylko musi mieć dwie rzeczy na raz.

Będzie musiał mi siłą zabrać partycje rozruchową (to zawsze trudniej xD)

Ostatnio edytowany przez Elizabeth (2018-03-04 18:40:27)


GPG Key ID: 0x8D55F13761AF5230
Fingerprint: B884 468A D6DC 0516 2B43 6675 8D55 F137 61AF 5230

Offline

 

#61  2018-03-04 18:50:57

  morfik - Cenzor wirtualnego świata

morfik
Cenzor wirtualnego świata
Skąd: ze WSI
Zarejestrowany: 2011-09-15
Serwis

Re: pełne transparentne szyfrowanie dysku z użyciem dm-crypt

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

Offline

 

#62  2018-03-04 18:59:23

  Elizabeth - Użytkownik

Elizabeth
Użytkownik
Zarejestrowany: 2017-12-27

Re: pełne transparentne szyfrowanie dysku z użyciem dm-crypt

Przecież jeśli by trzymać klucz w formie odszyfrowanej to wystarczyłoby mieć dostęp do partycji rozruchowej.

Moim zdaniem nie da się tego zrobić prościej jeśli chcesz mieć podwójną autoryzacje (czyli hasło + klucz fizyczny)

Ostatnio edytowany przez Elizabeth (2018-03-04 19:01:42)


GPG Key ID: 0x8D55F13761AF5230
Fingerprint: B884 468A D6DC 0516 2B43 6675 8D55 F137 61AF 5230

Offline

 

#63  2018-03-04 19:37:37

  Jacekalex - Podobno człowiek...;)

Jacekalex
Podobno człowiek...;)
Skąd: /dev/random
Zarejestrowany: 2008-01-07

Re: pełne transparentne szyfrowanie dysku z użyciem dm-crypt

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


W demokracji każdy naród ma taką władzę, na jaką zasługuje ;)
Si vis pacem  para bellum  ;)       |       Pozdrawiam :)

Offline

 

#64  2018-03-04 19:42:48

  Elizabeth - Użytkownik

Elizabeth
Użytkownik
Zarejestrowany: 2017-12-27

Re: pełne transparentne szyfrowanie dysku z użyciem dm-crypt

A partycja rozruchowa jest właśnie na pendraku więc od razu tam można jeszcze dorzucić zaszyfrowany klucz do odszyfrowania dysku :)

trzymanie na innym penie /boot'a a na innym klucza nie zwieksza bezpieczeństwa


GPG Key ID: 0x8D55F13761AF5230
Fingerprint: B884 468A D6DC 0516 2B43 6675 8D55 F137 61AF 5230

Offline

 

#65  2018-03-04 21:06:45

  morfik - Cenzor wirtualnego świata

morfik
Cenzor wirtualnego świata
Skąd: ze WSI
Zarejestrowany: 2011-09-15
Serwis

Re: pełne transparentne szyfrowanie dysku z użyciem dm-crypt

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

Offline

 

#66  2018-03-04 21:15:08

  Elizabeth - Użytkownik

Elizabeth
Użytkownik
Zarejestrowany: 2017-12-27

Re: pełne transparentne szyfrowanie dysku z użyciem dm-crypt

morfik napisał(-a):

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

Nie, w przypakdu 1 przechwycenie hasła != kompromitacja zaszyfrowanych danych, bo jeśli atakujący nie ma keyfile to nic nie zrobi.

morfik napisał(-a):

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

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.


GPG Key ID: 0x8D55F13761AF5230
Fingerprint: B884 468A D6DC 0516 2B43 6675 8D55 F137 61AF 5230

Offline

 

#67  2018-03-04 21:31:41

  morfik - Cenzor wirtualnego świata

morfik
Cenzor wirtualnego świata
Skąd: ze WSI
Zarejestrowany: 2011-09-15
Serwis

Re: pełne transparentne szyfrowanie dysku z użyciem dm-crypt

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)

Offline

 

#68  2018-03-04 21:45:16

  Elizabeth - Użytkownik

Elizabeth
Użytkownik
Zarejestrowany: 2017-12-27

Re: pełne transparentne szyfrowanie dysku z użyciem dm-crypt

A myślisz, że uzyskanie keyfile przy takiej konfiguracji jak ty masz jest jakimś problemem?

To czy jest problemem zależy od pomysłowości właściciela.

Elizabeth 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

Przecież policja to akurat ten typ atakującego, który bez problemu może użyć dużej siły żeby zabrać ci keyfile :)

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.

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

Ostatnio edytowany przez Elizabeth (2018-03-04 21:56:35)


GPG Key ID: 0x8D55F13761AF5230
Fingerprint: B884 468A D6DC 0516 2B43 6675 8D55 F137 61AF 5230

Offline

 

#69  2018-03-04 22:52:35

  morfik - Cenzor wirtualnego świata

morfik
Cenzor wirtualnego świata
Skąd: ze WSI
Zarejestrowany: 2011-09-15
Serwis

Re: pełne transparentne szyfrowanie dysku z użyciem dm-crypt

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

Offline

 

#70  2018-03-05 15:29:21

  Elizabeth - Użytkownik

Elizabeth
Użytkownik
Zarejestrowany: 2017-12-27

Re: pełne transparentne szyfrowanie dysku z użyciem dm-crypt

morfik napisał(-a):

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).

Nie wiem jak według ciebie miałby mi zabrać keyfile ?

Jeśli będzie chciał to zrobić stosując przemoc to ja zawsze mam pod ręką jeszcze sprzętowy eraser.

morfik napisał(-a):

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

Nie zgodzę się z tym xD

morfik napisał(-a):

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

Androidy dobrze zabezpieczone ?

Mi się zawsze wydawało, że te zabezpieczenia w androidach to tylko
taka atrapa którą można ominąć w 5 minut

Faktycznie gdybym przeniosła nagłówki na dysk gdzie jest partrycja rozruchowa to bym nie musiała mieć
tego dodatkowego keyfile, bo master key w nagłówku spełniałby tą samą role.

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


GPG Key ID: 0x8D55F13761AF5230
Fingerprint: B884 468A D6DC 0516 2B43 6675 8D55 F137 61AF 5230

Offline

 

#71  2018-03-05 16:53:37

  morfik - Cenzor wirtualnego świata

morfik
Cenzor wirtualnego świata
Skąd: ze WSI
Zarejestrowany: 2011-09-15
Serwis

Re: pełne transparentne szyfrowanie dysku z użyciem dm-crypt

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

Offline

 

#72  2018-03-05 17:58:00

  Jacekalex - Podobno człowiek...;)

Jacekalex
Podobno człowiek...;)
Skąd: /dev/random
Zarejestrowany: 2008-01-07

Re: pełne transparentne szyfrowanie dysku z użyciem dm-crypt

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

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

Ostatnio edytowany przez Jacekalex (2018-03-05 22:26:11)


W demokracji każdy naród ma taką władzę, na jaką zasługuje ;)
Si vis pacem  para bellum  ;)       |       Pozdrawiam :)

Offline

 

#73  2018-03-05 18:50:48

  morfik - Cenzor wirtualnego świata

morfik
Cenzor wirtualnego świata
Skąd: ze WSI
Zarejestrowany: 2011-09-15
Serwis

Re: pełne transparentne szyfrowanie dysku z użyciem dm-crypt

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

Offline

 

#74  2018-03-07 21:31:03

  Elizabeth - Użytkownik

Elizabeth
Użytkownik
Zarejestrowany: 2017-12-27

Re: pełne transparentne szyfrowanie dysku z użyciem dm-crypt

morfik napisał(-a):

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.

Moim celem jest zmniejszanie powierzchni ataku a nie zwiekszanie jej.

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

Twoja propozycja zwieksza powierzchnie ataku z pkt. d) do wszytskich czterech wyżej wymienionych punktów.

Natomaist dobra polityka bezpieczenstwa powinna zmniejszac powierchnie ataku a nie zwiekszac ją.


Nie chodzi tylko o to ze podmiot odpowiedzialny za dany punkt moze chciec przechwycic
klucz, ale jest to tez zwiekszenie pola do szukania podatnosci przez osoby postronne, dzieki czemu osoba trzecia ma wieksze szanse na zdobycie hasla oraz/lub kontroli nad komputerem. (przykładowo wystarczy że zostanie skompromitowany serwer dostawcy tej aplikacji albo androida i nawet jesli debian bedzie nadal bezpieczny to wszystko szlag trafi)

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)

morfik napisał(-a):

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

no wlasnie u mnie sie tak da, ja przy obecnej konfiguracji moge calkowicie zneutralizowac skutki skompromitowania partycji rozruchowej bez potrzeby przeszyfrowywania calego dysku, bo ten dodatkowy klucz (/boot/keyfile.gpg) moge w kazdej chwili zmienic :)

Ostatnio edytowany przez Elizabeth (2018-03-07 21:50:18)


GPG Key ID: 0x8D55F13761AF5230
Fingerprint: B884 468A D6DC 0516 2B43 6675 8D55 F137 61AF 5230

Offline

 

#75  2018-03-08 13:10:57

  morfik - Cenzor wirtualnego świata

morfik
Cenzor wirtualnego świata
Skąd: ze WSI
Zarejestrowany: 2011-09-15
Serwis

Re: pełne transparentne szyfrowanie dysku z użyciem dm-crypt

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

Offline

 

Stopka forum

Powered by PunBB
© Copyright 2002–2005 Rickard Andersson
Nas ludzie lubią po prostu, a nie klikając w przyciski ;-)