Kris Pister writes: > > Actually no. I think EBs are actually very good and cheap way to keep > > up in sync in network. The only thing required from them in that case > > is that they have real key protecting them (i.e. no well-known keys). > > Now this *is* a real mistake, and provides a false sense of security. > If multiple vendors need to ship products that have a secret key in > firmware, that key will not remain secret for long. If you depend on > it for security, that's a false sense of security.
Yes, thats why I am against well-known keys. Keys in RFC == well-known keys. Keys in firmware == well-known keys. Pre-configured keys == keys configured during the deployment or installation process to the devices using some out of band method. Keys shared among peers == pairwise keys configured during the deployment, or installation process to the devices using some out of band method. Or they can also be created during the initial bootstrapping process, i.e. when the device is first booted up, it might create pairwise key with some entity in the network, store that in stable storage and use that from that on. Keys generated using KMP == keys created during the bootstrap procedure using KMP. Those keys can either be network wide keys (K1, K2) or they can be peerwise keys. > If the key is generated randomly for each network, that's fine, but > then how do the new nodes join? What is the problem with joining? The K1 is used to integrity protect the EB. The joining node is able to parse EB even when it does not have the key, and can extract the information need for joining from there. The joining node will contact to the joining coordinator entity with security level 0, i.e. no encryption, no mic, and JCE will do the authentication and authorization of the JN using methods we are talking here. One of those methods could be that the JN uses 802.15.9 with suitable KMP and created pairwise key between JN and JCE. This key is used for the rest of the process. As the security of well-known K1 == no security, it does not matter whether the JN uses no security or whether it uses well-known K1. > Either they get programmed with the randomly generated key for the > particular network that they want to join (which is not an > acceptable solution to most end users) or they don't rely on a > secret key during the joining phase. This is no different with well-know K1. With well-known K1 the JN do not rely on secret key during the joining process. The joining process needs to be such process that it works without relying on the security of K1. > Once through the joining phase they get one or more L2 keys that are > random and secret for that network. Yes. > If you want to beacon with that key to maintain sync, fine. But > don't think that your global EB PSK is going to remain secret - it > won't. Depends what you mean by global EB PSK. If you mean randomly generated K1 which is rekeyed every now and then, and distributed only to the authenticated members of the network, then it will stay secret, unless you have attackers inside your network. If they are part of your network, then any network wide keys is unsafe. I myself think that network wide keys are bad idea, but for EBs they work well enough. For all other traffic you should use pairwise keys... -- [email protected] _______________________________________________ 6tisch mailing list [email protected] https://www.ietf.org/mailman/listinfo/6tisch
