Facilitating IoT provisioning at scale

Article By : Richard Elberger

Whether you’re looking to design a new device or retrofitting an existing device for the IoT, you will need to consider IoT provisioning which brings IoT...

Whether you’re looking to design a new device or retrofitting an existing device for the IoT, you will need to consider IoT provisioning which brings IoT devices online to cloud services.  IoT provisioning design requires decisions to be made that impact user experience and security for both network commissioning and credential provisioning mechanisms which configure digital identities, cloud end-points, and network credentials so that devices can securely connect to the cloud.

To perform IoT provisioning at scale, customers often build and maintain custom-built tools and software applications that can push required credentials over protocols supported by their devices that spans multiple problem domains.  The IoT provisioning domains include:

• Network commissioning, which provides mechanisms for customers to define context specific parameters;
• Credential provisioning, which assigns credentials and configuration to physical devices; and
• Cloud provisioning, which sets the cloud-side configuration data that enables authentication, authorization, and device management.

All three of these provisioning domains must work in harmony for a spectacular customer user experience.

For example, a mobile operator provisions configuration data and policy settings when a mobile phone user connects for the first time. This is a simple and well-understood process that does not take much time for the mobile device user where the SIM card represents device identity. The situation becomes very different and challenging for customers, especially original equipment manufacturers (OEMs), who try to provision millions of IoT devices.

Throughout this article, you will be able to learn how to avoid or mitigate the risks associated with your own IoT deployment as well as understand, through brief examples, how an IoT service provided through cloud platforms like Amazon Web Services (AWS) helps you achieve your IoT provisioning goals.

Approaches to network commissioning when the need arises

Eventually, your IoT device connects to and communicates with a central service that is the hub of your IoT solution.  To reach that hub, your IoT device must join a networked medium.  The medium can be a hard wire, like Ethernet, or radio transmission, like Wi-Fi.  Depending on the medium, you need a human to tell the device what medium it must join to succeed in reaching the hub.  For example, with cellular you won’t need to tell the device the network to join because this has been defined by the SIM card. On the other hand, to join a Wi-Fi network, you will need to know the Wi-Fi Access Point name and password and be able to tell the device these details.  We will focus on the devices requiring configuration to join a network.

There are several different mechanisms customers have been using to join IoT networks.  Most everyone has a smartphone today and most every smartphone has Bluetooth, so configuration over Bluetooth has become pervasive.  However, that’s not the only means to getting connected. Some Wi-Fi modules on IoT devices are smart enough to become access points in their own right, where you can develop a simple webpage that allows users to input the larger network’s configuration.  For non-consumer devices, it’s still common to configure over serial or microSD.  Bluetooth configuration with the help of a smartphone application has become the norm. These smartphone apps can also give an assist to device cloud provisioning which you will discover later on in this article.

Approaches to device credential provisioning at scale

Device credential provisioning processes continue to be a highly fragmented across the industry with no line of sight for convergence anytime soon.  Most IoT centralized systems strongly suggest, or require, a Transport Layer Security (TLS) 1.2 connection for encrypted transport, which is more recently, and perhaps eloquently, known as encryption in transit.  Today, most IoT deployments use Public Key Infrastructure (PKI) so the rest of this article assumes the use of PKI.  In any case, it is imperative that each device owns its own unique identifying Private Key and Certificate.

To create a session with a cloud (or service endpoint), TLS 1.2 requires a Private Key and an x.509 certificate (or credential). Note: Some techniques such as Java Web Tokens, or JWT, have similar challenges but will not be discussed here. The Private Key, which is like your DNA, should only be known to an individual device which means it must not be shared with other devices. The x.509 certificate, which is like a driver’s license, is issued by a verifiable Certificate Authority (CA) by providing a Certificate Signing Request (CSR).  Delivering a CSR is not too dissimilar from handing your country’s passport-issuing entity your birth certificate with a fingerprint and proof of other passed tests as proof to receive a passport. Throughout this article, we refer to the x.509 certificate as a credential, with the assumption that the device has a unique Private Key.

The details of TLS 1.2 is beyond the scope of this article, but we will just give you enough information to be a bit informed so you can understand why it is imperative that the device protects the Private Key.  During the TLS 1.2 connection process, a series of exchanges occur to prove that the device is the owner of the Private Key that is its identity.  Your device must prove that it is the real owner of the x.509 certificate that it is trying to use for authentication.  In order for the IoT service to trust a device credential when your device connects, you need to have that Private Key on hand.  Now you can realize that if a bad actor got a hold of that key, the security model falls apart. At all costs, protect the keys to your IoT castle!

Like most who are deploying the IoT, you must make decisions about how to provision these credentials at scale.  To briefly review, each device must have:

• A unique, immutable Private Key representing the device. Ideally, to protect against side-by-side and other advanced attacks, the Private Key should be physically protected and not loadable into main program memory.
• A credential, relating to your application or IoT service.

Logistics differ among choices for Private Key and credential provisioning, some which are disjoint from cloud provisioning and others that rely on cloud provisioning.

• Integrated circuit security modules (which usually have cryptographic capabilities), either standalone or participating in a System-In-Package (SiP), System-On-Module (SoM), or System-On-Chip (SoC) design, having one of the following behaviors:

• • A security module having a manually provisioned or self-generating Private Key, or root of trust.
  • In addition to the previous item, the security module provides credentials in the form of pre-provisioned x.509 certificates.

• Subscriber Identity Module (SIM), embedded-SIM (eSIM), and integrated SIM (iSIM) technologies provide hardware that designers use as a cellular identity for communicating with cellular networks. Credential provisioning usually depends on the Mobile Network Operator (MNO) provider, Mobile Virtual Network Provider (MVNO), or third party.  If you are using cellular modules for communication, this is your choice.
• Customized, automated device credential provisioning to a device flash segment, which could have special secure flash, in conjunction with a Hardware Security Module (HSM) during manufacturing.
• Manual provisioning of Private Keys and credentials to special secure secure flash (or non-secure flash, typically during prototyping but not recommended for fleet provisioning).

Execution of TLS 1.2 is a compute-intensive activity due to the cryptography requirements, which in turn influences compute component choice, especially if you are using a microcontroller for your design.  Specialized ICs usually include cryptography routines, which relieve the host processor from applying cycles on the TLS 1.2 operation while ensuring that the Private Key does not get loaded into main memory.

The approach you take for hardware depends on your hardware design.  Choosing an elegant solution for the hardware design certainly simplifies at-scale provisioning,  but requires component selection early in the hardware design life-cycle since it influences other component design choices for compute, cryptography modules, math co-processing, and flash. Certainly, for devices at scale you will not want to manually provision, and trends suggest pre-provisioned devices produce the least friction from manufacturing, operations, and customer experience perspectives.

IoT device provisioning requires cloud and device orchestration

Successful IoT device provisioning requires cloud and device provisioning orchestration that influences hardware and software design as well as how you will manage devices throughout the device life-cycle.

From an IoT service perspective, you will need a process that aligns with your credential provisioning choice to create related configuration objects.  When the device connects to an IoT service, the IoT service must be able to recognize the device (authentication), enable specific device actions (authorization), and operate and manage the device in a specific context (device management).

For authentication, the IoT service must have a fingerprint of the credential so when the device connects and sends the credential to the IoT service, the IoT service can relate the physical connection with the configuration objects.  For AWS IoT, you register your credential which enables the IoT service to recognize the incoming connection.  The TLS handshake, which requires that the device has access to the Private Key (which the IoT service does not) ensures that the credential has been sent from the device with the Private Key. This is why it is so very essential to protect the Private Key on the device.

For authorization, the IoT service must apply rules to the connection that grants the minimum IoT service access.  Minimum IoT service access means setting limits the device to use only the resources it needs to fulfill its operational obligation. For example, AWS customers create IoT Policies that relate to the credential’s configuration object.

For device management, you will want to apply metadata to your configuration objects to cleanly specify groups or aggregations of devices, or fleets.  With IoT, we will need to manage thousands, tens of thousands, and millions of devices.  It will be impractical to manage each device individually.  Plan ahead to apply metadata to your device configuration because retrofitting or refactoring can be painful.  For AWS IoT, you create Thing Type and Thing Group configuration objects that drive IoT Device Management practices.

Approaches to device cloud provisioning at scale

It cannot be said that every IoT deployment is different when it comes to device provisioning, but there is enough differentiation across hardware vendors, IoT applications, and operational contexts to drive a robust set of mechanisms that will influence your decision on the right mechanism for you.  Generally speaking, there are three approaches: bulk registration, on-demand registration, and lazy registration.  All of the following methods expect that every IoT device has, or will have, its own unique Private Key and Certificate pair.

Bulk registration

With bulk registration, the set of credentials you wish to register with an IoT service is known prior to device deployment to the field.  Once the list of credentials has been obtained, you then channel the credentials to a bulk registration process.  The bulk registration process registers the credential and then also coordinates the credential with related management objects in the IoT service where you use to manage your IoT fleet.  Bulk registration may require customization but IoT service providers usually provide a bulk registration process to customers.  For example, AWS provides AWS IoT Bulk registration process as part of the AWS IoT Core service and custom processing using the AWS SDK.  An open source project named ThingPress handles specific import use cases.

On-demand registration

With on-demand device registration, the set of physical devices with paired credentials are not known to you prior to device deployment to the field. After the device has been deployed to the field, you will power on the device. With on-demand, a connectivity subroutine determines if a reference to the issuer of the credential has been registered with the IoT service.  As long as the IoT service has a robust mechanism for verifying that you are in fact the owner of the issuer, which means you have on hand the issuer identity (in PKI, the issuer’s Private Key), you can rest assured that the issuer provided the credential.  Then the subroutine automatically registers the credential and creates related management objects.  For example, AWS has two on-demand device registration mechanisms named Just-In-Time-Provisioning (JITP) that uses a provisioning template and Just-In-Time-Registration (JITR) that provides mechanisms that can be fully customized.

Lazy registration

With lazy registration, neither the set of physical devices nor the paired credentials are known prior to deployment to the field.  In this case, devices have a known, immutable identity (typically, a protected Private Key) that the IoT service can confirm without transferring the private identity beyond the device.

Today, there are three mechanisms for lazy registration: by claim, by authorized mobile device, and by authorized list of identities.  In the first case, the device sends the claim to the credential issuer, the issuer responds with a token, and the device uses the token to make a direct web service API call to issue the certificate.  In the second case, the device works in tandem with a mobile phone, where the mobile phone uses mobile credentials, like a username and password, the issuer responds with a token, the mobile phone sends the token to the device, and the device uses the token to make a direct API call.  In the third case, an authorized list, which can be a list of Public Keys, and the device makes a direct API call to the IoT service with a CSR. The Public Key derived from the CSR is then compared to the authorized list, and then provisions the certificate to the device when a match exists.  For example, AWS Fleet provisioning provides claim and smartphone based provisioning mechanisms, the open source project IoT Provisioning Secret-Free provides lazy registration mechanisms using claims, and AWS partner 1nce provides a streamlined cellular provisioning experience through the AWS Marketplace.

Choosing the device provisioning that is right for you

Choosing the device provisioning that is right for you means finding the device credential and device cloud provisioning practice that aligns with your hardware design, software design, manufacturing, and device life-cycle operations.  The hardware design defines how you define and store individual device identity and credential files.  The software design influences device authorization.  Manufacturing influences the conditions under which secrets will be created and stored, or identified, influence how authorization fingerprints reflect into IoT services.

How you decide to do credential provisioning to the physical hardware, which reflects hardware design that is usually decided far in advance when doing product design, creates a fundamental pivot to specific types of cloud provisioning processes. Further, if you’re not doing your own manufacturing, then you will be using contract manufacturers for constructing your products.  Contract manufacturing has a lot of benefits, but many aspects of the manufacturing process will not be in your control, which includes creating device secrets such as private keys and certificates on the manufacturing line. The risks such as overproduction, cloning, and other attack vectors can directly relate to the contract manufacturer under hire, which means you need to have a lot of trust to sleep easy at night.

If you are not managing a private CA for your IoT fleet, then pre-provisioned credentials might be the right fit for you.  Pre-provisioned credentials may cost a little extra up front, but we have seen that they significantly reduce operational costs. If you need to manage your own private CA, then some hardware companies provide pre-provisioned credentials where configuration is done at tape-out, which means the contract manufacturer will not have any knowledge of the secrets on the device.  Otherwise, you might want to lean toward lazy style provisioning where the device has the immutable Private Key or reproducible self-generating Private Key` on the device and can participate with a IoT service to have credentials deployed after some level of attestation.  If you are left in the unfortunate situation of not having an immutable Private Key on the device, then you can still provision a Private Key and credential directly to flash, but this is very much not recommended.

In contrast to hardware design, software design is more flexible and can change throughout the device development and even life-cycle (think Over-The-Air Firmware Updates).  Whenever you ship a new batch of devices to customers, you will need to lean on the device cloud provisioning process.  Like software design, the provisioning design may require flexibility based on your evolving software requirements.  The required configuration and customization breadth drive the device cloud provisioning process you will use when deploying new or additional device fleets.

Device life-cycle operations requirements will drive the level of flexibility that will be required for device cloud provisioning.  More specifically, while most of the processes for AWS IoT device cloud provisioning enable automatic creation of management objects such as Thing Types and Thing Groups, if your process also requires any custom interoperability during registration time you might want to consider Just-In-Time-Provisioning which allows deeper customization.

Finally, when looking at the device life-cycle, consider the opportunity for the device to change human owners throughout its usefulness.  While the device identity in terms of the Private Key might not change, there is opportunity to deprecate the prior owner’s Certificate to move the device to a “factory state”.  When the new human owner commissions the device to a new network and provisions using perhaps a mobile application, a fresh Certificate may need to be provisioned at that time.  The life-cycle mechanics would then need to accompany those requirements.

Conclusion

Throughout this article, we discussed IoT provisioning situations that you are likely witnessing today.  Likewise, you have witnessed that there are many choices depending on what you are trying to achieve and the outcomes you want your customers to enjoy.  Like everything, security underpins provisioning, which starts with every device having its own unique and identifiable Private Key and Certificate pair.  The credential provisioning approach you choose creates that pivot point for your device cloud provisioning choices.  If you are doing a new design, you will want to take a hard look at hardened hardware security solutions such as secure elements and secure enclaves, which in turn simplifies device cloud provisioning.  If you are evolving or reworking an existing design, your choices may seem much more limited, but there are still options for you to get your device connected in an IoT capacity.  Finally, throughout the examples and anecdotes you were able to witness that AWS IoT has delivered device cloud provisioning solutions that pair well with our silicon partner solutions.  Now it’s time to go build securely commissioned and provisioned IoT devices!

— Richard Elberger is an IoT Principal Technologist at Amazon Web Services.

Related articles:

• Report: Semiconductor startup market review
• Arm DevSummit: Virtual flagship conference for developers
• Rigol extends their RF portfolio with the addition of vector network analysis capability on the ultrareal analyzer platform

Subscribe to Newsletter