JP2000349747A - 公開鍵管理方法 - Google Patents

公開鍵管理方法

Info

Publication number
JP2000349747A
JP2000349747A JP15532299A JP15532299A JP2000349747A JP 2000349747 A JP2000349747 A JP 2000349747A JP 15532299 A JP15532299 A JP 15532299A JP 15532299 A JP15532299 A JP 15532299A JP 2000349747 A JP2000349747 A JP 2000349747A
Authority
JP
Japan
Prior art keywords
public key
host
domain name
kms
dns
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
JP15532299A
Other languages
English (en)
Inventor
Atsushi Maeda
篤志 前田
Ken Watabe
謙 渡部
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Hitachi Ltd
Original Assignee
Hitachi Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Hitachi Ltd filed Critical Hitachi Ltd
Priority to JP15532299A priority Critical patent/JP2000349747A/ja
Priority to US09/585,358 priority patent/US6928167B1/en
Publication of JP2000349747A publication Critical patent/JP2000349747A/ja
Pending legal-status Critical Current

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/06—Network architectures or network communication protocols for network security for supporting key management in a packet data network
    • H04L63/062—Network architectures or network communication protocols for network security for supporting key management in a packet data network for key distribution, e.g. centrally by trusted party
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L61/00—Network arrangements, protocols or services for addressing or naming
    • H04L61/45—Network directories; Name-to-address mapping
    • H04L61/4505—Network directories; Name-to-address mapping using standardised directories; using standardised directory access protocols
    • H04L61/4511—Network directories; Name-to-address mapping using standardised directories; using standardised directory access protocols using domain name system [DNS]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/12—Applying verification of the received information
    • H04L63/126—Applying verification of the received information the source of the received data

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Hardware Design (AREA)
  • Computing Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)
  • Computer And Data Communications (AREA)
  • Small-Scale Networks (AREA)

Abstract

(57)【要約】 【課題】 セキュリティ通信を行おうとする２つのホス
トが通信開始前にお互いの公開鍵を自動的かつ安全に得
ることを可能にした公開鍵管理方法。 【解決手段】 階層構造のドメイン名の構成を持ち、そ
のドメイン名とアドレスとの対応を管理するＤＮＳサー
バが階層毎にあるネットワークにおいて、公開鍵を管理
するモジュールとネットワークに属するホストの公開鍵
とドメイン名との対応を示すデータベースを各ＤＮＳサ
ーバに設ける。２つのホストがセキュリティ通信を開始
するとき、一方のホストが前述の機能拡張したＤＮＳか
ら通信相手のホストの公開鍵を自動的に取得する。この
とき、公開鍵問い合わせパケットの中にホストが信用す
るＤＮＳサーバの名前を入れさせ、このホストが指定す
るＤＮＳサーバが、公開鍵応答パケットに電子署名を付
ける。ホストは、この電子署名により公開鍵応答パケッ
トにある公開鍵が信用できるかどうかを判定することが
でき、不正なホストが通信相手になりすますのを防止す
る。

Description

【発明の詳細な説明】
【０００１】
【発明の属する技術分野】本発明は、公開鍵の管理方法
に係り、特に、ネットワークにおけるセキュリティ技術
に使用される公開鍵暗号システムに使用して好適な公開
鍵の管理方法に関する。
【０００２】
【従来の技術】インターネットを使用してセキュリティ
通信を実現する方法として、例えば、ＩＰレイヤのセキ
ュリティプロトコルであるＩＰＳＥＣ(IP SECurity）が
知られており、ＩＰＳＥＣに関する技術文献として、例
えば、“［RFC1825］ SecurityArchitecture for the I
nternet Protocol. 著者：R.Atkinson 発行：IETF”等
が知られている。
【０００３】ＩＰＳＥＣに付随する鍵管理プロトコル
は、公開鍵暗号システムを利用するものであり、鍵管理
プロトコルに関する従来技術として、例えば“Simple K
ey-Management For Internet Protocol. 著者：Ashar A
ziz, Tom Markson, Hemma Prafullchandra 発行：IET
F”等に記載されたＳＫＩＰと呼ばれる技術が知られて
いる。以下、この鍵管理プロトコルについて説明する。
【０００４】いま、ネットワーク内にセキュリティ通信
を行う２つのホストＡ、Ｂがあり、これらのホストＡ、
Ｂは、ＩＰＳＥＣに基づいた共通鍵暗号システムによっ
て暗号通信を行うものとし、ホストＡは、ホストＢの公
開鍵を、ホストＢは、ホストＡの公開鍵を知っているも
のとする。
【０００５】ホストＡとＢとは、通信を行うに際して、
既知のアルゴリズムを用いて、それぞれ自らの秘密鍵と
相手の公開鍵とを組み合わせて共通鍵を暗号化するため
の鍵Ｋ(Ａ)、Ｋ(Ｂ)を生成する。ここで、例えば、ホス
トＡがホストＢにデータを送信するとき、ホストＡは、
共通鍵Ｔを生成し、それを用いてデータを暗号化し、鍵
Ｋ(Ａ)を用いて共通鍵Ｔを暗号化する。ホストＡは、暗
号化された共通鍵Ｔの情報を含む新たなヘッダをＩＰヘ
ッダの後に挿入する。受信側のホストＢは、自らが持つ
秘密鍵によって、パケットの中にある暗号化された共通
鍵Ｔを解読し、解読した共通鍵Ｔによって暗号化された
パケットのデータを解読する。そして、このようなホス
トＡ、Ｂ間のセキュリティ通信において、データを暗号
化するための共通鍵は、定期的に更新される。
【０００６】前述したようなＩＰＳＥＣに付随する従来
技術による鍵管理プロトコルは、セキュリティ通信を行
う２つのホストが通信開始前に互いに相手の公開鍵を知
っていることが前提とされている。
【０００７】
【発明が解決しようとする課題】前述した従来技術によ
る方法は、セキュリティ通信を行おうとする２つのホス
トが、通信開始前にお互いの公開鍵を自動的かつ安全に
交換する方法がなく、その結果、手渡しによる公開鍵の
交換等の方法に頼ることになり、公開鍵の管理が複雑に
なっているという問題点を有している。また、この結
果、前述の従来技術は、ネットワークの規模が大きい場
合、ネットワークの管理者に対する負担が大きくなると
いう問題点を生じさせている。
【０００８】さらに、前述の従来技術は、ネットワーク
上の認証を伴わない公開鍵の配布を行った場合、不正な
ホストがセキュリティ通信の相手になりすますことを防
ぐことができないという問題点をも有している。
【０００９】本発明の目的は、前述した従来技術の問題
点を解決し、セキュリティ通信を行おうとする２つのホ
ストが通信開始前にお互いの公開鍵を自動的かつ安全に
交換することを可能にした公開鍵の管理方法を提供する
ことにある。
【００１０】
【課題を解決するための手段】本発明によれば前記目的
は、階層構造を持ち、各階層毎にドメイン名を持つネッ
トワークと、そのドメイン名とアドレスとの対応を管理
する前記各階層毎に設けられるＤＮＳサーバと、ネット
ワークに収容されるホストとを備え、前記ＤＮＳサーバ
が、ネットワークに属するホストに対して他のホストが
持つ公開鍵を配布する公開鍵管理方法において、前記Ｄ
ＮＳサーバが、公開鍵を管理する手段と、前記ネットワ
ークに属するホストの公開鍵とドメイン名とを対応付け
て格納したデータベースとを持ち、第１のホストからの
ドメイン名の情報による第２のホストの公開鍵の問い合
わせを受けたとき、前記公開鍵管理手段が前記データベ
ースを参照することにより、前記ドメイン名に対応する
第２のホストの公開鍵の情報を前記第１のホストに応答
することにより達成される。
【００１１】また、前記目的は、前記ＤＮＳサーバが、
第１のホストから第２のホストの公開鍵の問い合わせを
受けたとき、自サーバ内の前記データベースの中に問い
合わせのドメイン名に対応するエントリがない場合、他
の公開鍵管理手段とデータベースとを備えた他のＤＮＳ
サーバに公開鍵の解決をドメイン名の階層に沿って再帰
的に委託することにより達成される。
【００１２】さらに、前記目的は、前記ホストが、前記
ＤＮＳサーバに他のホストの公開鍵を問い合わせる手段
を備え、セキュリティ通信開始時、前記公開鍵問い合わ
せ手段に通信相手となるホストのドメイン名に対応する
公開鍵を前記ＤＮＳサーバに問い合わせることにより達
成される。
【００１３】本発明の目的は、前述の手段を持つ構成以
外に、さらに、次に示すような手段を備えることによっ
ても達成することができる。
【００１４】すなわち、前記目的は、ネットワークの構
成に変更が生じた場合、構成の変化に関係する一部のＤ
ＮＳサーバが、ホストの公開鍵とドメイン名のと対応を
格納しているデータベースを更新し、前記以外のＤＮＳ
サーバがデータベースの更新を行わないようにすること
により達成される。
【００１５】また、前記目的は、前記公開鍵管理手段と
データベースとを備えたＤＮＳサーバと、前記公開鍵を
問い合わせる手段を備えたホストとに電子署名を処理す
る手段を設け、公開鍵問い合わせ及び応答のために出力
するパケットに電子署名を付け、電子署名の付いた入力
パケットについて、その電子署名を確認し、改竄されて
いる入力パケットを廃棄することにより、パケットの内
容が改竄されるのを防止するようにすることにより達成
される。
【００１６】また、前記目的は、公開鍵問い合わせ及び
応答のために上記公開鍵管理手段とデータベースとを備
えたＤＮＳサーバと、前記公開鍵を問い合わせる手段を
備えたホストとが、入出力するパケットとして、従来の
ＤＮＳパケットと同じフォーマットのパケットを用いる
ことにより達成される。
【００１７】また、前記目的は、前記ＤＮＳサーバに対
してホストが送信する公開鍵問い合わせパケットの中に
ホストが信用するＤＮＳサーバのドメイン名の情報を含
め、公開鍵の情報を応答する前に、前記ＤＮＳサーバの
公開鍵管理手段に、公開鍵問い合わせパケットの中で示
されるホストが信用するＤＮＳサーバに対して電子署名
を要求させ、電子署名の要求を受けたＤＮＳサーバの公
開鍵管理手段に、公開鍵応答パケットに電子署名を付け
させ、その電子署名により公開鍵応答パケットに含まれ
る公開鍵の情報が信用できるか否かを前記ホストの電子
署名を処理する手段に判定させ、これにより、不正なホ
ストが自分の公開鍵とアドレスとを公開鍵問い合わせパ
ケットの中にある問い合わせドメイン名に対応している
ように見せかけることを防止するようにしたことにより
達成される。
【００１８】また、前記目的は、電子署名の要求を受け
たＤＮＳサーバが公開鍵問い合わせパケットの中で示さ
れるホストが信用するＤＮＳサーバと異なるとき該ＤＮ
Ｓサーバの公開鍵管理手段は、ドメイン名の階層構造に
沿って、上位のＤＮＳサーバに公開鍵応答パケットに対
する電子署名を要求し、最終的には公開鍵問い合わせパ
ケットの中で示されるホストが信用するＤＮＳサーバに
公開鍵応答パケットに電子署名を付けさせることにより
達成される。
【００１９】また、前記目的は、前記ホストの公開鍵問
い合わせ手段に、問い合わせるドメイン名に従って信用
するＤＮＳサーバを選択させ、公開鍵問い合わせパケッ
トの中に該ＤＮＳサーバのドメイン名の情報を含め、公
開鍵応答パケットに電子署名を付ける処理を行うＤＮＳ
サーバの数を減らすことにより公開鍵の取得を効率的な
ものとすることにより達成される。
【００２０】また、前記目的は、電子署名付きの公開鍵
の応答を受けたＤＮＳサーバの公開鍵管理手段に、電子
署名付きの公開鍵の応答パケットに含まれる公開鍵、電
子署名及び電子署名をしたサーバのドメイン名の情報を
キャッシングさせ、ネットワーク及びサーバに無駄な負
荷がかかることを防止し、公開鍵の取得を効率化するよ
うにしたことにより達成される。
【００２１】前述において、ネットワークのドメイン名
とアドレスとの対応を解決する手段であるＤＮＳは、Ｄ
ＮＳを実現するための装置であるＤＮＳサーバの機能を
拡張し、ドメイン名と公開鍵との対応を解決する手段を
提供する。ＤＮＳの実現方法は、例えば、“文献：［RF
C1035］ Domain Names - Implementation and Specific
ations 著者：P. Mockapetris 発行：IETF”等に説明さ
れている。
【００２２】本発明により公開鍵を管理する手段と、ネ
ットワークに属するホストの公開鍵とドメイン名とを対
応付けて格納されたデータベースとを有する機能拡張さ
れたＤＮＳサーバは、ホストからドメイン名の情報によ
って公開鍵の問い合わせを受けたとき、前記の公開鍵を
管理する手段が前記データベースを参照することによ
り、問い合わせのドメイン名に対応する公開鍵をホスト
に応答することができる。これにより、本発明は、ネッ
トワーク上の２つのホストがセキュリティ通信を開始す
るとき、通信相手のホストのドメイン名に対応する公開
鍵を自動的に取得させ、ネットワークにおける公開鍵の
管理を容易とすることができる。
【００２３】また、本発明は、公開鍵問い合わせパケッ
トの中にホストが信用するＤＮＳサーバの名前を入れさ
せ、このホストが信用するＤＮＳサーバによって公開鍵
応答パケットに電子署名を付けさせているので、公開鍵
応答パケットにある公開鍵が信用できるか否かをホスト
が判定することができ、不正なホストが自分の公開鍵と
アドレスが問い合わせのあったドメイン名に対応してい
るように見せかけることでセキュリティ通信の相手にな
りすますことを防止することができる。このとき、公開
鍵を取得するためにやり取りする全てのパケットに対し
て、前述した機能拡張したＤＮＳサーバに電子署名を付
けさせることにより、パケットの内容の改竄を防止する
ことができる。
【００２４】
【発明の実施の形態】以下、本発明による公開鍵の管理
方法の実施形態を図面により説明する。
【００２５】図１はＤＮＳサーバを機能拡張したサーバ
であるＫＭＳ(Ｋey Ｍanagement Ｓerver)の構成を示す
ブロック図、図２は拡張したＤＮＳクライアントの機能
を持つホストの構成を示すブロック図、図３は公開鍵と
ドメイン名との対応を説明するテーブルの構成を示す
図、図４はＤＮＳサーバが公開鍵の問い合わせを受けた
ときに公開鍵を応答する手順を説明するフローチャー
ト、図５はＤＮＳサーバが電子署名の要求を受けたとき
に公開鍵応答パケットに電子署名を付与する手順を説明
するフローチャート、図６はＤＮＳクライアントの機能
を持つホストが通信相手の公開鍵を取得する手順を説明
するフローチャート、図７は本発明を階層的なドメイン
名の構造を持つネットワークに適用した場合の実施形態
を示すブロック図、図８はホストが通信相手の公開鍵の
取得ために行う手順の中で、ホスト・ＫＭＳ間及びＫＭ
Ｓ・ＫＭＳ間でやり取りするパケットの種類とそれらに
付与される電子署名を説明する図、図９はＤＮＳパケッ
トのフォーマットの構成を説明する図、図１０はＤＮＳ
パケットに含まれる資源レコードのフォーマットの構成
を説明する図である。図１、図２、図７、図８におい
て、１０はＫＭＳ、１１、２１はネットワーク制御部、
１２、２２はＩＰ処理部、１３、２３はＴＣＰ／ＵＤＰ
処理部、１４は拡張ＤＮＳ処理部、１５はドメイン名／
ＩＰアドレステーブル、１６、２５はドメイン名・公開
鍵・電子署名テーブル、１７、２６は初期保持データ、
２４は拡張ＤＮＳクライアント、２７はセキュリティ通
信処理部、１０１はネットワーク、１４１、２４１はＤ
ＮＳパケット振り分け部、１４２はＤＮＳ処理部、１４
３は公開鍵問い合わせ／応答処理部、１４４は電子署名
処理部、２４２はドメイン名リゾルバ、２４３は公開鍵
問い合わせ処理部、２４４は電子署名処理部、７１、７
５はホストＡ、Ｂ、７２〜７４、７６はＫＭＳである。
【００２６】まず最初に、本発明が適用されるネットワ
ークシステム全体の構成及び処理の流れについて図７を
参照して説明する。
【００２７】図７に示すネットワークシステムは、ネッ
トワークが階層構造を持ち、各階層毎にドメイン名が与
えられており、ドメインを持つネットワークの各階層が
１つのＫＭＳを持つように構成されている。ここで、ホ
ストＡ７１がホストＢ７５の公開鍵を取得する場合につ
いて考える。この場合、ホストＡ７１は、同一のドメイ
ンの階層にあるＫＭＳ“１”７２に対してホストＢ７５
の公開鍵を問い合わせる。このとき、単にホストＢ７５
の公開鍵のデータを受け取るのみでは不正な他のホスト
がホストＢ７５に成りすますのを防ぐことができないの
で、ホストＡ７１は、信用することができるＫＭＳの電
子署名も要求する。今の場合、ホストＡ７１が信用する
ＫＭＳはＫＭＳ“００”７４であるとする。また、ＫＭ
Ｓ“００”７４の公開鍵は、ホストＡ７１のみならず一
般に広く知られ、認証されているものとする。
【００２８】ＫＭＳ“１”７２は、ホストＡ７１からの
ホストＢ７５の公開鍵のデータの要求に対して、ホスト
Ｂ７５の公開鍵のデータを持ってない場合、上位のＫＭ
Ｓ“０”７３に問い合わせるが、持っている場合、ホス
トＡ７１が信用しているＫＭＳ“００”７４にホストＢ
７５の公開鍵のデータに電子署名を付けるように要求す
る。また、ＫＭＳ“１”７２は、ホストＢ７５の公開鍵
のデータを持ってない場合、ホストＢ７５の公開鍵のデ
ータを持っているＫＭＳに行き会うまで再帰的に上位の
ＫＭＳに問い合わせを続ける。ＫＭＳ“１”７２からの
問い合わせを受けたホストＢ７５の公開鍵のデータを持
っているＫＭＳは、ＫＭＳ“００”７４に電子署名を要
求する。
【００２９】電子署名を付けるように要求されたＫＭＳ
“００”７４は、自らの電子署名を付けたホストＢ７５
の公開鍵のデータをＫＭＳ“１”７２に返す。ＫＭＳ
“１”７２は、ホストＢ７５の公開鍵のデータをホスト
Ａ７１に返す。この場合、ホストＡ７１は、元々ＫＭＳ
“００”７４の公開鍵を知っているためそれが信用でき
るデータか否かを判断することができる。
【００３０】前述した一連の処理によりホストＡ７１
は、ホストＢ７５の公開鍵を安全に取得することがで
き、これを使用して、ホストＢ７５との間でセキュリテ
ィ通信を行うことができる。
【００３１】次に、図９、図１０を参照して、ＤＮＳパ
ケットのフォーマットの構成と、ＤＮＳパケットに含ま
れる資源レコードのフォーマットの構成とを説明する。
【００３２】ＤＮＳパケットは、図９に示すように、Ｄ
ＮＳヘッダ９１、問い合わせ部９２、回答部９３、権限
付きネームサーバの名前を表す権威部９４、複数の資源
レコードを含む付加情報部９５から成る。また、図１０
に示すように、ＤＮＳパケットに含まれる資源レコード
の１つであるＴＸＴレコードは、名前フィールド１０
１、ＴＹＰＥフィールド１０２、ＣＬＡＳＳフィールド
１０３、この資源レコードが捨てられずにキャッシュさ
れている時間間隔を示すＴＴＬフィールド１０４、デー
タ長フィールド１０５、データフィールド１０６からな
る。
【００３３】複数の資源レコードとしては、ＴＹＰＥに
より識別される複数のものがあり、本発明の実施形態
は、複数あるＤＮＳ資源レコードの内ＴＸＴレコードと
呼ばれるＴＹＰＥ＝１６の資源レコードに、公開鍵問い
合わせ情報及び公開鍵応答情報を入れることとする。ま
た、本発明の実施形態は、公開鍵問い合わせ情報及び公
開鍵応答情報を入れる資源レコードのデータフィールド
１０６の先頭に公開鍵問い合わせ／応答、電子署名要
求、または、通常のＴＸＴレコードの区別がつくような
識別子１０６１のフィールドを設けている。
【００３４】なお、ＴＸＴレコードについては、前掲の
ＤＮＳに関する文献の中に説明がある。また、資源レコ
ードとして、前述したＴＸＴレコードの他に、アドレス
とドメイン名との対応を示すＡレコード（ＴＹＰＥ＝
１）、メール・エクスチェンジャのドメイン名を示すＭ
Ｘレコード（ＴＹＰＥ＝１５）等がある。
【００３５】次に、図１を参照して、本発明の実施形態
によるサーバであるＫＭＳの構成を説明する。図１にお
いて、各ブロックを結ぶ実線はパケットの受け渡しを行
う関係を示し、破線はデータの参照を行うことを示す。
【００３６】ＫＭＳ１０は、ネットワーク制御部１１
と、ＩＰ処理部１２と、ＴＣＰ／ＵＤＰ処理部１３と、
拡張ＤＮＳ処理部１４と、ドメイン名／ＩＰアドレステ
ーブル１５と、ドメイン名・公開鍵・電子署名テーブル
１６と、初期保持データ１７とを備えて構成され、ネッ
トワーク制御部１１を介してネットワーク１０１に接続
されている。また、拡張ＤＮＳ処理部１４は、ＤＮＳパ
ケット振り分け部１４１と、ＤＮＳ処理部１４２と、公
開鍵問い合わせ／応答処理部１４３と、電子署名処理部
１４４とを備えて構成されている。
【００３７】前述において、ネットワーク制御部１１
は、ＫＭＳ１０とＩＰネットワーク１０１とを接続して
いる。ＩＰ処理部１２は、ネットワーク制御部１１の上
位にあって、ＩＰ(Internet Protocol) によってやり取
りされるパケットの送受信処理を行う。ＴＣＰ／ＵＤＰ
処理部１３は、ＩＰ処理部１２の上位にあって、ＴＣＰ
／ＵＤＰ(Transmission Control Protocol／User Datag
ram Protocol) によってやり取りされるパケットの送受
信処理を行う。ここで、特に、ＴＣＰ／ＵＤＰ処理部１
３は、ＤＮＳに割り当てられたソケット番号を持つパケ
ットを受信したとき、そのパケットを拡張ＤＮＳ処理部
１４に送る。逆に、拡張ＤＮＳ処理部１４は、自ら生成
したパケットを送信するとき、その送信すべきパケット
をＴＣＰ／ＵＤＰ処理部１３に送る。
【００３８】拡張ＤＮＳ処理部１４におけるＤＮＳパケ
ット振り分け部１４１は、ＴＣＰ／ＵＤＰ処理部１３か
らＤＮＳパケットを受け取り、図１０に示す識別子１０
６１を見てＤＮＳ処理部１４２、公開鍵問い合わせ／応
答処理部１４３、電子署名処理部１４４の３つの内のど
れかにＤＮＳパケットを振り分ける。ＤＮＳ処理部１４
２は、ＴＣＰ／ＵＤＰ処理部１３からの従来のＤＮＳパ
ケットを受け取り、ドメイン名とＩＰアドレスとが対応
づけて格納さているデータベースであるドメイン名・Ｉ
Ｐアドレステーブル１５の検索またはエントリの追加を
行う。公開鍵問い合わせ／応答処理部１４３は、他のＫ
ＭＳからの公開鍵の問い合わせを拡張ＤＮＳパケットの
形でＴＣＰ／ＵＤＰ処理部１３から受け取ったとき、問
い合わせのあったドメイン名の公開鍵を取得するために
ドメイン名と公開鍵とが対応づけて格納されたドメイン
名・公開鍵・電子署名テーブル１６を検索する。
【００３９】ドメイン名・公開鍵・電子署名テーブル１
６は、図３に示すように、ドメイン名３１、公開鍵３
２、ホストが信用するＫＭＳが付けた電子署名３３、電
子署名を付けたＫＭＳ名３４、エントリの生成時点を示
すタイムスタンプ３５の５つの項目から成る。公開鍵問
い合わせ／応答処理部１４３は、もし、ドメイン名・公
開鍵・電子署名テーブル１６にエントリがあれば、問い
合わせの要求に従って他のＫＭＳへ電子署名の要求を出
すか、または、電子署名処理部１４４によって公開鍵の
応答パケットに電子署名を付ける処理を行う。また、公
開鍵問い合わせ／応答処理部１４３は、ドメイン名・公
開鍵・電子署名テーブル１６にエントリがないとき、他
のＫＭＳに対して、問い合わせのあったドメイン名の公
開鍵を問い合わせるパケットをＴＣＰ／ＵＤＰ処理部１
３を通して送信する。電子署名処理部１４４は、他のＫ
ＭＳからの電子署名要求を拡張ＤＮＳパケットの形でＴ
ＣＰ／ＵＤＰ処理部１３から受け取ったとき、問い合わ
せの要求に従って他のＫＭＳへ電子署名の要求を出す
か、または、公開鍵応答パケットに電子署名を付ける処
理を行う。
【００４０】また、ＫＭＳ１０は、初期保持データ１７
を持つ。初期保持データ１７は、自分のドメイン名・公
開鍵１７１、ＤＮＳの親子関係において上位のＫＭＳの
ドメイン名１７２、ＤＮＳの親子関係において下位にあ
るものの中で信用するＫＭＳのドメイン名・公開鍵１７
３から成る。ＫＭＳ１０は、他のＫＭＳに公開鍵を問い
合わせに行くときにこれらのデータを利用する。
【００４１】次に、図２を参照して本発明により拡張し
たＤＮＳクライアントの機能を持つホストの構成を説明
する。
【００４２】ホスト２０は、ネットワーク制御部２１
と、ＩＰ処理部２２と、ＴＣＰ／ＵＤＰ処理部２３と、
拡張ＤＮＳクライアント２４と、ドメイン名・公開鍵・
電子署名テーブル２５と、初期保持データ２６と、セキ
ュリティ通信処理部２７とを備えて構成され、ネットワ
ーク制御部１１を介してＩＰネットワーク１０１に接続
されている。また、拡張ＤＮＳクライアント２４は、Ｄ
ＮＳパケット振り分け部２４１と、ドメイン名リゾルバ
２４２と、公開鍵問い合わせ処理部２４３と、電子署名
確認部２４４とを備えて構成されている。
【００４３】前述において、ホスト２０は、ＫＭＳと同
様に、ネットワーク制御部２１、ＩＰ処理部２２、ＴＣ
Ｐ／ＵＤＰ処理部２３を持ち、ＩＰネットワーク２０１
に接続されている。ＴＣＰ／ＵＤＰ処理部２３は、ＤＮ
Ｓに割り当てられたソケット番号を持つパケットを受信
したとき、そのパケットを拡張ＤＮＳクライアント２４
に送る。逆に、拡張ＤＮＳクライアント２４は、自ら生
成したパケットを送信するとき、そのパケットをＴＣＰ
／ＵＤＰ処理部２３に送る。
【００４４】拡張ＤＮＳクライアント２４内のＤＮＳパ
ケット振り分け部２４１は、ＴＣＰ／ＵＤＰ処理部２３
からＤＮＳパケットを受け取り、ＤＮＳヘッダの中身を
見てドメイン名リゾルバ２４２、公開鍵問い合わせ処理
部２４３のいずれかに処理を振り分ける。ドメイン名リ
ゾルバ２４２は、従来のＤＮＳクライアントと同様に、
ドメイン名に対応するＩＰアドレスを解決する処理を行
う。そして、ドメイン名に対応するＩＰアドレスを問い
合わせる際、ドメイン名リゾルバ２４２は、ＴＣＰ／Ｕ
ＤＰ処理部２３を通して問い合わせパケットを送信す
る。ドメイン名リゾルバ２４２は、問い合わせに対する
応答もＴＣＰ／ＵＤＰ処理部２３を通して受信する。
【００４５】本発明により新たに付加したモジュールで
ある公開鍵問い合わせ処理部２４３は、ドメイン名に対
応する公開鍵を解決する処理を行う。公開鍵問い合わせ
処理部２４３は、新規に得た公開鍵の情報をドメイン名
・公開鍵・電子署名テーブル２５に保存し、次回に公開
鍵を問い合わせに行く前に参照する。電子署名確認部２
４４は、公開鍵問い合わせ処理部２４３が受け取った公
開鍵の情報について、初期保持データ２６内の信用する
ＫＭＳのドメイン名・公開鍵２６３を参照して、公開鍵
の情報に付いている電子署名が信用するＫＭＳのものか
否かを判定し、公開鍵の情報が信用できるか否かを確認
する。
【００４６】公開鍵問い合わせ処理部２４３は、信用す
るＫＭＳのドメイン名・公開鍵２６３が複数ある場合
に、公開鍵を問い合わせるドメイン名に応じて信用する
ＫＭＳのドメイン名・公開鍵２６３の中から最適な信用
するＫＭＳを選択する。ホスト２０は、初期保持データ
２６内に自分のドメイン名・公開鍵２６１と上位のＫＭ
Ｓのドメイン名２６２とを持ち、公開鍵問い合わせ処理
部２４３は、公開鍵を問い合わせに行く際に自分のドメ
イン名・公開鍵２６１と上位のＫＭＳのドメイン名２６
２とを参照する。セキュリティ通信処理部２７は、公開
鍵問い合わせ処理部２４３が取得した通信相手の公開鍵
に基づいて、従来の方法に従ってセキュリティ通信を行
う。
【００４７】次に、図４に示すフロー、及び、ホスト・
ＫＭＳ間及びＫＭＳ・ＫＭＳ間でやり取りするパケット
の種類とそれらに付与される電子署名を示す図８を参照
して、本発明を階層的なドメイン名の構造を持つネット
ワークに適用した場合の図７に示すネットワークにおい
て、ホストが通信相手の公開鍵の取得ために行う手順に
ついて説明する。
【００４８】図７において、ＫＭＳ“０”７３、ＫＭＳ
“１”７２、ＫＭＳ“２”７６、ＫＭＳ“００”７４
は、図１により説明した構成を持つＫＭＳであり、ま
た、ホストＡ７１、Ｂ７５は、図２により説明した構成
の拡張したＤＮＳクライアントの機能を持つホストであ
る。そして、ＫＭＳ“００”７４は、ドメイン名ｘｘを
持つネットワーク７０１に接続され、ＫＭＳ“０”７３
は、ドメイン名ａ．ｘｘを持つネットワーク７０２に接
続されている。また、ホストＡ７１とＫＭＳ“１”７２
とは、ドメイン名ｂ．ａ．ｘｘを持つネットワーク７０
３に接続され、ホストＢ７５とＫＭＳ“２”７６とは、
ドメイン名ｃ．ａ．ｘｘを持つネットワーク７０４に接
続されている。
【００４９】ドメイン名は、階層構造を成しており、各
ＫＭＳは、従来のＤＮＳサーバの役割をも果たしてい
る。また、図８に示す例は、ホストＢ７５の公開鍵の情
報をＫＭＳ“２”７６のみが持っている場合の各ＫＭＳ
の動作を示しており、また、図８に示す各矢印は、ホス
トＡ７１がホストＢ７５の公開鍵を取得する際に、ホス
トとＫＭＳとの間やＫＭＳとＫＭＳとの間でやり取りす
るパケットやパケットに付加する電子署名の形態を示し
ている。パケットの種類は、公開鍵問い合わせ、電子署
名要求、公開鍵応答の３通りあり、電子署名の具体的な
内容は、図８の枠内の記号を用いて表しているように、
次のように定義されているものとする。
【００５０】Ｓ（Ｋ，［ａ，ｂ，ｃ］）：鍵Ｋによりメ
ッセージ［ａ，ｂ，ｃ］に電子署名を付与したもの Ｄ（Ｘ）：Ｘのドメイン名 Ｓ（Ｘ）：Ｘの公開鍵 Ｔ（Ｘ）：Ｘの秘密鍵 ＩＰ（Ｘ）：ＸのＩＰアドレス ＫＭＳ（Ｘ）：Ｘが電子署名を要求するＫＭＳ
【００５１】以下、ホストＡ７１が電子署名を要求する
ＫＭＳがＫＭＳ“００”７４であるとして図４に示すフ
ローを説明する。
【００５２】（１）まず、ホストＡは、ホストＢ７５の
公開鍵を問い合わせるパケットをＫＭＳ“１”７２に送
信する。この公開鍵を問い合わせるパケットは、図８に
矢印８１により示しているように、 Ｓ（Ｔ（Ａ），［Ｄ（Ｂ），ＫＭＳ（Ａ），ＩＰ
（Ａ），Ｄ（Ａ）］） であり、これは、前述の定義から理解できるように、ホ
ストＢのドメイン名、ホストＡが電子署名を要求するＫ
ＭＳ、ホストＡのＩＰアドレス、ホストＡのドメイン名
よりなるメッセージに、ホストＡの秘密鍵により電子署
名を行ったものである。ＫＭＳ“１”７２がホストＡ７
１からホストＢ７５の公開鍵を問い合わせるパケットを
受けたとき、図１に示す電子署名処理部１４４は、パケ
ットに付いている電子署名を見る。電子署名処理部１４
４は、ドメイン名・公開鍵・電子署名テーブル１６から
ホストＡ７１の公開鍵を取り出し、パケットの内容が改
竄されてないか否かをその公開鍵を使って判定する（ス
テップ４１）。
【００５３】（２）ＫＭＳ“１”７２は、ステップ４１
の判定で、問い合わせパケットが改竄されていた場合、
そのパケットを廃棄して処理を終了し、問い合わせパケ
ットが改竄されていない場合、図１に示す公開鍵問い合
わせ／応答処理部１４３を動作させ、問い合わせのドメ
イン名についてドメイン名・公開鍵・電子署名テーブル
１６にエントリがあるか否か検索する。ここで、タイム
スタンプも参照し、一定時間以上過ぎている場合、無効
なエントリと見做す（ステップ４３、４２）。
【００５４】（３）ステップ４２の判定で、ドメイン名
・公開鍵・電子署名テーブル１６にエントリがなかった
とき、図７に示すＫＭＳ“１”７２の公開鍵問い合わせ
／応答処理部１４３は、問い合わせのあったホストのド
メイン名と自分のドメイン名とについてそれぞれが属す
るネットワークの名前が一致するか否か判定する。例え
ば、図７において、問い合わせのホストがＢ７５である
場合、Ｂ７５の属するネットワークのドメイン名ｃ．
ａ．ｘｘとＫＭＳ“１”７２の属するネットワークのド
メイン名ｂ．ａ．ｘｘは一致しない（ステップ４４）。
【００５５】（４）ステップ４４の判定においてネット
ワークの名前が一致したとき、図７のＫＭＳ“１”７２
は、ホストＡ７１に対してホストＢに対する公開鍵が未
解決であることを通知する（ステップ４５）。
【００５６】（５）ステップ４４の判定においてネット
ワークの名前が一致しなかったとき、ＫＭＳ“１”７２
は、図１にける初期保持データ１７内の上位のＫＭＳの
ドメイン名１７２を参照して問い合わせ先を調べ、ＫＭ
Ｓ“０”７３にホストＢ７５の公開鍵を問い合わせる。
この場合の問い合わせパケットは、図８に矢印８２によ
り示すように、 Ｓ(Ｔ(ＫＭＳ１)，［Ｄ(Ｂ)，ＫＭＳ(Ａ)，ＩＰ(ＫＭＳ
１)，Ｄ(ＫＭＳ１)］) であり、ホストＢ７５のドメイン名、ホストＡ７１が電
子署名を要求するＫＭＳのドメイン名、ＫＭＳ“１”７
２のＩＰアドレス及びＫＭＳ“１”７２のドメイン名を
メッセージとし、ＫＭＳ“１”７２の秘密鍵を電子署名
の鍵とする電子署名を付加して構成される。このよう
に、電子署名を付加することによって問い合わせパケッ
トの不正な改竄を防止することができる（ステップ４
６）。
【００５７】（６）次に、ＫＭＳ“１”７２は、自ＫＭ
Ｓに公開鍵を問い合わせた者がホストかＫＭＳかを公開
鍵問い合わせパケットの始点ＩＰアドレスから判定し、
公開鍵を問い合わせたのがＫＭＳである場合、処理を終
了する（ステップ４６１）。
【００５８】（７）ステップ４６１で、自ＫＭＳに公開
鍵を問い合わせた者がホストである場合、公開鍵問い合
わせ／応答処理部１４３は、上位のＫＭＳから公開鍵の
応答があるまで一定時間待ち、一定時間内に公開鍵の応
答がなく、電子署名付きの公開鍵を取得できなかった場
合、処理を終了する（ステップ４６２、４６３）。
【００５９】（８）公開鍵問い合わせ／応答処理部１４
３は、電子署名付きの公開鍵の応答が一定時間内にあっ
た場合、その公開鍵を図１に示すドメイン名・公開鍵・
電子署名テーブル１６にキャッシングする。このように
キャッシングを行うことにより、別のホストから同じド
メイン名について公開鍵の問い合わせがあったときに、
公開鍵問い合わせ／応答処理部１４３は、再度別のＫＭ
Ｓに公開鍵の問い合わせに行かずに済み、公開鍵を解決
する処理を効率的に行うことができる（ステップ４６
４）。
【００６０】（９）次に、公開鍵問い合わせ／応答処理
部１４３は、図８の矢印８７に示すように自らの電子署
名をつけた公開鍵応答パケットを公開鍵の問い合わせを
受けたホストに返す。この電子署名付きの公開鍵応答パ
ケットは、Ｄ(ＫＭＳ１)、Ｄ(Ｂ)、Ｓ(Ｂ)、Ｓ(Ｔ(ＫＭ
Ｓ００))，［Ｄ(Ｂ)，Ｓ(Ｂ)，Ｄ(ＫＭＳ００)］をメッ
セージとし、秘密鍵Ｔ(ＫＭＳ１)を署名の鍵とするもの
である（ステップ４６５）。
【００６１】（10）ステップ４２のデータベースの検索
で、問い合わせのドメイン名について、ドメイン名・公
開鍵・電子署名テーブル１６にエントリがあった場合、
図１に示す公開鍵問い合わせ／応答処理部１４３は、そ
のエントリに指定されたＫＭＳの電子署名が付いている
か否かを見る（ステップ４７）。
【００６２】（11）ステップ４７のチェックで、指定さ
れたＫＭＳの電子署名がエントリに付いていた場合、公
開鍵問い合わせ／応答処理部１４３は、そのエントリに
ある電子署名付きの公開鍵をホストＡ７１に返す（ステ
ップ４８）。
【００６３】（12）一方、ステップ４７で指定されたＫ
ＭＳの電子署名がエントリに付いていなかった場合、公
開鍵問い合わせ／応答処理部１４３は、パケットに付い
ているホストＡ７１が信用するＫＭＳと図１の初期保持
データの上位のＫＭＳのドメイン名１７２を見て、図７
に示すＫＭＳ“０”７３に電子署名の要求を出す。図７
に示すＫＭＳ“２”７６がホストＢ７５の公開鍵の情報
を持っていて、ＫＭＳ“０”７３に電子署名の要求を出
す場合、図８の矢印８４に示すように、［Ｄ（Ｂ）、Ｋ
ＭＳ（Ａ）、ＩＰ（ＫＭＳ１）、Ｓ（Ｂ）及びＤ（ＫＭ
Ｓ２）］をメッセージとして、ＫＭＳ“２”７６の秘密
鍵を鍵とする電子署名を付けて要求を行う（ステップ４
９）。
【００６４】前述では、図７におけるＫＭＳ“１”７２
の動作について説明したが、他のＫＭＳ“０”７３、Ｋ
ＭＳ“２”７６も、前述したＫＭＳ“１”７２の場合と
同様な動作を行う。
【００６５】次に、図５に示すフローと図７及び図８と
を参照して、図１に示すＫＭＳの各部の動作の中での電
子署名の要求と応答とについて説明する。
【００６６】（１）いま、図７に示すＫＭＳ“０”７３
が、ＫＭＳ“１”７２から電子署名の要求を受けたとす
る。この場合、ＫＭＳ“０”７３は、図１に示ような構
成を持つ自装置内の電子署名処理部１４４を動作させ、
パケットに付いている電子署名を見る。電子署名処理部
１４４は、ドメイン名・公開鍵・電子署名テーブル１６
からＫＭＳ１７２の公開鍵を取り出し、パケットの内容
が改竄されていないか否かを判定する（ステップ５
１）。
【００６７】（２）ステップ５１の判定で、パケットの
内容が改竄されていた場合、電子署名処理部１４４はパ
ケットを廃棄し、ＫＭＳ“０”７３は処理を終了する
（ステップ５３）。
【００６８】（３）ステップ５１の判定で、パケットの
内容が改竄されていなかった場合、電子署名処理部１４
４は、パケットの内容を見て電子署名の要求先が自分自
身か否かを判定する（ステップ５２）。
【００６９】（４）ステップ５２の判定で、電子署名の
要求先が自分自身でない場合、電子署名処理部１４４
は、初期保持データの上位のＫＭＳのドメイン名１７２
を参照し、電子署名の要求を上位のＫＭＳに対して出
す。図７において、ホストＡ７１が電子署名を要求する
ＫＭＳがＫＭＳ“００”７４である場合、図８の矢印８
５に示すように、ＫＭＳ“０”７３からＫＭＳ“００”
７４への電子署名要求パケットは、［Ｄ（Ｂ）、ＫＭＳ
（Ａ）、ＩＰ（ＫＭＳ１）、Ｓ（Ｂ）及びＤ（ＫＭＳ
０）］をメッセージとしＫＭＳ“０”７３の秘密鍵を鍵
とする電子署名を付けたものとなる（ステップ５４）。
【００７０】（５）一方、ステップ５２の判定で、電子
署名の要求先が自分自身であった場合、電子署名処理部
１４４は、要求されたパケットに対して自分の秘密鍵に
よって電子署名を付け、要求元のＫＭＳに電子署名付き
のパケットを返す。説明している例で、例えば、署名要
求に対してＫＭＳ“００”７４がＫＭＡ“１”７２へ公
開鍵を応答するものとすると、その場合の応答パケット
は、図８の矢印８６に示すように、［Ｄ（Ｂ）、Ｓ
（Ｂ）及びＤ（ＫＭＳ００）］をメッセージとしＫＭＳ
“００”７４の秘密鍵を鍵とする電子署名を付けたもの
となる（ステップ５５）。
【００７１】次に、図６に示すフローと図７及び図８と
を参照して、図２に示す構成のホストの動作を説明す
る。
【００７２】（１）図７において、ホストＡ７１がホス
トＢ７５の公開鍵を取得しようとするものとする。この
とき、図２に示す構成を持つホストＡ７１の公開鍵問い
合わせ処理部２４３は、ドメイン名・公開鍵・電子署名
テーブル２５を検索しホストＢ７５のエントリがあるか
否かを調べる（ステップ６１）。
【００７３】（２）ステップ６１で、ドメイン名・公開
鍵・電子署名テーブル２５にホストＢ７５のエントリが
なかったとき、公開鍵問い合わせ処理部２４３は、初期
保持データ２６の信用するＫＭＳのドメイン名・公開鍵
２６３を参照して信用するＫＭＳを選択し、信用するＫ
ＭＳのドメイン名・公開鍵２６３が複数ある場合、問い
合わせるドメイン名より上位にあってそれに最も近いＫ
ＭＳを選択する（ステップ６２）。
【００７４】（３）次に、公開鍵問い合わせ処理部２４
３は、初期保持データ２６内の公開鍵を問い合わせに行
くＫＭＳのドメイン名２６２を参照して、そのＫＭＳに
ホストＢ７５の公開鍵を問い合わせる。この場合の公開
鍵問い合わせパケットは、図８の矢印８１に示すよう
に、［Ｄ（Ｂ）、ＫＭＳ（Ａ）、ＩＰ（Ａ）及びＤ
（Ａ）］をメッセージとし、ホストＡの秘密鍵Ｔ（Ａ）
を鍵とする電子署名を付加したものとなる（ステップ６
３）。
【００７５】（４）ホストＡ７１は、ステップ６３での
問合せに対して、公開鍵応答パケットが返ってきたと
き、図２の電子署名確認部２４４を動作させ、公開鍵応
答パケットに付いている電子署名が要求したＫＭＳのも
のであって、かつパケットの内容が改竄されていないか
を確認する（ステップ６４）。
【００７６】（５）一定時間以内に公開鍵応答パケット
が返ってこないとき、あるいは、ステップ６４で、公開
鍵応答パケットに付いている電子署名が要求したＫＭＳ
のものでないか、パケットの内容が改竄されていると判
定された場合、ホストＡ７１は、何もせずに処理を終了
する。これにより、ネットワーク上にある不正なホスト
が自らの公開鍵とアドレスが問い合わせのあったドメイ
ン名に対応しているように見せかけることでセキュリテ
ィ通信の相手になりすますことを防止することができ
る。
【００７７】（６）ステップ６４で、公開鍵応答パケッ
トに付いている電子署名が要求したＫＭＳのものであっ
て、かつパケットの内容が改竄されていないと判定され
た場合、公開鍵問い合わせ処理部２４３は、その公開鍵
応答パケットの内容を見て、ドメイン名・公開鍵・電子
署名・署名したＫＭＳのドメイン名の４つの組でドメイ
ン名・公開鍵・電子署名テーブル２５にキャッシングす
る（ステップ６５）。
【００７８】（７）ホストＡ７１のセキュリティ通信処
理部２７は、前述までの処理で取得した公開鍵、あるい
は、ステップ６１で見つかった公開鍵を用い、セキュリ
ティ通信を行うための処理を開始する（ステップ６
６）。
【００７９】ホストは、前述した処理を実行することに
より、公開鍵を解決する処理を効率化することができ
る。
【００８０】前述した本発明の実施形態によれば、ネッ
トワークの２つのホストがセキュリティ通信を開始する
前に機能拡張したＤＮＳサーバによって通信相手のホス
トのドメイン名に対応する公開鍵を自動的に取得させる
ことが可能となり、公開鍵の管理の容易化を図ることが
できる。
【００８１】また、本発明の実施形態によれば、ホスト
が指定したＤＮＳサーバによって公開鍵の応答パケット
に電子署名を付けさせることができるので、ネットワー
ク上にある不正なホストが自らの公開鍵とアドレスとが
問い合わせのあったドメイン名に対応しているように見
せかけることによりセキュリティ通信の相手になりすま
すことを防止することができる。
【００８２】前述したような本発明は、ＦＤやＣＤ−Ｒ
ＯＭ等の記憶媒体に本発明を実現するプログラムを格納
しておき、このプログラムをＤＮＳサーバ及びホストに
インストールして実現することができる。また、本発明
は、ネットワークに接続された情報処理装置の記憶媒体
に本発明を実現するプログラムを格納しておき、ネット
ワークを通してＤＮＳサーバ及びホストのハードディス
ク等の記憶媒体に前述のプログラムをコピーして実現す
ることができる。
【００８３】
【発明の効果】以上説明したように本発明によれば、ネ
ットワークの２つのホストがセキュリティ通信を開始す
る前に通信相手のホストのドメイン名に対応する公開鍵
を安全に自動的に取得することができるため、公開鍵の
管理が容易となる。
【００８４】また、本発明によれば、ネットワーク上に
ある不正なホストが自らの公開鍵とアドレスとが問い合
わせのあったドメイン名に対応しているように見せかけ
ることによりセキュリティ通信の相手になりすますこと
を防止することができる。
【図面の簡単な説明】
【図１】ＤＮＳサーバを機能拡張したサーバであるＫＭ
Ｓ(Ｋey Ｍanagement Ｓerver)の構成を示すブロック図
である。
【図２】拡張したＤＮＳクライアントの機能を持つホス
トの構成を示すブロック図である。
【図３】公開鍵とドメイン名との対応を説明するテーブ
ルの構成を示す図である。
【図４】ＤＮＳサーバが公開鍵の問い合わせを受けたと
きに公開鍵を応答する手順を説明するフローチャートで
ある。
【図５】ＤＮＳサーバが電子署名の要求を受けたときに
公開鍵応答パケットに電子署名を付与する手順を説明す
るフローチャートである。
【図６】ＤＮＳクライアントの機能を持つホストが通信
相手の公開鍵を取得する手順を説明するフローチャート
である。
【図７】本発明を階層的なドメイン名の構造を持つネッ
トワークに適用した場合の実施形態を示すブロック図で
ある。
【図８】ホストが通信相手の公開鍵の取得ために行う手
順の中で、ホスト・ＫＭＳ間及びＫＭＳ・ＫＭＳ間でや
り取りするパケットの種類とそれらに付与される電子署
名を説明する図である。
【図９】ＤＮＳパケットのフォーマットの構成を説明す
る図である。
【図１０】ＤＮＳパケットに含まれる資源レコードのフ
ォーマットの構成を説明する図である。
【符号の説明】
１０ ＫＭＳ １１、２１ ネットワーク制御部 １２、２２ ＩＰ処理部 １３、２３ ＴＣＰ／ＵＤＰ処理部 １４ 拡張ＤＮＳ処理部 １５ ドメイン名／ＩＰアドレステーブル １６、２５ ドメイン名・公開鍵・電子署名テーブル １７、２６ 初期保持データ ２４ 拡張ＤＮＳクライアント ２７ セキュリティ通信処理部 １０１ ネットワーク １４１、２４１ ＤＮＳパケット振り分け部 １４２ ＤＮＳ処理部 １４３ 公開鍵問い合わせ／応答処理部 １４４ 電子署名処理部 ２４２ ドメイン名リゾルバ ２４３ 公開鍵問い合わせ処理部 ２４４ 電子署名確認部 ７１、７５ ホストＡ、Ｂ ７２〜７４、７６ ＫＭＳ
───────────────────────────────────────────────────── フロントページの続き (51)Int.Cl.7 識別記号 ＦＩ テーマコート゛(参考） Ｈ０４Ｌ 12/56 Ｈ０４Ｌ 11/00 ３１０Ｚ 11/20 １０２Ｚ Ｆターム(参考） 5B089 GA11 GB03 HA10 HB02 KA17 KB13 KC58 KH30 5J104 AA07 AA16 EA02 KA02 KA05 NA02 NA37 PA07 5K030 GA15 HC01 HC14 HD06 HD09 JT06 KA05 KA07 LD19 5K033 AA08 CB09 CB11 DA05 DB12 DB14 EC04 9A001 CC07 EZ03 JZ01 JZ25 JZ27 LL03

Claims (4)

    【特許請求の範囲】
  1. 【請求項１】 階層構造を持ち、各階層毎にドメイン名
    を持つネットワークと、そのドメイン名とアドレスとの
    対応を管理する前記各階層毎に設けられるＤＮＳサーバ
    と、ネットワークに収容されるホストとを備え、前記Ｄ
    ＮＳサーバが、ネットワークに属するホストに対して他
    のホストが持つ公開鍵を配布する公開鍵管理方法におい
    て、前記ＤＮＳサーバは、公開鍵を管理する手段と、前
    記ネットワークに属するホストの公開鍵とドメイン名と
    を対応付けて格納したデータベースとを持ち、第１のホ
    ストからのドメイン名の情報による第２のホストの公開
    鍵の問い合わせを受けたとき、前記公開鍵管理手段が前
    記データベースを参照することにより、前記ドメイン名
    に対応する第２のホストの公開鍵の情報を前記第１のホ
    ストに応答することを特徴とする公開鍵管理方法。
  2. 【請求項２】 前記ＤＮＳサーバは、第１のホストから
    第２のホストの公開鍵の問い合わせを受けたとき、自サ
    ーバ内の前記データベースの中に問い合わせのドメイン
    名に対応するエントリがない場合、他の公開鍵管理手段
    とデータベースとを備えた他のＤＮＳサーバに公開鍵の
    解決をドメイン名の階層に沿って再帰的に委託すること
    を特徴とする請求項１記載の公開鍵管理方法。
  3. 【請求項３】 前記ホストは、前記ＤＮＳサーバに他の
    ホストの公開鍵を問い合わせる手段を備え、セキュリテ
    ィ通信開始時、前記公開鍵問い合わせ手段に通信相手と
    なるホストのドメイン名に対応する公開鍵を前記ＤＮＳ
    サーバに問い合わせることを特徴とする請求項１記載の
    公開鍵管理方法。
  4. 【請求項４】 請求項１、２または３記載の公開鍵管理
    方法を実現するための、ＤＮＳサーバに設けられる公開
    鍵を管理する手段の機能を実行するプログラムと、ネッ
    トワークに属するホストの公開鍵とドメイン名とを対応
    付けて格納するデータベースと、ホストからドメイン名
    の情報によって公開鍵の問い合わせを受けたとき該公開
    鍵管理手段が前記データベースを参照することによりド
    メイン名に対応する公開鍵をホストに応答する処理を実
    行するプログラムとを格納したことを特徴とする記憶媒
    体。
JP15532299A 1999-06-02 1999-06-02 公開鍵管理方法 Pending JP2000349747A (ja)

Priority Applications (2)

Application Number Priority Date Filing Date Title
JP15532299A JP2000349747A (ja) 1999-06-02 1999-06-02 公開鍵管理方法
US09/585,358 US6928167B1 (en) 1999-06-02 2000-06-02 Method for managing public key

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
JP15532299A JP2000349747A (ja) 1999-06-02 1999-06-02 公開鍵管理方法

Publications (1)

Publication Number Publication Date
JP2000349747A true JP2000349747A (ja) 2000-12-15

Family

ID=15603367

Family Applications (1)

Application Number Title Priority Date Filing Date
JP15532299A Pending JP2000349747A (ja) 1999-06-02 1999-06-02 公開鍵管理方法

Country Status (2)

Country Link
US (1) US6928167B1 (ja)
JP (1) JP2000349747A (ja)

Cited By (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2001103046A (ja) * 1999-09-30 2001-04-13 Sony Corp 通信装置、通信システム及び通信方法並びに認証装置
WO2003009546A1 (es) * 2001-07-16 2003-01-30 Vodafone Group Plc. Sistema de nombramientos de dominios (dns) para acceso a bases de datos
US7436833B2 (en) 2004-07-15 2008-10-14 Kabushiki Kaisha Toshiba Communication system, router, method of communication, method of routing, and computer program product
US10362031B2 (en) 2014-09-17 2019-07-23 Microsoft Technology Licensing, Llc Establishing trust between two devices
JP2020530734A (ja) * 2017-07-31 2020-10-22 スレットストップ・インコーポレーテッド ネットワークノードによる情報の伝搬

Families Citing this family (22)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7088720B1 (en) * 2000-08-07 2006-08-08 Sbc Technology Resources, Inc. Multiservice use of network connection capability under user-to-network interface signaling
US7136386B2 (en) * 2001-07-19 2006-11-14 Sbc Technology Resources, Inc. Virtual private network over asynchronous transfer mode
US7187678B2 (en) * 2001-08-13 2007-03-06 At&T Labs, Inc. Authentication for use of high speed network resources
US20030163567A1 (en) * 2002-02-28 2003-08-28 Mcmorris Patrick Domain name validation using mapping table
US7382785B2 (en) * 2003-02-21 2008-06-03 At&T Knowledge Ventures, L.P. Extended virtual user-to-network interface with ATM network
EP1779216A1 (en) * 2004-08-20 2007-05-02 Rhoderick John Kennedy Pugh Server authentication
US20070118750A1 (en) * 2005-10-27 2007-05-24 The Go Daddy Group, Inc. Authenticating a caller initiating a communication session
US20070101144A1 (en) * 2005-10-27 2007-05-03 The Go Daddy Group, Inc. Authenticating a caller initiating a communication session
US7876902B2 (en) * 2006-08-31 2011-01-25 Microsoft Corporation Distribution of encrypted software update to reduce attack window
US8538028B2 (en) * 2006-11-20 2013-09-17 Toposis Corporation System and method for secure electronic communication services
CA2705903A1 (en) * 2006-11-20 2008-05-29 Toposis Corporation System and method for secure electronic communication services
US9998423B1 (en) 2006-12-05 2018-06-12 Oath Inc. IP address management of multiple DHCP services
US8494168B1 (en) 2008-04-28 2013-07-23 Netapp, Inc. Locating cryptographic keys stored in a cache
WO2009132446A1 (en) * 2008-05-02 2009-11-05 Toposis Corporation Systems and methods for secure management of presence information for communications services
US9521138B2 (en) 2013-06-14 2016-12-13 Go Daddy Operating Company, LLC System for domain control validation
US9178888B2 (en) 2013-06-14 2015-11-03 Go Daddy Operating Company, LLC Method for domain control validation
US9633128B2 (en) 2014-03-13 2017-04-25 Go Daddy Operating Company, LLC Lightweight web page generation
US10659423B2 (en) 2014-12-19 2020-05-19 Go Daddy Operating Company, LLC System and method for modifying a domain name system template
US10164933B2 (en) 2014-12-19 2018-12-25 Go Daddy Operating Company, LLC System and method for domain name system restore points
US9935950B2 (en) * 2015-01-12 2018-04-03 Verisign, Inc. Systems and methods for establishing ownership and delegation ownership of IOT devices using domain name system services
US20160205106A1 (en) * 2015-01-12 2016-07-14 Verisign, Inc. Systems and methods for providing iot services
US9973337B2 (en) * 2015-11-18 2018-05-15 International Business Machines Corporation Domain-server public-key reference

Family Cites Families (10)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5109384A (en) * 1988-11-02 1992-04-28 Tseung Lawrence C N Guaranteed reliable broadcast network
US5175765A (en) * 1989-05-09 1992-12-29 Digital Equipment Corporation Robust data broadcast over a distributed network with malicious failures
US5455865A (en) * 1989-05-09 1995-10-03 Digital Equipment Corporation Robust packet routing over a distributed network containing malicious failures
US5422953A (en) * 1993-05-05 1995-06-06 Fischer; Addison M. Personal date/time notary device
US5870475A (en) * 1996-01-19 1999-02-09 Northern Telecom Limited Facilitating secure communications in a distribution network
US5790548A (en) * 1996-04-18 1998-08-04 Bell Atlantic Network Services, Inc. Universal access multimedia data network
US5825884A (en) * 1996-07-01 1998-10-20 Thomson Consumer Electronics Method and apparatus for operating a transactional server in a proprietary database environment
US6111883A (en) * 1996-07-12 2000-08-29 Hitachi, Ltd. Repeater and network system utilizing the same
US6023507A (en) * 1997-03-17 2000-02-08 Sun Microsystems, Inc. Automatic remote computer monitoring system
US5883810A (en) * 1997-09-24 1999-03-16 Microsoft Corporation Electronic online commerce card with transactionproxy number for online transactions

Cited By (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2001103046A (ja) * 1999-09-30 2001-04-13 Sony Corp 通信装置、通信システム及び通信方法並びに認証装置
WO2003009546A1 (es) * 2001-07-16 2003-01-30 Vodafone Group Plc. Sistema de nombramientos de dominios (dns) para acceso a bases de datos
ES2183728A1 (es) * 2001-07-16 2003-03-16 Airtel Movil S A Sistema de nombramientos de dominios (dns) para acceso a bases de datos.
AU2002319319B2 (en) * 2001-07-16 2007-08-30 Vodafone Group Plc. System of assigning domain names (DNS) providing access to databases
US7436833B2 (en) 2004-07-15 2008-10-14 Kabushiki Kaisha Toshiba Communication system, router, method of communication, method of routing, and computer program product
US10362031B2 (en) 2014-09-17 2019-07-23 Microsoft Technology Licensing, Llc Establishing trust between two devices
US10581848B2 (en) 2014-09-17 2020-03-03 Microsoft Technology Licensing, Llc Establishing trust between two devices
JP2020530734A (ja) * 2017-07-31 2020-10-22 スレットストップ・インコーポレーテッド ネットワークノードによる情報の伝搬
JP7280260B2 (ja) 2017-07-31 2023-05-23 スレットストップ・インコーポレーテッド ネットワークノードによる情報の伝搬

Also Published As

Publication number Publication date
US6928167B1 (en) 2005-08-09

Similar Documents

Publication Publication Date Title
JP2000349747A (ja) 公開鍵管理方法
US7461250B1 (en) System and method for certificate exchange
Kohl et al. The evolution of the Kerberos authentication service
Czerwinski et al. An architecture for a secure service discovery service
US5822434A (en) Scheme to allow two computers on a network to upgrade from a non-secured to a secured session
US6557037B1 (en) System and method for easing communications between devices connected respectively to public networks such as the internet and to private networks by facilitating resolution of human-readable addresses
JP3263878B2 (ja) 暗号通信システム
US6823454B1 (en) Using device certificates to authenticate servers before automatic address assignment
KR101085638B1 (ko) 피어 투 피어 네트워크에서의 안전한 계층적 이름 공간
US8301753B1 (en) Endpoint activity logging
JPH11167536A (ja) コンピュータ・ネットワークを利用したクライアント／ホスト間の通信方法と装置
GB2359969A (en) Automated authentication of communication devices with certificates bound to the device identifier
WO2002039637A1 (en) A method and system for secure wireless database management
WO2008116416A1 (fr) Procédé, dispositif et système pour qu'un système de nom de domaine se mette à jour de façon dynamique
CN101242426B (zh) 建立传输层安全连接的方法、系统及装置
US20020035686A1 (en) Systems and methods for secured electronic transactions
EP4203377A1 (en) Service registration method and device
CN112132581B (zh) 基于iota的pki身份认证系统及方法
WO2009143739A1 (zh) 管理和查询映射信息的方法、设备及通信系统
Lioy et al. DNS security
CN115580498B (zh) 融合网络中的跨网通信方法及融合网络系统
Chetioui et al. New Protocol E-DNSSEC to Enhance DNSSEC Security.
JP2012527794A (ja) ホストアイデンティティタグ取得のための方法およびシステム
Cisco Configuring Certification Authority Interoperability
EP1615402B1 (en) Identification and authentication system and method for a secure data exchange

Legal Events

Date Code Title Description
A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20060525

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20090414

A02 Decision of refusal

Free format text: JAPANESE INTERMEDIATE CODE: A02

Effective date: 20090818