HAB i.MX28 Invalid Certificate

[persmitt]

Hi

I am having a problem with a Freescale imx28 to get HAB (High Assurance Boot) working with U-Boot.

What I have done is that I have started with a mainline U-Boot (v2016.01) and I have added/modified a few hab-related items. The main reason for choosing a late U-Boot is that Marek Vasut has added support to generate the IVT by building U-Boot using "make u-boot-signed.sb"

* board/freescale/mx28evk/sign/u-boot-spl.csf

* board/freescale/mx28evk/sign/u-boot.csf

* board/freescale/mx28evk/hab.h

* board/freescale/mx28evk/hab_types.h

* board/freescale/mx28evk/mx28evk.c

I have attached all these files to the post as a reference. hab.h and hab_types.h have been stolen from https://community.freescale.com/thread/306378 where Christopher Preschern has done a really good job describing his problems and solutions.

I used CST 2.3.1 to generate a pki tree. I read today that all CST versions after 2.0.0 are broken on the i.MX28.

http://lists.denx.de/pipermail/u-boot/2015-November/234717.html

I have posted to the support to get access to BLN_CST_MAIN_02.00.00 and will hopefully soon get that CST version to try. At the time of writing I have not verified if that is the cause of my problems.

I have tried to generate both 1024 bit keys and 2048 bit keys with the same result.

I generated the srk_table.bin and srk_fuses.bin using srktool in the CST.

$ srktool -h 4 -t srk_table.bin -e srk_fuses.bin -d sha256 -c crts/SRK1_sha256_2048_65537_v3_ca_crt.pem -f 1

The following files have been copied from the cst tool to the u-boot root directory.

* CSF1_1_sha256_2048_65537_v3_usr_crt.pem

* IMG1_1_sha256_2048_65537_v3_usr_crt.pem

* srk_table.bin

* srk_fuses.bin

* key_pass.txt

Once all this was in placed I built and ran it using

$ make mrproper

$ make mx28evk_nand_config

$ make u-boot-signed.sb

$ sudo mxsldr u-boot-signed.sb

I get the following result:

--------- HAB Event 1 -----------------

event data:

    0xdb 0x00 0x14 0x40 0x33 0x21 0xc0 0x00

    0xbe 0x00 0x0c 0x00 0x03 0x17 0x00 0x00

    0x00 0x00 0x00 0x50

(HAB_INV_CERTIFICATE 0x21)

--------- HAB Event 2 -----------------

event data:

    0xdb 0x00 0x14 0x40 0x33 0x0c 0xa0 0x00

    0x00 0x00 0x00 0x00 0x00 0x00 0x80 0x00

    0x00 0x00 0x00 0x20

(HAB_INV_ASSERTION 0x0C)

--------- HAB Event 3 -----------------

event data:

    0xdb 0x00 0x14 0x40 0x33 0x0c 0xa0 0x00

    0x00 0x00 0x00 0x00 0x00 0x00 0x10 0x00

    0x00 0x00 0x00 0x04

(HAB_INV_ASSERTION 0x0C)

--------- HAB Event 4 -----------------

event data:

    0xdb 0x00 0x14 0x40 0x33 0x21 0xc0 0x00

    0xbe 0x00 0x0c 0x00 0x03 0x17 0x00 0x00

    0x00 0x00 0x00 0x50

(HAB_INV_CERTIFICATE 0x21)

--------- HAB Event 5 -----------------

event data:

    0xdb 0x00 0x14 0x40 0x33 0x0c 0xa0 0x00

    0x00 0x00 0x00 0x00 0x40 0x00 0x10 0x00

    0x00 0x00 0x00 0x20

(HAB_INV_ASSERTION 0x0C)

--------- HAB Event 6 -----------------

event data:

    0xdb 0x00 0x14 0x40 0x33 0x0c 0xa0 0x00

    0x00 0x00 0x00 0x00 0x40 0x00 0x20 0x00

    0x00 0x00 0x00 0x04

(HAB_INV_ASSERTION 0x0C)

We get two invalid certificates. These are probably from u-boot-spl and u-boot. I am guessing the asserts are the execution of the unverified code.

Here are my questions:

1. Invalid Certificate, does this mean that it does not conform to the x509 standard or does this mean that it is indeed a certificate but does not match the SRK_HASH written in the fuses (Bank 4 Word 0..7)

2. When writing the fuses for the SRK_HASH I am unsure what goes where.

I have a fuse file that looks like this:

$ od -t x1 srk_fuses.bin

0000000 b4 d9 54 14 bc 39 da 51 4e 1d 42 d8 be 57 88 22

0000020 1d ca 3b f3 28 1f 3f 04 3f 0c 4b 34 8a a4 2b 57

What should then be written to Bank 4 Word 0:

Should it be b4d95414 or should it be 1454d9b4?

I have seen guides online that indicate the latter saying that it should be written in the same order as if you read the file in 4 byte words:

$ od -t x4 srk_fuses.bin

0000000 1454d9b4 51da39bc d8421d4e 228857be

0000020 f33bca1d 043f1f28 344b0c3f 572ba48a

If I use otp_burner.py (which only works on 32 bit systems) and order it to print the result I get the following which also strengthens this theory.

$ python otp_burner.py -i bit_settings.txt -o bit_settings.sb --srk srk_fuses.bin -a -p

Bank 0          Bank 1          Bank 2          Bank 3          Bank 4

0: 0x00000000   0: 0x00000000   0: 0x00000000   0: 0x00000000   0: 0x1454d9b4

1: 0x00000000   1: 0x00000000   1: 0x00000000   1: 0x00000000   1: 0x51da39bc

2: 0x00000000   2: 0x00000000   2: 0x00000000   2: 0x00000000   2: 0xd8421d4e

3: 0x00000000   3: 0x00000000   3: 0x00000000   3: 0x00000000   3: 0x228857be

4: 0x00000000   4: 0x00000000   4: 0x00000000   4: 0x00000000   4: 0xf33bca1d

5: 0x00000000   5: 0x00000000   5: 0x00000000   5: 0x00000000   5: 0x043f1f28

6: 0x00000000   6: 0x00000000   6: 0x00000000   6: 0x00000000   6: 0x344b0c3f

7: 0x00000000   7: 0x00000000   7: 0x00000000   7: 0x00000000   7: 0x572ba48a

So once more it indicates that the latter option is the correct one.

However the documentation seems to indicate the other alternative:

HABCST_UG.pdf page 30:

The SRK1_2_3_4_fuse.bin file from the example in the previous section has the following contents:

93ea61d0bd30ffb62aba0b9d5e144d082dd7faeb39223d9e3f9a22a06429895a

This hash value must be burned to the SoC efuses in the following order:

SRK_HASH[255:248] = 0x93

SRK_HASH[247:240] = 0xea

SRK_HASH[239:232] = 0x61

...

SRK_HASH[15:8] = 0x89

SRK_HASH[7:0] = 0x5a

i.MX28 Reference page 957:

HW_OCOTP_SRK0: 0x8002C220:31:0 Super Root Key hash value bits 255-254 (Typo in document, should be 224 not 254)

HW_OCOTP_SRK1: 0x8002C230:31:0 Super Root Key hash value bits 223-192

HW_OCOTP_SRK2: 0x8002C240:31:0 Super Root Key hash value bits 191-160

HW_OCOTP_SRK3: 0x8002C250:31:0 Super Root Key hash value bits 159-128

HW_OCOTP_SRK4: 0x8002C260:31:0 Super Root Key hash value bits 127-96

HW_OCOTP_SRK5: 0x8002C270:31:0 Super Root Key hash value bits 95-64

HW_OCOTP_SRK6: 0x8002C280:31:0 Super Root Key hash value bits 63-32

HW_OCOTP_SRK7: 0x8002C290:31:0 Super Root Key hash value bits 31-0

I interpret this as HW_OCOTP_SRK0 should have the value 0x93ea61d0 but as said, that goes against the guides I have found.

I would like if anyone could confirm this one way or another to limit the amount of devices I have to write the wrong values to.

And yes, I am fully aware that any device signed with these keys is not secure since I am handing out every single bit that has been generated. These keys are debug and development keys only.

Many thanks in advance,

Per Smitt

Original Attachment has been moved to: burned_certs.tar.gz

Original Attachment has been moved to: srk_table.bin.zip

Original Attachment has been moved to: srk_fuses.bin.zip

Original Attachment has been moved to: mx28evk.c.patch.zip

Original Attachment has been moved to: u-boot.csf.zip

Original Attachment has been moved to: hab_types.h.zip

Original Attachment has been moved to: hab.h.zip

Original Attachment has been moved to: u-boot-spl.csf.zip

Original Attachment has been moved to: mx28evk.c.zip

[collinshi]

Hi Per,

Where can I download the CST 2.0.0 ?

In freescale's webisite now it is cst-2.3.2.

I want to sign my eboot for i.MX28.

[Yuri]

Hello,

I send You email with CST 2 link.

Hope it helps.

Regards,

Yuri.

[Yuri]

Hello,

It may be recommended just to follow section 6 (Manage the electrical fuses)
of app note AN4555 (Secure Boot with i.MX28 HAB Version 4).

Have a great day,
Yuri

-----------------------------------------------------------------------------------------------------------------------
Note: If this post answers your question, please click the Correct Answer button. Thank you!
-----------------------------------------------------------------------------------------------------------------------

[persmitt · Accepted solution]

I have now managed to test the CST 2.0.0 and HAB works. Anything after 2.0.0 is broken for the i.MX28 which is really a shame. It should be written in the release notes and manual a large warning that it doesn't work with the i.MX28 so engineers don't have to waste days on debugging and searching for the reason why things aren't working.

So to sum up my problems so others can benefit from my experience:

Problem 1: Use CST 2.0.0

Anything later breaks HAB for i.MX28.The software package name is BLN_CST_MAIN_02.00.00.

Problem 2: CST 2.0.0 only works on 32 bit systems

To get CST 2.0.0 to work I installed ubuntu32. I used vagrant to quickly setup an ubuntu server with VirtualBox. VagrantFile with configuration is attached.

Problem 3: CST 2.0.0 takes 20 minutes to execute without an entropy generator

To solve the CST entropy problem I had to install rngtools.

$ sudo apt-get install rng-tools

Problem 4: make u-boot-signed.sb failed due to lacking keys

This was my bad. In the above post I had only copied CSF1 and IMG1 certificates to the U-Boot root directory. The private keys are also needed.

Problem 5: How to write the fuses

otp_burner.py is broken on 64 bit systems. BitInit.exe can apparently work on some Windows XP systems, but I didn't manage to get it to work in either Windows 7 64 bit or Windows XP 32 bit.

Instead of these faulty tools use the Linux command od.

$ od -t x4  ../crts/SRK_1_2_3_4_fuse.bin

0000000 d7dd02f7 596a91bd b7fb2ec3 09525b17

0000020 6fe30579 0bb67f9e 7e53c7e4 44f06a93

These values can then be written with the MfgTool:

<CMD state="Updater" type="push" body="$ echo 0xd7dd02f7 > /sys/fsl_otp/HW_OCOTP_SRK0">Burn Word 0 of SRK hash field in OTP </CMD>

Or with the fuse command in U-Boot:

fuse prog 4 0 d7dd02f7 596a91bd b7fb2ec3 09525b17 6fe30579 0bb67f9e 7e53c7e4 44f06a93

Add #define CONFIG_CMD_FUSE to mx28evk.h in U-Boot to compile in fuse support.

Or write them manually with BitBurner.exe from the Freescale OTP package. The one OTP tool that actually worked like a charm.

Problem 6: Shared Drive

I made the mistake to build U-Boot on a shared drive in Virtual Box. Big mistake. It was significantly slower and the last step fails saying that mkimage cannot map u-boot-signed.sb. Simply avoid working on a shared drive and you are good.

Conclusion:

These steps combined with my post above should get HAB to work on the iMX28. At least it is working like a charm for me. I even put HAB to closed and verified that unsigned software would not execute.

One final note is that to build U-Boot on the 32 bit ubuntu server you obviously need to get a 32 bit tool chain. You also need to install libssl-dev and some other packages to get  U-Boot to build. But if you have gotten this far compiling U-Boot is the least of your concerns.

[persmitt]

Trust me I would have loved to use the tools described there as a baseline to know how it is supposed to look. Unfortunately that's where the problems start.

otp_burner.py - Does not work on 64 bit systems. I installed a 32bit ubuntu server in virtual box and ran it there. It is with that tool I have a good indication how the fuses should be set.

BitInit.exe - This tool crashes under Windows 7 64 bit and Windows XP 32 bit. Since it keeps crashing I cannot use it for reference.

BitBurner.exe - This tool requires you to write the fuses manually. Pretty much like MFG tool you need to know the value the fuses should have to use this tool.

It is because these tools couldn't give me a 100% certain answer that I asked about the fuses. I am 95% certain how it is supposed to be but since writing the fuses is final I wanted to have some external verification. I am right now preparing a 32 bit tool chain since the CST 2.0.0 that you gave me only works under 32bit Linux. Many thanks for the tool, and I will report my success or failure as soon as I have tried it.

I wonder though, are customers and developers who use these tools expected to have less than 4GB of RAM and use 32 bit systems?