Live data from Hacker News

BusKill: A kill cord for your laptop

tech.michaelaltfield.net

201–210 of 272 posts

Re: BusKill: A kill cord for your laptop

#201

Ross Ulbricht had his laptop snatched by an undercover FBI agent while he was using it. This kill cord might have saved him some grief.

Indeed. Better, perhaps, would be to trigger wiping the LUKS header and deleting the boot partition.

The hard question is how to put an easy-to-use self-destruction mechanism in an existing machine (only the NSA can make a customized machine), and, at the same time, ensure the safety of the self-destruction mechanism. A self-destruction button is a safety risk if it can be triggered accidentally or maliciously, on the other hand, a secured self-destruction button is a safety risk if it's too hard to trigger.

The NSA laptops have two buttons on one side of the machine, to destruct crypto keys, one needs to open a cover and press two buttons simultaneously. It's a pretty good self-destruction button. But you cannot find it in your laptops.

Or perhaps you can design your kill switch like the Russian nuclear Dead Hand - the automatic nuclear retaliation mechanism is only armed if a safety switch has been explicitly switched on, in peacetime, the switch is turned off to avoid an accidental nuclear apocalypse. But remember to arm the switch every time you travel with your laptop became a question.

Re: BusKill: A kill cord for your laptop

#202
post #197

Earlier quoted context omitted.

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.

> D-Bus is not part of the problem 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.

Re: BusKill: A kill cord for your laptop

#203

Earlier quoted context omitted.

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

> 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.

> 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.

Re: BusKill: A kill cord for your laptop

#204
post #89

Earlier quoted context omitted.

I'd like to see a post demonstrating this attack.

For getting encryption keys from RAM after shutdown there's this video mentioned by another commentor: https://www.youtube.com/watch?v=JDaicPIgn9U 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…

> 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:

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.

Re: BusKill: A kill cord for your laptop

#205

I used to have my laptop setup to require my specific Yubikey to be inserted to allow waking from sleep and booting, and when you pulled it out it locked the machine, logged you out, suspended, or shutdown depending on which modifier key you were holding down when you removed it. Worked pretty well as a "kill switch" when getting up from my desk. I probably have the udev scripts laying around somewhere.

Sounds like a good way to hit the 10k usb-c lifespan

Re: BusKill: A kill cord for your laptop

#207

Earlier quoted context omitted.

It's not quite ready to go, but it's doable with TrueCrypt/VeraCrypt: https://www.veracrypt.fr/en/VeraCrypt%20Hidden%20Operating%2...

Why is it not ready to go? I used truecrypt hidden systemvolume years ago? I do not anymore, but did it decreased?

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.

[0] [PDF] https://opencryptoaudit.org/reports/TrueCrypt_Phase_II_NCC_O...

[1] https://yro.slashdot.org/story/08/07/17/2043248/schneier-uw-...

Re: BusKill: A kill cord for your laptop

#208
A gentle warning: different Linux distros handle UDEV "remove" differently, and incompatibly, so few people actually use this message it's not well tested (try shipping code for a device that DOES need it!).

Debian was a particular problem until they switched to SystemD (which I think is possibly the only udevdaemon that gets it right) - even so some distros (Ubuntu I'm looking at you) screwed up starting the udevdaemon before they mounted root writable meaning that scripts run from it couldn't really do anything useful

Fortunately most distros are switching to SystemD so this will likely work in most places

Re: BusKill: A kill cord for your laptop

#210

A gentle warning: different Linux distros handle UDEV "remove" differently, and incompatibly, so few people actually use this message it's not well tested (try shipping code for a device that DOES need it!). Debian was a particular problem until they switched to SystemD (which I think is possibly the only udevdaemon that gets it right) - even so some distros (Ubuntu I'm looking at you) screwed up starting the udevdae…

BTW - a clue for budding writers of UDEV scripts - you can't run daemons directly (udevdaemon will kill them when the scripts that started them exit) - you can use "at now" (after you install at of course) to start a secondary script that will be allowed to start your daemon for you

(that way you can write code that works with all init systems, largely by avoiding them)

Post reply on HN