【テクニカル・上級編】エンタープライズWi-Fi認証におけるEAP-TLS（Extensible Authentication Protocol-Transport Layer Security） – 家庭用ネットワーク・IoT・モバイル通信実践ガイド

Wi-Fi 7時代のセキュリティ最前線：EAP-TLSによる「ゼロトラスト無線」の解体新書

Wi-Fi 7（IEEE 802.11be）の登場により、マルチリンクオペレーション（MLO）や4K-QAMといった派手なワードが飛び交っていますが、ネットワークの屋台骨を支えるのは、依然として「堅牢な認証」です。WPA3-Enterpriseの標準である EAP-TLS。これは単なる証明書認証ではありません。クライアントとサーバが互いの正当性を証明し合う、無線LANにおける「究極の要塞」です。

本稿では、インフラアーキテクトの視点から、EAP-TLSのパケットレベルの挙動と、極限の環境で求められる最適化手法を深掘りします。

—

1. 相互認証の深淵：TLSハンドシェイクの再解釈

EAP-TLSがなぜ最強とされるのか。それは、パスワードという「人間が忘れる・漏洩する・使い回す」脆弱な要素を完全に排除し、暗号学的証明書による相互認証を行うからです。

無線LAN空間において、認証は4段階のフェーズで進行します。

1. EAP-Start: クライアントがアクセスポイント（AP）へ認証要求を投げる。
2. TLSハンドシェイクの開始: EAP-Request/Responseを通じて、TLSの ClientHello / ServerHello がカプセル化される。
3. 証明書交換: サーバ証明書だけでなく、クライアント証明書を要求する CertificateRequest が送信される。
4. セッションキーの生成: ChangeCipherSpec を経て、無線通信そのものを保護するPMK（Pairwise Master Key）が確定する。

ここで重要なのは、TLSのハンドシェイクが無線空間（L2）で行われるため、パケットロスが致命的になるという点です。無線環境下では、再送制御（Retransmission）が発生すると、ハンドシェイクのRTT（Round Trip Time）が急激に跳ね上がります。

—

2. パフォーマンスチューニング：RTT削減とバッファの最適化

インフラエンジニアが直面する最も泥臭い課題は「認証の遅延」です。特に大量のクライアントが同時接続するオフィス環境では、RADIUSサーバの負荷分散と、クライアント側のTCP/TLSパラメータのチューニングが必須となります。

LinuxクライアントにおけるTCP/TLSのチューニング

LinuxベースのIoTデバイスを配備する場合、カーネルパラメータを最適化して、認証パケットのキューイング遅延を抑えることが肝要です。

# /etc/sysctl.conf に記述すべき最適化設定
# TCPバッファサイズを拡大し、高遅延環境でのパケットロス耐性を強化
net.ipv4.tcp_rmem = 4096 87380 16777216
net.ipv4.tcp_wmem = 4096 65536 16777216

# 輻輳制御アルゴリズムをBBRに変更（パケットロス時のスループット低下を抑制）
net.core.default_qdisc = fq
net.ipv4.tcp_congestion_control = bbr

RADIUSサーバ（FreeRADIUS）の最適化

RADIUS側では、TLSセッションのキャッシュを有効にし、再認証時のハンドシェイクを省略（Session Resumption）させます。これにより、CPU負荷を劇的に軽減可能です。

# /etc/freeradius/3.0/mods-available/eap の設定例
eap {
    tls-config tls-common {
        # セッションキャッシュを有効化（認証高速化の要）
        cache {
            enable = yes
            lifetime = 24h
        }
        # 不要な古いTLSバージョンを排除し、攻撃対象を最小化
        cipher_list = "ECDHE-ECDSA-AES256-GCM-SHA384"
    }
}

—

3. セキュリティ設計の「落とし穴」と回避策

EAP-TLSを実装する際、多くのアーキテクトが陥るのが「証明書失効リスト（CRL）」の扱いです。

OCSP Staplingの検討: CRLをクライアントがダウンロードしようとすると、ネットワーク負荷と遅延が発生します。サーバ側でOCSPステープリングを行い、ハンドシェイク中に証明書の有効性を証明させることで、エンドポイントの負荷を減らすのが賢い設計です。
中間者攻撃（MitM）への備忘: クライアント側でRADIUSサーバのルートCAを正しく検証していないデバイスは、偽のAPに接続されるリスクがあります。wpa_supplicantの ca_cert パラメータは、たとえ面倒でも全てのデバイスで厳格に指定してください。

—

4. 総括：次世代無線認証を見据えて

Wi-Fi 7の時代においても、物理層の高速化だけでは不十分です。私たちは「いかにして認証を不可視化し、かつ暗号学的に担保するか」を追求し続けなければなりません。

EAP-TLSは、もはや「導入が難しい」技術ではありません。現代のインフラ構築において、これは「ゼロトラスト」というパズルの最も重要なピースです。パケットをキャプチャし、ハンドシェイクの揺らぎを観察し、カーネルの奥深くまでチューニングする。その泥臭い積み重ねこそが、最高品質のネットワーク体験を支える唯一の道なのです。

次回の記事では、このEAP-TLSとWi-Fi 7のマルチリンク認証における、より詳細な暗号スイートの選定基準について語りたいと思います。現場のエンジニア諸君、パケットの海でお会いしましょう。