|
| 1 | +--- |
| 2 | +title: Device authentication in Azure IoT Central | Microsoft Docs |
| 3 | +description: This article introduces key concepts relating to device authentication in Azure IoT Central |
| 4 | +author: dominicbetts |
| 5 | +ms.author: dobett |
| 6 | +ms.date: 03/02/2022 |
| 7 | +ms.topic: conceptual |
| 8 | +ms.service: iot-central |
| 9 | +services: iot-central |
| 10 | + |
| 11 | +ms.custom: [amqp, mqtt, device-developer] |
| 12 | + |
| 13 | +# This article applies to operators and device developers. |
| 14 | +--- |
| 15 | + |
| 16 | +# Device authentication concepts in IoT Central |
| 17 | + |
| 18 | +This article describes how devices authenticate to an IoT Central application. To learn more about the overall connection process, see [Connect a device](overview-iot-central-developer.md#how-devices-connect). |
| 19 | + |
| 20 | +Devices authenticate with the IoT Central application by using either a _shared access signature (SAS) token_ or an _X.509 certificate_. X.509 certificates are recommended in production environments. |
| 21 | + |
| 22 | +You use _enrollment groups_ to manage the device authentication options in your IoT Central application. |
| 23 | + |
| 24 | +This article describes the following device authentication options: |
| 25 | + |
| 26 | +- [X.509 enrollment group](#x509-enrollment-group) |
| 27 | +- [SAS enrollment group](#sas-enrollment-group) |
| 28 | +- [Individual enrollment](#individual-enrollment) |
| 29 | + |
| 30 | +## X.509 enrollment group |
| 31 | + |
| 32 | +In a production environment, using X.509 certificates is the recommended device authentication mechanism for IoT Central. To learn more, see [Device Authentication using X.509 CA Certificates](../../iot-hub/iot-hub-x509ca-overview.md). |
| 33 | + |
| 34 | +An X.509 enrollment group contains a root or intermediate X.509 certificate. Devices can authenticate if they have a valid leaf certificate that's derived from the root or intermediate certificate. |
| 35 | + |
| 36 | +To connect a device with an X.509 certificate to your application: |
| 37 | + |
| 38 | +1. Create an _enrollment group_ that uses the **Certificates (X.509)** attestation type. |
| 39 | +1. Add and verify an intermediate or root X.509 certificate in the enrollment group. |
| 40 | +1. Generate a leaf certificate from the root or intermediate certificate in the enrollment group. Install the leaf certificate on the device for it to use when it connects to your application. |
| 41 | + |
| 42 | +To learn more, see [How to connect devices with X.509 certificates](how-to-connect-devices-x509.md) |
| 43 | + |
| 44 | +### For testing purposes only |
| 45 | + |
| 46 | +In a production environment, use certificates from your certificate provider. For testing only, you can use the following utilities to generate root, intermediate, and device certificates: |
| 47 | + |
| 48 | +- [Tools for the Azure IoT Device Provisioning Device SDK](https://github.com/Azure/azure-iot-sdk-node/blob/main/provisioning/tools/readme.md): a collection of Node.js tools that you can use to generate and verify X.509 certificates and keys. |
| 49 | +- [Manage test CA certificates for samples and tutorials](https://github.com/Azure/azure-iot-sdk-c/blob/master/tools/CACertificates/CACertificateOverview.md): a collection of PowerShell and Bash scripts to: |
| 50 | + - Create a certificate chain. |
| 51 | + - Save the certificates as .cer files to upload to your IoT Central application. |
| 52 | + - Use the verification code from the IoT Central application to generate the verification certificate. |
| 53 | + - Create leaf certificates for your devices using your device IDs as a parameter to the tool. |
| 54 | + |
| 55 | +## SAS enrollment group |
| 56 | + |
| 57 | +A SAS enrollment group contains group-level SAS keys. Devices can authenticate if they have a valid SAS token that's derived from a group-level SAS key. |
| 58 | + |
| 59 | +To connect a device with device SAS token to your application: |
| 60 | + |
| 61 | +1. Create an _enrollment group_ that uses the **Shared Access Signature (SAS)** attestation type. |
| 62 | +1. Copy the group primary or secondary key from the enrollment group. |
| 63 | +1. Use the Azure CLI to generate a device token from the group key: |
| 64 | + |
| 65 | + ```azurecli |
| 66 | + az iot central device compute-device-key --primary-key <enrollment group primary key> --device-id <device ID> |
| 67 | + ``` |
| 68 | +
|
| 69 | +1. Use the generated device token when the device connects to your IoT Central application. |
| 70 | +
|
| 71 | +> [!NOTE] |
| 72 | +> To use existing SAS keys in your enrollment groups, disable the **Auto generate keys** toggle and manually enter your SAS keys. |
| 73 | +
|
| 74 | +## Individual enrollment |
| 75 | +
|
| 76 | +Typically, devices connect by using credentials derived from an enrollment group X.509 certificate or SAS key. However, if your devices each have their own credentials, you can use individual enrollments. An individual enrollment is an entry for a single device that's allowed to connect. Individual enrollments can use either X.509 leaf certificates or SAS tokens (from a physical or virtual trusted platform module) as attestation mechanisms. For more information, see [DPS individual enrollment](../../iot-dps/concepts-service.md#individual-enrollment). |
| 77 | +
|
| 78 | +> [!NOTE] |
| 79 | +> When you create an individual enrollment for a device, it takes precedence over the default enrollment group options in your IoT Central application. |
| 80 | +
|
| 81 | +### Create individual enrollments |
| 82 | +
|
| 83 | +IoT Central supports the following attestation mechanisms for individual enrollments: |
| 84 | +
|
| 85 | +- **Symmetric key attestation:** Symmetric key attestation is a simple approach to authenticating a device with the DPS instance. To create an individual enrollment that uses symmetric keys, open the **Device connection** page for the device, select **Individual enrollment** as the authentication type, and **Shared access signature (SAS)** as the authentication method. Enter the base64 encoded primary and secondary keys, and save your changes. Use the **ID scope**, **Device ID**, and either the primary or secondary key to connect your device. |
| 86 | +
|
| 87 | + > [!TIP] |
| 88 | + > For testing, you can use **OpenSSL** to generate base64 encoded keys: `openssl rand -base64 64` |
| 89 | +
|
| 90 | +- **X.509 certificates:** To create an individual enrollment with X.509 certificates, open the **Device Connection** page, select **Individual enrollment** as the authentication type, and **Certificates (X.509)** as the authentication method. Device certificates used with an individual enrollment entry have a requirement that the issuer and subject CN are set to the device ID. |
| 91 | +
|
| 92 | + > [!TIP] |
| 93 | + > For testing, you can use [Tools for the Azure IoT Device Provisioning Device SDK for Node.js](https://github.com/Azure/azure-iot-sdk-node/tree/main/provisioning/tools) to generate a self-signed certificate: `node create_test_cert.js device "mytestdevice"` |
| 94 | +
|
| 95 | +- **Trusted Platform Module (TPM) attestation:** A [TPM](../../iot-dps/concepts-tpm-attestation.md) is a type of hardware security module. Using a TPM is one of the most secure ways to connect a device. This article assumes you're using a discrete, firmware, or integrated TPM. Software emulated TPMs are well suited for prototyping or testing, but they don't provide the same level of security as discrete, firmware, or integrated TPMs. Don't use software TPMs in production. To create an individual enrollment that uses a TPM, open the **Device Connection** page, select **Individual enrollment** as the authentication type, and **TPM** as the authentication method. Enter the TPM endorsement key and save the device connection information. |
| 96 | +
|
| 97 | +## Automatically register devices |
| 98 | +
|
| 99 | +This scenario enables OEMs to mass manufacture devices that can connect without first being registered in an application. An OEM generates suitable device credentials, and configures the devices in the factory. |
| 100 | +
|
| 101 | +To automatically register devices that use X.509 certificates: |
| 102 | +
|
| 103 | +1. Generate the leaf-certificates for your devices using the root or intermediate certificate you added to your [X.509 enrollment group](#x509-enrollment-group). Use the device IDs as the `CNAME` in the leaf certificates. A device ID can contain letters, numbers, and the `-` character. |
| 104 | +
|
| 105 | +1. As an OEM, flash each device with a device ID, a generated X.509 leaf-certificate, and the application **ID scope** value. The device code should also send the model ID of the device model it implements. |
| 106 | +
|
| 107 | +1. When you switch on a device, it first connects to DPS to retrieve its IoT Central connection information. |
| 108 | +
|
| 109 | +1. The device uses the information from DPS to connect to, and register with, your IoT Central application. |
| 110 | +
|
| 111 | +1. The IoT Central application uses the model ID sent by the device to [assign the registered device to a device template](concepts-device-templates.md#assign-a-device-to-a-device-template). |
| 112 | +
|
| 113 | +To automatically register devices that use SAS tokens: |
| 114 | +
|
| 115 | +1. Copy the group primary key from the **SAS-IoT-Devices** enrollment group: |
| 116 | +
|
| 117 | + :::image type="content" source="media/concepts-device-authentication/group-primary-key.png" alt-text="Group primary key from SAS-IoT-Devices enrollment group"::: |
| 118 | +
|
| 119 | +1. Use the `az iot central device compute-device-key` command to generate the device SAS keys. Use the group primary key from the previous step. The device ID can contain letters, numbers, and the `-` character: |
| 120 | +
|
| 121 | + ```azurecli |
| 122 | + az iot central device compute-device-key --primary-key <enrollment group primary key> --device-id <device ID> |
| 123 | + ``` |
| 124 | +
|
| 125 | +1. As an OEM, flash each device with the device ID, the generated device SAS key, and the application **ID scope** value. The device code should also send the model ID of the device model it implements. |
| 126 | +
|
| 127 | +1. When you switch on a device, it first connects to DPS to retrieve its IoT Central registration information. |
| 128 | +
|
| 129 | +1. The device uses the information from DPS to connect to, and register with, your IoT Central application. |
| 130 | +
|
| 131 | +1. The IoT Central application uses the model ID sent by the device to [assign the registered device to a device template](concepts-device-templates.md#assign-a-device-to-a-device-template). |
| 132 | +
|
| 133 | +## Next steps |
| 134 | +
|
| 135 | +Some suggested next steps are to: |
| 136 | +
|
| 137 | +- Review [best practices](concepts-device-implementation.md#best-practices) for developing devices. |
| 138 | +- Review some sample code that shows how to use SAS tokens in [Tutorial: Create and connect a client application to your Azure IoT Central application](tutorial-connect-device.md) |
| 139 | +- Learn how to [How to connect devices with X.509 certificates using Node.js device SDK for IoT Central Application](how-to-connect-devices-x509.md) |
| 140 | +- Learn how to [Monitor device connectivity using Azure CLI](./howto-monitor-devices-azure-cli.md) |
| 141 | +- Read about [Azure IoT Edge devices and Azure IoT Central](./concepts-iot-edge.md) |
0 commit comments