On 7/21/2016 5:04 AM, Hannes Tschofenig wrote:
Some other folks, including myself, believe that we would not just
use the group key to determine the authorization decision but would
instead rely on the authorization mechanism to prevent larger harm.
This means that a compromised luminare would indeed turn on and off
other luminaires in the group but they would not be able to successfully
send commands to a door lock since those would (a) not use group
communication and (b) if they use group communication then that would
require an interaction with the authorization server to first obtain a
different group key for such an interaction. Most likely there is no
need for a luminare to obtain a group key for communicating with a door
lock.
Hi Hannes -
If the protocol were constrained to a small number of group members -
say 16 for example - then solving this problem is as simple as sending a
control message with multiple message integrity tags - one per target
device. In the lighting problem, you could probably make this work with
about a 3 byte overhead per device for a total of 48 MIC bytes (4 bits
for EP identifier, 20 bits for the MIC) and still have reasonable
security. And all without having to have a group key.
If you go larger than this, then the group key becomes more attractive,
but also less secure. The probability of compromise of the group - if
its an interesting target - approaches unity assuming physical access to
any device in the group.
Without unique source identification (and for that matter role
identification either inband or implicit) any compromised device results
in your attacker being able to act as a controller for the group.
Again, not a large problem (but a problem nonetheless) for a small group
of lights inside an office behind locked doors. But a very large problem
for a system that's possibly controlling 100 or 1000 lights in a group.
As I said at the microphone, if I thought you could just do this as the
"ACE protocol for group control of lights" and keep people from using it
for other things I'd be a lot less concerned (but still there's the
whole threat of turning off all the lights in a building all at once).
But the reality is this protocol will be used for control of things
beyond lights and it would be irresponsible to standardize a protocol
with a real possibility for direct real-world negative impacts on safety
and health.
The way to solve this for a general involves public key cryptography -
that's just how the security and physics and math work out.
Mike
ps - the idea of secure group multicast for controlling things is indeed
a wonderful idea - but think for a moment. If it's such a great idea,
why isn't it already in use somewhere?
MSEC did quite a lot of work on providing confidentiality for
multicasted messages, but the work it did on integrity/authentication
produced only a document that allowed you to authenticate the sender
after the event was supposed to occur. (E.g. TESLA) That's probably not
useful for controlling things in real time.
Given the amount of work that was done there, and in various academic
settings and with a large number of people and with money and with
impetus to make this work on symmetric key systems, why will ACE be more
successful? What has changed in our understanding of the problem and
the solutions set?
_______________________________________________
Ace mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ace
