ザイリンクス®デバイスの普及により、デバイス内の知的財産（IP）を保護することは、デバイスによって処理されるデータを保護することと同じくらい重要になっています。 最新の認証方法によるセキュアブートがサポートされており、許可されていないコードや変更されたコードがザイリンクスデバイスで実行されるのを防ぎ、許可されたプログラムのみがさまざまな暗号化技術をロードするためにイメージにアクセスするようにします。
で Zynq®UltraScale+™MPSoC デバイスの場合、セキュアブートは、ハードウェアルートオブトラストブートメカニズムを使用して実行されます。これにより、すべてのブートファイルまたは構成ファイルを暗号化する方法も提供されます。 このアーキテクチャは、最も安全なアプリケーションをホストするために必要な機密性、整合性、および認証を提供します。
Zynq UltraScale + MPSoCには、ブートイメージの機密性をサポートするAES-GCMハードウェアエンジンがあり、ブート後にユーザーデータを暗号化および復号化するために使用することもできます。
Zynq UltraScale + MPSoCハードウェアの信頼ルートは、SHA-4096 / 3と組み合わせたRSA-384非対称認証アルゴリズムに基づいています。 Zynq UltraScale + MPSoCで使用されるXNUMXつのキーペアがあり、その結果、プライマリ公開キー（PPK）とセカンダリ公開キー（SPK）のXNUMXつの公開キータイプがあります。
AES暗号化：
AESは、対称鍵暗号化技術です。 暗号化と復号化に同じキーを使用します。 ブートイメージの暗号化に使用されるキーは、デバイスがそのブートイメージでブートしている間、復号化プロセスのためにデバイスで使用可能である必要があります。 通常、キーはeFUSEまたはBBRAMのいずれかに保存され、キーのソースは、BIF属性を介してブートイメージの作成中に選択できます。 ZynqMPでは、プレーンテキストキー（赤のキー）、難読化されたキー（灰色のキー）、暗号化されたキー（黒のキー）のXNUMXつの形式でキーを保存できます。
暗号化プロセス：
ブートイメージパーティションは、BIFファイル内のユーザー提供の暗号化コマンドと属性に基づいて暗号化されます。 Bootgenツールはパーティションを暗号化するために使用され、.bifファイルがそれに入力されます。
図：暗号化プロセス
復号化プロセス：
ザイリンクスSoCデバイスの場合、BootROMおよびFSBLは、ブートサイクル中にパーティションを復号化します。 BootROMは、フラッシュからFSBLを読み取り、復号化し、ロードして、コントロールを渡します。 FSBLは実行を開始すると、残りのパーティションを読み取り、復号化してロードします。 パーティションの復号化に必要なAESキーは、eFUSEまたはBBRAMから取得できます。
図：復号化プロセス
キー管理：
AES暗号化エンジンは、さまざまなキーソースのセットにアクセスできます。 不揮発性キーソースには、eFUSE、BBRAM、PUFキー暗号化キー（KEK）、およびファミリキーが含まれます。 これらのキーは、デバイスの電源がオフの場合でも値を維持します。 揮発性キーソースには、操作キーとキー更新レジスタキーが含まれます。
赤い鍵：
赤いキーは暗号化されていないキー（プレーンテキストキー）であり、eFUSE / BBRAMに保存できます。 赤いキーはbootgenがイメージを暗号化するために使用し、ZynqMPは赤いキーを使用してブートプロセス中にイメージを復号化します。
ブラックキー：
黒のキーは、ZynqMPSoCのPhysicalUnclonable Function（PUF）モジュールによって生成されたキー暗号化キー（KEK）で暗号化されたAESキーです。 作成したイメージのeFUSE / bootヘッダーに保存できます。
灰色/難読化されたキー：
難読化されたキーは、ZynqMP SoCのファミリキーで暗号化（難読化）されたAESキーです。 ファミリキーはデバイスの専用の埋め込みキーであり、デバイスファミリ内のすべてのデバイスで同じキーが使用されます。 難読化されたキーは、イメージのeFUSE / bootヘッダーに保存できます。
操作キー：
OPキーは、ブートイメージのセキュアヘッダーから復号化されたキーを保持するレジスタです。 優れた鍵管理手法には、秘密鍵または秘密鍵の使用を最小限に抑えることが含まれます。 これは、Bootgenで有効になっている操作キーオプションを使用して実行できます。
有効にすると、FSBLの暗号化されたセキュアヘッダーには、ユーザーが指定したOPキーと、構成ファイルの最初のブロックに必要な初期化ベクトル（IV）しか含まれません。 その結果、BBRAMまたはeFUSEのいずれかでデバイスに保存されているAESキーは、384ビットでのみ使用されるため、サイドチャネル攻撃への露出が大幅に制限されます。
図：操作キー
ローリングキー：
AES_GCMローリングキー機能は、暗号化されたイメージ全体を、より小さなAES暗号化ブロック/モジュールの観点から表します。 各モジュールは、独自の一意のキーを使用して暗号化されます。 初期キーはデバイスのキーソースに保存されますが、後続の各モジュールのキーは前のモジュールで暗号化（ラップ）されます。
RSA認証：
RSAは非対称アルゴリズムです。つまり、検証するキーは、署名に使用されるキーと同じではありません。 認証にはXNUMX組の鍵が必要です。 署名は秘密鍵/秘密鍵を使用して行われ、検証は公開鍵を使用して行われます。
ザイリンクスSoCでは、プライマリキーとセカンダリキーのXNUMX組の公開キーと秘密キーが使用されます。 プライマリ公開/秘密鍵ペアの機能は、セカンダリ公開/秘密鍵ペアを認証することです。 二次キーの機能は、パーティションに署名/検証することです。
歌う：
Bootgenは、秘密鍵を使用してパーティションに署名します。 署名プロセスは、次の手順で説明されています。
- PPKとSPKは、認証証明書（AC）に保存されます。
- SPKは、PSKを使用して署名され、ACの一部としても保存されるSPK署名を取得します。
- パーティションはSSKを使用して署名され、ACに入力されるパーティション署名を取得します。
- ACは、デバイスに応じて、認証用にオプトインされている各パーティションに追加または追加されます。
- PPKはハッシュ化され、eFUSEに保存されます。
検証：
デバイスでは、BootROMがFSBLを検証し、FSBLまたはU-Bootのいずれかが公開鍵を使用して後続のパーティションを検証します。
- PPKの検証：このステップでは、XNUMX次キーの認証に使用されるXNUMX次キーの信頼性を確立します
- PPKはブートイメージのACから読み取られます
- PPKハッシュを生成する
- ハッシュされたPPKは、eFUSEから取得されたPPKハッシュと比較されます。
- それらが同じである場合、主キーは信頼されます。 そうしないと、セキュアブートが失敗します
- 二次キーの検証：このステップでは、パーティションの認証に使用される二次キーの信頼性を確立します
- SPKはブートイメージのACから読み取られます
- ハッシュされたSPKを生成する
- PPKを使用してACに保存されているSPK署名を検証することにより、SPKハッシュを取得します
- ステップ（b）とステップ（c）のハッシュを比較します
- それらが同じである場合、XNUMX次キーは信頼されます。 そうしないと、セキュアブートが失敗します
- パーティションの検証：このステップでは、起動されるパーティションの信頼性を確立します
- パーティションはブートイメージから読み取られます
- パーティションのハッシュを生成します
- SPKを使用してACに保存されているパーティション署名を確認することにより、パーティションハッシュを取得します
- ステップ（b）とステップ（c）のハッシュを比較します
- それらが同じである場合、パーティションは信頼されています。 そうしないと、セキュアブートが失敗します
参照：
1. https://www.xilinx.com/support/documentation/user_guides/ug1085-zynq-ultrascale-trm.pdf
2. https://www.xilinx.com/support/documentation/user_guides/ug1137-zynq-ultrascale-mpsoc-swdev.pdf
3. https://www.xilinx.com/support/documentation/sw_manuals/xilinx2021_1/ug1283-bootgen-user-guide.pdf
PlatoAi。 Web3の再考。 増幅されたデータインテリジェンス。
アクセスするには、ここをクリックしてください。
