On 06/12/15 01:09, ertetlen barmok wrote: > Any luck with this? no luck at all, since your patch to make it happen wasn't attached to the email, and thus, never should have been sent to tech@.
Personally, it looks like a highly invasive change (which also means almost certain to introduce OTHER security bugs!) for reducing ONE physical security risk. And, I'd hardly call it the major physical security risk. For the OP: https://xkcd.com/538/ Most of you probably know exactly what that is, no reason to click on it. :) If your data is "important", physical security is important. Your proposed task-for-others doesn't change this. Doesn't solve key loggers, doesn't solve smart hw monitoring the server, doesn't prevent rubber hose decryption, etc. Nick. > -------- Original Message -------- > From: "ertetlen barmok" <ertetlenbar...@safe-mail.net> > Apparently from: owner-tech+m42...@openbsd.org > To: tech@openbsd.org > Subject: RAM encryption and key storing in CPU > Date: Sat, 23 May 2015 05:15:47 -0400 > >> Hello, >> >> ========== >> Problem: >> >> Everything is stored in plaintext in the Memory. >> >> So if although full disc encryption is used on an OpenBSD machine, it is >> possible to copy the content of the memory, while the notebook was on >> suspend or it was running: >> >> https://citp.princeton.edu/research/memory/media/ >> >> ========== >> Solution: >> >> Can we (optionally*) encrypt the content of the memory and store the key for >> decryption in the CPU to avoid in general these kind of attacks? >> >> There are solutions for this on Linux already, but only on patch level: >> >> https://www1.informatik.uni-erlangen.de/tresor >> >> *if someone would want to harden it's OpenBSD (since notebooks could be >> stolen..) it could turn on this feature to avoid a policy to always turn off >> the notebook while not using it. >> >> Thank you for your comments. >
