question

TomBulsinkInspiro-2000 avatar image
1 Vote"
TomBulsinkInspiro-2000 asked TomBulsinkInspiro-2000 commented

Azure DPS and IoT hub, x509 authentication and certificate management

I am reading up and experimenting with DPS, IoT hub and x509 authentication, but some things are not entirely clear for me. Assuming a setup with x509 and group enrollment through intermediate certificates:

  • When a device connects to DPS, will it be registered to a hub if the intermediate certificate is removed, but the root certificate is still present and valid?

  • When a device connects to DPS, will it be registered to a hub if the intermediate certificate has expired but the root certificate is still valid?

  • When a device connects to DPS, will it be registered to a hub if the intermediate certificate is valid but the root certificate has expired?

  • To disallow DPS access in a group certificate setup, one would create an individual device registration using the device certificate and then disable that device. However, in such a setup the device certificate might not be available as that is generated with the intermediate certificate. How does one create this individual device registration in this case?

  • Is the device certificate actually used as TLS client authentication or is device authentication something built on top of of TLS?

  • What are the recommended validity periods of CA, intermediate/group and device certificates in DPS/IoT hub?

  • What is the recommended strategy regarding device certificates if devices could be offline for longer (5 years and more perhaps) periods of time in which there might be no way of updating (client) certificates?


azure-iot-hubazure-iot-dps
5 |1600 characters needed characters left characters exceeded

Up to 10 attachments (including images) can be used with a maximum of 3.0 MiB each and 30.0 MiB total.

SatishBoddu-MSFT avatar image
1 Vote"
SatishBoddu-MSFT answered TomBulsinkInspiro-2000 commented

Hello @TomBulsinkInspiro-2000, This is really a great question on DPS and IoT Hub best practices. The majority covers very broad areas! I tried my best to put it in a simple way to reduce reading confusion.


When a device connects to DPS, will it be registered to a hub if the intermediate certificate is removed, but the root certificate is still present and valid?
When a device connects to DPS, will it be registered to a hub if the intermediate certificate has expired but the root certificate is still valid?
When a device connects to DPS, will it be registered to a hub if the intermediate certificate is valid but the root certificate has expired?

Please see this documentation for an example: DPS device chain requirements

Be aware, though, that, if you delete the enrollment group and there is an enabled enrollment group for a signing certificate higher up in the certificate chain of one or more of the devices, those devices can re-enroll. More info: Enrollment groups||How to deprovision devices that were previously auto-provisioned

143125-image.png

To disallow DPS access in a group certificate setup, one would create an individual device registration using the device certificate and then disable that device. However, in such a setup the device certificate might not be available as that is generated with the intermediate certificate. How does one create this individual device registration in this case?

You may be interested to read this document: Disallow specific devices in an enrollment group

Is the device certificate actually used as TLS client authentication or is device authentication something built on top of of TLS?

This document talks about the DPS and TLS support: TLS support in Azure IoT Hub Device Provisioning Service (DPS)

What are the recommended validity periods of CA, intermediate/group and device certificates in DPS/IoT hub?

The frequency in which you roll your certificates will depend on the security needs of your solution. Customers with solutions involving highly sensitive data may roll certificate(s) daily, while others roll their certificates every couple of years. Please see this document on How to roll X.509 device certificates

What is the recommended strategy regarding device certificates if devices could be offline for longer (5 years and more perhaps) periods of time in which there might be no way of updating (client) certificates?

Please see this document : Understand extended offline capabilities for IoT Edge devices, modules, and child devices, for the certificate management, again it depends on the security needs of your solution.


Please comment in the below section if you need any further help in this matter, happy to help.

If the response is helpful, please click "Accept Answer" and upvote it.




image.png (184.9 KiB)
· 1
5 |1600 characters needed characters left characters exceeded

Up to 10 attachments (including images) can be used with a maximum of 3.0 MiB each and 30.0 MiB total.

@SatishBoddu-MSFT

If the Root cert itself is different, the full chain will not be verified!

I think my question is answered by this:

Authentication will fail if DPS cannot traverse the certificate chain to a verified certificate.

And

Intermediate certificates can also be verified with proof-of-possession..

From the link you posted

To me this indicates that if the intermediate is verified and known to DPS and the root certificate is "gone" a device signed by the intermediate will be allowed as the intermediate cert is known and verfied. Please correct me if i'm wrong.

Do you by any chance have some more information about my other questions regarding blocking devices in group enrollment when device certificates are not available and dealing with devices that are offline for extended periods of time when not using an IOT edge gateway?







0 Votes 0 ·
TomBulsinkInspiro-2000 avatar image
0 Votes"
TomBulsinkInspiro-2000 answered SatishBoddu-MSFT commented

Hello @SatishBoddu-MSFT

My apologies for the late response, and thank you for the information provided. Regarding DPS and certificate management i think its mostly clear now : The DPS will search the chain up to the first certificate it can validate and if that certificate is valid, the device will be allowed provision and if its invalid or disabled it will not be allowed to provision. This means that if the intermediate certificate is valid but its 'parent' certificate is not, the device will be allowed to provision. Is that correct?

You may be interested to read this document: Disallow specific devices in an enrollment group

This specifies what to do to block a device (make an individual device registration) but not how to obtain this registration if the device certificate was generated/signed by an intermediate certificate. How would one in that case obtain the device certificate to make this registration?

This document talks about the DPS and TLS support: TLS support in Azure IoT Hub Device Provisioning Service (DPS)

It does not say however if the device certificate is actually used in the TLS client authentication step. For now i'm assuming it is.

Please see this document : Understand extended offline capabilities for IoT Edge devices, modules, and child devices, for the certificate management, again it depends on the security needs of your solution.

This article is about a setup using an IoT Edge gateway device. In our setup we are not using a gateway.

One other question that came up during testing:
The device when connecting to the DPS service should provide the Scope ID of the DPS service. Is this Scope ID changed every time the DPS service is (re)created? That is, if a device was offline for a longer period of time, could the DPS ID Scope have changed if the DPS service was deleted and re-deployed in Azure?





· 1
5 |1600 characters needed characters left characters exceeded

Up to 10 attachments (including images) can be used with a maximum of 3.0 MiB each and 30.0 MiB total.

Hello @TomBulsinkInspiro-2000, thanks for the response!

If the Root cert itself is different, the full chain will not be verified!
So the question is like: If the verified Root cert is different, how can the entire cert chain be verified?

146624-image.png

**ID scope:** Is unique for every Azure DPS being created\deployed.

146612-image.png


0 Votes 0 ·
image.png (36.9 KiB)
image.png (20.3 KiB)