ESP-IDF Programming Guide - Secure Boot

ESP32のセキュアブートの仕組みを理解する目的で、ESP-IDF Programming Guideの該当箇所を和訳しました。機械翻訳を多用してます。

オリジナルはこちら。
ESP-IDF Programming Guide - Secure Boot

#Secure Boot

Important
All references in this document are related to Secure Boot V1 (The AES based Secure Boot Scheme). ESP32 Revision 3 onwards, the preferred secure boot scheme is Secure Boot V2. Please refer to Secure Boot V2 document for ESP32 Revision 3 or ESP32-S2.
このドキュメントの内容は、Secure Boot V1 (The AES based Secure Boot Scheme) に関するものです。ESP32 Revision 3 以降では、Secure Boot V2 が推奨されています。ESP32 Revision 3 または ESP32-S2 については、Secure Boot V2 のドキュメントを参照してください。

Secure Boot is a feature for ensuring only your code can run on the chip. Data loaded from flash is verified on each reset.
セキュアブートは、お客様のコードのみがチップ上で実行できるようにするための機能です。フラッシュからロードされたデータは、リセットのたびに検証されます。

Secure Boot is separate from the Flash Encryption feature, and you can use secure boot without encrypting the flash contents. However, for a secure environment both should be used simultaneously. See Secure Boot & Flash Encryption for more details.
セキュアブートはフラッシュ暗号化機能とは別物で、フラッシュの内容を暗号化せずにセキュアブートを使用することができます。ただし、安全な環境を実現するためには、両方を同時に使用する必要があります。詳細については、「Secure Boot & Flash Encryption」を参照してください。

Important
Enabling secure boot limits your options for further updates of your ESP32. Make sure to read this document throughly and understand the implications of enabling secure boot.
セキュアブートを有効にすると、ESP32 のアップデートのオプションが制限されます。この文書をよく読み、セキュアブートを有効にすることの意味を理解してください。

Background

• Most data is stored in flash. Flash access does not need to be protected from physical access in order for secure boot to function, because critical data is stored (non-software-accessible) in Efuses internal to the chip.
  ほとんどのデータはフラッシュに保存されています。セキュアブートが機能するためには、フラッシュアクセスを物理的なアクセスから保護する必要はありません。

• Efuses are used to store the secure bootloader key (in efuse BLOCK2), and also a single Efuse bit (ABS_DONE_0) is burned (written to 1) to permanently enable secure boot on the chip. For more details about efuse, see Chapter 11 “eFuse Controller” in the Technical Reference Manual.
  eFuseは、eFuse BLOCK2にsecure bootloader keyが格納されるとともに、eFuseビット(ABS_DONE_0) に1を焼きこむことでチップのセキュアブートが恒久的に有効になります。eFuse の詳細については、Technical Reference Manualの第11章「eFuse Controller」を参照してください。

• To understand the secure boot process, first familiarise yourself with the standard ESP-IDF boot process.
  セキュアブートプロセスを理解するには、まず、標準の ESP-IDF ブートプロセスを理解してください。

• Both stages of the boot process (initial software bootloader load, and subsequent partition & app loading) are verified by the secure boot process, in a “chain of trust” relationship.
  ブートプロセスの両方の段階（最初のソフトウェアブートローダのロード、その後のパーティションとアプリのロード）は、「信頼の連鎖」の関係の中で、セキュアブートプロセスによって検証されます。

Secure Boot Process Overview

This is a high level overview of the secure boot process. Step by step instructions are supplied under How To Enable Secure Boot. Further in-depth details are supplied under Technical Details:
これは、セキュアブートプロセスの高レベルの概要です。ステップバイステップの手順は、How To Enable Secure Boot の下で提供されています。さらに詳細な詳細は、「技術的な詳細」に記載されています。

1. The options to enable secure boot are provided in the Project Configuration Menu, under “Secure Boot Configuration”.
   セキュアブートを有効にするためのオプションは、プロジェクト設定メニューの「Secure Boot Configuration」で提供されます。
   （注：v4.0.1では「Security features」->「Enable hardware secure boot in bootloader」）

2. Secure Boot defaults to signing images and partition table data during the build process. The “Secure boot private signing key” config item is a file path to a ECDSA public/private key pair in a PEM format file.
   セキュアブートは、ビルドプロセス中にイメージとパーティションテーブルデータに署名することをデフォルトとしています。「Secure boot private signing key」設定項目は、ECDSA公開鍵/秘密鍵ペアのPEM形式ファイルへパスです。

3. The software bootloader image is built by esp-idf with secure boot support enabled and the public key (signature verification) portion of the secure boot signing key compiled in. This software bootloader image is flashed at offset 0x1000.
   esp-idfは、セキュアブートサポートが有効化され、セキュアブート署名鍵の公開鍵（署名検証）部分が含まれた状態で、ソフトウェアブートローダイメージをビルドします。このソフトウェアブートローダイメージは、フラッシュのオフセット0x1000に書き込まれます。

4. On first boot, the software bootloader follows the following process to enable secure boot:
   最初のブート時には、ソフトウェアブートローダは以下のプロセスに従ってセキュアブートを行います。

   1. Hardware secure boot support generates a device secure bootloader key (generated via hardware RNG, then stored read/write protected in efuse), and a secure digest. The digest is derived from the key, an IV, and the bootloader image contents.
      ハードウェアのセキュアブートサポートは、デバイスのセキュアブートローダキー (ハードウェア RNG を介して生成され、efuse に読み書き保護されて保存されます) とセキュアダイジェストを生成します。ダイジェストは、キー、IV、ブートローダイメージの内容から生成されます。

   2. The secure digest is flashed at offset 0x0 in the flash.
      セキュアダイジェストは、フラッシュのオフセット 0x0 にフラッシュされます。

   3. Depending on Secure Boot Configuration, efuses are burned to disable JTAG and the ROM BASIC interpreter (it is strongly recommended these options are turned on.)
      セキュアブート設定に応じて、JTAGとROM BASICインタプリタを無効にする設定をeFuseに焼きこまれます (これらのオプションをオンにしておくことを強くお勧めします)。

   4. Bootloader permanently enables secure boot by burning the ABS_DONE_0 efuse. The software bootloader then becomes protected (the chip will only boot a bootloader image if the digest matches.)
      ブートローダは、eFuseのABS_DONE_0を焼きこむことでセキュアブートを恒久的に有効にします。これにより、ソフトウェアブートローダは保護されます (チップはダイジェストが一致した場合にのみブートローダイメージを起動します)。

5. On subsequent boots the ROM bootloader sees that the secure boot efuse is burned, reads the saved digest at 0x0 and uses hardware secure boot support to compare it with a newly calculated digest. If the digest does not match then booting will not continue. The digest and comparison are performed entirely by hardware, and the calculated digest is not readable by software. For technical details see Secure Boot Hardware Support.
   それ以降のブートでは、ROM ブートローダはセキュアブート用のeFuseが焼かれたことを見て、0x0 に保存されたダイジェストを読み込んで、ハードウェアのセキュアブートサポートを使って、新たに計算されたダイジェストと比較します。ダイジェストが一致しない場合、ブートは続行されません。ダイジェストと比較はすべてハードウェアで行われ、計算されたダイジェストはソフトウェアでは読み取れません。技術的な詳細については、セキュアブートハードウェアサポートを参照してください。

6. When running in secure boot mode, the software bootloader uses the secure boot signing key (the public key of which is embedded in the bootloader itself, and therefore validated as part of the bootloader) to verify the signature appended to all subsequent partition tables and app images before they are booted.
   セキュアブートモードで実行している場合、ソフトウェアブートローダは、セキュアブート署名鍵 (公開鍵はブートローダに組み込まれており、ブートローダの一部として検証されています) を使用して、後続のすべてのパーティションテーブルとアプリイメージがブートされる前に署名を確認します。

##Keys
The following keys are used by the secure boot process:
セキュアブートプロセスでは、以下の鍵が使用されます。

• “secure bootloader key” is a 256-bit AES key that is stored in Efuse block 2. The bootloader can generate this key itself from the internal hardware random number generator, the user does not need to supply it (it is optionally possible to supply this key, see Re-Flashable Software Bootloader). The Efuse holding this key is read & write protected (preventing software access) before secure boot is enabled.
  「secure bootloader key」は、Efuse ブロック 2 に格納されている 256 ビット AES 鍵です。ブートローダは、内部のハードウェア乱数発生器からこのキーを生成することができます。このキーを保持している Efuse は、セキュアブートが有効になる前に読み書き保護されます (ソフトウェアアクセスを防止します)。

By default, the Efuse Block 2 Coding Scheme is “None” and a 256 bit key is stored in this block. On some ESP32s, the Coding Scheme is set to 3/4 Encoding (CODING_SCHEME efuse has value 1) and a 192 bit key must be stored in this block.
デフォルトでは、Efuse Block 2 Coding Schemeは "None "となっており、256ビットのキーがこのブロックに格納されます。一部のESP32では、Coding Schemeが「3/4 Encoding」に設定されており（CODING_SCHEME efuseは値1）、192ビットのキーをこのブロックに格納する必要があります。

See ESP32 Technical Reference Manual section 20.3.1.3 System Parameter coding_scheme for more details.
詳細については、ESP32テクニカル・リファレンス・マニュアルのセクション20.3.1.3 システム・パラメータ coding_schemeを参照してください。

The algorithm operates on a 256 bit key in all cases, 192 bit keys are extended by repeating some bits (details).
アルゴリズムはすべての場合に256ビットの鍵で動作し、192ビットの鍵はいくつかのビットを繰り返すことで拡張されます（詳細）。

• “secure boot signing key” is a standard ECDSA public/private key pair (see Image Signing Algorithm) in PEM format.
  「secure boot signing key」は、PEM形式の標準的なECDSA公開鍵/秘密鍵ペア(Image Signing Algorithm参照)です。

The public key from this key pair (for signature verification but not signature creation) is compiled into the software bootloader and used to verify the second stage of booting (partition table, app image) before booting continues. The public key can be freely distributed, it does not need to be kept secret.
この鍵ペアからの公開鍵 (署名検証用ですが、署名作成用ではありません) は、ソフトウェアのブートローダにコンパイルされ、ブートが継続する前の第二段階 (パーティションテーブル、アプリイメージ) の検証に使用されます。公開鍵は自由に配布することができ、秘密にしておく必要はありません。

The private key from this key pair must be securely kept private, as anyone who has this key can authenticate to any bootloader that is configured with secure boot and the matching public key.
この鍵ペアの秘密鍵は、秘密にしておかなければなりません。この鍵を持っていれば任意のブートローダを、セキュアブートと対応する公開鍵で構成されたものとして承認できてしまうためです。

##Bootloader Size
When secure boot is enabled the bootloader app binary bootloader.bin may exceed the default bootloader size limit. This is especially likely if flash encryption is enabled as well. The default size limit is 0x7000 (28672) bytes (partition table offset 0x8000 - bootloader offset 0x1000).
セキュアブートが有効な場合、ブートローダアプリのバイナリ bootloader.bin がデフォルトのブートローダサイズの上限を超えることがあります。これは、特にフラッシュ暗号化が有効になっている場合に起こります。デフォルトのサイズ制限は 0x7000 (28672) バイトです (パーティションテーブルオフセット 0x8000 - ブートローダオフセット 0x1000)。

If the bootloader becomes too large, the ESP32 will fail to boot - errors will be logged about either invalid partition table or invalid bootloader checksum.
ブートローダのサイズが大きくなりすぎると、ESP32 は起動に失敗し、無効なパーティションテーブルか無効なブートローダチェックサムのどちらかのエラーが記録されます。

Options to work around this are:
これを回避するためのオプションは以下の通りです。

• Reduce bootloader log level. Setting log level to Warning, Error or None all significantly reduce the final binary size (but may make it harder to debug).
  ブートローダのログレベルを下げる。ログレベルを Warning, Error, None のいずれかに設定すると、最終的なバイナリサイズが大幅に減少します (ただし、デバッグが困難になる可能性があります)。

• Set partition table offset to a higher value than 0x8000, to place the partition table later in the flash. This increases the space available for the bootloader. If the partition table CSV file contains explicit partition offsets, they will need changing so no partition has an offset lower than CONFIG_PARTITION_TABLE_OFFSET + 0x1000. (This includes the default partition CSV files supplied with ESP-IDF.)
  パーティションテーブルのオフセットを 0x8000 よりも高い値に設定して、パーティションテーブルをフラッシュの後に配置します。これにより、ブートローダの利用可能なスペースが増えます。パーティションテーブル CSV ファイルに明示的なパーティションオフセットが含まれている場合、CONFIG_PARTITION_TABLE_OFFSET + 0x1000 より低いオフセットを持つパーティションがないように変更する必要があります (これはデフォルトのパーティション CSV ファイルを含みます)。(これには ESP-IDF と一緒に提供されているデフォルトのパーティション CSV ファイルも含まれます)

##How To Enable Secure Boot

• Open the Project Configuration Menu, navigate to “Secure Boot Configuration” and select the option “One-time Flash”. (To understand the alternative “Reflashable” choice, see Re-Flashable Software Bootloader.)
  プロジェクト構成メニューを開き、「Secure Boot Configuration」に移動し、オプションの「One-time Flash」を選択します。（もう一つの「Reflashable」という選択肢については、「Re-Flashable Software Bootloader」を参照してください)。
  （注：v4.0.1では「Security features」->「Enable hardware secure boot in bootloader」->「One-time Flash」）

• Select a name for the secure boot signing key. This option will appear after secure boot is enabled. The file can be anywhere on your system. A relative path will be evaluated from the project directory. The file does not need to exist yet.
  secure boot signing keyの名前を選択します。このオプションは、セキュアブートが有効になった後に表示されます。ファイルはシステム上の任意の場所に置くことができます。プロジェクトディレクトリからの相対パスが評価されます。ファイルはまだ存在する必要はありません。

• Set other menuconfig options (as desired). Pay particular attention to the “Bootloader Config” options, as you can only flash the bootloader once. Then exit menuconfig and save your configuration
  必要に応じて他の menuconfig オプションを設定します。ブートローダは一度しかフラッシュできないので、「Bootloader Config」オプションには特に注意して設定してください。その後、menuconfig を終了し、設定を保存します。

• The first time you run make, if the signing key is not found then an error message will be printed with a command to generate a signing key via espsecure.py generate_signing_key.
  makeを最初に実行したときに、署名鍵が見つからなかった場合は、エラーメッセージと署名鍵を生成するためのコマンドespsecure.py generate_signing_keyが表示されます。

Important
A signing key generated this way will use the best random number source available to the OS and its Python installation (/dev/urandom on OSX/Linux and CryptGenRandom() on Windows). If this random number source is weak, then the private key will be weak.
このようにして生成された署名鍵は、OSとそのインストールされているPythonで利用可能な最高の乱数源(OSX/Linuxでは/dev/urandom、WindowsではCryptGenRandom()を使用します)を使用します。この乱数源が弱い場合、秘密鍵は弱いものになります。

Important
For production environments, we recommend generating the keypair using openssl or another industry standard encryption program. See Generating Secure Boot Signing Key for more details.
本番環境では、openssl またはその他の業界標準の暗号化プログラムを使用してキーペアを生成することをお勧めします。詳細は「Generating Secure Boot Signing Key」を参照してください。

• Run idf.py bootloader to build a secure boot enabled bootloader. The build output will include a prompt for a flashing command, using esptool.py write_flash.
  idf.py bootloaderを実行して、セキュアブート対応のブートローダをビルドします。ビルドの出力には、esptool.py write_flashを使ったフラッシュコマンドのプロンプトが表示されます。

• When you’re ready to flash the bootloader, run the specified command (you have to enter it yourself, this step is not performed by make) and then wait for flashing to complete. Remember this is a one time flash, you can’t change the bootloader after this!.
  ブートローダをフラッシュする準備ができたら、指定されたコマンドを実行して (自分で入力する必要があります。このステップは make では実行されません)、フラッシュが完了するのを待ちます。これは一度だけのフラッシュなので、この後にブートローダを変更することはできないことを覚えておいてください。

• Run idf.py flash to build and flash the partition table and the just-built app image. The app image will be signed using the signing key you generated in step 4.
  idf.py flashを実行してパーティションテーブルとビルドしたばかりのアプリイメージをフラッシュします。アプリイメージは、ステップ4で生成した署名キーを使用して署名されます。

Note
idf.py flash doesn’t flash the bootloader if secure boot is enabled.
idf.py flash は、セキュアブートが有効な場合、ブートローダをフラッシュしません。

• Reset the ESP32 and it will boot the software bootloader you flashed. The software bootloader will enable secure boot on the chip, and then it verifies the app image signature and boots the app. You should watch the serial console output from the ESP32 to verify that secure boot is enabled and no errors have occurred due to the build configuration.
  ESP32をリセットすると、フラッシュしたソフトウェアブートローダが起動します。ソフトウェアブートローダはチップ上でセキュアブートを有効にし、アプリのイメージ署名を検証してアプリを起動します。ESP32からのシリアルコンソール出力を見て、セキュアブートが有効になっていること、ビルド設定によるエラーが発生していないことを確認してください。

Note
Secure boot won’t be enabled until after a valid partition table and app image have been flashed. This is to prevent accidents before the system is fully configured.
セキュアブートは、有効なパーティションテーブルとアプリイメージがフラッシュされるまで有効になりません。これは、システムが完全に設定される前の事故を防ぐためです。

Note
If the ESP32 is reset or powered down during the first boot, it will start the process again on the next boot.
最初のブート時に ESP32 がリセットされたり、電源が落ちたりすると、次のブート時に再度プロセスが開始されます。

• On subsequent boots, the secure boot hardware will verify the software bootloader has not changed (using the secure bootloader key) and then the software bootloader will verify the signed partition table and app image (using the public key portion of the secure boot signing key).
  次のブートでは、セキュアブートハードウェアはソフトウェアブートローダが変更されていないことを確認し(セキュアブートローダ鍵を使用)、ソフトウェアブートローダは署名されたパーティションテーブルとアプリイメージを確認します(セキュアブート署名鍵の公開鍵部分を使用)。

##Re-Flashable Software Bootloader
Configuration “Secure Boot: One-Time Flash” is the recommended configuration for production devices. In this mode, each device gets a unique key that is never stored outside the device.
「Secure Boot: One-Time Flash」は、本番デバイスで推奨される構成です。このモードでは、各デバイスは一意のキーを取得し、デバイスの外部に保存されることはありません。

However, an alternative mode Secure Boot: Reflashable is also available. This mode allows you to supply a binary key file that is used for the secure bootloader key. As you have the key file, you can generate new bootloader images and secure boot digests for them.
一方、もう一つのモード「Secure Boot: Reflashable」もあります。このモードでは、secure bootloader keyに使用するバイナリ鍵ファイルを提供することができます。鍵ファイルがあれば、新しいブートローダイメージとそのためのセキュアブートダイジェストを生成することができます。

In the esp-idf build process, this 256-bit key file is derived from the ECDSA app signing key generated by the user (see the Generating Secure Boot Signing Key step below). This private key’s SHA-256 digest is used as the secure bootloader key in efuse (as-is for Coding Scheme None, or truncate to 192 bytes for 3/4 Encoding). This is a convenience so you only need to generate/protect a single private key.
esp-idf ビルドプロセスでは、この 256 ビットの鍵ファイルは、ユーザによって生成された ECDSA アプリ署名鍵から派生します (下記のセキュアブート署名鍵の生成ステップを参照してください)。この秘密鍵の SHA-256 ダイジェストが efuse のセキュアブートローダ鍵として使用されます (Coding Scheme None の場合はそのまま、3/4 エンコーディングの場合は 192 バイトに切り捨てます)。これは便利なので、単一の秘密鍵を生成/保護するだけで済みます。

Note
Although it’s possible, we strongly recommend not generating one secure boot key and flashing it to every device in a production environment. The “One-Time Flash” option is recommended for production environments.
1つのsecure boot keyをすべてのデバイスに展開することは、可能ではありますが、本番環境ではこの方法を使わないことを強くお勧めします。本番環境では「One-Time Flash」をお勧めします。

To enable a reflashable bootloader:
リフラッシュ可能なブートローダを有効にするには

1. In the Project Configuration Menu, select “Bootloader Config” -> CONFIG_SECURE_BOOT -> CONFIG_SECURE_BOOT_V1_ENABLED -> CONFIG_SECURE_BOOTLOADER_MODE -> Reflashable.
   Project Configuration Menu で、「Bootloader Config」->「CONFIG_SECURE_BOOT」->「CONFIG_SECURE_BOOT_V1_ENABLED」->「CONFIG_SECURE_BOOTLOADER_MODE」->「Reflashable」を選択します。
   （注：v4.0.1では「Security features」->「Enable hardware secure boot in bootloader」->「Secure bootloader mode」）

2. If necessary, set the CONFIG_SECURE_BOOTLOADER_KEY_ENCODING based on the coding scheme used by the device. The coding scheme is shown in the Features line when esptool.py connects to the chip, or in the espefuse.py summary output.
   必要に応じて、CONFIG_SECURE_BOOT_LOADER_KEY_ENCODING をデバイスが使用するコーディングスキームに基づいて設定します。コーディングスキームは、esptool.pyがチップに接続したときのFeatures行、またはespefuse.pyのサマリー出力に表示されます。

3. Follow the steps shown above to choose a signing key file, and generate the key file.
   上記の手順に従って、署名鍵ファイルを選択し、鍵ファイルを生成します。

4. Run idf.py bootloader. A binary key file will be created, derived from the private key that is used for signing. Two sets of flashing steps will be printed - the first set of steps includes an espefuse.py burn_key command which is used to write the bootloader key to efuse. (Flashing this key is a one-time-only process.) The second set of steps can be used to reflash the bootloader with a pre-calculated digest (generated during the build process).
   idf.py bootloaderを実行します。署名に使用する秘密鍵から派生したバイナリ鍵ファイルが作成されます。フラッシュへの書き込みを行う2つの手順が表示されます。最初の手順には espefuse.py burn_key コマンドが含まれており、bootloader keyを eFuse に書き込むために使われます（このKeyの書込みは一度だけの処理です）。2番目のステップは、ブートローダと、（ビルド中に生成された）ダイジェストをフラッシュに再書き込みするために使われます。

5. Resume from Step 6 of the one-time flashing process, to flash the bootloader and enable secure boot. Watch the console log output closely to ensure there were no errors in the secure boot configuration.
   ブートローダをフラッシュに書込み、セキュアブートを有効にするために、one-time flashing processのStep 6以降を行います。コンソールログの出力をよく見て、セキュアブート設定にエラーがないことを確認してください。

##Generating Secure Boot Signing Key
The build system will prompt you with a command to generate a new signing key via espsecure.py generate_signing_key. This uses the python-ecdsa library, which in turn uses Python’s os.urandom() as a random number source.
ビルドシステムはespsecure.py generate_signing_keyで新しい署名鍵を生成するコマンドを表示します。これは python-ecdsa ライブラリを使用しており、乱数源として Python の os.urandom() を使用しています。

The strength of the signing key is proportional to (a) the random number source of the system, and (b) the correctness of the algorithm used. For production devices, we recommend generating signing keys from a system with a quality entropy source, and using the best available EC key generation utilities.
署名鍵の強さは、(a) システムの乱数源、(b) 使用されているアルゴリズムの正しさに比例します。実運用のデバイスでは、品質の高いエントロピー源を持つシステムから署名鍵を生成し、利用可能な最高の EC 鍵生成ユーティリティを使用することをお勧めします。

For example, to generate a signing key using the openssl command line:
例えば、opensslコマンドラインを使って署名キーを生成するには、次のようにします。

openssl ecparam -name prime256v1 -genkey -noout -out my_secure_boot_signing_key.pem

Remember that the strength of the secure boot system depends on keeping the signing key private.
安全なブートシステムの強さは、署名鍵を秘密にしておくことにかかっていることを覚えておいてください。

##Remote Signing of Images
For production builds, it can be good practice to use a remote signing server rather than have the signing key on the build machine (which is the default esp-idf secure boot configuration). The espsecure.py command line program can be used to sign app images & partition table data for secure boot, on a remote system.
本番環境でのビルドでは、ビルドマシンに署名鍵を持たせるのではなく、リモートの署名サーバを使用するのが良い方法です (これはデフォルトの esp-idf セキュアブート設定です)。espsecure.py コマンドラインプログラムを使うと、アプリイメージとパーティションテーブルデータに対するセキュアブートのための署名を、リモートシステム上で行うことができます。

To use remote signing, disable the option “Sign binaries during build”. The private signing key does not need to be present on the build system. However, the public (signature verification) key is required because it is compiled into the bootloader (and can be used to verify image signatures during OTA updates.
リモート署名を使用するには、"Sign binaries during build" オプションを無効にしてください。プライベート署名鍵はビルドシステム上に存在する必要はありません。ただし、公開鍵(署名検証)はブートローダにコンパイルされているので必要です(OTAアップデート時のイメージ署名の検証にも使用できます)。

To extract the public key from the private key:
秘密鍵から公開鍵を抽出するには

espsecure.py extract_public_key --keyfile PRIVATE_SIGNING_KEY PUBLIC_VERIFICATION_KEY

The path to the public signature verification key needs to be specified in the menuconfig under “Secure boot public signature verification key” in order to build the secure bootloader.
セキュアブートローダをビルドするためには、menuconfig の「Secure boot public signature verification key」で公開署名検証鍵へのパスを指定する必要があります。

After the app image and partition table are built, the build system will print signing steps using espsecure.py:
アプリイメージとパーティションテーブルがビルドされると、ビルドシステムは espsecure.pyを使用して署名ステップを表示します。

espsecure.py sign_data --keyfile PRIVATE_SIGNING_KEY BINARY_FILE

The above command appends the image signature to the existing binary. You can use the –output argument to write the signed binary to a separate file:
上記のコマンドは、既存のバイナリにイメージ署名を追加します。output 引数を使用すると、署名されたバイナリを別のファイルに書き込むことができます。

espsecure.py sign_data --keyfile PRIVATE_SIGNING_KEY --output SIGNED_BINARY_FILE BINARY_FILE

##Secure Boot Best Practices

• Generate the signing key on a system with a quality source of entropy.
  エントロピーの質の高いシステム上で署名鍵を生成する。

• Keep the signing key private at all times. A leak of this key will compromise the secure boot system.
  署名鍵は常に非公開にしてください。この鍵が漏洩すると、安全なブートシステムが危うくなります。

• Do not allow any third party to observe any aspects of the key generation or signing process using espsecure.py. Both processes are vulnerable to timing or other side-channel attacks.
  espsecure.pyを使った鍵生成や署名プロセスのいかなる側面も、第三者に監視させないようにしてください。どちらのプロセスも、タイミングやその他のサイドチャネル攻撃に対して脆弱です。

• Enable all secure boot options in the Secure Boot Configuration. These include flash encryption, disabling of JTAG, disabling BASIC ROM interpeter, and disabling the UART bootloader encrypted flash access.
  セキュアブート設定で、すべてのセキュアブートオプションを有効にしてください。これには、フラッシュ暗号化、JTAG の無効化、BASIC ROM インターペッターの無効化、UART ブートローダの暗号化されたフラッシュアクセスの無効化が含まれます。

• Use secure boot in combination with flash encryption to prevent local readout of the flash contents.
  フラッシュ暗号化と組み合わせてセキュアブートを使用すると、フラッシュコンテンツのローカル読み出しを防ぐことができます。

##Technical Details
The following sections contain low-level reference descriptions of various secure boot elements:
以下のセクションでは、さまざまなセキュアブート要素の低レベルの参照説明が含まれています。

###Secure Boot Hardware Support
The first stage of secure boot verification (checking the software bootloader) is done via hardware. The ESP32’s Secure Boot support hardware can perform three basic operations:
セキュアブート検証の第一段階(ソフトウェアブートローダのチェック)は、ハードウェアを介して行われます。ESP32のセキュアブートサポートハードウェアは、3つの基本的な操作を実行できます。

1. Generate a random sequence of bytes from a hardware random number generator.
   ハードウェア乱数発生器からランダムなバイト列を生成する。

2. Generate a digest from data (usually the bootloader image from flash) using a key stored in Efuse block 2. The key in Efuse can (& should) be read/write protected, which prevents software access. For full details of this algorithm see Secure Bootloader Digest Algorithm. The digest can only be read back by software if Efuse ABS_DONE_0 is not burned (ie still 0).
   eFuse Block 2 に格納されているキーを使用して、データ (通常はフラッシュからのブートローダイメージ) からダイジェストを生成します。eFuse の鍵は、ソフトウェアからのアクセスを防ぐために、読み取り/書き込みで保護することができます(そしてそうすべきです)。このアルゴリズムの詳細については、Secure Bootloader Digest Algorithm を参照してください。ダイジェストは、eFuse ABS_DONE_0 が焼かれていない (つまり 0 のまま) 場合にのみ、ソフトウェアから読み出すことができます。

3. Generate a digest from data (usually the bootloader image from flash) using the same algorithm as step 2 and compare it to a pre-calculated digest supplied in a buffer (usually read from flash offset 0x0). The hardware returns a true/false comparison without making the digest available to software. This function is available even when Efuse ABS_DONE_0 is burned.
   ステップ 2 と同じアルゴリズムを使用して、データ (通常はフラッシュからのブートローダイメージ) からダイジェストを生成し、バッファに供給された事前に計算されたダイジェスト (通常はフラッシュオフセット 0x0 から読み込まれたもの) と比較します。ハードウェアは、ダイジェストをソフトウェアで利用できるようにすることなく、真偽の比較を返します。この関数は、Efuse ABS_DONE_0 が焼かれている場合でも使用可能です。

###Secure Bootloader Digest Algorithm
Starting with an “image” of binary data as input, this algorithm generates a digest as output. The digest is sometimes referred to as an “abstract” in hardware documentation.
入力としてバイナリデータの「イメージ」から始まり、このアルゴリズムは出力としてダイジェストを生成します。ダイジェストは、ハードウェアのドキュメントでは "アブストラクト "と呼ばれることもあります。

For a Python version of this algorithm, see the espsecure.py tool in the components/esptool_py directory (specifically, the digest_secure_bootloader command).
このアルゴリズムの Python バージョンについては、components/esptool_py ディレクトリの espsecure.py ツール (特に digest_secure_bootloader コマンド) を参照してください。

Items marked with (^) are to fulfill hardware restrictions, as opposed to cryptographic restrictions.
(^)でマークされた項目は、暗号化の制限とは対照的に、ハードウェアの制限を満たすためのものです。

1. Read the AES key from efuse block 2, in reversed byte order. If Coding Scheme is set to 3/4 Encoding, extend the 192 bit key to 256 bits using the same algorithm described in Flash Encryption Algorithm.
   ブロック 2 から AES キーをバイト順を逆にして読み出す。Coding Schemeが3/4 Encodingに設定されている場合は、「Flash Encryption Algorithm」に記載されているものと同じアルゴリズムを使用して、192ビットのキーを256ビットに拡張します。

2. Prefix the image with a 128 byte randomly generated IV.
   イメージに128バイトのランダムに生成されたIVをプレフィックスする。

3. If the image length is not modulo 128, pad the image to a 128 byte boundary with 0xFF. (^)
   イメージ長がモジュロ128でない場合は、イメージを128バイトの境界に0xFFでパディングします。(^)

4. For each 16 byte plaintext block of the input image: - Reverse the byte order of the plaintext input block (^) - Apply AES256 in ECB mode to the plaintext block. - Reverse the byte order of the ciphertext output block. (^) - Append to the overall ciphertext output.
   入力画像の 16 バイトの平文ブロックごとに．- 平文入力ブロックのバイト順を逆にする (^) - 平文ブロックに ECB モードの AES256 を適用する．- (^) - 平文ブロックに ECB モードの AES256 を適用．(^) - 暗号文出力全体に追加する．

5. Byte-swap each 4 byte word of the ciphertext (^)
   暗号文の 4 バイトワードをバイトスワップ (^)

6. Calculate SHA-512 of the ciphertext.
   暗号文のSHA-512を計算します。

Output digest is 192 bytes of data: The 128 byte IV, followed by the 64 byte SHA-512 digest.
出力ダイジェストは192バイトのデータです。128バイトのIVに、64バイトのSHA-512ダイジェストを連結したものです。

###Image Signing Algorithm
Deterministic ECDSA as specified by RFC 6979.
RFC 6979 で規定されているDeterministic ECDSA。

Curve is NIST256p (openssl calls this curve “prime256v1”, it is also sometimes called secp256r1).
曲線は NIST256p (openssl はこの曲線を "prime256v1" と呼び、secp256r1 と呼ばれることもあります)。

Hash function is SHA256.
ハッシュ関数はSHA256です。

Key format used for storage is PEM.
保存に使用する鍵フォーマットはPEMです。

In the bootloader, the public key (for signature verification) is flashed as 64 raw bytes.
ブートローダでは、公開鍵(署名検証用)は64 raw bytesとしてフラッシュされます。

Image signature is 68 bytes - a 4 byte version word (currently zero), followed by a 64 bytes of signature data. These 68 bytes are appended to an app image or partition table data.
イメージ署名は68バイト - 4バイトのバージョンワード(現在はゼロ)の後に64バイトの署名データが続きます。これらの 68 バイトは、アプリのイメージやパーティションテーブルのデータに追加されます。

###Manual Commands
Secure boot is integrated into the esp-idf build system, so make will automatically sign an app image if secure boot is enabled. idf.py bootloader will produce a bootloader digest if menuconfig is configured for it.
セキュアブートは esp-idf ビルドシステムに統合されているので、セキュアブートが有効になっていれば make は自動的にアプリイメージに署名します。menuconfig が設定されていれば、idf.py bootloader はブートローダのダイジェストを生成します。

However, it is possible to use the espsecure.py tool to make standalone signatures and digests.
しかし、espsecure.py ツールを使ってスタンドアロンのシグネチャやダイジェストを作成することは可能です。

To sign a binary image:

espsecure.py sign_data --keyfile ./my_signing_key.pem --output ./image_signed.bin image-unsigned.bin

Keyfile is the PEM file containing an ECDSA private signing key.

To generate a bootloader digest:

espsecure.py digest_secure_bootloader --keyfile ./securebootkey.bin --output ./bootloader-digest.bin build/bootloader/bootloader.bin

Keyfile is the 32 byte raw secure boot key for the device.

The output of the espsecure.py digest_secure_bootloader command is a single file which contains both the digest and the bootloader appended to it. To flash the combined digest plus bootloader to the device:

esptool.py write_flash 0x0 bootloader-digest.bin

##Secure Boot & Flash Encryption
If secure boot is used without Flash Encryption, it is possible to launch “time-of-check to time-of-use” attack, where flash contents are swapped after the image is verified and running. Therefore, it is recommended to use both the features together.
フラッシュ暗号化を使用せずにセキュアブートを使用した場合、イメージを検証して実行した後にフラッシュの内容がスワップされてしまう「time-of-check to time-of-use」攻撃が行われる可能性があります。そのため、両方の機能を併用することをお勧めします。

##Signed App Verification Without Hardware Secure Boot
The integrity of apps can be checked even without enabling the hardware secure boot option. This option uses the same app signature scheme as hardware secure boot, but unlike hardware secure boot it does not prevent the bootloader from being physically updated. This means that the device can be secured against remote network access, but not physical access. Compared to using hardware Secure Boot this option is much simpler to implement. See How To Enable Signed App Verification for step by step instructions.
ハードウェアセキュアブートオプションを有効にしなくても、アプリの整合性をチェックすることができます。このオプションはハードウェアセキュアブートと同じアプリ署名方式を使用しますが、ハードウェアセキュアブートとは異なり、 ブートローダが物理的に更新されるのを防ぎません。つまり、デバイスはリモートネットワークアクセスからは保護されますが、物理的なアクセスからは保護されません。ハードウェアセキュアブートを使用する場合と比較して、このオプションは実装が非常にシンプルです。ステップバイステップの手順については、「How To Enable Signed App Verification」を参照してください。

An app can be verified on update and, optionally, be verified on boot.
アプリはアップデート時に検証されます。オプションで起動時に検証することもできます。

• Verification on update: When enabled, the signature is automatically checked whenever the esp_ota_ops.h APIs are used for OTA updates. If hardware secure boot is enabled, this option is always enabled and cannot be disabled. If hardware secure boot is not enabled, this option still adds significant security against network-based attackers by preventing spoofing of OTA updates.
  更新時の検証：有効にすると、esp_ota_ops.h API が OTA 更新で使用されるたびに、署名が自動的にチェックされます。ハードウェアセキュアブートが有効な場合、このオプションは常に有効であり、無効にすることはできません。ハードウェアセキュアブートが有効になっていない場合でも、このオプションはOTAアップデートのなりすましを防止することで、ネットワークベースの攻撃者に対する重要なセキュリティを追加します。

• Verification on boot: When enabled, the bootloader will be compiled with code to verify that an app is signed before booting it. If hardware secure boot is enabled, this option is always enabled and cannot be disabled. If hardware secure boot is not enabled, this option doesn’t add significant security by itself so most users will want to leave it disabled.
  ブート時の検証：有効にすると、ブートローダは、起動前にアプリが署名されているかどうかを検証するコードでコンパイルされます。ハードウェアセキュアブートが有効な場合、このオプションは常に有効であり、無効にすることはできません。ハードウェアセキュアブートが有効になっていない場合、このオプションはそれ自体では重要なセキュリティを追加しないので、ほとんどのユーザは無効にしたままにしておきたいと思うでしょう。

###How To Enable Signed App Verification

1. Open Project Configuration Menu -> Security features -> Enable CONFIG_SECURE_SIGNED_APPS_NO_SECURE_BOOT
   プロジェクト設定メニューを開き、「Security features」->「Enable CONFIG_SECURE_SIGNED_APPS_NO_SECURE_BOOT」を有効にします。
   （注：v4.0.1では、「Security features」->「Require signed app images」を有効にすると、「Verify app signature on update」が表示されて有効になる。）

2. “Bootloader verifies app signatures” can be enabled, which verifies app on boot.
   「Bootloader verifies app signatures」を有効にすると、起動時にアプリを検証します。

3. By default, “Sign binaries during build” will be enabled on selecting “Require signed app images” option, which will sign binary files as a part of build process. The file named in “Secure boot private signing key” will be used to sign the image.
   デフォルトでは、「Require signed app images」を有効にすると「Sign binaries during build」も有効になり、ビルドプロセスの一部としてバイナリファイルに署名します。これにより、ビルドプロセスの一部としてバイナリファイルに署名が行われます。

4. If you disable “Sign binaries during build” option then you’ll have to enter path of a public key file used to verify signed images in “Secure boot public signature verification key”. In this case, private signing key should be generated by following instructions in Generating Secure Boot Signing Key; public verification key and signed image should be generated by following instructions in Remote Signing of Images.
   「Sign binaries during build」オプションを無効にした場合、「Secure boot public signature verification key」に署名済みイメージの検証に使用する公開鍵ファイルのパスを入力する必要があります。この場合、秘密署名鍵は「Generating Secure Boot Signing Key」の手順に従って生成し、検証用公開鍵と署名済みイメージは「Remote Signing of Images」の手順に従って生成する必要があります。

##Advanced Features
##JTAG Debugging
By default, when Secure Boot is enabled then JTAG debugging is disabled via eFuse. The bootloader does this on first boot, at the same time it enables Secure Boot.
デフォルトでは、Secure Boot が有効な場合、JTAG デバッグは eFuse を介して無効になります。ブートローダは最初のブート時にこれを行い、同時にセキュアブートを有効にします。

See JTAG with Flash Encryption or Secure Boot for more information about using JTAG Debugging with either Secure Boot or signed app verification enabled.
セキュアブートまたは署名付きアプリ検証を有効にした状態での JTAG デバッグの使用についての詳細は、フラッシュ暗号化またはセキュアブートを使用した JTAG を参照してください。