If you have shipped products on the F28, you may have already dealt with device security. Setting up the DCSM, choosing keys, and configuring zones is real work, and getting it wrong can lock you out of your own device. But it is a model you have learned to manage. The F29 changes the rules: certificates, key pairs, signed firmware, a hardware security module, and a chain of one-way lifecycle states. A step that used to be a known quantity now looks like a cryptography project.
It does not have to be one. The F29 security model is genuinely more involved than the F28, but it is not something you should have to assemble by hand. This post explains what changed and why, in plain terms. Then it shows how C2Prog, which now supports the Texas Instruments F29 family, does the certificate and signing work for you, so provisioning an F29 stays a single, repeatable step.
Code security on F28 devices
F28 devices protect code with a password. Older parts use the single-zone Code Security Module (CSM). Newer parts use the Dual Code Security Module (DCSM), which adds a second independent zone, so two parties can secure their own code on the same chip.
Each zone is guarded by a 128-bit password held in one-time-programmable (OTP) memory. To read, debug, or erase protected code, you supply the password and the device runs its password match flow to unlock the zone. The model rests on a shared secret: whoever knows the password has access. C2Prog runs that match flow and unlocks the correct zone for you.
This password keeps code from being read, but the F28 has no built-in mechanism for reflashing an encrypted firmware image: a field update normally requires unlocking the security module first. CodeSkin secure bootloaders close that gap, keeping the DCSM locked at all times and decrypting an AES-encrypted image on the target so the plaintext code never travels over the programming link.
Two kinds of keys
The F28 and F29 models use cryptography in different ways. It helps to understand the difference first.
The F28 model uses a shared secret. This is called symmetric. There is one secret value. The same value both locks and unlocks the device. Anyone who knows the secret has full access. So you must protect the secret in every place that programs a device, including the factory floor.
The F29 model uses a key pair. This is called asymmetric. A key pair has two parts: a private key and a public key. The two parts belong together, but they are not the same value.
- The private key signs the code. You keep it secret and in one safe place.
- The public key checks the signature. It does not need to be secret.
On F29 you sign your code with the private key. The device checks the code with the matching public key. The private key never goes onto the device, and it never goes to the factory floor. The factory only handles signed files, not the secret key.
This is a main reason the F29 model is stronger. With F28, the secret must travel to every place that programs a device. With F29, the secret stays in one place, and only signed files travel.
Security on F29 devices
The F29 does more than keep your code from being read. It adds protections the F28 does not have. It verifies that the code it runs is authentic: an F28 password can keep code from being read, but it cannot prove that the code on the device is genuine. The F29 can also download code in encrypted form, so your firmware stays confidential on its way onto the device. Both rely on certificates and digital signatures rather than a shared password.
Inside the chip is a Hardware Security Module (HSM). The HSM holds the root of trust, a key the device is set to trust, and it only accepts code signed by that key. It checks the signature when you program the device and again at every boot. If the signature is not valid, the device does not run the code, so the protection is active both during programming and during normal operation.
The F29 security model also reaches beyond the F28 zone concept. A security profile, enforced by the device’s Safety and Security Unit (SSU), governs how the device behaves, including its operating mode. You set this profile during provisioning, described below.
The root of trust is written one time into OTP memory. It cannot be changed later, so the device moves through a fixed sequence of states and cannot return to an earlier one.
The three lifecycle states
The F29 device moves through three states, always in the same order:
- HS-FS (Field Securable). The starting state. The device is still open. The HSM does not verify any keys yet. A dummy certificate is enough to let the code run.
- HS-KP (Key Provisioned). Your keys are now written into the device. The root of trust is set. From this point, code must be signed.
- HS-SE (Secure). The security profile is active. The device runs only signed code.
The order is HS-FS, then HS-KP, then HS-SE. Each step is one way. You cannot move back.
You do not have to move through all the states. It is also fine to leave the device in HS-FS. In that state the device runs your code with a dummy certificate and does not enforce key security. This is similar to an F28 that does not enable its code security (DCSM).
The three provisioning steps
Each state change is one provisioning step:
- Key provisioning. Write your keys into OTP. This moves the device from HS-FS to HS-KP.
- Security configuration. Program a security profile. The profile defines the device’s security settings, including its operating mode (the SSUMODE), and goes well beyond the F28 zone model. TI provides default profiles in the F29 SDK. Programming a profile while the device is in HS-KP moves it to HS-SE; you can also update the profile later, once it is in HS-SE.
- Application code. Program your signed firmware.
After key provisioning, every file you program must be signed.
The added complexity of F29
On F28 you configure your zones and set their passwords. On F29 there is more to manage: you need keys, certificates, and signatures, you must program a security profile, and you must follow the order of the lifecycle states.
TI examples build and sign these files with OpenSSL, with Python scripts, and inside Code Composer Studio. This takes time to set up. It is also easy to make a mistake.
C2Prog handles the complexity
C2Prog creates and signs the certificates for you. You give it your .out file. C2Prog makes a file that is ready to program.
For this you do not need OpenSSL or Python scripts. C2Prog does the certificate and signing work.
One command turns a .out file into a ready file:
c2p-cli mkehx-cp --target=29H850TU-CPU1_UART --sign-key-file smpk.pem application.out
You set up your keys one time. For this you use the TI Cybershield Toolkit (CST). CST creates your manufacturer keys and the key provisioning certificate. After that, C2Prog handles the rest: code provisioning, security configuration, and application signing.
C2Prog supports three ways to sign:
- A key file, for testing.
- A CST session, for development.
- A hardware token through PKCS#11, for production. The private key stays inside the token and is never written to disk.
In the C2Prog workflow, your firmware does not contain a certificate. C2Prog always generates the certificate for you. This is also true in the first state. In HS-FS the device has no custom keys yet, so it only needs a small dummy certificate to boot. C2Prog produces this dummy certificate, so the first programming step works without any extra setup.
One build step instead of many
The TI example projects use a series of post-build steps. These steps call OpenSSL and Python to create a certificate and add it to the .out file. This is hard to set up and easy to break.
C2Prog replaces all of these steps with one. C2Prog reads your .out file and produces the ready .ehx file. You can run this as a post-build step in Code Composer Studio:
"C:\Program Files\C2Prog 2.x\c2p-cli.exe" mkehx-cp --target=29H850TU-CPU1_UART --sign-key-file smpk.pem ${BuildArtifactFileBaseName}.out
Now every build gives you an .ehx file, containing signed binaries, that is ready to program. You can run the same command outside of Code Composer Studio as well, for example on a build server.
One file for the factory floor and the field
The output of C2Prog is an Extended Hex file (.ehx). This single file holds everything needed to program a device:
- the bootloader,
- the HSM runtime,
- your binary,
- and all required certificates and signatures.
All certificates and signatures are created when the ehx file is built. The signing keys stay with the person who builds the file. The operator does not need them.
Because everything is in one file, the operator does not configure anything. On the manufacturing floor, or in the field, the operator opens the ehx file and programs the device. The ehx file can also be password protected. This protects your code and stops unauthorized use.
The short version
- F28 keeps code from being read, using a password. F29 goes further: it verifies code authenticity, supports encrypted download, and enforces a security profile, all built on certificates and a root of trust. The device moves through one-way states.
- The F29 model is stronger, but it is much harder to set up by hand.
- C2Prog does the certificate and signing work for you. No OpenSSL, no Python scripts, just one post-build step.
- The result is a single self-contained
.ehxfile, ready for safe programming on the factory floor or in the field.
The F29 raises the bar on device security, and you do not have to become a cryptography expert to clear it. Let C2Prog handle the certificates and signatures so you can stay focused on your application.
Download C2Prog at c2prog.com, point it at your .out file, and program your first secured F29 device today.
Setting up a secure solution for an F28 or F29 design and want a hand? Email us at info@codeskin.com. We are glad to help you get device security right from the start.