ブート時のセキュリティ

ザイリンクスでは、最新の認証方法を使用して、すべてのデバイスのセキュアなブートをサポートし、ザイリンクス デバイス上で認証されていないコードまたは変更されたコードが実行されないようにしています。ザイリンクスでは、認証されたプログラムのみがイメージにアクセスするよう、さまざまな暗号化技術をサポートしています。デバイスごとのハードウェア セキュリティ機能の詳細は、次の各セクションを参照してください。

Zynq-7000 SoC デバイスのセキュア モードおよび非セキュア モード

セキュリティ上の理由により、PS の全マスター モジュールの中で CPU 0 が最初にリセット状態を終了します。CPU 1 は WFE ステートを維持します。bootROM が実行されている間は、安全性を確保するためにリセットの種類に関係なく JTAG は常に無効となります。bootROM の実行が完了した後、ブート モードが非セキュアな場合は JTAG が有効になります。

bootROM コードには、FSBL/ユーザー コードをロードする役目もあります。bootROM がステージ 1 へ制御をリリースすると、ユーザー ソフトウェアがシステム全体を完全に制御します。bootROM を再度実行するには、システム リセットのいずれかを実行する以外に方法はありません。FSBL/ユーザー コードのサイズは、暗号化/非暗号化ともに 192 KB までに制限されています。この制限は、非セキュアの XIP (eXecute-In-Place) オプションを使用する場合は適用されません。

PS ブート ソースは BOOT_MODE ストラップ ピンに弱いプルアップまたはプルダウン抵抗を接続して選択します。このピンは、パワーオン リセット (POR) 時に 1 回だけサンプルされます。サンプルした値は slcr.BOOT_MODE レジスタに格納されます。

bootROM は暗号化/認証されたイメージ (セキュア ブート) と暗号化していないイメージ (非セキュア ブート) をサポートしています。また、非セキュア ブート イメージのみを対象とした場合、XIP (eXecute-In-Place、xip_mode) オプションを使用してステージ 1 イメージを NOR または Quad-SPI から直接実行できます。XIP (eXecute-In-Place) は、NOR および Quad-SPI ブート モードでのみ利用できます。

  • セキュア ブートの場合、bootROM コードを実行している CPU は、ブート デバイス上のユーザー PS イメージを復号化/認証して OCM に格納した後、このイメージに分岐します。
  • 非セキュア ブートの場合、bootROM を実行している CPU は、PL 内の AES ユニットなどすべてのセキュア ブート機能を無効にした後、OCM メモリまたはフラッシュ デバイス (XIP (eXecute-In-Place) を使用した場合) 内のユーザー イメージに分岐します。

これ以降の PS または PL に対するブート ステージは開発者であるユーザーの責任で、ユーザー制御下で実行する必要があります。bootROM コードにはユーザーからはアクセスできません。ステージ 1 ブートがセキュア ブートの場合、その後のブート ステージはセキュアまたは非セキュアのどちらも可能です。ステージ 1 ブートが非セキュア ブートの場合、その後のブート ステージは非セキュア ブートしか実行できません。

Zynq UltraScale+ MPSoC デバイスのセキュリティ

Zynq® UltraScale+™ MPSoC デバイスでは、ハードウェア ルート オブ トラストのブート メカニズムを使用してセキュア ブートが実行されます。これにより、すべてのブート ファイルまたはコンフィギュレーション ファイルも暗号化されます。このアーキテクチャは、アプリケーションの安全性を最大限に確保するために必要な機密性、完全性、および認証を提供します。

詳細は、『Zynq UltraScale+ デバイス テクニカル リファレンス マニュアル』 (UG1085: 英語版日本語版)このセクションを参照してください。

暗号化の使用

セキュア ブートは、デバイス上のイメージの実行が許可される前にこれらを検証するため、フィールドで展開されているほとんどの電子デバイスにとって不可欠な機能となっています。暗号化については、ザイリンクスでは AES (Advanced Encryption Standard) アルゴリズムによる AES 暗号化をサポートしています。

AES では、対称型キー暗号 (暗号化と復号化の両方に対応する 1 つのキー定義) が提供されます。暗号化と復号化の両方を逆の順序で完了する場合も、同じステップが実行されます。

AES は反復式の対称型ブロック暗号であり、次のように動作します。

  • 同じ定義されたステップを複数回繰り返して動作する。
  • 秘密キーの暗号化アルゴリズムを使用する。
  • 固定バイト数で動作する。

暗号化プロセス

Bootgen は、BIF ファイルでユーザーが提供する暗号化コマンドおよび属性に基づいてブート イメージ パーティションを暗号化できます。AES は対称キー暗号化手法であり、暗号化および復号化に同じキーを使用します。ブート イメージの暗号化に使用するキーは、デバイスがそのブート イメージでブート中、復号化プロセス用にデバイスで使用可能であることが求められます。一般に、キーは eFUSE または BBRAM のいずれかに格納され、キー ソースはブート イメージの作成時に BIF 属性を介して選択できます (次の図参照)。

1: 暗号化プロセスの図

復号化プロセス

SoC デバイスの場合、ブート サイクル中に bootROM および FSBL によってパーティションが復号化されます。bootROM は、フラッシュから FSBL を読み出し、復号化し、ロードし、制御を FSBL に渡します。FSBL の実行が開始されると、残りのパーティションが読み込まれ、復号化され、ロードされます。パーティションの復号化に必要な AES キーは、eFUSE または BBRAM のいずれかから取得できます。暗号化キーのソースを把握するために、ブート イメージ内のブート ヘッダー テーブルのキー ソース フィールドが読み出されます。暗号化されたパーティションはそれぞれ、AES ハードウェア エンジンを使用して復号化されます。

2: 復号化プロセスの図

Zynq-7000 デバイスのパーティションの暗号化

Zynq®-7000 SoC デバイスは、内蔵型でプログラマブル ロジック (PL) ベースの HMAC (Hash-based Message Authentication Code)、および Cipher Block Chaining (CBC) モードの Advanced Encryption Standard (AES) モジュールを使用します。

BIF ファイルの例

暗号化されたパーティションを持つブート イメージを作成するには、aeskeyfile 属性を使用して BIF で AES キー ファイルを指定します。暗号化する BIF ファイルにリストされている各イメージ ファイルに対して encryption=aes 属性を指定します。BIF ファイル (secure.bif) の例を次に示します。

image: 
{
	[aeskeyfile] secretkey.nky
	[keysrc_encryption] efuse
	[bootloader, encryption=aes] fsbl.elf
	[encryption=aes] uboot.elf
}
コマンド ラインから、次のコマンドを使用して、暗号化された fsbl.elf および uboot.elf を含むブート イメージを生成します。
bootgen -arch zynq -image secure.bif -w -o BOOT.bin

キーの生成

Bootgen は AES-CBC キーを生成できます。Bootgen は、BIF で指定された AES キー ファイルを使用し、パーティションを暗号化します。キー ファイルが空または存在しない場合、Bootgen は BIF ファイルで指定されたファイルにキーを生成します。キー ファイルが BIF で指定されておらず、いずれかのパーティションに対して暗号化が要求されている場合、Bootgen は BIF と同じディレクトリに拡張子 .nky の BIF ファイル名を用いたキー ファイルを生成します。次に、キー ファイルの例を示します。

3: キー ファイルの例

Zynq MPSoC デバイスのパーティションの暗号化

Zynq® UltraScale+™ MPSoC デバイスは、AES-GCM コアを使用します。このコアは 32 ビット ワード ベースのデータ インターフェイスを備えており、256 ビット キーをサポートします。AES-GCM モードは、暗号化と復号化、複数のキーソース、内蔵のメッセージ インテグリティ チェックをサポートします。

操作キー

優れたキー管理の方法の 1 つは、秘密キーの使用を最小限に抑えることです。このためには、Bootgen で有効になっている操作キー オプションを使用します。

Bootgen は、暗号化された安全なヘッダーを作成します。このヘッダーには、ユーザー指定の操作キー (opt_key) と、Bootgen が有効のときにコンフィギュレーション ファイルの最初のブロックに必要な初期化ベクトル (IV) が含まれます。このため、BBRAM または eFUSE のいずれかに格納された AES キーは 384 ビットのみで使用され、サイド チャネル攻撃にさらされる可能性がかなり低くなります。opt_key 属性は、操作キーの使用方法を指定するものです。fsbl_config 属性に対する引数であるopt_key 値の詳細は、fsbl_configを参照してください。次に、opt_key 属性の使用例を示します。

image:
{
	[fsbl_config] opt_key
	[keysrc_encryption] bbram_red_key 
	 
	[bootloader, 
	 destination_cpu = a53-0,
	 encryption      = aes, 
	 aeskeyfile      = aes_p1.nky]fsbl.elf
	 
	[destination_cpu = a53-3,
	 encryption      = aes, 
	 aeskeyfile      = aes_p2.nky]hello.elf
	 
}

操作キーは、次に示すように、AES キー (.nky) ファイルで Key Opt 名を用いて与えられます。

4: 操作キー

Bootgen は暗号化キー ファイルを生成します。前の例に示すように、BIF ファイルで opt_key が有効になっている場合、操作キー opt_key.nkyファイルで生成されます。

操作キーを使用するその他の例は、操作キーを使用した開発環境のデバイス キーの保護を参照してください。

この機能の詳細は、『Zynq UltraScale+ デバイス テクニカル リファレンス マニュアル』 (UG1085: 英語版日本語版)の「セキュリティ」章のキー管理を参照してください。

キーの差し替え

AES-GCM は、暗号化されたイメージ全体をより小規模な AES 暗号化ブロック/モジュール単位で表すキー差し替え機能もサポートしています。各モジュールは独自のキーを使用して暗号化されます。最初のキーはデバイスのキー ソースで格納され、後続の各モジュールのキーは直前のモジュール内で暗号化 (ラップ) されます。キー差し替えをサポートするブート イメージは、Bootgen を使用して生成できます。BIF の属性 (blocks) を使用して、暗号化用に複数の小さなブロックを作成するためのパターンを指定します。

image:
{
	[keysrc_encryption] bbram_red_key
		
	[
		bootloader, 
		destination_cpu = a53-0,
		encryption      = aes, 
		aeskeyfile      = aes_p1.nky,
		blocks          = 1024(2);2048;4096(2);8192(2);4096;2048;1024 
	]    fsbl.elf
	 	
	[
		destination_cpu = a53-3,
		encryption      = aes, 
		aeskeyfile      = aes_p2.nky,
		blocks          = 4096(1);1024 
	]    hello.elf
}
注記:
  • キー ファイル内のキーの数は、暗号化されるブロックの数と常に一致する必要があります。
    • キーの数が暗号化されるブロック数より少ない場合、Bootgen はエラーを返します。
    • キーの数が暗号化されるブロック数より多い場合、Bootgen は余分なキーを無視します。
  • 複数のキー/IV ペアを指定する場合は、no. of blocks + 1 ペアを指定する必要があります。
    • 余ったキー/IV ペアは、セキュア ヘッダーの暗号化に使用されます。

グレー/難読化キー

ユーザー キーは、ファミリ キーで暗号化されており、デバイスの金属層に埋め込まれています。このファミリ キーは、Zynq® UltraScale+™ MPSoC のすべてのデバイスで同じであり、結果、難読化キーとして使用されます。難読化キーは、認証されたブート ヘッダーまたは eFUSE のいずれかに配置できます。

image:
{
	[keysrc_encryption] efuse_gry_key 
	[bh_key_iv] bhiv.txt
	[
		bootloader, 
		destination_cpu = a53-0,
		encryption      = aes, 
		aeskeyfile      = aes_p1.nky
	]    fsbl.elf 
	[
		destination_cpu = r5-0,
		encryption      = aes,
		aeskeyfile      = aes_p2.nky 
	]    hello.elf
}

Bootgen は、イメージの作成中に次を実行します。

  1. ブート ヘッダーの BH IV フィールドに bhiv.txt の IV を置きます。
  2. ブート ヘッダーのセキュア ヘッダー IV フィールドに aes.nky の IV 0 を置きます。
  3. aes.nky の Key0 および IV0 を使用して、パーティションを暗号化します。

グレー/ファミリ キーを使用する別の例については、ユース ケースおよび例を参照してください。

この機能の詳細は、『Zynq UltraScale+ デバイス テクニカル リファレンス マニュアル』 (UG1085: 英語版日本語版) を参照してください。

キーの生成

Bootgen には、AES-GCM キーを生成する機能があります。Bootgen は、NIST が認定する Counter Mode KDF を使用し、CMAC を疑似ランダム関数として使用します。ユーザーがキー ローリングのためにシードから複数のキーを派生させる場合、Bootgen はシードを入力として受け取ります。シードが指定されている場合、これを使用してキーが生成されます。シードが指定されていない場合、Key0 に基づいてキーが生成されます。空のキー ファイルが指定されている場合、Bootgen は時間ベースのランダム化 (KDF ではない) でシードを生成します。これは KDF がほかのキー/IV ペアを生成するための入力となります。

注記:
  • 1 つの暗号化ファイルが指定され、ほかの暗号化ファイルが生成される場合、Bootgen は最初のパーティションの暗号化ファイルにある Key0/IV0 ペアと同じものを生成されたキーに使用できます。
  • 最初のパーティションに暗号化ファイルが生成され、それ以降のパーティションには Key0/IV0 を含むほかの暗号化ファイルが指定されると、Bootgen は終了し、誤った Key0/IV0 ペアが使用されたというエラーを返します。
キーの生成

キー ファイルのサンプルを次に示します。

5: キー ファイルの例
難読化キーの生成

Bootgen は、ファミリ キーと、ユーザー提供の IV を用いてレッド キーを暗号化することで難読化キーを生成できます。ファミリ キーは、ザイリンクス セキュリティ グループが提供します。詳細は、familykey を参照してください。難読化キーを生成するために、Bootgen は BIF ファイルから次の入力を取得します。

obf_key:
{
	[aeskeyfile] aes.nky  
	[familykey] familyKey.cfg 
	[bh_key_iv] bhiv.txt
}

難読化キーを生成する構文は、次のとおりです。

bootgen -arch zynqmp -image all.bif -generate_keys obfuscatedkey

ブラック キー/PUF キー

ブラック キーのストレージ ソリューションは、PUF から生成された暗号強度の高い KEK (key encryption key) を使用し、ユーザー キーを暗号化します。生成されたブラック キーは、eFUSE に格納するか、認証されたブート ヘッダーの一部として格納できます。

image:
{ 
	[puf_file] pufdata.txt
	[bh_key_iv] black_iv.txt
	[bh_keyfile] black_key.txt
	[fsbl_config] puf4kmode, shutter=0x0100005E, pufhd_bh
	[keysrc_encryption] bh_blk_key 
	
	[
	  bootloader,
	  destination_cpu = a53-0,
	  encryption      = aes, 
	  aeskeyfile      = aes_p1.nky
	] fsbl.elf
		 
	[
	  destination_cpu = r5-0,
	  encryption      = aes,
	  aeskeyfile      = aes_p2.nky
	] hello.elf
}

ブラック キーを使用するその他の例は、ユース ケースおよび例を参照してください。

複数の暗号化キー ファイル

以前のバージョンの Bootgen では、1 つの暗号化キーで複数のパーティションを暗号化してブート イメージを作成できました。この場合、各パーティションで同じキーが繰り返し使用されます。これはセキュリティの脆弱性の要因となるため、推奨されていません。各キーの使用は、フローで一度だけとする必要があります。

Bootgen は、パーティションごとに個別の暗号化キーをサポートしています。キー ファイルが複数ある場合、各暗号化キー ファイルで同じ Key0 (デバイス キー)、IV0、および操作キーが使用されるようにしてください。各暗号化キー ファイルでブート イメージが異なると、Bootgen でブート イメージを作成できません。ユーザーが複数の暗号化キー ファイル (イメージ内の各パーティションに 1 つずつ) を指定する必要があります。パーティションは、各パーティションに指定されたキーを使用して暗号化されます。

注記: ファイル名に ".1", ".2"...".n" を付けたキー ファイルを該当パーティションのキー ファイルの同じディレクトリに置くことで、ロード可能なセクションが複数あるために作成された各パーティションに対して一意のキー ファイルを使用できます。

次は、サンプルの暗号化キー ファイルの一部を示しています。

all:
{
	[keysrc_encryption] bbram_red_key
	// FSBL (Partition-0)
	[
		bootloader, 
		destination_cpu = a53-0, 
		encryption = aes,
		aeskeyfile = key_p0.nky
		
	]fsbla53.elf
				 
	// application (Partition-1)
	[
		destination_cpu = a53-0,
		encryption = aes,
		aeskeyfile = key_p1.nky
			
	]hello.elf  
}
  • fsbla53.elf パーティションは、key_p0.nky ファイルのキーで暗号化されます。
  • hello.elf にロード可能なセクションが 3 つあるため 3 つのパーティションが存在するとした場合、hello.elf.0 パーティションは test2.nky ファイルのキーで暗号化されます。
  • 続いて hello.elf.1 パーティションが test2.1.nky のキーで暗号化されます。
  • hello.elf.2 パーティションは test2.2.nky のキーで暗号化されます。

認証の使用

AES 暗号化は対称キーを用いた自己認証アルゴリズムで、暗号化と復号化に同じキーを使用します。したがって、このキーは非公開キーとして保護する必要があり、キーを格納するための領域が内部に必要になります。RSA (Rivest Shamir Adleman) による認証手段もあります。RSA は非対称アルゴリズムで、署名に使用するキーと検証に使用するキーが異なります。認証には一対のキーが必要です。

  • 署名には、秘密キーを使用します。
  • 検証には、公開キーを使用します。

この公開キーは保護の必要がないため、セキュアな格納領域は不要です。この認証方式と暗号化を組み合わせることにより、真正性と機密性の両方を確保できます。RSA は、暗号化されているパーティションと暗号化されていないパーティションのいずれにも使用可能です。

RSA のメリットは、公開キーを使用することだけではなく、復号化する前に認証を実行できることが挙げられます。RSA 公開キーのハッシュ値は eFUSE に格納する必要があります。ザイリンクス SoC デバイスでは、パーティション データは AES 復号化エンジンに送信される前に認証されます。この方法では、パーティション データの真正性を確認してから復号化を実行することになるため、復号化エンジンへの攻撃を防ぐことができます。

ザイリンクス SoC では、公開キーと秘密キーの 2 つのペアが使用されます (プライマリおよびセカンダリ)。プライマリ公開/秘密キーは、セカンダリ公開/秘密キー ペアを認証します。セカンダリ キーは、パーティションを署名/検証します。

キーを示す頭文字の最初のアルファベットは、プライマリの場合 P、セカンダリの場合 S となります。キーを示す頭文字の 2 番目のアルファベットは、公開の場合 P、秘密の場合 S となります。キーの種類は次の 4 つです。

  • PPK = プライマリ公開キー
  • PSK = プライマリ秘密キー
  • SPK = セカンダリ公開キー
  • SSK = セカンダリ秘密キー

Bootgen は、次の 2 つの方法で認証証明を作成できます。

  • PSK と SSK を与えます。これらの 2 つの入力を使用し、SPK 署名がオンザフライで計算されます。
  • PPK と SSK、そして SPK 署名を入力として与えます。この方法は、PSK がわからない場合に使用されます。

プライマリ キーはハッシュ化されて eFUSE 内に格納されます。このハッシュ値は、FSBL によってブート イメージに格納されたプライマリ キーのハッシュ値と比較されます。このハッシュは、Vitis に付属するスタンドアロン ドライバーを使用して PS の eFUSE メモリに書き込むことができます。

BIF ファイルの例を次に示します。

image:
{ 
	[pskfile]primarykey.pem
	[sskfile]secondarykey.pem
	[bootloader,authentication=rsa] fsbl.elf
	[authentication=rsa]uboot.elf
}

デバイス固有の認証の詳細は、次の資料を参照してください。

署名

次の図に、パーティションに対する RSA 署名を示します。Bootgen は、セキュアな施設から秘密キーを使用してパーティションに署名を与えます。ここでは、署名プロセスについて次の手順で解説します。

  1. PPK および SPK は、認証証明 (AC) に格納されます。
  2. SPK は、PSK で署名されて SPK 署名を取得します。また、AC の一部としても格納されます。
  3. パーティションは、SSK で署名されてパーティション署名を取得し、AC に格納されます。
  4. AC は、認証が選択されている各パーティションに追加されます。
  5. PPK はハッシュ化されて eFUSE 内に格納されます。
6: パーティションに対する RSA 署名

次の表に、認証のオプションを示します。

表 1. 認証キーに対してサポートされているファイル フォーマット
キー 名称 説明 サポートされているファイル フォーマット
PPK プライマリ公開キー パーティションを認証するために使用するキーです。

パーティションの認証時に必ず指定する必要があります。

*.txt

*.pem

*.pub

*.pk1

PSK プライマリ秘密キー パーティションを認証するために使用するキーです。

パーティションの認証時に必ず指定する必要があります。

*.txt

*.pem

*.pk1

SPK セカンダリ公開キー このキーを指定した場合、パーティションの認証に使用されます。 *.txt

*.pem

*.pub

*.pk1

SSK セカンダリ秘密キー このキーを指定した場合、パーティションの認証に使用されます。 *.txt

*.pem

*.pk1

検証

デバイス内では、公開キーを使用して、bootROM が FSBL を検証し、FSBL または U-Boot のいずれかが続くパーティションを検証します。

  1. PPK の検証 - この手順では、プライマリ キーの認証が確立されます。プライマリ キーは、セカンダリ キーの認証に使用します。
    1. ブート イメージの AC から PPK が読み出されます。
    2. PPK ハッシュ値を生成します。
    3. ハッシュ化された PPK と、eFUSE から取得された PPK ハッシュ値を比較します。
    4. 同じ場合はプライマリ キーが信頼されます。そうでない場合はセキュア ブート エラーとなります。
  2. セカンダリ キーの検証 - この手順では、セカンダリ キーの認証が確立されます。セカンダリ キーはパーティションの認証に使用します。
    1. ブート イメージの AC から SPK が読み出されます。
    2. SPK ハッシュ値を生成します。
    3. PSK を使用して AC に格納されている SPK 署名を検証し、SPK ハッシュ値を取得します。
    4. ステップ (b) およびステップ (c) からのハッシュ値を比較します。
    5. 同じ場合はセカンダリ キーが信頼されます。そうでない場合はセキュア ブート エラーとなります。
  3. パーティションの検証 - この手順では、ブートされているパーティションの信頼性を確立します。
    1. ブート イメージからパーティションが読み出されます。
    2. パーティションのハッシュ値を生成します。
    3. SSK を使用して AC に格納されているパーティション署名を検証し、パーティション ハッシュ値を取得します。
    4. ステップ (b) およびステップ (c) からのハッシュ値を比較します。
    5. 同じ場合はパーティションが信頼されます。そうでない場合はセキュア ブート エラーとなります。
7: 検証のフロー図

Bootgen は、次の 2 つの方法で認証証明を作成できます。

  • PSK と SSK を与えます。これらの 2 つの入力を使用し、SPK 署名がオンザフライで計算されます。
  • PPK と SSK、そして SPK 署名を入力として与えます。この方法は、PSK がわからない場合に使用されます。

Zynq UltraScale+ MPSoC の認証サポート

Zynq® UltraScale+™ MPSoC デバイスは RSA-4096 認証を使用するため、プライマリ キーおよびセカンダリ キーのサイズは 4096 ビットとなります。

NIST SHA-3 のサポート

注記: SHA-3 認証では、ブート ヘッダー、PPK、およびブート イメージのハッシュ値の計算に Keccak SHA-3 が常に使用されます。ROM によってロードされないその他すべてのパーティションには、NIST-SHA3 が使用されます。

生成された署名は、次の表に基づいて Keccak-SHA3 または NIST-SHA3 を使用します。

表 2. 認証署名
認証証明 (AC) の種類 シグネチャ SHA アルゴリズムおよび SPK eFUSE 署名の生成に使用される秘密キー
ヘッダー AC (FSBL/FW によってロードされる) SPK 署名 SPKID eFUSE の場合 Keecak、ユーザー eFUSE の場合は NIST PSK
BH 署名 常に Keecak SSKheader
ヘッダー署名 常に NIST SSKheader
ブートローダー AC (ROM によってロードされる) SPK 署名 常に Keecak、常に SPK 用の SPKID eFUSE PSK
BH 署名 常に Keecak SSKBootloader
ヘッダー署名 常に Keecak SSKBootloader
パーティション AC (FSBL FW によってロードされる) SPK 署名 SPKID eFUSE の場合 Keecak、ユーザー eFUSE の場合は NIST PSK
BH 署名 常に Keecak SSKPartition
ヘッダー署名 常に NIST SSKPartition

例 1: 1 つのキー ファイル セットでパーティションを認証するための BIF ファイル

image:
{
	[fsbl_config] bh_auth_enable
	[auth_params] ppk_select=0; spk_id=0x00000000
	[pskfile] primary_4096.pem
	[sskfile] secondary_4096.pem
	[pmufw_image] pmufw.elf
	[bootloader, authentication=rsa, destination_cpu=a53-0] fsbl.elf
	[authenication=rsa, destination_cpu=r5-0] hello.elf
}

例 2: パーティションごとに個別のセカンダリ キーを使用してパーティションを認証するための BIF ファイル

image:
{
	[auth_params] ppk_select=1
	[pskfile] primary_4096.pem
	[sskfile] secondary_4096.pem
	
	// FSBL (Partition-0)
	[
	  bootloader,
	  destination_cpu = a53-0,
	  authentication = rsa,
	  spk_id = 0x01,
	  sskfile = secondary_p1.pem
	] fsbla53.elf

	// ATF (Partition-1)
	[
	  destination_cpu = a53-0,
	  authentication = rsa,
	  exception_level = el-3,
	  trustzone = secure,
	  spk_id = 0x01,
	  sskfile = secondary_p2.pem
	] bl31.elf
	
	// UBOOT (Partition-2)
	[
	  destination_cpu = a53-0, 
	  authentication = rsa,
	  exception_level = el-2,
	  spk_id = 0x01,
	  sskfile = secondary_p3.pem
	] u-boot.elf
}

外部メモリを使用したビットストリーム認証

ビットストリームの認証は、その他のパーティションとは異なります。FSBL は、OCM 内にすべて含めることが可能であるため、デバイス内部で認証して復号化できます。ビットストリームの場合は、ファイル サイズが非常に大きいためデバイス内にすべてを含めることができず、外部メモリを使用する必要があります。外部メモリを使用すると、攻撃者がこの外部メモリに侵入する可能性があるため、セキュリティ管理という課題が生じます。ビットストリームの認証が要求されると、Bootgen はビットストリーム全体を 8MB ブロックに分割し、各ブロックに認証証明が与えられます。ビットストリームが 8MB の倍数でない場合は、最後のブロックに残りのビットストリーム データが含まれます。認証と暗号化の両方が有効の場合は、最初にビットストリームの暗号化が実行されます。その後、Bootgen は暗号化されたデータをブロックに分割して、各ブロックに認証証明を提供します。

8: 外部メモリを使用したビットストリーム認証

ユーザー eFUSE サポートおよび RSA キー取り消しの改善

RSA キー取り消しサポートの改善

RSA キーは、すべてのパーティションのセカンダリ キーを取り消すことなく、1 つのパーティションのセカンダリ キーを取り消すことができます。

注記: プライマリ キーは、すべてのパーティションで同じものである必要があります。

これには、USER_FUSE0USER_FUSE7 の eFUSE と、BIF パラメーターの spk_select を使用します。

注記: すべてのキーを使用する必要がない場合は、最大で 256 個のキーを取り消すことができます。

次の BIF ファイルの例は、改善されたユーザー eFUSE 取り消しを示しています。イメージ ヘッダーおよび FSBL は、下記の例を BIF へ追加することで、認証に異なる SSK を使用します (それぞれ ssk1.pem および ssk2.pem)。

the_ROM_image:
{
	[auth_params]ppk_select = 0
	[pskfile]psk.pem
	[sskfile]ssk1.pem
	[
	  bootloader,
	  authentication = rsa,
	  spk_select = spk-efuse,
	  spk_id = 0x8,
	  sskfile = ssk2.pem
	] zynqmp_fsbl.elf
	[
	  destination_cpu = a53-0,
	  authentication = rsa,
	  spk_select = user-efuse,
	  spk_id = 0x200,
	  sskfile = ssk3.pem
	] application.elf
	[
	  destination_cpu = a53-0,
	  authentication = rsa,
	  spk_select = spk-efuse,
	  spk_id = 0x8,
	  sskfile = ssk4.pem
	] application2.elf
} 
  • spk_select = spk-efuse の場合、そのパーティションに spk_id eFUSE が使用されることを意味します。
  • spk_select = user-efuse の場合、そのパーティションにユーザー eFUSE が使用されることを意味します。

CSU ROM によってロードされるパーティションは、常に spk_efuse を使用します。

注記: spk_id eFUSE は、どのキーが有効であるかを指定します。したがって、ROM は spk_id eFUSE のフィールド全体を SPK ID と照合してビットが一致することを確認します。

ユーザー eFUSE は、どのキー ID が有効でない (取り消された) かを指定します。したがって、ファームウェア (ROM 以外) は、SPK ID を表すそのユーザー eFUSE がプログラムされているかどうかをチェックします。

キーの生成

Bootgen には RSA キーを生成する機能があります。または、OpenSSL などの外部ツールを使用してキーを作成することもできます。Bootgen は BIF ファイルで指定したパスにキーを作成します。

次の図は、RSA 秘密キー ファイルの例です。
9: RSA 秘密キー ファイルの例
注記: 公開コンポーネントには、通常拡張子 .pub が使用されます。これは、公開コンポーネントおよび秘密コンポーネント両方を含む秘密キーから抽出できます。秘密キーには、通常拡張子 .pem が使用されます。公開キー コンポーネントを生成するには、上記の例の pskfile/sskfile の代わりに ppkfile/spkfile を使用します。
BIF の例

BIF ファイルの例 generate_pem.bif を次に示します。

generate_pem:
{
	[pskfile] psk0.pem
	[sskfile] ssk0.pem
}
コマンド

キーを生成する構文は、次のとおりです。

bootgen -generate_keys pem -arch zynqmp -image generate_pem.bif

eFUSE 用の PPK ハッシュ

Bootgen は、PPK が信頼されることを確実にすることを目的とした、eFUSE に格納するための PPK ハッシュを生成します。次に示す手順は、eFUSE モードの RSA 認証でのみ実行する必要があり、Zynq® UltraScale+™ MPSoC デバイスの RSA ブート ヘッダー認証ではスキップできます。efuseppksha.txt からの値は、eFUSE にプログラムして、eFUSE モードの RSA 認証に使用できます。

BBRAM および eFUSE プログラミングの詳細は、『BBRAM および eFUSE のプログラミング』 (XAPP1319: 英語版日本語版) を参照してください。

BIF ファイルの例

BIF ファイルの例 (generate_hash_ppk.bif) を次に示します。

generate_hash_ppk:
{
	[pskfile] psk0.pem
	[sskfile] ssk0.pem
	[bootloader, destination_cpu=a53-0, authentication=rsa] fsbl_a53.elf
}
コマンド

eFUSE プログラミング用の PPK ハッシュを生成するコマンドは次のとおりです。

bootgen –image generate_hash_ppk.bif –arch zynqmp –w –o /
test.bin –efuseppkbits efuseppksha.txt

HSM モードの使用

現在の暗号技術では、すべてのアルゴリズムが公開されているため、秘密キーの保護が重要です。ハードウェア セキュリティ モジュール (HSM) は、暗号化キーのライフサイクルを保護するために特別に設計された専用の暗号処理デバイスであり、公開キーのみが Bootgen に渡され、秘密キーは渡されないことからキー処理セキュリティが向上します。標準モードも利用可能です。このモードではキーを渡す必要はありません。

一部の組織では、情報セキュリティ担当者がセキュア エンベデッド製品のプロダクション リリースを担当します。情報セキュリティ スタッフは、デジタル署名に HSM を使用し、暗号化には別のセキュア サーバーを使用することがあります。HSM とセキュア サーバーは、通常はセキュア エリア内に配置されます。HSM はセキュア キー/署名生成デバイスであり、秘密キーを生成し、秘密キーを使用してパーティションを署名し、RSA キーの公開部分を Bootgen に提供します。秘密キーは、HSM にのみ配置されます。

HSM モードの Bootgen は、RSA 公開キーと、ブート イメージを生成するために HSM によって作成された署名のみを使用します。HSM は、Bootgen によって生成されたパーティションのハッシュ値を受け入れ、ハッシュ値と RSA 秘密キーに基づいて署名ブロックを返します。

HSM モードとは対照的に、標準モードの Bootgen は、イメージ内のパーティションの暗号化および認証に AES 暗号化キーと BIF ファイルで提供される RSA 秘密キーそれぞれ使用します。出力は 1 つのブート イメージであり、暗号化されて認証されています。認証用に、ユーザーは公開キーと秘密キーの両方のセットを提供する必要があります。Bootgen は秘密キーを使用してパーティションに署名を入れ、署名を作成します。これらの署名は公開キーと共に最終的なブート イメージに埋め込まれます。

FPGA の HSM モードの詳細は、FPGA の HSM モードを参照してください。

高度なキー管理オプションの使用

秘密キーに関連付けられた公開キーは、ppk.pub および spk.pub です。HSM は、Bootgen によって生成されたパーティションのハッシュ値を受け入れ、ハッシュ値と秘密キーに基づいて署名ブロックを返します。

HSM モードを使用したブート イメージの作成: PSK の共有なし

次の図に、HSM モードを使用するステージ 0 〜ステージ 2 のブート スタックを示します。SSK を配布することでステップ数が削減されています。

この図では、Zynq® UltraScale+™ MPSoC デバイスを使用して各ステージを説明しています。

10: 一般的な 3 ステージ ブート イメージ

ブート プロセス

HSM モードを使用したブート イメージの作成は、次の BIF ファイルを使用して標準フローでブート イメージを作成するのと似ています。

all:
{
	[auth_params] ppk_select=1;spk_id=0x12345678
	[keysrc_encryption]bbram_red_key
	[pskfile]primary.pem
	[sskfile]secondary.pem
	[
	 bootloader,
	 encryption=aes,
 	aeskeyfile=aes.nky,
	 authentication=rsa
	]fsbl.elf
	[destination_cpu=a53-0,authentication=rsa]hello_a53_0_64.elf
}

ステージ 0: HSM モードを使用してブート イメージを作成

信頼されている個人が、プライマリ秘密キーを使用して SPK 署名を作成します。SPK 署名は、認証証明ヘッダー、SPK、および SPK にあります。上記のためのハッシュを生成するには、次の BIF ファイルの抜粋を使用します。

stage 0:
{
	[auth_params] ppk_select=1;spk_id=0x12345678
	[spkfile]keys/secondary.pub
}

Bootgen コマンドは次のとおりです。

bootgen -arch zynqmp -image stage0.bif -generate_hashes

このコマンドの出力は secondary.pub.sha384 です。

ステージ 1: SPK 署名を配布

信頼されている個人が SPK 署名を開発チームに配布します。

openssl rsautl -raw -sign -inkey keys/primary0.pem -in secondary.pub.sha384 > secondary.pub.sha384.sig 

このコマンドの出力は secondary.pub.sha384.sig です。

ステージ 2: FSBL で AES を使用して暗号化

開発チームが Bootgen を使用して必要な数のブート イメージを作成します。開発チームは次を使用します。

  • 信頼されている個人からの SPK 署名。
  • セカンダリ秘密キー (SSK)、SPK、および SPKID
Stage2:
{
	[keysrc_encryption]bbram_red_key 
	[auth_params] ppk_select=1;spk_id=0x12345678
	[ppkfile]keys/primary.pub
	[sskfile]keys/secondary0.pem
	[spksignature]secondary.pub.sha384.sig 
	[bootloader,destination_cpu=a53-0, encryption=aes, aeskeyfile=aes0.nky, authentication=rsa] fsbl.elf 
	[destination_cpu=a53-0, authentication=rsa] hello_a53_0_64.elf 
}
Bootgen コマンドは次のとおりです。
bootgen -arch zynqmp -image stage2.bif -o final.bin

HSM モードを使用した Zynq-7000 SoC デバイス ブート イメージの作成

次の図に、Zynq®-7000 SoC デバイスのHSM モードのブート イメージを示します。この図の後にブート イメージを作成する手順を示します。

11: ステージ 0 ~ 8 のブート プロセス

HSM モードを使用して Zynq®-7000 SoC デバイスのブート イメージを作成するプロセスは、次の BIF ファイルを使用して標準フローでブート イメージを作成するのと似ています。これらの例は、必要に応じてハッシュ ファイルを生成するために OpenSSL プログラムを使用します。

all:
{
	[aeskeyfile]my_efuse.nky 
	[pskfile]primary.pem 
	[sskfile]secondary.pem
	[bootloader,encryption=aes,authentication=rsa] zynq_fsbl_0.elf
	[authentication=rsa]system.bit
}

ステージ 0: SPK のハッシュを生成

このステージは、SPK キーのハッシュを生成します。

stage0:
{
	[ppkfile] primary.pub
	[spkfile] secondary.pub
}

Bootgen コマンドは次のとおりです。

bootgen -image stage0.bif –w -generate_hashes

ステージ 1: SPK ハッシュに署名

このステージは SPK ハッシュにサインして署名を作成します。

xil_rsa_sign.exe -gensig -sk primary.pem -data secondary.pub.sha256 -out secondary.pub.sha256.sig
または、OpenSSL プログラムを使用して署名を作成します。
#Swap the bytes in SPK hash
objcopy -I binary -O binary --reverse-bytes=256 secondary.pub.sha256

#Generate SPK signature using OpenSSL
openssl rsautl -raw -sign -inkey primary.pem -in secondary.pub.sha256 > secondary.pub.sha256.sig

#Swap the bytes in SPK signature
objcopy -I binary -O binary --reverse-bytes=256 secondary.pub.sha256.sig

ステージ 2: AES を使用して暗号化

このステージはパーティションを暗号化します。stage2.bif は次のとおりです。

stage2:
{
	[aeskeyfile] my_efuse.nky
	[bootloader, encryption=aes] zynq_fsbl_0.elf
}
Bootgen コマンドは次のとおりです。
bootgen -image stage2.bif -w -o fsbl_e.bin -encrypt efuse
出力は、暗号化されたファイル (fsbl_e.bin) です。

ステージ 3: パーティションのハッシュを生成

このステージは、さまざまなパーティションのハッシュを生成します。

ステージ 3a: FSBL ハッシュを生成

BIF ファイルは次のとおりです。

stage3a:
{
	[ppkfile] primary.pub
	[spkfile] secondary.pub
	[spksignature] secondary.pub.sha256.sig
	[bootimage, authentication=rsa] fsbl_e.bin
}
Bootgen コマンドは次のとおりです。
bootgen -image stage3a.bif -w -generate_hashes

出力は、ハッシュ ファイル (zynq_fsbl_0.elf.0.sha256) です。

ステージ 3b: ビットストリーム ハッシュを生成

このステージの BIF ファイルは次のとおりです。

stage3b:
{
	[ppkfile] primary.pub
	[spkfile] secondary.pub
	[spksignature] secondary.pub.sha256.sig
	[authentication=rsa] system.bit
}
Bootgen コマンドは次のとおりです。
bootgen -image stage3b.bif -w -generate_hashes
出力は、ハッシュ ファイル (system.bit.0.sha256) です。

ステージ 4: ハッシュに署名

このステージは作成したパーティション ハッシュ ファイルから署名を作成します。

ステージ 4a: FSBL パーティション ハッシュに署名
xil_rsa_sign.exe -gensig -sk secondary.pem -data zynq_fsbl_0.elf.0.sha256 -out zynq_fsbl_0.elf.0.sha256.sig
または、OpenSSL プログラムを使用して署名を作成します。
#Swap the bytes in FSBL hash
objcopy -I binary -O binary --reverse-bytes=256 zynq_fsbl_0.elf.0.sha256

#Generate FSBL signature using OpenSSL
openssl rsautl -raw -sign -inkey secondary.pem -in zynq_fsbl_0.elf.0.sha256 > zynq_fsbl_0.elf.0.sha256.sig

#Swap the bytes in FSBL signature
objcopy -I binary -O binary --reverse-bytes=256 zynq_fsbl_0.elf.0.sha256.sig

出力は、署名ファイル (zynq_fsbl_0.elf.0.sha256.sig) です。

ステージ 4b: ビットストリーム ハッシュに署名
xil_rsa_sign.exe -gensig -sk secondary.pem -data system.bit.0.sha256 -out system.bit.0.sha256.sig
または、OpenSSL プログラムを使用して署名を作成します。
#Swap the bytes in bitstream hash
objcopy -I binary -O binary --reverse-bytes=256 system.bit.0.sha256

#Generate bitstream signature using OpenSSL
openssl rsautl -raw -sign -inkey secondary.pem -in system.bit.0.sha256 > system.bit.0.sha256.sig

#Swap the bytes in bitstream signature
objcopy -I binary -O binary --reverse-bytes=256 system.bit.0.sha256.sig
出力は、署名ファイル (system.bit.0.sha256.sig) です。

ステージ 5: パーティションの署名を挿入

上記のステージで作成したパーティションの署名を挿入し、認証証明に変更します。

ステージ 5a: FSBL 署名を挿入

stage5a.bif は次のとおりです。

stage5a:
{
	[ppkfile] primary.pub
	[spkfile] secondary.pub
	[spksignature] secondary.pub.sha256.sig
	[bootimage, authentication=rsa, presign=zynq_fsbl_0.elf.0.sha256.sig] fsbl_e.bin
}
Bootgen コマンドは次のとおりです。
bootgen -image stage5a.bif -w -o fsbl_e_ac.bin -efuseppkbits efuseppkbits.txt -nonbooting
認証された出力ファイルは、fsbl_e_ac.bin および efuseppkbits.txt です。
ステージ 5b: ビットストリーム署名を挿入
stage5b.bif は次のとおりです。
stage5b:
{
	[ppkfile] primary.pub
	[spkfile] secondary.pub
	[spksignature] secondary.pub.sha256.sig
	[authentication=rsa, presign=system.bit.0.sha256.sig] system.bit
}
Bootgen コマンドは次のとおりです。
bootgen -image stage5b.bif -o system_e_ac.bin –nonbooting
認証された出力ファイルは system_e_ac.bin です。

ステージ 6: ヘッダー テーブルのハッシュを生成

このステージは、ヘッダー テーブルのハッシュを生成します。

stage6.bif は次のとおりです。
stage6:
{
	[bootimage] fsbl_e_ac.bin
	[bootimage] system_e_ac.bin
}
Bootgen コマンドは次のとおりです。
bootgen -image stage6.bif -generate_hashes
出力ハッシュ ファイルは ImageHeaderTable.sha256 です。

ステージ 7: ヘッダー テーブル署名を生成

このステージは、ヘッダー テーブル署名を生成します。

xil_rsa_sign.exe -gensig -sk secondary.pem -data ImageHeaderTable.sha256 -out ImageHeaderTable.sha256.sig
または、OpenSSL プログラムを使用して署名を作成します。
#Swap the bytes in header table hash
objcopy -I binary -O binary --reverse-bytes=256 ImageHeaderTable.sha256

#Generate header table signature using OpenSSL
openssl rsautl -raw -sign -inkey secondary.pem -in ImageHeaderTable.sha256 > ImageHeaderTable.sha256.sig

#Swap the bytes in header table signature
objcopy -I binary -O binary --reverse-bytes=256 ImageHeaderTable.sha256.sig
出力は、署名ファイル (ImageHeaderTable.sha256.sig) です。

ステージ 8: パーティションを結合し、ヘッダー テーブル署名を挿入する

stage8.bif は次のとおりです。

stage8:
{
	[headersignature] ImageHeaderTable.sha256.sig
	[bootimage] fsbl_e_ac.bin
	[bootimage] system_e_ac.bin
}
Bootgen コマンドは次のとおりです。
bootgen -image stage8.bif -w -o final.bin
出力は、ブート イメージ ファイル (final.bin) です。

HSM モードを使用した Zynq UltraScale+ MPSoC デバイス ブート イメージの作成

次の図に、HSM モードのブート イメージの図を示します。

12: 0 〜 10 ステージのブート プロセス

HSM モードを使用した Zynq® UltraScale+™ MPSoC デバイスのブート イメージの作成は、次の BIF ファイルを使用して標準フローでブート イメージを作成するのと似ています。これらの例は、必要に応じてハッシュ ファイルを生成するために OpenSSL プログラムを使用します。

all:
{
	[fsbl_config] bh_auth_enable
	[keysrc_encryption] bbram_red_key
	[pskfile] primary0.pem
	[sskfile] secondary0.pem
	
	[
	  bootloader,
	  destination_cpu=a53-0,
	  encryption=aes,
	  aeskeyfile=aes0.nky,
	  authentication=rsa
	] fsbl.elf

	[
	  destination_device=pl,
	  encryption=aes,
	  aeskeyfile=aes1.nky,
 	 authentication=rsa
	] system.bit

	[
	  destination_cpu=a53-0,
	  authentication=rsa,
	  exception_level=el-3,
	  trustzone=secure
	] bl31.elf

	[
	  destination_cpu=a53-0,
	  authentication=rsa,
	  exception_level=el-2
	] u-boot.elf
}

ステージ 0: SPK のハッシュを生成

次に、BIF ファイルの抜粋を示します。

stage0:
{
	[ppkfile]primary.pub
	[spkfile]secondary.pub
}

Bootgen コマンドは次のとおりです。

bootgen -arch zynqmp -image stage0.bif -generate_hashes -w on -log error

ステージ 1: SPK ハッシュに署名 (パーティションを暗号化)

次に、OpenSSL を使用して SPK ハッシュを生成するコードの抜粋を示します。

openssl rsautl -raw -sign -inkey primary0.pem -in secondary.pub.sha384 > secondary.pub.sha384.sig

このコマンドの出力は secondary.pub.sha384.sig です。

ステージ 2a: FSBL を暗号化

次の BIF ファイルの抜粋部分を使用して FSBL を暗号化します。

Stage 2a:
{
	[keysrc_encryption] bbram_red_key

	[
	  bootloader,destination_cpu=a53-0,
	  encryption=aes,
	  aeskeyfile=aes0.nky
	] fsbl.elf
}

Bootgen コマンドは次のとおりです。

bootgen -arch zynqmp -image stage2a.bif -o fsbl_e.bin -w on -log error

ステージ 2b: ビットストリームを暗号化

次の BIF ファイル エントリを生成します。

stage2b:
{
	[
	  encryption=aes,
	  aeskeyfile=aes1.nky,
	  destination_device=pl,
	  pid=1
	] system.bit
}

Bootgen コマンドは次のとおりです。

bootgen -arch zynqmp -image stage2b.bif -o system_e.bin -w on -log error

ステージ 3: ブート ヘッダー ハッシュを生成

次の BIF ファイルを使用してブート ヘッダー ハッシュを生成します。

stage3:
{
 	[fsbl_config] bh_auth_enable
 	[ppkfile] primary.pub
 	[spkfile] secondary.pub
 	[spksignature]secondary.pub.sha384.sig
 	[bootimage,authentication=rsa]fsbl_e.bin
}

Bootgen コマンドは次のとおりです。

bootgen -arch zynqmp -image stage3.bif -generate_hashes -w on -log error

ステージ 4: ブート ヘッダー ハッシュに署名

次の OpenSSL コマンドを使用して、ブート ヘッダー ハッシュを生成します。

openssl rsautl -raw -sign -inkey secondary0.pem -in bootheader.sha384 > bootheader.sha384.sig

ステージ 5: パーティション ハッシュを取得

BIF ファイルの次のコマンドを使用して、パーティション ハッシュを取得します。

stage5:
{		
	[ppkfile]primary.pub
	[spkfile]secondary.pub
	[spksignature]secondary.pub.sha384.sig
	[bhsignature]bootheader.sha384.sig 
	[bootimage,authentication=rsa]fsbl_e.bin
	[bootimage,authentication=rsa]system_e.bin
	
	[
	  destination_cpu=a53-0,
	  authentication=rsa,
	  exception_level=el-3,
	  trustzone=secure
	] bl31.elf

	[
	  destination_cpu=a53-0,
	  authentication=rsa,
	  exception_level=el-2
	] u-boot.elf
}

Bootgen コマンドは次のとおりです。

bootgen -arch zynqmp -image stage5.bif -generate_hashes -w on -log error

ビットストリーム パーティション用に複数のハッシュが生成されます。詳細は、外部メモリを使用したビットストリーム認証 を参照してください。

ブート ヘッダー ハッシュもこのステージ 5 で生成されます。ステージ 5 では bh_auth_enable が使用されないので、このハッシュはステージ 3 で生成されたものとは異なります。これは必要に応じてステージ 5 に追加できますが、ステージ 3 で生成されたブート ヘッダー ハッシュはステージ 4 で署名され、この署名は HSM モード フローでしか使用されないので、大きな影響はありません。

ステージ 6: パーティション ハッシュに署名

OpenSSL を使用して次のファイルを作成します。

openssl rsautl -raw -sign -inkey secondary0.pem -in fsbl.elf.0.sha384 > fsbl.elf.0.sha384.sig
openssl rsautl -raw -sign -inkey secondary0.pem -in system.bit.0.sha384 > system.bit.0.sha384.sig
openssl rsautl -raw -sign -inkey secondary0.pem -in system.bit.1.sha384 > system.bit.1.sha384.sig
openssl rsautl -raw -sign -inkey secondary0.pem -in system.bit.2.sha384 > system.bit.2.sha384.sig
openssl rsautl -raw -sign -inkey secondary0.pem -in system.bit.3.sha384 > system.bit.3.sha384.sig
openssl rsautl -raw -sign -inkey secondary0.pem -in u-boot.elf.0.sha384 > u-boot.elf.0.sha384.sig
openssl rsautl -raw -sign -inkey secondary0.pem -in bl31.elf.0.sha384 > bl31.elf.0.sha384.sig
openssl rsautl -raw -sign -inkey secondary0.pem -in bl31.elf.1.sha384 > bl31.elf.1.sha384.sig

ステージ 7: パーティション署名を認証証明に挿入

ステージ 7a: 次のコードを BIF ファイルに追加して FSBL 署名を挿入します。

Stage7a:
{
	[fsbl_config] bh_auth_enable
	[ppkfile] primary.pub
	[spkfile] secondary.pub
	[spksignature]secondary.pub.sha384.sig
	[bhsignature]bootheader.sha384.sig
	[bootimage,authentication=rsa,presign=fsbl.elf.0.sha384.sig]fsbl_e.bin
}
Bootgen コマンドは次のとおりです。
bootgen -arch zynqmp -image stage7a.bif -o fsbl_e_ac.bin -efuseppkbits 
efuseppkbits.txt -nonbooting -w on -log error

ステージ 7b: BIF ファイルに次を追加してビットストリーム署名を挿入します。

stage7b:
{
	[ppkfile]primary.pub
	[spkfile]secondary.pub
	[spksignature]secondary.pub.sha384.sig
	[bhsignature]bootheader.sha384.sig
	[
	  bootimage,
	  authentication=rsa,
	  presign=system.bit.0.sha384.sig
	] system_e.bin
}

Bootgen コマンドは次のとおりです。

bootgen -arch zynqmp -image stage7b.bif -o system_e_ac.bin -nonbooting -w on -log error

ステージ 7c: BIF ファイルに次を追加して U-Boot 署名を挿入します。

stage7c:
{
	[ppkfile] primary.pub
	[spkfile] secondary.pub
	[spksignature]secondary.pub.sha384.sig
	[bhsignature]bootheader.sha384.sig
	[
	  destination_cpu=a53-0,
	  authentication=rsa,
	  exception_level=el-2,
	  presign=u-boot.elf.0.sha384.sig
	] u-boot.elf
}

Bootgen コマンドは次のとおりです。

bootgen -arch zynqmp -image stage7c.bif -o u-boot_ac.bin -nonbooting -w on -log error

ステージ 7d: BIF ファイルに次を追加して ATF 署名を挿入します。

stage7d:
{
	[ppkfile] primary.pub
	[spkfile] secondary.pub
	[spksignature]secondary.pub.sha384.sig
	[bhsignature]bootheader.sha384.sig
	[
	  destination_cpu=a53-0,
	  authentication=rsa,
	  exception_level=el-3,
	  trustzone=secure,
	  presign=bl31.elf.0.sha384.sig
	] bl31.elf
}

Bootgen コマンドは次のとおりです。

bootgen -arch zynqmp -image stage7d.bif -o bl31_ac.bin -nonbooting -w on -log error

ステージ 8: パーティションを結合し、ヘッダー テーブル ハッシュを取得

BIF ファイルに次を追加します。

stage8: 
{
	[bootimage]fsbl_e_ac.bin
	[bootimage]system_e_ac.bin
	[bootimage]bl31_ac.bin
	[bootimage]u-boot_ac.bin
}

Bootgen コマンドは次のとおりです。

bootgen -arch zynqmp -image stage8.bif -generate_hashes -o stage8.bin -w on -log error

ステージ 9: ヘッダー テーブル ハッシュに署名

OpenSSL を使用して次のファイルを生成します。

openssl rsautl -raw -sign -inkey secondary0.pem -in ImageHeaderTable.sha384 > ImageHeaderTable.sha384.sig

ステージ 10: パーティションを結合し、ヘッダー テーブル署名を挿入

BIF ファイルに次を追加します。

stage10: 
{
	[headersignature]ImageHeaderTable.sha384.sig
	[bootimage]fsbl_e_ac.bin
	[bootimage]system_e_ac.bin
	[bootimage]bl31_ac.bin
	[bootimage]u-boot_ac.bin
}

Bootgen コマンドは次のとおりです。

bootgen -arch zynqmp -image stage10.bif -o final.bin -w on -log error