Lol, I dont know if I can even make software…lol. But I think a CAC or USB lock might be fun to use. I also forget my passwords lol.
1 Like
I think @regulareel ’s suggestion of a Yuubikey might be a better solution, all told, and I like the idea of a data store being separately locked to the OS.
1 Like
I hadn’t hear of that till now. Seems like a good option. Like I said I’m sure it’s overkill but I’m still OPSEC minded.
Nothing drove me more crazy than people posting pictures on Facebook when we were overseas… it was crazy! Could get a whole layout of our little FOB. GRRRRRRRFF
1 Like
Using one of those pet RFID tags the vet embeds in a dogs neck would be amusing, as 2FA not the entire way to unlock the device. To Prince Albert or not, that is the question 
1 Like
Sadly, they only have to accuse you of something. There was a federal court ruling (US only) that you cannot communicate a passphrase; it violates your Miranda rights (perhaps it was overturned?) . However, they can force you to give up any other means of unlocking the phone or device.
rant deleted.
2 Likes
Feel free to rant…I do
1 Like
Linux biometrics suggestion…my suggestion is don’t use biometrics.
But I know that isn’t what you’re looking for. I would echo the above in that sure you could use biometric data to encrypt data but the heuristics of biometrics will by its nature greatly reduce security. Biometrics as a 2 factor? maybe? You can’t really leave a fingerprint at home accidentally like you could a yubikey…
2 Likes
Hmm. Especially for a phone that could be clever: combined fingerprint, RFID, and password required for unlock, but with limited UI feedback about what is failing.
With an RFID ring, glove, or implanted capsule between thumb and index finger, it would just look like a normal fingerprint unlock, and anyone trying to fool the fingerprint scanner would assume that his/her finger forgery was wrong without suspecting that there is a missing third or second factor.
General biometric usage commentary
I think the proper design of biometrics tends to be as a way to unlock a cached login, rather than as a full replacement for the password itself.
On iOS/macOS, the system (for the most part) treats TouchID/FaceID as more of a convenience measure: fail the biometric check a few times, and the device password is required again; reboot the device, real password is again needed.
It acts like a half-locked state, which only exists for a few attempts:
- powered off → fully locked
- password entered → unlocked
- locked with biometric → half locked
- failed biometric → fully locked again
As I understand, Apple does this by storing whatever keys/credentials are needed to unlock the device inside a “secure” sub-processor (Secure Element on ARM, discrete T2 chip on x86). Then after n failed attempts, it clears the keys from its internal RAM.
I share your curiosity, but my guess is that the secure processor needs to do the comparison of input face/fingerprint to the actual reference data. I am having difficulty imagining a reliable way one could calculate enough bits from a biometric input that would be both stable and unique enough to use a decryption key. As mentioned above:
Even if the face/fingerprint reference is stored as set of properties (Ex: relative distances between facial features, whorl v. arch v. loop) rather than a reference picture, I cannot imagine this being anywhere close to as secure from reversibility as a securely hashed password.
Therefore, I would only consider it safe if the secure processor is storing biometric reference material encrypted so that only it can decrypt it.
Possible ideas for secure-processor storage
If you assume constant power, you can have the secure processor randomly generate an encryption key when it is first powered on, and keep that in its internal RAM for the entire life of the product. Cable boxes are known to use sort of design.
Maybe a variant of this could be to have a set of efuses that are blown to permanently store a key at first power-on.
Both of these methods would let the device use encryption on off-chip storage so that even the manufacturer would have no advantage in attempting to decrypt any data. Of course, with limitless funding, one could attempt to physically and destructively examine the chip to check efuses, but you likely only have one risky shot at it.
Edit: To be clear, I do not know how Apple is implementing its TouchID/FaceID reference material storage, but the above was merely is my idea of an ideal system.
On Windows, Hello functionality appears to rely on a TPM, but TPM chips have a reputation for limited data throughput, which makes me wonder how much if the biometric processing is actually done inside the TPM.
1 Like
This topic was automatically closed 273 days after the last reply. New replies are no longer allowed.