Secure implementations with RN2483 and ATAES132A security IC?

[kersing (Jac Kersing)]

Peter,

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.

@pmb_nl

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?

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.