Whitepapers

LoRaWAN Security Whitepaper

Issue link: https://read.uberflip.com/i/1423199

Contents of this Issue

Navigation

Page 3 of 3

AppKey and the derived session keys are persistently stored on a LoRa Alliance™ device and their protection depends on the device physical security. If the device is subject to physical threats, keys can be protected in tamper resistant storage (a.k.a. Secure Element), where they will be extremely difficult to extract. The LoRa Alliance works towards ensuring its protocol and architecture specifications are secure, while recognizing that the overall security of the solution also depends on the specific implementation and deployment. Implementation security issues need to be taken up by the relevant manufacturers and deployment issues need to be taken up by the relevant network operators. These two types of issues are not specific to the LoRaWAN technology and usually equally applicable to any radio technology implemented on the same platforms/networks. PHYSICAL SECURITY OF A LoRaWAN™ DEVICE As AppSKey and NwkSKey are generated from the same AppKey, one could argue that if the LoRaWAN operator has the AppKey, it is able to derive the AppSKey and hence to decrypt the traffic. In order to avoid this situation, the server managing the AppKey storage, mutual SESSION KEY DISTRIBUTION IMPLEMENTATION AND DEPLOYMENT SECURITY The backend interfaces involve control and data signaling among network and application servers. HTTPS and VPN technologies are used for securing the communication among these critical infrastructure elements, much the same way done in any other telecom systems. BACKEND INTERFACES SECURITY Some sources claim that LoRaWAN™ cryptography only uses XOR and not AES. In fact, as already mentioned, AES is used in the standardised CTR mode which makes use of XOR crypto operations (as many other modes like CBC 5 ). This strengthens the AES algorithm by using a unique AES key for each block cipher. CRYPTOGRAPHY 1 AES - Advanced Encryption Standard. It is a public encryption algorithm based on symmetric secret keys, allowing message encryption and authentication. 2 CMAC - Cipher-based Message Authentication Code. 3 CTR - Counter Mode Encryption. It is a mode of operation of AES algorithm relying on a counter to encrypt streams of data. 4 AES-CMAC - Cipher-based Message Authentication Code using AES encryption algorithm to provide message integrity and authenticity. 5 CBC is a mode of operation of AES algorithm relying on an initialization vector and the previous data block to encrypt streams of data. The LoRa Alliance™ and LoRaWAN™ Marks and logos are trademarks of Semtech Corporation or its subsidiaries in the U.S. and/or other countries LoRaWAN™ Specification, v1.0.2, July 2016 LoRa Alliance™: www.lora-alliance.org media@lora-alliance.org AS SHOWN IN THIS PAPER, THE LoRaWAN™ SPECIFICATION HAS BEEN DESIGNED FROM THE ONSET WITH SECURITY AS AN ESSENTIAL ASPECT, PROVIDING STATE-OF-THE-ART SECURITY PROPERTIES FOR THE NEED OF HIGHLY-SCALABLE LOW POWER IOT NETWORKS. UNLIKE MANY OTHER IOT TECHNOLOGIES, IT ALREADY OFFERS DEDICATED END-TO- END ENCRYPTION TO APPLICATION PROVIDERS. SECURITY FACTS AND FALLACIES authentication and key derivation can be run by an entity outside the control of the operator. In order to give operators additional flexibility, a future release of the LoRaWAN specification (1.1) defines two independent master keys: one for the network (NwkKey) and one for the applications (AppKey).

Articles in this issue

view archives of Whitepapers - LoRaWAN Security Whitepaper