From d4af4f1a9c25ae8ae4eb42b0c50081800dde8a33 Mon Sep 17 00:00:00 2001 From: Masaki Iwai Date: Mon, 19 May 2025 10:20:26 +0900 Subject: [PATCH] [JA] added appendix1-13 --- wolfBoot/mkdocs-ja.yml | 15 ++- wolfBoot/src-ja/appendix01.md | 49 +++++++ wolfBoot/src-ja/appendix02.md | 95 ++++++++++++++ wolfBoot/src-ja/appendix03.md | 187 +++++++++++++++++++++++++++ wolfBoot/src-ja/appendix04.md | 179 ++++++++++++++++++++++++++ wolfBoot/src-ja/appendix05.md | 101 +++++++++++++++ wolfBoot/src-ja/appendix06.md | 31 +++++ wolfBoot/src-ja/appendix07.md | 79 ++++++++++++ wolfBoot/src-ja/appendix08.md | 149 +++++++++++++++++++++ wolfBoot/src-ja/appendix09.md | 38 ++++++ wolfBoot/src-ja/appendix10.md | 186 +++++++++++++++++++++++++++ wolfBoot/src-ja/appendix11.md | 236 ++++++++++++++++++++++++++++++++++ wolfBoot/src-ja/appendix12.md | 219 +++++++++++++++++++++++++++++++ wolfBoot/src-ja/appendix13.md | 228 ++++++++++++++++++++++++++++++++ wolfBoot/src-ja/chapter02.md | 2 +- 15 files changed, 1792 insertions(+), 2 deletions(-) diff --git a/wolfBoot/mkdocs-ja.yml b/wolfBoot/mkdocs-ja.yml index 5261601a..e066ab5e 100644 --- a/wolfBoot/mkdocs-ja.yml +++ b/wolfBoot/mkdocs-ja.yml @@ -12,7 +12,20 @@ nav: - "6. wolfBootの機能": chapter06.md - "7. wolfBootの既存プロジェクトへの統合": chapter07.md - "8. トラブルシューティング": chapter08.md - - "A. コンフィギュレーションオプション": appendix14.md + - "A. ATAセキュリティ": appendix01.md + - "B. Microsoft Azure Key Vaultを使用したファームウェアの署名": appendix02.md + - "C. One Time Programmable (OTP) フラッシュ領域を鍵ストアとして使用": appendix03.md + - "D. KeyStore構造：複数の公開鍵のサポート": appendix04.md + - "E. wolfBootをライブラリとしてビルド": appendix05.md + - "F. wolfBootローダー/アップデーター": appendix06.md + - "G. wolfBootを使用したMeasured Boot": appendix07.md + - "H. ポスト量子署名": appendix08.md + - "I. UARTを介したリモート外部フラッシュメモリのサポート": appendix09.md + - "J. Renesas製品におけるwolfBootの使用": appendix10.md + - "K. wolfBoot鍵ツール": appendix11.md + - "L. TrustZone-MセキュアドメインにおけるwolfCrypt": appendix12.md + - "M. wolfBoot TPMサポート": appendix13.md + - "N. コンフィギュレーションオプション": appendix14.md theme: name: null custom_dir: ../mkdocs-material/material diff --git a/wolfBoot/src-ja/appendix01.md b/wolfBoot/src-ja/appendix01.md index e69de29b..ab5a25e2 100644 --- a/wolfBoot/src-ja/appendix01.md +++ b/wolfBoot/src-ja/appendix01.md @@ -0,0 +1,49 @@ +# ATAセキュリティ + +## はじめに + +この文書は、wolfBootがATAセキュリティ機能を活用してATAドライブをロックまたはアンロックする方法の概要を提供します。 +ATAドライブは、ハードコードされたパスワードを使用するか、TPMに封印された秘密を使用してロックできます。 + +## 目次 + +- ハードコードされたパスワードでディスクをアンロックする +- TPMに封印された秘密でディスクをアンロックする +- パスワードを無効にする + +## ハードコードされたパスワードでディスクをアンロックする + +ハードコードされたパスワードを使用してディスクをアンロックするには、`.config`ファイルで次のオプションを使用します。 + +``` +DISK_LOCK=1 +DISK_LOCK_PASSWORD=hardcoded_password +``` + +ATAディスクにパスワードが設定されていない場合、最初の起動時に提供されたパスワードでディスクがロックされます。 + +## TPMに封印された秘密でディスクをアンロックする + +wolfBootは、特定の条件下でのみ解除できる方法でTPMに秘密を安全に封印できます。 +詳細については、[付録M](appendix13.md)と[付録G](appendix07.md)を参照してください。 +オプション`WOLFBOOT_TPM_SEAL`と`DISK_LOCK`が有効になっている場合、wolfBootはディスクのロック解除のためのパスワードとしてTPMに封印された秘密を使用します。 +以下のオプションは、秘密の封印と解除を制御します。 + +| オプション | 説明 | +|-----------|----------| +| WOLFBOOT_TPM_SEAL_KEY_ID| ポリシーに署名するために使用する鍵ID | +| ATA_UNLOCK_DISK_KEY_NV_INDEX | 封印された秘密を保存するNVインデックス | +| WOLFBOOT_DEBUG_REMOVE_SEALED_ON_ERROR| エラーの場合、秘密を削除し`panic()`する | + +`ATA_UNLOCK_DISK_KEY_NV_INDEX`に封印された秘密がない場合、新しいランダムな秘密が作成され、そのインデックスに封印されます。 +ATAドライブがロックされていない場合、最初の起動時にTPMに封印された秘密でロックされます。 + +## パスワードを無効にする + +パスワードを無効にする必要がある場合、デバイスにはすでにマスターパスワードが設定されている必要があります。 +その後、次のオプションを使用してwolfBootをコンパイルすることで、ドライブからパスワードを無効にしてpanicさせることができます。 + +``` +WOLFBOOT_ATA_DISABLE_USER_PASSWORD=1 +ATA_MASTER_PASSWORD=the_master_password +``` diff --git a/wolfBoot/src-ja/appendix02.md b/wolfBoot/src-ja/appendix02.md index e69de29b..12f1ccd6 100644 --- a/wolfBoot/src-ja/appendix02.md +++ b/wolfBoot/src-ja/appendix02.md @@ -0,0 +1,95 @@ +# Microsoft Azure Key Vaultを使用したファームウェアの署名 + +Microsoftは、HSMに保存された鍵を使用して安全な鍵管理およびプロビジョニングツールを提供しています。 +このメカニズムは、管理された鍵を使用したペイロードの署名のサポートを含む複数の目的のための鍵管理を一元化するのに役立ちます。 +これはwolfBootと組み合わせて、デバイスのフリートに公開鍵をプロビジョニングするために使用できます。 + +## 鍵ストアの準備 + +wolfBootは提供される`keygen`コマンドラインツールを使用して、鍵ストアに公開鍵をインポートできます。 +`keygen`は生のECC鍵とASN.1形式（.der）の両方をサポートしています。 + +Azureでは、デバイスをプロビジョニングするためにASN.1形式で公開鍵をダウンロードできます。 +wolfBootでのファームウェア認証に使用する各公開鍵を取得するには、以下を使用します。 + +```sh +az keyvault key download --vault-name -n test-signing-key-1 -e DER -f public-key-1.der +``` + +鍵ストアは、`keygen`の`-i`（インポート）オプションを使用して公開鍵をインポートして作成できます。 +このオプションは、鍵ストアにさらに多くの鍵を追加するために複数回繰り返すことができます。 + +```sh +./tools/keytools/keygen --ecc256 -i public-key-1.der [-i public-key-2.der ...] +``` + +## wolfBoot用のファームウェアイメージの署名 + +任意の外部HSMを使用した署名操作は、[付録B](appendix02.md)の関連セクションに記載されているように、3つのステップで実行されます。 +このセクションでは、Azure Key Vaultを使用してファームウェアイメージに署名する手順について説明します。 + +### SHA256ダイジェストの取得 + +ステップ1では、`--sha-only`引数を加えて`./sign`ツールを呼び出し、署名するダイジェストを生成します。 +Vault内で選択した署名鍵に関連付けられた公開鍵を提供する必要があります。 + +```sh +./tools/keytools/sign --ecc256 --sha-only --sha256 test-app/image.bin public-key-1.der 1 +``` + +https RESTリクエストに適合させるために、取得したダイジェストはbase64を使用してエンコードする必要があります。 + +```sh +DIGEST=$(cat test-app/image_v1_digest.bin | base64url_encode) +``` + +変数`DIGEST`には、リクエストに添付できる鍵の印刷可能なエンコーディングが保存されています。 + +### Key Vaultを使用してダイジェストに署名するためのHTTPSリクエスト + +リクエストを準備するために、まずVaultからアクセストークンを取得し、変数に保存します。 + +```sh +ACCESS_TOKEN=$(az account get-access-token --resource "https://vault.azure.net" --query "accessToken" -o tsv) +``` + +選択したKey Vaultに関連付けられたURLを使用します。 + +```sh +KEY_IDENTIFIER="https://.vault.azure.net/keys/test-signing-key" +``` + +cURLを使用してリクエストを実行し、結果を変数に保存します。 + +```sh +SIGNING_RESULT=$(curl -X POST \ + -s "${KEY_IDENTIFIER}/sign?api-version=7.4" \ + -H "Authorization: Bearer ${ACCESS_TOKEN}" \ + -H "Content-Type:application/json" \ + -H "Accept:application/json" \ + -d "{\"alg\":\"ES256\",\"value\":\"${DIGEST}\"}") +echo $SIGNING_RESULT +``` + +結果の`.value`フィールドには（base64でエンコードされた）署名が含まれています。 +レスポンスから署名を抽出するには、JSONパーサーを使用できます。 + +```sh +SIGNATURE=$(jq -jn "$SIGNING_RESULT|.value") +``` + +署名はbase64からバイナリにデコードできるようになり、`sign`ツールはその署名をマニフェストヘッダーに組み込むことができます。 + +```sh +echo $SIGNATURE| base64url_decode > test-app/image_v1_digest.sig +``` + +### 最終ステップ：署名されたファームウェアイメージの作成 + +HSM 3ステップの第3段階では、`--manual-sign`オプションとAzure REST APIを通じて取得した署名が必要です。 + +```sh +./tools/keytools/sign --ecc256 --sha256 --manual-sign test-app/image.bin test-signin-key_pub.der 1 test-app/image_v1_digest.sig +``` + +結果のバイナリファイル`image_v1_signed.bin`には、wolfBootによって認証およびステージングできる署名付きファームウェアイメージが保存されます。 diff --git a/wolfBoot/src-ja/appendix03.md b/wolfBoot/src-ja/appendix03.md index e69de29b..bc70dc20 100644 --- a/wolfBoot/src-ja/appendix03.md +++ b/wolfBoot/src-ja/appendix03.md @@ -0,0 +1,187 @@ +# One Time Programmable (OTP) フラッシュ領域を鍵ストアとして使用 + +一部のマイクロコントローラーは、一度だけ書き込みが可能で消去できないフラッシュメモリの特別な領域を提供しています。 + +この機能は、ファームウェア更新イメージを認証するために必要な公開鍵を保存する場合に特に便利です。 +公開鍵は自由に配布できる暗号鍵であり、ファームウェア更新イメージの署名を検証するために使用されます。 +公開鍵をOTP領域に保存することで、それらが不変であり改ざんできないことを保証できます。 + +## OTPを鍵ストアとしてアクセスするためのwolfBootのコンパイル + +OTP領域を鍵ストアとして使用するには、`FLASH_OTP_KEYSTORE`オプションを有効にしてwolfBootをコンパイルする必要があります。 +このオプションはデフォルトでは無効であり、鍵ストアはwolfBootバイナリ自体に組み込まれています。 + +wolfBootがOTP領域を鍵ストアとして使用する場合、実行時にOTP領域から公開鍵を読み取ります。 +公開鍵は、格納されている鍵の数、各鍵のサイズ、その他の情報を含む最初の16バイトヘッダーの後にOTP領域に格納されます。 + +wolfBootが起動時や更新時にファームウェアイメージの認証を開始するためには、次のセクションで説明するように、公開鍵を別のステップでOTP領域にプロビジョニングする必要があります。 + +ターゲットデバイスに応じて、OTP領域コンテンツのバイナリイメージを準備するか、`otp-keystore-primer`ファームウェアを使用してターゲットに直接鍵をプロビジョニングできます。 + +## OTP領域コンテンツのイメージの作成 + +OTP領域のコンテンツのバイナリイメージを作成できます。 +結果のファイル（`otp.bin`）は、ターゲットOTP領域への書き込みを可能にする任意の外部ツールを使用して手動でプロビジョニングできます。 + +現在の鍵ストアコンテンツを使用してotp-keystore-genツールをコンパイルするには、次のようにします。 + +```sh +make otpgen +``` + +そして、イメージファイル`otp.bin`を作成するには、次のようにします。 + +```sh +./tools/keytools/otp/otp-keystore-gen +``` + +## OTP領域への公開鍵の直接プロビジョニング（プライマー） + +`.config`ファイルで`FLASH_OTP_KEYSTORE`オプションを有効にした後、「`make`」を実行してwolfBootをコンパイルすると、`tools/keytools/otp`の下に`otp-keystore-primer`という追加アプリケーションが生成されます。 +このアプリケーションはOTP領域に公開鍵をプロビジョニングするために使用されます。 +このアプリケーションをマイクロコントローラーにフラッシュすることで、鍵ストア（以前に`keygen`によって生成された）に含まれる公開鍵がOTP領域に書き込まれます。 + +`otp-keystore-primer`アプリケーションは埋め込まれた公開鍵で生成されます。 +鍵は`keygen`コマンドによって生成された`keystore.c`ファイルから取得されます。 +`otp-keystore-primer`アプリケーションは`keystore.c`ファイルから公開鍵を読み取り、OTP領域に書き込みます。 + +`keygen`アプリケーションで新しい`keystore.c`を生成した後、`make otp`を実行することで、`otp-keystore-primer`アプリケーションを再度生成できます。 + +> [!警告] +> `otp-keystore-primer`アプリケーションは一回限りのアプリケーションです。アプリケーションがターゲットで実行されると、公開鍵がOTP領域に書き込まれ、それらを消去することは不可能になります。したがって、公開鍵をOTP領域にプロビジョニングする前に、公開鍵が正しいことを確認し、関連する秘密鍵が安全に保存されていることを確認することが重要です。誤って秘密鍵を紛失すると、OTP領域に保存されている公開鍵は使用できなくなります。 + +> [!注意] +> **`otp-keystore-primer`アプリケーションを使用する際は十分注意してください。ご自身の責任で使用してください。** + +## 例 + +### STM32H5 OTP KeyStore + +NULCLEO-STM32H563ZI（TrustZone（PKCS11経由）、DualBank、PQ LMSによる署名）の場合 + +1) 設定と鍵ツールをセットアップする + +```sh +cp config/examples/stm32h5-tz-dualbank-otp-lms.config .config +make include/target.h +make keytools +``` + +2) OTPに書き込む鍵を生成する + + - `./examples/keytools/keygen --lms -g 1.key -g 2.key -g 3.key -g 4.key -g 5.key` + +3) 生成された鍵と`src/keystore.c`をバックアップする + + - wolfBootツリー外の安全な場所に保存する + +4) 使用する署名鍵を設定する + + - 生成された鍵の1つを`wolfboot_signing_private_key.der`にコピーする + - `cp 1.key wolfboot_signing_private_key.der` + +5) OTP鍵ストアをセットアップする + + OTP鍵ストアプライマーをフラッシュする + + - `make otp`を実行する + - `./tools/keytools/otp/otp-keystore-primer.bin`を`0x08000000`にフラッシュする + - ツールを切断してリセットボタンを押す + - プライマーが実行され、keystore.cをOTPにフラッシュし、それらのブロックに書き込み保護を有効にする + + または + + 外部ツールを使用してOTP（otp.bin）を生成してフラッシュする + + - `make otpgen`を実行する + - `./tools/keytools/otp/otp-keystore-gen`を実行してotp.binファイルを生成する + - STM32CubeProgrammerなどの外部ツールを使用してotp.binを`0x08FFF000`にプログラムする + +6) OTP鍵ストアを検証する + + - アドレス`0x08FFF000`のメモリを読み取る（ASCII「`WOLFBOOT`」で始まるはずです） + - 通常はSTM32CubeProgrammerを使用する + +7) オプションバイトを設定する + + - ユーザー構成2 -> TrustZone有効（TZEN=0xB4） + - Bank1 - フラッシュウォーターマークエリア（`SECWM1_START=0x00`、`SECWM1_END=0x1F`） + - Bank2 - フラッシュウォーターマークエリア（`SECWM2_START=0x00`、`SECWM2_END=0x1F`） + +8) デバイスの一括消去 + + - STM32CubeProgrammer -> フルチップ消去 + +9) `make`を使用してwolfBootとテストアプリケーションをビルドする + +10) wolfBootとtest-appをフラッシュする + +- `wolfboot.bin`を`0x0C000000`にフラッシュする +- `test-app/image_v1_signed.bin`を`0x08040000`にフラッシュする + +11) 切断して再起動すると、赤色LEDが点灯するはず。 + +12) コンソール用にNUCLEOボード上のUSB UARTに接続する + +コマンドラインを探索する（helpを実行） + +```sh +======================== +STM32H5 wolfBoot demo Application +Copyright 2024 wolfSSL Inc +GPL v3 +Version : 0x1 +======================== + +cmd> help +help : shows this help message +info : display information about the system and partitions +success : confirm a successful update +pkcs11 : enable and test crypto calls with PKCS11 in secure mode +random : generate a random number +timestamp : print the current timestamp +benchmark : run the wolfCrypt benchmark +test : run the wolfCrypt test +update : update the firmware via XMODEM +reboot : reboot the system +``` + +13) 更新をテストする + + - ファームウェアの新しいバージョンに署名する：`./tools/keytools/sign --lms test-app/image.bin wolfboot_signing_private_key.der 2` + - シェルで「update」コマンドを実行し、xmodem転送を待つ + - 「minicom」や「CoolTerm」などのxmodemをサポートするシリアルターミナルを使用する。 + * `/dev/ttyACM0`で`minicom`を実行し、「CTRL+A; S」を使用してファイル転送を開始する + * xmodemを選択し、新しい署名付きファームウェアファイル`test-app/image_v2_signed.bin`に移動する + - 転送中、黄色のLEDが点滅する。 + - 緑色のLEDはUART RXと同期しているため薄暗い + - 転送の終わりに、新しいイメージが更新パーティションに配置される。 + - ボードをリセットして新しいファームウェアをインストールし、新しいバージョン番号を確認する。 + +更新出力の例： + +```sh +cmd> update +Erasing update partition...Done. +Waiting for XMODEM transfer... +................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................. + + + + +End of transfer. ret: 0 +New firmware version: 0x2 +Triggering update... +Update completed successfully. + +cmd> reboot + +======================== +STM32H5 wolfBoot demo Application +Copyright 2024 wolfSSL Inc +GPL v3 +Version : 0x2 +======================== + +cmd> +``` diff --git a/wolfBoot/src-ja/appendix04.md b/wolfBoot/src-ja/appendix04.md index e69de29b..79b15ac9 100644 --- a/wolfBoot/src-ja/appendix04.md +++ b/wolfBoot/src-ja/appendix04.md @@ -0,0 +1,179 @@ +# KeyStore構造：複数の公開鍵のサポート + +## wolfBoot KeyStoreとは + +KeyStoreは、現在のファームウェアと更新の署名を認証するためにwolfBootが使用する、すべての公開鍵を格納するメカニズムです。 + +wolfBootの鍵生成ツールは1つまたは複数の鍵を生成するために使用できます。 +デフォルトでは、初めて`make`を実行すると、単一の鍵`wolfboot_signing_private_key.der`が作成され、鍵ストアモジュールに追加されます。 +この鍵は、ターゲット上で実行されるファームウェアだけでなく、ファームウェア更新バイナリにも署名するために使用する必要があります。 + +さらに、`keygen`ツールは鍵ストアの異なる表現を含む追加ファイルを作成します。 + +- .cファイル（`src/keystore.c`）：鍵ストアを`wolfboot.elf`にリンクすることで、ブートローダー自体の一部として公開鍵をデプロイするために使用できます。 +- .binファイル（`keystore.bin`）：カスタムメモリサポートでホストできる鍵ストアを含みます。鍵ストアにアクセスするには、小さなドライバーが必要です（以下の「インターフェースAPI」セクションを参照）。 + +## デフォルトの使用法（組み込み鍵ストア） + +デフォルトでは、`src/keystore.c`の鍵ストアオブジェクトは、そのシンボルをビルドに含めることでwolfBootによってアクセスされます。 +生成されると、このファイルには、ターゲットシステム上のwolfBootで利用できる各公開鍵を記述する構造体の配列が含まれます。 +さらに、公開鍵スロットの詳細と内容にアクセスするためのwolfBoot鍵ストアAPIに接続するいくつかの関数があります。 + +公開鍵は次の構造体によって記述されます。 + +```c +struct keystore_slot { + uint32_t slot_id; + uint32_t key_type; + uint32_t part_id_mask; + uint32_t pubkey_size; + uint8_t pubkey[KEYSTORE_PUBKEY_SIZE]; +}; +``` + +- `slot_id`は、0から始まる鍵スロットの増分識別子です。 +- `key_type`は、鍵のアルゴリズム（例：`AUTH_KEY_ECC256`または`AUTH_KEY_RSA3072`）を記述します。 +- `mask`は、鍵の権限を記述します。これは、この鍵を検証に使用できるパーティションIDのビットマップです。 +- `pubkey_size`は公開鍵バッファのサイズです。 +- `pubkey`は、生の形式で公開鍵を含む実際のバッファです。 + +起動時、wolfBootは署名されたファームウェアイメージに関連付けられた公開鍵を自動的に選択し、検証が実行されているパーティションIDのアクセス許可マスクと一致することを確認してから、選択された公開鍵スロットを使用してイメージの署名を認証しようとします。 + +### 複数の鍵の作成 + +`keygen`は秘密鍵の複数のファイル名を受け入れます。 + +2種類の引数が用意されています。 + +- `-g priv.der` 新しい鍵ペアを生成し、秘密鍵をpriv.derに保存し、公開鍵を鍵ストアに追加します +- `-i pub.der` 既存の公開鍵をインポートして鍵ストアに追加します + +2つのED25519鍵を持つ鍵ストアを作成する場合、次のように実行します。 + +`./tools/keytools/keygen --ed25519 -g first.der -g second.der` + +これにより、以下のファイルが作成されます。 + +- `first.der` 最初の秘密鍵 +- `second.der` 2番目の秘密鍵 +- `src/keystore.c` `first.der`と`second.der`に関連付けられた両方の公開鍵を含むC鍵ストア + +生成された`keystore.c`は次のようになります。 + +```c +#define NUM_PUBKEYS 2 +const struct keystore_slot PubKeys[NUM_PUBKEYS] = { + + /* Key associated to private key 'first.der' */ + { + .slot_id = 0, + .key_type = AUTH_KEY_ED25519, + .part_id_mask = KEY_VERIFY_ALL, + .pubkey_size = KEYSTORE_PUBKEY_SIZE_ED25519, + .pubkey = { + 0x21, 0x7B, 0x8E, 0x64, 0x4A, 0xB7, 0xF2, 0x2F, + 0x22, 0x5E, 0x9A, 0xC9, 0x86, 0xDF, 0x42, 0x14, + 0xA0, 0x40, 0x2C, 0x52, 0x32, 0x2C, 0xF8, 0x9C, + 0x6E, 0xB8, 0xC8, 0x74, 0xFA, 0xA5, 0x24, 0x84 + }, + }, + + /* Key associated to private key 'second.der' */ + { + .slot_id = 1, + .key_type = AUTH_KEY_ED25519, + .part_id_mask = KEY_VERIFY_ALL, + .pubkey_size = KEYSTORE_PUBKEY_SIZE_ED25519, + .pubkey = { + 0x41, 0xC8, 0xB6, 0x6C, 0xB5, 0x4C, 0x8E, 0xA4, + 0xA7, 0x15, 0x40, 0x99, 0x8E, 0x6F, 0xD9, 0xCF, + 0x00, 0xD0, 0x86, 0xB0, 0x0F, 0xF4, 0xA8, 0xAB, + 0xA3, 0x35, 0x40, 0x26, 0xAB, 0xA0, 0x2A, 0xD5 + }, + }, + + +}; +``` + +### 権限 + +デフォルトでは、新しい鍵ストアが作成されると、アクセス許可マスクは`KEY_VERIFY_ALL`に設定されます。 +これは、任意のパーティションIDをターゲットとするファームウェアを検証するために鍵を使用できることを意味します。 + +`part_id_mask`値はビットマスクであり、各ビットは異なるパーティションを表します。 +ビット「0」はwolfBootの自己更新用に予約されている一方、通常、メインファームウェアパーティションはID 1に関連付けられているため、ビット「1」が設定された鍵が必要です。 +つまり、`--id 3`でパーティションに署名するには、マスクでビット「3」をオンにする、つまり（1U << 3）を追加する必要があります。 + +単一の鍵のアクセス許可を制限するには、各鍵の`part_id_mask`の値を変更するだけで十分です。 +これは、keygen用の`--id`コマンドラインオプションを通じて行われます。 +生成またはインポートされた各鍵は、パーティションIDをカンマ区切りのリストで渡すことにより、複数のパーティションと関連付けることができます。 + +使用例 + +```sh +keygen --ecc256 -g generic.key --id 1,2,3 -g restricted.key +``` + +2つの鍵ペア、`generic.key`と`restricted.key`を生成します。 +前者はデフォルトのマスク`KEY_VERIFY_ALL`を想定しており、システムコンポーネントのいずれかを認証するために使用することが可能です。 +後者は代わりに、ビット「1」、「2」、および「3」だけがセットされたマスク（mask = b00001110 =0x000e）を持ち、割り当てられたパーティションIDでのみ使用を許可します。 + +### 公開鍵のインポート + +`-i`オプションは、既存の公開鍵を鍵Vaultにインポートするために使用されます。 +使用法は `-g` オプションと同じですが、提供されるファイルが存在し、指定されたアルゴリズムと鍵サイズの有効な公開鍵を含んでいる必要があります。 + +### 異なるタイプの鍵の生成とインポート + +デフォルトでは、wolfBootはすべての署名検証操作に使用される鍵のタイプを鍵ストア形式にハードコードします。 + +あるいは、wolfBootは`WOLFBOOT_UNIVERSAL_KEYSTORE=1`オプションでコンパイルすることもできます。 +これはコンパイル時のチェックを無効にし、異なるタイプの鍵を鍵ストアに追加することを可能にします。 +例えば、異なるECC曲線を持つ2つの鍵ペアを作成し、さらに既存のRSA2048公開鍵ファイル`rsa-pub.der`を保存したい場合、次のように実行します。 + +```sh +keygen --ecc256 -g a.key --ecc384 -g b.key --rsa2048 -i rsa-pub.der +``` + +上記のコマンドは、実行時にブートローダーがアクセスできる3つの公開鍵を持つ鍵ストアを生成します。 + +デフォルトでは、wolfBootは`SIGN=`オプションで選択されたもの以外の公開鍵アルゴリズム実装を含まないことに注意してください。 +そのため、通常この機能は、Root of Trust内の他のポリシーやコンポーネントが、異なる目的のために異なる鍵タイプを保存する必要がある特定のユースケースに限定されます。 + +## 外部鍵VaultでのKeyStoreの使用 + +外部NVM、鍵Vault、または任意の一般的なサポートを使用してKeyStoreにアクセスすることが可能です。 +この場合、wolfBootは生成された`keystore.c`を直接リンクするのではなく、`keystore.c`によって実装されるのと同じAPIを、エクスポートする外部インターフェイスに依存することになります。 + +APIは、以下に説明するいくつかの関数で構成しています。 + +### インターフェースAPI + +#### 鍵ストア内の鍵の数 + +`int keystore_num_pubkeys(void)` + +鍵ストア内のスロットの数を返します。 +今日ファームウェアを認証したい場合は、少なくとも1つのスロットが配置されているはずです。 +インターフェイスは、スロットが0から`keystore_num_pubkeys() - 1`まで順番に番号付けされていると想定しています。 +このAPIを通じてこれらのスロットにアクセスすると、常に有効な公開鍵が返されるはずです。 + +#### スロット内の公開鍵のサイズ + +`int keystore_get_size(int id)` + +スロット`id`に保存されている公開鍵のサイズを返します。 +エラーの場合、負の値を返します。 + +#### 実際の公開鍵バッファ（メモリにマップ/コピーされる） + +`uint8_t *keystore_get_buffer(int id)` + +スロット`id`に関連付けられた公開鍵を含むバッファを含む、メモリ内のアクセス可能な領域へのポインタを返します。 + +#### 権限マスク + +`uint32_t keystore_get_mask(int id)` + +スロット`id`に保存されている公開鍵の権限マスクを32ビットwordとして返します。 diff --git a/wolfBoot/src-ja/appendix05.md b/wolfBoot/src-ja/appendix05.md index e69de29b..d04c9bc5 100644 --- a/wolfBoot/src-ja/appendix05.md +++ b/wolfBoot/src-ja/appendix05.md @@ -0,0 +1,101 @@ +# wolfBootをライブラリとしてビルド + +wolfBootをスタンドアロンリポジトリではなくセキュアブートライブラリとしてビルドし、サードパーティのブートローダーやカスタムステージングソリューションなどに統合することもできます。 + +## ライブラリAPI + +wolfBootセキュアブートイメージ検証は非常にシンプルなインターフェースを持っています。 +イメージを記述するコアオブジェクトは`struct wolfBoot_image`であり、`wolfBoot_open_image_address()`が呼び出されるときに初期化されます。 +シグネチャは以下のとおりです。 + +`int wolfBoot_open_image_address(struct wolfBoot_image* img, uint8_t* image)` + +ここで`img`はローカルの（初期化されていない）`wolfBoot_image`型の構造体へのポインタで、`image`はマニフェストヘッダーの先頭から始まる、署名されたイメージがメモリにマップされている場所へのポインタです。 + +成功すると、ゼロが返されます。 +イメージがマニフェストの先頭に有効な「マジックナンバー」を含んでいない場合、またはイメージのサイズが`WOLFBOOT_PARTITION_SIZE`より大きい場合、`-1`が返されます。 + +`open_image_address`操作が成功した場合、他の2つの関数を呼び出すことができます。 + +- `int wolfBoot_verify_integrity(struct wolfBoot_image *img)` + +この関数は、イメージの内容のSHAハッシュを計算し、マニフェストヘッダーに保存されているダイジェストと比較することによって、イメージの整合性を検証します。 +`img`は以前に`wolfBoot_open_image_address`によって初期化された`wolfBoot_image`型のオブジェクトへのポインタです。 + +イメージの整合性が正常に検証できた場合は0が返され、そうでない場合は`-1`が返されます。 + +- `int wolfBoot_verify_authenticity(struct wolfBoot_image *img)` + +この関数は、イメージの内容が信頼できる相手によって署名されたこと（つまり、利用可能な公開鍵の1つを使用して検証できること）を確認します。 + +認証が成功した場合は`0`が返され、操作中に何か問題が発生した場合は`-1`が返され、署名が見つかったが公開鍵に対して認証できなかった場合は`-2`が返されます。 + +## ライブラリモード：サンプルアプリケーション + +サンプルアプリケーションは`hal/library.c`で提供しています。 + +アプリケーション`test-lib`はコマンドラインから引数として渡されたパスからファイルを開き、そのファイルが有効で署名されたイメージを含み、ライブラリモードでwolfBootを使用して整合性と真正性を検証できることを確認します。 + +## test-libアプリケーションの設定とコンパイル + +ステップ1：提供された設定を使用してライブラリモードでwolfBootをコンパイルします。 + +```sh +cp config/examples/library.config .config +``` + +ステップ2：次の行だけを含む`target.h`ファイルを作成します。 + +```sh +cat > include/target.h << EOF +#ifndef H_TARGETS_TARGET_ +#define H_TARGETS_TARGET_ + +#define WOLFBOOT_NO_PARTITIONS + +#define WOLFBOOT_SECTOR_SIZE 0x20000 +#define WOLFBOOT_PARTITION_SIZE 0x20000 + +#endif /* !H_TARGETS_TARGET_ */ + +EOF +``` + +`WOLFBOOT_PARTITION_SIZE`は適宜変更してください。 +`wolfBoot_open_image_address()`は`WOLFBOOT_PARTITION_SIZE` - `IMAGE_HEADER_SIZE`より大きいイメージを廃棄します。 + + +ステップ3：keytoolsをコンパイルし、鍵を作成します。 + +```sh +make keytools +./tools/keytools/keygen --ed25519 -g wolfboot_signing_private_key.der +``` + + +ステップ4：空のファイルを作成し、秘密鍵を使用して署名します。 + +```sh +touch empty +./tools/keytools/sign --ed25519 --sha256 empty wolfboot_signing_private_key.der 1 +``` + + +ステップ5：ライブラリモードのwolfBootとステップ4で作成した鍵ペアの公開鍵にリンクされたtest-libアプリケーションをコンパイルします。 + +```sh +make test-lib +``` + +ステップ6：署名されたイメージでアプリケーションを実行します。 + +```sh +./test-lib empty_v1_signed.bin +``` + +すべてがうまくいった場合、出力は次のようになるはずです。 + +```sh +Firmware Valid +booting 0x5609e3526590(actually exiting) +``` diff --git a/wolfBoot/src-ja/appendix06.md b/wolfBoot/src-ja/appendix06.md index e69de29b..eb167dd1 100644 --- a/wolfBoot/src-ja/appendix06.md +++ b/wolfBoot/src-ja/appendix06.md @@ -0,0 +1,31 @@ +# wolfBootローダー/アップデーター + +## loader.c + +wolfBootセーフブートプロセスを開始し、`*_updater.c`実装のいずれかを活用する、デフォルトのwolfBootローダーエントリーポイントです。 + +## loader_stage1.c + +wolfBootをフラッシュからRAMにロードして実行するための第一段階ローダーです。 +これは、フラッシュがメモリマップされていない（XIP）プラットフォームで必要です。 +例えば、外部NANDフラッシュが使用されるPowerPC e500v2では、ブート用に小さな4KBの領域しか利用できないため、wolfBootはRAMにロードした後に実行される必要があります。 + +例: `make WOLFBOOT_STAGE1_LOAD_ADDR=0x1000 stage1` + +* `WOLFBOOT_STAGE1_SIZE`: wolfBoot第一段階ローダーの最大サイズ +* `WOLFBOOT_STAGE1_FLASH_ADDR`: 第一段階ローダーのフラッシュ内の場所（ブートROMからXIP） +* `WOLFBOOT_STAGE1_BASE_ADDR`: 第一段階ローダーをロードするRAM内のアドレス +* `WOLFBOOT_STAGE1_LOAD_ADDR`: wolfBootをロードするRAM内のアドレス +* `WOLFBOOT_LOAD_ADDRESS`: アプリケーションパーティションをロードするRAM内のアドレス + +## update_ram.c + +RAMベースのアップデーターの実装です。 + +## update_flash.c + +フラッシュベースのアップデーターの実装です。 + +## update_flash_hwswap.c + +ハードウェア支援アップデーターの実装です。 diff --git a/wolfBoot/src-ja/appendix07.md b/wolfBoot/src-ja/appendix07.md index e69de29b..218121ce 100644 --- a/wolfBoot/src-ja/appendix07.md +++ b/wolfBoot/src-ja/appendix07.md @@ -0,0 +1,79 @@ +# wolfBootを使用したMeasured Boot + +wolfBootはTrusted Platform Module（TPM）を使用してシステムブートプロセスの状態を記録し追跡する方法として、簡略化されたMeasured Bootの実装を提供しています。 + +この記録は、Platform Configuration Register（PCR）と呼ばれるTPM内の特別なレジスタによって改ざん防止しています。 +その後、ファームウェアアプリケーション、RTOS、リッチOS（Linux）はTPMのPCRを読み取ることで、その情報のログにアクセスできます。 + +wolfBootはwolfTPMとの統合により、TPM2.0チップと疎通できます。 +wolfTPMはMicrosoft WindowsとLinuxをネイティブにサポートしており、スタンドアロンまたはwolfBootと併せて使用できます。 +wolfBootとwolfTPMの組み合わせにより、開発者はブート中およびブート後のシステム保護のための改ざん防止セキュアストレージを得ることができます。 + +## コンセプト + +一般的に、システムはセキュアブートを使用して署名を検証することで、正しく本物のファームウェアがブートされることを保証します。 +その後、この知識はシステムにとって未知のものとなります。 +アプリケーションは、システムが既知の良好な状態で起動したかどうかを知りません。 +時にはこの保証がファームウェア自体に必要です。 +そのようなメカニズムを提供するために、Measured Bootの概念が存在します。 + +Measured Bootは、設定やユーザー情報（ユーザーパーティション）を含む、あらゆるスタートアップコンポーネントをチェックするために使用できます。 +チェックの結果は、PCRと呼ばれる特別なレジスタに保存されます。 +このプロセスはPCR拡張と呼ばれ、TPM測定として参照されます。 +PCRレジスタはTPM電源投入時にのみリセットできます。 + +TPM測定があることで、WindowsやLinuxなどのファームウェアまたはオペレーティングシステム（OS）は、システム制御を獲得する前にロードされたソフトウェアが信頼でき、変更されていないことを知ることができます。 + +wolfBootでは、この概念は単一のコンポーネント、つまり主要なファームウェアイメージを測定することに簡略化しています。 +ただし、これは簡単に複数のPCRレジスタを使用して拡張できます。 + +## 設定 + +Measured Bootを有効にするには、wolfBootの設定に`MEASURED_BOOT=1`を追加します。 + +また、測定が保存されるPCR（インデックス）を選択する必要があります。 + +選択は`MEASURED_BOOT_PCR_A=[index]`設定を使用して行われます。 +この設定をwolfBootの設定に追加し、`[index]`を0から23までの数字に置き換えてください。 +以下に、PCRインデックスを選択するためのガイドラインを示します。 + +すべてのTPMには最低24のPCRレジスタがあります。 +それらの一般的な使用法は以下の通りです。 + +| インデックス | 一般的な使用法 | 推奨される使用対象 | +|----------|:-------------:|------:| +| 0 | コアRoot of Trust および/または BIOS測定 | ベアメタル、RTOS | +| 1 | プラットフォーム構成データの測定 | ベアメタル、RTOS | +| 2-3 | オプションROMコードの測定 | ベアメタル、RTOS | +| 4-5 | マスターブートレコードの測定 | ベアメタル、RTOS | +| 6 | 状態遷移 | ベアメタル、RTOS | +| 7 | ベンダー固有 | ベアメタル、RTOS | +| 8-9 | パーティション測定 | ベアメタル、RTOS | +| 10 | ブートマネージャーの測定 | ベアメタル、RTOS | +| 11 | 一般的にMicrosoft Bitlockerによって使用される | ベアメタル、RTOS | +| 12-15 | 任意の用途に利用可能 | ベアメタル、RTOS、Linux、Windows | +| 16 | デバッグ | テスト目的でのみ使用 | +| 17 | DRTM | 信頼されたブートローダー | +| 18-22 | 信頼されたOS | 信頼された実行環境（TEE） | +| 23 | アプリケーション | 一時的な測定にのみ使用 | + +PCRインデックスを選択するための推奨事項： + +- 開発中は、テスト目的のためのPCR16を使用することをお勧めします。 +- 本番環境では、ベアメタルファームウェアまたはRTOSを実行している場合、DRTM信頼されたOS（PCR17-23）を除くほとんどすべてのPCR（PCR0-15）を使用できます。 +- LinuxまたはWindowsを実行している場合、Linux IMAやMicrosoft Bitlockerなど、Linux内からPCRを使用している他のソフトウェアとの競合を避けるために、本番環境対応のファームウェアにはPCR12-15を選択できます。 + +以下は開発中のwolfBoot `.config`の一部の例です。 + +``` +MEASURED_BOOT?=1 +MEASURED_PCR_A?=16 +``` + +### コード + +wolfBootは、すぐに使える解決策を提供します。 +Measured Bootを使用するためにwolfBootコードを変更する必要は全くありません。 +コードをチェックしたい場合は、`src/image.c`、特に`measure_boot()`関数をご参照ください。 +そこには、wolfTPMへのいくつかのTPM2ネイティブAPIコールが見つかります。 +wolfTPMについての詳細情報は、[GitHubリポジトリ](https://github.com/wolfSSL/wolfTPM)に掲載しています。 diff --git a/wolfBoot/src-ja/appendix08.md b/wolfBoot/src-ja/appendix08.md index e69de29b..306dcac1 100644 --- a/wolfBoot/src-ja/appendix08.md +++ b/wolfBoot/src-ja/appendix08.md @@ -0,0 +1,149 @@ +# ポスト量子署名 + +wolfBootはポスト量子署名のサポートを追加しています。 +現在、[LMS/HSS](https://tex2e.github.io/rfc-translater/html/rfc8554.html)および[XMSS/XMSS^MT](https://tex2e.github.io/rfc-translater/html/rfc8391.html)のサポートが追加しています。 + +LMS/HSSとXMSS/XMSS^MTはどちらもポスト量子ステートフルハッシュベース署名（HBS）方式です。 +これらは小さな公開鍵、比較的高速な署名と検証操作を持ちますが、署名サイズが大きいことで知られています。 +ただし、署名サイズはそれぞれのパラメータによって調整可能であり、サイズと処理時間のトレードオフがあります。 + +ステートフルHBS方式は、基礎となるハッシュ関数とマークルツリーのセキュリティに基づいており、暗号学的に関連する量子コンピュータの出現によって破られることは予想されていません。 +このため、NIST SP 800-208とNSAのCNSA 2.0スイートの両方で推奨されています。 + +ステートフルHBSサポートとwolfSSL/wolfCryptの詳細については、以下のリンクをご参照ください。 + +- +- + +## サポートされているPQ署名方法 + +以下の4つのPQ署名オプションをサポートしています。 + +- LMS: `wc_lms.c`と`wc_lms_impl.c`によるwolfcrypt実装を使用します。 +- XMSS: `wc_xmss.c`と`wc_xmss_impl.c`によるwolfcrypt実装を使用します。 +- ext_LMS: `ext_lms.c`からの外部統合を使用します。 +- ext_XMSS: `ext_xmss.c`からの外部統合を使用します。 + +wolfcrypt実装はより高性能であり、推奨しています。 +外部統合は実験的であり、相互運用性のテスト用です。 + +### LMS/HSS設定 + +新しいLMSシミュレーションサンプルを以下に掲載しています。 + +``` +config/examples/sim-lms.config +``` + +`LMS_LEVELS`、`LMS_HEIGHT`、`LMS_WINTERNITZ`、`IMAGE_SIGNATURE_SIZE`、（オプションで）`IMAGE_HEADER_SIZE`を設定する必要があります。 + +``` +SIGN?=LMS +... +LMS_LEVELS=2 +LMS_HEIGHT=5 +LMS_WINTERNITZ=8 +... +IMAGE_SIGNATURE_SIZE=2644 +IMAGE_HEADER_SIZE?=5288 +``` + +LMSでは、署名サイズはパラメータの関数です。 +LMSパラメータに基づいて署名の長さを計算するために、追加されたヘルパースクリプト`tools/lms/lms_siglen.sh`を使用してください。 + +``` +$ ./tools/lms/lms_siglen.sh 2 5 8 +levels: 2 +height: 5 +winternitz: 8 +signature length: 2644 +``` + +### XMSS/XMSS^MT設定 + +新しいXMSSシミュレーションサンプルを以下に掲載しています。 + +``` +config/examples/sim-xmss.config +``` + +`XMSS_PARAMS`、`IMAGE_SIGNATURE_SIZE`、（オプションで）`IMAGE_HEADER_SIZE`を設定する必要があります。 + +``` +SIGN?=XMSS +... +XMSS_PARAMS='XMSS-SHA2_10_256' +... +IMAGE_SIGNATURE_SIZE=2500 +IMAGE_HEADER_SIZE?=5000 +``` + +`XMSS_PARAMS`はNIST SP 800-208の表10および11からのSHA256パラメータセット文字列であれば何でも構いません。 +XMSS/XMSS^MTパラメータ文字列に基づいて署名の長さを計算するには、ヘルパースクリプト`tools/xmss/xmss_siglen.sh`を使用してください。 + +使用例： + +``` +$ ./tools/xmss/xmss_siglen.sh XMSS-SHA2_10_256 +parameter set: XMSS-SHA2_10_256 +signature length: 2500 +``` + +``` +$ ./tools/xmss/xmss_siglen.sh XMSSMT-SHA2_20/2_256 +parameter set: XMSSMT-SHA2_20/2_256 +signature length: 4963 +``` + + +## 外部PQ統合のビルド + +### ext_LMSサポート + +wolfCryptの外部LMS/HSSサポートには、[hash-sigsライブラリ](https://github.com/cisco/hash-sigs)が必要です。 +hash-sigsをwolfBootでビルドするために準備するには、次の手順を使用します。 + +```sh +$ cd lib +$ mkdir hash-sigs +$ ls + CMakeLists.txt hash-sigs wolfssl wolfTPM +$ cd hash-sigs +$ mkdir lib +$ git clone https://github.com/cisco/hash-sigs.git src +$ cd src +$ git checkout b0631b8891295bf2929e68761205337b7c031726 +$ git apply ../../../tools/lms/0001-Patch-to-support-wolfBoot-LMS-build.patch +``` + +これ以上は必要ありません。 +wolfBootが必要なhash-sigsビルド成果物を自動的に生成します。 + +注意：hash-sigsプロジェクトは静的ライブラリのみをビルドします。 + +- `hss_verify.a`: シングルスレッドの検証専用静的ライブラリ +- `hss_lib.a`: シングルスレッドの静的ライブラリ +- `hss_lib_thread.a`: マルチスレッドの静的ライブラリ + +keytoolsユーティリティは`hss_lib.a`にリンクされており、鍵生成、署名、検証機能がすべて必要です。 +ただし、wolfBootは検証機能のみが必要なため、`hss_verify.a`ビルドルールのオブジェクトのサブセットに直接リンクされます。 + +### ext_XMSSサポート + +wolfCryptの外部XMSS/XMSS^MTサポートには、[xmss-referenceライブラリ](https://github.com/XMSS/xmss-reference.git)のパッチ適用版が必要です。 +xmss-referenceをwolfBootでビルドするために、以下の手順でご用意ください。 + +```sh +$ cd lib +$ git clone https://github.com/XMSS/xmss-reference.git xmss +$ ls +CMakeLists.txt wolfPKCS11 wolfTPM wolfssl xmss +$ cd xmss +$ git checkout 171ccbd26f098542a67eb5d2b128281c80bd71a6 +$ git apply ../../tools/xmss/0001-Patch-to-support-wolfSSL-xmss-reference-integration.patch +``` + +パッチは追加のreadme `patch_readme.md` を作成するもので、追加コメントを記載しています。 + +パッチ適用ステップ以外は何も必要ありません。 +wolfBootが必要なxmssビルド成果物を処理します。 diff --git a/wolfBoot/src-ja/appendix09.md b/wolfBoot/src-ja/appendix09.md index e69de29b..50c0b33b 100644 --- a/wolfBoot/src-ja/appendix09.md +++ b/wolfBoot/src-ja/appendix09.md @@ -0,0 +1,38 @@ +# UARTを介したリモート外部フラッシュメモリのサポート + +wolfBootはUART通信を使用して隣接システムとの外部パーティションをエミュレートできます。 +この機能は、更新を外部処理ユニットの支援によって保存できる、非同期マルチプロセスアーキテクチャにおいて特に有用です。 + +## ブートローダーのセットアップ + +この機能を有効にするオプションは`UART_FLASH=1`です。 +この構成オプションは外部フラッシュAPIに依存しており、ブートローダーをコンパイルするには`EXT_FLASH=1`オプションも必須です。 + +ターゲットシステムのHALは、シンプルなUARTドライバーを含むように拡張する必要があります。 +これはブートローダーがボード上のUARTコントローラの1つを使用してリモートフラッシュの内容にアクセスするために使用されます。 + +サポートされているいくつかのプラットフォーム用のUARTドライバーの例は、`hal/uart`ディレクトリにあります。 + +サポートされているターゲット向けのUART HAL拡張機能によって公開されるAPIは、以下の関数で構成しています。 + +```c +int uart_init(uint32_t bitrate, uint8_t data, char parity, uint8_t stop); +int uart_tx(const uint8_t c); +int uart_rx(uint8_t *c); +``` + +あなたのプラットフォームで外部フラッシュメモリサポートを使用したい場合で、まだ公式にサポートされていない場合は、提供された例に基づいてこれら3つの関数を実装することを検討してください。 + +## ホスト側：UARTフラッシュサーバー + +ターゲット用の外部パーティションイメージをホストするリモートシステム上では、UARTメッセージの上に簡単なプロトコルを実装して、フラッシュアクセス固有の呼び出しに対応できます。 + +GNU/Linuxホスト上で実行し、ファイルシステム上のローカルファイルで外部パーティションをエミュレートするように設計された例のuart-flash-serverデーモンは、`tools/uart-flash-server`で利用可能です。 + +## 外部フラッシュ更新メカニズム + +wolfBootは、外部のUPDATEおよびSWAPパーティションを、ローカルSPIフラッシュ上にマッピングされている場合と同じように扱います。 +読み取りと書き込み操作は、リモートアプリケーションによって解釈され、ホストのみがアクセス可能な実際のストレージ要素への読み取りと書き込みアクセスを提供できるUART経由のリモートプロシージャコールに単純に変換されます。 + +これは、更新が成功した後、以前のファームウェアのコピーがリモートパーティションに保存され、他のすべてのユースケースで利用可能なものと全く同じ更新メカニズムを提供することを意味します。 +唯一の違いは物理的なストレージ領域へのアクセス方法ですが、より高いレベルでのすべてのメカニズムは同じままです。 diff --git a/wolfBoot/src-ja/appendix10.md b/wolfBoot/src-ja/appendix10.md index e69de29b..017619c7 100644 --- a/wolfBoot/src-ja/appendix10.md +++ b/wolfBoot/src-ja/appendix10.md @@ -0,0 +1,186 @@ +# Renesas製品におけるwolfBootの使用 + +対応プラットフォーム： + +- Renesas RZ (RZN2L) (RSIP) + - [chapter03.md#renesas-rzn2l](chapter03.md#renesas-rzn2l) + - IDE/Renesas/e2studio/RZN2L/Readme.md + - IDE/Renesas/e2studio/RZN2L/Readme_wRSIP.md +- Renesas RA (RA6M4) (SCE) + - [chapter03.md#renesas-ra6m4](chapter03.md#renesas-ra6m4) + - IDE/Renesas/e2studio/RA6M4/Readme.md + - IDE/Renesas/e2studio/RA6M4/Readme_withSCE.md +- Renesas RX (RX65N/RX72N) (TSIP) + - [chapter03.md#renesas-rx72n](chapter03.md#renesas-rx72n) + - IDE/Renesas/e2studio/RX72N/Readme.md + - IDE/Renesas/e2studio/RX72N/Readme_withTSIP.md + +すべての実装例はe2Studioの使用をサポートしています。 +Renesas RXパーツは、rx-elf-gccクロスコンパイラと例の.configファイルを使用したwolfBoot Makefileの使用をサポートしています。 + +## セキュリティ鍵管理ツール（SKMT）鍵ラッピング + +1) Renesas鍵ラップアカウントを設定し、PGP鍵交換を行います。 + +RenesasからPGP/GPGにインポートする必要がある公開鍵「`keywrap-pub.key`」が提供されます。 + +注意：RSA 4096ビット鍵は使用できません。RSA-2048またはRSA-3072を使用する必要があります。 + +2) 「セキュリティ鍵管理ツール」を使用して32バイトのUFPK（ユーザーファクトリプログラミング鍵）を作成します。これはランダムな32バイト値でも構いません。 + +例：ランダムな32バイト `B94A2B96 1C755101 74F0C967 ECFC20B3 77C7FB25 6DB627B1 BFFADEE0 5EE98AC4` + +3) 32バイトバイナリファイルに「`sample.key`」をPGPで署名して暗号化します。結果は「`sample.key.gpg`」です。 +GPG4Winと署名/暗号化オプションを使用します。自分のGPG鍵で署名し、Renesas公開鍵で暗号化します。 + +4) を使用して「`sample.key.gpg`」をラップします。 +RenesasとRX TSIPの両方がRenesasファクトリから事前にプロビジョニングされている隠しルート鍵（HRK）を使用します。 +結果は「`sample.key_enc.key`」です。 + +例：`00000001 6CCB9A1C 8AA58883 B1CB02DE 6C37DA60 54FB94E2 06EAE720 4D9CCF4C 6EEB288C` + +## RX TSIP + +1) Renesas用の鍵ツールをビルド + +```sh +# Build keytools for Renesas RX (TSIP) +$ make keytools RENESAS_KEY=2 +``` + +2) 公開鍵を新規作成またはインポート + +以下の手順はECDSA P384（SECP384R1）用です。 +SECP256R1の場合は、「ecc384」を「ecc256」に、「secp384r1」を「secp256r1」に置き換えてください。 + +新しい署名鍵を作成： + +```sh +# Create new signing key +$ ./tools/keytools/keygen --ecc384 -g ./pri-ecc384.der +Keytype: ECC384 +Generating key (type: ECC384) +Associated key file: ./pri-ecc384.der +Partition ids mask: ffffffff +Key type : ECC384 +Public key slot: 0 +Done. + +# Export public portion of key as PEM +$ openssl ec -inform der -in ./pri-ecc384.der -pubout -out ./pub-ecc384.pem +``` + +または + +公開鍵をインポート： + +```sh +# Export public portion of key as DER +$ openssl ec -inform der -in ./pri-ecc384.der -pubout -outform der -out ./pub-ecc384.der + +# Import public key and populate src/keystore.c +$ ./tools/keytools/keygen --ecc384 -i ./pub-ecc384.der +Keytype: ECC384 +Associated key file: ./pub-ecc384.der +Partition ids mask: ffffffff +Key type : ECC384 +Public key slot: 0 +Done. +``` + +3) ラップされた公開鍵（コードファイル）の作成 + +Security Key Management Tool（SKMT）コマンドラインツール（CLI）を使用して、ラップされた公開鍵を作成します。 + +ユーザー暗号化鍵を使用して公開鍵をラップし、key_data.cとkey_data.hファイルを出力します。 + +```sh +$ C:\Renesas\SecurityKeyManagementTool\cli\skmt.exe -genkey -ufpk file=./sample.key -wufpk file=./sample.key_enc.key -key file=./pub-ecc384.pem -mcu RX-TSIP -keytype secp384r1-public -output include/key_data.c -filetype csource -keyname enc_pub_key +Output File: include\key_data.h +Output File: include\key_data.c +UFPK: B94A2B961C75510174F0C967ECFC20B377C7FB256DB627B1BFFADEE05EE98AC4 +W-UFPK: 000000016CCB9A1C8AA58883B1CB02DE6C37DA6054FB94E206EAE7204D9CCF4C6EEB288C +IV: 6C296A040EEF5EDD687E8D3D98D146D0 +Encrypted key: 5DD8D7E59E6AC85AE340BBA60AA8F8BE56C4C1FE02340C49EB8F36DA79B8D6640961FE9EAECDD6BADF083C5B6060C1D0309D28EFA25946F431979B9F9D21E77BDC5B1CC7165DE2F4AE51E418746260F518ED0C328BD3020DEC9B774DC00270B0CFBBE3DD738FDF715342CFBF2D461239 +``` + +4) ラップされた公開鍵（フラッシュファイル）の作成 + +ラップされた鍵をフラッシュに書き込むためのMotorolaヘックスファイルを生成します。 + +```sh +$ C:\Renesas\SecurityKeyManagementTool\cli\skmt.exe -genkey -ufpk file=./sample.key -wufpk file=./sample.key_enc.key -key file=./pub-ecc384.pem -mcu RX-TSIP -keytype secp384r1-public -output pub-ecc384.srec -filetype "mot" -address FFFF0000 +Output File: Y:\GitHub\wolfboot\pub-ecc384.srec +UFPK: B94A2B961C75510174F0C967ECFC20B377C7FB256DB627B1BFFADEE05EE98AC4 +W-UFPK: 000000016CCB9A1C8AA58883B1CB02DE6C37DA6054FB94E206EAE7204D9CCF4C6EEB288C +IV: 9C13402DF1AF631DC2A10C2424182601 +Encrypted key: C4A0B368552EB921A3AF3427FD7403BBE6CB8EE259D6CC0692AA72D46F7343F5FFE7DA97A1C811B21BF392E3834B67C3CE6F84707CCB8923D4FBB8DA003EF23C1CD785B6F58E5DB161F575F78D646434AC2BFAF207F6FFF6363C800CFF7E7BFF4857452A70C496B675D08DD6924CAB5E +``` + +生成されたファイルは、`0xFFFF0000`アドレスを使用する指示を含むラップされた公開鍵を含むMotorolaヘックス（S-Record）フォーマットのイメージです。 + +``` +S00E00007075622D65636333737265D5 +S315FFFF000000000000000000006CCB9A1C8AA58883C5 +S315FFFF0010B1CB02DE6C37DA6054FB94E206EAE720E7 +S315FFFF00204D9CCF4C6EEB288C9C13402DF1AF631D7F +S315FFFF0030C2A10C2424182601C4A0B368552EB921EA +S315FFFF0040A3AF3427FD7403BBE6CB8EE259D6CC06AE +S315FFFF005092AA72D46F7343F5FFE7DA97A1C811B27D +S315FFFF00601BF392E3834B67C3CE6F84707CCB8923ED +S315FFFF0070D4FBB8DA003EF23C1CD785B6F58E5DB1F0 +S315FFFF008061F575F78D646434AC2BFAF207F6FFF66C +S315FFFF0090363C800CFF7E7BFF4857452A70C496B6D9 +S311FFFF00A075D08DD6924CAB5ED6FF44C5E3 +S705FFFF0000FC +``` + +デフォルトのフラッシュメモリアドレスは`0xFFFF0000`ですが、変更できます。 + +以下の2か所を設定する必要があります。 + +a) `user_settings.h`ビルドマクロ`RENESAS_TSIP_INSTALLEDKEY_ADDR` +b) リンカースクリプトの`.rot`セクション（例：`hal/rx72n.ld`または`hal/rx65n.ld`）。 + +5) .configの`PKA?=1`を編集 + +6) wolfBootを再ビルド + +```sh +$ make clean && make wolfboot.srec +``` + +7) アプリケーションに署名 + +上記で作成した秘密鍵`pri-ecc384.der`を使用してアプリケーションに署名します。 + +```sh +$ ./tools/keytools/sign --ecc384 --sha256 test-app/image.bin pri-ecc384.der 1 +wolfBoot KeyTools (Compiled C version) +wolfBoot version 2010000 +Update type: Firmware +Input image: test-app/image.bin +Selected cipher: ECC384 +Selected hash : SHA256 +Public key: pri-ecc384.der +Output image: test-app/image_v1_signed.bin +Target partition id : 1 +image header size overridden by config value (1024 bytes) +Calculating SHA256 digest... +Signing the digest... +Output image(s) successfully created. +``` + +8) `wolfboot.srec`、`pub-ecc384.srec`および署名済みアプリケーションバイナリをフラッシュに書き込み + +Renesasフラッシュプログラマーを使用してファイルをフラッシュにダウンロードします。 + + +### RX TSIPベンチマーク + +| ハードウェア | クロック | アルゴリズム | RX TSIP | デバッグ | リリース (-Os) | リリース (-O2) | +| ------------ | -------- | ----------------- | -------- | --------- | ------------- | ------------- | +| RX72N | 240MHz | ECDSA検証 P384 | 17.26 ms | 1570 ms | 441 ms | 313 ms | +| RX72N | 240MHz | ECDSA検証 P256 | 2.73 ms | 469 ms | 135 ms | 107 ms | +| RX65N | 120MHz | ECDSA検証 P384 | 18.57 ms | 4213 ms | 2179 ms | 1831 ms | +| RX65N | 120MHz | ECDSA検証 P256 | 2.95 ms | 1208 ms | 602 ms | 517 ms | diff --git a/wolfBoot/src-ja/appendix11.md b/wolfBoot/src-ja/appendix11.md index e69de29b..1c78a882 100644 --- a/wolfBoot/src-ja/appendix11.md +++ b/wolfBoot/src-ja/appendix11.md @@ -0,0 +1,236 @@ +# wolfBoot鍵ツール + +`keygen`と`sign`は、PCまたは自動化されたサーバー環境で使用するコマンドラインツールで、wolfBootの秘密鍵を管理し、ターゲットの初期ファームウェアとすべての更新に署名するために使用されます。 + +## CまたはPython + +ツールは、移植性の理由から、同じコマンドライン構文を使用する2つのバージョンで配布しています。 + +デフォルトでは、C鍵ツールがコンパイルされます。このリポジトリのMakefileとスクリプトはCツールを使用します。 + +### C鍵ツール + +鍵ツールのスタンドアロンCバージョンは、`./tools/keytools`で利用できます。 + +これらは`tools/keytools`で`make`を使用するか、wolfBootのルートから`make keytools`を使用してビルドできます。 + +Cバージョンの鍵ツールが存在する場合、それらはwolfBootのMakefileとスクリプトによって使用されます。 + +#### Windows Visual Studio + +Windows用の`sign.exe`と`keygen.exe`ツールをビルドするには、`wolfBootSignTool.vcxproj` Visual Studioプロジェクトを使用します。 + +欠落している`target.h`に関するエラーが表示された場合、これはmakeプロセスを使用して.configに基づいて生成されるファイルです。 +デルタ更新で使用される`WOLFBOOT_SECTOR_SIZE`に必要です。 + +### Python鍵ツール + +**Pythonツールは非推奨であり、将来のバージョンでは削除される予定であることに注意してください。** + +Python鍵ツールを使用するには、Pythonの環境に`wolfcrypt`パッケージがインストールされていることを確認してください。ほとんどのシステムでは、以下のようなコマンドを実行するだけで十分です。 + +```sh +pip install wolfcrypt +``` + +これにより、依存関係が満たされていることが確認されます。 + +## コマンドラインツールの使用方法 + +### 鍵生成ツール + +使用法: `keygen [OPTIONS] [-g new-keypair.der] [-i existing-pubkey.der] [...]` + +`keygen`は既存の新しい公開鍵で鍵ストアを埋めるために使用されます。 +2つのオプションをサポートしています。 + +- `-g privkey.der` 新しい鍵ペアを生成し、公開鍵を鍵ストアに追加し、秘密鍵を新しいファイル`privkey.der`に保存します +- `-i existing.der` 既存の公開鍵を`existing.der`からインポートします +- `--der` 生成された秘密鍵をDER形式で保存します + +引数は排他的ではなく、複数の鍵で鍵ストアを埋めるために複数回繰り返すことができます。 + +鍵ストアで有効なアルゴリズムを選択するために、1つのオプションを指定する必要があります（例：`--ed25519`または`--rsa3072`）。 +使用可能なオプションについては、署名ツールの「公開鍵署名オプション」セクションを参照してください。 + +鍵ジェネレーターツールによって生成されるファイルは次のとおりです。 + +- Cファイル`src/keystore.c`、鍵が生成されたCコードを通じてプロビジョニングされる場合、通常はwolfBootイメージとリンクされます。 +- バイナリファイル`keystore.img`、代替ストレージを通じて公開鍵をプロビジョニングするために使用できます。 +- コマンドラインから提供された各`-g`オプションに対する秘密鍵。 + +鍵ストアメカニズムの詳細については、[付録D](appendix04.md)を参照してください。 + + +### サインツール + +`sign`は、wolfBootでサポートされている形式でマニフェストヘッダーを作成することにより、署名付きファームウェアイメージを生成します。 + +使用法: `sign [OPTIONS] IMAGE.BIN KEY.DER VERSION` + +`IMAGE.BIN`: 署名するバイナリファームウェア/ソフトウェアを含むファイル +`KEY.DER`: バイナリイメージに署名するためのDER形式の秘密鍵ファイル +`VERSION`: この署名されたソフトウェアに関連付けられたバージョン +`OPTIONS`: 以下で説明される0個以上のオプション + +#### 公開鍵署名オプション + +以下の引数のいずれも指定されていない場合、ツールはKEY.DERで検出された形式と鍵の長さから鍵のサイズを推測しようとします。 + + * `--ed25519` ファームウェアの署名にED25519を使用します。指定されたKEY.DERファイルがこの形式であると仮定します。 + + * `--ed448` ファームウェアの署名にED448を使用します。指定されたKEY.DERファイルがこの形式であると仮定します。 + + * `--ecc256` ファームウェアの署名にecc256を使用します。指定されたKEY.DERファイルがこの形式であると仮定します。 + + * `--ecc384` ファームウェアの署名にecc384を使用します。指定されたKEY.DERファイルがこの形式であると仮定します。 + + * `--ecc521` ファームウェアの署名にecc521を使用します。指定されたKEY.DERファイルがこの形式であると仮定します。 + + * `--rsa2048` ファームウェアの署名にrsa2048を使用します。指定されたKEY.DERファイルがこの形式であると仮定します。 + + * `--rsa3072` ファームウェアの署名にrsa3072を使用します。指定されたKEY.DERファイルがこの形式であると仮定します。 + + * `--rsa4096` ファームウェアの署名にrsa4096を使用します。指定されたKEY.DERファイルがこの形式であると仮定します。 + + * `--lms` ファームウェアの署名にLMS/HSSを使用します。指定されたKEY.DERファイルがこの形式であると仮定します。 + + * `--xmss` ファームウェアの署名にXMSS/XMSS^MTを使用します。指定されたKEY.DERファイルがこの形式であると仮定します。 + + * `--no-sign` セキュアブート署名検証を無効にします。ブートローダーでは署名検証が実行されず、KEY.DER引数は提供しないでください。 + +#### ハッシュダイジェストオプション + +以下のいずれも使用されない場合、デフォルトでは「--sha256」が想定されます。 + + * `--sha256` バイナリイメージと公開鍵のダイジェスト計算にsha256を使用します。 + + * `--sha348` バイナリイメージと公開鍵のダイジェスト計算にsha384を使用します。 + + * `--sha3` バイナリイメージと公開鍵のダイジェスト計算にsha3-384を使用します。 + +#### ターゲットパーティションID（複数パーティションイメージ、「自己更新」機能） + +以下のいずれも使用されない場合、デフォルトでは「`--id=1`」が想定されます。 +検証する単一のイメージを持つシステム（例：単一のアクティブパーティションを持つマイクロコントローラー）では、`ID=1`はステージングするファームウェアイメージのデフォルト識別子です。 +`ID=0`はwolfBootの「自己更新」用に予約されており、ブートローダー自体が格納されているパーティションを指します。 + + * `--id N` イメージパーティションIDを「N」に設定します。 + + * `--wolfboot-update` イメージにブートローダー用の署名された自己更新パッケージが含まれていることを示します。`--id 0`と同等です。 + +#### 対称鍵を使用した暗号化 + +認証のために署名していますが、デフォルトではイメージは暗号化されておらず、平文として配布されます。 +外部の不揮発性メモリにファームウェアが保存されている場合、ファームウェアパッケージングから更新プロセスまでのエンドツーエンドの暗号化を使用できます。 +暗号化された更新は、事前共有の秘密対称鍵を使用して、次のオプションを渡すことで生成できます。 + + * `--encrypt SHAREDKEY.BIN` ファイルSHAREKEY.BINを使用してイメージを暗号化します。 + +ファイルの形式は、暗号化に選択されたアルゴリズムによって異なります。 +形式が指定されておらず、`--encrypt SHAREDKEY.BIN`オプションが存在する場合、デフォルトでは`--chacha`が想定されます。 + +以下のオプションを参照してください。 + + * `--chacha` イメージの暗号化にChaCha20アルゴリズムを使用します。ファイルSHAREDKEY.BINは正確に44バイトのサイズであることが期待され、そのうち32バイトが鍵に、12バイトがIVの初期化に使用されます。 + + * `--aes128` イメージの暗号化にカウンターモードでAES-128アルゴリズムを使用します。ファイルSHAREDKEY.BINは正確に32バイトのサイズであることが期待され、そのうち16バイトが鍵に、16バイトがIVの初期化に使用されます。 + + * `--aes256` イメージの暗号化にカウンターモードでAES-256アルゴリズムを使用します。ファイルSHAREDKEY.BINは正確に48バイトのサイズであることが期待され、そのうち32バイトが鍵に、16バイトがIVの初期化に使用されます。 + +#### デルタ更新（既知のバージョンからの増分更新） + +以下のオプションが提供されると、署名ツールを使用して増分更新が作成されます。 + + * `--delta BASE_SIGNED_IMG.BIN` このオプションは、`BASE_SIGNED_IMG.BIN`と`IMAGE.BIN`から署名された新しいイメージの間のバイナリ差分ファイルを作成します。結果は`_signed_diff.bin`で終わるファイルに保存されます。 + +使用される圧縮ス鍵ムはBentley–McIlroyです。 + +#### ポリシー署名（TPMでのシーリング/アンシーリング用） + +ヘッダーに含めて署名するPCRマスクとダイジェストを提供します。署名鍵はダイジェストに署名するために使用されます。 + + * `--policy policy.bin`: この引数は多目的です。 + デフォルトでは、ファイルには署名される4バイトのPCRマスクとSHA2-256 PCRダイジェストが含まれている必要があります。 + `--manual-sign`を使用する場合、ファイルには4バイトのPCRマスクと署名が含まれている必要があります。 + PCRマスクと署名は`HDR_POLICY_SIGNATURE`ヘッダータグに含まれます。 + 最終的に署名されたポリシー（4バイトのPCRマスクを含む）のコピーが`[inputname].sig`に出力されます。 + + 注意：これにはヘッダーに2つの署名が保存されるため、`IMAGE_HEADER_SIZE`の増加が必要になる場合があります。 + +#### マニフェストヘッダーへのカスタムフィールドの追加 + +カスタムタグで設定される値を提供します + + * `--custom-tlv tag len val`: マニフェストヘッダーにTLVエントリを追加します。`tag`によって識別されるタイプに対応し、長さ`len`バイトで、値`val`を割り当てます。 + 値は10進数または16進数（'0x'が前に付いている）です。タグは16ビットの数字です。 + 有効なタグは0x0030から0xFEFEの範囲です。 + + * `--custom-tlv-buffer tag value`: 任意の長さのTLVエントリをマニフェストヘッダーに追加します。`tag`によって識別されるタイプに対応し、値`value`を割り当てます。タグは16ビットの数字です。有効なタグは0x0030から0xFEFEの範囲です。長さは暗黙的であり、値の長さです。 + 値引数は16進文字列の形式です。例えば、`--custom-tlv-buffer 0x0030 AABBCCDDEE` + はタグ0x0030、長さ5、値0xAABBCCDDEEのTLVエントリを追加します。 + + * `--custom-tlv-string tag ascii-string`: 任意の長さのTLVエントリをマニフェストヘッダーに追加します。`tag`によって識別されるタイプに対応し、`ascii-string`の値を割り当てます。タグは16ビットの数字です。有効なタグは0x0030から0xFEFEの範囲です。長さは暗黙的であり、`ascii-string`の長さです。`ascii-string`引数は文字列の形式です。 + 例えば、`--custom-tlv-string 0x0030 "Version-1"`はタグ0x0030、 + 長さ9、値Version-1のTLVエントリを追加します。 + +#### 外部プロビジョニングツールを使用した三段階の署名 + +秘密鍵がアクセス可能でない場合でも、サードパーティツールを使用してペイロードに署名できます。 +署名メカニズムは3つのフェーズに分けることができます。 + +- フェーズ1: イメージのshaダイジェストのみを作成し、サードパーティツールによって署名できる中間ファイルを準備します。 + +これは次のオプションを使用して行われます。 + + * `--sha-only` このオプションが選択されると、署名ツールは署名する必要があるマニフェストの一部を含む中間イメージを作成し、`_digest.bin`で終わるファイルを作成します。この場合、KEY.DERにはフェーズ2でファームウェアに署名するために使用される鍵の公開部分が含まれています。 + +- フェーズ2: 中間イメージ`*_digest.bin`は外部ツール、HSM、またはサードパーティの署名サービスによって署名されます。その後、署名はそのraw形式でエクスポートされ、ファイル（例：`IMAGE_SIGNATURE.SIG`）にコピーされます。 + +- フェーズ3: 次のオプションを使用して、最終的な認証済みファームウェアイメージを構築します。このイメージには、前面にマニフェストヘッダーが含まれています。 + + * `--manual-sign` このオプションが提供されると、KEY.DER引数にはフェーズ2でファームウェアの署名に使用された鍵の公開部分が含まれています。このオプションには、VERSION後に1つの追加引数が必要で、これは前のフェーズの出力であった署名のファイル名、つまり`IMAGE_SIGNATURE.SIG`である必要があります。 + +実際の例については、以下のセクションをご覧ください。 + +## 使用例 + +### ファームウェアへの署名 + +1. 署名に使用する秘密鍵を`./wolfboot_signing_private_key.der`にロードします。 +2. 非対称アルゴリズム、ハッシュアルゴリズム、署名するファイル、鍵、バージョンを指定して署名ツールを実行します。 + +```sh +./tools/keytools/sign --rsa2048 --sha256 test-app/image.bin wolfboot_signing_private_key.der 1 +``` + +注：最後の引数は「バージョン」番号です。 + +### 外部秘密鍵（HSM）を使用したファームウェアへの署名 + +外部鍵ソースを使用してファームウェアに手動で署名するための手順は次の通りです。 + +```sh +# Create file with Public Key +openssl rsa -inform DER -outform DER -in my_key.der -out rsa2048_pub.der -pubout + +# Add the public key to the wolfBoot keystore using `keygen -i` +./tools/keytools/keygen --rsa2048 -i rsa2048_pub.der + +# Generate Hash to Sign +./tools/keytools/sign --rsa2048 --sha-only --sha256 test-app/image.bin rsa2048_pub.der 1 + +# Sign hash Example (here is where you would use an HSM) +openssl pkeyutl -sign -keyform der -inkey my_key.der -in test-app/image_v1_digest.bin > test-app/image_v1.sig + +# Generate final signed binary +./tools/keytools/sign --rsa2048 --sha256 --manual-sign test-app/image.bin rsa2048_pub.der 1 test-app/image_v1.sig + +# Combine into factory image (0xc0000 is the WOLFBOOT_PARTITION_BOOT_ADDRESS) +tools/bin-assemble/bin-assemble factory.bin 0x0 wolfboot.bin \ + 0xc0000 test-app/image_v1_signed.bin +``` + +### Azure Key Vaultを使用したファームウェアへの署名 + +[付録B](appendix02.md)を参照してください。 diff --git a/wolfBoot/src-ja/appendix12.md b/wolfBoot/src-ja/appendix12.md index e69de29b..dd5aed60 100644 --- a/wolfBoot/src-ja/appendix12.md +++ b/wolfBoot/src-ja/appendix12.md @@ -0,0 +1,219 @@ +# TrustZone-MセキュアドメインにおけるwolfCrypt + +ARMv8-Mマイクロコントローラーは、ソフトウェア実行のためのハードウェア支援ドメイン分離をサポートしています。 +このTEEメカニズムは2つの個別ドメイン（セキュアおよび非セキュア）を提供し、非セキュアドメインからセキュア関数を呼び出すためのインターフェースとして使用できる追加ゾーン（非セキュア呼び出し可能）を提供します。 + +wolfBootはオプションで、非セキュアドメインにステージングされたあらゆるソフトウェアからアクセス可能な非呼び出し可能APIとして、暗号化機能をエクスポートできます。 + +## TrustZone-MセキュアドメインでwolfCryptを使用したwolfBootのコンパイル + +wolfBootが`TZEN=1`および`WOLFCRYPT_TZ=1`オプションでコンパイルされると、wolfCrypt暗号ライブラリのより完全なコンポーネントセットがブートローダーに組み込まれます。 +そうすると、非セキュア呼び出し可能APIを通じて非セキュアドメインで実行されるアプリケーションまたはOSからアクセスできるようになります。 + +この機能は、コアとなる暗号操作をアプリケーションから分離するために使用されます。 + +## 非セキュアワールドでのPKCS11 API + +`WOLFCRYPT_TZ_PKCS11`オプションは、セキュアモードの専用フラッシュ領域にPKCS11オブジェクトを保存するためのストレージを含む、標準的なPKCS11インターフェースを提供します。 + +これにより、非セキュアドメインで実行されるアプリケーション、TLSライブラリ、およびオペレーティングシステムは、標準的なPKCS11インターフェースを通じてwolfCryptにアクセスし、非セキュアドメインに公開されることのない事前プロビジョニングされた鍵を使用して暗号ライブラリを使用できます。 + +## STM32L552を使用した例 + + - TrustZone-Mおよび PKCS11インターフェースでwolfCryptをサポートするSTM32-L5の例設定をコピーします。`cp config/examples/stm32l5-wolfcrypt-tz.config .config` + + - `make`を実行します。`wolfboot.elf`とテストアプリケーションは別々のオブジェクトとしてビルドされます。アプリケーションは署名され、`test-app/image_v1_signed.bin`として保存されます。 + + - ターゲットデバイスのオプションバイトが以下のように設定されていることを確認します。 + +``` +OPTION BYTES BANK: 0 + + Read Out Protection: + + RDP : 0xAA (Level 0, no protection) + + BOR Level: + + BOR_LEV : 0x0 (BOR Level 0, reset level threshold is around 1.7 V) + + User Configuration: + + nRST_STOP : 0x1 (No reset generated when entering Stop mode) + nRST_STDBY : 0x1 (No reset generated when entering Standby mode) + nRST_SHDW : 0x1 (No reset generated when entering the Shutdown mode) + IWDG_SW : 0x1 (Software independant watchdog) + IWDG_STOP : 0x1 (IWDG counter active in stop mode) + IWDG_STDBY : 0x1 (IWDG counter active in standby mode) + WWDG_SW : 0x1 (Software window watchdog) + SWAP_BANK : 0x0 (Bank 1 and bank 2 address are not swapped) + DB256 : 0x1 (256Kb dual-bank Flash with contiguous addresses) + DBANK : 0x0 (Single bank mode with 128 bits data read width) + SRAM2_PE : 0x1 (SRAM2 parity check disable) + SRAM2_RST : 0x1 (SRAM2 is not erased when a system reset occurs) + nSWBOOT0 : 0x1 (BOOT0 taken from PH3/BOOT0 pin) + nBOOT0 : 0x1 (nBOOT0 = 1) + PA15_PUPEN : 0x1 (USB power delivery dead-battery disabled/ TDI pull-up activated) + TZEN : 0x1 (Global TrustZone security enabled) + HDP1EN : 0x0 (No HDP area 1) + HDP1_PEND : 0x0 (0x8000000) + HDP2EN : 0x0 (No HDP area 2) + HDP2_PEND : 0x0 (0x8000000) + NSBOOTADD0 : 0x100000 (0x8000000) + NSBOOTADD1 : 0x17F200 (0xBF90000) + SECBOOTADD0 : 0x180000 (0xC000000) + BOOT_LOCK : 0x0 (Boot based on the pad/option bit configuration) + + Secure Area 1: + + SECWM1_PSTRT : 0x0 (0x8000000) + SECWM1_PEND : 0x39 (0x8039000) + + Write Protection 1: + + WRP1A_PSTRT : 0x7F (0x807F000) + WRP1A_PEND : 0x0 (0x8000000) + WRP1B_PSTRT : 0x7F (0x807F000) + WRP1B_PEND : 0x0 (0x8000000) +OPTION BYTES BANK: 1 + + Secure Area 2: + + SECWM2_PSTRT : 0x7F (0x807F000) + SECWM2_PEND : 0x0 (0x8000000) + + Write Protection 2: + + WRP2A_PSTRT : 0x7F (0x80BF000) + WRP2A_PEND : 0x0 (0x8040000) + WRP2B_PSTRT : 0x7F (0x80BF000) + WRP2B_PEND : 0x0 (0x8040000) +``` + + - `wolfboot.bin`とテストアプリケーションをフラッシュの2つの異なるドメインにアップロードします。 + +``` +STM32_Programmer_CLI -c port=swd -d wolfboot.bin 0x0C000000 +STM32_Programmer_CLI -c port=swd -d test-app/image_v1_signed.bin 0x08040000 +``` + + - 再起動後、ボード上のLEDが順番に点灯するはずです。 + - 赤色LED：セキュアブートが成功しました。アプリケーションが開始しました。 + - 青色LED：PKCS11トークンが初期化され、保存しました + - 緑色LED：ECDSA署名/検証テストが成功しました + + +## STM32H563を使用した例 + + - TrustZoneとPKCS11をサポートするSTM32H5の例設定のいずれかを`.config`にコピーします。 + `cp config/examples/stm32h5-tz.config .config` + `cp config/examples/stm32h5-tz-dualbank-otp.config .config` (デュアルバンク付き) + `cp config/examples/stm32h5-tz-dualbank-otp-lms.config .config` (デュアルバンクおよびPQ LMS付き) + + - `make`を実行します。`wolfboot.elf`とテストアプリケーションは別々のオブジェクトとしてビルドされます。アプリケーションは署名され、`test-app/image_v1_signed.bin`として保存されます。 + + - ターゲットデバイスのオプションバイトが以下のように設定されていることを確認します。 + +``` +OPTION BYTES BANK: 0 + + Product state: + + PRODUCT_STATE: 0xED (Open) + + BOR Level: + + BOR_LEV : 0x0 (BOR Level 1, the threshold level is low (around 2.1 V)) + BORH_EN : 0x0 (0x0) + + User Configuration: + + IO_VDD_HSLV : 0x0 (0x0) + IO_VDDIO2_HSLV: 0x0 (0x0) + IWDG_STOP : 0x1 (0x1) + IWDG_STDBY : 0x1 (0x1) + BOOT_UBE : 0xB4 (OEM-iRoT (user flash) selected) + SWAP_BANK : 0x0 (0x0) + IWDG_SW : 0x1 (0x1) + NRST_STOP : 0x1 (0x1) + NRST_STDBY : 0x1 (0x1) +OPTION BYTES BANK: 1 + + User Configuration 2: + + TZEN : 0xB4 (Trust zone enabled) + SRAM2_ECC : 0x1 (SRAM2 ECC check disabled) + SRAM3_ECC : 0x1 (SRAM3 ECC check disabled) + BKPRAM_ECC : 0x1 (BKPRAM ECC check disabled) + SRAM2_RST : 0x1 (SRAM2 not erased when a system reset occurs) + SRAM1_3_RST : 0x1 (SRAM1 and SRAM3 not erased when a system reset occurs) +OPTION BYTES BANK: 2 + + Boot Configuration: + + NSBOOTADD : 0x80400 (0x8040000) + NSBOOT_LOCK : 0xC3 (The SWAP_BANK and NSBOOTADD can still be modified following their individual rules.) + SECBOOT_LOCK : 0xC3 (The BOOT_UBE, SWAP_BANK and SECBOOTADD can still be modified following their individual rules.) + SECBOOTADD : 0xC0000 (0xC000000) +OPTION BYTES BANK: 3 + + Bank1 - Flash watermark area definition: + + SECWM1_STRT : 0x0 (0x8000000) + SECWM1_END : 0x1F (0x803E000) + + Write sector group protection 1: + + WRPSGn1 : 0xFFFFFFFF (0x0) +OPTION BYTES BANK: 4 + + Bank2 - Flash watermark area definition: + + SECWM2_STRT : 0x7F (0x81FE000) + SECWM2_END : 0x0 (0x8100000) + + Write sector group protection 2: + + WRPSGn2 : 0xFFFFFFFF (0x8000000) +OPTION BYTES BANK: 5 + + OTP write protection: + + LOCKBL : 0x0 (0x0) +OPTION BYTES BANK: 6 + + Flash data bank 1 sectors: + + EDATA1_EN : 0x0 (No Flash high-cycle data area) + EDATA1_STRT : 0x0 (0x0) +OPTION BYTES BANK: 7 + + Flash data bank 2 sectors : + + EDATA2_EN : 0x0 (No Flash high-cycle data area) + EDATA2_STRT : 0x0 (0x0) +OPTION BYTES BANK: 8 + + Flash HDP bank 1: + + HDP1_STRT : 0x1 (0x2000) + HDP1_END : 0x0 (0x0) +OPTION BYTES BANK: 9 + + Flash HDP bank 2: + + HDP2_STRT : 0x1 (0x2000) + HDP2_END : 0x0 (0x0) +``` + + - `wolfboot.bin`とテストアプリケーションをフラッシュの2つの異なるドメインにアップロードします。 + +``` +STM32_Programmer_CLI -c port=swd -d wolfboot.bin 0x0C000000 +STM32_Programmer_CLI -c port=swd -d test-app/image_v1_signed.bin 0x08040000 +``` + + - 再起動後、ボード上のLEDが順番に点灯するはずです。 + - 赤色LED：セキュアブートが成功しました。アプリケーションが開始しました。 + - 青色LED：PKCS11トークンが初期化され、保存しました + - 緑色LED：ECDSA署名/検証テストが成功しました diff --git a/wolfBoot/src-ja/appendix13.md b/wolfBoot/src-ja/appendix13.md index e69de29b..8a800902 100644 --- a/wolfBoot/src-ja/appendix13.md +++ b/wolfBoot/src-ja/appendix13.md @@ -0,0 +1,228 @@ +# wolfBoot TPMサポート + +wolfBootでは、TPMベースのRoot of Trust、シーリング/アンシーリング、暗号化オフローディング、TPMを使用したMeasured Bootをサポートしています。 + +## ビルドオプション + +| 設定オプション | プリプロセッサマクロ | 説明 | +| ------------- | ------------------ | ----------------------------------- | +| `WOLFTPM=1` | `WOLFBOOT_TPM` | wolfTPMサポートを有効にします | +| `WOLFBOOT_TPM_VERIFY=1` | `WOLFBOOT_TPM_VERIFY` | RSA2048およびECC256/384の暗号化オフローディングをTPMに対して有効にします。 | +| `WOLFBOOT_TPM_KEYSTORE=1` | `WOLFBOOT_TPM_KEYSTORE` | TPMベースのRoot of Trustを有効にします。NVインデックスには信頼された公開鍵のハッシュを保存する必要があります。 | +| `WOLFBOOT_TPM_KEYSTORE_NV_BASE=0x` | `WOLFBOOT_TPM_KEYSTORE_NV_BASE=0x` | プラットフォーム範囲0x1400000 - 0x17FFFFFのNVインデックス。| +| `WOLFBOOT_TPM_KEYSTORE_AUTH=secret` | `WOLFBOOT_TPM_KEYSTORE_AUTH` | NVアクセス用のパスワード | +| `MEASURED_BOOT=1` | `WOLFBOOT_MEASURED_BOOT` | Measured Bootを有効にします。wolfBootハッシュでPCRを拡張します。 | +| `MEASURED_PCR_A=16` | `WOLFBOOT_MEASURED_PCR_A=16` | 使用するPCRインデックス。[付録G](appendix07.md)を参照してください。 | +| `WOLFBOOT_TPM_SEAL=1` | `WOLFBOOT_TPM_SEAL` | 外部で署名されたPCRポリシーに基づくシーリング/アンシーリングのサポートを有効にします。 | +| `WOLFBOOT_TPM_SEAL_NV_BASE=0x01400300` | `WOLFBOOT_TPM_SEAL_NV_BASE` | プラットフォーム階層内のデフォルトのシールされたブロブストレージの場所をオーバーライドします。 | +| `WOLFBOOT_TPM_SEAL_AUTH=secret` | `WOLFBOOT_TPM_SEAL_AUTH` | シーリング/アンシーリングの秘密のためのパスワード、省略された場合はPCRポリシーが使用されます | + +## Root of Trust (RoT) + +wolfTPM Secure Root of Trust（RoT）の例は[こちら](https://github.com/wolfSSL/wolfTPM/tree/master/examples/boot)をご覧ください。 + +この設計では、ロックされたプラットフォームNVハンドルを使用します。 +NVには公開鍵のハッシュが保存されます。 +TPMの改ざんを防ぐために、派生した「認証」値を提供することをお勧めします。 +この認証値はバス上で暗号化されます。 + +## 暗号化オフローディング + +RSA2048およびECC256/384ビットの検証は、コードサイズの削減またはパフォーマンス向上のためにTPMにオフロードできます。`WOLFBOOT_TPM_VERIFY`を使用して有効にします。 + +注意：TPMのRSA検証にはASN.1エンコーディングが必要なため、SIGN=RSA2048ENCを使用してください。 + +## Measured Boot + +wolfBootイメージはハッシュ化され、指定されたPCRに拡張されます。これは後でアプリケーションで、ブートプロセスが改ざんされていないことを証明するために使用できます。 +`WOLFBOOT_MEASURED_BOOT`で有効にし、API `wolfBoot_tpm2_extend`を公開します。 + +## 秘密のシーリングとアンシーリング + +wolfTPMのシーリング/アンシーリングの例は[こちら](https://github.com/wolfSSL/wolfTPM/tree/master/examples/boot#secure-boot-encryption-key-storage)をご覧ください。 + +既知のPCR値は、秘密をシール/アンシールするために署名される必要があります。 +認証ポリシーの署名は、`--policy`引数を使用して署名されたヘッダーに配置されます。 +ヘッダーに署名されたポリシーがない場合、値はシールされません。 +代わりに、PCR値とPCRポリシーダイジェストが外部で署名するために表示されます。 +`./tools/keytools/sign`または`./tools/tpm/policy_sign`を使用して、ポリシーに外部で署名できます。 + +これにより、NVインデックスに保存されたブロブでデータをシールおよびアンシールするための2つの新しいwolfBoot APIが公開されます。 + +```c +int wolfBoot_seal_auth(const uint8_t* pubkey_hint, const uint8_t* policy, uint16_t policySz, + int index, const uint8_t* secret, int secret_sz, const byte* auth, int authSz); +int wolfBoot_unseal_auth(const uint8_t* pubkey_hint, const uint8_t* policy, uint16_t policySz, + int index, uint8_t* secret, int* secret_sz, const byte* auth, int authSz); +``` + +デフォルトでは、このインデックスは`(0x01400300 + index)`のNVインデックスに基づきます。 +デフォルトのNVベースは`WOLFBOOT_TPM_SEAL_NV_BASE`でオーバーライドできます。 + +注意：TPMのRSA検証にはASN.1エンコーディングが必要なため、SIGN=RSA2048ENCを使用してください。 + +### シミュレータでのシール/アンシールのテスト + +```sh +% cp config/examples/sim-tpm-seal.config .config +% make keytools +% make tpmtools +% echo aaa > aaa.bin +% ./tools/tpm/pcr_extend 0 aaa.bin +% ./tools/tpm/policy_create -pcr=0 +# if ROT enabled +% ./tools/tpm/rot -write [-auth=TestAuth] +% make clean +$ make POLICY_FILE=policy.bin [WOLFBOOT_TPM_KEYSTORE_AUTH=TestAuth] [WOLFBOOT_TPM_SEAL_AUTH=SealAuth] + +% ./wolfboot.elf get_version +Simulator assigned ./internal_flash.dd to base 0x103378000 +Mfg IBM (0), Vendor SW TPM, Fw 8217.4131 (0x163636), FIPS 140-2 1, CC-EAL4 0 +Unlocking disk... +Boot partition: 0x1033f8000 +Image size 54400 +Error 395 reading blob from NV index 1400300 (error TPM_RC_HANDLE) +Error 395 unsealing secret! (TPM_RC_HANDLE) +Sealed secret does not exist! +Creating new secret (32 bytes) +430dee45553c4a8b75fbc6bcd0890765c48cab760b24b1aa6b633dc0538e0159 +Wrote 210 bytes to NV index 0x1400300 +Read 210 bytes from NV index 0x1400300 +Secret Check 32 bytes +430dee45553c4a8b75fbc6bcd0890765c48cab760b24b1aa6b633dc0538e0159 +Secret 32 bytes +430dee45553c4a8b75fbc6bcd0890765c48cab760b24b1aa6b633dc0538e0159 +Boot partition: 0x1033f8000 +Image size 54400 +TPM Root of Trust valid (id 0) +Simulator assigned ./internal_flash.dd to base 0x103543000 +1 + +% ./wolfboot.elf get_version +Simulator assigned ./internal_flash.dd to base 0x10c01c000 +Mfg IBM (0), Vendor SW TPM, Fw 8217.4131 (0x163636), FIPS 140-2 1, CC-EAL4 0 +Unlocking disk... +Boot partition: 0x10c09c000 +Image size 54400 +Read 210 bytes from NV index 0x1400300 +Secret 32 bytes +430dee45553c4a8b75fbc6bcd0890765c48cab760b24b1aa6b633dc0538e0159 +Boot partition: 0x10c09c000 +Image size 54400 +TPM Root of Trust valid (id 0) +Simulator assigned ./internal_flash.dd to base 0x10c1e7000 +1 +``` + +### 実際のハードウェアでのシール/アンシールのテスト + +1) ポリシー用の実際のPCRダイジェストを取得します。 + +2) ポリシーに署名し、ファームウェアイメージヘッダーに含めます。 + +#### PCR値の取得 + +署名されたポリシーが存在しない場合、シール機能はアクティブなPCR、PCRダイジェスト、ポリシーダイジェスト（署名用）を生成して表示します。 + +```sh +% make tpmtools +% ./tools/tpm/rot -write +% ./tools/tpm/pcr_reset 16 +% ./wolfboot.elf get_version +Simulator assigned ./internal_flash.dd to base 0x101a64000 +Mfg IBM (0), Vendor SW TPM, Fw 8217.4131 (0x163636), FIPS 140-2 1, CC-EAL4 0 +Boot partition: 0x101ae4000 +Image size 57192 +Policy header not found! +Generating policy based on active PCR's! +Getting active PCR's (0-16) +PCR 16 (counter 20) +8f7ac1d5a5eac58a2305ca459f27c35705a9212c0fb2a9088b1df761f3d5f842 +Found 1 active PCR's (mask 0x00010000) +PCR Digest (32 bytes): +f84085631f85333ad0338b06c82f16888b7923abaccffb881d5416e389be256c +PCR Mask (0x00010000) and PCR Policy Digest (36 bytes): +0000010034ba061436aba2e9a167a1ee46af4a9578a8c6b9f71fdece21607a0cb40468ec +Use this policy with the sign tool (--policy arg) or POLICY_FILE config +Image policy signature missing! +Boot partition: 0x101ae4000 +Image size 57192 +TPM Root of Trust valid (id 0) +Simulator assigned ./internal_flash.dd to base 0x101c2f000 +1 +``` + +上記の`0000010034ba061436aba2e9a167a1ee46af4a9578a8c6b9f71fdece21607a0cb40468ec`は鍵ツールで直接使用できます。 + +`echo "0000010034ba061436aba2e9a167a1ee46af4a9578a8c6b9f71fdece21607a0cb40468ec" | xxd -r -p > policy.bin` + +または、署名するダイジェストを生成するために`tools/tpm/policy_create`ツールを使用します。 +使用するPCRは「`-pcr=#`」を使用して設定する必要があります。PCRダイジェストは「`-pcrdigest=`」を使用して提供するか、提供されない場合はTPMから直接読み取られます。 + +```sh +% ./tools/tpm/policy_create -pcr=16 -pcrdigest=f84085631f85333ad0338b06c82f16888b7923abaccffb881d5416e389be256c -out=policy.bin +# OR +% ./tools/tpm/policy_create -pcrmask=0x00010000 -pcrdigest=f84085631f85333ad0338b06c82f16888b7923abaccffb881d5416e389be256c -out=policy.bin +Policy Create Tool +PCR Index(s) (SHA256): 16 (mask 0x00010000) +PCR Digest (32 bytes): + f84085631f85333ad0338b06c82f16888b7923abaccffb881d5416e389be256c +PCR Mask (0x00010000) and PCR Policy Digest (36 bytes): + 0000010034ba061436aba2e9a167a1ee46af4a9578a8c6b9f71fdece21607a0cb40468ec +Wrote 36 bytes to policy.bin +``` + +#### ポリシーの署名 + +署名するポリシーダイジェストを含むファームウェアのビルドは次のように実行します。 + +```sh +% make POLICY_FILE=policy.bin +``` + +あるいは、`tools/tpm/policy_sign`または`tools/keytools/sign`ツールを使用してポリシーに手動で署名します。 +これらのツールはTPMへのアクセスを必要とせず、ポリシーダイジェストに署名します。 +結果は32ビットのPCRマスク + 署名です。 + +policy_signツールで署名する場合： + +```sh +% ./tools/tpm/policy_sign -pcr=0 -pcrdigest=eca4e8eda468b8667244ae972b8240d3244ea72341b2bf2383e79c66643bbecc +Sign PCR Policy Tool +Signing Algorithm: ECC256 +PCR Index(s) (SHA256): 0 +Policy Signing Key: wolfboot_signing_private_key.der +PCR Digest (32 bytes): + eca4e8eda468b8667244ae972b8240d3244ea72341b2bf2383e79c66643bbecc +PCR Policy Digest (32 bytes): + 2d401eb05f45ba2b15c35f628b5896cc7de9745bb6e722363e2dbee804e0500f +PCR Policy Digest (w/PolicyRef) (32 bytes): + 749b3139ece21449a7828f11ee05303b0473ff1a26cf41d6f9ff28b24c717f02 +PCR Mask (0x1) and Policy Signature (68 bytes): + 01000000 + 5b5f875b3f7ce78b5935abe4fc5a4d8a6e87c4b4ac0836fbab909e232b6d7ca2 + 3ecfc6be723b695b951ba2886d3c7b83ab2f8cc0e96d766bc84276eaf3f213ee +Wrote PCR Mask + Signature (68 bytes) to policy.bin.sig +``` + +署名鍵ツールを使用する場合： + +```sh +% ./tools/keytools/sign --ecc256 --policy policy.bin test-app/image.elf wolfboot_signing_private_key.der 1 +wolfBoot KeyTools (Compiled C version) +wolfBoot version 1100000 +Update type: Firmware +Input image: test-app/image.elf +Selected cipher: ECC256 +Selected hash : SHA256 +Public key: wolfboot_signing_private_key.der +Output image: test-app/image_v1_signed.bin +Target partition id : 1 +image header size calculated at runtime (256 bytes) +Calculating SHA256 digest... +Signing the digest... +Opening policy file policy.bin +Signing the policy digest... +Saving policy signature to policy.bin.sig +Output image(s) successfully created. +``` diff --git a/wolfBoot/src-ja/chapter02.md b/wolfBoot/src-ja/chapter02.md index 67c9b6c6..7a5861d3 100644 --- a/wolfBoot/src-ja/chapter02.md +++ b/wolfBoot/src-ja/chapter02.md @@ -33,7 +33,7 @@ wolfBootは、さまざまな種類の組み込みシステムにわたってポ .configは、テキストエディターで変更して、後でデフォルトのオプションを変更できます。 -使用可能なコンフィギュレーションオプションの詳細については、[付録A コンフィギュレーションオプション](appendix14.md)に掲載しています。 +使用可能なコンフィギュレーションオプションの詳細については、[付録N コンフィギュレーションオプション](appendix14.md)に掲載しています。 ## プラットフォームの選択