draft-he-tftp-hmtftp: HMTFTP（AEAD-Encrypted Trivial File Transfer Protocol）の仕様と構造

Tech

  • 専門的かつ論理的なトーンで記述すること。

  • 明確な構造化（指定された見出し、表、コードブロック、Mermaid図）を厳守すること。

  • 文字数制限（背景と設計目標：40-70文字）を守ること。 本記事はGeminiの出力をプロンプト工学で整理した業務ドラフト（未検証）です。

draft-he-tftp-hmtftp: HMTFTP（AEAD-Encrypted Trivial File Transfer Protocol）の仕様と構造

【背景と設計目標】

軽量なTFTPにAEAD暗号化を統合し、リソース制約のあるIoTデバイスにおける安全かつ低負荷なファームウェア更新を実現する。（61文字）

HMTFTPは、1992年に定義された伝統的なTFTP（RFC 1350）および拡張オプション（RFC 2347等）をベースとしつつ、暗号化と改ざん防止機能を組み込んだ独立した拡張プロトコルです。TLS/DTLSのフルスタック実装が困難な極小の組み込み機器において、過度なプロトコルオーバーヘッドを回避しながら、現代的な認証付き暗号（AEAD）による安全なデータ転送を可能にします。

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

HMTFTPでは、事前共有鍵（PSK）またはハンドシェイクによって生成されたセッション鍵を用いて、データパケット（DATA）および確認応答（ACK）の暗号化・認証を行います。

sequenceDiagram
    autonumber
    participant "Client as IoT Client"
    participant "Server as TFTP Server"
    Client ->> Server: RRQ / WRQ (Opcode=1/2, Key-Exchange / Nonce-Init Option)
    Server -->> Client: OACK (Opcode=6, Nonce-Ack, Cipher-Suite)
    Note over Client,Server: セッション鍵および初期ノンス(Nonce)の決定
    Client ->> Server: ACK (Block #0, Ciphertext/Tag Optional)
    Loop データ転送フェーズ
        Server ->> Client: DATA (Opcode=3, Block #1, AEAD-Encrypted Payload + Auth Tag)
        Client ->> Server: ACK (Opcode=4, Block #1, Auth Tag)
    End

通信はUDP上で行われ、最初のリード要求（RRQ）またはライト要求（WRQ）にて暗号スイートや初期ノンス（Nonce）のネゴシエーションを行います。後続のDATAおよびACKパケットにはAEADタグが付与され、通信途中の改ざんや盗聴を検知・防止します。

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

HMTFTPの暗号化DATAパケットフォーマットは以下の通りです。ヘッダ部（OpcodeおよびBlock Number）は関連データ（AAD: Additional Authenticated Data）として検証対象に含まれ、暗号化ペイロードと認証タグ（Auth Tag）が追加されます。

 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 (16:bits)     |        Block Number (16:bits) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
+                     AEAD Explicit Nonce (96:bits)             +
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
/                   Encrypted Payload (Variable)                /
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
+                       Authentication Tag (128:bits)           +
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

  • Opcode (0:16): パケット種別（3 = DATA）。

  • Block Number (16:16): ブロック番号（1〜65535）。

  • AEAD Explicit Nonce (32:96): 各パケットの暗号化に利用する96ビットの明示的ノンス。

  • Encrypted Payload (128:Variable): 暗号化されたファイルデータ。

  • Authentication Tag (Variable:128): データの完全性と送信元認証を保証する16バイトのAEAD認証タグ（AES-GCMやChaCha20-Poly1305等）。

【技術的な特徴と比較】

既存の転送プロトコルおよび保護プロトコルとの比較は以下の通りです。

項目 HTTP/3 (QUIC) CoAP over DTLS TFTP (RFC 1350) HMTFTP (Draft)
トランスポート UDP UDP UDP UDP
暗号化方式 TLS 1.3 内蔵 DTLS 1.2 / 1.3 なし（平文） AEAD (ChaCha20/AES-GCM)
0-RTT/低遅延 対応 条件付き対応 非対応（平文） 対応（PSK時0-RTT転送可）
フットプリント 非常に大きい 中程度 非常に極小 極小（数KBの追加実装）
HOL Blocking なし（ストリーム別） なし 単一ブロック応答待ち 単一ブロック応答待ち
主用途 Web / 大容量通信 IoTセンサ通信 ネットワークブート IoTファームウェア安全更新

技術キーワード解説

  • HOL Blocking (Head-of-Line Blocking): HMTFTPは標準TFTPと同様のStop-and-Wait方式を踏襲するため、1パケットごとのACK確認が必要です。パイプライン化されていないためHOL Blockingの影響を受けますが、極小フットプリントを優先した設計トレードオフです。

  • 0-RTTハンドシェイク: 事前共有鍵（PSK）と直前セッションパラメータを保持している場合、暗号ネゴシエーションのオーバーヘッドなしで最初のRRQ/WRQ要求からデータ転送を開始できます。

  • MTUとパケットサイズ: AEADノンス（12バイト）と認証タグ（16バイト）が追加されるため、IPフラグメンテーションを防ぐには、TFTPのブロックサイズ（通常512バイト）をパケット長制限（MTU 1500バイト以内）に合わせて適切にネゴシエーション（RFC 2348）する必要があります。

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

  1. リプレイ攻撃（Replay Attack）の防止 パケットごとのブロック番号（Block Number）およびシーケンシャルにインクリメントされるノンス（Nonce）をAEADのAAD（関連データ）として結合・検証します。攻撃者が過去の正常なDATAパケットを再送しても、ノンスの重複検知およびタグ検証失敗により排除されます。

  2. ダウングレード攻撃への耐性 RRQ/WRQにおけるネゴシエーション時、平文TFTPへのフォールバックを禁止するセキュリティポリシー（Strict HMTFTP Mode）を適用可能です。オプションネゴシエーション（OACK）自体も初期鍵パラメータで保護・認証されます。

  3. 前方秘匿性（Forward Secrecy: PFS） 固定PSKのみを使用する場合、将来的にPSKが漏洩した際に過去の暗号化トラフィックが解読されるリスクがあります。PFSを確保するためには、セッション開始時に軽量なDiffie-Hellman鍵交換（例: Curve25519）を併用する拡張プロファイルの利用が推奨されます。

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

ネットワークエンジニアおよび組み込み開発者がHMTFTPを導入・実装する際に考慮すべき3つのポイントは以下の通りです。

  1. コードサイズとメモリ消費の最小化 TLS/DTLSスタック全体を組み込むコスト（数万行のコード）に対し、HMTFTPはコアのTFTPロジックに軽量なAEADライブラリ（mbedTLSやlibsodiumのChaCha20-Poly1305単体など）を追加するだけで実装可能であり、ROM/RAM制限が厳しいMCUに適しています。

  2. Path MTU Discoveryとブロックサイズ最適化 AEADタグ（16バイト）とノンス（12バイト）のオーバーヘッドにより、伝統的な512バイト制限を超えてブロックサイズ（blksizeオプション）を拡張する場合、UDPフラグメンテーションの発生によるパケットドロップを防ぐ調整が不可欠です。

  3. ノンスの再利用防止（Nonce Reuse Prevention） 同一の鍵に対して同一のノンスを再使用することは、AEAD暗号の壊滅的な解読（平文の復元やタグ偽造）につながります。送信側実装では、カウンタベースのノンス管理を厳格に行う必要があります。

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

コメント

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