We’ve been doing some work behind the scenes on the LMIC, and I’d like to give everyone an idea of what we’re working on. (That’s a big reason for setting up this forum.)
Secure Element Support
This has been developed on the innocent-sounding branch devel-issu578. We have refactored all the cryptographic support so that the LMIC can work with “secure elements”, by separating the implementation (and some of the policy) from the LoRaWAN protocol layer.
We’re doing this in anticipation of requirements like ETSI 303 645, which will raise consumer’s consciousness about the need for secure elements in IoT devices.
The secure-element architecture uses a new ‘lmic/se’ API plus “drivers” that implement the API.
We’ve done the following drivers:
-
“
se/drivers/default”. A driver that just implements the 3.2 LMIC secure element implementation in the new framework. The default secure element doesn’t add any security to the LMIC; it is just a refactoring of the base LMIC to move the crypto code to a new module. -
“
se/drivers/to-protect”: A driver that uses the Trusted Objects “TO-Protect” software secure element. The reference implementation targets STM32L0 devices, and includes constant-time crypto and obfuscation to provide a level of security that is intermediate between hardware secure elements and the default secure element.(We just got the go-ahead from Trusted Objects to merge that support into the the branch on 2020-12-04, so expect that to appear by 2020-12-11, depending on MCCI’s workload.)
The architecture is intended to support hardware secure elements as well. The Trusted Object architecture is probably the most restrictive architecture because it embeds the most LoRaWAN knowledge; it should be easy to support secure elements from Microchip and ST as well. We’d be happy to help people who want to experiment.
Doxygen Documentation
As part of doing the architecture for the refactoring for secure elements, had to document the APIs. Did this with a combination of tools, primarily Plantower UML and Doxygen. Once the secure element branch is merged, we plan to extend this.
When and how
I’ve been hesitant to merge this branch because it increases the code size a little bit. It’s only a few hundred bytes bigger, but on small devices, that’s significant. It appears that we still pass CI testing for all the targeted devices (including Atmel devices), but it would be good to get feedback.
It seems likely that we’ll merge this on to the main branch in December 2020.
Consequences
The architecture of the provisioning scheme (i.e., how we load keys into the devices) for the original LMIC doesn’t fit very well with secure elements. MCCI has wrappers for the LMIC that move the keys out of the code, but the examples still follow the original way of doing things. This is becoming more and more awkward to support. I would like to change to a mechanism more like that used by the Things Network Arduino library, where the client code pushes keys in during initialization. However, if done cleanly, this would be a breaking change. It’s possible that we can deprecate the old style in (hypothetical) V4 and then remove in V5.
Feedback and comments are welcome…
–Terry