Cortex-M33 TrustZone for Security Certification

TrustZone on the Cortex-M33 builds a vault into the chip. A secure region of memory and a matching secure CPU state hold the keys, the boot code, and the cryptographic routines. Nothing outside that region can read what sits inside. The application reaches the vault only by calling through a few vetted gateways, and it never touches the keys directly. A security certificate is awarded to that boundary and to the small body of code behind it. The part number on the package earns nothing on its own. This is the core a vendor reaches for when a product has to pass PSA Certified, SESIP, or a Common Criteria lab. A boundary protects only as far as it stays small. A team settles that scope long before any certificate is on the table.

The line the hardware draws

The split rests on two small hardware blocks. A Security Attribution Unit, set by software, and an Implementation Defined Attribution Unit, fixed by the chip maker, together label every region of the address space as secure, non-secure, or non-secure callable. The processor carries a security state that tracks the region of memory it is executing from. In the secure state, the core may read and write the secure regions and reach the secure peripherals. The hardware refuses every one of those accesses the moment the core is anywhere else, and it refuses in the same cycle as the access, with no software check in the path. The labels and the state move as one piece, so the protection holds whether or not any firmware remembers to enforce it.

The boundary is set up once and then frozen. Early secure boot code programs the attribution unit, marks the secure and callable regions, and locks the configuration before any non-secure code runs. Interrupts are split the same way the memory is. Each interrupt line is assigned to a world. A secure timer or a secure crypto block raises its interrupt straight into secure code. The non-secure scheduler never sees that line. A single configuration bit lets secure interrupts take priority over every non-secure one. A security event is never starved by application load. An illegal reach across the line raises a secure fault, a dedicated exception the secure world handles as its designers chose, from a quiet log entry to a hard reset.

The interesting part is the crossing. The only way for non-secure code to enter the secure world is to call a function whose entry sits in a non-secure callable region and opens with a Secure Gateway instruction. Land anywhere else inside secure memory and the core faults at once. So the secure side publishes a short list of entry points, fixed at build time. Every call from the application arrives on one of them. The veneer functions in the callable region are the entire public surface of the secure world. A reviewer can read them in an afternoon.

Each crossing costs only a handful of processor cycles. The application calls a secure function the way it calls any other.

Each world also gets its own copy of the core’s control machinery. There are two stack pointers in each state, a banked set of special registers, a separate memory protection unit, a separate SysTick timer, and a separate vector table with its own fault handlers. A fault raised in the non-secure world is taken by non-secure code and need never expose a secure address. Each attribution unit can mark only a finite number of regions. A design lays out its secure code and data in a few contiguous blocks, kept together by intent. The secure side also carries its own two-tier privilege, a privileged handler above an unprivileged set of services. A flaw in one secure service cannot freely rewrite another. The secure world keeps its own view of memory protection. A bug in the application cannot rearrange the secure side’s permissions. This duplication is what lets the two halves run as if they were two processors that happen to share one arithmetic unit.

What a certificate is awarded to

A security certificate is a record that an independent lab tried to break a defined boundary and reported how far it got. The work is paid for, scheduled, and carried out against a written target that names the assets in scope and the attacks allowed against them. A part with TrustZone gives that lab a real boundary it can test. The hardware separation is the thing under examination, together with the services sitting behind it. A questionnaire about good intentions is one kind of assurance. A lab with the part on the bench and a budget to attack it is another. A certificate names which kind was done, and means something only against a written threat model. The security target names the assets the product protects, the attackers it assumes, and the attacks left out of scope. A reader who skips that document learns little from the mark on the box. A strong result against a weak threat model proves almost nothing. The serious schemes pin the model down in a protection profile the whole industry shares. Two certified parts can then be compared on the same terms. Certification also stacks in layers: the silicon vendor certifies the chip and its Root of Trust; a platform vendor certifies the secure firmware built on top; the product team certifies its own application last. Each layer reuses the evidence from the one below it. This composite approach is what keeps the top layer’s evaluation small, since the heavy work was signed off underneath before the product team began.

Each scheme sets its own bar for how hard the lab pushes. PSA Certified defines three levels of rising rigour: a security questionnaire reviewed at Level 1, an independent test of the Root of Trust against software attack at Level 2, and a substantial hardware-and-software attack, side-channel and fault injection included, at Level 3. SESIP carries the same approach into the IoT market and reuses much of the Common Criteria method. Common Criteria itself, graded in Evaluation Assurance Levels, is the heavyweight scheme a payment or government product meets. A team picks the scheme its market demands. The secure world is then sized to survive that level of attack, no more and no less. The evidence a lab works from is concrete: the design of the secure world, the source of its services, the threat model, and the lab’s own log of what it tried and where it stopped. A certificate is the short public summary of that thick private file.

The discipline of a small secure world

The hardware gives a boundary. The certificate depends on what that boundary surrounds. An evaluator counts the code inside the secure world and reads every entry point in the callable region, because each one is a way in. The amount of secure code is the amount of software that has to be proven correct under attack, so the size of the secure world is the size of the job.

Every exported function is a door someone will try. A wide secure interface is a wide attack surface.

So the secure side is kept deliberately thin. It holds the assets and the few operations that touch them: store a key, sign with it, verify a firmware image, hand back a yes or a no. The application asks for an outcome and receives it. The key material never leaves the secure side. Nothing in the published interface lets the caller read a key or step through the algorithm that uses it. A good secure interface reads like a short list of verbs. It stays that small on purpose. Each call takes a handle and some data, does one defined thing, and returns a status. The caller names a key by an index it was handed at provisioning. The value of the key never appears in the call at all. Even the identity of the key stays on the secure side.

Teams fall into the opposite mistake just as often. One treats the secure world as a convenient privileged mode and moves a slab of the application into it, chasing speed or direct access to a peripheral. Secure code grows. The attack surface grows by the same amount. The evaluation that follows has more to read, more to test, and more to find. A defect in that swollen secure world runs with the keys in reach. That is the one place a defect can do the greatest damage.

A certifiable design holds the secure world to a minimum by intent. It starts as the smallest thing that can carry a root of trust and grows only when a new asset genuinely earns the protection. Every line added to the secure side is a line that has to be reviewed, tested, and defended in the lab. The teams that pass on the first attempt tend to be the ones that kept the secure side boring. The framework puts numbers on the discipline. PSA defines isolation levels of rising strictness. The first separates the secure world from the application. The second walls the Root of Trust off from any other secure code. The third isolates each secure service from its neighbours behind its own protection-unit regions. A higher level costs more memory regions and more time in the calls between partitions. A design picks the level its certificate target asks for and pays only that much. The wrong instinct shows up early. A team with a TLS stack and a tight deadline notices that the crypto already lives on the secure side and decides to move the whole stack in next to it. The secure world doubles. A parser that faces the open network now runs with the keys in reach. A single buffer overrun in it reaches straight past the boundary, into the keys it was meant to protect. The fix is to leave the stack outside and let it call in only when an operation needs a secret.

What lives behind the boundary

Everything the secure world holds shares one trait: a product cannot add it back after the fact. That is what makes them the services to wall off. The chain starts at power-on, with an immutable boot stage burned into the chip that no later code can alter. It measures the next stage, checks the measurement against a known value, and only then lets it run. Each stage vouches for the one above it. A single trusted instruction at reset reaches all the way up to a trusted application a hundred thousand instructions later. Break the chain at any link and the part refuses to run. The first link is the one that cannot be patched, fused into ROM at the factory, because a root of trust a remote attacker could rewrite would be no root at all. On that foundation sits the secret the whole scheme protects. A private key is generated inside the boundary, sealed there, and used there, and it never appears in memory the application can read. The secure side does more than hide the key. Signing and decryption run there too. An application asks for a signature and receives one. The key that made it stays where no bug in the caller can reach. Attestation turns that sealed identity outward. The part signs a short report of which firmware it is running, using a key only the secure world holds. A server reads the report and decides whether this device, in this exact state, is one it will talk to. The report carries the boot measurement and a fresh number the server picked. A recorded reply cannot be played back later, since that number is never the same twice. Secure update keeps the arrangement honest over time. A new image is checked against a key in the secure world before a byte of it runs. A monotonic counter then refuses any image older than the one installed. A flaw that was fixed cannot be quietly reopened. None of this is a product team’s to invent. Trusted Firmware-M implements the set to the PSA specification and runs as the secure-world firmware on a wide range of Cortex-M33 parts. A silicon vendor submits its own build of it for evaluation once. A team that starts there inherits a secure world the chip maker already designed and certified. Its effort goes to the application. The cryptographic core under it arrived finished.

The cost of a certificate, and what a base saves

Certification is neither free nor fast. A higher assurance level raises the figures a lab quotes. A Common Criteria evaluation can run from a few months to about two years and from tens of thousands of dollars into the hundreds of thousands. A deeper attack pushes both numbers up. What the lab does explains the climb. The lighter levels read the design documents and run a catalogue of known software attacks against the interface. The heavier levels add a bench: power-analysis rigs and fault-injection gear that glitch the supply and the clock to make the silicon skip a check. That hardware work is slow. It needs rare skill. A high-assurance evaluation is counted in lab-months for exactly that reason. A PSA Certified Level 2 evaluation is a time-boxed lab test measured in weeks. A schedule feels the calendar cost as keenly as the money, since a certificate sits in the gap between a finished design and a legal shipment into a regulated market.

That regulated market is no longer a niche. The European Radio Equipment Directive added security provisions for connected products, in force for new equipment from August 2025. The Cyber Resilience Act reaches further, with a duty of care across the life of anything carrying a digital element sold into the bloc, phased in over the years that follow. In the United States, a Cyber Trust Mark covers consumer IoT. A product that ships on a plain MCU today will often need a documented security posture to enter these markets at all. A certified secure core is the shortest path to one. A recall after launch costs far more than the evaluation it skipped.

A pre-certified secure core turns that cost from a wall into a step. When a vendor has already put its Root of Trust through Level 2 or Level 3, a product built on it does not re-certify the core. The evaluation reuses the vendor’s evidence and looks only at what the product added on top. A secure world that took the chip maker months to certify arrives as a credential the product inherits on day one. The team’s own lab time then covers its application and its own assets, a far smaller job than proving a cryptographic core from nothing.

The inheritance comes with a condition. The secure world has to stay stable, since a change to the certified code can pull the whole product back into the lab. A team that keeps its own logic in the non-secure world updates that logic freely and leaves the certificate untouched. This is one more reason the secure side is kept small and slow to change. The credential a team inherits is only as durable as its discipline about what it adds to the secure world after the fact.

Deciding for a product

The decision turns on a single question. Does the product hold a secret, or answer to a regulator. The cases that need a certificate are easy to name: payment terminals carrying card data, smart locks guarding a credential, medical and metering devices under a regulator’s eye, and the broad class of connected goods now covered by the Cyber Resilience Act in Europe. For any of these, a certificate is a condition of sale. The hardware boundary is the reason an M33 part wins the socket. That choice belongs early in the design. Retrofitting security onto a product that skipped it means re-opening the architecture, re-spinning the board, and paying for an evaluation. A boundary planned in from the start would have folded that evaluation into the schedule.

Once the need is settled, the part choice narrows to what a vendor wraps around the core. Several families carry a Cortex-M33 with TrustZone, among them ST’s STM32L5 and U5, NXP’s LPC55S6x, and Nordic’s nRF5340. The Arm core inside them is identical. What separates them, once certification is the goal, is the secure firmware and the credential behind it: a Trusted Firmware-M port on one, a hardware accelerator and an on-chip key-derivation block on another, a Root of Trust that already carries a PSA Certified or SESIP result on a third. A part that brings that certified Root of Trust earns its higher price the moment a product has to certify, since the alternative is to build and prove a cryptographic core in-house, a detour of months few schedules can absorb. A part without one runs the same application code. It hands the entire security burden back to the team. The market also has a say in which credential counts: a payment product needs an EMVCo or Common Criteria result, a consumer device in Europe one that satisfies the Cyber Resilience Act, an industrial sensor often a SESIP level. The right part is the one whose existing evidence lines up with the scheme the product has to meet.

A certified part also adds a manufacturing step to the plan. Before it ships, the part goes through provisioning: a controlled flow that loads its keys, closes its debug access, and has to fit the factory behind it. A vendor may run that flow as a service in its own facility, or hand over a tool so a team can provision on a trusted line of its own. The keys can be injected in that step, or generated on the part and never exported, or derived by a physical unclonable function from variations in the silicon that no two chips share. From then on the lifecycle state governs the part. Debug stays open through development and closes when the unit is deployed. A return can reopen it only through a path that leaves the keys untouched. Getting that flow wrong is expensive in its own right. A key exposed on the production line, or a debug port left open across a batch, voids the security of every unit it touched. No firmware update reaches back to fix a key that already leaked. Second-sourcing runs into the same wall. A board can route for a second M33, since TrustZone is an Arm standard at the source level. The certificate does not travel with the layout. It belongs to the chip maker whose secure firmware earned it.