Re: [Ace] Summary of ACE Group Communication Security Discussion

[Michael StJohns <[e-mail]>]

On 9/26/2016 12:10 PM, Eliot Lear wrote:
> Hi Mike,
>
> Just one clarification:
>
>
> On 9/26/16 5:41 PM, Michael StJohns wrote:
>> With respect to Eliot's comment, it doesn't really matter if the key
>> management protocol is asymmetric if the multicast session keys are
>> symmetric and used for control.
> This doesn't really capture my position which leads me to believe I've
> muddled it.  The key question is whether every transaction needs to be
> authenticated to a unique device *within this protocol* or is it
> sufficient that such authentication exists at other layers, e.g., either
> in content or at lower layers?  I recognize that there are some big
> risks to adding such a dependency, because there is no certainty that
> implementations will follow that guidance.
Hi Eliot -

Ah - sorry, I didn't understand what you meant.

Let me discuss a few more things and hopefully that will clarify things.

Multicast traffic falls into three broad groups:  Content (e.g. 
broadcast audio/video etc), sensor and control.

Of these three, only the first has a real (non-mitigated) symmetric key 
story: if you can break into an end node to steal its copy of the 
multicast key, you can break into an end node to steal the content, so 
the compromise of the multicast key and the compromise of the node have 
similar impacts. In other words, the risk of using symmetric key 
multicast is no worse than the risk of using symmetric key unicast.

  For the other two, it comes down to source authentication: being able 
to forge either a control command or a sensor datum can have *bad* 
consequences (e.g. having the sensor tell you that the coolant level in 
the cooling pond for nuclear rods is too high so you pump out what you 
think is the excess; having a key extracted from an actuator node 
telling the pump to go on).  In the latter two cases, breaking into the 
node can allow you to do more than the node is legitimately authorized 
to do, and can allow you to masquerade as any node that uses that key 
for authentication.  In this case, using symmetric key multicast is 
*MUCH* worse than using symmetric key unicast with respect to the 
security guarantees.

So far so good?

In the instant case - lighting - there's really no secret content to 
speak of, and hence the content confidentiality model of multicast with 
symmetric keys is really inapplicable.  So, if confidentiality isn't a 
really a requirement, and you can't achieve source authentication 
(required for sensor or control) with symmetric key multicast, why do it?


>
>> The analysis of this can pretty much ignore the key management piece
>> and start with 100 controllers and 1000 actuators with pre-shared keys
>> to consider the threat and mitigation models. Which analysis - AFAICT
>> - no one has actually done.  Basically, if you can't secure this
>> 100/1000 system  and keep it secure with respect to control functions,
>> I would argue that the rest of it (e.g. key management) is meaningless
>> window dressing.
> The question in this context again, is whether it all has to happen at
> this layer?

Can you figure out any way to prevent implementers and designers from 
using the symmetric multicast key for authentication?  If so, then the 
answer is yes,  If not, then no. This is what I've been talking about 
when I say "crippling" the protocol to prevent the abuses. You might as 
well do an all in one secure protocol at this level rather than leaving 
this an exercise for the student.   That's not to say that application 
layer protocols might not also have their own authentication.

Later, Mike

>
> Eliot
>
>