Side meeting: Security for 802.15.4 @ Summit

Community
1

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.

1 Like
2

My summary of how I see the roadmap:

  1. Solve the persistence issues, possibly together with the PSA topic
  2. Make the 802.15.4 security module get its numbers from there.

At this point, we fix https://github.com/RIOT-OS/RIOT/issues/16844 and get very minimal security at the level of WEP (shared key that doesn’t get changed, and is burnt into every device)

  1. Implement CoJP.

Now we can roll over network keys, and kick devices from the network.

  1. Implement EDHOC, get network keys with CoJP+EDHOC.

Now we don’t have to provision devices with knowledge of the network, but can enroll them by just handing their public key to the JRC.

Unless we use 6TiSCH at this point, we still need to use local persistence.

  1. Implement ACE-AUTHZ in addition.

Now the device can connect to a network even if it wasn’t told beforehand that this is the network to connect to.

  1. Do something for keys not shared across the network.

I don’t know which specs to use here, and don’t see a strong use case. (I’d use this if different devices have different quotas of outbound traffic or stuff like that, which is a weak case).

Personally, I’d be happy to get to 2 already.

3

chrysn via RIOT notifications@riot-os.org wrote: > 1. Solve the persistence issues, possibly together with the PSA > topic > 2. Make the 802.15.4 security module get its numbers from there.

>   At this point, we fix https://github.com/RIOT-OS/RIOT/issues/16844
> and get very minimal security at the level of WEP (shared key that
> doesn't get changed, and is burnt into every device)

I wasn’t thinking about such a step, but I totally agree it’s a good one. In particular, being able to burn in the 15wep key (a word I just made up) into to devices independently of the image you want to (debug) run is a great simplification of configuration errors vs coding errors.

> 3. Implement CoJP.
>
>   Now we can roll over network keys, and kick devices from the network.

CoJP lets you do initial onboarding to any network that knows the device’s long-term symmetric key. It’s more than just rolling over network keys.

> 4. Implement EDHOC, get network keys with CoJP+EDHOC.

>   Now we don't have to provision devices with knowledge of the network,
> but can enroll them by just handing their public key to the JRC.

This isn’t specified anywhere, but I guess it is a step we can consider but devices need to know what network they are going to join. So, i don’t think of this as a step :slight_smile:

> 5. Implement ACE-AUTHZ in addition.

>   Now the device can connect to a network even if it wasn't told
> beforehand that this is the network to connect to.

Yes.

> 100. Do something for keys not shared across the network.

> I don't know which specs to use here, and don't see a strong use
> case. (I'd use this if different devices have different quotas of
> outbound traffic or stuff like that, which is a weak case).

This involves some kind of per-peer-pair key agreement algorithm. It makes sense to use EDHOC for that, but that will require some IEEE-level “IANA” action, and a document somewhere.

1 Like
4

This involves some kind of per-peer-pair key agreement algorithm. It makes sense to use EDHOC for that, but that will require some IEEE-level “IANA” action, and a document somewhere.

Using more than one key on 802.15.4 would not necessarily mean peer-to-peer stuff. In networks in which all traffic goes through the 6LBR, each node could get its own key (as there is no need for nodes to read each other’s messages; the 6LBR will re-encrypt them for the recipient), or there could be one key used just between 6LBR and the node.

Peer-to-peer key negotiation would be a step beyond that. (But I don’t think that there’s any urgency to either version, which is why I numbered this 100).

5

You’ve describe a 1-hop deep mesh with a very capable 6LBR, or some kind of mesh-under network. I would love to know more about this, but I agree… step 100 :slight_smile: