encrypted tmpfs - Running /tmp /var/lock and /var/run in encrypted RAM

cynicalpsycho · 2015-05-13 13:02:08

BLUF: I'm using an SSD on my system, so I'm primarily doing this to increase the life of my drive. But I'd also like to know if it would make any sense to encrypt volatile memory for security purposes.

From an anti-forensics point of view the ram would be viable for recovery for only a few minutes after shutdown (slightly longer with some air-duster hacking). My question is to prevent a cold-boot recovery in this very unlikely case, would encrypting the contents of a tmpfs with something like dm-crypt be viable?

Resources
https://wiki.archlinux.org/index.php/Tmpfs

gay · 2015-05-14 00:18:12

Hoping that I don't misunderstand your question: I have no idea if it makes sense (as far as I remember, coldboot attacks are always treated as fairly unrealistic), but of course it is viable. To do it manually, you can, for instance, do

sudo mkfs /dev/ram0 64m
sudo cryptsetup luksFormat /dev/ram0
sudo cryptsetup luksOpen /dev/ram0 ram0
sudo mkfs /dev/mapper/ram0 
sudo mount /dev/mapper/ram0 /whereever/you/want/it/mounted

Note that this is not quite efficient, as the filesystem is created twice, since I do unfortunately not know another or more generic way to slice out a piece of the RAM, but it works. And of course, you can mount it everywhere you want, including at /tmp or /var/lock or /var/run.

Since it works manually, I would think, that there should be a way to convince crypttab to do it you would just need to ensure that the device (/dev/ram0 in the above example) is created before crypttab acts.

ewaller · 2015-05-14 03:41:09

cynicalpsycho wrote:

From an anti-forensics point of view the ram would be viable for recovery for only a few minutes after shutdown (slightly longer with some air-duster hacking). My question is to prevent a cold-boot recovery in this very unlikely case, would encrypting the contents of a tmpfs with something like dm-crypt be viable?

Are you seriously worried about this? Environmental and side channel attacks are real, but damn difficult and expensive. Expensive in terms of equipment and the expertise required to pull them off.
It is a PITA to build memory controllers that do keep dynamic memory from losing their contents after 100 mS -- I know, I've done it.
I've also built systems that have secret keys that have to vanish in response to a physical attack -- including environmental attacks. We used static registers with direct clear instead of dynamic registers for that very reason. We did this because of the high value of the stuff we were trying to protect.

The rule is that data are only safe if it costs more money to steal them then they are worth.

What are the value of your data? Why do people want them? How motivated are they?

cynicalpsycho · 2015-05-14 13:33:41

ewaller wrote:

cynicalpsycho wrote:
From an anti-forensics point of view the ram would be viable for recovery for only a few minutes after shutdown (slightly longer with some air-duster hacking). My question is to prevent a cold-boot recovery in this very unlikely case, would encrypting the contents of a tmpfs with something like dm-crypt be viable?
Are you seriously worried about this? Environmental and side channel attacks are real, but damn difficult and expensive. Expensive in terms of equipment and the expertise required to pull them off.
It is a PITA to build memory controllers that do keep dynamic memory from losing their contents after 100 mS -- I know, I've done it.
I've also built systems that have secret keys that have to vanish in response to a physical attack -- including environmental attacks. We used static registers with direct clear instead of dynamic registers for that very reason. We did this because of the high value of the stuff we were trying to protect.
The rule is that data are only safe if it costs more money to steal them then they are worth.
What are the value of your data? Why do people want them? How motivated are they?

Your primary premise is invalid. Cold boot attacks are neither expensive nor difficult. Anyone with a thumbdrive, physical access, and a connection to the internet could pull one off. Both the knowledge and the means (Access to a distro that can perform a RAM dump.) are freely available.

Reference:
https://www.ethicalhacker.net/features/ … tion-tests

You're also incorrect to assume that volatile memory invariably loses it's contents after 100mS. The contents of RAM can be made to last and be recovered for a decent amount of time after shutdown. (Especially with a little compressed-air hack) -- I know, I've done it.

Reference
https://citp.princeton.edu/research/memory/

We also confirmed that decay rates vary dramatically
with temperature. We obtained surface temperatures of
approximately −50C with a simple cooling technique:
discharging inverted cans of “canned air” duster spray
directly onto the chips. At these temperatures, we typically
found that fewer than 1% of bits decayed even after
10 minutes without power. To test the limits of this effect,
we submerged DRAM modules in liquid nitrogen
(ca. −196C) and saw decay of only 0.17% after 60 minutes
out of the computer.

And in reference to threat modeling: my risk is fairly low, however the people I work for have a significantly higher threat level to concider. As I've said in previous threads. My motivation for doing this on my own system is more for the experience and familiarization than for any actual risk to my self/data.

Last edited by cynicalpsycho (2015-05-14 14:52:03)

ewaller · 2015-05-14 15:40:02

Well, their paper identifies several attacks. I was only speaking to those where they use reduced temperature to increase persistence. I had not even considered a reboot to a small footprint OS after a short power interruption.

I do not accept that all DRAM is as cooperative as that used in their experiments. Be that as it may, accepting their data at face value, they acknowledge that they had the problem that keys had degraded and had to be partially recovered and acknowledged that brute forcing that would be computationally expensive. They used cryptanalysis to recover the lost bits.

To pull this off, they needed several machines.
They needed to cool the memories. Yes, they used propellent to prove they could do it, but the pictures lead me to believe they used a lot more LN.
There are nine names on the paper. Probably all well educated.
They certainly did not pull it off the first time they tried it. I am pretty sure that some times it worked better than others. I don't see any mention of their rate of success -- they only provide the assertion that they had succeeded in attacks.
There are significant portions of the paper that point to how to identify keys in the image.

My point being that an attack that attempts to recover data from DRAM that has been cooled, powered down, moved, powered and imaged -- followed by an analysis of that image, identification of keys and recovery of lost bits requires significant time and (certainly for the analysis of the image) expert knowledge. To pull of the capture of the image might be plausible for someone who has some technical skill given a fair amount of practice. The amount of effort is non-trivial.

The only reasons I can see to invest the time would be to recover data that could be exploited for criminal purposes (bank fraud, identity theft, theft of proprietary data), for criminal prosecution (records of money laundering, child pornography), or national security. A laptop with 10s of thousands of social security numbers or bank credentials might be worth attacking, but a personal machine with one person's (or family's) data is probably not worth the effort. You acknowledge your threat model is fairly low.

I do admit that these sort of attacks are viable. They are just not as easy or inexpensive as one would think. In situations where there are viable threats (credit card processing, for example), keys are kept in static registers with direct clear inputs. The systems have thermal limit detection, incorporate active tamper detection for the security boundary, and are battery powered 24-7. If you are interested, check out the PCI (Payment Card Industry) PTS (PIN Transaction Security) requirements -- https://www.pcisecuritystandards.org/do … _Final.pdf

cynicalpsycho · 2015-05-14 16:35:34

1. I'm not looking to hack systems with PCI/PTS standards. Most systems don't have any sort of thermal limit detection built in (other than those built into bios to prevent overheating - Not over cooling.). And really that's the only place you'd need to worry about any countermeasures/detection (on the firmware level) because you'll be loading your own software to the system anyway, thereby bypassing most security features available to the system. And for the truly dedicated attacker, it wouldn't be that hard (in most cases) to simply swap out the ram, moving the super-cooled loaded ram onto a battery backup, for even longer persistence (this would also bypass any firmware issues)

2. You seem to insist this involves a deep understanding of this stuff. And this may require a little bit of research, but you don't need a PHD to understand what's going on. Not only are such attacks viable. But they're within the grasps of any highly motivated 13 year old kid that wants to learn it let alone the criminals, state actors, investigators, etc.
https://www.youtube.com/watch?v=WoMFFAS0FHM --- great video that explains the simplicity of such an attack.
Even when it comes to dump analysis that too is documented with freely available tools to automate the process all over the net
http://forensic.belkasoft.com/en/live-r … c355258248
https://www.youtube.com/watch?v=iE8b7oESqUE
https://www.youtube.com/watch?v=3gFT2_u_6cI

Last edited by cynicalpsycho (2015-05-14 16:44:00)

ewaller · 2015-05-14 16:49:40

Okay. When you try it, let me know how it works out.

cynicalpsycho · 2015-05-14 16:59:25

ewaller wrote:

Okay. When you try it, let me know how it works out.

Dumping RAM? Analysing it?
I've done it... it works... If done quickly there's minimal loss of data. how long do you think it takes to dump ram?

Arch Linux

#1 2015-05-13 13:02:08

encrypted tmpfs - Running /tmp /var/lock and /var/run in encrypted RAM

#2 2015-05-14 00:18:12

Re: encrypted tmpfs - Running /tmp /var/lock and /var/run in encrypted RAM

#3 2015-05-14 03:41:09

Re: encrypted tmpfs - Running /tmp /var/lock and /var/run in encrypted RAM

#4 2015-05-14 13:33:41

Re: encrypted tmpfs - Running /tmp /var/lock and /var/run in encrypted RAM

#5 2015-05-14 15:40:02

Re: encrypted tmpfs - Running /tmp /var/lock and /var/run in encrypted RAM

#6 2015-05-14 16:35:34

Re: encrypted tmpfs - Running /tmp /var/lock and /var/run in encrypted RAM

#7 2015-05-14 16:49:40

Re: encrypted tmpfs - Running /tmp /var/lock and /var/run in encrypted RAM

#8 2015-05-14 16:59:25

Re: encrypted tmpfs - Running /tmp /var/lock and /var/run in encrypted RAM

Board footer