JP2004015530A - アクセス権限管理システム、中継サーバ、および方法、並びにコンピュータ・プログラム - Google Patents

Abstract

【課題】ネットワークを介した通信における確実なアクセス制限を実行するシステムおよび方法を実現する。
【解決手段】通信ネットワークを介した通信処理装置間の通信において、ホームサーバ等の中継サーバが、アクセス元の属性証明書の検証、審査を実行して、アクセス元がアクセス先の許容メンバーであるか否かの判定処理を実行し、アクセス先の許容するアクセス元である場合にのみ、名前解決処理を実行して、アクセス先のアドレス情報をアクセス元に通知する。アクセス元のドメイン名、ホスト名を記述したグループ属性証明書を適用し、さらに、ドメイン名、ホスト名に対応するアドレスの更新を実行する構成とした。
【選択図】　図１３

Description

【０００１】
【発明の属する技術分野】
本発明は、アクセス権限管理システム、中継サーバ、および方法、並びにコンピュータ・プログラムに関する。例えば特定の通信端末、あるいはユーザにのみアクセス権限を付与し、アクセス権限を有する機器あるいはユーザからのアクセスのみを許容可能としたアクセス権限管理システム、中継サーバ、および方法、並びにコンピュータ・プログラムに関する。
【０００２】
【従来の技術】
昨今、インターネット等の通信ネットワークを介した通信が盛んに行なわれている。ネットワークに接続されている機器は、アドレスによって通信先が特定され、相互の通信が可能となる。インターネットではルーティテングプロトコルとしてＩＰ（ＩｎｔｅｒｎｅｔＰｒｏｔｏｃｏｌ）が用いられている。現在主に使用されているＩＰはＩＰｖ４であり、発信元／宛先として３２ビットからなるアドレス（ＩＰアドレス）が用いられている。インターネット通信においては、３２ビットＩＰアドレスを各発信元／宛先にユニークに割り当てるグローバルＩＰアドレスを採用し、ＩＰアドレスに応じて、個々の発信元／宛先を判別している。
【０００３】
ＩＰアドレス（ＩＰｖ４）は３２ビットのアドレスを８ビットを単位として１０進数で表して表記する。このような数字の羅列はユーザにとっては覚えにくいものである。このため、ＩＰアドレスの代わりにホストネームを用いて通信を可能とするためのＤＮＳ（Ｄｏｍａｉｎ　Ｎａｍｅ　Ｓｙｓｔｅｍ）が利用される。
【０００４】
ＤＮＳサーバが端末（ホスト）のＩＰアドレスとホスト名の対応付けを管理し、端末が通信を行うときにＤＮＳサーバにアクセスしてホスト名に基づいてホストアドレス（ＩＰアドレス）を得ることができる。
【０００５】
すなわち、アドレスは単なるビット列であるので、これを利用者が直接管理することは困難である。そのため、インターネットにおいては人が理解しやすい名前を付与し、それをアドレスに変換する機構としてＤＮＳ（Ｄｏｍａｉｎ　Ｎａｍｅ　Ｓｙｓｔｅｍ）が導入されている。
【０００６】
ＷＷＷやコンテンツ配信サービス等ではサーバと呼ばれるサービスの提供を専門に行う機器に利用者がアクセスすることが多いのに対し、利用者同士でチャットを行うインスタント・メッセージングといった場合では、利用者の機器を直接接続する形態がとられることがある。この直接接続形態を一般的に「ピア・ツー・ピア」（Ｐｅｅｒ　ｔｏ　Ｐｅｅｒ）と呼ぶ。
【０００７】
情報処理装置間の直接通信処理としてのピア・ツー・ピア（Ｐ２Ｐ：Ｐｅｅｒ−ｔｏ−Ｐｅｅｒ）ネットワークとは、集中的に処理を行なうサーバを設置するのではなく、各ネットワーククライアントが持つ資源としての情報処理装置、例えばＰＣ、携帯端末、ＰＤＡ、携帯電話、さらに、通信処理可能な機能を持つあるいは通信機器間を直接接続した通信ネットワークである。
【０００８】
ピア・ツー・ピア（Ｐ２Ｐ：Ｐｅｅｒ−ｔｏ−Ｐｅｅｒ）ネットワーク技術は、米ＩＢＭ社が提唱するＡＰＰＮ（Ａｄｖａｎｃｅｄ　Ｐｅｅｒ　ｔｏ　Ｐｅｅｒ　Ｎｅｔｗｏｒｋｉｎｇ）の中で用いられたのが最初とされている。このネットワークを使うことで、従来のようなクライアント−サーバ型ネットワークにおいてコンテンツ配信を行う場合に必要となる巨大な配信サーバを設置する必要がなくなり、各ネットワーククライアントが持つ資源に分散配置されたコンテンツを多くのユーザが利用可能となり、大容量のコンテンツの分散格納および、配信が可能となる。
【０００９】
【発明が解決しようとする課題】
しかし、特定のサービスプロバイダによるコンテンツ配信等の場合は、一般的に配信を行うサービスプロバイダと利用者とがあらかじめ契約等で信頼関係を構築し、データ送信側と受信側とが、契約に基づく信頼関係をベースとしたデータ送受信が可能であるのに対し、リモートコントロールやインスタント・メッセージングでは、特に信頼関係のない不特定多数から各クライアントの通信端末に対するアクセス要求があり、データの送受信が実行されることになる。
【００１０】
従って、インターネット等に接続した通信処理装置としてのクライアント端末は、クライアント端末や、そのクライアント端末を接続したホームネットワークに対して悪意を持った他のネットワーク接続機器からＤｏＳ（Ｄｅｎｉａｌ　ｏｆ　Ｓｅｒｖｉｃｅ）攻撃等の通信妨害を受ける可能性がある。ＤｏＳ（Ｄｅｎｉａｌ　ｏｆ　Ｓｅｒｖｉｃｅ）攻撃とは、大量のデータや不正パケット、あるいはコマンドを送信することにより、サービスの提供を困難とさせるものである。
【００１１】
たとえ一度信頼関係を結んだ通信端末間であっても、その信頼関係を解消した場合、アドレスが固定アドレスであると、引き続きアクセスを実行することが可能となってしまい、不正アクセスや攻撃の可能な状態が維持されてしまうといった問題がある。
【００１２】
本発明は、上記問題点に鑑みてなされたものであり、ネットワークに接続されたクライアント端末等、通信処理装置に対する不正なアクセスを排除する構成を提供するものである。
【００１３】
本発明は、ＰＣ、携帯端末、ＰＤＡ、携帯電話等のクライアント端末としての通信処理装置の許容するユーザあるいは端末からのアクセス要求のみを許可する構成を実現するアクセス権限管理システム、中継サーバ、および方法、並びにコンピュータ・プログラムを提供することを目的する。
【００１４】
さらに、具体的には、本発明は、安全なホームネットワークの実現に向けて、ＤｏＳ（Ｄｅｎｉａｌ　ｏｆ　Ｓｅｒｖｉｃｅ）攻撃等への対策を考慮したものであり、ネットワークに接続された例えばホームサーバにおいて、アクセス要求元から提示される属性証明書を適用したアクセス権限の確認処理を実行し、アクセス権限の確認を条件として名前解決処理を実行する構成として、アクセスを許容したユーザあるいは端末からの要求に対してのみアクセスを許容することを可能としたアクセス権限管理システム、中継サーバ、および方法、並びにコンピュータ・プログラムを提供することを目的する。
【００１５】
【課題を解決するための手段】
本発明の第１の側面は、
通信ネットワークを介した通信処理装置間の通信におけるアクセス権限管理システムであり、
アクセス先通信処理装置のホスト名とアドレスの対応データを有し、アクセス先通信処理装置に対応するホスト名に関する名前解決処理を実行する名前解決サーバと、
アクセス元通信処理装置から、アクセス先通信処理装置のホスト名を受信するとともに、特定通信処理装置の集合からなるグループに対応して設定されるグループ識別情報を格納し発行者電子署名を有するグループ属性証明書を受信し、該グループ属性証明書の検証処理、および、アクセス先通信処理装置のアクセス許容グループにアクセス元通信処理装置が属するか否かの審査処理を実行し、該検証および審査が成立したことを条件として、前記名前解決サーバを適用した名前解決処理により、アクセス先通信処理装置のアドレスを取得し、前記アクセス元通信処理装置に対する通知処理を実行する中継サーバと、
を有することを特徴とするアクセス権限管理システムにある。
【００１６】
さらに、本発明のアクセス権限管理システムの一実施態様において、前記グループ属性証明書は、ドメイン名をグループ識別情報として格納し、前記中継サーバは、前記アクセス先通信処理装置に対するアクセス許可グループ情報としてドメイン名によるアクセス許可グループ情報を格納した許可グループデータベースを参照して、アクセス先通信処理装置のアクセス許容グループにアクセス元通信処理装置が属するか否かの審査処理を実行する構成であることを特徴とする。
【００１７】
さらに、本発明のアクセス権限管理システムの一実施態様において、前記グループ属性証明書は、ホスト名をグループ識別情報として格納し、前記中継サーバは、前記アクセス先通信処理装置に対するアクセス許可グループ情報としてホスト名によるアクセス許可グループ情報を格納した許可グループデータベースを参照して、アクセス先通信処理装置のアクセス許容グループにアクセス元通信処理装置が属するか否かの審査処理を実行する構成であることを特徴とする。
【００１８】
さらに、本発明のアクセス権限管理システムの一実施態様において、前記中継サーバは、前記アクセス先通信処理装置にネットワーク接続されたホームサーバであることを特徴とする。
【００１９】
さらに、本発明のアクセス権限管理システムの一実施態様において、前記中継サーバは、前記アクセス先通信処理装置に対応するドメイン名またはホスト名に対応するアドレスの更新処理を実行する構成を有し、前記アクセス先通信処理装置の有する属性証明書の検証の成立を条件として前記更新処理を実行する構成であることを特徴とする。
【００２０】
さらに、本発明のアクセス権限管理システムの一実施態様において、前記中継サーバは、アクセス元通信処理装置との相互認証を実行し、相互認証の成立を条件として、前記アクセス元通信処理装置から提示されるグループ属性証明書の検証および審査を実行する構成であることを特徴とする。
【００２１】
さらに、本発明のアクセス権限管理システムの一実施態様において、前記グループ属性証明書は、グループ属性証明書に対応する公開鍵証明書に関するリンク情報を格納した構成であり、前記中継サーバは、前記グループ属性証明書の検証に際し、前記リンク情報によって取得される公開鍵証明書の検証を併せて実行する構成であることを特徴とする。
【００２２】
さらに、本発明の第２の側面は、
通信ネットワークを介した通信処理装置間の通信におけるアクセス権限管理を実行する中継サーバであり、
アクセス元通信処理装置から、アクセス先通信処理装置のホスト名を受信するとともに、特定通信処理装置の集合からなるグループに対応して設定されるグループ識別情報を格納し発行者電子署名を有するグループ属性証明書を受信し、該グループ属性証明書の検証処理、および、アクセス先通信処理装置のアクセス許容グループにアクセス元通信処理装置が属するか否かの審査処理を実行し、該検証および審査が成立したことを条件として、名前解決サーバを適用した名前解決処理により、アクセス先通信処理装置のアドレスを取得し、前記アクセス元通信処理装置に対する通知処理を実行する構成を有することを特徴とする中継サーバにある。
【００２３】
さらに、本発明の中継サーバの一実施態様において、前記グループ属性証明書は、ドメイン名をグループ識別情報として格納し、前記中継サーバは、前記アクセス先通信処理装置に対するアクセス許可グループ情報としてドメイン名によるアクセス許可グループ情報を格納した許可グループデータベースを参照して、アクセス先通信処理装置のアクセス許容グループにアクセス元通信処理装置が属するか否かの審査処理を実行する構成であることを特徴とする。
【００２４】
さらに、本発明の中継サーバの一実施態様において、前記グループ属性証明書は、ホスト名をグループ識別情報として格納し、前記中継サーバは、前記アクセス先通信処理装置に対するアクセス許可グループ情報としてホスト名によるアクセス許可グループ情報を格納した許可グループデータベースを参照して、アクセス先通信処理装置のアクセス許容グループにアクセス元通信処理装置が属するか否かの審査処理を実行する構成であることを特徴とする。
【００２５】
さらに、本発明の中継サーバの一実施態様において、前記中継サーバは、前記アクセス先通信処理装置にネットワーク接続されたホームサーバであることを特徴とする。
【００２６】
さらに、本発明の中継サーバの一実施態様において、前記中継サーバは、前記アクセス先通信処理装置に対応するドメイン名またはホスト名に対応するアドレスの更新処理を実行する構成を有し、前記アクセス先通信処理装置の有する属性証明書の検証の成立を条件として前記更新処理を実行する構成であることを特徴とする。
【００２７】
さらに、本発明の中継サーバの一実施態様において、前記中継サーバは、アクセス元通信処理装置との相互認証を実行し、相互認証の成立を条件として、前記アクセス元通信処理装置から提示されるグループ属性証明書の検証および審査を実行する構成であることを特徴とする。
【００２８】
さらに、本発明の中継サーバの一実施態様において、前記グループ属性証明書は、グループ属性証明書に対応する公開鍵証明書に関するリンク情報を格納した構成であり、前記中継サーバは、前記グループ属性証明書の検証に際し、前記リンク情報によって取得される公開鍵証明書の検証を併せて実行する構成であることを特徴とする。
【００２９】
さらに、本発明の第３の側面は、
通信ネットワークを介した通信処理装置間の通信におけるアクセス権限管理方法であり、
中継サーバにおいて、アクセス元通信処理装置から、アクセス先通信処理装置のホスト名を受信するとともに、特定通信処理装置の集合からなるグループに対応して設定されるグループ識別情報を格納し発行者電子署名を有するグループ属性証明書を受信するステップ、
該グループ属性証明書の検証処理、および、アクセス先通信処理装置のアクセス許容グループにアクセス元通信処理装置が属するか否かの審査処理を実行するステップ、
該検証および審査が成立したことを条件として、名前解決サーバを適用した名前解決処理により、アクセス先通信処理装置のアドレスを取得し、前記アクセス元通信処理装置に対する通知処理を実行するステップ、
を含むことを特徴とするアクセス権限管理方法にある。
【００３０】
さらに、本発明のアクセス権限管理方法の一実施態様において、前記グループ属性証明書は、ドメイン名をグループ識別情報として格納し、前記中継サーバは、前記アクセス先通信処理装置に対するアクセス許可グループ情報としてドメイン名によるアクセス許可グループ情報を格納した許可グループデータベースを参照して、アクセス先通信処理装置のアクセス許容グループにアクセス元通信処理装置が属するか否かの審査処理を実行することを特徴とする。
【００３１】
さらに、本発明のアクセス権限管理方法の一実施態様において、前記グループ属性証明書は、ホスト名をグループ識別情報として格納し、前記中継サーバは、前記アクセス先通信処理装置に対するアクセス許可グループ情報としてホスト名によるアクセス許可グループ情報を格納した許可グループデータベースを参照して、アクセス先通信処理装置のアクセス許容グループにアクセス元通信処理装置が属するか否かの審査処理を実行することを特徴とする。
【００３２】
さらに、本発明のアクセス権限管理方法の一実施態様において、前記中継サーバは、前記アクセス先通信処理装置にネットワーク接続されたホームサーバであることを特徴とする。
【００３３】
さらに、本発明のアクセス権限管理方法の一実施態様において、前記アクセス権限管理方法において、前記中継サーバは、さらに、前記アクセス先通信処理装置に対応するドメイン名またはホスト名に対応するアドレスの更新処理を実行するステップを有し、前記アクセス先通信処理装置の有する属性証明書の検証の成立を条件として前記更新処理を実行することを特徴とする。
【００３４】
さらに、本発明のアクセス権限管理方法の一実施態様において、前記中継サーバは、アクセス元通信処理装置との相互認証を実行し、相互認証の成立を条件として、前記アクセス元通信処理装置から提示されるグループ属性証明書の検証および審査を実行することを特徴とする。
【００３５】
さらに、本発明のアクセス権限管理方法の一実施態様において、前記グループ属性証明書は、グループ属性証明書に対応する公開鍵証明書に関するリンク情報を格納した構成であり、前記中継サーバは、前記グループ属性証明書の検証に際し、前記リンク情報によって取得される公開鍵証明書の検証を併せて実行することを特徴とする。
【００３６】
さらに、本発明の第４の側面は、
通信ネットワークを介した通信処理装置間の通信におけるアクセス権限管理処理を実行せしめるコンピュータ・プログラムであって、
アクセス元通信処理装置から、アクセス先通信処理装置のホスト名を受信するとともに、特定通信処理装置の集合からなるグループに対応して設定されるグループ識別情報を格納し発行者電子署名を有するグループ属性証明書を受信するステップ、
該グループ属性証明書の検証処理、および、アクセス先通信処理装置のアクセス許容グループにアクセス元通信処理装置が属するか否かの審査処理を実行するステップ、
該検証および審査が成立したことを条件として、名前解決サーバを適用した名前解決処理により、アクセス先通信処理装置のアドレスを取得し、前記アクセス元通信処理装置に対する通知処理を実行するステップ、
を有することを特徴とするコンピュータ・プログラムにある。
【００３７】
【作用】
本発明の構成によれば、通信ネットワークを介した通信処理装置間の通信において、アクセス先の許容するアクセス元であるか否かをホームサーバ等の中継サーバにおいて判定して、アクセス先の許容するアクセス元である場合にのみ、名前解決処理を実行して、アクセス先のアドレス情報をアクセス元に通知する構成としたので、アクセス先の許容したアクセス元からのアクセスのみを実行する構成が実現される。
【００３８】
さらに、本発明の構成によれば、通信ネットワークを介した通信処理装置間の通信において、ホームサーバ等の中継サーバが、アクセス元の属性証明書の検証、審査を実行して、アクセス元がアクセス先の許容メンバーであるか否かの判定処理を実行し、アクセス先の許容するアクセス元である場合にのみ、名前解決処理を実行して、アクセス先のアドレス情報をアクセス元に通知する構成としたので、属性証明書に基づく確実な審査によるアクセス制限を実行することが可能となる。
【００３９】
さらに、本発明の構成によれば、アクセス元のドメイン名属性証明書、ホスト名属性証明書等、属性情報としてドメイン名、ホスト名を記述したグループ属性証明書を適用する構成としたので、特定ドメインに属する機器、あるいは特定ホスト名の機器に限定したアクセス制限を実行することが可能となる。
【００４０】
さらに、本発明の構成によれば、アクセス元のドメイン名属性証明書、ホスト名属性証明書等、属性情報としてドメイン名、ホスト名を記述したグループ属性証明書を適用する構成とするとともに、ドメイン名、ホスト名に対応するアドレスの更新を実行する構成としたので、旧アドレスを適用したアクセスの排除が可能となる。
【００４１】
なお、本発明のコンピュータ・プログラムは、例えば、様々なプログラム・コードを実行可能なコンピュータ・システムに対して、コンピュータ可読な形式で提供する記憶媒体、通信媒体、例えば、ＣＤやＦＤ、ＭＯなどの記録媒体、あるいは、ネットワークなどの通信媒体によって提供可能なコンピュータ・プログラムである。このようなプログラムをコンピュータ可読な形式で提供することにより、コンピュータ・システム上でプログラムに応じた処理が実現される。
【００４２】
本発明のさらに他の目的、特徴や利点は、後述する本発明の実施例や添付する図面に基づくより詳細な説明によって明らかになるであろう。なお、本明細書においてシステムとは、複数の装置の論理的集合構成であり、各構成の装置が同一筐体内にあるものには限らない。
【００４３】
【発明の実施の形態】
以下、本発明について図面を参照して詳細に説明する。なお、以下、下記に示す項目順に説明する。
（１）アクセス権限管理システム構成概要
（２）ユーザデバイス構成
（３）アクセス制限処理
（３−１）アクセス制限処理概要
（３−２）ドメイン登録および属性証明書発行処理
（３−３）アクセス許可情報の登録および削除処理
（３−４）アクセス許可判定処理
（３−５）アドレス更新処理
（４）各エンティテイの構成
【００４４】
［（１）アクセス権限管理システム概要］
本発明のアクセス権限管理システムは、図１に示すように、公開鍵証明書（ＰＫＣ：ＰｕｂｌｉｃＫｅｙｃｅｒｔｉｆｉｃａｔｅ）１２１に基づく公開鍵基盤（ＰＫＩ：ＰｕｂｌｉｃＫｅｙｉｎｆｒａｓｔｒｕｃｔｕｒｅ）１０１、属性証明書（ＡＣ：Ａｔｔｒｉｂｕｔｅｃｅｒｔｉｆｉｃａｔｅ）１２２に基づく権限管理基盤（ＰＭＩ：ＰｒｉｖｉｌｅｇｅｍａｎａｇｅｍｅｎｔＩｎｆｒａｓｔｒｕｃｔｕｒｅ）１０２を基本インフラとし、これらのインフラの下で、耐タンパ性のセキュリティチップ（あるいはセキュリティモジュール）を持つ通信処理装置としてのユーザデバイス１３１〜１３３、およびユーザデバイス１４１〜１４３がネットワークを介した通信を実行する。
【００４５】
ユーザデバイス１３１〜１３３は、例えばホームサーバ等の中継サーバ１３０を介してネットワーク１１０を介した通信を実行し、ユーザデバイス１４１〜１４３は、中継サーバ１４０を介してネットワーク１１０を介した通信を実行する。
【００４６】
ユーザデバイス１３１〜１３３とホームサーバ等の中継サーバ１３０とは、サブネットワークを構成し、例えばイーサネット等の有線あるいは無線ＬＡＮ、その他の通信ネットワークにより接続され、中継サーバ１３０は、以下、詳細に説明するグループ属性証明書等、属性証明書１２２に基づいて、自己の管理領域内のユーザデバイス１３１〜１３３に対するアクセス要求に関するアクセス権限の判定処理を実行し、アクセス権限があると判定されたアクセス要求のみに対して、ＤＮＳ（Ｄｏｍａｉｎ　Ｎａｍｅ　Ｓｙｓｔｅｍ）としての名前解決サーバ１３５によるホスト名からアドレスへの変換処理を実行し、名前解決により取得したアクセス先のアドレスデータをアクセス要求元に対して通知する。中継サーバ１４０も、同様にグループ属性証明書等の属性証明書１２２に基づいて、自己の管理領域内のユーザデバイス１４１〜１４３に対するアクセス要求のアクセス権限を判定し、同様の処理を実行する。
【００４７】
ユーザデバイス１３１〜１３３，１４１〜１４３は、ネットワーク１１０を介したユーザデバイス間における通信処理が実行可能な端末であり、具体的には、ＰＣ、ゲーム端末、ＤＶＤ，ＣＤ等の再生装置、携帯通信端末、ＰＤＡ、メモリカード等によって構成され、耐タンパ構成のセキュリティチップを搭載している。ユーザデバイスの詳細については後述する。
【００４８】
なお、図１では、ユーザデバイス相互間の通信制御構成を示してあるが、ユーザデバイスが、サービスプロバイダから音楽、画像、プログラム等の各種コンテンツ提供サービス、その他の情報利用サービス、決済サービス等の各種サービスの提供を受領する場合にも、同様の属性証明書を適用したアクセス権限の判定、および判定に基づく名前解決処理の実行プロセスが可能であり、本発明のアクセス権限管理システムは、ユーザデバイス間のアクセス制御のみならず、サービスプロバイダとユーザデバイス間など、さまざまなエンティテイ間の通信におけるアクセス制御に適用可能である。
【００４９】
（公開鍵証明書：ＰＫＣ）
次に、公開鍵基盤について説明する。公開鍵基盤（ＰＫＩ：ＰｕｂｌｉｃＫｅｙｉｎｆｒａｓｔｒｕｃｔｕｒｅ）１０１は、公開鍵証明書（ＰＫＣ：ＰｕｂｌｉｃＫｅｙｃｅｒｔｉｆｉｃａｔｅ）を適用して通信エンティテイ間の認証処理、あるいは転送データの暗号処理等を実行可能とした基盤（インフラ）である。（公開鍵証明書（ＰＫＣ））について図２，図３、図４を用いて説明する。公開鍵証明書は、認証局（ＣＡ：Ｃｅｒｔｉｆｉｃａｔｉｏｎ　Ａｕｔｈｏｒｉｔｙ）が発行する証明書であり、ユーザ、各エンティテイが自己のＩＤ、公開鍵等を認証局に提出することにより、認証局側が認証局のＩＤや有効期限等の情報を付加し、さらに認証局による署名を付加して作成される証明書である。
【００５０】
なお、認証局（ＣＡ）の事務代理機関として、登録局（ＲＡ：Ｒｅｇｉｓｔｒａｔｉｏｎ　Ａｕｔｈｏｒｉｔｙ）を設け、登録局（ＲＡ）において、公開鍵証明書（ＰＫＣ）の発行申請受理、申請者の審査、管理を行なう構成が一般的となっている。
【００５１】
公開鍵証明書のフォーマット例を図２〜図４に示す。これは、公開鍵証明書フォーマットＩＴＵ−Ｔ　Ｘ．５０９に準拠した例である。
【００５２】
バージョン（ｖｅｒｓｉｏｎ）は、証明書フォーマットのバージョンを示す。
シリアルナンバ（Ｓｅｒｉａｌ　Ｎｕｍｂｅｒ）は、公開鍵証明書発行局（ＣＡ）によって設定される公開鍵証明書のシリアルナンバである。
シグネチャ（Ｓｉｇｎａｔｕｒｅ）は、証明書の署名アルゴリズムである。なお、署名アルゴリズムとしては、楕円曲線暗号およびＲＳＡがあり、楕円曲線暗号が適用されている場合はパラメータおよび鍵長が記録され、ＲＳＡが適用されている場合には鍵長が記録される。
発行者（ｉｓｓｕｅｒ）は、公開鍵証明書の発行者、すなわち公開鍵証明書発行局（ＩＡ）の名称が識別可能な形式（Ｄｉｓｔｉｎｇｕｉｓｈｅｄ　Ｎａｍｅ）で記録されるフィールドである。
有効期限（ｖａｌｉｄｉｔｙ）は、証明書の有効期限である開始日時、終了日時が記録される。
サブジェクト公開鍵情報（ｓｕｂｊｅｃｔ　Ｐｕｂｌｉｃ　Ｋｅｙ　Ｉｎｆｏ）は、証明書所有者の公開鍵情報として鍵のアルゴリズム、鍵が格納される。
【００５３】
証明局鍵識別子（ａｕｔｈｏｒｉｔｙ　Ｋｅｙ　Ｉｄｅｎｔｉｆｉｅｒ−ｋｅｙ　Ｉｄｅｎｔｉｆｉｅｒ、ａｕｔｈｏｒｉｔｙ　Ｃｅｒｔ　Ｉｓｓｕｅｒ、ａｕｔｈｏｒｉｔｙ　Ｃｅｒｔ　Ｓｅｒｉａｌ　Ｎｕｍｂｅｒ）は、署名検証に用いる証明書発行者の鍵を識別する情報であり、鍵識別子、機関証明書発行者の名称、機関証明書シリアル番号を格納する。
サブジェクト鍵識別子（ｓｕｂｊｅｃｔ　ｋｅｙ　Ｉｄｅｎｔｉｆｉｅｒ）は、複数の鍵を公開鍵証明書において証明する場合に各鍵を識別するための識別子を格納する。
鍵使用目的（ｋｅｙ　ｕｓａｇｅ）は、鍵の使用目的を指定するフィールドであり、（０）ディジタル署名用、（１）否認防止用、（２）鍵の暗号化用、（３）メッセージの暗号化用、（４）共通鍵配送用、（５）認証の署名確認用、（６）失効リストの署名確認用の各使用目的が設定される。
秘密鍵有効期限（ｐｒｉｖａｔｅ　Ｋｅｙ　Ｕｓａｇｅ　Ｐｅｒｉｏｄ）は、証明書に格納した公開鍵に対応する秘密鍵の有効期限を記録する。
認証局ポリシー（ｃｅｒｔｉｆｉｃａｔｅ　Ｐｏｌｉｃｉｅｓ）は、公開鍵証明書発行者の証明書発行ポリシーを記録する。例えばＩＳＯ／ＩＥＣ９３８４−１に準拠したポリシーＩＤ、認証基準である。
ポリシー・マッピング（ｐｏｌｉｃｙ　Ｍａｐｐｉｎｇ）は、認証パス中のポリシー関係の制限に関する情報を格納するフィールドであり、認証局（ＣＡ）証明書にのみ必要となる。
サブジェクト別名（ｓｕｂｊｅｃｔ　Ａｌｔ　Ｎａｍｅ）は、証明書所有者の別名を記録するフィールドである。
発行者別名（ｉｓｓｕｅｒ　Ａｌｔ　Ｎａｍｅ）は、証明書発行者の別名を記録するフィールドである。
サブジェクト・ディレクトリ・アトリビュート（ｓｕｂｊｅｃｔ　Ｄｉｒｅｃｔｏｒｙ　Ａｔｔｒｉｂｕｔｅ）は、証明書所有者のために必要とされるディレクトリの属性を記録するフィールドである。
基本制約（ｂａｓｉｃ　Ｃｏｎｓｔｒａｉｎｔ）は、証明対象の公開鍵が認証局（ＣＡ）の署名用か、証明書所有者のものかを区別するためのフィールドである。
許容サブツリー制約名（ｎａｍｅ　Ｃｏｎｓｔｒａｉｎｔｓ　ｐｅｒｍｉｔｔｅｄ　Ｓｕｂｔｒｅｅｓ）は、発行者が発行する証明書の名前の制限情報を格納するフィールドである。
制約ポリシー（ｐｏｌｉｃｙ　Ｃｏｎｓｔｒａｉｎｔｓ）は、認証パス中のポリシーの関係の制限情報を格納するフィールドである。
ＣＲＬ参照ポイント（Ｃｅｒｔｉｆｉｃａｔｅ　Ｒｅｖｏｃａｔｉｏｎ　Ｌｉｓｔ　Ｄｉｓｔｒｉｂｕｔｉｏｎ　Ｐｏｉｎｔｓ）は、証明書所有者が証明書を利用する際に、証明書が失効していないか、どうかを確認するための失効リストの参照ポイントを記述するフィールドである。
署名アルゴリズム（Ｓｉｇｎａｔｕｒｅ　Ａｌｇｏｒｉｔｈｍ）は、証明書の署名付けに用いるアルゴリズムを格納するフィールドである。
署名は、公開鍵証明書発行者の署名フィールドである。電子署名は、証明書全体に対しハッシュ関数を適用してハッシュ値を生成し、そのハッシュ値に対して発行者の秘密鍵を用いて生成したデータである。署名付けやハッシュをとるだけでは改竄は可能であるが、検出できれば実質的に改竄できないことと同様の効果がある。
【００５４】
認証局は、図２〜図４に示す公開鍵証明書を発行するとともに、有効期限が切れた公開鍵証明書を更新し、不正を行った利用者の排斥を行うための失効リスト（Ｒｅｖｏｃａｔｉｏｎ　Ｌｉｓｔ）の作成、管理、配布（これをリボケーション：Ｒｅｖｏｃａｔｉｏｎと呼ぶ）を行う。また、必要に応じて公開鍵・秘密鍵の生成も行う。
【００５５】
一方、この公開鍵証明書を利用する際には、利用者は自己が保持する認証局の公開鍵を用い、当該公開鍵証明書の電子署名を検証し、電子署名の検証に成功した後に公開鍵証明書から公開鍵を取り出し、当該公開鍵を利用する。従って、公開鍵証明書を利用する全ての利用者は、共通の認証局の公開鍵を保持している必要がある。
【００５６】
（属性証明書：ＡＣ）
権限管理基盤（ＰＭＩ：ＰｒｉｖｉｌｅｇｅｍａｎａｇｅｍｅｎｔＩｎｆｒａｓｔｒｕｃｔｕｒｅ）１０２は、属性証明書（ＡＣ：Ａｔｔｒｉｂｕｔｅｃｅｒｔｉｆｉｃａｔｅ）１２２を適用した権限確認処理を実行可能とする基盤（インフラ）である。属性証明書の１形態としてのグループ属性証明書（グループＡＣ）について図５乃至図７を参照して説明する。本発明におけるシステムで適用する属性証明書の機能は、アクセス権限、サービス利用権限の確認機能であり、属性証明書には、例えば特定の通信処理装置としてのユーザデバイス（エンドエンティテイ）に対するアクセス許可情報として適用可能な所有者の属性情報が記述される。
【００５７】
属性証明書は、基本的には属性認証局／属性証明書発行局（ＡＡ：Ａｔｔｒｉｂｕｔｅ　Ａｕｔｈｏｒｉｔｙ）が発行する証明書であり、証明書発行対象の属性情報を格納し、属性認証局／属性証明書発行局側がＩＤや有効期限等の情報を付加し、さらに属性認証局／属性証明書発行局の秘密鍵による署名を付加して作成される証明書である。ただし、以下において説明するグループ属性証明書は、必ずしも属性認証局／属性証明書発行局（ＡＡ：Ａｔｔｒｉｂｕｔｅ　Ａｕｔｈｏｒｉｔｙ）が発行機関として限定されるものではなく、サービスプロバイダ、ホームサーバ等の中継サーバ、ユーザデバイスにおける発行処理が可能である。
【００５８】
なお、属性認証局／属性証明書発行局（ＡＡ）の事務代理機関として、属性証明書登録局（ＡＲＡ：Ａｔｔｒｉｂｕｔｅ　Ｒｅｇｉｓｔｒａｔｉｏｎ　Ａｕｔｈｏｒｉｔｙ）を設け、属性証明書登録局（ＡＲＡ）において、属性証明書（ＡＣ）の発行申請受理、申請者の審査、管理を行なう構成により、処理負荷の分散が可能である。
【００５９】
本発明の構成において適用されるグループ属性証明書（グループＡＣ）は、複数の対象、例えば複数のユーザ、あるいは複数のユーザ機器を１つの同一属性集合としたグループとして設定し、設定したグループを単位として、グループの構成機器または構成ユーザに対して発行される属性証明書である。グループ属性証明書は、特定機器または特定ユーザの集合からなるグループに対応して設定されるグループ識別情報を格納情報とするとともに発行者の電子署名の付加された証明書である。
【００６０】
例えば複数人が所属している会社、組織、学校といった属性、あるいは家族といったグループに属する各ユーザまたはユーザ機器に対して発行される。あるいは、１つのサービスプロバイダの提供するサービスを受領する複数のユーザ単位といったグループのメンバ（ユーザ、ユーザ機器）に対して発行される。また、例えばドメイン名、ホスト名によるグループ定義が適用可能である。グループについては、様々な設定が可能であり、具体例については、後述する。
【００６１】
属性証明書の基本フォーマットはＩＴＵ−Ｔ　Ｘ．５０９で規定されており，ＩＥＴＦ　ＰＫＩＸ　ＷＧでＰｒｏｆｉｌｅを策定している。公開鍵証明書とは異なり所有者の公開鍵を含まない。しかし属性証明書認証局（Ａｔｔｒｉｂｕｔｅ　Ｃｅｒｔｉｆｉｃａｔｅ　Ａｕｔｈｏｒｉｔｙ）の署名がついているため、改竄されていないかどうかの判定はこの署名を検証することで行える、という点は公開鍵証明書と同様である。
【００６２】
なお、本発明において適用するグループ属性証明書は、属性証明書の基本フォーマットに準拠したものとして構成可能である。ただし、ＩＴＵ−Ｔ　Ｘ．５０９で規定されたフォーマットに従うことが必須ではなく、独自フォーマットとした属性証明書構成としてもよい。
【００６３】
本発明の構成においては、属性証明書（ＡＣ）の発行管理を行なう属性証明書認証局（ＡＡ：Ａｔｔｒｉｂｕｔｅ　Ｃｅｒｔｉｆｉｃａｔｅ　Ａｕｔｈｏｒｉｔｙ）、および属性証明書登録局（ＡＲＡ）の機能を、サービスプロバイダ、ホームサーバ、あるいはユーザデバイスが兼務することが可能である。すなわち、サービスプロバイダ、ホームサーバあるいはユーザデバイス自身が、属性証明書認証局（ＡＡ）、属性証明書登録局（ＡＲＡ）の各機能を果たす構成が可能である。
【００６４】
属性証明書は基本的に公開鍵証明書と関連づけて利用する。すなわち属性証明書所有者の本人性自体は公開鍵証明書で確認し、その上で所有者にいかなる権限が与えられているかを属性証明書によって確認する。例えば特定のユーザデバイス（エンドエンティテイ）に対するアクセス権限があるか否かを、そのユーザデバイス（エンドエンティテイ）を管轄する中継サーバとしてのホームサーバがアクセス要求元の属性証明書を検証して確認する。属性証明書の検証にあたっては、当該証明書の署名検証を行った後、その属性証明書に関連づけられている公開鍵証明書の検証も行う。
【００６５】
なお、その際、原則的には証明書連鎖をたどって最上位の公開鍵証明書まで順に検証を実施することが好ましい。複数の認証局（ＣＡ）が存在し、階層構成をなす認証局構成では、下位の認証局自身の公開鍵証明書は、その公開鍵証明書を発行する上位認証局によって署名されている。すなわち、下層の公開鍵証明書発行局（ＣＡ−Ｌｏｗ）に対して上位の公開鍵証明書発行局（ＣＡ−Ｈｉｇｈ）が公開鍵証明書を発行するという連鎖的な公開鍵証明書発行構成をとる。公開鍵証明書の連鎖検証とは、下位から上位へ証明書連鎖をたどって最上位の公開鍵証明書までの連鎖情報を取得して、最上位（ル−トＣＡ）までの公開鍵証明書の署名検証を行なうことを意味する。
【００６６】
属性証明書の有効期間を短期間とすることにより、失効処理を行わないことも可能である。この場合、証明書の失効手続きや失効情報の参照手順等を省くことができ、システムが簡易となる長所がある。ただし証明書の不正利用に対しては失効以外の何らかの対策が必要となるため、十分に注意しなければならない。
【００６７】
図５を参照してグループ属性証明書の構成について説明する。
証明書のバージョン番号は、証明書フォーマットのバージョンを示す。
ＡＣ保持者の公開鍵証明書情報、これは属性証明書（ＡＣ）の発行者に対応する公開鍵証明書（ＰＫＣ）に関する情報であり、ＰＫＣ発行者名、ＰＫＣシリアル番号、ＰＫＣ発行者固有識別子等の情報であり、対応公開鍵証明書を関連づけるリンクデータとしての機能を持つ。
属性証明書の発行者の名前は、属性証明書の発行者、すなわち属性証明書認証局（ＡＡ）の名称が識別可能な形式（Ｄｉｓｔｉｎｇｕｉｓｈｅｄ　Ｎａｍｅ）で記録されるフィールドである。
署名アルゴリズム識別子は、属性証明書の署名アルゴリズム識別子を記録するフィールドである。
証明書の有効期限は、証明書の有効期限である開始日時、終了日時が記録される。
属性情報フィールドには、グループ属性証明書のグループを識別するグループ識別情報としてグループＩＤ、ドメイン名、ホスト名など、グループを特定する属性情報が格納される。
【００６８】
なお、属性情報フィールドには、グループ識別情報（グループＩＤ、ドメイン名、ホスト名など、）以外にも、様々な情報が格納可能であり、例えば、アクセス権限期間情報、その他アクセス権限に関する詳細情報を格納することが可能である。
【００６９】
属性証明書には、さらに、署名アルゴリズムが記録され、属性証明書発行者、例えば属性証明書認証局（ＡＡ）によって署名が施される。発行者がサービスプロバイダ、ホームサーバ、あるいはユーザデバイスである場合は、各発行者の署名がなされる。電子署名は、属性証明書全体に対しハッシュ関数を適用してハッシュ値を生成し、そのハッシュ値に対して属性証明書発行者の秘密鍵を用いて生成したデータである。
【００７０】
グループ属性証明書は、グループ属性証明書を発行するエンティテイ、例えば属性証明書認証局（ＡＡ：Ａｔｔｒｉｂｕｔｅ　Ｃｅｒｔｉｆｉｃａｔｅ　Ａｕｔｈｏｒｉｔｙ）、属性証明書認証局（ＡＡ）の事務代行を行なう属性証明書登録局（ＡＲＡ：Ａｔｔｒｉｂｕｔｅ　Ｒｅｇｉｓｔｒａｔｉｏｎ　Ａｕｔｈｏｒｉｔｙ）、あるいはサービスプロバイダ、ホームサーバ、ユーザデバイスにおいて管理される発行ポリシーに基づいて発行処理がなされる。
【００７１】
グループ属性証明書を発行するエンティテイは、発行ポリシーテーブルを有し、自己が発行したグループ属性証明書のグループ識別情報（グループＩＤ、ドメイン名、ホスト名など）、グループ情報、発行基準等の発行ポリシーとを対応付けたデータを有する。また、グループ属性証明書の新規発行、追加発行、更新処理等に際し、グループ属性証明書の発行ポリシーテーブルに基づいて、審査が実行され、ポリシーを満足する場合に限り、発行、更新等の手続きがなされる。
【００７２】
図６にグループ属性証明書（グループＡＣ）の発行者、所有者、検証者、属性情報の構成例を示す。
【００７３】
（ａ）は単一機器によるグループであり、発行者：鈴木家ホームサーバ（ＨＳ）、所有者：鈴木一郎の携帯電話、グループ：鈴木一郎として定義されたグループのグループ属性証明書（グループＡＣ）である。（ｂ）は複数機器によるグループであり、発行者：鈴木家ホームサーバ（ＨＳ）、所有者：鈴木家のホームサーバ（ＨＳ）、ビデオカメラ、冷蔵庫の各機器であり、グループ：鈴木一郎所有機器、として定義されたグループのグループ属性証明書（グループＡＣ）である。
【００７４】
（ｃ）は複数機器によるグループであり、発行者：メーカーＸ、所有者：ビデオデッキの各機器であり、グループ：メーカーＸ製造のビデオデッキ、として定義されたグループのグループ属性証明書（グループＡＣ）である。（ｄ）は複数ユーザによるグループであり、発行者：グループ属性証明書認証局（ＡＡ）、所有者：鈴木家のメンバーであり、グループ：鈴木家、として定義されたグループのグループ属性証明書（グループＡＣ）である。
【００７５】
（ｅ）はドメイン名によるグループ定義のされたドメイン名属性証明書であり、例えば発行者：ドメイン名グループ属性証明書認証局（ＡＡ）、所有者：鈴木家ＨＳ、テレビ、カメラであり、グループドメイン：ｓｕｚｕｋｉ．ａｂｃ．ｎｅｔ、として定義されたグループのグループ属性証明書（グループＡＣ）である。同じドメインに属する通信処理装置は、同じグループドメインを属性情報として有するドメイン名グループ属性証明書を保有することになる。
【００７６】
（ｆ）はホスト名によるグループ定義のされたホスト名属性証明書であり、例えば発行者：ホスト名グループ属性証明書認証局（ＡＡ）、所有者：鈴木家テレビであり、グループホスト名：ｔｖ１．ｓｕｚｕｋｉ．ａｂｃ．ｎｅｔ、として定義されたグループのグループ属性証明書（グループＡＣ）である。
【００７７】
上述のような、様々な定義のグループの所属機器またはユーザを対象としてグループ属性証明書が発行される場合、発行されたグループ属性証明書は、ユーザの所有する機器内に格納される。ユーザデバイスの詳細については後述する。
【００７８】
ユーザデバイスに対して発行されたグループ属性証明書に基づいてアクセス権限確認を実行する検証者は、例えば、図１に示すホームサーバ等の中継サーバであり、中継サーバの管理領域内のユーザデバイス（通信処理装置）に対するアクセスの要求機器からグループ属性証明書を受領して、受領したグループ属性証明書の検証および審査を実行して、アクセス権限が確認されたことを条件として名前解決サーバに対してホスト名からアドレスへの変換処理を依頼し、取得アドレスをアクセス要求元に通知することで、受領アドレスを適用した通信が可能となる。属性証明書の検証、審査の結果、アクセス権限が認められない場合は、名前解決サーバによるホスト名からアドレスへの変換が実行されず、アクセス要求元はアクセス要求先のアドレスを得ることができず、通信処理は実行されない。
【００７９】
図６を参照して説明した様々なグループ定義に基づくグループ属性証明書中の（ｅ）ドメイン名グループ、（ｆ）ホスト名グループの各グループ定義に基づく属性証明書構成例を図７に示す。（ｅ）ドメイン名グループ属性証明書は、属性情報フィールドにドメイン名が記述され、特定のドメインが識別される。一方、（ｆ）ホスト名グループ属性証明書は、属性情報フィールドにホスト名が記述され、特定のホストが識別可能となる。
【００８０】
図８を参照して、ドメイン名グループ属性証明書の発行体系について説明する。ドメイン名グループ属性証明書は、原則的に所属ドメインの上位のドメイン名属性証明書登録局（ＡＲＡ：Ａｔｔｒｉｂｕｔｅ　Ｒｅｇｉｓｔｒａｔｉｏｎ　Ａｕｔｈｏｒｉｔｙ）を通じてドメイン名属性証明書認証局（ＡＡ）から発行される。なお、ドメイン名ＡＡは単一であるとは限らず、複数存在してもよい。また、ドメインの公共性を考慮して運営主体は独立した事業体であることが望ましい。
【００８１】
図８には、ドメインとして上位から、ａｂｃ．ｎｅｔドメイン１５１、ｈｏｍｅ１．ａｂｃ．ｎｅｔドメイン１５２、ｓｕｂ．ｈｏｍｅ１．ａｂｃ．ｎｅｔドメイン１５３の３ドメイン領域が示されている。上位ドメインは、下位ドメインを含む構成である。
【００８２】
ａｂｃ．ｎｅｔドメイン１５１のサービスプロバイダ１５５に対するドメイン名グループ属性証明書は、上位のドメイン名属性証明書登録局（ＡＲＡ）であるセカンドレベルドメイン割当機関１５４が、サービスプロバイダ１５５の要求に基づいて、発行ポリシーに基づく発行手続きを行ない、ポリシーに従っていることを条件として、ドメイン名属性証明書認証局（ＡＡ）１５０の発行したドメイン名グループ属性証明書１６１をサービスプロバイダ１５５に送付する。
【００８３】
ａｂｃ．ｎｅｔドメイン１５１の下位ドメインであるｈｏｍｅ１．ａｂｃ．ｎｅｔドメイン１５２のホームサーバ１５６、または、エンドエンティテイ（ユーザデバイス）であるＥＥ　Ａ１５８に対するドメイン名グループ属性証明書は、上位のドメイン名属性証明書登録局（ＡＲＡ）であるサービスプロバイダ１５５が、ホームサーバ１５６、ＥＥ　Ａ１５８の要求に基づいて、発行ポリシーに基づく発行手続きを行ない、ポリシーに従っていることを条件として、ドメイン名属性証明書認証局（ＡＡ）１５０の発行したドメイン名グループ属性証明書１６２，１６３をホームサーバ１５６、ＥＥ　Ａ１５８に送付する。
【００８４】
ｈｏｍｅ１．ａｂｃ．ｎｅｔドメイン１５２の下位ドメインであるｓｕｂ．ｈｏｍｅ１．ａｂｃ．ｎｅｔドメイン１５３のホームサーバ１５７、または、エンドエンティテイ（ユーザデバイス）であるＥＥ　Ｐ１５９、ＥＥ　Ｑ１６０に対するドメイン名グループ属性証明書は、上位のドメイン名属性証明書登録局（ＡＲＡ）であるホームサーバ１５６が、ホームサーバ１５７、ＥＥ　Ｐ１５９、ＥＥ　Ｑ１６０の要求に基づいて、発行ポリシーに基づく発行手続きを行ない、ポリシーに従っていることを条件として、ドメイン名属性証明書認証局（ＡＡ）１５０から発行されたドメイン名グループ属性証明書１６４〜１６６をホームサーバ１５７、ＥＥ　Ｐ１５９、ＥＥ　Ｑ１６０に送付する。
【００８５】
このように、ドメイン名グループ属性証明書は、上位のドメイン名属性証明書登録局（ＡＲＡ）が、下位のドメインに属するメンバー（機器）に対して発行ポリシーに従って発行する処理を実行する。
【００８６】
次に、図９を参照してホスト名グループ属性証明書の発行体系について説明する。ホスト名グループ属性証明書は、原則的に所属ドメインのホスト名属性証明書登録局（ＡＲＡ：Ａｔｔｒｉｂｕｔｅ　Ｒｅｇｉｓｔｒａｔｉｏｎ　Ａｕｔｈｏｒｉｔｙ）を通じてドメイン名属性証明書認証局（ＡＡ）から発行される。なお、ホスト名ＡＡはサービスプロバイダが運営してもよい。
【００８７】
図９には、図８と同様、ドメインとして上位から、ａｂｃ．ｎｅｔドメイン、ｈｏｍｅ１．ａｂｃ．ｎｅｔドメイン、ｓｕｂ．ｈｏｍｅ１．ａｂｃ．ｎｅｔドメインの３ドメインのそれぞれに属するエンティテイが記載され、ａｂｃ．ｎｅｔドメインには、サービスプロバイダ１５５が所属し、ｈｏｍｅ１．ａｂｃ．ｎｅｔドメインには、ホームサーバ１５６、およびエンドエンティテイ（ユーザデバイス）であるＥＥ　Ａ１５８が所属し、ｓｕｂ．ｈｏｍｅ１．ａｂｃ．ｎｅｔドメインには、ホームサーバ１５７、およびエンドエンティテイ（ユーザデバイス）であるＥＥ　Ｐ１５９、ＥＥ　Ｑ１６０が所属している。
【００８８】
ｈｏｍｅ１．ａｂｃ．ｎｅｔドメインのホームサーバ１５６、または、エンドエンティテイ（ユーザデバイス）であるＥＥ　Ａ１５８に対するホスト名グループ属性証明書は、所属ドメインに対応するホスト名属性証明書登録局（ＡＲＡ）であるホームサーバ１５６が、発行ポリシーに基づく発行手続きを行ない、ポリシーに従っていることを条件として、ホスト名属性証明書認証局（ＡＡ）１７１から発行されたホスト名グループ属性証明書１７３，１７４をホームサーバ１５６、ＥＥ　Ａ１５８に送付する。
【００８９】
ｈｏｍｅ１．ａｂｃ．ｎｅｔドメイン１５２の下位ドメインであるｓｕｂ．ｈｏｍｅ１．ａｂｃ．ｎｅｔドメイン１５３のホームサーバ１５７、または、エンドエンティテイ（ユーザデバイス）であるＥＥ　Ｐ１５９、ＥＥ　Ｑ１６０に対するホスト名グループ属性証明書は、所属ドメインに対応するホスト名属性証明書登録局（ＡＲＡ）であるホームサーバ１５７が、発行ポリシーに基づく発行手続きを行ない、ポリシーに従っていることを条件として、ホスト名属性証明書認証局（ＡＡ）１７２から発行されたドメイン名グループ属性証明書１７５〜１７７をホームサーバ１５７、ＥＥ　Ｐ１５９、ＥＥ　Ｑ１６０に送付する。
【００９０】
このように、ホスト名グループ属性証明書は、対応するドメイン内のドメイン名属性証明書登録局（ＡＲＡ）が、自己のドメインに属するメンバーに対して発行ポリシーに従って発行する処理を実行する。
【００９１】
発行された属性証明書は、サービスプロバイダの機器内のセキュリティモジュール（ＳＭ：Ｓｅｃｕｒｉｔｙ　Ｍｏｄｕｌｅ）、あるいはホームサーバ等の中継サーバ、あるいはユーザデバイスのセキュリティチップ（ＳＣ：Ｓｅｃｕｒｉｔｙ　Ｃｈｉｐ）での署名検証による検証の後、格納される。ホームサーバ等の中継サーバ、ユーザデバイスのセキュリティチップ、サービスプロバイダの機器内のセキュリティモジュールは、外部からのデータ読み出しの制限された耐タンパ構成を持つことが好ましい。
【００９２】
図１０にアクセス権限管理システムに参加する各エンティテイの信頼関係構成を説明するトラストモデルを示す。
【００９３】
システムホルダ（ＳＨ：Ｓｙｓｔｅｍ　Ｈｏｌｄｅｒ）１８０は、本発明のアクセス権限管理システム全体の統括的管理を行なう主体、すなわちシステム運用主体であり、システムに参加する各エンティテイのセキュリティチップ（ＳＣ）、セキュリティモジュール（ＳＭ）の正当性を保証するとともに、公開鍵証明書（ＰＫＣ）の発行責任を持つ。システムホルダ（ＳＨ）１８０は、最上位認証局としてのルートＣＡ（ＲｏｏｔＣＡ）１８１、階層構成の複数の認証局（ＣＡ）１８２、および公開鍵証明書発行事務局としての登録局（ＲＡ）１８３を有する。
【００９４】
システムホルダ（ＳＨ：Ｓｙｓｔｅｍ　Ｈｏｌｄｅｒ）１８０は、属性証明書認証局（ＡＡ）１８４、属性証明書登録局（ＡＲＡ）１８５、サービスプロバイダ１８７、ドメイン領域１９０に属する中継サーバとしてのホームサーバ１９２、およびユーザデバイスとしてのエンドエンティテイ（ＥＥ）１９１の各エンティテイに対応する公開鍵証明書（ＰＫＣ）を発行し、各エンティテイは、必要とするエンティテイの公開鍵証明書を格納する。
【００９５】
また、グループ属性証明書（グループＡＣ）は、サービスプロバイダ１８７、中継サーバとしてのホームサーバ１９２、およびユーザデバイスとしてのエンドエンティテイ（ＥＥ）１９１の各エンティ等からの要求にしたがって、それぞれのエンティテイに対応して設定される属性証明書登録局（ＡＲＡ）１８５においてポリシー（発行条件等）に従って属性証明書発行審査を行ない、発行可と判定された場合に属性証明書認証局（ＡＡ）１８４に対して、属性証明書登録局（ＡＲＡ）１８５から発行依頼を転送する。
【００９６】
属性証明書認証局（ＡＡ）１８４は、グループ属性証明書発行依頼に基づいて、先に説明したドメイン名、あるいはホスト名、グループＩＤなどの情報をグループ識別情報として属性情報領域に格納し、属性証明書認証局（ＡＡ）１８４の秘密鍵による署名を付加したグループ属性証明書（図５参照）を発行要求者に対して発行する。
【００９７】
なお、前述したように、これら属性証明書認証局（ＡＡ）１８４、および属性証明書登録局（ＡＲＡ）１８５は、サービスプロバイダ、ホームサーバ、あるいはユーザデバイスがその機能を実行する構成とすることも可能である。
【００９８】
［（２）セキュリティチップ構成］
次に通信ネットワークを介した通信を実行する通信処理装置としてのユーザデバイスあるいは中継サーバとしてのホームサーバ、およびサービスプロバイダ等に構成されるセキュリティチップ（またはモジュール）の構成について説明する。なお、ユーザデバイスは、通信実行機器としてのエンドエンティテイ（ＥＥ）であり、他の通信処理装置との通信を実行するインタフェースを持つ例えばＰＣ、ホームサーバ、ＰＤＡ等の携帯端末、ＩＣカード等、各種データ処理装置である。
【００９９】
通信処理装置としてのユーザデバイス（エンドエンティテイ）あるいは中継サーバとしてのホームサーバ、およびサービスプロバイダなどに構成されるセキュリテイチップ（またはモジュール）の構成例について、図１１を参照して説明する。
【０１００】
図１１に示すように、ユーザデバイス（エンドエンティテイ）あるいは中継サーバとしてのホームサーバ、およびサービスプロバイダなどのデバイス２００には、セキュリティチップ２１０が、デバイス側制御部２２１に対して、相互にデータ転送可能な構成として内蔵される。
【０１０１】
セキュリティチップ２１０は、プログラム実行機能、演算処理機能を持つＣＰＵ（Ｃｅｎｔｒａｌ　Ｐｒｏｃｅｓｓｉｎｇ　Ｕｎｉｔ）２０１を有し、データ通信用のインタフェース機能を持つ通信インタフェース２０２、ＣＰＵ２０１によって実行される各種プログラム、例えば暗号処理プログラムなどを記憶するＲＯＭ（Ｒｅａｄ　Ｏｎｌｙ　Ｍｅｍｏｒｙ）２０３、実行プログラムのロード領域、また、各プログラム処理におけるワーク領域として機能するＲＡＭ（Ｒａｎｄｏｍ　Ａｃｃｅｓｓ　Ｍｅｍｏｒｙ）２０４、外部機器との認証処理、電子署名の生成、検証処理、格納データの暗号化、復号化処理等の暗号処理を実行する暗号処理部２０５、各種鍵データを含むデバイスの固有情報を格納した例えばＥＥＰＲＯＭ（Ｅｌｅｃｔｒｉｃａｌｌｙ　Ｅｒａｓａｂｌｅ　Ｐｒｏｇｒａｍｍａｂｌｅ　ＲＯＭ）によって構成されるメモリ部２０６を有する。
【０１０２】
デバイス２００は、暗号化コンテンツあるいはサービス情報等を格納する領域としてのＥＥＰＲＯＭ、ハードディスク等によって構成される外部メモリ部２２２を有する。外部メモリ部２２２は、公開鍵証明書、グループ属性証明書の格納領域としても利用可能である。
【０１０３】
セキュリティチップを搭載したユーザデバイスが、外部エンティテイ、例えばネットワーク接続された他のユーザデバイス、中継サーバとしてのホームサーバ、あるいはサービスプロバイダと接続して通信処理を実行する場合には、ネットワークインタフェース２３２を介した接続を実行する。ただし、ネットワークインタフェース２３２を持たないユーザデバイスは、接続機器インタフェース２３１を介して通信機能を持つエンドエンティテイ（ＥＥ）に接続して、エンドエンティテイのネットワークインタフェース２３２を介した通信を実行する。
【０１０４】
図１１に示すセキュリティチップを持つユーザデバイスあるいは中継サーバとしてのホームサーバ、およびサービスプロバイダ等が接続し、エンティテイ間でデータ転送を実行する場合には、必要に応じて相互認証が行われる。これらの処理の詳細については、後段で詳述する。
【０１０５】
ユーザデバイスのセキュリティチップの格納データ例を図１２に示す。これらの多くは、不揮発性メモリの一形態であるフラッシュメモリ等のＥＥＰＲＯＭ（Ｅｌｅｃｔｒｉｃａｌｌｙ　Ｅｒａｓａｂｌｅ　Ｐｒｏｇｒａｍｍａｂｌｅ　ＲＯＭ）によって構成されるメモリ部２０６に格納されるが、公開鍵証明書、グループ属性証明書は、セキュリティチップ内のメモリに格納しても、外部メモリに格納してもよい。
【０１０６】
各データについて説明する。
公開鍵証明書（ＰＫＣ）：公開鍵証明書は、第三者に対して正当な公開鍵であることを示す証明書で、証明書には配布したい公開鍵を含み、信頼のおける認証局により電子署名がなされている。ユーザデバイスには、前述した階層構成の最上位認証局（ルートＣＡ）の公開鍵証明書、ユーザデバイスに対するサービスを提供するサービスプロバイダの公開鍵証明書等、ユーザデバイスとのデータ通信を実行する際の認証、暗号化、復号処理等に適用する公開鍵を取得するために必要となる公開鍵証明書が格納される。
【０１０７】
グループ属性証明書（ＡＣ）：公開鍵証明書が証明書利用者（所有者）の“本人性”を示すのに対し、グループ属性証明書は証明書利用者のグループを識別しグループの構成メンバに付与された利用権限を確認するものである。利用者はグループ属性証明書を提示することにより、グループ属性証明書に記載された権利・権限に基づいて、アクセスが行えるようになる。なお、グループ属性証明書は所定の発行手続きに基づいて発行される。これらの処理の詳細は後述する。
【０１０８】
鍵データ：鍵データとしては、セキュリティチップに対して設定される公開鍵、秘密鍵のペア、さらに、乱数生成用鍵、相互認証用鍵等が格納される。
【０１０９】
識別情報：識別情報としては、セキュリティチップ自身の識別子としてのセキュリティチップＩＤが格納される。さらに継続的なサービス提供を受けるサービスプロバイダ（ＳＰ）の識別子としてのサービスプロバイダＩＤ、ユーザデバイスを利用するユーザに付与されたユーザＩＤ、サービスプロバイダの提供するサービスに対応するアプリケーションを識別するアプリケーションＩＤ等が格納可能である。
【０１１０】
その他：ユーザデバイスには、さらに、乱数生成用のシード情報、すなわち認証処理、暗号処理等の際に適用する乱数をＡＮＳＩ　Ｘ９．１７に従って生成するための情報や、様々な利用制限が付加されたサービスに関する利用情報、例えば、コンテンツ利用回数制限が付加されたコンテンツを利用した際に更新されるコンテンツ利用回数情報、あるいは決済情報等の情報、あるいは、各情報に基づいて算出されるハッシュ値が格納される。
【０１１１】
なお、図１２に示すデータ構成例は、一例であり、この他にも必要に応じて、ユーザデバイスの受領するサービスに関連する各種の情報が格納可能である。
【０１１２】
なお、データ送受信部であるネットワークインタフェースを介して受信したグループ属性証明書の検証処理の実行、あるいは、グループ属性証明書の生成処理の実行手段としても図１１に示すセキュリティチップ構成が適用される。
【０１１３】
［（３）アクセス制限処理］
（３−１）アクセス制限処理概要
次に、ドメイン名、ホスト名、団体、学校、会社、あるいは１つの家族等、様々な集合に属するユーザ、あるいは、同一メーカの機器、同一サービスプロバイダのサービスを受領するユーザ、機器等、複数のユーザまたは機器をグループとして設定し、グループに属するユーザまたは機器の各々に対して発行するグループ属性証明書に基づくアクセス制限処理の詳細について説明する。
【０１１４】
グループ属性証明書は、ネットワークを介した通信を実行しようとするユーザまたは機器（ユーザデバイス）が特定のグループに属することを確認可能な証明書であり、他の通信処理装置に対するアクセス要求に際して、通信相手となる通信処理装置（ユーザデバイス）を管理するホームサーバ等の中継サーバに提示する。
【０１１５】
図１３を参照して、アクセス権限管理システムの概要について説明する。図１３において、ホームサーバ等の中継サーバ１，３１３は、エンドエンティテイ通信処理装置としてのユーザデバイス（ＥＥ−Ａ）３１１を管理端末として有し、ユーザデバイス（ＥＥ−Ａ）３１１に対する通信ネットワーク３５５を介したアクセスの許可、不許可について、アクセス要求元から送付される属性証明書、およびアクセス許可情報を格納した許可グループデータベース３１４の格納情報に基づいて判定する。
【０１１６】
一方ホームサーバ等の中継サーバ２，３２３は、通信処理装置としてのユーザデバイス３２１を管理端末として有し、ユーザデバイス３２１に対する通信ネットワーク３５５を介したアクセスの許可、不許可について、アクセス要求元から送付される属性証明書およびアクセス許可情報を格納した許可グループデータベース３２４の格納情報に基づいて判定する。
【０１１７】
ユーザデバイス３１１とホームサーバ等の中継サーバ１，３１３とは、ある特定のサブネットワーク名にあり、例えばイーサネット等の有線あるいは無線ＬＡＮ、その他の通信ネットワークにより接続される。
【０１１８】
図１３の中継サーバ１，３１３は、アクセス要求元から提示されるグループ属性証明書に基づいて、自己の管理領域内のユーザデバイス３１４に対するアクセス権限を判定し、アクセス権限があると判定されたことを条件として、ＤＮＳ（Ｄｏｍａｉｎ　Ｎａｍｅ　Ｓｙｓｔｅｍ）としての名前解決サーバ３１２によるホスト名からアドレスへの変換処理を実行し、アドレスデータをアクセス要求元に対して通知する。中継サーバ２，３２３も、同様にアクセス要求元から提示されるグループ属性証明書に基づいて、自己の管理領域内のユーザデバイス３２４に対するアクセス要求のアクセス権限を判定し、同様の処理を実行する。
【０１１９】
図１３に示すサービスプロバイダ（ＳＰ１）３３１は、中継サーバ３１３の上位ドメイン領域に属するサービスプロバイダであり、中継サーバ３１３または、ユーザデバイス３１１に対するドメイン名属性証明書の発行手続きを実行する属性証明書登録局（ＡＲＡ）として機能し、中継サーバ３１３または、ユーザデバイス３１１からの属性証明書発行要求に応じて、サービスプロバイダ（ＳＰ１）３３１が、発行ポリシーに基づく発行手続きを行ない、ポリシーに従っていることを条件として、ドメイン名属性証明書認証局（ＡＡ）３５１から発行されたドメイン名属性証明書を中継サーバ３１３または、ユーザデバイス３１１に送付する。
【０１２０】
サービスプロバイダ（ＳＰ２）３４１は、中継サーバ３２３の上位ドメイン領域に属するサービスプロバイダであり、中継サーバ３２３または、ユーザデバイス３２１に対するドメイン名属性証明書の発行手続きを実行する属性証明書登録局（ＡＲＡ）として機能し、中継サーバ３２３または、ユーザデバイス３２１からの属性証明書発行要求に応じて、サービスプロバイダ（ＳＰ２）３４１が、発行ポリシーに基づく発行手続きを行ない、ポリシーに従っていることを条件として、ドメイン名属性証明書認証局（ＡＡ）３５２から発行されたドメイン名属性証明書を中継サーバ３２３または、ユーザデバイス３２１に送付する。
【０１２１】
また、サービスプロバイダ（ＳＰ１）３３１、サービスプロバイダ（ＳＰ２）３４１も、通信ネットワーク３５５を介した通信処理においてそれぞれの名前解決サーバ３３３，３４３により、ホスト名からアドレスへの変換処理を実行し、アドレスデータをアクセス要求元に対して通知する処理を実行する。
【０１２２】
サービスプロバイダ（ＳＰ１）３３１の利用する名前解決サーバ３３３、および、中継サーバ３１３の利用する名前解決サーバ３１２の有するデータベース例を図１４に示す。
【０１２３】
図１４（ａ）は、サービスプロバイダ（ＳＰ１）３３１の利用する名前解決サーバ３３３のデータベース例であり、自己の属するドメイン［ａｂｃ．ｎｅｔ］の配下のドメインに対応するドメイン名に対応するアドレス空間、および中継サーバとしてのホームサーバのＩＰアドレスの各データが格納された構成を持つ。
【０１２４】
図１４（ｂ）は、中継サーバ３１３の利用する名前解決サーバ３１２の有するデータベース例であり、自己の属するドメイン［ｈｏｍｅ１．ａｂｃ．ｎｅｔ］に属する機器のホスト名に対応するＩＰアドレスが格納され、さらに上位ドメインの名前解決サーバ、図１３の構成では名前解決サーバ３３３のＩＰアドレスデータが格納されている。
【０１２５】
サービスプロバイダ、ホームサーバ等の中継サーバは、通信ネットワークを介する通信処理において、アクセス要求元からホスト名を受信し、名前解決サーバを利用してアドレスを取得して、アドレス情報をアクセス要求元に通知し、アドレスに基づく通信を可能とする処理を実行する。
【０１２６】
（３−２）ドメイン登録および属性証明書発行処理
次に、ドメイン登録申請処理、およびドメイン名属性証明書の取得処理について説明する。
【０１２７】
まず、図１５、図１６を参照して１以上の通信処理装置としてのユーザデバイスを管理するホームサーバによるドメイン登録申請処理、およびドメイン名属性証明書の取得処理手順を説明する。なお、図１５、図１６において、
ホーム名前解決サーバ：ホームサーバの利用する名前解決サーバ、
ホームサーバ：属性証明書に基づく審査に基づいてホーム名前解決サーバを利用した名前解決を実行する中継サーバ、
サービスプロバイダ（ＳＰ）：ホームサーバに対するドメイン名付与を実行するサービスプロバイダ、
ＳＰ名前解決サーバ：サービスプロバイダ（ＳＰ）が名前解決を実行するために利用する名前解決サーバ、
ドメイン名ＡＲＡ：ドメイン名属性証明書登録局、
ドメイン名ＡＡ：ドメイン名属性証明書認証局、
である。
【０１２８】
図１５は、ホームサーバによるドメイン登録申請処理手順を示しており、ステップＳ１１において、ユーザがホームサーバに対してドメイン登録開始処理コマンドを入力すると、ステップＳ１２において、ホームサーバは、自己の属するドメインの管理サービスプロバイダに対してドメイン登録申請を送信する。
【０１２９】
ステップＳ１３では、ホームサーバと、ドメイン登録申請を受領したサービスプロバイダとの間で相互認証処理が実行される。相互認証は、データ送受信を実行する２つのエンティテイ間で相互に相手が正しいデータ通信者であるか否かの確認のために実行される処理である。認証成立を条件として必要なデータ転送を行なう。また、相互認証処理時にセッション鍵の生成を実行して、生成したセッション鍵を共有鍵として、その後は、セッション鍵に基づく暗号化処理を施したデータ転送を行なう構成が好ましい。相互認証方式としては、公開鍵暗号方式、共通鍵暗号方式等、各方式の適用が可能である。
【０１３０】
ここでは、公開鍵暗号方式の１つの認証処理方式であるハンドシェイクプロトコル（ＴＬＳ１．０）について図１７のシーケンス図を参照して説明する。
【０１３１】
図１７において、エンティテイＡ（クライアント）、エンティテイＢ（サーバ）が、通信を実行する２エンティテイであり、ここではホームサーバまたはサービスプロバイダに対応する。まず、（１）エンティテイＢが暗号化仕様を決定するためのネゴシエーション開始要求をハローリクエストとしてエンティテイＡに送信する。（２）エンティテイＡはハローリクエストを受信すると、利用する暗号化アルゴリズム、セッションＩＤ、プロトコルバージョンの候補をクライアントハローとして、エンティテイＢ側に送信する。
【０１３２】
（３）エンティテイＢ側は、利用を決定した暗号化アルゴリズム、セッションＩＤ、プロトコルバージョンをサーバーハローとしてエンティテイＡに送信する。（４）エンティテイＢは、自己の所有するルートＣＡまでの公開鍵証明書（Ｘ．５０９ｖ３）一式をエンティテイＡに送信（サーバ・サーティフィケート）する。なお、証明書連鎖をたどって最上位の公開鍵証明書まで順に検証を実施しない場合には、必ずしもルートＣＡまでの公開鍵証明書（Ｘ．５０９ｖ３）一式を送付する必要はない。（５）エンティテイＢは、ＲＳＡ公開鍵またはＤｉｆｆｉｅ＆Ｈｅｌｌｍａｎ公開鍵情報をエンティテイＡに送信（サーバ・キー・エクスチェンジ）する。これは証明書が利用できない場合に一時的に適用する公開鍵情報である。
【０１３３】
（６）次にエンティテイＢ側は、エンティテイＡに対してサーティフイケート・リクエストとして、エンティテイＡの有する証明書を要求し、（７）エンティテイＢによるネゴシエーション処理の終了を知らせる（サーバハロー終了）。
【０１３４】
（８）サーバハロー終了を受信したエンティテイＡは、自己の所有するルートＣＡまでの公開鍵証明書（Ｘ．５０９ｖ３）一式をエンティテイＢに送信（クライアント・サーティフィケート）する。なお、公開鍵証明書の連鎖検証を行なわない場合は公開鍵証明書の一式送付は必須ではない。（９）エンティテイＡは、４８バイト乱数をエンティテイＢの公開鍵で暗号化してエンティテイＢに送信する。エンティテイＢ、エンティテイＡは、この値をもとに送受信データ検証処理のためのメッセージ認証コード：ＭＡＣ（Ｍｅｓｓａｇｅ　Ａｕｔｈｅｎｔｉｃａｔｉｏｎ　Ｃｏｄｅ）生成用のデータ等を含むマスターシークレットを生成する。
【０１３５】
（１０）エンティテイＡは、クライアント証明書の正しさを確認するため、ここまでのメッセージのダイジェストをクライアントの秘密鍵で暗号化してエンティテイＢに送信（クライアントサーティフィケート確認）し、（１１）先に決定した暗号化アルゴリズム、鍵利用の開始を通知（チェンジ・サイファー・スペック）し、（１２）認証の終了を通知する。一方、（１３）エンティテイＢ側からエンティテイＡに対しても、先に決定した暗号化アルゴリズム、鍵利用の開始を通知（チェンジ・サイファー・スペック）し、（１４）認証の終了を通知する。
【０１３６】
上記処理において決定された暗号化アルゴリズムに従ってエンティテイＡとエンティテイＢ間のデータ転送が実行されることになる。
【０１３７】
データ改竄の検証は、上述の認証処理でエンティテイＡとエンティテイＢ間の合意のもとに生成されたマスターシークレットから算出されるメッセージ認証コード：ＭＡＣ（Ｍｅｓｓａｇｅ　Ａｕｔｈｅｎｔｉｃａｔｉｏｎ　Ｃｏｄｅ）を各エンティテイの送信データに付加することでメッセージの改竄検証を行なう。
【０１３８】
図１８にメッセージ認証コード：ＭＡＣ（Ｍｅｓｓａｇｅ　Ａｕｔｈｅｎｔｉｃａｔｉｏｎ　Ｃｏｄｅ）の生成構成を示す。データ送信側は、送信データに対して、認証処理において生成したマスターシークレットに基づいて生成されるＭＡＣシークレットを付加し、これらの全体データからハッシュ値を計算し、さらにＭＡＣシークレット、パディング、ハッシュ値に基づいてハッシュ算出を行なってメッセージ認証コード（ＭＡＣ）を生成する。この生成したＭＡＣを送信データに付加して、受信側で受信データに基づいて生成したＭＡＣと受信ＭＡＣとの一致が認められればデータ改竄なしと判定し、一致が認められない場合には、データの改竄があったものと判定する。
【０１３９】
図１５に示すステップＳ１３において、ホームサーバとサービスプロバイダ（ＳＰ）との間で、例えば上述したシーケンスに従った相互認証処理が実行され、双方が正しい通信相手であることの確認がなされると、ステップＳ１４において、サービスプロバイダ（ＳＰ）は、事前定義ポリシーに従ったドメイン登録審査を実行し、審査不合格である場合は、エラー処理、たとえばホームサーバに対して登録処理が実行不可能である旨を通知する処理などを実行する。
【０１４０】
審査合格である場合は、ステップＳ１７において、ホームサーバに対して、希望ドメイン名の要求を実行し、ステップＳ１８において、ホームサーバが希望ドメイン名をサービスプロバイダ（ＳＰ）に送信すると、サービスプロバイダは、ドメイン名未登録確認処理を実行する。これは、ステップＳ２０以下の処理として実行され、サービスプロバイダからサービスプロバイダの管轄するＳＰ名前解決サーバに対して申請ドメイン名が送信されて、ＳＰ名前解決サーバがドメイン名の検索を実行し、申請ドメイン名が未登録か否かを判定する。登録されている場合は、ステップＳ１７に戻り、再度、希望ドメイン名を要求する。
【０１４１】
申請ドメイン名が登録されていない場合は、ステップＳ２２に進み、登録可能通知をサービスプロバイダ、さらに、サービスプロバイダからホームサーバに送信する。
【０１４２】
次に、ドメインの登録されたホームサーバが実行するドメイン名属性証明書（ドメイン名ＡＣ）の発行要求に対する処理手順について図１６を参照して説明する。
【０１４３】
ステップＳ３１において、ホームサーバは、サービスプロバイダを介してドメイン名属性証明書登録局（ＡＲＡ）に対してドメイン名属性証明書（ドメイン名ＡＣ）の発行要求を行なう。この際、ホームサーバの公開鍵証明書（ＰＫＣ）と、登録済みドメイン名を付加データとして送信する。
【０１４４】
ドメイン名属性証明書登録局（ＡＲＡ）は、発行要求に基づいて、ポリシーに従った審査を実行して、発行条件を満足すると判断すると、ステップＳ３２において、ドメイン名属性証明書認証局（ＡＡ）に対して、ホームサーバの公開鍵証明書（ＰＫＣ）と、登録済みドメイン名とともに、ドメイン名属性証明書発行要求を行なう。
【０１４５】
ドメイン名属性証明書認証局（ＡＡ）は、ステップＳ３３において、ホームサーバの公開鍵証明書（ＰＫＣ）と、登録済みドメイン名に基づいて、ドメイン名属性証明書を生成して、ドメイン名属性証明書登録局（ＡＲＡ）に送信する。ここで生成するドメイン名属性証明書は、先に、図７（ａ）を参照して説明した構成を持ち、属性情報フィールドにドメイン名が格納され、ドメイン名属性証明書認証局（ＡＡ）の秘密鍵による署名がなされたものである。
【０１４６】
ドメイン名属性証明書登録局（ＡＲＡ）は、受信したドメイン名属性証明書をサービスプロバイダに送信し、サービスプロバイダは、ステップＳ３５において、ホームサーバのドメイン名に対応するアドレス空間の割り当てを実行して、ステップＳ３６において、決定したドメイン名に対応するアドレス空間と、ドメイン名属性証明書（ＡＣ）をホームサーバに送信し、一方、ＳＰ名前解決サーバに対しても、決定したドメイン名に対応するアドレス空間と、ドメイン名属性証明書（ＡＣ）のコピーを送信する。ＳＰ名前解決サーバは、ドメイン名に対応するアドレス空間をデータベース（図１４（ａ）参照）に登録する。
【０１４７】
ドメイン名に対応するアドレス空間と、ドメイン名属性証明書（ＡＣ）を受信したホームサーバは、ホームサーバの利用するホーム名前解決サーバに対して決定したドメイン名に対応するアドレス空間と、ドメイン名属性証明書（ＡＣ）のコピーを送信する。ホーム名前解決サーバは、ドメイン名に対応するアドレス空間をデータベース（図１４（ｂ）参照）に登録する。
【０１４８】
なお、上記処理において、ドメイン名属性証明書（ＡＣ）を受領したホームサーバは、その署名を検証してドメイン名属性証明書（ＡＣ）の改竄がないことを確認した後、自己のメモリに格納し、またコピーを生成する。
【０１４９】
属性証明書の生成時に属性証明書認証局（ＡＡ）が実行する電子署名の生成、および、属性証明書の格納時にホームサーバが実行する電子署名の検証処理について、図１９、図２０を参照して説明する。
【０１５０】
署名は、データ改竄の検証を可能とするために付加されるものである。前述のＭＡＣ値を用いることも可能であり、公開鍵暗号方式を用いた電子署名を適用することも可能である。
【０１５１】
まず、公開鍵暗号方式を用いた電子署名の生成方法について、図１９を用いて説明する。図１９に示す処理は、ＥＣ−ＤＳＡ（（Ｅｌｌｉｐｔｉｃ　Ｃｕｒｖｅ　Ｄｉｇｉｔａｌ　Ｓｉｇｎａｔｕｒｅ　Ａｌｇｏｒｉｔｈｍ）、ＩＥＥＥ　Ｐ１３６３／Ｄ３）を用いた電子署名データの生成処理フローである。なお、ここでは公開鍵暗号として楕円曲線暗号（Ｅｌｌｉｐｔｉｃ　Ｃｕｒｖｅ　Ｃｒｙｐｔｏｓｙｓｔｅｍ（以下、ＥＣＣと呼ぶ））を用いた例を説明する。なお、本発明のデータ処理装置においては、楕円曲線暗号以外にも、同様の公開鍵暗号方式における、例えばＲＳＡ暗号（（Ｒｉｖｅｓｔ、Ｓｈａｍｉｒ、Ａｄｌｅｍａｎ）など（ＡＮＳＩ　Ｘ９．３１））を用いることも可能である。
【０１５２】
図１９の各ステップについて説明する。ステップＳ１において、ｐを標数、ａ、ｂを楕円曲線の係数（楕円曲線：ｙ^２＝ｘ^３＋ａｘ＋ｂ，４ａ^３＋２７ｂ^２≠０（ｍｏｄｐ））、Ｇを楕円曲線上のベースポイント、ｒをＧの位数、Ｋｓを秘密鍵（０＜Ｋｓ＜ｒ）とする。ステップＳ２おいて、メッセージＭのハッシュ値を計算し、ｆ＝Ｈａｓｈ（Ｍ）とする。
【０１５３】
ここで、ハッシュ関数を用いてハッシュ値を求める方法を説明する。ハッシュ関数とは、メッセージを入力とし、これを所定のビット長のデータに圧縮し、ハッシュ値として出力する関数である。ハッシュ関数は、ハッシュ値（出力）から入力を予測することが難しく、ハッシュ関数に入力されたデータの１ビットが変化したとき、ハッシュ値の多くのビットが変化し、また、同一のハッシュ値を持つ異なる入力データを探し出すことが困難である特徴を有する。ハッシュ関数としては、ＭＤ４、ＭＤ５、ＳＨＡ−１などが用いられる場合もあるし、ＤＥＳ−ＣＢＣが用いられる場合もある。この場合は、最終出力値となるＭＡＣ（チェック値：ＩＣＶに相当する）がハッシュ値となる。
【０１５４】
続けて、ステップＳ３で、乱数ｕ（０＜ｕ＜ｒ）を生成し、ステップＳ４でベースポイントをｕ倍した座標Ｖ（Ｘｖ，Ｙｖ）を計算する。なお、楕円曲線上の加算、２倍算は次のように定義されている。
【０１５５】
【数１】
Ｐ＝（Ｘａ，Ｙａ），Ｑ＝（Ｘｂ，Ｙｂ），Ｒ＝（Ｘｃ，Ｙｃ）＝Ｐ＋Ｑとすると、
Ｐ≠Ｑの時（加算）、
Ｘｃ＝λ^２−Ｘａ−Ｘｂ
Ｙｃ＝λ×（Ｘａ−Ｘｃ）−Ｙａ
λ＝（Ｙｂ−Ｙａ）／（Ｘｂ−Ｘａ）
Ｐ＝Ｑの時（２倍算）、
Ｘｃ＝λ^２−２Ｘａ
Ｙｃ＝λ×（Ｘａ−Ｘｃ）−Ｙａ
λ＝（３（Ｘａ）^２＋ａ）／（２Ｙａ）
【０１５６】
これらを用いて点Ｇのｕ倍を計算する（速度は遅いが、最もわかりやすい演算方法として次のように行う。Ｇ、２×Ｇ、４×Ｇ・・を計算し、ｕを２進数展開して１が立っているところに対応する２^ｉ×Ｇ（Ｇをｉ回２倍算した値（ｉはｕのＬＳＢから数えた時のビット位置））を加算する。
【０１５７】
ステップＳ５で、ｃ＝Ｘｖｍｏｄｒを計算し、ステップＳ６でこの値が０になるかどうか判定し、０でなければステップＳ７でｄ＝［（ｆ＋ｃＫｓ）／ｕ］ｍｏｄｒを計算し、ステップＳ８でｄが０であるかどうか判定し、ｄが０でなければ、ステップＳ９でｃおよびｄを電子署名データとして出力する。仮に、ｒを１６０ビット長の長さであると仮定すると、電子署名データは３２０ビット長となる。
【０１５８】
ステップＳ６において、ｃが０であった場合、ステップＳ３に戻って新たな乱数を生成し直す。同様に、ステップＳ８でｄが０であった場合も、ステップＳ３に戻って乱数を生成し直す。
【０１５９】
次に、公開鍵暗号方式を用いた電子署名の検証方法を、図２０を用いて説明する。ステップＳ１１で、Ｍをメッセージ、ｐを標数、ａ、ｂを楕円曲線の係数（楕円曲線：ｙ^２＝ｘ^３＋ａｘ＋ｂ，４ａ^３＋２７ｂ^２≠０（ｍｏｄｐ））、Ｇを楕円曲線上のベースポイント、ｒをＧの位数、ＧおよびＫｓ×Ｇを公開鍵（０＜Ｋｓ＜ｒ）とする。ステップＳ１２で電子署名データｃおよびｄが０＜ｃ＜ｒ、０＜ｄ＜ｒを満たすか検証する。これを満たしていた場合、ステップＳ１３で、メッセージＭのハッシュ値を計算し、ｆ＝Ｈａｓｈ（Ｍ）とする。次に、ステップＳ１４でｈ＝１／ｄ　ｍｏｄ　ｒを計算し、ステップＳ１５でｈ１＝ｆｈ　ｍｏｄ　ｒ、ｈ２＝ｃｈ
ｍｏｄ　ｒを計算する。
【０１６０】
ステップＳ１６において、既に計算したｈ１およびｈ２を用い、点Ｐ＝（Ｘｐ，Ｙｐ）＝ｈ１×Ｇ＋ｈ２・Ｋｓ×Ｇを計算する。電子署名検証者は、ベースポイントＧおよびＫｓ×Ｇを知っているので、図１９のステップＳ４と同様に楕円曲線上の点のスカラー倍の計算ができる。そして、ステップＳ１７で点Ｐが無限遠点かどうか判定し、無限遠点でなければステップＳ１８に進む（実際には、無限遠点の判定はステップＳ１６でできてしまう。つまり、Ｐ＝（Ｘ，Ｙ）、Ｑ＝（Ｘ，−Ｙ）の加算を行うと、λが計算できず、Ｐ＋Ｑが無限遠点であることが判明している）。ステップＳ１８でＸｐｍｏｄｒを計算し、電子署名データｃと比較する。最後に、この値が一致していた場合、ステップＳ１９に進み、電子署名が正しいと判定する。
【０１６１】
電子署名が正しいと判定された場合、データは改竄されておらず、公開鍵に対応した秘密鍵を保持する者が電子署名を生成したことがわかる。
【０１６２】
ステップＳ１２において、電子署名データｃまたはｄが、０＜ｃ＜ｒ、０＜ｄ＜ｒを満たさなかった場合、ステップＳ２０に進む。また、ステップＳ１７において、点Ｐが無限遠点であった場合もステップＳ２０に進む。さらにまた、ステップＳ１８において、Ｘｐｍｏｄｒの値が、電子署名データｃと一致していなかった場合にもステップＳ２０に進む。
【０１６３】
ステップＳ２０において、電子署名が正しくないと判定された場合、データは改竄されているか、公開鍵に対応した秘密鍵を保持する者が電子署名を生成したのではないことがわかる。上述したように、署名付けやハッシュをとるだけでは改竄は可能であるが、検出により実質的に改竄できないことと同様の効果がある。
【０１６４】
上述した電子署名の生成、検証により、改竄された属性証明書の利用を防止することが可能となる。なお、属性証明書を適用したアクセス権限の確認処理に際しても、属性証明書の署名検証が実行される。この処理については後述する。
【０１６５】
次に、通信処理装置（ユーザデバイス）としてのエンドエンティテイ（ＥＥ）の新規追加、および、エンドエンティテイ（ＥＥ）に対するドメイン名属性証明書、およびホスト名属性証明書の発行シーケンスについて、図２１乃至図２３を参照して説明する。
【０１６６】
なお、図２１乃至図２２において、
新規ＥＥ：新規の通信処理装置としてホームサーバの管理下に追加するエンドエンティテイ
ホームサーバ：属性証明書に基づく審査に基づいてホーム名前解決サーバを利用した名前解決を実行する中継サーバ、
ホーム名前解決サーバ：ホームサーバの利用する名前解決サーバ、
ドメイン名ＡＲＡ：ドメイン名属性証明書登録局、
ドメイン名ＡＡ：ドメイン名属性証明書認証局、
である。
【０１６７】
まず、図２１、ステップＳ２０１において、通信処理装置としての新規ＥＥ（エンドエンティテイ）がネットワークに接続され、ステップＳ２０２において、ホームサーバに対して登録要求を出力する。この新規ＥＥは、たとえば図１１を参照して説明した構成を持ち、ネットワークインタフェース２３２（図１１参照）を介してネットワークに接続する。
【０１６８】
ホームサーバは、新規ＥＥからの登録要求に対して仮アドレスを割り当て（Ｓ２０３）、その後、新規ＥＥとホームサーバ間で相互認証が実行（Ｓ２０４）される。この相互認証処理は、例えば先に図１７を参照して説明したシーケンスに従って実行される。相互認証の成立を条件として、次ステップに進む。新規ＥＥは、登録処理に必要となる機器情報をホームサーバに送信（Ｓ２０５）し、ホームサーバは、受信情報の検証、審査を実行（Ｓ２０６）する。
【０１６９】
検証、審査の結果登録不可（Ｓ２０７：Ｎｏ）と判定されると、エラー処理（Ｓ２０８）を実行して処理終了となる。検証、審査の結果登録可（Ｓ２０７：Ｙｅｓ）と判定されると、登録可能通知を新規ＥＥに送信（Ｓ２０９）し、新規ＥＥは、登録可能通知を受信するとＥＥ名（ホスト名）登録申請をホームサーバに送信（Ｓ２１０）し、ホームサーバは、希望ＥＥ名（ホスト名）を新規ＥＥに対して要求（Ｓ２１１）し、新規ＥＥは、希望ＥＥ名（ホスト名）をホームサーバに送信（Ｓ２１２）する。
【０１７０】
新規ＥＥが希望ＥＥ名（ホスト名）をホームサーバに送信すると、ホームサーバは、ＥＥ名（ホスト名）未登録確認処理を実行（Ｓ２１３）する。これは、ステップＳ２１４以下の処理として実行され、ホームサーバからホーム名前解決サーバに対して希望ＥＥ名（ホスト名）が送信されて、ホーム名前解決サーバが希望ＥＥ名（ホスト名）の検索を実行し、未登録か否かを判定する。登録されている場合は、ステップＳ２１１に戻り、再度、希望ＥＥ名（ホスト名）を要求する。
【０１７１】
希望ＥＥ名（ホスト名）が登録されていない場合は、ステップＳ２１６に進み、登録可能通知をホームサーバに送信し、ホームサーバは、ＥＥ名（ホスト名）に対応するアドレス空間の割り当てを実行（Ｓ２１７）して、ステップＳ２１８において、決定したＥＥ名（ホスト名）と、対応するアドレスとを新規登録ＥＥに通知し、一方、ホーム名前解決サーバに対しても、決定したＥＥ名（ホスト名）と、対応するアドレスを送信する。ホーム名前解決サーバは、ホスト名に対応するアドレス空間をデータベース（図１４（ｂ）参照）に登録する。
【０１７２】
次に、図２２を参照して、エンドエンティテイ（ＥＥ）が実行するドメイン名属性証明書（ドメイン名ＡＣ）の発行要求に対する処理手順について説明する。
【０１７３】
まず、ステップＳ２２１において、ＥＥ（エンドエンティテイ）がホームサーバに対してドメイン名属性証明書（ドメイン名ＡＣ）の発行要求を出力する。ホームサーバは、ＥＥからの要求を受信すると、ＥＥとホームサーバ間で相互認証を実行（Ｓ２２２）する。この相互認証処理は、例えば先に図１７を参照して説明したシーケンスに従って実行される。相互認証の成立を条件として、次ステップに進む。ＥＥは、ドメイン名属性証明書（ドメイン名ＡＣ）発行処理に必要となる機器情報、ホスト名（ＥＥ名）をホームサーバに送信（Ｓ２２３）し、ホームサーバは、受信情報の検証、審査を実行（Ｓ２２４）する。
【０１７４】
検証、審査の結果ドメイン名属性証明書（ドメイン名ＡＣ）発行不可（Ｓ２２５：Ｎｏ）と判定されると、エラー処理（Ｓ２２６）を実行して処理終了となる。検証、審査の結果、ドメイン名属性証明書（ドメイン名ＡＣ）発行可（Ｓ２２５：Ｙｅｓ）と判定されると、ステップＳ２２７において、ホームサーバは、ドメイン名属性証明書登録局（ＡＲＡ）に対してドメイン名属性証明書（ドメイン名ＡＣ）の発行要求を行なう。この際、ホームサーバの公開鍵証明書（ＰＫＣ）と、ＥＥの機器情報、ホスト名（ＥＥ名）、ドメイン名を付加データとして送信する。
【０１７５】
ドメイン名属性証明書登録局（ＡＲＡ）は、発行要求に基づいて、属性証明書発行ポリシーに従った審査を実行して、発行条件を満足すると判断すると、ステップＳ２２８において、ドメイン名属性証明書認証局（ＡＡ）に対して、ホームサーバの公開鍵証明書（ＰＫＣ）と、ＥＥの機器情報、ホスト名（ＥＥ名）、ドメイン名を通知するとともに、ドメイン名属性証明書発行要求を行なう。
【０１７６】
ドメイン名属性証明書認証局（ＡＡ）は、ステップＳ２２９において、ホームサーバの公開鍵証明書（ＰＫＣ）と、登録済みドメイン名に基づいて、ドメイン名属性証明書を生成して、ドメイン名属性証明書登録局（ＡＲＡ）に送信する。ここで生成するドメイン名属性証明書は、先に、図７（ａ）を参照して説明した構成を持ち、属性情報フィールドにドメイン名が格納され、ドメイン名属性証明書認証局（ＡＡ）の秘密鍵による署名がなされたものである。
【０１７７】
ドメイン名属性証明書登録局（ＡＲＡ）は、受信したドメイン名属性証明書をホームサーバに送信（Ｓ２３０）し、ホームサーバは、ステップＳ２３１において、ドメイン名属性証明書（ＡＣ）をエンドエンティテイ（ＥＥ）に送信し、一方、ホーム名前解決サーバに対しても、ホスト名、ドメイン名属性証明書（ＡＣ）のコピーを送信する。
【０１７８】
次に、図２３を参照して、エンドエンティテイ（ＥＥ）が実行するホスト名属性証明書（ホスト名ＡＣ）の発行要求に対する処理手順について説明する。
【０１７９】
なお、図２３において、
新規ＥＥ：新規の通信処理装置としてホームサーバの管理下に追加するエンドエンティテイ
ホームサーバ：属性証明書に基づく審査に基づいてホーム名前解決サーバを利用した名前解決を実行する中継サーバ、
ホーム名前解決サーバ：ホームサーバの利用する名前解決サーバ、
ホスト名ＡＲＡ：ホスト名属性証明書登録局、
ホスト名ＡＡ：ホスト名属性証明書認証局、
である。
【０１８０】
まず、ステップＳ２４１において、ＥＥ（エンドエンティテイ）がホームサーバに対してホスト名属性証明書（ホスト名ＡＣ）の発行要求を出力する。ホームサーバは、ＥＥからの要求を受信すると、ＥＥとホームサーバ間で相互認証が実行（Ｓ２４２）される。この相互認証処理は、例えば先に図１７を参照して説明したシーケンスに従って実行される。相互認証の成立を条件として、次ステップに進む。ＥＥは、ホスト名属性証明書（ホスト名ＡＣ）発行処理に必要となる機器情報、ホスト名（ＥＥ名）をホームサーバに送信（Ｓ２４３）し、ホームサーバは、受信情報の検証、審査を実行（Ｓ２４４）する。
【０１８１】
検証、審査の結果ホスト名属性証明書（ホスト名ＡＣ）発行不可（Ｓ２４５：Ｎｏ）と判定されると、エラー処理（Ｓ２４６）を実行して処理終了となる。検証、審査の結果、ホスト名属性証明書（ホスト名ＡＣ）発行可（Ｓ２４５：Ｙｅｓ）と判定されると、ステップＳ２４７において、ホームサーバは、ホスト名属性証明書登録局（ＡＲＡ）に対してホスト名属性証明書（ホスト名ＡＣ）の発行要求を行なう。この際、ホームサーバの公開鍵証明書（ＰＫＣ）と、ＥＥの機器情報、ホスト名（ＥＥ名）を付加データとして送信する。
【０１８２】
ホスト名属性証明書登録局（ＡＲＡ）は、発行要求に基づいて、ポリシーに従った審査を実行して、発行条件を満足すると判断すると、ステップＳ２４８において、ホスト名属性証明書認証局（ＡＡ）に対して、ホームサーバの公開鍵証明書（ＰＫＣ）と、ＥＥの機器情報、ホスト名（ＥＥ名）、ホスト名とともに、ホスト名属性証明書発行要求を行なう。
【０１８３】
ホスト名属性証明書認証局（ＡＡ）は、ステップＳ２４９において、ホームサーバの公開鍵証明書（ＰＫＣ）と、登録済みホスト名に基づいて、ホスト名属性証明書を生成して、ホスト名属性証明書登録局（ＡＲＡ）に送信する。ここで生成するホスト名属性証明書は、先に、図７（ｂ）を参照して説明した構成を持ち、属性情報フィールドにホスト名が格納され、ホスト名属性証明書認証局（ＡＡ）の秘密鍵による署名がなされたものである。
【０１８４】
ホスト名属性証明書登録局（ＡＲＡ）は、受信したホスト名属性証明書をホームサーバに送信（Ｓ２５０）し、ホームサーバは、ステップＳ２５１において、ホスト名属性証明書（ＡＣ）をエンドエンティテイ（ＥＥ）に送信し、一方、ホーム名前解決サーバに対しても、ホスト名、ホスト名属性証明書（ＡＣ）のコピーを送信する。
【０１８５】
なお、上記処理において、ホスト名属性証明書（ＡＣ）を受領したエンドエンティテイ（ＥＥ）は、その署名を検証してドメイン名属性証明書（ＡＣ）の改竄がないことを確認した後、自己のメモリに格納する。
【０１８６】
（３−３）アクセス許可情報の登録および削除処理
次に、アクセス許可情報の登録および削除処理について説明する。例えば図１３に示した構成において、エンドエンティテイ（ＥＥ）としてのユーザデバイス３１１は、自身に対するアクセス要求について接続を許可するアクセス要求元グループを、中継サーバ１（ホームサーバ１）３１３に登録することができる。一方、ユーザデバイス３２１は、自身に対するアクセス要求について接続を許可するアクセス要求元グループを、中継サーバ２（ホームサーバ２）３２３に登録することができる。
【０１８７】
中継サーバ１，３１３は、自己の管理ユーザデバイス、すなわち名前解決サーバ３１２を適用した名前解決処理サービスを提供可能な端末（例えば図１３ではユーザデバイス３１１）から、自端末（ユーザデバイス３１１）に対するアクセス要求許可グループ情報を受領して、その情報登録を行う。
【０１８８】
中継サーバ１，３１３は、登録情報、およびアクセス要求元から提示されるドメイン名属性証明書、ホスト名属性証明書、その他のグループ属性証明書に基づいてアクセス可否を判定し、アクセス要求元がアクセスが許可されたグループに属している場合にのみ名前解決処理を行なってホスト名からアドレスを取得してアクセス要求元に通知する。
【０１８９】
まず、図２４を参照してユーザデバイスであるエンドエンティテイ（ＥＥ）が、自デバイスの名前解決処理を実行するホームサーバに対してアクセス許可グループ情報を登録するシーケンスについて説明する。なお、図２４において、
ＥＥ：アクセス許可情報の登録を要求するエンドエンティテイ（ユーザデバイス）
ホームサーバ：ＥＥのホスト名に基づく名前解決をアクセス要求元から提示される属性証明書、および登録されたアクセス許可情報に基づいて判定するホームサーバ
許可グループデータベース：アクセス許可情報の登録用データベース
である。
【０１９０】
まず、ステップＳ３０１において、ユーザがユーザデバイスであるエンドエンティテイ（ＥＥ）に対して、ＥＥのインタフェースを介して許可グループ情報の登録開始要求を入力する。ステップＳ３０２において、ＥＥは、自身の名前解決処理の実行判定を行なうホームサーバに対して許可グループ情報登録要求を出力する。
【０１９１】
次に、ステップＳ３０３において、ホームサーバとエンドエンティテイ（ＥＥ）間において相互認証を実行する。この相互認証処理は、例えば先に図１７を参照して説明したシーケンスに従って実行する。相互認証の成立を条件として、次ステップに進む。ステップＳ３０４において、ＥＥは、登録処理に必要となる情報、すなわち、アクセスを許容するグループ情報、アクセス許可期限などの情報をホームサーバに送信する。
【０１９２】
ホームサーバは、受信情報に基づいて、許可グループデータベース（ＤＢ）に対する登録処理を実行（Ｓ３０５）し、登録後、登録完了通知をエンドエンティテイ（ＥＥ）に送信（Ｓ３０６）して、登録処理が終了する。
【０１９３】
許可グループデータベースの構成例を図２５に示す。図２５の例は、エンドエンティテイ（ｅｅ−ａ）と、エンドエンティテイ（ｅｅ−ｂ）の２つのＥＥに対するアクセス許可グループが登録された例を示している。
【０１９４】
エンドエンティテイ（ｅｅ−ａ）については、Ａ社の機器、ユーザについて、５月５日まで、鈴木家の機器、ユーザに対して無期限、ａｂｃ．ｎｅｔドメイン内の機器に対して設定から４８時間内のアクセスを許可する情報が登録されている。エンドエンティテイ（ｅｅ−ｂ）は、Ａ社アメリカ支店の機器、ユーザについて、提示される属性証明書の有効期限内、Ｘ大学理学部の機器、ユーザに対して３月３１日まで、ｅｅ−ｓ．ｈｏｍｅ２．ａｂｃ．ｎｅｔのホスト名機器に対して設定から４月８日までのアクセスを許可する情報が登録されている。
【０１９５】
図２５に示す許可グループデータベースを持つホームサーバは、アクセス要求元から提示される属性証明書に基づいてアクセス要求元が、アクセス許可グーループに属するか否かを判定し、属すると判定された場合に名前解決処理により、アクセス要先のデバイス（ＥＥ）のホスト名からアドレスを取得して、アクセス要求元に通知する。
【０１９６】
次に、図２６を参照してアクセス許可グループ情報の削除シーケンスについて説明する。なお、図２６において、
ＥＥ：アクセス許可情報の登録を要求するエンドエンティテイ（ユーザデバイス）
ホームサーバ：ＥＥのホスト名に基づく名前解決をアクセス要求元から提示される属性証明書、および登録されたアクセス許可情報に基づいて判定するホームサーバ
許可グループデータベース：アクセス許可情報の登録用データベース
である。
【０１９７】
まず、ステップＳ３１１において、ユーザがユーザデバイスであるエンドエンティテイ（ＥＥ）に対して、ＥＥのインタフェースを介して許可グループ情報の削除開始要求を入力する。ステップＳ３１２において、ＥＥは、自身の名前解決処理の実行判定を行なうホームサーバに対して許可グループ情報削除要求を出力する。
【０１９８】
次に、ステップＳ３１３において、ホームサーバとエンドエンティテイ（ＥＥ）間において、相互認証が実行される。この相互認証処理は、例えば先に図１７を参照して説明したシーケンスに従って実行される。相互認証の成立を条件として、次ステップに進む。ステップＳ３１４において、ＥＥは、削除処理に必要となる情報、すなわち、削除を実行するグループ情報をホームサーバに送信する。
【０１９９】
ホームサーバは、受信情報に基づいて、許可グループデータベース（ＤＢ）の登録情報の削除処理を実行（Ｓ３１５）し、削除後、削除完了通知をエンドエンティテイ（ＥＥ）に送信（Ｓ３１６）して、登録処理が終了する。
【０２００】
（３−４）アクセス許可判定処理
次に、ネットワークを介した通信において、上述したアクセス許可グループデータベースを適用してアクセスの制限を行なう処理シーケンスについて説明する。
【０２０１】
図２７は、アクセス元ＥＥからアクセス先ＥＥに対してネットワークを介したアクセスを実行する際のシーケンスを示した図である。図２７において、
アクセス先ＥＥ：アクセス先としてのエンドエンティテイ（ユーザデバイス）
ホーム名前解決サーバ：アクセス先ＥＥに関するホスト名からアドレスの取得処理（名前解決処理）を行なうサーバ
アクセス先ホームサーバ：アクセス先ＥＥのホスト名に基づく名前解決をアクセス要求元から提示される属性証明書、および登録されたアクセス許可情報に基づいて判定するホームサーバ
アクセス元ＥＥ所属ドメインホームサーバ：アクセス元ＥＥの管理サーバであり、ネットワークを介する通信時に中継サーバとして機能し、アクセス先ホームサーバのアドレスをアクセス元ＥＥに通知する処理を行なうホームサーバ
アクセス元ＥＥ：アクセス元としてのエンドエンティテイ（ユーザデバイス）
である。
【０２０２】
まず、ステップＳ３２１において、アクセス元ＥＥは、アクセス元ＥＥ所属ドメインホームサーバに対して、アクセス先ＥＥの所属ドメイン名を送信する。ステップＳ３２２において、アクセス元ＥＥ所属ドメインホームサーバは、自己の管理範囲または、上位のサーバの管理する名前解決サーバを適用して、受信ドメイン名に対応するアクセス先のホームサーバのＩＰアドレスをアクセス元ＥＥに通知する。
【０２０３】
ドメイン名に基づく、アクセス先ホームサーバのＩＰアドレスのアクセス元ＥＥに対する通知処理の詳細シーケンスについて、図２８を参照して説明する。図２８において、
ＳＰは、アクセス元ＥＥ所属ドメインサーバの上位ドメインのサービスプロバイダ（ＳＰ）であり、ＳＰ名前解決サーバは、そのＳＰの適用する名前解決サーバである。
【０２０４】
アクセス元ＥＥ所属ドメインホームサーバが、アクセス元ＥＥからドメイン名を受信すると、ステップＳ３５１において、アクセス元ＥＥ所属ドメインホームサーバは、アクセス元ＥＥ所属ドメイン名前解決サーバに対して、ドメイン名に対応するアドレス取得を要求する。
【０２０５】
アクセス元ＥＥ所属ドメイン名前解決サーバは、たとえば先に図１４を参照して説明したデータベースに基づいてドメインが登録されているかを判定し、存在すれば（Ｓ３５２：Ｙｅｓ）、データベースからアドレスを取得してステップＳ３５７で、ドメイン名に対応するホームサーバのＩＰアドレスをアクセス元ＥＥ所属ドメインホームサーバに送信し、アクセス元ＥＥ所属ドメインホームサーバからアクセス要求元ＥＥにアドレス情報が送信される。
【０２０６】
一方、アクセス元ＥＥ所属ドメイン名前解決サーバのデータベースにドメインが登録されていない（Ｓ３５２：Ｎｏ）場合は、上位ドメインのサービスプロバイダ（ＳＰ）にドメインを送信し、名前解決を要求（Ｓ３５３）する。サービスプロバイダ（ＳＰ）は、ＳＰ名前解決サーバに対して、ドメイン名検索を要求（Ｓ３５４）し、ＳＰ名前解決サーバは、ドメインに対応するホームサーバのＩＰアドレスを取得して、サービスプロバイダ（ＳＰ）に送信（Ｓ３５５）し、サービスプロバイダ（ＳＰ）からアクセス元ＥＥ所属ドメインホームサーバ（Ｓ３５６）、アクセス元ＥＥ所属ドメインホームサーバからアクセス要求元ＥＥにアドレス情報が送信（Ｓ３５７）される。
【０２０７】
なお、図２８の例では、ドメイン名に対応するアドレス取得を１つのサービスプロバイダ（ＳＰ）に問い合わせて情報を取得する例を示しているが、必要に応じて、さらに上位、あるいは他のドメインのＳＰに対して、アドレス取得が実行されるまで再帰的に問い合わせを実行し、必要なアドレス情報を取得する。
【０２０８】
図２７に戻り、説明を続ける。ステップＳ３２２において、上述した処理により、アクセス元ＥＥが、アクセス先ホームサーバのＩＰアドレスを取得すると、次に、ステップＳ３２３において、アクセス元ＥＥは、受信したアクセス先のホームサーバのＩＰアドレスに従って、アクセス先ホームサーバにアクセスして、相互認証を実行（Ｓ３２４）する。相互認証処理は、例えば先に図１７を参照して説明したシーケンスに従って実行される。相互認証の成立を条件として、次ステップに進む。アクセス元ＥＥは、ステップＳ３２５において、アクセス先ホームサーバに自己の属性証明書を送付して、アクセス先ＥＥのホスト名からのアドレス取得、すなわち名前解決処理を要求する。
【０２０９】
属性証明書を受領したアクセス先ホームサーバは、属性証明書の検証、審査を実行する。属性証明書の検証とは、署名検証による改竄有無の検証であり、審査は、前述の許可グループデータベースを参照して、属性証明書によって証明されたグループが許可グループとして登録されているか否かの審査である。
【０２１０】
属性証明書の検証処理の詳細について、図２９乃至図３１を参照して説明する。まず、属性証明書（ＡＣ）と公開鍵証明書（ＰＫＣ）との関連確認処理について、図２９を参照して説明する。図２９のフローは、属性証明書（ＡＣ）の検証を実行する際に行なわれる属性証明書（ＡＣ）に関連する公開鍵証明書（ＰＫＣ）の確認処理である。
【０２１１】
確認対象の属性証明書（ＡＣ）がセット（Ｓ４２１）されると、属性証明書のＡＣ保持者の公開鍵証明書情報（ホルダー）フィールドを抽出（Ｓ４２２）し、抽出した公開鍵証明書情報（ホルダー）フィールド内に格納された公開鍵証明書の発行者情報（ＰＫＣ発行者）、公開鍵証明書シリアル番号（ＰＫＣシリアル）を確認（Ｓ４２３）し、公開鍵証明書の発行者情報（ＰＫＣ発行者）、公開鍵証明書シリアル番号（ＰＫＣシリアル）に基づいて公開鍵証明書（ＰＫＣ）を検索（Ｓ４２４）して、属性証明書（ＡＣ）に関連付けられた公開鍵証明書（ＰＫＣ）を取得（Ｓ４２５）する。
【０２１２】
図２９に示すように、属性証明書（ＡＣ）と公開鍵証明書（ＰＫＣ）とは、属性証明書に格納された公開鍵証明書情報（ホルダー）フィールド内の公開鍵証明書発行者情報（ＰＫＣ発行者）、および公開鍵証明書シリアル番号（ＰＫＣシリアル）により関連付けがなされている。
【０２１３】
次に、図３０を参照して属性証明書（ＡＣ）の検証処理について説明する。まず、検証対象となる属性証明書（ＡＣ）をセット（Ｓ４５１）し、属性証明書（ＡＣ）格納情報に基づいて、属性証明書（ＡＣ）の所有者および署名者を特定（Ｓ４５２）する。さらに、属性証明書（ＡＣ）の所有者の公開鍵証明書を直接あるいはリポジトリなどから取得（Ｓ４５３）して、公開鍵証明書の検証処理を実行（Ｓ４５４）する。
【０２１４】
図３１を参照して公開鍵証明書（ＰＫＣ）の検証処理について説明する。図３１に示す公開鍵証明書（ＰＫＣ）の検証は、下位から上位へ証明書連鎖をたどって最上位の公開鍵証明書までの連鎖情報を取得して、最上位（ル−トＣＡ）までの公開鍵証明書の署名検証を行なう連鎖検証処理フローである。まず、検証対象となる公開鍵証明書（ＰＫＣ）をセット（Ｓ４７１）し、公開鍵証明書（ＰＫＣ）格納情報に基づいて、公開鍵証明書（ＰＫＣ）署名者を特定（Ｓ４７２）する。さらに、検証対象となる証明書連鎖の最上位の公開鍵証明書であるかを判定（Ｓ４７３）し、最上位でない場合は、最上位公開鍵証明書を直接あるいはリポジトリなどから取得（Ｓ４７４）する。最上位公開鍵証明書が取得されセット（Ｓ４７５）されると、署名検証に必要な検証鍵（公開鍵）を取得（Ｓ４７６）し、検証対象の署名が自己署名であるか否かを判定し（Ｓ４７７）、自己署名でない場合は、下位ＰＫＣをセット（Ｓ４７９）して、上位の公開鍵証明書から取得した検証鍵（公開鍵）に基づいて署名検証を実行（Ｓ４８０）する。なお、ステップＳ４７７における自己署名判定において、自己署名の場合は自己の公開鍵を検証鍵とした検証を実行（Ｓ４７８）し、ステップＳ４８１に進む。
【０２１５】
署名検証に成功した場合（Ｓ４８１：Ｙｅｓ）は、目的とするＰＫＣの検証が完了したか否かを判定（Ｓ４８２）し、完了している場合は、ＰＫＣ検証を終了する。完了していない場合は、ステップＳ４７６に戻り、署名検証に必要な検証鍵（公開鍵）の取得、下位の公開鍵証明書の署名検証を繰り返し実行する。なお、署名検証に失敗した場合（Ｓ４８１：Ｎｏ）は、ステップＳ４８３に進み、エラー処理、例えばその後の手続きを停止する等の処理を実行する。
【０２１６】
図３０に戻り、属性証明書検証処理の説明を続ける。図３１で説明した公開鍵証明書の検証に失敗した場合（Ｓ４５５でＮｏ）は、ステップＳ４５６に進み、エラー処理を行なう。例えばその後の処理を中止する。公開鍵証明書の検証に成功した場合（Ｓ４５５でＹｅｓ）は、属性証明書（ＡＣ）の署名者に対応する公開鍵証明書を直接あるいはリポジトリなどから取得（Ｓ４５７）して、属性証明書（ＡＣ）の署名者に対応する公開鍵証明書の検証処理を実行（Ｓ４５８）する。
【０２１７】
属性証明書（ＡＣ）の署名者に対応する公開鍵証明書の検証に失敗した場合（Ｓ４５９でＮｏ）は、ステップＳ４６０に進み、エラー処理を行なう。例えばその後の処理を中止する。公開鍵証明書の検証に成功した場合（Ｓ４５９でＹｅｓ）は、属性証明書（ＡＣ）の署名者に対応する公開鍵証明書から公開鍵を取り出し（Ｓ４６１）て、取り出した公開鍵を用いて属性証明書（ＡＣ）の署名検証処理を実行（Ｓ４６２）する。署名検証に失敗した場合（Ｓ４６３でＮｏ）は、ステップＳ４６４に進み、エラー処理を行なう。例えばその後の処理を中止する。署名検証に成功した場合（Ｓ４６３でＹｅｓ）は、属性証明書検証を終了し、その後の処理、すなわち属性証明書の属性情報として登録されたグループ情報を取得し、取得したグループ情報が、許可グループデータベース（図２５参照）にアクセス許可グループとして登録されているか否かの審査処理を実行する。
【０２１８】
審査処理の詳細について、図３２を参照して説明する。ステップＳ４９１の判定は、図２９乃至図３１を参照して説明した属性証明書署名検証の検証結果判定ステップであり、検証不成立の場合は、この時点で、ステップＳ４９９に進み、検証・審査不合格応答をアクセス元ＥＥに対して行なうことになる。
【０２１９】
ステップＳ４９１の判定が、Ｙｅｓ、すなわち、属性証明書署名検証に成功し、属性証明書の改竄がないことが確認されると、ステップＳ４９２，Ｓ４９３において、属性証明書から発行者情報、属性情報（グループ情報）を取得する。このグループ情報は、先に図６を参照して説明したように、さまざまな機器グループ、ユーザグループ、ドメイン、ホストなどによって定義されるグループであり、例えばグループ情報としてのグループＩＤ、ドメイン名、ホスト名などによって構成される情報である。
【０２２０】
ステップＳ４９４で、アクセス先ホームサーバは、アクセス先ＥＥ名（ホスト名）を検索キーとして許可グループデータベース（図２５参照）の検索を実行し、許可グループデータベースは、アクセス先ＥＥ名（ホスト名）の許可グループリストを検索結果としてホームサーバに応答する（Ｓ４９５）。ホームサーバは、受信リストにグループ属性証明書から取得したグループ情報がアクセス許可グループとして含まれるか否かを判定（Ｓ４９７）し、存在した場合は、ステップＳ４９８において、名前解決サーバに対する名前解決処理要求（図２７のステップＳ３２９−）を行なうことになる。一方、受信リストにグループ属性証明書から取得したグループ情報がアクセス許可グループとして含まれていない場合は、ステップＳ４９９に進み、検証・審査不合格応答をアクセス元ＥＥに対して行なうことになる。
【０２２１】
図２７のシーケンス図に戻って説明を続ける。ステップＳ３２６では、上述したグループ属性証明書（Ｇｐ．ＡＣ）の検証後、属性証明書の属性情報として登録されたグループ情報を取得し、取得したグループ情報が、許可グループデータベース（図２５参照）にアクセス許可グループとして登録されているか否かの審査処理を実行する。
【０２２２】
上述のグループ属性証明書の検証、および審査処理において合格、すなわち、グループ属性証明書が改竄のない正当な証明書であり、属性証明書の属性情報フィールドに記録されたグループ情報が許可グループデータベース（図２５参照）にアクセス許可グループとして登録されている場合（Ｓ３２７：Ｙｅｓ）には、ステップＳ３２９に進み、ホーム名前解決サーバに対してアクセス先ＥＥ名（ホスト名）を出力する。ホーム名前解決サーバは、先に図１４（ｂ）を参照して説明したデータベースを持ち、アクセス先ＥＥ名（ホスト名）に対応するアドレスを取得（Ｓ３３０）して、アクセス先ホームサーバに応答する。ステップＳ３３１において、アクセス先ホームサーバは、取得アドレスをアクセス元ＥＥに通知し、アクセス元ＥＥは、取得アドレスに基づいて、アクセス先ＥＥへのアクセスを実行する。
【０２２３】
一方、ステップＳ３２７の判定がＮｏ、すなわち、グループ属性証明書の検証、および審査処理において不合格、すなわち、グループ属性証明書が改竄のない正当な証明書であることが証明されなかった場合、あるいは、属性証明書の属性情報フィールドに記録されたグループ情報が許可グループデータベース（図２５参照）にアクセス許可グループとして登録されていない場合には、ステップＳ３２８において、名前解決処理を実行しない、すなわち、名前解決不許可通知をアクセス元ＥＥに送信する。この場合、アクセス元ＥＥは、アクセス先ＥＥのアドレスを取得することができないので、アクセスが実行できないこととなる。
【０２２４】
上述の属性証明書に基づくアクセス可否判定処理において実行されるシーケンスについて、図３３を参照して総括して説明する。
【０２２５】
図３３のユーザデバイス３２１がアクセス元ＥＥであり、ユーザデバイス３１１がアクセス先ＥＥであり、（１）から（７）の順に処理が進められる。まず、（１）において、ユーザデバイス（アクセス元ＥＥ）３２１は、中継サーバ２（ホームサーバ２）３２３に対してアクセス先ＥＥのドメイン名を送信し、中継サーバ２（ホームサーバ２）３２３が名前解決サーバ３２２、あるいは上位ドメインのサービスプロバイダ３４１、あるいはさらに他のサーバを介してアクセス先ＥＥのドメイン内のホームサーバ、すなわち中継サーバ１（ホームサーバ１）３１３に対応するアドレスを取得して、（２）で取得アドレス情報をユーザデバイス（アクセス元ＥＥ）３２１に応答する。
【０２２６】
ユーザデバイス（アクセス元ＥＥ）３２１は、取得アドレスにしたがって、中継サーバ１（ホームサーバ１）３１３に対してアクセスし、属性証明書を送付するとともにユーザデバイス（アクセス先ＥＥ）３１１のホスト名についての名前解決処理の要求を行なう。中継サーバ１（ホームサーバ１）３１３は、属性証明書の検証、および許可グループデータベース３１４のデータに基づく審査を実行し、検査、審査の双方が成立したことを条件として、（４）において、名前解決サーバ３１２を適用してユーザデバイス（アクセス先ＥＥ）３１１のホスト名の名前解決処理を実行し、（５）でユーザデバイス（アクセス先ＥＥ）３１１のホスト名に対応するアドレスを取得して、（６）で、取得アドレスをユーザデバイス（アクセス元ＥＥ）３２１に通知する。
【０２２７】
次に、（７）の処理として、ユーザデバイス（アクセス元ＥＥ）３２１は、取得アドレスに基づいて、ユーザデバイス（アクセス先ＥＥ）３１１に対するアクセスを実行する。
【０２２８】
このように、アクセス要求元が、アクセス先のユーザデバイス（エンドエンティテイ）が設定したアクセス許可グループに属することが確認されることがアクセス許可条件となり、不特定多数のデバイスからのアクセスが排除可能となる。また、属性証明書に基づく検証、審査が実行されるので、確実な審査が可能となる。
【０２２９】
（３−５）アドレス更新処理
上述の手法により、アクセスをアクセス先ＥＥの認定したグループのメンバーに限定することが可能となる。エンドエンティテイ（ユーザデバイス）のアドレスが固定的であると、一度取得したアドレス情報に基づいて、その後、アクセス許可グループから除外された場合でもアクセスされる可能性がある。このような事態を防止するため、アドレスを動的に変更するアドレス更新処理について、以下説明する。
【０２３０】
まず、図３４のシーケンス図に基づいて、ホームサーバが、エンドエンティテイのアドレス更新スケジュールを管理し、スケジュールに従って、エンドエンティテイ（ＥＥ）のアドレスの更新処理を実行するシーケンスについて説明する。図３４において、
更新対象ＥＥ：アドレスの更新を実行するエンドエンティテイ（ユーザデバイス）
ホームサーバ：更新対象ＥＥのホスト名に基づく名前解決をアクセス要求元から提示される属性証明書、および登録されたアクセス許可情報に基づいて判定するホームサーバ
ホーム名前解決サーバ：更新対象ＥＥに関するホスト名からアドレスの取得処理（名前解決処理）を行なうサーバ
である。
【０２３１】
まず、ステップＳ５１１において、ホームサーバは、アドレス更新時期スケジューリングに従って、更新時期のエンドエンティテイを選択し更新対象ＥＥを決定（Ｓ５１２）する。アドレス更新時期スケジュールデータは、例えば所定日数ごとの一定期間サイクルの更新実行スケジュールをエンドエンティテイごとの管理データとして構成する。
【０２３２】
更新対象のエンドエンティテイが決定すると、ステップＳ５１３において、アドレス更新通知が更新対象ＥＥに通知され、ステップＳ５１４でホームサーバと、更新対象ＥＥ間の相互認証を実行する。相互認証処理は、例えば先に図１７を参照して説明したシーケンスに従って実行される。相互認証の成立を条件として、次ステップに進む。
【０２３３】
ステップＳ５１５において、更新対象ＥＥは、自己のグループ属性証明書をホームサーバに提示する。グループ属性証明書は、例えばドメイン名属性証明書、ホスト名属性証明書、あるいはその他のグループ情報を属性情報として格納したグループ属性証明書である。
【０２３４】
ステップＳ５１６において、ホームサーバは、更新対象ＥＥから受信したグループ属性証明書（グループＡＣ）の検証、審査を実行する。検証、審査処理は、先に図２９乃至図３２を参照して説明した処理に準ずる処理である。ただし、ここでの審査は、許可グループデータベースに対応するグループのアクセス許可がなされているか否かではなく、許可グループデータベースに更新対象ＥＥの対応エントリが存在するか否かの審査となる。存在する場合は、審査成立とする。
【０２３５】
グループＡＣの検証、審査が不成立の場合（Ｓ５１７：Ｎｏ）は、エラー処理（Ｓ５１８）として、例えば更新対象ＥＥに対してエラーメッセージの送付等が行なわれる。グループＡＣの検証、審査が成立の場合（Ｓ５１７：Ｙｅｓ）は、ステップＳ５１９において、更新対象ＥＥのアドレスが更新され、新アドレスが更新対象ＥＥに対して送信され、更新対象ＥＥにおいて、新アドレスに基づくアドレス更新が実行（Ｓ５２０）されて、更新完了通知がホームサーバに通知される。
【０２３６】
ホームサーバは、更新対象ＥＥの新アドレスをホーム名前解決サーバに、更新対象ＥＥ名（ホスト名）とともに通知（Ｓ５２１）し、ホーム名前解決サーバは、名前解決データベース（図１４（ｂ）参照）を更新（Ｓ５２２）する。
【０２３７】
次に、図３５のシーケンス図に基づいて、更新対象エンドエンティテイ（ＥＥ）自身が、自己のアドレス更新スケジュールを管理し、スケジュールに従ってアドレス更新処理を実行するシーケンスについて説明する。図３５において、
更新対象ＥＥ：アドレスの更新を実行するエンドエンティテイ（ユーザデバイス）
ホームサーバ：更新対象ＥＥのホスト名に基づく名前解決をアクセス要求元から提示される属性証明書、および登録されたアクセス許可情報に基づいて判定するホームサーバ
ホーム名前解決サーバ：更新対象ＥＥに関するホスト名からアドレスの取得処理（名前解決処理）を行なうサーバ
である。
【０２３８】
まず、ステップＳ５３１において、更新対象ＥＥは、アドレス更新時期スケジューリングに従って、更新時期の到来を確認し、ステップＳ５３２において、アドレス更新要求をホームサーバに送信し、ステップＳ５３３でホームサーバと、更新対象ＥＥ間の相互認証を実行する。相互認証処理は、例えば先に図１７を参照して説明したシーケンスに従って実行される。相互認証の成立を条件として、次ステップに進む。
【０２３９】
ステップＳ５３４において、更新対象ＥＥは、自己のグループ属性証明書をホームサーバに提示する。グループ属性証明書は、例えばドメイン名属性証明書、ホスト名属性証明書、あるいはその他のグループ情報を属性情報として格納したグループ属性証明書である。
【０２４０】
ステップＳ５３５において、ホームサーバは、更新対象ＥＥから受信したグループ属性証明書（グループＡＣ）の検証、審査を実行する。検証、審査処理は、先に図２９乃至図３２を参照して説明した処理に準ずる処理である。ただし、ここでの審査は、許可グループデータベースに対応するグループのアクセス許可がなされているか否かではなく、許可グループデータベースに更新対象ＥＥの対応エントリが存在するか否かの審査となる。存在する場合は、審査成立とする。
【０２４１】
グループＡＣの検証、審査が不成立の場合（Ｓ５３６：Ｎｏ）は、エラー処理（Ｓ５３７）として、例えば更新対象ＥＥに対してエラーメッセージの送付等が行なわれる。グループＡＣの検証、審査が成立の場合（Ｓ５３６：Ｙｅｓ）は、ステップＳ５３８において、更新対象ＥＥのアドレスが更新され、新アドレスが更新対象ＥＥに対して送信され、更新対象ＥＥにおいて、新アドレスに基づくアドレス更新が実行（Ｓ５３９）されて、更新完了通知がホームサーバに通知される。
【０２４２】
ホームサーバは、更新対象ＥＥの新アドレスをホーム名前解決サーバに、更新対象ＥＥ名（ホスト名）とともに通知（Ｓ５４０）し、ホーム名前解決サーバは、名前解決データベース（図１４（ｂ）参照）を更新（Ｓ５４１）する。
【０２４３】
次に、ホームサーバおよびエンドエンティテイの属するドメイン名に対応するアドレスの更新処理シーケンスについて説明する。
【０２４４】
まず、図３６を参照して、ホームサーバのドメイン名に対応するアドレス管理を実行するサービスプロバイダ（ＳＰ）が、アドレス更新スケジュールを管理し、スケジュールに従って、ホームサーバおよびエンドエンティテイの属するドメイン名に対応するアドレスの更新処理を実行するシーケンスについて説明する。図３６において、
更新対象ドメイン内ＥＥ：ドメイン名対応アドレスの更新を実行するドメイン内のエンドエンティテイ（ユーザデバイス）
更新対象ドメイン名前解決サーバ：ドメイン名対応アドレスの更新を実行するドメイン内の名前解決サーバ
更新対象ホームドメインホームサーバ：ドメイン名対応アドレスの更新を実行するドメイン内のホームサーバ
ＳＰ：ドメイン名に対応するアドレス管理を実行するサービスプロバイダ（ＳＰ）
ＳＰ名前解決サーバ：ＳＰの管理する名前解決サーバであり、ドメイン名に対応するアドレスの取得処理を実行するデータ（図１４（ａ）参照）を有する
である。
【０２４５】
まず、ステップＳ５５１において、サービスプロバイダ（ＳＰ）は、アドレス更新時期スケジューリングに従って、更新時期のドメインを選択し更新対象ドメインを決定（Ｓ５５２）する。アドレス更新時期スケジュールデータは、例えば所定日数ごとの一定期間サイクルの更新実行スケジュールをドメインごとの管理データとして構成する。
【０２４６】
更新対象のドメインが決定すると、ステップＳ５５３において、アドレス空間更新通知が更新対象ドメインホームサーバに通知され、ステップＳ５５４でサービスプロバイダ（ＳＰ）と、更新対象ドメインホームサーバ間の相互認証を実行する。相互認証処理は、例えば先に図１７を参照して説明したシーケンスに従って実行される。相互認証の成立を条件として、次ステップに進む。
【０２４７】
ステップＳ５５５において、更新対象ドメインホームサーバは、自己のグループ属性証明書をサービスプロバイダ（ＳＰ）に提示する。グループ属性証明書は、例えばドメイン名属性証明書、あるいはその他のグループ情報を属性情報として格納したグループ属性証明書である。
【０２４８】
ステップＳ５５６において、サービスプロバイダ（ＳＰ）は、更新対象ドメインホームサーバから受信したグループ属性証明書（グループＡＣ）の検証、審査を実行する。検証、審査処理は、先に図２９乃至図３２を参照して説明した処理に準ずる処理である。ただし、ここでの審査は、許可グループデータベースに対応するグループのアクセス許可がなされているか否かではなく、許可グループデータベースに更新対象ドメインホームサーバの対応エントリが存在するか否かの審査となる。存在する場合は、審査成立とする。
【０２４９】
グループＡＣの検証、審査が不成立の場合（Ｓ５５７：Ｎｏ）は、エラー処理（Ｓ５５８）として、例えば更新対象ドメインホームサーバに対してエラーメッセージの送付等が行なわれる。グループＡＣの検証、審査が成立の場合（Ｓ５５７：Ｙｅｓ）は、ステップＳ５５９において、更新対象ドメインに対応する新アドレス空間の割り当てを実行する。
【０２５０】
次に、サービスプロバイダ（ＳＰ）は、更新対象ドメインに対応する新アドレス空間を更新対象ドメインホームサーバに通知し、さらに、ＳＰ名前解決サーバに、ドメイン名とともに新アドレス空間データを通知（Ｓ５６０）する。ＳＰ名前解決サーバは、名前解決データベース（図１４（ａ）参照）を更新（Ｓ５６１）する。
【０２５１】
さらに、更新対象ドメインホームサーバは、新アドレス空間通知を更新対象ドメイン名前解決サーバに通知（Ｓ５６２）し、更新対象ドメイン名前解決サーバは、名前解決データベース（図１４（ｂ）参照）を更新（Ｓ５６３）して、更新完了通知を更新対象ドメインホームサーバに送信する。更新対象ドメインホームサーバは、さらに、自己の管理ユーザデバイスであるエンドエンティテイである更新対象ドメイン内ＥＥに対して、更新された新アドレスを通知（Ｓ５６４）し、更新対象ドメイン内ＥＥにおいて、新アドレスに基づくアドレス更新が実行（Ｓ５６５）されて、更新完了通知が更新対象ドメインホームサーバに通知され、更新処理が終了する。
【０２５２】
次に、図３７を参照して、ホームサーバ自身がドメイン名に対応するアドレス管理を実行して、スケジュールに従って、ホームサーバおよびエンドエンティテイの属するドメイン名に対応するアドレスの更新処理を実行するシーケンスについて説明する。図３７において、
更新対象ドメイン内ＥＥ：ドメイン名対応アドレスの更新を実行するドメイン内のエンドエンティテイ（ユーザデバイス）
更新対象ドメイン名前解決サーバ：ドメイン名対応アドレスの更新を実行するドメイン内の名前解決サーバ
更新対象ホームドメインホームサーバ：ドメイン名対応アドレスの更新を実行するドメイン内のホームサーバ
ＳＰ：ドメイン名に対応するアドレス管理を実行するサービスプロバイダ（ＳＰ）
ＳＰ名前解決サーバ：ＳＰの管理する名前解決サーバであり、ドメイン名に対応するアドレスの取得処理を実行するデータ（図１４（ａ）参照）を有する
である。
【０２５３】
まず、ステップＳ５７１において、更新対象ドメインホームサーバは、アドレス更新時期スケジューリングに従って、更新時期の到来を確認すると、アドレス更新要求をサービスプロバイダ（ＳＰ）に通知（Ｓ５７２）する。ステップＳ５７３でサービスプロバイダ（ＳＰ）と、更新対象ドメインホームサーバ間の相互認証を実行する。相互認証処理は、例えば先に図１７を参照して説明したシーケンスに従って実行される。相互認証の成立を条件として、次ステップに進む。
【０２５４】
ステップＳ５７４において、更新対象ドメインホームサーバは、自己のグループ属性証明書をサービスプロバイダ（ＳＰ）に提示する。グループ属性証明書は、例えばドメイン名属性証明書、あるいはその他のグループ情報を属性情報として格納したグループ属性証明書である。
【０２５５】
ステップＳ５７５において、サービスプロバイダ（ＳＰ）は、更新対象ドメインホームサーバから受信したグループ属性証明書（グループＡＣ）の検証、審査を実行する。検証、審査処理は、先に図２９乃至図３２を参照して説明した処理に準ずる処理である。ただし、ここでの審査は、許可グループデータベースに対応するグループのアクセス許可がなされているか否かではなく、許可グループデータベースに更新対象ドメインホームサーバの対応エントリが存在するか否かの審査となる。存在する場合は、審査成立とする。
【０２５６】
グループＡＣの検証、審査が不成立の場合（Ｓ５７６：Ｎｏ）は、エラー処理（Ｓ５７７）として、例えば更新対象ドメインホームサーバに対してエラーメッセージの送付等が行なわれる。グループＡＣの検証、審査が成立の場合（Ｓ５７６：Ｙｅｓ）は、ステップＳ５７８において、更新対象ドメインに対応する新アドレス空間の割り当てを実行する。
【０２５７】
次に、サービスプロバイダ（ＳＰ）は、更新対象ドメインに対応する新アドレス空間を更新対象ドメインホームサーバに通知し、さらに、ＳＰ名前解決サーバに、ドメイン名とともに新アドレス空間データを通知（Ｓ５７９）する。ＳＰ名前解決サーバは、名前解決データベース（図１４（ａ）参照）を更新（Ｓ５８０）する。
【０２５８】
さらに、更新対象ドメインホームサーバは、新アドレス空間通知を更新対象ドメイン名前解決サーバに通知（Ｓ５８１）し、更新対象ドメイン名前解決サーバは、名前解決データベース（図１４（ｂ）参照）を更新（Ｓ５８２）して、更新完了通知を更新対象ドメインホームサーバに送信する。更新対象ドメインホームサーバは、さらに、自己の管理ユーザデバイスであるエンドエンティテイである更新対象ドメイン内ＥＥに対して、更新された新アドレスを通知（Ｓ５８３）し、更新対象ドメイン内ＥＥにおいて、新アドレスに基づくアドレス更新が実行（Ｓ５８４）されて、更新完了通知が更新対象ドメインホームサーバに通知され、更新処理が終了する。
【０２５９】
図３８を参照してアドレス更新による効果について説明する。図３８のユーザデバイス３２１がアクセス元ＥＥであり、ユーザデバイス３１１がアクセス先ＥＥである。ユーザデバイス３２１（アクセス元ＥＥ）は、ユーザデバイス３１１（アクセス先ＥＥ）からアクセス許可グループのメンバーとして、過去において、認められていたが、現在はアクセス許可グループのメンバーから除外されているものとする。
【０２６０】
たとえば、ユーザデバイス３２１（アクセス元ＥＥ）のドメイン名［ｈｏｍｅ２．ｘｙｚ．ｃｏｍ］がアクセス許可グループとして、ユーザデバイス３１１（アクセス先ＥＥ）を管轄する中継サーバ１（ホームサーバ１）３１３の適用する許可グループデータベース３１４に登録されていたが、その後削除されたものとする。さらに、ユーザデバイス３１１（アクセス先ＥＥ）は、前述した説明に従ったアドレス更新を実行して、旧アドレス［１０．０．１．１００］から、新アドレス［１０．０．１．２２２］に更新処理を行なったとする。
【０２６１】
ユーザデバイス３２１（アクセス元ＥＥ）は、過去にユーザデバイス３１１（アクセス先ＥＥ）にアクセスした時点で取得したアドレス［１０．０．１．１００］を適用して、ユーザデバイス３１１（アクセス先ＥＥ）に対するアクセスを実行しようとしても、現在のユーザデバイス３１１（アクセス先ＥＥ）のアドレスは新アドレス［１０．０．１．２２２］であるので、アクセスすることはできない。
【０２６２】
また、ユーザデバイス３１１（アクセス先ＥＥ）のホスト名［ｅｅ−ａ．ｈｏｍｅ１．ａｂｃ．ｎｅｔ］を適用して名前解決処理によって新アドレスを取得してアクセスを実行しようとしても、中継サーバ１（ホームサーバ１）３１３における属性証明書検証および審査により、ユーザデバイス３２１（アクセス元ＥＥ）は、ユーザデバイス３１１（アクセス先ＥＥ）からアクセス許可グループのメンバーとして認められていないと判断され、名前解決処理が拒否されることになり、新アドレスの取得が行なわれず、新アドレスによるアクセスの実行は防止される。
【０２６３】
［（４）各エンティテイの構成］
次に、上述した処理、すなわち属性証明書の生成、検証、送受信等を実行するユーザデバイスとしてのエンドエンティテイ（ＥＥ）、中継サーバとしてのホームサーバ、あるいはサービスプロバイダ（ＳＰ）等、各エンティテイの情報処理装置としての構成例について図を参照しながら、説明する。
【０２６４】
ユーザデバイス、ホームサーバ、サービスプロバイダ等、各エンティテイの情報処理装置は、各種のデータ処理、および制御を実行するＣＰＵを有し、かつ他エンティテイと通信可能な通信手段を備えた例えば、サーバ、ＰＣ、ＰＤＡ、形態通信端末装置等の各種の情報処理装置によって構成可能である。
【０２６５】
図３９に情報処理装置構成例を示す。なお、図３９に示す構成例は１つの例であり、各エンティテイは、ここに示すべての機能を必ずしも備えることが要求されるものではない。図３９に示すＣＰＵ（Ｃｅｎｔｒａｌ　ｐｒｏｃｅｓｓｉｎｇ　Ｕｎｉｔ）９５１は、各種アプリケーションプログラムや、ＯＳ（Ｏｐｅｒａｔｉｎｇ　Ｓｙｓｔｅｍ）を実行するプロセッサである。ＲＯＭ（Ｒｅａｄ−Ｏｎｌｙ−Ｍｅｍｏｒｙ）９５２は、ＣＰＵ９５１が実行するプログラム、あるいは演算パラメータとしての固定データを格納する。ＲＡＭ（Ｒａｎｄｏｍ　Ａｃｃｅｓｓ　Ｍｅｍｏｒｙ）９５３は、ＣＰＵ９５１の処理において実行されるプログラム、およびプログラム処理において適宜変化するパラメータの格納エリア、ワーク領域として使用される。
【０２６６】
ＨＤＤ９５４はハードディスクの制御を実行し、ハードディスクに対する各種データ、プログラムの格納処理および読み出し処理を実行する。セキュリティチップ９６２は、前述したように耐タンパ構造を持つ構成であり、暗号処理に必要な鍵データ等を格納し、権限確認処理としての属性証明書の検証、あるいは生成処理等を実行する暗号処理部、データ処理部、メモリを有する。
【０２６７】
バス９６０はＰＣＩ（Ｐｅｒｉｐｈｅｒａｌ　Ｃｏｍｐｏｎｅｎｔ　Ｉｎｔｅｒｆａｃｅ）バス等により構成され、各モジュール、入出力インタフェース９６１を介した各入手力装置とのデータ転送を可能にしている。
【０２６８】
入力部９５５は、例えばキーボード、ポインティングデバイス等によって構成され、ＣＰＵ９５１に各種のコマンド、データを入力するためにユーザにより操作される。出力部９５６は、例えばＣＲＴ、液晶ディスプレイ等であり、各種情報をテキストまたはイメージ等により表示する。
【０２６９】
通信部９５７はデバイスの接続したエンティテイ、例えばサービスプロバイダ等との通信処理を実行するネットワークインタフェース、接続機器インタフェース等からなり、ＣＰＵ９５１の制御の下に、各記憶部から供給されたデータ、あるいはＣＰＵ９５１によって処理されたデータ、暗号化されたデータ等を送信したり、他エンティテイからのデータを受信する処理を実行する。
【０２７０】
ドライブ９５８は、フレキシブルディスク、ＣＤ−ＲＯＭ（Ｃｏｍｐａｃｔ　Ｄｉｓｃ　ＲｅａｄＯｎｌｙ　Ｍｅｍｏｒｙ），ＭＯ（Ｍａｇｎｅｔｏ　ｏｐｔｉｃａｌ）ディスク，ＤＶＤ（Ｄｉｇｉｔａｌ　Ｖｅｒｓａｔｉｌｅ　Ｄｉｓｃ）、磁気ディスク、半導体メモリなどのリムーバブル記録媒体９５９の記録再生を実行するドライブであり、各リムーバブル記録媒体９５９からのプログラムまたはデータ再生、リムーバブル記録媒体９５９に対するプログラムまたはデータ格納を実行する。
【０２７１】
各記憶媒体に記録されたプログラムまたはデータを読み出してＣＰＵ９５１において実行または処理を行なう場合は、読み出したプログラム、データはインタフェース９６１、バス９６０を介して例えば接続されているＲＡＭ９５３に供給される。
【０２７２】
前述の説明内に含まれるユーザデバイス、サービスプロバイダ等における処理を実行するためのプログラムは例えばＲＯＭ９５２に格納されてＣＰＵ９５１によって処理されるか、あるいはハードディスクに格納されＨＤＤ９５４を介してＣＰＵ９５１に供給されて実行される。
【０２７３】
以上、特定の実施例を参照しながら、本発明について詳解してきた。しかしながら、本発明の要旨を逸脱しない範囲で当業者が該実施例の修正や代用を成し得ることは自明である。すなわち、例示という形態で本発明を開示してきたのであり、限定的に解釈されるべきではない。本発明の要旨を判断するためには、冒頭に記載した特許請求の範囲の欄を参酌すべきである。
【０２７４】
なお、明細書中において説明した一連の処理はハードウェア、またはソフトウェア、あるいは両者の複合構成によって実行することが可能である。ソフトウェアによる処理を実行する場合は、処理シーケンスを記録したプログラムを、専用のハードウェアに組み込まれたコンピュータ内のメモリにインストールして実行させるか、あるいは、各種処理が実行可能な汎用コンピュータにプログラムをインストールして実行させることが可能である。
【０２７５】
例えば、プログラムは記録媒体としてのハードディスクやＲＯＭ（Ｒｅａｄ　Ｏｎｌｙ　Ｍｅｍｏｒｙ）に予め記録しておくことができる。あるいは、プログラムはフケキシブルディスク、ＣＤ−ＲＯＭ（Ｃｏｍｐａｃｔ　Ｄｉｓｃ　Ｒｅａｄ　Ｏｎｌｙ　Ｍｅｍｏｒｙ），ＭＯ（Ｍａｇｎｅｔｏ　ｏｐｔｉｃａｌ）ディスク，ＤＶＤ（Ｄｉｇｉｔａｌ　Ｖｅｒｓａｔｉｌｅ　Ｄｉｓｃ）、磁気ディスク、半導体メモリなどのリムーバブル記録媒体に、一時的あるいは永続的に格納（記録）しておくことができる。このようなリムーバブル記録媒体は、いわゆるパッケージソフトウエアとして提供することができる。
【０２７６】
なお、プログラムは、上述したようなリムーバブル記録媒体からコンピュータにインストールする他、ダウンロードサイトから、コンピュータに無線転送したり、ＬＡＮ（Ｌｏｃａｌ　Ａｒｅａ　Ｎｅｔｗｏｒｋ）、インターネットといったネットワークを介して、コンピュータに有線で転送し、コンピュータでは、そのようにして転送されてくるプログラムを受信し、内蔵するハードディスク等の記録媒体にインストールすることができる。
【０２７７】
なお、明細書に記載された各種の処理は、記載に従って時系列に実行されるのみならず、処理を実行する装置の処理能力あるいは必要に応じて並列的にあるいは個別に実行されてもよい。また、本明細書においてシステムとは、複数の装置の論理的集合構成であり、各構成の装置が同一筐体内にあるものには限らない。
【０２７８】
【発明の効果】
以上、説明したように、本発明によれば、通信ネットワークを介した通信処理装置間の通信において、アクセス先の許容するアクセス元であるか否かをホームサーバ等の中継サーバにおいて判定して、アクセス先の許容するアクセス元である場合にのみ、名前解決処理を実行して、アクセス先のアドレス情報をアクセス元に通知する構成としたので、アクセス先の許容したアクセス元からのアクセスのみを実行する構成が実現される。
【０２７９】
さらに、本発明の構成によれば、通信ネットワークを介した通信処理装置間の通信において、ホームサーバ等の中継サーバが、アクセス元の属性証明書の検証、審査を実行して、アクセス元がアクセス先の許容メンバーであるか否かの判定処理を実行し、アクセス先の許容するアクセス元である場合にのみ、名前解決処理を実行して、アクセス先のアドレス情報をアクセス元に通知する構成としたので、属性証明書に基づく確実な審査によるアクセス制限を実行することが可能となる。
【０２８０】
さらに、本発明の構成によれば、アクセス元のドメイン名属性証明書、ホスト名属性証明書等、属性情報としてドメイン名、ホスト名を記述したグループ属性証明書を適用する構成としたので、特定ドメインに属する機器、あるいは特定ホスト名の機器に限定したアクセス制限を実行することが可能となる。
【０２８１】
さらに、本発明の構成によれば、アクセス元のドメイン名属性証明書、ホスト名属性証明書等、属性情報としてドメイン名、ホスト名を記述したグループ属性証明書を適用する構成とするとともに、ドメイン名、ホスト名に対応するアドレスの更新を実行する構成としたので、旧アドレスを適用したアクセスの排除が可能となる。
【図面の簡単な説明】
【図１】アクセス権限管理システムにおける公開鍵基盤、権限管理基盤構成について説明する図である。
【図２】公開鍵証明書のフォーマットを示す図である。
【図３】公開鍵証明書のフォーマットを示す図である。
【図４】公開鍵証明書のフォーマットを示す図である。
【図５】権限情報証明書としての属性証明書のフォーマットを示す図である。
【図６】グループ属性証明書（グループＡＣ）の構成例を示す図である。
【図７】ドメイン名属性証明書およびホスト名属性証明書のフォーマットを示す図である。
【図８】ドメイン名属性証明書の発行体系を説明する図である。
【図９】ホスト名属性証明書の発行体系を説明する図である。
【図１０】アクセス権限管理システムに参加する各エンティテイの信頼関係構成を説明するトラストモデルを示す図である。
【図１１】ユーザデバイス、ホームサーバ、サービスプロバイダ等のエンティテイに構成されるセキュリテイチップの構成例を示す図である。
【図１２】ユーザデバイスのセキュリティチップの格納データ例を示す図である。
【図１３】アクセス権限管理システムの概要について説明する図である。
【図１４】名前解決サーバの有するデータベース構成例である。
【図１５】ドメイン名登録処理シーケンスを示す図である。
【図１６】ドメイン名属性証明書発行処理シーケンスを示す図である。
【図１７】公開鍵暗号方式の１つの認証処理方式であるハンドシェイクプロトコル（ＴＬＳ１．０）について示す図である。
【図１８】メッセージ認証コード：ＭＡＣ（Ｍｅｓｓａｇｅ　Ａｕｔｈｅｎｔｉｃａｔｉｏｎ　Ｃｏｄｅ）の生成構成を示す図である。
【図１９】電子署名の生成処理を説明するフロー図である。
【図２０】電子署名の検証処理を説明するフロー図である。
【図２１】新規エンドエンティテイ（ＥＥ）の登録処理シーケンスを示す図である。
【図２２】エンドエンティテイ（ＥＥ）によるドメイン名属性証明書発行処理シーケンスを示す図である。
【図２３】エンドエンティテイ（ＥＥ）によるホスト名属性証明書発行処理シーケンスを示す図である。
【図２４】エンドエンティテイ（ＥＥ）によるアクセス許可グループ情報登録処理シーケンスを示す図である。
【図２５】アクセス許可グループ情報のデータ構成例を示す図である。
【図２６】エンドエンティテイ（ＥＥ）によるアクセス許可グループ情報削除処理シーケンスを示す図である。
【図２７】アクセス権限の確認を伴うアクセス処理シーケンスを説明する図である。
【図２８】ドメイン名に基づくアドレス取得処理シーケンスを説明する図である。
【図２９】公開鍵証明書（ＰＫＣ）と属性証明書（ＡＣ）との関連について説明する図である。
【図３０】属性証明書（ＡＣ）の検証処理フローを示す図である。
【図３１】公開鍵証明書（ＰＫＣ）の検証処理フローを示す図である。
【図３２】アクセス権限審査処理について説明するシーケンス図である。
【図３３】アクセス権限の確認を伴うアクセス処理シーケンスを説明する図である。
【図３４】エンドエンティテイ（ＥＥ）のアドレス更新処理シーケンスを示す図である。
【図３５】エンドエンティテイ（ＥＥ）のアドレス空間更新処理シーケンスを示す図である。
【図３６】ドメインに対応するアドレス空間の更新処理シーケンスを示す図である。
【図３７】ドメインに対応するアドレスの更新処理シーケンスを示す図である。
【図３８】アドレスの更新処理による効果を説明する図である。
【図３９】ユーザデバイス、ホームサーバ、サービスプロバイダ等、各エンティテイの情報処理装置構成例を示す図である。
【符号の説明】
１０１　公開鍵基盤
１０２　権限管理基盤
１１０　ネットワーク
１２１　公開鍵証明書
１２２　属性証明書
１３０，１４０　中継サーバ（ホームサーバ）
１３１−１３３，１４１−１４３　ユーザデバイス
１３５，１４５　名前解決サーバ
１５０　ドメイン名属性証明書認証局
１５１，１５２，１５３　ドメイン領域
１５４　セカンドレベルドメイン割当機関
１５５　サービスプロバイダ
１５６，１５７　ホームサーバ
１５８−１６０　エンドエンティテイ（ＥＥ）
１６１−１６６　ドメイン名属性証明書
１７１，１７２　ホスト名属性証明書認証局
１７３−１７７　ホスト名属性証明書
１８０　システムホルダ
１８１　ルート認証局（ＣＡ）
１８２　認証局（ＣＡ）
１８３　登録局（ＲＡ）
１８４　属性証明書認証局（ＡＡ）
１８５　属性証明書登録局（ＡＲＡ）
１８６　ポリシーテーブル
１８７　サービスプロバイダ（ＳＰ）
１９０　ドメイン領域
１９１　エンドエンティテイ（ＥＥ）
１９２　ホームサーバ（ＨＳ）
２００　デバイス
２０１　ＣＰＵ　（Ｃｅｎｔｒａｌ　ｐｒｏｃｅｓｓｉｎｇ　Ｕｎｉｔ）
２０２　インタフェース
２０３　ＲＯＭ（Ｒｅａｄ−Ｏｎｌｙ−Ｍｅｍｏｒｙ）
２０４　ＲＡＭ（Ｒａｎｄｏｍ　Ａｃｃｅｓｓ　Ｍｅｍｏｒｙ）
２０５　暗号処理部
２０６　メモリ部
２１０　セキュリティチップ
２２１　ユーザデバイス側制御部
２２２　外部メモリ部
２３１　接続機器インタフェース
２３２　ネットワークインタフェース
３１１，３２１　ユーザデバイス
３１２，３２２　名前解決サーバ
３１３，３２３　中継サーバ（ホームサーバ）
３１４，３２４　許可グループデータベース
３３１，３４１　サービスプロバイダ
３３２，３４２　ドメイン名属性証明書登録局
３３３，３４３　名前解決サーバ
３５１，３５２　ドメイン名属性証明書認証局
３５５　通信ネットワーク
９５１　ＣＰＵ　（Ｃｅｎｔｒａｌ　ｐｒｏｃｅｓｓｉｎｇ　Ｕｎｉｔ）
９５２　ＲＯＭ（Ｒｅａｄ−Ｏｎｌｙ−Ｍｅｍｏｒｙ）
９５３　ＲＡＭ（Ｒａｎｄｏｍ　Ａｃｃｅｓｓ　Ｍｅｍｏｒｙ）
９５４　ＨＤＤ
９５５　入力部
９５６　出力部
９５７　通信部
９５８　ドライブ
９５９　リムーバブル記録媒体
９６０　バス
９６１　入出力インタフェース
９６２　セキュリティチップ

Claims (22)

1. 通信ネットワークを介した通信処理装置間の通信におけるアクセス権限管理システムであり、
   アクセス先通信処理装置のホスト名とアドレスの対応データを有し、アクセス先通信処理装置に対応するホスト名に関する名前解決処理を実行する名前解決サーバと、
   アクセス元通信処理装置から、アクセス先通信処理装置のホスト名を受信するとともに、特定通信処理装置の集合からなるグループに対応して設定されるグループ識別情報を格納し発行者電子署名を有するグループ属性証明書を受信し、該グループ属性証明書の検証処理、および、アクセス先通信処理装置のアクセス許容グループにアクセス元通信処理装置が属するか否かの審査処理を実行し、該検証および審査が成立したことを条件として、前記名前解決サーバを適用した名前解決処理により、アクセス先通信処理装置のアドレスを取得し、前記アクセス元通信処理装置に対する通知処理を実行する中継サーバと、
   を有することを特徴とするアクセス権限管理システム。
2. 前記グループ属性証明書は、
   ドメイン名をグループ識別情報として格納し、
   前記中継サーバは、
   前記アクセス先通信処理装置に対するアクセス許可グループ情報としてドメイン名によるアクセス許可グループ情報を格納した許可グループデータベースを参照して、アクセス先通信処理装置のアクセス許容グループにアクセス元通信処理装置が属するか否かの審査処理を実行する構成であることを特徴とする請求項１に記載のアクセス権限管理システム。
3. 前記グループ属性証明書は、
   ホスト名をグループ識別情報として格納し、
   前記中継サーバは、
   前記アクセス先通信処理装置に対するアクセス許可グループ情報としてホスト名によるアクセス許可グループ情報を格納した許可グループデータベースを参照して、アクセス先通信処理装置のアクセス許容グループにアクセス元通信処理装置が属するか否かの審査処理を実行する構成であることを特徴とする請求項１に記載のアクセス権限管理システム。
4. 前記中継サーバは、
   前記アクセス先通信処理装置にネットワーク接続されたホームサーバであることを特徴とする請求項１に記載のアクセス権限管理システム。
5. 前記中継サーバは、
   前記アクセス先通信処理装置に対応するドメイン名またはホスト名に対応するアドレスの更新処理を実行する構成を有し、
   前記アクセス先通信処理装置の有する属性証明書の検証の成立を条件として前記更新処理を実行する構成であることを特徴とする請求項１に記載のアクセス権限管理システム。
6. 前記中継サーバは、
   アクセス元通信処理装置との相互認証を実行し、相互認証の成立を条件として、前記アクセス元通信処理装置から提示されるグループ属性証明書の検証および審査を実行する構成であることを特徴とする請求項１に記載のアクセス権限管理システム。
7. 前記グループ属性証明書は、グループ属性証明書に対応する公開鍵証明書に関するリンク情報を格納した構成であり、
   前記中継サーバは、
   前記グループ属性証明書の検証に際し、前記リンク情報によって取得される公開鍵証明書の検証を併せて実行する構成であることを特徴とする請求項１に記載のアクセス権限管理システム。
8. 通信ネットワークを介した通信処理装置間の通信におけるアクセス権限管理を実行する中継サーバであり、
   アクセス元通信処理装置から、アクセス先通信処理装置のホスト名を受信するとともに、特定通信処理装置の集合からなるグループに対応して設定されるグループ識別情報を格納し発行者電子署名を有するグループ属性証明書を受信し、該グループ属性証明書の検証処理、および、アクセス先通信処理装置のアクセス許容グループにアクセス元通信処理装置が属するか否かの審査処理を実行し、該検証および審査が成立したことを条件として、名前解決サーバを適用した名前解決処理により、アクセス先通信処理装置のアドレスを取得し、前記アクセス元通信処理装置に対する通知処理を実行する構成を有することを特徴とする中継サーバ。
9. 前記グループ属性証明書は、
   ドメイン名をグループ識別情報として格納し、
   前記中継サーバは、
   前記アクセス先通信処理装置に対するアクセス許可グループ情報としてドメイン名によるアクセス許可グループ情報を格納した許可グループデータベースを参照して、アクセス先通信処理装置のアクセス許容グループにアクセス元通信処理装置が属するか否かの審査処理を実行する構成であることを特徴とする請求項８に記載の中継サーバ。
10. 前記グループ属性証明書は、
    ホスト名をグループ識別情報として格納し、
    前記中継サーバは、
    前記アクセス先通信処理装置に対するアクセス許可グループ情報としてホスト名によるアクセス許可グループ情報を格納した許可グループデータベースを参照して、アクセス先通信処理装置のアクセス許容グループにアクセス元通信処理装置が属するか否かの審査処理を実行する構成であることを特徴とする請求項８に記載の中継サーバ。
11. 前記中継サーバは、
    前記アクセス先通信処理装置にネットワーク接続されたホームサーバであることを特徴とする請求項８に記載の中継サーバ。
12. 前記中継サーバは、
    前記アクセス先通信処理装置に対応するドメイン名またはホスト名に対応するアドレスの更新処理を実行する構成を有し、
    前記アクセス先通信処理装置の有する属性証明書の検証の成立を条件として前記更新処理を実行する構成であることを特徴とする請求項８に記載の中継サーバ。
13. 前記中継サーバは、
    アクセス元通信処理装置との相互認証を実行し、相互認証の成立を条件として、前記アクセス元通信処理装置から提示されるグループ属性証明書の検証および審査を実行する構成であることを特徴とする請求項８に記載の中継サーバ。
14. 前記グループ属性証明書は、グループ属性証明書に対応する公開鍵証明書に関するリンク情報を格納した構成であり、
    前記中継サーバは、
    前記グループ属性証明書の検証に際し、前記リンク情報によって取得される公開鍵証明書の検証を併せて実行する構成であることを特徴とする請求項８に記載の中継サーバ。
15. 通信ネットワークを介した通信処理装置間の通信におけるアクセス権限管理方法であり、
    中継サーバにおいて、アクセス元通信処理装置から、アクセス先通信処理装置のホスト名を受信するとともに、特定通信処理装置の集合からなるグループに対応して設定されるグループ識別情報を格納し発行者電子署名を有するグループ属性証明書を受信するステップ、
    該グループ属性証明書の検証処理、および、アクセス先通信処理装置のアクセス許容グループにアクセス元通信処理装置が属するか否かの審査処理を実行するステップ、
    該検証および審査が成立したことを条件として、名前解決サーバを適用した名前解決処理により、アクセス先通信処理装置のアドレスを取得し、前記アクセス元通信処理装置に対する通知処理を実行するステップ、
    を含むことを特徴とするアクセス権限管理方法。
16. 前記グループ属性証明書は、
    ドメイン名をグループ識別情報として格納し、
    前記中継サーバは、
    前記アクセス先通信処理装置に対するアクセス許可グループ情報としてドメイン名によるアクセス許可グループ情報を格納した許可グループデータベースを参照して、アクセス先通信処理装置のアクセス許容グループにアクセス元通信処理装置が属するか否かの審査処理を実行することを特徴とする請求項１５に記載のアクセス権限管理方法。
17. 前記グループ属性証明書は、
    ホスト名をグループ識別情報として格納し、
    前記中継サーバは、
    前記アクセス先通信処理装置に対するアクセス許可グループ情報としてホスト名によるアクセス許可グループ情報を格納した許可グループデータベースを参照して、アクセス先通信処理装置のアクセス許容グループにアクセス元通信処理装置が属するか否かの審査処理を実行することを特徴とする請求項１５に記載のアクセス権限管理方法。
18. 前記中継サーバは、
    前記アクセス先通信処理装置にネットワーク接続されたホームサーバであることを特徴とする請求項１５に記載のアクセス権限管理方法。
19. 前記アクセス権限管理方法において、前記中継サーバは、さらに、
    前記アクセス先通信処理装置に対応するドメイン名またはホスト名に対応するアドレスの更新処理を実行するステップを有し、
    前記アクセス先通信処理装置の有する属性証明書の検証の成立を条件として前記更新処理を実行することを特徴とする請求項１５に記載のアクセス権限管理方法。
20. 前記中継サーバは、
    アクセス元通信処理装置との相互認証を実行し、相互認証の成立を条件として、前記アクセス元通信処理装置から提示されるグループ属性証明書の検証および審査を実行することを特徴とする請求項１５に記載のアクセス権限管理方法。
21. 前記グループ属性証明書は、グループ属性証明書に対応する公開鍵証明書に関するリンク情報を格納した構成であり、
    前記中継サーバは、
    前記グループ属性証明書の検証に際し、前記リンク情報によって取得される公開鍵証明書の検証を併せて実行することを特徴とする請求項１５に記載のアクセス権限管理方法。
22. 通信ネットワークを介した通信処理装置間の通信におけるアクセス権限管理処理を実行せしめるコンピュータ・プログラムであって、
    アクセス元通信処理装置から、アクセス先通信処理装置のホスト名を受信するとともに、特定通信処理装置の集合からなるグループに対応して設定されるグループ識別情報を格納し発行者電子署名を有するグループ属性証明書を受信するステップ、
    該グループ属性証明書の検証処理、および、アクセス先通信処理装置のアクセス許容グループにアクセス元通信処理装置が属するか否かの審査処理を実行するステップ、
    該検証および審査が成立したことを条件として、名前解決サーバを適用した名前解決処理により、アクセス先通信処理装置のアドレスを取得し、前記アクセス元通信処理装置に対する通知処理を実行するステップ、
    を有することを特徴とするコンピュータ・プログラム。

Images