+ There is a potential security issue with XTS mode and large blocks.
+ LUKS and dm-crypt always use 512B blocks and the issue does not
+ apply.
+
+
+ * 5.17 Is LUKS FIPS-140-2 certified?
+
+ No. But that is more a problem of FIPS-140-2 than of LUKS. From a
+ technical point-of-view, LUKS with the right parameters would be
+ FIPS-140-2 compliant, but in order to make it certified, somebody
+ has to pay real money for that. And then, whenever cryptsetup is
+ changed or extended, the certification lapses and has to be
+ obtained again.
+
+ From the aspect of actual security, LUKS with default parameters
+ should be as good as most things that are FIPS-140-2 certified,
+ although you may want to make sure to use /dev/random (by
+ specifying --use-random on luksFormat) as randomness source for
+ the master key to avoid being potentially insecure in an
+ entropy-starved situation.
+
+
+ * 5.18 What about Plausible Deniability?
+
+ First let me attempt a definition for the case of encrypted
+ filesystems: Plausible deniability is when you hide encrypted data
+ inside an encrypted container and it is not possible to prove it is
+ there. The idea is compelling and on first glance it seems
+ possible to do it. And from a cryptographic point of view, it
+ actually is possible.
+
+ So, does it work in practice? No, unfortunately. The reasoning used
+ by its proponents is fundamentally flawed in several ways and the
+ cryptographic properties fail fatally when colliding with the real
+ world.
+
+ First, why should "I do not have a hidden partition" be any more
+ plausible than "I forgot my crypto key" or "I wiped that partition
+ with random data, nothing in there"? I do not see any reason.
+
+ Second, there are two types of situations: Either they cannot force
+ you to give them the key (then you simply do not) or the can. In
+ the second case, they can always do bad things to you, because they
+ cannot prove that you have the key in the first place! This means
+ they do not have to prove you have the key, or that this random
+ looking data on your disk is actually encrypted data. So the
+ situation will allow them to waterboard/lock-up/deport you
+ anyways, regardless of how "plausible" your deniability is. Do not
+ have a hidden partition you could show to them, but there are
+ indications you may? Too bad for you. Unfortunately "plausible
+ deniability" also means you cannot prove there is no hidden data.
+
+ Third, hidden partitions are not that hidden. There are basically
+ just two possibilities: a) Make a large crypto container, but put a
+ smaller filesystem in there and put the hidden partition into the
+ free space. Unfortunately this is glaringly obvious and can be
+ detected in an automated fashion. This means that the initial
+ suspicion to put you under duress in order to make you reveal you
+ hidden data is given. b) Make a filesystem that spans the whole
+ encrypted partition, and put the hidden partition into space not
+ currently used by that filesystem. Unfortunately that is also
+ glaringly obvious, as you then cannot write to the filesystem
+ without a high risk of destroying data in the hidden container.
+ Have not written anything to the encrypted filesystem in a while?
+ Too bad, they have the suspicion they need to do unpleasant things
+ to you.
+
+ To be fair, if you prepare option b) carefully and directly before
+ going into danger, it may work. But then, the mere presence of
+ encrypted data may already be enough to get you into trouble in
+ those places were they can demand encryption keys.
+
+ Here is an additional reference for some problems with plausible
+ deniability: http://www.schneier.com/paper-truecrypt-dfs.pdf I
+ strongly suggest you read it.
+
+ So, no, I will not provide any instructions on how to do it with
+ plain dm-crypt or LUKS. If you insist on shooting yourself in the
+ foot, you can figure out how to do it yourself.
+
+
+ * 5.19 What about SSDs or Flash Drives?
+
+ The problem is that you cannot reliably erase parts of these
+ devices, mainly due to wear-leveling and possibly defect
+ management.
+
+ Basically, when overwriting a sector (of 512B), what the device
+ does is to move an internal sector (may be 128kB or even larger) to
+ some pool of discarded, not-yet erased unused sectors, take a
+ fresh empty sector from the empty-sector pool and copy the old
+ sector over with the changes to the small part you wrote. This is
+ done in some fashion so that larger writes do not cause a lot of
+ small internal updates.
+
+ The thing is that the mappings between outside-adressable sectors
+ and inside sectors is arbitrary (and the vendors are not talking).
+ Also the discarded sectors are not necessarily erased immediately.
+ They may linger a long time.
+
+ For plain dm-crypt, the consequences are that older encrypted data
+ may be lying around in some internal pools of the device. Thus may
+ or may not be a problem and depends on the application. Remember
+ the same can happen with a filesystem if consecutive writes to the
+ same area of a file can go to different sectors.
+
+ However, for LUKS, the worst case is that key-slots and LUKS
+ header may end up in these internal pools. This means that password
+ management functionality is compromised (the old passwords may
+ still be around, potentially for a very long time) and that fast
+ erase by overwriting the header and key-slot area is insecure.
+
+ Also keep in mind that the discarded/used pool may be large. For
+ example, a 240GB SSD has about 16GB of spare area in the chips that
+ it is free to do with as it likes. You would need to make each
+ individual key-slot larger than that to allow reliable overwriting.
+ And that assumes the disk thinks all other space is in use.
+ Reading the internal pools using forensic tools is not that hard,
+ but may involve some soldering.
+
+ What to do?
+
+ If you trust the device vendor (you probably should not...) you can
+ try an ATA "secure erase" command for SSDs. That does not work for
+ USB keys though. And if it finishes after a few seconds, it was
+ possibly faked by the SSD.
+
+ If you can do without password management and are fine with doing
+ physical destruction for permenently deleting data (allways after
+ one or several full overwrites!), you can use plain dm-crypt or
+ LUKS.
+
+ If you want or need the original LUKS security features to work,
+ you can use a detached LUKS header and put that on a conventional,
+ magnetic disk. That leaves potentially old encrypted data in the
+ pools on the disk, but otherwise you get LUKS with the same
+ security as on a magnetic disk.
+
+ If you are concerned about your laptop being stolen, you are likely
+ fine using LUKS on an SSD. An attacker would need to have access
+ to an old passphrase (and the key-slot for this old passphrase
+ would actually need to still be somewhere in the SSD) for your
+ data to be at risk. So unless you pasted your old passphrase all
+ over the Internet or the attacker has knowledge of it from some
+ other source and does a targetted laptop theft to get at your
+ data, you should be fine.
+
+
+6. Backup and Data Recovery
+
+
+ * 6.1 Why do I need Backup?
+
+ First, disks die. The rate for well-treated (!) disk is about 5%
+ per year, which is high enough to worry about. There is some
+ indication that this may be even worse for some SSDs. This applies
+ both to LUKS and plain dm-crypt partitions.
+
+ Second, for LUKS, if anything damages the LUKS header or the
+ key-stripe area then decrypting the LUKS device can become
+ impossible. This is a frequent occurrence. For example an
+ accidental format as FAT or some software overwriting the first
+ sector where it suspects a partition boot sector typically makes a
+ LUKS partition permanently inaccessible. See more below on LUKS
+ header damage.
+
+ So, data-backup in some form is non-optional. For LUKS, you may
+ also want to store a header backup in some secure location. This
+ only needs an update if you change passphrases.
+
+
+ * 6.2 How do I backup a LUKS header?
+
+ While you could just copy the appropriate number of bytes from the
+ start of the LUKS partition, the best way is to use command option
+ "luksHeaderBackup" of cryptsetup. This protects also against
+ errors when non-standard parameters have been used in LUKS
+ partition creation. Example:
+
+
+ cryptsetup luksHeaderBackup --header-backup-file <file> <device>
+
+ To restore, use the inverse command, i.e.
+
+ cryptsetup luksHeaderRestore --header-backup-file <file> <device>
+
+
+ * 6.3 How do I test a LUKS header?
+
+ Use
+
+ cryptsetup -v isLuks <device>
+
+ on the device. Without the "-v" it just signals its result via
+ exit-status. You can also use the more general test
+
+ blkid -p <device>
+
+ which will also detect other types and give some more info. Omit
+ "-p" for old versions of blkid that do not support it.
+
+
+ * 6.4 How do I backup a LUKS or dm-crypt partition?
+
+ There are two options, a sector-image and a plain file or
+ filesystem backup of the contents of the partition. The sector
+ image is already encrypted, but cannot be compressed and contains
+ all empty space. The filesystem backup can be compressed, can
+ contain only part of the encrypted device, but needs to be
+ encrypted separately if so desired.
+
+ A sector-image will contain the whole partition in encrypted form,
+ for LUKS the LUKS header, the keys-slots and the data area. It can
+ be done under Linux e.g. with dd_rescue (for a direct image copy)
+ and with "cat" or "dd". Example:
+
+ cat /dev/sda10 > sda10.img
+ dd_rescue /dev/sda10 sda10.img
+
+ You can also use any other backup software that is capable of making
+ a sector image of a partition. Note that compression is
+ ineffective for encrypted data, hence it does not make sense to
+ use it.
+
+ For a filesystem backup, you decrypt and mount the encrypted
+ partition and back it up as you would a normal filesystem. In this
+ case the backup is not encrypted, unless your encryption method
+ does that. For example you can encrypt a backup with "tar" as
+ follows with GnuPG:
+
+ tar cjf - <path> | gpg --cipher-algo AES -c - > backup.tbz2.gpg
+
+ And verify the backup like this if you are at "path":
+
+ cat backup.tbz2.gpg | gpg - | tar djf -
+
+ Note: Always verify backups, especially encrypted ones.
+
+ In both cases GnuPG will ask you interactively for your symmetric
+ key. The verify will only output errors. Use "tar dvjf -" to get
+ all comparison results. To make sure no data is written to disk
+ unencrypted, turn off swap if it is not encrypted before doing the
+ backup.
+
+ You can of course use different or no compression and you can use
+ an asymmetric key if you have one and have a backup of the secret
+ key that belongs to it.
+
+ A second option for a filesystem-level backup that can be used when
+ the backup is also on local disk (e.g. an external USB drive) is
+ to use a LUKS container there and copy the files to be backed up
+ between both mounted containers. Also see next item.
+
+
+ * 6.5 Do I need a backup of the full partition? Would the header and
+ key-slots not be enough?
+
+ Backup protects you against two things: Disk loss or corruption
+ and user error. By far the most questions on the dm-crypt mailing
+ list about how to recover a damaged LUKS partition are related
+ to user error. For example, if you create a new filesystem on a
+ LUKS partition, chances are good that all data is lost
+ permanently.
+
+ For this case, a header+key-slot backup would often be enough. But
+ keep in mind that a well-treated (!) HDD has roughly a failure
+ risk of 5% per year. It is highly advisable to have a complete
+ backup to protect against this case.
+
+
+ * *6.6 What do I need to backup if I use "decrypt_derived"?
+
+ This is a script in Debian, intended for mounting /tmp or swap with
+ a key derived from the master key of an already decrypted device.
+ If you use this for an device with data that should be persistent,
+ you need to make sure you either do not lose access to that master
+ key or have a backup of the data. If you derive from a LUKS
+ device, a header backup of that device would cover backing up the
+ master key. Keep in mind that this does not protect against disk
+ loss.
+
+ Note: If you recreate the LUKS header of the device you derive from
+ (using luksFormat), the master key changes even if you use the same
+ passphrase(s) and you will not be able to decrypt the derived
+ device with the new LUKS header.
+
+
+ * 6.7 Does a backup compromise security?
+
+ Depends on how you do it. However if you do not have one, you are
+ going to eventually lose your encrypted data.
+
+ There are risks introduced by backups. For example if you
+ change/disable a key-slot in LUKS, a binary backup of the partition
+ will still have the old key-slot. To deal with this, you have to
+ be able to change the key-slot on the backup as well, securely
+ erase the backup or do a filesystem-level backup instead of a binary
+ one.
+
+ If you use dm-crypt, backup is simpler: As there is no key
+ management, the main risk is that you cannot wipe the backup when
+ wiping the original. However wiping the original for dm-crypt
+ should consist of forgetting the passphrase and that you can do
+ without actual access to the backup.
+
+ In both cases, there is an additional (usually small) risk with
+ binary backups: An attacker can see how many sectors and which
+ ones have been changed since the backup. To prevent this, use a
+ filesystem level backup method that encrypts the whole backup in
+ one go, e.g. as described above with tar and GnuPG.