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

[Robert Cragie <[e-mail]>]

Mike,

Apart from the black/white aspect, I think we are actually in agreement,
i.e. I agree that using a public key-based signature is easily the most
practical and secure mechanism from a crypto perspective. If it is
practical for the application, it should be what is recommended, However,
Markus has concisely summed up different security levels. In other words,
there are alternatives to "use public key-based signatures or the sky will
fall on your head".

Robert

On 27 July 2016 at 17:06, Michael StJohns <[e-mail]> wrote:

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