移動可能プロセスの認証方法
【課題】改竄、不正コピー等を防止可能な移動可能プロセスの認証方法の提案
【解決手段】 移動可能プロセス生成時にユーザー等の生成者により与えられた認証情報を保持する証明書正本を、安全の確保された証明書管理機構に設置し、前記証明書正本より派生した証明書副本を前記移動可能プロセスの実行環境内に設置し、前記移動可能プロセスと前記移動可能プロセスとを双方向に参照する参照により一対一に対応させ、前記証明書正本と前記証明書副本とを双方向に一対一に対応させ、前記証明書正本に前記移動可能プロセスへの参照を設定することを特徴とする移動可能プロセスの認証方法。
【解決手段】 移動可能プロセス生成時にユーザー等の生成者により与えられた認証情報を保持する証明書正本を、安全の確保された証明書管理機構に設置し、前記証明書正本より派生した証明書副本を前記移動可能プロセスの実行環境内に設置し、前記移動可能プロセスと前記移動可能プロセスとを双方向に参照する参照により一対一に対応させ、前記証明書正本と前記証明書副本とを双方向に一対一に対応させ、前記証明書正本に前記移動可能プロセスへの参照を設定することを特徴とする移動可能プロセスの認証方法。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】本発明は、ネットワークを構成するコンピュータ間において移動する移動可能プロセスのマルチ・ホップ認証方式とその各種の変形に関する。
【０００２】
【従来の技術】ネットワーク間を移動する移動エージェントなどの移動移動可能プロセスにおいては、当該移動プロセスが移動する際に、当該移動プロセスが真正なところから発信されたものであるかどうか、の認証の問題が伴う。例えば、図4のネットワーク構成において、認証サーバーA, B, Cがあたえられ、そのサーバーそれぞれに統治される３つのドメインa, b, cが存在すると仮定する。また、ドメインａ，ｂ，ｃ間は通信回線で結合されており、セキュリティ・プロトコルに準拠したデータのやり取りが可能であるとする。このとき、ドメインａにあるプロセスをPxとし、それをドメインb、ドメインc、に移動させる事を考える。
【０００３】従来の認証方法は、認証を受ける側と与える側とで他には知り得ない秘密を共有することや、他の存在は所持し得ない持ち物を提示する事によって行われていた。それらの秘密や特定のための情報は、パスワードや暗号鍵、IC-カード、個人の身体的な特徴などである。プロセスの移動を考慮しない場合のプロセスの認証は、プロセスの生成時に生成者本人が認証者に対してその秘密や持ち物を提示する事によって行われていた。
【０００３】また、公開鍵暗号方式を利用する場合、本人が自分しか知らない秘密鍵で署名を行い、その署名の確認は対応する公開鍵で署名が読めるかどうかで行われる。公開鍵を使用する場合、個人が持つ秘密鍵を外部に一切知らせずに、公知の公開鍵だけで確認ができる点が長所である。この技術を使用する場合、署名を公的な機関に登録する事によって、署名に対する公的な認証効果を持たせる事が可能である。ここにおいて、両者に共通している事は、個人だけにしか持ち得ない持ち物や秘密の存在を仮定している点である。尚、あらかじめ、以下の記述で主要な役割を持つ用語を定義しておく。
【０００４】[プロセス]本発明では、プロセスという用語を通常より拡大された意味で用いる。それは、本発明の目的が、いわゆる移動エージェントと呼ばれるネットワーク上を移動しながら一連の手順を実行するオブジェクトプログラムに対する認証機構を定めるためである。そこで、本発明では、プロセスという用語に対して、従来のプロセスの意味に加えて、移動エージェントを構成し得るオブジェクトという意味を与える。ここには、基礎となるシステムに応じて、タスク、実行スレッド、スクリプトなどを含ませることが可能である。
【０００５】[プロセスの外部形式]プロセスの外部形式とは、実行中のプロセスをネットワーク上の別のホストや外部記憶媒体などに転送する際の形式をいう。そこには、プロセスを構成する手順と実行時の内部状態データ、制御情報などが含まれている。オブジェクト指向システムでは、シリアライゼーション（Serialization:直列化）と呼ばれる技法が使用される事が多い。本発明では、所によっては、プロセスの外部形式を生成する意味で、シリアライゼーションという用語を使用する場合がある。ただし、本発明では、外部形式のデータ構造や手法は特に限定しない。
【０００６】[認証者]認証者 (Authenticator) とは、単一あるいは複数の処理手続きであって次のような機能をもつものをいう。
1) 証明書の真正性の判定を行う。
2) 証明書の真正性にもとづいて証明書と対応付けられたプロセスなどのオブジェクトに対する認証をあたえる。
3) ドメインを管理する証明書管理機構の特定をする。この機能は、認証者固有の機能である。その他、の機能は実装上の判断によっては、次に述べる証明書管理機構に行わせることも考えられる。
4) エージェントなどの移動可能プロセスに対する移動時の認証を行う。
5) ユーザーに対する認証を与える。
6) 認証にもとづいて証明書の発行を行う。
【０００７】認証者は、これらの機能を実現するに当たって証明書管理機構にアクセスし、そこで保持されている証明書データを使用する事が可能である。また、証明書管理機構間で定められた秘密情報を利用する事も許されている。従って、認証者の安全性を保証する必要がある。もっとも、必ずしも、全ての認証者が上記の機能の全てを実装するわけではなく、上記の機能の一部だけを実装する事によって、様々なタイプの認証者が実現され得る。
【０００８】例えば、ユーザーの認証を行い、そのユーザーが所有するオブジェクトやプロセスそして、それらに対応する証明書を発行する認証者は、ユーザー認証者などと呼ばれるであろうし、移動時のエージェントの認証を専門に行う認証者はエージェント認証者などと呼ばれるかもしれない。
【０００９】[証明書管理機構]証明書管理機構は、正本、副本からなる証明書のうち、証明書正本を複数管理する。これは、証明書管理機構固有の機能の一つである。一般に、認証を与えるサーバーのことを認証サーバーと呼んでいるが、本発明では、認証を与え証明書の発行／管理をも行うサーバーもしくはサーバーと同等な機能を有する装置に対して証明書管理機構なる用語を与える事にする。証明書管理機構は外部からの不正アクセスに対して安全であることが必要である。ある証明書管理機構は、別の証明書管理機構と秘密を共有する等の方法によって相互認証を行う事が可能であることが要求される。これは、二つ目の証明書管理機構固有の機能である。ただし、本発明では証明書管理機構間の相互認証の方式に関しては特に定めない。なお、本発明では、所によっては、証明書管理機構の意味で認証サーバーとかサーバーという用語を用いる場合もある。通常、証明書管理機構には、専用の独立したホスト・マシンが与えられている。
【００１０】[認証機構]上に記した認証者と証明書管理機構との組が本方式での認証機構を形成する。認証者は認証を与えるオブジェクトと証明書管理機構との仲介を行う立場にある。認証機構全体から見ると、上記の認証者と証明書管理機構との役割はある程度流動的なものと考えても良い。上で記された認証者の機能の一部を証明書管理機構側に持たせる事などは、本発明で述べる証明書方式を利用した認証機構の実装上の判断として許される。従って、以下の本発明の記述に関して、証明書管理機構の機能とされる部分を認証者に行わせたり、その逆を行わせたりする変形が生じたとしても、その多くは認証機構の機能としてみると、本発明で述べる記述と本質的な違はない。このような役割配分の検討を行う最大の理由は、証明書管理機構への負荷の集中を回避する事にある。
【００１１】尚、認証者の存在理由は、セキュリティ・ドメイン内に存在する証明書副本がどのような改ざんにあったとしても、対応する証明書正本を見つけ出せる事を保証する事にある。
【００１２】[環境]手続き、プロセス、オブジェクトなどの実行を行う場一般を環境と呼ぶ事とする。ここには、コンピュータ・ハードウェア、オペレーティング・システム、仮想マシン、サーバー・プログラムなどを含ませることが可能であるが、手続き、プロセス、オブジェクト等が実行可能でありさえすれば、本発明ではその形態を問題にはしない。ただし、所によっては、オペレーティング・システムや仮想マシンのニュアンスを込めて実行環境という用語も使用する。
【００１３】[通信機構]環境と環境との間で情報の交換を可能にする機構を通信機構とよぶ。所によって通信システム、通信回線という用語も同じ意味に使用することもある。通信機構自体は信頼性が高いと仮定する。すなわち誤りの無い通信が可能である。しかし、悪者による意図的な盗聴やノイズの混入も有り得ると仮定する。
【００１４】[証明書]プロセスやオブジェクトの認証情報を保持するデータを証明書という。本システムの証明書は正副の２つ証明書データから構成される。証明書の正本は、証明書管理機構側に置かれ、証明書の副本はユーザー環境のセキュリティ管理プログラム内に置かれる。そして、正副証明書相互は双方向の参照でリンクされている。
【００１５】[セキュリティ・ドメイン]証明書管理機構などの認証サーバーは権威あるプロセスであって、厳密な安全対策が施されていると想定する。従って、証明書管理機構への侵入やデータの改ざんは困難である。このことが、本機構内で証明書の唯一の存在を保証する前提である。証明書管理機構など認証サーバーの周辺には、その認証サーバーによって統治されているユーザー環境が複数存在している。そのような、認証サーバーに統治されるユーザー環境内のオブジェクトの集合が、セキュリティ・ドメインを構成する。セキュリティ・ドメイン中のオブジェクトは認証サーバーによって認証されているものもあれば、認証されていないものもある。認証されていないオブジェクトは、原則としてゲストとして扱われ公共の資源に対するアクセスだけが許可される。認証されたオブジェクトの集合が安全なドメインを形成する。本発明では、特に断りの無い限り、このような安全なドメインだけを考える事にする。
【００１６】
【発明が解決しようとする課題】[移動可能プロセスの認証問題]しかし、従来の技術で述べた認証方式を図１０R>０のような移動するプロセスの認証に使用する事は、実際上不可能である。第１の理由として、情報であるプロセスに個人が所持している物体を持たせる事は不可能だからである。第２の理由として、個人と認証サーバーで共有している暗号鍵や、公開鍵暗号方式の秘密鍵をプロセスに保持させることは、秘密の漏洩の恐れがあるため、安全上好ましくないからである。しかし、たとえ秘密をプロセスに持たせなくても、プロセスPxはドメインａにて生成され、認証サーバーAにて認証されている場合、ドメインaからドメインbに移動させる際の認証は可能であり、認証サーバＡの認証を通じて、プロセスPxをドメインbにて受け入れることは可能である。
【００１７】これは、認証サーバAがプロセスPxの生成に直接関与し、プロセスPxの生成時に、プロセスPxの生成を要求した人物本人の認証を行うために必要な情報を保持しているからであり、ドメインｂの認証サーバBの要求を満足させるだけの認証情報を、認証サーバAがプロセスPxに対して付加することが可能なためである。例えば、プロセスPxをドメインｂに送る際、ドメインa内でプロセスPxの生成者の秘密鍵を利用した署名をつけ、プロセスPxをドメインbに送った後に、ドメインｂの認証サーバBが公開鍵で当該署名を確認することなども可能である。
【００１８】[移動可能プロセスの多段階の認証問題]では、ドメインb上に移動したプロセスPxが次にドメインcに移動する場合、同じ手続きが可能であろうか？ これは、困難である。認証サーバーBが認証サーバーCに対して簡単にプロセスPxの認証を与える事はできない。なぜなら、そもそもプロセスPxはドメインbにて生成されたものではないためである。では、サーバーCはサーバーAに問い合わせを行いプロセスPxの認証情報を受ける事ができるだろうか？ それも、困難である。プロセスPxはドメインb上にて処理を行い、その内部状態はドメインa上で処理を行っていた時とは異なっているためである。厳密には、ドメインa上にて活動していたプロセスPxは、ドメインbに移動した時点からプロセスPx'としてプロセスPxとは区別して扱うべき物となっているからある。
【００１９】従って、認証サーバーAとしては、プロセスPx'がプロセスPxの処理の結果なのか、別のプロセスPyがプロセスPx'と詐称しているのか区別する事はきわめて困難である。また、上述した第１の理由を再検討すると、プロセスPxの生成者の秘密鍵を認証サーバーAから認証サーバーBに送る事も機密保持上許されることではない。仮に送信できるとしても、署名等の認証情報を付加されたプロセスPx'が、元々のプロセスPxによる直接の結果であるかどうかを確認することは、困難である。ここで、仮定としてプロセスPxが生成者本人の所持する秘密鍵Kを所持していた場合を考える。認証サーバーCは認証サーバーAにある（任意の或いは所定の？）数Xを提示してもらい、プロセスPxにその秘密鍵Kで数Xを暗号化したK[X]を作らせ、この数Ｋ[Ｘ]を認証サーバーAに確認させ、認証を行う事も確かに可能ではある。
【００２０】しかし、コンピュータ上ではプロセスPxの内部状態まで含めた複写は容易であって、プロセスPxを複写して生成されたプロセスPy（プロセスPxとは異なる）であっても、上の手順は実行可能であって、同様に認証をうけることが可能である。従って、この認証手続きには欠陥がある。尚、移動エージェントの多段階の認証(Multi-hop Authentication)に関しては、「GMD FOKUS、International Business Machines Corporation、Supported by: Crystaliz, Inc.、 General Magic, Inc.、The Open Group "Joint Submission : Mobile Agent System Interoperability Facilities Specification" 、November 10, 1997 OMG TC Document orbos/97-10-05」がある。この論文内には、セキュリティ技術的には未解決である、という記述が見られる。これは、上記ような問題を指すのであろう。この記述については、本発明の第１９実施形態において再び取り上げる。
【００２１】発明者は、このような問題につき以下のように考察した。移動可能プロセスの認証は、移動可能プロセスが確かに移動可能プロセスの所有者のプリンシパル（人間のユーザー、或いはシステム実体であって、認証システムに登録されており、本物であると認められているもの。以下、同じ）に属すことを証明することである。移動可能プロセスはあくまでプリンシパルの代理であり、しかも物体ではなくプログラムと内部データとが複合されたものである。また、内部データは処理の進行に応じて変化するし、コピーも可能である。このため様々な制約や困難が生ずる。そのような制約や問題の幾つかを整理すると、以下の通りとなる。
【００２２】(1) 移動可能プロセス自身にキーを持ち運ばせるのは、プライベート・キーを公開することと同じであるため、危険である。従って、プリンシパルを証明する方式としての、プライベート・キーによる暗号化は移動可能プロセス自身は使えない。
(2)データが変化するので、ハッシュ関数の値を認証の根拠に使うことは出来ない。
(3)一時的なパスワードを移動可能プロセスに保持させることも不可能ではないが、移動可能プロセスはデータでもあるので、パスワードを含めた移動可能プロセス全体をコピーした後に改ざんを受ける可能性がある。
(4)移動可能プロセスの不変部分（移動可能プロセスのコード部など）に署名を付加することも考えられるが、可変部分の信用を保証することはできない。たとえば、不変部分と署名だけをコピーして、可変部分を偽造することも可能だからである。
【００２３】[移動可能プロセスの認証方法]本来、移動可能プロセスの認証とは何を意味するのか？ 移動前の移動可能プロセスAと移動後の移動可能プロセスA'が、同じものであることを証明するとは、何を言っているのか、その正確な意味を定義する必要がある。「同じ」とは決して物理的な同一性を指している訳ではない。実際、移動後の移動可能プロセスA'は、移動前の移動可能プロセスAのコピーである。コピーということは、厳密には同一のものではないということである。このことは、移動可能プロセスの移動自体が、人や物の移動とは異なっていることを意味している。人間世界での認証では、人物のコピーは通常有り得ないとされ、認証行為もその前提で実施される。従って、顔かたちが「同じである」ということの証明が、認証方法として一般に通用するのである。この一般的な通念を覆す例が、双子の片方によって成された犯罪が、状況証拠のみしかない場合、犯人の確定を困難なものにするケースである。この場合、「似ている」という意味を含む「同じ」は、同一性の認証の基準には採用できない。
【００２４】移動可能プロセスの認証にも、やや似た状況が発生している。移動したプロセスが正確なコピーなのか、模造なのかの識別は、両者とも厳密な意味で原本とは同一物でない以上、困難である。すなわち、移動可能プロセスの認証の正確な意味を定義し直す必要がある。
【００２５】
【課題を解決するための手段】発明者は、この認証問題の解決に当たって、ネットワーク上に唯一の存在が保証されている証明書もしくは、許可証があると都合がよいと考える。その実現方法は、認証サーバー上に証明書の正本を置き、ユーザー側にその副本を置くことによる。その際、正本と副本の両者間に双方向の参照を配置する。証明書を生成する際、オーナーのプリンシパルの認証を事前に必要とする。認証の結果として発行された証明書は、ネットワーク上に唯一存在し、複製が不可能であるため、その証明書が盗まれない限り、証明書を保持するという事実自体が認証効果をもつ。これは、パスポートや運転免許証の開示によって本人を認証することと同様である。いわばネットワーク上の身分証明書として通用する。ここにおいて、証明書は、外部形式化可能なデータであり、ネットワーク上を移動させる事が可能なものとする。また、移動や二次記憶媒体への保存には、証明書の唯一性を保証するための手続きを必要なものとする。換言すれば、移動可能プロセスの認証は、移動可能プロセスが属する責任の主体を確定することにより確立される。このことは、移動可能プロセスが与える結果に対して誰に責任を問えるのかを確定する事であるとも言える。
【００２６】なぜなら、移動プロセスは常にその状態を変化させ続けている変化の過程にあるものであって、固定されたものではないため、物体の帰属を問うように移動プロセスに対してそのもの自身の帰属を問うことは出来ない。しかし、その変化の原因-結果の連鎖を原因側にたどって行くことによって、最終的に開始プリンシパルに達するならば、その変化の一局面に対して開始プリンシパルに属する移動プロセスとして認証を与えても良い。すなわち、転送元実行環境にて移動可能プロセスAはすでに認証されていることを帰納法の仮定とすると、移動可能プロセスA'が、移動可能プロセスAからの直接の結果として生じたことを証明できれば、移動可能プロセスA'が、移動可能プロセスAのプリンシパルに属していると主張してよい。
【００２７】この主張を形式的に表現すると、次のような移動可能オブジェクトの認証に関する定義に到達する。ここで、プロセスはオブジェクトの特殊な形態とみなす。
定義1． 移動可能オブジェクトの認証とは、そのオブジェクトが所属するプリンシパルを確定することである。
定義2．移動可能オブジェクトAがプリンシパルPに属するということを次のように帰納的に定める。
【００２８】(1)プリンシパルPの主体がオブジェクトAを直接生成した場合、オブジェクトAはプリンシパルPに所属する。
(2)プリンシパルPに所属するあるオブジェクトAnが存在し、オブジェクトAがオブジェクトAnの結果として生じた場合、オブジェクトAはプリンシパルPに所属する。
(3)オブジェクトAがプリンシパルPに所属するのは、上の(1),(2)の場合に限る。
この定義を具体的な場合にあてはめてみる。シリアライゼーションなどによって外部形式化された移動可能プロセスＡ１のデータ列A2が、転送先実行環境において、元になる移動可能プロセスA1自身によって作成されたことを証明できれば、そのデータ列A2は、移動可能プロセスA1のプリンシパルＰに属しているとして良い。その結果、そのデータ列A2が転送先実行環境でも認証された事になる。
【００２９】さらに、データ列A2をデシリアライズされたデータ列A3もまた移動可能プロセスA1と同じプリンシパルに所属すると判断できる。従って、データ列A3の認証も行われたことになる。このことを実際に応用するためには、移動可能プロセスの転送時における、移動可能プロセスの外部形式化されたオブジェクトが、移動可能プロセス自身の結果として生じたということを明示する必要がある。この、原因-結果の関係を転送時に明確に主張する形の移動可能プロセス（またはオブジェクト）の転送方法を次に記す。
【００３０】このような課題を解決するために、本発明の請求項１は、移動可能プロセス生成時にユーザー等の生成者により与えられた認証情報を保持する証明書正本を、安全の確保された証明書管理機構に設置し、前記証明書正本より派生した証明書副本を前記移動可能プロセスの実行環境内に設置し、前記移動可能プロセスと前記移動可能プロセスとを双方向に参照する参照により一対一に対応させ、前記証明書正本と前記証明書副本とを双方向に一対一に対応させ、前記証明書正本に前記移動可能プロセスへの参照を設定することを特徴とする。
【００３１】また、本発明の請求項２の発明は、請求項１の移動可能プロセスの認証方法であって、前記証明書正本副本、前記移動可能プロセス間の相互間の参照が整合すること、ならびに、前記証明書正本副本情報が整合することの確認をもって、前記移動可能プロセスの認証成功を判定し、当該認証処理において、前記証明書正本が前記証明書管理機構を代表すると見なすことをもって、前記証明書管理機構と前記移動可能プロセス相互の認証が行われたと判定し、前記証明書管理機構と前記移動可能プロセス以外の系には知り得ない共有の秘密生成を可能としたことを特徴とする。
【００３２】また、本発明の請求項３の発明は、１以上のネットワークで接続された転送元実行環境と転送先実行環境と、前記転送元実行環境で生成された移動可能プロセス及び前記転送先実行環境の共有鍵KP1、並びに、前記転送先実行環境の共有鍵KP2を保持し、前記移動可能プロセスと相互認証を行っている証明書管理機構とにおける移動可能プロセスの認証方法であり、第１のステップにおいて、転送に先立ち、前記移動可能プロセスは、前記証明書管理機構に対して共通秘密鍵KAJの生成を要求すると共に、この要求の際、前記移動可能プロセスは秘密の数SAを定め、TA=gSA mod p（pは素数、gはある整定数で、modは法演算をあらわす）を計算してTAを前記証明書管理機構Jに渡し、第２のステップにおいて、前記証明書管理機構は前記移動可能プロセスの要求に答えて、秘密の数SJを生成して TJ=gSJ mod pを計算すると共に、共通鍵KAJをKAJ=TASJ mod p とし、第３のステップにおいて、前記証明書管理機構は前記共有鍵KP2により前記共通秘密鍵KAJを暗号化して、KP2[KAJ]を計算し、第４ステップにおいて、前記証明書管理機構は、前記移動可能プロセスに対して、TJとKP2[KAJ]を前記要求に対して回答し、第５ステップにおいて、前記移動可能プロセスは受け取ったTJから、KAJ=TJSA mod pを計算して、共通鍵KAJを再生し、第６ステップにおいて、前記移動可能プロセスは転送するオブジェクトを外部形式化して外部形式OExを生成した後、この外部形式OEx全体を前記共有鍵KAJにて暗号化してKAJ[OEx]とを生成し、第７ステップにおいて、前記移動可能プロセスは前記転送元実行環境に対して、KAJ[OEx]とKP2[KAJ]とを前記転送先実行環境に転送することを要求し、第８ステップにおいて、前記転送元実行環境から前記転送先実行環境にKAJ[OEx]とKP2[KAJ]とが転送されたとき、前記転送先実行環境はKAJ[OEx]とKP2[KAJ]とを解読して共有鍵KAJをつくることを特徴とする。
【００３３】更に、本発明の請求項４の発明は、請求項２における移動可能プロセスの認証方法であり、前記移動可能プロセスは移動可能オブジェクトであり、この移動可能オブジェクトに、この移動可能オブジェクトに一対一に対応すると共に、前記転送元実行環境の本体であることを示すプリンシパルの識別が記載される名札オブジェクトを前記証明書副本として配置し、前記移動可能オブジェクトが前記名札オブジェクトを配布する場合を、(1)前記プリンシパルの主体が移動可能オブジェクトを直接生成した場合と、(2)前記プリンシパルに所属するある移動可能オブジェクトAnが存在し、ある移動可能オブジェクトAが前記移動可能オブジェクトAnの結果として生じた場合とに限定し、前記(1)の場合に、前記プリンシパルの主体は、当該生成された移動可能オブジェクトが当該プリンシパルに所属することを示す名札オブジェクトを生成し、前記(2)に、前記移動可能オブジェクトAnは当該移動可能オブジェクトAnの名札オブジェクトを複写して、前記移動可能オブジェクトAに付与することを特徴とする。更に、本発明の請求項５の発明は、請求項２の移動可能プロセスの認証方法であり、前記移動可能プロセスは移動可能オブジェクトであり、前記証明書管理機構に、前記名札オブジェクトに一対一に対応する影の名札オブジェクトを前記証明書正本として配置すると共に、前記名札オブジェクトの内容と前記影の名札オブジェクトの内容とを常に一致させ、移動可能オブジェクトがプリンシパルに属するとして認証する場合を、(1)当該プリンシパルの主体が移動可能オブジェクトを直接生成した場合と、(2)ある移動可能オブジェクトAが、元となる移動可能オブジェクトAnの結果として生じた場合とに限定し、前記(1)の場合に、プリンシパルの主体は、プリンシパルの識別が記載された名札オブジェクトを移動可能オブジェクトに対応づけると共に、その名札オブジェクトと同じ内容の影の名札オブジェクトとを対応させて、前記(2)の場合に、オブジェクトAnはオブジェクトAnの名札オブジェクトを複写してオブジェクトAに与え、その名札オブジェクトに影の名札が対応している場合に限り、影の名札オブジェクトの複写も行うことを特徴とする。
【００３４】
【実施の形態】以下に、本発明の実施形態を説明する。
[実施形態１：移動可能プロセスの認証方法]図５は、本発明の第１の実施の形態を示す。図５において、転送元実行環境をP1，宛先実行環境をP2，移動可能プロセスをAとする。さらに、認証キーを生成する審判サーバーJの存在を仮定する。Jは鍵配布センター(KDC)が兼務してもよい。ここで、AとJとは相互認証を行っていると仮定する。またpは素数、gはある整定数で、事前に決めていてもよいし、通信時に定めても良い。また、modは法演算をあらわす。
(1)転送に先立って、移動可能プロセスAはDiffie-Hellman方式を使って、審判サーバJに対して共通秘密鍵KAJの生成を依頼する。この際Aは秘密の数SAを定め、TA=gSA mod p を計算し、TAを審判サーバJに渡す。
(2)審判サーバJは移動可能プロセスＡの要求に答えて、秘密の数SJを生成し、TJ=gSJ mod pを計算する。さらに共通鍵KAJも KAJ=TASJ mod p とする。
(3)審判サーバJは宛先実行環境P2の共有鍵KP2を保持しており、この共有鍵KP2により前記の共有鍵KAJを暗号化し、KP2[KAJ]を計算する。
(4)審判サーバJは、移動可能プロセスAに対して、TJとKP2[KAJ]を要求に対する回答としてあたえる。
(5)移動可能プロセスAは受け取ったTJから、KAJ=TJSA mod pを計算することによって、共通鍵KAJを再生する。
(6)移動可能プロセスAは転送するオブジェクトOを外部形式化し外部形式OExを作る。そして外部形式OEx全体を共有鍵KAJにて暗号化し、これをKAJ[OEx]とする。（このとき、外部形式OExに共有鍵KAJを連結したものをつくり、そのデータ列のメッセージ・ダイジェストを求め、ダイジェスト値と外部形式OExの組をKAJ[OEx]としても良い。）
(7)移動可能プロセスAは転送元実行環境P1に対して、KAJ[OEx]とKP2[KAJ]とを宛先実行環境P2に転送してもらうことを要求する。
(8)転送元実行環境P1から宛先実行環境P2にデータが転送されたとき、KP2[KAJ]を解読して共有鍵KAJをつくる。この共有鍵KAJにてKAJ[OEx]を解読可能であることを根拠に、この外部形式データOExが移動可能プロセスAによって作成されたことが確認できる。そこで、外部形式OExを内部形式化したオブジェクトO'に対して、移動可能プロセスAのプリンシパルに属するという認証を与える事ができる。
【００３５】上の転送手続きでは、転送元実行環境P1が悪意を持って、移動可能プロセスAの内部コードを解析しない限り共有鍵KAJを知ることはできない。上の手順は移動可能プロセスAと審判サーバJとがすでに相互認証を行っていることを仮定している。よって、移動可能プロセスAと審判サーバJしか知る事ができない共有秘密鍵KAJは、信頼できる審判サーバJによって移動可能プロセスAの関与を保証している、と考えることが出来る。従って、KAJ[OEx]が移動可能プロセスAによる結果であるという、原因-結果の連鎖の存在を証明している。故に、外部形式OExが移動可能プロセスAのプリンシパルに属していることが証明されており、さらに外部形式OExを内部形式化して得られるオブジェクトO'も移動可能プロセスAと同じプリンシパルに属していることが示される。
【００３６】この手順は実行環境自体が信頼できない場合には成立しない。実際、悪意を持っている者が、コアダンプをとったり、デバッガーを使用したりすることによって、共通鍵KAJを移動可能プロセスAから取り出すことは困難ではない。ただ、KP2[KAJ]を作る際に審判サーバJによってタイムスタンプを付加してKP2[KAJ|タイムスタンプ]とすることなど、有効期限を課すことで、悪意ある試みにある程度は対抗することもできる。例えば有効期限をタイムスタンプから10分以内とすると、10分間で、共通鍵を取り出し、偽のデータを作成し、P1からP2に転送することは、実際上は、かなり難しい。
【００３７】[第２の実施形態：移動可能プロセスの認証方法の問題点と名札による解決]第１の実施形態で提示した移動可能プロセスの認証方法には、2つの解決しなくてはならない問題がある。一つは、プロセスまたはオブジェクトの所属関係は、理論的には定義されていても、プログラムで使用できるような具体的な表現が与えられていない点である。具体的には、「プロセスAがプリンシパルPに所属する場合」などというとき、処理プログラムが、プロセスAからどのようにしてプリンシパルPという情報を知るのかは、一切触れられていない。
【００３８】もう一つは、移動可能プロセスと審判と呼ばれるサーバーとが、相互認証されているという前提である。この点につき、プロセスの認証を論じているのにその前提として、あらかじめ相互認証されていると仮定することは、循環論法にならないかという疑問が生じるかもしれない。しかし、実際には、この仮定は循環論法ではなく、一種の帰納法の仮定に相当するものである。しかし、これが帰納法の仮定として、通用するためには、本発明の認証結果が単に受け入れ側での認証にとどまらず、受け入れ側と受け入れ側を管理する新たな審判サーバーにも認証できるような、より強い認証手順が求められていることを示している。
【００３９】この２つの問題を解決するために、移動可能オブジェクトに対して、名札とよばれる特殊なオブジェクトを対応させる。名札には転送元実行環境のプリンシパルの識別が記載されており、移動可能オブジェクトに一対一に対応している。移動可能オブジェクトが所属しているプリンシパルの識別が記載されている名札オブジェクトを、特にクレデンシャルと呼ぶ。前述の認証に関する定義２を次のように書きかえると、認証とクレデンシャルの保持とを同一視することが可能なことは、明らかである。
【００４０】クレデンシャルの配布手順 (定義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)の場合に限る。
【００４１】[第３の実施形態：影の名札付きクレデンシャル配布手順]第２の実施形態において、プログラムの操作対象として、名札を見る場合、任意のオブジェクトに任意の名札を与えることは現実に可能であるし、他のオブジェクトがもつ名札を勝手に複写したり、書き換えたりすることも可能である。このように、名札が上のクレデンシャル配布手順以外の方法でも容易に割り付けられる以上、名札とクレデンシャルとの判別が可能な、より実際的な仕組みが必要である。そこで、上のクレデンシャル配布手順にさらに制限を加えた、影の名札付きのクレデンシャル配布手順を考える。影の名札とは、選ばれた名札に一対一に対応づけられたオブジェクトのことで、しかも、名札の内容と影の名札の内容は常に一致するように、名札には影の名札の内容が自動的に反映されるものと仮定する。
【００４２】移動可能オブジェクト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)の場合に限る。
この手順だけを使用してクレデンシャルの割付が行われることを仮定するならば、帰納法によって、クレデンシャルが存在することと影の名札が存在することが同値になることは、明らかである。従って、あるプロセスが影の名札を持つならば、そのプロセスの認証を行うことは可能である。この影の名札付きクレデンシャル配布手順に相当するシステムをプログラムとして実装することは可能である。すると、前節において、プロセスの原因-結果という関係で与えられていた、プロセスの認証を、影の名札に対応付けられたクレデンシャルというデータに基づく認証に置きかえることが可能になる。
【００４３】[第４の実施形態：影の名札付きクレデンシャル配布システムとしての証明書機構]第３の実施形態で議論されたクレデンシャルを構成する名札と影の名札の組を、ネットワークで結合されたコンピュータ上に実装する仕組みとして証明書機構を利用する。ここでは、名札に相当するものが証明書副本と呼ばれ、それはオブジェクトと一対一に対応する。（図6参照）第３の実施形態で影の名札と呼ばれたものは、ここでは証明書正本として実装される。証明書副本の内容は、証明書正本の内容によって2重化され、破壊や改ざんから保護される。証明書正本を証明書副本が置かれているホストとは異なる厳重な安全対策が実施されているホストに置く。これによって、影の名札がクレデンシャル以外の名札とは結合しないことの保証が可能である。さらに、ユーザー・オブジェクト生成時に、プリンシパルの認証を行った後に、オブジェクトに正副証明書を割り付けることとする。
【００４４】これは、第３実施形態の[影の名札付きクレデンシャル配布手順]における「(1)プリンシパルPの主体が直接オブジェクトAを生成した場合、オブジェクトAはプリンシパルPに所属する。このとき、プリンシパルPの主体は、プリンシパルPの識別が記載された名札オブジェクトをオブジェクトAに対応つける。この時、その名札と同じ内容の影の名札を対応させる。」という個所に対応する。証明書副本からユーザー・オブジェクトへの参照をもたせるのと同時に、証明書正本からもユーザー・オブジェクトへの参照をもたせるているため、２つの参照がクレデンシャルとプロセスやオブジェクトとの対応を実現している。万一、副本側の参照が壊れても、実装上クレデンシャルからプロセスへの対応は確保される。
【００４５】もう一つ注目すべき点は、証明書副本はプロセスの所有者に属し、証明書正が認証サーバーの所有者に属しているという仮定を置くと、証明書正本が証明書副本を知っていることと、証明書副本が証明書正本を知っていることとが、結果的にオブジェクト同士の相互認証がとなっている点である。ここで行った仮定が充分に信頼できるならば、証明書正本、副本間（結果的にはプロセスと認証サーバー間で）、Diffie-Hellam法を実施することが可能となり、本発明の移動可能プロセスの認証手順を実現することが可能になる。
【００４６】ところで、この機構の背景にある考えは、どのようにすれば、CORBA・セキュリティ・サービスで使用されているクレデンシャル・オブジェクト（Credential：信任状）自体に認証効果を与えることができるだろうか、という疑問に答えることにある。CORBA・セキュリティ・サービスのシステムでのクレデンシャルは、認証時にパスポートや免許証のように提示するだけで認証が可能となるものではなかった。そのため、本人確認時に、パスポートや車の運転免許証などの提示するだけで認証が可能になるシステムをネット上に形成することができないだろうかと考えた。
【００４７】一般に、パスポートなどの証書は、個人が携帯するパスポートの冊子や免許証のカードそれぞれに対して、所轄の機関で保存されている管理情報の存在が前提になっている。それらの情報作成の際、本人確認の手順が実施される。その手順の一環として、戸籍謄本や住民票の提出などが義務づけられている。そのため、パスポートや免許証を携帯しているという事実によって本人の認証が行われているのである。もしそれらの証書自体に疑念がある場合、所轄の機関に証書の真正性の問い合わせが行われる。証書の偽造はできても、所轄の機関に保存されている情報の偽造は困難であるため、このような問い合わせは有効である。
【００４８】ネットワーク上をこのような証明書をもったプロセスが移動するとき、証明書とプロセスの組み合わせを保証する形で転送処理を行う必要がある。このことを保証するために、暗号技術を応用した転送手順の考案を行った。これは、第３実施形態の[影の名札付きクレデンシャル配布手順]における「(2)プリンシパルPに所属するあるオブジェクトAnが存在し、オブジェクトAがオブジェクトAnの結果として生じた場合、オブジェクトAはプリンシパルPに所属する。このとき、オブジェクトAnはオブジェクトAnの名札を複写してオブジェクトAに与える。もしも、その名札に影の名札が対応している場合、その場合に限り、影の名札の複写も行う。」という部分に相当する。この手順については、次の第５実施形態で詳述する。
【００４９】[第５実施形態： 証明書を応用したプロセス移動方式]プロセスPxと正副証明書は、図6、図７のように対応付けられていると仮定する。ここで、プロセスPxがドメインａからドメインbへ移動するケースを考える。ここで認証サーバーA、B、Cは証明書管理機構として機能し、各ドメインの認証機構をそれぞれAuthA、AuthB、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]とする。ここで、KAPx[PxEx]は外部形式PxExの全面的な暗号化ではなく暗号鍵KAPxを利用したメッセージ・ダイジェスト値を外部形式PxExに付加したものであっても良い。たとえば、外部形式PxExの文頭もしくは文末に暗号鍵KAPxを連結し、それに対してメッセージ・ダイジェスト関数を適用する。このようにして求まったメッセージ・ダイジェスト値と外部形式PxExをまとめて送付しても良い。
(7) プロセスPxはドメインbのAuth BにKAPx[PxEx]、KAB[KAPx]、KAB[O]を送り、プロセスＰｘの移動を申請する。
(8) Auth Bは、手順３にて決定した暗号鍵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から実行形式Pxを再生し、証明書正本O, 証明書副本S, プロセスPx間の対応を形成しプロセスPxの実行を許可する。
(11) この時点で、証明書正本O,証明書副本S の組を使った認証が、ドメインb上でも可能となる。ドメインbからドメインcへの移動の際には、上の認証サーバ Aとドメインaを認証サーバ Bとドメインbに、認証サーバ Bとドメインbを、認証サーバ Cとドメインcにそれぞれ置換えてこの手順を実行すれば良い。
【００５０】注意1、上記手順（第５実施形態）の第7項を契機として、Auth A上で管理されている証明書正本Oならびにその証明書副本Sの無効処置が必要となる。これをどの時点に実施するかは本方式の具体的な実装に依存する。逆に、無効処置を行わない場合、本手順は、プロセスPxを他ドメインへ複写する手順として利用可能である。この場合、相手先認証機構は、証明書を生成する際、複写であることを証明書に明示すべきである。
注意2、上記手順（第５実施形態）の第4項にて行われる共有鍵KAPxの生成は、プロセスPxとAuth A間にて行われるが、暗号鍵KAPxの安全性に配慮するならば、Auth Aの範囲を一層限定して、プロセスPxとAuth A内の認証サーバAとの間で行われるほうが、望ましい。ただし、実装上の選択として、効率性、負荷分散の観点から別の鍵管理機構などをAuth A内に設置して、そことプロセスPxとの間で暗号鍵KAPxを生成することも考えられる。また、上記（第５実施形態）第8項でAuth Bが暗号鍵KABを用いる場合も、暗号鍵KABが認証サーバ Bの外部に流出しないような配慮を行うべきである。
注意3、上記（第５実施形態）第5項から第7項の手順において、KAB[O]と、KAB[KAPx]をプロセスPx経由にてAuth Bに送っているが、その一方もしくは双方を、直接、Auth Bに送るなどの手順変形は可能である。基本的にそれらの変形は上記手順と同等のものと見なして良い。
注意4、応用上、プロセスPxの送信元実行環境と受け入れ側実行環境との相互認証が別途必要となる場合もある。ただし、これは、本手順で扱っている移動時のプロセスに対する認証とは別の手順である。
【００５１】[第５実施形態における重要事項]第５実施形態の手順には4つの重要事項がある。その１つは、プロセスPxの外部形式PxExが確かにプロセスPxによって作られたものであることを、移動先であるドメインｂが納得できる根拠を与える事にある。そのために、暗号鍵KAPxというプロセスPxとAuth Aしか知る事のできない秘密による痕跡をプロセスPxの外部形式PxExに付加する事によって、根拠をあたえる。暗号鍵KAPｘは外部形式PxExが確かにプロセスPxの結果であることを主張すると同時に、AuthAによる公認された結果でもあることも主張している。あるいは、プロセスPxとAuth Aによる連名の署名として機能すると考えても良い。その2つ目は、プロセスPxの所属を明示することである。これは、本発明の前半で述べた証明書正本副本によって行われる。この証明書正本副本は改ざん偽造が困難なので信頼できる。さらに、KAB[KAPx]によって、証明書正本副本とプロセスPxが確かに対応することが示されている。3つ目は、暗号鍵KAPxを生成する際の認証サーバ AとプロセスPxとの相互認証である。これは、証明書正副間の双方向のリンクによって行われる。（従来技術でも記した通り、プロセスPxにプロセス生成者本人の秘密鍵やパスワードを保持させる事は、危険であって意味を成さない。秘密以外の方式でプロセスPxの認証が可能な方式を開発する必要がある。） 双方向のリンクを持つデータ構造は、そのどちらか一方の所在が確定できれば、他方の所在も確定できる。しかも双方のデータが論理的に同じ物を保持する場合、データの変更は双方のデータの変更を必要とする。従って、そのようなデータのどちらか一方の安全を保障すれば、他方のデータを容易に復元し得る。このようなデータの片方づつを、独立したノードに保持させる事で、ノード間の相互認証が可能となる。ノード間での相互認証が確立すると、Diffie-Hellman方式などによって、ノード間で共通の秘密鍵を生成することが可能となる。４つ目は、認証の権限の移譲である。認証サーバ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）
【００５２】[第６実施形態：各種の攻撃への対処方法]第５の実施形態において、証明書正本副本には改ざん、偽造などさまざまな攻撃が起こり得る、以下ではそれらの攻撃に対する対処方法を概説する。
＜6.1 証明書の偽造に対抗する事＞このように証明書正本副本をリンクによって相互参照させることによって、偽造、改ざん、不正コピーへの対抗が可能となる。通常、不正行為はユーザー環境側で行われるが、ユーザー環境側にて証明書を偽造しても、証明書管理機構側にそのデータに対応する証明書の正本を作成する事が困難なため、偽造である事を容易に検出する事が可能である。(図８参照)＜6.2 証明書の不正コピーに対抗する事＞悪者は、正規の証明書の不正コピーを作り、あたかもそれを正規の証明書であるかのように使用するかもしれない。この場合、正規の証明書の正副には、厳密に一対一対応が形成されているが、不正コピーからは、証明書正に向かう参照があっても、証明書正から証明書副への参照は正規の証明書を指し、不正コピーは参照されないため、証明書管理機構からの問い合わせに矛盾が生じ不正が発覚してしまう。
＜6.3 証明書の改ざんに対抗する事＞悪者は、正規の証明書副を改ざんする場合もある。しかし、証明書正の内容を改ざんすることは困難なので、適当な周期で証明書正と証明書副との照合手続きを実行したり、証明書データを利用する際、事前に照合を行う事で、改ざんの有無を検出する事ができる。また、改ざんを発見したとき、改ざんされた証明書を改ざんされていない証明書に基づいて、正規の証明書へ復元する事も可能である。
＜6.4 ユーザー・プロセスの偽装に対抗する事＞あるユーザー・プロセス（オブジェクト）が所持する正規の証明書副の参照を手に入れ、別のプロセスがそのユーザー・プロセスを偽装するかもしれない。この問題は、セキュリティ・システムとユーザー・システムとの間のインターフェースを工夫し、ユーザー・プロセスと証明書との間も一対一対応を形成させることで解消する。この様子は図６にて示されている。このようなプロセス管理機構を作ると、偽装したプロセスからの要求に対して、その証明書の正本を保持する証明書管理機構からの逆方向の問い合わせに矛盾が生じ、偽装が発覚してしまう。
【００５３】＜第７実施形態：不正検出アルゴリズムへの応用＞不正コピー、偽造、偽装といった不正に対する検出方法は、いずれも証明書正本と証明書副本ならびにプロセス（あるいはオブジェクト）との相互参照が規定通りかどうかを確認するものである。これは以下のような手順にて行う。
プロセスPからの要求に対する手順（最も単純な場合）
第７実施形態では、プロセスをP，プロセスＰの参照をＰ’、証明書正本をO，証明書副本をS、証明書管理機構をAとする。プロセスPの参照から、証明書副本Sの参照、証明書正本Oの参照それぞれを取り出すことが可能である。ここで、プログラム言語的にその参照の同一性を判定できる場合には、証明書副本Ｓが証明書正本OとプロセスＰを参照し、かつ証明書正本Oが証明書副本ＳとプロセスＰを参照していることを確認できれば、認証されたと見なして良い。このような同一性の判定がプログラム的にはサポートされていない場合、次のような手順にて参照の相互関係を確認する。
(1)Ｐから、Ｓを経由してOに対して認証要求コールを送る。
(2)Oは要求コールの戻りとしてＸを戻す。
(3)Oは自分のもつプロセスの参照Ｐ'を使用して先ほど与えた乱数Ｘを戻す事を要求する。
(4)Ｐ'が乱数Ｘを戻した場合、Ｐ'とＰは等しいと見なす。ＰとＰ'とが異なる場合、Ｐ'は乱数Ｘの値を知らないはずである。
(5)ＰからＳを経由して再度Oに対する認証要求コールを送る。
(6)Oは要求コールの戻りとして乱数Ｙを戻す。このとき乱数Ｙは乱数Ｘと異なるものでなくてはならない。
(7)Oは自分のもつプロセスの参照Ｐ'を使用して先ほど与えた乱数Ｙを戻す事を要求する。
(8)Ｐ'が乱数Ｙを戻した場合、Ｐ'とＰは等しいと見なし、認証されたものとする。
ここでは、(1)から(4)にかけての手順と(5)から(8)にかけての手順のように、確認手順を２回行ったが、この回数は多ければ多いほど認証の確実性が向上する。最低２回は行う必要がある。
【００５４】＜第８実施形態：証明書副本からの要求に対する証明書正副同士の確認手順＞上とほぼ同様な手順にて、証明書副本の偽造、不正コピーの検出も可能である。以下にその手順の最初の4項を示す。これも2回以上繰り返す必要がある。ここでも、プロセスをP，プロセスＰの参照をＰ’、証明書正本をO，証明書副本をS、証明書管理機構をAとする。
(1)ＳからOに対して認証要求コールを送る。
(2)Oは要求コールの戻りとして乱数Ｘを戻す。
(3)Oは、自分の（証明書副本Ｓ自身の）もつ証明書副本Ｓの参照S'を使用して先ほど与えた乱数Ｘを戻す事を要求する。
(4)S'が乱数Ｘを戻した場合、S'とSは等しいと見なす。SとS'とが異なる場合、S'は乱数Ｘの値を知らないはずである。
上記のアルゴリズムによる認証には、認証対象となるプロセスやオブジェクトからの要求を受けた際のみに有効な認証手順である。さらに、複数の証明書管理機構の関与も考慮にはいれていない。そこで、複数の証明書管理機構の関与する場合で、認証側が認証対象オブジェクトに対して、主体的に実施する認証手順を以下に記述する。この際、少なくとも同一環境内におけるオブジェクトの参照は、リモート参照、ローカル参照の区別なく参照同士の一致不一致を検出する手続きが存在することを仮定する。
【００５５】＜第９実施形態：複数の証明書管理機構が関与する場合の応用例：認証側が認証対象のオブジェクトに対して主体的に実施する認証手順＞この認証手順として、次の３つの場合を検討する。手順1は証明書管理機構AがプロセスPの参照を得て、Pの認証を行う場合であり、手順2は、プロセスP1がプロセスP2の参照を得てP2の認証を行う場合であり、手順3はプロセスP1がプロセスP2からの要求を受け、P2を認証する場合である。
＜認証手順１：証明書管理機構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に認証の失敗を通知する。
【００５６】＜認証手順2：プロセスP1がプロセスP2の参照を得てP2の認証を行う場合＞(1) P1は自分の所属するドメインの証明書管理機構に対してP2を渡して上の手順１「証明書管理機構AがプロセスPの参照を得て、Pの認証を行う手順」を実施する。
【００５７】＜認証手順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に認証の成功、失敗のいずれかを通知する。
【００５８】注意1、上のO2とS2との照合は次のように行う。
(1)O2とS2との対応する項目の一致不一致を確認することで、内容面での改ざんの有無を調べる。
(2)改ざんされていないことが確認できた場合、O2から副本S2'への参照を取り出し、S2'とS2との一致を確認する。
注意2、上述の手順で、認証要求を発する側は、可能ならば、プロセスの参照、プロセスが保持している副本の参照、副本が保持している正本の参照の3組をあらかじめ取り出し、その3組の整合性を確認するようにし、副本に保持されている正本の参照の利用をなるべく避ける方向で実装するほうがよい。それは、実際には誤った正本の参照が書き込まれているにもかかわらず、処理直前に一時的に正しい正本の参照を与えることで、認証を通過させ、認証後にまた誤った正本の参照を再設定することにより、プロセスに誤った正本を信用させる不正が可能なためである。
【００５９】＜第９実施形態：不正検出アルゴリズムの限界とその対策＞第８実施形態のアルゴリズムの限界は、プロセスＰとプロセスの参照Ｐ'とが異なるプロセスでありながら、裏で繋がっている場合、バケツリレー式の偽装が可能になってしまうことである。裏でつながっている場合とは、公認されたプロセスＰ'自体が不正なプロセスＰと共謀した場合である。しかし、この場合は、責任は公認されたプロセスＰ’自身にある。プロセスＰ'自身の秘密を教えることに危機を招いた責任があるからである。この場合は、公認プロセスＰ’が不正プロセスＰから乱数Ｘ、Ｙの値を教えてもらい、公認プロセスＰ'自身が不正プロセスＰのふりをすることにもなる。このような、プロセスの偽装を見破るには、実行環境レベルのプロセス管理情報を利用するとよい。証明書正副にプロセスidを参照以外に登録し、プロセスの参照Pをプロセス管理情報に渡して、そのプロセスidを受け取り、証明書内のidと一致／不一致を確認すればよい。これらは、OSや実行環境に依存する実装上の詳細事項である。
【００６０】＜第１０実施形態：オブジェクト間の参照方式の変形＞参照方式には、基礎となるシステムに応じて、幾つかの変形が発生する。証明書同士や証明書とプロセスを結合する参照は、分散オブジェクト・システム上では、オブジェクトのローカルな参照もしくは、リモート・オブジェクトの参照となる。ローカルな参照は参照する側とされる側のオブジェクトがともに同一環境内に位置する場合に使用される。２つのオブジェクトが異なる環境に置かれている場合、その参照はリモート・オブジェクトの参照になる。ローカルな参照が使われる場合、参照されるオブジェクトの（ローカルな）メソッドを呼出す事ができ、リモートの参照が使用される場合には、参照されるオブジェクトに対して、リモート・メソッド呼出し（Remote Method Invocation）が可能である。第７実施形態で述べた「不正検出アルゴリズム」は基本的にはこのようなオブジェクト同士の参照を利用した、ローカルまたはリモートのメソッド呼出しによって実施されることを想定している。オブジェクト指向技術を使用していないシステム上でも「不正検出アルゴリズム」の各手順は次のように実施することが可能である。証明書やプロセス管理データを定められたデータ構造をもつデータ・ブロックとして実装する。これらのデータ・ブロックを互いに識別するために、各ブロックごとに一意の識別子をあたえる。この識別子はユニークな数値や文字列など他と明確に区別可能な任意の型のデータであってよい。サーバー・プログラムなどこれらのデータ・ブロックが置かれている場を環境と呼ぶ事にすると、これらの識別子は、同一環境内では、一意性を保証する必要がある。これらの識別子に加えて、証明書やプロセス管理用のデータが所属する環境と通信するための通信制御用の識別情報も識別子と合わせてデータ・ブロックに保持させる。通信制御用の識別情報には、例えばホスト名、ipアドレス、ソケット番号、ポート番号など、基礎となる通信システムに応じてさまざまなものがある。この（識別子：通信制御用識別情報）の組がオブジェクト間の参照に対応する。
【００６１】このとき、リモート・メソッド呼出しに対応する手続きの呼出しは次の通りである。呼出しの往路は、通信制御用識別情報によって定められる相手側環境に対して、処理要求内容を示すコマンド・コードと操作対象となるデータ・ブロックの識別子、そして操作に必要となる任意のパラメータ情報をメッセージとして送信することである。呼出しの処理本体の実行は、上記のメッセージを受け取った環境側が、識別子で指定される操作対象に、コマンド・コードとパラメータに従った処理を実施する事である。この処理の実施で得られる情報を応答メッセージとして環境から送信元へもどすことが、呼出しの復路に対応する。システムによっては、この一連の操作をRPC（Remote Procedure Call：遠隔手続き呼出し）によって、通常の手続き呼出しのような外観にて実施する事が可能である。このように、上記の手順はオブジェクト指向のシステムでなくとも、通信回線その他によって互いに交信可能な系同士であれば実施可能である。
【００６２】＜第１１実施形態：証明書とユーザー・オブジェクトとの一体化＞セキュリティ機構がOSや実行環境に標準的に装備されている環境などでは、ユーザー・オブジェクトやプロセスに証明書を直接埋め込むことも考えられる。(図１１参照)（オブジェクト指向言語を使用する場合、ユーザー・オブジェクトのクラスを証明書オブジェクトのサブ・クラス等として実現することになる。）この場合でも証明書とユーザー・オブジェクトは一対一に対応するので、これは図6のような参照によってユーザー・オブジェクトとの対応付けを行う仕組みの変形であると考えられる。この長所は、参照等を改変される心配が無くなるため、外部からの攻撃に強くなり、また認証時の処理も証明書の真正性の確認だけで済む点にある。また、オペレーティング・システムの核などに本証明書方式を組み込む場合、プロセス管理ブロックとかタスク管理ブロックなどとよばれる、実行制御の対象となるプロセスを、管理するデータ構造の一部として、本証明書に使用することも可能である。この場合は、ちょうど図１１のケースと図6のケースの中間にあたる変形であると考えられる。
【００６３】＜第１２実施形態：証明書管理機構自体の偽装への対抗＞これまでは、証明書の正本と副本のいずれかは信頼できるということを暗黙の仮定としてきた。しかし、副本が改ざんされ、副本が参照している正本も本来の証明書管理機構とは異なるニセの証明書管理機構上に作られている場合も考慮する必要がある。この場合、本来の副本が改ざんされたのか、それとも全くの偽造なのかの区別が必要である。この問題に対処する際、副本が正しい正本を参照していると仮定することはできない。ただし、最低限の前提として、本来の証明書管理機構上には、正規の正本が存在していることは前提とする。（逆に、ユーザー側のシステム上に正規の副本があると仮定してもほぼ同じ手法で対策を立てる事ができる。）さらに、セキュリティ・ドメイン上に認証者（Authenticator）が存在する事を前提とする。認証者はセキュリティ・ドメイン上における正規の証明書管理機構の所在を管理する。また、プロセスが所属するドメインの認証者への参照は、プロセスが実行されているユーザー環境に置かれているセキュリティ管理機構やオペレーティング・システム呼出し等のあらかじめ定められたインターフェースを介して取得されるものとする。このことによって、証明書の真正性に依存する事無く、プロセスの所属するドメインに対応する認証者への要求を発する事が可能である。ユーザー環境が正規のドメインに所属している場合、正規の認証者が必ず参照される。正規の認証者は正規の証明書管理機構の所在が分かる。従って、証明書の正本の参照に対して、当該参照に対応する証明書が実在するかどうかを、証明書管理機構自体が内部で管理している証明書表などに基づいて、確認する事が可能である。証明書正本の真正性をこのように確定できるので、それを使用して証明書副の真正性の確定が可能である。
【００６４】一方、ユーザー環境が正規のドメインに所属していない場合、正規の認証者が参照されるという保証はない。正規の認証者の参照が得られる場合、上記の手順で証明書副の真正性の確認が得られる。正規の認証者の参照が得られない場合、その認証者は、ニセの証明書管理機構を使用し、嘘の認証を行うかもしれない。認証者がニセの証明書管理機構を与えたとしても、認証の確認が外部にある正規のドメインの要求で行われている場合、そのドメインの証明書管理機構と認証者が与えた証明書管理機構との相互認証を行う事で、ニセの証明書管理機構を見破る事が可能である。認証の確認が外部のドメインからではない場合、認証は行われるが、そのドメインの外には認証結果の効力が及ばない。従って、外部にある正規のドメインには影響を与えない。
【００６５】上の記述を明確化することで、以下に述べる証明書の偽装ならびに改ざんに対抗する手順が得られる。この際の少なくとも、同一環境内におけるオブジェクトの参照に関してリモート参照、ローカル参照の区別なく参照同士の一致不一致を検出する手続きが存在することを前提とする。
【００６６】＜偽装ならびに改ざんへの対抗手順＞ここでは、証明書副本をS、正本をO、認証者をAu、証明書管理機構をAとする。
(ステップ１：正規の正本Oの参照を獲得する。)(1) 副本Sは認証者Auに対して証明書管理機構Ａの問い合わせを行う。
(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は自分が偽造されていると判断する。
（ステップ２:正本と副本の照合ならびに修正を行う。)(1) Sは、自分の持つ各項目と対応するOの項目とを比較する。ある項目が一致しない場合その項目をOの項目で置きかえる。
【００６７】＜第１３実施形態：証明書管理機構A、B間の協議手順の詳細＞前述した第５実施形態(3)の「AとＢとの協議」によって暗号鍵KABを生成する手順については、A,B間の認証方式に応じてさまざまな方式が考えられる。以下にいくつかの例を提示する。
例１．秘密鍵KCを証明書管理機構A,B間で共有し、暗号鍵KABを証明書管理機構B側で生成する方式。
(1)AからBへKABの生成要求を発する。
(2)BからAに乱数R1をチャレンジとして送る。
(3)Aは、R1の末尾に０を連結したものを秘密鍵KCで暗号化したKC[R1|0]と、さらにBに対するチャレンジとして乱数R2をBに送る。
(4)BはR2の末尾に１を連結したものを秘密鍵KCで暗号化したKC[R2|1]をAに送る。さらに、Bは、適当な乱数を発生させてKABとし、それをKCで暗号化したKC[KAB]と、KABを利用した通信セッションを識別するためのセッションidとを、Aに送る。
(5)AからBに、KABの受理の確認を行う。たとえば、Aは、セッションidと日付を連結させたメッセージをKABで暗号化したKAB[セッションid｜日付]をBに送ってもよい。
【００６８】例２．秘密鍵KCをA,B間で共有し、KAB生成にDiffie-Hellman鍵交換方式を使用する方式。ここでｐを素数、ｇをある整定数。modを法演算とする。このｐとｇとは事前に合意してあってもよいし、一方から他方へ通知してもよい。このとき関数P(x)をP(x)=ｇx mod pによって定める。
(1)AからBへ暗号鍵KABの生成要求を発する。
(2)BからAに乱数R1をチャレンジとして送る。
(3)Aは、R1の末尾に０を連結したものをKCで暗号化したKC[R1|0]と、Bに対するチャレンジとしての乱数R2と、秘密の数RAを発生させて法関数とした関数P(RA)とを、Bに送る。
(4)Bは、R2の末尾に１を連結したものを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に送ってもよい。
【００６９】例３． 秘密鍵KCをA,B間で共有し、KCを暗号鍵KABとする方式。この方式は認証者にKCを知らせる等KCのセキュリティに問題があるが、効率的である。
(1)AからBへセッションid生成要求を発する。
(2)BからAに乱数R1をチャレンジとして送る。
(3)Aは、R1の末尾に０を連結したものをKCで暗号化したKC[R1|0]と、Bに対するチャレンジとして乱数R2とを、Bに送る。
(4)Bは、R2の末尾に１を連結したものをKCで暗号化したKC[R2|1]と、通信セッションを識別するためのセッションidとを、Aに送る。
(5)AからBに、セッションidの受理の確認を行う。この場合、単にACK（？）を送るだけでもよい。
【００７０】例４． A,B間は公開鍵暗号方式による署名によって認証を行う方式。この場合、KABはDiffie-Hellman鍵交換方式を利用して生成するとよい。ここでｐを素数、ｇをある整定数。modを法演算とする。このｐとｇとは事前に合意してあってもよいし、一方から他方へ通知してもよい。このとき関数P(x)をP(x)=ｇx 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 mod p が暗号鍵KABとなる。さらに、乱数R1を発生させKAB[R1]をチャレンジとしてBからAに送る。またセッションidを生成しそれもBからAに送る。
(4)AはR1の末尾に１を連結したものをKABで暗号化したKAB[R1|1]をBに送る。
【００７１】例５．A,B間は公開鍵暗号方式による暗号化によって認証を行う方式。この場合、暗号鍵KABはDiffie-Hellman鍵交換方式を利用して生成するとよい。ここでｐを素数、ｇをある整定数。modを法演算とする。このｐとｇとは事前に合意してあってもよいし、一方から他方へ通知してもよい。このとき関数P(x)をP(x)=ｇx 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の末尾に１を連結したものをKABで暗号化したKAB[R1|1]をBに送る。
【００７２】＜第１４実施形態：証明書を応用したプロセス移動方式の変形＞第１３実施形態の例３ではA、B間での共通鍵KABとしてAとBとが相互認証のために元々合意していた鍵KCを利用していた。この例では、セッションidを確定する都合上A,B間では協議の手順が実行されていたが、共通鍵KABとして無条件にKCを使用し、セッションidの設定も省略してしまうとA,B間の協議のステップ自体を省略する事もできる。この方式は、第１３実施形態の例３で述べた方式の変形であると考えられるが、きわめて効率的である反面、KCが破られる危険があること、以前に処理されたKAPx[PxEx]、KC[O]、KC[KAPx]からなる転送メッセージをそっくり複写したものを認証者に与えると、認証者が受理してしまう恐れがあることなどの欠点をもつ。そのため、KCを適当な周期で更新するとか、Pxからのメッセージにはタイムスタンプを連結して暗号化するなどの処置が必要である。またこの手順は、Kerberos認証システムで使用されている認証手順にも類似しているが、Kerberosシステムは人物など動かない対象の認証システムであるのに対し、本方式はプロセスのような処理にともなって内容が変化するデータに対する認証ならびに移動の手順であること、さらに証明書もこの移動にともなって認証機関の間を移動していく事など、Kerberosシステムとは目的や手法が大きく異なる。
【００７３】この変形方式の手順を以下に示す。ここで、プロセスPxがドメインａからドメインbへ移動するケースを考える。ここでサーバーA、B、Cは証明書管理機構として機能し、各ドメインの認証機構をそれぞれAuthA、AuthB、AuthCとする。サーバーAとサーバーBとの間にはあらかじめ暗号鍵KCについての合意がある。
(1)プロセスPxは認証機構AuthAにドメインａからドメインbへ移動したいという要求を送る。
(2)サーバーAとPxとの相互認証を行う。この際、ドメインaの認証者によるAの認証と、第７実施形態の「不正検出アルゴリズム」によるPxの認証が行われる。
(3)PxとAuthAは一時的な暗号鍵KAPxを生成する。KAPxの合意は、たとえば、Diffie-Hellmanの鍵交換法を使用して行われる。
(4)AuthAは証明書正本OをKCで暗号化しKC[O]を作る。また、KAPxもKCで暗号化し、KC[KAPx]を作る。そしてそれを、Pxに送る。（OとKAPxとを連結してKCで暗号化し、KC[O|KAPx]を作っても良い。）
(5)プロセスPxは自分自身の外部形式PxExを作り、それをKAPxで暗号化しKAPx[PxEx]とする。（ここで、KAPx[PxEx]はPxExの全面的な暗号化ではなくKAPxを利用したメッセージ・ダイジェスト値をPxExに付加したものであっても良い。たとえば、PxExの文頭もしくは文末にKAPxを連結し、それに対してメッセージ・ダイジェスト関数を適用する。このようにして求まったメッセージ・ダイジェスト値とPxExをまとめて送付しても良い。）
(6)プロセスPxはドメインbの認証機構AuthBに、KAPx[PxEx]、 KC[KAPx]、 KC[O]を送り、プロセスの移動を申請する。
(7)AuthBはKCをあらかじめ知っているので、KC[O]から証明書Oを再生し、KC[KAPx]からKAPxを再生することができる。そして、KAPxを使用して、KAPx[PxEx]からPxExを再生することができる。
(8)KAPxはこの転送サイクルにおいてPxとAuthAしか知り得ない秘密であり、KC[KAPx]にKAPxがあることは、AuthAしか知り得ない。従って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にそれぞれ置換えてこの手順を実行すれば良い。
【００７４】注意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：応用上、プロセスの送信元実行環境と受け入れ側実行環境との相互認証が別途必要となる場合もある。ただし、これは、移動時のプロセスに対する認証とは別の手順である。
【００７５】＜第１５実施形態：セキュリティ・ドメイン内でのプロセス移動に関する方式の変形＞第１２実施形態、第１４実施形態での方式は異なるセキュリティドメインa、b間をプロセスが移動する際の、証明書を利用したプロセスの認証ならびに移動、そして証明書も証明書管理機構AからBに移動させる場合の方式であった。プロセスはこのような異なるセキュリティ・ドメインへの移動に限らず同じセキュリティ・ドメイン内での異なる実行環境間を移動する場合もあり得る。この場合、方式はより単純化した形へ変形される。もっとも単純な場合は、移動のセッションを識別するセッションidだけを割り付け、プロセスの外部形式を生成したのち、その外部形式にセッションidを付加して移動先の環境に送付する方式である。その方式よりも多少セキュリティに配慮した変形を以下に示す。この方式は、同一セキュリティ・ドメイン内の移動の方式としても捕らえる事ができるのみならず、ローカル・エリア・ネットワークなどに単一の証明書管理機構を設置した小規模なネットワーク環境内だけで移動プロセスを使用する場合の標準的な移動手順としても捕らえる事ができる。ここでは、プロセスPxがドメインａ内の環境E1からE2へ移動するケースを考える。
【００７６】ここでサーバー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[PxEx]はPxExの全面的な暗号化ではなくKAPxを利用したメッセージ・ダイジェスト値をPxExに付加したものであっても良い。たとえば、PxExの文頭もしくは文末にKAPxを連結し、それに対してメッセージ・ダイジェスト関数を適用する。このようにして求まったメッセージ・ダイジェスト値とPxExをまとめて送付しても良い。）
(5)プロセスPxはドメインaの認証者AuthAにKAPx[PxEx]、を送り、プロセスのE2への移動を申請する。
(6)AuthAは、Pxと共有しているKAPxを使用して、KAPx[PxEx]からPxExを再生することができる。KAPxはこの転送サイクルにおいてPxとAuthAしか知り得ない秘密である。従ってPxExが正常に解読できた事を持ってPxがAuthAによって認証されたプロセスであることが確認できる。
(7)AuthAは、サーバーA内に保管されていたPxの証明書Oに対応する副本Sを生成する。PxExから実行形式Pxを再生し、O, S, Px間の対応を形成しPxの実行を許可する。
【００７７】注意1：上記手順の第3項にて行われる共有鍵KAPxの生成は、Px、AuthA間にて行われるが、KAPxの安全性に配慮するならば、AuthAの範囲を一層限定して、PxとAuthA内のサーバーAとの間で行われるほうが、望ましい。ただし、実装上の選択として、効率性、負荷分散の観点から別の鍵管理機構などをAuthA内に設置して、そことPxとの間でKAPxを生成することも考えられる。
注意2：上記手順の第7項にて、転送元にある証明書副本Sの無効処置が必要となる。これをどの時点に実施するかは本方式の具体的な実装に依存する。逆に、無効処置を行わない場合、本手順は、プロセスを実行環境へ複写する手順として利用可能である。この場合、相手先認証機構は、証明書を生成する際、複写としての証明書正本を新たに割り付ける必要がある。
注意3：応用上、実行環境E1、E2の相互認証が別途必要となる場合もある。ただし、これは、移動時のプロセスに対する認証とは別の手順である。
【００７８】＜第１６実施形態：証明書付きのプロセスの保存方式＞第１４実施形態の[証明書を応用したプロセス移動方式] を変形することによって、証明書付きのプロセスを保存する方式が得られる。通信回線等で結ばれた処理系内では障害等によってデータが失われる場合がある。従ってデータの破損や喪失への対策としてこのようなプロセスの保存方式が要求される。この手順は、プロセス移動手順と併用する事が可能である。以下は第１２実施形態の手順に基づく保存法式であるが、第１４実施形態の移動方式の変形、第１５実施形態の移動方式の変形に対しても同様にして対応する保存方式が得られる。
【００７９】この手順の概略は次の通りである。ここで、プロセスPxがドメインａからドメインbへ移動する場合、ドメインbにてプロセスを保存するケースを考える。ここでサーバーA、B、Cは証明書管理機構として機能し、各ドメインの認証機構をそれぞれAuthA、AuthB、AuthCとする。
(1)PxはAuthAにドメインbへ移動したいという要求を送る。
(2)サーバーAとPxとの相互認証を行う。この際、ドメインaの認証者によるAの認証と、すでに述べた「不正検出アルゴリズム」によるPxの認証が行われる。
(3)サーバーAはサーバーBと協議を行い暗号鍵KABを用意する。この手順の詳細は第１３実施形態の説明を援用する。
(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[PxEx]はPxExの全面的な暗号化ではなくKAPxを利用したメッセージ・ダイジェスト値をPxExに付加したものであっても良い。たとえば、PxExの文頭もしくは文末にKAPxを連結し、それに対してメッセージ・ダイジェスト関数を適用する。このようにして求まったメッセージ・ダイジェスト値とPxExをまとめて送付しても良い。）
(7)プロセスPxはドメインbの認証機構AuthBに、KAPx[PxEx]、 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があることは、AuthAしか知り得ない。従ってPxExが正常に解読できた事を持ってPxがAuthAによって認証されたプロセスであることが確認できる。
(10) AuthBは、この事実を持ってサーバーB内に証明書正本Oを割り付ける。その際、KAPxとプロセスのバックアップ名を正本に対応付けてサーバーB内に保存する。そして、プロセスのバックアップ名とKAPx[PxEx]を対応付けて不揮発性記憶媒体に書き込む。この際、宛先実行環境の識別などプロセスの再開に必要となる情報も合わせて記録する。これらの情報は、証明書正本Oに保持させる事も可能であるが、これらは、本手順の実装に依存する。
【００８０】注意1：上記手順(4)にて行われる共有鍵KAPxの生成は、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項以降も互いに矛盾するものではない。従って、第５実施形態の方式を使用してプロセスを移動させる際、プロセスの保存を並行して行う事が可能である。上記の手順によって保存されたプロセスを再生させる際に、2通りの場合が考えられる。一方は、そのプロセスの証明書副本がすでに存在し、その証明書副本に対応するプロセスを復旧させる場合である。他方は証明書の副本がまだ割り付けられていないか、プロセスが副本も含めて失われてしまった場合である。
【００８１】[プロセスの復旧：副本が存在する場合](1)認証機構は、副本の真正性を確認する。
(2)真正性が確かめられたならば、正本に対応付けられたプロセスのバックアップ名と暗号鍵KAPxを取り出す。
(3)バックアップ名に対応したKAPx[PxEx]を読み込む。
(4)KAPx[PxEx]をKAPxで解読し、PxExを取り出し。それからPxを割り付ける。
【００８２】[プロセスの復旧：副本が存在しない場合]この場合、そもそもどのプロセスを復旧させるのかを決定しなくてはならない。そのためには、1)証明書管理機構内の正本すべてをしらみつぶしに調べ、すべての副本についてその存在の問い合わせを行う、2)常時適当な周期で、少しずつ、証明書管理機構内の正本に対応する副本の問い合わせをしておく、などが必要である。いずれかの方法で副本の消滅が確認された場合、証明書管理機構側が認証者に副本が存在していない証明書正本の情報を伝える。以後次の手順によって復旧を行う。
(1)認証機構は、正本に対応付けられたプロセスのバックアップ名と暗号鍵KAPxを取り出す。
(2)バックアップ名に対応したKAPx[PxEx]を読み込む。
(3)KAPx[PxEx]をKAPxで解読し、PxExを取り出す。証明書正本に基づき証明書副本Sと、プロセスPxを割り付ける。
【００８３】本方式は移動可能プロセス移動時のバックアップと復旧の方式であるが、移動時に認証機構に渡す要求に適当なオプションや異なる要求を与える事によって、プロセスの保存だけを行って、プロセスの実行を延期させることも、ほぼ同様な手順で可能である。この場合、証明書管理機構に割り付ける証明書正本に再開時刻等を含めた実行延期を示す情報を対応させる等の処置を行う。
【００８４】＜第１７実施形態：プロセスの違法コピーへの対処方法＞第５実施形態、第１４実施形態、第１５実施形態に示したプロセス移動方法、および第１６実施形態節にて示したプロセスの保存方法において、認証機構とプロセスとの間で共有暗号鍵KAPxを定めた直後に、プロセスの複写を行うと、複写されたプロセスと共に共有鍵KAPxが奪われてしまう恐れがある。この第１７実施形態では、第５実施形態での記号を流用する。本手順では、証明書正本のデータが、正規の証明書副本に渡る事が保証されている。しかし、何らかの方法で悪者によって、暗号化された正本KAB[O]、暗号化された共有鍵KAB[KAPx]などの情報を傍受されると、違法にコピーされたプロセスを通じて、贋のプロセスPyの外部形式PyExを共有鍵KAPxによって暗号化したKAPx[PyEx]に盗み出したKAB[O]、KAB[KAPx]などの情報を添付して、相手先の認証機構に送付する事によって、贋のプロセスが証明書正本を奪う恐れがある。
【００８５】このような違法コピーに対する対処には次の2通りの方法が考えられる。
方法1) 相手先認証機構で、KAB[O]などの暗号化された正本、KAB[KAPx]などの暗号化された共有鍵、KAPx[PxEx]など暗号化されたプロセスの受信時に送信元を「不正検出アルゴリズム」を使用して認証する。
方法2）正規のプロセスの外部形式に関するメッセージ・ダイジェスト関数値を自ドメインの認証機構にあらかじめ教えておき、暗号化された正本に添付してもらう。これらの、対処方法を手順に組み込む際には、組み込みに伴う処理上のオーバヘッドと、プロセス・コピーの現実的な可能性、および、認証機構から送られる、暗号化された正本や、暗号化された共有鍵の傍受の現実的な可能性を勘案する必要がある。
【００８６】以下では、第５実施形態の手順に上記の方法2）の手順を加えたものを示す事にする。なお、第５実施形態の手順の後に記されている注記は本手順でも内容上対応する項目に適合する。また、第1４，１５，１６実施形態の手順でも、ほぼ同様な変更を加える事ができる。第５実施形態と同様に、Pxがドメインａからドメインbへ移動するケースを考える。ここでサーバーA、B、Cは証明書管理機構として機能し、各ドメインの認証機構をそれぞれAuthA、AuthB、AuthCとする。
【００８７】手順：上記方法2)を適用した場合。ここでは、SHA(x)やMD5(x)などのメッセージ・ダイジェスト関数をHASH(x)とする。
(1) PxはAuthAにドメインbへ移動したいという要求を送る。Pxはこの時点で、Pxの外部形式PxExとPxExのメッセージ・ダイジェスト関数値HASH(PxEx)を計算しこれをHashPxとする。
(2) サーバーAとPxは相互認証を行う。この際、ドメインaの認証者によるAの認証と、すでに述べた「不正検出アルゴリズム」によるPxの認証が行われる。
(3) PxはAuthAにHashPxを送る。（Pxは、AuthAの要求の答えとしてHashPxを返しても良い。）
(4) サーバーAはサーバーBと協議を行い暗号鍵KABを用意する。この手順については、第1６実施形態の説明を援用する。
(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を連結し、それに対してメッセージ・ダイジェスト関数を適用する。このようにして求まったメッセージ・ダイジェスト値とPxExをまとめて送付しても良い。）
(8) プロセスPxはドメインbの認証機構AuthBにKAPx[PxEx]、 KAB[KAPx]、 KAB[O]、KAB[HashPx]を送り、プロセスの移動を申請する。
(9) AuthBは、手順4にて決定したKABを用いて、KAB[O]から証明書Oを再生し、KAB[KAPx]からKAPxを再生することができ、さらに、HashPxの再生ができる。そして、KAPxを使用して、KAPx[PxEx]からPxExを再生することができる。
(10) AuthBはPxExのメッセージ・ダイジェスト関数値HASH(PxEx)を計算し、これが、HashPxと一致する事を確認する。もしも、一致しない場合には手順をこの時点にて打ち切る。
(11) KAPxはこの転送サイクルにおいて、原則として、Pxと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のコピーをとるなどしても、PxEx以外のプロセスの外部形式を送る事は難しい。また、この手順は、PxExの転送中におけるデータの欠落の有無や、改ざんの有無の確認にもなる。この性質ゆえに、方法2)の方が応用上安全である。なぜなら、共有鍵KAPxがプロセスのコピーによって流出することを想定すると、Pxが送信しようとするPxExの改ざんにも対処する必要がある。方法2)は、PxExの改ざんを検出する事が可能である。改ざんが発見された場合、Pxは相手先からのエラー・コードなどを受け、もう一度手順の先頭からやり直す事ができる。
【００８８】＜第１８実施形態：証明書による認証方法の変形＞これまでのところでは、プロセス（またはオブジェクト）Pxと証明書管理機構Aとの間に２重の証明書を用意し、その参照が一意的に定まることを利用してプロセスＰｘと証明書管理機構Ａとの相互認証を与える方法について記してきた。この方法の変形例として、最初にプロセスＰｘと証明書管理機構Ａとの間の認証を2重の証明書によって行い、認証が行われた時点でプロセスＰｘと証明書管理機構Ａとの間で共通の秘密を設定し（例えばDiffie-Hellmanの鍵交換方式などを使用する）、以後の認証をその共通の秘密によって行うことも考えられる。
【００８９】この方法は、プロセスＰｘを共通の秘密とともに複写して生成されたプロセスＰｙを容易に作る事ができ、プロセスＰｘと異なるプロセスPyがその秘密を保持することが可能なため、認証効果は低い。しかし、プロセスＰｘと証明書管理機構Ａとで適当な周期で共通の秘密を更新する事によってある程度、複写の問題に対抗する事も可能である。この方式の良さは、プロセスＰｘと証明書管理機構Ａとの間の認証に従来から行われている秘密情報に基づく認証方法が適用可能な点である。また、さらなる変形例として、証明書正本と証明書副本との間に共通の秘密を設定し、証明書正副間の不正検出を、この秘密を知っているかどうかによって行う方法も考えられる。この共通の秘密の設定に際して、Diffie-Hellman法を使用する場合、証明書間の相互認証が必要なので、最低一回は、参照を利用した、前述の不正検出アルゴリズムを使用して、相手の確認を行うことが必要である。
【００９０】この場合、図１３に示すように、証明書内に共通の秘密を置かずに、証明書を管理するオブジェクトもしくはデータ構造内に、配列やハッシュ・テーブルを置き、その配列またはハッシュテーブルにて証明書と秘密との対応付けを行い、配列やハッシュ・テーブルに対する外部からのアクセスに制限を設ける事で秘密の安全性を、ある程度、確保することが可能である。この方法では、そのように管理される秘密に対して、証明書からどのようにアクセスを許すのかが、問題となる。オブジェクト指向言語の中には、変数の参照制限機能や、一度定義されたメソッドの上書きの禁止を行う機能が提供されているものがある。そのような、プログラミング言語を使用すると、秘密を管理する配列やハッシュ・テーブルに対する外部からの参照を制限し、秘密へのアクセス・メソッドを上書き禁止にすることで安全なアクセスが可能になる。また、上記の２つの方法を折衷し、プロセスと認証サーバーとの間に設定される共通の秘密を、プロセス自体に保持させずに、証明書管理オブジェクト内のハッシュ・テーブル等に証明書と対応させて保持させることも考えられる。そこで、このような共通の秘密の生成例をDiffie-Hellman鍵交換方式によって行う場合を以下に説明する。
【００９１】ここでｐを素数、ｇをある整定数。modを法演算とする。このｐとｇとは事前に合意してあってもよいし、一方から他方へ通知してもよい。このとき関数P(x)をP(x)=ｇx mod p によって定める。すると、次のような手順で行うと、共通鍵をプロセスも含め、外部に一切漏らさずに生成することができる。ここで、プロセスをPx、認証サーバーを証明書管理機構Ａとする。また、証明書管理オブジェクトをCOとする。COはプロセスＰｘと証明書管理機構Ａとのプロキシーとして機能し、上記の定数g、pを知っていると仮定する。以下では記述を簡単にするために、プロセスと証明書との対応チェックを省略しているが、実装時にはそのようなチェックを行うべきである。
【００９２】(1)プロセスＰｘから証明書管理機構Ａへ共通鍵生成要求をCO経由で発する。このとき秘密の数Rxを生成し、その要求のパラメータとして付加する。
(2)制御を受け取ったCOはRxの値をプロセスＰｘに対応する証明書副本の秘密の値として管理し、証明書管理機構Ａに対するパラメータをRxからP(Rx)に置換えて、メソッド呼出しを証明書管理機構Ａに中継する。
(3)証明書管理機構Ａは、秘密の数Raを生成する。そしてP(Ra)を計算し、CO経由のプロセスＰｘの戻り値としてP(Ra)を戻す。このとき、P(Rx・Ra)=gRx・Ra mod p = P(Rx)Ra mod p = P(Ra)Rx mod p が共通の秘密となる。
(4)証明書管理機構Ａからの戻り値P(Ra)を受け取ったCOは、その値と、管理しているRxを利用して、P(Rx・Ra)= P(Ra)Rx mod pを計算し、P(Rx・Ra)をプロセスＰｘに対応する証明書副本の秘密の値として管理する。プロセスＰｘには単に、共通秘密生成の成功通知だけを戻す。
【００９３】この方法を変数やメソッドのアクセス制限機能のあるオブジェクト指向言語などで実装すれば、プロセスの違法コピー等による秘密の漏洩を防止する効果があり、さらに、プロセス転送手順にて必要とされる共通秘密鍵の一時的な保存方式としても効果的である。ただし、このような工夫で保証されている安全性は、証明書COを経由してアクセスされているという事実のみであることに注意するべきである。贋のプロセスがCOの参照を利用して、隠された秘密を利用する恐れは、依然残っている。また、これは実装上の工夫というべきであるが、証明書管理オブジェクトの安全が保障されている場合、図１３の秘密情報の位置に、証明書副本に対しては、証明書正本への参照を置き、正本に対しては、副本への参照を置くようにし、証明書自体には互いの参照を置かないようにすることも考えられる。このように、参照の管理を証明書自体と分離する事により、証明書が違法にコピーされた場合を考慮して行われる、証明書間の煩雑な参照確認手順を簡略化することが可能となる。このような管理方式を使用すると、証明書を違法にコピーしても、対応するもう片方の証明書への参照が得られないので、証明書を利用した認証手順の早期の段階で不正を見破る事ができる。ただし、この方法も、証明書管理オブジェクトが安全であることが、前提である。
【００９４】逆に、証明書間の参照や秘密情報と証明書自体を分離するこれらの方法は、証明書管理オブジェクトが充分安全で、しかも定期的なバックアップや信頼できるホスト内にレプリカを保持するなどのシステム・クラッシュ時の情報復旧対策が取られている場合、本証明書方式を利用したシステムのフォールト・トーレラント性を高める手段ともなり得る。
【００９５】＜証明書方式の応用＞このような証明書の最も直接的な応用は、CORBA分散オブジェクト・システムの部分系であるCORBAセキュリティ・サービスでサポートされているクレデンシャル（Credential:信任状）として使用するか、もしくはその補助データとして使用する事である。CORBAセキュリティ・サービスにおけるクレデンシャルは、認証されたオブジェクトに対応付けられオブジェクトの発するリモート・メソッド呼出し時の呼出し元プリンシパルの照会に使用されたり、オブジェクトに対して設定されるセキュリティ属性の保持、ならびにそのセキュリティ属性に従って他のオブジェクトに対するアクセス許可の決定などに使用される。
【００９６】しかし、CORBAセキュリティ・サービスでは、オブジェクトのカレント・スレッドに対しては、クレデンシャルのコピーの作成や現在参照すべきクレデンシャルとして別のクレデンシャルの設定が可能であるなど、相当自由なオペレーションが許されている。そのことが、かえってクレデンシャル自体の認証能力を結果的には弱めてしまい、厳密な認証を必要とする場合、オブジェクトを生成したドメインの認証サーバーなどへ照会を行わなければならない。このことが、現行のCORBAセキュリティ・サービスでの枠組みにおける、移動エージェントなどの、セキュリティ・ドメインを超えて移動可能なオブジェクトや移動可能なプロセスの実現に困難をもたらしている。
【００９７】例えば、次のような記述が成されている。「エージェントの認証はエージェント・システムの認証とは異なる。エージェントは移動の際、（プライベート・キーなどの）暗号化キーを持ち運ぶことはできない。エージェントの認証は（秘密キーなどを持つ代わりに）認証者を立てることによって行う。認証者とはエージェントの真正性を見極めるアルゴリズムである。発進元のエージェントシステムやエージェントを発進させたクライアントの真正性に関する情報、エージェントやエージェント・システムのオーソリティ、さらに恐らくエージェントを認証する主体として信頼できるオーソリティに付与された情報などを認証者は使用することが出来る。エージェント・システムと同様に認証者もタイプを持つ必要がある。さらに、認証者は名前つけを担当するオーソリティによって登録されるべきである。認証者を一段階、と多段階との２つのタイプに分類することが出来る。現時点では、一段階の認証者に関する動作と要件の仕様の作成は可能である。しかし、現時点のセキュリティ技術に限界があるために、多段階の認証者の仕様は先送りせざるをえない。
【００９８】一段階の認証者はエージェントが出発点から一段階離れたところへ移動する際のエージェントの認証ができる。例えば、オーソリティAに属するエージェントがオーソリティAのエージェント・システム上で実行している際、そのエージェントがオーソリティBのエージェント・システムへ移動する場合を考える。エージェント・システムBがエージェント・システムAの認証に成功した場合、エージェントはエージェント・システムAの真正性をエージェント・システムＢ上で保有する。エージェント・システムＢがエージェント・システムＡを認証できない場合、そのエージェントは認証されたとはみなされない。エージェントが移動元のエージェント・システムとは異なるオーソリティを持つ場合、このエージェント転送は多段の操作と考えられる。多段階の認証については、本仕様の対象とはしない。」（「GMD FOKUS、International Business Machines Corporation、Supported by: Crystaliz, Inc.、 General Magic, Inc.、The Open Group "Joint Submission : Mobile Agent System Interoperability Facilities Specification" 、November 10, 1997 OMG TC Document orbos/97-10-05」より）
【００９９】パスポートや運転免許証のように発行時に厳密な認証を受ければ、以後その証書を提示する事によって一定水準の認証が可能であるような証明書が存在すると、上記の多段階の認証に関する問題は解決可能となる。しかし、コンピュータ上やネットワーク上でのデータ化された証書はコピーや改ざんが容易なため、原本のコピーや改変と原本自体とを確実に識別できる証書システムが必要である。しかも、そのような証書はエージェントの移動に伴って移動可能でなければならない。このとき、先に述べてきた２重の証明書機構は、原本とそのコピーや改変との識別が可能でしかも移動も可能なクレデンシャルとしての要求を満足するものである。今までの説明において、改ざん不正コピー等、悪意に基づく違法アクセスに対抗する例を多く考えてきたが、クレデンシャルとして応用する場合、コピーや属性の変更はシステム的にも認められた操作である。この場合においてもコピーや異形に対して原本を識別する操作として上述のコピーや改ざんに対抗する操作を使用する事ができる。
【０１００】この技術は、移動エージェントの認証機構として開発されたものだが、プロセスとしては、エージェントだけでなく、署名付きの変造不能なデータを与えることも可能である。このようなプロセスは、有価証券や、金券など、ネットワーク上においてその存在の唯一性の保証が要求されるものに対する代替物として利用可能である。従来方式の署名付きデータだけでは、容易にデータのコピーが可能であったため、有価証券などの実現はネットワーク上では困難であった。本技術の証明書をそのデータに付加させることで違法コピーや偽装が困難になることは、すでに説明した通りである。
【０１０１】＜第１９実施形態：証明書正副間に悪者が介在する場合の排除方法＞本発明の認証方式は証明書の正本と副本との間の参照やメソッド呼出しに矛盾が無い事を前提にしている。これは、証明書相互間に共通の秘密を仮定せず、証明書の真正性を確認する方式を与えるためには、必要な事である。本方式は、移動可能プロセスの認証に応用する事が主要な目的であるため、このように共通の秘密を前提にしないことが要求されている。しかし、図１４のように、証明書正本と証明書副本との間に、悪者が介在し、両者間のメソッド呼出しを横取りすることによって、正本に対して副本を偽装し、副本に対して正本を偽装する方式の攻撃の恐れがある。いわゆる、バケツリレー式の攻撃である。
【０１０２】このような攻撃に対する対策は、証明書機構より下位に位置する通信機構にて行う必要がある。これには、次のような選択がある。ここで証明書管理機構が稼動しているホストをH1、ユーザー側のプロセスが稼動しているホストをH2とする。
(1)ホストＨ1とホストＨ2との通信システムに特に保護機能は置かないが、他の介在者が入り込まないよう運用面での管理を行う。
(2)ホストＨ1とホストＨ2との通信システムの物理層あるいは、データ・リンク層に暗号化機構などの保護機能を組み込む。
(3)ホストＨ1とホストＨ2との通信システムとアプリケーションとの制御を行うオペレーティング・システムなどに暗号化機能などの保護機能を組み込む。
(4)ホストＨ1とホストＨ2上で動作している、ORB（Object Request Broker）などのRMIやRPCを実現するミドルウェアに暗号化機能などの保護機能を組み込む。
(5)移動可能プロセスを実行させる実行環境と、証明書管理機構を実装するサーバー・プログラム等との間の通信に、暗号化機能などを組み込んだ安全な汎用メソッド呼出し機能を実現する。これは、両者は移動しないプロセスなので、プロセス立ち上げ時などに共通の秘密をパラメータやコンフィギュレーション・ファイルなどの形で与える事ができるので可能である。個々の証明書間のメソッド呼出しは、証明書の参照や、コマンド・コード、その他のデータを引数として汎用メソッドに渡す事で行う。
(6)Proxy（代理プロセス）をホストＨ2上、またはホストＨ1とホストＨ2双方の上に置き、Proxy経由でメソッド呼出しを行う。Proxyは暗号化等の保護機能を実現する。認証者をこの目的のために使用する事も考えられる。証明書副とProxyは同一ホスト上なので、その間の通信は充分安全であると考える。
【０１０３】＜第２０実施形態：証明書付き移動可能プロセスのデジタル通貨への応用＞銀行など許可された金融機関に証明書管理機構を設置し、そこを中心とした、セキュリティ・ドメインを構築する。様々な、金融機関の本支店間に独立したセキュリティ・ドメインが存在すると仮定する。各セキュリティ・ドメインには、そのドメインを管理する金融機関と契約した顧客のホストが接続されていると仮定する。セキュリティ・ドメイン相互間は、通信回線で結合されデータやプロセスの移動が可能であると仮定する。
【０１０４】このとき、それらのセキュリティ・ドメイン全体で流通する無記名のデジタル通貨を次のように実現することが可能である。
(1)デジタル通貨は、金融機関によって発行された証明書付きの移動可能プロセスである。
(2)証明書には、発行金融機関名と、発行日付、一意の識別番号、金額が明示されている。そして、証明書の内容が真正であることを示す、金融機関の署名が付加されている。
(3)プロセスには2つのメソッドが定義されていて、その一つは支払であり、他の一つは受け取りである。
(4)プロセスは、通貨の所有者を示す特殊な実行環境で動作する。この実行環境は、顧客のホスト内で動作し、ちょうど財布や金庫の役割を果たす。
(5)支払メソッドによってデジタル通貨は、現在実行中の環境から、指定された環境へ移動する。これは、金銭の支払に相当する。
(6)このメソッドの実行途中に、現実行環境から、所有者本人もしくは、本人の代理のプロセスに対して承認を求める通知がなされる。承認を受け取るまで、プロセス移動処理は一時中断する。
(7)この承認をうけて、プロセスの移動処理が再開される。
(8)この移動時に、既に述べられた証明書付きのプロセスの移動手順が実施され、通貨の認証と一意性の保証がなされる。
(9)プロセスの移動が完了し、再起動されるときに受け取りメソッドが実行される。このとき、受領通知が、送り元実行環境に伝えられる。これは、領収書に相当する。
(10)通貨を金融機関等に預金する目的で、第17節で記した、証明書付きプロセスの保存法式を応用することも可能である。
【０１０５】＜第２１実施形態：記名式通貨（手形：小切手）の実現＞記名式デジタル通貨は、振り出し人本人によって発行された証明書付きの移動可能プロセスである。証明書には、本人の氏名、取引先金融機関名と、発行日付、支払期日、一意の識別番号、金額が明示されている。そして、証明書の内容が真正であることを示す、本人の署名が付加されている。プロセスには、支払、受け取り、裏書き、取りたて、不渡りという5つのメソッドが定義されている。プロセスは、通貨の所有者を示す特殊な実行環境で動作する。この実行環境は、顧客のホスト内で動作し、ちょうど財布や金庫の役割を果たす。支払メソッド、もしくは裏書きメソッドによって記名式デジタル通貨は、現在実行中の環境から、指定された環境へ移動する。これは、手形の振り出し、もしくは裏書きに相当する。
(1)このメソッドの実行途中に、現実行環境から、所有者本人もしくは、本人の代理のプロセスに対して承認を求める通知がなされる。承認を受け取るまで、プロセス移動処理は一時中断する。
(2)この承認をうけて、プロセスの移動処理が再開される。
(3)この移動時に、第５，１４，１５，１６及びその他の実施形態において既に述べられた証明書付きのプロセスの移動手順が実施され、通貨の認証と一意性の保証がなされる。さらに、裏書きの場合、裏書人の氏名、実行環境名、および署名が、一旦、証明書管理機構に送られ、証明書正本に、氏名と実行環境名、および署名が付加される。
(4)プロセスの移動が完了し、再起動されるときに受け取りメソッドが実行される。このとき、受領通知が、送り元実行環境に伝えられる。これは、領収書に相当する。
(5)取り立ての際、受取人は、取り立てメソッドの実行を要求する。このメソッドは支払期日後に限って有効である。
(6)記名付きデジタル通貨は、証明書に明示されている取り引き金融機関に移動し、等価の無記名デジタル通貨との交換を要求する。
(7)金融機関は振り出し人の口座の残高を確認し、残高が充分な場合には、指定された金額を口座から引き落とし、その金額のデジタル通貨を受取人に支払う。
(8)口座の残高が不足している場合、不渡りメソッドが実行される。
(9)不渡りメソッドは、証明書正本に付加されている、裏書人の実行環境リストを逆の順序で移動しながら、当該手形が不渡りになったことを、各裏書き人に通知しながら、振出し人の実行環境に戻る。
(10)通貨を金融機関等に預金する目的で、第１６実施形態で記した[証明書付きプロセスの保存法式]を応用することも可能である。
【０１０６】（フ゜ロセスの移動と生成処理の実施例）
<手順１．証明書管理機構同士の認証に使用する共有鍵の登録>手動で行う。
【０１０７】<手順２．証明書管理機構の起動>手動で行う。
【０１０８】<手順３．認証者の起動>マスター認証者の起動は、手動または、各ホスト・コンピュータの定義ファイルなどにて定められた手順にて起動する。その他の認証者は、マスター認証者によって起動される。認証者の種類は、ユーザー認証者、実行環境認証者（前記実施形態では、証明書機構をサポートするJava仮想マシンを立ち上げる認証者）、オブジェクト生成認証者、オブジェクト再生成認証者、移動プロセス認証者、マスター認証者（証明書管理機構の所在を管理する）である。認証者との対話方式は実装によって異なる。
【０１０９】<手順４． 実行環境の起動>前提としては、証明書管理機構と実行環境との間には、信頼を確立する方法が存在する。たとえば、あらかじめ暗号鍵が共有されている。
(1)もしも、ユーザーの認証が行われていない場合には、ユーザー認証者はユーザーの認証を行う。
(2)ユーザーとの安全な通信セッションを確立する。
(3)ユーザーが実行環境の起動を要求する。
(4)実行環境認証者がユーザーの権限の問い合わせを行う。
(5)指定された実行環境の起動が行われる。
【０１１０】<手順５．実行環境と証明書管理機構との安全な通信の確立>(1)証明書管理機構と実行環境との相互認証が行われる。
(2)相互に安全な通信を行うための通信セッション鍵を生成する。
(3)以後の通信をそのセッション鍵でもって暗号化する。
(4)実行環境を管理する証明書を生成する。この情報は実行環境認証者によって与えられる。
【０１１１】<手順６．オブジェクトもしくはプロセスの生成>(1)もしも、ユーザーの認証が行われていない場合には、ユーザー認証者はユーザーの認証を行う。
(2)ユーザーとの安全な通信セッションを確立する。
(3)もしも、実行環境の起動が必要な場合は、手順５にしたがって実行環境の起動を行う。
(4)手順７にしたがって、クラスやプログラムの権限の確認を行う。
(5)オブジェクト生成認証者によってオブジェクトの生成要求を行う。
(6)手順８に従ってオブジェクトの生成が行われる。
(7)必要ならば、生成されたオブジェクトの妥当性をユーザーに確認させる。
(8)オブジェクト生成認証者はオブジェクトの参照と空の証明書副本の参照を証明書管理機構に渡す。
【０１１２】<手順７．オブジェクトを定めるクラスやプログラム等の権限の確認>要求したユーザーの権限に対して、使用されるクラスやプログラムの許可レベルが適切かどうかを確認する。
【０１１３】<手順８．環境内でのオブジェクトの生成>(1)指定されたクラスに基づくオブジェクトのインスタンスを生成する。
(2)空の証明書副本を生成する。
(3)証明書副本とオブジェクトとの対応付けを行う。
(4)オブジェクト生成認証者にオブジェクトと証明書副本の参照を渡す。
【０１１４】<手順９．証明書正本生成>(1)オブジェクト生成認証者より渡されたオブジェクトの参照と空の証明書副本ならびに、ユーザー情報、さらに認証情報データ・ベースなどによる情報に従って、証明書正本を作成する。
(2)正本に副本の参照を設定する。
(3)正本にオブジェクトへの参照を設定する。
(4)副本に対して初期設定要求をだす。
【０１１５】<手順10. 証明書副本の初期設定手順>(1)マスター認証者に対して証明書管理機構の参照を要求する。
(2)証明書管理機構に対して、証明書副本の参照を渡して、対応する正本の参照を要求する。
(3)もしも、正本の参照が得られない場合は、エラーとする。
(4)副本に正本の参照を設定する。
(5)正本に対して証明書データ読み出し要求を出す。
(6)正本から送られてきたデータを副本に設定する。
【０１１６】<手順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]を解読し、整数Ｒを取り出す。
(11)最後に、応答としてR+1を戻す。
(12)適当な整数R2を生成しKXY[R2]をチャレンジとして証明書正本に送る。
(13)その応答としてR2+1が戻されてきた場合、共有鍵の生成は成功である。また、その応答には、暗号化された、証明書正本と暗号化された共有鍵が添付されている。
(14)手順16を行う。
(15)手順17を行う。
【０１１７】<手順12. マスター認証者による移動可能プロセスと証明書管理機構との、移動のための相互認証手順>(1)不正検出アルゴリズムの手順2に従って、プロセスの認証を行う。このとき、証明書管理機構は、認証成功時にプロセス間で鍵を決定するために必要な、素数p、整定数gを返すものとする。
(2)認証結果をもどす。その際、成功時には、素数p、整定数gも戻す。
【０１１８】<手順13．証明書管理機構間の共有鍵生成手順>(1)宛先情報を名前付け管理機構などに渡し、相手先の認証機構の参照を得る。
(2)第16節の手順のいずれかに従って、共有鍵を生成する。ここで生成された鍵をKABとする。また、ここでは、転送セッションIDも生成されることとする。
【０１１９】<手順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を返す。
【０１２０】<手順15．正本側の証明書とプロセスとの共有鍵との暗号化手順>(1)証明書正本、プロセスとの共有鍵KXY、タイムスタンプを文字列として結合する。
(2)この文字列をKABにて暗号化する。
【０１２１】<手順16．プロセスの外部形式生成と暗号化手順>(1)定められたシリアライゼーションの手順に従ってプロセスの外部形式をバイト列として生成する。
(2)生成されたバイト列をKXYにて暗号化する。
【０１２２】<手順17.プロセスの他セキュリティドメインの移動プロセス認証者に対する移動申請手順>(1)プロセスが管理している宛先情報を、名前付け管理機構などに渡し、移動先の移動プロセス認証者の参照を入手する。
(2)手順16にて得られた暗号化されたプロセスの外部形式、証明書管理機構から送られた暗号化された正本、プロセスと証明書管理機構との共有鍵、セッションID、プロセスの参照、証明書正本、副本の参照を引数として、移動プロセス認証者に移動要求を発行する。
【０１２３】<手順18．移動プロセス認証者によるプロセスと証明書との複号化手順>(1)プロセスの暗号化されたプロセスの参照、セッションIDと、証明書正本の参照、暗号化された正本、プロセスとの共有鍵を証明書管理機構に渡し、手順20によって証明書とプロセスの再生成を行う。
(2)正常に再生成が行われない場合要求プロセス側にエラーを戻す。
【０１２４】<手順19のa．移動プロセスの再生成手順>(1)与えられたプロセスの外部形式から所定のデシリアライゼーション手順を使用して内部形式を生成する。
(2)内部形式の生成に失敗した場合はエラーとする。
(3)手順７にしたがって、クラスやプログラムの権限の確認を行う。
(4)空の証明書副本を生成する。
(5)証明書副本とオブジェクトとの対応付けを行う。
(6)移動プロセスト生成認証者はオブジェクトの参照と空の証明書副本の参照を証明書管理機構に渡す。
【０１２５】<手順19のｂ．プロセスの外部形式解読を経たプロセス生成>(1)KXYによってプロセスの暗号を解読しプロセスの外部形式を作る。
(2)もしも、実行環境の起動が必要な場合は、手順５にしたがって実行環境の起動を行う。
(3)手順19のaによってプロセスの生成を行う。
(4)生成されたプロセスの参照と空の副本の参照を戻す。
【０１２６】<手順20．証明書とプロセスの再生成>(1)セッションIDより共有鍵KABを取り出す。
(2)共有鍵KABを使用して暗号化された証明書ならびにプロセスとの共有鍵、タイムスタンプの暗号を解除する。
(3)送信側の証明書正本の参照と暗号解除された証明書との照合を行う。
(4)照合で致命的な不一致が発見された場合、またはタイムスタンプが閾値の範囲に入らない場合は、エラーとして処理を打ち切る。
(5)オブジェクト再生成認証者にプロセスとの共有鍵KXY、暗号化されたプロセスの外部形式を渡し、手順19のbにてプロセスの再生成を行わせる。このとき、正常に再生成された場合、空の証明書副本とプロセスの参照が渡される。
(6)正常な再生成が行われなければ、エラーとして処理を打ち切る。
(7)オブジェクト再生成認証者よりもどされたオブジェクトの参照と空の証明書副本ならびに、解読された正本情報、さらに認証情報データ・ベースなどによる情報に従って、証明書正本を作成する。
(8)正本に副本の参照を設定する。
(9)正本にオブジェクトへの参照を設定する。
(10) 副本に対して初期設定要求をだす。
(11)送信側の証明書正本に対して手順21の無効化処理を行う。
【０１２７】<手順21．送信側の証明書の無効化手順（正副の無効化）>(1)要求側が、証明書管理機構であることを確認する。
(2)証明書正本に無効フラグを設定する。
(3)正本で管理しているプロセスの参照に対して手順22の無効要求を発する。
(4)正本を管理テーブルなどから削除する。
【０１２８】<手順22．送信側のプロセスの無効化手順>(1)マスター認証者に対して証明書管理機構の参照を要求する。
(2)証明書管理機構に対して、証明書副本の参照を渡して、対応する正本の参照を要求する。
(3)もしも、正本の参照が得られない場合は、プロセスの終了処理を行う。
(4)正本の無効フラグをチェックする。
(5)無効フラグがtrueの場合には、プロセスの終了処理を行う。
【０１２９】
【プロセス・コピーに対抗した場合の手順の変形】<手順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]を解読し、整数Ｒを取り出す。
(13) 最後に、応答としてR+1を戻す。
(14) 適当な整数R2を生成しKXY[R2]をチャレンジとして証明書正本に送る。
(15) その応答としてR2+1が戻されてきた場合、共有鍵の生成は成功である。また、その応答には、暗号化された、証明書正本と暗号化された共有鍵が添付されている。
(16) 手順28を行う。
(17) 手順29を行う。
【０１３０】<手順24. マスター認証者による移動可能プロセスと証明書管理機構との相互認証手順>(1)不正検出アルゴリズムの手順2に従って、プロセスの認証を行う。このとき、証明書管理機構は、認証成功時にプロセス間で鍵を決定するために必要な、素数p、整定数gを返すものとする。またこの処理の終了段階で、認証成功時、手順25によって、証明書正本経由でプロセスからハッシュ値の転送を行う。
(2)認証結果をもどす。その際、成功時には、素数p、整定数gも戻す。
【０１３１】<手順25．ハッシュ値送付手順>(1)証明書正本は自分が保持しているプロセスの参照に対してハッシュ値の要求を行う。
(2)プロセスからの戻りとしてハッシュ値が与えられる。
【０１３２】<手順26．証明書管理機構間の共有鍵生成手順>(1)宛先情報を名前付け管理機構などに渡し、相手先の認証機構の参照を得る。
(2)第16節の手順のいずれかに従って、共有鍵を生成する。ここで生成された鍵をKABとする。また、ここでは、転送セッションIDも生成されることとする。
【０１３３】<手順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を返す。
【０１３４】<手順28．プロセスの外部形式の暗号化手順>(1)定められたシリアライゼーションの手順に従ってプロセスの外部形式をバイト列として生成する。
(2)生成されたバイト列をKXYにて暗号化する。
【０１３５】<手順29.プロセスの他セキュリティドメインの移動プロセス認証者に対する移動申請手順>(1)プロセスが管理している宛先情報を、名前付け管理機構などに渡し、移動先の移動プロセス認証者の参照を入手する。
(2)手順28にて得られた暗号化されたプロセスの外部形式、証明書管理機構から送られた暗号化された正本、プロセスと証明書管理機構との共有鍵、ハッシュ値、セッションID、プロセスの参照、証明書正本、副本の参照を引数として、移動プロセス認証者に移動要求を発行する。
【０１３６】<手順30．移動プロセス認証者によるプロセスと証明書との複号化手順>(1)プロセスの暗号化されたプロセスの参照、セッションIDと、証明書正本の参照、暗号化された正本、プロセスとの共有鍵、ハッシュ値を証明書管理機構に渡し、手順32によって証明書とプロセスの再生成を行う。
(2)正常に再生成が行われない場合要求プロセス側にエラーを戻す。
【０１３７】<手順31．環境内での移動プロセスの再生成手順>(1)与えられたプロセスの外部形式から所定のデシリアライゼーション手順を使用して内部形式を生成する。
(2)内部形式の生成に失敗した場合はエラーとする。
(3)手順７にしたがって、クラスやプログラムの権限の確認を行う。
(4)空の証明書副本を生成する。
(5)証明書副本とオブジェクトとの対応付けを行う。
(6)移動プロセスト生成認証者はオブジェクトの参照と空の証明書副本の参照を証明書管理機構に渡す。
【０１３８】<手順32．証明書とプロセスの再生成>(1)セッションIDより共有鍵KABを取り出す。
(2)共有鍵KABを使用して暗号化された証明書ならびにプロセスとの共有鍵、タイムスタンプ、ハッシュ値の暗号を解除する。
(3)送信側の証明書正本の参照と暗号解除された証明書との照合を行う。
(4)照合で致命的な不一致が発見された場合、またはタイムスタンプが閾値の範囲に入らない場合は、エラーとして処理を打ち切る。
(5)オブジェクト再生成認証者にプロセスとの共有鍵KXY、暗号化されたプロセスの外部形式、ハッシュ値HashPを渡し、手順33にてプロセスの再生成を行わせる。このとき、正常に再生成された場合、空の証明書副本とプロセスの参照が戻される。
(6)正常な再生成が行われなければ、エラーとして処理を打ち切る。
(7)オブジェクト再生成認証者よりもどされたオブジェクトの参照と空の証明書副本ならびに、解読された正本情報、さらに認証情報データ・ベースなどによる情報に従って、証明書正本を作成する。
(8)正本に副本の参照を設定する。
(9)正本にオブジェクトへの参照を設定する。
(10) 副本に対して初期設定要求をだす。
(11) 送信側の証明書正本に対して手順21の無効化処理を行う。
【０１３９】<手順33プロセスの外部形式解読とハッシュ値との照合を経たプロセス生成>(1)KXYによってプロセスの暗号を解読しプロセスの外部形式を作る。
(2)外部形式にハッシュ関数を適用してハッシュ値Hを求める。
(3)HとHashPとが一致しない場合、エラーとして処理を打ち切る。
(4)もしも、実行環境の起動が必要な場合は、手順５にしたがって実行環境の起動を行う。
(5)手順31によってプロセスの生成を行う。
(6)生成されたプロセスの参照と空の副本の参照を戻す。
【０１４０】
【発明の効果】本発明の移動可能プロセスの認証方法によれば、証明書管理機構の安全が確保されていることにより、証明書正本副本の信頼性の保障が可能となり、他の情報に依存することなく、証明書正本副本と移動可能プロセスのみによって移動可能プロセスの移動時の認証を行うが可能となる。従って、実行環境間において転々と転送されて移動する移動可能プロセスが変化しても、移動の元となった実行環境のプリンシパルと移動可能プロセスとの相互参照可能な証明書正副データにより、当該転送された移動可能プロセスの真正性を証明書管理機構側で認証することが可能となり、移動可能プロセスの不正コピーや、改竄、なりすまし、データの盗難・破壊を防止することができ、移動エージェントなどの移動可能プロセスのセキュリティーを顕著に向上させることができる。
【図面の簡単な説明】
【図１】本発明の認証機構の概念を示す図
【図２】本発明の証明書機構の基本構造を示す概念図
【図３】本発明のセキュリティ・ドメインの概念図
【図４】本発明で問題としているセキュリティ・ドメイン間のプロセス移動の概念図
【図５】本発明の移動可能プロセスの認証手順の概念図
【図６】本発明のユーザー・オブジェクトへの証明書の割付の概念図
【図７】本発明の移動可能プロセスの認証手順の概念図
【図８】本発明における証明書偽造への対策を示す概念図
【図９】本発明における不正コピーへの対策を示す概念図
【図１０】本発明における偽装への対策を示す概念図
【図１１】本発明におけるユーザー・オブジェクトへの証明書の埋め込みを示す概念図
【図１２】本発明における証明書管理機構自体を偽装している場合の対策を示す概念図
【図１３】本発明において配列又はハッシュテーブルにより証明書と秘密の対応をさせた場合の概念図
【図１４】正副証明書間に介在者が存在した場合のバケツリレー攻撃の概念図
【０００１】
【発明の属する技術分野】本発明は、ネットワークを構成するコンピュータ間において移動する移動可能プロセスのマルチ・ホップ認証方式とその各種の変形に関する。
【０００２】
【従来の技術】ネットワーク間を移動する移動エージェントなどの移動移動可能プロセスにおいては、当該移動プロセスが移動する際に、当該移動プロセスが真正なところから発信されたものであるかどうか、の認証の問題が伴う。例えば、図4のネットワーク構成において、認証サーバーA, B, Cがあたえられ、そのサーバーそれぞれに統治される３つのドメインa, b, cが存在すると仮定する。また、ドメインａ，ｂ，ｃ間は通信回線で結合されており、セキュリティ・プロトコルに準拠したデータのやり取りが可能であるとする。このとき、ドメインａにあるプロセスをPxとし、それをドメインb、ドメインc、に移動させる事を考える。
【０００３】従来の認証方法は、認証を受ける側と与える側とで他には知り得ない秘密を共有することや、他の存在は所持し得ない持ち物を提示する事によって行われていた。それらの秘密や特定のための情報は、パスワードや暗号鍵、IC-カード、個人の身体的な特徴などである。プロセスの移動を考慮しない場合のプロセスの認証は、プロセスの生成時に生成者本人が認証者に対してその秘密や持ち物を提示する事によって行われていた。
【０００３】また、公開鍵暗号方式を利用する場合、本人が自分しか知らない秘密鍵で署名を行い、その署名の確認は対応する公開鍵で署名が読めるかどうかで行われる。公開鍵を使用する場合、個人が持つ秘密鍵を外部に一切知らせずに、公知の公開鍵だけで確認ができる点が長所である。この技術を使用する場合、署名を公的な機関に登録する事によって、署名に対する公的な認証効果を持たせる事が可能である。ここにおいて、両者に共通している事は、個人だけにしか持ち得ない持ち物や秘密の存在を仮定している点である。尚、あらかじめ、以下の記述で主要な役割を持つ用語を定義しておく。
【０００４】[プロセス]本発明では、プロセスという用語を通常より拡大された意味で用いる。それは、本発明の目的が、いわゆる移動エージェントと呼ばれるネットワーク上を移動しながら一連の手順を実行するオブジェクトプログラムに対する認証機構を定めるためである。そこで、本発明では、プロセスという用語に対して、従来のプロセスの意味に加えて、移動エージェントを構成し得るオブジェクトという意味を与える。ここには、基礎となるシステムに応じて、タスク、実行スレッド、スクリプトなどを含ませることが可能である。
【０００５】[プロセスの外部形式]プロセスの外部形式とは、実行中のプロセスをネットワーク上の別のホストや外部記憶媒体などに転送する際の形式をいう。そこには、プロセスを構成する手順と実行時の内部状態データ、制御情報などが含まれている。オブジェクト指向システムでは、シリアライゼーション（Serialization:直列化）と呼ばれる技法が使用される事が多い。本発明では、所によっては、プロセスの外部形式を生成する意味で、シリアライゼーションという用語を使用する場合がある。ただし、本発明では、外部形式のデータ構造や手法は特に限定しない。
【０００６】[認証者]認証者 (Authenticator) とは、単一あるいは複数の処理手続きであって次のような機能をもつものをいう。
1) 証明書の真正性の判定を行う。
2) 証明書の真正性にもとづいて証明書と対応付けられたプロセスなどのオブジェクトに対する認証をあたえる。
3) ドメインを管理する証明書管理機構の特定をする。この機能は、認証者固有の機能である。その他、の機能は実装上の判断によっては、次に述べる証明書管理機構に行わせることも考えられる。
4) エージェントなどの移動可能プロセスに対する移動時の認証を行う。
5) ユーザーに対する認証を与える。
6) 認証にもとづいて証明書の発行を行う。
【０００７】認証者は、これらの機能を実現するに当たって証明書管理機構にアクセスし、そこで保持されている証明書データを使用する事が可能である。また、証明書管理機構間で定められた秘密情報を利用する事も許されている。従って、認証者の安全性を保証する必要がある。もっとも、必ずしも、全ての認証者が上記の機能の全てを実装するわけではなく、上記の機能の一部だけを実装する事によって、様々なタイプの認証者が実現され得る。
【０００８】例えば、ユーザーの認証を行い、そのユーザーが所有するオブジェクトやプロセスそして、それらに対応する証明書を発行する認証者は、ユーザー認証者などと呼ばれるであろうし、移動時のエージェントの認証を専門に行う認証者はエージェント認証者などと呼ばれるかもしれない。
【０００９】[証明書管理機構]証明書管理機構は、正本、副本からなる証明書のうち、証明書正本を複数管理する。これは、証明書管理機構固有の機能の一つである。一般に、認証を与えるサーバーのことを認証サーバーと呼んでいるが、本発明では、認証を与え証明書の発行／管理をも行うサーバーもしくはサーバーと同等な機能を有する装置に対して証明書管理機構なる用語を与える事にする。証明書管理機構は外部からの不正アクセスに対して安全であることが必要である。ある証明書管理機構は、別の証明書管理機構と秘密を共有する等の方法によって相互認証を行う事が可能であることが要求される。これは、二つ目の証明書管理機構固有の機能である。ただし、本発明では証明書管理機構間の相互認証の方式に関しては特に定めない。なお、本発明では、所によっては、証明書管理機構の意味で認証サーバーとかサーバーという用語を用いる場合もある。通常、証明書管理機構には、専用の独立したホスト・マシンが与えられている。
【００１０】[認証機構]上に記した認証者と証明書管理機構との組が本方式での認証機構を形成する。認証者は認証を与えるオブジェクトと証明書管理機構との仲介を行う立場にある。認証機構全体から見ると、上記の認証者と証明書管理機構との役割はある程度流動的なものと考えても良い。上で記された認証者の機能の一部を証明書管理機構側に持たせる事などは、本発明で述べる証明書方式を利用した認証機構の実装上の判断として許される。従って、以下の本発明の記述に関して、証明書管理機構の機能とされる部分を認証者に行わせたり、その逆を行わせたりする変形が生じたとしても、その多くは認証機構の機能としてみると、本発明で述べる記述と本質的な違はない。このような役割配分の検討を行う最大の理由は、証明書管理機構への負荷の集中を回避する事にある。
【００１１】尚、認証者の存在理由は、セキュリティ・ドメイン内に存在する証明書副本がどのような改ざんにあったとしても、対応する証明書正本を見つけ出せる事を保証する事にある。
【００１２】[環境]手続き、プロセス、オブジェクトなどの実行を行う場一般を環境と呼ぶ事とする。ここには、コンピュータ・ハードウェア、オペレーティング・システム、仮想マシン、サーバー・プログラムなどを含ませることが可能であるが、手続き、プロセス、オブジェクト等が実行可能でありさえすれば、本発明ではその形態を問題にはしない。ただし、所によっては、オペレーティング・システムや仮想マシンのニュアンスを込めて実行環境という用語も使用する。
【００１３】[通信機構]環境と環境との間で情報の交換を可能にする機構を通信機構とよぶ。所によって通信システム、通信回線という用語も同じ意味に使用することもある。通信機構自体は信頼性が高いと仮定する。すなわち誤りの無い通信が可能である。しかし、悪者による意図的な盗聴やノイズの混入も有り得ると仮定する。
【００１４】[証明書]プロセスやオブジェクトの認証情報を保持するデータを証明書という。本システムの証明書は正副の２つ証明書データから構成される。証明書の正本は、証明書管理機構側に置かれ、証明書の副本はユーザー環境のセキュリティ管理プログラム内に置かれる。そして、正副証明書相互は双方向の参照でリンクされている。
【００１５】[セキュリティ・ドメイン]証明書管理機構などの認証サーバーは権威あるプロセスであって、厳密な安全対策が施されていると想定する。従って、証明書管理機構への侵入やデータの改ざんは困難である。このことが、本機構内で証明書の唯一の存在を保証する前提である。証明書管理機構など認証サーバーの周辺には、その認証サーバーによって統治されているユーザー環境が複数存在している。そのような、認証サーバーに統治されるユーザー環境内のオブジェクトの集合が、セキュリティ・ドメインを構成する。セキュリティ・ドメイン中のオブジェクトは認証サーバーによって認証されているものもあれば、認証されていないものもある。認証されていないオブジェクトは、原則としてゲストとして扱われ公共の資源に対するアクセスだけが許可される。認証されたオブジェクトの集合が安全なドメインを形成する。本発明では、特に断りの無い限り、このような安全なドメインだけを考える事にする。
【００１６】
【発明が解決しようとする課題】[移動可能プロセスの認証問題]しかし、従来の技術で述べた認証方式を図１０R>０のような移動するプロセスの認証に使用する事は、実際上不可能である。第１の理由として、情報であるプロセスに個人が所持している物体を持たせる事は不可能だからである。第２の理由として、個人と認証サーバーで共有している暗号鍵や、公開鍵暗号方式の秘密鍵をプロセスに保持させることは、秘密の漏洩の恐れがあるため、安全上好ましくないからである。しかし、たとえ秘密をプロセスに持たせなくても、プロセスPxはドメインａにて生成され、認証サーバーAにて認証されている場合、ドメインaからドメインbに移動させる際の認証は可能であり、認証サーバＡの認証を通じて、プロセスPxをドメインbにて受け入れることは可能である。
【００１７】これは、認証サーバAがプロセスPxの生成に直接関与し、プロセスPxの生成時に、プロセスPxの生成を要求した人物本人の認証を行うために必要な情報を保持しているからであり、ドメインｂの認証サーバBの要求を満足させるだけの認証情報を、認証サーバAがプロセスPxに対して付加することが可能なためである。例えば、プロセスPxをドメインｂに送る際、ドメインa内でプロセスPxの生成者の秘密鍵を利用した署名をつけ、プロセスPxをドメインbに送った後に、ドメインｂの認証サーバBが公開鍵で当該署名を確認することなども可能である。
【００１８】[移動可能プロセスの多段階の認証問題]では、ドメインb上に移動したプロセスPxが次にドメインcに移動する場合、同じ手続きが可能であろうか？ これは、困難である。認証サーバーBが認証サーバーCに対して簡単にプロセスPxの認証を与える事はできない。なぜなら、そもそもプロセスPxはドメインbにて生成されたものではないためである。では、サーバーCはサーバーAに問い合わせを行いプロセスPxの認証情報を受ける事ができるだろうか？ それも、困難である。プロセスPxはドメインb上にて処理を行い、その内部状態はドメインa上で処理を行っていた時とは異なっているためである。厳密には、ドメインa上にて活動していたプロセスPxは、ドメインbに移動した時点からプロセスPx'としてプロセスPxとは区別して扱うべき物となっているからある。
【００１９】従って、認証サーバーAとしては、プロセスPx'がプロセスPxの処理の結果なのか、別のプロセスPyがプロセスPx'と詐称しているのか区別する事はきわめて困難である。また、上述した第１の理由を再検討すると、プロセスPxの生成者の秘密鍵を認証サーバーAから認証サーバーBに送る事も機密保持上許されることではない。仮に送信できるとしても、署名等の認証情報を付加されたプロセスPx'が、元々のプロセスPxによる直接の結果であるかどうかを確認することは、困難である。ここで、仮定としてプロセスPxが生成者本人の所持する秘密鍵Kを所持していた場合を考える。認証サーバーCは認証サーバーAにある（任意の或いは所定の？）数Xを提示してもらい、プロセスPxにその秘密鍵Kで数Xを暗号化したK[X]を作らせ、この数Ｋ[Ｘ]を認証サーバーAに確認させ、認証を行う事も確かに可能ではある。
【００２０】しかし、コンピュータ上ではプロセスPxの内部状態まで含めた複写は容易であって、プロセスPxを複写して生成されたプロセスPy（プロセスPxとは異なる）であっても、上の手順は実行可能であって、同様に認証をうけることが可能である。従って、この認証手続きには欠陥がある。尚、移動エージェントの多段階の認証(Multi-hop Authentication)に関しては、「GMD FOKUS、International Business Machines Corporation、Supported by: Crystaliz, Inc.、 General Magic, Inc.、The Open Group "Joint Submission : Mobile Agent System Interoperability Facilities Specification" 、November 10, 1997 OMG TC Document orbos/97-10-05」がある。この論文内には、セキュリティ技術的には未解決である、という記述が見られる。これは、上記ような問題を指すのであろう。この記述については、本発明の第１９実施形態において再び取り上げる。
【００２１】発明者は、このような問題につき以下のように考察した。移動可能プロセスの認証は、移動可能プロセスが確かに移動可能プロセスの所有者のプリンシパル（人間のユーザー、或いはシステム実体であって、認証システムに登録されており、本物であると認められているもの。以下、同じ）に属すことを証明することである。移動可能プロセスはあくまでプリンシパルの代理であり、しかも物体ではなくプログラムと内部データとが複合されたものである。また、内部データは処理の進行に応じて変化するし、コピーも可能である。このため様々な制約や困難が生ずる。そのような制約や問題の幾つかを整理すると、以下の通りとなる。
【００２２】(1) 移動可能プロセス自身にキーを持ち運ばせるのは、プライベート・キーを公開することと同じであるため、危険である。従って、プリンシパルを証明する方式としての、プライベート・キーによる暗号化は移動可能プロセス自身は使えない。
(2)データが変化するので、ハッシュ関数の値を認証の根拠に使うことは出来ない。
(3)一時的なパスワードを移動可能プロセスに保持させることも不可能ではないが、移動可能プロセスはデータでもあるので、パスワードを含めた移動可能プロセス全体をコピーした後に改ざんを受ける可能性がある。
(4)移動可能プロセスの不変部分（移動可能プロセスのコード部など）に署名を付加することも考えられるが、可変部分の信用を保証することはできない。たとえば、不変部分と署名だけをコピーして、可変部分を偽造することも可能だからである。
【００２３】[移動可能プロセスの認証方法]本来、移動可能プロセスの認証とは何を意味するのか？ 移動前の移動可能プロセスAと移動後の移動可能プロセスA'が、同じものであることを証明するとは、何を言っているのか、その正確な意味を定義する必要がある。「同じ」とは決して物理的な同一性を指している訳ではない。実際、移動後の移動可能プロセスA'は、移動前の移動可能プロセスAのコピーである。コピーということは、厳密には同一のものではないということである。このことは、移動可能プロセスの移動自体が、人や物の移動とは異なっていることを意味している。人間世界での認証では、人物のコピーは通常有り得ないとされ、認証行為もその前提で実施される。従って、顔かたちが「同じである」ということの証明が、認証方法として一般に通用するのである。この一般的な通念を覆す例が、双子の片方によって成された犯罪が、状況証拠のみしかない場合、犯人の確定を困難なものにするケースである。この場合、「似ている」という意味を含む「同じ」は、同一性の認証の基準には採用できない。
【００２４】移動可能プロセスの認証にも、やや似た状況が発生している。移動したプロセスが正確なコピーなのか、模造なのかの識別は、両者とも厳密な意味で原本とは同一物でない以上、困難である。すなわち、移動可能プロセスの認証の正確な意味を定義し直す必要がある。
【００２５】
【課題を解決するための手段】発明者は、この認証問題の解決に当たって、ネットワーク上に唯一の存在が保証されている証明書もしくは、許可証があると都合がよいと考える。その実現方法は、認証サーバー上に証明書の正本を置き、ユーザー側にその副本を置くことによる。その際、正本と副本の両者間に双方向の参照を配置する。証明書を生成する際、オーナーのプリンシパルの認証を事前に必要とする。認証の結果として発行された証明書は、ネットワーク上に唯一存在し、複製が不可能であるため、その証明書が盗まれない限り、証明書を保持するという事実自体が認証効果をもつ。これは、パスポートや運転免許証の開示によって本人を認証することと同様である。いわばネットワーク上の身分証明書として通用する。ここにおいて、証明書は、外部形式化可能なデータであり、ネットワーク上を移動させる事が可能なものとする。また、移動や二次記憶媒体への保存には、証明書の唯一性を保証するための手続きを必要なものとする。換言すれば、移動可能プロセスの認証は、移動可能プロセスが属する責任の主体を確定することにより確立される。このことは、移動可能プロセスが与える結果に対して誰に責任を問えるのかを確定する事であるとも言える。
【００２６】なぜなら、移動プロセスは常にその状態を変化させ続けている変化の過程にあるものであって、固定されたものではないため、物体の帰属を問うように移動プロセスに対してそのもの自身の帰属を問うことは出来ない。しかし、その変化の原因-結果の連鎖を原因側にたどって行くことによって、最終的に開始プリンシパルに達するならば、その変化の一局面に対して開始プリンシパルに属する移動プロセスとして認証を与えても良い。すなわち、転送元実行環境にて移動可能プロセスAはすでに認証されていることを帰納法の仮定とすると、移動可能プロセスA'が、移動可能プロセスAからの直接の結果として生じたことを証明できれば、移動可能プロセスA'が、移動可能プロセスAのプリンシパルに属していると主張してよい。
【００２７】この主張を形式的に表現すると、次のような移動可能オブジェクトの認証に関する定義に到達する。ここで、プロセスはオブジェクトの特殊な形態とみなす。
定義1． 移動可能オブジェクトの認証とは、そのオブジェクトが所属するプリンシパルを確定することである。
定義2．移動可能オブジェクトAがプリンシパルPに属するということを次のように帰納的に定める。
【００２８】(1)プリンシパルPの主体がオブジェクトAを直接生成した場合、オブジェクトAはプリンシパルPに所属する。
(2)プリンシパルPに所属するあるオブジェクトAnが存在し、オブジェクトAがオブジェクトAnの結果として生じた場合、オブジェクトAはプリンシパルPに所属する。
(3)オブジェクトAがプリンシパルPに所属するのは、上の(1),(2)の場合に限る。
この定義を具体的な場合にあてはめてみる。シリアライゼーションなどによって外部形式化された移動可能プロセスＡ１のデータ列A2が、転送先実行環境において、元になる移動可能プロセスA1自身によって作成されたことを証明できれば、そのデータ列A2は、移動可能プロセスA1のプリンシパルＰに属しているとして良い。その結果、そのデータ列A2が転送先実行環境でも認証された事になる。
【００２９】さらに、データ列A2をデシリアライズされたデータ列A3もまた移動可能プロセスA1と同じプリンシパルに所属すると判断できる。従って、データ列A3の認証も行われたことになる。このことを実際に応用するためには、移動可能プロセスの転送時における、移動可能プロセスの外部形式化されたオブジェクトが、移動可能プロセス自身の結果として生じたということを明示する必要がある。この、原因-結果の関係を転送時に明確に主張する形の移動可能プロセス（またはオブジェクト）の転送方法を次に記す。
【００３０】このような課題を解決するために、本発明の請求項１は、移動可能プロセス生成時にユーザー等の生成者により与えられた認証情報を保持する証明書正本を、安全の確保された証明書管理機構に設置し、前記証明書正本より派生した証明書副本を前記移動可能プロセスの実行環境内に設置し、前記移動可能プロセスと前記移動可能プロセスとを双方向に参照する参照により一対一に対応させ、前記証明書正本と前記証明書副本とを双方向に一対一に対応させ、前記証明書正本に前記移動可能プロセスへの参照を設定することを特徴とする。
【００３１】また、本発明の請求項２の発明は、請求項１の移動可能プロセスの認証方法であって、前記証明書正本副本、前記移動可能プロセス間の相互間の参照が整合すること、ならびに、前記証明書正本副本情報が整合することの確認をもって、前記移動可能プロセスの認証成功を判定し、当該認証処理において、前記証明書正本が前記証明書管理機構を代表すると見なすことをもって、前記証明書管理機構と前記移動可能プロセス相互の認証が行われたと判定し、前記証明書管理機構と前記移動可能プロセス以外の系には知り得ない共有の秘密生成を可能としたことを特徴とする。
【００３２】また、本発明の請求項３の発明は、１以上のネットワークで接続された転送元実行環境と転送先実行環境と、前記転送元実行環境で生成された移動可能プロセス及び前記転送先実行環境の共有鍵KP1、並びに、前記転送先実行環境の共有鍵KP2を保持し、前記移動可能プロセスと相互認証を行っている証明書管理機構とにおける移動可能プロセスの認証方法であり、第１のステップにおいて、転送に先立ち、前記移動可能プロセスは、前記証明書管理機構に対して共通秘密鍵KAJの生成を要求すると共に、この要求の際、前記移動可能プロセスは秘密の数SAを定め、TA=gSA mod p（pは素数、gはある整定数で、modは法演算をあらわす）を計算してTAを前記証明書管理機構Jに渡し、第２のステップにおいて、前記証明書管理機構は前記移動可能プロセスの要求に答えて、秘密の数SJを生成して TJ=gSJ mod pを計算すると共に、共通鍵KAJをKAJ=TASJ mod p とし、第３のステップにおいて、前記証明書管理機構は前記共有鍵KP2により前記共通秘密鍵KAJを暗号化して、KP2[KAJ]を計算し、第４ステップにおいて、前記証明書管理機構は、前記移動可能プロセスに対して、TJとKP2[KAJ]を前記要求に対して回答し、第５ステップにおいて、前記移動可能プロセスは受け取ったTJから、KAJ=TJSA mod pを計算して、共通鍵KAJを再生し、第６ステップにおいて、前記移動可能プロセスは転送するオブジェクトを外部形式化して外部形式OExを生成した後、この外部形式OEx全体を前記共有鍵KAJにて暗号化してKAJ[OEx]とを生成し、第７ステップにおいて、前記移動可能プロセスは前記転送元実行環境に対して、KAJ[OEx]とKP2[KAJ]とを前記転送先実行環境に転送することを要求し、第８ステップにおいて、前記転送元実行環境から前記転送先実行環境にKAJ[OEx]とKP2[KAJ]とが転送されたとき、前記転送先実行環境はKAJ[OEx]とKP2[KAJ]とを解読して共有鍵KAJをつくることを特徴とする。
【００３３】更に、本発明の請求項４の発明は、請求項２における移動可能プロセスの認証方法であり、前記移動可能プロセスは移動可能オブジェクトであり、この移動可能オブジェクトに、この移動可能オブジェクトに一対一に対応すると共に、前記転送元実行環境の本体であることを示すプリンシパルの識別が記載される名札オブジェクトを前記証明書副本として配置し、前記移動可能オブジェクトが前記名札オブジェクトを配布する場合を、(1)前記プリンシパルの主体が移動可能オブジェクトを直接生成した場合と、(2)前記プリンシパルに所属するある移動可能オブジェクトAnが存在し、ある移動可能オブジェクトAが前記移動可能オブジェクトAnの結果として生じた場合とに限定し、前記(1)の場合に、前記プリンシパルの主体は、当該生成された移動可能オブジェクトが当該プリンシパルに所属することを示す名札オブジェクトを生成し、前記(2)に、前記移動可能オブジェクトAnは当該移動可能オブジェクトAnの名札オブジェクトを複写して、前記移動可能オブジェクトAに付与することを特徴とする。更に、本発明の請求項５の発明は、請求項２の移動可能プロセスの認証方法であり、前記移動可能プロセスは移動可能オブジェクトであり、前記証明書管理機構に、前記名札オブジェクトに一対一に対応する影の名札オブジェクトを前記証明書正本として配置すると共に、前記名札オブジェクトの内容と前記影の名札オブジェクトの内容とを常に一致させ、移動可能オブジェクトがプリンシパルに属するとして認証する場合を、(1)当該プリンシパルの主体が移動可能オブジェクトを直接生成した場合と、(2)ある移動可能オブジェクトAが、元となる移動可能オブジェクトAnの結果として生じた場合とに限定し、前記(1)の場合に、プリンシパルの主体は、プリンシパルの識別が記載された名札オブジェクトを移動可能オブジェクトに対応づけると共に、その名札オブジェクトと同じ内容の影の名札オブジェクトとを対応させて、前記(2)の場合に、オブジェクトAnはオブジェクトAnの名札オブジェクトを複写してオブジェクトAに与え、その名札オブジェクトに影の名札が対応している場合に限り、影の名札オブジェクトの複写も行うことを特徴とする。
【００３４】
【実施の形態】以下に、本発明の実施形態を説明する。
[実施形態１：移動可能プロセスの認証方法]図５は、本発明の第１の実施の形態を示す。図５において、転送元実行環境をP1，宛先実行環境をP2，移動可能プロセスをAとする。さらに、認証キーを生成する審判サーバーJの存在を仮定する。Jは鍵配布センター(KDC)が兼務してもよい。ここで、AとJとは相互認証を行っていると仮定する。またpは素数、gはある整定数で、事前に決めていてもよいし、通信時に定めても良い。また、modは法演算をあらわす。
(1)転送に先立って、移動可能プロセスAはDiffie-Hellman方式を使って、審判サーバJに対して共通秘密鍵KAJの生成を依頼する。この際Aは秘密の数SAを定め、TA=gSA mod p を計算し、TAを審判サーバJに渡す。
(2)審判サーバJは移動可能プロセスＡの要求に答えて、秘密の数SJを生成し、TJ=gSJ mod pを計算する。さらに共通鍵KAJも KAJ=TASJ mod p とする。
(3)審判サーバJは宛先実行環境P2の共有鍵KP2を保持しており、この共有鍵KP2により前記の共有鍵KAJを暗号化し、KP2[KAJ]を計算する。
(4)審判サーバJは、移動可能プロセスAに対して、TJとKP2[KAJ]を要求に対する回答としてあたえる。
(5)移動可能プロセスAは受け取ったTJから、KAJ=TJSA mod pを計算することによって、共通鍵KAJを再生する。
(6)移動可能プロセスAは転送するオブジェクトOを外部形式化し外部形式OExを作る。そして外部形式OEx全体を共有鍵KAJにて暗号化し、これをKAJ[OEx]とする。（このとき、外部形式OExに共有鍵KAJを連結したものをつくり、そのデータ列のメッセージ・ダイジェストを求め、ダイジェスト値と外部形式OExの組をKAJ[OEx]としても良い。）
(7)移動可能プロセスAは転送元実行環境P1に対して、KAJ[OEx]とKP2[KAJ]とを宛先実行環境P2に転送してもらうことを要求する。
(8)転送元実行環境P1から宛先実行環境P2にデータが転送されたとき、KP2[KAJ]を解読して共有鍵KAJをつくる。この共有鍵KAJにてKAJ[OEx]を解読可能であることを根拠に、この外部形式データOExが移動可能プロセスAによって作成されたことが確認できる。そこで、外部形式OExを内部形式化したオブジェクトO'に対して、移動可能プロセスAのプリンシパルに属するという認証を与える事ができる。
【００３５】上の転送手続きでは、転送元実行環境P1が悪意を持って、移動可能プロセスAの内部コードを解析しない限り共有鍵KAJを知ることはできない。上の手順は移動可能プロセスAと審判サーバJとがすでに相互認証を行っていることを仮定している。よって、移動可能プロセスAと審判サーバJしか知る事ができない共有秘密鍵KAJは、信頼できる審判サーバJによって移動可能プロセスAの関与を保証している、と考えることが出来る。従って、KAJ[OEx]が移動可能プロセスAによる結果であるという、原因-結果の連鎖の存在を証明している。故に、外部形式OExが移動可能プロセスAのプリンシパルに属していることが証明されており、さらに外部形式OExを内部形式化して得られるオブジェクトO'も移動可能プロセスAと同じプリンシパルに属していることが示される。
【００３６】この手順は実行環境自体が信頼できない場合には成立しない。実際、悪意を持っている者が、コアダンプをとったり、デバッガーを使用したりすることによって、共通鍵KAJを移動可能プロセスAから取り出すことは困難ではない。ただ、KP2[KAJ]を作る際に審判サーバJによってタイムスタンプを付加してKP2[KAJ|タイムスタンプ]とすることなど、有効期限を課すことで、悪意ある試みにある程度は対抗することもできる。例えば有効期限をタイムスタンプから10分以内とすると、10分間で、共通鍵を取り出し、偽のデータを作成し、P1からP2に転送することは、実際上は、かなり難しい。
【００３７】[第２の実施形態：移動可能プロセスの認証方法の問題点と名札による解決]第１の実施形態で提示した移動可能プロセスの認証方法には、2つの解決しなくてはならない問題がある。一つは、プロセスまたはオブジェクトの所属関係は、理論的には定義されていても、プログラムで使用できるような具体的な表現が与えられていない点である。具体的には、「プロセスAがプリンシパルPに所属する場合」などというとき、処理プログラムが、プロセスAからどのようにしてプリンシパルPという情報を知るのかは、一切触れられていない。
【００３８】もう一つは、移動可能プロセスと審判と呼ばれるサーバーとが、相互認証されているという前提である。この点につき、プロセスの認証を論じているのにその前提として、あらかじめ相互認証されていると仮定することは、循環論法にならないかという疑問が生じるかもしれない。しかし、実際には、この仮定は循環論法ではなく、一種の帰納法の仮定に相当するものである。しかし、これが帰納法の仮定として、通用するためには、本発明の認証結果が単に受け入れ側での認証にとどまらず、受け入れ側と受け入れ側を管理する新たな審判サーバーにも認証できるような、より強い認証手順が求められていることを示している。
【００３９】この２つの問題を解決するために、移動可能オブジェクトに対して、名札とよばれる特殊なオブジェクトを対応させる。名札には転送元実行環境のプリンシパルの識別が記載されており、移動可能オブジェクトに一対一に対応している。移動可能オブジェクトが所属しているプリンシパルの識別が記載されている名札オブジェクトを、特にクレデンシャルと呼ぶ。前述の認証に関する定義２を次のように書きかえると、認証とクレデンシャルの保持とを同一視することが可能なことは、明らかである。
【００４０】クレデンシャルの配布手順 (定義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)の場合に限る。
【００４１】[第３の実施形態：影の名札付きクレデンシャル配布手順]第２の実施形態において、プログラムの操作対象として、名札を見る場合、任意のオブジェクトに任意の名札を与えることは現実に可能であるし、他のオブジェクトがもつ名札を勝手に複写したり、書き換えたりすることも可能である。このように、名札が上のクレデンシャル配布手順以外の方法でも容易に割り付けられる以上、名札とクレデンシャルとの判別が可能な、より実際的な仕組みが必要である。そこで、上のクレデンシャル配布手順にさらに制限を加えた、影の名札付きのクレデンシャル配布手順を考える。影の名札とは、選ばれた名札に一対一に対応づけられたオブジェクトのことで、しかも、名札の内容と影の名札の内容は常に一致するように、名札には影の名札の内容が自動的に反映されるものと仮定する。
【００４２】移動可能オブジェクト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)の場合に限る。
この手順だけを使用してクレデンシャルの割付が行われることを仮定するならば、帰納法によって、クレデンシャルが存在することと影の名札が存在することが同値になることは、明らかである。従って、あるプロセスが影の名札を持つならば、そのプロセスの認証を行うことは可能である。この影の名札付きクレデンシャル配布手順に相当するシステムをプログラムとして実装することは可能である。すると、前節において、プロセスの原因-結果という関係で与えられていた、プロセスの認証を、影の名札に対応付けられたクレデンシャルというデータに基づく認証に置きかえることが可能になる。
【００４３】[第４の実施形態：影の名札付きクレデンシャル配布システムとしての証明書機構]第３の実施形態で議論されたクレデンシャルを構成する名札と影の名札の組を、ネットワークで結合されたコンピュータ上に実装する仕組みとして証明書機構を利用する。ここでは、名札に相当するものが証明書副本と呼ばれ、それはオブジェクトと一対一に対応する。（図6参照）第３の実施形態で影の名札と呼ばれたものは、ここでは証明書正本として実装される。証明書副本の内容は、証明書正本の内容によって2重化され、破壊や改ざんから保護される。証明書正本を証明書副本が置かれているホストとは異なる厳重な安全対策が実施されているホストに置く。これによって、影の名札がクレデンシャル以外の名札とは結合しないことの保証が可能である。さらに、ユーザー・オブジェクト生成時に、プリンシパルの認証を行った後に、オブジェクトに正副証明書を割り付けることとする。
【００４４】これは、第３実施形態の[影の名札付きクレデンシャル配布手順]における「(1)プリンシパルPの主体が直接オブジェクトAを生成した場合、オブジェクトAはプリンシパルPに所属する。このとき、プリンシパルPの主体は、プリンシパルPの識別が記載された名札オブジェクトをオブジェクトAに対応つける。この時、その名札と同じ内容の影の名札を対応させる。」という個所に対応する。証明書副本からユーザー・オブジェクトへの参照をもたせるのと同時に、証明書正本からもユーザー・オブジェクトへの参照をもたせるているため、２つの参照がクレデンシャルとプロセスやオブジェクトとの対応を実現している。万一、副本側の参照が壊れても、実装上クレデンシャルからプロセスへの対応は確保される。
【００４５】もう一つ注目すべき点は、証明書副本はプロセスの所有者に属し、証明書正が認証サーバーの所有者に属しているという仮定を置くと、証明書正本が証明書副本を知っていることと、証明書副本が証明書正本を知っていることとが、結果的にオブジェクト同士の相互認証がとなっている点である。ここで行った仮定が充分に信頼できるならば、証明書正本、副本間（結果的にはプロセスと認証サーバー間で）、Diffie-Hellam法を実施することが可能となり、本発明の移動可能プロセスの認証手順を実現することが可能になる。
【００４６】ところで、この機構の背景にある考えは、どのようにすれば、CORBA・セキュリティ・サービスで使用されているクレデンシャル・オブジェクト（Credential：信任状）自体に認証効果を与えることができるだろうか、という疑問に答えることにある。CORBA・セキュリティ・サービスのシステムでのクレデンシャルは、認証時にパスポートや免許証のように提示するだけで認証が可能となるものではなかった。そのため、本人確認時に、パスポートや車の運転免許証などの提示するだけで認証が可能になるシステムをネット上に形成することができないだろうかと考えた。
【００４７】一般に、パスポートなどの証書は、個人が携帯するパスポートの冊子や免許証のカードそれぞれに対して、所轄の機関で保存されている管理情報の存在が前提になっている。それらの情報作成の際、本人確認の手順が実施される。その手順の一環として、戸籍謄本や住民票の提出などが義務づけられている。そのため、パスポートや免許証を携帯しているという事実によって本人の認証が行われているのである。もしそれらの証書自体に疑念がある場合、所轄の機関に証書の真正性の問い合わせが行われる。証書の偽造はできても、所轄の機関に保存されている情報の偽造は困難であるため、このような問い合わせは有効である。
【００４８】ネットワーク上をこのような証明書をもったプロセスが移動するとき、証明書とプロセスの組み合わせを保証する形で転送処理を行う必要がある。このことを保証するために、暗号技術を応用した転送手順の考案を行った。これは、第３実施形態の[影の名札付きクレデンシャル配布手順]における「(2)プリンシパルPに所属するあるオブジェクトAnが存在し、オブジェクトAがオブジェクトAnの結果として生じた場合、オブジェクトAはプリンシパルPに所属する。このとき、オブジェクトAnはオブジェクトAnの名札を複写してオブジェクトAに与える。もしも、その名札に影の名札が対応している場合、その場合に限り、影の名札の複写も行う。」という部分に相当する。この手順については、次の第５実施形態で詳述する。
【００４９】[第５実施形態： 証明書を応用したプロセス移動方式]プロセスPxと正副証明書は、図6、図７のように対応付けられていると仮定する。ここで、プロセスPxがドメインａからドメインbへ移動するケースを考える。ここで認証サーバーA、B、Cは証明書管理機構として機能し、各ドメインの認証機構をそれぞれAuthA、AuthB、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]とする。ここで、KAPx[PxEx]は外部形式PxExの全面的な暗号化ではなく暗号鍵KAPxを利用したメッセージ・ダイジェスト値を外部形式PxExに付加したものであっても良い。たとえば、外部形式PxExの文頭もしくは文末に暗号鍵KAPxを連結し、それに対してメッセージ・ダイジェスト関数を適用する。このようにして求まったメッセージ・ダイジェスト値と外部形式PxExをまとめて送付しても良い。
(7) プロセスPxはドメインbのAuth BにKAPx[PxEx]、KAB[KAPx]、KAB[O]を送り、プロセスＰｘの移動を申請する。
(8) Auth Bは、手順３にて決定した暗号鍵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から実行形式Pxを再生し、証明書正本O, 証明書副本S, プロセスPx間の対応を形成しプロセスPxの実行を許可する。
(11) この時点で、証明書正本O,証明書副本S の組を使った認証が、ドメインb上でも可能となる。ドメインbからドメインcへの移動の際には、上の認証サーバ Aとドメインaを認証サーバ Bとドメインbに、認証サーバ Bとドメインbを、認証サーバ Cとドメインcにそれぞれ置換えてこの手順を実行すれば良い。
【００５０】注意1、上記手順（第５実施形態）の第7項を契機として、Auth A上で管理されている証明書正本Oならびにその証明書副本Sの無効処置が必要となる。これをどの時点に実施するかは本方式の具体的な実装に依存する。逆に、無効処置を行わない場合、本手順は、プロセスPxを他ドメインへ複写する手順として利用可能である。この場合、相手先認証機構は、証明書を生成する際、複写であることを証明書に明示すべきである。
注意2、上記手順（第５実施形態）の第4項にて行われる共有鍵KAPxの生成は、プロセスPxとAuth A間にて行われるが、暗号鍵KAPxの安全性に配慮するならば、Auth Aの範囲を一層限定して、プロセスPxとAuth A内の認証サーバAとの間で行われるほうが、望ましい。ただし、実装上の選択として、効率性、負荷分散の観点から別の鍵管理機構などをAuth A内に設置して、そことプロセスPxとの間で暗号鍵KAPxを生成することも考えられる。また、上記（第５実施形態）第8項でAuth Bが暗号鍵KABを用いる場合も、暗号鍵KABが認証サーバ Bの外部に流出しないような配慮を行うべきである。
注意3、上記（第５実施形態）第5項から第7項の手順において、KAB[O]と、KAB[KAPx]をプロセスPx経由にてAuth Bに送っているが、その一方もしくは双方を、直接、Auth Bに送るなどの手順変形は可能である。基本的にそれらの変形は上記手順と同等のものと見なして良い。
注意4、応用上、プロセスPxの送信元実行環境と受け入れ側実行環境との相互認証が別途必要となる場合もある。ただし、これは、本手順で扱っている移動時のプロセスに対する認証とは別の手順である。
【００５１】[第５実施形態における重要事項]第５実施形態の手順には4つの重要事項がある。その１つは、プロセスPxの外部形式PxExが確かにプロセスPxによって作られたものであることを、移動先であるドメインｂが納得できる根拠を与える事にある。そのために、暗号鍵KAPxというプロセスPxとAuth Aしか知る事のできない秘密による痕跡をプロセスPxの外部形式PxExに付加する事によって、根拠をあたえる。暗号鍵KAPｘは外部形式PxExが確かにプロセスPxの結果であることを主張すると同時に、AuthAによる公認された結果でもあることも主張している。あるいは、プロセスPxとAuth Aによる連名の署名として機能すると考えても良い。その2つ目は、プロセスPxの所属を明示することである。これは、本発明の前半で述べた証明書正本副本によって行われる。この証明書正本副本は改ざん偽造が困難なので信頼できる。さらに、KAB[KAPx]によって、証明書正本副本とプロセスPxが確かに対応することが示されている。3つ目は、暗号鍵KAPxを生成する際の認証サーバ AとプロセスPxとの相互認証である。これは、証明書正副間の双方向のリンクによって行われる。（従来技術でも記した通り、プロセスPxにプロセス生成者本人の秘密鍵やパスワードを保持させる事は、危険であって意味を成さない。秘密以外の方式でプロセスPxの認証が可能な方式を開発する必要がある。） 双方向のリンクを持つデータ構造は、そのどちらか一方の所在が確定できれば、他方の所在も確定できる。しかも双方のデータが論理的に同じ物を保持する場合、データの変更は双方のデータの変更を必要とする。従って、そのようなデータのどちらか一方の安全を保障すれば、他方のデータを容易に復元し得る。このようなデータの片方づつを、独立したノードに保持させる事で、ノード間の相互認証が可能となる。ノード間での相互認証が確立すると、Diffie-Hellman方式などによって、ノード間で共通の秘密鍵を生成することが可能となる。４つ目は、認証の権限の移譲である。認証サーバ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）
【００５２】[第６実施形態：各種の攻撃への対処方法]第５の実施形態において、証明書正本副本には改ざん、偽造などさまざまな攻撃が起こり得る、以下ではそれらの攻撃に対する対処方法を概説する。
＜6.1 証明書の偽造に対抗する事＞このように証明書正本副本をリンクによって相互参照させることによって、偽造、改ざん、不正コピーへの対抗が可能となる。通常、不正行為はユーザー環境側で行われるが、ユーザー環境側にて証明書を偽造しても、証明書管理機構側にそのデータに対応する証明書の正本を作成する事が困難なため、偽造である事を容易に検出する事が可能である。(図８参照)＜6.2 証明書の不正コピーに対抗する事＞悪者は、正規の証明書の不正コピーを作り、あたかもそれを正規の証明書であるかのように使用するかもしれない。この場合、正規の証明書の正副には、厳密に一対一対応が形成されているが、不正コピーからは、証明書正に向かう参照があっても、証明書正から証明書副への参照は正規の証明書を指し、不正コピーは参照されないため、証明書管理機構からの問い合わせに矛盾が生じ不正が発覚してしまう。
＜6.3 証明書の改ざんに対抗する事＞悪者は、正規の証明書副を改ざんする場合もある。しかし、証明書正の内容を改ざんすることは困難なので、適当な周期で証明書正と証明書副との照合手続きを実行したり、証明書データを利用する際、事前に照合を行う事で、改ざんの有無を検出する事ができる。また、改ざんを発見したとき、改ざんされた証明書を改ざんされていない証明書に基づいて、正規の証明書へ復元する事も可能である。
＜6.4 ユーザー・プロセスの偽装に対抗する事＞あるユーザー・プロセス（オブジェクト）が所持する正規の証明書副の参照を手に入れ、別のプロセスがそのユーザー・プロセスを偽装するかもしれない。この問題は、セキュリティ・システムとユーザー・システムとの間のインターフェースを工夫し、ユーザー・プロセスと証明書との間も一対一対応を形成させることで解消する。この様子は図６にて示されている。このようなプロセス管理機構を作ると、偽装したプロセスからの要求に対して、その証明書の正本を保持する証明書管理機構からの逆方向の問い合わせに矛盾が生じ、偽装が発覚してしまう。
【００５３】＜第７実施形態：不正検出アルゴリズムへの応用＞不正コピー、偽造、偽装といった不正に対する検出方法は、いずれも証明書正本と証明書副本ならびにプロセス（あるいはオブジェクト）との相互参照が規定通りかどうかを確認するものである。これは以下のような手順にて行う。
プロセスPからの要求に対する手順（最も単純な場合）
第７実施形態では、プロセスをP，プロセスＰの参照をＰ’、証明書正本をO，証明書副本をS、証明書管理機構をAとする。プロセスPの参照から、証明書副本Sの参照、証明書正本Oの参照それぞれを取り出すことが可能である。ここで、プログラム言語的にその参照の同一性を判定できる場合には、証明書副本Ｓが証明書正本OとプロセスＰを参照し、かつ証明書正本Oが証明書副本ＳとプロセスＰを参照していることを確認できれば、認証されたと見なして良い。このような同一性の判定がプログラム的にはサポートされていない場合、次のような手順にて参照の相互関係を確認する。
(1)Ｐから、Ｓを経由してOに対して認証要求コールを送る。
(2)Oは要求コールの戻りとしてＸを戻す。
(3)Oは自分のもつプロセスの参照Ｐ'を使用して先ほど与えた乱数Ｘを戻す事を要求する。
(4)Ｐ'が乱数Ｘを戻した場合、Ｐ'とＰは等しいと見なす。ＰとＰ'とが異なる場合、Ｐ'は乱数Ｘの値を知らないはずである。
(5)ＰからＳを経由して再度Oに対する認証要求コールを送る。
(6)Oは要求コールの戻りとして乱数Ｙを戻す。このとき乱数Ｙは乱数Ｘと異なるものでなくてはならない。
(7)Oは自分のもつプロセスの参照Ｐ'を使用して先ほど与えた乱数Ｙを戻す事を要求する。
(8)Ｐ'が乱数Ｙを戻した場合、Ｐ'とＰは等しいと見なし、認証されたものとする。
ここでは、(1)から(4)にかけての手順と(5)から(8)にかけての手順のように、確認手順を２回行ったが、この回数は多ければ多いほど認証の確実性が向上する。最低２回は行う必要がある。
【００５４】＜第８実施形態：証明書副本からの要求に対する証明書正副同士の確認手順＞上とほぼ同様な手順にて、証明書副本の偽造、不正コピーの検出も可能である。以下にその手順の最初の4項を示す。これも2回以上繰り返す必要がある。ここでも、プロセスをP，プロセスＰの参照をＰ’、証明書正本をO，証明書副本をS、証明書管理機構をAとする。
(1)ＳからOに対して認証要求コールを送る。
(2)Oは要求コールの戻りとして乱数Ｘを戻す。
(3)Oは、自分の（証明書副本Ｓ自身の）もつ証明書副本Ｓの参照S'を使用して先ほど与えた乱数Ｘを戻す事を要求する。
(4)S'が乱数Ｘを戻した場合、S'とSは等しいと見なす。SとS'とが異なる場合、S'は乱数Ｘの値を知らないはずである。
上記のアルゴリズムによる認証には、認証対象となるプロセスやオブジェクトからの要求を受けた際のみに有効な認証手順である。さらに、複数の証明書管理機構の関与も考慮にはいれていない。そこで、複数の証明書管理機構の関与する場合で、認証側が認証対象オブジェクトに対して、主体的に実施する認証手順を以下に記述する。この際、少なくとも同一環境内におけるオブジェクトの参照は、リモート参照、ローカル参照の区別なく参照同士の一致不一致を検出する手続きが存在することを仮定する。
【００５５】＜第９実施形態：複数の証明書管理機構が関与する場合の応用例：認証側が認証対象のオブジェクトに対して主体的に実施する認証手順＞この認証手順として、次の３つの場合を検討する。手順1は証明書管理機構AがプロセスPの参照を得て、Pの認証を行う場合であり、手順2は、プロセスP1がプロセスP2の参照を得てP2の認証を行う場合であり、手順3はプロセスP1がプロセスP2からの要求を受け、P2を認証する場合である。
＜認証手順１：証明書管理機構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に認証の失敗を通知する。
【００５６】＜認証手順2：プロセスP1がプロセスP2の参照を得てP2の認証を行う場合＞(1) P1は自分の所属するドメインの証明書管理機構に対してP2を渡して上の手順１「証明書管理機構AがプロセスPの参照を得て、Pの認証を行う手順」を実施する。
【００５７】＜認証手順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に認証の成功、失敗のいずれかを通知する。
【００５８】注意1、上のO2とS2との照合は次のように行う。
(1)O2とS2との対応する項目の一致不一致を確認することで、内容面での改ざんの有無を調べる。
(2)改ざんされていないことが確認できた場合、O2から副本S2'への参照を取り出し、S2'とS2との一致を確認する。
注意2、上述の手順で、認証要求を発する側は、可能ならば、プロセスの参照、プロセスが保持している副本の参照、副本が保持している正本の参照の3組をあらかじめ取り出し、その3組の整合性を確認するようにし、副本に保持されている正本の参照の利用をなるべく避ける方向で実装するほうがよい。それは、実際には誤った正本の参照が書き込まれているにもかかわらず、処理直前に一時的に正しい正本の参照を与えることで、認証を通過させ、認証後にまた誤った正本の参照を再設定することにより、プロセスに誤った正本を信用させる不正が可能なためである。
【００５９】＜第９実施形態：不正検出アルゴリズムの限界とその対策＞第８実施形態のアルゴリズムの限界は、プロセスＰとプロセスの参照Ｐ'とが異なるプロセスでありながら、裏で繋がっている場合、バケツリレー式の偽装が可能になってしまうことである。裏でつながっている場合とは、公認されたプロセスＰ'自体が不正なプロセスＰと共謀した場合である。しかし、この場合は、責任は公認されたプロセスＰ’自身にある。プロセスＰ'自身の秘密を教えることに危機を招いた責任があるからである。この場合は、公認プロセスＰ’が不正プロセスＰから乱数Ｘ、Ｙの値を教えてもらい、公認プロセスＰ'自身が不正プロセスＰのふりをすることにもなる。このような、プロセスの偽装を見破るには、実行環境レベルのプロセス管理情報を利用するとよい。証明書正副にプロセスidを参照以外に登録し、プロセスの参照Pをプロセス管理情報に渡して、そのプロセスidを受け取り、証明書内のidと一致／不一致を確認すればよい。これらは、OSや実行環境に依存する実装上の詳細事項である。
【００６０】＜第１０実施形態：オブジェクト間の参照方式の変形＞参照方式には、基礎となるシステムに応じて、幾つかの変形が発生する。証明書同士や証明書とプロセスを結合する参照は、分散オブジェクト・システム上では、オブジェクトのローカルな参照もしくは、リモート・オブジェクトの参照となる。ローカルな参照は参照する側とされる側のオブジェクトがともに同一環境内に位置する場合に使用される。２つのオブジェクトが異なる環境に置かれている場合、その参照はリモート・オブジェクトの参照になる。ローカルな参照が使われる場合、参照されるオブジェクトの（ローカルな）メソッドを呼出す事ができ、リモートの参照が使用される場合には、参照されるオブジェクトに対して、リモート・メソッド呼出し（Remote Method Invocation）が可能である。第７実施形態で述べた「不正検出アルゴリズム」は基本的にはこのようなオブジェクト同士の参照を利用した、ローカルまたはリモートのメソッド呼出しによって実施されることを想定している。オブジェクト指向技術を使用していないシステム上でも「不正検出アルゴリズム」の各手順は次のように実施することが可能である。証明書やプロセス管理データを定められたデータ構造をもつデータ・ブロックとして実装する。これらのデータ・ブロックを互いに識別するために、各ブロックごとに一意の識別子をあたえる。この識別子はユニークな数値や文字列など他と明確に区別可能な任意の型のデータであってよい。サーバー・プログラムなどこれらのデータ・ブロックが置かれている場を環境と呼ぶ事にすると、これらの識別子は、同一環境内では、一意性を保証する必要がある。これらの識別子に加えて、証明書やプロセス管理用のデータが所属する環境と通信するための通信制御用の識別情報も識別子と合わせてデータ・ブロックに保持させる。通信制御用の識別情報には、例えばホスト名、ipアドレス、ソケット番号、ポート番号など、基礎となる通信システムに応じてさまざまなものがある。この（識別子：通信制御用識別情報）の組がオブジェクト間の参照に対応する。
【００６１】このとき、リモート・メソッド呼出しに対応する手続きの呼出しは次の通りである。呼出しの往路は、通信制御用識別情報によって定められる相手側環境に対して、処理要求内容を示すコマンド・コードと操作対象となるデータ・ブロックの識別子、そして操作に必要となる任意のパラメータ情報をメッセージとして送信することである。呼出しの処理本体の実行は、上記のメッセージを受け取った環境側が、識別子で指定される操作対象に、コマンド・コードとパラメータに従った処理を実施する事である。この処理の実施で得られる情報を応答メッセージとして環境から送信元へもどすことが、呼出しの復路に対応する。システムによっては、この一連の操作をRPC（Remote Procedure Call：遠隔手続き呼出し）によって、通常の手続き呼出しのような外観にて実施する事が可能である。このように、上記の手順はオブジェクト指向のシステムでなくとも、通信回線その他によって互いに交信可能な系同士であれば実施可能である。
【００６２】＜第１１実施形態：証明書とユーザー・オブジェクトとの一体化＞セキュリティ機構がOSや実行環境に標準的に装備されている環境などでは、ユーザー・オブジェクトやプロセスに証明書を直接埋め込むことも考えられる。(図１１参照)（オブジェクト指向言語を使用する場合、ユーザー・オブジェクトのクラスを証明書オブジェクトのサブ・クラス等として実現することになる。）この場合でも証明書とユーザー・オブジェクトは一対一に対応するので、これは図6のような参照によってユーザー・オブジェクトとの対応付けを行う仕組みの変形であると考えられる。この長所は、参照等を改変される心配が無くなるため、外部からの攻撃に強くなり、また認証時の処理も証明書の真正性の確認だけで済む点にある。また、オペレーティング・システムの核などに本証明書方式を組み込む場合、プロセス管理ブロックとかタスク管理ブロックなどとよばれる、実行制御の対象となるプロセスを、管理するデータ構造の一部として、本証明書に使用することも可能である。この場合は、ちょうど図１１のケースと図6のケースの中間にあたる変形であると考えられる。
【００６３】＜第１２実施形態：証明書管理機構自体の偽装への対抗＞これまでは、証明書の正本と副本のいずれかは信頼できるということを暗黙の仮定としてきた。しかし、副本が改ざんされ、副本が参照している正本も本来の証明書管理機構とは異なるニセの証明書管理機構上に作られている場合も考慮する必要がある。この場合、本来の副本が改ざんされたのか、それとも全くの偽造なのかの区別が必要である。この問題に対処する際、副本が正しい正本を参照していると仮定することはできない。ただし、最低限の前提として、本来の証明書管理機構上には、正規の正本が存在していることは前提とする。（逆に、ユーザー側のシステム上に正規の副本があると仮定してもほぼ同じ手法で対策を立てる事ができる。）さらに、セキュリティ・ドメイン上に認証者（Authenticator）が存在する事を前提とする。認証者はセキュリティ・ドメイン上における正規の証明書管理機構の所在を管理する。また、プロセスが所属するドメインの認証者への参照は、プロセスが実行されているユーザー環境に置かれているセキュリティ管理機構やオペレーティング・システム呼出し等のあらかじめ定められたインターフェースを介して取得されるものとする。このことによって、証明書の真正性に依存する事無く、プロセスの所属するドメインに対応する認証者への要求を発する事が可能である。ユーザー環境が正規のドメインに所属している場合、正規の認証者が必ず参照される。正規の認証者は正規の証明書管理機構の所在が分かる。従って、証明書の正本の参照に対して、当該参照に対応する証明書が実在するかどうかを、証明書管理機構自体が内部で管理している証明書表などに基づいて、確認する事が可能である。証明書正本の真正性をこのように確定できるので、それを使用して証明書副の真正性の確定が可能である。
【００６４】一方、ユーザー環境が正規のドメインに所属していない場合、正規の認証者が参照されるという保証はない。正規の認証者の参照が得られる場合、上記の手順で証明書副の真正性の確認が得られる。正規の認証者の参照が得られない場合、その認証者は、ニセの証明書管理機構を使用し、嘘の認証を行うかもしれない。認証者がニセの証明書管理機構を与えたとしても、認証の確認が外部にある正規のドメインの要求で行われている場合、そのドメインの証明書管理機構と認証者が与えた証明書管理機構との相互認証を行う事で、ニセの証明書管理機構を見破る事が可能である。認証の確認が外部のドメインからではない場合、認証は行われるが、そのドメインの外には認証結果の効力が及ばない。従って、外部にある正規のドメインには影響を与えない。
【００６５】上の記述を明確化することで、以下に述べる証明書の偽装ならびに改ざんに対抗する手順が得られる。この際の少なくとも、同一環境内におけるオブジェクトの参照に関してリモート参照、ローカル参照の区別なく参照同士の一致不一致を検出する手続きが存在することを前提とする。
【００６６】＜偽装ならびに改ざんへの対抗手順＞ここでは、証明書副本をS、正本をO、認証者をAu、証明書管理機構をAとする。
(ステップ１：正規の正本Oの参照を獲得する。)(1) 副本Sは認証者Auに対して証明書管理機構Ａの問い合わせを行う。
(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は自分が偽造されていると判断する。
（ステップ２:正本と副本の照合ならびに修正を行う。)(1) Sは、自分の持つ各項目と対応するOの項目とを比較する。ある項目が一致しない場合その項目をOの項目で置きかえる。
【００６７】＜第１３実施形態：証明書管理機構A、B間の協議手順の詳細＞前述した第５実施形態(3)の「AとＢとの協議」によって暗号鍵KABを生成する手順については、A,B間の認証方式に応じてさまざまな方式が考えられる。以下にいくつかの例を提示する。
例１．秘密鍵KCを証明書管理機構A,B間で共有し、暗号鍵KABを証明書管理機構B側で生成する方式。
(1)AからBへKABの生成要求を発する。
(2)BからAに乱数R1をチャレンジとして送る。
(3)Aは、R1の末尾に０を連結したものを秘密鍵KCで暗号化したKC[R1|0]と、さらにBに対するチャレンジとして乱数R2をBに送る。
(4)BはR2の末尾に１を連結したものを秘密鍵KCで暗号化したKC[R2|1]をAに送る。さらに、Bは、適当な乱数を発生させてKABとし、それをKCで暗号化したKC[KAB]と、KABを利用した通信セッションを識別するためのセッションidとを、Aに送る。
(5)AからBに、KABの受理の確認を行う。たとえば、Aは、セッションidと日付を連結させたメッセージをKABで暗号化したKAB[セッションid｜日付]をBに送ってもよい。
【００６８】例２．秘密鍵KCをA,B間で共有し、KAB生成にDiffie-Hellman鍵交換方式を使用する方式。ここでｐを素数、ｇをある整定数。modを法演算とする。このｐとｇとは事前に合意してあってもよいし、一方から他方へ通知してもよい。このとき関数P(x)をP(x)=ｇx mod pによって定める。
(1)AからBへ暗号鍵KABの生成要求を発する。
(2)BからAに乱数R1をチャレンジとして送る。
(3)Aは、R1の末尾に０を連結したものをKCで暗号化したKC[R1|0]と、Bに対するチャレンジとしての乱数R2と、秘密の数RAを発生させて法関数とした関数P(RA)とを、Bに送る。
(4)Bは、R2の末尾に１を連結したものを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に送ってもよい。
【００６９】例３． 秘密鍵KCをA,B間で共有し、KCを暗号鍵KABとする方式。この方式は認証者にKCを知らせる等KCのセキュリティに問題があるが、効率的である。
(1)AからBへセッションid生成要求を発する。
(2)BからAに乱数R1をチャレンジとして送る。
(3)Aは、R1の末尾に０を連結したものをKCで暗号化したKC[R1|0]と、Bに対するチャレンジとして乱数R2とを、Bに送る。
(4)Bは、R2の末尾に１を連結したものをKCで暗号化したKC[R2|1]と、通信セッションを識別するためのセッションidとを、Aに送る。
(5)AからBに、セッションidの受理の確認を行う。この場合、単にACK（？）を送るだけでもよい。
【００７０】例４． A,B間は公開鍵暗号方式による署名によって認証を行う方式。この場合、KABはDiffie-Hellman鍵交換方式を利用して生成するとよい。ここでｐを素数、ｇをある整定数。modを法演算とする。このｐとｇとは事前に合意してあってもよいし、一方から他方へ通知してもよい。このとき関数P(x)をP(x)=ｇx 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 mod p が暗号鍵KABとなる。さらに、乱数R1を発生させKAB[R1]をチャレンジとしてBからAに送る。またセッションidを生成しそれもBからAに送る。
(4)AはR1の末尾に１を連結したものをKABで暗号化したKAB[R1|1]をBに送る。
【００７１】例５．A,B間は公開鍵暗号方式による暗号化によって認証を行う方式。この場合、暗号鍵KABはDiffie-Hellman鍵交換方式を利用して生成するとよい。ここでｐを素数、ｇをある整定数。modを法演算とする。このｐとｇとは事前に合意してあってもよいし、一方から他方へ通知してもよい。このとき関数P(x)をP(x)=ｇx 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の末尾に１を連結したものをKABで暗号化したKAB[R1|1]をBに送る。
【００７２】＜第１４実施形態：証明書を応用したプロセス移動方式の変形＞第１３実施形態の例３ではA、B間での共通鍵KABとしてAとBとが相互認証のために元々合意していた鍵KCを利用していた。この例では、セッションidを確定する都合上A,B間では協議の手順が実行されていたが、共通鍵KABとして無条件にKCを使用し、セッションidの設定も省略してしまうとA,B間の協議のステップ自体を省略する事もできる。この方式は、第１３実施形態の例３で述べた方式の変形であると考えられるが、きわめて効率的である反面、KCが破られる危険があること、以前に処理されたKAPx[PxEx]、KC[O]、KC[KAPx]からなる転送メッセージをそっくり複写したものを認証者に与えると、認証者が受理してしまう恐れがあることなどの欠点をもつ。そのため、KCを適当な周期で更新するとか、Pxからのメッセージにはタイムスタンプを連結して暗号化するなどの処置が必要である。またこの手順は、Kerberos認証システムで使用されている認証手順にも類似しているが、Kerberosシステムは人物など動かない対象の認証システムであるのに対し、本方式はプロセスのような処理にともなって内容が変化するデータに対する認証ならびに移動の手順であること、さらに証明書もこの移動にともなって認証機関の間を移動していく事など、Kerberosシステムとは目的や手法が大きく異なる。
【００７３】この変形方式の手順を以下に示す。ここで、プロセスPxがドメインａからドメインbへ移動するケースを考える。ここでサーバーA、B、Cは証明書管理機構として機能し、各ドメインの認証機構をそれぞれAuthA、AuthB、AuthCとする。サーバーAとサーバーBとの間にはあらかじめ暗号鍵KCについての合意がある。
(1)プロセスPxは認証機構AuthAにドメインａからドメインbへ移動したいという要求を送る。
(2)サーバーAとPxとの相互認証を行う。この際、ドメインaの認証者によるAの認証と、第７実施形態の「不正検出アルゴリズム」によるPxの認証が行われる。
(3)PxとAuthAは一時的な暗号鍵KAPxを生成する。KAPxの合意は、たとえば、Diffie-Hellmanの鍵交換法を使用して行われる。
(4)AuthAは証明書正本OをKCで暗号化しKC[O]を作る。また、KAPxもKCで暗号化し、KC[KAPx]を作る。そしてそれを、Pxに送る。（OとKAPxとを連結してKCで暗号化し、KC[O|KAPx]を作っても良い。）
(5)プロセスPxは自分自身の外部形式PxExを作り、それをKAPxで暗号化しKAPx[PxEx]とする。（ここで、KAPx[PxEx]はPxExの全面的な暗号化ではなくKAPxを利用したメッセージ・ダイジェスト値をPxExに付加したものであっても良い。たとえば、PxExの文頭もしくは文末にKAPxを連結し、それに対してメッセージ・ダイジェスト関数を適用する。このようにして求まったメッセージ・ダイジェスト値とPxExをまとめて送付しても良い。）
(6)プロセスPxはドメインbの認証機構AuthBに、KAPx[PxEx]、 KC[KAPx]、 KC[O]を送り、プロセスの移動を申請する。
(7)AuthBはKCをあらかじめ知っているので、KC[O]から証明書Oを再生し、KC[KAPx]からKAPxを再生することができる。そして、KAPxを使用して、KAPx[PxEx]からPxExを再生することができる。
(8)KAPxはこの転送サイクルにおいてPxとAuthAしか知り得ない秘密であり、KC[KAPx]にKAPxがあることは、AuthAしか知り得ない。従って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にそれぞれ置換えてこの手順を実行すれば良い。
【００７４】注意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：応用上、プロセスの送信元実行環境と受け入れ側実行環境との相互認証が別途必要となる場合もある。ただし、これは、移動時のプロセスに対する認証とは別の手順である。
【００７５】＜第１５実施形態：セキュリティ・ドメイン内でのプロセス移動に関する方式の変形＞第１２実施形態、第１４実施形態での方式は異なるセキュリティドメインa、b間をプロセスが移動する際の、証明書を利用したプロセスの認証ならびに移動、そして証明書も証明書管理機構AからBに移動させる場合の方式であった。プロセスはこのような異なるセキュリティ・ドメインへの移動に限らず同じセキュリティ・ドメイン内での異なる実行環境間を移動する場合もあり得る。この場合、方式はより単純化した形へ変形される。もっとも単純な場合は、移動のセッションを識別するセッションidだけを割り付け、プロセスの外部形式を生成したのち、その外部形式にセッションidを付加して移動先の環境に送付する方式である。その方式よりも多少セキュリティに配慮した変形を以下に示す。この方式は、同一セキュリティ・ドメイン内の移動の方式としても捕らえる事ができるのみならず、ローカル・エリア・ネットワークなどに単一の証明書管理機構を設置した小規模なネットワーク環境内だけで移動プロセスを使用する場合の標準的な移動手順としても捕らえる事ができる。ここでは、プロセスPxがドメインａ内の環境E1からE2へ移動するケースを考える。
【００７６】ここでサーバー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[PxEx]はPxExの全面的な暗号化ではなくKAPxを利用したメッセージ・ダイジェスト値をPxExに付加したものであっても良い。たとえば、PxExの文頭もしくは文末にKAPxを連結し、それに対してメッセージ・ダイジェスト関数を適用する。このようにして求まったメッセージ・ダイジェスト値とPxExをまとめて送付しても良い。）
(5)プロセスPxはドメインaの認証者AuthAにKAPx[PxEx]、を送り、プロセスのE2への移動を申請する。
(6)AuthAは、Pxと共有しているKAPxを使用して、KAPx[PxEx]からPxExを再生することができる。KAPxはこの転送サイクルにおいてPxとAuthAしか知り得ない秘密である。従ってPxExが正常に解読できた事を持ってPxがAuthAによって認証されたプロセスであることが確認できる。
(7)AuthAは、サーバーA内に保管されていたPxの証明書Oに対応する副本Sを生成する。PxExから実行形式Pxを再生し、O, S, Px間の対応を形成しPxの実行を許可する。
【００７７】注意1：上記手順の第3項にて行われる共有鍵KAPxの生成は、Px、AuthA間にて行われるが、KAPxの安全性に配慮するならば、AuthAの範囲を一層限定して、PxとAuthA内のサーバーAとの間で行われるほうが、望ましい。ただし、実装上の選択として、効率性、負荷分散の観点から別の鍵管理機構などをAuthA内に設置して、そことPxとの間でKAPxを生成することも考えられる。
注意2：上記手順の第7項にて、転送元にある証明書副本Sの無効処置が必要となる。これをどの時点に実施するかは本方式の具体的な実装に依存する。逆に、無効処置を行わない場合、本手順は、プロセスを実行環境へ複写する手順として利用可能である。この場合、相手先認証機構は、証明書を生成する際、複写としての証明書正本を新たに割り付ける必要がある。
注意3：応用上、実行環境E1、E2の相互認証が別途必要となる場合もある。ただし、これは、移動時のプロセスに対する認証とは別の手順である。
【００７８】＜第１６実施形態：証明書付きのプロセスの保存方式＞第１４実施形態の[証明書を応用したプロセス移動方式] を変形することによって、証明書付きのプロセスを保存する方式が得られる。通信回線等で結ばれた処理系内では障害等によってデータが失われる場合がある。従ってデータの破損や喪失への対策としてこのようなプロセスの保存方式が要求される。この手順は、プロセス移動手順と併用する事が可能である。以下は第１２実施形態の手順に基づく保存法式であるが、第１４実施形態の移動方式の変形、第１５実施形態の移動方式の変形に対しても同様にして対応する保存方式が得られる。
【００７９】この手順の概略は次の通りである。ここで、プロセスPxがドメインａからドメインbへ移動する場合、ドメインbにてプロセスを保存するケースを考える。ここでサーバーA、B、Cは証明書管理機構として機能し、各ドメインの認証機構をそれぞれAuthA、AuthB、AuthCとする。
(1)PxはAuthAにドメインbへ移動したいという要求を送る。
(2)サーバーAとPxとの相互認証を行う。この際、ドメインaの認証者によるAの認証と、すでに述べた「不正検出アルゴリズム」によるPxの認証が行われる。
(3)サーバーAはサーバーBと協議を行い暗号鍵KABを用意する。この手順の詳細は第１３実施形態の説明を援用する。
(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[PxEx]はPxExの全面的な暗号化ではなくKAPxを利用したメッセージ・ダイジェスト値をPxExに付加したものであっても良い。たとえば、PxExの文頭もしくは文末にKAPxを連結し、それに対してメッセージ・ダイジェスト関数を適用する。このようにして求まったメッセージ・ダイジェスト値とPxExをまとめて送付しても良い。）
(7)プロセスPxはドメインbの認証機構AuthBに、KAPx[PxEx]、 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があることは、AuthAしか知り得ない。従ってPxExが正常に解読できた事を持ってPxがAuthAによって認証されたプロセスであることが確認できる。
(10) AuthBは、この事実を持ってサーバーB内に証明書正本Oを割り付ける。その際、KAPxとプロセスのバックアップ名を正本に対応付けてサーバーB内に保存する。そして、プロセスのバックアップ名とKAPx[PxEx]を対応付けて不揮発性記憶媒体に書き込む。この際、宛先実行環境の識別などプロセスの再開に必要となる情報も合わせて記録する。これらの情報は、証明書正本Oに保持させる事も可能であるが、これらは、本手順の実装に依存する。
【００８０】注意1：上記手順(4)にて行われる共有鍵KAPxの生成は、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項以降も互いに矛盾するものではない。従って、第５実施形態の方式を使用してプロセスを移動させる際、プロセスの保存を並行して行う事が可能である。上記の手順によって保存されたプロセスを再生させる際に、2通りの場合が考えられる。一方は、そのプロセスの証明書副本がすでに存在し、その証明書副本に対応するプロセスを復旧させる場合である。他方は証明書の副本がまだ割り付けられていないか、プロセスが副本も含めて失われてしまった場合である。
【００８１】[プロセスの復旧：副本が存在する場合](1)認証機構は、副本の真正性を確認する。
(2)真正性が確かめられたならば、正本に対応付けられたプロセスのバックアップ名と暗号鍵KAPxを取り出す。
(3)バックアップ名に対応したKAPx[PxEx]を読み込む。
(4)KAPx[PxEx]をKAPxで解読し、PxExを取り出し。それからPxを割り付ける。
【００８２】[プロセスの復旧：副本が存在しない場合]この場合、そもそもどのプロセスを復旧させるのかを決定しなくてはならない。そのためには、1)証明書管理機構内の正本すべてをしらみつぶしに調べ、すべての副本についてその存在の問い合わせを行う、2)常時適当な周期で、少しずつ、証明書管理機構内の正本に対応する副本の問い合わせをしておく、などが必要である。いずれかの方法で副本の消滅が確認された場合、証明書管理機構側が認証者に副本が存在していない証明書正本の情報を伝える。以後次の手順によって復旧を行う。
(1)認証機構は、正本に対応付けられたプロセスのバックアップ名と暗号鍵KAPxを取り出す。
(2)バックアップ名に対応したKAPx[PxEx]を読み込む。
(3)KAPx[PxEx]をKAPxで解読し、PxExを取り出す。証明書正本に基づき証明書副本Sと、プロセスPxを割り付ける。
【００８３】本方式は移動可能プロセス移動時のバックアップと復旧の方式であるが、移動時に認証機構に渡す要求に適当なオプションや異なる要求を与える事によって、プロセスの保存だけを行って、プロセスの実行を延期させることも、ほぼ同様な手順で可能である。この場合、証明書管理機構に割り付ける証明書正本に再開時刻等を含めた実行延期を示す情報を対応させる等の処置を行う。
【００８４】＜第１７実施形態：プロセスの違法コピーへの対処方法＞第５実施形態、第１４実施形態、第１５実施形態に示したプロセス移動方法、および第１６実施形態節にて示したプロセスの保存方法において、認証機構とプロセスとの間で共有暗号鍵KAPxを定めた直後に、プロセスの複写を行うと、複写されたプロセスと共に共有鍵KAPxが奪われてしまう恐れがある。この第１７実施形態では、第５実施形態での記号を流用する。本手順では、証明書正本のデータが、正規の証明書副本に渡る事が保証されている。しかし、何らかの方法で悪者によって、暗号化された正本KAB[O]、暗号化された共有鍵KAB[KAPx]などの情報を傍受されると、違法にコピーされたプロセスを通じて、贋のプロセスPyの外部形式PyExを共有鍵KAPxによって暗号化したKAPx[PyEx]に盗み出したKAB[O]、KAB[KAPx]などの情報を添付して、相手先の認証機構に送付する事によって、贋のプロセスが証明書正本を奪う恐れがある。
【００８５】このような違法コピーに対する対処には次の2通りの方法が考えられる。
方法1) 相手先認証機構で、KAB[O]などの暗号化された正本、KAB[KAPx]などの暗号化された共有鍵、KAPx[PxEx]など暗号化されたプロセスの受信時に送信元を「不正検出アルゴリズム」を使用して認証する。
方法2）正規のプロセスの外部形式に関するメッセージ・ダイジェスト関数値を自ドメインの認証機構にあらかじめ教えておき、暗号化された正本に添付してもらう。これらの、対処方法を手順に組み込む際には、組み込みに伴う処理上のオーバヘッドと、プロセス・コピーの現実的な可能性、および、認証機構から送られる、暗号化された正本や、暗号化された共有鍵の傍受の現実的な可能性を勘案する必要がある。
【００８６】以下では、第５実施形態の手順に上記の方法2）の手順を加えたものを示す事にする。なお、第５実施形態の手順の後に記されている注記は本手順でも内容上対応する項目に適合する。また、第1４，１５，１６実施形態の手順でも、ほぼ同様な変更を加える事ができる。第５実施形態と同様に、Pxがドメインａからドメインbへ移動するケースを考える。ここでサーバーA、B、Cは証明書管理機構として機能し、各ドメインの認証機構をそれぞれAuthA、AuthB、AuthCとする。
【００８７】手順：上記方法2)を適用した場合。ここでは、SHA(x)やMD5(x)などのメッセージ・ダイジェスト関数をHASH(x)とする。
(1) PxはAuthAにドメインbへ移動したいという要求を送る。Pxはこの時点で、Pxの外部形式PxExとPxExのメッセージ・ダイジェスト関数値HASH(PxEx)を計算しこれをHashPxとする。
(2) サーバーAとPxは相互認証を行う。この際、ドメインaの認証者によるAの認証と、すでに述べた「不正検出アルゴリズム」によるPxの認証が行われる。
(3) PxはAuthAにHashPxを送る。（Pxは、AuthAの要求の答えとしてHashPxを返しても良い。）
(4) サーバーAはサーバーBと協議を行い暗号鍵KABを用意する。この手順については、第1６実施形態の説明を援用する。
(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を連結し、それに対してメッセージ・ダイジェスト関数を適用する。このようにして求まったメッセージ・ダイジェスト値とPxExをまとめて送付しても良い。）
(8) プロセスPxはドメインbの認証機構AuthBにKAPx[PxEx]、 KAB[KAPx]、 KAB[O]、KAB[HashPx]を送り、プロセスの移動を申請する。
(9) AuthBは、手順4にて決定したKABを用いて、KAB[O]から証明書Oを再生し、KAB[KAPx]からKAPxを再生することができ、さらに、HashPxの再生ができる。そして、KAPxを使用して、KAPx[PxEx]からPxExを再生することができる。
(10) AuthBはPxExのメッセージ・ダイジェスト関数値HASH(PxEx)を計算し、これが、HashPxと一致する事を確認する。もしも、一致しない場合には手順をこの時点にて打ち切る。
(11) KAPxはこの転送サイクルにおいて、原則として、Pxと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のコピーをとるなどしても、PxEx以外のプロセスの外部形式を送る事は難しい。また、この手順は、PxExの転送中におけるデータの欠落の有無や、改ざんの有無の確認にもなる。この性質ゆえに、方法2)の方が応用上安全である。なぜなら、共有鍵KAPxがプロセスのコピーによって流出することを想定すると、Pxが送信しようとするPxExの改ざんにも対処する必要がある。方法2)は、PxExの改ざんを検出する事が可能である。改ざんが発見された場合、Pxは相手先からのエラー・コードなどを受け、もう一度手順の先頭からやり直す事ができる。
【００８８】＜第１８実施形態：証明書による認証方法の変形＞これまでのところでは、プロセス（またはオブジェクト）Pxと証明書管理機構Aとの間に２重の証明書を用意し、その参照が一意的に定まることを利用してプロセスＰｘと証明書管理機構Ａとの相互認証を与える方法について記してきた。この方法の変形例として、最初にプロセスＰｘと証明書管理機構Ａとの間の認証を2重の証明書によって行い、認証が行われた時点でプロセスＰｘと証明書管理機構Ａとの間で共通の秘密を設定し（例えばDiffie-Hellmanの鍵交換方式などを使用する）、以後の認証をその共通の秘密によって行うことも考えられる。
【００８９】この方法は、プロセスＰｘを共通の秘密とともに複写して生成されたプロセスＰｙを容易に作る事ができ、プロセスＰｘと異なるプロセスPyがその秘密を保持することが可能なため、認証効果は低い。しかし、プロセスＰｘと証明書管理機構Ａとで適当な周期で共通の秘密を更新する事によってある程度、複写の問題に対抗する事も可能である。この方式の良さは、プロセスＰｘと証明書管理機構Ａとの間の認証に従来から行われている秘密情報に基づく認証方法が適用可能な点である。また、さらなる変形例として、証明書正本と証明書副本との間に共通の秘密を設定し、証明書正副間の不正検出を、この秘密を知っているかどうかによって行う方法も考えられる。この共通の秘密の設定に際して、Diffie-Hellman法を使用する場合、証明書間の相互認証が必要なので、最低一回は、参照を利用した、前述の不正検出アルゴリズムを使用して、相手の確認を行うことが必要である。
【００９０】この場合、図１３に示すように、証明書内に共通の秘密を置かずに、証明書を管理するオブジェクトもしくはデータ構造内に、配列やハッシュ・テーブルを置き、その配列またはハッシュテーブルにて証明書と秘密との対応付けを行い、配列やハッシュ・テーブルに対する外部からのアクセスに制限を設ける事で秘密の安全性を、ある程度、確保することが可能である。この方法では、そのように管理される秘密に対して、証明書からどのようにアクセスを許すのかが、問題となる。オブジェクト指向言語の中には、変数の参照制限機能や、一度定義されたメソッドの上書きの禁止を行う機能が提供されているものがある。そのような、プログラミング言語を使用すると、秘密を管理する配列やハッシュ・テーブルに対する外部からの参照を制限し、秘密へのアクセス・メソッドを上書き禁止にすることで安全なアクセスが可能になる。また、上記の２つの方法を折衷し、プロセスと認証サーバーとの間に設定される共通の秘密を、プロセス自体に保持させずに、証明書管理オブジェクト内のハッシュ・テーブル等に証明書と対応させて保持させることも考えられる。そこで、このような共通の秘密の生成例をDiffie-Hellman鍵交換方式によって行う場合を以下に説明する。
【００９１】ここでｐを素数、ｇをある整定数。modを法演算とする。このｐとｇとは事前に合意してあってもよいし、一方から他方へ通知してもよい。このとき関数P(x)をP(x)=ｇx mod p によって定める。すると、次のような手順で行うと、共通鍵をプロセスも含め、外部に一切漏らさずに生成することができる。ここで、プロセスをPx、認証サーバーを証明書管理機構Ａとする。また、証明書管理オブジェクトをCOとする。COはプロセスＰｘと証明書管理機構Ａとのプロキシーとして機能し、上記の定数g、pを知っていると仮定する。以下では記述を簡単にするために、プロセスと証明書との対応チェックを省略しているが、実装時にはそのようなチェックを行うべきである。
【００９２】(1)プロセスＰｘから証明書管理機構Ａへ共通鍵生成要求をCO経由で発する。このとき秘密の数Rxを生成し、その要求のパラメータとして付加する。
(2)制御を受け取ったCOはRxの値をプロセスＰｘに対応する証明書副本の秘密の値として管理し、証明書管理機構Ａに対するパラメータをRxからP(Rx)に置換えて、メソッド呼出しを証明書管理機構Ａに中継する。
(3)証明書管理機構Ａは、秘密の数Raを生成する。そしてP(Ra)を計算し、CO経由のプロセスＰｘの戻り値としてP(Ra)を戻す。このとき、P(Rx・Ra)=gRx・Ra mod p = P(Rx)Ra mod p = P(Ra)Rx mod p が共通の秘密となる。
(4)証明書管理機構Ａからの戻り値P(Ra)を受け取ったCOは、その値と、管理しているRxを利用して、P(Rx・Ra)= P(Ra)Rx mod pを計算し、P(Rx・Ra)をプロセスＰｘに対応する証明書副本の秘密の値として管理する。プロセスＰｘには単に、共通秘密生成の成功通知だけを戻す。
【００９３】この方法を変数やメソッドのアクセス制限機能のあるオブジェクト指向言語などで実装すれば、プロセスの違法コピー等による秘密の漏洩を防止する効果があり、さらに、プロセス転送手順にて必要とされる共通秘密鍵の一時的な保存方式としても効果的である。ただし、このような工夫で保証されている安全性は、証明書COを経由してアクセスされているという事実のみであることに注意するべきである。贋のプロセスがCOの参照を利用して、隠された秘密を利用する恐れは、依然残っている。また、これは実装上の工夫というべきであるが、証明書管理オブジェクトの安全が保障されている場合、図１３の秘密情報の位置に、証明書副本に対しては、証明書正本への参照を置き、正本に対しては、副本への参照を置くようにし、証明書自体には互いの参照を置かないようにすることも考えられる。このように、参照の管理を証明書自体と分離する事により、証明書が違法にコピーされた場合を考慮して行われる、証明書間の煩雑な参照確認手順を簡略化することが可能となる。このような管理方式を使用すると、証明書を違法にコピーしても、対応するもう片方の証明書への参照が得られないので、証明書を利用した認証手順の早期の段階で不正を見破る事ができる。ただし、この方法も、証明書管理オブジェクトが安全であることが、前提である。
【００９４】逆に、証明書間の参照や秘密情報と証明書自体を分離するこれらの方法は、証明書管理オブジェクトが充分安全で、しかも定期的なバックアップや信頼できるホスト内にレプリカを保持するなどのシステム・クラッシュ時の情報復旧対策が取られている場合、本証明書方式を利用したシステムのフォールト・トーレラント性を高める手段ともなり得る。
【００９５】＜証明書方式の応用＞このような証明書の最も直接的な応用は、CORBA分散オブジェクト・システムの部分系であるCORBAセキュリティ・サービスでサポートされているクレデンシャル（Credential:信任状）として使用するか、もしくはその補助データとして使用する事である。CORBAセキュリティ・サービスにおけるクレデンシャルは、認証されたオブジェクトに対応付けられオブジェクトの発するリモート・メソッド呼出し時の呼出し元プリンシパルの照会に使用されたり、オブジェクトに対して設定されるセキュリティ属性の保持、ならびにそのセキュリティ属性に従って他のオブジェクトに対するアクセス許可の決定などに使用される。
【００９６】しかし、CORBAセキュリティ・サービスでは、オブジェクトのカレント・スレッドに対しては、クレデンシャルのコピーの作成や現在参照すべきクレデンシャルとして別のクレデンシャルの設定が可能であるなど、相当自由なオペレーションが許されている。そのことが、かえってクレデンシャル自体の認証能力を結果的には弱めてしまい、厳密な認証を必要とする場合、オブジェクトを生成したドメインの認証サーバーなどへ照会を行わなければならない。このことが、現行のCORBAセキュリティ・サービスでの枠組みにおける、移動エージェントなどの、セキュリティ・ドメインを超えて移動可能なオブジェクトや移動可能なプロセスの実現に困難をもたらしている。
【００９７】例えば、次のような記述が成されている。「エージェントの認証はエージェント・システムの認証とは異なる。エージェントは移動の際、（プライベート・キーなどの）暗号化キーを持ち運ぶことはできない。エージェントの認証は（秘密キーなどを持つ代わりに）認証者を立てることによって行う。認証者とはエージェントの真正性を見極めるアルゴリズムである。発進元のエージェントシステムやエージェントを発進させたクライアントの真正性に関する情報、エージェントやエージェント・システムのオーソリティ、さらに恐らくエージェントを認証する主体として信頼できるオーソリティに付与された情報などを認証者は使用することが出来る。エージェント・システムと同様に認証者もタイプを持つ必要がある。さらに、認証者は名前つけを担当するオーソリティによって登録されるべきである。認証者を一段階、と多段階との２つのタイプに分類することが出来る。現時点では、一段階の認証者に関する動作と要件の仕様の作成は可能である。しかし、現時点のセキュリティ技術に限界があるために、多段階の認証者の仕様は先送りせざるをえない。
【００９８】一段階の認証者はエージェントが出発点から一段階離れたところへ移動する際のエージェントの認証ができる。例えば、オーソリティAに属するエージェントがオーソリティAのエージェント・システム上で実行している際、そのエージェントがオーソリティBのエージェント・システムへ移動する場合を考える。エージェント・システムBがエージェント・システムAの認証に成功した場合、エージェントはエージェント・システムAの真正性をエージェント・システムＢ上で保有する。エージェント・システムＢがエージェント・システムＡを認証できない場合、そのエージェントは認証されたとはみなされない。エージェントが移動元のエージェント・システムとは異なるオーソリティを持つ場合、このエージェント転送は多段の操作と考えられる。多段階の認証については、本仕様の対象とはしない。」（「GMD FOKUS、International Business Machines Corporation、Supported by: Crystaliz, Inc.、 General Magic, Inc.、The Open Group "Joint Submission : Mobile Agent System Interoperability Facilities Specification" 、November 10, 1997 OMG TC Document orbos/97-10-05」より）
【００９９】パスポートや運転免許証のように発行時に厳密な認証を受ければ、以後その証書を提示する事によって一定水準の認証が可能であるような証明書が存在すると、上記の多段階の認証に関する問題は解決可能となる。しかし、コンピュータ上やネットワーク上でのデータ化された証書はコピーや改ざんが容易なため、原本のコピーや改変と原本自体とを確実に識別できる証書システムが必要である。しかも、そのような証書はエージェントの移動に伴って移動可能でなければならない。このとき、先に述べてきた２重の証明書機構は、原本とそのコピーや改変との識別が可能でしかも移動も可能なクレデンシャルとしての要求を満足するものである。今までの説明において、改ざん不正コピー等、悪意に基づく違法アクセスに対抗する例を多く考えてきたが、クレデンシャルとして応用する場合、コピーや属性の変更はシステム的にも認められた操作である。この場合においてもコピーや異形に対して原本を識別する操作として上述のコピーや改ざんに対抗する操作を使用する事ができる。
【０１００】この技術は、移動エージェントの認証機構として開発されたものだが、プロセスとしては、エージェントだけでなく、署名付きの変造不能なデータを与えることも可能である。このようなプロセスは、有価証券や、金券など、ネットワーク上においてその存在の唯一性の保証が要求されるものに対する代替物として利用可能である。従来方式の署名付きデータだけでは、容易にデータのコピーが可能であったため、有価証券などの実現はネットワーク上では困難であった。本技術の証明書をそのデータに付加させることで違法コピーや偽装が困難になることは、すでに説明した通りである。
【０１０１】＜第１９実施形態：証明書正副間に悪者が介在する場合の排除方法＞本発明の認証方式は証明書の正本と副本との間の参照やメソッド呼出しに矛盾が無い事を前提にしている。これは、証明書相互間に共通の秘密を仮定せず、証明書の真正性を確認する方式を与えるためには、必要な事である。本方式は、移動可能プロセスの認証に応用する事が主要な目的であるため、このように共通の秘密を前提にしないことが要求されている。しかし、図１４のように、証明書正本と証明書副本との間に、悪者が介在し、両者間のメソッド呼出しを横取りすることによって、正本に対して副本を偽装し、副本に対して正本を偽装する方式の攻撃の恐れがある。いわゆる、バケツリレー式の攻撃である。
【０１０２】このような攻撃に対する対策は、証明書機構より下位に位置する通信機構にて行う必要がある。これには、次のような選択がある。ここで証明書管理機構が稼動しているホストをH1、ユーザー側のプロセスが稼動しているホストをH2とする。
(1)ホストＨ1とホストＨ2との通信システムに特に保護機能は置かないが、他の介在者が入り込まないよう運用面での管理を行う。
(2)ホストＨ1とホストＨ2との通信システムの物理層あるいは、データ・リンク層に暗号化機構などの保護機能を組み込む。
(3)ホストＨ1とホストＨ2との通信システムとアプリケーションとの制御を行うオペレーティング・システムなどに暗号化機能などの保護機能を組み込む。
(4)ホストＨ1とホストＨ2上で動作している、ORB（Object Request Broker）などのRMIやRPCを実現するミドルウェアに暗号化機能などの保護機能を組み込む。
(5)移動可能プロセスを実行させる実行環境と、証明書管理機構を実装するサーバー・プログラム等との間の通信に、暗号化機能などを組み込んだ安全な汎用メソッド呼出し機能を実現する。これは、両者は移動しないプロセスなので、プロセス立ち上げ時などに共通の秘密をパラメータやコンフィギュレーション・ファイルなどの形で与える事ができるので可能である。個々の証明書間のメソッド呼出しは、証明書の参照や、コマンド・コード、その他のデータを引数として汎用メソッドに渡す事で行う。
(6)Proxy（代理プロセス）をホストＨ2上、またはホストＨ1とホストＨ2双方の上に置き、Proxy経由でメソッド呼出しを行う。Proxyは暗号化等の保護機能を実現する。認証者をこの目的のために使用する事も考えられる。証明書副とProxyは同一ホスト上なので、その間の通信は充分安全であると考える。
【０１０３】＜第２０実施形態：証明書付き移動可能プロセスのデジタル通貨への応用＞銀行など許可された金融機関に証明書管理機構を設置し、そこを中心とした、セキュリティ・ドメインを構築する。様々な、金融機関の本支店間に独立したセキュリティ・ドメインが存在すると仮定する。各セキュリティ・ドメインには、そのドメインを管理する金融機関と契約した顧客のホストが接続されていると仮定する。セキュリティ・ドメイン相互間は、通信回線で結合されデータやプロセスの移動が可能であると仮定する。
【０１０４】このとき、それらのセキュリティ・ドメイン全体で流通する無記名のデジタル通貨を次のように実現することが可能である。
(1)デジタル通貨は、金融機関によって発行された証明書付きの移動可能プロセスである。
(2)証明書には、発行金融機関名と、発行日付、一意の識別番号、金額が明示されている。そして、証明書の内容が真正であることを示す、金融機関の署名が付加されている。
(3)プロセスには2つのメソッドが定義されていて、その一つは支払であり、他の一つは受け取りである。
(4)プロセスは、通貨の所有者を示す特殊な実行環境で動作する。この実行環境は、顧客のホスト内で動作し、ちょうど財布や金庫の役割を果たす。
(5)支払メソッドによってデジタル通貨は、現在実行中の環境から、指定された環境へ移動する。これは、金銭の支払に相当する。
(6)このメソッドの実行途中に、現実行環境から、所有者本人もしくは、本人の代理のプロセスに対して承認を求める通知がなされる。承認を受け取るまで、プロセス移動処理は一時中断する。
(7)この承認をうけて、プロセスの移動処理が再開される。
(8)この移動時に、既に述べられた証明書付きのプロセスの移動手順が実施され、通貨の認証と一意性の保証がなされる。
(9)プロセスの移動が完了し、再起動されるときに受け取りメソッドが実行される。このとき、受領通知が、送り元実行環境に伝えられる。これは、領収書に相当する。
(10)通貨を金融機関等に預金する目的で、第17節で記した、証明書付きプロセスの保存法式を応用することも可能である。
【０１０５】＜第２１実施形態：記名式通貨（手形：小切手）の実現＞記名式デジタル通貨は、振り出し人本人によって発行された証明書付きの移動可能プロセスである。証明書には、本人の氏名、取引先金融機関名と、発行日付、支払期日、一意の識別番号、金額が明示されている。そして、証明書の内容が真正であることを示す、本人の署名が付加されている。プロセスには、支払、受け取り、裏書き、取りたて、不渡りという5つのメソッドが定義されている。プロセスは、通貨の所有者を示す特殊な実行環境で動作する。この実行環境は、顧客のホスト内で動作し、ちょうど財布や金庫の役割を果たす。支払メソッド、もしくは裏書きメソッドによって記名式デジタル通貨は、現在実行中の環境から、指定された環境へ移動する。これは、手形の振り出し、もしくは裏書きに相当する。
(1)このメソッドの実行途中に、現実行環境から、所有者本人もしくは、本人の代理のプロセスに対して承認を求める通知がなされる。承認を受け取るまで、プロセス移動処理は一時中断する。
(2)この承認をうけて、プロセスの移動処理が再開される。
(3)この移動時に、第５，１４，１５，１６及びその他の実施形態において既に述べられた証明書付きのプロセスの移動手順が実施され、通貨の認証と一意性の保証がなされる。さらに、裏書きの場合、裏書人の氏名、実行環境名、および署名が、一旦、証明書管理機構に送られ、証明書正本に、氏名と実行環境名、および署名が付加される。
(4)プロセスの移動が完了し、再起動されるときに受け取りメソッドが実行される。このとき、受領通知が、送り元実行環境に伝えられる。これは、領収書に相当する。
(5)取り立ての際、受取人は、取り立てメソッドの実行を要求する。このメソッドは支払期日後に限って有効である。
(6)記名付きデジタル通貨は、証明書に明示されている取り引き金融機関に移動し、等価の無記名デジタル通貨との交換を要求する。
(7)金融機関は振り出し人の口座の残高を確認し、残高が充分な場合には、指定された金額を口座から引き落とし、その金額のデジタル通貨を受取人に支払う。
(8)口座の残高が不足している場合、不渡りメソッドが実行される。
(9)不渡りメソッドは、証明書正本に付加されている、裏書人の実行環境リストを逆の順序で移動しながら、当該手形が不渡りになったことを、各裏書き人に通知しながら、振出し人の実行環境に戻る。
(10)通貨を金融機関等に預金する目的で、第１６実施形態で記した[証明書付きプロセスの保存法式]を応用することも可能である。
【０１０６】（フ゜ロセスの移動と生成処理の実施例）
<手順１．証明書管理機構同士の認証に使用する共有鍵の登録>手動で行う。
【０１０７】<手順２．証明書管理機構の起動>手動で行う。
【０１０８】<手順３．認証者の起動>マスター認証者の起動は、手動または、各ホスト・コンピュータの定義ファイルなどにて定められた手順にて起動する。その他の認証者は、マスター認証者によって起動される。認証者の種類は、ユーザー認証者、実行環境認証者（前記実施形態では、証明書機構をサポートするJava仮想マシンを立ち上げる認証者）、オブジェクト生成認証者、オブジェクト再生成認証者、移動プロセス認証者、マスター認証者（証明書管理機構の所在を管理する）である。認証者との対話方式は実装によって異なる。
【０１０９】<手順４． 実行環境の起動>前提としては、証明書管理機構と実行環境との間には、信頼を確立する方法が存在する。たとえば、あらかじめ暗号鍵が共有されている。
(1)もしも、ユーザーの認証が行われていない場合には、ユーザー認証者はユーザーの認証を行う。
(2)ユーザーとの安全な通信セッションを確立する。
(3)ユーザーが実行環境の起動を要求する。
(4)実行環境認証者がユーザーの権限の問い合わせを行う。
(5)指定された実行環境の起動が行われる。
【０１１０】<手順５．実行環境と証明書管理機構との安全な通信の確立>(1)証明書管理機構と実行環境との相互認証が行われる。
(2)相互に安全な通信を行うための通信セッション鍵を生成する。
(3)以後の通信をそのセッション鍵でもって暗号化する。
(4)実行環境を管理する証明書を生成する。この情報は実行環境認証者によって与えられる。
【０１１１】<手順６．オブジェクトもしくはプロセスの生成>(1)もしも、ユーザーの認証が行われていない場合には、ユーザー認証者はユーザーの認証を行う。
(2)ユーザーとの安全な通信セッションを確立する。
(3)もしも、実行環境の起動が必要な場合は、手順５にしたがって実行環境の起動を行う。
(4)手順７にしたがって、クラスやプログラムの権限の確認を行う。
(5)オブジェクト生成認証者によってオブジェクトの生成要求を行う。
(6)手順８に従ってオブジェクトの生成が行われる。
(7)必要ならば、生成されたオブジェクトの妥当性をユーザーに確認させる。
(8)オブジェクト生成認証者はオブジェクトの参照と空の証明書副本の参照を証明書管理機構に渡す。
【０１１２】<手順７．オブジェクトを定めるクラスやプログラム等の権限の確認>要求したユーザーの権限に対して、使用されるクラスやプログラムの許可レベルが適切かどうかを確認する。
【０１１３】<手順８．環境内でのオブジェクトの生成>(1)指定されたクラスに基づくオブジェクトのインスタンスを生成する。
(2)空の証明書副本を生成する。
(3)証明書副本とオブジェクトとの対応付けを行う。
(4)オブジェクト生成認証者にオブジェクトと証明書副本の参照を渡す。
【０１１４】<手順９．証明書正本生成>(1)オブジェクト生成認証者より渡されたオブジェクトの参照と空の証明書副本ならびに、ユーザー情報、さらに認証情報データ・ベースなどによる情報に従って、証明書正本を作成する。
(2)正本に副本の参照を設定する。
(3)正本にオブジェクトへの参照を設定する。
(4)副本に対して初期設定要求をだす。
【０１１５】<手順10. 証明書副本の初期設定手順>(1)マスター認証者に対して証明書管理機構の参照を要求する。
(2)証明書管理機構に対して、証明書副本の参照を渡して、対応する正本の参照を要求する。
(3)もしも、正本の参照が得られない場合は、エラーとする。
(4)副本に正本の参照を設定する。
(5)正本に対して証明書データ読み出し要求を出す。
(6)正本から送られてきたデータを副本に設定する。
【０１１６】<手順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]を解読し、整数Ｒを取り出す。
(11)最後に、応答としてR+1を戻す。
(12)適当な整数R2を生成しKXY[R2]をチャレンジとして証明書正本に送る。
(13)その応答としてR2+1が戻されてきた場合、共有鍵の生成は成功である。また、その応答には、暗号化された、証明書正本と暗号化された共有鍵が添付されている。
(14)手順16を行う。
(15)手順17を行う。
【０１１７】<手順12. マスター認証者による移動可能プロセスと証明書管理機構との、移動のための相互認証手順>(1)不正検出アルゴリズムの手順2に従って、プロセスの認証を行う。このとき、証明書管理機構は、認証成功時にプロセス間で鍵を決定するために必要な、素数p、整定数gを返すものとする。
(2)認証結果をもどす。その際、成功時には、素数p、整定数gも戻す。
【０１１８】<手順13．証明書管理機構間の共有鍵生成手順>(1)宛先情報を名前付け管理機構などに渡し、相手先の認証機構の参照を得る。
(2)第16節の手順のいずれかに従って、共有鍵を生成する。ここで生成された鍵をKABとする。また、ここでは、転送セッションIDも生成されることとする。
【０１１９】<手順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を返す。
【０１２０】<手順15．正本側の証明書とプロセスとの共有鍵との暗号化手順>(1)証明書正本、プロセスとの共有鍵KXY、タイムスタンプを文字列として結合する。
(2)この文字列をKABにて暗号化する。
【０１２１】<手順16．プロセスの外部形式生成と暗号化手順>(1)定められたシリアライゼーションの手順に従ってプロセスの外部形式をバイト列として生成する。
(2)生成されたバイト列をKXYにて暗号化する。
【０１２２】<手順17.プロセスの他セキュリティドメインの移動プロセス認証者に対する移動申請手順>(1)プロセスが管理している宛先情報を、名前付け管理機構などに渡し、移動先の移動プロセス認証者の参照を入手する。
(2)手順16にて得られた暗号化されたプロセスの外部形式、証明書管理機構から送られた暗号化された正本、プロセスと証明書管理機構との共有鍵、セッションID、プロセスの参照、証明書正本、副本の参照を引数として、移動プロセス認証者に移動要求を発行する。
【０１２３】<手順18．移動プロセス認証者によるプロセスと証明書との複号化手順>(1)プロセスの暗号化されたプロセスの参照、セッションIDと、証明書正本の参照、暗号化された正本、プロセスとの共有鍵を証明書管理機構に渡し、手順20によって証明書とプロセスの再生成を行う。
(2)正常に再生成が行われない場合要求プロセス側にエラーを戻す。
【０１２４】<手順19のa．移動プロセスの再生成手順>(1)与えられたプロセスの外部形式から所定のデシリアライゼーション手順を使用して内部形式を生成する。
(2)内部形式の生成に失敗した場合はエラーとする。
(3)手順７にしたがって、クラスやプログラムの権限の確認を行う。
(4)空の証明書副本を生成する。
(5)証明書副本とオブジェクトとの対応付けを行う。
(6)移動プロセスト生成認証者はオブジェクトの参照と空の証明書副本の参照を証明書管理機構に渡す。
【０１２５】<手順19のｂ．プロセスの外部形式解読を経たプロセス生成>(1)KXYによってプロセスの暗号を解読しプロセスの外部形式を作る。
(2)もしも、実行環境の起動が必要な場合は、手順５にしたがって実行環境の起動を行う。
(3)手順19のaによってプロセスの生成を行う。
(4)生成されたプロセスの参照と空の副本の参照を戻す。
【０１２６】<手順20．証明書とプロセスの再生成>(1)セッションIDより共有鍵KABを取り出す。
(2)共有鍵KABを使用して暗号化された証明書ならびにプロセスとの共有鍵、タイムスタンプの暗号を解除する。
(3)送信側の証明書正本の参照と暗号解除された証明書との照合を行う。
(4)照合で致命的な不一致が発見された場合、またはタイムスタンプが閾値の範囲に入らない場合は、エラーとして処理を打ち切る。
(5)オブジェクト再生成認証者にプロセスとの共有鍵KXY、暗号化されたプロセスの外部形式を渡し、手順19のbにてプロセスの再生成を行わせる。このとき、正常に再生成された場合、空の証明書副本とプロセスの参照が渡される。
(6)正常な再生成が行われなければ、エラーとして処理を打ち切る。
(7)オブジェクト再生成認証者よりもどされたオブジェクトの参照と空の証明書副本ならびに、解読された正本情報、さらに認証情報データ・ベースなどによる情報に従って、証明書正本を作成する。
(8)正本に副本の参照を設定する。
(9)正本にオブジェクトへの参照を設定する。
(10) 副本に対して初期設定要求をだす。
(11)送信側の証明書正本に対して手順21の無効化処理を行う。
【０１２７】<手順21．送信側の証明書の無効化手順（正副の無効化）>(1)要求側が、証明書管理機構であることを確認する。
(2)証明書正本に無効フラグを設定する。
(3)正本で管理しているプロセスの参照に対して手順22の無効要求を発する。
(4)正本を管理テーブルなどから削除する。
【０１２８】<手順22．送信側のプロセスの無効化手順>(1)マスター認証者に対して証明書管理機構の参照を要求する。
(2)証明書管理機構に対して、証明書副本の参照を渡して、対応する正本の参照を要求する。
(3)もしも、正本の参照が得られない場合は、プロセスの終了処理を行う。
(4)正本の無効フラグをチェックする。
(5)無効フラグがtrueの場合には、プロセスの終了処理を行う。
【０１２９】
【プロセス・コピーに対抗した場合の手順の変形】<手順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]を解読し、整数Ｒを取り出す。
(13) 最後に、応答としてR+1を戻す。
(14) 適当な整数R2を生成しKXY[R2]をチャレンジとして証明書正本に送る。
(15) その応答としてR2+1が戻されてきた場合、共有鍵の生成は成功である。また、その応答には、暗号化された、証明書正本と暗号化された共有鍵が添付されている。
(16) 手順28を行う。
(17) 手順29を行う。
【０１３０】<手順24. マスター認証者による移動可能プロセスと証明書管理機構との相互認証手順>(1)不正検出アルゴリズムの手順2に従って、プロセスの認証を行う。このとき、証明書管理機構は、認証成功時にプロセス間で鍵を決定するために必要な、素数p、整定数gを返すものとする。またこの処理の終了段階で、認証成功時、手順25によって、証明書正本経由でプロセスからハッシュ値の転送を行う。
(2)認証結果をもどす。その際、成功時には、素数p、整定数gも戻す。
【０１３１】<手順25．ハッシュ値送付手順>(1)証明書正本は自分が保持しているプロセスの参照に対してハッシュ値の要求を行う。
(2)プロセスからの戻りとしてハッシュ値が与えられる。
【０１３２】<手順26．証明書管理機構間の共有鍵生成手順>(1)宛先情報を名前付け管理機構などに渡し、相手先の認証機構の参照を得る。
(2)第16節の手順のいずれかに従って、共有鍵を生成する。ここで生成された鍵をKABとする。また、ここでは、転送セッションIDも生成されることとする。
【０１３３】<手順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を返す。
【０１３４】<手順28．プロセスの外部形式の暗号化手順>(1)定められたシリアライゼーションの手順に従ってプロセスの外部形式をバイト列として生成する。
(2)生成されたバイト列をKXYにて暗号化する。
【０１３５】<手順29.プロセスの他セキュリティドメインの移動プロセス認証者に対する移動申請手順>(1)プロセスが管理している宛先情報を、名前付け管理機構などに渡し、移動先の移動プロセス認証者の参照を入手する。
(2)手順28にて得られた暗号化されたプロセスの外部形式、証明書管理機構から送られた暗号化された正本、プロセスと証明書管理機構との共有鍵、ハッシュ値、セッションID、プロセスの参照、証明書正本、副本の参照を引数として、移動プロセス認証者に移動要求を発行する。
【０１３６】<手順30．移動プロセス認証者によるプロセスと証明書との複号化手順>(1)プロセスの暗号化されたプロセスの参照、セッションIDと、証明書正本の参照、暗号化された正本、プロセスとの共有鍵、ハッシュ値を証明書管理機構に渡し、手順32によって証明書とプロセスの再生成を行う。
(2)正常に再生成が行われない場合要求プロセス側にエラーを戻す。
【０１３７】<手順31．環境内での移動プロセスの再生成手順>(1)与えられたプロセスの外部形式から所定のデシリアライゼーション手順を使用して内部形式を生成する。
(2)内部形式の生成に失敗した場合はエラーとする。
(3)手順７にしたがって、クラスやプログラムの権限の確認を行う。
(4)空の証明書副本を生成する。
(5)証明書副本とオブジェクトとの対応付けを行う。
(6)移動プロセスト生成認証者はオブジェクトの参照と空の証明書副本の参照を証明書管理機構に渡す。
【０１３８】<手順32．証明書とプロセスの再生成>(1)セッションIDより共有鍵KABを取り出す。
(2)共有鍵KABを使用して暗号化された証明書ならびにプロセスとの共有鍵、タイムスタンプ、ハッシュ値の暗号を解除する。
(3)送信側の証明書正本の参照と暗号解除された証明書との照合を行う。
(4)照合で致命的な不一致が発見された場合、またはタイムスタンプが閾値の範囲に入らない場合は、エラーとして処理を打ち切る。
(5)オブジェクト再生成認証者にプロセスとの共有鍵KXY、暗号化されたプロセスの外部形式、ハッシュ値HashPを渡し、手順33にてプロセスの再生成を行わせる。このとき、正常に再生成された場合、空の証明書副本とプロセスの参照が戻される。
(6)正常な再生成が行われなければ、エラーとして処理を打ち切る。
(7)オブジェクト再生成認証者よりもどされたオブジェクトの参照と空の証明書副本ならびに、解読された正本情報、さらに認証情報データ・ベースなどによる情報に従って、証明書正本を作成する。
(8)正本に副本の参照を設定する。
(9)正本にオブジェクトへの参照を設定する。
(10) 副本に対して初期設定要求をだす。
(11) 送信側の証明書正本に対して手順21の無効化処理を行う。
【０１３９】<手順33プロセスの外部形式解読とハッシュ値との照合を経たプロセス生成>(1)KXYによってプロセスの暗号を解読しプロセスの外部形式を作る。
(2)外部形式にハッシュ関数を適用してハッシュ値Hを求める。
(3)HとHashPとが一致しない場合、エラーとして処理を打ち切る。
(4)もしも、実行環境の起動が必要な場合は、手順５にしたがって実行環境の起動を行う。
(5)手順31によってプロセスの生成を行う。
(6)生成されたプロセスの参照と空の副本の参照を戻す。
【０１４０】
【発明の効果】本発明の移動可能プロセスの認証方法によれば、証明書管理機構の安全が確保されていることにより、証明書正本副本の信頼性の保障が可能となり、他の情報に依存することなく、証明書正本副本と移動可能プロセスのみによって移動可能プロセスの移動時の認証を行うが可能となる。従って、実行環境間において転々と転送されて移動する移動可能プロセスが変化しても、移動の元となった実行環境のプリンシパルと移動可能プロセスとの相互参照可能な証明書正副データにより、当該転送された移動可能プロセスの真正性を証明書管理機構側で認証することが可能となり、移動可能プロセスの不正コピーや、改竄、なりすまし、データの盗難・破壊を防止することができ、移動エージェントなどの移動可能プロセスのセキュリティーを顕著に向上させることができる。
【図面の簡単な説明】
【図１】本発明の認証機構の概念を示す図
【図２】本発明の証明書機構の基本構造を示す概念図
【図３】本発明のセキュリティ・ドメインの概念図
【図４】本発明で問題としているセキュリティ・ドメイン間のプロセス移動の概念図
【図５】本発明の移動可能プロセスの認証手順の概念図
【図６】本発明のユーザー・オブジェクトへの証明書の割付の概念図
【図７】本発明の移動可能プロセスの認証手順の概念図
【図８】本発明における証明書偽造への対策を示す概念図
【図９】本発明における不正コピーへの対策を示す概念図
【図１０】本発明における偽装への対策を示す概念図
【図１１】本発明におけるユーザー・オブジェクトへの証明書の埋め込みを示す概念図
【図１２】本発明における証明書管理機構自体を偽装している場合の対策を示す概念図
【図１３】本発明において配列又はハッシュテーブルにより証明書と秘密の対応をさせた場合の概念図
【図１４】正副証明書間に介在者が存在した場合のバケツリレー攻撃の概念図
【特許請求の範囲】
【請求項１】移動可能プロセス生成時にユーザー等の生成者により与えられた認証情報を保持する証明書正本を、安全の確保された証明書管理機構に設置し、前記証明書正本より派生した証明書副本を前記移動可能プロセスの実行環境内に設置し、前記移動可能プロセスと前記移動可能プロセスとを双方向に参照する参照により一対一に対応させ、前記証明書正本と前記証明書副本とを双方向に一対一に対応させ、前記証明書正本に前記移動可能プロセスへの参照を設定することを特徴とする移動可能プロセスの認証方法。
【請求項２】請求項１の移動可能プロセスの認証方法であって、前記証明書正本副本、前記移動可能プロセス間の相互間の参照が整合すること、ならびに、前記証明書正本副本情報が整合することの確認をもって、前記移動可能プロセスの認証成功を判定し、当該認証処理において、前記証明書正本が前記証明書管理機構を代表すると見なすことをもって、前記証明書管理機構と前記移動可能プロセス相互の認証が行われたと判定し、前記証明書管理機構と前記移動可能プロセス以外の系には知り得ない共有の秘密生成を可能としたことを特徴とする移動可能プロセスの認証方法。
【請求項３】１以上のネットワークで接続された転送元実行環境と転送先実行環境と、前記転送元実行環境で生成された移動可能プロセス及び前記転送先実行環境の共有鍵KP1、並びに、前記転送先実行環境の共有鍵KP2を保持し、前記移動可能プロセスと相互認証を行っている証明書管理機構とにおける移動可能プロセスの認証方法であり、第１のステップにおいて、転送に先立ち、前記移動可能プロセスは、前記証明書管理機構に対して共通秘密鍵KAJの生成を要求すると共に、この要求の際、前記移動可能プロセスは秘密の数SAを定め、TA=gSA mod p（pは素数、gはある整定数で、modは法演算をあらわす）を計算してTAを前記証明書管理機構Jに渡し、第２のステップにおいて、前記証明書管理機構は前記移動可能プロセスの要求に答えて、秘密の数SJを生成して TJ=gSJ mod pを計算すると共に、共通鍵KAJをKAJ=TASJ mod p とし、第３のステップにおいて、前記証明書管理機構は前記共有鍵KP2により前記共通秘密鍵KAJを暗号化して、KP2[KAJ]を計算し、第４ステップにおいて、前記証明書管理機構は、前記移動可能プロセスに対して、TJとKP2[KAJ]を前記要求に対して回答し、第５ステップにおいて、前記移動可能プロセスは受け取ったTJから、KAJ=TJSA mod pを計算して、共通鍵KAJを再生し、第６ステップにおいて、前記移動可能プロセスは転送するオブジェクトを外部形式化して外部形式OExを生成した後、この外部形式OEx全体を前記共有鍵KAJにて暗号化してKAJ[OEx]とを生成し、第７ステップにおいて、前記移動可能プロセスは前記転送元実行環境に対して、KAJ[OEx]とKP2[KAJ]とを前記転送先実行環境に転送することを要求し、第８ステップにおいて、前記転送元実行環境から前記転送先実行環境にKAJ[OEx]とKP2[KAJ]とが転送されたとき、前記転送先実行環境はKAJ[OEx]とKP2[KAJ]とを解読して共有鍵KAJをつくることを特徴とする移動可能プロセスの認証方法。
【請求項４】請求項２における移動可能プロセスの認証方法であり、前記移動可能プロセスは移動可能オブジェクトであり、この移動可能オブジェクトに、この移動可能オブジェクトに一対一に対応すると共に、前記転送元実行環境の本体であることを示すプリンシパルの識別が記載される名札オブジェクトを前記証明書副本として配置し、前記移動可能オブジェクトが前記名札オブジェクトを配布する場合を、(1)前記プリンシパルの主体が移動可能オブジェクトを直接生成した場合と、(2)前記プリンシパルに所属するある移動可能オブジェクトAnが存在し、ある移動可能オブジェクトAが前記移動可能オブジェクトAnの結果として生じた場合とに限定し、前記(1)の場合に、前記プリンシパルの主体は、当該生成された移動可能オブジェクトが当該プリンシパルに所属することを示す名札オブジェクトを生成し、前記(2)に、前記移動可能オブジェクトAnは当該移動可能オブジェクトAnの名札オブジェクトを複写して、前記移動可能オブジェクトAに付与することを特徴とする移動可能プロセスの認証方法。
【請求項５】請求項２の移動可能プロセスの認証方法であり、前記移動可能プロセスは移動可能オブジェクトであり、前記証明書管理機構に、前記名札オブジェクトに一対一に対応する影の名札オブジェクトを前記証明書正本として配置すると共に、前記名札オブジェクトの内容と前記影の名札オブジェクトの内容とを常に一致させ、移動可能オブジェクトがプリンシパルに属するとして認証する場合を、(1)当該プリンシパルの主体が移動可能オブジェクトを直接生成した場合と、(2)ある移動可能オブジェクトAが、元となる移動可能オブジェクトAnの結果として生じた場合とに限定し、前記(1)の場合に、プリンシパルの主体は、プリンシパルの識別が記載された名札オブジェクトを移動可能オブジェクトに対応づけると共に、その名札オブジェクトと同じ内容の影の名札オブジェクトとを対応させて、前記(2)の場合に、オブジェクトAnはオブジェクトAnの名札オブジェクトを複写してオブジェクトAに与え、その名札オブジェクトに影の名札が対応している場合に限り、影の名札オブジェクトの複写も行うことを特徴とする移動可能プロセスの認証方法。
【請求項１】移動可能プロセス生成時にユーザー等の生成者により与えられた認証情報を保持する証明書正本を、安全の確保された証明書管理機構に設置し、前記証明書正本より派生した証明書副本を前記移動可能プロセスの実行環境内に設置し、前記移動可能プロセスと前記移動可能プロセスとを双方向に参照する参照により一対一に対応させ、前記証明書正本と前記証明書副本とを双方向に一対一に対応させ、前記証明書正本に前記移動可能プロセスへの参照を設定することを特徴とする移動可能プロセスの認証方法。
【請求項２】請求項１の移動可能プロセスの認証方法であって、前記証明書正本副本、前記移動可能プロセス間の相互間の参照が整合すること、ならびに、前記証明書正本副本情報が整合することの確認をもって、前記移動可能プロセスの認証成功を判定し、当該認証処理において、前記証明書正本が前記証明書管理機構を代表すると見なすことをもって、前記証明書管理機構と前記移動可能プロセス相互の認証が行われたと判定し、前記証明書管理機構と前記移動可能プロセス以外の系には知り得ない共有の秘密生成を可能としたことを特徴とする移動可能プロセスの認証方法。
【請求項３】１以上のネットワークで接続された転送元実行環境と転送先実行環境と、前記転送元実行環境で生成された移動可能プロセス及び前記転送先実行環境の共有鍵KP1、並びに、前記転送先実行環境の共有鍵KP2を保持し、前記移動可能プロセスと相互認証を行っている証明書管理機構とにおける移動可能プロセスの認証方法であり、第１のステップにおいて、転送に先立ち、前記移動可能プロセスは、前記証明書管理機構に対して共通秘密鍵KAJの生成を要求すると共に、この要求の際、前記移動可能プロセスは秘密の数SAを定め、TA=gSA mod p（pは素数、gはある整定数で、modは法演算をあらわす）を計算してTAを前記証明書管理機構Jに渡し、第２のステップにおいて、前記証明書管理機構は前記移動可能プロセスの要求に答えて、秘密の数SJを生成して TJ=gSJ mod pを計算すると共に、共通鍵KAJをKAJ=TASJ mod p とし、第３のステップにおいて、前記証明書管理機構は前記共有鍵KP2により前記共通秘密鍵KAJを暗号化して、KP2[KAJ]を計算し、第４ステップにおいて、前記証明書管理機構は、前記移動可能プロセスに対して、TJとKP2[KAJ]を前記要求に対して回答し、第５ステップにおいて、前記移動可能プロセスは受け取ったTJから、KAJ=TJSA mod pを計算して、共通鍵KAJを再生し、第６ステップにおいて、前記移動可能プロセスは転送するオブジェクトを外部形式化して外部形式OExを生成した後、この外部形式OEx全体を前記共有鍵KAJにて暗号化してKAJ[OEx]とを生成し、第７ステップにおいて、前記移動可能プロセスは前記転送元実行環境に対して、KAJ[OEx]とKP2[KAJ]とを前記転送先実行環境に転送することを要求し、第８ステップにおいて、前記転送元実行環境から前記転送先実行環境にKAJ[OEx]とKP2[KAJ]とが転送されたとき、前記転送先実行環境はKAJ[OEx]とKP2[KAJ]とを解読して共有鍵KAJをつくることを特徴とする移動可能プロセスの認証方法。
【請求項４】請求項２における移動可能プロセスの認証方法であり、前記移動可能プロセスは移動可能オブジェクトであり、この移動可能オブジェクトに、この移動可能オブジェクトに一対一に対応すると共に、前記転送元実行環境の本体であることを示すプリンシパルの識別が記載される名札オブジェクトを前記証明書副本として配置し、前記移動可能オブジェクトが前記名札オブジェクトを配布する場合を、(1)前記プリンシパルの主体が移動可能オブジェクトを直接生成した場合と、(2)前記プリンシパルに所属するある移動可能オブジェクトAnが存在し、ある移動可能オブジェクトAが前記移動可能オブジェクトAnの結果として生じた場合とに限定し、前記(1)の場合に、前記プリンシパルの主体は、当該生成された移動可能オブジェクトが当該プリンシパルに所属することを示す名札オブジェクトを生成し、前記(2)に、前記移動可能オブジェクトAnは当該移動可能オブジェクトAnの名札オブジェクトを複写して、前記移動可能オブジェクトAに付与することを特徴とする移動可能プロセスの認証方法。
【請求項５】請求項２の移動可能プロセスの認証方法であり、前記移動可能プロセスは移動可能オブジェクトであり、前記証明書管理機構に、前記名札オブジェクトに一対一に対応する影の名札オブジェクトを前記証明書正本として配置すると共に、前記名札オブジェクトの内容と前記影の名札オブジェクトの内容とを常に一致させ、移動可能オブジェクトがプリンシパルに属するとして認証する場合を、(1)当該プリンシパルの主体が移動可能オブジェクトを直接生成した場合と、(2)ある移動可能オブジェクトAが、元となる移動可能オブジェクトAnの結果として生じた場合とに限定し、前記(1)の場合に、プリンシパルの主体は、プリンシパルの識別が記載された名札オブジェクトを移動可能オブジェクトに対応づけると共に、その名札オブジェクトと同じ内容の影の名札オブジェクトとを対応させて、前記(2)の場合に、オブジェクトAnはオブジェクトAnの名札オブジェクトを複写してオブジェクトAに与え、その名札オブジェクトに影の名札が対応している場合に限り、影の名札オブジェクトの複写も行うことを特徴とする移動可能プロセスの認証方法。
【図１】
【図３】
【図２】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１４】
【図１２】
【図１３】
【図３】
【図２】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１４】
【図１２】
【図１３】
【公開番号】特開平１１−１６８４６２
【公開日】平成１１年（１９９９）６月２２日
【国際特許分類】
【出願番号】特願平９−３３４５８１
【出願日】平成９年（１９９７）１２月４日
【出願人】（５９７１６９６９４）
【出願人】（５９７１６９７０８）
【公開日】平成１１年（１９９９）６月２２日
【国際特許分類】
【出願日】平成９年（１９９７）１２月４日
【出願人】（５９７１６９６９４）
【出願人】（５９７１６９７０８）
[ Back to top ]