On 7/25/2016 8:21 AM, Somaraju Abhinav wrote:
Hi Mike,
The group key is also the authorization key in the model proposed.
Any entity that holds that key can forge a message that can cause the
action authorized by the issuance of that key. In your example,
assuming that the door lock and the lightbulb share the same group
key, then compromising the lightbulb allows you to control the door lock.
[AS] This is not the model we have in mind in the document. It is
clear that the document needs some more specification work which
relies on OSCOAP/COSE being complete. However, if you look at sections
3.3 and 3.4 both the AT-R and AT-KDC assume that there is a field
“Scope” which mentions permissions of the entity holding the token
including “which resources maybe accessed with the token”. So,
compromising a lightbulb group key does not automatically imply that
the door-lock can be controlled with the same key.
Let's try one more time here.
1) If a group of devices share a key, and
2) If some of that group of devices are controllers, and
3) The majority are actuators (e.g. lightbulbs, locks), and,
4) The shared key is the only cryptographic protection on
authentication, THEN,
5) The compromise of any device, even an actuator can be used to
successfully forge messages that appear to come from controller nodes.
Permissions notwithstanding - if more than two entities share a
symmetric key, a receiver of a symmetrically signed message cannot trust
that the message it received came from the identified source.
[If two entities share a key, and I get a message that's signed by that
key, and I didn't sign the message then obviously it came from the other
guy. If three entities share a key Alice, Bob and Charlie, and Alice
receives a message that purports to be from Bob, but is actually
originating from Charlie, she cannot determine that the message did not
come from Bob through any cryptographic means with this key]
Continuing:
The usual model for symmetric key authentication of a message is:
Sender does: messageAuthenticationCode = MAC (sharedKey, Message). Send
Message || messageAuthenticationCode.
Receiver does: receivedMessageAuthenticationCode = MAC (sharedKey,
Message). Compare receivedMessageAuthenticationCode with
messageAuthenticationCode and if they match (according to match rules),
message is authenticate.
Note the similarities. In a symmetric key authentication - the sign
and verify steps differ only on what you do with the output of the MAC
calculation. Which implies that basically if you can verify it, you can
forge it.
Please let's consider the cryptography rather than something that
doesn't actually provide an enforceable mechanism.
Mike
ps - someplace along the way someone came up with the meme that the
lightbulbs and locks were on the same key domain and that was what I was
complaining about. Instead, see above. What I'm complaining about -
indeed what we settled upon in DICE - is that symmetric key group
communications systems are not secure enough for any cyber-physical
control system without specific mitigations. (For a definition of
cyber-physical - Wiki is pretty good -
https://en.wikipedia.org/wiki/Cyber-physical_system)
In general, authentication comes with the key that you have -
authorization is then tied to that key. In DTLS (as in TLS), your
session key is also your authorization key once your TLS session is
tied to a particular identity (e.g. via an HTTP login, via a client
cert exchange, via OAuth).
So - cosmetic differences only.
Mike
_______________________________________________
Ace mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ace
