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

[Michael StJohns <[e-mail]>]

Comments inline. Also see particularly, the comments underlined and in bold.

On 11/24/2016 9:09 AM, Hannes Tschofenig wrote:
> Hi Mike
>
> On 11/17/2016 06:50 AM, Michael StJohns wrote:
>> There is no case (absent hardware mitigation) in which a symmetric group
>> key solution can be made secure/safe and no one has made an offer of
>> proof that they can make it secure.    I've asked repeatedly - no one
>> has come forward with more than "oh we can lock the symmetric key stuff
>> in a corner and make sure it isn't used for anything important".
> Security is not a black and white thing. What has been clear is that any
> solution that was proposed for symmetric keys did not meet your
> expectation.

This is a fairly null-value and disingenuous statement, _*but it helped 
me realize that you (plural) haven't actually stated any security 
requirements for a group  control system protocol*_. What you have 
stated are constraints (low cost, low latency) that you believe inform 
the choice of security solutions - but these are NOT security 
requirements.   Unfortunately, without stating your actual security 
requirements, its difficult for you to realize that the solution 
intersection of your constraints with any reasonable security 
requirements is probably the empty set.

The analysis of whether a particular solution meets or exceeds the 
requirements for the system *is* actually a pretty black and white thing 
- it involves physics, math, cryptography and probability and an 
analysis of threats vs strengths.

So let me put forth what I believe is a reasonable minimum security 
requirement for this group control system:

"Compromise of a single device shall not result in an attacker having 
more privileges that nominally are assigned to that device." or less 
nuanced: "Compromise of a single device shall not result in the 
compromise of the entire system."

Now you can put forth your minimum security requirements and we can 
decide as a group if those minimums are acceptable, and then figure out 
if your proposed solutions meet the requirements in any meaningful manner.





>
>>
>> Given the recent attacks on the internet by IOT botnets, there is a
>> further consideration that should be undertaken - whether the symmetric
>> group key solution applied to 10s of 1000s of IOT devices is an active
>> threat to the rest of the internet (e.g. enabling DDOS, cyber physical
>> issues, etc)?
> The recent attack was made possible because all devices were provisioned
> with the same password, which was publically known.

Seriously?   If you'd had 10,000 devices with the same password, but 
that the password wasn't known to anyone at manufacture, the result 
wouldn't have been any different.  The attacker would have grabbed one 
of the devices, and extracted the password and controlled 10K 
devices.    Alternately, buy 10k devices, set an identical new password 
on each of them and deploy.  Same result.

>
> What we are proposing here is a key distribution protocol where
> * each device is provisioned with unique keys (symmetric or asymmetric
> keys),
> * uses those keys to authenticated to the trusted third party (the KDC),
> and
> * then gets provisioned with temporary shared secrets for used with
> group communication (whereby non-persistent symmetric keys are used for
> different groups, keys change over time and where there is an
> authorization step before you can join a group).

Again, 1) compromise a device, 2) have it pass on any symmetric key it 
is given to an attacker. 3) Attacker controls the system. Lather, rinse, 
repeat.  It *DOES NOT MATTER* how the symmetric keys get to the 
device,_*it only matters that more than two devices at time T share the 
same symmetric key and the attacker can get to one of those devices.*__*
*_
>
>
>> The multiparty (group) symmetric key solution is only wanted for a
>> single corner of the solution space - low latency, no cost systems.
>> E.g. lightbulbs.  Given there is a worked example of the insecurity of
>> multiparty symmetric key systems (e.g. the attack on the symmetric
>> signing key of the HUE lights), I'm unclear why anyone at all would
>> think that pursuing a known bad solution in the IETF is a good idea.
> While the lighting sector is only one part of the IoT industry I think
> it is OK to standardize a solution for one industry that consists of
> different vendors.
>
> The hack against the HUE lightbulbs you are referring to was also
> different. The issue there was that the entire product series was using
> the same shared secret provisioned during manufacturing.
They were using the same shared symmetric firmware signing/encrypting 
key.  Which allowed an attacker to create "valid" firmware and use a 
zigbee stack flaw to cause it to be loaded.

Again - a symmetric key shared between more than two entities led to a 
fatal flaw in the system.

> What we are
> doing, however, is to utilize a key distribution protocol to dynamically
> create shared secrets. So, each device has unique keys to authenticate
> to the KDC and then gets group keys dynamically provisioned. Note that
> the security difference here is huge.

No, it's actually not and no reasonable cryptographic protocol designer 
would say otherwise.

>
> I know that you are aware of the differences between the attacks and
> what we do in the ACE working group. Hence I am a bit disappointed that
> you are trying to make others in the group, who are less knowledgeable
> in security, believe that these attacks are actually related.

And I'm a bit disappointed that you're trying to claim that the attacks 
are not. I'm also a bit disappointed about the personal attack - but 
that's irrelevant to the discussion. The only difference between the HUE 
attack and attacking a multi-party symmetric key system is where and how 
you get the group key (or signing key).    In general, in both, attack a 
single device and you can extract the multi-party shared secret.

In terms of threat analysis they are exactly the same order of attack:  
Compromise one device, compromise the system that the device belongs 
to.  In the HUE attack all the HUE devices belonged to the same firmware 
system.  In an attack on group symmetric key multicast, all the devices 
belong to the same  multicast group.

The details for the attacks may differ.  The actual impacts to a 
successful attacks may differ (re-writing firmware vs turning on and off 
things), but the security analysis are exactly the same.

Mike


>
> Ciao
> Hannes
>
>
>
> _______________________________________________
> Ace mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ace