JAJA733 January   2023 MSPM0G1105 , MSPM0G1106 , MSPM0G1107 , MSPM0G1505 , MSPM0G1506 , MSPM0G1507 , MSPM0G3105 , MSPM0G3106 , MSPM0G3107 , MSPM0G3505 , MSPM0G3506 , MSPM0G3507 , MSPM0L1105 , MSPM0L1106 , MSPM0L1227 , MSPM0L1228 , MSPM0L1228-Q1 , MSPM0L1303 , MSPM0L1304 , MSPM0L1305 , MSPM0L1306 , MSPM0L1343 , MSPM0L1344 , MSPM0L1345 , MSPM0L1346 , MSPM0L2227 , MSPM0L2228 , MSPM0L2228-Q1

 

  1.   概要
  2.   商標
  3. 1はじめに
    1. 1.1 サイバー・セキュリティの目標
    2. 1.2 プラットフォームのセキュリティ・イネーブラ
  4. 2デバイス・セキュリティ・モデル
    1. 2.1 ブート時の初期条件
    2. 2.2 ブート構成ルーチン (BCR)
    3. 2.3 ブートストラップ・ローダ (BSL)
    4. 2.4 ブート・フロー
    5. 2.5 ユーザー指定のセキュリティ・ポリシー
      1. 2.5.1 ブート構成ルーチン (BCR) のセキュリティ・ポリシー
        1. 2.5.1.1 シリアル・ワイヤ・デバッグ関連のポリシー
          1. 2.5.1.1.1 SWD セキュリティ・レベル 0
          2. 2.5.1.1.2 SWD セキュリティ・レベル 1
          3. 2.5.1.1.3 SWD セキュリティ・レベル 2
        2. 2.5.1.2 ブートストラップ・ローダ (BSL) のイネーブル / ディセーブル・ポリシー
        3. 2.5.1.3 フラッシュ・メモリの保護と整合性ポリシー
          1. 2.5.1.3.1 アプリケーション (MAIN) フラッシュ・メモリのロック
          2. 2.5.1.3.2 構成 (NONMAIN) フラッシュ・メモリのロック
          3. 2.5.1.3.3 アプリケーション (MAIN) フラッシュ・メモリの整合性の検証
      2. 2.5.2 ブートストラップ・ローダ (BSL) のセキュリティ・ポリシー
        1. 2.5.2.1 BSL アクセス・パスワード
        2. 2.5.2.2 BSL 読み出しポリシー
        3. 2.5.2.3 BSL セキュリティ・アラート・ポリシー
      3. 2.5.3 構成データのエラー耐性
        1. 2.5.3.1 CRC で保護された構成データ
        2. 2.5.3.2 クリティカル・フィールドの 16 ビット・パターン一致
  5. 3セキュア・ブート
    1. 3.1 セキュア・ブート認証フロー
    2. 3.2 非対称型と対称型のセキュア・ブート
  6. 4暗号化アクセラレーション機能
    1. 4.1 ハードウェア AES アクセラレーション
      1. 4.1.1 概要
      2. 4.1.2 AES の性能
    2. 4.2 ハードウェア真性乱数生成器 (TRNG)
  7. 5デバイス ID
  8. 6まとめ
  9. 7関連資料
  10. 8改訂履歴
  11.   A サブファミリ別のセキュリティ・イネーブラ

セキュア・ブート認証フロー

セキュア・ブートをサポートするデバイスを準備するには、以下のプロビジョニング手順が必要です。

  1. ブート・イメージ・マネージャ・ファームウェアは、MAIN フラッシュ・メモリに構成およびプログラムする必要があります。リセット・ベクトルは 0x0000.0004 で、ブート・イメージ・マネージャの開始を指しています。
  2. ブート・イメージ・マネージャが必要とするすべての認証キー・マテリアルは、ブート・イメージ・マネージャに隣接する MAIN フラッシュ・メモリにプログラムする必要があります。
  3. デバイスの NONMAIN 構成メモリは、次のようにプログラムする必要があります。
    1. ブート・イメージ・マネージャ・ファームウェアと認証キー・マテリアルを含む MAIN フラッシュ・セクタは、変更を防止するため静的書き込み保護として構成する必要があります。
    2. NONMAIN フラッシュ・セクタは、変更を防止するため静的書き込み保護として構成する必要があります。
    3. 一括消去および工場出荷時リセット・コマンドは、パスワード保護またはディセーブルすることを推奨します。上記の構成設定で工場出荷時リセットをディセーブルすると、NONMAIN 構成がブート・イメージ・マネージャおよび認証キーを含むセクタと共に永続的にロックされます。
    4. MAIN フラッシュ・メモリの整合性チェックはイネーブルにし、アドレス範囲をブート・イメージ・マネージャと認証キーを含めるように設定することを推奨します。

プロビジョニングが完了し、署名済みファームウェアがデバイスにプログラムされると、デバイスの電源投入からのセキュア・ブート・フローは次のようになります。

  1. 電源投入時、デバイスは最大のセキュア状態になります。BCR がデバイス構成メモリの整合性をチェックし、デバイス構成が有効な場合はそれに応じてユーザー指定のポリシーをロードします。
  2. BCR が BIM と認証キー・マテリアルを含む MAIN フラッシュ・メモリに対応する CRC 値を計算します。CRC チェックに成功すると、BCR は最初のユーザー・コード (ブート・イメージ・マネージャ) に実行を移行します。
  3. ブート・イメージ・マネージャが、残りのアプリケーション・コードのダイジェストを計算します。
    1. 非対称認証の場合、アプリケーション・コードのセキュア・ハッシュ (SHA2-256) ダイジェストはソフトウェアで計算されます。
    2. 対称型認証の場合、アプリケーション・コードに対応する CMAC メッセージ認証コードは、認証キーを使用して計算されます。
  4. ブート・イメージ・マネージャが、供給された署名に対してダイジェストを検証します。
    1. 非対称認証の場合、楕円曲線デジタル署名アルゴリズム (ECDSA) を使用してソフトウェアでデジタル署名が復号化され、その結果が計算されたハッシュと比較されます。
    2. 対称型認証の場合、計算された CMAC がデジタル署名の CMAC と比較されます。
  5. アプリケーション・コード・ダイジェストが署名と一致すると、アプリケーション・コードが開始します。一致しない場合は、ユーザー指定のエラー・ハンドラが呼び出されます。