Kudelski Security, a company specializing in security audits, has released the Shufflecake toolkit, which allows for the creation of hidden file systems that are spread across available free space in existing partitions and indistinguishable from random residual data. The partitions are created in such a way that, without the access key, proving their existence is problematic, even during forensic analysis. The code for the utilities (shufflecake-userland) and the Linux kernel module (dm-sflc) is written in C and released under the GPLv3 license, which makes it impossible to include the published kernel module in the main kernel due to incompatibility with the GPLv2 license under which the kernel is distributed. <\/p>\n
The project is positioned as a more advanced solution than Truecrypt and Veracrypt for hiding sensitive data, which has native support for the Linux platform and allows for the placement of up to 15 hidden partitions on a device, nested within each other to obscure their existence. While the application of Shufflecake itself is not a secret, as can be judged by the presence of the corresponding utilities in the system, the overall number of created hidden partitions cannot be determined. The hidden partitions can be formatted at the user's discretion to accommodate any file systems, such as ext4, xfs, or btrfs. Each partition is treated as a separate virtual block device with its own unlock key. <\/p>\n
To obscure traces, it is recommended to use the behavior model of 'plausible deniability,' which means that valuable data is hidden as additional layers within encrypted sections containing less valuable data, forming a kind of hidden hierarchy of sections. In case of pressure, the device owner can reveal the key to the encrypted section, but this section may conceal other sections (up to 15 nested levels), and determining their presence and proving existence is problematic. <\/p>\n
Hiding is achieved by forming each section as a set of encrypted slices that are placed in random positions on the storage device. Each slice is created dynamically when additional storage space is required within the section. To complicate analysis, slices from different sections are interspersed, i.e., Shufflecake sections are not linked to contiguous areas and slices from all sections are mixed together. Information about the used and free slices is stored in a location map associated with each section, which is referenced by the encrypted header. Both the maps and the header are encrypted and are indistinguishable from random data without knowledge of the access key. <\/p>\n
The header is divided into slots, each defining its section and associated slices. The slots in the header are stacked and recursively linked \u2014 the current slot contains the key to decrypt the parameters of the previous section in the hierarchy (less hidden), which allows using one password to decrypt all less hidden sections related to the selected section. Each less hidden section considers the slices of nested sections as free. <\/p>\n
By default, all nested Shufflecake sections have the same visible size as the top-level section. For example, if three sections are used on a device with a size of 1 GB, each will be visible to the system as a section with a size of 1 GB, and the total available disk space will be shared among all sections \u2014 if the total size of saved data exceeds the actual device size, an input\/output error will start to occur. <\/p>\n
Unopened nested sections do not participate in space distribution, meaning that attempting to fill a top-level section will overwrite data in nested sections without revealing their presence through data size analysis that could fit in the section before an error is triggered (it is assumed that top-level sections contain immutable data to distract attention and are never used individually, while regular operations always occur with the most recently nested section; the scheme implies that it is more important to maintain the secrecy of data existence than to lose that data). <\/p>\n
In fact, 15 Shufflecake sections are always created \u2014 the used sections are tied to the user password, while unused sections are assigned a randomly generated password (it is impossible to know how many sections are really in use). When initializing Shufflecake sections, the disk, partition, or virtual block device allocated for their placement is filled with random data, which does not allow determining the metadata and Shufflecake data against the overall background. <\/p>\n
The implementation of Shufflecake offers quite high performance, but due to overhead, it has approximately half the throughput compared to disk encryption based on the LUKS subsystem. The use of Shufflecake also results in additional memory and storage space requirements for metadata on the disk. Memory costs are estimated at 60 MB per partition, while disk space usage is about 1% of the total size. In comparison, a similar technique, WORAM, leads to slowdowns ranging from 5 to 200 times with a 75% loss of usable disk space. <\/p>\n