ファイルの保全性を保証するサーバコンピュータ
【課題】サーバコンピュータ上に記憶されたコンピュータファイルが不正変更されたときは、外部の第３の当事者はそのコピーを得ることはできないようにしたサーバコンピュータを提供する。
【解決手段】各々が関係する固有のディジタル署名をもっているコンピュータファイルを記憶し、該コンピュータファイルへのアクセスを受取るサーバコンピューは、関係するディジタル署名が有効であるときのみ、該コンピュータファイルへのアクセスを許可する。
【解決手段】各々が関係する固有のディジタル署名をもっているコンピュータファイルを記憶し、該コンピュータファイルへのアクセスを受取るサーバコンピューは、関係するディジタル署名が有効であるときのみ、該コンピュータファイルへのアクセスを許可する。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明はコンピュータファイルのサービスを供給するための方法および装置に関する。本発明は、とくにディジタル形式で署名されたコンピュータファイルの安全なサービスを供給する応用をもつ。
【背景技術】
【０００２】
いくつかの形態のサインを文書またはオブジェクトに関係付けて、例えばオーサーシップ（authorship）または所有権を示すという考えは長期にわたって存在している。人間の性質を不運に反映するものとして、これに関連する考えがあり、サインを文書またはオブジェクトに誤ってあるいは偽って関係付けて、誤ったあるいは偽ったオーサーシップまたは所有権を示してしまうといったことも長期にわたって存在している。
【０００３】
印刷機および印刷された文書、より最近ではディジタルまたは電子コンピュータおよびディジタルまたは電子文書が出現して、文書の忠実な再生と文書の便利な編集または変更とについての問題は相当に改善された。
【０００４】
周知のように、ディジタル形式の文書は一般的に、変化している文書の情報内容を表わしているディジタルのビットのみが変わるので、品質を変えずに所望の回数だけ変更およびコピーすることができる。ディジタルの文書は第１の当事者によって作成され、次に第２の当事者によって隠れて（内密に）変更されるとき、続いて第３の当事者（第三者）が文書を読み取って、文書が変更されたことを判断することは非常に困難である。
【０００５】
コンピュータ間のネットワーク通信の出現、特にインターネットおよびワールドワイドウエブの増加は、世界中の膨大な数のコンピュータが現在共通のプロトコルを使用して互いに通信できることを意味している。現在、電子文書はウエブサイト上でウエブページとして得られることが多い。
【０００６】
ワールドワイドウエブ（または、以下では単に‘ウエブ’）は多様な関係する概念および基準をもつことがよく知られている。これらの概念および基準に関係する豊富な情報はワールドワイドウエブコンソーシアム（World Wide Web Consortium, http://www.w3c.org）、すなわちマサチューセッツ工科大学（Massachusetts Institute of Technology, MIT）のコンピュータサイエンスの研究所によって主催（運営）された団体から得られる。‘ウエブサーバ(Web Server)’、‘ウエブサイト（Web Site）’、‘ウエブページ(Web Page)’、‘ウエブブラウザ（Web Browser）’、‘ハイパーリンク（Hyperlink）’、‘ユニフォームリソースロケータ（Uniform Resource Locator）’のような概念、および‘HyperText Transport Protocol, HTTP）’、‘HyperText Markup Language, HTML）’のような基準はよく知られている。
【０００７】
これらの当事者が、例えばワールドワイドウエブ上で電子文書またはファイルの形態をとる内容（コンテンツ）を分配したいときに直面する問題は、承認されていない第３の当事者が通信ネットワーク上で記憶された内容にアクセスして、意図的に変更することに対して内容の防備が甘いことである。
【０００８】
承認されていない第３の当事者が所与のウエブサーバにアクセスすると仮定すると、第３の当事者は、例えばこのウエブサーバ上に記憶されたウエブページを編集することができることになる。その後にウエブページがウエブブラウザで閲覧されるときは、ウエブページの内容は、元の内容のプロバイダではなく、第３の当事者のメッセージを反映することになる。
【０００９】
承認されていない第３の当事者が内容の所与の部分によって伝えられるメッセージを破壊することを試みる種々の動機が存在するが、全ての場合において、内容のプロバイダは勝手に手を加えられて、その後そのプロバイダ自身のものとしてブラウジングワールドへ送られた内容によって配信されるメッセージをもつことを選ばないと仮定することがおそらくは安全であることが理解されるであろう。
【００１０】
承認されていない第３の当事者による変更に対する記憶された内容の防備の弱さについてのこの問題に取り組む第１の今日のアプローチでは、記憶された内容に承認されていない第３の当事者がアクセスできないことを確実にすることを試みる。
【００１１】
このアプローチの１つの例は、いわゆる‘ファイアウオール’の使用である。周知のように、ファイアウオールを使用して、コンピュータとネットワークとの間のトラヒックを制御することによってネットワークに接続されたコンピュータを保護して、その結果コンピュータの管理者によって規定されるように、一定のタイプのトラヒックのみがトラヒックからコンピュータへ、またはその逆に送ることが許可される。理論上は、これは、承認されていない第３の当事者がネットワークからコンピュータにアクセスして、このコンピュータ上に記憶された内容を変更するのを防いでいる。もちろんこのようなファイアウオールは、悪意のあるユーザがファイアウオール内で適正に行う変更から記憶された内容を保護することはできない。
【００１２】
実際には、ファイアウオールの現実の構成は安全にはほど遠いことが多いことがよく分かるであろう。
【００１３】
第２のアプローチでは、記憶されたとき、または通信チャンネル上の伝送中に変更された内容は、ダウンロードされた内容について検査を行い、それが不正変更されたか否かを調べることに留意すべきである。
【００１４】
この第２のアプローチの１つの簡単な例では、いわゆる‘チェックサム’を使用する。周知のように、チェックサムは所与のデータブロックからコンピュータ処理され、導き出した値をこのデータブロックに関係付ける。チェックサムのコンピュータ処理が再び実行されるとき、データにおける変化がチェックサム値の変化を導く。チェックサム方法は、データ伝送中に破損を検出する簡単な検査として最も頻繁に使用されている。理論上は、内容の所与の部分が元のチェックサム値と一緒にダウンロードされるとき、新しいチェックサム値は、ダウンロードされた内容に対してコンピュータ処理され、次にこの内容と一緒に送られた元のチェックサム値と比較される。元のチェックサム値と新しく導き出されたチェックサム値とが同じとき、元のチェックサム値をコンピュータ処理した後、内容は変更されておらず、記憶されているか、または伝送中であると考えられている。
【００１５】
しかしながら実際には、承認されていない第３の当事者が、例えば記憶された内容にアクセスして、不正使用をすることが十分に可能であるときはそれに応じて元のチェックサムを変更することが十分に可能であることが分かるであろう。これが実行されたときは、内容がダウンロードされるときに実行されるチェックサムの比較は、内容が不正使用されなかったと誤って示すことになる。
【００１６】
この第２のアプローチのより高度な例は、いわゆる‘ディジタル署名’を使用することを含む。インターネット、およびより特定的にワールドワイドウエブが急激な増加を経験した過去数年間において、ディジタル署名の理論および実行は非常によく知られるようになった。
【００１７】
ディジタル署名の処理は、例えば、文献(‘Applied Cryptography: Protocols, Algorithms and Source Code in C’, Bruce Schneier, second edition 1996, John Wiley & Sons)に記載されている。ディジタル署名の別の処理は、文献（‘PGP: Pretty Good Privacy’, Simson Garfinkel, first edition 1995, O'Reilly & Associates）に記載されている。‘公開鍵（パブリックキー）’、‘秘密鍵（プライベートキー）’、‘ハッシュ機能’、および‘メッセージダイジェスト機能’のような用語がよく分かるであろう。
【００１８】
ディジタル署名技術は、いわゆる‘公開鍵’暗号方式を使用する。周知のように、公開鍵暗号法は、より以前からある対称鍵暗号法の単一の鍵ではなく、アルゴリズムにおいて関係する対の鍵、すなわち、いわゆる‘公開鍵’といわゆる‘秘密鍵’とを使用して、メッセージを暗号化する。公開鍵はパブリックドメインにおいて幅広く分配されることを意図されており、一方で秘密鍵は完全に秘密を保持されなければならない。非常に重要なこととして、公開鍵を知っていても、秘密鍵を判断することはできない。一般的に、公開鍵で暗号化されたメッセージはデクリプトされるが、デクリプトすることができるのは、対応する秘密鍵のみである。暗号化プロセスは対称的であるが、秘密鍵で行われた暗号化は公開鍵でデクリプトすることができる。所与の公開鍵でデクリプションに成功するとき、メッセージは整合する秘密鍵で暗号化されることが保証される。
【００１９】
公開鍵暗号法を使用して、通信チャンネルを安全保護する試行ができ、その結果この通信チャンネル上を送られる内容を傍受して、秘密を漏らすことはできなくなる。このような応用の１つの例は、Netscape Communications Corporation(Mountain View CA, USA)によって最初に開発されたSecure Socket Layer（ＳＳＬ）プロトコルである。例えばクライアントコンピュータとサーバコンピュータとの間の通信において、このようなＳＳＬプロトコルは最初に公開鍵の暗号化を使用してサーバコンピュータを認証し、次にクライアントとサーバコンピュータとの間の全ての別の通信を暗号化するのに使用する対称鍵を共有する。したがってＳＳＬのようなプロトコルは、第２のサーバコンピュータを装って、第２のサーバコンピュータからであると偽って示されているデータを供給することに対して第１のサーバコンピュータを保護し、承認されていない第３の当事者が伝送中に通信をインターセプトして変更するのを妨げる。しかしながらこのようなプロトコルは、記憶された内容が変更に対する防備が甘いといった問題を解決するのではなく、伝送中の内容を保護することを目的としている。
【００２０】
公開鍵暗号法を使用するディジタル署名技術は、ディジタル形式で署名された‘文書’が実際には、文書が保持している署名の当事者から送出されたことを保証する‘認証’としてだけでなく、送信元の当事者が文書をディジタル形式で署名してから文書の内容が不正変更されていないことを保証する‘保全性’としても検査をすることができる。
【００２１】
次に、ディジタル署名を使用して、ダウンロードされた内容に対して検査を行って、それが不正使用されたか、否かを判断するプロセスを、本発明に関してより詳しく記載することにする。この点はディジタル署名を使用することによって与えられる機能は第２のアプローチの次の例を検討することで十分である。
【００２２】
Microsoft Corporation(Redmond WA, USA)は、いわゆる“Authenticode（商標）”を開発した。Authenticode（商標）ソフトウエアはクライアントコンピュータ上にインストールされ、例えばサーバコンピュータからネットワーク上をダウンロードされたソフトウエアを検査し、ソフトウエアが承認されていないやり方で不正変更されたか否かを調べることに宛てられる。このような各コードはディジタル形式で署名される。ネットワーク上をダウンロードされたディジタル形式で署名された特定のコードに関して、コードをインストールまたは実行する前に、Authenticode(商標)はディジタル署名を検査して、それが有効であるか否かを調べる。クライアントのソフトウエアでAuthenticode(商標)の安全設定を‘高’、‘中’、または‘なし’から選択しなければならない。Authenticode(商標)は、‘高’設定では関係するディジタル署名が無効であることが分かっているコードのインストールまたは実行を許可しない。しかしながらAuthenticode(商標)は、‘中’設定ではユーザにこのコードが‘信用できない’ことを警告するが、ユーザが望むときはこのコードをインストールまたは実行するオプションを可能にする。Authenticode(商標)は、‘なし’の安全設定ではこのような警告を与えない。
【００２３】
明らかになることであるが、Authenticode(商標)のような構成は、クライアントへダウンロードされるコードをこのクライアントにおいて検査し、これのみが記憶された内容の保護を或る程度行うことができる。クライアントにおいて実行されるこのような検査は、クライアントコンピュータへ問題の内容を送ることを含む。このやり方では、不正使用された内容は依然としてネットワーク上をクライアントへ送られる。Authenticode(商標)のような構成は、‘信用できない’コードのインストールまたは実行を拒絶するように構成されているが、このコードは依然としてクライアントに存在し、十分な能力をもつユーザがそれにアクセスできないと保証できない。その代わりに、このような構成を変えて、‘信用できない’コードを望まれたときにインストールまたは実行できることが明らかである。
【００２４】
内容変更の問題に対して（記憶された内容へ承認されていない第３の当事者がアクセスできないことを保証することを試行する）第１のアプローチか、または（ダウンロードされた内容が不正使用されたか否かを調べるためにこのダウンロードされた内容に対して検査することを試行する）第２のアプローチにおいて、変更された内容が参照されないことが保証されることが分かるであろう。
【００２５】
第１の場合において、例えば関連するファイアウオールが破られ、ウエブサイトの管理者に気付かれずに記憶された内容が変更されたとき、ウエブサイトの管理者が気付くか、または変更を知らされて、修正動作がとられるときまで、変更された内容はウエブページにアクセスした者によって参照されることになる。
【００２６】
同じやり方で、第２の場合では、例えば関連するダウンロードされた内容のディジタル署名の認証に失敗したとき、上述のように、この内容は‘信用できない’と考えられるが、この内容を十分に‘ダウンローダ（downloader）’に対して開いて、‘信用できない’変更された内容を閲覧するか、さもなければ実行する。実際に、承認されていない第３の当事者によって不正使用されたというウエブページの評判は、ウエブサイトの管理者が修正動作をとる前にウエブページを閲覧したいと思わせる完全な理由であるという情況を想像することができる。ここでもダウンローダが、例えば信じられないファイルを実行するのを妨げられるとしても、このファイルは依然としてネットワーク上で送られていて、プロセス中のある点でファイルのコピーにアクセスすることが十分に可能である。
【発明の概要】
【００２７】
しかしながらこれらの今日のアプローチとは対照的に、本発明にしたがってサーバコンピュータであって：コンピュータファイルを記憶するようにされた手段と；ディジタル署名を記憶するようにされた手段と；各コンピュータファイルは関係するディジタル署名をもっていて；少なくとも1つの他のコンピュータから前記サーバコンピュータ上に記憶された少なくとも１つのコンピュータファイルにアクセスする要求を受取るようにされている手段と；該または各要求されたコンピュータファイルを検索するようにされた手段と；該または各要求されたコンピュータファイルを検索するようにされた手段と；該または各要求されたコンピュータファイルに関係するディジタル署名の有効性を検査するようにされた手段と；該または各それぞれ要求されたコンピュータファイルに関係するディジタル署名が有効であるときのみ、該または各要求されたコンピュータファイルへのアクセスを前記他のコンピュータへ与えるようにされている手段とを含むサーバコンピュータを提供する。
【００２８】
このやり方では、コンピュータファイルメモリのセキュリティが破られ、ファイルが不正使用されたとき、外部の当事者が不正変更の結果を調べることができないことを保証することが長所である。このコンピュータファイルに関係するディジタル署名が有効でなくても、コンピュータファイルへのアクセスは与えられない。とくに、コンピュータファイルに関係するディジタル署名が有効とされない限り、コンピュータファイルのコピーは、それが記憶されているファイルサーバコンピュータから取り出されなない。したがって、ファイルが不正使用されたときは、外部の第３の当事者はそのコピーを得ることはできない。元のコンピュータファイルのそれ自身の端部へのメッセージまたは機能が、承認されていない第３の当事者によって破壊される可能性はない。
【００２９】
サーバコンピュータを動作する方法も提供される。
【００３０】
ここで本発明の実施形態を例示的に添付の図面を参照して記載することにする。
【図面の簡単な説明】
【００３１】
【図１】通信ネットワークに接続された第１および第２の従来のコンピュータの図（図１Ａ）およびこのような従来のコンピュータの模式図（図１Ｂ）。
【図２】ディジタル文書をディジタルで署名する手続きのフローチャート。
【図３】図２のプロセスに含まれるエンティティを示す図。
【図４】ディジタルで署名された文書を供給する手続きのフローチャート。
【図５】ディジタルで署名された文書のディジタル署名を認証するための手続きのフローチャート。
【図６】図５のプロセスに関連するエンティティを示す図。
【発明を実施するための形態】
【００３２】
図１Ａは、ウエブサーバとして使用するのに適した従来の汎用コンピュータ100を示している。このようなコンピュータ100は図１Ｂに示されており、一般的に、少なくとも中央処理ユニット（central processing unit, ＣＰＵ）102；読取り専用メモリ（read-only memory, ＲＯＭ）104；ランダムアクセスメモリ（random-access memory, ＲＡＭ）106；ハードディスク108のようなメモリデバイス、フロッピー（登録商標）ディスクから読み取るか、またはそこへ書込むためのフロッピー（登録商標）ディスクドライブ110のようなメモリ媒体から読み取るか、またはそこへ書込むためのデバイス、並びに他のデバイスかまたは通信ネットワークへ接続するための入力および出力ポート112をもっている。
【００３３】
図１Ａを再び参照すると、フロッピー（登録商標）ディスク114が示されており、フロッピー（登録商標）ディスクドライブ110はこのフロッピー（登録商標）ディスク114から読み取るか、またはそこへ書込むことができる。コンピュータ100は通信ネットワーク116へ接続されており、通信ネットワーク116は、この実施形態では、例えば伝送制御プロトコル／インターネットプロトコル（Transmission Control Protocol/Internet Protocol, ＴＣＰ／ＩＰ）を使用する周知のインターネットとして理解される。第２の従来の汎用コンピュータ118は、ウエブクライアントとして使用するのに適しており、同様にインターネット通信ネットワーク116へ接続されている。
【００３４】
コンピュータ100は適切なオペレーティングシステムを使用することができ、例えばMicrosoft Windows（登録商標）ＮＴ、Linux（登録商標）、またはUnix（登録商標）の他の多くのバージョンの何れか１つがよく知られている。アプリケーションプログラムは、アプリケーションプログラムを書くための多くの周知の適切な言語の何れかで書くことができ、周知の例の１つはＣ＋＋である。このようなオペレーティングシステムおよびアプリケーションプログラムは、コンピュータ100のメモリデバイス108へロードすることができる。
【００３５】
本発明のこの実施形態にしたがって開示される機能は、コンピュータ100によって実行されるソフトウエアモジュールのアプリケーションプログラムとして実行することができる。このソフトウエアアプリケーションプログラムは、適切なコンピュータの読取り可能なメモリ媒体の形態をとる、例えばフロッピー（登録商標）ディスク114上に記憶され、実行のためには、フロッピー（登録商標）ディスクドライブ110を介して、コンピュータ100へロードする。周知の代わりのアプリケーションプログラムは、ＣＤ−ＲＯＭ（図示されていない）上にソフトウエアアプリケーションを記憶し、実行のためには、ＣＤ−ＲＯＭドライブ（図示されていない）を介してコンピュータ100へロードする。別の周知の代わりのアプリケーションプログラムでは、コンピュータ100によって実行するために、ネットワーク116上にソフトウエアアプリケーションプログラムをダウンロードする。
【００３６】
この実施形態では、コンピュータ100は、ソフトウエアアプリケーションプログラムをロードされていて、このプログラムが実行されると、コンピュータ100はウエブサーバとして動作する。ウエブ文書は、従来のように、ウエブサーバの適切なメモリデバイス上に記憶される。
【００３７】
ウエブブラウザプログラムを含む、第２のコンピュータ108上にロードされるソフトウエアアプリケーションプログラムは、実行されると、ワールドワイドウエブプロトコルを使用して通信をイネーブルし、特にウエブページ、ウエブサーバコンピュータ100上でホストされたウエブページを、例えばウエブブラウザを使用して、閲覧（view）できるようにする。
【００３８】
ここで従来のディジタル署名プロセスを図２および３に関連して記載することにする。図２および３の構造は忠実に反映されていることが分かるであろう；図２はディジタルかまたは電子の文書のディジタル署名プロセスの手続きのフローチャートを示しており、一方で図３は簡単なやり方で対応するエンティティの振舞いを示している。手続きのフローチャートに示されている段階は、ウエブサーバ100上を走るソフトウエアアプリケーションを実行することによって行われることも分かるであろう。
【００３９】
この実施形態の例として、検討されているウエブ文書はウエブページであり、一般的に、ウエブサーバ100の適切なメモリデバイス、この例ではハードディスク上に記憶されたHyperText Markup Language（ＨＴＭＬ）の文書である。しかしながらこの例は無限であり；すなわち本発明にしたがって多くの他の形態のコンピュータファイル（例えば、ＨＴＭＬ以外のフォーマットの文書、例えばJoint Photographic Experts Group（ＪＰＥＧ）フォーマットの画像、およびダウンロードできるソフトウエアプログラム）も同様に処理するできることに注意すべきである。
【００４０】
第1の段階200では、ディジタル署名をするための文書が選択される。このような文書300は図３に示した。
【００４１】
第２の段階202では、署名される文書は、いわゆる‘ハッシュ’機能を通される。ハッシュ機能はこの文書の短い表示を生成し、これはしばしば文書の‘ハッシュ’と呼ばれる。署名される文書300はおよび署名される文書のハッシュ302は図３に模式的に示されている。ハッシュ機能および文書のハッシュは、代わりに、それぞれ‘メッセージダイジェスト’機能および‘メッセージダイジェスト’と呼ばれることがよくある。２つの周知のハッシュ機能の例はＭＤ５およびＳＨＡハッシュ機能である。
【００４２】
ハッシュ機能によって生成された文書のハッシュはその文書の内容に対する感度が著しく高いことがよく知られている。例えば、テキスト文書が終止符の挿入のみによって変更されるとき、終止符を挿入する前に生成されたハッシュおよび終止符の挿入後に挿入されたハッシュは、概して完全に異なる。
【００４３】
第３の段階204において、ディジタル署名は秘密鍵を使用して文書のハッシュを暗号化することによって作成される。この秘密鍵は、例えば内容の作成者、内容の所有者、または内容の管理者を含む多数の当事者の何れかの秘密鍵であることが分かるであろう。認可された署名する当事者が関係する認可された秘密鍵をもつ概念については後で記載することにする。署名される文書のハッシュ302およびディジタル署名304を図３に示した。
【００４４】
署名される文書のためのディジタル署名は、作成されると、ウエブサーバ100の適切なメモリデバイス、この例ではハードディスク上に記憶される。
【００４５】
その代わりにオプションの第４の段階206において、このように作成されたディジタル署名は、署名される文書に添付されて、ディジタル形式で署名された文書を作成する。ディジタル形式で署名された文書306は図３に示されている。次にディジタル形式で署名された文書は、ウエブサーバ100の適切なメモリデバイス、この例ではハードディスク上に記憶することができる。
【００４６】
本発明の文書供給プロセスを図１、４、５、および６に関連して記載する。ここでも手続きのフローチャート内に示された段階は、ウエブサーバ100上を走るソフトウエアアプリケーションを実行することによって行なわれることが分かるであろう。
【００４７】
図１および４に関して、第１の段階400において、ウエブサーバ100は第２のコンピュータ114から、ウエブサーバ100上に記憶された所与のウエブページへアクセスするための要求を受取る。よく知られているように、この要求は一般的に、第２のコンピュータ114のユーザがハイパーリンク上をクリックすることによって開始され、このユニフォームリソースロケータ（ＵＲＬ）が所与のウエブページを指示する。さらによく知られているように、ウエブサーバ100は、クライアントから到来する接続を受取るためのＴＣＰポート80を監視するプロセスをもつ。ＴＣＰ接続が設定されると、ウエブページに対するＨＴＴＰ要求が上述のように行われる。
【００４８】
第２の段階402において、ＵＲＬ要求に対応するウエブページは、ウエブサーバ100の適切なメモリデバイス、この例ではハードディスクから検索される。
【００４９】
第３の段階404では、このウエブページに対応するディジタル署名も、ウエブサーバの適切なメモリデバイス、この例ではハードディスクから検索される。ディジタル署名が、上述のオプションの段階206にしたがって文書に既に添付されているときは、この段階は文書自体を検索するときに行なわれることが分かるであろう。
【００５０】
第４の段階406では、文書に関係するディジタル署名の有効性が検査される。
【００５１】
ディジタル署名の妥当性検査プロセスの手続きのフローチャートは図５および６に記載した。ここで段階406に用意されたこのディジタル署名の妥当性検査プロセスを、図４に示した段階の記載に戻る前に、図５および６に関連して記載することにする。図５および６の構造は忠実に反映されていることが認識され：図５はディジタル署名の妥当性検査プロセスの手続きのフローチャートを示しており、一方で図６は対応するエンティティの振舞いを簡単に示している。
【００５２】
図５に関連して、第１の段階500において、文書に関係するディジタル署名は公開鍵でデクリプトされ、この場合に秘密鍵に対応する公開鍵を使用して、最初に文書のハッシュまたはメッセージダイジェストに署名する。周知のように、このデクリプションによって文書のハッシュが得られる。要求された文書に関係するディジタル署名600およびデクリプションによって得られたハッシュ602は図６に示した。
【００５３】
第２の段階502において、文書は再び、文書をディジタル形式で署名するプロセスで最初に使用されたのと同じハッシュ機能を実行される。こうして文書の新しいハッシュが導き出される。文書604および文書の新しいハッシュ606は図６示されている。
【００５４】
要求された文書に関係するディジタル署名をデクリプトするのに使用される公開鍵が、文書のハッシュに署名するのに使用される秘密鍵に整合する公開鍵でないとき、ディジタル署名は正しくデクリプトされない。その結果、デクリプションによって得られた文書のハッシュは正しいものでなくなり、文書の新しいハッシュと異なることになる。同様に、文書がハッシュの生成を含む文書への署名と新しいハッシュの生成との間で変更されるとき、ハッシュと新しいハッシュとは異なることがさらに分かるであろう。
【００５５】
その結果、段階504において、文書のハッシュと文書の新しいハッシュとが比較される。文書のハッシュ602と文書の新しいハッシュ606との比較は、図６に模式的に示されている。
【００５６】
ハッシュと新しいハッシュとが同じであるとき、文書に署名したと考えられる当事者が、現実に文書に署名した（すなわち、デクリプションに使用された公開鍵が、文書に署名するのに使用された秘密鍵に正しく整合している）ことが保証されるだけでなく、ディジタル署名を生成してから文書が変更されていない（すなわち、文書のハッシュと文書の新しいハッシュとは同一である）ことも保証される。文書のハッシュと文書の新しいハッシュとを比較して、段階406に示された認証の照会に対する結果を戻す。要求された文書に関係するディジタル署名は、妥当性検査試験に通るときと、通らないときがある。
【００５７】
ここで図４を再び参照して文書供給プロセスについて検討する。
【００５８】
ディジタル署名が有効であると、第５の段階408において、ウエブサーバは従来のやり方でウエブページを要求している当事者へ送ることを始める。
【００５９】
より一般的な場合に、コンピュータファイルに関係するディジタル署名が有効であると、サーバコンピュータは、全てのファイルを一度にクライアントコンピュータへ送るのではなく、コンピュータファイルへのアクセスを許可することに注意すべきである。例示的に、サーバコンピュータはその代わりにクライアントコンピュータと通信セッションを開き、ファイルの一部を要求に応じてクライアントコンピュータへ流す。
【００６０】
しかしながらディジタル署名が有効でないとき、すなわち文書が、その文書に関係するディジタル署名が作成されてから変更されたか、または文書が現実に文書に署名したと表示された人以外の人によって署名されたときは、ウエブサーバが文書を送り始めることは絶対にない。その代わりに、第６の段階410において、ウエブサーバはウエブページを要求している当事者へ送り、要求しているウエブページが有効でないことを知らせる。
【００６１】
第７の段階412では、ウエブサーバは、例えば、無効のディジタル署名に関する警告を含むメッセージをシステムの管理者へ送る。
【００６２】
現在、公開鍵の処理は比較的に緩慢であり、ハッシュ機能または対称鍵の処理よりも１００ないし１０００倍程度緩慢であることに注意すべきである。ウエブサーバが、供給された各文書に対してディジタル署名を検査するとき、これが直ぐに動作の隘路になることが分かるであろう。この問題を改善するために、ディジタル署名の検査のために最適化された専用のハードウエアボードを使用することができる。このようなボードの１つの例としては、nCipher(Cambridge, United Kingdom)によって生成されたものがある。このような各ボードは一般的に、１秒間に数百のディジタル署名を検査することができ、要求に応じて別のボードをデイジーチェーン接続することもできる。
【００６３】
既に記載したように、‘それらの’文書の１つをディジタル形式で署名したい当事者が数多くいる可能性は相当に高い。このような各当事者は、自身の秘密鍵をもち、これを使用して、関連する暗号化を行う。したがってディジタル形式で署名された各ファイルを関連する署名する当事者に関係付けることができる手段を用意することが必要であり、その結果適切に整合した公開鍵はディジタル署名の認証に使用できる。
【００６４】
各ディジタル形式で署名されたファイルと署名する当事者とを関係付けることができる手段は、１つの例では署名する当事者のディジタルの証明のコピーをディジタル形式で署名されたファイルに添付するだけである。図２に関して、これは、例えば、段階206に続く段階で行われる。ディジタル証明の周知の概念は、ディジタル署名の概念に密接に関連しており、ここでは詳しく記載しない。ディジタル証明は当事者の識別子をその当事者の公開鍵と結合し、このディジタル証明自体は、普通は第三者機関（Trusted Third Party, ＴＴＰ）を示す第３の当事者によって署名されることのみに注意するべきである。
【００６５】
このやり方で、図４に関連して、段階402および404においてディジタル形式で署名されたファイルが検索されるとき、添付されたディジタル証明も検索される。ディジタル証明は、署名する当事者の識別子および署名する当事者の関係する公開鍵とを与える。図５に関連して、段階500において公開鍵を使用して、認証プロセスにおいて要求されるようにディジタル形式で署名された文書のハッシュを得ることができる。
【００６６】
ファイルに添付されたディジタル証明が署名する当事者のディジタル証明でないとき、認証は失敗する。しかしながら承認されていない第３の当事者がディジタル形式で署名されたファイルを整合したディジタル証明をもつウエブサーバへなんとか密かにもちだすことについて検討する。そこで発生する従属的な問題は、その当事者の制御がその特定のウエブサイト上に記憶する文書に署名することを認証されている。
【００６７】
認証された署名する当事者のリストはウエブサーバ上で構成され、記憶されるようにでき；認証された署名する当事者のディジタル証明のみを有効に使用することができる。承認されていない第３の当事者に対する次の攻撃地点は、誤った‘承認された’署名する当事者をリストに加えることを試行するので、このリストは、システムの管理者の秘密鍵によってそれに署名することによって、それ自体を保護することができる。このやり方では、システム管理者の公開鍵を使用してリストを読み取ることができ、したがって、上述の記憶された文書のように、リストが不正使用されておらず、現実にシステムの管理者から発信していることを保証する。
【００６８】
関心をもっている別の問題は、‘寿命’が制限されている文書が所定の時刻または日付を過ぎると供給されないことを保証することである。図２に関して、これは段階206に続く段階で、ディジタル形式で署名されたファイルに‘期限切れ時刻または日付のスタンプ’を付加することによって達成される。この期限切れ時刻のスタンプが損われるのを防ぐために、期限切れ時刻のスタンプを添付されたディジタル形式で署名された文書自体は、さらに別の段階において、例えばシステム管理者の秘密鍵で署名される。
【００６９】
図４に関連して、この場合に、ディジタル形式で署名された文書が検索されるとき、段階402および404において、ディジタル形式で署名される文書は添付された期限切れ時刻−スタンプをもち、システムの管理者によって署名される。別の段階では、期限切れの時刻−スタンプは最初に、システムの管理者の公開鍵でディジタル形式で署名された文書をデクリプトすることによって検索される。さらに別の段階では、関連する時刻または日付が過ぎたか否かを調べるために検査が行われる。関連する時刻または日付が過ぎているときは、文書は供給されない。
【００７０】
ここで本発明のこの実施形態の簡単な応用を記載する。図１に示したウエブサーバは協働するウエブサイトのホストとして働くために採用されている。ウエブサーバは一般的に、既に記載したように協働するファイアウオールによって保護される。インターネットに接続されていて、ウエブブラウザを適切に装備した一般のコンピュータを使用して、この協働するウエブサイト上でウエブページを閲覧することができる。周知のように、これらのウエブページは一般に、会社に関する情報を全世界へ送るために使用される。
【００７１】
第１の情況として、会社がウエブページの形態の文書をその協働するウエブサイト上にポストすることについて検討する。文書は、上述の図２および３についての記述にしたがって会社の秘密鍵を使用してディジタル形式で署名されている。一般のメンバは、典型的に文書に関係するハイパーリンク上をクリックすることによって、この文書へのアクセスを要求する。上述の図４、５、および６についての記載にしたがって、ウエブサーバは文書のディジタル署名の認証を実行する。この第１の情況において、認証は成功し、一般のメンバに供給されたウエブページはその後は事もなく要求を行う。
【００７２】
ここで第２の情況として、会社がウエブページの形態の文書をその協働するウエブサイト上にポストすることについて検討する。文書は、図２および３に関する既に記載された部分にしたがって、例えば会社の秘密鍵を使用してディジタル形式で署名される。しかしながらこの情況では、協働するウエブサイトの管理者に気付かれずに、協働するファイアウオールは損われ、承認されていない第３の当事者がウエブサーバへのアクセスを得る。このアクセスを使用して、承認されていない第３の当事者は、ウエブサーバ上に記憶されたウエブページを変更することを始める。この承認されていない第３の当事者によって実行される変更は、このような攻撃を展開する動機に依存しているが；都合の悪いことに、悪ふざけ（prank）から明らかな妨害行為（sabotage）までの広範囲の動機を考えてしまい易い。
【００７３】
ここで一般公衆のメンバは、承認されていない第３の当事者によって変更された文書へのアクセスを要求していると考えられる。図４、５、および６についての既に記載された部分にしたがって、ウエブサーバは文書のディジタル署名の認証を実行する。この第２の情況では、文書のハッシュと文書の新しいハッシュとが整合しないために認証は失敗する。
【００７４】
したがってウエブページは、要求を行う一般のメンバへは供給されない。したがって、要求を行う一般のメンバは変更された文書を全く参照できないことは極めて重要である。
【００７５】
既に記載したように、承認されていない第３の当事者の侵入者の動機に適するように変更されたウエブページを要求を行っている一般のメンバへ供給することが許可されているとき、この文書は‘信用できない’という警告があっても、会社の商取引または評判にダメージを与えてしまう。
【００７６】
ここで第３の情況について検討する。この第３の情況では再び、協働するウエブサイトの管理者に知られずに、協働するファイアウオールは損われ、承認されていない第３の当事者がウエブサーバへのアクセスを得る。このアクセスを使用して、承認されていない第３の当事者はウエブページの形態をとる偽造された文書を会社の協働するウエブサイト上にポストする。文書は、図２および３について既に記載された部分にしたがって第３の当事者によってディジタル形式で署名されるが、署名プロセスで使用される秘密鍵は、会社ではなく、承認されていない第３の当事者によって選択されたものである。
【００７７】
ここで承認されていない第３の当事者によって変更された文書へのアクセスを要求することについて検討する。図４、５、および６について既に記載された部分にしたがって、ウエブサーバは文書のディジタル署名の認証を行う。この第３の情況では、認証は再び失敗する。ディジタル署名が承認されていない第３の当事者の秘密鍵で署名されたときに、会社の公開鍵でディジタル署名をデクリプトすることを試行することにより、文書のハッシュと文書の新しいハッシュとの不正合が再び発生する。
【００７８】
したがってさらにここでもウエブページは要求を行っている一般のメンバへ供給されず、したがってここでも要求をしている一般のメンバが変更された文書を全く参照できないことは非常に重要である。
【技術分野】
【０００１】
本発明はコンピュータファイルのサービスを供給するための方法および装置に関する。本発明は、とくにディジタル形式で署名されたコンピュータファイルの安全なサービスを供給する応用をもつ。
【背景技術】
【０００２】
いくつかの形態のサインを文書またはオブジェクトに関係付けて、例えばオーサーシップ（authorship）または所有権を示すという考えは長期にわたって存在している。人間の性質を不運に反映するものとして、これに関連する考えがあり、サインを文書またはオブジェクトに誤ってあるいは偽って関係付けて、誤ったあるいは偽ったオーサーシップまたは所有権を示してしまうといったことも長期にわたって存在している。
【０００３】
印刷機および印刷された文書、より最近ではディジタルまたは電子コンピュータおよびディジタルまたは電子文書が出現して、文書の忠実な再生と文書の便利な編集または変更とについての問題は相当に改善された。
【０００４】
周知のように、ディジタル形式の文書は一般的に、変化している文書の情報内容を表わしているディジタルのビットのみが変わるので、品質を変えずに所望の回数だけ変更およびコピーすることができる。ディジタルの文書は第１の当事者によって作成され、次に第２の当事者によって隠れて（内密に）変更されるとき、続いて第３の当事者（第三者）が文書を読み取って、文書が変更されたことを判断することは非常に困難である。
【０００５】
コンピュータ間のネットワーク通信の出現、特にインターネットおよびワールドワイドウエブの増加は、世界中の膨大な数のコンピュータが現在共通のプロトコルを使用して互いに通信できることを意味している。現在、電子文書はウエブサイト上でウエブページとして得られることが多い。
【０００６】
ワールドワイドウエブ（または、以下では単に‘ウエブ’）は多様な関係する概念および基準をもつことがよく知られている。これらの概念および基準に関係する豊富な情報はワールドワイドウエブコンソーシアム（World Wide Web Consortium, http://www.w3c.org）、すなわちマサチューセッツ工科大学（Massachusetts Institute of Technology, MIT）のコンピュータサイエンスの研究所によって主催（運営）された団体から得られる。‘ウエブサーバ(Web Server)’、‘ウエブサイト（Web Site）’、‘ウエブページ(Web Page)’、‘ウエブブラウザ（Web Browser）’、‘ハイパーリンク（Hyperlink）’、‘ユニフォームリソースロケータ（Uniform Resource Locator）’のような概念、および‘HyperText Transport Protocol, HTTP）’、‘HyperText Markup Language, HTML）’のような基準はよく知られている。
【０００７】
これらの当事者が、例えばワールドワイドウエブ上で電子文書またはファイルの形態をとる内容（コンテンツ）を分配したいときに直面する問題は、承認されていない第３の当事者が通信ネットワーク上で記憶された内容にアクセスして、意図的に変更することに対して内容の防備が甘いことである。
【０００８】
承認されていない第３の当事者が所与のウエブサーバにアクセスすると仮定すると、第３の当事者は、例えばこのウエブサーバ上に記憶されたウエブページを編集することができることになる。その後にウエブページがウエブブラウザで閲覧されるときは、ウエブページの内容は、元の内容のプロバイダではなく、第３の当事者のメッセージを反映することになる。
【０００９】
承認されていない第３の当事者が内容の所与の部分によって伝えられるメッセージを破壊することを試みる種々の動機が存在するが、全ての場合において、内容のプロバイダは勝手に手を加えられて、その後そのプロバイダ自身のものとしてブラウジングワールドへ送られた内容によって配信されるメッセージをもつことを選ばないと仮定することがおそらくは安全であることが理解されるであろう。
【００１０】
承認されていない第３の当事者による変更に対する記憶された内容の防備の弱さについてのこの問題に取り組む第１の今日のアプローチでは、記憶された内容に承認されていない第３の当事者がアクセスできないことを確実にすることを試みる。
【００１１】
このアプローチの１つの例は、いわゆる‘ファイアウオール’の使用である。周知のように、ファイアウオールを使用して、コンピュータとネットワークとの間のトラヒックを制御することによってネットワークに接続されたコンピュータを保護して、その結果コンピュータの管理者によって規定されるように、一定のタイプのトラヒックのみがトラヒックからコンピュータへ、またはその逆に送ることが許可される。理論上は、これは、承認されていない第３の当事者がネットワークからコンピュータにアクセスして、このコンピュータ上に記憶された内容を変更するのを防いでいる。もちろんこのようなファイアウオールは、悪意のあるユーザがファイアウオール内で適正に行う変更から記憶された内容を保護することはできない。
【００１２】
実際には、ファイアウオールの現実の構成は安全にはほど遠いことが多いことがよく分かるであろう。
【００１３】
第２のアプローチでは、記憶されたとき、または通信チャンネル上の伝送中に変更された内容は、ダウンロードされた内容について検査を行い、それが不正変更されたか否かを調べることに留意すべきである。
【００１４】
この第２のアプローチの１つの簡単な例では、いわゆる‘チェックサム’を使用する。周知のように、チェックサムは所与のデータブロックからコンピュータ処理され、導き出した値をこのデータブロックに関係付ける。チェックサムのコンピュータ処理が再び実行されるとき、データにおける変化がチェックサム値の変化を導く。チェックサム方法は、データ伝送中に破損を検出する簡単な検査として最も頻繁に使用されている。理論上は、内容の所与の部分が元のチェックサム値と一緒にダウンロードされるとき、新しいチェックサム値は、ダウンロードされた内容に対してコンピュータ処理され、次にこの内容と一緒に送られた元のチェックサム値と比較される。元のチェックサム値と新しく導き出されたチェックサム値とが同じとき、元のチェックサム値をコンピュータ処理した後、内容は変更されておらず、記憶されているか、または伝送中であると考えられている。
【００１５】
しかしながら実際には、承認されていない第３の当事者が、例えば記憶された内容にアクセスして、不正使用をすることが十分に可能であるときはそれに応じて元のチェックサムを変更することが十分に可能であることが分かるであろう。これが実行されたときは、内容がダウンロードされるときに実行されるチェックサムの比較は、内容が不正使用されなかったと誤って示すことになる。
【００１６】
この第２のアプローチのより高度な例は、いわゆる‘ディジタル署名’を使用することを含む。インターネット、およびより特定的にワールドワイドウエブが急激な増加を経験した過去数年間において、ディジタル署名の理論および実行は非常によく知られるようになった。
【００１７】
ディジタル署名の処理は、例えば、文献(‘Applied Cryptography: Protocols, Algorithms and Source Code in C’, Bruce Schneier, second edition 1996, John Wiley & Sons)に記載されている。ディジタル署名の別の処理は、文献（‘PGP: Pretty Good Privacy’, Simson Garfinkel, first edition 1995, O'Reilly & Associates）に記載されている。‘公開鍵（パブリックキー）’、‘秘密鍵（プライベートキー）’、‘ハッシュ機能’、および‘メッセージダイジェスト機能’のような用語がよく分かるであろう。
【００１８】
ディジタル署名技術は、いわゆる‘公開鍵’暗号方式を使用する。周知のように、公開鍵暗号法は、より以前からある対称鍵暗号法の単一の鍵ではなく、アルゴリズムにおいて関係する対の鍵、すなわち、いわゆる‘公開鍵’といわゆる‘秘密鍵’とを使用して、メッセージを暗号化する。公開鍵はパブリックドメインにおいて幅広く分配されることを意図されており、一方で秘密鍵は完全に秘密を保持されなければならない。非常に重要なこととして、公開鍵を知っていても、秘密鍵を判断することはできない。一般的に、公開鍵で暗号化されたメッセージはデクリプトされるが、デクリプトすることができるのは、対応する秘密鍵のみである。暗号化プロセスは対称的であるが、秘密鍵で行われた暗号化は公開鍵でデクリプトすることができる。所与の公開鍵でデクリプションに成功するとき、メッセージは整合する秘密鍵で暗号化されることが保証される。
【００１９】
公開鍵暗号法を使用して、通信チャンネルを安全保護する試行ができ、その結果この通信チャンネル上を送られる内容を傍受して、秘密を漏らすことはできなくなる。このような応用の１つの例は、Netscape Communications Corporation(Mountain View CA, USA)によって最初に開発されたSecure Socket Layer（ＳＳＬ）プロトコルである。例えばクライアントコンピュータとサーバコンピュータとの間の通信において、このようなＳＳＬプロトコルは最初に公開鍵の暗号化を使用してサーバコンピュータを認証し、次にクライアントとサーバコンピュータとの間の全ての別の通信を暗号化するのに使用する対称鍵を共有する。したがってＳＳＬのようなプロトコルは、第２のサーバコンピュータを装って、第２のサーバコンピュータからであると偽って示されているデータを供給することに対して第１のサーバコンピュータを保護し、承認されていない第３の当事者が伝送中に通信をインターセプトして変更するのを妨げる。しかしながらこのようなプロトコルは、記憶された内容が変更に対する防備が甘いといった問題を解決するのではなく、伝送中の内容を保護することを目的としている。
【００２０】
公開鍵暗号法を使用するディジタル署名技術は、ディジタル形式で署名された‘文書’が実際には、文書が保持している署名の当事者から送出されたことを保証する‘認証’としてだけでなく、送信元の当事者が文書をディジタル形式で署名してから文書の内容が不正変更されていないことを保証する‘保全性’としても検査をすることができる。
【００２１】
次に、ディジタル署名を使用して、ダウンロードされた内容に対して検査を行って、それが不正使用されたか、否かを判断するプロセスを、本発明に関してより詳しく記載することにする。この点はディジタル署名を使用することによって与えられる機能は第２のアプローチの次の例を検討することで十分である。
【００２２】
Microsoft Corporation(Redmond WA, USA)は、いわゆる“Authenticode（商標）”を開発した。Authenticode（商標）ソフトウエアはクライアントコンピュータ上にインストールされ、例えばサーバコンピュータからネットワーク上をダウンロードされたソフトウエアを検査し、ソフトウエアが承認されていないやり方で不正変更されたか否かを調べることに宛てられる。このような各コードはディジタル形式で署名される。ネットワーク上をダウンロードされたディジタル形式で署名された特定のコードに関して、コードをインストールまたは実行する前に、Authenticode(商標)はディジタル署名を検査して、それが有効であるか否かを調べる。クライアントのソフトウエアでAuthenticode(商標)の安全設定を‘高’、‘中’、または‘なし’から選択しなければならない。Authenticode(商標)は、‘高’設定では関係するディジタル署名が無効であることが分かっているコードのインストールまたは実行を許可しない。しかしながらAuthenticode(商標)は、‘中’設定ではユーザにこのコードが‘信用できない’ことを警告するが、ユーザが望むときはこのコードをインストールまたは実行するオプションを可能にする。Authenticode(商標)は、‘なし’の安全設定ではこのような警告を与えない。
【００２３】
明らかになることであるが、Authenticode(商標)のような構成は、クライアントへダウンロードされるコードをこのクライアントにおいて検査し、これのみが記憶された内容の保護を或る程度行うことができる。クライアントにおいて実行されるこのような検査は、クライアントコンピュータへ問題の内容を送ることを含む。このやり方では、不正使用された内容は依然としてネットワーク上をクライアントへ送られる。Authenticode(商標)のような構成は、‘信用できない’コードのインストールまたは実行を拒絶するように構成されているが、このコードは依然としてクライアントに存在し、十分な能力をもつユーザがそれにアクセスできないと保証できない。その代わりに、このような構成を変えて、‘信用できない’コードを望まれたときにインストールまたは実行できることが明らかである。
【００２４】
内容変更の問題に対して（記憶された内容へ承認されていない第３の当事者がアクセスできないことを保証することを試行する）第１のアプローチか、または（ダウンロードされた内容が不正使用されたか否かを調べるためにこのダウンロードされた内容に対して検査することを試行する）第２のアプローチにおいて、変更された内容が参照されないことが保証されることが分かるであろう。
【００２５】
第１の場合において、例えば関連するファイアウオールが破られ、ウエブサイトの管理者に気付かれずに記憶された内容が変更されたとき、ウエブサイトの管理者が気付くか、または変更を知らされて、修正動作がとられるときまで、変更された内容はウエブページにアクセスした者によって参照されることになる。
【００２６】
同じやり方で、第２の場合では、例えば関連するダウンロードされた内容のディジタル署名の認証に失敗したとき、上述のように、この内容は‘信用できない’と考えられるが、この内容を十分に‘ダウンローダ（downloader）’に対して開いて、‘信用できない’変更された内容を閲覧するか、さもなければ実行する。実際に、承認されていない第３の当事者によって不正使用されたというウエブページの評判は、ウエブサイトの管理者が修正動作をとる前にウエブページを閲覧したいと思わせる完全な理由であるという情況を想像することができる。ここでもダウンローダが、例えば信じられないファイルを実行するのを妨げられるとしても、このファイルは依然としてネットワーク上で送られていて、プロセス中のある点でファイルのコピーにアクセスすることが十分に可能である。
【発明の概要】
【００２７】
しかしながらこれらの今日のアプローチとは対照的に、本発明にしたがってサーバコンピュータであって：コンピュータファイルを記憶するようにされた手段と；ディジタル署名を記憶するようにされた手段と；各コンピュータファイルは関係するディジタル署名をもっていて；少なくとも1つの他のコンピュータから前記サーバコンピュータ上に記憶された少なくとも１つのコンピュータファイルにアクセスする要求を受取るようにされている手段と；該または各要求されたコンピュータファイルを検索するようにされた手段と；該または各要求されたコンピュータファイルを検索するようにされた手段と；該または各要求されたコンピュータファイルに関係するディジタル署名の有効性を検査するようにされた手段と；該または各それぞれ要求されたコンピュータファイルに関係するディジタル署名が有効であるときのみ、該または各要求されたコンピュータファイルへのアクセスを前記他のコンピュータへ与えるようにされている手段とを含むサーバコンピュータを提供する。
【００２８】
このやり方では、コンピュータファイルメモリのセキュリティが破られ、ファイルが不正使用されたとき、外部の当事者が不正変更の結果を調べることができないことを保証することが長所である。このコンピュータファイルに関係するディジタル署名が有効でなくても、コンピュータファイルへのアクセスは与えられない。とくに、コンピュータファイルに関係するディジタル署名が有効とされない限り、コンピュータファイルのコピーは、それが記憶されているファイルサーバコンピュータから取り出されなない。したがって、ファイルが不正使用されたときは、外部の第３の当事者はそのコピーを得ることはできない。元のコンピュータファイルのそれ自身の端部へのメッセージまたは機能が、承認されていない第３の当事者によって破壊される可能性はない。
【００２９】
サーバコンピュータを動作する方法も提供される。
【００３０】
ここで本発明の実施形態を例示的に添付の図面を参照して記載することにする。
【図面の簡単な説明】
【００３１】
【図１】通信ネットワークに接続された第１および第２の従来のコンピュータの図（図１Ａ）およびこのような従来のコンピュータの模式図（図１Ｂ）。
【図２】ディジタル文書をディジタルで署名する手続きのフローチャート。
【図３】図２のプロセスに含まれるエンティティを示す図。
【図４】ディジタルで署名された文書を供給する手続きのフローチャート。
【図５】ディジタルで署名された文書のディジタル署名を認証するための手続きのフローチャート。
【図６】図５のプロセスに関連するエンティティを示す図。
【発明を実施するための形態】
【００３２】
図１Ａは、ウエブサーバとして使用するのに適した従来の汎用コンピュータ100を示している。このようなコンピュータ100は図１Ｂに示されており、一般的に、少なくとも中央処理ユニット（central processing unit, ＣＰＵ）102；読取り専用メモリ（read-only memory, ＲＯＭ）104；ランダムアクセスメモリ（random-access memory, ＲＡＭ）106；ハードディスク108のようなメモリデバイス、フロッピー（登録商標）ディスクから読み取るか、またはそこへ書込むためのフロッピー（登録商標）ディスクドライブ110のようなメモリ媒体から読み取るか、またはそこへ書込むためのデバイス、並びに他のデバイスかまたは通信ネットワークへ接続するための入力および出力ポート112をもっている。
【００３３】
図１Ａを再び参照すると、フロッピー（登録商標）ディスク114が示されており、フロッピー（登録商標）ディスクドライブ110はこのフロッピー（登録商標）ディスク114から読み取るか、またはそこへ書込むことができる。コンピュータ100は通信ネットワーク116へ接続されており、通信ネットワーク116は、この実施形態では、例えば伝送制御プロトコル／インターネットプロトコル（Transmission Control Protocol/Internet Protocol, ＴＣＰ／ＩＰ）を使用する周知のインターネットとして理解される。第２の従来の汎用コンピュータ118は、ウエブクライアントとして使用するのに適しており、同様にインターネット通信ネットワーク116へ接続されている。
【００３４】
コンピュータ100は適切なオペレーティングシステムを使用することができ、例えばMicrosoft Windows（登録商標）ＮＴ、Linux（登録商標）、またはUnix（登録商標）の他の多くのバージョンの何れか１つがよく知られている。アプリケーションプログラムは、アプリケーションプログラムを書くための多くの周知の適切な言語の何れかで書くことができ、周知の例の１つはＣ＋＋である。このようなオペレーティングシステムおよびアプリケーションプログラムは、コンピュータ100のメモリデバイス108へロードすることができる。
【００３５】
本発明のこの実施形態にしたがって開示される機能は、コンピュータ100によって実行されるソフトウエアモジュールのアプリケーションプログラムとして実行することができる。このソフトウエアアプリケーションプログラムは、適切なコンピュータの読取り可能なメモリ媒体の形態をとる、例えばフロッピー（登録商標）ディスク114上に記憶され、実行のためには、フロッピー（登録商標）ディスクドライブ110を介して、コンピュータ100へロードする。周知の代わりのアプリケーションプログラムは、ＣＤ−ＲＯＭ（図示されていない）上にソフトウエアアプリケーションを記憶し、実行のためには、ＣＤ−ＲＯＭドライブ（図示されていない）を介してコンピュータ100へロードする。別の周知の代わりのアプリケーションプログラムでは、コンピュータ100によって実行するために、ネットワーク116上にソフトウエアアプリケーションプログラムをダウンロードする。
【００３６】
この実施形態では、コンピュータ100は、ソフトウエアアプリケーションプログラムをロードされていて、このプログラムが実行されると、コンピュータ100はウエブサーバとして動作する。ウエブ文書は、従来のように、ウエブサーバの適切なメモリデバイス上に記憶される。
【００３７】
ウエブブラウザプログラムを含む、第２のコンピュータ108上にロードされるソフトウエアアプリケーションプログラムは、実行されると、ワールドワイドウエブプロトコルを使用して通信をイネーブルし、特にウエブページ、ウエブサーバコンピュータ100上でホストされたウエブページを、例えばウエブブラウザを使用して、閲覧（view）できるようにする。
【００３８】
ここで従来のディジタル署名プロセスを図２および３に関連して記載することにする。図２および３の構造は忠実に反映されていることが分かるであろう；図２はディジタルかまたは電子の文書のディジタル署名プロセスの手続きのフローチャートを示しており、一方で図３は簡単なやり方で対応するエンティティの振舞いを示している。手続きのフローチャートに示されている段階は、ウエブサーバ100上を走るソフトウエアアプリケーションを実行することによって行われることも分かるであろう。
【００３９】
この実施形態の例として、検討されているウエブ文書はウエブページであり、一般的に、ウエブサーバ100の適切なメモリデバイス、この例ではハードディスク上に記憶されたHyperText Markup Language（ＨＴＭＬ）の文書である。しかしながらこの例は無限であり；すなわち本発明にしたがって多くの他の形態のコンピュータファイル（例えば、ＨＴＭＬ以外のフォーマットの文書、例えばJoint Photographic Experts Group（ＪＰＥＧ）フォーマットの画像、およびダウンロードできるソフトウエアプログラム）も同様に処理するできることに注意すべきである。
【００４０】
第1の段階200では、ディジタル署名をするための文書が選択される。このような文書300は図３に示した。
【００４１】
第２の段階202では、署名される文書は、いわゆる‘ハッシュ’機能を通される。ハッシュ機能はこの文書の短い表示を生成し、これはしばしば文書の‘ハッシュ’と呼ばれる。署名される文書300はおよび署名される文書のハッシュ302は図３に模式的に示されている。ハッシュ機能および文書のハッシュは、代わりに、それぞれ‘メッセージダイジェスト’機能および‘メッセージダイジェスト’と呼ばれることがよくある。２つの周知のハッシュ機能の例はＭＤ５およびＳＨＡハッシュ機能である。
【００４２】
ハッシュ機能によって生成された文書のハッシュはその文書の内容に対する感度が著しく高いことがよく知られている。例えば、テキスト文書が終止符の挿入のみによって変更されるとき、終止符を挿入する前に生成されたハッシュおよび終止符の挿入後に挿入されたハッシュは、概して完全に異なる。
【００４３】
第３の段階204において、ディジタル署名は秘密鍵を使用して文書のハッシュを暗号化することによって作成される。この秘密鍵は、例えば内容の作成者、内容の所有者、または内容の管理者を含む多数の当事者の何れかの秘密鍵であることが分かるであろう。認可された署名する当事者が関係する認可された秘密鍵をもつ概念については後で記載することにする。署名される文書のハッシュ302およびディジタル署名304を図３に示した。
【００４４】
署名される文書のためのディジタル署名は、作成されると、ウエブサーバ100の適切なメモリデバイス、この例ではハードディスク上に記憶される。
【００４５】
その代わりにオプションの第４の段階206において、このように作成されたディジタル署名は、署名される文書に添付されて、ディジタル形式で署名された文書を作成する。ディジタル形式で署名された文書306は図３に示されている。次にディジタル形式で署名された文書は、ウエブサーバ100の適切なメモリデバイス、この例ではハードディスク上に記憶することができる。
【００４６】
本発明の文書供給プロセスを図１、４、５、および６に関連して記載する。ここでも手続きのフローチャート内に示された段階は、ウエブサーバ100上を走るソフトウエアアプリケーションを実行することによって行なわれることが分かるであろう。
【００４７】
図１および４に関して、第１の段階400において、ウエブサーバ100は第２のコンピュータ114から、ウエブサーバ100上に記憶された所与のウエブページへアクセスするための要求を受取る。よく知られているように、この要求は一般的に、第２のコンピュータ114のユーザがハイパーリンク上をクリックすることによって開始され、このユニフォームリソースロケータ（ＵＲＬ）が所与のウエブページを指示する。さらによく知られているように、ウエブサーバ100は、クライアントから到来する接続を受取るためのＴＣＰポート80を監視するプロセスをもつ。ＴＣＰ接続が設定されると、ウエブページに対するＨＴＴＰ要求が上述のように行われる。
【００４８】
第２の段階402において、ＵＲＬ要求に対応するウエブページは、ウエブサーバ100の適切なメモリデバイス、この例ではハードディスクから検索される。
【００４９】
第３の段階404では、このウエブページに対応するディジタル署名も、ウエブサーバの適切なメモリデバイス、この例ではハードディスクから検索される。ディジタル署名が、上述のオプションの段階206にしたがって文書に既に添付されているときは、この段階は文書自体を検索するときに行なわれることが分かるであろう。
【００５０】
第４の段階406では、文書に関係するディジタル署名の有効性が検査される。
【００５１】
ディジタル署名の妥当性検査プロセスの手続きのフローチャートは図５および６に記載した。ここで段階406に用意されたこのディジタル署名の妥当性検査プロセスを、図４に示した段階の記載に戻る前に、図５および６に関連して記載することにする。図５および６の構造は忠実に反映されていることが認識され：図５はディジタル署名の妥当性検査プロセスの手続きのフローチャートを示しており、一方で図６は対応するエンティティの振舞いを簡単に示している。
【００５２】
図５に関連して、第１の段階500において、文書に関係するディジタル署名は公開鍵でデクリプトされ、この場合に秘密鍵に対応する公開鍵を使用して、最初に文書のハッシュまたはメッセージダイジェストに署名する。周知のように、このデクリプションによって文書のハッシュが得られる。要求された文書に関係するディジタル署名600およびデクリプションによって得られたハッシュ602は図６に示した。
【００５３】
第２の段階502において、文書は再び、文書をディジタル形式で署名するプロセスで最初に使用されたのと同じハッシュ機能を実行される。こうして文書の新しいハッシュが導き出される。文書604および文書の新しいハッシュ606は図６示されている。
【００５４】
要求された文書に関係するディジタル署名をデクリプトするのに使用される公開鍵が、文書のハッシュに署名するのに使用される秘密鍵に整合する公開鍵でないとき、ディジタル署名は正しくデクリプトされない。その結果、デクリプションによって得られた文書のハッシュは正しいものでなくなり、文書の新しいハッシュと異なることになる。同様に、文書がハッシュの生成を含む文書への署名と新しいハッシュの生成との間で変更されるとき、ハッシュと新しいハッシュとは異なることがさらに分かるであろう。
【００５５】
その結果、段階504において、文書のハッシュと文書の新しいハッシュとが比較される。文書のハッシュ602と文書の新しいハッシュ606との比較は、図６に模式的に示されている。
【００５６】
ハッシュと新しいハッシュとが同じであるとき、文書に署名したと考えられる当事者が、現実に文書に署名した（すなわち、デクリプションに使用された公開鍵が、文書に署名するのに使用された秘密鍵に正しく整合している）ことが保証されるだけでなく、ディジタル署名を生成してから文書が変更されていない（すなわち、文書のハッシュと文書の新しいハッシュとは同一である）ことも保証される。文書のハッシュと文書の新しいハッシュとを比較して、段階406に示された認証の照会に対する結果を戻す。要求された文書に関係するディジタル署名は、妥当性検査試験に通るときと、通らないときがある。
【００５７】
ここで図４を再び参照して文書供給プロセスについて検討する。
【００５８】
ディジタル署名が有効であると、第５の段階408において、ウエブサーバは従来のやり方でウエブページを要求している当事者へ送ることを始める。
【００５９】
より一般的な場合に、コンピュータファイルに関係するディジタル署名が有効であると、サーバコンピュータは、全てのファイルを一度にクライアントコンピュータへ送るのではなく、コンピュータファイルへのアクセスを許可することに注意すべきである。例示的に、サーバコンピュータはその代わりにクライアントコンピュータと通信セッションを開き、ファイルの一部を要求に応じてクライアントコンピュータへ流す。
【００６０】
しかしながらディジタル署名が有効でないとき、すなわち文書が、その文書に関係するディジタル署名が作成されてから変更されたか、または文書が現実に文書に署名したと表示された人以外の人によって署名されたときは、ウエブサーバが文書を送り始めることは絶対にない。その代わりに、第６の段階410において、ウエブサーバはウエブページを要求している当事者へ送り、要求しているウエブページが有効でないことを知らせる。
【００６１】
第７の段階412では、ウエブサーバは、例えば、無効のディジタル署名に関する警告を含むメッセージをシステムの管理者へ送る。
【００６２】
現在、公開鍵の処理は比較的に緩慢であり、ハッシュ機能または対称鍵の処理よりも１００ないし１０００倍程度緩慢であることに注意すべきである。ウエブサーバが、供給された各文書に対してディジタル署名を検査するとき、これが直ぐに動作の隘路になることが分かるであろう。この問題を改善するために、ディジタル署名の検査のために最適化された専用のハードウエアボードを使用することができる。このようなボードの１つの例としては、nCipher(Cambridge, United Kingdom)によって生成されたものがある。このような各ボードは一般的に、１秒間に数百のディジタル署名を検査することができ、要求に応じて別のボードをデイジーチェーン接続することもできる。
【００６３】
既に記載したように、‘それらの’文書の１つをディジタル形式で署名したい当事者が数多くいる可能性は相当に高い。このような各当事者は、自身の秘密鍵をもち、これを使用して、関連する暗号化を行う。したがってディジタル形式で署名された各ファイルを関連する署名する当事者に関係付けることができる手段を用意することが必要であり、その結果適切に整合した公開鍵はディジタル署名の認証に使用できる。
【００６４】
各ディジタル形式で署名されたファイルと署名する当事者とを関係付けることができる手段は、１つの例では署名する当事者のディジタルの証明のコピーをディジタル形式で署名されたファイルに添付するだけである。図２に関して、これは、例えば、段階206に続く段階で行われる。ディジタル証明の周知の概念は、ディジタル署名の概念に密接に関連しており、ここでは詳しく記載しない。ディジタル証明は当事者の識別子をその当事者の公開鍵と結合し、このディジタル証明自体は、普通は第三者機関（Trusted Third Party, ＴＴＰ）を示す第３の当事者によって署名されることのみに注意するべきである。
【００６５】
このやり方で、図４に関連して、段階402および404においてディジタル形式で署名されたファイルが検索されるとき、添付されたディジタル証明も検索される。ディジタル証明は、署名する当事者の識別子および署名する当事者の関係する公開鍵とを与える。図５に関連して、段階500において公開鍵を使用して、認証プロセスにおいて要求されるようにディジタル形式で署名された文書のハッシュを得ることができる。
【００６６】
ファイルに添付されたディジタル証明が署名する当事者のディジタル証明でないとき、認証は失敗する。しかしながら承認されていない第３の当事者がディジタル形式で署名されたファイルを整合したディジタル証明をもつウエブサーバへなんとか密かにもちだすことについて検討する。そこで発生する従属的な問題は、その当事者の制御がその特定のウエブサイト上に記憶する文書に署名することを認証されている。
【００６７】
認証された署名する当事者のリストはウエブサーバ上で構成され、記憶されるようにでき；認証された署名する当事者のディジタル証明のみを有効に使用することができる。承認されていない第３の当事者に対する次の攻撃地点は、誤った‘承認された’署名する当事者をリストに加えることを試行するので、このリストは、システムの管理者の秘密鍵によってそれに署名することによって、それ自体を保護することができる。このやり方では、システム管理者の公開鍵を使用してリストを読み取ることができ、したがって、上述の記憶された文書のように、リストが不正使用されておらず、現実にシステムの管理者から発信していることを保証する。
【００６８】
関心をもっている別の問題は、‘寿命’が制限されている文書が所定の時刻または日付を過ぎると供給されないことを保証することである。図２に関して、これは段階206に続く段階で、ディジタル形式で署名されたファイルに‘期限切れ時刻または日付のスタンプ’を付加することによって達成される。この期限切れ時刻のスタンプが損われるのを防ぐために、期限切れ時刻のスタンプを添付されたディジタル形式で署名された文書自体は、さらに別の段階において、例えばシステム管理者の秘密鍵で署名される。
【００６９】
図４に関連して、この場合に、ディジタル形式で署名された文書が検索されるとき、段階402および404において、ディジタル形式で署名される文書は添付された期限切れ時刻−スタンプをもち、システムの管理者によって署名される。別の段階では、期限切れの時刻−スタンプは最初に、システムの管理者の公開鍵でディジタル形式で署名された文書をデクリプトすることによって検索される。さらに別の段階では、関連する時刻または日付が過ぎたか否かを調べるために検査が行われる。関連する時刻または日付が過ぎているときは、文書は供給されない。
【００７０】
ここで本発明のこの実施形態の簡単な応用を記載する。図１に示したウエブサーバは協働するウエブサイトのホストとして働くために採用されている。ウエブサーバは一般的に、既に記載したように協働するファイアウオールによって保護される。インターネットに接続されていて、ウエブブラウザを適切に装備した一般のコンピュータを使用して、この協働するウエブサイト上でウエブページを閲覧することができる。周知のように、これらのウエブページは一般に、会社に関する情報を全世界へ送るために使用される。
【００７１】
第１の情況として、会社がウエブページの形態の文書をその協働するウエブサイト上にポストすることについて検討する。文書は、上述の図２および３についての記述にしたがって会社の秘密鍵を使用してディジタル形式で署名されている。一般のメンバは、典型的に文書に関係するハイパーリンク上をクリックすることによって、この文書へのアクセスを要求する。上述の図４、５、および６についての記載にしたがって、ウエブサーバは文書のディジタル署名の認証を実行する。この第１の情況において、認証は成功し、一般のメンバに供給されたウエブページはその後は事もなく要求を行う。
【００７２】
ここで第２の情況として、会社がウエブページの形態の文書をその協働するウエブサイト上にポストすることについて検討する。文書は、図２および３に関する既に記載された部分にしたがって、例えば会社の秘密鍵を使用してディジタル形式で署名される。しかしながらこの情況では、協働するウエブサイトの管理者に気付かれずに、協働するファイアウオールは損われ、承認されていない第３の当事者がウエブサーバへのアクセスを得る。このアクセスを使用して、承認されていない第３の当事者は、ウエブサーバ上に記憶されたウエブページを変更することを始める。この承認されていない第３の当事者によって実行される変更は、このような攻撃を展開する動機に依存しているが；都合の悪いことに、悪ふざけ（prank）から明らかな妨害行為（sabotage）までの広範囲の動機を考えてしまい易い。
【００７３】
ここで一般公衆のメンバは、承認されていない第３の当事者によって変更された文書へのアクセスを要求していると考えられる。図４、５、および６についての既に記載された部分にしたがって、ウエブサーバは文書のディジタル署名の認証を実行する。この第２の情況では、文書のハッシュと文書の新しいハッシュとが整合しないために認証は失敗する。
【００７４】
したがってウエブページは、要求を行う一般のメンバへは供給されない。したがって、要求を行う一般のメンバは変更された文書を全く参照できないことは極めて重要である。
【００７５】
既に記載したように、承認されていない第３の当事者の侵入者の動機に適するように変更されたウエブページを要求を行っている一般のメンバへ供給することが許可されているとき、この文書は‘信用できない’という警告があっても、会社の商取引または評判にダメージを与えてしまう。
【００７６】
ここで第３の情況について検討する。この第３の情況では再び、協働するウエブサイトの管理者に知られずに、協働するファイアウオールは損われ、承認されていない第３の当事者がウエブサーバへのアクセスを得る。このアクセスを使用して、承認されていない第３の当事者はウエブページの形態をとる偽造された文書を会社の協働するウエブサイト上にポストする。文書は、図２および３について既に記載された部分にしたがって第３の当事者によってディジタル形式で署名されるが、署名プロセスで使用される秘密鍵は、会社ではなく、承認されていない第３の当事者によって選択されたものである。
【００７７】
ここで承認されていない第３の当事者によって変更された文書へのアクセスを要求することについて検討する。図４、５、および６について既に記載された部分にしたがって、ウエブサーバは文書のディジタル署名の認証を行う。この第３の情況では、認証は再び失敗する。ディジタル署名が承認されていない第３の当事者の秘密鍵で署名されたときに、会社の公開鍵でディジタル署名をデクリプトすることを試行することにより、文書のハッシュと文書の新しいハッシュとの不正合が再び発生する。
【００７８】
したがってさらにここでもウエブページは要求を行っている一般のメンバへ供給されず、したがってここでも要求をしている一般のメンバが変更された文書を全く参照できないことは非常に重要である。
【特許請求の範囲】
【請求項１】
サーバコンピュータであって：
コンピュータファイルを記憶するようにされた手段と；
ディジタル署名を記憶するようにされた手段と；
各コンピュータファイルは関係するディジタル署名をもっていて、
少なくとも1つの他のコンピュータから前記サーバコンピュータ上に記憶された少なくとも１つのコンピュータファイルにアクセスする要求を受取るようにされている手段と；
該または各要求されたコンピュータファイルを検索するようにされた手段と；
該または各要求されたコンピュータファイルを検索するようにされた手段と；
該または各要求されたコンピュータファイルに関係するディジタル署名の有効性を検査するようにされた手段と；
該または各それぞれ要求されたコンピュータファイルに関係するディジタル署名が有効であるときのみ、該または各要求されたコンピュータファイルへのアクセスを前記他のコンピュータへ与えるようにされている手段とを含むサーバコンピュータ。
【請求項２】
該または各それぞれの要求されたコンピュータファイルに関係するディジタル署名が有効であるときのみ、該または各要求されたコンピュータファイルへのアクセスを前記他のコンピュータへ与えるようにされている前記手段が、該または各それぞれの要求されたコンピュータファイルが有効であるときのみ、該または各コンピュータファイルのコピーを前記他のコンピュータへ供給するようにされている手段を含む請求項１記載のサーバコンピュータ。
【請求項３】
認可されたコンピュータファイルに署名する当事者のリストを記憶するようにされている手段をさらに含み；
各コンピュータファイルに署名をする当事者がディジタル署名を作成するための少なくとも1つの関係する署名用の鍵をもっていて；
該または各要求されたコンピュータファイルに関係するディジタル署名の有効性を検査するようにされている前記手段が、前記ディジタル署名が認可されたコンピュータファイルの署名する当事者に関係する署名用の鍵を使って作成されたときのみ、前記ディジタル署名を有効とする請求項１または２記載のサーバコンピュータ。
【請求項４】
クロックをさらに含み、前記サーバコンピュータ上に記憶された該または各コンピュータファイルが関係する期限切れ日付をもっていて；
該または各要求されたコンピュータファイルに関係するディジタル署名の有効性を検査するようにされている前記手段が、該または各コンピュータファイルに関係する期限切れの日付が現在のクロックの日付を過ぎたときのみ、前記ディジタル署名を有効とする請求項１ないし３の何れか１項記載のサーバコンピュータ。
【請求項５】
コンピュータファイルおよびディジタル署名を記憶するようにされているサーバコンピュータであって、各コンピュータファイルは関係するディジタル署名をもっていて：
別のコンピュータからの接続を受入れ；
前記別のコンピュータから、前記サーバコンピュータ上に記憶された少なくとも１つのコンピュータファイルへアクセスする要求を受取り；
該または各要求されたコンピュータファイルを検索し；
該または各要求されたコンピュータファイルに関係するディジタル署名を検索し；
該または各要求されたコンピュータファイルに関係するディジタル署名の有効性を検査し；
該または各要求されたコンピュータファイルに関係するディジタル署名が有効であるときのみ、該または各要求されたコンピュータファイルへのアクセスを前記他のコンピュータに与える動作を実行するようにされているサーバコンピュータ。
【請求項６】
サーバコンピュータを動作する方法であって：
少なくとも１つの他のコンピュータから、前記サーバコンピュータ上に記憶された少なくとも1つのコンピュータファイルへアクセスするための要求を受取り；各前記コンピュータファイルが前記サーバコンピュータ上に記憶された関係する固有のディジタル署名をもっている段階と；
該または各要求されたコンピュータファイルを検索する段階と；
該または各要求されたコンピュータファイルに関係するディジタル署名を検索する段階と；
該または各要求されたコンピュータファイルに関係する固有のディジタル署名の有効性を検査する段階と；
該または各要求されたコンピュータファイルに関係するディジタル署名が有効であるときのみ、該または各要求されたコンピュータファイルへのアクセスを前記コンピュータへ与える段階とを含む方法。
【請求項７】
該または各要求されたコンピュータファイルに関係するディジタル署名が有効であるときのみ、該または各要求されたコンピュータファイルへのアクセスを前記コンピュータへ与える前記段階が、該または各要求されたコンピュータファイルに関係するディジタル署名が有効であるときのみ、該または各コンピュータファイルのコピーを前記他のコンピュータへ与えることを含む請求項６記載の方法。
【請求項８】
コンピュータへロードするためのコンピュータの読取り可能なコードを取入れ、前記コンピュータが請求項６または７記載の方法を実行するのを実行可能にするコンピュータプログラムメモリ媒体。
【請求項１】
サーバコンピュータであって：
コンピュータファイルを記憶するようにされた手段と；
ディジタル署名を記憶するようにされた手段と；
各コンピュータファイルは関係するディジタル署名をもっていて、
少なくとも1つの他のコンピュータから前記サーバコンピュータ上に記憶された少なくとも１つのコンピュータファイルにアクセスする要求を受取るようにされている手段と；
該または各要求されたコンピュータファイルを検索するようにされた手段と；
該または各要求されたコンピュータファイルを検索するようにされた手段と；
該または各要求されたコンピュータファイルに関係するディジタル署名の有効性を検査するようにされた手段と；
該または各それぞれ要求されたコンピュータファイルに関係するディジタル署名が有効であるときのみ、該または各要求されたコンピュータファイルへのアクセスを前記他のコンピュータへ与えるようにされている手段とを含むサーバコンピュータ。
【請求項２】
該または各それぞれの要求されたコンピュータファイルに関係するディジタル署名が有効であるときのみ、該または各要求されたコンピュータファイルへのアクセスを前記他のコンピュータへ与えるようにされている前記手段が、該または各それぞれの要求されたコンピュータファイルが有効であるときのみ、該または各コンピュータファイルのコピーを前記他のコンピュータへ供給するようにされている手段を含む請求項１記載のサーバコンピュータ。
【請求項３】
認可されたコンピュータファイルに署名する当事者のリストを記憶するようにされている手段をさらに含み；
各コンピュータファイルに署名をする当事者がディジタル署名を作成するための少なくとも1つの関係する署名用の鍵をもっていて；
該または各要求されたコンピュータファイルに関係するディジタル署名の有効性を検査するようにされている前記手段が、前記ディジタル署名が認可されたコンピュータファイルの署名する当事者に関係する署名用の鍵を使って作成されたときのみ、前記ディジタル署名を有効とする請求項１または２記載のサーバコンピュータ。
【請求項４】
クロックをさらに含み、前記サーバコンピュータ上に記憶された該または各コンピュータファイルが関係する期限切れ日付をもっていて；
該または各要求されたコンピュータファイルに関係するディジタル署名の有効性を検査するようにされている前記手段が、該または各コンピュータファイルに関係する期限切れの日付が現在のクロックの日付を過ぎたときのみ、前記ディジタル署名を有効とする請求項１ないし３の何れか１項記載のサーバコンピュータ。
【請求項５】
コンピュータファイルおよびディジタル署名を記憶するようにされているサーバコンピュータであって、各コンピュータファイルは関係するディジタル署名をもっていて：
別のコンピュータからの接続を受入れ；
前記別のコンピュータから、前記サーバコンピュータ上に記憶された少なくとも１つのコンピュータファイルへアクセスする要求を受取り；
該または各要求されたコンピュータファイルを検索し；
該または各要求されたコンピュータファイルに関係するディジタル署名を検索し；
該または各要求されたコンピュータファイルに関係するディジタル署名の有効性を検査し；
該または各要求されたコンピュータファイルに関係するディジタル署名が有効であるときのみ、該または各要求されたコンピュータファイルへのアクセスを前記他のコンピュータに与える動作を実行するようにされているサーバコンピュータ。
【請求項６】
サーバコンピュータを動作する方法であって：
少なくとも１つの他のコンピュータから、前記サーバコンピュータ上に記憶された少なくとも1つのコンピュータファイルへアクセスするための要求を受取り；各前記コンピュータファイルが前記サーバコンピュータ上に記憶された関係する固有のディジタル署名をもっている段階と；
該または各要求されたコンピュータファイルを検索する段階と；
該または各要求されたコンピュータファイルに関係するディジタル署名を検索する段階と；
該または各要求されたコンピュータファイルに関係する固有のディジタル署名の有効性を検査する段階と；
該または各要求されたコンピュータファイルに関係するディジタル署名が有効であるときのみ、該または各要求されたコンピュータファイルへのアクセスを前記コンピュータへ与える段階とを含む方法。
【請求項７】
該または各要求されたコンピュータファイルに関係するディジタル署名が有効であるときのみ、該または各要求されたコンピュータファイルへのアクセスを前記コンピュータへ与える前記段階が、該または各要求されたコンピュータファイルに関係するディジタル署名が有効であるときのみ、該または各コンピュータファイルのコピーを前記他のコンピュータへ与えることを含む請求項６記載の方法。
【請求項８】
コンピュータへロードするためのコンピュータの読取り可能なコードを取入れ、前記コンピュータが請求項６または７記載の方法を実行するのを実行可能にするコンピュータプログラムメモリ媒体。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図２】
【図３】
【図４】
【図５】
【図６】
【公開番号】特開２０１２−４８７２９（Ｐ２０１２−４８７２９Ａ）
【公開日】平成２４年３月８日（２０１２．３．８）
【国際特許分類】
【外国語出願】
【出願番号】特願２０１１−２０４８４５（Ｐ２０１１−２０４８４５）
【出願日】平成２３年９月２０日（２０１１．９．２０）
【分割の表示】特願２０００−６０８５６３（Ｐ２０００−６０８５６３）の分割
【原出願日】平成１２年３月２２日（２０００．３．２２）
【出願人】（３９００２８５８７）ブリティッシュ・テレコミュニケーションズ・パブリック・リミテッド・カンパニー (104)
【氏名又は名称原語表記】ＢＲＩＴＩＳＨ ＴＥＬＥＣＯＭＭＵＮＩＣＡＴＩＯＮＳ ＰＵＢＬＩＣ ＬＩＭＩＴＥＤ ＣＯＭＰＡＮＹ
【Ｆターム（参考）】
【公開日】平成２４年３月８日（２０１２．３．８）
【国際特許分類】
【出願番号】特願２０１１−２０４８４５（Ｐ２０１１−２０４８４５）
【出願日】平成２３年９月２０日（２０１１．９．２０）
【分割の表示】特願２０００−６０８５６３（Ｐ２０００−６０８５６３）の分割
【原出願日】平成１２年３月２２日（２０００．３．２２）
【出願人】（３９００２８５８７）ブリティッシュ・テレコミュニケーションズ・パブリック・リミテッド・カンパニー (104)
【氏名又は名称原語表記】ＢＲＩＴＩＳＨ ＴＥＬＥＣＯＭＭＵＮＩＣＡＴＩＯＮＳ ＰＵＢＬＩＣ ＬＩＭＩＴＥＤ ＣＯＭＰＡＮＹ
【Ｆターム（参考）】
[ Back to top ]