JP2002290397A - セキュア通信方法 - Google Patents

Abstract

(57)【要約】 【課題】計算処理やデータ伝送に当たっての負荷を小さ
くでき、かつ、安全性の高いセキュア通信方法を提供す
ること。 【解決手段】登録されたエンティティCl1，Cl2の認証を
行うと共に、秘密鍵を発生する鍵管理サーバＳを用い、
エンティティの認証時に、相互通信を行おうとする各エ
ンティティに対して同一の秘密鍵を与え、これら相互通
信を行おうとするエンティティ間における相互認証は、
互いに同一秘密鍵（セッション鍵）の所持を確認するこ
とで行い、相互認証完了後は、相互通信を行おうとする
エンティティ間で授受するデータを秘密鍵を用いて対称
型暗号化方式により暗号化して伝送するようにしたこと
を特徴とする。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】本発明は、ネットワークを介
して情報を授受するに当たり、簡易且つ有効なセキュリ
ティを確保できるようにしたセキュア通信方法に関す
る。

【０００２】

【従来の技術】医療関係機関や医療業務参画者向けに通
信ネットワークを利用した医療関係情報の広域利用が計
画され、実用化に向けて研究されている。この場合、医
療関係情報には患者のカルテや診断画像、検査データ等
も対象とほか、これらの情報を通信ネットワークを用い
て伝送することとなるので、データの改竄防止や個人の
プライバシーを保証できるシステムである必要があり、
また、なりすましを含めた不正侵入を防止できるシステ
ムでなければならない。

【０００３】ところで、クライアント／サーバシステム
の通信層セキュリティ方式としてはＳＳＬ[参考文献“T
he SSL, Protocol V3.0, Netscape Communication
Corporation,1996.3”]が知られている。ＳＳＬはク
ライアント／サーバのエンティティ間で相互認証、転送
データ秘匿、及び転送データの完全性保証等のセキュリ
ティ機能を提供している。従って、このような既存のセ
キュリティ方式の利用が考えられる。

【０００４】しかし、このＳＳＬ方式における鍵管理は
不特定多数通信向けの公開鍵暗号技術をベースとしてい
る。そのため、特にローカルなネットワークセキュリテ
ィシステム構築に適用することを考えた場合には、以下
のような問題点がある。

【０００５】（１）第１には、鍵生成処理及び鍵配送の
オーバヘッドが大きいという点である。

【０００６】すなわち、公開鍵は一般的には１０２４
［ｂｉｔ］程度の容量を持たせてあるので通信量が大き
くなり、また、鍵の処理に要する計算量が大きく、処理
時間が長くなると云う問題が残ることである。

【０００７】（２）また、第２には、クライアント側ユ
ーザの秘密鍵が回復できないという点である。すなわ
ち、秘密鍵を紛失した場合に回復できないという問題で
ある。

【０００８】（３）第３には、各種プロトコル攻撃に対
し、今後どの程度安全かが不透明であるという点であ
る。アルゴリズムに対する攻撃の一つであって、プロト
コルのやり取りの中で割って入って成り済ますプロトコ
ル攻撃に対してどの程度安全が保証されるか不透明であ
るという問題である。

【０００９】（４）第４には、グローバルなＰＫＩや、
X．509等の公開鍵に関する暗号化システム連携を考慮す
ると早期のセキュリティ構築が覚束ないという点であ
る。

【００１０】

【発明が解決しようとする課題】クライアント／サーバ
のエンティティ間で相互認証、転送データ秘匿、及び転
送データの完全性保証等のセキュリティ機能を提供して
いるＳＳＬ方式の鍵管理は不特定多数通信向けの公開鍵
暗号技術をベースとしている。そのため、特にローカル
なネットワークセキュリティシステム構築に際しては、 （１）鍵生成処理及び鍵配送のオーバヘッドが大きい。

【００１１】（２）クライアント側ユーザの秘密鍵が回
復できない。

【００１２】（３）各種プロトコル攻撃に対し、今後ど
の程度安全かが不透明である。

【００１３】（４）グローバルなＰＫＩや、X．509等の
公開鍵に関する暗号化システム連携を考慮すると早期の
セキュリティ構築が覚束ない。

【００１４】といった問題がある。

【００１５】従って、計算処理やデータ伝送に当たって
の負荷が小さく、しかも、データの改竄防止や個人のプ
ライバシーを保証できると共に、なりすましを含めた不
正侵入に対して耐性の強いシステムの早急な開発が嘱望
される。

【００１６】そこでこの発明の目的とするところは、計
算処理やデータ伝送に当たっての負荷が小さく、しか
も、データの改竄防止や個人のプライバシーを保証でき
ると共に、なりすましを含めた不正侵入に対して耐性の
強いセキュア通信方法を提供することにある。

【００１７】

【課題を解決するための手段】上記目的を達成するた
め、本発明は次のように構成する。すなわち、第１に
は、登録されたエンティティの認証を行うと共に、秘密
鍵を発生する鍵管理サーバを用い、エンティティの認証
時に、相互通信を行おうとする各エンティティに対して
同一の秘密鍵を与え、これら相互通信を行おうとするエ
ンティティ間における相互認証は、互いに同一秘密鍵
（セッション鍵）の所持を確認することで行い、相互認
証完了後は、相互通信を行おうとするエンティティ間で
授受するデータを前記秘密鍵を用いて対称型暗号化方式
により暗号化して伝送するようにしたことを特徴とす
る。

【００１８】また、第２には、各エンティティのＩＤ情
報をマスタ鍵により処理して生成した各エンティティの
個別鍵をそれぞれ対応するエンティティに保持させると
共に、鍵管理サーバを設けて、ここに登録された各エン
ティティのＩＤ情報を保持させ、エンティティ間での通
信要求があると鍵管理サーバには第１の乱数を発生さ
せ、通信要求のあったエンティティにはこの第１の乱数
を用いてエンティティ側で個別鍵により変換処理させ
て、また、自己の発生させた第２の乱数とともに鍵管理
サーバに伝送させると共に、鍵管理サーバにはこれを受
け取るとエンティティ側で発生させた第２の乱数ととも
に受け取って再変換処理し、元の第１の乱数を再生して
前記発生した第１の乱数と照合し、第２の乱数をそのエ
ンティティの個別鍵で変換処理させて当該エンティティ
に伝送し、エンティティ側で再変換処理して第２の乱数
を再生し、元の第２の乱数と照合することにより鍵管理
サーバとエンティティ間の認証し、鍵管理サーバとエン
ティティとの相互認証が終わると鍵管理サーバより秘密
鍵情報（すなわち、セッション鍵（またはその種）ｋ
ｓ）を有効期限限定で一時的に生成し、この生成した秘
密鍵情報を、通信要求のあった対象のエンティティそれ
ぞれに配信し、この秘密鍵情報を得た通信要求のあるエ
ンティティ相互間においては、この秘密鍵情報の共有を
以て、互いの認証を行うようにし、以後のこれらエンテ
ィティ相互の通信はこの秘密鍵情報を暗号化処理に利用
することによりセキュアな通信路を確立することを特徴
とする。

【００１９】また、第３には送信側では伝送するデータ
をハッシュ関数により処理して暗号化することにより署
名処理した情報を伝送データに付加し、受信側では受信
したデータをハッシュ関数により処理して暗号化した情
報と送信側で前記署名処理した情報とを照合し、一致の
有無で伝送データの改竄を検証する検証機能（データ完
全性補償機能）を前記第１または第２のセキュア通信方
法に併用する。

【００２０】本発明は、通信要求のあったエンティティ
に対して登録されたエンティティであるか否かを鍵管理
サーバとの間での相互認証により確認し、その後に通信
要求のあったエンティティおよびこのエンティティと通
信するエンティティそれぞれに秘密鍵情報を与え、秘密
鍵情報の共有を以てエンティティ相互の認証を行い、そ
の後は秘密鍵情報を用いて対称鍵暗号化技術にデータ通
信するようにしたものであり、対称鍵暗号化技術を採用
することにより、以下のことが期待できる。

【００２１】第１には、各クライアント（エンティテ
ィ）のＩＤ情報と鍵管理サーバＳのマスタ鍵用いて暗号
化して各クライアントの個別鍵を生成するので個別鍵の
高速生成可能である。そして、対称鍵暗号化を用いるの
で、生成鍵の長さは５６［ｂｉｔ］〜１６８［ｂｉｔ］
と短くて済み、従って、通信量オーバヘッドは小さく、
暗号化処理に必要な演算量も少なくて済む。

【００２２】第２には、ＩＤベースの鍵管理の活用によ
り、クライアント側の個別鍵はクライアントＩＤ情報か
ら回復可能である。従って、個別鍵を失っても回復可能
である。

【００２３】第３には、対称鍵暗号系でのプロトコル攻
撃はReplay攻撃が主であり、セッション番号Ｎまたは時
刻情報Ｔを平文(セッション鍵情報含む)に付加すれば対
処は十分である。

【００２４】第４に、鍵管理サーバＳを信頼点(認証局)
とすることで、信頼点と各クライアント間での暗号化プ
ロトコルを利用する署名方式は一意性の保証ができるこ
とから、ローカルなセキュア通信網が、簡易な鍵管理サ
ーバで容易に実現できる。

【００２５】といった効果が得られる。

【００２６】第５に、データ完全性保証機能を併用する
ことで、データの改竄に対する耐性を強固にでき、一層
のセキュリティを確保できるようになる。

【００２７】従って、本発明によれば、ネットワークを
介して情報を授受するに当たり、簡易且つ有効なセキュ
リティを確保できるようにしたセキュア通信方法を提供
できる。

【００２８】また、更には本発明は、鍵管理サーバから
相互通信する各エンティティに対して与える同一の秘密
鍵情報（相互に共有する秘密鍵情報（セッション鍵））
は、送るべき秘密情報を２番目の受け手の秘密鍵で暗号
化した第１の結果と、当該第１の結果についてハッシュ
関数処理して得た結果を再度、第２の受け手の秘密鍵で
暗号化した第２の結果とを、結合したものに、さらに、
第１の受け手の秘密鍵で送るべき秘密情報を暗号化した
第３の結果を付加し、且つ、これら第１乃至第３の結果
に対してハッシュ関数処理して得た結果を前記第１の受
け手の秘密鍵で暗号化してなる第４の結果を結合した構
成とする。

【００２９】このようなセッション鍵フォーマットを用
いることにより、その時点で伝送路が開設されている片
方に鍵情報を送るようにすることで、安全にデータを送
ることができるようになり、また、どのようなネットワ
ークの経路であっても、関係するエンティティに対して
は、一つに鍵を送れば全てに安全にデータを送ることが
できるようになる。

【００３０】また、鍵管理サーバから相互通信する各エ
ンティティに対して与える同一の秘密鍵情報は、有効期
限を定めて管理する。特に、有効期限内で一時的に発生
させて利用するものとする。

【００３１】このように、有効期限を定めて管理する
と、有効期限を短く設定すれば、有効期限内での利用に
おけるセキュリティはの保証はより確実なものとなり、
また、一時的に発生させて使用するものであるから、一
層、安全度の高いセキュア通信方法が確立できる。

【００３２】また、鍵管理サーバから相互通信する各エ
ンティティに対して与える同一の秘密鍵情報（セッショ
ン鍵またはその種）は、有効期限および管理期限が定め
られており、管理期限内で利用可能であることを特徴と
する。

【００３３】この場合、“保管期限”は“使用期限”と
同期限とすることもできるが、“保管期限”を“使用期
限”より長く設定しておくことで、過去の秘密情報に対
してもデータの永続性が保たれるメリットがある。すな
わち、“保管期限”内であれば、“使用期限”が切れて
いてもその期限切れのセッション鍵を使用することが可
能であり、管理期限内の利用であれば、その期限切れの
セッション鍵の配布を受けていたエンティティはそのセ
ッション鍵を使用して暗号を解くことができるので、暗
号化された過去の情報があってそれを参照したい場合な
どに活用できる。

【００３４】また、鍵管理サーバから相互通信する各エ
ンティティに対して与える同一の秘密鍵情報（セッショ
ン鍵またはその種）は、一つでも良いが、複数種とする
こともできる。

【００３５】このように複数のセッション鍵（またはそ
の種）を用いる方式を採用すると、現在の鍵の有効期限
に制限されることなく、新しい鍵を作成して使用できる
ことから、ある期間内に通信が継続されることが見込ま
れるときに、現在の鍵の有効期限に左右されることな
く、通信を継続できるようになり、しかも、セキュアな
通信が保証できる環境を提供できるようになる。

【００３６】

【発明の実施の形態】暗号化技術には鍵を利用するが、
この鍵には公開鍵を用いた暗号化技術と対称鍵を用いた
暗号化技術とがある。そして、暗号化技術を通信システ
ムへ適用に際し、最も考慮すべき点は鍵管理であり、こ
れは公開鍵暗号化技術を選択するか対称鍵暗号化技術を
選択するかにより大きく異なる。

【００３７】前者は鍵管理の簡便性及び署名・検証の一
意性の点で優れているが、これはサーバ側で管理する各
クライアント側の公開鍵及び公開鍵を署名する秘密健が
改竃・漏洩されない認証局（ＣＡ局）があることを前提
とした上のことである。もしも認証局の信頼性が担保で
きない場合、対称鍵暗号システムの信頼局(ＴＴＰ局)と
同様、認証局での障害は全クライアント側に被害が拡大
する。

【００３８】また、署名の一意性に関しては対称鍵暗号
化技術の方が優れている。対称鍵暗号系は信頼点(認証
局)と各クライアント間での暗号化プロトコルを利用す
る署名方式では一意性の保証ができる。

【００３９】従って、両者を比較してみると両者の技術
上の差は無いと言える。しかし、対称鍵暗号系では、処
理の高速性、安全性の面で今後大きなアドバンテージが
期待できる。従って、本発明では公開鍵を一切使用せ
ず、対称鍵暗号化技術を採用するようにした。対称鍵暗
号化技術を使用することにより、処理スピードの高速化
が期待でき、安全性も高い。

【００４０】医療関係情報には患者のカルテや診断画
像、検査データ等も対象とほか、これらの情報を通信ネ
ットワークを用いて伝送することとなるので、データの
改竄防止や個人のプライバシーを保証できるシステムで
ある必要があり、また、なりすましを含めた不正侵入を
防止できるシステムでなければならない。

【００４１】このような目的から、本願出願人が主体と
なって標準化のための策定を進め、既に公開した通信規
約に統合型セキュア通信方式（ＩＳＣＬ：Integrated S
ecure Communication Layer）がある。

【００４２】このＩＳＣＬは、一般公衆回線上で秘密通
信路を確保するための通信規約であるが、セキュリティ
の基礎には、共有秘密鍵による対称型暗号方式を採用し
ている。この対称型暗号方式では、秘密通信の開始に先
だって通信者同士は秘密鍵を共有しておく必要がある。

【００４３】そして、そのために、ＩＳＣＬのバージョ
ン1.0（V1.0）においては、加入者全員に共通の共有秘
密鍵を格納したセキュアモジュール（ＩＣカード等）を
持ち合うことで対応させるようにしていたのを、更に一
歩進めて、[ｉ]加入者ＩＤに基づく個別秘密鍵の生成
と、[ii]通信希望者間に張られる通信路上で一時的に利
用されるセッション鍵の配布、の２つの機能を有する
「鍵管理サーバ」と呼ばれる信頼点（ＴＴＰ）を仮定し
たプロトコルを採用する。

【００４４】以下、詳細を説明する。

【００４５】図１は、本システムの構成例を示す概念図
であって、診療機関内などにあるＣＴ（コンピュータト
モグラフィ）装置Ｃｌｎ-1や超音波診断装置Ｃｌｎ、診
断画像を収集保管しておく画像サーバＣｌ２、ワークス
テーションＣｌ３などが、医療用に開発された国際標準
のネットワークであるＤＩＣＯＭネットワークＮＷ１に
接続されたシステムがあり、このネットワークＮＷ１は
公衆網ＮＷ２に接続されている。Ｃｌ１は公衆網ＮＷ２
に接続されたパソコンなどのインテリジェント端末であ
る。また、ＤＩＣＯＭネットワークＮＷ１には鍵管理サ
ーバＳが接続されている。

【００４６】鍵管理サーバＳは、ある限られたネットワ
ーク内におけるＴＴＰ（対称鍵暗号システムの信頼局）
として、ネットワーク内の全エンティティ（実体）Ｃｌ
１，〜Ｃｌｎそれぞれにおけるある秘密情報を予め有し
ており、それを用いて任意エンティティＣｌｍ（ｍ＝
１，２，３，４，…）の秘密鍵を生成することができる
構成としてある。秘密鍵は５６［ｂｉｔ］〜１６８［ｂ
ｉｔ］程度の容量の暗号化鍵としてあり、公開鍵の場合
の１０２４［ｂｉｔ］と比べて大幅に容量を小さくして
ある。尚、各エンティティＣｌ１，〜Ｃｌｎの秘密鍵を
知り得る、或は生成できるのは、当該エンティティＣｌ
１，〜Ｃｌｎと鍵管理サーバＳのみである。

【００４７】本発明の特徴は、秘密の情報を以て認証し
合う方式であり、有効期間を設定した秘密情報を一時的
に生成し、通信しようとするエンティティ間で共有して
認証に用いる。

【００４８】本発明においては、鍵管理サーバＳを含
め、各エンティティＣｌ１，〜Ｃｌｎは、医療・保険分
野でのＩＴ（Information Technology；情報技術）化推
進要求に円滑に応え得る通信層セキュリティ方式として
のＩＳＣＬ V2.0方式を基本とするものであり、当該方
式の各種セキュリティ構成要素及び方式選定方法を説明
する。

【００４９】ここでは、暗号化技術として対称鍵暗号化
技術を採用している。

【００５０】＜ＩＳＣＬの認証方式とセキュア通信路の
確保＞ここで説明するＩＳＣＬでは２つのエンティティ
（実体）間における相互認証を、“秘密情報の共有の確
認を以て成立する”、と云う立場をとるようにしてい
る。秘密情報から適宜なる対称型暗号方式（Ｆとする）
の鍵（Ｋとする）を生成し（秘密情報そのものが鍵であ
る場合もある）、双方向でチャレンジ・アンド・レスポ
ンスを繰り返す３パス４ウェイ方式と呼ばれるプロトコ
ルにより、鍵Ｋの共有を確認し合うようにする。

【００５１】鍵Ｋの共有を確認し合った２つのエンティ
ティ（実体）は、以後、対称型暗号方式Ｆ、鍵Ｋによる
暗号化情報を交換する。このことで、原理的に、セキュ
ア通信路を確保することができる。

【００５２】対称鍵暗号化技術を採用することにより、
以下のことが期待できる。

【００５３】［１］ 各クライアントの個別鍵生成は、
各クライアントのＩＤ情報を鍵管理サーバＳのマスタ鍵
で暗号化して得る方式であるから、各クライアントの個
別鍵を高速で生成可能である。しかも、対称鍵暗号化を
用いるので、生成鍵の長さは５６［ｂｉｔ］〜１６８
［ｂｉｔ］と短くて済み、従って、通信量オーバヘッド
は小さく、暗号化処理に必要な演算量も少なくて済む。

【００５４】［２］ ＩＤベース鍵管理の活用により、
クライアント側の個別鍵はクライアントＩＤ情報から回
復可能である。

【００５５】［３］ 対称鍵暗号系でのプロトコル攻撃
はReplay攻撃が主であり、セッション番号Ｎまたは時刻
情報を平文(セッション鍵情報含む)に付加すれば対処は
十分である。

【００５６】［４］ ローカルなセキュア通信網が簡易
な鍵管理サーバで容易に実現できる。

【００５７】＜ＩＳＣＬの認証方式とセキュア通信路の
確保＞ＩＳＣＬでは２つのエンティティ（実体）間にお
ける相互認証を、“秘密情報の共有の確認を以て成立す
る”、と云う立場をとるようにしている。秘密情報から
適宜なる対称型暗号方式（Ｆとする）の鍵（Ｋとする）
を生成し（秘密情報そのものが鍵である場合もある）、
双方向でチャレンジ・アンド・レスポンスを繰り返す３
パス４ウェイ方式と称するプロトコルによって鍵Ｋの共
有を確認し合うようにするのである。

【００５８】鍵Ｋの共有を確認し合った両者は、以後対
称型暗号方式Ｆ、鍵Ｋによる暗号化情報を交換すること
で、原理的に、セキュア通信路を確保することができ
る。

【００５９】本発明の特徴は、秘密の情報を以て認証し
合う方式であり、有効期間を設定した秘密情報を一時的
に生成し、共有して認証に用いる。

【００６０】この秘密の情報を生成するのが鍵管理サー
バＳであり、鍵管理サーバＳは、ある限られたネットワ
ーク内におけるＴＴＰ（対称鍵暗号システムの信頼局）
として、ネットワーク内の全エンティティそれぞれにお
けるある秘密情報を予め有しており、それを用いて任意
エンティティの秘密鍵を生成することができる構成とし
てある。５６［ｂｉｔ］〜１６８［ｂｉｔ］程度として
あり、公開鍵の場合の１０２４［ｂｉｔ］と比べて大幅
に容量を小さくしてある。

【００６１】尚、各エンティティの秘密鍵を知り得る、
或は生成できるのは、当該エンティティと鍵管理サーバ
のみである。

【００６２】具体的には、図２に示す如きである。図２
はＩＳＣＬ Ｖ２．０のクライアント／サーバ鍵管理モ
デルを示す。この運用において、各クライアントＣｌ
Ａ，ＣｌＢは自身のＩＤ情報を信頼点である鍵管理サー
バＳへ予め登録しておき、各クライアントＣｌＡ，Ｃｌ
Ｂには鍵管理サーバＳより個別鍵Ｋａ，Ｋｂを安全な手
段（例えば、ＩＣカード、ＰＣカード等のセキュアモジ
ュールに鍵を格納)で配付するようにする。

【００６３】鍵管理サーバＳは、各クライアントＣｌ
Ａ，ＣｌＢのＩＤ情報を予め登録しておくＩＤ登録簿Ｉ
Ｄｆと、マスタ鍵ＫＭを持ち、また、セッション鍵（ま
たは種）鍵ｋｓをある有効期間にわたり保管するための
保管部Ｓｔを持つ。

【００６４】尚、各クライアントＣｌＡ，ＣｌＢの個別
鍵Ｋａ，Ｋｂは鍵管理サーバＳが発行するが、これは鍵
管理サーバＳの持つＩＤ登録簿ＩＤｆに予め登録されて
いる各クライアントＣｌＡ，ＣｌＢのＩＤ情報を、鍵管
理サーバＳの持つマスタ鍵ＫＭを使用して鍵管理サーバ
Ｓが変換(暗号化)することにより取得するようにしてあ
る。

【００６５】また、各クライアントＣｌＡ，ＣｌＢは配
付された各個別鍵Ｋａ，Ｋｂを用いてクライアント／サ
ーバ間の認証を行うようにしてある。

【００６６】このような構成の本システムの作用を説明
する。

【００６７】鍵管理サーバＳと個別エンティティＣｌ
１，〜Ｃｌｎは、当該エンティティＣｌ１，〜Ｃｌｎの
秘密情報の共有を以て双方を認証し合い、セキュアな通
信路を確保することができる。

【００６８】この前提のもと、ネットワーク上のある任
意の２個のエンティティ（例えば、クライアント（端
末））Ｃｌ1，Ｃｌ2が秘密通信を行うに当たって、２エ
ンティティＣｌ１，Ｃｌ２の双方もしくは一方の求めに
応じて、２エンティティＣｌ１，Ｃｌ２と鍵管理サーバ
Ｓの３者のみが知ることとなる秘密情報（すなわち、セ
ッション鍵（またはその種）ｋｓ）を有効期限限定で一
時的に生成し、エンティティＣｌ１，Ｃｌ２と鍵管理サ
ーバＳ間に張られたセキュアな通信路を用いて配送する
ことが、鍵管理サーバＳの役割である。

【００６９】すなわち、ネットワーク上のある任意の２
個のエンティティＣｌ1，Ｃｌ2間での通信の要求がある
と、まず両者と鍵管理サーバＳの間で相互認証が行われ
る。

【００７０】＜相互認証機能＞エンティティ（クライア
ントＡ）Ｃｌ１及び鍵管理サーバＳ間の相互認証プロト
コル例を図３に示す。この認証は、通信セッションを張
る際に二者間でエンティティＣｌ1の個別鍵である個別
鍵Ｋａを共有して行う。すなわち、エンティティＣｌ1
から鍵管理サーバＳに対して相互認証の要求をする。す
ると、鍵管理サーバＳは乱数ｒ１を発生し、エンティテ
ィＣｌ1に送る。

【００７１】これを受けてエンティティＣｌ1はこの乱
数ｒ１を自己の持つ個別鍵Ｋａを用いて所定のアルゴリ
ズムに従い変換処理（すなわち、暗号化処理）する。こ
れが変換乱数ＥＫａ（ｒ１）である。また、エンティテ
ィＣｌ1は乱数ｒ２を発生してこの乱数ｒ２と変換処理
したＥＫａ（ｒ１）と鍵管理サーバＳに伝送する。鍵管
理サーバＳではこのエンティティＣｌ1から受けた乱数
ｒ２と変換乱数ＥＫａ（ｒ１）とを用い、ＥＫａ（ｒ
１）を逆変換処理（すなわち、復号化処理）することで
自己の発行した乱数ｒ１を抽出して自己が発行した乱数
ｒ１と照合し、合っていれば所定のアルゴリズムに従
い、エンティティＣｌ１の個別鍵Ｋａを用いてｒ２を変
換処理して変換乱数ＥＫａ（ｒ２）を得、これをエンテ
ィティＣｌ1に送る。

【００７２】エンティティＣｌ1では、鍵管理サーバＳ
から受けた変換乱数ＥＫａ（ｒ２）を逆変換処理してｒ
２を得、これと自己の発行した乱数ｒ２とを照合し、合
っていれば正しいと認証する。このような認証をエンテ
ィティＣｌ２においても行うことで、エンティティＣｌ
１，Ｃｌ２は鍵管理サーバＳにて管理されている正規の
相手先であることを認証する。

【００７３】この機能は第三者からの通信妨害を早期に
検出するために採用した。

【００７４】尚、クライアント間での認証は、セッショ
ン鍵（または種）ｋｓを共有して行う。

【００７５】本システムでは、データ完全性保証する機
能として、次の如きデータ完全性保証機能を併用する。

【００７６】すなわち、本システムでは、認証やデータ
授受に際してつぎのような手法を併用することにより、
データ完全性を保証している。本システムで用いるデー
タ完全性保証機能は、送り側が署名処理し、受け手側が
検証処理を行うもので、この機能は二者間又は三者間で
セッション鍵ｋｓの配送又はデータ転送を行う際、第三
者又はクライアント中継者からの改竄行為を検出するた
めに採用した。

【００７７】＜データ完全性保証機能＞すなわち、本発
明では秘密鍵であるセッション鍵ｋｓを用いた対称鍵暗
号化処理による送信データの暗号化の他、データ完全性
補償機能のためのデータを付加して送信する。もちろ
ん、データ完全性補償機能のためのデータは送信データ
の特定位置等に配置し、纏めて対称鍵暗号化処理して伝
送し、受け手側で暗号化を解いた後、復号化された送信
データ中から当該データ完全性補償機能のためのデータ
を抽出してデータ完全性補償機能のために利用する構成
とすることもできる。

【００７８】データ完全性保証機能のデータは、図４の
ようにして得る。図４に示すように、伝送すべきデータ
をハッシュ（Ｈａｓｈ）関数で処理する。このハッシュ
関数とは、可逆処理のできない一方向性関数であり、こ
のハッシュ関数で処理されたデータとの排他的論理和
（ＥＯＲ）処理をし、それをハッシュ関数で処理してハ
ッシュ値を得、これを鍵で暗号化処理してＭＡＣ（メッ
セージ認証子）データ（通信途上で改変やエラーが起こ
っていないこと（データ完全性）を検査するためのも
の）得（すなわち、署名処理）、このＭＡＣデータを相
手方に伝送すると共に、相手方では、受信した暗号化デ
ータを復号して得たデータを入力データとして上記と同
じ処理をしてＭＡＣデータを得、相手から受信した前記
のＭＡＣデータと比較照合して一致していれば正（ye
s）、不一致ならば誤（no）の判定をすることで検証し
ている。

【００７９】図４において、Ｈａｓｈ関数を用いたのは
ＤＥＳ（Data Encryption Standard；データ暗号化標
準）や、ＡＥＳ（Advanced Encryption Standard：NIST
（米商務省標準技術局）がＤＥＳの次世代の国際標準暗
号と位置づけている、手順公開型の共通鍵暗号化）の場
合、鍵はシステム共通パラメータを用いており、終段の
暗号化処理はハッシュ値ＨＣの鍵の乗せ替えを容易にす
るため、採用した。

【００８０】＜秘密情報（セッション鍵）の生成＞相互
認証が終わると、鍵管理サーバＳは、２エンティティＣ
ｌ１，Ｃｌ２の双方もしくは一方の求めに応じて、２エ
ンティティＣｌ１，Ｃｌ２と鍵管理サーバＳの３者のみ
が知ることとなる秘密情報（すなわち、セッション鍵
（またはその種）ｋｓ）を有効期限限定で一時的に生成
する。

【００８１】そして、この生成した秘密情報を２エンテ
ィティＣｌ１，Ｃｌ２に配信すると共に、保管部Ｓｔに
この生成した秘密情報（セッション（シード）鍵ｋｓ）
を保管する。

【００８２】２エンティティＣｌ１，Ｃｌ２において
は、こうして鍵管理サーバＳから配信された共有の秘密
情報を基礎に、互いの認証を行うと共に、セッション鍵
（またはその種）ｋｓの共有によって、セキュアな通信
路を確立することができる。すなわち、セッション鍵ｋ
ｓを暗号化鍵としてデータを暗号化し、伝送するように
し、受け手側は共有のセッション鍵ｋｓを用いて暗号を
解くようにすることで、セキュアな通信路による通信を
確保する。

【００８３】本システムで用いるセッション鍵ｋｓを特
徴付ける情報は、例えば、以下の６種である。

【００８４】すなわち、“ｉｄ１（クライアントＣｌ１
のＩＤ情報）”、“ｉｄ２（クライアントＣｌ２のＩＤ
情報）”、“セッション鍵ｋｓ本体”、“鍵番号（ｋi
d）”、“使用期限（Ｔ）”、“保管期限（ＫＩ）”の
計６種である。

【００８５】これらのうち、“使用期限（Ｔ）”は、鍵
管理サーバがエンティティに推奨するセッション鍵ｋｓ
の使用期限であり、ここで定めた期限を越えて使用する
場合のリスク担保は、ユーザ側の責任となる。“保管期
限”は、鍵管理サーバがセッション鍵ｋｓを保管してお
く期限である。

【００８６】“保管期限”は“使用期限”と同期限とす
ることもできるが、“保管期限”を“使用期限”より長
く設定しておくことで、過去の秘密情報に対してもデー
タの永続性が保たれるメリットがある。すなわち、“保
管期限”内であれば、“使用期限”が切れていてもその
期限切れのセッション鍵を使用することが可能であり、
管理期限内の利用であれば、その期限切れのセッション
鍵の配布を受けていたエンティティはそのセッション鍵
を使用して暗号を解くことができるので、暗号化された
過去の情報があってそれを参照したい場合などに活用で
きる。なお、セッション鍵は“有効期限”内のみ、使用
可能に運用することも可能である。

【００８７】鍵管理サーバＳは、エンティティＣｌ１，
Ｃｌ２の要求に応じて鍵保管部Ｓｔに保管中の鍵を配送
する。本発明のシステムでは、基本的には２エンティテ
ィＣｌ１，Ｃｌ２の間では、ある期間に亘ってセッショ
ン鍵ｋｓが有効であり続けるが、一方の意思によって、
新たなセッション鍵の配布が行われることもある。この
ときは、鍵管理サーバＳの鍵保管部Ｓｔには、当該２者
間の保管期限内の複数のセッション鍵が存在することに
なる。

【００８８】例えば、図５に示す例では、セッション鍵
としてｋ１が生成された後に、セッション鍵ｋ２が生成
され、そしてその後にセッション鍵ｋｓとして第３の新
たなセッション鍵ｋ３が生成配布された時点では、鍵管
理サーバＳにおける鍵保管庫である鍵保管部Ｓｔには３
個の鍵ｋ１，〜ｋ３が保管されている。また、セッショ
ン鍵ｋ１とｋ２の使用期間が重複している期間では、発
生した鍵配送要求に対して、セッション鍵ｋ２が選ばれ
る、と云った具合に、有効なセッション鍵の中から一方
のエンティティの意思によって、所望のセッション鍵の
配布が行われることもある。

【００８９】このような複数のセッション鍵を用いる方
式を採用すると、現在の鍵の有効期限に制限されること
なく、新しい鍵を作成して使用できることから、ある期
間内に通信が継続されることが見込まれるときに、現在
の鍵の有効期限に左右されることなく、通信を継続でき
るようになり、しかも、セキュアな通信が保証できるメ
リットがある。

【００９０】本システムでは、２つのエンティティ間に
おける相互認証を、互いに同じ秘密情報（セッション
鍵）を持っていることを確認し合うことで行う。すなわ
ち、対称型暗号化方式（Ｆ）用の鍵（Ｋ）を生成し（ｋ
ｓそのものでも良い）、双方向でチャレンジ・アンド・
レスポンスを繰り返す３パス４ウエイ方式のプロトコル
により、Ｋの共有を確認することで相互認証する。

【００９１】相互認証を済ませた後は、以後、対称型暗
号化方式（Ｆ）とそれに用いる鍵（Ｋ）により暗号化し
た情報を交換する形態をとることでセキュアな通信路を
確立する。

【００９２】＜鍵配送パターンと配送プロトコル＞鍵配
送は、配送要求エンティティの数とセキュアな通信を希
望するエンティティの通信方向により、図６のような３
通りの配送パタンが存在し得る。（ａ）は鍵管理サーバ
ＳとエンティティＡ，Ｂが共に繋がっていていずれにも
配信可能な構成であり、（ｂ）は鍵管理サーバＳはエン
ティティＡとは繋がっているが、エンティティＢとは繋
がっておらず、エンティティＡとエンティティＢ間は繋
がっている構成であり、（ｃ）鍵管理サーバＳとエンテ
ィティＢは繋がっているがエンティティＡには繋がって
おらず、エンティティＢとエンティティＡは繋がってい
るという形態である。

【００９３】どのパタンの場合も、鍵管理サーバからエ
ンティティに送られるセッション鍵情報は、次のような
ものである。ただし、この例はクライアントＣｌ1へ送
られる場合を示している。

【００９４】 {F(k1,ks｜付帯情報｜id2),F(k2,ks｜付帯情報｜id1)F(k2,HC)}F(k1,HC') … （１） ここで、“k1”、“k2”は、それぞれCl1、Cl2の秘密
鍵、“ks”は配送セッション鍵、“付帯情報”は、配送
セッション鍵ksの固有番号や有効期限等、“HC”は、F
(k2,ks｜付帯情報｜id1)に対する伝達情報認証子（HAS
H）、“HC′”は、{F(k1,ks｜付帯情報｜id2),F(k2,ks
｜付帯情報｜id1)F(k2,HC)}に対する情報認証子である
（Cl2への場合は、１と２が交換）。

【００９５】上記式（１）はセッション鍵のフォーマッ
トを示しており、この式の持つ意味は、“送るべき秘密
情報を２番目の受け手の秘密鍵で暗号化したもの”と、
“その暗号化の結果のハッシュ（HASH）処理結果を再
度、受け手（第１の受け手）の秘密鍵で暗号化もの”と
を、結合したものに、さらに“もう一方の受け手（第２
の受け手）の秘密鍵で送るべき秘密情報を暗号化したも
の”を付加し、“その全体のハッシュ処理結果をもう一
方の受け手（第２の受け手）の秘密鍵で暗号化処理した
ものを結合したもの”とする、というものである。

【００９６】そして、このセッション鍵フォーマットを
用いることで、［ｉ］その時点で伝送路が開設されてい
る片方に鍵情報を送ることで安全にデータを送ることが
できる（配送パタン２，３）、［ii］どういうネットワ
ークの経路であっても関係するエンティティに対して一
つに鍵を送れば全部に安全にデータを送ることができ
る、といったメリットが得られる。

【００９７】パタン１（図６の（ａ））の場合の鍵配送
スケジュールは図７に示す如きのダイヤグラムに従うの
が標準的である。

【００９８】すなわち、図７において、エンティティと
してのクライアントＣｌ１から鍵管理サーバＳにＣｌ２
との間の通信要求があると、鍵管理サーバＳにおいてセ
ッション鍵ｋｓが生成され、そのセッション鍵ｋｓのＩ
Ｄ情報であるｋｉｄと有効期間Ｔの情報を含めてＣｌ１
とＣｌ２を指定した（すなわち、Ｃｌ１のＩＤ情報であ
るｉｄ１とＣｌ２のＩＤ情報であるｉｄ２を含んだ）リ
クエストＲｅｑ１がＣｌ１に送られて、Ｃｌ１と鍵管理
サーバＳとの通信処理が開始される。そして、Ｃｌ１は
これを受けてこのれら情報のうち、ｉｄ１とｋｉｄおよ
び有効期間Ｔの情報を含んだリクエストＲｅｑ２をＣｌ
２に送り、さらにＣｌ２はこれを受けてこの中のｉｄ１
とｉｄ２およびｋｉｄの情報とを含んだリクエストＲｅ
ｑ３を鍵管理サーバＳに送る。鍵管理サーバＳはこれを
受けて、鍵検索しどのセッション鍵かを調べる。そし
て、見付けたセッション鍵ｋｓとその鍵の有効期間Ｔの
情報とをＣｌ２に送り、これを受けたＣｌ２からの肯定
応答Ａｃｋを待ってＣｌ１は鍵配送完了を知る。

【００９９】このようなダイヤグラムに則ってセッショ
ン鍵ｋｓの配送を受けた後、セッション鍵ｋｓの共有を
根拠としてクライアントＣｌ１とクライアントＣｌ２の
間で認証処理が行われる。認証処理が済んだ後はｋｓを
用いて対称型暗号化方式（Ｆ）によりデータを暗号化し
てＣｌ２とデータの授受をする。

【０１００】また、この図において、有効期限Ｔ内のセ
ッション鍵ｋｓが既に配布されていることが既知の場合
には、リクエストＲｅｑ１、Ｒｅｑ３（及びそれらの回
答）の交換は省略され、リクエストＲｅｑ２及び肯定応
答Ａｃｋのみを交わし、直接、クライアントＣｌ１とク
ライアントＣｌ２の認証処理が行われてもよい。

【０１０１】鍵配送スケジュールを含むプロトコル全系
は図９のようなブロック構成になる。

【０１０２】“Ｃｌ１と鍵管理サーバＳとの通信開始処
理”、そして次に“Ｃｌ１と鍵管理サーバＳとの認証処
理”、次に“Ｃｌ１によるｋｓの要求”、次に“鍵管理
サーバＳによるｋｓの生成と保管”、次に“Ｃｌ１に対
するｋｓの配送”、次に“Ｃｌ１とＣｌ２の通信開始処
理”、次に“Ｃｌ２と鍵管理サーバＳとの認証処理（ｋ
２）”、次に“Ｃｌ２によるｋｓ要求”、次に“Ｃｌ２
に対するｋｓの配送”、そして、次に“Ｃｌ１とＣｌ２
の認証処理（ｋｓ）”、これで認証が終わる。尚、
（ ）内は認証の基礎となる共有情報を示す。

【０１０３】上記ブロック中、認証処理が正常に終了し
たあとは、それぞれに以降の通信はセキュアな通信が行
われる。“Ｃｌ１とＣｌ２間のセキュア通信”の段階に
入る。このような手順を踏んでＣｌ１とＣｌ２間の通信
が開始される。

【０１０４】ＩＳＣＬの階層概念を図８（ａ）に示す。
図８（ａ）に示すように、ＩＳＣＬは上層のアプリケー
ション層と下層の物理層の間に存在する。物理層にはＩ
ＣカードやＰＣカードがあり、それらのリーダ／ライ
タ、そしてインタフェースを介してＩＳＣＬとリンクす
る。通信層側はイーサネット（登録商標）、ＴＣＰ／Ｉ
Ｐ、インタフェースがあり、これらを介して通信を行う
ことができる。すなわち、物理層通信層を介してアプリ
ケーションは情報を授受してその情報を処理するが、そ
の間に本発明のＩＳＣＬが介在しており、このＩＳＣＬ
を介在させることにより通信を行おうとするエンティテ
ィと鍵管理サーバＳとの通信により認証を受け、その
後、処理上述した有効期間Ｔを持つ秘密鍵としてのセッ
ション鍵をネットワークＮＷ上の鍵管理サーバＳにて発
行して貰い、通信を行おうとするエンティティ間で当該
秘密鍵としてのセッション鍵を共有していることを以て
エンティティ間の相互認証を行い、正当と判断された場
合に、相互認証時に授受した有効期間Ｔ付き鍵（セッシ
ョン鍵）を利用した対称型暗号化処理によるセキュアな
通信路を確保する。

【０１０５】対称鍵暗号化技術を採用することにより、
以下のことが期待できる。

【０１０６】第１には、各クライアント（エンティテ
ィ）のＩＤ情報と鍵管理サーバＳのマスタ鍵用いて暗号
化して各クライアントの個別鍵を生成するので個別鍵の
高速生成可能である。そして、対称鍵暗号化を用いるの
で、生成鍵の長さは５６［ｂｉｔ］〜１６８［ｂｉｔ］
と短くて済み、従って、通信量オーバヘッドは小さく、
暗号化処理に必要な演算量も少なくて済む。

【０１０７】第２には、ＩＤベースの鍵管理の活用によ
り、クライアント側の個別鍵はクライアントＩＤ情報か
ら回復可能である。従って、個別鍵を失っても回復可能
である。

【０１０８】第３には、対称鍵暗号系でのプロトコル攻
撃はReplay攻撃が主であり、セッション番号Ｎまたは時
刻情報Ｔを平文(セッション鍵情報含む)に付加すれば対
処は十分である。

【０１０９】第４に、鍵管理サーバＳを信頼点(認証局)
とすることで、信頼点と各クライアント間での暗号化プ
ロトコルを利用する署名方式は一意性の保証ができるこ
とから、ローカルなセキュア通信網が、簡易な鍵管理サ
ーバで容易に実現できる。

【０１１０】といった効果が得られる。

【０１１１】なお、ネットワークとしてインターネット
に適用する形態が考えられるが、この場合、Ｗｅｂブラ
ウザからＷｅｂサーバ内にある情報を安全にアクセスす
る必要がある。そのために、Ｗｅｂサーバへの不正アク
セスに対するセキュアな通信の確保が必要である。

【０１１２】セキュリティにかかわる鍵情報を記録した
ＩＣカードを利用すること、そして、クライアント及び
サーバにプロキシを設置することにより、セキュリティ
のあるシステムを構築できる。この場合のソフトウエア
の構成は図１２に示すように、クライアント側は上層に
Ｗｅｂブラウザ、その下にブラウザ用のプロキシ、そし
てその下層にクライアント側Ｗｅｂ用のＩＳＣＬ、そし
て、このＩＳＣＬにＩＣカードなどの物理層が繋がる。
サーバ側はＷｅｂサーバの下層にサーバ用のプロキシが
あり、その下層にサーバ側Ｗｅｂ用のＩＳＣＬがあり、
物理層として鍵管理ボックスが接続されるクライアント
側及びサーバ側のＷｅｂ用の各ＩＳＣＬはＩＳＣＬネッ
トワークＮＷに接続される。

【０１１３】このような構成で、インターネットに適用
可能なシステムが構築できる。

【０１１４】次に、本システムの通信速度を検証してお
く。

【０１１５】上述した統合型セキュリティ通信規格（Ｉ
ＳＣＬ）は、トランスポート層の上位でセキュアな通信
層を確保するための通信規約を規定している。また、Ｉ
ＳＣＬに基づくＩＳＣＬ標準ソフトウェア仕様には、な
りすましの対策として相互認証機能、データの改ざんや
盗聴の対策としてメッセージ認証及び秘匿機能などを提
供するＡＰＩ（Application Program Interface；アプ
リケーションからＯＳの各種機能を利用するための仕組
み）が設けられている。

【０１１６】従って、セキュリティの点では問題はない
が、ＩＳＣＬ規格に準拠するソフトウェアが、医療画像
など比較的にデータ量が多い医療分野に適するようにす
るためには、安全性に加えて、通信速度が確保できるか
が重要なファクタの一つとなる。そして、通信速度が確
保できない場合には実用化への妨げになりかねない。

【０１１７】以下では、ＩＳＣＬを実装する標準ソフト
ウェアの仕様と速度の面での性能、またＩＳＣＬのＤＩ
ＣＯＭ(Digital Imaging and Communications in Medic
ine)への適用について述べる。

【０１１８】ＩＳＣＬ標準ソフトウェアの仕様 ＩＳＣＬ標準ソフトウェアのＡＰＩを構成するモジュー
ルには、ＯＳ標準搭載のソケット(Windows環境（Window
sはパソコンのＯＳ名でマイクロソフト社の登録商標）
ではWinSock)を使用してＴＣＰ／ＩＰ層とのインタフェ
ースを提供する通信モジュールと、鍵の管理、認証、秘
匿機能のインターフェースを提供するセキュアアクセス
モジュールがある。また、セキュアアクセスモジュール
には、ＩＣカードに対する鍵管理や相互認証機能を提供
する認証モジュールと、メッセージの秘匿及び認証機能
を提供する暗号モジュールがある。

【０１１９】図１０はＩＳＣＬ標準ソフトウェアを構成
するモジュールを表している。現在、これらのモジュー
ルはＣ言語からスタティックにロード可能なダイナミッ
クリンクライブラリとして実装されている。

【０１２０】ＩＳＣＬ標準ソフトウェアのWindows版
は、Microsoft社のＶｉｓｕａｌ Ｃ＋＋により開発さ
れ、Microsoft Foundation Class（MFC）Libraryを使用
している。また通信セッション毎にスレッドを生成する
マルチスレッド環境で動作しているので、接続待ちある
いは受信待ちの状況でもユーザプログラムのWindowsイ
ベントをディスパッチすることでバックグラウンド動作
が可能である。

【０１２１】ＩＳＣＬ標準ソフトウェアの認証モジュー
ルはＪＩＣＳＡＰ仕様のＩＣカード使用を前提としてい
る。

【０１２２】＜ＩＳＣＬ標準ソフトウェアによる性能評
価＞ＩＳＣＬ標準ソフトウェアの動作環境としては、現
在ＵＮＩＸ（登録商標）系でＳｏｌａｒｉｓ（登録商
標） ２．５．ｘ、Windows系は95とNT4.0での動作が保
証されている。ハードウェアは、Windows ＮＴ４．
０、Intel Pentium III ５００［ＭＨz］の性能のＣＰ
Ｕと、３２［ＭＢ］以上のメモリを装着した推奨マシン
２台をピアツーピア接続し、ＬＡＮカードは１００Ｂａ
ｓｅ−ＴＸを用いた構成で実行した。

【０１２３】図１１はＩＳＣＬ標準ソフトウェアのデー
タ伝送率を測定したグラフである。ＩＳＣＬでのデータ
伝送モードには、データを暗号化して送る暗号化モー
ド、データ認証を行うデータ認証モード、暗号化やデー
タ認証を行わないノーマルモードと高速通信用に手順を
省略したスルーモードがある。図１１では夫々のデータ
送信モードの伝送率を比較するため、レファレンスとし
て、WinSockのAPI関数を直接使用した場合のデータ伝送
率を測定した。

【０１２４】ノーマルモードの伝送率は、ＩＳＣＬの通
信プロトコールが持つオーバヘッドにも拘らず、下位の
ソケット通信のみでの速度の比べて顕著な差がないこと
が判る。伝送データが小さい場合、ＯＳ側のＴＣＰ層で
の動きによっては逆転する場合も観測される。しかし、
データの暗号化や認証を行う場合には、伝送率は著しく
落ちているのが見られ、その分に対しては、高速化アル
ゴリズムの導入やハードウェアの性能の向上により改善
の余地が残っている所である。

【０１２５】実験でのデータ伝送時間には、回線接続時
にかかる相互認証時間は含まれていない。この時間に
は、主にＩＣカードをアクセスする時間分の割合が大き
く、現在東芝製のＩＣカードリーダＦＺ１３３３を使っ
た場合は、合計１．５秒程度である。

【０１２６】医療画像に関する国際規格であるＤＩＣＯ
Ｍには、ＩＳＣＬをＳＳＬと共にSecure Channelの一つ
として規定している。図８（ｂ）はＤＩＣＯＭにおける
ＩＳＣＬの位置を示していて、ＩＳＣＬはＤＩＣＯＭ
Ｕｐｐｅｒ Ｌａｙｅｒプロトコールでの下位層を占め
ている。現在幾つかの医療施設では、地域医療連携シス
テムでの医療施設間のデータ伝送あるいは、医療施設内
のオンライン電子保存にＩＳＣＬの利用が始まってい
る。本発明はこれらに有効に適用することができ、セキ
ュリティを確保して資格者に対してどこからでも安全に
必要な医用情報・保険情報を提供することができるよう
になる。

【０１２７】なお、本発明は上述した実施形態に限定さ
れるものではなく、種々変形して実施可能である。ま
た、本発明において、上記実施形態には種々の段階の発
明が含まれており、開示される複数の構成要件における
適宜な組み合わせにより種々の発明が抽出され得る。例
えば、実施形態に示される全構成要件から幾つかの構成
要件が削除されても、発明が解決しようとする課題の欄
で述べた課題の少なくとも１つが解決でき、発明の効果
の欄で述べられている効果の少なくとも１つが得られる
場合には、この構成要件が削除された構成が発明として
抽出され得る。

【０１２８】

【発明の効果】以上、詳述したように、本発明によれ
ば、個別鍵の高速生成可能であり、また、対称鍵暗号化
を用いるので、生成鍵の長さは短くて済み、従って、通
信量オーバヘッドは小さく、暗号化処理に必要な演算量
も少なくて済む他、クライアント側の個別鍵はクライア
ントＩＤ情報から回復可能であるから、個別鍵を失って
も回復可能であり、対称鍵暗号系であるから、攻撃に対
して強く強固なセキュリティを確保できる他、ローカル
なセキュア通信網が、簡易な鍵管理サーバで容易に実現
できるといった効果が得られる。

【図面の簡単な説明】

【図１】本発明を説明するための図であって、本発明を
適用するシステムの構成例を説明するための図である。

【図２】本発明を説明するための図であって、本発明を
適用するＩＳＣＬ Ｖ２．０のクライアント／サーバ鍵
管理モデルを説明するための図である。

【図３】本発明を説明するための図であって、本発明に
おけるエンティティ（クライアントＡ）Ｃｌ１及び鍵管
理サーバＳ間の相互認証プロトコル例を説明するための
図である。

【図４】本発明を説明するための図であって、本発明で
用いるデータ完全性保証機能の処理例を説明するための
図である。

【図５】本発明を説明するための図である。

【図６】本発明を説明するための図であって、鍵配送パ
タンを説明するための図である。

【図７】本発明を説明するための図である。

【図８】本発明を説明するための図であって、本発明に
おけるＩＳＣＬの階層概念図である。

【図９】本発明を説明するための図であって、本発明し
すてむにおける鍵配送スケジュールを含むプロトコル全
系を説明するための図である。

【図１０】本発明を説明するための図であって、本発明
システムにおけるＩＳＣＬ標準ソフトウェアを構成する
モジュールを表した図である。

【図１１】本発明を説明するための図であって、本発明
システムにおけるＩＳＣＬ標準ソフトウェアのデータ伝
送率を測定したグラフである。

【図１２】本発明を説明するための図であって、本発明
をＷｅｂに適用する場合のソフトウエア構成例を示す図
である。

【符号の説明】

Ｃｌ１，Ｃｌ２，〜Ｃｌｎ…エンティティ（クライアン
ト） Ｓ…鍵管理サーバ ＮＷ１，ＮＷ２…ネットワーク Ｓｔ…鍵保管部 ｋｓ…セッション鍵（またはその種） Ｋａ，Ｋｂ…個別鍵 ＫＭ…マスタ鍵

───────────────────────────────────────────────────── フロントページの続き Ｆターム(参考） 5B017 AA08 BA07 CA16 5J104 AA01 AA09 AA18 AA41 EA01 EA06 EA26 JA03 KA01 KA04 KA06 KA21 LA01 LA06 MA06 NA03 NA11 NA12 NA35 NA36 NA37 NA38 NA41

Claims (9)

【特許請求の範囲】
1. 【請求項１】登録されたエンティティの認証を行うと共
   に、秘密鍵情報を発生する鍵管理サーバを用い、エンテ
   ィティの認証時に、相互通信を行おうとする各エンティ
   ティに対して同一の秘密鍵情報を与え、これら相互通信
   を行おうとするエンティティ間における相互認証は、互
   いに同一秘密鍵情報の所持を確認することで行い、相互
   認証完了後は、相互通信を行おうとするエンティティ間
   で授受するデータを前記秘密鍵情報を用いて対称型暗号
   化方式により暗号化して伝送するようにしたことを特徴
   とするセキュア通信方法。
2. 【請求項２】各エンティティのＩＤ情報をマスタ鍵によ
   り処理して生成した各エンティティの個別鍵をそれぞれ
   対応するエンティティに保持させると共に、 鍵管理サーバを設けて、ここに登録された各エンティテ
   ィのＩＤ情報を保持させ、エンティティ間での通信要求
   があると鍵管理サーバには第１の乱数を発生させ、 通信要求のあったエンティティにはこの第１の乱数を用
   いてエンティティ側で個別鍵により変換処理させて、ま
   た、自己の発生させた第２の乱数とともに鍵管理サーバ
   に伝送させると共に、 鍵管理サーバにはこれを受け取るとエンティティ側で発
   生させた第２の乱数とともに受け取って再変換処理し、
   元の第１の乱数を再生して前記発生した第１の乱数と照
   合し、第２の乱数をそのエンティティの個別鍵で変換処
   理させて当該エンティティに伝送し、 エンティティ側で再変換処理して第２の乱数を再生し、
   元の第２の乱数と照合することにより鍵管理サーバとエ
   ンティティ間の認証し、 鍵管理サーバとエンティティとの相互認証が終わると鍵
   管理サーバより秘密鍵情報を有効期限限定で生成し、こ
   の生成した秘密鍵情報を、通信要求のあった対象のエン
   ティティそれぞれに配信し、 この秘密鍵情報を得た通信要求のあるエンティティ相互
   間においては、この秘密鍵情報の共有を以て、互いの認
   証を行うようにし、 以後のこれらエンティティ相互の通信はこの秘密鍵情報
   を暗号化処理に利用することによりセキュアな通信路を
   確立することを特徴とするセキュア通信方法。
3. 【請求項３】送信側では伝送するデータをハッシュ関数
   により処理して暗号化することにより署名処理した情報
   を伝送データに付加し、受信側では受信したデータをハ
   ッシュ関数により処理して暗号化した情報と送信側で前
   記署名処理した情報とを照合し、一致の有無で伝送デー
   タの改竄を検証する検証機能を併用することを特徴とす
   る請求項１または２いずれか１項記載のセキュア通信方
   法。
4. 【請求項４】鍵管理サーバから相互通信する各エンティ
   ティに対して与える同一の秘密鍵情報は、送るべき秘密
   情報を２番目の受け手の秘密鍵で暗号化した第１の結果
   と、当該第１の結果についてハッシュ関数処理して得た
   結果を再度、第２の受け手の秘密鍵で暗号化した第２の
   結果とを、結合したものに、さらに、第１の受け手の秘
   密鍵で送るべき秘密情報を暗号化した第３の結果を付加
   し、且つ、これら第１乃至第３の結果に対してハッシュ
   関数処理して得た結果を前記第１の受け手の秘密鍵で暗
   号化してなる第４の結果を結合した構成であることを特
   徴とする請求項１または２いずれか１項に記載のセキュ
   ア通信方法。
5. 【請求項５】鍵管理サーバから相互通信する各エンティ
   ティに対して与える同一の秘密鍵情報は、一つもしくは
   複数種とすることを特徴とする請求項１乃至４いずれか
   １項に記載のセキュア通信方法。
6. 【請求項６】鍵管理サーバから相互通信する各エンティ
   ティに対して与える同一の秘密鍵情報は、有効期限が定
   められていることを特徴とする請求項１乃至５いずれか
   １項に記載のセキュア通信方法。
7. 【請求項７】鍵管理サーバから相互通信する各エンティ
   ティに対して与える同一の秘密鍵情報は、有効期限が定
   められており、有効期限内で利用可能であることを特徴
   とする請求項１乃至５いずれか１項に記載のセキュア通
   信方法。
8. 【請求項８】鍵管理サーバから相互通信する各エンティ
   ティに対して与える同一の秘密鍵情報は、有効期限が定
   められており、有効期限内で一時的に生成されて利用可
   能であることを特徴とする請求項１乃至５いずれか１項
   に記載のセキュア通信方法。
9. 【請求項９】鍵管理サーバから相互通信する各エンティ
   ティに対して与える同一の秘密鍵情報は、有効期限およ
   び管理期限が定められており、管理期限内で利用可能で
   あることを特徴とする請求項１乃至５いずれか１項に記
   載のセキュア通信方法。