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
[email protected]
https://www.ietf.org/mailman/listinfo/ace
_______________________________________________
Ace mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ace
