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.
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.