475510_zh-CN

是

HAB i.MX28 无效证书

HI

我在使用飞思卡尔 imx28 时遇到了问题，无法让 HAB（高度保证启动）与 U-Boot 配合使用。

我所做的是我从主线 U-启动 (v2016.01) 开始我还添加/修改了一些与居住相关的项目。选择较晚的 U-Boot 的主要原因是 Marek Vasut 通过使用 " make u-boot-signed.sb " 构建 U-Boot 来增加对生成 IVT 的支持

* 板/freescale/mx28evk/sign/u-启动-spl.csf

* 板/freescale/mx28evk/sign/u-启动.csf

* 板/freescale/mx28evk/hab.h

* 板/freescale/mx28evk/hab_types.h

* 板/freescale/mx28evk/mx28evk.c

我已将所有这些文件附在帖子中作为参考。hab.h 和 hab_types.h已从https://community.freescale.com/thread/306378 克里斯托弗-普雷舍恩（Christopher Preschern）在该书中很好地描述了他的问题和解决方案。

我使用 CST 2.3.1 生成了一棵 pki 树。我今天看到消息说，所有 2.0.0 之后的 CST 版本在 i.MX28 上都被破解了。

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

我已向技术支持部门提交了 BLN_CST_MAIN_02.00.00 的访问权限，希望很快就能得到该 CST 版本供试用。在撰写本报告时，我尚未证实这是否是造成我的问题的原因。

我曾尝试生成 1024 位密钥和 2048 位密钥，结果都一样。

我使用 CST 中的 srktool 生成了 srk_table.bin 和 srk_fuses.bin。

$ 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

以下文件已从 cst 工具复制到 u-启动根目录。

* 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

所有这些都准备就绪后，我使用它来版本和运行它

$ make mrproper

$ make mx28evk_nand_config

$ make u-启动-signed.sb

$ sudo mxsldr u-启动-signed.sb

结果如下

--------- HAB 事件 1 -----------------

事件数据：

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 -----------------

事件数据：

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 -----------------

事件数据：

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 -----------------

事件数据：

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 -----------------

事件数据：

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 -----------------

事件数据：

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

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

0x00 0x00 0x00 0x04

(HAB_INV_ASSERTION 0x0C)

我们得到了两份无效证书。这些可能来自 u-boot-spl 和 u-boot。我猜测断言是未验证代码的执行。

以下是我的问题：

1。证书无效，这是否意味着它不符合 x509 标准，还是意味着它确实是证书但与熔丝中写的 SRK_HASH 不匹配（Bank 4 Word 0.. 7）

2。在为 SRK_HASH 编写熔丝时，我不确定会发生什么。

我有一个看起来像这样的熔丝文件：

$ 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

然后应向第 4 组字 0 写入什么内容：

应该是b4d95414还是1454d9b4？

我在网上看到过指南，其中指出后者说应该按照与你用 4 字节字节的字读取文件相同的顺序编写：

$ od -t x4 srk_fuses.bin

00000001454D9B451DA39BC D8421D4E 228857BE

0000020 F33BCA1D 043F1F28 344B0C3F 572BA48A

如果我使用 otp_burner.py（仅适用于 32 位系统）并命令它打印结果，会得到以下结果，这也加强了我的理论。

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

银行 0 银行 1 银行 2 银行 3 银行 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

因此，这再次表明后一种选择是正确的。

不过，文件似乎显示了另一种选择：

HABCST_UG.pdf 第 30 页：

上节示例中的 SRK1_2_3_4_fuse.bin 文件内容如下：

93ea61d0bd30ffb62aba0b9d5e144d082dd7faeb39223d9e3f9a22a06429895a

必须按照以下顺序将哈希值烧录到 SoC 的保险丝中：

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 参考页面 957：

HW_OCOTP_SRK0：0x8002C220:31:0 超级根密钥哈希值位 255-254 （文件中有错字，应为 224 而非 254）

HW_OCOTP_SRK1：0x8002C230:31:0 超级根密钥哈希值第 223-192 位

HW_OCOTP_SRK2：0x8002C240:31:0 超级根密钥哈希值第 191-160 位

HW_OCOTP_SRK3：0x8002C250:31:0 超级根密钥哈希值第 159-128 位

HW_OCOTP_SRK4：0x8002C260:31:0 超级根密钥哈希值第 127-96 位

HW_OCOTP_SRK5：0x8002C270:31:0 超级根密钥哈希值第 95-64 位

HW_OCOTP_SRK6：0x8002C280:31:0 超级根密钥哈希值第 63-32 位

HW_OCOTP_SRK7：0x8002C290:31:0 超级根密钥哈希值第 31-0 位

我的理解是，HW_OCOTP_SRK0 的值应该是 0x93ea61d0，但如前所述，这与我找到的指南相悖。

我想知道是否有人能以一种或另一种方式确认这一点，以限制我必须向其写入错误值的设备数量。

是的，我完全意识到任何使用这些密钥签名的设备都是不安全的，因为我会分发生成的每一位。这些密钥仅用于调试和开发。

非常感谢、

佩尔-斯密特

原始附件已移至：burned_certs.tar.gz

原始附件已移至：srk_table.bin.zip

原始附件已移至：srk_fuses.bin.zip

原始附件已移至：mx28evk.c.patch.zip

原始附件已移至：u-启动oot.csf.zip

原始附件已移至：hab_types.h.zip

原始附件已移至：hab.h.zip

原始附件已移至：u-启动-spl.csf.zip

原始附件已移至：mx28evk.c.zip

i.MX2x

Re: HAB i.MX28 Invalid Certificate

当前版本的 cst（4.0.1）能与 imx28 一起使用吗？如果没有，能否将 cst2.0.0 的下载链接发送给我？
-Jari

Re: HAB i.MX28 Invalid Certificate

你好

我给您发送了带有 CST 2 链接的电子邮件。

希望对你有所帮助。

此致，

尤里。

Re: HAB i.MX28 Invalid Certificate

嗨，佩尔、

在哪里可以下载 CST 2.0.0？

在飞思卡尔的网站上，现在是 cst-2.3.2。

我想在 i.MX28 的电子启动器上签名。

Re: HAB i.MX28 Invalid Certificate

我现在已经成功测试了 CST 2.0.0，HAB 可以正常工作。对于 i.MX28 而言，2.0.0 版之后的任何版本都已失效，这实在令人遗憾。它应该写在版本说明和手册中，警告它不适用于i.MX28，这样工程师就不必浪费几天时间进行调试和寻找无法运行的原因。

因此，总结一下我的问题，以便其他人能从我的经验中受益：

问题 1：使用 CST 2.0.0

以后任何东西都会破坏 i.mx28 的 HAB。代码包的名称是 BLN_CST_MAIN_02.00.00。

问题 2：CST 2.0.0仅适用于 32 位系统

为了让 CST 2.0.0 正常工作，我安装了 ubuntu32。我用 vagrant 通过 VirtualBox 快速安装了一个 ubuntu 服务器。已附上包含配置的 VagrantFile。

问题 3：CST 2.0.0 在没有熵发生器的情况下需要 20 分钟才能执行

为了解决 CST熵问题，我必须安装 rngtools。

$ sudo apt-get install rng-tools

问题 4：由于缺少密钥，使 u-启动-signed.sb 失败

这是我的错。在上面的文章中，我只将 CSF1 和 IMG1 证书复制到 U-启动根目录中。还需要私钥。

问题 5：如何写熔丝

在 64 位系统上，otp_burner.py 已损坏。BitInit.exe 显然可以在某些 Windows XP 系统上运行，但我没能让它在 Windows 7 64 位和 Windows XP 32 位系统上运行。

使用 Linux 命令 od 代替这些错误的工具。

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

0000000 D7DD02F7 596A91BD B7FB2EC3 09525B17

0000020 6fe30579 0bb67f9e 7e53c7e4 44f06a93

然后就可以使用制造工具写入这些值：

Burn Word 0 of SRK hash field in OTP

或者在 U-Boot 中使用熔丝命令：

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

在启动中将 #define CONFIG_CMD_FUSE 添加到 mx28evk.h 中，以在熔丝支持下进行编译。

或者使用飞思卡尔 OTP 代码包中的 BitBurner.exe 手动编写它们。这是最有效的 OTP 工具。

问题 6：共享驱动器

我犯了在 Virtual Box 中的共享驱动器上版本 U-启动的错误。大错特错。速度要慢得多，最后一个步骤失败了，说 mkimage 无法映射 u-启动-signed.sb。只要避免在共享驱动器上工作就可以了。

结论

这些步骤与我上面的帖子相结合，应该能让 HAB 在 iMX28 上运行。至少它对我来说非常有效。我甚至将 HAB 设为关闭，并验证了未签名软件不会执行。

最后要注意的是，要在32位的ubuntu服务器上版本U-Boot，你显然需要一个32位的工具链。你还需要安装 libssl-dev 和其他一些代码包才能构建 U-启动。但是，如果你已经走了这么远，编译 U-启动是你最不关心的问题。

Re: HAB i.MX28 Invalid Certificate

相信我，我很想用那里描述的工具作为基准，了解它应该是什么样子。不幸的是，问题就是从这里开始的。

otp_burner.py - 无法在 64 位系统上运行。我在虚拟机中安装了一个 32 位 ubuntu 服务器并在那里运行。正是有了这个工具，我就可以清楚地知道应该如何设置熔丝。

BitInit.exe - 该工具在 Windows 7 64 位和 Windows XP 32 位操作系统下会崩溃。由于它一直崩溃，我无法将其用作参考。

BitBurner.exe-这个工具需要你手动写熔丝。就像制造工具一样，你需要知道熔丝在使用这个工具时应该具备的价值。

我之所以问熔丝问题，是因为这些工具无法给出百分之百确定的答案。我 95% 确定应该是什么样子，但由于熔丝的写作是最终的，所以我想进行一些外部验证。我现在正在准备一个 32 位工具链，因为你给我的 CST 2.0.0 只能在 32 位 Linux 下运行。非常感谢你提供的工具，一旦试用成功，我将立即报告我的成败。

但我想知道，使用这些工具的客户和开发人员的内存是否会低于 4GB，并使用 32 位系统？

Re: HAB i.MX28 Invalid Certificate

你好

可能建议您只遵循应用笔记 AN4555（使用 i.MX28 HAB 版本 4 进行安全启动）
第 6 节（管理电气熔丝）。

祝您愉快，
Yuri

-----------------------------------------------------------------------------------------------------------------------
注：如果本帖回答了您的问题，请点击正确答案按钮。Thank you!
-----------------------------------------------------------------------------------------------------------------------