JP2007334753A - アクセス管理システムおよび方法 - Google Patents

Abstract

【課題】ネットワーク接続された家庭内の装置のセキュリティ管理を低コストで実現することのできるアクセス管理システムを提供する。
【解決手段】プロキシサーバ１３に対して認証機関１４からプロキシ証明書の発行を受ける。ネットワーク１０を介したアクセスの可否の検証に用いるためのユーザ証明書を、ユーザ宅内装置１１の自己署名によって作成する。アクセス端末１２からプロキシサーバ１３に対してユーザ宅内装置１１への接続が要求されると、プロキシサーバ１３とアクセス端末１２の間ではプロキシ証明書を用いた検証を行って通信路を確立し、プロキシサーバ１３とユーザ宅内装置１１の間ではユーザ証明書を用いた検証を行って通信路を確立する。アクセス端末１２とユーザ宅内装置１１の間の通信をそれらの通信路を用いてプロキシサーバで中継する。
【選択図】図１

Description

本発明は、ネットワーク上のセキュリティ保護の技術に関し、特に、家庭内に設置された外部からアクセス可能なサーバのセキュリティを保護する技術に関する。

インターネットに代表されるネットワークの発展と普及に伴い、家庭内の様々な機器が通信機能を備えるようになってきている。そして、通信機能を有する様々な機器を接続するために家庭にサーバを導入するシステムの需要が高まっている。例えば、ＨＤＤ（Ｈａｒｄ Ｄｉｓｋ Ｄｒｉｖｅ）レコーダやビデオカメラによって撮り貯めたビデオ画像を集積するためにビデオサーバを導入するというものがある。他の例として、防犯カメラや電気錠の状態や設定などを管理するホームセキュリティサーバを導入するものがある。さらに他の例として、風呂の湯沸し、電動雨戸、室内照明等の制御を行うホームオートメーションサーバを導入するというものがある。家庭内に外部からアクセスすることのできるサーバを導入すれば、外出先からサーバにアクセスし、家庭内の各機器の状態を調べたり、各機器を制御したりできて便利である。

このように家庭内にサーバを導入し、外部からアクセスできるようにすることによって家庭の様々な事が便利になるが、その一方で、セキュリティ上の脅威に晒されるという面がある。例えば、外部からのアクセスで送受信される情報を第三者に盗聴さされる恐れがある。また、それによって不正に取得された情報が、サーバへの不正アクセスやなりすまし（フィッシングなど）など他の犯罪に利用される可能性もある。

ネットワーク上のセキュリティ保護について、これまでにも様々な方法が提案されている（例えば、非特許文献１〜３参照）。例えば暗号化技術を利用して盗聴を防止し、また、電子署名技術を利用して不正アクセスやなりすましを防止するというものがある。

非特許文献１には、ＴＬＳ（Ｔｒａｎｓｐｏｒｔ Ｌａｙｅｒ Ｓｅｃｕｒｉｔｙ）プロトコルが規定されている。ＴＬＳプロトコルは、ＩＥＴＦで標準化されたプロトコルであり、インターネット上で情報を暗号化して送受信するのに用いられる。また、非特許文献２にはＳＳＬ（Ｓｅｃｕｒｅ Ｓｏｃｋｅｔｓ Ｌａｙｅｒ）２が開示され、非特許文献３にはＳＳＬ３が開示されている。これらＳＳＬ２、ＳＳＬ３は、ＴＬＳの基礎となったプロトコルであり、デファクトスタンダードとして広く利用されている。
ＲＦＣ２２４６ Ｔｈｅ ＴＬＳ Ｐｒｏｔｏｃｏｌ Ｖｅｒｓｉｏｎ１．０． Ｔ．Ｄｉｅｒｋｓ， Ｃ．Ａｌｌｅｎ． Ｊａｎｕａｒｙ １９９９．、［ｏｎｌｉｎｅ］、［平成１８年４月５日検索］、インターネット＜ＵＲＬ： http://www.ietf.org/rfc/rfc2246.txt＞ Ｈｉｃｋｍａｎ，Ｋｉｐｐ， "Ｔｈｅ ＳＳＬ Ｐｒｏｔｏｃｏｌ"，Ｎｅｔｓｃａｐｅ Ｃｏｍｍｕｎｉｃａｔｉｏｎｓ Ｃｏｒｐ．，Ｆｅｂ．９，１９９５．、［ｏｎｌｉｎｅ］、［平成１８年４月５日検索］、インターネット＜ＵＲＬ： http://wp.netscape.com/eng/security/SSL_2.html＞ Ａ．Ｆｒｉｅｒ， Ｐ．Ｋａｒｌｔｏｎ， ａｎｄ Ｐ．Ｋｏｃｈｅｒ，"Ｔｈｅ ＳＳＬ３．０ Ｐｒｏｔｏｃｏｌ"，Ｎｅｔｓｃａｐｅ Ｃｏｍｍｕｎｉｃａｔｉｏｎｓ Ｃｏｒｐ．，Ｎｏｖ．１８，１９９６．、［ｏｎｌｉｎｅ］、［平成１８年４月５日検索］、インターネット＜ＵＲＬ： http://wp.netscape.com/eng/ssl3/draft302.txt＞

しかし、電子署名技術の利用に際し、証明局（ＣＡ：Ｃｅｒｔｉｆｉｃａｔｅ Ａｕｔｈｏｒｉｔｙ）から証明書の発行を受けるには高額の料金を支払う必要がある。そのため、各家庭で自身のサーバに対する証明書を証明局から受けるのはコスト的にみて現実的でない。

また、通信事業者が認証機関に代わって各家庭のサーバの正当性を証明するとすれば、通信事業者が自身の役割を越えた行為をすることとなり、責任分担が不明確となる。また、通信事業者が証明書を発行するのは高コストにもなる。さらに、携帯電話など、本来の既存の証明局から発行された証明書でなければ受け付けない端末が存在している。

本発明の目的は、ネットワーク接続された家庭内の装置のセキュリティ管理を低コストで実現することのできるアクセス管理システムを提供することである。

上記目的を達成するために、本発明のアクセス管理システムは、ユーザ宅内の装置へのネットワークを介したアクセスを管理するアクセス管理システムであって、
前記ネットワークに接続されており、前記ネットワークを介したアクセスの可否の検証に用いるための自己署名によるユーザ証明書を予め作成しておき、前記アクセスがあると前記ユーザ証明書を用いた検証を行って通信路を確立するユーザ宅内装置と、
前記ユーザ宅内装置で作成された前記ユーザ証明書を予め登録し、認証機関からプロキシ証明書の発行を予め受けておき、アクセス端末から前記ユーザ宅内装置への接続要求を受けると、前記アクセス端末との間で前記プロキシ証明書を用いた検証を行って通信路を確立し、前記ユーザ宅内装置との間で前記ユーザ証明書を用いた検証を行って通信路を確立し、前記アクセス端末と前記ユーザ宅内装置の間の通信を中継するプロキシサーバと、を有している。

本発明によれば、プロキシサーバは認証機関からプロキシ証明書を受けて身分を証明し、そのプロキシ証明書をアクセス端末との間の検証に用い、ユーザ宅内装置は自己署名のユーザ証明書を作成し、そのユーザ証明書をプロキシサーバとの間の検証に用いる。認証機関により証明するのがプロキシサーバだけでよく、プロキシサーバはユーザ宅内装置の作成したユーザ証明書を使用するので、ユーザ宅内装置へのアクセスのセキュリティ管理を安価なシステムで実現できる。

また、前記プロキシサーバは、前記ユーザ宅内装置と、該ユーザ宅内装置がアクセスを許可しているユーザあるいはアクセス端末との対応を示す認証データを管理しており、ユーザによるアクセス端末からの前記接続要求を受けると、前記認証データを参照して、接続先のユーザ宅内装置が、該ユーザあるいは該アクセス端末によるアクセスを許可しているか否か判定し、許可している場合にのみ前記通信路を確立することにしてもよい。

これによれば、ユーザ宅内装置毎にアクセスを許可するアクセス端末を制限することでセキュリティ性を更に向上させることができる。

また、前記ユーザ宅内装置の最新のアドレスを管理する動的ドメイン名管理サーバを更に有し、
前記ユーザ宅内装置は、自身のアドレスが変更されると、新しいアドレスを前記動的ドメイン名管理サーバに登録し、
前記プロキシサーバは、前記ユーザ宅内装置との間に通信路を設定するとき、前記動的ドメイン名管理サーバに問合せて取得した前記ユーザ宅内装置の最新のアドレスを用いることにしてもよい。

本発明によれば、アクセス端末がユーザ宅内装置への接続をプロキシサーバに要求すると、プロキシサーバは、動的ドメイン名管理サーバからユーザ宅内装置の最新のアドレスを取得し、それを用いてユーザ宅内装置に接続するので、アドレスが変更された直後からユーザ宅内装置への接続が可能となる。

本発明によれば、ユーザ宅内装置へのアクセスに関するセキュリティ管理を安価なシステムで実現できる。

本発明を実施するための形態について図面を参照して詳細に説明する。

（第１の実施形態）
図１は、第１の実施形態によるアクセス管理システムの構成を示すブロック図である。図１を参照すると、本実施形態のアクセス管理システムは、ユーザ宅内装置１１、アクセス端末１２、およびプロキシサーバ１３を有している。ユーザ宅内装置１１とプロキシサーバ１３はネットワーク１０に接続されている。ネットワーク１０は典型的にはインターネットである。また、ネットワーク１０にはＣＡ（Ｃｅｒｔｉｆｉｃａｔｅ Ａｕｔｈｏｒｉｔｙ）装置１４が接続されている。アクセス端末１２はネットワーク１０への接続が可能な端末である。

ＣＡ装置１４は、認証機関によって運用される装置であり、公開鍵の登録を受けて、正当性を証明する電子的な証明書を発行する。

ユーザ宅内装置１１は、家庭内ＧＷ（ゲートウェイ）１１Ａと家庭内サーバ１１Ｂからなる。家庭内ＧＷ１１Ａはネットワーク１０へ接続するインタフェースを有し、家庭内サーバ１１Ｂをネットワーク１０に接続するゲートウェイである。家庭内サーバ１１Ｂは、家庭内に設けられるサーバであり、ネットワーク１０に接続したアクセス端末１２から家庭内ゲートウェイ１１Ａを介してアクセスされる。具体例として、家庭内サーバ１１Ｂは、ビデオサーバ、ホームセキュリティサーバ、あるいはホームオートメーションサーバである。

プロキシサーバ１３は、アクセス端末１２からユーザ宅内装置１１へのアクセスの管理および中継を行う。そのために、プロキシサーバ１３は予めＣＡ装置１４からプロキシ証明書（プロキシサーバのホスト証明書）の発行を受け、アクセスしてきた端末に対してそのプロキシ証明書を提示することで正しいサーバであることを示すことができる。そして、ルート証明書の配布を受けているアクセス端末１２からのアクセスをユーザ宅内装置１１へ中継する。また、その際、アクセス端末１２とプロキシサーバ１３の間、プロキシサーバ１３とユーザ宅内装置１１の間は、例えばＳＳＬによる暗号通信路で通信が行われる。

アクセス端末１２は、外出先などからユーザ宅内装置１１の家庭内サーバ１１Ｂにアクセスするための端末であり、例えば、Ｗｅｂブラウザ機能を内蔵した携帯電話機や携帯情報端末である。アクセス端末１２は、予めＣＡ装置１４のルート証明書を内蔵している。このルート証明書を用いることで、暗号通信時にプロキシサーバ１３から提示されるプロキシ証明書を検証することができる。そして、アクセス端末１２は、そのようにして証明されたプロキシサーバ１３を通して家庭内サーバ１１Ｂへアクセスする。

本実施形態によるアクセス管理システムの動作について説明する。本実施形態によるアクセス管理システムの動作は、証明書を準備する段階と、暗号通信路を確立する段階と、実際に通信を行う段階に分けられる。

まず、証明書を準備する段階について説明する。図２は、証明書を準備する段階について説明するための模式図である。

ＣＡ装置１４は、自身を証明するするＣＡ証明書を予め作成し、アクセス端末１２に配布しておく。プロキシサーバ１３は、プロキシ公開鍵およびプロキシ秘密鍵を作成し、プロキシ公開鍵をＣＡ装置１４に送信してプロキシ証明書を要求する。ＣＡ装置１４は、プロキシサーバ１３からプロキシ公開鍵を受け、そのプロキシ公開鍵に自身のＣＡ秘密鍵で署名することによりプロキシ証明書を作成し、プロキシサーバ１３に交付する。

ユーザ宅内装置１１は、ユーザ公開鍵およびユーザ秘密鍵を作成し、ユーザ公開鍵にユーザ秘密鍵で自己署名することによりユーザ証明書を作成する。そして、ユーザ宅内装置１１は、作成したユーザ証明書をプロキシサーバ１３に送って登録する。

以上で証明書の準備が完了する。

次に、暗号通信路を確立する段階について説明する。図３は、暗号通信路を確立する段階について説明するための模式図である。

プロキシサーバ１３に交付されたプロキシ証明書がプロキシサーバ１３からアクセス端末１２に配布される。アクセス端末１２は、予め記録してあったＣＡ証明書を用いてプロキシ証明書を検査する。アクセス端末１２とプロキシサーバ１３の間の暗号通信路の確立において、プロキシサーバ１３がプロキシ秘密鍵を暗号通信路の確立に用い、アクセス端末１２がプロキシ証明書で暗号通信路の検証を行う。

一方、プロキシサーバ１３とユーザ宅内装置１１の間の暗号通信路の確立において、ユーザ宅内装置１１はユーザ秘密鍵を暗号通信路の確立に用い、プロキシサーバ１３がユーザ証明書で暗号通信路を検証する。なお、ユーザ宅内装置１１における暗号通信路は家庭内ＧＷ１１Ａが終端してもよく、家庭内サーバ１１Ｂが終端してもよい。

以上で暗号通信路の確立が完了する。その後、アクセス端末１２とユーザ宅内装置１１はプロキシサーバ１３を介して通信を行う。

本実施形態によれば、プロキシサーバ１３はＣＡ装置１４からプロキシ証明書を受けて身分を証明し、そのプロキシ証明書をアクセス端末１２との間の検証に用い、ユーザ宅内装置１１は自己署名のユーザ証明書を作成し、そのユーザ証明書をプロキシサーバ１３との間の検証に用いる構成である。

ＣＡ装置１４はプロキシサーバ１３（通信事業者）だけを証明すればよく、またプロキシサーバ１３はユーザ宅内装置１１の作成したユーザ証明書を使用するので、
ユーザ宅内装置１１へのアクセスに関するセキュリティ管理を安価なシステムで実現できる。また、本実施形態によれば、通信事業者が認証機関に代わって証明書を発行することがないので、認証機関と通信事業者の責任分担が明確となる。

また、本実施形態において、通信事業者はプロキシ秘密鍵とキャッシュの内容の漏洩を防止すれば、通信内容の盗聴を防止することができる。また、本実施形態において、ユーザ宅内装置１１を提供するハードベンダがユーザ秘密鍵を用意し、ハードウェアに予め組み込んでおくことにすれば、第三者による悪用を防止することができる。

また、本実施形態では、アクセス端末１２とユーザ宅内装置１１の間の通信の暗号をプロキシサーバ１３が一旦解いて再び暗号化するので、プロキシサーバ１３内で通信内容が一時的に暗号化されていない状態となる。しかし、一般的にプロキシサーバ１３は通信事業者（携帯電話キャリア、固定電話キャリア、ＩＳＰ）によって運用されるので、ある程度以上の信頼性は確保される。それでも不十分と考えるユーザは、直接ＣＡ装置１４からユーザ宅内装置１１用のサーバ証明書を受け、アクセス端末１２とユーザ宅内装置１１の間に直接暗号通信路を確立して通信してもよい。

また、本実施形態では、暗号通信路の設定、通信の暗号化および暗号解除の処理によりプロキシサーバ１３の負荷が高くなることが考えられるが、これらの処理はセッション毎に独立した処理であるため、プロキシサーバ１３を複数のコンピュータで並列化した構成とすることで、処理能力を高めることができる。また、大きなコンテンツを家庭から配信する場合など暗号化の必要がなければ、プロキシサーバ１３を認証のみに使用し、実際の通信についてはプロキシサーバ１３を介さずアクセス端末１２とユーザ宅内装置１１が暗号化しない通信路で行うことにしてもよい。

また、本実施形態では、アクセス端末１２はユーザ認証あるいは端末認証を経ずに任意のユーザ宅内装置１１にアクセスすることができるが、ユーザ認証あるいは端末認証によってアクセス可能なユーザ宅内装置１１を制限することにしてもよい。

（第２の実施形態）
第２の実施形態としてアクセスの際に端末認証を行う例を示す。ここでは端末認証を例示するが、ユーザ認証についてもこれと同様である。

図４は、第２の実施形態によるアクセス管理システムの構成を示すブロック図である。図４を参照すると、本実施形態のアクセス管理システムは、ユーザ宅内装置１１、アクセス端末１２、およびプロキシサーバ２１を有している。プロキシサーバ２１は認証データベース２２を備えている。

ユーザは自身のユーザ宅内装置１１へのアクセスを許可するアクセス端末１２を予め決めてプロキシサーバ２１に登録しておく。プロキシサーバ２１は、各ユーザ宅内装置１１のアクセスを許可するアクセス端末１２を認証データベース２２に記録しておく。

アクセス端末１２がユーザ宅内装置１１への接続要求をすると、それを受けたプロキシサーバ２１は、認証データベース２２を参照して端末認証を行い、接続先のユーザ宅内装置１１へのアクセスを許可されているアクセス端末１２からの要求であれば接続を許可して暗号化通信路を設定する。

図５は、端末認証を行う段階について説明するための模式図である。認証データベース２２には端末認証を行うための認証データが予め登録されている。認証データは、各ユーザ宅内装置１１と、そのユーザ宅内装置１１へのアクセスを許可されたアクセス端末１２との対応を示している。ここでは、アクセス端末１２はユーザ宅内装置１１へのアクセスを許可されているが、ユーザ宅内装置１１′へのアクセスは許可されていないものとする。

アクセス端末１２がユーザ宅内装置１１への接続要求をすると、プロキシサーバ２１は認証データベース２２を参照して端末認証を行い、接続を許可して暗号通信路を設定する。一方、アクセス端末１２がユーザ宅内装置１１′への接続要求をすると、プロキシサーバ２１は認証データベース２２を参照して端末認証を行い、接続を許可しない。

ここに示した以外の第２の実施形態における証明書を準備する段階、暗号通信路を確立する段階、および実際に通信を行う段階の動作は第１の実施形態と同様である。

以上説明したように、本実施形態によれば、ユーザ宅内装置１１毎にアクセスを許可するアクセス端末１２を制限することでセキュリティ性を更に向上させることができる。

なお、多くの家庭のユーザは固定アドレスサービスに加入していない。そのため、ネットワーク１０への接続をしなおしたときにＩＰアドレスが変化してしまう可能性がある。通常、プロキシサーバ１３はユーザ宅内装置１１をＩＰアドレスで指定するが、そのＩＰアドレスの変化を認識していなければユーザ宅内装置１１に接続することができない。

ＩＰアドレスの変化に対応するために、一般にはＤＤＮＳ（Ｄｙｍａｎｉｃ Ｄｏｍａｉｎ Ｎａｍｅ Ｓｙｓｔｅｍ）が用いられている。ＤＤＮＳは、ホスト名とＩＰアドレスの対応を動的に更新するシステムである。しかし、ＤＤＮＳにアドレス変更を登録しても、それがインターネット全体に行き渡るのには数分から数週間とかなりの時間を要する。その間、アクセス端末１２は、やはり、ユーザ宅内装置１１にアクセスできない状態となる。

そこで、ここではプロキシサーバ１３はＤＤＮＳを参照してユーザ宅内装置１１のＩＰアドレスを取得し、それを用いてユーザ宅内装置１１に接続することにしてもよい。

（第３の実施形態）
第３の実施形態は、プロキシサーバがＤＤＮＳを参照してユーザ宅内装置１１のＩＰアドレスを取得するアクセス管理システムである。図６は、第３の実施形態によるアクセス管理システムの構成を示すブロック図である。図６を参照すると、本実施形態のアクセス管理システムは、ユーザ宅内装置１１、アクセス端末１２、およびプロキシサーバ３１、およびＤＤＮＳサーバ３３を有している。プロキシサーバ３１は認証データベース２２を備えている。

ＤＤＮＳサーバ３３は、各ユーザ宅内装置１１のホスト名とＩＰアドレスの対応を示すアドレスデータを記憶している。ユーザ宅内装置１１は、ＩＰアドレスが変更されると、新しいアドレスをＤＤＮＳサーバ３３に登録する。

プロキシサーバ３１は、アクセス端末１２からユーザ宅内装置１１への接続要求を受けると、認証データベース２２を参照して端末認証を行う。認証ＯＫであれば、プロキシサーバ３１は、アクセス端末１２と暗号通信路を設定すると共に、ＤＤＮＳサーバ３３を参照してユーザ宅内装置１１のＩＰアドレスを取得し、そのＩＰアドレスで指定してユーザ宅内装置１１と暗号通信路を設定する。

図７は、ＤＤＮＳサーバを参照してユーザ宅内装置に接続する段階について説明するための模式図である。ユーザ宅内装置１１のＩＰアドレスが変更されると、ユーザ宅内装置１１からＤＤＮＳサーバ３３に新しいＩＰアドレスが登録される。その後、ＤＤＮＳサーバ３３のアドレスデータの変更は、他のＤＤＮＳサーバ３５には数分から数週間かけて行き渡る。

一般に、アクセス端末１２からユーザ宅内装置１１へのアクセスはプロキシサーバ３１を経由する、プロキシに閉じたサービスである。そのため、プロキシサーバ３１がユーザ宅内装置１１のアドレス変更を認識できれば、アドレス変更が他のＤＤＮＳサーバ３５に行き渡っていなくてもサービスの運用に支障がない。

アクセス端末１２は、いずれかのＤＮＳサーバ（通常は他のＤＮＳサーバ３５）にプロキシサーバ３１のＤＮＳ問合せ（ＩＰアドレスの問合せ）を行い、プロキシサーバ３１のＩＰアドレスを取得する。プロキシサーバ３１のＩＰアドレスは固定されているので、ここでプロキシサーバ３１のＩＰアドレスを取得できないということはない。

アクセス端末１２は、取得したＩＰアドレスでプロキシサーバ３１を指定して、ユーザ宅内装置１１への接続要求をする。プロキシサーバ３１は、認証データベース３２を参照して端末認証を行い、ＤＤＮＳサーバ３３を参照してユーザ宅内装置１１の最新のＩＰアドレスを取得し、暗号通信路を設定する。

以上説明したように、本実施形態によれば、アクセス端末１２がユーザ宅内装置１１への接続をプロキシサーバ３１に要求すると、プロキシサーバ３１は、ユーザ宅内装置１１の最新のアドレスが登録されているＤＤＮＳサーバ３３を参照してＩＰアドレスを取得し、それを用いてユーザ宅内装置１１に接続するので、ＩＰアドレスが変更された直後からユーザ宅内装置１１への接続が可能となる。

なお、本実施形態では、プロキシサーバ３１とは別個にＤＤＮＳサーバ３３を設置する構成を示したが、本発明はこれに限定されるものではない。他の構成例として、プロキシサーバ３１がＤＤＮＳサーバ３３を兼ねる構成としてもよい。

次に、以上に説明した各実施形態における暗号通信路の確立の具体的な手順について説明する。暗号通信路を設定する際にはＳＳＬプロトコルを用いればよい。図８は、本実施形態の手順の元となる一般的なＳＳＬセッション開始の手順を示すシーケンス図である。

認証機関の証明局は他の証明局の証明書を発行することができる。これを利用して証明書を階層化することができる。ここではルートＣＡから中間ＣＡ（１）〜ＣＡ（ｎ）の階層化がされている。

発行した証明局の正当性が定かでない証明書を検査するときには、その証明局の正当性を確認する必要がある。階層構造に従って上位の証明局をたどることにより、その証明局の正当性を確認できる。

ＳＳＬ対応サーバ９２には予め中間ＣＡ（ｎ）からサーバ証明書が発行されているものとする。また、アクセス端末９１は予めルートＣＡの証明書を内蔵している。

アクセス端末９１とＳＳＬ対応サーバ９２は暗号化プロトコルバージョンやセッションＩＤの決定などセッション確立を開始するためのネゴシエーションを行う（ステップ９０１）。次に、ＳＳＬ対応サーバ９２からアクセス端末９１に、中間ＣＡ（ｎ）によって署名されたサーバ証明書を送り、またサーバ鍵の交換を行う（ステップ９０２）。

次に、アクセス端末９１は、ＳＳＬ対応サーバ９２から受けたサーバ証明書を検査する（ステップ９０３）。その際、アクセス端末９１は、階層構造をたどって上位の証明局によって署名された証明書を取得する。図８では、中間ＣＡ（２）を中間ＣＡ（１）が証明し、中間ＣＡ（１）をルートＣＡが証明するというような階層構造が例示されている。アクセス端末９１は、最終的に、内蔵しているルートＣＡの証明書によってサーバ証明書の検査を完了する。

認証ＮＧであれば、アクセス端末９１は、ここで処理を終了する。認証ＯＫであれば、アクセス端末９１からＳＳＬ対応サーバ９２に、クライアント鍵の交換を行い、暗号方式を決定する（ステップ９０４）。続いて、ＳＳＬ対応サーバ９２からアクセス端末９１に、暗号方式を決定してセッションの確立を完了する（ステップ９０５）。以上により、ＳＳＬで暗号化された通信を行うことができる状態となる（ステップ９０６）。

図９は、アクセス管理システムのＳＳＬセッション開始の手順を示すシーケンス図である。ここでは、上述した第２の実施形態を例にＳＳＬセッション開始の手順を説明するが、他の実施形態についても同様に適用することができる。

図９を参照すると、まず、アクセス端末１２とプロキシサーバ２１の間で通常のＳＳＬセッションの開始を行う（ステップ１０１）。通常のＳＳＬセッションの開始は図８に示した手順で行われる。続いて、プロキシサーバ２１は、アクセス端末１２の端末ＩＤで認証データベース２２を検索し、アクセス端末１２の端末認証を行う（ステップ１０２）。そして、プロキシサーバ２１は、認証した端末ＩＤと認証データベース２２から接続先となるユーザ宅内装置１１特定する（ステップ１０３）。

接続先のユーザ宅内装置１１がアクセスを許可されていなければ、プロキシサーバ２１は、そこで処理を終了する。接続先のユーザ宅内装置１１がアクセスを許可されていれば、プロキシサーバ２１は、特定されたユーザ宅内装置１１との間でＳＳＬセッションの確立処理を開始する（ステップ１０４）。そのとき、ユーザ宅内装置１１のユーザ証明書がプロキシサーバ２１に通知される。

プロキシサーバ２１は、通知されたユーザ証明書を認証する（ステップ１０５）。認証ＮＧであれば、プロキシサーバ２１は、そこで処理を終了する。認証ＯＫであれば、プロキシサーバ２１は、ユーザ宅内装置１１との間に暗号通信路を確立して処理を完了する（ステップ１０６）。

なお、ここではＳＳＬプロトコルを用いた例を示したが、本発明はこれに限定されるものではない。他の例としてＴＬＳプロトコルを用いてもよい。また、ステップ１０４、１０６において送受信されるメッセージは従来のＳＳＬあるいはＴＬＳのセッション確立と同様である。

次に、以上に説明した各実施形態において暗号通信路を確立した後に実際に通信を行う段階について具体的に説明する。図１０は、実際に通信を行う段階の手順を示すシーケンス図である。ここでは、上述した第２の実施形態を例に実際の通信の手順を説明するが、他の実施形態についても同様に適用することができる。

図１０を参照すると、アクセス端末１２は、ユーザ宅内装置１１に対するリクエストをプロキシサーバ２１に送る（ステップ２０１）。リクエストは、例えばＧＥＴやＰＯＳＴなどのＨＴＴＰメソッドである。リクエストは暗号通信路（ＨＴＴＰ ｏｖｅｒ ＳＳＬあるいはＴＬＳ）で転送される。

リクエストを受けたプロキシサーバ２１は、アクセス端末１２からの暗号通信路の宛先となっているユーザ宅内装置１１を特定し、リクエストの宛先と一致するか否か検査する（ステップ２０２）。一致しなければ、プロキシサーバ２１は、そこで処理を終了する。一致すれば、プロキシサーバ２１は、リクエストに含まれているＵＲＬを必要に応じて書き換えて（ステップ２０３）、ユーザ宅内装置１１に送信する（ステップ２０４）。

ユーザ宅内装置１１がリクエストに対するリザルトをプロキシサーバ２１に返すと、プロキシサーバ２１は、そのリザルトに含まれているＵＲＬを必要に応じて書き換えて（ステップ２０６）、アクセス端末１２に送信する（ステップ２０７）。

ステップ２０３、２０６において、プロキシサーバ２１は必要に応じてＵＲＬの書き換えを行うが、このＵＲＬの書き換えの要否について説明する。

アクセス端末１２の典型例である携帯電話機や携帯情報端末には、特定のＵＲＬに対してプロキシを設定できるものとできないものがある。特定のＵＲＬにプロキシを設定できるアクセス端末１２であれば、それを設定しておくことでプロキシサーバ２１でのＵＲＬの書き換えは不要となる。接続先がユーザ宅内装置１１のＵＲＬの場合にプロキシサーバ２１をプロキシとして使用することを設定しておけばよい。例えば、プロキシサーバ２１のＵＲＬが「https://proxy.example.net/」で、ユーザ宅内装置１１のＵＲＬが「https://user01.example.jp/」であるとすると、接続先が「https://user01.example.jp/」の場合に「https://proxy.example.net/」をプロキシとして使用するという設定をすればよい。

また、特定のＵＲＬにプロキシを設定できないアクセス端末１２であれば、アクセス端末１２はリクエストにはプロキシサーバ２１にアクセスするようなＵＲＬを記載する。そこで、プロキシサーバ２１は、そのＵＲＬをユーザ宅内装置１１のＵＲＬに書き換えて送信する必要がある。例えば、プロキシサーバ２１のＵＲＬが「https://proxy.example.com/」で、ユーザ宅内装置１１のアクセス対象のＵＲＬが「http://user1.example.jp/foo/bar.html」であるとする。その場合に、アクセス端末１２とプロキシサーバ２１の間では「https://proxy.example.com/user1.example.jp/foo/bar.html」を使用し、プロキシサーバ２１とユーザ宅内装置１１の間では、「http://user1.example.jp/foo/bar.html」を用いればよい。また、他の例として、既存のｄｅｌｅｇａｔｅあるいはｃｇｉ−ｐｒｏｘｙにおけるＵＲＬ書き換え方法を採用してもよい。

第１の実施形態によるアクセス管理システムの構成を示すブロック図である。 第１の実施形態における証明書を準備する段階について説明するための模式図である。 第１の実施形態における暗号通信路を確立する段階について説明するための模式図である。 第２の実施形態によるアクセス管理システムの構成を示すブロック図である。 第２の実施形態における端末認証を行う段階について説明するための模式図である。 第３の実施形態によるアクセス管理システムの構成を示すブロック図である。 ＤＤＮＳサーバを参照してユーザ宅内装置に接続する段階について説明するための模式図である。 本実施形態の手順の元となる一般的なＳＳＬセッション開始の手順を示すシーケンス図である。 アクセス管理システムのＳＳＬセッション開始の手順を示すシーケンス図である。 実際に通信を行う段階の手順を示すシーケンス図である。

符号の説明

１０ ネットワーク
１１、１１′ ユーザ宅内装置
１１Ａ 家庭内ＧＷ（ゲートウェイ）
１１Ｂ 家庭内サーバ
１２ アクセス端末
１３、２１、３１ プロキシサーバ
１４ ＣＡ（Ｃｅｒｔｉｆｉｃａｔｅ Ａｕｔｈｏｒｉｔｙ）装置
２２ 認証データベース
３３ ＤＤＮＳサーバ
１０１〜１０６、２０１〜２０７ ステップ

Claims (6)

1. ユーザ宅内の装置へのネットワークを介したアクセスを管理するアクセス管理システムであって、
   前記ネットワークに接続されており、前記ネットワークを介したアクセスの可否の検証に用いるための自己署名によるユーザ証明書を予め作成しておき、前記アクセスがあると前記ユーザ証明書を用いた検証を行って通信路を確立するユーザ宅内装置と、
   前記ユーザ宅内装置で作成された前記ユーザ証明書を予め登録し、認証機関からプロキシ証明書の発行を予め受けておき、アクセス端末から前記ユーザ宅内装置への接続要求を受けると、前記アクセス端末との間で前記プロキシ証明書を用いた検証を行って通信路を確立し、前記ユーザ宅内装置との間で前記ユーザ証明書を用いた検証を行って通信路を確立し、前記アクセス端末と前記ユーザ宅内装置の間の通信を中継するプロキシサーバと、を有するアクセス管理システム。
2. 前記プロキシサーバは、前記ユーザ宅内装置と、該ユーザ宅内装置がアクセスを許可しているユーザあるいはアクセス端末との対応を示す認証データを管理しており、ユーザによるアクセス端末からの前記接続要求を受けると、前記認証データを参照して、接続先のユーザ宅内装置が、該ユーザあるいは該アクセス端末によるアクセスを許可しているか否か判定し、許可している場合にのみ前記通信路を確立する、請求項１に記載のアクセス管理システム。
3. 前記ユーザ宅内装置の最新のアドレスを管理する動的ドメイン名管理サーバを更に有し、
   前記ユーザ宅内装置は、自身のアドレスが変更されると、新しいアドレスを前記動的ドメイン名管理サーバに登録し、
   前記プロキシサーバは、前記ユーザ宅内装置との間に通信路を設定するとき、前記動的ドメイン名管理サーバに問合せて取得した前記ユーザ宅内装置の最新のアドレスを用いる、請求項１または２に記載のアクセス管理システム。
4. ユーザ宅内装置へのネットワークを介したアクセスを管理するためのアクセス管理方法であって、
   プロキシサーバが認証機関からプロキシ証明書の発行を受け、
   前記ネットワークを介したアクセスの可否の検証に用いるためのユーザ証明書を、ユーザ宅内装置が自己署名によって作成し、
   アクセス端末から前記プロキシサーバに対して前記ユーザ宅内装置への接続が要求されると、前記プロキシサーバと前記アクセス端末の間では前記プロキシ証明書を用いた検証を行って通信路を確立し、前記プロキシサーバと前記ユーザ宅内装置の間では前記ユーザ証明書を用いた検証を行って通信路を確立し、
   前記アクセス端末と前記ユーザ宅内装置の間の通信を、前記アクセス端末と前記プロキシサーバの間の通信路と、前記プロキシサーバと前記ユーザ宅内装置の間の通信路とを用いて前記プロキシサーバが中継する、アクセス管理方法。
5. 前記ユーザ宅内装置と、該ユーザ宅内装置がアクセスを許可しているユーザあるいはアクセス端末との対応を示す認証データを前記プロキシサーバにて管理しており、
   ユーザによるアクセス端末からの前記接続要求を受けると、前記プロキシサーバが、前記認証データを参照して、接続先のユーザ宅内装置が、該ユーザあるいは該アクセス端末によるアクセスを許可しているか否か判定し、許可している場合にのみ前記通信路を確立する、請求項４に記載のアクセス管理方法。
6. 前記ユーザ宅内装置の最新のアドレスを動的ドメイン名管理サーバにて管理しており、
   前記ユーザ宅内装置との間に通信路を設定するとき、前記プロキシサーバは、前記動的ドメイン名管理サーバに問合せて取得した前記ユーザ宅内装置の最新のアドレスを用いる、請求項４または５に記載のアクセス管理方法。

Images