1. Secure Boot

This tutorial aims to provide an in-depth analysis of the secure boot feature on the DA1469x Bluetooth SoC. In contrast to other Renesas BLE devices, the boot loader of the DA1469x supports secure boot and so, there is no need for invoking a secondary boot loader. On top of that, the embedded OTP memory contains a special area where secure keys are stored. Three groups of product keys are supported, each consisting of up to 8 different keys. The size of each key is 256-bits in length. Following is a brief description of the aforementioned three groups of product keys:

• QSPI FW Decryption Keys Area (Payload): This memory area holds symmetric keys utilized by the secure-QSPI controller for decrypting, on-the-fly, the FW image.

Note

When the device operates in secure mode it is mandatory for the application image to be encrypted before storing it in to the FLASH device. Otherwise the device cannot boot. The same product key is used both for encrypting and decrypting the FW image

• Signature Keys Area (Payload): This memory area accommodates asymmetric keys stored in pairs of private-public keys. The private key is used for generating a digital signature based on the target FW image. The public key is invoked by the BootROM code to authenticate and verify the validity the signed FW image

• User Data Encryption Keys Area (Payload): This memory area holds symmetric keys used by the general-purpose AES crypto engine to encrypt/decrypt user-defined data. By using different symmetric keys for encrypting/decrypting user-defined data and the FW image, the secure mechanism is considered more robust

Figure 1 Product Keys - OTP Area

For each product key there is a product key index, 4-bytes each, that designates the validity of that specific secure key. By default, the value of all key indexes is 0xFFFFFFFF. In fact, this is the value of an unwritten OTP memory cell. A key index value set to 0xFFFFFFFF designates a valid product key whereas, a key index value set to 0x00000000 designates a revoked and hence an invalid product key.

Note

The initial value of an OTP memory cell, integrated on the DA1469x, is logic 1. This value can be changed to logic 0. The opposite direction is not possible.

1.1. Working with the Secure Boot Feature

This section describes the steps required to enable secure booting on the DA1469x chips. The steps are provided with the order they should be executed.

1.1.1. Step #1 - Importing Python Scripts

All functionality related to the secure boot feature can be found in the python_scripts project. This project contains a bunch of scripts which can be executed either directly via a terminal or from SmartSnippets Studio (SSS). In this tutorial the latter option is demonstrated.

Note

This step is not required if scripts are executed externally via a terminal/command line. To avoid any misconfigurations it is highly recommended to work with the external tools as provided in SmartSnippets Studio.

1. On the SmartSnippets Welcome page, click Browse in the SOFTWARE RESOURCES section.

Figure 2 Open Project Browser

2. In the pop-up window, click OK as your current workspace folder should be automatically selected. If this is not the case, you must explicitly select it.

Figure 3 Select SDK Folder

3. The final step is to select the python_scripts project. The easiest way to do that is to:

   • Click Deselect All

   • Select the aforementioned project by clicking on the respective tick box

   • Click Finish

Once the project is imported switch to C/C++ window. You should get the following output:

Figure 4 Select Target Project

1.1.2. Step #2 - Generating the Keys and the Secure Boot Configuration XML Files

The next step involves generating the product keys for all three keys categories. To do so, execute the following steps:

1. Run the secure_config external tool from SmartSnippets Studio.

Figure 5 Generating Product Keys - Running External Tool

2. In the pop-up window select Yes.

Figure 6 Generating Product Keys - Generating Product Keys

3. In the displayed window select the target family of devices. This should be the DA1496x-00. Then click OK.

Figure 7 Generating Product Keys - Selecting Target Family

4. Next, you will be prompted to select if the secure boot feature should be enabled. To continue select Yes.

Figure 8 Generating Product Keys - Enabling Secure Boot

5. In the pop-up window select which of the 8 public keys, written in product_keys.xml, should be used for validating the signed FW image. The selected Public Key is used by the ROM booter to authenticate the FW image during boot. The corresponding Private Key is used for generating the digital signature of the application image. For demonstration purposes select the key index with index 1.

Figure 9 Generating Product Keys - Selecting Public Key Index

Note

Scripts do not check if the selected key is revoked, that is if the key has been invalidated and is no longer valid.

6. Choose which of the 8 FW decryption keys, written in product_keys.xml, should be used for decrypting the FW image. The selected key is used in run-time by the secure-QSPI controller to decrypt on-the-fly the FW image. It is imperative for the FW image to be encrypted using the same symmetric key. For demonstration purposes select the key with index 2.

Figure 10 Generating Product Keys - Selecting FW Decryption Key Index

Note

Scripts do not check if the selected key is revoked, that is if the key has been invalidated and is no longer valid.

7. The last step requires to select one or more keys that should be revoked. To continue, select No as revocation process is demonstrated at a later section in this tutorial.

Figure 11 Generating Product Keys - Revoking Keys

Upon successful keys generation, right-click on the python_scripts project and select Refresh to refresh its contents. A new file, named product_keys.xml should be generated. This XML file contains the 8 arbitrary keys for all three product keys categories. The generated keys should also be displayed on the Console window at the bottom side of the IDE.

Figure 12 Product Keys XML File

Also a second file, named secure_cfg.xml, should now be generated in the script’s location. This file is used:

• For encrypting and signing the target FW image

• For writing the secure related entries in the Header Image section of the FW image

• For enabling the secure boot feature by writing the appropriate entry in the Configuration Script section in OTP. This step is done only once. Following attempts to execute that step are ignored

Figure 13 Keys Configuration XML File

Note

User is free to change secure_cfg.xml according to their needs without, though, changing the format of the underlying XML file.

1.1.3. Step #3 - Creating the secure image

If not done so, import the project into the workspace and compile a SUOTA supported image:

Figure 14 Create SUOTA image

Note

After programming the security flags in the OTP, the only way to update the application software is over the air, using SUOTA.

When the build is successful, both a secure- and non-secure image are created. Beside the product_keys.xml and the secure_cfg.xml file, a 3rd file is generated: nonce_cfg.xml.

Figure 15 Image creation

1.1.4. Step #4 - Writing the Secure FW image in the FLASH

Write the secure FW image in the FLASH. It is important to have a valid secure FW image in the flash before enabling the secure boot feature. If the secure boot feature is enabled either without FW image or without valid secure FW image , or without the correct keys programmed in the OTP, the device will be locked and there is no way to bypass this and program the device again.

Figure 16 Writing secure FW to FLASH

The secure_img_prog_jtag and secure_img_prog_serial scripts will encrypt the FW image using the key selected during the keys creation phase, it will create the FW image header with the security segments, generate the digital signature of the FW image (including the signed part of the FW image header) and add it to the FW image to be written in the FLASH.

Note

Make sure that there is a valid secure FW image in the FLASH and the correct valid keys in the OTP to have a functional device. In case where the keys are wrong, or the FW image is not properly created, or it is not used a secure image and the secure boot feature is enabled, the device will be permanently disabled because such action falls in the device attach category and will activate the secure boot device protection feature.

1.1.5. Step #5 - Programming Product Keys & Enabling Secure Boot

After finished generated the appropriate XML files and written the secure FW image in the FLASH, the next step is to burn the product keys in the embedded On-Time-Programmable (OTP) memory and enable the secure boot feature. To do that you should:

1. Run the secure_keys_prog_jtag/serial external tool from SSS. You are free to run the script employing either the serial port or JTAG interface.

Figure 17 Writing Product Keys in OTP - Running External Tool

If the secure boot feature is enabled in secure_cfg.xml, the tool will attempt to write the appropriate entry in the CS section in OTP. The status of each step is displayed on the Console window at the bottom side. Once the writing process is complete and there are no errors, you should get the following output:

Figure 18 Writing Product Keys in OTP - Report Status

Note

If the secure boot feature is already enabled in CS, no action will be performed.

In case the product keys are already written in OTP you should get the following output:

Figure 19 Writing Product Keys in OTP - Report Status

In case the product keys are already written in OTP but do not match with the ones in product_keys.xml you should get the following output:

Figure 20 Writing Product Keys in OTP - Report Status

In case the product keys written in product_keys.xml are invalid you should get the following output:

Figure 21 Writing Product Keys in OTP - Report Status

Warning

It is of paramount importance to highlight that product keys safe storage and manipulation is customer’s liability. If the keys are lost, there is no way to recover them from the device once the SWD port and Development Mode are disabled. If all keys of a group are invoked the device will be permanently disabled. Renesas Electronics is not liable in any way for problems caused by either poor management and unsafe handling of the keys or revocation of all keys in a keys group.

1.2. Enabling Secure Boot Manually

The secure boot feature can also be enabled manually without invoking the corresponding python scripts. Enabling the secure boot, involves writing the appropriate entry in CS section in OTP. This value is used by the booter to configure the SECURE_BOOT_REG[SECURE_BOOT] bit-field. This configuration should take place before the device starts executing the FW image. In doing so, the chip will operate in secure boot mode which mainly involves authenticating and then decrypting, on-the-fly, the flashed FW image.

There are two main options for writing a value in OTP. The first option employs the SmartSnippets Toolbox and the second option makes use of the CLI programmer tool. In this tutorial, the former option is demonstrated. To continue execute the following steps:

1. On the SmartSnippets Welcome page, click SmartSnippets Toolbox.

2. In the newly displayed window open a new instance of SmartSnippets Studio. To do so, execute the following steps:

   1. (Optional) Select New to create a new project (1). In the New Project window, enter a name for the project (2). This step is optional if a project has already been created.

   2. Choose an available project (4).

   3. Choose a communication interface (3) and a port (5).

   4. Select the family of devices to use (6). This should be the DA1469x-00.

   5. Open the selected project (7).

Figure 22 Opening a Project in the SmartSnippets Toolbox

3. Switch to the OTP Programmer window located under the Tools section:

Figure 23 Enabling Secure Boot Manually - Opening OPT Programmer

4. In the OTP Header[Device: DA1469x-00] window click on Connect. Log messages should be displayed on the Log window.

   • A cursor should start rotating waiting for the device to reboot

   • Press the RESET button on the DA1469x daughterboard and wait for the SmartSnippets Toolbox to connect to the target chip

   • Once connected, the cursor should stop rotating

Figure 24 Enabling Secure Boot Manually - Connecting to the Device

5. Being at the same window click on the icon as illustrated below:

Figure 25 Enabling Secure Boot Manually - Opening Configuration Script

6. In the Manage Configuration Script window select Register Configuration (1) and then click Add (2):

Figure 26 Enabling Secure Boot Manually - Adding New Entry

7. In the pop-up window click Select (3). In the newly displayed window search for SECURE_BOOT_REG (4). Once the register is found, click on it (5) and then select OK (6). Next, declare the register’s value as illustrated below (7) and finally click OK (8).

Figure 27 Enabling Secure Boot Manually - Declaring New Entry

8. In the Manage Configuration Script window select OK (9).

9. In the OTP Header[Device: DA1469x-00] window click Burn to write the newly defined entry in OTP.

Figure 28 Enabling Secure Boot Manually - Writing to the OTP #1

10. In the pop-up window select Burn to write the previously defined entries in the OTP memory.

Figure 29 Enabling Secure Boot Manually - Writing to the OTP #2

Warning

Once the secure boot feature is enabled, non-secure FW images cannot be started on the device. Moreover, disabling the secure boot mode is no longer possible.

Warning

Once the secure boot feature is enabled, the product keys area in OTP can no longer be accessed by the ARM M33 application core of the device. Only the secure-QSPI controller and the 7th channel of the DMA engine can access the special product keys area in OTP.

1.3. Writing NONCE Parameter Manually

Users can also declare their own nonce value required by the AES crypto engine to decrypt the FW image. To do so, user can change the NONCE parameter directly in the nonce_cfg.xml file.

Note

Be aware that re-using the NONCE in consecutive software (update) images can have negative influence on the security and therefor it is recommended to us a different NONCE every time a new software image is created.

1.4. Revoking Product Keys

Key revocation is the process of invalidating one or more product keys written in OTP. The revocation procedure is performed by the ROM booter. The revocation information is delivered through the FW image header and thus, revoking one or more keys requires programming a new FW image in the FLASH device. The latter can be achieved either by overwriting the existing FW image stored in the FLASH device or adding a new image via the SUOTA functionality. Revoking a key involves destroying the key itself as well as invalidating the corresponding key index value in OTP. The latter is achieved by zeroing the key index value. The booter will ignore any revoked key(s) and will not use them to load the FW image. Any product key of all three categories can be revoked. Usually, the process of revoking one or more keys is imperative when a key has been leaked to the public.

Warning

At least, one FW decryption and one signature verification key should be valid in order for the device to boot. If all keys are revoked the device will not be able to boot.

1. The easiest way to proceed is to run the secure_config external tool.

Figure 30 Revoking Product Keys - Running the External Tool

Note

Once product_keys.xml is generated, re-running secure_config will only modify secure_cfg.xml.

2. A window with the current keys configurations, read from product_keys.xml, should be displayed. To continue click Change:

Figure 31 Revoking Product Keys - Changing the Keys Configuration File

3. In the pop-up window select the target family of devices. This should be the DA1469x-00.

4. In the displayed window select whether the secure boot feature should be enabled or not. Note that, once the secure boot is enabled in CS no further action will take place.

5. Next, you will be asked to select a valid public key index.

6. Then you will be prompted to declare the nonce value. Select No and let the script define an arbitrary value.

7. Select a valid FW decryption key index.

8. In the pop-up window select Yes as revocation process should take place.

Figure 32 Revoking Product Keys - Enabling Revocation

9. A pop-up window with all available public keys, read from product_keys.xml, will be displayed. Select one or more keys that should be revoked and then click OK. In this demonstration the 7th key index is selected for revocation.

Figure 33 Revoking Product Keys - Revoking Public Keys

10. A pop-up window with all available FW decryption keys, read from product_keys.xml, will be displayed. Select one or more keys that should be revoked and then click OK. In this demonstration the 7th key index is selected for revocation.

Figure 34 Revoking Product Keys - Revoking FW Decryption Keys

11. A pop-up window with all available user data decryption keys, read from product_keys.xml, will be displayed. Select one or more keys that should be revoked and then click OK. In this demonstration none of the keys are selected for revocation.

Figure 35 Revoking Product Keys - Selecting User Data Keys

Note

Scripts do not check which keys are already revoked. If a key is revoked and its revocation is requested, no action is performed for the specified key.

If all above steps are executed successfully you should get the following output on the Console window:

Figure 36 Revoking Product Keys - Console Window

secure_cfg.xml should now be updated. Open the file and verify the updated Device Administration XML entries:

Figure 37 Revoking Product Keys - Updating the Keys Configuration File

Note

User can also change the Device Administration values directly from secure_cgf.xml by modifying the corresponding XML entries.

1.5. Known Restrictions and Limitation

• The secure_config external tool generates all 8 keys for all three keys categories. If fewer keys should be generated, product_keys.xml should be edited manually. Once the keys are written in OTP, the rest of the keys (not initially defined) cannot be written by re-running secure_keys_prog_jtag/serial. This operation should be done either via SmartSnippets Toolbox or the CLI programmer tool

• Once the product_keys.xml file is generated, it cannot be overwritten by re-running secure_config. If new keys have to be generated the keys file should be removed manually. In that case, do not forget to keep a copy of the keys file

• Scripts do not check which keys are already revoked; this information is printed only as log. If a key was revoked and its revocation is requested, then no action is performed for that specified product key

1.6. Troubleshooting

When the flashed application image cannot execute, check the following:

Possible Cause	Recommended Action
Secure boot is not enabled in the Configuration Script in OPT	Run secure_config and enable the secure boot feature. Once the tool is executed successfully, run secure_keys_prog_jtag/release to write the CS section in OTP
The signature verification and/or FW decryption keys, used by secure_img_prog_jtag/serial to generate the FW image, do not match the keys stored in OTP	Make sure that there is no other product keys file that might has been programmed to the OTP memory earlier
The currently selected signature verification and/or FW decryption keys have been revoked by the previous application image	At least one key in each category must be valid in order for the device to boot. Run secure_config and select another valid key index. Then run secure_img_pro_jtag/serial to sign and encrypt the application image with the selected keys

1.7. Further Increasing Device Security

• The device can be further secured by permanently disabling its SWD port. In doing so, there is no longer possibility for the chip to be accessed via the JTAG interface. The aforementioned state can be achieved by setting the FORCE_DEBUGGER_OFF sticky bit of SECURE_BOOT_REG to 0x01. To do so, the appropriate value should be written in the Configuration Script section in OTP. For more information on how to write a new Register Configuration entry in CS please refer to Enabling Secure Boot Manually

• Another way to secure the device is to permanently disable the serial port so that no secondary bootloader can be utilized to load a new application image. This can be achieved by permanently disabling the Development Mode which, by default, is enabled at the initialization phase of the booter. In specific, the special value 0x70000000 will force the booter to disable the Development Mode and run the device in Production Mode. To do so, the aforementioned special value should be written in CS in OTP with the help of SmartSnippets Studio. For more information please read the Enabling Secure Boot Manually section. In this case the corresponding command type should be selected as illustrated below:

Figure 38 Disabling Development Mode

Note

In case a Register Configuration is declared multiple times in the Configuration Script section in OTP, the last pertinent entry will eventually determine the value of the target register.

Warning

Once the SWD port as well as Development Mode are disabled, a new application image can only be loaded through the SUOTA service, if enabled.