Forum Debian Users Gang

robert93 · 2019-10-07 22:33:35

Witam
Dotychczas uzywalem windows7 + veracrypt dla FDE
Czy istnieje podobne 100% rozwizanie w debianie ?

Przegladajac forum https://forum.dug.net.pl/viewtopic.php?pid=298062#p298062
okazuje sie ze rozwiazanie FDE podczas instalacji systemu Debian nie zapewnia 100% skutecznosci szyfrowania(..??). Z tego co jest tam napisanie jeszcze dodatkowo by trzeba zaszyfrowac /boot/ zeby ktos nie odczytal mojego hasla albo przenesienie headersow na pendrive(i co mam go chowac czy tez ponownie zaszyfrowac), troche to bez sensu w porownaniu do fde z veracrypt 'a.
Pewnie cos mieszam w rozumowaniu ale tak to rozumiem.
Znacie jakies dobre rozwiazanie do fde na debianie, najlepiej z poradnikiem jak to zrobic?

Ostatnio edytowany przez robert93 (2019-10-07 22:38:38)

morfik · 2019-10-07 22:55:36

Obecnie jak masz Grub'a to możesz i boot zaszyfrować:
https://cryptsetup-team.pages.debian.net/cryptsetup … ted-boot.html

Ale to rozwiązanie póki co działa tylko z LUKSv1 i nie wiadomo kiedy Grub dorobi wsparcie dla tego LUKSv2.

loms · 2019-10-07 23:00:30

Przy szyfrowaniu partycji systemowej dm-crypt/LUKS nie można szyfrować i nie ma potrzeby szyfrować partycji boot (nie ma na niej nic poufnego).
Nie należy tworzyć partycji wymiany swap bo tam mogą być poufne dane, ostatecznie można umieścić ją w pliku na zaszyfrowanej partycji.
Ja od wielu lat mam taki układ partycji, który ustawiam przy instalacji Debiana:

robert93 · 2019-10-07 23:10:20

loms czyli sugerujesz ,ze morfik nie ma racji ?

loms · 2019-10-07 23:17:03

robert93 napisał(-a):
loms czyli sugerujesz ,ze morfik nie ma racji ?

Nie mam pojęcia o czym on pisze, wkleja linki, które podsuwa mu wyszukiwarka. Nie chce mi się tych informacji weryfikować.

morfik · 2019-10-08 00:09:34

Ponawiam prośbę do administracji by zbanować tego loms'a. Pliss... xD

Bodzio · 2019-10-08 06:57:13

morfik napisał(-a):
Ponawiam prośbę do administracji by zbanować tego loms'a. Pliss... xD

Zrobione. Nie Ty jeden pisałeś na PW

robert93 · 2019-10-08 12:03:55

Witam :)
morfik nie wszystko dokadnie rozumie :( , lecz chciabym miec takie szyfrowanie fde ktore gwarantuje veracrypt pod windowsem.
Jak bys mogl mnie naprowadzic na jakis poradnik czy tutorial typu "Explain to me like I'm 5" (moze byc po angielsku byle do piecolatkow) xD

morfik · 2019-10-08 16:08:29

No ale ja nie wiem co veracrypt pod windowsem gwarantuje — mógłbyś wyjaśnić? xD

Zgodnie z tym co piszą tutaj[1]. to grub oferuje chyba dokładnie ten sam poziom, z tym, że ograniczony jedynie do LUKS v1. Ja jakiś czas temu opracowałem o wiele lepszy mechanizm bezpieczeństwa[2], bo wyprowadziłem całą partycję /boot/ wraz z nagłówkami zaszyfrowanych partycji poza dysk główny — do zaszyfrowanego telefonu. W ten sposób nie ma możliwości nawet poznać, że dysk jest zaszyfrowany, a już nie wspominając o możliwości jego zdeszyfrowaniu. To się przydaje, gdy chcesz pojechać za granice i obawiasz się, że będą ci chcieli kompa przeszukać. xD Także ośmieliłbym się powiedzieć, że cryptsetup jest lepszy od veracrypt. xD

[1]: https://www.veracrypt.fr/en/Encryption%20Scheme.html
[2]: https://gist.github.com/morfikov/0bd574817143d0239c5a0e1259613b7d

Ostatnio edytowany przez morfik (2019-10-08 16:25:57)

BlackEvo · 2019-10-08 20:21:16

Ja szyfruje caly dysk, oprocz /boot ktory jest na osobnej partycji (BTRFS) a cala reszta dysku to szyfrowany LVM ( F2FS) ( SSD). Jesli ktos wyciagnie dysk to tez nie widac na nim zadnych partycji oprocz tej jednej. Uwazam to za zensowne rozwiazanie, wg mnie nawet praktyczniejsze, niz dzielenie na 'fizyczne' woluminy i potem traktowanie LUKS'em. Tak mam na lapku, na PC mam podobnie i tutaj dochodza 2 HDD 'wpiete' pod LVM i widoczne jako jedna wielka dostepna przestrzen. Nie jest to zaden serwer itp, wiec RAID sobie odpuscilem, ale na domowe sprawy sie sprawdza.

Przykladowy poradnik LVM+LUKS to np: https://www.youtube.com/watch?v=wShiEsQtSsE

Moze nie tyczy sie typowo Debiana, ale sam LUKS i zasada pozostaja niezmienne.

Pozdrawiam

morfik · 2019-10-08 20:38:33

Ale przecież luks się zdradzi w binarnej analizie -- on ma nagłówek, który można bez problemu odszukać. To raz, a dwa, jak masz nieszyfrowany /boot/ to tam masz informacje dotyczące jak ten dysk systemowy odszyfrować, więc nawet binarnej analizy nie trzeba by zobaczyć, że jednak coś tam jest schowane. xD

Ostatnio edytowany przez morfik (2019-10-08 20:39:06)

BlackEvo · 2019-10-08 20:53:25

@morfik
Jesli mieliby sie bawic tym specjalisci od analizowania danych np FBI ( ups, teraz mnie obserwuja skoro to napisalem xD ) i inne nawet rodzime, to pewnie jakos by to zlamali. Szczerze? nie popadam w skrajnosc, nie nosze na glowie pod czapka folii aluminiowej xD i nie owijam nia przedmiotow elektronicznych :)
Szyfruje np lapka, bo mam bardzo mobilna robote, laptop czesto zostaje w aucie i jak jakis 'cFaniak' buchnie, to raczej nie ogarnie o co tutaj chodzi, bo przeciez nawet nie ma Windows'a. Odepnie, sformatuje itp i tyle. Laptop ma kilkanascie lat, a backup robiony w miare na bierzaco ;)

Btw...mozesz mi podac info, jak taki zielony user ( lamer ) jak ja, moglby sobie zobaczyc, gdzie widnieje info "dotyczące jak ten dysk systemowy odszyfrować" ? ;) - tak z czystej...dziennikarskiej nazwijmy to...ciekawosci ;)

morfik · 2019-10-08 21:30:29

Nie muszą się bawić tym specjaliści -- to standard przy analizie danych. Nie trzeba nawet uzyskiwać dostępu do danych, wystarczy informacja, że szyfrujesz, a luks tej informacji nie zataja, a nawet ją świadomie ujawnia, by rozmaite narzędzia były w stanie interpretować pewne rzeczy. Dlatego jeśli ktoś tę informację chce zataić, to albo musi używać czystego dm-crypt i podawać klucz szyfrujący i wszystkie pozostałe metadane ręcznie, albo musi wyprowadzić nagłówki wraz z initramfs/initrd poza szyfrowany dysk.

Dziś się już nie "kradnie zaszyfrowanych danych" w celu późniejszej próby złamania szyfru, tylko podrzuca jakiś syf nieświadomej osobie, by ona wszelkie niezbędne informacje do odszyfrowania tych danych podała dobrowolnie. Potem cię odwiedzają goście w czarnych garniakach i tyle z twojego szyfrowania. xD

A co do info? To rozpakuj sobie initramfs/initrd, który jest na partycji boot i poszukaj /etc/crypttab -- w końcu jakoś twój system znajduje te "ukrytą" zaszyfrowaną partycje i nie robi tego pytając wróżki. xD

BlackEvo · 2019-10-08 22:47:00

"Jak to miło madrego po szkole posluchac" ;)

EDIT:

Ok, nie daje mi to spokoju, a czlowiek uczy sie cale zycie, wiec pytanko/a ;)

Zeby w moim przypadku poznac jaka metoda szyfruje, gdzie trzymam klucz ( keyfile ) to...trzeba by chocby wylistowac /etc/fstab i mamy wieszkosc info poczawszy od UUID woluminu - OK
Zeby poznac moje haslo skladajace sie ze 128 losowych znakow nalezaloby odpytac dm-crypt ( dmsetup table --showkeys ) - OK

Wszystko, jak na dloni. Ale...to przy znajomosci chocby hasla root'a ( tak to rozumiem ) - prawda? :)
Czy...jedyna w miare bezpieczna opcja, to 'wyciagnac' np keyfile 'na zewnatrz'? ( np pendrive ) :)

Ostatnio edytowany przez BlackEvo (2019-10-08 23:06:36)

robert93 · 2019-10-08 23:04:44

BlackEvo napisał(-a):
"Jak to miło madrego po szkole posluchac" ;)

Pozdro

Witam
I co tam zobaczyles ?
Jest haslo?

BlackEvo · 2019-10-08 23:07:02

robert93 napisał(-a):
BlackEvo napisał(-a):
"Jak to miło madrego po szkole posluchac" ;)

Pozdro
Witam
I co tam zobaczyles ?
Jest haslo?

Nie.

robert93 · 2019-10-08 23:47:59

BlackEvo napisał(-a):
"Jak to miło madrego po szkole posluchac" ;)

EDIT:

Ok, nie daje mi to spokoju, a czlowiek uczy sie cale zycie, wiec pytanko/a ;)

Zeby w moim przypadku poznac jaka metoda szyfruje, gdzie trzymam klucz ( keyfile ) to...trzeba by chocby wylistowac /etc/fstab i mamy wieszkosc info poczawszy od UUID woluminu - OK
Zeby poznac moje haslo skladajace sie ze 128 losowych znakow nalezaloby odpytac dm-crypt ( dmsetup table --showkeys ) - OK

Wszystko, jak na dloni. Ale...to przy znajomosci chocby hasla root'a ( tak to rozumiem ) - prawda? :)
Czy...jedyna w miare bezpieczna opcja, to 'wyciagnac' np keyfile 'na zewnatrz'? ( np pendrive ) :)

morfik Z tego co zrozumialem to:
1 nie da sie zlamac hasla (wystarczajaco silnego) kradnac wylaczonego laptopa
2 mozna wczescniej cos tam podinstalowac zeby ofiara sama podala nam haslo jesli widoczny jest /boot/ czy program rozruchowy o mam, atak sprzataczki https://security.stackexchange.com/questions/159173 … l-maid-attack
Chyba veracrypt po rozruchu sprawdza hash programu bootujacego i to chyba jest najbardziej optymalne rozwiazanie, zamiat przenoszaenia rozruchu na pena
3 O co chodzi z tymi naglowkami, ktore widac ? Moglbys podac jakies przyklady? np. mam plik tekstowy "HaslaGmail" i co z tego widac, albo jakis program firefox.exe

Ostatnio edytowany przez robert93 (2019-10-08 23:54:39)

morfik · 2019-10-09 02:45:50

BlackEvo napisał(-a):
Zeby poznac moje haslo skladajace sie ze 128 losowych znakow nalezaloby odpytac dm-crypt ( dmsetup table --showkeys ) - OK

Wszystko, jak na dloni. Ale...to przy znajomosci chocby hasla root'a ( tak to rozumiem ) - prawda? :)
Czy...jedyna w miare bezpieczna opcja, to 'wyciagnac' np keyfile 'na zewnatrz'? ( np pendrive ) :)

W dmsetup znajdował się odszyfrowany klucz szyfrujący dane w kontenerach. Po to właśnie (między innymi) wymyślili LUKSv2, by już żaden user (nawet root) nie był w stanie wyciągnąć klucza szyfrującego w działającym systemie — już ich nie ma w `dmsetup table --showkeys`. Same klucze zaś zostały przeniesione do keyring'a kernela, co znacznie poprawiło bezpieczeństwo tych kluczy szyfrujących. O hasło/keyfile trzeba zadbać sobie samemu, żeby nic go nie przechwyciło, np. jakiś keyloger zaszyty w MBR/MBR-GAP. Dlatego jedyną bezpieczna opcją jest wyprowadzenie całego bootloader'a wraz z nagłówkami zaszyfrowanych partycji na osobny nośnik i odpalanie kompa z niego, tak jak ja to sobie zrobiłem z telefonem.

robert93 napisał(-a):
morfik Z tego co zrozumialem to:
1 nie da sie zlamac hasla (wystarczajaco silnego) kradnac wylaczonego laptopa

Da się — po to są klastry graficzne i właśnie po to stworzyli LUKSv2, by uzbroić hasła do kluczy szyfrujących w argon2. Np. moje kontenery do odszyfrowania wymagają 1GiB RAM i każdy wątek do łamania hasła będzie skutkował alokowaniem 1 GiB RAM i łamanie hasła przy pomocy klastrów graficznych staje się już wysoce nieefektywne. xD Dlatego jak tylko wprowadzili ten LUKSv2, to ja od razy na niego zmigrowałem, podobnie mam z keepassxc, który również oferuje zbrojenie haseł przy pomocy argon2.

robert93 napisał(-a):
2 mozna wczescniej cos tam podinstalowac zeby ofiara sama podala nam haslo jesli widoczny jest /boot/ czy program rozruchowy o mam, atak sprzataczki https://security.stackexchange.com/questions/159173 … l-maid-attack
Chyba veracrypt po rozruchu sprawdza hash programu bootujacego i to chyba jest najbardziej optymalne rozwiazanie, zamiat przenoszaenia rozruchu na pena

Nie wiem co veracrypt tam robi, bo ja go nigdy nie miałem zainstalowanego. Niby jest free i opensource ale do debiana z pewnych względów on nie trafił i nie trafi. Podobnie było z truecrypt. Kiedyś testowałem truecrypt na tę podatność z podmienieniem bootloader'a i działało, a sam truecrypt żadnych ostrzeżeń nie wyrzucał i hasło było można bez problemu wyciągnąć. Czy jakieś usprawnienia dorzucili w veracrypt, tego nie wiem — trzeba by sprawdzić. Niemniej jednak, zrobienie sobie obrazu z partycji /boot/ i wyprowadzenie go poza dysk zawsze jest bezpieczne. xD

robert93 napisał(-a):
3 O co chodzi z tymi naglowkami, ktore widac ? Moglbys podac jakies przyklady? np. mam plik tekstowy "HaslaGmail" i co z tego widac, albo jakis program firefox.exe

No bo teraz jest zagrożenie terrorystyczne i tylko terroryści szyfrują dane. xD I jak się przemieszczasz, to możesz trafić na wrednych ludzi, którzy będą chcieli sprawdzić co masz na kompie, np. na granicy. A ty powiesz im, że masz zaszyfrowanego kompa albo oni napotkają prompt'a o hasło przy starcie systemu i poproszą cię o nie, albo zostaniesz oskarżony o terroryzm. xD Jak ja bym podróżował z moim lapkiem i fonem, to lapka mam w zasadzie czystego, a w fonie bym sobie wyzerował partycję boot i recovery (sposób tylko dla mediatek'ów), tak by fon się już nie uruchomił. Potem po przyjeździe w docelowe miejsce, obrazy partycji boot i recovery bym z neta pobrał i wgrał na fona i już jestem gotów do wysadzania WTC z mojego zaszyfrowanego debiana. xD A jak masz nagłówki LUKS na dysku, to zawsze je znajdą, nawet jak powiesz, że nie szyfrujesz. :] Tu[1] sobie poczytaj o tym "problemie".

[1]: https://gitlab.com/cryptsetup/cryptsetup/wikis/Freq … urity-aspects

Ostatnio edytowany przez morfik (2019-10-09 02:49:10)

blind · 2019-10-09 06:38:16

morfik napisał(-a):
Da się — po to są klastry graficzne

Jeśli masz odpowiednio silne hasło, to prędzej dojdzie do naturalnej śmierci wszechświata niż je złamią. To chyba wypełnia definicję "nie da się".

Ostatnio edytowany przez blind (2019-10-09 06:43:17)

morfik · 2019-10-09 12:10:03

Da się. xD

blind · 2019-10-09 17:13:52

Mógłbyś to jakoś bardziej uargumentować? Jestem bardzo ciekaw, co masz na myśli pisząc, że się da.

Dla zabawy ja podam przykład:

16 znakowe hasło składające się z małych i dużych liter, cyfr i znaków specjalnych daje 95^16 możliwych kombinacji. Jedyna informacja jaką znalazłem na temat szybkości łamania haseł pochodzi z 2012 roku i mówi o 350 bilionach prób na sekundę na które pozwolił klaster składający się z 25 kart graficznych. Zaokrąglijmy to sobie do 1 000 bilionów kombinacji na sekundę i pomnóżmy razy 1000, bo w końcu mamy 2019 rok. 25 kart graficznych to też mało imponująca liczba, więc pomnóżmy sobie wszystko jeszcze razy 1 000. Takim sposobem mamy klaster składający się z 25 tysięcy kart, każda 1000 szybsza niż te z 2012. Dość optymistycznie. Taki klaster da nam tryliard (nie mylić z trylionem) czyli 10^21 haseł na sekundę.

Podzielmy więc sobie :

95^16 / 10^21 = 44 012 666 865 sekund

czyli w przybliżeniu 1 395 lat. Cofamy się do czasów Mahometa, który wątpię aby dysponował takim sprzętem i cierpliwością. :D

Ostatnio edytowany przez blind (2019-10-09 17:24:53)

Jacekalex · 2019-10-09 17:23:24

czyli w przybliżeniu 1 395 lat. Cofamy się do czasów Mahometa, który wątpię aby dysponował takim sprzętem i cierpliwością. :D

Nie zapomnij, że Amazon i kilka innych firm oferują niemałe chmurki obliczeniowe, które można najmować na godziny,
natomiast booty hakerskie czasem mają dostęp nie do jednego, ale do paru mln procesorów i GPU.
Wtedy 1400 lat podziel np przez milion kompów, i łamanie hasełka robi się już realne.

blind · 2019-10-09 17:55:03

Jacekalex napisał(-a):
Wtedy 1400 lat podziel np przez milion kompów, i łamanie hasełka robi się już realne.

No nie, zapominasz, że w poprzednim przykładzie nie użyłem jednego kompa, a klastra składającego się z 25 tysięcy kart, każda 100 razy mocniejsza niż obecne na rynku karty. Oczywiście wszystkie te obliczenia to tylko zabawa, ale żeby z botnetu uzyskać moc taką jak powyższy klaster, to musiałbyś podłączyć 2,5 miliona kompów z nowoczesnymi kartami. Chciałbym zobaczyć rachunek za prąd za te 1400 lat działania takiego botnetu. :)

Ostatnio edytowany przez blind (2019-10-09 17:55:47)

urbinek · 2019-10-09 18:03:39

@blind, uwzględnij, że nie każdy posiada hasło składające się z się z małych i dużych liter, cyfr,znaków specjalnych, krwi dziewicy i futra jednorożca. Sama długość hasła też jest przeważnie krótka.

Dodatkowo uwzględnij, że te wyliczenia tyczą się każdego możliwego hasła, właściwe hasło może być gdzieś na początku albo bliżej środka, statystyki nie oszukasz.

That's being said, skomplikowanie hasła nie ma znaczenia gdy w sofcie znajdą/zaszyją lukę i uzyskają dostęp do twoich danych.

BA, widziałem już metody wyciągania haseł z działających systemów poprzez podpięcie się pod kości RAM na działającym systemie :D

hi · 2019-10-09 18:38:34

loms ale rozpierdol tam masz, u mnie dyzio mechanik:

NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
sda 8:0 0 1,8T 0 disk
├─sda1 8:1 0 487M 0 part /boot
└─sda2 8:2 0 1,8T 0 part
└─sda2_crypt 254:0 0 1,8T 0 crypt
├─deb_crypt-root 254:1 0 18,6G 0 lvm /
├─deb_crypt-swap 254:2 0 7,5G 0 lvm [SWAP]
├─deb_crypt-tmp 254:3 0 976M 0 lvm
├─deb_crypt-var 254:4 0 7,5G 0 lvm /var
└─deb_crypt-home 254:5 0 1,8T 0 lvm /home
sr0 11:0 1 1024M 0 rom

XFS szyfrowany Twofish'em

spróbuj szczęścia na mojej partycji /boot

aha:

Kod:

cat /etc/lilo.conf 
lba32
delay=20
vga=775
boot=/dev/sda
root=/dev/mapper/deb_crypt-root
map=/boot/map
append="edd=off apparmor=1 security=apparmor"
default=Linux
# password=

image=/boot/vmlinuz-5.2.0-3-amd64
    label=Linux
    read-only
    initrd=/boot/initrd.img-5.2.0-3-amd64

kompa na kłódkę trzeba zapiąć jeszcze z uruchamianym samozapalnikiem :) :)

zapraszam :)

Ostatnio edytowany przez hi (2019-10-09 19:12:59)

Forum Debian Users Gang

Ogłoszenie

#1 2019-10-07 22:33:35

robert93 - Użytkownik

FDE Full-Disk Encryption podczas instalacji

#2 2019-10-07 22:55:36

morfik - Cenzor wirtualnego świata

Re: FDE Full-Disk Encryption podczas instalacji

#3 2019-10-07 23:00:30

loms - Użytkownik

Re: FDE Full-Disk Encryption podczas instalacji

#4 2019-10-07 23:10:20

robert93 - Użytkownik

Re: FDE Full-Disk Encryption podczas instalacji

#5 2019-10-07 23:17:03

loms - Użytkownik

Re: FDE Full-Disk Encryption podczas instalacji

robert93 napisał(-a):

#6 2019-10-08 00:09:34

morfik - Cenzor wirtualnego świata

Re: FDE Full-Disk Encryption podczas instalacji

#7 2019-10-08 06:57:13

Bodzio - Ojciec Założyciel

Re: FDE Full-Disk Encryption podczas instalacji

morfik napisał(-a):

#8 2019-10-08 12:03:55

robert93 - Użytkownik

Re: FDE Full-Disk Encryption podczas instalacji

#9 2019-10-08 16:08:29

morfik - Cenzor wirtualnego świata

Re: FDE Full-Disk Encryption podczas instalacji

#10 2019-10-08 20:21:16

BlackEvo - Driver

Re: FDE Full-Disk Encryption podczas instalacji

#11 2019-10-08 20:38:33

morfik - Cenzor wirtualnego świata

Re: FDE Full-Disk Encryption podczas instalacji

#12 2019-10-08 20:53:25

BlackEvo - Driver

Re: FDE Full-Disk Encryption podczas instalacji

#13 2019-10-08 21:30:29

morfik - Cenzor wirtualnego świata

Re: FDE Full-Disk Encryption podczas instalacji

#14 2019-10-08 22:47:00

BlackEvo - Driver

Re: FDE Full-Disk Encryption podczas instalacji

#15 2019-10-08 23:04:44

robert93 - Użytkownik

Re: FDE Full-Disk Encryption podczas instalacji

BlackEvo napisał(-a):

#16 2019-10-08 23:07:02

BlackEvo - Driver

Re: FDE Full-Disk Encryption podczas instalacji

robert93 napisał(-a):

BlackEvo napisał(-a):

#17 2019-10-08 23:47:59

robert93 - Użytkownik

Re: FDE Full-Disk Encryption podczas instalacji

BlackEvo napisał(-a):

#18 2019-10-09 02:45:50

morfik - Cenzor wirtualnego świata

Re: FDE Full-Disk Encryption podczas instalacji

BlackEvo napisał(-a):

robert93 napisał(-a):

robert93 napisał(-a):

robert93 napisał(-a):

#19 2019-10-09 06:38:16

blind - Użytkownik

Re: FDE Full-Disk Encryption podczas instalacji

morfik napisał(-a):

#20 2019-10-09 12:10:03

morfik - Cenzor wirtualnego świata

Re: FDE Full-Disk Encryption podczas instalacji

#21 2019-10-09 17:13:52

blind - Użytkownik

Re: FDE Full-Disk Encryption podczas instalacji

#22 2019-10-09 17:23:24

Jacekalex - Podobno człowiek...;)

Re: FDE Full-Disk Encryption podczas instalacji

#23 2019-10-09 17:55:03