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

[Somaraju Abhinav <[e-mail]>]

Hi Mike,
Would it help if the draft allows two solutions one based on symmetrical keys and one based on asymmetric keys and allows the system designers to pick one of the two options?
Abhinav
________________________________
From: Somaraju Abhinav<mailto:[e-mail]>
Sent: ‎25/‎07/‎2016 19:00
To: Michael StJohns<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>
Subject: Re: [Ace] Adoption of Low Latency Group Communication Security Work in ACE




________________________________
Let's try one more time here.
[AS] Good. Much clearer now.

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.
[AS] Agree.

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.
[AS] Agree, but I have a few comments:
1) Source authentication vs group membership authentication: I agree with you that the receiver can not authenticate the source of the message. However, if the key is not compromised, then the receiver can authenticate that the source of the message is from a group member.
2) Group membership authentication is sufficient: I am only knowledgeable about lighting applications and will talk about how this occurs (but this is also applicable to other building automation applications AFAIK). In this application, a commissioner verifies the existence of devices that are permanently installed in a building using public key crypto and can give group keys to devices that should be a part of the group. Note that these groups are not dynamically changing and members of the group are permanently installed in a building. Therefore, typically authentication of group membership is sufficient for application requirements.
3) Probability of key compromise: This is the point where group symmetric key crypto suffers compared to using symmetric key for a pair of devices. The claim here is that it is easier to compromise a key that is stored in a large number (e.g. 1000) of identical devices rather than a specific device in a network. I do not disagree with this claim. However, I do not think this is a big price to pay at least for lighting applications. The claim here is that it is easier to hack into one of a thousand identical devices than a small number of these identical devices. You have to weigh this against the fact that it solves an application problem with no other feasible solution. I am prepared to be educated in this regard but we essentially have 50-100 ms for the signing+verification process and I do not know of a solution that does this.

[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.
[AS] This point is completely clear. We CAN NOT DO SOURCE AUTHENTICATION.

Please let's consider the cryptography rather than something that doesn't actually provide an enforceable mechanism.
[AS] Again, I repeat the comments above. It is clear that if a symmetric group key is used, then source authentication is no longer possible. But, considering cryptography, it is possible to authenticate group membership. Authentication of group membership is sufficient for this use case. The main issues to weigh are: "The greater likelihood of key compromise when the secret is shared by a large number of identical and permanently installed nodes compared to a similar single node" vs "The requirements of low latency communication".

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.
[AS] Agree. We are looking at various mitigation issues. The main ones are: Ensure permissions are properly scoped so that compromise of group key only results in little harm. Propose methods for recycling group key. Ensure that devices use PKI to authenticate themselves before receiving a group key. This list is clearly not complete and would be great to receive more input as to how more mitigation is possible.

(For a definition of cyber-physical - Wiki is pretty good - https://en.wikipedia.org/wiki/Cyber-physical_system)
Cyber-physical system - Wikipedia, the free encyclopedia<https://en.wikipedia.org/wiki/Cyber-physical_system>
en.wikipedia.org
A cyber-physical system (CPS) is a mechanism controlled or monitored by computer-based algorithms. Examples of CPS include smart grid, autonomous automobile systems, ...








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


________________________________________________________ The contents of this e-mail and any attachments are confidential to the intended recipient. They may not be disclosed to or used by or copied in any way by anyone other than the intended recipient. If this e-mail is received in error, please immediately notify the sender and delete the e-mail and attached documents. Please note that neither the sender nor the sender's company accept any responsibility for viruses and it is your responsibility to scan or otherwise check this e-mail and any attachments.
________________________________________________________ The contents of this e-mail and any attachments are confidential to the intended recipient. They may not be disclosed to or used by or copied in any way by anyone other than the intended recipient. If this e-mail is received in error, please immediately notify the sender and delete the e-mail and attached documents. Please note that neither the sender nor the sender's company accept any responsibility for viruses and it is your responsibility to scan or otherwise check this e-mail and any attachments.