Technology
Secure Boot with GELin - Trustworthy system startup for embedded systems
With increasing networking and growing software complexity, the attack surface for embedded systems is growing. A key security goal is therefore to ensure that only tested, unmodified software is executed.
With increasing connectivity and growing software complexity in embedded systems, the attack surface is also growing significantly. A key security goal of modern embedded Linux platforms is therefore to ensure that only tested, approved, and unmodified software is executed. Secure Boot forms the basis for this. GELin, the Ginzinger Embedded Linux Distribution, implements a comprehensive Secure Boot approach that extends from the first instruction cycle of the hardware to the running root file system.
Cryptographic fundamentals
Secure Boot is based on established cryptographic methods for ensuring authenticity and integrity.
Symmetric cryptography
In symmetric methods, the same key is used for encryption and decryption.
- Advanced Encryption Standard (AES)
- High performance, low computing effort
- Typical use: Encryption of data (e.g., file systems, memory)
However, symmetric methods are not suitable for trust checks in open systems, as the key must remain secret.
Asymmetric cryptography
Asymmetric methods work with key pairs:
- Private key: for signing
- Public key: for verification
The methods used are RSA (Rivest-Shamir-Adleman) and ECC (elliptic curve cryptography). Asymmetric cryptography is the basis for secure boot, as only the public key needs to be stored in the target system.
Chain of Trust
GELin's secure boot concept is based on a multi-level chain of trust. The aim is to cryptographically verify each software component beforehand, thereby establishing a consistent basis of trust.
Principle
- Several consecutive boot stages
- Each stage contains the public key of the next stage and validates its digital signature.
- All software components within the chain of trust are signed by the customer.
- The signature is made with the corresponding private key.
This makes the customer an active part of the security concept. The management, protection, and confidentiality of the private keys is entirely the customer's responsibility. A compromised private key undermines the entire chain of trust.
Advantages
- Individual levels can be updated independently
- Clear security boundaries between boot phases
- High flexibility combined with high security
Starting point
- BootROM of the SoC
- Contains a fused public key
- Forms the immutable root of trust
Secure Boot Chain in GELin
For NXP i.MX processors, GELin uses the integrated security mechanism:
- High Assurance Boot (HAB), which verifies signed bootloader components
- Code Signing Tool (CST) for signing the bootloader configuration and individual bootloader components
Manipulated or unsigned bootloaders are not executed by the SoC.
U-Boot: Signed images with FIT
U-Boot is used as a secondary bootloader.
- Use of FIT images (Flattened Image Tree)
- FIT image as a container for:
- Linux kernel
- Device tree
- initRAM-FS
- Configurations
All components can be signed individually. U-Boot only loads images whose signature has been successfully verified.
Linux kernel: Verification and root file system
dm-verity - Is hard-coded into the kernel.
- Block-by-block integrity check via a hash tree
- Root hash is signed and trustworthy
- Each block read is checked upon access
The public key for verification is added to the kernel via CONFIG_SYSTEM_TRUSTED_KEYS.
Root file system
- The RootFS is only mounted in a verified state
- Initial processing takes place in a RAM disk
- Changes to the file system result in mount errors
This ensures that the system only runs with an unmodified root file system.
Secure updates with GELin
Software updates are also part of the security chain.
- ge-update is also based on a file system
- Only signed update images are accepted
- Verification takes place before installation
This prevents manipulated or unauthorized updates from being installed.
Additional safety-related measures
Bootchain control
To prevent bypass attacks, additional measures are necessary:
- No interactive bootloader command line
- Bootloader environment variables hard-coded into the image
- Kernel parameters cannot be changed at runtime
Hardware security
- Blocking of JTAG and debug interfaces
- Protection against physical access to security-critical components
Licensing and compliance
- Compliance with GPLv3
- Prevention of Tivoization
- Users must be able to install their own software
- Security must not lead to impermissible restrictions
Restrictions and operational implications of Secure Boot
The use of Secure Boot inevitably leads to restrictions in system operation:
- Private key handling
- Secure generation, storage, and access control required
- Loss or compromise of the key can render devices unusable
- Limited debugging and analysis capabilities
- Secure systems are largely closed
- Error analysis and investigations in the event of repairs become significantly more complex
- Increased development and maintenance costs
- Strict processes for signing and release
- Clear separation of development, test, and production keys required
Secure Boot thus not only increases security, but also the complexity of a product's life cycle. Security is effective—but rarely convenient.
Secure Boot as part of a comprehensive security concept
Secure Boot is often considered a standalone security measure. In practice, however, it is only one component of a comprehensive security concept. The decision to use Secure Boot should therefore always be made as part of an overarching security concept that takes the following aspects into account, among others:
- Threat analysis and attack models
- Protection against physical access
- Key management and organizational processes
- Update strategies
- Maintenance, repair, and debugging in the field
The use of Secure Boot significantly increases security, but also has conceptual and organizational consequences.
Secure Boot with GELin implements a consistent, hardware-supported security architecture for embedded Linux systems. From the first instruction in the SoC to the bootloader, kernel, root file system, and software updates, every component is cryptographically verified.
At the same time, the use of Secure Boot requires a conscious security concept, clear processes, and a willingness to accept the associated restrictions. Used correctly, Secure Boot is an effective tool—not a panacea, but a central component of modern embedded security strategies.