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

[Michael StJohns <[e-mail]>]

On 7/25/2016 12:59 PM, Somaraju Abhinav wrote:
>
>
>
>
> ------------------------------------------------------------------------
> 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.

The receiver has no guaranteed way of knowing whether or not ANY group 
member is compromised so the authentication is pretty much meaningless.

Also any assertion in the message as to the role of the purported sender 
is meaningless as well as you can't actually enforce responsible 
behavior on an end-node.

> 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.

Again - no.  Compromise of a single device that is legitimately part of 
the group can be done on an on-going basis.  E.g. the device gets and 
keeps getting group keys and then sends them off to the attacker.

> 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.

*sigh*  The formula for the probability of the compromised of a mesh is  
1-(1-p)^N.  Where p is the probability of the compromise of a single 
device and N is the number of devices.

The table is here: 
https://www.ietf.org/mail-archive/web/dtls-iot/current/msg00165.html

The cost formula for actually attacking the mesh is MIN 
(costAttack[0..N]) where costAttack[0..N] is the array of costs to break 
into any given node.

The probability approaches unity that someone will figure out how to 
hack any give product assuming that product is wide spread (cf Philips 
lightbulbs).

And - I repeat - there is a feasible solution - public key control 
message authentication.   (I note with amusement that the figure of 
merit of 50-100ms performance is a decrease from what I think was the 
original figure of merit of 200-300ms and that it seems to be getting 
lower as the performance of commodity hardware increases). And note that 
special purpose hardware can do this will within this time window. 
(https://www.ietf.org/mail-archive/web/dtls-iot/current/msg00316.html, 
https://www.ietf.org/mail-archive/web/dtls-iot/current/msg00317.html)

>
> [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.

To be clear, you can't do source authentication with group symmetric keys.

So given that you can't do source authentication, why do group keys at 
all?  It's no better than a sturdy lock on an outhouse with no roof.



>
> 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".

You've stated your restrictions.  I've stated my objections.  I see 
nothing at all new in the discussion since DICE.

>
> 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.

You have locked on to one particular solution that will not work. Using 
PKI to get symmetric group keys WILL NOT give you any protection.


>
> (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.