AnsweredAssumed Answered

HAB i.MX28 Invalid Certificate

Question asked by Per Smitt on Mar 14, 2016

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

Outcomes