LinuxLink Login   |    1.866.392.4897 |    sales@timesys.

com                   

U a
Blog > Embedded Development > Secure Boot and Encrypted Data Storage

Secure Boot and Encrypted Data Storage

by Akshay Bhat | July 13, 2017 | Embedded Development, Security | 4 comments

This website uses cookies to understand how you use our site and to improve your experience. By continuing to use our site, you accept
2
our use of cookies, Privacy Policy and Terms of Use. To avoid the collection of cookie-based information, you can visit this site with cookies
turned off in your browser.

OK Read More
 This website uses cookies to understand how you use our site and to improve your experience. By continuing to use our site, you accept
2
our use of cookies, Privacy Policy and Terms of Use. To avoid the collection of cookie-based information, you can visit this site with cookies
turned off in your browser.
What is secure boot?
Secure boot ensures only authenticated so ware runs on the device and OKis achieved by verifying digital signatures of the so ware prior to executing that
Read More
code. To achieve secure boot, processor/SoC support is required. In our experience, some of the more secure boot friendly processors with readily available
documentation are NXP i.MX/QorIQ Layerscape, Xilinx Zynq, Atmel SAMA5, TI Sitara and Qualcomm Snapdragon series. Some TI Sitara processors (AM335x)
might involve TI factory programming of signing keys and custom part numbers.

Protecting intellectual property and user data

While secure boot ensures authenticity, it does not protect the device from being counterfeited or prevent hackers from extracting user/application data from
the device o line (i.e. reading the non-volatile storage like NAND, eMMC using external hardware mechanisms). User data privacy and protection might be a
requirement for compliance such as HIPAA on medical devices. If data confidentiality and/or anti-counterfeit functionality is needed, then so ware/user data
needs to be encrypted. The key used for encrypting the data also needs to be protected.

Identifying components to protect

A typical Linux based system has the below components:

Bootloader
Kernel, Device Tree
Root Filesystem + User applications
Application data
Optional: Firmware (FPGA, co-processor)

Let’s explore some of the methods to secure each of the above.

Bootloader authentication
Bootloader authentication is processor specific. However the high level mechanism is usually the same, it involves:
This website uses cookies to understand how you use our site and to improve your experience. By continuing to use our site, you accept
2
our use of cookies, Privacy Policy and Terms of Use. To avoid the collection of cookie-based information, you can visit this site with cookies
Creating a public/private key pair
turned off in your browser.
Computing the hash of the bootloader image
Signing the hash with private key using vendor-specific code signing
OK tools
Read More
 Appending the signature/certificate along with public key to the bootloader image
Flashing the public key (or hash of public key) onto One-Time programmable (OTP) fuse on the processor

The processor ROM code on power-up loads the bootloader along with the signature/certificate appended to it. It then verifies the so ware by performing the
following steps:

Verify the hash of public key appended to bootloader image matches the one stored in OTP fuse
Extract the hash of bootloader from the signature using the verified public key
Compare the extracted hash with the computed hash of the bootloader. If it matches it proceed with the boot process, thus authenticating the
bootloader.

High-level overview (generic):

This website uses cookies to understand how you use our site and to improve your experience. By continuing to use our site, you accept
2
our use of cookies, Privacy Policy and Terms of Use. To avoid the collection of cookie-based information, you can visit this site with cookies
turned off in your browser.
In addition to authenticating the bootloader, the bootloader can be also encrypted before signing.

Chain of trust OK Read More

Extending the trust scheme all the way to user space involves establishing a chain of trust.
i.e. ROM verifies signed bootloader, bootloader verifies signed kernel and kernel verifies/mounts encrypted/signed root filesystem (RFS).

FIT image authentication

FIT stands for Flattened Image Tree and is a single binary that can contain multiple images along with metadata for storing image information along with
signatures, thus making it convenient to authenticate. A typical secure boot use case is to generate a FIT image containing kernel, device tree and initramfs.
The FIT image is then signed using a private key, and the signature is embedded inside the FIT image. The public key is then embedded inside U-Boot as part
of U-Boot device tree. Since the signed U-Boot is authenticated by the ROM, we can trust the public key inside of U-Boot to verify the FIT image.

Verified boot using FIT image is part of mainline U-Boot and FIT image signing is supported by mainline Yocto. Depending on the version of U-Boot/Yocto,
certainThis website
patches mightuses cookies
need to understand how you use our site and to improve your experience. By continuing to use our site, you accept
to backported.
2
our use of cookies, Privacy Policy and Terms of Use. To avoid the collection of cookie-based information, you can visit this site with cookies
Alternate approach turned off in your browser.
Instead of using a FIT image, a combined kernel/devicetree/initramfs image can be created, and SoC vendor specific APIs (when available) can be used to
OK However,
verify the combined image (similar to how ROM authenticated bootloader). Read More
to achieve this, we need good documentation and well-supported
bootloader so ware from the SoC vendor.
Root filesystem and application data protection
If a root filesystem is read only and small enough to run out of RAM, then embedding the root filesystem inside the FIT image should be su icient for
authenticating it. However, typical root filesystems are large, and we need to leverage on the mechanisms provided by the Linux kernel for authenticating
and/or encrypting its contents.

Full disk encryption or authentication

Full disk encryption or authentication involves encrypting and/or verifying the contents of the entire disk at a block level. This is performed by the kernel’s
device mapper (dm) modules. This method can be used with block devices only (eg: EMMC).

Type Linux module Operates on Used in Notes

Encrypted dm-crypt Block level Linux desktop distros, Can be used with dm-
(read/write) or (read-only) Android integrity/dm-verity for
authentication + encryption

Authenticated dm-verity Block level Android, ChromeOS  

(read-only)

Authenticated dm-integrity Block level Newly introduced Needs 4.13 kernel or higher
(read/write)

For full disk encryption or authentication, we need an initramfs (initial RAM filesystem) which is a minimal filesystem responsible for:
This website uses cookies to understand how you use our site and to improve your experience. By continuing to use our site, you accept
2
our use of cookies, Privacy Policy and Terms of Use. To avoid the collection of cookie-based information, you can visit this site with cookies
verifying the signature of the RFS before mounting a signedturned
RFS partition, andbrowser.
off in your
decrypting and mounting an encrypted RFS partition.
OK Read More
Directory/File level encryption or authentication
An alternate approach is to encrypt and authenticate on a file or directory basis. Below are some mechanisms to achieve the same:

Type Linux module Operates on Used in Notes

Encrypted ext4 Directory/File level Android Nougat Needs 4.1 kernel or higher
(read/write)

Encrypted ubifs Directory/File level Newly introduced Needs 4.10 kernel or higher
(read/write)

Encrypted ecryptfs Directory/File level Linux desktop distros

(read/write)

Authenticated IMA/EVM File level Tizen, Gentoo Potential issues with

(read/write) filesystem corruptions and
o line tampering
Complicated setup

Protecting the key used for encryption

On a desktop or cell phone, the key used to encrypt the filesystem is derived from a user password entered interactively. IoT and embedded devices typically
do not have this luxury. Hence we need to store and protect the key on the device. Below are some protection mechanisms:

Encrypt the key using a SoC mechanism (more details below)

Store the key in a external crypto or security chip (eg: ATECC508A) which provides secure storage
This website uses cookies to understand how you use our site and to improve your experience. By continuing to use our site, you accept
2
Useuse
our a external Trusted
of cookies, Platform
Privacy Module
Policy (TPM) chip
and Terms of Use. To avoid the collection of cookie-based information, you can visit this site with cookies
Remote attestation turned off in your browser.

OK Read More
Case Study: Key protection on i.MX without using a TPM
Many external security chips such as TPM are susceptible to I2C bus attacks. Leveraging secure storage capabilities of the main processor is preferred when
possible. Using an NXP i.MX processor as an example, let’s explore a method to protect the key without using a TPM. On i.MX, each processor has a unique
master key (pre-programmed by NXP) that can only be accessed by the Cryptographic Accelerator and Assurance Module (CAAM) module. A CAAM kernel
driver can be written to encrypt filesystem encryption key with the unique processor master key. The encrypted key blob can then be stored in the boot
partition. This is done as a part of the manufacturing step. During the boot process a script is run from initramfs to decrypt the key blob using CAAM kernel
driver and the plain key is then used to decrypt the root filesystem.

Since secure boot or high assurance boot(HAB) is enabled, we do not have to worry about malicious firmware being able to decrypt the encrypted key blob.
Further, the encrypted key blob is unique to each device (because of unique master key) and thus provides anti-counterfeit feature (i.e. if an attacker cloned
the contents of the flash to another device, the counterfeit device would not be able to run the so ware since it can not decrypt the key blob).

This website uses cookies to understand how you use our site and to improve your experience. By continuing to use our site, you accept
2
our use of cookies, Privacy Policy and Terms of Use. To avoid the collection of cookie-based information, you can visit this site with cookies
turned off in your browser.

OK Read More
 This website uses cookies to understand how you use our site and to improve your experience. By continuing to use our site, you accept
2
our use of cookies, Privacy Policy and Terms of Use. To avoid the collection of cookie-based information, you can visit this site with cookies
turned off in your browser.

OK Read More
Example of di erent signing/encryption keys
Component Key type Key storage Protected by

SPL and/or U-Boot Public/Private key generated by Public key hash is burnt to processor OPT fuse bits
vendor tool (eg: NXP CST tool) OTP

FIT image) Public/Private key generated using Public key embedded in u-boot Signed u-boot
OpenSSL

dm-crypt encrypted RFS and/or LUKS Passphrase (random 256 bit Encrypted key blob in boot partition Unique processor master
Application data key)

Signed RFS Public/Private key generated using Public key embedded in initramfs Signed FIT image
OpenSSl

Example partition scheme and its contents

Bootloader (SPL/u-boot) -> Raw partition

fitImage1, fitImage2, -> Unencrypted partition

rfs-key.blob, app-key.blob

RFS Image 1 (active) -> Encrypted LUKS partition

(Optional read-only)

RFS Image 2 (inactive, for -> Encrypted LUKS partition

firmware upgrade) (Optional read-only)

User Application Data -> Encrypted LUKS partition

(Read/write)
This website uses cookies to understand how you use our site and to improve your experience. By continuing to use our site, you accept
2
our use of cookies, Privacy Policy and Terms of Use. To avoid the collection of cookie-based information, you can visit this site with cookies
turned off in your browser.
Firmware upgrade security
Firmware update mechanism helps patch any security vulnerabilities and
OK introduce new features in a product. It is critical to implement a firmware update
Read More
mechanism that is secure to complement the secure boot mechanism. Below are some considerations for making the update process secure:
 Server authentication (for OTA updates only)
Use of CA certificates and TLS

Package/image signing and encryption

Built-in feature in some package managers and/or firmware update clients
Use gpg/openssl tools to external sign/encrypt if using custom update process

Integration
Once signing and encryption schemes have been tested, the next step is to integrate everything back into the build system and manufacturing setups.

Build system
Create recipes for FIT image creation
Create recipes for signing SPL, U-Boot, FIT image
Create recipes for generating initramfs

Manufacturing/factory setup
Flash OTP keys
Create encrypted key blobs
Create encrypted partitions before writing RFS image
Disable JTAG access, serial console access

This website uses cookies to understand how you use our site and to improve your experience. By continuing to use our site, you accept
2
our use of cookies, Privacy Policy and Terms of Use. To avoid the collection of cookie-based information, you can visit this site with cookies
Conclusion turned off in your browser.

Security cannot be introduced as an a erthought; it needs to be baked into the product design. It also has potential impact on device boot times, file system
OK Read More
performance, firmware upgrade process, so implementing it early in the process is highly recommended.
Timesys has in-depth experience in deploying secure boot on products across multiple platforms including Qualcomm Snapdragon 410, NXP i.MX6, i.MX7,
LS1046, Microchip SAMA5D2.

Contact us today for help with enabling secure boot and establishing chain of trust on your product.

Next: Learn how to leverage ARM TrustZone and OP-TEE to deploy applications in a hardware isolated secure environment in this blog post.

Akshay Bhat is a Security Architect at Timesys. Akshay’s experience with embedded systems spans a broad range of industries with a focus on board bring-up, driver development
and so ware security. Akshay received his MS in Electrical Engineering from NYU Polytechnic University.

About Timesys
Timesys has extensive experience with embedded system development and lifecycle management. Timesys has been instrumental in working with global leader
semiconductor manufacturers with smart, quick and quality solutions for highly complex systems with accelerated product innovation and multiple product
variants.

4 Comments
skWang on May 11, 2020 at 5:36 am

Hi, REPLY

I am currently working on an i.MX6 development board. I want to encrypt the entire file system. During the boot
process,
This website usesu-boot or kernel
cookies decrypts the
to understand howfile system.
you Thesite
use our operation
and to of encryption
improve yourand decryptionBy
experience. is continuing
called trusted
to use our site, you accept
2
our use ofhardware
cookies, (CAAM).
PrivacyIsPolicy and Terms
this feasible? of Use.
Is there To avoid
a tutorial thetocollection
for me refer to? of cookie-based information, you can visit this site with cookies
turned off in your browser.
Thanks a lot!
OK Read More
 Akshay Bhat on May 13, 2020 at 6:39 pm

Yes, it is possible to achieve entire file system encryption on i.MX. NXP recently published an app note for REPLY
the same: https://www.nxp.com/docs/en/application-note/AN12714.pdf

sawan roy on December 20, 2019 at 1:42 am

Hi, REPLY

I working on the project in which i have to implement the secure boot. In implementing the secure i able to signed the
zimage and uboot but i have no idea for signing the rootfs.

can you please help me for signing the rootfs.

Akshay Bhat on January 17, 2020 at 11:45 am

For signing the rootfs, there are 3 popular open source solutions: REPLY
1. If the rootfs is small enough to run from RAM, then include the rootfs as part of the FIT image.
Alternatively you can embed the rootfs inside the zImage and use your existing zImage mechanism to
sign the combined zImage
2. If the rootfs can not run from RAM, then use dm-verity. References:
https://www.kernel.org/doc/html/latest/admin-guide/device-mapper/verity.html
https://github.com/intel/intel-iot-refkit/blob/master/meta-refkit-core/classes/refkit-hash-dm-verity-
This website uses cookies to understand how you use our site and to improve your experience. By continuing to use our site, you accept
2
key.bbclass)
our use of cookies, Privacy Policy and Terms of Use. To avoid the collection of cookie-based information, you can visit this site with cookies
3. For read-write rootfs dm-integrity can beoffused
turned in your browser.
(https://gitlab.com/cryptsetup/cryptsetup/-/wikis/DMIntegrity)
OK Read More
 While the solutions are open source, setting up the rootfs signing for a custom platform typically
involves engineering e ort. Please contact sales ([email protected]) if you would like to engage us help
you implement the solution on your platform.

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Search
Search

Recent Articles
Vigiles Enhancements: So ware Composition Analysis & CVE Mitigation for Stronger Embedded System Security
Stop Chasing Vulnerability Ghosts: Why e icient vulnerability detection is essential to medical device security
Medical Devices: Automated Vulnerability Monitoring for Streamlined FDA Security Compliance

Topics
Continuous Testing
Embedded Development
Industrial
IoT
This website uses cookies to understand how you use our site and to improve your experience. By continuing to use our site, you accept
2
Medical
our use of cookies, Privacy Policy and Terms of Use. To avoid the collection of cookie-based information, you can visit this site with cookies
On-Premises Board Farm Cloud turned off in your browser.
Security
OK Read More
Test Automation
TimeStorm
Yocto Project

Subscribe to Our Blog

Get our feed or signup to receive email notification of new blogs and updates.

  Get our RSS Feed.

SIGN ME UP

This website uses cookies to understand how you use our site and to improve your experience. By continuing to use our site, you accept
2
our use of cookies, Privacy Policy and Terms of Use. To avoid the collection of cookie-based information, you can visit this site with cookies
turned off in your browser.

OK Read More
 SECURITY SOLUTIONS ENGINEERING SERVICES DEVELOPMENT SOLUTIONS INDUSTRIES LEARN
Timesys TRST Security So ware Engineering Services Development Acceleration Timesys Industries Overview Blog
Solutions Overview Solutions Overview
Industrial Embedded So ware Training
Secure by Design Embedded Expertise Embedded Linux IDE -
TimeStorm Medical Newsletter
Vigiles™ Security Vulnerability OS Expertise
Management Remote Development, Debug & Test and Measurement Videos
Industries Test – BFC
Managed BSP Maintenance Transportation Webinars
Case Studies Testing Automation – TAS
TRST Security Demos Demo Images
Engagement Process Embedded Linux BSP and SDK
Podcasts
Build System – Factory

Managed BSP Maintenance

ABOUT US PARTNERS
About Timesys

Management Team

News & Events

We’re Hiring

Contact Us

This website uses cookies to understand how you use our site and to improve your experience. By continuing to use our site, you accept
2
our use of cookies, Privacy Policy and Terms of Use. To avoid the collection of cookie-based information, you can visit this site with cookies
Copyright © 2018-2020 Timesys Corporation. All Rights Reserved. Privacy Policy | Cookie Policy | Eula | Terms of Service | Terms of Sale
turned off in your browser.
All company and product names mentioned and marks and logos used are trademarks and/or registered trademarks of their respective owners.

OK Read More