I was expecting a "kill switch" destroying the computer, but that's just a thing that switch off your laptop when unplugged. I guess you could also do this with bluetooth, for example.
"Kill cord" is jargon from jetskis, powerboats and treadmills, which often have a cord you attach to your body that cuts power if you are thrown off. [1]
On Linux there is blueproximity [2] that can lock (and if you like, unlock) your computer based on the proximity of a bluetooth device. My personal experience is that Bluetooth is frustratingly unreliable, and this package was no exception. But it's there if you'd like to try it!
Bluetooth on Linux is an unprecedented abomination.
You’d think most of it would be similar to network interfaces, handled by the kernel with commands such as ip, iptables, etc to configure it?
Wrong! Instead it’s mostly done in userspace and the tools to talk to it are using D-Bus which is an opaque, inconsistent, hard to understand mess which you can’t easily interact with programmatically.
As horrible as BT itself is I’d give the protocol itself a break in this case and focus on the terrible implementation.
D-Bus is not part of the problem... it is just the common bus for communication between user processes. It is in fact a very straightforwards and well implemented specification.
Only in the sense that the bluetooth maintainers never completed the port to D-Bus. So, 25% of what you need to do with bluetooth needs to be done via kernel anyway.
Bluetooth on Linux is a prime example of how open source can fail.
The Bluetooth stack itself is an overcomplicated, terrible specification that leads to most Bluetooth chips have an _incomplete_ port of their own vital functionality.
It isn't shocking that the thing to talk to them isn't complete.
I only tested with my smartphone, as it's the only bluetooth device I reliably carry with me.
I'm sure there are configurations that work - blueproximity probably worked well for its author, or they wouldn't have released it! And I gather Windows offers "Dynamic lock" which locks the screen based on bluetooth.
However, having experienced bluetooth unreliability with Linux, Windows, Android and iPhone; and with mice, GPS receivers, cars, access control systems and sports watches; I am confident the unreliability was not unique to a single bluetooth device.
In theory an adversary could deep-freeze the computer the moment the kill cord activates. Sufficiently cold RAM doesn't loose data immediately when it loses power, allowing the adversary to make a copy and read the decryption keys from RAM.
Though if this is part of your threat model you should be much more concerned about a thousand more mundane problems, like adversaries reconstructing keystrokes from keyboard vibrations that are easily measured with a laser, or reconstructing screen content from reflections on a spoon.
It's pretty common for law enforcement to quickly freeze RAM when busting hackers. I've definitely read of cases where suspects encryption keys were pulled from RAM using exactly this method.
The killcord would have been useful for Ross Ulbricht (Silk Road) who was busted by the FBI after using his laptop in public - they grabbed it while he had it unlocked and didn't have time to put it in suspend.
If you can't prevent the device from powering down, you have less than a minute to freeze the RAM before the contents become useless. This can be done with a can of cold spray.
No idea how long you have to power it back on afterwards, tens of minutes to a couple of hours probably.
That said, the proper "kill switch" operation would be to explicitly wipe the key from memory before powering off (if you want to power off instead of just locking).
> you have less than a minute to freeze the RAM before the contents become useless. This can be done with a can of cold spray.
I wonder what their approach to a laptop with poor serviceability would be. I think it would take me more than a minute to get physical access to the ram of some modern computers.
> Ross Ulbricht (Silk Road) who was busted by the FBI after using his laptop in public - they grabbed it while he had it unlocked and didn't have time to put it in suspend.
That’s pretty smart by the FBI agents to wait until it was unlocked and sneak up and take it. If instead they stormed in guns drawn, all Ross had to do was close the lid and bye bye evidence.
A secure location is an ICBMable location. (Not that anyone realistically has this problem, but “so safe that Bin Laden would still be alive” feels like the right level of overengineering when it comes to OPSEC.)
There's sdmem for Linux boxes. It has a -l and -ll option that makes it reasonably fast. So a combination of a duress encrypted volume, then killing only "sensitive processes", then clearing cache via /proc/sys/vm/drop_caches, then sdmem followed by halt might be reasonable protection. Your second point, though, makes sense. It won't always be someone physically grabbing your PC.
I would expect the unmount of an encrypted filesystem to secure delete the encryption key from memory. My understanding of the memory freezing attacks is that you don't unmount it, you just kill the power by removing the battery.
With this method, you would still be able to freeze the RAM, reboot the computer, dump the RAM, and disassemble the kernel memory, and discover where the disk encryption key was stored: in that location, you'd find all zeroes.
My preferred method is a custom kernel build that does a few extra obfuscation steps before or after encryption on each data block. While you might find my key in ram, good luck decompiling my kernel module based on a bitrotted ramdump. Simply not storing the key contiguously unless there is an actual IO operation going in is a good start - scatter it around the heap so a simple search won't find it.
In reality, RAM doesn't so much instantly lose its contents on power off anyway, the freezing just slows it down. IIRC there are cases of recovering significant portions of RAM a half hour or more after poweroff even without freezing.
You're right, I think an attack could be possible on some computers if the agents act very quickly. I don't think 30 minutes would be possible though, judging from what is said and shown in the original cold boot video:
I agree with your comment, I'm not disagreeing with you. Just offering a story I thought was interesting on a recovery technique that works in theory.
I read an article many years ago (I don't have a link but if you're interested google might find it) before ssd's were mainstream. They took a hdd and did one pass of overwriting it with /dev/zero.
Then they contacted some data recovery companies, told them they accidentally blanked the hdd with one pass, and ask for a quote to retrieve the data.
None of them had any interest in giving a quote or trying to recover the data even though in theory it could be recovered with a microscope or however they do it.
As you said, there are a 1000 more mundane ways that would be cheaper and more reliable than deep freeze.
How long does it take RAM to lose that data though? Most laptops take far more time to remove the ram than a PC and it's soldered down in a lot of cases.
Suprisingly long. I've played around with that a bit a while ago and sometimes up to minutes later you could still recover recognizable bitmaps. But definitely not something you should rely on if you want a bit perfect copy, the first bits start to flip immediately upon power loss, some of them take a lot longer and our brain is pretty good at such reconstruction from noisy data, especially if it knows what it is looking at.
I guess the higher the RAM capacity the shorter it would be because of the decrease in physical cell size.
For using reflections, there's this paper implementing reading screen content from various things like reading glasses, a can of coke or even the user's eye (including a discussion of limitations): http://gauss.ececs.uc.edu/Courses/c6055/extra/reflections.pd...
Right now I can't find something on reading keyboard vibrations with lasers, but here's one doing it acoustically and one doing it via acclerometer of a phone on the table:
> Right now I can't find something on reading keyboard vibrations with lasers, but here's one doing it acoustically and one doing it via acclerometer of a phone on the table:
TrueCrypt shuttered in 2014, though an independent audit didn't find any significant issues in 2015. [0]
VeraCrypt is one of the main forks that has picked up popularity, and has addressed some of the minor concerns of the audit.
The hidden volume hasn't had a high degree of success when it comes to deniability [1]. Some leaks closed, probably not all. With the design, it may not actually be possible to close all the leaks. (Especially as "Stoned" can break the full-disk encryption).
TrueCrypt doesn't use the TPM (and nor does VeraCrypt), because the authors didn't believe it added any security whatsoever (as it can't defend against a hardware keylogger, despite making coldboot attacks harder).
TrueCrypt is vulnerable to coldboot, evil maid and the "Stoned" bootkit. Depending on your security concerns, that might be fine, it might not. Other solutions may be better when dealing with those attacks.
The "plausible" part is what seems not out of the box to me. Some easy way for the decoy image to show recent real looking activity, and an easy way to use the real image. Probably some integration with a VM or container.
I took ready to go to mean "run a command and it spins up a plausible fake system". The tech of TrueCrypt/VeraCrypt, AFAICT, seems sound, but maintaining the contents of the fake system (so it's not an obvious decoy/placeholder) takes more work.
Well, you would probably want some stealth that doesn't provide that makes it less obvious. Like maybe the duress passphrase decrypts everything except a docker container you use for sensitive work, replacing it with a vanilla docker image.
Edit: Ahh, read up a but. I wasn't aware "veracrypt hidden volumes" are already pretty stealthy. Would probably require some work to make it plausible though...like recent faked web browsing history.
The VeraCrypt guide recommends "You should use the decoy operating system as frequently as you use your computer. Ideally, you should use it for all activities that do not involve sensitive data." You don't need to fake it per se, but section off what needs to be in the hidden operating system (rather than a standard VeraCrypt partition). You are therefore revealing real, thus plausible, information, but not the actual subset you want to hide.
Are we going too overboard hiding our fetish video collections? My family members just leave thier dvds lying around, meanwhile Im encrypting every hd I can.
I think waterboarding is more common. For US citizens they're usually stuck with just solitary confinement, which is a working form of torture but is kind of slow.
That would be far too direct and brutal. Put them in prison until they talk and let the inmates know that they are refusing to decrypt their PC. The inmates will soon enough make their own assumptions why and do the beating themselves. Of course protective custody would be an option, but that is just even further isolation and mental torture.
If the FBI traces illegal activity to a cafe / library / wework office, and you're the only one with a kill cord attached to your belt with a carabiner, guess who they're going to target first.
You could get similar outcomes to that if you used FDE and had it power off the machine fully. But then also your cat might ruin your day with one step :purplegirlshrug:
I think most MacBook Pros have some accelerometer functions you can access. I wonder if you could create a util to detect if your laptop was picked up and automatically log you out.
In this case that may not have been useful, assuming law enforcement knows about the cord. Law enforcement will plug in a mouse jiggler (simulated moving USB mouse), having the script detect rogue USB devices and shutting down at that moment would add another layer of protection. I saw that solution a few years back... Maybe this works doubly well for devices with USB and USB-c power connections now... Since law enforcement try to keep power running on machines seized in this way.
How would they know about the cord? Or something more stealthy, like Bluetooth?
I don't think a mouse jiggler would help. A dead-man script would force a fast, ungraceful OS halt. Maybe after emptying some caches and wiping memory.
Whenever I read stuff like this I am forced to wonder just what the fuck people are doing that they feel such a pressing need to hide their data from law enforcement.
I mean, I have plenty of things to hide just like any other reasonably interesting person, but none of it is outright criminal.
There's no shortage of things someone might find morally acceptable themselves while still being potentially criminal. Or grey area stuff, like a business that sells marijuana in a state where it's legal, since the US federal government doesn't consider it legal.
Or use cases like a crypto wallet. Where legality isn't the main concern.
This would be useful outside of "hiding from law enforcement". Plenty of people have jobs where the compromise of their laptop could cause significant damage to their employer or their customers. Many people ready this thread should be taking these precautions.
If you happen to have an opinion that is not shared by the current powers-that-be, law enforcement will be happy to look at your data under any pretense it can cook up.
And they'll be equally fine with - ooops! accidentally, of course! - leaking info that you'd like to stay hidden, even if it's not anything criminal.
In other words, it's just a bunch of self-important tech asshats deluding themselves into believing they are important enough to warrant FBI attention?
Eh, believable, but I think it's more likely a lot of them are evading taxes or committing securities fraud.
I would probably look into it if I was already on some government agency's radar for whatever reason. You've probably broken a ton of obscure laws yourself without knowing it.
Yeah, all reasonable, I just have difficulty believing that the people who post things like the parent are actually involved in any of those activities.
Maybe I sell marijuana in a US state where it's legal, but still have reservations about the Federal government. Or maybe it was just an example and I happen to find the topic interesting.
Have you ever remembered something that you left in a home directory on someone else's server but only after you no longer had access to it? It wasn't sensitive but then, it wasn't something you'd leave in a public place like foo.com/~name, either. You can't convince yourself they had the inclination to just delete all your trash. You know of at least one person who might have gained access (you don't know whether) and he probably would have engaged in some voyeurism. Everyone who knew him after you were gone knew that he was an asshole, and your one brief interaction with this person indicates that's an understatement.
Did that feel good? Well, it was preventable. That's a kind of thing that a reasonably interesting person might want to prevent.
Anyway, this happened. Not that I'm, like, supposed to be reasonably interesting or anything. ;)
Yeah, it's fine to have stuff you want to hide for a lot of reasons. The problem I have with what the parent posted is that the specifically invoke "FBI" as what they're afraid of. That suggests to me that they aren't just hiding embarrassing or private information, but specifically something illegal. Now, as other posters have mentioned, parent could be an activist or something, but frankly I doubt that everyone I've seen post something similar is. I'm left with the conclusion that in addition to being holier-than-thou assholes and pedants, a lot of tech people are also casually engaged in things like tax evasion and securities fraud.
Yeah it is kind of silly. If you aren't truly anonymous, you blow out some of your deniability just by discussing deniability. You said law enforcement and I straw manned another thing today. Great.
I was expecting a "kill switch" destroying the computer, but that's just a thing that switch off your laptop when unplugged. I guess you could also do this with bluetooth, for example.