セキュアブート

目次

5.1. セキュアブートとチェーンオブトラスト
5.2. HAB とは
5.3. 署名環境を構築する
5.3.1. 署名環境について
5.3.2. ATDE を準備する
5.3.3. 署名ツール (CST) を準備する
5.3.4. アップデートファイル作成ツール (mkswu) を準備する
5.3.5. Armadillo Base OS イメージの取得
5.3.6. 署名環境のディレクトリツリー構成
5.3.7. 署名鍵を生成する
5.4. セキュアブート機能の選択
5.5. セキュアブートのセットアップ
5.5.1. uboot-imx のセキュアブートの実装仕様
5.5.2. セットアップの流れ
5.5.3. 署名済みブートローダーの作成
5.5.4. 署名済み Linux カーネルイメージの作成
5.5.5. ルートファイルシステムのビルド
5.5.6. セキュアブートセットアップ用 SD boot ディスクの作成
5.6. 暗号化セキュアブートのセットアップ
5.6.1. uboot-imx の暗号化セキュアブートの実装仕様
5.6.2. セットアップの流れ
5.6.3. 署名済みの暗号化ブートローダーの作成
5.6.4. 暗号化 Linux カーネルイメージの生成
5.6.5. 暗号化セキュアブート対応 swu の作成
5.6.6. ルートファイルシステムのビルド
5.6.7. セキュアブートセットアップ用 SD boot ディスクの作成
5.7. ストレージの暗号化のセットアップ
5.7.1. 実装仕様の概要
5.7.2. セットアップの流れ
5.7.3. 署名済みブートローダーの作成
5.7.4. 署名済み Linux カーネルイメージの作成
5.7.5. セキュアブート対応 swu の作成
5.7.6. ルートファイルシステムのビルド
5.7.7. セキュアブートセットアップ用 SD boot ディスクの作成
5.8. Armadillo-IoT ゲートウェイ G4 上の作業
5.8.1. Armadillo-IoT ゲートウェイ G4 の準備
5.8.2. SRK ハッシュの書き込み
5.8.3. close 処理
5.8.4. ファームウェアの書き込みをはじめる
5.8.5. 作業が中断した場合
5.9. 動作確認
5.9.1. ストレージ暗号化の確認
5.9.2. セキュアブートの確認
5.10. セットアップ完了後のアップデートの運用について
5.11. 補足情報
5.11.1. secureboot.conf の設定方法
5.11.2. 署名済みイメージと展開先
5.11.3. セキュアブートのフロー
5.11.4. ビルドのプロセスフロー
5.11.5. ファームウェアアップデートのフロー
5.11.6. SRK の無効化と切り替え

この章ではセキュアブートを有効にする方法について説明します。 また、セキュアブートをベースにしたいくつかの技術についても紹介します。

5.1. セキュアブートとチェーンオブトラスト

組み込みデバイスへの攻撃は様々な方向から行われます。ある方向のセキュリティ対策が強固な場合、攻撃者は回避可能な別の方向がないのか模索します。攻撃者のコードを何らかの方法でデバイスに組み込んで対策を回避するのが、単純ですが有効な方法でしょう。IoT デバイスはネットワーク上のサービスとデータのやり取りを行います。通信路の暗号化、サーバーとデバイスの相互認証などの対策を講じたとしても、IoT デバイス上にあるソフトウェアに攻撃者のコードを組み込むことで対策を回避してシステムに侵入される可能性があるのです。

セキュアブートは、起動ソフトウェアのディジタル署名を用いて正規ソフトウェアであることを確認してから起動する処理のことです。攻撃者によって作られた不正なコードを実行前に検出することができます。セキュアブートはチェーンオブトラスト (chain of trust) と表裏一体に実装されます。チェーンオブトラストとは、その名の通り、信頼を繋いでいく形態のことを指します。ルートオブトラストと呼ばれる基礎となる情報から枝葉のように繋がれた情報を認証していくことで、繋がれた個々のコンポーネントだけでなくシステムを信頼できるものにしてくれます。セキュアブートは、起動時にソフトウェアを順番に認証することで信頼を次に繋いでいるのです。セキュアブートの範囲をどこまでにするかによりますが、起動時に認証されたソフトウェアで別の情報を認証すれば、チェーンオブトラストを繋げていくことができます。また、IoT デバイスとクラウドサービスから構成されるような広範囲に及ぶシステムは特に信頼が必要になります。信頼できるセキュリティ基盤を構築するためには、構成するソフトウェアが正規のリリース物であることを確認することが重要になります。チェーンオブトラストを採用することでより信頼できる IoT システムとなり得るのです。

./images/chain_of_trust.png

図5.1 チェーンオブトラスト


では、どういったケースでセキュアブートを採用するべきでしょうか。セキュアブートはセキュアな組み込みデバイスを実現する上で最初のステップにするべき技術です。しかし、導入するのであればコスト面にも配慮することが必要でしょう。まず、製造時の追加コストが必要です。鍵等を書き込む工程が必要になります。ただ書き込めばよいわけではなく、漏洩があってはいけないので物理的な隔離などセキュアに書き込む必要があります。メンテナンスにも追加のコストが必要です。ソフトウェアのリリース時にはソフトウェアの署名が必要になります。こちらも、物理的な隔離などの漏洩、汚染対策が必要になります。また、どこまでやるかによりますが、定期的な鍵の更新、インシデントや製品寿命による鍵のリボーケーションなどのメンテナンスコストが必要になってきます。費用対効果を検討してからの導入をお勧めします。

5.2. HAB とは

HAB (High Assurance Booting) は、NXP が提供するセキュアブートの実装です。i.MX 8M Plus の BootROM には HABv4 が組み込まれます。デフォルトでは無効な状態になっていますが、一度、eFuse に情報を書き込むことでセキュアブートが有効になり、それ以降、有効な状態のまま変更不可能になります。HABv4 で規定する仕様では次の情報をブートローダーイメージに追加することで BootROM が起動時にブートローダーの認証を行います。

  • CSF (Command Sequence File)、IVT (Image Vector Table)
  • SRK (Super Root Key)、CSF、IMG 署名確認鍵
  • イメージの署名

NXP は署名ツールとして CST (Code Signing Tool) をリリースしています。本来、署名範囲などは環境によって様々な実装がなされるべきなので署名ツール自体にはその辺りの仕様が含まれません。ブートローダーの実装仕様に依存します。Armadillo Base OS で採用される uboot-imx のセキュアブート処理では、Trusted Firmware-A (ATF)、OP-TEE OS、Linux カーネルイメージまでが認証の対象になります。署名に関する概要は以下のとおりです。

  • 署名確認用の鍵は X.509 証明書に対応する
  • 署名は RSA/ECC に対応する

    • RSA 1024, 2048, 3072, 4096 bits
    • ECC NIST P-256, NIST P-384, NIST P-521
  • 署名のダイジェストは SHA256 のみ
[注記]

HAB の詳しい仕様は以下を参照してください。

5.3. 署名環境を構築する

まず、セキュアブートをセットアップするために必要な環境を構築していきます。

5.3.1. 署名環境について

ここで利用する署名環境の構成は以下のとおりです。

表5.1 署名環境

ツール/パッケージ説明

ATDE(Atmark Techno Development Environment)

提供元 : アットマークテクノ

Armadillo シリーズの開発環境として VMware イメージとして配布されます

CST(Code Signing Tool)

提供元 : NXP

HAB の署名を行うツールや鍵を生成するツールを含みます

mkswu パッケージ

提供元 : アットマークテクノ

Armadillo Base OS のファームウェアアップデートの仕組みである SWUpdate 用のアップデートファイルを生成するツールを含みます

build-rootfs-[VERSION].tar.gz

提供元 : アットマークテクノ

Armadillo Base OS のルートファイルシステムを生成するツールを含みます

Alpine Linux をベースにアットマークテクノのパッケージを加えた構成になります

imx-boot-[VERSION].tar.gz

提供元 : アットマークテクノ

ブートローダーのソースコードや、セキュアブート用のイメージをつくるスクリプトを含みます

baseos-[VERSION].tar.zst

提供元 : アットマークテクノ

Armadillo Base OS のルートファイルシステムのビルド済みバイナリ


[注記]

ビルドの全体的なプロセスフローについては 「ビルドのプロセスフロー」に図があります。

5.3.2. ATDE を準備する

Armadillo-IoT ゲートウェイ G4の製品マニュアルの 「開発/動作確認環境の構築」 を参考に作業をしてください。

5.3.3. 署名ツール (CST) を準備する

NXP から署名ツールをダウンロードします

以下のサイトからダウンロードします。

[注記]
  • ダウンロードには NXP サイトへのユーザー登録が必要になります
  • 本書作成時点では v3.3.1 を利用しました。 2023 年 6 月時点で最新の v3.3.2 では、ブートローダーの暗号化が利用出来ませんので、必要な場合はサポートにご連絡ください。

ツールを展開します。

[ATDE ~]$ tar -xaf cst-3.3.1.tgz

5.3.4. アップデートファイル作成ツール (mkswu) を準備する

mkswu は SWUpdate に対応したアップデートファイルを生成するツールです。 ATDE にデフォルトでインストールされていないので、 手動でインストールする必要があります。

Armadillo-IoT ゲートウェイ G4 の製品マニュアルの 「SWUイメージの作成」を参考に次の作業をしてください。

  • mkswu の取得
  • 最初に行う設定 (mkswu --init)
[注記]

セキュアブートに対応する mkswu は 4.0-1 以上になります。

[重要項目]

SWU イメージの暗号化

SWU イメージはデフォルト設定では暗号化されません。 通信路は TLS で守られても、ファイルで保管されているときには平文なので SWU イメージ内にある機密情報が漏洩する可能性があります。 SWU イメージに漏洩すると問題のある情報資産を含めるときには必ず暗号化するべきです。

Armadillo-IoT ゲートウェイ G4 の製品マニュアル内の「最初に行う設定」を 実施するときには、以下の質問では y と答えてください。

アップデートイメージを暗号化しますか? (N/y)

バージョンの確認方法は以下のとおりです。

[ATDE ~]$ dpkg -l mkswu
ii  mkswu        4.0-1

5.3.5. Armadillo Base OS イメージの取得

署名や暗号化の対象であるブートローダーや Linux は、 アットマークテクノからビルド済みイメージが配布されています。 アットマークテクノのサイトから最新イメージをダウンロードしてください。

[注記]

本書作成時点で利用したパッケージは以下のとおりです。

  • imx-boot-2020.04-at8.tar.gz
  • baseos-x2-3.15.4-at.7.tar.zst
  • build-rootfs-v3.15-at.7.tar.gz

Armadillo Base OS を展開します。

[ATDE ~]$ mkdir -p baseos
[ATDE ~]$ tar xaf baseos-x2-[VERSION].tar.zst -C baseos 1

1

[VERSION] はバージョンによって変化します

ブートローダーを展開します。

[ATDE ~]$ tar xaf imx-boot-[VERSION].tar.gz 1

1

[VERSION] はバージョンによって変化します

ビルドツールを展開します。

[ATDE ~]$ tar xaf build-rootfs-[VERSION].tar.gz 1

1

[VERSION] はバージョンによって変化します

5.3.6. 署名環境のディレクトリツリー構成

ディレクトリ構成の一部抜粋は以下のとおりです。

├── baseos
├── build-rootfs-[VERSION] 1
├── cst_3.3.1
│   ├── crts 2
│   ├── keys 3
│   └── linux64/bin 4
├── imx-boot-[VERSION] 5
├── mkswu 6
└── secureboot 7

1 5

[VERSION] はそれぞれのバージョンによって変化します

2

ブートローダーに組み込む自己証明書群が配置される

3

鍵の生成ツール、生成された鍵が配置される

4

ビルド済み署名ツールが配置される

6

swu 作成に利用される。

7

ビルド結果が配置される。ビルド前にはないディレクトリ

5.3.7. 署名鍵を生成する

セキュアブート用の PKI tree を作っていきます。 生成する鍵とその証明書は以下のとおりです。

表5.2 セキュアブート用の鍵と証明書

namedescriptionfile name

CA 鍵ペア

ルート CA

CA1_sha256_[alg]_v3_ca_crt

SRK 鍵ペア

Super Root Key 用の鍵ペア

SRK[n]_sha256_[alg]_v3_ca_key

CSF 鍵ペア

CSF 用の鍵ペア

CSF[n]_sha256_[alg]_v3_usr_key

IMG 鍵ペア

イメージ用の鍵ペア

IMG[n]_sha256_[alg]_v3_usr_key

SRK 証明書

CA 鍵によって署名されたSRK 公開鍵を含んだ証明書

SRK[n]_sha256_[alg]_v3_ca_crt

CSF 証明書

SRK によって署名された CSF 公開鍵を含んだ証明書

CSF[n]_sha256_[alg]_v3_usr_crt

IMG 証明書

SRK によって署名された IMG 公開鍵を含んだ証明書

IMG[n]_sha256_[alg]_v3_usr_crt


  • [alg]: アルゴリズム (RSA: 1024/2048/3072/4096, ECC: prime256v1/secp384r1/secp521r1)
  • [n]: n = 1,2,3,4
[重要項目]

署名鍵のデフォルト設定は ECC secp521r1 となっています。 鍵の種類などの設定は imx-boot/secureboot.conf にあります。 変更する場合は 「secureboot.conf の設定方法」 を参照してください。

5.3.7.1. 署名鍵の生成

実際に署名鍵を生成していきます。 ここでは既存の CA 証明書を利用せずに鍵を生成します。 以下のコマンドを実行してください。

[ATDE ~]$ ./imx-boot/secureboot.sh init_srk

秘密鍵のパスワードを求められるので入力してください。

Passphrase used for key generation (will be written in plain text on filesystem)
[注記]

CST の詳細の情報は cst 内の docs ディレクトリにある CST_UG.pdf をご参照ください。

5.3.7.2. 生成された署名鍵の確認

ファイルがあるかどうかで鍵が生成されたことを確認してください。 以下はデフォルト設定である ECC secp521r1 の鍵を生成した場合の結果になります。

cst-3.3.1
    ├── crts
    │   ├── CA1_sha256_secp521r1_v3_ca_crt.der
    │   ├── CA1_sha256_secp521r1_v3_ca_crt.pem
    │   ├── CSF1_1_sha256_secp521r1_v3_usr_crt.der
    │   ├── CSF1_1_sha256_secp521r1_v3_usr_crt.pem
    │   ├── CSF2_1_sha256_secp521r1_v3_usr_crt.der
    │   ├── CSF2_1_sha256_secp521r1_v3_usr_crt.pem
    │   ├── CSF3_1_sha256_secp521r1_v3_usr_crt.der
    │   ├── CSF3_1_sha256_secp521r1_v3_usr_crt.pem
    │   ├── CSF4_1_sha256_secp521r1_v3_usr_crt.der
    │   ├── CSF4_1_sha256_secp521r1_v3_usr_crt.pem
    │   ├── IMG1_1_sha256_secp521r1_v3_usr_crt.der
    │   ├── IMG1_1_sha256_secp521r1_v3_usr_crt.pem
    │   ├── IMG2_1_sha256_secp521r1_v3_usr_crt.der
    │   ├── IMG2_1_sha256_secp521r1_v3_usr_crt.pem
    │   ├── IMG3_1_sha256_secp521r1_v3_usr_crt.der
    │   ├── IMG3_1_sha256_secp521r1_v3_usr_crt.pem
    │   ├── IMG4_1_sha256_secp521r1_v3_usr_crt.der
    │   ├── IMG4_1_sha256_secp521r1_v3_usr_crt.pem
    │   ├── SRK1_sha256_secp521r1_v3_ca_crt.der
    │   ├── SRK1_sha256_secp521r1_v3_ca_crt.pem
    │   ├── SRK2_sha256_secp521r1_v3_ca_crt.der
    │   ├── SRK2_sha256_secp521r1_v3_ca_crt.pem
    │   ├── SRK3_sha256_secp521r1_v3_ca_crt.der
    │   ├── SRK3_sha256_secp521r1_v3_ca_crt.pem
    │   ├── SRK4_sha256_secp521r1_v3_ca_crt.der
    │   ├── SRK4_sha256_secp521r1_v3_ca_crt.pem
    │   ├── SRK_1_2_3_4_fuse.bin
    │   └── SRK_1_2_3_4_table.bin
    └── keys
        ├── CA1_sha256_secp521r1_v3_ca_key.der
        ├── CA1_sha256_secp521r1_v3_ca_key.pem
        ├── CSF1_1_sha256_secp521r1_v3_usr_key.der
        ├── CSF1_1_sha256_secp521r1_v3_usr_key.pem
        ├── CSF2_1_sha256_secp521r1_v3_usr_key.der
        ├── CSF2_1_sha256_secp521r1_v3_usr_key.pem
        ├── CSF3_1_sha256_secp521r1_v3_usr_key.der
        ├── CSF3_1_sha256_secp521r1_v3_usr_key.pem
        ├── CSF4_1_sha256_secp521r1_v3_usr_key.der
        ├── CSF4_1_sha256_secp521r1_v3_usr_key.pem
        ├── IMG1_1_sha256_secp521r1_v3_usr_key.der
        ├── IMG1_1_sha256_secp521r1_v3_usr_key.pem
        ├── IMG2_1_sha256_secp521r1_v3_usr_key.der
        ├── IMG2_1_sha256_secp521r1_v3_usr_key.pem
        ├── IMG3_1_sha256_secp521r1_v3_usr_key.der
        ├── IMG3_1_sha256_secp521r1_v3_usr_key.pem
        ├── IMG4_1_sha256_secp521r1_v3_usr_key.der
        ├── IMG4_1_sha256_secp521r1_v3_usr_key.pem
        ├── SRK1_sha256_secp521r1_v3_ca_key.der
        ├── SRK1_sha256_secp521r1_v3_ca_key.pem
        ├── SRK2_sha256_secp521r1_v3_ca_key.der
        ├── SRK2_sha256_secp521r1_v3_ca_key.pem
        ├── SRK3_sha256_secp521r1_v3_ca_key.der
        ├── SRK3_sha256_secp521r1_v3_ca_key.pem
        ├── SRK4_sha256_secp521r1_v3_ca_key.der
        └── SRK4_sha256_secp521r1_v3_ca_key.pem
[重要項目]

生成した鍵は今後も利用するものです。 壊れにくい、セキュアなストレージにコピーしておくことをお勧めします。

[重要項目]

鍵の更新は計画性を持って行ってください。 たとえば開発時のみ利用する鍵、運用時に利用する鍵を使い分ける。 また、鍵は定期的に更新が必要です。以下を参考にしてください。

5.3.7.3. 鍵のハッシュ値の確認

生成が終わったら、次のコマンドを実行して鍵のハッシュ値を確認して、 結果を控えておいて下さい。後ほどデバイス上で efuse を書く際に利用します。

[ATDE ~]$ ./imx-boot-[VERSION]/secureboot.sh print_srk_fuse

以下のように表示されます。 あくまで例でハッシュ値は生成された鍵毎に異なります。このまま利用しないでください。

Use the following commands in uboot to set root key hash in OTP:
fuse prog -y 6 0 0xC04FA990 0x6C4BCFCC 0x90DAC78E 0x6C6CED49
fuse prog -y 7 0 0x535C7B3E 0x2695B4D4 0x9B3D028E 0x9FF5EFFB
fuse prog -y 0 0 0x200

For testing it is possible to temporarly override fuses instead,
but this only validates the last part of the boot:
fuse override 6 0 0xC04FA990 0x6C4BCFCC 0x90DAC78E 0x6C6CED49
fuse override 7 0 0x535C7B3E 0x2695B4D4 0x9B3D028E 0x9FF5EFFB

以上で、環境構築を終わります。

5.4. セキュアブート機能の選択

実際にセットアップする前にセキュアブートのオプションについて説明します。

セキュアブートを実現することによって、 セキュアブートのチェーンオブトラストをベースとした様々な機能を 入れられるようになります。 Armadillo-IoT ゲートウェイ G4 と Armadillo Base OS を利用することで、 以下のようなセキュリティ機能を実現することができます。 セキュリティの要件に合わせて機能を選択してください。

表5.3 セキュアブートの派生機能

機能概要期待される効果

セキュアブート (基本)

「セキュアブートのセットアップ」

ブートローダーと Linux kernel の署名確認

ブートローダーと Linux Kernel の改竄を検出することができます。また、 署名とその検証によって、正規ソフトウェアのみの起動を強制させることができます。

暗号化セキュアブート

「暗号化セキュアブートのセットアップ」

セキュアブート

+ブートローダーの暗号化

ブートローダーがフラッシュメモリに保存されている間は暗号化によって ブートローダー内にある情報資産の漏洩や、解析から保護することができます。 基本ブートローダーに情報資産はないですが、情報資産を守るための鍵をもつ場合が あるので、そういったケースでの活用が考えられます。

ストレージの暗号化

「ストレージの暗号化のセットアップ」

セキュアブート

+ブートローダーの暗号化

+ブロックデバイスの暗号化

ファイルがフラッシュメモリに保存されている間は暗号化によって ファイルは保護されます。 通常はアプリケーションやデータなどはファイルとして保存されるので、 そういったファイルに情報資産が含まれるケースでの活用が考えられます。


5.5. セキュアブートのセットアップ

ここではセキュアブートを有効にする方法を説明します。

5.5.1. uboot-imx のセキュアブートの実装仕様

セキュアブートの実装は uboot-imx のガイドに準拠しています。 詳しい仕様は以下を参照してください。 取得したソースツリー内にドキュメントがあります。

[ティップ]

セキュアブートのフローは 「セキュアブートのフロー」 を参照してください。

イメージの詳しいフォーマットと展開先については 「署名済みイメージと展開先」 を参照してください。

アップデートのフローの詳細については 「ファームウェアアップデートのフロー」を参照してください。

5.5.3. 署名済みブートローダーの作成

セキュアブートに対応したブートローダーをビルドします。 Armadillo-IoT ゲートウェイ G4 製品マニュアルの 「ブートローダーをビルドする」 を参考にビルドしてください。

以下のファイルが作られていれば、ビルドに成功しています。

[ATDE ~]$ ls imx-boot-[VERSION]
imx-boot_armadillo_x2

次に、ビルドしたイメージを署名して、イメージに署名を付加していきます。 セキュアブートに対応するために、特別な修正は必要ありません。 アットマークテクノからリリースされているブートローダーをそのまま利用できます。 既にビルドされたブートローダーを利用します。

署名をブートローダーイメージに付加していきます。

[ATDE ~]$ cd imx-boot-[VERSION]
[ATDE ~/imx-boot-[VERSION]]$ ./secureboot.sh imxboot

ビルド後に以下の2つのイメージが作られれば成功です。

[ATDE ~/imx-boot-[VERSION]]$ ls ../secureboot
secureboot/imx-boot_armadillo_x2.signed
[重要項目]

imx-boot_armadillo_x2.sign は SRK の異なるボードには 当たり前ですが利用できません。 誤って書き込まないようご注意ください。

5.5.4. 署名済み Linux カーネルイメージの作成

secureboot.conf を開発環境に合わせて更新していきます。

[ATDE ~]$ vi imx-boot-[VERSION]/secureboot.conf

Linux カーネルとデバイスツリーブロブがある場所を参照するように変更します。

LINUX_IMAGE="$SCRIPT_DIR/../baseos/boot/Image"
LINUX_DTB="$SCRIPT_DIR/../baseos/boot/armadillo_iotg_g4.dtb"
[注記]

設定の詳細については 「secureboot.conf の設定方法」 を参照してください。

最後に、Linux カーネルイメージを作ります。

[ATDE ~]$ cd imx-boot-[VERSION]
[ATDE ~/imx-boot-[VERSION]]$ ./secureboot.sh linux

ビルド後に以下のイメージがあれば成功です。

[ATDE ~/imx-boot-[VERSION]]$ ls ../secureboot
Image.signed

5.5.5. ルートファイルシステムのビルド

まず、ルートファイルシステムに組み込むために、 署名された Linux カーネルのイメージをビルド用のリソースディレクトリに配置します。

[ATDE ~]$ mkdir -p build-rootfs-[VERSION]/ax2/resources/boot
[ATDE ~]$ cp secureboot/Image.signed build-rootfs-[VERSION]/ax2/resources/boot/Image

組み込むファイルの準備が終わったので、次にルートファイルシステムをビルドします。

[ATDE ~]$ cd build-rootfs-[VERSION]
[ATDE ~/build-rootfs-[VERSION]]$ sudo ./build_rootfs.sh

以下のファイルがあればルートファイルシステムのビルドは成功しています。 以下は例なので、ファイル名などはバージョンや日付によって変化します。

[ATDE ~/build-rootfs-[VERSION]]$ ls
baseos-[VERSION].[DATE].tar.zst

5.5.6. セキュアブートセットアップ用 SD boot ディスクの作成

SD boot するための起動イメージを作ります。

[ATDE ~/build-rootfs-[VERSION]]$ sudo ./build_image.sh

以下のファイルができていれば成功です。ファイルに含まれる日付やバージョンは 変化します。

[ATDE ~/build-rootfs-[VERSION]]$ ls
baseos-[VERSION].[DATE].img

次に、上記の起動イメージを使って SD boot で初回書き込みを行うためのディスクイメージを 作成します。上記のイメージで SD boot して、これからつくるイメージを eMMC に 書き込んでいきます。

同じコマンドを使って引数を変えることで可能です。--installer には 上記のイメージを指定します。--boot には生成したブートローダーを指定します。

[ATDE ~/build-rootfs-[VERSION]]$ sudo ./build_image.sh \
--installer baseos-[VERSION].[DATE].img \
--boot ../secureboot/imx-boot_armadillo_x2.signed

以下のファイルができていれば成功です。ファイルに含まれる日付やバージョンは 変化します。

[ATDE ~/build-rootfs-[VERSION]]$ ls
baseos-[VERSION].[DATE]-installer.img

上記で作成した SD boot イメージを、 Armadillo-IoT ゲートウェイ G4の製品マニュアルの 「ブートディスクの作成」 を参考にして SD カードに書き込んでください。

SD boot 用の SD カードの作成が終わったら、 次からは実際に「Armadillo-IoT ゲートウェイ G4 上の作業」を行います。

5.6. 暗号化セキュアブートのセットアップ

ここでは暗号化されたブートローダーによるセキュアブートを有効にする方法を 説明します。

5.6.1. uboot-imx の暗号化セキュアブートの実装仕様

暗号化セキュアブートは uboot-imx の Encrypted boot で実現しています。 実装仕様は uboot-imx のガイドに準拠しています。 詳しい仕様は以下を参照してください。 取得したソースツリー内にドキュメントがあります。

[ティップ]

セキュアブートのフローは 「セキュアブートのフロー」 を参照してください。

イメージの詳しいフォーマットと展開先については 「署名済みイメージと展開先」 を参照してください。

アップデートのフローの詳細については 「ファームウェアアップデートのフロー」を参照してください。

5.6.3. 署名済みの暗号化ブートローダーの作成

セキュアブートと暗号化に対応したブートローダーをビルドします。 Armadillo-IoT ゲートウェイ G4 製品マニュアルの 「ブートローダーをビルドする」 を参考にビルドしてください。

以下のファイルが作られていれば、ビルドに成功しています。

[ATDE ~]$ ls imx-boot-[VERSION]
imx-boot_armadillo_x2

ビルドしたイメージを署名して、イメージに署名を付加していきます。 セキュアブートに対応するために、特別な修正は必要ありません。 アットマークテクノからリリースされているブートローダーをそのまま利用できます。 既にビルドされたブートローダーを利用します。

署名をブートローダーイメージに付加していきます。

[ATDE ~]$ cd ./imx-boot-[VERSION]
[ATDE ~/imx-boot-[VERSION]]$ ./secureboot.sh imxboot
[ATDE ~/imx-boot-[VERSION]]$ ./secureboot.sh imxboot_enc

ビルド後に以下のイメージが作られれば成功です。

[ATDE ~/imx-boot-[VERSION]]$ ls ../secureboot
secureboot/imx-boot_armadillo_x2.enc
secureboot/imx-boot_armadillo_x2.signed
secureboot/imx-boot_armadillo_x2.dek_offsets
[重要項目]

imx-boot_armadillo_x2.enc は暗号化セキュアブート専用になります。 この手順以外では基本的には利用できません。 誤って書き込まないようご注意ください。

また、imx-boot_armadillo_x2.sign は SRK の異なるボードには 当たり前ですが利用できません。 誤って書き込まないようご注意ください。

5.6.4. 暗号化 Linux カーネルイメージの生成

secureboot.conf を開発環境に合わせて更新していきます。

[ATDE ~]$ vi imx-boot-[VERSION]/secureboot.conf

Linux カーネルとデバイスツリーブロブがある場所を参照するように変更します。

LINUX_IMAGE="/home/atmark/baseos/boot/Image"
LINUX_DTB="/home/atmark/baseos/boot/armadillo_iotg_g4.dtb"
[注記]

設定の詳細については 「secureboot.conf の設定方法」 を参照してください。

Linux カーネルイメージを作ります。

[ATDE ~]$ cd imx-boot-[VERSION]
[ATDE ~/imx-boot-[VERSION]]$ ./secureboot.sh linux

ビルド後に以下のイメージがあれば成功です。

[ATDE ~/imx-boot-[VERSION]]$ ls ../secureboot
Image.signed

5.6.5. 暗号化セキュアブート対応 swu の作成

暗号鍵 (dek.blob) を組み込み処理を行う SWUpdate ファイル (swu) を作っていきます。

まず、dek.blob の組み込み処理を記述した desc ファイルの用意します。 desc ファイルの修正のためにファイルをコピーします。

[ATDE ~]$ cp /usr/share/mkswu/examples/encrypted_imxboot_update.desc ./mkswu

以下のように変更してください。

[ATDE ~]$ vi mkswu/encrypted_imxboot_update.desc
swdesc_boot_enc "../secureboot/imx-boot_armadillo_x2.enc" \
"../secureboot/armadillo_x2.dek_offsets"
[ティップ]

desc ファイル

SWUpdate ではファームウェアアップデート処理中にユーザー定義の追加処理を 行うことが可能です。 ユーザー定義の追加処理は desc ファイルに記述します。 desc ファイルは独自のシンタックスをもつアットマークテクノ製ツール (mkswu) 用の スクリプトファイルです。Armadillo Base OS に最適化されています。 mkswu パッケージのインストール先に desc ファイルの例があります。

desc のシンタックスの詳細仕様は Armadillo-IoT ゲートウェイ G4 製品マニュアルの 「mkswu の desc ファイル」 を参照してください。

実際に swu ファイルを作ります。

[ATDE ~]$ cd mkswu
[ATDE ~/mkswu]$ mkswu initial_setup.desc encrypted_imxboot_update.desc \
-o initial_setup_encboot.swu

以下のファイルができていれば成功です。

[ATDE ~/mkswu]$ ls
initial_setup_encboot.swu
[重要項目]

initial_setup_encboot.swu は暗号化セキュアブート専用になります。 この手順以外では基本的には利用できません。 誤って書き込まないようご注意ください。

5.6.6. ルートファイルシステムのビルド

まず、ルートファイルシステムに組み込むために、 署名された Linux カーネルのイメージをビルド用のリソースディレクトリに配置します。

[ATDE ~]$ mkdir -p build-rootfs-[VERSION]/ax2/resources/boot
[ATDE ~]$ cp secureboot/Image.signed build-rootfs-[VERSION]/ax2/resources/boot/Image

生成した暗号化セキュアブート対応 swu を配置します。

[ATDE ~]$ cp mkswu/initial_setup_encboot.swu build-rootfs-[VERSION]/ax2/installer

組み込むファイルの準備が終わったので、次にルートファイルシステムをビルドします。

[ATDE ~]$ cd build-rootfs-[VERSION]
[ATDE ~/build-rootfs-[VERSION]]$ sudo ./build_rootfs.sh

以下のファイルがあればルートファイルシステムのビルドは成功しています。 以下は例なので、ファイル名などはバージョンや日付によって変化します。

[ATDE ~/build-rootfs-[VERSION]]$ ls
baseos-[VERSION].[DATE].tar.zst

5.6.7. セキュアブートセットアップ用 SD boot ディスクの作成

SD boot するための起動イメージを作ります。

[ATDE ~/build-rootfs-[VERSION]]$ sudo ./build_image.sh

以下のファイルができていれば成功です。ファイルに含まれる日付やバージョンは 変化します。

[ATDE ~/build-rootfs-[VERSION]]$ ls
baseos-[VERSION].[DATE].img

次に、上記の起動イメージを使って SD boot で初回書き込みを行うためのディスクイメージを 作成します。上記のイメージで SD boot して、これからつくるイメージを eMMC に 書き込んでいきます。

同じコマンドを使って引数を変えることで可能です。--installer には 上記のイメージを指定します。--boot には生成したブートローダーを指定します。

[ATDE ~/build-rootfs-[VERSION]]$ sudo ./build_image.sh \
--installer baseos-[VERSION].[DATE].img \
--boot ../secureboot/imx-boot_armadillo_x2.signed

以下のファイルができていれば成功です。ファイルに含まれる日付やバージョンは 変化します。

[ATDE ~/build-rootfs-[VERSION]]$ ls
baseos-[VERSION].[DATE]-installer.img

上記で作成した SD boot イメージを、 Armadillo-IoT ゲートウェイ G4の製品マニュアルの 「ブートディスクの作成」 を参考にして SD カードに書き込んでください。

SD boot 用の SD カードの作成が終わったら、 次からは実際に「Armadillo-IoT ゲートウェイ G4 上の作業」を行います。

5.7. ストレージの暗号化のセットアップ

ここではストレージを暗号化する方法を説明します。

5.7.1. 実装仕様の概要

Armadiilo Base OS では、ストレージの暗号化に LUKS2 (Linux Unified Key Setup) を採用しました。CAAM を用いた方法もありますが、CAAM は AES XTS モードを サポートしておらず、AES CBC/ECB モードのみサポートされています。 パフォーマンスが極端に悪いので、CAAM を利用せずに LUKS2 で ARM Cryptographic extension を利用しています。

LUKS2 に与える鍵は CAAM の Black key 技術によって保護されます。 Black key はデバイス固有の鍵を利用してファイルを暗号化することができます。 デバイス固有の鍵を利用しているので、Black key を別のボートにコピーしても、 鍵を利用することはできません。 Black key をフル機能で利用するためには、セキュアブートが必須なので、 暗号化セキュアブートも利用します。

Armadillo Base OS ではストレージの2つの領域の暗号化をサポートします。

  1. アプリケーションを配置するコンテナのファイルシステム
  2. Armadioo Base OS のルートファイルシステム

build-rootfs のスクリプト (build_image.sh) では、 1 (USERFS) か 1+2 (ALL) の設定が可能です。

[ティップ]

セキュアブートのフローは 「セキュアブートのフロー」 を参照してください。

イメージの詳しいフォーマットと展開先については 「署名済みイメージと展開先」 を参照してください。

アップデートのフローの詳細については 「ファームウェアアップデートのフロー」を参照してください。

5.7.3. 署名済みブートローダーの作成

セキュアブートと暗号化に対応したブートローダーをビルドします。 Armadillo-IoT ゲートウェイ G4 製品マニュアルの 「ブートローダーをビルドする」 を参考にビルドしてください。

以下のファイルが作られていれば、ビルドに成功しています。

[ATDE ~]$ ls imx-boot-[VERSION]
imx-boot_armadillo_x2

次に、ビルドしたイメージを署名して、イメージに署名を付加していきます。 セキュアブートに対応するために、特別な修正は必要ありません。 アットマークテクノからリリースされているブートローダーをそのまま利用できます。 既にビルドされたブートローダーを利用します。

署名をブートローダーイメージに付加していきます。

[ATDE ~]$ cd ./imx-boot-[VERSION]
[ATDE ~/imx-boot-[VERSION]]$ ./secureboot.sh imxboot
[ATDE ~/imx-boot-[VERSION]]$ ./secureboot.sh imxboot_enc

ビルド後に以下の3つのファイルが作られれば成功です。

[ATDE ~/imx-boot-[VERSION]]$ ls ../secureboot
secureboot/imx-boot_armadillo_x2.enc
secureboot/imx-boot_armadillo_x2.signed
secureboot/imx-boot_armadillo_x2.dek_offsets
[重要項目]

imx-boot_armadillo_x2.enc は暗号化セキュアブート専用になります。 この手順以外では基本的には利用できません。 誤って書き込まないようご注意ください。

また、imx-boot_armadillo_x2.sign は SRK の異なるボードには 当たり前ですが利用できません。 誤って書き込まないようご注意ください。

5.7.4. 署名済み Linux カーネルイメージの作成

まず、initrd 用のルートファイルシステムをビルドします。

[ATDE ~]$ cd build-rootfs-[VERSION]
[ATDE ~/build-rootfs-[VERSION]]$ sudo ./build_rootfs.sh

以下のファイルがあればルートファイルシステムのビルドは成功しています。 以下は例なので、ファイル名などはバージョンや日付によって変化します。

[ATDE ~/build-rootfs-[VERSION]]$ ls
baseos-[VERSION].[DATE].tar.zst

次に、initrd の作成します。 ストレージ暗号化に対応するためには、通常の Armadillo Base OS にはない、 暗号鍵などの設定を行うための initrd が必要になります。

[ATDE ~/build-rootfs-[VERSION]]$ sudo ./build_initrd.sh

以下のファイルがあれば initrd のビルドは成功しています。 以下は例なので、ファイル名などはバージョンや日付によって変化します。

[ATDE ~/build-rootfs-[VERSION]]$ ls
initrd-baseos-[VERSION].[DATE].zst

次に、secureboot.conf を開発環境に合わせて更新していきます。

[ATDE ~]$ vi imx-boot/secureboot.conf

Linux カーネルとデバイスツリーブロブがある場所を参照するように変更します。

LINUX_IMAGE="/home/atmark/baseos/boot/Image"
LINUX_DTB="/home/atmark/baseos/boot/armadillo_iotg_g4.dtb"

上記で作った initrd を参照するように設定を変更します。

LINUX_INITRD="../build-rootfs-[VERSION]/initrd-baseos-[VERSION].[DATE].zst"
[注記]

設定の詳細については 「secureboot.conf の設定方法」 を参照してください。

最後に、Linux カーネルイメージを作ります。

[ATDE ~]$ cd imx-boot-[VERSION]
[ATDE ~/imx-boot-[VERSION]]$ ./secureboot.sh linux

ビルド後に以下のイメージが更新されていれば成功です。

[ATDE ~/imx-boot-[VERSION]]$ ls ../secureboot
Image.signed

5.7.5. セキュアブート対応 swu の作成

ストレージ暗号化対応の SWUpdate 用のファイル (swu) を作っていきます。

まず、設定ファイルの準備します。 swu を作成するために必要なファイルを集めます。desc ファイルは swu を作成する アットマークテノ製ツール mkswu の入力となる設定ファイルです。修正のために ファイルをコピーします。

[ATDE ~]$ cp /usr/share/mkswu/examples/enable_disk_encryption.desc ./mkswu
[ATDE ~]$ cp /usr/share/mkswu/examples/encrypted_imxboot_update.desc ./mkswu

以下のように変更してください。

[ATDE ~]$ vi mkswu/encrypted_imxboot_update.desc
swdesc_boot_enc "../secureboot/imx-boot_armadillo_x2.enc" \
"../secureboot/armadillo_x2.dek_offsets"
[ティップ]

desc ファイル

SWUpdate ではファームウェアアップデート処理中にユーザー定義の追加処理を 行うことが可能です。 ユーザー定義の追加処理は desc ファイルに記述します。 desc ファイルは独自のシンタックスをもつアットマークテクノ製ツール (mkswu) 用の スクリプトファイルです。Armadillo Base OS に最適化されています。 mkswu パッケージのインストール先に desc ファイルの例があります。

desc のシンタックスの詳細仕様は Armadillo-IoT ゲートウェイ G4 製品マニュアルの 「mkswu の desc ファイル」 を参照してください。

実際に swu ファイルを作ります。

[ATDE ~]$ cd mkswu
[ATDE ~/mkswu]$ mkswu initial_setup.desc enable_disk_encryption.desc \
encrypted_imxboot_update.desc -o initial_setup_encryption.swu

以下のファイルができていれば成功です。

[ATDE ~/mkswu]$ ls
initial_setup_encryption.swu
[重要項目]

initial_setup_encryption.swu はストレージ暗号化専用になります。 この手順以外では基本的には利用できません。 誤って書き込まないようご注意ください。

5.7.6. ルートファイルシステムのビルド

まず、ルートファイルシステムに組み込むために、 署名された Linux カーネルのイメージをビルド用のリソースディレクトリに配置します。

[ATDE ~]$ mkdir -p build-rootfs-[VERSION]/ax2/resources/boot
[ATDE ~]$ cp secureboot/Image.signed build-rootfs-[VERSION]/ax2/resources/boot/Image

生成したストレージ暗号化対応 swu も配置します。

[ATDE ~]$ cp mkswu/initial_setup_encryption.swu build-rootfs-[VERSION]/ax2/installer

組み込むファイルの準備が終わったので、次にルートファイルシステムをビルドします。

[ATDE ~]$ cd build-rootfs-[VERSION]
[ATDE ~/build-rootfs-[VERSION]]$ sudo ./build_rootfs.sh

以下のファイルがあればルートファイルシステムのビルドは成功しています。 以下は例なので、ファイル名などはバージョンや日付によって変化します。

[ATDE ~/build-rootfs-[VERSION]]$ ls
baseos-[VERSION].[DATE].tar.zst

5.7.7. セキュアブートセットアップ用 SD boot ディスクの作成

SD boot するための起動イメージを作ります。

[ATDE ~/build-rootfs-[VERSION]]$ sudo ./build_image.sh

以下のファイルができていれば成功です。ファイルに含まれる日付やバージョンは 変化します。

[ATDE ~/build-rootfs-[VERSION]]$ ls
baseos-[VERSION].[DATE].img

次に、上記の起動イメージを使って SD boot で初回書き込みを行うためのディスクイメージを 作成します。上記のイメージで SD boot して、これからつくるイメージを eMMC に 書き込んでいきます。

同じコマンドを使って引数を変えることで可能です。--installer には 上記のイメージを指定します。--boot には生成したブートローダーを指定します。

[ATDE ~/build-rootfs-[VERSION]]$ sudo ./build_image.sh \
--encrypt all \
--installer baseos-[VERSION].[DATE].img \
--boot ../secureboot/imx-boot_armadillo_x2.signed
[注記]

ストレージの暗号化を行う範囲は2通り選択可能です。

--encrypt オプション

  • userfs : アプリケーション領域
  • all : アプリケーション領域と Linux rootfs 領域

以下のファイルができていれば成功です。ファイルに含まれる日付やバージョンは 変化します。

[ATDE ~/build-rootfs-[VERSION]]$ ls
baseos-[VERSION].[DATE]-installer.img

上記で作成した SD boot イメージを、 Armadillo-IoT ゲートウェイ G4の製品マニュアルの 「ブートディスクの作成」 を参考にして SD カードに書き込んでください。

SD boot 用の SD カードの作成が終わったら、 次からは実際に「Armadillo-IoT ゲートウェイ G4 上の作業」を行います。

5.8. Armadillo-IoT ゲートウェイ G4 上の作業

以下は作業の流れです。 セキュアブート、暗号化セキュアブート、ストレージの暗号化で共通の作業になります。

以降はアップデート処理によって自動的にセットアップが行われます。

5.8.1. Armadillo-IoT ゲートウェイ G4 の準備

Armadillo IoT G4 の電源を投入する前に 以下の作業を行ってください。

  • CON1(SD インターフェース)に作った SD カードを挿入する
  • JP1 ジャンパーをショート(SD ブートに設定)します。

また、minicom などのシリアル通信ソフトウェアを起動して、デバッグ入出力を 受け付けられるようにしておいてください。

5.8.2. SRK ハッシュの書き込み

電源を投入するとすぐに以下のように uboot からデバッグ出力されます。 その間にシリアル通信ソフトウェア上で何らかのキーを押して、 uboot の プロンプトに入ってください。

Hit any key to stop autoboot:  2
u-boot=>
[注記]

uboot プロンプトへの遷移に間に合わなかった場合は、 そのままの状態 (SD カードを挿したまま、JP1 をショート)で 電源を切って再投入後に再試行して下さい。

セキュアブートを有効にするためには、i.MX 8M Plus の eFuse に SRK のハッシュ値を 書く必要があります。i.MX 8M Plus の OCOTP (On-chip One-Time Programmable Element Controller) のレジスタ経由で 書き込むことになります。uboot-imx には OCOTPA へのアクセスを行う fuse コマンドがあります。

以下は手順のはじめに出てきた secureboot.sh print_srk_fuse の結果です。 あくまで例なのでハッシュ値は生成された鍵毎に異なります。 このまま入力しないでください。

u-boot=> fuse prog -y 6 0 0xC04FA990 0x6C4BCFCC 0x90DAC78E 0x6C6CED49
u-boot=> fuse prog -y 7 0 0x535C7B3E 0x2695B4D4 0x9B3D028E 0x9FF5EFFB
u-boot=> fuse prog -y 0 0 0x200
[注意]

eFuse は OTP なので一度作業を行うと変更はできません。注意して作業してください。

[注意]

ハッシュ値は生成された鍵毎にことなります。例の値をそのまま書かないで下さい。

次に、これまでのビルド作業や実機上の作業を簡単に確認するために、 HAB の状態を確認します。 次のステップである close 処理を行うとセキュアブートに対応したファームウェア でしか起動できなくなります。 まだ、close 処理されていない状態ではセキュアブートの必要がないので、 問題の解析がしやすくなります。

まず、再起動します。

u-boot=> reset

uboot のプロンプトで以下のコマンドで確認してください。 以下は正常時のログになります。

u-boot=> hab_status

Secure boot enabled

HAB Configuration: 0xcc, HAB State: 0x99
No HAB Events Found!
[注記]

問題が発生した場合

原理確認などを行っているケースでは作業内容に何かしらの問題がある 可能性があります。ログで今までの作業内容を見直してください。 製造ラインなどで同じ作業を繰り返しているケースでは問題は発生しないはずですが、 個体不良の解析のためにここでチェックすることをお勧めします。

5.8.3. close 処理

SRK ハッシュを書いただけでは署名確認に失敗しても起動自体は継続されます。 close 処理を行うことで署名確認に失敗すると起動に失敗するようになります。

[ティップ]

開発フェーズなどでセキュアブート処理を確認する場合は、 この close 処理をスキップすることをすることをお勧めします。

[注記]

i.MX 8M plus 内にある SNVS (Secure Non-Volatile Storage) で利用される鍵は、 close 処理をしないとテスト用の鍵が使われます。 テスト用の鍵はデバイス間で共通なため、そのままでは簡単に復号できてしまいます。 close 処理を行うことで、デバイスに固有な鍵を利用するようになります。

close 処理は以下のコマンドで efuse を書き込むことで行います。

u-boot=> fuse prog -y 1 3 0x2000000

5.8.4. ファームウェアの書き込みをはじめる

次に、アップデート作業をはじめるためにリセットします。 今後の作業は全て自動的に行われます。

u-boot=> reset

以下のログが表示されたら、電源が入った状態で JP1 ジャンパーをショート (SD ブートに設定)を解除してください。

mkfs.fat 4.2 (2021-01-31)
Finished writing mmc. powering off now

最終的に Linux のログインプロンプトが表示できたら作業は完了です。

[注記]

アップデートのフローの詳細については 「ファームウェアアップデートのフロー」を参照してください。

5.8.5. 作業が中断した場合

万が一、電源断などで作業が中断してしまった場合に作業を完了させる方法に ついて説明します。

まず、電源を切った状態で 「Armadillo-IoT ゲートウェイ G4 の準備」 が維持されていること を確認してください。そのうえで、状況に応じて以下の作業を行ってください。

  • SRK ハッシュを書いていない場合は、「SRK ハッシュの書き込み」 から作業をやり直します
  • close 処理を完了していない場合は、SRK ハッシュの書き込みをスキップしてください
  • ファームウェアの書き込みが完了していない場合は、SRK ハッシュの書き込みと close 処理をスキップします。 具体的な手順としては、電源を投入した直後 (だいたい数秒後) に電源が入った状態で JP1 ジャンパーのショートを解除して、処理が完了するのを待ってください

最終的に立ち上がってきたら、次の動作確認に進んでください。

5.9. 動作確認

5.9.1. ストレージ暗号化の確認

ストレージの暗号化が成功したかどうかは、 Armadillo IoT G4 上で以下のコマンドを実行することで確認できます。 TYPE が crypt となっているパーティションが暗号化されています。

[armadillo ~] # lsblk
NAME          MAJ:MIN RM  SIZE RO TYPE  MOUNTPOINTS
mmcblk2       179:0    0 14.8G  0 disk
|-mmcblk2p1   179:1    0  301M  0 part
| `-rootfs_0  253:0    0  300M  0 crypt /live/rootfs
|-mmcblk2p2   179:2    0  301M  0 part
|-mmcblk2p3   179:3    0   50M  0 part
| `-mmcblk2p3 253:1    0   49M  0 crypt /var/log
|-mmcblk2p4   179:4    0  200M  0 part
| `-mmcblk2p4 253:2    0  199M  0 crypt /opt/firmware
`-mmcblk2p5   179:5    0   14G  0 part
  `-mmcblk2p5 253:3    0   14G  0 crypt /var/tmp
                                        /var/app/volumes
                                        /var/app/rollback/volumes
                                        /var/lib/containers/storage_readonly

5.9.2. セキュアブートの確認

Linux カーネルが立ち上がることを確認してください。 Linux カーネルまで立ち上がらない場合、uboot-imx のコマンドで HAB の状態を確認することができます。

Linux 起動まで正常な起動ログ

: (省略)
Booting from mmc ...

## Checking Image at 40480000 ...
Unknown image format!
53522 bytes read in 22 ms (2.3 MiB/s)

Authenticate image from DDR location 0x40480000...

Secure boot enabled 1

HAB Configuration: 0xcc, HAB State: 0x99
No HAB Events Found! 2

## Flattened Device Tree blob at 45000000
   Booting using the fdt blob at 0x45000000
   Using Device Tree in place at 0000000045000000, end 0000000045010111

Starting kernel ...
: (省略)

1

セキュアブートが有効な場合に表示されます

2

問題がない場合はイベントが表示されません

ブートローダーに問題がある場合の起動ログ

: (省略)
spl: ERROR:  image authentication unsuccessful
### ERROR ### Please RESET the board ###
: (省略)

Linux カーネルイメージに問題がある場合の起動ログ

: (省略)
Authenticate image from DDR location 0x40480000...
bad magic magic=0x14 length=0xa1 version=0x0
bad length magic=0x14 length=0xa1 version=0x0
bad version magic=0x14 length=0xa1 version=0x0
Error: Invalid IVT structure

Allowed IVT structure:
IVT HDR      = 0x4X2000D1
IVT ENTRY    = 0xXXXXXXXX
IVT RSV1      = 0x0
IVT DCD      = 0x0
IVT BOOT_DATA = 0xXXXXXXXX
IVT SELF      = 0xXXXXXXXX
IVT CSF      = 0xXXXXXXXX
IVT RSV2      = 0x0
Authenticate Image Fail, Please check 1
: (省略)

1

認証に失敗しています

u-boot コマンドの hab_status

問題がない場合

u-boot=> hab_status

Secure boot enabled

HAB Configuration: 0xcc, HAB State: 0x99
No HAB Events Found!

Linux カーネルイメージの署名確認で問題がある場合

u-boot=> hab_status

Secure boot disabled

HAB Configuration: 0xf0, HAB State: 0x66

--------- HAB Event 1 -----------------
event data:
        0xdb 0x00 0x14 0x45 0x33 0x0c 0xa0 0x00
        0x00 0x00 0x00 0x00 0x40 0x1f 0xdd 0xc0
        0x00 0x00 0x00 0x20

STS = HAB_FAILURE (0x33)
RSN = HAB_INV_ASSERTION (0x0C)
CTX = HAB_CTX_ASSERT (0xA0)
ENG = HAB_ENG_ANY (0x00)

5.10. セットアップ完了後のアップデートの運用について

コンテナ内のアプリケーションのアップデートはセットアップとは関係なく、 とくに特別な対応なしで通常どおりの方法でアップデートが可能です。 Armadillo-IoT ゲートウェイ G4 製品マニュアルの 「Armadillo のソフトウェアをアップデートする」 を参考にしてください。

ブートローダーや Linux カーネルを更新するのは若干の違いがあります。 以下のオプションをつけることが必要になります。

ブートローダーの更新 (encrypted_imxboot_update.desc)

[ATDE ~/mkswu]$ mkswu encrypted_imxboot_update.desc -o update_boot.swu

Linux カーネルの更新 (encrypted_rootfs_linux_update.desc)

[ATDE ~/mkswu]$ mkswu encrypted_rootfs_linux_update.desc -o update_linux.swu

5.11. 補足情報

5.11.1. secureboot.conf の設定方法

secureboot.conf はセキュアブートイメージ生成スクリプト secureboot.sh の設定ファイルです。以下はコンフィグの一部です。

CST_ECC

既存の CA 証明書を利用するかどうかを設定する

  • y: EC を利用する
  • n: RSA を利用する
CST_KEYLEN, CST_KEYTYPE
鍵長を設定する

表5.4 セキュアブート用の鍵の種類

AlgorithmCST_KEYLENCST_KEYTYPE

RSA 1024

1024

1024_65537

RSA 2048

2048

2048_65537

RSA 3072

3072

3072_65537

RSA 4096

4096

4096_65537

EC NIST P-256

p256

prime256v1

EC NIST P-384

p384

secp384r1

EC NIST P-521

p521

secp521r1


CST_SOURCE_INDEX
SRK は最大4本まで持つことができます。この設定ではどの SRK を利用するのか設定します。 設定値は 0 はじまりで、0 がデフォルトです。
CST_UNLOCK_SRK
SRK のリボーク時に利用します。デフォルト設定では攻撃や事故の防止のために、 リボークができない状態になっています。#CST_UNLOCK_SRK=y のコメントを外すことで リボークが可能な状態になります。
LINUX_IMAGE,LINUX_DTB
FIT イメージに組み込むための Linux kernel イメージとデバイスツリーブロブ (DTB) の絶対パス。
LINUX_DTB_OVERLAYS
Linux 向けの Device tree オーバーレイ用ファイルを組み込むために利用する。いったん、Linux の device mapper を利用してルートファイルシステムを暗号化してしまうと、ブートローダーでは鍵がないとファイルを読むことができない。そのために FIT イメージに組み込んでおくためのオプション。/boot/overlays.conf にも同様の修正を加えてください。 以下は例です。組み込みたいファイルを追加してください。
LINUX_DTB_OVERLAYS=(
        armadillo_iotg_g4-nousb.dtbo
        armadillo_iotg_g4-sw1-wakeup.dtbo
)
LINUX_INITRD
暗号化されたルートファイルシステムを復号するための処理を行うための initrd の絶対パス。encrypted boot を利用しない場合には設定は不要です。

5.11.2. 署名済みイメージと展開先

以下にブートローダーの署名済みイメージと展開先についての例を示します。緑色の部分が BootROM によって署名検証される部分、橙色の部分は SPL によって署名検証される部分になります。

./images/memmap_secureboot_spl.png

図5.2 ブートローダーの署名済みイメージ


./images/memmap_encryptedboot_spl.png

図5.3 暗号化ブートローダーの署名済みイメージ


Linux の署名済みイメージと展開先の例は以下のとおりです。水色の部分は u-boot によって署名検証される部分になります。

./images/memmap_secureboot_linux.png

図5.4 Linux カーネルの署名済みイメージ


./images/memmap_storage_encryption.svg

図5.5 ストレージ暗号化に対応した Linux カーネルの署名済みイメージ


5.11.3. セキュアブートのフロー

以下に SPL (Secondary Program Loader) のブートフローの概要を示します。点線で囲っている部分はセキュアブートで有効になる処理です。

./images/spl_boot_sequence.png

図5.6 SPL セキュアブートのフロー


u-boot のブートフローの概要は以下のとおりです。SPL と同様に点線で囲っている部分はセキュアブートで有効になる処理です。

./images/u-boot_boot_sequence.png

図5.7 u-boot セキュアブートのフロー


5.11.4. ビルドのプロセスフロー

./images/build-flow_storage-encryption.svg

図5.8 セキュアブートのビルドフロー


5.11.5. ファームウェアアップデートのフロー

./images/update-flow_secureboot.svg

図5.9 ファームウェアアップデートのフロー


5.11.6. SRK の無効化と切り替え

何らかのインシデント対応による鍵更新、また、鍵の定期更新などが必要な場合、その時点で利用している鍵を無効化して、別の鍵に切り替えることが可能です。ただし、その場合は複数 (i.MX 8M Plus の場合、最大4つ) の SRK が書かれていることが前提となります。

5.11.6.1. SRK の無効化 (revocation)

ここでは SRK1 (index 0) から SRK2 (index 1) に変更する例を説明します。

  1. secureboot.conf の revocation のロックを解除する設定を有効にします

    デフォルトでは eFuse の revoke レジスタはロックされているので書き込みできません。 ロックは HAB の設定で解除することができます。常にロックを解除すると攻撃者に 悪用される可能性があるので通常はロックされるべきです。

    imx-boot-[VERSION}/secureboot.conf を開いて、CST_UNLOCK_SRK=y のコメントを 外してください。 secureboot.conf の詳細については 「secureboot.conf の設定方法」 を参照してください。

    [ATDE ~]$ vi imx-boot-[VERSION]/secureboot.conf
  2. 署名済みイメージを書き込む

    環境に合わせて、署名済みか、暗号化+署名済みのイメージを作成して、 イメージを書き込んでください。

  3. 再起動
  4. Unlock を確認する

    再起動時の uboot-imx のプロンプトを立ち上げてレジスタ値を確認します。 以下のコマンドを実行してください。bit1 (SRK_REVOKE_LOCK) が落ちていると Unlock 状態です。

    u-boot=> md 0x30350050 1
    30350050: 00007dbc 1

    1

    7dbc の bit 1 が落ちているので unlock 状態

  5. SRK を無効化する

    ビットフィールドはビットは 0 はじまりで、鍵の番号は 1 はじまり (1,2,3,4) になります。 bit0 が SRK1、bit1 が SRK2、bit2 が SRK3、bit3 が SRK4 です。

    [注意]

    以下のコマンドはあくまで例なので、そのまま実行しないで下さい。

    SRK1 を無効化する場合は以下のコマンドを実行してください。最終引数が無効化する鍵の設定値です。

    u-boot=> fuse prog 9 3 1

5.11.6.2. SRK の切り替え

ここでは SRK1 (index 0) から SRK2 (index 1) に変更する例を説明します。

  1. SRK の変更

    secureboot.conf の CST_SOURCE_INDEX を 0 から 1 に変更してください。 secureboot.conf の詳細については 「secureboot.conf の設定方法」 を参照してください。

    [ATDE ~]$ vi imx-boot-[VERSION]/secureboot.conf
  2. 再署名する

    環境に合わせて、署名済みか、暗号化+署名済みのイメージを作成して、 イメージを書き込んでください。