<div dir="ltr"><div dir="ltr"><div class="gmail_default" style="font-family:monospace,monospace">On Sat, Apr 10, 2021 at 5:10 PM Rick Smith <<a href="mailto:me@cys.me">me@cys.me</a>> wrote:<br></div></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Regarding disk encryption and access control, Bear notes:<br>
<br>
> While the system is running, the disk is mounted, the process of<br>
> encrypting or decrypting is abstracted away, and every bit of malware<br>
> that works on unencrypted systems works just fine on encrypted systems.<br>
> Basically the encryption provides no protection beyond the first login<br>
> where the disk is mounted. .....<br>
<br>
Truth.<br>
</blockquote><div><br></div><div style="font-family:monospace,monospace" class="gmail_default">I think what people seem to be missing here is "what is the threat model" for all of this FDE?</div><div style="font-family:monospace,monospace" class="gmail_default"><br></div><div style="font-family:monospace,monospace" class="gmail_default">The main purpose of FDE is--and as far as I know, always has been--to protect "smash-and-grab" attacks, where for instance a crook is walking past a locked parked car, sees a laptop on the back see, smashes the window and grabs the laptop and runs off with it. (It provides similar protection if your laptop is powered down and you simply lost it.) If it's advertised as anything more than this, chances are, it's just hype.<br></div><div style="font-family:monospace,monospace" class="gmail_default"><br></div><div style="font-family:monospace,monospace" class="gmail_default">Businesses who issued company laptops to their employees were the ones who pushed to get FDE deployed because there were way too many news stories popping up of stolen or lost company laptops where the employee may have had thousands or millions of consumer records containing PII on them and this was one way to address that liability. (And more effective than telling the employee "not to do that", especially when that employee was a C-level executive.)<br></div><div style="font-family:monospace,monospace" class="gmail_default"><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
> Disk encryption that actually provides the protections people think disk<br>
> encryption provides would require a whole new filesystem type, a whole<br>
> new OS mostly organized around key management, ....<br></blockquote><div><br></div><div style="font-family:monospace,monospace" class="gmail_default">Rather than FDE, Linux (and probably other OSes as well) offer encryption at the file system or even at the home directory (i.e., per user) level, the latter which is usually decrypted from a key partially derived from (or at least tied to) the user's password. While I've never tested it, I suppose one could perhaps tie this to autofs / automount so those directories get unmounted after some period of inactivity. The keys would of course have to be flushed / scrubbed as well. Not perfect, but it is probably better than the default FDE behavior. I think that ecryptfs can already be set up that way, but I've never used anything but the default because all I really care about is the 'smash-and-grab' attack vector and the defaults seem adequate for that.<br></div><div style="font-family:monospace,monospace" class="gmail_default"><br></div><div style="font-family:monospace,monospace" class="gmail_default">-kevin<br></div></div>-- <br><div dir="ltr" class="gmail_signature"><div dir="ltr"><div>Blog: <a href="https://off-the-wall-security.blogspot.com/" target="_blank">https://off-the-wall-security.blogspot.com/</a>    | Twitter: @KevinWWall | OWASP ESAPI Project co-lead<br>NSA: All your crypto bit are belong to us.</div></div></div></div>