Date: Mon, 24 Feb 2020 11:06:21 -0500 From: Jerry <jerry@seibercom.net> To: freebsd-questions@freebsd.org Subject: Re: rm | Cleaning up recycle bin Message-ID: <20200224110621.3267115d@scorpio> In-Reply-To: <e3a6e679-2fe7-c79d-7a75-f1ffa6460f00@kicp.uchicago.edu> 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>
next in thread | previous in thread | raw e-mail | index | archive | help
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? -- Jerry
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20200224110621.3267115d>