Skip to content

Commit 94b3f58

Browse files
Merge pull request #277618 from kgremban/jun7-dpscrypto
Recommended ECC curves for DPS and X509
2 parents e49255f + 86a0abb commit 94b3f58

File tree

2 files changed

+21
-9
lines changed

2 files changed

+21
-9
lines changed

articles/iot-dps/concepts-x509-attestation.md

Lines changed: 20 additions & 8 deletions
Original file line numberDiff line numberDiff line change
@@ -19,7 +19,7 @@ X.509 certificates can be stored in a hardware security module HSM.
1919
> [!TIP]
2020
> We strongly recommend using an HSM with devices to securely store secrets, like the X.509 certificate, on your devices in production.
2121
22-
## Provision devices with X.509 certificates
22+
## Understand the X.509 certificate chain
2323

2424
Using X.509 certificates as an attestation mechanism is an excellent way to scale production and simplify device provisioning. X.509 certificates are typically arranged in a certificate chain of trust in which each certificate in the chain is signed by the private key of the next higher certificate, and so on, terminating in a self-signed root certificate. This arrangement establishes a delegated chain of trust from the root certificate generated by a trusted certificate authority (CA) down through each intermediate certificate to the final certificate installed on a device. To learn more, see [Device Authentication using X.509 CA Certificates](../iot-hub/iot-hub-x509ca-overview.md).
2525

@@ -48,13 +48,7 @@ Imagine that Contoso is a large corporation with its own Public Key Infrastructu
4848

4949
A *leaf certificate*, or *end-entity certificate*, identifies a certificate holder. It has the root certificate in its certificate chain and zero or more intermediate certificates. A leaf certificate is not used to sign any other certificates. It uniquely identifies a device to the provisioning service and is sometimes referred to as a *device certificate*. During authentication, a device uses the private key associated with its certificate to respond to a proof of possession challenge from the service.
5050

51-
Leaf certificates used with [individual enrollment](./concepts-service.md#individual-enrollment) entries must have the subject common name (CN) set to the registration ID. The registration ID identifies the device registration with DPS and must be unique to the DPS instance (ID scope) where the device registers.
52-
53-
For [enrollment groups](./concepts-service.md#enrollment-group), the subject common name (CN) sets the device ID that is registered with IoT Hub. The device ID will be shown in the **Registration Records** for the authenticated device in the enrollment group. For individual enrollments, the device ID can be set in the enrollment entry. If it's not set in the enrollment entry, then the subject common name (CN) is used.
54-
55-
To learn more, see [Authenticate devices signed with X.509 CA certificates](../iot-hub/iot-hub-x509ca-overview.md#authenticate-devices-signed-with-x509-ca-certificates).
56-
57-
## Control device access with X.509 certificates
51+
## Use X.509 certificates with DPS
5852

5953
The provisioning service exposes two enrollment types that you can use to control device access with the X.509 attestation mechanism:
6054

@@ -67,6 +61,24 @@ A certificate can be specified in only one enrollment entry in your DPS instance
6761

6862
When DPS enrollments are configured for X.509 attestation, mutual TLS (mTLS) is supported by DPS.
6963

64+
### DPS encryption algorithm requirements
65+
66+
The Device Provisioning Service only accepts X.509 certificates that use either the Rivest-Shamir-Adleman (RSA) algorithm or the Elliptic Curve Cryptography (ECC) algorithm for encryption. ECC and RSA provide equivalent levels of encryption strength, but ECC uses a shorter key length.
67+
68+
If you use ECC methods to generate X.509 certificates for device attestation, we recommend the following elliptic curves:
69+
70+
* nistP256
71+
* nistP284
72+
* nistP521
73+
74+
### DPS certificate naming requirements
75+
76+
Leaf certificates used with [individual enrollment](./concepts-service.md#individual-enrollment) entries must have the subject common name (CN) set to the registration ID. The registration ID identifies the device registration with DPS and must be unique to the DPS instance (ID scope) where the device registers.
77+
78+
For [enrollment groups](./concepts-service.md#enrollment-group), the subject common name (CN) sets the device ID that is registered with IoT Hub. The device ID will be shown in the **Registration Records** for the authenticated device in the enrollment group. For individual enrollments, the device ID can be set in the enrollment entry. If it's not set in the enrollment entry, then the subject common name (CN) is used.
79+
80+
To learn more, see [Authenticate devices signed with X.509 CA certificates](../iot-hub/iot-hub-x509ca-overview.md#authenticate-devices-signed-with-x509-ca-certificates).
81+
7082
### DPS device chain requirements
7183

7284
When a device is attempting registration through DPS using an enrollment group, the device must send the certificate chain from the leaf certificate to a [verified certificate](how-to-verify-certificates.md). Otherwise, authentication fails.

articles/iot-dps/quick-enroll-device-x509.md

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -15,7 +15,7 @@ zone_pivot_groups: iot-dps-set2
1515

1616
# Programmatically create a Device Provisioning Service enrollment group for X.509 certificate attestation
1717

18-
This article shows you how to programmatically create an [enrollment group](concepts-service.md#enrollment-group) that uses intermediate or root CA X.509 certificates. The enrollment group is created by using the [Azure IoT Hub DPS service SDK](libraries-sdks.md#service-sdks) and a sample application. An enrollment group controls access to the provisioning service for devices that share a common signing certificate in their certificate chain. To learn more, see [Control device access with X.509 certificates](./concepts-x509-attestation.md#control-device-access-with-x509-certificates). For more information about using X.509 certificate-based Public Key Infrastructure (PKI) with Azure IoT Hub and Device Provisioning Service, see [X.509 CA certificate security overview](../iot-hub/iot-hub-x509ca-overview.md).
18+
This article shows you how to programmatically create an [enrollment group](concepts-service.md#enrollment-group) that uses intermediate or root CA X.509 certificates. The enrollment group is created by using the [Azure IoT Hub DPS service SDK](libraries-sdks.md#service-sdks) and a sample application. An enrollment group controls access to the provisioning service for devices that share a common signing certificate in their certificate chain. To learn more, see [Use X.509 certificates with DPS](./concepts-x509-attestation.md#use-x509-certificates-with-dps). For more information about using X.509 certificate-based Public Key Infrastructure (PKI) with Azure IoT Hub and Device Provisioning Service, see [X.509 CA certificate security overview](../iot-hub/iot-hub-x509ca-overview.md).
1919

2020
## Prerequisites
2121

0 commit comments

Comments
 (0)