[HN Gopher] Trust dies in darkness: Shedding light on Samsung's ...
       ___________________________________________________________________
        
       Trust dies in darkness: Shedding light on Samsung's TrustZone
       Keymaster design [pdf]
        
       Author : zdw
       Score  : 125 points
       Date   : 2022-03-04 14:50 UTC (8 hours ago)
        
 (HTM) web link (eprint.iacr.org)
 (TXT) w3m dump (eprint.iacr.org)
        
       | no_time wrote:
       | ~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 wrote:
         | Would you consider WebAuthN platform credentials and securing
         | payment credentials "anti-user"?
         | 
         | DRM is just one application.
        
           | no_time wrote:
           | 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 wrote:
             | 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.
        
       | danuker wrote:
       | 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 wrote:
         | Just so you know, the title is a play on "Democracy Dies in
         | Darkness" which is the Washington Post newspaper's motto
        
           | unixbane wrote:
           | which both get ignored by means of the hyperbole filter
        
             | jessaustin wrote:
             | It's more of a mission statement than a motto, anyway.
        
       | motohagiography wrote:
       | 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 wrote:
         | >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...
        
       | api wrote:
       | 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 wrote:
         | It is good for the freedom of the user, that the user it is
         | able to access everything in the TrustZone.
        
         | SkittyDog wrote:
         | 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
         | 
         | 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.
        
       | mschuster91 wrote:
       | 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.
        
       | codedokode wrote:
       | This "TrustZone" looks like a user-hostile feature which was
       | invented for convenience of placing difficult to detect
       | backdoors.
        
         | lxgr wrote:
         | 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.
        
       ___________________________________________________________________
       (page generated 2022-03-04 23:00 UTC)