Keyfile trzymany w głębokim ukryciu
Kategoria: Artykuły, etykiety: keyfile, luks, pendrive, szyfrowanie
Dodany: 2014-03-17 19:54
(zmodyfikowany: 2014-03-17 20:01)
Przez: morfik
Wyświetleń: 12338
Pisząc ostatni artykuł na temat udeva i montowania przy jego pomocy zaszyfrowanego kontenera, wpadł mi do głowy ciekawy pomysł na trzymanie keyfile w czymś co się potocznie nazywa "głębokim ukryciem". Z reguły ludzie nie chcą używać haseł do odblokowywania swoich systemów czy partycji. Zamiast tego wolą keyfile, czyli małe pliki, zwykle o rozmiarze paru KiB, które, jak nie patrzeć, są dość unikatowe i odporne na ataki słownikowe czy inne formy przemocy. Jedyny problem z jakim człowiek musi się zmierzyć to z zabezpieczeniem takiego keyfile i tutaj sprawa nie wygląda wcale dobrze. Keyfile są trzymane zwykle na tym samym urządzeniu, do którego mają dostarczyć dostęp, a nawet jeśli nie na tym samym, to w jego pobliżu i zwykle przechwycenie zaszyfrowanego dysku skutkuje przechwyceniem klucza, który może posłużyć do otwarcia urządzenia.
A może istnieje jakiś sposób, który by ukrył taki keyfile by nikt, kto o jego istnieniu nie wie, nie mógł go użyć do odszyfrowania urządzenia? Jeśli przypatrzymy się takiemu pendrivowi, to możemy zobaczyć poniższy układ partycji:
# fdisk -l /dev/sdb
Disk /dev/sdb: 15.5 GB, 15513354240 bytes
64 heads, 32 sectors/track, 14794 cylinders, total 30299520 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x0005c7f0
Device Boot Start End Blocks Id System
/dev/sdb1 2048 6293503 3145728 83 Linux
/dev/sdb2 6293504 10487807 2097152 83 Linux
/dev/sdb3 10487808 30298111 9905152 83 Linux
Gdzie można by schować keyfile? Moim zdaniem gdzieś poniżej 2048 sektora, bo tam nic nie ma, bo partycja pierwsza zaczyna się na 2048 sektorze w wyniku równania do 1MiB. 2047 sektorów (bo jeden to MBR) daje nam 1048064 bajtów wolnego miejsca, a my potrzebujemy 2KiB . Czyli mamy dość miejsca by ulokować keyfile tak by nie można było zgadnąć gdzie on jest. Ten keyfile nie będzie miał nazwy, bo jest to tylko zbitka bitów na dysku i nie pozostawia praktycznie żadnych wskazówek co do swojego istnienia.
Naturalnie można by stworzyć mały pliczek i wgrać go w któreś miejsce między 0 a 2048 sektorem ale istnieje lepszy sposób na zachowanie poufności keyfile. Bo w przypadku gdyby tam były same 0 i wgralibyśmy losowe dane o długości 2048 bajtów, to będą one widoczne jak na dłoni. Dlatego też zapiszemy losowymi danymi całą wolną przestrzeń pierw, po czym określimy, które sektory będą robić za keyfile.
To do dzieła. Zapisujemy 2047 sektorów 512 bajtowych pomijając pierwszy z nich, w którym siedzi MBR -- nie chcemy sobie wpinąć przy okazji tablicy partycji.
# dd if=/dev/urandom of=/dev/sdb bs=512 count=2047 seek=1
2047+0 records in
2047+0 records out
1048064 bytes (1.0 MB) copied, 0.346335 s, 3.0 MB/s
W ten sposób mamy losowe dane w MBR-GAP. Nasz keyfile ma 2KiB długości i by w ogóle coś z nim robić to musimy go pierw dodać do nagłówka LUKS:
# dd if=/dev/sdb bs=512 count=4 skip=100 > ./keyfile
4+0 records in
4+0 records out
2048 bytes (2.0 kB) copied, 0.00102532 s, 2.0 MB/s
# ls -al ./keyfile
-rw-r--r-- 1 root root 2.0K Mar 17 19:17 ./keyfile
# cryptsetup luksAddKey /dev/sdb2 ./keyfile
Enter any passphrase:
Oczywiście rozmiar keyfile może być dowolny, tzn. nie większy niż 8192KiB. Powyższa linijka czyta 4*512 bajtów, czyli 2KiB, pomijając pierwsze 100 sektorów czyli 100*512=51200 bajtów od początku pendrive. To tam właśnie będzie znajdował się nasz keyfile.
Sprawdzamy czy keyfile został dodany do nagłówka:
# cryptsetup luksDump /dev/sdb2
LUKS header information for /dev/sdb2
Version: 1
Cipher name: aes
Cipher mode: xts-plain64
Hash spec: sha512
Payload offset: 4096
MK bits: 512
MK digest: d0 9d 3d b3 34 2d 0c d3 0e 99 59 79 14 71 f3 00 07 b5 b8 76
MK salt: d6 9f 77 4f f0 2d c8 07 c9 cf a7 60 c4 6f 3d 90
c9 4d 5c ae f4 e5 36 d3 e5 75 b4 5d 3b 83 c9 79
MK iterations: 18125
UUID: 90ec6f73-8fdb-4c8d-aebd-cadd0f51b412
Key Slot 0: ENABLED
Iterations: 37558
Salt: c1 1a 6f 49 5f f4 49 94 e2 4d 56 3a 49 39 87 14
95 38 2f d3 cd 99 43 73 50 9b 44 09 cb c5 ad 9f
Key material offset: 8
AF stripes: 4000
Key Slot 1: ENABLED
Iterations: 15685
Salt: 95 f7 1b 27 04 c6 87 c8 3c 14 23 5b c7 99 f8 c2
cf ab 1c ed 8c 70 69 b4 da a3 a7 67 97 5e f6 a4
Key material offset: 512
AF stripes: 4000
Key Slot 2: ENABLED
Iterations: 37036
Salt: dc cf 2b ff da a1 4a cf ee 54 c0 19 5a d4 48 cd
ed 25 52 b6 0c e8 ad ae 35 56 96 35 64 22 db ce
Key material offset: 1016
AF stripes: 4000
Key Slot 3: DISABLED
Key Slot 4: DISABLED
Key Slot 5: DISABLED
Key Slot 6: DISABLED
Key Slot 7: DISABLED
By otworzyć partycję na pendraku z wykorzystaniem tego keyfile, wpisujemy poniższą linijkę:
# dd if=/dev/sdb bs=512 count=4 skip=100 | cryptsetup luksOpen /dev/sdb2 sdb2 --key-file=-
4+0 records in
4+0 records out
2048 bytes (2.0 kB) copied, 0.000904289 s, 2.3 MB/s
I jeszcze możemy sprawdzić czy aby na pewno kontener się otwiera gdy podamy parametry 512 4 100 dla dd. Podmieńmy zatem 100 na 101:
# dd if=/dev/sdb bs=512 count=4 skip=101 | cryptsetup luksOpen /dev/sdb2 sdb2 --key-file=-
4+0 records in
4+0 records out
2048 bytes (2.0 kB) copied, 0.00220645 s, 928 kB/s
No key available with this passphrase.
Nasz keyfile co prawda jest dostarczany razem z zaszyfrowanym urządzeniem ale pozostaje w głębokim ukryciu i nikt kto nie zna tych 3 parametrów, nie uzyska dostępu do pena, poza tym, kto by chował keyfile w MBR-GAP? xD