LoRaWAN™ SECURITY FULL END–TO–END FOR IoT APPLICATION PROVIDERS

A WHITE PAPER PREPARED FOR THE LoRa ALLIANCE™ BY GEMALTO, ACTILITY AND SEMTECH February 2017 INTRODUCTION

LoRaWAN™ is a Low Power Wide Area Network (LPWAN) pro- As security is a fundamental need in all of the aforementioned tocol that supports low-cost, mobile, and secure bi-directional applications, it has been designed into the LoRaWAN communication for Internet of Things (IoT), machine-to-machine specification from the very beginning. However, the topic of (M2M), smart city, and industrial applications. The LoRaWAN security encompasses multiple properties and, in particular, protocol is optimized for low power consumption and is the cryptographic mechanisms used to implement security in designed to support large networks with millions of devices. LoRaWAN deserve careful explanation. This whitepaper aims Innovative LoRaWAN features include support for redundant to present the security of the current LoRaWAN specification. operation, geolocation, low-cost, and low-power applications. First, we will present the security properties embodied in the Devices can even run on energy harvesting technologies LoRaWAN specifications, then details of its implementation and enabling the mobility and ease of use of IoT. finally some explanations about LoRaWAN security design. PROPERTIES OF LoRaWAN™ SECURITY LoRaWAN security is designed to fit the the LoRaWAN network as part of the payloads exchanged between the general LoRaWAN design criteria: low network join procedure. This ensures end-devices and application servers. power consumption, low implementation that only genuine and authorized devices LoRaWAN is one of the few IoT networks complexity, low cost and high scalability. will be joined to genuine and authentic implementing end-to-end encryption. In As devices are deployed in the field networks. some traditional cellular networks, the for long periods of time (years), LoRaWAN MAC and application traffic is encrypted over the air interface, security must be future-proof. The messaging are origin authenticated, but it is transported as plain text in the LoRaWAN security design adheres integrity protected, replay protected, and operator’s core network. Consequently, to state-of-the-art principles: use of encrypted. This protection, combined end users are burdened by selecting, standard, well-vetted algorithms, and with mutual , ensures that deploying and managing an additional end-to-end security. Later, we describe network traffic has not been altered, is security layer (generally implemented by the fundamental properties that are coming from a legitimate device, is not some type of VPN or application layer supported in LoRaWAN security: mutual comprehensible to eavesdroppers and encryption security such as TLS). authentication, integrity protection and has not been captured and replayed by This approach is not suited in LPWANs confidentiality. rogue actors. where over-the-top security layers Mutual authentication is established LoRaWAN security further implements add considerable additional power between a LoRaWAN end-device and end-to-end encryption for application consumption, complexity and cost. SECURITY IMPLEMENTATION The security mechanisms mentioned networks. LoRaWAN security uses the which are used during the device authen- previously rely on the well-tested AES cryptographic primitive combined tication process. Allocation of EUI-64 and standardized AES1 cryptographic with several modes of operation: CMAC2 identifiers require the assignor to have an algorithms. These algorithms have been for integrity protection and CTR3 for Organizationally Unique Identifier (OUI) analysed by the cryptographic community encryption. Each LoRaWAN device is from the IEEE Registration Authority. Sim- for many years, are NIST approved and personalized with a unique 128 bit AES ilarly, LoRaWAN networks are identified widely adopted as a best security key (called AppKey) and a globally unique by a 24-bit globally unique identifier practice for constrained nodes and identifier (EUI-64-based DevEUI), both of assigned by the LoRa Alliance™. SECURING APPLICATION PAYLOADS

LoRaWAN™ application payloads are always encrypted end-to-end between the end-device and the application server. Integrity protection is provided in a hop-by-hop nature: one hop over the air through the integrity protection provided by LoRaWAN protocol and the other hop between the network and application server by using secure transport solutions such as HTTPS and VPNs.

MUTUAL AUTHENTICATION

The Over-the-Air Activation (a.k.a. Join are then derived, one for providing integ- order to prove/verify the packets authen- Procedure) proves that both the end de- rity protection and encryption of the ticity and integrity. The AppSKey is dis- vice and the network have the knowl- LoRaWAN MAC commands and appli- tributed to the application server in order edge of the AppKey. This proof is made cation payload (the NwkSKey), and one to encrypt/decrypt the application pay- by an AES-CMAC4 (using the for end-to-end encryption of application load. AppKey and AppSKey can be hidden AppKey) on the device’s join request and payload (the AppSKey). The NwkSKey is from the network operator so that it is not by the backend receiver. Two session keys distributed to the LoRaWAN network in able to decrypt the application payloads.

LoRaWAN™ AppSKey NwkSKey SECURITY Join Server

Network Security

Application Security

Device Devices Gateways LoRaWAN™ Application Manufacturers Network Server Servers

DATA INTEGRITY AND CONFIDENTIALITY PROTECTION Header/ MAC Header Payload MIC Counter All LoRaWAN traffic is protected using the two session keys. Each payload is encrypted by AES-CTR and carries a frame counter (to avoid packet replay) and a Message Integrity Code (MIC) com- Encryped with AppSKey puted with AES-CMAC (to avoid packet tampering). See beside the structure of a LoRaWAN packet and its protection: Compute MIC with NwkSKey SECURITY FACTS AND FALLACIES

PHYSICAL SECURITY authentication and key derivation can IMPLEMENTATION OF A LoRaWAN™ DEVICE be run by an entity outside the control of AND DEPLOYMENT SECURITY the operator. In order to give operators AppKey and the derived session keys are additional flexibility, a future release of The LoRa Alliance works towards persistently stored on a LoRa Alliance™ the LoRaWAN specification (1.1) defines ensuring its protocol and architecture device and their protection depends on two independent master keys: one for specifications are secure, while the device physical security. If the device the network (NwkKey) and one for the recognizing that the overall security is subject to physical threats, keys can applications (AppKey). of the solution also depends on the be protected in tamper resistant storage specific implementation and deployment. (a.k.a. Secure Element), where they will BACKEND INTERFACES SECURITY Implementation security issues be extremely difficult to extract. need to be taken up by the relevant The backend interfaces involve control manufacturers and deployment issues CRYPTOGRAPHY and data signaling among network and need to be taken up by the relevant application servers. HTTPS and VPN network operators. These two types of Some sources claim that LoRaWAN™ technologies are used for securing the issues are not specific to the LoRaWAN cryptography only uses XOR and not communication among these critical technology and usually equally applicable AES. In fact, as already mentioned, infrastructure elements, much the same to any radio technology implemented on AES is used in the standardised CTR way done in any other telecom systems. the same platforms/networks. mode which makes use of XOR crypto operations (as many other modes like CBC5). This strengthens the AES algorithm by using a unique AES key AS SHOWN IN THIS PAPER, THE LoRaWAN™ SPECIFICATION for each block cipher. 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 SESSION KEY DISTRIBUTION LOW POWER IOT NETWORKS. UNLIKE MANY OTHER IOT TECHNOLOGIES, IT ALREADY OFFERS DEDICATED END-TO- As AppSKey and NwkSKey are generated END ENCRYPTION TO APPLICATION PROVIDERS. from the same AppKey, one could argue that if the LoRaWAN operator has the AppKey, it is able to derive the AppSKey LoRaWAN™ Specification, v1.0.2, July 2016 and hence to decrypt the traffic. In LoRa Alliance™: www.lora-alliance.org order to avoid this situation, the server [email protected] managing the AppKey storage, mutual

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