公開鍵暗号系を利用した証明書の変更を考慮した管理方式の投計

マルチメディア通信と分散処理ワークショップ平成7年10月

公開鍵暗号系を利用した証明書の

変更を考慮した管理方式の設計

根井三子 佐 野 晋 日 本 電 気 株 式 会 社 ネ ッ ト ワ ー キ ン グ 技 術 研 究 所 公 開 鍵 暗 号 を 利 用 し た シ ス テ ム で は 、 信 頼 で き る 第 三 者 が 公 開 鍵 を 証 明 書 形 式にして配布することが一般的である。本稿では、このようなシステムを長期 運用する上での鎚管理に関する諸問題のうち、鍵変更に伴って証明書の変更が 生じた場合に着目し、問題点について整理するo さらに、鍵変更を考慮した証 明書の管理方式として、鍵変更時のエンテイテイの認証や証明書の履歴管理に 必要なインターフェイスについての設計を行うo 1. は じ め に コンビュータネットワーク、ことにインタ ネ ッ ト の ピ ジ ネ ス 利 用 は 急 速 に 進 み つ つ あ る。今後のピジネス利用の応用基盤として、 電子取引・デジタルキャッシュをはじめとす るエレクトロニックコマースについての技術 検討が行われる中で、ネットワーク上のアプ リケーションにおいて相手が本物であるかど うかを確認するー認証するー方式の実現はま すます重要な謀題となっている。また、認証 強化の要求と同様にエンドーエンドで通信す るデータを暗号化したいという要求も高まっ ているo 従来、ネットワーク上のアプリケーション で 相 手 を 認 証 す る 方 法 は 、 ユ ー ザ

I

D

とパス ワ ー ド の 組 で 行 わ れ て き た が 、 こ の 方 法 で は、秘密であるはずのパスワード情報がネッ ト ワ ー ク 上 を そ の ま ま 流 れ る た め 、 ネ ッ ト ワ ー ク 上 の 盗 聴 に 対 し て 弱 い こ と が 明 ら か となっているo このような問題点を解決する ために、最近注目を浴びている方式の1つと して、公開鍵暗号を利用して認涯を行う方式 があり、電子メールのセキュリテイ強化のた A Design of Key Management Methods Consid -ering Public Key Certificate's Update

Mine Sakurai. Susumu Sano Networking Systems Laboratories. N EC Corporation めのPEM(PrivacyEnhanced Mail)[2

ト

[5]等で 使われている。公開鍵暗号では、各エンティ テイ(アプリケーション、ユーザ等)が都密鍵 と公開鍵の対を持ち、公開鍵は文字通り公開 しでもよいが、各エンティティと公開鍵の組 合せが正しいことを示す必要がある。その組 合 せ の 正 し い こ と を 第 三 者 機 関 で あ る 証 明 書発行局(以下、発行局)が証明し、証明書形 式 で 配 布 す る と い う 方 法 が 提 案 さ れ て い る

(

3

]

0

現 在 、 公 開 鍵 暗 号 を 利 用 し た ア プ リ ケ ー シ ョ ン の 実 装 が い く つ か 見 ら れ るo このよ う な ア プ リ ケ ー シ ョ ン を 長 期 連 用 す る 場 合 には、各エンティテイの鍵の変更(結果とし て証明書の変更)が運用上生じる場合がある が、鍵の変更に対する影響の考察や、対応策 の検討はアプリケーション全体の観点からは 十分に行われているとはいえない。 そ こ で 本 稿 で は 、 特 に 証 明 書 の 利 用 を 前 提 とするアプリケーションにおいて、鍵変更が 生 じ た 場 合 の 問 題 点 を 洗 い 出 し 整 理 す る 。 さらに、証明書変更の処理手順を考慮しなが ら、鍵変更に対応するための機能設計につい ていくつかの提案を行うo

2

.

公開鍵証明書と発行局 本 章 で は 、 ま ず 用 語 を 定 義 し 、 発 行 局 の 機 能や階層についてまとめるo

円 。

n u

2

.

1

用語の定義 署名:認証とデータ改ざんの検出を行うため に、都密鍵と公開鍵の対のうち、秘密鍵 を用いてデータのハッシュ値を暗号化す ること。 署名の確認z署名データを(署名時に利用し た秘密鍵と対の)公開鍵で復号して得ら れるハッシュ値と、自分で計算したハッ シュ値が一致するか比較すること。 証明書:公開鍵証明書。通信相手に伝えるべ き公開鍵情報とその所有者の対応が正し いことを証明するために、信頼できる第 三者が署名したデータ

[

1

]

0

具体的な形式 を図1に示す。 発行局z証明書を発行する第三者機関

[

3

]

0

ユーザz証明書を所有するエンティティのう ち、発行局以外のアプリケーションプロ グラム(サーパ、クライアント)やユーザ を指す。 アプリケーション:証明書を利用するアプリ ケーションシステム。 配布局:任意の発行局が発行した証明書を配 布するディレクトリシステム。ユーザが 通信相手の柾明書を入手する場合、この 配布局を利用する。 パ-!Jaン・e シリアル・If S事行局.:& 隆明・の有lillllll ユーザ悶 ユーザ闘の~.・-および隠.fII. (7ルゴリズムm.およびパ';C-'， ..a腿週情・ (7.ゴリズムm.oょr1，c

，

.

.

.

.

-

，

)

..a 図 1:証明書に含まれるデータ

2

.

2

証明書発行手踊 一般的な証明書発行手順を、以下にまとめ るo前提として、発行局自体は秘密鍵と公開 鍵の対を既に持っているものとする。 i)ユーザ(図2で は ユ ー ザK)が 秘 密 鍵 と 公 開鍵の対を作成する ii)ユーザが公開鍵の証明を発行局に要求す る iu)発行局は(何らかの方法で)ユーザを認証 し、正しければユーザと公開鍵の対応に 署名を行い証明書として発行する iv)寵明書を発行局から配布局に登録する 図

2

:

証明書とアプリケーション

2

.

3

証明書の確認と発行局の階層 あるユーザの証明書から公開鍵を取り出す 場合、この公開鍵が本当にそのユーザの鍵か どうかは、発行局の公開鍵で証明書の署名を 確認することによって行う。 一般的には、発行局は図3にあるような階 層 構 造 を 取 り 、 発 行 局 の 公 開 鍵 は そ れ よ り も上位の発行局が証明する

[

3

]

。 こ の 方 法 で は、最上位の発行局の公開鍍については信用 するものとし、その公開鍵を何らかの方法で あらかじめ配布しておく必要がある。その他 の発行局の証明書は配布局等から入手する0 2.4 CRL( Certiflcate Revocation Lis

旬)

発行局は、発行した証明書について、有効 期限が切れる前に登録を破棄した証明書のリ ストを CRL(Certificate Revocation Lists)と して保存するような枠組を持っている

[

1

，

3

]

。 CRLに は 、 証 明 書 の 有 効 期 限 が 切 れ る ま で保存される。

図

3

:

発行局の階層構造 2.5 証明書変更のタイミング 証 明 書 を 利 用 す る こ と に よ っ て 、 ネ ッ ト ワーク上のシステムで必要なユーザ認証や、 秘密性の確保を容易に実現することが可能と なる(図

2

)

。

しかし、アプリケーションを長期運用する と、以下のタイミングで鍵を変更し証明書を 発行しなおす場合があるo

(

1

)

鍵を紛失した時

(

2

)

鍵 を 人 に 知 ら れ た 、 あ る い は 鍵 を 盗 ま れ た時

(

3

)

証明書の有効期限が切れた時 そこで、証明書の変更によってアプリケー ションにどのような影響や問題点があるかを 整理し解決策について考察することにする0 3. 証明書変更時の問題点 本章では、証明書変更が生じた場合の問題 点と対策方針について列挙する。 3.1 証明書変更時のプロトコルの問題 ユーザが鍵を変更する際のプロトコルは、 ユーザから発行局に対して証明書の変更要求 を出す部分と、発行局で証明書の変更処理を した結果を本人および他のユーザに通知する 部分に分かれる。 3.1.1 要求時 ユーザが発行局に対して証明書変更の要求 を行う場合、第三者が不正に発行局に対して 挺 明 書 変 更 の 要 求 を 行 う 可 能 性 が 考 え ら れ る。そこで、発行局では何らかの方法で証明 書変更の要求を行ってきたユーザの確認を行 う必要がある。

3

.

1.

2

通知時 証明書変更の通知が遅れた場合には、本人 に 通 知 が 届 く ま で に 有 効 期 限 の 切 れ た 古 い 鍵が不正に利用される可能性がある。また、 ユ ー ザ の 通 信 相 手 が そ の ユ ー ザ の 証 明 書 を キャッシュしていて、証明書の変更に気づか ない場合がある。古い鍵が不正利用された時 の被害が深刻となるようなアプリケーション では、ユーザが配布局から毎回証明書を入手 する方がよい。

3

.

2

証明書の有効期限切れ時のサービス中 断問題 送信者が鍵を利用する時には有効期限内で あったが、受信者が鍵を利用する時には有効 期限が切れていて、署名確認やデータの復号 に失敗して誤判定する可能性がある。 この問題に対する対策方針としては、以下 の方法が考えられるo

(

1

)

発信者であるユーザ

A

に再度送信を要求 する

(

2

)

証 明 書 の 有 効 期 限 前 後 の あ る 期 間 は

2

つ の証明書を利用できるようにする

(

3

)

証 明 書 の 有 効 期 限 以 前 に 早 め に 鍵 を 変 更 する

(

4

)

発信時刻を認証する 発信者がデータを送信した時間のタイムス タンプをデータ中に記録しておき、有効期限 内に鍵が利用されたことを確認する。 しかし、第三者を介さない場合では、送信 者 と 受 信 者 双 方 に と っ て 時 刻 を 偽 る こ と は 容 易 で あ り 、 時 刻 の 保 証 を 行 う の は 困 難 で ある。第三者を介す方法では、 DTS(digital tim

e

-

stamping service)等が実際に有料サーピ Aとして存在する

[

6

]

0

3.3 過去の蓄積デー舎の管理問題 直明書が変更されると、古い鍵を利用した 暗号化データが読めなくなったり、認証情報 (署名データ)が確認できなくなるという問題 が発生する。 暗 号 化 デ ー タ と 署 名 デ ー タ の 場 合 に 分 け て、問題点および対策について考察するo 3.3.1 暗号化データ 過去の暗号化データに対する要件としては 以下の2つにまとめられる。

-95-(

1

)

読めるようにする (2)できれば安全に保存する (1)のためには、暗号化データを復号して 管理するという方法でもよい。

(

2

)

のために は、暗号化した状態でデータを管理する必要 があり、復号鍵として古い秘密鑓を履歴を管 理する方法や、別の暗号化鍵で暗号化して保 存する方法が考えられる。 3.3.2 署名データ 過去の署名データに対する要件としては、 署名が正しかった、かつ改ぎんされなかった ことの保証があげられる。このためには、古 い公開鍵の管理することや署名データを碕認 できたという印を残すなどの方法が考えられ る。 しかし、鍵が無効になった後では、署名を 第三者への証拠とすることは不可能であるo 3.4 発行局のliE明書変更時の問題点 ユーザの他、発行局の鍵の対についても変 更する可能性がある。発行局の証明書を変更 すると、結果としてその発行局が今までに発 行 し た 証 明 書 は 無 効 に な る と い う 問 題 が あ る白 また、発行局の秘密鍵が漏洩したという理 由による紅明書の変更はさらに深刻で、証明 書が変更されるまでに、架空の紅明書が偽造 されたり、発行局自身の証明書が変更される 可能性があり、発行局の信頼性が失われると いう問題があるo 発行局の証明書を変更した場合は、必ずオ フライン(倒えば新聞等)やオンラインの複数 の経路を使って、証明書を変更したという通 知を全ユーザに知らせなければならない。

4

.

証明書変更方式の段計 前 章 で 述 べ た ょ っ に 、 証 明 書 を 利 用 す る アプリケーションにおいて征明書の変更が生 じた場合には様々な問題があり、アプリケー シ ョ ン の 機 能 自 体 に 大 き な 影 響 を 与 え る 可 能性がある。ここでは、特にユーザの証明書 に変更が生じた場合に必要なユーザ認証の方 法、証明書の履歴管理方法の設計について述 べるo まず、本設計を行う上での前提条件に ついてまとめ、用語の定義を行う6 4.1 前提 発行局の寵明書の配布:発行局の証明書自体 の有効期限切れについては考厳しない。 また、発行局の階層の最上位の発行局の 証明書については、あらかじめ正しく配 布されている(例えばアプリケーション のパッケージの中に最初から含まれてい る等)。 発行局の構成z発行局の階層における最上位 の発行局が複数ある状態を併すo すなわ ち、発行局の木構造が独立に複数ある状 態を許し、あるユーザは独立した階層下 の発行局からそれぞれ証明書の発行を受 けられるものとする。 発行局の証明書とユーザの関係

z

あ る 発 行 局 が 同 ー の ユ ー ザ に 対 し て 証 明 書 を 複 数 発行しでも構わない。 4.2 周誌の定義 発行局および認証局z発行局のユーザ認証の 機能と証明書発行機能を分離して、それ ぞれ認証局および発行局と再定義する。 認証局と発行局は各々鍵の対を持ち、発 行局と認証局の認証は署名の確認によっ て行うものとする。 直明書

ID:

ユーザは、同ーの、または複数の 発行局から1つ以上の証明書の発行を受 けることが可能であるo あるユーザの複 数の証明書から証明書を一意に識別する ために、証明書IDを、以下のように定 義する。 証明書ID =ユーザID+発行局名+シリアル番号 4.3 全体の流れ ユーザの証明書を変更する際の一連の情報 の流れを示すと図4のようになる。古い証明 容 を ど う 管 理 す べ き か と い う 点 を 除 け ぽ 健 明書の作成時の流れと同じである。図4中の く

1>

- く

6

>は、証明書変更時に技術的 に検討すべきポイントを示しているo本設計 では、ユーザ認証、証明書や秘密鍵の履歴管 理、履歴入手のインターフェイスに分類して 検討するo

<5)・ 叫〉証明・Jl夏時の.ユーザと毘庭局周のIUE <2>f通行局1:11M局聞の12ff <3>毘8局でのff明'の属鹿管理 <IS> <4>配布局で笹明書を入手するためのインター'71イ且 <5..品』ザ毎時

8

"

.

の管理 <6>ユーザ毎の相手町笹羽.町民思智理 図

4

:

証明書変更時のシステム全体の流れ

4

.

4

設計方針 ユーザの証明書を変更する場合、認証局に おいて変更を要求してきたユーザをどのよう に認証するかは、アプリケーションの性質や ポリシによって変わる。また、ユーザの古い 証明書を利用する必要があるかどうかに関し でも、アプリケーションによって異なる。そ こで、証明書変更方式の設計に当たっては、 具体的な機能をアプリケーションが選択でき るようにするために、個々の機能に対して複 数の方式を用意するo 4.5 証明書変更時のユーザの認証方法 4.5.1 .."プリケーションと認証レベル アプリケーションがサービスを提供する場 合、証明書作成や変更時にどのような認証レ ベルを要求するかについて、アプリケーショ ンのタイプ(表1)別の分類例を表 2に示す。 4.5.2 オフラインによる認証方法 不正な変更要求を受け入れた場合の被害が 大きいという理由で、高い認証レベルを必要 とするアプリケーションについては、電話や 郵便等オフラインの方法を利用するのが現実 的である。この場合、処理が終わるまでは証 明書の利用を停止する必要がある。以下にい くつかの方法を列挙する。 (1)調査会社(第三者)を利用した認証 調査会社(第三者)がユーザについてのプ

-97-ラックリストを管理し、これをもとにして認 証を行いその結果を認証局に伝える。システ ムに依存しない認証が可能であるが、調査会 社の信頼性をどのようにして擁立するかが課 題である。

(

2

)

郵便を利用した認証 変 更 要 求 を 行 う と 認 証 局 が ユ ー ザ に 対 し て葉書を郵送し、ユーザは受け取った葉書を 持って認証局に行き証明書の発行を受ける。 (3)電話を利用した認証 変更要求時には認証を行わずに、変更結果 を本人に通知する際に認証を行うために電話 で直接ユーザに確認を求める。電話番号は証 明書を最初に発行するときに登録しておく必 要がある。 4.5.3 オンラインによる認証方法 アプリケーションを利用するユーザ数が非 常 に 多 い 場 合 や 、 証 明 書 の 変 更 時 の 処 理 時 聞がサーピス提供に重大な影響をもたらす場 合、オンラインの方法を利用して迅速かつ大 量 に 証 明 書 変 更 処 理 を 行 う 機 能 を 必 要 と す る。 証 明 書 の 変 更 を オ ン ラ イ ン で 行 う た め に は、証明書変更要求フォームは認証局への配 送途中で書き換えられないようにする(完全 性を保証する)必要があるo (1)ユーザの証明書を用いた認証 証明書の変更要求フォームをユーザがその 証明書の対となる秘密鍵を使って署名し、認 証局がユーザの公開鍵で確認する

[

8

]

0

この方法では、認証が自動化できるという 利点があるが、 3.1.1節で述べたように、ユー ザの秘密鍵が盗まれた場合、第三者に悪用さ れる可能性があるo

(

2

)

ア プ リ ケ ー シ ョ ン と 独 立 し た 他 の 証 明 書 を用いた認証 方法は(1)と同様である。ユーザは少なく とも2つの独立した階層の証明書を持たなけ ればならない。

(

3

)

証明書作成時の登録情報を用いた認証 証明書作成時に証明書変更に必要な情報を 認証局に登録しておき、その情報を利用して 認証を行う方法が考えられる。この方法では ユーザにとって秘密に管理すべき情報が新た に発生するため、アプリケーションで利用す

表1:アプリケーションのタイプ分類 ￨タイプ￨アプリケーションの特徴

l

不正な証明書発行によるサーバ側の不利益

l

IA ￨金銭的取り引き ￨被害額負担、信用低下 B ￨個人情報提供

I

(間接的)被害額負担、信用低下 .組織内共有情報提供

I

!

践合他社との競争力低下、信用低下 表

2

:

アプリケーションのタイプ別認証レベルの分類(例) ￨レベル 11 タイプ A タイプ B タイプ C 高 高額取り引き 犠密データ 機密データ (医療カルテ、秘話等) (新技術情報、人事情報等) 中 中額取り引き 評価データ等 組織データ (100万円程度まで) (成績等) (電話帳、組織図、顧客名簿等) 低 少額取り引き 低機密データ 低機密データ (1万円程度まで) (所属、プロフィール等} (書類テンプレート等) る秘密鍵とは独立に管理しておくことが大前 提となる。

a

)

K位beros[ll)等の他の認証システムを利用 する ユーザと認証局が同一組織内に存在してい る よ う な 場 合 、 同 ー 組 織 内 に あ る Kerber08 サーバのような第三者による仲介を利用して 認証を行う方法が挙げられる

[

1

2

]

0

証明書変更要求フォームの配送途中での改 ざ ん 防 止 の た め に 、 フ ォ ー ム を Kerberosの セッションキーで暗号化する。

b

)

パスワードを登録して利用する 証明書作成時に認証局にユーザのパスワー ドを登録し、証明書変更時にパスワードを利 用してユーザの認粧を行う。登録時には、パ スワードの盗聴を防ぐためにパスワードを認 柾 局 の 公 開 鍵 で 暗 号 化 す る 等 の 工 夫 が 必 要 である。パスワード利用時には、リプレイア タックを防ぐためにパスワードを含む情報が 毎回異なっている必要がある。これに対して は、変更要求フォームとパスワードを認証局 の公開鍵で暗号化して送信する等の方法が考 えられる。また、変更要求フォームを一時的 な鍵で暗号化し、この鍵とパスワードを認証 局の公開鍵で暗号化する方法もある。

c

)

公開鍵を登録して利用する ユーザは証明書作成時に公開鍵と秘密鍵の 組を 2組 作 成 す る 。 図 5の よ う に 、 証 明 書 作 成時にはパスワードの代わりにユーザのもう 一 つ の 公 開 鍵(Sp2)を登録するo証 明 書 変 更 時には、ユーザは証明書変更要求フォームを Sp2に 対 応 す る 秘 密 鍵(Ss2)で 暗 号 化 し て 送 信する。認証局では登録しておいた Sp2を利 用して証明書変更要求フォームを復号できる かどうかによってユーザ恕涯を行うo 11111

・

ft4JI

.

.

L

"

1__1削昼町公園1.~ぃ~: _ U &

.

.

.

.

L!堕日一、・一一一一一' ・ ・・・・・・・・『‘ L.. 8"aの公開・ 珂・

.

.

U

-

A

T. :+剛刷

J

11明・1 RI!" 81'<1" ・ .B~暗'化 Lt:ヂ-~ S件品ーザ置のも'ー曹の公園a aーザS sd: ~ーザ宮内 .d ー曹の舗".

，

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

旬

、

e : 勾 抽 堀

"

.

.

R

_

*

"

.

ーム))J

U

f

81l..&L!堕!..I

-

l

.

n.OJl..，.-....1Il1J1IIす

j

a

・

・

l

、

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

_

.

'

・・・・・・・・・・ ・_.:;. -， ー ー ー 司 - - ー ー ー ー ・ー ~ SI2(fI明・

.U*?-

Io) ..2. .・・・・・・・・・・・・・・・・・ 圃~-ザB 図5:ユ ー ザ の も う 一 組 の 公 開 鍵 と 秘 密 鍵 を 利 用 し た 認 証 この方法では、 Sp2が認証局以外に知られ でも、 Ss2を持つユーザ以外は証明書の変更 ができないため、認証局でのSp2をそのまま の形で管理できるo また、認証局自身の鑓管 理とSp2の管理を独立に行うことができる。

4.6 証明書や秘密鍵の履歴管理 認証情報や暗号データの利用期間の観点、で アプリケーションを分類すると、表3のよう なレベルが得られる。 2.4節で述べたCRLで は有効期限内に証明書を変更するなどして無 効となった証明書のリストを管理するが、表 3のように有効期限を過ぎた証明書の履歴に ついても必要な場合がある。 4.6.1 証明書の履歴管理 証明書の履歴管理は、配布局で行うか、 ユーザで行うか等の選択肢があるo (1)配布局で全ての証明書の履歴管理を行う 場合 配布局で証明書の履歴管理を行う利点は、 ユーザが個別に証明書を保存する必要がない ということである。 配布局で扱う証明書の数が多く頻繁に証明 書の入手が行われる場合、保管能力と処理能 力が問題となる。保管能力については、証明 書のデータが1Kbyte程度と小さいことから 現実に管理可能な容量であると考えられる。 処理能力については、配布局のキャッシュや 負荷分散のための技術を利用して処理能力の 低下を防ぐ必要があるo 他の問題点として、全ての証明書の履歴を 長期間公開することによって、公開鍵から秘 密鍵が求められる可能性がある。 (2)ユーザが通信相手の証明書の履歴管理を 行う場合 自分の通信相手の証明書のみを履歴管理す ればよいため、保管能力については問題にな らない。しかし、他のユーザの証明書が変更 されたタイミングを正確に知ることが難しい という問題がある。 4.6.2 秘密鍵の履歴管理 秘密鍵の履歴は必要な時以外はオンライン でアクセスできないように管理する必要があ るo 自分の複数の秘密鍵を管理する場合、そ の識別を行うためにはその秘密鍵がどの公開 鍵(すなわち証明書)の対であるかという情報 が必要であるo秘密鍵の履歴管理を行った場 合 、 証 明 書 と 同 様 に 証 明 書IDか ら 履 歴 を 入 手する方法を提供するのがよい。 -99-4.7 証明書や秘密鍵の履歴入手のためのイ ンターフェイス 証明書や都密鍵の履歴を入手しようとする 場合、特定の証明書を取り出したり、特定の 条件を満たす証明書リストを取り出すための インターフェイスについて、表4の よ う に 定 義するo もちろん、アプリケーションにとっ て必要なインターフェイスを選択して提供す ることが重要である。

5

.

おわりに 本 稿 で は 、 公 開 鍵 暗 号 の 証 明 書 の 変 更 が 生じた場合に、証明書を利用するアプリケー シ ョ ン に ど の よ う な 問 題 が 生 じ る か と い う 点について整理を行った。さらに、ユーザの 個々の証明書を変更する場合に着目して、発 行局を前提とした証明書システム全体の見直 しと設計を一部行った。 変更時のユーザ認証の方法については具体 的にはアプリケーション毎に選択することが 必要で、ここでは選択肢となるいくつかの方 法を示した。 証明書や秘密鍵の履歴管理については、履 歴管理を必要とするアプリケーションの特徴 に つ い て 述 べ 、 誰 が 履 歴 管 理 を 行 う か の 検 討、また証明書の履歴を入手するためのイン ターフェイスの定義を行った。今後はこれら の 設 計 に 基 づ い て 発 行 局 や 配 布 局 の 実 装 を 行っていくつもりである。 公開鍵暗号を応用し、セキュリティについ て 考 慮 し た シ ス テ ム は 、 今 後 ま す ま す 増 え てくると予想される。その際、システムの基 本原理としての強さだけでなく、システムを 運 用 し て い く 上 で ど の よ う に し て シ ス テ ム の 強 さ を 確 保 す る か を 考 え て い く こ と が 重 要になってくる。本稿では、特に証明書の変 更に関連した鍵管理の問題について扱ってき たが、この他にも公開鍵暗号をとりま〈数多 くの鍵管理の問題、例えば発行局の鍵管理の 問題や、秘密鍵自体の管理、証明書のキャッ シュと配布局との関係づけ等について検討し 解決していきたい。 謝 辞 本稿作成にあたり、議論、助言その他様々 な 御 協 力 を い た だ い た 社 内 他 部 門 お よ び 職

表3:ア プ リ ケ ー シ ョ ン と 証 明 書 利 用 期 間 の 関 係 ￨レベル ￨証明書利用期間 ￨証明書の履歴管理! リモートログイン サーピス開始時のみ 不要 短い有効期限っき文書 文書の有効期間 不要 但し、証明書の有効期間コ文書の有効期間 長い有効期限っき文書 文書の有効期間 必要 但し、証明書の有効期間

c

文書の有効期間 電子メール、電子承認

。

。

必要 表4:履 歴 入 手 の た め の イ ン タ ー フ ェ イ ス 例 ￨要求 ￨指定すべきインターフェイス 特定の証明書 証 明 書 面 (ユーザID+発行局名+シリアル番号} あるユーザについて 現在有効な証明書のリスト ユーザB 現在無効な証明書のリスト ユーザID+ inva.1id 1993 -1994年に有効だった証明書のリスト ユーザID+ 1993-1994 ある発行局の発行した証明書のリスト 発行局名 特定の証明書に対応する秘密鑓 証明書ID+腸cret ユーザID[発行局名] [シリアル番号] [日時:] [invalid] [secret] 場 の 皆 さ ん 、 ま た 検 討 に 参 加 し て 下 さ っ た WIDEプ ロ ジ ェ ク ト メ ン バ の 方 々 に 深 く 感 謝 致します。 参考文献

[

問

1司]CCαITT:ゾ‘吋heDiredory -A

F

r

amewl

倒

。

rk_'

_ヘ

CCαITTRe舵

。

c

∞

mmenda叫，tion1 X.509 (Nov. 1988). [2] J. Linn:

“

Privacy Enha.ncement ior Inter・ net Eledronic Ma

i

1

:

Part 1: Messa<<e En -αyption a.nd A uthentica.tion Procedures"t RFC 1421 (Feb. 1993). (3] S. Kent:

“

PrivacyEnh姐 cement ior In色町・ net Eledronic Ma.il:Pa.rt II: Certi量ca.te同 Ba.sed Key Ma.nagement"t RFC 1422 (Feb. 1993). [4} D.

B

a.lenson:

“

P白 紙yEnh姐 cem凶 for Internet Eledronic Mail: Pa.rt IV:Key Cer -tification a.nd Rela.ted Services"

，

RFC1423 (Feb. 1993). [51B. Kaliski:

“

Priva.cy Enhancement for In・ ternet Eledronic Ma.il: Pa.rt IV: Key Cer -tifica.tion and Rela.ted Ser吋ces"t RFC 1424 (Feb. 1993).

(

6

)

P. F:油n:

“

AnswersTo FREQUENTLY ASKED QUESTIONS About Today's Cryp -togra.phy (Ver 2.0)" (Sep. 1993).

[

7

]

R. Rivest:

“

The MD5 Messa.ge-Digest Al・ goriihm"

，

RFC1321 (Apr. 1992). (8)菊 池 浩 明 、 黒 田 康 嗣 : “FJPEM

マニュ

アルヘ FJPEMパ ッ ケ ー ジ に 含 ま れ る マ

ニュア

Jレ(M低・1994). [9]槙井三子、佐野晋:“PEM公開運用実験 へ の 参 加 と 課 題 ヘ 信 学 会 ， 通 信 の 快 適 性・安全性・信頼性ワークショップ

(M

a.

r

.

1995).

[

1

司 大 瀧 保 広 、 森 亮 一 : “ 超 流 通 に お け る 暗 号 の 手 法 に つ い て ヘ 信 学 技 法 ， Vo

1

.

90， ISEC9仏49

，

pp.33-42 (1990). [11] J. 1. Steiner

，

B. C. Neum組 組dJ. G.

3

制 位 "Kerberos: An Authentication er吋cefor Op佃 NetworkSystems"

，

USENIX 1988 Winter Confer佃 ce

，

pp.191・ 202 (1988). (12) J. 1. Steiner組 dD. Atkins:

“

Sca.ling the

Web o! Trust: Combining Kerberos叩 d

PGP to Provide L回JreSca1e Authenti.

ca.tion"

，

USENIX Temnica.lConference

，

pp.83-93

(

J

an. 1995).