forked from mbroz/cryptsetup
-
Notifications
You must be signed in to change notification settings - Fork 6
/
Copy pathFAQ
2621 lines (1918 loc) · 111 KB
/
FAQ
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
894
895
896
897
898
899
900
901
902
903
904
905
906
907
908
909
910
911
912
913
914
915
916
917
918
919
920
921
922
923
924
925
926
927
928
929
930
931
932
933
934
935
936
937
938
939
940
941
942
943
944
945
946
947
948
949
950
951
952
953
954
955
956
957
958
959
960
961
962
963
964
965
966
967
968
969
970
971
972
973
974
975
976
977
978
979
980
981
982
983
984
985
986
987
988
989
990
991
992
993
994
995
996
997
998
999
1000
Frequently Asked Questions.
Sections
1. General Questions
2. Setup
3. Common Problems
4. Troubleshooting
5. Security Aspects
6. Backup and Data Recovery
7. Interoperability with other Disk Encryption Tools
8. Issues with Specific Versions of cryptsetup
9. References and Further Reading
A. Contributors
1. General Questions
* 1.1 What is this?
This is the FAQ (Frequently Asked Questions) for cryptsetup. It
covers Linux disk encryption with plain dm-crypt (one passphrase, no
management, no metadata on disk) and LUKS (multiple user keys with
one master key, anti-forensic features, metadata block at start of
device, ...). The latest version of this FAQ should usually be
available at
https://gitlab.com/cryptsetup/cryptsetup/wikis/FrequentlyAskedQuestions
* 1.2 WARNINGS
ATTENTION: If you are going to read just one thing, make it the
section on Backup and Data Recovery. By far the most questions on
the cryptsetup mailing list are from people that managed to damage
the start of their LUKS partitions, i.e. the LUKS header. In most
cases, there is nothing that can be done to help these poor souls
recover their data. Make sure you understand the problem and
limitations imposed by the LUKS security model BEFORE you face such a
disaster! In particular, make sure you have a current header backup
before doing any potentially dangerous operations.
DEBUG COMMANDS: While the --debug option does not leak data, "strace"
and the like can leak your full passphrase. Do not post an strace
output with the correct passphrase to a mailing-list or online! See
Item 4.5 for more explanation.
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 attacker model. See Section 5.19.
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.
CLONING/IMAGING: If you clone or image a LUKS container, you make a
copy of the LUKS header and the master key will stay the same! That
means that if you distribute an image to several machines, the same
master key will be used on all of them, regardless of whether you
change the passphrases. Do NOT do this! If you do, a root-user on
any of the machines with a mapped (decrypted) container or a
passphrase on that machine can decrypt all other copies, breaking
security. See also Item 6.15.
DISTRIBUTION INSTALLERS: Some distribution installers offer to create
LUKS containers in a way that can be mistaken as activation of an
existing container. Creating a new LUKS container on top of an
existing one leads to permanent, complete and irreversible data loss.
It is strongly recommended to only use distribution installers after
a complete backup of all LUKS containers has been made.
UBUNTU INSTALLER: In particular the Ubuntu installer seems to be
quite willing to kill LUKS containers in several different ways.
Those responsible at Ubuntu seem not to care very much (it is very
easy to recognize a LUKS container), so treat the process of
installing Ubuntu as a severe hazard to any LUKS container you may
have.
NO WARNING ON NON-INTERACTIVE FORMAT: If you feed cryptsetup from
STDIN (e.g. via GnuPG) on LUKS format, it does not give you the
warning that you are about to format (and e.g. will lose any
pre-existing LUKS container on the target), as it assumes it is used
from a script. In this scenario, the responsibility for warning the
user and possibly checking for an existing LUKS header is shifted to
the script. This is a more general form of the previous item.
LUKS PASSPHRASE IS NOT THE MASTER KEY: The LUKS passphrase is not
used in deriving the master key. It is used in decrypting a master
key that is randomly selected on header creation. This means that if
you create a new LUKS header on top of an old one with exactly the
same parameters and exactly the same passphrase as the old one, it
will still have a different master key and your data will be
permanently lost.
PASSPHRASE CHARACTER SET: Some people have had difficulties with this
when upgrading distributions. It is highly advisable to only 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 work with a different
encoding. A table of the standardized first 128 ASCII characters
can, e.g. be found on http://en.wikipedia.org/wiki/ASCII
KEYBOARD NUM-PAD: Apparently some pre-boot authentication
environments (these are done by the distro, not by cryptsetup, so
complain there) treat digits entered on the num-pad and ones entered
regularly different. This may be because the BIOS USB keyboard
driver is used and that one may have bugs on some computers. If you
cannot open your device in pre-boot, try entering the digits over the
regular digit keys.
* 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 to
activate their existing LUKS partition. The installer gives no or an
inadequate warning and will destroy your old LUKS header, causing
permanent data loss. See also the section on Backup and Data
Recovery.
This issue has been acknowledged by the Ubuntu dev team, see
here: http://launchpad.net/bugs/420080
Update 4/2013: I am still unsure whether this has been fixed by now,
best be careful. They also seem to have added even more LUKS killer
functionality to the Ubuntu installer. I can only strongly
recommended to not install Ubuntu on a system with existing LUKS
containers without complete backups.
Update 11/2014: There seem to be other problems withe existing LUKS
containers and Ubuntu as well, be extra careful when using LUKS
on Ubuntu in any way, but exactly as the Ubuntu installer does.
* 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 may 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.
- 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>. If you want
to send me encrypted email, my current PGP key is DSA key CB5D9718,
fingerprint 12D6 C03B 1B30 33BB 13CF B774 E35C 5FA1 CB5D 9718.
Other contributors are listed at the end. If you want to contribute,
send your article, including a descriptive headline, to the
maintainer, or the dm-crypt mailing list with something like "FAQ
..." in the subject. You can also send more raw information and have
me write the section. Please note that by contributing to this FAQ,
you accept the license described below.
This work is under the "Attribution-Share Alike 3.0 Unported"
license, which means distribution is unlimited, you may create
derived works, but attributions to original authors and this license
statement must be retained and the derived work must be under the
same license. See http://creativecommons.org/licenses/by-sa/3.0/ for
more details of the license.
Side note: I did text license research some time ago and I think this
license is best suited for the purpose at hand and creates the least
problems.
* 1.6 Where is the project website?
There is the project website at
https://gitlab.com/cryptsetup/cryptsetup/ Please do not post
questions there, nobody will read them. Use the mailing-list
instead.
* 1.7 Is there a mailing-list?
Instructions on how to subscribe to the mailing-list are at on the
project website. People are generally helpful and friendly on the
list.
The question of how to unsubscribe from the list does crop up
sometimes. For this you need your list management URL, which is sent
to you initially and once at the start of each month. Go to the URL
mentioned in the email and select "unsubscribe". This page also
allows you to request a password reminder.
Alternatively, you can send an Email to dm-crypt-request@saout.de
with just the word "help" in the subject or message body. Make sure
to send it from your list address.
The mailing list archive is here:
http://dir.gmane.org/gmane.linux.kernel.device-mapper.dm-crypt
* 1.8 Unsubscribe from the mailing-list
Send mail to dm-crypt-unsubscribe@saout.de from the subscribed
account. You will get an email with instructions.
Basically, you just have to respond to it unmodified to get
unsubscribed. The listserver admin functions are not very fast. It
can take 15 minutes or longer for a reply to arrive (I suspect
greylisting is in use), so be patient.
Also note that nobody on the list can unsubscribe you, sending
demands to be unsubscribed to the list just annoys people that are
entirely blameless for you being subscribed.
If you are subscribed, a subscription confirmation email was sent to
your email account and it had to be answered before the subscription
went active. The confirmation emails from the listserver have
subjects like these (with other numbers):
Subject: confirm 9964cf10.....
and are sent from dm-crypt-request@saout.de. You should check whether
you have anything like it in your sent email folder. If you find
nothing and are sure you did not confirm, then you should look into a
possible compromise of your email account.
2. Setup
* 2.1 LUKS Container Setup mini-HOWTO
This item tries to give you a very brief list of all the steps you
should go though when creating a new LUKS encrypted container, i.e.
encrypted disk, partition or loop-file.
01) All data will be lost, if there is data on the target, make a
backup.
02) Make very sure you have the right target disk, partition or
loop-file.
03) If the target was in use previously, it is a good idea to wipe it
before creating the LUKS container in order to remove any trace of
old file systems and data. For example, some users have managed to
run e2fsck on a partition containing a LUKS container, possibly
because of residual ext2 superblocks from an earlier use. This can
do arbitrary damage up to complete and permanent loss of all data in
the LUKS container.
To just quickly wipe file systems (old data may remain), use
wipefs -a <target device>
To wipe file system and data, use something like
cat /dev/zero > <target device>
This can take a while. To get a progress indicator, you can use the
tool dd_rescue (->google) instead or use my stream meter "wcs"
(source here: http://www.tansi.org/tools/index.html) in the following
fashion:
cat /dev/zero | wcs > <target device>
Be very sure you have the right target, all data will be lost!
Note that automatic wiping is on the TODO list for cryptsetup, so at
some time in the future this will become unnecessary.
Alternatively, plain dm-crypt can be used for a very fast wipe with
crypto-grade randomness, see Item 2.19
04) Create the LUKS container:
cryptsetup luksFormat <target device>
Just follow the on-screen instructions.
Note: Passphrase iteration is determined by cryptsetup depending on
CPU power. On a slow device, this may be lower than you want. I
recently benchmarked this on a Raspberry Pi and it came out at about
1/15 of the iteration count for a typical PC. If security is
paramount, you may want to increase the time spent in iteration, at
the cost of a slower unlock later. For the Raspberry Pi, using
cryptsetup luksFormat -i 15000 <target device>
gives you an iteration count and security level equal to an average
PC for passphrase iteration and master-key iteration. If in doubt,
check the iteration counts with
cryptsetup luksDump <target device>
and adjust the iteration count accordingly by creating the container
again with a different iteration time (the number after '-i' is the
iteration time in milicesonds) until your requirements are met.
05) Map the container. Here it will be mapped to /dev/mapper/c1:
cryptsetup luksOpen <target device> c1
06) (Optionally) wipe the container (make sure you have the right
target!):
cat /dev/zero > /dev/mapper/c1
Note that this creates a small information leak, as an attacker can
determine whether a 512 byte block is zero if the attacker has access
to the encrypted container multiple times. Typically a competent
attacker that has access multiple times can install a passphrase
sniffer anyways, so this leakage is not very significant. For
getting a progress indicator, see step 03.
Note that at some time in the future, cryptsetup will do this for
you, but currently it is a TODO list item.
07) Create a file system in the mapped container, for example an
ext3 file system (any other file system is possible):
mke2fs -j /dev/mapper/c1
08) Mount your encrypted file system, here on /mnt:
mount /dev/mapper/c1 /mnt
Done. You can now use the encrypted file system to store data. Be
sure to read though the rest of the FAQ, these are just the very
basics. In particular, there are a number of mistakes that are easy
to make, but will compromise your security.
* 2.2 LUKS on partitions or raw disks?
This is a complicated question, and made more so by the availability
of RAID and LVM. I will try to give some scenarios and discuss
advantages and disadvantages. Note that I say LUKS for simplicity,
but you can do all the things described with plain dm-crypt as well.
Also note that your specific scenario may be so special that most or
even all things I say below do not apply.
Be aware that if you add LVM into the mix, things can get very
complicated. Same with RAID but less so. In particular, data
recovery can get exceedingly difficult. Only do so if you have a
really good reason and always remember KISS is what separates an
engineer from an amateur. Of course, if you really need the added
complexity, KISS is satisfied. But be very sure as there is a price
to pay for it. In engineering, complexity is always the enemy and
needs to be fought without mercy when encountered.
Also consider using RAID instead of LVM, as at least with the old
superblock format 0.90, the RAID superblock is in the place (end of
disk) where the risk of it permanently damaging the LUKS header is
smallest and you can have your array assembled by the RAID controller
(i.e. the kernel), as it should be. Use partition type 0xfd for
that. I recommend staying away from superblock formats 1.0, 1.1 and
1.2 unless you really need them. Be aware that you lose
autodetection with them and have to fall back to some user-space
script to do it.
Scenarios:
(1) Encrypted partition: Just make a partition to your liking, and
put LUKS on top of it and a filesystem into the LUKS container. This
gives you isolation of differently-tasked data areas, just as
ordinary partitioning does. You can have confidential data,
non-confidential data, data for some specific applications,
user-homes, root, etc. Advantages are simplicity as there is a 1:1
mapping between partitions and filesystems, clear security
functionality and the ability to separate data into different,
independent (!) containers.
Note that you cannot do this for encrypted root, that requires an
initrd. On the other hand, an initrd is about as vulnerable to a
competent attacker as a non-encrypted root, so there really is no
security advantage to doing it that way. An attacker that wants to
compromise your system will just compromise the initrd or the kernel
itself. The better way to deal with this is to make sure the root
partition does not store any critical data and move that to
additional encrypted partitions. If you really are concerned your
root partition may be sabotaged by somebody with physical access
(that would however strangely not, say, sabotage your BIOS, keyboard,
etc.), protect it in some other way. The PC is just not set-up for a
really secure boot-chain (whatever some people may claim).
(2) Fully encrypted raw block device: For this, put LUKS on the raw
device (e.g. /dev/sdb) and put a filesystem into the LUKS container,
no partitioning whatsoever involved. This is very suitable for
things like external USB disks used for backups or offline
data-storage.
(3) Encrypted RAID: Create your RAID from partitions and/or full
devices. Put LUKS on top of the RAID device, just if it were an
ordinary block device. Applications are just the same as above, but
you get redundancy. (Side note as many people seem to be unaware of
it: You can do RAID1 with an arbitrary number of components in
Linux.) See also Item 2.8.
(4) Now, some people advocate doing the encryption below the RAID
layer. That has several serious problems. One is that suddenly
debugging RAID issues becomes much harder. You cannot do automatic
RAID assembly anymore. You need to keep the encryption keys for the
components in sync or manage them somehow. The only possible
advantage is that things may run a little faster as more CPUs do the
encryption, but if speed is a priority over security and simplicity,
you are doing this wrong anyways. A good way to mitigate a speed
issue is to get a CPU that does hardware AES.
* 2.3 How do I set up encrypted swap?
As things that are confidential can end up in swap (keys,
passphrases, etc. are usually protected against being swapped to
disk, but other things may not be), it may be advisable to do
something about the issue. One option is to run without swap, which
generally works well in a desktop-context. It may cause problems in
a server-setting or under special circumstances. The solution to
that is to encrypt swap with a random key at boot-time.
NOTE: This is for Debian, and should work for Debian-derived
distributions. For others you may have to write your own startup
script or use other mechanisms.
01) Add the swap partition to /etc/crypttab. A line like the
following should do it:
swap /dev/<partition> /dev/urandom swap,noearly
Warning: While Debian refuses to overwrite partitions with a
filesystem or RAID signature on it, if your disk IDs may change
(adding or removing disks, failure of disk during boot, etc.), you
may want to take additional precautions. Yes, this means that your
kernel device names like sda, sdb, ... can change between reboots!
This is not a concern if you have only one disk. One possibility is
to make sure the partition number is not present on additional disks
or also swap there. Another is to encapsulate the swap partition (by
making it a 1-disk RAID1 or by using LVM), so that it gets a
persistent identifier. Specifying it directly by UUID does not work,
unfortunately, as the UUID is part of the swap signature and that is
not visible from the outside due to the encryption and in addition
changes on each reboot with this setup.
Note: Use /dev/random if you are paranoid or in a potential
low-entropy situation (embedded system, etc.). This may cause the
operation to take a long time during boot. If you are in a "no
entropy" situation, you cannot encrypt swap securely. In this
situation you should find some entropy, also because nothing else
using crypto will be secure, like ssh, ssl or GnuPG.
Note: The "noearly" option makes sure things like LVM, RAID, etc.
are running. As swap is non-critical for boot, it is fine to start
it late.
02) Add the swap partition to /etc/fstab. A line like the following
should do it:
/dev/mapper/swap none swap sw 0 0
That is it. Reboot or start it manually to activate encrypted swap.
Manual start would look like this:
/etc/init.d/crypdisks start
swapon /dev/mapper/swap
* 2.4 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 the
sectors of the device, with a direct 1:1 mapping between encrypted
and decrypted sectors.
Primary advantage is high resilience to damage, as one damaged
encrypted sector results in exactly one damaged decrypted sector.
Also, it is not readily apparent that there even is encrypted data on
the device, as an overwrite with crypto-grade randomness (e.g. from
/dev/urandom) looks exactly the same on disk.
Side-note: That has limited value against the authorities. In
civilized countries, they cannot force you to give up a crypto-key
anyways. In quite a few countries around the world, they can force
you to give up the keys (using imprisonment or worse to pressure you,
sometimes without due process), and in the worst case, they only need
a nebulous "suspicion" about the presence of encrypted data.
Sometimes this applies to everybody, sometimes only when you are
suspected of having "illicit data" (definition subject to change) and
sometimes specifically when crossing a border. Note that this is
going on in countries like the US and the UK, to different degrees
and sometimes with courts restricting what the authorities can
actually demand.
My advice is to either be ready to give up the keys or to not have
encrypted data when traveling to those countries, especially when
crossing the borders. The latter also means not having any
high-entropy (random) data areas on your disk, unless you can explain
them and demonstrate that explanation. Hence doing a zero-wipe of
all free space, including unused space, may be a good idea.
Disadvantages are that you do not have all the nice features that the
LUKS metadata offers, like multiple passphrases that can be changed,
the cipher being stored in the metadata, anti-forensic properties
like key-slot diffusion and salts, etc..
LUKS format uses a metadata header and 8 key-slot areas that are
being placed at the beginning of the disk, see below under "What does
the LUKS on-disk format looks like?". The passphrases are used to
decrypt a single master key that is stored in the anti-forensic
stripes.
Advantages are a higher usability, automatic configuration of
non-default crypto parameters, defenses against low-entropy
passphrases like salting and iterated PBKDF2 passphrase hashing, the
ability to change passphrases, and others.
Disadvantages are that it is readily obvious there is encrypted data
on disk (but see side note above) and that damage to the header or
key-slots usually results in permanent data-loss. See below under
"6. Backup and Data Recovery" on how to reduce that risk. Also the
sector numbers get shifted by the length of the header and key-slots
and there is a loss of that size in capacity (1MB+4096B for defaults
and 2MB for the most commonly used non-default XTS mode).
* 2.5 Can I encrypt an already existing, non-empty partition to use LUKS?
There is no converter, and it is not really needed. The way to do
this is to make a backup of the device in question, securely wipe the
device (as LUKS device initialization does not clear away old data),
do a luksFormat, optionally overwrite the encrypted device, create a
new filesystem and restore your backup on the now encrypted device.
Also refer to sections "Security Aspects" and "Backup and Data
Recovery".
For backup, plain GNU tar works well and backs up anything likely
to be in a filesystem.
* 2.6 How do I use LUKS with a loop-device?
This can be very handy for experiments. Setup is just the same as
with any block device. If you want, for example, to use a 100MiB
file as LUKS container, do something like this:
head -c 100M /dev/zero > luksfile # create empty file
losetup /dev/loop0 luksfile # map luksfile to /dev/loop0
cryptsetup luksFormat /dev/loop0 # create LUKS on loop device
Afterwards just use /dev/loop0 as a you would use a LUKS partition.
To unmap the file when done, use "losetup -d /dev/loop0".
* 2.7 When I add a new key-slot to LUKS, it asks for a passphrase
but then complains about there not being a key-slot with that
passphrase?
That is as intended. You are asked a passphrase of an existing
key-slot first, before you can enter the passphrase for the new
key-slot. Otherwise you could break the encryption by just adding a
new key-slot. This way, you have to know the passphrase of one of
the already configured key-slots in order to be able to configure a
new key-slot.
* 2.8 Encryption on top of RAID or the other way round?
Unless you have special needs, place encryption between RAID and
filesystem, i.e. encryption on top of RAID. You can do it the other
way round, but you have to be aware that you then need to give the
passphrase for each individual disk and RAID autodetection will not
work anymore. Therefore it is better to encrypt the RAID device,
e.g. /dev/dm0 .
This means that the typical layering looks like this:
Filesystem <- top
|
Encryption
|
RAID
|
Raw partitions
|
Raw disks <- bottom
The big advantage is that you can manage the RAID container just like
any RAID container, it does not care that what is in it is encrypted.
* 2.9 How do I read a dm-crypt key from file?
Use the --key-file option, like this:
cryptsetup create --key-file keyfile e1 /dev/loop0
This will read the binary key from file, i.e. no hashing or
transformation will be applied to the keyfile before its bits are
used as key. Extra bits (beyond the length of the key) at the end
are ignored. Note that if you read from STDIN, the data will still
be hashed, just as a key read interactively from the terminal. See
the man-page sections "NOTES ON PASSPHRASE PROCESSING..." for more
detail.
* 2.10 How do I read a LUKS slot key from file?
What you really do here is to read a passphrase from file, just as
you would with manual entry of a passphrase for a key-slot. You can
add a new passphrase to a free key-slot, set the passphrase of an
specific key-slot or put an already configured passphrase into a
file. In the last case make sure no trailing newline (0x0a) is
contained in the key file, or the passphrase will not work because
the whole file is used as input.
To add a new passphrase to a free key slot from file, use something
like this:
cryptsetup luksAddKey /dev/loop0 keyfile
To add a new passphrase to a specific key-slot, use something
like this:
cryptsetup luksAddKey --key-slot 7 /dev/loop0 keyfile
To supply a key from file to any LUKS command, use the --key-file
option, e.g. like this:
cryptsetup luksOpen --key-file keyfile /dev/loop0 e1
* 2.11 How do I read the LUKS master key from file?
The question you should ask yourself first is why you would want to
do this. The only legitimate reason I can think of is if you want to
have two LUKS devices with the same master key. Even then, I think
it would be preferable to just use key-slots with the same
passphrase, or to use plain dm-crypt instead. If you really have a
good reason, please tell me. If I am convinced, I will add how to do
this here.
* 2.12 What are the security requirements for a key read from file?
A file-stored key or passphrase has the same security requirements as
one entered interactively, however you can use random bytes and
thereby use bytes you cannot type on the keyboard. You can use any
file you like as key file, for example a plain text file with a human
readable passphrase. To generate a file with random bytes, use
something like this:
head -c 256 /dev/random > keyfile
* 2.13 If I map a journaled file system using dm-crypt/LUKS, does
it still provide its usual transactional guarantees?
Yes, it does, unless a very old kernel is used. The required flags
come from the filesystem layer and are processed and passed onwards
by dm-crypt. A bit more information on the process by which
transactional guarantees are implemented can be found here:
http://lwn.net/Articles/400541/
Please note that these "guarantees" are weaker than they appear to
be. One problem is that quite a few disks lie to the OS about having
flushed their buffers. Some other things can go wrong as well. The
filesystem developers are aware of these problems and typically can
make it work anyways. That said, dm-crypt/LUKS will not make things
worse.
One specific problem you can run into though is that you can get
short freezes and other slowdowns due to the encryption layer.
Encryption takes time and forced flushes will block for that time.
For example, I did run into frequent small freezes (1-2 sec) when
putting a vmware image on ext3 over dm-crypt. When I went back to
ext2, the problem went away. This seems to have gotten better with
kernel 2.6.36 and the reworking of filesystem flush locking mechanism
(less blocking of CPU activity during flushes). It should improve
further and eventually the problem should go away.
* 2.14 Can I use LUKS or cryptsetup with a more secure (external)
medium for key storage, e.g. TPM or a smartcard?
Yes, see the answers on using a file-supplied key. You do have to
write the glue-logic yourself though. Basically you can have
cryptsetup read the key from STDIN and write it there with your own
tool that in turn gets the key from the more secure key storage.
For TPM support, you may want to have a look at tpm-luks at
https://github.com/shpedoikal/tpm-luks. Note that tpm-luks is not
related to the cryptsetup project.
* 2.15 Can I resize a dm-crypt or LUKS partition?
Yes, you can, as neither dm-crypt nor LUKS stores partition size.
Whether you should is a different question. Personally I recommend
backup, recreation of the encrypted partition with new size,
recreation of the filesystem and restore. This gets around the
tricky business of resizing the filesystem. Resizing a dm-crypt or
LUKS container does not resize the filesystem in it. The backup is
really non-optional here, as a lot can go wrong, resulting in partial
or complete data loss. Using something like gparted to resize an
encrypted partition is slow, but typically works. This will not
change the size of the filesystem hidden under the encryption though.
You also need to be aware of size-based limitations. The one
currently relevant is that aes-xts-plain should not be used for
encrypted container sizes larger than 2TiB. Use aes-xts-plain64 for
that.
* 2.16 How do I Benchmark the Ciphers, Hashes and Modes?
Since version 1.60 cryptsetup supports the "benchmark" command.
Simply run as root:
cryptsetup benchmark
It will output first iterations/second for the key-derivation
function PBKDF2 parameterized with different hash-functions, and then
the raw encryption speed of ciphers with different modes and
key-sizes. You can get more than the default benchmarks, see the
man-page for the relevant parameters. Note that XTS mode takes two
keys, hence the listed key sizes are double that for other modes and
half of it is the cipher key, the other half is the XTS key.
* 2.17 How do I Verify I have an Authentic cryptsetup Source Package?
Current maintainer is Milan Broz and he signs the release packages
with his PGP key. The key he currently uses is the "RSA key ID
D93E98FC", fingerprint 2A29 1824 3FDE 4664 8D06 86F9 D9B0 577B D93E
98FC. While I have every confidence this really is his key and that
he is who he claims to be, don't depend on it if your life is at
stake. For that matter, if your life is at stake, don't depend on me
being who I claim to be either.
That said, as cryptsetup is under good version control, a malicious
change should be noticed sooner or later, but it may take a while.
Also, the attacker model makes compromising the sources in a
non-obvious way pretty hard. Sure, you could put the master-key
somewhere on disk, but that is rather obvious as soon as somebody
looks as there would be data in an empty LUKS container in a place it
should not be. Doing this in a more nefarious way, for example
hiding the master-key in the salts, would need a look at the sources
to be discovered, but I think that somebody would find that sooner or
later as well.
That said, this discussion is really a lot more complicated and
longer as an FAQ can sustain. If in doubt, ask on the mailing list.
* 2.18 Is there a concern with 4k Sectors?
Not from dm-crypt itself. Encryption will be done in 512B blocks, but
if the partition and filesystem are aligned correctly and the
filesystem uses multiples of 4kiB as block size, the dm-crypt layer
will just process 8 x 512B = 4096B at a time with negligible
overhead. LUKS does place data at an offset, which is 2MiB per
default and will not break alignment. See also Item 6.12 of this FAQ
for more details. Note that if your partition or filesystem is
misaligned, dm-crypt can make the effect worse though.
* 2.19 How can I wipe a device with crypto-grade randomness?
The conventional recommendation if you want to not just do a
zero-wipe is to use something like
cat /dev/urandom > <taget-device>
That is very slow and painful at 10-20MB/s on a fast computer.
Using cryptsetup and a plain dm-crypt device with a random key,
it is much faster and gives you the same level of security. The
defaults are quite enough.
For device set-up, do the following:
cryptsetup open --type plain -d /dev/urandom /dev/<block-device> to_be_wiped
This maps the container as plain under /dev/mapper/to_be_wiped with a
random password. For the actual wipe you have several options.
Simple wipe without progress-indicator:
cat /dev/zero > /dev/mapper/to_be_wiped
Progress-indicator by dd_rescue:
dd_rescue -w /dev/zero /dev/mapper/to_be_wiped
Progress-indicator by my "wcs" stream meter (available from
http://www.tansi.org/tools/index.html ):
cat /dev/zero | wcs > /dev/mapper/to_be_wiped
Remove the mapping at the end and you are done.
* 2.20 How to I wipe only the LUKS header?
This is not the emergency wipe procedure. That is in Item 5.4. This procedure
is intended to be used when the data should stay intact, e.g. when you change
your LUKS container to use a detached header and want to remove the old one.
Most safe way is this (backup is still a good idea):
01) Determine header size in 512 Byte sectors with "luksDump":
cryptsetup luksDump <device with LUKS container>
-> ...
Payload offset: <number>
...
02) Take the result number and write number * 512 zeros to the start of the
device, e.g. like this:
dd bs=512 count=<number> if=/dev/zero of=<device>
That is it.
3. Common Problems
* 3.1 My dm-crypt/LUKS mapping does not work! What general steps
are there to investigate the problem?
If you get a specific error message, investigate what it claims
first. If not, you may want to check the following things.
- Check that "/dev", including "/dev/mapper/control" is there. If it
is missing, you may have a problem with the "/dev" tree itself or you
may have broken udev rules.
- Check that you have the device mapper and the crypt target in your
kernel. The output of "dmsetup targets" should list a "crypt"
target. If it is not there or the command fails, add device mapper
and crypt-target to the kernel.
- Check that the hash-functions and ciphers you want to use are in
the kernel. The output of "cat /proc/crypto" needs to list them.
* 3.2 My dm-crypt mapping suddenly stopped when upgrading cryptsetup.
The default cipher, hash or mode may have changed (the mode changed
from 1.0.x to 1.1.x). See under "Issues With Specific Versions of
cryptsetup".
* 3.3 When I call cryptsetup from cron/CGI, I get errors about
unknown features?
If you get errors about unknown parameters or the like that are not
present when cryptsetup is called from the shell, make sure you have
no older version of cryptsetup on your system that then gets called
by cron/CGI. For example some distributions install cryptsetup into
/usr/sbin, while a manual install could go to /usr/local/sbin. As a
debugging aid, call "cryptsetup --version" from cron/CGI or the
non-shell mechanism to be sure the right version gets called.
* 3.4 Unlocking a LUKS device takes very long. Why?
The iteration time for a key-slot (see Section 5 for an explanation
what iteration does) is calculated when setting a passphrase. By
default it is 1 second on the machine where the passphrase is set.
If you set a passphrase on a fast machine and then unlock it on a
slow machine, the unlocking time can be much longer. Also take into
account that up to 8 key-slots have to be tried in order to find the
right one.
If this is problem, you can add another key-slot using the slow
machine with the same passphrase and then remove the old key-slot.
The new key-slot will have an iteration count adjusted to 1 second on
the slow machine. Use luksKeyAdd and then luksKillSlot or
luksRemoveKey.
However, this operation will not change volume key iteration count
(MK iterations in output of "cryptsetup luksDump"). In order to
change that, you will have to backup the data in the LUKS container
(i.e. your encrypted data), luksFormat on the slow machine and
restore the data. Note that in the original LUKS specification this
value was fixed to 10, but it is now derived from the PBKDF2
benchmark as well and set to iterations in 0.125 sec or 1000,
whichever is larger. Also note that MK iterations are not very
security relevant. But as each key-slot already takes 1 second,
spending the additional 0.125 seconds really does not matter.
* 3.5 "blkid" sees a LUKS UUID and an ext2/swap UUID on the same
device. What is wrong?
Some old versions of cryptsetup have a bug where the header does not
get completely wiped during LUKS format and an older ext2/swap
signature remains on the device. This confuses blkid.
Fix: Wipe the unused header areas by doing a backup and restore of
the header with cryptsetup 1.1.x:
cryptsetup luksHeaderBackup --header-backup-file <file> <device>
cryptsetup luksHeaderRestore --header-backup-file <file> <device>
* 3.6 cryptsetup segfaults on Gentoo amd64 hardened ...
There seems to be some interference between the hardening and and the
way cryptsetup benchmarks PBKDF2. The solution to this is currently
not quite clear for an encrypted root filesystem. For other uses,
you can apparently specify USE="dynamic" as compile flag, see
http://bugs.gentoo.org/show_bug.cgi?id=283470
4. Troubleshooting
* 4.1 I get the error "LUKS keyslot x is invalid." What does that mean?
This means that the given keyslot has an offset that points outside
the valid keyslot area. Typically, the reason is a corrupted LUKS
header because something was written to the start of the device the
LUKS container is on. Refer to Section "Backup and Data Recovery"
and ask on the mailing list if you have trouble diagnosing and (if
still possible) repairing this.
* 4.2 I cannot unlock my LUKS container! What could be the problem?
First, make sure you have a correct passphrase. Then make sure you
have the correct key-map and correct keyboard. And then make sure
you have the correct character set and encoding, see also "PASSPHRASE
CHARACTER SET" under Section 1.2.
If you are sure you are entering the passphrase right, there is the
possibility that the respective key-slot has been damaged. There is
no way to recover a damaged key-slot, except from a header backup
(see Section 6). For security reasons, there is also no checksum in
the key-slots that could tell you whether a key-slot has been
damaged. The only checksum present allows recognition of a correct
passphrase, but that only works if the passphrase is correct and the
respective key-slot is intact.
In order to find out whether a key-slot is damaged one has to look
for "non-random looking" data in it. There is a tool that
automatizes this in the cryptsetup distribution from version 1.6.0
onwards. It is located in misc/keyslot_checker/. Instructions how
to use and how to interpret results are in the README file. Note
that this tool requires a libcryptsetup from cryptsetup 1.6.0 or
later (which means libcryptsetup.so.4.5.0 or later). If the tool
complains about missing functions in libcryptsetup, you likely have
an earlier version from your distribution still installed. You can
either point the symbolic link(s) from libcryptsetup.so.4 to the new
version manually, or you can uninstall the distribution version of
cryptsetup and re-install that from cryptsetup >= 1.6.0 again to fix
this.
* 4.3 Can a bad RAM module cause problems?
LUKS and dm-crypt can give the RAM quite a workout, especially when
combined with software RAID. In particular the combination RAID5 +
LUKS + XFS seems to uncover RAM problems that never caused obvious
problems before. Symptoms vary, but often the problem manifest
itself when copying large amounts of data, typically several times
larger than your main memory.
Side note: One thing you should always do on large data