Hi everyone, I found the great question on booting encrypted drives, and since I’m somewhat paranoid I’d like to ask a follow-up:
When the key to decrypt the drive is input into the system, I’m assuming it stays in the RAM till the time the computer shuts downs. We know that one could, in theory, get a dump of the contents of the RAM in such a state, if done correctly. How would you deal with this problem? Is there some way to insert the USB, decrypt the drive, and then remove the USB and all traces of the key from the system?
Thanks!
Edit: link to the question I referenced: https://feddit.de/post/6735667
This level of paranoia isn’t really compatible with modern hardware, and requires a lot of effort.
You’re pretty much limited to stuff that has open firmware available, and even then you have to hope there are no bugs or backdoors in the hardware.
For the intel world almost everything with open firmware is pretty old - some nowadays unsupported, which means no longer microcode updates. And those microcode updates also are a problem - you can’t mitigate everything in kernel space, so usually you’d want them, but they’d also be an attack vector against you.
And even if you manage to trust the computer itself there are a lot of attack vectors surrounding it. Do you have anything capable of recording audio in the same room as your computer? If yes, not a good idea - it has been proven possible to extract passwords from audio recordings of a keyboard. Does the room have windows? That counts as an audio recording device.
If you got rid of that, do you have some other hardware with sensors? There’s a high chance that a device placed on your desk containing an accelerometer would also be capable of extracting your password.
I’m so glad that you brought this up. As might be apparent, I have fairly strong sentiments regarding freedom of software. I won’t be spilling everything I feel into a single comment, but needless to say, this is a subject I feel strongly about.
On hardware
I absolutely detest Intel and Qualcomm. I wish them the worst in their collective futures (alongside the likes of Samsung and Mediatek too, but I’ll keep to the two of these for now). I have a soft spot for AMD for sticking with the FOSS community to an extent and for their affirmative action towards open silicon initialisation with OpenSIL.
I am not one to drink, but I will personally purchase an expensive bottle of wine from the nearest Costco on the occasion I feel that RISC-V has finally reached the realm of everyday computing. Unfortunately, that seems to be a while away, with SBCs being the only ones to bring the technology forward.
On software
On a related note, I am almost equally annoyed at software that has been locked down. Embedded software like the one in the EC and the PCH, alongside proprietary drivers in peripherals and microcode like you described, are something I wholly abhor.
But that was a lot of complaining. If you go through my posts, just the other day I was asking if the T440p was the last Thinkpad I could put Coreboot on (the answer is yes), alongside which I went over me_cleaner and the AMD PSP remover. I do not prefer Coreboot either, but it’s the best we can do till probably 2030.
On physical security
I will be employing Faraday cages and metal shielding liberally around my electronics, in an attempt to prevent some of what you mention. Unless we’re talking about undisclosed exploits in Android, removing Google and most other proprietary applications should do the trick (I doubt I can do much if the NSA really wants to listen). Of course, by that logic, me_cleaner should be good enough too, but I digress. Of course, all network traffic will be logged and I will operate on a “whitelist by case” basis.
Thank you for bringing across the point of spying using an accelerometer (I’m interested in how that would work, could you point me towards what I should look for?), I’ll make sure to utilise simple and easily auditable hardware.
This is not a perfect method, and I have a lot to learn about OPSEC and cybersecurity. Thanks again for your comment.
I’m quite happy with having proper graphics cards again thanks to AMD working with their open source driver - and also looking forward to OpenSIL. Though there’s still the problem with the PSP in their CPUs.
Did you checkout heads? That’s what I’m using on my x230 - seems to be currently the most sensible choice for portable hardware.
Also make sure to shield cables. There’s not much public research into passive RF, but from the few people who looked into that we can say that the situation is bad, and the bad guys probably can do a lot of bad things (most likely both display signals and keystrokes from a USB or PS/2 keyboards can be recovered reasonably well from some distance by just analysing the RF sent by the cables)
Pretty much all phones sold in a bit over a decade no longer have a separate baseband. With a unified memory architecture you possibly have a remotely exploitable (remember, baseband) access to the OS memory, if you manage to bypass memory restrictions - in which case none of the mitigations in the OS will help you as it’s just not aware of you being there. While this is a pretty complex attack it unfortunately has been proven in a few cases to be possible. I don’t keep very important stuff on my phone - I don’t consider it trustworthy.
Seems research about being able to recover a phone password/pin by using the phones accelerometer is shadowing search results - I’m pretty sure I’ve seen a paper about a phones accelerometer being used to reconstruct key strokes of a keyboard on the same table a few years ago - pretty much same idea as recovering the keystrokes via sound.
Also note that things like hard disks contain their own embedded computer, and in some cases contain an accelerometer. They also have DMA access…
Or, you could address that paranoia problem directly.