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

[Michael StJohns <[e-mail]>]

On 7/26/2016 7:55 PM, Robert Cragie wrote:
> Mike,
>
> My concern with this thread is that you seem to have a very 
> black/white assumption regarding the use of a symmetric group key. 
> Defining a protocol which allows use of a symmetric group key does not 
> in itself imply that it will be misused. It's a bit like saying we 
> can't design an automobile because the driver may be inept and cause a 
> serious accident.

Hi Robert -

I tend to have a very black/white assumption with most of the laws of 
physics.

>
> However, I do agree with almost all the statements you have made 
> regarding the use of a symmetric group key apart from this one:
>
> MSJ >The receiver has no guaranteed way of knowing whether or not ANY 
> group member is compromised so the authentication is pretty much 
> meaningless.
>
> It is not meaningless, it still applies to the holder of the group 
> key. Sure, one of the group could be compromised and as you say 
> purport to be any member of the group (and there are still probably 
> mitigations against this) but an entity outside of the group will not 
> be able to purport to be in the group.

I remain confused as to how you think that is.

I'm not a member of the group, but I convinced a member of the group to 
give me his copy of the group key (e.g. I broke in and stole it and he 
was none the wiser).  How do you differentiate between me and him?  In a 
message, what cryptographic evidence proves that a message came from a 
member of the group?  If you say group key, I say "stolen".

I'm a member of the group but a bad actor - I'm masquerading as a 
controller instead of an actuator.  How do you prove I'm not a 
controller?  In a message, what cryptographic evidence proves that the 
message came from a controller?  If you say group key, I say "hacked".

Forget for a moment about the process of getting keys to the various 
devices (e.g. let's leave off the key management topic for a moment) and 
consider this case::

A device builder builds 1000 devices, of which 900 are lightbulbs and 
100 are lightswitches and installs within all of them a single group 
key.  That group key is used - as is being described here - as the key 
for the switches to control all of the light bulbs.

Note that at this point we're effectively at the same place a mesh with 
a key management protocol that is distributing a group key would be.  We 
just got there manually.

An attacker manages to get his hands on one of the lightbulbs and 
extracts the group key.  He places his own device in the system which 
has the lighting network  interface on one side, a more general IP 
network interface on the other (complete with HTTP or Telnet or 
somesuch), and contains a copy of the group key and all the relevant 
protocols. Whenever the attacker wants,  he may use that group key to 
send out a control message to any of the lightbulbs.

The addition of a key management protocol to distribute symmetric group 
keys does not improve this much if at all -- UNLESS you have wickedly 
good compromise detection mechanisms that allow you to identify and 
eject bad actors quickly.  But I can't actually think of a scenario 
where depending on good compromise detection without a human in the loop 
works well.

Continuing - the addition of the key management protocol allows you to 
update the group key and hopefully send it to only good actors. But, 
even that provides little or no mitigation as an attacker can a) steal 
the identity keys for a device and passively tap the over the air 
negotiations. b) if that doesn't work, can steal the identity keys and 
replace a legitimate device with his own clone and use that to fake 
control messages, c) re-purpose an existing device to tell him the keys, 
etc.   There are mitigations for most of these, but they require secure 
elements.  Once you have secure elements, then the argument for not 
doing public key pretty much goes away.

> So it is not meaningless. There are many cases where groups can be 
> small and therefore (as you explain) the impact of compromise decreases.

It really is meaningless when N > 2.  And becomes even more meaningless 
(true, hard to go down from zero...) as N increases.




>
> This leads to the points Abhinav and Kathleen have made. Security 
> policies can be put in place to limit the scope and distribution of 
> group keys. If the potential number in a group for a particular use 
> case (taking into account all the properties of that use case which 
> may provide additional mitigation) exceeds a certain amount then we 
> can recommend that symmetric group keys are not used.

You and I agree here.  My number is 3.  (It's actually 2, but Kerberos 
like systems are actually somewhat useful so its 3 with caveats).   I 
haven't heard an argument that makes sense for anything larger.



>
> You mentioned secure element in an earlier e-mail; these facilities 
> are becoming more widely available and cheaper and are starting to 
> appear in low-cost microcontrollers today. As indeed are crypto 
> elements, which would then suggest the use of signing+verifying would 
> be more appropriate as you suggest.
>
> In a nutshell, I agree with your assessment regarding symmetric group 
> keys but there are always tradeoffs and I don't see how we can ban 
> something simply because it might be problematic if misused.

Hmm... the IETF seems poised to ban clear-text transmissions of any kind 
because they might be problematic if misused...

Never mind.  In any case, Cyber-Physical is a different beast. We've 
started to see an upswing of attacks on poorly secured physical systems 
(power, military drones, etc).  I'm not sanguine about introducing a 
known bad solution that CANNOT be made secure without other assumptions 
(e.g. the secure element stuff).


I've sketched out a few symmetric key multicast protocols that might 
work with secure elements, but they all require an interesting thing to 
provide any guarantees - that the secure element be able to prove 
(during the key exchange/update protocol) that it is a secure element by 
the definition of the protocol.  Think of it this way - it doesn't help 
to build a protocol that depends on secure elements for guarantees, if 
you can trivially defeat those guarantees by introducing a device that 
implements the protocols, but doesn't actually keep the keys in a secure 
element.

So, I fall back on public key systems as being a lot less complex, a lot 
more flexible and a lot easier to understand than the nuances of 
symmetric key multicast.

Later, Mike




>
> Robert
>