組み込みデバイスへの攻撃は様々な方向から行われます。ある方向のセキュリティ対策が強固な場合、攻撃者は回避可能な別の方向がないのか模索します。攻撃者のコードを何らかの方法でデバイスに組み込んで対策を回避するのが、単純ですが有効な方法でしょう。IoT デバイスはネットワーク上のサービスとデータのやり取りを行います。通信路の暗号化、サーバーとデバイスの相互認証などの対策を講じたとしても、IoT デバイス上にあるソフトウェアに攻撃者のコードを組み込むことで対策を回避してシステムに侵入される可能性があるのです。
セキュアブートは、起動ソフトウェアのディジタル署名を用いて正規ソフトウェアであることを確認してから起動する処理のことです。攻撃者によって作られた不正なコードを実行前に検出することができます。セキュアブートはチェーンオブトラスト (chain of trust) と表裏一体に実装されます。チェーンオブトラストとは、その名の通り、信頼を繋いでいく形態のことを指します。ルートオブトラストと呼ばれる基礎となる情報から枝葉のように繋がれた情報を認証していくことで、繋がれた個々のコンポーネントだけでなくシステムを信頼できるものにしてくれます。セキュアブートは、起動時にソフトウェアを順番に認証することで信頼を次に繋いでいるのです。セキュアブートの範囲をどこまでにするかによりますが、起動時に認証されたソフトウェアで別の情報を認証すれば、チェーンオブトラストを繋げていくことができます。また、IoT デバイスとクラウドサービスから構成されるような広範囲に及ぶシステムは特に信頼が必要になります。信頼できるセキュリティ基盤を構築するためには、構成するソフトウェアが正規のリリース物であることを確認することが重要になります。チェーンオブトラストを採用することでより信頼できる IoT システムとなり得るのです。
では、どういったケースでセキュアブートを採用するべきでしょうか。セキュアブートはセキュアな組み込みデバイスを実現する上で最初のステップにするべき技術です。しかし、導入するのであればコスト面にも配慮することが必要でしょう。まず、製造時の追加コストが必要です。鍵等を書き込む工程が必要になります。ただ書き込めばよいわけではなく、漏洩があってはいけないので物理的な隔離などセキュアに書き込む必要があります。メンテナンスにも追加のコストが必要です。ソフトウェアのリリース時にはソフトウェアの署名が必要になります。こちらも、物理的な隔離などの漏洩、汚染対策が必要になります。また、どこまでやるかによりますが、定期的な鍵の更新、インシデントや製品寿命による鍵のリボーケーションなどのメンテナンスコストが必要になってきます。費用対効果を検討してからの導入をお勧めします。
まず、セキュアブートをセットアップするために必要な環境を構築していきます。
ここで利用する署名環境の構成は以下のとおりです。
表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 のルートファイルシステムのビルド済みバイナリ |
NXP から署名ツールをダウンロードします
以下のサイトからダウンロードします。
![[注記]](images/note.png) | |
|---|
-
ダウンロードには NXP サイトへのユーザー登録が必要になります
-
本書作成時点では v3.3.1 を利用しました。
2023 年 6 月時点で最新の v3.3.2 では、ブートローダーの暗号化が利用出来ませんので、必要な場合はサポートにご連絡ください。
|
ツールを展開します。
[ATDE ~]$ tar -xaf cst-3.3.1.tgz
5.3.4. アップデートファイル作成ツール (mkswu) を準備する
mkswu は SWUpdate に対応したアップデートファイルを生成するツールです。
製品マニュアルを参考に ATDE をセットアップしてください。
| |
|---|
セキュアブートに対応する mkswu は 4.0-1 以上になります。 |
![[重要項目]](images/important.png) | |
|---|
SWU イメージの暗号化 SWU イメージはデフォルト設定では暗号化されません。
通信路は TLS で守られても、ファイルで保管されているときには平文なので
SWU イメージ内にある機密情報が漏洩する可能性があります。
SWU イメージに漏洩すると問題のある情報資産を含めるときには必ず暗号化するべきです。 Armadillo-IoT ゲートウェイ G4/Armadillo-X2 の製品マニュアル内の「最初に行う設定」を
実施するときには、以下の質問では 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 
|
[VERSION] はバージョンによって変化します
|
ブートローダーを展開します。
[ATDE ~]$ tar xaf imx-boot-[VERSION].tar.gz
|
[VERSION] はバージョンによって変化します
|
ビルドツールを展開します。
[ATDE ~]$ tar xaf build-rootfs-[VERSION].tar.gz
|
[VERSION] はバージョンによって変化します
|
ディレクトリ構成の一部抜粋は以下のとおりです。
├── baseos
├── build-rootfs-[VERSION]
├── cst_3.3.1
│ ├── crts 
│ ├── keys 
│ └── linux64/bin 
├── imx-boot-[VERSION] 
├── mkswu 
└── secureboot 
|
[VERSION] はそれぞれのバージョンによって変化します
|
|
ブートローダーに組み込む自己証明書群が配置される
|
|
鍵の生成ツール、生成された鍵が配置される
|
|
ビルド済み署名ツールが配置される
|
|
swu 作成に利用される。
|
|
ビルド結果が配置される。ビルド前にはないディレクトリ
|
セキュアブート用の PKI tree を作っていきます。
生成する鍵とその証明書は以下のとおりです。
表5.2 セキュアブート用の鍵と証明書
| name | description | file 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 の設定方法」 を参照してください。 |
実際に署名鍵を生成していきます。
ここでは既存の 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 をご参照ください。 |
ファイルがあるかどうかで鍵が生成されたことを確認してください。
以下はデフォルト設定である 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 | |
|---|
生成した鍵は今後も利用するものです。
壊れにくい、セキュアなストレージにコピーしておくことをお勧めします。 |
| |
|---|
鍵の更新は計画性を持って行ってください。
たとえば開発時のみ利用する鍵、運用時に利用する鍵を使い分ける。
また、鍵は定期的に更新が必要です。以下を参考にしてください。 |
生成が終わったら、次のコマンドを実行して鍵のハッシュ値を確認して、
結果を控えておいて下さい。後ほどデバイス上で 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.5.1. uboot-imx のセキュアブートの実装仕様
セキュアブートの実装は uboot-imx のガイドに準拠しています。
詳しい仕様は以下を参照してください。
取得したソースツリー内にドキュメントがあります。
セキュアブートのセットアップの流れは以下のとおりです。
PC 上の作業
事前準備
ビルド
Armadillo-IoT ゲートウェイG4/Armadillo-X2 上の作業
セキュアブートに対応したブートローダーをビルドします。
製品マニュアルを参考にビルドしてください。
以下のファイルが作られていれば、ビルドに成功しています。
[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]]$ 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"
最後に、Linux カーネルイメージを作ります。
[ATDE ~]$ cd imx-boot-[VERSION]
[ATDE ~/imx-boot-[VERSION]]$ ./secureboot.sh linux
ビルド後に以下のイメージがあれば成功です。
[ATDE ~/imx-boot-[VERSION]]$ ls ../secureboot
Image.signed
まず、ルートファイルシステムに組み込むために、
署名された 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 イメージを、
製品マニュアルを参考にして SD カードに書き込んでください。
SD boot 用の SD カードの作成が終わったら、
次からは実際に「Armadillo-IoT ゲートウェイ G4/Armadillo-X2 上の作業」を行います。
ここでは暗号化されたブートローダーによるセキュアブートを有効にする方法を
説明します。
5.6.1. uboot-imx の暗号化セキュアブートの実装仕様
暗号化セキュアブートは uboot-imx の Encrypted boot で実現しています。
実装仕様は uboot-imx のガイドに準拠しています。
詳しい仕様は以下を参照してください。
取得したソースツリー内にドキュメントがあります。
暗号化セキュアブートのセットアップの流れは以下のとおりです。
PC 上の作業
事前準備
ビルド
Armadillo-IoT ゲートウェイG4/Armadillo-X2 上の作業
5.6.3. 署名済みの暗号化ブートローダーの作成
セキュアブートと暗号化に対応したブートローダーをビルドします。
製品マニュアルを参考にビルドしてください。
以下のファイルが作られていれば、ビルドに成功しています。
[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"
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"
![[ティップ]](images/tip.png) | |
|---|
desc ファイル SWUpdate ではファームウェアアップデート処理中にユーザー定義の追加処理を
行うことが可能です。
ユーザー定義の追加処理は desc ファイルに記述します。
desc ファイルは独自のシンタックスをもつアットマークテクノ製ツール (mkswu) 用の
スクリプトファイルです。Armadillo Base OS に最適化されています。
mkswu パッケージのインストール先に desc ファイルの例があります。 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 は暗号化セキュアブート専用になります。
この手順以外では基本的には利用できません。
誤って書き込まないようご注意ください。 |
まず、ルートファイルシステムに組み込むために、
署名された 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 イメージを、
製品マニュアルを参考にして SD カードに書き込んでください。
SD boot 用の SD カードの作成が終わったら、
次からは実際に「Armadillo-IoT ゲートウェイ G4/Armadillo-X2 上の作業」を行います。
ここではストレージを暗号化する方法を説明します。
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 ではストレージの２つの領域の暗号化をサポートします。
-
アプリケーションを配置するコンテナのファイルシステム
-
Armadioo Base OS のルートファイルシステム
build-rootfs のスクリプト (build_image.sh) では、
1 (USERFS) か 1+2 (ALL) の設定が可能です。
ストレージ暗号化のセットアップの流れは以下のとおりです。
PC 上の作業
事前準備
ビルド
Armadillo-IoT ゲートウェイG4/Armadillo-X2 上の作業
セキュアブートと暗号化に対応したブートローダーをビルドします。
製品マニュアルを参考にビルドしてください。
以下のファイルが作られていれば、ビルドに成功しています。
[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.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 --lock
| |
|---|
build-rootfs バージョン 3.19-at.2 以降では --lock を使う場合にこの initrd で以下の制限が入ります： -
エラーの場合に shell を提供しない。
-
eMMC 以外では起動できない。
-
暗号化されている rootfs 以外では起動できない。
SD カードなどでも使う場合にロックせずにビルドしてください。 |
以下のファイルがあれば 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"
最後に、Linux カーネルイメージを作ります。
[ATDE ~]$ cd imx-boot-[VERSION]
[ATDE ~/imx-boot-[VERSION]]$ ./secureboot.sh linux
ビルド後に以下のイメージが更新されていれば成功です。
[ATDE ~/imx-boot-[VERSION]]$ ls ../secureboot
Image.signed
ストレージ暗号化対応の 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 のシンタックスの詳細仕様は製品マニュアルを参照してください。 |
実際に 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 はストレージ暗号化専用になります。
この手順以外では基本的には利用できません。
誤って書き込まないようご注意ください。 |
まず、ルートファイルシステムに組み込むために、
署名された 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
| |
|---|
ストレージの暗号化を行う範囲は２通り選択可能です。 --encrypt オプション -
userfs : アプリケーション領域
-
all : アプリケーション領域と Linux rootfs 領域
|
以下のファイルができていれば成功です。ファイルに含まれる日付やバージョンは
変化します。
[ATDE ~/build-rootfs-[VERSION]]$ ls
baseos-[VERSION].[DATE]-installer.img
上記で作成した SD boot イメージを、
製品マニュアルを参考にして SD カードに書き込んでください。
SD boot 用の SD カードの作成が終わったら、
次からは実際に「Armadillo-IoT ゲートウェイ G4/Armadillo-X2 上の作業」を行います。
5.8. Armadillo-IoT ゲートウェイ G4/Armadillo-X2 上の作業
以下は作業の流れです。
セキュアブート、暗号化セキュアブート、ストレージの暗号化で共通の作業になります。
以降はアップデート処理によって自動的にセットアップが行われます。
5.8.1. Armadillo-IoT ゲートウェイ G4/Armadillo-X2 の準備
Armadillo IoT G4/Armadillo-X2 の電源を投入する前に 以下の作業を行ってください。
-
CON1(SD インターフェース)に作った SD カードを挿入する
-
JP1 ジャンパーをショート(SD ブートに設定)します。
また、minicom などのシリアル通信ソフトウェアを起動して、デバッグ入出力を
受け付けられるようにしておいてください。
電源を投入するとすぐに以下のように 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
![[注意]](images/caution.png) | |
|---|
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!
| |
|---|
問題が発生した場合 原理確認などを行っているケースでは作業内容に何かしらの問題がある
可能性があります。ログで今までの作業内容を見直してください。
製造ラインなどで同じ作業を繰り返しているケースでは問題は発生しないはずですが、
個体不良の解析のためにここでチェックすることをお勧めします。 |
SRK ハッシュを書いただけでは署名確認に失敗しても起動自体は継続されます。
close 処理を行うことで署名確認に失敗すると起動に失敗するようになります。
| |
|---|
開発フェーズなどでセキュアブート処理を確認する場合は、
この close 処理をスキップすることをすることをお勧めします。 |
| |
|---|
i.MX 8M plus 内にある SNVS (Secure Non-Volatile Storage) で利用される鍵は、
close 処理をしないとテスト用の鍵が使われます。
テスト用の鍵はデバイス間で共通なため、そのままでは簡単に復号できてしまいます。
close 処理を行うことで、デバイスに固有な鍵を利用するようになります。 |
close 処理は以下のコマンドで efuse を書き込むことで行います。
u-boot=> fuse prog -y 1 3 0x2000000
次に、アップデート作業をはじめるためにリセットします。
今後の作業は全て自動的に行われます。
u-boot=> reset
以下のログが表示されたら、電源が入った状態で JP1 ジャンパーをショート
(SD ブートに設定)を解除してください。
mkfs.fat 4.2 (2021-01-31)
Finished writing mmc. powering off now
最終的に Linux のログインプロンプトが表示できたら作業は完了です。
万が一、電源断などで作業が中断してしまった場合に作業を完了させる方法に
ついて説明します。
まず、電源を切った状態で 「Armadillo-IoT ゲートウェイ G4/Armadillo-X2 の準備」 が維持されていること
を確認してください。そのうえで、状況に応じて以下の作業を行ってください。
-
SRK ハッシュを書いていない場合は、「SRK ハッシュの書き込み」
から作業をやり直します
-
close 処理を完了していない場合は、SRK ハッシュの書き込みをスキップしてください
-
ファームウェアの書き込みが完了していない場合は、SRK ハッシュの書き込みと
close 処理をスキップします。
具体的な手順としては、電源を投入した直後 (だいたい数秒後) に電源が入った状態で
JP1 ジャンパーのショートを解除して、処理が完了するのを待ってください
最終的に立ち上がってきたら、次の動作確認に進んでください。
ストレージの暗号化が成功したかどうかは、
Armadillo IoT G4/Armadillo-X2 上で以下のコマンドを実行することで確認できます。
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_readonlyLinux カーネルが立ち上がることを確認してください。
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
HAB Configuration: 0xcc, HAB State: 0x99
No HAB Events Found!
## Flattened Device Tree blob at 45000000
Booting using the fdt blob at 0x45000000
Using Device Tree in place at 0000000045000000, end 0000000045010111
Starting kernel ...
: (省略)
|
セキュアブートが有効な場合に表示されます
|
|
問題がない場合はイベントが表示されません
|
ブートローダーに問題がある場合の起動ログ
: (省略)
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
: (省略)
|
認証に失敗しています
|
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. セットアップ完了後のアップデートの運用について
コンテナ内のアプリケーションのアップデートはセットアップとは関係なく、
とくに特別な対応なしで通常どおりの方法でアップデートが可能です。
製品マニュアルを参考にしてください。
ブートローダーや 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
