[coppsilgold]

I would not recommend that one trust a secure enclave with full disk encryption (FDE). This is what you are doing when your password/PIN/fingerprint can't contain sufficient entropy to derive a secure encryption key.

The problem with low entropy security measures arises due to the fact that this low entropy is used to instruct the secure enclave (TEE) to release/use the actual high entropy key. So the key must be stored physically (eg. as voltage levels) somewhere in the device.

It's a similar story when the device is locked, on most computers the RAM isn't even encrypted so a locked computer is no major obstacle to an adversary. On devices where RAM is encrypted the encryption key is also stored somewhere - if only while the device is powered on.

[pregnenolone]

RAM encryption doesn’t prevent DMA attacks and perofming a DMA attack is quite trivial as long as the machine is running. Secure enclaves do prevent those and they're a good solution. If implemented correctly, they have no downsides. I'm not referring to TPMs due to their inherent flaws; I’m talking about SoC crypto engines like those found in Apple’s M series or Intel's latest Panther Lake lineup. They prevent DMA attacks and side-channel vulnerabilities. True, I wouldn’t trust any secure enclave never to be breached – that’s an impossible promise to make even though it would require a nation-state level attack – but even this concern can be easily addressed by making the final encryption key depend on both software key derivation and the secret stored within the enclave.

[QuiEgo]

I recommend reading the AES-XTS spec, in particular the “tweak”. Or for AES-GCM look at how IV works.

I also recommend looking up PUF and how modern systems use it in conjunction with user provided secrets to dervie keys - a password or fingerprint is one of many inputs into a kdf to get the final keys.

The high level idea is that the key that's being used for encryption is derived from a very well randomized and protected device-unique secret setup at manufacturing time. Your password/fingerprint/whatever are just adding a little extra entropy to that already cryptographically sound seed.

Tl;dr this is a well solved problem on modern security designs.

[coppsilgold]

> I recommend reading the AES-XTS spec, in particular the “tweak”. Or for AES-GCM look at how IV works.

What does this have to with anything? Tweakable block ciphers or XTS which converts a block cipher to be tweakable operate with an actualized key - the entropy has long been turned into a key.

> Your password/fingerprint/whatever are just adding a little extra entropy to that already cryptographically sound seed.

Correct. The "cryptographically sound seed" however is stored inside the secure enclave for anyone with the capability to extract. Which is the issue I referenced.

And if what you add to the KDF is just a minuscule amount of entropy you may as well have added nothing at all - they perform the addition for the subset of users that actually use high entropy passwords and because it can't hurt. I don't think anyone adds fingerprint entropy though.