Trust&GO LoRa® Secure Authentication with the ATECC608B Secure Element

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

How Does the Join Server Service Work?

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.

What Is the Value of a Configured and Provisioned Secure Element for LoRa-Based Systems?

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:

• How will you get started with securely provisioning authentication keys in secured storage?
• How will you to develop, deploy and manage a join server on the LoRaWAN network?
• How will you make sure the keys of the join server and the ones in the edge node match?
• How will you avoid the keys leaking throughout the whole process?
• How will you distribute shared keys securely?
• How will you manufacture thousands of devices with a different key in each system?

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:

• How will you implement a secure environment to handle millions of your shared keys between your join server provider, the site where keys are provisioned and across your complete supply chain—including your semiconductor vendor, distribution partner, design house and ODM—to finally arrive at the OEM?

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:

1. Purchase the secure elements
2. Open a join server account and activate it
3. Claim the batch of secure elements to your join server account
4. Start coding your application without the design burden of securing your authentication

Why Is Secure Hardware Key Storage So Important?

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.

What Do You Really Get with This Configured and Provisioned ATECC608B for LoRaWAN-Connected Applications?

All ATECC608B-TNGLORA or ATECC608B-TNGACT secure elements provide:

• An already defined and configured memory zone within the secure element with all the agreed policies necessary to work with the TTI (ATECC608B-TNGLORA) or Actility (ATECC608B-TNGACT) join server and the LoRaWAN authentication protocol. More precisely, these secure elements are configured for authentication, rekeying and secure boot use cases.
• Already-provisioned keys for network servers and application servers. Both authentication keys are used to connect to the network and application LoRa server of your choice. TTI and Actility offer both network and application server services, but their join servers are agnostic of the network server and application server.