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 サブファミリ別のセキュリティ・イネーブラ
2.5.1.1.2 SWD セキュリティ・レベル 1

SWD セキュリティ・レベル 1 では、セキュリティ構成をカスタマイズできます。物理的デバッグ・ポート (SW-DP) はイネーブルのままにし、各機能 (アプリケーションのデバッグ、一括消去コマンド、工場出荷時リセット・コマンド、テキサス・インスツルメンツ故障分析) は個別にイネーブル、ディセーブル、または (場合によって) パスワード認証を使用してイネーブルにでき、特定の使用事例に合わせてデバイスの動作をカスタマイズすることが可能です。

この状態を使用する状況

レベル 1 は、制限されたプロトタイプ製作 / 開発シナリオや、特定の SWD 機能 (工場出荷時リセット、テキサス・インスツルメンツ故障解析など) を保持しながら、アプリケーションのデバッグなどの機能をディセーブルにする量産シナリオに最適です。表 2-2 に、レベル 1 のカスタマイズ構成の一般的な例を示します。

表 2-2 レベル 1 構成の例
レベル 1 シナリオ 構成
アプリケーションのデバッグ 一括消去 工場出荷時リセット テキサス・インスツルメンツ FA
このシナリオでは、ユーザー指定のパスワードを使用してデバッグ・アクセスを制限するが、工場出荷時リセットとテキサス・インスツルメンツ障害解析は使用可能。この構成ではフィールド・デバッグ (パスワードを使用) が可能で、工場出荷時リセットによりデバイスをデフォルトのレベル 0 状態に戻すことも可能。 パスワードでイネーブル ディセーブル イネーブル イネーブル
このシナリオではデバッグは不可。工場出荷時リセットは可能だが、ユーザー指定のパスワードが必要。これにより、MAIN メモリの内容をクリアし、パスワードがわかっている場合はデバイスをレベル 0 状態に戻すことにより、現場でデバイスを開けることが可能。工場出荷時リセット用のパスワードが漏洩した場合でも、攻撃者は MAIN フラッシュ・メモリ内の独自の情報を読み取ることは不可。 ディセーブル ディセーブル パスワードでイネーブル イネーブル
このシナリオでは、デバッグとテキサス・インスツルメンツ故障解析は不可。これにより、ユーザーが FA 用にデバイスをテキサス・インスツルメンツに返却する場合に、ユーザー指定のパスワードを使用して工場出荷時リセットを実行しない限り、テキサス・インスツルメンツがデバイスに対して工場出荷時リセットおよび FA 作業を実行することは不可。 ディセーブル ディセーブル パスワードでイネーブル ディセーブル
注: レベル 1 は、ほとんどの標準的な製造使用事例で推奨される構成です。セキュア・ブートを必要としないアプリケーションでは、製造にレベル 1 を使用し、工場出荷時リセットを (パスワードを指定して) イネーブルにして、テキサス・インスツルメンツ故障解析はイネーブルのままにすることをお勧めします。このような構成では、ユーザー (パスワードを使用) またはテキサス・インスツルメンツ (障害解析の返却フロー) のいずれかによるプロビジョニング後に、デバイスをより制限の少ない状態に回復できます。最大限のセキュア・ブート保護を必要とする使用事例では、製造用により制限の厳しいレベル 1 またはレベル 2 を使用できます。ただし、デバイスをプロビジョニングした後は、より制限の低い状態に回復できない可能性があるというトレードオフがあります。

この状態を使用するべきでない状況

プロトタイプ作成時にデバイスへの完全なアクセスが必要な場合は、レベル 1 を使用せず、レベル 0 を使用してください。

また、最大限の制限が必要で、SWD 機能をイネーブルにしない量産シナリオでも、レベル 1 を使用しないでください。 このような場合はレベル 2 を使用して、SWD 物理インターフェイス全体を直接ディセーブルし、誤設定の可能性を最小限に抑える必要があります。

注: アプリケーション・デバッグと工場出荷時リセットをでディセーブルしてデバイスを構成した場合、ユーザーがデバイスへのデバッグ・アクセスを回復する唯一の方法は、ユーザー・アプリケーション・コードで NONMAIN 構成をより制限の少ない状態に変更するメカニズムを提供することです。NONMAIN が静的な書き込み保護によってロックされている場合は、状態を変更できず、ユーザーがデバッグ・アクセスを回復することはできません。