JPH09507729A - キー寄託機能付き暗号システムおよび方法 - Google Patents

Abstract

(57)【要約】 本発明は、ユーザの秘密暗号化キーを複数の構成部分に分割し、それらの構成部分を特定のユーザが選択した信用された代理人に送信するための方法を使用するキー寄託機能付き暗号システムおよび方法と、自己認証するチップデバイスにより実行される、近代的な公開キー認証管理を使用するシステムを提供する。チップは、ある種の条件が満たされる場合にのみ、暗号化または復号化を行う。つまり（１）有効な「送信者認証」および有効な「受取人認証」が入力される場合、この場合の「有効な」とは、特定のユーザの使用復号化キーが、指定された数の寄託代理人に認証できるように寄託されること、およびマスタ寄託センタが、チップ製造メーカーにより登録、認証されることを意味する場合、および（２）有効なメッセージ制御ヘッダが送信者により作成され、受取人により確証され、それにより、許可された調査官に、寄託されたキーを要求し、取得するのに用いる十分な情報を与える場合である。キー寄託および寄託認証を受け取るための方法は、信用されたデバイスを信用された第三者で登録し、その関係者がら、デバイスが他の信用されたデバイスと通信できるようにする許可を受け取るという、より一般化されたケースにも適用される。本発明は、信用された寄託センターで、複数のユーザにより使用される複数の非対称暗号化キーを寄託するステップと、寄託センタで、前記複数のキーのそれぞれを確認するステップと、確認時に前記複数のキーのそれぞれの権限授与を認証するステップと、前記認証を条件とした前記複数のキーのそれぞれ１つを使用する前記複数のユーザのそれぞれから通信を開始するステップとを具備し、複数のユーザの間で認証できるように信用された通信を作成する方法も提供する。さらに、本発明は、各通信に含まれるメッセージ制御ヘッダの使用に基づき、許可された警察による通信の復号化、特殊な警察デコーダボックスの使用、警察および他の機関による濫用を防止するための警察の盗聴装置の監査も実現する。さらに、認証システムおよびストリーム指向データの暗号化を使用し、デバイスファームウェアの再キー入力およびアップグレードを実現する。

Description

【発明の詳細な説明】 キー寄託機能付き暗号システムおよび方法 背景技術 本発明は、暗号通信システムに関する。さらに詳しくは、本発明は、暗号通信 システムで使用される暗号化キーの安全な作成、認証、記憶、および配布に関す る。またさらに詳しくは、本発明は、自己認証チップデバイスにより実行される 暗号化キー寄託、および公開キー認証管理のシステムに関する。 精密なコンピュータ技術および分散データ処理システムの開発および普及によ り、ディジタル形式での情報の転送は急激な伸びを示した。この情報は、財政お よび金融に関する事柄、電子メール、電子データ交換およびそれ以外のデータ処 理システムで使用される。この情報を安全にされていない、あるいは保護されて いない通信路で伝送することは、伝送される情報を盗聴、または改変にさらすと いう危険を伴う。暗号通信システムは、不安全な通信路で伝送されるメッセージ の許可されていない関係者によるモニタを防止することにより、これらの伝送の プライバシーを守る。また、暗号通信システムは、不安全な通信路上で伝送され るメッセージ中の情報を許可されていない関係者が改変するのを防止することに よって、これらの伝送の保全性も保証する。暗号通信システムは、さらに、確認 することができる偽造不可能かつ文書に依存した形式でのディジタル化された、 送信者による自身のメッセージの拒否を防止することができる署名を提供するこ とにより、伝送の保全性および確実性を保証することができる。 暗号システムは、ディジタル化された音声伝送または画像伝送を含む、ディジ タルデータ伝送を、意図された受取人以外のすべてによって理解不能とするため に、ディジタルデータ伝送の符号化または暗号化を必要とする。ディジタル化さ れた、音、文字または数字から構成される普通文（平文）メッセージは、数値に より符号化されてから、符号化されたメッセージを、暗号化キーとも呼ばれる番 号または数字の指定されたセットに基づいて変換する複雑な数学的なアルゴリズ ムを使用して暗号化される。暗号化キーとは、使用されるアルゴリズムまたは暗 号システムに応じて無作為に選択されるか、特殊な数学的な特質を持つデータビ ットのシーケンスである。コンピュータで実現される精密な暗号アルゴリズムは 、 長さ数十万ビットで、許可されていない復号化のあらゆる既知の方法に対抗でき る番号を変換および操作できる。暗号アルゴリズムには、対称キーアルゴリズム および非対称キーアルゴリズムという２種類の基本的な暗号アルゴリズムがある 。 対称キーアルゴリズムは、通信の送信者による暗号化および通信の受信者によ る復号化の両方に同一の暗号化キーを使用する。対称キー暗号システムは、信頼 されていない第三者から保護するために暗号システムを使用する目的で暗号化キ ーを共有する２つの関係者の相互信頼の上に構築される。もっとも有名な対称キ ーアルゴリズムとは、国立規格技術研究所（National Institute of Standards and Technology）により最初に発表された国立データ暗号規格（ＤＥＳ）アルゴ リズムである。これは、連邦登録、１９７５年３月１７日、第４０巻、第５２号 、および１９７５年８月１日、第４０巻、第１４９号を参照するとよい。送信者 の暗号デバイスは、ＤＥＳアルゴリズムを使用して、その通信セッション（セッ ションキー）用の暗号化キー（ＤＥＳ暗号化キーの長さは５６ビットである）で ロードされた時点でメッセージを暗号化する。受取人の暗号デバイスは、ＤＥＳ アルゴリズムの反対のアルゴリズムを使用し、暗号化に使用されたのと同一の暗 号化キーでロードされた時点で暗号化されたメッセージを解読する。ただし、送 信者と受取人の間で希望される通信が行われる以前に、許可されていない第三者 がアクセスしない安全な通信路上で送信者と受取人が暗号化キーを交換する必要 があるため、対称キー暗号システムの妥当性は、一般的に、疑問視されてきた。 最初に暗号化キーを確実に交換してから初めて通信を暗号化するというこのプロ セスは、大部分の場合、低速かつ面倒であるため、自然発生的または懇願された のではない通信を必要とする状況、または互いに知らない者同士である関係者間 での通信を必要とする状況においてはうまくいかない。さらに、許可されていな い第三者による暗号化キーの割込みにより、その第三者は暗号化された会話の両 側で盗聴できるようになる。 暗号アルゴリズムの第２の種類である非対称キーアルゴリズムは、暗号化およ び復号化に異なる暗号化キーを用いる。非対称キーアルゴリズムを使用する暗号 システムのおいては、ユーザは暗号化キーを公開とし、復号化キーを秘密（秘密 ）とするため、公開暗号化キーから秘密復号化キーを引き出すことは実行不可 能である。したがって、ある特定のユーザの公開キーを知る誰もがそのユーザに 対するメッセージを暗号化できるのに対し、メッセージを復号化できるのはその 公開キーに対応する秘密キーの所有者であるユーザだけである。この公開／秘密 キーシステムは、その両方とも本明細書に参照により取り入れられている、１９ ７６年１１月の情報理論に関するＩＥＥＥ会報のディッフィー（Diffie）および ヘルマン（Hellman）の「暗号作成法の新しい方向」および米国特許第４，２０ ０，７００号（ヘルマン等）の中で初めて提案された。 初期のタイプの非対称キーアルゴリズムを使用すると、通信のそのセッション の間、暗号化キーの通信関係者による対話による作成により、安全ではない通信 路上で安全に通信することができる。非対称キーアルゴリズムを使用する場合、 ２者の対話を行うユーザは、同時にかつ独立して、盗聴者が推論不可能であり、 ユーザ間の通信のそのセッションを符号化するために対称的に使用される必要が ある安全な暗号化キーを作成することができる。安全な暗号化キーを作成するこ の対話型の方法は、ディッフィーおよびヘルマンにより彼らの１９７６年の論文 に記述された。図２に図示される対話型ディッフィー・ヘルマン法として知られ るこの従来の技術による方法の下では、二人のユーザＡ、Ｂのそれぞれが無作為 に秘密番号２１、２２を選択してから、２つの公開既知番号およびそのユーザに より選択される秘密番号２１、２２を使用して中間番号２３、２４を計算する。 その後で、各ユーザは、相手ユーザに中間番号２３、２４を送信してから、自分 自身の秘密番号２１、２２および相手ユーザから受信したばかりの中間番号２４ 、２３を使用して、秘密（対称）暗号化キー２５を計算する。その後で、対話的 に作成された暗号化キー２５は、その通信セッションを、このようにされていな ければ安全ではない通信路上で、対称キーアルゴリズム通信のやり方で暗号化お よび復号化するために、両方のユーザによりＤＥＳまたはそれ以外の対称暗号化 キーとして使用される。この対話型プロセスは、数秒のリアルタイムしか必要と せず、ある特定のセッション中のディジタル化された音声伝送または画像伝送を 含むすべてのディジタル通信は、単にセッション開始時にボタンを押して対話キ ー交換プロセスを開始するだけで暗号化することができる。対話型ディッフィー ・ヘルマン・キー作成方法で選択されるすべての数は非常に大きいため、計算を 逆 に実行することは不可能であり、盗聴者は秘密暗号化キーを計算することはでき ないため、通信のプライバシーが保たれる。計算を逆に計算することが不可能で あるため、各ユーザは、このアルゴリズムを使用して受信されるあらゆる通信は 改変されておらず、相手方ユーザによってのみ送信されたことが分かるので、通 信の保全性および確実性が保たれる。しかしながら、この対話型キー交換法では 、関係者が、暗号化キーを作成するためにリアルタイムで対話することが必要と なり、懇願されたのではない通信あるいはなじみのない関係者にとっては有効で はない場合がある。特に、対話型ディッフィー・ヘルマン・キー交換法は、受取 人がセッションキーを交渉するためにオンライン上にいないため、蓄積形通信電 子メールスタイルのメッセージ通信や電子データ記憶システムでの文書の長期保 存にはうまく行かない。 認証型ディッフィー・ヘルマンとして知られる修正された非対話形のディッフ ィー・ヘルマン法は、通信する関係者がともにオンラインにいない場合に使用で きる。認証型ディッフィー・ヘルマンセッションキー作成法の認証ステップは、 図３に示される。未来の受信者である一人のユーザが、秘密番号３１（彼の秘密 キー）を無作為に選択してから、２つの公開されている数３２とそのユーザが選 択した秘密番号３１を使用して、中間番号３３を計算する。それから、そのユー ザは、中間番号およびその数がともに彼の秘密キー３４を形成する２つの公開数 とともに識別の証拠を認証を行う権威に送信し、その後でその権威が、発行する 認証を行う権威がユーザの認定をユーザのディッフィー・ヘルマン公開キー情報 ３４に結び付けることにより、ディジタル署名３６される公開キー認証３５を発 行する。そのユーザにより公開された公開キー３４は、ユーザが別の秘密キー３ １を再入力し、選択するまで変わらない。認証型ディッフィー・ヘルマン法を使 用するメッセージ通信は、図４に示される。そのユーザにメッセージを伝送する ために、送信ユーザは、最初に受信ユーザの認証３５を入手し、認証を行う権威 の署名３６を確認する。送信者は、次に受取人の（受取人の認証から）中間番号 ３３および無作為に選択する送信者自身の秘密番号４１（彼の秘密キー）を使用 して、その通信セッションのセッションキー４２を計算する。それから、送信者 はセッションキー４２を使用してメッセージ４３を暗号化し、暗号化していない 自分自身の中間番号４０を通信の最初に入れる。受信者は、通信を受信するとす ぐに、送信者の暗号化されていない中間番号４０および自分自身の秘密番号３１ （つまり秘密キー）を使用してセッションキー４２を計算し、その後でセッショ ンキー４２を使用してメッセージ４３を解読する。対話型ディッフィー・ヘルマ ン法を使用する場合のように、認証型ディッフィー・ヘルマン法で作成されるセ ッションキーは、ＤＥＳのような従来の対称アルゴリズムを使用して、さもなけ れば不安全な通信路上でそのセッションの間通信の暗号化および復号化をするた めに、両方の関係者により使用される。しかしながら、認証型ディッフィー・ヘ ルマン法では、信頼される存在、つまり認証を行う権威が、送信ユーザが中に含 まれる情報が正しいことを信頼できるように、受信ユーザの公開キー認証に署名 することが必要となる。加えて、送信者により無作為に選択され、それを用いて 送信者がその通信のセッションキーおよび中間番号を計算する秘密キーは、他者 が（認証済みの公開キー番号に対応する）恒久的な秘密キー番号を学習すること を回避する目的で、送信者自身の公開キー認証に結び付けられている秘密キーに 同一であってはならず、送信者はそれらを特定のメッセージに対してだけ作成さ れる短命な秘密キーまたは中間番号とは異なったものにしておく必要がある。 ライベスト（Rivest）、シャミール（shamir）およびアドルマン（Adleman） にちなんで命名されたＲＳＡアルゴリズムと呼ばれる別の非対称キーアルゴリズ ムは、本明細書に参照により取り入れられる米国特許第４，４０５，８２９号（ ライベスト等）に記述され、２つの大きな素数の積である数を因数分解する難し さを伴う。対話型ディッフィー・ヘルマン法を使用する場合と同じように、ＲＳ Ａアルゴリズムは計算する場合に比較的簡単であるが、実際には逆計算するのは 実行不可能である。したがって、公開キーから秘密キーを引き出すのは実現可能 ではなく、このようにして通信のプライバシーは守られる。いったんメッセージ がＲＳＡアルゴリズムを使用する公開キーで暗号化されると、秘密キーだけがそ れを復号化できるし、逆もまた同じである。認証型ディッフィー・ヘルマン法を 使用する場合と同じように、ＲＳＡアルゴリズムでは、信頼される存在がユーザ の公開キーを認証し、公開する必要がある。ただし、両方のディッフィー・ヘル マン法とは対照的に、ＲＳＡアルゴリズムは、双方の関係者に より共通に使用される「セッションキー」をそれ自体で作成しない。代わりに、 ある特定のユーザ向けの公開暗号化キーは直接そのユーザに対する通信を暗号化 し、そのユーザの秘密復号化キーが、ユーザの公開キーを用いて暗号化されたそ れらの通信を復号化する。このように、ＲＳＡアルゴリズムは純粋な非対称キー アルゴリズムである。 しかしながら、ＲＳＡアルゴリズムは複雑であり、非常に大きな数によるメッ セージの指数化が必要となるため、ＲＳＡアルゴリズムを使用する妥当な長さの メッセージの暗号化もしくは復号化はかなりの時間を要する。したがって、対称 アルゴリズムで使用するＤＥＳ暗号化キーを転送するためにＲＳＡ非対称アルゴ リズムを使用する方が、はるかに簡略、高速、および効率的である。この従来の モードの動作は、ＲＳＡキー転送として知られ、図５および図６に示される。例 えば、図５を参照すると、ユーザは、無作為なＤＥＳキー５１を作成し、そのＤ ＥＳキーを用いてメッセージ５２を暗号化できる。それから、ユーザは、意図さ れた受信ユーザの公開ＲＳＡ暗号化キー５３を用いてＤＥＳキー５１を暗号化し 、ＲＳＡ暗号化されたＤＥＳキー５５とともに、ＤＥＳ暗号化されたメッセージ ５４を受信ユーザに伝送する。図６に示されるように、伝送の受信後、受取人は 、自分の秘密ＲＳＡ復号化キー５６を使用してＤＥＳキー５１を復号化し、その ＤＥＳキー５１を使用して、メッセージ５２を復号化する。ＤＥＳアルゴリズム の方が、ＲＳＡアルゴリズムより計算に必要とする時間および費用がはるかに少 ないため、対称ＤＥＳキーは実際のメッセージの暗号化および復号化に使用され るが、非対称ＲＳＡキーは、対称ＤＥＳキーの暗号化および復号化に使用される 。 ＲＳＡ公開／秘密キー暗号システムは、メッセージ依存および署名者依存の両 方であるディジタル「署名」も実現し、受信されたメッセージが実際に送信者に より送信されたこと、およびメッセージが改変されずに受信されたことを認証す るのに使用できる。ＲＳＡディジタル署名は、ユーザの秘密キーがそのユーザの 公開キーを使用して暗号化された通信だけを復号化できるようにすることに加え て、ユーザの秘密キーがそのユーザの公開キーによってだけ復号化できるメッセ ージを暗号化できるようにするＲＳＡのもう一つの特性に基づいている。ユーザ だけが秘密キーを持っているので、秘密キーを暗号化に使用することにより、ユ ーザの公開キーにアクセスするあらゆる人により確認可能な出所の認証が可能と なる。実際には、送信者は最初に自分の秘密キーを使用してメッセージテキスト を、誰もが復号化できるが、出所はその送信者だけである署名済みメッセージに 符号化する。希望する場合、送信者は、それから随意に受取人の公開暗号化キー を使用し、伝送対象の署名済みメッセージを暗号化することができる。受取人は 、暗号テキストを受信するとすぐに、必要ならば自分の秘密復号化キーを用いて 暗号テキストを復号化し、署名済みメッセージを送信者の公開暗号化キーで復号 化する。送信者だけが自分の独自の秘密キーを知っているので、送信者だけが特 定の「署名済み」メッセージを送信するであろう。したがって、署名は送信者の アイデンティティを確認する。また、受取人だけが送信者の公開キーを持ってい るため、送信者は、受取人または許可されていない第三者が自分のメッセージを 改変あるいは偽造したと主張することはできない。したがって、署名は、送信者 によるメッセージの否認を防止する。さらに、送信者の秘密キーだけが元のメッ セージを変換し、送信者だけが自分独自の秘密キーを知っているため、受取人も 許可されていない第三者もメッセージを改変することはできなかったであろう。 したがって、署名はメッセージの保全性を認証する。 また、ＲＳＡアルゴリズムは、ハッシング（hashinq）機能を使用し、各文書 に一意である短いメッセージ摘要を作成する別のタイプのディジタル署名も実現 する。図７および図８は、それぞれ、ハッシング機能を使用するＲＳＡ署名の作 成およびＲＳＡ署名の確認を示す。ハッシング機能とは、「一方向」、つまりハ ッシュ結果から文書を再構築することが実行不可能であるように、そして「衝突 がない」、つまり同じ摘要にハッシュする別の文書を作成することが実行不可能 となるようにする別の複雑な数学アルゴリズムである。図７に示されるように、 送信者は最初に、メッセージ摘要７４を作成するためにハッシングアルゴリズム ７３を使用してメッセージ７２を渡してから、摘要を自分のＲＳＡ秘密キー７５ を用いて暗号化し、メッセージ７２に添付される簡潔なディジタル署名７４を形 成する。図８に示されるように、受取人は、メッセージ７２の伝送およびメッセ ージ摘要７６を受け取った後で、送信者のＲＳＡ公開キー７７を使用して、送信 者のＲＳＡ暗号化されたメッセージ摘要７６（ディジタル署名）を復号化する。 また、受取人は同じハッシングアルゴリズム７３を使用して、受信したメッセー ジからメッセージ摘要７４を作成する。受取人が実行する２つの変換の結果生じ る２つのメッセージ摘要は同一でなければならず、このようにしてメッセージが 送信者により署名された旨を確認する。 ディジタル署名アルゴリズムの略でＤＳＡと呼ばれるディジタル署名の別のシ ステムも、送信者の確認に使用できる。ＤＳＡアルゴリズムは、本明細書に全体 として参照として取り入れられる米国特許出願第０７／７３８，４３１号に開示 された。ＤＳＡアルゴリズムは、送信者がメッセージ摘要を作成するためにハッ シングアルゴリズムを介してメッセージを渡してから、自分の秘密キーを使用し てメッセージ摘要を暗号化または署名し、受取人は、送信者の公開キーを使用し て暗号化された摘要を確認するという点で、ＲＳＡ署名アルゴリズムの特性に類 似する特性を有する。しかしながら、受取人が暗号ブロックを復号化するときに 元のメッセージ摘要を戻すＲＳＡ署名アルゴリズムとは異なり、ＤＳＡ確認アル ゴリズムの結果、署名の妥当性の明確な確認だけが生じる。意図された受取人の 公開キーを使用して暗号化された通信は、受取人の対応する秘密キーを用いた復 号化により、後で復旧することはできない。このため、ＤＳＡアルゴリズムは、 ディジタル署名にはきわめてうまく使用できるが、キー転送または直接メッセー ジ暗号には使用できない。 公開／秘密キーシステムが効率的に動作するために、ユーザは、集中キー認証 権威を信用して、公開暗号化キーのディレクトリの公開および更新に責任を持た せなければならない。キー認証権威は、すべてのユーザ、つまり送信者と受取人 の両者により信用され、メッセージが意図されていない受取人に伝送されないよ うに、すべてのユーザの正しい公開キーを配布しなければならない。この目的の ため、認証を行う権威は、前記および以下に詳説するように、各ユーザの氏名お よび公開暗号化キー情報を配布し、情報の正しさを認証する目的で独自のディジ タル署名を配布された情報に付けるであろう。しかしながら、認証プロセスに複 数のエンティティ、つまりエンティティの階層が関わっている場合、ユーザがど のようにして認証を処理するのかを判断するには複数の異なる方法論または「信 用モデル」がある。３つの主要なモデルとは、（１）純粋階層モデル、（２）複 数の階層間の相互認証を使用するモデル、および（３）「ローカル信用」モデル である。これらのモデルは、全体として本明細書に参照として取り入れられる、 規格文書である米国国家規格（American National Standard）Ｘ９．３０、「投 資情報サービス機関業界向け不可逆アルゴリズムを使用する公開キー暗号法：第 ３部：ＤＳＡの認証管理」（米国銀行業者協会、１９９２年、ワシントンＤ．Ｃ ．）に詳細に説明される。まだ前記の信用モデルの内どれが最良かという点に関 する一般的なコンセンサスはないが、本開示を通して、適切な、一般的に認めら れる認証信用モデルは、複数のエンティティにより発行される認証が必要となる 場合に常に確立され、固守されると仮定される。 前記公開／秘密キーシステムは、通信を個人として送受することを希望するユ ーザのプライバシーの利害を考慮する。ただし、さらに、考慮しなければならな い政府の法の施行および国家安全保障上の利害も存在する。政府がさもなければ 秘密の電子伝送を法の施行ならびに国家安全保障上の目的でモニタまたは盗聴す る能力は、怪しいと考えられる犯罪者、テロリスト、および外国の諜報部員が法 の手の届かないところで陰謀を練ることができないようにするために、守られな ければならない。電話通信は電話に盗聴器を仕掛けることによりモニタできるが 、暗号化アルゴリズムは、暗号化されたデータを強力な暗号破壊コンピュータに よっても復号化できないようにする。したがって、高度アルゴリズムを用いて暗 号化されたディジタル伝送およびディジタル化された伝送の量およびパーセンテ ージの増加は、特に暗号化デバイスが電話、コンピュータ、ファクシミリ機械お よびそれ以外のすべてのデータ処理装置に幅広く実装される場合、これらの通信 の法律の認める政府による電子的な監視を挫折させたり、妨害する役割を果たす ことになるであろう。 政府または他の権限を持つ調査官が疑いのかけられた犯罪者の通信をモニタす る一つの方法とは、暗号通信のすべてのユーザに、民間の権威または政府のどち らかにその秘密復号化キーを寄託する、つまり民間の当事者または政府のどちら かがユーザの復号化キーの信頼された記憶者となることができるようにする必要 がある。監督のために必要な場合には、それから政府は、すべての暗号化された 通信をモニタするために、秘密キーにアクセスするまたはアクセスできるように なる。ただし、この方法は、秘密復号化キーの政府による濫用、および政府また は民間の当事者からの盗難、または政府または民間の当事者の担当者の違法行為 のどちらかにより、許可されていない第三者に対し秘密復号化キーが漏れる可能 性があることに対して講じられる保護手段が不十分であるため、うまく行かない 。 プライバシーの利益および法の施行による安全保障上の利害の両方を守るため に、秘密復号化キーを寄託するもう一つの方法とは、その両方とも参照により本 明細書に取り入れられる、１９９３年３月にＣＲＹＰＴＯ９２のシルビオ・ミカ リ（Silvio Micali）により提案され、１９９３年１０月１３日にマサチューセ ッツ工科大学のコンピュータ科学研究所により出版された「公正な公開キー暗号 システム」、および米国特許第５，２７６，７３７号に記述される方式のような システムを使用することによる。図９〜図１１に示されるこの方式によって、暗 号化する目的で自分の公開キーを認証することを希望するユーザは、以下に示す やり形で自分の秘密キーを寄託しなければならない。図９に示されるように、ユ ーザは、まず自分の秘密キー９１を、そのそれぞれが個々に完全な秘密キー９１ の有効な一部であることを検証することができる複数の「部分」９２に分解する 。秘密キーは、すべての部分またはその内のいくつかの指定された数を知らない 限り再構築することはできない。その次に、ユーザは、図１０に示されるように 、特殊なアルゴリズムを使用して秘密キーの正しい部分として、その部分を確認 し（９５）、この確認９６をマスタ寄託センタに通信する、別の寄託代理人また は機関９４に各部分を送信する（９３）。図１１を参照すると、秘密キーの各部 が正しい旨の確認９６、９７を受け取ってから、マスタ寄託センタは、ユーザの 公開キー９９に対する認証９８を発行し、それが秘密システムで、必要がある場 合および令状または裁判所の命令に従う場合にのみ、法を施行する機関が、ユー ザが選択した寄託代理人から秘密キーの秘密の部分を入手し、それらを組み合わ せし直し、そのユーザの通信をモニタすることができるという保証を持ちつつ、 使用できるようにする。このシステムにより、ユーザは、自分達の暗号化された 伝送のプライバシーを保証され、政府は、必要が申し立てられた場合には暗号化 された伝送へのアクセスを得るその能力を保証される。どのエンティティも通常 は完全な秘密キーにアクセスを持たないため、およびユーザが自分で信用するエ ンティティを選択するため、非合法的な行為あるいは不正行為の確率は大幅に削 減される。また、寄託代理人として適格となるエンティティの範囲が広がるため 、すべての寄託代理人を同時に危険にさらし、それによりすべての信頼されてい る取引を混乱させることはさらに少なくなる。 ユーザの公開キーの確実性を認証する信頼された権威としてのマスタ寄託セン タは、公開暗号化キーとその所有者の識別情報のつながりを認証または公証する 公けに利用可能な認証を定期的に発行する。確実性の認証は、その指定された公 開キーユーザに対する伝送が、実際に、意図された受信者だけに受信され、読ま れる旨を送信者に保証する。認証は、通常、ＣＣＩＴＴ勧告Ｘ．５０９に指定さ れ、国際標準化機構（ＩＳＯ）により国際規格として発行されるような国際的に 認められた電子形式を取る。公開暗号化キー寄託認証形式の例は、図１２に示さ れる。認証の中には、とりわけ認証を作成した組織またはキー管理センタ（発行 者）１２１の名称、所有者の公開キー１２２、所有者の識別情報１２６、認証連 続番号１２３、および有効開始日付および終了日付１２４が含まれる。発行者の ディジタル署名１２５が認証に「捺印」し、その改変を防止する。 ただし、米国政府は、政府（およびおそらく業界の）規格として、政府が秘密 復号化キーを寄託し、通信をモニタできるようにする別の方法を提案した。米国 政府は、政府および商業的に生産されたの電話およびコンピュータデバイスに内 蔵可能な「クリッパーチップ」と呼ばれる超小型回路を開発した。クリッパーチ ップは、大量の暗号およびキー管理に使用できる低価格のチップである。キャッ プストーンチップはクリッパーチップをさらに高度にしたバージョンで、ディジ タル署名およびメッセージ摘要機能が付け加えられる。他の暗号システムと同様 に、クリッパーチップは、スキップジャックと呼ばれる電話とディジタルコンピ ュータデータ通信をＤＥＳに類似したやり方ではあるが、８０ビットキーを使用 してスクランブルする機密扱いのアルゴリズムではあるが、対称暗号アルゴリズ ムを使用する。各クリッパーチップには一意の連続番号、すべてのクリッパーチ ップに共通のクリッパーファミリキー、およびチップを内蔵するデバイスにより 符号化されるメッセージを復号化する目的で許可された政府機関により必要とさ れる独自の対称秘密デバイスキーが設定されている。チップを内蔵するデバイス の製造時、一意の秘密デバイスキーは（「キー分割部」と呼ばれる）２つの構成 部分に分割され、政府内で設立される２つのキー寄託データベースまたは機関に 別個に預託される。警察、検察、法執行機関（以下、総称して警察と称する）は 、通信に盗聴装置を仕掛けたり、モニタするための令状または他の法的な権威を 得たり、２つの寄託機関に令状を提示することにより、これらの秘密デバイスキ ーに対するアクセスを得ることができる。 クリッパーチップデバイスのユーザは、通信を希望する場合、最初に、それを 用いて通信を暗号化する対称セッションキーに合意する。対話型ディッフィー・ ヘルマン・キー導出プロセスのような対称セッションキーを引き出す任意の方法 、およびＲＳＡ転送のようなユーザ間でＤＥＳセッションキーを転送する任意の 方法を使用することができる。各通信開始時に、各ユーザは、他方が、警察が通 信に盗聴装置を仕掛けたり、モニタできるようにするほどの情報が含まれる警察 アクセスフィールド（ＬＥＡＦ）を送信する。クリッパーＬＥＡＦの考えられて いる形式が、図１３に示される（ＬＥＡＦ形式の正確な詳細、作成、および検証 は、現在、米国政府により機密扱い「秘密」されているため、この説明および図 １３はともにある程度推論的であることに注意する）。ＬＥＡＦを形成するには 、秘密デバイスキーを使用して、セッションキーが最初に暗号化される。それか ら、デバイスキーで暗号化されたセッションキー、送信者デバイスの連続番号お よび元の暗号化されていないセッションキーのチェックサム（確認値）は、ＬＥ ＡＦを完了するために、ともにクリッパーファミリキーで暗号化される。その次 に、メッセージは、選択されたセッションキーを使用して暗号化される。セッシ ョンキーで暗号化されたメッセージおよびファミリキーで暗号化されたＬＥＡＦ は、ともに受取人に伝送される。受信側ユーザは、ＬＥＡＦが有効であるかどう か、およびＬＥＡＦ内で暗号化されたセッションキーが以前に受信されたセッシ ョンキーと一致するかどうかを確認する目的で、通信を受信するとすぐに、まず 受信されたＬＥＡＦを自分のクリッパーチップの中にロードする。ＬＥＡＦが有 効である場合には、クリッパーチップは、以前に受信された、選択されたセッシ ョンキーを用いてメッセージを復号化する。 しかしながら、通信に合法的に盗聴装置を仕掛けたり、モニタする警察はセッ ションキーを知らないため、まずセッションキーを入手するためにＬＥＡＦを復 号化しなければならない。機関は、希望されるＬＥＡＦに割り込み、クリッパー ファミリキーを使用してＬＥＡＦを解読してから、ＬＥＡＦからのチップ連続番 号および裁判所により命令された令状またはそれ以外の合法的な権威を政府寄託 機関に提示し、代わりに、盗聴装置を仕掛けられたユーザの秘密デバイスキーの ２つのキー分割部を受け取る。機関は、２つの寄託されたデバイスキー構成部分 を結合し、その結果として生じるデバイスキーを使用して、デバイスキーにより 暗号化されたセッションキーをＬＥＡＦから復号化する。それから、セッション キーは、通信からの実際のメッセージの復号化に使用できるようになる。各ＬＥ ＡＦは同じ通信媒体上での複数のユーザ間で渡されると考えられるため、送信者 および受信者がそれぞれＬＥＡＦを作成し、他者のＬＥＡＦの妥当性を確認する という要件により、警察が、ＬＥＡＦ割込み時に相応な確率を持つことが保証さ れる。さらに、これにより、警察は、どのユーザが通信を始めたかに関わりなく 、そのユーザが作成したＬＥＡＦを復号化することにより一人の疑いがかけられ たユーザだけを選択してモニタすることができる。 残念なことに、米政府のクリッパーチップ提案には、大部分は寄託される秘密 キーが製造の間にクリッパーチップに恒久的に埋め込まれるという事実から生じ る多くの技術的な問題がある。ある特定のデバイス用の秘密暗号化キーがチップ に焼き付けられ、変更できないため、危険にさらされた場合には、チップおよび おそらくチップを内蔵するデバイス全体が廃棄されなければならない。ある特定 のデバイスのユーザは、危険にさらされる疑いがある場合または潜在的な危険を 回避するために定期的な間隔で、デバイスを随意にキーボードから再入力したり 、寄託し直したり、認証し直すことができる方が望ましい。ユーザがキーボード から再入力できなかったり、寄託し直せない場合だけではなく、クリッパーデバ イスのユーザは、自分の秘密キーを保護するために、政府により利用されるキー 寄託代理人の数やアイデンティティの選択肢は持たない。代わりに、秘密キー分 割部が政府が設立した２つの寄託データベースまたは機関に預託される。ユーザ は、政府がデバイスを介して任意の伝送またはトランザクションに完全なアクセ ス、濫用あるいは変造されるアクセスを持つ可能性があるというリスクのため、 クリ ッパーチップデバイスを信用できない。また、ユーザが、自分達の秘密キーがさ らに安全となるようにするために、キーが、政府が提供する以上の受託人に寄託 されることを希望する場合もある。キー寄託の概念が重要性を持つ必要がある場 合には、各ユーザは、自分の秘密キーを寄託する自分独自の受託人を、希望する 信用レベルに基づいて選択できなければならない。 また、政府のクリッパーシステムは、ユーザが、対称的に、リアルタイムで通 信できるようにし、蓄積転送電子メール型のメッセージ通信に対する直接的なサ ポートは提供しないと考えられている。通信を暗号化する前に、送信者および受 取人は、それを用いてまず通信を暗号化する対称セッションキーで合意しなけれ ばならない。通常、このキー交換は、クリッパーチップによりサポートされると 考えられる唯一のキー交換方式である対話型ディッフィー・ヘルマン法を使用し て実行される。したがって、ユーザは、独自のキー管理システムを整備すること を希望しない限り、リアルタイムの音声通信やファクシミリ通信のような同時対 話型通信に制限される。しかしながら、蓄積転送電子メール型メッセージ通信を 使用するためには、ユーザは、意図された受信者が対話型オンライン通信に応じ られない場合にも、認証型ディッフィー・ヘルマン法または認証型ＲＳＡキー転 送法を使用するなどして、意図された受取人の公開キーにアクセスできなければ ならない。政府のクリッパーシステムがこれを容易にしないと考えられているた め、蓄積電子メール型のメッセージ通信は困難である。このようにして、政府の 提案した標準システムは、ユーザの通信機能をオンライン対話に限定する傾向に ある。 さらに、政府のシステムの下では、ユーザの雇用者は、その従業員の暗号化さ れたデータや伝送にアクセスできない。従業員が、その代わりに内密のまたは独 占データを開発、通信、または伝送している雇用者は、従業員のデータまたは伝 送に対するアクセスを得る権利を保有しなければならない。暗号化された情報を 、暗号システムの使用に直接的に関与している特定の従業員だけしか利用できず 、従業員に責任を持ち、法人データリソースを所有する経営陣または重役会が利 用できない多くの状況が発生する。データや通信を暗号化することにより、従業 員は、まったく雇用者が知らない状態で、新しいプログラム、製品または技術を 開 発あるいは自分自身に使用したり、違法活動およびトランザクションを行うこと がある。また、スタッフの移動や再構成および記憶施設の変更により、暗号化の 時点で暗号化するほど重要であった大量の情報が失われる結果となる場合がある 。参照により本明細書に取り入れられる、ドン・Ｂ・パーカー（Donn B．Parker ）の「暗号とビジネス情報の無秩序」（１９９３年１１月３日〜５日、バージニ ア州、レストンでのコンピュータと通信機密保護に関する第１年次ＡＣ会議での 招待スピーカーのプレゼンテーション）を参照する。データの作成者または伝送 の送信者とは別に、クリッパーチップを使用すると、政府だけが伝送にアクセス できるようになる。雇用者が、従業員の通信をモニタする目的で裁判所が発行し た令状を求める可能性があるが、雇用者が嫌疑が生じた場合にいつでも連邦捜査 を開始することにより、より慎重なやり方で内部役員のモニタを希望する場合が ある。 さらに、チップに埋め込まれているため、ハードウェア内だけで利用可能で、 政府が許可したチップ製造メーカーからのみ入手できる機密扱いのアルゴリズム を強制すると、政府が、急速に変化を遂げ、通信およびコンピュータハードウェ アの競争が激化した市場の中に参入することになる。政府機関または政府が許可 した製造メーカーは、民間の製造メーカーが行うように、特定の企業向けに特別 に作られる高度なデバイスおよび製品を設計したり、販売できない、あるいは自 発的に設計したり販売しない場合がある。政府が、一定のベンダーだけが機密扱 いアルゴリズムを備えたチップを製造するのを許可する場合、競争は少なくなり 、技術が他の製品に取り入れられるのが妨げられるであろう。さらに、スキップ ジャックアルゴリズムの詳細が公にされていないため、その設計者による見落と しあるいは政府によるバイパス侵入手段の慎重な導入のどちらかが原因で、アル ゴリズムが不安全であるのかどうかに関する疑念が生じた。暗号システム設計の 重要な価値とは、暗号化されたメッセージのプライバシーおよび機密保護が、シ ステムの詳細の秘密にではなく、関連するキー値の秘密に依存するべきであると いう点である。 したがって、公開されたアルゴリズムを使用し、ユーザの信用および信頼を鼓 舞し、国家安全保障および警察の要求により提起された問題点を解決する商業的 なキー寄託システムを提供することが望ましい。 また、ユーザが随意にまたは定期的な間隔で変更できる秘密キーを利用する商 業的なキー寄託システムを提供することも望ましい。 さらに、ユーザが、自分の秘密キーまたは秘密キーの別個の部分を守るために 、キー寄託代理人を選択できるようにする商業的なキー寄託システムを提供する ことが望ましい。 無制限な政府によるアクセスに対する保護手段を含むが、ユーザの雇用者また は外国のユーザがその市民である国によるアクセスを可能とする商業的なキー寄 託システムを提供することも望ましい。 また、米国政府が提案したクリッパーチップシステムの代替策を提供する商業 的なキー寄託システムを提供することも望ましい。 発明の開示 本発明の第１の目的は、公開されたアルゴリズムを利用し、ユーザの信用およ び信頼を鼓舞する方法で動作し、国家の安全保障および警察の要求により提起さ れる問題点を解決する商業的なキー寄託システムを提供することである。 本発明の第２の目的は、ユーザが随意にまたは定期的な間隔で変更できる秘密 キーを利用する商業的なキー寄託システムを提供することである。 本発明の第３の目的は、ユーザが、自分の秘密キーまたは秘密キーの別個の部 分を守るためにキー寄託代理人を選択できるようにする商業的なキー寄託システ ムを提供することである。 本発明の第４の目的は、無制限の政府によるアクセスに対する保護手段を具備 するが、ユーザの雇用者または外国のユーザが市民である国によるアクセスを可 能とする商業的なキー寄託システムを提供することである。 本発明の第５の目的は、米国政府が提案したクリッパーチップシステムの代替 策を提供する商業的なキー寄託システムを提供することである。 本発明の以上の目的およびそれ以外の目的は、ユーザの秘密暗号化キーを構成 部分に検証して分割し、それらの構成部分を特定のユーザが選択した信用された 代理人に送信するための、ミカリ（Micali）「公正」寄託方式のような暗号化キ ー寄託システムを提供することにより、および自己認証も行うチップデバイス により施行される現代的な公開キー認証管理を利用するシステムを提供すること により、本発明の原則に則って達成される。本発明の実施例では、新しいチップ は、一定の条件が満たされた場合にのみ、つまり、（１）有効な「送信者認証」 および有効な「受取人認証」が入力された場合で、この場合「有効な」とは、特 定のユーザの秘密復号化キーが指定された数の寄託代理人に認証できるように寄 託されたことと、マスタ寄託センタがチップ製造メーカーにより登録され、認証 されることを意味する場合、ならびに（２）有効なメッセージ制御ヘッダが送信 者により作成され、受取人により確証されることにより、許可された捜査官がそ れをもって寄託されたキーを要求し、入手する十分な情報を得る場合にだけ暗号 化または復号化を行う。本発明は、認証管理のシステムに依存するため、純粋な オンラインシステムとは異なり、ロケーションおよび時間に関係なく、本発明を 非常に柔軟にすることができる。秘密暗号化キーを寄託し、寄託認証を受け取る ための方法は、本明細書において、信用されたデバイスを信用された第三者で登 録し、デバイスが他の信用されたデバイスと通信できるようにするその関係者か らの許可を受けるというさらに一般化されたケースにも適用される。 さらに望ましい本発明の実施例は、複数のユーザにより使用される非対称暗号 化キーを信用された寄託センタで寄託するステップと、前記複数のキーのそれぞ れを寄託センタで確認するステップと、前記複数のキーのそれぞれの許可を確認 時に認証するステップと、前記認証を条件として前記複数のキーのそれぞれを使 用して前記複数のユーザのそれぞれから通信を開始するステップを構成する、複 数のユーザの間での認証できる信用される通信を作成するための方法を実現する 。さらに、本発明の実施例は、許可された警察機関による、各通信で入れられる メッセージ制御ヘッダの使用に基づいた通信の復号化、特殊な警察デコーダボッ クスの使用、警察およびそれ以外の役人による濫用を妨げるため、警察による盗 聴装置の監査も実現する。さらに好ましい実施例は、認証システムを使用したデ バイスのキーボードからの再入力およびアップグレード、およびストリーム指向 データの暗号化を実現する。 図面の簡単な説明 本発明の前記の目的およびそれ以外の目的ならびに優位点は、参照文字が全体 を通して類似した部分を参照する添付の図面に関連し、以下に詳細な記載を考慮 すると明かになるであろう。 図１Ａ〜図１Ｇは、本発明の図面で使用される記号および省略語のリストであ る。 図２は、従来の技術による対話型ディッファー・ヘルマン・キー導出法のステ ップを示すフローチャートである。 図３は、従来の技術による認証型ディッファー・ヘルマン法の認証部分のステ ップを示すフローチャートである。 図４は、従来の技術による認証型ディッファー・ヘルマン法のメッセージ通信 部分のステップを示すフローチャートである。 図５は、従来の技術によるＲＳＡ転送法を使用した暗号化のステップを示すフ ローチャートである。 図６は、従来の技術によるＲＳＡ転送法を使用した復号化のステップを示すフ ローチャートである。 図７は、従来の技術によるＲＳＡ転送法を使用した署名作成のステップを示す フローチャートである。 図８は、従来の技術によるＲＳＡ転送法を使用した署名確認のステップを示す フローチャートである。 図９〜図１１は、従来の技術によるミカリキー寄託プロセスのステップをとも に示すフローチャートである。 図１２は、従来の技術による公開暗号化キー寄託認証の書式の例である。 図１３は、クリッパーデバイス警察アクセスフィールド（ＬＥＡＦ）の考えら れる書式の例である。 図１４は、本発明のデバイスの製造メーカーにより発行されるデバイス認証の 書式の例である。 図１５は、唯一の寄託代理人にキーを認証できるように寄託する方法のステッ プを示すフローチャートである。 図１６は、信用されたデバイスだけに基づいて、認証できるようにキーを寄託 する方法のステップを示すフローチャートである。 図１７は、メッセージ制御ヘッダ（ＭＣＨ）で暗号化されたメッセージを送信 する方法のステップを示すフローチャートである。 図１８は、ＲＳＡキー転送書式でのＭＣＨの例である。 図１９は、ＭＣＨで暗号化されたメッセージを受け取る方法のステップを示す フローチャートである。 図２０は、ＭＣＨデコーダボックスおよびそのプロセスフローのフローチャー トの例である。 図２１は、自己認証を行う信用されるタイムスタンプデバイスの例である。 図２２は、本発明のデバイスの製造メーカーにより発行されるデバイス所有者 認証の書式の例である。 図２３は、本発明のデバイスの所有者によりキーを寄託し直す（再キー入力す る）方法のステップを示すフローチャートである。 図２４は、信用された第三者による本発明の信用されたデバイスの登録のため の方法のステップを示すフローチャートである。 発明を実施するための最良の形態 以下、図面を参照して本発明の実施例を説明する。 ディジタル署名の利用を含む、公開キー暗号システムは、国のあるいは世界的 な書類を使用しないペーパーレス電子文書システムの作成の基礎となる可能性が ある。これらのシステムの利用は、コスト節約という観点で莫大な商業的な意味 を持つことになるであろう。これらのシステムの開発および普及の重大な要素と は、政府、銀行、企業および個人ユーザを含むそれ以外のユーザによって基礎と なる暗号システムおよびディジタル署名に置かれる信頼である。これらのシステ ムに対する信頼は、各ユーザの独自の社内システムに対するまたはそれ以外のユ ーザに対する信頼から生じるのではなく、各ユーザの公開キー暗号システムおよ びそれが提供する認証機構に対する信頼から生じるべきである。本発明による商 業的な暗号システムは、自己認証を行う、したがって信頼された暗号デバイスを 信用の公明正大な仲裁人として利用することによりこれらの懸念を静める。 本発明の好ましい実施例では、暗号化、復号化およびディジタル署名を実行す る、不正に動かせないようにされたチップ、またはチップを内蔵する不正な動き を防止した信用されたデバイスに、そのチップに一意な修正不能公開／秘密署名 キーペアおよび「製造メーカーの認証」が埋め込まれている。埋め込まれた製造 メーカーの認証は、チップを内蔵するデバイスが（ａ）専用の秘密デバイス署名 キーを使用して、ディジタルで文書および通信に「署名」し、それらがそのデバ イスから一意で創作されたことを認証できるようにし、（ｂ）製造メーカーの認 証を文書および通信に添付することにより、創作するデバイスが既知の信用され たタイプの内の１つであり、その信用された製造メーカーにより作成されるため 、それらのデータ構造が信用できることを認証できるようにする。実際に、製造 メーカーの認証には、「その秘密キーが本書で認証される公開キーと一致するデ バイスはＸＸＸである。署名済み、製造メーカー」と記載される。秘密署名キー は不正な動きを防止するように埋め込まれているため、および製造メーカーが信 用されているため、デバイスにより発行され、秘密署名キーを使用して署名され る文書および通信も信用されることになる。 本発明の好ましい実施例には、以下に示す８つの重要な利用段階がある。 （１）デバイスに内蔵されるチップの作成または製造、（２）デバイスの暗号化 キーの寄託代理人での登録、（３）ユーザメッセージの正常な暗号化および復号 化、（４）許可された警察機関による通信の復号化、（５）所有者または雇用者 によるデバイスの再キー入力およびアップグレード、（６）警察盗聴装置の監査 、（７）ストリーム指向データの暗号化、および（８）国家安全保障保護手段。 信用されたデバイスの製造 本発明の信用されたデバイスの製造は、以下に示す一般的な特徴の存在に基づ く。 （１）埋め込み型マイクロプロセッサ（またはマイクロコントローラ）、すべ ての外部アクセスを取り次ぎ、さまざまな計算動作およびプログラミング動作を 実行するマイクロコンピュータ。 （２）標準的な数学暗号化動作および復号化動作を汎用マイクロプロセッサが 実行するよりはるかに高速に実行することが可能で、暗号化キー作成に必要とな る認証できる無作為番号の作成を補助するために、ダイオードノイズソースのよ うなハードウェアノイズソースを具備することが望ましいオプションの暗号コプ ロセッサ。 （３）ステータスディスプレイまたはモニタを具備することがある、マイクロ プロセッサとの間でのデータおよびコマンドのフローの処理を補助するための入 出力インタフェースまたはサブシステム。および、 （４）それぞれが、（ａ）恒久的かつ変更不能プログラムおよびデータを記憶 できる読取り専用メモリ（「ＲＯＭ」）、（ｂ）半恒久的なプログラムおよびデ ータを記憶できる、つまり変更可能ではあるが、停電時または電気が遮断された ときにも失われない電気的消去可能ＲＯＭ（「ＥＥＰＲＯＭ」）、すなわち「フ ラッシュ」メモリ、および（ｃ）一時的な計算および一時的なデータ記憶に使用 できるが、電気が遮断された場合には失われてしまうランダムアクセスメモリ（ 「ＲＡＭ」）のような耐久性およびアクセス可能性のさまざまな特徴を持つ複数 の種類のメモリ記憶装置技術を利用する可能性があるメモリサブシステム。 デバイス全体は、特に恒久的および半恒久的なメモリ領域を含む、すべてのそ の要素がその内容を明かにしたり、その動作モードを変更する可能性がある不正 な動きから保護されるように、設計および製造される。デバイス要素を不正な動 きから保護する一つの方法とは、被覆剤の下にある情報を破壊することなく除去 することが困難な特殊被覆剤を使用することによる。さらに、メモリ領域の物理 的なエンクロージャに対して改変が試みられる場合、あるいはデバイスの内部防 御機構の動作を停止し、破壊しようとして、デバイスを異常に低温に冷却するな どの疑わしい行為が発生する場合に、メモリを消去させるそれ以外の機能もある 。これらの保護機能のいくつかは、不正な動きが疑われる場合に、デバイスが重 要なデータを削除するために電気的な処置を講じることができるように、一定し たバッテリ電源を必要とする可能性がある。本発明は、デバイスが不正な動きを しないようにする特定の望ましい方法を指定しないが、デバイス内に記憶される データの許可されていない公開または修正からの許容可能な保護程度を提供する と一般的に見なされている、または見なされる可能性がある既存の技術または将 来の技術に依存する。このような特徴を持つデバイスは、不正な動きが防止され た安全なモジュール（ＴＲＳＭ）と呼ばれる場合があり、その現在の例が、マイ コ トロンクス社（Mykotronx，Inc.）が市販している前記のクリッパー／キャップ ストーンデバイスである。 チップの製造は、多くの主要コンピュータマイクロプロセッサチップ製造メー カーの製造となる可能性がある。製造メーカーは、暗号産業に知られており、チ ップの品質ならびにその製造プロセスの機密保護および保全性に関して信頼され ている製造メーカーであるのが望ましい。 本発明の実施例での使用を目的として製造されるチップは、以下に示す機能を 備えるであろう。まず最初に、チップは、デバイスにより発行されるデバイス署 名の埋め込みデバイス公開／秘密キーペアを備え、この場合、秘密署名キーは読 み取り不能、かつ不正な動きをしない。暗号署名キーは、ＲＳＡのような許容さ れる暗号型となる可能性がある。ただし、ＲＳＡは暗号機能および署名機能の両 方を備え、署名プロセスと暗号化プロセスは隔離することが望ましいので、暗号 署名キーはＤＳＡとなるのが望ましい。また、チップは、埋め込みで、不正な動 きを防止するデバイス署名キーの製造メーカーの認証を具備し、その書式の例は 図１４に示される。チップを内蔵するデバイスは、署名が後記品質を持つ既知の 信用された型のデバイスから創作された旨を認証する目的で、この認証をその署 名に添付できる。 また、本発明の実施例で使用するために製造されたチップは、不正な動きをし ないようにチップ内に埋め込まれる製造メーカーの公開署名認証キーを備える。 製造メーカーの公開署名キーは、ユーザが他者から受け取られたそれらの命令を 、それらの命令が製造メーカーで創作されたのか、あるいは製造メーカーによっ て信用された者により創作されたのかを判断する目的で、それらの命令が製造メ ーカーの秘密署名キーにより作成される有効なディジタル署名を付けているかど うかをチェックすることにより、確認するのに使用できる。また、チップは、他 者から受け取られた命令を確認するためにユーザが使用できる埋め込まれた不正 な動きを防止した公開命令キーも備える。公開命令キーとは、製造メーカーによ り選択されるバンカーズトラスト会社（Bankers Trust Co.）のような、誰か他 の信用されたエンティティの公開キーであることもあれば、信用された国家のま たは世界的な全システムの権威であることもあり、余分な製造メーカーから信 用されたエンティティに対する認証を確認する必要を回避するための「手っとり 早い方法」として使用するために、オプションで製造メーカーによりチップの中 に埋め込まれる。製造メーカーは、製造メーカーが選択し、有能かつ信用されて いると考えるさまざまな適格なキー寄託ハウスの複数の命令キーをインストール する。 さらに、本発明の実施例で使用されるチップは、個人ユーザによるデータおよ び通信の暗号化および復号化のための公開／秘密キーペアを作成する能力を持つ だろう。暗号の暗号化キーは、ＲＳＡのような許容される非対称暗号型となるこ とがある。ただし、暗号化キーは、ディッフィー・ヘルマンであるのが望ましい 。つまり、ユーザの秘密番号が秘密キーであり、ユーザの公開された中間番号が 公開キーであり、これらは、通信の暗号化および復号化に使用されるセッション キーを作成するために、ともに認証型ディッフィー・ヘルマン法で使用される。 このように作成される秘密キーは、次に読取り不能かつ不正な動きを防止したや り方でチップの内部に記憶される。さらに、チップは、いったんそのデバイスの 公開／秘密暗号化キーペアが作成されてしまうと、以前のキーペアの代わりに、 新しい公開／秘密暗号化キーペアをキーボードから再入力し、作成する機能も備 えるであろう。別の実施例では、対話型ディッフィー・ヘルマン・キー作成は、 後記のように、すべての送信者および受取人が新しい無作為番号をメッセージセ ッションキーの作成に寄与することを保証する目的でも使用できる。 本発明の好ましい実施例では、信用されたデバイスは、２つの条件だけで暗号 化された通信を復号化する機能を持つことになる。第１条件とは、送信側デバイ スおよび受信側デバイス両方の有効なマスタ寄託センタ認証が、デバイスが暗号 化された伝送を受信する前に、デバイスの中に供給されるということである。各 認証は、そのデバイスの秘密復号化キーが一人以上の適格な寄託代理人、できれ ば認証可能なキー分割プロトコルを利用する二人以上のミカリスタイルの代理人 に寄託されていることを認証するマスタ寄託センタにより署名されている場合は 有効である。このマスタ寄託センタ認証は、指定されたマスタ寄託センタを有効 な寄託代理人として立証する製造メーカーにより発行される別の認証が添付され るか、あるいは製造メーカーによりチップ内部に埋め込まれる公開命令キーの保 持者として指定される第三者（信用されている国内または世界での権威）により 署名されなければならない。復号化の第２条件とは、警察または雇用者の機密保 護担当者がそこから受信者の寄託された秘密キーを入手し、それで通信をモニタ するのに十分なデータを持つように、復号化対象のメッセージの前に有効なメッ セージ制御ヘッダ（ＭＣＨ）データフィールド（その書式については後述する） が先行しなければならないという点である。 本発明の別の実施例では、チップは、デバイス署名に使用される埋め込み型の キーペアとは別に、ユーザ署名に使用される公開／秘密キーペアを作成する能力 を備える。デバイス署名キーペアの場合と同様に、暗号ユーザ署名キーは、ＲＳ Ａのような許容できる暗号型となるが、ここでも、メッセージ暗号化に使用され るキーとの考えられる混乱を回避する目的で、ＤＳＡであるのが望ましい。ユー ザ署名秘密キーは、読取り不能かつ不正な動きが防止されたものでなければなら ない。ユーザは、署名秘密キーを使用して、送信者の確認および否認をなくす目 的で、自分の通信に署名する。本発明の別の実施例においては、チップは、それ がユーザ向けに作成された旨のユーザ公開署名キーの認証の要求に署名すること により、ユーザ署名キーペアが既知の不正な動きを防止した特性のデバイスによ り作成され、秘密キーが既知の不正な動きを防止した特性のデバイスにより保護 されていることを認証する目的で、デバイス署名キーを使用する能力も備える。 本発明の別の実施例では、チップは、キー作成中に無作為番号を作成するための ダイオードノイズソースのようなハードウェアノイズソース、およびデバイスま たはその動作を経理システム、ネットワーク管理システム、および在庫システム で追跡調査できるようにする一意の物理デバイス連続番号も備える。この実施例 においては、デバイス署名は、ユーザのデバイスが既知の不正な動きを防止する 特性を持つ旨だけではなく、デバイスにより作成されたあらゆるキーつまり無作 為番号が、ダイオードノイズソースが望ましい高品質無作為番号生成プログラム を使用するたびに新規に無作為に作成されたことを認証する。 本発明のチップを内蔵する信用されたデバイスを製造する上で、チップのメモ リは、少なくとも以下に示す３つの一般的な領域に分割される。（１）製造中に チップに埋め込まれるデータおよびファームウェアを記憶する恒久的、かつ修正 不能なメモリスペース、（２）データおよびキーがディジタル署名を行ったり、 ユーザの代わりに復号化するために利用されることがあるが、デバイスの外には 決して発表されることのない、ユーザのために作成され、チップによりユーザ用 に委託される秘密暗号化キーおよび署名キーなどのデータを記憶する半恒久的か つ修正可能なメモリスペース、および（３）さまざまなデータ処理動作の入力、 中間結果、および最終結果を一時的に記憶するために使用される作業領域を含む 恒久的ではなく、一時的なメモリスペース。設計に応じて、これらの３種類の一 般的な領域は、恒久的なデータの場合はＲＯＭ、委託されるユーザデータの場合 はＥＥＰＲＯＭまたはＦＬＡＳＨメモリ、揮発性の一時記憶領域の場合はＲＡＭ のように、それぞれ異なる種類のメモリ記憶装置システム内に常駐する。別のア プローチは、恒久的および恒久的ではないデータの両方にＦＬＡＳＨメモリを利 用することである。しかし、別のアプローチは、マイクロプロセッサのメモリを オブジェクトのディレクトリを使用して管理するチップ運用システムを活用する ことである。このアプローチの場合、メモリの一部をテーブルやメモリ内の他の アイテムのディレクトリ専用とすることが可能で、各オブジェクトに以下のよう な標準化された情報を入れられる。 −論理名（例えば、「製造メーカーの公開キー」） −種類（例えば、キー、認証、コードルーチンなど） −開始アドレスおよび（バイト単位の）データ長 −前回の修正日付（オプション） −保護レベル（恒久、ユーザ、または揮発性） −発表レベル（外部で読取り可能、または外部で読取り不能） このようにして、メモリ全体が等しく不正な動きを防止する場合には、マイク ロプロセッサは、データオブジェクトの関連するディレクトリエントリに記憶さ れるコードに基づいて、容易に希望のレベルの保護を施行できるため、保護デー タまたは未保護データに特殊な領域を指定する必要はない。この手法は、データ に当てはまるのと同程度に容易にファームウェアコードルーチンにも当てはまり 、デバイスやそのメモリユニットのいずれかを物理的に交換する必要なく、信用 されたファームウェアコードルーチンを更新したり、置換する場合に、優位に適 用 できる。 本発明の好ましい実施例のデバイスの保護されたメモリ領域には、データおよ びファームウェアプログラムコードの両方を含む、以下に示す種類の情報が記憶 される。 Ａ．製造メーカーにより恒久的に埋め込まれた情報 １．外部で発表できる ａ．全システムの権威の公開キー（オプション） ｂ．製造メーカー公開キー ｃ．全システムの権威からの製造メーカー認証 ｄ．デバイス公開キー ｅ．製造メーカーからのデバイス認証 ｆ．デバイス専用連続番号 ｇ．ファームウェアバージョン番号 ｈ．信用された銀行公開命令キー ２．外部で発表できない ａ．デバイス秘密署名キー ３．ファームウェア ａ．オペレーティングシステムおよびファイルシステム ｂ．基本暗号ライブラリルーチン ｃ．寄託システムルーチン ｄ．その他の信用されるアプリケーションコード Ｂ．ユーザの動作により作成され、ユーザのために委託される １．外部で発表できる ａ．ユーザの公開暗号化キー ｂ．ユーザの公開暗号化キー寄託認証 ｃ．ユーザの公開署名キー ｄ．ユーザの公開署名キー認証 ２．外部で発表できない ａ．ユーザの秘密暗号化キー ｂ．ユーザの秘密署名キー Ｃ．他の不揮発性読書き記憶領域（オプション） ａ．通信者の署名認証 ｂ．通信者の寄託認証 ｃ．通信者のデバイス認証（ＭＣＨ確認用） Ｄ．作業領域（揮発性である場合もある） 公開キー（全種）、認証（全種）、ハッシュ値、署名ブロック、それ以外の処 理中のデータ構造 キー寄託プロセス 本発明のチップが製造され、チップを通信の暗号化または復号化に使用する前 に、ユーザの公開暗号化キーは、マスタ寄託センタまたはチップ製造メーカーに より承認される寄託代理人で登録されていなければならない。ユーザはこの動作 を自身で実行するか、あるいは製造メーカーが、製造中のチップを初期化し、寄 託代理人で登録し、そのためユーザを自分のキーを自身で寄託するという要件か ら解放される。ただし、製造メーカーは、依然としてユーザに後の時点で自身で キーボードから再入力するというオプションを残して置く。多くの個人ユーザに とって、再キー入力オプションが付いているかどうかに関係なく、製造メーカー がチップを登録できるようにすることで十分であろう。さらに、消費者は、必ず やチップ製造メーカーが選択した寄託代理人を信頼するであろう。企業や他の雇 用者は、自分のチップおよび従業員のチップをプログラムし、チップを自分自身 で選択した寄託代理人で登録する。ただし、前述したように、それにより企業情 報および資産の管理が失われる結果となるため、通常、企業はその従業員が独自 に再キー入力することは許さない。 復号化キーを作成、登録するために、ユーザ（または動作を実行するあらゆる エンティティ）は、チップの中に埋め込まれ、チップに、ミカリキー寄託方式ま たは使用される特殊なキー寄託方式の特定のステップを実行するように命令する ファームウェアプログラムを呼び出す。図９〜図１１、図１５、および図１６を 参照する。一人以上の寄託代理人に秘密キーを寄託するために選択される方法を 使用して、チップは、まず、（それらの番号が他の以前の無作為な作成によりす でに設定されていない場合に必要となるそれ以外の公開番号だけではなく）その ユーザの秘密復号化キーとなる秘密番号を無作為に作成または選択する。チップ は、読取り不可能かつ不正な動作が防止されたやり方で秘密キーを記憶する。図 １５に示されるように、秘密復号化キーは、単独の寄託代理人に寄託できる。信 用されるデバイス１５０は、まず、公開／秘密暗号化キーペア１５１をユーザの ために作成してから、寄託センタ１５３に、暗号化され、署名された、暗号化キ ーペア１５１およびデバイス連続番号１５４から構成されるメッセージ１５２を 、署名確認のため製造メーカーの認証１５５とともに、送信する。寄託センタ１ ５３は署名を確認し、メッセージパケットを復号化し、ユーザの秘密復号化キー を記憶する。寄託センタ１５３は、ユーザに、ユーザのデバイス連続番号１５４ 、ユーザの公開暗号化キー１５１、およびデバイスの公開署名認証キー１５７か ら構成される署名された認証１５６を、署名確認のために、寄託センタの認証１ ５８とともに送信する。ユーザのデバイスがいったん寄託センタの署名を確認す ると、登録は完了する。 秘密キーが二人以上の寄託代理人に寄託される場合には、チップは、特殊な公 式に従って、秘密キーをキー分割部と呼ばれる複数の場所に分ける。前述され、 図９に図示されるミカリ寄託方式およびアルゴリズムを使用すると、チップは次 に、各値が秘密キーの場所９２の内の１つの数学的な変換に基づくように、特殊 なミカリアルゴリズムを使用して、一定の値９０を計算する。それから、チップ はユーザが指定する各受託人または寄託代理人９４ごとに１つの共用パケットを 形成し、各共用パケット９３は、ユーザのデバイスの一意の連続番号、１つの秘 密キー分割部、および受託人に完全な秘密キーの知識を与えなくても、特定の受 託人が、完全な秘密キーの有効な一部として、受信された秘密キーを確認できる ようにするある種の値のセットを含む。後述するように、ユーザがデバイスの所 有者ではないが、例えば雇用者−所有者の従業員である場合、雇用者−所有者が 最初に令状を取得する必要なく、従業員−ユーザの秘密キーを入手できるように 、受託人の共用パケットには、デバイスの所有者の一意の識別番号、およびデバ イスの所有者の認証も含まれるであろう。その次に、チップは、一意のデバイス 秘 密署名キーを使用して各受託人共用パケットに署名し、チップを伝送するために 製造メーカーの認証を添付し、それにより伝送された情報が既知の信用されたタ イプのデバイスから創作されたことを認証する。最後に、チップは、信用された 寄託代理人に対するユーザによる送達のため、それぞれの署名済み受託人共用パ ケットを出力するであろう。 ミカリ方式を使用しなくても、信用されたデバイスだけを頼りにすることによ り、マスタ寄託センタが別個のキー分割部を確認する別の望ましい方式がある。 図１６に示されるキー分割部を確認するこの方式を使用すると、チップは、秘密 暗号化キーのキー分割部ごとに１つの無作為番号を作成する。その次に、チップ は、ユーザが指定した各受託人または寄託代理人１６３ごとに１つの共用パケッ ト１６１を形成し、各パケットには、ユーザのデバイスの一意の番号、１つの秘 密キー分割、および無作為番号の内の１つが含まれる。チップは、一意のデバイ ス秘密署名キーを使用して各受託人共用パケットに署名し、伝送側チップに製造 メーカーの認証１６２を添付し、それにより伝送された情報が既知の信用された 種類のデバイスから創作されたことを認証する。ミカリ方式での場合と同様に、 チップは、信用された寄託代理人１６３に対するユーザによる送達のために、各 署名済み受託人共用パケット１６１を出力する。さらに、チップは、各寄託代理 人にキー分割部で指定された無作為番号に加えて、とりわけユーザの公開暗号化 キーおよびユーザが指定した寄託代理人の名前を含んだ、マスタ寄託センタ宛て の（暗号化された）メッセージも作成しなければならない。 しかしながら、各受託人共用パケットには秘密キー分割部が含まれるため、ユ ーザから寄託代理人への通信にアクセスする第三者が、ユーザのすべての共用パ ケットの内容を読み、完全な秘密キーを組立し直すために、それらのパケットな いで秘密キー分割部を結合し直すことが考えられる。その場合、秘密キーを使用 して、その第三者は、ユーザの名前で通信の復号化および暗号化を行うであろう 。この状況を回避するのに最良な方法とは、ユーザから寄託代理人に共用パケッ トを送信する際に、暗号化された通信システムを使用することである。ユーザは 、各認証が、マスタ寄託センタにより署名され、特定の寄託代理人がマスタ寄託 センターに信用され、キー分割パケットを受信し、記憶することを認証するユー ザ の秘密キーを寄託するために選択された各寄託代理人の公開暗号化キー認証１６ ６を入手してから、デバイスの製造メーカーから（または全システムの権威から ）の認証を使用するか、あるいは事前に埋め込まれた命令キーを使用して、マス タ寄託センタの署名を確認する。それから、デバイスは、その代理人の認証され た公開暗号化キーに基づき、寄託代理人ごとに、ユーザの使用キー共用パケット を含む伝送１６１を暗号化する。代わりに、製造メーカーが、前記のように、ユ ーザが、通常はマスタ寄託センタである、命令キーの保持者により信用される寄 託代理人に自分の使用キー分割部を送るため、それぞれに対して命令キーと突き 合わされた、複数の信用された寄託代理人の公開暗号化キーをチップの中に埋め 込むことができる。このようにして、マスタ寄託センタのすべての寄託代理人ま たは製造メーカーの「ファミリ」は、すべての寄託代理人の公開暗号化キー認証 を入手するという負担をユーザにかけずに、寄託に対するユーザの要求を復号化 する。 いったん寄託代理人、つまり受託人１６３が、ユーザまたはユーザのデバイス から適切な共用パケット１６１を受け取ると、受託人はユーザのデバイスから受 託人共用パケット１６１内で受け取られた使用キー分割部を検査し、マスタ寄託 センタ１６５とともに、それが完全な秘密キーの有効かつ正しい部分であること を確認する。寄託代理人およびマスタ寄託センターは、ユーザの秘密復号化キー の断片が実際に預託されたことを認証または確認する信頼できる手段を持つ必要 がある。キー分割部の確認は、一度もそれらの断片を検査したり、所有しなくて も、または一度もそれらをいっしょに１つのロケーションに持ち込まなくても、 寄託代理人およびマスタ寄託センタにより達成されるのが望ましい。ミカリ「公 正」寄託システムは、寄託センタがキー断片の別個の預託部分を確認するための １つの高く信用された方法を実現する。図１０および図１１に示されるミカリ方 式では、この確認は、特殊なミカリアルゴリズムを使用することにより共用パケ ットの作成中にユーザのチップにより計算され、寄託代理人に対する各共用パケ ット内にキー分割部とともに含まれたある種の値のセットを用いて実行される。 ミカリアルゴリズムおよびキー分割部の確認は、技術で既知であり、本明細書で 繰り返す必要はない。それから、各受託人９４は、デバイスの製造メーカーの認 証を、復号化の際に後で使用するために記憶し、ユーザの氏名およびデバイス認 証とともに適切な署名済みのメッセージ９６をマスタ寄託センタに送信し、キー 分割部９０に署名し、記憶することにより、キー分割部９３を承認する。（ａ） 令状または裁判所の命令、または（ｂ）デバイスの合法的な所有者からの署名付 き要求のどちらかを提示された場合にのみ、受託人は、所有している指定された 秘密復号化キーの１つの部分（または複数の部分）を明かにするであろう。 図１６に示される、信用されたデバイスだけに頼る望ましい寄託確認方式を使 用すると、各受託人１６３は、ユーザの氏名、公開暗号化キー、デバイス番号、 およびそれが受け取った無作為番号を識別するメッセージ１６７を、マスタ寄託 センタ１６５に伝送する。さらに、ユーザデバイスは、秘密キー分割部の確認に 使用される無作為番号を含むパケットをマスタ寄託センタ１６５に送信し、その パケットは、マスタ寄託センタの公開暗号化キーを使用して暗号化される必要が ある。マスタ寄託センタ１６５は、ユーザデバイスおよび受託人１６３からのメ ッセージ１６４、１６７を受け取り、各受託人から受け取った個々の無作為番号 が、記述されたユーザデバイスがその受託人に指定された無作為番号に一致する か確認する。この方法では、寄託代理人１６３およびマスタ寄託センタ１６５が 、寄託が適切であることを自らに保証するために、共用パケット１６１上の信用 されたデバイスの署名だけを信頼することに注意する。この寄託確認方法は、寄 託が適切であるか、または認証のために提示された公開キーが預託されたキー断 片と一致するかを確認する目的で、二次的な数学的な演算を実行する必要はない 。公開、ユーザまたは全システムでの信用という見地からは、依然として、ミカ リプロセスのような認証可能なキー寄託アルゴリズムを活用することが望ましい が、このようなプロセスの使用により増加したコストを正当化できない場合には 、これは明らかに必要ではなく、免除することができる。さらに、信用されたデ バイスだけを頼るこの方法により、指定された法の正しい性能を検証するために 複雑な二次的なアルゴリズムを考案する必要はないため、考案可能なキー分割法 の複雑さに対する制限はない。ファームウェアコードを埋め込むデバイスの製造 メーカーの保全性を信用し、デバイスが不正な動きをしないことを信用するだけ が必要である。 すべてのユーザの秘密キー分割部を確認した後で、マスタ寄託センタ自体が、 さらに、すべてのユーザの受託人に承認された秘密復号化キーに対応する公開暗 号化キーを承認する。マスタ寄託センタ１６５は、認証される公開キーに対応す る秘密キーが、適切なやり方ですでに寄託されたことを認証する、（マスタ寄託 センタ認証、公開暗号化キー認証、または単に寄託認証と呼ばれる）署名付きの 認証１６８を発行することにより、公開キーを承認する。デバイスの製造メーカ ーの認証から得られるユーザのデバイスの公開署名キーも、マスタ寄託センタ認 証の中に入れ、それによりプロセスの後の時点でデバイス製造メーカー認証を送 信したり、確認し直す必要性を排除する。マスタ寄託センタ認証は、以下に示す ようにフォーマットされることがある。 バージョン番号 寄託認証連続番号 マスタ寄託センタ国コード マスタ寄託センタ名 マスタ寄託センタ公開暗号化キー（ＬＥＡＦを作成する際に使用するため） ユーザ識別名 （これにより認証される）ユーザ公開暗号化キー （デバイス署名を確認するための）ユーザデバイス公開署名認証キー 有効日付（開始／終了） マスタ寄託センタ署名 ［マスタ寄託センタ全システム認証］ マスタ寄託センタにより発行された公開暗号化キー認証は配布され、デバイス 所有者がデバイスを起動し、暗号化されたメッセージを始めるために使用される か、あるいはそれ以外の者が、そのユーザの公開／秘密暗号化キーペアを含むデ バイスの所有者に対するメッセージを暗号化するために使用できる。 本発明では、二人以上の寄託代理人がユーザの秘密暗号化キー分割部の受取人 になる必要はないことを注記する必要がある。ユーザの秘密復号化キーを単独の 寄託代理人（または寄託センタ）に預託するだけで十分な場合もある。ただし、 ユーザおよび社会のシステムに対する信用を高めるためには、ユーザのキーを組 立し直し、通信を復号化する目的ですべてのキー分割部または指定された数のキ ー分割部が必要となるように、ユーザの秘密復号化キーを複数の寄託代理人の間 で分割することが望ましい。さらに、各寄託代理人が独立した信用されるビジネ スオペレーションであり、それにより違法行為、賄賂、恐喝または濫用が試みら れた場合には、秘密キーが単独のエンティティに記憶されている場合より、ユー ザの秘密復号化キーを不法に入手することがはるかに困難になるように、「分割 知識」を達成することが望ましい。また、エンティティは、破壊や違法行為の試 みをさらに抑圧する目的で、地理的に分けられていることが望ましい。 通信の暗号化 別のユーザに暗号化された通信を送信することを希望するユーザは、自身のデ バイスの寄託認証および意図された受取人の公開暗号化キーの寄託認証を持たな ければならない。これは、本発明のデバイスが、そのどちらかが欠けている場合 、暗号化も復号化も行わないためである。最初に、送信者は、自身の有効な認証 を、一般的にはそれをマスタ寄託センタから初めて受け取る場合に、デバイスの 中にロードしなければならない。その後は、意図された受取人の公開キー認証は 、意図された受取人から直接的に、キー認証をリストするディレクトリサービス から、あるいは送信者が以前に暗号化された通信を交換した相手のユーザのファ イルなどの送信者のローカルファイルからのいずれかで入手できる。本発明の１ つの実施例においては、受取人のデバイスが暗号化されたメッセージを解読する ために、受取人の公開暗号化キー認証が有効ではない限り、送信者のデバイスが 暗号化を行わず、受取人のデバイスが復号化を行わないため、受取人の公開暗号 化キー認証は（ａ）受取人のデバイスの製造メーカー（デバイス製造メーカーは 、おそらく寄託として受託するユーザの秘密キーとはならないため、これは起こ りそうもないケースである）、（ｂ）マスタ寄託センタ、およびマスタ寄託セン タを有効な受託人として承認する製造メーカーの認証が添付されるか、（ｃ）そ の命令キーが製造中にデバイスの中に埋め込まれた受託人またはマスタ寄託セン タのいずれかにより署名されなければならない。受取人の公開暗号化キー認証に 規定される意図された受取人の認証された公開暗号化キーを使用して、送信側ユ ーザは、 通信の暗号化および復号化を行うために、送信者と受取人の両者によって使用さ れるためのセッションキーを作成する。このセッションキーは、、むしろ認証型 ディッフィー・ヘルマン方式、または代わりに同等な他のシステムを使用して作 成できる。認証型ディッフィー・ヘルマン方式では、ユーザは、最初に無作為に 、そのメッセージ用の一時的な秘密キーを作成してから、自身の秘密キーおよび 受取人の公開キー（つまり、受取人の中間番号および２つの公開番号で、すべて 受取人の公開暗号化キー認証とともに入れられる）に基づいてセッションキーを 計算する。それから、セッションキーを使用し、送信者は、受取人ユーザに送信 するメッセージを暗号化する。 しかしながら、暗号化されたメッセージを意図された受取人に送信するかどう かを決定する上で、送信者が、送信者のデバイスが受取人のデバイスを使った製 造メーカーと異なる製造メーカーにより作られている場合、受取人の公開暗号化 キー認証の特性またはその上のディジタル書名の特性を確認できない可能性があ る。受取人のデバイスが別の製造メーカーにより作られたという事実により、送 信者のデバイスは、製造メーカーの署名、または受取人のマスタ寄託センタが有 効であり、その製造メーカーにより承認された旨を述べる（受取人のキー寄託認 証に署名したマスタ寄託センターを認証した）製造メーカーの認証のどちらかを 容易に確認できなくなるであろう。同様にして、受取人のチップは、復号化前に 送信者の認証に関するこれらの条件を確認できないであろう。警察が、必ずしも 他のモニタされていない関係者の秘密復号化キーを得ずに、送信され、指定され た疑わしいユーザにより受け取られるメッセージに合法的に割り込み、復号化し 、それによりそのモニタされていない関係者の関連のないメッセージにアクセス できるようにするために、両方の関係者に対する寄託制限の施行が必要となる。 依然として二人以上の製造メーカーが暗号デバイスを製作できるようにしつつ 、この問題を取り扱う一つの方法は、デバイスの中に、またはユーザのマスタ寄 託センタまたはチップ製造メーカーのどちらかによって発行される認証の中に、 連邦準備銀行（ＦＲＢ）が、他のさまざまなマスタ寄託センタや製造メーカーの それぞれに対して発行する別の認証を確認するのに使用される、ＦＲＢなどの信 用のある国家エンティティの公開キーを埋め込むことである。このような認証は 、 特定のマスタ寄託センタまたは製造メーカーの信頼性を確認し、ＦＲＢにより署 名される。したがって、マスタ寄託センタは、ＦＲＢ公開キーまたは認証により 認証されるように、チップ製造メーカーによってではなくＦＲＢに正式認可され たので、送信側ユーザは、意図された受取人の公開暗号化キー認証を入手し、認 証を発行したマスタ寄託センタを信用する。また、ある特定のデバイスの署名は 、ＦＲＢ認証または公開キーにより認証されるように、そのデバイスを認証した 他の製造メーカーがＦＲＢにより正式認可されたため、信用できるであろう。よ り地方的ではない米国ベースのレベルでこの問題を処理し、さらに国際的かつ世 界規模のシステムを促進するために、スイスにある国際決裁銀行のような信用の ある世界的なエンティティの公開キーが、（利用される信用モデルに応じて）信 用されたデバイス、ＦＲＢ認証やマスタ寄託センタ、または製造メーカー認証の 中に埋め込まれ、マスタ寄託センタおよび製造メーカーを世界規模で正式認可す るために、ＦＲＢキーに関して説明したのと同じように動作する。米国または世 界の権威を関与しない方法ではあるが、あるデバイスが別の製造メーカーにより 認証される寄託センタを信用するための別の方法は、デバイス製造メーカーまた はマスタ寄託センターが互いを相互認証することである。これは、送信者のデバ イスが、受取人のデバイス製造メーカーまたはマスタ寄託センタから自身まで受 取人の寄託認証の認証経路を確認できるようにすることにより、送信者のデバイ スが受取人の寄託制限を施行するのを助けることができるようにする。好ましい 実施例においては、全システムベースですべてのマスタ寄託センタおよび製造メ ーカーを正式認可するために、信用のある全システムのエンティティの公開キー が信用されるデバイスの中に埋め込まれ、ＦＲＢや世界的なエンティティのキー に関して前述したのと同じように動作する。 任意のユーザ、エンティティまたはデバイスがディジタルで署名された「認証 」を「確認する」ときは常に、認証を行う権威または製造メーカーにより発行さ れた製造メーカーの認証または寄託認証であろうと、大部分のまたはすべての実 際のおよび提案されている公開キー認証管理システムにおいて、ユーザ、エンテ ィティまたはデバイスが、認証を行う権威または他の発行者が、適切な機密保護 方針に従って更新される取り消された認証のリストを配布、伝搬、またはそれ 以外の場合には利用できるようにするかどうか、および発行者名および認証番号 に基づいて、認証が無効にされたのかどうかを判断する目的で、該当する「認証 無効リスト」（「ＣＲＬ」）もチェックすることは一般的な慣行であり、本開示 中でも想定される。ユーザに発行される認証は、死亡、氏名や職業の変更、また は秘密キーを具備するデバイス（パーソナルスマートカード）の損失、盗難、ま たは破壊のために無効となることがある。エンティティに発行される認証は、商 売の中止、名称の変更、または秘密キーを具備するデバイスの損失、盗難または 破壊が原因で無効とされる場合がある。デバイスに対して発行される認証は、デ バイスの損失、盗難、サービス停止または破壊が原因で無効とされる場合がある 。認証確認中のＣＲＬのチェックは、（ＡＮＳＩ Ｘ９．３０−第３部などの） 公開されている文献に十分に記載され、さらに説明を必要としない。すべてのユ ーザ、エンティティ、およびデバイスは、通常、適切な電気通信施設にアクセス し、希望に応じて、ＣＲＬを検索したり、照会を実行できる。同様に、本発明の 元では、ＣＲＬを発行するすべてのエンティティは、すべての関係する関係者に より利用できると仮定される。 メッセージ制御ヘッダ書式 暗号化された通信を送信する場合、送信側ユーザは、以下の情報が指定される 適当なメッセージ制御ヘッダ（ＭＣＨ）フィールドも形成しなければならない。 （１）それを用いてメッセージが暗号化されたセッションキーを計算するため に送信者によっても使用された、送信者の無作為に作成された一時的な秘密キー を使用して送信者により計算される暗号化されたメッセージの送信者の中間番号 。受取人ユーザは、メッセージを復号化するためのセッションキーを計算する目 的で、この中間番号を備えなければならない。 （２）送信者のマスタ寄託センタの名称および国コード。 （３）受取人の公開キー認証から入手される、受取人のマスタ寄託センタの名 称および国コード。 （４）送信者のマスタ寄託センタだけがそれを復号化できるように、（送信者 の寄託認証から入手される）送信者のマスタ寄託センタの公開暗号化キーを使用 して暗号化される送信者の寄託認証番号。 （５）送信者のマスタ寄託センタに、それを用いて送信者の認証番号が暗号化 される一時的なセッションキーを計算するために、送信者により使用される（送 信者の以前の中間番号とは異なる）送信者の中間番号。送信者のマスタ寄託セン タは、送信者の認証番号を復号化するための一時的なキーを計算するために、こ の番号を持たなければならない。 （６）実際には、送信者が自分自身にメッセージセッションキーを送信するよ うに、送信者自身の公開キー（送信者自体の公開認証の中間番号）を使用して暗 号化された、暗号化メッセージのセッションキー。警察は、いったん送信者の秘 密キー公正要素を送信者の寄託代理人から入手すると、このメッセージセッショ ンキーに対するアクセスを獲得する。 （７）それを用いてメッセージセッションキーが自身に暗号化される一時的な キーを計算するために、送信者により使用された（送信者の２つの以前の中間番 号とは異なる）送信者の中間番号。警察は、送信者のマスタ寄託センタから入手 される送信者の秘密キーも使用して、メッセージセッションキーを復号化するた めの一時的なキーを計算するために、この数を持たなければならない。 （８）受取人のマスタ寄託センタだけがそれを復号化できるように、（受取人 の寄託認証から入手される）受取人のマスタ寄託センタの公開暗号化キーを使用 して暗号化された受取人の認証番号。 （９）それを用いて受取人の寄託認証番号が受取人のマスタ寄託センタに従い 暗号化された一時的なキーを計算するために送信者により使用された（送信者の 過去の３つの中間番号とは異なる）送信者の中間番号。受取人のマスタ寄託セン タは、受取人の認証番号を復号化するための一時的なセッションキーを計算する ためにこの番号を備えなければならない。 （１０）追跡調査の目的、および令状の施行日付のおよび時間的な制限事項を 補助するための、タイムスタンプ（オプション）。 （１１）送信者のデバイスの署名。 （１２）送信者のマスタ寄託センタにより発行される送信者の公開キー寄託認 証。送信者の寄託認証には、マスタ寄託センタが事前に確認してから、送信者の デバイスの製造メーカーの認証から複写した送信者のデバイス公開署名キーが入 る。 （１３）受取人のチップが別の製造メーカーにより作られている場合、送信者 の寄託認証に付加される、ＦＲＢ、製造メーカー、または信用されるあらゆる全 システム権威のマスタ寄託センタの認証。製造メーカー、ＦＲＢまたは全システ ム権威の認証は、２つの関係者の間の初めての通信にだけ必要とされる。認証は 、受取人の製造メーカーまたはマスタ寄託センタの相互認証である場合もある。 このように記述されるＭＣＨは、以下の通りに要約される。 （受取人がメッセージを復号化できるようにする）送信者中間番号 送信者マスタ寄託センタ国コード 送信者マスタ寄託センタ名 受取人マスタ寄託センタ国コード 受取人マスタ寄託センタ名 送信者マスタ寄託センタ向けに暗号化された送信者寄託認証番号 （送信者認証番号を暗号化するための）送信者中間番号 送信者用に暗号化されたメッセージセッションキー （送信者に対するメッセージセッションキーを暗号化するための）送信者中 間番号 受取人マスタ寄託センタのために暗号化された受取人寄託認証番号。 （受取人認証番号を暗号化するための）送信者中間番号 タイムスタンプ 送信者デバイスＭＣＨ署名 ［送信者寄託認証］ ［寄託センタ認証］ 図１７は、ＭＣＨで暗号化されたメッセージ１７６を送信するためのプロセス を示す。ＭＣＨ１７２全体（付加される認証１７３、１７４、１７５は技術的に ＭＣＨの一部ではない）は、デバイス秘密ＤＳＡ署名キーを使用して、送信者の デバイス１７１により署名され、製造メーカーの埋め込まれた認証が、デバイス の公開署名キーを認証する目的で（送信者の寄託認証内で）そこに添付される。 これにより、ＭＣＨ全体が元のまま受取人に送達され、受取人のチップが、ＭＣ Ｈが修正されていないことを容易に確認できるのが保証される。製造メーカーの 認証には、国家（ＦＲＢ）の認証または世界的な権威の認証が添付され、受取人 のデバイスが別の製造メーカーによって製造される場合には、送信者のチップの 製造メーカーの信頼性を認証することがある。 本発明の別の実施例では、第２のより短いＭＣＨ書式が、完全なプライバシー が重大ではないケースに使用できる。このＭＣＨでは、送信者認証番号も受取人 認証番号も、各マスタ寄託センタに対しては暗号化されない。認証番号を暗号化 しないことで、ＭＣＨの作成でのかなりの時間とスペースが節約される。この発 明の別の実施例では、第３のさらに短いＭＣＨ書式が、ＥＣ１をＥＣ２と同一に することにより、送信者と受取人の両者が同じマスタ寄託センタをキー寄託プロ セスのために活用する共通のケースに使用できる。ＭＣＨ内での、第２マスタ寄 託センタの情報を識別する必要性、および第２マスタ寄託センタに受取人認証番 号を暗号化するために使用される特殊中間番号の必要性を排除することにより、 ＭＣＨは大幅に短縮できる。さらに、ＭＣＨのサイズは、ＲＳＡキー転送を使用 し、メッセージおよび３つの暗号化された内部ＬＥＡＦ構成要素のそれぞれにＤ ＥＳキーを暗号化することにより、さらに縮小できる。この方法に従って、各送 信者中間番号は、さらに小型のＲＳＡ包装済みＤＥＳキーにより置換される。し たがって、送信者は、受信者のメッセージセッションキーをＲＳＡ暗号化し、Ｍ ＣＨでの初めての中間番号の必要性を排除する。また、送信者は、（実際には、 警察が後で復号化するために）自身にメッセージセッションキーをＲＳＡ暗号化 し、したがってＭＣＨ内での第３の中間番号の必要性を排除する。送信者は、さ らに、自身の認証番号および受取人の認証番号をＲＳＡ暗号化し、したがってＭ ＣＨ内での第２中間番号および第４中間番号の必要性を排除する。図１８に示さ れるように、４つの中間番号およびその関連暗号を排除し、各中間番号をより小 さなＲＳＡ転送暗号１８１で置換することにより、ＭＣＨサイズのかなりの量の スペースが節約される。 無作為材料への寄与 ＲＳＡキー転送方式または認証型ディッフィー・ヘルマン法だけを使用して交 換されたメッセージセッションキーが、これらの２つの方式のどちらかを使用す ると、送信者と受取人の両者が情報を提供するが、メッセージセッションキーを 作成するのは送信者だけであるため、十分に安全ではないと懸念する人もいる。 しかしながら、安全な通信の軍事規格の元では、明らかに、送信者が弱いキーを 使用したり、同じキーを繰り返し使用し、それにより受信者を望ましくない意志 に反した機密保護リスクにさらす確率を減らすために、送信者と受取人の両者が 、各通信セッションの前にセッションキーを作成する際に無作為材料を寄与しな ければならない。本発明で考えられた信用されたデバイスのシステムは、この恐 れを２つのやり方で緩和できる。第１に、システムは、送信側デバイスが、前述 したように、反転バイアスダイオードのような内蔵ハードウェアノイズソースの ノイズから引き出される無作為番号を使用して別個に各キーを作成することを保 証することができる。次に、デバイスがＭＣＨ、つまりメッセージ制御ヘッダに 署名する限り、受取人は、各メッセージセッションキーおよびその作成に使用さ れる無作為番号が強力かつ一意であることを保証される。機密扱い情報用のタイ プ−１軍事システム用に定義されるように、さらに高い機密保護を主張する人達 が、依然として、通信の両側による無作為材料の寄与を要求する可能性がある。 この開示中ここまで、送信者は、通信のセットアップ段階中に受取人から受け 取られる無作為材料に基づいてではなく、自分の寄託認証に記載されるように、 受取人の公開暗号化キーに基づいてメッセージセッションキーを作成するとして 記述されてきた。しかしながら、送信者が受取人から寄与を受け取るように調整 することにより、新しい問題が生じる。受取人は、単に、独自にディッフィー・ ヘルマン中間番号を作成し、メッセージセッションキーを作成する際に使用する ためにそれを送信者に送信してはならない。これは、その場合、受信者がメッセ ージを復号化するために、自分の信用されたデバイス内で寄託された秘密キーを 使用しなくなるため、およびその通信が警察により決してモニタされないためで ある。寄託法の施行で継続的な成功をおさめるには、送信者も受取人も、登録さ れた信用されたデバイスを使用しないでメッセージを読み取ることができない必 要がある。 送信者と受取人の両者が、通信前に、メッセージセッションキーに無作為材料 を寄与する状況を可能とするためには、初期のキー交換プロトコルが、見せかけ の受取人のデバイスが、別個でありその受信者の寄託された秘密キーと離れた、 代わりにメッセージの暗号化のためにメッセージセッションキーの計算に使用す るために送信者に送信される新しい中間番号の計算に使用される新しい一時的な ディッフィー・ヘルマン秘密番号を作成できるようにするために修正される。受 取人の寄託された秘密キーは、依然として、ＭＣＨのさまざまな部分の暗号化に 使用される中間番号および一時的なセッションキーの作成に使用されるだろう。 しかし、この修正には、新しい秘密番号の作成が見せかけの受取人のデバイス内 で発生すること、この新しい秘密番号が信用されたデバイス内にとどまること、 および新しい中間番号が、新しい一時的な秘密番号が実際には受取人のデバイス 内に安全にとどめられていることを認証する目的で、送信者のデバイスに送信さ れる前に、見せかけの受取人の装置により署名されることが必要になる。以前と 同様、送信者のデバイスは、別個で送信者の寄託された秘密キーと離れた新しい 秘密番号を作成し、その新しい秘密番号および受取人の新しい中間番号を使用し て、メッセージの復号化のためのメッセージセッションキーを作成する。また、 送信者のデバイスは、送信者の新しい秘密番号を使用して、盗聴装置を仕掛ける 目的でＭＣＨの要素として受取人のデバイスに送信される、送信者の新しい中間 番号を作成する。したがって、この方式では、メッセージセッションキーは、希 望に応じて、送信者と受信者両者により寄与される無作為材料を含む。 ただし、この修正されたキー交換プロトコルの下では、受取人および送信者が 実際に新しいディッフィー・ヘルマン秘密キーを各メッセージに使用するので、 警察および企業経営陣が寄託代理人からそれらの一時的なメッセージセッション キーを決して入手することができないように、寄託機能はやはり「消える」。し たがって、寄託システムのニーズおよび利害のあるコミュニティーは、メッセー ジセッションキーが以前同様ＭＣＨ内で転送されることを必要とする。実際、傍 受の平等を保証するために、以前ＭＣＨの一部として発表されたすべてのフィー ルドはそのままとなる。（メッセージを読み取るために送信者に盗聴装置を仕掛 ける警察の唯一の方法である）メッセージセッションキーを送信者に転送するフ ィールドは、傍受の平等の原則を守る目的で、ＭＣＨの中に依然として含まれな ければならない。メッセージセッションキーは、以前同様、送信者の公開暗号化 キーを使用して、警察が依然としてアクセスを持つ、ＭＣＨの中に暗号化される 。送信者の新しい中間番号は、警察が受取人に盗聴装置を仕掛、メッセージセッ ションキーを計算できるようにするために、依然同様、ＭＣＨの最初の要素とし て、受取人に送信される。したがって、対話型ディッフィー・ヘルマン・キー交 換技法を取り入れるためには、このプロトコルは、それが利害のあるコミュニテ ィー（警察、雇用者およびその他）がメッセージを読み取ることができる唯一の 方法であるため、見せかけの受取人の新しい中間番号が、内部で作成され、受取 人のデバイスにより署名されることを必要とし、送信者の新しい中間番号が、以 前述べられたキー転送方式の代わりに使用されるのではなく、ＭＣＨに追加され ることを必要とする。ただし、デバイスが記憶しなければならないこと、つまり 、相手方の特殊中間番号が多すぎるため、この方式は、オンライン電話、ネット ワーク、またはダイヤル呼び出しのトランザクション以外のトランザクションに は経済的ではないであろう。この方式は、純粋にリアルタイムの対話型セッショ ンが希望されるセルラー電話、ネットワークログオンなどで使用されるのが望ま しい。 興味あるヘッダのコミュニティ（共同体） ＭＣＨは、通常、暗号化されたメッセージの前に、メッセージヘッダとしてお かれる。多くの現在の電子メールおよび文書システムでは、複数の受取人が、各 受取人の公開暗号化キーを使用するメッセージセッションキーをＲＳＡ暗号化す ることにより、前記のＭＣＨ設計のＲＳＡ転送実施例を使用する、符号化された １つのメッセージを読むことができる。すなわち、複数の受取人が同じ暗号化メ ッセージを受け取ることを意図される場合、ＭＣＨヘッダには、意図された受信 人のそれぞれに、その受取人の公開暗号化キーを使用して意図された受取人の一 人一人にＲＳＡ暗号化された、メッセージセッションキーが後に続く意図された 受取人の氏名を入れることができる。このようにして、一人一人の意図された受 取人はＭＣＨヘッダ内で自分のエントリを見つけ出し、メッセージセッションキ ーのコピーを復号化し、メッセージを読むことができる。意図された受取人が複 数いる場合でも、ＭＣＨの正しさは、通信の両側で施行される。つまり、送信側 では、ＭＣＨ出力は、送信者のデバイスの内部論理、すなわちそれがメッセージ の暗号化の前に有効なＭＣＨを作成するという要件により施行され、受信側では 、ＭＣＨの正しさは、受信者のデバイスによる送信者のデバイスのディジタル署 名の確認により施行される。以前注記したように、メッセージキーの受取人のコ ピーはＭＣＨに一体化しているので、ＭＣＨ自体がキー転送機構にリンクされて いないクリッパーシステムとは異なり、ＭＣＨが元のまま送信され受信されない 限り、どの受取人もメッセージを復号化することはできない。 このＭＣＨフォーマット概念の元では、ＭＣＨは、図２５に示されるように要 約できる。以前のＭＣＨ書式の場合と同様に、ＭＣＨの確実性は、送信者のデバ イス２５８のディジタル署名により保証される。さらに、以前同様、送信者およ び受取人の寄託認証暗号は、そのそれぞれのマスタ寄託センタ２５１、２５２の 公開暗号化キーの元で暗号化される。ただし、この書式では、送信者のデバイス により署名されるＭＣＨは、現代の暗号化された電子メールシステムの動作様式 に関してより柔軟で、より理解しやすい修正された「受取人のリスト」となる。 例えば、送信者の氏名および受取人の氏名（またはシステムＩＤやアドレス）は 、現在では、ＭＣＨ２５３、２５４の中に暗号化されない状態で示されている。 これは送信者および受取人の匿名性を侵害するが、実際のところ、電子メールシ ステムで、送信者および受取人の氏名とアドレスでメッセージにタグを付けずに メッセージを送信することは困難である。したがって、プライバシーの損失はわ ずかである。さらに、送信者の雇用者および受取人の雇用者２５５、２５６の氏 名（または、納税番号やＤＵＮＳ番号のような独自のＩＤ）も、暗号化しない状 態で示されているため、雇用者の機密保護スタッフのそのそれぞれの従業員によ り送受されるメッセージを見つけるための負担はかなり削減される。代わりに、 送信者名、受取人名、および雇用者名のブロックを暗号化しないままにしておく 代わりに、これらのエントリは、実際の識別子は、以前同様、暗号化された領域 の中にある状態で、「送信者」、「宛先」、「送信者の雇用主」、および「受取 人の雇用主」（またはそれに同等なもの）と読み取られる方がよい。したがって 、通信の意図された受取人は、自分の暗号化されていない識別省略を探してＭＣ Ｈ を覗き、このようにして自分に宛てられ、白分のために暗号化されたＭＣＨの部 分だけを復号化し、読み取ろうとする。 さらに、図２５に示されるこのＭＣＨフォーマットにより、二次雇用者行（ａ 、ｂなど）を定義すれば、雇用者組織内のサブユニットによるアクセスが可能と なる。秘密を意識した雇用者の場合、ＭＣＨは、前記のように、暗号化されてい ない「送信者雇用者サブユニットｂ」と読まれ、暗号化された領域に実際の会社 のユニットが含まれる。各ＭＣＨエントリにはラベルが付けられているため、ど のくらい多くの雇用者アクセスの層が存在できるかに制限はない。つまり、ある い意味では、そのすべてがメッセージの許可された「受取人」となる。さらに、 以前のＭＣＨ書式とは対照的に、雇用者が、メッセージの復号化のためにメッセ ージセッションキーを入手する目的でマスタ寄託センタおよび代理人に行かなく ても済むように、このＭＣＨ書式には、雇用者２５７に対して直接暗号化された メッセージセッションキーを含めることができる。仕事場でのプライバシーに関 する従業員の期待を侵害する可能性はあるが、この書式を使用すると、雇用者は 、最小限の努力で従業員のファイルをチェックまたは復旧することができるよう になる。 通信を送信する前にこの書式でＭＣＨを作成するためには、送信者は、まず、 意図された受取人およびその雇用者のすべての必要な氏名／コードおよび公開キ ーを入手しなければならない。この情報は、受取人の寄託認証および自身の寄託 認証から手に入れることができる。ただし、このアプローチを一般化し、この情 報を通信の送信を希望するユーザが利用できるようにするためには、マスタ寄託 センタが、各ユーザーの標準書式寄託認証の中に、前記のように、雇用者および 雇用者のあらゆるサブユニット両方の一意の識別またはコード番号および公開暗 号化キーを含めなければならない。寄託認証のレイアウトは、可変数の「利害の あるコミュニティー」関係者を効率的に処理するために、反復するサブグループ を使用することにより作成できる。各利害のあるコミュニティー関係者のエント リには、一意の識別番号、公開暗号化キー、および送信者のデバイスにその関係 者のＭＣＨエントリを符号化する方法を命令する命令コード（または後述のよう な方針コード）が設定される。命令コードには、送信側デバイスに（１）暗号化 されていないか、「ｅｍｐｌ−ａ」のような別名を使用する関係者の一意の識別 番号、（２）コーディングされた領域のメッセージセッションキー、または無し 、（３）コーディングされた領域の関係者の一意の識別番号、または無し、およ び（４）コーディングされた領域の初めでのタイムスタンプまたは無作為番号、 または無しを入れるというオプションを与える選択肢の要素が含まれる。これら （およびおそらく他の）命令コードは、ビットマスクフラグとして定義できるで あろう。関係者（またはそのコードあるいはその両方）、その公開暗号化キー、 および命令フラグのリストは、送信者のデバイスに、ＭＣＨの利害のあるコミュ ニティー部分を、各関係者の希望にそって、部分的な匿名性または完全な匿名性 のために、フォーマットする方法を命令する。実際には、多くの利害のあるコミ ュニティー関係者が、自分自身の氏名および識別番号を明らかにしておく場合に その従業員のメッセージを検索し、識別する方がはるかに容易であるため、関係 者が匿名性にはこだわらないことが予測される。 受取人による復号化 意図された受取人が暗号化されたメッセージ１９１およびＭＣＨフィールド１ ９２を受け取ると、受取人がメッセージを読むためには、図１９に示されるよう に、複数のことがなされなければならない。本発明の好ましい実施例では、チッ プは寄託認証なしに復号化を行わないため、まず最初に、受取人は、自身の有効 な寄託認証１９３をチップ１９０にロードしなければならない。通常、受取人の 寄託認証は、事前に確認された状態でデバイスのメモリの中にすでに記憶される 。次に、受取人はチップ１９０に、ＭＣＨ１９２、および（必要な場合には、適 切な全システム、国内、または世界的な権威の認証１９５とともに）送信者のデ バイスの公開署名認証キーも含む送信者の寄託認証１９４をロードしなければな らない。受取人のチップ１９０は、送信者の秘密暗号化キーが寄託されているか どうかを確認する目的で、送信者の寄託認証１９４をチェックする。これは、デ バイス認証上の製造メーカーの署名、または、必要な場合には、寄託センタ認証 上の全システムの権威の署名を確認するために製造メーカーの公開キーを使用し 、送信者の寄託認証上の寄託センタの署名が有効であるかどうかをチェックする こ とにより実行される。好ましい実施例では、直接寄託認証１９５を確認するため に、全システム権威の公開署名キー１９６が使用される。それから、受取人のチ ップは、（１）送信側デバイスが信用されているかどうか、（２）送信者のキー が、送信者によっても確認されるように、寄託として預けられているかどうか、 および（３）ＭＣＨ１９２が有効であるか、つまりＭＣＨが適切な書式を取り、 すべての必要な情報を記載しているうかどうかを確認する目的で先に進む前に、 ＭＣＨ署名をチェックする。これは、送信者のデバイス署名、送信者のデバイス 製造メーカーの認証署名、および必要ならば、製造メーカーの全システム権威認 証を確認することにより実行される。製造メーカーの、および全システム権威の 公開キーは、この確認プロセスを容易にするために、受取人のチップ１９０の中 に埋め込まれる。もっとも単純なケースでは、受取人は、送信者の寄託認証１９ ４を、自身の埋め込まれた製造メーカーの公開キーまたは全システムで信用され るエンティティの命令キーと比較して、一度だけ確証する必要がある。一度これ らがある特定の送信者に対して有効であることが示されると、受取人は、送信者 の事前に確証済みのデバイス公開キーを使用してＭＣＨ署名を確証するだけとな り、その結果メッセージごとに１つの署名確証が行われる。送信者の認証１９４ またはＭＣＨ１９２のどちらかが無効である場合は、受取人のチップはメッセー ジを復号化しない。最後に、これらの認証および署名の確認後、受取人は、送信 者の中間番号に基づき、ＭＣＨの中に含まれたメッセージセッションキー、およ び受取人の公開暗号化キー認証１９３に公開される公開キーに対応する受取人自 身の秘密キー（受取人の秘密番号）を計算する。受取人は、セッションキーを使 用して、送信側ユーザーが送信したメッセージを復号化する。 警察による復号化 ある特定のユーザに対するおよびユーザからの間の通信に割り込み、復号化す る目的で、警察は、その特定のユーザの通信をモニタするための裁判所の許可ま たは令状を得なければならない。裁判所の許可は、十中八九、（１）警察がユー ザの通信のモニタを開始してもよい「モニタ開始」日付および時刻、（２）それ 以降、警察がユーザの通信をモニタしてはならない「モニタ終了」日付および時 刻、およびおそらく（３）その猶予期間中、警察が、さらにそのユーザの追加の 通信に割り込んだり、モニタするためではなく、以前に割り込んだ通信を復号化 するだけのために、ユーザの秘密キーを保持してもよい「モニタ終了」日付に続 く猶予期間が含まれる。送信側ユーザの通信をモニタする際、警察は通信に割り 込み、誰から送信者の秘密復号化キーを要求したらいいのかを判断するために、 ＭＣＨから送信者のマスタ寄託センタの名称および国を識別する。その次に、警 察は、裁判所の許可および割り込んだ通信からのＭＣＨを、ＭＣＨの中に暗号化 された送信者の認証番号を復号化するためにその秘密キーを使用する送信者のマ スタ寄託センタに提示する。送信者のマスタ寄託センタは、送信者の認証番号を 使用して、送信側ユーザの氏名および送信者の寄託代理人の氏名を検索し、警察 が後ほど復号化の間に必要とする送信者のデバイス製造メーカー認証とともに、 そのすべてを警察に明らかにする。それから、警察は、送信者の寄託代理人のそ れぞれに連絡を取り、代理人に対して送信者の氏名および令状を提示し、各寄託 代理人から、送信者によりその代理人に委ねられたキー分割部を入手する。本発 明での警察による暗号化された通信の割込みおよび復号化の望ましい方法は、以 下に指定されるデコーダボックスを使用することによるため、キー分割部が、警 察機関自身に対してではなく、警察デコーダボックスに直接送信できるように、 警察の寄託代理人に対する要求には、警察デコーダボックスの公開暗号化キーも 含まれる。各寄託代理人は、デコーダボックスが令状の条項を実行できるように 、自分が所有する送信者のキー分割部を、「モニタ開始」日付および「モニタ停 止」日付、ならびにオプションの「猶予期間」が設定された暗号化されたメッセ ージとして警察デコーダボックスに送信する。それから、デコーダボックスは暗 号化されたキー分割部メッセージを復号化し、キー分割部を結合し、送信者の組 立し直した秘密キーを使用して、送信者により自分自身に対して送信されたメッ セージとしてＭＣＨの中に暗号化された通信のセッションキーを入手する。した がって、デコーダボックスは、令状に明記されたモニタ期間中のみ、送信者に対 するおよび送信者からの間の通信をモニタし、割り込むことができ、令状に明記 された猶予期間の最後までだけ、それらの割り込んだ通信の復号化を続けること ができる。 類似した手順は、受取人に対するおよび受取人からの間の通信のモニタにも使 用される。割り込まれた通信のＭＣＨから、警察は、受取人のマスタ寄託センタ の氏名および国を識別し、それから令状および割り込まれた通信のＭＣＨを、Ｍ ＣＨに暗号化された受取人の認証番号を復号化するためにその秘密キーを使用す る受取人のマスタ寄託センタに提示する。受取人のマスタ寄託センタは、受取人 の認証番号を使用して、受取人の氏名および受取人の寄託代理人の氏名を検索し 、そのすべてを警察に明かにする。その次に、警察は受取人の寄託代理人のそれ ぞれに連絡を取り、その代理人に対して受取人の氏名および令状を提示する。各 寄託代理人は、受取人ユーザによりその代理人に委ねられたキー分割部を、デコ ーダボックスによる令状の条項の実行のために、「モニタ開始」日付、「モニタ 停止」日付および猶予期間が設定されたデコーダボックスに対して暗号化された メッセージとして、警察デコーダボックスに送信する。それから、デコーダボッ クスは、暗号化されたキー分割部を暗号分解し、それらを結合し、受取人の結果 として生じる組立し直された秘密キーを、通信のセッションキーを計算するため に、各ＭＣＨの先頭にある送信者の中間番号とともに使用する。したがって、デ コーダボックスは、令状に明記されたモニタ期間中のみ受取人に対するおよび受 取人からの通信をモニタし、割り込むことができ、令状に明記された猶予期間の 最後までだけそれらの割り込んだ通信の復号化を続けることができる。 本発明の別の実施例では、各寄託代理人の警察デコーダボックスに対する暗号 化されたキー分割部メッセージの書式は、以下の通りとなる。 ユーザの認証番号 秘密キー断片：Ｘ（ｉ） モニタ開始日付および時刻 モニタ停止日付および時刻 裁判所が許可した猶予期間（日数／時間数） （このキー分割部メッセージの）日付および時刻 寄託代理人署名 ［寄託代理人認証］ この書式では、認証番号以外のすべての情報は、デコーダボックスの暗号化キ ーで暗号化される。寄託代理人からのキー分割部メッセージはその特定のデコー ダボックスに対して暗号化されるため、他のユーザまたはデコーダボックスがそ れらを読むことはできない。さらに、「モニタ開始」および「モニタ停止」日付 および時刻が、デコーダボックスに、いつ通信のモニタおよび復号化を開始する のか、およびいつモニタを停止するのかを命令する。猶予期間により、デコーダ ボックスは、以前に割り込んだ通信のバックログを復号化する追加指定時間期間 を許され、その時間期間後、デコーダボックスは復号化を停止し、対象者の秘密 キーを消去しなければならない。このようにして、デコーダボックスは、その時 点で、デコーダボックスおよびその埋め込まれたタイムクロックによりさらに復 号化が行われないようになる令状に明記される日付までモニタされたユーザの通 信の復号化に使用することができる。デコーダボックスは、１２時間（または他 のなんらかの指定時間期間）以上経過したメッセージ日付および時刻が設定され るか、あるいはすでに過ぎてしまった満了日付および時刻が設定されたキー分割 部メッセージの処理を拒否することもある。 デコーダボックスの実現 本発明の好ましい実施例では、警察は、ある種の定義され、制御された条件下 で、モニタされたユーザの通信に割り込み、復号化するための特殊な不正な動き を防止するデコーダボックスを利用する。デコーダボックスおよびその処理フロ ーの例は、図２０に示される。デコーダボックス２００は、本発明の信用された デバイスのシステム内で類似したデザインを持つ信用されたデバイスとなるよう に設計され、それゆえ、警察による不適切な行為を妨げるためにさまざまな条件 を施行できる。デコーダボックス２００は、製造メーカーにより埋め込まれた秘 密デバイス署名キー、およびデバイス秘密署名キーを突き合わせる公開署名キー の製造メーカーの公開署名キー認証を備える。製造メーカーの認証２０２に加え て、デコーダボックスは、デコーダボックスと警察または機密保護当局の間のつ ながりを認証または公証し、デコーダボックスがその独占的な所有および管理下 にあることを認証する、そのデコーダボックスを所有する警察当局または企業機 密保護部門により（または代わりに）発行される認証２０３を持つ。デコーダボ ックス２００は、デコーダボックスへの管理および制御メッセージの暗号化およ び復号化のために、本発明の通常のユーザチップと同様に、公開／秘密キーのペ アを作成する能力も備える。デコーダボックスは、さらに、その秘密キーを安全 に記憶し、製造メーカーにより署名されたそのデバイス認証２０２が添付された 状態で、それ自体により署名された認証２０１内で対応する公開暗号化キーを発 行する能力も備える。この公開／秘密キーのペアを作成する能力を備えることに より、盗聴装置を仕掛られたユーザの寄託代理人２０６は、警察によりマスタ寄 託センタに対するユーザの通信をモニタするための令状が提示された時点で、そ の盗聴装置を仕掛けられたユーザのキー分割部２０４を、デコーダボックスの公 開暗号化キーを使用して暗号化されたデコーダボックスに送信できるようになり 、デコーダボックスはその秘密復号化キーを使用してそれらのキー分割部を復号 化できるようになる。しかしながら、メッセージを復号化し、暗号化されていな い結果をユーザに戻す本発明の通常のユーザチップとは異なり、デコーダボック スは、盗聴装置が仕掛けられたユーザの秘密キーを警察機関に決して出力しない 。代わりに、デコーダボックスは、令状およびキー分割部メッセージに明記され る猶予期間の最後までこの情報を安全に記憶し、その時点でデコーダボックスは 情報を永久に消去する。 したがって、信用されたデバイスとしてその職務を全うし、盗聴装置を仕掛け る当局により課される日付および時間の制限を実行するために、デコーダボック ス２００は、信用される、較正済みの保証された日付／タイムクロック２０５も 具備しなければならない。する。デコーダボックスの製造メーカーは、製造メー カーがその既知のデバイス特性のリスト付きのデバイス認証２０２を発行すると 、クロックの有効性および較正を認証し、実証する。デコーダボックス２００が 寄託代理人２０７から、（令状に基づき）その前後で令状が有効ではない時刻制 限を含むキー分割部２０４を受け取ると、デコーダボックス２００は、その内部 タイムクロック２０５を使用して、警察令状が依然として有効であることを確認 する。令状が有効ではない場合、デコーダボックスは、盗聴装置が仕掛けられた ユーザの通信のモニタや復号化を行わない。令状（および該当する猶予期間）が 満了すると、盗聴装置が仕掛けられたユーザの秘密キーは消去され、（新しい時 間 期間が設定された新しい令状が発行されない限り）その令状で再びデコーダボッ クスにより作成し直されることはない。信用されたタイムクロック２０５は、本 発明の通常のユーザチップにとってはオプションではあるが、デコーダボックス が、盗聴装置令状の日付および時刻制限を実行できるようにするには、デコーダ ボックス２００にとって必須であることを注記しなければならない。ただし、通 常ユーザチップのユーザは、チップのタイムクロックの較正を維持することによ り、時刻制限の実行を補助することができる。ユーザのクロックが較正されてい ないと、通信中にユーザのデバイスにより作成されるＭＣＨは、タイムスタンプ フィールドにヌル値を指定される。その場合、通信に割り込むデコーダボックス は、令状および猶予期間の満了後、復号化を行うことを拒否することにより、令 状のモニタ停止日付のみを実行することができる。したがって、令状が依然とし て有効である限りは、令状によりヌルタイムスタンプ値が指定されたすべてのＭ ＣＨの復号化が、それらが令状期間のモニタ開始日付および時刻の前に割り込ま れていたのであっても、許可されるため、デコーダボックスはモニタ開始日付を 施行することはできない。しかし、ユーザのクロックが較正されている場合は、 警察デコーダボックスは、令状のモニタ開始日付および時刻前の日付および時刻 に有効かつ信用されたタイムスタンプが設定されるすべてのＭＣＨの復号化を拒 否することが可能で、拒否するであろう。本発明のデコーダボックスは、令状時 間期間中にタイムスタンプされたことが信頼できる通信だけを復号化するのがも っとも望ましい。このように、警察による令状の時間期間の考えられる濫用から さらに免れることが、本発明のチップのユーザが、自分のチップを較正済みの状 態で維持する動機となることが期待される。実際、データ記憶装置システムで多 数のメッセージを暗号化するためにシステムが使用される場合には、後での令状 または開示命令のために時間期間を施行するのがきわめて望ましい。これは、さ もなければ合法的な命令の範囲外にある多くのメッセージが検査の対象となる可 能性があるためである。 警察監査機能 寄託される暗号システムを使用する場合、警察が、高い経済価値を持つデータ を保護する暗号化キーを取得するために容易に買収される可能性があるという懸 念が存在する。例えば、潤沢な資金を持つ犯罪企業体のメンバーが、まずいくつ かのメッセージヘッダおよび寄託代理人名を取得するために不法にその会社の通 信を傍受し、次に低賃金の警察官を買収し、その企業の秘密復号化キーを寄託代 理人から取得するために麻薬捜査の令状を要求し、最後に秘密復号化キーを使用 して計画を盗み出すことにより、ある特定の企業から貴重な産業計画のセットを 盗み出すことができるかもしれない。暗号は現在では多くのコンピュータ間での 安全な通信に使用されているため、警察が最小の保護手段しか持たない電気通信 システムに盗聴装置を設置することは受け入れられなくなった。警察の手順およ び支配を近代的な企業コンピュータ機密保護慣行のレベルまで高め、この種の状 況の発生を防ぐためには、はるかに強力な保護手段のセットが必要とされる。 信用されたデバイスのこのような保護手段の１つは、各メッセージ制御ヘッダ に番号を付けるための内部カウンタであり、このカウンタはアクセスされるたび に順次増加する。メッセージシーケンス番号（ＭＳＮ）は、外部者には見えない ように暗号化された各メッセージヘッダに設定できる。これは、番号を（１）メ ッセージセッションキーの送信者のコピーとともに、送信者の公開暗号化キーの 元で、（２）送信者か受取人どちらかの寄託代理人の公開暗号化キーの元で、あ るいは（３）望ましくは、少なくとも送信者、受信者、および送信者と受信者の 寄託代理人の元で、および可能であれば利害のあるコミュニティー内のすべての 関係者の元でのいずれかで番号を暗号化することにより実行できる。しかし、送 信者の寄託代理人は、方針の問題として、シーケンス番号を、スペースの節約お よびそれを露呈する低いリスクという根拠で、普通文で開示することを可能とす ることを選択することもある。メッセージ制御ヘッダの重複番号を回避するのは 重大であり、番号付けでのギャップもできる限り避けられるべきである。 別の保護手段機能は、ユーザが、メッセージ制御ヘッダの中にオプションの秘 密「タイトル行」を含めるようにすることである。ユーザが不適切な令状での不 法な傍受を恐れる場合、ユーザは、自分自身および他者にメッセージの内容に対 して注意を喚起するために「計画＃１２３」のような短いタイトルを符号化でき る。代わりに、ユーザは、単に、（メールソフトウェアシステムを使用して）デ バイスが割り当てたメッセージシーケンス番号およびユーザが割り当てたタイト ルに関する自分自身のログを記憶することもできる。スペースを節約するには、 たいていの場合そうであるように、タイトルが入力されないならば、タイトル行 が長さゼロとなるであろう。 第３の保護は、ユーザまたは警察のどちらかが、復号化されたメッセージの内 容が実際に送信されたもの以外であると後に主張するのを妨げるために、メッセ ージ制御ヘッダの署名部分に、メッセージの摘要またはハッシュを付け加えるこ とである。つまり、例えば、ユーザは、以前送信された麻薬取引のメッセージを 無害なメッセージで置き換えたり、腐敗した警察役人が、役人が盗んでいた貴重 な産業計画を麻薬取引や無害なメッセージで置き換えることはできないだろう。 これらの保護手段は、追加機密保護処置として利用できる。第一に、送信者の デバイスが作成したメッセージシーケンス番号は、警察と裁判所機構の両方によ ってだけではなく、送信者と受信者の両者により、メッセージを追跡調査するた めに使用される。特に犯罪者の熱心な追求のさなかに、警察のアクセスを効果的 に制御することは困難であるが、および裁判所機構は必ずしも盗聴装置設置許可 を発行する前に警察の要求を注意深く分析することができないが、盗聴装置の結 果、すべての盗聴装置の、盗聴装置の無作為なサンプルの、またはなにかしら異 常と考えられる盗聴装置の結果を監査する目的で事実を求める不断の努力を行使 することができる。したがって、警察の信用されたデバイスであるデコーダボッ クスは、メッセージシーケンス番号およびそれがモニタし、警察により読み取ら れることを許したメッセージのメッセージ摘要（および、存在する場合はタイト ル行）の安全な内部ログを含むように修正される。盗聴装置を仕掛けられたユー ザの寄託代理人により、そのユーザのキー分割部とともにデコーダボックスに送 信される電子許可は、令状を発行した裁判所の公開暗号化キーおよび公開署名キ ーも含むことがある。したがって、デコーダボックスは、おそらく令状を発行し た裁判所などの適切に許可された受取人のキーの元で暗号化されたメッセージシ ーケンス番号およびタイトル行のログを印刷するという要求に応えることができ る。 別の実施例では、デコーダボックスは、寄託代理人から受け取られたキー分割 部に一致する特定の裁判所の命令を受け取るまで、モニタした通信の復号化を開 始しない。例えば、寄託代理人から受け取られ、デコーダボックスの公開暗号化 キーを使用して暗号化されるキー分割部メッセージを、令状を発行した裁判所の 公開暗号化キーおよび公開署名キーを（各寄託代理人から）含むように強化する ことができる。あるいは、寄託代理人は、自分達のキー分割部メッセージの中で 、令状の日付および（存在する場合には）番号を参照し、デコーダボックスが、 裁判所から、元の盗聴装置設置許可に添付されていた裁判所の公開キー認証だけ ではなく裁判所の公開暗号化キーおよび公開署名キーを受け取る。例えば、寄託 代理人に対する裁判所の許可は、キー分割メッセージに必要となる以下に示すデ ータを伝達するように強化することができる。 マスタ寄託センターの名称またはＩＤ番号 モニタされたユーザの認証番号 裁判所の名称またはＩＤ番号 令状番号（存在する場合） 令状の日付および時刻 モニタ開始日付および時刻 モニタ停止日付および時刻 メッセージの最大数（オプション） ［裁判官の署名］ 裁判官の認証 裁判官の証人の認証（例えば、裁判所など） それから、寄託代理人は、寄託代理人からデコーダボックスへの暗号化された キー分割部メッセージに、各寄託代理人からの各キー分割部の中に存在しなけれ ばならない以下の追加情報を入れることにより、デコーダボックスに対する裁判 所の公開暗号化キーおよび公開署名キーを「再認証する」ことがある。 マスタ寄託センタの名称またはＩＤ番号 モニタされたユーザの認証番号 （このキー分割部メッセージを送信する）寄託代理人の名称またはＩＤ番号 裁判所の名称またはＩＤ番号 裁判所公開暗号化キー 裁判所公開署名キー 令状番号（存在する場合） 令状の日付および時刻 メッセージの最大数（オプション） 寄託代理人諸汚名 ［寄託代理人認証］ このようにして、デコーダボックスは、すべてのキー分割部メッセージが同じ 裁判官および同じ令状から生じたという保証を受け取る。 デコーダボックスが裁判官の公開暗号化キーおよび公開署名キーも持つという 事実により、裁判官は、警察の正当化されていない、非合法的な、あるいは違法 行為から保護するための盗聴装置後監査として、盗聴装置期間中にデコーダボッ クスにより割り込まれ、復号化されたすべてのメッセージシーケンス番号および メッセージタイトル行のログを（秘密りに）要求し、受け取ることができる。さ らに、デコーダボックスは、デコーダボックスがそれを行ってもよいと述べる、 以前に受け取られた公開署名に比較して確認される、裁判官または裁判所からの 別個の命令を受け取るまで、モニタされたメッセージログに割り当てられるメモ リを削除、消去、または再利用しない。裁判所がデコーダボックスからすでに、 過去に要求したモニタされたメッセージログを受け取っているため、あるいは裁 判所がこの例では監査は必要とされないと判断したため、このような命令が発行 される。モニタされるメッセージログメモリ記憶装置領域がいっぱいになると、 ログが裁判官または裁判所に送られ、デコーダボックスがモニタされたメッセー ジログを消去することを許可する、裁判所により署名された命令が受け取られる まで、デコーダボックスは、それ以上メッセージを復号化しない。いっぱいにな ったメッセージログが監査のためにクリアされるまで、新しいメッセージは復号 化されないが、警察は、モニタされたメッセージログのクリアまで、新しいメッ セージの割込みを続けることができる。デコーダボックスは、デコーダボックス が復号化を停止しないようにメッセージ監査ログのアップロードを要求できるよ うに、モニタされたメッセージログが容量に近づきつつあることを警察に警告す る機能も備える。以上のトランザクションおよび通信は、完全に自動化され、ほ ぼ瞬間的となる。 監査ログの各エントリには、メッセージの摘要に加えて、（ａ）メッセージ摘 要に（ｂ）共に連結され再編集された以前のログエントリの完全なテキストを加 えたものの結果である第２摘要が含まれる。これにより、不誠実な裁判所職員が ログ中のエントリを追加、削除または配列し直すことを防ぐことができる。この 概念は、本明細書に参照により取り入れられる米国特許第５，３１６，６４６号 および米国特許第５，１３６，６４７号の中で説明される。 フォローアップ処置として、裁判所は、後で、警察が、裁判所が受け取った監 査ログ中のメッセージヘッダおよびメッセージ摘要の完全な内容を提出すること を要求する。また、その盗聴装置設置許可の中で、裁判所は、モニタされたメッ セージログおよびメッセージヘッダが監査されなければならなくなる前に、デコ ーダボックスにより復号化されるモニタされたメッセージの数を、最大メッセー ジログ容量以下に人為的に制限する。監査のためのログの裁判所へのダウンロー ドはほとんど瞬間的なものであるため、この種の制限は警察の総合的な調査能力 には影響を与えないが、裁判所に異常な状況を警告する可能性がある。裁判所に モニタされたメッセージログを単に送信するより強力な管理を必要とする特殊な ケースでは、裁判所は、警察が追加通信をモニタするための新しい令状を求めな ければならなくなる前に、警察を最大メッセージログ容量以下に制限することが ある。 したがって、（１）送信者および受信者の両者が彼らが送受するメッセージの シーケンス番号を追跡調査し、メッセージ制御ヘッダの中のタイトル行を関連付 けるか、あるいはそのローカルソフトウェアシステムの中でメッセージをログす る場合、（２）警察および裁判所の両方が、警察により復号化される各メッセー ジの完全なログを保持する場合、および（３）各メッセージヘッダが、関係者が その行為を隠ぺいするために後でメッセージを改変するのを防ぐためにメッセー ジの摘要を含む場合、信頼できる傍受後の監査が、警察により濫用または違法行 為があったかどうかを判断することができる。このシステムは、前記の計画盗難 シナリオを演繹的に防ぐことはできないが、犯罪企業体がその行為が裁判所およ び対象となるユーザの両方により完全に監査可能であると知ることは、不適切な 警察の行為に対する相当なチェックとなる。また、これは、警察が令状の元で割 り込んだすべてのメッセージを記録し、裁判所に提出し、特に対象が企業体に結 び付いており、その盗聴装置に基づき刑事責任は申し立てられない場合、盗聴装 置が仕掛けられた関係者が盗聴装置の監査を要求することができるという規則の 問題とされる。 ストリーム指向データ 各通信が二人またはそれ以上のユーザからの複数のメッセージパケットのスト リームから構成される電話のようなストリーム指向データに関係する通信では、 送信者デバイスがＭＣＨの一部としてメッセージ全体をハッシュし、署名するこ とは不可能である。通信の各パケットとＭＣＨを送信することは可能であるかも しれないが、そうすると処理時間およびネットワークの帯域幅という点で非常に 費用がかかる。したがって、ＭＣＨは、呼のセットアップ時に一度だけ送信され るべきである。暗号化されたデータの連続ストリームを処理するための望ましい 方法は、発呼者ユーザを「送信者」として指定し、以前同様、メッセージシーケ ンス番号（ＭＳＮ）およびデバイスにより署名される（存在する場合には）第１ パケットのハッシュを含めて、通信開始時にＭＣＨを交渉することである。その 場合、送信者のデバイスは、そのシーケンスが各通信の開始時にゼロから始まる 一連の一意のパケットシーケンス番号（ＰＳＮ）を作成する。それ以降のすべて のパケットに関しては、デバイスはその特定のパケットをハッシュし、署名し、 そのパケットのハッシュ、ＭＳＨ（メッセージ全体の場合と同じ）、およびＰＳ Ｎを含め（署名す）るだけである。着呼者は、通信の発呼者のＭＳＨを参照し、 それ自体のパケットにゼロから初めて連続して番号を付け、着呼者デバイスに、 パケットハッシュ、発呼者のＭＳＮおよび着呼者のＰＳＮに署名させ、それによ り「パケット制御ヘッダ」（ＰＣＨ）を形成することにより、それが送信する各 パケットに対し類似した動作を実行する。デバイスは、すでにＭＣＨの以前開示 されたバージョンの中に存在する、（ミリ秒単位の）通信の最初からのオフセッ トとしての現在時間をオプションで含む。これにより呼をより現実的に再生でき るようになる。 通信後に発呼者のパケットと着呼者のパケットをさらに区別するためには、発 呼者＝０、着呼者＝１のように数を通信の関係者に割り当て、同じ暗号化された セッションの追加関係者がさらに大きな数を受け取る単純なコーディング法を備 える呼パーティコード（ＣＰＣ）を備えることが望ましい。あるいは、ＣＰＣの 代わりに、デバイス連続番号にデバイス製造メーカーＩＤ番号を加えた、デバイ ス連続番号または前記のハッシュのような一意の識別番号が使用できる。 これらの方法は、多数共同セッションキーの作成の方法として一般化すること もできる。例えば、発呼者は、セッションキーを作成し、その同じキーを使用し 、同時にＲＳＡキー転送を使用する複数の着呼者との呼を開始することができる 。その場合、最初の２つの関係者（発呼者および着呼者）の後に追加された関係 者ごとに別個のＭＣＨが存在するであろう。発呼者のデバイスは、多数共同呼を 、別個の複数の呼、または同じセッションキーが設定されるが複数のＣＰＣを持 つ単独の呼として処理できる。したがって、各着呼者は、発呼者のＭＳＮを使用 し、それ自身のＣＰＣおよびＰＳＮを維持する責任を持つであろう。代わりに、 （ディッフィー・ヘルマン法のような）従来の二共同セッションキー作成方法の 使用を仮定して、（システムオペレータのような）中心的な関係者がすべての呼 をかけ、各関係者のパケットのリアルタイム復号化および再暗号化を他のすべて の者の代わりに実行する、会議電話が存在する。また、中心的な関係者が、次の 着呼者に臨時に接続する個人である場合もあり、その場合、その着呼者のパケッ トはその個人のデバイスにより復号化されてから、着呼者が他の関係者（複数の 場合がある）との通信に使用するセッションキー（複数の場合がある）を使用し て再暗号化される。３者またはそれ以上の関係者でのディッフィー・ヘルマンの 使用に関しては、シュネイアー（schneier）の応用復号化法、Ｊ．ウィリー、１ ９９４年、Ｐ２７６も参照する。 パケット制御ヘッダ（ＰＣＨ）は、以下のように公式化できる。 元の発呼者のＭＳＨ ユーザ呼関係者コード（ＣＰＣ）（発呼者＝０など） ユーザパケットシーケンス番号（ＰＳＮ） 呼セットアップからの時間オフセット（ｍｓｅｃ） （このパケットの）ハッシュ ［デバイス署名］ 短いパケットを使用するいくつかのシステムにおいては、結果的に相当のオー バヘッドを生じさせるため、通信のパケットごとでＰＣＨを送信せずに、定期的 にだけＰＣＨを送信することが望ましい。これは、パケットの配列および再試行 がパケットごとに実行されるのではなく、多数のパケットに対してのみ実行され る、ネットワーク通信で「スライディングウィンドウ」として知られる技法に類 似している。通常、このようなシステムは、ラインノイズに基づき、動的に「ウ ィンドウ」、つまりエラーチェックの間に送信されるパケット数を調整、つまり ウィンドウを明確なラインの場合には大きくするが、多くのエラー再試行を引き 起こす騒がしいラインの場合にはウィンドウを小さくする。エラーが頻繁に発生 する場合、小さなウィンドウは、ユーザに少量のデータの再送しか要求しない。 エラーがまれにしか起きない場合には、エラーの場合に損失データを再送するに は高いコストがかかるとしても、チェックはたまに実行される。パケット制御ヘ ッダは、通信システムのスライディングウィンドウ法に直接統合でき、それによ り、近代的な通信ネットワークでの最大システムスループットを可能にしつつ、 パケットレベルに至るまで警察の行為を監査する希望の能力を提供できる。 盗聴装置プロセスの監査可能性をさらに高めるために、通信セッションの最後 をなんらかの特殊なパケットではっきりとマークすることが役に立つ。このパケ ットは、ユーザまたは警察のどちらかが、実際には反対のことが起きたときに、 後で、会話が終わっていたまたは終わっていなかったと主張するのを妨げるため に、ユーザに知られずに、切断前に各デバイスにより他のデバイスに自動的に送 信される。これは、その人間のユーザから「いま電話を切りたい」という入力を 受け入れるように各デバイスに命令することにより行われ、その結果、デバイス は「切断準備」パケットを送出し、それが他のデバイス（複数の場合がある）に 同じことを実行させる。デバイス（複数の場合がある）は、そのデータストリー ムを、追加データは含んでいないが送受された全パケットの合計、通話保留時間 等を含んだ「最終」パケットで終了する。 タイムスタンプデバイス デコーダボックスに関して前述されたその好ましい実施例における本発明のも う一つの機能とは、信用された不正な動きを防止するタイムスタンプデバイスで 、それが第三者によって信頼できると見なされるディジタル署名されたタイムス タンプ（またはこのようなタイムスタンプを備えるデータ構造）を発行（または 添付）できることを自己認証する。このようなタイムスタンプデバイスは、アデ ィソンＭフィッシャー（Addison M．Fischer）による米国特許第５，００１，７ ５２号および米国特許第５，１３６，６４３号に説明される。図２１に示される その好ましい実施例において、タイムスタンプデバイス２１０（またはサブシス テム）は、郵便料金メーターが、地方の米国郵便サービス支局オフィスによって のみ設置され、それ以降、事前に支払われた金額までしか郵便料金メーター切手 を施与しないと一般の人々および郵便制度により信用されるのとほぼ同じように 、製造メーカーまたは製造メーカーにより信用される権威のような信頼される権 威によってのみ較正され、運転を始められる。いったん較正されると、タイムス タンプデバイス２１０（またはサブシステム）は、「時間設定」命令２１１（つ まり再較正）に、その命令が製造メーカー自体、あるいは製造メーカーまたは製 造メーカーが信用するものの、エンティティがホストデバイスのタイムスタンプ デバイス（またはサブシステム）を設置し、較正するのに信用されている旨を述 べる認証２１２を添付したエンティティのどちらかにより署名される場合にだけ 、応答する。おそらく時間設定命令動作は、一時的に物理的にデバイスを所有し 、デバイスの所有者が命令を捕捉し、デバイスのクロックを「実際より前の日付 にする」ために後で命令を再生する可能性を防ぐ目的で、ただちに時間設定命令 ２１１を消去する時間設定権限を持つ人に実行される必要があるだろう。 いったん較正され、妨害されない限り、タイムスタンプデバイス２１０は、そ の内部クロック機構に基づき、タイムスタンプ２１３または構造化データフィー ルド内の完全なタイムスタンプデータを添付し、その秘密デバイスキーが設定さ れた結果として生じるデータ構造に署名２１４し、その製造メーカー認証２１５ を提供する。ホストデバイスが、電源が切れるか、それ自体を停止させる命令に より干渉されるか、それ自体を停止させる命令を受け取ると、タイムスタンプデ バイスはタイムスタンプの発行を停止する。その場合、絶対的な問題として信用 のあるタイムスタンプを必要としない他の有効な機能を損なわせるのを避けるた めに、タイムスタンプデバイスは、構造化データフィールドがタイムスタンプの 入力を要求する場合は、タイムスタンプフィールドをすべてのバイナリゼロやバ イナリ１のような事前に合意した「ヌル」値で満たすなどの規約（あるいは同等 な規約）を活用する。ただし、構造化データフィールドまたはホストデバイスが 、タイムスタンプデバイスがタイムスタンプの発行を停止した場合に、警察デコ ーダボックスの場合でのように実際のタイムスタンプの発行を要求すると、タイ ムスタンプを必要とするホストデバイス機能は動作しない。デコーダボックスの 場合には、ボックスは割り込まれた通信の復号化を拒絶する。ホストデバイスの 停電状況の発生を回避または最小限に抑えるために、各信用されたタイムスタン プデバイスは、専用の別個の長命のクロック専用バッテリ２１６、タイムスタン プデバイスのバッテリ交換前の停電を防ぐためのなんらかの「低バッテリ」警告 インジケータ、およびバッテリ交換動作中に適切な電荷を保持する（記憶装置コ ンデンサ、第２バッテリコンパートメントまたはオプションの外付け電源のよう な）手段を具備するのが望ましい。 タイムスタンプデバイスにより発行される各タイムスタンプには、製造メーカ ー（あるいは別の時間設定権威）により発行され、タイムスタンプクロックの品 質および信頼性、タイムスタンプクロックの予測タイムドリフトだけではなく、 タイムスタンプクロックが前回セットされた日付を記述するタイムスタンプデバ イス認証があるだろう。受取人ユーザが、ホストデバイスによりディジタル署名 されたデータ構造を受け取ると、その受取人は、タイムスタンプフィールドが有 効値で完了している場合、デバイスの署名および認証が、データ構造が作成、署 名、および発行された時刻が正しいことを認証することを理解する。この認証下 付は、（１）もっとも最近タイムスタンプクロックを較正した権威の信頼性、（ ２）デバイス認証に製造メーカーが記述するクロックのドリフト公差、および（ ３）クロックの干渉または停電時にそれ自体を停止させる機能に基づいている。 さらに、受取人は、タイムスタンプフィールドに「ヌル」値が指定されている場 合、タイムスタンプクロックが、デバイスがデータ構造を作成、署名および発行 した時点で信用された較正の状態になかったことを理解する。タイムスタンプデ バイスおよびその内部クロック機構の信用特性に関するこの情報は、適切な属性 値コーディング法を使用して、デバイス認証の中に直接符号化できるのが望まし い。ただし、この情報は、製造メーカーが、デバイス認証発行時に公に述べられ る「方針書」の一部として仕様書および性能認証で発表する、製造メーカー名お よびデバイスタイプからも示唆されるであろう。 このようなタイムスタンプは、ＭＣＨ作成および復号化以外の他のメッセージ 処理動作の一部としてデバイスにより発行されることもある。これらのタイムス タンプは、ユーザが、デバイス内部に安全に閉じこめられている自分の個人的な 署名キーを使用して別の文書またはトランザクションに署名する場合に、デバイ スのユーザの個人的な署名に添付される。デバイスは、ユーザの署名のタイムス タンプ要素に署名または共同署名するか、代わりに（文書のハッシュ結果メッセ ージ摘要とともに、やはりユーザにより署名される、タイムスタンプが入った） ユーザの署名ブロック全体の上に署名するだろう。したがって、デバイスは、製 造メーカーの公開キーを知っている第三者がタイムスタンプを信じ、信頼できる ようにするために、その認証を提供する。 信用されたアップグレード、置換および再キー入力 本発明のもう一つの機能とは、埋め込まれた製造メーカーの公開キー、保護さ れた不揮発性メモリ領域、および安全な中央演算処理装置（ＣＰＵ）を具備し、 製造メーカーにより埋め込まれるあらゆるファームウェアルーチンを信用された やり方でアップグレードまたは補足することができる、不正な動きを防止する信 用されたデバイスである。信用されたデバイスは、そのタイプのデバイスに適切 であり、製造メーカーの署名でディジタル署名される新しいまたは追加ファーム ウェアコードを含むデータの本体を入力として受け入れることによりアップグレ ードまたは補足を実行し、その署名が新しいファームウェアコードが製造メーカ ーにより作成、試験、承認されたこと、およびしたがってデバイスが（ａ）１つ 以上の現在埋め込まれたファームウェアルーチンを新しいファームウェアコード でオーバレイするか、あるいは（ｂ）新しいファームウェアコードを保護された メモリの現在未使用の領域内に１つ以上の新しいルーチンとして追加する必要が あることをデバイスに保証する。好ましい実施例においては、保護されたメモリ は、電源が入っていない間、その情報を無限に保持できるが、デバイスにより（ 比較的に低速ではあるが）消去することも可能で、希望する場合は再利用できる ＦＬＡＳＨタイプとなるだろう。保護されたメモリには、不正な動きが防止され ているかどうかに関係なく、アップグレードまたは捕足の対象となるコードが、 信用されたデバイスによってのみその復号化キーが知られている暗号化された形 式で記憶される（ディスクドライブのような）データ記憶領域も含まれる。デバ イスが、新しいファームウェア（またはソフトウェア）コードのこのような署名 された本文を受け取ると、ユーザは、製造メーカーの署名とともにコードを入力 し、デバイスに対して「ファームウェアアップグレード処理」命令を発行する。 それから、デバイスは、製造中にデバイス内に埋め込まれた製造メーカーの公開 署名キーを使用して製造メーカーの署名を確認する。製造メーカーの署名が確認 されると、コードが受け入れられ、デバイスは希望のアップグレードを実行する 。 前記の信用されたデバイスのファームウェアに対する信用されたアップグレー ドのプロセスは、主として信用されたデバイス製造メーカーとは関係なく、銀行 マスタ寄託センタにより設計および管理される、現在のキー寄託システムのよう な機能を含む、それらの第三者に関連するデバイス機能に関するファームウェア ルーチンのアップグレードを希望する許可され第三者を入れるように、さらに拡 張できる。第三者アップグレードの場合、製造メーカーは第三者ファームウェア 提供業者の公開キーを含むファームウェアアップグレード認証に署名し、それを その第三者に発行する。すると、第三者は、置換ファームウェアルーチンまたは 追加ファームウェアルーチンの作成、試験および承認を行い、第三者の秘密署名 キーでそれらに署名し、製造メーカーからのそのアップグレード認証をそこに添 付する。ユーザは、このようなアップグレードを受け取ると、署名済みのコード ルーチンおよび製造メーカーのアップグレード認証の両方をデバイスにロードし 、それから「第三者ファームウェアアップグレード処理」命令を発行する。した がって、デバイスは、新しいコードルーチン上の第三者の署名を、製造メーカー の アップグレード認証に比較して確認してから、製造中にデバイスに埋め込まれた 製造メーカーの公開署名キーに比較してアップグレード認証を確認する。両方の 署名が確認されると、アップグレードは受け入れられ、デバイスは希望のアップ グレードを実行する。 デバイスファームウェアルーチンをアップグレードまたは補足するための命令 を受け入れるだけではなく、不正な動きを防止する信用されたデバイスは、製造 中に埋め込まれた「命令」公開キーを置換または補足するための命令も受け入れ ることができる。前記のように、信用されたデバイスが、デバイスの製造中に製 造メーカーにより埋め込まれたキー以外の公開キーを備えている可能性がある。 本発明で記述されるように、このような「命令」公開キーには、１つ以上のマス タ寄託センタの公開キーが含まれる場合がある。製造メーカーまたはそれ以外の 信用された第三者のものを含むこれらの埋め込まれたキーは、寄託認証デバイス 認証、アップグレード認証、時間設定命令認証、およびデバイスが従って動作す るためにデバイスに提示されるそれ以外のもののようなさまざまな認証の確認に 使用できる。製造中に埋め込まれる公開キーだけを信頼するのに加えて、デバイ スは、新しい公開キーを埋め込んだり、既存の公開キーを置き換えるための外部 命令も受け入れることができる。デバイスが信用された第三者の公開署名キーの 秘密領域で受け入れ、記憶するためには、製造メーカーは、記載する認証を廃棄 し、指定の公開命令キーを中に記憶するようにデバイスに命令する、製造メーカ ーにより署名される署名済みの命令データパケット（または認証）の中に新しい 公開キーを入れる。特別なパケットは、デバイスに、新しいキーが信用されてい るトランザクションのタイプ（例えば、キー寄託アプリケーション、車レンタル アプリケーション、医療データアプリケーションと使用するためやそれ以外の使 用）に関しても命令する。製造メーカーからこのような公開キーデータパケット を受け取ると、デバイスは、最初に製造メーカーの署名を確認してから、新しい 公開キーを受け入れ、公開キーの使用に関する制限とともに記憶する。 製造メーカーは、製造中または後でのどちらかである、命令データパケットの 一部として第三者の公開命令キーを埋め込む時点で、その第三者キーが承認され たトランザクションの内の一つが製造メーカー自身の基本的な公開署名認証キー の代替物であることを指定することができる。製造メーカー自体の公開署名キー のこのような代替物はほぼ絶対に要求されないが、（デバイス認証およびデバイ スに対する他の命令を発行するための）製造メーカーの対応する秘密署名キーが 盗難のために危うくなる可能性がある。製造メーカーの秘密署名キーの盗難によ り、窃盗犯が、（怪しい信頼性の）新しい寄託センタを承認し、新しい時間設定 権威を承認するために、外見上有効な命令を発行できるだろう。代わりに、およ び、さらにありそうなのは、製造メーカーの秘密署名キーが単に失われるか、破 壊され、それによってさらに有効な命令の発行が妨げられることである。これら のイベントのどちらかは、コンピュータシステムの用語での「災害」として分類 され、その製造メーカーのデバイスのすべてを回収しなければならない結果とな る。しかしながら、本発明により、このような回収の費用は、信用された第三者 が製造メーカーの危うくされた署名キーを置き換えることができるようにするこ とにより、防止または軽減できるだろう。製造メーカーが、製造中またはその後 命令データパケットを使用する際のどちらかに、すでに１つ以上の信用された第 三者の命令キーをデバイスの中に埋め込み、第三者の公開命令キーが承認できる トランザクションの間にそれ自身の公開キーの代替物を入れてあると仮定すると 、製造メーカーはその信用された第三者を頼り、その第三者が、製造メーカーの 公開署名キーの代替物を許可し、それによって、それ自体およびそのユーザがす べての物理デバイスを実際に交換する巨額の費用を節約する製造メーカーのデバ イスのすべてに命令データパケットを発行することを要求する。製造メーカーに より発行されるすべてのデバイス認証も置き換えられなければならないため、こ れは各デバイスに、デバイス自体の公開デバイス署名キーに対する認証要求を発 行させることにより達成される。製造メーカーの秘密キーが失われるか破壊され 、危うくされなかった場合、すべての以前の署名は以前として有効となり、ユー ザは、製造メーカーの新しい署名キーにより署名される同じ情報に対して新しい デバイス認証を発行させるために、自分の旧いデバイス認証を提示するだけだろ う。それから、製造メーカーは、新しいデバイス認証を（おそらくオンラインま たは電子メールトランザクションを介して）戻すだろう。これは依然として高価 であるが、現場にあるその製造メーカーの信用されたデバイスのすべてを大規模 に物 理的に交換するより、安価であり、製造メーカーの評判に対する不利益は少なく なるだろう。 本発明の信用されるデバイスの中に、製造メーカーの公開キーまたはそれ以外 の信用される公開命令キーを取り入れると、全システムのルート公開キーを使用 することにより提起されるシステム機密保護リスクがいくぶん和らげられるであ ろう。これにより、純粋に階層的な信用モデルに対する信頼がさらに高まり、一 般的には、必要とする認証の数が少ないさらに短く、単純な認証が可能となり、 どの認証を活用するべきかを判断するための労力が減り、署名を確認するための 計算時間が減少するだろう。 所有者制御再入力 前記のように、ユーザは、製造後の任意の時点でそのユーザ暗号化キーペアに 関してデバイスに再入力するオプションも持つ。ユーザは、信用されたデバイス に対してキー寄託方法の特定のステップを実行する、つまり秘密キーと公開暗号 化キーの新しいペアを作成し、キー分割部を寄託代理人に送信し、最終的にマス タ寄託センタから新しい寄託認証を受け取るようにとのファームウェア命令を発 行することによりこれを実行する。しかし、ユーザの雇用者または後援者（ある いは、ユーザが別のデバイスまたはプロセスである場合には所有者）に、（ａ） ユーザが、許容できると考える寄託代理人を選択することを確認する目的で、お よび（ｂ）雇用者が、デバイスの真の所有者として、選択された寄託代理人にと って既知のままであり、このため最初に令状や裁判所の命令を取得しなくてもユ ーザのキー分割部を寄託代理人から要求することができることを保証する目的で 、キー入力および再キー入力プロセスを制御させるのも望ましい。雇用者が、例 えば内部監督を行うため、または関連するデバイスが損失、盗難または破壊され た後に、暗号化された独占データを復旧するためなどの任意の数の理由から、あ る特定のデバイスのキーへのアクセスを要求することがある。雇用者が、その以 前の暗号化キーまたは署名キーが危険にさらさされたか、消去されたデバイスの ため、別の従業員に与えられたデバイスのため、あるいはその所有者組織が方針 の問題として定期的な間隔ですべての暗号デバイスをキー入力し直すデバイスの た めなどの、任意の数の理由からデバイスにキー入力し直す必要があることもある 。 好ましい実施例においては、信用されたデバイスは、デバイスが、最初に、特 定のデバイスの恒久的な連続番号２２１を記載し、製造メーカーにより署名（２ ２５）された図２２に示されるもののようなデバイス２２０用の所有者の認証を 受け取らない限り、キー作成および寄託プロセスを開始しないように、製造メー カーにより事前設定されている。製造メーカーによりデバイスの企業購入者に対 して購入時点で発行される所有者の認証２２０は、企業の名称２２２、（内国歳 入庁雇用者識別番号（ＥＩＮ）またはダン＆ブラッドストリート番号（ＤＵＮＳ ）のような）企業の一意の識別番号２２３、および企業により保持される秘密署 名キーに対応し、再キー入力や企業によりデバイスに発行されるそれ以外の命令 を確認するために使用される企業の公開署名認証キー２２４も記載する。この情 報を受け取った後は、デバイスは、再キー入力、またはデバイスの所有者の認証 内に記載される公開キーに対応する企業所有者の秘密署名キーを使用して署名さ れるそれ以外の命令だけに応答する。 今度は図２３を参照すると、雇用者（デバイスの所有者）がデバイスの再キー 入力を希望する場合、雇用者は、（１）デバイスの連続番号２３２、一意の所有 者識別番号２３３、（２）寄託代理人２３５およびマスタ寄託センタ２３４の名 称、（３）再キー入力命令の日付および時刻、（４）再キー入力命令期限２３６ の日付および時刻、ならびに（５）再キー入力命令一意連続番号２３７を含む、 署名された命令２３１をデバイス２３０に発行し、雇用者の秘密署名キー２３８ を使用して命令に署名する。有効な所有者の認証２３９および有効な再キー入力 命令２３１を受け取ると、信用されたデバイスの中のチップ２３０は、まず所有 者の認証２３９上の製造メーカーの署名および再キー入力命令２３１上の雇用者 の署名を確認する。その次に、信用されたデバイスが、以前同様に、各寄託共用 パケット内の所有者の一意識別番号２３３を含むキー作成および寄託プロセスを 完了し、再キー入力命令２３１内の雇用者により指定される寄託代理人２３５に 対してだけ共用パケットを送信する。（電子的に発行できる）これらの命令のそ れ以降の再生は、デバイスが、不揮発性記憶領域内に、受信した前回の複数の再 キー入力命令の連続番号を保持し、命令を実行することを再び拒絶するようにデ バイスを設計することにより、制限することができる。デバイスのタイムクロッ クが順調に維持されていると仮定すると、命令中の期限の日付および時刻を尊重 するようにデバイスのタイムクロックに命令するだけで、再キー入力のそれ以降 の再生を制限することもできる。好ましい実施例においては、そのクロックが未 較正であるデバイスは、ヌル以外の期限日付／時刻が設定された再キー入力命令 の処理を拒絶するが、期限日付時刻がヌルのままとされている場合には先に進む 。 ユーザデバイスから一意の所有者識別番号を含むキー（または再キー）分割共 用パケットを受け取ると、寄託代理人およびマスタ寄託センタは、その一意の識 別番号を各データベースの中に記録し、それ以降は、その所有者からの秘密暗号 化キーへのアクセスの要求を尊重するだろう。好ましい実施例では、寄託代理人 および寄託センタは、それぞれ、一意の所有者識別番号を指定するキー分割共用 パケットにも、製造メーカーにより署名される各デバイス所有者認証が添付され なければならないことを要求する。このデバイス所有者認証により、寄託代理人 およびマスタ寄託センタは、デバイス所有者の認証中の所有者の公開キーに対応 する所有者の秘密署名キーで署名されるキー要求メッセージに従い動作できるよ うになる。 別の実施例においては、信用されたデバイスは、別個のデバイス所有者の認証 を使用しなくても、デバイス所有者からの再キー入力、再寄託、所有者移管また はそれ以外の命令を受け入れることが許可される。デバイスに対する命令に別個 の所有者の認証を使用しなければならないという要件は、所有者が、その所有す るすべてのデバイスの認証のデータベースを保守し、デバイスに再キー入力した り、デバイスになんらかの命令を送信したいと考えるたびに、適切な認証を見つ け出さなければならないため、管理上の負担である。図２６に示されるようによ り優れたアプローチとは、製造メーカーに、デバイスの指定されたファミリ用の 所有者の公開命令キーに対する単独の認証を所有者に発行させ、販売者に、デバ イス２６０の販売時に、その公開命令認証キー２６１をデバイス２６０の内側に インストールさせてから、それらのキーの内部記憶領域に基づいてシステムを設 定することである。デバイスがその製造メーカーにより所有者に最初に販売され た時点で、デバイス２６０は、まず、製造メーカーによりデバイス内に埋め込ま れた製造メーカーの公開命令キー２６３を使用して、所有者の製造メーカー認証 ２６２の有効性を確認する。デバイス内の所有者の公開命令キー領域２６４がブ ランクである場合、デバイスは、所有者の製造メーカー認証２６２からデバイス の所有者公開命令キー領域２６４の中に所有者の公開命令キー２６１をコピーす る。所有者公開命令キーがデバイス内にすでに存在し、デバイスの初期化を試み る所有者の所有者公開命令キーと異なる場合、デバイスは、製造メーカーがデバ イスを別のエンティティに販売したことがあると仮定する。各デバイスは、主要 所有者は多くても１つなので、そのデバイスの所有権は、所有者の認証者という 前記概念の代わり（あるいは前記概念に加えて）、デバイス２６０の中に所有者 公開命令キー２６１が存在するか、あるいは存在しなかにより決定される。 所有者公開命令キーがインストールされていない場合、デバイスは、デバイス の再キー入力や所有権移管に関して制限を受けていない単独ユーザ消費者デバイ スであると考えられる。それだけで、デバイスは、インストールされた所有者キ ーが存在しないということを、前記の再キー入力、再寄託、および所有権移管の 規則を呼び出さずに、ユーザの命令に従うための信号と見なすだろう。図２７に 示されるように、所有者公開命令キー２７１が信用されたデバイス２７０の中に インストールされている場合は、ユーザ再キー入力、再寄託および所有権移管の 命令２７２は、これらの命令が対応する所有者秘密署名キー２７４により署名２ ７３されていない限り、処理されない。所有者の署名２７３がいったん確認され ると、信用されたデバイス２７０は、前記の再寄託手順のステップを実行する。 したがって、所有者は、そのデバイスに命令するときに指定された数のデバイス に対する自分の所有権を認証する所有者の認証を添付する必要はない。ただし、 所有者の署名された命令は、命令がその所有者により所有されるあらゆるデバイ スに供給されるのを妨げるために、言うまでもなく、番号が付けられたデバイス 、またはおそらくそのデバイス番号が指定された規則またはテンプレートに従う あるクラスのデバイスに限られなければならない。 さらに、図２８に示されるように、所有者は、最初にインストールされた所有 者公開命令承認キーを（購入者、つまりデバイスの新しい所有者からの）別のも ので置き換えることにより、デバイスの所有権を移管するための命令を送信でき る。デバイス所有者は、現在の所有者の秘密命令署名キー２８３を使用して署名 された新規所有者の名称および公開命令認証キーを含む所有件移管命令２８２を デバイス２８０に送信する。デバイスは、現在の所有者の公開命令キー２８１を 使用して所有権移管命令２８２を確認し、そのキーを新規所有者の公開命令キー ２８４で置き換え、それ以降は新規所有者からの命令だけに応答する。さらに、 所有者は、第２公開命令キーをインストールすることにより、別の「二次所有者 」を加えることもできる。この第２公開命令認証キーには「権利」フィールドが あり、どの動作に関してそれが命令を受け入れることを許可されているのかを示 している。これらの権利の中に含まれると考えられるのは、再キー入力、別の所 有者の追加、（条件販売と同じ）所有者の削除、全所有者の削除、および記載さ れた所有者を持たない消費者デバイスへの復帰がある。ただし、これらの定義さ れた権利は、主要所有者命令キーの置換または削除を行う権利を含む、最初の、 つまり主要な命令認証キーより多い権利または少ない権利を含む場合もあれば、 同じ量の権利を持つ場合もある。 一般化されたデバイス登録 秘密復号化キーを寄託し、寄託認証を受け取るための前記の一般的な方法は、 必ずしも範囲または目的においてキー寄託状況に限定されることなく、信用され たデバイスを信用された第三者で登録し、その第三者から、デバイスが他の信用 されたデバイスと通信できるようにする許可を受け取るというより一般的なケー スにも適用することができることに注意する。図２４に描写されるこの一般的な プロセスは、信用された第三者（ＴＴＰ）２４１と通信するプログラム可能な信 用されたデバイス２４０が、秘密署名キーおよび対応する公開署名キーの製造メ ーカーの認証２４２を備える。また、このプロセスには、本開示の他のどこかで 説明される、追加のアプリケーションレベルのファームウェアおよび関連する公 開キーのリモートインストールをサポートすることができる同じ、かつ安全なシ ステムレベルファームウェアである可能性がある製造メーカーの公開キー、およ び全システム（またはグローバルな）権威（ＳＷＡ）公開キーも含まれる。デバ イス２４０は、ＳＷＡにより署名される権威２４３の認証を発行されたことによ り、この一般的な登録システムの中に入れられる無制限な数のＴＴＰ２４１のい ずれか一つで登録することができる（ＳＷＡは、公開キー認証階層の有名な原則 にしたがってＴＴＰがシステムの中に入れられるのを許可するための証人の追加 層を任命することもできる）。ユーザは、いったんそのデバイスを指定ＴＴＰで 登録すると、他の取引相手との特殊化されたトランザクションに従事することが できる。。 このプロセスの最初のステップでは、ユーザは、自分のデバイス２４０指定認 証済みＴＴＰ２４１で登録するための要求２４４を始動する。この要求２４４に は、ユーザおよび登録要求の資質を確認するための情報２４５が含まれ、署名お よび既知のタイプのデバイスを裏付けるために、製造メーカーのデバイス認証２ ４２が添付される。選択されたＴＴＰ２４１が、このプロトコルの範囲外ではあ るが、トランザクションを実行するための希望される許可を認めるか、否定する かのＴＴＰの決定に影響を及ぼす可能性がある、ユーザのアイデンティティ、所 属、信頼度などを確認するために、ユーザまたはその他の関係者のどちらかから その他の情報および保証を要求することもある。ＴＴＰ２４１は、適切な公開キ ーを使用して、デバイス認証２４２上の製造メーカーの署名およびユーザの登録 要求２４５内の情報に対するデバイス署名を確認する。 ユーザが要求されたクラスのトランザクションに従事することを許可可能であ ることに満足すると、ＴＴＰ２４１は、デバイスがユーザの代わりにそれらのト ランザクションを実行するのを特に許可する認証２４７を含む応答２４６を発行 する。ＴＴＰのデバイス許可認証２４７は、ユーザが取引相手とのそれ以降のト ランザクションのたびに、自分のデバイス認証２４２を提出しなくてもいいよう に、通常、便宜上（および後述するように）ユーザのデバイス公開署名キーの再 認証されたコピーだけではなく、ＴＴＰ、ユーザ、ユーザのデバイスおよび許可 が与えられたトランザクションを識別する情報も含む。また、ＴＴＰ応答２４６ には、ダウンロード可能なファームウェア、またはユーザの信用されたデバイス の中にロードされる、そのデバイスが許可されたトランザクションを実行できる ようにする、公開キー２４８、あるいはその両方が含まれることもある。ＴＴＰ 応答２４６がユーザに新しいファームウェアまたは公開キーを自分のデバイスの 中に安全にロードするように要求する場合、応答２４６は、ＴＴＰの公開署名キ ーを認証し、ファームウェアおよび公開キーのアップグレード権威を伝達する、 ＳＷＡにより発行される権威２４３のＴＴＰの認証も含む。ユーザの信用された デバイス２４０は、ＴＴＰの応答２４６を受け取ると、その埋め込まれたＳＷＡ 公開署名キーを使用し、権威２４３のＴＴＰの認証を確認し、その中に含まれる ＴＴＰ公開署名キーを使用し、ファームウェアおよび公開キーのアップグレード ２４８およびＴＴＰのデバイス許可認証２４７を確認する。 図２４を再び参照すると、ユーザが取引相手２５０とのトランザクションの実 行を希望すると、そのデバイスは、本開示全体で広範囲に説明してきたように、 デバイス上にインストールされたファームウェアプログラムの中で実現された規 則に則って（製造時点またはそれ以降のダウンロード時点のどちらかで）トラン ザクションデータ２４９を公式化し、トランザクション２４９に署名し、その対 応する公開キーの認証を添付する。この認証が、製造メーカーのデバイス許可認 証２４２であることもあるが、おそらく、便宜上認証し直されたデバイス公開キ ーのコピーを含むＴＴＰのデバイス許可認証２４７であろう。取引相手２５０は 、通常、ＴＴＰの公開キーを活用し、そのデバイス許可署名書２４７上のＴＴＰ の署名を確認してから、その中に含まれるデバイス公開署名キーを使用し、トラ ンザクション２４９でのデバイスの署名を確認し、それにより関連するファーム ウェアにより課されるトランザクションプロトコル要件とのデバイスの準拠を確 認する。取引相手２５０がすでに特定のＴＴＰの公開署名認証キーを持っていな い場合には、ユーザは、取引相手がＳＷＡ公開キーを使用して確認でき、それが このシステムの参加者となるためにすでに所有していなければならない、権威２ ４３のＴＴＰのＳＷＡ認証をトランザクション２４９の中に入れることができる 。 ここまで説明した一般化されたプロセスは、（ａ）ユーザデバイス認証中に記 載または示唆される情報が、デバイスが、すでに、本明細書で説明するキー寄託 暗号システムの特殊化された機能を実行することができるファームウェアを具備 している旨を寄託センタに伝達する、寄託センタ（ＴＴＰ）により署名される寄 託認証の返礼に、秘密暗号化キーを寄託すること、または（ｂ）このようなデバ イスがそのように具備されていないが、そのように具備される機能を持つ場合に 、 インストール時にデバイスが寄託システムのトランザクション要件を満たすこと ができるようにする安全なソフトウェアアップグレードをダウンロードすること を許可するほど一般的である。取引相手２５０に送信されるトランザクションデ ータ２４９は、メッセージ制御ヘッダによりプレフィックスされ、ＴＴＰ２４１ （マスタ寄託センタ）により発行される許可２４７（ユーザの寄託認証）が添付 される。 したがって、図２４の一般化されたシステムは、複雑な形式の企業および政府 のトランザクションを開放的な通信ネットワーク環境で促進することができる多 くのきわめて望ましい特性を持つ。特に、各参加デバイスが安全なマルチステッ プトランザクションを実行し、追加タイプの安全マルチステップトランザクショ ンを実行するためにファームウェアをダウンロードし、そのように作成されるト ランザクションに署名できる限り、多くの異なるデバイス製造メーカーが存在で きる。また、それぞれが異なったタイプのトランザクション許可を発行し、それ ぞれが、キー寄託、ディジタル現金管理、自動車レンタル、またはユーザ医療レ コード管理のような異なるクラスのファームウェアアプリケーションを認証する 、任意の数の信用された第三者も存在できる。したがって、取引相手は（ユーザ デバイスのファームウェアおよびプロトコルにより）比較できるように具備され る信用されたデバイスを活用することを要求される可能性があるが、そのデバイ スは、元のユーザの関係者とは異なる関係者により作成、発行、および具備され 、しかも元のユーザのトランザクションは、ＳＷＡおよびそのＴＴＰによりその ように認証される場合は、相手が、デバイスのすべてのバージョンおよびそのプ ログラムが互いに認識し、ともに作業できるようにするＳＷＡ公開署名認証キー ２４７のコピーを所有する限り、システム規則に則り、受け入れられ処理される 。このプロトコルにより実現されるビジネス目的のいくつかの例には、（ａ）認 証可能な寄託キーを使用する暗号化、（ｂ）現金またはそれ以外の高い価値の文 書のディジタル表現の管理、および（ｃ）ユーザの医療情報またはそれ以外の個 人的な情報へのアクセスおよびその使用に対するトランザクション要件を施行す るシステムを含む。 一意所有者識別番号 使いやすさをプライバシー権利とつり合わせる必要性に応じて、一意所有者識 別番号は、寄託代理人に対するキー分割メッセージの中だけではなく、オプショ ンで、（ａ）ユーザの寄託認証または（ｂ）通常の通信中に発行されるＭＣＨの どちらかに表示される。通信を復号化しようとする調査官が、ＭＣＨがその中か ら取られた通信に関係するデバイスの一方またはデバイスの両方が、指定された 所有者に属するかどうかを、所有者識別番号を含むＭＣＨを見ることにより判断 できるのが望ましい。ただし、ある種の所有者を含むそれ以外のプライバシーの 利害により、所有者識別番号が、通信のプライバシーを高める目的でＭＣＨから 省略されることが示唆される。所有者識別番号が、デバイス寄託認証のみに含ま れ、通信のＭＣＨ中には含まれないケースでは、ある特定の雇用者により雇用さ れ、リストされたデバイス所有者を持たない多くのＭＣＨに突き合わせて、ある 特定の通信が、その雇用者の従業員を起源とするのかどうかを判断しようとする 調査官は、指定されたＭＣＨ中にリストされたマスタ寄託センタに、そのＭＣＨ が、雇用者により所有されるデバイスを起源としたのかどうかを問い合わせるだ ろう。マスタ寄託センタは、そのキーがそのマスタ寄託センタに寄託されるＭＣ Ｈ通信の関係者の認証番号を復号化し、ユーザ認証が調査官の雇用者に対して発 行されたかどうかをチェックする。発行された場合、および調査官の要求が、雇 用者−所有者の署名キーを使用して署名される場合（つまり、調査官が雇用者− 所有者から調査するための許可を持つ）、マスタ寄託センタが、この情報を明ら かにするだろう。調査官が許可を持たない場合、調査官は、既知のデバイス所有 者のＭＣＨに反映される疑わしい活動を調査するための令状または裁判所命令を 求める必要があるだろう。大部分のデバイス所有者が、そのユーザの寄託認証お よびＭＣＨの中で公に名前を指定されるのに反対しないと予測される。これは、 大部分の電子通信システムにおいては、たいてい指定メッセージの送受制度を強 力に識別する物理ネットワークアドレスおよび論理ネットワークアドレスの情報 を抑制するのが実践的ではないためである。したがって、一意所有者識別番号を 公開することによりほとんど損失されず、送信者デバイス所有者名および受取人 デバイス所有者名により、メッセージをすばやくより分け、分類する能力を提供 することにより多くが得られる。 しかしながら、一意所有者識別番号が、公開されずに、依然として従業員寄託 認証の中または通信のＭＣＨの中に含まれる可能性がある。従業員の寄託認証お よびＭＣＨには、前記の他のキーとともに雇用者公開暗号化キーが含まれるだろ う。これらのキーは、（送信者と受取人両者が雇用者であると仮定し）通常、送 信者の寄託認証と受取人の寄託認証の両方に存在する。送信者のデバイスは、Ｍ ＣＨを形成する場合、実際には送信者のデバイスがＭＣＨを使用して各雇用者− 所有者にその各雇用者−所有者自身の一意のＩＤから構成されるそれだけが復号 化できるメッセージを送信するように、ＭＣＨの中に、それぞれがその雇用者の 公開暗号化キーを使用して一方または両方の雇用者一意識別番号を取り入れる。 この方法は、送信者が、送信者および受取人両者の、各寄託センタの公開暗号化 キーの元で暗号化された認証番号を送信するため、および両関係者の傍受を可能 とする目的で、メッセージセッションキーを送信者だけではなく受取人にも送信 する（ＭＣＨの正常な機能）ために、ＭＣＨを使用することに関して前記された 方法に類似する。この技法を使用すると、雇用者は、所用者−雇用者の従業員に 属するすべてのメッセージがメッセージトラヒックフロー内で容易に識別可能で あり、所有者ＩＤ番号が暗号化されておらず容易に取得できる状況を回避しつつ 、どのＭＣＨがその従業員に属するのかを容易に判断できる。 依然として、このアプローチには、雇用者公開暗号化キーを使用して暗号化さ れた一意の雇用者識別暗号が、常に同じ、したがって認識可能な値を生み出すと いう欠点がある。このアプローチをさらにうまく実施するならば、タイムスタン プが暗号化されるデータブロックに高い変化性を与えるように、（雇用書が明ら かに知る権利を持っている）従業員の寄託認証番号だけではなく現在のタイムス タンプ（または別の無作為番号）が入ったデータブロックを、雇用者の公開キー で暗号化する。「ＥＭＰＬ」（またはスペースが許すならば、雇用者の一意ＩＤ ）のような別個の「人目を引く」テキストの数バイトは、（人が確実に理解して いない可能性がある、他のデータ項目がバイナリであるケースで）フィールドを 復号化中のエンティティに成功した復号化を明らかにするために、暗号化された ブロックの内側にも入れることができるだろう。このケースでは、雇用者の所 有権の認証は、雇用者が単にこのフィールドを読むことができるということから 構成される。さらに、タイムスタンプが毎回異なり、したがってすべての雇用者 ＭＣＨデータブロックを一意とするほど十分に信用されない変化性を増すために 別の無作為番号がデータブロックに追加されるだろう。 送信されるあらゆるメッセージで送信者と受取人両者の雇用者に対して実行さ れるこの改善されたアプローチにより、雇用者およびその他の後援者が、それら の通信のどれかがその雇用者により所有されるデバイスを起源をしたのかどうか という点に関して判断するために、適切な寄託センタへの通信のたびに暗号化さ れたＭＣＨを提出しなくても、どの通信が従業員により作成され、受信されたの かを判断できるようになり、したがってかなりの金額が節約される。各雇用者は 、その雇用者の秘密暗号化キーを取得する目的で、以前同様、依然としてマスタ 寄託センタおよび寄託代理人と連絡しなければならず、デバイス製造メーカーに より発行される、その所有者認証内に記載される公開署名認証キーと突き合わせ るのは、実際には、その要求を秘密署名キーで署名することによる従業員のデバ イスの所有者であることを認証しなければならない。少なくとも、雇用者に、後 で所有されていないデバイスであることが判明するものを起源とする通信のＭＣ Ｈに関して、それらの関係者に追加に要求を出す時間、労力および費用をかけさ せないだろう。そして、以前同様、雇用者が、所有されていないデバイスによる 通信からのＭＣＨが添付される犯罪活動または他の不適切な活動に気づく場合、 雇用者は、常に適切な警察に接触し、その機関に犯罪活動に気づいた理由を教え 、第三者の従業員ではない犯罪者、またはおそらく従業員であるかどうかに関係 なく、雇用者により所有されておらず、雇用者に登録される暗号デバイスを使用 する雇用者の敷地の個人を起源とすると考えられる、それらの通信の割り込みま たは復号化あるいはその両方のための令状を取得するためにその機関を裁判所に 出向かせる。 情報およびがそれを読み取る権利を与えられた関係者によってだけ読み取られ るように、情報を暗号化されたＭＣＨの中に入れる方法を、（そのそれぞれがメ ッセージセッションキーを復号化できる）送信者と受取人、（そのそれぞれがそ のそれぞれのユーザの認証番号を解読できる）各関係者のマスタ寄託センタ、お よび（そのそれぞれが、メッセージごとに識別されるのを回避しつつ、誰か他の 人に連絡しなくてもそれが通信側デバイスを所有しているかどうかを確認できる ように、その従業員の認証番号またはそれ自体の一意の所有者識別番号を復号化 できる）各関係者の雇用者−所有者だけではない関係者に拡張できるのは明かで ある。これは、また、非常に大規模な企業または令状要件を持たないある外国の 地方の警察などのようなそれ以外の関係者にも拡張できる。言うまでもなく、こ れらの関係者が各メッセージで公に指名され、日常的に識別可能であることに反 対する根拠を持たないと仮定するならば、これらのキーの元ですべての情報は、 前記のように、普通文、つまり暗号化しないで表示することもできる。また、こ の情報は、ユーザに雇用者がいない場合などの関係者が関連していない場合も省 略できる。単純化されたアプローチとは、すべての状況に１つのＭＣＨ書式を使 用し、適用できない場合には、フィールドをブランクのまま残すことであろう。 それ以外の場合、好ましい実施例では、ＭＣＨを処理する各デバイスがどのフィ ールドを予測するかを判断し、ＭＣＨをそれに従って解析できるように、各書式 が第１フィールドの一意のバージョン番号により識別される、さまざまな異なる ＭＣＨ書式を同じシステム内では活用するであろう。この方法により、最大限に 柔軟なシステムであるＭＣＨの利害関係者の無限ネスティングが可能となる。計 算上のオーバヘッドは、おもに、どれだけ多くのこれらのフィールドが実際に各 それぞれの関係者の公開暗号化キーで暗号化されなければならなかったのかに依 存する。 雇用者は、各エントリに「方針フィールド」つまり、雇用者のデバイスにどの 情報をＭＣＨの中に入れるのかに関して命令するコードを含む命令コードを添付 することにより、ＭＣＨ内に入れられる情報をさらに容易に制御することができ る。以前同様、命令コードは、雇用者に以下の情報を入れるオプションを与える 選り抜きの要素を含む場合がある。（１）暗号化されているか、別名を使用する かのどちらかである雇用者の指名および一意の識別番号、（２）雇用者の一意の 識別番号がＭＣＨフィールドの中で暗号化されている、暗号化されていないワー ド「雇用者」、（３）暗号化されたフィールド内のユーザ認証番号、（４）暗号 化されたフィールドのメッセージセッションキー、（５）暗号化されたフィール ドのタイムスタンプ、および（６）他の暗号化されたフィールドのいずれかの中 の無作為交絡者番号。これらのオプションの多くは、実際には同時となる。さら に、これらの方針のオプションは、通信関係者自身を含む重要なコミュニティー の全メンバーにとって同じとなり、それによりそのメールＩＤまたはシステムＩ Ｄにより、あるいは関連する明かなＭＣＨフィールドで「送信者」または「受信 者」という言葉を使用するだけで、関係者にラベル付けできるようにする。 複数の同時寄託キー デバイスファームウェアルーチンをアップグレードし、製造メーカーの公開キ ーを置き換えるための前記機能に加えて、本発明の信用されたデバイスは、寄託 された暗号化キーの複数のセットを同時に保守、管理する能力も持つ必要がある 。通常、デバイスが、再キー入力、つまり新しい秘密暗号化キーの作成および寄 託を行うサイクルを開始し、その結果、対応する新しい公開暗号化キーの寄託認 証を受け取ると、デバイスは、新しく寄託された秘密キーに対するデバイスの信 頼を強制するために、以前の秘密キーを消去する。代わりに、デバイスは、必要 に応じて、暗号化されたデータを以前の秘密暗号化キーを使用してデータ記憶領 域内に復旧するのに必要となる時間のような、短時間だけ以前の秘密キーを保持 する。しかし、代わりの実施例においては、デバイスは、同じ秘密／公開暗号化 キーのペアに関する第２の有効な寄託認証を作成するために、前記のようにユー ザまたはデバイス所有者のどちらかからの再寄託命令も受け入れ、処理すること ができる。この実施例では、デバイスは、きっと寄託代理人の異なるリストと異 なるマスタ寄託センタを使用して寄託プロセスを先に進め、第２マスタ寄託セン タにより署名発行され、第１寄託認証に代えて使用できる同じ公開／秘密暗号化 キーペアの別個の等しく有効な寄託認証を受け取るであろう。この第２公開暗号 化キー認証は、デバイスのユーザが国際的に旅行し、他の国に位置する関係者と 通信するケース、特にそれらの他国がその他国を起源とするまたはその他国で終 端する通信の合法的な監督の実施を希望する場合に有効である。このようなケー スでは、別の国で同じデバイスキーを再寄託することにより、ユーザまたは雇用 者が時刻の寄託代理人の元のセットとビジネス（合法的な所有者のモニタ、損失 し たキーの復旧など）を行う便宜は許されたまま、ユーザ（またはユーザの雇用者 ）がその他の国での考えられる法的要件を満たすのに役立つことがある。したが って、所有者がその従業員のＭＣＨを追跡調査するのを可能とするためには、送 信者および受取人所有者ＩＤが各ＭＣＨに表示され、それにより所有者にそれが 本当にキーを取得する能力を持つ旨を告げるならば十分である可能性がある。時 間および労力を節約するために、所有者は、外国の寄託認証番号、基礎デバイス 番号および基礎デバイス認証を取得するためにこのようなＭＣＨを外国のマスタ 寄託センタに送信するが、すでに所有している所有者の認証を確認し、実際の秘 密キー分割部をリリースできるその国内寄託代理人に適用する。この手順により 、デバイス所有者は、外国の寄託代理人から実際のキー分割部を取得するために 必要となる可能性がある特別の法律上の手続きから解放される。 国家安全保障輸出保護手段 米国政府の現在の方針とは、合衆国内でのアメリカ人市民による規制を受けな い使用を許可するが、暗号デバイス、ソフトウェアまたはノウハウの輸出には重 い制限および罰金を課すというものである。合衆国内での暗号デバイスの比較的 に自由な個人的な使用を許可すると同時に、その国際的な使用に制限を課すよう に、本システムを修正することは可能である。こおようなシステムは、システム 全体で使用される標準的なメッセージ書式に対する変更を最小とした、またはま ったく行わないすべてのソフトウェアおよびハードウェアベンダに開放された別 個の操作が共通の「方針領域」を可能とするだろう。さらに、キー寄託システム が、ある特定の企業が、その企業が寄託したキーを使用して暗号課された通信へ の警察のアクセスを容易にするという明示または暗示された義務なしに、それ自 体の従業員による暗号の使用をモニタ、制御できる純粋な法人内の一国の状況で 秘密寄託代理人の使用を可能とすることが望ましい。特に、このような企業は自 ら使用するためにソフトウェアおよびハードウェアを購入するかもしれないが、 犯罪者やテロリストを熱心に追求する警察により望まれる、短期枠組みでの秘密 キーに対するアクセスの提供を行う公の義務を引き受けるのを断る可能性がある 。 これは、まず最初に、システム全体でのすべてのデバイスが、直接または間接 的に、（前述のように）それぞれが確実であり信頼できるとしてシステム内のデ バイスにより認識されるようにするために、寄託代理人、マスタ寄託センタおよ びデバイス製造メーカーに対し認証を発行する全システム権威（ＳＷＡ）にリン クされていると仮定することにより実行できる。国内または世界的な通信システ ムは、実践的な目的のため、そのそれぞれが確実であるとしてＳＷＡにより認証 されなければならない、複数の関連の内マスタ寄託センタおよびおよび代理人の 存在をサポートしなければならない。マスタ寄託センタまたは寄託代理人に対し て発行される各認証中で、ＳＷＡは、それを「公開」または「秘密」のどちらか として指定する。「公開」マスタ寄託センタまたは寄託代理人とは、国の安全保 障または警察の令状または召還状に速やかに応答する準備ができ、応答する責任 があるもののことである。そのキーがこのような代理人に寄託されるユーザは、 国境を越えた通信に関わることを許可される。「秘密」マスタ寄託センタまたは 寄託代理人は、独自に使用するためにキー寄託システム技術をインストールした が、公的なレベルでのサービスに対する責任を引き受けないそれらの単独企業ま たは単独国家のキーセンタを含む。ＳＷＡからマスタ寄託センタまたは寄託代理 人に対する認証には、国コードも含まれる。したがって、マスタ寄託センタによ り発行、署名され、マスタ寄託センタＳＷＡ認証が添付される各ユーザの寄託認 証は、ユーザの国コードも記載される。便宜上の問題として、ユーザの寄託認証 が、ＳＷＡがその情報の正しさを施行することは不可能であるかもしれないが、 それが公の寄託代理人または公ではない寄託代理人のどちらを起源とするのかも 述べる必要があることに注意する。これにより、デバイスは、マスタ寄託センタ のＳＷＡ認証を常に必要とするよりはるかに容易にこれらの規則を実行できるよ うになる。 図２９および図３０は、国際的な暗号通信の送受の際の寄託要件の施行を示す 。図２９に示されるように、送信者の信用されたデバイス２９は、送信者と受取 人の両者の寄託認証２９１、２９３、および送信者および受取人が同じマスタ寄 託センタで寄託されていない場合にはそのマスタ寄託センタＳＷＡ認証２９２、 ２９４を、国際通信を送信する前に必要とすることにより、このシステムを実施 する。受取人ユーザおよびそのマスタ寄託センタの国コード２９５、２９６は、 送 信側デバイスが通信を送信できるように一致しなければならない。さらに、送信 者および受取人が別の国々２９５、２９７にいる場合、および一方のユーザが公 ではないマスタ寄託センタ２９８、２９９を使用している場合、送信側デバイス は、その受取人に対する通信を始めることを拒絶するだろう。図３０に示される ように、受取人の信用されたデバイス３００も、送信者および受取人が別の国々 にいる場合に通信がどうにかして始められる場合、および一方のユーザが公では ない公開マスタ寄託センターを使用している場合に、通信の復号化を拒否するこ とによりこのシステムを実施する。マスタ寄託センタがＳＷＡにより認証される その公的なステータスを偽ることはできないため、およびたとえマスタ寄託セン タが（ユーザが他国の領域に所属するように見えるようにするために）ユーザの 国コードを偽ることができるとしても、デバイスがユーザの国コードとマスタ寄 託センタの国コードの間の不一致を許さないため、これらの規則は、寄託されて いない国際的な暗号通信を許可しないという望ましい方針を実現することになる 。これらの規則はユーザが不適切に信用された暗号デバイスを国境を越えて転送 することを妨げないが、ユーザが各国で寄託されたキーを維持し、各方針領域で 適切なキーだけを使用して通信することを許すことにより、国の要件に容易に準 拠できるようにする。 マルチユーザデバイスバージョン 本発明の別の機能とは、同じデバイスを使用する異なるローカルユーザまたは リモートユーザとの通信の複数の異なるセッションを始動し、同時に管理する能 力のことである。多くのより大規模なコンピュータは、大部分の場合、端末セッ ションを介して同時にログされるが、世界中の他のエンティティと暗号化された セッションを開始することを希望する複数のユーザをサポートする。ただし、共 用されたコンピュータでのユーザセッションごとに別個の信用されたデバイスを 要求することがきわめて非効率的であるため、信用されたデバイスは、そのセッ ションの一意のメッセージシーケンス番号（ＭＳＮ）とともにそれを記憶するこ とにより、各通信ごとにメッセージセッションキーを追跡調査できる。したがっ て、そのＭＳＨが付いた追加メッセージパケットが到着すると、これらのパケッ トは、遅延なく復号化され、応答が暗号化される。さらに、デバイスは、各ユー ザ秘密キーをある特定のユーザー意識別番号とリンクし、各キーがパスワード、 スマートカード、ＰＩＮ、生物測定、およびチャレンジ応答などのなんらかの適 切なユーザ認証が提示された場合にのみ、使用できるようにする一方、複数のユ ーザの秘密復号化キーを寄託できる。ユーザ識別番号およびパスワード、または 同等なものを各公開／秘密キーのペアに、それが寄託のために作成されるときに 割り当てることにより、長さ、期限、再試行ロックアウト、および推論の容易さ などの通常のパスワードに対する制御を、許可されていないアクセスの可能性を 制限する目的で、デバイスにより課すことができる。 このようにして、キー寄託機能が付いた暗号システムおよび方法が提供される 。当業者は、本発明が、図解の目的で提示されたのであり、制限のために提示さ れたのではない記述された実施例以外によっても実践可能であること、および本 発明が以下の請求の範囲によってのみ制限されることを理解するであろう。

───────────────────────────────────────────────────── フロントページの続き (51)Int.Cl.⁶ 識別記号 庁内整理番号 ＦＩ Ｇ０９Ｃ 1/00 ６４０ 7259−5Ｊ Ｇ０９Ｃ 1/00 ６４０Ｄ Ｈ０４Ｌ 9/32 9570−5Ｊ Ｈ０４Ｌ 9/00 ６０１Ｂ 9570−5Ｊ ６０１Ｅ 9570−5Ｊ ６７５Ｂ 9570−5Ｊ ６７５Ｄ (81)指定国 ＥＰ(ＡＴ，ＢＥ，ＣＨ，ＤＥ， ＤＫ，ＥＳ，ＦＲ，ＧＢ，ＧＲ，ＩＥ，ＩＴ，ＬＵ，Ｍ Ｃ，ＮＬ，ＰＴ，ＳＥ)，ＯＡ(ＢＦ，ＢＪ，ＣＦ，ＣＧ ，ＣＩ，ＣＭ，ＧＡ，ＧＮ，ＭＬ，ＭＲ，ＮＥ，ＳＮ， ＴＤ，ＴＧ)，ＡＰ(ＫＥ，ＭＷ，ＳＤ，ＳＺ)，ＡＭ， ＡＵ，ＢＢ，ＢＧ，ＢＲ，ＢＹ，ＣＡ，ＣＮ，ＣＺ，Ｆ Ｉ，ＧＥ，ＨＵ，ＪＰ，ＫＧ，ＫＰ，ＫＲ，ＫＺ，ＬＫ ，ＬＴ，ＬＶ，ＭＤ，ＭＧ，ＭＮ，ＭＸ，ＮＯ，ＮＺ， ＰＬ，ＰＴ，ＲＯ，ＲＵ，ＳＩ，ＳＫ，ＴＪ，ＴＴ，Ｕ Ａ，ＵＺ，ＶＮ 【要約の続き】 用されたデバイスと通信できるようにする許可を受け取 るという、より一般化されたケースにも適用される。本 発明は、信用された寄託センターで、複数のユーザによ り使用される複数の非対称暗号化キーを寄託するステッ プと、寄託センタで、前記複数のキーのそれぞれを確認 するステップと、確認時に前記複数のキーのそれぞれの 権限授与を認証するステップと、前記認証を条件とした 前記複数のキーのそれぞれ１つを使用する前記複数のユ ーザのそれぞれから通信を開始するステップとを具備 し、複数のユーザの間で認証できるように信用された通 信を作成する方法も提供する。さらに、本発明は、各通 信に含まれるメッセージ制御ヘッダの使用に基づき、許 可された警察による通信の復号化、特殊な警察デコーダ ボックスの使用、警察および他の機関による濫用を防止 するための警察の盗聴装置の監査も実現する。さらに、 認証システムおよびストリーム指向データの暗号化を使 用し、デバイスファームウェアの再キー入力およびアッ プグレードを実現する。

Claims (1)

1. 【特許請求の範囲】 １．認証可能な信用される秘密暗号ディジタル通信を、外部エンティティが前 記通信をモニタできるようにする一方で、複数のユーザの間で生成するための方 法であって、 少なくとも１つの信用される寄託センタに、複数のユーザにより暗号通信のた めに使用される複数の非対称暗号化キーを寄託するステップと、 前記少なくとも１つの寄託センタによる前記複数のキーのそれぞれの寄託を認 証するステップと、 前記複数のユーザの第１ユーザから前記複数のユーザの第２ユーザに対する通 信を、前記複数のキーの第１キーを使用して暗号化するステップと、 前記寄託される通信に、前記少なくとも１つの信用される寄託センタを識別す るのに十分な情報を含むメッセージ制御ヘッダを含めるステップと、 前記複数のキーの第２キーを使用して、前記複数のユーザの前記第２ユーザに よる前記暗号化された通信を復号化するステップとを具備し、 前記第２ユーザによる前記暗号化通信を復号化する前記ステップが、前記第１ および第２ユーザの前記キーの認証、および有効なメッセージ制御ヘッダの前記 通信内での存在を条件とする方法。 ２．前記第１ユーザからの通信を暗号化する前記ステップが、前記第１および 第２ユーザの前記キーの認証および有効なメッセージ制御ヘッダの前記通信内で の存在を条件とする請求の範囲第１項記載の方法。 ３．前記通信が、記憶のために前記第１ユーザからそのユーザ自身に対して暗 号化されるように、前記第１ユーザおよび前記第２ユーザが同一である請求の範 囲第１項記載の方法。 ４．各ユーザが、各ユーザが公開暗号化キーと秘密暗号化キーの少なくとも１ つの対応するペアを持つように、暗号通信の暗号化および復号化に使用する必要 がある複数の対応する公開キーと秘密キーのペアを構成する複数の無作為に作成 された非対称暗号化キーを持つ請求の範囲第１項記載の方法。 ５．前記寄託するステップが、さらに、各ユーザのために、 前記少なくとも１つの対応するキーのペアから成る秘密キーを部分に分割する ステップと、 少なくとも一人の受託人のそれぞれに、前記秘密キーの少なくとも１つの部分 を提供するステップと、 前記少なくとも一人の受託人のそれぞれに、前記受託人が、前記秘密キーの前 記少なくとも１つの部分の正しい受領を確認できるようにするための確認情報を 提供するステップと、 前記少なくとも１つの信用された寄託センタによる、前記秘密キーの前記少な くとも１つの部分の前記少なくとも一人の受託人のそれぞれによる正しい受領を 確認するステップとを具備する請求の範囲第４項記載の方法。 ６．前記寄託するステップが、さらに、前記分割するステップが前記寄託セン タにより実行されるように、前記ユーザ秘密キーを含む前記少なくとも１つの寄 託センタに対する通信を寄託するステップを具備する請求の範囲第５項記載の方 法。 ７．前記ユーザ秘密キーを含む前記少なくとも１つの寄託センタに対する通信 を寄託する前記ステップが、さらに、前記ユーザが前記通信をディジタル署名す るステップを具備する請求の範囲第６項記載の方法。 ８．前記分割するステップが、前記秘密キーを再構築するためには全Ｎ個の部 分が必要となるように、さらに、各ユーザの秘密キーをＮ個の部分に分割するこ とを具備する請求の範囲第５項記載の方法。 ９．前記分割するステップが、Ｍ＜Ｎの場合、前記秘密キーを再構築するため にはＭ個の部分だけが必要となるように、さらに、各ユーザの秘密キーをＮ個の 部分に分割することを具備する請求の範囲第５項記載の方法。 １０．少なくとも一人の受託人のそれぞれに前記秘密キーの少なくとも１つの 部分を提供する前記ステップが、さらに、前記ユーザ秘密キーの前記少なくとも １つの部分を含む前記少なくとも一人の受託人のそれぞれに対する通信を暗号化 するステップを具備する請求の範囲第５項記載の方法。 １１．少なくとも一人の受託人のそれぞれに確認情報を提供する前記ステップ が、さらに、前記確認情報を含む通信を前記少なくとも一人の受託人のそれぞれ に対して暗号化するステップを具備する請求の範囲第１０項記載の方法。 １２．前記ユーザ秘密キーの前記少なくとも１つの部分を含む前記少なくとも 一人の受託人に対する通信を暗号化する前記ステップが、前記ユーザにより実行 され、さらに、前記ユーザが前記通信にディジタル署名するステップを具備する 請求の範囲第１１項記載の方法。 １３．前記確認情報を含む前記少なくとも一人の受託人のそれぞれに対する通 信を暗号化する前記ステップが、前記ユーザにより実行され、さらに、前記ユー ザが前記通信をディジタル署名するステップを具備する請求の範囲第１２項記載 の方法。 １４．前記ユーザ秘密キーの前記少なくとも１つの部分を含む前記少なくとも 一人の受託人のそれぞれに対する通信を暗号化する前記ステップが、前記寄託セ ンタにより実行され、さらに、前記寄託センタが前記通信にディジタル署名する ステップを具備する請求の範囲第１３項記載の方法。 １５．前記確認情報を含む前記少なくとも一人の受託人に対する通信を暗号化 する前記ステップが、前記寄託センタにより実行され、さらに、前記寄託センタ が前記通信にディジタル署名するステップを具備する請求の範囲第１４項記載の 方法。 １６．前記少なくとも１つの寄託センタを確認する前記ステップが、各受託人 に対して、 前記受託人による前記ユーザの前記秘密キーの前記少なくとも１つの部分の受 領を、前記寄託センタに対して通知するステップと、 前記受託人による前記確認情報を前記寄託センターに対して通信するステップ と、 前記確認情報の前記受託人による正しい通信に基づいて、前記ユーザの前記秘 密キーの前記少なくとも１つの部分の、前記受託人による正しい受領を、前記寄 託センタにより確証するステップとを具備する請求の範囲第５項記載の方法。 １７．前記受託人によって前記確認情報を前記寄託センタに対して通信する前 記ステップが、前記確認情報を含む前記寄託センタに対する通信を暗号化するス テップを具備する請求の範囲第１６項記載の方法。 １８．前記確認情報を含む前記寄託センタに対する通信を暗号化する前記ステ ップが、さらに、前記受託人が前記通信にディジタル署名するステップを具備す る請求の範囲第１７項記載の方法。 １９．前記複数のユーザのそれぞれが、一意のディジタル識別コードを持ち、 前記方法が、さらに、前記少なくとも一人の受託人に前記ユーザの一意のディジ タル識別コードを提供するステップを具備する請求の範囲第５項記載の方法。 ２０．前記複数のキーのそれぞれの寄託を認証する前記ステップが、さらに、 前記暗号化キーと対応するユーザの間のつながりを公証し、前記暗号化キーが寄 託されたことを認証する前記複数の暗号化キーのそれぞれに対して、前記少なく とも１つの寄託センタにより寄託認証を発行することを含む請求の範囲第１項記 載の方法。 ２１．前記複数のキーのそれぞれの寄託を認証する前記ステップが、さらに、 前記対応するユーザに対して前記寄託認証のコピーを送信するステップを具備す る請求の範囲第２０項記載の方法。 ２２．前記複数のキーのそれぞれの寄託を認証する前記ステップが、さらに、 前記寄託認証を前記複数のユーザの他者が利用できるようにするステップを具備 する請求の範囲第２０項記載の方法。 ２３．前記寄託認証を利用できるようにするステップが、前記寄託認証をこの ようなユーザがアクセスできる寄託認証ディレクトリの中に入れることを含む請 求の範囲第２２項記載の方法。 ２４．上位権威により前記少なくとも１つの信用された寄託センタの信頼性を 認証するステップをさらに具備する請求の範囲第１項記載の方法。 ２５．信用された寄託センタを認証する前記ステップが、寄託のために前記寄 託センタの信頼性を公証する前記少なくとも１つの信用される寄託センターのそ れぞれに前記上位権威による認証を発行するステップとを具備する請求の範囲第 ２４項記載の方法。 ２６．前記信用された寄託センタを認証するステップが、前記対応する信用さ れる寄託センタに対して前記上位権威の認証のコピーを送信するステップをさら に具備する請求の範囲第２５項記載の方法。 ２７．前記信用される寄託センターを認証するステップが、前記複数のユーザ の他のものが前記上位権威認証を利用できるようにするステップをさらに具備す る請求の範囲第２５項記載の方法。 ２８．前記上位権威が全システム権威を構成する請求の範囲第２５項記載の方 法。 ２９．前記上位権威が信用されるデバイスの少なくとも１つの製造メーカーを 構成する請求の範囲第２５項記載の方法。 ３０．前記信用される寄託センタを認証するステップが、デバイスの前記少な くとも１つの製造メーカーの信頼性を公証し、製造された前記デバイスの非対称 暗号化キーを無作為に作成し、読取り不能の不正な動きを防止するやり方で前記 キーを記憶する能力を立証する、デバイスの前記少なくとも１つの製造メーカー のそれぞれに対して、全システム権威による製造メーカー認証を発行するステッ プをさらに具備する請求の範囲第２９項記載の方法。 ３１．前記信用された寄託センタを認証するステップが、前記対応する製造メ ーカーに対して前記製造メーカー認証のコピーを送信するステップをさらに具備 する請求の範囲第３０項記載の方法。 ３２．前記信用された寄託センタを認証するステップが、前記製造メーカーに より製造されるデバイスのユーザに対して前記製造メーカー認証のコピーを送信 するステップをさらに具備する請求の範囲第３０項記載の方法。 ３３．前記複数のキーのそれぞれの寄託を認証するステップが、前記対応する 暗号化キーのペアと対応するユーザの間のつながりを公証し、前記対応する暗号 化キーのペアの前記秘密キーが寄託された旨を認証する前記対応する暗号化キー のペアのそれぞれに対して、１つの寄託センタにより寄託認証を発行することを 具備する請求の範囲第４項記載の方法。 ３４．前記複数のキーのそれぞれの寄託を認証するステップが、前記対応する ユーザに対して前記寄託署名書のコピーを送信するステップをさらに具備する請 求の範囲第３３項記載の方法。 ３５．前記複数のキーのそれぞれの寄託を認証するステップが、前記寄託認証 を前記複数のユーザのその他のものが利用できるようにするステップをさらに具 備する請求の範囲第３３項記載の方法。 ３６．前記寄託認証を利用できるようにするステップが、前記ユーザが利用し やすい寄託認証ディレクトリの中に前記寄託認証を入れることを具備する請求の 範囲第３５項記載の方法。 ３７．前記複数のキーのそれぞれの寄託を認証するステップが、前記寄託認証 を発行する前に、前記少なくとも１つの寄託センタにより前記対応する暗号化キ ーのペアのそれぞれの秘密キーの寄託を確認することを具備する請求の範囲第３ ３項記載の方法。 ３８．前記対応する暗号化キーのペアの寄託認証が、前記認証を発行する寄託 センタの識別、前記寄託認証のディジタルコード識別、および前記対応する暗号 化キーのペアの前記公開キーを構成する請求の範囲第３７項記載の方法。 ３９．前記メッセージ制御ヘッダを入れるステップが、前記第１ユーザの寄託 センタの識別および前記第１ユーザの寄託認証の前記ディジタルコード識別を構 成する暗号メッセージ制御ヘッダパケットを形成するステップを具備する請求の 範囲第３８項記載の方法。 ４０．前記メッセージ制御ヘッダを入れるステップが、前記第２ユーザの寄託 センタの識別および前記第２ユーザの寄託認証の前記ディジタルコード識別を構 成する暗号メッセージ制御ヘッダパケットを形成するステップを具備する請求の 範囲第３９項記載の方法。 ４１．前記第１ユーザの寄託センタおよび前記第２ユーザの寄託センタが同一 であり、 メッセージ制御ヘッダを入れる前記ステップが、前記第１および第２ユーザの 寄託センタの識別および前記寄託認証のそれぞれの前記ディジタル識別コードを 構成する暗号メッセージ制御ヘッダパケットを形成するステップをさらに具備す る請求の範囲第４０項記載の方法。 ４２．前記メッセージ制御ヘッダを入れるステップが、前記第１ユーザの雇用 者または監督者の識別を構成する暗号メッセージ制御ヘッダパケットを形成する ステップをさらに具備する請求の範囲第３９項記載の方法。 ４３．前記メッセージ制御ヘッダを入れるステップが、前記第２ユーザの雇用 者または監督者の識別を構成する暗号メッセージ制御ヘッダを形成するステップ とを具備する請求の範囲第４２項記載の方法。 ４４．前記第１ユーザの雇用者または監督者および前記第２ユーザの雇用者ま たは監督者が同一であり、 メッセージ制御ヘッダを入れる前記ステップが、さらに、前記第１および第２ ユーザの雇用者または監督者の識別、および前記寄託認証のそれぞれの前記ディ ジタル識別コードを形成するステップを具備する請求の範囲第４３項記載の方法 。 ４５．前記メッセージ制御ヘッダを入れるステップが、前記第１ユーザによる 前記メッセージ制御ヘッダの形成の日付および時刻を示すタイムスタンプを構成 する暗号メッセージ制御ヘッダパケットを形成するステップをさらに具備する請 求の範囲第３９項記載の方法。 ４６．前記ユーザが、前記暗号通信および前記メッセージ制御ヘッダの形成の 日付および時刻を示すタイムスタンプを作成するための信用されるタイムクロッ クを備え、メッセージ制御ヘッダを入れる前記ステップが、前記タイムスタンプ の信頼性を認証するステップをさらに具備する請求の範囲第４５項記載の方法。 ４７．前記タイムスタンプの信頼性を認証するステップが、前記タイムスタン プを作成するために、前記タイムクロックの信頼性を公証する上位権威による認 証を発行することを具備する請求の範囲第４６項記載の方法。 ４８．前記タイムスタンプを認証するステップが、作成された前記タイムスタ ンプのそれぞれに前記タイムクロック認証を添付することをさらに具備する請求 の範囲第４７項記載の方法。 ４９．前記上位権威が全システム権威を構成する請求の範囲第４７項記載の方 法。 ５０．前記上位権威が前記タイムクロックの製造メーカーを構成する請求の範 囲第４７項記載の方法。 ５１．前記上位権威が寄託センタを構成し、前記タイムクロック認証が前記寄 託認証内で発行され、デバイス製造メーカーの判断および前記寄託プロセス中の デバイス情報に基づく請求の範囲第４６項記載の方法。 ５２．盗聴装置設置許可を持つ前記外部エンティティにより前記暗号通信をモ ニタするステップをさらに具備する請求の範囲第３９項記載の方法。 ５３．前記モニタするステップが、 前記外部エンティティによる前記暗号化された通信に割り込むステップと、 前記盗聴措置設置許可および前記メッセージ制御ヘッダを前記第１ユーザの寄 託センタに提示するステップと、 前記第１ユーザの寄託センタに寄託された前記第１ユーザの前記対応する暗号 化キーのページの秘密キーを取得するステップと、 前記第１ユーザの前記秘密キーを前記暗号化された通信の復号化に使用するス テップとをさらに具備する請求の範囲第５１項記載の方法。 ５４．前記提示するステップが、 前記メッセージ制御ヘッダから前記第１ユーザの寄託センタの前記識別および 前記第１ユーザの寄託認証の前記ディジタル識別コードを抽出するステップと、 前記盗聴装置設置許可および前記第１ユーザの寄託認証の前記ディジタル識別 コードを前記第１ユーザの寄託センタに提示するステップとをさらに具備する請 求の範囲第５３項記載の方法。 ５５．前記第１ユーザが、前記暗号通信および前記メッセージ制御ヘッダの形 成の日付および時刻を示すタイムスタンプを作成するための信用されたタイムク ロックを備え、 前記メッセージ制御ヘッダを入れるステップが、 前記第１ユーザによる前記メッセージ制御ヘッダの形成の日付および時刻を示 すタイムスタンプを構成する暗号メッセージ制御ヘッダパケットを形成するステ ップと、 タイムスタンプを作成する目的で、前記タイムクロックの信頼性を認証するス テップとをさらに具備する請求の範囲第５４項記載の方法。 ５６．前記信用されるタイムクロックが、前記タイムクロックの製造メーカー によってだけ設定または較正できる請求の範囲第５５項記載の方法。 ５７．前記盗聴装置設置許可が、少なくとも１つの事前に定義される制約を条 件とする請求の範囲第５３項記載の方法。 ５８．前記少なくとも１つの事前定義される制約が、前記盗聴装置設置許可に 、その前に前記第１ユーザの前記秘密キーを取得する前記ステップが発生しては な らない開始日付および時刻が含まれるような時間制約を具備する請求の範囲第５ ７項記載の方法。 ５９．前記少なくとも１つの事前定義される制約が、前記盗聴装置設置許可に 、その後では前記第１ユーザの前記秘密キーを取得する前記ステップが発生して はならない終了日付および時刻が含まれるようなさらに時間制約を具備する請求 の範囲第５８項記載の方法。 ６０．前記少なくとも１つの事前定義される制約が、前記盗聴装置設置許可に 、それ以降前記第１ユーザの前記秘密キーを取得する前記ステップが発生しては ならない終了日付および時刻が含まれるような時間制約を具備する請求の範囲第 ５３項記載の方法。 ６１．前記第１ユーザの秘密キーを取得するステップが、 前記少なくとも一人の受託人から、前記第１ユーザの秘密キーの前記少なくと も１つの部分を回収するステップと、 前記秘密キーの前記回収された部分から前記秘密キーを再構築するステップと をさらに具備する請求の範囲第５３項記載の方法。 ６２．前記取得するステップが、前記寄託センタにより実行される請求の範囲 第６１項記載の方法。 ６３．前記取得するステップが、前記外部エンティティにより実行される請求 の範囲第６１項記載の方法。 ６４．前記第２ユーザの寄託センタの識別および前記第２ユーザの寄託認証の 前記ディジタル識別コードを構成する暗号メッセージ制御ヘッダパケットを形成 するステップとを具備する請求の範囲第３８項記載の方法。 ６５．前記メッセージ制御ヘッダを入れるステップが、前記第２ユーザの雇用 者または監督者の識別を構成する暗号メッセージ制御ヘッダパケットを形成する ステップをさらに具備する請求の範囲第６４項記載の方法。 ６６．盗聴装置設置許可を持つ前記外部エンティティによる前記暗号通信をモ ニタするステップをさらに具備する請求の範囲第６４項記載の方法。 ６７．前記モニタするステップが、 前記外部エンティティによる前記暗号化された通信に割り込むステップと、 前記盗聴装置設置許可および前記メッセージ制御ヘッダを前記第２ユーザの寄 託センタに提示するステップと、 前記第２ユーザの寄託センタに寄託された、前記第２ユーザの前記対応する暗 号化キーのペアの秘密キーを取得するステップと、 前記暗号化された通信を復号化するために、前記第２ユーザの前記秘密キーを 使用するステップとをさらに具備する請求の範囲第６６項記載の方法。 ６８．前記提示するステップが、 前記メッセージ制御ヘッダから、前記第２ユーザの寄託センタの前記識別およ び前記第２ユーザの寄託認証の前記ディジタル識別を抽出するステップと、 前記盗聴装置設置許可および前記第２ユーザの寄託認証の前記ディジタルコー ド識別を前記第２ユーザの寄託センタに対して提示するステップとをさらに具備 する請求の範囲第６７項記載の方法。 ６９．前記第１ユーザが、前記暗号通信および前記メッセージ制御ヘッダの形 成の日付および時刻を示すタイムスタンプを作成するために信用されるタイムク ロックを備え、 前記メッセージ制御ヘッダを入れるステップが、 前記第１ユーザによる前記メッセージ制御ヘッダの形成の日付および時刻を示 すタイムスタンプを構成する暗号メッセージ制御ヘッダパケットを形成するステ ップと、 タイムスタンプを作成する目的で前記タイムクロックの信頼性を認証するステ ップとをさらに具備する請求の範囲第６８項記載の方法。 ７０．前記信用されたタイムクロックが、前記タイムクロックの製造メーカー によってのみ設定または較正可能な請求の範囲第６９項記載の方法。 ７１．前記盗聴装置許可が、少なくとも１つの事前定義された制約を条件とす る請求の範囲第６７項記載の方法。 ７２．前記少なくとも１つの事前定義された制約が、前記盗聴装置設置許可が 、それ以前は前記第２ユーザの前記秘密キーを取得する前記ステップが発生して はならない開始日付および時刻を含むような時間制約を具備する請求の範囲第７ １項記載の方法。 ７３．前記少なくとも１つの事前定義された制約が、前記盗聴装置設置許可が 、それ以後は前記第２ユーザの前記秘密キーを取得する前記ステップが発生して はならない終了日付および時刻を含むようなさらなる時間制約を具備する請求の 範囲第７２項記載の方法。 ７４．前記少なくとも１つの事前定義される制約が、前記盗聴装置設置許可が 、それ以後は前記第２ユーザの前記秘密キーを取得する前記ステップが発生して はならない終了日付および時刻を含むような時間制約を具備する請求の範囲第７ ３項記載の方法。 ７５．前記第２ユーザの秘密キーを取得するステップが、 前記少なくとも一人の受託人から前記第２ユーザの秘密キーの前記少なくとも １つの部分を回収するステップと、 前記秘密キーの前記回収された部分から前記秘密キーを再構築するステップと をさらに具備する請求の範囲第６７項記載の方法。 ７６．前記取得するステップが、前記寄託センタにより実行される請求の範囲 第７５項記載の方法。 ７７．前記取得するステップが、前記外部エンティティにより実行される請求 の範囲第７５項記載の方法。 ７８．公開キーと秘密キーの前記複数の対応するペアの中の各一致ペアに対し て、前記秘密キーだけが前記公開キーを使用して暗号化された通信を復号化でき る請求の範囲第４項記載の方法。 ７９．前記第１ユーザにより前記第２ユーザに対する前記通信を暗号化するた めに使用される前記複数のキーの前記第１キーが、前記第２ユーザの公開キーを 具備する請求の範囲第７８項記載の方法。 ８０．前記第２ユーザにより前記暗号化された通信の復号化に使用される前記 複数のキーの前記第２キーが、前記第２ユーザの秘密キーを具備する請求の範囲 第７８項記載の方法。 ８１．前記通信を暗号化するステップが、 前記第１ユーザと前記第２ユーザの間の暗号通信の暗号化および復号化の両方 で使用するために一意の暗号化キーを作成するステップと、 前記暗号化キーを使用して、前記第１ユーザによる前記第２ユーザに対する前 記通信を暗号化するステップとをさらに具備する請求の範囲第１項記載の方法。 ８２．前記一意の暗号化キーを作成するステップが、 前記第２ユーザの秘密キーおよび少なくとも１つの公開番号を使用して、前記 第２ユーザによる前記第２ユーザの中間番号を計算するステップと、 前記第１ユーザによる前記第２ユーザの中間番号を取得するステップと、 前記第１ユーザの秘密キーおよび前記第２ユーザの前記中間キーを使用して、 前記第１ユーザによる前記暗号化キーを計算するステップとを具備し、 前記暗号化キーを用いて暗号化された前記第１ユーザから前記第２ユーザへの 前記通信が、前記暗号化キーだけを用いて復号化できるようにする請求の範囲第 ８１項記載の方法。 ８３．前記第２ユーザの前記中間番号および前記少なくとも１つの公開番号が 前記第２ユーザの公開キーを構成する請求の範囲第８２項記載の方法。 ８４．前記第１ユーザにより前記第２ユーザに対する前記通信の暗号化に使用 される前記複数のキーの前記第１キーが、前記暗号化キーを計算する前記ステッ プで使用される前記第１ユーザの前記秘密キーを具備する請求の範囲第８２項記 載の方法。 ８５．前記第２ユーザにより前記暗号化された通信の復号化に使用される前記 複数のキーの前記第２キーが、中間番号を計算する前記ステップで使用される前 記第２ユーザの前記秘密キーを具備する請求の範囲第８２項記載の方法。 ８６．前記第１ユーザおよび前記少なくとも１つの公開番号を使用して、前記 第１ユーザによる前記第ユーザの中間番号を計算するステップをさらに具備する 請求の範囲第８２項記載の方法。 ８７．前記メッセージ制御ヘッダを入れるステップが、前記第１ユーザの前記 中間番号および前記少なくとも１つの公開番号を構成するメッセージ制御ヘッダ を形成するステップをさらに具備する請求の範囲第８６項記載の方法。 ８８．前記第２ユーザによる前記暗号化された通信を復号化する前記ステップ が、 前記第２ユーザの前記秘密キーおよび前記第１ユーザの前記中間番号を使用し て、前記第２ユーザによる前記暗号化キーを計算するステップと、 前記暗号化キーを使用する前記第２ユーザによる前記第１ユーザからの前記通 信を復号化するステップとをさらに具備する請求の範囲第８７項記載の方法。 ８９．前記一意の暗号化キーを作成するステップが、前記第１ユーザおよび前 記第２ユーザのそれぞれにより対話で前記暗号化キーを作成するステップを具備 する請求の範囲第８１項記載の方法。 ９０．前記第１ユーザおよび前記第２ユーザのそれぞれにより対話で前記暗号 化キーを作成するステップが、 前記第１ユーザの秘密キーおよび少なくとも１つの公開キーを使用して、前記 第１ユーザによる第１中間番号を計算するステップと、 前記第２ユーザの秘密キーおよび少なくとも１つの公開キーを使用して、前記 第２ユーザによる第２中間番号を計算するステップと、 前記第１ユーザの前記秘密キーおよび前記第２中間番号を使用して、前記第１ ユーザによる前記暗号化キーを計算するステップと、 前記第２ユーザの前記秘密キーおよび前記第１中間番号を使用して、前記第２ ユーザによる前記暗号化キーを計算するステップとを具備し、 前記暗号化キーを使用して暗号化される前記第１ユーザから前記第２ユーザへ のあるいは前記第２ユーザから前記第１ユーザへの前記通信が、前記暗号化キー を用いる場合だけ復号化できるようにする請求の範囲第８９項記載の方法。 ９１．前記第１ユーザにより前記第２ユーザへの前記通信の暗号化に使用され る前記複数のキーの前記第１キーが、第１中間番号を計算する前記ステップに使 用される前記第１ユーザの前記秘密キーを具備する請求の範囲第９０項記載の方 法。 ９２．前記第２ユーザにより前記暗号化された通信を復号化するのに使用され る前記複数のキーの前記第２キーが、第２中間番号を計算する前記ステップで使 用される前記第２ユーザの前記秘密キーを具備する請求の範囲第９０項記載の方 法。 ９３．前記第２ユーザによる前記暗号化された通信を復号化する前記ステップ が、前記暗号化キーを用いる前記第１ユーザからの前記通信を前記第２ユーザに より復号化するステップをさらに具備する請求の範囲第９０項記載の方法。 ９４．各信用デバイスが、対応するキーのペアの公開キーが前記デバイスに対 する暗号通信の暗号化に使用され、前記対応するキーのペアの対応する秘密キー が前記暗号通信の復号化に使用される無作為に作成される非対称暗号化キーの少 なくとも１つの対応するペアを持つ、複数の信用されるデバイスを備える暗号シ ステムにおいて、外部エンティティが前記通信をモニタできるようにしつつ、複 数のデバイスの間の認証できる信用された暗号通信を作成するための方法であっ て、 前記信用されたデバイスのそれぞれの暗号化キーの前記対応するペアの少なく とも１つの公開ペアを、少なくとも１つの寄託センタに寄託するステップと、 前記少なくとも１つの寄託センタによる前記デバイスのそれぞれの前記対応す るキーのペアの寄託を保証するステップと、 前記第２デバイスの前記対応するキーのペアの公開キーを使用して、前記デバ イスの２番目への前記デバイスの１番目からの通信を暗号化するステップと、 前記の少なくとも１つの信用された寄託センタを識別するのに十分な情報を含 むメッセージ制御ヘッダを、前記暗号化された通信とともに含むステップと、 前記第２デバイスの前記対応するキーのペアの秘密キーを使用して、前記第２ デバイスによる前記暗号化される通信を復号化するステップとを具備し、 前記第２デバイスによる前記暗号化される通信を復号化する前記ステップが、 前記第１デバイスおよび前記第２デバイスのそれぞれの前記秘密キーの認証、お よび有効なメッセージ制御ヘッダの前記通信内での存在を条件とする方法。 ９５．前記第１ステップからの通信を暗号化する前記ステップが、前記第１デ バイスおよび前記第２デバイスのそれぞれの前記秘密キーの認証および有効なメ ッセージ制御ヘッダ内での存在を条件にする請求の範囲第９４項記載の方法。 ９６．前記少なくとも１つの非対称暗号化キーの対応するペアのそれぞれに、 前記秘密キーだけが、前記公開キーを使用して暗号化された通信を復号化できる 請求の範囲第９４項記載の方法。 ９７．記憶のために、前記通信が前記第１デバイスからそれ自体に対して暗号 化されるように、前記第１デバイスおよび前記第２デバイスが同一である請求の 範囲第９４項記載の方法。 ９８．各信用されたデバイスが、前記少なくとも１つの対応する暗号化キーの ペアを無作為に作成し、安全で、不正な動きを防止し、読取り不可能なやり方で キーの前記ペアを記憶する能力を持つ請求の範囲第９４項記載の方法。 ９９．各前記信用されるデバイスに製造メーカーがあり、さらに、前記デバイ スの前記キーを無作為に作成し、記憶する能力を、上位権威により認証するステ ップを具備する請求の範囲第９８項記載の方法。 １００．前記製造メーカーを認証するステップが、前記製造メーカーの信頼性 および前記デバイスの前記キーを無作為に作成し、記憶する能力を公証する、前 記製造メーカーに対する前記上位権威による認証を発行するステップを具備する 請求の範囲第９９項記載の方法。 １０１．前記上位権威が全システム権威を構成する請求の範囲第９９項記載の 方法。 １０２．前記寄託するステップが、各信用されるデバイスに対して、 前記秘密キーを部分に分割するステップと、 少なくとも一人の受託人のそれぞれに、前記秘密キーの少なくとも１つの部分 を提供するステップと、 前記少なくとも一人の受託人に、前記受託人が、前記秘密キーの前記少なくと も１つの部分の正しい受領を確認できるようにする確認情報を提供するステップ と、 前記秘密キーの前記少なくとも１つの部分の前記少なくとも一人の受託人のそ れぞれによる正しい受領を、前記少なくとも１つの信用された寄託センタにより 確認するステップとをさらに具備する請求の範囲第９４項記載の方法。 １０３．前記少なくとも１つの信用された寄託センタのそれぞれが、暗号通信 の暗号化および復号化に使用される必要がある少なくとも１つの対応する公開暗 号化キーおよび秘密暗号化キーのペアを持ち、 前記寄託するステップが、前記分解するステップが前記寄託センタにより実行 されるように、前記信用されたデバイス秘密キーを含む前記少なくとも１つの寄 託センタに対する通信を暗号化するステップをさらに具備する請求の範囲第１０ ２項記載の方法。 １０４．前記少なくとも１つの信用された寄託センタの前記暗号化キーが、少 なくとも１つの寄託センタのグループが寄託目的で前記製造メーカーにより選択 されるように、前記デバイスの製造メーカーにより前記信用されたデバイスの中 に事前に埋め込まれ、 前記寄託するステップが、前記事前に埋め込まれた寄託センタ暗号化キーの１ つを使用して、少なくとも１つの寄託センタの前記グループの中から１つの寄託 センタに対する前記秘密キーの少なくとも１つの部分を含む通信を暗号化するス テップをさらに具備する請求の範囲第１０３項記載の方法。 １０５．前記少なくとも１つの寄託センタの前記暗号化キーが、前記デバイス が利用しやすい寄託認証ディレクトリから前記デバイスにより取得される請求の 範囲第１０３項記載の方法。 １０６．前記少なくとも１つの寄託センタに対する前記信用されたデバイス秘 密キーを含む通信を暗号化する前記ステップが、前記デバイスにより実行され、 前記デバイスが前記通信にディジタル署名するステップをさらに具備する請求の 範囲第１０３項記載の方法。 １０７．前記少なくとも一人の受託人のそれぞれが、暗号通信の暗号化および 復号化に使用される必要があるすくなくとも１つの対応する公開暗号化キーと秘 密暗号化キーのペアを持ち、 前記分割するステップが、前記デバイスにより実行される請求の範囲第１０２ 項記載の方法。 １０８．前記少なくとも一人の受託人の前記暗号化キーが、前記少なくとも一 人の受託人のグループが寄託目的で前記製造メーカーにより選択されるように、 前記デバイスの製造メーカーにより前記信用されたデバイスの中に事前に埋め込 まれ、少なくとも一人の受託人のそれぞれに、前記秘密キーの少なくとも１つの 部分を提供する前記ステップが、前記事前に埋め込まれた受託人暗号化キーの１ つを使用して、前記少なくとも一人の受託人の前記グループの中から少なくとも 一人の受託人のそれぞれに対する前記秘密キーの少なくとも１つの部分で通信を 暗号化するステップをさらに具備する請求の範囲第１０７項記載の方法。 １０９．前記少なくとも一人の受託人のそれぞれに対する通信を暗号化するス テップが、前記デバイスにより実行され、前記デバイスが前記通信をディジタル 署名するステップをさらに具備する請求の範囲第１０８項記載の方法。 １１０．前記秘密キーの少なくとも１つの部分を少なくとも一人の受託人のそ れぞれに提供するステップが、前記秘密キーの部分を受け取った前記少なくとも 一人の受託人のそれぞれの識別を構成する前記寄託センタに対する通信を暗号化 するステップをさらに具備する請求の範囲第１０８項記載の方法。 １１１．前記少なくとも一人の受託人のそれぞれに確認情報を提供するステッ プが、前記少なくとも一人の受託人のそれぞれに対して前記確認情報を含む通信 を暗号化するステップをさらに具備する請求の範囲第１０８項記載の方法。 １１２．前記確認情報を含む前記少なくとも一人の受託人のそれぞれに対する 通信を暗号化するステップが、前記デバイスにより実行され、前記デバイスが前 記通信をディジタル署名するステップをさらに具備する請求の範囲第１１１項記 載の方法。 １１３．前記少なくとも一人の受託人のそれぞれに確認情報を提供するステッ プが、（ａ）前記確認情報を受け取った前記少なくとも一人の受託人のそれぞれ の識別、および（ｂ）前記確認情報を構成する前記寄託センタに対する通信を暗 号化するステップをさらに具備する請求の範囲第１１１項記載の方法。 １１４．前記分割するステップが、前記秘密キーを再構築するために、Ｎ個の 部分すべてが必要となるように、さらに、前記秘密キーをＮ個の部分に分割する ことを具備する請求の範囲第１０２項記載の方法。 １１５．前記分割するステップが、Ｍ＜Ｎの場合、前記秘密キーを再構築する ために、Ｍ個の部分だけが必要とされるように、前記秘密キーをＮ個の部分に分 割することを具備する請求の範囲第１０２項記載の方法。 １１６．前記少なくとも一人の受託人のそれぞれに前記秘密キーの少なくとも １つの部分を提供するステップが、前記秘密キーの前記少なくとも１つの部分を 含む前記少なくとも一人の受託人のそれぞれに対する通信を暗号化するステップ をさらに具備する請求の範囲第１０２項記載の方法。 １１７．前記デバイス秘密キーの前記少なくとも１つの部分を含む前記少なく とも一人の受託人のそれぞれに対する通信を暗号化するステップが、前記通信に ディジタル署名するステップを具備する請求の範囲第１１６項記載の方法。 １１８．前記少なくとも一人の受託人のそれぞれに確認情報を提供するステッ プが、前記確認情報を含む通信を前記少なくとも一人の受託人のそれぞれに対し て暗号化するステップをさらに具備する請求の範囲第１１６項記載の方法。 １１９．前記確認情報を含む前記少なくとも一人の受託人のそれぞれに対する 通信を暗号化するステップが、前記寄託センタが前記通信をディジタル署名する ステップをさらに具備する請求の範囲第１１８項記載の方法。 １２０．前記少なくとも１つの寄託センタにより確認するステップが、各受託 人に対して、 前記受託人による前記デバイスの前記秘密キーの前記少なくとも１つの部分の 受領を前記寄託センタに通知するステップと、 前記受託人による、前記確認情報を前記寄託センタに対して通信するステップ と、 前記確認情報の前記受託人による正しい通信に基づき、前記デバイスの前記秘 密キーの前記少なくとも１つの部分の前記受託人による正しい受領を前記寄託セ ンタにより確証するステップとを具備する請求の範囲第１０２項記載の方法。 １２１．前記受託人による前記確認情報を前記寄託センタに対して通信するス テップが、前記確認情報を含む前記寄託センタに対する通信を暗号化するステッ プを具備する請求の範囲第１２０項記載の方法。 １２２．前記確認情報を含む前記寄託センタに対する通信を暗号化するステッ プが、前記受託人が前記通信をディジタル署名するステップをさらに具備する請 求の範囲第１２１項記載の方法。 １２３．前記複数の信用されたデバイスのそれぞれに一意のディジタル識別コ ードが設定され、前記方法が、前記デバイスの一意のディジタル識別コードを前 記少なくとも一人の受託人のそれぞれに提供するステップをさらに具備する請求 の範囲第１０２項記載の方法。 １２４．前記少なくとも１つの信用された寄託センタの信頼度を上位権威によ り認証するステップをさらに具備する請求の範囲第１０２項記載の方法。 １２５．信用された寄託センタを認証する前記ステップが、寄託目的のために 前記寄託センタの信頼度を交渉する、前記少なくとも１つの信用された寄託セン タのそれぞれに、前記上位権威により認証を発行するステップをさらに具備する 請求の範囲第１２４項記載の方法。 １２６．前記上位権威が全システム権威を構成する請求の範囲第１２５項記載 の方法。 １２７．前記上位権威が、デバイスの少なくとも１つの製造メーカーを構成す る請求の範囲第１２５項記載の方法。 １２８．前記信用された寄託センタを認証するステップが、デバイスの前記少 なくとも１つの製造メーカーの信頼度を公証し、製造される前記デバイスのそれ ぞれの非対称暗号化キーの対応するペアを無作為に作成し、読取り不能で不正な 動きを防止するやり方で前記キーを記憶する能力を立証するデバイスの前記少な くとも１つの製造メーカーのそれぞれに全市巣権威による認証を発行するステッ プをさらに具備する請求の範囲第１２７項記載の方法。 １２９．前記秘密キーの寄託を認証するステップが、前記対応する暗号化キー のペアの前記公開キーと前記秘密キーの間のつながりを公証し、前記対応する暗 号化キーのペアの前記秘密キーが寄託として受託されていることをりっそうする 、前記デバイスの前記対応する暗号化キーペアのそれぞれに対して、１つの寄託 代理人による寄託認証を発行するステップをさらに具備する請求の範囲第９４項 記載の方法。 １３０．前記対応する暗号化キーペアのそれぞれの前記寄託認証が、前記認証 発行寄託センタの識別、前記寄託認証のディジタル識別コード、および前記対応 する暗号化キーペアの前記公開キーを具備する請求の範囲第１２９項記載の方法 。 １３１．前記秘密キーの寄託を認証するステップが、前記寄託認証を発行する 前記ステップの前に、前記対応する暗号化キーペアの前記秘密キーの寄託を前記 認証発行寄託代理人により確証するステップをさらに具備する請求の範囲第１２ ９項記載の方法。 １３２．前記少なくとも１つの寄託センタによる前記確証するステップが、各 受託人に対して、 前記受託人による、前記デバイスの前記秘密キーの前記少なくとも１つの部分 の受領を前記寄託センタに通知するステップと、 前記受託人による前記確認情報の前記寄託センタに対する通信、および 前記確認情報の前記受託人による正しい通信に基づき、前記寄託センタによる 、前記デバイスの前記秘密キーの前記少なくとも１つの部分の前記受託人による 正しい受領を家訓するステップとを具備する請求の範囲第１３１項記載の方法。 １３３．前記確認情報を前記寄託センタに対して前記受託人により通信する前 記ステップが、前記確認情報を含む前記寄託センタに対する通信を暗号化するス テップを具備する請求の範囲第１３２項記載の方法。 １３４．前記確認情報を含む前記寄託センタに対する通信を暗号化する前記ス テップが、前記受託人が前記通信をディジタル署名するステップをさらに具備す る請求の範囲第１３３項記載の方法。 １３５．前記対応する暗号化キーペアのそれぞれに対する前記寄託認証が、前 記認証発行寄託センタの識別、前記寄託認証のディジタル識別コード、および前 記対応する暗号化キーペアの前記公開キーを具備する請求の範囲第１３１項記載 の方法。 １３６．前記メッセージ制御ヘッダを入れるステップが、前記第１デバイスの 寄託センタの識別、および前記第１デバイスの寄託認証の前記ディジタル識別コ ードを構成する暗号メッセージ制御ヘッダパケットを形成するステップを具備す る請求の範囲第１３５項記載の方法。 １３７．前記メッセージ制御ヘッダを入れるステップが、前記第２デバイスの 寄託センタの識別および前記第２デバイスの寄託認証の前記ディジタル識別コー ドを構成する暗号メッセージ制御ヘッダパケットを形成するステップを具備する 請求の範囲第１３６項記載の方法。 １３８．前記第１デバイスの寄託センタおよび前記第２デバイスの寄託センタ が同一であり、 前記メッセージ制御ヘッダを入れる前記ステップが、前記第１および第２デバ イスの寄託センタの識別および前記寄託認証のそれぞれの前記ディジタル識別コ ードを具備する暗号メッセージ制御ヘッダパケットを形成するステップを具備す る請求の範囲第１３７項記載の方法。 １３９．前記メッセージ制御ヘッダを入れるステップが、前記第１デバイスの 所有者の識別または前記第１デバイスのユーザの雇用者または監督者の識別を構 成する暗号メッセージ制御ヘッダを形成するステップをさらに具備する請求の範 囲第１３６項記載の方法。 １４０．前記メッセージ制御ヘッダを入れるステップが、前記第２デバイスの 所有者の識別または前記第２デバイスのユーザの雇用者または監督者の識別を構 成する暗号メッセージ制御ヘッダパケットを形成するステップをさらに具備する 請求の範囲第１３９項記載の方法。 １４１．前記第１デバイスおよび第２デバイスの前記所有者が、前記第１デバ イスおよび第２デバイスの前記ユーザの前記雇用者または監督者と同一であり、 前記メッセージ制御ヘッダを入れるステップが、前記所有者、雇用者または監 督者の識別、および前記寄託認証のそれぞれの前記ディジタル識別を構成する暗 号メッセージ制御ヘッダを形成するステップをさらに具備する請求の範囲第１４ ０項記載の方法。 １４２．前記第１デバイスによる前記メッセージ制御ヘッダの形成の日付およ び時刻を示す前記タイムスタンプを構成する暗号メッセージ制御ヘッダを形成す るステップをさらに具備する請求の範囲第１３６項記載の方法。 １４３．前記デバイスが、前記暗号通信および前記メッセージ制御ヘッダの作 成の日付および時刻を示すタイムスタンプを作成するための信用されたタイムク ロックを備え、 前記メッセージ制御ヘッダを入れるステップが、前記タイムスタンプの信頼度 を認証するステップをさらに具備する請求の範囲第１４２項記載の方法。 １４４．前記タイムスタンプの信頼度を認証する前記ステップが、前記タイム スタンプを作成するために前記タイムクロックの信頼度を公証する、上位権威に よる認証を発行することを具備する請求の範囲第１４３項記載の方法。 １４５．前記タイムスタンプを認証する前記ステップが、作成された前記タイ ムスタンプのそれぞれに前記タイムクロック認証を添付することをさらに具備す る請求の範囲第１４４項記載の方法。 １４６．前記上位権威タイムクロックが、全システム権威を構成する請求の範 囲第１４４項記載の方法。 １４７．前記上位権威タイムクロックが、前記デバイスの製造メーカーを構成 する請求の範囲第１４４項記載の方法。 １４８．前記上位権威タイムクロックは、寄託センタを構成する請求の範囲第 １４４項記載の方法。 １４９．前記信用されたタイムクロックが、前記タイムクロックの製造メーカ ーによってのみ設定または較正できる請求の範囲第１４３項記載の方法。 １５０．前記タイムクロックが、前記タイムクロックの製造メーカーにより許 可されたエンティティによってのみ設定または較正できる請求の範囲第１４３項 記載の方法。 １５１．盗聴装置設置許可を持つ前記外部エンティティによる前記暗号通信を モニタするステップをさらに具備する請求の範囲第１３６項記載の方法。 １５２．前記モニタするステップが、 前記外部エンティティによる前記暗号化された通信に割り込むステップと、 前記盗聴装置設置許可および前記メッセージ制御ヘッダを前記第１デバイスの 寄託センタに提示するステップと、 前記第１デバイスの寄託センタに寄託される、前記第１デバイスの前記対応す る暗号化キーペアの秘密キーを取得するステップと、 前記第１デバイスの前記秘密キーを前記暗号化された通信の復号化に使用する ステップとをさらに具備する請求の範囲第１５１項記載の方法。 １５３．前記提示するステップが、 前記メッセージ制御ヘッダから、前記第１デバイスの寄託センタの識別および 前記第１デバイスの寄託認証の前記ディジタル識別コードを抽出するステップと 、 前記盗聴装置設置許可および前記第１デバイスの寄託認証の前記ディジタル識 別コードを、前記第１デバイスから前記第１デバイスの寄託センタに提示するス テップとをさらに具備する請求の範囲第１５２項記載の方法。 １５４．前記第１デバイスが、前記暗号通信および前記メッセージ制御ヘッダ の作成の日付および時刻を示すタイムスタンプを作成するために信用されたタイ ムクロックを備え、 メッセージ制御ヘッダを入れる前記ステップが、 前記第１デバイスによる前記メッセージ制御ヘッダの形成の日付および実行を 示すタイムスタンプを構成する暗号メッセージ制御ヘッダパケットを形成するス テップと、 タイムスタンプを作成するために前記タイムクロックの信頼性を認証するステ ップとをさらに具備する請求の範囲第１５３項記載の方法。 １５５．前記信用されたタイムクロックが、前記タイムクロックの製造メーカ ーによってのみ設定または較正できる請求の範囲第１５４項記載の方法。 １５６．前記第１デバイスの前記秘密キーを前記通信の復号化に使用する前記 ステップが、前記外部エンティティにより実行される請求の範囲第１５１項記載 の方法。 １５７．前記第１デバイスの前記秘密キーを前記通信の復号化に使用する前記 ステップが、前記寄託センタにより実行される請求の範囲第１５２項記載の方法 。 １５８．前記盗聴装置設置許可が、少なくとも１つの事前に定義される制限を 条件とする請求の範囲第１５２項記載の方法。 １５９．前記少なくとも１つの事前に定義される制限が、前記盗聴装置設置許 可に、その以前に前記秘密キーを前記通信の復号化に使用するする前記ステップ が発生してはならない開始日付および時刻を含むような時間制約を具備する請求 の範囲第１５８項記載の方法。 １６０．前記少なくとも１つの事前に定義される制限が、前記盗聴装置設置許 可に、それ以降に前記秘密キーを前記通信の復号化に使用するする前記ステップ が発生してはならない終了日付および時刻を含むようなさらなる時間制約を具備 する請求の範囲第１５８項記載の方法。 １６１．前記少なくとも１つの事前に定義される制限が、前記盗聴装置設置許 可に、それ以降に前記秘密キーを前記通信の復号化に使用するする前記ステップ が発生してはならない終了日付および時刻を含むような時間制約を具備する請求 の範囲第１５８項記載の方法。 １６２．前記第１デバイスの秘密キーを取得する前記ステップが、 前記少なくとも一人の受託人から前記第１デバイスの秘密キーの前記少なくと も１つの部分を回収するステップと、 前記秘密キーの前記回収された部分から前記秘密キーを再構築するステップと をさらに具備する請求の範囲第１５２項記載の方法。 １６３．前記取得するステップが、前記寄託センタにより実行される請求の範 囲第１６２項記載の方法。 １６４．前記取得するステップが、前記外部エンティティにより実行される請 求の範囲第１６２項記載の方法。 １６５．前記分割するステップが、前記秘密キーを再構築するためには、Ｎ個 の部分すべてが必要となるように、前記秘密キーをＮ個の部分に分割するステッ プをさらに具備し、 前記秘密キーの前記少なくとも１つの部分を回収する前記ステップが、前記秘 密キーのＮ個の部分のすべてが回収されるように、前記少なくとも一人の受託人 のそれぞれから前記秘密キーの前記少なくとも１つの部分のそれぞれを回収する ステップを具備し、 前記秘密キーを再構築する前記ステップが、前記秘密キーの前記Ｎ個の回収さ れた部分のすべてから前記秘密キーを再構築するステップを具備する請求の範囲 第１６２項記載の方法。 １６６．前記秘密キーのＮ個の部分すべてを回収する前記ステップが、前記少 なくとも一人の受託人のそれぞれに対して、前記秘密キーを再構築する前記ステ ップが、前記外部エンティティにより実行されるように、前記少なくとも１つの デバイス秘密キー部分を含む前記外部エンティティへの通信を暗号化するステッ プをさらに具備する請求の範囲第１６２項記載の方法。 １６７．前記少なくとも１つのデバイス秘密キー部分を含む前記外部エンティ ティへの通信を暗号化する前記ステップが、前記受託人が前記通信にディジタル 署名するステップをさらに具備する請求の範囲第１６６項記載の方法。 １６８．前記秘密キーのＮ個の部分すべてを回収する前記ステップが、前記少 なくとも一人の受託人のそれぞれに対して、前記秘密キーを再構築する前記ステ ップが、前記寄託センタにより実行されるように、前記少なくとも１つの秘密キ ー部分を含む前記少なくとも１つの寄託センタに対する通信を暗号化するステッ プをさらに具備する請求の範囲第１６５項記載の方法。 １６９．前記少なくとも１つのデバイス秘密キー部分を含む前記寄託センタに 対する通信を暗号化する前記ステップが、前記受託人が前記通信にディジタル署 名するステップをさらに具備する請求の範囲第１６８項記載の方法。 １７０．前記分割するステップが、Ｍ＜Ｎの場合、前記秘密キーを再構築する ためにＭ個の部分だけが必要とされるように、前記秘密キーをＮ個の部分に分割 し、 前記秘密キーの前記少なくとも１つの部分を回収する前記ステップが、前記秘 密キーの少なくともＭ個の部分が回収されるように、前記少なくとも一人の受託 人から前記秘密キーの前記少なくとも１つの部分を回収し、 前記秘密キーを再構築する前記ステップが、前記秘密キーの前記少なくともＭ 個の回収される部分から前記秘密キーを再構築する請求の範囲第１６２項記載の 方法。 １７１．前記秘密キーの少なくともＭ個の部分を回収する前記ステップが、前 記秘密キーを再構築する前記ステップが前記外部エンティティにより実行される ように、前記少なくともひとりの受託人のそれぞれのために前記デバイス秘密キ ー部分を含む、前記外部エンティティに対する通信を暗号化するステップをさら に具備する請求の範囲第１７０項記載の方法。 １７２．前記デバイス秘密キー部分を含む前記外部エンティティに対する通信 を暗号化する前記ステップが、前記受託人が前記通信をディジタル署名するステ ップをさらに具備する請求の範囲第１７１項記載の方法。 １７３．前記秘密キーの少なくともＭ個の部分を回収する前記ステップが、前 記秘密キーを再構築する前記ステップが前記寄託センタにより実行されるように 、前記少なくともひとりの受託人のそれぞれのために、前記デバイス秘密キー部 分を含む前記少なくとも１つの寄託センタに対する通信を暗号化するステップを さらに具備する請求の範囲第１７０項記載の方法。 １７４．前記デバイス秘密キー部分を含む前記寄託センタに対する通信を暗号 化する前記ステップが、前記受託人が前記通信にディジタル署名するステップを さらに具備する請求の範囲第１７３項記載の方法。 １７５．前記メッセージ制御ヘッダを入れるステップが、前記第２デバイスの 寄託センタの識別および前記第２デバイスの寄託認証の前記ディジタル識別コー ドを構成する暗号メッセージ制御ヘッダパケットを形成するステップを具備する 請求の範囲第１３５項記載の方法。 １７６．前記メッセージ制御ヘッダを入れるステップが、前記第２デバイスの 所有者あるいは前記第２デバイスの雇用者または監督者の識別を構成する暗号メ ッセージ制御ヘッダパケットを形成するステップをさらに具備する請求の範囲第 １７５項記載の方法。 １７７．盗聴装置設置許可を持つ前記外部エンティティによる前記暗号通信を モニタするステップをさらに具備する請求の範囲第１７５項記載の方法。 １７８．前記モニタするステップが、 前記外部エンティティによる前記暗号化された通信に割り込むステップと、 前記盗聴装置許可および前記メッセージ制御ヘッダを前記第２デバイスの寄託 センタに提示するステップと、 前記第２デバイスの前記対応する暗号化キーペアの、前記第２デバイスの寄託 センタに寄託されている秘密キーを取得するステップと、 前記第２デバイスの前記秘密キーを前記暗号化された通信の復号化に使用する ステップとをさらに具備する請求の範囲第１７７項記載の方法。 １７９．前記提示するステップが、 前記メッセージ制御ヘッダから、前記第２デバイスの寄託センタの前記識別お よび前記第２デバイスの寄託認証の前記ディジタルコード識別を抽出するステッ プと、 前記盗聴装置設置許可および前記第２デバイスの寄託認証の前記ディジタルコ ード識別を前記第２デバイスの寄託センタに提示するステップとをさらに具備す る請求の範囲第１７８項記載の方法。 １８０．前記第１デバイスが、前記暗号通信および前記メッセージ制御ヘッダ の作成の日付および時刻を示すタイムスタンプを作成するために信用されたタイ ムクロックを備え、 前記メッセージ制御ヘッダを入れるステップが、 前記第１デバイスによる前記メッセージ制御ヘッダの作成の日付および時刻を 示すタイムスタンプを構成する暗号メッセージ制御ヘッダパケットを形成するス テップと、 タイムスタンプを作成する目的で前記タイムクロックの信頼性を認証するステ ップとを具備する請求の範囲第１７９項記載の方法。 １８１．前記タイムスタンプの信頼性を認証する前記ステップが、前記タイム スタンプを作成する目的で前記タイムクロックの信頼性を公証する上位権威によ る認証を発行することを具備する請求の範囲第１８０項記載の方法。 １８２．前記タイムスタンプを認証する前記ステップが、作成された前記タイ ムスタンプのそれぞれに前記タイムクロック認証を添付する請求の範囲第１８１ 項記載の方法。 １８３．前記上位権威が全システム権威を構成する請求の範囲第１８１項記載 の方法。 １８４．前記上位権威が前記デバイスの製造メーカーを構成する請求の範囲第 １８１項記載の方法。 １８５．前記上位権威が寄託センタを構成する請求の範囲第１８１項記載の方 法。 １８６．前記信用されるタイムクロックが、前記タイムクロックの製造メーカ ーによってだけ設定または較正できる請求の範囲第１８０項記載の方法。 １８７．前記信用されるタイムクロックが、製造メーカーによって指定される エンティティによってだけ再設定または再較正できる請求の範囲第１８０項記載 の方法。 １８８．前記第２デバイスの前記秘密キーを前記通信の復号化に使用する前記 ステップが、前記外部エンティティにより実行される請求の範囲第１７８項記載 の方法。 １８９．前記第２デバイスの前記秘密キーを前記通信の復号化に使用する前記 ステップが、前記寄託センタにより実行される請求の範囲第１７８項記載の方法 。 １９０．前記盗聴装置設置許可が、少なくとも１つの事前に定義される制約を 条件とする請求の範囲第１７８項記載の方法。 １９１．前記少なくとも１つの事前に定義される制約が、前記盗聴装置設置許 可に、その以前に前記第２デバイスの前記秘密キーを取得する前記ステップが発 生しない開始日付および時刻が含まれるような時間制約を具備する請求の範囲第 １９０項記載の方法。 １９２．前記少なくとも１つの事前に定義される制約が、前記盗聴装置設置許 可に、それ以降に前記第２デバイスの前記秘密キーを取得する前記ステップが発 生しない終了日付および時刻が含まれるようなさらなる時間制約を具備する請求 の範囲第１９０項記載の方法。 １９３．前記少なくとも１つの事前に定義される制約が、前記盗聴装置設置許 可に、その以降に前記第２デバイスの前記秘密キーを取得する前記ステップが発 生しない終了日付および時刻が含まれるような時間制約を具備する請求の範囲第 １９０項記載の方法。 １９４．前記第２デバイスの秘密キーを取得する前記ステップが、 前記少なくとも一人の受託人のそれぞれから前記第２デバイスの秘密キーの前 記少なくとも１つの部分を回収するステップと、 前記秘密キーの前記回収された部分から前記秘密キーを再構築するステップと をさらに具備する請求の範囲第１７８項記載の方法。 １９５．前記取得するステップが、前記寄託センタにより実行される請求の範 囲第１９４項記載の方法。 １９６．前記取得するステップが、前記外部エンティティにより実行される請 求の範囲第１９４項記載の方法。 １９７．前記分割するステップが、前記秘密キーを再構築するために、Ｎ個の 部分すべてが必要となるように、前記秘密キーをＮ個の部分に分割し、 前記秘密キーの前記少なくとも１つの部分を回収する前記ステップが、前記秘 密キーのＮ個の部分のすべてが回収されるように、前記少なくとも一人の受託人 のそれぞれから前記秘密キーの前記少なくとも１つの部分のそれぞれを回収し、 前記秘密キーを再構築する前記ステップが、前記秘密キーの前記Ｎ個の回収さ れた部分すべてから前記秘密キーを再構築する請求の範囲第１９４項記載の方法 。 １９８．前記秘密キーのＮ個すべての部分を回収する前記ステップが、前記少 なくとも一人の受託人のそれぞれのために、前記秘密キーを再構築する前記ステ ップが前記外部エンティティにより実行されるように、前記少なくとも１つのデ バイス秘密キー部分を含む前記外部エンティティに対する通信を暗号化するステ ップをさらに具備する請求の範囲第１９７項記載の方法。 １９９．前記少なくとも１つのデバイス秘密キー部分を含む前記外部エンティ ティに対する通信を暗号化する前記ステップが、前記受託人が前記通信にディジ タル署名するステップをさらに具備する請求の範囲第１９８項記載の方法。 ２００．前記秘密キーのＮ個の部分すべてを回収する前記ステップが、前記秘 密キーを再構築する前記ステップが前記寄託センタにより実行されるように、前 記すくなくとも一人の受託人のそれぞれのために、前記少なくとも１つのデバイ ス秘密キー許容部を含む前記少なくとも１つの寄託センタに対する通信を暗号化 するステップをさらに具備する請求の範囲第１９７項記載の方法。 ２０１．前記少なくとも１つのデバイス秘密キー部分を含む前記寄託センタに 対する通信を暗号化する前記ステップが、前記受託人が通信通信にディジタル署 名するステップをさらに具備する請求の範囲第２００項記載の方法。 ２０２．前記分割する方法が、Ｍ＜Ｎの場合、前記秘密キーを再構築するため にＭ個の部分だけが必要となるように、前記秘密キーをＮ庫の部分に分割し、 前記秘密キーの前記少なくとも１つの部分を回収する前記ステップが、前記秘 密キーの少なくともＭ個の部分が回収されるように、前記少なくとも一人の受託 人から前記秘密キーの前記少なくとも１つの部分を回収し、 前記秘密キーを再構築する前記ステップが、前記秘密キーの前記少なくともＭ 個の回収された部分から前記秘密キーを再構築する請求の範囲第１９４項記載の 方法。 ２０３．前記秘密キーの少なくともＭ個の部分を受け取る前記ステップが、前 記秘密キーを再構築する前記ステップが前記外部エンティティにより実行される ように、前記少なくとも一人の受託人のために、前記デバイス秘密キー部分を含 む前記外部エンティティに対する通信を暗号化するステップをさらに具備する請 求の範囲第２０２項記載の方法。 ２０４．前記デバイス秘密キーを含む前記外部エンティティに対する通信を暗 号化する前記ステップが、前記受託人が前記通信にディジタル署名するステップ をさらに具備する請求の範囲第２０３項記載の方法。 ２０５．前記秘密キーの少なくともＭ個の部分を受け取る前記ステップが、前 記秘密キーを再構築する前記ステップが前記寄託センタにより実行されるように 、前記少なくとも一人の受託人のそれぞれのために、前記デバイス秘密キー部分 を含む前記少なく後も１つの寄託センタに対する通信を暗号化するステップをさ らに具備する請求の範囲第２０２項記載の方法。 ２０６．前記デバイス秘密キー部分を含む前記寄託センタに対する前記暗号化 するステップが、前記受託人が前記通信にディジタル署名するステップをさらに 具備する請求の範囲第２０５項記載の方法。 ２０７．前記通信を暗号化するステップが、 前記第１デバイスと前記第２デバイスの間の暗号通信の暗号化および復号化両 方で使用するための一意の暗号化キーを作成するステップと、 前記第１デバイスによる前記暗号化キーを用いて前記第２デバイスに対する前 記通信を暗号化するステップとをさらに具備する請求の範囲第９４項記載の方法 。 ２０８．前記一意の暗号化キーを作成する前記ステップが、 前記第２デバイスの前記秘密キーおよび少なくとも１つの公開キーを使用して 、前記第２デバイスによる前記第２デバイスの中間番号を計算するステップと、 前記第１ユーザにより前記第２ユーザの中間番号を取得するステップと、 前記第１デバイスによる前記第１デバイスの前記秘密キーおよび前記第２デバ イスの前記中間番号を使用して前記暗号化キーを計算するステップとをさらに具 備し、 前記暗号化キーを使用して暗号化された前記第１デバイスから前記第２デバイ スへの前記通信が、前記暗号化キーを使用するだけで復号化できるようにする請 求の範囲第２０７項記載の方法。 ２０９．前記第２デバイスの前記秘密キーが前記第２デバイスにより無作為に 作成される請求の範囲第２０８項記載の方法。 ２１０．前記第２デバイスの前記中間番号が前記第２デバイスの前記公開キー を構成する請求の範囲第２０８項記載の方法。 ２１１．前記第２デバイスの前記中間番号および前記少なくとも１つの公開番 号が、前記第２デバイスの前記公開キーを具備する請求の範囲第２０８項記載の 方法。 ２１２．前記第１デバイスによる前記第１デバイスの前記秘密キーおよび前記 少なくとも１つの公開キーを使用して、前記第１デバイスの中間番号を計算する ステップをさらに具備する請求の範囲第２０８項記載の方法。 ２１３．前記第１デバイスの前記秘密キーが、前記第１デバイスにより無作為 に作成される請求の範囲第２１２項記載の方法。 ２１４．前記メッセージ制御ヘッダを入れるステップが、前記第１デバイスの 前記中間番号および前記少なくとも１つの公開番号を構成するメッセージ制御ヘ ッダパケットを形成するステップをさらに具備する請求の範囲第２１２項記載の 方法。 ２１５．前記第２デバイスにより前記暗号化された通信を復号化する前記ステ ップが、 前記第２デバイスによる前記第２デバイスの前記秘密キーおよび前記第１デバ イスの前記中間番号を使用して、前記暗号化キーを計算するステップと、 前記第２デバイスによる前記暗号化キーを使用して前記第１デバイスからの前 記通信を復号化するステップとを具備する請求の範囲第２１４項記載の方法。 ２１６．前記一意の暗号化キーを作成するステップが、前記第１デバイスおよ び第２デバイスのそれぞれにより対話で前記暗号化キーを作成するステップを具 備する請求の範囲第２０７項記載の方法。 ２１７．前記第１デバイスおよび第２デバイスのそれぞれにより対話で前記暗 号化キーを作成する前記ステップが、 前記第１デバイスの前記秘密キーおよび少なくとも１つの公開番号を使用して 、前記第１デバイスによる第１中間番号を計算するステップと、 前記第２デバイスによる前記第２デバイスの前記秘密キーおよび前記少なくと も１つの公開番号を使用して、前記中間番号を計算するステップと、 前記第１デバイスによる前記第１デバイスの前記秘密キーおよび前記第２中間 番号を使用して、前記暗号化キーを計算するステップと、 前記第２デバイスによる前記第２デバイスの前記秘密キーおよび前記第１中間 番号を使用して、前記暗号化キーを計算するステップとを具備し、 前記暗号化キーを使用して暗号化された前記第１デバイスから前記第２デバイ スまたは前記第２デバイスから前記第１デバイスへの前記通信が、前記暗号化キ ーだけを用いて復号化できるようにする請求の範囲第２１６項記載の方法。 ２１８．前記第１デバイスの前記秘密キーが前記第１デバイスにより無作為に 作成される請求の範囲第２１７項記載の方法。 ２１９．前記第２デバイスの前記秘密キーが前記第２デバイスにより無作為に 作成される請求の範囲第２１７項記載の方法。 ２２０．前記第２デバイスにより前記暗号化された通信を復号化する前記ステ ップが、さらに、前記暗号化キーを使用して、前記第１デバイスからの前記通信 の前記第２デバイスによる復号化のステップを具備する請求の範囲第２１７項記 載の方法。 ２２１．第１の対応するキーのペアの公開キーが、前記デバイスへの暗号通信 の暗号化に使用され、前記第１の対応するキーのペアの対応する秘密キーが前記 暗号通信の復号化に使用され、第２の対応するキーのペアの秘密キーがディジタ ルデータにディジタル署名するために使用され、前記第２の対応するキーのペア の対応する秘密キーが前記ディジタル署名の確認に使用される、それぞれの信用 されるデバイスが無作為に作成された非対称暗号化キーの少なくとも２つの対応 するペアを持つ、複数の信用されるデバイスを備える暗号システムにおける、外 部エンティティが前記通信をモニタできるようにしつつ、複数のユーザデバイス の間の認証できる信用された暗号通信を作成するための方法であって、 前記信用されたデバイスのそれぞれの少なくとも１つの秘密復号化キーを、少 なくとも１つの寄託センタに寄託するステップと、 前記少なくとも１つの寄託センタにより前記デバイスのそれぞれの前記少なく とも１つの秘密復号化キーの寄託を認証するステップと、 前記デバイスのそれぞれの少なくとも１つの秘密署名キーを認証するステップ と、 前記第２デバイスの公開暗号化キーを使用して、前記ユーザデバイスの第２に 対する前記ユーザデバイスの第１からの通信を暗号化するステップと、 前記少なくとも１つの信用された寄託センタを識別するのに十分な情報を含む メッセージ制御ヘッダを、前記暗号化された通信で入れるステップと、 前記第２デバイスの秘密復号化キーを使用して、前記第２デバイスによる前記 暗号化された通信を復号化するステップとを具備し、 前記第２デバイスによる前記暗号化された通信を復号化する前記ステップが、 前記第１デバイスおよび第２デバイスのそれぞれの前記秘密復号化キーの認証お よび有効なメッセージ制御ヘッダの前記通信内での存在を条件とする方法。 ２２２．前記第１デバイスからの通信を暗号化する前記ステップが、前記第１ デバイスおよび第２デバイスのそれぞれの前記秘密復号化キーの認証および有効 なメッセージ制御ヘッダの前記通信内での存在を条件とする請求の範囲第２２１ 項記載の方法。 ２２３．前記通信が、記憶のために前記第１デバイスからそれ自体に暗号化さ れるように、前記第１デバイスおよび前記第２デバイスが同一である請求の範囲 第２２１項記載の方法。 ２２４．前記それぞれの信用されたデバイスが、前記少なくとも２つの対応す る暗号化キーのペアを暗号化および復号化のために、ならびに署名および確認の ために無作為に作成する能力と、安全な不正な動きを防止する、読み取ることが できないやり方で前記キーのペアのそれぞれを記憶する能力を備える請求の範囲 第２２１項記載の方法。 ２２５．それぞれの前記信用されたデバイスに製造メーカーがあり、少なくと も１つの秘密署名キーを認証する前記ステップが、さらに、上位権威による前記 デバイスの前記キーを無作為に作成し記憶する能力を認証するステップを具備す る請求の範囲第２２４項記載の方法。 ２２６．前記デバイスの能力を認証する前記ステップが、さらに、前記製造メ ーカーの信頼性および前記製造メーカーにより製造されるデバイスの前記キーを 読み取ることができない不正な動きを防止するやり方で無作為に作成、記憶する 能力を公証する、前記上位権威による製造メーカー認証を発行するステップを具 備する請求の範囲第２２５項記載の方法。 ２２７．前記上位権威が全システム権威を構成する請求の範囲第２２６項記載 の方法。 ２２８．前記製造メーカー認証が、前記製造メーカーにより作成された秘密署 名キーを使用して発行された各署名に添付される請求の範囲第２２６項記載の方 法。 ２２９．上位権威による前記少なくとも１つの寄託センタの信頼性を認証する ステップをさらに具備する請求の範囲第２２１項記載の方法。 ２３０．前記寄託センタを認証するステップが、寄託する目的で前記寄託セン タの信頼性を公証する、前記少なくとも１つの寄託センタのそれぞれに対する前 記上位権威による認証を発行するステップを具備する請求の範囲第２２９項記載 の方法。 ２３１．前記上位権威が全システム権威を構成する請求の範囲第２３０項記載 の方法。 ２３２．前記上位権威がデバイスの少なくとも１つの製造メーカーを構成する 請求の範囲第２３０項記載の方法。 ２３３．前記寄託するステップが、各ユーザデバイスのために、 前記秘密復号化キーを部分に分割するステップと、 少なくとも一人の受託人のそれぞれに、前記秘密キーの少なくとも１つの部分 を提供するステップと、 前記少なくとも一人の受託人のそれぞれに、前記受託人が前記秘密キーの前記 少なくとも１つの部分の正しい受領を確認できるようにする確認情報を提供する ステップと、 前記少なくとも１つの寄託センタによる、前記秘密キーの前記少なくとも１つ の部分の前記少なくとも一人の受託人のそれぞれによる正しい受領を確認するス テップとをさらに具備する請求の範囲第２２１項記載の方法。 ２３４．前記少なくとも１つの寄託センタのそれぞれが、信用されるデバイス を構成し、暗号化する前記ステップが、前記分割するステップが前記寄託センタ により実行される容易、前記ユーザ秘密復号化キーを含む前記少なくとも１つの 寄託センタに対する通信を暗号化するステップをさらに具備する請求の範囲第２ ３３項記載の方法。 ２３５．前記分割するステップが、前記秘密キーを再構築するためにＮ個の部 分のすべてが必要とされるように、前記秘密キーをＮ個の部分に分割する請求の 範囲第２３４項記載の方法。 ２３６．前記分割するステップが、Ｍ＜Ｎの場合、前記秘密キーを再構築する ためにＭ個の部分だけが必要とされるように、前記秘密キーをＮ個の部分に分割 する請求の範囲第２３４項記載の方法。 ２３７．唯一の寄託センタの公開暗号化キーが、前記寄託センタが寄託を行う 目的で前記製造メーカーにより選択されるように、前記デバイスの製造メーカー により前記ユーザデバイスの中に事前に埋め込まれており、 前記寄託するステップが、前記事前に埋め込まれた寄託センタ暗号化キーを使 用して、前記寄託センタに対する通信を暗号化するステップをさらに具備する請 求の範囲第２３４項記載の方法。 ２３８．少なくとも１つの寄託センタの公開暗号化キーが、少なくとも１つの 寄託センタのグループが、寄託を行う目的で前記製造メーカーにより選択される ように、前記デバイスの製造メーカーにより前記ユーザデバイスの中に事前に埋 め込まれ、 寄託する前記ステップが、前記事前に埋め込まれた寄託センタ公開暗号化キー の１つを使用して、少なくとも１つの寄託センタの前記グループの１つに対する 前記秘密キーの少なくとも１つの部分を含む通信を暗号化するステップをさらに 具備する請求の範囲第２３４項記載の方法。 ２３９．前記少なくとも１つの寄託センタの前記暗号化キーが、寄託認証ディ レクトリから前記ユーザデバイスにより取得される請求の範囲第２３４項記載の 方法。 ２４０．前記ユーザデバイス秘密暗号化キーを含む前記少なくとも１つの寄託 センタに対する通信を暗号化する前記ステップが、前記秘密デバイス署名キーを 使用して、前記デバイスが前記通信にディジタル署名するステップをさらに具備 する請求の範囲第２３４項記載の方法。 ２４１．前記少なくとも一人の受託人のそれぞれに前記秘密キーの少なくとも １つの部分を提供する前記ステップが、前記寄託センタが、前記少なくとも１つ の受託人のそれぞれに対する前記秘密キーの前記少なくともつの部分を含む通信 を暗号化するステップをさらに具備する請求の範囲第２３４項記載の方法。 ２４２．前記デバイス秘密キーの前記少なくとも１つの部分を含む前記少なく とも一人の受託人のそれぞれに対する通信を暗号化する前記ステップが、前記寄 託センタが前記通信にディジタル署名するステップをさらに具備する請求の範囲 第２４１項記載の方法。 ２４３．前記少なくとも一人の受託人のそれぞれに確認情報を提供するステッ プが、前記秘密キーの前記少なくとも１つの部分を含む前記少なくとも一人の受 託人のそれぞれに対する前記通信に前記確認情報を入れる請求の範囲第２４１項 記載の方法。 ２４４．前記少なくとも一人の受託人のそれぞれに対する通信を暗号化する前 記ステップが、前記寄託センタが前記通信にディジタル署名するステップをさら に具備する請求の範囲第２４３項記載の方法。 ２４５．少なくとも一人の受託人のそれぞれが信用されたデバイスを構成し、 前記分割するステップが、前記デバイスにより実行される請求の範囲第２３３項 記載の方法。 ２４６．前記秘密キーを再構築するためにＮ個の部分のすべてが必要となるよ うに、前記秘密キーをＮ個の部分に分割することを具備する請求の範囲第２４５ 項記載の方法。 ２４７．前記分割するステップが、Ｍ＜Ｎの場合に、前記秘密キーを再構築す るためにＭ個の部分だけが必要とされるように、前記秘密キーをＮ個の部分に分 割する請求の範囲第２４５項記載の方法。 ２４８．前記少なくとも一人の受託人の公開暗号化キーが、少なくとも一人の 受託人のグループが、寄託を行う目的で前記製造メーカーにより選択されるよう に、前記デバイスの製造メーカーによる前記ユーザデバイスの中に事前に埋め込 まれ、 少なくとも一人の受託人のそれぞれに、前記秘密キーの少なくとも１つの部分 を提供する前記ステップが、さらに、前記事前に埋め込まれた受託人の公開暗号 化キーを使用して、少なくとも一人の受託人の前記グループの間から、少なくと も一人の受託人のそれぞれに対する前記秘密キーの少なくとも１つの部分を含む 通信を前記デバイスが暗号化するステップを具備する請求の範囲第２４５項記載 の方法。 ２４９．前記少なくとも一人の受託人のそれぞれに対する通信を暗号化する前 記ステップが、さらに、前記ユーザデバイスが前記通信にディジタル署名するス テップを具備する請求の範囲第２４８項記載の方法。 ２５０．前記少なくとも一人の受託人のそれぞれに前記秘密キーの少なくとも １つの部分を提供する前記ステップが、前記秘密キーの部分を前記ユーザデバイ スから受け取った前記少なくとも一人の受託人のそれぞれの識別を構成する、前 記確認ステップの中で後で使用するための、前記寄託センタに対する通信を前記 ユーザデバイスが暗号化するステップを具備する請求の範囲第２４８項記載の方 法。 ２５１．前記少なくとも一人の受託人のそれぞれに確認情報を提供する前記ス テップが、前記秘密キーの前記少なくとも１つの部分を含む前記少なくとも一人 の受託人のそれぞれに対する前記通信の中に、前記ユーザデバイスが前記確認情 報を入れることを具備する請求の範囲第２４８項記載の方法。 ２５２．前記少なくとも一人の受託人のそれぞれに対する通信を暗号化する前 記ステップが、前記ユーザデバイスが前記通信にディジタル署名するステップを さらに具備する請求の範囲第２５１項記載の方法。 ２５３．前記少なくとも１つの寄託センタによる前記確認するステップが、各 受託人のために、 前記ユーザデバイスの前記秘密キーの前記少なくとも１つの部分の受領を前記 寄託センタに対して前記受託人により通知するステップと、 前記受託人による前記確認情報を前記寄託センタに対して通信するステップと 、 前記確認情報の前記受託人による正しい通信に基づき、前記秘密キーの前記少 なくとも１つの部分の前記受託人による正しい受領を前記寄託センタにより確証 するステップとを具備する請求の範囲第２３３項記載の方法。 ２５４．前記受託人による前記確認情報を通信する前記ステップが、前記受託 人が前記確認情報を含む前記寄託センタに対する通信を暗号化するステップを具 備する請求の範囲第２５３項記載の方法。 ２５５．前記確認情報を含む前記寄託センタに対する通信を暗号化する前記ス テップが、前記受託人が前記通信をディジタル署名するステップをさらに具備す る請求の範囲第２５４項記載の方法。 ２５６．前記少なくとも１つの秘密復号化キーの寄託を認証する前記ステップ が、前記公開キーおよび前記秘密キーならびに前記対応するデバイスの間のつな がりを公証し、前記対応するキーペアの前記秘密復号化キーが寄託されているこ とを保証する、各前記ユーザデバイスの対応するキーペアごとに１つの寄託セン タによる寄託認証を発行するステップをさらに具備する請求の範囲第２３３項記 載の方法。 ２５７．前記秘密復号化キーの寄託を認証する前記ステップが、前記寄託認証 を発行する前記ステップの前に、前記秘密復号化キーの寄託を確証するステップ をさらに具備する請求の範囲第２５６項記載の方法。 ２５８．前記秘密復号化キーの寄託を確証する前記ステップが、各受託人のた めに、 前記デバイスの秘密復号化キーの前記少なくとも１つの部分の前記歌句人によ る受領を前記寄託センタに通知するステップと、 前記受託人による前記確認情報を前記寄託センタに通信するステップと、 前記確認情報の前記受託人による正しい通信に基づいて、前記デバイスの秘密 復号化キーの前記少なくとも１つの部分の前記受託人による正しい受領を前記寄 託センタにより確認するステップとを具備する請求の範囲第２５７項記載の方法 。 ２５９．前記寄託センタが信用されたデバイスを構成し、前記確認情報を前記 受託人により前記寄託センタに通信するステップが、前記確認情報を含む前記寄 託センタに対する通信を暗号化するステップを具備する請求の範囲第２５８項記 載の方法。 ２６０．前記受託人が信用されたデバイスを構成し、前記寄託センタに対する 通信を暗号化するステップが、前記受託人が秘密署名キーを使用して前記通信に ディジタル署名するステップをさらに具備する請求の範囲第２５９項記載の方法 。 ２６１．前記確認するステップが、前記確認情報を含む前記通信上の受託人の 署名を確認することをさらに具備する請求の範囲第２６０項記載の方法。 ２６２．前記寄託認証が前記認証発行寄託センタの識別、前記寄託認証のディ ジタル識別コード、および前記寄託された秘密復号化キーに対応する前記公開暗 号化キーを構成する請求の範囲第２５６項記載の方法。 ２６３．前記暗号化された通信でメッセージ制御ヘッダを入れる前記ステップ が、前記第１ユーザデバイスの寄託センタの識別および前記第１ユーザデバイス の寄託認証の前記ディジタル識別コードを構成する暗号メッセージ制御ヘッダパ ケットを形成するステップを具備する請求の範囲第２６２項記載の方法。 ２６４．前記メッセージ制御ヘッダを入れるステップが、前記第２ユーザデバ イスの寄託センタの識別および前記第２ユーザデバイスの寄託認証の前記ディジ タルコード識別を構成する暗号メッセージ制御ヘッダを形成するステップをさら に具備する請求の範囲第２６３項記載の方法。 ２６５．前記第１デバイスの寄託センタおよび前記第２ユーザデバイスの寄託 センタが同一であり、 メッセージ制御ヘッダを入れる前記ステップが、さらに、前記第１デバイスお よび第２デバイスの寄託センタの識別および前記寄託認証のそれぞれの前記ディ ジタルコード識別を形成するステップを具備する請求の範囲第２６４項記載の方 法。 ２６６．前記メッセージ制御ヘッダを入れるステップが、前記第１ユーザデバ イスの所有者の識別または前記１ユーザデバイスのユーザの雇用者または監督者 の識別を構成する暗号メッセージ制御ヘッダパケットを形成するステップをさら に具備する請求の範囲第２６３項記載の方法。 ２６７．前記メッセージ制御ヘッダを入れるステップが、前記第２ユーザデバ イスの所有者の識別または前記第２ユーザデバイスのユーザの雇用者または監督 者の識別を構成する暗号メッセージ制御ヘッダパケットを形成するステップをさ らに具備する請求の範囲第２６６項記載の方法。 ２６８．前記第１および第２ユーザデバイスの前記所有者または前記第１およ び第２ユーザデバイスの前記ユーザの前記雇用者または監督者が同一であり、 前記メッセージ制御ヘッダを入れるステップが、前記所有者、雇用者または監 督者の識別および前記寄託認証のそれぞれの前記ディジタルコード識別を構成す る暗号メッセージ制御ヘッダパケットを形成するステップをさらに具備する請求 の範囲第２６７項記載の方法。 ２６９．前記メッセージ制御ヘッダを入れるステップが、前記第１ユーザデバ イスによる前記メッセージ制御ヘッダの作成の日付および時刻を示すタイムスタ ンプを構成する暗号メッセージ制御ヘッダパケットを形成するステップを具備す る請求の範囲第２６３項記載の方法。 ２７０．前記各信用されたデバイスが、前記暗号通信および前記メッセージ制 御ヘッダの日付および時刻を示すタイムスタンプを作成するためにタイムクロッ クを具備し、 前記メッセージ制御ヘッダを入れるステップが、前記タイムスタンプの信頼性 を認証するステップをさらに具備する請求の範囲第２６９項記載の方法。 ２７１．前記タイムスタンプの信頼性を認証するステップが、前記タイムスタ ンプを作成する目的で前記タイムクロックの信頼性を公証する上位権威による認 証を発行する請求の範囲第２７０項記載の方法。 ２７２．前記タイムスタンプを認証するステップが、作成された前記タイムス タンプのそれぞれに前記タイムクロック認証を添付する請求の範囲第２７１項記 載の方法。 ２７３．前記上位権威タイムクロックが全システム権威を具備する請求の範囲 第２７１項記載の方法。 ２７４．前記上位権威タイムクロックが前記デバイスの製造メーカーを具備す る請求の範囲第２７１項記載の方法。 ２７５．前記信用されたタイムクロックが前記タイムクロックの製造メーカー によってのみ設定または較正できる請求の範囲第２７０項記載の方法。 ２７６．盗聴装置設置許可を持つ前記外部エンティティにより前記暗号通信を モニタするステップをさらに具備する請求の範囲第２６３項記載の方法。 ２７７．前記モニタするステップが、 前記外部エンティティによる前記暗号化された通信に割り込むステップと、 前記第１ユーザデバイスの寄託センタに対して、前記盗聴装置設置許可および 前記メッセージ制御ヘッダを提示するステップと、 前記第１ユーザデバイスの寄託センタに寄託されている前記第１ユーザデバイ スの秘密復号化キーを取得するステップと、 前記第１ユーザデバイスの前記秘密復号化キーを前記暗号化された通信の復号 化に使用するステップとをさらに具備する請求の範囲第２７６項記載の方法。 ２７８．前記提示するステップが、 前記メッセージ制御ヘッダから、前記第１ユーザデバイスの寄託センタの前記 識別および前記第１ユーザデバイスの寄託認証の前記ディジタル識別コードを抽 出するステップと、 前記盗聴装置設置許可および前記第１ユーザデバイスの寄託認証の前記ディジ タル識別コードを、前記ユーザデバイスの寄託センタに提示するステップとをさ らに具備する請求の範囲第２７７項記載の方法。 ２７９．前記第１ユーザデバイスが、前記暗号通信および前記メッセージ制御 ヘッダの形成の日付および時刻を示すタイムスタンプを形成作成するために信用 されたタイムクロックを備え、 前記メッセージ制御ヘッダを入れるステップが、 タイムスタンプを構成する暗号メッセージ制御ヘッダパケットを形成するステ ップと、 タイムスタンプを作成する目的で前記タイムクロックの信頼性を認証するステ ップとをさらに具備する請求の範囲第２７８項記載の方法。 ２８０．前記タイムスタンプの信頼性を認証する前記ステップが、前記タイム スタンプを作成する目的で、前記タイムクロックの信頼性を公証する、上位権威 による認証を発行する請求の範囲第２７９項記載の方法。 ２８１．前記タイムスタンプを認証する前記ステップが、作成された前記タイ ムスタンプのそれぞれに前記タイムクロックを添付する請求の範囲第２８０項記 載の方法。 ２８２．前記上位権威タイムクロックが全システム権威を具備する請求の範囲 第２８０項記載の方法。 ２８３．前記信用されたタイムクロックが、製造タイムクロックの製造メーカ ーによってのみ設定または較正できる請求の範囲第２７９項記載の方法。 ２８４．前記第１ユーザデバイスの前記秘密復号化キーを前記第１ユーザデバ イスの復号化に使用する前記ステップが、前記外部エンティティにより実行され る請求の範囲第２７７項記載の方法。 ２８５．前記第１ユーザデバイスの前記秘密復号化キーを前記通信の復号化に 使用する前記ステップが、前記寄託センタにより実行される請求の範囲第２７７ 項記載の方法。 ２８６．前記盗聴装置設置許可が、少なくとも１つの事前定義された制限を条 件とする請求の範囲第２７７項記載の方法。 ２８７．前記少なくとも１つの事前に定義される制約が、前記盗聴装置設置許 可に、それ以前は前記第１デバイスの前記秘密キーを取得する前記ステップが発 生してはならない開始日付および時刻を含むような時間制約を具備する請求の範 囲第２８６項記載の方法。 ２８８．前記少なくとも１つの事前に定義される制約が、前記盗聴装置設置許 可に、それ以降は前記第１デバイスの前記秘密キーを取得する前記ステップが発 生してはならない終了日付および時刻を含むようなさらなる時間制約を具備する 請求の範囲第２８７項記載の方法。 ２８９．前記少なくとも１つの事前に定義される制約が、前記盗聴装置設置許 可に、それ以降は前記第１デバイスの前記秘密キーを取得する前記ステップが発 生してはならない終了日付および時刻を含むような時間制約を具備する請求の範 囲第２８６項記載の方法。 ２９０．前記第１デバイスの秘密キーを取得する前記ステップが、 前記第１ユーザデバイスの秘密キーの前記少なくとも１つの部分を前記少なく とも一人の受託人から回収するステップと、 前記秘密キーの前記回収された部分から前記秘密キーを再構築するステップと を具備する請求の範囲第２７７項記載の方法。 ２９１．前記取得するステップが、前記寄託センタにより実行される請求の範 囲第２９０項記載の方法。 ２９２．前記取得するステップが、前記外部エンティティにより実行される請 求の範囲第２９０項記載の方法。 ２９３．前記分割するステップが、前記秘密キーを再構築するためにＮ個の部 分のすべてが必要とされるように、前記秘密キーをＮ個の部分に分割し、 前記秘密キーの前記少なくとも１つの部分を回収する前記ステップが、前記秘 密キーのＮ個の部分のすべてが必要とされるように、前記秘密キーの前記少なく とも一人の受託人から前記少なくとも１つの部分のそれぞれを回収し、 前記秘密キーを再構築する前記ステップが、前記秘密キーの前記Ｎ個の回収さ れた部分のすべてから前記秘密キーを再構築する請求の範囲第２９０項記載の方 法。 ２９４．前記秘密キーのＮ個の部分すべてを回収する前記ステップが、前記秘 密キーを再構築する前記ステップが、前記外部エンティティにより実行されるよ うに、前記少なくとも一人の受託人のそれぞれに対して、前記少なくとも１つの デバイス秘密キー部分を含む前記外部エンティティに対する通信を暗号化するス テップをさらに具備する請求の範囲第２９３項記載の方法。 ２９５．前記少なくとも１つのデバイス秘密キー部分を含む前記外部エンティ ティに対する通信を暗号化する前記ステップが、前記受託人が前記通信にディジ タル署名するステップをさらに具備する請求の範囲第２９３項記載の方法。 ２９６．前記秘密キーのＮ個の部分すべてを回収する前記ステップが、前記秘 密キーを再構築する前記ステップが、前記寄託センタにより実行されるように、 前記少なくとも１つのデバイス秘密キー部分を含む前記少なくとも１つの寄託セ ンタに対する通信を暗号化するステップをさらに具備する請求の範囲第２９３項 記載の方法。 ２９７．前記少なくとも１つのデバイス秘密キー部分を含む前記寄託センタに 対する通信を暗号化する前記ステップが、前記受託人が前記通信にディジタル署 名するステップをさらに具備する請求の範囲第２９６項記載の方法。 ２９８．分割する前記ステップが、Ｍ＜Ｎの場合、前記秘密キーを再構築する ためにＭ個の部分だけが必要とされるように、前記秘密キーをＮ個の部分に分割 し、 前記秘密キーの前記少なくとも１つの部分を回収する前記ステップが、前記秘 密キーの少なくともＭ個の部分が回収されるように、前記少なくとも一人の受託 人から前記秘密キーの前記少なくとも１つの部分を回収し、 前記秘密キーを再構築する前記ステップが、前記秘密キーの前記少なくともＭ 個の回収された部分から前記秘密キーを再構築する請求の範囲第２９０項記載の 方法。 ２９９．前記秘密キーの少なくともＭ個の部分を回収する前記ステップが、前 記秘密キーを再構築する前記ステップが前記外部エンティティにより実行される ように、前記少なくとも一人の受託人のそれぞれのために、前記デバイス秘密キ ー部分を含む前記外部エンティティに対する通信を暗号化するステップをさらに 具備する請求の範囲第２９８項記載の方法。 ３００．前記デバイス秘密キー部分を含む前記外部エンティティに対する通信 を暗号化する前記ステップが、前記受託人が前記通信にディジタル署名するステ ップをさらに具備する請求の範囲第２９９項記載の方法。 ３０１．前記秘密キーの少なくともＭ個の部分を回収する前記ステップが、前 記秘密キーを再構築する前記ステップが前記寄託センタにより実行されるように 、前記少なくとも一人の受託人のそれぞれのために、前記デバイス秘密キー部分 を含む前記少なくとも１つの寄託センタに対する通信を暗号化するステップをさ らに具備する請求の範囲第２９８項記載の方法。 ３０２．前記デバイス秘密キー部分を含む前記寄託センタに対する通信を暗号 化する前記ステップが、前記受託人が前記通信にディジタル署名するステップを さらに具備する請求の範囲第３０１項記載の方法。 ３０３．前記暗号化された通信でメッセージ制御ヘッダを入れる前記ステップ が、前記第２ユーザデバイスの寄託センタの識別および前記第２デバイスの寄託 認証の前記ディジタル識別コードを構成する暗号メッセージ制御ヘッダパケット を形成するステップを具備する請求の範囲第２６２項記載の方法。 ３０４．前記メッセージ制御ヘッダを入れるステップが、前記第２ユーザデバ イスの所有者の識別または前記第２ユーザデバイスのユーザの雇用者または監督 者の識別を構成する暗号メッセージ制御ヘッダパケットを形成するステップをさ らに具備する請求の範囲第３０３項記載の方法。 ３０５．盗聴装置設置許可を持つ前記外部エンティティによる前記暗号通信を モニタするステップをさらに具備する請求の範囲第３０３項記載の方法。 ３０６．前記モニタするステップが、 前記外部エンティティによる前記暗号化された通信に割り込むステップと、 前記盗聴装置設置許可および前記メッセージ制御ヘッダを前記第２ユーザデバ イスの寄託センタに提示するステップと、 前記第２ユーザデバイスの寄託センタに寄託されている前記第２ユーザデバイ スの秘密復号化キーを取得するステップと、 前記第２ユーザデバイスの前記秘密復号化キーを前記暗号化された通信の復号 化に使用するステップとをさらに具備する請求の範囲第３０５項記載の方法。 ３０７．前記提示するステップが、 前記メッセージ制御ヘッダから、前記第２ユーザデバイスの寄託センタの前記 識別および前記第２ユーザデバイスの寄託認証の前記ディジタル識別コードを抽 出するステップと、 前記盗聴装置設置許可および前記第２ユーザデバイスの寄託認証の前記ディジ タル識別コードを前記第２デバイスの寄託センタに提示するステップとをさらに 具備する請求の範囲第３０６項記載の方法。 ３０８．前記第１デバイスが、前記暗号通信および前記メッセージ制御ヘッダ の作成の日付および時刻を示すタイムスタンプを作成するために信用されたタイ ムクロックを備え、 前記メッセージ制御ヘッダを入れる前記ステップが、 タイムスタンプを構成するメッセージ制御ヘッダパケットを形成するステップ と、 タイムスタンプを作成する目的で前記タイムクロックの信用性を認証するステ ップとをさらに具備する請求の範囲第３０７項記載の方法。 ３０９．前記タイムスタンプの信頼性を認証する前記ステップが、前記タイム スタンプを作成する目的で前記タイムクロックの信頼性を公証する上位権威によ る認証を発行する請求の範囲第３０９項記載の方法。 ３１０．前記タイムスタンプを認証するステップが、作成された前記タイムス タンプのそれぞれに前記タイムクロック認証を添付する請求の範囲第３０９項記 載の方法。 ３１１．前記上位権威タイムクロックが全システム権威を具備する請求の範囲 第３０９項記載の方法。 ３１２．前記上位権威タイムクロックが前記デバイスの製造メーカーを具備す る請求の範囲第３０９項記載の方法。 ３１３．前記信用されたタイムクロックが、前記タイムクロックの製造メーカ ーによってのみ設定または較正できる請求の範囲第３０８項記載の方法。 ３１４．前記第２ユーザデバイスの前記秘密復号化キーを前記通信の復号化に 使用する前記ステップが、前記外部エンティティにより実行される請求の範囲第 ３０６項記載の方法。 ３１５．前記第２ユーザデバイスの前記秘密復号化キーを前記通信の復号化に 使用する前記ステップが、前記寄託センタにより実行される請求の範囲第３０６ 項記載の方法。 ３１６．前記盗聴装置設置許可が、少なくとも１つの事前に定義された制約を 条件とする請求の範囲第３０６項記載の方法。 ３１７．前記少なくとも１つの事前に定義された制約が、前記盗聴装置設置許 可に、それ以前に前記第２デバイスの前記秘密キーを取得する前記ステップが発 生してはならない開始日付および時刻が含まれるように時間制約を具備する請求 の範囲第３１６項記載の方法。 ３１８．前記少なくとも１つの事前に定義された制約が、前記盗聴装置設置許 可に、それ以降に前記第２デバイスの前記秘密キーを取得する前記ステップが発 生してはならない終了日付および時刻が含まれるようなさらなる時間制約を具備 する請求の範囲第３１７項記載の方法。 ３１９．前記少なくとも１つの事前に定義された制約が、前記盗聴装置設置許 可に、それ以降に前記第２デバイスの前記秘密キーを取得する前記ステップが発 生してはならない終了日付および時刻が含まれるような時間制約を具備する請求 の範囲第３１７項記載の方法。 ３２０．前記第２ユーザデバイスの秘密復号化キーを取得する前記ステップが 、 前記少なくとも一人の受託人のそれぞれから、前記第２ユーザデバイスの秘密 キーの前記少なくとも１つの部分を回収するステップと、 前記秘密キーの前記回収された部分から前記秘密キーを再構築するステップと をさらに具備する請求の範囲第３０６項記載の方法。 ３２１．前記取得するステップが、前記寄託センタにより実行される請求の範 囲第３２０項記載の方法。 ３２２．前記取得するステップが、前記外部エンティティにより実行される請 求の範囲第３２０項記載の方法。 ３２３．前記分割するステップが、前記秘密キーを再構築するにはＮ個の部分 すべてが必要とされるように前記秘密キーをＮ個の部分に分割し、 前記秘密キーの前記少なくとも１つの部分を回収する前記ステップが、前記秘 密キーのＮ個の部分のすべてが回収されるように、前記少なくとも一人の受託人 のそれぞれから前記秘密キーの前記少なくとも１つの部分のそれぞれを回収し、 前記秘密キーを再構築する前記ステップが、前記秘密キーの前記Ｎ個の回収さ れた部分すべてから前記秘密キーを再構築する請求の範囲第３２０項記載の方法 。 ３２４．前記秘密キーのＮ個の部分のすべてを回収する前記ステップが、前記 秘密キーを再構築する前記ステップが前記外部エンティティにより実行されるよ うに、前記少なくとも一人の受託人のそれぞれのために、前記少なくとも１つの デバイス秘密キー部分を含む前記外部エンティティに対する通信を暗号化するス テップをさらに具備する請求の範囲第３２３項記載の方法。 ３２５．前記少なくとも１つのデバイス秘密キー部分を含む前記外部エンティ ティに対する通信を暗号化する前記ステップが、前記受託人が前記通信にディジ タル署名するステップをさらに具備する請求の範囲第３２４項記載の方法。 ３２６．前記秘密キーのＮ個の部分すべてを回収する前記ステップが、前記秘 密キーを再構築する前記ステップが、前記寄託センタにより実行されるように、 前記少なくとも一人の受託人のそれぞれのために、前記少なくとも１つのデバイ ス秘密キー部分を含む前記少なくとも１つの寄託センタに対する通信を暗号化す るステップをさらに具備する請求の範囲第３２３項記載の方法。 ３２７．前記少なくとも１つのデバイス秘密キー部分を含む前記寄託センタに 対する通信を暗号化する前記ステップが、前記受託人が前記通信にディジタル署 名するステップをさらに具備する請求の範囲第３２６項記載の方法。 ３２８．前記分割するステップが、Ｍ＜Ｎの場合、前記秘密キーを再構築する ためにＭ個の部分だけが必要とされるように、前記秘密キーをＮ個の部分に分割 し、 前記秘密キーの前記少なくとも１つの部分を回収する前記ステップが、前記秘 密キーの少なくともＭ個の部分が回収されるように、前記すくなくとも一人の受 託人から前記秘密キーの前記少なくとも１つの部分を回収し、 前記秘密キーを再構築する前記ステップが、前記秘密キーの前記少なくともＭ 個の回収された部分から前記秘密キーを再構築する請求の範囲第３２０項記載の 方法。 ３２９．前記秘密キーの少なくともＭ個の部分を回収する前記ステップが、前 記秘密キーを再構築する前記ステップが前記外部エンティティにより実行される ように、前記少なくとも一人の受託者のそれぞれのために、前記デバイス秘密キ ー部分を含む前記外部エンティティに対する通信を暗号化するステップを具備す る請求の範囲第３２８項記載の方法。 ３３０．前記デバイス秘密キー部分を含む前記外部エンティティに対する通信 を暗号化する前記ステップが、前記受託人が前記通信にディジタル署名するステ ップをさらに具備する請求の範囲第３２９項記載の方法。 ３３１．前記秘密キーの少なくともＭ個の部分を回収する前記ステップが、前 記秘密キーを再構築する前記ステップが前記寄託センタにより実行されるように 、前記少なくとも一人の受託人のそれぞれのために、前記デバイス秘密キー部分 を含む前記少なくとも１つの寄託センタに対する通信を暗号化するステップをさ らに具備する請求の範囲第３２８項記載の方法。 ３３２．前記デバイス秘密キー部分を含む前記寄託センタに対する通信を暗号 化する前記ステップが、前記受託人が前記通信にディジタル署名するステップを 具備する請求の範囲第３３１項記載の方法。 ３３３．信用されたデバイスに第１ユーザと第２関係者の間の電子トランザク ションを実行する許可を与え、前記信用されたデバイスが、ユーザにより変更す ることができない事前に決定された規則にしたがって前記電子トランザクション に従事する旨の保証を提供する方法であって、 前記信用されたデバイスから第三者に、前記電子トランザクションに従事する ための許可の要求を電子的に送信し、前記要求が前記信用されたデバイスのアイ デンティティを含み、 前記第三者により、前記信用されたデバイスが前記トランザクションに、少な くとも部分的には、前記信用されたデバイスが前記規則にしたがって動作すると いう判断に従い、従事する権限を与えられなければならないことを判断し、 前記第三者から前記信用されたデバイスに前記電子トランザクションに従事す る許可を電子的に送信し、前記許可が、前記第三者が前記許可を与えたという認 証を含み、 前記信用されたデバイスから前記第２関係者へ前記認証を、前記信用されたデ バイスが前記電子トランザクションに従事する権限が与えられ、前記規則に則っ てのみ従事するであろう旨の保証として電子的に送信し、 前記信用されたデバイスから前記第２関係者へ、前記規則に則ってトランザク ションデータを電子的に送信する方法。 ３３４．前記許可伝送ステップが、前記第三者から前記信用されたデバイスへ の前記規則伝送のステップを含む請求の範囲第３３３項記載の方法。 ３３５．前記信用されたデバイスが、前記許可伝送ステップの前に、前記規則 を備える請求の範囲第３３３項記載の方法。 ３３６．前記許可伝送ステップが、前記第三者のディジタル署名を前記認証に 添付するステップを含む請求の範囲第３３３項記載の方法。 ３３７．前記要求伝送ステップが、前記信用されたデバイスの製造メーカーに よりディジタル署名される前記信用されたデバイスの前記アイデンティティの認 証を伝送するステップを含む請求の範囲第３３３項記載の方法。 ３３８．前記判断するステップが、前記デバイスが、前記信用されたデバイス の前記アイデンティティに基づき、不正な動きを防止する者であるかどうかを判 断するステップを含む請求の範囲第３３３項記載の方法。 ３３９．前記信用されたデバイスが、非対称暗号システムの公開キーおよび秘 密キーをそれに関連づけ、前記伝送ステップが、前記デバイス公開キーを前記第 三者に伝送するステップを含む請求の範囲第３３３項記載の方法。 ３４０．前記アイデンティティ認証が、前記信用されたデバイスの公開−秘密 キーペアの公開キーを含み、前記要求伝送ステップが、前記第三者が前記要求が 前記信用されたデバイスから生じたものであることを確認できるように、前記デ バイス秘密キーを用いて作成された前記信用されたデバイスのディジタル署名を 前記要求に添付することを含む請求の範囲第３３７項記載の方法。 ３４１．前記信用されたデバイスが、非対称暗号システムの第１キーおよび第 ２キーをそれに結び付け、トランザクションデータを前記第２関係者へ伝送する ステップが、前記第１キーを用いて作成された前記信用されたデバイスのディジ タル署名を添付するステップを含む請求の範囲第３３３項記載の方法。 ３４２．前記トランザクションデータを前記第２関係者に伝送する前記ステッ プが、前記第２キーを前記第２関係者に伝送するステップを含む請求の範囲第３ ４０項記載の方法。 ３４３．前記第１デバイスキーおよび前記第２デバイスキーが、それぞれ秘密 キーおよび公開キーである請求の範囲第３４１項または第３４２項記載の方法。