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.
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!
[1] https://www.rya.org.uk/knowledge-advice/safe-boating/look-af... [2] http://www.daniloaz.com/en/automatically-lock-unlock-your-sc...
In other words, did you test different bluetooth devices?
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.
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.
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.
It isn't shocking that the thing to talk to them isn't complete.
That said, the caveat of XKCD 538 (https://www.xkcd.com/538/) still applies.
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.
I do not anymore, but did it decreased?
[0] https://en.wikipedia.org/wiki/Deniable_encryption#Software
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.
[0] [PDF] https://opencryptoaudit.org/reports/TrueCrypt_Phase_II_NCC_O...
[1] https://yro.slashdot.org/story/08/07/17/2043248/schneier-uw-...
Exactly. One of my favourite vids is Don't Talk To The Police, it's the right thing to (not) do.
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.
I guess the higher the RAM capacity the shorter it would be because of the decrease in physical cell size.
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.
I’d really love a citation on this, especially since “quickly” seems to imply that they’d do this out in the field.
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).
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.
RAM is still one of the most accessible parts for most laptops & desktops.
Tablets and phones on the other hand make it much much harder.
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.
Drone strikes hit and kill hundreds of targets each year. Some on as little intelligence as an IP address used to click a link in a tweet.
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:
https://security.stackexchange.com/questions/23322/keyboard-...
https://dl.packetstormsecurity.net/papers/general/traynor-cc...
And here's how to get the acoustics with a chip packet, or glass of water or pot plant: https://news.mit.edu/2014/algorithm-recovers-speech-from-vib...
I'm not sure if that's high fidelity enough to match to a keyboard, but I'm sure that if MIT can do it, someone else can do it better.
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.
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.
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.
(Plus I tried several solutions to do this; BT is not really well suited for proximity detection, teeming with false positives and false negatives)
I'd be careful though, as you don't want any "misshaps". It's not likely worth going that far unless you're doing something very sensitive.
I mean, I have plenty of things to hide just like any other reasonably interesting person, but none of it is outright criminal.
Or use cases like a crypto wallet. Where legality isn't the main concern.
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.
Eh, believable, but I think it's more likely a lot of them are evading taxes or committing securities fraud.
Or politics (see Watergate), or being a public defender, or environmental activism, or... the list goes on.
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. ;)
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.
That sounds like exactly a good use case for this. Or maybe that's what you meant?