Operating Modes#
AES-CTR Mode#
The Advanced Encryption Standard Counter Mode or AES-CTR is a symmetric-key cipher that uses the AES Electronic Code Book (AES-ECB) algorithm to encrypt a number used once and a counter that is incremented to produce a sequence of output blocks that are combined via exclusive-or (XOR) with the plaintext to produce the ciphertext, and vice versa. Because each block can be constructed independently of each other, AES-CTR mode can be parallelized for applications like XiP where high throughput is required. Additionally, because each block can be independently encrypted or decrypted, AES-CTR mode is well-suited to random access – which is useful for XiP where many branch instructions may require accessing different blocks that are not necessarily close together. Finally, the resultant cipher-text from any plaintext will always be the same width and does not require padding, making it suitable for data of arbitrary length, such as an encrypted firmware executable.


In AES-CTR encryption mode, the precomputed counter blocks are XORed with a block of plaintext and the results of XORed blocks are concatenated into the final ciphertext.


In decryption mode, the inverse is performed: each counter block is XORed with the ciphertext before being decrypted into corresponding plaintext blocks which are concatenated into the original plaintext.
The sequence of counters must never repeat for any message under a specific key. If a counter repeats, then an attacker with a chosen ciphertext can use that ciphertext to determine contents of other unknown ciphertexts without knowledge of the underlying encryption key.
AES-CTR Configuration#
A section of flash memory, known as Master Boot Record (MBR), contains important configuration information of SiWx917, such as flash configuration, security features, peripheral configuration etc. Upon power-on, the device is configured according to the MBR (Mas-ter Boot Record) settings. To enable XIP in various modes minimal MBR configuration JSON content is shown further.
AES-CTR XiP on NWP Only
{
"puf_activation_code_addr": 8192,
"efuse_data": {
“ta_encrypt_firmware”: 1
},
"key_desc_table_addr": 768
}AES-CTR XiP on M4 Only
{
"puf_activation_code_addr": 8192,
"efuse_data": {
"m4_encrypt_firmware": 1,
"m4_fw_encryption_mode": 1,
},
"key_desc_table_addr": 768
}AES-CTR XiP on Both Cores
{
"puf_activation_code_addr": 8192,
"efuse_data": {
“ta_encrypt_firmware”: 1,
"m4_encrypt_firmware": 1,
"m4_fw_encryption_mode": 1,
},
"key_desc_table_addr": 768
}Note: NWP only has one field to both enable and configure encryption, while the M4 has one field to enable encryption and a separate field to set the mode.
AES-XTS Mode#
AES XEX-based tweaked-codebook with ciphertext stealing aka AES-XTS – is a block cipher mode of operation for AES that modifies AES-XEX with a feature called ciphertext stealing to allow plaintexts that are at least one or more blocks of 128 bytes plus a final block of less than 128 bytes to be encrypted and decrypted without use of padding. Ciphertext stealing works by taking a portion of the second-to-last block’s output ciphertext, which is then blanked, and using it to fill the last block’s plaintext before encryption.
During decryption, the last block is decrypted first, recovering the partial plaintext and ‘stolen’ ciphertext, which can then be added back into the second-to-last block before it is decrypted. AES-XTS uses two keys, one for encryption of block data and one for encryption of the ‘tweak’ which is used to modify blocks for added security by acting similarly to a NONCE: ensuring that if the same data is encrypted in two separate blocks, their resulting ciphertexts will still be different due to the tweak. In contrast to NONCE, a tweak is generated using the flash page number and a given block’s offset within its page, so that tweak does not require extra flash storage.


In AES-XTS encryption mode, the tweak is computed and XORed into the plaintext and the result is encrypted with the Block Key before being XORed with the tweak again.


In AES-XTS decryption mode, the tweak is computed and XORed into the ciphertext and the result is decrypted with the Block Key before being XORed with the tweak again.
It is important to note that while AES-XTS can preserve confidentiality – it does not ensure data integrity. It is not possible to detect that a ciphertext has been modified from its original.
AES-XTS Configuration#
The Master Boot Record of the 917 contains important configuration for the SiWx917. The efuse_data section in this file allows you to configure the functionality of the device. For example, minimal JSON files for enabling XiP in AES-XTS mode using commander manufacturing init appear further. The modified sections of the default JSON appear in bold type.
AES-XTS XiP on TA Only#
{
"puf_activation_code_addr": 8192,
"efuse_data": {
“ta_encrypt_firmware”: 2,
“m4_secure_boot_enable”:0,
"ta_secure_boot_enable": 1
},
"key_desc_table_addr": 768
}AES-XTS XiP on M4 Only#
{
"puf_activation_code_addr": 8192,
"efuse_data": {
"m4_encrypt_firmware": 1,
"m4_fw_encryption_mode": 2,
“m4_secure_boot_enable”:1,
"ta_secure_boot_enable": 0
},
"key_desc_table_addr": 768
}AES-XTS XiP on Both Cores#
{
"puf_activation_code_addr": 8192,
"efuse_data":
{
“ta_encrypt_firmware”: 2,
"m4_encrypt_firmware": 1,
"m4_fw_encryption_mode": 2,
“m4_secure_boot_enable”:1,
"ta_secure_boot_enable": 1
},
"key_desc_table_addr": 768
}Note: NWP only has one field to both enable and configure encryption, while the M4 has one field to enable encryption and a separate field to set the mode.