Re: [Ace] Adoption of Low Latency Group Communication Security Work in ACE

[Michael StJohns <[e-mail]>]

On 7/25/2016 8:21 AM, Somaraju Abhinav wrote:
>
> Hi Mike,
>
>
> The group key is also the authorization key in the model proposed.  
> Any entity that holds that key can forge a message that can cause the 
> action authorized by the issuance of that key. In your example, 
> assuming that the door lock and the lightbulb share the same group 
> key, then compromising the lightbulb allows you to control the door lock.
> [AS] This is not the model we have in mind in the document. It is 
> clear that the document needs some more specification work which 
> relies on OSCOAP/COSE being complete. However, if you look at sections 
> 3.3 and 3.4 both the AT-R and AT-KDC assume that there is a field 
> “Scope” which mentions permissions of the entity holding the token 
> including “which resources maybe accessed with the token”. So, 
> compromising a lightbulb group key does not automatically imply that 
> the door-lock can be controlled with the same key.
>

Let's try one more time here.

1) If a group of devices share a key, and
2) If some of that group of devices are controllers, and
3) The majority are actuators (e.g. lightbulbs, locks), and,
4) The shared key is the only cryptographic protection on 
authentication, THEN,
5) The compromise of any device, even an actuator can be used to 
successfully forge messages that appear to come from controller nodes.

Permissions notwithstanding - if more than two entities share a 
symmetric key, a receiver of a symmetrically signed message cannot trust 
that the message it received came from the identified source.

[If two entities share a key, and I get a message that's signed by that 
key, and I didn't sign the message then obviously it came from the other 
guy.  If three entities share a key Alice, Bob and Charlie, and Alice 
receives a message that purports to be from Bob, but is actually 
originating from Charlie, she cannot determine that the message did not 
come from Bob through any cryptographic means with this key]

Continuing:

The usual model for symmetric key authentication of a message is:

Sender does:  messageAuthenticationCode = MAC (sharedKey, Message). Send 
Message || messageAuthenticationCode.

Receiver does:  receivedMessageAuthenticationCode = MAC (sharedKey, 
Message).  Compare receivedMessageAuthenticationCode with 
messageAuthenticationCode and if they match (according to match rules), 
message is authenticate.

Note the similarities.  In a symmetric key authentication -  the sign 
and verify steps differ only on what you do with the output of the MAC 
calculation.  Which implies that basically if you can verify it, you can 
forge it.

Please let's consider the cryptography rather than something that 
doesn't actually provide an enforceable mechanism.

Mike

ps - someplace along the way someone came up with the meme that the 
lightbulbs and locks were on the same key domain and that was what I was 
complaining about.  Instead, see above.    What I'm complaining about - 
indeed what we settled upon in DICE - is that symmetric key group 
communications systems are not secure enough for any cyber-physical 
control system without specific mitigations.   (For a definition of 
cyber-physical - Wiki is pretty good - 
https://en.wikipedia.org/wiki/Cyber-physical_system)




>
> In general, authentication comes with the key that you have - 
> authorization is then tied to that key.  In DTLS  (as in TLS), your 
> session key is also your authorization key once your TLS session is 
> tied to a particular identity (e.g. via an HTTP login, via a client 
> cert exchange, via OAuth).
>
> So - cosmetic differences only.
>
> Mike
>