本記事はGeminiの出力をプロンプト工学で整理した業務ドラフト（未検証）です。
Authenticated Encryption for TFTP (HMTFTP) : draft-moriarty-tftp-aead
【背景と設計目標】
軽量なTFTPにAEAD（認証付き暗号）を導入し、DTLSの実装が困難な極小リソースのIoTデバイスへ、安全なファームウェア更新手段を提供する。
既存のRFC 1350（TFTP）との上位互換性を維持しつつ、RFC 2347（Option Extension）を利用して暗号化パラメーターをネゴシエーションする、既存プロトコルの段階的強化案です。
【通信シーケンスと動作】
HMTFTPは、通常のTFTPハンドシェイク時に特定のオプション（”aead”）を付与することで開始されます。
sequenceDiagram
participant "Client as HMTFTP Client"
participant "Server as HMTFTP Server"
Note over Client, Server: 事前共有鍵(PSK)または鍵交換完了済み
Client ->> Server: WRQ/RRQ [filename, mode, aead=aes-128-gcm]
Server -->> Client: OACK [aead=aes-128-gcm, nonce=random_val]
Client ->> Server: DATA (Block #1, Encrypted Payload, Tag)
Server -->> Client: ACK (Block #1, Tag)
Note over Client, Server: 以降、ブロックごとにAEADで保護された転送
Option Negotiation: クライアントがRRQ/WRQにて暗号アルゴリズムを提案。
Initial Nonce: サーバーがOACKで暗号化に使用する初期ナンス（Nonce）を提示。
Authenticated Transfer: 各データブロックに認証タグを付加し、改ざん検知と暗号化を同時に実現。
【データ構造 / パケットフォーマット】
HMTFTPのDATAパケット構造は、標準のTFTPヘッダーを拡張し、AEADタグをペイロードの末尾に配置します。
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] | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Encrypted Data Payload (Variable Length) | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Authentication Tag (e.g., 128 bits) | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Opcode: 標準TFTP（3=DATA, 4=ACK）を流用。
Encrypted Data: 選択されたAEADアルゴリズム（AES-GCM等）で暗号化。
Authentication Tag: MAC（メッセージ認証符号）。パケット全体の完全性を保証。
【技術的な特徴と比較】
HMTFTPは、フルスタックのセキュリティ（HTTPS/CoAP+DTLS）と、全くセキュリティのないTFTPの中間に位置します。
| 機能 / プロトコル | TFTP (RFC1350) | HMTFTP (Draft) | CoAP + DTLS |
|---|---|---|---|
| 暗号化方式 | なし | AEAD (AES-GCM等) | TLS 1.2/1.3準拠 |
| オーバーヘッド | 極小 | 低 (Tag分のみ) | 高 (Handshake/Record) |
| HOL Blocking | あり (Stop-and-Wait) | あり | 部分的に解消可 |
| 0-RTT | N/A | 実質可能 (PSK利用時) | 対応 (TLS 1.3) |
| 実装サイズ | 最小 (数KB) | 小 (AEADライブラリ依存) | 中〜大 |
【セキュリティ考慮事項】
リプレイ攻撃への耐性: TFTPのBlock NumberをAEADの追加認証データ（AAD）に含めることで、パケットの入れ替えや再送攻撃を検知します。
前方秘匿性（PFS）の欠如: 本ドラフトは主にPSK（事前共有鍵）を想定しており、PFSが必要な場合は上位層での鍵交換（Ephemeral Diffie-Hellman等）を別途組み合わせる必要があります。
初期ベクトルの再利用禁止: 同一の鍵でNonce（ナンス）が重複すると暗号強度が著しく低下するため、カウンタ管理の実装には厳格さが求められます。
【まとめと実装への影響】
ネットワークエンジニアおよび開発者が留意すべき点は以下の3点です。
省リソース環境の救世主: DTLSの複雑なステートマシンを実装できない8ビット/16ビットマイコンにおいて、実用的なセキュリティを最小限のコードサイズで提供できる。
既存ツールとの非互換性: 標準のTFTPサーバー/クライアントではオプションを無視してエラーになるか、暗号化パケットを平文として誤認するため、エンドツーエンドでのHMTFTP対応が必須。
鍵管理の外部依存: HMTFTP自体には鍵交換機能が含まれていない。製造時に鍵を埋め込むか、LwM2M等の別スキームで鍵を配布する運用設計が不可欠となる。
