(57)【要約】公開鍵システムのサーバがデジタルデータのフィンガープリントリストを記憶する。他のフィンガープリントはこのフィンガープリントリストで算出され、クライアント端末を備える。公開鍵システムのクライアント端末はこのシステムの第１のソースからデジタルデータのフィンガープリントリストを取得する。さらにクライアント端末は取得された２つのフィンガプリントを比較するため、第１のソースとともに第２のソースからもフィンガープリントリストのフィンガープリントを取得する。
2005539441.tif 000002
【特許請求の範囲】
【請求項１】
公開鍵システムのサーバによって実行される方法であって、前記公開鍵システムがさらに複数のクライアント端末を備え、
デジタル式に符号化されたデータの第１のフィンガープリントリストを記憶するステップと、
前記フィンガープリントリストの少なくとも一部について第１のフィンガープリントを算出するステップと、
前記算出された第１のフィンガープリントを供給するステップとを含む、方法。
【請求項２】
前記第１のフィンガープリントを算出するステップが、
前記第１のフィンガープリントリストの１つ又は複数のエントリを取得し、これにより、前記１つ又は複数のエントリが前記第１のフィンガープリントによってカバーされる、ステップと、
少なくとも前記取得された１つ又は複数のエントリに関してハッシュ値を算出するステップとを含む、請求項１に記載の方法。
【請求項３】
前記第１のフィンガープリントリストが、
各フィンガープリントに関連付けられる固有の識別子、
各フィンガープリントに関連付けられる時間仕様であって、前記フィンガープリント又は前記デジタルデータに関連付けられる前記第１のリストへのエントリの時間、前記フィンガープリント又は前記デジタルデータの発生時間、若しくは前記フィンガープリント又は前記デジタルデータの前記サーバへの供給時間の少なくとも１つを特定する、時間仕様、または
各フィンガープリントのデジタルデータへのリンク又はデジタルデータとの関連性のうち少なくとも１つをさらに備える、請求項１又は２に記載の方法。
【請求項４】
前記算出された第１のフィンガープリントを取得するステップにおける前記１つ又は複数のエントリが、フィンガープリントに関連付けられる固有の識別子又は時間仕様の少なくとも１つをさらに含む、請求項２及び３に記載の方法。
【請求項５】
前記固有の識別子、前記時間仕様、前記リンク又は前記関連性が、前記サーバにより前記記憶するステップの一部として確立され、割り当てられる、請求項３又は４に記載の方法。
【請求項６】
前記算出された第１のフィンガープリントを供給するステップが、前記第１のフィンガープリントを前記複数のユーザ端末の少なくとも１つへ送信されるメッセージに添付することを含む、請求項１〜５のいずれか１項に記載の方法。
【請求項７】
前記算出された第１のフィンガープリントを供給するステップ又は前記第１のフィンガープリントを算出するステップが、前記サーバによって前記第１のフィンガープリントに署名することをさらに含む、請求項１〜６のいずれか１項に記載の方法。
【請求項８】
前記第１のフィンガープリントリストを記憶するステップが、
デジタルデータを受信するステップと、
前記デジタルデータの完全性、前記デジタルデータの送信者の識別及び前記送信者の真正のうちの少なくとも１つを確立するステップであって、前記デジタルデータのデジタル署名を検証すること、前記デジタルデータ又は送信者に関連付けられるフィンガープリントを検証すること、前記送信者との通信のために安全且つ信用のある接続を使用すること、前記受信されたデジタルデータに対して暗号化スキームを適用することのうち少なくとも１つを含む、ステップと、
少なくとも前記デジタルデータに関してハッシュ値を算出するステップと、
前記ハッシュ値を前記第１のフィンガープリントリストへ追加するステップとを含む、請求項１〜７のいずれか１項に記載の方法。
【請求項９】
少なくとも前記第１のフィンガープリントを算出するステップ及び前記算出された第１のフィンガープリントを供給するステップが、計時されたスケジュールに従って繰り返し実行され、前記第１のフィンガープリントリストが、さらなるエントリによって増補、又は継続可能である、請求項１〜８のいずれか１項に記載の方法。
【請求項１０】
前記算出された第１のフィンガープリントを供給するステップが、前記第１のフィンガープリントを毎時、毎日、毎週、毎月又は他の定期ベースで供給又は更新することを含む、請求項９に記載の方法。
【請求項１１】
前記算出された第１のフィンガープリントを供給するステップが、時間仕様、有効性期間情報又は前記供給された第１のフィンガープリントの有効性を確立することを規定する他の識別子のうち少なくとも１つを関連付けて供給することをさらに含む、請求項１〜１０のいずれか１項に記載の方法。
【請求項１２】
公開鍵システムのクライアント端末によって実行される方法であって、前記公開鍵システムが複数のクライアント端末と少なくとも１つのサーバとを備え、
第１のソースからデジタル式に符号化されたデータの第１のフィンガープリントリストを取得するステップと、
第１のソースから前記フィンガープリントリストの第１のフィンガープリントを取得するステップと、
第２のソースから前記フィンガープリントリストの第２のフィンガープリントを取得するステップと、
前記第１及び第２のフィンガープリントを比較するステップとを含む、方法。
【請求項１３】
前記取得された第１のフィンガープリントリストのフィンガープリントを算出するステップと、
前記算出されたフィンガープリントと前記取得された第１及び第２のフィンガープリントとを比較するステップと、
前記比較するステップの結果、少なくとも一方でフィンガープリントが異なれば、前記受信されたフィンガープリント又は前記第１のフィンガープリントリストのデータの完全性が危うくされていることを確立するステップとをさらに含む、請求項１２に記載の方法。
【請求項１４】
前記フィンガープリントリストの前記デジタル式に符号化されたデータの少なくとも１つを取得するステップと、
前記取得されたデジタルデータのフィンガープリントを算出するステップと、
前記算出されたフィンガープリントを前記受信されたフィンガープリントリストにおける前記取得されたデジタルデータのフィンガープリントと比較するステップと、
前記比較するステップの結果、フィンガープリントが異なれば、前記受信されたデジタルデータ又は前記フィンガープリントリストのデータの完全性が危うくされていることを確立するステップとをさらに含む、請求項１２又は１３に記載の方法。
【請求項１５】
前記受信された第１及び第２のフィンガープリントに関してデジタル署名を検証すること、
受信されたフィンガープリントリストに関してデジタル署名を検証すること、
前記受信された第１及び第２のフィンガープリント又は前記第１及び第２のソースに関連付けられるフィンガープリントを検証すること、及び
ユーザ入力を受信して、前記デジタル署名を検証するステップ及びフィンガープリントを検証するステップの少なくとも一方を実行することのうち少なくとも１つをさらに含む、請求項１２〜１４のいずれか１項に記載の方法。
【請求項１６】
前記第１及び第２のフィンガープリントを取得するステップが、
前記第１及び第２のフィンガープリントを、前記クライアント端末と前記サーバとを接続する公衆ネットワークの通信媒体を介して前記クライアント端末へ送信されるメッセージと共に受信するステップを含み、
前記方法が、
前記フィンガープリントリストのフィンガープリントを、前記クライアント端末を接続する公衆ネットワークの通信媒体を介して他のクライアント端末へ送信されるメッセージに添付するステップを含む、請求項１２〜１５のいずれか１項に記載の方法。
【請求項１７】
前記第１及び第２のフィンガープリントを取得するステップ及びフィンガープリントを添付するステップが、前記メッセージの受信側であるクライアント端末による明確な要求なしに自動的に、但し前記第１又は第２のフィンガープリントの交換を目的として確立されるものではないクライアント端末間の定期通信の一部として達成される、請求項１６に記載の方法。
【請求項１８】
前記フィンガープリントを添付するステップが、時間仕様、有効性期間情報又は前記供給されたフィンガープリントの有効性を確立することを規定する他の識別子のうち少なくとも１つを関連付けて添付することをさらに含む、請求項１２〜１９のいずれか１項及び請求項１６に記載の方法。
【請求項１９】
前記フィンガープリントをメッセージに添付するステップが、前記クライアント端末によって有効であり且つ真正であることが検証されているフィンガープリントに関してのみ実行され、前記検証が、互いに異なる及び／又は独立したソースの受信された対応するフィンガープリントを使用して前記添付されたフィンガープリントに関して実行された成功裡の比較ステップ数に依存し、前記フィンガープリントを添付するステップが、前記クライアント端末により前記クライアント端末の秘密鍵を使用して前記フィンガープリントに署名することをさらに含む、請求項１６〜１８のいずれか１項に記載の方法。
【請求項２０】
前記第１及び第２のフィンガープリントを取得するステップが、
受信されたフィンガープリント及び／又は受信されたフィンガープリントリストが有効であり且つ前記受信されたフィンガープリント及び／又は受信されたフィンガープリントリストに関連付けられた、又は添付された情報によって、又は前記クライアント端末に周知の所定の計時されたスケジュールによって最新公開バージョンを提示しているかどうかを決定するステップと、
前記受信されたフィンガープリント及び／又は受信されたフィンガープリントリストが有効でなければ、前記受信されたフィンガープリント及び／又は受信されたフィンガープリントリストを無視する、若しくは他のソースからフィンガープリント及び／又はフィンガープリントリストを要求して無効なバージョンと交換するステップとを含む、請求項１２〜１９のいずれか１項に記載の方法。
【請求項２１】
前記クライアント端末が、異なるソースから受信された第１及び第２のフィンガープリントの記録をさらに取り且つ更新し、前記記録が、各フィンガープリントのソースの識別子を含むことが可能であり、前記更新が、フィンガープリントを、前記フィンガープリントが無効である、若しくは前記フィンガープリント又は前記フィンガープリントの個々のソースが信用できないものである、若しくは成功裡に認証され得ないことが確定した後に前記記録から除去することを含む、請求項１２〜２０のいずれか１項に記載の方法。
【請求項２２】
前記クライアント端末が、前記受信されたフィンガープリント又は前記フィンガープリントリストのデータの完全性が危うくされていると前記クライアント端末が決定した場合、前記システム、前記サーバ、前記システムの認証局及び前記クライアント端末のユーザのうち少なくとも１つへ報告し、前記報告が、前記危うくされているフィンガープリント又はリストのソースを識別して報告することを含むことが可能である、請求項１３〜２１のいずれか１項に記載の方法。
【請求項２３】
前記第１のフィンガープリントリストの１つ又は複数のエントリを取得するステップが、前記第１のフィンガープリントリストのエントリの特定のセグメントを取得することを含み、前記第１のフィンガープリントを算出するステップが、
前記算出されたハッシュ値を第２のフィンガープリントリストに記憶するステップと、
前記第２のフィンガープリントリストの１つ又は複数のエントリを、前記第１のリストの１つ又は複数のエントリを取得するステップと同じ方法で取得するステップであって、前記１つ又は複数のエントリが前記第１のフィンガープリントによってカバーされる、ステップと、
少なくとも前記取得された第２のフィンガープリントリストの１つ又は複数のエントリに関して、前記ハッシュ値を算出する第１のステップと同様にしてハッシュ値を算出するステップとをさらに含む、請求項２〜１１のいずれか１項に記載の方法。
【請求項２４】
前記特定のセグメントが時間間隔によって定義され、前記第１のフィンガープリントリストにおける取得されたエントリの時間仕様が、前記時間間隔に関連付けられ、且つ前記時間間隔にカバーされる、請求項２３及び３に記載の方法。
【請求項２５】
前記第２のフィンガープリントリストの１つ又は複数のエントリを取得するステップが、前記第２のフィンガープリントリストの特定のセグメントを取得することを含み、前記第２のフィンガープリントを算出するステップが、
前記算出されたハッシュ値を第３のフィンガープリントリストに記憶するステップと、
前記第３のフィンガープリントリストの１つ又は複数のエントリを、前記第１のリストの１つ又は複数のエントリを取得するステップと同じ方法で取得するステップであって、前記１つ又は複数のエントリが前記第１のフィンガープリントによってカバーされる、ステップと、
少なくとも前記取得された第３のフィンガープリントリストの１つ又は複数のエントリに関して、前記ハッシュ値を算出する第１のステップと同様にしてハッシュ値を算出するステップであって、任意選択として、前記ハッシュ値をさらなるフィンガープリントリストに記憶するステップと、続いて前記さらなるリストのエントリをカバーするさらなるハッシュ値を算出するステップとを含む、ステップとをさらに含む、請求項２３又は２４に記載の方法。
【請求項２６】
前記サーバが、前記第２のリスト、前記第３のリスト、前記特定のセグメント、前記第１、第２又は第３のリストの特別のエントリ及び／又はセグメントの特別なエントリを他のクライアント端末へ、又は前記システムの他の当事者へ供給し、前記他のクライアント端末又は当事者は前記供給を要求している、請求項２３〜２５のいずれか１項に記載の方法。
【請求項２７】
前記サーバが、時間間隔、前記フィンガープリントリストの１つの特定のフィンガープリント、及び前記特定のフィンガープリントに対する個々のデジタルデータのうち少なくとも１つを特定した要求を受信する、請求項２６に記載の方法。
【請求項２８】
幾つかの第２の、及び幾つかの第３のフィンガープリントリスト及び前記フィンガープリントリストの個々の幾つかの第２及び第３のフィンガープリントは算出され且つ／又は供給され、各リストが、異なる時間スケジュール及び時間間隔に従って、且つ／又は各リストにおけるエントリの異なる最大数に従って異なる種類のデジタルデータのために使用されることが可能である、請求項２３〜２７のいずれか１項に記載の方法。
【請求項２９】
前記第２のフィンガープリントリストが、前記第１のフィンガープリントリスト又は前記第１のフィンガープリントリストの特定のセグメントである、請求項２３〜２８のいずれか１項に記載の方法。
【請求項３０】
前記異なる時間スケジュール、異なる時間間隔又は前記エントリの異なる最大数が、前記サーバ又は前記システムの専用の手段により、前記システム、前記サーバ及び前記クライアント端末のうち少なくとも１つに関するペイロード及びパフォーマンス仕様に従って適合化又は特定される、請求項２８に記載の方法。
【請求項３１】
前記第１のフィンガープリントリスト、前記第２のフィンガープリントリスト又は前記第１のフィンガープリントのうち少なくとも１つの前記算出されたフィンガープリントが、前記第１のリストの特定のセグメント、前記第１のリストの他のセグメント、他の第１のリスト、前記第２のリスト、他の第２のリスト、前記第３のリスト、他の第３のリスト又は前記リストのエントリからコンパイルされたフィンガープリントのさらなるリストのうち少なくとも１つにさらに追加されることが可能である、請求項２３〜３０のいずれか１項に記載の方法。
【請求項３２】
前記セグメント、前記第１のリスト、前記第２のリスト及び／又は前記第３のリストの１つ又は複数のエントリが、前記第１のリストの特定のセグメント、前記第１のリストの他のセグメント、他の第１のリスト、前記第２のリスト、他の第２のリスト、前記第３のリスト、他の第３のリスト又は前記リストのエントリからコンパイルされたフィンガープリントのさらなるリストのうち少なくとも１つに追加される、請求項２３〜３１のいずれか１項に記載の方法。
【請求項３３】
デジタルデータを取得するステップと、
第２のフィンガープリントリストを要求するステップであって、前記第２のフィンガープリントリストが、前記第１のフィンガープリントリストにおけるフィンガープリントの少なくとも１つを算出するために使用されるフィンガープリントエントリを含み、前記フィンガープリントエントリの少なくとも１つが、前記取得されたデジタルデータをカバーする、ステップと、
前記要求された第２のフィンガープリントリストを取得するステップと、
前記第１のフィンガープリントリストにおける特定のフィンガープリントを算出するために使用される前記第２のリストのフィンガープリントエントリに関して第１のハッシュ値を算出するステップであって、前記フィンガープリントエントリの少なくとも１つが、前記取得されたデジタルデータをカバーし、それ故前記特定のフィンガープリントが、前記取得されたデジタルデータをカバーする、ステップと、
前記算出された第１のハッシュ値を前記特定のフィンガープリントと比較するステップと、
前記比較するステップの結果、フィンガープリントが異なれば、前記取得されたデジタルデータ又は前記フィンガープリントリストの少なくとも１つのデータの完全性が危うくされていることを確立するステップと、
前記取得されたデジタルデータに関して第２のハッシュ値を算出するステップと、
前記算出された第２のハッシュ値を前記取得されたデジタルデータをカバーする前記第２のフィンガープリントリストにおけるフィンガープリントと比較するステップと、
前記比較するステップの結果、フィンガープリントが異なれば、前記取得されたデジタルデータ又は前記フィンガープリントリストの少なくとも１つのデータの完全性が危うくされていることを確立するステップとをさらに含む、請求項１２〜２２のいずれか１項に記載の方法。
【請求項３４】
前記取得されたデジタルデータに関して第２のハッシュ値を算出するステップが、
第３のフィンガープリントリストを要求するステップであって、前記第３のフィンガープリントリストが、前記第２のフィンガープリントリストにおけるフィンガープリントの少なくとも１つを算出するために使用されるフィンガープリントエントリを含み、前記フィンガープリントエントリの少なくとも１つが、前記取得されたデジタルデータをカバーする、ステップと、
前記要求された第３のフィンガープリントリストを取得するステップと、
前記第２のフィンガープリントリストにおける特定のフィンガープリントを算出するために使用される前記第３のリストのフィンガープリントエントリに関して第３のハッシュ値を算出するステップであって、前記第３のフィンガープリントリストにおける前記フィンガープリントエントリの少なくとも１つが、前記取得されたデジタルデータをカバーする、ステップと、
前記算出された第３のハッシュ値を前記第２のフィンガープリントリストにおける前記特定のフィンガープリントと比較するステップと、
前記比較するステップの結果、フィンガープリントが異なれば、前記取得されたデジタルデータ又は前記フィンガープリントリストの少なくとも１つのデータの完全性が危うくされていることを確立するステップとを含む、請求項３３に記載の方法。
【請求項３５】
前記第１、第２又は第３のフィンガープリントリストの少なくとも１つが、他のフィンガープリントリストのセグメントである、請求項３３又は３４に記載の方法。
【請求項３６】
前記フィンガープリントリストを要求するステップが、
前記要求されたリストのエントリに関連付けられる時間間隔、
前記要求されたリストの少なくとも１つのエントリに関する時間仕様、
前記要求されたリストの少なくとも１つのフィンガープリント、
少なくとも前記要求されたリストのフィンガープリントによってカバーされた少なくとも１つのデジタルデータ、
前記要求されたリストの識別子、及び
前記要求されたリストの少なくとも１つのエントリの識別子のうち少なくとも１つを特定することによって前記要求されたフィンガープリントリストを特定するステップを含む、請求項３３〜３５のいずれか１項に記載の方法。
【請求項３７】
前記デジタルデータが、公開鍵対の公開鍵、認証、コンピュータプログラム、ソフトウェアファイル、データベース、実行ファイル、デジタル画像、映像又は音声情報及びデータファイルのうち少なくとも１つからなる、請求項１〜３６のいずれか１項に記載の方法。
【請求項３８】
請求項１〜１１又は請求項２３〜３２のいずれか１項に記載の少なくとも１つのサーバと、請求項１２〜２２又は請求項３３〜３６のいずれか１項に記載の少なくとも１つのクライアント端末とを備える、システム。
【請求項３９】
オペレーションに参加し実行する複数のクライアント端末を、請求項１２〜２２又は請求項３３〜３６のいずれか１項に明記された方法に従って制御するためのコンピュータプログラムを有する、コンピュータ読取り可能な記憶媒体。
【請求項４０】
オペレーションに参加し実行するサーバを、請求項１〜１１又は請求項２３〜３２のいずれか１項に明記された方法に従って制御するためのコンピュータプログラムを有する、コンピュータ読取り可能な記憶媒体。
【請求項４１】
公開鍵システムにおいてデジタルデータの安全な配信を供給するための方法であって、
第１の鍵対の公開鍵を使用してデジタルデータを暗号化することと、
前記第１の鍵対の対応する秘密鍵の使用を防止することにより前記暗号化されたデジタルデータの復号化を防止することと、
さらなるデジタルデータを暗号化し且つ復号化するために、前記第１の鍵対を第２の鍵対に交換することとを含む、方法。
【請求項４２】
前記防止するステップが、前記秘密鍵を取り消す又は削除することを含む、請求項４１に記載の方法。
【請求項４３】
前記暗号化するステップが、前記システムの第１の当事者によって実行され、対応する復号化が、前記システムの第２の当事者によって実行され、前記防止するステップ及び前記交換するステップが、前記システムによって少なくとも制御されるか、開始されるか、実行され、前記方法が、前記暗号化されたデジタルデータをネットワークを介して前記第２の当事者へ供給するステップと、前記暗号化されたデジタルデータ又はその個々のコピーを前記第２の当事者によって記憶するステップとを含む、請求項４１又は４２に記載の方法。
【請求項４４】
前記ネットワークがインターネットである、請求項４３に記載の方法。
【請求項４５】
前記防止するステップが、第１のスケジュールに従って自動的に実行され、前記交換するステップが、第２のスケジュールに従って自動的に実行される、請求項４１〜４４のいずれか１項に記載の方法。
【請求項４６】
前記第１及び前記第２のスケジュールが互いに独立していて、前記システム又は前記第１の当事者のいずれかによって特定される、請求項４３及び４５に記載の方法。
【請求項４７】
前記第１及び前記第２のスケジュールの少なくとも１つが、各々、第１及び第２の時間スパンを含み、前記防止するステップ及び前記交換するステップが、各々、前記第１及び前記第２の時間スパンが過ぎた後に実行され、前記第１及び／又は前記第２の時間スパンが、各々、
前記暗号化するステップ、
前記暗号化されたデータの前記第２の当事者への供給、
前記第１又は第２の鍵対の生成又は配信、又は
各々他の第１又は第２の時間スパンが開始された後の所定の時間のうちの１つによって開始される、請求項４５又は４６に記載の方法。
【請求項４８】
前記第１及び第２の鍵対の少なくとも１つが、前記システムの専用の手段によって生成され、配信され、又は供給される、請求項４１〜４７のいずれか１項に記載の方法。
【請求項４９】
２つ以上の第１の鍵対を、同時的な、又は重複する時間期間において使用し、且つ／又は２つ以上の第２の鍵対と交換する、請求項４１〜４８のいずれか１項に記載の方法。
【請求項５０】
前記２つ以上の第１の鍵対の各々が、異なる種類のデジタルデータ、前記第１の当事者の異なるグループ及び前記第２の当事者の異なるグループのうちの少なくとも１つのために個々に使用され、前記防止するステップ及び前記交換するステップが、前記暗号化されたデジタルデータへのアクセスを選択的に制御するために前記２つ以上の第１の鍵対の各々へ選択的且つ独立して適用される、請求項４９及び４３に記載の方法。
【請求項５１】
前記公開鍵の制御された削除又は取消しによって前記第１の鍵対の公開鍵の使用を防止するステップをさらに含む、請求項４１〜５０のいずれか１項に記載の方法。
【請求項５２】
前記公開鍵の使用を防止するステップが、前記システム又は前記第１の当事者によって少なくとも開始されるか、制御されるか、実行され、前記方法が、前記第２のユーザが前記公開鍵の使用を防止するステップの後に前記秘密鍵を使用する前記復号化プロセスにより依然として前記デジタルデータにアクセスするように導くために使用される、請求項４３及び５１に記載の方法。
【請求項５３】
前記方法が、
前記先行して暗号化されたデータに対する不正行為を損なわせる、
前記指定された、又は所定の時間枠の後に削除されるデジタルデータであって、前記暗号化されたデジタルデータの追加的に可能なバックアップコピー及び／又はログ情報もまた削除される、デジタルデータ、
前記第１の鍵対の前記秘密鍵の可能な開示は前記暗号化されたデジタルデータのセキュリティ及び秘密性を危うくしないことを保証することのうち少なくとも１つのために使用される、請求項４１〜５１のいずれか１項に記載の方法。
【請求項５４】
公開鍵システムにおけるデジタルデータの配信を制御するための方法であって、
第１の鍵対の公開鍵を使用して前記デジタルデータを暗号化することにより暗号化されたデジタルデータを算出することと、
前記第１の鍵対の対応する秘密鍵を使用して前記暗号化されたデジタルデータを復号化することと、
前記公開鍵の使用を防止することによって、さらなるデジタルデータに対する前記暗号化ステップを防止することと、
さらなるデジタルデータを暗号化し且つ復号化するために、前記第１の鍵対を第２の鍵対と交換することとを含む、方法。
【請求項５５】
前記暗号化するステップが、前記システムの第１の当事者によって実行され、対応する復号化ステップが、前記システムの第２の当事者によって実行され、前記防止するステップ及び交換するステップが、前記システムの専用の手段によって少なくとも制御されるか、開始されるか、実行され、前記方法が、前記暗号化されたデジタルデータをネットワークを介して前記第２の当事者へ供給するステップをさらに含む、請求項５４に記載の方法。
【請求項５６】
前記防止するステップが、前記公開鍵を取り消す、又は削除することを含む、請求項５４又は５５に記載の方法。
【請求項５７】
前記システムによって前記第１の鍵対の前記秘密鍵を制御して削除する、又は取り消すステップをさらに含む、請求項５４〜５６のいずれか１項に記載の方法。
【請求項５８】
公開鍵システムにおけるデジタルデータの配信を制御するための方法であって、
前記デジタルデータ上のデジタル署名を、第１のデジタル署名スキームに従って第１の鍵対の秘密鍵を使用して算出することと、
前記デジタル署名を、前記第１のデジタル署名スキームに従って前記第１の鍵対の対応する公開鍵を使用して検証することと、
前記秘密鍵の使用を防止することによって、さらなるデジタルデータに関する前記算出するステップを防止することと、
さらなるデジタルデータ上のデジタル署名を算出し且つ検証するために前記第１の鍵対を第２の鍵対と交換することとを含む、方法。
【請求項５９】
前記算出するステップが、前記システムの第１の当事者によって実行され、対応する検証ステップが、前記システムの第２の当事者によって実行され、前記防止するステップ及び交換するステップが、前記システムの専用の手段によって少なくとも制御されるか、開始されるか、実行され、前記方法が、前記デジタル署名及び前記デジタルデータをネットワークを介して前記第２の当事者へ供給するステップをさらに含む、請求項５８に記載の方法。
【請求項６０】
前記第２の当事者が、前記デジタル署名を検証するステップが失敗した場合に、前記供給されたデジタルデータを拒絶し、又は前記第２の当事者が、前記検証するステップが成功した場合にのみ、前記提供されたデジタルデータを使用し且つこれにアクセスすることができる、又はそれらを許容される、請求項５８又は５９に記載の方法。
【請求項６１】
前記デジタルデータを前記算出するステップに関連して暗号化するステップと、前記デジタルデータを成功裡の検証ステップの後に復号化するステップとをさらに含む、請求項５８〜６０のいずれか１項に記載の方法。
【請求項６２】
前記防止するステップが、前記秘密鍵を取り消す、又は削除することを含む、請求項５８〜６１のいずれか１項に記載の方法。
【請求項６３】
前記ネットワークがインターネットである、請求項５５、５６又は請求項５９〜６２のいずれか１項に記載の方法。
【請求項６４】
前記防止するステップが、第１のスケジュールに従って自動的に実行され、前記交換するステップが、第２のスケジュールに従って自動的に実行される、請求項５４〜６３のいずれか１項に記載の方法。
【請求項６５】
前記第１及び第２のスケジュールが、互いに独立していて、前記システム又は前記第１の当事者のいずれかによって特定される、請求項６４及び５５に記載の、又は請求項６４及び５９に記載の方法。
【請求項６６】
前記第１及び前記第２のスケジュールの少なくとも１つが、各々、第１及び第２の時間スパンを含み、前記防止するステップ及び前記交換するステップが、各々、前記第１及び第２の時間スパンが過ぎた後に実行され、前記第１及び／又は前記第２の時間スパンが、
前記算出するステップ、
前記第２の当事者へ供給するステップ、
前記第１又は第２の鍵対の生成又は配信、又は
各々他の第１又は第２の時間スパンが開始された後の所定の時間のうちの１つによって開始される、請求項６４又は６５に記載の方法。
【請求項６７】
前記第１及び第２の鍵対の少なくとも１つが、前記システムによって生成され、配信され、又は供給される、請求項５４〜６６のいずれか１項に記載の方法。
【請求項６８】
２つ以上の第１の鍵対が、同時的な、又は重複する時間期間において使用される、請求項５４〜６７のいずれか１項に記載の方法。
【請求項６９】
前記２つ以上の第１の鍵対の各々が、異なる種類のデジタルデータ、前記第１の当事者の異なるグループ及び前記第２の当事者の異なるグループのうち少なくとも１つのために個々に使用され、前記防止するステップ及び前記交換するステップが、前記デジタルデータへの安全な配信を選択的に制御するために前記２つ以上の第１の鍵対の各々へ選択的且つ独立して適用される、請求項６８及び５５に記載の、又は請求項６８及び５９に記載の方法。
【請求項７０】
前記方法が、追加的なデジタルデータがデジタルデータプールへ一切追加され得ないように制御するために使用され、前記プールに関連付けられる先行するデジタルデータは、引き続き配信、使用又はアクセス可能であり、デジタルデータの異なるプールは、異なる鍵対によって確立される、請求項５４〜６９のいずれか１項に記載の方法。
【請求項７１】
オペレーションに参加し実行する公開鍵システムの複数のクライアント端末を、請求項５４〜７０のいずれか１項に明記された方法に従って制御するためのコンピュータプログラムを有する、コンピュータ読取り可能な記憶媒体。
【請求項７２】
オペレーションに参加し実行する公開鍵システムのサーバを、請求項５４〜７０のいずれか１項に明記された方法に従って制御するためのコンピュータプログラムを有する、コンピュータ読取り可能な記憶媒体。
【請求項７３】
データ配信システムにおいてデジタルデータの層状の非対称暗号化を供給するための方法であって、
前記デジタルデータを第１の暗号化層において第１の鍵を使用して暗号化するステップと、
前記第１の鍵を前記第１の暗号化層において第２の鍵を使用して暗号化するステップと、
前記暗号化された第１の鍵を第２の暗号化層において第３の鍵を使用して暗号化するステップと、
前記暗号化されたデータ及び前記暗号化された第１の鍵を供給するステップと、
前記暗号化された第１の鍵を前記第２の暗号化層に従って復号化するステップと、
前記暗号化された第１の鍵を前記第１の暗号化層に従って復号化するステップと、
前記暗号化されたデジタルデータを前記第１の暗号化層に従って復号化するステップとを含む、方法。
【請求項７４】
前記デジタルデータを暗号化するステップが前記システムの第１の当事者によって実行され、前記第１の鍵が対称鍵であり、
前記第１の鍵を前記第１の暗号化層において暗号化するステップが前記第１の当事者によって実行され、前記第２の鍵が第１の公開鍵対の公開鍵であり、
前記暗号化された第１の鍵を前記第２の暗号化層において暗号化するステップが前記システムの前記第１の当事者又は第２の当事者によって実行され、前記第３の鍵が第２の公開鍵対の公開鍵であり、
前記供給するステップが、前記暗号化されたデータ及び前記暗号化された第１の鍵をネットワークによって前記システムの第３の当事者へ供給し、
前記暗号化された第１の鍵を前記第２の暗号化層に従って復号化するステップが、前記第３の当事者により前記第２の公開鍵対の秘密鍵を使用して実行され、
前記暗号化された第１の鍵を前記第１の暗号化層に従って復号化するステップが、前記システムの前記第３の当事者又は第４の当事者により前記第１の公開鍵対の秘密鍵を使用して実行され、
前記暗号化されたデジタルデータを復号化するステップが、前記第３又は第４の当事者により前記復号化された第１の鍵を使用して実行される、請求項７３に記載の方法。
【請求項７５】
前記暗号化された第１の鍵を、前記第２の暗号化層における前記暗号化の後に第３の暗号化層において第４の鍵を使用して暗号化するステップと、
前記暗号化された第１の鍵を、前記第２の暗号化層による前記復号化ステップより前に前記第３の暗号化層に従って復号化するステップとをさらに含む、請求項７３又は７４に記載の方法。
【請求項７６】
前記第１の鍵を前記第４の鍵を使用して暗号化するステップが、前記第１の当事者、前記第２の当事者又は第５の当事者のうち１つによって実行され、前記第４の鍵が、第３の公開鍵対の公開鍵であり、前記第３の暗号化層に従って復号化するステップが、前記システムの前記第３の当事者、前記第４の当事者又は第６の当事者のうち１つにより前記第３の公開鍵対の秘密鍵を使用して実行される、請求項７５に記載の方法。
【請求項７７】
前記第１の鍵を暗号化する１つ又は複数のステップが、前記デジタルデータを個々の暗号化層の暗号鍵を使用して暗号化することをさらに含む、請求項７３〜７６のいずれか１項に記載の方法。
【請求項７８】
前記暗号化された第１の鍵を暗号化する１つ又は複数のステップが、
前記第１の鍵をさらなる対称鍵を使用して暗号化することと、
前記さらなる対称鍵を前記１つ又は複数の暗号化ステップの暗号化層の個々の公開鍵対の公開鍵を使用して暗号化することと、
前記暗号化されたさらなる対称鍵を前記暗号化された第１の鍵に関連付けることであって、前記暗号化されたさらなる対称鍵が、任意の次の暗号化層によって前記第１の鍵と同様にして処理され、前記次の暗号化層が、暗号化された両方の鍵を１つの鍵情報部分として、又は２つの別個の暗号化された鍵と見なすこととを含み、
前記暗号化ステップの対応する復号化ステップが、
前記暗号化されたさらなる対称鍵を前記個々の暗号化層の公開鍵対の秘密鍵を使用して復号化することと、
前記暗号化された第１の鍵を前記復号化されたさらなる対称鍵を使用して復号化することとを含む、請求項７４〜７７のいずれか１項に記載の方法。
【請求項７９】
ネットワークを介する送信者から受信者までのデジタルデータの配信経路を制御するための方法であって、前記ネットワークが複数の接続されたネットワークノードを備え、
ａ）前記デジタルデータを第１の暗号化層において第１の鍵を使用して暗号化するステップと、
ｂ）前記第１の鍵を前記第１の暗号化層において第２の鍵を使用して暗号化するステップであって、前記第２の鍵が、前記デジタルデータの受信者に関連付けられる公開鍵である、ステップと、
ｃ）前記暗号化された第１の鍵を第２の暗号化層において第３の鍵を使用して暗号化するステップであって、前記第３の鍵が、第１のネットワークノードに関連付けられる公開鍵であり、前記デジタルデータが、配信経路沿いに前記ネットワークを介して前記受信者へ送られるように定義される、ステップと、
ｄ）前記暗号化されたデータ及び前記暗号化された第１の鍵を前記第１のネットワークノードへ供給するステップと、
ｅ）前記暗号化された第１の鍵を前記第１のネットワークノードにおいて前記第２の暗号化層に従って、前記第１のネットワークノードの前記公開鍵に対応する秘密鍵を使用して復号化するステップと、
ｆ）前記暗号化されたデータ及び前記暗号化された第１の鍵を前記受信者へ供給するステップと、
ｇ）前記暗号化された第１の鍵を前記第１の暗号化層に従って、前記受信者の前記公開鍵に対応する秘密鍵を使用して復号化するステップと、
ｈ）前記暗号化されたデジタルデータを前記第１の暗号化層に従って前記復号化された第１の鍵を使用して復号化するステップとを含む、方法。
【請求項８０】
前記暗号化するステップｃ）が、前記送信者又は前記暗号化されたデータと前記暗号化された第１の鍵とからなるメッセージが先に通過した第３のネットワークノードによって実行される、請求項７９に記載の方法。
【請求項８１】
前記暗号化された第１の鍵を第３の暗号化層において第４の鍵を使用して暗号化するステップであって、前記第４の鍵が、第２のネットワークノードに関連付けられる公開鍵であり、前記デジタルデータが、配信経路沿いに前記ネットワークを介して前記受信者へ送られるように定義される、ステップと、
前記暗号化されたデータ及び前記暗号化された第１の鍵を前記第２のネットワークノードへ供給するステップと、
前記暗号化された第１の鍵を前記第２のネットワークノードにおいて前記第３の暗号化層に従って、前記第２のネットワークノードの前記公開鍵に対応する秘密鍵を使用して復号化するステップとをさらに含む、請求項７９又は８０に記載の方法。
【請求項８２】
前記暗号化するステップが、前記送信者、前記第１のネットワークノード又は前記暗号化されたデータと前記暗号化された第１の鍵とからなるメッセージが先に通過した第３のネットワークノードのうち１つによって実行される、請求項８１に記載の方法。
【請求項８３】
各ネットワークノードにより前記暗号化されたデジタルデータ及び前記暗号化された第１の鍵を受信した後に実行される、
前記暗号化されて受信された第１の鍵が前記ネットワークノードにより特定の暗号化層に従って復号化されるかどうかを確立するステップと、
前記ネットワークノードが前記暗号化された第１の鍵を復号化しなければならない場合、前記暗号化された第１の鍵を前記特定の暗号化層に従って個々の秘密鍵を使用して復号化するステップと、
前記受信者を含む前記ネットワークの次のネットワークノードを確立するステップであって、前記暗号化されたデジタルデータ及び前記暗号化された第１の鍵が前記ネットワークノードによって供給されなければならない、ステップと、
前記暗号化された第１の鍵が少なくとも１つのさらなる暗号化層において前記次のネットワークノードに関連付けられる公開鍵及び／又はさらなるネットワークノードの公開鍵を使用して暗号化されなければならないかどうかを確立するステップと、
前記暗号化された第１の鍵が暗号化されなければならない場合、前記公開鍵を取得し、前記暗号化された第１の鍵を前記さらなる暗号化層に従って前記公開鍵を使用して暗号化するステップとをさらに含む、請求項７９〜８２のいずれか１項に記載の方法。
【請求項８４】
前記送信者及び／又は前記暗号化されたデータ及び前記暗号化された第１の鍵を送信するネットワークノードが、前記受信者を含む前記ネットワークの少なくとも１つのネットワークノードを特定し、前記暗号化されたデータ及び前記暗号化された第１の鍵が、前記受信者へ送信される際にこれを通過しなければならない、請求項７９〜８３のいずれか１項に記載の方法。
【請求項８５】
前記特定することが、少なくとも前記暗号化された第１の鍵を暗号化層に従って前記特定されたネットワークノードの公開鍵を使用して暗号化することよりなる、請求項８４に記載の方法。
【請求項８６】
ネットワークの複数のネットワークノードを制御するためのコンピュータプログラムを有するコンピュータ読取り可能な記憶媒体であって、前記コンピュータプログラムが、ネットワークノードに、暗号化されたデジタルデータ部分及び暗号化された第１の鍵部分からなるメッセージを受信した後に請求項８３に記載のステップを実行させる、コンピュータ読取り可能な記憶媒体。
【請求項８７】
前記ネットワークノードに前記受信者を含む前記ネットワークの少なくとも１つのネットワークノードを特定するステップをさらに実行させ、前記暗号化されたデータ及び前記暗号化された第１の鍵が、前記受信者へ送信される際にこれを通過しなければならず、前記特定するステップが、少なくとも前記暗号化された第１の鍵を暗号化層に従って前記特定されたネットワークノードの公開鍵を使用して暗号化することを含む、請求項８６に記載のコンピュータプログラム。
【請求項８８】
オペレーションに参加し実行する前記ネットワークノードを、請求項７４〜８５のいずれか１項に明記された方法に従ってさらに制御する、請求項８６に記載のコンピュータプログラム。
【請求項８９】
オペレーションに参加し実行する公開鍵システムの複数のクライアント端末を、請求項７３〜８５のいずれか１項に明記された方法に従って制御するためのコンピュータプログラムを有する、コンピュータ読取り可能な記憶媒体。
【請求項９０】
公開鍵システムにおけるデジタルデータの配信を前記デジタルデータ上のデジタル署名を使用して制御するための方法であって、
前記デジタルデータのハッシュ値を送信者により算出するステップと、
第１のデジタル署名を前記送信者により、前記ハッシュ値を第１のデジタル署名スキームに従って第１の公開鍵対の第１の秘密鍵を使用して暗号化することによって算出するステップと、
第２のデジタル署名を、前記第１のデジタル署名を第２のデジタル署名スキームに従って第２の公開鍵対の第２の秘密鍵を使用して暗号化することによって算出するステップと、
前記第２のデジタル署名及び前記デジタルデータを前記デジタルデータの受信者へ供給するステップと、
前記第２のデジタル署名の第１の検証値を前記第２のデジタル署名スキームに従って前記第２の公開鍵対の公開鍵を使用して算出するステップと、
前記第１の検証値の第２の検証値を前記第１のデジタル署名スキームに従って前記第１の公開鍵対の公開鍵を使用して算出するステップと、
前記デジタルデータのハッシュ値を取得するステップと、
前記取得されたハッシュ値と前記第２の検証値とを比較するステップと、
前記比較するステップの結果、値が異なれば、前記受信者へのデータ配信プロセスは意図されたプロセスフローから外れていることを確立するステップとを含む、方法。
【請求項９１】
前記第１のデジタル署名を前記供給されたデジタルデータ及び前記供給された第２のデジタル署名と共に前記供給するステップ、又はさらなる供給するステップのいずれかにおいて取得するステップと、
前記取得された第１のデジタル署名と前記算出された第１の検証値とを比較するステップと、
前記比較するステップの結果、値が異なれば、前記受信者へのデータ配信プロセスは意図されたプロセスフローから外れていることを確立するステップとをさらに含む、請求項９０に記載の方法。
【請求項９２】
前記ハッシュ値を取得するステップが、
前記ハッシュ値を前記供給されたデジタルデータから、前記送信者によって実行された前記ハッシュ値を算出する第１のステップと同様にして算出するステップ、又は
前記ハッシュ値を、前記供給するステップにおいて前記供給されたデジタルデータ及び前記供給された第２のデジタル署名と共に取得するステップのうち少なくとも１つを含む、請求項９０又は９１に記載の方法。
【請求項９３】
前記第２のデジタル署名を算出するステップが、
前記第１のデジタル署名を交換するために、前記第２のデジタル署名の算出に先立って第３のデジタル署名を、前記第１のデジタル署名を第３のデジタル署名スキームに従って第３の公開鍵対の第３の秘密鍵を使用して暗号化することによって算出するステップをさらに含み、
前記第２の検証値を算出するステップが、
前記第１の検証値を交換するために、前記第２の検証値の算出に先立って前記第１の検証値の第３の検証値を、前記第３のデジタル署名スキームに従って前記第３の公開鍵対の公開鍵を使用して算出するステップをさらに含む、請求項９０〜９２のいずれか１項に記載の方法。
【請求項９４】
前記第３のデジタル署名を前記供給されたデジタルデータ及び前記供給された第２のデジタル署名と共に前記供給するステップ、又はさらなる供給するステップの１つにおいて取得するステップと、
前記取得された第３のデジタル署名と前記算出された第１の検証値とを前記第２の検証値を算出するステップに先立って比較するステップと、
前記比較するステップの結果、値が異なれば、前記受信者へのデータ配信プロセスは意図されたプロセスフローから外れていることを確立するステップとをさらに含む、請求項９３に記載の方法。
【請求項９５】
前記デジタル署名が、前記配信プロセスのために請求項７３〜７８における少なくとも１つの請求項に定義されているように暗号化され、前記デジタル署名を算出するステップの各々及び前記検証値を算出する個々のステップ、比較し且つ確立する個々のステップが、前記暗号化層の１つに関連付けられ、且つこれに関連して実行される、請求項９０〜９４のいずれか１項に記載の方法。
【請求項９６】
ネットワークを介する送信者から受信者までのデジタルデータの配信経路を制御するための方法であって、前記ネットワークが、複数の接続されたネットワークノードを備え、前記方法が、請求項９０〜９４のいずれか１項のステップを含み、前記ネットワークノードの少なくとも１つが、前記デジタル署名を算出するステップの１つを実行する、方法。
【請求項９７】
前記ネットワークノードの少なくとも１つが、前記検証値を算出するステップと、ハッシュ値を取得するステップと、比較するステップと、確立するステップとを実行する、請求項９６及び９０に記載の方法。
【請求項９８】
前記ネットワークノードの少なくとも１つが、各ステップが前記公開鍵対の特定の１つに関連付けられる、
前記検証値を算出するステップ、
前記デジタル署名を取得するステップ、
前記取得されたデジタル署名と前記算出された検証値とを比較するステップ、
前記確立するステップのうち少なくとも１つのグループを実行する、請求項９１〜９４のいずれか１項及び請求項９６〜９７のいずれか１項に記載の方法。
【請求項９９】
前記暗号化された第１の鍵を第３の暗号化層において第４の鍵を使用して暗号化するステップであって、前記第４の鍵が、第２のネットワークノードに関連付けられる公開鍵であり、前記デジタルデータが、配信経路沿いに前記ネットワークを介して前記受信者へ送られるように定義される、ステップと、
前記暗号化されたデータ及び前記暗号化された第１の鍵を前記第２のネットワークノードへ供給するステップと、
前記暗号化された第１の鍵を前記第２のネットワークノードにおいて前記第３の暗号化層に従って前記第２のネットワークノードの前記公開鍵に対応する秘密鍵を使用して復号化するステップとをさらに含む、請求項７９又は８０に記載の方法。
【請求項１００】
各々が前記公開鍵対の１つに関連付けられる署名スキームは互いに異なるものであることが可能であり、前記システム、前記デジタルデータの送信者又は前記デジタルデータを前記システム内の他の当事者へ供給する前記システム内の他の当事者により予め決められ、又は指定される、請求項９０〜９９のいずれか１項に記載の方法。
【請求項１０１】
各ネットワークノードにより前記デジタルデータ及び前記デジタル署名を受信した後に実行される、
前記受信されたデジタル署名が前記ネットワークによってデジタル式に署名されなければならないかどうかを確立するステップと、
前記ネットワークノードが前記受信されたデジタル署名をデジタル式に署名しなければならない場合、前記受信されたデジタル署名を交換するために、前記デジタルデータ及び前記算出されたデジタル署名のさらなるネットワークノード又は前記受信者への供給に先立ってさらなるデジタル署名を、前記受信されたデジタル署名をさらなるデジタル署名スキームに従ってさらなる公開鍵対のさらなる秘密鍵を使用して暗号化することによって算出するステップと、
前記受信者を含む前記ネットワークの次のネットワークノードを確立するステップであって、前記デジタルデータ及び前記算出されたデジタル署名が、前記ネットワークノードによって供給されなければならない、ステップとをさらに含む、請求項９６〜１００のいずれか１項に記載の方法。
【請求項１０２】
ネットワークの複数のネットワークノードを制御するためのコンピュータプログラムを有するコンピュータ読取り可能な記憶媒体であって、前記コンピュータプログラムが、ネットワークノードに、前記デジタルデータ及び前記デジタル署名からなるメッセージを受信した後に請求項１０１に記載のステップを実行させる、コンピュータ読取り可能な記憶媒体。
【請求項１０３】
前記オペレーションに参加し実行するネットワークノードを請求項９０〜１００のいずれか１項に明記された方法に従ってさらに制御する、請求項１０２に記載のコンピュータプログラム。
【請求項１０４】
オペレーションに参加し実行する公開鍵システムの複数のクライアント端末を請求項９０〜１０１のいずれか１項に明記された方法に従って制御するためのコンピュータプログラムを有する、コンピュータ読取り可能な記憶媒体。
【請求項１０５】
クライアント・サーバシステムにおいてデジタルデータを交換するための安全な通信を供給するための方法であって、前記システムが、ネットワークを介して接続される少なくとも１つのサーバと複数のクライアント端末とを備え、
デジタルデータを前記システムのクライアント端末により、先に取得された第１のハッシュ値を対称暗号化スキームにおける鍵情報として使用して暗号化するステップと、
前記暗号化デジタルデータ及び先に取得された乱数トークンを前記クライアント端末により前記システムのサーバへ供給するステップであって、前記第１のハッシュ値が、前記乱数トークンに関連付けられ、且つ前記サーバと前記クライアント端末とで共有される秘密として機能する、ステップと、
前記サーバにより前記供給された乱数トークン及び一定の乱数値の第２のハッシュ値を算出するステップであって、前記一定の乱数値が、前記サーバが保有していて前記複数のクライアント端末には開示されない非公開の秘密値である、ステップと、
前記暗号化されたデジタルデータを前記サーバにより前記対称暗号化スキームに従って前記第２のハッシュ値を鍵情報として使用して復号化するステップとを含む、方法。
【請求項１０６】
前記乱数トークンを前記暗号化するステップに先行して取得するステップと、
前記乱数トークンを前記サーバへ前記暗号化するステップに先行して供給するステップと、
前記乱数トークン及び前記一定の乱数値の前記第１のハッシュ値を前記サーバにより前記暗号化するステップに先行して算出するステップと、
前記第１のハッシュ値を前記クライアント端末へ前記暗号化するステップに先行して供給するステップとをさらに含む、請求項１０５に記載の方法。
【請求項１０７】
前記乱数トークンを取得するステップと、
前記乱数トークンを供給するステップと、
前記第１のハッシュ値を算出するステップと、
前記第１のハッシュ値を供給するステップとが、前記クライアント端末の前記サーバへの初回登録プロセスの一部として実行され、その他のステップが、全て前記デジタルデータの安全なデータ交換トランザクションの一部として実行される、請求項１０６に記載の方法。
【請求項１０８】
前記乱数トークンを供給するステップが、前記乱数トークンを非対称暗号化スキームに従って暗号化する先行ステップをさらに含み、
前記第１のハッシュ値を算出するステップが、前記乱数トークンを前記非対称暗号化スキームに従って復号化する先行ステップをさらに含む、請求項１０６又は１０７に記載の方法。
【請求項１０９】
前記第１のハッシュ値を前記クライアント端末へ供給するステップが、第１のハッシュ値を非対称暗号化スキームに従って暗号化する先行ステップをさらに含み、
前記クライアント端末が、暗号化された第１のハッシュ値を前記暗号化された第１のハッシュ値を受信した後に前記個々の非対称暗号化スキームに従って復号化するステップをさらに実行する、請求項１０６〜１０８のいずれか１項に記載の方法。
【請求項１１０】
前記乱数トークンを取得するステップが、前記乱数トークンを前記クライアント端末において生成することを含む、請求項１０６〜１０９のいずれか１項に記載の方法。
【請求項１１１】
前記乱数トークンを取得するステップ及び前記乱数トークンを前記サーバへ供給するステップが、前記乱数トークンを前記サーバにおいて生成するステップにより達成され、
前記第１のハッシュ値を供給するステップが、前記生成された乱数トークンを前記クライアント端末へ供給することをさらに含み、前記第１のハッシュ値が前記供給するステップに関連して暗号化され且つ復号化される場合、前記乱数トークンが、前記第１のハッシュ値と同様にして暗号化され且つ復号化される、請求項１０６〜１０９のいずれか１項に記載の方法。
【請求項１１２】
前記サーバが、複数の異なる一定の乱数値を使用し、前記複数の異なる一定の乱数値の全て又は幾つかが、連続する、同時的又は重複する時間期間で使用される可能性があり、前記複数の異なる一定の乱数値の各々が、
クライアント端末の異なるグループ、
クライアント端末の前記サーバへの異なる登録回数、又は
前記方法のステップの少なくとも１つを実行するための異なる時間期間又は時点のうち少なくとも１つのために使用可能である、請求項１０５〜１０９のいずれか１項に記載の方法。
【請求項１１３】
前記乱数トークンを取得するステップ及び前記乱数トークンを前記サーバへ供給するステップが、前記乱数トークンの一部を前記サーバにおいて生成するステップを含み、
前記第１のハッシュ値を供給するステップが、前記生成された乱数トークンを前記クライアント端末へ供給することをさらに含み、前記第１のハッシュ値が前記供給するステップに関連して暗号化され且つ復号化される場合、前記乱数トークンが、前記第１のハッシュ値と同様にして暗号化され且つ復号化され、
前記サーバが、
前記複数の異なる一定の乱数値の特定値を前記第１のハッシュ値を算出するステップに先行して選定するステップと、
前記複数の異なる一定の乱数値の特定値を前記生成された乱数トークンの一部に関連付けるステップと、
前記複数の異なる一定の乱数値の特定値を前記第２のハッシュ値を算出するステップに先行して、前記供給された乱数トークンから前記生成された部分を決定し、続いて、その関連付けられた特定の一定の乱数値を識別することにより確立するステップとをさらに実行する、請求項１０６〜１０９のいずれか１項及び請求項１１２に記載の方法。
【請求項１１４】
前記複数の異なる一定の乱数値の特定値を前記新しい第１のハッシュ値を算出するステップに先行して選定するステップと、
前記複数の異なる一定の乱数値の特定値を前記第２のハッシュ値を算出するステップに先行して、前記異なる一定の乱数値の各々をそれが前記暗号化されたデジタルデータを前記サーバにより復号化する次のステップにおいて有効な結果をもたらすかどうか連続して検査することにより確立するステップとをさらに含む、請求項１０６〜１１１のいずれか１項及び請求項１１２に記載の方法。
【請求項１１５】
前記クライアント端末への応答メッセージのデジタルデータを前記サーバにより、前記対称暗号化スキームに従って前記第２のハッシュ値を鍵情報として使用して暗号化するステップと、
前記暗号化された応答メッセージのデジタルデータを前記クライアント端末へ供給するステップと、
前記暗号化された応答メッセージのデジタルデータを前記クライアント端末により、前記対称暗号化スキームに従って前記第１のハッシュ値を鍵情報として使用して復号化するステップとをさらに含む、請求項１０５〜１１４のいずれか１項に記載の方法。
【請求項１１６】
前記乱数トークンを取得するステップと、
前記乱数トークンを供給するステップと、
前記第１のハッシュ値を算出するステップと、
前記第１のハッシュ値を供給するステップとが、前記サーバが保有し且つ前記算出するステップに使用される前記一定の乱数値が新しい一定の乱数値に交換される場合に、クライアント端末の前記サーバへの新しい登録プロセスとして実行される、請求項１０６〜１１５のいずれか１項に記載の方法。
【請求項１１７】
前記複数の異なる一定の乱数値が、互いに独立して交換され、前記方法が、前記サーバへ再度登録するために前記複数の一定の乱数値に関連付けられる特定のユーザグループを選択的に要求することを規定する、請求項１１６及び請求項１１２〜１１４のいずれか１項に記載の方法。
【請求項１１８】
前記クライアント端末が前記サーバにとって終始匿名であり、前記サーバが、関連付けられたトークン、関連付けられたハッシュ値又は共有される秘密のうち１つを確立するために、前記クライアント端末に関する、それらの関連付けられたトークン、個々の対称暗号化スキームにおいて鍵情報として使用されるそれらの関連付けられたハッシュ値、前記サーバと前記クライアント端末との間で先に確立された他の共有の秘密又は前記クライアント端末の識別子を含む記録情報を記憶することを要求されない、請求項１０５〜１１７のいずれか１項に記載の方法。
【請求項１１９】
デジタルデータを交換するための安全な通信を供給するためのシステムであって、前記システムが、ネットワークを介して接続される少なくとも１つのサーバと複数のクライアント端末とを備え、前記クライアント端末が、
デジタルデータを、先に取得された第１のハッシュ値を対称暗号化スキームにおける鍵情報として使用して暗号化するための手段と、
前記暗号化デジタルデータ及び先に取得された乱数トークンを前記システムのサーバへ供給するための手段であって、前記第１のハッシュ値が、前記乱数トークンに関連付けられ且つ前記サーバと前記クライアント端末との共有の秘密として機能する、手段とを備え、
前記少なくとも１つのサーバが、
前記供給された乱数トークン及び一定の乱数値の第２のハッシュ値を算出するための手段であって、前記一定の乱数値が、前記サーバが保有していて前記複数のクライアント端末には開示されない非公開の秘密値である、手段と、
前記暗号化されたデジタルデータを前記対称暗号化スキームに従って前記第２のハッシュ値を鍵情報として使用して復号化するための手段とを備える、システム。
【請求項１２０】
前記クライアント端末が、
前記乱数トークンを前記デジタルデータの暗号化に先行して取得するための手段と、
前記乱数トークンを前記デジタルデータの暗号化に先行して前記サーバへ供給するための手段とをさらに備え、
前記少なくとも１つのサーバが、
前記乱数トークン及び前記一定の乱数値の前記第１のハッシュ値を前記デジタルデータの暗号化に先行して算出するための手段と、
前記第１のハッシュ値を前記デジタルデータの暗号化に先行して前記クライアント端末へ供給するための手段とをさらに備える、請求項１１９に記載のシステム。
【請求項１２１】
前記第１のハッシュ値を供給するためのサーバ手段が、前記部分的に生成された乱数トークンを前記クライアント端末へ供給するための手段をさらに備え、前記第１のハッシュ値が前記供給に関連して暗号化され且つ復号化される場合、前記手段が、さらに暗号化されるべき前記乱数トークンを前記第１のハッシュ値と同様にして供給し、
前記サーバが、
前記乱数トークンを部分的に生成するための手段と、
複数の異なる一定の乱数値の特定値を前記第１のハッシュ値の算出に先行して選定するための手段と、
前記複数の異なる一定の乱数値の特定値を前記部分的に生成された乱数トークンに関連付けるための手段と、
前記複数の異なる一定の乱数値の特定値を前記第２のハッシュ値を算出するステップに先行して、前記供給された乱数トークンから前記部分的に生成された乱数トークンを確立し、続いて、その関連付けられた一定の乱数値を識別することにより確立するための手段とをさらに備える、請求項１１９又は１２０に記載のシステム。
【請求項１２２】
前記サーバが、
前記クライアント端末への応答メッセージのデジタルデータを前記対称暗号化スキームに従って前記第２のハッシュ値を鍵情報として使用して暗号化するための手段と、
前記暗号化された応答メッセージのデジタルデータを前記クライアント端末へ供給するための手段とをさらに備え、
前記クライアント端末が、
前記暗号化された応答メッセージのデジタルデータを前記対称暗号化スキームに従って前記第１のハッシュ値を鍵情報として使用して復号化するための手段をさらに含む、請求項１１９〜１２１のいずれか１項に記載のシステム。
【請求項１２３】
請求項１０６〜１１８のいずれか１項に明記された方法を達成するための手段をさらに備える、請求項１１９〜１２２のいずれか１項に記載のシステム。
【請求項１２４】
オペレーションに参加し実行する複数のクライアント端末を、請求項１０５〜１１８のいずれか１項に明記された方法に従って制御するためのコンピュータプログラムを有する、コンピュータ読取り可能な記憶媒体。
【請求項１２５】
オペレーションに参加し実行するサーバを、請求項１０５〜１１８のいずれか１項に明記された方法に従って制御するためのコンピュータプログラムを有する、コンピュータ読取り可能な記憶媒体。
【請求項１２６】
前記乱数トークンをオリジナルの乱数トークンと同様にして使用される新しい乱数トークンと交換するステップをさらに含む、請求項１０５〜１１８のいずれか１項に記載の方法。
【請求項１２７】
前記新しい乱数トークンを前記サーバによって生成するステップと、
前記新しい乱数トークン及び前記一定の乱数値の新しい第１のハッシュ値を前記サーバによって算出するステップと、
前記新しい第１のハッシュ値を前記サーバにより、前記対称暗号化スキームに従って前記第２のハッシュ値を鍵情報として使用して暗号化するステップと、
前記暗号化された新しい第１のハッシュ値を前記サーバの前記クライアント端末への応答メッセージと共に、又は前記応答メッセージに関連して前記クライアント端末へ供給するステップと、
前記暗号化された新しい第１のハッシュ値を前記クライアント端末により前記オリジナルの第１のハッシュ値を使用して復号化するステップと、
前記新しい乱数トークンを前記クライアント端末によって取得するステップと、
前記クライアント端末におけるオリジナルの乱数トークンを前記新しい乱数トークンに交換し、前記オリジナルの第１のハッシュ値を前記クライアント端末における前記新しい第１のハッシュ値に交換するステップであって、前記新しい乱数トークン及び前記新しい第１のハッシュ値が、同様にして使用可能であり、前記個々のオリジナルの乱数トークン及び第１のハッシュ値に関して説明した方法のステップに適用可能である、ステップとをさらに含む、請求項１２６に記載の方法。
【請求項１２８】
前記新しい乱数トークンを前記サーバによって生成するステップが、前記暗号化デジタルデータ及び前記先行して取得された乱数トークンを供給するステップによって供給されたメッセージの所定の部分を使用して前記新しい乱数トークンを生成することを含み、前記所定の部分が、
前記復号化されたデジタルデータの所定の部分、
前記暗号化されたデジタルデータの所定の部分、
少なくとも前記所定の部分又は前記完全な復号化されたデジタルデータに対して実行されたハッシュ値、又は
少なくとも前記所定の部分又は前記完全な暗号化されたデジタルデータに対して実行されたハッシュ値のうち１つ又はそれ以上である、請求項１２７に記載の方法。
【請求項１２９】
前記新しい乱数トークンを前記クライアント端末によって取得するステップが、前記新しい乱数トークンを前記クライアント端末により、同じメッセージの前記所定の部分を前記新しい乱数トークンを生成する第１のステップにおいて前記サーバにより実行される方法と同様に使用して生成するステップを含む、請求項１２８に記載の方法。
【請求項１３０】
前記新しい乱数トークンを前記サーバによって生成するステップが、前記クライアント端末から前記サーバへ供給された任意のメッセージ又はデータとは独立している、請求項１２７に記載の方法。
【請求項１３１】
前記新しい乱数トークンを取得するステップが、前記新しい乱数トークンを前記クライアント端末へ供給するステップを含み、前記新しい乱数トークンが、前記新しい第１のハッシュ値と同様に、又はこれと共に前記供給するステップの前後で暗号化され且つ復号化される、請求項１２７、１２８又は１３０に記載の方法。
【請求項１３２】
前記新しい乱数トークンを前記サーバによって生成するステップが、前記新しい乱数トークンの一部を前記サーバにおいて前記提供されたメッセージとは独立して生成することをさらに含み、前記方法が、
前記複数の異なる一定の乱数値の特定値を前記新しい第１のハッシュ値を算出するステップに先行して選定するステップと、
前記複数の異なる一定の乱数値の特定値を前記生成された新しい乱数トークンの一部に関連付けるステップと、
前記複数の異なる一定の乱数値の特定値を前記第２のハッシュ値を算出するステップに先行して、前記供給された乱数トークンの前記生成された部分を決定し、続いて、その関連付けられた特定の一定の乱数値を識別することにより確立するステップとをさらに含む、請求項１２８又は１２９及び請求項１１２に記載の方法。
【請求項１３３】
前記複数の異なる一定の乱数値の特定値を前記サーバにより前記新しい第１のハッシュ値を算出するステップに先行して選定するステップと、
前記複数の異なる一定の乱数値の特定値を前記サーバにより前記第２のハッシュ値を算出するステップに先行して、前記異なる一定の乱数値の各々をそれが前記暗号化されたデジタルデータを前記サーバにより復号化する次のステップにおいて有効な結果をもたらすかどうか連続して検査することにより確立するステップとをさらに含む、請求項１２８又は１２９及び請求項１１２に記載の方法。
【請求項１３４】
前記確立するステップが、前記複数の異なる一定の乱数値の少なくとも１つを説明する前記連続的な検査の計時されたスケジュールに依存する、請求項１３３に記載の方法。
【請求項１３５】
新しい乱数トークンは、
前記クライアント端末と前記サーバとの間の各通信及びデータ交換トランザクションプロセス、
所定の回数の前記通信及びデータ交換トランザクション、
前記クライアント端末に関連付けられるユーザの要求時、及び
前記サーバの要求時のうち少なくとも１つに関して生成され、暗号化され、供給され、復号化され、交換される、請求項１２６〜１３４のいずれか１項に記載の方法。
【請求項１３６】
前記サーバが、
新しい乱数トークンを生成するための手段と、
前記新しい乱数トークン及び一定の乱数値の新しい第１のハッシュ値を算出するための手段と、
前記新しい第１のハッシュ値を、前記対称暗号化スキームに従って前記第２のハッシュ値を鍵情報として使用して暗号化するための手段とをさらに備え、
前記システムが、
前記暗号化された新しい第１のハッシュ値を前記サーバの前記クライアント端末への応答メッセージと共に、又は前記応答メッセージに関連して前記クライアント端末へ供給するための手段をさらに備え、
前記クライアント端末が、
前記暗号化された新しい第１のハッシュ値を前記オリジナルの第１のハッシュ値を使用して復号化するための手段と、
前記新しい乱数トークンを取得するための手段と、
前記クライアント端末におけるオリジナルの乱数トークンを前記新しい乱数トークンに交換し、前記オリジナルの第１のハッシュ値を前記クライアント端末における前記新しい第１のハッシュ値に交換するための手段であって、前記新しい乱数トークン及び前記新しい第１のハッシュ値が、同様にして使用可能であり、前記個々のオリジナルの乱数トークン及び第１のハッシュ値に関して明記されたシステムの手段に適用可能である、手段とをさらに備える、請求項１１９〜１２３のいずれか１項に記載のシステム。
【請求項１３７】
請求項１２８〜１３５のいずれか１項に明記された方法を達成するための手段をさらに備える、請求項１３６に記載のシステム。
【請求項１３８】
オペレーションに参加し実行する複数のクライアント端末を、請求項１２６〜１３５のいずれか１項に明記された方法に従って制御するためのコンピュータプログラムを有する、コンピュータ読取り可能な記憶媒体。
【請求項１３９】
オペレーションに参加し実行するサーバを、請求項１２６〜１３５のいずれか１項に明記された方法に従って制御するためのコンピュータプログラムを有する、コンピュータ読取り可能な記憶媒体。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、デジタルデータを１つ又は複数のサーバ又はコンテンツプロバイダからネットワークを介して複数のユーザへ配信するために使用される公開鍵インフラを有するシステムに関する。特に、インターネット等の公衆ネットワーク上でのデジタルデータの安全な配信及び提供を本発明によって説明する。
【背景技術】
【０００２】
潜在的に不確かな配信媒体上で安全にデータを配信するための一般的な公開鍵インフラ、及び公開鍵暗号化スキームを使用するシステムにおいて、デジタルデータは各受信者向けに特別に暗号化される。暗号化されて配信されるデータの検証可能な完全性及び真正を提供するためには、認証局（ＣＡ）等の信用のおける第三者によって発行される、又は認証される鍵、特に公開鍵対に依存することを余儀なくされる。この第三者への依存は、データ配信システムの安全性に不利益をもたらす。安全性は対応する秘密鍵の秘密性によって確立されるが、一般に秘密鍵は信用のある第三者又は認証局において周知である。これは、安全なデータ配信システムにとっての単一障害点になる。さらに、信用のある第三者又は認証局によって提供されるサービスは通常未決定の料金及びロイヤルティを含み、これはクライアント又はサービスプロバイダによって支払われなければならない。従って、公衆ネットワークを介して通信する多数の当事者を有するシステムにおいて、一方では安全要件及び算出コストの面で効果的であり且つ他方では第三者に依存しない安全なデータ配信を確立する能力のあるシステムを保有することが望ましい。さらに、データの完全性に関して高レベルの安全性を提供する一般的なデータ配信システムは通常、特に多数の受信者に対応する場合に演算コストが高価である。
【発明の開示】
【発明が解決しようとする課題】
【０００３】
本発明の第１の態様の目的は、加入しているサーバ及びユーザ端末のために演算コスト及び各受信者に供給されるデータ量を効果的に低減すると同時に信用のある第三者とは独立している安全なデータ配信を提供する方法及びシステムを提供することにある。しかしながら、本システムは、信用のある第三者を使用する従来の公開鍵暗号化スキームの使用もサポートすべきである。さらに、特に多数のユーザ及び配信されるデジタルデータに対応する場合に、システム内の様々な種類のデータ又は様々な当事者に多様に対応する上で適応可能であり且つフレキシブルであるようなシステム及び方法を提供する必要もある。
【課題を解決するための手段】
【０００４】
本発明の第１の態様によれば、デジタルデータを、データの検証可能な完全性及び真正を規定する配信されるデジタルデータのフィンガープリントリストを使用し且つこれらのフィンガープリントリスト又はその一部を同様にしてさらなるフィンガープリントを使用するクライアントへ効果的に、且つ低い送信及び演算コストで供給するサーバにより、複数のクライアント端末へ安全に提供するための方法及びシステムが開示されている。
【０００５】
本発明の他の態様はデジタルデータの配信に関し、同時に、配信されたデジタルデータの受信者側に記憶された後のアクセスを制御する効果的且つ実装が容易な概念を提供することに関する。通常、公衆ネットワークを介して提供されるデジタルデータ及び／又はシステム内の多数の当事者によってアクセス可能なデジタルデータは、データを非対称的に暗号化することによりシステム内の幾人かのユーザへ安全且つ秘密裏に配信されなければならないだけでなく、秘密性はデータが受信者側で受信された後も少なくとも所定の時間に渡って保証されなければならない。一般的なデータ配信システムでは、これは、先行して安全に配信されたデータを必要に応じて前記所定の時間の経過後に、例えば上記デジタルデータのプロバイダの制御又は強制により削除することによって達成されるしかない。現時点では、この問題点は安全且つ秘密裏のデータ配信プロセスによって独立的に解決されている。特にこれは、受信された全てのデータ及びその全ての可能なコピーを物理的に削除することによって達成される。従って、安全なデータ配信と、暗号化されたデータへ異なる時間に選択的に且つ／又は異なるユーザが選択的にアクセスするための効果的且つ実装が容易な制御方法とを組み合わせることができるシステム及び方法を設計することが望ましい。従って、安全なデータ配信プロセスのために使用される公開鍵暗号化スキーム及び／又は公開鍵署名スキームにおいて使用される公開鍵又は秘密鍵を自動的に取り消す、又は削除するための方法が開示されている。
【０００６】
本発明のさらなる態様は、配信されるデジタルデータを纏めて、又は逐次的に暗号化し且つ復号化する、又は署名し且つ検証する幾つかの当事者を規定する公開鍵システムにおける安全なデータ配信に関する。非対称暗号化スキームでは、対称鍵だけが非対称的に暗号化され、データ自体は対称鍵を使用して対称的に暗号化される。例えばシステム内の異なる当事者に対応するこのデータに異なる暗号化層を適用する場合には、データ全体をもう一度暗号化し、且つ当然ながら復号化しなければならない。これは、データ配信プロセスに伴う高い演算コストを意味する。暗号化スキームの類似の基本的プロセスはデジタル署名にも適用されることから、異なるエンティティ又は当事者が署名してデジタルデータを検証しなければならないデジタル署名スキームにも同じ欠点が作用する。従って、演算コストに関して容易で効果的な層状の暗号化及び／又は層状のデジタル署名機能を提供する方法及びシステムを提示することが望ましい。よって本発明は、データ配信システム内の効果的でさほど複雑でない層状の暗号化及び層状のデジタル署名を提供する方法について説明する。
【０００７】
本発明によるデジタルデータ配信システムのさらに他の態様は、公衆ネットワークを介して配信されるデジタルデータの経路の仕様に関する。安全なデジタルデータ配信のシステム及び方法は、デジタルデータがその最終受信者へ至る途中で通過しなければならないネットワークノードに関してデータ配信経路を特定し且つ制御する可能性を提供することが望ましい。この主題は、特に複雑さ、最小送信オーバーヘッド及び演算コストの面で先行技術により十分に対処されていない。従って本発明は、各々非対称暗号化スキーム及び／又はデジタル署名スキームを使用してこの問題に対処する方法ステップを含む方法について説明する。
【０００８】
典型的には、公開鍵インフラを使用する非対称暗号化は、デジタルデータの対称暗号化を使用する一方で対称鍵情報を非対称的に暗号化する。この対称鍵情報は、配信されるデジタルデータの送信者及び受信者が共有する秘密である。通常、この共有される秘密は、共有される秘密の確立プロセスに直接関わる、もしくはこのプロセスに沿って情報の認証を余儀なくされる信用のある第三者を必要とする形で確立又は供給される。信用のある第三者へのこの依存は、既に指摘したようにこれらのシステムの欠点である。従って、データ配信システムには、システムの２当事者間で対称鍵情報として機能することができる共有の秘密を確立するためのさほど複雑でなく効果的な可能性を包含することが望ましい。さらに、多数のユーザを有する通常のシステムの場合、サーバは加入している全てのユーザ及びそれらが共有する個々の秘密の記録を記憶し且つ保持しなければならない。これは特に、記憶装置の複雑さ、演算コスト及び演算時間の点からサーバにとって不利になる。従って、サーバが個々の加入ユーザについてこれらの共有の秘密を記憶、更新又は再入手する必要なしに複数のユーザ端末に共有される秘密をサーバによって確立するケイパビリティを提供する安全なデータ配信のシステム及び方法を保有することが望ましい。従って本発明は、ランダムに発生されるトークンに基づいて算出されるハッシュ値を使用して、サーバにより各ユーザに関する共有の秘密を記憶する必要なしに対称鍵情報として機能することができるサーバ及びクライアント端末間で共有される秘密を確立する方法及びシステムについて説明する。
【０００９】
本発明の目的は、上述の効果的な態様及び機能を達成し且つこれらを見込んだシステム及び方法並びにこのようなシステムの複数のユーザ端末及びサーバを適宜制御するコンピュータプログラムを提供することにある。この目的は、独立請求項の主題によって解決される。好適な実施形態は、従属請求項の主題によって定義される。
【発明を実施するための最良の形態】
【００１０】
以下、図面を参照して本発明を説明する。
添付の図面及び／又は各主題における幾つかの実施形態を参照して、本発明を、安全対策を講じたデータ配信システムの幾つかの態様に関連して説明する。本主題をより深く理解するために、最も明確な異なる態様及びそれらの実施形態について概説するが、これらに本発明の範囲を限定する意図はない。実際、説明する態様及び実施形態は、本発明の教示内容を逸脱することなく組み合わされることが可能である。当業者は、本発明の特定の態様に限定されることなく全ての実施形態により技術的に意味のある任意の組み合わせを行ない得ることを認識する。
【００１１】
以下、デジタルデータの配信のための、及び特に公開鍵システムにおいて使用される個々の公開鍵の配信のためのフィンガープリントとして使用されるハッシュ値に関連して本発明の第１の態様を説明する。
【００１２】
以下のシナリオ及び手段は、網羅的ではなく例示的であることが意図されている。特に、以下の本発明の態様は公開鍵に限定されず、プログラムファイル、データファイル、構成ファイル、ソフトウェアコード、これらの新規バージョン又は更新もしくは組み合わせ等の任意の種類のデジタルデータに適用されることは留意されるべきである。現時点での好適な実施形態は主としてこのシステムを使用し、特定の一種類のデータを選択することにより公開鍵を配信し且つ最大の理解度をもたらすことから、以下の説明の大部分はもっぱら安全に配信されるべきデジタルデータとしての公開鍵を参照する。
【００１３】
本発明の第１の態様による例示的な公開鍵システムを、図１に示す。本システムは、第１及び第２の認証局サーバ１１及び１３と、ハッシュ値サーバ１２と、クライアント端末１４〜１７とを備える。サーバ１１〜１３及びクライアント１４〜１７は、インターネット等の公衆ネットワークに接続される。認証局サーバ１１及び１３は、公開鍵インフラを有する公開鍵システムにおける１つ又は複数のこのような認証局の共同使用に対して責任を負う。本発明によれば、認証局のシステム内での使用はサポートされているが、続いて説明するように公開鍵等のデジタルデータの安全な供給を確立するために必要なものではない。さらに、ハッシュ値サーバ又は認証局は、例えばクライアント端末１４〜１７又はそのサブセットにより形成される配信されるピア・ツー・ピアシステムによってエミュレートされる方がよい。関連付けられた公開鍵ＰＫ１〜ＰＫ４は、クライアント端末１４〜１７の各々について、又はクライアント端末１４〜１７の対応するユーザについて存在する。
【００１４】
概して、クライアント端末１４〜１７、即ち個々のユーザのためのクライアント端末１４〜１７及びサーバ１１〜１３は、公衆ネットワークを介して互いに通信する。図１には示されていないが、好適にはサーバ１１〜１３の各々の間である直接接続は、必要に応じてインターネットよりも安全な通信経路を供給することが可能である。
【００１５】
一定レベルの検証可能なデータの完全性及びユーザ認証をもたらす公開鍵システム内で一般的に使用されている２つの端末間で安全な通信を実行するシナリオは、次のように要約することができる。公開鍵ＰＫ１の所有者（即ちクライアント）により要求されると、例えばＣＡ１  １１である認証局はまずクライアント端末１４の公開鍵ＰＫ１に関する認証を発行し、これによりＰＫ１が本物であってクライアント端末１４又はその個々のユーザに関連付けられるものであることを認証する。この認証ｃｅｒｔ＿ＣＡ１（ＰＫ１）は公的に入手可能であり、もしくはシステム内の残りのクライアント端末１５〜１７に供給される。クライアント端末１４は次に、これらの端末によりＰＫ１で暗号化されているデータを受け取ることができる。しかしながら、公開鍵ＰＫ１のこのような認証は、ＣＡ１がこのような通信を実行する全ての端末によって信頼されていなければならない信用のある第三者であることを想定している。さらに、ＣＡ１のＰＫもルートＣＡへの認証チェーンによって認証されなければならない。概して、認証局の概念は、周知の公開情報を使用して検証され得るが認証局自体にしか知られていない私的情報を使用して発行されなければならない、偽造できない認証を基礎としている。これは、もう一つの帰結を提示する。即ち認証局が信用されていなければならないだけでなく、認証プロセスも置換から防護されなければならない。言い替えれば、認証を検証するための情報、即ちＣＡ１の公開鍵が敵対者によって差し替えられ得ないことが保証されなければならない。
【００１６】
ハッシュ値サーバ１２は、公開鍵のハッシュ値のリストを記憶する。現時点での好適な実施形態によれば、これらの公開鍵は、認証局１１又は１３の少なくとも一方により追加的に署名される。公開鍵ＰＫ１のハッシュ値は、ハッシュ値サーバ１２のハッシュ値リスト内に記憶される。図５を参照して後に詳述するように、ハッシュ値サーバ１２は記憶されたハッシュ値リストのハッシュ値を算出し、算出されたハッシュ値及びハッシュ値リストを全ての端末が公的に入手できるように供給する。以下、ハッシュ値リストのハッシュ値をメタハッシュ値とも称する。
【００１７】
ハッシュ値サーバ１２に記憶された情報は、公共アクセス用に提供される場合もあれば、少なくともシステムの専用クライアント端末がアクセスできるようにされる場合もある。特に情報の提供は、それを要求に応じて、もしくは自動的に所定のクライアント端末リストへ転送することをも含んでいる。ハッシュ値リスト及びメタハッシュ値がクライアント端末へ提供され且つ配信される方法の異なる実施形態については、次の一般概念の説明に続いて論じる。
【００１８】
本発明の一実施形態において、クライアント端末１５は、ハッシュ値サーバ１２からハッシュ値リスト及びそのメタハッシュ値を受信する。受信されたメタハッシュ値を基礎として、クライアント端末１５は、公開鍵ＰＫ１を使用してデータを検証、認証又は暗号化する前にクライアント端末１４の公開鍵ＰＫ１の認証又は検証プロセスを実行する。さらにクライアント端末１５は、ハッシュ値リストに含まれるその固有の公開鍵ＰＫ２の真正についてもチェックすることが可能である。クライアント端末における対応プロセスについては、図６及び図７を参照して後に詳述する。
【００１９】
図１のハッシュ値サーバ１２は、認証局サーバ１１及び１３の一部として、安全に配信されるデジタルデータを記憶する、又は管理するネットワーク内の他のサーバの一部として、もしくはクライアント端末のピア・ツー・ピアシステムによって実装されることが可能である。使用されるハッシュアルゴリズムは、例えばＳＨＡ１又はＭＤ５であることが可能である。
【００２０】
図２は、図１のハッシュ値サーバの機能ユニットを示す。
典型的なハッシュ値サーバは、ＣＰＵ２１と、インターネットに接続されるネットワークインタフェースユニット２２と、オペレータと対話するためのオペレータＩ／Ｏユニット２３と、記憶手段２４と、さらなる記憶手段２５、２６とを備える。
【００２１】
オペレータＩ／Ｏユニット２３は、特に、モニタと、マウスと、キーボードとを備える。さらにネットワークインタフェースユニット２２は、サーバがクライアント端末からの情報要求を受信し、記憶された情報を送信する、又は入力情報を受信することを許容する。入力情報は、例えば、ハッシュ値リストに追加される例えば公開鍵であるさらなるデータに関して認証局サーバから受信されることが可能である。特にこの点に関しては、図示されていない直接的なインタフェースユニットがＣＡサーバの少なくとも１つへ安全な直接接続を供給することが可能である。
【００２２】
記憶手段２４は、ＲＡＭ、ＥＥＰＲＯＭ、ＲＯＭ、ハードディスク、磁気ディスク装置及び／又は光ディスク装置によって形成されることが可能である。記憶手段２４には、サーバの動作システム及び要求されたオペレーションを実行するアプリケーションソフトウェアが記憶される。
【００２３】
この例において、さらなる記憶手段２５、２６は、ハッシュ値を記憶するための第１の記憶ユニット２５と、公開鍵及びその認証を記憶するための第２の記憶ユニット２６とによって形成される。概して、記憶手段２６は、例えば安全に配信されるデータの１つ又は複数のリストに区切られた任意のデータを保持することが可能である。記憶ユニット２５は、記憶ユニット２６に記憶された公開鍵又はデータのハッシュ値リスト及びハッシュ値リストのメタハッシュ値を保持する。この記憶ユニット２５はさらに、その時点で公的に供給されているハッシュ値リストから分離して記憶される、受信されるハッシュ値の一時的なリストを記憶することが可能である。
【００２４】
図３は、ハッシュ値サーバに記憶される公開鍵（ＰＫ１〜ＰＫ４）のハッシュ値の例示的なリスト３２を示す。公開鍵に関連付けられる、よってそのハッシュ値にも関連付けられる固有の識別子は、相応してカラム３１に記憶される。固有の識別子は、好適には公開鍵ＰＫ１〜ＰＫ４の個々の所有者のｅメールアドレスにより形成される。ハッシュ値リスト３２はさらに、認証局ＣＡ２のハッシュ値リストのメタハッシュ値を記憶する。本リストはさらに、認証局ＣＡ２の公開鍵のハッシュ値を含むことが可能である。
【００２５】
最後に、ハッシュ値リスト３２の、又は好適にはハッシュ値リスト３２及び関連付けられるｅメールアドレス３１のメタハッシュ値が算出される。
図４は、この例の場合は公開鍵／認証対であるデータを図２の記憶ユニット２６に記憶され得る状態で示す。
【００２６】
カラム４１は、ユーザの固有の識別子としてのユーザＩＤを含む。ユーザＩＤは、例えば図３のｅメールアドレスに替わる、又は対応し得るものであり、又はさらなる参照テーブルにおいてそこにマップされることも可能である。この固有の識別子４１はまた、社会保障番号又は他の任意の識別番号であることが可能である。好適には、ハッシュ値サーバ又は認証局は、固有の識別子の各々には必ず唯一の有効な公開鍵が存在することを保証する。この固有の情報は、上記公開鍵を使用して暗号化されるメッセージの送信者が公開鍵の所有者を識別できるようにすることも可能である。カラム４２は、カラム４１で識別されているユーザの公開鍵のリストを含む。カラム４３は、関連付けられる公開鍵の認証リストを含み、上記認証は認証局ＣＡ１又はＣＡ２の一方によって発行されている。リスト４１〜４３における各エントリは、図３のハッシュ値リストにおける１つのエントリに対応する。
【００２７】
ユーザ１〜４の公開鍵ＰＫ１〜ＰＫ４の他に、図４のテーブルの最後の項目は、認証局ＣＡ２の公開鍵ＰＫ＿ＣＡ２を含んでいる。対応する認証ＣＡ１＿ｃｅｒｔ（ＰＫ＿ＣＡ２）は、認証局ＣＡ１によって発行される。
【００２８】
また、図３及び図４に示したテーブルはさらに、ハッシュ値又は対応する認証が取り消されているかどうかを表示する取消し情報、又はハッシュ値が更新された日付け又は時間を表示する更新情報等の図示されていないデータフィールドを含む。
【００２９】
次に、本発明のこの第１の態様の一実施形態による図５を参照して、ハッシュ値サーバにおけるハッシュ値リストの管理プロセスについて説明する。説明する本プロセスは、公開鍵リストをシステムのクライアント端末に転送され且つ同クライアント端末によって認証されるべきデータと称する。本シナリオ及び以下の全シナリオは、網羅的でなく例示的であることが意図されている。特に、本発明は公開鍵に限定されず、プログラムファイル、デジタルファイル、構成ファイル又はこれらの組み合わせ等の任意の種類のデジタルデータに適用されることに留意すべきである。
【００３０】
まずステップ５２において、認証局ＣＡによって署名されることが可能な公開鍵ＰＫが受信される。例えばこのＰＫは、ＣＡによって発行される認証の一部であることが可能である。
【００３１】
ステップ５３では、公開鍵のハッシュ値が算出される。
続いて、任意選択であるステップ５４では、公開鍵が実際に認証局によって署名され且つ／又は認証局から受信されていることを検証するために認証局ＣＡの署名がチェックされる可能性がある。このような検証ステップは、採用されている公開鍵署名又は認証プロセスに従ってＣＡの公開鍵を既存の受信されたＣＡの署名に当てはめることにより達成される。署名を検証し得ない場合には、プロセスは終了される。
【００３２】
ステップ５５では、算出されたハッシュ値が、ハッシュ値サーバ内に記憶されているハッシュ値リストへ追加される。ステップ５６では、ハッシュ値の補足リスト用にメタハッシュ値が算出される。ハッシュ値リストは、ステップ５７でハッシュ値サーバにより署名されることが可能である。最後に、ステップ５８において、ハッシュ値リスト、そのメタハッシュ値及び任意選択としてハッシュ値リストの署名が提供される。
【００３３】
提供するステップ５８は、例えば情報をハッシュ値サーバに記憶し、これを要求に応じて送信し、本情報を予め定義された宛先リストへ転送する、又は１つ又は複数の予め定義された公開手段へ転送することにより実施される可能性がある。
【００３４】
好適には、追加するステップ５５では、算出されたハッシュ値はまず、その時点で公開されているハッシュ値のリストとは別個に記憶される一時的なハッシュ値リストに追加される。さらに、ステップ５６〜５８を実行するための時間間隔が、例えば毎日、毎週又は毎月に限って定義されることが可能である。故に、所定の時間間隔内に受信される新しいハッシュ値は、その時間間隔の満了後に公開リストに追加されるように一時的なリストへ中間的に記憶される。さらに、メタハッシュ値の関連性に関する情報を与えるために、メタハッシュ値を算出した時間又は日付けがメタハッシュ値と併せて記憶され、提供されることが可能である。
【００３５】
さらに、公開鍵システムの要件に従って、ハッシュサーバにおいて割り当てられた、又はこれらのサーバの少なくとも１つによって承認された公開鍵所有者のｅメールアドレス等の固有の識別子も、ＣＡから受信されることが可能である。
【００３６】
図６及び図７は、本発明のこの第１の態様の一実施形態による、クライアント端末において実行される認証プロセスを示す。図５の場合のように、図６及び図７の基底を成す認証プロセスは公開鍵に関して示されているが、デジタルデータ一般に当てはまる。
【００３７】
図６のプロセス６０〜６８では、ハッシュ値リスト及びそのメタハッシュ値がまずステップ６１において第１のハッシュ値サーバから受信される。その後、ハッシュ値サーバのハッシュ値リストの第２のメタ値がステップ６２において第２のハッシュ値サーバから受信される。最後に、受信されたメタハッシュ値を比較するステップ６３において、両方のメタハッシュ値が互いに対応するものであるかどうかが決定される。
【００３８】
さらに、ステップ６１及び６２の各々は追加的に、メタハッシュ値の対応するハッシュ値サーバによって発行された署名を検証するステップ、及び／又は受信された情報が例えば相互認証プロセスから導出された鍵によって暗号化されていればその受信された情報を復号化するステップを含むことが可能である。下記でさらに明らかになるであろうが、例えばステップ６４及び６５、又はステップ６６及び６７である様々なサブプロセスは、公開鍵の認証プロセスにおいて、要求されるセキュリティレベルを変更するために任意選択で一般ステップ６１〜６３と組み合わされることが可能である。
【００３９】
プロセス６０〜７４は、比較、検証又は認証の任意のステップにおいて結果的に後続の通信には使用されるべきでない偽の鍵である可能性が指示されれば終了されることが可能である。例えば、ステップ６３の比較結果が偏位したハッシュ値を示せば、ハッシュ値リストを信用のおけるリストであるとすることはできない。しかしながら、このような単一の否定的な認証結果の後も、プロセスが終了される必要はなく、代替又は追加的なサブプロセスによって問題の公開鍵の認証を継続する方がよい。特に、受信及び比較ステップ６１及び６３、又は６２及び６３は、データを入手するために例えばさらに他のソースを使用して反復されることが可能である。この場合も又はッシュ値サーバは認証局サーバ又はこれをエミュレートするクライアントのピア・ツー・ピアシステムによって形成される方がよいことが知られている。
【００４０】
さらに、１つのハッシュ値リストに関して入手される、互いに比較されるメタハッシュ値の数は、図６に示したこの例示的なプロセスが指示するような初めの２つに限定されない。実際に、理想的な独立ソースから入手されるメタハッシュ値が多いほど、ハッシュ値リストが真正であるレベル信頼度は高くなり、よって比較が成功であるとすればカバーされたデータの完全性が与えられる。従って、他の実施形態では、所定のセキュリティ又は信頼レベルを確立するために、１つのハッシュ値リストに関して異なるソースから所定数のメタハッシュ値が必要とされる可能性がある。この要求されるレベルは、データの種類が異なれば変わる可能性があり、例えば公開鍵の場合はミュージックファイル等のさほど機密的でない情報を含むファイルの場合より高い可能性がある。またこれは、ユーザの命令又はコンテンツプロバイダ又はディストリビュータが設定する要件に基づいて変わる可能性がある。
【００４１】
比較ステップ６３の後は、ハッシュ値サーバから受信されたハッシュ値リストを基礎としてクライアント端末によりメタハッシュ値が算出される６４。算出されたメタハッシュ値は、ステップ６５において、受信されたメタハッシュ値の１つと比較される。
【００４２】
さらにステップ６６では、ハッシュ値リストに包含されている特定の公開鍵ＰＫについてハッシュ値が算出される。好適には、このステップ６６及びこれに続くステップ７６は、クライアント端末によって認証されるべき少なくとも所望される公開鍵に関して実行される。算出されたハッシュ値Ｈ（ＰＫ）を基礎として、受信されたハッシュ値リストに記憶された対応するハッシュ値は比較によって検証され得る６７。このような整合を検証することができれば、公開鍵とハッシュ値リストとの整合性が確立される。従って、メタハッシュ値を使用してハッシュ値リストの完全性及び真正を検証すれば、次に詳述するように、そこに包含される公開鍵の完全性を認証することができる。
【００４３】
図６に示すプロセスは、認証プロセスのさらに３つのサブプロセスを含む図７のステップ７１〜７４へ続く。
ハッシュ値を検証するためにユーザ入力を受信する任意選択のステップ７１は、ユーザによりｅメールを介して受信されるハッシュ値等、自動的に処理され得ないケース用に供給されている。受信するステップ７１は、ユーザ入力を要求することと、これを受信することと、公開鍵の算出されたハッシュ値との対応を評価することを含む可能性がある。同様のプロセスを、ハッシュ値リストのメタハッシュ値に関して実行することができる。
【００４４】
さらに、ステップ７２では、問題の公開鍵の認証を検証することが可能である。最後に、第三者又は公開鍵の所有者とされている者が実際に公開鍵に対応する秘密鍵を保持しているかどうかをチェックするために、典型的にはクライアント端末によりランダムチャレンジとして供給されるランダムデータに添付される秘密鍵の署名がさらなる任意選択のステップ７３において検証される。概してステップ７３は、鍵対の所有者とされる者の公開鍵に対応する秘密鍵の所有を検証するために、任意の利用可能な知識のゼロ知識証明法を達成することが可能である。
【００４５】
現時点での好適な実施形態によれば、ハッシュ値リスト及びその個々のメタハッシュ値のコンパイル、算出及び配信は下記のように実行される。
先述のプロセスで説明したように、ハッシュ値は、データの物理又は仮想リスト内のあらゆるエントリについて算出される。例えばハッシュ値は、各公開鍵について、又は適用可能であれば各公開鍵並びにその個々の認証について算出される。各々が少なくとも１つの固有の識別子に関連付けられるこれらのハッシュ値は、ハッシュ値リストを形成する。メタハッシュ値は、この完全なハッシュ値リストから算出される。従って、その時までに蓄積されたデータの継続リストに対して有効な新規メタハッシュ値が効力を有するたびに、完全なハッシュ値リストも上述の認証プロセス用の端末によって取得されなければならない。これは、例えば毎日、毎週又は毎月ベースで要求される可能性がある。
【００４６】
このハッシュ値リストは極めて大きいものである可能性があるが、クライアント端末（又は関連のユーザ）は例えば特定の公開鍵であるこのリストの単一の、又は数個のエントリを認証したいだけである可能性があることから、特定のデータエントリを認証する必要がある度にハッシュ値リスト全体を配信しなくてもよいことが望ましい。
【００４７】
従って、この件に関する好適な実施形態は、補助的なハッシュ値及びその個々のリストの使用を規定している。これについては引き続き、図８に示す例示的な図を参照してさらに詳しく説明する。
【００４８】
図８を参照すると、リスト８００はクライアント端末間で安全に配信されるべきデジタルデータ８０１を含む。このデジタルデータ８００は、例えば公開鍵４２又は図４に示すような個々の認証４３を伴う公開鍵４２に対応する、又はこれらを表す。リスト８００における各データエントリは、図３及び図４のカラム３１及びカラム４１に類似する固有の識別子８０２を有する。リスト８００はさらに、図３におけるハッシュ値３２に対応して、各データエントリ８０３について算出されたハッシュ値８０４を含む。
【００４９】
さらに、第２の識別子８０１はリスト８００内の各エントリに関連付けられ、好適にはそのデータがいつリストされたかがリストの継続に伴って昇順で特定される。以下、カラム８０１を関連データのエントリ時間と称する。この時間は、個々のハッシュ値８０４の算出時間がデータのエントリ時間とは異なる場合、上記算出時間にも対応する可能性があることは留意されるべきである。さらに、唯一の固有の識別子が、各データエントリについてカラム８０１における関連の時間及び固有のデータ識別子８０２の双方に取って替わる可能性がある。他のシナリオは、図３及び図４に示したリストの一方を使用してタイミング仕様を個々のエントリが好適にはポインタを介して互いにリンクされるさらなるリストに供給するというものである。しかしながら、このような識別子８０１を使用せず、代わりに異なる補助ハッシュ値８１２をテーブル８００内のその対応するセグメントにリンクするという同じ機能性を供給する他の方法又は手段を使用して、次に説明する概念を実現することもまた可能である。
【００５０】
リスト８００内のエントリは、連続するセグメントに分割される。好適には、これらのセグメントは厳密な意味で連続的であり、非重複的である。但し、これらは重複する可能性もあり、インタリーブされる場合すらある。現時点で好適な実施形態は、これらのセグメントを時間指定されたスケジュールに従って分割する。当然ながらリスト８００には、経時的に、例えばネットワーク又は新たにリリースされたソフトウェアプロダクトに加入するおそらくは新規クライアント及び／又はユーザに対して発行される公開鍵である新たなデータエントリが追加される。これらのエントリは蓄積され、次に必要であればハッシュ値８０４が算出される。例えば毎時間、毎日又は毎週といった所定の時間期間後の所定の時間に、他のセグメントにまだ包含されていない最新のエントリは全て、次のセグメントを形成する。図８に示すように、時間Ｔ１５０及びＴ２００で１つのセグメントが完成されている。その結果、時間Ｔ１５０以降予定された時間Ｔ２００までに加えられた全てのエントリ、即ちデータエントリＤ１０１〜Ｄ１５０が１つのセグメントを形成する。他のシナリオは、データエントリの数によってリスト８００を区分し、よってリストに入力されるデータに関して等しい時間スパンではなく等しいエントリ数でセグメントを形成するというものである。さらに他のシナリオは、異なる種類のデータに、又はユーザのｅメールアドレス等の異なる種類のデータ識別子に異なるセグメントを使用する。後者のシナリオは、リストへのエントリ時間によってスケジュールされるだけではない１つのセグメンテーション手順を表す。
【００５１】
リスト８００の各セグメントは、補助ハッシュ値の算出に使用される。これは、各セグメントを別個のリストと呼ぶ場合の図３及び図４に示すリストに関するメタハッシュ値の生成に類似する。メタハッシュ値と同様に、補助ハッシュ値に関して識別されるハッシュアルゴリズムは、もっぱら考慮対象データに適用される場合もあれば、上記データ及び各リストの行における残りのリストエントリに適用される場合もある。補助ハッシュ値の本ケースでは、ハッシュアルゴリズムを個々のセグメントにおける全てのハッシュ値８０４に適用することが可能であり、もしくは好適にはそのセグメントにおける全てのハッシュ値８０４及び個々のデータ８０３、データＩＤ８０２及び時間８０１に、又はその任意のサブセット又は所定の組み合わせに適用することが可能である。リスト８００の各セグメントに関する補助ハッシュ値８１２は、さらに各補助ハッシュ値についてハッシュ識別子８１１を含む他のリスト８１０におけるエントリである。このリスト８１０は、例えばリスト８００に包含される場合には、他のリスト又は「仮想リスト」として補助ハッシュ値エントリを識別するフラグ等の追加的なインジケータと共に記憶されることが可能である。
【００５２】
識別子８１１は、好適にはリスト８００の各関連セグメントにおける時間、及び特に最終の時間を表示する。例えば図８に示した第３のセグメントは、時間スパンＴ１５１〜Ｔ２００における全てのエントリを含んでいる。セグメント同士は排他的に隣接していることから、リスト８００内に最終エントリを含む１時間毎に完成する個々のセグメント等のスケジュールされたセグメンテーション手法を使用する場合、各セグメント内の最終時間は各セグメントを明確に識別する。従って、現時点で好適な実施形態は、この最終時間をハッシュＩＤ８１１として使用する。しかしながら他の実施形態では、補助ハッシュ値８１２から個々のセグメントへのこのマッピングは、他の任意の利用可能な明確なリンク方法、手段又は概念によって確立されることが可能である。但し、補助ハッシュ値が算出されて記憶されると、下記で明らかとなるように、双方向に明確であるために必ずしもこのマッピングは必要とされないことに留意する。
【００５３】
これで、リスト８１０内のエントリが他のリスト８２０に示すメタハッシュ８２１の算出に使用される。このリストもやはり、例えばリスト８００又は８１０である他の任意のリストに包含されることも可能である。メタハッシュ値は、最新のものを配信又は公開して古いものを削除することも可能であり、よって図８のリスト８２２が指示するようにメタハッシュ値は記憶されない。このメタハッシュ値は、図３〜図５を参照して既に先で述べたように算出される。明らかに、リスト８１０は図３に示したリストのように処理されることが可能であり、各補助ハッシュ値８１２はカラム３２におけるハッシュ値に対応し、ハッシュＩＤ８１１はカラム３１に対応している。既に先で述べた認証プロセスの場合のように、メタハッシュ値は配信されて例えばその算出時間を特定するハッシュＩＤ８２２であるタイミング又は妥当性情報に関連付けられ、必要に応じて受信されたメタハッシュ値及び対応するハッシュ値リストが依然として有効であるかどうか、又は既に最新バージョンが存在するかどうかが示される。原則的には、双方が互いに対応するものとして識別可能である限り、この情報はメタハッシュ値又は対応するハッシュ値リストＨＶＬの一方についてのみ要求される。
【００５４】
現時点で好適な実施形態によれば、メタハッシュ値８２１は、メタハッシュ値によってカバーされる最新の補助ハッシュ値８１２と共に算出される。図８に示す例を参照すると、メタハッシュ値ｍｈ１は、その個々のハッシュＩＤ８２２によって指示される通り時間Ｔ１５０で算出される。この時間識別子は、最近にカバーされた個々の補助ハッシュ値ａｈ２のハッシュＩＤ８１１と同一である。他の実施形態は、独立スケジュールを適用して完全にカバーされたセグメントに関しては一致しないハッシュ値８１２及び８２１を算出することが可能である。図８に示すように、メタハッシュ値ｍｈ２は時間Ｔ２２２で算出されるが、最近にカバーされた補助ハッシュ値ａｈ３はリスト８００における時間Ｔ２００までのデータエントリをカバーする。このシナリオは、現時点で好適な実施形態とは対照的に、メタハッシュ値（即ちｍｈ２）がそのメタハッシュ値が算出された時点（即ちＴ２２２）でリストに加えられている全てのデータ８０３（即ちＤ２０１〜Ｄ２２２）をカバーしない可能性のあるケースを示す。
【００５５】
現時点で好適な実施形態による認証プロセスは、上述の認証プロセスとは下記の点で異なる。ステップ６１〜６５は、図６を参照して説明したように適用可能である。これらのステップは、現行で考慮されている同一のハッシュ値リストに関する各々ステップ６１及び６２において異なるソースから取得された少なくとも２つのメタハッシュ値を比較するステップ６３を含んでいる。さらにステップ６５において、これらのメタハッシュ値は、この実施形態ではリスト８１０内に存在する個々のハッシュ値リストからクライアント端末によって算出されるローカルメタハッシュ値と比較される。このハッシュ値リストに関して考慮された全てのメタハッシュ値が同じであることが検証されれば、取得されたメタハッシュ値の異なる且つ完全な独立ソースのダイバーシティを基礎として、このハッシュ値リストの真正及び完全性を確立することができる。メタハッシュ値８２１は、次に補助ハッシュ値８１２から算出される。従って、クライアント端末によって認証されるべき例えば公開鍵ＰＫであるデータ８０３は、ステップ６１で受信されるような補助ハッシュ値リスト８１０内のどのハッシュ値にも直接一致しない。従って、ステップ６６及び後続ステップへ進む前に、下記のステップが実行されなければならない。
【００５６】
最大の理解度をもたらすことだけを目的として、以下のセクションではもっぱら公開鍵について言及する。これらの公開鍵は、１つの特定的な使用事例としてのデジタルデータ８０３を表す。さらに、このプロセスのより一般的な実施形態を示す図６及び図７もまた、公開鍵が認証されるべきデジタルデータを象徴しているこの特定の使用事例を参照している。
【００５７】
認証プロセスに関する第１の実施形態によれば、クライアント端末は、認証されなければならない現行で考慮されている公開鍵８０３にどの補助ハッシュ値８１２が対応するか、及びこの補助ハッシュ値８１２にリスト８００のどのセグメントが対応するかを確立する。従ってクライアント端末は、どのセグメントが上記公開鍵を含むかを確立する。クライアント端末は次に、この識別されたリスト８００のセグメントを少なくとも１つの所定のサーバから、好適には同じくハッシュ値リストを供給する同じハッシュ値サーバから要求する。本発明の場合、これらの確立するステップ及び要求するステップを達成するために異なる手法が適用可能であり且つ考慮される。可能性のある１つの手法は、各公開鍵をクライアント端末等の検証者が確立することのできる時間情報に関連付けるというものである。この時間情報は、現時点で好適な実施形態によって使用されるような対応するリスト８００内のセグメントを明確に特定する。しかしながら、異なる手法は時間指定されたセグメント（のみ）を使用することはできない、もしくは時間識別子８００、８１１及び／又は８２２を使用することはできない。他の手法は、例えば個々のセグメントを直接特定する、又は指示する各鍵に関連付けられる識別子を供給することが可能である。さらなる手法では、ハッシュＩＤ８１１は包含される全ての公開鍵８０３の識別を規定する情報を含むことが可能である。このようにしてクライアントは上記公開鍵の個々の補助ハッシュ値８１２を識別することが可能であり、補助ハッシュ値８１２は所望されるリスト８００のセグメントを特定して戻す。
【００５８】
現行で考慮されている公開鍵に対応するリスト８００のセグメントを取得する問題に関する第２の実施形態は、次のようなものである。クライアント端末は、公開鍵を送信し、指摘し又は特定することによりサーバにおいて、好適には上記第１のハッシュ値サーバにおいて必要とされるセグメントを要求する。するとこのサーバは対応するセグメントを確定し、次にはこのセグメントを要求側のクライアント端末へ直接提供することが可能であり、もしくは少なくともクライアント端末が要求されたセグメントを取得できるようにする情報を提供することが可能である。第１の実施形態との組み合わせも可能であり、例えば公開鍵８０３の個々の補助ハッシュ値８１２を決定するクライアントと、この補助ハッシュ値８１２の個々のセグメントを決定するサーバとの組み合わせが可能である。
【００５９】
この必要とされるセグメントの要求に関する第３の実施形態によれば、先に説明した両実施形態の何れか一方によって取得されたセグメントは、例えばハッシュ値サーバによってさらに暗号化され且つ／又は認証されることが可能である。これは、このセグメントを受信した後にクライアント端末によって実行される復号化及び／又は検証プロセスを含意する。
【００６０】
この必要とされるセグメントの要求に関する第４の実施形態によれば、全てのセグメントは各クライアント端末にとって公的に入手可能且つアクセス可能であり、例えばインターネットを介してアクセス可能なサーバ上で公開される。各端末は、例えば先に指摘したようにどのセグメントが必要とされているかを確定し、これを、専用のハッシュ値サーバ又は認証サーバと対話することなくこのサーバから入手する。
【００６１】
考慮されている公開鍵８０３に対応するリスト８００のセグメントを入手すると、クライアント端末はステップ６６及び図６に示したような認証プロセスの後続ステップへ進むことができる。
【００６２】
補助ハッシュ値を使用するこの現時点で好適な実施形態の優位点は、配信されるべきハッシュ値の減少にある。新たなメタハッシュ値が算出されてクライアント端末へ供給される際には、次のような２つの明らかな理由でメタハッシュ値がそこから算出される新たな増補されたハッシュ値リストも配信されなければならない。第１に、セキュリティを最大にするために、ハッシュ値リストは安全に配信又は提供されるべきデータ８０３の完全リストを包含しなければならない。第２に、説明している認証プロセスのステップ６４及び６５により、メタハッシュ値はクライアント端末によっても算出され、これが完全なハッシュ値リストを必要とする。メタハッシュ値８２１がそこから算出される補助ハッシュ値リスト８１０もやはり全てのデータ８０３を包含しているが、保有するエントリ数はオリジナルのリスト８００より少ない。従って、クライアント端末へはまず少ない方のエントリを有するリストが提供されざるを得ない。オリジナルのリスト８００から補助ハッシュ値リスト８１０へのサイズ縮小は、セグメントのサイズに直接依存する。しかしながら、セグメントサイズの増大は例えば各セグメント当たりのより大きい時間フレームの保有を含意し、望ましくない可能性がある。これはさらに、認証プロセス内でより大きいセグメント及び従ってより多くのデータがクライアント端末へ転送されなければならないことを含意し、これもまた望ましくないと思われる。このため、さらに他の実施形態は、メタハッシュ値を根として有する木構造に従って補助ハッシュ値リストの概念を再度連続的に補助ハッシュ値リスト８１０へ適用する段階的なセグメントを提供している。特に、入手されるハッシュ値リスト８１０は、任意の上述の実施形態に従ってセグメント化される。これらのセグメントは、最終的に所望されるメタハッシュ値８２２ではなくリスト８１０に類似する第２の補助ハッシュ値集合を算出するために使用される。この手順は任意数の段階に対して反復されることが可能であるが、この場合の段階深度は予め決められる場合もあれば可変である場合もある。特に、認証プロセス内で専用のサーバが必要とされるセグメントをそれによって決定し且つクライアント端末へ提供する上述の第２の実施形態を使用する場合、補助ハッシュ値の連続するステージング及び生成は完全にサーバの内部的なものになり、リスト管理及びクライアント端末に影響しないリンク機能が要求される。従って、サーバ又は幾つかのサーバは、それらの内部機能に合わせて適宜段階的なセグメントを生成することができる。さらに、異なる段階におけるセグメント及び１つの段階内のセグメントはサイズが変わる可能性がある。異なるセグメント及び段階の異なる補助ハッシュ値が、新たなセグメント内で組み合わされる場合もある。特に、１つの段階の補助ハッシュ値リストにおけるハッシュ値の１つの部分集合だけがさらにセグメント化され、次の段階の補助ハッシュ値によって「置換」されることが可能である。
【００６３】
次に、メタハッシュ値の算出に必要とされているハッシュ値リストの供給に関する他の実施形態を例示的に概説する。リスト８００、３２又は適用可能であればリスト８１０の何れかであるこの完全なハッシュ値リストは、メタハッシュ値の算出に必要とされる。この場合も、ここで言う完全なリストは上記リストの少なくとも全てのハッシュ値８０４、８１２又は３２を指すが、個々のリストの任意に、但し事前に決定されたさらなるエントリ数を含む可能性のある点は留意されるべきである。但し、このリストはこの継続されているリストに新たなエントリを加えることにより経時的に蓄積されるという事実は利用され得る。エントリは、一旦リストに加えられるとそのまま変更されない。従って、新しいメタハッシュ値に対応する新しいハッシュ値リストは、有効な先行するハッシュ値リストの全てのエントリを含んでいる。これは、新しいメタハッシュ値を受信した場合にクライアント端末におけるリスト全体を置換せずハッシュ値リストを更新することを可能にする。但しこの場合は、このリストの新しいメタハッシュ値を受信した際に、クライアント端末が既にハッシュ値リストを所有していることを想定している。新しいハッシュ値リストを個々に取得する代わりに、クライアント端末はこのハッシュ値リストへの新しいエントリだけを取得して既に局部的に記憶されているリストを適宜修正することもできる。この実施形態は、おそらくはさらに段階化されたセグメントを有するセグメント化されたリスト手法と組み合わされることが可能である。
【００６４】
ハッシュ値リスト及びメタハッシュ値に関連して説明した全ての実施形態において、異なるハッシュ値は異なるリスト及び／又はセグメント間で交差的に記録されることが可能である。オリジナルのリストである８００のその時点で有効なメタハッシュ値又は旧くてもはや使用されていないメタハッシュ値は、同じリスト８００へ、関連付けられる任意の補助リスト８１０へ、又は上記オリジナルリスト８００に関係のない他の任意のリスト８００又は８１０へ追加されることが可能である。好適にはメタハッシュ値であるハッシュ値のこのクロスポスティングはメタハッシュ値の配信ダイバーシティを増大させ、よってメタハッシュ値及びその関連リストの完全性を認証する際の信頼度及びセキュリティを高める。典型的には１つ又は数個のハッシュ値のこのクロスポスティングはシステムによるデータ処理量をさほど増加させず、よってそのパフォーマンスに影響を与えることなくシステムのセキュリティレベルを効果的に上げる。クライアント端末がそこから認証プロセスで使用されるメタハッシュ値を入手できる利用可能な異なるソースの数が少ない場合、この手法は特に効果的である。
【００６５】
クロスポスティングに加えて、例えば異なるハッシュ値サーバ１２又は認証局１１、１３から発生するハッシュ値リストである異なるリスト間の単一のハッシュ値は、単一のリスト内に組み合わされる方がよい。第三者は、このような組み合わされたリストを追加的に提供することが可能である。
【００６６】
本発明の他の態様は、認証プロセスに必要とされるようなメタハッシュ値の配信及び提供に言及している。このメタハッシュ値の配信に関する現時点で好適な実施形態は、次のようなものである。
【００６７】
先に指摘したようにメタハッシュ値を要求に応じて、例えばその個々のハッシュ値リストと共に受信する代わりに、メタハッシュ値は各クライアント端末へおそらくは複数回、且つ実際の認証プロセスとの関連以外にも送信される。現時点で好適な実施形態は、クライアント端末へ且つ／又はクライアント端末間で送信されるメッセージに効果的な現行使用されているメタハッシュ値を添付する。これは単一のハッシュ値であることから、端末の通信は端末へ送られるメッセージにこれが添付されてもさほど影響を受けない。これは新しいメタハッシュ値毎に１回行われることが可能であり、こうして例えば新しいメタハッシュ値が生成される一日又は一週間のスケジュールが実行される。しかしながら好適な代替例は、メタハッシュ値を幾つかのメッセージに例えば定期的に且つ／又は強制的に基本的な通信プロトコルの一部として添付する。クライアント端末により受信される定期的なメッセージへのこの添付は、ハッシュ値サーバ等の少なくとも１つのサーバによって手配される、又は発生されることが可能である。さらに、クライアント端末自体も、先行して受信されたメタハッシュ値を端末により送信されるメッセージに添付することが可能である。後者の場合、幾つかの所定のセキュリティ仕様に従って、メタハッシュ値は、例えば異なるソースから先行して受信された最少数の個々のメタハッシュ値の比較が首尾良く行われた後に所定の信頼レベルが達成されたことによってこれが端末により認証されている場合にのみ添付されることが必要である可能性がある。
【００６８】
添付されるこのメタハッシュ値はさらに、これをメッセージに添付するエンティティによって、即ちサーバ又は端末によって署名されることが可能である。これは、基本的なデジタル署名スキームのセキュリティ限度内で、実際にメタハッシュ値を添付したのはメッセージの送信者であってメッセージを傍受した敵対者ではないことを保証する。従って、メッセージが受信されてメタハッシュ値が取り外された後に、この関連書名は後の処理に進む前に端末によって検証されなければならない。
【００６９】
その使用時点で受信側端末によりメタハッシュ値が明示的に要求されないこの配信シナリオは、端末がメタハッシュ値の有効性を確立し得ることを必要とする。言い替えれば、クライアント端末には、受信されたメタハッシュ値が実際に認証プロセスにおいて必要とされるような最近に公開されたメタハッシュ値であるかどうかを決定する能力がなければならない。可能性のある一方法は、時間情報を配信されるメタハッシュ値に関連付けることである。これにより端末は、例えばメタハッシュ値が受信された最新のハッシュ値リストに対応すべく意図されているかどうかを確立することができる。好適にはこの情報は、メタハッシュ値及び／又は対応するハッシュ値リストの有効期限及び／又は発生時間を含む。従って、その有効性は、おそらくはメタ値を生成する周知のスケジュールをさらに考慮することによって確立されることが可能である。メタハッシュ値の有効性を確立するための他のシナリオは、要求に応じて受信された、よって最新であることが周知であるハッシュ値リストに対応しなければならない各値に固有の識別子を割り当てるというものであり、これにより好適には上記ハッシュ値リストもまた識別子を保有する。
【００７０】
この実施形態によって、クライアント端末は、例えば端末である異なるソースから受信される多くのメタハッシュ値を比較することができる。従って、確立された真正の信頼レベルは、比較ステップ６３によって、且つステップ６５における局部的な算出値とのその比較によって増大される。これは、特に先に認証されたメタハッシュ値がさらに他の端末へ配信される場合でも成り立つ。メタハッシュ値のこの配信ダイバーシティは、例えば悪意のある敵対者によって発生されるシステム内の単一障害点が検出されない機会を効果的に一段と減少させる。
【００７１】
本発明の他の態様は、もっぱら、符号化されたデジタルデータが宛先である受信者へ実際に提供される前、又は後にこのデータが記憶される、且つ／又はアクセス可能である際のその安全な配信に関連している。
【００７２】
本発明による配信モデルによってサポートされる使用モデルに関して最大のフレキシブルさをもたらすために、デジタルデータの安全な配信はまた、デジタルデータが実データ提供及び送信プロセスの前、後又はその最中に記憶され、且つおそらくは公的にアクセス可能である場合にデータセキュリティを保証する簡単な解法を規定している。さらに、通常のデータ配信シナリオでは、デジタルデータは公衆ネットワークを介して転送されることが多く、よって多くの第三者及びクライアントは配信されるデータへアクセスすることが可能である。従って、安全を確保された配信は、実データ送信トランザクションに対してだけでなく、その配信データへの先行する且つ／又は後続のアクセスに対しても責任を負わなければならない。よって、配信プロセスに関連して配信データへのアクセスを制御するための簡単な手法を提供することが望ましい。一つの明らかな手法は、例えば、実データ送信トランザクションによって定義される、データへのアクセスが可能にされる所定の時間スパン等の計時されたスケジュールを基礎とする制御されたデータアクセスメカニズムである。これは、時間スパンが満了になり且つデータアクセスケイパビリティが失効した後も、そのデータのセキュリティ及び信頼度は保証され得ることを確実にする。当然ながらこのシナリオは、所定の時間に、又は所定の時間の後に所定のデータが削除されなければならない場合にも発生し且つ適用可能である。この配信モデルを適用すると、削除は、そのデータの物理的削除を制御する必要なしに保証され得る。さらに、記憶されたデータ又は例えばサーバ上に記憶される配信データの自動発生的なログ情報及びバックアップが公衆に開示されることになるという潜在的なリスクは、本発明のこの態様の下記のような現時点で好適な実施形態によって最小限に抑えられることが可能である。
【００７３】
本発明のこの態様によれば、適切な公開鍵暗号化スキームにおける公開鍵／秘密鍵対の適用により、この配信システムを介して配信される全てのデジタルデータが非対称的に暗号化される。このため、全てのデータが公開鍵によって完全に、又は部分的に暗号化される。プレーンテキストのデータにアクセスすることを認証されている全ての意図された受信者及び当事者は、個々の復号化プロセスに必要とされる対応する秘密鍵を保有している。従って、これらの当事者しか暗号化されたデータを復号して配信データへアクセスすることができない。システムは次に、所定のスキームに従って異なる鍵対の使用を制御する。個々の鍵の取消し及び／又は削除は、この件に関する下記の実施形態によって記述されるように、保証された配信システムの異なる機能性及び特徴を確立する。
【００７４】
ある実施形態によれば、配信モデルは、データへのアクセスを認証された全ての受信者及びクライアントに、配信され且つ暗号化されたデータを復号するために必要な個々の秘密鍵を供給する。本実施形態及びこれ以降説明する全ての実施形態において、秘密鍵の供給は、安全な配信トランザクションによって達成される。保証され且つ信用のある通信媒体をそのために必要とするものもある多くの鍵配信システム及び鍵管理システムは広く使用されていて周知であり、またこの特定例ではこの鍵配信は一般的な独立した予備トランザクションとしても考えられ得ることから、この時点では鍵配信についてこれ以上考察しない。上記秘密鍵の配信には、適切な手段を利用可能であることが想定されている。好適には、これらの鍵は、説明したハッシュ値リスト及びメタハッシュ値を使用して安全に配信される。
【００７５】
さらに本システムにより、この秘密鍵は本発明のこの実施形態に従って削除又は取り消される。これは、アクティブな秘密鍵のこの制御された取消し、又は削除の後、この秘密鍵を事前に保有していた全ての認証されたクライアントはプレーンテキストとして暗号化されたデータへのアクセスをそれ以上得られないことを含意する。その結果、この鍵対を使用することによって事前に暗号化されている全てのデータは、実データを削除する必要なしにアクセスされることから効果的に防護される。削除又は取り消さなければならない鍵情報は比較的少量でしかなく、これは、１つの特定の鍵対を使用して配信され且つ暗号化されているデータ量が多い場合に特に効果的である。さらに、概して、クライアント又はクライアント端末における１つ又は数個の秘密鍵の取消し又は削除は、そのクライアントに事前に配信されている、その可能なバックアップ及びコピーを含む全てのデータの削除よりも容易且つ効果的に制御される、又は達成されることが可能である。
【００７６】
本システムによって秘密鍵が削除され、又は取り消されると、新しい鍵対が先の説明と同様に使用される。この基本的な概念は、本発明の例示的な異なる実施形態を提示して後に論じるように、異なる使用モデルに容易に適用され得る。これらの実施形態は網羅的であることを意図されたものではなく、よって本発明はこれらの事例に限定されない。特に、これらの実施形態とその技術的教示の任意の組み合わせもまた、本発明を説明する。
【００７７】
鍵対は、一度に１つだけ使用する代わりに、幾つかを同時に、又は重複する時間期間で使用することもできる。さらに、デジタルデータの配信を区別的に制御するために、異なる種類のデータ、異なる受信者グループ又はデジタルデータの異なるプロバイダに異なる鍵対を使用することができる。鍵の生成及び／又は取消しは、計時されたスケジュールに従って行なうことも可能である。システムは、新しい鍵対を生成して、送信者又は配信者に個々の秘密鍵を暗号化のために例えば毎月又は毎週ベースである最初の時間スパンで使用するように、但し例えばその生成の後、暗号化の実行後又は暗号化されたデータの受信者への送信以降６か月である第２の時間期間が過ぎるまではクライアント又は受信者において秘密鍵を取り消さない、又は削除しないように要求することができる。これは、認証された全てのクライアントは、個々の公開鍵が使用されている例えば１か月である第１の時間期間の間に暗号化されたデータに６か月間はアクセスできることを意味する。この時間ベースのアクセス制御は、特に異なる種類のデータ又はユーザに異なる鍵を使用する手法と組み合わされることが可能である。
【００７８】
他の実施形態によれば、鍵対は、先の実施形態に関して論じた方法と同様にデータをその配信に先立って暗号化するために生成され、適用される。但し、先の実施形態とは反対に、システムによる取消し又は削除の対象となるのは秘密鍵ではなく公開鍵である。従って、デジタルデータを暗号化し且つこれを配信するケイパビリティはシステムによって制御される。これは、公開鍵が削除又は取り消された後も、対応する秘密鍵を保有している全てのクライアントは引き続き、先に暗号化された全てのデータにアクセスできることを意味する。但し、この秘密鍵に関してそれ以上のデータは暗号化され且つ配信され得ないことが保証される。先に説明した実施形態と同様に、異なる種類のデータ、指定された受信者及びプロバイダに複数の鍵対を使用することが可能であり、公開鍵は１つ又は複数の計時されたスケジュールに従って生成され、取り消される。しかしながらこの実施形態は、追加的に秘密鍵を取り消す、又は削除して、先の実施形態に関して概説したものと同じ恩恵を得る場合もある。
【００７９】
本発明のさらなる実施形態によれば、同じ概念を使用して配信データ上にデジタル署名を生成することができる。このために、データプロバイダは、秘密鍵、受信者及び基本的な公開鍵署名スキームによる鍵対の対応する公開鍵を使用する。秘密鍵の取消し、又は削除は、この鍵対を使用してこれ以上データに署名はできないという効果を有する。デジタルデータの受信者がそのデータ上の署名を検証してその真正又は完全性を確認しなければならない場合、ネットワークの配信者又はプロバイダ側で秘密鍵を削除する、又は取り消すことによりさらなるデータの有効な配信は効果的に防止され得る。
【００８０】
本発明によれば、鍵の削除及び／又は取消しに関する先述の実施形態の任意の組み合わせも、やはり本発明のさらなる実施形態とされる。さらに、これら全ての実施形態においては、この鍵の削除及び／又は取消しは、システムに要求されるセキュリティにとって十分であり且つ上記セキュリティに依存する可能性のある適切な方法で制御され、実施され、又は保証されることが想定されている。これは、信用のおけるデバイス及び／又はシステムパーツの物理的セキュリティを必要とする可能性がある。さらに、鍵の削除及び／又は取消しに関する全ての実施形態は、システムの僅か１つの当事者に関連して実行される場合もある。特にこれは、個々の暗号化又は署名スキームに使用される公開鍵対を参照する。この単一の当事者又はクライアントは、デジタルデータを上記データを記憶する前にその固有の公開鍵を使用して暗号化することができる。データを復号できるのはこのクライアントだけであることから、この概念は安全な記憶機能を提供する。
【００８１】
本発明のさらに他の態様は、幾つかの暗号化スキーム及び／又は幾つかの暗号化ステップを使用する場合のデジタルデータの保証された配信に言及している。一般に、デジタルデータを配信し且つ送信するためのネットワークでは非対称暗号化スキームが使用されるが、これは特に公開鍵の暗号化システムである。典型的には、データを暗号化するためには、対称暗号化スキームがデータに適用され、対称鍵が使用される。本明細書では、以後これをＳで示す。この対称鍵Ｓ又はその生成は、多くの場合、暗号化スキームの暗号によるセキュリティを強化するために幾分かのランダムネスを必要とする。この場合、非対称暗号化は、対称鍵をその配信に先立って非対称的に暗号化することにより達成される。
【００８２】
次に、それ自体が本明細書の一部を成す添付の図面を参照し、対称鍵を使用して実データを暗号化するこの非対称暗号化概念を基礎とする、本発明による層状の暗号化スキームについてさらに詳しく説明する。層状の暗号化では、デジタルデータは好適にはネットワークの異なる当事者又はエンティティに関連付けられる幾つかの鍵を使用して連続的に暗号化され、これにより、各暗号化プロセス、従って使用された各鍵は上記暗号化層の１つを完成させる。言い替えれば、プレーンテキストデータはまず、第１の暗号化スキームによる第１の暗号鍵を使用して暗号化される。暗号化された結果は次に、各々が個々の暗号化スキームによる他の鍵を個々に適用する幾つかの段階でさらに暗号化される。
【００８３】
この連続的な、又は層状の暗号化は通常、おそらくは先行層の暗号化オーバーヘッドを含んだ状態でデータの全体量を各暗号化層において再度暗号化しなければならない。しかしながら、本発明によれば、この層状の暗号化プロセスの間に暗号化されなければならないこのデータ量は下記のように大幅に低減されることが可能である。即ち（既に暗号化された最初の暗号化層の後の）データ全体を再度暗号化する代わりに、各層では鍵情報だけが暗号化される。
【００８４】
おそらくはその保証されたデータ送信用に特に生成される一回限りの鍵である対称鍵を使用してデータが暗号化される概念を適用する場合には、暗号化されたデータだけでなくこの対称鍵も宛先である受信者へ送信される、もしくは少なくとも提示される。先に述べたように、この対称鍵Ｓは、公開鍵暗号化スキームを使用して非対称的に暗号化される。このために、データの暗号化を実行する、又は開始する送信者又は配信者は、まず対称鍵Ｓを適用してデータを個々に暗号化する。次に、送信者又は配信者は、データの宛先である受信者の公開鍵を使用して、採用された対称鍵Ｓを暗号化する。暗号化されて受信されたデータを復号するためには、受信者はこの対称鍵Ｓへアクセスできなければならない。その結果、受信者は、暗号化されたデータへアクセスすることができるようになる前に、まずはこの対称鍵を復号できなければならない。この、暗号化された実データを復号できるようになる前に対称鍵を復号できなければならないという前提条件は、本発明のこの態様による効率的な層状の暗号化プロセスを規定する。
【００８５】
各暗号化層では、全体データを暗号化する代わりに、既に暗号化されている対称鍵だけが暗号化される。パフォーマンスゲインは、主として最初の暗号化層を除く全ての暗号化層において少量の鍵情報だけを暗号化する、従って復号するだけでよいという事実から生じる。本発明の現時点で好適な実施形態によれば、各暗号化層における対称鍵の暗号化には公開鍵暗号化スキームが使用される。その結果、暗号化されたデータを復号できることが意図され、且つ従ってデータの暗号化に使用される対称鍵を復号することも意図されている宛先である受信者は、各暗号化層における対称鍵の個々の暗号化に使用される公開鍵に対応する全ての秘密鍵を保有していなければならない。
【００８６】
また、データを暗号化し、次いで暗号化された鍵情報を含む暗号化されたデータを受信者へ送る送信者は、各々が少なくとも１つの暗号化層に対して責任を負うネットワーク内の複数の異なる当事者又はエンティティを代表する可能性がある点も留意されるべきである。これは、ネットワークの１つのエンティティ又は当事者は、データ及び／又は対称鍵情報を暗号化し、次の暗号化層に関連付けられる全てのオペレーションを実行するためにこれを他のエンティティ又は当事者へ送ることを意味する。同様に、先に言及したような受信者は、各々が個々の復号ステップを実行することにより１つ又は複数の暗号化層に対応している複数の受信者を代表する可能性がある。暗号化された実データは暗号化された対称鍵に関する最後の復号ステップの後に初めて復号され得ることから、このシナリオは、これらの複数の受信者間の固有の依存性を規定すると思われる。従って、１つ又は複数の暗号化層により対称鍵情報を復号する受信者は、最終予測受信者宛の暗号化されたデータへのアクセスを制御することができる。各暗号化層に対応する個々の復号化プロセスが、暗号化されて送信された対称鍵情報に、対応する暗号化プロセスとは全くの逆順で適用されなければならない場合、暗号化されて送信されたデータを復号し且つこれにアクセスするケイパビリティを制御するための当事者又はエンティティによる階層が確立される可能性がある。
【００８７】
本発明の本件に関する他の実施形態によれば、異なる暗号化層において異なる暗号化スキームを適用可能である。これは、異なる暗号化層において、例えばＲＳＡ及びディフィー−ヘルマンベースのスキームのような異なる非対称暗号化スキームが適用され得ることを意味する。しかしながら、対称鍵を非対称的に暗号化する上述の概念からの偏向をサポートすることも考慮されている。特に、暗号化層によっては、既に対称的に暗号化されているデータも送信者によって再度部分的又は完全に暗号化される場合があり、これは受信者側で対応して復号される。このために、異なる手法が考慮されている。対称鍵情報を非対称的に暗号化することに加えて、対称的に暗号化されたデータも同じ公開鍵を使用して再度非対称的に暗号化されることが可能である。さらに、暗号化され得るものは暗号化されているデータのみであって、対称鍵情報ではない。後者の場合は、この特定の暗号化層は、受信者が対称鍵を復号できるかどうかに影響しないことを含意している。従ってこれは、むしろ残りの暗号化層とは独立している暗号化層を提起している。また、１つ又は複数の暗号化層は非対称公開鍵暗号化スキームを適用しないが、対称鍵を使用する対称暗号化スキームを適用し、オリジナルのプレーンテキストデータに対して実行される先に述べた初期対称暗号化層と同様にこの鍵を暗号化する。
【００８８】
この件における本発明の現時点で好適な実施形態によれば、上述の層状の暗号化手法は、幾つかのネットワークノードを有するネットワークを介するデジタルデータの配信に適用される。今までのところ、本発明によるネットワークを介する保証されたデジタルデータの配信をそのデジタルデータの配信者又は送信者と受信者とに関連して説明してきた。しかしながら、この同じ概念は、デジタルデータを配信するための基本的な通信媒体として使用されるネットワークに適用可能である。従って、図９は、幾つかのネットワークノード９０６〜９０９を有するネットワーク９００の例示的な図を示す。これらのネットワークノードは典型的には相互に接続され、互いの間でデータを交換する能力を有する。異なる端末及びサーバ９０１〜９０５は上記ネットワーク９００を介して互いに通信し、それら自体はネットワークノードと捉えることができる。現時点で好適な実施形態によれば、ネットワーク９００はインターネットである。複数のネットワークノード間の接続は典型的にはこれらのノード間の様々なリンクを介して確立され、これにより、１つ又は複数の直接リンク又は他のノードを介するリンクが可能になる。図９を参照すると、送信者９０１はネットワーク９００を介してデジタルデータを受信者９０２へ送ろうとしている。ユーザ端末９０２へ送信されるべきデジタルデータは、この場合は暗号化されたデータの送信より前に、少なくとも受信者の公開鍵を使用する公開鍵暗号化を適用することによって暗号化される。このために、データを暗号化するものとされている送信者９０１はまず受信者９０２の公開鍵を入手する。本発明の好適な実施形態によれば、受信者９０２の公開鍵は、この公開鍵システムに関して説明したようなハッシュ値リストを使用して送信者９０１に安全に供給される。ハッシュ値リストに関する全ての考察が当てはまることから、ここではこれ以上論じない。
【００８９】
受信者９０２の公開鍵を入手すると、送信者９０１は、先に論じた暗号化概念に従ってデジタルデータを暗号化する。この概念は送信者及び受信者だけでなく、ネットワークノードにも関連して適用される。ある実施形態によれば、１つ又は複数のネットワークノードは、適宜、先に特定したような異なる暗号化層に対応する１つ又は複数の暗号化及び復号化プロセスを実行する。例えば、ネットワークノード９０６は送信者９０１によって送信されたメッセージ（暗号化されたデータ及び対称鍵）をさらに暗号化する可能性があり、反対側ではネットワークノード９０９が暗号化されたデータ及び／又は暗号化された鍵を受信者９０２へ送る前に１つ又は複数の暗号化層によって復号する可能性がある。
【００９０】
本発明の他の実施形態によれば、この層状の暗号化概念は、ネットワークを介するデータフローを例えば送信者９０１によって、又はネットワーク９００の他のノードによって制御するために使用される。図１０〜図１２を参照すると、このプロセスの基本機能を示す高レベルのフローチャートが描かれている。図１０を参照すると、送信者９０１によって実行される例示的な作用が示されている。この場合、送信者は受信者とされる９０２に関連付けられる公開鍵を既に保有していることが想定されている。層状の暗号化の概念に従って、送信者は対称鍵Ｓを使用してデジタルデータを暗号化する。この対称鍵Ｓ及び個々の暗号化スキームは本発明に関連する概念に依存しない一般的な暗号化スキームであると思われることから、対称鍵を入手する方法又はシステムについては詳述しない。概して、この目的のためには任意の暗号化スキームを使用可能である。
【００９１】
図示された例の場合、暗号化されたデータはノードＡ（９０６）及びノードＤ（９０９）を介して受信者９０２へ送信されることが想定されている。周知であり且つ所定のネットワークノードを介するこのような経路仕様は、例えば、これらの指定されたネットワークノードによって達成されるセッション追跡及びデータ配信に関連する情報のロギングのために、セキュリティを目的として必要とされる可能性がある。この場合も、概してこのネットワーク９００に接続される端末又はサーバは何れもそれ自体がネットワークノードとして考えられ得るものであり、よって送信されるデータは、最終的な受信者９０２へ送信される前に特定の認証又は確認サーバへ送られなければならない可能性があることが知られている。図１０のステップ１１１が示すように、送信者はまず暗号鍵Ｓによってデジタルデータを暗号化する。次にこの対称鍵Ｓ自体が、ステップ１１２に示すように受信者９０２に対応する公開鍵を使用して暗号化される。結果的に得られる暗号化された対称鍵Ｓは、連続する暗号化ステップ１１３及び１１４に従って、まずネットワークノードＤの公開鍵ＰＫｄを適用し、次にはネットワークノードＡの公開鍵ＰＫａを適用することにより個々の暗号化プロセスにおいて再度暗号化される。この暗号化された暗号鍵Ｓは次に、暗号化されたデータと共にネットワークへ、特にネットワークノードＡへ送られる（ステップ１１５）。
【００９２】
まずネットワークノードＤの公開鍵を、次にネットワークノードＡの公開鍵を使用するこの層状の暗号化により、送信者は、図１１及び図１２に関する後続説明で明らかとなるように、暗号化されたメッセージがノードＡ及びノードＤを介して受信者９０２へ送信されることを保証する。
【００９３】
図１０及び図１１の双方を参照すると、図１０に示したフローチャートは図１１に示すように継続される。
ネットワークノードＡは送信者９０１によって送信されたメッセージを受信する。この場合のメッセージは、暗号化されたデジタルデータと非対称に暗号化された鍵Ｓとで構成される。ネットワークノードＡは次に暗号化された鍵Ｓを、ステップ１２１に示すようにその秘密鍵ＳＫａを使用して復号する。ステップ１１４で送信者により使用された公開鍵に対応する秘密鍵を保有するのはネットワークノードＡだけであることから、この復号ステップ１２１を実行できるのはノードＡだけである。この復号ステップ１２１は、明らかに、送信者９０１によって実行された暗号化ステップ１１３を逆行する。最終的に暗号化されたデータの復号に必要とされるような暗号鍵Ｓを得るためには、全ての暗号化ステップが対応する復号化ステップによって逆行されなければならない。その結果、ノードＡが暗号化された鍵Ｓを実際に個々に復号していれば、受信者９０２は、送信者９０１によって送信されたメッセージを受信した時点で暗号鍵Ｓを復号するだけでよい。これは、データがネットワークノードＡを通って送信されてくる場合でしか復号され得ないことを保証する。さらに、システムのセキュリティにとっては、送信者９０１が暗号化ステップ１１４の実行に際してネットワークノードＡに関連付けられる真正の公開鍵ＰＫａを適用したことを確信し得ることが欠かせない点も留意されるべきである。公開鍵ＰＫａ及びネットワークノードＡの要求されるこの認証された対応は、好適には説明したハッシュ値リストによる公開鍵の配信によって、及びおそらくはデジタル認証によって達成される。これは、この配信プロセスの間に使用される全ての公開鍵に対して同じである。
【００９４】
図９及び図１１を参照すると、ノードＡは、送信者９０１によって指定された通りにメッセージをノードＤへ送信することが想定されている。この経路仕様は、メッセージ内に包含されて各ネットワークノードにより分析されることが可能である。しかしながら、メッセージはこの例示的な図によればネットワークノードＢを介してノードＤへ送られる。従って、図１１のフローチャートが示すように、ネットワークノードＡはメッセージがノードＢを介して送信されることを明記し且つ保証する。よって、復号化ステップ１２１の結果、即ち依然として公開鍵ＰＫｄに関連して暗号化されている鍵Ｓは、ネットワークノードＢの公開鍵を適用して暗号化される。ネットワークノードＡに関して論じたように、これは、最終的に暗号鍵Ｓのプレーンテキストを取得し得るためにはメッセージがノードＢを介して送信されなければならないことを保証する。ネットワークノードＡは次に、暗号化されたデータを暗号化された鍵Ｓと共にネットワークノードＢへ送信する。
【００９５】
ネットワークノードＢは次に、受信されたメッセージを予測されたノードＤ以外のさらなるネットワークノード（図示せず）へ送信することができる。このために要求されるステップは、図１１のステップ１２０〜１２３と同様である。但し、ステップ１２２は任意選択のステップであり、ノードＡは特にネットワークノードＢ用に鍵Ｓを暗号化することなくメッセージをノードＢへ送る可能性があることは言及されなければならない。
【００９６】
図１１に示す例示的なフローチャートは図１２へと続き、ネットワークノードＢはステップ１３０でメッセージを受信する。次のステップ１３１はステップ１２１に対応するステップであるがノードＢ及びその秘密鍵に関連している。ネットワークノードＢは最終的に結果として得られるメッセージをノードＤへ送信し、ノードＤは暗号化された鍵Ｓとその秘密鍵に関連して復号化プロセスを実行する（ステップ１３４）。最後にメッセージは、ステップ１３５に示すように受信者９０２へ送られる。双方のメッセージ部分を受信すると（ステップ１３６）、受信者は次にステップ１３７においてその秘密鍵ＰＫＲを適用して鍵Ｓを復号することが可能になる。プレーンテキストとしての鍵Ｓへのこのアクセスにより、受信者は次に、ステップ１３８に示すように受信されたデータを復号することができる。
【００９７】
記述した配信プロセスは、当業者が本発明を理解する上で要求される必要なステップのみを説明するものである。概して記述したプロセスは、このようなネットワークを介するデータ配信に関連する、且つ技術上周知である公開鍵暗号化スキームを適用する場合の他の一般的なオペレーションをなすさらなるステップを含む可能性がある。この意味で明示的に挙げられるのは、受信されるメッセージの鍵情報部分及び／又はデータ情報部分を復号しなければならないかどうかをネットワークノードが決定する任意選択の確立ステップである。追加的なステップは、メッセージの送り先としてさらにどのノード（受信者を含む）が指定されるか、及びメッセージの通過が予定されているさらなる任意のノードに関連して鍵情報又はメッセージがさらに暗号化されなければならないかどうかを決定する可能性がある。可能性のあるさらなるステップは、情報を上記ルーティング及び暗号化仕様を明記するメッセージ又はその一部に追加する、又は関連付けることを含む。
【００９８】
本発明のさらなる実施形態によれば、層状の暗号化態様に関連して先に述べた考慮事項が公開鍵署名スキームにも当てはまる。先に述べた暗号化スキームに比較すると、公開鍵を基礎とするデジタル署名スキームは、対応する全ての暗号化及び復号化プロセスの役割を交換するだけである。これにより、先の暗号化プロセスは受信者によって実行される検証ステップに対応し、デジタルデータの署名者又は送信者によって実行される個々の復号化ステップは復号化ステップのオペレーションを含む。相応してデータの送信者又は署名者はその固有の秘密鍵を適用し、受信者又は署名の検証者は署名者の公開鍵を入手しなければならない。使用される大部分の署名スキームはさらに、算出され且つ予測された結果の署名検証プロセスの一部として比較ステップを必要とする。基礎的な公開鍵システムが同じであることから、層状の暗号化及び所定のネットワークノードを介する指定され且つ制御される配信をデジタル署名に適用することができる。デジタルデータへの署名に際しては、典型的にはハッシュ関数がそのデータに適用され且つ署名者の秘密鍵を包含する署名オペレーションがその算出されたハッシュ値に対して実行される。層状の署名スキームに関しては、これは異なる秘密鍵を有する、異なる署名層における連続的な署名へと移行し、受信者による対応する検証プロセスにおいて適宜これを検証する。
【００９９】
メッセージはデータ及び先行層によって生成された署名の双方によって形成されることから、通常、署名は、ある特定の層において両者をハッシュすることによって生成される。層状の暗号化と同様に、各層でこのメッセージ全体をハッシュする必要はない。当該層の関連の秘密鍵によって個々に署名し直されなければならないものは先行して算出されたハッシュ値だけであるが、これは、使用されるデジタル署名スキームに従って何らかの一般的なデータフォーマット又はハッシュを必要とする可能性がある。その結果、各層で（問題の同一のデジタルデータの）同一のハッシュ値に対して実行されることを除けば互いに独立しているデジタル署名が生成される。従って代替として、ハッシュ値ではなく、各層において個々の先行層の実署名（署名されたハッシュ値）が署名されることが可能である。（第１の層を除く）全ての層の署名はハッシュされたデータだけでなく先行層の署名に対しても発行されることから、この代替案は、どの署名が最初に発行されていて、よって最初に検証されなければならないか、即ちどの署名がどの署名層に対応するかをより簡単に確立し且つ制御することができるという優位点を有する。これにより、先行層の署名に署名する代わりに、先行署名をハッシュしてこの新しいハッシュ値に署名することもまた、全ての例において必要とされるわけではないが可能であり、これで、デジタルデータだけでなく先行署名に対しても責任を負うことになり、よって先に述べたものと同じ結果がもたらされる。これらの層状の署名は、配信されるデジタルデータの層状の暗号化プロセスに関する実施形態と組み合わされることが可能である。
【０１００】
この層状の署名方法は、層状の暗号化プロセスに関して述べたものと同じ方法で異なるネットワークノードに適用されることが可能である。（おそらくは暗号化されている）データ及びそれに対する１つ又は複数の署名からなるメッセージを送信又は受信する、この場合も同じく図９に示すような送信者及び／又は受信者である可能性のある各ノードは、署名を発行し且つ／又は署名を検証しなければならない。ネットワークを介する所定の経路に関する同様のスキームも、特定することが可能である。受信者は、メッセージが実際に所定の全てのノードを通過したかどうかを、これらのノードが受信されたメッセージに有効な署名で適宜署名したかどうかを確定することによって確立することができる。さらに、送信されるデータの予測された受信者とは異なるネットワークノードも、メッセージが通過した、又はメッセージの発生源である他のノードによって先に発行された１つ又は複数の署名の有効性を、そのメッセージを他のノード又は受信者へ送信する前に検証しなければならない方がよい。
【０１０１】
本発明の他の態様は、１つのサーバが多数のクライアント又はユーザに対応しなければならないサーバクライアント環境における保証されたデータ配信に関する。データ暗号化によって確立される多数のクライアントへの保証されたデータ配信のための現行の方法及びシステムは、算出が大規模であり、サーバ側に大規模な記憶容量を要求する。さらに、クライアントは暗号化されたデータの送信に先立ってシステム又はサーバに登録しなければならず、これは典型的には、クライアントに関する私的情報を、そのクライアントの将来的な識別及び認証用にサーバ側でこれを記録しておくために開示することを必要とする。対称及び非対称暗号化スキームでは一般に発生するこのアイデンティティ暴露の必要性は、これらの暗号化配信システムの欠点になる。非対称暗号化方法の場合であっても、クライアントは匿名のままでいる可能性があり、即ちあらゆるデータメッセージを個々に取得される公開鍵によって非対称的に暗号化する可能性があって、サーバに関する記憶及び処理要件は格段に高くなる可能性がある。対称暗号化スキームを使用する場合は、サーバは少なくとも、全ての加入クライアントの全ての対称鍵のリストを記憶し且つ保持しなければならない。さらに両当事者はこれらの鍵を承認し、又は確定し且つ／又は交換しなければならず、安全且つ秘密裡に開示されるデータ交換、従って非対称又は対称暗号化が必要になる。この匿名性／効率問題は、パフォーマンス及びユーザにとっての便宜性の面で問題であるだけでなく、意図された安全なデータ配信プロセスにとって必要である、且つ同プロセスの間に必要であるようなプライベートで秘密的なクライアント情報がサーバ側に送信されて記憶されなければならないためにシステムのセキュリティに直接影響する。従って、本発明の一実施形態による保証されたデータ配信は、必要な暗号化関連情報、特には配信データの送信者たるサーバと受信者たるクライアントとの間で共有される秘密としての対称鍵に関する情報の確立及び処理をも担っている。
【０１０２】
従って、本好適な実施形態は、サーバとクライアントとの間に安全且つ効率的な通信を確立する方法を含む。図１３Ａ及び図１３Ｂは、本発明のこの態様を説明し且つ当業者に基本機能を明らかにするために適切であると思われるステップを含む高レベルフローチャートを例示的に描いたものである。フローチャートは、図１３Ａ及びこれに続く図１３Ｂによって各々示されている。クライアントはまず、ランダムに生成されたトークンＴをサーバへ送信することによりネットワークのサーバ側での登録作業を行う。このトークンは、先述の安全な配信方法に該当するサーバの公開鍵及び個々の公開鍵を配信するためのハッシュ値リストを使用して非対称的に暗号化されることが可能である。これらのステップを、図１３Ａのステップ１４０及び１４１に示す。
【０１０３】
サーバは、安全且つ秘密裡の乱数値Ｒを生成又は取得する。図１３Ａのこのステップ１４２は一度実行され、このサーバに関して確定される場合もあれば再度生成される、又は経時的に更新される場合もある。トークンＴを受信し、且つ必要であれば復号を終えると、ステップ１４４に示すようにサーバは少なくともトークンＴ及びそのランダムに選択されて確定された値Ｒを含むメッセージに関してハッシュ値を算出する。算出されたハッシュ値はＳで示され、サーバとクライアントとの間の安全な通信のための対称鍵情報として作用し、両者間で共有される秘密となって実現する。サーバは、ステップ１４５に示すように、おそらくは先に取得したクライアントの公開鍵を使用して非対称的に暗号化されているこの共有の秘密Ｓをクライアントへ提供する。サーバは、この値Ｓ又はトークンＳも対応するクライアントのＩＤも記憶する必要がない。
【０１０４】
代わりに、ステップ１４６及び１４７に示すように、クライアントは、安全且つ秘密裡にサーバへ送信されるべきメッセージ、即ちデジタルデータを対称的に暗号化することができる。サーバには、問題のこのメッセージと共にトークンＴも送信される。この、及び後続のメッセージ及びデータの送信に関しては、これまでに述べた配信方法に関する幾つかの代替実施形態を適用可能である。トークンが例えばサーバの公開鍵によって暗号化されていれば、サーバは、任意選択のステップ１４８が示すようにトークンＴを個々に復号する。するとサーバは、問題のメッセージを対称的に暗号化するために使用された共有の秘密Ｓを容易に算出し直すことができるようになる。ステップ１４４と同じく、サーバはステップ１４９においてトークンＴ及びその秘密の乱数値Ｒをハッシュする。サーバは、ステップ１５０でこの算出された値Ｓを使用して受信されたメッセージを復号する。両者は、両者間で共有される秘密である値Ｓを保有していることから、ステップ１５１及び１５２に示すように、所望される可能性のあるクライアントへの応答メッセージはこの同じ値Ｓ及び対応する対称暗号化スキームを使用して暗号化されることが可能である。或いは、新しい共有の秘密Ｓを使用して類似プロセスが実行される場合もある。
【０１０５】
従って、概説したこの方法は、鍵のリストを記憶する必要がなく、サーバと通信する全てのクライアントに対して独立な対称暗号化機能を提供し、且つさらにクライアントがシステムに匿名で参加できる可能性を提供している。秘密のサーバ乱数値Ｒはもっぱら供給される秘密Ｓの算出を規定することから、システムのセキュリティはこの値Ｒの機密性及び秘密性に依存する。おそらくはシステムのセキュリティ仕様に従って計時されたスケジュール又は使用スケジュールに合わせてサーバが新しい乱数値Ｒを使用する場合、ステップ１４０又は１４２〜１４５の実行に際して、あらゆるクライアントはサーバ側での登録を再度行ない、つまりは共有の秘密及び鍵情報Ｓを取得しなければならない。
【０１０６】
他の実施形態によれば、サーバはトークンＴを生成し且つ／又は供給し、これを値Ｓと共にクライアントへ配信する。さらなる実施形態によれば、サーバはトークンＴの所定の部分を生成する。これを使用してサーバは幾つかの乱数値Ｒを算出し、相互を区別化することが可能であり、これによってサーバはこの生成されたトークンＴの一部によりどの値Ｒを適用して共有される秘密Ｓを算出するかを決定する。サーバは、クライアントを異なるグループに仕切る場合もあり、且つ／又はサーバにおけるクライアントの登録時間によって区別化する場合もある。後者の概念に従って、サーバは、トークンＴの個々の周知部分を選択的に交換又は更新することにより、どのユーザグループがシステムに再登録しなければならないかを制御することができる。
【０１０７】
さらに他の実施形態によれば、トークンＴは、サーバとクライアントとの間の通信の度に、又は指定された回数の同通信の後に新しいトークンＴと交換される。このため、クライアントによってサーバへ送信されたメッセージの一部は新しいトークンＴとして機能する。或いはこれは、例えばこのメッセージ部分をハッシュすることを必要とする可能性のある指定された関数を適用して新しいトークンを生成すべく使用されることが可能である。これは、サーバが新しい値Ｓを、例えばこれを応答メッセージと共にクライアントへ送ることによりクライアントへ提供することを含意する。特に、この通信の間は、サーバはクライアントからメッセージを受信する。これらのメッセージの一部は、新しいトークンのベースになる。本実施形態に関連して考察した幾つかの手順によれば、この部分は、暗号化されたメッセージの一部、復号されたメッセージデータの一部、前述の両一部の一方又は双方のハッシュ値又は単なるその一部又はこれらのデータセクションの任意の組み合わせである可能性がある。次にサーバは、ステップ１４４及び１４９に説明し且つ示すようにこの新しいトークン及び乱数値Ｒから新しい鍵情報Ｓを算出する。但し、クライアントへの応答メッセージ又はそのデータは、図１３Ａ及び図１３Ｂに関して説明したように先行する古い鍵値Ｓを使用して暗号化される。この暗号化された応答メッセージはさらに新しい鍵値Ｓを含むが、これもまた旧いＳ値を使用して暗号化され、応答メッセージと共にクライアントへ送信される。また、応答メッセージはこの新しい鍵Ｓだけを含むことも可能である。
【０１０８】
これでクライアントは、個々の基本的な暗号化スキームに従って旧い秘密の共有値Ｓを使用し、応答メッセージを復号することができる。新しい値Ｓを算出する前にサーバによって適用されるような新しいトークンＴを取得するためのスキーム又はアルゴリズムもまた、クライアントには周知である。これは、相互に合意されたデータ送信プロトコルの一部である場合もある。よって、また新しいトークンはこの同じクライアントにより送信された先行メッセージを基礎とするものであったために、クライアントはサーバと同様にして新しいトークンＴを算出することができる。
【０１０９】
この方法によれば、新しいトークンは、個々の、又は全てのクライアントによる再登録ステップを必要とすることなく、且つ多大な算出コストを追加することなく、サーバ／クライアント間のあらゆる通信に使用されることが可能である。さらに、新しいトークンＴ及び新しい鍵情報Ｓがクライアントから受信されたメッセージの復号されたデータの少なくとも一部を基礎とするものであれば、クライアント及びサーバ以外にどんな当事者も、どのクライアントが旧のトークンＴに関連付けられ、現にどのクライアントが新しいトークンＴに関連付けられているかを決定し得ない、又は追跡し得ないことが保証される。
【０１１０】
結果的にこの実施形態の場合、新しいＳ値は新しいトークンＴ及び新しい乱数値Ｒから取得されることに起因して、サーバ側の乱数値Ｒは、クライアントがサーバ側で再度登録する明らかな必要性なしに取り消され且つ交換されることが可能である。従ってサーバは、この新しいトークンの一部を説明したような受信されたメッセージからは取得せず、この部分をそうしたものから独立して生成し、この部分を新しい値Ｓと共に同様にしてクライアントへ送信する。サーバは、ステップ１４９の実行に際して旧い又は新しい乱数値Ｒが使用され、必然的に再度適用されなければならないかどうかを認識することから、この点は重要である。但し代替として、例えば時間仕様である他の何らかの適切な識別子を対応的に有効な値Ｒのこの決定に関するメッセージに添付することもまた可能である。他の代替方法として、さほど複雑でないオペレーションが実行されなければならないという意味合いから、可能な全ての値Ｒを使用する試行錯誤的手法もある。或いは、サーバによって完全なトークンＴが生成され、先の説明のようにクライアントに供給されることも可能である。
【図面の簡単な説明】
【０１１１】
【図１】公開鍵インフラシステム。
【図２】ハッシュ値サーバ又は認証局サーバの機能ユニット。
【図３】ハッシュ値及び固有の識別子のリストを記憶するテーブル。
【図４】公開鍵、関連のユーザＩＤ及び認証リストを記憶するテーブル。
【図５】ハッシュ値リストの管理プロセスのフローチャート。
【図６】公開鍵認証プロセスのフローチャートの第１の部分。
【図７】図６のプロセスの第２の部分。
【図８】補助ハッシュ値とそのリストの例示。
【図９】幾つかのネットワークノードを有するネットワークを含むシステム。
【図１０】ネットワークの幾つかのネットワークノードが関与する配信データの層状の暗号化のための基本的機能及びフローを示す高レベルフローチャート。
【図１１】ネットワークの幾つかのネットワークノードが関与する配信データの層状の暗号化のための基本的機能及びフローを示す高レベルフローチャート。
【図１２】ネットワークの幾つかのネットワークノードが関与する配信データの層状の暗号化のための基本的機能及びフローを示す高レベルフローチャート。
【図１３Ａ】安全なデジタルデータ配信のための安全且つ暗号化された通信を確立する基本的機能及びフローを示す高レベルフローチャート。
【図１３Ｂ】安全なデジタルデータ配信のための安全且つ暗号化された通信を確立する基本的機能及びフローを示す高レベルフローチャート。
【図１】
2005539441.tif 000003
【図２】
2005539441.tif 000004
【図３】
2005539441.tif 000005
【図４】
2005539441.tif 000006
【図５】
2005539441.tif 000007
【図６】
2005539441.tif 000008
【図７】
2005539441.tif 000009
【図８】
2005539441.tif 000010
【図９】
2005539441.tif 000011
【図１０】
2005539441.tif 000012
【図１１】
2005539441.tif 000013
【図１２】
2005539441.tif 000014
【図１３Ａ】
2005539441.tif 000015
【図１３Ｂ】
2005539441.tif 000016
【国際調査報告】
2005539441.tif 000017
2005539441.tif 000018
2005539441.tif 000019
2005539441.tif 000020
2005539441.tif 000021
2005539441.tif 000022