Just read this thread
What I am still asking myself though is whether the IoT Hub does detect that there are multiple active connections that use the same deviceid and credentials?
This could be the case if an attacker would steal the device auth key or the SAS token.
The anti-spoofing property ConnectionDeviceGenerationId does not seem to be used for this since:
generationId - An IoT hub-generated, case-sensitive string up to 128 characters long. This value is used to distinguish devices with the same deviceId, when they have been deleted and re-created.
What I am still asking myself though is whether the IoT Hub does
detect that there are multiple active connections that use the same
deviceid and credentials?
For AMQP and HTTP, when sending Device-To-Cloud messages,multiple active connections using the same device id are able to work properly. But when receiving Cloud-To-Device messages it doesn't work.
But for MQTT, IoT Hub only supports one active MQTT connection per device. Any new MQTT connection on behalf of the same device ID causes IoT Hub to drop the existing connection.
Update:
IoT Hub allows devices to use MQTT, MQTT over WebSockets, AMQP, AMQP over WebSockets, and HTTP protocols for device-side communications. The following table provides the high-level recommendations for your choice of protocol:
MQTT(MQTT over WebSocket)
Use on all devices that do not require to connect multiple devices (each with its own per-device credentials) over the same TLS connection.
AMQP (AMQP over WebSocket)
Use on field and cloud gateways to take advantage of connection multiplexing across devices.
HTTP
Use for devices that cannot support other protocols.
Related
I want to Forward messages from Cloud MQTT broker to Azure IOT Hub. I need the settings examples to create the bridge for multiple devices which can be accessible with Shared access key of IOT Hub rather than SAS for specific device. and can we use the single bridge for multiple devices or it needs single bridge for each device?
Note that IoT Hub is not a full-featured MQTT broker and does not support all the behaviors specified in the MQTT v3.1.1 standard.
A device can use the MQTT protocol to connect to an IoT hub using any of the following options:
Libraries in the Azure IoT SDKs.
The MQTT protocol directly.
can we use the single bridge for multiple devices or it needs single
bridge for each device?
AFAIK, Using the same connection string is not supported and you will see unexpected errors. Only one device can use the same connection string at a time. For example if you have two devices connecting with the same ID, then it would be difficult to identify where to send messages. You can use Modules Instead.
To answer your specific query, If your business scenario requires only sending a telemetry data (D2C messages), you can use a connection less device protocol such as the https using the REST API, with a sasToken for authorization header.
Also, see Using the MQTT protocol directly (as a device)
I'm looking into Azure IoT Hub and IoT Edge to understand capabilities and potential use cases roughly. One of the projects I had worked in the past had a strict requirement to disable cloud initiated contact and make things to work based on device initiated polling. For example, when certain settings are changed on the device management portal or new firmware is made available, rather than pushing this down to the devices, each device would become aware of this by polling periodically.
I have no control over this requirement but if that project is to be moved to Azure IoT, I'm certain that the same is going to be requested. Is there an easy way to achieve this with Azure?
I thought about tempering with the network access of the relevant containers but would this lead to the IoT hub going crazy and trying to communicate with 'unresponsive' devices continuously and flag all these failed attempts?
There are two parts to this quest: connections, and messages.
Connections
As far as connections are concerned, one of the security principles of IoT Hub is that the device is responsible for setting up the connection. Azure IoT devices by default do not accept incoming connections. The device sets up an AMQP or MQTT connection with IoT Hub, which will then allow bi-directional communication.
An exception to this is the HTTPS connection, if you use that method, the device will poll IoT Hub for new messages.
Messages
When the bi-directional connection is initiated from the device, this allows the device and IoT Hub to send messages to each other. For a non-edge device, if you don't use the SDK and write your (for instance MQTT) code yourself, you can decide not to listen to any of the incoming messages. You won't subscribe to topics like direct methods and twin updates and only look for them when you want.
For IoT Edge devices, bi-directional communication is handled by the Edge Hub. So your other containers (modules) don't talk to the cloud directly.
That leaves the Edge Agent, which also deals with outgoing connections only, it reports the status of the modules to the cloud.
In the comment of your question, you mention that the requirement is that the cloud can't initiate a connection with the device. In short, that doesn't happen, IoT Hub isn't designed that way.
In our scenario, we have a bunch of devices that communicate locally with a gateway. The gateway is responsible to aggregate events from the devices and send it to the cloud. It should also receive device configuration changes from the the cloud and transport it to the specific device.
Based on my reading I would think that this is actually a typical IoT Hub scenario. And we would very much like to use the device management, messaging and maybe even twins that IoT Hub provides.
However, the way the devices communicate is already implemented and shall not be changed. That means the devices themselves cannot create connections and provide IoT Hub credentials. This rules out using the azure-iot-protocol-gateway or similar.
We would rather need the gateway to act as a device that can act on behalf of other devices. The gateway would detect which devices are in his local network and subscribe to their topics (via MQTT or AMQP).
Is this even possible? Can devices send events or listen to Cloud-To-Device messages in place of other devices?
Your scenario is a perfect fit for Azure IoT Edge:
https://learn.microsoft.com/en-us/azure/iot-edge/
"Azure IoT Edge is an Internet of Things (IoT) service that builds on top of IoT Hub. This service is meant for customers who want to analyze data on devices, a.k.a. "at the edge", instead of in the cloud. By moving parts of your workload to the edge, your devices can spend less time sending messages to the cloud and react more quickly to changes in status."
And I would suggest that you use IoT Edge as an identity or protocol translation Gateway:
https://learn.microsoft.com/en-us/azure/iot-edge/iot-edge-as-gateway
"Gateways in IoT solutions provide device connectivity and edge analytics to IoT devices that otherwise wouldn't have those capabilities. Azure IoT Edge can be used to satisfy all needs for an IoT gateway regardless of whether they are related to connectivity, identity, or edge analytics. "
In our scenario, we have a bunch of devices that communicate locally with a gateway. The gateway is responsible to aggregate events from the devices and send it to the cloud. It should also receive device configuration changes from the the cloud and transport it to the specific device.
Based on my reading I would think that this is actually a typical IoT Hub scenario. And we would very much like to use the device management, messaging and maybe even twins that IoT Hub provides.
However, the way the devices communicate is already implemented and shall not be changed. That means the devices themselves cannot create connections and provide IoT Hub credentials. This rules out using the azure-iot-protocol-gateway or similar.
We would rather need the gateway to act as a device that can act on behalf of other devices. The gateway would detect which devices are in his local network and subscribe to their topics (via MQTT or AMQP).
Is this even possible? Can devices send events or listen to Cloud-To-Device messages in place of other devices?
Your scenario is a perfect fit for Azure IoT Edge:
https://learn.microsoft.com/en-us/azure/iot-edge/
"Azure IoT Edge is an Internet of Things (IoT) service that builds on top of IoT Hub. This service is meant for customers who want to analyze data on devices, a.k.a. "at the edge", instead of in the cloud. By moving parts of your workload to the edge, your devices can spend less time sending messages to the cloud and react more quickly to changes in status."
And I would suggest that you use IoT Edge as an identity or protocol translation Gateway:
https://learn.microsoft.com/en-us/azure/iot-edge/iot-edge-as-gateway
"Gateways in IoT solutions provide device connectivity and edge analytics to IoT devices that otherwise wouldn't have those capabilities. Azure IoT Edge can be used to satisfy all needs for an IoT gateway regardless of whether they are related to connectivity, identity, or edge analytics. "
I am consuming messages from the Azure Event Hub to my application and I am successfully receiving the messages. I want to know whether the messages sent from the Event Hub is encrypted. I searched in learn.microsoft.com but could not find much information. It would be a great help if anyone can help me out to understand.
Short answer: yes.
As you can find in the docs:
Any entity that reads event data from an event hub is an event consumer. All Event Hubs consumers connect via the AMQP 1.0 session and events are delivered through the session as they become available...
Now, there is more documentation around the use of AMQP regarding to the Service Bus and Event Hub, it can be found here:
It is the primary protocol of Azure Service Bus Messaging and Azure Event Hubs. Both services also support HTTPS.
and, more important in this context:
Azure Service Bus ( note: also Event Hub ) requires the use of TLS at all times. It supports connections over TCP port 5671, whereby the TCP connection is first overlaid with TLS before entering the AMQP protocol handshake, and also supports connections over TCP port 5672 whereby the server immediately offers a mandatory upgrade of connection to TLS using the AMQP-prescribed model. The AMQP WebSockets binding creates a tunnel over TCP port 443 that is then equivalent to AMQP 5671 connections.
In addition, Event Hub data is encrypted at rest, see [the docs])(https://learn.microsoft.com/en-us/azure/security/azure-security-encryption-atrest)