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.
Related
How can an IoT device which connects to an IoT Hub using the Azure IoT Hub SDK retrieve larger amounts of sensitive data which is part of the device configuration?
I know i can use Device Twins as configuration documents per Device, but those are limited to 8K in total.
I need larger amounts of data in binary format to be transfered to the device when i a device - for example - gets reset to factory defaults or somehow loses it's local storage as part of a hardware fault.
I was thinking about using a D2C method triggering a request which results in a series of C2D or direct method calls to the requesting device transmitting the information in question (basically mimiking request/response behavior). However this feels like a workaround.
My other thought was about transmitting urls to a storage account as part of the device twin properties allowing the device to download the binary information using the Storage SDK, however given the sensitive nature of the information downloaded i can't directly expose this information to the internet using a public accessible container in Azure Storage.
So my last thought was to access a REST API which controls access to the information. However my concern is, that i break out of the secure communication channel, the IoT Hub SDK provides with it's build in communication methods and i have to secure the communication between device and the REST API using some kind of rotating secret anyway which could expose other risks along with a complicated custom implementation.
What is the suggested way of providing access to this kind of device-specific data for Azure IoT Clients?
I do recommend to use a new feature (still in the preview) of the Azure IoT Hub such as a Device Streams.
You can test this new preview feature using my updated tool Azure IoT Hub Tester (see Appendix A2)
While using Azure IoT Edge as a transparent gateway, can downstream devices authenticate using SAS tokens using the Shared Access Policy keys? (device, iothubowner etc?). We have being able to successfully connect using SAS tokens signed by the device primary keys, but trying to do so with Shared Access Policy keys doesn't seem to work.
Note: The devices are using MQTT
I don't think that script (which is an eventhub script) creates the right SAS tokens for IoT Hub. The easiest way to do it is to do it from the Azure Cloud CLI (in the azure portal, click on the ">_" button up in the top nav bar.. then you can run this command:
az iot hub generate-sas-token -n [your iothub name] --policy device --key-type primary --duration [duration in seconds you want the token to be valid]
Try using that SAS token. I tested this tonight with the python paho.mqtt client and it worked fine. It connected to IoT Edge and successfully sent messages to both a module and IoT Hub.
Yes, this should work if the device is not a child device of the Edge Device in IoTHub. Look at these links to find out more about how to add devices as a child device of an Edge Device https://aka.ms/exofdocs and https://aka.ms/iot-edge-offline.
This is because, if the leaf device is a child device, EdgeHub will try to authenticate it locally, and for that it only uses the device’s key.
If the leaf device is not a child device of the Edge Device, then you should be able to connect to the EdgeHub using the device/iothub scoped key, since then the EdgeHub will authenticate the device with IoTHub. Note that the connection string should be of the format –
HostName=.azure-devices.net;DeviceId=;SharedAccessKeyName=;SharedAccessKey=;GatewayHostName=
I am currently thinking about a solution where an IoT device would have more than one possible endpoint to talk to. Like an API for some calls that do not concern telemetry or device twin data.
The connection to the IoT Hub can be secured very well (we will use certificates), and I want to awoid adding a different way of authentication to the architecture.
So my idea right now would be to have a back-end service generate device specific SAS tokens for my APIs, possibly on-demand if requested by the device.
The Cloud-to-device communications guidance mentions configuration data, so it feels like a good way to go. Would it be safe to write these tokens in the desired properties? Would it be safer to use the payload of a cloud-to-device-message? Or should it be done completely differently?
You can create a custom cloud service as a token service that uses an IoT Hub shared access policy with DeviceConnect permissions to create device-scoped tokens.
For more detailed information you can reference "Custom device authentication".
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
From Azure development guide https://azure.microsoft.com/en-us/documentation/articles/iot-hub-devguide, there is a small section (shown as below) talking about device anti-spoofing. It is not clear for me, it says IoT hub stamps every message with properties, but for me device anti-spoofing is that IoT hub to stop receiving messages sent from any spoofed device. Please help to explain how does this work?
Anti-spoofing properties
To avoid device spoofing in device-to-cloud messages, IoT Hub stamps
all messages with the following properties:
ConnectionDeviceId
ConnectionDeviceGenerationId
ConnectionAuthMethod
In IoT Hub there is a device registry that is used to authorize devices to the gateway. After authentication the device is checked against the registry.
When a device is registered with IoT Hub, the device's identity and key are saved in the device registry. This device and key is what the device uses to authenticate to the service.
The generation ID is a key part of this too. When the device is first registered with IoT Hub, a generation ID is assigned to the device. The purpose of this is to distinguish between identity registrations of the same device ID (added, removed, and then later added).
If you're interested in a deeper dive into the IoT Hub architecture see Clemen's 2015 Build talk here.