# Can I have encrypted, compressed IN-RAM-SWAP or RAM-DISK?

## as.gentoo

Not sure if it is possible…

So there is TMPFS which provides a RAM-DISK (e.g. hosting /tmp) but there is no compression neither encryption.

ZRAM and ZSWAP do store compressed data in RAM but supply no encryption. You can not stack them on top of a dm-crypt device because they access RAM directly.

I probably could create something like EXT2 @ DM-CRYPT @ ZRAM, however the encrypted data will not compress at all.

For the RAM-DISK, I might create a "normal" SWAP device ontop of LZ4-compressing ZVOL in a (ZFS) ZPOOL that uses an encrypted ZRAM(-device). 

-> SWAP @ ZVOL (compression) @ ZPOOL @ (2x) DM-CRYPT @ (2x) ZRAM device

However, that's not only a very fragile construction but AFAIK you can not create a ZPOOL with only one device - so the compression does instantly becomes futile, too. It also means that encryption would be done twice. Plus, ZRAM would execute compression although it would make no sense since (the already compressed) encrypted data should not be compressible. Maybe there is another way to have a RAM-device.

Am I missing something here?

I think something like TMPFS w/ compression and encryption and ZSWAP w/ encryption would be the best because both grow or shrink with the amount of held data. I wonder why TMPFS doesn't offer compression. Wouldn't RAM + LZ4 (de)compression always be much faster than r/w on SSD or HDD?

EDIT: Resize and encrypted may work well…Last edited by as.gentoo on Mon Dec 25, 2017 3:16 am; edited 1 time in total

----------

## szatox

You miss the fact, that the data in RAM in general is not encrypted.

I can see some reasons to use ZRAM, and I can see reasons to encrypt SWAP.

I do not see any reason to encrypt ZRAM though. What problem are you trying to solve?

----------

## as.gentoo

 *szatox wrote:*   

> You miss the fact, that the data in RAM in general is not encrypted.
> 
> I can see some reasons to use ZRAM, and I can see reasons to encrypt SWAP.

 Well, yes data in RAM is not encrypted.

But you could create a ZSWAP almost as big as your RAM and have (almost) everything encrypted because the data in RAM is forced to be swapped out to the - if possible encrypted - ZSWAP. Encryption could make sense here, if this would not slow down everything too much which depends how bad encryption is needed… 

However, that's not what I'm trying to figure out.

 *szatox wrote:*   

> I do not see any reason to encrypt ZRAM though.
> 
> What problem are you trying to solve?

 There is no real problem here but I'll set up a notebook and a workstation - and I'd like to know how far I can push security. 

Having an encrypted (Z)RAM-DISK for /tmp or cache data (/var/cache as well as ~/.cache …) would make sense, IMO. I bet there is data cached that could reveal quite a lot.

CORRECTION:

You can create a zpool having only one (v)device.Last edited by as.gentoo on Mon Dec 25, 2017 3:13 am; edited 1 time in total

----------

## tholin

 *as.gentoo wrote:*   

> Well, yes data in RAM is not encrypted.
> 
> But you could create a ZSWAP almost as big as your RAM and have (almost) everything encrypted because the data in RAM is forced to be swapped out to the - if possible encrypted - ZSWAP. Encryption could make sense here

 Are you trying to defend against cold boot attacks?

In this encrypted swap in ram setup the kernel would need to have the symmetric key for encryption and decryption or else it couldn't read and write to the swap. This key is stored in ram so you'd have encrypted data in ram and the key needed for decryption also in ram. That protects against nothing.

To encrypt ram properly the key can't be stored in ram. There are some hardware based solutions for this.

https://en.wikichip.org/wiki/x86/tme

----------

## NeddySeagoon

as.gentoo,

Please describe the threat(s) you want to defend against.

When your system is running, the crypto keys are in RAM.

I can steal them by rebooting with a USB key and making an image of RAM.

You might never know.  RAM is not cleared by either a shutdown or reboot.

When your system is off and the RAM data decayed, which takes several minutes, you keys are safe.  

However, this several minutes RAM decay time opens up another attack.

Given physical access to your running system, I can power it down, pull the RAM an image it in another device.

Run time encryption, with keys in RAM does nothing.

----------

## as.gentoo

Okay, looks like I didn't think this through.

Encrypted SWAP is needed for hardware that keeps data after power-off … SSD and HDD and maybe RAM that has its own refresh-power supply (battery). Encryption would prevent that swapped RAM content can be read after the "cold-boot timeout".

I see now, why RAM-encryption wouldn't help against a cold boot attack. Thanks for pointing that out!

Do you have knowledge or even experience regarding TRESOR?

 *NeddySeagoon wrote:*   

> I can steal them by rebooting with a USB key and making an image of RAM.

 Out of curiosity, how would I do that? Something like dd if=/dev/mem of=/dev/<SSD> ? I guess it's a bit more complicated because booting from a stick would per se overwrite some RAM, right?

This sounds like I could rescue data in RAM when the system crashed/deadlocked by storing it to a drive, I just have to be fast enough?

While we're at it, why haven't RAM manufacturers come up with a technology to fight data remanence successfully, really clearing RAM within a second - better less - right before power-off? 

A non-destructive overload maybe? In the best of cases by command like echo 1 > /sys/…/ram_zero_out instructing the hardware side to take action?

How about overwriting RAM as the last step of shutdown with zeroes on the software side (kernel)? And as above a command to start that instantly by echoing to /sys/…

In the threat described below destruction might even be desired in case remenance could only be fought by physical damage (heavy overload, short-circuit, high temperature…). Please show mercy, I'm no technician.  :Wink: 

The threats would be the "loss" of the notebook (theft, impoundment…) or having to cut power off - in order to protect your sources if I would be an investigative journalist - at the moment your front door is knocked in. Scenarios:

a) the system in S4 power state (suspend to drive) - hibernate-SWAP and other drive based SWAP encryption makes sense, preconditioned that a cold boot attack is not possible anymore. AFAIK that can be achieved.

b) cold boot attack - either in suspend to RAM or reboot/shutdown/cut-power.

 *tholln wrote:*   

> To encrypt ram properly the key can't be stored in ram. There are some hardware based solutions for this.
> 
> https://en.wikichip.org/wiki/x86/tme

 

You already gave me this hint for case (b). Anyhow, the used CPUs do not support TME.

You already gave pointers to TME but

----------

## as.gentoo

 *as.gentoo wrote:*   

> Do you have knowledge or even experience regarding TRESOR?

 

Oh, and there is cryptkeeper @ IEEE / cryptkeeper PDF

Not implemented AFAIK but interesting.

----------

## lagalopex

AMD added hardware encrypted ram extension to zen:

Wiki: Zen

----------

## NeddySeagoon

as.gentoo,

Yes, some RAM is overwritten by the reboot.

https://www.scribd.com/doc/130070110/Extracting-Encryption-keys-from-RAM

----------

