Last Update: 2026-10-08

Wi-Fi セキュリティ¶

WPA2¶

WPA2 は IEEE 802.11i-2004 で定義された Robust Security Network (RSN; cf. IEEE Std 802.11-2020 Clause 12) に基づいていて、2004 年から認定が始まっている Wi-Fi Alliance のセキュリティ規格。WPA の後継で、WPA からの主な変更点は、暗号化方式として CCMP/AES のサポートが必須になったこと（WPA ではほとんどが TKIP/ARC4 だった）。

WPA2 では、使える暗号化方式と認証方式を定めていて、認証方式によって 2 種類ある。

WPA2-Personal¶

WPA2-Personal の認証方式は PSK 認証。STA が WLAN に接続する際には、 AP で事前に設定したパスフレーズを用いて認証を行う（RADIUS サーバーが不要で設定が簡単）。

設定が簡単な分、ユーザーを認証する仕組みがないので、WLAN に接続しているユーザーを識別することはできない（接続してる機器の MAC アドレスはわかる）。
あと、全員が同じパスフレーズを毎回使うことによるリスクもあって、Wi-Fi 通信の暗号化に使う鍵（Temporal Key）を含む Pairwise Transient Key（PTK）の素材を使いまわしてるイメージで、 あと少しの材料が揃えば、もしかしたらパスフレーズが解析できてしまって、PTK も複製できてしまうかもしれない。

PTK の作成方法にその原因があって、STA と AP それぞれにおける PTK の作成方法は次の通り。

1. 事前に共有した下記の 2 つを使って、256 bit の PSK を作成する。

   • パスフレーズ
   • SSID
   パスフレーズと SSID から PSK を作る式（IEEE Std 802.11-2020, p.4243）

   The pass-phrase mapping defined in this subclause uses the PBKDF2 as defined in IETF RFC 2898 [B34] section 5.2.

   PSK = PBKDF2(passPhrase, ssid, 4096, 256/8)

   The following apply:

   • passPhrase is a sequence of between 8 and 63 ASCII-encoded characters. The limit of 63 comes from the need to distinguish between a pass-phrase and a PSK displayed as 64 hexadecimal characters.
   • Each character in the pass-phrase has an encoding in the range 32 to 126 (decimal).
   • ssid is the SSID of the ESS or IBSS where this pass-phrase is in use, encoded as an octet string used in the Beacon and Probe Response frames for the ESS or IBSS.
   • 4096 is the number of times the pass-phrase is hashed.
   • 256 is the number of bits output by the pass-phrase mapping.

2. PSK をそのまま PMK として使う。

   PSK と PMK の関係（IEEE Std 802.11-2020, p.2538）

   NOTE 3—If the AKMP is RSNA-PSK, then a 256-bit PSK might be configured into the STA and AP or a pass-phrase might be configured into the Supplicant or Authenticator. … If a pass-phrase is configured, then a 256-bit key is derived and used as the PSK. In any RSNA-PSK method, the PSK is used directly as the PMK. …

3. 4-Way Handshake で下記の 2 つの乱数を互いに受け渡しする。

   • ANonce（AP が生成）
   • SNonce（STA が生成）
   4-Way Handshake での ANonce・SNonce の受け渡し（IEEE Std 802.11-2020, p.2557）

   RSNA defines a protocol using EAPOL-Key frames called the 4-way handshake. … The information flow of the 4-way handshake is as follows:

   Message 1: Authenticator → Supplicant: EAPOL-Key(0,0,1,0,P,0,0,ANonce,0,{} or {PMKID})

   Message 2: Supplicant → Authenticator: EAPOL-Key(0,1,0,0,P,0,0,SNonce,MIC,{RSNE} or …)

   …

   • ANonce is a nonce that the Authenticator contributes for PTK generation. …
   • SNonce is a nonce from the Supplicant for PTK generation.

4. 下記の 5 つを使って計算し、384 bit の PTK を作成する。

   • PMK
   • ANonce
   • SNonce
   • STA の MAC アドレス
   • AP の MAC アドレス
   PMK から PTK を作る式（IEEE Std 802.11-2020, p.2538）

   The PTK shall be derived from the PMK by

   PTK = PRF-Length(PMK, “Pairwise key expansion”, Min(AA,SPA) || Max(AA,SPA) || Min(ANonce,SNonce) || Max(ANonce,SNonce))

   where Length = KCK_bits + KEK_bits + TK_bits. The values of KCK_bits and KEK_bits are AKM suite dependent and are listed in Table 12-10. The value of TK_bits is cipher-suite dependent and is defined in Table 12-7. …

   AKM ごとの KCK・KEK の長さ（IEEE Std 802.11-2020 Table 12-10, p.2555）

   AKM	Integrity algorithm	KCK_bits	Size of MIC	Key wrap algorithm	KEK_bits	KCK2_bits	KEK2_bits
   …	…	…	…	…	…	…	…
   00-0F-AC:2	HMAC-SHA-1-128	128	16	NIST AES Key Wrap	128	0	0
   …	…	…	…	…	…	…	…
   00-0F-AC:4	AES-128-CMAC	128	16	NIST AES Key Wrap	128	0	0
   …	…	…	…	…	…	…	…
   00-0F-AC:6	AES-128-CMAC	128	16	NIST AES Key Wrap	128	0	0
   …	…	…	…	…	…	…	…

   暗号スイートごとの TK の長さ（IEEE Std 802.11-2020 Table 12-7, p.2549）

   Cipher suite	Key length (octets)	TK_bits (bits)
   …	…	…
   CCMP-128	16	128
   …	…	…

PSK をそのまま PMK として使用しているのが良くない点。 PSK はパスフレーズと SSID により一意に定まるので、パスフレーズか SSID のどちらかを変更しない限り、 常に同じ PMK を使うことになってしまう。 もし、攻撃者が 4-Way Handshake のフレームを盗聴できたら、PTK の複製に必要な残りの材料は PMK だけ。 なので、WLAN においては PMK が暗号化のための最重要な要素って言ってもいいくらい重要なもの。 でも、WPA2-Personal では PMK=PSK なので、SSID は電波が飛んでるので既知であるとすると、 パスフレーズさえ分かれば PTK が複製できる状態になるってこと。 つまり、WLAN の電波が届く場所で 4-Way Handshake のフレームさえ盗聴できれば、 そのフレームに対してパスフレーズを変えながら解読を試行する攻撃が、場所に関係なく実行可能となってしまう（オフライン辞書攻撃・オフライン総当たり攻撃）。

このようなリスクがあるので、IEEE Std 802.11-2020 では、攻撃を抑止するために はパスフレーズは約 20 文字以上必要って書かれてる。

WPA2-Enterprise¶

WPA2-Enterprise の認証方式は IEEE 802.1X 認証（EAP 認証）。STA が WLAN に接続する際には、 ユーザー ID/パスワードとか、クライアント証明書を用いて認証を行う（RADIUS サーバーとかが必要）。

IEEE 802.1X 認証は、認証の成功によりネットワークへのアクセスを許可するフレームワーク。 下記 3 つの構成要素がある。

• Supplicant
• Authenticator
• Authentication Server（AS）

基本的には、

Supplicant が Authenticator を経由して AS に認証を求めて、AS が認めれば Authenticator が Supplicant のアクセスを許可する。

っていう感じ。

EAP ではいろいろな認証方式（EAP メソッド）が使えて、WLAN で多く採用 されるのが EAP-PEAP（PEAP: Protected Extensible Authentication Protocol）方式（下図）。 PEAP では、Supplicant が Authenticator に認証を要求し、Supplicant と AS 間で行われる ID やパスワード などを確認する通信を TLS トンネル（図中の緑色部分）で保護する。 TLS トンネルを構築するので、AS にはサーバー証明書のインストールが必須で、 Supplicant には CA 証明書のインストールが必要になる場合もある。

また、PEAP では TLS トンネルを構築する前に Supplicant が ID を送信する（図中の 9 のフレーム）。 このフレームで送信する ID は、認証を開始する目的のみに使用され、EAP の認証には使用されないので、 ダミーの ID を使用できる。

暗号化方式は、CCMP/AES が主に使われている。Supplicant と Authenticator 間の データフレーム暗号化には、Pairwise Transient Key（PTK）に含まれる 128 bit の Temporal Key （TK）が使われ、WPA2-Enterprise では PTK の安全性が高い。PTK の作成方法は次の通り。

1. Supplicant と AS の相互認証により、512 bit 以上の Master Session Key（MSK）を作成する。

   • Supplicant は AS を、AS のサーバー証明書で認証する（CA 証明書を使って検証）
   • AS は Supplicant を、ユーザー ID とパスワード（PEAP）やクライアント証明書（EAP-TLS）で認証する
   相互認証と MSK の長さ（IETF RFC 3748, p.51）

   It is possible for the peer and EAP server to mutually authenticate and derive keys. In order to provide keying material for use in a subsequently negotiated ciphersuite, an EAP method supporting key derivation MUST export a Master Session Key (MSK) of at least 64 octets, and an Extended Master Session Key (EMSK) of at least 64 octets. EAP Methods deriving keys MUST provide for mutual authentication between the EAP peer and the EAP Server.

2. MSK の先頭 256 bit を Pairwise Master Key（PMK）として、Supplicant と AS で共有し、AS は Authenticator に PMK を送信する。

   MSK の先頭を PMK にする（IEEE Std 802.11-2020, p.2537）

   … With all other AKM suite selectors, the length of the PMK, PMK_bits, shall be 256 bits. …

   When using IEEE 802.1X authentication, the PMK is derived from the MSK. The PMK shall be computed as the first PMK_bits bits (bits 0 to PMK_bits–1) of the MSK: PMK = L(MSK, 0, PMK_bits). …

   AS から Authenticator への PMK の送信（IEEE Std 802.11-2020, p.283）

   The Supplicant and AS authenticate each other and generate a PMK. The PMK is sent from the AS to the Authenticator over the secure channel. …

3. Supplicant と Authenticator が、4-Way Handshake で下記の 2 つの乱数を互いに受け渡しする。

   • ANonce（Authenticator が生成）
   • SNonce（Supplicant が生成）
   4-Way Handshake での ANonce・SNonce の受け渡し（IEEE Std 802.11-2020, p.2557）

   RSNA defines a protocol using EAPOL-Key frames called the 4-way handshake. … The information flow of the 4-way handshake is as follows:

   Message 1: Authenticator → Supplicant: EAPOL-Key(0,0,1,0,P,0,0,ANonce,0,{} or {PMKID})

   Message 2: Supplicant → Authenticator: EAPOL-Key(0,1,0,0,P,0,0,SNonce,MIC,{RSNE} or …)

   …

   • ANonce is a nonce that the Authenticator contributes for PTK generation. …
   • SNonce is a nonce from the Supplicant for PTK generation.

4. Supplicant と Authenticator それぞれが、下記の 5 つを使って計算し、384 bit の PTK を作成する。

   • PMK
   • ANonce
   • SNonce
   • Supplicant の MAC アドレス
   • Authenticator の MAC アドレス
   PMK から PTK を作る式（IEEE Std 802.11-2020, p.2538）

   The PTK shall be derived from the PMK by

   PTK = PRF-Length(PMK, “Pairwise key expansion”, Min(AA,SPA) || Max(AA,SPA) || Min(ANonce,SNonce) || Max(ANonce,SNonce))

   where Length = KCK_bits + KEK_bits + TK_bits. The values of KCK_bits and KEK_bits are AKM suite dependent and are listed in Table 12-10. The value of TK_bits is cipher-suite dependent and is defined in Table 12-7. …

   AKM ごとの KCK・KEK の長さ（IEEE Std 802.11-2020 Table 12-10, p.2555）

   AKM	Integrity algorithm	KCK_bits	Size of MIC	Key wrap algorithm	KEK_bits	KCK2_bits	KEK2_bits
   …	…	…	…	…	…	…	…
   00-0F-AC:1	HMAC-SHA-1-128	128	16	NIST AES Key Wrap	128	0	0
   …	…	…	…	…	…	…	…
   00-0F-AC:3	AES-128-CMAC	128	16	NIST AES Key Wrap	128	0	0
   …	…	…	…	…	…	…	…
   00-0F-AC:5	AES-128-CMAC	128	16	NIST AES Key Wrap	128	0	0
   …	…	…	…	…	…	…	…

   暗号スイートごとの TK の長さ（IEEE Std 802.11-2020 Table 12-7, p.2549）

   Cipher suite	Key length (octets)	TK_bits (bits)
   …	…	…
   CCMP-128	16	128
   …	…	…

PMK がパスフレーズから作られず、認証のたびに変わるので、WPA2-Personal のようにオフライン辞書攻撃や オフライン総当たり攻撃で PTK の複製を試みる攻撃は、現実的には成立しない。
WPA2-Enterprise を狙う場合は、IDとパスワードを盗み出すような攻撃が多いはず。

WPA2に対する攻撃¶

WPA2 に対する代表的な攻撃として、WPA2-Personal のパスフレーズクラッキングと WPA2-Enterprise(EAP-PEAP) のパスワードクラッキングがある。 自分のネットワークに対して検証できた攻撃手法を書いていく。

WPA2-Personal：パスフレーズクラッキング¶

WPA2-Personal の認証プロセス例は下図の通り。

WPA2-Personal では、STA と AP で設定した共通のパスフレーズにより認証を行う。 認証の際にパスフレーズに関する情報が送信されることはなくて、 4-Way Handshake によって互いに同じ Pairwise Transient Key（PTK）を作成することが認証の条件。 WPA2-Personal のパスフレーズには、8 文字から 63 文字の ASCII 文字を設定できる。

認証プロセスにおいて、4-Way Handshake では PTK の作成に必要な情報の一部が平文で通信される。 なので、そのフレームを盗聴して PTK の複製をするために、辞書攻撃などでパスフレーズを解析する攻撃が可能。

4-Way Handshake フレームの盗聴には、特殊な機器が必要なわけではなくて、 Apple MacBook でも可能だし、辞書ファイルはインターネット上にたくさんあるし、この攻撃の難易度は低いと思う。

攻撃のポイントとしては、パスフレーズを見つけられるかどうかっていうのが重要。 なので、一番簡単で重要な対策は、できるだけ長くて複雑なパスフレーズを使うこと （辞書ファイルにも載っていない・総当たりでも見つけるまでに時間がかかるようにする）。

WPA2-Enterprise：パスワードクラッキング¶

EAP-PEAP を用いた WPA2-Enterprise の認証プロセス例は下図の通り。

なお、図中の 15 で AS から送信される Challenge に対して、Supplicant がパスワードを使って Response を生成して、16 で AS に送信するので、認証情報っぽいものが流れるのはそのタイミング。 ただし、13〜18 の通信（図中の緑色部分）は TLS トンネルによって暗号化されるので、盗聴するだけではフレームの中身は分からない。

Response が暗号化されているので、それを横から盗聴するのではなくて、 正規の Authenticator（+ AS） になりすます（Evil Twin 攻撃）ことで、 復号鍵を持った状態で Response の受信を狙う。
Response の受信に成功したら、パスワード解析ツールと辞書ファイルを使ってパスワードを解析する攻撃が可能。

Supplicant が偽 Authenticator（+ AS） に接続する際には、サーバー証明書に関する警告が表示される。 これは、Supplicant が受け取ったサーバー証明書が、信頼できる正規の Authenticator（+ AS） のもので はなく、信頼されていない偽 Authenticator（+ AS） のものだったから。

攻撃のポイントとしては、偽 Authenticator（+ AS） に Supplicant を接続させられるかどうか っていうのが重要。なので、一番確実な対策は、サーバー証明書に関する警告が出て怪しいときは、 ユーザーがその WLAN に接続しないこと（正規の Authenticator（+ AS） であると確認できた場合にだけ、接続する）。

WPA3¶

WPA3 は 2018 年に Wi-Fi Alliance によって定められたセキュリティ規格。 認証方式によって、WPA3-Personal と WPA3-Enterprise に区別される。 あと、最高レベルの Wi-Fi セキュリティ規格として、192-bit mode も定義された。

WPA3（Only Mode, 192-bit Mode）では Protected Management Frames（PMF） の使用が必須条件 であるため、Deauthentication 攻撃を阻止できる。

WPA3-Personal¶

WPA2-Personal からの一番重要な進化は、PSK 認証ではなくなって、SAE 認証に変わったこと。 パスフレーズを共有しておくっていう UX は変わっていないけど、毎回異なる PMK が生成されるので格段に安全になった。

認証アルゴリズムも Open System authentication ではなく SAE になる。下図は実際の接続シーケンスで、Authentication フレーム（#3〜6）が SAE の Commit・Confirm のやり取り。

SAE では、STA と AP が互いに Commit（SEQ 1）と Confirm（SEQ 2）を送り合い、パスワードを知っていることを互いに証明する（相互認証）。

WPA3-Enterprise¶

The transitional mode allows for backward compatibility with WPA2-Enterprise. This allows WPA2-Enterprise clients to connect to the same SSID as WPA3-Enterprise clients. 802.1X/EAP authentication remains the same. However, in this mode MFP is used by the WPA3 clients but not necessarily by the WPA2 clients.
− CWNA Study Guide, p.760 より

WPA2-Enterprise との違いは、802.1X/EAP 認証はそのままで、主に変わる点は PMF と AKM。

WPA3-Enterprise 192-bit mode¶

WPA3-Enterprise 192-bit mode is well suited for deployments in sensitive enterprise environments to further protect Wi-Fi® networks with higher security requirements such as government, defense, and industrial.
− WPA3™ Specification Version 3.5, p.16 より

• EAP-TLS 認証が必須で、セキュリティレベルの高い 3 つの TLS の暗号スイートのみを使える。

• Supplicant と Authenticator 間の通信は 256 bit の共通鍵によって暗号化される。

プライベートCAの構築¶

EAP-TLS を導入するためにはクライアント証明書を準備する必要があって、そのためにプライベート CA を構築した。 プライベート CAでは、CA 証明書・サーバー証明書・クライアント証明書を発行する。

WPA3-Enterprise 192-bit mode では、EAP-TLS の鍵交換アルゴリズムとして ECDHE_RSA を使用する場合、 RSA 鍵長が 3,072 bit 以上であることが条件の 1 つ。

なので、プライベート CA で発行する証明書の公開鍵および対応する秘密鍵はすべて、3,072 bit の RSA 鍵としてる。

プライベート CA の構築と証明書の発行は、Rocky Linux 8（OpenSSL 1.1.1k）で行った。 発行したのは、CA 証明書・AS（RADIUS サーバー）のサーバー証明書・クライアント証明書の 3 つ。

1. 設定ファイルを用意する

/etc/pki/tls/openssl.cnf をコピーして /etc/pki/CA/openssl_ishigakiCA.cnf を作り、主に下記を変更した。 default_bits で RSA 鍵長を 3,072 bit にしているのが、WPA3-Enterprise 192-bit mode の条件に合わせたところ。 サーバー証明書とクライアント証明書は、証明書拡張の server_ext と client_ext で用途を分けている。

[ CA_default ]
certificate   = $dir/ishigakiCA-cert.pem
private_key   = $dir/private/ishigakiCA-key.pem
default_days  = 3650

[ req ]
default_bits  = 3072

[ v3_ca ]
keyUsage = cRLSign, keyCertSign

[ server_ext ]
authorityKeyIdentifier  = keyid:always
extendedKeyUsage        = serverAuth
keyUsage                = critical,digitalSignature,keyEncipherment
basicConstraints        = critical,CA:false

[ client_ext ]
authorityKeyIdentifier  = keyid:always
extendedKeyUsage        = clientAuth
keyUsage                = critical,digitalSignature,keyEncipherment
basicConstraints        = critical,CA:false

default_days は証明書の有効期間（10 年）。

2. CA の管理ファイルを作る

# cd /etc/pki/CA
# touch index.txt
# openssl rand -hex 16 > serial

index.txt は発行した証明書の台帳、serial は次に発行する証明書のシリアル番号。

3. CA 証明書を作る

# openssl req -new -x509 -days 3650 -extensions v3_ca \
    -keyout private/ishigakiCA-key.pem -out ishigakiCA-cert.pem -config ./openssl_ishigakiCA.cnf

CA 証明書は自己署名証明書になる。 CA 秘密鍵にはパスフレーズを設定していて、証明書に署名するたびに入力を求められる。 CA 秘密鍵は、オフラインで保管するなど安全に管理する必要がある。

4. サーバー証明書を発行する

# openssl req -new -nodes -out radius-req.pem -keyout private/radius-key.pem -config ./openssl_ishigakiCA.cnf
# openssl ca -config ./openssl_ishigakiCA.cnf -notext -out radius-cert.pem -in radius-req.pem -extensions server_ext

openssl req で秘密鍵と証明書署名要求（CSR）を作り、openssl ca で CA が署名して証明書を発行する。 -nodes は、秘密鍵をパスフレーズなしで出力するオプション。 -notext は、証明書ファイルに人が読むためのテキスト形式の内容を付けず、PEM 形式だけで出力するオプション。 -extensions server_ext を指定したので、発行時の確認では用途がサーバー認証（TLS Web Server Authentication）になっている。

        X509v3 extensions:
            X509v3 Extended Key Usage:
                TLS Web Server Authentication
            X509v3 Key Usage: critical
                Digital Signature, Key Encipherment
            X509v3 Basic Constraints: critical
                CA:FALSE
Certificate is to be certified until May 28 01:10:16 2033 GMT (3650 days)

証明書と秘密鍵がペアになっているかは、それぞれの modulus のハッシュ値が一致するかで確認できる。

# openssl x509 -noout -modulus -in radius-cert.pem | openssl md5
# openssl rsa -noout -modulus -in private/radius-key.pem | openssl md5

最後に、証明書と秘密鍵を 1 つのファイルにまとめた。

# cat radius-cert.pem private/radius-key.pem > radius-cert_key.pem

5. クライアント証明書を発行する

# openssl req -new -nodes -out client-req.pem -keyout private/client-key.pem -config ./openssl_ishigakiCA.cnf
# openssl ca -config ./openssl_ishigakiCA.cnf -notext -out client-cert.pem -in client-req.pem -extensions client_ext
# openssl pkcs12 -export -in client-cert.pem -inkey private/client-key.pem -out client-cert.p12

-extensions client_ext で、用途をクライアント認証（TLS Web Client Authentication）にしている。 端末にインストールするために、証明書と秘密鍵を PKCS#12 形式（.p12）にまとめた。 PKCS#12 ファイルには、書き出すときにパスワードを設定する。

EAP-TLS¶

EAP-TLS は RFC 5216 で 標準化されているプロトコル。 EAP-TLS における相互認証は、Supplicant が TLS クライアント、AS が TLS サーバーとして、 TLS Handshake プロトコルでセッションを確立することによって行われる（下図; 鍵交換アルゴリズムが ECDHE_RSA、TLS 1.2 を使用した場合）。

クライアントがサーバーを認証するプロセス

1. クライアントが Client Hello メッセージ（図中 12）で 32 バイトのクライアント乱数を送信する。
2. サーバーが Server Certificate メッセージ（図中 14）でサーバー証明書を送信する。
3. サーバーが Server Key Exchange メッセージ（図中 15）で ECDH パラメーターと署名を送信する。 （クライアント乱数・Server Hello（図中 13）で送信するサーバー乱数・ECDH パラメータの 3 つを結合した後で、 サーバーはサーバー秘密鍵を用いて署名する。）
4. クライアントはサーバー証明書を検証し、検証に成功した場合、サーバー証明書に含まれるサーバー公開鍵を 取り出し、署名を検証する。

サーバーがクライアントを認証するプロセス

1. サーバーが Server Hello メッセージ（図中 13）で 32 バイトのサーバー乱数を送信する。
2. サーバーが Certificate Request メッセージ（図中 16）で、受け入れ可能なクライアント証明書の種類に関する 情報（署名アルゴリズム・ハッシュ関数・CA 識別名）を通知する。
3. サーバー認証が成功した場合、クライアントは Client Certificate メッセージ（図中 18）でクライアント証明書を 送信する。
4. クライアントは Certificate Verify メッセージ（図中 20）より前の TLS Handshake メッセージ全てをクライ アント秘密鍵で署名し、Certificate Verify メッセージ（図中 20）で署名を送信する。（サーバー乱数が含まれる Server Hello メッセージを含め、クライアントはクライアント秘密鍵を用いて署名する。）
5. サーバーはクライアント証明書を検証し、検証に成功した場合、クライアント証明書に含まれるクライ アント公開鍵を取り出し、署名を検証する。

相互認証において、証明書や署名の検証に失敗した場合は、TLS Handshake プロトコルを用いたセッション の確立に失敗し、EAP-TLS の認証も失敗となる。

TLS セッションの完全性を検証するために、Finished メッセージに含まれる verify_data が使われる。 verify_data は、Finished メッセージより前の TLS Handshake メッセージ全て（Hello Request メッセージは除く）をハッシュ化して、マスターシークレットと組み合わせて計算される。Finished メッセージは暗号化され、メッセージ認証コードにより完全性が保証される。

WLAN では、認証が成功した Supplicant と Authenticator 間のユニキャスト通信は、PTK に含まれる Temporal Key（TK）によって暗号化される。PTK の作成に必要となる Master Session Key（MSK）の 作成方法を次に示す。なお、MSK の先頭 32 バイトを Pairwise Master Key（PMK）として、PTK の 作成に使用する。

1. サーバーとクライアント、両者でプリマスターシークレットを共有する。（プリマスターシークレットの 共有方法は鍵交換アルゴリズムにより異なる。）
2. プリマスターシークレット・サーバー乱数・クライアント乱数を使って、48 バイトのマスターシーク レットを擬似乱数関数により計算する。
3. マスターシークレット・サーバー乱数・クライアント乱数を使って、64 バイトの MSK を擬似乱数関数に より計算する。

各機器の設定¶

• Supplicant: CA 証明書・クライアント証明書ファイルをインストールして、WPA3-Enterprise 192-bit mode を使って WLAN に接続する設定

• Authenticator（Aruba AP-615）: SSID プロファイルにおいて WPA3 CNSA（192-bit mode）を使用する設定, authentication-server プロファイルにおいて RADIUS クライアント設定

  Aruba AP-615 の プロファイル例

  Aruba IAP では、SSID プロファイルで WPA3 CNSA（192-bit mode）を指定し、auth-server プロファイルで FreeRADIUS を RADIUS サーバーとして登録する。

  SSID プロファイル:

  wlan ssid-profile ishigaki-wlan_cnsa
   enable
   index 0
   type employee
   essid ishigaki-wlan_cnsa
   opmode wpa3-cnsa              # WPA3 CNSA（192-bit mode）を使う
   max-authentication-failures 0
   vlan guest
   auth-server ishigakiRADIUS     # 認証サーバーは設定した FreeRADIUS
   rf-band none
   rf-band-6ghz
   captive-portal disable
   dtim-period 1
   broadcast-filter none
   dmo-channel-utilization-threshold 90
   local-probe-req-thresh 0
   max-clients-threshold 64
  

  認証サーバー:

  wlan auth-server ishigakiRADIUS
   ip 192.168.0.101              # FreeRADIUS サーバーの IP
   port 1812
   acctport 1813
   key radius-shared-secret     # RADIUS シークレット（FreeRADIUS 側と一致させる）
   rfc5997 auth-only
   service-type-framed-user 1x
  

  Dynamic RADIUS proxy を有効にすると、RADIUS アクセス時の送信元 IP を Virtual Controller（VC）のアドレスに限定できる（無効だと各 IAP の IP で RADIUS にアクセスする）。cf: Dynamic RADIUS Proxy

  (Instant AP)(config)# dynamic-radius-proxy
  (Instant AP)(config)# end
  (Instant AP)# commit apply
  

• AS: FreeRADIUS を Rocky Linux 8 にインストールして設定, EAP-TLS 認証で使用するサーバー証明書・サーバー 秘密鍵・CA 証明書ファイルのインストール, 使用する楕円曲線を P-384 とする設定

  FreeRADIUS（AS）の EAP-TLS 設定

  AS（FreeRADIUS 3.0.20, Rocky Linux 8）の主な設定は次の通り。EAP-TLS を既定の EAP メソッドにして、 WPA3-Enterprise 192-bit mode の条件に合わせて楕円曲線を P-384（secp384r1）に指定している。

  /etc/raddb/mods-enabled/eap（抜粋）:

  default_eap_type = tls                                 # EAP-TLS を使う
  
  private_key_file     = ${certdir}/radius-key.pem       # サーバー秘密鍵
  certificate_file     = ${certdir}/radius-cert.pem      # サーバー証明書
  ca_file              = ${certdir}/ishigakiCA-cert.pem  # CA 証明書
  private_key_password = server-secret-password
  
  check_crl  = no
  ecdh_curve = "secp384r1"                               # 192-bit mode は最低でも P-384
  

  AP を RADIUS クライアントとして /etc/raddb/clients.conf に登録する。

  client 192.168.0.100 {
      ipaddr = 192.168.0.100
      secret = radius-shared-secret
  }
  

  その後、firewalld で UDP/1812・1813 を開放して radiusd サービスを起動する。

  クライアント証明書の失効（CRL）: Aruba IAP

  クライアント証明書を失効させて、その端末の Wi-Fi 接続を拒否したい場合は、プライベート CA で CRL（証明書失効リスト）を発行し、FreeRADIUS に反映する。

  プライベート CA 側で、対象の証明書を失効させて CRL を生成する。

  # openssl ca -revoke client-cert.pem -config openssl_ishigakiCA.cnf
  # echo 1000 > crlnumber
  # openssl ca -gencrl -out crl.pem -config openssl_ishigakiCA.cnf
  

  openssl ca -revoke で証明書を失効させ、openssl ca -gencrl で CRL を発行する。crlnumber ファイルは初回のみ作成する。失効は台帳 index.txt で確認でき、先頭の R が失効済みを表す。CRL の有効期間は openssl.cnf の default_crl_days で設定する。

  FreeRADIUS 側に CRL を置き、ハッシュを張り直して再起動する。

  # cp crl.pem /etc/raddb/certs/
  # openssl rehash /etc/raddb/certs/
  # systemctl restart radiusd
  

  あわせて mods-enabled/eap の check_crl を yes にする（最初の設定では no）。失効した証明書で接続を試みると認証に失敗し、RADIUS のログに certificate revoked が記録される。

  ERROR: (50) eap_tls: ERROR: SSL says error 23 : certificate revoked
  Auth: (50) Login incorrect (eap_tls: SSL says error 23 : certificate revoked)
  

  なお、Aruba IAP には CRL をアップロードする手段が見当たらないので、Internal RADIUS（AP 内蔵の RADIUS）を使う場合は、信頼された CA が発行した証明書であれば失効済みでも接続できてしまうかも。

  クライアント証明書の CN をログに記録する: Aruba IAP

  EAP-TLS では、ユーザー ID は平文で電波に乗るので、本来はダミーにしておく方が安全。ただし何も設定しないと、RADIUS のログに記録されるユーザー名は Supplicant が入力した ID そのものになるため、ダミーにすると「誰の接続か」が分からなくなる。そこで、ログのユーザー名をクライアント証明書の CN に置き換える。

  何も設定しないと、入力した ID がそのままログに載る（CN を入れれば CN、ダミーの dummy01 を入れれば dummy01）。

  Auth: (7846) Login OK: [client01/<via Auth-Type = eap>] (from client 192.168.0.100 port 0 cli 001122334455)
  Auth: (7855) Login OK: [dummy01/<via Auth-Type = eap>] (from client 192.168.0.100 port 0 cli 001122334455)
  

  /etc/raddb/sites-enabled/default の post-auth の先頭に、クライアント証明書の CN を User-Name に代入する if 文を追加する。

  post-auth {
      if (&TLS-Client-Cert-Common-Name) {
          update request {
              &User-Name := "%{TLS-Client-Cert-Common-Name}"
          }
      }
  
      # （以降は既存の設定のまま）
  }
  

  radiusd を再起動すると、以降は入力値によらずクライアント証明書の CN がユーザー名としてログに記録される。

設定後、Supplicant は EAP-TLS 認証で WLAN に接続が可能となった（EAP-TLSでのみ OK）。

Wi-Fi フレームの確認¶

接続時のフレームをキャプチャして、WPA3-Enterprise 192-bitmode の仕様通りになってることを確認できた。

• Probe Respones

RSN Information で、WPA3-Enterprise 192-bit mode に必要な下記の 5 つを確認。

• Association Request

Association Request の RSN Information でも、STA が選択した値として下記の 5 つを確認。

• EAP Request

EAP フレームに含まれる TLS セッションの Server Hello と Server Key Exchange で、下記の 3 つを確認。

References¶

1. Wi-Fi Alliance, “WPA3™ Specification Version 3.5”
2. Elaine Barker, “NIST SP 800-57: Recommendation for Key Management: Part 1 – General Revision 5”
3. CA/Browser Forum, “Baseline Requirements for the Issuance and Management of Publicly-Trusted Certificates Version 2.0.0”
4. David Cooper, et al., “RFC 5280: Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile”
5. Dan Simon, et al., “RFC 5216: The EAP-TLS Authentication Protocol”
6. Tim Dierks & Eric Rescorla, “RFC 5246: The Transport Layer Security (TLS) Protocol Version 1.2”
7. Bernard Aboba, et al., “RFC 3748: Extensible Authentication Protocol (EAP)”
8. Yoav Nir, et al., “RFC 8422: Elliptic Curve Cryptography (ECC) Cipher Suites for Transport Layer Security (TLS) Versions 1.2 and Earlier”
9. Kathleen Moriarty, et al., “RFC 8017: PKCS #1: RSA Cryptography Specifications Version 2.2”
10. David D. Coleman & David A. Westcott (2021), CWNA: Certified Wireless Network Administrator Study Guide Exam CWNA-108, 6^th ed, John Wiley & Sons
11. Jennifer (JJ) Minella (2022), Wireless Security Architecture, John Wiley & Sons
12. Ivan Ristić 著、齋藤孝道 監訳 (2017)、『プロフェッショナル SSL/TLS』、ラムダノート
13. 齋藤孝道 (2022)、『マスタリング TCP/IP 情報セキュリティ編（第 2 版）』、オーム社