Hello @unman and company,
I recognize that this is a very, very long reply. I apologize for the length, but feel it is necessary to adequately address all the points raised so far. It probably is not, which is my fault alone. I have split the following into two sections, the first of which clarifies some my attitudes and motivations toward the purpose of this topic and the project it proposes, and the second of which directly addresses how far I have gotten (not very far) and why I want this implementable during a Qubes installation (strongly preferred, but reluctantly optional). If all you care about is the latter, skip the first section and begin after the second section break.
I am aware that the Qubes installer is based on Fedora, but was unable to find anything that can help me from Fedora forums and communities. My best luck has been with the Arch Wiki, whose article and subarticles on dm-crypt have provided me the most insight. Unfortunately, there is not even any mention of cascading encryption, much less documentation or guides, which is why I am here. The closest I have found to that is a brief suggestion of how to do so in Zulucrypt for LUKS containers, which is found on the Whonix Wiki’s “Full Disk Encryption” article. To the best of my knowledge, guides or tutorials for implementing cascading encryption in LUKS using cryptsetup simply do not exist. If we are able to accomplish doing so, perhaps one will.
I believe that detached /boot and LUKS headers provide plausible deniability for the primary drive because the entire drive will be encrypted without any evidence or indication that it is. For anyone inspecting the drive without foreknowledge, it will simply appear to be filled with random data, which can be explained away as having just been wiped in preparation for installing an operating system. This requires no knowledge of the separate drive containing the /boot and LUKS headers. I understand this to be a typical method of implementing plausibly deniable full-disk encryption. Regardless, its deniability is not the primary purpose of this project, just a potential effect of it. The main goal, as I stated above, is to accomplish an implementation that does not trust a given algorithm set (such as AES+SHA) as a single point of failure, that provides a method of distrusting AES+SHA while benefiting from its status as a standard (“gray man” encryption), and that can increase the cost of successful cryptanalysis. This practically assists in preventing the unauthorized decryption of the data in the event that it is exfiltrated without the necessary keys or boot drive, such as in the event of theft, or confiscation, or imaging, or even the death of the owner.
I did not state that drive encryption is the “weakest link” and I recognize that the user is often that; you misunderstand me. What I proposed was a scenario in which we assume that it is for a particular security model, which was in response to being reminded that weaker links than drive encryption exist.
Frankly, however, I do not think I need to justify why I am attempting to accomplish this encryption scheme. That is ultimately not relevant to whether such an implementation is possible and successful. As a matter of courtesy, I am entertaining tangential discussions about the security implications of this setup and the threat models to which it responds in order to illustrate the practical relevance of cascading full-disk encryption in certain security scenarios. I have already extensively explored such considerations in my own time and with others, as well, so I can explain its practical relevance to security and identify entire problems and scenarios it helps one solve. None of that aids in accomplishing a proof-of-concept implementation, though, and does not actually get me any closer to figuring out how to do so.
The reality is that VeraCrypt already provides cascading encryption as a matter of due course, at least on Windows, and it can be enabled by simply selecting it as a feature during setup, all without any prerequisite knowledge of how it works beneath the hood or much work beyond that. This allows anyone, even someone with absolutely zero technical expertise, to benefit from extremely strong encryption with minimal change in how they use their devices.
dm-crypt has never had anything remotely comparable to that, which is a crying shame. It is long overdue for a successful, documented proof-of-concept implementation of cascading encryption with LUKS. While this may prove to be very difficult and confusing to figure out (it has for me), actually implementing it should be a breeze once a complete guide on how to do so is available. At that point, the whole process can even be automated and integrated into the installation process as a feature that automagically implements it for you, with as little required expertise as is demanded by VeraCrypt on Windows, to the benefit of all. Automating and integrating it can be a project for someone far more brilliant than me, though, such as @tripleh or even the Qubes/Whonix/dm-crypt+LUKS developers.
In my opinion, it is unacceptable that the most popular and common implementation of drive encryption on Linux systems (dm-crypt+LUKS) does not have feature parity with VeraCrypt on Windows. Part of what made TrueCrypt (and its spiritual successor, VeraCrypt) a game changer in my eyes is that it offered cascading encryption at the touch of a button, something that had never been done before in any publicly available, easy-to-use security tool. In doing so, it brought cascading encryption to the masses and set a new standard for state-of-the-art encryption. In light of this, the continued lack of support for cascading encryption in dm-crypt+LUKS—if only in documentation and implementation, and not possible configuration—derives from the security model a previous era, when cascading encryption was not available for anyone with a compatible device to use.
You may disagree with this opinion. I entirely understand why one might; many, including many professional security researchers, probably consider cascading encryption to be “excessive” or only providing diminishing returns. But that is not the point, and discussing the pros and cons of that perspective brings us no closer to it becoming a reality, which is my goal and the reason why I created this topic.
Hopefully now, you and anyone else reading this understand some of the motivations for why I am on this seemingly quixotic journey toward cascading encryption with dm-crypt+LUKS. If you or anyone else here can help me continue it, then I will be forever grateful and will do my best to pay it forward by producing documentation and guidance for how it can be implemented. If not, for whatever reason, then that is unfortunate but understandable and I appreciate the consideration nonetheless.
Now, with that out of the way, let me address your concluding remarks.
Regarding what I have tried, my answer is not much at all because—as I indicated in the original topic post—I do not even know where to begin or how to approach this. I do understand, generally, what tools will be necessary to accomplish the task and how the commands are likely to be crafted; but beyond that, I am stumped. Maybe I am overthinking it. I already understand how to accomplish full-disk encryption with dm-crypt+LUKS and detached encrypted /boot and LUKS headers, since all of that is documented in the Arch Wiki in a sufficiently clear format that it can be adapted and followed during the installation of nearly any Linux operating system.
The hard part is figuring out how to implement cascading encryption along with this and where to fit that part in the order of operations, especially since this appears to be uncharted territory without any corresponding guide or tutorial to consult. Thus far, I have surmised that I will need to manually set up multiple LUKS volumes nested inside each other and probably manually mount them as loop devices using losetup (unless cryptsetup can handle it for me, like it can in non-cascading setups); but I lack the expertise to understand how exactly that will look as a series of commands, and in particular what options may need to be included in them (such as --offset and --align-payload in cryptsetup). I will also need to generate a custom initramfs and perhaps more beyond that to implement the full-disk encryption part, but that is ultimately extraneous to the main goal of cascading encryption.
Once mapped out and defined, the whole process should be pretty straightforward (and appears to be from a high-level overview), but at the moment it is hopelessly confusing to me. In response, I am pouring over any information I can find to familiarize myself with the fundamentals and intricacies of these tools, such as the man pages of cryptsetup, losetup, and lvm; the aforementioned Arch Wiki documentation; conference presentations and tutorials on how to use these tools; guides on how to automate decryption of multiple LUKS volumes and set up LUKS-encrypted DVD/BD disks using loop devices; and even complaints about LUKS in the comments section of a Schneier blog article on TrueCrypt’s audit! And yet, I am still here, seeking guidance.
I want to implement all this during the Qubes installation process because:
- It should be possible to implement using only the tools provided by the ISO.
- It should not require any prior setup through a different device, which introduces unnecessary complexity and risk, especially if the threat scenario involves access to only one trusted device, an empty SSD and USB, and a DVD+R burned with a known safe copy of the Qubes ISO.
- It should not involve any custom tools from outside the Qubes ISO, whose trustworthiness and efficacy are unknown or in doubt (in contrast with reliable tools such as
cryptsetup, losetup, and lvm), whose compatibility and interoperability with Qubes OS are unknown, and whose involvement may block any chance of it being included as an automated feature in future installation processes (including in Qubes OS).
- It should be relatively easy and straightforward to implement by simply following the instructions on a guide (such as one I intend to create out this project), much like a standard Arch installation.
- It should be a setup anyone installing Qubes OS can implement if they want as an advanced example of a custom installation, whose documentation page can house the guide on how to do so.
Although I appreciate how limiting it may seem to do this entirely from a tty during the Qubes installation process, I believe that working within that constraint will ultimately simplify the process and ensure the greatest compatibility with existing Qubes installation procedures. If a custom tool is ever designed to automate this process, it can be included in future Qubes ISOs and integrated as an advanced feature, but the chances of that happening probably depends on an initial manual implementation of it as proof that it can be done.
If we remove this constraint, however, does that appreciably ease the difficulty of accomplishing this? At this point, I will even work toward a proof-of-concept implementation that requires additional tools and setup prior to initiating the Qubes installation process. Whatever it takes to securely implement cascading encryption using dm-crypt+LUKS is fine by me because at least that it a start.
I am under no illusion that I am requesting a lot here (and typing a lot, too), and that my goal is very ambitious (to put it nicely). But I would not be here unless I thought this community could lend me the expertise I am sorely lacking and needing to accomplish this. I just hope I am right, and that there is enough patience to go with it, because otherwise I may just have to shelve this project entirely as a incomplete failure. I can always try the PrivacyTools forum, as well, but if the wizards here lack the magic (or maybe just the will), then I worry those wizards will too.
If there is any further information I can provide, please do not hesitate to ask.
Weary regards,
John
