Protecting AppKey in deployed node

Hi all!
I am working on a commercial solution hopefully based on the RAK4270 module using AT commands.
How are commercial users protecting the AppKey in their end devices?

Currently, with the AT command firmware, it is fairly trivial to retrieve the LoRaWAN keys if ever an attacker gets physical access to the node (which is not impossible in the field).

How are you protecting yourselves from this?

Any help is appreciated. Thanks!

Mike

The DevEUI and App/JoinEUI’s aren’t hard coded to the module either.

There isn’t a whole heap you can realistically do apart from:

  • Send uplink if the case is opened to alert you to invalidate the keys
  • Small amount of Semtex to destroy the module
  • Large amount of Semtex in the case (this way you get the bad guy too)
  • Put the keys in to a secure key store chip and do some really messy coding to change them between transmissions

Primarily I think most of us do a risk analysis on what someone gains by stealing a device and reading the keys. If it’s of sufficient risk, we look at a solution that doesn’t make it quite as easy as an AT command!

One option is for you to use RUI to program the device and use a key store like the ATECC608B for the keys and patch out the relevant AT commands - now I’ve typed it, this seems like a really good idea, perhaps someone at RAK could develop this as using the online compiler can be a handful.

Thank you Nick!
The Semtex solutions sound a bit too extreme for me. :wink:
I will look into the RUI approach.

Maybe simply removing the AT commands that give access to the keys would be enough?

Thanks again!

LoRa Alliance is moving towards the usage of a secure chip then a join server. This way, you do not mess with the keys.

With RUI on the other hand, the easiest way is probably rename the AT commands. Even if someone opens your device and saw it as RAK4270, they can’t get your keys with standard AT commands

I am not sure if @nmcc is serious with Semtex approach. But that could be an analogy. Put a limit switch on the device. Once the device is opened, the limit switch will be open then you can probably modify your uplink payload. You can add a tamper flag/status on the payload so you can see if there’s tampering on the devices.

The Semtex was/is a pun on Semtech …

Love the renaming idea, bit close to security by obsfucation which isn’t the best of practise, but good enough for the casual hacker. The more determined one could read the device flash and dis-assemble the code, there are a raft of memory protection options and some issues arising. Again, it’s all about level of risk.

I have a few devices that have a microswitch that protrude out the back of the case so if it’s taken off the wall, it triggers immediately whilst it is still in location. You only need a case open switch if it can be opened whilst in-situ. No point using a case open switch if the device has been taken back to “lab”.