4.7 Encrypted messaging

Encrypted messaging protects communication between an Endpoint and the Amazon Sidewalk Cloud. Encrypted messaging has two layers of security: Network Layer security and Application Layer security. Each encrypted layer is used to encrypt different parts of the Message frame. The Network Encryption Layer encrypts the Network Layer frame payload. The Application Layer security may encrypt the “Application command” part of the Presentation Layer frame. Link Layer frame parts such as “Frame control”, “Source address”, “Destination address”, “Sequence number” are always sent as plaintext (see section 5.1.1, and section 5.1.1.1). Network Layer frame parts such as “Frame control” and “Authentication tag” are always sent as plaintext (see section 5.1.2, section 5.1.2.1, and section 5.1.2.2) figure 4.12 shows which security layers encrypt the different parts of the Link Layer and Network Layer frames. Information on whether Network Layer encryption is enabled can be found in the Network Layer frame in the encr_ena field of the Frame control part (see section 5.1.2.2.1). Information on whether Application Layer encryption is enabled can be found in the Presentation Layer frame in the app_encr_ena field of the Application Support Layer header part (see section 5.1.3). Network-only Messages do not use Application Layer encryption.

Beacon frame (see section 5.1.3.1) is always sent as plaintext. The Authentication tag that is included in the Beacon frame format is not used (see section 5.1.3.1.9).

figure 4.12 Message frame format encryption

Network Layer encryption and Application Layer encryption use different algorithms for encryption, decryption and MAC generation. Network Layer security shall use the AES-GCM algorithm for encryption, decryption, MAC generation and verification. Application Layer security shall only use the AES-CTR algorithm for encryption and decryption. Application Layer security shall not use the MAC for verifying the sender. During time synchronization, MAC generation shall use the AES-CMAC algorithm. Time sync messages shall be authenticated.

Encrypted messaging requires the Endpoint clock to be synchronized with the Amazon Sidewalk Cloud before end-to-end communication is established. Algorithms AES-GCM and AES-CTR use symmetric keys that are generated based on the global clock for all Amazon Sidewalk application commands. When the Endpoint clock is out of synchronization, AES-CMAC uses symmetric keys that are generated based on the counter for time synchronization commands (GET_TIME, RESP_TIME). When the Endpoint clock is synchronized, AES-CMAC also use symmetric keys that are generated based on the global clock for time synchronization commands. The end-to-end message is not encrypted and MAC verification is applied only for time synchronization commands. For more information on clock synchronization feature, see section 4.2. For more information on keys used for encryption, decryption and MAC generation, see section 4.7.1

The AES-GCM algorithm used for encryption and MAC generation requires the following input parameters - see figure 4.13):

Table 4.7 Input data for AES-GCM packet encryption

The output of the algorithm is:

1. N bytes of the ciphertext
2. MAC size is 4 B for sub-GHz encryption

fig 4.13 Network layer security - packet encryption

fig 4.14 Network layer security - packet decryption

The AES-GCM algorithm used for decryption and MAC verification requires the following input parameters (see figure 4.14):

Table 4.8 Input data for AES-GCM packet decryption

The output of the algorithm is N bytes of plaintext.

The AES-CTR algorithm used for encryption requires the following input parameters (figure 4.15):

Table 4.9 Input data for AES-CTR packet encryption

fig 4.15 Application layer security - packet encryption

The output of the algorithm is N bytes of the ciphertext.

The AES-CTR algorithm used for decryption requires the following input parameters (see figure 4.16): “”

Table 4.10 Input data for AES-CTR packet decryption

fig 4.16 Application layer security - packet decryption

The packet decryption algorithm outputs bytes of plaintext.

The AES-CMAC algorithm used for MAC generation requires the following input parameters (see figure 4.17):

Table 4.11 Input data for AES-CMAC

The output of the algorithm is the MAC. The MAC size for SubG-CSS devices is 4 B. The MAC size for SubG-FSK devices is 12 B.

4.17 MAC generation

The message to be authenticated is the Network Layer frame payload. The input to the AES-CMAC algorithm that contains “Message | 16B of AAD” is the concatenation of the Message and Additional Authenticated Data (AAD).

For more information on the Symmetric keys that are used in the AES-GCM, AES-CMAC and AES-CTR algorithms, see section 4.7.1.

For more information on Initialization Vector generation and format, see section 4.7.2.

For more information on Additional Authentication Data generation and formats, see section 4.7.3.

4.7.1 Symmetric keys used in encrypted messaging

Symmetric keys are used for encrypted messaging by Network Layer encryption, and Application Layer encryption. For more information on Symmetric key generation and rotation rules, see section 4.4.

Keys used by the Network Layer security for encrypted messaging are shown in table 4.12.

The following keys are used in encrypted messaging on the Application security level:

Application Layer security is not applicable when the Endpoint clock is not synchronized.

4.7.2 Initialization Vector

The Initialization Vector (IV) has different formats for the Network Layer security and Application Layer security. Network Layer security uses 12 B IV format that is presented in figure 4.18. Application Layer security uses a 16 B IV format, as shown in figure 4.19. The IV is never reused with the same encryption key as the monotonically increasing sequence number has 14 bits of entropy within a 1-min time reference window. In the sub-GHz link, the 14 bits of the sequence number will never be repeated within 1 min.

Table 4.12 Symmetric keys used in encrypted messaging - Network Layer

The following keys are used in encrypted messaging on the Application security level:

Table 4.13 Symmetric keys used in encrypted messaging - Application Security

4.7.2.1 Network encryption layer IV

The 12 B IV format is a concatenation of the following values:

1. Source ID is the Amazon Sidewalk ID of the Endpoint and the Cloud Service ID of the sender

2. Sequence number is in the Link Layer header which is a monotonically incremented number (see section 5.1.3)

   Link Layer packet sequence number size may be 1, 2 or 3 B. The IV generation shall use a 3 B format. When sequence number size is less than 3 B in the Link Layer then 0x00 value shall be added as MSB byte/s to compose a sequence number for IV generation e.g. when the sequence number is encoded in 2 B “12 34” then “00 12 34” shall be used for IV generation.

3. Reference time expressed in seconds is calculated based on the following formula:
   Time = ROUNDDOWN(T_current /T_IV_ref) * T_IV_ref
   where
   T_current - current network time
   T_IV_ref - validity of reference time in IV (see Appendix B.3 for the exact value of T_IV_ref)

   T_IV_ref = 60 s

fig 4.18 IV format for the Network security layer

4.7.2.2 Application Layer security IV

The 16 B IV format is a concatenation of the following values:

1. Source ID is the Amazon Sidewalk ID of the Endpoint and the Cloud Service ID of the sender
2. UL/DL indicates the message direction. Bit set to “0” indicates the downlink, bit set to “1” indicates the uplink

3. Application layer sequence number is the same as in sequence number field present in the ASL header / Presentation Layer

   Application sequence number size may have 1 or 2B. IV generation shall use a 2 B format. When the application sequence number size is less than 2 B then 0x00 value is added as MSB byte to compose the sequence number for IV generation e.g. Sequence number is 0x2, the sequence number portion of IV is 0x000002 for the downlink and 0x800002 for the uplink.

4. Reference time is the same as the Network Layer encryption reference time
5. 4 B, the LSB is reserved and the default value is 0x00000000

fig 4.19 IV format for the Application security layer

The generated IVs are rotated in intervals equal to T_IV_ref.

4.7.3 AEAD - Authenticated Encryption with Associated Data

The Authenticated Encryption with Associated Data (AEAD) has a different format of Additional Authentication Data (AAD) for Network Layer security and MAC generation. Network Layer security uses an 8 B format that is shown in Figure 4.20. MAC generation uses a 16 B format that is shown in Figure 4.21.

AEAD is the concatenation of the following parameters:

1. Sequence number is the Link Layer packet sequence number (see section 5.1.3.2).

   The Sequence number is only used in packet authentication AEAD generation.

   NOTE: The Link Layer packet sequence number size may be 1, 2 or 3B.

   The IV generation shall use a 3 B format.

   When the Link Layer sequence number is less than 3 B then 0x00 value shall be added as MSB byte/s to compose a sequence number for IV generation e.g. when the sequence number is encoded as 2 B “12 34” then “00 12 34” shall be used.

2. Source ID is sender entity ID. Source ID depends on the message source. Source ID can be the Device ID or the Cloud Service ID - see section 4.3.

3. Destination ID is the destination identity used in the Link Layer frame format. The Destination ID can be the Device ID or the Cloud Service ID.

   NOTE: Source ID and Destination ID size may be in the range 1 to 5 B. AEAD generation shall use a 5 B format. When Source ID or Destination ID size is less than 5 B in the Link Layer then the value 0x00 shall be added as LSB byte/s to compose an ID for AEAD generation e.g. when Destination ID is encoded in 2 B “12 34” then “12 34 00 00 00” shall be used.

4. Security reference is included in the Network Layer frame format (sec_ref field) when ext_hdr field is set to 1. When ext_hdr field is set to 0 and sec_ref is not included then the value shall be set to 0 by default.

5. Security topology is included in the “Frame control” block of the Network Layer frame format (sec_top field)

   NOTE: The current release of the protocol supports only one security topology. This bit shall be set to 1 by default.

6. Authentication code size is included in the “Frame control” block of the Network Layer frame format (auth_code_size field).
7. Encryption enabled is included in the “Frame control” block of the Network Layer frame format (encr_ena field).
8. Destination format and Source format are included in the “Frame control” block of the Link Layer frame format (src_frmt and dst_frmt fields).

9. RF frame protocol version is included in the “Frame control” block of the Link Layer frame format (prot_ver field).

   NOTE: The Link Layer contains a 4 bit prot_ver field that contains the protocol version, but AEAD requires a 1 B value. The value taken from the Link Layer shall have 4 bits with 0 value prepended to prot_ver field to fit the AEAD protocol version size.

fig 4.20 8B AAD for the Network security layer

4.21 16B AAD for MAC generation

---