Wi-Fiの「見えない穴」を埋める：PMF（802.11w）が守る通信の矜持と実装の深淵
Wi-Fi 7の登場により、MLO（Multi-Link Operation）がもたらす極低遅延の世界に胸を躍らせている方も多いだろう。しかし、どんなに物理層の変調方式が進化しても、その足元が脆弱であれば、ネットワークは砂上の楼閣に過ぎない。
今日語りたいのは、Wi-Fiの歴史の中で最も「無視されがちだが、極めて重要」な技術、PMF (Protected Management Frames: IEEE 802.11w) についてだ。
なぜ、管理フレームは「無防備」だったのか
Wi-Fiの黎明期、管理フレーム（Deauthentication や Disassociation パケット）は暗号化されていなかった。これは設計上の悲劇だ。攻撃者がMACアドレスをスプーフィングし、ターゲットのクライアントに対して「接続解除」を命じる不正パケットを流し込むだけで、通信は容易に切断される。これが有名なデアソシエーション攻撃だ。
かつてのWi-Fi環境では、カフェで仕事をしているエンジニアが、突如として接続を断たれ、再接続を強要される――そんな悪意ある「追い出し」が横行していた。PMFは、この管理フレームにメッセージ整合性チェック（MIC）を施し、暗号化の傘下に置くことで、この脆弱性に終止符を打った。
PMFの内部挙動：防御の解剖学
PMFが有効化されると、管理アクションフレームは Robust Management Frames として扱われる。具体的には、IEEE 802.11wは以下の仕組みで保護を実現する。
1. SA Query (Security Association Query): 接続解除要求が届いた際、APは即座に切断せず、クライアントに対して「本当に切断するのか？」というクエリを送る。攻撃者はこの応答を返せないため、接続は維持される。
2. IGTK (Integrity Group Temporal Key): マルチキャスト/ブロードキャストの管理フレームを保護するための鍵。これを用いることで、管理フレームの改ざんを不可能にする。
パケットキャプチャで見る「保護」の証
Wiresharkでパケットを覗くと、PMF有効時には 802.11 ヘッダー内の Frame Control フィールドにある Protected ビットが 1 になっていることが確認できるはずだ。もしこのビットが 0 であれば、その管理フレームは平文であり、攻撃の標的になり得ることを意味する。
インフラ構築における最適化の極み
テックリードやインフラアーキテクトが気にするべきは、セキュリティだけではない。PMFの導入は、必然的に 4-way Handshake のオーバーヘッドや、再認証時の RTT に影響を与える。
特に、高密度なオフィス環境では、頻繁なローミングが発生する。ここで 802.11r（Fast BSS Transition）とPMFを適切に組み合わせることが肝要だ。
サーバー/AP設定の勘所（例: hostapd）
LinuxベースのAP環境でPMFを強制（Required）に設定する場合、以下のパラメータを適用する。レガシーデバイスとの互換性を捨ててでもセキュリティを担保する際の設定例だ。
# hostapd.conf の設定例
# PMFを必須化（1: optional, 2: required）
ieee80211w=2
# 認証の高速化（802.11r）とPMFの併用
ieee80211r=1
ft_over_ds=1
# TCPバッファチューニング（カーネルパラメータの最適化）
# 高速ローミング中のパケットロスを最小限にするためのTCPキュー設定
sysctl -w net.ipv4.tcp_rmem="4096 87380 16777216"
sysctl -w net.ipv4.tcp_wmem="4096 65536 16777216"パフォーマンスとセキュリティのトレードオフ
ここで一度立ち止まって考えてほしい。PMFを有効にすると、ハンドシェイクのステップ数が増え、わずかながらレイテンシが増大する。しかし、現代の高性能なチップセット（Wi-Fi 6/7対応のNIC）であれば、ハードウェアアクセラレーションによってこの遅延はナノ秒単位で吸収される。
むしろ注目すべきは、TLSハンドシェイクの最適化だ。Wi-Fi層でPMFにより接続の信頼性が担保されていれば、上位レイヤーの TLS 1.3 で行われる 0-RTT（Zero Round Trip Time）再開を安心して利用できる。接続が不正に切断されないという「前提」があるからこそ、0-RTT の脆弱性を最小限に抑えつつ、接続速度を最大化できるのだ。
結びに代えて：泥臭い現場の知見
私がこれまで見てきたネットワークトラブルの多くは、PMFの「中途半端な設定」に起因していた。一部の古いIoTデバイスがPMFに対応できず、AP側で Required にしていると接続がループする、あるいは接続自体が拒否されるケースだ。
- 検証の鉄則: 導入前には必ず、対象デバイスが
802.11wに準拠しているかを確認すること。 - 監視の徹底:
802.11レベルの再送率や、不自然なDeauthenticationパケットの発生頻度をPrometheus等で可視化しておくこと。
ネットワークは「魔術」ではない。物理層の電気信号から、暗号学的な鍵交換、そしてTCPのバッファ管理に至るまで、すべての挙動に理由がある。PMFという小さな技術の積み重ねが、堅牢で、かつ誰もが快適に使えるインフラを支えているのだ。
さあ、あなたのネットワークの管理フレームは、今日から「守られた」ものになっているだろうか？
コメント