Keyfile trzymany w głębokim ukryciu

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