i.MX 93 セキュアブートハンズオン

i.MX 93 プロセッサで Advanced High Assurance Boot (AHAB) を使用したセキュア ブートを実装するための手顺を紹介します。


1.実践的な環境


ホストPC:

  • Yocto は、Linux PC および Windows PC に最適な環境 (WSL2、VMware、VirtualBox など) です。

    • OSはUbuntu 22.04です。

    • 続への接続にはネットワークを使用する必要があります。

    • ストレージ容量は約100GBです。(FRDM-IMX93 core-image-minimalの場合)

  • UUU、コンソールによる仕事はLinux PCでもWindows PCでも可能です。

    • UUUはLinux版、Windows版がそれぞれあります

    • シリーズコンソールは、Linux PCではscreenやminicomなどを、Windows PCではTeraTermやPuTTYなどを使うのが一般です。

ターゲット:


2.ホストPCのセットアップ(Linux)


ホストPCのOSはUbuntu 22.04です。システムを最新ステータス更新します。

$ sudo apt-get -y update
$ sudo apt-get -y upgrade

Yoctoでイメージをビルドするために必要なパッケージをインストールします。 imx-dockerのDockerfileをリファレンスしています。

$ sudo apt-get -y install gawk wget git-core diffstat unzip texinfo \
      gcc-multilib build-essential chrpath socat file cpio python3 \
      python3-pip python3-pexpect xz-utils debianutils iputils-ping \
      libsdl1.2-dev xterm tar locales net-tools rsync sudo vim curl zstd \
      liblz4-tool libssl-dev bc lzop libgnutls28-dev efitools git-lfs \
      bsdmainutils

今回の宿題は~/imx93-secure-boot上の、HOME宿題.ディレクトリの場所や名前は任意ですので、必要に応じて読んで代えてください。

$ mkdir ~/imx93-secure-boot
$ cd ~/imx93-secure-boot

ホスト PC の最終プログラムは、次のプログラムに基づいています。

imx93-secure-boot
├── IMX_CST_TOOL_NEW.tgz
├── cst-4.0.1
│   ├── ...
│   ├── keys
│   ├── crts
│   └── linux64
│       └── bin
├── backup-cst
└── yocto
    ├── ...
    ├── bin
    ├── build-imx93-11x11-lpddr4x-frdm
    │   ├── ...
    │   ├── conf
    │   └── tmp
    │       └── deploy
    │           └── images
    │               └── imx93-11x11-lpddr4x-frdm
    ├── downloads
    └── sources
        ├── ...
        ├── meta-imx
        ├── meta-imx-frdm
        └── meta-nxp-security-reference-design

 

3.コード署名ツールのダウンロード


コード署名ツール (以下、CST)、i.MX プロセッサの高保証ブート (HAB)、および高度な高保証ブート (AHAB) 機能は、i.MX プロセッサの署名および署名機能に基づいています。

NXP の Web ブラウザの最新バージョン。

最新バージョンをダウンロードすると、 IMX_CST_TOOL_NEW.tgzというファイルなので、最上位のディレクトリに保存してから、展開します。

$ cd ~/imx93-secure-boot
$ cp ~/Downloads/IMX_CST_TOOL_NEW.tgz .
$ tar xf IMX_CST_TOOL_NEW.tgz

拡張すると (2025/08 最新の最新バージョンです) cst-4.0.1というディレクトリに開発されます。バージョンが異なる場合は読み替えてください。


4. SRK生成¶


CSTはセキュアブートのためのSuper Root Key(以下SRK)を使用して生成を行います。詳細は以下をご参照ください。

  • UG10106、コード署名ツール ユーザーガイド、Rev. 4.0.1 — 2025年6月27日

    • cst-4.0.1/docs/UG10106_Rev4.0.1.pdfにあります。

ahab_pki_tree.shでSRKを生成します。オプションとして次の選択が行われます。

  • 既存の CA キーは「するか/n で選択します」を使用しています。

    • 使用する場合、CA キー名と CA 証明書名が使用されます。

  • SRK のキー タイプは rsa、rsa-pss、ecc から選択します。

    • rsa、rsa-pss、キーのビット长を2048、3072、4096から選択します。

    • eccの場合はキーが長く、p256、p384、p521とキーが選択されます。

  • ダイジェストアルゴリズムをsha256、sha384、sha512から選択します。

  • SRKの有効期間は年数によって決まります。

  • SRKをCA証明書は証明書によって生成され、証明書の証明書は証明書/nで選択します。

今回SRKで生成した設定は以下のとおりです。

  • 既存の CA ではない

  • キータイプ = ecc

  • キーの長さ = p384

  • ダイジェストアルゴリズム = sha384

  • 期間 = 10年

  • ユーザー証明書としての生成

ahab_pki_tree.shでインタラクティブにSRKの成を行う機会は、以下のような手顺になります。

$ cd ~/imx93-secure-boot
$ cd cst-4.0.1/keys
$ ./ahab_pki_tree.sh
...
Do you want to use an existing CA key (y/n)?: n
Do you want to use Elliptic Curve Cryptography (y/n)?: y
Enter length for elliptic curve to be used for PKI tree:
Possible values p256, p384, p521:  p384
Enter the digest algorithm to use: sha384
Enter PKI tree duration (years): 10
Do you want the SRK certificates to have the CA flag set? (y/n)?: n
...
$ cd -

その際の指定には ahab_pki_tree.sh のパラメータが使用され、次のようなものが便利です。

$ cd ~/imx93-secure-boot
$ cd cst-4.0.1/keys
$ ./ahab_pki_tree.sh -existing-ca n -kt ecc -kl p384 -da sha384 -duration 10 -srk-ca n
$ cd -

時間に、i.MX プロセッサーのヒューズに証明書のハッシュ値を、srktool で生成します。

$ cd cst-4.0.1/crts
$ ../linux64/bin/srktool -a -d sha256 -s sha384 -t SRK_1_2_3_4_table.bin \
-e SRK_1_2_3_4_fuse.bin -f 1 \
-c SRK1_sha384_secp384r1_v3_usr_crt.pem,SRK2_sha384_secp384r1_v3_usr_crt.pem,SRK3_sha384_secp384r1_v3_usr_crt.pem,SRK4_sha384_secp384r1_v3_usr_crt.pem

警告

-cオプションで指定する4つのファイル名は、コンマのみOKで、スペースなどの文が入らないようご注意ください。

正常に終了し、SRK_1_2_3_4_table.bin と SRK_1_2_3_4_fuse.bin が生成されます。この2つのファイルが正しく生成されます確認します。

SRK_1_2_3_4_table.bin の sha256 ダイジェストを意味します。

$ openssl dgst -binary -sha256 SRK_1_2_3_4_table.bin | hexdump -e '/4 "0x"' -e '/4 "%08x""\n"'

このダイジェストとSRK_1_2_3_4_fuse.binが同じ内容であることを確認します。

$ hexdump -e '/4 "0x"' -e '/4 "%08x""\n"' SRK_1_2_3_4_fuse.bin | tee srk_fuse.txt

じであれば、SRK_1_2_3_4_table.bin と SRK_1_2_3_4_fuse.bin が正しく生成されていると卡えられます。

i.MX 93のヒューズに书き込み値は証明書のハッシュ夤、ちなみにsrk_fuse.txtに书かれた内容になります。

ございます。元のファイルをu-boot_cmd_temp.txtというファイル名で制作します。これは、i.MX 93のヒューズ、Bank 16、Word 0-7に书き込み(プログラミング)を行うためのコマンドのテンプレートになります。

fuse prog -y 16 0
fuse prog -y 16 1
fuse prog -y 16 2
fuse prog -y 16 3
fuse prog -y 16 4
fuse prog -y 16 5
fuse prog -y 16 6
fuse prog -y 16 7

u-boot_cmd_temp.txtにヒューズが书かれたsrk_fuse.txtを右側に有料にして、u-boot_cmd.txtというファイルが生成されます。

$ paste -d" " u-boot_cmd_temp.txt srk_fuse.txt | tee u-boot_cmd.txt

以下の形式のu-boot_cmd.txtが生成されます。本文が完成したら、本文を参照してください。

fuse prog -y 16 0 
fuse prog -y 16 1 
fuse prog -y 16 2 
fuse prog -y 16 3 
fuse prog -y 16 4 
fuse prog -y 16 5 
fuse prog -y 16 6 
fuse prog -y 16 7 

今回は、Yocto のセキュアブートが自動生成されます。そのプロセスでnxp-cst-signerというツールが実行されます。 nxp-cst-signerはCSTディレクトリの正下にある設定ファイル(csf_ahab.cfg)を参照するルールになっているため、~/imx93-secure-boot/cst-4.0.1/csf_ahab.cfgします。

$ cd ~/imx93-secure-boot
$ cd cst-4.0.1
$ edit csf_ahab.cfg

以下の設定を行い、以下の説明を保存します。

#Header
header_version=1.0
#Install SRK
srktable_file=SRK_1_2_3_4_table.bin
srk_source=SRK1_sha384_secp384r1_v3_usr_crt.pem
srk_source_index=0
srk_source_set=OEM
srk_revocations=0x0
#Install Certificate
sgk_file=
sgk_permissions=

CSTの設定が完了しました。

このCSTディレクトリは、ヒューズを书きつけたi.MX 93デバイスのソフトウェアに署名する際になりますので、入手して安全な場所に長期間保管する必要があります。

$ cd ~/imx93-secure-boot
$ mkdir backup-cst
$ tar cf backup-cst/cst-4.0.1_$(date +"%Y%m%d-%H%M%S").tar.gz cst-4.0.1/

 

5. gitのセットアップ


Yoctoのビルドを行う记に、gitのユーザー名とメールアドレスを登录していないとエラーになる機会がありますので、していない機会は登録します。

$ git config --global user.name "Your Name"
$ git config --global user.email "[email protected]"

 

6. i.MX Linux BSPのダウンロード


Yocto ビルドはのディレクトリを使用して「します」を作成します。

$ cd ~/imx93-secure-boot
$ mkdir yocto
$ cd yocto

リポツールをダウンロードします。

$ mkdir bin
$ curl http://commondatastorage.googleapis.com/git-repo-downloads/repo > bin/repo

リポジトリに実行権を支払って、PATH を守ることで使用できるようになります。

$ chmod a+x bin/repo
$ PATH=${PATH}:$(pwd)/bin

repoでi.MX Linux BSP 6.6.36-2.1.0のレシピをダウンロードするための初期化を行います。

$ repo init -u https://github.com/nxp-imx/imx-manifest -b imx-linux-scarthgap -m imx-6.6.36-2.1.0.xml

リポでi.MX Linux BSP 6.6.36-2.1.0のレシピをダウンロードします。

$ repo sync

 

7.meta -imx-frdmのダウンロード


FRDM-IMX93 は追加のメタレイヤーを使用します。

$ cd sources
$ git clone https://github.com/nxp-imx-support/meta-imx-frdm -b imx-frdm-4.0
$ cd ..

 

8.meta -nxp-security-reference-designのダウンロード


Yoctoによるセキュアブートの自動ビルドを行うための追加メタレイヤーをダウンロードします。 このレイヤには i.MX Linux BSP 6.6.36-2.1.0 は「存在しませんが」を使用し、近似のscarthgap-6.6.23-2.0.0ブランチを「します」を使用します。

$ cd sources
$ git clone https://github.com/nxp-imx-support/meta-nxp-security-reference-design -b scarthgap-6.6.23-2.0.0
$ cd ..

このレイヤーをFRDM-IMX93に適用すると、署名を行った時にi.MX 93 EVKのdtbが使われてしまう無合があるため修正をしてください。 (このコントリビューションリファレンスにしています。 < https://github.com/nxp-imx-support/meta-nxp-security-reference-design/pull/2 > )

diff --git a/meta-secure-boot/recipes-secure-boot/imx-mkimage/imx-boot_%.bbappend b/meta-secure-boot/recipes-secure-boot/imx-mkimage/imx-boot_%.bbappend
index 1bbc7b2..6a2f069 100644
--- a/meta-secure-boot/recipes-secure-boot/imx-mkimage/imx-boot_%.bbappend
+++ b/meta-secure-boot/recipes-secure-boot/imx-mkimage/imx-boot_%.bbappend
@@ -15,7 +15,7 @@ do_compile:append:ahab() {
     mv ${BOOT_STAGING}/flash.bin ${BOOT_STAGING}/flash.bak

     # Invoke mkimage again to Get container info
-    make SOC=${IMX_BOOT_SOC_TARGET} flash_kernel
+    make SOC=${IMX_BOOT_SOC_TARGET} ${MKIMAGE_EXTRA_ARGS} flash_kernel

     # Rename kernel image name and move back the imx-boot flash image name
     mv ${BOOT_STAGING}/flash.bin ${BOOT_STAGING}/flash_os.bin

 

9.ビルド環境のセットアップ


Yocto ビルドのプロジェクトのセットアップを行います。 FRDM-IMX93は以下のような場合に適しています。

$ MACHINE=imx93-11x11-lpddr4x-frdm DISTRO=fsl-imx-xwayland EULA=1 source sources/meta-imx-frdm/tools/imx-frdm-setup.sh -b build-imx93-11x11-lpddr4x-frdm

コマンドが正常終了すると、build-imx93-11x11-lpddr4x-frdmディレクトリにモバイルしています。

のコマンドで、 meta-nxp-security-reference-design/meta-secure-bootをレイヤーとして追加します。これは自動にセキュアブートの署名を行うために必要です。

$ bitbake-layers add-layer ../sources/meta-nxp-security-reference-design/meta-secure-boot

ここでプロジェクトの設定(local.conf).エディタでlocal.confを开きますに「を行います」を追加しました。

$ edit conf/local.conf

local.conf の最後に最初の行を追加します。これにより、ramboot するための rootfs が追加で生成されます。

IMAGE_FSTYPES:append = " cpio.gz.u-boot"

local.conf の最後に最初の行を追加します。 CST_PATH 値は CST_PATH によって設定されます。 これは、meta-nxp-security-reference-designがCSTディレクトリを参照するために必須です。

CST_PATH = 

local.conf の最後に最初の行を追加します。 これは、meta-nxp-security-reference-designがFRDM-IMX93のカーネルとdtbに署名を支払う時にi.MX 93 EVKのdtbを组み込んでしまうので質問を回避するためです。

MKIMAGE_EXTRA_ARGS:imx93-11x11-lpddr4x-frdm = "KERNEL_DTB=imx93-11x11-frdm.dtb"

エディタを終了してlocal.confを保存します。

 

10.イメージのビルド


今回はサイズを小さくして、かつ、セキュア ブートの署名を自動に行いますcore-image-minimal-secure-bootをbitbakeします。時間が経って処理が終わりました。

$ bitbake core-image-minimal-secure-boot -k

イメージのビルドが正常に終了すると、次の2つのファイルが生成されます。 1つ目は署名paykibootloaderで、2つ目はlinuxカーネルとdtbが組み合わせられた署名paykiOSコンテナです。

$ stat tmp/deploy/images/imx93-11x11-lpddr4x-frdm/signed-imx-boot-imx93-11x11-lpddr4x-frdm-sd.bin-flash_singleboot
$ stat tmp/deploy/images/imx93-11x11-lpddr4x-frdm/os_cntr_signed.bin

Signed to pay kiBootloader と Signed to pay OS コンテナをグループみき投げイメージファイルも生成されています。

$ stat tmp/deploy/images/imx93-11x11-lpddr4x-frdm/core-image-minimal-secure-boot-imx93-11x11-lpddr4x-frdm.rootfs.wic.zst

Linux でシリアル ダウンロードを開始すると、RAM ディスクを使用してシリアル ダウンロードが生成されます。このファイルはその後ですによって署名されています。 ( RAMディスクによる署名)

$ stat tmp/deploy/images/imx93-11x11-lpddr4x-frdm/core-image-minimal-secure-boot-imx93-11x11-lpddr4x-frdm.rootfs.cpio.gz.u-boot

 

11. bitbakeから开开开到了したい機会


Bitbake は途中で中断され、シェルは時々再起動され、必要に応じて Yocto 環境値が設定されます。そのためには、次のスクリプトを使用します。

$ cd ~/imx93-secure-boot
$ cd yocto
$ source setup-environment build-imx93-11x11-lpddr4x-frdm

 

12.をやりたいの署名付き


SRKしたときなど、署名をやりたい機会は、 imx-bootimx-boot-signaturelinux-imx-signatureとイメージ(この章core-image-minimal-secure-boot ) の 4 つのパッケージをクリーンオールして、イメージを Zai ビルドします。

$ bitbake imx-boot imx-boot-signature linux-imx-signature core-image-minimal-secure-boot -c cleanall
$ bitbake core-image-minimal-secure-boot -k

 

13. RAMディスクの署名¶


イメージのビルドが正常に終了したら、deploy ディレクトリに 2 つのツールが存在します。 mkimage_imx8 はコンテナを作るツールですによって起動されます。 cst_signerはコンテナに署名を行うツールです。

$ stat tmp/deploy/images/imx93-11x11-lpddr4x-frdm/imx-boot-tools/mkimage_imx8
$ stat tmp/deploy/images/imx93-11x11-lpddr4x-frdm/imx-boot-tools/cst_signer

また、deployディレクトリにramdiskファイルも存在します。

$ stat tmp/deploy/images/imx93-11x11-lpddr4x-frdm/core-image-minimal-secure-boot-imx93-11x11-lpddr4x-frdm.rootfs.cpio.gz.u-boot

mkimage_imx8とcst_signerを使って、ramdiskファイルに署名をします。

本来はmkimage_imx8でramdiskをコンテナにします。コマンドの形式は以下のとおりです。

$ INITRD=
$ INITRD_ADDR=
$ mkimage_imx8 -soc IMX9 -container -data ${INITRD} a55 ${INITRD_ADDR} -out 

具体的なものは以下のとおりです。

$ tmp/deploy/images/imx93-11x11-lpddr4x-frdm/imx-boot-tools/mkimage_imx8 \
-soc IMX9 \
-container \
-data tmp/deploy/images/imx93-11x11-lpddr4x-frdm/core-image-minimal-secure-boot-imx93-11x11-lpddr4x-frdm.rootfs.cpio.gz.u-boot \
      a55 \
      0x83800000 \
-out initrd_cntr.bin

時間にcst_signerでコンテナに署名します。コマンドの形式は以下のとおりです。

$ CST_PATH= cst_signer -d -i  -c /csf_ahab.cfg

具体的なものは以下のとおりです。

$ CST_PATH=/home/nxp/imx93-secure-boot/cst-4.0.1 \
tmp/deploy/images/imx93-11x11-lpddr4x-frdm/imx-boot-tools/cst_signer \
-d \
-i initrd_cntr.bin \
-c /home/nxp/imx93-secure-boot/cst-4.0.1/csf_ahab.cfg

署名したramdiskはdeployディレクトリに手机お待ちしています。

$ mv signed-initrd_cntr.bin tmp/deploy/images/imx93-11x11-lpddr4x-frdm/

これでセキュアブートを行う環境がビルドできました。

 

14.ホストPCとターゲットの回線


ホスト PC とターゲットには 2 本の USB ケーブルが接続されています。

Keita_Nagashima_0-1766478908473.png

1 ホストPCの配線¶

 

15. UUUのインストール(Linux)


Linux 版 UUU は次のサイトからuuuをダウンロードして、 /usr/local/binなどのPATH を通った場所に設定します。

次のコマンドで、sudoなしでuuuを実行できるようにSETファイルをインストールします。

$ sudo sh -c "uuu -udev > /etc/udev/rules.d/70-uuu.rules"
$ sudo udevadm control --reload

ホストPCとFRDM-IMX93のUSB1ポートをUSB接続して、FRDM-IMX93をシリアルダウンロードモードに設定して電源をONにすると、 以下はFRDM-IMX93の情報の確認です。

$ uuu -lsusb
uuu (Universal Update Utility) for nxp imx chips -- libuuu_1.5.201-11-gf2a4e3e

Connected Known USB Devices
        Path      Chip    Pro     Vid     Pid     BcdVersion      Serial_no
        ====================================================================
        3:1224    MX93    SDPS:   0x1FC9  0x014E   0x0001      3A24F36BB35F4594

 

16. UUUのインストール(Windows)


UUU の Windows バージョンは次のuuu.exe構成されています。

ホストPCとFRDM-IMX93のUSB1ポートをUSB接続して、FRDM-IMX93をシリアルダウンロードモードに設定して電源をONにすると、 以下はFRDM-IMX93の情報の確認です。

> uuu -lsusb
uuu (Universal Update Utility) for nxp imx chips -- libuuu_1.5.201-11-gf2a4e3e

Connected Known USB Devices
        Path      Chip    Pro     Vid     Pid     BcdVersion      Serial_no
        ====================================================================
        3:1224    MX93    SDPS:   0x1FC9  0x014E   0x0001      3A24F36BB35F4594

 

17.コンソール(Linux)


ホスト PC でコンソールを开きます。たとえば、 minicomでFRDM-IMX93のシリアルポートを開く」は次の条件を満たします。

$ minicom -D/dev/ttyACM0

 

18.コンソール(Windows)


Windows のシリアルコンソールのアプリケーションで、FRDM-IMX93 の場合は COM ポートUSB-Enhanced-SERIAL-A CH342を使います。

i.MX 93 EVK の 4 番目のバージョン、EVK の 4 番目のバージョン、および COM のバージョンの 3 番目のバージョン。

 

19. Linux 起動テスト(1)


ブートローダーとLinuxを起動して、AHABのエラーを確認します。 BOOT_MODEによって方法が異なりますので、いずれかを選択してテストします。

 

19.1.シリアルダウンロードとLinuxの起動¶

シリアルダウンロードでブートローダーとLinuxのスタートアップテストを行います。

3番目の「つのファイル」は「します」を使用します。

  • キブートローダーファイルによる署名 signed-imx-boot-imx93-11x11-lpddr4x-frdm-sd.bin-flash_singleboot

  • Linuxカーネル os_cntr_signed.bin

  • きのramdiskファイルの署名付き signed-initrd_cntr.bin

3つのファイルが以下のパスに存在することを確認します。

$ cd ~/imx93-secure-boot
$ cd yocto/build-imx93-11x11-lpddr4x-frdm/tmp/deploy/images/imx93-11x11-lpddr4x-frdm
$ stat signed-imx-boot-imx93-11x11-lpddr4x-frdm-sd.bin-flash_singleboot
$ stat os_cntr_signed.bin
$ stat signed-initrd_cntr.bin
$ cd -

UUUで実行するスクリプトファイルsdp-ramboot-yocto-signed.uuuを成します。

$ cd ~/imx93-secure-boot
$ edit sdp-ramboot-yocto-signed.uuu

以下の内容を記述して保存します。

uuu_version 1.2.39
SDPS: boot -f yocto/build-imx93-11x11-lpddr4x-frdm/tmp/deploy/images/imx93-11x11-lpddr4x-frdm/signed-imx-boot-imx93-11x11-lpddr4x-frdm-sd.bin-flash_singleboot
FB: ucmd ahab_status
FB: ucmd setenv ramargs 'setenv bootargs ${jh_clk} console=${console} root=/dev/ram rw'
FB: ucmd setenv ramboot 'echo Booting from initramfs ...; run ramargs; booti ${loadaddr} ${initrd_addr} ${fdt_addr};'
FB: ucmd setenv fastboot_buffer ${cntr_addr}
FB: download -f yocto/build-imx93-11x11-lpddr4x-frdm/tmp/deploy/images/imx93-11x11-lpddr4x-frdm/os_cntr_signed.bin
FB: ucmd auth_cntr ${cntr_addr}
FB: ucmd ahab_status
FB: ucmd setenv fastboot_buffer ${cntr_addr}
FB: download -f yocto/build-imx93-11x11-lpddr4x-frdm/tmp/deploy/images/imx93-11x11-lpddr4x-frdm/signed-initrd_cntr.bin
FB: ucmd auth_cntr ${cntr_addr}
FB: ucmd ahab_status
FB: acmd run ramboot
FB: done

UUUでスクリプトを実行します。

$ uuu -d -v sdp-ramboot-yocto-signed.uuu

FRDM-IMX93をシリアルダウンロードモードにSETUPして電源をONにすると、ブートローダーからLinuxが起動します。 AHAB のエラーは、Linux が起動する直接フロントに実行しましたahab_statusコマンドの結果で判断します。

Authenticate OS container at 0x98000000
...
Lifecycle: 0x00000008, OEM Open


        0x0287fad6
        IPC = MU APD (0x2)
        CMD = ELE_OEM_CNTN_AUTH_REQ (0x87)
        IND = ELE_BAD_KEY_HASH_FAILURE_IND (0xFA)
        STA = ELE_SUCCESS_IND (0xD6)

        0x0287fad6
        IPC = MU APD (0x2)
        CMD = ELE_OEM_CNTN_AUTH_REQ (0x87)
        IND = ELE_BAD_KEY_HASH_FAILURE_IND (0xFA)
        STA = ELE_SUCCESS_IND (0xD6)

        0x0287fad6
        IPC = MU APD (0x2)
        CMD = ELE_OEM_CNTN_AUTH_REQ (0x87)
        IND = ELE_BAD_KEY_HASH_FAILURE_IND (0xFA)
        STA = ELE_SUCCESS_IND (0xD6)

        0x0287fad6
        IPC = MU APD (0x2)
        CMD = ELE_OEM_CNTN_AUTH_REQ (0x87)
        IND = ELE_BAD_KEY_HASH_FAILURE_IND (0xFA)
        STA = ELE_SUCCESS_IND (0xD6)

Detect USB boot. Will enter fastboot mode!
Booting from initramfs ...
## Loading init Ramdisk from Legacy Image at 83800000 ...
   Image Name:   core-image-minimal-secure-boot-i
   Created:      2011-04-05  23:00:00 UTC
   Image Type:   AArch64 Linux RAMDisk Image (uncompressed)
   Data Size:    56894907 Bytes = 54.3 MiB
   Load Address: 00000000
   Entry Point:  00000000
   Verifying Checksum ... OK
## Flattened Device Tree blob at 83000000
   Booting using the fdt blob at 0x83000000
Working FDT set to 83000000
   Using Device Tree in place at 0000000083000000, end 000000008300eaef
Working FDT set to 83000000
fail to find output device
probe video device failed, ret -19

Starting kernel ...

[    0.000000] Booting Linux on physical CPU 0x0000000000 [0x412fd050]
[    0.000000] Linux version 6.6.36-lts-next-g20aa8fc92c79 (oe-user@oe-host) (aarch64-poky-linux-gcc (GCC) 13.3.0, GNU ld 4
[    0.000000] KASLR disabled due to lack of seed
[    0.000000] Machine model: NXP i.MX93 11X11 FRDM board
...

Linux が起動するまでに、u-boot-spl、u-boot、kernel+dtb、ramdisk の 4 回の認証が行われますが、まだ SRK Hash がヒューズに书かれていないステータスでは、4 回の認証エラーELE_BAD_KEY_HASH_FAILURE_IND (0xFA)が発生したことがあります。

エラーELE_NO_AUTHENTICATION_FAILURE_IND (0xEE)が出る場合は、「イメージに署名が無いので認証できなかった」という意味で、署名はきイメージのビルドが正しくできていない可能性があります。

Lifecycle: 0x00000008, OEM Open


        0x0287eed6
        IPC = MU APD (0x2)
        CMD = ELE_OEM_CNTN_AUTH_REQ (0x87)
        IND = ELE_NO_AUTHENTICATION_FAILURE_IND (0xEE)
        STA = ELE_SUCCESS_IND (0xD6)

SRK ハッシュがヒューズに书かれて認定が正しく行われれば、AHAB のエラーがなくなり、次のようにNo Events Found!という意味になります。

Lifecycle: 0x00000008, OEM Open


        No Events Found!

 

19.2.SDまたはeMMCでLinux起動

FRDM-IMX93のBOOT_MODEスイッチをシリアルダウンロードモードに設定して電源をONにします。 SDブートの機会は书き込み可能なmicroSDカードをカードスロットに挿入してから、のコマンドでSDにイメージを书き込みます。

リスト 1 SD にき込み
$ cd ~/imx93-secure-boot
$ cd yocto/build-imx93-11x11-lpddr4x-frdm/tmp/deploy/images/imx93-11x11-lpddr4x-frdm/
$ uuu -b sd_all signed-imx-boot-imx93-11x11-lpddr4x-frdm-sd.bin-flash_singleboot core-image-minimal-secure-boot-imx93-11x11-lpddr4x-frdm.rootfs.wic.zst
$ cd -

eMMC ブートの際は、次のコマンドで eMMC にイメージを书き込みます。

リスト 2 eMMC への組み込み
$ cd ~/imx93-secure-boot
$ cd yocto/build-imx93-11x11-lpddr4x-frdm/tmp/deploy/images/imx93-11x11-lpddr4x-frdm/
$ uuu -b emmc_all signed-imx-boot-imx93-11x11-lpddr4x-frdm-sd.bin-flash_singleboot core-image-minimal-secure-boot-imx93-11x11-lpddr4x-frdm.rootfs.wic.zst
$ cd -

本が読み終わり、FRDM-IMX93の電源がOFFになります。 FRDM-IMX93のBOOT_MODEスイッチを、SDブートモードまたはeMMCブートモードに設定して電源をONにします。

U-Bootの「起動」は「起動」を意味し、「起動」は「一時停止」を意味します。以下のコマンドを入力して、署名payKOSイメージ(kernel + dtb)を認証します。

リスト 3Signature payKIOS イメージの証明
u-boot=> mmc dev ${mmcdev}
u-boot=> mmc rescan
u-boot=> run loadcntr
u-boot=> run mmcargs
u-boot=> run auth_os

ahab_status コマンドを入力してAHABのエラーを確認します。

リスト 4 署名および認定されたエラー
u-boot=> ahab_status
Lifecycle: 0x00000008, OEM Open


        0x0287fad6
        IPC = MU APD (0x2)
        CMD = ELE_OEM_CNTN_AUTH_REQ (0x87)
        IND = ELE_BAD_KEY_HASH_FAILURE_IND (0xFA)
        STA = ELE_SUCCESS_IND (0xD6)

        0x0287fad6
        IPC = MU APD (0x2)
        CMD = ELE_OEM_CNTN_AUTH_REQ (0x87)
        IND = ELE_BAD_KEY_HASH_FAILURE_IND (0xFA)
        STA = ELE_SUCCESS_IND (0xD6)

        0x0287fad6
        IPC = MU APD (0x2)
        CMD = ELE_OEM_CNTN_AUTH_REQ (0x87)
        IND = ELE_BAD_KEY_HASH_FAILURE_IND (0xFA)
        STA = ELE_SUCCESS_IND (0xD6)

Linux するまでに、u-boot-spl、u-boot、kernel+dtb の 3 期の認証が行われますが、先に SRK ハッシュがヒューズに书かれていないステータスでは、3 回の認証エラーELE_BAD_KEY_HASH_FAILURE_IND (0xFA)が発生したことがあります。

エラーELE_NO_AUTHENTICATION_FAILURE_IND (0xEE)が出る場合は、「イメージに署名が無いので認証できなかった」という意味で、署名はきイメージのビルドが正しくできていない可能性があります。

リスト 5署名なしイメージの機会
Lifecycle: 0x00000008, OEM Open


        0x0287eed6
        IPC = MU APD (0x2)
        CMD = ELE_OEM_CNTN_AUTH_REQ (0x87)
        IND = ELE_NO_AUTHENTICATION_FAILURE_IND (0xEE)
        STA = ELE_SUCCESS_IND (0xD6)

SRK ハッシュがヒューズに书かれて認定が正しく行われれば、AHAB のエラーがなくなり、次のようにNo Events Found!という意味になります。

リスト 6 AHABエラー無しの場合¶
Lifecycle: 0x00000008, OEM Open


        No Events Found!

最後に、次のコマンドを実行して、Linux のログインプロンプトまで開始することを確認します。

リスト7 Linuxの起動¶
u-boot=> run boot_os

 

20. SRKハッシュをヒューズに书き込み


i.MX 93のヒューズバンク16、Word 0-7の値が0x00000000であることを確認します。

u-boot=> fuse read 16 0
u-boot=> fuse read 16 1
u-boot=> fuse read 16 2
u-boot=> fuse read 16 3
u-boot=> fuse read 16 4
u-boot=> fuse read 16 5
u-boot=> fuse read 16 6
u-boot=> fuse read 16 7

SRKの制作u-boot_cmd.txtが確認されました。 (ここでは実记の値ではなく ~ という面记をしています。)

$ cd ~/imx93-secure-boot
$ cat cst-4.0.1/crts/u-boot_cmd.txt
fuse prog -y 16 0 
fuse prog -y 16 1 
fuse prog -y 16 2 
fuse prog -y 16 3 
fuse prog -y 16 4 
fuse prog -y 16 5 
fuse prog -y 16 6 
fuse prog -y 16 7 

u-boot_cmd.txt 通りに、u-bootのプロンプトからSRKハッシュをヒューズに书き込みます。 (ここでは実记の値ではなく ~ という面记をしています。)

警告

ヒューの书き込みは一度きりであり、元に戻すことはできません。しっかり確認して丁寧に作業をすることが大切です。

u-boot=> fuse prog -y 16 0 
u-boot=> fuse prog -y 16 1 
u-boot=> fuse prog -y 16 2 
u-boot=> fuse prog -y 16 3 
u-boot=> fuse prog -y 16 4 
u-boot=> fuse prog -y 16 5 
u-boot=> fuse prog -y 16 6 
u-boot=> fuse prog -y 16 7 

 

21. Linux 起動テスト(2)


ブートローダーとLinuxを起動して、AHABのエラーを確認します。 Linux起動プログラム(1)と同様の方法です。

ahab_statusハッシュ hash はされるNo Events Found!です。これは署名が支払います きイメージがすべて認証されたことを意味します。

Lifecycle: 0x00000008, OEM Open


        No Events Found!

 

22. OEM のクローズと移行¶


i.MX 93デバイスのライフサイクルがOEMクローズすることで、署名された支払いきイメージのみstartできるようになり、署名のいイメージや、間違った署名きイメージはstartできなくなります。

きイメージで開始してahab_statusコマンドでAHABエラーが無いことを確認しました。

u-boot=> ahab_status
Lifecycle: 0x00000008, OEM Open


        No Events Found!

ahab_close コマンドを実行すると、OEM Closedに再配置されます。

警告

OEM Closedへの移行は一度であり、OEM OpenのSTATEに戻すことはできません。しっかり確認して丁寧に作業をすることが大切です。

u-boot=> ahab_close
Warning: Please ensure your sample is in NXP closed state, OEM SRK hash has been fused,
         and you are able to boot a signed image successfully without any SECO events reported.
         If not, your sample will be unrecoverable.

Really perform this operation? 
y
Change to OEM closed successfully
u-boot=>

リセットを行うと、からOEMクローズとなります。サイン入りきイメージであれば再起動します。

u-boot=> reset
resetting ...

U-Boot SPL 2024.04+gde16f4f1722+p0 (Sep 02 2024 - 10:44:35 +0000)
SOC: 0xa1009300
...

ahab_status コマンドを実行すると、OEM Closedに再配置されていることがわかります。

u-boot=> ahab_status
Lifecycle: 0x00000020, OEM closed


        No Events Found!
u-boot=>

 

23. Linux 起動テスト(3)


ブートローダーとLinuxを起動できることを確認します。 Linux起動プログラム(1)と同様の方法です。

Linux が正常に起動し、セキュア ブートも成功しました。

 

24.参考文献



  • この情報は、NXP 製品で使用するための参考資料です。

  • 正式な様は製品マニュアル・アプリケーションノートを指します。

  • ソフトウェアのバージョンなど、さまざまな条件や条件の違い、その時々の状況に応じた内容や動作の説明を記載しています。

  • 使用目的に適合した機能試験証明書であり、使用目的に適合していることを証明します。


=========================

この投稿の 「 コメント 」欄は 投稿者によって書かれており、返信レターも投稿者によって書かれるようになりました 。
おロット番号を電話しますが、お質問い合わせの间には「 NXP への技術的な質問 - い合わせ方法( 日本語ブログ) 」をご参照ください
(弊社は NXP 社の代理店であり、 NXP社 のNXPディーラー であり、NXP社の取締役であり、質問の直接の担当者はNXP社です。 )