無線LANのセキュリティについて

資格
2019.08.26
スポンサーリンク

ネスぺ平成29年の午後２の問２で無線LANのセキュリティについての問題が出題されました。コテンパンにされたので、自分の備忘録として無線LANのセキュリティについて整理しました。
自分の試験前の見直し用ですので、間違いがあったらご指摘ください。

　

目次

　

無線LANのセキュリティ規格

無線LANのセキュリティ規格としては大きく４つある。

  • WEP(Wired Equivalent Privacy)
    • 脆弱性が見つかっており、現在は使用が非推奨。
  • WPA(Wi-Fi Protected Access)
    • WEPの脆弱性に対応すべく策定途中のIEEE 802.11iから先取りする形でWi-Fiアライアンスによって策定された。
  • WPA2(Wi-Fi Protected Access 2)
    • IEEE 802.11iを完全準拠した規格。
  • WPA3(Wi-Fi Protected Access 3)
    • WPA2/WPAには脆弱性「KRACKs」という脆弱性があることが知られており、その脆弱性対応した規格。2018年に策定された。
    • 「WPA3-Personal」では、PSK(Pre-shared Key)は使用せず、「SAE（Simultaneous Authentication of Equals）」というハンドシェイクで鍵交換をする。

WPA3は去年策定されたばかりであり、オプション扱いで搭載されているものなので、以下ではWEP、WPA、WPA2についてまとめる。

　

セキュリティを考えるうえで、以下の３つの観点で整理した。

  1. 暗号化方式
  2. 整合性の検証方法
  3. 認証方式

　

　

無線LANのセキュリティ規格の比較

全体をまとめると以下のようになる。

セキュリティ規格WEPWPAWPA2
暗号化方式
(暗号化アルゴリズム)		WEP(RC4)TKIP(RC4)CCMP(AES)
整合性の検証方法CRC32MICCCM
認証方法・Open System認証
・Shared key認証
(WEPキーによる認証)		・WPA /WPA2パーソナルモード
PSK(Pre Shared Key)による認証
・WPA /WPA2エンタープライズモード
IEEE 802.1Xによる認証

　

　

暗号化方式

WEPの暗号化方式

構成要素説明
暗号化方式WEP
暗号化アルゴリズムストリーム暗号化のRC4を採用
共通鍵の長さ40 or 104bit(WEPキー)
IVの長さ24bitのIV(Initialization Vector;初期化ベクトル)
暗号鍵の長さ64 or 128bit(WEPキー + IV)

　

暗号化アルゴリズムは以下の通り。

引用元： https://www.infraexpert.com/study/wireless9.html
  • 暗号化はDataとキーストリーム(WEPキー＋IV)のXOR(排他的論理和)
  • WEPキーはアクセスポイントと接続端末間で共通の鍵情報
  • IVは接続端末で生成されるが、IV部分は暗号化対象となっていない。
    パケットキャプチャで盗聴されるとばれる。

　

WPAの暗号化方式

構成要素説明
暗号化方式TKIP(Temporal Key Integrity Protocol)
暗号化アルゴリズムストリーム暗号化のRC4を採用
Temporal Keyの長さ128bit
IVの長さ48bit
暗号鍵の長さ104bit
WEPよりも複雑な暗号化鍵生成方法を実装

暗号鍵は以下のように生成される。

引用元： https://www.infraexpert.com/study/wireless12.html
  • Temporal Keyはパーソナルモードとエンタープライズモードでは生成の仕方が違う。
    パーソナルモードでは事前に共有しているPSK(Pre-Shared Key)から算出される。一方、エンタープライズモードではIEEE 802.1Xの認証後、認証サーバからセッションキーが動的に払出しされる。
  • 鍵の交換についてはPMK(Pairwaise Master Key)から4way Handshake を行うことで生成される。詳細については「【図解】WPA2の仕組みと脆弱性KRACK, 4way Handshake のシーケンスについて | SEの道標」参照。
  • TKIPではTemporal Key＋接続端末のMACアドレス＋IVで暗号鍵を生成する。
  • 暗号鍵を使った暗号方法はRC4のため、WEPと同じ。

　

WEP2の暗号化方式

構成要素説明
暗号化方式CCMP(Counter-mode CBC-MAC Protocol)
暗号化アルゴリズムブロック暗号化のAESを採用
Temporal Keyの長さ128bit(おそらく？？？)
IVの長さ48bit
暗号鍵の長さ128bit
WPAよりも長くした。

暗号鍵の生成方法はWEPと同様な手順で生成される。

一方、暗号化アルゴリズムはAESであり、以下の通り。

引用元： https://www.infraexpert.com/study/wireless13.html
  • AESはブロック暗号なので、暗号化するメッセージを一定サイズのブロック単位に分割する。
  • 平文をダイレクトに暗号化するのではなく、カウンタ値を暗号化してそれをXORするようにする。これはブロック分割などでデータがブロック未満になった時でも、カウンタ値をブロックサイズと同じサイズにしておくことで、AES暗号化できるようにするため。
  • 後述するCCMPでも整合性と合わせて暗号化処理をしているので、カウンタ値は平文とIV or 前カウンタの暗号文のXORで算出されている？？？

　

　

　

整合性の検証方法

WEPの整合性の検証方法

整合性の検証方法は、「CRC32」で行う。
CRC32でデータを特定のルールで送信側と受信側で計算し、その計算値を比較することでデータ破損や改ざんを検知することができる。

CRC32については以下のサイトが分かりやすい。

　

引用元： https://www.infraexpert.com/study/wireless9.html
  • 検証値をICV(Integrity Checksum Value)という。
  • ICVは計算式が分かれば、改ざんできてしまうので、データと合わせて暗号化して、受信側で複合後に検証する。

　

WPAの整合性の検証方法

整合性の検証方法は、「MIC」で行う。
CRC32同様、データを特定のルールで送信側と受信側で計算し、その計算値を比較することでデータ破損や改ざんを検知することができる。

引用元： https://www.infraexpert.com/study/wireless12.html
  • Michaelアルゴリズムによってハッシュ値が計算されている。
  • MICを計算していてもICV(CRC32)の計算は行う。

　

WPA2の整合性の検証方法

整合性の検証方法は、「CCM(Counter with CBC-MAC)」で行う。

引用元： https://www.infraexpert.com/study/wireless13.html
  • 整合性用のハッシュ値は最後のカウンタの暗号文が使われる。
  • 複合時のハッシュ値算出はどうやってやるのか？？？

　

　

　

認証方式

WEPの認証方式

認証方式は２つある。

  • Open System認証
    • 認証は行わなず、必ず成功が返る。
  • Shared key認証
    • APから送られてきた任意の文字列をWEPキーで暗号化して、それがWEPキーで複合できたら認証成功。
    • WEPキーは暗号化されずにパケット内に乗っているので、傍受されたらすぐにばれる。

上記より、WEPでは実質的には認証機能がない。

　

WPA/WPA2(パーソナルモード)の認証方式

アクセスポイントと接続端末の間で同じPSK(Pre-Shared Key)が設定されているかを確認することで認証を行う。
PSKはアクセスポイントに設定されているネットワークセキュリティキーから生成される。ネットワークセキュリティキーが流出したら誰でも接続できてしまうので、注意すること。

　

WPA/WPA2(エンタープライズモード)の認証方式

エンタープライズモードではIEEE 802.1Xを使って認証を行う。802.1Xでは認証プロトコルとしてEAP(PPP Extensible Authentication Protocol)を採用している。

さらに、EAPは認証方式によっていくつか分類される。

認証プロトコルサーバ認証クライアント認証
EAP-MD5なしユーザ名とパスワードによる認証
パスワードはMD5でハッシュ化して送信
EAP-PEAP
(Protected EAP)		サーバ証明書による認証クライアント-サーバ間で暗号化した通信路を確保後、ユーザ名とパスワードによる認証
EAP-TLSサーバ証明書による認証 クライアント証明書による認証
EAP-TTLS
(Tunneled TLS)		サーバ証明書による認証 クライアント-サーバ間で暗号化した通信路を確保後、ユーザ名とパスワードによる認証

プロトコルスタックとしては以下の通り。

引用元： https://www.infraexpert.com/study/wireless14.html
  • LEAPはCisco独自規格のため、ネスぺとしては気にしなくてOK
  • EAPOLは「EAP over LAN」の略で、EthernetやWi-Fiの差分を吸収してくれるレイヤ。

　

以下では、特にネスぺ平成29年の午後２の問２で出題された「EAP-TLS」について整理する。

EAP-TLSの認証方法

TLSと記載ある通り、認証対象の接続端末(サプリカント)と認証サーバ間でTLSのハンドシェイクを実行する。

  • ClientHelloとServerHello
    • 初期乱数、プロトコルバージョン、SessionID、暗号方式、圧縮方式などの暗号化アルゴリズムに必要な情報を交換する。
    • SessionIDがサーバとクライアント間で一致すれば一気に、ChangeCipherSpecまで進められる。
  • ServerCertificateとClientCertificate
    • ServerCertificateでサーバ証明書をクライアントに送信し、クライアント側でサーバ認証を行う。
    • ClientCertificateでクライアント証明書をサーバに送信し、サーバ側でクライアント認証を行う。
  • ServerKeyExchangeとClientKeyExchange
    • サーバとクライアント間で使用する共有鍵を交換する。
    • SSL/TLSで使われる鍵交換方式はRSA, DHE, ECDHEの３種類が主流。鍵交換方式によって、プリマスターシークレット(pre_master_secret)を交換し合う。
    • 共有秘密鍵はクライアント初期乱数、サーバ初期乱数、プリマスターシークレットから算出される。

参考：
SSL/TLS（SSL3.0～TLS1.2）のハンドシェイクを復習する | Qiita

　

EAP-TLSでは上記のTLSのハンドシェイクをIEEE 802.1X/EAP上で実行する。IEEE 802.1X/EAPでは以下のように、オーセンティケータがEAPOLパケットとRADIUSパケットを中継する。

引用元： https://www.infraexpert.com/study/wireless14.html

本来、TLSはトランスポートレイヤのプロトコルであり、TCP上で動くものであるが、RADIUSパケットはUDPであり、TLSのパケットをRADIUSのUDPパケットでカプセル化して送受信している。

IEEE 802.1X/EAPでのTLSハンドシェイクは以下のようなシーケンスになる。

引用元： https://www.nic.ad.jp/ja/materials/security-seminar/20051007/4_osamura_2005.pdf
  • PPP EAP/Req/Identityでオーセンティケータ(アクセス端末)からID要求があり、サプリカント(ユーザ端末)からID応答が送信される。オーセンティケータはそれを認証サーバに転送する。
  • IDを受け取った認証サーバはEAP/Rwq/TLS startで認証を開始する。
  • 認証中は、RADIUSパケットのAccess-Request(オーセンティケータ⇒認証サーバ)、Access-Challenge(認証サーバ⇒オーセンティケータ)を使って認証を行う。
  • 認証が完了したら、認証サーバからAccess-Acceptパケットが送信される。

なお、RADIUSパケットのフォーマットは以下のようにUDPパケットになる。

引用元： https://www.infraexpert.com/study/security20.html

　

　

　

補足

APとの接続シーケンス

上記の内容では、暗号化、認証についてまとめたが、APとの接続には事前に接続先のESSIDやチャネルを接続端末とAP間で合わせる必要がある。
そのために、以下のようなパッシブスキャンもしくはアクティブスキャンを行う。

引用元： https://www.infraexpert.com/study/wireless8.html
  • パッシブスキャンはAPが定期的に送信しているESSID入りのBeaconフレームを端末側で受信し、ESSIDと受信したチャネルを認識する。
  • アクティブスキャンは端末側からESSIDを指定して、全チャネルに対してProbe requestを送信する。Probe requestを受信したAPはESSIDが一致したら、Probe responseを返す。端末はProbe responseを受信したら、受信したチャネルを指定したESSIDのAPだと認識する。
  • 認証(Authentication)は方式ごとに上記の章でまとめた手順で実施される。
  • アソシエーションが済んだら、鍵交換のプロセスを行った後、暗号化されたデータが送受信されるようになる。

　

　

WPA/WPA2の鍵交換プロセス

上記の暗号化方式でまとめたとおり、WPA/WPA2のパーソナルモードなら、PSK(Pre-Shared Key)から、WPA/WPA2のエンタープライズモードならIEEE 802.1XのセッションキーからPMK(Pairwise Master Key)が生成される。

このPMKから4way Handshakeを行うことでPTKと呼ばれるユニキャスト通信で使用する鍵とGTKと呼ばれるマルチ/ブロードキャスト通信で使用する鍵を生成する。
※PTK/GTKによって暗号鍵の生成に使われるTemporal Keyが生成される。

4way Handshakeは以下のようなシーケンス。

引用元： https://milestone-of-se.nesuke.com/nw-advanced/nw-security/krack/
  • PTKを生成するために、AP⇒接続端末にANonce、接続端末⇒APにSNonceが送信される。
  • PTKはPMK,ANonce,SNonce,APのMACアドレス,接続端末のMACアドレスによって生成される。

　

　

サーバ証明書、クライアント証明書について

ネスぺのH29午後2の問2設問4でクライアント証明書の配布に関する問題がでた。そのため、証明書関連についても整理する。

「EAP-TLSの認証方法」の章でもまとめたが、SSL/TLSではClient Helloから鍵交換、証明書による認証を行う。証明書まで考慮したSSL/TLSハンドシェイクは以下のようになる。

引用元： https://www.infraexpert.com/study/security28.html

クライアント側で実施される「サーバ証明書の検証」とは以下のようなイメージで行われる。

  1. サーバ証明書にはサーバの公開鍵以外に認証局の秘密鍵で署名された認証局のデジタル署名が同封されている。
  2. また、クライアント側では有名な認証局のルート証明書は事前にブラウザが登録済みであり、ルート証明書の中に認証局の公開鍵がある。
  3. サーバ証明書に同封された認証局のデジタル署名を認証局のルート証明書に同封された公開鍵で複合し、署名の妥当性を検証する。署名が正しければ、信用された認証局で発行されたサーバ証明書であると判断することができる。
    ※ただし、ルート証明書は信用されたものである前提

　

ネスぺのH29午後2の問2設問4では、クライアント側に準備するものは何かを問われている。上記のシーケンスを見るとわかるが、クライアント側で必要なものは以下の通り。

  • ルート証明書(認証局の公開鍵込)※
  • クライアント証明書(クライアントの公開鍵込)
  • クライアントの秘密鍵

※ ネスぺのH29午後2の問2設問4では、一般の認証局ではなく社内のRADIUSサーバの認証局機能を使っているので、クライアント側には事前にルート証明書は登録されておらず、ダウンロードする必要がある。

　

　

　

関連情報

　

　

参考

以下の書籍やサイトをよく参考にしました。

　

以上!

スポンサーリンク

コメント

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