Del via

Device identity and security

  • Artikkel

Important

This is the Azure Sphere (Legacy) documentation. Azure Sphere (Legacy) is retiring on 27 September 2027, and users must migrate to Azure Sphere (Integrated) by this time. Use the Version selector located above the TOC to view the Azure Sphere (Integrated) documentation.

You can deploy and manage numerous devices at a time. Device management is based on the ability to identify and access each device individually when required. To enable you to do this, each Azure Sphere device is given a unique internal device ID that persists through any updates to the device, including recovery operations.

However, in digital systems, a device's ID can easily be spoofed, forged, or misused. As a result, you should only permit devices whose identities can be verified and validated to access your highly valuable data and connect to your services.

Azure Sphere provides a process for enabling a device to identify itself (authentication) and for confirmation of the device's identity (attestation). The authentication and attestation process employed by the Azure Sphere Security Service uses pre-known keys, secure communications, and specialized hardware to confirm a device's identity. If device authentication and attestation are successful, a certificate is issued to the device. A valid certificate indicates that:

  • The device's identity has been verified.
  • The device can be trusted.

With Azure Sphere, the device certificates are chained first to a tenant-level certificate (making it easy for an organization to trust only devices from its own tenants) and then to a Microsoft certificate, which reflects that Microsoft has validated that this hardware is a verified instance of a certified Azure Sphere chip that is running a secured Microsoft OS.

The following concepts can help use device identity in the most secure and effective ways:

  • Trust is transient
    Trust in a system can be lost, and it can be regained. A principle of implementing Zero Trust architecture in an IoT system is to verify explicitly. This means each and every time you have an interaction with a device, explicitly determine the device's authenticity and prove that the data transaction is trustworthy. Azure Sphere devices automatically perform an authentication and attestation process every 24 hours with the Azure Sphere cloud security services. An indication that a device's identity has been successfully verified is the presence of a cryptographically signed certificate, rooted in the Microsoft Azure Sphere Cloud Security Service.

  • Identity = identifiers + attestation
    Identifiers can be copied and duplicated. As a result, a device cannot simply be known by its identifier. A device's identity (or a user's identity) must be considered to be a combination of both an identifier and attestation that such an identifier is valid within a specific context. You should not assign identifiers to devices and use them independent of the attestation process. Where possible, combine identifiers with evidence of attestation at every layer of interaction within your systems.

  • Identifiers + trust certificates
    An identifier should be considered no more than a reference. Alone it should not be assumed to indicate anything about the trustworthiness of the object it references. For example, use an identifier to subscribe to MQTT messages, use an identifier to group trusted data together within a portal, and use identifiers to route traffic and data in a system. However, when it comes to trust, rather than trust the identifier, trust a cryptographically signed and chained certificate. Certificates are particularly beneficial for password-less dataflow between system components and are evidence of identification that has been tested and proven to be trustworthy within a specific context.

When using Azure IoT Hub, if configured according to documented recommendations, these concepts are already incorporated, simplifying the deployment of a secured and resilient system.

You must also apply these concepts when connecting to non-Azure endpoints or services that you directly control. For example, if using MQTT, a device may include its own identity as part of the MQTT topic it publishes to. However, before accepting a topic update from the device, the MQTT server must verify that the certificate the device provides authenticates it to publish to this specific topic.

Azure Sphere device certificate and device ID access

  • To access a device certificate in your application, use the DeviceAuth_GetCertificatePath function.

  • To access the device's unique Device ID, parse the subject from the certificate provided by the DeviceAuth_GetCertificatePath() function by using the wolfSSL_X509_get_subject_name function.

The code snippet Get Azure Sphere Device ID demonstrates how to get the Azure Sphere Device ID in a high-level application. It returns the Device ID as a character buffer of 128 characters. This snippet commands wolfSSL to open a session with the certificate, pull the context and certificate, parse out the subject ID of the certificate which is the Device ID for Azure Sphere Devices, and return it as a char pointer.