設問1 ア：AES イ：事前共有鍵 ウ：SIMカード エ：APN オ：NAPT カ：CONNECT
ア：AES
WEPやWAPまではRC4ベースの暗号化を採用していた。しかしこれには脆弱性があるので、WPA2からは、より強固なAESが使われている。
イ：事前共有鍵
単語の通り、事前に鍵を共有しておく方式のこと。
ウ：SIMカード
LTEを使う時にユーザ情報を識別するためのものがSIMカード。これはモバイルWi-FiルータだけでなくスマホやタブレットなどのLTEを使う端末にはすべて必須とされている。
エ：APN
APN（Access Point Name）はインターネットへ出るための出口を示すもの。SIMカード内の情報から判断される。
オ：NAPT
IPアドレスとポートの変換を担う仕組みをNAPTという。
カ：CONNECT
CONNECTはプロキシをバイパスとしてHTTPS通信をしたい場合に使うHTTPメソッドの一つ。通常のプロキシはアプリケーション層の中身を見て、宛先を判断して中継する。しかし、CONNECTの場合はアプリケーション層を暗号化したいので、プロキシでは中継できない。それを防ぐために、プロキシをただのバイパスとして機能させる方法がCONNECTメソッド。別の言い方をすると、アプリケーション層による転送処理ではなく、TCP/IP層のみを見て転送させるというものである。
では、実際にどのような流れでHTTPS通信が確立されるかを見ていこう！
▼CONNECTメソッドによるHTTPS通信の流れ
１．ブラウザ（クライアント）→プロキシへ
①ブラウザはアクセスしたいサイトのURLを確認する
②もしURLがhttps://google.comのようにHTTPSと書かれていれば「HTTPS通信だ！」と認識する
③プロキシ設定を確認して、「直接ではなくプロキシを通さないとだめなのか」と認識する
④「よし、じゃあプロキシに接続しよう」と内部で以下の設定が発行される
▼CONNECTメソッド
CONNECT google.com:443 HTTP/1.1
Host: google.com:443２．プロキシ→サーバ
①プロキシはCONNECTメソッドに指定されたドメインを名前解決する
② ①で得たIPアドレスなどをもとに当該サーバとTCPコネクションを張る
③TCPのマッピングテーブルを作成する。
| プロキシ内部のID (ソケット) | クライアント側 (Src IP:Port) | 転送先 (Dest IP:Port) |
| トンネルA | 192.168.1.10 : 50001 | 104.21.XX.XX : 443 |
| トンネルB | 192.168.1.10 : 50002 | 142.250.XX.XX : 443 |
上のようなテーブルを作成することで、ユーザとサーバ間のアプリケーション層が暗号化されて宛先の判断に迷っても、適切にバイパス機能を提供できるようになる。
３．プロキシ→ブラウザ（クライアント）
プロキシからブラウザへ「200 Connection Established」というTCPセッション作成できた旨の報告を入れる。
＊このフェーズを参考書などでは、「トンネルの準備ができた」と表現されることがある。これだと、この時点で暗号化通信がプロキシとサーバ間で成立したニュアンスを感じるが実施はただTCPセッションができただけ。
４．ブラウザ⇔サーバ
ブラウザとサーバ間でTLSハンドシェイクを実施する。
TLSハンドシェイクが完了すると暗号化通信が実施される
👇TLSハンドシェイクのわかりやすい流れについては以下👇を見てみよう！
Q.一般的なHTTPのメソッドはどうなってるの？
A.CONNECTメソッドだけだと、全体を把握しにくいので、GETメソッドをみて、どういう風なのかをサラッと確認しよう！
▼CONNECTメソッド
CONNECT google.com:443 HTTP/1.1
Host: google.com:443
▼GETメソッド（プロキシあり）
＊プロキシ経由の場合は絶対パスの指定が必須
GET http://example.com/index.html HTTP/1.1
Host: example.com
▼GETメソッド（プロキシなし）
＊プロキシを経由しない場合はファイルのパスだけでよい
GET /index.html HTTP/1.1
Host: example.com設問２
（１）定期的に送信するビーコン信号を停止する。
結論から言うと、これは修正が必要な回答。正しくは「ビーコン信号にSSIDを含めない」となる。もし、ビーコン信号自体を止めてしまうと、そもそものクライアント接続がとても非効率なものになる。では、御託を並べても仕方がないので実際のフローを見ていこう！
▼ステルスモードにおける端末がAPに接続するフロー
１．APのビーコン信号
APはSSIDを載せずにビーコン信号を出す。
これにより、ユーザは「SSIDはわからないけど、このチャネルにこのような性能をもつAPがいるんだ！」と認識する
２．プローブ要求
クライアントは１で受け取ったSSIDが分からないAPに対して、自身が接続したいSSID名を付与して接続要求を送る。
３．接続
クライアントが指定したSSIDとAPのSSIDが一致すれば接続ができる。
以上。ここからわかるように、もし、APがビーコン信号すら発っさなければどのチャネルにAPがいるかという情報自体を得ることができなくなる。そうなると、クライアントは、各チャネル１つ１つに対してプローブ要求を送らなければならず、無駄なリソースを消費してしまう。そのため、APはたとえステルスモードであっても、ビーコン信号は発っし続けなければならない。
（２）SSIDやMACアドレスは暗号化できず、傍受されるから
回答の通り、WPAやWPA2などを使ってもSSIDやMACアドレスまでは暗号化できない。それに、無線の場合は電波が届く範囲内にいれば誰でも傍受ができるので、有線よりも簡単にMACアドレスやSSIDが取得できてしまう。
Q.MACアドレスやSSIDが漏れたらどんなリスクがあるの？
A.情報が洩れるとなりすましのリスクが格段に上がる。APのなりすましである「Evil Twin攻撃」やクライアントのなりすましなどが発生する。詳細をいかに記そう。
・Evil Twin攻撃：
攻撃者が正規のSSIDを取得し、不正APを立てる。そのアクセスポイントに正規のAPと同じSSIDをつけることによって、クライアントが偽APに接続して中間者攻撃などをされてしまう。
・なりすまし：
MACアドレスが漏洩すると、攻撃者が正規のMACアドレスと偽って接続できてしまう。そのためMACアドレスフィルタリングをしていても、MACアドレスは正常なので攻撃者からの接続を許してしまう。
Q.MACアドレスやSSIDの漏洩を防ぐ方法はあるの？
A.防ぐ方法はない。なぜなら、MACアドレスやSSIDを暗号化してしまうと、そもそもの接続自体が正規ユーザであっても不可能になってしまうから。
Q.どうやって対策するの？
A.WPAやWPA2などの暗号化機能や、証明書を利用して正当性を保証する。正直、SSIDやMACアドレスを隠ぺいすることは難しい。なので、そこにフォーカスするのではなく、正当なユーザしか知らない別の情報をあらかじめ用意しておき、その情報をつかって認証することでなりすましを防ごう！という考えにシフトさせる。そうすることで、たとえSSIDやMACアドレスが知られたとしても、それら以外の別の情報が洩れなければ正当性を保証できるようになる。
（３）E
タブレット端末はVPNを通してE社のLANと同一サブネットのようなふるまいをする。つまり、区間（E）と同一サブネットになるわけだから、もちろん重複もNGということになる。
では、ここからは上の構成図の詳細を見ていこう！プライベートIPアドレスの割り当てであったり、LTE回線があったり、VPNサーバへのアクセス、など様々なものがこの構成図に集約されている。それらの流れを整理しつつ紐解いていこう！
▼LTEとVPNのセッション確立の流れ
１．モバイルWi-Fiルータ（以後、MRとする）を起動
２．基地局→MME→ゲートウェイへ
MRが起動すると、自身のSIMカード情報を載せてLTE回線を経由して基地局へ運ぶ。その後、基地局は認証機関であるMMEに情報を渡す。MMEが内容を確認してAPNから適切なゲートウェイを見つけ、コアネットワークを経由して運ぶ。
３．通信路の確立（MRのインターネットアクセスの準備が整う）
MMEからのパケットが届くと、それらの情報をもとに基地局とゲートウェイ間にGTPトンネルを確立する。また、基地局とMR間には無線ベアラと呼ばれる方式で通信する。
＊この時に、ゲートウェイは適切なプライベートIPアドレスをMRに割り当てる。
４．タブレット端末からVPNサーバへ
①タブレット内のVPNアプリを起動する。宛先IPはVPNサーバ宛てになる。
②それがMRに届き、LTEから割り当てられたプライベートIPにNAT変換されてLTEゲートウェイまで届く。
③LTEゲートウェイがNAPT変換して、宛先IPまでパケット転送する。
５．VPNの作成
本文のp.9を見るとL2TP over IPsec方式を採用しているので、まずはIPsecの手順から進める。
６．IPsecVPNの確立
①ISKMP SAの確立
1.クライアント→サーバ
「僕はこのような暗号化方法、認証方法をサポートしているよぉ」と報告
2.サーバ→クライアント
「じゃあ、この方法で進めよう」と応答する
3.DiffieHellmanで共通鍵の生成
この共通鍵をSKEYIDと呼ぶ
4.認証
証明書を、2で決定した暗号化/認証方法に則り、3で作成されたSKEYIDを使って暗号化する。暗号化対象は、認証情報と今までのやり取りの要約情報が対象。
②IPsec SAの確立
1.クライアント→サーバ
「僕はこのような暗号化方法、認証方法をサポートしているよぉ」と報告
2.サーバ→クライアント
「じゃあ、この方法で進めよう」と応答する
3.鍵生成
PFS（前方秘匿性）がONの場合：DiffieHellmanで共通鍵生成
PFSがOFFの場合：SKEYIDとノンスを使って鍵生成
４データ通信開始
2で決定した暗号化/認証方法に則り、3で作成された鍵を使って暗号化する。
７．L2TPのトンネルの確立
①.お互いのメモリ上にトンネルマッピングを作る
クライアントが「俺は10番のトンネルIDでいきます！」と宣言し、サーバ側は「よし、じゃあ僕は20番のトンネルIDを使うよ」と宣言する。
これにより、お互いのメモリ上に、トンネルIDの10番と20番をマッピングさせる。これにより論理的なトンネルを作成する。
②.セッションIDの交換
クライアントが「俺はセッションIDを100番にします」と宣言し、サーバ側は「よし、じゃあ僕はセッションIDを200番でいくよ」と宣言する。
これにより、トンネルの中に通信レーンが確立される。
③.仮想的な箱（Virtual-Access インターフェース）の準備
セッションごとに適切な処理をするために仮想的な箱（Virtual-Access インターフェース）を準備する。vritual-accessとかっこつけた名前だが、要は「vlanインタフェースのような静的に作られる仮想インタフェースではなく、動的に生成される仮想インタフェースのこと」。これによって、ユーザごとに仮想インタフェースを割り当てられるので、ユーザごとにACLを割り当てたりすることができる。
８．PPPセッションの確立
PPPのステップは「準備→認証→IPアドレス割り当て」の３つのステップからなる。
①LCP（Link Control Protocol）確立
「認証どうする？圧縮方式どうする？」というような通信のルールを決めるフェーズの実施。
②認証
PAPやCHAPといった仕組みをつかってID/Passwordが正しいことを確認する
③IPCP（IP Control Protocol）
IPアドレスの割り当てを行う。その当該IPアドレスはL2TPで作成されたVirtual-Accessインタフェースに付与される。また、クライアントにも当該IPは渡される
このIPCPが終わるとやっと、通信ができるようになる。ここまでが大まかな通信開始までの流れ。では、この後行われる実際のデータ転送プロセスを見ていこう！
▼LTEとVPNのデータ通信の流れ
１．タブレット→モバイルWi-Fiルータへ
まずは、タブレット内でデータを生成し、L2TPとIPsecのヘッダをつける。
内側IP構成：[送信元：PPPで割り当てられたIPアドレス / 宛先：社内のLAN宛て]
外側IP構成：[送信元：MRから割り当てられたIPアドレス / 宛先：VPNサーバ宛て]
２．MR→LTEゲートウェイ
外側IP構成：[送信元：MRがLTEから割り当てられたIPアドレスに変換/ 宛先：VPNサーバ宛て]
３．LTEゲートウェイ→VPNサーバ
外側IP構成：[送信元：LTEがNAPT変換/ 宛先：VPNサーバ宛て]
NAPT変換によってグローバルIPアドレスに変換され、インターネットを跨ぐことができる。そして、VPNサーバに到達する。
４．VPNサーバ→Virtual Access
①外側パケットを解除する
②L2TPヘッダがでてくる
L2TPヘッダからTunnel ID、セッションIDを確認して、内部のマッピング情報から適切なVirtula Accessへ振り分ける。
この際にL2TPヘッダは剥がされる。
③Virtual Access
Virutal Accessへ行くと、PPPヘッダがあるので、それを剥がして内部へパケットを流す
５．内部LAN
無事、内部LANに届いたら処理をして、今までの逆の処理をしてユーザまで返す。
▼IPsecについてはこちらでも解説している
設問３
（１）VPN接続の利用者IDを停止する
本文より、現状の認証は利用者IDとワンタイムパスワードであることが推測できる。また、利用者IDは基本的に推測が容易なIDとなっている。例えば、社員番号やメールアドレスなど。これらは端末が盗まれてPCにログオンできれば簡単に割り出されてしまう。また、VPNの多くはIDを保存するという機能があるので、IDを盗む必要すらないというパターンも多い。そのため、「不正アクセスがありました！」と検知されるよりも前に、何かを紛失してしまった場合は速やかに利用停止をする必要がある。
（２）プロキシサーバと内部DNSサーバへの通信
p.7のポツ５つ目より、プロキシサーバを使う旨の記述があるので、まずはプロキシサーバの通信を許可する必要がある。また、VPN接続が完了した後に、実際にプロキシサーバを使うためにはプロキシサーバの名前解決をする必要がある。そのため内部DNSへの通信も許可する必要がある。
Q.どこで通信の可否を判断しているの？
現状の構成は上記のようになっている。で、結論から言うと、FWで接続可否を判断している。具体的な流れを以下に記す。
１．タブレット→VPN
まずは、VPN接続完了している端末からアクセスが届く。
２．VPN→SW1→FW
VPNサーバは外部からの通信なので、FWに通す。そのため、SW1を経由してFWに届ける。
３．FW
通信ルールから内部DNS or プロキシサーバ宛て以外の通信はブロックする。もし、それら２つならSW2に流す。
設問４
（１）機能名：プロキシ認証 設定内容：営業員ごとに利用者IDを登録する
プロキシ認証：
プロキシを使う際に認証を実施させる機能。具体的には、ユーザからの情報をもとに認証基盤（ActiveDirectoryなど）に正当性を確認し、OKなら許可しNGなら拒否する。プロキシサーバ自体がIDとパスワードを管理するというのは小規模なら可能だが、大規模の場合は認証基盤を使うのが一般的。
Q.プロキシ認証において、普段の会社のPCとかで毎回認証のポップアップが出ないのはなぜ？
A.統合Windows認証（IWA:Integrated Windows Authentication）を使う。これによりPCにログインした時点でSSOを利用できるようになるため、プロキシを利用するたびにポップアップが表示されなくて済む。
なお、統合Windows認証の根幹となる技術はケルベロスによって支えられている。
Q.ケルベロス認証とは
A.一度のログインで色んなサービスを使えるようにする技術（SSO）のこと。では、フローを見ながら理解していこう！
１．PC→AS（AuthenticationServer）
PCはASへ「ログインしたいです！」と伝える。
２．AS（AuthenticationServer）
ASはKDC（KeyDistributtionCenter）内にある窓口の一つで、認証を担当する。
暗号化データ（TGT（Ticket Granting Ticket）と共通鍵（＝Client-TGSセッション鍵）をクライアントに返す。その際に使われる暗号化鍵はクライアントのパスワードから作られた鍵。
３．AS→PC
PCは暗号化データを自身のパスワードをベースにした鍵で復号する。これによりTGTと共通鍵（＝Client-TGSセッション鍵）を手に入れる。
４．PC→TGS（Ticket Granting Service）
PCは「このサービス（例えばファイルサーバなど）を使いたいのでチケットをください！」とTGSへ伝える。
TGTとオーセンティケーター（タイムスタンプ入りの証明書）をTGSに渡す。また、その際に公開領域（リクエスト内の暗号化されていない部分）にアクセスしたいサービスを指定する。
＊オーセンティケーターはASからもらった共通鍵で暗号化した状態で送付する。
５．TGS（Ticket Granting Service）→PC
①公開領域を確認する
公開領域内にアクセスしたい場所が記されているので、それを確認する
②TGTをKDCだけがもつ鍵で復号する。
その中にユーザとの共通鍵（＝Client-TGSセッション鍵）とユーザIDが入っている。それによって、「あ、このユーザIDは認証済みなんだ！」と認識できる。
③オーセンティケーターをClient-TGSセッション鍵で復号する。
その中にあるユーザIDやタイムスタンプを確認してTGTとの整合性を確認する
③ST（ServiceTicket）と共通鍵（＝Client-Serverセッション鍵）を配布する
Client-Serverセッション鍵はClient-TGSセッション鍵で暗号化されて渡す。
STはKDCとサービスサーバとの共通鍵（ServiceKey）で暗号化されている
６．TGS→PC
①PCは共通鍵を取り出す
共通鍵（Client-Serverセッション鍵）はClient-TGSセッション鍵で暗号化されているので、自身のClient-TGSセッション鍵で復号する
PCはサービスサーバーに対して、オーセンティケーターとSTを渡す
７．PC→サービスサーバ
①サービスサーバは、STを復号し中にあるユーザIDや共通鍵（Client-Serverセッション鍵）を取り出す。
＊STを復号するときはServiceKeyを使う
②オーセンティケーターをClient-Serverセッション鍵で復号し、STとの整合性を確認する
以上の手順が滞りなく実施されるとユーザのアクセスが許可されサービスの利用が開始される
８．2回目以降のアクセス
手順３にてPCには既にClient-TGSセッションキーがあるので、それを使ってオーセンティケーターを作成する。
移行の流れは同じ。
＊Client-TGSセッションキーの有効期限が切れると再度、ASに認証を要求する必要がある。
（２）①接続先ホスト名 ②接続先ポート番号
Request-URIを簡単にいうと、HTTPリクエストの１行目のこと。
例：CONNECTメソッドなら「CONNECT google.com:443 HTTP/1.1」が該当し、GETメソッドなら「GET /index.html HTTP/1.1」が該当する。要はどこにアクセスしたいかを表現する場所のことである。
で、ここからわかる情報は、「メソッド、宛先ホスト、ポート番号、HTTPプロトコル」である。なので、回答は接続先ホスト名と接続先ポート番号という風になる。
▼CONNECTメソッド
CONNECT google.com:443 HTTP/1.1
Host: google.com:443
▼GETメソッド（プロキシあり）
＊プロキシ経由の場合は絶対パスの指定が必須
GET http://example.com/index.html HTTP/1.1
Host: example.com
▼GETメソッド（プロキシなし）
＊プロキシを経由しない場合はファイルのパスだけでよい
GET /index.html HTTP/1.1
Host: example.comp.7 内部DNSサーバの必要性
以下の構成において、内部DNSサーバはなぜ必要か。それを見ていこう！
答えはシンプルで、VPN接続後のタブレット端末が販売管理サーバと通信したい際に使われる。URLはわかっても実際のIPアドレスが分からないと通信できないので、それを解消するために内部DNSサーバを利用する。
p.7 LTE回線
LTE（LongTermEvolution）は3GPP（Third Generation Partnership Project）という世界中の通信会社やメーカーが集まる組織が作った、数万ページに及ぶ「規格（ルールブック）」のこと。そして、その規格に則った回線をLTE回線と呼ぶ。以下に特徴をまとめる。
・SIMカードを使った認証：
多くの場合、LTE回線では認証を必要とする。なぜなら誰彼構わず通信を提供していたらビジネスにならない。また、移動通信（ハンドオーバー）やトラフィック制御、課金管理などを提供するには利用者を識別する必要があるため認証を実施する。
・オールIPによる通信：
音声通話もデータ通信もすべてIPで通信する。一昔前は音声通話は電話用の回路へ送出され、データ通信はデータ通信用の回路へ送出されていた。このように用途によって回路が分かれていたが、LTEはすべてIPで包んで通信させる方式を採用した。
・APN（Access Point Name）による接続先の選択：
SIMカードの契約情報に基づき、インターネット網や特定の企業向け閉域網など、適切なネットワーク（ゲートウェイ）へ通信を振り分ける。
もし、これがないとモバイルのコアネットワークから外のほかのネットワーク（インターネット、会社VPNなど）へ通信できなくなる。
このような特徴をLTEは持つ。
Q.LTE回線におけるインターネットアクセスのフローは？
A.LTE回線が具体的にどのようなものかイメージするためにはフロー理解が役立つ。なので、見ていこう！
１．端末：
送信データに宛先IPを付与
２．無線アクセス：
LTE/5Gの電波に乗せて、基地局（base station）へ運ぶ
３．コアネットワーク：
基地局経由でコアネットワークに到着
４．ゲートウェイ（APN）：
端末のAPN設定に基づき、適切なゲートウェイへ振り分け。ここで、NAPT変換やGTPトンネル（モバイル回線）の終端の役割を担う。
＊APNはどのゲートウェイを使うかを示す名前（識別子）
５．NAPT変換：
ゲートウェイで端末のプライベートIPアドレスをキャリアのグローバルIPアドレスに変換
＊ここで言うプライベートIPアドレスは、端末が「LTEで通信したい！」とキャリアに伝えてからキャリアのゲートウェイが端末に割り振るIPアドレスのことを指す。
６．インターネット接続：
NAPT変換されたパケットはキャリア網のバックボーンネットワークを経由して、インターネット（AS）との境界ルータへ渡される。で、ここから先はBGPを使い複数のASを経由して宛先までホップする
Q.GTP（GPRS Tunneling Protocol）トンネルの作成フロー
では、GTPトンネルの作成フローを見ていこう！
１．クライアントが接続要求
SIM情報を載せて基地局へ投げる。
＊この時点ではまだ、IPアドレスの払い出しやGTPトンネルは張られていない
２．基地局へ届く
基地局へ届くと管理装置であるMMEに処理を投げる
３．MME（Mobility Management Entity）
MMEと呼ばれる管理装置は、SIM情報のAPNなどからゲートウェイを特定し、当該ゲートウェイに「ユーザにプライベートIPアドレスを払い出せ！基地局とGTPトンネルを張れ」と処理を投げる。
また、基地局に対しては、「ユーザと無線ベアラ開通させろ！」と処理を投げる。
４．ゲートウェイ
GTPトンネルの開通：
・基地局からゲートウェイの間にGTPトンネルを開通させる。
・TEID（Tunnel Endpoint Identifier）という識別子をトンネルに付与することで「誰のパケット」かを明示する
IPアドレスの払い出し：
・ユーザにプライベートIPアドレスの払い出しをする
５．ゲートウェイ→MMEへ
GTPトンネルやIP払い出しの準備ができたらその情報をMMEに送る。
６．MME→基地局
無線ベアラの接続指示を与える。
５の情報を基地局に伝える。
７．基地局→ユーザ
無線ベアラを確立する。
以上が大まかな流れだよ。ユーザ⇔基地局 と 基地局⇔ゲートウェイ のように２つの接続種類を使うことでユーザが移動して基地局が変わったとしても基地局⇔ゲートウェイで使われているトンネル情報を移動先に張り替えるだけで維持できるので、ハンドオーバーをスムーズに実現できるようになる。
p.8 WEP,WPA,WPA2
WEP,WPA,WPA2は無線LANのセキュリティ規格。では、それぞれ順番にみていこう！
Q.WEP（WiredEquivalentPrivacy）:
WEPは、データと謎の鍵（キーストリーム）を合体させて暗号化する方法であるストリーム暗号方式を採用している。
＊キーストリームを作るための材料がWEPキー（パスワード、共有鍵）とIV
＃暗号化
データ XOR キーストリーム = 暗号文
＃復号化
暗号文 XOR キーストリーム = データ
#キーストリーム
キーストリーム = RC4（WEPキー,IV）
▼暗号化手順
１．WEPキー（パスワード）とIVをまぜる
＊IVはパケットごとに変化する
２．２で混ぜた値をRC4という暗号アルゴリズムに入れてデータと同じ長さのキーストリームを生成する
３．キーストリームとデータをXORして暗号文を生成
４．３でできたデータとIV（平文）をセットして空中に飛ばす
▼弱点
弱点１：IVが短すぎる
WEPではIVが24ビットしかないので、2^24は1677万しかパターンがない。これは現在の高速Wi-Fi通信において、あっという間に重複してしまう数値。結果として同じキーストリーム（IV＋パスワード）を使いまわすことになり、XORの法則で解析されてしまう。
このような式（暗号文A XOR 暗号文B = データB XOR データA）になれば、もしデータBかAが推測できるならばもう一方のデータ必然的に導出されてしまう。
###########################
#
# もし、キーストリームが重複すると
#
##########################
XORのルール
①順番はどうでもいい
②同じ値同士のXORは０になる
１．重複した２つのデータを準備
暗号文A = データA XOR キーストリーム
暗号文B = データB XOR キーストリーム
２．ルール①より式を変換
キーストリーム = 暗号文A XOR データA
キーストリーム = 暗号文B XOR データB
３．等価関係
暗号文A XOR データA = 暗号文B XOR データB
４．ルール①より暗号文Bを左辺へ、データAを右辺へ移動させる
暗号文A XOR 暗号文B = データB XOR データA弱点２：RC4の脆弱性
RC4が使われるタイミングはキーストリームを生成するとき。キーストリーム = RC4（WEPキー,IV）。しかし、RC4には元のパスワードの統計的情報が生成したキーストリームの先頭付近に漏れ出てしまう特性がある。これを統計処理されると元のパスワードが導出されてしまう。
以上の理由からWEPの使用は現在では非推奨とされている。
Q.WPA（Wi-Fi Protected Access）：
WEPという脆弱性の塊を、ハードウェアの変更をすることなく補強し延命するための規格。
▼改善点
改善点１：IVの拡大
WEPは24ビット（約1677万）だったがWPAでは48ビット（約281兆）に拡大された。これは重複して使われることがほぼない。
改善点２：パラメータの増加
WEPはキーストリームのパラメータが「WEPキー＋IV」の２つだけだった。しかしWPAでは、「WEPキー＋IV＋送信元MACアドレス＋パケット番号」の４つのパラメータを使っている。
＊WPAにおけるWEPキーは４way handshakeによって生成されたTKである。
キーストリーム = RC4（WEPキー＋IV＋送信元MACアドレス＋パケット番号）改善点３：４ウェイハンドシェイクの導入
使用するパラメータは
・Aノンス（APのノンス）
・Cノンス（クライアントのノンス）
・AMAC（APのMACアドレス）
・ＣMAC（クライアントのMACアドレス）
・PMK（事前共有鍵）
▼４way hand-shakeの流れ
１．①AP→クライアントにAノンスを送る
２．クライアントがPTKの生成
クライアントは「PMK＋Aノンス＋Cノンス＋AMAC＋CMAC」を導出関数に入れてPTKを生成する。
＊導出関数はPRF (Pseudo-Random Function：擬似乱数関数) または KDF (Key Derivation Function：鍵導出関数)と呼ばれる。RC4やAESとは全く別で、「入力した情報をめちゃくちゃに混ぜて規則性のないランダムな値を生成する」ための数学的な仕組み
３．PTKから鍵を取り出す
PTKにはKCK、KEK、TKと呼ばれる鍵が内在されている。
KCK：MICを生成するための鍵
KEK：GTKを暗号化するための鍵
TK：通常のデータを暗号化するための鍵
４．②クライアント→APにCノンスとMICを送る
クライアントは自身のノンスと先ほど生成したPTKのKCKから生成したMICを送る。
＊MIC（MessageIntegrityCheck）
５．APが正当性の確認
APを受け取ったCノンスなどの情報を使いPTKを生成する。また、そのPTKのKCKからMICを生成し、そのMICがクライアントから送られてきたMICと一致したら正当性も保証される。
６．③AP→クライアントにGTKの配布
GTKと呼ばれるグループ鍵をAPが生成する。それをKEKで暗号化（RC4を使う）してクライアントに配る。また、この際もMICを生成して正当性の確認ができるようにする。
７．④クライアント→APにACKの送信
クライアントが受け取ったMICの正当性を確認したり、GTKをRC4で復号できたらACK（確認応答）をAPに返して４way handshakeの完了となる。
以上、４way handshakeの手順である。
ちなみに実際のデータを送るときは「TK＋送信元MACアドレス＋IV＋パケット番号＋実データ」の５つを使い暗号化する
Q.WPA2（Wi-Fi Protected Access 2）：
WPAではRC4ベースの暗号化方式を使っていた。それだと脆弱性があるので、AESベースのCCMP暗号化方式を採用したのがWPA2である。
また、整合性チェック（MIC）の方式も変わった。WPAでは、暗号化したデータの後ろにMICを張り付けていた。一方WPA2では、MICも暗号化対象とすることで、改ざんされたら必ず気づけるようになった。これを専門用語でAEAD(Authenticated Encryption with Associated Data：認証付き暗号)と呼ぶ。
Q.AEAD(Authenticated Encryption with Associated Data：認証付き暗号)
WPAの時代は、暗号化パケットの後ろにMICをつけていた。いわば、暗号化と認証が別々のプロセスとして扱われていた。そのため、どこかが間違っていると、AP側は「あ、このパットは暗号化部分がミスってるよ！」や「いや、認証部分がミスってるよ」などと具体的なエラーを返すことができた。これを利用して攻撃者はうまく改ざんできる方法を調整していた。（このような仕組みはパディングオラクル攻撃と呼ばれている）
しかし、WPA2では、認証と暗号化を同じプロセス内で実施するAEAD方式を採用した。これにより、どこかが間違っていたとしても、AP側は暗号化処理なのか認証処理のどっちがまちがっているのか判断できない。そのため特にエラーメッセージを出すことなくドロップされる。これをされると攻撃者はヒントを得られないので攻撃を進めることが難しくなる。
