Securing your connected devices and their data in a cost-efficient way can be a challenge. There are, of course, standards for connectivity and communication, but what about injecting the necessary certificates and keys into your devices in the first place?
In most cases, this is done in the manufacturing phase. Factories are prepared with secure rooms for you to operate your own certificate authority machines. But what if your product needs a different configuration based on customer deployment? This introduces a new challenge in handling security assets on the factory floor. Manufacturing customer-specific batches is expensive and introduces long lead times.
nRF Cloud Security Services provides a solution to remotely provision your devices in the deployment phase. This simplifies manufacturing, enables you to produce generic devices, and enhances the security in manufacturing and operation.
In this blog post, we will give you an overview of the nRF Cloud Security Services and what it can offer to streamline your cellular IoT development. We will present a real use case of parcel lockers as an example of how the services can facilitate the deployment process.
nRF Cloud Security Services
Nordic’s nRF Cloud Security Services provides Identity and Provisioning Services which, along with the nRF9161 SiP, offer something unique: a ready-made, crypto-provable device ID and remote, over-the-air provisioning. With these new services, it’s no longer necessary to provision a device with your own cloud credentials or other configurations during the manufacturing process. Instead, you can do it when the device is deployed.
This means you don’t need to create keys on the factory floor and can manufacture generic, globally deployable devices. The devices are remotely provisioned with deployment-specific assets after they leave the factory, resulting in smoother manufacturing and delivery. It’s not a one-time deal, either: you can re-provision devices whenever needed, futureproofing them and enhancing security throughout the product lifecycle.
Device identity as a service
Let’s first talk about the nRF Cloud Secure Identity Service. You can use it by itself to authenticate devices, but it’s also the basis for secure provisioning.
Nordic SiP manufacturing sets a universally unique ID (UUID) to the SiP and secures it. The SiP internally generates an identity key pair from where the public identity key is exported and stored in the Identity Service. The private identity key is not accessible to the application running on the SiP. When the device’s identity needs to be verified, the device application requests an identity attestation token or an identity JWT, which is given to the Identity Service to verify it with the public key.
Figure 1: Sequence of steps in the token verification process
Because of this, you don’t need to create your own identity assets and verification system. You can store the device’s UUID from manufacturing and check the device’s attestation to verify it. Certificates can stay generic, and device authentication can be based on identity attestation.
Provisioning Service: a game changer
Moving on to the nRF Cloud Secure Provisioning Service, the nRF Cloud solution allows you to onboard devices to the selected cloud after devices leave the factory, shifting provisioning decisions to the deployment phase. Secure provisioning provides everything you need: a ready-made nRF Device provisioning library that needs minimal integration, a Web UI (nRF Cloud portal) to manage and monitor provisioning configurations, provisioning rules to automate configuration deployment for multiple devices, and a REST API to integrate with your tools and services.
When you deploy a device, you can set one or more tags that you can use as a target condition for a provisioning rule. The rule contains a configuration that runs commands you set through the service. When the device connects, it can apply a single configuration you set specifically for the device or apply rules targeting it. You can configure how often the device checks for configurations and rules in your application using the nRF Device provisioning library. You can use this, for example, to rotate keys for security management.
Secure provisioning futureproofs your system: you could redirect devices to a new region for smoother business growth or reliably decommission retired devices by removing credentials, among other things.
Late provisioning process: Parcel locker deployment example
Let’s use parcel lockers as an example to cover some of the technical aspects of the service. If you’re unfamiliar with these, they are automated postal lockers, often in grocery stores or shopping centers, that store packages for a period of time. Packages are delivered to the locker, and the recipient can then pick up their package using a code.
In this example, your company manufactures parcel lockers that are sold to post offices and delivery companies in different countries. You manufacture the parcel locker modules in your factory, but you don’t know where they’ll be delivered.
The provisioning process starts with claiming ownership of the device using an identity attestation token generated by the device. The claim binds the device to your nRF Cloud team and prevents others from claiming and provisioning it.
You’ve made a contract with Finland’s postal agency to provide them with parcel lockers. As part of new customer onboarding, you define a provisioning rule specific to devices deployed to the Finnish postal network. It defines the certificates, service address, and credentials. When the parcel locker is installed at the grocery store, the field engineer assigns a tag to it. This tag can be the locker location, store address, device model—depending on how you want to organize your deployed devices.
Finally, the field engineer plugs in the device, and the locker boots up. The locker connects to the nRF Cloud Provisioning Service, a provisioning rule is triggered based on the tag, and new commands are added to the device’s provisioning configuration. After running the commands, the device has all the needed security assets to connect to the Finnish postal service.
Secure provisioning can also set key-value configurations and, for example, define ‘localization':'FIN', which makes the UI match the postal service branding.
Figure 2: Sequence of steps for parcel locker deployment example
Closing
nRF Cloud Security Services does not directly make your data secure, but it enables you to make it secure in an easy way. It eliminates the need for immediate certificate signing and key handling so that you can manufacture in bulk and provision deployment-specific assets later. These new features add flexibility and security to the device lifecycle through target cloud changes and key rotation.
For more information see About Security Services (nordicsemi.com)
