475510_ja-JP

是

HAB i.MX28 無効な証明書

ハイ

Freescale imx28 で HAB (High Assurance Boot) を U-Boot で動作させるのに問題があります。

私がやったことは、メインラインのU-Boot（v2016.01）から始めたことです。また、ハブ関連の項目をいくつか追加/変更しました。後期のU-Bootを選択した主な理由は、Marek Vasutが「make u-boot-signed.sb」を使用してU-BootをビルディングすることでIVTを生成するためのサポートを追加したためです。

* ボード/フリースケール/mx28evk/サイン/u-boot-spl.csf

* ボード/フリースケール/mx28evk/サイン/u-boot.csf

* ボード/フリースケール/mx28evk/hab.h

* ボード/フリースケール/mx28evk/hab_types.h

* ボード/フリースケール/mx28evk/mx28evk.c

これらすべてのファイルを参考として投稿に添付しました。hab.h と hab_types.hhttps://community.freescale.com/thread/306378から盗まれたものですChristopher Preschern 氏が、問題と解決策を非常にうまく説明しています。

pki ツリーを生成するために CST 2.3.1 を使用しました。今日読んだところによると、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-boot ルートディレクトリにコピーされました。

* 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

これらすべてを配置したら、ビルドして実行しました。

$ mrproper を作成する

$ mx28evk_nand_config を作成する

$ u-boot-signed.sb を作成します

$ sudo mxsldr u-boot-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 イベント情報 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 イベント情報 3 -----------------

イベント情報データ:

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

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

0x00 0x00 0x00 0x04

(HAB_INV_ASSERTION 0x0C)

--------- HAB イベント情報 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 イベント情報 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 イベント情報 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)

無効な証明書が 2 つあります。これらはおそらく u-boot-spl と u-boot からのものです。アサートは検証されていないコードの実行であると推測しています。

私の質問は次のとおりです。

1. 無効な証明書です。これは x509 標準に準拠していないことを意味しますか、それとも証明書ではあるがヒューズ (バンク 4 ワード 0..7) に書き込まれた SRK_HASH と一致しないことを意味しますか。

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

0000000 1454d9b4 51da39bc 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: 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: 0x043f1f28

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

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

SO、もう一度、後者のオプションが正しいことを示します。

ただし、ドキュメントでは別の代替案が示されているようです。

HABCST_UG.pdf 30ページ:

前のセクションの例の SRK1_2_3_4_fuse.bin ファイルの内容は次のとおりです。

93ea61d0bd30ffb62aba0b9d5e144d082dd7faeb39223d9e3f9a22a06429895a

このハッシュ値は、次の順序で SoC eFUSE に書き込む必要があります。

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 (文書内のタイプミス、254 ではなく 224 である必要があります)

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-boot.csf.zip

元の添付ファイルは、 hab_types.h.zipに移動されました。

元の添付ファイルは、 hab.h.zipに移動されました。

元の添付ファイルは次の場所に移動されました: u-boot-spl.csf.zip

元の添付ファイルは次の場所に移動されました: mx28evk.c.zip

i.MX2x

Re: HAB i.MX28 Invalid Certificate

現在のバージョンの cst (4.0.1) は imx28 で動作しますか?そうでない場合は、cst2.0.0 へのダウンロードリンクを CAN 送信していただけますか?
-ヤリ

Re: HAB i.MX28 Invalid Certificate

こんにちは、

CST 2 リンクを記載したメールをお送りします。

お役に立てれば幸いです。

よろしくお願いいたします。

Yuri.

Re: HAB i.MX28 Invalid Certificate

こんにちは、パーさん。

CST 2.0.0 はどこからダウンロードできますか?

現在、フリースケールの Web サイトでは cst-2.3.2 となっています。

i.MX28 の eboot に署名したいです。

Re: HAB i.MX28 Invalid Certificate

現在、CST 2.0.0 と HAB の動作をテストすることができました。2.0.0 以降は i.MX28 では壊れており、本当に残念です。エンジニアがデバッグや動作しない理由の調査に何日も費やす必要がないように、リリースノートとマニュアルに、i.MX28 では動作しないという大きな警告を記載する必要があります。

SO私の問題を要約すると、他の人も私の経験から利益を得られるようになります。

問題1: CST 2.0.0を使用する

それ以降のバージョンでは、i.MX28 の HAB が壊れます。ソフトウェアパッケージ名は BLN_CST_MAIN_02.00.00 です。

問題2: CST 2.0.032ビットシステムでのみ動作します

CST 2.0.0 を動作させるために、ubuntu32 をインストールしました。Vagrant を使用して、VirtualBox で Ubuntu サーバーをすばやくセットアップしました。設定を含む VagrantFile が添付されています。

問題3: CST 2.0.0はエントロピージェネレータなしでは実行に20分かかる

CST エントロピー問題を解決するには、rngtools をインストールする必要がありました。

$ sudo apt-get rng-tools をインストール

問題4: u-boot-signed.sb がキー不足のため失敗する

これは私のミスでした。上記の投稿では、CSF1 証明書と IMG1 証明書のみを U-Boot ルートディレクトリにコピーしました。秘密鍵も必要です。

問題5: ヒューズの書き方

otp_burner.py は 64 ビットシステムでは壊れています。BitInit.exe は一部の Windows XP システムではCAN動作するようですが、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

これらの値は、MfgTool を使用して CAN 書き込むことができます。

OTPのSRKハッシュフィールドのワード0を書き込みます

または、U-Boot の fuse コマンドを使用します。

ヒューズプログラム 4 0 d7dd02f7 596a91bd b7fb2ec3 09525b17 6fe30579 0bb67f9e 7e53c7e4 44f06a93

fuse サポートをコンパイルするには、U-Boot の mx28evk.h に #define CONFIG_CMD_FUSE を追加します。

または、Freescale OTP パッケージの BitBurner.exe を使用して手動で書き込みます。実際に完璧に機能した唯一の OTP ツール。

問題6: 共有ドライブ

私は Virtual Box の共有ドライブ上に U-Boot を構築するという間違いを犯しました。大きな間違いです。速度が大幅に低下し、最後のステップでは、mkimage が u-boot-signed.sb をマップできないというメッセージが表示されて失敗します。共有ドライブでの作業を避けるだけで問題ありません。

結論：

これらの手順と上記の私の投稿を組み合わせると、HAB が iMX28 で動作するようになるはずです。少なくとも私にとっては、それはうまく機能しています。さらに、HAB を閉じて、署名されていないソフトウェアは実行されないことを確認しました。

最後に注意すべき点は、32 ビット Ubuntu サーバー上で U-Boot を構築するには、当然 32 ビットツールチェーンを入手する必要があるということです。U-Boot をビルドするには、libssl-dev とその他のパッケージもインストールする必要があります。しかし、ここまで来たら、U-Boot のコンパイルはそれほど心配する必要はないでしょう。

Re: HAB i.MX28 Invalid Certificate

信じてください、私はそれがどのように見えるかを知るための基準として、そこに説明されているツールを使用したかったのです。残念ながら、問題はそこから始まります。

otp_burner.py - 64 ビットシステムでは動作しません。仮想ボックスに 32 ビット Ubuntu サーバーをインストールし、そこで実行しました。このツールを使用すると、ヒューズをどのように設定すればよいかがよくわかります。

BitInit.exe - このツールは、Windows 7 64 ビットおよび Windows XP 32 ビットではクラッシュします。クラッシュし続けるため、参考として使用することはCAN。

BitBurner.exe - このツールでは、ヒューズを手動で書き込む必要があります。MFG ツールとほぼ同様に、このツールを使用するにはヒューズの値を知っておく必要があります。

これらのツールでは 100% 確実な答えが得られなかったため、ヒューズについて質問しました。私はそれがどのようになっているかについて 95% 確信していますが、ヒューズの書き込みは最終的なものなので、外部で検証したいと考えていました。提供していただいた CST 2.0.0 は 32 ビット Linux でしか動作しないため、現在 32 ビットツールチェーンを準備しています。このツールに感謝します。試してみたら、成功か失敗かをすぐに報告します。

しかし、これらのツールを使用するお客様や開発者は、4 GB 未満の RAM を搭載し、32 ビットシステムを使用することが想定されているのでしょうか?

Re: HAB i.MX28 Invalid Certificate

こんにちは、

セクション6（電気ヒューズの管理）に従うことをお勧めします。
アプリケーションノート AN4555 (i.MX28 HAB バージョン 4 を使用したセキュアブート)。

すてきな一日を、
ユリ

-----------------------------------------------------------------------------------------------------------------------
注: この投稿で質問が解決した場合は、「正解」ボタンをクリックしてください。ありがとう！
-----------------------------------------------------------------------------------------------------------------------