[HN Gopher] A simple, (as-of-yet unidentified) asymmetric Authen...
       ___________________________________________________________________
        
       A simple, (as-of-yet unidentified) asymmetric Authenticated Key
       Exchange
        
       Author : Fethbita
       Score  : 32 points
       Date   : 2024-03-25 07:30 UTC (1 days ago)
        
 (HTM) web link (dannyvanheumen.nl)
 (TXT) w3m dump (dannyvanheumen.nl)
        
       | jonahbenton wrote:
       | This seems to be the use case for a user communicating with a
       | confidential computing/enclave abstraction.
        
         | pclmulqdq wrote:
         | Why wouldn't you have your enclave carry a certificate instead
         | of doing this?
         | 
         | You may eventually need to rotate its identity key, and if you
         | want to do that, you need a certificate system.
        
       | mike_d wrote:
       | I think this depends on a lot of assumptions about the
       | capabilities of what is otherwise described as an absolutely dumb
       | featureless device.
       | 
       | If the device lacks access to storage it cannot store any state.
       | How do you ensure the RNG isn't initialized to the same value
       | every time? I'm not sure how that impacts some of the assumptions
       | about security here.
        
         | a1369209993 wrote:
         | > the RNG isn't initialized
         | 
         | Or used.
         | 
         | sk_identity is static over the lifetime of the device, so
         | doesn't need new entropy.
         | 
         | sk_device is generated _after_ pk_user is recieved, so can use
         | HASH(sk_identity,pk_user) as entropy. This results in the same
         | pk_device for every session with a given pk_user, which
         | theoretically enables traffic analysis, but the security model
         | implies traffic analysis is out-of-scope.
         | 
         | signature and enc_sig might need entropy as well, but can still
         | use HASH(sk_identity,pk_user).
        
           | mike_d wrote:
           | You could... but I guess my bigger point is that wasn't even
           | addressed.
           | 
           | This is my first time seeing Verifpal, but it looks like a
           | huge foot gun in the wrong hands. Here the author was lead to
           | believe there was some sort of formal validation of his roll-
           | your-own crypto, while glossing over obvious potential
           | implementation flaws.
        
       | pclmulqdq wrote:
       | I think this protocol is correct-ish* when you make the strong
       | assumptions you have made about the device, but I also don't know
       | why you would use it. Normally, you would prefer to both have
       | unique device public keys for domain separation (preventing re-
       | use of IVs, etc.) combined with the ability to verify that the
       | device public key is actually the public key of a legitimate
       | device. Otherwise, you could have a non-legit device conduct a
       | MITM attack by running this protocol (if you trust the device to
       | provide its identity PK) with the user and the device separately
       | or you could have a counterfeit device created when sk_identity
       | is eventually exfiltrated (if you set the identity PK as the same
       | number for all devices at the factory - see what happens with
       | DRM). Using some sort of device ID with a database mapping IDs to
       | PKs also doesn't give you counterfeit protection the way a
       | certificate does - a counterfeiter can re-use an ID. You also
       | can't rotate your identity keys if you use this scheme.
       | 
       | Most cryptosystems today offer flexible-enough primitives that
       | you can come up with a lot of different possible ways to do
       | things like this. Whether they are useful is a different story.
       | 
       | IMO you should probably do something more normal, and just store
       | the certificate chain with the device programming.
       | 
       | *After about 10 minutes of analysis, so YMMV taking my word for
       | it.
        
         | layer8 wrote:
         | Yeah, from the requirements it's not clear why you wouldn't
         | just use TLS.
        
           | mike_d wrote:
           | This. Even if TLS is the wrong answer, it will always be
           | better than anything you roll yourself.
           | 
           | Shout out to https://www.trustedfirmware.org/projects/mbed-
           | tls/
        
       | thadt wrote:
       | On a cursory glance, this looks rather quite a bit like a Noise
       | [1] pattern. One rather nice aspect of Noise is that there is a
       | good reference chart for which security properties one should
       | expect from different combinations - saving time on proofs.
       | 
       | [1] https://noiseprotocol.org
        
         | abound wrote:
         | While we're talking Noise, I'll plug the excellent Noise
         | Explorer [1], which visualizes handshakes, enumerates security
         | properties, and offers Go + Rust (+ wasm) implementation
         | downloads.
         | 
         | I used this (and the NNpsk0 handshake [2]) as the basis for an
         | E2EE chat app.
         | 
         | [1] https://noiseexplorer.com/
         | 
         | [2] https://noiseexplorer.com/patterns/NNpsk0/
        
       ___________________________________________________________________
       (page generated 2024-03-26 23:01 UTC)