(57)【要約】      （修正有）【課題】ユーザとデバイスとの両方を効率的に認証可能な認証システムを提供する。【解決手段】証明書発行要求生成装置１の記憶部１ａは、当該装置の装置情報Ｃ２および暗号鍵Ｋ２を記憶する。演算部１ｂは、情報処理装置２により記憶媒体６から読み取られたユーザＡのユーザ情報Ｃ１を取得する。演算部１ｂは、ユーザ情報Ｃ１と装置情報Ｃ２と暗号鍵Ｋ２とに基づいて、ユーザＡと証明書発行要求生成装置１との組み合わせに対応するものであることを証明する証明書Ａ１の発行要求Ｃを生成し情報処理装置２を介して証明書発行装置３に送信する。証明書発行装置３により、発行要求Ｃに応じて証明書Ａ１が発行され、証明書発行要求生成装置１に提供される。認証時には、証明書発行要求生成装置１により、証明書Ａ１が認証装置４に送信され、認証装置４により、証明書Ａ１に含まれるユーザ情報Ｃ１と装置情報Ｃ２との組み合わせに基づく認証が行われる。【選択図】図１
2015039141.tif 000002
【特許請求の範囲】
【請求項１】
ユーザの情報を含んでおり第１の暗号鍵が前記ユーザに対応するものであることを証明する第１の証明書データと前記第１の暗号鍵とを記憶する記憶媒体を読み取ることができない第１の装置に、
前記記憶媒体を読み取ることができる第２の装置を介して、前記記憶媒体から読み取られた前記ユーザの情報を取得し、
前記ユーザの情報と前記第１の装置の識別情報と前記第１の装置により保持される固有の第２の暗号鍵とに基づいて、前記第２の暗号鍵が前記ユーザと前記第１の装置との組み合わせに対応するものであることを証明する第２の証明書データの発行要求を生成する、
処理を実行させる証明書発行要求生成プログラム。
【請求項２】
前記第２の暗号鍵は、公開鍵基盤に用いられる秘密鍵であり、
前記生成では、前記第２の暗号鍵に対応する公開鍵を前記発行要求に含め、前記第２の暗号鍵により前記発行要求にデジタル署名を付加する、
請求項１記載の証明書発行要求生成プログラム。
【請求項３】
前記発行要求に応じて発行された前記第２の証明書データを取得し、前記第１の装置が備える所定の記憶装置に、前記第２の暗号鍵に対応付けて格納し、
認証装置による認証を受ける際に、前記記憶装置から前記第２の証明書データを読み出し、前記第２の暗号鍵によるデジタル署名を付加して前記認証装置に送信する、
請求項１または２記載の証明書発行要求生成プログラム。
【請求項４】
前記記憶装置に格納された前記第２の証明書データに基づいて、前記第２の証明書データの再発行要求を生成する、請求項３記載の証明書発行要求生成プログラム。
【請求項５】
ユーザの情報を含んでおり第１の暗号鍵が前記ユーザに対応するものであることを証明する第１の証明書データと前記第１の暗号鍵とを記憶する記憶媒体を読み取ることができる第１の装置に、
前記記憶媒体から前記ユーザの情報を取得し、
前記ユーザの情報と前記記憶媒体を読み取ることができない第２の装置の識別情報と前記第２の装置により保持される固有の第２の暗号鍵とに基づいて、前記第２の暗号鍵が前記ユーザと前記第２の装置との組み合わせに対応するものであることを証明する第２の証明書データの発行要求を生成する、
処理を実行させる証明書発行要求生成プログラム。
【請求項６】
ユーザの情報を含んでおり第１の暗号鍵が前記ユーザに対応するものであることを証明する第１の証明書データと前記第１の暗号鍵とを記憶する記憶媒体を読み取ることができない証明書発行要求生成装置であって、
自装置の識別情報と固有の第２の暗号鍵とを記憶する記憶部と、
前記記憶媒体を読み取ることができる装置を介して、前記記憶媒体から読み取られた前記ユーザの情報を取得し、前記ユーザの情報と前記記憶部に記憶された前記識別情報と前記第２の暗号鍵とに基づいて、前記第２の暗号鍵が前記ユーザと自装置との組み合わせに対応するものであることを証明する第２の証明書データの発行要求を生成する演算部と、
を有する証明書発行要求生成装置。
【請求項７】
ユーザの情報を含んでおり第１の暗号鍵が前記ユーザに対応するものであることを証明する第１の証明書データおよび前記第１の暗号鍵を記憶する記憶媒体を読み取ることができる第１の装置と、前記記憶媒体を読み取ることができない第２の装置と、を有し、
前記第１の装置または前記第２の装置は、前記第１の装置により前記記憶媒体に読み取られた前記ユーザの情報と前記第２の装置の識別情報と前記第２の装置により保持される固有の第２の暗号鍵とに基づいて、前記第２の暗号鍵が前記ユーザと前記第２の装置との組み合わせに対応するものであることを証明する第２の証明書データの発行要求を生成する、
証明書発行要求生成システム。
【請求項８】
ユーザの情報を含んでおり第１の暗号鍵が前記ユーザに対応するものであることを証明する第１の証明書データおよび前記第１の暗号鍵を記憶する記憶媒体を読み取ることができる第１の装置と、前記記憶媒体を読み取ることができない第２の装置とを含むシステムが、
前記第１の装置を用いて前記記憶媒体から前記ユーザの情報を取得し、
前記第１の装置または前記第２の装置を用いて、前記ユーザの情報と前記第２の装置の識別情報と前記第２の装置により保持される固有の第２の暗号鍵とに基づいて、前記第２の暗号鍵が前記ユーザと前記第２の装置との組み合わせに対応するものであることを証明する第２の証明書データの発行要求を生成する、
証明書発行要求生成方法。
【請求項９】
他の装置により保持される固有の暗号鍵が前記他の装置を利用するユーザと前記他の装置との組み合わせに対応するものであることを証明する証明書データの発行要求を受信する受信部と、
前記発行要求に応じて前記証明書データを発行する発行部と、
を有する証明書発行装置。
【請求項１０】
前記発行要求は、前記ユーザの情報と前記他の情報の識別情報とを含み、
前記受信部は、前記発行要求を受信する前に行われたユーザ認証に用いられた前記ユーザの情報を取得し、取得した当該情報と、前記発行要求に含まれる前記ユーザの情報とが一致する場合に前記発行要求を受理し、一致しない場合に不受理とする、
請求項９記載の証明書発行装置。
【請求項１１】
第１の装置と認証を行う第２の装置とを含むシステムが実行する認証方法であって、
ユーザの情報と前記第１の装置の識別情報と前記第１の装置が保有する暗号鍵に対応する復号鍵とを含んでおり前記暗号鍵が前記ユーザと前記第１の装置との組み合わせに対応するものであることを証明する証明書データ、および前記証明書データの要約を前記暗号鍵で暗号化した暗号データを前記第１の装置から前記第２の装置に送信し、
前記第２の装置を用いて、前記証明書データおよび前記暗号データにより前記復号鍵に対する前記暗号鍵が前記ユーザと前記第１の装置との組み合わせに対応するものであることを確認すると、前記証明書データに含まれる前記ユーザの情報と前記第１の装置の識別情報との組み合わせに基づいて認証を行う、
認証方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は証明書発行要求生成プログラム、証明書発行要求生成装置、証明書発行要求生成システム、証明書発行要求生成方法、証明書発行装置および認証方法に関する。
【背景技術】
【０００２】
暗号化技術の１つとして公開鍵暗号方式が利用されている。公開鍵暗号方式では、秘密鍵および公開鍵と呼ばれる鍵ペアを用いて情報の暗号化および復号を行う。秘密鍵は所有者により秘密に管理される鍵である。公開鍵は通信相手に対して配布可能な鍵である。
【０００３】
第１に、公開鍵で暗号化された情報は秘密鍵でのみ復号できる。これを利用すれば、装置間の通信を秘匿化できる。第２に、秘密鍵で暗号化された情報は公開鍵でのみ復号できる。これを利用すれば、公開鍵の保有者は、暗号化された情報を受信したとき、当該暗号化された情報を公開鍵で復号できるかを確認することで、情報の送信元を認証できる。
【０００４】
情報の送信元を公開鍵で認証する場合、公開鍵の配布方法が問題となる。例えば、第３者があるユーザになりすまして公開鍵を配布したとしても、配布された相手側は当該公開鍵が真正のユーザによって配布されたものであるか否かを単独では確認できない。そこで、公開鍵の配布元のユーザが真正であることの確認にデジタル証明書が利用されている。
【０００５】
デジタル証明書は、認証局（ＣＡ：Certificate Authority）により発行される。ＣＡは、公開鍵およびユーザ情報を含むデジタル証明書の発行要求（ＣＳＲ：Certificate Signing Request）を受け付けると、ユーザ情報の正当性を確認した上でデジタル証明書を発行し、ユーザに提供する。ＣＡは、デジタル証明書のメッセージダイジェストをＣＡが保有する秘密鍵で暗号化したデータ（デジタル署名）を当該デジタル証明書に付加する。
【０００６】
ユーザは、デジタル証明書を用いて自身の公開鍵を配布できる。デジタル証明書を取得した相手側は、ＣＡの公開鍵でＣＡのデジタル署名を検証することで、デジタル証明書に含まれる公開鍵の配布元（公開鍵に対応する秘密鍵の保有者）がＣＡにより保証された真正のユーザであることを確認できる。このようにユーザの真正性の確認を考慮した認証の仕組みは、公開鍵基盤（ＰＫＩ：Public Key Infrastructure）と呼ばれることがある。
【０００７】
例えば、ユーザに対応する秘密鍵とデジタル証明書とをスマートカードに格納しておき、ＰＫＩの仕組みでユーザ認証を行うことがある。ユーザがコンピュータを用いてネットワークやサーバなどへアクセスする際に、スマートカード内の秘密鍵とデジタル証明書とを用いた認証を課すことで、当該ユーザが真正のユーザであるか否かを確認できる。
【０００８】
なお、リモートデバイスで実行されるリモートデバイスデジタル証明書管理（ＲＤＤＣＭ）モジュールが、ワークステーションで実行されるワークステーションデジタル証明書管理（ＷＫＳＤＣＭ）モジュールからＣＳＲ作成要求を受け取ると、その要求に含められたデータと秘密鍵および／または公開鍵を使ってＣＳＲを作成する提案がある。
【先行技術文献】
【特許文献】
【０００９】
【特許文献１】特開２００８−２６２５６４号公報
【発明の概要】
【発明が解決しようとする課題】
【００１０】
近年、ネットワークへアクセス可能な比較的小型のデバイス（例えば、スマートフォンやタブレット装置など）が普及している。このため、組織内のネットワークに対し、不特定多数のユーザおよびデバイスがアクセスを試行し得る。そこで、これらデバイスからの不正アクセスに対するセキュリティを、どのようにして確保するかが問題となる。
【００１１】
特に、小型のデバイスにはスマートカードなどの記憶媒体を直接挿入して読み取れるインタフェースをもたないものがある。この場合、デバイスを利用するユーザの真正性の確認が容易でない。例えば、スマートカードを用いる代わりに、ユーザの識別情報をユーザにキー入力させて認証することも考えられるが、なりすましの問題が残る。同様に、デバイスの真正性の確認も容易でない。例えば、デバイスの情報をユーザにキー入力させるとしても、不正なデバイスから真正なデバイスの情報が不正に入力され得る。その上、ユーザやデバイスの情報を、アクセスの度にキー入力させるのはユーザにとって手間である。
【００１２】
１つの側面では、本発明は、ユーザとデバイスとの両方を効率的に認証可能とする証明書発行要求生成プログラム、証明書発行要求生成装置、証明書発行要求生成システム、証明書発行要求生成方法、証明書発行装置および認証方法を提供することを目的とする。
【課題を解決するための手段】
【００１３】
１つの態様では、ユーザの情報を含んでおり第１の暗号鍵がユーザに対応するものであることを証明する第１の証明書データと第１の暗号鍵とを記憶する記憶媒体を読み取ることができない第１の装置によって実行される証明書発行要求生成プログラムが提供される。この証明書発行要求生成プログラムは、第１の装置に、記憶媒体を読み取ることができる第２の装置を介して、記憶媒体から読み取られたユーザの情報を取得し、ユーザの情報と第１の装置の識別情報と第１の装置により保持される固有の第２の暗号鍵とに基づいて、第２の暗号鍵がユーザと第１の装置との組み合わせに対応するものであることを証明する第２の証明書データの発行要求を生成する、処理を実行させる。
【００１４】
また、１つの態様では、ユーザの情報を含んでおり第１の暗号鍵がユーザに対応するものであることを証明する第１の証明書データと第１の暗号鍵とを記憶する記憶媒体を読み取ることができる第１の装置によって実行される証明書発行要求生成プログラムが提供される。この証明書発行要求生成プログラムは、第１の装置に、記憶媒体からユーザの情報を取得し、ユーザの情報と記憶媒体を読み取ることができない第２の装置の識別情報と第２の装置により保持される固有の第２の暗号鍵とに基づいて、第２の暗号鍵がユーザと第２の装置との組み合わせに対応するものであることを証明する第２の証明書データの発行要求を生成する、処理を実行させる。
【００１５】
また、１つの態様では、ユーザの情報を含んでおり第１の暗号鍵がユーザに対応するものであることを証明する第１の証明書データと第１の暗号鍵とを記憶する記憶媒体を読み取ることができない証明書発行要求生成装置が提供される。この証明書発行要求生成装置は、記憶部と演算部とを有する。記憶部は、自装置の識別情報と固有の第２の暗号鍵とを記憶する。演算部は、記憶媒体を読み取ることができる装置を介して、記憶媒体から読み取られたユーザの情報を取得し、ユーザの情報と記憶部に記憶された識別情報と第２の暗号鍵とに基づいて、第２の暗号鍵がユーザと自装置との組み合わせに対応するものであることを証明する第２の証明書データの発行要求を生成する。
【００１６】
また、１つの態様では、証明書発行要求生成システムが提供される。この証明書発行要求生成システムは、ユーザの情報を含んでおり第１の暗号鍵がユーザに対応するものであることを証明する第１の証明書データおよび第１の暗号鍵を記憶する記憶媒体を読み取ることができる第１の装置と、記憶媒体を読み取ることができない第２の装置と、を有する。第１の装置または第２の装置は、第１の装置により記憶媒体に読み取られたユーザの情報と第２の装置の識別情報と第２の装置により保持される固有の第２の暗号鍵とに基づいて、第２の暗号鍵がユーザと第２の装置との組み合わせに対応するものであることを証明する第２の証明書データの発行要求を生成する。
【００１７】
また、１つの態様では、証明書発行要求生成方法が提供される。この証明書発行要求生成方法では、ユーザの情報を含んでおり第１の暗号鍵がユーザに対応するものであることを証明する第１の証明書データおよび第１の暗号鍵を記憶する記憶媒体を読み取ることができる第１の装置と、記憶媒体を読み取ることができない第２の装置とを含むシステムが、第１の装置を用いて記憶媒体からユーザの情報を取得し、第１の装置または第２の装置を用いて、ユーザの情報と第２の装置の識別情報と第２の装置により保持される固有の第２の暗号鍵とに基づいて、第２の暗号鍵がユーザと第２の装置との組み合わせに対応するものであることを証明する第２の証明書データの発行要求を生成する。
【００１８】
また、１つの態様では、証明書発行装置が提供される。この証明書発行装置は、受信部と発行部とを有する。受信部は、他の装置により保持される固有の暗号鍵が他の装置を利用するユーザと他の装置との組み合わせに対応するものであることを証明する証明書データの発行要求を受信する。発行部は、発行要求に応じて証明書データを発行する。
【００１９】
また、１つの態様では、認証方法が提供される。この認証方法では、第１の装置と認証を行う第２の装置とを含むシステムが、ユーザの情報と第１の装置の識別情報と第１の装置が保有する暗号鍵に対応する復号鍵とを含んでおり暗号鍵がユーザと第１の装置との組み合わせに対応するものであることを証明する証明書データ、および証明書データの要約を暗号鍵で暗号化した暗号データを第１の装置から第２の装置に送信し、第２の装置を用いて、証明書データおよび暗号データにより復号鍵に対する暗号鍵がユーザと第１の装置との組み合わせに対応するものであることを確認すると、証明書データに含まれるユーザの情報と第１の装置の識別情報との組み合わせに基づいて認証を行う。
【発明の効果】
【００２０】
１つの側面では、ユーザとデバイスとの両方を効率的に認証可能とする。
【図面の簡単な説明】
【００２１】
【図１】第１の実施の形態の認証システムを示す図である。
【図２】第２の実施の形態の情報処理システムを示す図である。
【図３】第２の実施の形態のスマートデバイスのハードウェア例を示す図である。
【図４】第２の実施の形態のＰＣのハードウェア例を示す図である。
【図５】第２の実施の形態のソフトウェア例を示す図である。
【図６】第２の実施の形態のデバイス情報の例を示す図である。
【図７】第２の実施の形態のユーザ証明書の例を示す図である。
【図８】第２の実施の形態のＣＳＲの例を示す図である。
【図９】第２の実施の形態のコンポジット証明書の例を示す図である。
【図１０】第２の実施の形態の認証テーブルの例を示す図である。
【図１１】第２の実施の形態のＣＳＲ生成の例を示すフローチャートである。
【図１２】第２の実施の形態の証明書申請の例を示すフローチャートである。
【図１３】第２の実施の形態の証明書発行の例を示すフローチャートである。
【図１４】第２の実施の形態の証明書発行の例を示すシーケンス図である。
【図１５】第２の実施の形態の認証の例を示すフローチャートである。
【図１６】第２の実施の形態の認証の例を示すシーケンス図である。
【図１７】第２の実施の形態の証明書の更新例を示すフローチャートである。
【図１８】第３の実施の形態のデバイス管理テーブルの例を示す図である。
【図１９】第３の実施の形態のＣＳＲ生成の例を示すフローチャートである。
【図２０】第４の実施の形態の認証の例を示すシーケンス図である。
【発明を実施するための形態】
【００２２】
以下、本実施の形態を図面を参照して説明する。
［第１の実施の形態］
図１は、第１の実施の形態の認証システムを示す図である。第１の実施の形態の認証システムは、証明書発行要求生成装置１、情報処理装置２、証明書発行装置３および認証装置４を含む。情報処理装置２、証明書発行装置３および認証装置４は、ネットワーク５を介して接続されている。
【００２３】
第１の実施の形態の認証システムでは、ユーザＡは、ユーザＡ自身に対するデジタル証明書（第１の証明書データ。以下、ユーザ証明書Ｘという）の発行を認証装置４から事前に受ける。ユーザ証明書Ｘは、ユーザ情報Ｃ１（例えば、ユーザＡの氏名、メールアドレス、所属など）を含む。ユーザ証明書Ｘは、ユーザＡが保有する記憶媒体６に格納される。
【００２４】
記憶媒体６は、ユーザＡに固有の暗号鍵Ｋ１とユーザ証明書Ｘとを記憶する可搬記憶媒体である。ユーザ証明書Ｘは、当該暗号鍵Ｋ１がユーザＡに対応付けられるものであることを証明するデータであるともいえる。記憶媒体６は、スマートカードやＩＣ（Integrated Circuit）カードなどと呼ばれるものでもよい。記憶媒体６はユーザＡにより保管管理される。
【００２５】
ユーザＡは、所定の装置を用いてネットワーク５（または、ネットワーク５に属する装置）にアクセスする際に、記憶媒体６に格納されたユーザ証明書Ｘを用いた認証を、認証装置４により求められる。認証装置４によりユーザＡが真正であると確認された場合に、ユーザＡが利用する装置によるネットワーク５へのアクセスが許容される。
【００２６】
証明書発行要求生成装置１は、証明書の発行要求を生成する装置である。証明書発行要求生成装置１は、スマートフォンやタブレット装置などの携帯装置である。スマートフォンなどの携帯装置はスマートデバイスと呼ばれることもある。証明書発行要求生成装置１は、無線または有線の通信を行える第１の通信インタフェースを用いて、情報処理装置２と直接通信可能である。
【００２７】
証明書発行要求生成装置１は、無線または有線の通信を行える第２の通信インタフェースを用いて、ネットワーク５にアクセスし得る。また、証明書発行要求生成装置１は、記憶媒体６を読み取ることができない。例えば、証明書発行要求生成装置１は、記憶媒体６を直接挿入して情報を読み取れるインタフェースを備えていない。
【００２８】
証明書発行要求生成装置１は、記憶部１ａおよび演算部１ｂを有する。記憶部１ａは、ＲＡＭ（Random Access Memory）などの揮発性記憶装置でもよいし、ＨＤＤ（Hard Disk Drive）やフラッシュメモリなどの不揮発性記憶装置でもよい。演算部１ｂは、ＣＰＵ（Central Processing Unit）、ＤＳＰ（Digital Signal Processor）、ＡＳＩＣ（Application Specific Integrated Circuit）、ＦＰＧＡ（Field Programmable Gate Array）などを含み得る。演算部１ｂはプログラムを実行するプロセッサであってもよい。ここでいう「プロセッサ」には、複数のプロセッサの集合（マルチプロセッサ）も含まれ得る。
【００２９】
記憶部１ａは、証明書発行要求生成装置１の識別情報（以下、装置情報Ｃ２ということがある）を記憶する。暗号鍵Ｋ２は、証明書発行要求生成装置１により保持される固有の鍵である。暗号鍵Ｋ２はＰＫＩに用いられる秘密鍵でもよい。
【００３０】
演算部１ｂは、記憶媒体６を読み取ることができる情報処理装置２を介して、記憶媒体６から読み取られたユーザ証明書Ｘを取得する。ユーザ証明書Ｘはユーザ情報Ｃ１を含むから、演算部１ｂはユーザ情報Ｃ１を取得しているといえる。例えば、情報処理装置２は、記憶媒体６を直接挿入して読み取れるインタフェースを備えており、当該インタフェースを用いて記憶媒体６からユーザ証明書Ｘを読み取ることができる。または、情報処理装置２は、記憶媒体６を直接挿入して情報を読み取るリーダ装置を接続可能なインタフェースを備え、当該リーダ装置を用いて記憶媒体６からユーザ証明書Ｘを読み取ってもよい。
【００３１】
演算部１ｂは、ユーザ証明書Ｘに含まれるユーザ情報Ｃ１と記憶部１ａに記憶された装置情報Ｃ２と暗号鍵Ｋ２とに基づいて、暗号鍵Ｋ２がユーザＡと証明書発行要求生成装置１との組み合わせに対応するものであることを証明するデジタル証明書（第２の証明書データ。以下、証明書Ａ１という）の発行要求Ｃを生成する。発行要求Ｃは、ユーザ情報Ｃ１と装置情報Ｃ２と暗号鍵Ｋ２に対応する公開鍵とを含む。発行要求Ｃは、暗号鍵Ｋ２によるデジタル署名を含む。発行要求Ｃは、ＣＳＲと呼ばれるものでもよい。演算部１ｂは、情報処理装置２に発行要求Ｃを送信する。
【００３２】
情報処理装置２は、前述のように記憶媒体６を読み取れる。情報処理装置２は、ユーザ証明書Ｘを用いて認証装置４によるユーザ認証を受けた上で、証明書発行装置３に発行要求Ｃを送信する。証明書発行装置３は、ＣＡの役割を担う。証明書発行装置３は、受信部３ａおよび発行部３ｂを有する。
【００３３】
受信部３ａは、発行要求Ｃを受信する。発行部３ｂは、発行要求Ｃに応じて証明書Ａ１を発行する。証明書Ａ１は、ユーザ情報Ｃ１および装置情報Ｃ２を含む。発行部３ｂは、発行要求Ｃに含まれるデジタル署名の検証に成功した場合に、証明書Ａ１を発行する。また、発行部３ｂは、発行要求Ｃに含まれるユーザ情報Ｃ１と、事前に取得したユーザ情報（例えば、情報処理装置２によるネットワーク５へのアクセス認証に用いられたユーザ情報）との一致を確認した場合に、証明書Ａ１を発行してもよい。証明書Ａ１には、証明書発行装置３によるデジタル署名が付加される。発行された証明書Ａ１は、情報処理装置２などを介して、証明書発行要求生成装置１に提供される。
【００３４】
演算部１ｂは、記憶部１ａに証明書Ａ１を格納する。演算部１ｂは、以後、証明書Ａ１を用いて、認証装置４による認証を受け、ネットワーク５へアクセス可能となる。例えば、演算部１ｂは、暗号鍵Ｋ２を用いたデジタル署名（署名データＡ１ｓという）を証明書Ａ１に付加し、証明書Ａ１とともに認証装置４に送る。署名データＡ１ｓは、証明書Ａ１のメッセージダイジェスト（要約）を暗号鍵Ｋ２で暗号化した暗号データである。例えば、メッセージダイジェストは証明書Ａ１のハッシュ値である。
【００３５】
認証装置４は、証明書Ａ１および署名データＡ１ｓにより証明書Ａ１に含まれる復号鍵（例えば、公開鍵）に対応する暗号鍵Ｋ２がユーザＡと証明書発行要求生成装置１との組み合わせに対応するものであることを確認する。例えば、認証装置４は、証明書Ａ１に含まれる証明書発行装置３のデジタル署名を証明書発行装置３の公開鍵で検証する。これにより、証明書Ａ１に含まれる復号鍵および暗号鍵Ｋ２の鍵ペアがユーザＡと証明書発行要求生成装置１との組み合わせに対応するものであることを確認できる。更に、認証装置４は、証明書発行要求生成装置１の署名データＡ１ｓを証明書Ａ１に含まれる復号鍵で検証する。これにより、認証装置４は、ユーザＡと証明書発行要求生成装置１との真正な組み合わせで、認証要求がなされていることを確認できる。その上で、認証装置４は、ユーザＡと証明書発行要求生成装置１との組み合わせがネットワーク５に対してアクセス権限を有するかを認証し得る。
【００３６】
第１の実施の形態の認証システムによれば、情報処理装置２により、記憶媒体６からユーザＡのユーザ情報Ｃ１が取得され、証明書発行要求生成装置１に提供される（ステップＳ１）。証明書発行要求生成装置１により、ユーザ情報Ｃ１と装置情報Ｃ２と暗号鍵Ｋ２とに基づいて、証明書Ａ１の発行要求Ｃが生成される。
【００３７】
これにより、記憶媒体６からユーザＡのユーザ証明書Ｘを読み取ることができないデバイス（証明書発行要求生成装置１）であっても、ユーザＡと当該デバイスとの両方を効率的に認証できるようになる。具体的には次の通りである。
【００３８】
その後、発行要求Ｃは情報処理装置２を介して証明書発行装置３に送信される（ステップＳ２）。証明書発行装置３により、発行要求Ｃに応じて証明書Ａ１が発行され、証明書発行要求生成装置１に提供される（ステップＳ３）。認証時には、証明書発行要求生成装置１により、証明書Ａ１が認証装置４に送信される（ステップＳ４）。認証装置４により、証明書Ａ１を用いて、暗号鍵Ｋ２がユーザＡと証明書発行要求生成装置１との組み合わせに対応するものであることが確認される。そして、認証装置４により、証明書Ａ１に含まれるユーザ情報Ｃ１と装置情報Ｃ２との組み合わせに基づく認証が行われる。
【００３９】
すなわち、証明書Ａ１を用いることで、ユーザＡと証明書発行要求生成装置１との両方が真正であることを一括して確認できる。証明書Ａ１は、１度発行されれば有効期間が切れるまでは継続して利用できる。このため、証明書発行要求生成装置１を用いてネットワーク５にアクセスする度にユーザ情報Ｃ１や装置情報Ｃ２をユーザＡにより入力させるよりも、ユーザによる操作の手間を軽減できる。
【００４０】
また、不正なユーザによるアクセスや不正なデバイスからのアクセスに対するセキュリティを向上することができる。特に、真正なユーザおよび真正なデバイスの適切な組み合わせを許容し、ユーザとデバイスとの不正な組み合わせによるアクセスを制限できる。このため、より強固なセキュリティを実現することができる。
【００４１】
特に、小型のデバイスにはスマートカードなどの記憶媒体を直接挿入して読み取れるインタフェースをもたないものがある。小型のデバイスは、屋外に持ち出して利用することが多く、ネットワーク５にアクセスしたいときにユーザがリーダ装置を持ち合わせていないことも多い（リーダ装置を別個に持ち歩かねばならないとすると不便である）。そこで、上記のように、認証を受けたいデバイスに証明書Ａ１を格納しておけば、屋外などからネットワーク５にアクセスしたいときにも便利である。
【００４２】
このようにして、ユーザとデバイスとの両方を効率的に認証できるようになる。なお、情報処理装置２が、証明書発行要求生成装置１の代わりに、発行要求Ｃを作成してもよい。具体的には次の通りである。
【００４３】
情報処理装置２は、記憶部２ａおよび演算部２ｂを有する。記憶部２ａは、記憶部１ａと同様に、ＲＡＭやＨＤＤなどでもよい。演算部２ｂは、演算部１ｂと同様に、プログラムを実行するＣＰＵなどのプロセッサでもよい。
【００４４】
記憶部２ａは、記憶媒体６から読み取ったユーザ情報Ｃ１を記憶する。演算部２ｂは、ユーザ情報Ｃ１と証明書発行要求生成装置１から取得された装置情報Ｃ２と暗号鍵Ｋ２とに基づいて、証明書の発行要求Ｃを生成する。演算部２ｂは、証明書発行装置３に発行要求Ｃを送信することで、証明書Ａ１の発行を受ける。例えば、演算部２ｂは、発行された証明書Ａ１を証明書発行要求生成装置１に提供する。
【００４５】
このように、証明書発行要求生成装置１の代わりに情報処理装置２が証明書Ａ１の発行要求Ｃを生成してもよい。これにより、上記と同様に、証明書発行要求生成装置１とユーザＡとの両方を効率的に認証できるようになる。
【００４６】
なお、情報処理装置２は、ネットワーク５に接続されたゲートウェイ装置７を介して証明書発行装置３に発行要求Ｃを送信してもよい。例えば、証明書発行装置３がインターネットに存在している場合である。この場合、ゲートウェイ装置７は、認証装置４による認証に成功した情報処理装置２から発行要求Ｃを取得する。ゲートウェイ装置７は証明書発行装置３に発行要求Ｃを転送する。このとき、上述した発行部３ｂによる事前確認（発行要求Ｃに含まれるユーザ情報Ｃ１と、情報処理装置２によるネットワーク５へのアクセス認証に用いられたユーザ情報とが一致するかの確認）を、発行部３ｂの代わりに、ゲートウェイ装置７が行ってもよい。すなわち、ゲートウェイ装置７は一致が確認できた場合に証明書発行装置３への発行要求Ｃの転送を行い、一致が確認できない場合には当該転送を行わないようにしてもよい。
【００４７】
［第２の実施の形態］
図２は、第２の実施の形態の情報処理システムを示す図である。第２の実施の形態の情報処理システムは、スマートデバイス（ＳＤ：Smart Device）１００、ＰＣ（Personal Computer）２００、スマートカード（ＳＣ：Smart Card）３００、ＷｅｂＧＷ（GateWay）サーバ４００、認証サーバ５００、ＤＨＣＰ（Dynamic Host Configuration Protocol）サーバ６００、業務サーバ７００、ＲＡ（Registration Authority）サーバ８００およびＣＡサーバ９００を含む。第２の実施の形態の情報処理システムは認証の仕組みにＰＫＩを用いる。
【００４８】
ＰＣ２００、ＷｅｂＧＷサーバ４００、認証サーバ５００、ＤＨＣＰサーバ６００、業務サーバ７００は、ネットワーク１０に接続されている。ＲＡサーバ８００およびＣＡサーバ９００は、ネットワーク２０に接続されている。ネットワーク１０，２０は相互に接続されている。ネットワーク１０はＬＡＮ（Local Area Network）である。ネットワーク２０は、ＬＡＮでもよいし、ＷＡＮ（Wide Area Network）やインターネットなどの広域ネットワークでもよい。
【００４９】
ＳＤ１００は、アクセスポイント１１を介してネットワーク１０にアクセス可能である。ただし、ＳＤ１００は、認証サーバ５００による認証を受けなければ、アクセスポイント１１を介したネットワーク１０へのアクセスを許可されない。ここで、アクセスポイント１１は無線ルータである。
【００５０】
また、ＳＤ１００のネットワーク１０に対するアクセス認証に、ＩＥＥＥ（The Institute of Electrical and Electronic Engineers）８０２．１Ｘを用いる。この場合、ＳＤ１００の認証用のクライアント機能をサプリカント（supplicant）、アクセスポイント１１をオーセンティケータ（authenticator）と呼ぶことがある。
【００５１】
以下の説明では、ＩＥＥＥ８０２．１Ｘ認証のうち、ＥＡＰ（Extensible Authentication Protocol）−ＴＬＳ（Transport Layer Security）を想定する。ＥＡＰ−ＴＬＳは、ＳＤ１００および認証サーバ５００の双方でデジタル証明書（公開鍵証明書と呼ぶこともある）による相互認証を行う手順を提供する。
【００５２】
ＳＤ１００は、ユーザＺによって利用される携帯装置である。例えば、ＳＤ１００はスマートフォンまたはタブレット装置などである。また、ＳＤ１００は、ＳＣ３００に記憶する情報を直接読み取ることができない。
【００５３】
ＰＣ２００は、ユーザＺによって利用されるクライアントコンピュータである。ＰＣ２００はリーダライタ装置２１を用いてＳＣ３００に記憶された情報を読み取ることができる。リーダライタ装置２１は、ＰＣ２００に所定のケーブルを用いて接続可能である。リーダライタ装置２１は、ＳＣ３００に記憶された情報を読み取り、ＰＣ２００に出力する。ＰＣ２００は、認証サーバ５００によるＴＬＳ認証を受けた上で、ＷｅｂＧＷサーバ４００にアクセス可能である。
【００５４】
ＳＣ３００は、ユーザＺにより所有され、ユーザＺが組織に所属する人物であることを示すＩＤ（IDentifier）カードである。ＳＣ３００は、ユーザＺに固有の秘密鍵およびユーザＺのユーザ証明書を記憶する。
【００５５】
ユーザ証明書は、ＳＣ３００に格納された秘密鍵に対応する公開鍵を含む。ユーザ証明書は、当該秘密鍵と当該公開鍵との鍵ペアがユーザＺに対応するものであることを証明するデータである。ユーザ証明書には、ＣＡサーバ９００の秘密鍵によるデジタル署名が付加される（ＣＡサーバ９００の秘密鍵で署名される）。
【００５６】
ＷｅｂＧＷサーバ４００は、ＲＡサーバ８００に対して電子証明書の発行を要求するサーバコンピュータである。例えば、ＷｅｂＧＷサーバ４００はＷｅｂサーバ機能を備え、ＰＣ２００で動作するＷｅｂブラウザに、ＣＳＲ申請用のＧＵＩ（Graphical User Interface）を提供する。
【００５７】
認証サーバ５００は、アクセスポイント１１と連携してネットワーク１０に対するアクセス認証を行うサーバコンピュータである。認証サーバ５００は、ＲＡＤＩＵＳ（Remote Authentication Dial In User Service）サーバとして機能し、ＳＤ１００からネットワーク１０へのアクセス許否を、アクセスポイント１１に指示する。また、認証サーバ５００は、ＷｅｂＧＷサーバ４００に対してＰＣ２００がアクセスする際のＴＬＳ認証（または、ＳＳＬ（Secure Sockets Layer）認証）も行う。
【００５８】
ＤＨＣＰサーバ６００は、認証サーバ５００による認証に成功したＳＤ１００に対して、ＩＰ（Internet Protocol）アドレスを割り当てるサーバコンピュータである。
業務サーバ７００は、認証サーバ５００による認証に成功したＳＤ１００やＰＣ２００に対して、業務アプリケーションの機能を提供するサーバコンピュータである。例えば、業務サーバ７００は、Ｗｅｂサーバとして機能し、業務アプリケーションを利用するためのＧＵＩを、クライアントで動作するＷｅｂブラウザに提供する。
【００５９】
ＲＡサーバ８００は、ＣＳＲを審査するサーバコンピュータである。ＣＡサーバ９００は、ＣＳＲに対してデジタル証明書を発行するサーバコンピュータである。ユーザＺは、自身が利用するＳＤ１００を用いてアクセスポイント１１を介してネットワーク１０へアクセスしたい場合、ＳＣ３００内のユーザ証明書とは別個のデジタル証明書をＣＡサーバ９００から事前に取得しておく必要がある。
【００６０】
図３は、第２の実施の形態のスマートデバイスのハードウェア例を示す図である。ＳＤ１００は、プロセッサ１０１、ＲＡＭ１０２、フラッシュメモリ１０３、無線部１０４、ディスプレイ１０５、入力デバイス１０６、媒体読取部１０７および機器接続部１０８を有する。各ユニットはＳＤ１００のバスに接続されている。
【００６１】
プロセッサ１０１は、ＳＤ１００の情報処理を制御する。プロセッサ１０１は、例えばＣＰＵ、ＤＳＰ、ＡＳＩＣまたはＦＰＧＡなどである。プロセッサ１０１は、マルチプロセッサであってもよい。プロセッサ１０１は、ＣＰＵ、ＤＳＰ、ＡＳＩＣ、ＦＰＧＡなどの２以上の要素の組合せであってもよい。
【００６２】
ＲＡＭ１０２は、ＳＤ１００の主記憶装置である。ＲＡＭ１０２は、プロセッサ１０１に実行させるＯＳ（Operating System）のプログラムやアプリケーションプログラムの少なくとも一部を一時的に記憶する。また、ＲＡＭ１０２は、プロセッサ１０１による処理に用いる各種データを記憶する。
【００６３】
フラッシュメモリ１０３は、ＳＤ１００の補助記憶装置である。フラッシュメモリ１０３には、ＯＳのプログラム、アプリケーションプログラムおよび各種データが格納される。フラッシュメモリ１０３は、ＳＤ１００に対して着脱可能な可搬型の記録媒体でもよい。
【００６４】
無線部１０４は、無線通信を行えるインタフェースである。無線部１０４は、アクセスポイント１１を介してネットワーク１０にアクセスできる。無線部１０４は、ネットワーク１０に接続された他のコンピュータとプログラムやデータの送受信を行える。
【００６５】
ディスプレイ１０５は、プロセッサ１０１からの命令に従って、画像を出力する。例えば、ディスプレイ１０５は、液晶ディスプレイや有機ＥＬ（Electro Luminescence）ディスプレイなどである。
【００６６】
入力デバイス１０６は、ユーザによる操作入力を検出し、入力信号をプロセッサ１０１に出力する。入力デバイス１０６としては、例えば、タッチパネルやキーパッドなどを用いることができる。
【００６７】
媒体読取部１０７は、プロセッサ１０１からの命令に従って、可搬型のメモリカード１２からプログラムやデータを読み取ったり、メモリカード１２に対してプログラムやデータを書き込んだりする。媒体読取部１０７は、メモリカード１２から読み取ったプログラムやデータをＲＡＭ１０２またはフラッシュメモリ１０３に格納する。
【００６８】
機器接続部１０８は、ＳＤ１００に周辺機器を接続するためのインタフェースである。当該インタフェースとして、例えば、ＵＳＢ（Universal Serial Bus）を用いることができる。例えば、機器接続部１０８にはＰＣ２００を接続できる。
【００６９】
図４は、第２の実施の形態のＰＣのハードウェア例を示す図である。ＰＣ２００は、プロセッサ２０１、ＲＡＭ２０２、ＨＤＤ２０３、通信部２０４、画像信号処理部２０５、入力信号処理部２０６、ディスクドライブ２０７および機器接続部２０８を有する。各ユニットはＰＣ２００のバスに接続されている。
【００７０】
プロセッサ２０１は、ＰＣ２００の情報処理を制御する。プロセッサ２０１は、例えばＣＰＵ、ＤＳＰ、ＡＳＩＣまたはＦＰＧＡなどである。プロセッサ２０１は、マルチプロセッサであってもよい。プロセッサ２０１は、ＣＰＵ、ＤＳＰ、ＡＳＩＣまたはＦＰＧＡのうちの２以上の要素の組み合わせであってもよい。
【００７１】
ＲＡＭ２０２は、ＰＣ２００の主記憶装置である。ＲＡＭ２０２は、プロセッサ２０１に実行させるＯＳのプログラムやアプリケーションプログラムの少なくとも一部を一時的に記憶する。また、ＲＡＭ２０２は、プロセッサ２０１による処理に用いる各種データを記憶する。
【００７２】
ＨＤＤ２０３は、ＰＣ２００の補助記憶装置である。ＨＤＤ２０３は、内蔵した磁気ディスクに対して、磁気的にデータの書き込みおよび読み出しを行う。ＨＤＤ２０３には、ＯＳのプログラム、アプリケーションプログラム、および各種データが格納される。ＰＣ２００は、フラッシュメモリやＳＳＤ（Solid State Drive）などの他の種類の補助記憶装置を備えてもよく、複数の補助記憶装置を備えてもよい。
【００７３】
通信部２０４は、ネットワーク１０に接続された他のコンピュータとプログラムやデータの送受信を行えるインタフェースである。
画像信号処理部２０５は、プロセッサ２０１からの命令に従って、ＰＣ２００に接続されたディスプレイ２２に画像を出力する。ディスプレイ２２としては、ＣＲＴ（Cathode Ray Tube）ディスプレイや液晶ディスプレイなどを用いることができる。
【００７４】
入力信号処理部２０６は、ＰＣ２００に接続された入力デバイス２３から入力信号を取得し、プロセッサ２０１に出力する。入力デバイス２３としては、例えば、マウスやタッチパネルなどのポインティングデバイス、キーボードなどを用いることができる。
【００７５】
ディスクドライブ２０７は、レーザ光などを利用して、光ディスク２４に記録されたプログラムやデータを読み取る駆動装置である。光ディスク２４として、例えば、ＤＶＤ（Digital Versatile Disc）、ＤＶＤ−ＲＡＭ、ＣＤ−ＲＯＭ（Compact Disc Read Only Memory）、ＣＤ−Ｒ（Recordable）／ＲＷ（ReWritable）などを使用できる。ディスクドライブ２０７は、例えば、プロセッサ２０１からの命令に従って、光ディスク２４から読み取ったプログラムやデータをＲＡＭ２０２またはＨＤＤ２０３に格納する。
【００７６】
機器接続部２０８は、ＰＣ２００に周辺機器を接続するためのインタフェースである。当該インタフェースとして、例えば、ＵＳＢを利用できる。例えば、機器接続部２０８には、ＵＳＢケーブルなどを介して、ＳＤ１００やメモリ装置２５、リーダライタ装置２１を接続できる。メモリ装置２５は、機器接続部２０８との通信機能を搭載した記録媒体である。リーダライタ装置２１は、前述のＳＣ３００からのデータの読み出しのほか、メモリカード１２へのデータの書き込み、またはメモリカード１２からのデータの読み出しを行える。機器接続部２０８は、例えば、プロセッサ２０１からの命令に従って、メモリ装置２５またはメモリカード１２、ＳＣ３００から読み取ったプログラムやデータをＲＡＭ２０２またはＨＤＤ２０３に格納する。
【００７７】
ＷｅｂＧＷサーバ４００、認証サーバ５００、ＤＨＣＰサーバ６００、業務サーバ７００、ＲＡサーバ８００およびＣＡサーバ９００も、ＰＣ２００と同様のハードウェアを用いて実現できる。また、ＳＣ３００もＳＤ１００やＰＣ２００と同様に演算処理を行うプロセッサと当該プロセッサの処理に用いられるメモリとを備えている。
【００７８】
図５は、第２の実施の形態のソフトウェア例を示す図である。図５に示すユニットの一部または全部は、各装置が備えるプロセッサによって実行されるプログラムのモジュールであってもよい。ＳＤ１００は、記憶部１１０および制御部１２０を有する。
【００７９】
記憶部１１０は、ＳＤ１００の識別情報（デバイス情報）を記憶する。デバイス情報は、例えば、ＭＡＣ（Media Access Control）アドレスや国際移動体装置識別番号（ＩＭＥＩ：International Mobile Equipment Identity）などである。ＳＤ１００を識別できる情報であれば、他の情報をデバイス情報として用いてもよい。記憶部１１０は、秘密鍵と公開鍵とのペア（鍵ペア）を記憶する。また、記憶部１１０は、ＣＡサーバ９００により発行されたデジタル証明書を記憶する。記憶部１１０は、ＲＡＭ１０２やフラッシュメモリ１０３の記憶領域を用いて実現できる。
【００８０】
制御部１２０は、鍵ペアを生成し、記憶部１１０に格納する。制御部１２０は、鍵ペアを用いてデジタル証明書の発行要求（ＣＳＲ）を生成する。具体的には、制御部１２０は、ＳＣ３００に記憶されたユーザ証明書を、ＰＣ２００を介して取得する。制御部１２０は、ユーザ証明書に含まれるユーザ情報と記憶部１１０に記憶されたデバイス情報と公開鍵とを含む所定のフォーマット（例えば、ＰＫＣＳ（Public-Key Cryptography Standards）＃１０形式）のＣＳＲを生成する。例えば、ユーザ情報は、ユーザＺの電子メールアドレスや電話番号などである。ユーザを識別できる情報であれば、他の情報をユーザ情報として用いてもよい。制御部１２０は、記憶部１１０に記憶された秘密鍵を用いて、生成したＣＳＲにデジタル署名を付加する。ＣＳＲを、証明書署名要求と呼ぶこともある。
【００８１】
制御部１２０は、ＣＳＲに応じてＣＡサーバ９００により発行されたデジタル証明書を記憶部１１０に格納する。ここで、後述するように、ＳＤ１００が生成したＣＳＲにより発行されるデジタル証明書は、ユーザＺおよびＳＤ１００の組が真正であることを証明するものである。このため、当該デジタル証明書をＳＣ３００に格納されるユーザ証明書と区別するために、コンポジット証明書と称する。
【００８２】
制御部１２０は、当該コンポジット証明書を用いた認証において、サプリカントとしても機能する。ただし、サプリカントの機能を制御部１２０とは別個のモジュールとして設けてもよい。
【００８３】
ＰＣ２００は、記憶部２１０および制御部２２０を有する。記憶部２１０は、ＳＣ３００から制御部２２０により読み出されたユーザ証明書を記憶する。記憶部２１０は、ＲＡＭ２０２やＨＤＤ２０３の記憶領域を用いて実現できる。
【００８４】
ＰＣ２００は、記憶部２１０および制御部２２０を有する。記憶部２１０は、ＳＣ３００から読み取られたユーザ証明書や制御部２２０の処理に用いられる情報などを記憶する。記憶部２１０は、ＲＡＭ２０２やＨＤＤ２０３の記憶領域を用いて実現できる。
【００８５】
制御部２２０は、ＳＣ３００に記憶されているユーザ証明書を、リーダライタ装置２１を用いて取得し、記憶部２１０に格納する。制御部２２０は、ユーザ証明書をＳＤ１００に提供する。また、制御部２２０は、ＳＤ１００により生成されたＣＳＲを取得し、ＷｅｂＧＷサーバ４００に送信する。制御部２２０は、ＷｅｂＧＷサーバ４００にアクセスする前に、認証サーバ５００との間で、ＳＣ３００を用いたＴＬＳ認証を行う。
【００８６】
ＳＣ３００は、記憶部３１０および制御部３２０を有する。記憶部３１０は、ユーザＺのユーザ証明書および当該ユーザ証明書内の公開鍵に対応する秘密鍵を記憶する。記憶部３１０は、ＳＣ３００が有する所定の不揮発性メモリの記憶領域を用いて実現できる。制御部３２０は、ＰＣ２００からの要求に応じて、記憶部３１０に記憶されたユーザ証明書を提供する。
【００８７】
ＷｅｂＧＷサーバ４００は、記憶部４１０およびユーザ照合部４２０を有する。記憶部４１０は、ユーザ照合部４２０の照合処理に用いられる情報を記憶する。記憶部４１０は、ＷｅｂＧＷサーバ４００が備えるＲＡＭやＨＤＤなどの記憶領域を用いて実現できる。
【００８８】
ユーザ照合部４２０は、ＰＣ２００と認証サーバ５００との間の認証が成功すると、ＰＣ２００からＣＳＲを受信する。そして、ユーザ照合部４２０は、事前に行われた（ＳＣ３００を用いた）認証の中で認証サーバ５００が取得した（ユーザ証明書内の）ユーザ情報（例えば、電子メールアドレス）を取得する。ユーザ照合部４２０は、当該ユーザ情報と、ＣＳＲ内のユーザ情報とを照合する。ユーザ照合部４２０は、照合に成功すると当該ＣＳＲをＲＡサーバ８００に送信する。
【００８９】
認証サーバ５００は、記憶部５１０および認証部５２０を有する。記憶部５１０は、認証部５２０の認証処理に用いられる情報を記憶する。記憶部５１０は、認証サーバ５００が備えるＲＡＭやＨＤＤなどの記憶領域を用いて実現できる。
【００９０】
認証部５２０は、ＰＣ２００がＷｅｂＧＷサーバ４００にアクセスする際に、ユーザ証明書を用いた認証を行う。また、認証部５２０は、ＳＤ１００がネットワーク１０にアクセスする際にコンポジット証明書を用いた認証を行う。ＳＤ１００のコンポジット証明書は、アクセスポイント１１を介して認証サーバ５００に送信される。認証部５２０は、認証に成功した場合はＳＤ１００によるネットワーク１０へのアクセスを許容し、認証に失敗した場合はＳＤ１００によるネットワーク１０へのアクセスを拒否する。認証部５２０は、認証結果に応じたアクセス許否の指示をアクセスポイント１１に送る。
【００９１】
図６は、第２の実施の形態のデバイス情報の例を示す図である。デバイス情報１１１は、記憶部１１０に予め格納される。前述のように、デバイス情報１１１として、ＭＡＣアドレスが考えられる。具体的には、無線部１０４が通信に用いるＭＡＣアドレス“ｙｙ：ｙｙ：ｙｙ：ｙｙ：ｙｙ：ｙｙ”である。また、例えば、デバイス情報１１１として、ＩＭＥＩが考えられる。具体的には、ＳＤ１００に固有の番号“ｘｘｘｘｘｘｘｘｘｘｘｘｘｘｘｘ”である。
【００９２】
図７は、第２の実施の形態のユーザ証明書の例を示す図である。ユーザ証明書５０は、ユーザＺに対して発行されたデジタル証明書である。ユーザ証明書５０は、記憶部３１０に格納されている。ユーザ証明書５０は、バージョン、シリアル番号、署名アルゴリズム、発行者、有効期間の開始、有効期間の終了、サブジェクト、公開鍵、ハッシュ化アルゴリズムおよびハッシュ値の項目を含む。
【００９３】
バージョンの項目には、ユーザ証明書５０の様式のバージョンが登録される。シリアル番号の項目には、ユーザ証明書５０のシリアル番号が登録される。署名アルゴリズムの項目には、ユーザ証明書５０にＣＡ（例えば、ＣＡサーバ９００）が付加したデジタル署名のアルゴリズムが登録される。発行者の項目には、発行したＣＡの名称が登録される。有効期間の開始の項目には、ユーザ証明書５０の有効期間の開始時が登録される。有効期間の終了の項目には、ユーザ証明書５０の有効期間の終了時が登録される。サブジェクトの項目には、ユーザ証明書５０に含まれる公開鍵（および当該公開鍵に対応する秘密鍵）の所有者（ユーザＺ）に関する情報が登録される。公開鍵の項目には、公開鍵が登録される。ハッシュ化アルゴリズムの項目には、ＣＡが用いたハッシュ化アルゴリズムが登録される。ハッシュ値の項目には、ＣＡが生成したユーザ証明書５０のハッシュ値が登録される。
【００９４】
例えば、ユーザ証明書５０には、バージョンが“Ｖ３”、シリアル番号が“０１”、署名アルゴリズムが“ｓｈａ１ＲＳＡ”、発行者が“ＣＡ１”、有効期間の開始が“２０１３／３／２１  ００：００”、有効期間の終了が“２０１５／３／２１  ２３：５９”、サブジェクトが“Ｃ（Country）＝ｊｐ、Ｏ（Organization）＝ｇｒｏｕｐＦ、ＣＮ（Common Name）＝ＦＵＪＩ  ＴＡＲＯ、Ｅｍａｉｌ＝ａｂｃ＠ｘｙｚ．ｃｏｍ”、公開鍵が“ＰｕｂＫｅｙ１”、ハッシュ化アルゴリズムが“ｓｈａ１”、ハッシュ値が“Ｈ１”という情報が登録される。
【００９５】
これは、ユーザ証明書５０の様式のバージョンが“３”、シリアル番号が“０１”、認証局“ＣＡ１”によるデジタル署名のアルゴリズムが“ｓｈａ１ＲＳＡ”であることを示す。また、ユーザ証明書５０の有効期間が“２０１３／３／２１  ００：００”から“２０１５／３／２１  ２３：５９”までであり、公開鍵が“ＰｕｂＫｅｙ１”であることを示す。また、認証局“ＣＡ１”のハッシュ化アルゴリズムが“ｓｈａ１”であり、認証局“ＣＡ１”がユーザ証明書５０に対して生成したハッシュ値が“Ｈ１”であることを示す。更に、ユーザ証明書５０が、サブジェクトで示される上記属性（国“ｊｐ”、組織“ｇｒｏｕｐＦ”、氏名“ＦＵＪＩ  ＴＡＲＯ”、電子メールアドレス“ａｂｃ＠ｘｙｚ．ｃｏｍ”）をもつユーザＺに対して発行されたものであることを示す。
【００９６】
図８は、第２の実施の形態のＣＳＲの例を示す図である。ＣＳＲ６０は、制御部１２０により生成されるコンポジット証明書の発行要求の例である。ＣＳＲ６０は、デバイス情報およびユーザ情報を含む。以下、ＣＳＲ６０に記述された内容を、ＣＳＲ６０に付した行番号を用いて説明する。
【００９７】
１行目は、以下の記述がＣＳＲであることを示す。２行目〜７行目は、コンポジット証明書の発行要求元（公開鍵に対応する秘密鍵の所有主体）に関する情報が設定されている。具体的には、４行目には、国（Ｃ＝ｊｐ）、組織（Ｏ＝ｇｒｏｕｐＦ）が設定されている。５行目には、ＳＤ１００のＩＭＥＩ（ＯＵ＝ＩＭＥＩ−ｘｘｘｘｘｘｘｘｘｘｘｘｘｘｘｘ）が設定されている。６行目には、ＳＤ１００のＭＡＣアドレス（ＯＵ＝ＭＡＣ−ｙｙ：ｙｙ：ｙｙ：ｙｙ：ｙｙ：ｙｙ）が設定されている。７行目には、ユーザ名（ＣＮ＝ＦＵＪＩ  ＴＡＲＯ）および電子メールアドレス（Ｅｍａｉｌ＝ａｂｃ＠ｘｙｚ．ｃｏｍ）が設定されている。８行目〜１３行目には、公開鍵“ＰｕｂＫｅｙ２”の情報（公開鍵そのものも含む）が設定されている。１４行目〜２４行目には、ＣＳＲのその他の属性が設定されている。行番号２５には署名アルゴリズムが設定されている。
【００９８】
図９は、第２の実施の形態のコンポジット証明書の例を示す図である。コンポジット証明書７０は、ＣＳＲ６０に応じてＣＡサーバ９００により生成されたデジタル証明書である。コンポジット証明書７０は、ＳＤ１００に提供され、記憶部１１０に格納される。コンポジット証明書７０は、バージョン、シリアル番号、署名アルゴリズム、発行者、有効期間の開始、有効期間の終了、サブジェクト、公開鍵、ハッシュ化アルゴリズムおよびハッシュ値の項目を含む。
【００９９】
各項目に設定される内容は、ユーザ証明書５０の同名の項目と同様である。ただし、サブジェクトの項目に、コンポジット証明書７０に含まれる公開鍵（および当該公開鍵に対応する秘密鍵）の所有者（ユーザＺおよびＳＤ１００の組）に関する情報が登録される点が、ユーザ証明書５０と異なる。
【０１００】
例えば、コンポジット証明書７０には、バージョンが“Ｖ３”、シリアル番号が“０２”、署名アルゴリズムが“ｓｈａ１ＲＳＡ”、発行者が“ＣＡ１”、有効期間の開始が“２０１３／４／２１  ００：００”、有効期間の終了が“２０１５／４／２１  ２３：５９”、サブジェクトが“Ｃ＝ｊｐ、Ｏ＝ｇｒｏｕｐＦ、ＯＵ＝ＩＭＥＩ−ｘｘｘｘｘｘｘｘｘｘｘｘｘｘｘｘ、ＯＵ＝ＭＡＣ−ｙｙ：ｙｙ：ｙｙ：ｙｙ：ｙｙ：ｙｙ、ＣＮ＝ＦＵＪＩ  ＴＡＲＯ、Ｅｍａｉｌ＝ａｂｃ＠ｘｙｚ．ｃｏｍ”、公開鍵が“ＰｕｂＫｅｙ２”、ハッシュ化アルゴリズムが“ｓｈａ１”、ハッシュ値が“Ｈ２”という情報が登録される。
【０１０１】
これは、コンポジット証明書７０の様式のバージョンが“３”、シリアル番号が“０２”、認証局“ＣＡ１”によるデジタル署名のアルゴリズムが“ｓｈａ１ＲＳＡ”であることを示す。また、コンポジット証明書７０の有効期間が“２０１３／４／２１  ００：００”から“２０１５／４／２１  ２３：５９”までであり、公開鍵が“ＰｕｂＫｅｙ２”であることを示す。また、認証局“ＣＡ１”のハッシュ化アルゴリズムが“ｓｈａ１”であり、認証局“ＣＡ１”がコンポジット証明書７０に対して生成したハッシュ値が“Ｈ２”であることを示す。更に、コンポジット証明書７０が、サブジェクトで示される上記属性（国“ｊｐ”、組織“ｇｒｏｕｐＦ”、ＩＭＥＩ“ｘｘｘｘｘｘｘｘｘｘｘｘｘｘｘｘ”、ＭＡＣアドレス“ｙｙ：ｙｙ：ｙｙ：ｙｙ：ｙｙ：ｙｙ”、氏名“ＦＵＪＩ  ＴＡＲＯ”、電子メールアドレス“ａｂｃ＠ｘｙｚ．ｃｏｍ”）をもつユーザＺおよびＳＤ１００の組み合わせに対して発行されたものであることを示す。
【０１０２】
図１０は、第２の実施の形態の認証テーブルの例を示す図である。認証テーブル５１１は、記憶部５１０に予め格納される。認証テーブル５１１は、電子メールアドレス、ＩＭＥＩ、ＭＡＣアドレスの項目を含む。電子メールアドレスの項目には、ユーザの電子メールアドレスが登録される。ＩＭＥＩの項目には、ＳＤ１００のＩＭＥＩが登録される。ＭＡＣアドレスの項目には、ＳＤ１００のＭＡＣアドレスが登録される。
【０１０３】
例えば、認証テーブル５１１には、電子メールアドレスが“ａｂｃ＠ｘｙｚ．ｃｏｍ”、ＩＭＥＩが“ｘｘｘｘｘｘｘｘｘｘｘｘｘｘｘｘ”、ＭＡＣアドレスが“ｙｙ：ｙｙ：ｙｙ：ｙｙ：ｙｙ：ｙｙ”という情報が登録される。電子メールアドレス“ａｂｃ＠ｘｙｚ．ｃｏｍ”はユーザＺの電子メールアドレスである。ＩＭＥＩ“ｘｘｘｘｘｘｘｘｘｘｘｘｘｘｘｘ”およびＭＡＣアドレス“ｙｙ：ｙｙ：ｙｙ：ｙｙ：ｙｙ：ｙｙ”はＳＤ１００の識別情報である。認証テーブル５１１の当該レコードは、ユーザＺとＳＤ１００との組に対して、ネットワーク１０に対するアクセスを許容することを示している。
【０１０４】
なお、認証テーブル５１１には、ネットワーク１０に対するアクセス権限だけでなく、ユーザとデバイスとの組み合わせに応じた種々のアクセス権限を設定することができる。例えば、ユーザとデバイスとの組み合わせに応じて、アクセス許可するネットワークを複数設定してもよい。また、ユーザとデバイスとの組み合わせに応じて、アクセス許可するサーバコンピュータ、アプリケーションおよびファイルサーバ上のディレクトリなどを設定することも考えられる。
【０１０５】
図１１は、第２の実施の形態のＣＳＲ生成の例を示すフローチャートである。以下、図１１に示す処理をステップ番号に沿って説明する。
（Ｓ１１）制御部２２０は、リーダライタ装置２１を用いてＳＣ３００に格納されたユーザ証明書５０を取得し、記憶部２１０に格納する。
【０１０６】
（Ｓ１２）制御部１２０は、ＰＣ２００からユーザ証明書を取得する。例えば、ＳＤ１００とＰＣ２００とをＵＳＢケーブルなどで接続していれば、制御部１２０は、記憶部２１０に格納されたユーザ証明書５０を取得できる。また、制御部１２０は、メモリカード１２などを介して、ユーザ証明書５０をＰＣ２００から取得してもよい。
【０１０７】
（Ｓ１３）制御部１２０は、秘密鍵と公開鍵とのペア（鍵ペア）を生成する。制御部１２０は、生成した鍵ペアを記憶部１１０の所定の記憶域に格納する。
（Ｓ１４）制御部１２０は、ユーザ証明書５０、ステップＳ１３で生成した公開鍵および記憶部１１０に記憶されたデバイス情報１１１に基づいて、ＣＳＲ６０を生成する。具体的には、制御部１２０はユーザ証明書５０から抽出したユーザ情報（ＣＮやＥｍａｉｌなど）をＣＳＲ６０に設定する。また、制御部１２０は、デバイス情報１１１をＣＳＲ６０に設定する。更に、制御部１２０は、ステップＳ１３で生成した公開鍵をＣＳＲ６０に設定する。
【０１０８】
（Ｓ１５）制御部１２０は、ステップＳ１３で生成した秘密鍵を用いてＣＳＲ６０にデジタル署名する。具体的には、制御部１２０は、所定のハッシュ関数にＣＳＲ６０を入力することでハッシュ値を生成し、当該ハッシュ値を秘密鍵で暗号化したもの（デジタル署名）をＣＳＲ６０に付与する。制御部１２０は、署名済のＣＳＲ６０をＰＣ２００に提供する。例えば、ＳＤ１００とＰＣ２００とをＵＳＢケーブルなどで接続していれば、制御部１２０は、ＣＳＲ６０をＰＣ２００に提供できる。あるいは、制御部１２０は、メモリカード１２などを介して、ＣＳＲ６０をＰＣ２００に提供してもよい。
【０１０９】
（Ｓ１６）制御部２２０は、ＳＤ１００により署名されたＣＳＲ６０（以下、単にＣＳＲ６０という）を取得する。制御部２２０は取得したＣＳＲ６０を用いてコンポジット証明書の申請を行う。
【０１１０】
図１２は、第２の実施の形態の証明書申請の例を示すフローチャートである。以下、図１２に示す処理をステップ番号に沿って説明する。
（Ｓ２１）制御部２２０は、ＷｅｂＧＷサーバ４００が提供するＣＳＲ申請用のＧＵＩのＵＲＬに対してＷｅｂアクセスを試みる。当該アクセスは、認証サーバ５００が提供するユーザ認証用のＷｅｂページ（認証ページ）へリダイレクトされる。制御部２２０は、リーダライタ装置２１を用いてＳＣ３００からユーザ証明書５０を取得する。制御部２２０は、認証サーバ５００との間で、ユーザ証明書５０を用いたＴＬＳ認証を行う。
【０１１１】
（Ｓ２２）認証部５２０は、ＰＣ２００からユーザ証明書５０を取得し、ユーザＺが真正のユーザであることを確認する。認証部５２０は、ユーザＺに対してＷｅｂＧＷサーバ４００へのアクセスが許可されているか否かを判定する。許可されていない場合、処理をステップＳ２３に進める。許可されている場合、認証部５２０はアクセス許可をＷｅｂＧＷサーバ４００に通知して、処理をステップＳ２４に進める。例えば、ＷｅｂＧＷサーバ４００へのアクセスを許可するユーザのリスト（認証テーブル５１１でもよい）を記憶部５１０に格納しておく。認証部５２０は、当該リストを参照することで、ユーザＺがＷｅｂＧＷサーバ４００へのアクセスが許可されているか否かを判定できる。
【０１１２】
（Ｓ２３）認証部５２０は、アクセス拒否をＰＣ２００に通知する。この場合、ユーザ認証に失敗したことになる。そして、処理を終了する。
（Ｓ２４）ユーザ照合部４２０は、認証部５２０からユーザＺの電子メールアドレスを取得する。当該電子メールアドレスは、ステップＳ２２のユーザ認証に用いられたユーザ証明書５０に含まれているものである。
【０１１３】
（Ｓ２５）制御部２２０は、ＳＤ１００から取得したＣＳＲ６０をＷｅｂＧＷサーバ４００へ送信する。例えば、ユーザＺは、ＷｅｂＧＷサーバ４００が提供するＣＳＲ申請用のＧＵＩを操作して、ＣＳＲ６０をＷｅｂＧＷサーバ４００へアップロードできる。
【０１１４】
（Ｓ２６）ユーザ照合部４２０は、ステップＳ２４で取得した電子メールアドレスと、ステップＳ２５で取得されたＣＳＲ６０に含まれる電子メールアドレスとが一致するか否かを判定する。一致しない場合、処理をステップＳ２７に進める。一致する場合、処理をステップＳ２８に進める。
【０１１５】
（Ｓ２７）ユーザ照合部４２０は、ＣＳＲ６０を不受理扱いとする。この場合、ユーザ照合部４２０はＲＡサーバ８００に対するコンポジット証明書の申請は行わない。そして、処理を終了する。
【０１１６】
（Ｓ２８）ユーザ照合部４２０は、ＣＳＲ６０を受理扱いとする。ユーザ照合部４２０は、ＣＳＲ６０をＲＡサーバ８００に送信することで、コンポジット証明書の申請を行う。
【０１１７】
このように、ＷｅｂＧＷサーバ４００は、認証サーバ５００でのユーザ認証時に取得されたユーザ情報と、ＣＳＲ６０に含まれるユーザ情報とを照合して、ユーザ認証時のユーザと、ＣＳＲ６０を作成したユーザとが一致していることを確認する。これにより、ＣＳＲ６０の送信者が組織内の真正なユーザであることを確認できる。
【０１１８】
図１３は、第２の実施の形態の証明書発行の例を示すフローチャートである。以下、図１３に示す処理をステップ番号に沿って説明する。
（Ｓ３１）ＲＡサーバ８００は、ＣＳＲ６０に付加されたデジタル署名の検証を行う。ＲＡサーバ８００は、デジタル署名の検証に成功したか否かを判定する。失敗した場合、処理をステップＳ３２に進める。成功した場合、ＲＡサーバ８００はＣＳＲ６０をＣＡサーバ９００に送信して、処理をステップＳ３３に進める。具体的には、ＲＡサーバ８００は、ＣＳＲ６０に含まれる公開鍵で、デジタル署名を復号してハッシュ値を得る。また、ＲＡサーバ８００は、ＣＳＲ６０で指定されているハッシュ関数を用いて、ＣＳＲ６０のハッシュ値を生成する。両ハッシュ値が一致していれば、検証成功である。両ハッシュ値が異なっていれば、検証失敗である。
【０１１９】
（Ｓ３２）ＲＡサーバ８００は、ＣＳＲ６０を不受理と判断する。ＣＳＲ６０が不受理となった旨は、例えば、ＷｅｂＧＷサーバ４００などを介してＰＣ２００に通知される。そして、処理を終了する。
【０１２０】
（Ｓ３３）ＣＡサーバ９００は、ＲＡサーバ８００からＣＳＲ６０を受信する。ＣＡサーバ９００は、ＣＳＲ６０に基づいて、コンポジット証明書７０を発行する。
（Ｓ３４）ＣＡサーバ９００は、生成したコンポジット証明書７０をＷｅｂＧＷサーバ４００に送信する。
【０１２１】
このように、ＲＡサーバ８００およびＣＡサーバ９００はＣＳＲ６０に対してコンポジット証明書７０を生成する。
なお、ステップＳ３１において、ＲＡサーバ８００は、ＣＳＲ６０に含まれるユーザ情報の審査も行う。例えば、ユーザＺの氏名、電子メールアドレスおよび所属などが適正であるかを審査する。ＲＡサーバ８００は、当該審査によりＣＳＲ６０内の情報が適正と判断される場合に、ＣＡサーバ９００にＣＳＲ６０を送信する。
【０１２２】
また、第２の実施の形態の例では、ＲＡサーバ８００およびＣＡサーバ９００の２台で処理を分担する場合を例示しているが、ＲＡサーバ８００の機能をＣＡサーバ９００に統合してもよい。更に、ＲＡサーバ８００やＣＡサーバ９００を組織内のネットワークに設ける場合には、ＲＡサーバ８００およびＣＡサーバ９００の機能をＷｅｂＧＷサーバ４００に統合してもよい。
【０１２３】
図１４は、第２の実施の形態の証明書発行の例を示すシーケンス図である。以下、図１４に示す処理をステップ番号に沿って説明する。
（ＳＴ１０１）ＰＣ２００は、ユーザ証明書５０をＳＣ３００から取得する。ＰＣ２００は、ユーザ証明書５０をＳＤ１００に提供する。
【０１２４】
（ＳＴ１０２）ＳＤ１００は、ユーザ証明書５０に含まれるユーザ情報と自身のデバイス情報と自身の公開鍵を用いてＣＳＲ６０を生成する。ＳＤ１００は、当該公開鍵に対応する秘密鍵を用いてＣＳＲ６０に署名する（以下、ＣＳＲ６０という場合、署名済のものを指す）。
【０１２５】
（ＳＴ１０３）ＳＤ１００は、ＣＳＲ６０をＰＣ２００に送信する。ＰＣ２００は、ＣＳＲを受信する。
（ＳＴ１０４）ＰＣ２００は、ＷｅｂＧＷサーバ４００が提供するＣＳＲ申請用のＷｅｂページへのアクセスを試みる。当該アクセスは、ユーザ認証用のＷｅｂページにリダイレクトされる。ＰＣ２００は、認証サーバ５００との間でＳＣ３００内のユーザ証明書５０を用いたユーザ認証（ＴＬＳ認証）を行う。ＰＣ２００は、認証に成功するとＷｅｂＧＷサーバ４００が提供するＣＳＲ申請用のＷｅｂページにアクセス可能となる。ＷｅｂＧＷサーバ４００は、認証サーバ５００からユーザ証明書５０に含まれるユーザＺの電子メールアドレスを取得する。
【０１２６】
（ＳＴ１０５）ＰＣ２００は、ＷｅｂＧＷサーバ４００にＣＳＲ６０を送信する。例えば、ユーザＺは、上記ＣＳＲ申請用のＷｅｂページからＣＳＲ６０をＷｅｂＧＷサーバ４００にアップロードできる。
【０１２７】
（ＳＴ１０６）ＷｅｂＧＷサーバ４００は、ＣＳＲ６０に含まれる電子メールアドレスとステップＳＴ１０４で取得した電子メールアドレスとが一致していることを確認する（ユーザ検証）。
【０１２８】
（ＳＴ１０７）ＷｅｂＧＷサーバ４００は、ＲＡサーバ８００にＣＳＲ６０を送信することで、コンポジット証明書の発行を申請する。
（ＳＴ１０８）ＲＡサーバ８００は、ＣＳＲ６０のデジタル署名を検証し、ＣＳＲ６０が確かにユーザＺにより作成されたものであることを確認する。また、ＲＡサーバ８００は、ＣＳＲ６０に含まれるユーザ情報を審査する。
【０１２９】
（ＳＴ１０９）ＲＡサーバ８００は、審査の結果、問題がないことを確認すると、ＣＡサーバ９００にＣＳＲ６０を送信する。
（ＳＴ１１０）ＣＡサーバ９００は、ＣＳＲ６０に基づいて、コンポジット証明書７０を発行する。
【０１３０】
（ＳＴ１１１）ＣＡサーバ９００は、ＲＡサーバ８００を介して、ＷｅｂＧＷサーバ４００にコンポジット証明書７０を提供する。ＷｅｂＧＷサーバ４００は、ＰＣ２００を介して、ＳＤ１００にコンポジット証明書７０を提供する。ＳＤ１００は、コンポジット証明書７０を取得し、記憶部１１０に格納する。
【０１３１】
なお、ＷｅｂＧＷサーバ４００からＳＤ１００に対するコンポジット証明書７０の提供方法には種々の方法を採り得る。例えば、ＷｅｂＧＷサーバ４００は、ユーザＺ専用の所定のＷｅｂページを作成して、当該Ｗｅｂページからコンポジット証明書７０をダウンロード可能としてもよい。また、例えば、ＷｅｂＧＷサーバ４００は、ユーザＺの電子メールアドレス宛にコンポジット証明書７０を送信してもよい。これにより、ＷｅｂＧＷサーバ４００からＰＣ２００へコンポジット証明書７０が提供される。
【０１３２】
ＰＣ２００は、ＷｅｂＧＷサーバ４００からのダウンロードなどにより取得したコンポジット証明書７０を、ＰＣ２００とＵＳＢなどで接続されたＳＤ１００に送信する。または、ＰＣ２００上のコンポジット証明書７０をメモリカード１２に格納し、メモリカード１２をＳＤ１００に移し、メモリカード１２内のコンポジット証明書７０をＳＤ１００で読み取ってもよい。
【０１３３】
例えば、ＳＤ１００は、所定のフォーマット（ＰＫＣＳ＃１２など）を用いてコンポジット証明書７０を管理する。ＳＤ１００は、秘密鍵およびコンポジット証明書７０を専用の記憶域に保持する。例えば、当該記憶域は前述のようにＨＤＤ１０３などに設けた専用の記憶域でもよい。あるいは、ＳＤ１００に鍵格納用の耐タンパ性を有する記憶装置を設け、当該記憶装置に秘密鍵などを格納してもよい。次に、コンポジット証明書７０を用いた認証の手順を説明する。
【０１３４】
図１５は、第２の実施の形態の認証の例を示すフローチャートである。以下、図１５に示す処理をステップ番号に沿って説明する。
（Ｓ４１）制御部１２０は、アクセスポイント１１との接続を確立するための事前設定を行う。例えば、制御部１２０は、入力デバイス１０６を用いたユーザＺによる設定入力を受け付ける。例えば、ユーザＺは、入力デバイス１０６を操作して、アクセスポイント１１のＳＳＩＤ（Service Set IDentifier）、認証方式（ここでは、ＩＥＥＥ８０２．１ＸのＥＡＰ−ＴＬＳ）および認証時に用いるＩＤ（電子メールアドレス）の入力を行える。当該ＩＤは、コンポジット証明書７０に登録された電子メールアドレスと同じ電子メールアドレスとする。
【０１３５】
（Ｓ４２）制御部１２０は、アクセスポイント１１との間で、ＥＡＰ−ＴＬＳ認証を開始する。以後、ＳＤ１００とアクセスポイント１１との間でＥＡＰ、アクセスポイントと認証サーバ５００との間でＲＡＤＩＵＳ（ＥＡＰメッセージをカプセル化する）を用いて、ＥＡＰ−ＴＬＳの一連の手順が行われる。以降の各ステップでは、ＥＡＰ−ＴＬＳの一連の手順のうち、デジタル証明書が関係する処理に着目して説明する（一連の手順の詳細については後述する）。ＳＤ１００と認証サーバ５００との間の通信はアクセスポイント１１を介して行われる。
【０１３６】
（Ｓ４３）認証部５２０は、サーバ証明書を制御部１２０に送信する。
（Ｓ４４）制御部１２０は、サーバ証明書のデジタル署名を検証する。制御部１２０は、検証に成功すると、コンポジット証明書７０をＳＤ１００の秘密鍵で署名し、認証サーバ５００に送信する。
【０１３７】
（Ｓ４５）認証部５２０は、コンポジット証明書７０のデジタル署名を検証する。認証部５２０は、当該デジタル署名の検証により、ユーザＺとＳＤ１００との真正な組み合わせで認証要求がなされている（適正な認証要求である）ことを確認できる。認証要求が適正であれば、認証部５２０は、認証テーブル５１１を参照して、ユーザＺとＳＤ１００との組み合わせによるネットワーク１０へのアクセスが許可されているか否かを判定する。許可されている場合、処理をステップＳ４６に進める。許可されていない場合、処理をステップＳ４８に進める。
【０１３８】
（Ｓ４６）認証部５２０は、ＳＤ１００にアクセス許可を通知する。
（Ｓ４７）制御部１２０は、ＤＨＣＰサーバ６００からＩＰアドレスの割り当てを受ける。これにより、ＳＤ１００は、ネットワーク１０を介して、他の装置とのデータ通信を行えるようになる。そして、上記一連の認証処理は完了となる。
【０１３９】
（Ｓ４８）認証部５２０は、ＳＤ１００にアクセス不可を通知する。この場合、ＳＤ１００は、ネットワーク１０へのアクセスを行えないことになる。
なお、図１０で例示したように、認証テーブル５１１には、ユーザＺとＳＤ１００との組み合わせに対して種々のアクセス権限を付与することもできる。その場合、ステップＳ４５〜Ｓ４７において、ＳＤ１００は、認証テーブル５１１に登録されたアクセス権限を付与されることになる。次に、コンポジット証明書７０を用いたＥＡＰ−ＴＬＳ認証の具体的な流れを説明する。
【０１４０】
図１６は、第２の実施の形態の認証の例を示すシーケンス図である。以下、図１６に示す処理をステップ番号に沿って説明する。なお、以下の説明では、アクセスポイント１１を介して行われるＳＤ１００と認証サーバ５００との間の１つの手順を１つのステップで表すものとする。前述のように、ＳＤ１００とアクセスポイント１１との間の通信にはＥＡＰが用いられ、アクセスポイント１１と認証サーバ５００との間の通信にはＲＡＤＩＵＳが用いられる。
【０１４１】
（ＳＴ１２１）ＳＤ１００は、ＥＡＰｏＬ（EAP over LAN）の開始をアクセスポイント１１に通知する。
（ＳＴ１２２）アクセスポイント１１は、ＳＤ１００にＩＤを要求する。
【０１４２】
（ＳＴ１２３）ＳＤ１００は、アクセスポイント１１にＩＤを応答する。例えば、ＩＤは電子メールアドレスである。例えば、ユーザＺのＩＤは“ａｂｃ＠ｘｙｚ．ｃｏｍ”である。前述のように、当該ＩＤはユーザＺによりＳＤ１００に予め入力される。アクセスポイント１１は、受信したＩＤを認証サーバ５００に送信する。
【０１４３】
（ＳＴ１２４）認証サーバ５００はＴＬＳ認証の開始をＳＤ１００に通知する。認証サーバ５００は、当該ＩＤが認証テーブル５１１に登録されたＩＤであることを確認した上で、ＴＬＳ認証の開始をＳＤ１００に通知してもよい。
【０１４４】
（ＳＴ１２５）ＳＤ１００は、Ｃｌｉｅｎｔ  ｈｅｌｌｏメッセージを認証サーバ５００に送信する。当該メッセージには、セッションキー（共通鍵）生成用の乱数や暗号化アルゴリズムの候補などの情報も含まれる。
【０１４５】
（ＳＴ１２６）認証サーバ５００は、Ｓｅｒｖｅｒ  ｈｅｌｌｏメッセージとともに、サーバ証明書をＳＤ１００に送信する。認証サーバ５００は、サーバ証明書に加えて、当該サーバ証明書に対して署名した認証局のデジタル証明書（ルート証明書）を、ＳＤ１００に送信してもよい。また、本ステップＳＴ１２６で送信される情報には、セッションキー生成用の乱数や暗号化アルゴリズムの指定なども含まれる。ＳＤ１００は、当該サーバ証明書を受信すると、当該サーバ証明書のデジタル署名を検証する。
【０１４６】
（ＳＴ１２７）ＳＤ１００は、コンポジット証明書７０を認証サーバ５００に送信する。コンポジット証明書７０は、ＳＤ１００の秘密鍵により署名されている。ＳＤ１００は、コンポジット証明書７０とともに、セッションキー用のプレマスタシークレット（具体的には乱数。認証サーバ５００の公開鍵で暗号化される）やセッションキーの利用宣言、ＴＬＳ認証の完了なども通知する。ＳＤ１００からアクセスポイント１１に送信されるフレーム（Ｅｔｈｅｒｎｅｔ（登録商標）フレーム）には、ＳＤ１００のＭＡＣアドレスが含まれる。更に、アクセスポイント１１が認証サーバ５００に対して送信するフレームには、ＳＤ１００のＭＡＣアドレスが含まれる。
【０１４７】
（ＳＴ１２８）認証サーバ５００は、コンポジット証明書７０のデジタル署名を検証する。すなわち、認証サーバ５００は、ユーザＺとＳＤ１００との真正な組み合わせで認証要求がなされていることを確認する。また、認証サーバ５００は、ステップＳＴ１２３で取得したＩＤが、コンポジット証明書７０に含まれる電子メールアドレス（Ｅｍａｉｌ）の設定と一致していることを確認する。また、認証サーバ５００は、受信したフレーム内からＳＤ１００のＭＡＣアドレスを抽出し、コンポジット証明書７０に含まれるＭＡＣアドレスと一致していることを確認する。更に、認証サーバ５００は、認証テーブル５１１を参照して、当該電子メールアドレスとＭＡＣアドレスとの組み合わせが許可された組み合わせであることを確認する。
【０１４８】
（ＳＴ１２９）認証サーバ５００は、ＳＤ１００から得たプレマスタシークレットからセッションキーを生成し、当該セッションキーの利用宣言およびＥＡＰ−ＴＬＳ認証の完了をＳＤ１００に通知する。
【０１４９】
（ＳＴ１３０）ＳＤ１００は、認証サーバ５００が適正なセッションキーを使用していることを確認する。ＳＤ１００は、認証サーバ５００に認証完了を通知する。
（ＳＴ１３１）認証サーバ５００は、アクセスポイント１１に、ＲＡＤＩＵＳアクセスアクセプトパケットを送信する。当該パケットには、セッションキーの情報が含まれる。アクセスポイント１１は、ＥＡＰ−ＴＬＳ認証の完了をＳＤ１００に通知する。
【０１５０】
（ＳＴ１３２）アクセスポイント１１は、認証サーバ５００から取得したセッションキーを元にＷＥＰ（Wired Equivalent Privacy）キーを生成し、ＳＤ１００に送信する。以降、ＳＤ１００とアクセスポイント１１との通信はＷＥＰキーを用いて暗号化される。
【０１５１】
このようにして、認証サーバ５００は、ＳＤ１００に対し、コンポジット証明書７０を用いた認証を行う。
ここで、コンポジット証明書７０には有効期間が定められている。当該有効期間を過ぎると、コンポジット証明書７０を用いた認証を行えなくなる。このため、ユーザＺは、ＳＤ１００を用いてコンポジット証明書の再発行依頼を行うことになる。次に、当該再発行依頼時のＣＳＲの作成手順を説明する。
【０１５２】
図１７は、第２の実施の形態の証明書の更新例を示すフローチャートである。以下、図１７に示す処理をステップ番号に沿って説明する。
（Ｓ５１）制御部１２０は、コンポジット証明書７０の有効期間の更新指示を受け付ける。例えば、コンポジット証明書７０の更新指示は、ユーザＺによる操作入力によりＳＤ１００に与えられる。
【０１５３】
（Ｓ５２）制御部１２０は、秘密鍵と公開鍵とのペア（鍵ペア）を生成する。制御部１２０は、生成した鍵ペアを記憶部１１０の所定の記憶域に格納する。
（Ｓ５３）制御部１２０は、コンポジット証明書７０およびステップＳ５２で生成した公開鍵に基づいてＣＳＲを生成する。当該ＣＳＲの内容は、ＣＳＲ６０の内容と同様である。
【０１５４】
（Ｓ５４）制御部１２０は、ステップＳ５２で生成した秘密鍵を用いて、ＣＳＲにデジタル署名する。
（Ｓ５５）制御部１２０は、署名済のＣＳＲをＷｅｂＧＷサーバ４００に送信する。この場合、ＷｅｂＧＷサーバ４００および認証サーバ５００は、図１２で例示したようにＰＣ２００と同様の認証をＳＤ１００に対して行ってもよい。その場合、当該認証に、コンポジット証明書７０を用いることができる。例えば、ＷｅｂＧＷサーバ４００は、コンポジット証明書７０に含まれる電子メールアドレスと、新たに受け付けたＣＳＲに含まれる電子メールアドレスとの一致を確認した上で、当該ＣＳＲをＲＡサーバ８００に送信する。
【０１５５】
このようにして、ＳＤ１００は、既に発行済みのコンポジット証明書７０を利用して、新しいコンポジット証明書の再発行要求を行える。このとき、ＳＤ１００は、コンポジット証明書を保持しているので、ＣＳＲを生成するためにＰＣ２００からユーザ情報を取得しなくてよい。また、ＳＤ１００は、コンポジット証明書７０を用いてネットワーク１０へアクセス可能なので、ＰＣ２００を介さなくても、新しいコンポジット証明書の再発行要求を行える。
【０１５６】
以上のように、第２の実施の形態では、コンポジット証明書７０を用いてユーザＺおよびＳＤ１００の組を一括して認証できる。このため、ユーザＺおよびＳＤ１００の認証を別個に行うよりも、ユーザＺとＳＤ１００との両方を効率的に認証できる。特に、ユーザ情報およびデバイス情報はコンポジット証明書７０に格納されており、これらの情報を認証に利用できる。このため、ユーザ情報やデバイス情報をユーザＺにより個別にキー入力させて認証を行うよりも、ユーザＺの認証時の操作負担を軽減できる。
【０１５７】
また、小型のデバイスには、ＳＤ１００のようにＳＣ３００を直接挿入して読み取れるインタフェースをもたないものがある。ＳＤ１００は、屋外に持ち出して利用されることも多く、ネットワーク１０にアクセスしたいときにユーザＺがリーダライタ装置を持ち合わせていないことも多い。そこで、上記のように、認証を受けたいＳＤ１００にコンポジット証明書７０を格納しておけば、屋外のアクセスポイントを介してネットワーク１０にアクセスしたいときにも便利である。
【０１５８】
また、新しいコンポジット証明書の再発行を申請する際にも、ＳＤ１００が保有するコンポジット証明書７０を利用することで、ＳＤ１００単体により、容易に再発行要求（ＣＳＲ）を生成できる。すなわち、ＰＣ２００と連携させなくてもＣＳＲを生成でき、ユーザの手間を軽減できる。
【０１５９】
なお、第２の実施の形態では、コンポジット証明書７０を利用する認証方式として、ＥＡＰ−ＴＬＳを例示したが、ＥＡＰ−ＴＬＳ以外の認証方式にコンポジット証明書７０を利用することを妨げるものではない。コンポジット証明書７０は、ＰＫＩの仕組みによる他の認証方式にも利用できる。
【０１６０】
［第３の実施の形態］
次に、第３の実施の形態を説明する。前述の第２の実施の形態と相違する事項を主に説明し、共通する事項の説明を省略する。
【０１６１】
第２の実施の形態では、ＳＤ１００でＣＳＲ６０を生成するものとした。これに対し、ＰＣ２００が、ＳＤ１００の代わりに、ＣＳＲ６０を生成してもよい。第３の実施の形態では、この機能を提供する。
【０１６２】
ここで、第３の実施の形態の情報処理システムは、図２で説明した第２の実施の形態の情報処理システムと同様である。第３の実施の形態の各装置のハードウェアおよびソフトウェアは図３〜５で説明した各装置のハードウェアおよびソフトウェアと同様である。そこで、第３の実施の形態でも、第２の実施の形態と同様の名称および符号を用いる。第３の実施の形態では、ＰＣ２００の記憶部２１０は、ＳＤ１００の情報を記憶する。
【０１６３】
図１８は、第３の実施の形態のデバイス管理テーブルの例を示す図である。デバイス管理テーブル２１１は、記憶部２１０に格納される。デバイス管理テーブル２１１は、ＩＭＥＩ、ＭＡＣアドレスの項目を含む。ＩＭＥＩの項目には、ＳＤ１００のＩＭＥＩが登録される。ＭＡＣアドレスの項目には、ＳＤ１００のＭＡＣアドレスが登録される。
【０１６４】
例えば、デバイス管理テーブル２１１には、ＩＭＥＩが“ｘｘｘｘｘｘｘｘｘｘｘｘｘｘｘｘ”、ＭＡＣアドレスが“ｙｙ：ｙｙ：ｙｙ：ｙｙ：ｙｙ：ｙｙ”という情報が登録されている。例えば、ユーザＺは、入力デバイス２３を操作して、ＳＤ１００のＩＭＥＩやＭＡＣアドレスをデバイス管理テーブル２１１に登録できる。
【０１６５】
図１９は、第３の実施の形態のＣＳＲ生成の例を示すフローチャートである。以下、図１９に示す処理をステップ番号に沿って説明する。
（Ｓ６１）制御部２２０は、リーダライタ装置２１を用いてＳＣ３００に格納されたユーザ証明書５０を取得し、記憶部２１０に格納する。
【０１６６】
（Ｓ６２）制御部２２０は、秘密鍵と公開鍵とのペア（鍵ペア）を生成する。
（Ｓ６３）制御部２２０は、ユーザ証明書５０、ステップＳ６２で生成した公開鍵およびデバイス管理テーブル２１１に登録されたデバイス情報に基づいて、ＣＳＲ６０を生成する。具体的には、制御部２２０はユーザ証明書５０から抽出したユーザ情報（ＣＮやＥｍａｉｌなど）をＣＳＲ６０に設定する。また、制御部２２０は、デバイス情報をＣＳＲ６０に設定する。更に、制御部２２０は、ステップＳ６２で生成した公開鍵をＣＳＲ６０に設定する。
【０１６７】
（Ｓ６４）制御部２２０は、ステップＳ６２で生成した秘密鍵を用いてＣＳＲ６０にデジタル署名する。具体的には、制御部２２０は、所定のハッシュ関数にＣＳＲ６０を入力することでハッシュ値を生成し、当該ハッシュ値を秘密鍵で暗号化したもの（デジタル署名）をＣＳＲ６０に付与する。
【０１６８】
（Ｓ６５）制御部２２０は、ＷｅｂＧＷサーバ４００へのアクセスを試みる。当該アクセスは、認証サーバ５００にリダイレクトされ、ユーザ証明書５０を用いたＴＬＳ認証が行われる。制御部２２０は、当該認証に成功すると、ＷｅｂＧＷサーバ４００にアクセス可能となる。
【０１６９】
（Ｓ６６）制御部２２０は、署名済のＣＳＲ６０をＷｅｂＧＷサーバ４００に送信する。すると、ＷｅｂＧＷサーバ４００は、図１２で説明したように、ユーザ証明書５０に含まれる電子メールアドレスと、ＣＳＲ６０に含まれる電子メールアドレスとの一致を確認した上で、ＣＳＲ６０をＲＡサーバ８００に送信する。
【０１７０】
以降の処理は、図１３〜１６で説明した通りである。ただし、制御部２２０は、ステップＳ６２で生成した秘密鍵をＳＤ１００に提供する。あるいは、ステップＳ６２では、制御部２２０で鍵ペアを生成する代わりに、ＳＤ１００で生成された鍵ペアを取得してもよい。ＳＤ１００は、秘密鍵を所定の記憶域に保持する。このように、ＳＤ１００の代わりに、ＰＣ２００がＣＳＲ６０を生成することもできる。
【０１７１】
［第４の実施の形態］
次に、第４の実施の形態を説明する。前述の第２の実施の形態と相違する事項を主に説明し、共通する事項の説明を省略する。
【０１７２】
第４の実施の形態では、コンポジット証明書７０をＴＬＳ認証に用いる例を説明する。ここで、第４の実施の形態の情報処理システムは、図２で説明した第２の実施の形態の情報処理システムと同様である。第４の実施の形態の各装置のハードウェアおよびソフトウェアは図３〜５で説明した各装置のハードウェアおよびソフトウェアと同様である。そこで、第４の実施の形態でも、第２の実施の形態と同様の名称および符号を用いる。ただし、第４の実施の形態では、ＳＤ１００は、ネットワーク１０に予めアクセス可能である。認証サーバ５００は、ＳＤ１００に対してコンポジット証明書７０を用いたＴＬＳ認証を行う。
【０１７３】
図２０は、第４の実施の形態の認証の例を示すシーケンス図である。以下、図２０に示す処理をステップ番号に沿って説明する。
（ＳＴ１４１）ＳＤ１００は、業務サーバ７００が提供するログイン画面のＵＲＬを指定したＨＴＴＰ（HyperText Transfer Protocol）リクエストを業務サーバ７００に送信する。
【０１７４】
（ＳＴ１４２）業務サーバ７００は、認証サーバ５００をリダイレクト先に指定し、ログイン画面をＳＤ１００に応答する。
（ＳＴ１４３）ＳＤ１００は、認証サーバ５００にＨＴＴＰＳ（HTTP over SSL）での接続要求を行う。当該接続要求には、ユーザＺにより入力されたＩＤ（電子メールアドレス）が含まれる。
【０１７５】
（ＳＴ１４４）認証サーバ５００は、ＳＤ１００にＨＴＴＰＳの接続許可を応答する（ＴＬＳ認証の開始通知）。
（ＳＴ１４５）ＳＤ１００は、Ｃｌｉｅｎｔ  ｈｅｌｌｏメッセージを認証サーバ５００に送信する。当該メッセージには、セッションキー（共通鍵）生成用の乱数や暗号化アルゴリズムの候補などの情報も含まれる。
【０１７６】
（ＳＴ１４６）認証サーバ５００は、Ｓｅｒｖｅｒ  ｈｅｌｌｏメッセージとともに、サーバ証明書をＳＤ１００に送信する。認証サーバ５００は、サーバ証明書に加えて、当該サーバ証明書に対して署名した認証局のデジタル証明書（ルート証明書）を、ＳＤ１００に送信してもよい。また、本ステップＳＴ１４６で送信される情報には、セッションキー生成用の乱数や暗号化アルゴリズムの指定なども含まれる。ＳＤ１００は、当該サーバ証明書を受信すると、当該サーバ証明書のデジタル署名を検証する。
【０１７７】
（ＳＴ１４７）ＳＤ１００は、コンポジット証明書７０を認証サーバ５００に送信する。コンポジット証明書７０は、ＳＤ１００の秘密鍵により署名されている。ＳＤ１００は、コンポジット証明書７０とともに、セッションキー用のプレマスタシークレット（具体的には乱数。認証サーバ５００の公開鍵で暗号化される）やセッションキーの利用宣言、ＴＬＳ認証の完了なども通知する。
【０１７８】
（ＳＴ１４８）認証サーバ５００は、コンポジット証明書７０のデジタル署名を検証する。すなわち、認証サーバ５００は、ユーザＺとＳＤ１００との真正な組み合わせで認証要求がなされていることを確認する。また、認証サーバ５００は、ステップＳＴ１４３で取得したＩＤが、コンポジット証明書７０に含まれる電子メールアドレス（Ｅｍａｉｌ）の設定と一致していることを確認する。更に、認証サーバ５００は、認証テーブル５１１を参照して、当該電子メールアドレスがアクセス許可されたものである（認証テーブル５１１に当該電子メールアドレスが登録されている）ことを確認する。
【０１７９】
（ＳＴ１４９）認証サーバ５００は、ＳＤ１００から得たプレマスタシークレットからセッションキーを生成し、当該セッションキーの利用宣言およびＴＬＳ認証の完了をＳＤ１００に通知する。
【０１８０】
（ＳＴ１５０）ＳＤ１００は、業務サーバ７００と交換した共通鍵を用いて暗号通信を行う。
このように、コンポジット証明書７０をＴＬＳ認証に用いることもできる。このとき、ステップＳＴ１４８で例示したように、ＭＡＣアドレスの認証を省略してもよい。ただし、ステップＳＴ１４８においてユーザＺの権限などに応じてＭＡＣアドレスの認証を行うようにしてもよい。
【０１８１】
なお、第２〜第４の実施の形態の説明では、ユーザＺを識別するためのＩＤとして、電子メールアドレスを用いる場合を主に例示したが、他の情報をＩＤとして用いてもよい。例えば、ユーザＺの電話番号やユーザＺに付与された所定の識別記号などをＩＤとして用いることも考えられる。
【０１８２】
ところで、前述のように、第１の実施の形態の情報処理は、演算部１ｂ，２ｂにプログラムを実行させることで実現できる。また、第２〜第４の実施の形態の情報処理は、ＳＤ１００、ＰＣ２００が備えるプロセッサ１０１，２０１にプログラムを実行させることで実現できる。プログラムは、コンピュータ読み取り可能な記録媒体（例えば、光ディスク、メモリ装置およびメモリカードなど）に記録できる。
【０１８３】
例えば、プログラムを記録した記録媒体を配布することで、プログラムを流通させることができる。また、プログラムを他のコンピュータに格納しておき、ネットワーク経由でプログラムを配布してもよい。例えば、ＳＤ１００は、記録媒体に記録されたプログラムまたは他のコンピュータからダウンロードしたプログラムを、ＲＡＭ１０２やフラッシュメモリ１０３などの記憶装置に格納する（インストール）。プロセッサ１０１は、当該記憶装置からプログラムを読み込んで実行することで、制御部１２０の機能を発揮できる。
【符号の説明】
【０１８４】
１  証明書発行要求生成装置
１ａ，２ａ  記憶部
１ｂ，２ｂ  演算部
２  情報処理装置
３  証明書発行装置
３ａ  受信部
３ｂ  発行部
４  認証装置
５  ネットワーク
６  記憶媒体
７  ゲートウェイ装置
Ａ  ユーザ
Ｃ  発行要求
Ｃ１  ユーザ情報
Ｃ２  装置情報
Ｋ１，Ｋ２  暗号鍵
Ａ１  証明書
Ａ１ｓ  署名データ
Ｘ  ユーザ証明書
【図１】
2015039141.tif 000003
【図２】
2015039141.tif 000004
【図３】
2015039141.tif 000005
【図４】
2015039141.tif 000006
【図５】
2015039141.tif 000007
【図６】
2015039141.tif 000008
【図７】
2015039141.tif 000009
【図８】
2015039141.tif 000010
【図９】
2015039141.tif 000011
【図１０】
2015039141.tif 000012
【図１１】
2015039141.tif 000013
【図１２】
2015039141.tif 000014
【図１３】
2015039141.tif 000015
【図１４】
2015039141.tif 000016
【図１５】
2015039141.tif 000017
【図１６】
2015039141.tif 000018
【図１７】
2015039141.tif 000019
【図１８】
2015039141.tif 000020
【図１９】
2015039141.tif 000021
【図２０】
2015039141.tif 000022