There are mentions in this thread about false positives, risk of data loss, others. This made me think of Star Trek's use of a self destruct phrase. Obviously their method is too slow, but you could have a "duress" phrase and a "all clear" phrase.
User-Defined Phrase: "Please dont kill me", activates "duress" mode.
- A daemon listens in the background for a phrase of your choice. When detected, your laptop makes a sound effect that is not out of the ordinary for others to hear, but not something you would expect it to play when self destruct is activated. Git repos are committed/pushed with a duress demarcation code to an alternate branch. Your encrypted volumes are dismounted, buffers and caches cleared, camera and microphone start sending small chunks of audio/video to a destination of your choosing. Instructions for playback from your cloud of choice are emailed to emergency contacts. If you do not give the "all clear" in a user-configurable time period, the laptop does user-defined things like wiping encrypted volumes after giving an optional warning sound, optionally sending eeprom codes to brick the BIOS or replace the BIOS with a tracker and setting the screen to say "Stolen From User-Defined String, User-Defined Phone Number" after giving an optional warning sound. All of these actions could be optionally spaced apart based on risk, probably defined in a key-pair text file or json file.
- Giving the all clear code disables this behavior and your ship does not self destruct. The system plays a sound to acknowledge "all clear". Emergency contacts are emailed the all-clear, but audio/video continue to upload for user-defined time in the event your were forced to give the phrase.
Perhaps newer cars could also have this feature? Are there any existing open source projects that could be adapted/bent to accomplish these things?
BusKill does not ship with destructive triggers. The current app is limited to locking your screen. Future releases will include soft/hard shutdown.
We do have a "LUKS Header Shredder" trigger (which we call self-destruct as it renders all the data on the FDE disk useless), but we (intentionally) don't include it by default and raise the barrier of entry because of the risk of data loss.
We'll be publishing a more detailed write-up on the LUKS Header Shredder in 2 weeks. You can subscribe for updates on our website (buskill.in) or the campaign directly (crowdsupply.com)
Does it support destroying keys in hardware tokens? Would be nice if plugging my yubikey into a specific USB port automatically destroyed all keys inside it.
You really want such devices - i.e. Devices with duress modes - to act normally, as much as possible when in those modes. If they clearly destroy themselves immediately you often place yourself in much greater danger. If anything log them into a sandbox or honeypot that is, as much as possible, indistinguishable from your normal environment but is less damaging for you for them to access.
I always thought that a lock screen with two passwords would be an interesting idea. Say the BusKill locks your system and sends a request to a server. If you don't enter the correct password to abort the script within a few seconds, it will run on your server, which sends a distress mail/call to emergency contacts, revoke all ssh keys/passwords etc.
If however the distress password gets entered, the script still runs, but the system unlocks into a virtual pc or another account which is not suspicious.
Truecrypt had this exact function - one password would decrypt your drive sort of on one end, and start the OS there, another password would decrypt the drive on the other end, and start the OS installed there - so you always had perfectly plausible deniability, since the drive taken as a whole looked like a completely normal encrypted drive(in fact you could accidentally destroy the hidden partition by overwriting "empty" area while booted into the non-secret OS). Always thought that was super cool.
The paranoid dystopian counterpart is that you cannot prove you don't have a second partition either. Might get awkward if someone decided to compel the second password on less solid evidence. If you're not actually using the feature.
There was a case here in Germany where the police report revealed that they apparently spent a lot of time looking for evidence of a hidden partition/encrypted data etc because a PC owned by single man with zero evidence of porn was unusual. (but didn't find anything in the end, and didn't claim anything they didn't have evidence for)
this is why you should actually have "signs of life" and something _slightly_ illegal on your plausible deniability partition. Just enough dirt to get you into trouble, but not too much trouble. If you're squeeky clean, you get the rubber hose cryptography treatment.
If you want those signs of life to be convincing, it should include all kinds of history without long gaps, such as:
- email, including recently received and sent emails
- web browser history
- system logs
- software updates
In practice, I think it’s impossible to do that. If the police discovers, for example, that your system logs show your machine was off for a week, but they also just saw you reset it, what do you tell them?
Yeah, there was a tutorial online. Thought it was a good idea in case my laptop got stolen. Don't need to be an expert to click through an automated wizard, do I?
this is a real problem, yes; i find encrypted volume in swap partition actually provides better plausible deniability. "I was told it should be 2x the size of RAM," - says a guy with 512G of ram and swapoff.
The only problem is this is sort of obvious from a forensics perspective. Person is using truecrypt, they boot it up for you, and the partition is only half the size it should be.
No, like the other reply pointed out too - it's not obvious. The first password unlocks the entire partition, the hidden one is just within the "empty" area of the drive. If you write a sufficiently large file while running the OS you could just overwrite and destroy the hidden partition without knowing that you did so. It's also impossible to tell that the hidden parition is there because encrypted data is indistinguishable from encrypted empty area of the drive.
The question always was what kind of attack are you trying to guard yourself against. I imagine top level agencies have a way to crack truecrypt/veracrypt encrypted volumes, but I also imagine they aren't using that capability against just anyone to not show their hand and risk the issue being fixed.
Your parent seems to point out that's not how it works: you've got access to the ful partition either way, meaning you can accidentally overwrite the other partition.
If I remember right, the hidden partitions are indistinguishable from random data on your disk and it was necessary to provide an offset to the first block (or whatever) so it could be decrypted. You could easily overwrite it accidentally because it just looks like free space.
Disclaimer: I know next to nothing about OS'es and login and so on.
I had an idea once, would it be possible to set up two sets of passwords? One to properly unlock your device, and one to trigger either encryption or scrambling of the data when entered?
Of course, but this won’t be easy with commodity hardware. Standard practice is to use write-blockers to prevent this kind of tricks, but of course you can prevent write-blockers by integrating your storage.
I think you could get a pixel phone to do this in a useful way.
Yep. Pretty much all nerd solutions to physical or legal threats are genius but also worse than useless. Here's a $5 hammer, hit him with it until he gives us what we're looking for, so goes the comic I saw once.
This is effective against legal threats. I remember at least one case in my country where one person was saved by truecrypt. They even asked the FBI for help on decrypting it.
Hopefully civilization is not so far gone that police will imprison, torture or kill for failing to incriminate themselves. If it gets to the point cold-blooded torture is on the table, you'll probably get killed anyway.
That's also why Assange (and others) developed the Rubberhose file system[0].
It's based on the game theoretic idea that if your adversary has no way of knowing how many hidden partitions you have, then you have no way of proving to them that you've given them all your secrets.
As such, there is no benefit to you revealing any secrets under torture, because the torture would continue even after you've told them everything, therefore there is no point to them torturing you in the first place.
If they don't understand game theory, that just means they will act sub-optimally. In any case, the correct strategy for the user is still to not decrypt any partitions, since, as you say, the sooner the user stops decrypting, the sooner the torturers give up.
That seems like a pretty foolish assumption to make of your adversaries/captors.
If a torturer has good reason to believe you have valuable information regarding subject X, they'll simply torture you until they possess that information or you die. If you don't possess the information, you're screwed. If you do possess the information, it's likely that they'll stop after they get what they're after.
A state liable to torture you may simply kill you instead. Or torture you and kill you, even if it serves no particular purpose.
If you're in the business of protecting your secrets against torture then you need to also be protecting them against death because that is grimly inevitable.
That's not really making the case for clever crypto solutions. Assange is rotting in prison and is probably going to die in the US in the near future. What secret information could he be protecting at this point?
I think at that point your laptop is the least of your concerns. I don't let people get that close.
As a side note, Emerson Knives makes a really nice highly durable set of pocket knives with a "wave" that forces the knife open when you extract it from your pocket. It's many times faster than a switch-blade but legal in most states and durable enough blade and handle to pry anything apart. Check with the laws in your state.
User-Defined Phrase: "Please dont kill me", activates "duress" mode.
- A daemon listens in the background for a phrase of your choice. When detected, your laptop makes a sound effect that is not out of the ordinary for others to hear, but not something you would expect it to play when self destruct is activated. Git repos are committed/pushed with a duress demarcation code to an alternate branch. Your encrypted volumes are dismounted, buffers and caches cleared, camera and microphone start sending small chunks of audio/video to a destination of your choosing. Instructions for playback from your cloud of choice are emailed to emergency contacts. If you do not give the "all clear" in a user-configurable time period, the laptop does user-defined things like wiping encrypted volumes after giving an optional warning sound, optionally sending eeprom codes to brick the BIOS or replace the BIOS with a tracker and setting the screen to say "Stolen From User-Defined String, User-Defined Phone Number" after giving an optional warning sound. All of these actions could be optionally spaced apart based on risk, probably defined in a key-pair text file or json file.
User-Defined Phrase: "Computer, disable self destruct" disables "duress" mode.
- Giving the all clear code disables this behavior and your ship does not self destruct. The system plays a sound to acknowledge "all clear". Emergency contacts are emailed the all-clear, but audio/video continue to upload for user-defined time in the event your were forced to give the phrase.
Perhaps newer cars could also have this feature? Are there any existing open source projects that could be adapted/bent to accomplish these things?