Chapter 16

通信のセキュリティ

この章がなぜ必要なのか——「TLS を使っています」は、何も保証しないから.

組み込み機器の TLS 実装で、証明書検証が無効化されている事例は、 驚くほど多い。理由はいつも同じである。

「つながらなかったので、検証を切ったら動いた。」

これで、中間者攻撃に対する防御が完全に失われる。 TLS は「使えば安全」ではなく、「正しく使えば安全」である。

この章で使う既出の用語（定義は各リンク先）. リプレイ（06 章 6 節）、AES-CCM（08 章 6 節）、必要（09 章 6 節）、確実（14 章 6 節）、廃止（15 章 8 節）、強力（15 章 4 節）、運用（15 章 8 節）

1. 通信で守るもの

「前方秘匿性」が組み込みでは特に重要である.

機器は 10〜20 年動く。その間に鍵が漏れる可能性は無視できない。

PFS がないと、攻撃者は通信を記録しておいて、 後で鍵を入手したときに全部復号できる（Harvest now, decrypt later）。

ECDHE を使う（RSA 鍵交換を使わない）ことで防げる。 TLS 1.3 では静的な RSA 鍵交換が廃止され、常に PFS がある。

2. TLS の正しい使い方

最低限のチェックリスト

失敗 1: 証明書検証の無効化

/* ★ 絶対にやってはいけない */
mbedtls_ssl_conf_authmode(&conf, MBEDTLS_SSL_VERIFY_NONE);

これで TLS は「盗聴されない通信路」ですらなくなる。 中間者が自分の証明書を提示すれば、機器はそれを受け入れて接続する。 以後、すべての通信が中間者に読まれ、改ざんされる。

/* ★ 正しい */
mbedtls_ssl_conf_authmode(&conf, MBEDTLS_SSL_VERIFY_REQUIRED);
mbedtls_ssl_conf_ca_chain(&conf, &cacert, NULL);
mbedtls_ssl_set_hostname(&ssl, "api.example.com");   /* ← ホスト名検証に必須 */

mbedtls_ssl_set_hostname() を呼び忘れると、ホスト名検証が行われない.

証明書チェーンは検証されるが、「その証明書が接続先のものか」は確認されない。 攻撃者が正規の CA から取得した別のドメインの証明書を提示すれば通ってしまう。

これは非常に多い実装ミスである。

失敗 2: 時刻が合っていない

証明書の有効期限を検証するには、正しい時刻が必要である。

「ビルド時刻を下限にする」は実用的な妥協である.

/* 完全ではないが、何もないよりずっとよい */
if (current_time < BUILD_TIMESTAMP) {
    current_time = BUILD_TIMESTAMP;   /* 少なくとも過去の証明書は弾ける */
}

これで「有効期限の切れた古い証明書を使った中間者攻撃」は防げる。 完全な時刻検証の代わりにはならないが、検証を切るよりは遥かによい。

失敗 3: 信頼する CA が広すぎる

組み込み機器は、特定のサーバとしか通信しない。 なのにブラウザと同じ数百個のパブリック CA を信頼する必要はない。

/* 自社のサーバとしか通信しないなら、自社の CA だけを信頼する */
mbedtls_x509_crt_parse(&cacert, my_company_root_ca, sizeof(my_company_root_ca));

ピンニングは諸刃の剣である.

証明書を更新したら、全機器が接続できなくなる——という事故が実際に起きている。

安全な運用:

• 複数のピンを持つ（現行 + 次期の予備）
• バックアップ CA を用意する
• ピンの更新を OTA で配れるようにする
• 有効期限に余裕を持つ

ピンニングを入れるなら、更新のシナリオを必ず設計すること。

3. リソース制約への対応

TLS は組み込みには重い。現実的な削り方を知っておく。

TLS 1.3 の利点

0-RTT は便利だが、リプレイ攻撃を許す.

0-RTT で送ったデータは再送されうる（サーバ側で防ぐのが難しい）。 冪等な操作（GET など）にのみ使うこと。 「ドアを開ける」のような操作に使ってはいけない。

DTLS — UDP 上の TLS

DTLS 1.3（RFC 9147）では、コネクション ID により IP アドレスが変わってもセッションを維持できる。 NAT の背後にいる機器や、モバイル機器で有用である。

さらに軽量な選択肢

独自プロトコルは避けること.

「TLS が重いから独自に作る」は、ほぼ確実に失敗する。 リプレイ防止、鍵更新、ダウングレード防止、エラー処理—— TLS が長年かけて解決してきた問題を、全部作り直すことになる。

どうしても軽くしたいなら、OSCORE + EDHOC のような 標準化された軽量プロトコルを検討すること。

4. 無線プロトコルのセキュリティ

BLE

Just Works は「認証なし」である.

画面もボタンもない機器では Just Works になりがちだが、 ペアリング時に中間者がいたら防げない。

対策:

• OOB（Out Of Band）を使う。NFC や QR コードで鍵情報を渡す
• ペアリング可能な時間を極小にする（ボタンを押した 30 秒だけなど）
• アプリ層で追加の認証を行う（証明書ベース）

最後の手段が実務的には最も確実である。 BLE のリンク層セキュリティを信頼しきらず、アプリ層で認証する。

Wi-Fi

Wi-Fi のプロビジョニング経路が盲点である.

「機器を AP モードにして、スマホから SSID とパスワードを送る」—— この通信が平文なら、近くにいる誰でも Wi-Fi パスワードを盗める。

• SoftAP に WPA2/WPA3 をかける
• アプリ層で公開鍵暗号を使う（機器の公開鍵で暗号化して送る）
• QR コードで機器の公開鍵を渡す（DPP / Wi-Fi Easy Connect が標準化している）

その他

産業プロトコル（Modbus、CAN、BACnet）には、そもそもセキュリティがない.

これらは「閉じたネットワークで使う」前提で設計されている。

• ネットワーク分離（01 章の Jeep の事例）
• ゲートウェイでの認証・フィルタ
• CAN では侵入検知（異常なメッセージの検出）
• Modbus/TCP なら TLS でトンネルする（Modbus/TCP Security）

IEC 62443 のゾーンとコンジットの考え方が、まさにこれである。

5. アプリケーション層

TLS の上でも、設計は必要である。

「クラウドは信頼できる」という前提を置かないこと.

クラウド側が侵害されたとき、 全機器に「工場出荷リセット」や「悪意あるファームウェア」を送れるなら、 被害は壊滅的になる。

対策:

• ファームウェアの署名鍵は、クラウドサーバに置かない（13 章の TUF の原則）
• 破壊的な操作には、追加の署名検証を要求する
• 機器側でサニティチェックをする（「全機器同時にリセット」は異常）

6. MQTT の設定

MQTT は、ブローカ（中継サーバ）を介して「トピック」単位でメッセージを 出版／購読（Pub/Sub）する軽量プロトコルで、IoT で最も広く使われる。だから個別に触れる。

7. 通信設定の検証

TLS 設定をチェックする

設定項目を切り替えて、どの攻撃が成立するかを確かめられる。

実機に対して確認する方法:

# サーバ側の設定確認
$ openssl s_client -connect api.example.com:8883 -showcerts
$ testssl.sh api.example.com:8883        # 包括的な診断

# 機器側の挙動確認（中間者を立てて、検証しているか確かめる）
# → 自己署名証明書を提示して、機器が接続を拒否するか確認する

「機器が不正な証明書を拒否するか」を必ず実機で確認すること.

コードレビューだけでは不十分である。 意図的に不正な証明書を提示して、接続が失敗することを試験項目に入れる。

• 自己署名証明書 → 拒否されるか
• 有効期限切れの証明書 → 拒否されるか
• 別のホスト名の正規証明書 → 拒否されるか（ホスト名検証）
• 失効した証明書 → 拒否されるか

これは出荷前試験の必須項目である。

8. この章のまとめ

ここまでで一般論は終わりである。 次章から第 VI 部——各社の SoC が、これらをどう実装しているかを見る。