Originally published at: https://boingboing.net/2019/09/10/rule-of-law-security.html
…
4 Likes
You missed a great option, Corey: encrypted file systems that provide different views based on which password is entered.
Think of a file system like a one-time pad, only you keep two decoder pads. The first one decodes the encrypted file system into your authentic file system with your actual files. The second one decodes the exact same encrypted file system into a completely different file system - one that looks legitimate, but that doesn’t have your actual secret stuff. Maybe it has just enough damaging or embarrassing information to convince an attacker that it’s the real deal, but you keep the best stuff in the first file system.
When you’re coerced, you give the attackers the second password. You don’t even admit the existence of the first password. And nothing about the file system suggests that there is any first password.
How is that possible? Imagine that your file system, by default, stores the hashes of 256 passwords. Each password may or may not decrypt a one-time pad that’s used to decrypt a view of the file system. Two slots hold the hashes of your actual passwords - say, slots #136 and #242 - and the other ones hold hashes that are garbage, that don’t correspond to any typeable password.
In this system, every update of the file system causes a recalculation of the one-time pads in an asymmetric manner (i.e.: if you know what’s in the file system, you can encode the one-time pad using a public key, but you need the corresponding private key to decode the file system using the one-time pad). The major difference is that the pads that you’re using, the ones that correspond to passwords you’ve stored, properly translate to the views of the file system that are reflected by each decoding - whereas the pads that you’re not using encode garbage.
With this system, it is impossible for an attacker to prove or disprove that any particular pad is or isn’t in use; that any particular slot is or isn’t in use; or what the contents of the file system would look like, without the pad that’s decrypted using the password. All they see is the file system for the password that you reveal. They can never prove that anything else exists if you don’t tell them.
Yes, this scheme is mathematically quite challenging, and computationally very expensive. Your storage device basically needs a massive, high-performance ASIC that encodes and decodes all 256 views of the file system and/or the corresponding one-time pads, in parallel for every read or write. It may not be reasonably feasible on modern hardware… but I wouldn’t underestimate the capabilities of a lot of engineers given a lot of time and resources. And the advantages of legitimately bulletproof deniability are probably highly coveted in some circles.
6 Likes
I like the general idea you described of having multiple keys required to change the software/rules/plan, distributed Amon people in a variety of non-allied countries. That would solve a lot of problems.
I think TrueCrypt accomplished the same basic idea some years ago. I don’t remember the details, but essentially you point to the encrypted drive and Password A unencrypts one set of data, but if you had set it up properly, Password B unencrypts a second set of data. I believe they claimed that it was not possible to tell whether or not there were two
2 Likes
I work in this domain, and I agree with her point of view, but then I start reading the actual technical steps needed to do it correctly (2 teams, with 2 sets of 2 of 4 threshold signing, and tested, rehearsed processes for threshold key revocation, etc…) and then I remember that in a previous job I lost days explaining fundamental CS concepts like locking to theoretically senior engineers, and that they would have been unable to use a password manager because they were so incompetent with cut and paste… then I ask myself “Really? That’s really going to work?”
Then I have another coffee, and get to work trying anyway. 
6 Likes
A few years ago when Google Glass was still a thing, me and a few colleagues pondered over how they could be used to prevent coercion. We had this idea that if you ran a free-speech friendly ISP then you would always wear your Google Glass (or similar) and have them pointing at you as you sleep. All the footage would be transmitted to a trusted reviewer in another jurisdiction. If nothing of interest happened the reviewer would keep deleting the footage. But as soon as something odd happened e.g. a warrant being served etc they would release the footage.
The idea was to make a gagging order impossible, by making it impossible to serve one without more than one person knowing about it.
Of course it would be hard to pull off technically, but it could work if someone was determined enough.
1 Like
Yeah, the hidden volume feature. Of course, we shouldn’t be using truecrypt anymore but the audited veracrypt has the same feature, being as it is a fork of the former.
Sorry, you lost me there. What?
1 Like
So basically a Veracrypt style hidden volume? Iirc these are hard unless the hidden volume is much smaller than the main.
As I recall, that was a different idea: encrypt the entire storage device, and allow each password to unlock a portion of it as a file system. So a first password unlocks 50%, and the other 50% either contains a second file system that’s unlockable with a second password or contains garbage - it’s impossible to tell which.
Unfortunately, that scheme has a few obvious disadvantages.
First - as a practical matter, this scheme requires sharding your capacity over each password or garbage space. People aren’t willing to sacrifice big chunks of their storage capacity to sit idle or to hold a second operating system.
Second and more importantly - the attacker can always tell which portion of the file system has been allocated for whichever password they’ve been given. The drive is 1 terabyte, the mounted file system is only the first 500 gigabytes… that suggests that the second half is used either for a second file system or as garbage. You can’t prove which, but you do know that the user has gone to some lengths to create plausible deniability about that 500 gigabytes.
Third - you can make a pretty good guess that the unused space probably isn’t garbage. By analogy - people don’t go through the effort of mounting a hack-proof safe in their homes just to put nothing in it. Similarly - people don’t waste big chunks of their storage capacity just to store garbage. It’s actually worse than that: people don’t intentionally create the appearance of hiding something, of casting suspicion on themselves, if they aren’t actually hiding anything.
The system I described doesn’t have any of those problems.
Interesting. I can see the problem with the file system, but if the drive is just files, and what I am protecting is text files, a 64GB drive that only is using 2GB wouldn’t raise any flags. If after being beaten with a wrench for a while, I give up a password that gives “just enough damaging or embarrassing information to convince an attacker that it’s the real deal,” I should be ok.
Actually, just checking my main non-os drive, it is 4TB and only 1.5TB is being used. Storage is cheap.
groovey , but needs more blockhain
True. Talking about it, anyone ever got to the point to explain why that particular project was, quite abruptly, ended?
But this is fragile: ostensibly democratic countries like Australia have banned using warrant canaries to reveal secret court orders.
That’s why my warrant canary’s message reads, “I’m not saying a secret court order was just issued against me…but I’m not saying one wasn’t, either.”
Storage is cheap.
But there’s a difference between mounting a 4tb volume for a 4tb drive, using 2tb of it, and leaving the other 2tb free… and only mounting a 2tb volume of a 4tb drive, with no explanation as to what the other 2tb is for.
One possibility (which, iirc, TrueCrypt did not offer) is to pretend that the hidden volume is free space when the dummy volume is mounted. So you have two passwords for a 4tb drive - one that mounts a 2tb hidden volume, and one that mounts the whole 4tb drive as one volume with 2tb+ of free space. If the user fills up the “free” 2tb and then also fills up the next 2tb, then it silently overwrites whatever is in the hidden 2tb volume.
This is pretty good, but it has an obvious problem.
Modern file systems are really good at mapping the capacity of a logical file to an arbitrary set of physical storage blocks - to the point where it doesn’t matter which blocks you choose. As a result, operating systems and storage devices just aren’t that picky about where they store stuff on the physical medium. If you want 2gb, you might get a 2gb slab that’s available anywhere on the platter / SSD, or four 500mb slabs scattered over the platter / SSD, etc.
Given that behavior, you’re forced into one of two options:
(a) Let the file system go ahead and be arbitrary as usual. The problem is that even if the primary volume every gets mounted and writes to the volume, there’s an excellent chance that it will arbitrarily write to the “free” space that actually constitutes your valuable hidden file system. The OS has no idea that it’s supposed to care which blocks it chooses, so it will happily overwrite your hidden data even if tons of actually-free capacity is available
(b) Make the file system use up the actually-free capacity before the capacity that doubles as the hidden file system. But an attacker can observe this peculiar, easily detectable behavior and deduce the presence of the hidden file system, which is exactly what you want to avoid.
(For people who depend on this level of secrecy - I’m thinking high-level espionage - it’s probably choice (a) all the way. If somebody mounts the file system with the coercion password, you probably want the hidden file system to be overwritten, as soon as humanly possible. Hope MI6 has a backup.)
1 Like
This topic was automatically closed after 5 days. New replies are no longer allowed.
