Jak dbać o swoją prywatność - nie tylko w sieci

Wstęp

Celem poniższego artykułu jest zaprezentowanie jak w łatwy sposób można zaimplementować algorytmy szyfrujące w codziennym używaniu komputera zwiększając tym bezpieczeństwo przechowywanych na nim danych. Pierwsze pytanie jakie się nasuwa - czy algorytmy szyfrujące gwarantują bezpieczeństwo? Ostatnio napisałem ciekawy post na forum odnośnie bezpieczeństwa AES 256 bit. Jest to generalnie mainstream, gdyż procesory, zarówno intela jak i amd, posiadają zestaw instrukcji wspierający ten algorytm, przyśpieszając działanie aplikacji wykorzystujących go. Dla ciekawych post znajduje się pod adresem: http://forum.dug.net.pl/viewtopic.php?pid=225733#p225733.

W skład poniższego tekstu wchodzi:

• Wstęp
• Jak to się robiło gdy byliśmy dziećmi
• Jak to się robi obecnie
• Szyfrowany LVM
• Procedura odzyskiwania skompromitowanego systemu
• Tworzenie voluminów przy użyciu truecrypta
  • Szyfrowanie symetryczne i asymetryczne
  • Jak tworzyć skomplikowane hasła i do tego łatwe do zapamiętania?
  • Konfiguracja voluminów truecrypta
  • Tworzenie zaszyfrowanych kontenerów na pliki
• Jak uprościć używanie truecrypta
  • Zastosowanie sudo
• Klucze PGP/GPG
  • Generowanie kluczy
  • Szyfrowanie wiadomości email
  • Szyfrowanie komunikacji przez protokół xmpp
  • Facebook
  • Google i Gtalk
• DNS i szyfrowanie zapytań
• Jak nie dać się skompromitować?
  • Porty USB
  • Hibernacja
• Problemy?

Po części też zostanie opisane wykorzystanie maszyn virtualnych w celu wyeliminowania przecieku informacji. Wszystko odbywać się będzie pod linuxem, aspekt windowsa zostanie pominięty. Nie chodzi o to, że windows jest dziurawy, bo tak naprawdę każde oprogramowanie posiada dziury, w tym też i opensource - by tak nie wybiegać za daleko w przeszłość, kernel i sudo. Chodzi generalnie o to, że w przypadku windowsa nie mamy informacji o tym jak naprawdę działa system i jakie informacje są "wykradane" przy codziennej pracy na nim. Podobnie sprawa ma się z oprogramowaniem, które ma nas zabezpieczyć ale każdy aspekt jego działania jest ukryty. To tak jakbym powiedział - moje oprogramowanie gwarantuje wam bezpieczeństwo i poufność danych ale musicie mi wierzyć na słowo. xD Dlatego ważnym aspektem zabezpieczeń, jest korzystanie z oprogramowania opensource. AES, truecrypt, linux i pozostałe aplikacje opisane w tym tekście spełnia to założenie. Zawsze można polemizować czy opensource jest lepszy od closedsource. Ja kiedyś napisałem pracę na konkurs i nawet znalazłem się wśród laureatów. xD

Jak to się robiło gdy byliśmy dziećmi

Od wieków istniała potrzeba ukrywania czegoś przed kimś. W tym konkretnym przypadku chodzi o pliki, których nie chcemy pokazywać innym i najlepiej byśmy się czuli gdyby owe pliki istniały tylko w naszej podświadomości. Na dobrą sprawę tak się dzieje - te pliki istnieją tylko dla nas póki ktoś się o nich nie dowie i to w naszej gestii leży by zadbać o ukrycie plików, których nie chcemy ujawniać.

Istnieją rozmaite metody ukrywania plików. Te najprostsze zakładają "schowanie" plików w jakimś katalogu "głębiej" w systemie, tak by nie rzucały się w oczy. Ale pliki można przeszukiwać pod kątem nazw, rozmiarów, daty modyfikacji, czasu dostępu, typu i kto wie czego jeszcze. Poza tym w systemie zostawiamy masę śladów gdy otwieramy jakiś plik, np w historii otwieranych plików w nautilusie. Na dobrą sprawę próba ukrycia danych wygląda jak wyścig zbrojeń.

Możemy oczywiście zmieniać położenie plików i ich nazwy albo i nawet rozszerzenia, tak by zmylić potencjalnych wścibskich intruzów chcących wkraść się w nasze bardzo prywatne życie. Niemniej jednak to rozwiązanie ma bardzo krótkie nogi, krótsze niż kłamstwo, gdyż z perspektywy maszyny nie ma znaczenia jak plik się nazywa i gdzie na dysku się znajduje. Dla niej jest to ciąg składający się z zer i jedynek i dużo ważniejsze są dla niej te cyferki, bo to jest właściwa informacja.

Jak to się robi obecnie

Skoro powyższe sposoby ukrywania plików odpadają, to co nam pozostaje? Jednym z bardziej wyrafinowanych trików jest utworzenie maszyny virtualnej. Ci, którzy widzieli film "The 13th floor" mogą się domyśleć o co chodzi. Wszystko czego potrzebujemy to wykroić trochę przestrzeni dyskowej pod virtualny system plików, oraz obraz .iso płytki instalacyjnej dowolnego systemu operacyjnego. Najnowsze procki wspierają virtualizację i nie stanowi dla nich problemu symulowanie wielu środowisk systemów operacyjnych na jednej maszynie w tym samym czasie. Temu też jeżeli mamy odpowiedni procek, rozwiązanie ukrycia danych za pomocą maszyny virtualnej może być dobrym pomysłem. Jednak pozostaje jeden mankament, jeżeli ktoś się dowie o tej maszynie, może uzyskać do niej dostęp w bardzo prosty sposób i przejrzeć zawarte na niej dane. Zaletą maszyny virtualnej jest fakt niepozostawiania praktycznie żadnych śladów w macierzystym systemie operacyjnym, wliczając w to rejestr (w windows), spersonalizowane ustawienia użytkowników, cała historia przeglądania sieci i wiele wiele innych. Połączenie maszyny virtualnej i szyfrowanych voluminów zapewnia najlepszą ochronę danych. Możemy również zamontować zewnętrzne zaszyfrowane voluminy w maszynie virtualnej i tym samym odseparować wirtualny system od poufnych danych. W przypadku gdy wiemy, że ktoś próbuje się nam dobrać do skóry możemy zniszczyć maszynę wirtualną, nadpisując jej virtualny dysk losowymi danymi, czyniąc dane nie do odzyskania, zacierając tym wszelkie ślady naszej działalności. Ale co jeśli nie jesteśmy świadomi zagrożenia?

Tutaj wchodzi w grę szyfrowanie dysków systemowych. Mamy prawie 100% pewność, że dane nie zostaną wykradzione, oczywiście, jeśli będziemy przestrzegać pewnych zasad obchodzenia się z zaszyfrowanymi danymi. Ale o tym później. O co chodzi z tym całym szyfrowaniem? Jak już wspomniałem wcześniej, maszyna widzi dane tak samo i tylko dla człowieka ma znaczenie w jakiej postaci są one prezentowane. Sposób generalnie polega na zmianie ciągu zer i jedynek za pomocą odpowiedniego klucza szyfrującego, tak by przeciętny śmiertelnik nie mógł w prosty sposób, tj. bez posiadania klucza, uzyskać dostępu do rzeczywistych danych, które zostały zaszyfrowane. Być może brzmi to trochę skomplikowanie ale dla maszyny nie ma to żadnego znaczenia - wystarczy wskazać jej klucz i ona już sama sobie poradzi z szyfrowaniem i deszyfrowaniem informacji w locie.

Dwa główne mechanizmy szyfrowania danych, których ja używam to: szyfrowany LVM oraz voluminy truecrypta. Szyfrowany LVM, jest w moim odczuciu chyba najlepszą opcją jeśli chcemy zaszyfrować sobie dysk systemowy przy jednoczesnym zachowaniu porządku w plikach, np. poprzez posiadanie wielu partycji z różnymi systemami plików lub opcjami ich montowania.

Szyfrowany LVM

LVM to nic innego jak szereg dysków virtualnych utworzonych na jednej partycji. Generalnie, mamy jedną partycję fizyczną, ale w systemie widocznych jest ich kilka, w zależności od tego jak skonfigurujemy sobie LVM. Całość zostanie zaszyfrowana przy pomocy LUKS. Czemu LUKS a nie truecrypt? Obecnie w linuxie nie jest możliwe zaszyfrowanie systemowej partycji przy pomocy truecrypta. W moim przypadku zostało użyte 8 voluminów logicznych: /, /home, /var, /var/log, /tmp, /var/cache/apt, /usr oraz przestrzeń wymiany SWAP. Po co się tak bawić, przecie można mieć wszystko na jednej partycji? Weźmy np. partycję /tmp - posiada ona u mnie system plików ext2, pozostałe mają ext4, ma ograniczony rozmiar do 3,5GiB. Mógłbym jej jeszcze zabrać prawa do wykonywania plików (parametr x). Dane z tej partycji zawsze są czyszczone przy starcie systemu, nie ma więc najmniejszego sensu tworzenie na niej dziennika (ext3, ext4), tylko by spowolnił pracę i tak już obciążonego dysku. Po co w LVM została umieszczona partycja SWAP? Czy szyfrowanie jej jest potrzebne i czy wpływa na bezpieczeństwo zaszyfrowanego systemu? Partycja SWAP zawiera krytyczną przestrzeń w której będą się gromadzić dane w przypadku niewystarczającej ilości miejsca w RAM. Istnieje więc ryzyko, że partycja wymiany będzie zawierać klucz szyfrujący. Wyobraźmy sobie, że nie szyfrujemy partycji wymiany i wyłączamy komputer. Załóżmy, że klucz szyfrujący lub/i hasło do niego zostały w niej zapisane. Po 1 min, po danych w RAMie nie pozostaje żaden ślad. Dane które zostały wgrane do SWAP, zostają. Teraz ktoś może zrobić zrzut niezaszyfrowanej przestrzeni dyskowej i odzyskać klucz i hasło. Kolejna sprawa - czy szyfrować inne części systemu, np. partycję /usr. Przecie nie ma tam, żadnych danych, które by coś dla nas znaczyły. Standardowa instalacja linuxa, po co zatem dane na /usr poddawać szyfrowaniu. Ano, z tego względu, że ktoś może podmienić na niej pliki. Wyobraźmy sobie sytuację gdy ktoś wgrywa nam trefny plik oraz podmienia firefoxa tak by wykonał instrukcje zawarte w tym pliku. Włączasz kompa, cieszysz się, że masz zaszyfrowany komputer i jesteś bezpieczny, odpalasz ff i całe twoje szyfrowanie jest zbędne tylko męczy procesor. Konkluzja? Każda przestrzeń niezaszyfrowana w naszym systemie to potencjalne zagrożenie dla poufności danych.

Można pierw stworzyć zaszyfrowaną partycję i umieścić w niej logiczne voluminy, lub też można stworzyć LVM składający się z zaszyfrowanych voluminów. Ja zawsze, przy instalacji debiana, wybierałem opcję tworzenia zaszyfrowanego dysku i umieszczania w nim voluminów LVM. Możemy także utworzyć szyfrowany LVM ręcznie, niepotrzebny jest do tego instalator linuxa - możemy skorzystać np. z livecd czy zwykłego systemu operacyjnego. W ubuntu-live jest możliwość zainstalowania systemu na zaszyfrowanych dyskach LVM ale potrzebny do tego jest cały nośnik, także jeżeli mamy partycje, na których znajdują się jakieś dane, w tym procesie zostaną usunięte. W przypadku ręcznej konfiguracji, nie mogłem się doszukać opcji szyfrowanych dysków czy LVM. Jeśli chodzi o ubuntu jeszcze, to z płytki alternate bez problemu szło przeprowadzić ustawianie szyfrowanego LVM (dokładnie tak samo jak w debianie) ale Canonical płytek alternate, poczawszy od 12.10, już nie robi.

W przypadku ustawiania szyfrowanego LVM trzeba pamiętać by niezaszyfrować partycji /boot. Czemu? Gdy zaszyfrujemy partycję /boot nie odpali nam się system. Trzeba przeznaczyć niewielki obszar dysku (100 - 200 MiB) na partycję /boot, na której będą trzymane obrazy modułów jądra oraz konfiguracja gruba. Ale zaraz, powiedziałem przed chwilą, że cała przestrzeń systemowa musi zostać zaszyfrowana, czy ta partycja /boot nie będzie stanowić zagrożenia? Będzie. Nie musimy się martwić tą niezaszyfrowaną przestrzenią do momentu utraty fizycznej kontroli nad dyskiem. W przypadku MBR jak i partycji /boot tego typu sytuacja (utrata kontroli) może mieć katastrofalne w skutkach konsekwencje. Czy ja wspomniałem MBR? Co to jest MBR i jak może zagrozić bezpieczeństwu danych? Tak samo jak w przypadku /boot, MBR jest to bardzo niewielka przestrzeń dysku, która jest niezaszyfrowana. Ok, mamy zatem dwie potencjalne dziury w systemie, przy czym trzeba pamiętać, że można się martwić wtedy gdy ktoś nam dysk zabierze lub będzie sam na sam z naszym kompem dłuższą chwilę.

Jak wygląda struktura MBR i jakie dane się w nim znajdują?

MBR znajduje się na pierwszej ścieżce, w pierwszym cylindrze, w pierwszym sektorze rozruchowego dysku (CHS – 0, 0, 1).
Ma 512 bajtów długości, z czego pierwsze 446 bajtów zajmuje program rozruchowy (ang. bootstrap).
Druga część MBR to tablica partycji – zawiera 4 struktury opisujące poszczególne partycje podstawowe, każda po 16 bajtów.
MBR kończą 2 bajty sygnatury – szesnastkowo 0x55 0xAA, co daje 446 + (8 · 8) + 2 = 512.

Potencjalne zagrożenie stanowi pierwsze 446 bajtów. W nich jest trzymany program rozruchowy, który można podmienić. Jaka jest na to rada? Kopia, albo całego MBR, albo przynajmniej pierwszych 446 bajtów i trzymanie ich w bezpiecznym miejscu. Atak Evil Maid na przykładzie truecrypta pokazuje dobitnie jak ta malusieńka przestrzeń dysku może nas skompromitować. W przypadku gdy tracimy fizyczną kontrolę nad maszyną i mamy przypuszczenia, że ktoś coś mógł namieszać. Musimy wgrać kopie MBR. Trzeba pamiętać by przy wgrywaniu 512 bajtów tablica partycji była niezmieniona. Jeżeli dokonywaliśmy zmian w partycjach, np zmienialiśmy ich rozmiar, nie możemy przywrócić całej kopi MBR. Musimy przywrócić tylko pierwsze 446 bajtów.

Jak zatem zrobić kopię zapasową MBR lub samego programu ładującego?

# dd if=/dev/sda of=/home/morfik/mbr bs=512 count=1

A jak przywrócić by nie pozamiatać sobie przy okazji wszystkich plików?

Cały MBR
# dd if=/home/morfik/mbr of=/dev/sda bs=512 count=1

Program rozruchowy
# dd if=/home/morfik/mbr of=/dev/sda bs=446 count=1

Co zrobić w przypadku partycji /boot. Można postąpić analogicznie lub też w troszeczkę inny sposób, który poniekąd opisuje procedurę odzyskiwania zaszyfrowanego systemu opartego o LVM.

Trzeba mieć też w świadomości możliwość użycia sprzętowych keyloggerów. Takie urządzonko ma niewielkie rozmiary zwykle doczepiane do przewodu od klawiatury. Jeżeli tracimy komputer z oczu, lepiej sprawdzić wszystkie wtyki czy czasem, ktoś czegoś nam nie zamontował. xD

Procedura odzyskiwania skompromitowanego systemu

Jak odzyskać zaszyfrowany system i czy jest to trudne? Nie jest to trudne i nie ma z tym większego ryzyka utraty danych niż przy zwykłej próbie odzyskiwania systemu. Potrzebna jest tylko płytka live cd z ubuntu np.

Jeżeli mamy przypuszczenie, że ktoś mógł mieszać przy dysku, musimy usunąć dane z każdej niezaszyfrowanej przestrzeni - w tym przypadku jest to MBR i partycja /boot. Czyścimy je zatem:

$ sudo su
# dd if=/dev/urandom of /dev/sda bs=446 count=1
# dd if=/dev/urandom of /dev/sda3

Następnie wgrywamy kopię MBR i tworzymy nową partycję /boot np. przy użyciu gparted. By się dostać do zaszyfrowanego systemu z poziomu livecd, musimy postępować według poniższej instrukcji:

# cryptsetup luksOpen /dev/sda4 sda4_crypt
# vgscan
# vgchange nazwa_grupy -a y
# lvscan

Przy czym musimy pamiętać by "sda4_crypt" odpowiednio zmodyfikować do własnych potrzeb i by ta nazwa zgadzała się z tą w pliku /etc/crypttab na zrootowanym systemie. Więcej informacji pod adresem: http://forum.dug.net.pl/viewtopic.php?id=23053. Po wydaniu ostatniego polecenia powinniśmy uzyskać listę aktywnych dysków LVM. Musimy teraz utworzyć katalog /mnt/root, w którym zamontujemy voluminy. Pamiętajmy też by podmontować partycję /boot w katalogu /mnt/root/boot. Po zamontowaniu wszystkich partycji, wpisujemy jeszcze poniższe linijki:

# mount -o bind /proc /mnt/root/proc
# mount -o bind /sys /mnt/root/sys
# mount -o bind /dev /mnt/root/dev
# mount -o bind /dev/pts /mnt/root/dev/pts
# cp /etc/resolv.conf /mnt/root/etc/resolv.conf

Teraz już pozostało nam zrootować środowisko i przejąć kontrolę nad zaszyfrowanym systemem.

# chroot /mnt/root /bin/bash

Za pomocą aptitude reinstalujemy gruba oraz kernela - pakiety: grub-pc grub-common linux-image-* . Mogą wystąpić problemy z reinstalacją powyższych pakietów. Jeśli nie dałoby rady przeinstalować ich za pomocą aptitude reinstall, trzeba będzie je usunąć (purge) i ponownie zainstalować. Podczas wydawania polecenia update-grub , prawdopodobnie pojawią się poniższe dwa błędy:

cat: /boot/grub/video.lst: No such file or directory

/usr/sbin/grub-probe: error: no such disk.

Jeśli chodzi o pierwszy komunikat, wystarczy wygenerować plik, którego brakuje za pomocą grub-install /dev/sda . Drugiego komunikatu nie udało mi się wyeliminować będąc na chroot ale błąd nie występuje podczas odpalenia update-grub po normalnym załadowaniu systemu. Jeżeli wspomniany komunikat by się pojawił, trzeba usunąć plik /boot/grub/device.map oraz wydać polecenie grub-install --recheck /dev/sda .

Wracając do chroot - trzeba jeszcze zaktualizować wpis odpowiedzialny za partycję /boot, konkretnie chodzi o nowe UUID wygenerowane przy tworzeniu nowej partycji. By uzyskać id wszystkich partycji w systemie wydajemy polecenie blkid, odszukujemy wpis od partycji /boot i kopiujemy jej UUID do pliku /etc/fstab. Zlikwiduje to błąd fsck przy starcie systemu. Gdy już skończymy wszelkie prace naprawcze, pozostaje nam wyjść z chroot i odmontować to co zamontowaliśmy powyżej.

Tak wygląda operowanie na zaszyfrowanym LVM. Nie jest to trudne, wymaga jednak przyzwyczajenia.

Tworzenie voluminów przy użyciu truecrypta

Nie wiem czemu truecrypt nie jest dostępny w repozytoriach debiana, w każdym razie możemy pobrać najnowszą wersję (7.1a, wydana 2012-02-07) ze strony http://www.truecrypt.org/. Instalacja nie powinna stanowić większego problemu. W przypadku debiana, prawdopodobnie wystąpią problemu z zależnościami - trzeba doinstalować pakiety od fuse oraz device mapper. Cała procedura tworzenia voluminów będzie odbywać się za pośrednictwem GUI, bo prościej. Wszystkie opisane kroki można bez problemu przeprowadzić za pośrednictwem konsoli.

Stworzenie voluminu nie powinno nastręczyć problemów. Jest jednak kilka punktów, o których trzeba pamiętać. Pierwszy z nich to taki, że przy tworzeniu zaszyfrowanej partycji zostaną usunięte z niej wszystkie dane. Kolejna sprawa to performance. W truecrypcie można szyfrować dane za pomocą trzech różnych algorytmów - AES, Serpent, Twofish oraz dowolnej ich konfiguracji. Co to oznacza? Wybór algorytmu przełoży się na prędkość z jaką będą dokonywane operacje szyfrowania/deszyfrowania plików w locie. Zależność jest prosta - im więcej algorytmów użyjemy, tym proces szyfrowania/deszyfrowania stanie się bardziej zasobnożerny. Warto pamiętać, że przy jednym algorytmie np. AES, szybkości zapisu/odczytu szyfrowanych danych będzie ograniczona parametrami dysku twardego. W przypadku wyboru 3 algorytmów szyfrujących, ogromne znaczenie będzie miała moc procesora.

Szyfrowanie symetryczne i asymetryczne

Nasuwa się pytanie - czy wybrać jeden czy kilka algorytmów? Ci, którzy przeczytali link do posta na forum, w którym opisałem czy AES 256 daje nam gwarancję poufności danych, prawdopodobnie już znają odpowiedź. Jednak potrzebne jest przedstawienie różnicy między szyfrowaniem asymetrycznym i symetrycznym by w pełni zrozumieć z czym ma się do czynienia. Podstawową różnicą, o której zapewne wszyscy wiedzą to korzystanie z jednego klucza (szyfrowanie symetryczne) i dwóch kluczy (szyfrowanie asymetryczne). Jaka jest jeszcze inna różnica między tymi dwoma typami szyfrowania? Długość klucza szyfrującego. W przypadku szyfrowania symetrycznego mamy do czynienia z kluczami do 256 bitów, w przypadku asymetrycznego, 1024-4096 bitów. Czy długość klucza wpływa na bezpieczeństwo? Tak, wpływa. Można zatem dojść do wniosku, że skoro mamy użyty klucz 256 bitowy, że jest on bardzo słaby, w porównaniu do takiego średniego 2048 bitowego klucza używanego przy SSL na stronach www. Nic bardziej błędnego - szacuje się, że 256 bitowy klucz symetryczny to odpowiednik 15360 bitowego klucza RSA.

Jednak gdyby ktoś by się uparł, mógłby zdeszyfrować dane zaszyfrowane za pomocą jednego klucza, wykorzystując bardzo specyficzne środowisko i mając sporo szczęścia. Możemy jednak troszeczkę temu komuś utrudnić ten proces, choćby przez stosowanie dwóch lub trzech algorytmów szyfrujących. Możemy także wypełnić losowymi danymi cały voluminum. Po co się tak bawić? W przypadku gdy utworzymy nową partycję i nie wypełnimy jej danymi (domyślnie truecrypt prosi o to) struktura danych na dysku będzie bardzo jednolita - zawierać same zera. Tam gdzie wgramy plik, będą zera i jedynki. W przypadku wypełnienia losowymi danymi zaszyfrowanej partycji, ciężko będzie stwierdzić gdzie znajdują się faktyczne dane. Niemniej jednak, wypełnienie losowymi danymi całej przestrzeni 2 TB dysku może trochę zająć. xD Osobiście nie polecam użycia 3 algorytmów, chyba że mamy bardzo wydajny procesor, a nasze dane są bardzo ściśle tajne i nie obawiamy się rachunków z elektrowni. Podwójne lub potrójne szyfrowanie ma tę przewagę, że w przypadku złamania szyfru pierwszego klucza, dane dalej będą nieczytelne, co może prowadzić do zaniechania dalszych prób deszyfracji, o ile w ogóle się ktoś weźmie za próbę złamania pierwszego klucza. Poza tym, prościej męczyć właściciela o hasło lub/i pliki klucze niż łamać szyfr. A w przypadku bardzo twardego właściciela, jedynym strażnikiem danych na dysku za pomocą, którego można uzyskać dostęp do danych będzie hasło. Dlatego ważne jest by było możliwie długie i możliwie skomplikowane ale do tego przejdziemy później.

Poza opcją wyboru algorytmu szyfrującego właściwe dane, mamy do wyboru jeszcze algorytm hashujący - RIPEMD-160, SHA-512, Whirlpool. Po co nam on? Za jego pomocą są generowane min. liczby losowe, które mogą zostać użyte do wypełnienia nowego pustego woluminu. Algorytm hashujący może też zostać zastosowany przy tworzeniu klucza głównego, klucza wtórnego, soli i plików kluczy.

Po wybraniu dwóch powyższych opcji, przechodzimy do ustanowienia hasła i/lub plików kluczy. Ustanowienie plików kluczy uodporni nasz zaszyfrowany volumin na wszelkie keyloggery. Nawet jak padniemy ofiarą i zostanie nam wykradzione hasło do klucza, volumin będzie chroniony za pomocą pliku lub plików. Pliki klucze zawsze można dodać lub usunąć. Hasło, z kolei musimy utworzyć silne, 20-30 znaków minimum. Czemu takie długie? Najsłabszym ogniwem w całej tej zabawie z truecryptem jest oczywiście człowiek. Ale może się okazać, że istnieje jeszcze słabsze ogniwo - hasło, które ma kilka znaków, które może zostać złamane w paręnaście min do kilku godzin. A jak ktoś pozna nasze hasło, to mamy pozamiatane. Trzeba sobie zadać dość ważne pytanie - czy naprawdę chcemy utrudnić sobie życie szyfrowaniem, czy może lepiej zaprzestać "nielegalnej działalności" i żyć w spokoju i nie mieć nic do ukrycia. xD Jeśli jednak chcemy mieć coś do ukrycia, np. przed żoną, trzeba niestety podejść poważnie do długości i skomplikowania hasła. O ile długość jest ważna o tyle nie musi to być hasło typu *98KKn-+(*d67H. Tego nie idzie w żaden sposób zapamiętać, a to tylko kilka znaków. xD

Jak tworzyć skomplikowane hasła i do tego łatwe do zapamiętania?

Metod na tworzenie haseł jest bardzo dużo. Mi np. tworzenie 20+ znakowych haseł na poczekaniu i używanie ich natychmiast nie stanowi problemu. Przy czym zaznaczam, że każde 20+ znakowe hasło różni się od siebie. Jak to możliwe, czy do tego potrzebne są jakieś nadprzyrodzone zdolności, albo trzeba mieć dziadka Einstein'a? Nic z tych rzeczy, wystarczy podzielić hasło na frazy i zacząć używać wyobraźni. Wyobraźmy sobie zdanie w obcym języku, np. w ENG. "I love my girlfriend". Oczywiście nie polecam używania tego typu hasła. Zamiast tego pokażę, jak z tak bardzo prostego mogłoby się wydawać hasła stworzyć bardzo silne i do tego długie hasło, o większej ilości znaków niż nasz przykład. Przede wszystkim słowa takie jak I, love, my, girlfriend, istnieją w słownikach i hasło składające się z nich nie stanowi żadnej bariery ochronnej dla nas. Biorąc pod uwagę fakt, że w angielskim wymowa bardzo mało ma wspólnego z pisownia, mamy ciekawe zjawisko, gdyż nasze zdanie przyjmuje już taką postać: "ajloawmajgyrfrend" - oczywiście, są różne dialekty i czasem ludzie wymawiają dany dźwięk troszeczkę inaczej, niektórych wcale nie wymawiają, co przełoży się dodatkowo na bardziej niepowtarzalne hasło. Mamy już całkiem dobre hasło, ale nie po to ktoś wymyślił znaki specjalne by tak sobie leżały odłogiem na klawiaturze - odseparujmy poszczególne wyrazy od siebie. Tutaj może być niezłe pole do popisu, gdyż możemy użyć separatora jakiego tylko chcemy. Przykładowo, ustalamy separator na -=+ - trzy proste znaki. Nasze hasło będzie miało postać: aj-=+loaw-=+maj-=+gyrfrend - przypomina to trochę losowe znaki, oczywiście możemy użyć separatora typu 12, 34, 56, 78, etc. Można użyć czego tylko dusza zapragnie. Ja chyba powinienem opatentować swoje metody generowania haseł. xD

Konfiguracja voluminów truecrypta

Mamy już hasło. Teraz pozostało nam skonfigurowanie systemu plików zaszyfrowane voluminu. Trzeba zaznaczyć, że domyślne opcje nie są zbytnio satysfakcjonujące. W przypadku systemu plików ext, zostanie zarezerwowane 5% danych dla roota. Trzeba będzie później te domyślne opcje pozmieniać za pomocą tune2fs. Póki co, zaznaczamy opcję "quck format" wypełnienie losowymi danymi voluminu zostanie pominięte. I tak doszliśmy do ostatniego kroku przed formatowaniem - generowanie klucza. Machamy myszką wewnątrz okna wykonując możliwie bardzo chaotyczne ruchy, gdyż to się przełoży na siłę klucza. gdy już się zmęczyliśmy, klikamy format. Teraz tylko trzeba poczekać aż zakończy się formatowanie nowej partycji.

Gdy proces dobiegnie końca, mamy świeżutką partycję, jednak nie do końca sformatowaną tak jakbyśmy sobie tego chcieli, przynajmniej w moim wypadku. Montując partycję z domyślnymi opcjami w oknie truecrypta uzyskamy informacje jakie urządzenie w katalogu /dev/ za nią odpowiada. Zaszyfrowane voluminy, czy to przy użyciu LVM jak i również truecrypt'a są zwykle oznaczone w katalogu /dev/ jako dm-1, dm-2, etc. W /dev/mapper/ są z kolei dowiązania do odpowiednich urządzeń w katalogu /dev/. Do zaszyfrowanych partycji możemy odwoływać się zarówno przez katalog /dev/ jak i /dev/mapper/, ale nie możemy tego robić za pomocą np. /dev/sda5. Jeżeli zaczniemy robić coś z urządzeniem /dev/sda5, np. sprawdzać go pod kątem spójności struktury sytemu plików, stracimy zaszyfrowane dane. Generalnie linux, nie potrafi wykryć voluminów truecrypta i oznacza jego partycje jako uszkodzone lub nieznane. Trzeba o tym pamiętać przy ewentualnej próbie naprawy systemu plików.

Jak zatem zmienić opcje systemu plików jak i również system plików zaszyfrowanego voluminu bez ponownego przechodzenia przez opisany przeze mnie powyżej proces? Partycja truecrypta nie różni się zbytnio od standardowej partycji dysku twardego, ma tylko inne oznaczenie, temu we wszystkich programach, które operują na partycjach lub danych na nich zawartych trzeba wziąć poprawkę, wpisując nowe położenie partycji, np. /dev/dm-1 lub /dev/mapper/szyfr.

Na sam początek zmieńmy etykietę systemu plików tak by łatwiej można było się zorientować co gdzie mamy, w przypadku posiadania wielu zaszyfrowanych voluminów. Zmienimy także współczynnik zarezerwowanego miejsca do 0% dla zaszyfrowanej partycji. Działając na systemie plików, należy pamiętać by nie był on podmontowany.

# tune2fs -m 0 -L tajne_dane /dev/mapper/truecrypt1

Co trzeba wiedzieć jeszcze o zaszyfrowanym systemie plików. Jako, że linux nie wykrywa poprawnie partycji truecrypt'a, będzie potrzeba ręcznego skanowania systemu plików w poszukiwaniu błędów. By tego dokonać trzeba odszyfrować zaszyfrowany volumin ale bez opcji montowania go. Wtedy wydać z konsoli polecenie fsck.ext4 -yfv /dev/dm-1 . Jeżeli nie będziemy skanować i ewentualnie naprawiać błędów w systemie plików, zaczniemy tracić dane. Czy jest możliwość utraty danych, np. przez niepoprawne zamknięcie systemu lub przy zaniku napięcia? Na dobrą sprawę nie ma takiej możliwości, co prawda jeżeli będziemy zapisywać plik i nam prąd wyłączą, to ten plik się uszkodzi - tak jak w przypadku zwykłego wgrywania danych na dysk. Nic z voluminem jako takim się nie stanie.

Tworzenie zaszyfrowanych kontenerów na pliki

W przypadku tworzenia kontenera na dane, postępujemy tak samo jak w przypadku tworzenia partycji, z tą różnicą, że zamiast przeznaczać całej partycji pod szyfrowanie, przeznaczamy tylko określoną część dysku. Efektem będzie stałej wielkości plik, który można zamontować w truecrypcie niczym obraz .iso w daemon tools, oraz możliwość jego łatwego przeniesienia, np. na pendrive.

Jak uprościć używanie truecrypta

Ok, wszystko fajnie w przypadku jednego voluminum, a czy używanie truecrypta może być proste gdy w grę wchodzi ich kilka? Czy da radę je w prosty sposób montować? Pominę oczywiście "sposoby" na obejście haseł, na używanie pendrivów jako kluczy, na auto montowanie zaszyfrowanego systemu plików podczas startu systemu. Dlaczego? Ano ze względów bezpieczeństwa. Jeżeli rozważacie powyższe 3 sposoby na umilenie sobie życia z truecryptem, zrezygnujcie z szyfrowania. Powyższe operacje powodują tylko narażenie klucza szyfrującego lub/i hasła na wyciek. Hasło nie może być nigdzie zapisane, nikt nie może o nim wiedzieć, nic nie może robić za hasło - chodzi o plik czy urządzenie.

Pokażę jak zamontowanć voluminy truecrypta za pomocą jednego kliku, przy zachowaniu hasła i wszelkich norm obchodzenia się z zaszyfrowanymi danymi. Co będzie potrzebne zatem. Plik .bash_aliases, w którym to zdefiniujemy pożądane aliasy, prosty skrypt montujący, oraz mechanizm sudo. Spójrzmy prawdzie w oczy, obecnie by zamontować voluminy truecrypta, potrzebujemy pierw zalogować się na roota, potem wybrać voluminy i zdefiniować ich opcje, takie jak np. punkty montowania, jeśli zależy nam na estetyce. Oczywiście są osoby, którym partycje typu truecrypt1, truecrypt2, etc nie przeszkadzają, ja mam bardziej wyrafinowany gust i lubię komplikować sobie życie. To jednak, jakby nie patrzeć takie ciągłe wprowadzanie tych parametrów może troszeczkę zirytować człowieka. Oczywiście można użyć zewnętrznego narzędzia - disk-manager - do montowania i definiowania opcji montowanych partycji. Wtedy montowanie partycji truecrypta się uprości ale nadal będzie przebiegać w trzech etapach - logowanie się na roota, odszyfrowanie partycji, skorzystanie z disk-managera w celu podmontowania. Potem to samo w drugą stronę - zalogowanie się na roota, odmontowanie przez disk-managera, zamknięcie voluminów w truecrypt. Można dostać nie powiem czego od tego typu operacji. xD W każdym razie, disk-manager montuje urządzenia w oparciu o plik /etc/fstab i to jest troszeczkę niebezpieczne, gdyż po zresetowaniu komputera (nie przez brak prądu), przy starcie systemu operacyjnego zostanie wyrzucony komunikat o uszkodzonych partycjach. A to dlatego, że w pliku /etc/fstab istnieją wpisy z zaszyfrowanymi partycjami, które obecnie nie są dostępne - bo voluminy truecrypta są zamknięte. Komunikat wygląda mniejwiecej tak:

fsck.ext3: Unable to resolve 'UUID=be8e2929-0de5-407a-a58b-c944823541f9'
fsck.ext3: Unable to resolve 'UUID=dbbcf0a1-2e19-4474-ad75-3b857e7eabbc'
fsck.ext3: Unable to resolve 'UUID=0560bcb7-77bc-460c-a4c1-712832af2617'
fsck.ext3: Unable to resolve 'UUID=54ed1521-310f-485a-94b5-cd7411238e06'
fsck died with exit status 8
failed (code 8).
File system check failed. A log is being saved in /var/log/fsck/checkfs if that location is writable. Please repair the file system manually. ... [ failed ]
A maintenance shell will now be started. CONTROL-D will terminate this shell and resume system boot. ... [ warning ]
Give root password for maintenance
(or type Control-D to continue): 
Mounting local filesystems...mount: special device UUID=be8e2929-0de5-407a-a58b-c944823541f9 does not exist
mount: special device UUID=dbbcf0a1-2e19-4474-ad75-3b857e7eabbc does not exist
mount: special device UUID=0560bcb7-77bc-460c-a4c1-712832af2617 does not exist
mount: special device UUID=54ed1521-310f-485a-94b5-cd7411238e06 does not exist

Czasem, tego typu komunikat może przyprawić o zawał serca, zwłaszcza gdy pierwszy raz się go widzi, niemniej jednak proces montowania jest dość upierdliwy. Trzeba poszukać czegoś prostszego.

Szukając jak rozwiązać ten problem, natknąłem się na artykuł poświęcony sudo. Powiedziałem wtedy sobie: "przeczytam, może coś się rozjaśni". Jako, że nigdy nie korzystałem z sudo, bo w debianie jest oddzielne konto root i zwykle wszystko co potrzebowałem robiłem za pomocą roota, pomyślałem, że przejście na sudo może być troszeczkę skomplikowane. Np. w ubuntu nie ma roota, jest samo sudo. Okazało się, że te dwa mechanizmy mogą istnieć obok siebie, a sudo wcale nie jest takie skomplikowane jak się może wydawać. W takim razie przejdźmy do aktywacji sudo i spróbujmy je skonfigurować.

Zastosowanie sudo

Jeżeli nie mamy w systemie zainstalowanego sudo to dociągamy. Kilka słów o konfiguracji. Oficjalną droga do edycji pliku konfiguracyjnego sudo jest przez narzędzie visudo, niby taki tryb bezpieczny. Wklepujemy do terminalu visudo i mamy edytor podobny do nano. Musimy tam dopisać jedną regułkę odpowiedzialną za zezwolenie użytkownikom innym niż root na używanie polecenia truecrypt. Oto ta linijka:

# Users in the truecrypt group are allowed to run TrueCrypt as root.
%truecrypt ALL=(root) NOPASSWD:/usr/bin/truecrypt

Analiza tej linijki trochę mi zajęła. Ale ostatecznie udało mi się rozkminić co oznacza ten zapis. Brzmi on tak: Zezwól użytkownikom grupy truecrypt na wykonywanie polecenia /usr/bin/truecrypt ze wszystkimi opcjami i parametrami jako użytkownik root bez proszenia o hasło (NOPASSWD:). ALL lub localhost wpisujemy w przypadku gdy nie dzielimy konfiguracji sudo między wieloma maszynami.

Czyli na dobrą sprawę trzeba utworzyć grupę truecrypt i dodać do niej pożądanych użytkowników i ci użytkownicy będą mogli korzystać z truecrypta tak jak root bez jakiegokolwiek hasła. Czyli odpadnie nam jedno hasło przy montowaniu voluminów. Jeden problem z głowy. Mamy jeszcze parę innych do rozwiązania.

Drugi problem jaki nasuwa się to, jak zautomatyzować montowanie kilku voluminów jednocześnie. Truecrypt sam w sobie posiada ulubione. Są tam powiązane partycje z punktami montowania. Teraz musimy tylko zamontować wszystko jak należy i dodać zestaw do ulubionych. Co znaczy "zamontować jak należy"? Tzn. otworzyć voluminy bez montowania ich, użyć disk-managera by sprecyzować punkty montowania. Jeśli mamy etykiety na partycjach, zostaną automatycznie uwzględnione w punktach montowania. Ustawiamy, montujemy i w truecrypcie widzimy jak zostają przepisane punkty montowania i powiązane zostają z określonymi partycjami. Zapisujemy ustawienie w ulubionych, odmontowujemy systemy plików w disk-managerze i zamykamy voluminy.

W tej chwili możemy w dość prosty sposób montować partycje. Wydając polecenie z konsoli truecrypt --auto-mount=favorites, lub z GUI -> Favorites -> Mount Favorite Volumes. Wpisujemy hasło. Ale to nie koniec naszej pracy. Jak jeszcze bardziej uprościć sobie życie. Skoro je na początku skomplikowaliśmy, teraz przydałoby się je uprościć. xD

Musimy zdefiniować sobie kilka aliasów w pliku .bash_aliases w katalogu /home/ - jeśli nie ma tego pliki to musimy go stworzyć. Jak mają wyglądać wpisy w nim i po co mają one być? Poniżej przykłady:

# voluminy truecrypt
alias tc_fav='truecrypt fmask=0113,dmask=0002 --auto-mount=favorites'
alias tc_1='truecrypt --fs-options=users,uid=$(id -u),gid=$(id -g),fmask=0113,dmask=0002 --mount /media/sllinux/linux.iso /media/szyfr_pen'
alias tc_u='truecrypt -d /media/szyfr_pen'

Mam zdefiniowane trzy aliasy: tc_fav, tc_1, tc_u. Pierwszy z nich odpowiada za automatyczne momntowanie ulubionych. Nie muszę pisać truecrypt --auto-mount=favorites. Wpisuje po prostu tc_fav.

Drugi alias odpowiada za montowanie kontenera, osobny, zaszyfrowany plik zlokalizowany na pendrive, od czasu do czasu używany jako backup.

Trzeci alias odmontowuje i zamyka volumin na pendrive. By odmontować wszystkie zamontowane voluminy truecrypta wydajemy polecenie truecrypt -d.

Opcje użyte w aliasach: fmask i dmask odpowiadają za ustanawianie atrybutów nowych plików 664 (fmask) i katalogów 775(dmask). Z kolei fs-options=users,uid=$(id -u),gid=$(id -g) odpowiada za zamontowanie voluminu z uprawnieniami użytkownika, który montuje.

Mamy aliasy, możemy montować wygodnie voluminy truecrypta z konsoli ale czegoś brakuje. Niektórzy chcieliby sobie tak kliknąć w ikonkę i by wyskoczyło im okienko z hasłem. Do tego będzie nam potrzebny prosty skrypt:

#!/bin/bash

# potrzebne do włączenia aliasów
shopt -s expand_aliases

# plik w którym trzymane są aliasy
source ~/.bash_aliases

tc_fav

Teraz już tylko pozostało nam utworzenia skrótu, np. na panelu gnome, nadanie chmod +x na skrypt i wybranie ikonki. Po kliknięciu w nią wyskoczy okno wpisania hasła - w tym przypadku do voluminów zdefiniowanych w ulubionych.

Klucze PGP/GPG

Wyróżniamy dwa rodzaje kluczy - symetryczne (opisane wyżej) oraz asymetryczne, i tymi drugimi zajmiemy się w tym dziale. Przy generowaniu klucza GPG, są tak naprawdę generowane dwa klucze - publiczny i prywatny. Mechanizm szyfrowania za ich pomocą sprowadza się do zaszyfrowania wiadomości przy użyciu klucza publicznego i deszyfracji jej za pomocą klucza prywatnego. Klucz publiczny, jak sama nazwa wskazuje, jest publiczny, czyli dostępny dla wszystkich. W celu uproszczenia wymiany kluczy publicznych stosuje się serwery do których owe klucze są wysyłane przez jedną ze stron i pobierane przez drugą. Oczywiście można zrezygnować z użycia zewnętrznych serwerów i słać klucz publiczny ręcznie do każdej osoby, która chce nam przesłać zaszyfrowaną wiadomość. W sytuacji gdy mamy jedną taką osobę a klucz nam nie wygasa, może być to idealne rozwiązanie ale co gdy mamy powiedzmy setkę osób i ważność klucza została określona na rok? W tym przypadku prościej jest wysłać klucz publiczny do serwera kluczy np. keyserver.ubuntu.com (tylko taki potrafię zapamiętać bez problemów xD) a zainteresowane osoby same go sobie dociągną. Istnieje też inne rozwiązanie, możemy zaszyfrować symetryczny klucz asymetrycznym i przesłać go za pomocą poczty, tak by odbiorca mógł go zdeszyfrować i później operować na kluczu symetrycznym, który jest o wiele mocniejszy niż klucz asymetryczny, nie wspominając już o fakcie, że tylko dwie zainteresowane strony posiadają ten klucz. W przypadku klucza pub-priv istnieje potencjalna możliwość złamania klucza prywatnego posługując się kluczem publicznym.

Klucze GPG znajdują zastosowanie przy szyfrowaniu tekstu, pojedynczych plików, wiadomości email, komunikacji za pomocą protokołu xmpp oraz wykorzystywane są do podpisywania dokumentów - w przypadku gdy nie chcemy szyfrować treści dokumentu ale chcemy by odbiorca był pewny, że wiadomość pochodzi od nas i nie została ona zmieniona przez kogoś trzeciego w procesie wymiany informacji. Działa to mniejwiecej tak:

do oryginalnej wiadomości dołączany jest skrót dokumentu, zaszyfrowany prywatnym kluczem nadawcy.
Potwierdzenie autentyczności wiadomości jest możliwe po odszyfrowaniu skrótu kluczem publicznym nadawcy
i porównaniu go z wytworzonym skrótem odebranego dokumentu.

Poniżej zostanie opisany sposób na zastosowanie szyfrowania poczty na przykładzie thunderbirda z wykorzystaniem dodatku enigmail oraz zaszyfrowanie komunikatów przesyłanych za pomocą protokołu xmpp na przykładzie aplikacji gajim. Zostanie również omówiona kwestia prywatności na facebooku oraz na googlu.

Generowanie kluczy

Klucze możemy generować używając tekstowego gpg lub tez za pomocą nakładek graficznych seahorse czy też GNU Privacy Assistant. Możemy w tym celu użyć również enigmaila. Niezależnie od użytej nakładki, tworzenie klucza nie powinno generować żadnych problemów. W przypadku enigmaila potrzebne jest pierw utworzenie konta email w thunderbirdzie. Dla tych, którzy chcą używać gpg w wersji tekstowej informacje na temat jak stworzyć klucz i nim zarządzać znajdują się pod adresem https://wiki.archlinux.org/index.php/GPG lub też pod adresem https://help.ubuntu.com/community/GnuPrivacyGuardHowto.

Przy generowaniu klucza warto wspomnieć o certyfikacie unieważniającym klucz. Można go wygenerować i w przypadku gdy tracimy klucz prywatny, za pomocą certyfikatu możemy unieważnić klucz. Wadą posiadania certyfikatu unieważniającego jest oczywiście możliwość jego wykradzenia, a jak stracimy certyfikat, to ktoś może nam zrobić psikusa i unieważnić nam nasz własny klucz. xD

Szyfrowanie wiadomości email

Szyfrowanie wiadomości email można uznać za paranoiczne podejście do kwestii wymiany informacji - zwykły człowiek mówi sobie: "ja przecie za pomocą poczty nie wysyłam nic ważnego, nawet swoich nagich fotek, a nawet jeśli już to są one od pasa w dół, poza tym gmail jest szyfrowany bo używa SSL". SSL co prawda jest ale ogranicza się do szyfrowania tego co robimy na gmailu, same wiadomości nie są szyfrowane. Poza tym google kiedyś wspominał, że w przypadku gdy policja będzie żądała dostępu do twojej skrzynki na gmailu, nie dość, że google to umożliwi, to jeszcze wyciągnie wszelkie maile jakie przez tę skrzynkę zostały przepuszczone - zarówno odebrane jak i wysłane. Temu tez musimy się zdać na zewnętrzny mechanizm szyfrujący, w ty przypadku będzie to dodatek do thunderbirda - enigmail.

W przypadku gdy mamy już istniejące klucze prywatne i chcemy je powiązać z naszym kontem email, dokonujemy tego przechodząc kolejno thunderbird > edycja > konfiguracja kont. Przy każdym koncie mamy informacje o openPGP. Tutaj musimy zdefiniować klucz, którego konto będzie używać domyślnie przy deszyfrowaniu wiadomości, które ktoś na to konto prześle. Jeżeli posiadamy wiele kont i chcemy by każde konto korzystało z innego klucza prywatnego, musimy w każdym koncie osobno zdefiniować pożądany klucz. Jedyna rzecz o której trzeba pamiętać to zmiana id klucza w konfiguracji konta mailowego w sytuacji gdy klucz wygasa. W przeciwnym razie nawet po wygenerowaniu nowych par kluczy, nie będzie możliwe zdeszyfrowanie wiadomości.

Klucze publiczne musimy przesłać na serwer kluczy - thunderbird > openPGP > zarządzanie kluczami, klikamy prawym na klucz i wybieramy "eksportuj klucze publiczne na serwer". Wybieramy serwer - keyserver.ubuntu.com, jest to chyba najpopularniejszy serwer kluczy, w każdym razie możemy wysłać klucz publiczny do kilku różnych serwerów.

Jeżeli posiadamy kogoś kto używa kluczy GPG, możemy przeszukać serwery kluczy w celu pobrania klucza publicznego tej osoby. Po tym jak zaimportujemy klucz, definiujemy reguły adres-klucz tak by nie musieć za każdym razem wybierać klucza przy tworzeniu wiadomości email, którą chcemy wysłać do konkretnej osoby. W tym celu przechodzimy do - thunderbird > openPGP > ustawienia i klikamy "ustawienia zaawansowane" i na zakładkę "wybór kluczy", następnie "definiuj reguły". Samo dodawanie reguł nie powinno sprawić trudności. W przypadku gdy importujemy nowy klucz publiczny, zaufanie do niego nie jest określone. By móc szyfrować za pomocą tego klucza, musimy pierw wyrobić zaufanie do niego. W okienku zarządzania kluczami klikamy prawym na klucz i wybieramy "ustaw poziom zaufania do właściciela".

Od tej chwili szyfrowanie wiadomości odbywać się będzie automatycznie. W przypadku gdy ktoś prześle nam zaszyfrowaną wiadomość naszym kluczem publicznym, by uzyskać do niej dostęp będziemy musieli podać hasło do klucza prywatnego. W taki oto prosty sposób mamy pewność, że tylko my i nasz rozmówca znamy treść wiadomości.

Szyfrowanie komunikacji przez protokół xmpp

Na dobrą sprawę korzystałem z dwóch komunikatorów obsługujących protokół jabbera - psi i gajim. Z psi już nie korzystam od lat, dlatego też cały opis szyfrowania odbędzie się na przykładzie gajima. Z tego co wiem, wszystkie opisane poniżej kroki można bez problemu przenieść na inny komunikator. Wszystko czego potrzebujemy to klucz prywatny. Przechodzimy do opcji konta by ustawić klucz prywatny: gajim > edycja > konta, zaznaczamy nasze konto i przechodzimy na zakładkę "informacje osobiste". To tam definiujemy klucz prywatny. Musimy także powiązać klucze publiczne z kontaktami. W tym celu otwieramy listę kontaktów i klikamy prawym na dany kontakt > manage contact > przypisz klucz openPGP. Od tego momenty, za każdym razem gdy będziemy coś pisać do tej osoby, w oknie rozmowy będziemy widzieć kłódkę wskazującą na to, że wiadomość jest szyfrowana.

Inną ciekawą opcją jest szyfrowanie end2end wbudowane bezpośrednio w komunikator. Jeżeli ty i twój rozmówca posiadacie ten sam komunikator, np. psi lub gajim, jest możliwość dynamicznego tworzenia par kluczy i korzystania z nich przy prowadzeniu rozmowy, szyfrując nimi wiadomości automatycznie. Przy każdej nowej konwersacji będą ustanawiane nowe klucze. Szkoda, że to rozwiązanie nie działa gdy ma się różne komunikatory, w takim przypadku pozostaje tylko użycie klucza GPG.

Facebook

Mało osób wie, że można użyć zewnętrznego komunikatora obsługującego sieć jabbera w celu komunikacji ze wszystkimi osobami, które mamy zdefiniowane w profilu na fejsie. Facebook jednak nie umożliwia komunikacji z naszymi kontaktami, które używają innych serwerów jabbera. Ale to nie robi żadnej różnicy, gdyż w komunikatorze, np. gajim, możemy dodać sobie kilka serwerów i posiadać "normalne" konto jabbera oraz to facebookowe.

Komunikacja na facebooku nie jest szyfrowana, mało tego log jest zapisywany na serwerach facebooka i facebook ma pełny wgląd w nasze rozmowy, co jest troszeczkę niebezpieczne. Skoro jest możliwość korzystania z zewnętrznego komunikatora, to co stoi na przeszkodzie by zaimplementować klucze GPG? No właśnie - myslałem, że da radę w prosty sposób ukryć swoją prywatność na fejsie za pomocą kluczy GPG ale wygląda na to, że nic z tego.

Po dodaniu konta do gajima i zdefiniowaniu serwera chat.facebook.com , wszystko zapowiadało się dobrze. Można bez problemu rozmawiać z osobami, które mamy w kontakach i to bez potrzeby użycia do tego celu przeglądarki. Klucze do konta w gajimie oraz te, do kontaktów bez problemowo się przypisują. Ale przy szyfrowaniu zostają wyrzucone poniższe komunikaty (testowane na lini psi-gajim):

# Gajim
[BŁĄD: Ta wiadomość jest zaszyfrowana a Ty nie jesteś w stanie jej odszyfrować.]

# PSI
[Ta wiadomość jest zaszyfrowana (Zobacz :XEP: '27'] ([This message is *encrypted* (See :XEP:`27`])

Pierwsze co mi przyszło do głowy to, że może klucze są źle dobrane. Sprawdziłem wszystko i było w porządku. Czemu zatem nie można odszyfrować wiadomości? Okazuje się, że jeżeli rozmawiamy za pośrednictwem zewnętrznego komunikatora, log rozmowy jest też zapisywany w wiadomościach facebooka, wszystko jedno czy mamy odpaloną wtedy przeglądarkę czy nie. Wychodzi na to, że tak naprawdę rozmawiamy z fejsem i on kopiuje nasze wiadomości do kontaktów, a nie posiadając klucza GPG nie może odszyfrować wiadomości. Dokładnie tak samo w przypadku gdyby ktoś trzeci próbował podsłuchać naszą rozmowę. Tutaj jednak wszystko przechodzi przez tą trzecią osobę, a konkretnie maszynę - lepiej nie wpisujcie w fejsie "bin laden", "terroryzm" i tego typu wyrażeń - echelon przy fejsie to pryszcz. xD

Google i Gtalk

Gtalk to taki googlowski komunikator oparty o sieć jabbera. Podobnie jak w przypadku fejsowego czatu, można skonfigurować zewnętrzny komunikator obsługujący protokół xmpp. ID do Gtalka to adres email poczty na gmailu. Konfiguracja konta nie powinna stanowić problemu - tutaj znajduje się dokładna rozpiska jak skonfigurować różne komunikatory. W przypadku Gtalka mamy możliwość komunikacji z osobami, które mają konta na innych serwerach jabberowych. Działa też szyfrowanie gpg i end2end w psi czy gajimie. Może i google udostępnia pocztę policji ale przynajmniej nie pozbawia nas możliwości szyfrowania, zarówno rozmów na Gtalku jak i samej poczty, a logi z zaszyfrowanej komunikacji może policji dawać! xD

DNS i szyfrowanie zapytań

Do SSL na stronach www chyba wszyscy przywykli. Obecnie praktycznie na każdej stronie gdzie jest okienko logowania, mamy do czynienia z szyfrowaniem danych przesyłanych za pomocą formularza. Co prawda, klucze nie są zbyt długie 512-2048 bit ale zawsze to lepsze to niż nic. O ile dane służące do logowania czy wszelkie operacje dokonywane w panelach administracyjnych da radę ukryć bez większego problemu, o tyle zapytania DNS są przesyłane otwartym tekstem i każdy może je sobie podejrzeć. Pytanie tylko, po co szyfrować ruch DNS? Czy są tam jakieś ważne dane? Jeśli przyjrzymy się jak działa system DNS, możemy dojść do wniosku, że szyfrowanie zapytań jest pozbawione sensu - nazwa domeny = IP. Znając IP, możemy i tak ustalić, kto na jakie strony wchodzi. Nie do końca jest to prawdą, poza tym istnieją jeszcze inne czynniki, które sprawiają, że ukrycie zapytań DNS ma jak najbardziej sens.

Czy naprawdę możemy ustalić kto jakie serwisy odwiedza na podstawie adresu IP? W sporej części przypadków zapewne tak ale tylko pod warunkiem, że dany adres IP jest wykorzystywany tylko przez jeden serwis. A co w przypadku gdy jeden adres IP hostuje kilka czy kilkaset stron? Znając tylko adres IP, nie będziemy mieć pewności, która strona została tak naprawdę odwiedzona. Co prawda, będziemy mieli zawężony krąg podejrzanych ale nie ustalimy czy dana osoba odwiedziła ten konkretny adres. Znając zapytania DNS, wiemy dokładnie kto gdzie wchodzi. Może to nie przekona większości z was, zatem jakie są jeszcze problemy związane z DNS?

Każdy słyszał o blokadach domen dokonywanych przez rząd USA. Jak to ma się do zapytań DNS? Podobnie jak rząd USA, rząd Polski może narzucić lokalnym ISP filtry stron zakazanych. O ile w przypadku rządu USA, który jest właścicielem root serwerów DNS nie możemy nic zrobić, bo blokady są globalne, o tyle w przypadku gdy nasz ISP zapragnie nam blokować serwisy internetowe filtrując DNS, mamy się jak bronić - zmieniamy serwery DNS. Niemniej jednak, cały ruch dalej przechodzi przez naszego ISP i zmiana samych adresów DNS nic nie da, Frazy domen mogą zostać odfiltrowane ale tylko w przypadku gdy będą widoczne. I tu właśnie znajduje zastosowanie szyfrowanie ruchu DNS.

Usługa OpenDNS oferuje dość zaawansowaną konfigurację DNS wliczając w to rozmaite filtry, w tym też blokowanie pojedynczych stron www. Można nawet włączyć log odwiedzanych adresów i generować ciekawe statystyki. Bardzo przydatne jeżeli mamy dzieci i chcemy wiedzieć na jakie strony wchodzą i czy są wśród nich strony porno. Wtedy bez problemu można poblokować odpowiednie domeny, wiem wredne - na szczęście są płytki live. xD Ważniejszym jednak ficzerem OpenDNS, przynajmniej dla mnie, jest szyfrowanie zapytań DNS.

Obecnie każdy system przy starcie pobiera konfigurację sieci przez DHCP od swojego ISP. Jest tam też konfiguracja serwerów DNS - jest ona opcjonalna. Możemy albo na sztywno zdefiniować adresy DNS przy konfiguracji sieci albo wpisać odpowiednie dane w pliku /etc/resolv.conf . Ręczna edycja pliku resolv.conf może się wydawać bezzasadna ale nie w przypadku gdy chcemy zablokować możliwość przypadkowej zmiany tego pliku, np przez zewnętrzne oprogramowanie - nadajemy mu atrybut chattr +i (system plików z rodziny ext). Teraz mamy pewność, że w tym pliku znajduje się dokładnie taka zawartość jakiej oczekujemy i nie musimy sprawdzać co chwila, czy czasem adresy DNS nie uległy zmianie. Gdy chcemy korzystać z serwerów OpenDNS, dodajemy w pliku poniższe adresy:

nameserver 208.67.222.222
nameserver 208.67.220.220

My jednak będziemy korzystać z opcji szyfrowania zapytań i nie możemy bezpośrednio użyć powyższych adresów. Musimy pierw utworzyć lokalny serwer, który będzie zapytania szyfrował i przesyłał je do OpenDNS.

Narzędzie, które posłuży nam do zaszyfrowania ruchu DNS to DNScrypt. Niestety, panowie z teamu OpenDNS zapomnieli o paczce .deb i program trzeba kompilować ręcznie. Najnowszą wersją obecnie jest 1.2.1. Pobieramy paczkę, kompilujemy i instalujemy. Jeżeli by były jakieś problemy, na stronie projektu są dokładne instrukcje odnośnie instalacji.

Mając już zainstalowany DNScrypt, musimy jeszcze poinstruować nasz lokalny resolver by przesyłał do niego ruch. W tym celu edytujemy /etc/resolv.conf , kasujemy zawartość i dodajemy poniższą linijkę:

nameserver 127.0.0.1

Nadajemy atrybut chattr + i na /etc/resolv.conf . Ze względów bezpieczeństwa wskazane jest by utworzyć użytkownika, który będzie uruchamiał DNScrypta - nie może to być ani root, ani standardowy użytkownik systemu. Tworzymy zatem użytkownika opendns bez możliwości logowania się na konsolę:

# addgroup opendns
# mkdir -p /home/opendns/
# chown -R opendns:opendns /home/opendns/
# useradd opendns -d /home/opendns -g opendns -s /bin/false

Musimy jeszcze dodać skrypt startowy odpowiedzialny za uruchamianie się DNScrypta. Tworzymy plik /etc/init.d/opendns i wklejamy do niego poniższą zawartość:

#!/bin/bash

### BEGIN INIT INFO
# Provides:          opendns
# Required-Start: $remote_fs $syslog
# Required-Stop:  $remote_fs $syslog
# Default-Start:     2 3 4 5
# Default-Stop:      0 1 6
# Short-Description: Run /etc/init.d/opendns if it exist
### END INIT INFO

/usr/local/sbin/dnscrypt-proxy --user=opendns --daemonize --logfile=/var/log/opendns

Opcja --logfile oddzieli logi od systemowych i zapisze je w oddzielnym pliku. Teraz już tylko dodajemy nasz skrypt startowy:

# insserv --verbose opendns
# /etc/init.d/opendns restart

Jeśli wszystko przebiegło pomyślnie, powinniśmy być w stanie ładować strony w przeglądarkach i co najważniejsze, ukryliśmy zapytania.

Jak nie dać się skompromitować?

Czasami nawet najbardziej wykwintne zabezpieczenia zdają się na nic gdy w grę wchodzi człowiek. Czasem też niektóre zabezpieczenia są pozbawione sensu i wynikają z przeświadczenia, że posiadając "zabezpieczenie", jestem bezpieczny. Przykład takiego "zabezpieczenia" - hasło na bios płyty głównej. Ok, w przypadku gdy do komputera jest utrudniony dostęp, np. jednostka centralna ukryta jest głęboko pod ziemią, niczym ul pod Raccoon City, zakładanie hasła na bios w celu uniemożliwienia choćby zmiany urządzeń, z których będzie ładowany system, ma sens. Większość ludzi ma komputer na biurku, niczym niezabezpieczony. Co stoi na przeszkodzie by wyciągnąć baterię z płyty głównej i zresetować bios? Obudowa, kilka śrubek? xD Jasne, że gdy w grę wchodzi czas, nawet odkręcenie paru śrubek może stanowić problem, ale co w przypadku gdy pozostawiamy naszą maszynę bez opieki na długie godziny? W takim przypadku trzeba mieć się na baczności. Trzeba pamiętać, że powyższe zabezpieczenia mają sens wtedy gdy bronimy dostępu do naszego sprzętu bardziej niż cnoty naszej dziewczyny. Szyfrowanie całego dysku daje nam pewność, że nikt nie dokonał żadnych zmian w strukturze danych, nie ustrzeże nas to jednak przed niezbyt rozsądnym korzystaniem z internetu - wchodzenie na podejrzane www i zasysanie rozmaitego syfu typu rootkity czy programowe keyloggery, które mogą bez problemu, wykorzystując naiwność ofiary, wykraść poufne informacje.

Porty USB

Warto też brać pod uwagę możliwość zrzutu informacji z urządzeń podłączanych do portów USB. Policja dysponuje ciekawymi narzędziami od MS (temu na początku artykułu się przyczepiłem do windowsa), które są zebrane na pendrivie i po wsadzeniu pena do portu USB, automatycznie tworzą bardzo rozbudowane logi, które nastepnie są zapisywane na podłączonym penie. Nie są to zbyt wyrafinowane progsy, do większości z nich przeciętny śmiertelnik ma dostęp przy codziennym użytkowaniu komputera. W każdym razie, w taki sposób się zdobywa dowody bez jakiejkolwiek inwazyjności w badany sprzęt. Narzędzia od MS działają na windowsie, niemniej jednak trzeba mieć świadomość dziury w postaci USB w systemie.

W przypadku linuxa by móc wejść w interakcję z podłączonymi urządzeniami trzeba pierw zamontować ich system plików. By uodpornić nasz system na opisane powyżej zrzuty informacji można ustawić by np. nasz linux prosił o hasło admina przy montowaniu wszelakich zewnętrznych urządzeń - po wsadzeniu pendriva do portu USB, zostanie wyświetlony komunikat z hasłem, w przypadku nie podania hasła, system plików nie zostanie zamontowany. Fakt podłączenia jakiegokolwiek urządzenia jednak będzie widoczny w logach systemowych. Chytry włamywacz nie dość, że nie dostanie się do systemu, do jeszcze zostawi nieusuwalne z jego pozycji ślady. xD

Zabezpieczenie portów sprowadza się do edycji pliku /usr/share/polkit-1/actions/org.freedesktop.udisks.policy . Przechodzimy do "Mount a device" i zmieniamy "allow_active" z "no" na "auth_admin".

Hibernacja

Hibernacja systemu może w poważnym stopniu zagrozić jego bezpieczeństwu, a to z tego względu, że dane z pamięci RAM zostaną zrzucone na dysk twardy, a konkretnie do SWAP. W przypadku gdy używamy szyfrowanego LVM, wydając polecenie hibernacji, zostanie zrobiony zrzut pamięci do szyfrowanej przestrzeni dysku. By przy starcie maszyny podnieść system, trzeba będzie pierw otworzyć voluminy LVM podając hasło. W przypadku gdy posiadamy sam kontener truecrypta, a partycja systemowa jest nieszyfrowana, unikałbym hibernacji jak ognia. Oczywiście możliwe jest też przechwycenie danych z pamięci RAM. Większość ludzi zapytana, po jakim czasie znikają dane z pamięci RAM, dopowie od razu po wyłączeniu zasilania. Ja na wstępie powiedziałem, że potrzeba około jednej minuty by dane z pamięci RAM się ulotniły. To wprawdzie mało czasu, by cokolwiek z RAMem zrobić. Ale ten czas można wydłużyć i to dość drastycznie - schładzając kości RAMu. Dla ciekawskich jest pdf oraz krótki materiał video.

Innym prostym zabezpieczeniem jakie możemy zastosować to blokada pulpitu, domyślnie ctrl+alt+L, za każdym razem gdy odchodzimy od komputera. Przydałoby się również dostosować automatyczne blokowanie pulpitu po pewnym czasie nieaktywności - domyślnie jest wygaszany monitor po 10 min i po wygaszeniu następuje blokada ekranu. Oczywiście gdy oglądamy filmy na vlc czy smplayerze, blokada jest zdejmowana.

Problemy?

Być może czegoś nie dopowiedziałem lub też zostało opisane w sposób błędny. Jeśli widzisz gdzieś błęda daj mi znać. Poniżej zamieszczam linki, w których znajduje się bardziej szczegółowy opis prezentowanych przeze mnie zagadnień. Tak wiem, używam debiana, a jadę na wiki archa i ubuntu. xD

- https://wiki.archlinux.org/index.php/System_Encryption_with_LUKS
- https://wiki.archlinux.org/index.php/TrueCrypt
- https://wiki.archlinux.org/index.php/Sudo
- https://wiki.archlinux.org/index.php/GPG
- https://help.ubuntu.com/community/GnuPrivacyGuardHowto
- http://www.truecrypt.org/docs/