Encrypted U-boot Example

[#1]

This example makes use of a U-Boot image as a bootloader. U-Boot is commonly used as a bootloader for Linux devices and is provide by the Freescale Linux BSP.

The default memory layout of the Freescale U-Boot port can be modified to meet the encrypted boot requirements. This is shown in figure 5. As it can be seen, this layout is similar to any other U-Boot port, with the addition of the security mechanisms appended at the end of the image.

                         Figure  Chosen memory layout of the encrypted u-boot

1)Assumptions

In designing a U-Boot image as an encrypted boot solution, there are three assumptions which accelerate and simplify the construction process.

. The U-boot image can be build for multiple board configuration, but for demonstration purposes this example uses i.MX6 Solo X

. The user is familiar with the secure configuration for U-Boot and is able to properly sign and boot a U-Boot image.

. The encrypted image will be constructed by an individual party, and there is no need to worry about provisioning the DEK.

2)Requirements

The components required to build an encrypted image are shown below. Note that the majority of these components are the product of following the signing U-Boot image procedure.

   a)Code Signing Tool in encryption mode

o To build the CST in encryption mode, run the following command

make OSTYPE=linux ENCRYPTION=yes HAB_RELEASE=~/hab/hab_release release

o Note: that CST is not in encryption mode by default. This feature needs to be enabled before encrypting the bootloader image. The performance of the CST might be affected, due to its dependency on the host entropy. Refer to the CST User Guide for more details.

  b) iMX6 Solo X device in secure mode

  c) U-Boot image with secure boot support enabled.

o To configure U-Boot to be built with secure boot support, CONFIG_SECURE_BOOT will need to be defined in the board header file (i.e. at include/configs/mx6q_arm2.h)

  d) Signed U-Boot image

o A U-Boot image with a CSF and digital signature attached.

3) Implementation

Many different implementations for constructing a encrypted U-boot image are possible. The right implementation depends on the solution’s requirement. The presented implementation is intended to provide the foundation principles; it can be modified to meet different needs.

[annguyen]

Hello,

Thank you for helpful guidline! I tried encrypted boot as following but failed to boot:

Board: MCIMX6Q-SDB

1. Enable secure features and Build u-boot from this source:

GitHub - boundarydevices/u-boot-imx6 at boundary-v2016.03

2. Use mkimage utility build and get information of u-boot.imx image

Image Type:   Freescale IMX Boot Image

Image Ver:    2 (i.MX53/6/7 compatible)

Data Size:    516096 Bytes = 504.00 kB = 0.49 MB

Load Address: 177ff420

Entry Point:  17800000

HAB Blocks:   177ff400 00000000 0007bc00

3. Generate keys and certificates with CST 2.3.2, fuse SRK table and close configution (fuse prog 0 6 0x2)

4. Create u-boot.csf as below to sign and encrypt u-boot.imx and generate dek.bin

where Blob Address = 0x1787D000 because:

Loadd address + encrypted uboot + (CSF + padding)

= 0x177ff400 + 0x7bc00 + 0x2000

5. Sign and encrypt by CST Tool :

./cst -o u-boot_csf.bin -i u-boot.csf

6. Pad u-boot_csf.bin to 0x2000

objcopy -I binary -O binary --pad-to=0x2000 --gap-fill=0x00 u-boot_csf.bin u-boot_csf.bin

7. Merge all component as following order

cat u-boot_csf.bin >> u-boot.imx

cat dek_blob.bin >> u-boot.imx

Length of each:

encrypted u-boot.imx: 0x7bc00

CSF + padding: 0x2000

dek_blob: 0x48

8. Install encrypted u-boot.imx into SD card

sudo dd if=u-boot.imx of=/dev/sdb bs=512 seek=2

sync

Insert SD card to the board, reboot but nothing shown on console via USB-to-UART port.

If I skip encryption, just sign the u-boot.imx only then it boots normally.

Can you instruct me more? Furthermore, how long is padding part after DEK_BLOB on the figure of your post?

Best regards,

An.

////////////////////////////////////////////////////////////////////////////////

u-boot.csf

////////////////////////////////////////////////////////////////////////////////

[Header]

Version = 4.1

Hash Algorithm = SHA256

Engine Configuration = 0

Certificate Format = X509

Signature Format = CMS

Engine = CAAM

[Install SRK]

File = "../crts/SRK_1_2_3_4_table.bin"

# Index of the key location in the SRK table to be installed

Source index = 0

[Install CSFK]

# Key used to authenticate the CSF data

File = "../crts/CSF1_1_sha256_4096_65537_v3_usr_crt.pem"

[Authenticate CSF]

[Unlock]

Engine = CAAM

Features = RNG

[Install Key]

# Key slot index used to authenticate the key to be installed

Verification Index = 0

# Key to install

Target Index = 2

File = "../crts/IMG1_1_sha256_4096_65537_v3_usr_crt.pem"

[Authenticate Data]

# Key slot index used to authenticate the image data

Verification Index = 2

#       Address   Offset        Length      Data File Path

Blocks = 0x177ff400 0x00000000 0x00000C10 "./u-boot.imx"

#Encrypt the boot image and create a DEK

[Install Secret Key]

Verification Index = 0

Target Index = 0

Key = "./dek.bin"

Key Length = 128

Blob Address = 0x1787D000

#Provide DEK blob location to decrypt

[Decrypt Data]

Verification Index = 0

Mac Bytes = 16

Blocks = 0x17800010 0x00000C10 0x0007AFF0 "./u-boot.imx"

[satyadamarla]

Hello Xie,

"Compile the cst tool with the options mentioned in the document". May I ask you where do I get source code for Code Signing Tool so that I can recompile it.

Greets,

Satya

[annguyen]

Hello Satya,

This is how I did to enable encryption feature for CST 2.3.2:

Link for Code Signing Tools

i.MX Software and Tools|NXP

$ sudo apt-get install libssl-dev

$ cd ~/cst-2.3.2/code/back_end/src

$ gcc -o cst -I ../hdr -L ../../../linux32/lib *.c -lfrontend -lcrypto

$ mv cst ../../../linux32

Good luck!

An.

[satyadamarla]

Hello An,

The build worked for me.

Thanks,

Satya

[satyadamarla]

Hello An,

I noticed few things that I dont understand. It would be great if you take time to clarify them to me:

1. The encrypted u-boot image: Did mkimage tool generate that for you? I think NO but who does it. Usually u-boot.bin is generated and mkimage utility uses the imxcfg.imx to generate the u-boot.imx. Please explain me how you encrypted the u-boot.bin using the key that is generated by CST.

2. DEK blob: I think the [Install Key] generates the dek.bin. I assume the dek.bin is the blob that has to be added at the last.

3. Your CSF File: Will you please elaborate on the Blocks that you use in the Decrypt part?

•     First parameter: Where encrypted USB starts?
• Second Parameter: Offset. What is this offset?
• Third Paramter: Length of the encrypted u-boot binary or something else?

Looking forward to your reply

Greets,

Satya

[annguyen]

Hello Satya,

How's it going?

1. Encrypted boot image: CST tool generates it. I just use mkimage to retrieve info of u-boot. As far as I know, follow 8 steps that I listed, encrypted image generated.

2. DEK blob: yes, CST creates it. After that, dek.bin is wrapped within the board by its secret key. You should prepare a u-boot supporting dek_blob command and try the following:

fatload mmc 1:1 0x10800000 dek.bin

dek_blob 0x10800000 0x10801000 128

fatwrite mmc 1:1 0x10801000 dek_blob.bin 0x48

3. u-boot.imx includes [IVT + DCD + padding to 0xC00] +  [u-boot.bin]

(header + u-boot.bin)

After execute CST tool with above CSF file, u-boot.bin part is encrypted.

- First parameter: HAB Blocks address + signed header = 0x177ff400 + 0xc10 = 0x17800010

- Second parameter: encrypted offset = signed header length = 0xc10

- Third paramter: length of u-boot.bin (u-boot binary)

NOTE: u-boot.imx built from DENX u-boot, if you use u-boot from other source, e.g yocto, it may be not generated, but u-boot.bin.

Hope this helps you.

Best,

An.

[satyadamarla]

Guys,

I observed the following:

The encrypted boot only works if the dek_blob is part of 0x2000 (CSF Signature) as it is mentioned in Encrypted boot loader on SabreSD i.MX6q board . The dek_blob is only 0x48 in size. So, I padded the CSF signature until 0x1F00 with zeros and the remaining (0x100) I filled it with dek_blob + zeros. 

If it is added after the 0x2000 (CSF Signature), I didn't have success. 

It would be great if members confirm or deny it. 

Thanks & Greets,

Satya

[gary_bisson]

Hi,

Yes the dek blob must be inside the CSF section.

The reason is that the bootROM only knows about the binary up until the end of the CSF section and won't load anything further of this address.

Regards,

Gary

[satyadamarla]

Hi Gary,

You are right. The reason behind this is because the size in the header of the image is size of padded image + size of CSF(0x2000). So, the image gets loaded until CSF only. But if we increase this size value by the dek_blob size then the example described here will also work. I found this when I try to authenticate kernel image (zImage). Of course I haven't tried that but that's what I think.

Greets,

Satya

[yurishilor]

Hi.

Where do you get the signed header length from (0xc10 in the example above)?

Thanks

[satyadamarla]

Hello Yuri,

Your question sin't clear. Please explain in detail.

Greets,

Satya

[stephenbiggs]

Satya, what is unclear about Yuri's question?? In this section here:

#Provide DEK blob location to decrypt

[Decrypt Data]

Verification Index = 0

Mac Bytes = 16

Blocks = 0x17800010 0x00000C10 0x0007AFF0 "./u-boot.imx"

.. how did you arrive at the 0x00000C10  number in the "Blocks" line? This is not anywhere in these instructions. There is this:

- First parameter: HAB Blocks address + signed header = 0x177ff400 + 0xc10 = 0x17800010

- Second parameter: encrypted offset = signed header length = 0xc10
but it still shows 0xc10 as some sort of magic number. How do I find the exact signed header length for my particular u-boot image? Why isn't it just 0xc00??