On 7/25/2016 12:59 PM, Somaraju Abhinav wrote:
------------------------------------------------------------------------
Let's try one more time here.
[AS] Good. Much clearer now.
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.
[AS] Agree.
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.
[AS] Agree, but I have a few comments:
1) Source authentication vs group membership authentication: I agree
with you that the receiver can not authenticate the source of the
message. However, if the key is not compromised, then the receiver can
authenticate that the source of the message is from a group member.
The receiver has no guaranteed way of knowing whether or not ANY group
member is compromised so the authentication is pretty much meaningless.
Also any assertion in the message as to the role of the purported sender
is meaningless as well as you can't actually enforce responsible
behavior on an end-node.
2) Group membership authentication is sufficient: I am only
knowledgeable about lighting applications and will talk about how this
occurs (but this is also applicable to other building automation
applications AFAIK). In this application, a commissioner verifies the
existence of devices that are permanently installed in a building
using public key crypto and can give group keys to devices that should
be a part of the group. Note that these groups are not dynamically
changing and members of the group are permanently installed in a
building. Therefore, typically authentication of group membership is
sufficient for application requirements.
Again - no. Compromise of a single device that is legitimately part of
the group can be done on an on-going basis. E.g. the device gets and
keeps getting group keys and then sends them off to the attacker.
3) Probability of key compromise: This is the point where group
symmetric key crypto suffers compared to using symmetric key for a
pair of devices. The claim here is that it is easier to compromise a
key that is stored in a large number (e.g. 1000) of identical devices
rather than a specific device in a network. I do not disagree with
this claim. However, I do not think this is a big price to pay at
least for lighting applications. The claim here is that it is easier
to hack into one of a thousand identical devices than a small number
of these identical devices. You have to weigh this against the fact
that it solves an application problem with no other feasible solution.
I am prepared to be educated in this regard but we essentially have
50-100 ms for the signing+verification process and I do not know of a
solution that does this.
*sigh* The formula for the probability of the compromised of a mesh is
1-(1-p)^N. Where p is the probability of the compromise of a single
device and N is the number of devices.
The table is here:
https://www.ietf.org/mail-archive/web/dtls-iot/current/msg00165.html
The cost formula for actually attacking the mesh is MIN
(costAttack[0..N]) where costAttack[0..N] is the array of costs to break
into any given node.
The probability approaches unity that someone will figure out how to
hack any give product assuming that product is wide spread (cf Philips
lightbulbs).
And - I repeat - there is a feasible solution - public key control
message authentication. (I note with amusement that the figure of
merit of 50-100ms performance is a decrease from what I think was the
original figure of merit of 200-300ms and that it seems to be getting
lower as the performance of commodity hardware increases). And note that
special purpose hardware can do this will within this time window.
(https://www.ietf.org/mail-archive/web/dtls-iot/current/msg00316.html,
https://www.ietf.org/mail-archive/web/dtls-iot/current/msg00317.html)
[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.
[AS] This point is completely clear. We CAN NOT DO SOURCE AUTHENTICATION.
To be clear, you can't do source authentication with group symmetric keys.
So given that you can't do source authentication, why do group keys at
all? It's no better than a sturdy lock on an outhouse with no roof.
Please let's consider the cryptography rather than something that
doesn't actually provide an enforceable mechanism.
[AS] Again, I repeat the comments above. It is clear that if a
symmetric group key is used, then source authentication is no longer
possible. But, considering cryptography, it is possible to
authenticate group membership. Authentication of group membership is
sufficient for this use case. The main issues to weigh are: "The
greater likelihood of key compromise when the secret is shared by a
large number of identical and permanently installed nodes compared to
a similar single node" vs "The requirements of low latency communication".
You've stated your restrictions. I've stated my objections. I see
nothing at all new in the discussion since DICE.
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.
[AS] Agree. We are looking at various mitigation issues. The main ones
are: Ensure permissions are properly scoped so that compromise of
group key only results in little harm. Propose methods for recycling
group key. Ensure that devices use PKI to authenticate themselves
before receiving a group key. This list is clearly not complete and
would be great to receive more input as to how more mitigation is
possible.
You have locked on to one particular solution that will not work. Using
PKI to get symmetric group keys WILL NOT give you any protection.
(For a definition of cyber-physical - Wiki is pretty good -
https://en.wikipedia.org/wiki/Cyber-physical_system)
Cyber-physical system - Wikipedia, the free encyclopedia
<https://en.wikipedia.org/wiki/Cyber-physical_system>
en.wikipedia.org
A cyber-physical system (CPS) is a mechanism controlled or monitored
by computer-based algorithms. Examples of CPS include smart grid,
autonomous automobile systems, ...
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
________________________________________________________ The contents
of this e-mail and any attachments are confidential to the intended
recipient. They may not be disclosed to or used by or copied in any
way by anyone other than the intended recipient. If this e-mail is
received in error, please immediately notify the sender and delete the
e-mail and attached documents. Please note that neither the sender nor
the sender's company accept any responsibility for viruses and it is
your responsibility to scan or otherwise check this e-mail and any
attachments.
_______________________________________________
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace
