Feature #7361

LUKS volume file and offset

Added by acraky 2014-06-01 19:15:20 . Updated 2014-07-10 07:22:04 .

Status:
Rejected
Priority:
Low
Assignee:
Category:
Target version:
Start date:
2014-06-01
Due date:
% Done:

0%

Feature Branch:
Type of work:
Code
Blueprint:

Starter:
0
Affected tool:
Deliverable for:

Description

Although Tails 1.0 integrate LUKS, some important features which LUKS inhere don’t be included.
1. Can’t create and open LUKS format volume file.
2. One of the most important feature of LUKS is ‘offset’, including data offset and key offset. The ‘offset’ can be applied in LUKS formatted volume file, partition or disk. While we can’t see any ‘offset’ here.
3. For security reasons, an encrypted volume file, partition, entire disk should not has any identification announcing ‘I’m an encrypted volume’, while partition created by LUKS in Tails seems has an identification compare to other LUKS software does.


Subtasks


History

#1 Updated by BitingBird 2014-06-01 19:39:45

  • Priority changed from High to Low

#2 Updated by intrigeri 2014-06-02 03:02:41

May you please check if these features you’re missing are present in the version of cryptsetup shipped in Tails 1.1~beta1?
If not, please tell us what minimal version of cryptsetup is needed to do all this.

> 3. For security reasons, an encrypted volume file, partition, entire disk should not
> has any identification announcing ‘I’m an encrypted volume’, while partition created
> by LUKS in Tails seems has an identification compare to other LUKS software does.

Either you’re confused, or I am. I’ve no idea what you mean with “other LUKS software”.
See https://en.wikipedia.org/wiki/LUKS and https://code.google.com/p/cryptsetup/.

#3 Updated by intrigeri 2014-06-20 13:11:08

  • Status changed from New to Rejected

It’s unclear what we’re being asked here, and the little I think I understand either is hard to implement due to how we designed persistence, or will be addressed by Feature #5929.

#4 Updated by acraky1 2014-07-09 14:40:07

Sorry for I had not expressed the problem clearly enough.
Please creat a LUKS format disk, insert another U-disk(etc.) to your computer. In 1.1~beta1: AccessoriesDisk Utility>click you U-disk on the leftFormat drive,Format,Format>Creat Partitionchoose FAT (etc.)>Encrypt underlying deviceCreat>input password->Creat. Now a LUKS format partition is created.

This partition can be open in Windows by FreeOTFE: FileLinux volume>Mount partitionDon’t click Entire disk, just click the partition on the picture,Ok>input your password, now you can decrypt the LUKS volume created in Tails.

I backup the CBD (critical data block) of LUKS patitions created by tails-i386-1.0.1 and tails-i386-1.1~beta1, this operation don’t need password. Both CBD indicate the security information of the partition in plain text without encryption.

LUKS aes cbc-essiv:sha256 sha1… following encrypted user password and encrypted master key(never change)

It’s obviously a big security hole, so TrueCrypt encrypt its CBD, and FreeOTFE not only encrypt its CBD but also hide CBD by setting OFFSET value which user had setup when creating the partition.

Cryptsetup don’t hide its basic information. If you choose cryptsetup, I hope you could provide more options when creating a secure partition or volume, algorithm AES-CBC-ESSIV is not secure enough, AES-XTS would be better. Cryptsetup has options like: —hash, —cipher, —verify-passphrase, —key-file, —key-size, —offset, —skip, —readonly.
Hidden partition created by offset and without any tag is trend of security. To gain maximum security, a FreeOTFE like software is preferd.

cryptsetup Style Dump of encrypted partition created in tails-i386-1.1~beta1
——————————-
LUKS header information for \Device\Harddisk3\Partition1

Version: 1
Cipher name: aes
Cipher mode: cbc-essiv:sha256
Hash spec: sha1
Payload offset: 4096
MK bits: 256
MK digest: bf 54 8e 3e cb a2 6d 73 80 58 6c fb 6a 5b 82 5a 8e 8d db bc
MK salt: 74 1c a2 a6 14 da d9 e1 36 93 30 24 83 ec dc 68
b7 f5 79 01 90 31 73 15 d8 c3 47 c6 81 11 1b 81
MK iterations: 25500
UUID: 6e494f9d-dbeb-4ba1-baf0-ef6e158793e4

Key Slot 0: ENABLED
Iterations: 102056
Salt: 75 71 8f c1 27 99 86 7e 14 9b 3f d7 95 ec ca be
7a ee 17 0a f3 7a 44 23 4b 29 0c 34 39 fc 6b c3
Key material offset: 8
AF stripes: 4000
Key Slot 1: DISABLED
Key Slot 2: DISABLED
Key Slot 3: DISABLED
Key Slot 4: DISABLED
Key Slot 5: DISABLED
Key Slot 6: DISABLED
Key Slot 7: DISABLED

Master Key
—————
User supplied password : test
Password unlocks key slot: 0
Recovered master key :
00000000 | 67 BE FE 89 43 98 37 DF | g…C.7.
00000008 | 3A E8 91 DF 1E 7C AB 89 | :….|..
00000010 | 0F 2A 9F CC 59 3C 30 98 | .*..Y<0.
00000018 | 57 37 5E 02 84 E3 0A E2 | W7^…..

cryptsetup Style Dump of encrypted partition created in tails-i386-1.0.1
——————————-
LUKS header information for \Device\Harddisk3\Partition1

Version: 1
Cipher name: aes
Cipher mode: cbc-essiv:sha256
Hash spec: sha1
Payload offset: 2056
MK bits: 256
MK digest: 1d 5f 54 cd ce 46 59 8e 1c 56 3b 1e 6b cd f6 42 2e df e4 db
MK salt: b8 b8 d9 06 57 d9 7d 92 fc 82 e0 b7 d6 25 81 46
fa ce 4b 70 62 d8 0f 3d 3a 3e 4b ec f8 6e fc 27
MK iterations: 20500
UUID: 99a86cfc-401d-451f-98a5-922140b4ebb9

Key Slot 0: ENABLED
Iterations: 82414
Salt: 39 ed c7 4e 86 65 e5 a7 cd 18 e6 01 37 4a 6e c8
fb 4c 62 94 fb c3 e9 f3 32 13 2c 3a e1 de 3d 70
Key material offset: 8
AF stripes: 4000
Key Slot 1: DISABLED
Key Slot 2: DISABLED
Key Slot 3: DISABLED
Key Slot 4: DISABLED
Key Slot 5: DISABLED
Key Slot 6: DISABLED
Key Slot 7: DISABLED

Master Key
—————
User supplied password : test2
Password unlocks key slot: 0
Recovered master key :
00000000 | D8 BF 1B 82 75 DD D4 BF | ….u…
00000008 | 01 78 78 E5 12 DB 87 91 | .xx…..
00000010 | 64 4A 25 34 B1 4E FE 9B | dJ%4.N..
00000018 | 22 B5 08 9A A1 D1 33 12 | "…..3.

#5 Updated by intrigeri 2014-07-10 07:22:04

  • Regarding “AES-CBC-ESSIV is not secure enough, AES-XTS”: is the latest cryptsetup upstream release still default’ing to CBC-ESSIV? If yes, then please take the discussion there first. Else, if they have switched to something presumably stronger in newer cryptsetup, indeed we should consider switching too, without waiting for e.g. Debian Jessie.
  • Regarding plausible deniability: Feature #5929