Security Architecture

Security architecture is the part of SoC design that decides what an attacker must not be able to do, and builds the hardware that stops them. A modern chip holds secrets, such as keys for encrypted storage, payment credentials and the identity of the device, and it runs software from many sources that must not all be trusted. This article explains what a chip protects and against whom, the root of trust and how keys are stored, how hardware isolates trusted from untrusted software, and the physical attacks, such as side channels and fault injection, that a design must resist.

12 min read | Intermediate

What You'll Learn

• Describe a threat model and the assets a chip must protect
• Explain the root of trust and how keys are stored on chip
• Describe hardware isolation between secure and normal software
• Identify side-channel and fault attacks and common defences

Starting From a Threat Model

Security can't be added by listing features. It starts with a threat model: a written statement of the assets to protect, the attackers expected, and what each attacker can do. The assets of a phone chip include its device keys, the user's data, the content protection keys for video, and the integrity of its own firmware. The attackers range from a malicious app, which can only run code, to a thief with the phone in hand, to a lab with probes, lasers and months of time.

Each attacker leads to different requirements. Stopping a malicious app needs isolation in hardware and correct software. Stopping someone with the device in hand needs secure boot, encrypted storage and closed debug ports. Stopping a well-equipped lab needs physical countermeasures, which cost area and power. No chip resists everything, so the threat model also says what is out of scope, and the product's cost and market decide where the line falls. A smart card for payments draws it far further than a toy.

The Root of Trust

Every chain of trust needs a first link that is trusted without being checked: the root of trust. On an SoC it is a small, carefully designed block, often with its own small processor, that holds the device's most important keys and starts the boot. Boot ROM and the Boot Flow showed how the boot ROM checks the signature of each stage before running it. The root of trust is what makes that check believable: its code is in ROM, so it can't be changed, and the public key it checks against is fixed in the chip.

Many designs put the root of trust in its own isolated subsystem, a secure enclave or hardware security module. The main processors can ask it to sign, decrypt or check something, but they never see the keys themselves. Even if the operating system is fully compromised, the keys stay inside, because no path in the hardware lets the main cores read them.

Storing Keys

Keys must survive power-off, so they need non-volatile storage. Common options are:

• One-time programmable memory (OTP), often built from fuses or antifuses, written once at the factory. Simple and permanent, but small, and some kinds can be read by a lab that removes the chip's layers.
• Physically unclonable functions (PUFs), which derive a key from tiny random differences between transistors that manufacturing leaves in every chip. The key is never stored; it is recreated at each power-up, so there is nothing to read while the chip is off.
• Wrapped keys in ordinary flash, encrypted with a key held in OTP or a PUF. This allows many keys while only one needs special protection.

Hardware also controls who may use a key. A key slot can be marked so that the crypto engine may use it but no processor may read it, or so that only the secure world may use it. Software asks the engine to encrypt with "key 3" and never handles the key's bits. A bug in software then can't leak the key, only misuse it while the bug lasts.

Isolation in Hardware

The application processors run code of very different trust: firmware from the chip maker, an operating system, and apps from anyone. Hardware gives each a level of privilege. Privilege Levels and Control and Status Registers explained how a processor's privilege modes stop user code from touching the operating system's memory. SoCs often add one more split, between a secure world and a normal world. The secure world runs a small trusted operating system that handles keys and payments; the normal world runs the main operating system and apps, and can't see the secure world's memory even with full privilege.

Making that split hold needs more than the processor. Every access on the interconnect carries a tag saying whether it comes from the secure world. Memory and devices are divided into regions, and a firewall, sometimes called a protection unit, checks each access against the rules for its region and refuses those that break them. A DMA engine working for the normal world can't be told to copy secure memory, because its accesses carry the normal-world tag and the firewall blocks them. This is the hardware side of the system-wide address checks that Memory Maps and Address Decoding introduced.

The firewall's own settings are powerful, so only the secure world may change them, and many designs lock them after boot until the next reset. A common mistake is to protect memory carefully and forget a device: a debug block, a DMA engine or a test register that can read anywhere is a way around every other rule. A security review lists every manager on the interconnect and asks what it can reach.

Debug and Life-Cycle States

Debug ports, such as JTAG, can stop the processors, read any memory and change any register. That is essential during development and a disaster in the field. Chips therefore have life-cycle states, recorded in OTP: a development state with full debug, a production state where debug is closed or needs a signed unlock, and a return state for failure analysis in which the keys are wiped first. Moving from one state to the next is one-way, so a chip in the field can't be put back into development mode.

Side Channels

A side channel leaks information through something other than the intended output: how long an operation takes, how much power it draws, its electromagnetic emissions, or what it leaves in a shared cache. If a crypto routine takes longer for some key bits than others, an attacker who times it many times can recover the key without ever reading it.

Defences match the channel. Crypto hardware is designed to take the same time whatever the data. Power analysis is resisted by masking, which splits each secret value into random shares that are processed separately, so that the power at any moment doesn't depend on the secret itself, and by adding noise. Cache and timing channels between software on the same chip are reduced by partitioning shared resources, or by flushing them on a switch between security domains. Processors that run instructions speculatively, as Out-of-Order Execution and Register Renaming describes, can leave traces of data they should never have read in the caches, which is why some well-known attacks targeted that feature. Each defence costs performance or area, so the threat model decides which are needed.

Fault Injection

A different physical attack changes how the chip behaves instead of watching it. A sharp drop in the supply voltage, a glitch on the clock, a laser pulse or an electromagnetic pulse can make a flip-flop take the wrong value or an instruction be skipped. If the skipped instruction is the branch that rejects a bad signature, the chip boots the attacker's code.

Defences include voltage and clock monitors that reset the chip when the supply or the clock goes out of range, light sensors under the top metal, duplicated checks that compare two results computed differently, and code that checks each important decision twice in ways a single glitch can't defeat both times. Some of these are the same techniques that protect against random faults, described in Safety and Reliability, aimed now at a deliberate attacker who can choose the timing.

Security Through the Design Flow

Security is designed and checked like any other requirement. The architecture spec states the threat model and the rules: which managers may reach which regions, which keys exist and who may use them, what debug allows in each life-cycle state. Reviews follow every path from untrusted code to a protected asset. Verification checks the access rules directly, including the attempts that must fail, since a test that only checks allowed accesses proves nothing about the forbidden ones. Formal tools can show that no path in the logic carries key bits to a readable register.

Some chips are also tested by outside labs and certified against published levels of protection. That forces the team to keep evidence: the threat model, the design decisions, the test results. The evidence also helps the team itself, because a security bug found after shipment can't be fixed in ROM or logic, only worked around, often at a large cost.

Common Mistakes