11 Provisioning

All ExpressLink modules will be equipped with a pre-provisioned hardware root of trust (on chip or external secure element, secure enclave, TPM, iSIM). This will provide the necessary unique identifier (UID) of the module, a key pair (public, private) and will hold a certificate that is signed by a CA shared with AWS as part of ExpressLink program. This certificate will be used to transfer the module public key to the AWS endpoint upon activation.

11.1 ExpressLink Modules Activation

Upon first use, or following a complete factory reset, each ExpressLink module is ready to establish a connection according to the model's specific connectivity capabilities (Wi-Fi, Cellular, ...). In case of Wi-Fi modules, this is possible only after the end-user has provided the module with the proper Wi-Fi credentials for a local, compatible Wi-Fi Access Point (router).

11.1.1 ExpressLink Staging Account Authentication

Each ExpressLink module is ready to establish a connection with a default AWS IoT ExpressLink staging account. The connection is mutually authenticated using the ExpressLink birth certificate (and an AWS server certificate) and upgraded to a secure socket connection (Mutual TLS).

11.1.2 ExpressLink Staging Account Endpoint

During the qualification process, AWS assigns each ExpressLink manufacturing partner a dedicated staging account and the associated, unique AWS endpoint (URL).

11.1.2.1   The assigned staging account endpoint is set as the "factory default" for the Endpoint configuration parameter (see Table 2 - Configuration Dictionary Persistent Keys ).

11.1.3 ExpressLink Birth Certificate

Each ExpressLink device must be provided with an X.509 certificate that conforms to the following specification:

• 11.1.3.1   The Serial Number must contain the device Unique ID (a unique, nonsequential 128-bit or larger number) also assigned as the ExpressLink module ThingName configuration.

• 11.1.3.2   The certificate signature is provided by a Certificate Authority that has been registered by the vendor with AWS IoT Core for the exclusive use of the vendor ExpressLink modules.

• 11.1.3.3   The expiration date is set to no less than 10 years from the device certificate issue.

11.1.4 ExpressLink staging account device registration

Using the staging account endpoint, the ExpressLink module proceeds to login to the AWS IoT Core MQTT broker. If successful, an automated process (JITP or similar) creates a thing and associated policies using an ExpressLink template and appends it to the staging account registry.

11.1.5 ExpressLink MQTT Login signature

Upon successful connection to the broker, ExpressLink modules present an MQTT login string containing anonymous metadata (vendor/model/qualification technical specification) meant to help AWS validate ExpressLink modules from qualified vendors. While the developer might not have direct access to it, they have an opportunity to volunteer additional custom device/project identifiable information using the CustomName configuration parameter (see Table 2 - Configuration Dictionary Persistent Keys .

11.2 ExpressLink Evaluation Kits Quick Connect Flow

ExpressLink Evaluation Kits are able to use the ExpressLink staging account to deliver a fast, out-of-box experience. As soon as connected they are able to publish data to an ExpressLink MQTT topic ("data") and subscribe to any ExpressLink MQTT topic ("state"). AWS provides a simple web application (Quick Connect) to all ExpressLink users to visualize the data published by the Host processor (using animated graphs) and to send customizable commands back to their Host processors.

Developers are also able to register their ExpressLink modules to their private developer's accounts and proceed to application development with a few simple, manual steps, including:

• extracting the device certificate

• uploading it to their private accounts

• updating the ExpressLink endpoint

11.2.1 Run the Quick Connect demo application

The Quick Connect demo application allows you to establish a connection with AWS IoT, all in the space of a few minutes; no dependencies to install, no source code to download and build, and no AWS account required. To run the demo, follow the below steps:

1. If you opened a terminal application previously, be sure to disconnect that application from the serial port.

2. Download the Quick Connect executable:

   • Download for Mac

   • Download for Windows

   • Download for Linux

3. Unzip the package. You will see a config.txt file. Open this and enter the serial port corresponding to the evaluation kit (for example, COM14, /dev/cu.usbserial-12345, and so on) in the serial port field.

4. For wifi kits, enter your wifi credentials in the SSID and Passphrase fields. For cellular kits, you may leave this blank.

5. Run the "Start_Quick_Connect" executable.

The demo will connect to AWS IoT and give you a URL that you can use to visualize data flowing from the device to the cloud using AT+SEND commands. The demo will run for up to two minutes, and afterwards, you will be able to type AT+SEND commands yourself and see the data coming in on the visualizer.

Figure 5 - ExpressLink evaluation kit Quick Connect flow

11.3 ExpressLink Production Onboarding Flow

Onboarding is the process of creating a "thing" corresponding to each physical device in the customer account registry in order to provide access to the account's IoT core services. Each thing must be associated with a valid certificate and access policy document.

In a production flow, ExpressLink customers can use any of a number of automated onboarding techniques as required by their application, including:

• Pre-registration, where the modules' certificates are obtained before assembly and uploaded to the customer account in advance.

• End of (assembly) Line registration, where module certificates are collected after product assembly and individually uploaded to the customer's AWS account.

• End of Line batch registration, where module certificates are collected after product assembly and shipped in batches to the customer for upload into the AWS account.

• Just in Time Registration, where the device onboards to the customer account at first connection. (This requires pre-registration of the module manufacturer's CA to the customer account.)

• Late-binding, where the end product user performs the product onboarding (often simultaneously with the user's own registration, although the two steps should not be confused).

11.3.1 ExpressLink late binding flow example

A late binding onboarding flow can be initiated by the end-user after purchasing the finished product when they connect it for the first time and register the product. The end-user can be directed to a web application devised by the OEM/customer (for example, a toaster manufacturer) that will guide the user through the following steps:

1. Enter Wi-Fi credentials (only for Wi-Fi modules)– this is required to access the AWS cloud. To accomplish this, the host can activate a CONFMODE for credential entry or the host can directly manipulate the configuration dictionary (SSID, Passphrase).

2. Access the ExpressLink staging account for the first time.

3. Claim the ExpressLink module (identified by ThingName) from the staging account.

4. Transfer the certificate to the OEM account registry (thing creation).

5. Update the ExpressLink module Endpoint (to point to the OEM account).

6. Disconnect and reconnect the ExpressLink Device to the OEM account.

Steps 1 and 2 are facilitated by the staging account assigned to each manufacturer and managed by AWS. Steps 3 and 4 require the customer to implement a claim mechanism that interacts with the AWS managed staging account. Step 5 is facilitated by a specific device feature as described in 11.3.2 ExpressLink onboarding states and transitions.

Additional steps to register the user, create an end-user (application) account, collect user identifiable information (user name and password) and bind it to the ExpressLink thing are left to the OEM application.

11.3.2 ExpressLink onboarding states and transitions

The configuration parameter Endpoint (see Table 2 - Configuration Dictionary Persistent Keys ) controls the onboarding state of the device. The device is in the staging state when the Endpoint parameter (string) matches the factory default value that corresponds to an AWS-managed staging account assigned to each manufacturer. The device is in the onboarded state when the Endpoint parameter has been modified to point to a customer account (endpoint) by a host that directly updated the configuration dictionary using a CONF command (see 6.2.1 CONF KEY={value}   »Assignment«) or by means of the following remote update process:

11.3.2.1   When (and only when) in the staging state, a connected ExpressLink module automatically subscribes ONLY to the endpoint-update topic: ThingName/expresslink_config. Then, when it receives a message on the update topic with the following format: {"Endpoint" : "value"}, the module updates the Endpoint configuration parameter with the requested new value.

11.3.2.2   The host can retrieve the MSG event produced (GET0) and use it to implement additional optional features, such as to alert the user of the device of a successful onboarding (registration).

11.3.2.3   The module will also automatically disconnect. The related CONLOST event will inform the host that it must re-establish a new connection, this time to the newly assigned endpoint.

11.3.2.4   The host can query the state of the module using the CONNECT? command and inspecting the second numerical parameter provided in the response (see 4.7.1 CONNECT?   »Request the connection status«) without having to inspect the contents of the Endpoint configuration parameter (or knowing or assuming the default Endpoint value to compare against).

11.3.2.5   When (and only when) in the onboarded state, a connected ExpressLink module subscribes automatically to several AWS-reserved topics as required to support OTA and other core ExpressLink functionality. In the same way, features dependent on the AWS IoT Device Defender and AWS IoT Device Shadow services are supported only when a module is in the onboarded state.

Figure 6 - ExpressLink onboarding states diagram

 

Once onboarded, all ExpressLink modules behave as fully owned devices and connect to the customer/OEM account as the ExpressLink things are transferred to the chosen OEM registry. It is the responsibility of the OEM to manage the product life cycle, use the OTA services to apply module updates (with images provided by the ExpressLink module vendor) and apply host processor application updates as needed.

11.4 End-User change, product re-registration

This is a normal occurrence in the life of many products when they are resold or disposed of. If required, ExpressLink modules can be reset to factory settings to reactivate the onboarding process from the beginning and eliminate any previous owner association.

11.5 Handling onboarding failures

The onboarding process can fail at various points due to end-user, host application, or network errors. We envision the following scenarios:

• Onboarding process failure: if the OEM misconfigures the account policies this would prevent the device certificate from being moved into the target account. The AWS IoT API will report this type of error to OEM developers during testing.

• Onboarding process failure: if the ExpressLink claim and removal from the staging account fails this would leave it in the staging account while a new thing is created in the OEM account and the ExpressLink module is redirected to the new endpoint. Staging account periodic cleaning and fraud detection sweeps will clear the anomaly in a short time.

• Endpoint Update failure: if the device does not receive the ExpressLink endpoint update message it remains in the staging account and fails to connect to the target OEM account within a given amount of time. The binding process (web application) can be designed to timeout and guide the user to repeat the procedure until successful.

• Accidental product factory reset: in this case, the ExpressLink device will rejoin the staging account as soon as connectivity is regained, and the onboarding process can be restarted at any time. The OEM application will be able to detect that an already registered device is re-applying to onboarding and could possibly help to restore the product status and/or report the error to developers.