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
You must log in or # to comment.
That’s not possible because of the way disk encryption works. When you unlock an encrypted drive, it does not actually decrypt it - that would take way too long and leave the disk unencrypted. Instead, the computer keeps the key in RAM and uses it to decrypt the accessed data blocks on the fly.
Thank you, and indeed, I realise that I may have been asking for the impossible
Honestly, I am just so curious about your threat model that you are considering this for self hosting.
What do you mean?
What he means is, your security considerations here must come from some perceived threat. What kind of threat do you forsee that requires this high level of security?
Usually when you consider security you start with a threat model, describing the scenarios you want to protect your systems from. And based on that you decide the necessary technical security measures that are relevant.
The key needs to be available to continue to be able to decrypt the data on the device. All encrypted data is not decrypted as you mount or unlock your encrypted device, that is done one the fly as you use it.
The attack you are thinking of should also not be relevant. What you worry about appears to imply that you are more concerned about the key being protected, rather than the data the key protects. You seem to wish to have your decrypted data available, but not the key.
Thank you, I realise that what I’m asking for might not be physically possible. I’m certain that RAM loses all of its contents after a loss of power, but would it be possible to pad the RAM before/during the shutdown process to make sure that nobody gets to the key?
Yes, but: somebody trying to attack your machine that way would cut the power and try to freeze your memory modules. So that mitigation wouldn’t trigger.
If you think you really need to guard against that attack you’d have to look into physical security: At room temperature there’s a pretty short window available for saving the contents. So if you manage to remove access of possibly used cooling agents to the memory modules you already made things quite tricky.
Now if you can make removing the memory modules hard as well, and prevent booting anything but what you want to be booted there’s a decent chance it’ll be impossible to recover memory contents.
If that still isn’t good enough you’d have to look into providing a means of physical destruction of the memory modules triggered by a backup power source inside the case on unexpected power loss.
Thank you for the comprehensive answer. I will go through it again and attempt to implement some of these mitigations.
Thanks again, I saved your comment
Take into account that your average police raid will not attempt that - they just don’t have the means for that.
If you have managed to become an important enough target that either specialists get called in, or you’ve managed to become target of three letter agencies or the equivalent in your country you will have been targeted by other attacks to gain access to your data, both software and hardware - and if you have to ask that kind of question here you’re very unlikely to successfully defend against them.
Thanks for your reply. Fortunately, I am not a person under such scrutiny, and the only reason I ask this is because I’m paranoid.
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.
If an attacker wants your encrypted data that bad, they will attack the running machine and use it to access the data, they will not steal a key and then attempt to physically remove the drive.
Drive encryption is for prevention of access when the drive is offline, it doesn’t protect a running system which can access that data.
If you are worried about the key being accessed while the machine is running, focus on hardening access to the machine via network, etc.
This machine will not be connected to the Internet, and the only way to get to it would be a VLAN-hopping attack (in which case, I’ll have to think of something else)
I’m assuming it stays in the RAM till the time the computer shuts downs
Correct.
We know that one could, in theory, get a dump of the contents of the RAM in such a state, if done correctly.
An example of such an attack would a “cold boot attack”.
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?
It sort of depends on how the underlying hardware is designed. You can create a system in which the RAM’s contents are encrypted by the hardware, but at some point the data must be decrypted for use. For example, one could theoretically sniff the data-lines between the RAM, and the CPU. This is all of course ignoring the fact that the hardware, itself, could be compromised i.e. Intel M.E., backdoors/vulnerabilities in the BIOS, etc. There’s lots that can be done to try to mitigate security vulnerabilites, but there is always a tradeoff between security, and convenience.
Maybe the best form of security is memorizing a private key, then manually doing the math with a pen and paper to decrypt some text, and transmit it with a carrier pigeon.
Thanks
I wouldn’t attack via USB, that path has already been too well thought out. I’d go for an interface with some sort of way to get DMA, such as:
- PCIE slots including M.2 and external thunderbolt. Some systems might support hotplug and there will surely be some autoloading device drivers that can be abused for DMA (such as a PCIE firewire card?)
- Laptop docking connectors (I can’t find a public pinout for the one on my Thinkpad, but I assume it’ll have something vulnerable/trusted like PCIE)
- Firewire (if you’re lucky, way too old to be found now)
- If you have enough funding: possibly even ones no-one has thought about like displayport + GPU + driver stack. I believe there have been some ethernet interface vulnerabilities previously (or were those just crash/DOS bugs?)
Thank you, I’ll need to think more about possible attack vectors
Sharing this article as I think it ties in with this conversation well: https://www.zdnet.com/article/cryogenically-frozen-ram-bypasses-all-disk-encryption-methods/
I do want to say that for most people, this is likely NOT a concern, but I don’t know OPs threat model.
deleted by creator
