本記事は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 < 512 bytes + Tag)
Client ->> 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, 一般データ |
【セキュリティ考慮事項】
リプレイ攻撃への耐性: TFTPのBlock Numberに加え、AEAD Nonceをセッションごとに一意に生成することで、古いパケットの再注入を防止する。
ダウングレード攻撃: RRQオプションにセキュリティフラグを含め、サーバー側で非暗号化接続を拒否するポリシー設定が必須となる。
前方秘匿性 (PFS): 標準的なHKDF (HMAC-based Extract-and-Expand Key Derivation Function) を用いた一時鍵生成により、長期的なマスターキー漏洩時の被害を最小化する設計。
リソース枯渇攻撃: 認証タグの検証を復号前に行うことで、不正なパケットによる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スタックに統合することが推奨される。
