Archiwizacja plików w Linuksie z linii poleceń z zastosowaniem kompresji, redundancji, szyfrowania i uwierzytelniania autentyczności pochodzenia

Kategoria: Artykuły, etykiety: gpg, gnupg, szyfrowanie, archiwizacja, kompresja

Dodany: 2015-02-07 00:15 (zmodyfikowany: 2016-04-10 14:57)
Przez: uzytkownikubunt

Wyświetleń: 14426

Starsza wersja poradnika dostępna pod adresami:

https://archive.is/nssUq

https://web.archive.org/web/20150316032419/https://dug.net.pl/tekst/313/archiwizacja_plikow_w_linuksie_z_linii_polecen_z_zastosowaniem_kompresji__redundancji__szyfrowania_i_uwierzytelniania_autentycznosci_pochodzenia/

W poradniku użyto gpg (GnuPG) 1.4.18, par2cmdline 0.6.11, xz 5.1.0alpha uruchomione na Debianie 8 Jessie

W poniższym poradniku zostanie pokazane jak stworzyć skompresowane archiwum. Następnie zostanie zaszyfrowane za pomocą szyfrowania symetrycznego w trybie CFB. Następnie zostaną stworzone dane naprawcze, dzięki którym będzie można w razie lekkiego uszkodzenia archiwum je odtworzyć, następnie następne dane naprawcze zabezpieczające wcześniej utworzone dane naprawcze. Następnie zostanie ono podpisane, by móc zweryfikować autentyczność pochodzenia archiwum. W międzyczasie zostanie podzielone na mniejsze części, by móc umieścić je na mniejszych nośnikach pamięci lub przesłać poprzez email.

Tryb CFB, a w zasadzie jego wariant, jest domyślnym dla OpenPGP

Dlaczego ktoś chciałby szyfrować pliki blokowym szyfrem symetrycznym? Szyfrowanie uznanym szyfrem symetrycznym jest prostsze dla użytkownika, szybsze dla sprzętu i jednocześnie bezpieczniejsze niż szyfrowanie RSA lub inne metody szyfrowania z użyciem szyfrów asymetrycznych. Wadą jednak jest to, że nie rozwiązuje problemu przesłania do jakiejś osoby danych wymaganych do odszyfrowania szyfrogramu poprzez niezaufane kanały komunikacji m.in. Internet. Jeśli jednak tworzymy sami dla siebie kopię zapasową lub możemy bezpiecznie przekazać hasło osobie, do której zamierzamy w przyszłości wysłać szyfrogram, np będąc z nią sam na sam, wtedy metoda ta jest najlepsza.

Dlaczego tworzyć dane naprawcze? Gdyż dzięki nim można w 100% odtworzyć oryginalne dane z lekko uszkodzonego archiwum. To tym bardziej ważne, gdy stosujemy kompresję xz: nawet zamiana jednego bitu w dowolnym miejscu powoduje, że program xz nie poradzi sobie z wypakowaniem dalszej części archiwum. Jeśli przesyłamy duży plik przez Internet (lub wiele małych plików składających się na duże archiwum), pomimo tego że protokół TCP posiada zdolność do wykrycia większości błędów, możliwość uszkodzenia pliku podczas przesyłania nie jest duża, ale jak najbardziej na tyle duża że można uznać ją za realną. Warto pamiętać, że takie dodatkowe dane naprawcze to nie jest prawdziwy backup. To tylko dodatkowa metoda zabezpieczania. Prawdziwy backup to co najmniej jedna, pełna kopia na niezależnym nośniku/sprzęcie.


Archiwizowanie

Zakładam, że znajduję się w katalogu przeznaczonym do pracy, a w podkatalogu katalogDoZaszyfrowania znajdują się wszystkie pliki, które chcę zaszyfrować.

Opcjonalnie w tym momencie mogę stworzyć nowy plik z losową długością, która zmieni wielkość pliku wynikowego.

dd if=/dev/urandom of=katalogDoZaszyfrowania/plikOLosowejDlugosci bs=$RANDOM count=6

Należy ustawić dla bs taką wartość, by plik wynikowy różnił się od oryginału wystarczająco.

Teraz możemy przystąpić do stworzenia lekko skompresowanego archiwum programem tar i xz:

tar cf - katalogDoZaszyfrowania/ | xz -zf --format=xz -2e --threads=2 - > wiadomosc.tar.xz

Z ciekawych szyfrów blokowych dostępnych w tej wersji oprogramowania można wymienić CAMELLIA256 i AES256. Ja użyję pierwszego. Oprócz tego wyłączona zostanie kompresja w programie gpg, gdyż dane już raz były kompresowane, więc nie zmniejszyłoby to ich wielkości, ale mogłoby utrudnić rozszyfrowanie w wypadku uszkodzenia. Aby przystąpić do części właściwej procesu szyfrowania wystarczy wykonać komendę i wpisać trudne do przewidzenia przez atakującego hasło (długie, skomplikowane, losowe):

gpg --cipher-algo=CAMELLIA256 --digest-algo=SHA512 --compress-algo="none"  \
--output szyfrogram.tar.xz.gpg --symmetric wiadomosc.tar.xz

shred -n1 --random-source=/dev/zero wiadomosc.tar.xz
rm wiadomosc.tar.xz

Jeśli plików byłoby więcej i nie pasowałoby wpisywanie za każdym razem hasła możesz zastanowić się nad opcją --passphrase-file, jednak należy uniemożliwić dostęp do pliku innym osobom, a po wykonaniu szyfrowania nadpisać plik. Ewentualnie opcja --passphrase-fd 0 i podanie hasła przez potok z komendy echo, jednak wtedy hasło zostanie zapisane w historii basha.

Zakładam, że w systemie jest już, nie tylko zainstalowane, ale też i skonfigurowane gpg, wraz z kluczami którymi można podpisać plik. Tworzymy podpis cyfrowy szyfrogramu:

gpg --output podpisSzyfrogramu.tar.xz.gpg.sig --detach-sig szyfrogram.tar.xz.gpg

Aby w Gnu/Linuksie podzielić plik na części, których nazwy zaczynają się od czescNr a końcą Szyfrogramu.tar.xz.gpg.part, a każda z części jest mniejsza niż 10 Megabajtów, wykonaj:

split --suffix-length=4 --numeric-suffixes --additional-suffix="Szyfrogramu.tar.xz.gpg.part" \
--bytes=10MB  szyfrogram.tar.xz.gpg czescNr

--bytes=10MB to 10^7 bajtów czyli mniej niż 2^20 bajtow. Jeśli chcesz ustawić maksymalną wielkość na 2^20 bajtów, wtedy --bytes=10m

W OpenBSD polecenie split róœnież pozwala podzielić, ale przyjmuje inne argumenty i ma mniejsze możliwości. Użyję więc dodatkowo pętli w shellu:

split -a4 -b9750000 szyfrogram.tar.xz.gpg czescNr
for ZMIENNA in `ls -1 | grep czescNr` ; do KONCOWKA="Szyfrogramu.tar.xz.gpg.part" ; \
NAZWA=$ZMIENNA$KONCOWKA ; mv $ZMIENNA $NAZWA ; done ;

W tej chwili stworzone zostaną dane redundantne (nadmiarowe), które zabezpieczą przed uniemożliwieniem wypakowania archiwum w skutek jego uszkodzenia. Danych tych będzie 2%.

par2 create -r2 -n1 czescNr0000Szyfrogramu.tar.xz.gpg.part.par2 \
czescNr*Szyfrogramu.tar.xz.gpg.part
tar -cf daneNadmiaroweGPG.tar czescNr*Szyfrogramu.tar.xz.gpg.part.*par2
rm czescNr*Szyfrogramu.tar.xz.gpg.part.*

Przy dużym archiwum dane nadmiarowe również mogą mieć dużą objętość. Je również podzielę na mniejsze fragmenty.

#Gnu/Linux
split --suffix-length=4 --numeric-suffixes --additional-suffix=".tar.part" \
--bytes=10MB  daneNadmiaroweGPG.tar czescDgpgNr
rm daneNadmiaroweGPG.tar
#OpenBSD
split -a4 -b9750000 daneNadmiaroweGPG.tar czescDgpgNr
for ZMIENNA in `ls -1 | grep czescDgpgNr` ; do KONCOWKA=".tar.part" ; \
NAZWA=$ZMIENNA$KONCOWKA ; mv ${ZMIENNA} ${NAZWA} ; done ;
rm daneNadmiaroweGPG.tar

Nie skończyliśmy jeszcze tworzenia wszystkich danych nadmiarowych. Dane teraz wytworzone będą miały za zadanie zabezpieczenie wcześniejszych danych nadmiarowych. Danych tych będzie 5% objętości wcześniejszych danych nadmiarowych.

par2 create -r5 -n1 czescDgpgNr0000.tar.part.par2 czescDgpgNr*tar.part
tar -cf daneNadmiarowePar.tar czescDgpgNr*tar.part.*par2
rm czescDgpgNr*tar.part.*

Mamy części szyfrogramu, więc można usunąć szyfrogram:

rm szyfrogram.tar.xz.gpg

Jeśli chcemy więc wysłać gdzieś pliki, to wysyłamy: czescNrSzyfrogramu.tar.xz.gpg.part, czescDgpgNrtar.part, daneNadmiarowePar.tar i ewentualnie podpisSzyfrogramu.tar.xz.gpg.sig.


Przywracanie danych

Założenie jest takie, że w katalogu w którym jesteśmy możemy swobodnie działać, znajdują się pliki czescNr*Szyfrogramu.tar.xz.gpg.part, a także plik z informacjami nadmiarowymi daneNadmiaroweGPG.tar i podpis cyforwy podpisSzyfrogramu.tar.xz.gpg.sig

Sprawdzone teraz zostanie, czy pliki naddatkowe pierwszego poziomu nie są uszkodzone.

tar -xf daneNadmiarowePar.tar
par2 verify czescDgpgNr0000.tar.part.par2

Jeśli ujrzymy napis "All files are correct, repair is not required" to znaczy, że nie trzeba naprawiać. Jeśli ujrzymy "Repair is required", naprawiamy, a następnie usuwamy niepotrzebne już rozpakowane pliki naddatkowe:

par2 repair czescDgpgNr0000.tar.part.par2
rm czescDgpgNr*tar.part.*

Aby połączyć pliki danych naddatkowych 1-szego poziomu wystarczy wykonać:

cat czescDgpgNr*tar.part > daneNadmiaroweGPG.tar

Sprawdzone teraz zostaną pliki składające się na szyfrogram:

tar -xf daneNadmiaroweGPG.tar
par2 verify czescNr0000Szyfrogramu.tar.xz.gpg.part.par2
#ewentualnie
par2 repair czescNr0000Szyfrogramu.tar.xz.gpg.part.par2
rm czescNr*Szyfrogramu.tar.xz.gpg.part.*

Łączę pliki szyfrogramu:

cat czescNr*Szyfrogramu.tar.xz.gpg.part > szyfrogram.tar.xz.gpg

Teraz można zweryfikować czy plik nie był modyfikowany. Jeśli był, to mógł zostać podmieniony przez atakującego lub dane naprawcze nie wystarczyły do jego pełnego naprawienia. Jeśli podpis się zgadza ujrzymy linijkę "gpg: Poprawny podpis złożony przez"

gpg --verify podpisSzyfrogramu.tar.xz.gpg.sig szyfrogram.tar.xz.tar.gpg

Teraz archiwum zostanie rozszyfrowane. Aby rozszyfrować plik wystarczy wykonać komendę i oczywiście podać poprawne hasło:

gpg --output wiadomosc.tar.xz --decrypt szyfrogram.tar.xz.gpg

Gdy ja plik lekko zmodyfikowałem hexeditem, podczas rozszyfrowania zobaczyłem:

gpg: OSTRZEŻENIE: zaszyfrowana wiadomość była manipulowana!

Teraz możemy sprawdzić czy archiwum nie jest uszkodzone i rozkompresować je:

xz --test wiadomosc.tar.xz
xz -d wiadomosc.tar.xz

Następnie można wyodrębnić pliki z archiwum do katalogu wyodrebnione:

mkdir wyodrebnione
tar -xf wiadomosc.tar -C wyodrebnione

Końcowy test dla poradnika:

Jeśli chcemy porównać w tym miejscu oryginalne pliki jeszcze nie zaszyfrowane z powstałymi w wyniku wszystkich powyższych operacji, wystarczy wykonać:

rsync -rvnc --delete katalogDoZaszyfrowania/ wyodrebnione/katalogDoZaszyfrowania/

Jeśli jakiś plik jest inny niż oryginał to pod napisem "sending incremental file list" wyświetli się jego nazwa.


Czego nie jestem pewien? Tego czy tar, xz lub potok nie pozostawi po tych operacjach na dysku fragmentów niezaszyfrowanych jeszcze plików.

OSnews Wykop Blip Flaker Kciuk Śledzik Facebook Identi.ca Twitter del.icio.us Google Bookmarks