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