8.7. Developing with High Security Devices

8.7.1. Introduction

The K3 security architecture supports different “Device Types” controlled by eFuse settings programmed during device manufacturing. Each Device Type offers different capabilities for Debug and Emulation as well as different behavior in functional operating modes. Depending on the Device Type, some security mechanisms are relaxed or enforced.

J721E supports General Purpose (GP) devices and High Secure (HS) device types. The high level difference between these devices are:

  • GENERAL PURPOSE (GP): The device is not capable of secure operation. Security features are transparent and do not affect operation either functionally and for Debug. However, secrets such as the secure ROM code, secure keys and other secure peripherals are not accessible.

  • HIGH SECURITY - Field Securable (HS-FS): In an HS-FS device, only the secure island is protected and no other security on the device is enforced. This is the device variant which is used for blowing customer keys into the device eFuses using the OTP keywriter (separate overlay package). This action will transition the device to an HS-SE device, as described in the next bullet

  • HIGH SECURITY - SECURE ENFORCED (HS-SE): In an HS-SE device, all security features are enabled, all secrets within the device are fully protected, all of the security goals are fully enforced, debug override sequence is supported, and the device enforces secure boot.

  • HIGH SECURITY Prime (HS Prime): HS-SE Prime is a variant of the standard HS-SE device. HS Prime uses customer keys for establishing root of trust on the device, bypassing all TI keys. This is accomplished via signing/encrypting the DMSC image with the customer keyset and requires custom DMSC add-on package to enable. This device type and add-on package is only available for select users.

The scope of this developer note is to point to build bootloaders/applications and run on HS devices.

8.7.2. Documentation References

8.7.2.1. X.509 Extensions

All boot images are accompanied by a signed X.509 certificate. Custom certificate extensions defined by TI provide information for both ROM and SYSFW to use for image authentication. The extensions are defined for each below:

Component

Documentation Reference

Section

ROM

See device Technical Reference Manual

Initialization –> Boot Image Format

SYSFW

https://software-dl.ti.com/tisci/esd/latest/2_tisci_msgs/security/sec_cert_format.html

Extensions

Note

All certificates bootloader, SYSFW, and board configuration certificates use a SWREV extension to indicate respective software revisions. SWREV in the certificate must be greater or equal than the SWREV programmed into the device eFuses in order for the device to boot properly.

SWREV must be set to at least 1 for all devices to ensure boot as all TI devices now ship from the factory with the default SWREV set to 1 for SBL, SYSFW, and board configuration. The certificate values must be equal or greater than the current value in the device efuses and will need to be incremented during the device lifecycle whenever the efuse values are incremented to provide anti-rollback protection. See https://software-dl.ti.com/tisci/esd/latest/6_topic_user_guides/otp_revision.html for more details on the efuse values and how to read and increment using the TISCI API.

8.7.2.2. Linux Guides to work with HS devices

SDK Component

Documentation

Description

Section

uboot

https://software-dl.ti.com/jacinto7/esd/processor-sdk-linux-jacinto7/08_06_01_02/exports/docs/linux/Foundational_Components_U-Boot.html

Overview of boot flow and steps to build u-boot and boot on GP devices

Boot Flow

uboot

https://github.com/u-boot/u-boot/blob/master/doc/README.ti-secure

Steps to build u-boot and boot on HS devices

Invoking the script for K3 Secure Devices

k3-image-gen

https://git.ti.com/cgit/k3-image-gen/k3-image-gen/tree/README.md

Steps to create an image tree blob (a.k.a. FIT image) on GP Devices

Building SYSFW Image and Configuration Data

k3-image-gen

https://git.ti.com/cgit/k3-image-gen/k3-image-gen/tree/README.md

Steps to create an image tree blob (a.k.a. FIT image) on HS Devices

Building SYSFW Image for High-Security(HS) devices

8.7.2.3. RTOS Guides to work with HS devices

SDK Component

Documentation

Description

Section

SBL

LINK

Bootloader Execution Sequence (Sequnce of steps from ROM to SBL to Application

  1. Bootloader (SBL) » 5.2. Jacinto 7 SBL >> Bootloader Execution Sequence

SBL

LINK

Build steps to create an SBL Image for GP devices

  1. Bootloader (SBL) » 5.2. Jacinto 7 SBL >> Building the SBL and its components

SBL

LINK

Steps to enable and disable JTAG for HS devices

  1. Bootloader (SBL) » 5.2. Jacinto 7 SBL >> Enabling/Disabling JTAG on secure devices

SBL

LINK

Steps to prepare boot media for GP and HS devices

  1. Bootloader (SBL) » 5.2. Jacinto 7 SBL >> Compiling apps that can be loaded by SBL

8.7.3. PDK steps for HS Devices

The steps to build HS SBL and HS Uniflash Programmer are as below:

  • TIFS board configuration update

    PDK provides a default board configuration definition which is intended for use with the standard SDK options. Any customization of the board configurations requires that the board config binaries are rebuilt before the bootloader can consume their binary data for TIFS configuration.

cd <pdk_install_dir>/packages/ti/build
make sciclient_boardcfg_hs BOARD=$BOARD
  • Building HS SBL

 cd <pdk_install_dir>/packages/ti/build
 make -s sbl_<bootmode>_img_hs BOARD=$BOARD

where boot mode is mmcsd, ospi, hyperflash, uart
This generates HS SBL images under <pdk_install_dir>/packages/ti/boot/sbl/binary/<$BOARD>_hs folder
  • Building HS Uniflash programmer Similar to SBL. Instead provide the make target as “board_utils_uart_flash_programmer_hs” This generates HS uniflash programmer image under <pdk_install_dir>/packages/ti/board/utils/uniflash/target/bin/<$BOARD>_hs folder

8.7.4. Linux SPL steps for HS Devices

8.7.5. Signing TIFS for HS Prime Device Variants

For the HS Prime device variant, the TIFS image is built and signed directly by the user, and no building or signing is provided by TI. Please refer to the TIFS build steps described in the add-on source package for HS prime devices.

Once the TIFS binary has been successfully built, it can be signed using the SDK tools. A reference is provided in the PDK scripts in the SDK:

cd <pdk_install_dir>/packages/ti/drv/sciclient
TIFS_DIR=<path_to_tifs_dir> ./tools/firmwareHeaderGen.sh j721e-hsp

J721E PG1.1 HS-SE Production parts have the SWREV Efuse value = 1. (J721E PG1.0 devices have SWREV = 0.)

ROM on these devices will boot SBL/SPL and TIFS only if the certificate contains a value of SWREV Efuse >= 1 to enforce anti-rollback. The SDK 8.0 enables SWREV Certificate Value = 1 for: