JAJA733 January   2023 MSPM0G1105 , MSPM0G1106 , MSPM0G1107 , MSPM0G1505 , MSPM0G1506 , MSPM0G1507 , MSPM0G3105 , MSPM0G3106 , MSPM0G3107 , MSPM0G3505 , MSPM0G3506 , MSPM0G3507 , MSPM0L1105 , MSPM0L1106 , MSPM0L1227 , MSPM0L1227-Q1 , MSPM0L1228 , MSPM0L1228-Q1 , MSPM0L1303 , MSPM0L1304 , MSPM0L1305 , MSPM0L1306 , MSPM0L1343 , MSPM0L1344 , MSPM0L1345 , MSPM0L1346 , MSPM0L2227 , MSPM0L2227-Q1 , 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 サブファミリ別のセキュリティ・イネーブラ

3.2 非対称型と対称型のセキュア・ブート

MSPM0 SDK に搭載されているブート・イメージ・マネージャは、非対称型と対称型のセキュア・ブートをサポートしていますが、2 つの実装の間にはトレードオフが存在します。特定のアプリケーションに対して、これらのトレードオフを注意深く検討する必要があります。表 3-1 に、2 つの方式のトレードオフを示します。

表 3-1 セキュア・ブート・アルゴリズムの比較
パラメータ 非対称型 (SHA2 + ECDSA) 対称型 (CMAC)
認証時間 長い (ソフトウェア・ハッシュの計算と公開キーの演算のため) 短い (アルゴリズムが簡素で、ハードウェア AES アクセラレーションが利用可能な場合に活用できるため)
コードのサイズ 大きい (SHA および ECDSA アルゴリズムのため) 小さい (特にターゲット・デバイスで AES アクセラレーションを利用できる場合)
キーの整合性 公開キーがデバイスにプロビジョニングされ、変更不可能であることが必要 共有キーがデバイスにプロビジョニングされ、変更不可能であることが必要
キーの機密性 公開キーには機密性の要件はなく、公開キーをアプリケーション・コードの脆弱性から保護する必要なし 共有キーは機密情報として保護し、使用しないときには、アプリケーション・コードの脆弱性から保護するため、ラップして静的読み取りファイアウォール (ターゲット・デバイスでサポートされる場合) で保護する必要あり

ほとんどの状況では、非対称型の実装を推奨します。コード・サイズが限られている場合や、認証時間を最小限に抑える必要がある場合には、対称型の実装を使用できます。ただし、共有キーを注意深く管理する必要があります。すべてのデバイスに、ソフトウェアの脆弱性から共有対称キーを保護するためのセキュアなストレージが搭載されているわけではありません。