Integrity Verification in Embedded Systems
(2026) EITL05 20261Department of Electrical and Information Technology
- Abstract
- Linux-based embedded systems are often deployed for long periods, updated in the field, and
expected to remain trustworthy under limited maintenance. Secure boot can protect the startup
process by verifying software before execution, but practical secure boot depends on more than
boot-time signature checks. Trust anchors, key material, provisioning steps, update mechanisms,
and release artifacts must remain consistent throughout the device lifecycle.
This thesis analyzes secure boot, cryptographic key management, and provisioning in Linux-
based embedded systems, with emphasis on practical maintainability. The work combines a
literature and standards review, a comparative analysis of selected secure boot solutions, and a
practical... (More) - Linux-based embedded systems are often deployed for long periods, updated in the field, and
expected to remain trustworthy under limited maintenance. Secure boot can protect the startup
process by verifying software before execution, but practical secure boot depends on more than
boot-time signature checks. Trust anchors, key material, provisioning steps, update mechanisms,
and release artifacts must remain consistent throughout the device lifecycle.
This thesis analyzes secure boot, cryptographic key management, and provisioning in Linux-
based embedded systems, with emphasis on practical maintainability. The work combines a
literature and standards review, a comparative analysis of selected secure boot solutions, and a
practical case study on an NXP i.MX 93 platform. The case study applies the resulting princi-
ples in a company-provided Atlas Yocto-based environment using Advanced High Assurance
Boot (AHAB), dm-verity, the Robust Auto-Update Controller (RAUC), and release artifact
traceability.
The practical implementation added read-only root filesystem behavior, separated writable
runtime and configuration state, integrated dm-verity for A/B root filesystem slots, adapted
RAUC to install raw dm-verity-protected images, synchronized slot-specific dm-verity metadata
after updates, and implemented an AHAB signing and provisioning workflow. The AHAB work
used Code Signing Tool (CST)-generated Super Root Key (SRK) material, programmed and
read back the corresponding Super Root Key Hash (SRKH) fuse words, and validated AHAB
behavior in Original Equipment Manufacturer (OEM) Open state with both mismatched and
correctly signed boot artifacts.
The validation showed that the storage layout, read-only root filesystem behavior, dm-verity root
mounting, RAUC A/B update flow, metadata synchronization, SRKH fuse programming, and
AHAB OEM Open event behavior operated as intended under the tested conditions. Both RAUC
update directions succeeded while preserving /dev/mapper/rootfs as the mounted root
source. For AHAB, a mismatched boot image produced an EdgeLock Enclave (ELE) key-hash
mismatch indication after SRKH programming, while the correctly signed flash_singleboot
artifact produced no remaining ELE authentication events under the tested OEM Open condi-
tions.
The results show that secure boot integration in embedded Linux depends on consistency
across several artifact boundaries: signed boot artifacts, programmed trust-anchor material,
root filesystem images, dm-verity metadata, update state, verification material, and provisioning
records must refer to the same system state. The study does not claim full production deployment
or OEM Closed enforcement, since the device lifecycle was not transitioned to OEM Closed
and a complete adversarial test campaign was outside scope. Instead, the contribution is a
method-oriented analysis and case study that connects general secure boot principles to concrete
embedded Linux engineering decisions. (Less) - Popular Abstract
- Many products that people use every day contain small computers. Examples include routers,
industrial controllers, vehicles, gateways, sensors, and connected appliances. These devices
often run for many years and may receive software updates after they have already been installed.
This creates an important security question: how can the device know that the software it starts
and later updates has not been changed by an attacker?
This thesis studies that question for Linux-based embedded systems. The central idea is secure
boot, where each part of the startup process checks the next part before it is allowed to run.
However, secure boot is not only one technical switch. It also depends on how cryptographic
keys are created, how... (More) - Many products that people use every day contain small computers. Examples include routers,
industrial controllers, vehicles, gateways, sensors, and connected appliances. These devices
often run for many years and may receive software updates after they have already been installed.
This creates an important security question: how can the device know that the software it starts
and later updates has not been changed by an attacker?
This thesis studies that question for Linux-based embedded systems. The central idea is secure
boot, where each part of the startup process checks the next part before it is allowed to run.
However, secure boot is not only one technical switch. It also depends on how cryptographic
keys are created, how trust is stored in the device, how software updates are handled, and how
the system can be maintained over time.
The work combines a study of standards, research, and vendor documentation with a practical
case study on an NXP i.MX 93 platform. The practical system used Yocto to build the embedded
Linux image, Robust Auto-Update Controller (RAUC) to handle A/B software updates, dm-
verity to verify the root filesystem, and Advanced High Assurance Boot (AHAB) to protect the
early boot process.
In the case study, the root filesystem was made read-only, while writable data and configuration
were moved to separate partitions. dm-verity was used to check that the root filesystem had
not been changed, and Robust Auto-Update Controller was adapted so that updates could still
be installed into inactive A/B slots. This required careful synchronization of update metadata,
because each updated root filesystem slot needs matching verification data before it can boot
correctly.
The AHAB part of the work was also extended beyond a simple signing test. New key and
certificate material was generated, the corresponding Super Root Key Hash fuse words were
programmed into the board, and the programmed values were read back to confirm that they
matched. After this, a wrongly signed boot image produced a key-hash mismatch indication,
while the correctly signed boot image produced no remaining authentication events in the tested
Original Equipment Manufacturer (OEM) Open state. The board was not moved to the final
OEM Closed state, so the work does not prove final production enforcement, but it does show
that the programmed trust material was used during AHAB authentication.
The main lesson is that secure boot should be treated as an engineering chain rather than a
single boot-time check. Build artifacts, signing keys, fuse programming, update bundles, dm-
verity metadata, and validation records all need to stay aligned for the system to remain secure,
understandable, and maintainable. (Less)
Please use this url to cite or link to this publication:
https://lup.lub.lu.se/student-papers/record/9247519
- author
- Fjällrud, Douglas LU and Blomén, Axel LU
- supervisor
- organization
- course
- EITL05 20261
- year
- 2026
- type
- M2 - Bachelor Degree
- subject
- keywords
- secure boot, embedded Linux, NXP i.MX 93, AHAB, dm-verity, secure updates
- report number
- LU/LTH-EIT 2026-1177
- language
- English
- id
- 9247519
- date added to LUP
- 2026-08-11 16:23:00
- date last changed
- 2026-08-11 16:23:00
@misc{9247519,
abstract = {{Linux-based embedded systems are often deployed for long periods, updated in the field, and
expected to remain trustworthy under limited maintenance. Secure boot can protect the startup
process by verifying software before execution, but practical secure boot depends on more than
boot-time signature checks. Trust anchors, key material, provisioning steps, update mechanisms,
and release artifacts must remain consistent throughout the device lifecycle.
This thesis analyzes secure boot, cryptographic key management, and provisioning in Linux-
based embedded systems, with emphasis on practical maintainability. The work combines a
literature and standards review, a comparative analysis of selected secure boot solutions, and a
practical case study on an NXP i.MX 93 platform. The case study applies the resulting princi-
ples in a company-provided Atlas Yocto-based environment using Advanced High Assurance
Boot (AHAB), dm-verity, the Robust Auto-Update Controller (RAUC), and release artifact
traceability.
The practical implementation added read-only root filesystem behavior, separated writable
runtime and configuration state, integrated dm-verity for A/B root filesystem slots, adapted
RAUC to install raw dm-verity-protected images, synchronized slot-specific dm-verity metadata
after updates, and implemented an AHAB signing and provisioning workflow. The AHAB work
used Code Signing Tool (CST)-generated Super Root Key (SRK) material, programmed and
read back the corresponding Super Root Key Hash (SRKH) fuse words, and validated AHAB
behavior in Original Equipment Manufacturer (OEM) Open state with both mismatched and
correctly signed boot artifacts.
The validation showed that the storage layout, read-only root filesystem behavior, dm-verity root
mounting, RAUC A/B update flow, metadata synchronization, SRKH fuse programming, and
AHAB OEM Open event behavior operated as intended under the tested conditions. Both RAUC
update directions succeeded while preserving /dev/mapper/rootfs as the mounted root
source. For AHAB, a mismatched boot image produced an EdgeLock Enclave (ELE) key-hash
mismatch indication after SRKH programming, while the correctly signed flash_singleboot
artifact produced no remaining ELE authentication events under the tested OEM Open condi-
tions.
The results show that secure boot integration in embedded Linux depends on consistency
across several artifact boundaries: signed boot artifacts, programmed trust-anchor material,
root filesystem images, dm-verity metadata, update state, verification material, and provisioning
records must refer to the same system state. The study does not claim full production deployment
or OEM Closed enforcement, since the device lifecycle was not transitioned to OEM Closed
and a complete adversarial test campaign was outside scope. Instead, the contribution is a
method-oriented analysis and case study that connects general secure boot principles to concrete
embedded Linux engineering decisions.}},
author = {{Fjällrud, Douglas and Blomén, Axel}},
language = {{eng}},
note = {{Student Paper}},
title = {{Integrity Verification in Embedded Systems}},
year = {{2026}},
}