[STYLE: TECHNICAL_DEEP_DIVE] [TARGET: NETWORK_ENGINEER] [FORMAT: RFC_SUMMARY]
本記事はGeminiの出力をプロンプト工学で整理した業務ドラフト（未検証）です。
draft-hansen-hmtftp-00: Hardened Minimal Trivial File Transfer Protocol
【背景と設計目標】
IoTデバイスの省リソース性を維持しつつ、従来のTFTP（RFC 1350）が抱える「暗号化なし・改竄検知なし」という脆弱性をAEAD（認証付き暗号）の導入により解決する。
【通信シーケンスと動作】
HMTFTPは、初手でセキュリティオプション（Key IDやNonce）をネゴシエーションし、以降のDATAパケットをAEADで保護します。
sequenceDiagram
participant "Client as Client (IoT Device)"
participant "Server as Server (Update Server)"
Note over Client, Server: Phase 1: Security Negotiation (RRQ/WRQ)
Client ->> Server: RRQ "firmware.bin" (Option: AEAD=AES_GCM_128, KeyID=0x01)
Server -->> Client: OACK (AEAD=AES_GCM_128, ServerNonce=... )
Note over Client, Server: Phase 2: Encrypted Data Transfer
Server ->> Client: DATA (Block #1, IV, Ciphertext, Tag)
Client -->> Server: ACK (Block #1)
Note over Client, Server: Phase 3: Completion
Server ->> Client: DATA (Last Block, Tag)
Client -->> Server: ACK (Last Block)
【データ構造 / パケットフォーマット】
HMTFTPのDATAパケットは、RFC 1350を拡張し、暗号化メタデータとMAC（メッセージ認証コード）をペイロードに含みます。
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 (0x03: DATA) | Block # (16 bits) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Initialization Vector (IV) | | (96 bits) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Encrypted Data (Variable Length Payload) | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Authentication Tag (MAC) | | (128 bits) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
【技術的な特徴と比較】
HMTFTPは、DTLSを実装できない極低リソースのMCU（マイコン）環境をターゲットとしています。
| 機能 / 特徴 | TFTP (RFC 1350) | TFTP over DTLS (RFC 7839) | HMTFTP (Proposed) |
|---|---|---|---|
| 暗号化方式 | なし | TLS準拠 (AES/ChaCha) | AEAD (AES-GCM/ChaCha-Poly) |
| オーバーヘッド | 最小 (4 bytes) | 大 (Handshake + Record) | 中 (IV + Tag) |
| 0-RTT/接続性 | 対応 | 非対応 (Handshake必須) | 対応 (PSK利用時) |
| HOL Blocking | UDPのためなし | UDPのためなし | なし |
| 実装難易度 | 極めて低い | 高い (Stackが必要) | 低い (AEADライブラリのみ) |
【セキュリティ考慮事項】
リプレイ攻撃耐性: Block番号をAEADの追加認証データ（AAD）として含めることで、パケットの順序入れ替えや再送攻撃を検知する。
前方秘匿性 (PFS): 静的共有鍵（PSK）運用の場合、PFSは提供されない。PFSが必要な場合は、事前にEphemeral Diffie-Hellman等を用いた鍵交換が必要。
IVの再利用禁止: 同一鍵でIV（Nonce）を再利用すると、ストリーム暗号の特性上、平文が漏洩するリスクがあるため、カウンター管理が厳格に求められる。
【まとめと実装への影響】
実装に際してネットワークエンジニアが留意すべき点は以下の3点です。
MTUの計算: AEADのTag（16バイト程度）とIV（12バイト程度）が各パケットに付与されるため、イーサネットMTU（1500）を超えるフラグメンテーションが発生しないよう、ブロックサイズ（通常512）の調整が必要。
暗号化ライブラリの選定: デバイス側のハードウェアアクセラレーション（AES-NI等）が利用可能なアルゴリズムを選択することで、CPU負荷を最小限に抑えることが可能。
鍵管理の運用設計: HMTFTP単体では鍵配布機能を定義していないため、製造時に個体識別鍵を書き込むか、別のセキュアチャネルでの鍵配布が前提となる。
