JPH11168462A - 移動可能プロセスの認証方法 - Google Patents

移動可能プロセスの認証方法

Info

Publication number
JPH11168462A
JPH11168462A JP9334581A JP33458197A JPH11168462A JP H11168462 A JPH11168462 A JP H11168462A JP 9334581 A JP9334581 A JP 9334581A JP 33458197 A JP33458197 A JP 33458197A JP H11168462 A JPH11168462 A JP H11168462A
Authority
JP
Japan
Prior art keywords
certificate
movable
authentication
original
procedure
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
JP9334581A
Other languages
English (en)
Inventor
Toshiya Iwai
俊弥 岩井
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.)
Individual
Original Assignee
Individual
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 Individual filed Critical Individual
Priority to JP9334581A priority Critical patent/JPH11168462A/ja
Publication of JPH11168462A publication Critical patent/JPH11168462A/ja
Pending legal-status Critical Current

Links

Landscapes

  • Stored Programmes (AREA)

Abstract

(57)【要約】 【課題】改竄、不正コピー等を防止可能な移動可能プロ
セスの認証方法の提案 【解決手段】 移動可能プロセス生成時にユーザー等の
生成者により与えられた認証情報を保持する証明書正本
を、安全の確保された証明書管理機構に設置し、前記証
明書正本より派生した証明書副本を前記移動可能プロセ
スの実行環境内に設置し、前記移動可能プロセスと前記
移動可能プロセスとを双方向に参照する参照により一対
一に対応させ、前記証明書正本と前記証明書副本とを双
方向に一対一に対応させ、前記証明書正本に前記移動可
能プロセスへの参照を設定することを特徴とする移動可
能プロセスの認証方法。

Description

【発明の詳細な説明】
【0001】
【発明の属する技術分野】本発明は、ネットワークを構
成するコンピュータ間において移動する移動可能プロセ
スのマルチ・ホップ認証方式とその各種の変形に関す
る。
【0002】
【従来の技術】ネットワーク間を移動する移動エージェ
ントなどの移動移動可能プロセスにおいては、当該移動
プロセスが移動する際に、当該移動プロセスが真正なと
ころから発信されたものであるかどうか、の認証の問題
が伴う。例えば、図4のネットワーク構成において、認
証サーバーA, B, Cがあたえられ、そのサーバーそれぞ
れに統治される3つのドメインa, b, cが存在すると仮
定する。また、ドメインa,b,c間は通信回線で結合
されており、セキュリティ・プロトコルに準拠したデー
タのやり取りが可能であるとする。このとき、ドメイン
aにあるプロセスをPxとし、それをドメインb、ドメイ
ンc、に移動させる事を考える。
【0003】従来の認証方法は、認証を受ける側と与え
る側とで他には知り得ない秘密を共有することや、他の
存在は所持し得ない持ち物を提示する事によって行われ
ていた。それらの秘密や特定のための情報は、パスワー
ドや暗号鍵、IC-カード、個人の身体的な特徴などであ
る。プロセスの移動を考慮しない場合のプロセスの認証
は、プロセスの生成時に生成者本人が認証者に対してそ
の秘密や持ち物を提示する事によって行われていた。
【0003】また、公開鍵暗号方式を利用する場合、本
人が自分しか知らない秘密鍵で署名を行い、その署名の
確認は対応する公開鍵で署名が読めるかどうかで行われ
る。公開鍵を使用する場合、個人が持つ秘密鍵を外部に
一切知らせずに、公知の公開鍵だけで確認ができる点が
長所である。この技術を使用する場合、署名を公的な機
関に登録する事によって、署名に対する公的な認証効果
を持たせる事が可能である。ここにおいて、両者に共通
している事は、個人だけにしか持ち得ない持ち物や秘密
の存在を仮定している点である。尚、あらかじめ、以下
の記述で主要な役割を持つ用語を定義しておく。
【0004】[プロセス]本発明では、プロセスという用
語を通常より拡大された意味で用いる。それは、本発明
の目的が、いわゆる移動エージェントと呼ばれるネット
ワーク上を移動しながら一連の手順を実行するオブジェ
クトプログラムに対する認証機構を定めるためである。
そこで、本発明では、プロセスという用語に対して、従
来のプロセスの意味に加えて、移動エージェントを構成
し得るオブジェクトという意味を与える。ここには、基
礎となるシステムに応じて、タスク、実行スレッド、ス
クリプトなどを含ませることが可能である。
【0005】[プロセスの外部形式]プロセスの外部形式
とは、実行中のプロセスをネットワーク上の別のホスト
や外部記憶媒体などに転送する際の形式をいう。そこに
は、プロセスを構成する手順と実行時の内部状態デー
タ、制御情報などが含まれている。オブジェクト指向シ
ステムでは、シリアライゼーション(Serialization:直
列化)と呼ばれる技法が使用される事が多い。本発明で
は、所によっては、プロセスの外部形式を生成する意味
で、シリアライゼーションという用語を使用する場合が
ある。ただし、本発明では、外部形式のデータ構造や手
法は特に限定しない。
【0006】[認証者]認証者 (Authenticator) とは、
単一あるいは複数の処理手続きであって次のような機能
をもつものをいう。 1) 証明書の真正性の判定を行う。 2) 証明書の真正性にもとづいて証明書と対応付けられ
たプロセスなどのオブジェクトに対する認証をあたえ
る。 3) ドメインを管理する証明書管理機構の特定をする。
この機能は、認証者固有の機能である。その他、の機能
は実装上の判断によっては、次に述べる証明書管理機構
に行わせることも考えられる。 4) エージェントなどの移動可能プロセスに対する移動
時の認証を行う。 5) ユーザーに対する認証を与える。 6) 認証にもとづいて証明書の発行を行う。
【0007】認証者は、これらの機能を実現するに当た
って証明書管理機構にアクセスし、そこで保持されてい
る証明書データを使用する事が可能である。また、証明
書管理機構間で定められた秘密情報を利用する事も許さ
れている。従って、認証者の安全性を保証する必要があ
る。もっとも、必ずしも、全ての認証者が上記の機能の
全てを実装するわけではなく、上記の機能の一部だけを
実装する事によって、様々なタイプの認証者が実現され
得る。
【0008】例えば、ユーザーの認証を行い、そのユー
ザーが所有するオブジェクトやプロセスそして、それら
に対応する証明書を発行する認証者は、ユーザー認証者
などと呼ばれるであろうし、移動時のエージェントの認
証を専門に行う認証者はエージェント認証者などと呼ば
れるかもしれない。
【0009】[証明書管理機構]証明書管理機構は、正
本、副本からなる証明書のうち、証明書正本を複数管理
する。これは、証明書管理機構固有の機能の一つであ
る。一般に、認証を与えるサーバーのことを認証サーバ
ーと呼んでいるが、本発明では、認証を与え証明書の発
行/管理をも行うサーバーもしくはサーバーと同等な機
能を有する装置に対して証明書管理機構なる用語を与え
る事にする。証明書管理機構は外部からの不正アクセス
に対して安全であることが必要である。ある証明書管理
機構は、別の証明書管理機構と秘密を共有する等の方法
によって相互認証を行う事が可能であることが要求され
る。これは、二つ目の証明書管理機構固有の機能であ
る。ただし、本発明では証明書管理機構間の相互認証の
方式に関しては特に定めない。なお、本発明では、所に
よっては、証明書管理機構の意味で認証サーバーとかサ
ーバーという用語を用いる場合もある。通常、証明書管
理機構には、専用の独立したホスト・マシンが与えられ
ている。
【0010】[認証機構]上に記した認証者と証明書管理
機構との組が本方式での認証機構を形成する。認証者は
認証を与えるオブジェクトと証明書管理機構との仲介を
行う立場にある。認証機構全体から見ると、上記の認証
者と証明書管理機構との役割はある程度流動的なものと
考えても良い。上で記された認証者の機能の一部を証明
書管理機構側に持たせる事などは、本発明で述べる証明
書方式を利用した認証機構の実装上の判断として許され
る。従って、以下の本発明の記述に関して、証明書管理
機構の機能とされる部分を認証者に行わせたり、その逆
を行わせたりする変形が生じたとしても、その多くは認
証機構の機能としてみると、本発明で述べる記述と本質
的な違はない。このような役割配分の検討を行う最大の
理由は、証明書管理機構への負荷の集中を回避する事に
ある。
【0011】尚、認証者の存在理由は、セキュリティ・
ドメイン内に存在する証明書副本がどのような改ざんに
あったとしても、対応する証明書正本を見つけ出せる事
を保証する事にある。
【0012】[環境]手続き、プロセス、オブジェクトな
どの実行を行う場一般を環境と呼ぶ事とする。ここに
は、コンピュータ・ハードウェア、オペレーティング・
システム、仮想マシン、サーバー・プログラムなどを含
ませることが可能であるが、手続き、プロセス、オブジ
ェクト等が実行可能でありさえすれば、本発明ではその
形態を問題にはしない。ただし、所によっては、オペレ
ーティング・システムや仮想マシンのニュアンスを込め
て実行環境という用語も使用する。
【0013】[通信機構]環境と環境との間で情報の交換
を可能にする機構を通信機構とよぶ。所によって通信シ
ステム、通信回線という用語も同じ意味に使用すること
もある。通信機構自体は信頼性が高いと仮定する。すな
わち誤りの無い通信が可能である。しかし、悪者による
意図的な盗聴やノイズの混入も有り得ると仮定する。
【0014】[証明書]プロセスやオブジェクトの認証情
報を保持するデータを証明書という。本システムの証明
書は正副の2つ証明書データから構成される。証明書の
正本は、証明書管理機構側に置かれ、証明書の副本はユ
ーザー環境のセキュリティ管理プログラム内に置かれ
る。そして、正副証明書相互は双方向の参照でリンクさ
れている。
【0015】[セキュリティ・ドメイン]証明書管理機構
などの認証サーバーは権威あるプロセスであって、厳密
な安全対策が施されていると想定する。従って、証明書
管理機構への侵入やデータの改ざんは困難である。この
ことが、本機構内で証明書の唯一の存在を保証する前提
である。証明書管理機構など認証サーバーの周辺には、
その認証サーバーによって統治されているユーザー環境
が複数存在している。そのような、認証サーバーに統治
されるユーザー環境内のオブジェクトの集合が、セキュ
リティ・ドメインを構成する。セキュリティ・ドメイン
中のオブジェクトは認証サーバーによって認証されてい
るものもあれば、認証されていないものもある。認証さ
れていないオブジェクトは、原則としてゲストとして扱
われ公共の資源に対するアクセスだけが許可される。認
証されたオブジェクトの集合が安全なドメインを形成す
る。本発明では、特に断りの無い限り、このような安全
なドメインだけを考える事にする。
【0016】
【発明が解決しようとする課題】[移動可能プロセスの
認証問題]しかし、従来の技術で述べた認証方式を図1
0のような移動するプロセスの認証に使用する事は、実
際上不可能である。第1の理由として、情報であるプロ
セスに個人が所持している物体を持たせる事は不可能だ
からである。第2の理由として、個人と認証サーバーで
共有している暗号鍵や、公開鍵暗号方式の秘密鍵をプロ
セスに保持させることは、秘密の漏洩の恐れがあるた
め、安全上好ましくないからである。しかし、たとえ秘
密をプロセスに持たせなくても、プロセスPxはドメイン
aにて生成され、認証サーバーAにて認証されている場
合、ドメインaからドメインbに移動させる際の認証は可
能であり、認証サーバAの認証を通じて、プロセスPxを
ドメインbにて受け入れることは可能である。
【0017】これは、認証サーバAがプロセスPxの生成
に直接関与し、プロセスPxの生成時に、プロセスPxの生
成を要求した人物本人の認証を行うために必要な情報を
保持しているからであり、ドメインbの認証サーバBの
要求を満足させるだけの認証情報を、認証サーバAがプ
ロセスPxに対して付加することが可能なためである。例
えば、プロセスPxをドメインbに送る際、ドメインa内
でプロセスPxの生成者の秘密鍵を利用した署名をつけ、
プロセスPxをドメインbに送った後に、ドメインbの認
証サーバBが公開鍵で当該署名を確認することなども可
能である。
【0018】[移動可能プロセスの多段階の認証問題]で
は、ドメインb上に移動したプロセスPxが次にドメインc
に移動する場合、同じ手続きが可能であろうか? これ
は、困難である。認証サーバーBが認証サーバーCに対し
て簡単にプロセスPxの認証を与える事はできない。なぜ
なら、そもそもプロセスPxはドメインbにて生成された
ものではないためである。では、サーバーCはサーバーA
に問い合わせを行いプロセスPxの認証情報を受ける事が
できるだろうか? それも、困難である。プロセスPxは
ドメインb上にて処理を行い、その内部状態はドメインa
上で処理を行っていた時とは異なっているためである。
厳密には、ドメインa上にて活動していたプロセスPx
は、ドメインbに移動した時点からプロセスPx'としてプ
ロセスPxとは区別して扱うべき物となっているからあ
る。
【0019】従って、認証サーバーAとしては、プロセ
スPx'がプロセスPxの処理の結果なのか、別のプロセスP
yがプロセスPx'と詐称しているのか区別する事はきわめ
て困難である。また、上述した第1の理由を再検討する
と、プロセスPxの生成者の秘密鍵を認証サーバーAから
認証サーバーBに送る事も機密保持上許されることでは
ない。仮に送信できるとしても、署名等の認証情報を付
加されたプロセスPx'が、元々のプロセスPxによる直接
の結果であるかどうかを確認することは、困難である。
ここで、仮定としてプロセスPxが生成者本人の所持する
秘密鍵Kを所持していた場合を考える。認証サーバーCは
認証サーバーAにある(任意の或いは所定の?)数Xを提
示してもらい、プロセスPxにその秘密鍵Kで数Xを暗号化
したK[X]を作らせ、この数K[X]を認証サーバーAに確
認させ、認証を行う事も確かに可能ではある。
【0020】しかし、コンピュータ上ではプロセスPxの
内部状態まで含めた複写は容易であって、プロセスPxを
複写して生成されたプロセスPy(プロセスPxとは異な
る)であっても、上の手順は実行可能であって、同様に
認証をうけることが可能である。従って、この認証手続
きには欠陥がある。尚、移動エージェントの多段階の認
証(Multi-hop Authentication)に関しては、「GMD FOKU
S、International Business Machines Corporation、Su
pported by: Crystaliz, Inc.、 General Magic, In
c.、The Open Group "Joint Submission : Mobile Agen
t System Interoperability Facilities Specificatio
n" 、November 10, 1997 OMG TC Document orbos/97-10
-05」がある。この論文内には、セキュリティ技術的に
は未解決である、という記述が見られる。これは、上記
ような問題を指すのであろう。この記述については、本
発明の第19実施形態において再び取り上げる。
【0021】発明者は、このような問題につき以下のよ
うに考察した。移動可能プロセスの認証は、移動可能プ
ロセスが確かに移動可能プロセスの所有者のプリンシパ
ル(人間のユーザー、或いはシステム実体であって、認
証システムに登録されており、本物であると認められて
いるもの。以下、同じ)に属すことを証明することであ
る。移動可能プロセスはあくまでプリンシパルの代理で
あり、しかも物体ではなくプログラムと内部データとが
複合されたものである。また、内部データは処理の進行
に応じて変化するし、コピーも可能である。このため様
々な制約や困難が生ずる。そのような制約や問題の幾つ
かを整理すると、以下の通りとなる。
【0022】(1) 移動可能プロセス自身にキーを持ち運
ばせるのは、プライベート・キーを公開することと同じ
であるため、危険である。従って、プリンシパルを証明
する方式としての、プライベート・キーによる暗号化は
移動可能プロセス自身は使えない。 (2)データが変化するので、ハッシュ関数の値を認証の
根拠に使うことは出来ない。 (3)一時的なパスワードを移動可能プロセスに保持させ
ることも不可能ではないが、移動可能プロセスはデータ
でもあるので、パスワードを含めた移動可能プロセス全
体をコピーした後に改ざんを受ける可能性がある。 (4)移動可能プロセスの不変部分(移動可能プロセスの
コード部など)に署名を付加することも考えられるが、
可変部分の信用を保証することはできない。たとえば、
不変部分と署名だけをコピーして、可変部分を偽造する
ことも可能だからである。
【0023】[移動可能プロセスの認証方法]本来、移動
可能プロセスの認証とは何を意味するのか? 移動前の
移動可能プロセスAと移動後の移動可能プロセスA'が、
同じものであることを証明するとは、何を言っているの
か、その正確な意味を定義する必要がある。「同じ」と
は決して物理的な同一性を指している訳ではない。実
際、移動後の移動可能プロセスA'は、移動前の移動可能
プロセスAのコピーである。コピーということは、厳密
には同一のものではないということである。このこと
は、移動可能プロセスの移動自体が、人や物の移動とは
異なっていることを意味している。人間世界での認証で
は、人物のコピーは通常有り得ないとされ、認証行為も
その前提で実施される。従って、顔かたちが「同じであ
る」ということの証明が、認証方法として一般に通用す
るのである。この一般的な通念を覆す例が、双子の片方
によって成された犯罪が、状況証拠のみしかない場合、
犯人の確定を困難なものにするケースである。この場
合、「似ている」という意味を含む「同じ」は、同一性
の認証の基準には採用できない。
【0024】移動可能プロセスの認証にも、やや似た状
況が発生している。移動したプロセスが正確なコピーな
のか、模造なのかの識別は、両者とも厳密な意味で原本
とは同一物でない以上、困難である。すなわち、移動可
能プロセスの認証の正確な意味を定義し直す必要があ
る。
【0025】
【課題を解決するための手段】発明者は、この認証問題
の解決に当たって、ネットワーク上に唯一の存在が保証
されている証明書もしくは、許可証があると都合がよい
と考える。その実現方法は、認証サーバー上に証明書の
正本を置き、ユーザー側にその副本を置くことによる。
その際、正本と副本の両者間に双方向の参照を配置す
る。証明書を生成する際、オーナーのプリンシパルの認
証を事前に必要とする。認証の結果として発行された証
明書は、ネットワーク上に唯一存在し、複製が不可能で
あるため、その証明書が盗まれない限り、証明書を保持
するという事実自体が認証効果をもつ。これは、パスポ
ートや運転免許証の開示によって本人を認証することと
同様である。いわばネットワーク上の身分証明書として
通用する。ここにおいて、証明書は、外部形式化可能な
データであり、ネットワーク上を移動させる事が可能な
ものとする。また、移動や二次記憶媒体への保存には、
証明書の唯一性を保証するための手続きを必要なものと
する。換言すれば、移動可能プロセスの認証は、移動可
能プロセスが属する責任の主体を確定することにより確
立される。このことは、移動可能プロセスが与える結果
に対して誰に責任を問えるのかを確定する事であるとも
言える。
【0026】なぜなら、移動プロセスは常にその状態を
変化させ続けている変化の過程にあるものであって、固
定されたものではないため、物体の帰属を問うように移
動プロセスに対してそのもの自身の帰属を問うことは出
来ない。しかし、その変化の原因-結果の連鎖を原因側
にたどって行くことによって、最終的に開始プリンシパ
ルに達するならば、その変化の一局面に対して開始プリ
ンシパルに属する移動プロセスとして認証を与えても良
い。すなわち、転送元実行環境にて移動可能プロセスA
はすでに認証されていることを帰納法の仮定とすると、
移動可能プロセスA'が、移動可能プロセスAからの直接
の結果として生じたことを証明できれば、移動可能プロ
セスA'が、移動可能プロセスAのプリンシパルに属して
いると主張してよい。
【0027】この主張を形式的に表現すると、次のよう
な移動可能オブジェクトの認証に関する定義に到達す
る。ここで、プロセスはオブジェクトの特殊な形態とみ
なす。 定義1. 移動可能オブジェクトの認証とは、そのオブジ
ェクトが所属するプリンシパルを確定することである。 定義2.移動可能オブジェクトAがプリンシパルPに属す
るということを次のように帰納的に定める。
【0028】(1)プリンシパルPの主体がオブジェクトA
を直接生成した場合、オブジェクトAはプリンシパルPに
所属する。 (2)プリンシパルPに所属するあるオブジェクトAnが存在
し、オブジェクトAがオブジェクトAnの結果として生じ
た場合、オブジェクトAはプリンシパルPに所属する。 (3)オブジェクトAがプリンシパルPに所属するのは、上
の(1),(2)の場合に限る。 この定義を具体的な場合にあてはめてみる。シリアライ
ゼーションなどによって外部形式化された移動可能プロ
セスA1のデータ列A2が、転送先実行環境において、元
になる移動可能プロセスA1自身によって作成されたこと
を証明できれば、そのデータ列A2は、移動可能プロセス
A1のプリンシパルPに属しているとして良い。その結
果、そのデータ列A2が転送先実行環境でも認証された事
になる。
【0029】さらに、データ列A2をデシリアライズされ
たデータ列A3もまた移動可能プロセスA1と同じプリンシ
パルに所属すると判断できる。従って、データ列A3の認
証も行われたことになる。このことを実際に応用するた
めには、移動可能プロセスの転送時における、移動可能
プロセスの外部形式化されたオブジェクトが、移動可能
プロセス自身の結果として生じたということを明示する
必要がある。この、原因-結果の関係を転送時に明確に
主張する形の移動可能プロセス(またはオブジェクト)
の転送方法を次に記す。
【0030】このような課題を解決するために、本発明
の請求項1は、移動可能プロセス生成時にユーザー等の
生成者により与えられた認証情報を保持する証明書正本
を、安全の確保された証明書管理機構に設置し、前記証
明書正本より派生した証明書副本を前記移動可能プロセ
スの実行環境内に設置し、前記移動可能プロセスと前記
移動可能プロセスとを双方向に参照する参照により一対
一に対応させ、前記証明書正本と前記証明書副本とを双
方向に一対一に対応させ、前記証明書正本に前記移動可
能プロセスへの参照を設定することを特徴とする。
【0031】また、本発明の請求項2の発明は、請求項
1の移動可能プロセスの認証方法であって、前記証明書
正本副本、前記移動可能プロセス間の相互間の参照が整
合すること、ならびに、前記証明書正本副本情報が整合
することの確認をもって、前記移動可能プロセスの認証
成功を判定し、当該認証処理において、前記証明書正本
が前記証明書管理機構を代表すると見なすことをもっ
て、前記証明書管理機構と前記移動可能プロセス相互の
認証が行われたと判定し、前記証明書管理機構と前記移
動可能プロセス以外の系には知り得ない共有の秘密生成
を可能としたことを特徴とする。
【0032】また、本発明の請求項3の発明は、1以上
のネットワークで接続された転送元実行環境と転送先実
行環境と、前記転送元実行環境で生成された移動可能プ
ロセス及び前記転送先実行環境の共有鍵KP1、並びに、
前記転送先実行環境の共有鍵KP2を保持し、前記移動可
能プロセスと相互認証を行っている証明書管理機構とに
おける移動可能プロセスの認証方法であり、第1のステ
ップにおいて、転送に先立ち、前記移動可能プロセス
は、前記証明書管理機構に対して共通秘密鍵KAJの生成
を要求すると共に、この要求の際、前記移動可能プロセ
スは秘密の数SAを定め、TA=gSA mod p(pは素数、gはあ
る整定数で、modは法演算をあらわす)を計算してTAを
前記証明書管理機構Jに渡し、第2のステップにおい
て、前記証明書管理機構は前記移動可能プロセスの要求
に答えて、秘密の数SJを生成して TJ=gSJ mod pを計算
すると共に、共通鍵KAJをKAJ=TASJ mod p とし、第3
のステップにおいて、前記証明書管理機構は前記共有鍵
KP2により前記共通秘密鍵KAJを暗号化して、KP2[KAJ]を
計算し、第4ステップにおいて、前記証明書管理機構
は、前記移動可能プロセスに対して、TJとKP2[KAJ]を前
記要求に対して回答し、第5ステップにおいて、前記移
動可能プロセスは受け取ったTJから、KAJ=TJSA mod pを
計算して、共通鍵KAJを再生し、第6ステップにおい
て、前記移動可能プロセスは転送するオブジェクトを外
部形式化して外部形式OExを生成した後、この外部形式O
Ex全体を前記共有鍵KAJにて暗号化してKAJ[OEx]とを生
成し、第7ステップにおいて、前記移動可能プロセスは
前記転送元実行環境に対して、KAJ[OEx]とKP2[KAJ]とを
前記転送先実行環境に転送することを要求し、第8ステ
ップにおいて、前記転送元実行環境から前記転送先実行
環境にKAJ[OEx]とKP2[KAJ]とが転送されたとき、前記転
送先実行環境はKAJ[OEx]とKP2[KAJ]とを解読して共有鍵
KAJをつくることを特徴とする。
【0033】更に、本発明の請求項4の発明は、請求項
2における移動可能プロセスの認証方法であり、前記移
動可能プロセスは移動可能オブジェクトであり、この移
動可能オブジェクトに、この移動可能オブジェクトに一
対一に対応すると共に、前記転送元実行環境の本体であ
ることを示すプリンシパルの識別が記載される名札オブ
ジェクトを前記証明書副本として配置し、前記移動可能
オブジェクトが前記名札オブジェクトを配布する場合
を、(1)前記プリンシパルの主体が移動可能オブジェク
トを直接生成した場合と、(2)前記プリンシパルに所属
するある移動可能オブジェクトAnが存在し、ある移動可
能オブジェクトAが前記移動可能オブジェクトAnの結果
として生じた場合とに限定し、前記(1)の場合に、前記
プリンシパルの主体は、当該生成された移動可能オブジ
ェクトが当該プリンシパルに所属することを示す名札オ
ブジェクトを生成し、前記(2)に、前記移動可能オブジ
ェクトAnは当該移動可能オブジェクトAnの名札オブジェ
クトを複写して、前記移動可能オブジェクトAに付与す
ることを特徴とする。更に、本発明の請求項5の発明
は、請求項2の移動可能プロセスの認証方法であり、前
記移動可能プロセスは移動可能オブジェクトであり、前
記証明書管理機構に、前記名札オブジェクトに一対一に
対応する影の名札オブジェクトを前記証明書正本として
配置すると共に、前記名札オブジェクトの内容と前記影
の名札オブジェクトの内容とを常に一致させ、移動可能
オブジェクトがプリンシパルに属するとして認証する場
合を、(1)当該プリンシパルの主体が移動可能オブジェ
クトを直接生成した場合と、(2)ある移動可能オブジェ
クトAが、元となる移動可能オブジェクトAnの結果とし
て生じた場合とに限定し、前記(1)の場合に、プリンシ
パルの主体は、プリンシパルの識別が記載された名札オ
ブジェクトを移動可能オブジェクトに対応づけると共
に、その名札オブジェクトと同じ内容の影の名札オブジ
ェクトとを対応させて、前記(2)の場合に、オブジェク
トAnはオブジェクトAnの名札オブジェクトを複写してオ
ブジェクトAに与え、その名札オブジェクトに影の名札
が対応している場合に限り、影の名札オブジェクトの複
写も行うことを特徴とする。
【0034】
【実施の形態】以下に、本発明の実施形態を説明する。 [実施形態1:移動可能プロセスの認証方法]図5は、本
発明の第1の実施の形態を示す。図5において、転送元
実行環境をP1,宛先実行環境をP2,移動可能プロセスを
Aとする。さらに、認証キーを生成する審判サーバーJの
存在を仮定する。Jは鍵配布センター(KDC)が兼務しても
よい。ここで、AとJとは相互認証を行っていると仮定す
る。またpは素数、gはある整定数で、事前に決めていて
もよいし、通信時に定めても良い。また、modは法演算
をあらわす。 (1)転送に先立って、移動可能プロセスAはDiffie-Hellm
an方式を使って、審判サーバJに対して共通秘密鍵KAJの
生成を依頼する。この際Aは秘密の数SAを定め、TA=gSA
mod p を計算し、TAを審判サーバJに渡す。 (2)審判サーバJは移動可能プロセスAの要求に答えて、
秘密の数SJを生成し、TJ=gSJ mod pを計算する。さらに
共通鍵KAJも KAJ=TASJ mod p とする。 (3)審判サーバJは宛先実行環境P2の共有鍵KP2を保持し
ており、この共有鍵KP2により前記の共有鍵KAJを暗号化
し、KP2[KAJ]を計算する。 (4)審判サーバJは、移動可能プロセスAに対して、TJとK
P2[KAJ]を要求に対する回答としてあたえる。 (5)移動可能プロセスAは受け取ったTJから、KAJ=TJSA m
od pを計算することによって、共通鍵KAJを再生する。 (6)移動可能プロセスAは転送するオブジェクトOを外部
形式化し外部形式OExを作る。そして外部形式OEx全体を
共有鍵KAJにて暗号化し、これをKAJ[OEx]とする。(こ
のとき、外部形式OExに共有鍵KAJを連結したものをつく
り、そのデータ列のメッセージ・ダイジェストを求め、
ダイジェスト値と外部形式OExの組をKAJ[OEx]としても
良い。) (7)移動可能プロセスAは転送元実行環境P1に対して、KA
J[OEx]とKP2[KAJ]とを宛先実行環境P2に転送してもらう
ことを要求する。 (8)転送元実行環境P1から宛先実行環境P2にデータが転
送されたとき、KP2[KAJ]を解読して共有鍵KAJをつく
る。この共有鍵KAJにてKAJ[OEx]を解読可能であること
を根拠に、この外部形式データOExが移動可能プロセスA
によって作成されたことが確認できる。そこで、外部形
式OExを内部形式化したオブジェクトO'に対して、移動
可能プロセスAのプリンシパルに属するという認証を与
える事ができる。
【0035】上の転送手続きでは、転送元実行環境P1が
悪意を持って、移動可能プロセスAの内部コードを解析
しない限り共有鍵KAJを知ることはできない。上の手順
は移動可能プロセスAと審判サーバJとがすでに相互認証
を行っていることを仮定している。よって、移動可能プ
ロセスAと審判サーバJしか知る事ができない共有秘密鍵
KAJは、信頼できる審判サーバJによって移動可能プロセ
スAの関与を保証している、と考えることが出来る。従
って、KAJ[OEx]が移動可能プロセスAによる結果である
という、原因-結果の連鎖の存在を証明している。故
に、外部形式OExが移動可能プロセスAのプリンシパルに
属していることが証明されており、さらに外部形式OEx
を内部形式化して得られるオブジェクトO'も移動可能プ
ロセスAと同じプリンシパルに属していることが示され
る。
【0036】この手順は実行環境自体が信頼できない場
合には成立しない。実際、悪意を持っている者が、コア
ダンプをとったり、デバッガーを使用したりすることに
よって、共通鍵KAJを移動可能プロセスAから取り出すこ
とは困難ではない。ただ、KP2[KAJ]を作る際に審判サー
バJによってタイムスタンプを付加してKP2[KAJ|タイム
スタンプ]とすることなど、有効期限を課すことで、悪
意ある試みにある程度は対抗することもできる。例えば
有効期限をタイムスタンプから10分以内とすると、10分
間で、共通鍵を取り出し、偽のデータを作成し、P1から
P2に転送することは、実際上は、かなり難しい。
【0037】[第2の実施形態:移動可能プロセスの認
証方法の問題点と名札による解決]第1の実施形態で提
示した移動可能プロセスの認証方法には、2つの解決し
なくてはならない問題がある。一つは、プロセスまたは
オブジェクトの所属関係は、理論的には定義されていて
も、プログラムで使用できるような具体的な表現が与え
られていない点である。具体的には、「プロセスAがプ
リンシパルPに所属する場合」などというとき、処理プ
ログラムが、プロセスAからどのようにしてプリンシパ
ルPという情報を知るのかは、一切触れられていない。
【0038】もう一つは、移動可能プロセスと審判と呼
ばれるサーバーとが、相互認証されているという前提で
ある。この点につき、プロセスの認証を論じているのに
その前提として、あらかじめ相互認証されていると仮定
することは、循環論法にならないかという疑問が生じる
かもしれない。しかし、実際には、この仮定は循環論法
ではなく、一種の帰納法の仮定に相当するものである。
しかし、これが帰納法の仮定として、通用するために
は、本発明の認証結果が単に受け入れ側での認証にとど
まらず、受け入れ側と受け入れ側を管理する新たな審判
サーバーにも認証できるような、より強い認証手順が求
められていることを示している。
【0039】この2つの問題を解決するために、移動可
能オブジェクトに対して、名札とよばれる特殊なオブジ
ェクトを対応させる。名札には転送元実行環境のプリン
シパルの識別が記載されており、移動可能オブジェクト
に一対一に対応している。移動可能オブジェクトが所属
しているプリンシパルの識別が記載されている名札オブ
ジェクトを、特にクレデンシャルと呼ぶ。前述の認証に
関する定義2を次のように書きかえると、認証とクレデ
ンシャルの保持とを同一視することが可能なことは、明
らかである。
【0040】クレデンシャルの配布手順 (定義2の変
形):移動可能オブジェクトAがプリンシパルPに属する
ということを次のように帰納的に定める。 (1) プリンシパルPの主体が直接オブジェクトAを生成し
た場合、移動可能オブジェクトAはプリンシパルPに所属
する。このとき、Pの主体はプリンシパルPの識別が記載
された名札をオブジェクトAに対応づける。 (2) Pに所属するあるオブジェクトAnが存在し、オブジ
ェクトAがAnの結果として生じた場合、オブジェクトAは
プリンシパルPに所属する。このとき、オブジェクトAn
はオブジェクトAnの名札を複写してオブジェクトAに与
える。 (3) オブジェクトAがプリンシパルPに所属するのは、上
の(1),(2)の場合に限る。
【0041】[第3の実施形態:影の名札付きクレデン
シャル配布手順]第2の実施形態において、プログラム
の操作対象として、名札を見る場合、任意のオブジェク
トに任意の名札を与えることは現実に可能であるし、他
のオブジェクトがもつ名札を勝手に複写したり、書き換
えたりすることも可能である。このように、名札が上の
クレデンシャル配布手順以外の方法でも容易に割り付け
られる以上、名札とクレデンシャルとの判別が可能な、
より実際的な仕組みが必要である。そこで、上のクレデ
ンシャル配布手順にさらに制限を加えた、影の名札付き
のクレデンシャル配布手順を考える。影の名札とは、選
ばれた名札に一対一に対応づけられたオブジェクトのこ
とで、しかも、名札の内容と影の名札の内容は常に一致
するように、名札には影の名札の内容が自動的に反映さ
れるものと仮定する。
【0042】移動可能オブジェクトAがプリンシパルPに
属するということを次のように帰納的に定める。 (1) プリンシパルPの主体が直接オブジェクトAを生成し
た場合オブジェクトAはプリンシパルPに所属する。この
とき、Pの主体はプリンシパルPの識別が記載された名札
をオブジェクトAに対応つける。この時、その名札と同
じ内容の影の名札を対応させる。 (2) プリンシパルPに所属するあるオブジェクトAnが存
在し、オブジェクトAがオブジェクトAnの結果として生
じた場合、オブジェクトAはプリンシパルPに所属する。
このとき、オブジェクトAnはオブジェクトAnの名札を複
写してオブジェクトAに与える。もしも、その名札に影
の名札が対応している場合、その場合に限り、影の名札
の複写も行う。 (3) オブジェクトAがプリンシパルPに所属するのは、上
の(1),(2)の場合に限る。 この手順だけを使用してクレデンシャルの割付が行われ
ることを仮定するならば、帰納法によって、クレデンシ
ャルが存在することと影の名札が存在することが同値に
なることは、明らかである。従って、あるプロセスが影
の名札を持つならば、そのプロセスの認証を行うことは
可能である。この影の名札付きクレデンシャル配布手順
に相当するシステムをプログラムとして実装することは
可能である。すると、前節において、プロセスの原因-
結果という関係で与えられていた、プロセスの認証を、
影の名札に対応付けられたクレデンシャルというデータ
に基づく認証に置きかえることが可能になる。
【0043】[第4の実施形態:影の名札付きクレデン
シャル配布システムとしての証明書機構]第3の実施形
態で議論されたクレデンシャルを構成する名札と影の名
札の組を、ネットワークで結合されたコンピュータ上に
実装する仕組みとして証明書機構を利用する。ここで
は、名札に相当するものが証明書副本と呼ばれ、それは
オブジェクトと一対一に対応する。(図6参照)第3の
実施形態で影の名札と呼ばれたものは、ここでは証明書
正本として実装される。証明書副本の内容は、証明書正
本の内容によって2重化され、破壊や改ざんから保護さ
れる。証明書正本を証明書副本が置かれているホストと
は異なる厳重な安全対策が実施されているホストに置
く。これによって、影の名札がクレデンシャル以外の名
札とは結合しないことの保証が可能である。さらに、ユ
ーザー・オブジェクト生成時に、プリンシパルの認証を
行った後に、オブジェクトに正副証明書を割り付けるこ
ととする。
【0044】これは、第3実施形態の[影の名札付きク
レデンシャル配布手順]における「(1)プリンシパルPの
主体が直接オブジェクトAを生成した場合、オブジェク
トAはプリンシパルPに所属する。このとき、プリンシパ
ルPの主体は、プリンシパルPの識別が記載された名札オ
ブジェクトをオブジェクトAに対応つける。この時、そ
の名札と同じ内容の影の名札を対応させる。」という個
所に対応する。証明書副本からユーザー・オブジェクト
への参照をもたせるのと同時に、証明書正本からもユー
ザー・オブジェクトへの参照をもたせるているため、2
つの参照がクレデンシャルとプロセスやオブジェクトと
の対応を実現している。万一、副本側の参照が壊れて
も、実装上クレデンシャルからプロセスへの対応は確保
される。
【0045】もう一つ注目すべき点は、証明書副本はプ
ロセスの所有者に属し、証明書正が認証サーバーの所有
者に属しているという仮定を置くと、証明書正本が証明
書副本を知っていることと、証明書副本が証明書正本を
知っていることとが、結果的にオブジェクト同士の相互
認証がとなっている点である。ここで行った仮定が充分
に信頼できるならば、証明書正本、副本間(結果的には
プロセスと認証サーバー間で)、Diffie-Hellam法を実
施することが可能となり、本発明の移動可能プロセスの
認証手順を実現することが可能になる。
【0046】ところで、この機構の背景にある考えは、
どのようにすれば、CORBA・セキュリティ・サービスで
使用されているクレデンシャル・オブジェクト(Creden
tial:信任状)自体に認証効果を与えることができるだ
ろうか、という疑問に答えることにある。CORBA・セキ
ュリティ・サービスのシステムでのクレデンシャルは、
認証時にパスポートや免許証のように提示するだけで認
証が可能となるものではなかった。そのため、本人確認
時に、パスポートや車の運転免許証などの提示するだけ
で認証が可能になるシステムをネット上に形成すること
ができないだろうかと考えた。
【0047】一般に、パスポートなどの証書は、個人が
携帯するパスポートの冊子や免許証のカードそれぞれに
対して、所轄の機関で保存されている管理情報の存在が
前提になっている。それらの情報作成の際、本人確認の
手順が実施される。その手順の一環として、戸籍謄本や
住民票の提出などが義務づけられている。そのため、パ
スポートや免許証を携帯しているという事実によって本
人の認証が行われているのである。もしそれらの証書自
体に疑念がある場合、所轄の機関に証書の真正性の問い
合わせが行われる。証書の偽造はできても、所轄の機関
に保存されている情報の偽造は困難であるため、このよ
うな問い合わせは有効である。
【0048】ネットワーク上をこのような証明書をもっ
たプロセスが移動するとき、証明書とプロセスの組み合
わせを保証する形で転送処理を行う必要がある。このこ
とを保証するために、暗号技術を応用した転送手順の考
案を行った。これは、第3実施形態の[影の名札付きク
レデンシャル配布手順]における「(2)プリンシパルPに
所属するあるオブジェクトAnが存在し、オブジェクトA
がオブジェクトAnの結果として生じた場合、オブジェク
トAはプリンシパルPに所属する。このとき、オブジェク
トAnはオブジェクトAnの名札を複写してオブジェクトA
に与える。もしも、その名札に影の名札が対応している
場合、その場合に限り、影の名札の複写も行う。」とい
う部分に相当する。この手順については、次の第5実施
形態で詳述する。
【0049】[第5実施形態: 証明書を応用したプロセ
ス移動方式]プロセスPxと正副証明書は、図6、図7のよ
うに対応付けられていると仮定する。ここで、プロセス
Pxがドメインaからドメインbへ移動するケースを考え
る。ここで認証サーバーA、B、Cは証明書管理機構とし
て機能し、各ドメインの認証機構をそれぞれAuthA、Aut
hB、AuthCとする。 (1) プロセスPxはAuthAにドメインbへ移動したいという
要求を送る。 (2) サーバーAとプロセスPxとは相互認証を行う。 (3) サーバーAはサーバーBと協議を行い暗号鍵KABを用
意する。この手順の詳細は後述する。 (4) プロセスPxとAuthAは一時的な暗号鍵KAPxを生成す
る。暗号鍵KAPxの合意は、たとえば、Diffie-Hellmanの
鍵交換法を使用して行われる。 (5) AuthAは証明書正本Oを暗号鍵KABで暗号化しKAB[O]
を作る。また、暗号鍵KAPxも暗号鍵KABで暗号化し、KAB
[KAPx]を作る。そしてそれを、プロセスPxに送る。尚、
証明書正本OとKAPxとを連結して暗号鍵KABで暗号化し、
KAB[O|KAPx]を作っても良い。 (6) プロセスPxは自分自身の外部形式PxExを作り、それ
を暗号鍵KAPxで暗号化しKAPx[PxEx]とする。ここで、KA
Px[PxEx]は外部形式PxExの全面的な暗号化ではなく暗号
鍵KAPxを利用したメッセージ・ダイジェスト値を外部形
式PxExに付加したものであっても良い。たとえば、外部
形式PxExの文頭もしくは文末に暗号鍵KAPxを連結し、そ
れに対してメッセージ・ダイジェスト関数を適用する。
このようにして求まったメッセージ・ダイジェスト値と
外部形式PxExをまとめて送付しても良い。 (7) プロセスPxはドメインbのAuth BにKAPx[PxEx]、KAB
[KAPx]、KAB[O]を送り、プロセスPxの移動を申請す
る。 (8) Auth Bは、手順3にて決定した暗号鍵KABを用い
て、KAB[O]から証明書正本Oを再生し、KAB[KAPx]から暗
号鍵KAPxを再生することができる。そして、暗号鍵KAPx
を使用して、KAPx[PxEx]から外部形式PxExを再生するこ
とができる。(KAB[KAPx]は証明書OとプロセスPxとのリ
ンクを表していると解釈してもよい。) (9) 暗号鍵KAPxは、この転送サイクルにおいてプロセス
PxとAuth Aしか知り得ない秘密であり、KAB[KAPx]に暗
号鍵KAPxがあることは、AuthAしか知り得ない。従って
外部形式PxExが正常に解読できた事を持ってプロセスPx
がAuth Aによって認証されたプロセスであることが確認
できる。 (10) Auth Bは、この事実を持って認証サーバ B内に証
明書正本Oを割り付け、さらにその証明書副本Sを証明書
正本Oに基づいて生成する。外部形式PxExから実行形式P
xを再生し、証明書正本O, 証明書副本S, プロセスPx間
の対応を形成しプロセスPxの実行を許可する。 (11) この時点で、証明書正本O,証明書副本S の組を使
った認証が、ドメインb上でも可能となる。ドメインbか
らドメインcへの移動の際には、上の認証サーバ Aとド
メインaを認証サーバ Bとドメインbに、認証サーバ Bと
ドメインbを、認証サーバ Cとドメインcにそれぞれ置換
えてこの手順を実行すれば良い。
【0050】注意1、上記手順(第5実施形態)の第7項
を契機として、Auth A上で管理されている証明書正本O
ならびにその証明書副本Sの無効処置が必要となる。こ
れをどの時点に実施するかは本方式の具体的な実装に依
存する。逆に、無効処置を行わない場合、本手順は、プ
ロセスPxを他ドメインへ複写する手順として利用可能で
ある。この場合、相手先認証機構は、証明書を生成する
際、複写であることを証明書に明示すべきである。 注意2、上記手順(第5実施形態)の第4項にて行われる
共有鍵KAPxの生成は、プロセスPxとAuth A間にて行われ
るが、暗号鍵KAPxの安全性に配慮するならば、Auth Aの
範囲を一層限定して、プロセスPxとAuth A内の認証サー
バAとの間で行われるほうが、望ましい。ただし、実装
上の選択として、効率性、負荷分散の観点から別の鍵管
理機構などをAuth A内に設置して、そことプロセスPxと
の間で暗号鍵KAPxを生成することも考えられる。また、
上記(第5実施形態)第8項でAuth Bが暗号鍵KABを用い
る場合も、暗号鍵KABが認証サーバ Bの外部に流出しな
いような配慮を行うべきである。 注意3、上記(第5実施形態)第5項から第7項の手順に
おいて、KAB[O]と、KAB[KAPx]をプロセスPx経由にてAut
h Bに送っているが、その一方もしくは双方を、直接、A
uth Bに送るなどの手順変形は可能である。基本的にそ
れらの変形は上記手順と同等のものと見なして良い。 注意4、応用上、プロセスPxの送信元実行環境と受け入
れ側実行環境との相互認証が別途必要となる場合もあ
る。ただし、これは、本手順で扱っている移動時のプロ
セスに対する認証とは別の手順である。
【0051】[第5実施形態における重要事項]第5実施
形態の手順には4つの重要事項がある。その1つは、プ
ロセスPxの外部形式PxExが確かにプロセスPxによって作
られたものであることを、移動先であるドメインbが納
得できる根拠を与える事にある。そのために、暗号鍵KA
PxというプロセスPxとAuth Aしか知る事のできない秘密
による痕跡をプロセスPxの外部形式PxExに付加する事に
よって、根拠をあたえる。暗号鍵KAPxは外部形式PxEx
が確かにプロセスPxの結果であることを主張すると同時
に、AuthAによる公認された結果でもあることも主張し
ている。あるいは、プロセスPxとAuth Aによる連名の署
名として機能すると考えても良い。その2つ目は、プロ
セスPxの所属を明示することである。これは、本発明の
前半で述べた証明書正本副本によって行われる。この証
明書正本副本は改ざん偽造が困難なので信頼できる。さ
らに、KAB[KAPx]によって、証明書正本副本とプロセスP
xが確かに対応することが示されている。3つ目は、暗号
鍵KAPxを生成する際の認証サーバ AとプロセスPxとの相
互認証である。これは、証明書正副間の双方向のリンク
によって行われる。(従来技術でも記した通り、プロセ
スPxにプロセス生成者本人の秘密鍵やパスワードを保持
させる事は、危険であって意味を成さない。秘密以外の
方式でプロセスPxの認証が可能な方式を開発する必要が
ある。) 双方向のリンクを持つデータ構造は、そのど
ちらか一方の所在が確定できれば、他方の所在も確定で
きる。しかも双方のデータが論理的に同じ物を保持する
場合、データの変更は双方のデータの変更を必要とす
る。従って、そのようなデータのどちらか一方の安全を
保障すれば、他方のデータを容易に復元し得る。このよ
うなデータの片方づつを、独立したノードに保持させる
事で、ノード間の相互認証が可能となる。ノード間での
相互認証が確立すると、Diffie-Hellman方式などによっ
て、ノード間で共通の秘密鍵を生成することが可能とな
る。4つ目は、認証の権限の移譲である。認証サーバA
とプロセスPxの相互認証が行われたとき、認証サーバ
A、B、Cが相互に信頼の鎖で結ばれている場合、認証サ
ーバ Aは認証サーバ Bや認証サーバ CにもプロセスPxを
認証する方法を教える事を可能とする。その方法が、証
明書の対に他ならない。認証サーバ AとプロセスPxとの
間に証明書の対が形成されているとき、プロセスPxがド
メインbに移動後、同じような証明書の対を認証サーバ
BとプロセスPxとの間でも形成できるようにする。する
とプロセスPxは認証サーバ BとプロセスPxとの間にある
証明書を足がかりに、認証サーバ BとプロセスPxとの相
互認証を確立し、次の認証サーバCへと移動する事が可
能になる。移動後、プロセスPxは認証サーバ Cとの間に
証明書の対を確立する。これは、多段階の認証が実現さ
れることを意味する。(malti hop Authentication)
【0052】[第6実施形態:各種の攻撃への対処方法]
第5の実施形態において、証明書正本副本には改ざん、
偽造などさまざまな攻撃が起こり得る、以下ではそれら
の攻撃に対する対処方法を概説する。 <6.1 証明書の偽造に対抗する事>このように証明書正
本副本をリンクによって相互参照させることによって、
偽造、改ざん、不正コピーへの対抗が可能となる。通
常、不正行為はユーザー環境側で行われるが、ユーザー
環境側にて証明書を偽造しても、証明書管理機構側にそ
のデータに対応する証明書の正本を作成する事が困難な
ため、偽造である事を容易に検出する事が可能である。
(図8参照) <6.2 証明書の不正コピーに対抗する事>悪者は、正規
の証明書の不正コピーを作り、あたかもそれを正規の証
明書であるかのように使用するかもしれない。この場
合、正規の証明書の正副には、厳密に一対一対応が形成
されているが、不正コピーからは、証明書正に向かう参
照があっても、証明書正から証明書副への参照は正規の
証明書を指し、不正コピーは参照されないため、証明書
管理機構からの問い合わせに矛盾が生じ不正が発覚して
しまう。 <6.3 証明書の改ざんに対抗する事>悪者は、正規の証
明書副を改ざんする場合もある。しかし、証明書正の内
容を改ざんすることは困難なので、適当な周期で証明書
正と証明書副との照合手続きを実行したり、証明書デー
タを利用する際、事前に照合を行う事で、改ざんの有無
を検出する事ができる。また、改ざんを発見したとき、
改ざんされた証明書を改ざんされていない証明書に基づ
いて、正規の証明書へ復元する事も可能である。 <6.4 ユーザー・プロセスの偽装に対抗する事>あるユ
ーザー・プロセス(オブジェクト)が所持する正規の証
明書副の参照を手に入れ、別のプロセスがそのユーザー
・プロセスを偽装するかもしれない。この問題は、セキ
ュリティ・システムとユーザー・システムとの間のイン
ターフェースを工夫し、ユーザー・プロセスと証明書と
の間も一対一対応を形成させることで解消する。この様
子は図6にて示されている。このようなプロセス管理機
構を作ると、偽装したプロセスからの要求に対して、そ
の証明書の正本を保持する証明書管理機構からの逆方向
の問い合わせに矛盾が生じ、偽装が発覚してしまう。
【0053】<第7実施形態:不正検出アルゴリズムへ
の応用>不正コピー、偽造、偽装といった不正に対する
検出方法は、いずれも証明書正本と証明書副本ならびに
プロセス(あるいはオブジェクト)との相互参照が規定
通りかどうかを確認するものである。これは以下のよう
な手順にて行う。 プロセスPからの要求に対する手順(最も単純な場合) 第7実施形態では、プロセスをP,プロセスPの参照を
P’、証明書正本をO,証明書副本をS、証明書管理機構
をAとする。プロセスPの参照から、証明書副本Sの参
照、証明書正本Oの参照それぞれを取り出すことが可能
である。ここで、プログラム言語的にその参照の同一性
を判定できる場合には、証明書副本Sが証明書正本Oと
プロセスPを参照し、かつ証明書正本Oが証明書副本S
とプロセスPを参照していることを確認できれば、認証
されたと見なして良い。このような同一性の判定がプロ
グラム的にはサポートされていない場合、次のような手
順にて参照の相互関係を確認する。 (1)Pから、Sを経由してOに対して認証要求コールを送
る。 (2)Oは要求コールの戻りとしてXを戻す。 (3)Oは自分のもつプロセスの参照P'を使用して先ほど
与えた乱数Xを戻す事を要求する。 (4)P'が乱数Xを戻した場合、P'とPは等しいと見な
す。PとP'とが異なる場合、P'は乱数Xの値を知らな
いはずである。 (5)PからSを経由して再度Oに対する認証要求コールを
送る。 (6)Oは要求コールの戻りとして乱数Yを戻す。このとき
乱数Yは乱数Xと異なるものでなくてはならない。 (7)Oは自分のもつプロセスの参照P'を使用して先ほど
与えた乱数Yを戻す事を要求する。 (8)P'が乱数Yを戻した場合、P'とPは等しいと見な
し、認証されたものとする。 ここでは、(1)から(4)にかけての手順と(5)から(8)にか
けての手順のように、確認手順を2回行ったが、この回
数は多ければ多いほど認証の確実性が向上する。最低2
回は行う必要がある。
【0054】<第8実施形態:証明書副本からの要求に
対する証明書正副同士の確認手順>上とほぼ同様な手順
にて、証明書副本の偽造、不正コピーの検出も可能であ
る。以下にその手順の最初の4項を示す。これも2回以上
繰り返す必要がある。ここでも、プロセスをP,プロセ
スPの参照をP’、証明書正本をO,証明書副本をS、証
明書管理機構をAとする。 (1)SからOに対して認証要求コールを送る。 (2)Oは要求コールの戻りとして乱数Xを戻す。 (3)Oは、自分の(証明書副本S自身の)もつ証明書副本
Sの参照S'を使用して先ほど与えた乱数Xを戻す事を要
求する。 (4)S'が乱数Xを戻した場合、S'とSは等しいと見なす。
SとS'とが異なる場合、S'は乱数Xの値を知らないはず
である。 上記のアルゴリズムによる認証には、認証対象となるプ
ロセスやオブジェクトからの要求を受けた際のみに有効
な認証手順である。さらに、複数の証明書管理機構の関
与も考慮にはいれていない。そこで、複数の証明書管理
機構の関与する場合で、認証側が認証対象オブジェクト
に対して、主体的に実施する認証手順を以下に記述す
る。この際、少なくとも同一環境内におけるオブジェク
トの参照は、リモート参照、ローカル参照の区別なく参
照同士の一致不一致を検出する手続きが存在することを
仮定する。
【0055】<第9実施形態:複数の証明書管理機構が
関与する場合の応用例:認証側が認証対象のオブジェク
トに対して主体的に実施する認証手順>この認証手順と
して、次の3つの場合を検討する。手順1は証明書管理
機構AがプロセスPの参照を得て、Pの認証を行う場合で
あり、手順2は、プロセスP1がプロセスP2の参照を得てP
2の認証を行う場合であり、手順3はプロセスP1がプロセ
スP2からの要求を受け、P2を認証する場合である。 <認証手順1:証明書管理機構AがプロセスPの参照を得
て、Pの認証を行う場合> (1) AはPに対して証明書副本Sの提示を要求する。 (2) Aは証明書副本Sから証明書正本Oの参照を得る。 (3) Aは正本Oから正本Oの所属する証明書管理機構Bへの
参照を得る。(注意:証明書正本からその正本が所属す
る証明書管理機構への参照は標準的な手続きとして確立
されていることを仮定する。) (4) AはBとの相互認証を行う。 (5) もしも、相互認証に失敗した場合には、Pは認証さ
れなかったものとする。 (6) AはBに正本O、副本S、プロセスPを渡し、Pの照会を
要求する。(注意SとPだけでもよい) (6-1) BはOとSとの内容の照合をする。 (6-2) 内容の照合で異常があれば、認証に失敗したこと
をAに通知する。 (6-3) Bは正本に含まれるプロセスの参照P'を取り出
し、P'にP'とPとの一致確認を要求する。 (6-4) P'がPと一致する場合、BはAに認証成功の通知を
する。 (6-5) P'がPと不一致の場合、BはAに認証の失敗を通知
する。
【0056】<認証手順2:プロセスP1がプロセスP2の
参照を得てP2の認証を行う場合> (1) P1は自分の所属するドメインの証明書管理機構に対
してP2を渡して上の手順1「証明書管理機構Aがプロセ
スPの参照を得て、Pの認証を行う手順」を実施する。
【0057】<認証手順3:プロセスP1がプロセスP2か
らの要求を受け、P2を認証する場合> (1) プロセスP2はプロセスP1に要求を発する。この際、
証明書副本S2を提示する。 (2) P1は乱数Xを戻す。 (3) P1はS2に保持されているプロセスの参照P2'に対し
て、数Xの問い合わせ、ならびに要求の再送を依頼す
る。 (4) P2はP1に再度要求を行う。 (5) P1は数Yを戻す。 (6) P1はS2に保持されているプロセスの参照P2'に対し
て数Yの問い合わせを行う。 (7) X,Yのいずれかの一致が確認されない場合認証は失
敗したものとする。 (8) P1は自分の所属するドメインの証明書管理機構Aに
対してS2を渡して証明書副本S2の照合を依頼する。 (8-1) AはS2から証明書正本O2を取り出す。 (8-2) O2からO2を管理する証明書管理機構Bの参照を取
り出す。 (8-3) AとBとの相互認証を行う。 (8-4) もしも、相互認証に失敗した場合、AはP1に認証
の失敗を通知する。 (8-5) AはBにO2、S2を渡し照会を依頼する。 (8-5-1) BはO2とS2の照合を行う。 (8-5-2) 照合に異常が発見された場合、BはAに認証の失
敗を通知する。 (8-5-3) 照合に異常が発見されなかった場合、BはAに認
証の成功を通知する。 (8-6) AはBからの通知にしたがって、P1に認証の成功、
失敗のいずれかを通知する。
【0058】注意1、上のO2とS2との照合は次のように
行う。 (1)O2とS2との対応する項目の一致不一致を確認するこ
とで、内容面での改ざんの有無を調べる。 (2)改ざんされていないことが確認できた場合、O2から
副本S2'への参照を取り出し、S2'とS2との一致を確認す
る。 注意2、上述の手順で、認証要求を発する側は、可能な
らば、プロセスの参照、プロセスが保持している副本の
参照、副本が保持している正本の参照の3組をあらかじ
め取り出し、その3組の整合性を確認するようにし、副
本に保持されている正本の参照の利用をなるべく避ける
方向で実装するほうがよい。それは、実際には誤った正
本の参照が書き込まれているにもかかわらず、処理直前
に一時的に正しい正本の参照を与えることで、認証を通
過させ、認証後にまた誤った正本の参照を再設定するこ
とにより、プロセスに誤った正本を信用させる不正が可
能なためである。
【0059】<第9実施形態:不正検出アルゴリズムの
限界とその対策>第8実施形態のアルゴリズムの限界
は、プロセスPとプロセスの参照P'とが異なるプロセ
スでありながら、裏で繋がっている場合、バケツリレー
式の偽装が可能になってしまうことである。裏でつなが
っている場合とは、公認されたプロセスP'自体が不正
なプロセスPと共謀した場合である。しかし、この場合
は、責任は公認されたプロセスP’自身にある。プロセ
スP'自身の秘密を教えることに危機を招いた責任があ
るからである。この場合は、公認プロセスP’が不正プ
ロセスPから乱数X、Yの値を教えてもらい、公認プロ
セスP'自身が不正プロセスPのふりをすることにもな
る。このような、プロセスの偽装を見破るには、実行環
境レベルのプロセス管理情報を利用するとよい。証明書
正副にプロセスidを参照以外に登録し、プロセスの参照
Pをプロセス管理情報に渡して、そのプロセスidを受け
取り、証明書内のidと一致/不一致を確認すればよい。
これらは、OSや実行環境に依存する実装上の詳細事項で
ある。
【0060】<第10実施形態:オブジェクト間の参照
方式の変形>参照方式には、基礎となるシステムに応じ
て、幾つかの変形が発生する。証明書同士や証明書とプ
ロセスを結合する参照は、分散オブジェクト・システム
上では、オブジェクトのローカルな参照もしくは、リモ
ート・オブジェクトの参照となる。ローカルな参照は参
照する側とされる側のオブジェクトがともに同一環境内
に位置する場合に使用される。2つのオブジェクトが異
なる環境に置かれている場合、その参照はリモート・オ
ブジェクトの参照になる。ローカルな参照が使われる場
合、参照されるオブジェクトの(ローカルな)メソッド
を呼出す事ができ、リモートの参照が使用される場合に
は、参照されるオブジェクトに対して、リモート・メソ
ッド呼出し(Remote Method Invocation)が可能であ
る。第7実施形態で述べた「不正検出アルゴリズム」は
基本的にはこのようなオブジェクト同士の参照を利用し
た、ローカルまたはリモートのメソッド呼出しによって
実施されることを想定している。オブジェクト指向技術
を使用していないシステム上でも「不正検出アルゴリズ
ム」の各手順は次のように実施することが可能である。
証明書やプロセス管理データを定められたデータ構造を
もつデータ・ブロックとして実装する。これらのデータ
・ブロックを互いに識別するために、各ブロックごとに
一意の識別子をあたえる。この識別子はユニークな数値
や文字列など他と明確に区別可能な任意の型のデータで
あってよい。サーバー・プログラムなどこれらのデータ
・ブロックが置かれている場を環境と呼ぶ事にすると、
これらの識別子は、同一環境内では、一意性を保証する
必要がある。これらの識別子に加えて、証明書やプロセ
ス管理用のデータが所属する環境と通信するための通信
制御用の識別情報も識別子と合わせてデータ・ブロック
に保持させる。通信制御用の識別情報には、例えばホス
ト名、ipアドレス、ソケット番号、ポート番号など、基
礎となる通信システムに応じてさまざまなものがある。
この(識別子:通信制御用識別情報)の組がオブジェク
ト間の参照に対応する。
【0061】このとき、リモート・メソッド呼出しに対
応する手続きの呼出しは次の通りである。呼出しの往路
は、通信制御用識別情報によって定められる相手側環境
に対して、処理要求内容を示すコマンド・コードと操作
対象となるデータ・ブロックの識別子、そして操作に必
要となる任意のパラメータ情報をメッセージとして送信
することである。呼出しの処理本体の実行は、上記のメ
ッセージを受け取った環境側が、識別子で指定される操
作対象に、コマンド・コードとパラメータに従った処理
を実施する事である。この処理の実施で得られる情報を
応答メッセージとして環境から送信元へもどすことが、
呼出しの復路に対応する。システムによっては、この一
連の操作をRPC(Remote Procedure Call:遠隔手続き呼
出し)によって、通常の手続き呼出しのような外観にて
実施する事が可能である。このように、上記の手順はオ
ブジェクト指向のシステムでなくとも、通信回線その他
によって互いに交信可能な系同士であれば実施可能であ
る。
【0062】<第11実施形態:証明書とユーザー・オ
ブジェクトとの一体化>セキュリティ機構がOSや実行環
境に標準的に装備されている環境などでは、ユーザー・
オブジェクトやプロセスに証明書を直接埋め込むことも
考えられる。(図11参照)(オブジェクト指向言語を使
用する場合、ユーザー・オブジェクトのクラスを証明書
オブジェクトのサブ・クラス等として実現することにな
る。)この場合でも証明書とユーザー・オブジェクトは
一対一に対応するので、これは図6のような参照によっ
てユーザー・オブジェクトとの対応付けを行う仕組みの
変形であると考えられる。この長所は、参照等を改変さ
れる心配が無くなるため、外部からの攻撃に強くなり、
また認証時の処理も証明書の真正性の確認だけで済む点
にある。また、オペレーティング・システムの核などに
本証明書方式を組み込む場合、プロセス管理ブロックと
かタスク管理ブロックなどとよばれる、実行制御の対象
となるプロセスを、管理するデータ構造の一部として、
本証明書に使用することも可能である。この場合は、ち
ょうど図11のケースと図6のケースの中間にあたる変
形であると考えられる。
【0063】<第12実施形態:証明書管理機構自体の
偽装への対抗>これまでは、証明書の正本と副本のいず
れかは信頼できるということを暗黙の仮定としてきた。
しかし、副本が改ざんされ、副本が参照している正本も
本来の証明書管理機構とは異なるニセの証明書管理機構
上に作られている場合も考慮する必要がある。この場
合、本来の副本が改ざんされたのか、それとも全くの偽
造なのかの区別が必要である。この問題に対処する際、
副本が正しい正本を参照していると仮定することはでき
ない。ただし、最低限の前提として、本来の証明書管理
機構上には、正規の正本が存在していることは前提とす
る。(逆に、ユーザー側のシステム上に正規の副本があ
ると仮定してもほぼ同じ手法で対策を立てる事ができ
る。)さらに、セキュリティ・ドメイン上に認証者(Au
thenticator)が存在する事を前提とする。認証者はセ
キュリティ・ドメイン上における正規の証明書管理機構
の所在を管理する。また、プロセスが所属するドメイン
の認証者への参照は、プロセスが実行されているユーザ
ー環境に置かれているセキュリティ管理機構やオペレー
ティング・システム呼出し等のあらかじめ定められたイ
ンターフェースを介して取得されるものとする。このこ
とによって、証明書の真正性に依存する事無く、プロセ
スの所属するドメインに対応する認証者への要求を発す
る事が可能である。ユーザー環境が正規のドメインに所
属している場合、正規の認証者が必ず参照される。正規
の認証者は正規の証明書管理機構の所在が分かる。従っ
て、証明書の正本の参照に対して、当該参照に対応する
証明書が実在するかどうかを、証明書管理機構自体が内
部で管理している証明書表などに基づいて、確認する事
が可能である。証明書正本の真正性をこのように確定で
きるので、それを使用して証明書副の真正性の確定が可
能である。
【0064】一方、ユーザー環境が正規のドメインに所
属していない場合、正規の認証者が参照されるという保
証はない。正規の認証者の参照が得られる場合、上記の
手順で証明書副の真正性の確認が得られる。正規の認証
者の参照が得られない場合、その認証者は、ニセの証明
書管理機構を使用し、嘘の認証を行うかもしれない。認
証者がニセの証明書管理機構を与えたとしても、認証の
確認が外部にある正規のドメインの要求で行われている
場合、そのドメインの証明書管理機構と認証者が与えた
証明書管理機構との相互認証を行う事で、ニセの証明書
管理機構を見破る事が可能である。認証の確認が外部の
ドメインからではない場合、認証は行われるが、そのド
メインの外には認証結果の効力が及ばない。従って、外
部にある正規のドメインには影響を与えない。
【0065】上の記述を明確化することで、以下に述べ
る証明書の偽装ならびに改ざんに対抗する手順が得られ
る。この際の少なくとも、同一環境内におけるオブジェ
クトの参照に関してリモート参照、ローカル参照の区別
なく参照同士の一致不一致を検出する手続きが存在する
ことを前提とする。
【0066】<偽装ならびに改ざんへの対抗手順>ここ
では、証明書副本をS、正本をO、認証者をAu、証明書管
理機構をAとする。 (ステップ1:正規の正本Oの参照を獲得する。) (1) 副本Sは認証者Auに対して証明書管理機構Aの問い
合わせを行う。 (1-1) AuはAを戻す。 (2) SはAに対してSに対応する正本を要求する。 (2-1) AはSに含まれている正本の参照O'を取り出す。 (2-2) O'に対応する正本Oが存在し、Oに含まれている副
本の参照S'が副本Sと一致する場合AはSに対してO'を戻
す。 (2-3) 一致しない場合、証明書管理機構Aは、A自身が管
理する全ての正本Oiに対して、Oiに含まれている副本の
参照SiがSと一致するものを探す。 (2-4) このとき、ある正本Ojに含まれている副本の参照
SjがSと一致するならば、AはSに対して当該正本Ojを戻
す。 (2-5) そのようなOiが存在しない場合、AはSに対して無
効を通知する。 (3) Aから無効通知を受けたSは自分が偽造されていると
判断する。 (ステップ2:正本と副本の照合ならびに修正を行う。) (1) Sは、自分の持つ各項目と対応するOの項目とを比較
する。ある項目が一致しない場合その項目をOの項目で
置きかえる。
【0067】<第13実施形態:証明書管理機構A、B間
の協議手順の詳細>前述した第5実施形態(3)の「AとB
との協議」によって暗号鍵KABを生成する手順について
は、A,B間の認証方式に応じてさまざまな方式が考えら
れる。以下にいくつかの例を提示する。 例1.秘密鍵KCを証明書管理機構A,B間で共有し、暗号
鍵KABを証明書管理機構B側で生成する方式。 (1)AからBへKABの生成要求を発する。 (2)BからAに乱数R1をチャレンジとして送る。 (3)Aは、R1の末尾に0を連結したものを秘密鍵KCで暗号
化したKC[R1|0]と、さらにBに対するチャレンジとして
乱数R2をBに送る。 (4)BはR2の末尾に1を連結したものを秘密鍵KCで暗号化
したKC[R2|1]をAに送る。さらに、Bは、適当な乱数を発
生させてKABとし、それをKCで暗号化したKC[KAB]と、KA
Bを利用した通信セッションを識別するためのセッショ
ンidとを、Aに送る。 (5)AからBに、KABの受理の確認を行う。たとえば、A
は、セッションidと日付を連結させたメッセージをKAB
で暗号化したKAB[セッションid|日付]をBに送ってもよ
い。
【0068】例2.秘密鍵KCをA,B間で共有し、KAB生成
にDiffie-Hellman鍵交換方式を使用する方式。ここでp
を素数、gをある整定数。modを法演算とする。このp
とgとは事前に合意してあってもよいし、一方から他方
へ通知してもよい。このとき関数P(x)をP(x)=gx mod p
によって定める。 (1)AからBへ暗号鍵KABの生成要求を発する。 (2)BからAに乱数R1をチャレンジとして送る。 (3)Aは、R1の末尾に0を連結したものをKCで暗号化した
KC[R1|0]と、Bに対するチャレンジとしての乱数R2と、
秘密の数RAを発生させて法関数とした関数P(RA)とを、B
に送る。 (4)Bは、R2の末尾に1を連結したものをKCで暗号化した
KC[R2|1]と、秘密の数RBを発生させて法関数とした関数
P(RB)とを、Aに送る。このとき、P(RA・RB)=gRA・RB mod
p = P(RA)RB mod p = P(RB)RA mod p がKABとなる。ま
た、そしてKABを利用した通信セッションを識別するた
めのセッションidもBからAに送る。 (5)AからBに、KABの受理の確認を行う。たとえば、セッ
ションidと日付を連結させたメッセージをKABで暗号化
したKAB[セッションid|日付]を、AからBに送ってもよ
い。
【0069】例3. 秘密鍵KCをA,B間で共有し、KCを暗
号鍵KABとする方式。この方式は認証者にKCを知らせる
等KCのセキュリティに問題があるが、効率的である。 (1)AからBへセッションid生成要求を発する。 (2)BからAに乱数R1をチャレンジとして送る。 (3)Aは、R1の末尾に0を連結したものをKCで暗号化した
KC[R1|0]と、Bに対するチャレンジとして乱数R2とを、B
に送る。 (4)Bは、R2の末尾に1を連結したものをKCで暗号化した
KC[R2|1]と、通信セッションを識別するためのセッショ
ンidとを、Aに送る。 (5)AからBに、セッションidの受理の確認を行う。この
場合、単にACK(?)を送るだけでもよい。
【0070】例4. A,B間は公開鍵暗号方式による署名
によって認証を行う方式。この場合、KABはDiffie-Hell
man鍵交換方式を利用して生成するとよい。ここでpを
素数、gをある整定数。modを法演算とする。このpと
gとは事前に合意してあってもよいし、一方から他方へ
通知してもよい。このとき関数P(x)をP(x)=gx mod pに
よって定める。 (1)AからBへKAB生成要求を発する。このとき秘密の数RA
を生成し関数P(RA)を計算する。この値にAの署名を付加
してBに送る。 (2)Bは、秘密の数RBを生成する。そして関数P(RB)を計
算し、その値にBの署名を付加してAに送る。このとき、
P(RA・RB)=gRA・RB mod p = P(RA)RB mod p = P(RB)RA mo
d p が暗号鍵KABとなる。さらに、乱数R1を発生させKAB
[R1]をチャレンジとしてBからAに送る。またセッション
idを生成しそれもBからAに送る。 (4)AはR1の末尾に1を連結したものをKABで暗号化したK
AB[R1|1]をBに送る。
【0071】例5.A,B間は公開鍵暗号方式による暗号
化によって認証を行う方式。この場合、暗号鍵KABはDif
fie-Hellman鍵交換方式を利用して生成するとよい。こ
こでpを素数、gをある整定数。modを法演算とする。
このpとgとは事前に合意してあってもよいし、一方か
ら他方へ通知してもよい。このとき関数P(x)をP(x)=gx
mod pによって定める。 (1) AからBへ暗号鍵KABの生成要求を発する。このとき
秘密の数RAを生成し関数P(RA)を計算する。この値をBの
暗号鍵KBにて暗号化したKB[P(RA)]をBに送る。 (2) Bは、秘密の数RBを生成する。そして関数P(RB)を計
算し、その値をAの暗号鍵KAにて暗号化したKA[P(RB)]を
Aに送る。このとき、P(RA・RB)=gRA・RB mod p = P(RA)RB
mod p = P(RB)RA mod p が暗号鍵KABとなる。さらに、
乱数R1を発生させKAB[R1]をチャレンジとして送る。ま
たセッションidを生成しそれもBからAに送る。 (3) AはR1の末尾に1を連結したものをKABで暗号化した
KAB[R1|1]をBに送る。
【0072】<第14実施形態:証明書を応用したプロ
セス移動方式の変形>第13実施形態の例3ではA、B間
での共通鍵KABとしてAとBとが相互認証のために元々合
意していた鍵KCを利用していた。この例では、セッショ
ンidを確定する都合上A,B間では協議の手順が実行され
ていたが、共通鍵KABとして無条件にKCを使用し、セッ
ションidの設定も省略してしまうとA,B間の協議のステ
ップ自体を省略する事もできる。この方式は、第13実
施形態の例3で述べた方式の変形であると考えられる
が、きわめて効率的である反面、KCが破られる危険があ
ること、以前に処理されたKAPx[PxEx]、KC[O]、KC[KAP
x]からなる転送メッセージをそっくり複写したものを認
証者に与えると、認証者が受理してしまう恐れがあるこ
となどの欠点をもつ。そのため、KCを適当な周期で更新
するとか、Pxからのメッセージにはタイムスタンプを連
結して暗号化するなどの処置が必要である。またこの手
順は、Kerberos認証システムで使用されている認証手順
にも類似しているが、Kerberosシステムは人物など動か
ない対象の認証システムであるのに対し、本方式はプロ
セスのような処理にともなって内容が変化するデータに
対する認証ならびに移動の手順であること、さらに証明
書もこの移動にともなって認証機関の間を移動していく
事など、Kerberosシステムとは目的や手法が大きく異な
る。
【0073】この変形方式の手順を以下に示す。ここ
で、プロセスPxがドメインaからドメインbへ移動する
ケースを考える。ここでサーバーA、B、Cは証明書管理
機構として機能し、各ドメインの認証機構をそれぞれAu
thA、AuthB、AuthCとする。サーバーAとサーバーBとの
間にはあらかじめ暗号鍵KCについての合意がある。 (1)プロセスPxは認証機構AuthAにドメインaからドメイ
ンbへ移動したいという要求を送る。 (2)サーバーAとPxとの相互認証を行う。この際、ドメイ
ンaの認証者によるAの認証と、第7実施形態の「不正検
出アルゴリズム」によるPxの認証が行われる。 (3)PxとAuthAは一時的な暗号鍵KAPxを生成する。KAPxの
合意は、たとえば、Diffie-Hellmanの鍵交換法を使用し
て行われる。 (4)AuthAは証明書正本OをKCで暗号化しKC[O]を作る。ま
た、KAPxもKCで暗号化し、KC[KAPx]を作る。そしてそれ
を、Pxに送る。(OとKAPxとを連結してKCで暗号化し、K
C[O|KAPx]を作っても良い。) (5)プロセスPxは自分自身の外部形式PxExを作り、それ
をKAPxで暗号化しKAPx[PxEx]とする。(ここで、KAPx[P
xEx]はPxExの全面的な暗号化ではなくKAPxを利用したメ
ッセージ・ダイジェスト値をPxExに付加したものであっ
ても良い。たとえば、PxExの文頭もしくは文末にKAPxを
連結し、それに対してメッセージ・ダイジェスト関数を
適用する。このようにして求まったメッセージ・ダイジ
ェスト値とPxExをまとめて送付しても良い。) (6)プロセスPxはドメインbの認証機構AuthBに、KAPx[Px
Ex]、 KC[KAPx]、 KC[O]を送り、プロセスの移動を申請
する。 (7)AuthBはKCをあらかじめ知っているので、KC[O]から
証明書Oを再生し、KC[KAPx]からKAPxを再生することが
できる。そして、KAPxを使用して、KAPx[PxEx]からPxEx
を再生することができる。 (8)KAPxはこの転送サイクルにおいてPxとAuthAしか知り
得ない秘密であり、KC[KAPx]にKAPxがあることは、Auth
Aしか知り得ない。従ってPxExが正常に解読できた事を
持ってPxがAuthAによって認証されたプロセスであるこ
とが確認できる。 (9)AuthBは、この事実を持ってサーバーB内に証明書Oを
割り付け、さらにその副本Sを正本Oに基づいて生成す
る。PxExから実行形式Pxを再生し、O, S, Px間の対応を
形成しPxの実行を許可する。 (10)この時点で、O, S の組を使った認証がドメインb上
でも可能となる。ドメインbからドメインcへの移動の際
には上のAとaをBとbに、BとbをCとcにそれぞれ置換えて
この手順を実行すれば良い。
【0074】注意1:上記の第6項を契機としてサーバー
A上で管理されている証明書Oならびにその副本Sの無効
処置が必要となる。これをどの時点に実施するかは本方
式の具体的な実装に依存する。逆に、無効処置を行わな
い場合、本手順は、プロセスを他ドメインへ複写する手
順として利用可能である。この場合、相手先認証機構
は、証明書を生成する際、複写であることを証明書に明
示すべきである。 注意2:上記手順の第3項にて行われる共有鍵KAPxの生成
は、Px、AuthA間にて行われるが、KAPxの安全性に配慮
するならば、AuthAの範囲を一層限定して、PxとAuthA内
のサーバーAとの間で行われるほうが、望ましい。ただ
し、実装上の選択として、効率性、負荷分散の観点から
別の鍵管理機構などをAuthA内に設置して、そことPxと
の間でKAPxを生成することも考えられる。また、第7項
でAuthBがKCを用いる場合も、KCがサーバーBの外部に流
出しないような配慮を行うべきである。 注意3:上記第4項から第6項の手順でKC[O]とKC[KAPx]を
Px経由にてAuthBに送っているが、その一方もしくは双
方を直接AuthBに送るなどの手順の変形は可能である。
基本的にそれらの変形は上記手順と同等のものと見なし
て良い。 注意4:応用上、プロセスの送信元実行環境と受け入れ
側実行環境との相互認証が別途必要となる場合もある。
ただし、これは、移動時のプロセスに対する認証とは別
の手順である。
【0075】<第15実施形態:セキュリティ・ドメイ
ン内でのプロセス移動に関する方式の変形>第12実施
形態、第14実施形態での方式は異なるセキュリティド
メインa、b間をプロセスが移動する際の、証明書を利用
したプロセスの認証ならびに移動、そして証明書も証明
書管理機構AからBに移動させる場合の方式であった。プ
ロセスはこのような異なるセキュリティ・ドメインへの
移動に限らず同じセキュリティ・ドメイン内での異なる
実行環境間を移動する場合もあり得る。この場合、方式
はより単純化した形へ変形される。もっとも単純な場合
は、移動のセッションを識別するセッションidだけを割
り付け、プロセスの外部形式を生成したのち、その外部
形式にセッションidを付加して移動先の環境に送付する
方式である。その方式よりも多少セキュリティに配慮し
た変形を以下に示す。この方式は、同一セキュリティ・
ドメイン内の移動の方式としても捕らえる事ができるの
みならず、ローカル・エリア・ネットワークなどに単一
の証明書管理機構を設置した小規模なネットワーク環境
内だけで移動プロセスを使用する場合の標準的な移動手
順としても捕らえる事ができる。ここでは、プロセスPx
がドメインa内の環境E1からE2へ移動するケースを考え
る。
【0076】ここでサーバーAは証明書管理機構として
機能し、ドメインaの認証機構をAuthAとする。 (1)PxはAuthAにドメインa内の環境E2へ移動したいとい
う要求を送る。 (2)サーバーAとPxとの相互認証を行う。この際、ドメイ
ンaの認証者によるAの認証と、すでに述べた「不正検出
アルゴリズム」によるPxの認証が行われる。 (3)PxとAuthAは一時的な暗号鍵KAPxを生成する。KAPxの
合意は、たとえば、Diffie-Hellmanの鍵交換法を使用し
て行われる。 (4)プロセスPxは自分自身の外部形式PxExを作り、それ
をKAPxで暗号化しKAPx[PxEx]とする。(ここで、KAPx[P
xEx]はPxExの全面的な暗号化ではなくKAPxを利用したメ
ッセージ・ダイジェスト値をPxExに付加したものであっ
ても良い。たとえば、PxExの文頭もしくは文末にKAPxを
連結し、それに対してメッセージ・ダイジェスト関数を
適用する。このようにして求まったメッセージ・ダイジ
ェスト値とPxExをまとめて送付しても良い。) (5)プロセスPxはドメインaの認証者AuthAにKAPx[PxE
x]、を送り、プロセスのE2への移動を申請する。 (6)AuthAは、Pxと共有しているKAPxを使用して、KAPx[P
xEx]からPxExを再生することができる。KAPxはこの転送
サイクルにおいてPxとAuthAしか知り得ない秘密であ
る。従ってPxExが正常に解読できた事を持ってPxがAuth
Aによって認証されたプロセスであることが確認でき
る。 (7)AuthAは、サーバーA内に保管されていたPxの証明書O
に対応する副本Sを生成する。PxExから実行形式Pxを再
生し、O, S, Px間の対応を形成しPxの実行を許可する。
【0077】注意1:上記手順の第3項にて行われる共有
鍵KAPxの生成は、Px、AuthA間にて行われるが、KAPxの
安全性に配慮するならば、AuthAの範囲を一層限定し
て、PxとAuthA内のサーバーAとの間で行われるほうが、
望ましい。ただし、実装上の選択として、効率性、負荷
分散の観点から別の鍵管理機構などをAuthA内に設置し
て、そことPxとの間でKAPxを生成することも考えられ
る。 注意2:上記手順の第7項にて、転送元にある証明書副本
Sの無効処置が必要となる。これをどの時点に実施する
かは本方式の具体的な実装に依存する。逆に、無効処置
を行わない場合、本手順は、プロセスを実行環境へ複写
する手順として利用可能である。この場合、相手先認証
機構は、証明書を生成する際、複写としての証明書正本
を新たに割り付ける必要がある。 注意3:応用上、実行環境E1、E2の相互認証が別途必要
となる場合もある。ただし、これは、移動時のプロセス
に対する認証とは別の手順である。
【0078】<第16実施形態:証明書付きのプロセス
の保存方式>第14実施形態の[証明書を応用したプロ
セス移動方式] を変形することによって、証明書付きの
プロセスを保存する方式が得られる。通信回線等で結ば
れた処理系内では障害等によってデータが失われる場合
がある。従ってデータの破損や喪失への対策としてこの
ようなプロセスの保存方式が要求される。この手順は、
プロセス移動手順と併用する事が可能である。以下は第
12実施形態の手順に基づく保存法式であるが、第14
実施形態の移動方式の変形、第15実施形態の移動方式
の変形に対しても同様にして対応する保存方式が得られ
る。
【0079】この手順の概略は次の通りである。ここ
で、プロセスPxがドメインaからドメインbへ移動する
場合、ドメインbにてプロセスを保存するケースを考え
る。ここでサーバーA、B、Cは証明書管理機構として機
能し、各ドメインの認証機構をそれぞれAuthA、AuthB、
AuthCとする。 (1)PxはAuthAにドメインbへ移動したいという要求を送
る。 (2)サーバーAとPxとの相互認証を行う。この際、ドメイ
ンaの認証者によるAの認証と、すでに述べた「不正検出
アルゴリズム」によるPxの認証が行われる。 (3)サーバーAはサーバーBと協議を行い暗号鍵KABを用意
する。この手順の詳細は第13実施形態の説明を援用す
る。 (4)PxとAuthAは一時的な暗号鍵KAPxを生成する。KAPxの
合意は、たとえば、Diffie-Hellmanの鍵交換法を使用し
て行われる。 (5)サーバーAは証明書正本OをKABで暗号化しKAB[O]を作
る。また、KAPxもKABで暗号化し、KAB[KAPx]を作る。そ
してそれを、Pxに送る。(OとKAPxとを連結してKABで暗
号化し、KAB[O|KAPx]を作っても良い。) (6)プロセスPxは自分自身の外部形式PxExを作り、それ
をKAPxで暗号化しKAPx[PxEx]とする。(ここで、KAPx[P
xEx]はPxExの全面的な暗号化ではなくKAPxを利用したメ
ッセージ・ダイジェスト値をPxExに付加したものであっ
ても良い。たとえば、PxExの文頭もしくは文末にKAPxを
連結し、それに対してメッセージ・ダイジェスト関数を
適用する。このようにして求まったメッセージ・ダイジ
ェスト値とPxExをまとめて送付しても良い。) (7)プロセスPxはドメインbの認証機構AuthBに、KAPx[Px
Ex]、 KAB[KAPx]、 KAB[O]を送り、プロセスの移動を申
請する。 (8)AuthBは(3)で決定したKABを用いて、 KAB[O]から証
明書Oを再生し、KAB[KAPx]からKAPxを再生することがで
きる。そして、KAPxを使用して、KAPx[PxEx]からPxExを
再生することができる。(KAB[KAPx]は、証明書Oとプロ
セスPxとのリンクを表していると解釈してもよいだろ
う。) (9)KAPxはこの転送サイクルにおいてPxとAuthAしか知り
得ない秘密であり、KAB[KAPx]にKAPxがあることは、Aut
hAしか知り得ない。従ってPxExが正常に解読できた事を
持ってPxがAuthAによって認証されたプロセスであるこ
とが確認できる。 (10) AuthBは、この事実を持ってサーバーB内に証明書
正本Oを割り付ける。その際、KAPxとプロセスのバック
アップ名を正本に対応付けてサーバーB内に保存する。
そして、プロセスのバックアップ名とKAPx[PxEx]を対応
付けて不揮発性記憶媒体に書き込む。この際、宛先実行
環境の識別などプロセスの再開に必要となる情報も合わ
せて記録する。これらの情報は、証明書正本Oに保持さ
せる事も可能であるが、これらは、本手順の実装に依存
する。
【0080】注意1:上記手順(4)にて行われる共有鍵KA
Pxの生成は、Px、AuthA間にて行われるが、KAPxの安全
性に配慮するならば、AuthAの範囲を一層限定して、Px
とAuthA内のサーバーAとの間で行われるほうが、望まし
い。ただし、実装上の選択として、効率性、負荷分散の
観点から別の鍵管理機構などをAuthA内に設置して、そ
ことPxとの間でKAPxを生成することも考えられる。ま
た、第8項でAuthBがKABを用いる場合も、KABがサーバー
Bの外部に流出しないような配慮を行うべきである。 注意2:上記(5)から(7)の手順でKAB[O]とKAB[KAPx]をPx
経由にてAuthBに送っているが、その一方もしくは双方
を直接AuthBに送るなどの手順変形は可能である。基本
的にそれらの変形は上記手順と同等のものと見なして良
い。 上記の手順の(1)から(9)までは、7節の証明書を応用し
たプロセスの移動方式と全く同じである。さらに10項以
降も互いに矛盾するものではない。従って、第5実施形
態の方式を使用してプロセスを移動させる際、プロセス
の保存を並行して行う事が可能である。上記の手順によ
って保存されたプロセスを再生させる際に、2通りの場
合が考えられる。一方は、そのプロセスの証明書副本が
すでに存在し、その証明書副本に対応するプロセスを復
旧させる場合である。他方は証明書の副本がまだ割り付
けられていないか、プロセスが副本も含めて失われてし
まった場合である。
【0081】[プロセスの復旧:副本が存在する場合] (1)認証機構は、副本の真正性を確認する。 (2)真正性が確かめられたならば、正本に対応付けられ
たプロセスのバックアップ名と暗号鍵KAPxを取り出す。 (3)バックアップ名に対応したKAPx[PxEx]を読み込む。 (4)KAPx[PxEx]をKAPxで解読し、PxExを取り出し。それ
からPxを割り付ける。
【0082】[プロセスの復旧:副本が存在しない場合]
この場合、そもそもどのプロセスを復旧させるのかを決
定しなくてはならない。そのためには、1)証明書管理機
構内の正本すべてをしらみつぶしに調べ、すべての副本
についてその存在の問い合わせを行う、2)常時適当な周
期で、少しずつ、証明書管理機構内の正本に対応する副
本の問い合わせをしておく、などが必要である。いずれ
かの方法で副本の消滅が確認された場合、証明書管理機
構側が認証者に副本が存在していない証明書正本の情報
を伝える。以後次の手順によって復旧を行う。 (1)認証機構は、正本に対応付けられたプロセスのバッ
クアップ名と暗号鍵KAPxを取り出す。 (2)バックアップ名に対応したKAPx[PxEx]を読み込む。 (3)KAPx[PxEx]をKAPxで解読し、PxExを取り出す。証明
書正本に基づき証明書副本Sと、プロセスPxを割り付け
る。
【0083】本方式は移動可能プロセス移動時のバック
アップと復旧の方式であるが、移動時に認証機構に渡す
要求に適当なオプションや異なる要求を与える事によっ
て、プロセスの保存だけを行って、プロセスの実行を延
期させることも、ほぼ同様な手順で可能である。この場
合、証明書管理機構に割り付ける証明書正本に再開時刻
等を含めた実行延期を示す情報を対応させる等の処置を
行う。
【0084】<第17実施形態:プロセスの違法コピー
への対処方法>第5実施形態、第14実施形態、第15
実施形態に示したプロセス移動方法、および第16実施
形態節にて示したプロセスの保存方法において、認証機
構とプロセスとの間で共有暗号鍵KAPxを定めた直後に、
プロセスの複写を行うと、複写されたプロセスと共に共
有鍵KAPxが奪われてしまう恐れがある。この第17実施
形態では、第5実施形態での記号を流用する。本手順で
は、証明書正本のデータが、正規の証明書副本に渡る事
が保証されている。しかし、何らかの方法で悪者によっ
て、暗号化された正本KAB[O]、暗号化された共有鍵KAB
[KAPx]などの情報を傍受されると、違法にコピーされた
プロセスを通じて、贋のプロセスPyの外部形式PyExを共
有鍵KAPxによって暗号化したKAPx[PyEx]に盗み出したKA
B[O]、KAB[KAPx]などの情報を添付して、相手先の認証
機構に送付する事によって、贋のプロセスが証明書正本
を奪う恐れがある。
【0085】このような違法コピーに対する対処には次
の2通りの方法が考えられる。 方法1) 相手先認証機構で、KAB[O]などの暗号化された
正本、KAB[KAPx]などの暗号化された共有鍵、KAPx[PxE
x]など暗号化されたプロセスの受信時に送信元を「不正
検出アルゴリズム」を使用して認証する。 方法2)正規のプロセスの外部形式に関するメッセージ
・ダイジェスト関数値を自ドメインの認証機構にあらか
じめ教えておき、暗号化された正本に添付してもらう。
これらの、対処方法を手順に組み込む際には、組み込み
に伴う処理上のオーバヘッドと、プロセス・コピーの現
実的な可能性、および、認証機構から送られる、暗号化
された正本や、暗号化された共有鍵の傍受の現実的な可
能性を勘案する必要がある。
【0086】以下では、第5実施形態の手順に上記の方
法2)の手順を加えたものを示す事にする。なお、第5
実施形態の手順の後に記されている注記は本手順でも内
容上対応する項目に適合する。また、第14,15,1
6実施形態の手順でも、ほぼ同様な変更を加える事がで
きる。第5実施形態と同様に、Pxがドメインaからドメ
インbへ移動するケースを考える。ここでサーバーA、
B、Cは証明書管理機構として機能し、各ドメインの認証
機構をそれぞれAuthA、AuthB、AuthCとする。
【0087】手順:上記方法2)を適用した場合。ここで
は、SHA(x)やMD5(x)などのメッセージ・ダイジェスト関
数をHASH(x)とする。 (1) PxはAuthAにドメインbへ移動したいという要求を送
る。Pxはこの時点で、Pxの外部形式PxExとPxExのメッセ
ージ・ダイジェスト関数値HASH(PxEx)を計算しこれをHa
shPxとする。 (2) サーバーAとPxは相互認証を行う。この際、ドメイ
ンaの認証者によるAの認証と、すでに述べた「不正検出
アルゴリズム」によるPxの認証が行われる。 (3) PxはAuthAにHashPxを送る。(Pxは、AuthAの要求の
答えとしてHashPxを返しても良い。) (4) サーバーAはサーバーBと協議を行い暗号鍵KABを用
意する。この手順については、第16実施形態の説明を
援用する。 (5) PxとAuthAは一時的な暗号鍵KAPxを生成する。KAPx
の合意は、たとえば、Diffie-Hellmanの鍵交換法を使用
して行われる。 (6) AuthAは証明書正本OをKABで暗号化しKAB[O]を作
る。また、KAPxもKABで暗号化し、KAB[KAPx]を作る。さ
らにPxから受け取ったHashPxも暗号化してKAB[HashPx]
を作り、それらを、Pxに送る。(OとKAPxとHashPxを連
結してKABで暗号化し、KAB[O|KAPx|HashPx]を作っても
良い。) (7) プロセスPxは自分自身の外部形式PxExをKAPxで暗号
化しKAPx[PxEx]とする。(ここで、KAPx[PxEx]はPxExの
全面的な暗号化ではなくKAPxを利用したメッセージ・ダ
イジェスト値をPxExに付加したものであっても良い。た
とえば、PxExの文頭もしくは文末にKAPxを連結し、それ
に対してメッセージ・ダイジェスト関数を適用する。こ
のようにして求まったメッセージ・ダイジェスト値とPx
Exをまとめて送付しても良い。) (8) プロセスPxはドメインbの認証機構AuthBにKAPx[PxE
x]、 KAB[KAPx]、 KAB[O]、KAB[HashPx]を送り、プロセ
スの移動を申請する。 (9) AuthBは、手順4にて決定したKABを用いて、KAB[O]
から証明書Oを再生し、KAB[KAPx]からKAPxを再生するこ
とができ、さらに、HashPxの再生ができる。そして、KA
Pxを使用して、KAPx[PxEx]からPxExを再生することがで
きる。 (10) AuthBはPxExのメッセージ・ダイジェスト関数値HA
SH(PxEx)を計算し、これが、HashPxと一致する事を確認
する。もしも、一致しない場合には手順をこの時点にて
打ち切る。 (11) KAPxはこの転送サイクルにおいて、原則として、P
xとAuthAしか知り得ない秘密であり、KAB[KAPx]にKAPx
があることは、AuthAしか知り得ない。従ってPxExが正
常に解読できた事を持ってPxがAuthAによって認証され
たプロセスであることが確認できる。 (12) AuthBは、この事実を持ってサーバーB内に証明書O
を割り付け、さらにその副本Sを正本Oに基づいて生成す
る。PxExから実行形式Pxを再生し、O、 S、 Px間の対応
を形成しPxの実行を許可する。 (13) この時点で、O、 S の組を使った認証がドメインb
上でも可能となる。ドメインbからドメインcへの移動の
際には上のAとaをBとbに、BとbをCとcにそれぞれ置換え
てこの手順を実行すれば良い。 解説:この手順では、(3)にてプロセスPxがAuthAにPxの
外部形式PxExのメッセージ・ダイジェスト値を教えてい
る。そしてこの値を証明書正本などと一緒にKABで暗号
化してプロセスの転送先に配送する。この値を持つ贋の
プロセスの外部形式を作成するのは、計算理論上難しい
ので。たとえ、悪者がPxのコピーをとるなどしても、Px
Ex以外のプロセスの外部形式を送る事は難しい。また、
この手順は、PxExの転送中におけるデータの欠落の有無
や、改ざんの有無の確認にもなる。この性質ゆえに、方
法2)の方が応用上安全である。なぜなら、共有鍵KAPxが
プロセスのコピーによって流出することを想定すると、
Pxが送信しようとするPxExの改ざんにも対処する必要が
ある。方法2)は、PxExの改ざんを検出する事が可能であ
る。改ざんが発見された場合、Pxは相手先からのエラー
・コードなどを受け、もう一度手順の先頭からやり直す
事ができる。
【0088】<第18実施形態:証明書による認証方法
の変形>これまでのところでは、プロセス(またはオブ
ジェクト)Pxと証明書管理機構Aとの間に2重の証明書
を用意し、その参照が一意的に定まることを利用してプ
ロセスPxと証明書管理機構Aとの相互認証を与える方
法について記してきた。この方法の変形例として、最初
にプロセスPxと証明書管理機構Aとの間の認証を2重
の証明書によって行い、認証が行われた時点でプロセス
Pxと証明書管理機構Aとの間で共通の秘密を設定し
(例えばDiffie-Hellmanの鍵交換方式などを使用す
る)、以後の認証をその共通の秘密によって行うことも
考えられる。
【0089】この方法は、プロセスPxを共通の秘密と
ともに複写して生成されたプロセスPyを容易に作る事
ができ、プロセスPxと異なるプロセスPyがその秘密を
保持することが可能なため、認証効果は低い。しかし、
プロセスPxと証明書管理機構Aとで適当な周期で共通
の秘密を更新する事によってある程度、複写の問題に対
抗する事も可能である。この方式の良さは、プロセスP
xと証明書管理機構Aとの間の認証に従来から行われて
いる秘密情報に基づく認証方法が適用可能な点である。
また、さらなる変形例として、証明書正本と証明書副本
との間に共通の秘密を設定し、証明書正副間の不正検出
を、この秘密を知っているかどうかによって行う方法も
考えられる。この共通の秘密の設定に際して、Diffie-H
ellman法を使用する場合、証明書間の相互認証が必要な
ので、最低一回は、参照を利用した、前述の不正検出ア
ルゴリズムを使用して、相手の確認を行うことが必要で
ある。
【0090】この場合、図13に示すように、証明書内
に共通の秘密を置かずに、証明書を管理するオブジェク
トもしくはデータ構造内に、配列やハッシュ・テーブル
を置き、その配列またはハッシュテーブルにて証明書と
秘密との対応付けを行い、配列やハッシュ・テーブルに
対する外部からのアクセスに制限を設ける事で秘密の安
全性を、ある程度、確保することが可能である。この方
法では、そのように管理される秘密に対して、証明書か
らどのようにアクセスを許すのかが、問題となる。オブ
ジェクト指向言語の中には、変数の参照制限機能や、一
度定義されたメソッドの上書きの禁止を行う機能が提供
されているものがある。そのような、プログラミング言
語を使用すると、秘密を管理する配列やハッシュ・テー
ブルに対する外部からの参照を制限し、秘密へのアクセ
ス・メソッドを上書き禁止にすることで安全なアクセス
が可能になる。また、上記の2つの方法を折衷し、プロ
セスと認証サーバーとの間に設定される共通の秘密を、
プロセス自体に保持させずに、証明書管理オブジェクト
内のハッシュ・テーブル等に証明書と対応させて保持さ
せることも考えられる。そこで、このような共通の秘密
の生成例をDiffie-Hellman鍵交換方式によって行う場合
を以下に説明する。
【0091】ここでpを素数、gをある整定数。modを
法演算とする。このpとgとは事前に合意してあっても
よいし、一方から他方へ通知してもよい。このとき関数
P(x)をP(x)=gx mod p によって定める。すると、次の
ような手順で行うと、共通鍵をプロセスも含め、外部に
一切漏らさずに生成することができる。ここで、プロセ
スをPx、認証サーバーを証明書管理機構Aとする。ま
た、証明書管理オブジェクトをCOとする。COはプロセス
Pxと証明書管理機構Aとのプロキシーとして機能し、
上記の定数g、pを知っていると仮定する。以下では記述
を簡単にするために、プロセスと証明書との対応チェッ
クを省略しているが、実装時にはそのようなチェックを
行うべきである。
【0092】(1)プロセスPxから証明書管理機構Aへ
共通鍵生成要求をCO経由で発する。このとき秘密の数Rx
を生成し、その要求のパラメータとして付加する。 (2)制御を受け取ったCOはRxの値をプロセスPxに対応
する証明書副本の秘密の値として管理し、証明書管理機
構Aに対するパラメータをRxからP(Rx)に置換えて、メ
ソッド呼出しを証明書管理機構Aに中継する。 (3)証明書管理機構Aは、秘密の数Raを生成する。そし
てP(Ra)を計算し、CO経由のプロセスPxの戻り値とし
てP(Ra)を戻す。このとき、P(Rx・Ra)=gRx・Ra mod p = P
(Rx)Ra mod p = P(Ra)Rx mod p が共通の秘密となる。 (4)証明書管理機構Aからの戻り値P(Ra)を受け取ったCO
は、その値と、管理しているRxを利用して、P(Rx・Ra)=
P(Ra)Rx mod pを計算し、P(Rx・Ra)をプロセスPxに対
応する証明書副本の秘密の値として管理する。プロセス
Pxには単に、共通秘密生成の成功通知だけを戻す。
【0093】この方法を変数やメソッドのアクセス制限
機能のあるオブジェクト指向言語などで実装すれば、プ
ロセスの違法コピー等による秘密の漏洩を防止する効果
があり、さらに、プロセス転送手順にて必要とされる共
通秘密鍵の一時的な保存方式としても効果的である。た
だし、このような工夫で保証されている安全性は、証明
書COを経由してアクセスされているという事実のみであ
ることに注意するべきである。贋のプロセスがCOの参照
を利用して、隠された秘密を利用する恐れは、依然残っ
ている。また、これは実装上の工夫というべきである
が、証明書管理オブジェクトの安全が保障されている場
合、図13の秘密情報の位置に、証明書副本に対して
は、証明書正本への参照を置き、正本に対しては、副本
への参照を置くようにし、証明書自体には互いの参照を
置かないようにすることも考えられる。このように、参
照の管理を証明書自体と分離する事により、証明書が違
法にコピーされた場合を考慮して行われる、証明書間の
煩雑な参照確認手順を簡略化することが可能となる。こ
のような管理方式を使用すると、証明書を違法にコピー
しても、対応するもう片方の証明書への参照が得られな
いので、証明書を利用した認証手順の早期の段階で不正
を見破る事ができる。ただし、この方法も、証明書管理
オブジェクトが安全であることが、前提である。
【0094】逆に、証明書間の参照や秘密情報と証明書
自体を分離するこれらの方法は、証明書管理オブジェク
トが充分安全で、しかも定期的なバックアップや信頼で
きるホスト内にレプリカを保持するなどのシステム・ク
ラッシュ時の情報復旧対策が取られている場合、本証明
書方式を利用したシステムのフォールト・トーレラント
性を高める手段ともなり得る。
【0095】<証明書方式の応用>このような証明書の
最も直接的な応用は、CORBA分散オブジェクト・システ
ムの部分系であるCORBAセキュリティ・サービスでサポ
ートされているクレデンシャル(Credential:信任状)
として使用するか、もしくはその補助データとして使用
する事である。CORBAセキュリティ・サービスにおける
クレデンシャルは、認証されたオブジェクトに対応付け
られオブジェクトの発するリモート・メソッド呼出し時
の呼出し元プリンシパルの照会に使用されたり、オブジ
ェクトに対して設定されるセキュリティ属性の保持、な
らびにそのセキュリティ属性に従って他のオブジェクト
に対するアクセス許可の決定などに使用される。
【0096】しかし、CORBAセキュリティ・サービスで
は、オブジェクトのカレント・スレッドに対しては、ク
レデンシャルのコピーの作成や現在参照すべきクレデン
シャルとして別のクレデンシャルの設定が可能であるな
ど、相当自由なオペレーションが許されている。そのこ
とが、かえってクレデンシャル自体の認証能力を結果的
には弱めてしまい、厳密な認証を必要とする場合、オブ
ジェクトを生成したドメインの認証サーバーなどへ照会
を行わなければならない。このことが、現行のCORBAセ
キュリティ・サービスでの枠組みにおける、移動エージ
ェントなどの、セキュリティ・ドメインを超えて移動可
能なオブジェクトや移動可能なプロセスの実現に困難を
もたらしている。
【0097】例えば、次のような記述が成されている。
「エージェントの認証はエージェント・システムの認証
とは異なる。エージェントは移動の際、(プライベート
・キーなどの)暗号化キーを持ち運ぶことはできない。
エージェントの認証は(秘密キーなどを持つ代わりに)
認証者を立てることによって行う。認証者とはエージェ
ントの真正性を見極めるアルゴリズムである。発進元の
エージェントシステムやエージェントを発進させたクラ
イアントの真正性に関する情報、エージェントやエージ
ェント・システムのオーソリティ、さらに恐らくエージ
ェントを認証する主体として信頼できるオーソリティに
付与された情報などを認証者は使用することが出来る。
エージェント・システムと同様に認証者もタイプを持つ
必要がある。さらに、認証者は名前つけを担当するオー
ソリティによって登録されるべきである。認証者を一段
階、と多段階との2つのタイプに分類することが出来
る。現時点では、一段階の認証者に関する動作と要件の
仕様の作成は可能である。しかし、現時点のセキュリテ
ィ技術に限界があるために、多段階の認証者の仕様は先
送りせざるをえない。
【0098】一段階の認証者はエージェントが出発点か
ら一段階離れたところへ移動する際のエージェントの認
証ができる。例えば、オーソリティAに属するエージェ
ントがオーソリティAのエージェント・システム上で実
行している際、そのエージェントがオーソリティBのエ
ージェント・システムへ移動する場合を考える。エージ
ェント・システムBがエージェント・システムAの認証に
成功した場合、エージェントはエージェント・システム
Aの真正性をエージェント・システムB上で保有する。
エージェント・システムBがエージェント・システムA
を認証できない場合、そのエージェントは認証されたと
はみなされない。エージェントが移動元のエージェント
・システムとは異なるオーソリティを持つ場合、このエ
ージェント転送は多段の操作と考えられる。多段階の認
証については、本仕様の対象とはしない。」(「GMD FO
KUS、International Business Machines Corporation、
Supported by: Crystaliz, Inc.、 General Magic, In
c.、The Open Group "Joint Submission : Mobile Agen
t System Interoperability Facilities Specificatio
n" 、November 10, 1997 OMG TC Document orbos/97-10
-05」より)
【0099】パスポートや運転免許証のように発行時に
厳密な認証を受ければ、以後その証書を提示する事によ
って一定水準の認証が可能であるような証明書が存在す
ると、上記の多段階の認証に関する問題は解決可能とな
る。しかし、コンピュータ上やネットワーク上でのデー
タ化された証書はコピーや改ざんが容易なため、原本の
コピーや改変と原本自体とを確実に識別できる証書シス
テムが必要である。しかも、そのような証書はエージェ
ントの移動に伴って移動可能でなければならない。この
とき、先に述べてきた2重の証明書機構は、原本とその
コピーや改変との識別が可能でしかも移動も可能なクレ
デンシャルとしての要求を満足するものである。今まで
の説明において、改ざん不正コピー等、悪意に基づく違
法アクセスに対抗する例を多く考えてきたが、クレデン
シャルとして応用する場合、コピーや属性の変更はシス
テム的にも認められた操作である。この場合においても
コピーや異形に対して原本を識別する操作として上述の
コピーや改ざんに対抗する操作を使用する事ができる。
【0100】この技術は、移動エージェントの認証機構
として開発されたものだが、プロセスとしては、エージ
ェントだけでなく、署名付きの変造不能なデータを与え
ることも可能である。このようなプロセスは、有価証券
や、金券など、ネットワーク上においてその存在の唯一
性の保証が要求されるものに対する代替物として利用可
能である。従来方式の署名付きデータだけでは、容易に
データのコピーが可能であったため、有価証券などの実
現はネットワーク上では困難であった。本技術の証明書
をそのデータに付加させることで違法コピーや偽装が困
難になることは、すでに説明した通りである。
【0101】<第19実施形態:証明書正副間に悪者が
介在する場合の排除方法>本発明の認証方式は証明書の
正本と副本との間の参照やメソッド呼出しに矛盾が無い
事を前提にしている。これは、証明書相互間に共通の秘
密を仮定せず、証明書の真正性を確認する方式を与える
ためには、必要な事である。本方式は、移動可能プロセ
スの認証に応用する事が主要な目的であるため、このよ
うに共通の秘密を前提にしないことが要求されている。
しかし、図14のように、証明書正本と証明書副本との
間に、悪者が介在し、両者間のメソッド呼出しを横取り
することによって、正本に対して副本を偽装し、副本に
対して正本を偽装する方式の攻撃の恐れがある。いわゆ
る、バケツリレー式の攻撃である。
【0102】このような攻撃に対する対策は、証明書機
構より下位に位置する通信機構にて行う必要がある。こ
れには、次のような選択がある。ここで証明書管理機構
が稼動しているホストをH1、ユーザー側のプロセスが稼
動しているホストをH2とする。 (1)ホストH1とホストH2との通信システムに特に保護
機能は置かないが、他の介在者が入り込まないよう運用
面での管理を行う。 (2)ホストH1とホストH2との通信システムの物理層あ
るいは、データ・リンク層に暗号化機構などの保護機能
を組み込む。 (3)ホストH1とホストH2との通信システムとアプリケ
ーションとの制御を行うオペレーティング・システムな
どに暗号化機能などの保護機能を組み込む。 (4)ホストH1とホストH2上で動作している、ORB(Obje
ct Request Broker)などのRMIやRPCを実現するミドル
ウェアに暗号化機能などの保護機能を組み込む。 (5)移動可能プロセスを実行させる実行環境と、証明書
管理機構を実装するサーバー・プログラム等との間の通
信に、暗号化機能などを組み込んだ安全な汎用メソッド
呼出し機能を実現する。これは、両者は移動しないプロ
セスなので、プロセス立ち上げ時などに共通の秘密をパ
ラメータやコンフィギュレーション・ファイルなどの形
で与える事ができるので可能である。個々の証明書間の
メソッド呼出しは、証明書の参照や、コマンド・コー
ド、その他のデータを引数として汎用メソッドに渡す事
で行う。 (6)Proxy(代理プロセス)をホストH2上、またはホス
トH1とホストH2双方の上に置き、Proxy経由でメソッ
ド呼出しを行う。Proxyは暗号化等の保護機能を実現す
る。認証者をこの目的のために使用する事も考えられ
る。証明書副とProxyは同一ホスト上なので、その間の
通信は充分安全であると考える。
【0103】<第20実施形態:証明書付き移動可能プ
ロセスのデジタル通貨への応用>銀行など許可された金
融機関に証明書管理機構を設置し、そこを中心とした、
セキュリティ・ドメインを構築する。様々な、金融機関
の本支店間に独立したセキュリティ・ドメインが存在す
ると仮定する。各セキュリティ・ドメインには、そのド
メインを管理する金融機関と契約した顧客のホストが接
続されていると仮定する。セキュリティ・ドメイン相互
間は、通信回線で結合されデータやプロセスの移動が可
能であると仮定する。
【0104】このとき、それらのセキュリティ・ドメイ
ン全体で流通する無記名のデジタル通貨を次のように実
現することが可能である。 (1)デジタル通貨は、金融機関によって発行された証明
書付きの移動可能プロセスである。 (2)証明書には、発行金融機関名と、発行日付、一意の
識別番号、金額が明示されている。そして、証明書の内
容が真正であることを示す、金融機関の署名が付加され
ている。 (3)プロセスには2つのメソッドが定義されていて、その
一つは支払であり、他の一つは受け取りである。 (4)プロセスは、通貨の所有者を示す特殊な実行環境で
動作する。この実行環境は、顧客のホスト内で動作し、
ちょうど財布や金庫の役割を果たす。 (5)支払メソッドによってデジタル通貨は、現在実行中
の環境から、指定された環境へ移動する。これは、金銭
の支払に相当する。 (6)このメソッドの実行途中に、現実行環境から、所有
者本人もしくは、本人の代理のプロセスに対して承認を
求める通知がなされる。承認を受け取るまで、プロセス
移動処理は一時中断する。 (7)この承認をうけて、プロセスの移動処理が再開され
る。 (8)この移動時に、既に述べられた証明書付きのプロセ
スの移動手順が実施され、通貨の認証と一意性の保証が
なされる。 (9)プロセスの移動が完了し、再起動されるときに受け
取りメソッドが実行される。このとき、受領通知が、送
り元実行環境に伝えられる。これは、領収書に相当す
る。 (10)通貨を金融機関等に預金する目的で、第17節で記し
た、証明書付きプロセスの保存法式を応用することも可
能である。
【0105】<第21実施形態:記名式通貨(手形:小
切手)の実現>記名式デジタル通貨は、振り出し人本人
によって発行された証明書付きの移動可能プロセスであ
る。証明書には、本人の氏名、取引先金融機関名と、発
行日付、支払期日、一意の識別番号、金額が明示されて
いる。そして、証明書の内容が真正であることを示す、
本人の署名が付加されている。プロセスには、支払、受
け取り、裏書き、取りたて、不渡りという5つのメソッ
ドが定義されている。プロセスは、通貨の所有者を示す
特殊な実行環境で動作する。この実行環境は、顧客のホ
スト内で動作し、ちょうど財布や金庫の役割を果たす。
支払メソッド、もしくは裏書きメソッドによって記名式
デジタル通貨は、現在実行中の環境から、指定された環
境へ移動する。これは、手形の振り出し、もしくは裏書
きに相当する。 (1)このメソッドの実行途中に、現実行環境から、所有
者本人もしくは、本人の代理のプロセスに対して承認を
求める通知がなされる。承認を受け取るまで、プロセス
移動処理は一時中断する。 (2)この承認をうけて、プロセスの移動処理が再開され
る。 (3)この移動時に、第5,14,15,16及びその他
の実施形態において既に述べられた証明書付きのプロセ
スの移動手順が実施され、通貨の認証と一意性の保証が
なされる。さらに、裏書きの場合、裏書人の氏名、実行
環境名、および署名が、一旦、証明書管理機構に送ら
れ、証明書正本に、氏名と実行環境名、および署名が付
加される。 (4)プロセスの移動が完了し、再起動されるときに受け
取りメソッドが実行される。このとき、受領通知が、送
り元実行環境に伝えられる。これは、領収書に相当す
る。 (5)取り立ての際、受取人は、取り立てメソッドの実行
を要求する。このメソッドは支払期日後に限って有効で
ある。 (6)記名付きデジタル通貨は、証明書に明示されている
取り引き金融機関に移動し、等価の無記名デジタル通貨
との交換を要求する。 (7)金融機関は振り出し人の口座の残高を確認し、残高
が充分な場合には、指定された金額を口座から引き落と
し、その金額のデジタル通貨を受取人に支払う。 (8)口座の残高が不足している場合、不渡りメソッドが
実行される。 (9)不渡りメソッドは、証明書正本に付加されている、
裏書人の実行環境リストを逆の順序で移動しながら、当
該手形が不渡りになったことを、各裏書き人に通知しな
がら、振出し人の実行環境に戻る。 (10)通貨を金融機関等に預金する目的で、第16実施形
態で記した[証明書付きプロセスの保存法式]を応用する
ことも可能である。
【0106】(フ゜ロセスの移動と生成処理の実施例) <手順1.証明書管理機構同士の認証に使用する共有鍵
の登録>手動で行う。
【0107】<手順2.証明書管理機構の起動>手動で行
う。
【0108】<手順3.認証者の起動>マスター認証者の
起動は、手動または、各ホスト・コンピュータの定義フ
ァイルなどにて定められた手順にて起動する。その他の
認証者は、マスター認証者によって起動される。認証者
の種類は、ユーザー認証者、実行環境認証者(前記実施
形態では、証明書機構をサポートするJava仮想マシンを
立ち上げる認証者)、オブジェクト生成認証者、オブジ
ェクト再生成認証者、移動プロセス認証者、マスター認
証者(証明書管理機構の所在を管理する)である。認証
者との対話方式は実装によって異なる。
【0109】<手順4. 実行環境の起動>前提として
は、証明書管理機構と実行環境との間には、信頼を確立
する方法が存在する。たとえば、あらかじめ暗号鍵が共
有されている。 (1)もしも、ユーザーの認証が行われていない場合に
は、ユーザー認証者はユーザーの認証を行う。 (2)ユーザーとの安全な通信セッションを確立する。 (3)ユーザーが実行環境の起動を要求する。 (4)実行環境認証者がユーザーの権限の問い合わせを行
う。 (5)指定された実行環境の起動が行われる。
【0110】<手順5.実行環境と証明書管理機構との
安全な通信の確立> (1)証明書管理機構と実行環境との相互認証が行われ
る。 (2)相互に安全な通信を行うための通信セッション鍵を
生成する。 (3)以後の通信をそのセッション鍵でもって暗号化す
る。 (4)実行環境を管理する証明書を生成する。この情報は
実行環境認証者によって与えられる。
【0111】<手順6.オブジェクトもしくはプロセス
の生成> (1)もしも、ユーザーの認証が行われていない場合に
は、ユーザー認証者はユーザーの認証を行う。 (2)ユーザーとの安全な通信セッションを確立する。 (3)もしも、実行環境の起動が必要な場合は、手順5に
したがって実行環境の起動を行う。 (4)手順7にしたがって、クラスやプログラムの権限の
確認を行う。 (5)オブジェクト生成認証者によってオブジェクトの生
成要求を行う。 (6)手順8に従ってオブジェクトの生成が行われる。 (7)必要ならば、生成されたオブジェクトの妥当性をユ
ーザーに確認させる。 (8)オブジェクト生成認証者はオブジェクトの参照と空
の証明書副本の参照を証明書管理機構に渡す。
【0112】<手順7.オブジェクトを定めるクラスや
プログラム等の権限の確認>要求したユーザーの権限に
対して、使用されるクラスやプログラムの許可レベルが
適切かどうかを確認する。
【0113】<手順8.環境内でのオブジェクトの生成> (1)指定されたクラスに基づくオブジェクトのインスタ
ンスを生成する。 (2)空の証明書副本を生成する。 (3)証明書副本とオブジェクトとの対応付けを行う。 (4)オブジェクト生成認証者にオブジェクトと証明書副
本の参照を渡す。
【0114】<手順9.証明書正本生成> (1)オブジェクト生成認証者より渡されたオブジェクト
の参照と空の証明書副本ならびに、ユーザー情報、さら
に認証情報データ・ベースなどによる情報に従って、証
明書正本を作成する。 (2)正本に副本の参照を設定する。 (3)正本にオブジェクトへの参照を設定する。 (4)副本に対して初期設定要求をだす。
【0115】<手順10. 証明書副本の初期設定手順> (1)マスター認証者に対して証明書管理機構の参照を要
求する。 (2)証明書管理機構に対して、証明書副本の参照を渡し
て、対応する正本の参照を要求する。 (3)もしも、正本の参照が得られない場合は、エラーと
する。 (4)副本に正本の参照を設定する。 (5)正本に対して証明書データ読み出し要求を出す。 (6)正本から送られてきたデータを副本に設定する。
【0116】<手順11. 移動可能プロセスの移動処理手
順> (1)プロセスは、副本の参照、副本に保持されている正
本の参照を一時領域に待避させる。(第9節の注意2に配
慮し、認証処理中の改ざんに対処するため。) (2)プロセスは、自環境の移動プロセス認証者に対し
て、移動要求を発行する。その際、宛先情報、自プロセ
スの参照、待避させた副本の参照、正本の参照を提示す
る。 (3)移動プロセス認証者は、その要求を受けて、マスタ
ー認証者を呼出し。プロセスと証明書管理機構との、移
動のための相互認証を行う。 (4)もしも、認証に失敗した場合、プロセスは副本の修
復を行い手順11の最初から行う。 (5)成功時には、エージェント認証者から返される素数
p、整定数gを保存する。 (6)適当な数Xを決定し、P(X)= gXmod pを計算し、その
値とともに証明書正本に対して、共有鍵生成要求を出
す。 (7)証明書管理機構側(証明書正本側)からの共有鍵生
成要求を待つ。 (8)証明書管理機構からP(Y)= gYmod pと共に、共有鍵生
成要求ならびに、チャレンジKXY[R]が送られてきたら、 (9)まず、KXY = P(X・Y) = gX・Y mod p = P(Y)X mod p
を計算する。 (10)そして、KXYにてKXY[R]を解読し、整数Rを取り出
す。 (11)最後に、応答としてR+1を戻す。 (12)適当な整数R2を生成しKXY[R2]をチャレンジとして
証明書正本に送る。 (13)その応答としてR2+1が戻されてきた場合、共有鍵の
生成は成功である。また、その応答には、暗号化され
た、証明書正本と暗号化された共有鍵が添付されてい
る。 (14)手順16を行う。 (15)手順17を行う。
【0117】<手順12. マスター認証者による移動可能
プロセスと証明書管理機構との、移動のための相互認証
手順> (1)不正検出アルゴリズムの手順2に従って、プロセスの
認証を行う。このとき、証明書管理機構は、認証成功時
にプロセス間で鍵を決定するために必要な、素数p、整
定数gを返すものとする。 (2)認証結果をもどす。その際、成功時には、素数p、整
定数gも戻す。
【0118】<手順13.証明書管理機構間の共有鍵生成
手順> (1)宛先情報を名前付け管理機構などに渡し、相手先の
認証機構の参照を得る。 (2)第16節の手順のいずれかに従って、共有鍵を生成す
る。ここで生成された鍵をKABとする。また、ここで
は、転送セッションIDも生成されることとする。
【0119】<手順14.プロセスと証明書管理機構との
共有鍵生成手順(正本側の手順)> (1)適当な整数Yを生成し、P(Y)= gY mod pを計算する。 (2)プロセス側から、P(X)= gX mod p、が送られてきた
ら、肯定応答を返す。 (3)KXY = P(X・Y) = gX・Y mod p = P(X)Y mod pを計算
する。 (4)適当な整数Rを生成し、KXYにてRを暗号化し、KXY[R]
を作りプロセスへのチャレンジとする。 (5)プロセスに対して、P(Y)、KXY[R]と渡し共有鍵生成
要求を行う。 (6)その戻りとしてR+1が返ってくれば片道側は成功であ
る。 (7)プロセスからのチャレンジを待つ。 (8)プロセスからチャレンジとして、KXY[R2]が与えられ
てきたら、片道側が成功している場合は、KXYにて解読
し、R2+1をチャレンジの応答として返す、このとき、手
順15によってつくられたKABで暗号化された証明書正本
とKABで暗号化された共有鍵KAB[KXY]、そしてセッショ
ンIDを添付する。 (9)片道側が失敗している場合は、定数FALSEを返す。
【0120】<手順15.正本側の証明書とプロセスとの
共有鍵との暗号化手順> (1)証明書正本、プロセスとの共有鍵KXY、タイムスタン
プを文字列として結合する。 (2)この文字列をKABにて暗号化する。
【0121】<手順16.プロセスの外部形式生成と暗号
化手順> (1)定められたシリアライゼーションの手順に従ってプ
ロセスの外部形式をバイト列として生成する。 (2)生成されたバイト列をKXYにて暗号化する。
【0122】<手順17.プロセスの他セキュリティドメイ
ンの移動プロセス認証者に対する移動申請手順> (1)プロセスが管理している宛先情報を、名前付け管理
機構などに渡し、移動先の移動プロセス認証者の参照を
入手する。 (2)手順16にて得られた暗号化されたプロセスの外部形
式、証明書管理機構から送られた暗号化された正本、プ
ロセスと証明書管理機構との共有鍵、セッションID、プ
ロセスの参照、証明書正本、副本の参照を引数として、
移動プロセス認証者に移動要求を発行する。
【0123】<手順18.移動プロセス認証者によるプロ
セスと証明書との複号化手順> (1)プロセスの暗号化されたプロセスの参照、セッショ
ンIDと、証明書正本の参照、暗号化された正本、プロセ
スとの共有鍵を証明書管理機構に渡し、手順20によって
証明書とプロセスの再生成を行う。 (2)正常に再生成が行われない場合要求プロセス側にエ
ラーを戻す。
【0124】<手順19のa.移動プロセスの再生成手順> (1)与えられたプロセスの外部形式から所定のデシリア
ライゼーション手順を使用して内部形式を生成する。 (2)内部形式の生成に失敗した場合はエラーとする。 (3)手順7にしたがって、クラスやプログラムの権限の
確認を行う。 (4)空の証明書副本を生成する。 (5)証明書副本とオブジェクトとの対応付けを行う。 (6)移動プロセスト生成認証者はオブジェクトの参照と
空の証明書副本の参照を証明書管理機構に渡す。
【0125】<手順19のb.プロセスの外部形式解読を
経たプロセス生成> (1)KXYによってプロセスの暗号を解読しプロセスの外部
形式を作る。 (2)もしも、実行環境の起動が必要な場合は、手順5に
したがって実行環境の起動を行う。 (3)手順19のaによってプロセスの生成を行う。 (4)生成されたプロセスの参照と空の副本の参照を戻
す。
【0126】<手順20.証明書とプロセスの再生成> (1)セッションIDより共有鍵KABを取り出す。 (2)共有鍵KABを使用して暗号化された証明書ならびにプ
ロセスとの共有鍵、タイムスタンプの暗号を解除する。 (3)送信側の証明書正本の参照と暗号解除された証明書
との照合を行う。 (4)照合で致命的な不一致が発見された場合、またはタ
イムスタンプが閾値の範囲に入らない場合は、エラーと
して処理を打ち切る。 (5)オブジェクト再生成認証者にプロセスとの共有鍵KX
Y、暗号化されたプロセスの外部形式を渡し、手順19のb
にてプロセスの再生成を行わせる。このとき、正常に再
生成された場合、空の証明書副本とプロセスの参照が渡
される。 (6)正常な再生成が行われなければ、エラーとして処理
を打ち切る。 (7)オブジェクト再生成認証者よりもどされたオブジェ
クトの参照と空の証明書副本ならびに、解読された正本
情報、さらに認証情報データ・ベースなどによる情報に
従って、証明書正本を作成する。 (8)正本に副本の参照を設定する。 (9)正本にオブジェクトへの参照を設定する。 (10) 副本に対して初期設定要求をだす。 (11)送信側の証明書正本に対して手順21の無効化処理を
行う。
【0127】<手順21.送信側の証明書の無効化手順
(正副の無効化)> (1)要求側が、証明書管理機構であることを確認する。 (2)証明書正本に無効フラグを設定する。 (3)正本で管理しているプロセスの参照に対して手順22
の無効要求を発する。 (4)正本を管理テーブルなどから削除する。
【0128】<手順22.送信側のプロセスの無効化手順> (1)マスター認証者に対して証明書管理機構の参照を要
求する。 (2)証明書管理機構に対して、証明書副本の参照を渡し
て、対応する正本の参照を要求する。 (3)もしも、正本の参照が得られない場合は、プロセス
の終了処理を行う。 (4)正本の無効フラグをチェックする。 (5)無効フラグがtrueの場合には、プロセスの終了処理
を行う。
【0129】
【プロセス・コピーに対抗した場合の手順の変形】<手
順23.移動可能プロセスから認証機構への移動手順(ハ
ッシュ値の生成を含む)> (1)プロセスは、副本の参照、副本に保持されている正
本の参照を一時領域に待避させる。(第9節の注意2に配
慮し、認証処理中の改ざんに対処するため。) (2)プロセスは定められたシリアライゼーションの手順
に従ってプロセスの外部形式をバイト列として生成す
る。 (3)生成されたバイト列に対してハッシュ関数を適用し
てハッシュ値HashPを計算する。 (4)プロセスは、自環境の移動プロセス認証者に対し
て、移動要求を発行する。その際、宛先情報、自プロセ
スの参照、待避させた副本の参照、正本の参照を提示す
る。 (5)移動プロセス認証者は、その要求を受けて、マスタ
ー認証者を呼出し。プロセスと証明書管理機構との、移
動のための相互認証(手順24)を行う。 (6)もしも、認証に失敗した場合、プロセスは副本の修
復を行い手順23の最初から行う。 (7)成功時には、移動プロセス認証者から返される素数
p、整定数gを保存する。 (8)適当な数Xを決定し、P(X)= gX mod pを計算し、その
値とともに証明書正本に対して、共有鍵生成要求を出
す。 (9)証明書管理機構側(証明書正本側)からの共有鍵生
成要求を待つ。 (10) 証明書管理機構からP(Y)= gY mod pと共に、共有
鍵生成要求ならびに、チャレンジKXY[R]が送られてきた
ら、 (11) まず、KXY = P(X・Y) = gX・Y mod p = P(Y)X mod
pを計算する。 (12) そして、KXYにてKXY[R]を解読し、整数Rを取り出
す。 (13) 最後に、応答としてR+1を戻す。 (14) 適当な整数R2を生成しKXY[R2]をチャレンジとして
証明書正本に送る。 (15) その応答としてR2+1が戻されてきた場合、共有鍵
の生成は成功である。また、その応答には、暗号化され
た、証明書正本と暗号化された共有鍵が添付されてい
る。 (16) 手順28を行う。 (17) 手順29を行う。
【0130】<手順24. マスター認証者による移動可能
プロセスと証明書管理機構との相互認証手順> (1)不正検出アルゴリズムの手順2に従って、プロセスの
認証を行う。このとき、証明書管理機構は、認証成功時
にプロセス間で鍵を決定するために必要な、素数p、整
定数gを返すものとする。またこの処理の終了段階で、
認証成功時、手順25によって、証明書正本経由でプロセ
スからハッシュ値の転送を行う。 (2)認証結果をもどす。その際、成功時には、素数p、整
定数gも戻す。
【0131】<手順25.ハッシュ値送付手順> (1)証明書正本は自分が保持しているプロセスの参照に
対してハッシュ値の要求を行う。 (2)プロセスからの戻りとしてハッシュ値が与えられ
る。
【0132】<手順26.証明書管理機構間の共有鍵生成
手順> (1)宛先情報を名前付け管理機構などに渡し、相手先の
認証機構の参照を得る。 (2)第16節の手順のいずれかに従って、共有鍵を生成す
る。ここで生成された鍵をKABとする。また、ここで
は、転送セッションIDも生成されることとする。
【0133】<手順27.プロセスと証明書管理機構との
共有鍵生成手順(正本側)> (1)適当な整数Yを生成し、P(Y)= gY mod pを計算する。 (2)プロセス側から、P(X)= gX mod p、が送られてきた
ら、肯定応答を返す。 (3)KXY = P(X・Y) = gX・Y mod p = P(X)Y mod pを計算
する。 (4)適当な整数Rを生成し、KXYにてRを暗号化し、KXY[R]
を作りプロセスへのチャレンジとする。 (5)プロセスに対して、P(Y)、KXY[R]と渡し共有鍵生成
要求を行う。 (6)その戻りとしてR+1が返ってくれば片道側は成功であ
る。 (7)プロセスからのチャレンジを待つ。 (8)プロセスからチャレンジとして、KXY[R2]が与えられ
てきたら、片道側が成功している場合は、KXYにて解読
し、R2+1をチャレンジの応答として返す、このとき、手
順26によってつくられたKABで暗号化された証明書正本
とKABで暗号化された共有鍵KAB[KXY]、さらに暗号化さ
れたハッシュ値KAB[HashP]、そしてセッションIDを添付
する。 (9)片道側が失敗している場合は、定数FALSEを返す。
【0134】<手順28.プロセスの外部形式の暗号化手
順> (1)定められたシリアライゼーションの手順に従ってプ
ロセスの外部形式をバイト列として生成する。 (2)生成されたバイト列をKXYにて暗号化する。
【0135】<手順29.プロセスの他セキュリティドメイ
ンの移動プロセス認証者に対する移動申請手順> (1)プロセスが管理している宛先情報を、名前付け管理
機構などに渡し、移動先の移動プロセス認証者の参照を
入手する。 (2)手順28にて得られた暗号化されたプロセスの外部形
式、証明書管理機構から送られた暗号化された正本、プ
ロセスと証明書管理機構との共有鍵、ハッシュ値、セッ
ションID、プロセスの参照、証明書正本、副本の参照を
引数として、移動プロセス認証者に移動要求を発行す
る。
【0136】<手順30.移動プロセス認証者によるプロ
セスと証明書との複号化手順> (1)プロセスの暗号化されたプロセスの参照、セッショ
ンIDと、証明書正本の参照、暗号化された正本、プロセ
スとの共有鍵、ハッシュ値を証明書管理機構に渡し、手
順32によって証明書とプロセスの再生成を行う。 (2)正常に再生成が行われない場合要求プロセス側にエ
ラーを戻す。
【0137】<手順31.環境内での移動プロセスの再生
成手順> (1)与えられたプロセスの外部形式から所定のデシリア
ライゼーション手順を使用して内部形式を生成する。 (2)内部形式の生成に失敗した場合はエラーとする。 (3)手順7にしたがって、クラスやプログラムの権限の
確認を行う。 (4)空の証明書副本を生成する。 (5)証明書副本とオブジェクトとの対応付けを行う。 (6)移動プロセスト生成認証者はオブジェクトの参照と
空の証明書副本の参照を証明書管理機構に渡す。
【0138】<手順32.証明書とプロセスの再生成> (1)セッションIDより共有鍵KABを取り出す。 (2)共有鍵KABを使用して暗号化された証明書ならびにプ
ロセスとの共有鍵、タイムスタンプ、ハッシュ値の暗号
を解除する。 (3)送信側の証明書正本の参照と暗号解除された証明書
との照合を行う。 (4)照合で致命的な不一致が発見された場合、またはタ
イムスタンプが閾値の範囲に入らない場合は、エラーと
して処理を打ち切る。 (5)オブジェクト再生成認証者にプロセスとの共有鍵KX
Y、暗号化されたプロセスの外部形式、ハッシュ値HashP
を渡し、手順33にてプロセスの再生成を行わせる。この
とき、正常に再生成された場合、空の証明書副本とプロ
セスの参照が戻される。 (6)正常な再生成が行われなければ、エラーとして処理
を打ち切る。 (7)オブジェクト再生成認証者よりもどされたオブジェ
クトの参照と空の証明書副本ならびに、解読された正本
情報、さらに認証情報データ・ベースなどによる情報に
従って、証明書正本を作成する。 (8)正本に副本の参照を設定する。 (9)正本にオブジェクトへの参照を設定する。 (10) 副本に対して初期設定要求をだす。 (11) 送信側の証明書正本に対して手順21の無効化処理
を行う。
【0139】<手順33プロセスの外部形式解読とハッシ
ュ値との照合を経たプロセス生成> (1)KXYによってプロセスの暗号を解読しプロセスの外部
形式を作る。 (2)外部形式にハッシュ関数を適用してハッシュ値Hを求
める。 (3)HとHashPとが一致しない場合、エラーとして処理を
打ち切る。 (4)もしも、実行環境の起動が必要な場合は、手順5に
したがって実行環境の起動を行う。 (5)手順31によってプロセスの生成を行う。 (6)生成されたプロセスの参照と空の副本の参照を戻
す。
【0140】
【発明の効果】本発明の移動可能プロセスの認証方法に
よれば、証明書管理機構の安全が確保されていることに
より、証明書正本副本の信頼性の保障が可能となり、他
の情報に依存することなく、証明書正本副本と移動可能
プロセスのみによって移動可能プロセスの移動時の認証
を行うが可能となる。従って、実行環境間において転々
と転送されて移動する移動可能プロセスが変化しても、
移動の元となった実行環境のプリンシパルと移動可能プ
ロセスとの相互参照可能な証明書正副データにより、当
該転送された移動可能プロセスの真正性を証明書管理機
構側で認証することが可能となり、移動可能プロセスの
不正コピーや、改竄、なりすまし、データの盗難・破壊
を防止することができ、移動エージェントなどの移動可
能プロセスのセキュリティーを顕著に向上させることが
できる。
【図面の簡単な説明】
【図1】本発明の認証機構の概念を示す図
【図2】本発明の証明書機構の基本構造を示す概念図
【図3】本発明のセキュリティ・ドメインの概念図
【図4】本発明で問題としているセキュリティ・ドメイ
ン間のプロセス移動の概念図
【図5】本発明の移動可能プロセスの認証手順の概念図
【図6】本発明のユーザー・オブジェクトへの証明書の
割付の概念図
【図7】本発明の移動可能プロセスの認証手順の概念図
【図8】本発明における証明書偽造への対策を示す概念
【図9】本発明における不正コピーへの対策を示す概念
【図10】本発明における偽装への対策を示す概念図
【図11】本発明におけるユーザー・オブジェクトへの
証明書の埋め込みを示す概念図
【図12】本発明における証明書管理機構自体を偽装し
ている場合の対策を示す概念図
【図13】本発明において配列又はハッシュテーブルに
より証明書と秘密の対応をさせた場合の概念図
【図14】正副証明書間に介在者が存在した場合のバケ
ツリレー攻撃の概念図

Claims (5)

    【特許請求の範囲】
  1. 【請求項1】移動可能プロセス生成時にユーザー等の生
    成者により与えられた認証情報を保持する証明書正本
    を、安全の確保された証明書管理機構に設置し、前記証
    明書正本より派生した証明書副本を前記移動可能プロセ
    スの実行環境内に設置し、前記移動可能プロセスと前記
    移動可能プロセスとを双方向に参照する参照により一対
    一に対応させ、前記証明書正本と前記証明書副本とを双
    方向に一対一に対応させ、前記証明書正本に前記移動可
    能プロセスへの参照を設定することを特徴とする移動可
    能プロセスの認証方法。
  2. 【請求項2】請求項1の移動可能プロセスの認証方法で
    あって、前記証明書正本副本、前記移動可能プロセス間
    の相互間の参照が整合すること、ならびに、前記証明書
    正本副本情報が整合することの確認をもって、前記移動
    可能プロセスの認証成功を判定し、当該認証処理におい
    て、前記証明書正本が前記証明書管理機構を代表すると
    見なすことをもって、前記証明書管理機構と前記移動可
    能プロセス相互の認証が行われたと判定し、前記証明書
    管理機構と前記移動可能プロセス以外の系には知り得な
    い共有の秘密生成を可能としたことを特徴とする移動可
    能プロセスの認証方法。
  3. 【請求項3】1以上のネットワークで接続された転送元
    実行環境と転送先実行環境と、前記転送元実行環境で生
    成された移動可能プロセス及び前記転送先実行環境の共
    有鍵KP1、並びに、前記転送先実行環境の共有鍵KP2を保
    持し、前記移動可能プロセスと相互認証を行っている証
    明書管理機構とにおける移動可能プロセスの認証方法で
    あり、第1のステップにおいて、転送に先立ち、前記移
    動可能プロセスは、前記証明書管理機構に対して共通秘
    密鍵KAJの生成を要求すると共に、この要求の際、前記
    移動可能プロセスは秘密の数SAを定め、TA=gSA mod p
    (pは素数、gはある整定数で、modは法演算をあらわ
    す)を計算してTAを前記証明書管理機構Jに渡し、第2
    のステップにおいて、前記証明書管理機構は前記移動可
    能プロセスの要求に答えて、秘密の数SJを生成して TJ
    =gSJ mod pを計算すると共に、共通鍵KAJをKAJ=TASJ mo
    d p とし、第3のステップにおいて、前記証明書管理
    機構は前記共有鍵KP2により前記共通秘密鍵KAJを暗号化
    して、KP2[KAJ]を計算し、第4ステップにおいて、前記
    証明書管理機構は、前記移動可能プロセスに対して、TJ
    とKP2[KAJ]を前記要求に対して回答し、第5ステップに
    おいて、前記移動可能プロセスは受け取ったTJから、KA
    J=TJSA mod pを計算して、共通鍵KAJを再生し、第6ス
    テップにおいて、前記移動可能プロセスは転送するオブ
    ジェクトを外部形式化して外部形式OExを生成した後、
    この外部形式OEx全体を前記共有鍵KAJにて暗号化してKA
    J[OEx]とを生成し、第7ステップにおいて、前記移動可
    能プロセスは前記転送元実行環境に対して、KAJ[OEx]と
    KP2[KAJ]とを前記転送先実行環境に転送することを要求
    し、第8ステップにおいて、前記転送元実行環境から前
    記転送先実行環境にKAJ[OEx]とKP2[KAJ]とが転送された
    とき、前記転送先実行環境はKAJ[OEx]とKP2[KAJ]とを解
    読して共有鍵KAJをつくることを特徴とする移動可能プ
    ロセスの認証方法。
  4. 【請求項4】請求項2における移動可能プロセスの認証
    方法であり、前記移動可能プロセスは移動可能オブジェ
    クトであり、この移動可能オブジェクトに、この移動可
    能オブジェクトに一対一に対応すると共に、前記転送元
    実行環境の本体であることを示すプリンシパルの識別が
    記載される名札オブジェクトを前記証明書副本として配
    置し、前記移動可能オブジェクトが前記名札オブジェク
    トを配布する場合を、(1)前記プリンシパルの主体が移
    動可能オブジェクトを直接生成した場合と、(2)前記プ
    リンシパルに所属するある移動可能オブジェクトAnが存
    在し、ある移動可能オブジェクトAが前記移動可能オブ
    ジェクトAnの結果として生じた場合とに限定し、前記
    (1)の場合に、前記プリンシパルの主体は、当該生成さ
    れた移動可能オブジェクトが当該プリンシパルに所属す
    ることを示す名札オブジェクトを生成し、前記(2)に、
    前記移動可能オブジェクトAnは当該移動可能オブジェク
    トAnの名札オブジェクトを複写して、前記移動可能オブ
    ジェクトAに付与することを特徴とする移動可能プロセ
    スの認証方法。
  5. 【請求項5】請求項2の移動可能プロセスの認証方法で
    あり、前記移動可能プロセスは移動可能オブジェクトで
    あり、前記証明書管理機構に、前記名札オブジェクトに
    一対一に対応する影の名札オブジェクトを前記証明書正
    本として配置すると共に、前記名札オブジェクトの内容
    と前記影の名札オブジェクトの内容とを常に一致させ、
    移動可能オブジェクトがプリンシパルに属するとして認
    証する場合を、(1)当該プリンシパルの主体が移動可能
    オブジェクトを直接生成した場合と、(2)ある移動可能
    オブジェクトAが、元となる移動可能オブジェクトAnの
    結果として生じた場合とに限定し、前記(1)の場合に、
    プリンシパルの主体は、プリンシパルの識別が記載され
    た名札オブジェクトを移動可能オブジェクトに対応づけ
    ると共に、その名札オブジェクトと同じ内容の影の名札
    オブジェクトとを対応させて、前記(2)の場合に、オブ
    ジェクトAnはオブジェクトAnの名札オブジェクトを複写
    してオブジェクトAに与え、その名札オブジェクトに影
    の名札が対応している場合に限り、影の名札オブジェク
    トの複写も行うことを特徴とする移動可能プロセスの認
    証方法。
JP9334581A 1997-12-04 1997-12-04 移動可能プロセスの認証方法 Pending JPH11168462A (ja)

Priority Applications (1)

Application Number Priority Date Filing Date Title
JP9334581A JPH11168462A (ja) 1997-12-04 1997-12-04 移動可能プロセスの認証方法

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
JP9334581A JPH11168462A (ja) 1997-12-04 1997-12-04 移動可能プロセスの認証方法

Publications (1)

Publication Number Publication Date
JPH11168462A true JPH11168462A (ja) 1999-06-22

Family

ID=18279010

Family Applications (1)

Application Number Title Priority Date Filing Date
JP9334581A Pending JPH11168462A (ja) 1997-12-04 1997-12-04 移動可能プロセスの認証方法

Country Status (1)

Country Link
JP (1) JPH11168462A (ja)

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2001265461A (ja) * 2000-03-22 2001-09-28 Sharp Corp 情報処理システム及び方法並びにこれに利用される記憶媒体
JP2006079144A (ja) * 2004-09-07 2006-03-23 Dainippon Printing Co Ltd 並列分散処理認証システム、および、並列分散処理認証方式
JP2009245089A (ja) * 2008-03-31 2009-10-22 Fujitsu Ltd 分散オブジェクト・プログラム及びレプリケーション処理方法

Cited By (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2001265461A (ja) * 2000-03-22 2001-09-28 Sharp Corp 情報処理システム及び方法並びにこれに利用される記憶媒体
JP2006079144A (ja) * 2004-09-07 2006-03-23 Dainippon Printing Co Ltd 並列分散処理認証システム、および、並列分散処理認証方式
JP4531498B2 (ja) * 2004-09-07 2010-08-25 大日本印刷株式会社 並列分散処理認証システム、および、並列分散処理認証方法
JP2009245089A (ja) * 2008-03-31 2009-10-22 Fujitsu Ltd 分散オブジェクト・プログラム及びレプリケーション処理方法

Similar Documents

Publication Publication Date Title
JP7194127B2 (ja) ネットワークの障害時におけるオフ・ブロックチェーン・チャネルに関して生じるセキュリティ関連脆弱性に対処するためのシステム及び方法
US11139984B2 (en) Information processing system, devices and methods
EP3073670B1 (en) A system and a method for personal identification and verification
US7908492B2 (en) Method for using a compact disk as a smart key device
US8112628B2 (en) Using a portable computing device as a smart key device
US7711951B2 (en) Method and system for establishing a trust framework based on smart key devices
CN111046352A (zh) 一种基于区块链的身份信息安全授权系统与方法
US8499147B2 (en) Account management system, root-account management apparatus, derived-account management apparatus, and program
WO2021008453A1 (zh) 一种基于标识认证的区块链离线交易方法和系统
EP3821586A1 (en) Systems and methods for secure custodial service
JP2005537559A (ja) トランザクションの安全な記録
US7849326B2 (en) Method and system for protecting master secrets using smart key devices
TW201913529A (zh) 基於區塊鏈智能合約的函證系統及其方法
JP6533542B2 (ja) 秘密鍵複製システム、端末および秘密鍵複製方法
CA3184856A1 (en) Method, participatant unit, transaction register, and payment system for managing transaction data sets
CN116720839B (zh) 基于区块链技术的金融信息管理方法及其监管系统
US11669833B1 (en) Blockchain endpoint protection
JPH1165443A (ja) 個人認証情報の管理方式
US20230298002A1 (en) Digital wallet tracing engine
JPH11168462A (ja) 移動可能プロセスの認証方法
JP2007298985A (ja) 銀行カードのコンピュータにおけるpki応用の一つの実現方法
TWI766171B (zh) 帳戶資料處理方法及帳戶資料處理系統
CN114553575B (zh) 一种基于Token的跨链通信认证方法
US20230222509A1 (en) Method, terminal, and coin register for transmitting electronic coin data sets
WO2024084262A1 (en) Blockchain endpoint protection