Device – Cloud Security

Device Authentication

Devices are authenticated using X.509 certificates. The system performs both device authentication with the server, as well as server authentication with the device. Device keys are pre-loaded during the manufacturing process and are tied to a unique device ID. In some cases devices can’t be loaded with a key during the manufacturing process. In these cases, the association is done ad-hoc in the field and requires a privileged logged in user to ensure reliance.

Secure Connectivity

All communication with the devices is using AES-256 encryption over TLS 1.3.

All communication to the IoT broker is done using MQTT, all other protocols are blocked and all ports are closed.

Secure Push Communication

The MQTT channel is utilized for workflows initiated from the cloud, such as remote device configuration, remote maintenance commands (e.g., reboot, activating remote desktop access applications like TeamViewer), software update initiation, and more.

Despite the enduring nature of the open MQTT channel, this approach offers enhanced security compared to configuring the device as a server—i.e., opening a port on the device and firewall to initiate such workflows. The rationale behind this lies in the fact that when one opens a server port, the server is equipped with a TCP Listener for that port, allowing clients to send it a TCP Connect command to initiate a new TCP session. This is precisely what a port scanner does: it sends TCP Connect commands to all potential ports. Conversely, when the device initiates a client session to a server (i.e., the cloud), a port scanner cannot access the open TCP client port. In fact, the firewall already thwarts such attempts before they reach the device. This is because the TCP port opened for the session is not a TCP Listener port. Unlike a TCP Listener port, the client session port does not anticipate receiving TCP Connect commands and disregards them if sent.

Additionally, the mutual authentication function of the MQTT channel enhances security by validating that the source of the TCP packet is the BioT platform and disregards any other sources.

Protecting from protocol vulnerabilities and device side attacks

MQTT messages are inspected for integrity and any message that does not conform to integrity will not be handled.

Auditing

All Microservice applications are logged and audited. This includes:

• Lambda Functions.
• RDS errors.
• User Activity via User Audit Service.
• Event history of AWS account activity, including actions taken through the AWS Management Console, AWS SDKs, command-line tools, and other AWS services.