Chapter 17

Arm のセキュリティアーキテクチャ

この章がなぜ必要なのか——Arm が業界の共通語だから.

IoT 向け MCU の大多数が Arm コアを採用している。 そして各社の「独自機能」の多くは、Arm が定めた枠組みの上に載っている。

だから Arm の考え方（TrustZone-M、PSA、TF-M）を先に理解すると、 18 章〜21 章の各社の説明が「その会社流の実装」として整理できる。

注意: 以下は執筆時点の公開情報に基づく概観である。 具体的な対応状況は、必ず対象品種のデータシートと Arm の公式資料で確認すること。

この章で使う既出の用語（定義は各リンク先）. セキュアブート（02 章 3 節）、PSA-RoT（04 章 2 節）、物理攻撃（04 章 6 節）、不可（06 章 1 節）、GTZC（07 章 3 節）、NSPE（07 章 4 節）、Non-secure（07 章 3 節）、SPU（07 章 3 節）、Secure（07 章 3 節）、TrustZone（07 章 2 節）、ポインタ検証（07 章 8 節）、両方（07 章 3 節）、CryptoCell（08 章 5 節）、キャッシュ（09 章 1 節）、必要（09 章 6 節）、消費電力（09 章 1 節）、ECDSA（10 章 2 節）、Nordic（11 章 4 節）、NXP（12 章 3 節）、Renesas（12 章 3 節）、認証付きデバッグ（14 章 3 節）、開発（14 章 5 節）、Rust（15 章 3 節）、要件（15 章 8 節）、RAM（16 章 3 節）、フラッシュ（16 章 3 節）、ポート（16 章 6 節）

1. Arm のセキュリティ製品群の地図

Arm のセキュリティ機能マップ

コアや機能を選ぶと、それが何を提供し、どの章の概念に対応するかが表示される。

2. Cortex-M のセキュリティ機能の世代

新規設計で TrustZone が欲しいなら、Cortex-M33 が現実的な第一候補である.

ほぼすべての主要ベンダが M33 ベースの品種を持っている。

• ST: STM32L5 / U5 / H5 / WBA
• NXP: LPC55S6x、i.MX RT500/600
• Nordic: nRF5340、nRF9160、nRF54L
• Renesas: RA4M2/RA6M4 など
• Silicon Labs: EFR32 Series 2 の一部
• Microchip: SAM L11 は M23
• TI: CC13x4/CC26x4
• Infineon: PSoC 64 / PSoC Edge

Cortex-M35P の位置づけ

M33 に物理攻撃対策を加えたコアである。

ただし「M35P を選べば物理攻撃に強い」わけではない.

コアだけでなく、メモリ・暗号エンジン・電源系まで含めた SoC 全体の設計が要る。 実際の耐性は、PSA Certified Level 3 や CC の取得状況で判断すること（03 章）。

PACBTI（Armv8.1-M）

15 章で触れた制御フロー保護である。

ROP / JOP 攻撃への直接的な対策であり、 メモリ安全性のバグを実際の攻撃に変換することを困難にする。

コンパイラの -mbranch-protection=standard で有効化する。

3. TrustZone-M の実装詳細

07 章で概念を扱ったので、ここでは実装に関わる点を補う。

SAU と IDAU の関係

IDAU の設計はベンダごとに大きく違う.

よくあるのは、アドレスのビット 28（0x1000_0000）で Secure / Non-secure を分ける方式である。

つまり同じ物理メモリが 2 つのアドレスに見える。 この「エイリアス」の理解が、TrustZone-M 開発の最初の壁になる。

どのアドレスが何にマップされるかは、必ずベンダのリファレンスマニュアルで確認すること。

開発ツールの対応

/* Secure 側: Non-secure から呼べる関数 */
#include <arm_cmse.h>

int32_t __attribute__((cmse_nonsecure_entry))
secure_get_random(uint8_t *buf, size_t len)
{
    /* ★ ポインタ検証（[07 章](07_分離.md#越境時の注意点)） */
    if (cmse_check_address_range(buf, len,
            CMSE_NONSECURE | CMSE_MPU_READWRITE) == NULL) {
        return -1;
    }
    return trng_read(buf, len);
}

/* Non-secure 側: 生成されたヘッダをインクルードして普通に呼ぶ */
#include "secure_interface.h"

uint8_t buf[32];
if (secure_get_random(buf, sizeof(buf)) != 0) { /* エラー処理 */ }

4. PSA — Platform Security Architecture

Arm が定めた、IoT セキュリティの包括的な枠組みである。

4 つの段階

PSA の 10 のセキュリティ目標

PSA Certified Level 1 の質問票は、次の目標に沿っている。

この 10 項目が、本シリーズの第 II 部〜第 IV 部とほぼ一致する.

偶然ではない。PSA は、組み込みセキュリティの合意された要件集として 広く参照されており、業界の共通認識になっている。

自社の設計をレビューするとき、この 10 項目でチェックするのは有効である。

PSA-RoT と ARoT

PSA-RoT と ARoT を分けるのは、07 章の「Secure 側を小さく保つ」の実装である。

5. PSA Functional API

Arm が定めた、移植性のあるセキュリティ API 群である。

PSA Crypto API の設計

#include "psa/crypto.h"

psa_crypto_init();

/* 鍵の属性を設定 */
psa_key_attributes_t attr = PSA_KEY_ATTRIBUTES_INIT;
psa_set_key_usage_flags(&attr, PSA_KEY_USAGE_SIGN_HASH);
psa_set_key_algorithm(&attr, PSA_ALG_ECDSA(PSA_ALG_SHA_256));
psa_set_key_type(&attr, PSA_KEY_TYPE_ECC_KEY_PAIR(PSA_ECC_FAMILY_SECP_R1));
psa_set_key_bits(&attr, 256);
psa_set_key_lifetime(&attr, PSA_KEY_LIFETIME_PERSISTENT);   /* 不揮発に保存 */

/* ★ チップ内で鍵を生成する（[12 章](12_プロビジョニング.md#方式-b-機器の中で生成する-推奨)の方式 B） */
psa_key_id_t key_id;
psa_generate_key(&attr, &key_id);

/* 使う: 鍵の値は返ってこない */
uint8_t sig[64]; size_t sig_len;
psa_sign_hash(key_id, PSA_ALG_ECDSA(PSA_ALG_SHA_256),
              hash, 32, sig, sizeof(sig), &sig_len);

この API の優れた点を整理しておく.

点	内容
鍵をハンドルで扱う	平文の鍵がアプリケーションのメモリに現れない（06 章）
用途を宣言する	PSA_KEY_USAGE_SIGN_HASH だけなら、暗号化には使えない
アルゴリズムを固定する	鍵ごとに 1 つ。アルゴリズム混同攻撃を防ぐ
ハードウェアに透過的	実装がアクセラレータを使うかは API に現れない
セキュアエレメントも同じ API	ドライバを差し替えるだけ（22 章）

「危険な使い方ができない API」を設計することが、最良の防御である。

PSA Crypto API と移植性

PSA Crypto API は Mbed TLS の標準 API になった（Mbed TLS 3.x 以降）。 つまり TrustZone がないチップでも、同じ API で書ける。

これは実務上、非常に大きな利点である。

6. Trusted Firmware-M（TF-M）

PSA の参照実装であり、事実上の標準になりつつある。

分離レベル

PSA Certified Level 2 以上では、Isolation Level 2 以上が要求される.

Level 3 は、Secure 側のパーティション同士も MPU で隔離するので、 「あるセキュアサービスの脆弱性が、他に波及しない」。 その分、実装と設定が複雑になり、性能オーバーヘッドも増える。

TF-M を使うか、自作するか

TF-M のコストも認識しておくこと.

• フラッシュを数十〜百数十 KB 消費する（構成による）
• RAM も相応に使う
• ビルドと設定が複雑（CMake、Kconfig、プラットフォームポート）
• IPC のオーバーヘッドがある

小さなセンサノードには重すぎることがある。 その場合は「TrustZone は使うが TF-M は使わず、最小限の Secure 側を書く」 という選択もありうる。ただし認証取得は難しくなる。

7. Cortex-A のセキュリティ

IoT ゲートウェイやエッジ AI 機器では Cortex-A が使われる。

MTE — メモリ安全性への画期的なアプローチ

MTE は、C/C++ のメモリ安全性問題への現実的な緩和策である.

Rust への全面移行が難しい既存コードベースに対して、 再コンパイルだけで（ほぼ）メモリ安全性を得られる。

現時点では主に高性能な Cortex-A で利用可能だが、 将来的に組み込み向けに降りてくる可能性がある技術として、押さえておく価値がある。

Armv9-A CCA

クラウドやエッジで、「インフラ提供者からもデータを守る」ための機構である。 IoT ゲートウェイでも、マルチテナントのワークロード分離に使える可能性がある。

8. Arm 系を選ぶときの確認事項

PSA Certified の取得レベルは、必ず PSA Certified の Web サイトで確認すること.

ベンダの資料に「PSA Certified」とだけ書かれていても、 Level 1 なのか Level 3 なのかで意味がまったく違う。

また、「チップが認証されている」ことと「あなたの製品が認証される」ことは別である。 チップの認証は土台であって、その上のソフトウェアは別途評価される。

9. この章のまとめ

次章から、具体的なベンダの実装を見ていく。まず STMicroelectronics。