(57)【要約】【課題】キー寄託機能付き暗号システムおよび方法。【解決手段】ユーザの秘密暗号化キーを複数の構成部分に分割し、それらの構成部分を特定のユーザが選択した信用された代理人に送信するための方法を使用するキー寄託機能付き暗号システムおよび方法と自己認証するチップデバイスにより実行される、キー寄託および寄託認証を受け取る方法は、信用されたデバイスを信用された第三者で登録し、関係者がデバイスが他の信用されたデバイスと通信できるようにする許可を受け取るというより一般化されたケースにも適用される。信用された寄託センターで、複数のユーザにより使用される複数の非対称暗号化キーを寄託するステップ、寄託センタで前記複数のキーのそれぞれを確認するステップ、確認時に前記複数のキーのそれぞれの権限授与を認証するステップ等を具備する。【選択図】      図１５
2006246543.tif 000002
【特許請求の範囲】
【請求項１】
多数のユーザ間で確認できる信用された通信を行う方法において、
前記多数のユーザにより使用される多数の秘密非対称暗号化キーを信用された寄託センタに寄託するステップと、
前記寄託センタで前記多数のキーの各々を確認するステップと、
確認結果に応じて前記多数のキーの各々を証明するステップと、
前記証明後前記多数のキーの各々を利用して前記多数のユーザ間の通信を開始するステップと、
を具備する方法。
【請求項２】
多数のユーザ間で確認できる信用された通信を行う方法において、
前記多数のユーザに関連する秘密非対称暗号化キーを信用された寄託センタに寄託するステップと、
前記寄託センタで前記キーを確認するステップと、
確認結果に応じて前記キーを証明するステップと、
通信を開始するユーザと通信を受信するユーザの両者のキーの証明に応じて通信を開始するユーザから通信を受信するユーザへの安全な通信を開始するステップと、
を具備する方法。
【請求項３】
選択的な非当事者アクセスを伴い多数のユーザ間で確認できる信用された通信を行う方法において、
前記多数のユーザに関連する秘密非対称暗号化キーを信用された寄託センタに寄託するステップ、前記各ユーザは少なくとも１つのキーとユーザ通信にアクセスする少なくとも選択的な第１の非当事者に関連付けられ、と、
前記寄託センタで前記キーを確認するステップと、
確認結果に応じて前記キーを証明するステップと、
第１の非当事者による通信へのアクセスを許可するように送信ユーザから受信者への信用通信を開始するステップと、
を具備する方法。
【請求項４】
第３者のアクセスを伴い多数のユーザ間で確認できる信用された通信を行う方法において、
前記多数のユーザの各々に関連する秘密非対称暗号化キーを多数の寄託センタの少なくとも１つに寄託するステップと、
前記寄託センタで前記キーを確認するステップと、
確認結果に応じて前記キーを証明するステップと、
通信を開始するユーザのキーと受信ユーザのキーを再生するための情報を含み、通信を開始するユーザから受信ユーザヘの信用された通信を開始するステップと、
を具備する方法。
【請求項５】
多数のユーザ間で確認できる信用された通信を行う方法において、
前記多数のユーザの各々に関連する秘密非対称暗号化キーを寄託センタに寄託するステップと、
前記寄託センタで前記キーを確認するステップと、
確認結果に応じて前記キーを証明するステップと、
通信を開始するユーザの信用装置が送信ユーザと受信ユーザのキーの証明を確認すると通信を開始するユーザから受信ユーザヘの通信を開始するステップと、
を具備する方法。
【請求項６】
多数のユーザ間で確認できる信用された通信を行う方法において、
前記多数のユーザの各々に関連する秘密非対称暗号化キーを信用された寄託センタに寄託するステップと、
前記寄託センタで前記キーを確認するステップと、
確認結果に応じて前記キーを証明するステップと、
第３者による通信へのアクセスを許可するアクセス情報を含む通信に使われるキーを証明すると通信を開始するユーザから受信ユーザヘの通信を開始するステップと、
を具備する方法。
【請求項７】
多数のユーザ間で確認できる信用された通信を行う方法において、
前記多数のユーザの各々に関連する秘密非対称暗号化キーを信用された寄託センタに寄託するステップと、
前記寄託センタで前記キーを確認するステップと、
確認結果に応じて前記キーを証明し、各ユーザに関連する信用された装置を証明するステップと、
通信に使われるキーの証明後、および通信を開始するユーザに関連する信用された装置の属性の確認後、通信を開始するユーザから受信ユーザヘの通信を開始する方法。
【請求項８】
多数のユーザ間で確認できる信用されたストリーム指向通信を行う方法において、
前記多数のユーザの各々に関連する非対称暗号化キーを信用された寄託センタに寄託するステップと、
前記寄託センタで前記キーを確認するステップと、
確認結果に応じて前記キーを証明するステップと、
通信を開始するユーザの暗号化キーを使用して通信を開始するユーザから受信ユーザヘの暗号化されたストリーム指向通信を開始するステップとを具備し、
前記通信は（ａ）第３者のストリーム復号を許可するアクセス情報を含む初期パケットと（ｂ）ストリームに関連するパケットを識別する情報を有する次以降のパケットストリームとを有し、前記次以降のパケットの少なくとも１つのパケットは前記アクセス情報を含まない通信方法。
【請求項９】
多数のユーザ間で確認できる信用されたストリーム指向通信を行う方法において、
前記多数のユーザの各々に関連する非対称暗号化キーを信用された寄託センタに寄託するステップと、
前記寄託センタで前記キーを確認するステップと、
確認結果に応じて前記キーを証明するステップと、
通信を開始するユーザからの第１の暗号化されたストリーム指向通信を受信ユーザにおいて受信するステップとを具備し、
前記通信は前記通信を開始するユーザの暗号化キーを用いて暗号化され、前記通信は（ａ）第３者のストリーム復号を許可するアクセス情報を含む初期パケットと（ｂ）ストリームに関連するパケットを識別する情報を有する次以降のパケットストリームとを有し、前記第１のストリームの次以降のパケットの少なくとも１つのパケットは前記アクセス情報を含まない通信方法。
【請求項１０】
多数のユーザ間で確認できる信用された通信を行う方法において、
第１のユーザのハードウェア内で安全な通信を行うステップ、該通信は該通信への第３者のアクセスを許可するアクセス情報を含む、と、
前記安全な通信に前記第１のユーザのハードウェアの署名チップに固有な秘密署名キーで署名するステップ、前記署名キーは前記ハードウェアが前記第１のユーザに渡される前に第１のユーザの署名チップに関連する耐タンパーメモリ内に埋め込まれている、と、
前記安全な通信に証明を付すステップ、該証明は前記第１のユーザの署名チップの秘密署名キーに対応し、信用された権威の秘密署名キーで署名された公開署名キーを含む、と、
安全な通信を第２のユーザに送信するステップと、
を具備する方法。
【請求項１１】
少なくとも１つの通信者と、通信に関与する者ではない者によって再生されるメッセージキーとを有するシステムで安全な通信を行う方法において、
各ユーザにコンピュータハードウェア装置を与えるステップと、
装置ユーザとは別個の装置所有者により決定される制御情報に応じてハードウェア装置をセンタに登録するステップと、
前記ハードウェア装置を証明し、前記センタ、ユーザ、ハードウェア装置に関連する証明書を発生するステップと、
所有者が通信にアクセスできるようにメッセージキーを利用して通信を開始するユーザから受信ユーザへ安全な通信を開始するステップと、
を具備する方法。
【請求項１２】
通信者と、通信に関与する者ではない者によって再生されるメッセージキーとを有するシステムで通信を暗号化する方法において、
各ユーザに少なくとも１つの装置関連キーを有するコンピュータハードウェア装置を与えるステップと、
ハードウェア装置を多数のセンタの中の少なくとも１つの選択されたセンタに登録するステップと、
前記ハードウェア装置を証明し、装置の証明書を発生するステップと、
メッセージキーを利用して通信を開始するユーザから受信ユーザへ安全な通信を開始するステップ、該通信はメッセージキーを再生するためにセンタのキーにより暗号化されたアクセス部分を含む、とを具備し、
該通信開始ステップは第１センタのキーを用いてアクセス情報を暗号化するステップと、第２センタのキーを用いてアクセス情報を暗号化するステップとを具備する暗号化方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、暗号通信システムに関する。さらに詳しくは、本発明は、暗号通信システムで使用される暗号化キーの安全な作成、認証、記憶、および配布に関する。またさらに詳しくは、本発明は、自己認証チップデバイスにより実行される暗号化キー寄託、および公開キー認証管理のシステムに関する。
【背景技術】
【０００２】
精密なコンピュータ技術および分散データ処理システムの開発および普及により、ディジタル形式での情報の転送は急激な伸びを示した。この情報は、財政および金融に関する事柄、電子メール、電子データ交換およびそれ以外のデータ処理システムで使用される。この情報を安全にされていない、あるいは保護されていない通信路で伝送することは、伝送される情報を盗聴、または改変にさらすという危険を伴う。暗号通信システムは、不安全な通信路で伝送されるメッセージの許可されていない関係者によるモニタを防止することにより、これらの伝送のプライバシーを守る。また、暗号通信システムは、不安全な通信路上で伝送されるメッセージ中の情報を許可されていない関係者が改変するのを防止することによって、これらの伝送の保全性も保証する。暗号通信システムは、さらに、確認することができる偽造不可能かつ文書に依存した形式でのディジタル化された、送信者による自身のメッセージの拒否を防止することができる署名を提供することにより、伝送の保全性および確実性を保証することができる。
【０００３】
暗号システムは、ディジタル化された音声伝送または画像伝送を含む、ディジタルデータ伝送を、意図された受取人以外のすべてによって理解不能とするために、ディジタルデータ伝送の符号化または暗号化を必要とする。ディジタル化された、音、文字または数字から構成される普通文（平文）メッセージは、数値により符号化されてから、符号化されたメッセージを、暗号化キーとも呼ばれる番号または数字の指定されたセットに基づいて変換する複雑な数学的なアルゴリズムを使用して暗号化される。暗号化キーとは、使用されるアルゴリズムまたは暗号システムに応じて無作為に選択されるか、特殊な数学的な特質を持つデータビットのシーケンスである。コンピュータで実現される精密な暗号アルゴリズムは、長さ数十万ビットで、許可されていない復号化のあらゆる既知の方法に対抗できる番号を変換および操作できる。暗号アルゴリズムには、対称キーアルゴリズムおよび非対称キーアルゴリズムという２種類の基本的な暗号アルゴリズムがある。
【０００４】
対称キーアルゴリズムは、通信の送信者による暗号化および通信の受信者による復号化の両方に同一の暗号化キーを使用する。対称キー暗号システムは、信頼されていない第三者から保護するために暗号システムを使用する目的で暗号化キーを共有する２つの関係者の相互信頼の上に構築される。もっとも有名な対称キーアルゴリズムとは、国立規格技術研究所（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）による米国特許第５，００１，７５２号および米国特許第５，１３６，６４３号に説明される。図２１に示されるその好ましい実施例において、タイムスタンプデバイス２１０（またはサブシステム）は、郵便料金メーターが、地方の米国郵便サービス支局オフィスによってのみ設置され、それ以降、事前に支払われた金額までしか郵便料金メーター切手を施与しないと一般の人々および郵便制度により信用されるのとほぼ同じように、製造メーカーまたは製造メーカーにより信用される権威のような信頼される権威によってのみ較正され、運転を始められる。いったん較正されると、タイムスタンプデバイス２１０（またはサブシステム）は、「時間設定」命令２１１（つまり再較正）に、その命令が製造メーカー自体、あるいは製造メーカーまたは製造メーカーが信用するものの、エンティティがホストデバイスのタイムスタンプデバイス（またはサブシステム）を設置し、較正するのに信用されている旨を述べる認証２１２を添付したエンティティのどちらかにより署名される場合にだけ、応答する。おそらく時間設定命令動作は、一時的に物理的にデバイスを所有し、デバイスの所有者が命令を捕捉し、デバイスのクロックを「実際より前の日付にする」ために後で命令を再生する可能性を防ぐ目的で、ただちに時間設定命令２１１を消去する時間設定権限を持つ人に実行される必要があるだろう。
【０１１０】
いったん較正され、妨害されない限り、タイムスタンプデバイス２１０は、その内部クロック機構に基づき、タイムスタンプ２１３または構造化データフィールド内の完全なタイムスタンプデータを添付し、その秘密デバイスキーが設定された結果として生じるデータ構造に署名２１４し、その製造メーカー認証２１５を提供する。ホストデバイスが、電源が切れるか、それ自体を停止させる命令により干渉されるか、それ自体を停止させる命令を受け取ると、タイムスタンプデバイスはタイムスタンプの発行を停止する。その場合、絶対的な問題として信用のあるタイムスタンプを必要としない他の有効な機能を損なわせるのを避けるために、タイムスタンプデバイスは、構造化データフィールドがタイムスタンプの入力を要求する場合は、タイムスタンプフィールドをすべてのバイナリゼロやバイナリ１のような事前に合意した「ヌル」値で満たすなどの規約（あるいは同等な規約）を活用する。ただし、構造化データフィールドまたはホストデバイスが、タイムスタンプデバイスがタイムスタンプの発行を停止した場合に、警察デコーダボックスの場合でのように実際のタイムスタンプの発行を要求すると、タイムスタンプを必要とするホストデバイス機能は動作しない。デコーダボックスの場合には、ボックスは割り込まれた通信の復号化を拒絶する。ホストデバイスの停電状況の発生を回避または最小限に抑えるために、各信用されたタイムスタンプデバイスは、専用の別個の長命のクロック専用バッテリ２１６、タイムスタンプデバイスのバッテリ交換前の停電を防ぐためのなんらかの「低バッテリ」警告インジケータ、およびバッテリ交換動作中に適切な電荷を保持する（記憶装置コンデンサ、第２バッテリコンパートメントまたはオプションの外付け電源のような）手段を具備するのが望ましい。
【０１１１】
タイムスタンプデバイスにより発行される各タイムスタンプには、製造メーカー（あるいは別の時間設定権威）により発行され、タイムスタンプクロックの品質および信頼性、タイムスタンプクロックの予測タイムドリフトだけではなく、タイムスタンプクロックが前回セットされた日付を記述するタイムスタンプデバイス認証があるだろう。受取人ユーザが、ホストデバイスによりディジタル署名されたデータ構造を受け取ると、その受取人は、タイムスタンプフィールドが有効値で完了している場合、デバイスの署名および認証が、データ構造が作成、署名、および発行された時刻が正しいことを認証することを理解する。この認証下付は、（１）もっとも最近タイムスタンプクロックを較正した権威の信頼性、（２）デバイス認証に製造メーカーが記述するクロックのドリフト公差、および（３）クロックの干渉または停電時にそれ自体を停止させる機能に基づいている。さらに、受取人は、タイムスタンプフィールドに「ヌル」値が指定されている場合、タイムスタンプクロックが、デバイスがデータ構造を作成、署名および発行した時点で信用された較正の状態になかったことを理解する。タイムスタンプデバイスおよびその内部クロック機構の信用特性に関するこの情報は、適切な属性値コーディング法を使用して、デバイス認証の中に直接符号化できるのが望ましい。ただし、この情報は、製造メーカーが、デバイス認証発行時に公に述べられる「方針書」の一部として仕様書および性能認証で発表する、製造メーカー名およびデバイスタイプからも示唆されるであろう。
【０１１２】
このようなタイムスタンプは、ＭＣＨ作成および復号化以外の他のメッセージ処理動作の一部としてデバイスにより発行されることもある。これらのタイムスタンプは、ユーザが、デバイス内部に安全に閉じこめられている自分の個人的な署名キーを使用して別の文書またはトランザクションに署名する場合に、デバイスのユーザの個人的な署名に添付される。デバイスは、ユーザの署名のタイムスタンプ要素に署名または共同署名するか、代わりに（文書のハッシュ結果メッセージ摘要とともに、やはりユーザにより署名される、タイムスタンプが入った）ユーザの署名ブロック全体の上に署名するだろう。したがって、デバイスは、製造メーカーの公開キーを知っている第三者がタイムスタンプを信じ、信頼できるようにするために、その認証を提供する。
【０１１３】
信用されたアップグレード、置換および再キー入力
本発明のもう一つの機能とは、埋め込まれた製造メーカーの公開キー、保護された不揮発性メモリ領域、および安全な中央演算処理装置（ＣＰＵ）を具備し、製造メーカーにより埋め込まれるあらゆるファームウェアルーチンを信用されたやり方でアップグレードまたは補足することができる、不正な動きを防止する信用されたデバイスである。信用されたデバイスは、そのタイプのデバイスに適切であり、製造メーカーの署名でディジタル署名される新しいまたは追加ファームウェアコードを含むデータの本体を入力として受け入れることによりアップグレードまたは補足を実行し、その署名が新しいファームウェアコードが製造メーカーにより作成、試験、承認されたこと、およびしたがってデバイスが（ａ）１つ以上の現在埋め込まれたファームウェアルーチンを新しいファームウェアコードでオーバレイするか、あるいは（ｂ）新しいファームウェアコードを保護されたメモリの現在未使用の領域内に１つ以上の新しいルーチンとして追加する必要があることをデバイスに保証する。好ましい実施例においては、保護されたメモリは、電源が入っていない間、その情報を無限に保持できるが、デバイスにより（比較的に低速ではあるが）消去することも可能で、希望する場合は再利用できるＦＬＡＳＨタイプとなるだろう。保護されたメモリには、不正な動きが防止されているかどうかに関係なく、アップグレードまたは捕足の対象となるコードが、信用されたデバイスによってのみその復号化キーが知られている暗号化された形式で記憶される（ディスクドライブのような）データ記憶領域も含まれる。デバイスが、新しいファームウェア（またはソフトウェア）コードのこのような署名された本文を受け取ると、ユーザは、製造メーカーの署名とともにコードを入力し、デバイスに対して「ファームウェアアップグレード処理」命令を発行する。それから、デバイスは、製造中にデバイス内に埋め込まれた製造メーカーの公開署名キーを使用して製造メーカーの署名を確認する。製造メーカーの署名が確認されると、コードが受け入れられ、デバイスは希望のアップグレードを実行する。
【０１１４】
前記の信用されたデバイスのファームウェアに対する信用されたアップグレードのプロセスは、主として信用されたデバイス製造メーカーとは関係なく、銀行マスタ寄託センタにより設計および管理される、現在のキー寄託システムのような機能を含む、それらの第三者に関連するデバイス機能に関するファームウェアルーチンのアップグレードを希望する許可され第三者を入れるように、さらに拡張できる。第三者アップグレードの場合、製造メーカーは第三者ファームウェア提供業者の公開キーを含むファームウェアアップグレード認証に署名し、それをその第三者に発行する。すると、第三者は、置換ファームウェアルーチンまたは追加ファームウェアルーチンの作成、試験および承認を行い、第三者の秘密署名キーでそれらに署名し、製造メーカーからのそのアップグレード認証をそこに添付する。ユーザは、このようなアップグレードを受け取ると、署名済みのコードルーチンおよび製造メーカーのアップグレード認証の両方をデバイスにロードし、それから「第三者ファームウェアアップグレード処理」命令を発行する。したがって、デバイスは、新しいコードルーチン上の第三者の署名を、製造メーカーのアップグレード認証に比較して確認してから、製造中にデバイスに埋め込まれた製造メーカーの公開署名キーに比較してアップグレード認証を確認する。両方の署名が確認されると、アップグレードは受け入れられ、デバイスは希望のアップグレードを実行する。
【０１１５】
デバイスファームウェアルーチンをアップグレードまたは補足するための命令を受け入れるだけではなく、不正な動きを防止する信用されたデバイスは、製造中に埋め込まれた「命令」公開キーを置換または補足するための命令も受け入れることができる。前記のように、信用されたデバイスが、デバイスの製造中に製造メーカーにより埋め込まれたキー以外の公開キーを備えている可能性がある。本発明で記述されるように、このような「命令」公開キーには、１つ以上のマスタ寄託センタの公開キーが含まれる場合がある。製造メーカーまたはそれ以外の信用された第三者のものを含むこれらの埋め込まれたキーは、寄託認証デバイス認証、アップグレード認証、時間設定命令認証、およびデバイスが従って動作するためにデバイスに提示されるそれ以外のもののようなさまざまな認証の確認に使用できる。製造中に埋め込まれる公開キーだけを信頼するのに加えて、デバイスは、新しい公開キーを埋め込んだり、既存の公開キーを置き換えるための外部命令も受け入れることができる。デバイスが信用された第三者の公開署名キーの秘密領域で受け入れ、記憶するためには、製造メーカーは、記載する認証を廃棄し、指定の公開命令キーを中に記憶するようにデバイスに命令する、製造メーカーにより署名される署名済みの命令データパケット（または認証）の中に新しい公開キーを入れる。特別なパケットは、デバイスに、新しいキーが信用されているトランザクションのタイプ（例えば、キー寄託アプリケーション、車レンタルアプリケーション、医療データアプリケーションと使用するためやそれ以外の使用）に関しても命令する。製造メーカーからこのような公開キーデータパケットを受け取ると、デバイスは、最初に製造メーカーの署名を確認してから、新しい公開キーを受け入れ、公開キーの使用に関する制限とともに記憶する。
【０１１６】
製造メーカーは、製造中または後でのどちらかである、命令データパケットの一部として第三者の公開命令キーを埋め込む時点で、その第三者キーが承認されたトランザクションの内の一つが製造メーカー自身の基本的な公開署名認証キーの代替物であることを指定することができる。製造メーカー自体の公開署名キーのこのような代替物はほぼ絶対に要求されないが、（デバイス認証およびデバイスに対する他の命令を発行するための）製造メーカーの対応する秘密署名キーが盗難のために危うくなる可能性がある。製造メーカーの秘密署名キーの盗難により、窃盗犯が、（怪しい信頼性の）新しい寄託センタを承認し、新しい時間設定権威を承認するために、外見上有効な命令を発行できるだろう。代わりに、および、さらにありそうなのは、製造メーカーの秘密署名キーが単に失われるか、破壊され、それによってさらに有効な命令の発行が妨げられることである。これらのイベントのどちらかは、コンピュータシステムの用語での「災害」として分類され、その製造メーカーのデバイスのすべてを回収しなければならない結果となる。しかしながら、本発明により、このような回収の費用は、信用された第三者が製造メーカーの危うくされた署名キーを置き換えることができるようにすることにより、防止または軽減できるだろう。製造メーカーが、製造中またはその後命令データパケットを使用する際のどちらかに、すでに１つ以上の信用された第三者の命令キーをデバイスの中に埋め込み、第三者の公開命令キーが承認できるトランザクションの間にそれ自身の公開キーの代替物を入れてあると仮定すると、製造メーカーはその信用された第三者を頼り、その第三者が、製造メーカーの公開署名キーの代替物を許可し、それによって、それ自体およびそのユーザがすべての物理デバイスを実際に交換する巨額の費用を節約する製造メーカーのデバイスのすべてに命令データパケットを発行することを要求する。製造メーカーにより発行されるすべてのデバイス認証も置き換えられなければならないため、これは各デバイスに、デバイス自体の公開デバイス署名キーに対する認証要求を発行させることにより達成される。製造メーカーの秘密キーが失われるか破壊され、危うくされなかった場合、すべての以前の署名は以前として有効となり、ユーザは、製造メーカーの新しい署名キーにより署名される同じ情報に対して新しいデバイス認証を発行させるために、自分の旧いデバイス認証を提示するだけだろう。それから、製造メーカーは、新しいデバイス認証を（おそらくオンラインまたは電子メールトランザクションを介して）戻すだろう。これは依然として高価であるが、現場にあるその製造メーカーの信用されたデバイスのすべてを大規模に物理的に交換するより、安価であり、製造メーカーの評判に対する不利益は少なくなるだろう。
【０１１７】
本発明の信用されるデバイスの中に、製造メーカーの公開キーまたはそれ以外の信用される公開命令キーを取り入れると、全システムのルート公開キーを使用することにより提起されるシステム機密保護リスクがいくぶん和らげられるであろう。これにより、純粋に階層的な信用モデルに対する信頼がさらに高まり、一般的には、必要とする認証の数が少ないさらに短く、単純な認証が可能となり、どの認証を活用するべきかを判断するための労力が減り、署名を確認するための計算時間が減少するだろう。
【０１１８】
所有者制御再入力
前記のように、ユーザは、製造後の任意の時点でそのユーザ暗号化キーペアに関してデバイスに再入力するオプションも持つ。ユーザは、信用されたデバイスに対してキー寄託方法の特定のステップを実行する、つまり秘密キーと公開暗号化キーの新しいペアを作成し、キー分割部を寄託代理人に送信し、最終的にマスタ寄託センタから新しい寄託認証を受け取るようにとのファームウェア命令を発行することによりこれを実行する。しかし、ユーザの雇用者または後援者（あるいは、ユーザが別のデバイスまたはプロセスである場合には所有者）に、（ａ）ユーザが、許容できると考える寄託代理人を選択することを確認する目的で、および（ｂ）雇用者が、デバイスの真の所有者として、選択された寄託代理人にとって既知のままであり、このため最初に令状や裁判所の命令を取得しなくてもユーザのキー分割部を寄託代理人から要求することができることを保証する目的で、キー入力および再キー入力プロセスを制御させるのも望ましい。雇用者が、例えば内部監督を行うため、または関連するデバイスが損失、盗難または破壊された後に、暗号化された独占データを復旧するためなどの任意の数の理由から、ある特定のデバイスのキーへのアクセスを要求することがある。雇用者が、その以前の暗号化キーまたは署名キーが危険にさらさされたか、消去されたデバイスのため、別の従業員に与えられたデバイスのため、あるいはその所有者組織が方針の問題として定期的な間隔ですべての暗号デバイスをキー入力し直すデバイスのためなどの、任意の数の理由からデバイスにキー入力し直す必要があることもある。
【０１１９】
好ましい実施例においては、信用されたデバイスは、デバイスが、最初に、特定のデバイスの恒久的な連続番号２２１を記載し、製造メーカーにより署名（２２５）された図２２に示されるもののようなデバイス２２０用の所有者の認証を受け取らない限り、キー作成および寄託プロセスを開始しないように、製造メーカーにより事前設定されている。製造メーカーによりデバイスの企業購入者に対して購入時点で発行される所有者の認証２２０は、企業の名称２２２、（内国歳入庁雇用者識別番号（ＥＩＮ）またはダン＆ブラッドストリート番号（ＤＵＮＳ）のような）企業の一意の識別番号２２３、および企業により保持される秘密署名キーに対応し、再キー入力や企業によりデバイスに発行されるそれ以外の命令を確認するために使用される企業の公開署名認証キー２２４も記載する。この情報を受け取った後は、デバイスは、再キー入力、またはデバイスの所有者の認証内に記載される公開キーに対応する企業所有者の秘密署名キーを使用して署名されるそれ以外の命令だけに応答する。
【０１２０】
今度は図２３を参照すると、雇用者（デバイスの所有者）がデバイスの再キー入力を希望する場合、雇用者は、（１）デバイスの連続番号２３２、一意の所有者識別番号２３３、（２）寄託代理人２３５およびマスタ寄託センタ２３４の名称、（３）再キー入力命令の日付および時刻、（４）再キー入力命令期限２３６の日付および時刻、ならびに（５）再キー入力命令一意連続番号２３７を含む、署名された命令２３１をデバイス２３０に発行し、雇用者の秘密署名キー２３８を使用して命令に署名する。有効な所有者の認証２３９および有効な再キー入力命令２３１を受け取ると、信用されたデバイスの中のチップ２３０は、まず所有者の認証２３９上の製造メーカーの署名および再キー入力命令２３１上の雇用者の署名を確認する。その次に、信用されたデバイスが、以前同様に、各寄託共用パケット内の所有者の一意識別番号２３３を含むキー作成および寄託プロセスを完了し、再キー入力命令２３１内の雇用者により指定される寄託代理人２３５に対してだけ共用パケットを送信する。（電子的に発行できる）これらの命令のそれ以降の再生は、デバイスが、不揮発性記憶領域内に、受信した前回の複数の再キー入力命令の連続番号を保持し、命令を実行することを再び拒絶するようにデバイスを設計することにより、制限することができる。デバイスのタイムクロックが順調に維持されていると仮定すると、命令中の期限の日付および時刻を尊重するようにデバイスのタイムクロックに命令するだけで、再キー入力のそれ以降の再生を制限することもできる。好ましい実施例においては、そのクロックが未較正であるデバイスは、ヌル以外の期限日付／時刻が設定された再キー入力命令の処理を拒絶するが、期限日付時刻がヌルのままとされている場合には先に進む。
【０１２１】
ユーザデバイスから一意の所有者識別番号を含むキー（または再キー）分割共用パケットを受け取ると、寄託代理人およびマスタ寄託センタは、その一意の識別番号を各データベースの中に記録し、それ以降は、その所有者からの秘密暗号化キーへのアクセスの要求を尊重するだろう。好ましい実施例では、寄託代理人および寄託センタは、それぞれ、一意の所有者識別番号を指定するキー分割共用パケットにも、製造メーカーにより署名される各デバイス所有者認証が添付されなければならないことを要求する。このデバイス所有者認証により、寄託代理人およびマスタ寄託センタは、デバイス所有者の認証中の所有者の公開キーに対応する所有者の秘密署名キーで署名されるキー要求メッセージに従い動作できるようになる。
【０１２２】
別の実施例においては、信用されたデバイスは、別個のデバイス所有者の認証を使用しなくても、デバイス所有者からの再キー入力、再寄託、所有者移管またはそれ以外の命令を受け入れることが許可される。デバイスに対する命令に別個の所有者の認証を使用しなければならないという要件は、所有者が、その所有するすべてのデバイスの認証のデータベースを保守し、デバイスに再キー入力したり、デバイスになんらかの命令を送信したいと考えるたびに、適切な認証を見つけ出さなければならないため、管理上の負担である。図２６に示されるようにより優れたアプローチとは、製造メーカーに、デバイスの指定されたファミリ用の所有者の公開命令キーに対する単独の認証を所有者に発行させ、販売者に、デバイス２６０の販売時に、その公開命令認証キー２６１をデバイス２６０の内側にインストールさせてから、それらのキーの内部記憶領域に基づいてシステムを設定することである。デバイスがその製造メーカーにより所有者に最初に販売された時点で、デバイス２６０は、まず、製造メーカーによりデバイス内に埋め込まれた製造メーカーの公開命令キー２６３を使用して、所有者の製造メーカー認証２６２の有効性を確認する。デバイス内の所有者の公開命令キー領域２６４がブランクである場合、デバイスは、所有者の製造メーカー認証２６２からデバイスの所有者公開命令キー領域２６４の中に所有者の公開命令キー２６１をコピーする。所有者公開命令キーがデバイス内にすでに存在し、デバイスの初期化を試みる所有者の所有者公開命令キーと異なる場合、デバイスは、製造メーカーがデバイスを別のエンティティに販売したことがあると仮定する。各デバイスは、主要所有者は多くても１つなので、そのデバイスの所有権は、所有者の認証者という前記概念の代わり（あるいは前記概念に加えて）、デバイス２６０の中に所有者公開命令キー２６１が存在するか、あるいは存在しなかにより決定される。
【０１２３】
所有者公開命令キーがインストールされていない場合、デバイスは、デバイスの再キー入力や所有権移管に関して制限を受けていない単独ユーザ消費者デバイスであると考えられる。それだけで、デバイスは、インストールされた所有者キーが存在しないということを、前記の再キー入力、再寄託、および所有権移管の規則を呼び出さずに、ユーザの命令に従うための信号と見なすだろう。図２７に示されるように、所有者公開命令キー２７１が信用されたデバイス２７０の中にインストールされている場合は、ユーザ再キー入力、再寄託および所有権移管の命令２７２は、これらの命令が対応する所有者秘密署名キー２７４により署名２７３されていない限り、処理されない。所有者の署名２７３がいったん確認されると、信用されたデバイス２７０は、前記の再寄託手順のステップを実行する。したがって、所有者は、そのデバイスに命令するときに指定された数のデバイスに対する自分の所有権を認証する所有者の認証を添付する必要はない。ただし、所有者の署名された命令は、命令がその所有者により所有されるあらゆるデバイスに供給されるのを妨げるために、言うまでもなく、番号が付けられたデバイス、またはおそらくそのデバイス番号が指定された規則またはテンプレートに従うあるクラスのデバイスに限られなければならない。
【０１２４】
さらに、図２８に示されるように、所有者は、最初にインストールされた所有者公開命令承認キーを（購入者、つまりデバイスの新しい所有者からの）別のもので置き換えることにより、デバイスの所有権を移管するための命令を送信できる。デバイス所有者は、現在の所有者の秘密命令署名キー２８３を使用して署名された新規所有者の名称および公開命令認証キーを含む所有件移管命令２８２をデバイス２８０に送信する。デバイスは、現在の所有者の公開命令キー２８１を使用して所有権移管命令２８２を確認し、そのキーを新規所有者の公開命令キー２８４で置き換え、それ以降は新規所有者からの命令だけに応答する。さらに、所有者は、第２公開命令キーをインストールすることにより、別の「二次所有者」を加えることもできる。この第２公開命令認証キーには「権利」フィールドがあり、どの動作に関してそれが命令を受け入れることを許可されているのかを示している。これらの権利の中に含まれると考えられるのは、再キー入力、別の所有者の追加、（条件販売と同じ）所有者の削除、全所有者の削除、および記載された所有者を持たない消費者デバイスへの復帰がある。ただし、これらの定義された権利は、主要所有者命令キーの置換または削除を行う権利を含む、最初の、つまり主要な命令認証キーより多い権利または少ない権利を含む場合もあれば、同じ量の権利を持つ場合もある。
【０１２５】
一般化されたデバイス登録
秘密復号化キーを寄託し、寄託認証を受け取るための前記の一般的な方法は、必ずしも範囲または目的においてキー寄託状況に限定されることなく、信用されたデバイスを信用された第三者で登録し、その第三者から、デバイスが他の信用されたデバイスと通信できるようにする許可を受け取るというより一般的なケースにも適用することができることに注意する。図２４に描写されるこの一般的なプロセスは、信用された第三者（ＴＴＰ）２４１と通信するプログラム可能な信用されたデバイス２４０が、秘密署名キーおよび対応する公開署名キーの製造メーカーの認証２４２を備える。また、このプロセスには、本開示の他のどこかで説明される、追加のアプリケーションレベルのファームウェアおよび関連する公開キーのリモートインストールをサポートすることができる同じ、かつ安全なシステムレベルファームウェアである可能性がある製造メーカーの公開キー、および全システム（またはグローバルな）権威（ＳＷＡ）公開キーも含まれる。デバイス２４０は、ＳＷＡにより署名される権威２４３の認証を発行されたことにより、この一般的な登録システムの中に入れられる無制限な数のＴＴＰ２４１のいずれか一つで登録することができる（ＳＷＡは、公開キー認証階層の有名な原則にしたがってＴＴＰがシステムの中に入れられるのを許可するための証人の追加層を任命することもできる）。ユーザは、いったんそのデバイスを指定ＴＴＰで登録すると、他の取引相手との特殊化されたトランザクションに従事することができる。
【０１２６】
このプロセスの最初のステップでは、ユーザは、自分のデバイス２４０指定認証済みＴＴＰ２４１で登録するための要求２４４を始動する。この要求２４４には、ユーザおよび登録要求の資質を確認するための情報２４５が含まれ、署名および既知のタイプのデバイスを裏付けるために、製造メーカーのデバイス認証２４２が添付される。選択されたＴＴＰ２４１が、このプロトコルの範囲外ではあるが、トランザクションを実行するための希望される許可を認めるか、否定するかのＴＴＰの決定に影響を及ぼす可能性がある、ユーザのアイデンティティ、所属、信頼度などを確認するために、ユーザまたはその他の関係者のどちらかからその他の情報および保証を要求することもある。ＴＴＰ２４１は、適切な公開キーを使用して、デバイス認証２４２上の製造メーカーの署名およびユーザの登録要求２４５内の情報に対するデバイス署名を確認する。
【０１２７】
ユーザが要求されたクラスのトランザクションに従事することを許可可能であることに満足すると、ＴＴＰ２４１は、デバイスがユーザの代わりにそれらのトランザクションを実行するのを特に許可する認証２４７を含む応答２４６を発行する。ＴＴＰのデバイス許可認証２４７は、ユーザが取引相手とのそれ以降のトランザクションのたびに、自分のデバイス認証２４２を提出しなくてもいいように、通常、便宜上（および後述するように）ユーザのデバイス公開署名キーの再認証されたコピーだけではなく、ＴＴＰ、ユーザ、ユーザのデバイスおよび許可が与えられたトランザクションを識別する情報も含む。また、ＴＴＰ応答２４６には、ダウンロード可能なファームウェア、またはユーザの信用されたデバイスの中にロードされる、そのデバイスが許可されたトランザクションを実行できるようにする、公開キー２４８、あるいはその両方が含まれることもある。ＴＴＰ応答２４６がユーザに新しいファームウェアまたは公開キーを自分のデバイスの中に安全にロードするように要求する場合、応答２４６は、ＴＴＰの公開署名キーを認証し、ファームウェアおよび公開キーのアップグレード権威を伝達する、ＳＷＡにより発行される権威２４３のＴＴＰの認証も含む。ユーザの信用されたデバイス２４０は、ＴＴＰの応答２４６を受け取ると、その埋め込まれたＳＷＡ公開署名キーを使用し、権威２４３のＴＴＰの認証を確認し、その中に含まれるＴＴＰ公開署名キーを使用し、ファームウェアおよび公開キーのアップグレード２４８およびＴＴＰのデバイス許可認証２４７を確認する。
【０１２８】
図２４を再び参照すると、ユーザが取引相手２５０とのトランザクションの実行を希望すると、そのデバイスは、本開示全体で広範囲に説明してきたように、デバイス上にインストールされたファームウェアプログラムの中で実現された規則に則って（製造時点またはそれ以降のダウンロード時点のどちらかで）トランザクションデータ２４９を公式化し、トランザクション２４９に署名し、その対応する公開キーの認証を添付する。この認証が、製造メーカーのデバイス許可認証２４２であることもあるが、おそらく、便宜上認証し直されたデバイス公開キーのコピーを含むＴＴＰのデバイス許可認証２４７であろう。取引相手２５０は、通常、ＴＴＰの公開キーを活用し、そのデバイス許可署名書２４７上のＴＴＰの署名を確認してから、その中に含まれるデバイス公開署名キーを使用し、トランザクション２４９でのデバイスの署名を確認し、それにより関連するファームウェアにより課されるトランザクションプロトコル要件とのデバイスの準拠を確認する。取引相手２５０がすでに特定のＴＴＰの公開署名認証キーを持っていない場合には、ユーザは、取引相手がＳＷＡ公開キーを使用して確認でき、それがこのシステムの参加者となるためにすでに所有していなければならない、権威２４３のＴＴＰのＳＷＡ認証をトランザクション２４９の中に入れることができる。
【０１２９】
ここまで説明した一般化されたプロセスは、（ａ）ユーザデバイス認証中に記載または示唆される情報が、デバイスが、すでに、本明細書で説明するキー寄託暗号システムの特殊化された機能を実行することができるファームウェアを具備している旨を寄託センタに伝達する、寄託センタ（ＴＴＰ）により署名される寄託認証の返礼に、秘密暗号化キーを寄託すること、または（ｂ）このようなデバイスがそのように具備されていないが、そのように具備される機能を持つ場合に、インストール時にデバイスが寄託システムのトランザクション要件を満たすことができるようにする安全なソフトウェアアップグレードをダウンロードすることを許可するほど一般的である。取引相手２５０に送信されるトランザクションデータ２４９は、メッセージ制御ヘッダによりプレフィックスされ、ＴＴＰ２４１（マスタ寄託センタ）により発行される許可２４７（ユーザの寄託認証）が添付される。
【０１３０】
したがって、図２４の一般化されたシステムは、複雑な形式の企業および政府のトランザクションを開放的な通信ネットワーク環境で促進することができる多くのきわめて望ましい特性を持つ。特に、各参加デバイスが安全なマルチステップトランザクションを実行し、追加タイプの安全マルチステップトランザクションを実行するためにファームウェアをダウンロードし、そのように作成されるトランザクションに署名できる限り、多くの異なるデバイス製造メーカーが存在できる。また、それぞれが異なったタイプのトランザクション許可を発行し、それぞれが、キー寄託、ディジタル現金管理、自動車レンタル、またはユーザ医療レコード管理のような異なるクラスのファームウェアアプリケーションを認証する、任意の数の信用された第三者も存在できる。したがって、取引相手は（ユーザデバイスのファームウェアおよびプロトコルにより）比較できるように具備される信用されたデバイスを活用することを要求される可能性があるが、そのデバイスは、元のユーザの関係者とは異なる関係者により作成、発行、および具備され、しかも元のユーザのトランザクションは、ＳＷＡおよびそのＴＴＰによりそのように認証される場合は、相手が、デバイスのすべてのバージョンおよびそのプログラムが互いに認識し、ともに作業できるようにするＳＷＡ公開署名認証キー２４７のコピーを所有する限り、システム規則に則り、受け入れられ処理される。このプロトコルにより実現されるビジネス目的のいくつかの例には、（ａ）認証可能な寄託キーを使用する暗号化、（ｂ）現金またはそれ以外の高い価値の文書のディジタル表現の管理、および（ｃ）ユーザの医療情報またはそれ以外の個人的な情報へのアクセスおよびその使用に対するトランザクション要件を施行するシステムを含む。
【０１３１】
一意所有者識別番号
使いやすさをプライバシー権利とつり合わせる必要性に応じて、一意所有者識別番号は、寄託代理人に対するキー分割メッセージの中だけではなく、オプションで、（ａ）ユーザの寄託認証または（ｂ）通常の通信中に発行されるＭＣＨのどちらかに表示される。通信を復号化しようとする調査官が、ＭＣＨがその中から取られた通信に関係するデバイスの一方またはデバイスの両方が、指定された所有者に属するかどうかを、所有者識別番号を含むＭＣＨを見ることにより判断できるのが望ましい。ただし、ある種の所有者を含むそれ以外のプライバシーの利害により、所有者識別番号が、通信のプライバシーを高める目的でＭＣＨから省略されることが示唆される。所有者識別番号が、デバイス寄託認証のみに含まれ、通信のＭＣＨ中には含まれないケースでは、ある特定の雇用者により雇用され、リストされたデバイス所有者を持たない多くのＭＣＨに突き合わせて、ある特定の通信が、その雇用者の従業員を起源とするのかどうかを判断しようとする調査官は、指定されたＭＣＨ中にリストされたマスタ寄託センタに、そのＭＣＨが、雇用者により所有されるデバイスを起源としたのかどうかを問い合わせるだろう。マスタ寄託センタは、そのキーがそのマスタ寄託センタに寄託されるＭＣＨ通信の関係者の認証番号を復号化し、ユーザ認証が調査官の雇用者に対して発行されたかどうかをチェックする。発行された場合、および調査官の要求が、雇用者−所有者の署名キーを使用して署名される場合（つまり、調査官が雇用者−所有者から調査するための許可を持つ）、マスタ寄託センタが、この情報を明らかにするだろう。調査官が許可を持たない場合、調査官は、既知のデバイス所有者のＭＣＨに反映される疑わしい活動を調査するための令状または裁判所命令を求める必要があるだろう。大部分のデバイス所有者が、そのユーザの寄託認証およびＭＣＨの中で公に名前を指定されるのに反対しないと予測される。これは、大部分の電子通信システムにおいては、たいてい指定メッセージの送受制度を強力に識別する物理ネットワークアドレスおよび論理ネットワークアドレスの情報を抑制するのが実践的ではないためである。したがって、一意所有者識別番号を公開することによりほとんど損失されず、送信者デバイス所有者名および受取人デバイス所有者名により、メッセージをすばやくより分け、分類する能力を提供することにより多くが得られる。
【０１３２】
しかしながら、一意所有者識別番号が、公開されずに、依然として従業員寄託認証の中または通信のＭＣＨの中に含まれる可能性がある。従業員の寄託認証およびＭＣＨには、前記の他のキーとともに雇用者公開暗号化キーが含まれるだろう。これらのキーは、（送信者と受取人両者が雇用者であると仮定し）通常、送信者の寄託認証と受取人の寄託認証の両方に存在する。送信者のデバイスは、ＭＣＨを形成する場合、実際には送信者のデバイスがＭＣＨを使用して各雇用者−所有者にその各雇用者−所有者自身の一意のＩＤから構成されるそれだけが復号化できるメッセージを送信するように、ＭＣＨの中に、それぞれがその雇用者の公開暗号化キーを使用して一方または両方の雇用者一意識別番号を取り入れる。この方法は、送信者が、送信者および受取人両者の、各寄託センタの公開暗号化キーの元で暗号化された認証番号を送信するため、および両関係者の傍受を可能とする目的で、メッセージセッションキーを送信者だけではなく受取人にも送信する（ＭＣＨの正常な機能）ために、ＭＣＨを使用することに関して前記された方法に類似する。この技法を使用すると、雇用者は、所用者−雇用者の従業員に属するすべてのメッセージがメッセージトラヒックフロー内で容易に識別可能であり、所有者ＩＤ番号が暗号化されておらず容易に取得できる状況を回避しつつ、どのＭＣＨがその従業員に属するのかを容易に判断できる。
【０１３３】
依然として、このアプローチには、雇用者公開暗号化キーを使用して暗号化された一意の雇用者識別暗号が、常に同じ、したがって認識可能な値を生み出すという欠点がある。このアプローチをさらにうまく実施するならば、タイムスタンプが暗号化されるデータブロックに高い変化性を与えるように、（雇用書が明らかに知る権利を持っている）従業員の寄託認証番号だけではなく現在のタイムスタンプ（または別の無作為番号）が入ったデータブロックを、雇用者の公開キーで暗号化する。「ＥＭＰＬ」（またはスペースが許すならば、雇用者の一意ＩＤ）のような別個の「人目を引く」テキストの数バイトは、（人が確実に理解していない可能性がある、他のデータ項目がバイナリであるケースで）フィールドを復号化中のエンティティに成功した復号化を明らかにするために、暗号化されたブロックの内側にも入れることができるだろう。このケースでは、雇用者の所有権の認証は、雇用者が単にこのフィールドを読むことができるということから構成される。さらに、タイムスタンプが毎回異なり、したがってすべての雇用者ＭＣＨデータブロックを一意とするほど十分に信用されない変化性を増すために別の無作為番号がデータブロックに追加されるだろう。
【０１３４】
送信されるあらゆるメッセージで送信者と受取人両者の雇用者に対して実行されるこの改善されたアプローチにより、雇用者およびその他の後援者が、それらの通信のどれかがその雇用者により所有されるデバイスを起源をしたのかどうかという点に関して判断するために、適切な寄託センタへの通信のたびに暗号化されたＭＣＨを提出しなくても、どの通信が従業員により作成され、受信されたのかを判断できるようになり、したがってかなりの金額が節約される。各雇用者は、その雇用者の秘密暗号化キーを取得する目的で、以前同様、依然としてマスタ寄託センタおよび寄託代理人と連絡しなければならず、デバイス製造メーカーにより発行される、その所有者認証内に記載される公開署名認証キーと突き合わせるのは、実際には、その要求を秘密署名キーで署名することによる従業員のデバイスの所有者であることを認証しなければならない。少なくとも、雇用者に、後で所有されていないデバイスであることが判明するものを起源とする通信のＭＣＨに関して、それらの関係者に追加に要求を出す時間、労力および費用をかけさせないだろう。そして、以前同様、雇用者が、所有されていないデバイスによる通信からのＭＣＨが添付される犯罪活動または他の不適切な活動に気づく場合、雇用者は、常に適切な警察に接触し、その機関に犯罪活動に気づいた理由を教え、第三者の従業員ではない犯罪者、またはおそらく従業員であるかどうかに関係なく、雇用者により所有されておらず、雇用者に登録される暗号デバイスを使用する雇用者の敷地の個人を起源とすると考えられる、それらの通信の割り込みまたは復号化あるいはその両方のための令状を取得するためにその機関を裁判所に出向かせる。
【０１３５】
情報およびがそれを読み取る権利を与えられた関係者によってだけ読み取られるように、情報を暗号化されたＭＣＨの中に入れる方法を、（そのそれぞれがメッセージセッションキーを復号化できる）送信者と受取人、（そのそれぞれがそのそれぞれのユーザの認証番号を解読できる）各関係者のマスタ寄託センタ、および（そのそれぞれが、メッセージごとに識別されるのを回避しつつ、誰か他の人に連絡しなくてもそれが通信側デバイスを所有しているかどうかを確認できるように、その従業員の認証番号またはそれ自体の一意の所有者識別番号を復号化できる）各関係者の雇用者−所有者だけではない関係者に拡張できるのは明かである。これは、また、非常に大規模な企業または令状要件を持たないある外国の地方の警察などのようなそれ以外の関係者にも拡張できる。言うまでもなく、これらの関係者が各メッセージで公に指名され、日常的に識別可能であることに反対する根拠を持たないと仮定するならば、これらのキーの元ですべての情報は、前記のように、普通文、つまり暗号化しないで表示することもできる。また、この情報は、ユーザに雇用者がいない場合などの関係者が関連していない場合も省略できる。単純化されたアプローチとは、すべての状況に１つのＭＣＨ書式を使用し、適用できない場合には、フィールドをブランクのまま残すことであろう。  それ以外の場合、好ましい実施例では、ＭＣＨを処理する各デバイスがどのフィールドを予測するかを判断し、ＭＣＨをそれに従って解析できるように、各書式が第１フィールドの一意のバージョン番号により識別される、さまざまな異なるＭＣＨ書式を同じシステム内では活用するであろう。この方法により、最大限に柔軟なシステムであるＭＣＨの利害関係者の無限ネスティングが可能となる。計算上のオーバヘッドは、おもに、どれだけ多くのこれらのフィールドが実際に各それぞれの関係者の公開暗号化キーで暗号化されなければならなかったのかに依存する。
【０１３６】
雇用者は、各エントリに「方針フィールド」つまり、雇用者のデバイスにどの情報をＭＣＨの中に入れるのかに関して命令するコードを含む命令コードを添付することにより、ＭＣＨ内に入れられる情報をさらに容易に制御することができる。以前同様、命令コードは、雇用者に以下の情報を入れるオプションを与える選り抜きの要素を含む場合がある。（１）暗号化されているか、別名を使用するかのどちらかである雇用者の指名および一意の識別番号、（２）雇用者の一意の識別番号がＭＣＨフィールドの中で暗号化されている、暗号化されていないワード「雇用者」、（３）暗号化されたフィールド内のユーザ認証番号、（４）暗号化されたフィールドのメッセージセッションキー、（５）暗号化されたフィールドのタイムスタンプ、および（６）他の暗号化されたフィールドのいずれかの中の無作為交絡者番号。これらのオプションの多くは、実際には同時となる。さらに、これらの方針のオプションは、通信関係者自身を含む重要なコミュニティーの全メンバーにとって同じとなり、それによりそのメールＩＤまたはシステムＩＤにより、あるいは関連する明かなＭＣＨフィールドで「送信者」または「受信者」という言葉を使用するだけで、関係者にラベル付けできるようにする。
【０１３７】
複数の同時寄託キー
デバイスファームウェアルーチンをアップグレードし、製造メーカーの公開キーを置き換えるための前記機能に加えて、本発明の信用されたデバイスは、寄託された暗号化キーの複数のセットを同時に保守、管理する能力も持つ必要がある。通常、デバイスが、再キー入力、つまり新しい秘密暗号化キーの作成および寄託を行うサイクルを開始し、その結果、対応する新しい公開暗号化キーの寄託認証を受け取ると、デバイスは、新しく寄託された秘密キーに対するデバイスの信頼を強制するために、以前の秘密キーを消去する。代わりに、デバイスは、必要に応じて、暗号化されたデータを以前の秘密暗号化キーを使用してデータ記憶領域内に復旧するのに必要となる時間のような、短時間だけ以前の秘密キーを保持する。しかし、代わりの実施例においては、デバイスは、同じ秘密／公開暗号化キーのペアに関する第２の有効な寄託認証を作成するために、前記のようにユーザまたはデバイス所有者のどちらかからの再寄託命令も受け入れ、処理することができる。この実施例では、デバイスは、きっと寄託代理人の異なるリストと異なるマスタ寄託センタを使用して寄託プロセスを先に進め、第２マスタ寄託センタにより署名発行され、第１寄託認証に代えて使用できる同じ公開／秘密暗号化キーペアの別個の等しく有効な寄託認証を受け取るであろう。この第２公開暗号化キー認証は、デバイスのユーザが国際的に旅行し、他の国に位置する関係者と通信するケース、特にそれらの他国がその他国を起源とするまたはその他国で終端する通信の合法的な監督の実施を希望する場合に有効である。このようなケースでは、別の国で同じデバイスキーを再寄託することにより、ユーザまたは雇用者が時刻の寄託代理人の元のセットとビジネス（合法的な所有者のモニタ、損失したキーの復旧など）を行う便宜は許されたまま、ユーザ（またはユーザの雇用者）がその他の国での考えられる法的要件を満たすのに役立つことがある。したがって、所有者がその従業員のＭＣＨを追跡調査するのを可能とするためには、送信者および受取人所有者ＩＤが各ＭＣＨに表示され、それにより所有者にそれが本当にキーを取得する能力を持つ旨を告げるならば十分である可能性がある。時間および労力を節約するために、所有者は、外国の寄託認証番号、基礎デバイス番号および基礎デバイス認証を取得するためにこのようなＭＣＨを外国のマスタ寄託センタに送信するが、すでに所有している所有者の認証を確認し、実際の秘密キー分割部をリリースできるその国内寄託代理人に適用する。この手順により、デバイス所有者は、外国の寄託代理人から実際のキー分割部を取得するために必要となる可能性がある特別の法律上の手続きから解放される。
【０１３８】
国家安全保障輸出保護手段
米国政府の現在の方針とは、合衆国内でのアメリカ人市民による規制を受けない使用を許可するが、暗号デバイス、ソフトウェアまたはノウハウの輸出には重い制限および罰金を課すというものである。合衆国内での暗号デバイスの比較的に自由な個人的な使用を許可すると同時に、その国際的な使用に制限を課すように、本システムを修正することは可能である。こおようなシステムは、システム全体で使用される標準的なメッセージ書式に対する変更を最小とした、またはまったく行わないすべてのソフトウェアおよびハードウェアベンダに開放された別個の操作が共通の「方針領域」を可能とするだろう。さらに、キー寄託システムが、ある特定の企業が、その企業が寄託したキーを使用して暗号課された通信への警察のアクセスを容易にするという明示または暗示された義務なしに、それ自体の従業員による暗号の使用をモニタ、制御できる純粋な法人内の一国の状況で秘密寄託代理人の使用を可能とすることが望ましい。特に、このような企業は自ら使用するためにソフトウェアおよびハードウェアを購入するかもしれないが、犯罪者やテロリストを熱心に追求する警察により望まれる、短期枠組みでの秘密キーに対するアクセスの提供を行う公の義務を引き受けるのを断る可能性がある。
【０１３９】
これは、まず最初に、システム全体でのすべてのデバイスが、直接または間接的に、（前述のように）それぞれが確実であり信頼できるとしてシステム内のデバイスにより認識されるようにするために、寄託代理人、マスタ寄託センタおよびデバイス製造メーカーに対し認証を発行する全システム権威（ＳＷＡ）にリンクされていると仮定することにより実行できる。国内または世界的な通信システムは、実践的な目的のため、そのそれぞれが確実であるとしてＳＷＡにより認証されなければならない、複数の関連の内マスタ寄託センタおよびおよび代理人の存在をサポートしなければならない。マスタ寄託センタまたは寄託代理人に対して発行される各認証中で、ＳＷＡは、それを「公開」または「秘密」のどちらかとして指定する。「公開」マスタ寄託センタまたは寄託代理人とは、国の安全保障または警察の令状または召還状に速やかに応答する準備ができ、応答する責任があるもののことである。そのキーがこのような代理人に寄託されるユーザは、国境を越えた通信に関わることを許可される。「秘密」マスタ寄託センタまたは寄託代理人は、独自に使用するためにキー寄託システム技術をインストールしたが、公的なレベルでのサービスに対する責任を引き受けないそれらの単独企業または単独国家のキーセンタを含む。ＳＷＡからマスタ寄託センタまたは寄託代理人に対する認証には、国コードも含まれる。したがって、マスタ寄託センタにより発行、署名され、マスタ寄託センタＳＷＡ認証が添付される各ユーザの寄託認証は、ユーザの国コードも記載される。便宜上の問題として、ユーザの寄託認証が、ＳＷＡがその情報の正しさを施行することは不可能であるかもしれないが、それが公の寄託代理人または公ではない寄託代理人のどちらを起源とするのかも述べる必要があることに注意する。これにより、デバイスは、マスタ寄託センタのＳＷＡ認証を常に必要とするよりはるかに容易にこれらの規則を実行できるようになる。
【０１４０】
図２９および図３０は、国際的な暗号通信の送受の際の寄託要件の施行を示す。図２９に示されるように、送信者の信用されたデバイス２９は、送信者と受取人の両者の寄託認証２９１、２９３、および送信者および受取人が同じマスタ寄託センタで寄託されていない場合にはそのマスタ寄託センタＳＷＡ認証２９２、２９４を、国際通信を送信する前に必要とすることにより、このシステムを実施する。受取人ユーザおよびそのマスタ寄託センタの国コード２９５、２９６は、送信側デバイスが通信を送信できるように一致しなければならない。さらに、送信者および受取人が別の国々２９５、２９７にいる場合、および一方のユーザが公ではないマスタ寄託センタ２９８、２９９を使用している場合、送信側デバイスは、その受取人に対する通信を始めることを拒絶するだろう。図３０に示されるように、受取人の信用されたデバイス３００も、送信者および受取人が別の国々にいる場合に通信がどうにかして始められる場合、および一方のユーザが公ではない公開マスタ寄託センターを使用している場合に、通信の復号化を拒否することによりこのシステムを実施する。マスタ寄託センタがＳＷＡにより認証されるその公的なステータスを偽ることはできないため、およびたとえマスタ寄託センタが（ユーザが他国の領域に所属するように見えるようにするために）ユーザの国コードを偽ることができるとしても、デバイスがユーザの国コードとマスタ寄託センタの国コードの間の不一致を許さないため、これらの規則は、寄託されていない国際的な暗号通信を許可しないという望ましい方針を実現することになる。これらの規則はユーザが不適切に信用された暗号デバイスを国境を越えて転送することを妨げないが、ユーザが各国で寄託されたキーを維持し、各方針領域で適切なキーだけを使用して通信することを許すことにより、国の要件に容易に準拠できるようにする。
【０１４１】
マルチユーザデバイスバージョン
本発明の別の機能とは、同じデバイスを使用する異なるローカルユーザまたはリモートユーザとの通信の複数の異なるセッションを始動し、同時に管理する能力のことである。多くのより大規模なコンピュータは、大部分の場合、端末セッションを介して同時にログされるが、世界中の他のエンティティと暗号化されたセッションを開始することを希望する複数のユーザをサポートする。ただし、共用されたコンピュータでのユーザセッションごとに別個の信用されたデバイスを要求することがきわめて非効率的であるため、信用されたデバイスは、そのセッションの一意のメッセージシーケンス番号（ＭＳＮ）とともにそれを記憶することにより、各通信ごとにメッセージセッションキーを追跡調査できる。したがって、そのＭＳＨが付いた追加メッセージパケットが到着すると、これらのパケットは、遅延なく復号化され、応答が暗号化される。さらに、デバイスは、各ユーザ秘密キーをある特定のユーザー意識別番号とリンクし、各キーがパスワード、スマートカード、ＰＩＮ、生物測定、およびチャレンジ応答などのなんらかの適切なユーザ認証が提示された場合にのみ、使用できるようにする一方、複数のユーザの秘密復号化キーを寄託できる。ユーザ識別番号およびパスワード、または同等なものを各公開／秘密キーのペアに、それが寄託のために作成されるときに割り当てることにより、長さ、期限、再試行ロックアウト、および推論の容易さなどの通常のパスワードに対する制御を、許可されていないアクセスの可能性を制限する目的で、デバイスにより課すことができる。
【０１４２】
このようにして、キー寄託機能が付いた暗号システムおよび方法が提供される。当業者は、本発明が、図解の目的で提示されたのであり、制限のために提示されたのではない記述された実施例以外によっても実践可能であること、および本発明が以下の請求の範囲によってのみ制限されることを理解するであろう。
【０１４３】
また本願の実施例の記載は以下の各項に記載の発明を含む。
（１）認証可能な信用される秘密暗号ディジタル通信を、外部エンティティが前記通信をモニタできるようにする一方で、複数のユーザの間で生成するための方法であって、少なくとも１つの信用される寄託センタに、複数のユーザにより暗号通信のために使用される複数の非対称暗号化キーを寄託するステップと、前記少なくとも１つの寄託センタによる前記複数のキーのそれぞれの寄託を認証するステップと、前記複数のユーザの第１ユーザから前記複数のユーザの第２ユーザに対する通信を、前記複数のキーの第１キーを使用して暗号化するステップと、前記寄託される通信に、前記少なくとも１つの信用される寄託センタを識別するのに十分な情報を含むメッセージ制御ヘッダを含めるステップと、前記複数のキーの第２キーを使用して、前記複数のユーザの前記第２ユーザによる前記暗号化された通信を復号化するステップとを具備し、前記第２ユーザによる前記暗号化通信を復号化する前記ステップが、前記第１および第２ユーザの前記キーの認証、および有効なメッセージ制御ヘッダの前記通信内での存在を条件とする方法を含む。
【０１４４】
（２）前記第１ユーザからの通信を暗号化する前記ステップが、前記第１および第２ユーザの前記キーの認証および有効なメッセージ制御ヘッダの前記通信内での存在を条件とする（１）に記載の方法。
（３）前記通信が、記憶のために前記第１ユーザからそのユーザ自身に対して暗号化されるように、前記第１ユーザおよび前記第２ユーザが同一である（１）に記載の方法。
【０１４５】
（４）各ユーザが、各ユーザが公開暗号化キーと秘密暗号化キーの少なくとも１つの対応するペアを持つように、暗号通信の暗号化および復号化に使用する必要がある複数の対応する公開キーと秘密キーのペアを構成する複数の無作為に作成された非対称暗号化キーを持つ（１）に記載の方法。
（５）前記寄託するステップが、さらに、各ユーザのために、前記少なくとも１つの対応するキーのペアから成る秘密キーを部分に分割するステップと、少なくとも一人の受託人のそれぞれに、前記秘密キーの少なくとも１つの部分を提供するステップと、前記少なくとも一人の受託人のそれぞれに、前記受託人が、前記秘密キーの前記少なくとも１つの部分の正しい受領を確認できるようにするための確認情報を提供するステップと、前記少なくとも１つの信用された寄託センタによる、前記秘密キーの前記少なくとも１つの部分の前記少なくとも一人の受託人のそれぞれによる正しい受領を確認するステップとを具備する（４）に記載の方法。
【０１４６】
（６）前記寄託するステップが、さらに、前記分割するステップが前記寄託センタにより実行されるように、前記ユーザ秘密キーを含む前記少なくとも１つの寄託センタに対する通信を寄託するステップを具備する（５）に記載の方法。
（７）前記ユーザ秘密キーを含む前記少なくとも１つの寄託センタに対する通信を寄託する前記ステップが、さらに、前記ユーザが前記通信をディジタル署名するステップを具備する（６）に記載の方法。
【０１４７】
（８）前記分割するステップが、前記秘密キーを再構築するためには全Ｎ個の部分が必要となるように、さらに、各ユーザの秘密キーをＮ個の部分に分割することを具備する（５）に記載の方法。
（９）前記分割するステップが、Ｍ＜Ｎの場合、前記秘密キーを再構築するためにはＭ個の部分だけが必要となるように、さらに、各ユーザの秘密キーをＮ個の部分に分割することを具備する（５）に項記載の方法。
【０１４８】
（１０）少なくとも一人の受託人のそれぞれに前記秘密キーの少なくとも１つの部分を提供する前記ステップが、さらに、前記ユーザ秘密キーの前記少なくとも１つの部分を含む前記少なくとも一人の受託人のそれぞれに対する通信を暗号化するステップを具備する（５）に記載の方法。
【０１４９】
（１１）少なくとも一人の受託人のそれぞれに確認情報を提供する前記ステップが、さらに、前記確認情報を含む通信を前記少なくとも一人の受託人のそれぞれに対して暗号化するステップを具備する（１０）記載の方法。
（１２）前記ユーザ秘密キーの前記少なくとも１つの部分を含む前記少なくとも一人の受託人に対する通信を暗号化する前記ステップが、前記ユーザにより実行され、さらに、前記ユーザが前記通信にディジタル署名するステップを具備する（１１）に記載の方法。
【０１５０】
（１３）前記確認情報を含む前記少なくとも一人の受託人のそれぞれに対する通信を暗号化する前記ステップが、前記ユーザにより実行され、さらに、前記ユーザが前記通信をディジタル署名するステップを具備する（１２）に記載の方法。
（１４）前記ユーザ秘密キーの前記少なくとも１つの部分を含む前記少なくとも一人の受託人のそれぞれに対する通信を暗号化する前記ステップが、前記寄託センタにより実行され、さらに、前記寄託センタが前記通信にディジタル署名するステップを具備する（１３）に記載の方法。
【０１５１】
（１５）前記確認情報を含む前記少なくとも一人の受託人に対する通信を暗号化する前記ステップが、前記寄託センタにより実行され、さらに、前記寄託センタが前記通信にディジタル署名するステップを具備する（１４）に記載の方法。
（１６）前記少なくとも１つの寄託センタを確認する前記ステップが、各受託人に対して、前記受託人による前記ユーザの前記秘密キーの前記少なくとも１つの部分の受領を、前記寄託センタに対して通知するステップと、前記受託人による前記確認情報を前記寄託センターに対して通信するステップと、前記確認情報の前記受託人による正しい通信に基づいて、前記ユーザの前記秘密キーの前記少なくとも１つの部分の、前記受託人による正しい受領を、前記寄託センタにより確証するステップとを具備する（５）に記載の方法。
【０１５２】
（１７）前記受託人によって前記確認情報を前記寄託センタに対して通信する前記ステップが、前記確認情報を含む前記寄託センタに対する通信を暗号化するステップを具備する（１６）に記載の方法。
（１８）前記確認情報を含む前記寄託センタに対する通信を暗号化する前記ステップが、さらに、前記受託人が前記通信にディジタル署名するステップを具備する（１７）に記載の方法。
【０１５３】
（１９）前記複数のユーザのそれぞれが、一意のディジタル識別コードを持ち、前記方法が、さらに、前記少なくとも一人の受託人に前記ユーザの一意のディジタル識別コードを提供するステップを具備する（５）に記載の方法。
（２０）前記複数のキーのそれぞれの寄託を認証する前記ステップが、さらに、前記暗号化キーと対応するユーザの間のつながりを公証し、前記暗号化キーが寄託されたことを認証する前記複数の暗号化キーのそれぞれに対して、前記少なくとも１つの寄託センタにより寄託認証を発行することを含む（１）に記載の方法。
【０１５４】
（２１）前記複数のキーのそれぞれの寄託を認証する前記ステップが、さらに、前記対応するユーザに対して前記寄託認証のコピーを送信するステップを具備する（２０）に記載の方法。
（２２）前記複数のキーのそれぞれの寄託を認証する前記ステップが、さらに、前記寄託認証を前記複数のユーザの他者が利用できるようにするステップを具備する（２０）に記載の方法。
【０１５５】
（２３）前記寄託認証を利用できるようにするステップが、前記寄託認証をこのようなユーザがアクセスできる寄託認証ディレクトリの中に入れることを含む（２２）に記載の方法。
（２４）上位権威により前記少なくとも１つの信用された寄託センタの信頼性を認証するステップをさらに具備する（１）に記載の方法。
【０１５６】
（２５）信用された寄託センタを認証する前記ステップが、寄託のために前記寄託センタの信頼性を公証する前記少なくとも１つの信用される寄託センターのそれぞれに前記上位権威による認証を発行するステップとを具備する（２４）に記載の方法。
（２６）前記信用された寄託センタを認証するステップが、前記対応する信用される寄託センタに対して前記上位権威の認証のコピーを送信するステップをさらに具備する（２５）に記載の方法。
【０１５７】
（２７）前記信用される寄託センターを認証するステップが、前記複数のユーザの他のものが前記上位権威認証を利用できるようにするステップをさらに具備する（２５）に記載の方法。
（２８）前記上位権威が全システム権威を構成する（２５）に記載の方法。
【０１５８】
（２９）前記上位権威が信用されるデバイスの少なくとも１つの製造メーカーを構成する（２５）に記載の方法。
（３０）前記信用される寄託センタを認証するステップが、デバイスの前記少なくとも１つの製造メーカーの信頼性を公証し、製造された前記デバイスの非対称暗号化キーを無作為に作成し、読取り不能の不正な動きを防止するやり方で前記キーを記憶する能力を立証する、デバイスの前記少なくとも１つの製造メーカーのそれぞれに対して、全システム権威による製造メーカー認証を発行するステップをさらに具備する（２９）に記載の方法。
（３１）前記信用された寄託センタを認証するステップが、前記対応する製造メーカーに対して前記製造メーカー認証のコピーを送信するステップをさらに具備する（３０）に記載の方法。
【０１５９】
（３２）前記信用された寄託センタを認証するステップが、前記製造メーカーにより製造されるデバイスのユーザに対して前記製造メーカー認証のコピーを送信するステップをさらに具備する（３０）に記載の方法。
（３３）前記複数のキーのそれぞれの寄託を認証するステップが、前記対応する暗号化キーのペアと対応するユーザの間のつながりを公証し、前記対応する暗号化キーのペアの前記秘密キーが寄託された旨を認証する前記対応する暗号化キーのペアのそれぞれに対して、１つの寄託センタにより寄託認証を発行することを具備する（４）に記載の方法。
【０１６０】
（３４）前記複数のキーのそれぞれの寄託を認証するステップが、前記対応するユーザに対して前記寄託署名書のコピーを送信するステップをさらに具備する（３３）に記載の方法。
（３５）前記複数のキーのそれぞれの寄託を認証するステップが、前記寄託認証を前記複数のユーザのその他のものが利用できるようにするステップをさらに具備する（３３）に記載の方法。
【０１６１】
（３６）前記寄託認証を利用できるようにするステップが、前記ユーザが利用しやすい寄託認証ディレクトリの中に前記寄託認証を入れることを具備する（３５）に記載の方法。
（３７）前記複数のキーのそれぞれの寄託を認証するステップが、前記寄託認証を発行する前に、前記少なくとも１つの寄託センタにより前記対応する暗号化キーのペアのそれぞれの秘密キーの寄託を確認することを具備する（３３）に記載の方法。
【０１６２】
（３８）前記対応する暗号化キーのペアの寄託認証が、前記認証を発行する寄託センタの識別、前記寄託認証のディジタルコード識別、および前記対応する暗号化キーのペアの前記公開キーを構成する（３７）に記載の方法。
（３９）前記メッセージ制御ヘッダを入れるステップが、前記第１ユーザの寄託センタの識別および前記第１ユーザの寄託認証の前記ディジタルコード識別を構成する暗号メッセージ制御ヘッダパケットを形成するステップを具備する（３８）に記載の方法。
【０１６３】
（４０）前記メッセージ制御ヘッダを入れるステップが、前記第２ユーザの寄託センタの識別および前記第２ユーザの寄託認証の前記ディジタルコード識別を構成する暗号メッセージ制御ヘッダパケットを形成するステップを具備する（３９）に記載の方法。
【０１６４】
（４１）前記第１ユーザの寄託センタおよび前記第２ユーザの寄託センタが同一であり、
メッセージ制御ヘッダを入れる前記ステップが、前記第１および第２ユーザの寄託センタの識別および前記寄託認証のそれぞれの前記ディジタル識別コードを構成する暗号メッセージ制御ヘッダパケットを形成するステップをさらに具備する（４０）に記載の方法。
【０１６５】
（４２）前記メッセージ制御ヘッダを入れるステップが、前記第１ユーザの雇用者または監督者の識別を構成する暗号メッセージ制御ヘッダパケットを形成するステップをさらに具備する（３９）に記載の方法。
（４３）前記メッセージ制御ヘッダを入れるステップが、前記第２ユーザの雇用者または監督者の識別を構成する暗号メッセージ制御ヘッダを形成するステップとを具備する（４２）に記載の方法。
【０１６６】
（４４）前記第１ユーザの雇用者または監督者および前記第２ユーザの雇用者または監督者が同一であり、 メッセージ制御ヘッダを入れる前記ステップが、さらに、前記第１および第２ユーザの雇用者または監督者の識別、および前記寄託認証のそれぞれの前記ディジタル識別コードを形成するステップを具備する（４３）に記載の方法。
【０１６７】
（４５）前記メッセージ制御ヘッダを入れるステップが、前記第１ユーザによる前記メッセージ制御ヘッダの形成の日付および時刻を示すタイムスタンプを構成する暗号メッセージ制御ヘッダパケットを形成するステップをさらに具備する（３９）に記載の方法。
【０１６８】
（４６）前記ユーザが、前記暗号通信および前記メッセージ制御ヘッダの形成の日付および時刻を示すタイムスタンプを作成するための信用されるタイムクロックを備え、メッセージ制御ヘッダを入れる前記ステップが、前記タイムスタンプの信頼性を認証するステップをさらに具備する（４５）に記載の方法。
【０１６９】
（４７）前記タイムスタンプの信頼性を認証するステップが、前記タイムスタンプを作成するために、前記タイムクロックの信頼性を公証する上位権威による認証を発行することを具備する（４６）に記載の方法。
（４８）前記タイムスタンプを認証するステップが、作成された前記タイムスタンプのそれぞれに前記タイムクロック認証を添付することをさらに具備する（４７）に記載の方法。
【０１７０】
（４９）前記上位権威が全システム権威を構成する（４７）に記載の方法。
（５０）前記上位権威が前記タイムクロックの製造メーカーを構成する（４７）に記載の方法。
（５１）前記上位権威が寄託センタを構成し、前記タイムクロック認証が前記寄託認証内で発行され、デバイス製造メーカーの判断および前記寄託プロセス中のデバイス情報に基づく（４６）に記載の方法。
【０１７１】
（５２）盗聴装置設置許可を持つ前記外部エンティティにより前記暗号通信をモニタするステップをさらに具備する（３９）に記載の方法。
（５３）前記モニタするステップが、前記外部エンティティによる前記暗号化された通信に割り込むステップと、前記盗聴措置設置許可および前記メッセージ制御ヘッダを前記第１ユーザの寄託センタに提示するステップと、前記第１ユーザの寄託センタに寄託された前記第１ユーザの前記対応する暗号化キーのページの秘密キーを取得するステップと、前記第１ユーザの前記秘密キーを前記暗号化された通信の復号化に使用するステップとをさらに具備する（５１）に記載の方法。
【０１７２】
（５４）前記提示するステップが、前記メッセージ制御ヘッダから前記第１ユーザの寄託センタの前記識別および前記第１ユーザの寄託認証の前記ディジタル識別コードを抽出するステップと、前記盗聴装置設置許可および前記第１ユーザの寄託認証の前記ディジタル識別コードを前記第１ユーザの寄託センタに提示するステップとをさらに具備する（５３）に記載の方法。
【０１７３】
（５５）前記第１ユーザが、前記暗号通信および前記メッセージ制御ヘッダの形成の日付および時刻を示すタイムスタンプを作成するための信用されたタイムクロックを備え、前記メッセージ制御ヘッダを入れるステップが、前記第１ユーザによる前記メッセージ制御ヘッダの形成の日付および時刻を示すタイムスタンプを構成する暗号メッセージ制御ヘッダパケットを形成するステップと、タイムスタンプを作成する目的で、前記タイムクロックの信頼性を認証するステップとをさらに具備する（５４）に記載の方法。
【０１７４】
（５６）前記信用されるタイムクロックが、前記タイムクロックの製造メーカーによってだけ設定または較正できる（５５）に記載の方法。
（５７）前記盗聴装置設置許可が、少なくとも１つの事前に定義される制約を条件とする（５３）に記載の方法。
【０１７５】
（５８）前記少なくとも１つの事前定義される制約が、前記盗聴装置設置許可に、その前に前記第１ユーザの前記秘密キーを取得する前記ステップが発生してはならない開始日付および時刻が含まれるような時間制約を具備する（５７）に記載の方法。
（５９）前記少なくとも１つの事前定義される制約が、前記盗聴装置設置許可に、その後では前記第１ユーザの前記秘密キーを取得する前記ステップが発生してはならない終了日付および時刻が含まれるようなさらに時間制約を具備する（５８）に記載の方法。
【０１７６】
（６０）前記少なくとも１つの事前定義される制約が、前記盗聴装置設置許可に、それ以降前記第１ユーザの前記秘密キーを取得する前記ステップが発生してはならない終了日付および時刻が含まれるような時間制約を具備する（５３）に記載の方法。
（６１）前記第１ユーザの秘密キーを取得するステップが、前記少なくとも一人の受託人から、前記第１ユーザの秘密キーの前記少なくとも１つの部分を回収するステップと、前記秘密キーの前記回収された部分から前記秘密キーを再構築するステップとをさらに具備する（５３）に記載の方法。
【０１７７】
（６２）前記取得するステップが、前記寄託センタにより実行される（６１）に記載の方法。
（６３）前記取得するステップが、前記外部エンティティにより実行される（６１）に記載の方法。
（６４）前記第２ユーザの寄託センタの識別および前記第２ユーザの寄託認証の前記ディジタル識別コードを構成する暗号メッセージ制御ヘッダパケットを形成するステップとを具備する（３８）に記載の方法。
【０１７８】
（６５）前記メッセージ制御ヘッダを入れるステップが、前記第２ユーザの雇用者または監督者の識別を構成する暗号メッセージ制御ヘッダパケットを形成するステップをさらに具備する（６４）に記載の方法。
（６６）盗聴装置設置許可を持つ前記外部エンティティによる前記暗号通信をモニタするステップをさらに具備する（６４）に記載の方法。
【０１７９】
（６７）前記モニタするステップが、前記外部エンティティによる前記暗号化された通信に割り込むステップと、前記盗聴装置設置許可および前記メッセージ制御ヘッダを前記第２ユーザの寄託センタに提示するステップと、前記第２ユーザの寄託センタに寄託された、前記第２ユーザの前記対応する暗号化キーのペアの秘密キーを取得するステップと、前記暗号化された通信を復号化するために、前記第２ユーザの前記秘密キーを使用するステップとをさらに具備する（６６）に記載の方法。
【０１８０】
（６８）前記提示するステップが、前記メッセージ制御ヘッダから、前記第２ユーザの寄託センタの前記識別および前記第２ユーザの寄託認証の前記ディジタル識別を抽出するステップと、前記盗聴装置設置許可および前記第２ユーザの寄託認証の前記ディジタルコード識別を前記第２ユーザの寄託センタに対して提示するステップとをさらに具備する（６７）に記載の方法。
【０１８１】
（６９）前記第１ユーザが、前記暗号通信および前記メッセージ制御ヘッダの形成の日付および時刻を示すタイムスタンプを作成するために信用されるタイムクロックを備え、
前記メッセージ制御ヘッダを入れるステップが、前記第１ユーザによる前記メッセージ制御ヘッダの形成の日付および時刻を示すタイムスタンプを構成する暗号メッセージ制御ヘッダパケットを形成するステップと、タイムスタンプを作成する目的で前記タイムクロックの信頼性を認証するステップとをさらに具備する（６８）に記載の方法。
【０１８２】
（７０）前記信用されたタイムクロックが、前記タイムクロックの製造メーカーによってのみ設定または較正可能な（６９）に記載の方法。
（７１）前記盗聴装置許可が、少なくとも１つの事前定義された制約を条件とする（６７）に記載の方法。
（７２）前記少なくとも１つの事前定義された制約が、前記盗聴装置設置許可が、それ以前は前記第２ユーザの前記秘密キーを取得する前記ステップが発生してはならない開始日付および時刻を含むような時間制約を具備する（７１）に記載の方法。
【０１８３】
（７３）前記少なくとも１つの事前定義された制約が、前記盗聴装置設置許可が、それ以後は前記第２ユーザの前記秘密キーを取得する前記ステップが発生してはならない終了日付および時刻を含むようなさらなる時間制約を具備する（７２）に記載の方法。
【０１８４】
（７４）前記少なくとも１つの事前定義される制約が、前記盗聴装置設置許可が、それ以後は前記第２ユーザの前記秘密キーを取得する前記ステップが発生してはならない終了日付および時刻を含むような時間制約を具備する（７３）に記載の方法。
（７５）前記第２ユーザの秘密キーを取得するステップが、前記少なくとも一人の受託人から前記第２ユーザの秘密キーの前記少なくとも１つの部分を回収するステップと、前記秘密キーの前記回収された部分から前記秘密キーを再構築するステップとをさらに具備する（６７）に記載の方法。
【０１８５】
（７６）前記取得するステップが、前記寄託センタにより実行される（７５）に記載の方法。
（７７）前記取得するステップが、前記外部エンティティにより実行される（７５）に記載の方法。
（７８）公開キーと秘密キーの前記複数の対応するペアの中の各一致ペアに対して、前記秘密キーだけが前記公開キーを使用して暗号化された通信を復号化できる（４）に記載の方法。
【０１８６】
（７９）前記第１ユーザにより前記第２ユーザに対する前記通信を暗号化するために使用される前記複数のキーの前記第１キーが、前記第２ユーザの公開キーを具備する（７８）に記載の方法。
（８０）前記第２ユーザにより前記暗号化された通信の復号化に使用される前記複数のキーの前記第２キーが、前記第２ユーザの秘密キーを具備する（７８）に記載の方法。
【０１８７】
（８１）前記通信を暗号化するステップが、前記第１ユーザと前記第２ユーザの間の暗号通信の暗号化および復号化の両方で使用するために一意の暗号化キーを作成するステップと、前記暗号化キーを使用して、前記第１ユーザによる前記第２ユーザに対する前記通信を暗号化するステップとをさらに具備する（１）に記載の方法。
【０１８８】
（８２）前記一意の暗号化キーを作成するステップが、
前記第２ユーザの秘密キーおよび少なくとも１つの公開番号を使用して、前記第２ユーザによる前記第２ユーザの中間番号を計算するステップと、前記第１ユーザによる前記第２ユーザの中間番号を取得するステップと、前記第１ユーザの秘密キーおよび前記第２ユーザの前記中間キーを使用して、前記第１ユーザによる前記暗号化キーを計算するステップとを具備し、前記暗号化キーを用いて暗号化された前記第１ユーザから前記第２ユーザへの前記通信が、前記暗号化キーだけを用いて復号化できるようにする（８１）に記載の方法。
【０１８９】
（８３）前記第２ユーザの前記中間番号および前記少なくとも１つの公開番号が前記第２ユーザの公開キーを構成する（８２）に記載の方法。
（８４）前記第１ユーザにより前記第２ユーザに対する前記通信の暗号化に使用される前記複数のキーの前記第１キーが、前記暗号化キーを計算する前記ステップで使用される前記第１ユーザの前記秘密キーを具備する（８２）記載の方法。
【０１９０】
（８５）前記第２ユーザにより前記暗号化された通信の復号化に使用される前記複数のキーの前記第２キーが、中間番号を計算する前記ステップで使用される前記第２ユーザの前記秘密キーを具備する（８２）に記載の方法。
（８６）前記第１ユーザおよび前記少なくとも１つの公開番号を使用して、前記第１ユーザによる前記第ユーザの中間番号を計算するステップをさらに具備する（８２）に記載の方法。
【０１９１】
（８７）前記メッセージ制御ヘッダを入れるステップが、前記第１ユーザの前記中間番号および前記少なくとも１つの公開番号を構成するメッセージ制御ヘッダを形成するステップをさらに具備する（８６）に記載の方法。
（８８）前記第２ユーザによる前記暗号化された通信を復号化する前記ステップが、前記第２ユーザの前記秘密キーおよび前記第１ユーザの前記中間番号を使用して、前記第２ユーザによる前記暗号化キーを計算するステップと、前記暗号化キーを使用する前記第２ユーザによる前記第１ユーザからの前記通信を復号化するステップとをさらに具備する（８７）に記載の方法。
【０１９２】
（８９）前記一意の暗号化キーを作成するステップが、前記第１ユーザおよび前記第２ユーザのそれぞれにより対話で前記暗号化キーを作成するステップを具備する（８１）に記載の方法。
（９０）前記第１ユーザおよび前記第２ユーザのそれぞれにより対話で前記暗号
化キーを作成するステップが、前記第１ユーザの秘密キーおよび少なくとも１つの公開キーを使用して、前記第１ユーザによる第１中間番号を計算するステップと、前記第２ユーザの秘密キーおよび少なくとも１つの公開キーを使用して、前記第２ユーザによる第２中間番号を計算するステップと、前記第１ユーザの前記秘密キーおよび前記第２中間番号を使用して、前記第１ユーザによる前記暗号化キーを計算するステップと、前記第２ユーザの前記秘密キーおよび前記第１中間番号を使用して、前記第２ユーザによる前記暗号化キーを計算するステップとを具備し、前記暗号化キーを使用して暗号化される前記第１ユーザから前記第２ユーザへのあるいは前記第２ユーザから前記第１ユーザへの前記通信が、前記暗号化キーを用いる場合だけ復号化できるようにする（８９）に記載の方法。
【０１９３】
（９１）前記第１ユーザにより前記第２ユーザへの前記通信の暗号化に使用される前記複数のキーの前記第１キーが、第１中間番号を計算する前記ステップに使用される前記第１ユーザの前記秘密キーを具備する（９０）に記載の方法。
（９２）前記第２ユーザにより前記暗号化された通信を復号化するのに使用される前記複数のキーの前記第２キーが、第２中間番号を計算する前記ステップで使用される前記第２ユーザの前記秘密キーを具備する（９０）に記載の方法。
【０１９４】
（９３）前記第２ユーザによる前記暗号化された通信を復号化する前記ステップが、前記暗号化キーを用いる前記第１ユーザからの前記通信を前記第２ユーザにより復号化するステップをさらに具備する（９０）に記載の方法。
（９４）各信用デバイスが、対応するキーのペアの公開キーが前記デバイスに対する暗号通信の暗号化に使用され、前記対応するキーのペアの対応する秘密キーが前記暗号通信の復号化に使用される無作為に作成される非対称暗号化キーの少なくとも１つの対応するペアを持つ、複数の信用されるデバイスを備える暗号システムにおいて、外部エンティティが前記通信をモニタできるようにしつつ、複数のデバイスの間の認証できる信用された暗号通信を作成するための方法であって、前記信用されたデバイスのそれぞれの暗号化キーの前記対応するペアの少なくとも１つの公開ペアを、少なくとも１つの寄託センタに寄託するステップと、前記少なくとも１つの寄託センタによる前記デバイスのそれぞれの前記対応するキーのペアの寄託を保証するステップと、前記第２デバイスの前記対応するキーのペアの公開キーを使用して、前記デバイスの２番目への前記デバイスの１番目からの通信を暗号化するステップと、前記の少なくとも１つの信用された寄託センタを識別するのに十分な情報を含むメッセージ制御ヘッダを、前記暗号化された通信とともに含むステップと、前記第２デバイスの前記対応するキーのペアの秘密キーを使用して、前記第２デバイスによる前記暗号化される通信を復号化するステップとを具備し、前記第２デバイスによる前記暗号化される通信を復号化する前記ステップが、前記第１デバイスおよび前記第２デバイスのそれぞれの前記秘密キーの認証、および有効なメッセージ制御ヘッダの前記通信内での存在を条件とする方法。
【０１９５】
（９５）前記第１ステップからの通信を暗号化する前記ステップが、前記第１デバイスおよび前記第２デバイスのそれぞれの前記秘密キーの認証および有効なメッセージ制御ヘッダ内での存在を条件にする（９４）に記載の方法。
９６）前記少なくとも１つの非対称暗号化キーの対応するペアのそれぞれに、前記秘密キーだけが、前記公開キーを使用して暗号化された通信を復号化できる（９４）に記載の方法。
【０１９６】
（９７）記憶のために、前記通信が前記第１デバイスからそれ自体に対して暗号化されるように、前記第１デバイスおよび前記第２デバイスが同一である（９４）に記載の方法。
（９８）各信用されたデバイスが、前記少なくとも１つの対応する暗号化キーのペアを無作為に作成し、安全で、不正な動きを防止し、読取り不可能なやり方でキーの前記ペアを記憶する能力を持つ（９４）に記載の方法。
【０１９７】
（９９）各前記信用されるデバイスに製造メーカーがあり、さらに、前記デバイスの前記キーを無作為に作成し、記憶する能力を、上位権威により認証するステップを具備する（９８）に記載の方法。
（１００）前記製造メーカーを認証するステップが、前記製造メーカーの信頼性および前記デバイスの前記キーを無作為に作成し、記憶する能力を公証する、前記製造メーカーに対する前記上位権威による認証を発行するステップを具備する（９９）に記載の方法。
【０１９８】
（１０１）前記上位権威が全システム権威を構成する（９９）に記載の方法。
（１０２）前記寄託するステップが、各信用されるデバイスに対して、前記秘密キーを部分に分割するステップと、少なくとも一人の受託人のそれぞれに、前記秘密キーの少なくとも１つの部分を提供するステップと、前記少なくとも一人の受託人に、前記受託人が、前記秘密キーの前記少なくとも１つの部分の正しい受領を確認できるようにする確認情報を提供するステップと、前記秘密キーの前記少なくとも１つの部分の前記少なくとも一人の受託人のそれぞれによる正しい受領を、前記少なくとも１つの信用された寄託センタにより確認するステップとをさらに具備する（９４）に記載の方法。
【０１９９】
（１０３）前記少なくとも１つの信用された寄託センタのそれぞれが、暗号通信の暗号化および復号化に使用される必要がある少なくとも１つの対応する公開暗号化キーおよび秘密暗号化キーのペアを持ち、前記寄託するステップが、前記分解するステップが前記寄託センタにより実行されるように、前記信用されたデバイス秘密キーを含む前記少なくとも１つの寄託センタに対する通信を暗号化するステップをさらに具備する（１０２）に記載の方法。
【０２００】
（１０４）前記少なくとも１つの信用された寄託センタの前記暗号化キーが、少なくとも１つの寄託センタのグループが寄託目的で前記製造メーカーにより選択されるように、前記デバイスの製造メーカーにより前記信用されたデバイスの中に事前に埋め込まれ、前記寄託するステップが、前記事前に埋め込まれた寄託センタ暗号化キーの１つを使用して、少なくとも１つの寄託センタの前記グループの中から１つの寄託センタに対する前記秘密キーの少なくとも１つの部分を含む通信を暗号化するステップをさらに具備する（１０３）に記載の方法。
【０２０１】
（１０５）前記少なくとも１つの寄託センタの前記暗号化キーが、前記デバイスが利用しやすい寄託認証ディレクトリから前記デバイスにより取得される（１０３）に記載の方法。
（１０６）前記少なくとも１つの寄託センタに対する前記信用されたデバイス秘密キーを含む通信を暗号化する前記ステップが、前記デバイスにより実行され、前記デバイスが前記通信にディジタル署名するステップをさらに具備する（１０３）に記載の方法。
【０２０２】
（１０７）前記少なくとも一人の受託人のそれぞれが、暗号通信の暗号化および復号化に使用される必要があるすくなくとも１つの対応する公開暗号化キーと秘密暗号化キーのペアを持ち、前記分割するステップが、前記デバイスにより実行される（１０２）に記載の方法。
【０２０３】
（１０８）前記少なくとも一人の受託人の前記暗号化キーが、前記少なくとも一人の受託人のグループが寄託目的で前記製造メーカーにより選択されるように、前記デバイスの製造メーカーにより前記信用されたデバイスの中に事前に埋め込まれ、少なくとも一人の受託人のそれぞれに、前記秘密キーの少なくとも１つの部分を提供する前記ステップが、前記事前に埋め込まれた受託人暗号化キーの１つを使用して、前記少なくとも一人の受託人の前記グループの中から少なくとも一人の受託人のそれぞれに対する前記秘密キーの少なくとも１つの部分で通信を暗号化するステップをさらに具備する（１０７）に記載の方法。
【０２０４】
（１０９）前記少なくとも一人の受託人のそれぞれに対する通信を暗号化するステップが、前記デバイスにより実行され、前記デバイスが前記通信をディジタル署名するステップをさらに具備する（１０８）に記載の方法。
（１１０）前記秘密キーの少なくとも１つの部分を少なくとも一人の受託人のそれぞれに提供するステップが、前記秘密キーの部分を受け取った前記少なくとも一人の受託人のそれぞれの識別を構成する前記寄託センタに対する通信を暗号化するステップをさらに具備する（１０８）に記載の方法。
【０２０５】
（１１１）前記少なくとも一人の受託人のそれぞれに確認情報を提供するステップが、前記少なくとも一人の受託人のそれぞれに対して前記確認情報を含む通信を暗号化するステップをさらに具備する（１０８）に記載の方法。
（１１２）前記確認情報を含む前記少なくとも一人の受託人のそれぞれに対する通信を暗号化するステップが、前記デバイスにより実行され、前記デバイスが前記通信をディジタル署名するステップをさらに具備する（１１１）に記載の方法。
【０２０６】
（１１３）前記少なくとも一人の受託人のそれぞれに確認情報を提供するステップが、（ａ）前記確認情報を受け取った前記少なくとも一人の受託人のそれぞれの識別、および（ｂ）前記確認情報を構成する前記寄託センタに対する通信を暗号化するステップをさらに具備する（１１１）に記載の方法。
【０２０７】
（１１４）前記分割するステップが、前記秘密キーを再構築するために、Ｎ個の部分すべてが必要となるように、さらに、前記秘密キーをＮ個の部分に分割することを具備する（１０２）に記載の方法。
（１１５）前記分割するステップが、Ｍ＜Ｎの場合、前記秘密キーを再構築するために、Ｍ個の部分だけが必要とされるように、前記秘密キーをＮ個の部分に分割することを具備する（１０２）に記載の方法。
【０２０８】
（１１６）前記少なくとも一人の受託人のそれぞれに前記秘密キーの少なくとも１つの部分を提供するステップが、前記秘密キーの前記少なくとも１つの部分を含む前記少なくとも一人の受託人のそれぞれに対する通信を暗号化するステップをさらに具備する（１０２）に記載の方法。
【０２０９】
（１１７）前記デバイス秘密キーの前記少なくとも１つの部分を含む前記少なくとも一人の受託人のそれぞれに対する通信を暗号化するステップが、前記通信にディジタル署名するステップを具備する（１１６）に記載の方法。
（１１８）前記少なくとも一人の受託人のそれぞれに確認情報を提供するステップが、前記確認情報を含む通信を前記少なくとも一人の受託人のそれぞれに対して暗号化するステップをさらに具備する（１１６）に記載の方法。
【０２１０】
（１１９）前記確認情報を含む前記少なくとも一人の受託人のそれぞれに対する通信を暗号化するステップが、前記寄託センタが前記通信をディジタル署名するステップをさらに具備する（１１８）に記載の方法。
（１２０）前記少なくとも１つの寄託センタにより確認するステップが、各受託人に対して、前記受託人による前記デバイスの前記秘密キーの前記少なくとも１つの部分の受領を前記寄託センタに通知するステップと、前記受託人による、前記確認情報を前記寄託センタに対して通信するステップと、前記確認情報の前記受託人による正しい通信に基づき、前記デバイスの前記秘密キーの前記少なくとも１つの部分の前記受託人による正しい受領を前記寄託センタにより確証するステップとを具備する（１０２）に記載の方法。
【０２１１】
（１２１）前記受託人による前記確認情報を前記寄託センタに対して通信するステップが、前記確認情報を含む前記寄託センタに対する通信を暗号化するステップを具備する（１２０）に記載の方法。
（１２２）前記確認情報を含む前記寄託センタに対する通信を暗号化するステップが、前記受託人が前記通信をディジタル署名するステップをさらに具備する（１２１）に記載の方法。
【０２１２】
（１２３）前記複数の信用されたデバイスのそれぞれに一意のディジタル識別コードが設定され、前記方法が、前記デバイスの一意のディジタル識別コードを前記少なくとも一人の受託人のそれぞれに提供するステップをさらに具備する（１０２）に記載の方法。
【０２１３】
（１２４）前記少なくとも１つの信用された寄託センタの信頼度を上位権威により認証するステップをさらに具備する（１０２）に記載の方法。
（１２５）信用された寄託センタを認証する前記ステップが、寄託目的のために前記寄託センタの信頼度を交渉する、前記少なくとも１つの信用された寄託センタのそれぞれに、前記上位権威により認証を発行するステップをさらに具備する（１２４）に記載の方法。
【０２１４】
（１２６）前記上位権威が全システム権威を構成する（１２５）に記載の方法。
（１２７）前記上位権威が、デバイスの少なくとも１つの製造メーカーを構成する（１２５）に記載の方法。
（１２８）前記信用された寄託センタを認証するステップが、デバイスの前記少なくとも１つの製造メーカーの信頼度を公証し、製造される前記デバイスのそれぞれの非対称暗号化キーの対応するペアを無作為に作成し、読取り不能で不正な動きを防止するやり方で前記キーを記憶する能力を立証するデバイスの前記少なくとも１つの製造メーカーのそれぞれに全市巣権威による認証を発行するステップをさらに具備する（１２７）に記載の方法。
【０２１５】
（１２９）前記秘密キーの寄託を認証するステップが、前記対応する暗号化キーのペアの前記公開キーと前記秘密キーの間のつながりを公証し、前記対応する暗号化キーのペアの前記秘密キーが寄託として受託されていることをりっそうする、前記デバイスの前記対応する暗号化キーペアのそれぞれに対して、１つの寄託代理人による寄託認証を発行するステップをさらに具備する（９４）に記載の方法。
【０２１６】
（１３０）前記対応する暗号化キーペアのそれぞれの前記寄託認証が、前記認証発行寄託センタの識別、前記寄託認証のディジタル識別コード、および前記対応する暗号化キーペアの前記公開キーを具備する（１２９）に記載の方法。
（１３１）前記秘密キーの寄託を認証するステップが、前記寄託認証を発行する前記ステップの前に、前記対応する暗号化キーペアの前記秘密キーの寄託を前記認証発行寄託代理人により確証するステップをさらに具備する（１２９）に記載の方法。
【０２１７】
（１３２）前記少なくとも１つの寄託センタによる前記確証するステップが、各受託人に対して、前記受託人による、前記デバイスの前記秘密キーの前記少なくとも１つの部分の受領を前記寄託センタに通知するステップと、前記受託人による前記確認情報の前記寄託センタに対する通信、および前記確認情報の前記受託人による正しい通信に基づき、前記寄託センタによる、前記デバイスの前記秘密キーの前記少なくとも１つの部分の前記受託人による正しい受領を家訓するステップとを具備する（１３１）に記載の方法。
【０２１８】
（１３３）前記確認情報を前記寄託センタに対して前記受託人により通信する前記ステップが、前記確認情報を含む前記寄託センタに対する通信を暗号化するステップを具備する（１３２）に記載の方法。
（１３４）前記確認情報を含む前記寄託センタに対する通信を暗号化する前記ステップが、前記受託人が前記通信をディジタル署名するステップをさらに具備する（１３３）に記載の方法。
【０２１９】
（１３５）前記対応する暗号化キーペアのそれぞれに対する前記寄託認証が、前記認証発行寄託センタの識別、前記寄託認証のディジタル識別コード、および前記対応する暗号化キーペアの前記公開キーを具備する（１３１）に記載の方法。
（１３６）前記メッセージ制御ヘッダを入れるステップが、前記第１デバイスの寄託センタの識別、および前記第１デバイスの寄託認証の前記ディジタル識別コードを構成する暗号メッセージ制御ヘッダパケットを形成するステップを具備する（１３５）に記載の方法。
【０２２０】
（１３７）前記メッセージ制御ヘッダを入れるステップが、前記第２デバイスの寄託センタの識別および前記第２デバイスの寄託認証の前記ディジタル識別コードを構成する暗号メッセージ制御ヘッダパケットを形成するステップを具備する（１３６）に記載の方法。
【０２２１】
（１３８）前記第１デバイスの寄託センタおよび前記第２デバイスの寄託センタが同一であり、前記メッセージ制御ヘッダを入れる前記ステップが、前記第１および第２デバイスの寄託センタの識別および前記寄託認証のそれぞれの前記ディジタル識別コードを具備する暗号メッセージ制御ヘッダパケットを形成するステップを具備する（１３７）に記載の方法。
【０２２２】
（１３９）前記メッセージ制御ヘッダを入れるステップが、前記第１デバイスの所有者の識別または前記第１デバイスのユーザの雇用者または監督者の識別を構成する暗号メッセージ制御ヘッダを形成するステップをさらに具備する（１３６）に記載の方法。
【０２２３】
（１４０）前記メッセージ制御ヘッダを入れるステップが、前記第２デバイスの所有者の識別または前記第２デバイスのユーザの雇用者または監督者の識別を構成する暗号メッセージ制御ヘッダパケットを形成するステップをさらに具備する（１３９）に記載の方法。
【０２２４】
（１４１）前記第１デバイスおよび第２デバイスの前記所有者が、前記第１デバイスおよび第２デバイスの前記ユーザの前記雇用者または監督者と同一であり、
前記メッセージ制御ヘッダを入れるステップが、前記所有者、雇用者または監督者の識別、および前記寄託認証のそれぞれの前記ディジタル識別を構成する暗号メッセージ制御ヘッダを形成するステップをさらに具備する（１４０）に記載の方法。
【０２２５】
（１４２）前記第１デバイスによる前記メッセージ制御ヘッダの形成の日付および時刻を示す前記タイムスタンプを構成する暗号メッセージ制御ヘッダを形成するステップをさらに具備する（１３６）に記載の方法。
（１４３）前記デバイスが、前記暗号通信および前記メッセージ制御ヘッダの作成の日付および時刻を示すタイムスタンプを作成するための信用されたタイムクロックを備え、前記メッセージ制御ヘッダを入れるステップが、前記タイムスタンプの信頼度を認証するステップをさらに具備する（１４２）に記載の方法。
【０２２６】
（１４４）前記タイムスタンプの信頼度を認証する前記ステップが、前記タイムスタンプを作成するために前記タイムクロックの信頼度を公証する、上位権威による認証を発行することを具備する（１４３）に記載の方法。
（１４５）前記タイムスタンプを認証する前記ステップが、作成された前記タイムスタンプのそれぞれに前記タイムクロック認証を添付することをさらに具備する（１４４）に記載の方法。
【０２２７】
（１４６）前記上位権威タイムクロックが、全システム権威を構成する（１４４）に記載の方法。
（１４７）前記上位権威タイムクロックが、前記デバイスの製造メーカーを構成する（１４４）に記載の方法。
（１４８）前記上位権威タイムクロックは、寄託センタを構成する（１４４）に記載の方法。
【０２２８】
（１４９）前記信用されたタイムクロックが、前記タイムクロックの製造メーカーによってのみ設定または較正できる（１４３）に記載の方法。
（１５０）前記タイムクロックが、前記タイムクロックの製造メーカーにより許可されたエンティティによってのみ設定または較正できる（１４３）に記載の方法。
【０２２９】
（１５１）盗聴装置設置許可を持つ前記外部エンティティによる前記暗号通信をモニタするステップをさらに具備する（１３６）に記載の方法。
（１５２）前記モニタするステップが、前記外部エンティティによる前記暗号化された通信に割り込むステップと、前記盗聴装置設置許可および前記メッセージ制御ヘッダを前記第１デバイスの寄託センタに提示するステップと、前記第１デバイスの寄託センタに寄託される、前記第１デバイスの前記対応する暗号化キーペアの秘密キーを取得するステップと、前記第１デバイスの前記秘密キーを前記暗号化された通信の復号化に使用するステップとをさらに具備する（１５１）に記載の方法。
【０２３０】
（１５３）前記提示するステップが、前記メッセージ制御ヘッダから、前記第１デバイスの寄託センタの識別および前記第１デバイスの寄託認証の前記ディジタル識別コードを抽出するステップと、前記盗聴装置設置許可および前記第１デバイスの寄託認証の前記ディジタル識別コードを、前記第１デバイスから前記第１デバイスの寄託センタに提示するステップとをさらに具備する（１５２）に記載の方法。
【０２３１】
（１５４）前記第１デバイスが、前記暗号通信および前記メッセージ制御ヘッダの作成の日付および時刻を示すタイムスタンプを作成するために信用されたタイムクロックを備え、メッセージ制御ヘッダを入れる前記ステップが、前記第１デバイスによる前記メッセージ制御ヘッダの形成の日付および実行を示すタイムスタンプを構成する暗号メッセージ制御ヘッダパケットを形成するステップと、タイムスタンプを作成するために前記タイムクロックの信頼性を認証するステップとをさらに具備する（１５３）に記載の方法。
【０２３２】
（１５５）前記信用されたタイムクロックが、前記タイムクロックの製造メーカーによってのみ設定または較正できる（１５４）に記載の方法。
（１５６）前記第１デバイスの前記秘密キーを前記通信の復号化に使用する前記ステップが、前記外部エンティティにより実行される（１５１）に記載の方法。
【０２３３】
（１５７）前記第１デバイスの前記秘密キーを前記通信の復号化に使用する前記ステップが、前記寄託センタにより実行される（１５２）に記載の方法。
（１５８）前記盗聴装置設置許可が、少なくとも１つの事前に定義される制限を条件とする（１５２）に記載の方法。
【０２３４】
（１５９）前記少なくとも１つの事前に定義される制限が、前記盗聴装置設置許可に、その以前に前記秘密キーを前記通信の復号化に使用するする前記ステップが発生してはならない開始日付および時刻を含むような時間制約を具備する（１５８）に記載の方法。
【０２３５】
（１６０）前記少なくとも１つの事前に定義される制限が、前記盗聴装置設置許可に、それ以降に前記秘密キーを前記通信の復号化に使用するする前記ステップが発生してはならない終了日付および時刻を含むようなさらなる時間制約を具備する（１５８）に記載の方法。
【０２３６】
（１６１）前記少なくとも１つの事前に定義される制限が、前記盗聴装置設置許可に、それ以降に前記秘密キーを前記通信の復号化に使用するする前記ステップが発生してはならない終了日付および時刻を含むような時間制約を具備する（１５８）に記載の方法。
【０２３７】
（１６２）前記第１デバイスの秘密キーを取得する前記ステップが、前記少なくとも一人の受託人から前記第１デバイスの秘密キーの前記少なくとも１つの部分を回収するステップと、前記秘密キーの前記回収された部分から前記秘密キーを再構築するステップとをさらに具備する（１５２）に記載の方法。
【０２３８】
（１６３）前記取得するステップが、前記寄託センタにより実行される（１６２）に記載の方法。
（１６４）前記取得するステップが、前記外部エンティティにより実行される（１６２）に記載の方法。
（１６５）前記分割するステップが、前記秘密キーを再構築するためには、Ｎ個の部分すべてが必要となるように、前記秘密キーをＮ個の部分に分割するステップをさらに具備し、前記秘密キーの前記少なくとも１つの部分を回収する前記ステップが、前記秘密キーのＮ個の部分のすべてが回収されるように、前記少なくとも一人の受託人のそれぞれから前記秘密キーの前記少なくとも１つの部分のそれぞれを回収するステップを具備し、前記秘密キーを再構築する前記ステップが、前記秘密キーの前記Ｎ個の回収された部分のすべてから前記秘密キーを再構築するステップを具備する（１６２）に記載の方法。
【０２３９】
（１６６）前記秘密キーのＮ個の部分すべてを回収する前記ステップが、前記少なくとも一人の受託人のそれぞれに対して、前記秘密キーを再構築する前記ステップが、前記外部エンティティにより実行されるように、前記少なくとも１つのデバイス秘密キー部分を含む前記外部エンティティへの通信を暗号化するステップをさらに具備する（１６２）に記載の方法。
【０２４０】
（１６７）前記少なくとも１つのデバイス秘密キー部分を含む前記外部エンティティへの通信を暗号化する前記ステップが、前記受託人が前記通信にディジタル署名するステップをさらに具備する（１６６）に記載の方法。
（１６８）前記秘密キーのＮ個の部分すべてを回収する前記ステップが、前記少なくとも一人の受託人のそれぞれに対して、前記秘密キーを再構築する前記ステップが、前記寄託センタにより実行されるように、前記少なくとも１つの秘密キー部分を含む前記少なくとも１つの寄託センタに対する通信を暗号化するステップをさらに具備する（１６５）に記載の方法。
【０２４１】
（１６９）前記少なくとも１つのデバイス秘密キー部分を含む前記寄託センタに対する通信を暗号化する前記ステップが、前記受託人が前記通信にディジタル署名するステップをさらに具備する（１６８）に記載の方法。
（１７０）前記分割するステップが、Ｍ＜Ｎの場合、前記秘密キーを再構築するためにＭ個の部分だけが必要とされるように、前記秘密キーをＮ個の部分に分割し、前記秘密キーの前記少なくとも１つの部分を回収する前記ステップが、前記秘密キーの少なくともＭ個の部分が回収されるように、前記少なくとも一人の受託人から前記秘密キーの前記少なくとも１つの部分を回収し、前記秘密キーを再構築する前記ステップが、前記秘密キーの前記少なくともＭ個の回収される部分から前記秘密キーを再構築する（１６２）に記載の方法。
【０２４２】
（１７１）前記秘密キーの少なくともＭ個の部分を回収する前記ステップが、前記秘密キーを再構築する前記ステップが前記外部エンティティにより実行されるように、前記少なくともひとりの受託人のそれぞれのために前記デバイス秘密キー部分を含む、前記外部エンティティに対する通信を暗号化するステップをさらに具備する（１７０）に記載の方法。
【０２４３】
（１７２）前記デバイス秘密キー部分を含む前記外部エンティティに対する通信を暗号化する前記ステップが、前記受託人が前記通信をディジタル署名するステップをさらに具備する（１７１）に記載の方法。
（１７３）前記秘密キーの少なくともＭ個の部分を回収する前記ステップが、前記秘密キーを再構築する前記ステップが前記寄託センタにより実行されるように、前記少なくともひとりの受託人のそれぞれのために、前記デバイス秘密キー部分を含む前記少なくとも１つの寄託センタに対する通信を暗号化するステップをさらに具備する（１７０）に記載の方法。
【０２４４】
（１７４）前記デバイス秘密キー部分を含む前記寄託センタに対する通信を暗号
化する前記ステップが、前記受託人が前記通信にディジタル署名するステップをさらに具備する（１７３）に記載の方法。
（１７５）前記メッセージ制御ヘッダを入れるステップが、前記第２デバイスの寄託センタの識別および前記第２デバイスの寄託認証の前記ディジタル識別コードを構成する暗号メッセージ制御ヘッダパケットを形成するステップを具備する（１３５）に記載の方法。
【０２４５】
（１７６）前記メッセージ制御ヘッダを入れるステップが、前記第２デバイスの所有者あるいは前記第２デバイスの雇用者または監督者の識別を構成する暗号メッセージ制御ヘッダパケットを形成するステップをさらに具備する（１７５）に記載の方法。
（１７７）盗聴装置設置許可を持つ前記外部エンティティによる前記暗号通信をモニタするステップをさらに具備する（１７５）に記載の方法。
【０２４６】
（１７８）前記モニタするステップが、 前記外部エンティティによる前記暗号化された通信に割り込むステップと、前記盗聴装置許可および前記メッセージ制御ヘッダを前記第２デバイスの寄託センタに提示するステップと、前記第２デバイスの前記対応する暗号化キーペアの、前記第２デバイスの寄託センタに寄託されている秘密キーを取得するステップと、前記第２デバイスの前記秘密キーを前記暗号化された通信の復号化に使用するステップとをさらに具備する（１７７）に記載の方法。
【０２４７】
（１７９）前記提示するステップが、前記メッセージ制御ヘッダから、前記第２デバイスの寄託センタの前記識別および前記第２デバイスの寄託認証の前記ディジタルコード識別を抽出するステップと、前記盗聴装置設置許可および前記第２デバイスの寄託認証の前記ディジタルコード識別を前記第２デバイスの寄託センタに提示するステップとをさらに具備する（１７８）に記載の方法。
【０２４８】
（１８０）前記第１デバイスが、前記暗号通信および前記メッセージ制御ヘッダの作成の日付および時刻を示すタイムスタンプを作成するために信用されたタイムクロックを備え、前記メッセージ制御ヘッダを入れるステップが、前記第１デバイスによる前記メッセージ制御ヘッダの作成の日付および時刻を示すタイムスタンプを構成する暗号メッセージ制御ヘッダパケットを形成するステップと、タイムスタンプを作成する目的で前記タイムクロックの信頼性を認証するステップとを具備する（１７９）に記載の方法。
【０２４９】
（１８１）前記タイムスタンプの信頼性を認証する前記ステップが、前記タイムスタンプを作成する目的で前記タイムクロックの信頼性を公証する上位権威による認証を発行することを具備する（１８０）に記載の方法。
（１８２）前記タイムスタンプを認証する前記ステップが、作成された前記タイムスタンプのそれぞれに前記タイムクロック認証を添付する（１８１）に記載の方法。
【０２５０】
（１８３）前記上位権威が全システム権威を構成する（１８１）に記載の方法。
１８４）前記上位権威が前記デバイスの製造メーカーを構成する（１８１）に記載の方法。
（１８５）前記上位権威が寄託センタを構成する（１８１）に記載の方法。
（１８６）前記信用されるタイムクロックが、前記タイムクロックの製造メーカーによってだけ設定または較正できる（１８０）に記載の方法。
【０２５１】
（１８７）前記信用されるタイムクロックが、製造メーカーによって指定されるエンティティによってだけ再設定または再較正できる（１８０）に記載の方法。
（１８８）前記第２デバイスの前記秘密キーを前記通信の復号化に使用する前記ステップが、前記外部エンティティにより実行される（１７８）に記載の方法。
【０２５２】
（１８９）前記第２デバイスの前記秘密キーを前記通信の復号化に使用する前記ステップが、前記寄託センタにより実行される（１７８）に記載の方法。
（１９０）前記盗聴装置設置許可が、少なくとも１つの事前に定義される制約を条件とする（１７８）に記載の方法。
【０２５３】
（１９１）前記少なくとも１つの事前に定義される制約が、前記盗聴装置設置許可に、その以前に前記第２デバイスの前記秘密キーを取得する前記ステップが発生しない開始日付および時刻が含まれるような時間制約を具備する（１９０）に記載の方法。
（１９２）前記少なくとも１つの事前に定義される制約が、前記盗聴装置設置許可に、それ以降に前記第２デバイスの前記秘密キーを取得する前記ステップが発生しない終了日付および時刻が含まれるようなさらなる時間制約を具備する（１９０）に記載の方法。
【０２５４】
（１９３）前記少なくとも１つの事前に定義される制約が、前記盗聴装置設置許可に、その以降に前記第２デバイスの前記秘密キーを取得する前記ステップが発生しない終了日付および時刻が含まれるような時間制約を具備する（１９０）に記載の方法。
（１９４）前記第２デバイスの秘密キーを取得する前記ステップが、 前記少なくとも一人の受託人のそれぞれから前記第２デバイスの秘密キーの前記少なくとも１つの部分を回収するステップと、 前記秘密キーの前記回収された部分から前記秘密キーを再構築するステップとをさらに具備する（１７８）に記載の方法。
【０２５５】
（１９５）前記取得するステップが、前記寄託センタにより実行される（１９４）に記載の方法。
（１９６）前記取得するステップが、前記外部エンティティにより実行される（１９４）に記載の方法。
（１９７）前記分割するステップが、前記秘密キーを再構築するために、Ｎ個の部分すべてが必要となるように、前記秘密キーをＮ個の部分に分割し、前記秘密キーの前記少なくとも１つの部分を回収する前記ステップが、前記秘密キーのＮ個の部分のすべてが回収されるように、前記少なくとも一人の受託人のそれぞれから前記秘密キーの前記少なくとも１つの部分のそれぞれを回収し、前記秘密キーを再構築する前記ステップが、前記秘密キーの前記Ｎ個の回収された部分すべてから前記秘密キーを再構築する（１９４）に記載の方法。
【０２５６】
（１９８）前記秘密キーのＮ個すべての部分を回収する前記ステップが、前記少なくとも一人の受託人のそれぞれのために、前記秘密キーを再構築する前記ステップが前記外部エンティティにより実行されるように、前記少なくとも１つのデバイス秘密キー部分を含む前記外部エンティティに対する通信を暗号化するステップをさらに具備する（１９７）に記載の方法。
【０２５７】
（１９９）前記少なくとも１つのデバイス秘密キー部分を含む前記外部エンティティに対する通信を暗号化する前記ステップが、前記受託人が前記通信にディジタル署名するステップをさらに具備する（１９８）に記載の方法。
（２００）前記秘密キーのＮ個の部分すべてを回収する前記ステップが、前記秘密キーを再構築する前記ステップが前記寄託センタにより実行されるように、前記すくなくとも一人の受託人のそれぞれのために、前記少なくとも１つのデバイス秘密キー許容部を含む前記少なくとも１つの寄託センタに対する通信を暗号化するステップをさらに具備する（１９７）に記載の方法。
【０２５８】
（２０１）前記少なくとも１つのデバイス秘密キー部分を含む前記寄託センタに対する通信を暗号化する前記ステップが、前記受託人が通信にディジタル署名するステップをさらに具備する（２００）に記載の方法。
（２０２）前記分割する方法が、Ｍ＜Ｎの場合、前記秘密キーを再構築するためにＭ個の部分だけが必要となるように、前記秘密キーをＮ庫の部分に分割し、前記秘密キーの前記少なくとも１つの部分を回収する前記ステップが、前記秘密キーの少なくともＭ個の部分が回収されるように、前記少なくとも一人の受託人から前記秘密キーの前記少なくとも１つの部分を回収し、前記秘密キーを再構築する前記ステップが、前記秘密キーの前記少なくともＭ個の回収された部分から前記秘密キーを再構築する（１９４）に記載の方法。
【０２５９】
（２０３）前記秘密キーの少なくともＭ個の部分を受け取る前記ステップが、前記秘密キーを再構築する前記ステップが前記外部エンティティにより実行されるように、前記少なくとも一人の受託人のために、前記デバイス秘密キー部分を含む前記外部エンティティに対する通信を暗号化するステップをさらに具備する（２０２）に記載の方法。
【０２６０】
（２０４）前記デバイス秘密キーを含む前記外部エンティティに対する通信を暗号化する前記ステップが、前記受託人が前記通信にディジタル署名するステップをさらに具備する（２０３）に記載の方法。
（２０５）前記秘密キーの少なくともＭ個の部分を受け取る前記ステップが、前記秘密キーを再構築する前記ステップが前記寄託センタにより実行されるように、前記少なくとも一人の受託人のそれぞれのために、前記デバイス秘密キー部分を含む前記少なく後も１つの寄託センタに対する通信を暗号化するステップをさらに具備する（２０２）に記載の方法。
【０２６１】
（２０６）前記デバイス秘密キー部分を含む前記寄託センタに対する前記暗号化するステップが、前記受託人が前記通信にディジタル署名するステップをさらに具備する（２０５）に記載の方法。
（２０７）前記通信を暗号化するステップが、 前記第１デバイスと前記第２デバイスの間の暗号通信の暗号化および復号化両方で使用するための一意の暗号化キーを作成するステップと、前記第１デバイスによる前記暗号化キーを用いて前記第２デバイスに対する前記通信を暗号化するステップとをさらに具備する（９４）に記載の方法。
【０２６２】
（２０８）前記一意の暗号化キーを作成する前記ステップが、前記第２デバイスの前記秘密キーおよび少なくとも１つの公開キーを使用して、前記第２デバイスによる前記第２デバイスの中間番号を計算するステップと、前記第１ユーザにより前記第２ユーザの中間番号を取得するステップと、前記第１デバイスによる前記第１デバイスの前記秘密キーおよび前記第２デバイスの前記中間番号を使用して前記暗号化キーを計算するステップとをさらに具備し、前記暗号化キーを使用して暗号化された前記第１デバイスから前記第２デバイスへの前記通信が、前記暗号化キーを使用するだけで復号化できるようにする（２０７）に記載の方法。
【０２６３】
（２０９）前記第２デバイスの前記秘密キーが前記第２デバイスにより無作為に作成される（２０８）に記載の方法。
（２１０）前記第２デバイスの前記中間番号が前記第２デバイスの前記公開キーを構成する（２０８）に記載の方法。
（２１１）前記第２デバイスの前記中間番号および前記少なくとも１つの公開番号が、前記第２デバイスの前記公開キーを具備する（２０８）に記載の方法。
【０２６４】
（２１２）前記第１デバイスによる前記第１デバイスの前記秘密キーおよび前記少なくとも１つの公開キーを使用して、前記第１デバイスの中間番号を計算するステップをさらに具備する（２０８）に記載の方法。
（２１３）前記第１デバイスの前記秘密キーが、前記第１デバイスにより無作為に作成される（２１２）に記載の方法。
【０２６５】
（２１４）前記メッセージ制御ヘッダを入れるステップが、前記第１デバイスの前記中間番号および前記少なくとも１つの公開番号を構成するメッセージ制御ヘッダパケットを形成するステップをさらに具備する（２１２）に記載の方法。
（２１５）前記第２デバイスにより前記暗号化された通信を復号化する前記ステップが、前記第２デバイスによる前記第２デバイスの前記秘密キーおよび前記第１デバイスの前記中間番号を使用して、前記暗号化キーを計算するステップと、前記第２デバイスによる前記暗号化キーを使用して前記第１デバイスからの前記通信を復号化するステップとを具備する（２１４）に記載の方法。２１６）前記一意の暗号化キーを作成するステップが、前記第１デバイスおよび第２デバイスのそれぞれにより対話で前記暗号化キーを作成するステップを具備する（２０７）に記載の方法。
【０２６６】
（２１７）前記第１デバイスおよび第２デバイスのそれぞれにより対話で前記暗号化キーを作成する前記ステップが、前記第１デバイスの前記秘密キーおよび少なくとも１つの公開番号を使用して、前記第１デバイスによる第１中間番号を計算するステップと、
前記第２デバイスによる前記第２デバイスの前記秘密キーおよび前記少なくとも１つの公開番号を使用して、前記中間番号を計算するステップと、前記第１デバイスによる前記第１デバイスの前記秘密キーおよび前記第２中間番号を使用して、前記暗号化キーを計算するステップと、前記第２デバイスによる前記第２デバイスの前記秘密キーおよび前記第１中間番号を使用して、前記暗号化キーを計算するステップとを具備し、前記暗号化キーを使用して暗号化された前記第１デバイスから前記第２デバイスまたは前記第２デバイスから前記第１デバイスへの前記通信が、前記暗号化キーだけを用いて復号化できるようにする（２１６）に記載の方法。
【０２６７】
（２１８）前記第１デバイスの前記秘密キーが前記第１デバイスにより無作為に作成される（２１７）に記載の方法。
（２１９）前記第２デバイスの前記秘密キーが前記第２デバイスにより無作為に作成される（２１７）に記載の方法。
（２２０）前記第２デバイスにより前記暗号化された通信を復号化する前記ステップが、さらに、前記暗号化キーを使用して、前記第１デバイスからの前記通信の前記第２デバイスによる復号化のステップを具備する（２１７）に記載の方法。
【０２６８】
（２２１）第１の対応するキーのペアの公開キーが、前記デバイスへの暗号通信の暗号化に使用され、前記第１の対応するキーのペアの対応する秘密キーが前記暗号通信の復号化に使用され、第２の対応するキーのペアの秘密キーがディジタルデータにディジタル署名するために使用され、前記第２の対応するキーのペアの対応する秘密キーが前記ディジタル署名の確認に使用される、それぞれの信用されるデバイスが無作為に作成された非対称暗号化キーの少なくとも２つの対応するペアを持つ、複数の信用されるデバイスを備える暗号システムにおける、外部エンティティが前記通信をモニタできるようにしつつ、複数のユーザデバイスの間の認証できる信用された暗号通信を作成するための方法であって、
前記信用されたデバイスのそれぞれの少なくとも１つの秘密復号化キーを、少なくとも１つの寄託センタに寄託するステップと、前記少なくとも１つの寄託センタにより前記デバイスのそれぞれの前記少なくとも１つの秘密復号化キーの寄託を認証するステップと、前記デバイスのそれぞれの少なくとも１つの秘密署名キーを認証するステップと、前記第２デバイスの公開暗号化キーを使用して、前記ユーザデバイスの第２に対する前記ユーザデバイスの第１からの通信を暗号化するステップと、前記少なくとも１つの信用された寄託センタを識別するのに十分な情報を含むメッセージ制御ヘッダを、前記暗号化された通信で入れるステップと、前記第２デバイスの秘密復号化キーを使用して、前記第２デバイスによる前記暗号化された通信を復号化するステップとを具備し、前記第２デバイスによる前記暗号化された通信を復号化する前記ステップが、前記第１デバイスおよび第２デバイスのそれぞれの前記秘密復号化キーの認証および有効なメッセージ制御ヘッダの前記通信内での存在を条件とする方法。
【０２６９】
（２２２）前記第１デバイスからの通信を暗号化する前記ステップが、前記第１デバイスおよび第２デバイスのそれぞれの前記秘密復号化キーの認証および有効なメッセージ制御ヘッダの前記通信内での存在を条件とする（２２１）に記載の方法。
（２２３）前記通信が、記憶のために前記第１デバイスからそれ自体に暗号化されるように、前記第１デバイスおよび前記第２デバイスが同一である（２２１）に記載の方法。
【０２７０】
（２２４）前記それぞれの信用されたデバイスが、前記少なくとも２つの対応する暗号化キーのペアを暗号化および復号化のために、ならびに署名および確認のために無作為に作成する能力と、安全な不正な動きを防止する、読み取ることができないやり方で前記キーのペアのそれぞれを記憶する能力を備える（２２１）に記載の方法。
【０２７１】
（２２５）それぞれの前記信用されたデバイスに製造メーカーがあり、少なくとも１つの秘密署名キーを認証する前記ステップが、さらに、上位権威による前記デバイスの前記キーを無作為に作成し記憶する能力を認証するステップを具備する（２２４）に記載の方法。
【０２７２】
（２２６）前記デバイスの能力を認証する前記ステップが、さらに、前記製造メーカーの信頼性および前記製造メーカーにより製造されるデバイスの前記キーを読み取ることができない不正な動きを防止するやり方で無作為に作成、記憶する能力を公証する、前記上位権威による製造メーカー認証を発行するステップを具備する（２２５）に記載の方法。
【０２７３】
（２２７）前記上位権威が全システム権威を構成する（２２６）に記載の方法。
（２２８）前記製造メーカー認証が、前記製造メーカーにより作成された秘密署名キーを使用して発行された各署名に添付される（２２６）に記載の方法。
（２２９）上位権威による前記少なくとも１つの寄託センタの信頼性を認証するステップをさらに具備する（２２１）に記載の方法。
【０２７４】
（２３０）前記寄託センタを認証するステップが、寄託する目的で前記寄託センタの信頼性を公証する、前記少なくとも１つの寄託センタのそれぞれに対する前記上位権威による認証を発行するステップを具備する（２２９）に記載の方法。
（２３１）前記上位権威が全システム権威を構成する（２３０）に記載の方法。
【０２７５】
２３２）前記上位権威がデバイスの少なくとも１つの製造メーカーを構成する（２３０）に記載の方法。
（２３３）前記寄託するステップが、各ユーザデバイスのために、 前記秘密復号化キーを部分に分割するステップと、少なくとも一人の受託人のそれぞれに、前記秘密キーの少なくとも１つの部分を提供するステップと、前記少なくとも一人の受託人のそれぞれに、前記受託人が前記秘密キーの前記少なくとも１つの部分の正しい受領を確認できるようにする確認情報を提供するステップと、前記少なくとも１つの寄託センタによる、前記秘密キーの前記少なくとも１つの部分の前記少なくとも一人の受託人のそれぞれによる正しい受領を確認するステップとをさらに具備する（２２１）に記載の方法。
【０２７６】
（２３４）前記少なくとも１つの寄託センタのそれぞれが、信用されるデバイスを構成し、暗号化する前記ステップが、前記分割するステップが前記寄託センタにより実行される容易、前記ユーザ秘密復号化キーを含む前記少なくとも１つの寄託センタに対する通信を暗号化するステップをさらに具備する（２３３）に記載の方法。
【０２７７】
（２３５）前記分割するステップが、前記秘密キーを再構築するためにＮ個の部分のすべてが必要とされるように、前記秘密キーをＮ個の部分に分割する（２３４）に記載の方法。
（２３６）前記分割するステップが、Ｍ＜Ｎの場合、前記秘密キーを再構築するためにＭ個の部分だけが必要とされるように、前記秘密キーをＮ個の部分に分割する（２３４）に記載の方法。
【０２７８】
（２３７）唯一の寄託センタの公開暗号化キーが、前記寄託センタが寄託を行う目的で前記製造メーカーにより選択されるように、前記デバイスの製造メーカーにより前記ユーザデバイスの中に事前に埋め込まれており、前記寄託するステップが、前記事前に埋め込まれた寄託センタ暗号化キーを使用して、前記寄託センタに対する通信を暗号化するステップをさらに具備する（２３４）に記載の方法。
【０２７９】
（２３８）少なくとも１つの寄託センタの公開暗号化キーが、少なくとも１つの寄託センタのグループが、寄託を行う目的で前記製造メーカーにより選択されるように、前記デバイスの製造メーカーにより前記ユーザデバイスの中に事前に埋め込まれ、寄託する前記ステップが、前記事前に埋め込まれた寄託センタ公開暗号化キーの１つを使用して、少なくとも１つの寄託センタの前記グループの１つに対する前記秘密キーの少なくとも１つの部分を含む通信を暗号化するステップをさらに具備する（２３４）に記載の方法。
【０２８０】
（２３９）前記少なくとも１つの寄託センタの前記暗号化キーが、寄託認証ディレクトリから前記ユーザデバイスにより取得される（２３４）に記載の方法。
（２４０）前記ユーザデバイス秘密暗号化キーを含む前記少なくとも１つの寄託センタに対する通信を暗号化する前記ステップが、前記秘密デバイス署名キーを使用して、前記デバイスが前記通信にディジタル署名するステップをさらに具備する（２３４）に記載の方法。
【０２８１】
（２４１）前記少なくとも一人の受託人のそれぞれに前記秘密キーの少なくとも１つの部分を提供する前記ステップが、前記寄託センタが、前記少なくとも１つの受託人のそれぞれに対する前記秘密キーの前記少なくともつの部分を含む通信を暗号化するステップをさらに具備する（２３４）に記載の方法。
【０２８２】
（２４２）前記デバイス秘密キーの前記少なくとも１つの部分を含む前記少なくとも一人の受託人のそれぞれに対する通信を暗号化する前記ステップが、前記寄託センタが前記通信にディジタル署名するステップをさらに具備する（２４１）に記載の方法。
（２４３）前記少なくとも一人の受託人のそれぞれに確認情報を提供するステップが、前記秘密キーの前記少なくとも１つの部分を含む前記少なくとも一人の受託人のそれぞれに対する前記通信に前記確認情報を入れる（２４１）に記載の方法
（２４４）前記少なくとも一人の受託人のそれぞれに対する通信を暗号化する前記ステップが、前記寄託センタが前記通信にディジタル署名するステップをさらに具備する（２４３）に記載の方法。
【０２８３】
（２４５）少なくとも一人の受託人のそれぞれが信用されたデバイスを構成し、前記分割するステップが、前記デバイスにより実行される（２３３）に記載の方法。
（２４６）前記秘密キーを再構築するためにＮ個の部分のすべてが必要となるように、前記秘密キーをＮ個の部分に分割することを具備する（２４５）に記載の方法。
【０２８４】
（２４７）前記分割するステップが、Ｍ＜Ｎの場合に、前記秘密キーを再構築するためにＭ個の部分だけが必要とされるように、前記秘密キーをＮ個の部分に分割する（２４５）に記載の方法。
（２４８）前記少なくとも一人の受託人の公開暗号化キーが、少なくとも一人の受託人のグループが、寄託を行う目的で前記製造メーカーにより選択されるように、前記デバイスの製造メーカーによる前記ユーザデバイスの中に事前に埋め込まれ、少なくとも一人の受託人のそれぞれに、前記秘密キーの少なくとも１つの部分を提供する前記ステップが、さらに、前記事前に埋め込まれた受託人の公開暗号化キーを使用して、少なくとも一人の受託人の前記グループの間から、少なくとも一人の受託人のそれぞれに対する前記秘密キーの少なくとも１つの部分を含む通信を前記デバイスが暗号化するステップを具備する（２４５）に記載の方法。
【０２８５】
（２４９）前記少なくとも一人の受託人のそれぞれに対する通信を暗号化する前記ステップが、さらに、前記ユーザデバイスが前記通信にディジタル署名するステップを具備する（２４８）に記載の方法。
（２５０）前記少なくとも一人の受託人のそれぞれに前記秘密キーの少なくとも１つの部分を提供する前記ステップが、前記秘密キーの部分を前記ユーザデバイスから受け取った前記少なくとも一人の受託人のそれぞれの識別を構成する、前記確認ステップの中で後で使用するための、前記寄託センタに対する通信を前記ユーザデバイスが暗号化するステップを具備する（２４８）に記載の方法。
【０２８６】
（２５１）前記少なくとも一人の受託人のそれぞれに確認情報を提供する前記ステップが、前記秘密キーの前記少なくとも１つの部分を含む前記少なくとも一人の受託人のそれぞれに対する前記通信の中に、前記ユーザデバイスが前記確認情報を入れることを具備する（２４８）に記載の方法。
【０２８７】
（２５２）前記少なくとも一人の受託人のそれぞれに対する通信を暗号化する前記ステップが、前記ユーザデバイスが前記通信にディジタル署名するステップをさらに具備する（２５１）に記載の方法。
（２５３）前記少なくとも１つの寄託センタによる前記確認するステップが、各受託人のために、前記ユーザデバイスの前記秘密キーの前記少なくとも１つの部分の受領を前記寄託センタに対して前記受託人により通知するステップと、前記受託人による前記確認情報を前記寄託センタに対して通信するステップと、前記確認情報の前記受託人による正しい通信に基づき、前記秘密キーの前記少なくとも１つの部分の前記受託人による正しい受領を前記寄託センタにより確証するステップとを具備する（２３３）に記載の方法。
【０２８８】
（２５４）前記受託人による前記確認情報を通信する前記ステップが、前記受託人が前記確認情報を含む前記寄託センタに対する通信を暗号化するステップを具備する（２５３）に記載の方法。
（２５５）前記確認情報を含む前記寄託センタに対する通信を暗号化する前記ステップが、前記受託人が前記通信をディジタル署名するステップをさらに具備する（２５４）に記載の方法。
【０２８９】
（２５６）前記少なくとも１つの秘密復号化キーの寄託を認証する前記ステップが、前記公開キーおよび前記秘密キーならびに前記対応するデバイスの間のつながりを公証し、前記対応するキーペアの前記秘密復号化キーが寄託されていることを保証する、各前記ユーザデバイスの対応するキーペアごとに１つの寄託センタによる寄託認証を発行するステップをさらに具備する（２３３）に記載の方法。
【０２９０】
（２５７）前記秘密復号化キーの寄託を認証する前記ステップが、前記寄託認証を発行する前記ステップの前に、前記秘密復号化キーの寄託を確証するステップをさらに具備する（２５６）に記載の方法。
（２５８）前記秘密復号化キーの寄託を確証する前記ステップが、各受託人のために、
前記デバイスの秘密復号化キーの前記少なくとも１つの部分の前記歌句人による受領を前記寄託センタに通知するステップと、前記受託人による前記確認情報を前記寄託センタに通信するステップと、前記確認情報の前記受託人による正しい通信に基づいて、前記デバイスの秘密復号化キーの前記少なくとも１つの部分の前記受託人による正しい受領を前記寄託センタにより確認するステップとを具備する（２５７）に記載の方法。
【０２９１】
（２５９）前記寄託センタが信用されたデバイスを構成し、前記確認情報を前記受託人により前記寄託センタに通信するステップが、前記確認情報を含む前記寄託センタに対する通信を暗号化するステップを具備する（２５８）に記載の方法。
（２６０）前記受託人が信用されたデバイスを構成し、前記寄託センタに対する通信を暗号化するステップが、前記受託人が秘密署名キーを使用して前記通信にディジタル署名するステップをさらに具備する（２５９）に記載の方法。
【０２９２】
（２６１）前記確認するステップが、前記確認情報を含む前記通信上の受託人の署名を確認することをさらに具備する（２６０）に記載の方法。
（２６２）前記寄託認証が前記認証発行寄託センタの識別、前記寄託認証のディジタル識別コード、および前記寄託された秘密復号化キーに対応する前記公開暗号化キーを構成する（２５６）に記載の方法。
【０２９３】
（２６３）前記暗号化された通信でメッセージ制御ヘッダを入れる前記ステップが、前記第１ユーザデバイスの寄託センタの識別および前記第１ユーザデバイスの寄託認証の前記ディジタル識別コードを構成する暗号メッセージ制御ヘッダパケットを形成するステップを具備する（２６２）に記載の方法。
【０２９４】
（２６４）前記メッセージ制御ヘッダを入れるステップが、前記第２ユーザデバイスの寄託センタの識別および前記第２ユーザデバイスの寄託認証の前記ディジタルコード識別を構成する暗号メッセージ制御ヘッダを形成するステップをさらに具備する（２６３）に記載の方法。
【０２９５】
（２６５）前記第１デバイスの寄託センタおよび前記第２ユーザデバイスの寄託センタが同一であり、メッセージ制御ヘッダを入れる前記ステップが、さらに、前記第１デバイスおよび第２デバイスの寄託センタの識別および前記寄託認証のそれぞれの前記ディジタルコード識別を形成するステップを具備する（２６４）に記載の方法。
【０２９６】
（２６６）前記メッセージ制御ヘッダを入れるステップが、前記第１ユーザデバイスの所有者の識別または前記１ユーザデバイスのユーザの雇用者または監督者の識別を構成する暗号メッセージ制御ヘッダパケットを形成するステップをさらに具備する（２６３）に記載の方法。
【０２９７】
（２６７）前記メッセージ制御ヘッダを入れるステップが、前記第２ユーザデバイスの所有者の識別または前記第２ユーザデバイスのユーザの雇用者または監督者の識別を構成する暗号メッセージ制御ヘッダパケットを形成するステップをさらに具備する（２６６）に記載の方法。
【０２９８】
（２６８）前記第１および第２ユーザデバイスの前記所有者または前記第１および第２ユーザデバイスの前記ユーザの前記雇用者または監督者が同一であり、前記メッセージ制御ヘッダを入れるステップが、前記所有者、雇用者または監督者の識別および前記寄託認証のそれぞれの前記ディジタルコード識別を構成する暗号メッセージ制御ヘッダパケットを形成するステップをさらに具備する（２６７）に記載の方法。
【０２９９】
（２６９）前記メッセージ制御ヘッダを入れるステップが、前記第１ユーザデバイスによる前記メッセージ制御ヘッダの作成の日付および時刻を示すタイムスタンプを構成する暗号メッセージ制御ヘッダパケットを形成するステップを具備する（２６３）に記載の方法。
【０３００】
（２７０）前記各信用されたデバイスが、前記暗号通信および前記メッセージ制御ヘッダの日付および時刻を示すタイムスタンプを作成するためにタイムクロックを具備し、前記メッセージ制御ヘッダを入れるステップが、前記タイムスタンプの信頼性を認証するステップをさらに具備する（２６９）に記載の方法。
【０３０１】
（２７１）前記タイムスタンプの信頼性を認証するステップが、前記タイムスタンプを作成する目的で前記タイムクロックの信頼性を公証する上位権威による認証を発行する（２７０）に記載の方法。
（２７２）前記タイムスタンプを認証するステップが、作成された前記タイムスタンプのそれぞれに前記タイムクロック認証を添付する（２７１）に記載の方法。
【０３０２】
（２７３）前記上位権威タイムクロックが全システム権威を具備する（２７１）に記載の方法。
（２７４）前記上位権威タイムクロックが前記デバイスの製造メーカーを具備する（２７１）に記載の方法。
（２７５）前記信用されたタイムクロックが前記タイムクロックの製造メーカーによってのみ設定または較正できる（２７０）に記載の方法。
【０３０３】
（２７６）盗聴装置設置許可を持つ前記外部エンティティにより前記暗号通信をモニタするステップをさらに具備する（２６３）に記載の方法。
（２７７）前記モニタするステップが、前記外部エンティティによる前記暗号化された通信に割り込むステップと、前記第１ユーザデバイスの寄託センタに対して、前記盗聴装置設置許可および前記メッセージ制御ヘッダを提示するステップと、前記第１ユーザデバイスの寄託センタに寄託されている前記第１ユーザデバイスの秘密復号化キーを取得するステップと、前記第１ユーザデバイスの前記秘密復号化キーを前記暗号化された通信の復号化に使用するステップとをさらに具備する（２７６）に記載の方法。
【０３０４】
（２７８）前記提示するステップが、前記メッセージ制御ヘッダから、前記第１ユーザデバイスの寄託センタの前記識別および前記第１ユーザデバイスの寄託認証の前記ディジタル識別コードを抽出するステップと、前記盗聴装置設置許可および前記第１ユーザデバイスの寄託認証の前記ディジタル識別コードを、前記ユーザデバイスの寄託センタに提示するステップとをさらに具備する（２７７）に記載の方法。
【０３０５】
（２７９）前記第１ユーザデバイスが、前記暗号通信および前記メッセージ制御ヘッダの形成の日付および時刻を示すタイムスタンプを形成作成するために信用されたタイムクロックを備え、前記メッセージ制御ヘッダを入れるステップが、タイムスタンプを構成する暗号メッセージ制御ヘッダパケットを形成するステップとタイムスタンプを作成する目的で前記タイムクロックの信頼性を認証するステップとをさらに具備する（２７８）に記載の方法。
【０３０６】
（２８０）前記タイムスタンプの信頼性を認証する前記ステップが、前記タイムスタンプを作成する目的で、前記タイムクロックの信頼性を公証する、上位権威による認証を発行する（２７９）に記載の方法。
（２８１）前記タイムスタンプを認証する前記ステップが、作成された前記タイムスタンプのそれぞれに前記タイムクロックを添付する（２８０）に記載の方法。
【０３０７】
（２８２）前記上位権威タイムクロックが全システム権威を具備する（２８０）に記載の方法。
（２８３）前記信用されたタイムクロックが、製造タイムクロックの製造メーカーによってのみ設定または較正できる（２７９）に記載の方法。
（２８４）前記第１ユーザデバイスの前記秘密復号化キーを前記第１ユーザデバイスの復号化に使用する前記ステップが、前記外部エンティティにより実行される（２７７）に記載の方法。
【０３０８】
（２８５）前記第１ユーザデバイスの前記秘密復号化キーを前記通信の復号化に使用する前記ステップが、前記寄託センタにより実行される（２７７）に記載の方法。
（２８６）前記盗聴装置設置許可が、少なくとも１つの事前定義された制限を条件とする（２７７）に記載の方法。
【０３０９】
（２８７）前記少なくとも１つの事前に定義される制約が、前記盗聴装置設置許可に、それ以前は前記第１デバイスの前記秘密キーを取得する前記ステップが発生してはならない開始日付および時刻を含むような時間制約を具備する（２８６）に記載の方法。
【０３１０】
（２８８）前記少なくとも１つの事前に定義される制約が、前記盗聴装置設置許可に、それ以降は前記第１デバイスの前記秘密キーを取得する前記ステップが発生してはならない終了日付および時刻を含むようなさらなる時間制約を具備する（２８７）に記載の方法。
【０３１１】
（２８９）前記少なくとも１つの事前に定義される制約が、前記盗聴装置設置許可に、それ以降は前記第１デバイスの前記秘密キーを取得する前記ステップが発生してはならない終了日付および時刻を含むような時間制約を具備する（２８６）に記載の方法。
【０３１２】
（２９０）前記第１デバイスの秘密キーを取得する前記ステップが、前記第１ユーザデバイスの秘密キーの前記少なくとも１つの部分を前記少なくとも一人の受託人から回収するステップと、前記秘密キーの前記回収された部分から前記秘密キーを再構築するステップとを具備する（２７７）に記載の方法。
【０３１３】
（２９１）前記取得するステップが、前記寄託センタにより実行される（２９０）に記載の方法。
（２９２）前記取得するステップが、前記外部エンティティにより実行される（２９０）に記載の方法。
（２９３）前記分割するステップが、前記秘密キーを再構築するためにＮ個の部分のすべてが必要とされるように、前記秘密キーをＮ個の部分に分割し、前記秘密キーの前記少なくとも１つの部分を回収する前記ステップが、前記秘密キーのＮ個の部分のすべてが必要とされるように、前記秘密キーの前記少なくとも一人の受託人から前記少なくとも１つの部分のそれぞれを回収し、前記秘密キーを再構築する前記ステップが、前記秘密キーの前記Ｎ個の回収された部分のすべてから前記秘密キーを再構築する（２９０）に記載の方法。
【０３１４】
（２９４）前記秘密キーのＮ個の部分すべてを回収する前記ステップが、前記秘密キーを再構築する前記ステップが、前記外部エンティティにより実行されるように、前記少なくとも一人の受託人のそれぞれに対して、前記少なくとも１つのデバイス秘密キー部分を含む前記外部エンティティに対する通信を暗号化するステップをさらに具備する（２９３）に記載の方法。
【０３１５】
（２９５）前記少なくとも１つのデバイス秘密キー部分を含む前記外部エンティティに対する通信を暗号化する前記ステップが、前記受託人が前記通信にディジタル署名するステップをさらに具備する（２９３）に記載の方法。
（２９６）前記秘密キーのＮ個の部分すべてを回収する前記ステップが、前記秘密キーを再構築する前記ステップが、前記寄託センタにより実行されるように、前記少なくとも１つのデバイス秘密キー部分を含む前記少なくとも１つの寄託センタに対する通信を暗号化するステップをさらに具備する（２９３）に記載の方法。
【０３１６】
（２９７）前記少なくとも１つのデバイス秘密キー部分を含む前記寄託センタに対する通信を暗号化する前記ステップが、前記受託人が前記通信にディジタル署名するステップをさらに具備する（２９６）に記載の方法。
（２９８）分割する前記ステップが、Ｍ＜Ｎの場合、前記秘密キーを再構築するためにＭ個の部分だけが必要とされるように、前記秘密キーをＮ個の部分に分割し、
前記秘密キーの前記少なくとも１つの部分を回収する前記ステップが、前記秘密キーの少なくともＭ個の部分が回収されるように、前記少なくとも一人の受託人から前記秘密キーの前記少なくとも１つの部分を回収し、前記秘密キーを再構築する前記ステップが、前記秘密キーの前記少なくともＭ個の回収された部分から前記秘密キーを再構築する（２９０）に記載の方法。
【０３１７】
（２９９）前記秘密キーの少なくともＭ個の部分を回収する前記ステップが、前記秘密キーを再構築する前記ステップが前記外部エンティティにより実行されるように、前記少なくとも一人の受託人のそれぞれのために、前記デバイス秘密キー部分を含む前記外部エンティティに対する通信を暗号化するステップをさらに具備する（２９８）に記載の方法。
【０３１８】
３００）前記デバイス秘密キー部分を含む前記外部エンティティに対する通信を暗号化する前記ステップが、前記受託人が前記通信にディジタル署名するステップをさらに具備する（２９９）に記載の方法。
（３０１）前記秘密キーの少なくともＭ個の部分を回収する前記ステップが、前記秘密キーを再構築する前記ステップが前記寄託センタにより実行されるように、前記少なくとも一人の受託人のそれぞれのために、前記デバイス秘密キー部分を含む前記少なくとも１つの寄託センタに対する通信を暗号化するステップをさらに具備する（２９８）に記載の方法。
【０３１９】
（３０２）前記デバイス秘密キー部分を含む前記寄託センタに対する通信を暗号
化する前記ステップが、前記受託人が前記通信にディジタル署名するステップをさらに具備する（３０１）に記載の方法。
（３０３）前記暗号化された通信でメッセージ制御ヘッダを入れる前記ステップが、前記第２ユーザデバイスの寄託センタの識別および前記第２デバイスの寄託認証の前記ディジタル識別コードを構成する暗号メッセージ制御ヘッダパケットを形成するステップを具備する（２６２）に記載の方法。
【０３２０】
（３０４）前記メッセージ制御ヘッダを入れるステップが、前記第２ユーザデバイスの所有者の識別または前記第２ユーザデバイスのユーザの雇用者または監督者の識別を構成する暗号メッセージ制御ヘッダパケットを形成するステップをさらに具備する（３０３）に記載の方法。
【０３２１】
（３０５）盗聴装置設置許可を持つ前記外部エンティティによる前記暗号通信をモニタするステップをさらに具備する（３０３）に記載の方法。
（３０６）前記モニタするステップが、前記外部エンティティによる前記暗号化された通信に割り込むステップと、前記盗聴装置設置許可および前記メッセージ制御ヘッダを前記第２ユーザデバイスの寄託センタに提示するステップと、前記第２ユーザデバイスの寄託センタに寄託されている前記第２ユーザデバイスの秘密復号化キーを取得するステップと、前記第２ユーザデバイスの前記秘密復号化キーを前記暗号化された通信の復号化に使用するステップとをさらに具備する（３０５）に記載の方法。
【０３２２】
（３０７）前記提示するステップが、前記メッセージ制御ヘッダから、前記第２ユーザデバイスの寄託センタの前記識別および前記第２ユーザデバイスの寄託認証の前記ディジタル識別コードを抽出するステップと、前記盗聴装置設置許可および前記第２ユーザデバイスの寄託認証の前記ディジタル識別コードを前記第２デバイスの寄託センタに提示するステップとをさらに具備する（３０６）に記載の方法。
【０３２３】
（３０８）前記第１デバイスが、前記暗号通信および前記メッセージ制御ヘッダの作成の日付および時刻を示すタイムスタンプを作成するために信用されたタイムクロックを備え、前記メッセージ制御ヘッダを入れる前記ステップが、タイムスタンプを構成するメッセージ制御ヘッダパケットを形成するステップと、タイムスタンプを作成する目的で前記タイムクロックの信用性を認証するステップとをさらに具備する（３０７）に記載の方法。
【０３２４】
（３０９）前記タイムスタンプの信頼性を認証する前記ステップが、前記タイムスタンプを作成する目的で前記タイムクロックの信頼性を公証する上位権威による認証を発行する（３０９）に記載の方法。
（３１０）前記タイムスタンプを認証するステップが、作成された前記タイムスタンプのそれぞれに前記タイムクロック認証を添付する（３０９）に記載の方法。
【０３２５】
（３１１）前記上位権威タイムクロックが全システム権威を具備する（３０９）に記載の方法。
（３１２）前記上位権威タイムクロックが前記デバイスの製造メーカーを具備する（３０９）に記載の方法。
（３１３）前記信用されたタイムクロックが、前記タイムクロックの製造メーカーによってのみ設定または較正できる（３０８）に記載の方法。
【０３２６】
（３１４）前記第２ユーザデバイスの前記秘密復号化キーを前記通信の復号化に使用する前記ステップが、前記外部エンティティにより実行される（３０６）に記載の方法。
（３１５）前記第２ユーザデバイスの前記秘密復号化キーを前記通信の復号化に使用する前記ステップが、前記寄託センタにより実行される（３０６）に記載の方法。
【０３２７】
（３１６）前記盗聴装置設置許可が、少なくとも１つの事前に定義された制約を条件とする（３０６）に記載の方法。
（３１７）前記少なくとも１つの事前に定義された制約が、前記盗聴装置設置許可に、それ以前に前記第２デバイスの前記秘密キーを取得する前記ステップが発生してはならない開始日付および時刻が含まれるように時間制約を具備する（３１６）に記載の方法。
【０３２８】
（３１８）前記少なくとも１つの事前に定義された制約が、前記盗聴装置設置許可に、それ以降に前記第２デバイスの前記秘密キーを取得する前記ステップが発生してはならない終了日付および時刻が含まれるようなさらなる時間制約を具備する（３１７）に記載の方法。
【０３２９】
（３１９）前記少なくとも１つの事前に定義された制約が、前記盗聴装置設置許可に、それ以降に前記第２デバイスの前記秘密キーを取得する前記ステップが発生してはならない終了日付および時刻が含まれるような時間制約を具備する（３１７）に記載の方法。
【０３３０】
（３２０）前記第２ユーザデバイスの秘密復号化キーを取得する前記ステップが、前記少なくとも一人の受託人のそれぞれから、前記第２ユーザデバイスの秘密キーの前記少なくとも１つの部分を回収するステップと、前記秘密キーの前記回収された部分から前記秘密キーを再構築するステップとをさらに具備する（３０６）に記載の方法。
【０３３１】
（３２１）前記取得するステップが、前記寄託センタにより実行される（３２０）に記載の方法。
（３２２）前記取得するステップが、前記外部エンティティにより実行される（３２０）に記載の方法。
（３２３）前記分割するステップが、前記秘密キーを再構築するにはＮ個の部分すべてが必要とされるように前記秘密キーをＮ個の部分に分割し、前記秘密キーの前記少なくとも１つの部分を回収する前記ステップが、前記秘密キーのＮ個の部分のすべてが回収されるように、前記少なくとも一人の受託人のそれぞれから前記秘密キーの前記少なくとも１つの部分のそれぞれを回収し、前記秘密キーを再構築する前記ステップが、前記秘密キーの前記Ｎ個の回収された部分すべてから前記秘密キーを再構築する（３２０）に記載の方法。
【０３３２】
（３２４）前記秘密キーのＮ個の部分のすべてを回収する前記ステップが、前記秘密キーを再構築する前記ステップが前記外部エンティティにより実行されるように、前記少なくとも一人の受託人のそれぞれのために、前記少なくとも１つのデバイス秘密キー部分を含む前記外部エンティティに対する通信を暗号化するステップをさらに具備する（３２３）に記載の方法。
【０３３３】
（３２５）前記少なくとも１つのデバイス秘密キー部分を含む前記外部エンティティに対する通信を暗号化する前記ステップが、前記受託人が前記通信にディジタル署名するステップをさらに具備する（３２４）に記載の方法。
（３２６）前記秘密キーのＮ個の部分すべてを回収する前記ステップが、前記秘密キーを再構築する前記ステップが、前記寄託センタにより実行されるように、前記少なくとも一人の受託人のそれぞれのために、前記少なくとも１つのデバイス秘密キー部分を含む前記少なくとも１つの寄託センタに対する通信を暗号化するステップをさらに具備する（３２３）に記載の方法。
【０３３４】
（３２７）前記少なくとも１つのデバイス秘密キー部分を含む前記寄託センタに対する通信を暗号化する前記ステップが、前記受託人が前記通信にディジタル署名するステップをさらに具備する（３２６）に記載の方法。
（３２８）前記分割するステップが、Ｍ＜Ｎの場合、前記秘密キーを再構築するためにＭ個の部分だけが必要とされるように、前記秘密キーをＮ個の部分に分割し、前記秘密キーの前記少なくとも１つの部分を回収する前記ステップが、前記秘密キーの少なくともＭ個の部分が回収されるように、前記すくなくとも一人の受託人から前記秘密キーの前記少なくとも１つの部分を回収し、前記秘密キーを再構築する前記ステップが、前記秘密キーの前記少なくともＭ個の回収された部分から前記秘密キーを再構築する（３２０）に記載の方法。
【０３３５】
（３２９）前記秘密キーの少なくともＭ個の部分を回収する前記ステップが、前記秘密キーを再構築する前記ステップが前記外部エンティティにより実行されるように、前記少なくとも一人の受託者のそれぞれのために、前記デバイス秘密キー部分を含む前記外部エンティティに対する通信を暗号化するステップを具備する（３２８）に記載の方法。
【０３３６】
３３０）前記デバイス秘密キー部分を含む前記外部エンティティに対する通信を暗号化する前記ステップが、前記受託人が前記通信にディジタル署名するステップをさらに具備する（３２９）に記載の方法。
（３３１）前記秘密キーの少なくともＭ個の部分を回収する前記ステップが、前記秘密キーを再構築する前記ステップが前記寄託センタにより実行されるように、前記少なくとも一人の受託人のそれぞれのために、前記デバイス秘密キー部分を含む前記少なくとも１つの寄託センタに対する通信を暗号化するステップをさらに具備する（３２８）に記載の方法。
【０３３７】
（３３２）前記デバイス秘密キー部分を含む前記寄託センタに対する通信を暗号
化する前記ステップが、前記受託人が前記通信にディジタル署名するステップを具備する（３３１）に記載の方法。
（３３３）信用されたデバイスに第１ユーザと第２関係者の間の電子トランザクションを実行する許可を与え、前記信用されたデバイスが、ユーザにより変更することができない事前に決定された規則にしたがって前記電子トランザクションに従事する旨の保証を提供する方法であって、前記信用されたデバイスから第三者に、前記電子トランザクションに従事するための許可の要求を電子的に送信し、前記要求が前記信用されたデバイスのアイデンティティを含み、前記第三者により、前記信用されたデバイスが前記トランザクションに、少なくとも部分的には、前記信用されたデバイスが前記規則にしたがって動作するという判断に従い、従事する権限を与えられなければならないことを判断し、前記第三者から前記信用されたデバイスに前記電子トランザクションに従事する許可を電子的に送信し、前記許可が、前記第三者が前記許可を与えたという認証を含み、前記信用されたデバイスから前記第２関係者へ前記認証を、前記信用されたデバイスが前記電子トランザクションに従事する権限が与えられ、前記規則に則ってのみ従事するであろう旨の保証として電子的に送信し、前記信用されたデバイスから前記第２関係者へ、前記規則に則ってトランザクションデータを電子的に送信する方法。
【０３３８】
（３３４）前記許可伝送ステップが、前記第三者から前記信用されたデバイスへの前記規則伝送のステップを含む（３３３）に記載の方法。
（３３５）前記信用されたデバイスが、前記許可伝送ステップの前に、前記規則を備える（３３３）に記載の方法。
【０３３９】
（３３６）前記許可伝送ステップが、前記第三者のディジタル署名を前記認証に添付するステップを含む（３３３）に記載の方法。
（３３７）前記要求伝送ステップが、前記信用されたデバイスの製造メーカーによりディジタル署名される前記信用されたデバイスの前記アイデンティティの認証を伝送するステップを含む（３３３）に記載の方法。
【０３４０】
（３３８）前記判断するステップが、前記デバイスが、前記信用されたデバイスの前記アイデンティティに基づき、不正な動きを防止する者であるかどうかを判断するステップを含む（３３３）に記載の方法。
（３３９）前記信用されたデバイスが、非対称暗号システムの公開キーおよび秘密キーをそれに関連づけ、前記伝送ステップが、前記デバイス公開キーを前記第三者に伝送するステップを含む（３３３）に記載の方法。
【０３４１】
（３４０）前記アイデンティティ認証が、前記信用されたデバイスの公開−秘密キーペアの公開キーを含み、前記要求伝送ステップが、前記第三者が前記要求が前記信用されたデバイスから生じたものであることを確認できるように、前記デバイス秘密キーを用いて作成された前記信用されたデバイスのディジタル署名を前記要求に添付することを含む（３３７）に記載の方法。
【０３４２】
（３４１）前記信用されたデバイスが、非対称暗号システムの第１キーおよび第２キーをそれに結び付け、トランザクションデータを前記第２関係者へ伝送するステップが、前記第１キーを用いて作成された前記信用されたデバイスのディジタル署名を添付するステップを含む（３３３）に記載の方法。
【０３４３】
（３４２）前記トランザクションデータを前記第２関係者に伝送する前記ステップが、前記第２キーを前記第２関係者に伝送するステップを含む（３４０）に記載の方法。
（３４３）前記第１デバイスキーおよび前記第２デバイスキーが、それぞれ秘密キーおよび公開キーである（３４１）または（３４２）に記載の方法。
【図面の簡単な説明】
【０３４４】
【図１Ａ】本発明の図面で使用される記号および省略語のリストである。
【図１Ｂ】本発明の図面で使用される記号および省略語のリストである。
【図１Ｃ】本発明の図面で使用される記号および省略語のリストである。
【図１Ｄ】本発明の図面で使用される記号および省略語のリストである。
【図１Ｅ】本発明の図面で使用される記号および省略語のリストである。
【図１Ｆ】本発明の図面で使用される記号および省略語のリストである。
【図１Ｇ】本発明の図面で使用される記号および省略語のリストである。
【図２】従来の技術による対話型ディッファー・ヘルマン・キー導出法のステップを示すフローチャートである。
【図３】従来の技術による認証型ディッファー・ヘルマン法の認証部分のステップを示すフローチャートである。
【図４】従来の技術による認証型ディッファー・ヘルマン法のメッセージ通信部分のステップを示すフローチャートである。
【図５】従来の技術によるＲＳＡ転送法を使用した暗号化のステップを示すフローチャートである。
【図６】従来の技術によるＲＳＡ転送法を使用した復号化のステップを示すフローチャートである。
【図７】従来の技術によるＲＳＡ転送法を使用した署名作成のステップを示すフローチャートである。
【図８】従来の技術によるＲＳＡ転送法を使用した署名確認のステップを示すフローチャートである。
【図９】従来の技術によるミカリキー寄託プロセスのステップをともに示すフローチャートである。
【図１０】従来の技術によるミカリキー寄託プロセスのステップをともに示すフローチャートである。
【図１１】従来の技術によるミカリキー寄託プロセスのステップをともに示すフローチャートである。
【図１２】従来の技術による公開暗号化キー寄託認証の書式の例である。
【図１３】クリッパーデバイス警察アクセスフィールド（ＬＥＡＦ）の考えられる書式の例である。
【図１４】本発明のデバイスの製造メーカーにより発行されるデバイス認証の書式の例である。
【図１５】唯一の寄託代理人にキーを認証できるように寄託する方法のステップを示すフローチャートである。
【図１６】信用されたデバイスだけに基づいて、認証できるようにキーを寄託する方法のステップを示すフローチャートである。
【図１７】メッセージ制御ヘッダ（ＭＣＨ）で暗号化されたメッセージを送信する方法のステップを示すフローチャートである。
【図１８】ＲＳＡキー転送書式でのＭＣＨの例である。
【図１９】ＭＣＨで暗号化されたメッセージを受け取る方法のステップを示すフローチャートである。
【図２０】ＭＣＨデコーダボックスおよびそのプロセスフローのフローチャートの例である。
【図２１】自己認証を行う信用されるタイムスタンプデバイスの例である。
【図２２】本発明のデバイスの製造メーカーにより発行されるデバイス所有者認証の書式の例である
【図２３】本発明のデバイスの所有者によりキーを寄託し直す（再キー入力する）方法のステップを示すフローチャートである。
【図２４】信用された第三者による本発明の信用されたデバイスの登録のための方法のステップを示すフローチャートである。
【図２５】ＭＣＨフォーマットについて示す。
【図２６】所有者認証に関して示す図である。
【図２７】所有者公開命令キーの処理について示す。
【図２８】所有者公開命令承認キーの置き換えを示す。
【図２９】国際的な暗号通信の送受の際の寄託要件の施行を示す。
【図３０】国際的な暗号通信の送受の際の寄託要件の施行を示す。
【図１Ａ】
2006246543.tif 000003
【図１Ｂ】
2006246543.tif 000004
【図１Ｃ】
2006246543.tif 000005
【図１Ｄ】
2006246543.tif 000006
【図１Ｅ】
2006246543.tif 000007
【図１Ｆ】
2006246543.tif 000008
【図１Ｇ】
2006246543.tif 000009
【図２】
2006246543.tif 000010
【図３】
2006246543.tif 000011
【図４】
2006246543.tif 000012
【図５】
2006246543.tif 000013
【図６】
2006246543.tif 000014
【図７】
2006246543.tif 000015
【図８】
2006246543.tif 000016
【図９】
2006246543.tif 000017
【図１０】
2006246543.tif 000018
【図１１】
2006246543.tif 000019
【図１２】
2006246543.tif 000020
【図１３】
2006246543.tif 000021
【図１４】
2006246543.tif 000022
【図１５】
2006246543.tif 000023
【図１６】
2006246543.tif 000024
【図１７】
2006246543.tif 000025
【図１８】
2006246543.tif 000026
【図１９】
2006246543.tif 000027
【図２０】
2006246543.tif 000028
【図２１】
2006246543.tif 000029
【図２２】
2006246543.tif 000030
【図２３】
2006246543.tif 000031
【図２４】
2006246543.tif 000032
【図２５】
2006246543.tif 000033
【図２６】
2006246543.tif 000034
【図２７】
2006246543.tif 000035
【図２８】
2006246543.tif 000036
【図２９】
2006246543.tif 000037
【図３０】
2006246543.tif 000038