When it comes to LoRa security, provisioning and storing network server and application server keys is as important as it is complex due to the nature of the shared key authentication model. Because of this, you will face three main challenges when implementing secure authentication on a LoRaWAN network:
To overcome these challenges, you can strengthen the authentication process by implementing a secure hardened key storage both at the node and in the LoRaWAN backend. This prevents the exposure of authentication keys to software, firmware, manufacturing sites, end users and other third parties. Our secure elements—ATECC608B-TNGLORA for The Things Industries (TTI) and ATECC608B-TNGACT for Actility—are pre-provisioned with the corresponding authentication keys and provide a JIL “high” rated secure key storage to isolate keys in the nodes. This is especially valuable in LoRa systems that are based on a shared key security model and leverage a wide variety of traditional low-power microcontrollers.
To make adding secure elements to your design easier, the devices are paired with the join server services of either The Things Industries (TTI) or Actility for turnkey secure authentication. The corresponding AES128 authentication keys are also hosted and protected in their managed join servers. Through a claim procedure available via TTI’s or Actility’s web portal, the protected keys in the secure element are claimed and then owned by the company. This process simplifies the cumbersome and unsecure provisioning practice used without secure key storage. The join server is completely agnostic to the network server and/or application server providers to preserve business scalability, offering you freedom of choice in your architecture. Flexibility doesn’t stop here though. The secure element is a microcontroller-agnostic solution that adds hardware secure key storage to any LoRa-connected products.
|Product||Provisioning||Algorithm Type||Density||Interface Type||Temp (C)|
|ATECC608B-TCSM||TrustCUSTOM||ECC-P256 (ECDH and ECDSA), SHA256, AES128-GCM||10.5Kb||Single-wire; I2C||-40 to 85|
|ATECC608B-TFLXTLS||TrustFLEX||ECC P256 (ECDH and ECDSA), SHA256, AES-GCM||10.5Kb||Single-wire; I2C||-40 to 85|
|ATECC608B-TNGTLS||Trust&GO||ECC-P256 (ECDH and ECDSA), SHA256, AES128-GCM||10.5Kb||Single-wire; I2C||-40 to 85|
|ATSHA204A-TCSM||TrustCUSTOM||SHA256||4.5Kb||Single-wire; I2C||-40 to 85|
Credentials: Identity verification tools or methods that include X.509 certificates, generic certificates for thumbprint authentication, keys and data packets
Customization: The action of creating a unique device/system through its configuration and set of secrets
Firmware Verification: When a key and cryptographic operation are used to verify a signed image on a device at boot up or during run time
IP Protection: When a key and a cryptographic operation are used to verify signed (or hashed) firmware that is considered Intellectual Property (IP) of a product
Key(s): A set of binary numbers that is used to trigger a cryptographic algorithm that implements asymmetric or symmetric encryption
Over-the-Air (OTA) Verification: When a key and a cryptographic operation are used to verify a signed image that has been loaded into a connected device by a push notification from a cloud service
PKI: Public Key Infrastructure
Provisioning: The action of generating a credential into an embedded storage area
Thumbprint Certificate: An X.509 certificate not issued by a certificate authority that is used for authentication to the cloud
The architecture of TTI’s or Actility’s join server services makes securing LoRaWAN connections both easy and portable. Their services are network server agnostic and application server agnostic, enabling you to protect your connection from anywhere at any time. Once a device identifies itself to join a LoRaWAN network, the network contacts the join server to verify that the identity comes from a trusted device and not a fraudulent one. The derived session keys are then sent securely to your network server and application server of choice. The join server supports any LoRaWAN network, from commercially operated networks to private networks built on open-source components.
We have also partnered with TTI and Actility to make the onboarding process of LoRaWAN devices seamless and secure. LoRaWAN device identities protected in the secure element are claimed by the join server provider with minimal intervention, eliminating the need for you to have expertise in security or add unnecessary supply chain costs. You can choose any LoRaWAN network and migrate to any other LoRaWAN join server by rekeying the device. This means that there is no vendor lock-in and you have full control over where and how the device keys are stored.
Without a simplified onboarding process, such as the one provided by Microchip and TTI or Actility, the procedure to provision the authentication keys is not only complex but also unsecure. The handling of AES keys is particularly sensitive. You will need to be aware of the security risks associated with the deployment and management of a shared key model, not only in your hardware, but across all the stacks of the LoRa network. This includes the cloud backend architecture and all the steps involved in going from prototyping to production at a global scale.
During your prototyping and development phases, the first complexity will be selecting a technology provider in the segmented LoRa industry. Security, a well-known gap, needs to be added, significantly increasing the complexity of your design. Here are some questions you will need to answer:
Assuming these questions have been answered and you have designed in the necessary requirements, as you move onto production you will face the next question:
To simplify the onboarding and logistics process, our bundled solution provides simple-to-use yet robust security foundations for developing LoRa products. Here are the basic steps you need to follow:
Security is often mistaken to mean just encryption. While encryption is an important aspect of security, encryption alone doesn’t solve all security needs. Encrypting and storing a key in a standard memory does not mean that a system is secure since firmware and software bugs are a natural part of coding and will always exist. There is another considerable attack surface to consider too. During the manufacturing process, keys and other cryptographic assets can be exposed to employees and equipment. All these backdoors can be exploited to spoof a key and inflict malicious actions on a device or system.
When you use an ATECC608B secure element combined with our provisioning service, you can isolate your keys from software, firmware, manufacturing, third-party companies and users. This solution also simplifies and reduces the cost and complexity of your supply chain by leveraging Microchip’s provisioning service.
The secure element is equipped with active anti-tampering protections as well as side-attack channel protections. All of the cryptographic functions involved with the key are in the same secure boundary as the secure element. This architecture can be used with any microprocessor or microcontroller to reduce backdoors to keys, providing a very affordable means of implementing a high grade of security. The ATECC608B secure element has been rated JIL “high” demonstrating its high robustness in protecting keys.
All ATECC608B-TNGLORA or ATECC608B-TNGACT secure elements provide:
Manipulating application and network server keys is not only a daunting process but also opens backdoors in LoRaWAN™ connected products. In this workshop recorded at The Things Conference 2019, you’ll find out how to use Microchip’s secure element to build a secure provision workflow and strengthen authentication to The Things Industry’s (TTI’s) join server.
In this archived Livestream event, our security experts discuss how to easily develop a LoRa-connected device with secure authentication using our robust, yet simple-to-use, hardware-based security solution using our ATECC608B secure element, SAM R34 radio and The Things Industries (TTI) join server.