注記: SHA-3 認証では、ブートヘッダー、PPK、およびブートイメージのハッシュ値の計算に Keccak SHA-3 が常に
使用されます。ROM によってロードされないその他すべてのパーティションには 、NIST-SHA3 が使用されます。
生成された署名は、次の表に基づいて Keccak-SHA3 または NIST-SHA3 を使用します。
認証証明 (AC) の種類 署名 eFUSE 署名の生成に使用される秘密キー パーティション ヘッダー AC
(FSBL/FW によってロードされ る)
SPK 署名 SPKID eFUSE の場合 Keccak、
ユーザー eFUSE の場合は NIST
PSK
BH 署名 常に Keccak SSKheader
ヘッダー署名 常に NIST SSKheader
ブートローダー (FSBL) AC
(ROM によってロードされる) SPK 署名 常に Keccak、常に SPK 用の
SPKID eFUSE PSK
BH 署名 常に Keccak SSKBootloader
FSBL 署名 常に Keccak SSKBootloader
その他のパーティション AC (FSBL FW によってロードされ る)
SPK 署名 SPKID eFUSE の場合 Keccak、
ユーザー eFUSE の場合は NIST
PSK
BH 署名 常に Keccak パディング 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
}
{ [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 は暗号化されたデータをブロックに分割して、各ブロックに認証証明を提供します。
ユーザー eFUSE サポートおよび RSA キー取り消しの改善
RSA キー取り消しサポートの改善
RSA キーは、すべてのパーティションのセカンダリ キーを取り消すことなく、1 つのパーティションのセカンダリ キ
ーを取り消すことができます。
注記: プライマリ キーは、すべてのパーティションで 同じものである必要があります。
これには、USER_FUSE0 〜 USER_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 = 0x100,
sskfile = ssk3.pem ] application.elf [
destination_cpu = a53-0, authentication = rsa,
] 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 秘密キー ファイルの例です。
注記: 公開コンポーネントには、通常拡張子 .pub が使用されます。これは、公開コンポーネントおよび秘密コンポー ネント両方を含む秘密キーから抽出できます。秘密キーには、通常拡張子 .pem が使用されます。公開キー コンポー ネントを生成するには、上記の例の pskfile/sskfile の代わりに ppkfile/spkfile を使用します。
generate_pem:
{ [pskfile] psk0.pem [sskfile] ssk0.pem }
コマンド
キーを生成する構文は、次のとおりです。
bootgen -generate_keys pem -arch zynqmp -image generate_pem.bif