0

Due to stories like the following: https://hackerone.com/news/pink-panther (forced at airport customs to decrypt laptop) being more and more frequent, I thought of the following. What if you simply travel with a laptop where you encrypted the unencrypted parts in a LUKS FDE setup via a script and a live cd. Your entire hard drive should look like random data and you'd have plausible deniability that you wiped your hard drive prior to travelling. Upon arriving at your destination, you simply boot your live cd, download your script from a server and decrypt /boot and your boot loader to have a working laptop again. Now I was wondering, how much would my script need to encrypt, i.e what parts in a standard FDE setup with LUKS are not encrypted.

So I use standard LUKS with a 512 MB ext2 /boot partition:

$ sudo fdisk -l /dev/sdd

Disk /dev/sdd: 238.5 GiB, 256060514304 bytes, 500118192 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disklabel type: dos
Disk identifier: 0x0de4d334

Device Boot Start End Sectors Size Id Type
/dev/sdd1 * 2048 1050623 1048576 512M 83 Linux
/dev/sdd2 1050624 500118191 499067568 238G bf Solaris

The /dev/sdd2 partition is completely encrypted with AES/LUKS and should therefore be indistinguishable from random data. Would it suffice to have a script encrypt sector 0 up to 1050624 in this case? Or is my setup leaking data in other places about it being more than just random data? End of a partition at the end of the disk maybe? Should I encrypt the first 50 MB of /dev/sdd2 too?

migrated from crypto.stackexchange.com Jan 8 '15 at 13:01

This question came from our site for software developers, mathematicians and others interested in cryptography.

3

As you said the boot partition is not encrypted at all, because dm-crypt + LUKS does not support it.

As second point a typical encrypted partition under dm-crypt + LUKS setup is the sum of the encrypted data and a partition header (containing the master key, all the keyslots, and some encryption parameters).

This header has a well know structure so, even all the partition is full of random data, the partition header leaks the presence of such encryption. You can easily backup it on a remote website and overwrite it on the disk with random data and later put it back at its original place.

yOu can even get all the parameters for your encryption and feed with all the data the dmsetup command to decrypt your partition without using cryptsetup or luks.

I'm not aware of other possible leaks.

More info about the header format: https://code.google.com/p/cryptsetup/wiki/Specification or see Question 6.12 here: https://code.google.com/p/cryptsetup/wiki/FrequentlyAskedQuestions#6._Backup_and_Data_Recovery


    Refers to LUKS On-Disk Format Specification Version 1.2.1
LUKS header:
offset  length  name             data type  description
0x0000   0x06   magic            byte[]     'L','U','K','S', 0xba, 0xbe
     0      6
0x0006   0x02   version          uint16_t   LUKS version
     6      3
0x0008   0x20   cipher-name      char[]     cipher name spec.
     8     32
0x0028   0x20   cipher-mode      char[]     cipher mode spec.
    40     32
0x0048   0x20   hash-spec        char[]     hash spec.
    72     32
0x0068   0x04   payload-offset   uint32_t   bulk data offset in sectors
   104      4                               (512 bytes per sector)
0x006c   0x04   key-bytes        uint32_t   number of bytes in key
   108      4
0x0070   0x14   mk-digest        byte[]     master key checksum
   112     20                               calculated with PBKDF2
0x0084   0x20   mk-digest-salt   byte[]     salt for PBKDF2 when
   132     32                               calculating mk-digest
0x00a4   0x04   mk-digest-iter   uint32_t   iteration count for PBKDF2
   164      4                               when calculating mk-digest
0x00a8   0x28   uuid             char[]     partition UUID
   168     40
0x00d0   0x30   key-slot-0       key slot   key slot 0
   208     48
0x0100   0x30   key-slot-1       key slot   key slot 1
   256     48
0x0130   0x30   key-slot-2       key slot   key slot 2
   304     48
0x0160   0x30   key-slot-3       key slot   key slot 3
   352     48
0x0190   0x30   key-slot-4       key slot   key slot 4
   400     48
0x01c0   0x30   key-slot-5       key slot   key slot 5
   448     48
0x01f0   0x30   key-slot-6       key slot   key slot 6
   496     48
0x0220   0x30   key-slot-7       key slot   key slot 7
   544     48

Key slot: offset length name data type description 0x0000 0x04 active uint32_t key slot enabled/disabled 0 4 0x0004 0x04 iterations uint32_t PBKDF2 iteration count 4 4 0x0008 0x20 salt byte[] PBKDF2 salt 8 32 0x0028 0x04 key-material-offset uint32_t key start sector 40 4 (512 bytes/sector) 0x002c 0x04 stripes uint32_t number of anti-forensic 44 4 stripes

  • Thank you for your answer, that should cover the start of the disk pretty much. Another thing to consider may be that if you have free space left on your hard drive that the end of the disk may be 0's because there never has been any data written to it. This would make arguing that you did a wipe of the hard drive harder because why would you stop the wipe before it completes? Can of course be mitigated by writing random data to your hard drive before using it as explained here: unix.stackexchange.com/questions/124051/… – sukosevato Jan 8 '15 at 20:31

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.