« back to all changes in this revision
Viewing changes to FAQ
- browse files at revision 34
- compare with another revision
- download diff
- download tarball
- view history from revision 34
- Committer: Package Import Robot
- Author(s): Jonas Meurer
- Date: 2014-03-04 20:14:07 UTC
- mfrom: (0.2.13)
- Revision ID: package-import@ubuntu.com-20140304201407-8cn7znmyssyrgduu
Tags: 2:1.6.6-1
* new upsream version 1.6.6.
* add versioned dependency on cryptsetup-bin to cryptsetup. (closes: #747670)
* change versioned build-depends on automake to >= 1.12 to reflect upstream
requirements. Thanks to Joel Johnson. (closes: #740688)
* build and link against libgcrypt20 (>= 1.6.1). Add note about whirlpool
bug in older libgcrypt releases and how to deal with it to debian/NEWS.
* add systemd support to askpass. Thanks to David Härdeman for the patch.
(closes: #742600, #755074)
* fix initramfs cryptroot hook to not include modules unconditionally. Thanks
to Dmitrijs Ledkovs for bugreport and patch. (closes: #714104)
* fix decrypt_keyctl script to ask again in case of wrong passphrase. Thanks
to Dmitriy Matrosov for bugreport and patch. (closes: #748368)
* incorporate changes from ubuntu package:
- don't hardcode paths to udevadm and udevsettle.
- restore terminal settings in askpass.c. (closes: #714942)
- migrate upstart jobs to new names.
* add versioned dependency on cryptsetup-bin to cryptsetup. (closes: #747670)
* change versioned build-depends on automake to >= 1.12 to reflect upstream
requirements. Thanks to Joel Johnson. (closes: #740688)
* build and link against libgcrypt20 (>= 1.6.1). Add note about whirlpool
bug in older libgcrypt releases and how to deal with it to debian/NEWS.
* add systemd support to askpass. Thanks to David Härdeman for the patch.
(closes: #742600, #755074)
* fix initramfs cryptroot hook to not include modules unconditionally. Thanks
to Dmitrijs Ledkovs for bugreport and patch. (closes: #714104)
* fix decrypt_keyctl script to ask again in case of wrong passphrase. Thanks
to Dmitriy Matrosov for bugreport and patch. (closes: #748368)
* incorporate changes from ubuntu package:
- don't hardcode paths to udevadm and udevsettle.
- restore terminal settings in askpass.c. (closes: #714942)
- migrate upstart jobs to new names.
- files added:
- docs/v1.6.5-ReleaseNotes
- files modified:
- AUTHORS
added
removed
FAQ
41
41
SSDs/FLASH DRIVES: SSDs and Flash are different. Currently it is
42
42
unclear how to get LUKS or plain dm-crypt to run on them with the
43
43
full set of security features intact. This may or may not be a
44
problem, depending on the attacher model. See Section 5.19.
44
problem, depending on the attacker model. See Section 5.19.
45
45
46
46
BACKUP: Yes, encrypted disks die, just as normal ones do. A full
47
47
backup is mandatory, see Section "6. Backup and Data Recovery" on
268
268
Note that automatic wiping is on the TODO list for cryptsetup, so
269
269
at some time in the future this will become unnecessary.
270
270
271
Alternatively, plain cm-crypt can be used for a very fast wipe with
272
crypto-grade randomness, see Item 2.19
273
271
274
04) Create the LUKS container:
272
275
cryptsetup luksFormat <target device>
273
276
322
325
easy to make, but will compromise your security.
323
326
324
327
325
* 2.2 How do I set up encrypted swap?
328
* 2.2 LUKS on partitions or raw disks?
329
330
This is a complicated question, and made more so by the availability
331
of RAID and LVM. I will try to give some scenarios and discuss
332
advantages and disadvantages. Note that I say LUKS for simplicity,
333
but you can do all the things described with plain dm-crypt as well.
334
Also note that your specific scenario may be so special that most
335
or even all things I say below do not apply.
336
337
Be aware that if you add LVM into the mix, things can get very
338
complicated. Same with RAID but less so. In particular, data
339
recovery can get exceedingly difficult. Only do so if you have a
340
really good reason and always remember KISS is what separates an
341
engineer from an amateur. Of course, if you really need the added
342
complexity, KISS is satisfied. But be very sure as there is a price
343
to pay for it. In engineering, complexity is always the enemy and
344
needs to be fought without mercy when encountered.
345
346
Also consider using RAID instead of LVM, as at least with the old
347
superblock format 0.90, the RAID superblock is in the place (end
348
of disk) where the risk of it permanently damaging the LUKS header
349
is smallest and you can have your array assembled by the RAID
350
controller (i.e. the kernel), as it should be. Use partition type
351
0xfd for that. I recommend staying away from superblock formats
352
1.0, 1.1 and 1.2 unless you really need them. Be aware that you
353
lose autodetection with them and have to fall back to some
354
user-space script to do it.
355
356
Scenarios:
357
358
(1) Encrypted partition: Just make a partition to your liking,
359
and put LUKS on top of it and a filesystem into the LUKS container.
360
This gives you isolation of differently-tasked data areas, just as
361
ordinary partitioning does. You can have confidential data,
362
non-confidential data, data for some specific applications,
363
user-homes, root, etc. Advantages are simplicity as there is a 1:1
364
mapping between partitions and filesystems, clear security
365
functionality and the ability to separate data into different,
366
independent (!) containers.
367
368
Note that you cannot do this for encrypted root, that requires an
369
initrd. On the other hand, an initrd is about as vulnerable to a
370
competent attacker as a non-encrypted root, so there really is no
371
security advantage to doing it that way. An attacker that wants to
372
compromise your system will just compromise the initrd or the
373
kernel itself. The better way to deal with this is to make sure the
374
root partition does not store any critical data and move that to
375
additional encrypted partitions. If you really are concerned your
376
root partition may be sabotaged by somebody with physical access
377
(that would however strangely not, say, sabotage your BIOS,
378
keyboard, etc.), protect it in some other way. The PC is just not
379
set-up for a really secure boot-chain (whatever some people may
380
claim).
381
382
(2) Fully encrypted raw block device: For this, put LUKS on the
383
raw device (e.g. /dev/sdb) and put a filesystem into the LUKS
384
container, no partitioning whatsoever involved. This is very
385
suitable for things like external USB disks used for backups or
386
offline data-storage.
387
388
(3) Encrypted RAID: Create your RAID from partitions and/or full
389
devices. Put LUKS on top of the RAID device, just if it were an
390
ordinary block device. Applications are just the same as above, but
391
you get redundancy. (Side note as many people seem to be unaware of
392
it: You can do RAID1 with an arbitrary number of components in
393
Linux.) See also Item 2.8.
394
395
(4) Now, some people advocate doing the encryption below the RAID
396
layer. That has several serious problems. One is that suddenly
397
debugging RAID issues becomes much harder. You cannot do automatic
398
RAID assembly anymore. You need to keep the encryption keys for the
399
components in sync or manage them somehow. The only possible
400
advantage is that things may run a little faster as more CPUs do
401
the encryption, but if speed is a priority over security and
402
simplicity, you are doing this wrong anyways. A good way to
403
mitigate a speed issue is to get a CPU that does hardware AES.
404
405
406
* 2.3 How do I set up encrypted swap?
326
407
327
408
As things that are confidential can end up in swap (keys,
328
409
passphrases, etc. are usually protected against being swapped to
378
459
swapon /dev/mapper/swap
379
460
380
461
381
* 2.3 What is the difference between "plain" and LUKS format?
462
* 2.4 What is the difference between "plain" and LUKS format?
382
463
383
464
First, unless you happen to understand the cryptographic background
384
465
well, you should use LUKS. It does protect the user from a lot of
443
524
non-default XTS mode).
444
525
445
526
446
* 2.4 Can I encrypt an already existing, non-empty partition to use
527
* 2.5 Can I encrypt an already existing, non-empty partition to use
447
528
LUKS?
448
529
449
530
There is no converter, and it is not really needed. The way to do
458
539
to be in a filesystem.
459
540
460
541
461
* 2.5 How do I use LUKS with a loop-device?
542
* 2.6 How do I use LUKS with a loop-device?
462
543
463
544
This can be very handy for experiments. Setup is just the same as
464
545
with any block device. If you want, for example, to use a 100MiB
472
553
To unmap the file when done, use "losetup -d /dev/loop0".
473
554
474
555
475
* 2.6 When I add a new key-slot to LUKS, it asks for a passphrase but
556
* 2.7 When I add a new key-slot to LUKS, it asks for a passphrase but
476
557
then complains about there not being a key-slot with that
477
558
passphrase?
478
559
484
565
new key-slot.
485
566
486
567
487
* 2.7 Encryption on top of RAID or the other way round?
568
* 2.8 Encryption on top of RAID or the other way round?
488
569
489
570
Unless you have special needs, place encryption between RAID and
490
571
filesystem, i.e. encryption on top of RAID. You can do it the other
510
591
encrypted.
511
592
512
593
513
* 2.8 How do I read a dm-crypt key from file?
594
* 2.9 How do I read a dm-crypt key from file?
514
595
515
596
Use the --key-file option, like this:
516
597
525
606
detail.
526
607
527
608
528
* 2.9 How do I read a LUKS slot key from file?
609
* 2.10 How do I read a LUKS slot key from file?
529
610
530
611
What you really do here is to read a passphrase from file, just as
531
612
you would with manual entry of a passphrase for a key-slot. You can
551
632
cryptsetup luksOpen --key-file keyfile /dev/loop0 e1
552
633
553
634
554
* 2.10 How do I read the LUKS master key from file?
635
* 2.11 How do I read the LUKS master key from file?
555
636
556
637
The question you should ask yourself first is why you would want to
557
638
do this. The only legitimate reason I can think of is if you want
562
643
do this here.
563
644
564
645
565
* 2.11 What are the security requirements for a key read from file?
646
* 2.12 What are the security requirements for a key read from file?
566
647
567
648
A file-stored key or passphrase has the same security requirements
568
649
as one entered interactively, however you can use random bytes and
574
655
head -c 256 /dev/random > keyfile
575
656
576
657
577
* 2.12 If I map a journaled file system using dm-crypt/LUKS, does it
658
* 2.13 If I map a journaled file system using dm-crypt/LUKS, does it
578
659
still provide its usual transactional guarantees?
579
660
580
661
Yes, it does, unless a very old kernel is used. The required flags
602
683
should improve further and eventually the problem should go away.
603
684
604
685
605
* 2.13 Can I use LUKS or cryptsetup with a more secure (external)
686
* 2.14 Can I use LUKS or cryptsetup with a more secure (external)
606
687
medium for key storage, e.g. TPM or a smartcard?
607
688
608
689
Yes, see the answers on using a file-supplied key. You do have to
616
697
related to the cryptsetup project.
617
698
618
699
619
* 2.14 Can I resize a dm-crypt or LUKS partition?
700
* 2.15 Can I resize a dm-crypt or LUKS partition?
620
701
621
702
Yes, you can, as neither dm-crypt nor LUKS stores partition size.
622
703
Whether you should is a different question. Personally I recommend
636
717
for that.
637
718
638
719
639
* 2.15 How do I Benchmark the Ciphers, Hashes and Modes?
720
* 2.16 How do I Benchmark the Ciphers, Hashes and Modes?
640
721
641
722
Since version 1.60 cryptsetup supports the "benchmark" command.
642
723
Simply run as root:
652
733
and half of it is the cipher key, the other half is the XTS key.
653
734
654
735
655
* 2.16 How do I Verify I have an Authentic cryptsetup Source Package?
736
* 2.17 How do I Verify I have an Authentic cryptsetup Source Package?
656
737
657
738
Current maintainer is Milan Broz and he signs the release packages
658
739
with his PGP key. The key he currently uses is the "RSA key ID
677
758
longer as an FAQ can sustain. If in doubt, ask on the mailing list.
678
759
679
760
680
* 2.17 Is there a concern with 4k Sectors?
761
* 2.18 Is there a concern with 4k Sectors?
681
762
682
763
Not from dm-crypt itself. Encryption will be done in 512B blocks,
683
764
but if the partition and filesystem are aligned correctly and the
689
770
misaligned, dm-crypt can make the effect worse though.
690
771
691
772
773
* 2.19 How can I wipe a device with crypto-grade randomness?
774
775
The conventional recommendation if you want to not just do a
776
zero-wipe is to use something like
777
778
cat /dev/urandom > <taget-device>
779
780
That is very slow and painful at 10-20MB/s on a fast computer.
781
Using cryptsetup and a plain dm-crypt device with a random key, it
782
is much faster and gives you the same level of security. The
783
defaults are quite enough.
784
785
For device set-up, do the following:
786
787
cryptsetup open --type plain -d /dev/urandom /dev/<block-device> to_be_wiped
788
789
Then you have several options. Simple wipe without
790
progress-indicator:
791
792
cat /dev/zero > /dev/mapper/to_be_wiped
793
794
Progress-indicator by dd_rescue:
795
796
dd_rescue -w /dev/zero /dev/mapper/to_be_wiped
797
798
Progress-indicator by my "wcs" stream meter (available from
799
http://www.tansi.org/tools/index.html ):
800
801
cat /dev/zero | wcs > /dev/mapper/to_be_wiped
802
803
Remove the mapping at the end and you are done.
804
805
692
806
3. Common Problems
693
807
694
808
1124
1238
new filesystem on the raw LUKS partition, making the raw partition
1125
1239
part of a raid array and just writing to the raw partition.
1126
1240
1127
The LUKS header contains a 256 bit "salt" value and without that no
1128
decryption is possible. While the salt is not secret, it is
1129
key-grade material and cannot be reconstructed. This is a
1241
The LUKS header contains a 256 bit "salt" per key-slot and without
1242
that no decryption is possible. While the salts are not secret,
1243
they are key-grade material and cannot be reconstructed. This is a
1130
1244
cryptographically strong "cannot". From observations on the
1131
1245
cryptsetup mailing-list, people typically go though the usual
1132
1246
stages of grief (Denial, Anger, Bargaining, Depression, Acceptance)
1135
1249
fine. Even if we usually cannot help with getting back your data,
1136
1250
most people found the feedback comforting.
1137
1251
1138
If your header does not contain an intact salt, best go directly
1139
to the last stage ("Acceptance") and think about what to do now.
1140
There is one exception that I know of: If your LUKS container is
1141
still open, then it may be possible to extract the master key from
1142
the running system. See Item "How do I recover the master key from
1143
a mapped LUKS container?" in Section "Backup and Data Recovery".
1252
If your header does not contain an intact key-slot salt, best go
1253
directly to the last stage ("Acceptance") and think about what to
1254
do now. There is one exception that I know of: If your LUKS
1255
container is still open, then it may be possible to extract the
1256
master key from the running system. See Item "How do I recover the
1257
master key from a mapped LUKS container?" in Section "Backup and
1258
Data Recovery".
1144
1259
1145
1260
1146
1261
* 5.8 What is a "salt"?
1669
1784
1670
1785
cryptsetup luksHeaderRestore --header-backup-file <file> <device>
1671
1786
1787
If you are unsure about a header to be restored, make a backup of
1788
the current one first! You can also test the header-file without
1789
restoring it by using the --header option for a detached header
1790
like this:
1791
1792
cryptsetup --header <file> luksOpen <device> </dev/mapper/ -name>
1793
1794
If that unlocks your keys-lot, you are good. Do not forget to close
1795
the device again.
1796
1672
1797
1673
1798
* 6.3 How do I test a LUKS header?
1674
1799
1719
1844
1720
1845
cat backup.tbz2.gpg | gpg - | tar djf -
1721
1846
1722
Note: Always verify backups, especially encrypted ones.
1847
Note: Always verify backups, especially encrypted ones!
1848
1849
There is one problem with verifying like this: The kernel may still
1850
have some files cached and in fact verify them against RAM or may
1851
even verify RAM against RAM, which defeats the purpose of the
1852
exercise. The following command empties the kernel caches:
1853
1854
echo 3 > /proc/sys/vm/drop_caches
1855
1856
Run it after backup and before verify.
1723
1857
1724
1858
In both cases GnuPG will ask you interactively for your symmetric
1725
1859
key. The verify will only output errors. Use "tar dvjf -" to get
1727
1861
unencrypted, turn off swap if it is not encrypted before doing the
1728
1862
backup.
1729
1863
1864
Restore works like certification with the 'd' ('difference')
1865
replaced by 'x' ('eXtract'). Refer to the man-page of tar for more
1866
explanations and instructions. Note that with default options tar
1867
will overwrite already existing files without warning. If you are
1868
unsure about how to use tar, experiment with it in a location
1869
where you cannot do damage.
1870
1730
1871
You can of course use different or no compression and you can use
1731
1872
an asymmetric key if you have one and have a backup of the secret
1732
1873
key that belongs to it.
1810
1951
damage the LUKS header or key-slots?
1811
1952
1812
1953
There are two critical components for decryption: The salt values
1813
in the header itself and the key-slots. If the salt values are
1814
overwritten or changed, nothing (in the cryptographically strong
1815
sense) can be done to access the data, unless there is a backup
1816
of the LUKS header. If a key-slot is damaged, the data can still
1817
be read with a different key-slot, if there is a remaining
1818
undamaged and used key-slot. Note that in order to make a key-slot
1819
unrecoverable in a cryptographically strong sense, changing about
1820
4-6 bits in random locations of its 128kiB size is quite enough.
1954
in the key-slot descriptors of the header and the key-slots. If the
1955
salt values are overwritten or changed, nothing (in the
1956
cryptographically strong sense) can be done to access the data,
1957
unless there is a backup of the LUKS header. If a key-slot is
1958
damaged, the data can still be read with a different key-slot, if
1959
there is a remaining undamaged and used key-slot. Note that in
1960
order to make a key-slot unrecoverable in a cryptographically
1961
strong sense, changing about 4-6 bits in random locations of its
1962
128kiB size is quite enough.
1821
1963
1822
1964
1823
1965
* 6.9 What happens if I (quick) format a LUKS partition?
1951
2093
The exact specification of the format is here:
1952
2094
http://code.google.com/p/cryptsetup/wiki/Specification
1953
2095
2096
For your convenience, here is the LUKS header with hex offsets.
2097
NOTE: The spec counts key-slots from 1 to 8, but the cryptsetup
2098
tool counts from 0 to 7. The numbers here refer to the cryptsetup
2099
numbers.
2100
2101
Refers to LUKS On-Disk Format Specification Version 1.2.1
2102
LUKS header:
2103
offset length name data type description
2104
-----------------------------------------------------------------------
2105
0x0000 0x06 magic byte[] 'L','U','K','S', 0xba, 0xbe
2106
0 6
2107
0x0006 0x02 version uint16_t LUKS version
2108
6 3
2109
0x0008 0x20 cipher-name char[] cipher name spec.
2110
8 32
2111
0x0028 0x20 cipher-mode char[] cipher mode spec.
2112
40 32
2113
0x0048 0x20 hash-spec char[] hash spec.
2114
72 32
2115
0x0068 0x04 payload-offset uint32_t bulk data offset in sectors
2116
104 4 (512 bytes per sector)
2117
0x006c 0x04 key-bytes uint32_t number of bytes in key
2118
108 4
2119
0x0070 0x14 mk-digest byte[] master key checksum
2120
112 20 calculated with PBKDF2
2121
0x0084 0x20 mk-digest-salt byte[] salt for PBKDF2 when
2122
132 32 calculating mk-digest
2123
0x00a4 0x04 mk-digest-iter uint32_t iteration count for PBKDF2
2124
164 4 when calculating mk-digest
2125
0x00a8 0x28 uuid char[] partition UUID
2126
168 40
2127
0x00d0 0x30 key-slot-0 key slot key slot 0
2128
208 48
2129
0x0100 0x30 key-slot-1 key slot key slot 1
2130
256 48
2131
0x0130 0x30 key-slot-2 key slot key slot 2
2132
304 48
2133
0x0160 0x30 key-slot-3 key slot key slot 3
2134
352 48
2135
0x0190 0x30 key-slot-4 key slot key slot 4
2136
400 48
2137
0x01c0 0x30 key-slot-5 key slot key slot 5
2138
448 48
2139
0x01f0 0x30 key-slot-6 key slot key slot 6
2140
496 48
2141
0x0220 0x30 key-slot-7 key slot key slot 7
2142
544 48
2143
Key slot:
2144
offset length name data type description
2145
-------------------------------------------------------------------------
2146
0x0000 0x04 active uint32_t key slot enabled/disabled
2147
0 4
2148
0x0004 0x04 iterations uint32_t PBKDF2 iteration count
2149
4 4
2150
0x0008 0x20 salt byte[] PBKDF2 salt
2151
8 32
2152
0x0028 0x04 key-material-offset uint32_t key start sector
2153
40 4 (512 bytes/sector)
2154
0x002c 0x04 stripes uint32_t number of anti-forensic
2155
44 4 stripes
2156
1954
2157
1955
2158
* 6.13 What is the smallest possible LUKS container?
1956
2159
2157
2360
accessible anymore!
2158
2361
2159
2362
With cryptsetup 1.1.x, the distro maintainer can define different
2160
default encryption modes for LUKS and plain devices. You can check
2161
these compiled-in defaults using "cryptsetup --help". Moreover, the
2162
plain device default changed because the old IV mode was
2163
vulnerable to a watermarking attack.
2363
default encryption modes. You can check the compiled-in defaults
2364
using "cryptsetup --help". Moreover, the plain device default
2365
changed because the old IV mode was vulnerable to a watermarking
2366
attack.
2164
2367
2165
2368
If you are using a plain device and you need a compatible mode, just
2166
2369
specify cipher, key size and hash algorithm explicitly. For
2186
2389
It is the other way round: In gcrypt 1.5.3 and before Whirlpool is
2187
2390
broken and it was fixed in the next version. If you selected
2188
2391
whirlpool as hash on creation of a LUKS container, it does not work
2189
anymore with the fixed library. Currently, the only work-around is
2190
to decrypt with the old version. This also shows one risk of using
2191
rarely used settings.
2392
anymore with the fixed library. This shows one serious risk of
2393
using rarely used settings.
2394
2395
The only two ways to deal with this are either to decrypt with an
2396
old gcrypt version that has the flaw or to use a compatibility
2397
feature introduced in cryptsetup 1.6.4 and gcrypt 1.6.1 or later.
2398
Versions of gcrypt between 1.5.4 and 1.6.0 cannot be used.
2399
2400
Steps:
2401
2402
- Make a least a header backup or better, refresh your full
2403
backup. (You have a full backup, right? See Item 6.1 and
2404
following.)
2405
2406
- Make sure you have cryptsetup 1.6.4 or later and check the gcrypt
2407
version:
2408
2409
2410
cryptsetup luksDump <your luks device> --debug | grep backend
2411
2412
If gcrypt is at version 1.5.3 or before:
2413
2414
- Reencrypt the LUKS header with a different hash. (Requires
2415
entering all keyslot passphrases. If you do not have all, remove
2416
the ones you do not have before.):
2417
2418
cryptsetup-reencrypt --keep-key --hash sha256 <your luks device>
2419
2420
If gcrypt is at version 1.6.1 or later:
2421
2422
- Patch the hash name in the LUKS header from "whirlpool" to
2423
"whirlpool_gcryptbug". This activates the broken implementation.
2424
The detailed header layout is in Item 6.12 of this FAQ and in the
2425
LUKS on-disk format specification. One way to change the hash is
2426
with the following command:
2427
2428
echo -n -e 'whirlpool_gcryptbug\0' | dd of=<luks device> bs=1 seek=72 conv=notrunc
2429
2430
- You can now open the device again. It is highly advisable to
2431
change the hash now with cryptsetup-reencrypt as described above.
2432
While you can reencrypt to use the fixed whirlpool, that may not
2433
be a good idea as almost nobody seems to use it and hence the long
2434
time until the bug was discovered.
2192
2435
2193
2436
2194
2437
9. References and Further Reading
Loggerhead is a web-based interface for Breezy
Version: 2.0.1