6.4 Amazon Sidewalk BLE features

6.4.1 Endpoint-initiated Encrypted Connection

It is assumed that an Endpoint is registered and time synchronized. Process flow is presented in 6.16. Obfuscated TXID and Amazon Sidewalk internal server ID are used in the advertisement packet. Details of frames content are presented in 6.2.

BLE Endpoint initiated encrypted connection

fig 6.16 BLE Endpoint initiated encrypted connection

The connection request advertisement is an on-demand procedure when an application needs to send an uplink packet but no active connection to the Amazon Sidewalk Cloud is available. A connection request from an Endpoint application API is handled by an Endpoint SDK to translate into a connection request advertisement. The Amazon Sidewalk BLE Gateway forwards the connection request advertisement to the Amazon Sidewalk internal server as a Report Beacon message. The Amazon Sidewalk internal server, based on decoded content, builds a challenge request and sends it back to a BLE Gateway which then forwards the challenge request to the Endpoint over RF. After successful reception and authentication, the Endpoint SDK notifies the application of confirmation of link existence after which the application can send uplink data traffic over the Amazon Sidewalk network.

The encrypted link is disconnected due to timeouts and message decryption errors.

6.4.2 Device-to-Device Communication (D2D)

Device to device (D2D) functionality describes encrypted connection of the Amazon Sidewalk Mobile SDK hosted on a mobile phone and an Endpoint. D2D functionality encompasses Amazon Sidewalk Mobile SDK authentication to the Amazon Sidewalk Cloud and encrypted channel establishment between the Mobile Application and an Endpoint.

The core of D2D functionality is the Mobile Application to Endpoint device key (D2D_PRIMARY_KEY) that is established on the Endpoint and on the Mobile Application. The customer owning an Endpoint can have more than one instance of the Mobile Application in the Amazon Sidewalk environment. Two basic cases are possible:

1x1 configuration - one Mobile Application handles the Endpoint.
Nx1 configuration - multiple Mobile Applications instances with the Endpoint belonging to the customer. All instances of the Mobile Application have the same D2D_PRIMARY_KEY.

D2D_PRIMARY_KEY is generated independently on the Mobile Application and the Endpoint in case of 1x1 configuration. When an additional instance of the Mobile Application is created (Nx1 configuration) then this additional instance of the Mobile Application gets the D2D_PRIMARY_KEY from the Endpoint using a session key.

D2D_PRIMARY_KEY is the input parameter for derivation of the D2D_GCM_KEY, and for derivation of the D2D_GCM_CTRREF_KEY that are used in encrypted communication between the Mobile Application and the Endpoint with either time-based reference or counter-based reference (see Chapter 6.3 for the derivation formula).

D2D connection establishment is the base for data exchange between the Mobile Application and the Endpoint. D2D session establishment, Custom class, Challenge request/response and Metrics commands are supported on D2D communication.

6.4.2.1 D2D communication scenarios

D2D communications between the Mobile Application, the Amazon Sidewalk Cloud and the Endpoint include the following:

The Endpoint is not registered
- Mobile activity
  1. Detects Endpoint proximity based on Beacon data.
  2. Starts establishing the encrypted channel with the cloud and the Endpoint.
  3. At the end of establishing the encrypted channel:
    1. Mobile Application instance will have the D2D_PRIMARY_KEY and the frequency of D2D_GCM_KEY key rotation.
  4. If channel establishment fails or the BLE link disconnects, and a D2D_PRIMARY_KEY was generated, that key is discarded.
- Cloud activity
  
  Supports mobile to establish the encrypted channel establishment by validating the Endpoint with signature verification from the Endpoint.
- Endpoint activity
  1. Performs signature verification from the cloud via a Mobile Application to verify it is communicating with a trusted source.
  2. At the end of the procedure of establishing the channel:
    1. The Endpoint will have the D2D_PRIMARY_KEY and the frequency of D2D_GCM_KEY key rotation.
  3. In case of failure or disconnection of BLE link, D2D_PRIMARY_KEY is discarded if generated.
The Endpoint is registered and Mobile Application has Mobile to device key
- Mobile activity
  1. Checks if the Endpoint is registered with the Beacon data and:
    1. if authentication material is present, authenticates the obfuscated TXID with the authentication material for the Amazon Sidewalk ID.
    2. if authentication material is not present, requests that the cloud to identify the device and receives the authentication material.
    3. if Endpoint is requesting time sync, Mobile Application shall request that the Amazon Sidewalk Cloud provide time to the Endpoint
  2. Establishes direct BLE connection to exchange data using time-based encryption
    (D2D_GCM_KEY key).
- Cloud activity
  
  Performs the Endpoint authentication on the mobile request and provides authentication material to the Mobile Application.
- Endpoint activity
  
  Decrypts the packet (using D2D_GCM_KEY key) and provide the payload to application.
The Endpoint is registered and mobile does not have Mobile to device key
- Mobile activity
  1. Checks if the Endpoint is registered with the Beacon data and:
    1. if authenticated material is present, authenticates the obfuscated TXID with the authentication material for the Amazon Sidewalk ID.
    2. if authenticated material is not present, requests that the cloud identify the device and receives the authentication material.
    3. if Endpoint is requesting time sync, Mobile Application shall request that the Amazon Sidewalk Cloud provide time to the Endpoint
  2. Requests the cloud to send a challenge request to the Endpoint. The Endpoint shall respond with its challenge response to the cloud for authentication and the Endpoint shall open up the encrypted session channel.
  3. Starts the procedure of establishing the encrypted channel and derives the session key. A derived key from the session key shall be used to get the D2D_PRIMARY_KEY from the Endpoint.
- Cloud activity
  1. Performs the Endpoint authentication on the mobile request and provides authentication material to the Mobile Application.
  2. Sends the challenge request to the Endpoint via the Mobile Application.
  3. Validates the challenge response from the Endpoint.
- Endpoint activity
  1. Validates the challenge request. When the validation is successful then sends the challenge response to the cloud.
  2. Opens up the gate to honor commands required for establishing an encrypted session and derivation of session key.
  3. Derived key from session key shall be used to share the D2D_PRIMARY_KEY to the Mobile Application.
The Endpoint is registered and both the Endpoint and Mobile Application do not have primary key
- Mobile activity
  1. Checks if the Endpoint is registered with the Beacon data and:
    1. if authenticated material is present, authenticates the obfuscated TXID with the authentication material for the Amazon Sidewalk ID.
    2. if authenticate material is not present, requests that the cloud identify the device and receives the authentication material.
    3. if the Endpoint is requesting time sync, the Mobile Application shall request that the Amazon Sidewalk Cloud provide time to the Endpoint.
  2. Requests that the cloud send a challenge request to the Endpoint. The Endpoint shall respond with its challenge response to the cloud for verification.
  3. Starts the procedure of establishing the encrypted channel and derives the session key. Since the Endpoint does not have the D2D_PRIMARY_KEY, the Endpoint shall store the session key as D2D_PRIMARY_KEY. D2D_PRIMARY_KEY is shared using a derived key from session key.
- Cloud activity
  1. Performs the Endpoint authentication on the mobile request and provides authentication material to the Mobile Application.
  2. Sends the challenge request to the Endpoint via the Mobile Application.
  3. Validates the challenge response from the Endpoint.
- Endpoint activity
  1. Validates the challenge request. When the validation is successful then sends the challenge response to the cloud.
  2. Opens up the gate to honor commands required for establishing an encrypted session and derivation of session key.
  3. Derived key from session key shall be used to share the D2D_PRIMARY_KEY to the Mobile Application.
The Endpoint is registered to another user

The Amazon Sidewalk Cloud shall prevent D2D communication from the Mobile Application to the Endpoint by not providing the authentication material to the Mobile Application.

6.4.3 Touchless Registration (Frustration-Free Network)

Frustration-Free Network (FFN) is a procedure where an Endpoint is registered onto the Amazon Sidewalk network without user interaction (Touchless). Simplified architecture diagram is presented in 6.17.

BLE FFN architecture

fig 6.17 BLE FFN architecture

There are three types of user accounts possible to provide FFN setup:

User account type	Registration type
Amazon account	Type A registration
Enterprise/Partner account	Type B registration
No account (WAN use cases)	Type C registration

Setup options are presented in 6.18.

BLE FFN touchless registration flow

fig 6.18 BLE FFN touchless registration flow

The FFN process consists of two preliminary steps: Amazon Sidewalk registration and initialization session and actual registration in the Amazon Sidewalk system. During the FFN procedure the Endpoint is verified and authenticated by the Amazon Sidewalk Cloud and the credentials, and the key and configuration are stored in the Endpoint and in the cloud registry. Following completion of the FFN procedure, the BLE link is disconnected. The Endpoint is then ready to establish a link with its updated key and configuration. Using the link, the Endpoint can obtain time information and perform any required Amazon Sidewalk functionality.

For detailed flow diagrams see: 6.19, and 6.20.

BLE Endpoint registration 1of2

fig 6.19 BLE Endpoint registration 1of2

BLE Endpoint registration 2of2

fig 6.20 BLE Endpoint registration 2of2

6.4.4 Time Sync trigger over Amazon Sidewalk BLE Beacon

Time Synchronization with a common time source is a prerequisite for the operation of time-based authentication materials and encryption of messages in normal operation mode. During the boot-up process, the internal clock in the Endpoint is not synchronized with the NTP source, therefore counter-based synchronization is carried out in the first stage of establishing the connection. The counter is represented by 4 B length TimeSync.

The synchronization process is as follows: An Endpoint sends the TimeSync Beacon to the Gateway and the Gateway forwards the TimeSync Beacon once every 30 s to the Amazon Sidewalk TimeSync Server. The Amazon Sidewalk TimeSync server, based on the received Beacon, authenticates the counter-based TXID and sends back to the Gateway a notify Response Time with one time authentication key. Gateway provides the reference time to the Endpoint. After authenticating the response time, the Endpoint disconnects the BLE link and changes its state to obfuscated time-based TXID.

During normal operation mode, the Endpoint will move to periodic TimeSync mode once every 2 h for 60 s to correct time drift. If the time cannot be synced, then the Endpoint shall remain time synced and Beacon with obfuscated time-based TXID for normal operation. When the Endpoint detects the drift to be more than 60 s, then the Endpoint will reset the network time and more into TimeSync request mode till the Endpoint receives a time from the Amazon Sidewalk Cloud.

BLE TimeSync flow

fig 6.21 BLE TimeSync flow

For details of the events used for time synchronization, and the periodicity of events, see Table 6.6.

Table 6.6 Periodicity of TimeSync events

TimeSync events	Periodicity	Comments
Beaconing Interval	160ms for the first 30s after boot and 1s afterward
Time sync beacons Upload from gateway	30 sec
Periodic time sync request (counter-based)	Every 2 hours	For 60 seconds

6.4.5 Network Key Refresh

6.4.5.1 Introduction

Sufficiently frequent key exchange is essential to avoid system compromise. Based on estimation of traffic and keys’ complexity, the key refresh procedure is to be triggered periodically for the Endpoint. This periodicity is configurable by the Amazon Sidewalk Cloud. The network key refresh process is similar to the registration procedure. The network key refresh process is triggered by the cloud service in the Amazon Sidewalk system. Due to available bandwidth in the BLE channel, the impact for the system performance during executing network key refreshing procedure can be neglected.

Due to lack of a direct TCP link between Endpoint and Network Server an intermediate state of the state machine maintaining both established (previous) keys and current (new) keys is necessary.

6.4.5.2 Key Refresh Flow

Key refreshing scheduler initiates Key Refresh process using a time-based policy for cloud-initiated Key Refresh request.
Keep track of Key Refresh state and update flag Key Refresh pending if the Endpoint is not in a pending reset state.
Perform the Key Refresh if the Endpoint is time-synchronized.
1. Check Key Refresh Initiated flag for device refresh state
2. Provisioning Service will send a cloud-authenticated message to start Key Refresh process on the Endpoint
Upon handshake verification, Amazon Sidewalk Provisioning Service shall indicate to the Network Server to delete the old authentication material and calculate the new authentication material.
On completion of the Key Refresh procedure, the Endpoint shall Beacon with the TXID generated with the new key.

6.4.5.3 Sequence Diagram

The process follows the diagram shown in 6.22

BLE Network key refresh

fig 6.22 BLE Network key refresh

Details about state machine flags are presented below.

6.4.5.4 States for Key Refresh

KEY_REFRESH_TRIGGERED: When the scheduler trigger event is received for an Endpoint in the provisioning service and GET_ENCRYPTION_CAPABILITIES is sent to the Endpoint from the cloud.
KEY_REFRESH_INITIATED: When the Initial commands are received for authentication with Key Refresh flag.
KEY_REFRESH_UNSUCCESSFUL: If any error occurs during the Key Refresh flows and the current state of the device is one of the above, set retry count accordingly.
KEY_REFRESH_PROCESSED: When Endpoint signature is verified and processed successfully (cloud has old and new keys stored for the device).
KEY_REFRESH_COMPLETED: When the Perform Handshake is successful, the device entry will have this state (old key will be cleared and only new key will be maintained).

For intermediate step failure, the Endpoint resets back to initialization state for the Key Refresh procedure to be restarted.

6.4.6 Deregistration

Deregistration of the Endpoint and Endpoint reset work together in BLE mode. When the Amazon account user or AWS API user initiates the deregistration process, its authorization is validated first with its Amazon LWA or AWS account credentials respectively. The next step is to update the Endpoint state in AWS IoT wireless from “registered” to “provisioned” and cancel Endpoint associations. The Amazon Sidewalk Cloud will mark the internal state of the Endpoint to be in Pending Reset state. The Amazon Sidewalk Cloud continues to hold device keys and authentication material until an Endpoint becomes reachable by the network and successfully resets. A cloud-authenticated RESET message is sent from the cloud to the Amazon Sidewalk Mobile SDK. After the Mobile SDK determines that the Endpoint is not in initialization mode, the Mobile SDK forwards the RESET command to an Endpoint. An Endpoint answers with a cloud-authenticated RESET_RESPONSE message and removes all the credentials and transitions to a provisioned state. The Endpoint starts sending initialization Beacon message, awaiting reregistration. During this time, the Amazon Sidewalk Mobile SDK is scanning for registration Beacon from the Endpoint. After successful registration and Beacon reception, the Amazon Sidewalk Mobile SDK sends Deregister Device message to the cloud proxy service to finalize the deregistration process in the cloud. The Endpoint status is published, credentials are removed, session information is removed and confirmation response is sent back to the Amazon Sidewalk Mobile SDK. The Endpoint state machine is presented in 6.23.

BLE Endpoint state machine

fig 6.23 BLE Endpoint state machine

A detailed process flow is presented in 6.26.

BLE deregistration

fig 6.24 BLE deregistration

If a Mobile is not in the proximity of the Endpoint, then the cloud marks the device state as pending reset and attempts to send a deregistration command via an available Gateway to reach the Endpoint when the Endpoint tries communicating with the Amazon Sidewalk Cloud.

A similar deregistration procedure is followed using a Gateway. When the user deregisters the Endpoint on the Amazon Sidewalk Cloud, the Amazon Sidewalk Cloud marks the Endpoint in Reset Pending state and waits for any uplink message from the Endpoint. When an uplink message is received and the Endpoint is in Reset Pending state, the authenticated RESET message is sent to the Endpoint via a reachable Gateway.

The Endpoint authenticates the RESET command and then sends the RESET_RESPONSE as best effort. The Endpoint shall then remove credentials and shall move to a deregistration state awaiting reregistration.

A detailed process flow is presented in 6.25.

Deregistration by Sidewalk Gateway when Endpoint is not in proximity of mobile application

fig 6.25 Deregistration by Sidewalk Gateway when Endpoint is not in proximity of mobile application

6.26 shows the reset message sent might or might not reach the Endpoint. Even if the reset message does not reach the Endpoint, it will be resent upon receiving the first uplink from the Endpoint.

BLE GW deregistration

fig 6.26 BLE GW deregistration

An Endpoint can trigger deregistration using sid_set_factory_reset API provided to the application. Amazon Sidewalk SDK as best effort shall attempt to send Factory Reset Notify using an available link to the Amazon Sidewalk Cloud via a Gateway and then clear the credentials. The Endpoint shall move to waiting for reregistration state. A detailed process flow is presented in 6.27

BLE Endpoint Triggered deregistration

fig 6.27 BLE Endpoint Triggered deregistration