On TI C2000™ F29x devices, two hardware blocks enforce firmware security.
The Hardware Security Module (HSM) controls which firmware the device accepts. Once the customer keys are provisioned, the HSM verifies the X.509 certificate of every image before it programs or launches it. An image that is not signed with those keys is refused.
The Safety and Security Unit (SSU) controls what the firmware may reach while it runs. It checks every memory and peripheral access against the security configuration stored in flash, which also sets flash write protection, debug access, and the authority to change these rules later.
This post is about the HSM and the security states a device moves through. The SSU is the subject of a separate post.
The HSM core
An F29H85x system on chip (SoC) carries up to three C29 CPUs. The HSM is a subsystem beside them, based on an Arm Cortex-M4 core, with its own boot ROM, its own RAM, its own flash and its own debug access ports. The C29 CPUs reach it only over a mailbox.
Code authentication rests on a key pair that belongs to the owner of the firmware. The private half signs the images and never reaches the device. Key provisioning writes a hash of the public half into the one-time programmable memory (OTP) of the device, where it becomes the root of trust. TI calls this pair the Secondary Manufacturer key, or SMPK. The certificate of an image carries the public key itself, which the HSM checks against the hash in OTP before it checks the signature over the image.
The HSM runs two kinds of code:
- The boot ROM, fixed in silicon. It holds the cryptography that authentication needs: SHA-512 hashing, RSA and ECDSA signature checks, and AES-256 decryption.
- An HSM runtime, which TI’s documentation calls TIFS-MCU Firmware or HSMrt. The boot ROM authenticates such an image and starts it on the HSM core. A runtime performs key provisioning, programs the flash of a secured device, and answers crypto and OTP requests from the C29 side.
Such an image comes from one of two places. C29 code can stage it in RAM and hand it over, or the HSM can run it from its own flash. In both cases the certificate sits in front of the image, and the boot ROM authenticates it before it starts. An image in HSM flash costs no C29 flash and needs no transfer at start-up, so a product can keep its own security work there, for example cryptographic operations or an update path that checks a new image before it reaches the application flash. The C29 CPUs do not see into the HSM, whose firewalls block accesses from outside its boundary after reset until the HSM opens one.
The security lifecycle
An F29x device moves through three states, and the state it is in decides what the HSM enforces:
- HS-FS, High Security - Field Securable. The state in which a device leaves the TI factory.
- HS-KP, High Security - Key Provisioned. Key provisioning takes the device there.
- HS-SE, High Security - Security Enforced. Programming the first security configuration takes it there.
The sequence only advances, and no transition can be reversed. A fourth state, HS-FA for failure analysis, can be entered from HS-SE by deleting the security assets. It is terminal as well and plays no part in provisioning.
The boot flow
At every reset, the HSM and the C29 CPUs start in their own boot ROM. What happens next depends on the state of the device.
In HS-FS the HSM performs no secure boot of the application. The boot ROM checks that the certificate of an image has the correct format, and the application starts without a signature check.
The HSM boot ROM accepts a runtime in this state if the image authenticates against TI’s keys, whose hash is in OTP from the factory. A runtime signed with a customer key cannot run yet, since no customer key is provisioned. The runtime TI supplies for this state is the keywriter, so key provisioning is in practice what the HSM is asked to do here. Debug access to the HSM is blocked, so a probe cannot attach to its Cortex-M4 core.
In HS-KP the C29 CPUs may neither read nor program their flash, so no application boots. From this state on, the HSM boot ROM authenticates every image it is handed against the customer keys in OTP, the HSM runtime included. The runtime sent here performs code provisioning, and the first signed security configuration it programs takes the device to HS-SE. Debug access to the HSM stays blocked.
In HS-SE the HSM boot ROM performs the secure boot. It loads only application images whose X.509 certificate validates against the key in OTP, so a C29 CPU starts only code that was signed with the provisioned key. Access to the HSM boot ROM is blocked once the boot is complete.
A runtime starts on request from a C29 core, in practice CPU1, during provisioning or when the application needs one of its services. The request goes over the mailbox and names the address of the image, which is either staged in C29 RAM or already programmed in HSM flash. The boot ROM authenticates the image at that address and starts it. The runtime answers with a boot notification once it runs. The HSM takes another runtime only after a reset.
Developing before the customer keys exist
A part arrives in HS-FS, and C2Prog programs it in this state from the GUI or
from c2p-cli mkehx and c2p-cli load, with no signing and no key material involved. Early
development is therefore easiest here, and a product whose firmware needs no
protection against replacement can ship in this state as well. The boot ROM
still expects a certificate on every image. C2Prog programs the certificates
that the image carries, and generates placeholder ones where it has none.
A security configuration can be developed and tested in this state too. C2Prog writes it without the HSM and without signing, so a configuration can be tried on a device before any key exists. The SSU post covers what such a configuration contains.
Later development may continue on a provisioned device, where every image is
signed. The build then uses mkehx-cp with the keyset, which signs everything
it packages.
Provisioning the customer keys
Key provisioning starts with c2p-cli mkkeys, which generates the key pairs
into a keyset. mkkpcert builds the key-provisioning certificate from that
keyset, with the key count, the key revision and the anti-rollback floors the
device is to enforce. mkehx-kp packages the certificate with TI’s keywriter
runtime into one Extended Hex file, which is
what the operator programs.
TI’s keywriter runtime and TI’s Field Encryption Key both come from TI’s OTP
Keywriter package for the part, which is specific to the silicon revision.
mkkpcert reports what the certificate will commit before anything is written,
including the OTP fields that cannot change afterwards. A backup key pair is
optional, and this step is the only chance to write one. The device can switch
its root of trust to the backup pair later only if that pair is in OTP.
Certificates, signing and encryption
From HS-KP onwards, every image the device accepts must carry an X.509 certificate
signed with the provisioned key. That holds for the application images, for the
C2Prog flash kernel, for the HSM runtime and for the security configuration.
mkehx-cp builds each of those certificates, fills in the image hash, the load
address and the software revision, signs it, and writes the result into one
Extended Hex file.
All of this happens on the build machine. The certificate structures come from C2Prog rather than from a template, so the build needs no signing scripts, no OpenSSL step and no second tool from TI.
The signing key comes from a keyset that mkkeys produced, from a PEM file, or
from a PKCS#11 token. Production key management uses the PKCS#11 route, where
the private key never leaves the token and the signing happens inside it. A USB
HSM such as the Nitrokey HSM 2 serves this purpose. The manual covers its
setup.
mkehx-cp --encrypt encrypts the CPU1 and CPU3 application images with the
encryption key of the keyset, so the file carries ciphertext only. The device’s
HSM decrypts each image during provisioning and programs the plaintext into
flash. The encryption key never travels in the file: the HSM uses the copy
that key provisioning wrote into OTP.
Generating these files is a command-line task, which suits a post-build step in Code Composer Studio or a release pipeline. File generation runs on the free Basic license, and programming from the command line is a Professional feature.
A production station needs only the .ehx file, and no keys or signing
capability.
Questions for an AI assistant
An AI assistant with the C2Prog agentic interface registered has the manual and the attached hardware at hand. The questions below are the ones a first provisioning run may raise.
I have a new F29H85x board and want to end up with a key-provisioned device that runs a signed application. Which steps does that take, and in which order?
The answer follows the route through the manual, from the keys and the key-provisioning certificate to the file that takes the device to HS-SE, with the reset that each transition needs.
Explain what this key-provisioning certificate does to the device before I program it.
A certificate has its own review, which needs no device and no key. The report names the root-of-trust key and the backup key with their fingerprints, the OTP fields that become write- and read-protected for good, the anti-rollback floors and the manufacturer-specific value. Compare those fingerprints against your key inventory while the certificate is still unprogrammed, because a fingerprint that belongs to a published development key is one to catch at this point.
We want the signing key to stay inside a USB token. What does that setup look like, and what changes in the commands?
The manual has a chapter on the PKCS#11 setup, including the token C2Prog is tested against. The assistant walks through it and names the signing options that take a token instead of a keyset.
The SSU post covers the other half of F29
security, and the .ehx file post covers
what travels in the file the operator receives.