How to maintain/upgrade your device authentication/authorization scheme when migrating to AWS IoT Core

1. Use case description

AnyCompany Ltd is currently using a Hosted MQTT broker solution to collect data from 2 families of IoT devices (Device family 1 & Device family 2).

The devices authenticate to the broker service online with MQTT username and password combination sent over a TLS connection. AnyCompany is willing to understand how that same security posture can be replicated (or improved, if possible) when migrating to AWS IoT.

2. AnyCompany current IoT infrastructure.

2.1. Architecture

To allow some flexibility on MQTT Broker selection (avoid the constraint to make updates to their whole device fleet if MQTT Broker changes), AnyCompany has set the MQTT broker address in all their devices with an intermediate domain name (iot.anycompany.com) and embed the corresponding CA Certificate. That domain name currently resolves to a load balancer that perform TLS termination and distributes traffic to a cluster of Proxy servers. Finally, the proxy servers are the ones performing the actual TCP /TLS connections to the MQTT broker provider broker.domain.com.

The broker service verifies username/password provided by the client device against an internal credentials database provided by the broker (and configurable by AnyCompany). If authentication is successful, broker service checks if the requested operation (Publish / Subscribe) is authorized by checking a policy document corresponding to the MQTT client.

The current broker also offers options to query an external database or Web service to validate client credentials but authorization still uses policy document.

2.2. Connectivity details summary

Connection item	Value	Comment
Hosted Broker
Actual Broker URL	broker.domain.com	Endpoint address provided by broker
Actual broker unencrypted MQTT Port	1883	Endpoint port provided by broker for plain MQTT
Actual Broker TLS/SSL Port	8883	Endpoint port provided by broker for MQTT over TLS
Broker Server Certificate	broker.pem	Public certificate presented by the broker to client devices
Devices
Broker URL set in the device	iot.anycompany.com	Intermediate domain
Broker SSL/TLS secure port(s) set in the device	8080 (family 1); 8081 (family 2)	Target Broker port set in each device family software
Server certificate	iot-anycompany-com.pem	public certificate registered for domain "iot.anycompany.com"
Client authentication mode	username/password	username/password credentials maintained through a broker-provided portal
ALPN	None	Clients do not specify ALPN negotiation in TLS Hello message
Proxy
Proxy/Intermediate domain name	iot.anycompany.com
Proxy certificate	iot-anycompany-com.pem	public certificate registered for domain "iot.anycompany.com"

3. AnyCompany migration to AWS IoT Core

Below is a step-by-step guide on how AnyCompany can seamlessly enable client devices to connect to AWS IoT Core keeping the same authentication/authorization pattern.

3.1. Step 1: Identify AnyCompany future AWS IoT Core Endpoint

Upon AWS Account creation, AWS IoT Core assigns a default account-specific IoT endpoint in each region; only TLS access (v1.2 or v1.3) is accepted, to optimize your security posture.

To check the IoT Core data endpoint details, connect to AWS IoT Core Console in the closest region(s) (the closest to the devices, to minimize latency). In the left navigation bar, look for Settings. On the Settings page, look for Endpoint. The ‘endpoint’ address is in this format: account-specific-prefix.iot.aws-region.amazonaws.com.

Alternatively, AWS CLI may be used, as per the documentation here:

aws iot describe-endpoint --endpoint-type iot:Data-ATS

3.2. Step 2: Confirm the protocol and ports AnyCompany devices will use to communicate with AWS IoT Core

AnyCompany future destination ports on AWS IoT Core depend on the protocol the company intends to use for the connection and the authentication scheme. Refer to the developer guide for the updated mapping.

“Username/password” authentication currently being used falls under AWS IoT “custom authentication” category. To use it on a MQTT over TLS connection, it is required for device clients to use port 443, set ALPN to ‘mqtt’, and highly-recommended to use SNI feature of TLS (check here for details).

But, since AnyCompany is using an intermediate domain with proxy servers, clients can be left untouched and these changes implemented on the proxy servers only.

Connection item	Value	Comment
AWS IoT Core
Actual Broker URL	account-specific-prefix.iot.aws-region.amazonaws.com.	Default AWS IoT Core Endpoint address
Actual broker unencrypted MQTT Port	1883	Endpoint port for plain MQTT
Actual Broker TLS/SSL Port	443	Endpoint port provided by broker for MQTT over TLS
Broker Server Certificate	AmazonRootCA1.pem	Default public certificate presented by IoT Core to client devices
Devices
Broker URL set in the device	iot.anycompany.com	Intermediate domain
Broker SSL/TLS secure port(s) set in the device	8080 (family 1); 8081 (family 2)	Target Broker port set in each device family software
Server certificate	iot-anycompany-com.pem	public certificate registered for domain "iot.anycompany.com"
Client authentication mode	username/password	username/password credentials maintained through a broker-provided portal
ALPN	mqtt	Protocol to advertise in TLS connection request. Required for MQTT over TLS Custom Authentication
SNI	account-specific-prefix.iot.aws-region.amazonaws.com.	Default server name to include in TLS connection request. Strongly recommended
Proxy
Proxy/Intermediate domain name	iot.anycompany.com
Proxy certificate	iot-anycompany-com.pem	public certificate registered for domain "iot.anycompany.com"

3.3. Step 3: Leverage Custom Authorizers, Configurable Endpoints with Custom Domains and AWS IoT Core VPC Endpoint features

There are several features on AWS IoT Core that can help AnyCompany migration on both security and connectivity aspects.

First, AWS IoT Core lets you define "Custom Authorizers" that allow you to fully create and manage client devices authentication and authorization logic. Practically, this consists of:

• A lambda function on AWS that will handle both devices authentication and authorization logic, written in your favorite programming language.
• a “custom authorizer” object on AWS IoT Core, that formally binds the lambda function to your AWS IoT Core broker (so it can be called anytime a specific client sends a connection request to your endpoint).

Then, Domain Configurations let you specify a custom fully qualified domain name (FQDN) to connect to AWS IoT Core in lieu of the default AWS endpoint address provided with your account. Therefore, AnyCompany now has the possibility to map any domain name they own directly to AWS IoT Core for:

• TLS termination (using same certificate “iot-anycompany-com.pem” already in the devices)
• devices authentication

Finally, using interface VPC endpoints with AWS IoT Core, AnyCompany can create IoT data endpoints directly within a VPC. This is particularly useful when incoming traffic from the devices is going through an AWS load balancer; in that case, IoT data endpoints created in the load balancer VPC can be targeted directly using their private IP addresses (as they share the same address space).

4. AnyCompany Architecture with AWS IoT Core

Below are architectural updates that can be applied to the former architecture diagram (leveraging and implementing AWS IoT Core features mentioned above).

As the changes implemented obviously depend on the devices capabilities and the level of control/access AnyCompany has on their current devices fleet, 3 different cases are presented.

4.1. Devices in AnyCompany fleet do not support ALPN and SNI (or access to the fleet is constraint)

A comparative picture of Connectivity & Authentication/Authorization before and after migration.

Comparing the 2 scenarios from a high-level perspective, at least 2 major details can be outlined:

1. The segment between the load balancer and the broker now belongs to a single unified environment (VPC - Virtual Private Cloud) owned by AnyCompany. Incoming traffic stays within AWS global insfrastructure, as opposed to traffic between proxy servers and MQTT broker over public internet previously.
2. The authentication/authorization logic on the right-side is now fully under AnyCompany management, through the Authorizer Lambda function and potentially other services under their AWS Account.

Having full hand over the authentication/authorization logic now allows AnyCompany to go beyond plain username/password verification against a database, and adjust their authorization mechanism to include potentially broader elements of decision:

• manage prohibited devices lists,
• implement rules on access hours or holidays,
• leverage virtually any external system for extra-verification,
• etc.

All this logic is fully owned and written by AnyCompany team in their favorite programming language (provided it is supported by AWS Lambda).

As for the single unified environment, it is only possible thanks to “domain configuration” feature mentioned above. Domain certificate (”iot-anycompany-com.pem“ already present in the devices) and actual MQTT clients authentication are both handled by AWS IoT Core.

Note that every time a domain configuration is created/set, it is possible to directly specify its default authorizer. This can be very helpful, as the default authorizer lambda function will be the default one triggered by AWS IoT Core broker every time a non-authenticated client sends a MQTT connection request with that domain name as target.

Also note that on the new architecture, “Proxy” servers are kept solely because the existing devices do not specify ALPN and SNI when initiating the TLS sessions. TLS termination is done by the load balancer and new TLS with proper ALPN and SNI parameters is still initiated by the proxy.

4.2. Devices in the fleet can set ALPN and SNI with custom ports

If updating AnyCompany devices fleet (to set ALPN and SNI in client requests) can be done with low effort, then the architecture access part becomes much more straightforward.

Here, Load balancer does not terminate the TLS session anymore, but only takes care of TCP port forwarding to the IoT Core data endpoints on port 443. The Proxy servers are not required anymore, resulting in immediate cost savings and obvious performances improvement expectations.

4.3. Devices in the fleet can set ALPN and SNI with AWS IoT Core port (443)

If, in addition to setting the ALPN and SNI on clients, AnyCompany is ready to change the custom ports set in the devices to match with AWS IoT Core port 443, then the entire VPC environment becomes unnecessary, and domain iot.anycompany.com can be configured to map with AWS IoT endpoint address directly (through a CNAME record entry in Anycompany domain hosting for example).

The security here is guaranteed by TLS (v1.2 or v1.3) standard security features and some Out-of-the-box extra security features to ensure infrastructure security and monitoring.

5. More security tools for AnyCompany on AWS IoT Core

In addition to the possibilities already mentioned, here are more options available for AnyCompany to implement extra security at any stage:

• Load Balancer, with features like security compliance validation to align with any Industry-specific security requirement
• VPC security, with Security groups or Network Access-Control List (ACL)
• VPC Endpoint access control
• AWS IoT Core security, with out-of-the-box IoT security monitoring features like AWS IoT Device defender to analyze, audit, and monitor connected devices to detect abnormal behavior, and mitigate security risks.

6. Key Takeaways and further reading

Migrating from your current MQTT broker to AWS IoT Core requires a careful review of several key aspects like functionality, data security and risk assessment, migration costs, etc.

In this article, through a pretty common use case, we presented several tools you can leverage to not only maintain, but upgrade your current IoT security posture while moving from any MQTT broker to an AWS IoT environment.

To learn more about planning aspects for your migration to AWS IoT Core, refer to this blog post or this video breakdown.