such a disaster! In particular, make sure you have a current header
backup before doing any potentially dangerous operations.
+ SSDs/FLASH DRIVES: SSDs and Flash are different. Currently it is
+ unclear how to get LUKS or plain dm-crypt to run on them with the
+ full set of security features intact. This may or may not be a
+ problem, depending on the attacher model. See Section 5.17.
+
BACKUP: Yes, encrypted disks die, just as normal ones do. A full
backup is mandatory, see Section "6. Backup and Data Recovery" on
options for doing encrypted backup.
PASSPHRASE CHARACTER SET: Some people have had difficulties with
this when upgrading distributions. It is highly advisable to only
- use the 94 printable characters from the first 128 characters of
+ use the 95 printable characters from the first 128 characters of
the ASCII table, as they will always have the same binary
representation. Other characters may have different encoding
depending on system configuration and your passphrase will not
http://en.wikipedia.org/wiki/ASCII
- * 1.3 System Specific warnings
+ * 1.3 System specific warnings
- Ubuntu as of 4/2011: It seems the installer offers to create
LUKS partitions in a way that several people mistook for an offer
This issue has been acknowledged by the Ubuntu dev team, see here:
http://launchpad.net/bugs/420080
+ Update 7/2012: I am unsure whether this has been fixed by now, best
+ be careful.
+
+
+ * 1.4 My LUKS-device is broken! Help!
+
+ First: Do not panic! In many cases the data is still recoverable.
+ Do not do anything hasty! Steps:
+
+ - Take some deep breaths. Maybe add some relaxing music. This may
+ sound funny, but I am completely serious. Often, critical damage is
+ done only after the initial problem.
+
+ - Do not reboot. The keys mays still be in the kernel if the device
+ is mapped.
+
+ - Make sure others do not reboot the system.
+
+ - Do not write to your disk without a clear understanding why this
+ will not make matters worse. Do a sector-level backup before any
+ writes. Often you do not need to write at all to get enough access
+ to make a backup of the data.
- * 1.4 Who wrote this?
+ - Relax some more.
+
+ - Read section 6 of this FAQ.
+
+ - Ask on the mailing-list if you need more help.
+
+
+ * 1.5 Who wrote this?
Current FAQ maintainer is Arno Wagner <arno@wagner.name>. Other
contributors are listed at the end. If you want to contribute, send
* 2.1 What is the difference between "plain" and LUKS format?
+ First, unless you happen to understand the cryptographic background
+ well, you should use LUKS. It does protect the user from a lot of
+ common mistakes. Plain dm-crypt is for experts.
+
Plain format is just that: It has no metadata on disk, reads all
parameters from the commandline (or the defaults), derives a
master-key from the passphrase and then uses that to de-/encrypt
foot, you can figure out how to do it yourself.
+ * 5.17 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
process, except generating a new LUKS header with the old master
key (it prints the command for that though):
-http://code.google.com/p/cryptsetup/source/browse/trunk/misc/luks-header-from-active
+http://code.google.com/p/cryptsetup/source/browse/misc/luks-header-from-active
You can also do this manually. Here is how:
projects / platform / upstream / cryptsetup.git / blobdiff