(57)【特許請求の範囲】
【請求項１】
AP（アクセスポイント）と、
前記APに帰属するSTA（子機）と、
前記APが前記STAからの検証要求を受信した場合に、検証を行う検証サーバと、
正規の前記APの情報が登録されたデータベースと、を備え、
前記APは、
前記STAを帰属する前に、前記STAが本発明技術に対応する旨を前記STAから伝えられた場合に、信頼できる認証局の署名がされた検証サーバ証明書を前記STAに送信し、
前記STAからの検証要求を受信した場合に、その内容を検証サーバへ送信し、前記検証サーバからの検証応答をセキュアな経路を使用して受信し、
前記検証応答を受信した場合に、前記STAとの無線LANの暗号方式として、前記検証応答の中に含まれる乱数を種とした暗号通信を行う方式を利用して通信を行い、
前記検証応答を受信した場合に、前記検証応答の中に含まれる乱数を種とした共有鍵を生成し、前記検証応答内容を暗号化して前記STAに送信し、
前記STAは、
前記APに帰属する前に、対応するSTAである旨を前記APに伝え、前記APからの前記検証サーバ証明書を受信し、前記検証サーバ証明書に信頼できる認証局の署名がなされているかを検証し、
前記検証サーバ証明書が信頼できる場合に、検証要求として接続先の情報および乱数を、前記検証サーバ証明書に付属の公開鍵で暗号化して前記APへ送信し、
前記APから検証応答を受信した場合に、前記乱数を種とした共通鍵を生成し、前記検証応答内容を復号化し、その内容として検証の合否および前記乱数が含まれているかを確認し、
検証内容が合格であり、かつ前記乱数が確認できた場合に、前記APとの無線LANの暗号方式として、前記乱数を種とした暗号通信を行う方式を利用して通信を行い、
前記検証サーバは、
前記APから前記検証要求を受信した場合に、前記信頼できる認証局の署名がされた前記検証サーバ証明書に付属の公開鍵の対となる秘密鍵で内容を復号化し、前記検証要求に含まれる情報が、正規APの情報が登録されたデータベースにおいて一致するレコードが存在するか否かにより、合否判定を行い、
前記合否判定の結果と、前記検証要求に含まれる乱数を、検証応答としてセキュアな経路を使用して前記検証要求を送信してきたAPに送信する、
通信システム。
【請求項２】
前記データベースは、前記検証サーバ内に格納されている、
請求項１に記載の通信システム。
【請求項３】
前記STAが、検証要求として、前記検証サーバ証明書に付属の公開鍵で暗号化して前記APに送信する接続先の情報には、接続先のESSID，BSSID，チャネル番号を含み、
前記検証サーバは、合否判定を行う際に、前記検証要求に含まれるESSID, BSSID, チャネル番号の全てが、正規APの情報が登録されたデータベースにおいて一致するレコードが存在するか否かにより合否判定を行う、
請求項１又は２に記載の通信システム。
【請求項４】
前記信頼できる認証局の署名に換えて、前記APを提供するものが署名を行うとともに、あらかじめ前記STAにルート証明書を格納しておき、
前記STAは、前記APからの前記検証サーバ証明書を受信し、前記検証サーバ証明書に署名がなされているかを検証する、
請求項１乃至３のいずれか１項に記載の通信システム。
【請求項５】
AP（アクセスポイント）は、前記APがSTA（子機）を帰属する前に、前記STAが本発明技術に対応する旨を前記STAから伝えられた場合に、信頼できる認証局の署名がされた検証サーバ証明書を前記STAに送信し、
前記APは、前記STAからの検証要求を受信した場合に、その内容を検証サーバへ送信し、前記検証サーバからの検証応答をセキュアな経路を使用して受信し、
前記APは、前記検証応答を受信した場合に、前記STAとの無線LANの暗号方式として、前記検証応答の中に含まれる乱数を種とした暗号通信を行う方式を利用して通信を行い、
前記APは、前記検証応答を受信した場合に、前記検証応答の中に含まれる乱数を種とした共有鍵を生成し、前記検証応答内容を暗号化して前記STAに送信し、
前記STAは、前記APに帰属する前に、対応するSTAである旨を前記APに伝え、前記APからの前記検証サーバ証明書を受信し、前記検証サーバ証明書に信頼できる認証局の署名がなされているかを検証し、
前記STAは、前記検証サーバ証明書が信頼できる場合に、検証要求として接続先の情報および乱数を、前記検証サーバ証明書に付属の公開鍵で暗号化して前記APへ送信し、
前記STAは、前記APから検証応答を受信した場合に、前記乱数を種とした共通鍵を生成し、前記検証応答内容を復号化し、その内容として検証の合否および前記乱数が含まれているかを確認し、
前記STAは、検証内容が合格であり、かつ前記乱数が確認できた場合に、前記APとの無線LANの暗号方式として、前記乱数を種とした暗号通信を行う方式を利用して通信を行い、
前記検証サーバは、前記APから前記検証要求を受信した場合に、前記信頼できる認証局の署名がされた前記検証サーバ証明書に付属の公開鍵の対となる秘密鍵で内容を復号化し、前記検証要求に含まれる情報が、正規APの情報が登録されたデータベースにおいて一致するレコードが存在するか否かにより、合否判定を行い、
前記検証サーバは、前記合否判定の結果と、前記検証要求に含まれる乱数を、検証応答としてセキュアな経路を使用して前記検証要求を送信してきたAPに送信する、
通信経路確立方法。
【請求項６】
前記データベースは前記検証サーバ内に格納されており、前記検証サーバが前記APから前記検証要求を受信した場合には、前記検証サーバ内に格納された前記データベースに記憶されたレコードを用いて合否判定を行う、
請求項５に記載の通信経路確立方法。
【請求項７】
前記STAが、検証要求として、前記検証サーバ証明書に付属の公開鍵で暗号化して前記APに送信する接続先の情報には、接続先のESSID，BSSID，チャネル番号を含み、
前記検証サーバは、合否判定を行う際に、前記検証要求に含まれるESSID, BSSID, チャネル番号の全てが、正規APの情報が登録されたデータベースにおいて一致するレコードが存在するか否かにより合否判定を行う、
請求項５又は６に記載の通信経路確立方法。
【請求項８】
AP（アクセスポイント）は、前記APがSTA（子機）を帰属する前に、前記STAが本発明技術に対応する旨を前記STAから伝えられた場合に、信頼できる認証局の署名がされた検証サーバ証明書を前記STAに送信し、
前記APは、前記STAからの検証要求を受信した場合に、その内容を検証サーバへ送信し、前記検証サーバからの検証応答をセキュアな経路を使用して受信し、
前記APは、前記検証応答を受信した場合に、前記STAとの無線LANの暗号方式として、前記検証応答の中に含まれる乱数を種とした暗号通信を行う方式を利用して通信を行い、
前記APは、前記検証応答を受信した場合に、前記検証応答の中に含まれる乱数を種とした共有鍵を生成し、前記検証応答内容を暗号化して前記STAに送信する、
前記APに記憶された通信経路確立プログラム。
【請求項９】
STA（子機）は、AP（アクセスポイント）に帰属する前に、本発明技術に対応するSTAである旨を前記APに伝え、前記APからの検証サーバ証明書を受信し、前記検証サーバ証明書に信頼できる認証局の署名がなされているかを検証し、
前記STAは、前記検証サーバ証明書が信頼できる場合に、検証要求として接続先の情報および乱数を、前記検証サーバ証明書に付属の公開鍵で暗号化して前記APへ送信し、
前記STAは、前記APから検証応答を受信した場合に、前記乱数を種とした共通鍵を生成し、前記検証応答内容を復号化し、その内容として検証の合否および前記乱数が含まれているかを確認し、
前記STAは、検証内容が合格であり、かつ前記乱数が確認できた場合に、前記APとの無線LANの暗号方式として、前記乱数を種とした暗号通信を行う方式を利用して通信を行う、
前記STAに記憶された通信経路確立プログラム。
【請求項１０】
検証サーバは、AP（アクセスポイント）から検証要求を受信した場合に、信頼できる認証局の署名がされた検証サーバ証明書に付属の公開鍵の対となる秘密鍵で内容を復号化し、前記検証要求に含まれる情報が、正規APの情報が登録されたデータベースにおいて一致するレコードが存在するか否かにより、合否判定を行い、
前記検証サーバは、前記合否判定の結果と、前記検証要求に含まれる乱数を、検証応答としてセキュアな経路を使用して前記検証要求を送信してきたAPに送信する、
前記検証サーバに記憶された通信経路確立プログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、アクセスポイント（以下、AP）を管理可能な状況下で、子機（以下、ステーション又はSTA）が管理者の指定した正規のAP以外に帰属することを防ぐ、無線LAN（Local Area Network）機器、および周辺機器を用いた通信システム、及び通信経路確立方法、および経路確立プログラムに関する。
【背景技術】
【０００２】
スマートフォンに代表される携帯通信端末の普及と配信されるコンテンツの変化に伴って携帯通信網におけるデータ通信量は爆発的に増加してきており、携帯通信端末のデータトラフィックを携帯通信網から各地に設置される公衆無線LANへ移すこと（オフロード）が命題となっている。
【０００３】
そのため公衆無線LANが利用できるエリアは増加してきているが、公衆無線LANはその誰でも利用できるという特性上セキュリティ面での課題があり、ユーザは利用を控えたり、あるいは利用した場合にサイバー攻撃を受けてしまう恐れがある。
【０００４】
現在、5Gなどの新しい携帯通信技術も登場してきているが、今後も公衆無線LANへのオフロードが望まれることには変わりなく、公衆無線LANの普及が望まれている。
【先行技術文献】
【特許文献】
【０００５】
【特許文献１】特表2014-527762号公報
【発明の概要】
【発明が解決しようとする課題】
【０００６】
公衆無線LANは便利であるが、セキュリティ面での問題がある。具体的には、ユーザの利便性を考えるとパスワード入力なしで（すなわちOpen認証で）利用可能なものが望ましいが、現在一般に普及している無線LANの暗号モードでは、Open認証の場合は通信の暗号化すらしていない。この場合、悪意を持った利用者（以降攻撃者と呼ぶ）は無線LANパケットをキャプチャするだけで他者の通信内容を盗聴できるため、極めて危険であるといえる。
【０００７】
これは、最新のセキュリティ規格である WPA3 の OWE(Opportunistic Wireless Encryption) では Open認証でありながら暗号化通信を行うことが可能であるのでこれを利用するか、WPA2でも非Open認証な暗号モードであれば暗号化通信を行うのでそれを利用すると、攻撃者はキャプチャするだけでは通信内容はわからず、盗聴のリスクを下げることができる。しかしながら、攻撃者が盗聴するための手法はパケットキャプチャだけではない。
【０００８】
例えば、攻撃手法の一つには、中間者(Man-in-the-Middle)攻撃（以降MitMと呼ぶ）という手法がある。これは無線LANに限った攻撃手法ではないが、無線LANでMitMを行う場合には次のような方法を行う。
【０００９】
まず、攻撃者は正規のAP（以降Real APと呼ぶ）に一般の利用者と同じように自身の装置を帰属させる。続いて、STAとしての動作は維持しつつ、正規のAPを真似したAPを立てる（以降Rogue APと呼ぶ）。そして、正規のユーザを騙し、攻撃対象であるユーザのSTAを、Rogue APに帰属させる。これにより、騙されたユーザは一見Real APに帰属したように感じるが、実際にはRogue APに帰属しており、Rogue APを経由してReal APへ通信することになる。故に、ユーザの通信データは全て攻撃者の装置上で盗聴や改ざんが可能となる。
【００１０】
このMitMにおいて、STAの無線LANとしての通信経路は一度Rogue APで終端しているため、無線LANの暗号化はRogue AP上で一度復号化される。したがって、MitMされている状況では無線LAN通信の暗号化は盗聴や改ざんの防止策としての意味をなさない。また、MitMは攻撃者の装置をReal APに帰属させる必要があるため、MitMを防止するには攻撃者の装置をReal APに帰属させなくする、すなわちReal APに認証を設けることは良い策である。しかしながら、公衆無線LANの場合はその特性上Open認証であったり、非Open認証であっても簡単にパスワードを取得できるため MitMをガードすることは実質できていないのが現状である。つまり、現状の公衆無線LANにはMitMをガードする手がなく、セキュリティ面で問題がある。
【００１１】
特許文献１では、以下のようにして疑わしいAPへの接続をガードしている。まず、日常的に（任意の）STAは（任意の）APに帰属している際に、帰属先APの評判となるデータを評価サーバに送信しておく。評判とは、例えば「信頼できるwebサイトとのSSL証明書検証に失敗した」といったものであり、この例の場合は悪評である。またAP自身も、自身の評判となるデータを評価サーバへ送信しておく。この場合の評判とは、例えば自身に帰属しているSTAの台数であり、この場合帰属台数が多いほど好評となる。そして、あるSTAがあるAPへ接続しようとする際に、まず評価サーバへ評判を問い合わせる。評価サーバは、蓄積された評価データをもとに機械学習で導いた法則にしたがってAPの評判値をSTAに返答する。そしてSTAは得られた評判値によって、APへの接続を続行するかしないかを決定する。このようにすることで評判の悪いAPへの接続をガードすることとしている。
【００１２】
この特許文献１で示された方法は、不特定多数のAPについて、AP管理者の手を煩わせずとも一般論としてのAPの良し悪しを提供することができる点で優れているが、いくつかの問題点が存在する。1点目は、評価対象のAPに対する評判となるデータが一定量蓄積されていないと、信頼できる判断ができないという点である。例えば新規開店した店舗で提供される公衆無線LANであったり、既存の公衆無線LANでも老朽化等でAPを交換した際には、そのAPに対する評判となるデータがほとんどない状態になるため、信頼できる判断ができなくなる。2点目は、エンドユーザからの情報をベースにAPを判断しているため、攻撃者が偽の評判となるデータを評価サーバへ送信することで、偽の評判を作り上げることが可能な点である。それにより例えばReal APの評判を下げたり、Rogue APの評判を上げることが可能である。つまり、あくまでも特許文献１には「疑わしいAPの検出」する技術が開示されているのであって、APを正確に判断してMitMをガードする技術が開示されているわけではない。
【００１３】
ここで、公衆無線LANの利用者は、自身が接続しようとしているAPが、新規に設置されたものなのかどうかを気にかけることなく利用する。また、利用者は、確実に正規のAPにのみ接続できるべきであって、APが疑わしいかどうかの情報が提供されてもその情報自体が偽の評判で作られた可能性があるのでは、MitMをガードするという点では意味をなさない。このように特許文献１に開示された技術では、上述した公衆無線LANにおけるMitMをガードする手がないという課題は解決できておらず、この課題は依然残されている。
【課題を解決するための手段】
【００１４】
本開示の目的は、APと、前記APに帰属するSTAと、前記APが前記STAからの検証要求を受信した場合に、検証を行う検証サーバと、正規の前記APの情報が登録されたデータベースと、を備え、前記APは、前記STAを帰属する前に、対応するAPである旨を前記STAから伝えられた場合に、信頼できる認証局の署名がされた検証サーバ証明書を前記STAに送信し、前記STAからの検証要求を受信した場合に、その内容を検証サーバへ送信し、前記検証サーバからの検証応答をセキュアな経路を使用して受信し、前記検証応答を受信した場合に、前記STAとの無線LANの暗号方式として、前記検証応答の中に含まれる乱数を種とした暗号通信を行う方式を利用して通信を行い、前記検証応答を受信した場合に、前記検証応答の中に含まれる乱数を種とした共有鍵を生成し、前記検証応答内容を暗号化して前記STAに送信し、前記STAは、前記APに帰属する前に、対応するSTAである旨を前記APに伝え、前記APからの前記検証サーバ証明書を受信し、前記検証サーバ証明書に信頼できる認証局の署名がなされているかを検証し、前記検証サーバ証明書が信頼できる場合に、検証要求として接続先の情報および乱数を、前記検証サーバ証明書に付属の公開鍵で暗号化して前記APへ送信し、前記APから検証応答を受信した場合に、前記乱数を種とした共通鍵を生成し、前記検証応答内容を復号化し、その内容として検証の合否および前記乱数が含まれているかを確認し、検証内容が合格であり、かつ前記乱数が確認できた場合に、前記APとの無線LANの暗号方式として、前記乱数を種とした暗号通信を行う方式を利用して通信を行い、前記検証サーバは、前記APから前記検証要求を受信した場合に、前記信頼できる認証局の署名がされた前記検証サーバ証明書に付属の公開鍵の対となる秘密鍵で内容を復号化し、前記検証要求に含まれる情報が、正規APの情報が登録されたデータベースにおいて一致するレコードが存在するか否かにより、合否判定を行い、前記合否判定の結果と、前記検証要求に含まれる乱数を、検証応答としてセキュアな経路を使用して前記検証要求を送信してきたAPに送信する、通信システムを提供することにある。
【００１５】
また、本開示の目的は、APは、前記APがSTAを帰属する前に、対応するAPである旨を前記STAから伝えられた場合に、信頼できる認証局の署名がされた検証サーバ証明書を前記STAに送信し、前記APは、前記STAからの検証要求を受信した場合に、その内容を検証サーバへ送信し、前記検証サーバからの検証応答をセキュアな経路を使用して受信し、前記APは、前記検証応答を受信した場合に、前記STAとの無線LANの暗号方式として、前記検証応答の中に含まれる乱数を種とした暗号通信を行う方式を利用して通信を行い、前記APは、前記検証応答を受信した場合に、前記検証応答の中に含まれる乱数を種とした共有鍵を生成し、前記検証応答内容を暗号化して前記STAに送信し、前記STAは、前記APに帰属する前に、対応するSTAである旨を前記APに伝え、前記APからの前記検証サーバ証明書を受信し、前記検証サーバ証明書に信頼できる認証局の署名がなされているかを検証し、前記STAは、前記検証サーバ証明書が信頼できる場合に、検証要求として接続先の情報および乱数を、前記検証サーバ証明書に付属の公開鍵で暗号化して前記APへ送信し、前記STAは、前記APから検証応答を受信した場合に、前記乱数を種とした共通鍵を生成し、前記検証応答内容を復号化し、その内容として検証の合否および前記乱数が含まれているかを確認し、前記STAは、検証内容が合格であり、かつ前記乱数が確認できた場合に、前記APとの無線LANの暗号方式として、前記乱数を種とした暗号通信を行う方式を利用して通信を行い、前記検証サーバは、前記APから前記検証要求を受信した場合に、前記信頼できる認証局の署名がされた前記検証サーバ証明書に付属の公開鍵の対となる秘密鍵で内容を復号化し、前記検証要求に含まれる情報が、正規APの情報が登録されたデータベースにおいて一致するレコードが存在するか否かにより、合否判定を行い、前記検証サーバは、前記合否判定の結果と、前記検証要求に含まれる乱数を、検証応答としてセキュアな経路を使用して前記検証要求を送信してきたAPに送信する、通信経路確立方法を提供することにある。
【００１６】
また、本開示の目的は、AP（アクセスポイント）は、前記APがSTA（子機）を帰属する前に、対応するAPである旨を前記STAから伝えられた場合に、信頼できる認証局の署名がされた検証サーバ証明書を前記STAに送信し、前記APは、前記STAからの検証要求を受信した場合に、その内容を検証サーバへ送信し、前記検証サーバからの検証応答をセキュアな経路を使用して受信し、前記APは、前記検証応答を受信した場合に、前記STAとの無線LANの暗号方式として、前記検証応答の中に含まれる乱数を種とした暗号通信を行う方式を利用して通信を行い、前記APは、前記検証応答を受信した場合に、前記検証応答の中に含まれる乱数を種とした共有鍵を生成し、前記検証応答内容を暗号化して前記STAに送信する、前記APに記憶された通信経路確立プログラムを提供することにある。
【００１７】
また、本開示の目的は、STA（子機）は、AP（アクセスポイント）に帰属する前に、対応するSTAである旨を前記APに伝え、前記APからの検証サーバ証明書を受信し、前記検証サーバ証明書に信頼できる認証局の署名がなされているかを検証し、前記STAは、前記検証サーバ証明書が信頼できる場合に、検証要求として接続先の情報および乱数を、前記検証サーバ証明書に付属の公開鍵で暗号化して前記APへ送信し、前記STAは、前記APから検証応答を受信した場合に、前記乱数を種とした共通鍵を生成し、前記検証応答内容を復号化し、その内容として検証の合否および前記乱数が含まれているかを確認し、前記STAは、検証内容が合格であり、かつ前記乱数が確認できた場合に、前記APとの無線LANの暗号方式として、前記乱数を種とした暗号通信を行う方式を利用して通信を行う、前記STAに記憶された通信経路確立プログラムを提供することにある。
【００１８】
また、本開示の目的は、検証サーバは、AP（アクセスポイント）から検証要求を受信した場合に、信頼できる認証局の署名がされた検証サーバ証明書に付属の公開鍵の対となる秘密鍵で内容を復号化し、前記検証要求に含まれる情報が、正規APの情報が登録されたデータベースにおいて一致するレコードが存在するか否かにより、合否判定を行い、前記検証サーバは、前記合否判定の結果と、前記検証要求に含まれる乱数を、検証応答としてセキュアな経路を使用して前記検証要求を送信してきたAPに送信する、前記検証サーバに記憶された通信経路確立プログラムを提供することにある。
【発明の効果】
【００１９】
管理者が正規のAPを管理できる状況において、攻撃者に偽のAPを立てられた場合でも、STAは正規のAPにのみ帰属可能となる。
【図面の簡単な説明】
【００２０】
【図１】実施の形態１にかかる無線LAN環境の構成図である。
【図２】実施の形態１にかかる情報の送受信を模式的に示した図である。
【図３】実施の形態１にかかるSTAの動作フローの一例を示した図である。
【図４】実施の形態１にかかるReal APの動作フローの一例を示した図である。
【図５】実施の形態１にかかる検証サーバの動作フローの一例を示した図である。
【図６】実施の形態１にかかるReal APとRogue APを立てた構成図である。
【図７】実施の形態１にかかる電波状態の一例を示した図である。
【図８】実施の形態１にかかる攻撃者がRogue APのほかに偽の検証サーバも用意した状態の構成図である。
【図９】実施の形態１にかかる具体的な無線LAN環境の一例を示す構成図である。
【図１０】実施の形態１にかかるAPの主要な設定項目を示す図である。
【図１１】実施の形態１にかかる検証サーバのデータベースに記録されている内容の一例を示す図である。
【図１２】実施の形態１にかかる偽の検証サーバのデータベースに記録されている内容の一例を示す図である。
【発明を実施するための形態】
【００２１】
実施の形態１
以下、図面を参照して本発明の実施の形態について説明する。図１に本発明の構成図を示す。検証サーバ1-1は公衆無線LANを提供するAPを設置する事業者が管理するものであり、Real AP1-3の管理を行うサーバである。なお、図１では検証サーバ1-1はインターネット1-2越しにReal AP1-3と接続されているが、必ずしもインターネットを経由する必要はない。Real AP1-3は検証サーバ1-1と同様に事業者が設置するものであり、これは正規のAPである。なお、図1は本発明の最小構成図であるためReal APは1台のみ描いているが、実際にはReal APは複数台存在することが想定される。STA1-4は公衆無線LANの利用者の子機端末である。
【００２２】
続いて、本発明での動作を、図２を用いて説明する。なお、図２において網掛けの経路は、その両端の装置の間でセキュアな経路が確立していることを示している。まず、公衆無線LANとしてのサービスを始める前にAPを管理する事業者は以下の準備を行っておく。
【００２３】
本発明において、検証サーバ2-1はSTA2-3との間でデジタル証明書を用いた公開鍵暗号方式の通信を行うため、あらかじめ信頼できる認証局のデジタル署名付きの証明書を取得しておく。（以降、この証明書を「検証サーバ証明書」と呼ぶ。）検証サーバ証明書には検証サーバ2-1が作成した公開鍵が含まれており、対となる秘密鍵は検証サーバ2-1にインストールしておく。一方、取得した検証サーバ証明書はReal AP2-2内に格納しておく。また、これとは別に検証サーバ2-1とReal AP2-2の間でセキュアな通信経路を確立しておく。この経路の確立方法はVPNやHTTPSなどの一般的な手法を用いてよい。そして、検証サーバ2-1上のデータベースに、正規のAPに関する情報としてReal AP2-2が提供するBSS(Basic Service Set)に関するESSID(Extended Service Set IDentifer)、BSSID(BSS IDentifer)、チャネル番号の3つの情報を登録しておく。以上を公共無線LANとしてのサービスを始める前に準備として行っておく。
【００２４】
続いて公衆無線LANとしてサービスを開始してからの動作について図２,３,４,５を用いて説明する。図３,４,５はそれぞれSTA2-3,Real AP2-2,検証サーバ2-1の処理に関するフローチャートである。また、Real AP2-2やSTA2-3の基本的な動作は一般的な無線LAN機器の動作に準ずるため、ここでは本発明に関連する部分のみ説明する。
【００２５】
まず、STA2-3は無線LANの接続処理を始める前に、一般的なSTAの動作としてAPが存在するか確認するための存在通知要求を送信するが、この存在通知要求を送る際に、本発明技術に対応していることを示すデータを合わせて送信し（2-4, 3-1）、一定時間の間APからの存在通知応答を待つ(3-2)。
【００２６】
Real AP2-2は存在通知要求を受信すると（4-1）、STA2-3が本発明技術に対応しているかを確認する（4-2）。本発明技術に対応しているReal AP2-2では、本発明技術に対応していないSTAの帰属は認めていないため、もしSTA2-3が本発明技術に対応していない場合はこれ以降の処理は行われない（4-4）。
【００２７】
STA2-3が本発明技術に対応している場合は(4-3)、本発明技術に対応していることを示すデータと検証サーバ証明書を付属した存在通知応答をSTA2-3に送信する（2-5,4-5）。一方、STA2-3は、もし一定時間内に存在通知応答が受信できなければ、それ以降の処理は行わない（3-4）。存在通知応答が受信できた場合には(3-3)、Real AP2-2が本発明技術に対応しているかどうかを検証する（3-5）。もしReal AP2-2が本発明技術に対応していない場合にはそれ以降の処理は行わない（3-7）。
【００２８】
Real AP2-2が本発明技術に対応している場合には(3-6)、受信した存在通知応答から検証サーバ証明書を取得し、信頼できる認証局の署名がなされているかを検証する（3-8）。そしてもし、検証できない（信頼できない）のであれば、これ以降の処理は行われない（3-10）。
【００２９】
信頼できる認証局の署名がなされていることを検証できた場合には（3-9）、STA2-3は乱数値rndを生成する（3-11）。そしてSTA2-3は、これから接続しようとしているBSSに関する、ESSID、BSSID、チャネル番号と、rndの4つの情報を、検証サーバ証明書に付属の公開鍵を用いて暗号化し、Real AP2-2に送信する（2-6, 3-12）。
【００３０】
なお、rndを除く3つの情報は Real AP2-2が発するBeaconなどを見れば容易に取得できる情報であり、一般的な動作としてSTAがAPへ帰属する際には必ず取得する情報である。Real AP2-2は先述の存在通知応答を送信後、一定期間STA2-3からのデータが受信されるのを待っており(4-6)、受信できた場合には(4-7)その内容を検証要求として検証サーバ2-1へ転送する（2-7, 4-9）。ここでもし、一定期間内に受信できなければ、これ以降の処理は行わない（4-8）。
【００３１】
検証サーバ2-1は、検証要求を受信すると（5-1）、まずそのデータ内容を自身の秘密鍵を使って復号化する。続いて得られたESSID, BSSID,チャネル番号の情報を、自身の管理するデータベースと照合し、３つの情報全てが一致するものが存在するか確認する（5-2）。
【００３２】
３つの情報全てが一致するものが存在する場合(5-3)、検証応答として合格である旨とrndを、あらかじめ用意しておいたセキュアな経路を通じてReal AP2-2へ送信する（2-8, 5-5）。一方、情報が一致するものが存在しない場合(5-4)は、不合格である旨とrndをセキュアな経路を通じてReal AP2-2へ送信する。
【００３３】
検証応答を受信した（4-10）Real AP2-2は、検証応答の中からrndを取得する（4-11）。そして検証応答の合否を確認し(4-12)、合格の場合は(4-13) STA2-3との無線LAN通信に、rndを種とする暗号通信を行うような暗号方式を設定する（4-15）。不合格の場合(4-14)は暗号方式を設定する処理は行わない。そして、検証応答の内容をrndを共通鍵として暗号化し、STA2-3へ送信する（2-9, 4-16）。
【００３４】
処理3-12でReal AP2-2に検証要求送信したSTA2-3は、その後、一定期間Real AP2-2からのデータが受信されるのを待っており(3-13)、受信できた場合(3-14)にはrndを共通鍵として復号化する（3-16）。ここでもし、一定期間内に受信できなければ、これ以降の処理は行われない（3-15）。
【００３５】
続いて、復号化した内容が、合格を示す旨であり、かつ、（復号化して得られた）rndの値が自身で生成した値と一致するかどうか検証する（3-17）。上記条件を満たさない場合（例えばそもそも復号化に失敗した場合や、不合格である場合や、rndの値が自身で生成した値と一致しない場合）はこれ以降の処理は行われない(3-19)。
【００３６】
一方、上記条件を満たす場合(3-18)には、Real AP2-2との無線LAN通信に、rndを鍵とする暗号通信を行うような暗号方式を設定する（3-20）。以降、STA2-3は一般的なSTAとしての帰属処理（Authenticationフレームの送信以降）を行い(3-21)、Real AP2-2もこれに対応する一般的なAPとしての帰属処理を行う（4-17）ことで、STA2-3はReal AP2-2への帰属が完了する。
【００３７】
以上の動作を行う事で、STAは正規のAPへの帰属が完了する。
【００３８】
次に、本発明の効果の理解を助けるために、偽のAP(=Rogue AP)が存在した場合にどのようにMitMがガードされるかについて説明する。
【００３９】
Rogue APは基本的にMACアドレスを含めて全てのパラメータをReal APと同じにするが、単純にすべてのパラメータが同じAPを立てると、Real APの通信と Rogue APの通信が混線し（無線LANパケットは電波なので物理的にはReal AP、Rogue APのどちらにも届き、BSSID(=MACアドレス)が同じであるならどちらのAPも受信する）、正常に通信ができない。そのため一部のパラメータを異なるものにするか、電波として物理的に混線しないよう何らかの対策を取ってRogue APを正規のAPと詐称することになる。
【００４０】
ケース１として、Real APとは別のチャネルでRogue APを立てる場合を考える。構成としては図６に示すものになる。
【００４１】
ケース１の場合、BSSIDは Real AP6-3と Rogue AP6-4で同じであるが、チャネルが異なるため、Real AP6-3と Rogue AP6-4の通信内容が混線することはない。通信経路としては STA6-5 ― Rogue AP6-4 ― Real AP6-3 ― 検証サーバ6-1となる。
【００４２】
もし、本発明技術を適用していない場合には、Rogue AP6-4が使用するチャネル番号を検証する処理がない為、STA6-5はRogue AP6-4に帰属してしまう。一方、本発明技術を適用している場合には、処理3-12にてSTA6-5はRogue AP6-4のチャネル番号を含めて（Rogue AP6-4、Real AP6-3を経由して）検証サーバ6-1へ検証要求を送信しており、検証サーバ6-1ではチャネル番号を含めた検証が行われる（5-2）ため、Real AP6-3と異なるチャネルを利用するRogue AP6-4は処理5-2にて不合格判定となる。
【００４３】
また、STA6-5の送信する検証要求(3-12)はSTA自身が生成する乱数rndを含んだ上で検証サーバ証明書の公開鍵で暗号化されているため、Rogue AP6-4がこのデータを改ざんすることはできない。（rndを知るためには一度復号化する必要があるが、Rogue AP6-3は秘密鍵を持たないので不可能。）仮にRogue AP6-4が本来の検証要求の代わりに偽の検証要求を送信したとしても、rndが不正確であるため処理3-17でガードされる。このようにケース1の場合はMitMは成功しない。
【００４４】
ケース２として、Real APと同一チャネルだがBSSIDが異なる場合を考える。BSSIDが異なるため、Real APと同じチャネルであっても混線することはない。ケース2の場合も、本発明技術ではチャネル番号と同時にBSSIDも検証しているため、ケース1と同じ理屈でMitMは成功しない。
【００４５】
ケース３として、チャネルやBSSIDを含め、全てのパラメータがReal AP同じRogue APを立てる場合を考える。構成としてはこれまでと同じ図６に示すものである。
【００４６】
先述の通り、全てのパラメータがReal APと同じであると通信が混線してしまうが、図７のような電波状況を作り出せば混線せずに通信することが可能となる。すなわち、Real AP7-1の電波7-4はRogue AP7-2には届くがSTA7-3には届かず、かつ、STA7-3の電波7-5はRogue AP7-2には届くがReal AP7-1には届かないという状況である。
【００４７】
この場合、検証サーバ6-1による検証では見抜けないが、検証サーバ6-1の検証応答は、セキュアな経路を使って確実にReal AP6-3に届けられ(2-7, 5-5)、Rogue AP6-4はその内容が届かないまたは復号化できないため、Rogue AP6-4がrndを知りえないことには変わりなく、処理3-17でガードされる。そのためケース3の場合もMitMは成功しない。
【００４８】
ケース４として攻撃者が、Rogue APのほかに偽の検証サーバも用意する場合を考える。この場合の構成は図８に示す通りである。
【００４９】
この場合の通信経路は STA8-6 ― Rogue AP8-5 ― 偽の検証サーバ8-4となる。ケース４の場合は処理3-8での検証サーバ証明書の検証処理でガードされる。その理由は、信頼できる認証局からの署名付きのデジタル証明書を入手するには、費用の負担と厳正な審査を受ける必要があるためである。つまり、攻撃者は信頼できる認証局からの署名付きのデジタル証明書を入手できないため、署名無し、あるいは自己署名の証明書を使うしかなく、処理3-8でガードされる。そのためケース４の場合もMitMは成功しない。
【００５０】
以上の通り、本発明技術はMitMに対して非常に高い堅牢性を有している。
【００５１】
次に、より具体的な実施例について説明する。実施例の構成図を図９に示す。
【００５２】
検証サーバ9-2、及びReal AP(A,B)9-3,9-4は、公衆無線LANサービスを行う事業者が用意し、設置したものである。STA9-5は公衆無線LANを利用するユーザの無線端末（ここではスマートフォンとする）であり、これを事業者が用意した正規のAPであるReal AP(A)9-3もしくはReal AP(B)9-4に帰属させること、およびRogue AP(A,B,C)9-6,9-7,9-8には帰属させないことが本発明の目的である。偽の検証サーバ9-9、Rogue AP(A,B,C)9-6, 9-7, 9-8は攻撃者が用意したものであり、攻撃者はSTA9-5をいずれかのRogue APに帰属させることを狙っている。
【００５３】
ここで、Rogue AP(A)9-6は、先に説明したケース1の場合のRogue APである。Rogue AP(B)9-7は先に説明したケース３の場合のRogue APである。Rogue AP(C)9-8は先に説明したケース４の場合のRogue APである。Rogue AP(A,B)9-6,9-7については子機としてReal AP(B)9-4に帰属済みである。
【００５４】
各APの主要な設定項目について図１０に示す。この例での公衆無線LANサービスは、"freewlan" というESSIDで提供されており、Real AP, Rogue APの全てにおいて、ESSIDは"freewlan"となっている。
【００５５】
BSSIDについては、Rogue AP(A,B)9-6,9-7は Real AP(B)9-4を詐称するので、Real AP(B)9-4と同じものとなる。Rogue AP(C)9-8は特定のReal APを詐称しているわけではないのでBSSIDは別の物で良い。チャネル番号については、Real AP(A)9-3とReal AP(B)9-4の間で合わせる必要はないため、異なっている。Rogue AP(A)9-6はReal AP(B)9-4との混線を避けるため、Real AP(B)9-4とは異なるチャネル番号となっている。一方Rogue AP(B)9-7は先に説明した通り、電波的に干渉しないようになっているため、Real AP(B)9-4と同じチャネル番号となっている。Rogue AP(C)9-8についてはBSSIDと同様でReal APに合わせる必要がないため別のチャネルとなっている。
【００５６】
検証サーバ証明書については2種類存在し、便宜上"A"と"B"という表記で示している。Aの証明書は検証サーバ9-2のものであり、信頼できる認証局の署名がされている。一方Bの証明書は偽の検証サーバ9-9のものであり、信頼できる認証局の署名はされていない。
【００５７】
次に、動作の説明を行う。
【００５８】
公衆無線LANサービスを行う事業者は、あらかじめ以下を行っておく。まず、検証サーバ証明書として、信頼できる認証局に依頼し、ITU-T X.509で規定される署名付きのデジタル証明書、および対応する秘密鍵を取得しておく。取得した検証サーバ証明書は、Real AP(A,B)9-3,9-4内に格納し、秘密鍵は検証サーバ9-2に格納しておく。また、これとは別に、検証サーバ9-2とReal AP(A,B)9-6,9-7のそれぞれの間でIPsecによるコネクションを確立しておく。加えて、検証サーバ9-2はIPsecで確立したコネクション以外の通信は行わないようFire Wall等を用いてブロックしておく。そして、検証サーバ9-2上のデータベースに、図１１のように正規のAPに関する情報としてReal AP(A,B)9-3, 9-4のESSID、BSSID,チャネル番号を登録しておく。
【００５９】
続いて、STA9-5が帰属する場合の動作について説明する。
【００６０】
まずは、Real AP(A)9-3へ帰属する場合の動作について説明する。ユーザがSTA9-5の画面に表示されているESSID一覧の中から"freewlan"をタップすると、まずSTA9-5はESSIDに"freewlan"を指定したProbeRequestをブロードキャストする。ここで、ProbeRequestフレームにはVendor Specificと呼ばれるベンダが自由にデータを挿入できるエリアがあるため、このエリアに本発明に対応していることを示す"READY"の文字列を挿入して送信する（3-1）。
【００６１】
Real AP(A)9-3は上記ProbeRequestを受信し（4-1）、Vendor Specific 部分に"READY"の文字列が存在するかを確認する（4-2）。そして"READY"の文字列が含まれているので（4-3）、ProbeResponse を送信する（4-5）。ここで、ProbeResponseにもVendor Specificのエリアが存在するため、そこに事前に本発明に対応していることを示す"READY"の文字列とReal AP(A)9-3内に格納されていた検証サーバ証明書を挿入して送信する。
【００６２】
ProbeResponseを受信したSTA9-5は、まずVendor Specificに"READY"の文字列が存在するかを確認する（3-5）。そして存在が確認できるので（3-6）、同封されてきた証明書が信頼できるかを検証する（3-8）。この例では検証サーバ証明書は信頼できる認証局によって署名されており、信頼できる認証局は信頼できるルート証明機関としてあらかじめSTA9-5に設定されている（一般に工場出荷時に設定されている）ため、検証サーバ証明書は信頼できると判断する（3-9）。
【００６３】
続いてSTA9-5は乱数値rndを生成する（3-11）。ここではrndは 12345678 になったとする。そしてSTA9-5は、Real AP(A)9-3に関するESSID,BSSID,チャネル番号を取得し、「"freewlan", AA:AA:AA:AA:AA:AA, 1, 12345678」という情報を検証サーバ証明書に含まれる公開鍵を用いて暗号化する。そして、これらの情報を再びProbeRequestのVendor Specificに格納し、Real AP(A)9-3へ送信する（3-12）。
【００６４】
STA9-5からの２度目のProbeRequestを受信したReal AP(A)9-4は、STA9-5が送信してきた暗号化されたデータをそのまま検証サーバへ転送する（4-9）。検証サーバ9-2はそれを受信し、自身に格納されている秘密鍵を用いてデータを復号化し、データベース上に送信されてきたESSID,BSSID, チャネル番号 が一致するレコードが存在するか確認する（5-2）。ここで図１１に示すように、データベースを見ると、No1のレコードが一致していることがわかる。そのため、検証サーバ9-2は、検証応答として「"OK", 12345678」を Real AP(A)9-3へ送信する（5-5）。
【００６５】
Real AP(A)9-3は検証応答を受信することで初めてrndが 12345678 であることを知る（4-11）。そして、Real AP(A)9-3はSTA9-5との通信をする際には無線LANの暗号化方式をWPA2(AES)方式とし、PSK(Pre Shared Key)としてrndである 12345678 を用いるように設定する（4-15）。さらにReal AP(A)9-3は検証応答の内容を、rndである12345678 を種として生成した共通鍵で暗号化し、ProbeResponseのVendor Specificに格納してSTA9-5へ送信する（4-16）。
【００６６】
2度目のProbeResponseを受信したSTA9-5は、Real AP(A)9-3と同様に 12345678 を種として生成した共通鍵で復号化し、内容を得る（3-16）。その内容は「"OK", 12345678」であり、"OK"でかつ自身が生成したrndと同じ値が書かれているので一連の問い合わせは正しく行われたことを認識し、暗号化方式をWPA2(AES)方式とし、PSKとして 12345678 を用いるように設定される（3-20）。
【００６７】
かくしてSTA9-5とReal AP(A)9-3は互いに接続できる準備が整った状態となる。以降は一般の無線LAN接続処理と同様であり、STA9-5からReal AP(A)9-3へAuthenticationの送信と続き、帰属が完了する。
【００６８】
次にReal AP(B)9-4へ帰属する場合であるが、Real AP(A)9-3と同様の処理が行われて帰属するため、説明は省略する。
【００６９】
続いてRogue AP(A)9-6へ帰属する場合を説明する。Rogue APはReal APと同様の動作をするため、検証サーバ9-2がRogue AP(A)9-6からの検証要求を受信して復号化し、判定を行う(5-2)までの動作はReal AP(B)9-4の場合と同様であるため、説明は省略する。
【００７０】
ここで、Rogue AP(A)9-6へ帰属する場合は、検証要求として送られてくるデータ内容は「"freewlan", BB:BB:BB:BB:BB:BB, 11, 12345678」となる。そのため、検証サーバ9-2のデータベース（図11）上で一致するレコードが存在しない。故に、検証サーバ9-2は検証応答として「"NG", 12345678」をRogue AP(A)9-6に送信する（5-6）。その後の処理もReal AP(B)9-4に帰属する場合と同様に進むが、処理3-17において"OK"ではないので、処理3-20は行われずに子機の処理は終了する。故に、STA9-5は Rogue AP(A)9-6に帰属できない状態となる。
【００７１】
次にRogue AP(B)9-7へ帰属する場合を説明する。この場合、検証要求として送られてくるデータ内容は「"freewlan", BB:BB:BB:BB:BB:BB, 7, 12345678」となり、データベース（図１１）上に存在するため、Real AP(B)9-4に帰属する場合と同様に処理が進む。しかし、Rogue AP(B)9-7と検証サーバ9-2 との間にはIPsecが張られていないため、Rogue AP(B)9-7への検証応答はブロックされ、Rogue AP(B)9-7に届かない。故にRogue AP(B)9-7は処理4-10以降を進められないため、STA9-5がRogue AP(B)9-7に帰属することはない。
【００７２】
次にRogue AP(C)9-8へ帰属する場合を説明する。Rogue AP(C)9-8は検証要求を検証サーバ9-2ではなく、偽の検証サーバ9-9に送信するよう設定されている。この場合、Rogue AP(C)9-8が処理4-5で送信するデジタル証明書は、偽の検証サーバ9-9の証明書となる。攻撃者は本技術の仕組み自体を真似するために、偽の検証サーバ9-9上のデータベースには、図１２に示すように、Rogue AP(C)9-8の情報を登録しておく。しかしながら、そもそも偽の検証サーバ証明書には信頼できる認証局の署名がなされていないため、STA9-5は、処理3-8にて信頼できる認証局の署名が確認できずに帰属処理は終了する。故にSTA9-5がRogue AP(C)9-8に帰属することはない。
【００７３】
これにより、管理者が正規のAPを管理できる状況において、攻撃者に偽のAPを立てられた場合でも、STAは正規のAPにのみ帰属可能にすることができる。
【００７４】
また、デジタル署名されたデジタル証明書を用いることで、攻撃者が本発明技術の仕組み自体を真似することが極めて困難である状態にできる。
【００７５】
実施の形態２
実施の形態１では、STAとAP間での検証要求、および検証応答にProbeRequestあるいは ProbeResponseを利用したが、必ずしもこれらを利用する必要はない。帰属処理が完了するより前に検証要求及び照応等が行われればよいので、AuthenticationパケットやAssociationパケットを利用してもよいし、全く独自にパケットを生成してもよい。
【００７６】
また、検証サーバとReal APの間でのセキュアな経路としてIPsecを用いたが、これについても必ずしもIPsecである必要はない。例えばTLSセッションを張ることで対応してもよいし、独自回線で接続してもよい。
【００７７】
他にも、処理4-15や3-20では無線LANの暗号化方式をWPA2(AES)方式とし、PSKとしてrndを用いるようにしたが、重要なのはrndを種とする暗号通信を行うという点である。そのため、WPA2(AES)方式でなくてもよいし（例えばWPA3-SAEでもよい）、WPA2(AES)であっても、例えば rndの値をそのまま使用するのではなく、rndのhash値をPSKとしてもよい。
【００７８】
また、データベースは検証サーバ内に存在する前提で記述したが、検証サーバとは別にデータベースサーバを用意してもよい。ただしその場合には、検証サーバとデータベースサーバ間についてもあらかじめセキュアな経路を確立しておく必要がある点には、注意する必要がある。
【００７９】
さらに、先述の実施例では信頼できる認証局として公に知られている認証局を利用する場合の例を挙げたが、事業者自身が認証局として検証サーバ証明書に署名することもできる。この場合は公に知られている信頼できる認証局に証明書を発行してもらうためのコストを削減できるが、当然ながらそのままではSTAは信頼できる認証局と認識しないため、正規のAPに接続することもできなくなってしまう。故に、この場合には、あらかじめ事業者自身が作成したルート証明書を、例えば会員向けアプリなどを通じてなど、何らかの確実に安全な手段でSTA本体へ格納しておく必要がある。
【００８０】
このようにして、検証要求や検証応答の方法の変更、セキュアな経路の種類の変更、暗号化方式の変更、データベースの所在の変更、認証局の変更、のいずれか、又は複数の組み合わせで行った状態であって、攻撃者に偽のAPを立てられた場合でも、STAは正規のAPにのみ帰属可能にすることができる。
【００８１】
なお、本発明は上記実施の形態に限られたものではなく、趣旨を逸脱しない範囲で適宜変更することが可能である。
【００８２】
上述の実施の形態では、本発明をハードウェアの構成として説明したが、本発明は、これに限定されるものではない。本発明は、任意の処理を、ＣＰＵ（Central Processing Unit）にコンピュータプログラムを実行させることにより実現することも可能である。  また、上述したプログラムは、様々なタイプの非一時的なコンピュータ可読媒体（ｎｏｎ−ｔｒａｎｓｉｔｏｒｙ  ｃｏｍｐｕｔｅｒ  ｒｅａｄａｂｌｅ  ｍｅｄｉｕｍ）を用いて格納され、コンピュータに供給することができる。非一時的なコンピュータ可読媒体は、様々なタイプの実体のある記録媒体（ｔａｎｇｉｂｌｅ  ｓｔｏｒａｇｅ  ｍｅｄｉｕｍ）を含む。非一時的なコンピュータ可読媒体の例は、磁気記録媒体（例えばフレキシブルディスク、磁気テープ、ハードディスクドライブ）、光磁気記録媒体（例えば光磁気ディスク）、ＣＤ−ＲＯＭ（Ｒｅａｄ  Ｏｎｌｙ  Ｍｅｍｏｒｙ）ＣＤ−Ｒ、ＣＤ−Ｒ／Ｗ、半導体メモリ（例えば、マスクＲＯＭ、ＰＲＯＭ（Ｐｒｏｇｒａｍｍａｂｌｅ  ＲＯＭ）、ＥＰＲＯＭ（Ｅｒａｓａｂｌｅ  ＰＲＯＭ）、フラッシュＲＯＭ、ＲＡＭ（Ｒａｎｄｏｍ  Ａｃｃｅｓｓ  Ｍｅｍｏｒｙ））を含む。また、プログラムは、様々なタイプの一時的なコンピュータ可読媒体（ｔｒａｎｓｉｔｏｒｙ  ｃｏｍｐｕｔｅｒ  ｒｅａｄａｂｌｅ  ｍｅｄｉｕｍ）によってコンピュータに供給されてもよい。一時的なコンピュータ可読媒体の例は、電気信号、光信号、及び電磁波を含む。一時的なコンピュータ可読媒体は、電線及び光ファイバ等の有線通信路、又は無線通信路を介して、プログラムをコンピュータに供給できる。
【符号の説明】
【００８３】
1-1 検証サーバ, 1-2 インターネット, 1-3 Real AP, 1-4 STA, 2-1 検証サーバ, 2-2 Real AP, 2-3 STA, 6-1 検証サーバ, 6-2 インターネット, 6-3 Real AP, 6-4 Rogue AP, 6-5 SPA, 7-1 Real AP, 7-2 Rogue AP, 7-3 STA, 8-1 検証サーバ, 8-2 インターネット, 8-3 Real AP, 8-4 偽の検証サーバ, 8-5 Rogue AP, 8-6 STA, 9-1インターネット, 9-2検証サーバ, 9-3 Real AP(A), 9-4 Real AP(B), 9-5 STA, 9-6 Rogue AP(A), 9-7 Rogue AP(B), 9-8 Rogue AP(C), 9-9 偽の検証サーバ
【要約】
【課題】STAを正規のAPにのみ帰属可能にする。
【解決手段】AP1-3と、AP1-3にするSTA1-4と、AP1-3がSTA1-4からの検証要求を受信した場合に、検証を行う検証サーバ1-1と、正規のAP1-3の情報が登録されたデータベースと、を備え、AP1-3は、信頼できる認証局の署名がされた検証サーバ証明書をSTA1-4に送信し、STA1-4からの検証要求を受信した場合に内容を検証サーバへ送信し、前記検証応答の中に含まれる乱数を種とした暗号通信を行い、検証応答内容を暗号化してSTA1-4に送信し、STA1-4は共通鍵を生成して応答内容を確認し、検証サーバ証明書を受信して信頼できる認証局の署名の有無を検証し、検証要求として接続先の情報および乱数を暗号化してAP1-3へ送信し、STA1-4は、検証応答内容を復号化し検証の合否および乱数が含まれているかを確認し、検証サーバ証明書の内容を復号化し、検証要求に含まれる情報をデータベースのレコードの有無により合否判定を行う。
【選択図】図１【図１】
0006856271.tif 000002
【図２】
0006856271.tif 000003
【図３】
0006856271.tif 000004
【図４】
0006856271.tif 000005
【図５】
0006856271.tif 000006
【図６】
0006856271.tif 000007
【図７】
0006856271.tif 000008
【図８】
0006856271.tif 000009
【図９】
0006856271.tif 000010
【図１０】
0006856271.tif 000011
【図１１】
0006856271.tif 000012
【図１２】
0006856271.tif 000013