4.1 Architecture
Amazon Sidewalk is a shared network developed by Amazon to allow developers outside Amazon to create and bring to market all types of consumer, enterprise, and public sector smart and connected devices and services.
Amazon Sidewalk security features include: device authentication, data encryption, and more. These features encrypt and protect the network, maintain customer privacy and protect customer data.
The following key components are referenced throughout this chapter: Amazon Sidewalk Gateways, Amazon Sidewalk Endpoints, Amazon Sidewalk Network Server, and Application Servers. These key components are defined as follows:
- An Endpoint is a source and termination point of data for the RF protocol. As a hardware entity, an Endpoint contains safe storage for keys (including device and application keys and credentials) and a memory area for security procedures. The Endpoint security software is responsible for the ID obfuscation process.
- The Endpoint Application Firmware is a dedicated external application that is loaded onto an Endpoint for handling application business logic tasks. Software is signed using the device manufacturer’s firmware signing key during the manufacturing process.
- The Gateway is a hardware entity in the Amazon Sidewalk network. A Gateway provides storage for keys and credentials and a memory area for security procedures.
- The Amazon Sidewalk Gateway Software is an Amazon Sidewalk-dedicated internal software module for routing Amazon Sidewalk protocol messages and configuring local resources. Endpoint to Application Server traffic (payload) passes through the Gateway software. For SubG-CSS and SubG-FSK, the Flex Layer has a third layer of encryption to encrypt the communication between the Gateway MCU and the Amazon Sidewalk Cloud.
- The Amazon Sidewalk Network Server is a dedicated cloud service responsible for time-based ID obfuscation, rotation and network key management. The service is also responsible for managing device primary keys and the certificate chain, and for terminating the Flex Layer and the Network Layer. The Amazon Sidewalk Network Server is the source of the time in GCS functionality that is part of each ciphering procedure used within the Amazon Sidewalk system. The routing table for Endpoint devices is stored in the Network Server.
- The Application Server is a dedicated cloud service. The Application Server is responsible for routing application traffic between external applications and applications in the Endpoint. AWS IoT Wireless is responsible for maintaining Endpoint application credentials for the Application Server.
Encrypted links in the Amazon Sidewalk system are listed below:
- Endpoint to Gateway content is handled by Amazon Sidewalk protocol. Security aspects are described in section 4.6.1
- Gateway to Amazon Sidewalk Network Server link is managed by the Flex Layer, see section 4.8.1. An encrypted link is established during the Gateway provisioning process, see section 4.4.1.1. Transmission is encrypted by the Gateway network security key. Keys are derived and rotated on an hourly basis, see section 4.5.2. The Gateway primary key is refreshed on each Gateway device reboot.
- Endpoint to Amazon Sidewalk Network Server security content is handled by the Network Layer protocol, command messages are provided in the Presentation Layer protocol. See section 5.1.1; for security aspects see section 5.1.2.2.2, and for multirate see section 5.4.3. Encrypted Third Party Application traffic is encapsulated in flex frames. The Gateway uses the Amazon Sidewalk protocol to route flex frames to the Endpoint.
- Endpoint to Application Server communication is handled by the Application Layer protocol. Application key encryption is used to encrypt traffic between the Endpoint and the AWS IoT Wireless managed service. See section 3.1; for key exchange procedures see section 4.5; for encoding, decoding and related security aspects, see section 4.7.
- Communication between AWS IoT Wireless service and Third Party Application is handled by AWS Cloud Services. The operation of AWS Cloud Services is outside the scope of this document.
The end-to-end system has an Amazon Sidewalk system and a Third party (Web-based) application.
The Amazon Sidewalk system has two hardware modules (Endpoint and Gateway) and five software modules (Endpoint Application, Gateway application, Mobile application, Network, and Application Servers in the cloud).Figure 4.1 shows a simplified view of the system components. AWS IoT asset services support Application Server with auxiliary data (device and user-related).
fig 4.1 Security Spec architecture diagram
4.1.1 Security model
The Amazon Sidewalk protocol ensures the security of transmitted data by encrypting the data. The Amazon Sidewalk protocol also supports device registration, authentication and authorization when connecting to the Amazon Sidewalk network.
Authorization in Amazon Sidewalk is based on Amazon Sidewalk’s Public Key Infrastructure Certificate Authority system. A multilevel certificate chain is maintained, based on a self-signed root certificate authority (CA). Certificate issuing and signing and exchange of cryptographic keys is carried out using the asymmetric algorithm ECDH (elliptic curve Diffie-Hellman). Two sets of elliptic cryptographic curves (Ed25519 and p256r1) are used for keys and certificate generation. The Ed25519 certificate is used to define the identity of the device. The p256r1 is used to define the signature of the device. Both are needed to register a device with the certificates and to show proof of possession. Network data confidentiality and integrity are provided by the AES-GCM algorithm. Application data confidentiality is achieved using the symmetric key AES-CTR algorithm.
Endpoint pseudo-anonymity is achieved by Device ID obfuscation, and by address translation in the Network server. Each of the entities (device, service) has a set of credentials associated with it. Credentials consist of asymmetric keys, certificates and their signatures - see section 4.1.3. Security aspects are implemented across the whole of the system’s lifetime starting with device production, then FW management, connection to the user’s network, maintaining transmission confidentiality, and ensuring pseudo-anonymity of devices in the network.
End user identification and authentication are outside the scope of this document.
4.1.2 Certificate chain
The terms used to describe the certificate chain are described in 4.1.
| Term | Definition |
|---|---|
| Certificate | An electronic document used to prove the validity of a public key. In Sidewalk, a certificate consists of three parts: the public key, the certificate serial number, and the certificate signature. |
| Certificate Chain | The certificate chain is a list of certificates used to authenticate an entity. The chain, begins with the certificate of that entity, and each certificate in the chain is signed by the entity identified by the next certificate in the chain. |
| Certificate Authority | A Certificate Authority (CA) is a certificate that issues (validates and signs) other certificates in the certificate chain. |
| Root Certificate Authority | A Root Certificate Authority (CA) forms the basis for the certificate chain. The root CA has the property that it is self-signed, issuing its own certificate, thus generating its own signature. |
| Intermediate Certificate Authority | An Intermediate Certificate Authority (CA) is a certificate in the chain that was issued (validated and signed) by another CA, and has the authority to issue other certificates (in contrast to the root CA which issues itself). |
| Device Attestation Key | The Device Attestation Key (DAK) is a private key issued by a Certificate Authority (CA) used to sign and issue device certificates during device provisioning and manufacturing. |
| Hardware Security Module | The Hardware Security Module (HSM) is a physical computing device that safeguards and manages digital keys. The HSM is used for computing device certificate signatures. |
Amazon Sidewalk maintains two multilevel certificate chains using Ed25519 and p256r1 elliptic curves. Each Certificate Authority (CA) issues a certificate to the next level in a certificate chain. The certificate chain begins with the Amazon Root CA. The Device Attestation Key (DAK) is hosted on a Hardware Security Module (HSM). The HSM issues device certificates during the manufacturing provisioning process, see section 4.4.1.1. Cloud certificates (Network Server certificate) are derived from the Amazon Root CA. Application server certificates are derived from the Manufacturer’s certificate.Figure 4.2 shows a simplified certification chain.
4.1.3 Certificates and device serial numbers
Amazon Sidewalk Certificates contain three fields - Serial, Public Key, and Signature. Amazon Sidewalk Certificates use the following layout:
Device certificates use the Amazon Sidewalk Manufacturing Serial Number (SMSN) as their serial number in the Serial field. Intermediate and root CAs use the following table to generate a 4 B serial number for the Serial field. A detailed fields description is in Table 4.2.
For more information on device serial number content see Section 4.3, for more information on the process of assigning numbers, see Section 4.4.1.1.
fig 4.3 Sidewalk certificate formats
Table 4.2 Certificate serial number
| Bit # | Content | Description | Notes |
|---|---|---|---|
| 31..30 | Type of certificate | 0 -root, 1- intermediate, 2 - cloud | |
| 29..28 | Chain size | 1-3 - depth of the full cert chain | |
| 27..26 | Depth in chain | 0 -root (or cloud) 1 -3 - intermediate certificate | |
| 25..23 | Signing rights | 0 - intermediate only 1 - intermediate and Endpoint 2 - intermediate and cloud 3 - intermediate, Endpoint and cloud cert 4 - Endpoint cert only 5 - cloud cert only 6 - Gateway 7 - All | Note: cloud can only sign messages |
| 22 : 0 | Subset of device serial number | Allows assignment of around 8.3M serial numbers |
4.1.4 Key types
There are two types of keys in the Amazon Sidewalk system: Asymmetric keys and Symmetric keys. Asymmetric keys are used to sign and verify the message. Symmetric keys are used to encrypt and decrypt the message. Asymmetric keys are built during the factory provisioning process, for more information, see section 4.4.1.1. Symmetric keys are periodically derived from the primary symmetric key. Primary symmetric keys are derived during the device registration process, for more information, see section 4.4.2.
Each symmetric key is presented in two versions: counter-based (CTRREF) and global clock-based.
Table 4.3 Ephemeral key types: Symmetric security keys are derived in network nodes from a primary symmetric key and rotated periodically
| Key Type | Key name | **Usage | description** | Notes |
|---|---|---|---|---|
| Asymmetric Key | DEVICE_ED25519_PRIVATE | Generate message signature using EDDSA | Ed25519 private key | Built during factory provisioning process |
| Asymmetric Key | DEVICE_ED25519_PUBLIC | Verify message signature EDDSA | Ed25519 public key | Built during factory provisioning process |
| Asymmetric Key | DEVICE_SECP256R1_PRIVATE | Generate message signature using ECDSA | secp256r1 private key | Built during factory provisioning process |
| Asymmetric Key | DEVICE_SECP256R1_PUBLIC | Verify message signature ECDSA | secp256r1 public key | Built during factory provisioning process |
| Symmetric Key | NETWORK_PRIMARY | Generate network symmetric security keys | Primary network key | Shared during device registration or key refresh process by ECDH |
| Symmetric Key | APPLICATION_PRIMARY | Generate application symmetric security keys | Primary application key | Shared during device registration by ECDH-E |
| Link | Key name | Usage | Derivation | Rotation interval |
|---|---|---|---|---|
| Network Server | TX_ID_KEY | Generate TX_ID for WAN data packet | CMAC(WAN_Primary key, “Network_KDF_TX_UUID” | GCS time reference) | 1 hour |
| Network Server | GCM_KEY | Encrypt/Decrypt data WAN packet with time reference | CMAC(Primary key, “Network_KDF_Device_Network_GCM” | GCS time reference) | 1 hour |
| Network Server | GCM_CTRREF_KEY | Encrypt/Decrypt data WAN packet with counter-based reference | CMAC(Primary key, “Network_KDF_Dev_Ntw_GCM_COUNTER” | counter) | Whenever counter is updated |
| Network Server | TX_ID_CTRREF_KEY | Generate TX ID for WAN time sync packet based on counter | CMAC(Primary key, “Network_KDF_Time_Sync_TX_UUID” | Time_Sync_Counter) | Whenever Time Sync Counter is increased |
| Network Server | CMAC_KEY | Generate authentication tag for time sync packets | CMAC(Primary key, “Network_KDF_Device_Network_CMAC” | GCS time reference) | 1 hour |
| Network Server | CMAC_CTRREF_KEY | Generate authentication tag with counter-based reference | CMAC(Primary key, “Network_KDF_Dev_Ntw_CMAC_COUNTER” | counter) | Whenever counter is updated |
| Network Server | TSYNC_RESP_KEY | Generate time-based CMAC tag for WAN mode RESP_TIME command | CMAC(Primary key, “Network_KDF_Dev_Ntw_Tsync_Resp” | GCS time reference) | 10 min |
| Application Server | TSYNC_RESP_CTRREF_KEY | Generate counter-based CMAC tag for WAN mode RESP_TIME command | CMAC(Primary key, “Network_KDF_Dev_Ntw_Tsync_Resp_Counter” | Time_Sync_Counter) | Whenever counter is updated |
| Application Server | JOIN_RESP_GCM_KEY | Encrypt/Decrypt WAN JOIN RESPONSE packet | CMAC(Primary key, “Network_KDF_Join_Resp_Dev_Ntw” | GCS time reference) | 5 min |
| Application Server | APP_CTR_KEY | Encrypt/Decrypt (AES-CTR) application payload | CMAC(Application Primary key, “Application_KDF_Device_Application_CTR” | GCS time reference) | 1 hour |
| Application Server | APP_GCM_CTRREF_KEY | Encrypt/Decrypt (AES-GCM) application payload with counter-based reference | CMAC(Application Primary key, “Application_KDF_Registration_GCM_COUNTER” | counter) | Whenever counter is updated |
4.1.5 The procedure of generating device private keys during MFG process
Each device requires two unique key pairs corresponding to the Ed25519 and p256r1 elliptic curves that are generated at the time of device manufacturing. The private keys are then stored in the device’s persistent memory area. The device public key and the Amazon Sidewalk Manufacturing Serial Number (SMSN) are signed using the DAK private key. The device public key and the Amazon Sidewalk Manufacturing Serial Number form the device certificate signature. Note the signing operation takes place in the HSM device, avoiding exposure of the DAK.
- ECDSA Signature = ECDSA(DAK p256r1 private key, Device p256r1 Public Key ‖ SMSN)
- EdDSA Signature = EdDSA(DAK Ed25519 private key, Device Ed25519 Public Key ‖ SMSN)