[Draft] AEAD for Trivial File Transfer Protocol (HMTFTP)

Tech

本記事はGeminiの出力をプロンプト工学で整理した業務ドラフト（未検証）です。

[Draft] AEAD for Trivial File Transfer Protocol (HMTFTP)

【背景と設計目標】

リソース制約のあるIoT機器において、TFTPの低負荷性を維持しつつAEADによる認証・暗号化を実現し、セキュアなファームウェア更新を可能にする。

本プロトコルは、RFC 1350 (TFTP v2) をベースに、RFC 2347 (Option Extension) を利用してセキュリティパラメータをネゴシエーションする。TLS/DTLSのオーバーヘッドを許容できない超軽量デバイスにおける、既存の非暗号化TFTPの置き換えを主眼に置いている。

【通信シーケンスと動作】

HMTFTPは、初回のRead Request (RRQ) 時にセキュリティオプションを提示し、サーバーとの間で一時鍵の共有および暗号化アルゴリズム（AES-GCM等）の合意を行う。

sequenceDiagram
    participant "Client as IoT Device (Client)"
    participant "Server as Update Server"

    Note over Client, Server: Phase 1: Negotiation (RFC 2347 Based)
    Client ->> Server: RRQ (Filename, Mode, "aead-algo", "client-nonce")
    Server -->> Client: OACK ("aead-algo", "server-nonce", "tag-len")

    Note over Client, Server: Phase 2: Key Derivation (HKDF)
    Note right of Server: Generate Session Key from Nonces

    Note over Client, Server: Phase 3: Secure Data Transfer
    Server ->> Client: DATA (Block #, AEAD-Nonce, Ciphertext, Auth-Tag)
    Client ->> Server: ACK (Block #)

    Note over Client, Server: Phase 4: Termination
    Server ->> Client: DATA (Final Block > Server: ACK (Final Block #)

【データ構造 / パケットフォーマット】

HMTFTPのデータパケットは、従来のTFTPヘッダーの直後にAEADに必要なNonce領域と認証タグ領域を拡張して配置する。

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  Opcode (3: DATA) [16 bits]   |     Block # [16 bits]         |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
|             AEAD Explicit Nonce (e.g., 96 bits)               |
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
|                 Encrypted Payload (Variable)                  |
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
|              Authentication Tag (e.g., 128 bits)              |
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

【技術的な特徴と比較】

HMTFTPは、トランスポート層にDTLSを採用する場合と比較して、ステート管理の簡略化とコードサイズの削減を優先している。

特徴 TFTP (RFC 1350) HMTFTP (Draft) HTTP/3 (QUIC)
暗号化 なし AEAD (AES-GCM/ChaCha20-Poly1305) TLS 1.3
整合性検証 なし (UDP Checksumのみ) AEAD Auth Tag による検証 TLS MAC / QUIC Frame
0-RTT 対応 (ただし未暗号) 対応可能 (Session Resumption時) 対応
MTU考慮 512B固定が一般的 AEAD Tag分、有効Payloadが減少 パスMTU探索必須
多重化 不可 不可 可能 (Stream)
主要用途 NetBoot, 内部転送 IoTファームウェア更新 Web, 一般データ

【セキュリティ考慮事項】

  1. リプレイ攻撃への耐性: TFTPのBlock Numberに加え、AEAD Nonceをセッションごとに一意に生成することで、古いパケットの再注入を防止する。

  2. ダウングレード攻撃: RRQオプションにセキュリティフラグを含め、サーバー側で非暗号化接続を拒否するポリシー設定が必須となる。

  3. 前方秘匿性 (PFS): 標準的なHKDF (HMAC-based Extract-and-Expand Key Derivation Function) を用いた一時鍵生成により、長期的なマスターキー漏洩時の被害を最小化する設計。

  4. リソース枯渇攻撃: 認証タグの検証を復号前に行うことで、不正なパケットによるCPU負荷（DoS）を抑制する。

【まとめと実装への影響】

HMTFTPの実装にあたって、エンジニアは以下の3点に留意すべきである。

  • MTUとフラグメンテーションの管理: AEADのNonce（約12バイト）とTag（約16バイト）が追加されるため、従来の512バイトのデータ長を維持すると、UDPパケット全体がMTUを超過しフラグメンテーションが発生するリスクがある。実装上はblksizeオプションで調整が必要。

  • 乱数生成器 (TRNG) の確保: AEAD Nonceの重複は致命的な脆弱性（Nonce Reuse Attack）を招く。IoTデバイス側で質の高い乱数生成が可能か、あるいはカウンターベースのNonce管理を厳密に行う必要がある。

  • ライブラリのフットプリント: OpenSSLのような巨大なライブラリではなく、mbedTLSやWolfSSL等の軽量実装を選択し、AEADプリミティブのみを抽出してTFTPスタックに統合することが推奨される。

ライセンス：本記事のテキスト/コードは特記なき限り CC BY 4.0 です。引用の際は出典URL（本ページ）を明記してください。
利用ポリシー もご参照ください。

コメント

タイトルとURLをコピーしました