5 ms·

Trust dies in darkness: Shedding light on Samsung’s TrustZone Keymaster design [pdf]

165 points by zdw 5y ago

no_time 5y ago
~10 years ago: How horrible. Sad to see such security holes being found in our devices. Now: Nice. I wonder what kind of DRM/Anti-user feature will this break. I hope it never gets patched.
- lxgr 5y ago
  Would you consider WebAuthN platform credentials and securing payment credentials "anti-user"? DRM is just one application.
  - no_time 5y ago
    No. That's the least bad use case out of the bunch. If it stays as an option and/or the issuing organization provides the token, it's a benefit. 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.
    - lxgr 5y ago
      As far as I'm aware, there's nothing in either the WebAuthN or the FIDO/CTAP specifications forbidding back-up-able (i.e. clonable) credentials. 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.
      - franga2000 5y ago
        WebAuthN is designed to let the site limit what kind of tokens you're allowed to use. It doesn't matter that clonable tokens exist if every site only allows unclonable ones. We're currently in the same boat with rooted Android devices - we have the freedom, but if we want to use anything from bank apps to scooter rentals, we aren't allowed to exercise that freedom.
        lxgr 5y ago
        > WebAuthN is designed to let the site limit what kind of tokens you're allowed to use. 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.)
        franga2000 5y ago
        No! If I get my token stolen or cloned, that's my problem. When have you seen a service provider held liable for what someone did with credentials that were stolen from a customer. If someone steals my bank card and uses it to buy stuff, the bank isn't going to be liable for that, so why would it be any different for 2FA tokens? 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.
  - Schroedingersat 5y ago
    Yes. If it means access to commerce or banking services requires submitting control of your phone to a third party.
    - lxgr 5y ago
      As long as it's a well-defined, sandboxed component of my phone, this seems like a much better tradeoff than behavioral fingerprinting that just gobbles up as much sensor data as it can get its hands on (while still not completely preventing moderately sophisticated spoofing attacks).
api 5y ago
This was obviously built by someone lacking even a basic understanding of how to use cryptographic primitives. It's not that hard to use an AEAD cipher construction properly. Nonce stands for number used once.
- JCWasmx86 5y ago
  It is good for the freedom of the user, that the user it is able to access everything in the TrustZone.
- SkittyDog 5y ago
  Interesting thing about the term "nonce"... that etymology is not entirely accurate. It's not quite a false etymology, but it is a sort of a "backronym" kinda thing. 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 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.
danuker 5y ago
Cute title! Security through obscurity falls apart when brought to the spotlight. Which is why I don't trust platforms mentioning "Trust". They are not built for the consumer anyway, but through subsidies of a misguided copyright industry seeking to inflict DRM.
- jimmySixDOF 5y ago
  Just so you know, the title is a play on "Democracy Dies in Darkness" which is the Washington Post newspaper's motto
  - unixbane 5y ago
    which both get ignored by means of the hyperbole filter
    - jessaustin 5y ago
      It's more of a mission statement than a motto, anyway.
      - unixbane 5y ago
        well all news media is pro state and anti freedom so...
- ElectricalUnion 5y ago
  I find funny that on most security contexts, "Trust" doesn't mean something is secure, rather the opposite, that security is definitely compromised if "Trust" is compromised.
mschuster91 5y ago
Does this also impact Android's FDE layer when used with a reasonably-strong password, or does the FDE layer rely purely on userspace password-driven key derivation? 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.
- motohagiography 5y ago
  What I knew about Knox 10y ago was that it was an applet within the TrustZone that samsung adopted, and I didn't think they got an actual fuse. Think of it as an HSM/Vault so Android would essentally use it as that. The secrets in the SE/HSM would ensure anything sent to it by the OS would be derived from that unique hardware protected key. There are a couple of ways and a few factors of doing a secure environment in the OS based on this. 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.
motohagiography 5y ago
This is vindicating. I suspect the vulnerabilities were caused by a requirement to align with the Global Platform specification they mention in their references. Not sure that it prescribes AES-GCM, but I remember it being a bit janky at the time as they were trying to adapt protocols from smart card secure elements to mobile phones in a way that preserved compatability. 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.
- upofadown 5y ago
  >Modern protocols would just use ECC with a totally different protocol, ... Do you mean something with initialization vector reuse resistance? Because that seems to be the problem here...
  - motohagiography 5y ago
    To a point. The IV reuse is an artifact of an agreement for a stream cipher, whereas if you used an asymetric key protocol and even DH key exchange, you don't have the same problem. The reason they're using a streaming mode in the first place is likely because of AES/symmetric compatability issues with Global Platform / EMV protocols that rely on initializing the protocol based on a shared secret (so they needed some extra diversification), and a lack of supportability for asymmetric keys in the hardware compatability, imo.
codedokode 5y ago
This "TrustZone" looks like a user-hostile feature which was invented for convenience of placing difficult to detect backdoors.
- lxgr 5y ago
  No, it's mainly a cheaper way to get some level of trusted computing and/or hardened credential storage on ARM-based mobile devices. 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.
  - userbinator 5y ago
    The whole concept of "trusted" computing was never about trusting the user (which in the vast majority of cases involving a mobile phone, is the owner); in fact, quite the opposite. The fact that it sometimes helps the user is merely a beneficial side-effect that the proponents of this authoritarian scheme use as an excuse. https://en.wikipedia.org/wiki/Next-Generation_Secure_Computing_Base https://en.wikipedia.org/wiki/Next-Generation_Secure_Computi... https://en.wikipedia.org/wiki/Peter_Biddle https://en.wikipedia.org/wiki/Peter_Biddle
rkagerer 5y ago
They demonstrated their findings on Galaxy S8 through S21 smartphones. 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?

165 points by zdw 5y ago

~10 years ago: How horrible. Sad to see such security holes being found in our devices. Now: Nice. I wonder what kind of DRM/Anti-user feature will this break. I hope it never gets patched.

lxgr 5y ago
Would you consider WebAuthN platform credentials and securing payment credentials "anti-user"? DRM is just one application.
- no_time 5y ago
  No. That's the least bad use case out of the bunch. If it stays as an option and/or the issuing organization provides the token, it's a benefit. 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.
  - lxgr 5y ago
    As far as I'm aware, there's nothing in either the WebAuthN or the FIDO/CTAP specifications forbidding back-up-able (i.e. clonable) credentials. 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.
    - franga2000 5y ago
      WebAuthN is designed to let the site limit what kind of tokens you're allowed to use. It doesn't matter that clonable tokens exist if every site only allows unclonable ones. We're currently in the same boat with rooted Android devices - we have the freedom, but if we want to use anything from bank apps to scooter rentals, we aren't allowed to exercise that freedom.
      - lxgr 5y ago
        > WebAuthN is designed to let the site limit what kind of tokens you're allowed to use. 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.)
        franga2000 5y ago
        No! If I get my token stolen or cloned, that's my problem. When have you seen a service provider held liable for what someone did with credentials that were stolen from a customer. If someone steals my bank card and uses it to buy stuff, the bank isn't going to be liable for that, so why would it be any different for 2FA tokens? 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.
- Schroedingersat 5y ago
  Yes. If it means access to commerce or banking services requires submitting control of your phone to a third party.
  - lxgr 5y ago
    As long as it's a well-defined, sandboxed component of my phone, this seems like a much better tradeoff than behavioral fingerprinting that just gobbles up as much sensor data as it can get its hands on (while still not completely preventing moderately sophisticated spoofing attacks).

api 5y ago

This was obviously built by someone lacking even a basic understanding of how to use cryptographic primitives. It's not that hard to use an AEAD cipher construction properly. Nonce stands for number used once.

JCWasmx86 5y ago
It is good for the freedom of the user, that the user it is able to access everything in the TrustZone.
SkittyDog 5y ago
Interesting thing about the term "nonce"... that etymology is not entirely accurate. It's not quite a false etymology, but it is a sort of a "backronym" kinda thing. 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 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.

danuker 5y ago

Cute title! Security through obscurity falls apart when brought to the spotlight. Which is why I don't trust platforms mentioning "Trust". They are not built for the consumer anyway, but through subsidies of a misguided copyright industry seeking to inflict DRM.

jimmySixDOF 5y ago
Just so you know, the title is a play on "Democracy Dies in Darkness" which is the Washington Post newspaper's motto
- unixbane 5y ago
  which both get ignored by means of the hyperbole filter
  - jessaustin 5y ago
    It's more of a mission statement than a motto, anyway.
    - unixbane 5y ago
      well all news media is pro state and anti freedom so...
ElectricalUnion 5y ago
I find funny that on most security contexts, "Trust" doesn't mean something is secure, rather the opposite, that security is definitely compromised if "Trust" is compromised.

mschuster91 5y ago

Does this also impact Android's FDE layer when used with a reasonably-strong password, or does the FDE layer rely purely on userspace password-driven key derivation? 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.

motohagiography 5y ago
What I knew about Knox 10y ago was that it was an applet within the TrustZone that samsung adopted, and I didn't think they got an actual fuse. Think of it as an HSM/Vault so Android would essentally use it as that. The secrets in the SE/HSM would ensure anything sent to it by the OS would be derived from that unique hardware protected key. There are a couple of ways and a few factors of doing a secure environment in the OS based on this. 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.

motohagiography 5y ago

This is vindicating. I suspect the vulnerabilities were caused by a requirement to align with the Global Platform specification they mention in their references. Not sure that it prescribes AES-GCM, but I remember it being a bit janky at the time as they were trying to adapt protocols from smart card secure elements to mobile phones in a way that preserved compatability. 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.

upofadown 5y ago
>Modern protocols would just use ECC with a totally different protocol, ... Do you mean something with initialization vector reuse resistance? Because that seems to be the problem here...
- motohagiography 5y ago
  To a point. The IV reuse is an artifact of an agreement for a stream cipher, whereas if you used an asymetric key protocol and even DH key exchange, you don't have the same problem. The reason they're using a streaming mode in the first place is likely because of AES/symmetric compatability issues with Global Platform / EMV protocols that rely on initializing the protocol based on a shared secret (so they needed some extra diversification), and a lack of supportability for asymmetric keys in the hardware compatability, imo.

codedokode 5y ago

This "TrustZone" looks like a user-hostile feature which was invented for convenience of placing difficult to detect backdoors.

lxgr 5y ago
No, it's mainly a cheaper way to get some level of trusted computing and/or hardened credential storage on ARM-based mobile devices. 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.
- userbinator 5y ago
  The whole concept of "trusted" computing was never about trusting the user (which in the vast majority of cases involving a mobile phone, is the owner); in fact, quite the opposite. The fact that it sometimes helps the user is merely a beneficial side-effect that the proponents of this authoritarian scheme use as an excuse. https://en.wikipedia.org/wiki/Next-Generation_Secure_Computing_Base https://en.wikipedia.org/wiki/Next-Generation_Secure_Computi... https://en.wikipedia.org/wiki/Peter_Biddle https://en.wikipedia.org/wiki/Peter_Biddle

rkagerer 5y ago

They demonstrated their findings on Galaxy S8 through S21 smartphones. 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?