________________________________ 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. [AS] But this is also the case when we have two entities. The receiver has no way of knowing whether the other entity is compromised. You are simply stating my point 3 below again here. It is more likely that a group key is stolen. 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. [AS] Again this applies to the two entity case. If we cannot enforce responsible behaviour on the senders then having crypto makes no sense. 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. [AS] Again, this is the case with the single sender. The only issue goes back to greater likelihood of stealing a key that is shared between multiple senders. 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. [AS] You are assuming an independent probability distribution in this calculation - if the probability of key compromise from one device is p then the probability of key compromise from N devices is clearly greater than p but it is only equal to your formula in a theoretic world of independent distributions. Now if we have N identical devices in a building, I do not know what this number is but without proper experimentation there is no way to determine this number. 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. [AS] Agree. The probability approaches unity that someone will figure out how to hack any give product assuming that product is wide spread (cf Philips lightbulbs). [AS] Agree. But you are saying here the p goes to 1 in your formula. So we get to the situation of no difference between the group key vs pairwise keys because (1-p ~= (1 - (1-p)^N). 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). [AS] The original figure of merit of 200ms is still valid. However, not all of these 200 ms are available for crypto. It is difficult to come up with an exact number for how much is available for crypto because this really depends on the number of hops in the mesh and also whether or not a controller is present as an intermediate step between sensor and actuator. The 50-100ms I provided is already very generous from an application point of view - which we understand quite will. 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) [AS] I do not know of any special purpose hardware that does this at the cost levels we need. We are already using ECDSA capable hardware in our development because we use asymmetric crypto for almost everything other than to turn light on/off (e.g. to configure/commission the system). The best parts we have seen offer us about 200 ms for sing+verify. The links you provided do not tell me what hardware parts you are proposing we use. [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. ________________________________________________________ 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
