Follow-up question to mounting encrypted drives

Submitted ⁨⁨11⁩ ⁨months⁩ ago⁩ by ⁨MigratingtoLemmy@lemmy.world⁩ to ⁨selfhosted@lemmy.world⁩

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!

source

Comments

Sort:hotnew top

sirprize@lemm.ee ⁨11⁩ ⁨months⁩ ago
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.

source
- MigratingtoLemmy@lemmy.world ⁨11⁩ ⁨months⁩ ago
  Thank you, and indeed, I realise that I may have been asking for the impossible
  
  source
brygphilomena@lemmy.world ⁨11⁩ ⁨months⁩ ago
Honestly, I am just so curious about your threat model that you are considering this for self hosting.

source
- MigratingtoLemmy@lemmy.world ⁨11⁩ ⁨months⁩ ago
  What do you mean?
  
  source
  - gloriousspearfish@feddit.dk ⁨11⁩ ⁨months⁩ ago
    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 treat 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.
    
    source
mumblerfish@lemmy.world ⁨11⁩ ⁨months⁩ ago
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.

source
- MigratingtoLemmy@lemmy.world ⁨11⁩ ⁨months⁩ ago
  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 the key?
  
  source
  - aard@kyu.de ⁨11⁩ ⁨months⁩ ago
    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.
    
    source
    -> View More Comments
4am@lemm.ee ⁨11⁩ ⁨months⁩ ago
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.

source
- MigratingtoLemmy@lemmy.world ⁨11⁩ ⁨months⁩ ago
  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)
  
  source
Kalcifer@sh.itjust.works ⁨11⁩ ⁨months⁩ ago

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., the BIOS, etc.

source
- MigratingtoLemmy@lemmy.world ⁨10⁩ ⁨months⁩ ago
  Thanks
  
  source
WaterWaiver@aussie.zone ⁨11⁩ ⁨months⁩ ago
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

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 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?)
source
- MigratingtoLemmy@lemmy.world ⁨10⁩ ⁨months⁩ ago
  Thank you, I’ll need to think more about possible attack vectors
  
  source
njordomir@lemmy.world ⁨11⁩ ⁨months⁩ ago
Sharing this article as I think it ties in with this conversation well: zdnet.com/…/cryogenically-frozen-ram-bypasses-all…

I do want to say that for most people, this is likely NOT a concern, but I don’t know OPs threat model.

source
- surewhynotlem@lemmy.world ⁨11⁩ ⁨months⁩ ago
  For those not clicking the link, “cryogenically frozen” actually means an upside down can of compressed air.
  
  source
  - Markaos@lemmy.one ⁨11⁩ ⁨months⁩ ago
    On the other hand, it’s also worth noting that newer RAM generations are less and less susceptible to this kind of attack. Not because of any countermeasures, they just lose the data without constant refreshing much quicker even when chilled / frozen, so the attack becomes impractical.
    
    So from DDR4 up, you’re probably safe.
    
    source
  - njordomir@lemmy.world ⁨11⁩ ⁨months⁩ ago
    That was a perfect one sentence summary of the article!
    
    Its amazing some of the things people come up with like gathering intel on what a computer is doing via power draw changes, monitoring an air-gapped computers electromagnetic fields, or in this case “cryogenically” freezing ram with compressed air.
    
    source
- Tangent5280@lemmy.world ⁨11⁩ ⁨months⁩ ago
  OP is likely Raoul Silva, the antagonist from Skyfall (2012).
  
  source
tagginator@utter.online [bot] ⁨11⁩ ⁨months⁩ ago
New Lemmy Post: Follow-up question to mounting encrypted drives (https://lemmy.world/post/9668038)
Tagging: #SelfHosted
(Replying in the OP of this thread (NOT THIS BOT!) will appear as a comment in the lemmy discussion.)
I am a FOSS bot. Check my README: https://github.com/db0/lemmy-tagginator/blob/main/README.md
source