Are there already implementations of the RN2483 in combination with a security IC (like Atmel ATAES132A) that takes care of keys storage, mutual authentication, encryption & decryption handling? Or are there other good secure alternatives?
I’ve read the LoRa security guide from Mwr Labs, their YouTube video and the security video from and the security webinar from Johan Stokking that sparked my interest to find good secure implementations of LoRaWAN solutions.
Especially to ensure the identity on both sides and the prevent possible altering of sensor values.
I was surprised how minimal the Google hits are on this topic and the use of security ICs what can be interesting for sensor solutions in public places.
I’m using the Microchip/Atmel ATECC508A crypto authentication chip in a number of projects, primarily for key storage and configuration authentication. The problem with using these to sign sensor data is that it adds a considerable number of bytes to the payload hence the reason I’ve found it more useful in the provisioning and configuration of the devices.
Thanks for the fast response!
Sounds interesting, can you share some (anonymized) code sample or guidance on the use?
Are you using the Atmel C library of the chip?
I’m also interested what you mean by configuration authentication.
My idea/hope was that the ATAES132A IC could be used to handle the AES128 encryption & decryption and for computing the Message Integrity Code (MIC) to avoid tampering of the data/payload that already is part of the LoRaWAN protocol. Mutual identity check is also taken care of by the protocol?
I was curious why the payload increases, is that by the fact that you perform asymmetric payload encryption above the LoRaWAN stack or …?
For the RN2483 to function it requires the LoRaWAN keys to be programmed into it either at run time or during setup. In both cases storing the keys in a secure storage does not help. When initializing the module at run time transfer of the keys to the RN2483 is in plain text, so anyone with access to the device can listen in using hardware available for a couple of euros.
Storing the keys during setup is safer, it’s not possible to query the device for the encryption keys, but anyone determined to access the keys can attempt to disassemble the module and access the information stored in the controller and the external store.
So the only (in my opinion) useful application of the security chip would be to use it to sign/encrypt the data before sending it to the module (where LoRaWAN stack will encrypt it again) resulting in additional payload bytes.
The RN2483 provides only the unencrypted data to the ‘user’. The headers required for your idea are not part of the accessible data. You could probably use an RFM95 with the LMIC stack (needs modifications) for your idea.
Best regards,
Jac
Mutual identity check is done using encyption. The two partners of the conversation are (should be) the only ones with the keys required to encrypt/decrypt and verify the validity of the LoRaWAN packet.
Thanks Jac,the challenge is getting more clear to me.
I realize that the fact that the RN2483 uses high level commands and acts as a “black box” for LoRaWAN communications makes the move of related AES encryption & decryption code to a secure IC impossible.
Storing keys during setup before deployment in the field sounds saver.
If an encryption layer is used on top of LoRaWAN stack, what whould you suggest for the following situation?
large number of nodes, use in public area, where maintainability and cost is a factor
key risks with data integrity and identities, low data volumes & low communication frequencies
If this encryption takes place with a security IC and keys inside IC, where do you see the risks that someone could hack a security chip that is made for this purpose? Both code and keys & random number generator are all in the chip.
Does such chip wipe its secrets when it loses power? If not, then anyone who can read the LoRaWAN secrets (by having physical access to the device) could also take the chip and use it?
As always the question is the level of protection required. A determined opponent will find a way into the product given time, hardware and target nodes. The chips have an impressive number of options to protect against tampering, using all of them correctly to get the highest level of security will be one of the biggest challenges. (Implementing security algorithms correctly is where most coders go wrong, I think this holds for interfacing with security hardware as well)
An obvious attack point for me would not be the security chip but the sensor and controller communicating with it. Why bother going for the difficult part when other components can be manipulated. For instance a temperature sensor could be replaced by a controller implementing the same interface making the controller assume it is talking to the sensor while you are feeding it random values.
Another obvious hack would be to start a DoS attack by simply triggering the protection mechanisms of the chip rendering the node in-operational, incurring large costs to replace/repair (if you can be bothered)
I was talking about signing the data - please read responses properly.
When you sign the data using your private key you also need to include the generated digital signature. In the case of the ATECC508A, this can be 64 bytes (need to double check exact size).
I’m using the chip to generate the application key as part of the device provisioning process.
@andrewl
Do you know where we can have “real life” sample code using ATECC508A to store keys ?
Anyway, would it be “unsafe” to store session keys (retrieved after 1st join) in this chip to avoid rejoin proccess ? Of course doing a full join sometime (ie once a week) ?
There is no need to join every week. If you send some data a couple of times every week the keys will stay valid. (You could use a confirmed transmit a couple of times a week to check if the keys are still valid)
Joining too often will only increase the chances of duplicate nonces…
Guys, thanks,
But in this case, what happens if backend reset or any events expire keys (server crash or whatever) ?
does LMIC send will detect and try a rejoin or do I need to check in my application ?
It’s just for this case I wanted to do join again sometime.
Any way, any option to “know” when keys are not valid anymore ?
What scenarios would such an additional security chip prevent? Preventing possible altering of sensor values is a bit vague to me. Could you please give a few actual examples including how such a chip could prevent it?
The things like hardware tampering are like jac also mentions still possible I believe. Is reverse engineering of arduino firmware a realistic thing to fear?
