JP3640338B2 - 安全な電子データ格納、取出しシステムおよび方法 - Google Patents

Description

【０００１】
【発明の属する技術分野】
本発明は、電子データ格納の分野を対象とし、さらに詳細には、データ取出し時にアクセス制御が実施され第三者であるデータ保管者（custodian）によって管理される、安全なデータ・リポジトリ／交換システムを提供する。
【０００２】
【従来の技術】
ネットワーク通信と公開キー・インフラストラクチャ（public key infrastructure）（「ＰＫＩ」）テクノロジにおける最近の平行した進歩によって、企業や公的機関は、あらゆる種類の記録保管および業務処理に際して、電子文書を使用するようになってきた。伝送の保全性および機密保護の向上に伴い、インターネットや他のオープン・ネットワークを介して電子的に送信される文書は、改ざんされずに完全な形で着信すると確信することができる。データベース管理システムを、数ギガバイトのデータを記憶することができる最新のコンピュータ・メモリと組み合わせることによって、企業や公的機関は、不動産コストのかさむ大量の記録用紙を保管しなくてもよくなった。
【０００３】
一般に、１つのエンティティから発信されるデータは、寄託、検討などいくつかの理由で他のエンティティへ送信しなければならないことがある。このデータ要素は、銀行口座やその他の財務情報など非構造化文書ファイルまたは構造化レコードの形式を採ることができる。非構造化データの例では、検討の目的で、発信元システムから同じシステム内の他のコンピュータへ、または別のシステム上に常駐するコンピュータへ、文書を転送する必要が生じることがある。こうした状況は、企業の立場（たとえば、合弁事業の申込みや複雑な入札の目的）においても、公的機関の立場（たとえば大学の論文審査委員会に提出する前に指導教官によって検討される卒業論文）においても、等しく発生する可能性がある。文書は（特に長い文書の場合）、毎回文書全体をタイプし直す必要がなく、改訂や追加が容易にできるので、電子的に作成されている。
【０００４】
文書を電子書式にすると簡単に伝送できることから、検討も容易になる。ただし、作成者は文書を回覧するのではなく、所期の検討者にその文書が入手可能なことを知らせ、アクセス権を提供することができる。文書を検討するためには、許可された検討者にその文書の格納場所へのアクセス権を与える必要がある。
【０００５】
文書作成者が文書をローカルに格納したくないと考えるのには、いくつかの理由がある。ローカル文書格納手段が、そのファイアウォールの背後にある他のエンティティに対してオープン・アクセスを提供している場合、機密保護のリスク（ハッカーの脅威）が生じる。ローカル格納場所にアクセスすると、検討者による１つの不注意な行動によって文書ファイルが消去されてしまう可能性もあるため、データ管理も危険にさらされる。また、システムまたはネットワーク、あるいはその両方の可用性が低いと、検討者が感じる格納場所にある文書に直接アクセスできるという便利さが帳消しになることがある。システムの可用性とは、文書発信者のローカル・マシンまたはＬＡＮがいつでも検討者に便利なように利用できるかどうかということであり、ネットワークの可用性とは、数人の検討者が同時にアクセスしようとした場合に、ネットワークがローカル格納場所に複数のポイントを使用可能にし難いようにする制約のことである。
【０００６】
企業または公的機関においても、文書の発信者が一定の日付に文書（たとえば商用入札）を提出したことを示す独立した確認を提供しなければならない理由があることがある。
【０００７】
解決方法の１つは、第三者、特に安全なデータ・リポジトリのサービスを提供する業務を担当しており、必要であれば寄託証明を発行できる人のリポジトリを使用することである。
【０００８】
Document Authentication Systems, Inc.に譲渡された、共に「System and Method for Electronic Transmission Storage and Retrieval of Authenticated Documents」という名称の、米国特許第５６１５２６８号および第５７４８７３８号は、データ・リポジトリ・サービスと通信するために、知的所有権のあるＷｉｎｄｏｗｓクライアントを使用してデータ保全性および非拒否保証を提供するシステムについて記載している。
【０００９】
これらの特許で対象とされていない重要な問題は、リポジトリに格納されたデータの保全性およびこのデータへのアクセスが、文書リポジトリを管理する第三者のアクションに依存していないことである。言い換えれば、データ保管者が不注意なアクションまたは不当なアクションによって、システム・ユーザによってアクションが検出されることなくデータの内容を修正できるようであってはならない。さらに、データ保管者が、ユーザのデータ要素にアクセスできるようにする特権またはアクセスできないようにする制約を変更できるようであってはならない。
【００１０】
前述の米国特許第５６１５２６８号および第５７４８７３８号のシステムでは、データ・リポジトリ・サービスは、データを他のユーザに漏らすことがないと信用されている。このシステムでは、暗号技術を使用したデータのプライバシーは実現されていない。
【００１１】
【発明が解決しようとする課題】
したがって、本発明の一目的は、電子文書の格納／交換システムを提供することであって、このシステムでは、文書は第三者によって管理されるリポジトリ内に物理的に格納されるが、ユーザはこの文書へのアクセスが可能であり、この文書を互いに共用する。
【００１２】
本発明の他の目的は、リポジトリ内に格納されたデータの保全性およびこのデータへのアクセスが第三者である管理者のアクションに依存していないシステムを提供することである。
【００１３】
【課題を解決するための手段】
したがって一態様において、本発明は、データ・リポジトリと、寄託側コンピュータの暗号化された電子データをデータ・リポジトリに格納しそこから取り出すのを管理するリポジトリ・マネージャと、寄託側コンピュータのエージェント・プログラムとからなる、安全な電子データの格納／取出しシステムを対象とする。エージェント・プログラムは、寄託側コンピュータがオンラインであろうとオフラインであろうと、リポジトリ・マネージャにアクセス可能である。さらにエージェント・プログラムは、要求元コンピュータの認証時に、要求元コンピュータの要求に応じてデータ・リポジトリから取り出された寄託側コンピュータの暗号化された電子データの暗号を解読する手段も有する。好ましくは、リポジトリ・マネージャが、データ・リポジトリに格納する前に暗号化された電子データにデジタル署名し、次いで、署名付き暗号化データのコピーをエージェント・プログラムに転送して、エージェント・プログラムが暗号解読後に取り出した暗号化電子データを署名付き暗号化データと突き合わせて検証できるようにすることができる。
【００１４】
別の態様において、本発明は、データのソースとは無関係にリポジトリ・マネージャによって管理されるデータ・リポジトリに格納された電子データへのユーザ・アクセスを確実に認証するためのシステムおよび方法を提供し、ここでユーザ許可のアクセス制御リストは、データ・リポジトリに格納されるときに電子データに関連付けられる。ソース側が、アクセス制御リストの更新を担当し、現アクセス制御リストの証拠を保持する。現アクセス制御リストの証拠は、更新を実行したどのユーザ・コンピュータにも提供される。ソース側は、データを要求元コンピュータに解放する前に、電子データと共にデータ・リポジトリに格納された更新済みのアクセス制御リストが正確であることを確証する。
【００１５】
本発明は、多数のユーザにアクセス可能で、多数のユーザによってアクセスされる多数の文書を有するシステムで使用すると、特に有効である。ユーザ・アクセス情報を集中させると、情報の重複を避けることになるため、システム効率が向上する。さらに、強力な集中化された検索権限を使用すると、豊富な検索が可能になり、パラメータは文書識別に制限する必要がなくなるが、作成時間、文書発信者の識別など、他の識別子を含むことも考えられる。
【００１６】
本発明は、前述のシステムまたは方法を実行するためにプログラム・コードを使って符号化された媒体の形式で実現することができる。
【００１７】
【発明の実施の形態】
第三者の保管者を利用する文書リポジトリ・システムの従来の配置を図１に示す。文書発信者１００は、その接続１０２を介して、第三者によって管理されるデータベースなどのリモート文書リポジトリ・サービス１０４に文書を預けることができる。寄託文書の所有者として、文書発信者１００はその文書へのアクセスを割り当てることができる。たとえば、文書発信者は、業務パートナ１０６に「読取り」権限を割り当てることが可能であるが、これは、割り当てられた業務パートナがその文書リポジトリ・サービス１０４への接続１０８を介して文書を取り出すことができるが、寄託文書を変更することはできないという意味である。
【００１８】
このような従来のシステムでは、一般に、要求時に業務パートナ１０６が文書を検討できるように、文書発信者１００から寄託された文書は暗号化されない。これは、従来技術では文書の暗号解読に関連した問題があるためである。文書を暗号解読するには、文書発信者１００の秘密キーにアクセスする必要がある。秘密キーにアクセスするには、文書発信者１００が、暗号解読自体を実行するために暗号解読が要求される可能性のある場合にはいつでも自分自身をオンラインで使用できるようにしておく（システム可用性の問題）か、またはその秘密キーを業務パートナ１０６が直接または信用される代理人（図示せず）を介して使用できるようにするためにあらかじめスキームをセットアップしておく必要がある。
【００１９】
インターナショナル・ビジネス・マシーンズ・コーポレイションの米国特許第５４９１７５０号は、「Method and Apparatus for Three-Party Entity Authentication and Key Distribution Using Message Authentication Codes」に関するものである。この特許は、２者またはそれ以上の通信パートナが信用される仲介者を介して認証された後に、この通信パートナによって共用される秘密のセッション管理キーの配布を可能にするシステムについて記載している。ただし、このスキームの下で生成されたキーならびにこれと同様の他のキーは一時的なものであって、絶対に必要な場合以外はほとんど使用しないように意図されている。このようなスキームが、永続的な文書リポジトリを使用した文書検討システムで、通信パートナ間での暗号解除キーの安全な伝送を行うのに適しているかどうかは明らかでない。
【００２０】
したがって、文書が一定期間寄託され暗号化されない従来のシステム（図１）では、第三者の管理者であるリポジトリ・サービス１０４は文書の保全性維持について信用できるものでなければならない。
【００２１】
本発明の好ましい実施形態の文書リポジトリ・システムは、ＩＢＭ社に譲渡された１９９７年１１月２６日出願の「Secure Server and Method of Operation for a Distributed Information System」という名称の、米国特許出願第９８００２２号の主題である、IBM Vault Registry製品を使用して構築することができる。米国特許出願第９８００２２号は参照により本明細書に組み込まれる。IBM Vault Registry製品は、ヴォールト（Vault）と呼ばれるクライアント環境の安全な拡張を実装する、拡張ｗｅｂサーバ環境を提供する。このシステムは、電子的に伝送される文書および他のデータがそのままの形でエラーもなく着信するという、本明細書の発明の属する技術分野に記載した最新の伝送技術を利用している。クライアントのヴォールト内に含まれるリソースは、認定された公開キーによる強力な認証を使用してクライアントからアクセスされた場合にのみ使用可能となる。環境によっては、クライアントのｗｅｂブラウザを介してアクセスすることもある。
【００２２】
ヴォールトの情報内容は、プライバシーのため暗号化されている。サーバ上にあるヴォールトは、固有の暗号キー、およびブラウザを介したアクセスなどヴォールトの所有者によって承認された信用できる経路を介したアクセス以外のキーへのアクセスを抑制する機構を有する。ヴォールト内で実行されるプログラムは、以下のことを保証するために、オペレーティング・システム・サービスによって分離されている。
ａ）ヴォールト内で動作するプログラムによる改変の可能性なしに従属プロセスにその識別が使用できるように、システム識別（仮想ログオン）を使用したプロセスで動作する。
ｂ）その中で動作しているヴォールトのデータ内容だけにアクセスでき、他のものにはアクセスできない。
ｃ）ヴォールトの所有者によって、ヴォールト内での実行が承認されている。
ｄ）改ざんや「トロイの木馬」攻撃を防ぐために署名されている。
【００２３】
ヴォールト内で動作するプログラムは、同じヴォールト、または互いの公開キーへの安全なアクセスを有する他のヴォールトに情報を預けることができる。一般に、これらのヴォールトは同じヴォールト・サーバ上に配置されているが、異なるヴォールト・サーバ上に配置し、公開キー情報を提供するために共通の認証機関にアクセスすることもできる。ヴォールト・リポジトリの文脈では、「寄託」という語が様々な意味を持つことがある。一実施態様では、寄託という語は目標ヴォールトの暗号化キーにデータを暗号化し、そのデータを寄託ヴォールトの署名キー中で署名することを表すことができる。ヴォールト・プログラムは、暗号化キーと署名キーのどちらにも直接アクセスすることはできない。これは、ＡＰＩを介して実行される。任意選択で、「寄託」機能は、目標ヴォールト内に収容されている待ち行列に情報を入れることもできる。別のオプションでは、情報が寄託されたこと、および目標ヴォールト内のプログラムがデータをオープンしたことを確認する「配達証明（return receipt）」が提供される。これらすべての「寄託」機能は、次のような形でヴォールト内で情報を受け渡す手段を提供する。
ａ）元のプロセスは否定できない。
ｂ）プロセス間通信バッファを検査する機能を有するものによって、内容が閲覧されない。
ｃ）送達が保証されている。
【００２４】
アプリケーションが目標ヴォールトへのデータを待ち行列に入れることを選択しない場合は、ファイル、データベース内に情報を格納すること、あるいはデータを「不透明な（opaque）」項目として処理できる（たとえばオブジェクトが永続性になるようにシリアル化する）他の任意のシステム・サービスを使用することを選択することができる。この不透明情報は、バックアップおよび回復用の標準的なシステム技術で管理することができる。ただし、その内容は、SecureDepositorアプリケーション・プログラミング・インタフェースを使用してそれを所有するヴォールトの文脈で実行されるプログラムによってのみ、暗号解読することができる。
【００２５】
IBM Vault Registry製品を使用した本発明の好ましい実施形態を、図２に略図で示す。
【００２６】
図１に示したシステムと同様に、図２に示したスキームでは、文書発信者２００が文書リポジトリ・サービス２０４との接続２０２を介して文書を寄託することができ、さらに寄託文書の所有者として、業務パートナなどの第三者２０６に、その文書へのアクセス・レベルを割り当てることができ、この第三者２０６は、自分自身のネットワーク接続２０８を介して文書リポジトリ・サービス２０４内にある文書へアクセスできるようになる。ただし、前述のシステムとは異なり、文書リポジトリ・システムのユーザには、第三者を信用してリポジトリ内の文書フィールドの保全性を維持させる義務はない。
【００２７】
好ましい実施形態の文書リポジトリ・システム２０４は、２つの構成要素、アプリケーション・サーバ２１０およびヴォールト・コントローラ２１４を備える。アプリケーション・サーバ（ＡＳ）は、データベース・リポジトリ２１２を管理するプログラムであって、同じマシン上にあっても、また閉じたネットワーク上のリモート位置にあってもよい。ヴォールト・コントローラ２１４は、複数の構成要素、すなわち個別に文書発信者２００および業務パートナ２０６に割り当てられたユーザ・ヴォールト２１６、２１８、アプリケーション・サーバ２１０に割り当てられたＡＳヴォールト２２０、ならびにヴォールト監視プログラム２２２を含む。
【００２８】
ユーザ・ヴォールト２１６または２１８には、適切な認証に基づいてヴォールトが割り当てられたユーザ（文書発信者２００または業務パートナ２０６）だけがアクセスすることができる。個々のヴォールトは文書データベース２１２に直接アクセスすることができず、アクセスはＡＳヴォールト２２０およびアプリケーション・サーバ２１０を介して行われる。
【００２９】
アプリケーション・サーバ構成要素２１０は、信用されるコンピューティング・ベースでは実行されないが、任意のプラットフォーム上で実行可能である。アプリケーション・サーバは、ヴォールト・コントローラ２１４内にあるこれに割り当てられたＡＳヴォールト２２０内で実行される交互（reciprocating）構成要素を有する。ＡＳヴォールト２２０はアプリケーション・サーバ２１０と通信可能であり、このアプリケーション・サーバを介して文書データベース２１２にアクセスすることができる。
【００３０】
図３は、本発明の好ましい実施形態による、文書作成のプロセスを示す流れ図である。IBM Vault Registry環境を使用すると、パーソナル・ヴォールトは概念的にヴォールト所有者環境の安全な拡張となる。したがって、図３では、文書発信者とアプリケーション・サーバのヴォールト間での各プロセス・ステップ間の対話が示されている。
【００３１】
データ・リポジトリ内で文書を作成する場合、文書はまずこれを作成または発信したユーザのデスクトップからユーザ（文書発信者）のパーソナル・ヴォールトに送信され（ブロック３００）、ここで文書はユーザ・ヴォールトの秘密署名キーで「署名」される（ブロック３０２）。
【００３２】
データ要素の電子署名とは、署名者がそのデータ要素の保全性を保証するものである。署名は、まずデータ要素のダイジェストを計算することにより算出することができる。このダイジェストは、セキュリティを保証するための特有のプロパティを有する、比較的小規模な構造（たとえば、ＭＤ２またはＭＤ５ダイジェストの場合１２８ビット）である。第１に、これは一方向関数であり、すなわちダイジェストが与えられても、それを生成したオリジナル文書を取得することは不可能である。さらに、ダイジェストが与えられても、同じダイジェストを有するはずの第２のプレイメージを見つけることも不可能（または計算による実現不可能）である。ダイジェストは、衝突に対する耐性もある。すなわち、２つの異なるプレイメージが同じダイジェストを生成することはほとんどあり得ない。
【００３３】
次いでデータ要素のダイジェストは、ユーザ・ヴォールト・アプリケーションの秘密署名キーを使って暗号化される（ブロック３０４）。好ましい実施形態では、対称暗号技術および公開キー非対称暗号技術の両方が使用される。
【００３４】
公開キー暗号を使用する場合、アプリケーションは、キー・ペアと呼ばれる公開キーと秘密キーの２つのキーを有する。秘密キーはアプリケーションによってローカルに保持されており、下記で詳しく論じる。公開キーは、通常はＸ．５００分散型ディレクトリのようなディレクトリ・サービスを介して、すべてのユーザが使用できるようになっている。公開キー配布は、当技術分野で周知であり、本明細書ではこれ以上詳しくは論じない。
【００３５】
公開キー暗号が使用されるとき、公開キーで暗号化されたデータ要素は、対応する秘密キーでのみ暗号解読することができる。同様に、秘密キーで暗号化されたデータ要素は、公開キーでのみ暗号解読することができる。
【００３６】
対称キー技法では、暗号化と暗号解読の両方に１つのキーが使用される。現在のところ、対称キー技法による暗号化／暗号解読およびキー生成の方が公開キー非対称技法を用いるよりもかなり高速である。
【００３７】
データは通常、ランダムに生成された対称キーを使用して暗号化される。次いでこの対称キーは、ユーザの公共暗号キーを使用してそれ自体が暗号化され文書と共に格納されて、文書の一部となる。
【００３８】
さらに図３を続けて見ていくと、暗号化された文書と電子署名は、文書データベースに保管するためにアプリケーション・サーバのヴォールトに転送される（ブロック３０６）。暗号化された文書を受け取ると（ブロック３０８）、アプリケーション・サーバのヴォールト内で実行中のアプリケーションは、それ自体の秘密署名キーを使用して再署名することによって、署名を公証する（ブロック３１０）。
【００３９】
電子的文脈において、署名の公証とは、「公証人」としての役割を果たす第三者が、署名の内容を証明するという意味である。（政府機関によって授与された公証人役場に課せられたすべての義務が、本明細書における「公証人」および「公証」の参照によってカバーされるものではない。）一般に署名の電子公証は、後でその署名が許可なく修正されるのを防ぐための特別な予防措置として実行される。本発明の場合、ユーザのデジタル署名の公証は、ユーザが文書リポジトリ内にあるオリジナル文書を置き換えたり修正したりするのを防ぐ。その文書に関連する公証済み署名をチェックすれば、不一致があれば明らかになるはずである。
【００４０】
公証済みの電子署名には、所与のデータ要素の発信者署名とその発信者署名の公証人の署名という２つの情報が含まれる。公証人の署名は、発信者署名および現タイム・スタンプに関して計算されるものとする。
【００４１】
その後アプリケーション・サーバのヴォールト内で実行中のアプリケーションは、受け取った文書に署名する（ブロック３１２）。文書発信者から受け取ったデータは暗号化されているため、アプリケーション・サーバは実際には文書の内容について何の知識も持たない。したがって、本発明によれば、この第２の署名は暗号化文書および発信者の公証済み署名に対して計算される。アプリケーション・サーバの署名は、リポジトリ・サービスが文書を受け取ったことを文書発信者（寄託元）に対して証明する、非拒否証明（non-repudiation receipt）となる。その後リポジトリ内で文書を作成しても、後でリポジトリ・サービスによって拒否されることはない。
【００４２】
暗号化された文書、文書発信者の公証済み署名、および非拒否証明は、すべてアプリケーション・サーバのリポジトリまたはアプリケーション・データベースに格納される（ブロック３１４）。非拒否証明は、文書発信者のヴォールトに送信される（ブロック３１６）。文書発信者のヴォールトは、暗号化された文書の署名を検証することにより、非拒否証明の正確さをチェックする（ブロック３１８）。文書発信者のヴォールトはまた、公証済み署名のタイム・スタンプが現在のものであるかどうかをチェックする（ブロック３２０）。タイム・スタンプの許容範囲は、アプリケーションに依存する。これらのテストのどちらかに不合格になると、エラー・メッセージがＡＳヴォールトに戻され（ブロック３２２）、システムに記録される。証明が正しい現在のものであれば、ユーザのヴォールト内で実行されているアプリケーションは、文書がリポジトリに格納されているとの証明が必要になった場合、非拒否証明を将来の参照用にローカルに保管しておくために発信者ユーザに戻す（ブロック３２４）。
【００４３】
文書発信者は、格納のためにヴォールトに提出する前に、自分の知的所有権のある技法を使用して文書の署名または暗号化あるいはその両方を行うことができる。ただし、文書リポジトリは、格納される文書の内容に関知しない。したがって、暗号化された文書は、他の文書が処理されるのと同様に、ユーザのヴォールトによって再署名および再暗号化される。
【００４４】
図４および図５は、本発明の好ましい実施形態による、文書発信者のアクセス制御リスト（ＡＣＬ）の下で許可された要求元によって文書が取り出されるのを許可するために実行する必要のある、各ステップを示す流れ図である。ＡＣＬの確立および保守については、下記で詳しく論じる。
【００４５】
図３と同様に、図４および図５に示すプロセス・ステップは、それぞれのパーソナル・ヴォールトがそれぞれの作業スペースの概念的に安全な拡張であることに基づいて、IBM Vault Registry製品または同様の特性を備えた環境で提供される、文書発信者、アプリケーション・サーバ、および要求元の各ヴォールト間でのアクションと対話を示したものである。
【００４６】
図４から始めると、要求元が自分のヴォールト・アプリケーションに対して、アプリケーション・サーバ・リポジトリから文書を取り出すように要求し（ブロック４００）、要求元のヴォールト・アプリケーションがその文書に対する要求を、アプリケーション・サーバのヴォールトに転送する（ブロック４０２）。
【００４７】
アプリケーション・サーバのヴォールト・アプリケーションは、アクセス要求を受け取り（ブロック４０４）、暗号化文書、発信者の公証済み署名、および署名付きＡＣＬを、アプリケーション・データベースから取り出す（ブロック４０６）。
【００４８】
アプリケーション・サーバのヴォールト・アプリケーションは、暗号化文書、公証済み署名、および署名付きＡＣＬを文書発信者のヴォールトに送信する。さらにアプリケーション・サーバのヴォールトは、要求元の識別ヴォールトも発信者のヴォールトに送信する（ブロック４０８）。
【００４９】
発信者のヴォールトは、要求元が文書の取出しを許可されているかどうかチェックする（ブロック４１２）。好ましい実施形態では、文書アクセスを許可されたエンティティのみに制限するために使用されるアクセス制御リストを介して、文書のアクセス制御が可能になる。アクセス制御リストは文書に関連付けられ、要求元が文書を取り出すことを求める要求を送信するときにチェックする必要がある。要求元は、アクセス権をもっている場合、文書のコピーのみを与えられる。要求元は、機能リストが使用されている場合、要求に先立ってアクセスを検証することができる。要求元が文書へのアクセスを許可されていない場合は、発信者にエラー・メッセージが戻され、システムに記録される（ブロック４１４）。
【００５０】
図５に進むと、要求元が文書の受取りを許可されている場合、発信者のヴォールト・アプリケーションは文書を暗号解読し（ブロック４１６）、公証済み署名を検証する（ブロック４１８）。
【００５１】
発信者のオリジナル署名は暗号化されていない文書内容に対して計算されたものであるため、文書内容にアクセスできるユーザだけが署名を検証することができる。受け取った署名が暗号解読された文書と対応していない場合は、預けた文書と同じバージョンでないことが明らかなので、発信者はエラー・メッセージをアプリケーション・サーバに戻す（ブロック４２０）。
【００５２】
署名が検証された場合、発信者は暗号解読された文書と公証済み署名を要求元のヴォールトに転送する（ブロック４２２）。
【００５３】
暗号解読された文書を受信すると、要求元のヴォールト・アプリケーションは、公証人の公共署名キーを使用して発信者の公証済み署名の検証を試みる（ブロック４２４）。要求元がそれを検証できない場合、エラー・メッセージが発信者に戻され、システムに記録される（ブロック４２６）。
【００５４】
発信者の公証済み署名が検証できる場合、要求元のヴォールトは文書と共に受け取った公証済み署名に署名する。この署名は公証済み署名ならびに現タイム・スタンプに対して計算されたもので、文書がリポジトリから取り出されたことを証明する送達証明（delivery receipt）となる（ブロック４２８）。要求元のヴォールトは、暗号解読された文書を生成した非拒否証明と共に要求元のデスクトップに戻す（ブロック４３０）。さらに要求元のヴォールトは、非拒否証明をアプリケーション・サーバのヴォールトに転送する（ブロック４３２）。アプリケーション・サーバは、これを受け取り次第、要求元ヴォールトの署名を検証する（ブロック４３４）。署名が文書と対応していない場合、その証明は誤りまたは「受取りなし（missing receipt）」としてマークされ、アプリケーションにこの格納機能が含まれている場合はキャッシュされる（ブロック４３６）。署名が検証できる場合、アプリケーション・サーバ・ヴォールトは、要求元が文書を取り出した証拠としてこの証明をアプリケーション・データベースに格納する（ブロック４３８）。
【００５５】
文書取出しに関するアクセス制御の不変性（immutability）
前述のように、データ・リポジトリでは文書アクセス制御に関する要件がある。すなわち、文書の所有者が許可したユーザだけがその文書を閲覧することが可能であり、文書アクセス許可は、文書の所有者（すなわち文書発信者）と、所与の文書のアクセス制御リストを修正する許可を文書の所有者から与えられている他のユーザだけが修正できるということである。リポジトリ管理者でも、文書の所有者から許可されていない限り文書のアクセス許可を修正する権限のないことを保証することが重要である。
【００５６】
文書アクセス制御の不変性を確立するためのアプリケーションの要件には、２つの異なるタイプのものがある。文書アクセスは、
１）ユーザが閲覧する許可を与えられているすべての文書を見つけるための検索を実行するとき、および
２）ユーザが実際に文書の取出しを実行するときに、チェックする必要がある。
【００５７】
すべてのアプリケーションは、文書取出し時にアクセス制御を実施する必要がある（上記アクセス・タイプの２）。このタイプのアクセスの場合、リポジトリは、文書のアクセス制御が、競合企業など許可されていないユーザによって修正される可能性がないことを保証しなければならない。
【００５８】
またアプリケーションによっては、文書検索時にも、特にユーザがリポジトリのアプリケーション・サーバを使用する以外にどの文書へのアクセス権が認められているかを判定する手段を持たない場合に、アクセス制御を実施する必要がある。文書の検索時および取出し時の両方にアクセス制御の不変性を実施するシステムは、本発明者等が本出願と同時に出願した「System for Electronic Repository of Data Enforcing Access Control on Data Search and Retrieval」という名称の出願（ＩＢＭ整理番号第ＣＡ９９８−０４０号）の主題である。
【００５９】
一部のアプリケーションでは、ユーザが閲覧を許可されているすべての文書に関して文書リポジトリを照会できることが不可欠ではない。たとえば、この知識は業務会議の際にオフラインで、あるいは電子メールや電話を介して伝えることができる。このような場合、ユーザは既にどの文書にアクセスできるかを知っているため、要求元自身の文書アクセスに関する知識が、リポジトリのアクションによって影響を受けることはない。
【００６０】
好ましい実施形態では、各文書が、それに関連付けられた、様々なユーザに関する文書へのアクセス許可を識別するアクセス制御リスト（ＡＣＬ）を有する。不変性を保証するために、各ＡＣＬは文書発信者のヴォールト内で図６に示すように処理される。
【００６１】
各ＡＣＬには、その最新の修正のバージョン番号およびタイム・スタンプが付随する。ＡＣＬが更新されると（ブロック５００）、そのバージョン番号は増分され（ブロック５０２）、ＡＣＬに関連する古いタイム・スタンプが最新のタイム・スタンプで置き換えられる（ブロック５０４）。ＡＣＬの不変性を保証するためのトークンが、このときＡＣＬに関連する最新のバージョン番号およびタイム・スタンプから作成される。トークンは、文書発信者のヴォールトによって署名される（ブロック５０６）。テキスト文字列やバイナリ構造などのデータ構造が、ＡＣＬにトークンを接続することによって生成される（ブロック５０８）。このデータ構造は、置き換えられる可能性をなくすために所有者のヴォールトによって署名され（ブロック５１０）、文書リポジトリ内に格納するためにＡＣＬおよびトークンと共にＡＳヴォールトに転送される（ブロック５１２）。
【００６２】
ＡＣＬトークンは、将来のＡＣＬ検証のためにユーザのアクセス・アプリケーションと共にデスクトップに格納するため、文書へのアクセスが許可されている任意のユーザのヴォールトへも転送される（ブロック５１４）。署名付きトークンは、格納のために文書発信者のデスクトップに転送される（ブロック５１６）。文書発信者は、署名付きトークンのコピーを保持しているので、文書ＡＣＬが最新のものであるか否かの最終決裁者となる。
【００６３】
業務パートナが文書を取り出したいときは、ＡＳヴォールト・アプリケーションは、前述のように暗号化された文書を発信者のヴォールトに送信する（図４のブロック４０８）。ＡＳヴォールトは、この文書、公証済み署名、および要求元のＩＤと共に、署名付きのＡＣＬをも発信者のヴォールトに送信する。要求元の許可を検証するために（図４のブロック４１２）、その後発信者のヴォールトは次のチェックを実行する。
１．ＡＣＬ署名が正しいかどうかを検証する。
２．バージョン番号およびタイム・スタンプが発信者のヴォールト内に格納されているものと一致することを検証する。
３．検証済みのＡＣＬ内で、要求元が指示された文書へのアクセス権を有することをチェックする。
【００６４】
この方法を使用すると、アプリケーション・データベース内に格納されたＡＣＬを発信者のヴォールトに検出されずに修正することはまったくできない。
【００６５】
前述のように、リポジトリ内の文書を所有している各ユーザは、各ＡＣＬの正しいバージョンの署名付きトークンをそのデスクトップ上に保持している。ユーザ・ヴォールトによって保持されているＡＣＬバージョンは、ユーザのデスクトップ上に格納されている署名付きトークンとユーザのヴォールト内に格納されているそれとを比較することによって検証される。この比較は、様々なときに実行することができる。ユーザのヴォールト内に格納されているＡＣＬを検証する好機の１つはログオン時であり、ユーザがログオンするごとにユーザのＡＣＬが検証される。
【００６６】
ＡＣＬ検証に失敗した場合、ユーザのヴォールト・アプリケーションは、ＡＣＬによって保護されている文書を取り出すことを求めるすべての要求の受付けを自動的に停止する。このような文書のアクセス不能状態は、ユーザが新しいＡＣＬを作成するか、または既存のＡＣＬを再認証するまで持続する。既存のＡＣＬの再認証プロセスには、ユーザのヴォールトに格納されたＡＣＬトークンとユーザのデスクトップ上に格納されたトークンとの同期化が含まれる。
【００６７】
この実施形態では、実際のＡＣＬはアプリケーション・データベースに格納される。ユーザが許可を与えられている文書を検索したい場合、この検索は、アプリケーション・データベースに直接アクセスできる唯一のプログラムであるアプリケーション・サーバのヴォールト・アプリケーションによってのみ実行可能である。ただし、文書へのユーザのアクセス権に関する「悪意の」アプリケーション・サーバによるどんな誤情報も、チェック可能である。アプリケーション・サーバは、ユーザのワークステーション上またはユーザのヴォールト内にある署名付きＡＣＬトークンにアクセスすることはできない。ユーザは、次にユーザがトークンを検証する際に、そのトークンが、アプリケーション・サーバから受け取った情報と一致していないことを発見することになる（下記の「バックアップおよび回復」の項を参照）。これは特に、文書へのアクセスが認められているだけで後で除去されないような形で設計されたシステムで有用である。
【００６８】
所有者特権の割当て
環境によっては、文書発信者が他の人に所与の文書のアクセス・リストの修正を許可できるようにする必要がある。たとえば、所有者が使用できない場合、別の許可されたユーザが所与の文書のアクセス制御を更新できるようになる。
【００６９】
本発明の好ましい実施形態によれば、この機能は図７に示すように実装することができる。ＡＣＬの更新を試みるとき、更新を行うユーザは、そのＡＣＬの最新の署名付きトークンを提示することができなければならない（ブロック６００）。署名付きトークンは、更新を行うユーザ自身のヴォールトに送信され（ブロック６０２）、それが署名付きトークンを発信者のヴォールトに渡す（ブロック６０４）。発信者のヴォールトは、このトークンと自分自身の格納場所にある署名付きトークンとを比較することによって、トークンの有効性をチェックする（ブロック６０６）。発信者のヴォールトは、更新を行うユーザの権限もチェックする（ブロック６１０）。
【００７０】
トークンが無効、または更新を行うユーザがこの文書のＡＣＬに割り当てられた所有者特権を持っていない場合、文書発信者のヴォールトはこれを検出して、更新を拒否し、ユーザのヴォールトにエラー・メッセージを戻す（ブロック６０８）。
【００７１】
発信者のヴォールトが署名を行うユーザの文書へのアクセスを検証できる場合、およびＡＣＬトークンのバージョン番号とタイム・スタンプが最新のものである場合（ブロック６１０）、ＡＣＬは更新され（ブロック６１２）、新しいトークンが生成され署名されて（ブロック６１４）、発信者のヴォールトに格納される（ブロック６１６）。新しい署名付きトークンは、リポジトリに格納するためにアプリケーション・サーバのヴォールトに転送される（ブロック６１８）。この新しい署名付きトークンは、更新元のヴォールトに送信される（ブロック６２０）。この更新元のヴォールトは、新しいトークンを格納するために更新元のデスクトップに戻す（ブロック６２２）。
【００７２】
この手順には、ＡＣＬの更新を実行できる人が常に１人だけであることが必要である。たとえば、文書発信者のジョン（John）が休暇で休む場合、彼は同僚のメアリー（Mary）に、文書のＡＣＬに関する彼の最新のトークンを与えることによって、彼が会社を休んでいる間に彼女が彼の文書のＡＣＬを更新できるように許可することができる。次いでメアリーは、自分のヴォールトを介してジョンのヴォールトにトークンを提示することによって、ＡＣＬの更新を発行する。メアリーは、このＡＣＬの新しい署名付きトークンを受け取り、ジョンが会社に復帰したとき彼に戻す。この新しいトークンをインストールした後、ジョンは自分自身のＡＣＬ更新を発行することができる。
【００７３】
データのバックアップおよび回復
文書リポジトリの管理者が、以前のバックアップから文書データベースを復元する必要が生じることが時折ある。これはたとえば、ディスク・クラッシュなど破局的なデータベースの障害が生じた場合に必要になる。バックアップに含める必要のあるデータは、文書自体、ＡＣＬ（アプリケーション・データベースまたは所有者ヴォールトのどちらに格納されている場合でも）、機能リスト（前述のように機能を実行するシステムに関する）、ＡＣＬおよび機能リストの検証トークンである。
【００７４】
データを復元した後、最新のバックアップ後に実行された更新は失われることがある。本発明では、ＡＣＬおよび機能リストの更新がそれに含まれる可能性がある。その場合、ユーザのデスクトップに格納された検証トークンが、対応するヴォールト内のトークンと一致しなくなり、適正なユーザ・アクセスが拒否されることがある。
【００７５】
したがって、様々な状況でデータを復元する場合の標準を提供するために、以下のシステムが実装された。バックアップはタイム１で実行され、復元は要求元が文書の取出しを実行したタイム１でのデータの状態に基づきその後のタイム２で発生したと仮定する。
【００７６】
ヴォールトに格納された文書データベース、ＡＣＬ、機能リスト、および対応するトークンの完全なデータ復元が実行される場合、タイム１より前に文書へのアクセスを許可されているユーザは、タイム２の後にもこれにアクセスできる。つまり、ユーザがタイム１より前には許可されていて、タイム１より後でタイム２より前にその権限が取り消された場合、そのユーザは、文書発信者がＡＣＬトークンのチェックを実行するまでは文書にアクセスできることになる。したがって、すべてのユーザは、完全なデータ復元の後に、ＡＣＬおよび機能リストのチェックを行う必要がある。
【００７７】
文書データベースのみが復元され、ＡＣＬ、機能リスト、およびヴォールトに格納されたトークンはそのままである場合、ユーザは、タイム１より後に追加されたが、その後データベースの復元中に失われたため、データベース内に存在しない文書へのアクセスが許可されていることを発見することがある。すべてのトークンは最新のものであるため、他の異常はいっさい発生しない。
【００７８】
別のケースとして、機能リストは使用されていないが、ＡＣＬがアプリケーション・データベースに格納されているシステムの場合がある。文書データベースおよびＡＣＬが復元されており、ヴォールトに格納されたトークンは復元されていない場合、ユーザは、タイム１より後に変更されたＡＣＬを有するすべての文書がアクセス不可能であることを発見する。これは、アプリケーション・データベース内のＡＣＬトークンが、個々の所有者のヴォールト内に格納されているトークンと一致しないためである。この問題を処理するためには、すべての文書発信者がＡＣＬを更新しなければならない。その一方法としては、管理者が古いＡＣＬ（タイム１の時点では有効であった）を文書発信者に送信し、対応するトークンをそのヴォールトに再インストールするように依頼することである。この更新は自動ではなく手動で実行され、所有者がこの更新を完了するまで所有者の文書はアクセス不能である。
【００７９】
データベースの不整合を避けなければならない場合、リポジトリ管理者は復元後、発信者が是正処置を実行するまで、すべての文書へのアクセスを禁止することができる。このアクセス禁止は、リポジトリ内に格納されているすべての文書に適用されるか、または整合性がクリティカルな文書のサブセットだけに適用される。この場合、リポジトリ管理者に依拠して、システムの整合性を保持しなければならない。ただし前述のように、いずれの場合でも管理者には文書へのユーザ・アクセスを認可したり取り消したりする権限はもたない。
【００８０】
システムに一斉（orchestrated）攻撃が加えられる可能性を最小限に抑えるためには、ヴォールト・サーバの管理者および対応するローカル・ヴォールト格納場所と、データベース管理者との間で役割を分けることが重要である。
【００８１】
以上、IBM Vault Registry製品を使用して実装された本発明の好ましい実施形態について述べてきた。ただし本発明が、各ユーザのデスクトップにローカルに配置された安全なヴォールト様環境など、類似の機能を提供する他の製品を使用しても実装できることは、当業者には自明であろう。この性質および当業者に自明な他の性質の修正は、添付の特許請求の範囲によってカバーされるものとする。
【００８２】
まとめとして、本発明の構成に関して以下の事項を開示する。
【００８３】
（１）安全な電子データ格納／取出しシステムであって、
データ・リポジトリと、
寄託側コンピュータが暗号化された電子データをデータ・リポジトリ内へ格納しそこから取り出すのを管理するためのリポジトリ・マネージャと、
寄託側コンピュータがオンラインであれオフラインであれ、リポジトリ・マネージャにアクセス可能な寄託側コンピュータのエージェント・プログラムとを含み、前記エージェント・プログラムが要求元コンピュータの認証時に要求元コンピュータの要求に応じてデータ・リポジトリから取り出された寄託側コンピュータの暗号化された電子データを解読する手段を有するシステム。
（２）リポジトリ・マネージャが、データ・リポジトリに格納する前に暗号化された電子データにデジタル署名し、この署名付き暗号化データのコピーを寄託側コンピュータのエージェント・プログラムに転送するようにさらに適合され、寄託側コンピュータのエージェント・プログラムが、署名付き暗号化データに照らして暗号解読後取り出した暗号化電子データを検証するように適合されている、上記（１）に記載のシステム。
（３）前記エージェント・プログラムが暗号解読した電子データを要求元コンピュータに転送するようにさらに適合された、上記（１）または（２）に記載のシステム。
（４）前記エージェント・プログラムが、寄託側コンピュータの安全な拡張であり、寄託側コンピュータとリポジトリ・マネージャとの間の通信を管理するように適合されている、上記（３）に記載のシステム。
（５）リポジトリ・マネージャ、寄託側コンピュータ、および要求元コンピュータとの通信リンクを有するサーバをさらに含み、前記サーバが、
寄託側コンピュータのエージェント・プログラムと、
リポジトリ・マネージャの安全な拡張を含み、このリポジトリ・マネージャを使用してサーバ上で行われる他の環境との間の通信を管理するように適合された第２の環境と、
要求元コンピュータの安全な拡張を含み、この要求元コンピュータを使用してサーバ上で行われる他の環境との間の通信を管理するように適合された第３の環境とを少なくとも収納する、上記（４）に記載のシステム。
（６）寄託側コンピュータのエージェント・プログラムが、寄託側コンピュータから受け取った電子データを暗号化してデジタル署名する手段と、暗号化した電子データおよび署名をデータ・リポジトリに格納するためにリポジトリ・マネージャに転送する手段とを含む、上記（４）または（５）に記載のシステム。
（７）電子データのソースとは無関係にリポジトリ・マネージャによって管理されるデータ・リポジトリ内に格納された電子データへのユーザ・アクセスを安全に認証するための方法であって、
ユーザ許可のアクセス制御リストをデータ・リポジトリ内に格納されるとき電子データと関連付けるステップと、
前記電子データのソースからアクセス制御リストの更新を実行するステップと、
前記更新されたアクセス制御リストをデータ・リポジトリ内に格納された電子データと共に格納するステップと、
電子データのソース側と更新を行った任意のユーザ・コンピュータ側に更新済みのアクセス制御リストの証拠を格納するステップと、
前記電子データを要求元の許可ユーザに解放する前にソース側に格納された証拠を使用して、前記電子データと共にデータ・リポジトリ内に格納された更新済みアクセス制御リストの正確さを検証するステップとを含む方法。
（８）アクセス制御リストの更新を実行するステップが、
更新されたアクセス制御リストの改訂レベルを識別するステップと、
現タイム・スタンプを更新されたアクセス制御リストに関連付けるステップとを含み、
前記証拠を格納するステップが、
改訂レベルと現タイム・スタンプのトークンを作成するステップと、
データ・リポジトリ内の電子データにアクセスできるあらゆるユーザ側に前記トークンを格納するステップとを含む、上記（７）に記載の方法。
（９）データ構造を形成するために更新済みアクセス制御リストにトークンを付けるステップと、
前記データ構造にデジタル署名するステップと、
署名付きデータ構造を更新済みアクセス制御リストと共にデータ・リポジトリ内およびソース側に格納するステップとをさらに含み、
前記更新済みアクセス制御リストの正確さを検証するステップが、
ソース側でデータ構造署名の暗号解読を検証するステップと、
検証されたデータ構造をデータ・リポジトリから取り出した更新済みアクセス制御リストと比較するステップとを含む、上記（８）に記載の方法。
（１０）前記証拠を格納するステップが、
トークンにデジタル署名するステップと、
署名付きトークンをソース側に格納するステップとをさらに含む、上記（８）に記載の方法。
（１１）デジタル署名付きトークンを、ソースからアクセス制御リストを更新する許可を与えられたユーザに転送するステップと、
デジタル署名付きトークンがアクセス制御リストを更新する許可を与えられたユーザによって提示される際に、
ソース側でトークン署名を検証するステップと、
検証されたトークンを、データ・リポジトリから取り出した更新済みアクセス制御リストに関連する改訂レベルおよび現タイム・スタンプと比較するステップとをさらに含む、上記（１０）に記載の方法。
（１２）遠隔データ・リポジトリにおいて電子データを安全に格納し取り出すための方法であって、
ソース側で電子データにデジタル署名するステップと、
ソース側で電子データを暗号化するステップと、
暗号化された電子データをデータ・リポジトリに転送するステップと、
寄託証明を作成するためにデータ・リポジトリ側で暗号化された電子データにデジタル署名するステップと、
暗号化された電子データと寄託証明をデータ・リポジトリに格納するステップと、
寄託証明のコピーをソース側に戻すステップとを含む方法。
（１３）格納された電子データにアクセスすることを求める要求を要求元ユーザから受け取るステップと、
暗号化された電子データを取り出し、取り出したデータをソース側に転送するステップと、
要求元ユーザが電子データへのアクセスを許可されたユーザであるか否かを検証するステップと、
確認された場合に取り出したデータの暗号解読を行うステップとをさらに含む、上記（１２）に記載の方法。
（１４）ユーザ許可のアクセス制御リストを、データ・リポジトリ内に格納されたときに電子データと関連付けるステップと、
電子データのソース側からアクセス制御リストの更新を実行するステップと、更新済みのアクセス制御リストをデータ・リポジトリ内に格納された電子データと共に格納するステップと、
ソース側とデータ・リポジトリ内の電子データへのアクセスを許可されたあらゆるユーザ側に更新済みアクセス制御リストの証拠を格納するステップとをさらに含む、上記（１３）に記載の方法。
（１５）要求元ユーザが許可されているか否かを検証するステップが、更新済みアクセス制御リストにその要求元ユーザを入れるステップを含む、上記（１４）に記載の方法。
（１６）電子データを要求元のユーザに解放する前にソース側に格納された証拠を使用して、電子データと共にデータ・リポジトリ内に格納された更新済みアクセス制御リストの正確さを検証するステップをさらに含む、上記（１５）に記載の方法。
（１７）上記（７）ないし（１６）のいずれか一項に記載の方法をコンピュータで実行する際に使用するための命令を格納するコンピュータ可読メモリ。
【図面の簡単な説明】
【図１】第三者保管者を利用する文書リポジトリ・システムの概略図である。
【図２】図１と同様、本発明の好ましい実施形態で使用されるヴォールト文書リポジトリ・システムを示す概略図である。
【図３】本発明による文書作成のプロセスを示す流れ図である。
【図４】本発明による文書検索のプロセスを示す流れ図である。
【図５】本発明による文書検索のプロセスを示す流れ図である。
【図６】本発明の好ましい実施形態による、文書検索に関するアクセス制御の不変性を提供するためのプロセスを示す流れ図である。
【図７】本発明による格納文書に所有者特権を割り当てるためのプロセスを示す流れ図である。
【符号の説明】
２００ 文書発信者
２０２ 文書の寄託、アクセス制御の割当て
２０４ 文書リポジトリ・サービス
２０６ 業務パートナ
２０８ 文書の調査
２１０ アプリケーション・サーバ
２１２ データベース・リポジトリ
２１４ ヴォールト・コントローラ
２１６ 文書発信者ヴォールト
２１８ 業務パートナ・ヴォールト
２２０ ＡＳヴォールト
２２２ ヴォールト監視プログラム

Claims (17)

1. 安全な電子データ格納／取出しシステムであって、
   データ・リポジトリと、
   電子データを寄託する寄託側コンピュータが暗号化された電子データを前記データ・リポジトリ内へ格納しそこから取り出すのを管理するためのリポジトリ・マネージャと、
   前記寄託側コンピュータがオンラインであろうとオフラインであろうと、前記リポジトリ・マネージャにアクセス可能な前記寄託側コンピュータのエージェント・プログラムとを含み、前記エージェント・プログラムが電子データを要求する要求元コンピュータの認証時に該要求元コンピュータの要求に応じて前記データ・リポジトリから取り出された前記寄託側コンピュータの前記暗号化された電子データを解読する手段を有するシステム。
2. 前記リポジトリ・マネージャが、前記データ・リポジトリに格納する前に前記暗号化された電子データにデジタル署名し、この署名付き暗号化データのコピーを前記寄託側コンピュータの前記エージェント・プログラムに転送するようにさらに適合され、前記寄託側コンピュータの前記エージェント・プログラムが、前記署名付き暗号化データに照らして暗号解読後取り出した前記暗号化電子データを検証するように適合されている、請求項１に記載のシステム。
3. 前記エージェント・プログラムが暗号解読した前記電子データを前記要求元コンピュータに転送するようにさらに適合された、請求項１または２に記載のシステム。
4. 前記エージェント・プログラムが、前記寄託側コンピュータを安全に機能拡張させ、前記寄託側コンピュータと前記リポジトリ・マネージャとの間の通信を管理するように適合されている、請求項３に記載のシステム。
5. 前記リポジトリ・マネージャ、前記寄託側コンピュータ、および前記要求元コンピュータとの通信リンクを有するサーバをさらに含み、前記サーバが、
   前記リポジトリ・マネージャにアクセス可能な前記寄託側コンピュータの前記エージェント・プログラムと、
   前記リポジトリ・マネージャを安全に機能拡張させ、このリポジトリ・マネージャを使用して前記サーバ上で行われる他の環境との間の通信を管理するように適合された第２の環境と、
   前記要求元コンピュータを安全に機能拡張させ、この要求元コンピュータを使用して前記サーバ上で行われる他の環境との間の通信を管理するように適合された第３の環境とを少なくとも収納する、請求項４に記載のシステム。
6. 前記寄託側コンピュータの前記エージェント・プログラムが、前記寄託側コンピュータから受け取った電子データを暗号化してデジタル署名する手段と、暗号化した前記電子データおよび署名を前記データ・リポジトリに格納するために前記リポジトリ・マネージャに転送する手段とを含む、請求項４または５に記載のシステム。
7. 電子データのソースとは無関係にリポジトリ・マネージャによって管理されるデータ・リポジトリ内に格納された電子データへのユーザ・アクセスを安全に認証するための方法であって、
   ユーザ許可のアクセス制御リストを前記データ・リポジトリ内に格納されるとき前記電子データと関連付けるステップと、
   前記電子データの前記ソースから前記アクセス制御リストの更新を実行するステップと、
   前記更新されたアクセス制御リストを前記データ・リポジトリ内に格納された前記電子データと共に格納するステップと、
   前記電子データのソース側と更新を行った任意のユーザ・コンピュータ側に更新済みの前記アクセス制御リストの証拠を格納するステップと、
   前記電子データを要求元の許可ユーザに解放する前に前記ソース側に格納された前記証拠を使用して、前記電子データと共に前記データ・リポジトリ内に格納された前記更新済みアクセス制御リストの正確さを検証するステップとを含む方法。
8. 前記アクセス制御リストの更新を実行するステップが、
   更新された前記アクセス制御リストの改訂レベルを識別するステップと、
   現タイム・スタンプを前記更新されたアクセス制御リストに関連付けるステップとを含み、
   前記証拠を格納するステップが、
   前記改訂レベルと前記現タイム・スタンプのトークンを作成するステップと、
   前記データ・リポジトリ内の前記電子データにアクセスできるあらゆるユーザ・コンピュータ側に前記トークンを格納するステップとを含む、請求項７に記載の方法。
9. データ構造を形成するために前記更新済みアクセス制御リストに前記トークンを付けるステップと、
   前記データ構造にデジタル署名するステップと、
   署名付き前記データ構造を前記更新済みアクセス制御リストと共に前記データ・リポジトリ内および前記ソース側に格納するステップとをさらに含み、
   前記更新済みアクセス制御リストの正確さを検証するステップが、
   前記ソース側でデータ構造署名の暗号解読を検証するステップと、
   検証された前記データ構造を前記データ・リポジトリから取り出した前記更新済みアクセス制御リストと比較するステップとを含む、請求項８に記載の方法。
10. 前記証拠を格納するステップが、
    前記トークンにデジタル署名するステップと、
    署名付き前記トークンを前記ソース側に格納するステップとをさらに含む、請求項８に記載の方法。
11. デジタル署名付き前記トークンを、前記ソースから前記アクセス制御リストを更新する許可を与えられたユーザに転送するステップと、
    前記デジタル署名付きトークンが前記アクセス制御リストを更新する許可を与えられた前記ユーザによって提示される際に、
    前記ソース側でトークン署名を検証するステップと、
    検証された前記トークンを、前記データ・リポジトリから取り出した前記更新済みアクセス制御リストに関連する前記改訂レベルおよび現タイム・スタンプと比較するステップとをさらに含む、請求項１０に記載の方法。
12. 遠隔データ・リポジトリにおいて電子データを安全に格納し取り出すための方法であって、
    ソース側で前記電子データにデジタル署名するステップと、
    前記ソース側で前記電子データを暗号化するステップと、
    暗号化された前記電子データを前記データ・リポジトリに転送するステップと、
    寄託証明を作成するためにデータ・リポジトリ側で暗号化された前記電子データにデジタル署名するステップと、
    前記暗号化された電子データと前記寄託証明を前記データ・リポジトリに格納するステップと、
    前記寄託証明のコピーを前記ソース側に戻すステップとを含む方法。
13. 格納された前記電子データにアクセスすることを求める要求を要求元ユーザから受け取るステップと、
    暗号化された前記電子データを取り出し、取り出した前記データを前記ソース側に転送するステップと、
    前記要求元ユーザが前記電子データへのアクセスを許可されたユーザであるか否かを検証するステップと、
    確認された場合に前記取り出したデータの暗号解読を行うステップとをさらに含む、請求項１２に記載の方法。
14. ユーザ許可のアクセス制御リストを、前記データ・リポジトリ内に格納されたときに前記電子データと関連付けるステップと、
    前記電子データの前記ソース側から前記アクセス制御リストの更新を実行するステップと、
    更新済みの前記アクセス制御リストを前記データ・リポジトリ内に格納された前記電子データと共に格納するステップと、
    前記ソース側と前記データ・リポジトリ内の前記電子データへのアクセスを許可されたあらゆるユーザ側に前記更新済みアクセス制御リストの証拠を格納するステップとをさらに含む、請求項１３に記載の方法。
15. 前記要求元ユーザが許可されているか否かを検証するステップが、前記更新済みアクセス制御リストにその要求元ユーザを入れるステップを含む、請求項１４に記載の方法。
16. 前記電子データを前記要求元のユーザに解放する前に前記ソース側に格納された前記証拠を使用して、前記電子データと共に前記データ・リポジトリ内に格納された前記更新済みアクセス制御リストの正確さを検証するステップをさらに含む、請求項１５に記載の方法。
17. 請求項７ないし１６のいずれか一項に記載の方法をコンピュータで実行する際に使用するための命令を格納するコンピュータ可読メモリ。

Images