Date: Mon, 24 Feb 2020 10:21:25 -0600 From: Valeri Galtsev <galtsev@kicp.uchicago.edu> To: freebsd-questions@freebsd.org Subject: Re: rm | Cleaning up recycle bin Message-ID: <1152c135-28bf-24a9-2987-14ec04711323@kicp.uchicago.edu> In-Reply-To: <20200224161525.GB9130@neutralgood.org> References: <a589bf69-a53b-a732-08ff-74e09b723bbd@cloudzeeland.nl> <20200223184908.b35d656a.freebsd@edvax.de> <20200224145317.GA9130@neutralgood.org> <20200224151337.30d8d819e7cf74bde984b77a@sohara.org> <e3a6e679-2fe7-c79d-7a75-f1ffa6460f00@kicp.uchicago.edu> <20200224110621.3267115d@scorpio> <20200224161525.GB9130@neutralgood.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On 2020-02-24 10:15, Kevin P. Neal wrote: > On Mon, Feb 24, 2020 at 11:06:21AM -0500, Jerry wrote: >> On Mon, 24 Feb 2020 09:38:46 -0600, Valeri Galtsev stated: >>> It depends on what kind of attack you are trying to defend from. If it >>> is theft of your hard drive from your cold powered off machine, then >>> this will help (not 100% solve it, just brute force drive decryption >>> attack is too expensive or slow). If, however, it is physical machine >>> security that you are trying to solve, encrypting drive not >>> necessarily will help. The following is the speculation about how the >>> attack can be performed. Bad guy has physical access to your machine >>> when it is up and running. He opens the case, splashes liquid nitrogen >>> onto your RAM, pulls RAM modules, plugs them into his device. Low >>> temperature ensures the content of RAM is not lost while physically >>> swapping it over to bad guy's device, and that device ensures the >>> content of RAM is not lost (pretty much the same way as dynamic RAM is >>> used always). And the guy takes the hard drive. Encryption/decryption >>> happens on the fly on running machine (otherwise yanking the power >>> will allow on to have decrypted drive), and therefore the >>> encryption/decryption key(s) must me somewhere in the RAM when machine >>> runs. And the bad guy has it all now: the whole content of the RAM >>> (with the keys), and [encrypted] hard drive. He has your information. >> >> Can you document an actual event when this scenario occurred? > > Freezing RAM and then recovering the data is an attack that became public > a few years ago (maybe five? I don't think ten?). > That sounds right. It's been quite some time since I've first heard about that. I remember my first reaction: YES, it's pure physics, how come I didn't think about that myself... (I guess, I didn't have the need of doing it - that might be my excuse then). Valeri -- ++++++++++++++++++++++++++++++++++++++++ Valeri Galtsev Sr System Administrator Department of Astronomy and Astrophysics Kavli Institute for Cosmological Physics University of Chicago Phone: 773-702-4247 ++++++++++++++++++++++++++++++++++++++++
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1152c135-28bf-24a9-2987-14ec04711323>