How to implement a LUKS NUKE option for a specific password?

systemd · 2021-12-11 00:51:52

Hi all,

I am using Arch, BTRFS with LUKE encryption. My boot-loader is not LUKS encrypted. Upon boot, the kernal asks for the LUKS password to be entered so the booting process can continue. BTRFS has treated me with features from the future and LUKS guarantees that my data is safe.

However, there is an aspect of security that is a bit overlooked here which is addressed in Veracrypt. Law enforcement can prove the existence of a LUKS encrypted storage. if done so, things can get messy. Meaning, follow up questions can arise stemming from the fast 1. Why was there a LUKS encrypted device? 2. Why can't the password for that be remembered? etc. This situation can be very dynamic and turn to be bad. Veracrypt offers support for this "real life situation" by enabling two passwords where each chooses an operating system to boot. Whenever the " I don't care if you see inside this operating system" is booted, the data in the "hidden" operating system "looks" random thereby giving the ability to the defendant to prove the "non-existance" of data. This is a huge edge for the defendant. This is not possible with LUKS. Porting this feature to LUKS is also troublesome. Maintaining is also troublesome. So, one alternative is to type a password that invokes the same kernel but deletes the headers in the LUKS container responsible for decrypting. This renders the LUKS storage close to useless. Giving an edge to the defendant.

People on the internet has proposed alternate use cases such as Tails OS etc. Using Tails OS as a daily driver is not easy. We need something easy and saves time but is ready at an urgent time.

What is the best way to attach LUKS NUKE option to an existing Arch Linux Install?

Thank you for answering my concern and providing me pointers.

mpan · 2021-12-11 16:27:35

No sane law enforcement agency runs your own software to decrypt drives. Stock or dedicated software is used. Erasing data like that will also be considered destroying evidence, which in many jurisdictions puts you in more trouble than the original charges.

Veracrypt promises to offer plausible deniability with a decoy, which is a different concept. It’s also a solution that must be complemented by relevant laws and those laws being respected. Currently the idea is at best providing hypothetical protection in optimistic cases, with most places on Earth not even fulfilling requirements for it to work.

Instead of chasing a rabbit of non-existent perfect security/privacy, find a reasonable solution that addresses actual concerns of the threat model you have specified (thought you haven’t shared it with us).

ewaller · 2021-12-11 17:16:19

If this thread continues in the context of thwarding legal search and seizure, it will be shut down.at the least, keep the advarsary generic.

Id be more concerned about advarsaries on the other side of the law. And the means they could use to extract the password from you. And yes, anyone trying to recover data will be working from a mirrored copy

Last edited by ewaller (2021-12-11 17:48:53)

Xyne · 2021-12-11 22:59:31

As stated above, any situation in which you are being held against your will and interrogated for a password is also a situation in which you no longer have any access to the hardware. Providing a NUKE password would not destroy the data but the attempt would almost certainly incur further consequences, as already mentioned above. The specific consequences vary wildly from one hypothetical to another but in all imaginable scenarios you simply have to weigh the consequences of revealing the password against those of withholding it and then hope that you bet on the right horse.

The only plausible situation in which a NUKE password would have any real value is one in which you can access the disk before an adversary apprehends you. But even then evidence of the filesystem's existence will likely remain and thereby inculpate your premeditated destruction of it. You would probably need several hours to securely wipe the disk and re-install a plausible decoy over it. You could set that up as a panic button but you would have to be completely sure about the timing for it to work.

Plausible deniability is a function of your adversary's sophistication. For any serious adversary who already has a reason to suspect you, it basically doesn't exist. You're never going to beat forensic experts who are using state-of-the-art recovery tools with years of experience and you should't be in a situation in which you even need to worry about them. And if your adversary doesn't have forensic experts, they probably have something even more threatening to your immediate well-being which can quickly shift the balance of the conceal-or-reveal conundrum.

If you want peace of mind for these kinds of hypotheticals, get a friend who has unfettered access to a 24/7 working blast furnace.

tsrnc2 · 2021-12-11 23:33:42

* Sorry better for me to stay silent on this one

Last edited by tsrnc2 (2021-12-11 23:37:54)

systemd · 2021-12-12 02:12:37

Thank you for your comments and views. Apolagise for aiming the question wrongly. I am merely curious and I want to learn. The scenario I explained is equally applicable for non government organizations as well. Let's not further discuss anything to do with goverment regulations as it may be against the regulations of this forum. The problem I specified can easilly be extended for many scenarios. There can be many malicious actors in the world interested in decrypting and detecting the presence of "encrypted data". E.g. there can be a terrorist organization who will kidnap a journalist. Typically, such organizations tend to have equal (or higher) capabilities and access to tools similar to powerful organizations in the world.

I've learnt several key points from your responses.

- NUKS passwords are not much useful in practice as a party that steals your equipment by force will make a clone and work on a clone. The only way to combat this is to take your device with you, keep your device with you at all times. Be able to NUKE it at ease. And such freedom is never available and is not practical.
- Veracrypt offers possible "deniability" by offering a hidden container.

I am interested in cases this model can fail. Imagine there is a disk encrypted with Veracrypt that has two passwords. Veracrypt ensures data in the hidden container is random data. Furthermore, no one can prove the presence of a hidden compartment. This method is mathematically sound as well. In this case, what are vulnerabilities of using a Veracrypt disk with a hidden partition?

Xyne · 2021-12-12 03:31:47

systemd wrote:

I am interested in cases this model can fail. Imagine there is a disk encrypted with Veracrypt that has two passwords. Veracrypt ensures data in the hidden container is random data. Furthermore, no one can prove the presence of a hidden compartment. This method is mathematically sound as well. In this case, what are vulnerabilities of using a Veracrypt disk with a hidden partition?

If the adversary does not believe that you have a hidden container or can't act without proving it, you're safe whether or not you have one.

If the adversary believes that you have a hidden container and can act without proof, you're in trouble. There's no way to prove that you don't have a hidden container so if you really don't have one, you may be subjected to extreme coercive measures with no recourse.

Arch Linux

#1 2021-12-11 00:51:52

How to implement a LUKS NUKE option for a specific password?

#2 2021-12-11 16:27:35

Re: How to implement a LUKS NUKE option for a specific password?

#3 2021-12-11 17:16:19

Re: How to implement a LUKS NUKE option for a specific password?

#4 2021-12-11 22:59:31

Re: How to implement a LUKS NUKE option for a specific password?

#5 2021-12-11 23:33:42

Re: How to implement a LUKS NUKE option for a specific password?

#6 2021-12-12 02:12:37

Re: How to implement a LUKS NUKE option for a specific password?

#7 2021-12-12 03:31:47

Re: How to implement a LUKS NUKE option for a specific password?

Board footer