Trust dies in darkness: Shedding light on Samsung’s TrustZone Keymaster design [pdf]
eprint.iacr.org
eprint.iacr.org
Now: Nice. I wonder what kind of DRM/Anti-user feature will this break. I hope it never gets patched.
DRM is just one application.
As a password replacement, whole concept rubs me the wrong way though. Just let me make a god damn backup. "just buy 2 tokens lol" is such a shitty solution.
I strongly prefer STANDARDIZED totp.
Apple is even explicitly planning to offer something like this for their platform authenticator implementation on iOS and macOS, although I'm not sure it's been finalized whether and how that fact will be exposed to applications.
I'm not sure either is a good idea though, to be honest: The line between enabling credential/authenticator backups and enabling "credential skimming" is very fine.
As is their right, no? Hopefully (and heavily depending on jurisdiction), service providers will be liable for any fraud happening on their platform, which I believe is only justifiable if service providers are also allowed to take some reasonable fraud prevention measures.
I'll take the requirement for an uncloneable WebAuthN authenticator over privacy-invasive fingerprinting (via location, device sensors etc.) and pointless security theater any day, which seems to be the status quo for many services. (For example, my bank has a habit of locking my account and having me call them about 3 out of 4 times I transfer money between my own checking and savings account.)
As for behavior analysis for fraud detection: that isn't going anywhere any time soon, no matter if our tokens are clonable or not. And clearly the system your bank is using is dumb as nails, so I doubt there's a privacy issue there.
The dodgy issue was that counters on slow low power card based secure elements were designed to depend on tamper proof hardware and had a small moving window, whereas in software, I'd speculate they needed something like GCM to maintain protocol backward compatability with some additional assurance in software. Modern protocols would just use ECC with a totally different protocol, but to maintain compatability for payments and global platform, you needed a symmetric protocol, and GCM was the best they could do.
It's vindicating because when I worked on a related TZ problem almost 10y ago, the authors of this paper were the precise threat actor I proposed in the design discussions.
Do you mean something with initialization vector reuse resistance? Because that seems to be the problem here...
In linguistics, the term "nonce word" describes a term invented for a specific occasion/purpose where you have a need for a term that isn't met by existing language: https://en.m.wikipedia.org/wiki/Nonce_word
So the cryptographic term "nonce" was a reference to the existing linguistic terminology, which IIRC goes back pretty far, maybe into Old English.
I don't know exactly when/how the "number once" thing came about, but it's definitely become a valid definition in its own right... And a very useful mnemonic, as you pointed out.
They are not built for the consumer anyway, but through subsidies of a misguided copyright industry seeking to inflict DRM.
And additionally, interesting that the authors were able to conduct this research. IIRC, on Samsung devices rooting requires blowing the "Knox" fuse as part of the process, which should have bricked the TrustZone part.
Essentially, each device gets a basic provisioning key at manufacture that authenticates/attests it back to the OEM, and then it gets "personalized" with a set of new keys unique to the device, derived from either that provisioning key, or secrets at the OEM's HSM.
The stream cipher that they broke using the IV weakness would plausibly have used these personalization keys (post provisioning/manufacturing), and not ones protected by a fuse from manufacture.
Again, speculative based on design principles, but there's a short list of ways this stuff works.
Like with all such platforms, it can be used for good and evil (from the device owner's perspective), and its aptitude for enabling hard-to-detect backdoors or spyware depends entirely on how powerful the interfaces to the main user computing platform are.
https://en.wikipedia.org/wiki/Next-Generation_Secure_Computi...
From what I gather the specific exploits have already been patched, but the underlying message here is that designing 'in the dark' without sharing implementation code in order for the wider industry to audit results in insecurity, and there may be more exploit opportunities lingering?