Achieve device provisioning during production (CA-289)

[albatros96]

Hello,

Synthesis

We'd like to know how to achieve the provisioning step during production.

Details

I'm using the example tls_mutual_auth with AWS platform. I've been able to use a device with certificates and key uploaded as binary hardcoded text files (the standard way).

Now, I suppose we will do a next step soon and we'll need a production provisioning. In other words, I cannot simply adjust everytime the private key, the device ID and the device certificate.

We need a way which enables us to gain provisioning of a lot of devices. So I saw this README file related to digital signature that seems to explain how to use configure_esp_secure_cert.py in order to create a special partition where the certificates will be flashed. However I'm not sure this will work, because I won't modify the device ID.

Question

1. Is there a more accurate way to gain the same result for production? Should I look at fleet provisioning?
2. If yes, could you provide me docs/explanation for Espressif?
3. If no, is this way correct or it needs other steps?

I hope I've been clear. Thank you.

[SolidStateLEDLighting]

YES -- and "not really". Espressif doesn't document fleet provisioning other than publishing a demo project. On the up-side, fleet provisioning is nothing more than subscribing, publishing, and unsubscribing to topics. Once you understand it -- the idea is fairly simple.

The tricky part is getting AWS set up with certificates, roles, policies, and the provisioning template. AWS does publish all the information that you need, but getting it all sorted out is a challenge.

[albatros96]

YES -- and "not really". Espressif doesn't document fleet provisioning other than publishing a demo project. On the up-side, fleet provisioning is nothing more than subscribing, publishing, and unsubscribing to topics. Once you understand it -- the idea is fairly simple.

Thank you, I've just read how to perform fleet provisioning. I agree with you, it is a challenge conveyed by production necessity. However starting to use fleet provisioning requires to set-up the properties on the AWS portal. I'll try to go ahead and I'll update you.

If there are other suggestions, I'll be pleased to receive them.

[SolidStateLEDLighting]

I may have some suggestions. Can you give me an idea of what you are working on? I'm assuming this is a commercial product of some type? You can communicate with me privately if you like -- here is my e mail address Keith at SSLEDLighting dot com.

[albatros96]

@SolidStateLEDLighting after a week we have a clearer idea of what we want. Thank you for giving me you e-mail address!

Here the fact: our customer wants to create an application in order to achieve the fleet provisioning by trusted user. Of all the possibilities, this is the one that seems more "user friendly" but it is also a complication on our side.

First of all, there isn't an official example to achieve this provisioning. The fleet provisioning example is by claim. I understood that the claim of credentials is performed either by CreateCertificatefromCsr() if by claim (the example), or by CreateKeysAndCertificate() if by trusted user.

Is there any sort of documentation (or better working example) to understand the implementation of fleet provisioning by trusted user?

[SolidStateLEDLighting]

Gosh, it has been a while since I have read up on all this -- but, if my memory serves me well enough -- I think that "trusted user" was someone walking out to the field with a piece of hardware and provisioning a device through a physical connection??? This is the circumstance where the product leaves the factory but must be provisioned physically after delivery?

Do you understand why your client needs this particular approach?

K.

---

From: Filippo @.> Sent: Tuesday, May 9, 2023 5:39 PM To: espressif/esp-aws-iot @.> Cc: keith ssledlighting.com @.>; Mention @.> Subject: Re: [espressif/esp-aws-iot] Achieve device provisioning during production (CA-289) (Issue #180)

@SolidStateLEDLightinghttps://github.com/SolidStateLEDLighting after a week we have a clearer idea of what we want. Thank you for giving me you e-mail address!

Here the fact: our customer wants to create an application in order to achieve the fleet provisioning by trusted user. Of all the possibilities, this is the one that seems more "user friendly" but it is also a complication on our side.

First of all, there isn't an official example to achieve this provisioning. The fleet provisioning examplehttps://github.com/espressif/esp-aws-iot/tree/release/202210.01-LTS/examples/fleet_provisioning/fleet_provisioning_with_csr is by claim. I understood that the claim of credentials is performed either by CreateCertificatefromCsr() if by claim (the example), or by CreateKeysAndCertificate() if by trusted user.

Is there any sort of documentation (or better working example) to understand the implementation of fleet provisioning by trusted user?

— Reply to this email directly, view it on GitHubhttps://github.com/espressif/esp-aws-iot/issues/180#issuecomment-1539662661, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AGGOKE2LWXCKK4U5OC6XQ4TXFIGFZANCNFSM6AAAAAAXPIY4KY. You are receiving this because you were mentioned.Message ID: @.***>

[albatros96]

Gosh, it has been a while since I have read up on all this -- but, if my memory serves me well enough -- I think that "trusted user" was someone walking out to the field with a piece of hardware and provisioning a device through a physical connection??? This is the circumstance where the product leaves the factory but must be provisioned physically after delivery?

It is partially true: the device will exit from production as non-provisioned. The end user then will use a mobile application (ad-hoc) which will complete the provision step. This can be done via Wi-Fi, BLE or USB.

However at the moment I don't know how to proceed inside the aws SDK.

[SolidStateLEDLighting]

You haven't answered the important question. Why would the client NOT want the unit to self-provision at the factory? Or why would they NOT want the unit to re-provision if the credentials were somehow lost/deleted at AWS?

K.

---

From: Filippo @.> Sent: Tuesday, May 9, 2023 8:40 PM To: espressif/esp-aws-iot @.> Cc: keith ssledlighting.com @.>; Mention @.> Subject: Re: [espressif/esp-aws-iot] Achieve device provisioning during production (CA-289) (Issue #180)

Gosh, it has been a while since I have read up on all this -- but, if my memory serves me well enough -- I think that "trusted user" was someone walking out to the field with a piece of hardware and provisioning a device through a physical connection??? This is the circumstance where the product leaves the factory but must be provisioned physically after delivery?

It is partially true: the device will exit from production as non-provisioned. The end user then will use a mobile application (ad-hoc) which will complete the provision step. This can be done via Wi-Fi, BLE or USB.

However at the moment I don't know how to proceed inside the aws SDK.

— Reply to this email directly, view it on GitHubhttps://github.com/espressif/esp-aws-iot/issues/180#issuecomment-1540044989, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AGGOKEZQYYNOJH5MJ65TWUDXFI3LZANCNFSM6AAAAAAXPIY4KY. You are receiving this because you were mentioned.Message ID: @.***>

[albatros96]

You haven't answered the important question. Why would the client NOT want the unit to self-provision at the factory?

It's a matter of security, in fact fleet provisioning by claim is less secure. Also, it's a matter of complication: a provisioned device means it has been already registered by using unique private key and certificate.

[SolidStateLEDLighting]

Personally, I think there is already plenty of security with regard to secure boot, FLASH encryption, and all the tools over at AWS. The manger of Things can monitor security with Device Defender and just turn off credentials which are flagged as compromised (or under attack).

Based on what I remember, the "trusted user" approach uses a hand held device which side loads the security credentials on-site. This might be helpful for customer who wants to buy in to a service after trying out the hardware... OR there could be a bank vault or military application which keeps the hardware inactive until authorization is required.

I just reviewed the "trusted user" approach. It looks just like "provision by claim" except that the first credential is delivered by phone app and is only good for 5 minutes. Everything else looks exactly the same to me. The publishing topics and chronological order of steps are identical once the phone app delivers the first credential.

K.

---

From: Filippo @.> Sent: Tuesday, May 9, 2023 9:53 PM To: espressif/esp-aws-iot @.> Cc: keith ssledlighting.com @.>; Mention @.> Subject: Re: [espressif/esp-aws-iot] Achieve device provisioning during production (CA-289) (Issue #180)

You haven't answered the important question. Why would the client NOT want the unit to self-provision at the factory?

It's a matter of security, in fact fleet provisioning by claim is less secure. Also, it's a matter of complication: a provisioned device means it has been already registered by using unique private key and certificate.

— Reply to this email directly, view it on GitHubhttps://github.com/espressif/esp-aws-iot/issues/180#issuecomment-1540170688, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AGGOKE6VGBKFOGSPHN5LPITXFJD5BANCNFSM6AAAAAAXPIY4KY. You are receiving this because you were mentioned.Message ID: @.***>

[albatros96]

It looks just like "provision by claim" except that the first credential is delivered by phone app and is only good for 5 minutes. Everything else looks exactly the same to me. The publishing topics and chronological order of steps are identical once the phone app delivers the first credential. K.

Do you mean I should only manage the exchange of the credentials between the smartphone and the IoT device (and the remaining part is like fleet provisioning by claim)? Is there any built-in function of the AWS SDK which is able to handle this step?

Thank you for your patience.

[SolidStateLEDLighting]

I looked at the sequence diagram for provision by trusted user, the all the steps after the first one (after the device hands over credentials) looked the same. I recognized them as being just like provision by claim.

Yes, you need to handle the exchange of credentials between phone and IOT device - first.

The trusted user is described as a hand held device, but I don't think it specifies a wired or wireless connection between those 2 devices.

I am not aware of any particular tool that Espressif provides to expedite making a trusted user device. However, I were doing it, I think I would start with the Unified Provisioning tool and build on that. That code normally is used to securly deliver Wifi credentials from phone to device -- but it could delivery anything. Most of the code you will want is publically available.

The easiest way forward is likely convincing your client that they don't need provisioning by trusted user???

Sadly, I don't think you're going to find an easy answer.

K.

---

From: Filippo @.> Sent: Monday, May 15, 2023 5:54 PM To: espressif/esp-aws-iot @.> Cc: keith ssledlighting.com @.>; Mention @.> Subject: Re: [espressif/esp-aws-iot] Achieve device provisioning during production (CA-289) (Issue #180)

It looks just like "provision by claim" except that the first credential is delivered by phone app and is only good for 5 minutes. Everything else looks exactly the same to me. The publishing topics and chronological order of steps are identical once the phone app delivers the first credential. K.

Do you mean I should only manage the exchange of the credentials between the smartphone and the IoT device (and the remaining part is like fleet provisioning by claim)? Is there any built-in function of the AWS SDK which is able to handle this step?

Thank you for your patience.

— Reply to this email directly, view it on GitHubhttps://github.com/espressif/esp-aws-iot/issues/180#issuecomment-1547541107, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AGGOKE3XT7SUS3QMG2UZNWLXGH4NNANCNFSM6AAAAAAXPIY4KY. You are receiving this because you were mentioned.Message ID: @.***>

[albatros96]

However, I were doing it, I think I would start with the Unified Provisioning tool and build on that. That code normally is used to securly deliver Wifi credentials from phone to device -- but it could delivery anything. Most of the code you will want is publically available.

Nice to know! Now I have a starting point I can look at!!

The easiest way forward is likely convincing your client that they don't need provisioning by trusted user???

Unfortunately I can't do this in my position. I think it will be a challenge to implement this provisioning but I hope I'll make it work :blush:

Thank you, at the moment I'm not implementing the code and I was trying to find as much informations as I can.

[martmalo]

@filgra96 Hey, I'm currently in the provisioning phase and cannot decide what to choose. I wanted to know what you ended up choosing and what worked best for you?

[albatros96]

@filgra96 Hey, I'm currently in the provisioning phase and cannot decide what to choose. I wanted to know what you ended up choosing and what worked best for you?

In my case the customer choose the provisioning by using an external application.
I'm closing this issue, I'll reopen it if necessary.