名前管理サーバおよびアクセス制御方法
【課題】公開鍵の登録データ量を削減し、公開鍵を管理する処理負荷を減らすことを課題とする。
【解決手段】ＤＮＳサーバ１０は、所定のドメインネームとグループ公開鍵とを対応付けて登録する旨の登録要求を受け付けた場合に、所定のドメインネームとグループ公開鍵とを対応付けて鍵情報記憶部に登録する。また、ＤＮＳサーバ１０は、所定のドメインネームに対応するＩＰアドレスを検索する旨の検索要求を受け付けた場合に、所定のドメインネームに対応するグループ公開鍵を鍵情報記憶部から取得し、グループ公開鍵を用いて、検索要求に含まれるグループ署名の正当性を検証する。そして、ＤＮＳサーバ１０は、グループ署名が正当であると検証された場合には、ドメインネームに対応するＩＰアドレスを検索し、ＩＰアドレスを検索要求の要求元に送信する。
【解決手段】ＤＮＳサーバ１０は、所定のドメインネームとグループ公開鍵とを対応付けて登録する旨の登録要求を受け付けた場合に、所定のドメインネームとグループ公開鍵とを対応付けて鍵情報記憶部に登録する。また、ＤＮＳサーバ１０は、所定のドメインネームに対応するＩＰアドレスを検索する旨の検索要求を受け付けた場合に、所定のドメインネームに対応するグループ公開鍵を鍵情報記憶部から取得し、グループ公開鍵を用いて、検索要求に含まれるグループ署名の正当性を検証する。そして、ＤＮＳサーバ１０は、グループ署名が正当であると検証された場合には、ドメインネームに対応するＩＰアドレスを検索し、ＩＰアドレスを検索要求の要求元に送信する。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、名前管理サーバおよびアクセス制御方法に関する。
【背景技術】
【０００２】
従来、インターネットの利用者に対して、ドメインネームとＩＰアドレス（Internet Protocol Address）とを対応付けて管理する名前管理システム（ＤＮＳ：Domain Name System）によるサービスが提供されている。このようなＤＮＳのソフトウェアであるＢＩＮＤ（Berkeley Internet Name Domain）では、ＩＰアドレス単位のアクセス制御を実現している。
【０００３】
ところが、ＢＩＮＤによるＩＰアドレス単位のアクセス制御では、発信元ＩＰアドレスを偽装するＩＰなりすましを防止できず、また、ＩＰアドレスを動的に割り当てるプロトコルであるＤＨＣＰ（Dynamic Host Configuration Protocol）に対応できない場合がある。このため、ＩＰなりすましを防止し、ＤＨＣＰに対応できる方式として、公開鍵署名を利用するＳＩＧ（０）を用いたアクセス制御方式が知られている。
【先行技術文献】
【特許文献】
【０００４】
【非特許文献１】“ＤＮＳにおけるアクセス制御プロトコルの検討”、［online］、［平成２３年４月１３日検索］、インターネット＜http://ci.nii.ac.jp/naid/110004028896＞
【発明の概要】
【発明が解決しようとする課題】
【０００５】
しかしながら、上記したＳＩＧ（０）を用いたアクセス制御方式では、ＤＮＳサーバ側の一つのドメインネームの登録データに対して、登録データにアクセスするユーザ数分だけ公開鍵を登録する。このため、アクセスするユーザ数が膨大な数である場合には、一つの登録データに対して大量の公開鍵を登録する必要がある。この結果、公開鍵の登録データ量が膨大な量となり、公開鍵を管理する処理負荷が大きいという課題があった。
【０００６】
そこで、この発明は、上述した従来技術の課題を解決するためになされたものであり、公開鍵を管理する処理負荷を軽減することを目的とする。
【課題を解決するための手段】
【０００７】
上述した課題を解決し、目的を達成するために、本発明に係る名前管理サーバは、所定の名前情報とグループ公開鍵とを対応付けて登録する旨の登録要求を受け付けた場合に、該所定の名前情報とグループ公開鍵とを対応付けて記憶部に保存する登録部と、グループ署名を含むとともに所定の名前情報に対応するアドレス情報を検索する旨の検索要求を検索要求受付部が受け付けた場合に、該所定の名前情報に対応するグループ公開鍵を前記記憶部から取得し、該グループ公開鍵を用いて、前記検索要求に含まれるグループ署名の正当性を検証するアクセス制御部と、前記アクセス制御部によって前記グループ署名が正当であると検証された場合には、前記記憶部から検索された前記名前情報に対応するアドレス情報を検索要求の要求元に送信する検索応答部とを有することを特徴とする。
【０００８】
また、本発明に係るアクセス制御方法は、名前管理サーバで実行されるアクセス制御方法であって、所定の名前情報とグループ公開鍵とを対応付けて登録する旨の登録要求を受け付けた場合に、該所定の名前情報とグループ公開鍵とを対応付けて記憶部に保存する登録工程と、グループ署名を含むとともに所定の名前情報に対応するアドレス情報を検索する旨の検索要求を受け付けた場合に、該所定の名前情報に対応するグループ公開鍵を前記記憶部から取得し、該グループ公開鍵を用いて、前記検索要求に含まれるグループ署名の正当性を検証するアクセス制御工程と、前記アクセス制御工程によって前記グループ署名が正当であると検証された場合には、前記記憶部から検索された前記名前情報に対応するアドレス情報を検索要求の要求元に送信する検索応答工程とを含んだことを特徴とする。
【発明の効果】
【０００９】
実施形態に係る名前管理サーバおよびアクセス制御方法によれば、公開鍵を管理する処理負荷を軽減することができるという効果を奏する。
【図面の簡単な説明】
【００１０】
【図１】図１は、実施例１に係る名前管理システムの構成を説明するための図である。
【図２】図２は、実施例１に係るＤＮＳサーバの構成を示すブロック図である。
【図３】図３は、アドレス情報テーブルの一例を示す図である。
【図４】図４は、鍵情報テーブルの一例を示す図である。
【図５】図５は、グループ署名について説明する図である。
【図６】図６は、リソースレコードの構造の一例を示す図である。
【図７】図７は、実施例１に係るＤＮＳサーバによる登録処理の流れを示すシーケンス図である。
【図８】図８は、実施例１に係るＤＮＳサーバによるアクセス制御処理の流れを示すシーケンス図である。
【図９】図９は、開示の技術に係るアクセス制御プログラムによる情報処理がコンピュータを用いて具体的に実現されることを示す図である。
【発明を実施するための形態】
【００１１】
以下に添付図面を参照して、この発明に係る名前管理サーバおよびアクセス制御方法の実施例を詳細に説明する。なお、この実施例によりこの発明が限定されるものではない。
【実施例１】
【００１２】
以下の実施例では、実施例１に係る名前管理システムの構成、ＤＮＳサーバ装置の構成および処理の流れを順に説明し、最後に実施例１による効果を説明する。
【００１３】
［名前管理システムの構成］
まず、実施例１における名前管理システムについて図１を用いて説明する。図１は、実施例１に係る名前管理システムの構成を説明するための図である。図１に示すように、実施例１における名前管理システム１は、ＤＮＳサーバ１０、ユーザ端末２０および管理端末３０を有する。ＤＮＳサーバ１０、ユーザ端末２０および管理端末３０は、インターネット４０を介して、それぞれ接続されている。なお、図１では、ＤＮＳサーバ１０、ユーザ端末２０、管理端末３０の各装置が一台ずつの例を示しているが、各装置が複数であってもよい。
【００１４】
ＤＮＳサーバ１０は、自身が管理する名前空間の範囲に対するドメインネームとＩＰアドレスとの対応関係を管理する。ＤＮＳサーバ１０は、ユーザ端末２０から所定のドメインネーム（例えば、「www.exaple.jp」）に対応するＩＰアドレスを要求するクエリ要求を受け付ける。そして、ＤＮＳサーバ１０は、クエリ要求を受け付けると、ドメインネームに対応するＩＰアドレスをユーザ端末２０に返信する。なお、ＤＮＳサーバ１０の詳しい構成については、後に図２を用いて詳述する。
【００１５】
ユーザ端末２０は、自装置がグループに所属しているか認証できるグループ署名に用いられる公開鍵（以下、グループ公開鍵という）と、グループのメンバであることを証明するメンバ証明書、グループ署名を暗号化する秘密鍵である署名鍵を保持している。
【００１６】
また、ユーザ端末２０は、ＩＰアドレスを要求するクエリ要求をＤＮＳサーバ１０に送信する際には、グループ公開鍵、メンバ証明書、署名鍵を用いて、グループ署名を生成する。そして、ユーザ端末２０は、アクセス制御に関する情報およびメッセージを含むクエリ要求をＤＮＳサーバ１０に送信する。
【００１７】
管理端末３０は、ＤＮＳサーバ１０に対してグループ公開鍵の登録を要求する。例えば、管理端末３０は、ユーザ端末２０が利用するグループ公開鍵を受信し、受信したグループ公開鍵とユーザ端末２０がアクセスする端末／サーバのドメインネームとを対応付けて記憶する旨の要求をＤＮＳサーバ１０に送信する。
【００１８】
［ＤＮＳサーバの構成］
次に、図２を用いて、図１に示したＤＮＳサーバ１０の構成を説明する。図２は、実施例１に係るＤＮＳサーバの構成を示すブロック図である。図２に示すように、このＤＮＳサーバ１０は、通信制御Ｉ／Ｆ１１、制御部１２、記憶部１３を有し、インターネット４０を介してユーザ端末２０および管理端末３０と接続される。以下にこれらの各部の処理を説明する。
【００１９】
通信制御Ｉ／Ｆ１１は、インターネット４０と接続されるユーザ端末２０および管理端末３０との間でやり取りする各種情報に関する通信を制御する。具体的には、通信制御Ｉ／Ｆ１１は、ドメインネームに関する情報およびグループ公開鍵に関する情報を含む登録要求を管理端末３０から受信し、登録した旨の応答である登録応答を管理端末３０に送信する。また、通信制御Ｉ／Ｆ１１は、ドメインネームに対応するＩＰアドレスを要求するクエリ要求を受信し、要求の応答としてＩＰアドレスまたはエラーメッセージをユーザ端末２０に送信する。
【００２０】
記憶部１３は、例えばＲＡＭ（Random Access Memory）やフラッシュメモリなどの半導体メモリ素子、ハードディスク、光ディスクなどであり、各種情報を記憶する。例えば、記憶部１３は、図２に示すように、アドレス情報記憶部１３ａおよび鍵情報記憶部１３ｂを有する。
【００２１】
アドレス情報記憶部１３ａは、ドメインネームとＩＰアドレスとアクセス制御の有無の情報とを対応付けて記憶する。例えば、図３に例示するように、アドレス情報記憶部１３ａは、ドメインネーム「abc.sample.co.jp」とＩＰアドレス「１９２．１６８．０１」とアクセス制御「有」を対応付けて記憶する。図３は、アドレス情報テーブルの一例を示す図である。ここで、アクセス制御「有」とは、アクセス制御として、公開鍵またはグループ公開鍵を用いた認証処理を行い、グループ署名または署名の正当性が有効である場合に、ドメインネームに対応するＩＰアドレスをユーザ端末２０に送信することを意味している。また、アクセス制御「無」とは、認証処理を行うことなく、ドメインネームに対応するＩＰアドレスをユーザ端末２０に送信することを意味している。
【００２２】
例えば、図３の例を用いて説明すると、ＤＮＳサーバ１０は、ドメインネーム「abc.sample.co.jp」に対応するＩＰアドレスを要求するクエリ要求をユーザ端末２０から受け付けた場合には、アクセス制御が「有」なので、アクセス制御として、公開鍵またはグループ公開鍵を用いた認証処理を行う。そして、ＤＮＳサーバ１０は、グループ署名または署名の正当性が有効である場合に、ドメインネーム「abc.sample.co.jp」に対応するＩＰアドレス「１９２．１６８．０１」をユーザ端末２０に返信する。
【００２３】
鍵情報記憶部１３ｂは、ドメインネームとグループ公開鍵とを対応付けて記憶する。例えば、図４に例示するように、鍵情報記憶部１３ｂは、ドメインネーム「abc.sample.co.jp」とグループ公開鍵「０ｘ３４ｄ２ａ３６ｂ」とを対応付けて記憶する。図４は、鍵情報テーブルの一例を示す図である。つまり、後にアクセス制御部１２４の処理の説明で詳述するが、ドメインネーム「abc.sample.co.jp」に対応するＩＰアドレスの検索を要求する旨のクエリ要求があった場合に、グループ公開鍵「０ｘ３４ｄ２ａ３６ｂ」を用いてグループ署名の正当性の可否を検証する処理が実施されることを意味する。
【００２４】
制御部１２は、ＤＮＳサーバ１０において実行される各種処理を制御する。具体的には、制御部１２は、図２に示すように、ＤＮＳ基本機能部１２ａ、グループ署名機能部１２ｂを有する。ＤＮＳ基本機能部１２ａは、ＤＮＳの基本的な処理を行う。グループ署名機能部１２ｂは、グループ署名の正当性の可否を検証する処理を行う。また、ＤＮＳ基本機能部１２ａは、登録部１２１、検索要求受付部１２２、検索応答部１２３を有する。グループ署名機能部１２ｂは、アクセス制御部１２４を有する。以下に各部について説明する。
【００２５】
登録部１２１は、ドメインネームとグループ公開鍵とを対応付けて登録する旨の登録要求を受け付けた場合に、所定のドメインネームとグループ公開鍵とを対応付けて鍵情報記憶部１３ｂに登録する。具体的には、登録部１２１は、管理端末３０からグループ署名に用いるグループ公開鍵を登録する旨の要求を受信すると、鍵情報記憶部１３ｂに登録要求のあったグループ公開鍵を登録する。そして、登録部１２１は、登録した旨の応答を管理端末３０に送信する。
【００２６】
検索要求受付部１２２は、ドメインネームに対応するＩＰアドレスの検索を要求する旨のクエリ要求を受け付ける。検索要求受付部１２２が受け付けるクエリ要求には、アクセス制御に関する情報とドメインネームに関する情報であるメッセージが含まれている。
【００２７】
ここで、図５を用いて、グループ署名について説明する。図５は、グループ署名について説明する図である。図５に示すように、ユーザ端末２０側では、署名鍵（ｉ）、メンバ証明書（ｉ）、メッセージ、グループ公開鍵を保持している。そして、ユーザ端末２０は、署名鍵、メンバ証明書、メッセージ、グループ公開鍵を用いて、グループ署名を生成し、ＤＮＳサーバ１０に対してメッセージおよびアクセス制御に関する情報を送信する。
【００２８】
ここで、ユーザ端末２０が送信するメッセージおよびアクセス制御に関する情報のデータ構造について図６を用いて説明する。図６は、リソースレコードの構造の一例を示す図である。ユーザ端末２０は、メッセージおよびアクセス制御に関する情報を含むクエリ要求として、図６に例示するようなＳＩＧ（０）リソースレコード構造のデータをＤＮＳサーバ１０に対して送信する。図６に示すように、ＳＩＧ（０）リソースレコードは、ドメインネームに関する情報である「メッセージ」と、「アクセス制御に関する情報」とで構成される。
【００２９】
ＳＩＧ（０）リソースレコードのメッセージには、「ＮＡＭＥ」、「ＴＹＰＥ」、「ＣＬＡＳＳ」、「ＴＴＬ」、「ＲＤＬＥＮＧＴＨ」が含まれる。ＮＡＭＥは、データ長が可変長であって、ドメインネームを示すデータである。ＴＹＰＥは、データ長が１６ビットであって、リソースレコードに保存されるリソースのタイプを示すデータである。ＣＬＡＳＳは、データ長が１６ビットであって、リソースレコードのクラスを示すデータである。ＴＴＬは、データ長が１６ビットであって、レコードの有効期限を示すデータである。ＲＤＬＥＮＧＴＨは、データ長が１６ビットであって、データサイズに関する情報を示すデータである。
【００３０】
また、ＳＩＧ（０）リソースレコードのアクセス制御に関する情報には、「Ｔｙｐｅ Ｃｏｖｅｒｅｄ」、「Ａｌｇｏｒｉｔｈｍ Ｎｕｍｂｅｒ」、「Ｌａｂｅｌｓ」、「Ｏｒｉｇｉｎａｌ ＴＴＬ」、「Ｓｉｇｎａｔｕｒｅ Ｅｘｐｉｒａｎａｔｉｏｎ」、「Ｓｉｇｎａｔｕｒｅ Ｉｎｃｅｐｔｉｏｎ」、「Ｋｅｙ Ｔａｇ」、「Ｓｉｇｎｅｒ’ｓ Ｎａｍｅ」、「Ｓｉｇｎａｔｕｒｅ」が含まれる。
【００３１】
Ｔｙｐｅ Ｃｏｖｅｒｅｄは、データ長が１６ビットであって、署名対象となるリソースレコードのタイプを示すデータである。Ａｌｇｏｒｉｔｈｍ Ｎｕｍｂｅｒは、データ長が８ビットであって、グループ署名の利用の有無を示すデータである。Ｌａｂｅｌｓは、データ長が８ビットであって、ゾーンの深度であるラベル数を示すデータであり、ＳＩＧ（０）リソースレコードでは「０」の値が設定されている。Ｏｒｉｇｉｎａｌ ＴＴＬは、データ長が３２ビットであって、レコードの有効期限を示すデータであり、ＳＩＧ（０）リソースレコードでは「０」の値が設定されている。
【００３２】
Ｓｉｇｎａｔｕｒｅ Ｅｘｐｉｒａｎａｔｉｏｎは、データ長が３２ビットであって、署名の有効期限を示すデータである。Ｓｉｇｎａｔｕｒｅ Ｉｎｃｅｐｔｉｏｎは、データ長が３２ビットであって、署名時刻を示すデータである。Ｋｅｙ Ｔａｇは、データ長が８ビットであって、鍵のＩＤを示すデータである。Ｓｉｇｎｅｒ’ｓ Ｎａｍｅは、データ長が可変長であって、署名をしたユーザ端末２０の名称を示すデータである。Ｓｉｇｎａｔｕｒｅは、データ長が可変長であって、グループ署名を示すデータである。
【００３３】
図５の説明に戻って、例えば、ユーザ端末２０は、署名鍵、メンバ証明書、メッセージ、グループ公開鍵から署名を生成すると、ＳＩＧ（０）リソースレコードの「Ａｌｇｏｒｉｔｈｍ Ｎｕｍｂｅｒ」にグループ署名の利用を示す値を設定し、「Ｓｉｇｎａｔｕｒｅ」フィールドに生成した署名データを設定する。そして、ユーザ端末２０は、メッセージおよびアクセス制御に関する情報を含むクエリ要求をＤＮＳサーバ１０に送信する。
【００３４】
そして、ＤＮＳサーバ１０の検索要求受付部１２２は、ユーザ端末２０からクエリ要求を受け付けると、ドメインネームに対するＩＰアドレスおよびＳＩＧ（０）を用いたアクセス制御の有無の情報をアドレス情報記憶部１３ａから取得する。続いて、検索要求受付部１２２は、取得結果がＳＩＧ（０）を用いたアクセス制御有りであるか判定する。この結果、検索要求受付部１２２は、取得結果がＳＩＧ（０）を用いたアクセス制御無しであると判定した場合には、ＩＰアドレスとともに、該ＩＰアドレスを含む応答メッセージを生成する旨の指示を検索応答部１２３に通知する。
【００３５】
また、検索要求受付部１２２は、取得結果がＳＩＧ（０）を用いたアクセス制御有りであると判定した場合には、クエリ要求にＳＩＧ（０）リソースレコードが含まれているか判定する。この結果、検索要求受付部１２２は、ＳＩＧ（０）リソースレコードが含まれていると判定した場合には、ＳＩＧ（０）リソースレコードのＡｌｇｏｒｉｔｈｍ Ｎｕｍｂｅｒフィールドの値をチェックし、グループ署名が利用されているか判定する。
【００３６】
この結果、検索要求受付部１２２は、グループ署名が利用されていると判定した場合には、グループ署名機能部１２ｂのアクセス制御部１２４に対してメッセージおよびアクセス制御に関する情報を送信する。
【００３７】
また、検索要求受付部１２２は、クエリ要求にＳＩＧ（０）リソースレコードが含まれているが、グループ署名が利用されていないと判定した場合には、従前の方法と同様に、公開鍵を用いて署名データの検証を実施し、検証結果を検索応答部１２３に送信する。また、検索要求受付部１２２は、クエリ要求にＳＩＧ（０）リソースレコードが含まれていない場合には、検証処理を行わずに、エラーメッセージを生成する旨の指示を検索応答部１２３に通知する。
【００３８】
検索応答部１２３は、グループ署名が正当であると検証された場合には、アドレス情報記憶部１３ａから検索されたドメインネームに対応するＩＰアドレスを検索要求の要求元に送信する。具体的には、検索応答部１２３は、検索要求受付部１２２またはアクセス制御部１２４から検証結果を受信すると、検証結果によりグループ署名または署名の正当性が有効であるか判定する。
【００３９】
この結果、検索応答部１２３は、グループ署名または署名の正当性が有効である場合には、検索要求受付部１２２から受信したＩＰアドレスを含む応答メッセージを生成し、応答メッセージをユーザ端末２０に送信する。また、検索応答部１２３は、グループ署名または署名の正当性が有効でない場合には、エラーメッセージを生成し、エラーメッセージをユーザ端末２０に送信する。また、検索応答部１２３は、ＩＰアドレスを含む応答メッセージを生成する旨の指示を検索要求受付部１２２から受信すると、検索要求受付部１２２から受信したＩＰアドレスを含む応答メッセージを生成し、応答メッセージをユーザ端末２０に送信する。また、検索応答部１２３は、エラーメッセージを生成する旨の指示を検索要求受付部１２２から受信すると、エラーメッセージを生成し、エラーメッセージをユーザ端末２０に送信する。
【００４０】
アクセス制御部１２４は、グループ公開鍵を用いて、ユーザ端末２０のアクセス制御を行う。具体的には、アクセス制御部１２４は、検索要求受付部１２２からメッセージおよびアクセス制御に関する情報を受け付けると、メッセージに含まれるドメインネーム（図６に例示する「ＮＡＭＥ」）を抽出し、ドメインネームに対応するグループ公開鍵を鍵情報記憶部１３ｂから取得する。そして、アクセス制御部１２４は、取得したグループ公開鍵を用いて、グループ署名の検証を実施し、グループ署名の正当性が有効であるか否かを示す検証結果を検索応答部１２３に通知する。
【００４１】
このように、ＤＮＳサーバ１０は、グループ公開鍵を用いてグループ署名の検証を実施することで、ＤＮＳにおけるセキュリティを向上させるとともに、ＤＮＳサーバ１０側で管理する公開鍵の登録データ量を削減し、公開鍵を管理する処理負荷を減らすことができる。
【００４２】
［ＤＮＳサーバ装置による処理］
次に、図７および図８を用いて、実施例１に係るＤＮＳサーバ１０による処理を説明する。図７は、実施例１に係るＤＮＳサーバによる登録処理の流れを示すシーケンス図である。図８は、実施例１に係るＤＮＳサーバによるアクセス制御処理の流れを示すシーケンス図である。
【００４３】
まず、図７を用いて、ＤＮＳサーバによる登録処理の流れを説明する。図７に示すように、ＤＮＳサーバ１０のＤＮＳ基本機能部１２ａは、管理端末３０からグループ署名の検証に用いるグループ公開鍵を登録する旨の登録要求を受信する（ステップＳ１０１）。例えば、ＤＮＳ基本機能部１２ａは、登録要求として、グループ公開鍵およびドメインネームの組を受信する。
【００４４】
そして、ＤＮＳ基本機能部１２ａは、登録要求のあったグループ公開鍵とドメインネームとを対応付けて、鍵情報記憶部１３ｂに登録し、続いて登録要求のあったドメインネームとアクセス制御有の情報とを対応付けてアドレス情報記録部１３ａに登録する（ステップＳ１０２）。なお、既にアドレス情報記録部１３ａにアクセス制御有の情報が登録されていた場合には登録情報の変更を実施しない。そして、登録部１２１は、登録した旨の応答を管理端末３０に送信する（ステップＳ１０３）。このように、ＤＮＳサーバ１０は、グループ公開鍵を鍵情報記憶部１３ｂに登録するので、ユーザ数分の公開鍵を登録する場合と比較して、管理する公開鍵の数を減らすことができ、公開鍵の管理負担を減らすことができる。
【００４５】
次に、図８を用いて、ＤＮＳサーバ１０によるアクセス制御処理の流れを説明する。図８に示すように、ＤＮＳサーバ１０のＤＮＳ基本機能部１２ａは、ドメインネームに対応するＩＰアドレスの検索を要求する旨のクエリ要求を受け付ける（ステップＳ２０１）。そして、ＤＮＳ基本機能部１２ａは、ドメインネームに対するＩＰアドレスおよびＳＩＧ（０）を用いたアクセス制御の有無の情報をアドレス情報記憶部１３ａから取得する（ステップＳ２０２）。
【００４６】
続いて、ＤＮＳ基本機能部１２ａは、取得結果がＳＩＧ（０）を用いたアクセス制御有りであるか判定する（ステップＳ２０３）。この結果、ＤＮＳ基本機能部１２ａは、取得結果がＳＩＧ（０）を用いたアクセス制御無しであると判定した場合には（ステップＳ２０３否定）、Ｓ２０２で取得したＩＰアドレスを含む応答メッセージを生成し（ステップＳ２１４）、応答メッセージをユーザ端末２０に送信する（ステップＳ２１５）。
【００４７】
また、ＤＮＳ基本機能部１２ａは、取得結果がＳＩＧ（０）を用いたアクセス制御有りであると判定した場合には（ステップＳ２０３肯定）、Ｓ２０１で受信したクエリ要求にＳＩＧ（０）リソースレコードが含まれているか判定する（ステップＳ２０４）。
【００４８】
この結果、ＤＮＳ基本機能部１２ａは、ＳＩＧ（０）リソースレコードが含まれていると判定した場合には（ステップＳ２０４肯定）、ＳＩＧ（０）リソースレコードのＡｌｇｏｒｉｔｈｍ Ｎｕｍｂｅｒフィールドの値をチェックし（ステップＳ２０５）、グループ署名が利用されているか判定する（ステップＳ２０６）。この結果、ＤＮＳ基本機能部１２ａは、グループ署名が利用されていると判定した場合には（ステップＳ２０６肯定）、グループ署名機能部１２ｂに対してメッセージおよびアクセス制御に関する情報を送信する（ステップＳ２０８）。
【００４９】
そして、グループ署名機能部１２ｂは、グループ公開鍵を用いて、グループ署名の検証を実施する（ステップＳ２０９）。具体的には、グループ署名機能部１２ｂは、ＤＮＳ基本機能部１２ａからメッセージおよびアクセス制御に関する情報を受け付けると、メッセージに含まれるドメインネーム（図６に例示する「ＮＡＭＥ」）を抽出し、ドメインネームに対応するグループ公開鍵を鍵情報記憶部１３ｂから取得する。そして、グループ署名機能部１２ｂは、取得したグループ公開鍵を用いて、グループ署名の検証を実施する。
【００５０】
そして、グループ署名機能部１２ｂは、検証を実施した後、グループ署名の正当性が有効であるか否かを示す検証結果をＤＮＳ基本機能部１２ａに通知する（ステップＳ２１０）。続いて、ＤＮＳ基本機能部１２ａは、検証結果を受信すると、検証結果によりグループ署名または署名の正当性が有効（図８では、「検証ＯＫ」と記載）であるか判定する（ステップＳ２１１）。
【００５１】
この結果、ＤＮＳ基本機能部１２ａは、グループ署名または署名の正当性が有効でない場合には（ステップＳ２１１否定）、エラーメッセージを生成し（ステップＳ２１２）、エラーメッセージをユーザ端末２０に送信する（ステップＳ２１３）。また、ＤＮＳ基本機能部１２ａは、グループ署名または署名の正当性が有効である場合には（ステップＳ２１１肯定）、Ｓ２０２で取得したＩＰアドレスを含む応答メッセージを生成し（ステップＳ２１４）、応答メッセージをユーザ端末２０に送信する（ステップＳ２１５）。
【００５２】
Ｓ２０４の説明に戻って、ＤＮＳ基本機能部１２ａは、ＳＩＧ（０）リソースレコードが含まれていないと判定した場合には（ステップＳ２０４否定）、エラーメッセージを生成し（ステップＳ２１４）、エラーメッセージをユーザ端末２０に送信する（ステップＳ２１５）。
【００５３】
また、Ｓ２０６の説明に戻って、ＤＮＳ基本機能部１２ａは、グループ署名が利用されていないと判定した場合には（ステップＳ２０６否定）、従前の方法と同様に、公開鍵を用いて署名データの検証を実施する（ステップＳ２０７）。そして、ＤＮＳ基本機能部１２ａは、検証結果を受信すると、検証結果によりグループ署名または署名の正当性が有効であるか判定する（ステップＳ２１１）。
【００５４】
この結果、ＤＮＳ基本機能部１２ａは、検索応答部１２３は、グループ署名または署名の正当性が有効でない場合には（ステップＳ２１１否定）、エラーメッセージを生成し（ステップＳ２１２）、エラーメッセージをユーザ端末２０に送信する（ステップＳ２１３）。また、ＤＮＳ基本機能部１２ａは、グループ署名または署名の正当性が有効である場合には（ステップＳ２１１肯定）、Ｓ２０２で取得したＩＰアドレスを含む応答メッセージを生成し（ステップＳ２１４）、応答メッセージをユーザ端末２０に送信する（ステップＳ２１５）。
【００５５】
[実施例１の効果]
上述してきたように、ＤＮＳサーバ１０は、所定のドメインネームとグループ公開鍵とを対応付けて登録する旨の登録要求を受け付けた場合に、所定のドメインネームとグループ公開鍵とを対応付けて鍵情報記憶部１３ｂに登録する。また、ＤＮＳサーバ１０は、所定のドメインネームに対応するＩＰアドレスを検索する旨の検索要求を受け付けた場合に、所定のドメインネームに対応するグループ公開鍵を鍵情報記憶部１３ｂから取得し、グループ公開鍵を用いて、検索要求に含まれるグループ署名の正当性を検証する。そして、ＤＮＳサーバ１０は、グループ署名が正当であると検証された場合には、ドメインネームに対応するＩＰアドレスを検索し、ＩＰアドレスを検索要求の要求元に送信する。このように、ＤＮＳサーバ１０は、グループ公開鍵を鍵情報記憶部１３ｂに登録するので、ユーザ数分の公開鍵を登録する場合と比較して、管理する公開鍵の数を減らすことができ、公開鍵の管理負担を減らすことができる。この結果、ＤＮＳサーバ１０は、公開鍵の登録データ量を削減し、公開鍵を管理する処理負荷を減らすことが可能である。
【００５６】
また、実施例１によれば、ＤＮＳサーバ１０は、検索要求を受け付けた場合に、該検索要求がグループ署名を利用するものであるか判定し、検索要求がグループ署名を利用するものである場合には、ドメインネームに対応するグループ公開鍵を鍵情報記憶部１３ｂから取得し、該グループ公開鍵を用いて、検索要求に含まれるグループ署名の正当性を検証する。このため、ＤＮＳサーバ１０は、Ａｌｇｏｒｉｔｈｍ Ｎｕｍｂｅｒをチェックするだけで容易にグループ署名を利用していると分かる結果、検索要求がグループ署名を利用するものであるか容易に判定することが可能である。
【００５７】
また、実施例１によれば、ＤＮＳサーバ１０は、検索要求がグループ署名を利用するものでないと判定された場合には、ドメインネームに対応するＩＰアドレスを検索し、該ＩＰアドレスを検索要求の要求元に送信する。このため、検索要求がグループ署名を利用しないものである場合には、検証処理を行うことなく検索処理を行うことができ、グループ署名を利用しない検索要求にも対応することが可能である。
【実施例２】
【００５８】
ところで、上記実施例１における名前管理システムは、上述した実施例以外にも、種々の異なる形態にて実施されてよい。そこで、実施例２では、上記の名前管理システムの他の実施例について説明する。
【００５９】
［システム構成］
また、本実施例において説明した各処理の内、自動的に行われるものとして説明した処理の全部又は一部を手動的に行うこともでき、あるいは、手動的に行われるものとして説明した処理の全部又は一部を公知の方法で自動的に行うこともできる。この他、上述文書中や図面中で示した処理手順、制御手順、具体的名称、各種のデータやパラメータを含む情報については、特記する場合を除いて任意に変更することができる。
【００６０】
また、図示した各装置の各構成要素は機能概念的なものであり、必ずしも物理的に図示の如く構成されていることを要しない。すなわち、各装置の分散・統合の具体的形態は図示のものに限られず、その全部又は一部を、各種の負荷や使用状況などに応じて、任意の単位で機能的又は物理的に分散・統合して構成することができる。
【００６１】
［プログラム］
図９は、開示の技術に係るアクセス制御プログラムによる情報処理がコンピュータを用いて具体的に実現されることを示す図である。図９に例示するように、コンピュータ３０００は、例えば、メモリ３０１０と、ＣＰＵ（Central Processing Unit）３０２０と、ハードディスクドライブインタフェース３０３０と、ディスクドライブインタフェース３０４０と、シリアルポートインタフェース３０５０と、ビデオアダプタ３０６０と、ネットワークインタフェース３０７０とを有する。コンピュータ３０００の各部はバス３１００によって接続される。
【００６２】
メモリ３０１０は、図９に例示するように、ＲＯＭ３０１１及びＲＡＭ３０１２を含む。ＲＯＭ３０１１は、例えば、ＢＩＯＳ（Basic Input Output System）等のブートプログラムを記憶する。ハードディスクドライブインタフェース３０３０は、図９に例示するように、ハードディスクドライブ３０８０に接続される。ディスクドライブインタフェース３０４０は、図９に例示するように、ディスクドライブ３０９０に接続される。例えば磁気ディスクや光ディスク等の着脱可能な記憶媒体が、ディスクドライブ３０９０に挿入される。シリアルポートインタフェース３０５０は、図９に例示するように、例えばマウス３０５１、キーボード３０５２に接続される。ビデオアダプタ３０６０は、図９に例示するように、例えばディスプレイ３０６１に接続される。
【００６３】
ここで、図９に例示するように、ハードディスクドライブ３０８０は、例えば、ＯＳ３０８１、アプリケーションプログラム３０８２、プログラムモジュール３０８３、プログラムデータ３０８４を記憶する。すなわち、開示の技術に係る更新プログラムは、コンピュータによって実行される指令が記述されたプログラムモジュール３０８３として、例えばハードディスクドライブ３０８０に記憶される。具体的には、上記実施例で説明した制御部１２の各部と同様の情報処理を実行する手順各々が記述されたプログラムモジュールが、ハードディスクドライブ３０８０に記憶される。
【００６４】
また、上記実施例で説明した記憶部１３に記憶されるデータのように、アクセス制御プログラムによる情報処理に用いられるデータは、プログラムデータ３０８４として、例えばハードディスクドライブ３０８０に記憶される。そして、ＣＰＵ３０２０が、ハードディスクドライブ３０８０に記憶されたプログラムモジュール３０８３やプログラムデータ３０８４を必要に応じてＲＡＭ３０１２に読み出し、各種の手順を実行する。
【００６５】
なお、アクセス制御プログラムに係るプログラムモジュール３０８３やプログラムデータ３０８４は、ハードディスクドライブ３０８０に記憶される場合に限られない。例えば、プログラムモジュール３０８３やプログラムデータ３０８４は、着脱可能な記憶媒体に記憶されても良い。この場合、ＣＰＵ３０２０は、ディスクドライブなどの着脱可能な記憶媒体を介してデータを読み出す。また、同様に、アクセス制御プログラムに係るプログラムモジュール３０８３やプログラムデータ３０８４は、ネットワーク（ＬＡＮ（Local Area Network）、ＷＡＮ（Wide Area Network）等）を介して接続された他のコンピュータに記憶されても良い。この場合、ＣＰＵ３０２０は、ネットワークインタフェースを介して他のコンピュータにアクセスすることで各種データを読み出す。
【００６６】
［その他］
なお、本実施例で説明したアクセス制御プログラムは、インターネットなどのネットワークを介して配布することができる。また、制御プログラムは、ハードディスク、フレキシブルディスク（ＦＤ）、ＣＤ−ＲＯＭ、ＭＯ、ＤＶＤなどのコンピュータで読み取り可能な記録媒体に記録され、コンピュータによって記録媒体から読み出されることによって実行することもできる。
【符号の説明】
【００６７】
１ 名前管理システム
１０ ＤＮＳサーバ
１１ 通信制御Ｉ／Ｆ
１２ 制御部
１２ａ ＤＮＳ基本機能部
１２ｂ グループ署名機能部
１２１ 登録部
１２２ 検索要求受付部
１２３ 検索応答部
１２４ アクセス制御部
１３ 記憶部
１３ａ アドレス情報記憶部
１３ｂ 鍵情報記憶部
２０ ユーザ端末
３０ 管理端末
４０ インターネット
３０００ コンピュータ
３０１０ メモリ
３０３０ ハードディスクドライブインタフェース
３０４０ ディスクドライブインタフェース
３０５０ シリアルポートインタフェース
３０５１ マウス
３０５２ キーボード
３０６０ ビデオアダプタ
３０６１ ディスプレイ
３０７０ ネットワークインタフェース
３０８０ ハードディスクドライブ
３０８２ アプリケーションプログラム
３０８３ プログラムモジュール
３０８４ プログラムデータ
３０９０ ディスクドライブ
３１００ バス
【技術分野】
【０００１】
本発明は、名前管理サーバおよびアクセス制御方法に関する。
【背景技術】
【０００２】
従来、インターネットの利用者に対して、ドメインネームとＩＰアドレス（Internet Protocol Address）とを対応付けて管理する名前管理システム（ＤＮＳ：Domain Name System）によるサービスが提供されている。このようなＤＮＳのソフトウェアであるＢＩＮＤ（Berkeley Internet Name Domain）では、ＩＰアドレス単位のアクセス制御を実現している。
【０００３】
ところが、ＢＩＮＤによるＩＰアドレス単位のアクセス制御では、発信元ＩＰアドレスを偽装するＩＰなりすましを防止できず、また、ＩＰアドレスを動的に割り当てるプロトコルであるＤＨＣＰ（Dynamic Host Configuration Protocol）に対応できない場合がある。このため、ＩＰなりすましを防止し、ＤＨＣＰに対応できる方式として、公開鍵署名を利用するＳＩＧ（０）を用いたアクセス制御方式が知られている。
【先行技術文献】
【特許文献】
【０００４】
【非特許文献１】“ＤＮＳにおけるアクセス制御プロトコルの検討”、［online］、［平成２３年４月１３日検索］、インターネット＜http://ci.nii.ac.jp/naid/110004028896＞
【発明の概要】
【発明が解決しようとする課題】
【０００５】
しかしながら、上記したＳＩＧ（０）を用いたアクセス制御方式では、ＤＮＳサーバ側の一つのドメインネームの登録データに対して、登録データにアクセスするユーザ数分だけ公開鍵を登録する。このため、アクセスするユーザ数が膨大な数である場合には、一つの登録データに対して大量の公開鍵を登録する必要がある。この結果、公開鍵の登録データ量が膨大な量となり、公開鍵を管理する処理負荷が大きいという課題があった。
【０００６】
そこで、この発明は、上述した従来技術の課題を解決するためになされたものであり、公開鍵を管理する処理負荷を軽減することを目的とする。
【課題を解決するための手段】
【０００７】
上述した課題を解決し、目的を達成するために、本発明に係る名前管理サーバは、所定の名前情報とグループ公開鍵とを対応付けて登録する旨の登録要求を受け付けた場合に、該所定の名前情報とグループ公開鍵とを対応付けて記憶部に保存する登録部と、グループ署名を含むとともに所定の名前情報に対応するアドレス情報を検索する旨の検索要求を検索要求受付部が受け付けた場合に、該所定の名前情報に対応するグループ公開鍵を前記記憶部から取得し、該グループ公開鍵を用いて、前記検索要求に含まれるグループ署名の正当性を検証するアクセス制御部と、前記アクセス制御部によって前記グループ署名が正当であると検証された場合には、前記記憶部から検索された前記名前情報に対応するアドレス情報を検索要求の要求元に送信する検索応答部とを有することを特徴とする。
【０００８】
また、本発明に係るアクセス制御方法は、名前管理サーバで実行されるアクセス制御方法であって、所定の名前情報とグループ公開鍵とを対応付けて登録する旨の登録要求を受け付けた場合に、該所定の名前情報とグループ公開鍵とを対応付けて記憶部に保存する登録工程と、グループ署名を含むとともに所定の名前情報に対応するアドレス情報を検索する旨の検索要求を受け付けた場合に、該所定の名前情報に対応するグループ公開鍵を前記記憶部から取得し、該グループ公開鍵を用いて、前記検索要求に含まれるグループ署名の正当性を検証するアクセス制御工程と、前記アクセス制御工程によって前記グループ署名が正当であると検証された場合には、前記記憶部から検索された前記名前情報に対応するアドレス情報を検索要求の要求元に送信する検索応答工程とを含んだことを特徴とする。
【発明の効果】
【０００９】
実施形態に係る名前管理サーバおよびアクセス制御方法によれば、公開鍵を管理する処理負荷を軽減することができるという効果を奏する。
【図面の簡単な説明】
【００１０】
【図１】図１は、実施例１に係る名前管理システムの構成を説明するための図である。
【図２】図２は、実施例１に係るＤＮＳサーバの構成を示すブロック図である。
【図３】図３は、アドレス情報テーブルの一例を示す図である。
【図４】図４は、鍵情報テーブルの一例を示す図である。
【図５】図５は、グループ署名について説明する図である。
【図６】図６は、リソースレコードの構造の一例を示す図である。
【図７】図７は、実施例１に係るＤＮＳサーバによる登録処理の流れを示すシーケンス図である。
【図８】図８は、実施例１に係るＤＮＳサーバによるアクセス制御処理の流れを示すシーケンス図である。
【図９】図９は、開示の技術に係るアクセス制御プログラムによる情報処理がコンピュータを用いて具体的に実現されることを示す図である。
【発明を実施するための形態】
【００１１】
以下に添付図面を参照して、この発明に係る名前管理サーバおよびアクセス制御方法の実施例を詳細に説明する。なお、この実施例によりこの発明が限定されるものではない。
【実施例１】
【００１２】
以下の実施例では、実施例１に係る名前管理システムの構成、ＤＮＳサーバ装置の構成および処理の流れを順に説明し、最後に実施例１による効果を説明する。
【００１３】
［名前管理システムの構成］
まず、実施例１における名前管理システムについて図１を用いて説明する。図１は、実施例１に係る名前管理システムの構成を説明するための図である。図１に示すように、実施例１における名前管理システム１は、ＤＮＳサーバ１０、ユーザ端末２０および管理端末３０を有する。ＤＮＳサーバ１０、ユーザ端末２０および管理端末３０は、インターネット４０を介して、それぞれ接続されている。なお、図１では、ＤＮＳサーバ１０、ユーザ端末２０、管理端末３０の各装置が一台ずつの例を示しているが、各装置が複数であってもよい。
【００１４】
ＤＮＳサーバ１０は、自身が管理する名前空間の範囲に対するドメインネームとＩＰアドレスとの対応関係を管理する。ＤＮＳサーバ１０は、ユーザ端末２０から所定のドメインネーム（例えば、「www.exaple.jp」）に対応するＩＰアドレスを要求するクエリ要求を受け付ける。そして、ＤＮＳサーバ１０は、クエリ要求を受け付けると、ドメインネームに対応するＩＰアドレスをユーザ端末２０に返信する。なお、ＤＮＳサーバ１０の詳しい構成については、後に図２を用いて詳述する。
【００１５】
ユーザ端末２０は、自装置がグループに所属しているか認証できるグループ署名に用いられる公開鍵（以下、グループ公開鍵という）と、グループのメンバであることを証明するメンバ証明書、グループ署名を暗号化する秘密鍵である署名鍵を保持している。
【００１６】
また、ユーザ端末２０は、ＩＰアドレスを要求するクエリ要求をＤＮＳサーバ１０に送信する際には、グループ公開鍵、メンバ証明書、署名鍵を用いて、グループ署名を生成する。そして、ユーザ端末２０は、アクセス制御に関する情報およびメッセージを含むクエリ要求をＤＮＳサーバ１０に送信する。
【００１７】
管理端末３０は、ＤＮＳサーバ１０に対してグループ公開鍵の登録を要求する。例えば、管理端末３０は、ユーザ端末２０が利用するグループ公開鍵を受信し、受信したグループ公開鍵とユーザ端末２０がアクセスする端末／サーバのドメインネームとを対応付けて記憶する旨の要求をＤＮＳサーバ１０に送信する。
【００１８】
［ＤＮＳサーバの構成］
次に、図２を用いて、図１に示したＤＮＳサーバ１０の構成を説明する。図２は、実施例１に係るＤＮＳサーバの構成を示すブロック図である。図２に示すように、このＤＮＳサーバ１０は、通信制御Ｉ／Ｆ１１、制御部１２、記憶部１３を有し、インターネット４０を介してユーザ端末２０および管理端末３０と接続される。以下にこれらの各部の処理を説明する。
【００１９】
通信制御Ｉ／Ｆ１１は、インターネット４０と接続されるユーザ端末２０および管理端末３０との間でやり取りする各種情報に関する通信を制御する。具体的には、通信制御Ｉ／Ｆ１１は、ドメインネームに関する情報およびグループ公開鍵に関する情報を含む登録要求を管理端末３０から受信し、登録した旨の応答である登録応答を管理端末３０に送信する。また、通信制御Ｉ／Ｆ１１は、ドメインネームに対応するＩＰアドレスを要求するクエリ要求を受信し、要求の応答としてＩＰアドレスまたはエラーメッセージをユーザ端末２０に送信する。
【００２０】
記憶部１３は、例えばＲＡＭ（Random Access Memory）やフラッシュメモリなどの半導体メモリ素子、ハードディスク、光ディスクなどであり、各種情報を記憶する。例えば、記憶部１３は、図２に示すように、アドレス情報記憶部１３ａおよび鍵情報記憶部１３ｂを有する。
【００２１】
アドレス情報記憶部１３ａは、ドメインネームとＩＰアドレスとアクセス制御の有無の情報とを対応付けて記憶する。例えば、図３に例示するように、アドレス情報記憶部１３ａは、ドメインネーム「abc.sample.co.jp」とＩＰアドレス「１９２．１６８．０１」とアクセス制御「有」を対応付けて記憶する。図３は、アドレス情報テーブルの一例を示す図である。ここで、アクセス制御「有」とは、アクセス制御として、公開鍵またはグループ公開鍵を用いた認証処理を行い、グループ署名または署名の正当性が有効である場合に、ドメインネームに対応するＩＰアドレスをユーザ端末２０に送信することを意味している。また、アクセス制御「無」とは、認証処理を行うことなく、ドメインネームに対応するＩＰアドレスをユーザ端末２０に送信することを意味している。
【００２２】
例えば、図３の例を用いて説明すると、ＤＮＳサーバ１０は、ドメインネーム「abc.sample.co.jp」に対応するＩＰアドレスを要求するクエリ要求をユーザ端末２０から受け付けた場合には、アクセス制御が「有」なので、アクセス制御として、公開鍵またはグループ公開鍵を用いた認証処理を行う。そして、ＤＮＳサーバ１０は、グループ署名または署名の正当性が有効である場合に、ドメインネーム「abc.sample.co.jp」に対応するＩＰアドレス「１９２．１６８．０１」をユーザ端末２０に返信する。
【００２３】
鍵情報記憶部１３ｂは、ドメインネームとグループ公開鍵とを対応付けて記憶する。例えば、図４に例示するように、鍵情報記憶部１３ｂは、ドメインネーム「abc.sample.co.jp」とグループ公開鍵「０ｘ３４ｄ２ａ３６ｂ」とを対応付けて記憶する。図４は、鍵情報テーブルの一例を示す図である。つまり、後にアクセス制御部１２４の処理の説明で詳述するが、ドメインネーム「abc.sample.co.jp」に対応するＩＰアドレスの検索を要求する旨のクエリ要求があった場合に、グループ公開鍵「０ｘ３４ｄ２ａ３６ｂ」を用いてグループ署名の正当性の可否を検証する処理が実施されることを意味する。
【００２４】
制御部１２は、ＤＮＳサーバ１０において実行される各種処理を制御する。具体的には、制御部１２は、図２に示すように、ＤＮＳ基本機能部１２ａ、グループ署名機能部１２ｂを有する。ＤＮＳ基本機能部１２ａは、ＤＮＳの基本的な処理を行う。グループ署名機能部１２ｂは、グループ署名の正当性の可否を検証する処理を行う。また、ＤＮＳ基本機能部１２ａは、登録部１２１、検索要求受付部１２２、検索応答部１２３を有する。グループ署名機能部１２ｂは、アクセス制御部１２４を有する。以下に各部について説明する。
【００２５】
登録部１２１は、ドメインネームとグループ公開鍵とを対応付けて登録する旨の登録要求を受け付けた場合に、所定のドメインネームとグループ公開鍵とを対応付けて鍵情報記憶部１３ｂに登録する。具体的には、登録部１２１は、管理端末３０からグループ署名に用いるグループ公開鍵を登録する旨の要求を受信すると、鍵情報記憶部１３ｂに登録要求のあったグループ公開鍵を登録する。そして、登録部１２１は、登録した旨の応答を管理端末３０に送信する。
【００２６】
検索要求受付部１２２は、ドメインネームに対応するＩＰアドレスの検索を要求する旨のクエリ要求を受け付ける。検索要求受付部１２２が受け付けるクエリ要求には、アクセス制御に関する情報とドメインネームに関する情報であるメッセージが含まれている。
【００２７】
ここで、図５を用いて、グループ署名について説明する。図５は、グループ署名について説明する図である。図５に示すように、ユーザ端末２０側では、署名鍵（ｉ）、メンバ証明書（ｉ）、メッセージ、グループ公開鍵を保持している。そして、ユーザ端末２０は、署名鍵、メンバ証明書、メッセージ、グループ公開鍵を用いて、グループ署名を生成し、ＤＮＳサーバ１０に対してメッセージおよびアクセス制御に関する情報を送信する。
【００２８】
ここで、ユーザ端末２０が送信するメッセージおよびアクセス制御に関する情報のデータ構造について図６を用いて説明する。図６は、リソースレコードの構造の一例を示す図である。ユーザ端末２０は、メッセージおよびアクセス制御に関する情報を含むクエリ要求として、図６に例示するようなＳＩＧ（０）リソースレコード構造のデータをＤＮＳサーバ１０に対して送信する。図６に示すように、ＳＩＧ（０）リソースレコードは、ドメインネームに関する情報である「メッセージ」と、「アクセス制御に関する情報」とで構成される。
【００２９】
ＳＩＧ（０）リソースレコードのメッセージには、「ＮＡＭＥ」、「ＴＹＰＥ」、「ＣＬＡＳＳ」、「ＴＴＬ」、「ＲＤＬＥＮＧＴＨ」が含まれる。ＮＡＭＥは、データ長が可変長であって、ドメインネームを示すデータである。ＴＹＰＥは、データ長が１６ビットであって、リソースレコードに保存されるリソースのタイプを示すデータである。ＣＬＡＳＳは、データ長が１６ビットであって、リソースレコードのクラスを示すデータである。ＴＴＬは、データ長が１６ビットであって、レコードの有効期限を示すデータである。ＲＤＬＥＮＧＴＨは、データ長が１６ビットであって、データサイズに関する情報を示すデータである。
【００３０】
また、ＳＩＧ（０）リソースレコードのアクセス制御に関する情報には、「Ｔｙｐｅ Ｃｏｖｅｒｅｄ」、「Ａｌｇｏｒｉｔｈｍ Ｎｕｍｂｅｒ」、「Ｌａｂｅｌｓ」、「Ｏｒｉｇｉｎａｌ ＴＴＬ」、「Ｓｉｇｎａｔｕｒｅ Ｅｘｐｉｒａｎａｔｉｏｎ」、「Ｓｉｇｎａｔｕｒｅ Ｉｎｃｅｐｔｉｏｎ」、「Ｋｅｙ Ｔａｇ」、「Ｓｉｇｎｅｒ’ｓ Ｎａｍｅ」、「Ｓｉｇｎａｔｕｒｅ」が含まれる。
【００３１】
Ｔｙｐｅ Ｃｏｖｅｒｅｄは、データ長が１６ビットであって、署名対象となるリソースレコードのタイプを示すデータである。Ａｌｇｏｒｉｔｈｍ Ｎｕｍｂｅｒは、データ長が８ビットであって、グループ署名の利用の有無を示すデータである。Ｌａｂｅｌｓは、データ長が８ビットであって、ゾーンの深度であるラベル数を示すデータであり、ＳＩＧ（０）リソースレコードでは「０」の値が設定されている。Ｏｒｉｇｉｎａｌ ＴＴＬは、データ長が３２ビットであって、レコードの有効期限を示すデータであり、ＳＩＧ（０）リソースレコードでは「０」の値が設定されている。
【００３２】
Ｓｉｇｎａｔｕｒｅ Ｅｘｐｉｒａｎａｔｉｏｎは、データ長が３２ビットであって、署名の有効期限を示すデータである。Ｓｉｇｎａｔｕｒｅ Ｉｎｃｅｐｔｉｏｎは、データ長が３２ビットであって、署名時刻を示すデータである。Ｋｅｙ Ｔａｇは、データ長が８ビットであって、鍵のＩＤを示すデータである。Ｓｉｇｎｅｒ’ｓ Ｎａｍｅは、データ長が可変長であって、署名をしたユーザ端末２０の名称を示すデータである。Ｓｉｇｎａｔｕｒｅは、データ長が可変長であって、グループ署名を示すデータである。
【００３３】
図５の説明に戻って、例えば、ユーザ端末２０は、署名鍵、メンバ証明書、メッセージ、グループ公開鍵から署名を生成すると、ＳＩＧ（０）リソースレコードの「Ａｌｇｏｒｉｔｈｍ Ｎｕｍｂｅｒ」にグループ署名の利用を示す値を設定し、「Ｓｉｇｎａｔｕｒｅ」フィールドに生成した署名データを設定する。そして、ユーザ端末２０は、メッセージおよびアクセス制御に関する情報を含むクエリ要求をＤＮＳサーバ１０に送信する。
【００３４】
そして、ＤＮＳサーバ１０の検索要求受付部１２２は、ユーザ端末２０からクエリ要求を受け付けると、ドメインネームに対するＩＰアドレスおよびＳＩＧ（０）を用いたアクセス制御の有無の情報をアドレス情報記憶部１３ａから取得する。続いて、検索要求受付部１２２は、取得結果がＳＩＧ（０）を用いたアクセス制御有りであるか判定する。この結果、検索要求受付部１２２は、取得結果がＳＩＧ（０）を用いたアクセス制御無しであると判定した場合には、ＩＰアドレスとともに、該ＩＰアドレスを含む応答メッセージを生成する旨の指示を検索応答部１２３に通知する。
【００３５】
また、検索要求受付部１２２は、取得結果がＳＩＧ（０）を用いたアクセス制御有りであると判定した場合には、クエリ要求にＳＩＧ（０）リソースレコードが含まれているか判定する。この結果、検索要求受付部１２２は、ＳＩＧ（０）リソースレコードが含まれていると判定した場合には、ＳＩＧ（０）リソースレコードのＡｌｇｏｒｉｔｈｍ Ｎｕｍｂｅｒフィールドの値をチェックし、グループ署名が利用されているか判定する。
【００３６】
この結果、検索要求受付部１２２は、グループ署名が利用されていると判定した場合には、グループ署名機能部１２ｂのアクセス制御部１２４に対してメッセージおよびアクセス制御に関する情報を送信する。
【００３７】
また、検索要求受付部１２２は、クエリ要求にＳＩＧ（０）リソースレコードが含まれているが、グループ署名が利用されていないと判定した場合には、従前の方法と同様に、公開鍵を用いて署名データの検証を実施し、検証結果を検索応答部１２３に送信する。また、検索要求受付部１２２は、クエリ要求にＳＩＧ（０）リソースレコードが含まれていない場合には、検証処理を行わずに、エラーメッセージを生成する旨の指示を検索応答部１２３に通知する。
【００３８】
検索応答部１２３は、グループ署名が正当であると検証された場合には、アドレス情報記憶部１３ａから検索されたドメインネームに対応するＩＰアドレスを検索要求の要求元に送信する。具体的には、検索応答部１２３は、検索要求受付部１２２またはアクセス制御部１２４から検証結果を受信すると、検証結果によりグループ署名または署名の正当性が有効であるか判定する。
【００３９】
この結果、検索応答部１２３は、グループ署名または署名の正当性が有効である場合には、検索要求受付部１２２から受信したＩＰアドレスを含む応答メッセージを生成し、応答メッセージをユーザ端末２０に送信する。また、検索応答部１２３は、グループ署名または署名の正当性が有効でない場合には、エラーメッセージを生成し、エラーメッセージをユーザ端末２０に送信する。また、検索応答部１２３は、ＩＰアドレスを含む応答メッセージを生成する旨の指示を検索要求受付部１２２から受信すると、検索要求受付部１２２から受信したＩＰアドレスを含む応答メッセージを生成し、応答メッセージをユーザ端末２０に送信する。また、検索応答部１２３は、エラーメッセージを生成する旨の指示を検索要求受付部１２２から受信すると、エラーメッセージを生成し、エラーメッセージをユーザ端末２０に送信する。
【００４０】
アクセス制御部１２４は、グループ公開鍵を用いて、ユーザ端末２０のアクセス制御を行う。具体的には、アクセス制御部１２４は、検索要求受付部１２２からメッセージおよびアクセス制御に関する情報を受け付けると、メッセージに含まれるドメインネーム（図６に例示する「ＮＡＭＥ」）を抽出し、ドメインネームに対応するグループ公開鍵を鍵情報記憶部１３ｂから取得する。そして、アクセス制御部１２４は、取得したグループ公開鍵を用いて、グループ署名の検証を実施し、グループ署名の正当性が有効であるか否かを示す検証結果を検索応答部１２３に通知する。
【００４１】
このように、ＤＮＳサーバ１０は、グループ公開鍵を用いてグループ署名の検証を実施することで、ＤＮＳにおけるセキュリティを向上させるとともに、ＤＮＳサーバ１０側で管理する公開鍵の登録データ量を削減し、公開鍵を管理する処理負荷を減らすことができる。
【００４２】
［ＤＮＳサーバ装置による処理］
次に、図７および図８を用いて、実施例１に係るＤＮＳサーバ１０による処理を説明する。図７は、実施例１に係るＤＮＳサーバによる登録処理の流れを示すシーケンス図である。図８は、実施例１に係るＤＮＳサーバによるアクセス制御処理の流れを示すシーケンス図である。
【００４３】
まず、図７を用いて、ＤＮＳサーバによる登録処理の流れを説明する。図７に示すように、ＤＮＳサーバ１０のＤＮＳ基本機能部１２ａは、管理端末３０からグループ署名の検証に用いるグループ公開鍵を登録する旨の登録要求を受信する（ステップＳ１０１）。例えば、ＤＮＳ基本機能部１２ａは、登録要求として、グループ公開鍵およびドメインネームの組を受信する。
【００４４】
そして、ＤＮＳ基本機能部１２ａは、登録要求のあったグループ公開鍵とドメインネームとを対応付けて、鍵情報記憶部１３ｂに登録し、続いて登録要求のあったドメインネームとアクセス制御有の情報とを対応付けてアドレス情報記録部１３ａに登録する（ステップＳ１０２）。なお、既にアドレス情報記録部１３ａにアクセス制御有の情報が登録されていた場合には登録情報の変更を実施しない。そして、登録部１２１は、登録した旨の応答を管理端末３０に送信する（ステップＳ１０３）。このように、ＤＮＳサーバ１０は、グループ公開鍵を鍵情報記憶部１３ｂに登録するので、ユーザ数分の公開鍵を登録する場合と比較して、管理する公開鍵の数を減らすことができ、公開鍵の管理負担を減らすことができる。
【００４５】
次に、図８を用いて、ＤＮＳサーバ１０によるアクセス制御処理の流れを説明する。図８に示すように、ＤＮＳサーバ１０のＤＮＳ基本機能部１２ａは、ドメインネームに対応するＩＰアドレスの検索を要求する旨のクエリ要求を受け付ける（ステップＳ２０１）。そして、ＤＮＳ基本機能部１２ａは、ドメインネームに対するＩＰアドレスおよびＳＩＧ（０）を用いたアクセス制御の有無の情報をアドレス情報記憶部１３ａから取得する（ステップＳ２０２）。
【００４６】
続いて、ＤＮＳ基本機能部１２ａは、取得結果がＳＩＧ（０）を用いたアクセス制御有りであるか判定する（ステップＳ２０３）。この結果、ＤＮＳ基本機能部１２ａは、取得結果がＳＩＧ（０）を用いたアクセス制御無しであると判定した場合には（ステップＳ２０３否定）、Ｓ２０２で取得したＩＰアドレスを含む応答メッセージを生成し（ステップＳ２１４）、応答メッセージをユーザ端末２０に送信する（ステップＳ２１５）。
【００４７】
また、ＤＮＳ基本機能部１２ａは、取得結果がＳＩＧ（０）を用いたアクセス制御有りであると判定した場合には（ステップＳ２０３肯定）、Ｓ２０１で受信したクエリ要求にＳＩＧ（０）リソースレコードが含まれているか判定する（ステップＳ２０４）。
【００４８】
この結果、ＤＮＳ基本機能部１２ａは、ＳＩＧ（０）リソースレコードが含まれていると判定した場合には（ステップＳ２０４肯定）、ＳＩＧ（０）リソースレコードのＡｌｇｏｒｉｔｈｍ Ｎｕｍｂｅｒフィールドの値をチェックし（ステップＳ２０５）、グループ署名が利用されているか判定する（ステップＳ２０６）。この結果、ＤＮＳ基本機能部１２ａは、グループ署名が利用されていると判定した場合には（ステップＳ２０６肯定）、グループ署名機能部１２ｂに対してメッセージおよびアクセス制御に関する情報を送信する（ステップＳ２０８）。
【００４９】
そして、グループ署名機能部１２ｂは、グループ公開鍵を用いて、グループ署名の検証を実施する（ステップＳ２０９）。具体的には、グループ署名機能部１２ｂは、ＤＮＳ基本機能部１２ａからメッセージおよびアクセス制御に関する情報を受け付けると、メッセージに含まれるドメインネーム（図６に例示する「ＮＡＭＥ」）を抽出し、ドメインネームに対応するグループ公開鍵を鍵情報記憶部１３ｂから取得する。そして、グループ署名機能部１２ｂは、取得したグループ公開鍵を用いて、グループ署名の検証を実施する。
【００５０】
そして、グループ署名機能部１２ｂは、検証を実施した後、グループ署名の正当性が有効であるか否かを示す検証結果をＤＮＳ基本機能部１２ａに通知する（ステップＳ２１０）。続いて、ＤＮＳ基本機能部１２ａは、検証結果を受信すると、検証結果によりグループ署名または署名の正当性が有効（図８では、「検証ＯＫ」と記載）であるか判定する（ステップＳ２１１）。
【００５１】
この結果、ＤＮＳ基本機能部１２ａは、グループ署名または署名の正当性が有効でない場合には（ステップＳ２１１否定）、エラーメッセージを生成し（ステップＳ２１２）、エラーメッセージをユーザ端末２０に送信する（ステップＳ２１３）。また、ＤＮＳ基本機能部１２ａは、グループ署名または署名の正当性が有効である場合には（ステップＳ２１１肯定）、Ｓ２０２で取得したＩＰアドレスを含む応答メッセージを生成し（ステップＳ２１４）、応答メッセージをユーザ端末２０に送信する（ステップＳ２１５）。
【００５２】
Ｓ２０４の説明に戻って、ＤＮＳ基本機能部１２ａは、ＳＩＧ（０）リソースレコードが含まれていないと判定した場合には（ステップＳ２０４否定）、エラーメッセージを生成し（ステップＳ２１４）、エラーメッセージをユーザ端末２０に送信する（ステップＳ２１５）。
【００５３】
また、Ｓ２０６の説明に戻って、ＤＮＳ基本機能部１２ａは、グループ署名が利用されていないと判定した場合には（ステップＳ２０６否定）、従前の方法と同様に、公開鍵を用いて署名データの検証を実施する（ステップＳ２０７）。そして、ＤＮＳ基本機能部１２ａは、検証結果を受信すると、検証結果によりグループ署名または署名の正当性が有効であるか判定する（ステップＳ２１１）。
【００５４】
この結果、ＤＮＳ基本機能部１２ａは、検索応答部１２３は、グループ署名または署名の正当性が有効でない場合には（ステップＳ２１１否定）、エラーメッセージを生成し（ステップＳ２１２）、エラーメッセージをユーザ端末２０に送信する（ステップＳ２１３）。また、ＤＮＳ基本機能部１２ａは、グループ署名または署名の正当性が有効である場合には（ステップＳ２１１肯定）、Ｓ２０２で取得したＩＰアドレスを含む応答メッセージを生成し（ステップＳ２１４）、応答メッセージをユーザ端末２０に送信する（ステップＳ２１５）。
【００５５】
[実施例１の効果]
上述してきたように、ＤＮＳサーバ１０は、所定のドメインネームとグループ公開鍵とを対応付けて登録する旨の登録要求を受け付けた場合に、所定のドメインネームとグループ公開鍵とを対応付けて鍵情報記憶部１３ｂに登録する。また、ＤＮＳサーバ１０は、所定のドメインネームに対応するＩＰアドレスを検索する旨の検索要求を受け付けた場合に、所定のドメインネームに対応するグループ公開鍵を鍵情報記憶部１３ｂから取得し、グループ公開鍵を用いて、検索要求に含まれるグループ署名の正当性を検証する。そして、ＤＮＳサーバ１０は、グループ署名が正当であると検証された場合には、ドメインネームに対応するＩＰアドレスを検索し、ＩＰアドレスを検索要求の要求元に送信する。このように、ＤＮＳサーバ１０は、グループ公開鍵を鍵情報記憶部１３ｂに登録するので、ユーザ数分の公開鍵を登録する場合と比較して、管理する公開鍵の数を減らすことができ、公開鍵の管理負担を減らすことができる。この結果、ＤＮＳサーバ１０は、公開鍵の登録データ量を削減し、公開鍵を管理する処理負荷を減らすことが可能である。
【００５６】
また、実施例１によれば、ＤＮＳサーバ１０は、検索要求を受け付けた場合に、該検索要求がグループ署名を利用するものであるか判定し、検索要求がグループ署名を利用するものである場合には、ドメインネームに対応するグループ公開鍵を鍵情報記憶部１３ｂから取得し、該グループ公開鍵を用いて、検索要求に含まれるグループ署名の正当性を検証する。このため、ＤＮＳサーバ１０は、Ａｌｇｏｒｉｔｈｍ Ｎｕｍｂｅｒをチェックするだけで容易にグループ署名を利用していると分かる結果、検索要求がグループ署名を利用するものであるか容易に判定することが可能である。
【００５７】
また、実施例１によれば、ＤＮＳサーバ１０は、検索要求がグループ署名を利用するものでないと判定された場合には、ドメインネームに対応するＩＰアドレスを検索し、該ＩＰアドレスを検索要求の要求元に送信する。このため、検索要求がグループ署名を利用しないものである場合には、検証処理を行うことなく検索処理を行うことができ、グループ署名を利用しない検索要求にも対応することが可能である。
【実施例２】
【００５８】
ところで、上記実施例１における名前管理システムは、上述した実施例以外にも、種々の異なる形態にて実施されてよい。そこで、実施例２では、上記の名前管理システムの他の実施例について説明する。
【００５９】
［システム構成］
また、本実施例において説明した各処理の内、自動的に行われるものとして説明した処理の全部又は一部を手動的に行うこともでき、あるいは、手動的に行われるものとして説明した処理の全部又は一部を公知の方法で自動的に行うこともできる。この他、上述文書中や図面中で示した処理手順、制御手順、具体的名称、各種のデータやパラメータを含む情報については、特記する場合を除いて任意に変更することができる。
【００６０】
また、図示した各装置の各構成要素は機能概念的なものであり、必ずしも物理的に図示の如く構成されていることを要しない。すなわち、各装置の分散・統合の具体的形態は図示のものに限られず、その全部又は一部を、各種の負荷や使用状況などに応じて、任意の単位で機能的又は物理的に分散・統合して構成することができる。
【００６１】
［プログラム］
図９は、開示の技術に係るアクセス制御プログラムによる情報処理がコンピュータを用いて具体的に実現されることを示す図である。図９に例示するように、コンピュータ３０００は、例えば、メモリ３０１０と、ＣＰＵ（Central Processing Unit）３０２０と、ハードディスクドライブインタフェース３０３０と、ディスクドライブインタフェース３０４０と、シリアルポートインタフェース３０５０と、ビデオアダプタ３０６０と、ネットワークインタフェース３０７０とを有する。コンピュータ３０００の各部はバス３１００によって接続される。
【００６２】
メモリ３０１０は、図９に例示するように、ＲＯＭ３０１１及びＲＡＭ３０１２を含む。ＲＯＭ３０１１は、例えば、ＢＩＯＳ（Basic Input Output System）等のブートプログラムを記憶する。ハードディスクドライブインタフェース３０３０は、図９に例示するように、ハードディスクドライブ３０８０に接続される。ディスクドライブインタフェース３０４０は、図９に例示するように、ディスクドライブ３０９０に接続される。例えば磁気ディスクや光ディスク等の着脱可能な記憶媒体が、ディスクドライブ３０９０に挿入される。シリアルポートインタフェース３０５０は、図９に例示するように、例えばマウス３０５１、キーボード３０５２に接続される。ビデオアダプタ３０６０は、図９に例示するように、例えばディスプレイ３０６１に接続される。
【００６３】
ここで、図９に例示するように、ハードディスクドライブ３０８０は、例えば、ＯＳ３０８１、アプリケーションプログラム３０８２、プログラムモジュール３０８３、プログラムデータ３０８４を記憶する。すなわち、開示の技術に係る更新プログラムは、コンピュータによって実行される指令が記述されたプログラムモジュール３０８３として、例えばハードディスクドライブ３０８０に記憶される。具体的には、上記実施例で説明した制御部１２の各部と同様の情報処理を実行する手順各々が記述されたプログラムモジュールが、ハードディスクドライブ３０８０に記憶される。
【００６４】
また、上記実施例で説明した記憶部１３に記憶されるデータのように、アクセス制御プログラムによる情報処理に用いられるデータは、プログラムデータ３０８４として、例えばハードディスクドライブ３０８０に記憶される。そして、ＣＰＵ３０２０が、ハードディスクドライブ３０８０に記憶されたプログラムモジュール３０８３やプログラムデータ３０８４を必要に応じてＲＡＭ３０１２に読み出し、各種の手順を実行する。
【００６５】
なお、アクセス制御プログラムに係るプログラムモジュール３０８３やプログラムデータ３０８４は、ハードディスクドライブ３０８０に記憶される場合に限られない。例えば、プログラムモジュール３０８３やプログラムデータ３０８４は、着脱可能な記憶媒体に記憶されても良い。この場合、ＣＰＵ３０２０は、ディスクドライブなどの着脱可能な記憶媒体を介してデータを読み出す。また、同様に、アクセス制御プログラムに係るプログラムモジュール３０８３やプログラムデータ３０８４は、ネットワーク（ＬＡＮ（Local Area Network）、ＷＡＮ（Wide Area Network）等）を介して接続された他のコンピュータに記憶されても良い。この場合、ＣＰＵ３０２０は、ネットワークインタフェースを介して他のコンピュータにアクセスすることで各種データを読み出す。
【００６６】
［その他］
なお、本実施例で説明したアクセス制御プログラムは、インターネットなどのネットワークを介して配布することができる。また、制御プログラムは、ハードディスク、フレキシブルディスク（ＦＤ）、ＣＤ−ＲＯＭ、ＭＯ、ＤＶＤなどのコンピュータで読み取り可能な記録媒体に記録され、コンピュータによって記録媒体から読み出されることによって実行することもできる。
【符号の説明】
【００６７】
１ 名前管理システム
１０ ＤＮＳサーバ
１１ 通信制御Ｉ／Ｆ
１２ 制御部
１２ａ ＤＮＳ基本機能部
１２ｂ グループ署名機能部
１２１ 登録部
１２２ 検索要求受付部
１２３ 検索応答部
１２４ アクセス制御部
１３ 記憶部
１３ａ アドレス情報記憶部
１３ｂ 鍵情報記憶部
２０ ユーザ端末
３０ 管理端末
４０ インターネット
３０００ コンピュータ
３０１０ メモリ
３０３０ ハードディスクドライブインタフェース
３０４０ ディスクドライブインタフェース
３０５０ シリアルポートインタフェース
３０５１ マウス
３０５２ キーボード
３０６０ ビデオアダプタ
３０６１ ディスプレイ
３０７０ ネットワークインタフェース
３０８０ ハードディスクドライブ
３０８２ アプリケーションプログラム
３０８３ プログラムモジュール
３０８４ プログラムデータ
３０９０ ディスクドライブ
３１００ バス
【特許請求の範囲】
【請求項１】
所定の名前情報とグループ公開鍵とを対応付けて登録する旨の登録要求を受け付けた場合に、該所定の名前情報とグループ公開鍵とを対応付けて記憶部に保存する登録部と、
グループ署名を含むとともに所定の名前情報に対応するアドレス情報を検索する旨の検索要求を受け付けた場合に、該所定の名前情報に対応するグループ公開鍵を前記記憶部から取得し、該グループ公開鍵を用いて、前記検索要求に含まれるグループ署名の正当性を検証するアクセス制御部と、
前記アクセス制御部によって前記グループ署名が正当であると検証された場合には、前記記憶部から検索された前記名前情報に対応するアドレス情報を検索要求の要求元に送信する検索応答部と
を有することを特徴とする名前管理サーバ。
【請求項２】
前記アクセス制御部は、前記検索要求を受け付けた場合に、該検索要求に含まれるグループ署名を利用するか否かを示す情報に基づいて、該検索要求が前記グループ署名を利用するものであるか判定し、前記検索要求が前記グループ署名を利用するものである場合には、前記名前情報に対応するグループ公開鍵を前記記憶部から取得し、該グループ公開鍵を用いて、前記検索要求に含まれるグループ署名の正当性を検証することを特徴とする請求項１に記載の名前管理サーバ。
【請求項３】
前記検索応答部は、前記アクセス制御部によって前記検索要求がグループ署名を利用するものでないと判定された場合には、前記名前情報に対応するアドレス情報を検索し、検索されたアドレス情報を検索要求の要求元に送信することを特徴とする請求項２に記載の名前管理サーバ。
【請求項４】
名前管理サーバで実行されるアクセス制御方法であって、
所定の名前情報とグループ公開鍵とを対応付けて登録する旨の登録要求を受け付けた場合に、該所定の名前情報とグループ公開鍵とを対応付けて記憶部に保存する登録工程と、
グループ署名を含むとともに所定の名前情報に対応するアドレス情報を検索する旨の検索要求を受け付けた場合に、該所定の名前情報に対応するグループ公開鍵を前記記憶部から取得し、該グループ公開鍵を用いて、前記検索要求に含まれるグループ署名の正当性を検証するアクセス制御工程と、
前記アクセス制御工程によって前記グループ署名が正当であると検証された場合には、前記記憶部から検索された前記名前情報に対応するアドレス情報を検索要求の要求元に送信する検索応答工程と
を含んだことを特徴とするアクセス制御方法。
【請求項１】
所定の名前情報とグループ公開鍵とを対応付けて登録する旨の登録要求を受け付けた場合に、該所定の名前情報とグループ公開鍵とを対応付けて記憶部に保存する登録部と、
グループ署名を含むとともに所定の名前情報に対応するアドレス情報を検索する旨の検索要求を受け付けた場合に、該所定の名前情報に対応するグループ公開鍵を前記記憶部から取得し、該グループ公開鍵を用いて、前記検索要求に含まれるグループ署名の正当性を検証するアクセス制御部と、
前記アクセス制御部によって前記グループ署名が正当であると検証された場合には、前記記憶部から検索された前記名前情報に対応するアドレス情報を検索要求の要求元に送信する検索応答部と
を有することを特徴とする名前管理サーバ。
【請求項２】
前記アクセス制御部は、前記検索要求を受け付けた場合に、該検索要求に含まれるグループ署名を利用するか否かを示す情報に基づいて、該検索要求が前記グループ署名を利用するものであるか判定し、前記検索要求が前記グループ署名を利用するものである場合には、前記名前情報に対応するグループ公開鍵を前記記憶部から取得し、該グループ公開鍵を用いて、前記検索要求に含まれるグループ署名の正当性を検証することを特徴とする請求項１に記載の名前管理サーバ。
【請求項３】
前記検索応答部は、前記アクセス制御部によって前記検索要求がグループ署名を利用するものでないと判定された場合には、前記名前情報に対応するアドレス情報を検索し、検索されたアドレス情報を検索要求の要求元に送信することを特徴とする請求項２に記載の名前管理サーバ。
【請求項４】
名前管理サーバで実行されるアクセス制御方法であって、
所定の名前情報とグループ公開鍵とを対応付けて登録する旨の登録要求を受け付けた場合に、該所定の名前情報とグループ公開鍵とを対応付けて記憶部に保存する登録工程と、
グループ署名を含むとともに所定の名前情報に対応するアドレス情報を検索する旨の検索要求を受け付けた場合に、該所定の名前情報に対応するグループ公開鍵を前記記憶部から取得し、該グループ公開鍵を用いて、前記検索要求に含まれるグループ署名の正当性を検証するアクセス制御工程と、
前記アクセス制御工程によって前記グループ署名が正当であると検証された場合には、前記記憶部から検索された前記名前情報に対応するアドレス情報を検索要求の要求元に送信する検索応答工程と
を含んだことを特徴とするアクセス制御方法。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【公開番号】特開２０１２−２３８９３５（Ｐ２０１２−２３８９３５Ａ）
【公開日】平成２４年１２月６日（２０１２．１２．６）
【国際特許分類】
【出願番号】特願２０１１−１０４８８１（Ｐ２０１１−１０４８８１）
【出願日】平成２３年５月１０日（２０１１．５．１０）
【新規性喪失の例外の表示】特許法第３０条第１項適用申請有り 社団法人 電子情報通信学会 電子情報通信学会技術研究報告（ＶＯＬ．１１０ ＮＯ．２８９），発行日 平成２２年１１月１１日
【出願人】（０００００４２２６）日本電信電話株式会社 (13,992)
【Ｆターム（参考）】
【公開日】平成２４年１２月６日（２０１２．１２．６）
【国際特許分類】
【出願日】平成２３年５月１０日（２０１１．５．１０）
【新規性喪失の例外の表示】特許法第３０条第１項適用申請有り 社団法人 電子情報通信学会 電子情報通信学会技術研究報告（ＶＯＬ．１１０ ＮＯ．２８９），発行日 平成２２年１１月１１日
【出願人】（０００００４２２６）日本電信電話株式会社 (13,992)
【Ｆターム（参考）】
[ Back to top ]