OTAセキュリティ

概要

OTA セキュリティ（Over-the-Air Security）とは、デバイスに対する無線経由のファームウェア・ソフトウェアアップデートを安全に実施するための技術的対策の総称である。

OTA（Over-the-Air）更新はフィールドに展開済みの IoT デバイスに脆弱性修正や機能追加を届ける重要な手段であるが、同時に攻撃者にとっての格好の攻撃対象でもある。悪意ある偽ファームウェアのインストール、通信の盗聴・改ざん、リプレイ攻撃（古いバージョンへの意図的なダウングレード）などの脅威に対処しなければならない。

セキュアな OTA は「配布サーバーの認証」「配信経路の暗号化」「ファームウェアの署名検証」「ロールバック防止」「更新失敗からの復旧」という五つの要素が揃って初めて成立する。

歴史・背景

OTA の起源: 携帯電話の SIM カードへの遠隔設定変更（OTA SIM プロビジョニング）が先駆け。1990 年代後半から普及。
スマートフォン OTA: Android/iOS の App Store・Google Play によるアプリ更新、OS のシステムアップデートで OTA が一般化（2007 年〜）。
組み込み IoT への展開: 2015 年前後から AWS IoT OTA、Azure IoT Hub の Device Update などクラウドプラットフォームが IoT 向け OTA サービスを提供し始めた。
セキュリティ事故の教訓: 2016 年の Mirai ボットネット（脆弱な IoT デバイスへの大規模攻撃）を契機に、IoT セキュリティと OTA の重要性が再認識された。
IETF SUIT WG: Software Updates for Internet of Things（SUIT）ワーキンググループが設立（2017年）。RFC 9019、RFC 9124 などで IoT OTA の標準的な枠組みが整備された。
EU Cyber Resilience Act（2024年）: EU でサイバーレジリエンス法が制定され、IoT デバイスへのセキュリティアップデート提供が法的義務となった。

技術仕様

OTA セキュリティの要素

┌──────────────────────────────────────────────────────────┐
│ OTA セキュリティの5要素                                    │
├────────────────────┬─────────────────────────────────────┤
│ 1. サーバー認証    │ TLS でサーバー証明書を検証          │
├────────────────────┼─────────────────────────────────────┤
│ 2. 通信暗号化      │ TLS/DTLS で転送中データを保護       │
├────────────────────┼─────────────────────────────────────┤
│ 3. ファームウェア  │ ECDSA/RSA 署名でイメージを検証      │
│    署名検証        │                                     │
├────────────────────┼─────────────────────────────────────┤
│ 4. ロールバック防止│ バージョン番号 OTP でダウングレード  │
│                    │ を禁止                              │
├────────────────────┼─────────────────────────────────────┤
│ 5. 失敗からの復旧  │ デュアルバンク、フォールバック      │
│                    │ パーティション                      │
└────────────────────┴─────────────────────────────────────┘

MCUboot を使った OTA 対応フラッシュレイアウト

フラッシュメモリレイアウト（デュアルバンク構成）:

┌─────────────────────────────┐ 0x00000000
│ MCUboot (セキュアブートローダー│
│ 〜40 KB)                    │
├─────────────────────────────┤ 0x0000A000
│ Primary Slot               │
│ （現在動作中のファームウェア）│
│ 〜256 KB                   │
├─────────────────────────────┤ 0x0004A000
│ Secondary Slot             │
│ （OTA で受信した新ファームウェア）│
│ 〜256 KB                   │
├─────────────────────────────┤ 0x0008A000
│ Scratch Area               │
│ （スワップ用バッファ）        │
│ 〜40 KB                    │
└─────────────────────────────┘ 0x00100000

SUIT マニフェストの構造

IETF SUIT では、ファームウェアイメージに「マニフェスト」と呼ばれる更新メタデータを付与する。

SUIT マニフェスト（CBOR 形式）
├── authentication-wrapper: マニフェスト自体への署名
├── manifest:
│   ├── sequence-number: 3  （単調増加でロールバック防止）
│   ├── common:
│   │   ├── dependencies: 依存するコンポーネント
│   │   └── components: 更新対象コンポーネント情報
│   ├── install: インストール手順
│   ├── validate: 検証手順（ハッシュ確認）
│   └── invoke: 起動手順
└── integrated-payload: ファームウェアバイナリ（オプション）

動作原理

OTA 更新の全体フロー

[クラウドサーバー]                    [デバイス]
      │                                   │
      │  1. 新ファームウェアを署名付きで準備│
      │     開発者秘密鍵で ECDSA 署名      │
      │                                   │
      │  2. OTA Job 作成（AWS IoT 等）    │
      │                                   │
      │ ─── TLS 接続通知（MQTT）──────→  │  TLS でサーバー認証
      │                                   │
      │  3. デバイスが接続を確立          │
      │     （mTLS でデバイス認証）       │
      │                                   │
      │ ←── 署名済みファームウェアを要求  │
      │ ─── HTTPS でイメージ配信 ──────→ │  TLS で通信暗号化
      │                                   │
      │                          4. Secondary Slot に書き込み
      │                          5. 署名検証（デバイス内の公開鍵）
      │                          6. バージョン確認（ロールバック防止）
      │                          7. 再起動 → MCUboot がスワップ
      │                          8. 新ファームウェアで起動
      │                          9. 動作確認 → コミット
      │                             （失敗時は旧バージョンに戻る）
      │                                   │
      │ ←── 更新成功レポート ──────────── │

MCUboot での実装例（zephyr/nRF Connect SDK）

/* OTA 受信後、Secondary Slot に書き込む例 */
#include <zephyr/dfu/flash_img.h>
#include <zephyr/dfu/mcuboot.h>

struct flash_img_context flash_ctx;

void ota_write_chunk(const uint8_t *data, size_t len, bool is_last) {
    /* Secondary Slot へのフラッシュ書き込み */
    flash_img_buffered_write(&flash_ctx, data, len, is_last);

    if (is_last) {
        /* MCUboot に次回起動時の更新を指示 */
        boot_request_upgrade(BOOT_UPGRADE_TEST);
        /* または自動コミット: boot_request_upgrade(BOOT_UPGRADE_PERMANENT) */

        /* 再起動 */
        sys_reboot(SYS_REBOOT_COLD);
    }
}

/* MCUboot の起動後: 動作確認が成功したら確定させる */
void confirm_new_firmware(void) {
    if (!boot_is_img_confirmed()) {
        /* テストモードで動作中：動作確認 OK なら確定 */
        boot_write_img_confirmed();
        printk("OTA: 新ファームウェアを確定しました\n");
    }
}

AWS IoT OTA の実装例（ESP-IDF + AWS IoT SDK）

#include "aws_iot_ota_api.h"

/* OTA エージェントコールバック */
static void ota_app_callback(OtaJobEvent_t event) {
    switch (event) {
    case OtaJobEventActivate:
        /* 新ファームウェアが検証済み → 起動要求 */
        OTA_ActivateNewImage();
        break;

    case OtaJobEventFail:
        /* OTA 失敗 → エラーログ + リカバリ */
        ESP_LOGE(TAG, "OTA 失敗。旧ファームウェアのまま継続");
        OTA_SetImageState(OtaImageStateRejected);
        break;

    case OtaJobEventSelfTestFailed:
        /* セルフテスト失敗 → ロールバック */
        ESP_LOGE(TAG, "セルフテスト失敗。ロールバックします");
        esp_ota_mark_app_invalid_rollback_and_reboot();
        break;

    default:
        break;
    }
}

void start_ota_agent(void) {
    OtaAgentInit(&otaInterface, CLIENT_ID, ota_app_callback, NULL);
    OtaAgentStart(OTA_TASK_PRIORITY, OTA_TASK_STACK_SIZE);
}

ロールバック防止の実装

/* バージョン番号を OTP に書き込み、古いバージョンの実行を禁止 */
#define VERSION_MAJOR 2
#define VERSION_MINOR 1

bool is_rollback_allowed(uint16_t new_version) {
    /* OTP から現在の最小許可バージョンを読み取り */
    uint16_t min_allowed_version = read_otp_min_version();

    if (new_version < min_allowed_version) {
        ESP_LOGE(TAG, "ロールバック拒否: new=%d, min=%d",
                 new_version, min_allowed_version);
        return false;
    }
    return true;
}

/* 新バージョンが安定動作を確認後、OTP の最小バージョンを更新 */
void update_min_version(uint16_t version) {
    write_otp_min_version(version); /* 一度書いたら下げられない */
}

用途・ユースケース

セキュリティ脆弱性の修正

フィールドに展開済みのデバイスで発見された脆弱性に対し、物理回収なしに修正パッチを適用する。セキュリティアップデートはデバイスのライフサイクル全体を通じて提供することが求められる。

機能追加・改善

セキュリティ修正だけでなく、機能拡張や性能改善も OTA で行える。スマートホーム機器、車載システム、産業機器でのフィールドアップグレードが普及している。

認証情報の更新

期限切れのデバイス証明書や暗号鍵の更新も OTA で行える。証明書を定期的に更新することでセキュリティを維持できる。

マルチコンポーネント更新

SUIT マニフェストを使えば、メインアプリ、ブートローダー、FPGA ビットストリームなど複数コンポーネントをまとめて更新できる。

実装・開発のポイント

A/B パーティション（デュアルバンク）の重要性

OTA 中に電源が切れた場合や新ファームウェアが正常に動作しなかった場合でも、旧バージョンに戻れる仕組みが必須である。

デュアルバンク（A/B）パーティション戦略:
  ・Slot A（現在動作中） → OTA 受信後も保持
  ・Slot B（新ファームウェア書き込み）→ 検証後にスワップ
  ・スワップが成功し動作確認できたら Slot A を上書き
  ・失敗なら Slot A のまま起動

OTA の段階的ロールアウト

一度に全デバイスを更新すると問題発生時の影響が甚大である。段階的ロールアウト（カナリアデプロイ）を採用し、少数のデバイスで先行確認後に全体展開する。

デルタ（差分）更新

フラッシュ容量や通信帯域が制限される環境では、完全なイメージではなく差分のみを送信するデルタアップデートが有効。bsdiff/bspatch、Janpatch などのライブラリが使われる。

他技術との比較

技術	OTA セキュリティとの関係
ファームウェア署名	OTA で配布するイメージへの署名
セキュアブート	OTA 後の起動時に新ファームを検証
TLS/DTLS	配信経路の暗号化と認証
デバイス認証	更新対象デバイスが正規であることの確認
セキュリティアップデート	OTA で届ける主要なコンテンツ

OTA セキュリティは単独で完結する技術ではなく、署名・暗号化・認証・ブートローダー・クラウド基盤が統合されたシステムとして設計される。「OTA できる」ことと「安全に OTA できる」ことの差が、デプロイ後のデバイスの長期的なセキュリティを左右する。

概要