Chapter 08

暗号アクセラレータと乱数生成器

この章がなぜ必要なのか——乱数の質が、全部の土台だから.

どんなに強い暗号を使っても、鍵が予測できるなら意味がない。 TLS のセッション鍵も、機器の秘密鍵も、ノンス（1 回きりで使い捨てる値）も、 IV（暗号化のたびに変える初期値）も、すべて乱数から作られる。

乱数生成器は、セキュリティにおける単一障害点である。 そして組み込みでは、ここが驚くほど頻繁に壊れている。

この章で使う既出の用語（定義は各リンク先）. 物理攻撃（04 章 6 節）、署名検証（04 章 4 節）、RSA-2048（05 章 3 節）、経年劣化（06 章 3 節）、起動時間（06 章 3 節）、Crypto（07 章 4 節）、Secure（07 章 3 節）、TrustZone（07 章 2 節）、サイドチャネル（07 章 8 節）

1. 乱数の質が壊れた実例

共通しているのは「エントロピー不足」である.

エントロピーとは、外から予測できない無秩序さの量のことで、乱数の「種」になる。 種が足りないまま乱数を作ると、出力が乱数らしく見えても、 実際には少数のパターンしか出ていない——上の事例はすべてこれである。

特に組み込みで危険なのが起動直後である。

• マウスもキーボードもない
• ディスク I/O のタイミングもない
• ネットワークもまだ繋がっていない
• 時計すら合っていない

PC やサーバでエントロピー源として使われるものが、何もない。 だからハードウェアの TRNG が必須になる。

2. TRNG と DRBG — 2 段構成

「DRBG があるから TRNG は要らない」は誤りである.

DRBG はシードを増幅するだけであり、エントロピーを作り出さない。 シードが 32 ビットの予測可能な値なら、出力も 32 ビットの探索で破られる。

TRNG が本物のエントロピーを供給しない限り、DRBG は無意味である。

3. 関連する標準

データシートで確認すべきこと.

• 「NIST SP 800-90B 準拠」または「AIS 31 PTG.2/PTG.3 準拠」と書かれているか
• エントロピーレート（1 ビットあたりの min-entropy）はいくつか
• オンライン健全性テストを持っているか
• 起動時のテスト（power-on self test）があるか

「TRNG 搭載」とだけ書かれていて、これらの記載がない場合は要注意である。 単なる LFSR や、ADC のノイズを読んだだけの実装も存在する。

乱数の品質を見る

エントロピー源の品質を変えて、生成される鍵空間がどう変わるかを確かめられる。

4. オンライン健全性テスト

TRNG は故障する。経年劣化、温度、電源ノイズ、そして意図的な攻撃によって。

だから常時テストが必要になる。

これらは NIST SP 800-90B で規定されている。 異常を検出したら、乱数の供給を止めるかアラートを上げる設計にする。

ソフトウェア側でも、最低限の防御をしておくこと.

/* 悪い例: エラーを無視している */
uint8_t key[32];
hal_rng_read(key, 32);            /* 戻り値を見ていない */

/* 良い例 */
uint8_t key[32];
if (hal_rng_read(key, 32) != HAL_OK) {
    /* ★ 乱数が取れなかった。鍵を作ってはいけない */
    enter_safe_state();
}
/* さらに、全部ゼロ・全部 FF などの明らかな異常値を弾く */
if (is_all_same(key, 32)) {
    enter_safe_state();
}

「乱数生成に失敗したら止まる」設計にすること。 エラーを無視して 0 で埋まった鍵を使う、という事故が実際に起きている。

5. 暗号アクセラレータ

何を持っているか

速度の目安

ハードウェアがあるかないかで、桁が違う。

公開鍵演算の差が決定的である.

ECDSA P-256 の署名検証がソフトウェアで 200 ms かかると——

• セキュアブートが 200 ms 遅くなる（多段なら数倍）
• TLS ハンドシェイクが数百 ms 遅くなる
• 電池駆動ならその分の電力を消費する

起動時間や電池寿命の要件が厳しい製品では、 公開鍵アクセラレータ（PKA）の有無が SoC 選定を決めることがある。

アクセラレータの効果を見る

処理内容とクロックを変えて、ソフトウェア／ハードウェアの差を確かめられる。

各社の名称

6. アクセラレータの落とし穴

落とし穴 1: サイドチャネル対策の有無

「AES ハードウェアがある」と「DPA に耐える AES ハードウェアがある」は別である。

DPA 対策の有無は、データシートに明記されているとは限らない.

セキュリティアプリケーションノートや、 PSA Certified Level 3 / SESIP 4 / CC AVA_VAN.4 以上の取得状況を見るのが確実である。 これらのレベルは物理攻撃への耐性を評価に含む（03 章）。

ST の SAES（Secure AES）のように、 「サイドチャネル対策を施した AES」を通常の AES と別に持つ SoC がある。 どちらを使うかはソフトウェアが選ぶので、 鍵を扱う処理では必ず対策版を使うこと。

落とし穴 2: DMA と共有バス

アクセラレータは DMA でデータを読むことが多い。

/* 使い終わったら必ず消す */
uint8_t plaintext[64];
...
aes_encrypt(plaintext, sizeof(plaintext), ciphertext);
/* ★ コンパイラに最適化で消されないよう、専用の関数を使う */
mbedtls_platform_zeroize(plaintext, sizeof(plaintext));
/* memset() は「その後読まれない」と判断されて削除されうる */

memset() で消したつもりが消えていない、は古典的なバグである.

コンパイラは「この後読まれないメモリへの書き込み」を デッドストア削除で除去してよい（規格上、正当な最適化である）。

• C11 の memset_s()
• mbedtls_platform_zeroize()
• explicit_bzero()（BSD / glibc）
• volatile ポインタ経由の書き込み

のいずれかを使うこと。

落とし穴 3: モードの誤用

ハードウェアがあっても、使い方を間違えれば安全にならない。

原則: AEAD（認証付き暗号）を使う.

• AES-GCM（アクセラレータ対応が多い）
• AES-CCM（BLE や Zigbee で標準）
• ChaCha20-Poly1305（ソフトウェア実装が速い）

これらは暗号化と完全性検証が一体になっているので、 「MAC を付け忘れる」「順序を間違える」という事故が起きない。

GCM の IV（ノンス）は絶対に再利用しないこと。 カウンタ方式にして、不揮発に保存するか、鍵を更新する設計にする。

7. ソフトウェア暗号ライブラリ

ハードウェアがない部分は、ソフトウェアで補う。

ベンダの HAL がハードウェアアクセラレータへのグルーを提供している.

Mbed TLS には ALT 実装（MBEDTLS_AES_ALT など）の仕組みがあり、 ベンダがハードウェアを叩く実装に差し替えられる。

• ST: STM32Cube の Mbed TLS ラッパー
• NXP: MCUXpresso SDK の els_pkc / mbedtls ポート
• Nordic: nrf_security（PSA Crypto ドライバ経由で CryptoCell / CRACEN）
• Silicon Labs: SE Manager 経由

PSA Crypto API を使っておくと、この差し替えが透過的になる。 移植性の観点でも、PSA Crypto API を第一選択にする価値がある。

8. 選定時のチェックポイント

9. この章のまとめ

ここまでで第 II 部は終わりである。 次章から第 III 部——実際の物理攻撃がどう行われるかを見る。