Introduction to Security Design in Embedded Linux Systems

Follow + star our public account, don’t miss the wonderful content

Author: HywelStar

Recently, while chatting with several friends involved in embedded systems, we discussed system security and found that many projects are still relatively weak in system-level security design. Today, let’s talk about what security hardening can be done at the system level in embedded Linux.

The goal is simple: from the moment the device is powered on, every step must be “trusted”, from the chip, bootloader, to the kernel, file system, and user space—a completetrust chain is constructed.

1. TrustZone: Hardware-Level “Doppelgänger”

Think of ARM’s TrustZone as giving the chip a “dual system”:

• • One is the Secure World, dedicated to sensitive tasks like encryption and key storage;
• • The other is the Normal World, running the familiar Linux system.

These two worlds are isolated from each other, with the Normal World unable to access data and code in the Secure World.

In practical projects, TrustZone is typically used for:

• • Securely storing keys for encryption/signing;
• • Handling firmware signature verification;
• • Performing encryption and decryption operations during the boot phase;
• • Verifying OTA upgrade packages.

Many common platforms support it, such as NXP i.MX8, STM32MP1, TI’s AM64x, etc.

2. Secure Boot: Don’t Let Unrecognized Code Run

Secure Boot acts as the “gatekeeper” of the entire boot process, with the core idea being:No signature, no entry.

The boot process is like a series of interviews, where each level must verify the “identity card” of the next level:

1. 1. Boot ROM (built into the chip): verifies the signature of the first stage bootloader;
2. 2. SPL / FSBL: performs initialization;
3. 3. U-Boot / SSBL: continues loading the kernel and device tree;
4. 4. Kernel: finally loads rootfs and starts the system.

The key points are:

• • Each boot file must be signed (e.g., RSA, ECDSA);
• • The chip’s internal (e.g., OTP/EFUSE) public key hash must be pre-burned to prevent tampering;
• • If a signature mismatch is detected, the system immediately halts, preferring not to run than to make an error.

STM32MP1 is a typical example, supporting RSA2048 / ECDSA signatures, along with AES encryption, and can be set up using STM32CubeProgrammer to burn the OTP Key.

3. Key Storage: A Secure “Safe”

No matter how secure the mechanism, keys must be stored securely. Where should these keys be stored?

Common storage solutions include:

Storage Method	Description
OTP	One-time programmable, cannot be changed once written, e.g., UID, authorization codes
EFUSE	Burnable bits, suitable for storing hashes, public keys, SN, etc.
TPM Chip	Dedicated security chip that can store keys, perform signing, and work with Secure Boot
Secure Element	Small encryption chip, like ATECC608B, dedicated to encryption tasks

Recommendations:

• • Public key hashes must be burned into OTP or EFUSE;
• • Private keys should ideally never leave the chip (and should not be stored in the file system);
• • Some platforms can also use the chip’s unique ID (UID) as input for authorization calculations, which is quite useful.

4. Practical: How to Sign U-Boot Images?

U-Boot itself supports image signing, and it’s not too complicated to set up:

1. 1. Configure U-Boot’s signing support:

   CONFIG_FIT=y
   CONFIG_FIT_SIGNATURE=y
   CONFIG_RSA=y
   CONFIG_OF_CONTROL=y

2. 2. Generate an RSA key pair:

   openssl genrsa -out dev_key.pem 2048
   openssl rsa -in dev_key.pem -pubout -out dev_key_pub.pem

3. 3. Package and generate a signed FIT image:

   mkimage -f fit.its signed.itb

4. 4. Burn the public key hash into the device’s OTP area;
5. 5. During boot, U-Boot automatically verifies the image signature, and if it fails, it will not continue.

This process can prevent U-Boot or the kernel from being maliciously replaced, making it especially suitable for industrial or IoT scenarios.

5. System Integrity Verification: Don’t Let Anyone Tamper with rootfs

Even if your Secure Boot is well implemented, the system may still be tampered with after it starts. What can be done?

Here are some solutions:

• • dm-verity: A “read-only verification” mechanism supported by the kernel, similar to a read-only rootfs + hash tree verification;
• • IMA/EVM: Linux security modules that can verify the signatures or hashes of executable files;
• • OSTree/RAUC: Used in conjunction with rootfs signing, also suitable for system-level OTA upgrades.

Thus, even if a hacker gains access to the system, they cannot modify any critical files.

6. What Does a Complete Trust Chain Look Like?

With the entire setup, a secure link can be designed as follows:

BootROM → Bootloader → Kernel → RootFS → Application Authorization Files

At each level:

• • All must have signature verification;
• • All must know which file to load at the next stage and which public key to use for verification;
• • All must ensure “I trust you because you are the trusted one”.

This way, it can be achieved:

• • Every piece of code executed is trusted;
• • Each system’s identity is unique and cannot be counterfeited;
• • OTA upgrades will not introduce risks.

7. Conclusion

Ensuring security in embedded systems is not just about “setting up a firewall”. It should run through the entire lifecycle:

• • From powering on the chip, to system startup, to function authorization, every step should have security measures;
• • TrustZone / Secure Boot / Signature Verification / Key Storage are the foundations for building a “trust chain”;
• • The earlier security is considered, the less likely there will be issues later.

In today’s world, where IoT, industrial devices, and automotive terminals are becoming increasingly prevalent, these “system-level security capabilities” may be the core competitiveness of your product.

Previous Recommendations

Watchdog: Differences and Usage Analysis of IWDT and WWDT

TODO/FIXME/XXX: “SOS Signals” in Embedded Code

Mounting JFFS2 File System in Linux

Discussing File Systems in Embedded Systems

How to Flexibly Manage Python Versions in Linux

Common Web Servers Used in Embedded Devices

How to Monitor Files or Folders in Linux

How to Use systemctl to Add Custom Startup Services

Implementation of USB RNDIS Network Sharing in Linux

GitHub Website Tips

Common Commands in Linux U-Boot

Analysis of Root File System Construction

Click“Read the original text” to recharge together!