I am doing a hands on IoT Hub, so everything is only my local desktop. In production, I was curious to know where each of the certificates would be placed i.e on Device or IoT Hub or somewhere else :
Root Certificate - Uploaded on Azure Portal
Verified Certificate - Uploaded on Azure Portal
PFX File - On Device
Intermediate Certificates (Chain of Trust) - ???
Root Certificate PEM File - ???
Sorry for this insane question. But I want to know the same. Thanks in advance.
On the device the certificate can be anywhere that makes sense, but the certificate store is probably the best option. You don't need to store the root certificate anywhere though. The IoT Hub service only checks that the thumbprint is valid, but doesn't do any chain validation. The place to do that is in whatever process you're using to register the devices.
That's all different if you're using IoT Hub Provisioning Service though, as that will do chain validation, and the device cert must reside on a TPM.
Related
I am having trouble figuring out how to connect a downstream device to my IoT Central application. There is sample code showing how to do it using symmetric keys, but I am interested in using x509 certificate (https://learn.microsoft.com/en-us/azure/iot-central/core/how-to-connect-iot-edge-transparent-gateway#provision-a-downstream-device). I've tried using the code in the EdgeX509AuthDownstreamDevice sample, but I am not sure what to put for the IOTHUB_HOSTNAME environment variable since IoT Central doesn't expose the IoT Hub. Has anyone gotten this to work?
The variables used are misleading. You don't see the IoTHUB connection string. Below, just replace the device shared key and it should work:
export IOTHUB_DEVICE_CONNECTION_STRING="HostName=edgegateway;DeviceId=thermostat1;SharedAccessKey={your device shared key}"
In the reference architectures for IOT Hub\Central you can easily see how the SAS or X509 Cert is used for device authentication. As an example, look at this MXChip OTA Example. (my notes in pink)
Reference Article: Azure MXChip IoT DevKit Firmware OTA (Over-the-Air)
When we extend out to other Azure Services, can you leverage this authentication for other actions such as downloading files for OTA.
The only approach I can come up with is either:
a) have the download endpoint be secure through obscurity (not great).
b) introduce a shim service and implement an additional authentication layer there.
A seems bad. B seems like a waste. I feel like I'm missing and option C or lack the right info on the Azure-way for this one.
Thanks!
The following are steps for a device download file from the Azure Storage blob container using the IoT Central App:
Configure your IoT Central App for Device file upload.
Upload to the configured storage blob container requested blob for its downloading by device (in my example: container=iotc, deviceId=device123, blobname=test.json)
Generate a device connection string, hostname and sasToken for your IoT Central App, see more implementation details here.
Based on the response from the step 3. use the REST POST request to the underlaying IoT Hub of your IoT Central App for a specific blob references, such as:
{
"correlationId":"****",
"hostName":"****.blob.core.windows.net",
"containerName":"iotc",
"blobName":"device123/test.json",
"sasToken":"?sv=2018-03-28&sr=b&sig=****&se=2021-01-20T10%3A26%3A59Z&sp=rw"
}
Based on the response from the step 4., download the blob using the REST GET request, see the following example:
https://****.blob.core.windows.net/iotc/device123/test.json?sv=2018-03-28&sr=b&sig=****&se=2021-01-20T10%3A26%3A59Z&sp=rw
Notify underlaying IoT Hub of your IoT Central App that the device ended the download process, see the REST POST request. Note, that the correlationId you will received in the step 4.
With regard to my original question about using the authenticated device session to access other Azure services, both in general and specifically for the purpose of downloading files for OTA. This is not possible.
You either need to implement an additional authentication mechanism and your own service, use the service specific SDK in your application or for the case of Blob Storage with firmware updates, use a publicly available download point.
Note: The answer from Roman shows how to upload and access an uploaded file. It may help some who will end up here.
So, in the first place I have connected a DHT11 (temperature sensor) to my RPi (Raspberry Pi) then, in my azure portal I have created an IOT Hub and registered a Virtual device identity in the hub, while creating this (for the first time) I have selected the symmetric keys option as mentioned in the Azure IoT Hub tutorial documentation and then i have written a python script to be executed on my RPI which captures the temp reading and sends it to my iot hub.
Now to understand the security aspects of iot hub, i am trying to exactly replicate the above functionality (sending temp reading to iot hub) but this time using X.509 authentication method.
as of now i have followed this link and generated a certificate and uploaded it to the azure iot hub and verified it as well
OPENSSL - How to generate a proof of possesion for a X509 certificate?
now when i am trying to send the sensor data (DHT11) to the iot device registered in my iot hub it shows device not authorized
i don't understand how to authorize/authenticate a device with the certificate.
i feel i should copy over the certificate onto my raspberry pi and somehow make changes in the code that i am using to send temp data to the iot hub to intimate the iot hub that this device has already got a certificate (valid one)
i don't know how to do this...can somebody please help me out....i want to do this using python
There is a Python X.509 authentication sample here https://github.com/Azure/azure-iot-sdk-python-preview/blob/master/azure-iot-device/samples/advanced-hub-scenarios/send_message_x509.py
This is using the replacement Python SDK which is still in preview but it should still work.
You will need to create a certificate and private key and sign it with the certificate that you have verified on your IoT hub. This process is explained here: https://github.com/Azure/azure-iot-sdk-c/blob/master/tools/CACertificates/CACertificateOverview.md.
Following situation:
our gateways have a TPM and we are going to provision it with per device certificates (issued by our PKI). How could the IoT Hub authentication work?
As far as I know one needs to register the thumbprints of the primary and secondary certificates with the IoT Hub, which is ok.
Later on we would like to use the primary certificate to authenticate a device with the IoT Hub. According to the source code of this project one is supposed to provide certificate's private key
var authWithPrimaryPfx = new DeviceAuthenticationWithX509Certificate(device.Id, primaryCertSecret);
This is something I would like to avoid. I do not want the private key to be in memory (RAM). Is it possible to hash/encrypt and use the result for authentication? How would it work?
We are going to use Windows 10 IoT Enterprise or Linux (NOT Windows 10 IoT Core)
EDIT: Here https://github.com/ms-iot/security/blob/master/Limpet/Limpet.NET/Limpet.cs is the method (SignHmac) used to create a signature for a SAS Token based on the device's primary key directly in the TPM (2.0). I need something similar with a certificate.
#Helikaon,
You can use the new Azure IoT Hub Device Provisioning Service which is now in public preview to register devices using TPM with IoT Hub. You can find more info here:
https://learn.microsoft.com/en-us/azure/iot-dps/about-iot-dps
Rajeev
Can the Azure IoT hub identify the spoofing of identity during the registration process
Assume a new IoT device is joining the IoT hub which is showing the spoofed MAC id to the IoT hub.
Will the Azure IoT hub detect that the device uses spoofed identity.
The Azure IoT Hub Identity Registry is what manages devices identities. You can read some literature about it here.
When it comes to authenticating devices, IoT Hub offers several options that are detailed here.
In a nutshell you have 3 ways to provision a device with unique identity and credentials: using a connection string with a unique ID and Key (which allows to compute a SAS Token on the device), using a SAS Token (which you would have to create offline), or using an X-509 certificate.
The only way a device could try and spoof an identity would be if someone was able to retrieve these unique id and credentials from a legit device or some other source, reason why we strongly recommend leveraging secure storage solutions on the device to not allow for the device credentials to be stolen and reused.
If a device tries to connect using valid credentials already used by another device, then the first device will be disconnected, but beyond this, you can (and it is recommended) to implement some security strategy such as rolling secure keys regularly. These strategies depend on your scenario, device type, the way you plan to provision the devices... IoT Hub gives you the tools to implement what fits your needs.