Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.

Bug 454855

Summary: Full disk encryption: allow for hidden system, accessed by different password
Product: [Fedora] Fedora Reporter: Peter Keenig <freeform.reform>
Component: cryptsetupAssignee: Milan Broz <gmazyland>
Status: CLOSED WONTFIX QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: low Docs Contact:
Priority: low    
Version: rawhideCC: agk, dwysocha, gmazyland, okozina, opensource, pjones, prockai
Target Milestone: ---Keywords: FutureFeature
Target Release: ---   
Hardware: All   
OS: Linux   
Fixed In Version: Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2018-04-04 07:13:40 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Bug Depends On:    
Bug Blocks: 809563    

Description Peter Keenig 2008-07-10 08:31:41 UTC
Description of problem:
Truecrypt 6.0 allows to setup a second (hidden) OS inside an already protected
OS (currently Windows only).

Fedora 9 has introduced a very well working full disk encryption. 

It would be great to take it one step further: 
Allow to create a second /home(2) partition, that is hidden from the first
/home(1) partition. Depending on what password is entered upon boot, either
/home(1) or /home(2) is unlocked and can be accessed.

Comment 1 Milan Broz 2008-07-14 11:01:23 UTC
- hidden volumes are supported by truecrypt on Linux now
- the whole truecrypt engine uses dm-crypt module in version 6
(except protection of hidden volume)

- LUKS has a visible header marker, useful for identicication by blkid,
but cannot be used for implementing hidden volume

Anyway, hidden volume (without volume overwriting protection) can be created
using simple script - something like this:

 - create standard LUKS device with some "fake files", use some fs which
occupies only beggining of the disk (IIRC truecrypt uses FAT by default)
Be sure that you initialized whole device using random data before formatting.

 - manually create dm-crypt mapping (without LUKS header, cryptsetup still
suports this mode) to part of device, where are unused blocks (usually end of
device, use --offset parameter in cryptsetup)

The script then should try to decrypt hidden volume with known offset and checks
against some known pattern there.
(But just existence of this script shows an anomaly that you are are hiding
someting :-) 

Nobody without password (and properly used cipher) cannot distinguish if the
blocks are part of hidden volume or just unused blocks in "outer" volume.

(Of course if you write something to outer volume, you can destroy data in
hidden volume in this trivial mapping mode; device-mapper easily allows mapping
that will protect hidden part - by mapping that part to to error target, but
again, it shows to potential attacker that you are hiding something there...)

Anyway, it is interesting idea to automatize it somehow, but probably low
priority now.

Comment 2 Milan Broz 2018-04-04 07:13:40 UTC
LUKS will not provide any hidden partitions directly.

With modern SSD it is not even possible, TRIM will discard any data that are "unused" from the outer volume.

Closing as WONTFIX, it does make sense to keep this open while there are no plans to introduce plausible deniability in cryptsetup/LUKS.