Device update with TPM about iot-hub-device-update HOT 15 CLOSED

Hi @neonsoftware,

Thank you for that update! Please refer to this document on how to contribute, that is a good idea.

Thanks!

• @esha0611

from iot-hub-device-update.

Hi @neonsoftware,

Are you planning on using a TPM for storing connection string secrets (SAS Key, cert etc)? If so, you should be able to use a TPM for your connection string just not with the IoT Identity service. You can look at the DU source code from eis_util for an example on how to format your own connection string using the returned secrets from a TPM.

from iot-hub-device-update.

Thanks @ValOlson.

Thanks for the prompt response.

I will take a look at the proposed eis_util sample and also provide more details on the use case within mid-next week.

Will keep you and @nihemstr updated here.

Wishing you both an outstanding week,
FC

from iot-hub-device-update.

Hi @ValOlson and @nihemstr,

Here is some more information.

1. our use case:
   recap of context: mips linux board which has TPM, openwrt os, no-edge
   use case: at connection-creation-time, we already use the TPM create a IoTHub connection in our main application,
   via IoTHubClient_Auth_CreateFromDeviceAuth.
   No tokens or any other information is needed or stored in the device
   Adding the Device Update we would like to maintain this information-less scenario.

2. the impression from eis_util:
   By seeing current implementation it seems that the vision is:
   "device update always takes a connection string, and how to get the connection string from all sorts of authentication should be dealt elsewhere ".
   In the case of eis_utils, it's another process, and IPC exchange.

3. questions:
   a) Is the scenario in point 1, where one only uses the TPM chip and never stores tokens feasible/correct (IoTHubClient_Auth_CreateFromDeviceAuth underneath contacts the provisioning service at each re-connection) or should one start with TPM then continue with tokens ?
   b) Are my impressions on point 2 correct ?
   c) I would be ok to re-create a situation similar to eis: creating a single process in the system that connects with TPM, and assembles a connection string from it and makes it available through IPC. Only I cannot seem to find in the SDK they way to extreact the tokens from the provisioning service using TPM.
   Is it there and I missed it ?

Thanks in advance for taking a look.
Have a great day

from iot-hub-device-update.

Hi @neonsoftware,

Thank you for sharing addition details.

Adding responses below for your questions a,b and c:

a) What we had suggested above is one way how Device Update (DU) could get the connection strings from a custom eis_util because you cannot use IoTEdge or IoT Identity service. I would defer to my IoTEdge colleague Micah to confirm if there are any other best practices for #1 and #2.
b) Yes, the IoT Identity service could be treated as a separate process that DU interacts with over IPC exchange.
c) I will defer to Micah to share where in the IoTEdge SDK you can they find this.

from iot-hub-device-update.

Looks like Cristian answered c) in the issue linked above.

from iot-hub-device-update.

Hi,

Thank you all for the follow-up.

Yes there have been responses on the other issue, although the subject is still internally open.

Follow-up analysis will be performed within this and next week, I will report here.

Thank you for keeping the issue open.

from iot-hub-device-update.

Hi @ValOlson,

Yes, it will probably be a custom eis_util as you described.
And in C99, for the reasons above.
And, possibly, via custom_hsm as pointed in the issue linked above as possible solution.

Device Update, when using eis_util, operates as a module.

Before implementation attempts I will wait for the information if, by-design, a solution custom_hsm might work with both devices and modules.

I will keep reporting information here.
Have a nice day.

from iot-hub-device-update.

Hi,

I think there is an easier option for using TPM with IoT Hub device update.

This is what I have done, let me know if this correct:

1. Compile iot-sdk-c with use_prov_client and hsm_type_sastoken
2. After flashing the device for the first time, perform TPM device provision based on the SDK example tpm_device_provision and enroll your device to DPS.
3. Modify the adu-agent code so that the IoT Hub security type will be IOTHUB_SECURITY_TYPE_SAS. Also the agent need to be compiled with USE_PROV_MODULE_FULL option.
4. Create a new service that runs before adu-agent. This service will run an executable similar to the SDK prov_dev_client_sample example (modified to work with TPM). This is needed because the provisioning API works with AMQP and the adu-agent is using MQTT.
5. Note that the connection string format should be HostName=<hub_name>;DeviceId=<registartion_id>;UseProvisioning=true and thus it does not contain any secret keys.
6. Now when the agent starts, everything works based on TPM attestation

I can share the code if you want me to. Let me know what do you think

from iot-hub-device-update.

Hi @asbarnes,

Thank you for the information.
Absolutely, willing to look at 360 degrees, it would be interesting to know more.
Point 4. for example. And in point 5., is DeviceId=<registartion_id> the registration id of the DPS TPM enrollemment, instead of the actual hub's deviceId ?

Thanks again in advance,
Have a great day.

from iot-hub-device-update.

Hi,

Regarding point 4 - check out the example from this link. It is based on the SDK example prov_dev_client_sample.

Regarding point 5 - for example, if the TPM registration key (SRK) is sizmf6sllrqe4op4wm576nl26la72rssxmf7i7oag2fbuy7uvbaq and the iot hub url is test-iot-hub.azure.net the connection string will be HostName=test-iot-hub.azure.net;DeviceId=sizmf6sllrqe4op4wm576nl26la72rssxmf7i7oag2fbuy7uvbaq;UseProvisioning=true.

Now the flow is:

1. Step 4 - DPS is used for device provisioning. The secret symmetric key ("nonce challenge") is now inside your TPM.
2. Step 5 - Device update agent is launched and generates SAS token based on the key inside the TPM from the previous step, no communication with the DPS is needed

I'm working on cleaning up the code and doing some more tests and will share it soon.

@ValOlson what do you think about this approach?

from iot-hub-device-update.

[ping] thanks again @asbarnes
Still waiting for time allocation from my team to test this approach, will keep you updated..

from iot-hub-device-update.

Hi @asbarnes ,

The new flow should work in theory, please test it out. From Device Update agent perspective it does matter how its provisioned or connected as long as the Device Update service and agent can communicate over IoT Hub to send OTA updates.

• @nihemstr as well.

from iot-hub-device-update.

Hi @ValOlson,

update

The solution from @asbarnes has worked successfully.
Now connecting with "UseProvisioning=true" with two applications at same time. One as device and one as module.

question:

In order to guarantee future non-regressions I think it might be beneficial the existence of both a simpler documentation and samples.
@ValOlson and others, what would be your opinion ? Should such contribution come as PRs ?

Thank you in advance such info,
Wishing a nice day

from iot-hub-device-update.

@esha0611 did we ever follow up with a detailed method for contribution?

@neonsoftware thank you so much for testing it out! I'm gunna close this Issue as it seems discussion has petered out. If we still have questions or comments on it please feel free to create another issue and we can go from there.

from iot-hub-device-update.