Security considerations in development
The definition of secure depends on the target application. If you are developing a remote light measurement device, the main security concern is probably preventing it from being commandeered to be used as part of a botnet; a remotely controlled medical device must be far more robust.
It is important to think about security early, because your security requirements guide your technological choices. It is also more efficient: retrofitting or modifying security can be expensive (and may be impossible for shipped devices).
One of the first things to do when designing your application is a threat model. You can use one of the ones Arm provides as part of the PSA framework if it is applicable to you. If not, there is a lot of public documentation available on how to perform one. The main idea is to identify assets (in other words, "things of value") and attackers in your system. You can then review how to protect assets from attackers.
Security features in Mbed OS and Pelion
With Mbed OS and Pelion, you can use the following security features:
- Mutually authenticated (D)TLS connections between your device and Pelion using Mbed TLS.
- A first-time-use LwM2M bootstrapping mechanism.
- A firmware update mechanism.
Diversification of secrets
We recommend that secrets (such as keys) deployed in devices be diversified: each device should have secrets that are unique and specific to it, stored in the device's secure storage system.
Using the same secret across devices is akin to sharing passwords across web sites: it allows an attacker who has successfully attacked a device to attack others or impersonate any of the devices that share the same secret.
Certificates in development with Device Management Client
It's important to understand how your device securely connects to Device Management and how we've made this process easier in the development stage.
This guide covers Device Management Client, not Device Management Client Lite, which is only available to select Partners.
Secure connection: X.509 certificates
To securely connect your deployment devices to Device Management using the client, you need X.509 certificates appropriate for your onboarding process. However, during development you need only one - the developer certificate - which you can download from the Device Management Portal (note that it always connects using the bootstrap onboarding process). This reduces development time and expense, by delaying certificate authority work to production environments.
Deployment certificates are reviewed later in this document.
The Device Management Portal can generate a development certificate that you can download and add to your application's root directory.
Note that each account has a limited number of developer certificates, and each certificate can only be used by a limited number of devices, so they are not suitable for large scale testing.
- For instructions for generating certificates and adding them to your device (using the
fcc_developer_flow()API), please see the developer certificate documentation.
Secure updates: authenticity certificates
For your device to use the Device Management Update service, you must generate an authenticity certificate - a container for a public key that the device trusts and uses to verify the authenticity of update manifests.
Restrict the public key's use to Device Management Update to compartmentalize and protect Update in case information about any other key is leaked.
We provide a Python tool, called the manifest tool, to simplify the creation of firmware update manifests. This tool is integrated with our other development tools - Mbed CLI and the Online Compiler - so you can use it either as a standalone or through these other tools.
By default, the authenticity certificate that the manifest tool generates is only valid for 90 days. Before deploying the device, you must replace the authenticity certificate with a secure certificate with a longer lifespan.