From owner-freebsd-questions@freebsd.org Mon Feb 24 16:21:28 2020 Return-Path: Delivered-To: freebsd-questions@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 5B0C4239D9E for ; Mon, 24 Feb 2020 16:21:28 +0000 (UTC) (envelope-from galtsev@kicp.uchicago.edu) Received: from kicp.uchicago.edu (kicp.uchicago.edu [128.135.20.70]) by mx1.freebsd.org (Postfix) with ESMTP id 48R6kv04qYz4MH9 for ; Mon, 24 Feb 2020 16:21:26 +0000 (UTC) (envelope-from galtsev@kicp.uchicago.edu) Received: from point.uchicago.edu (point.uchicago.edu [128.135.52.6]) (Authenticated sender: galtsev) by kicp.uchicago.edu (Postfix) with ESMTPSA id 01A944E67C for ; Mon, 24 Feb 2020 10:21:26 -0600 (CST) Subject: Re: rm | Cleaning up recycle bin To: freebsd-questions@freebsd.org References: <20200223184908.b35d656a.freebsd@edvax.de> <20200224145317.GA9130@neutralgood.org> <20200224151337.30d8d819e7cf74bde984b77a@sohara.org> <20200224110621.3267115d@scorpio> <20200224161525.GB9130@neutralgood.org> From: Valeri Galtsev Message-ID: <1152c135-28bf-24a9-2987-14ec04711323@kicp.uchicago.edu> Date: Mon, 24 Feb 2020 10:21:25 -0600 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:68.0) Gecko/20100101 Thunderbird/68.4.1 MIME-Version: 1.0 In-Reply-To: <20200224161525.GB9130@neutralgood.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 48R6kv04qYz4MH9 X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=fail reason="No valid SPF, No valid DKIM" header.from=uchicago.edu (policy=none); spf=none (mx1.freebsd.org: domain of galtsev@kicp.uchicago.edu has no SPF policy when checking 128.135.20.70) smtp.mailfrom=galtsev@kicp.uchicago.edu X-Spamd-Result: default: False [-1.61 / 15.00]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; DMARC_POLICY_SOFTFAIL(0.10)[uchicago.edu : No valid SPF, No valid DKIM,none]; NEURAL_HAM_MEDIUM(-0.82)[-0.822,0]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-1.00)[-0.999,0]; MIME_GOOD(-0.10)[text/plain]; TO_DN_NONE(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-questions@freebsd.org]; RCPT_COUNT_ONE(0.00)[1]; IP_SCORE(0.12)[ip: (0.33), ipnet: 128.135.0.0/16(0.16), asn: 160(0.13), country: US(-0.05)]; RCVD_IN_DNSWL_NONE(0.00)[70.20.135.128.list.dnswl.org : 127.0.10.0]; R_SPF_NA(0.00)[]; RCVD_NO_TLS_LAST(0.10)[]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:160, ipnet:128.135.0.0/16, country:US]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_COUNT_TWO(0.00)[2] X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Feb 2020 16:21:28 -0000 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 ++++++++++++++++++++++++++++++++++++++++