Gentoo Forums
Gentoo Forums
Gentoo Forums
Quick Search: in
Can I have encrypted, compressed IN-RAM-SWAP or RAM-DISK?
View unanswered posts
View posts from last 24 hours

 
Reply to topic    Gentoo Forums Forum Index Kernel & Hardware
View previous topic :: View next topic  
Author Message
as.gentoo
Guru
Guru


Joined: 07 Aug 2004
Posts: 318

PostPosted: Sun Dec 24, 2017 10:18 pm    Post subject: Can I have encrypted, compressed IN-RAM-SWAP or RAM-DISK? Reply with quote

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
Back to top
View user's profile Send private message
szatox
Veteran
Veteran


Joined: 27 Aug 2013
Posts: 1751

PostPosted: Sun Dec 24, 2017 10:46 pm    Post subject: Reply with quote

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?
Back to top
View user's profile Send private message
as.gentoo
Guru
Guru


Joined: 07 Aug 2004
Posts: 318

PostPosted: Sun Dec 24, 2017 10:54 pm    Post subject: Reply with quote

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
Back to top
View user's profile Send private message
tholin
Apprentice
Apprentice


Joined: 04 Oct 2008
Posts: 170

PostPosted: Mon Dec 25, 2017 11:15 am    Post subject: Reply with quote

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
Back to top
View user's profile Send private message
NeddySeagoon
Administrator
Administrator


Joined: 05 Jul 2003
Posts: 43383
Location: 56N 3W

PostPosted: Mon Dec 25, 2017 11:32 am    Post subject: Reply with quote

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.
_________________
Regards,

NeddySeagoon

Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail.
Back to top
View user's profile Send private message
as.gentoo
Guru
Guru


Joined: 07 Aug 2004
Posts: 318

PostPosted: Mon Dec 25, 2017 1:11 pm    Post subject: Reply with quote

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. ;)

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
Back to top
View user's profile Send private message
as.gentoo
Guru
Guru


Joined: 07 Aug 2004
Posts: 318

PostPosted: Sun Dec 31, 2017 5:07 am    Post subject: Reply with quote

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.
Back to top
View user's profile Send private message
lagalopex
Guru
Guru


Joined: 16 Oct 2004
Posts: 545

PostPosted: Sun Dec 31, 2017 8:50 am    Post subject: Reply with quote

AMD added hardware encrypted ram extension to zen:
Wiki: Zen
_________________
System: AMD FX 8350, 16GB RAM, NVidia GeForce GTX 750 Ti, Asus M5A99X EVO R2.0
Back to top
View user's profile Send private message
NeddySeagoon
Administrator
Administrator


Joined: 05 Jul 2003
Posts: 43383
Location: 56N 3W

PostPosted: Sun Dec 31, 2017 11:08 am    Post subject: Reply with quote

as.gentoo,

Yes, some RAM is overwritten by the reboot.

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

NeddySeagoon

Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail.
Back to top
View user's profile Send private message
Display posts from previous:   
Reply to topic    Gentoo Forums Forum Index Kernel & Hardware All times are GMT
Page 1 of 1

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum