Conversation

As impressive and scary as tjis sounds, it's a complete non-threat with proper use of FDE and IOMMU.

Quote Tweet

Oct 5, 2020

One of my first ever hardware projects was making malware that installs itself inside the hard drive (not on the disk, but inside the hard drive firmware). Even if you reformatted the entire computer, the malware would just write itself back.

Show this thread

Replying to

In theory, but in practice disk encryption rarely provides authenticated encryption and doesn't protect against an attacker able to modify the encrypted data. It is possible to do it though. Code that handles bootstrapping also needs to be verified of course.

Replying to

and

i.e. can't just be using AES-XTS, need to be using something like AES-GCM and in a way that avoids trusting the storage. kernel.org/doc/html/lates has a quite high performance cost and it's not really doing much more than defending against precisely this threat (compromised SSD).

Replying to

and

fscrypt is supposed to be providing efficient AEAD cipher support at some point. I'm not sure if fscrypt is actually entirely upstream though since source.android.com/security/encry doesn't seem to be supported upstream rather than layering it on dm-crypt like source.android.com/security/encry.

source.android.com

Metadata Encryption | Android Open Source Project

8:21 PM · Oct 5, 2020Twitter Web App

Replying to

Not interested in anything that mixes up layers for the performance lulz. FDE belongs entirely at the block layer not as part of the fs.

Replying to

Filesystem-based encryption primarily exists to provide finer-grained encryption such as per-user/per-workspace encryption keys which become at rest when logged out. It's possible to use it as a form for FDE with only a boot password, but that would be missing the point of it.

Show replies