BusKill: A kill cord for your laptop

Post by nodesocket » Fri, Jan 03, 2020, 2:36 AM UTC

alasdair_ wrote: post #164

jbarberu wrote: post #73

Earlier quoted context omitted.

If your attack vector is adversaries ready to deep freeze your laptop, perhaps you should do your computing in a more secure location :)

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.

Post by D2187645 » Fri, Jan 03, 2020, 2:54 AM UTC

stordoff wrote: post #55

tyingq wrote: post #41

Earlier quoted context omitted.

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 w…

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 actu…

Post by nwallin » Fri, Jan 03, 2020, 3:43 AM UTC

wongarsu wrote: post #35

k_sze wrote: post #16

Earlier quoted context omitted.

If you are doing proper OpSec, you would have whole disk encryption anyway, in which case destroying the computer is largely unnecessary, I think. That said, the caveat of XKCD 538 ( https://www.xkcd.com/538/ ) still applies.

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 vibr…

Post by bsder » Fri, Jan 03, 2020, 4:15 AM UTC

jmercouris wrote: post #118

Nextgrid wrote: post #112

Earlier quoted context omitted.

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…

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.

Post by beatgammit » Fri, Jan 03, 2020, 4:25 AM UTC

faceplanted wrote: post #54

wongarsu wrote: post #35

Earlier quoted context omitted.

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 vibr…

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.