There was a side meeting on 802.15.4 security today at the summit; here are some notes taken during that:
RIOT summit 2022: 802.15.4 security
Koen: Two issues with 802.15.4 – neighbor might be sniffing, and might be injecting data. There is link layer security, but key management is out of scope. We can fix something here to get working and up-and-running security. I’d like to keep this simple. OpenThread has something, but I’d prefer simple, native and low-layer. Not talking about same symmetric key on all devices, but that’s not the solution as it’s just obfuscating.
Kaspar: Is there an open standard?
MCR: Yes, RFC9031, 6TiSCH minimal security. Nothing 6TiSCH dependent. One round-trip of OSCORE. You have to flash a unique key per device, and there is a limit to how that scales, and there is JRC (key server) that has copies to answer. Results in communication of a per-network symmetric key, like WPA-PSK.
?: First step is how to configure such a key at runtime.
Koen: Had a session on that. Let’s start from assumption that some key is present.
?: Problem starts because we don’t have 15.4 impl. We can send frames, but missing 15.4. It’s like WiFi without Gateway but just internal network. Don’t need to impleent this ourselves.
MCR: 802.15.9 now part of .4 has every single kind of security in, but nothing at all on provisioning keys. AFAIK we have all code we need; we miss part of the spec but these are stupid.
chrysn: Disagree with assessment that CoJP (6TiSCH minimal security) is independent of TSCH. It does use ASNs.
José: I wouldn’t rule out OpenThread because it’s way easier to configure than GNRC. There is an existing border router compatible with others. What we miss is socket layer. Everything else is free there.
Kaspar: OpenThread is an implementation of the Thead standard, and that’s not open.
José: But it’s based on standards, RFCs and some expired drafts. Kind of uses standard stuff.
MCR: It uses crypto layers that …?
Oleg: Key provisioning is defined in thread, and that’s not open.
José: Not sure.
Oleg: Agree that OpenThread is one way, but also want solution for GNRC.
Koen: At this point I’d be happy with anything based on IETF standards. Not necessarily full thing in terms of provisioning, but having something that works and converges to IETF standards. Get keys on devices and continue from there.
José: So we just look for key provisioning to existing security module?
Koen: Yes. If we can bolt anything on top of what we have, it’s good.
MCR: There is an RFC that does right that from a symmetric key. If you want an asymmetric key, there’s a draft that says how to do that. The draft is 4y old because depends on EDHOC. Good analysis on it. It’s very scalable. Just needs to be implemented.
MCR on chrysn’s point on ASN: Yes there are pieces that do that. In 6TiSCH ASN is monotonic and provdies nonce. In GNRC and Thread, we don’t use that mode. We use a different mode where nonce is created per node, MAC address goes in. So some 6TiSCH things are there.
chrysn: So the device still needs to keep track of a counter, that won’t wrap unless the MAC address is retired or the network key is retired.
José: There are still things like commissioning, low power mode etc. in OpenThread, and these are critical for us. We don’t implement the right features to have that, eg. indirect transmission but we don’t have support for that. It gives even better power efficiency than TSCH. It’s not hard and we still don’t have it.
MCR: i dont see that it is mutually exclusive with adding security, and doesn’t interdepend.
José: Right, it’s a detour.
José: Thread is an option for users, but what I’m getting at here is that we’re missing core features of 802.15.4 (which Thread may have) for low power.
Koen: So you want more parts of 802.15.4 implemented?
José: Yes, esp. before we do custom stuff.
Next steps
Meeting with input from MCR and chrysn for the purpose of crypto sanity checks.
