5 ms·
> And that's the difference. When you perform TouchID authentication, the secure enclave can decide to release a secret that can be used to decrypt your keyring
by baybal2 3y ago
> And that's the difference. When you perform TouchID authentication, the secure enclave can decide to release a secret that can be used to decrypt your keyring. We can't easily do this under Linux because we don't have an interface to store those secrets.
> The secret material can't just be stored on disk - that would allow anyone who had access to the disk to use that material to decrypt the keyring and get access to the passwords, defeating the object.
I'll provide a broader explanation: you cannot encrypt your key with a fingerprint.
A genuine "throw away the key" lock is only possible when the decryption key is completely erased from memory during the screen lock, and you cannot use your fingerprint or face image as a key by itself.
A screen lock using stored secret is inherently incapable of providing encryption at rest. It's like a password on a sticky note.
A "throw away the key" is only possible with a password, or a smartcard.
- parker_mountain 3y agoI'm not sure if you're familiar with how Touch ID and the secure enclave works?
- mjg59 3y agoIf you trust the hardware then it's entirely possible to tie the release of an encryption key to a fingerprint validated by that hardware. Hardware-backed keys are widely used (the entire WebAuthn ecosystem is predicated upon them being trustworthy), and having that hardware validate a fingerprint rather than merely physical presence is an improvement.
- RockRobotRock 3y agoAs far as physical attacks go, we only trust secure elements because they're tiny and very difficult to reverse engineer, right?
- mjg59 3y agoIn theory you could potentially decap the enclave and read data out of it but you would need extremely high end equipment to do that and it would be obviously destructive so it's not in most people's threat model
- g_p 3y agoPartly that, and partly because they were/are built with constrained functionality (do one thing well) that significantly limits the interfaces exposed, and are designed to be secure under the assumption of physical attack (which most things aren't!) Partly because many secure enclave type applications have undergone formal verification and verification through something like CC EAL, which should reduce the likelihood of glaring oversights etc. One final aspect, more for hardware enclaves though, is that they're often designed specifically to resist the kinds of physical attacks people may try - as security products, they've very likely considered power rail glitching and how to reset the enclave if there's a glitch. Similarly, the physical ICs may be produced with physical features to try to prevent successfully decapping the chip, like sensing wires you'll disrupt, and inbuilt EM shielding.
- baybal2 3y ago[dead]
- westurner 3y agohttps://news.ycombinator.com/item?id=33311523 https://news.ycombinator.com/item?id=33311523 : > [WebAuthn, TPM, U2F/FIDO2, Seahorse,] > tpm-fido: https://github.com/psanford/tpm-fido https://github.com/psanford/tpm-fido : >> tpm-fido is FIDO token implementation for Linux that protects the token keys by using your system's TPM. tpm-fido uses Linux's uhid facility to emulate a USB HID device so that it is properly detected by browsers. TPM > TPM software libraries: https://en.wikipedia.org/wiki/Trusted_Platform_Module#TPM_software_libraries https://en.wikipedia.org/wiki/Trusted_Platform_Module#TPM_so... TPM > Virtualization; virtual TPM devices: https://en.wikipedia.org/wiki/Trusted_Platform_Module#Virtualization https://en.wikipedia.org/wiki/Trusted_Platform_Module#Virtua... WebAuthn: https://en.wikipedia.org/wiki/WebAuthn https://en.wikipedia.org/wiki/WebAuthn