JP2004506245A - デバイスの公開鍵と製造中の情報とのリンク - Google Patents

Abstract

デジタル署名（１２２）を生成するデバイス（１０４）に関する情報が確実に識別される方法は、安全な環境（１１４）で各デバイス（１０４）について、各デバイスが安全な環境からリリースされる前に、デバイスを製造する工程（１０２）と、一組の公開−秘密鍵（１１６、１１８）を作成する工程と、メッセージ（１２２）用のデジタル署名（１２２）を生成する際に利用するために秘密鍵（１１６）をデバイス（１０４）内に格納する工程と、公開鍵（１１８）をデバイス（１０４）のセキュリティプロフィール（１２０）にリンクさせる工程とを含む。デバイス（１０４）はその後、安全な環境（１１４）からリリースされ、デジタル署名（１２２）が世界（１０６）のいずれかの場所（１０８）から受け取られる。メッセージ（１２２）は、疑わしい公開鍵（１２４）を用いて認証され、疑わしい公開鍵（１２４）が、リンクされた公開鍵（１１８）と比較される。
【選択図】図１

Description

【０００１】
（Ｉ．関連出願の引用）
本特許出願は、Ｗｈｅｅｌｅｒらによる米国仮特許出願第６０／２２３，０７６号の出願日の利益に対して、米国特許出願およびパリ条約において世界中に優先権を主張する。米国仮特許出願第６０／２２３，０７６号は、２０００年８月に出願され、本明細書中において参考として援用される。さらに、本出願は、三つの国際特許出願および三つの米国特許出願のそれぞれを本明細書中に参考として援用する。それらは、ＡｎｎｅおよびＬｙｎｎ　Ｗｈｅｅｌｅｒによって、米国特許商標庁に２００１年８月６日に同時に出願され、出願番号第ＰＣＴ／ＵＳ０１／４１５８７号（「Ｐｅｒｓｏｎ−Ｃｅｎｔｒｉｃ　Ａｃｃｏｕｎｔ−Ｂａｓｅｄ　Ｄｉｇｉｔａｌ　Ｓｉｇｎａｔｕｒｅ　Ｓｙｓｔｅｍ」と称されている）、出願番号第０９／９２３，１７９号（Ａｃｃｏｕｎｔ−Ｂａｓｅｄ　Ｄｉｇｉｔａｌ　Ｓｉｇｎａｔｕｒｅ（ＡＢＤＳ）　Ｓｙｓｔｅｍ」と称されている）、出願番号第ＰＣＴ／ＵＳ０１／４１５６２号（「Ｅｎｔｉｔｙ　Ａｕｔｈｅｎｔｉｃａｔｉｏｎ　ｉｎ　Ｅｌｅｃｔｒｏｎｉｃ　Ｃｏｍｍｕｎｉｃａｔｉｏｎｓ　ｂｙ　Ｐｒｏｖｉｄｉｎｇ　Ｖｅｒｉｆｉｃａｔｉｏｎ　Ｓｔａｔｕｓ　ｏｆ　Ｄｅｖｉｃｅ」と称されている）、出願番号第０９／９２３，０７５号（「Ｍｏｄｉｆｙｉｎｇ　Ｍｅｓｓａｇｅ　Ｄａｔａ　ａｎｄ　Ｇｅｎｅｒａｔｉｎｇ　Ｒａｎｄｏｍ　Ｎｕｍｂｅｒ　Ｄｉｇｉｔａｌ　Ｓｉｇｎａｔｕｒｅ　Ｗｉｔｈｉｎ　Ｃｏｍｐｕｔｅｒ　Ｃｈｉｐ」と称されている）、出願番号第０９／９２３，２１３号（「Ｍａｎｕｆａｃｔｕｒｉｎｇ　Ｕｎｉｑｕｅ　Ｄｅｖｉｃｅｓ　Ｔｈａｔ　Ｇｅｎｅｒａｔｅ　Ｄｉｇｉｔａｌ　Ｓｉｇｎａｔｕｒｅｓ」と称されている）、および出願番号第ＰＣＴ／ＵＳ０１／２４５６３号（「Ｔｒｕｓｔｅｄ　Ａｕｔｈｅｎｔｉｃａｔｉｏｎ　Ｄｉｇｉｔａｌ　Ｓｉｇｎａｔｕｒｅ（ＴＡＤＳ）　Ｓｙｓｔｅｍ」と称されている）である。
【０００２】
（ＩＩ．本発明の分野）
本発明は、概して、電気通信に関し、特に電気通信に関連したデジタル署名を生成するデバイスに関する。
【０００３】
（ＩＩＩ．本発明の背景）
本明細書中に使用されるように、電気通信（「ＥＣ」）は、電気的な形態の任意の通信であると判定される。ＥＣは、今日の商取引ビジネスの不可欠な部分であり、特に、インターネットおよび電子商取引の成長には不可欠である。ＥＣは、例えば、情報または物理領域、資金の振替の銀行への指示といった金融商取引、あるいは、署名された契約書の配送といった法的行為に関するアクセスの要求を表現し得る。
【０００４】
近年にわたって、デジタル署名はまた、電子商取引の重要な部分になっている。デジタル署名の作成は、概して、（１）メッセージダイジェスト（例えば、ハッシュ値）の算出、（２）それに続くメッセージダイジェストの暗号化を含む。メッセージダイジェストは、公開−秘密鍵の暗号化（非対称暗号化としても既知である）に使用される一組の鍵のうち秘密鍵を一般に用いる電子デバイスによって暗号化される。生成される暗号文は、たいていそれ自体デジタル署名で構成する。このデジタル署名は、一般に、ＥＣを形成するメッセージに添付される。デジタル署名を作成する（秘密鍵で暗号化する）第２の部分は、デジタル署名を「生成する」として本明細書中に言及され、この二つの工程の組み合わせは、デジタル署名を「作成する」として本明細書中に言及される。さらに、デジタル署名の生成がメッセージダイジェストの暗号として慣習的に理解される一方で、デジタル署名を生成することが、さらにメッセージダイジェストではなくメッセージを暗号化し易くすることを含み得ることが本明細書中で検討される。ＥＣにおけるメッセージに対するどんな変化であれ、メッセージおよびデジタル署名の分析から検出可能であるので、デジタル署名は重要である。この点において、デジタル署名は、ＥＣ内に含まれるメッセージを「認証する」ために使用される（本明細書中に「メッセージ認証」として言及される）。
【０００５】
例えば、メッセージダイジェストは、ハッシュ法アルゴリズムをメッセージに適用することによって算出され得る。ハッシュ法アルゴリズムは、デバイス内部、またはデバイスの外部のいずれかに生じたハッシュ値で適用され得、その後、デジタル署名の生成のためのデバイスに伝送され得る。この例示においてメッセージ認証を実行するために、ＥＣの受信側は、メッセージに適用されるハッシュ法アルゴリズムのアイデンティティおよびメッセージダイジェストを暗号化するために使用される秘密鍵に対応する公開鍵（「ＰｕＫ」）を共に知る必要があり、取得することができる。この認識と共に、受信側は、ハッシュ値を算出するためにメッセージに適切なハッシュ法アルゴリズムを適用し、受信側は、公開鍵を用いてデジタル署名を解読する。受信側によって算出されたハッシュ値が解読されたデジタル署名のハッシュ値に等しい場合、受信側は、ＥＣに含まれるメッセージのコンテンツが伝送されなかったと判定する。この伝送は、必然的にハッシュ値を変化させる。
【０００６】
メッセージ認証を実行すると、ＥＣの送信側がメッセージを首尾良く認証するために使用される公開鍵に対応する秘密鍵を保有したことを受信側が確認するほど、受信側はさらにＥＣの送信側を認証する。このことは、エンティティ認証の一種であり、送信側が「有する」ものに基づく（本明細書中において「ファクタＡエンティティ認証」として言及される）。ＥＣの受信側が、公開鍵の所有者のアイデンティティによる情報を信用したとき、ファクタＡエンティティ認証は役に立つ。このような信用された情報は、ＥＣを伴ない、公開鍵を用いて秘密鍵の所有者のアイデンティティを拘束する信用された第三者によって発行されたデジタルの証明書から生じ得る。この信用された認識はまた、例えば、受信側自身が秘密鍵または秘密鍵を含むデバイスを所有者に発行した場合、秘密鍵の所有者のアイデンティティの実際の認識を含み得る。
【０００７】
理解されるように、デジタル署名の信用は、秘密鍵の合法的な所有および使用に依存する（すなわち、実際に秘密鍵の所有者であるＥＣの送信側に依存する）。ＥＣのデジタル署名を生成するための秘密鍵の不正な使用は、上述されたメッセージ認証およびファクタＡのエンティティ認証手順を介して容易に見破られることができない。それ故、デバイスの秘密鍵が、秘密鍵を含むデバイスの物理的な盗み、または秘密鍵を発見し、次にデジタル署名を作成可能である別のデバイスでコピーし、使用するかの一方によって盗用される場合、デジタル認証システムは、不正行為が可能である。
【０００８】
デバイス自体の盗みによる、デバイスの不正な使用に対して警戒するために、個人識別番号（ＰＩＮ）、パスワード、またはパスフレーズ（「機密」として本明細書中に共通して言及される）は、一般に、デバイス内に予め格納され、デジタル署名を作成することが操作される以前にデバイスに入力される必要がある。あるいは、機密は、事前に受信側に共有され、後にＥＣが受信側に送信されると、機密はまた、メッセージに関連して受信側に送信される。第１の場合において、機密の検証は、デバイスのユーザを認証して（本明細書中では「ユーザ認証」）、第２の場合において、機密の検証は、ＥＣの送信側を認証する（本明細書中では「送信側認証」）。いずれの場合でも、機密の確認は、ユーザまたは送信側が「知る」ものに基づくエンティティ認証を表す（本明細書中では「ファクタＢのエンティティ認証」）。物理的な盗難によるデバイスの不正な使用に対して警戒する別のセキュリティの特徴は、デバイスのユーザまたはＥＣの送信側の指紋のように、生体測定の特徴の検証を含む。この種の認証は、ユーザまたは送信側が「何であるか」に基づく（本明細書中では「ファクタＣのエンティティ認証」）。機密と同様に、生体測定値は、ユーザ認証のデバイス内に維持されるか、受信側による送信側認証以前に受信側と共有されるか、どちらか一方である。秘密鍵が発見され、次に別のデバイスでのコピーおよび使用に対して警戒するために、デバイスは、電気保護、ゼロ化、検査、タンパー印およびタンパー応答、ならびにデバイスに含まれる秘密鍵（および他の保護されたデータ）を保護するために果たす他のセキュリティ特徴を用いて製造される。
【０００９】
このようなデバイスのセキュリティの特性は、ハードウェア、ソフトウェア、およびファームウェアを含み、安全なコンピュータチップおよび暗号化モジュールを有する他のデバイスを製造する従来技術において周知である。このようなセキュリティの特徴の必要性は、例えば、Ｆｅｄｅｒａｌ　Ｉｎｆｏｒｍａｔｉｏｎ　Ｐｒｏｃｅｓｓｉｎｇ　Ｓｔａｎｄａｒｄｓ　Ｐｕｂｌｉｃａｔｉｏｎ　１４０−１、Ｓｅｃｕｒｉｔｙ　Ｒｅｑｕｉｒｅｍｅｎｔ　ｆｏｒ　Ｃｒｙｐｔｏｇｒａｐｈｉｃ　ＭｏｄｕｌｅｓのＵＳ　ＤＯＣ／ＮＢＳ（１９９４年１月１１日）（本明細書中では「ＦＩＰＳ　ＰＵＢ　１４０−１」）（ｈｔｔｐ：／／ｃｓｒｃ．ｎｉｓｔ．ｇｏｖ／ｐｕｂｌｉｃａｔｉｏｎｓ／ｆｉｐｓでダウンロード可能）、およびＦｅｄｅｒａｌ　Ｉｎｆｏｒｍａｔｉｏｎ　Ｐｒｏｃｅｓｓｉｎｇ　Ｓｔａｎｄａｒｄｓ　Ｐｕｂｌｉｃａｔｉｏｎ　１４０−２、Ｓｅｃｕｒｉｔｙ　Ｒｅｑｕｉｒｅｍｅｎｔｓ　ｆｏｒ　Ｃｒｙｐｔｏｇｒａｐｈｉｃ　Ｍｏｄｕｌｅｓ、ＵＳ　ＤＯＣ／ＮＢＳ（２００１年５月２５日）（本明細書中では「ＦＩＰＳ　ＰＵＢ　１４０−２」）（ｈｔｔｐ：／／ｃｓｒｃ．ｎｉｓｔ．ｇｏｖ／ｐｕｂｌｉｃａｔｉｏｎｓ／ｆｉｐｓでダウンロード可能）において特定され、共に本明細書中で参考として援用される。ＦＩＰＳ　ＰＵＢ　１４０−１および１４０−２はまた、デバイスの秘密鍵を識別しようとして直面する時間および金銭の点での困難性の様々なレベルを一般に表すこれらの定義された各セキュリティレベルと共に、デバイスのセキュリティ特徴に基づいてデバイスにより達成され得るセキュリティレベルを定義する。現在のところ、四つのセキュリティレベルは、利用可能なセキュリティの最も高いレベルがセキュリティレベル４で定義される。
【００１０】
このようなセキュリティ特徴の仕様はまた、Ｔｒｕｓｔｅｄ　Ｃｏｍｐｕｔｉｎｇ　Ｐｌａｔｆｏｒｍ　Ａｌｌｉａｎｃｅ　Ｔｒｕｓｔｅｄ　Ｐｌａｔｆｏｒｍ　Ｍｏｄｕｌｅ　Ｐｒｏｔｅｃｔｉｏｎ　Ｐｒｏｆｉｌｅ　Ｖｅｒｓｉｏｎ　０．４５（ＴＲＵＳＴＥＤ　ＣＯＭＰＵＴＩＮＧ　ＰＬＡＴＦＯＲＭ　ＡＬＬＩＡＮＣＥ（２０００年９月））、Ｔｒｕｓｔｅｄ　Ｐｌａｔｆｏｒｍ　Ｍｏｄｕｌｅ（ＴＰＭ）　Ｓｅｃｕｒｉｔｙ　Ｐｏｌｉｃｙ　Ｖｅｒｓｉｏｎ　０．４５（ＴＲＵＳＴＥＤ　ＣＯＭＰＵＴＩＮＧ　ＰＬＡＴＦＯＲＭ　ＡＬＬＩＡＮＣＥ（２０００年１０月））、およびＴＣＰＡ　ＰＣ　Ｉｍｐｌｅｍｅｎｔａｔｉｏｎｓ　Ｓｐｅｃｉｆｉｃａｔｉｏｎ　Ｖｅｒｓｉｏｎ　０．９５（ＴＲＵＳＴＥＤ　ＣＯＭＰＵＴＩＮＧ　ＰＬＡＴＦＯＲＭ　ＡＬＬＩＡＮＣＥ（２００１年７月４日））に示され、本明細書中に参考として援用し（共同で「ＴＣＰＡ文書」）、ｈｔｔｐ：／／ｔｒｕｓｔｅｄｐｃ．ｃｏｍでダウンロード可能であり、ならびに、Ｃｏｍｍｏｎ　Ｃｒｉｔｅｒｉａ　ｆｏｒ　Ｉｎｆｏｒｍａｔｉｏｎ　Ｔｅｃｈｎｏｌｏｇｙ　Ｓｅｃｕｒｉｔｙ　Ｅｖａｌｕａｔｉｏｎ、Ｓｍａｒｔ　Ｃａｒｄ　Ｐｒｏｔｅｃｔｉｏｎ　Ｐｒｏｆｉｌｅ、Ｄｒａｆｔ　Ｖｅｒｓｉｏｎ　２．１ｄ（ＳＭＡＲＴ　ＣＡＲＤ　ＳＥＣＵＲＩＴＹ　ＵＳＥＲ　ＧＲＯＵＰ（２００１年３月２１日））に示され、本明細書中に参考として援用し（本明細書中では後に「スマートカード保護プロフィール」）、ｈｔｔｐ：／／ｃｓｒｃ．ｎｉｓｔ．ｇｏｖでダウンロード可能である。
【００１１】
秘密鍵および他の保護されたデータの発見に対して防御するデバイスの特定の特徴は、本明細書中にデバイスの「セキュリティ特徴」として参照される。ユーザを認証することによってデバイスの非認証である使用に対して保護するデバイスの特定の特徴は、本明細書中にデバイスの「認証能力」として参照される。デバイスの「セキュリティ特徴」は、セキュリティ特徴および認証能力ならびにデバイスの他のセキュリティ特徴を備える。上述した引例にデバイスの必要性が明記される。
【００１２】
あいにく、上述のセキュリティ機能は、概して、全体的にデジタル署名システム内の不正行為の可能性を減少する。デジタル署名を含むある特定のＥＣの任意の受信側は、デジタル署名を作成するために使用されるデバイスに不慣れである。従って、その受信側は、デバイスの盗みまたは秘密鍵の発見のいずれかによって、デジタル署名が不正に生成されたかどうかの可能性を評価することができない。
【００１３】
確かに、受信側が、送信側認証を実行するための共有の秘密または送信側の生体測定値を所有する場合、受信側は、デジタル認証が共有の秘密または生体測定値が盗まれなかったことを想定して不正に生成されなかったことを判別し得る。しかし、受信側によるこの種の保護は、重大な欠点があり、受信側によって必ずしも使用されるとは限らない。例えば、秘密または生体測定値は、受信側による送信側認証のメッセージに関して受信側に通信される場合、次に、まず秘密または生体測定値が、前もって受信側に共有され、確立された、既存の関係の部分として受信側によって防御される。その結果、送信側と予め関係のない受信側は、送信側認証を実行できない。
【００１４】
別の欠点は、受信側との秘密または生体測定値の共有は、受信側を責任で、秘密または生体測定値自体を盗みおよび流布のより大きな可能性に曝す。認証に対する秘密または生体測定値は、送信中の妨害および発見の可能性が付いてくる。受信に関して、秘密または生体測定値は、受信側によって防御される必要がある。受信側は、本質的に受信側から盗みの可能性を生じる。このことは、企業背景において特に深刻である。なぜなら悪い従業員が保護された秘密または生体測定値を盗み得る（インサイダー不正行為は、歴史的に最も大きな脅威である）。秘密または生体測定値が盗まれたとき、潜在的な損害もまた大きい。個々が複数の受信側の複数の秘密を覚えることは困難であるので、同じ秘密を異なる受信側で使用することは通常のことである。それによって、ある受信側からの秘密の盗みは、少なくとも秘密が各受信側で変更されるまで、受信側全員によって行われる送信側認証を危うくする。生体測定値の盗みの場合、送信側の生物特性は、変更され得ず、一旦失うと、いずれの将来の送信側認証を潜在的に危うくするように、損害はよりシビアになる。
【００１５】
従って、受信側は、概して、秘密または生体測定値が送信側と受信側との間で共有されていないとき、デジタル署名が不正に生成されているかどうかの可能性を正確に判定することができない。代わりに、受信側は、デジタル署名を生成するために使用されるデバイスが盗まれていないことを承認し、デジタル署名を生成するために使用されるデバイスを十分に保護して、発見および使用からデバイスの秘密鍵を保護していることを承認することを盲目的に信じる必要がある。
【００１６】
従って、受信側は、デジタル署名が、盗まれた秘密鍵を不正に使用して生成されたかどうか（デバイスの物理的な盗みによって盗まれたのか、秘密鍵自体の発見によって盗まれたのかどうか）の可能性を確実に識別し得る方法を必要とする。それによって、受信側は、不正に対してデジタル署名自体を保護し得る。この点について、デジタル署名を含むＥＣの受信側は、デジタル署名を生成するために使用される秘密鍵が属するデバイスの現在のセキュリティレベルを所与の時間で確実に判定し得る方法をさらに必要とする。ＥＣの受信側は、不正に対する保護を用いるこのようなデバイスの保護手段を確実に判定し得る方法を必要とする。
【００１７】
（ＩＶ．本発明の要旨）
本発明は、概して、デジタル署名を、デバイスが製造される環境内のデバイスに関する他の情報に対して非対称の暗号を用いて生成する、デバイスの公開鍵の確実な様態でリンクすることを含む。本明細書中で使用されるように、「他の情報」は、少なくとも１つのセキュリティ特徴およびデバイスの製造履歴を含み、好ましくは、セキュリティ特徴とデバイスの製造履歴とを共に含む（本明細書中、「セキュリティプロフィール」として全体的に言及される）。
【００１８】
本明細書中に使用されるように、デバイスの「認証能力」は、デバイスによるユーザ認証に関してファクタＢおよびＣのエンティティ認証の一方または両方を実行するそれらの構成要素を含む。さらに、デバイスの「製造履歴」は、好ましくは、デバイスの製造属性（例えば、デバイスの生産者、デバイスに対する適切な全ての詳細、デバイスの製造日、製造場所、デバイスのバッチ識別子、デバイスのシリアル番号または品番、製造施設のセキュリティ、レイアウトおよびプロセスのジオメトリに関するデバイスの物理的な具体化、ソフトウェアの識別番号および公開日、電圧および周波数領域を含むデバイスの操作パラメータ、ならびにデバイスの全ての使用可能なハードウェアおよびソフトウェアセキュリティ特徴の識別番号）の記録を含む。デバイスの製造履歴はまた、好ましくは、暗号特性、キー生成特性、およびデバイスの乱数生成特性を含む。
【００１９】
（Ａ．本発明の第１の局面：デジタル署名を生成するデバイスのＰｕＫリンクされた情報を認証する工程）
本発明の第１の局面は、デバイス製造の環境内の他の情報とデバイスの公開鍵とをリンクし、次いで、デバイスの公開鍵に基づく製造環境からのデバイスの公開後にデバイスに関する他の情報を識別することを含む。このような情報のより最近の識別を考慮することによって、受信側は、デバイスに属する秘密鍵を用いるデジタル署名が不正に生成されたかどうかの可能性または確立を正しく判定することができる。
【００２０】
本発明の第１の局面の好適な方法によると、デバイスは、安全な環境（すなわち、このような環境で製造された任意のデバイスのセキュリティレベルを危うくように、十分なセキュリティ評定を有する環境）で製造される。さらにデバイスの公開鍵とリンクされた情報は、デバイスのセキュリティプロフィールを含む。従って、受信側は、デバイスの識別されたセキュリティ特徴に基づいたデバイスの現在のセキュリティレベルを判定することができる。受信側はまた、デバイスの秘密鍵がデバイスの識別されたセキュリティ特徴に基づいて判定されたかどうかの可能性を正しく判定することができる。また、受信側は、秘密鍵を含むデバイスがデバイスの識別された認証性能に基づいて不正に使用されたかどうかの可能性を正しく判定することができる。最後に、受信側はまた、デバイスの識別された製造履歴に基づいたデバイスの公認のセキュリティ特徴を評価することができる。
【００２１】
本発明の第１の局面の好適な方法において、製造されたデバイスが安全な環境から移動される前に、一組の公開−秘密鍵がデバイス内で作成され、公開鍵は、安全な環境内で維持された１つ以上のデータベース（本明細書中、全体的に「安全なデータベース」という）内のデバイスのセキュリティプロフィールにエクスポートされ、リンクされる。特に、キーの１つである公開鍵は、デバイス生産者または他の信頼できるエンティティ（「安全なエンティティ」）によって安全なデータベースに記録され、他のキーである秘密鍵は、好ましくは、製造されたデバイス内で保持され、発見に対して防御される。公開鍵はまた、デバイス内で保持され、オンデマンドでエクスポート可能である。製造されたデバイスのセキュリティプロフィールは、安全なデータベースに記録され、従って、その記録は、対応する公開鍵にインデックスを付けられるか、またはマッピングされる。それ故、デバイスの公開鍵およびセキュリティプロフィールを共に確実にリンクする。この場合、独自の識別子は、デバイス内に格納され、オンデマンドでエクスポート可能である。さらに、それぞれの公開鍵は独特（少なくとも高い可能性で）であるので、安全なデータベースにおけるマッピングは一対一である。あるいは、公開鍵および安全なプロフィールは、安全なデータベース内のデバイスの独自の識別子に対してインデックスを付けられ、これにより、デバイスの公開鍵およびセキュリティプロフィールを共に確実にリンクして、それ故、デバイスの保証レベルが判定され得る。
【００２２】
次に、ＥＣが疑わしいデバイスによって生成されたデジタル署名を含む受信側によって受信され、メッセージが疑わしい公開鍵を利用して認証されたとき、受信側は、ＥＣのデジタル署名を生成するために用いた公開鍵に属する実際の製造されたデバイス（本明細書中、「本物のデバイス」として言及する）に関する、疑わしい公開鍵にリンクされたセキュリティプロフィールを識別する。従って、デジタル署名が不正に生成されたかどうかは、本物のデバイスに対する公知のセキュリティプロフィールに基づいた受信側によって正しく判定され得る。特に、製造されたデバイス内に保持された公開鍵が危ういかどうかの可能性（そして、疑わしいデバイスが本物のデバイスであるかどうか）は、本物のデバイスの識別されたセキュリティ特徴に基づいて正しく判定され得る。そして、本物のデバイスが不正に使用されたかどうかの可能性は、本物のデバイスの識別された認証能力に基づいて正しく判定され得る。これらの評価はまた、必要に応じて、デバイスの識別された製造履歴に基づいて認定され得る。
【００２３】
本発明の第１の局面の代替の好適な方法において、一組の公開−秘密鍵は生成され、デバイスの公開鍵は、安全なエンティティによってデジタルに署名された記録内に、公開鍵とセキュリティプロフィールとを組み合わせることによって、デバイスのセキュリティプロフィールにリンクされる。記録およびデジタル署名は共に、「セキュリティ証明書」を形成する。セキュリティ証明書はまた、公開鍵を用いて安全に保護するためにデバイス中にインポートされる。安全な環境における安全なエンティティによる記録のデジタル署名は、製造されたデバイスのセキュリティプロフィールおよびデバイスの公開鍵を確実にリンクする。
【００２４】
次に、デジタル署名がＥＣに含まれるためにデバイスによって生成されたとき、セキュリティ証明書はまた、ＥＣに含まれる。セキュリティ証明書に示される疑わしい公開鍵を用いてメッセージを受信し、かつ、認証が成功すると、受信側は、安全なエンティティの公開鍵を利用して、ＥＣにおいてセキュリティ証明書を認証する。メッセージの認証に成功すると、受信側は、ＥＣのデジタル署名を生成するために使用される公開鍵が属する本物のデバイスのセキュリティプロフィールの公開鍵を利用してセキュリティ証明書を認証する。従って、デジタル署名が不正に生成されたかどうかは、本物のデバイスに対する公知のセキュリティプロフィールに基づいた受信側によって正しく判定され得る。特に、製造されたデバイス内に保持された公開鍵が危ういかどうかの可能性（そして、疑わしいデバイスが本物のデバイスであるかどうか）は、本物のデバイスの識別されたセキュリティ特徴に基づいて正しく判定され得る。そして、本物のデバイスが不正に使用されたかどうかの可能性は、本物のデバイスの識別された認証能力に基づいて正しく判定され得る。これらの評価はまた、必要に応じて、デバイスの識別された製造履歴に基づいて認定され得る。
【００２５】
（Ｂ．本発明の第２の局面：ＰｕＫリンクされた口座データベースを確立する）
本発明の第２の局面は、初期のＰｕＫリンクされた口座データベースを確立することを含む。本発明のこの局面による方法は、デジタル署名を生成するデバイスを製造する工程と、製造されたデバイスがそれの製造環境から公開される以前に各デバイスに対して、非対称の暗号に使用される一組の鍵を作成する工程と、電子メッセージのデジタル署名を生成中に、利用する製造されたデバイス内に鍵の１つを格納する工程と、例えば、情報がデータベースにおける鍵とリンクされるといった環境内に維持されるデータベースに他の鍵と他の情報とを記録する工程とを包含する。次に、この製造されたデバイスは、複数のユーザに分配される。製造されたデバイスが分配されるユーザは、既存の顧客および第三者の潜在的な顧客を含む。従って、分配され製造されたデバイスのデータベース記録は、ユーザの初期のＰｕＫリンクされた口座データベースとして第三者に識別される。
【００２６】
本発明のこの局面の好適な方法によると、デバイスの各鍵とリンクされる情報は、それぞれのデバイスのセキュリティプロフィールを含み、セキュリティプロフィールが識別されるデバイスは、安全な環境において製造される。データベースはまた、好ましくは、安全なデータベースを含む。さらに、各デバイスの鍵は、好適には、オンデマンドで好適にエクスポート可能である公開鍵と共に生成され、デバイス内に保持される。
【００２７】
本発明のこの局面の好適な方法において、データベース記録を識別する工程は、初期の第三者のＰｕＫリンクされた口座データベースとして分配され製造されたデバイスのデータベース記録を安全な様態の安全な環境から通信する工程を含む。この点においては、データベース記録は、データベース記録が属する任意の製造されたデバイスの安全レベルよりも高い安全評定を有する様態で通信される。確かに、安全な評定は、データベース記録が属する全ての個々のデバイスによって提示される合計の可能性に対して比率するべきである。このような様態は、データベース記録のデジタル署名を生成し、次いで、第三者に対してデータベース記録およびデジタル署名を通信する工程とを含む。
【００２８】
第三者が、ＰｕＫリンクされたデータベースをユーザの初期のＰｕＫリンクされた口座データベースとして受信すると、ＰｕＫリンクされたデータベースは、各ユーザによって提供されるようにユーザ固有の情報に更新され得る。ユーザに関する固有の情報と初期のＰｕＫリンクされた口座データベースとを結び付けると、ファクタＡのエンティティ認証は、好ましくは、製造されたデバイスの秘密鍵を有するメッセージをデジタルに署名することに基づいて使用される。あるいは、初期のＰｕＫリンクされた口座データベースは、ユーザ固有の情報を含む第三者によって維持されるユーザの既存の口座データベースと併合され得る。または、初期のＰｕＫリンクされた口座データベースは、このようなユーザの既存の口座データベースを用いてインデックスを付けられるが、ユーザの既存の口座データベースから切り離して維持され得る。このような場合において、第三者は、好ましくは、このような関連になる以前に口座データベースにおいてユーザのそれぞれの記録に関して正しいユーザになるように各ユーザを認証する。従って、ファクタＡエンティティ認証は、好ましくは、ＰｕＫリンクされた口座データベースにおいてユーザの記録に関して使用され、他のエンティティ認証技術は、口座データベースにおける記録に関してユーザを認証するために使用される。このような他の技術は、記録中に固有の口座情報についてユーザに質問する工程と、ユーザの母親の旧姓といった秘密を提供することをユーザに要求する工程とを含む。
【００２９】
（Ｃ．本発明の第３の局面：初期のＰｕＫリンクされた口座データベース記録を確立すること）
本発明の第３の局面は、異なる第三者によって維持される複数の口座を有するユーザの初期のＰｕＫリンクされた口座データベースを確立する工程を含む。本発明のこの局面による方法は、デジタル署名を生成するデバイスを製造する工程と、製造されたデバイスが製造環境から公開される以前に各デバイスに対して、非対称の暗号に使用される一組の鍵を作成する工程と、電子メッセージのデジタル署名を生成中に、利用する製造されたデバイス内に鍵の１つを格納する工程と、例えば、情報がデータベースにおける鍵とリンクされるといった環境内に維持されるデータベースに他の鍵と他の情報とを記録する工程とを包含する。次に、製造されたデバイスの１つがユーザに分配される。その後、分配されたデバイスのデータベース記録は、ユーザの初期のＰｕＫリンクされた口座データベース記録になるように第三者のそれぞれに識別される。ユーザは、顧客または各第三者の潜在的な顧客であり得る。
【００３０】
本発明のこの局面の好適な方法によると、デバイスの鍵とリンクされる情報は、デバイスのセキュリティプロフィールを含み、デバイスは、安全な環境において製造される。鍵およびセキュリティプロフィールがリンクされるデータベースはまた、好ましくは、安全なデータベースを含む。さらに、鍵は、オンデマンドで好適にエクスポート可能である公開鍵と共に、好適に生成され、デバイス内に保持される。
【００３１】
本発明のこの局面の好適な方法において、初期のＰｕＫリンクされた口座データベース記録を識別する工程は、ユーザの口座が維持される、または維持され得る第三者に対して、ユーザのデバイスのデータベース記録を、安全な様態で安全な環境から通信する工程を含む。この点に関して、データベース記録は、データベース記録が属する製造されたデバイスの安全レベルよりも高い安全評定を有する様態で通信される。このような様態は、安全なエンティティによるデータベース記録に対してデジタル署名を生成する工程と、次に、第三者に対してデータベース記録とデジタル署名とを通信する工程と含む。
【００３２】
第三者が、ユーザの初期のＰｕＫリンクされた口座データベース記録としてＰｕＫリンクされたデータベース記録を受信すると、ＰｕＫリンクされたデータベース記録は、ユーザによって提供されるようにユーザ固有の情報に更新され得る。ユーザ固有の情報をユーザの初期のＰｕＫリンクされた口座データベース記録と結び付けると、ファクタＡエンティティ認証は、好適には、製造されたデバイスの秘密鍵を有するメッセージをデジタルに署名するユーザに基づいて初期のＰｕＫリンクされた口座データベース記録に使用される。あるいは、初期のＰｕＫリンクされた口座データベース記録は、ユーザ固有の情報を含む第三者によって維持されるユーザの既存の口座データベースと併合され得る。または、初期のＰｕＫリンクされた口座データベース記録は、このようなユーザの既存の口座データベース記録を用いてインデックスを付けられるが、ユーザの既存の口座データベース記録から切り離して維持され得る。このような場合において、第三者は、好ましくは、このような関連以前に、両方の口座記録に対して正しいユーザとしてユーザを認証する。従って、ファクタＡエンティティ認証は、好ましくは、口座データベース記録に関してユーザを認証するための他のエンティティ認証技術と共に使用される。このような他の技術は、記録における固有の口座情報についてユーザに質問する工程と、例えば、ユーザの母親の旧姓といった秘密を提供することをユーザに要求する工程とを包含し得る。
【００３３】
（Ｄ．本発明の第４の局面：デバイス生成デジタル署名の識別されたＰｕＫリンクされた情報に基づく取引に対してＥＣを保証する）
今までのところ、本発明の第４の局面は、本発明の第１の局面によるデジタル署名を生成する製造されたデバイスの識別された情報に（少なくとも部分的に）基づいて取引を保証する工程を含む。特に、本発明の第４の局面による好適な方法は、安全な環境においてデバイスを製造する工程と、デバイス安全な環境から公開される以前に各製造されたデバイスに関して、非対称の暗号で使用される一組の鍵を作成する工程と、電子メッセージのデジタル署名を生成中に、利用するために製造されたデバイス内に鍵の１つを格納する工程と、安全な環境において他の鍵と製造されたデバイスのセキュリティプロフィールとをともにリンクする工程とを含む。次に、製造されたデバイスは、安全な環境から公開される。
【００３４】
従って、取引を表す電子通信は、疑わしいデバイスで生成されたデジタル署名と共に送信される。電子通信は、製造されたデバイスの１つに格納された鍵を利用するために生成された電子メッセージおよびデジタル署名を含む。受信すると、メッセージは、公開鍵を用いて認証される。次に、メッセージをうまく認証する公開鍵にリンクされたセキュリティプロフィールは、デジタル署名を生成する際に使用される秘密鍵に属する本物のデバイスのセキュリティプロフィールとして識別され、金銭的な保証は、電子メッセージのデジタル署名が不正に生成されなかったことが提供される。金銭的な保証（すなわち、保険）は、本物のデバイスの識別されたセキュリティ特徴の評価に（少なくとも部分的に）基づいた、さらにデバイスの製造履歴の評価に基づき得るプレミアムの代わりに提供される。この点に関して、好適な方法は、金銭的な保証の供給の代わりに異なる保険料に対応する各定義された可能性レベルと共に、識別されたセキュリティプロフィールに基づいてＥＣに対して定義された可能性レベルを割り当てる工程を含む。
【００３５】
（Ｅ．本発明の第５の局面：口座によるＥＣがデジタル署名を生成するデバイスのＰｕＫリンクされた情報に基づいた不正であるかどうかを正しく判定すること）
本発明の第５の局面は、口座による取引がデジタル署名を生成するために使用されるデバイスの公開鍵とリンクされる情報だけでなく、受信側によって記録されたような口座の取引履歴、および特に、デジタルに署名された口座による取引の履歴（本明細書中、「取引履歴」という）にも基づき不正であることを表すデジタルに署名されたメッセージを含むかどうかの可能性を正しく判定する工程を含む。
【００３６】
本発明のこの局面にの特性において、複数の製造されたデバイスは、ユーザに分配されるか、またはユーザによって取得される。各分配されたデバイスに対するデータベース記録は、受信側に提供され、ユーザの口座と結び付けられる。次に、受信側によって受信され、デバイスの１つによって生成されるデジタル署名を含む口座による取引のためのＥＣに関して、受信側は、口座における各このような取引に関する特別な詳細を記録する。しかし、概して、取引の詳細と全体的な口座とを結び付けるのではなく、受信側は、取引の詳細とＥＣのメッセージをうまく認証するために使用されるリンクされた公開鍵とを結び付ける。従って、受信された各ＥＣに関して、受信側は、本発明の第１の局面に従って識別された公開鍵とリンクされた情報だけでなく、受信側によって記録されるような鍵を用いて認証されるデジタル署名の取引履歴にも基づいて不正のＥＣの潜在性を評価する。さらにさらなる特性において、ＥＣのデジタル署名が生成されるような環境はまた、このような情報がＥＣから識別可能であるか、または、さもなければ入手可能である場合、好ましくは、ＥＣが不正であるかどうかの可能性を正しく判定して考えられる。例えば、Ｉ／Ｏ支援要素はまた、ＥＣをデジタルに署名し得る。そして、Ｉ／Ｏ支援要素の公開鍵にリンクされたＩ／Ｏ支援要素に関連する情報は、本発明の第１の局面によって識別され得る。さらに、別の特徴において、リンクされた公開鍵がユーザの口座と関連されるときに実施される認証技術は、口座記録に記録され、特定のＥＣが不正であるかどうかの可能性を正しく判定して考えられる。
【００３７】
（Ｆ．本発明の第６の局面：デジタル署名を生成するデバイスのＰｕＫリンクされた情報を普及するためのサービス）
本発明の第６の局面によると、エンティティ（本明細書中、「中央鍵オーソリティ」）は、ユーザのためのＰｕＫリンクされた口座登録情報（本明細書中、「登録情報」）を維持する。登録情報は、公開鍵およびデジタル署名を生成するユーザの特定のデバイスに関連する情報である、ユーザがデバイスに対してＰｕＫリンクされた口座を有する第三者のアイデンティティ、本発明の第１の局面によるデバイスの公開鍵とリンクされる情報、ユーザ固有情報、ならびに該当する場合、中央鍵オーソリティによって維持されるユーザ固有情報を検証して使用された認証技術の１つ以上のタイプを含む。
【００３８】
本発明のこの局面に従って、中央鍵オーソリティは、該当する場合、第三者に登録情報の一部または全てを普及する。登録情報は、ユーザが第三者と口座を有するとき（すなわち第三者と口座を確立することを所望するとき）、およびデバイスを用いてデジタルに署名される口座により取引を表すメッセージを有するＥＣを送信することを所望するときに普及される。例えば、第三者との登録情報が特定の口座に対して古くなったときに、登録情報の普及がさらに生じる。さらに、本発明の第３の局面と共に登録情報の普及がなされ得る。
【００３９】
（Ｖ．図面の簡単な説明）
本発明のこれら局面のさらなる特徴および利点は、添付の図面と共に得られる好適な実施形態の詳細な説明から明白であり、同様の参照符号は、同様の構成要素を言及する。
【００４０】
（ＶＩ．好適な実施形態の詳細な説明）
例示的な様態として、本発明のデバイス、システム、および方法の次の詳細な説明を考慮して、当業者によって容易に理解される。本発明は、広い実用性および用途が可能である。本明細書に記載される以外の本発明の多くの実施形態および適応ならびに多くの改変、変更、および等価な配置は、本発明の本質または意図から逸脱することなく、本発明、および本発明の以下の詳細な説明から明白であり、合理的に示唆される。さらに、当業者は、様々なプロセスの工程が好適なシーケンスまたは一時的な順序で実行されるようにいくつかの例に示され、記載され得るが、このようなプロセスの工程がこのような特定のシーケンスまたは順序において実行されるように限定されることを必要としないことを理解し、認識する。それどころか、多くの例において、本明細書中に記載されるプロセスの工程は、本発明の範囲内に限定されているが、多様な異なるシーケンスおよび順序で実行され得る。従って、本発明が、好適な実施形態に関して本明細書中に詳細に記載される一方で、この詳細な説明は、本発明の図解および例示に過ぎず、本発明の開示を全てを提供し、本発明を開示する目的のために過ぎない。本明細書中に示す詳細な説明は、本発明を限定するため、またはそうでなければ、本発明の任意のこのような他の実施形態、適応、変化、変更、および等価な配置を除外するように意図されず、そして構成されない。本発明は、上掲の特許請求の範囲およびその等価物によってのみ限定される。
【００４１】
（Ａ．本発明の概要）
本発明は、公開−秘密鍵の暗号を用いるデジタル署名を生成するデバイスの公開鍵の信頼できる様態で、デバイスが製造される環境内のデバイスに関連する他の情報にリンクする工程を含む。一組の公開−秘密鍵は、製造中にデバイス内に生成され、その後、秘密鍵は、デバイス内に安全に保持され、決してエクスポートされず、公開鍵は、デバイス内に保持され、必要とされるときはいつでもオンデマンドでエクスポート可能になり得る。
【００４２】
本発明の局面に従って、デバイスは、ハードウェアまたはファームウェアを含み、特に、コンピュータチップ、集積回路、デバイス内の適切なソフトウェアを有するコンピュータ読み出し可能媒体、またはその組み合わせを含む。デバイスは、例えば、ハードウェアトークンまたは内蔵のトークン、コンピュータチップ、集積回路、またはソフトウェアを含むトークン、あるいはその組み合わせといった対象物をさらに含み得る。デバイスがハードウェアトークンである場合、デバイスは、好ましくは、リングまたは他の宝石、ドングル、電子鍵、ＩＣカード、スマートカード、クレジットカード、ＩＤバッジ、セキュリティバッジ、駐車カード、または通行カードといったカードなどの形態を取り得る。デバイスが内蔵したトークンである場合、デバイスは、内蔵したトークンである場合、デバイスは、好ましくは、携帯電話、電話、テレビ、携帯情報端末機器（ＰＤＡ）、腕時計、コンピュータ、またはコンピュータハードウェアなどの形態を取り得る。デバイスは、好ましくは、ポート（無線通信ポート、シリアルポート、ＵＳＢポート、パラレルポート、または赤外ポートを含む）を備えるデバイスインタフェース、または接触であろうと非接触であろうと、外部の電子装置と通信するためのいくつかの他の物理インタフェースを含む。デバイスはまた、上述のＴＣＰＡドキュメントに示され、記載されるように、プラットフォームにおいて増した信頼を提供するハードウェアおよびソフトウェア構成要素を含む信頼されたプラットフォームモジュール（ＴＰＭ）を含み得る。
【００４３】
これらのデバイスのいくつかは、メッセージ、秘密、または生体測定の特徴を表すデータを受信するようにデバイスをイネーブルするためにＩ／Ｏ支援要素の使用を要求する。デバイスのいくつかは、データの特定のタイプ（他のタイプではなく）を受信するためにＩ／Ｏ支援要素を要求する。デバイスのいくつかは、デジタル署名および受信側へのメッセージを含む情報を送信するためにＩ／Ｏ支援要素の使用を要求する。デバイスのいくつかは、内蔵型であり、外部装置を使用することなくメッセージおよびデジタル署名を生成し、送信し得る。内蔵型ではあるがいくつかのデバイスは、例えば、所望ならば、Ｉ／Ｏ支援要素といった、このような外部装置との相互通信を可能にする。Ｉ／Ｏ支援要素は、任意の数の異なる装置の形態を取り得て、Ｉ／Ｏ支援要素が使用される特定の用途に依存して、相互通信するデバイスのタイプに依存する。
【００４４】
高いセキュリティを要求するデバイスのアプリケーションに関して、デバイス（すなわち、Ｉ／Ｏ支援要素と組み合わせたデバイス）は、好適には、ユーザがメッセージを構成するか、または変更することが可能であるユーザデータエントリ機構のキーパッド（英数字）、相互通信ディスプレイ、または他のタイプ（「ユーザインタフェース」として本明細書中に全体的に言及される）と、秘密を表すデータを入力するためのユーザインタフェース（なお、メッセージを生成するか、または変更するためのユーザインタフェースが、秘密を表すデータのエントリのユーザインタフェースと、必ずしも同じになる必要はないが、同じになり得る）と、ユーザにメッセージおよび／または秘密を示すためのディスプレイ、スキャナ、またはユーザの生体測定の特徴の生体測定データの少なくとも１つを受信するためのリーダーと、認証されたユーザの秘密、認証されたユーザの生体測定データ、および秘密鍵を安全に格納するためのメモリと、認証されたユーザの秘密になるように生体測定データの秘密の入力を検証するためのプロセッサまたは回路と、デジタル署名を生成するか、またはデジタル署名を作成するためのプロセッサまたは回路と、デバイスから出力し、メッセージおよびその代わりにデジタル署名を含む情報を送信するための手段といった構成要素を含む。好ましくは、デバイスはまた、特定の秘密鍵に関連した公開鍵を格納してエクスポートするためのメモリ、および例えば、口座情報、およびユーザＩＤなどといったユーザ情報のタイプを格納するためのメモリを含む。
【００４５】
本発明の好適な実施形態の情報にリンクされた公開鍵は、デバイスのセキュリティプロフィールを含む。上記で定義されるように、セキュリティプロフィールは、好ましくは、デバイスのセキュリティ特徴（特性および認証能力を含む）、およびデバイスの製造履歴を含む。単にデバイスの公認のセキュリティレベルというよりも、技術がセキュリティ特徴の有効性を低減するように時間をかけて発展し、それ故に、デバイスの実際のセキュリティレベルの減少を引き起こすようにデバイスのこのようなセキュリティ特徴を知ることは重要である。アップグレードがなされなかった場合、デバイスのセキュリティ特徴は、デバイスのセキュリティレベルが最終的に時間を掛けて減少する間に関係がある。セキュリティ特徴を知ることによって、デバイスの適切なセキュリティレベルは、任意の所与の時間で決定され得る。さらに、デバイスのセキュリティ特徴を知ることによって、受信側は、デバイスの公開鍵が危うくなったかどうかの可能性を正しく判定することができ、デバイスの認証能力を知ることによって、受信側は、認証されたユーザ以外の誰かが、デジタル署名を生成するためにデバイスを利用したかどうかの可能性を正しく判定することができる。最後に、デバイスの製造履歴を知ることによってデバイスの安全特徴は、エラー、脱落、欠陥、セキュリティ侵害、または考えられる不適当などがデバイスの製造中に起きたこととして発見されるように、訂正され得る。
【００４６】
（Ａ．デジタル署名を生成するデバイスのＰｕＫリンクされた情報を識別する工程）
（１．第１の好適な実施形態）
本発明の第１の局面に従っておよび図１を参照して、第１の好適な実施形態は、安全な製造施設１０２、デバイス１０４によって表されるような施設１０２で製造されたデバイス、世界１０６、受信側１０８、および安全なエンティティ１１２によって維持される安全なデータベース１１０を含む第１の好適なシステム１００内で実行される。施設１０２および安全なデータベース１１０は、施設１０２で製造されたデバイス１０４の安全レベルを危うくするといけないので、十分な安全評定を有する任意の位置、および全ての位置を表す安全な環境１１４内に位置される。明白になるように、施設１０２および安全なデータベース１１０は、安全な環境１１４内になるために同じ物理的位置において同じ場所に配置される必要はない。このような可能性は本発明の範囲内であるが、デバイス１０２の製造者が安全なデータベース１１０を維持する安全なエンティティ１１２になる必要はない。
【００４７】
安全な環境１１４内で実施される関連した製造する工程は、図２に示される。図１および２を参照すると、一組の公開−秘密鍵は、施設１０２でデバイスの製造中に、およびデバイス１０４が安全な環境１１４から公開される以前にデバイス１０４内に生成される（工程２０２）。好ましくは、一組の公開−秘密鍵は、デバイス１０４内に置かれたランダムな数のジェネレータを用いて作成される。秘密鍵１１６（ＰｒＫ）は、デバイス１０４自体に保持される一方で、デバイス１０４が安全な環境１１４から公開される以前に、対応する公開鍵（ＰｕＫ）１１８は、デバイス１０４からエクスポートされ（工程２０４）、安全なデータベース１１０に記録される（工程２０６）。所望ならば、公開鍵１１８はまた、安全な環境１１４からデバイス１０４を公開した後で、後にオンデマンドでエクスポートするためにデバイス１０４内に保持され得る（図示せず）。秘密鍵１１６は、例えば、受信側１０８に通信されるメッセージ（Ｍ）のデジタル署名（ＤＳ）を生成中に利用される。公開鍵１１８に加えて、デバイス１０４のセキュリティプロフィール１２０は、安全なデータベース１１０に編集され、記録されて（工程２０８）、公開鍵１１８にインデックスを付けられる。それによって、セキュリティプロフィール１２０は、公開鍵１１８の認識に基づいて安全なデータベース１１０から取り戻せる。その結果、公開鍵１１８およびセキュリティプロフィール１２０は、共に安全にリンクされる。
【００４８】
公開鍵１１８およびデバイス１０４のセキュリティプロフィール１２０を有する安全なデータベース１１０の以下の集団について、デバイス１０４は、安全な環境１１４から世界１０６に公開される。しかし、安全なデータベース１１０は、安全な環境１１４で記録されたデータの統合性を保護するために安全な環境１１４に維持される（工程２１０）。さらに、以下の製造について、保証された環境１１４の安全な評定は、安全なデータベース１１０で維持される公開鍵１１８およびセキュリティプロフィール１２０の施設１０２で製造された各デバイス１０４の安全なレベルと少なくとも（好ましくは、より高い安全レベルで）比較できるようなレベルで維持される。
【００４９】
図３〜６をここで参照すると、デジタル署名（ＤＳ）は、世界１０６のどこかでメッセージ（Ｍ）に対して疑わしいデバイスで作成される（工程４０２）。疑わしいデバイスは、合法的に使用される、図１の施設１０２で製造された本物のデバイス１０４、不正に使用される本物のデバイス１０４、または本物のデバイス１０４の秘密鍵１１６の複製を有する偽造のデバイスになり得る。次に、デジタル署名は、ＥＣ１２２を形成するためにメッセージと組み合わされる（工程４０４）。ＥＣ１２２は、例えばインターネットまたはプライベートネットワークといった任意の従来の安全な、または安全でない電子通信ネットワークを介して受信側１０８に送信される（工程４０６）。
【００５０】
受信側１０８は、ＥＣ１２２を受信し（工程５０２）、疑わしいデバイスの公開鍵１２４を用いてメッセージを認証することを試みる（工程５０４）。疑わしいデバイスの公開鍵１２４は、受信側に提供され、好ましくは、受信側１０８によって受信されるＥＣ１２２内に含まれる。それによって、受信側１０８は、メッセージの認証を容易に試み得る。あるいは、疑わしいデバイスの公開鍵１２４は、疑わしいデバイスの公開鍵１２４と受信側１０８がＥＣ１２２とを結び付けることが可能であるこのような様態でＥＣ１２２の受信前、または受信後に受信側１０８に識別される。
【００５１】
任意のイベントにおいて、メッセージが疑わしいデバイスの公開鍵を用いてうまく認証し、メッセージが疑わしいデバイスの公開鍵１２４を用いて認証される第１のメッセージである場合、次に、受信側１０８は、疑わしいデバイスの公開鍵１２４を、安全なデータベース１１０をうまく処理して、公開鍵１２４に関連があるセキュリティプロフィールを要求する安全なエンティティ１１２に送信する（工程５０６）。受信側１０８と安全なエンティティ１１２との間の通信は、例えば、インターネットまたはプライベートネットワークといった従来の安全な、または安全でない電子通信ネットワークを手段としている。
【００５２】
安全なエンティティ１１２が受信側１０８から疑わしいデバイスの公開鍵１２４を受信すると（工程６０４）、安全なエンティティ１１２は、一致するかどうかを判定するために安全なデータベース１１０に維持されるエクスポートされた公開鍵と対照して疑わしいデバイスの公開鍵１２４を比較する（工程６０６）。一致が確認されると、次に、一致するエクスポートされた公開鍵と関連があるセキュリティプロフィールは、取り出されて、移動中の情報の整合性を維持するために安全なエンティティ１１２によってデジタルに署名される（工程６０８）。従って、セキュリティプロフィールおよびデジタル署名は、次に、受信側１０８に転送される「セキュリティ証明書」（ＳＣ）１２６を作成する。好適には、疑わしいデバイスの公開鍵１２４に一致する製造されたデバイス１０４の公開鍵１１８は、セキュリティ証明書１７６に関係がある公開鍵１１８の受信側１０８によって確認のためのセキュリティ証明書１２６に含まれる。
【００５３】
安全なエンティティ１１２からのセキュリティ証明書１２６を受信する（工程５０８）と、セキュリティ証明書１２６の認証は、安全なエンティティ１１２の公開鍵１２８（ＳＥ　ＰｕＫ）を用いてチェックされる（工程５１０）。安全なエンティティ１１２の公開鍵１２８は、好ましくは、予め受信側１０８に通信されている（工程６０２）。次に、うまく認証すると、認証されたセキュリティ証明書１２６に含まれるセキュリティプロフィールは、ＥＣ１２２のメッセージをデジタルに署名するために使用される秘密鍵１１６に属する本物のデバイス１０４のセキュリティプロフィール１２０として識別される。
【００５４】
従って、受信側１０８は、ＥＣ１２２のメッセージをデジタルに署名するための、本物のデバイス１０４の秘密鍵１１６の使用が識別されたセキュリティプロフィールに基づいた不正であったかどうかの可能性を正しく判定する。セキュリティ証明書１２６はまた、受信側１０８によって維持される「組織内」のデータベースに、受信側１０８によって記録される。それによって、将来のＥＣを認証するために使用される同様の疑わしいデバイスの公開鍵１２４は、セキュリティプロフィールの要求を安全なエンティティ１１２に送信することに対してというよりも、適切なセキュリティプロフィールを識別するためのこの「組織内」のデータベースに対して参照され得る。従って、セキュリティプロフィールが安全なエンティティ１１２によって更新されなかった場合、および更新されるまで、別の要求は必要とされない。
【００５５】
（２．第２の好適な実施形態）
簡単に説明すると、本発明の第１の局面の第２の好適な実施形態において、安全なエンティティは、安全な製造施設で製造された複数のデバイスの安全なエンティティにリンクされたデバイスの公開鍵を含むレファレンスおよびセキュリティプロフィールに対応するレファレンスを生成し、そのレファレンスを受信側に通信する。このレファレンスは、紙面または電子媒体で具現化され、製造されたデバイスのそれぞれの公開鍵によってインデックスを付けられた製造されたデバイスのセキュリティプロフィールのリストを含む。さらに、レファレンスは、好ましくは、安全なエンティティによってデジタルに署名される。それによって、受信側は、安全なエンティティの公開鍵を用いてうまく認証されるとレファレンスに含まれる情報に安全に信頼し得る。従って、受信側は、それぞれの疑わしいデバイスの公開鍵をセキュリティプロフィールの安全なエンティティに送信されるというよりも、メッセージをうまく認証するそれぞれの疑わしいデバイスの公開鍵を、そのレファレンスに含まれるデバイスの公開鍵に対して比較することのみを必要とする。故に、受信側は、メッセージをデジタルに署名するために使用される秘密鍵に属する本物のデバイスのセキュリティプロフィールを容易に識別することができる。
【００５６】
図７を特に参照し、この第２の好適な実施形態に従って、一組の公開−秘密鍵は、デバイスの製造中、およびデバイスが安全な環境７１４から除去される以前に各デバイス内に作成される（工程７０２）。各デバイスのそれぞれの公開鍵は、デバイス内に安全に保持される。それぞれの公開鍵は、各デバイスからエクスポートされ（工程７０４）、各デバイスのそれぞれのセキュリティプロフィールと共に安全なデータベースに記録される（工程７０６）。それぞれの公開鍵はまた、各デバイス内に保持され、オンデマンドでエクスポート可能であり得る。各セキュリティプロフィールは、それぞれのデバイスのエクスポートされた公開鍵を用いてインデックスを付けられ（工程７０８）、それによって、デバイスのセキュリティプロフィールは、公開鍵に基づいて安全なデータベースから取り出し可能である。公開鍵とともに安全なデータベースの集合に続いて安全なエンティティは、好ましくは、それぞれのデバイスについてリンクされるセキュリティプロフィールおよび公開鍵を含むレファレンスを作成して、デジタルに署名される（工程７１０）。当業者に理解されるように、工程７０２〜７１０の全ては、安全な環境７１４内で生じる。
【００５７】
安全な環境７１４からのデバイスの公開に従い、ここで図８〜１１を参照すると、デジタル署名は、疑わしいデバイスを用いて世界８０６のどこかでメッセージ（Ｍ）に対して作成される（工程９０２）。デジタル署名は、ＥＣ８２２を形成するためにメッセージと組み合わされる（工程９０４）。次に、ＥＣ８２２は、受信側８０８に送信される（工程９０６）。受信側８０８は、ＥＣ８２２を受信して（工程１００４）、ＥＣ８２２内に送信されるか、またはそうでなければ、受信側８０８に提供される疑わしいデバイスの公開鍵を用いてメッセージを認証することを試みる（工程１００６）。
【００５８】
メッセージの成功した認証に関して、受信側８０８は、疑わしいデバイスの公開鍵を、安全なエンティティ８１２によって作成されたレファレンス８３０に含まれる公開鍵に対して比較する。レファレンス８３０は、受信側８０８に転送され（工程１１０６）、好ましくは、ＥＣ８２２の受信の前に受信側８０８によって受信され、認証される（工程１００２）。さらに、受信側８０８がレファレンス８３０を認証し得るために、安全なエンティティ８１２の公開鍵８２８（ＳＥ　ＰｕＫ）はまた、好ましくは、予め安全な様態で通信される（工程１１０２）。従って、疑わしいデバイスの公開鍵がレファレンス８３０において公開鍵と一致する場合、メッセージをデジタルに署名するために使用される公開鍵に属する本物のデバイスのセキュリティプロフィールは、識別される。次に、受信側８０８は、識別されたセキュリティプロフィールに基づいて、本物のデバイスの公開鍵が、ＥＣ８２２のメッセージをデジタルに署名を付けられるように不正に使用された可能性を正しく判定することができる。
【００５９】
（３．第３の好適な実施形態）
第３の好適な実施形態において、セキュリティ証明書は、デバイス製造の安全な環境からの公開以前に製造されたデバイスに組み込まれる。この点において、図１２を参照すると、一組の鍵は、デバイスの製造中、および安全な環境１２１４からのデバイスの公開以前にデバイス内に作成される（工程１２０２）。秘密鍵は、デバイス内に安全に保持され、公開鍵は、デバイスからエクスポートされ（工程１２０４）、さらにデバイス内に保持され、オンデマンドでエクスポート可能である。エクスポートされた公開鍵は、デバイスのセキュリティプロフィールと組み合わされ、セキュリティ証明書を形成するために安全なエンティティによってデジタルに署名される（工程１２０６）。次に、セキュリティ証明書は、それ自体、デバイスにインポートされ（工程１２０８）、ＥＣに含むためにデジタル署名によってデバイスからエクスポート可能である。
【００６０】
従って、図１３〜１６を参照すると、疑わしいデバイスは、世界１３０６のどこかでメッセージ（Ｍ）に対するデジタル署名を作成する（工程１４０２）。次に、デバイスのデジタル署名およびセキュリティ証明書は、ＥＣ１３２２を形成するために、デバイスからエクスポートされ、メッセージと組み合わされる（工程１４０４）。次に、ＥＣ１３２２は、受信側１３０８に送信される（工程１４０６）。受信側１３０８によってＥＣ１３２２を受信すると（工程１５０４）、セキュリティ証明書で識別された疑わしいデバイスの公開鍵を用いてメッセージを認証し（工程１５０６）、安全なエンティティの公開鍵１３２８（好ましくは、安全なエンティティ１３１２によって通信され、予め受信側１３０８によって受信される）を用いて、セキュリティ証明書を認証する（工程１５０８）。うまく認証すると、その結果、デジタル署名を生成するために使用される公開鍵に属する本物のデバイスのセキュリティプロフィールは、受信側１３０８に識別される。識別されたセキュリティプロフィールに基づくと、受信側１３０８は、本物のデバイスの秘密鍵がＥＣ１３２２のメッセージをデジタルに署名するために不正に使用されたという可能性を正しく判定することができる。さらに、公開鍵が、安全な環境におけるデバイスの製造中に、セキュリティ証明書のときにセキュリティプロフィールと結びつけられるので、受信側１３０８は、実際に、本物のデバイスに対応するセキュリティ証明書を信頼することができる。
【００６１】
本発明の第１の局面による第３の好適な実施形態の利点は、受信側１３０８が疑わしいデバイスの公開鍵を安全なエンティティ１３１２に送信する必要性の排除、および安全なエンティティ１３１２が受信側１３０８に直接セキュリティプロフィールを伝送する必要性の排除を含む。確かに、この好適な方法に対する不利益は、セキュリティ証明書をデジタルに署名するために使用される安全なエンティティの秘密鍵が危うい場合、システム全体が危ういということである。
【００６２】
（４．好適な実施形態の改変）
本発明の第１の局面による第１および第２の好適な実施形態において、各デバイスのセキュリティプロフィールは、デバイスの公開鍵に対して安全なデータベースにインデックスを付けられ、公開鍵に基づいて安全なデータベースから取り出し可能である。これら２つの好適な実施形態の変化（図示せず）において、各デバイスのセキュリティプロフィールおよび公開鍵は、安全なデータベースに記録され、固有のデバイスの識別子にインデックスを付けられる。この固有のデバイスの識別子は、例えば、デバイスの製造中にデバイスに書き込まれた口座番号、またはデバイスの製造中にデバイス内に製造されたシリアル番号などを含み得る。デバイス識別子は、デバイスによって生成される各デジタル署名を含むためにデバイスからエクスポート可能である。デジタル署名およびデバイス識別子を含むＥＣを受信すると、次に、受信側は、公知のデータベースを有するデバイス識別子、または共にリンクされる公開鍵およびセキュリティプロフィールに対するレファレンスを相互参照することによって疑わしいデバイスの公開鍵を取得する。この点において、受信側は、疑わしいデバイスの公開鍵およびその代わりのセキュリティプロフィールを識別するため、デバイスの識別子を安全なエンティティに転送する。すなわち、受信側は、デバイス識別子によってインデックスを付けられた公開鍵およびリンクされたセキュリティプロフィールを含む安全なエンティティによって公開されたレファレンスにおいてデバイス識別子を比較する。方法論は、第１および第２の好適な実施形態で上述されたように類似しており、受信側が安全なエンティティに接するか、または受信したメッセージを認証することを試みる以前のレファレンスをチェックするかの主な違いがある。各デバイスのセキュリティプロフィールが公開鍵に対してインデックスを付けられる第１および第２の好適な実施形態において、メッセージが、メッセージに含まれる疑わしいデバイス公開鍵を用いて最初に認証する場合、受信側だけが、安全なエンティティに接するか、またはレファレンスをチェックする必要がある。
【００６３】
本発明のこの局面による第１、第２、および第３の好適な実施形態の改変において、安全なエンティティは、ＥＣを受信し、安全なエンティティ自体が、メッセージをデジタルに署名するために使用される公開鍵に属する本物のデバイスのセキュリティプロフィールを識別する。さらに、この場合におけるＥＣは、本物のデバイスの公開鍵がメッセージをデジタルに署名するために不正に使用されたという可能性を正しく判定するため、受信側によって、安全なエンティティに直接送信されるか、または安全なエンティティに転送され得るかのいずれかである。
【００６４】
好ましくは、図５〜６、図１０〜１１、および図１５〜１６に関して上で示された工程は、コンピュータ自動化され、各図のそれぞれの群のイベントの全体のシーケンスは、秒単位でなければ、分単位の大きさで小さい時間間隔内に生じる。
【００６５】
本発明の第１の局面による好適な実施形態の前述の詳細な記載を考慮すると、デバイス製造の安全な環境から公開する以前に、デバイス自体に各デバイスのそれぞれの一対の公開−秘密鍵を作成する工程と、デバイスから公開鍵のみをエクスポートし、エクスポートの可能性に対してデバイス内に秘密鍵を保持する工程と、デバイス製造の安全な環境内の他の情報と共にデバイスのエクスポートされた公開鍵を安全にリンクする工程とは、当業者によって理解される。故に、各デバイスは、他のデバイスの全てに関して固有性が提供される。さらに、デバイスが製造されるのは安全な環境であるため、および他の情報と公開鍵とを安全にリンクするため、第三者（例えば、将来の口座ソリティ）は、デバイスの実際の製造中に任意の制御または関与を有し得ないが、デバイスの独自性は、このような第三者に依存され得る。デバイスの製造環境内の各デバイスと公開鍵との安全な結合は、各デバイスが、デバイスに保持される秘密鍵、およびデバイスのみに保持される秘密鍵に基づいて認証され得るように、デバイスの独自性に依存するために必要とされる信頼を提供する。従って、本発明は、さらに、デバイスのこの製造プロセスを含む。
【００６６】
この製造プロセスの利点は、デバイスの製造場所から、デバイスが高いセキュリティレベル、通常利用されるレベルを用いずに、特定の口座ソリティについて初期化されるさらなる処理施設へ運搬するための能力を提供することである。例えば、特定の金融機関の初期化を目的とする処理施設へのクレジットカードおよびＩＣカードの送達を保護するために、装甲車およびガード（ａｒｍｏｒｅｄ　ｃａｒｓ　ａｎｄ　ｇｕａｒｄｓ）が通常用いられる。実際には、本発明の製造プロセスの結果として、特定の口座ソリティの利点においてさらなる処理が生じる施設は、ここで、デバイスの初期化以前に、および製造施設からのデバイスの運搬から独立して各デバイスを認証し得る。さらに、デバイスの製造にすぐに続く、およびその後に特定のデバイスを認証するための能力のため、異なる口座ソリティを用いて維持される複数の口座で取引をするための単一のデバイスを使用するシステムは、ここで、従来技術で発見されない限り、より高いレベルの信頼を用いてイネーブルされる。
【００６７】
（Ｂ．初期ＰｕＫリンクされた口座データベースを確立する）
本発明の第２の局面は、初期ＰｕＫリンクされた口座データベースを確立することを含み、部分的に本発明の第１の局面に基づく。この点について、上述したような複数の製造されたデバイス用のデータベースを確立することは、第三者の複数の顧客および／または消費者（本明細書では包括して「顧客」と呼ぶ）用の初期ＰｕＫリンクされた口座データベースを作成することに基づいて構築され得るデータベースを表す。上記デバイスの各々は、デバイスに関する公開鍵と他の情報とを含む独自の記録を有する。
【００６８】
特に図１７を参照すると、第三者１７３２は、複数の顧客１７３６の各々にサービスおよび／または商品１７３４を提供し、これに関連して顧客１７３６用の口座記録のデータベース１７３８を維持する。例えば第三者１７３２（本明細書では「口座オーソリティ」と呼ぶ）は、銀行、金融会社、または保険会社を含む金融機関、商人、インターネットサービスプロバイダ、テレコミュニケーションプロバイダ、医療プロバイダ、政府機関、または公益事業会社であり得るが、これらに限られない。口座データベース１７３８は典型的には、各顧客１７３６が口座オーソリティ１７３２に関係するごとに顧客単位で一度に１つの口座を確立する。顧客１７３６用の各データベース記録は典型的には、独自の口座番号によりデータベース１７３８内でインデックスを付けられる。
【００６９】
本発明の第２の局面によると、図１８に示すように、所定数のデバイス１８０４が、本発明の第１の局面の第１および第２の好適な実施形態による安全な環境１８１４で製造される。本発明の第２の局面によると、デバイス１８０４は口座オーソリティ１７３２の印をつけられる。安全なデータベース１８１０内の、デバイス１８０４に対応するデータベース記録１８４０は、口座オーソリティ１７３２と安全な様式１８１４’で通信される。印をつけられたデバイス１８０４はさらに、口座オーソリティ１７３２の顧客１７３６に配信される。
【００７０】
ＰｕＫリンクされたデータベース記録１８４０が口座オーソリティ１７３２によって受信されると、データベース記録１８４０は、口座オーソリティ１７３２用の初期ＰｕＫリンクされた口座データベースを表す。データベース記録１８４０は好適には、本発明の第１の局面の第１および第２の好適な実施形態に関して上述したように、デバイス１８０４の公開鍵１８１８とデバイス１８０４のセキュリティプロフィール１８２０とを含む。さらに、データベース記録１８４０は好適には、安全なエンティティ１８１２から口座オーソリティ１７３２への移送の際のセキュリティのために安全なエンティティ１８１２によってデジタル署名される。
【００７１】
図１９に、好適なデータベース記録１８４０の一例を示す。上記発明の背景の項で述べたように、セキュリティプロフィールは、デバイスのセキュリティ特徴、および例えばＳｍａｒｔ　Ｃａｒｄ　Ｐｒｏｔｅｃｔｉｏｎ　Ｐｒｏｆｉｌｅに特定されているようなデバイスの製造履歴を含む。デバイスの仕様は、例えばＦＩＰＳ　ＰＵＢＳ　１４０−１および１４０−２に記載されている。さらに、本発明の好適な実施形態によると、セキュリティプロフィールのセキュリティ特徴は、デバイスのセキュリティ特性および認証能力を含む。
【００７２】
口座オーソリティ１７３２は、ＰｕＫリンクされた口座データベース記録を一旦受け取ると、顧客１７３６の特定の情報および顧客の口座を用いて、ＰｕＫリンクされた口座データベース記録を更新する。しかし、特定の顧客の口座と初期ＰｕＫリンクされた口座データベース記録との間の関連づけがなされる前に、特定の顧客１７３６が上記顧客の口座に関して口座オーソリティ１７３２に対して認証されることが好ましい。したがって、口座データベース内の記録に関して顧客１７３６を認証するためにエンティティ認証技術が用いられる。このような認証技術は、特定の顧客１７３６に、記録内の特定の口座に関連した情報について尋ねること、または特定の顧客１７３６に対して、秘密のまたは他のエンティティ情報、例えば顧客の母親の結婚前の姓の提供を要求すること（ファクタＢエンティティ認証）を含み得る。
【００７３】
さらに、口座オーソリティ１７３２は好適には、顧客１７３６が正しいデバイス１８０４を受け取ったことを検証する。顧客１７３６によって受け取られたデバイス１８０４は、顧客１７３６がデバイス１８０４の秘密鍵でメッセージにデジタル署名し、メッセージとデジタル署名とをそれぞれのＥＣ１８２２で送信することによって識別される。ＥＣ１８２２は、ファクタＡ認証のために口座オーソリティ１７３２に送られる。口座オーソリティ１７３２は、好適にはＥＣ１８２２に含まれるデバイス１８０４の公開鍵を用いて、メッセージを認証する。さらに、メッセージが首尾よく認証されると、口座オーソリティ１７３２は、メッセージを首尾よく認証した公開鍵に対応する初期ＰｕＫリンクされた口座データベース内の記録を識別して、顧客１７３６用の口座と関連づける。
【００７４】
さらなるセキュリティが必要である場合、各デバイスは、機能する前にまず顧客によってエンタされなければならない初期化ＰＩＮを含み得る。初期化ＰＩＮが正しくエンタされると、その後各顧客は好適には個人化ＰＩＮをエンタする。個人化ＰＩＮは、例えばその後デバイスが用いられる毎にエンタされなければならない。初期化ＰＩＮは好適には、デバイスとは別個に顧客に配信される。さらに、各デバイスにおける初期化ＰＩＮおよび個人化ＰＩＮの使用は好適には、それぞれのデバイスの認証能力の一部として各データベース記録内に含まれる。
【００７５】
顧客が正しいカードを受け取ったことを検証する複数の技術もまた用いられ得る。例えば、各顧客は、デバイスと顧客の口座との関連づけを有効にするために、顧客自身の自宅から特定の番号を呼び出して各デバイスに印刷された番号を電話を介して入力することを要求し得る。
【００７６】
一旦十分な認証が完了すると、顧客特定情報がＰｕＫリンクされた口座データベース記録と、様々な方法で関連づけられ得る。第１に、初期ＰｕＫリンクされた口座データベース記録が、口座オーソリティによって維持されている顧客の、前から存在する口座データベースであって顧客特定情報を含むデータベースとマージされることが可能である。第２に、初期ＰｕＫリンクされた口座データベースが、顧客の前から存在する口座データベースであって顧客の特定情報を含むデータベースとは別に維持されるが、識別子によって上記口座データベースとしてインデックスを付けられることが可能である。第３に、口座オーソリティが単に、認証の後に顧客からの顧客特定情報を取得し、それに従ってＰｕＫリンクされた口座データベース記録を更新することが可能である。
【００７７】
本発明のこの第２の局面はさらに、口座オーソリティの新しい顧客用の口座を確立する際に有用である。この点について、デバイスは図１８に示す様式と同一の様式で配信されるが、配信先は現行の顧客ではなく、口座オーソリティの潜在的顧客である。しかしこの場合、前から存在する口座に関するエンティティ認証は不要である。なぜなら、潜在的顧客によって確立されるのは、新規口座だからである。しかし、ファクタＡエンティティ認証は、顧客を特定のＰｕＫリンクされた記録の１つと関連づける際には依然重要である。
【００７８】
新しい口座の確立に関して述べると、製造されたデバイスは「匿名」枠で顧客に配信され、商品および／またはサービスは、顧客特定情報とは無関係に顧客に提供される。すなわち、商品および／またはサービスは、デバイスの公開鍵によって識別されるようにデバイスベースで提供され、必ずしも顧客ベースでは提供されるわけではない。したがって、公開鍵によって識別された口座は、デバイスの１つによってデジタル署名されたメッセージの公開鍵で首尾よく認証されると、活性化され、それ以上何も必要としない。
【００７９】
他方、新規顧客は各々、顧客特定情報を「個人化」枠で口座オーソリティに提供する。口座オーソリティは、顧客特定情報をその顧客のデバイスに対応するＰｕＫリンクされたデータベース記録（デバイスの公開鍵によって識別されている）と関連づけることにより、初期ＰｕＫリンクされた口座データベースを更新する。この場合も口座オーソリティは、現行の口座に関連して新規顧客を認証する必要はない。
【００８０】
本発明の第２の局面による、初期ＰｕＫリンクされた口座データベースを確立する新しいビジネスメソッドの一例は、インターネットサービスプロバイダ（ＩＳＰ）用の新規顧客を確立することを含む。第１に、例えばドングルなどの複数の製造されたデバイスが、例えば本発明の第１の局面によって製造され、ＩＳＰの見込みのある複数の顧客にメールされる。各ドングルは、セットアップ用および見込みのある顧客のコンピュータをＩＳＰおよびインターネットに接続するソフトウェアを含むＣＤ−ＲＯＭと共にパッケージされる。ドングルおよびＣＤ−ＲＯＭはさらに、例えば雑誌のインサートとして配信され得る。見込みのある顧客は、ソフトウェアを受け取ると、自分のコンピュータにソフトウェアをインストールし、ドングルをコンピュータの適切なポートに取り付ける。その後コンピュータがＩＳＰと接続すると、ＥＣがＩＳＰに通信される。ＥＣは、ドングル内に保持されている秘密鍵とドングル内に保持されてドングルからエクスポートされる公開鍵とを用いて生成されたデジタル署名を含む。ＥＣを受け取ると、ＩＳＰはメッセージと共に含まれた公開鍵を用いてメッセージを認証する。認証が行われると、ＩＳＰは、受け取った公開鍵と初期ＰｕＫリンクされた口座データベース内のリンクされた公開鍵とを比較して両者がマッチするか否かを判断し、マッチする公開鍵を有する口座を活性化させる。口座記録は、ＩＳＰの広告的紹介として、例えば１００時間の無料インターネットサーフィンの提供を含み得る。この例では、顧客特定情報は不要であり、口座は匿名枠で提供される。
【００８１】
あるいは、新規口座を活性化させるために、ＩＳＰは、請求書の発行およびクレジットカードに関する情報を含む顧客特定情報を顧客に要求してもよい。上記情報が受け取られると、ＰｕＫリンクされた口座データベース内の識別された記録が、顧客特定情報を用いて更新され、口座が活性化される。その結果得られる、ＩＳＰの更新されたＰｕＫリンクされた口座データベース２０４０は、いくつかの口座を活性化した後は、例えば図２０のそれに似たものであり得る。
【００８２】
上記口座の活性化の後、口座は好適には、ＩＳＰに送信される各メッセージと共に含まれる、独自の口座識別子を割り当てられる。この口座識別子は、メッセージが関係している口座を識別する。ユーザＩＤまたは口座番号が、口座識別子として作用し得る。公開鍵がＰｕＫリンクされたデータベースに記録される。その結果、適切な口座記録が口座識別子を用いて識別されると、デジタル署名されたメッセージが、関連づけられた公開鍵を用いて認証されるようになる。あるいは、公開鍵自体が口座識別子として作用してもよい。いずれの場合も、デジタル署名されたメッセージが首尾よく認証されると（ファクタＡエンティティ認証）、ＩＳＰによってネットワークおよびインターネットへのアクセスが許可される。
【００８３】
本発明の第２の局面による、初期ＰｕＫリンクされた口座データベースの上述した確立を用いた新しいビジネスメソッドの別の例は、金融機関の現行の顧客にチェックカードとして用いられるＩＣカードを提供することを含む。例えば、本発明の第１の局面によって複数のＩＣカードが製造され、ＩＣカードをリクエストした金融機関の複数の現行の顧客にメールされる。製造されたＩＣカードは各々、初期化ＰＩＮを含む。初期化ＰＩＮは、ＩＣカードを口座に用いるために活性化するために、金融機関に送られなければならない。各初期化ＰＩＮは、対応するＩＣカードとは別個に各顧客にメールされる。さらに、各ＩＣカードは、メール先の顧客の口座番号を記録している。
【００８４】
安全なデータベースに記録されたＩＣカードのデータベース記録は、安全な様式で金融機関に送信される。データベース記録は、受信されると、ＰｕＫリンクされた口座データベースを表す。口座データベースはその後、金融機関によって維持されている前から存在する口座データベース内の顧客の記録により更新される、および／または上記記録とマージされる。その結果得られるデータベースは、ＰｕＫリンクされた口座データベースである。得られるＰｕＫリンクされた口座データベース２１４０は、例えば図２１のそれと似ているものであり得る。
【００８５】
各顧客がＩＣカードおよび初期化ＰＩＮを別々に受け取ると、顧客はまず、金融機関のＡＴＭ機でＩＣカードを用いる。これは、初期化ＰＩＮをエンタし、次いで顧客からのＰＩＮおよびＩＣカードからの口座番号を含むＥＣを金融機関に通信することによって行われる。ＥＣはＩＣカードでデジタル署名されている。金融機関は、ＥＣを受け取ると、ＥＣの送信側を認証する。これは、ＥＣ内の識別された口座番号から認可されたＰＩＮを取り出し、認可されたＰＩＮをＥＣで送信されたＰＩＮと比較することによって行われる。金融機関は同様に、識別された口座番号と関連づけられた公開鍵を用いて、メッセージを認証する。ＰＩＮが首尾よく検証されメッセージが首尾よく認証されると、金融機関は、記録内でＩＣカードを活性化し、口座用のチェックカードとして用いることができるようにする。さらに、ＩＣカードの活性化後、ＥＣ内の、口座に対する取引を表すメッセージはＩＣカードでデジタル署名さえされればよく、上記メッセージは顧客の口座番号を含む。このようなＥＣは、顧客の個人的な情報、例えば顧客の氏名、請求先住所、ＰＩＮなどを含む必要はない。
【００８６】
（Ｃ．ＰｕＫリンクされたデータベース記録を用いて複数の第三者口座を確立する）
本発明の第３の局面は、ＰｕＫリンクされたデータベース記録を用いて複数の第三者口座を確立することを含み、本発明の第１の局面の第１および第２の好適な実施形態に部分的に基づく。この点に関して、図２２を参照すると、デジタル署名を生成するデバイス２２０４が、安全な環境２２１４内で製造される。デバイス２２０４が安全な環境２２１４からリリースされる前に、デバイス２２０４の公開鍵２２１８と他の何らかの情報が、安全なデータベース２２１０内にデータベース記録２２７５として記録される。他の情報は好適には、本発明の第１の局面に関して上述したように、デバイス２２０４のセキュリティプロフィール２２２０を含む。デバイス２２０４はその後、顧客２２３２に配信され、顧客２２３２は、複数の所望の口座オーソリティ２２４２、２２４４、および２２４６の各々を用いて各口座を確立する。
【００８７】
本発明の第３の局面によると、顧客２２３２の各ＰｕＫリンクされた口座は、安全なデータベース２２１０から所望の口座オーソリティ２２４２、２２４４、および２２４６の各々へのＰｕＫリンクされたデータベース記録２２４８の通信に、少なくとも部分的に基づいて確立される。上述したように、ＰｕＫリンクされたデータベース記録２２４８は好適には、デバイス２２０４の公開鍵２２１８、および安全なエンティティ２２１２によって公開鍵２２１８にリンクされたセキュリティプロフィール２２２０を含む。さらに、データベース記録２２４８は安全な様式２２１４’で通信されることにより、データベース記録２２４８の完全性が保持される。
【００８８】
データベース記録２２４８のセキュリティプロフィール２２２０にリンクされた公開鍵２２１８は、対応する口座オーソリティ２２４２、２２４４および２２４６によって受け取られると、対応する口座オーソリティを有する顧客２２３２の初期ＰｕＫリンクされた口座データベース記録を表す。顧客２２３２が対応する口座オーソリティの現行の顧客である場合、初期ＰｕＫリンクされた口座データベース記録２２４８は好適には、顧客２２３２の現行の口座データベース記録と関連づけられる。しかし、安全なエンティティ２２１２から受け取ったＰｕＫリンクされた口座データベース記録２２４８を、顧客２２３２の現行の口座データベース記録と関連づけることは、好適には、顧客２２３２が正しいデバイス２２０４を受け取ったことが、本発明の第２の局面に関して上述した１以上の認証技術を介して検証された後にのみ行われる。
【００８９】
初期ＰｕＫリンクされた口座データベース記録が顧客２２３２の唯一の口座データベース記録を表す場合（すなわち、顧客が口座オーソリティにとって新規である場合）、顧客２２３２は個人化枠で、顧客特定情報を口座オーソリティに供給する。この供給は、顧客２２３２の初期ＰｕＫリンクされた口座データベース記録に記録するために行われる。匿名枠では、顧客特定情報は不要である。
【００９０】
さらに個人化枠では、顧客２２３２がデバイス２２０４を用いてデジタル署名されたメッセージを、対応するＥＣ２２２２で各口座オーソリティ２２４２、２２４４および２２４６に送信したとき、および、デジタル署名されたメッセージが、対応するＰｕＫリンクされた口座データベース記録２２４８と関連づけられた公開鍵を用いて、対応する口座オーソリティ２２４２、２２４４および２２４６によって認証されたときに、デバイス２２０４が活性化されて各口座で用いられるようになる。
【００９１】
匿名枠では、顧客２２３２がデジタル署名されたメッセージを対応するＥＣ２２２２でデバイス２２０４を用いて各口座オーソリティ２２４２、２２４４および２２４６に送信したとき、および、デジタル署名されたメッセージが、対応するＰｕＫリンクされた口座データベース記録２２４８と関連づけられた公開鍵を用いて、対応する口座オーソリティ２２４２、２２４４および２２４６によって認証されたときに、口座オーソリティ２２４２、２２４４および２２４６を用いて確立された各口座が活性化される。
【００９２】
（Ｄ．デジタル署名を生成するデバイスの識別された安全特性に基づいて取引に保険をかける）
本発明の第４の局面は、デジタル署名されたＥＣによって表される取引に保険をかけることを含む。さらに保険は好適には、取引毎に提供される。例えば、１顧客の口座から２５０，０００ドルを電信で送金することを指示するＥＣを受け取った、金融機関などの受信側は、ＥＣが認証されていても、ＥＣが不正でないことに対して保険をかけることを望むかもしれない。
【００９３】
このような取引に保険がかかっている場合、ＥＣのデジタル署名を生成するために用いられる秘密鍵が属するデバイスのセキュリティ特徴を確実に知ることが従来欠けていた。取引に保険をかけるエンティティ（「保険エンティティ」）はＥＣが不正に送信された可能性を判定しその可能性に基づいて請求すべきプレミアムを計算する。したがって、保険エンティティは、このような取引に高い保険をかけることを余儀なくされる。
【００９４】
本発明の第１の局面を鑑みると、ＥＣのデジタル署名を生成するために用いられる秘密鍵が属するデバイスのセキュリティ特徴は、確実に識別することができる。その上、デバイスの製造履歴もまた同時に確実に識別することができる。したがって、特定のデジタル署名されたＥＣが不正に送信された可能性は、より正確に判定される。それゆえ、このような保険に請求されるプレミアムは、知識が豊富であるためにより低くなり得、その結果、取引のリスクも低減し得る。さらに、知識がこのように豊富であるために、複数の取引に保険をかける、よりターゲットを絞ったプレミアム構造が生まれる。この構造では、デジタル署名を生成するデバイスの識別されたセキュリティ特徴が変化することに少なくとも部分的に基づいて、異なるレートが用いられる。
【００９５】
本発明の第４の局面の好適な実施形態が実施されるシステムを図２３に示す。このシステムでは、本発明の第１の局面による安全な環境２３０４内で、安全な製造施設２３０２において、複数のデバイス２３０４が製造される。デバイス２３０４の各々には秘密鍵が保持されている。これに対応する公開鍵２３１８は、安全なデータベース２３１０内のセキュリティプロフィール２３２０にリンクされている。安全なデータベース２３１０は、安全なエンティティ２３１２によって維持されている。製造後、デバイス２３０４は安全な環境２３１４から世界２３０６にリリースされる。デバイスの１つは最終的には、金融機関２３５０の顧客に到達し、金融機関２３５０に維持される顧客の口座と関連づけられる。
【００９６】
本発明の第４の局面の第１の好適な実施形態によると、図２４〜図２８に示すように、デジタル署名が生成される（ステップ２５０２）。このデジタル署名は、金融機関２３５０に維持されている顧客の口座から２５０，０００ドルを電信で送金するようにというリクエストを含むメッセージ用である。デジタル署名はメッセージと組み合わされて（ステップ２５０４）電信で送信されてＥＣ２３２２を形成する。ＥＣ２３２２はその後、世界２３０６のいずれかの場所から金融機関２３５０に送信される（ステップ２５０６）。ＥＣ２３２２は好適には、送金元の口座番号を含む。
【００９７】
ＥＣ２３２２を受け取ると（ステップ２６０２）、金融機関２３５０は、ＥＣ２３２２内で識別された口座と関連づけられた公開鍵を用いて、ＥＣ２３２２のメッセージを認証する（ステップ２６０４）。その後金融機関２３５０は、ＥＣ２３２２に含まれる指示に従うか否かを決定し、従う場合、ＥＣ２３２２によって表される取引に保険をかけるか否かを決定する。指示に従うか否かの決定は好適には、少なくとも部分的に、本発明の第１の局面によって識別されたセキュリティ特徴および製造履歴に基づく。
【００９８】
ＥＣ２３２２によって表される取引に保険をかけるという肯定的な決定がなされると、金融機関２３５０は、公開鍵と共にＥＣ２３２２を保険エンティティ２３５２に転送する（ステップ２６０６）。これを受け取ると（ステップ２７０２）、保険エンティティ２３５２は、公開鍵を用いてＥＣ２３２２のメッセージを認証する（ステップ２７０４）ことにより、メッセージの認証を確認する。首尾よく認証が行われると、保険エンティティ２３５２がセキュリティエンティティ２３１２に公開鍵を送信する（ステップ２７０６）。
【００９９】
セキュリティエンティティ２３１２は、公開鍵を受け取ると（ステップ２８０４）、公開鍵を、安全なデータベース２３１０内に維持された、リンクされた公開鍵と比較してマッチするか否かを調べる（ステップ２８０６）。マッチしている場合、マッチしている公開鍵にリンクされたセキュリティプロフィールが取り出され（ステップ２８０８）、移送中の情報の完全性を維持する目的で、安全なエンティティ２３１２によってデジタル署名される（これもまたステップ２８０８）。これによりセキュリティ証明書２３２６が形成される。セキュリティ証明書２３２６はその後保険エンティティ２３５２に送信される（ステップ２８１０）。好適には、マッチする公開鍵がセキュリティ証明書２３２６に含まれて、セキュリティ証明書２３２６が関連する公開鍵が保険エンティティ２３５２によって確認される。セキュリティ証明書２３２６が保険エンティティ２３５２によって受け取られると（ステップ２７０８）、セキュリティ証明書２３２６が真正であることが、安全なエンティティ２３２１の公開鍵２４２８（ＳＥ　ＰｕＫ）を用いて確認される（ステップ２７０８）。安全なエンティティ２３２１の公開鍵２４２８は、前もって保険エンティティ２３５２に通信されている（ステップ２８０２）ことが好ましい。その後、認証されたセキュリティ証明書２３２６に含まれるセキュリティプロフィールが、保険エンティティ２３５２によって、製造されたデバイスのセキュリティプロフィールであると識別される。上記製造されたデバイスには、ＥＣ２３２２のメッセージにデジタル署名する際に用いられた秘密鍵が属する。
【０１００】
識別されたセキュリティプロフィールに基づいて、保険エンティティ２３５２は、ＥＣ２３２２にデジタル署名する際に、製造されたデバイスの秘密鍵が不正に用いられた可能性を判定することができる。そして保険エンティティ２３５２は、取引を、対応するプレミアムレート用に分類することができる。その後取引の特定の分類に対応するプレミアムレートが、保険をかけようとする取引の金銭的価値（すなわち、この電信による送金の例では２５０，０００ドル）に適用され、問題の特定の取引に関して請求される実際のプレミアムが計算される。その後、保険がかけられたという確認２３５４が保険エンティティ２３５２によって、金融機関２３５０に送信される（ステップ２７１０）。保険の確認２３５４は好適には、識別されたセキュリティプロフィール、適用可能なプレミアムレート、およびＥＣ２３２２によって表される特定の取引に対して金融機関２３５０に請求される計算されたプレミアムを含む。保険の確認２３５４はさらに好適には、保険エンティティ２３５２によってデジタル署名されることにより、移送中の保険の確認２３５４の完全性が保持される。保険の確認２３５４が受け取られ認証されると（ステップ２６０８）、金融機関２３５０は、リクエストされた電信による送金２３５６を行う（ステップ２６１０）。
【０１０１】
本発明の第４の局面の第２の好適な実施形態では、第１の好適な実施形態同様、複数のデバイスが安全な環境で安全な製造施設で製造される。デバイスは各々、秘密鍵を保持し、対応する公開鍵が安全なエンティティによって維持されている安全なデータベース内のセキュリティプロフィールにリンクされている。製造後、デバイスは、安全な環境から世界に向けてリリースされる。デバイスの１つは最終的には、金融機関の顧客に到達し、金融機関に維持されている顧客の口座と関連づけられる。
【０１０２】
本発明の第４の局面の第２の実施形態では、第１の好適な実施形態とは異なり、図２９〜図３３に示すように、安全なエンティティ２９１２が、製造されたデバイスの公開鍵と対応するセキュリティプロフィールとを含むレファレンス２９３０を作成し保険エンティティ２９５２に通信する。安全なエンティティ２９１２は、図２４〜図２８に示す第１の好適な実施形態のように、製造されたデバイスの特定の１つの安全な証明書を送信するわけではない。保険エンティティ２９５２も、安全なデータベース２９１０からのセキュリティプロフィールを識別するために安全なエンティティ２９１２に公開鍵を送信するわけではない。
【０１０３】
特に一連のイベントに関して述べると、安全なエンティティ２９１２は、金融機関２９５０の口座と関連づけられた全デバイスの公開鍵およびリンクされたセキュリティ特徴を含むレファレンス２９３０を生成する（ステップ３３０４）。その後安全なエンティティ２９１２は、保険エンティティ２９５２にレファレンス２９３０を転送する（ステップ３３０６）。いずれのデバイスが金融機関２９５０の口座と関連しているかという情報は、本発明の第２および第３の局面の安全なエンティティ２９１２によって知られている。あるいは、上記情報は、金融機関２９５０または保険エンティティ２９５２のいずれかによって安全なエンティティ２９１２に対して識別される。レファレンス２９３０は好適には、本発明の第１の局面によって図７〜図１１に示すように収集される。レファレンス２９３０は好適には、安全なエンティティ２９１２によってデジタル署名されることにより、移送および格納中の情報の完全性を保持する。安全なエンティティ２９１２の公開鍵２９２８は、前もって安全な様式で保険エンティティ２９５２に通信されていることが好ましい。それを受け取ると（ステップ３２０２および３２０４）、保険エンティティ２９５２は、安全なエンティティ２９１２の公開鍵２９２８を用いてレファレンス２９３０を認証する（ステップ３２０６）。
【０１０４】
その後デジタル署名が、金融機関２９５０に維持される特定の口座番号に対する電信による送金に対するリクエストを含むメッセージ用に作成され（ステップ３００２）、上記メッセージと組み合わされて（ステップ３００４）、ＥＣ２９２２が形成される。ＥＣ２９２２はその後金融機関２９５０に送信される（ステップ３００６）。ＥＣ２９２２を受け取ると（ステップ３１０２）、金融機関２９５０は、ＥＣ２９２２内で識別された口座と関連づけられた公開鍵を用いてＥＣ２９２２のメッセージを認証する（ステップ３１０４）。その後金融機関２９５０は、ＥＣ２９２２に含まれる指示に従うか否かを決定し、従う場合には、ＥＣ２９２２によって表される取引に保険をかけるか否かを決定する。指示に従うか否かの決定は好適には、少なくとも部分的に、本発明の第１の局面によって識別されたセキュリティ特徴および製造履歴に基づく。
【０１０５】
ＥＣ２９２２によって表される取引に保険をかけるという肯定的な決定がなされると、金融機関２９５０は、公開鍵と共にＥＣ２９２２を保険エンティティ２９５２に転送する（ステップ３１０６）。ＥＣ２９２２を受け取ると（ステップ３２０８）、保険エンティティ２９５２は、公開鍵を用いてＥＣ２９２２のメッセージを認証する（ステップ３２１０）ことにより、メッセージの認証を確認する。首尾よく認証が行われると、保険エンティティ２９５２が、公開鍵を、レファレンス２９３０内のリンクされた公開鍵と比較してマッチするか否かを調べる。それにより、マッチする公開鍵とそれにリンクされたセキュリティプロフィールとを識別する（ステップ３２１２）。こうして識別されたセキュリティプロフィールは、ＥＣ２９２２のメッセージにデジタル署名する際に用いられた秘密鍵が属する、製造されたデバイスのセキュリティプロフィールを表す。
【０１０６】
識別されたセキュリティプロフィールに基づいて、保険エンティティ２９５２は、ＥＣ２９２２のメッセージにデジタル署名する際に、製造されたデバイスの秘密鍵が不正に用いられた可能性を判定することができる。そして保険エンティティ２９５２は、取引を、対応するプレミアムレート用に分類することができる。その後取引の特定の分類に対応するプレミアムレートが、保険をかけようとする取引の金銭的価値（すなわち、この電信による送金の例では２５０，０００ドル）に適用され、問題の特定の取引に関して請求される実際のプレミアムが計算される。その後、保険がかけられたという確認２９５４が保険エンティティ２９５２によって、金融機関２９５０に送信される（ステップ３２１４）。保険の確認２９５４は好適には、識別されたセキュリティプロフィール、適用可能なプレミアムレート、およびＥＣ２９２２の特定の取引に対して金融機関２９５０に請求されるプレミアムを含む。保険の確認２９５４はさらに好適には、保険エンティティ２９５２によってデジタル署名されることにより、移送中の保険の確認２９５４の完全性が保持される。保険の確認２９５４が受け取られ認証されると（ステップ３１０８）、金融機関２９５０は、リクエストされた電信による送金２９５６を行う（ステップ３１１０）。
【０１０７】
本発明の第４の局面の第２の好適な方法の変形例では、図３４〜図３８に示すように、安全なエンティティ３４１２が、レファレンス３４３０を、保険エンティティ３４５２ではなく、金融機関３４５０に通信する。レファレンス３４３０はその後金融機関３４５０によって保険エンティティ３４５２に転送される。この点以外は、ステップは、図２９〜図３３に示す、本発明の第４の局面の第２の方法について上述したものと同一である。
【０１０８】
具体的には、安全なエンティティ３４１２は、金融機関３４５０の口座と関連づけられた全デバイスの公開鍵およびリンクされたセキュリティ特徴を含むレファレンス３４３０を生成する（ステップ３８０２）。その後安全なエンティティ３４１２は、金融機関３４５０にレファレンス３４３０を送信する（ステップ３８０４）。これを受け取ると（ステップ３６０２）、金融機関３４５０は、レファレンス３４３０を保険エンティティ３４５２に転送する（ステップ３６０４）。そして安全なエンティティ３４１２は、確実な様式でその公開鍵３４２８を保険エンティティ３４５２に送信する（ステップ３８０６）。保険エンティティ３４５２は、レファレンス３４３０を受け取り（ステップ３７０２）かつ安全なエンティティ３４１２の公開鍵３４２８を受け取ると（ステップ３７０４）、レファレンス３４３０を認証する（ステップ３７０６）。
【０１０９】
その後デジタル署名が、電信による送金に関するメッセージ用に作成され（ステップ３５０２）、上記メッセージと組み合わされて（ステップ３５０４）、ＥＣ３４２２が形成される。ＥＣ３４２２はその後金融機関３４５０に送信される（ステップ３５０６）。ＥＣ３４２２を受け取ると（ステップ３６０６）、金融機関３４５０は、ＥＣ３４２２内で識別された、送信元の口座と関連づけられた公開鍵を用いてＥＣ３４２２のメッセージを認証する（ステップ３６０８）。その後金融機関３４５０は、ＥＣ３４２２に含まれる指示に従うか否かを決定し、従う場合には、ＥＣ３４２２によって表される取引に保険をかけるか否かを決定する。指示に従うか否かの決定は好適には、少なくとも部分的に、本発明の第１の局面によって識別されたセキュリティ特徴および製造履歴に基づく。
【０１１０】
ＥＣ３４２２によって表される取引に保険をかけるという肯定的な決定がなされると、金融機関３４５０は、公開鍵と共にＥＣ３４２２を保険エンティティ３４５２に転送する（ステップ３６１０）。ＥＣ３４２２を受け取ると（ステップ３７０８）、保険エンティティ３４５２は、公開鍵を用いてＥＣ３４２２のメッセージを認証する（ステップ３７１０）ことにより、メッセージの認証を確認する。首尾よく認証が行われると、保険エンティティ３４５２が、公開鍵を、レファレンス３４３０内のリンクされた公開鍵と比較してマッチするか否かを調べる。それにより、マッチする公開鍵とそれにリンクされたセキュリティプロフィールとを識別する（ステップ３７１２）。こうして識別されたセキュリティプロフィールは、ＥＣ３４２２のメッセージにデジタル署名する際に用いられた秘密鍵が属する、製造されたデバイスのセキュリティプロフィールを表す。
【０１１１】
識別されたセキュリティプロフィールに基づいて、保険エンティティ３４５２は、ＥＣ３４２２のメッセージにデジタル署名する際に、製造されたデバイスの秘密鍵が不正に用いられた可能性を判定することができる。そして保険エンティティ３４５２は、取引を、対応するプレミアムレート用に分類することができる。その後取引の特定の分類に対応するプレミアムレートが、保険をかけようとする取引の金銭的価値（すなわち、この電信による送金の例では２５０，０００ドル）に適用され、問題の特定の取引に関して請求される実際のプレミアムが計算される。その後、保険がかけられたという確認３４５４が保険エンティティ３４５２によって、金融機関３４５０に送信される（ステップ３７１４）。保険の確認３４５４は好適には、識別されたセキュリティプロフィール、適用可能なプレミアムレート、およびＥＣ３４２２の特定の取引に対して金融機関３４５０に請求されるプレミアムを含む。保険の確認３４５４はさらに好適には、保険エンティティ３４５２によってデジタル署名されることにより、移送中の保険の確認３４５４の完全性が保持される。保険の確認３４５４が受け取られ認証されると（ステップ３６１２）、金融機関３４５０は、リクエストされた電信による送金３４５６を行う（ステップ３６１４）。
【０１１２】
本発明の第４の局面の第３の好適な方法では、本発明の第１の局面の第３の好適な実施形態による安全な環境からデバイスがリリースされる前に、セキュリティ証明書が、製造されたデバイス自体に組み込まれる。従って、図３９〜図４３に示すように、疑わしいデバイスが世界３９０６のいずれかの場所でデジタル署名を作成する（ステップ４００２）とき、セキュリティ証明書がデジタル署名およびメッセージと共にＥＣ３９２２に含まれている（ステップ４００４）。ＥＣ３９２２はその後、金融機関３９５０に送信される（ステップ４００６）。ＥＣ３９２２が金融機関３９５０によって受け取られると（ステップ４１０２）、セキュリティ証明書内で識別された公開鍵を用いてメッセージが認証される（ステップ４１０４）。その後、取引に保険をかけることが望まれる場合、金融機関３９５０が保険エンティティ３９５２にＥＣ３９２２を転送する（ステップ４１０６）。指示に従うか否かの決定は好適には、少なくとも部分的に、本発明の第１の局面によってセキュリティ証明書内で識別されたセキュリティ特徴および製造履歴に基づく。
【０１１３】
ＥＣ３９２２を受け取ると（ステップ４２０４）、保険エンティティ３９５２はセキュリティ証明書内に含まれる公開鍵を用いてメッセージを認証し（ステップ４２０６）、メッセージの認証を確認する。保険エンティティ３９５２はさらに、安全なエンティティ３９１２の公開鍵３９２８を用いてセキュリティ証明書を認証する（ステップ４２０８）。安全なエンティティ３９１２の公開鍵３９２８は、前もって安全なエンティティ３９１２によって通信され（ステップ４３０２）保険エンティティ３９５２によって受け取られている（ステップ４２０２）ことが好ましい。これによりＥＣ３９２２のメッセージ用のデジタル署名を生成する際に用いられた秘密鍵が属する、製造されたデバイスのセキュリティプロフィールが保険エンティティ３９５２に対して識別される。
【０１１４】
識別されたセキュリティプロフィールに基づいて、保険エンティティ３９５２は、ＥＣ３９２２のメッセージにデジタル署名する際に、製造されたデバイスの秘密鍵が不正に用いられた可能性を判定することができる。そして保険エンティティ３９５２は、取引を、対応するプレミアムレート用に分類することができる。その後取引の分類に対応するプレミアムレートが、保険をかけようとする取引の金銭的価値（すなわち、この電信による送金の例では２５０，０００ドル）に適用され、問題の特定の取引に関して請求される実際のプレミアムが計算される。その後、保険がかけられたという確認３９５４が保険エンティティ３９５２によって、金融機関３９５０に送信される（ステップ３７１４）。保険の確認３９５４は好適には、識別されたセキュリティプロフィール、適用可能なプレミアムレート、およびＥＣ３９２２の特定の取引に対して金融機関３９５０に請求されるプレミアムを含む。保険の確認３９５４はさらに好適には、保険エンティティ３９５２によってデジタル署名されることにより、移送中の保険の確認３９５４の完全性が保持される。保険の確認３９５４が受け取られ認証されると（ステップ３６１２）、金融機関３９５０は、リクエストされた電信による送金３９５６を行う（ステップ３６１４）。
【０１１５】
本発明の第４のいずれの好適な方法においても、保険エンティティによる金融機関への実際の請求書の発行は、通常の予定期間、例えば月々、に行われる。さらに、各取引分類に対するプレミアムレートは好適には、金融機関と保険エンティティとの間で締結された予め用意された保険契約に従って決定される。この点について、取引時にデバイスが満たすセキュリティレベルが高ければ高いほど、プレミアムレートは低いべきである。さらに、ある期間に対して保険をかけられた全取引の保険の確認であって金融機関が受け取った保険の確認は、上記期間に保険エンティティが請求するプレミアム額を監視するために金融機関によって容易に利用され得る。
【０１１６】
好適には、図２６〜図２８，図３１〜図３３、図３６〜図３８、および図４１〜図４３を参照して上述したステップは、コンピュータによって自動化され、図の各セットに示されるステップの手順全体が、短い時間内、数秒とまではいかなくとも少なくとも数分以内になされる。
【０１１７】
保険は、取引ベースではなく、ある制限が設けられるという条件でデバイス毎にかけてもよい。この場合、取引ベースに保険をかける上述の方法とは異なり、各ＥＣは保険エンティティには送信されない。この場合、保険は口座オーソリティ（例えば金融機関など）に提供されて、デジタル署名されたメッセージを送信する、口座オーソリティの顧客が取引する。本発明の第４の局面によると、各メッセージは、本発明の第１の局面によって製造されたデバイスの保持された秘密鍵を用いてデジタル署名される。上記製造されたデバイスに関しては、セキュリティプロフィールなどの情報が確実に識別される。例えば、本発明の第２または第３の局面によって確立された、顧客のＰｕＫリンクされた口座データベースであってＰｕＫリンクされた口座データベース記録内の識別されたセキュリティプロフィールを含む口座データベース、を維持する金融機関が、本発明の第４の局面による顧客の全デバイスに対する保険を取得してもよい。保険が各デバイスに提供されるプレミアムは、各デバイスの公開鍵がリンクされている、デバイスの識別されたセキュリティプロフィールに少なくとも部分的に基づく。本発明の第１の局面によって提供される、各デバイスのセキュリティプロフィールを確実に知る能力のおかげで、デバイスに関連づけられ得るリスクのレベルを差を反映して、デバイス間で請求されるプレミアムに差をつけることができる。
【０１１８】
（Ｅ．口座のＥＣが不正であるか否かをデジタル署名を生成するＰｕＫリンクされた情報にもとづいて判定する）
本発明の第５の局面は、口座に対する取引を表しデバイスでデジタル署名されたＥＣのメッセージが不正であるという可能性を判定すること、およびそれに基づいて取引を行うべきか否かを決定することを含む。上記可能性の判定は、製造時にデバイスの公開鍵に確実にリンクされていた識別された情報に基づき、好適には本発明の第１の局面を組み込む。上記情報は、デバイスのセキュリティ特徴と製造履歴とを含む。上記可能性の判定は追加の要素にも基づき、追加の要素は、公開鍵を用いて認証されたデジタル署名の取引口座履歴、ＥＣ用のデジタル署名が作成された環境、ならびに口座特定および事業特定要素を含む。口座特定および事業特定要素とは、例えば、取引が口座に対しても行われるか否かということである。
【０１１９】
図４４に、本発明の第５の局面による、複数のユーザのために口座オーソリティによって維持される口座データベースの一例を示す。この口座データベースは、図２１の口座データベースに対応し、各口座に関する「取引履歴」および「ＰｕＫ−口座認証」情報がセキュリティプロフィールと共に口座記録に追加されることにより「リスク管理情報」を形成する。デバイスのセキュリティ特徴および製造履歴、ならびにそれにリンクされた公開鍵は、本発明の第１、第２および第３の局面に関連して上述した口座オーソリティと関連づけられており、口座オーソリティによって取得され得る。あるいは、デバイスのセキュリティ特徴および製造履歴、ならびにそれにリンクされた公開鍵は、口座オーソリティによって信頼できると考えられる任意の他のプロセスを介して取得され得る。
【０１２０】
取引口座履歴は、口座オーソリティによって口座に記録され、好適には、デジタル署名されたＥＣが受け取られる。具体的には、口座オーソリティが各ＥＣの取引詳細を口座記録内に記録する。取引履歴は、使用の地理的位置、取引額、および取引の頻度などの要素を含み得る。これらはすべて、口座オーソリティによって追跡および評価されて、不正が行われているか否かが監視される。デバイスのユーザを認証するために用いられる秘密の又はバイオメトリックな特性を表すデータが誤ってエンタされた回数などの情報が、口座オーソリティによって監視され得る。口座オーソリティは不正の可能性があることを示すためにも作用する。
【０１２１】
ＰｕＫ−口座認証は、公開鍵とＰｕＫリンクされた情報とが口座オーソリティによって維持される口座と関連づけられたときに採用される認証技術である。この情報は、公開鍵およびＰｕＫリンクされた情報を口座と最初に関連づける際に生じ得るリスクを評価する際に重要である。
【０１２２】
さらに本発明の第５の局面によると、口座オーソリティは、メッセージ用のデジタル署名が作成された環境に関して知られている全ての要素を記録する。実際、デバイスがしばしば用いられる環境は、ＥＣ自体で通信される。例えば、クレジットの請求を含む金融取引において、発行銀行などの口座オーソリティは、取引のための販売時点においてカードが存在していたか否か、または、請求がその他の方法、例えばインターネットを介してなど、で行われたか否かを決定することができる。前者の場合は、後者の場合よりも不正の可能性がはるかに低いと考えられる。別の例では、Ｉ／Ｏサポートエレメントなどの外部装置がデバイスと共に用いられてメッセージを構成しデジタル署名を作成した場合、Ｉ／Ｏサポートエレメントに関する情報は好適にはＥＣで通信される環境情報に含まれる。例えば、Ｉ／ＯサポートエレメントがさらにＥＣにデジタル署名してもよく、Ｉ／Ｏサポートエレメントの公開鍵にリンクされた、Ｉ／Ｏサポートエレメント関連情報は好適には、本発明の第１の局面に従って識別される。実際、デバイスは、ハードウェアコンポーネントとソフトウェアコンポーネントとを含むカードリーダを含み得る。ハードウェアコンポーネントおよびソフトウェアコンポーネントは、周知の金融取引ＩＣカードリーダプロジェクト（「ＦＩＮＲＥＡＤ」として一般に知られている）の結果、ＣＥＮ／ＩＳＳＳによって公開されている技術仕様に従って設計されている。
【０１２３】
本発明の本局面の好適な実施形態を図４５に示す。ここでは、口座オーソリティが、メッセージとメッセージ用のデジタル署名とを含むＥＣを受け取る（ステップ４５０２）。デジタル署名されたメッセージは、ＥＣ内で独自の口座番号によって識別された特定の口座に対する取引を表す指示を含む。これが受け取られると、口座オーソリティは、特定の口座と関連づけられた公開鍵を取り出し（ステップ４５０４）、次いで公開鍵を用いてＥＣのメッセージを認証する（ステップ４５０６）ことを試みる。ステップ４５０８においてメッセージが認証されなかった場合、口座オーソリティはメッセージを拒否する（ステップ４５１０）。ステップ４５０８においてメッセージが認証された場合、口座オーソリティはさらにメッセージを処理する（ステップ４５１２）。
【０１２４】
メッセージのさらなる処理（ステップ４５１２）は、デジタル署名が不正に生成された可能性を判定し、最終的にその口座に対する取引を行うべきか否かを決定するために口座オーソリティが用いる多くの要素を考慮すること（ステップ４５１４）を含む。考慮すること（ステップ４５１４）は、デバイスの製造環境内でデバイスの公開鍵にリンクされているデバイスのセキュリティ特徴と製造履歴とを適用可能であると評価すること（ステップ４５１６）、ＥＣの送信側またはデバイスのユーザによって提供されたエンティティ認証を評価すること（ステップ４５１８）、ＥＣの作成を巡る環境要素を評価すること（ステップ４５２０）、口座に対するデバイスの取引履歴を評価すること（ステップ４５２２）、その他の口座特定または事業特定要素を評価すること（ステップ４５２４）を含む。最も基本的なレベルでは、ＰｕＫ−口座認証もまた、不正の可能性を判定する際に考慮され得る。
【０１２５】
口座オーソリティが上記要素の一部または全部を考慮するか否かということ、口座オーソリティが特定の要素にどれだけの重きを置くかということ、口座オーソリティがこれらの評価をどの順で行うかということは条件次第で変わり得る。口座オーソリティは、それ自体のビジネスルールおよび判断を用いて、ステップ４５１４でのそれ自体の考慮点に基づいて、口座に対する取引を行うか否かを決定する（ステップ４５２６）。ステップ４５２６の決定が否定的なものである場合、口座オーソリティはメッセージを拒否する（ステップ４５１０）。ステップ４５２６の決定が肯定的なものである場合、口座オーソリティは口座に対する取引を行い（ステップ４５２８）、それに従って口座記録を更新する（ステップ４５３０）。あるいは、口座オーソリティは、その考慮点（ステップ４５１４）に基づいて指示の限られた部分（図示せず）のみを実行することを選択し得る。または、口座オーソリティは、取引を行う前に（図示せず）ＥＣの送信側に追加の情報を要求し得る。
【０１２６】
本発明の１つの特徴として、複数の異なるデバイスが、口座オーソリティで維持される同一のユーザ口座と関連づけられる。この場合、不正取引のリスクは、口座全体をベースとするのではなく、各口座についてデバイス毎に判定されることが好ましい。特に、口座に対するデジタル署名の取引履歴が記録され、後にデバイスべースで考慮されることが好ましい。
【０１２７】
もちろん、各口座オーソリティが用いる実際のルールベースまたはビジネスロジックは主観的なものであり、必然的に口座オーソリティ間で異なる。しかし、デバイスのセキュリティ特徴および製造履歴の確実な識別は、デバイスによって生成されたデジタル署名の取引口座履歴の評価、デジタル署名が作成される環境要素、および他の口座特定または事業特定要素と組み合わされたときに、これ以外の方法では実現されない、不正取引に対する追加のセキュリティを提供する。
【０１２８】
（Ｆ．デジタル署名を生成するデバイスの、ＰｕＫリンクされた情報を配布する）
本発明の第６の局面によると、エンティティ（本明細書では、「中央鍵オーソリティ」と呼ぶ）が、ユーザのＰｕＫリンクされた口座情報（本明細書では、「登録情報」と呼ぶ）を維持して、１以上の口座オーソリティに配布する。登録情報は、デジタル署名を生成するユーザのデバイスの公開鍵（ＰｕＫ）と、以下のタイプの情報の１以上を含む：ユーザがデバイス用のＰｕＫリンクされた口座を有する口座オーソリティのアイデンティティと、ユーザの各ＰｕＫリンクされた口座のアイデンティティを、対応する口座オーソリティに対して識別する口座識別子；本発明の第１の局面によるデバイスの公開鍵にリンクされた情報；ユーザの郵送先住所、クレジットカード情報、年齢などのユーザ特定情報；および所望であれば、中央鍵オーソリティによって維持されるユーザ特定情報を検証する際に採用された認証技術。さらに、中央鍵オーソリティは好適には、ユーザの登録情報を独自の口座識別子を用いてインデックスを付け、登録情報が口座識別子に基づいて取り出され得るようにする。この点について、図示はしないが、公開鍵は、独自の識別子として作用し得る。中央鍵オーソリティのＰｕＫリンクされた口座データベース４６４０の一例を図４６に示す。
【０１２９】
本発明の本局面によると、中央鍵オーソリティは、登録情報の一部または全部を適切なものとして口座オーソリティに配布する。登録情報は、ユーザが口座オーソリティに口座を有しているとき、または口座オーソリティに口座を確立したいと望むとき、そしてメッセージを有するＥＣを送信したいと望むときに、配布される。上記メッセージは各々、口座に対する取引を表す指示を含み、各メッセージはデバイスでデジタル署名されている。登録情報の配布は、例えば、口座オーソリティによって維持される登録情報の有効期限が特定の口座で切れたときに起こる。さらに登録情報の配布は、本発明の第３の局面に従って起こりえる。その場合、中央鍵オーソリティが安全なエンティティとしての資格を得るに十分なセキュリティ手段およびプロトコルを有していると考えられた場合に、ＰｕＫリンクされた口座データベース記録が中央鍵オーソリティから取得される。
【０１３０】
中央鍵オーソリティによって維持される登録情報は、様々な方法で取得される。例えば、公開鍵およびそれにリンクされた情報は好適には、本発明の第１、第２および第３の局面に従って安全なエンティティから取得される。ユーザがデバイス用のＰｕＫリンクされた口座を有する口座オーソリティのアイデンティティ、およびこのような口座オーソリティに対してユーザのＰｕＫリンクされた口座を識別する口座識別子は、好適には、ユーザから取得され、ユーザが中央鍵オーソリティに登録したとき、ユーザの指示により中央鍵オーソリティがユーザに代わって口座オーソリティに口座を確立したとき、または、ユーザの指示により第三者が中央鍵オーソリティから登録情報を獲得したときに、取得される。
【０１３１】
本発明の第６の局面に従って、中央鍵オーソリティによって提供され得る効率および便利さの一例は、デバイスのそれぞれの公開鍵によって表されるユーザの古い（そしておそらく有効期限の切れた）デバイスではなくユーザの新しいデバイスを用いてユーザのＰｕＫリンクされた口座を更新することを含む。図４７〜図５１を参照すると、このような更新は好適には、ユーザ４７５８が単にＥＣ４７２２を中央鍵オーソリティ４７６０に送信する（ステップ４８０６）だけで達成される。中央鍵オーソリティ４７６０は、ユーザ４７５８が以前、古い公開鍵（ＰｕＫ１）によって表される古いデバイスで登録していたオーソリティである。
【０１３２】
ＥＣ４７２２は、新しい公開鍵（ＰｕＫ２）を、ある口座オーソリティ４７６２、４７６４によって維持されている、ユーザ４７５８の口座と関連づけるようにという指示を有するメッセージ（Ｍ）を含む。新しい公開鍵（ＰｕＫ２）はメッセージに含まれている。口座オーソリティ４７６２、４７６４は好適には、中央鍵オーソリティ４７６０に登録されている。メッセージは秘密鍵（ＰｒＫ１）を用いてデジタル署名され（ステップ４８０２）、そのデジタル署名（ＤＳ）は、メッセージと共にＥＣ４７２２内に含まれる（ステップ４８０４）。ＥＣ４７２２はさらに、中央鍵オーソリティ４７６０によって維持される口座用の口座識別子（ＣＫＡ＃）を含む。
【０１３３】
ＥＣ４７２２を受け取ると（ステップ４９０２）、中央鍵オーソリティ４７６０は、ＥＣ４７２２のメッセージ（Ｍ）を認証する（ステップ４９０４）。この認証は、中央鍵オーソリティ４７６０によって維持され、且つ、独自の口座識別子（ＣＫＡ＃）によって識別される、ユーザ４７５８の口座と関連づけられた公開鍵（ＰｕＫ１）を用いて行われる。
【０１３４】
首尾よく認証が行われると、中央鍵オーソリティ４７６０は、新しい公開鍵（ＰｕＫ２）を用いて登録情報を更新し（ステップ４９０６）、それぞれのＥＣ４７６６、４７６８を、ユーザ４７５８によって識別された口座オーソリティ４７６２、４７６４に送信する（ステップ４９０８）。各ＥＣ４７６２、４７６４は、新しい公開鍵（ＰｕＫ２）をユーザ４７５８の口座と関連づけるようにという、口座オーソリティ４７６２、４７６４の各リクエストを含む。中央鍵オーソリティ４７６０はさらに好適には、本発明の第１の局面により、新しい公開鍵（ＰｕＫ２）にリンクされたセキュリティプロフィールを取得し、口座オーソリティ４７６２、４７６４に送信された各リクエスト内に、新しい公開鍵（ＰｕＫ２）と共にセキュリティプロフィールを含む。
【０１３５】
リクエストは、中央鍵オーソリティ４７６０の秘密鍵を用いてデジタル署名され（ステップ４９０８）、各口座オーソリティ４７６２、４７６４がリクエストとその中の情報とを認証できるようになっていることが好ましい。リクエストは、ユーザ４７５８から中央鍵オーソリティ４７６０によって受け取られたＥＣ４７２２を含み得る。各リクエストはさらに好適には、各口座オーソリティ４７６２、４７６４によって更新されるべき口座用の適切な口座識別子を含み、この情報は、中央鍵オーソリティ４７６０によって維持される登録情報の一部である。
【０１３６】
ＥＣ４７６６が口座オーソリティ４７６２によって受け取られると（ステップ５００２）、リクエスト（Ｒ１）は、中央鍵オーソリティ４７６０の公開鍵を用いて認証される（ステップ５００４）。中央鍵オーソリティ４７６０の公開鍵は、前もって口座オーソリティ４７６２によって取得されていることが好ましい。口座オーソリティ４７６２はさらに、所望であれば、ＥＣ４７２２内のオリジナルメッセージ（Ｍ）を認証し得る。首尾よく認証が行われると、口座オーソリティ４７６２は、新しい公開鍵（ＰｕＫ２）を口座と関連づけることにより、ＥＣ４７６６内の口座識別子（Ａｃｃ＃）によって識別された口座を更新する（ステップ５００６）。
【０１３７】
同様に、ＥＣ４７６８が口座オーソリティ４７６４によって受け取られると（ステップ５１０２）、リクエスト（Ｒ２）が、中央鍵オーソリティ４７６０の公開鍵を用いて認証される（ステップ５１０４）。中央鍵オーソリティ４７６０の公開鍵は、前もって口座オーソリティ４７６４によって取得されていることが好ましい。口座オーソリティ４７６４はさらに、所望であれば、ＥＣ４７２２内のオリジナルメッセージ（Ｍ）を認証する。首尾よく認証が行われると、口座オーソリティ４７６４は、新しい公開鍵（ＰｕＫ２）を口座と関連づけることにより、ＥＣ４７６８内の口座識別子（Ａｃｃ＃）によって識別された口座を更新する（ステップ５１０６）。
【０１３８】
当業者には理解されるように、図４７〜図５１の好適な方法には２つの口座オーソリティが示されているが、適切かつ所望であれば、中央鍵オーソリティによってＥＣを送信される口座オーソリティの数に制限はない。実際、コンタクトされる口座オーソリティの数が多ければ多いほど、本発明の第６の局面による好適な方法はより効率的であり、より便利である。
【０１３９】
従って、本発明の好適な実施形態、デバイス、および方法の上述した詳細な説明を鑑みると、本発明は広範囲の利用性および応用が可能であることが当業者には理解される。本明細書に記載したもの以外の、本発明の多くの方法、実施形態および応用、ならびに多くの改変、変更、および均等な構成が、本発明の実体および範囲から逸脱することなく、本発明および以下の詳細な説明から明らかであるか、当然に導き出される。さらに当業者であれば理解するが、様々なプロセスのステップがいくつかの例で、好適なシーケンスまたは時間的順序で実行されるものとして示され記載されているが、このようなプロセスのステップは必ずしも、このような特定のシーケンスまたは順序で実行されることに限られない。むしろ多くの例では、本明細書に記載したプロセスのステップは、様々な異なるシーケンスおよび順序で実行され得るが、これらも本発明の範囲内に含まれる。従って、本明細書では本発明を好適な方法およびデバイスに関連して記載しているが、この詳細な説明は本発明を説明および例示するためだけのものであり、本発明の完全な、かつ本発明を実施可能にする開示を提供する目的のためだけになされていることが理解されるべきである。本明細書で上述された詳細な説明は、本発明を限定すること、および他の実施形態、応用、改変、変更、均等な構成を排除することを意図するものではない。本発明は、特許請求の範囲およびその均等物によってのみ限定される。
【０１４０】
例えば、本発明によると、安全な製造施設、安全なエンティティ、口座オーソリティ、金融機関、保険エンティティ、および中央鍵オーソリティに関して上述した役割は、すべて単一のエンティティまたは関連するエンティティ、あるいはその組み合わせによって果たされてもよい。さらに、上記エンティティのいずれもがＥＣの受取側であってもよい。
【０１４１】
さらに、本発明に関して上述したデバイスは、例えば、デジタル署名を生成する商人または他の商業的エンティティのデバイスを含み、デジタル署名を生成する個人消費者のデバイスに限られない。例えば、本発明によるデバイスは、Ｉ／Ｏサポートエレメントを含み、Ｉ／Ｏサポートエレメントは、例えば、安全な金融取引を確立する際に個人消費者のＩＣカードを読み取るために用いられるＩＣカードリーダを含む。但しこれは、ＩＣカードリーダ自体がデジタル署名を生成する場合である。この点について、このようなデバイスは、信頼できるプラットフォームモジュールを含み得る。
【図面の簡単な説明】
【図１】図１は、本発明の第１の局面の第１の好適な方法が実行される好適なシステムを示す。
【図２】図２は、本発明の第１の局面の第１の好適な方法に従って安全な環境内で実施される工程のフローチャートを示す。
【図３】図３は、本発明の第１の局面の第１の好適な方法に従ってデバイスのセキュリティプロフィールを識別する通信シーケンスを示す。
【図４】図４は、本発明の第１の局面の第１の好適な方法に従ってＥＣのデジタル署名を作成する疑わしいデバイスによって実施される工程のフローチャートを示す。
【図５】図５は、本発明の第１の局面の第１の好適な方法に従って受信側によって実施される工程のフローチャートを示す。
【図６】図６は、本発明の第１の局面の第１の好適な方法に従って安全なエンティティによって実施される工程のフローチャートを示す。
【図７】図７は、本発明の第１の局面の第２の好適な方法に従って安全な環境内で実行される工程のフローチャートを示す。
【図８】図８は、本発明の第１の局面の第２の好適な方法に従ってデバイスのセキュリティプロフィールを識別する際の通信シーケンスを示す。
【図９】図９は、本発明の第１の局面の第２の好適な方法に従ってＥＣのデジタル署名を作成する疑わしいデバイスによって実施される工程のフローチャートを示す。
【図１０】図１０は、本発明の第１の局面の第２の好適な方法に従って受信側によって実施される工程のフローチャートを示す。
【図１１】図１１は、本発明の第１の局面の第２の好適な方法に従って安全なエンティティによって実施される工程のフローチャートを示す。
【図１２】図１２は、本発明の第１の局面の第３の好適な方法に従って安全な環境内で実行される工程のフローチャートを示す。
【図１３】図１３は、本発明の第１の局面の第３の好適な方法に従ってデバイスのセキュリティプロフィールを識別する際の通信シーケンスを示す。
【図１４】図１４は、本発明の第１の局面の第３の好適な方法に従ってＥＣのデジタル署名を作成する疑わしいデバイスによって実施される工程のフローチャートを示す。
【図１５】図１５は、本発明の第１の局面の第３の好適な方法に従って受信側によって実施される工程のフローチャートを示す。
【図１６】図１６は、本発明の第１の局面の第３の好適な方法に従って安全なエンティティによって実施される工程のフローチャートを示す。
【図１７】図１７は、第三者が、顧客に商品および／またはサービスを提供し、それらと共に顧客の口座データベースを維持する、本発明の第２の局面に関連したシステムを示す。
【図１８】図１８は、本発明の第２の局面の好適な方法が実行される好適なシステムを示す。
【図１９】図１９は、本発明の第２の局面の好適な方法に従う初期のＰｕＫリンクされた口座データベースのデータベース記録を示す。
【図２０】図２０は、インターネットサービスプロバイダを表す第三者によって更新され、および／または併合された後に、図１９のデータベース記録を含むＰｕＫリンクされた口座データベースを示す。
【図２１】図２１は、金融機関を表す第三者によって更新され、および／または併合された後に、図１９のデータベース記録を含むＰｕＫリンクされた口座データベースを示す。
【図２２】図２２は、本発明の第３の局面の好適な方法が実行される好適なシステムを示す。
【図２３】図２３は、本発明の第４の局面の第１の好適な方法が実行される好適なシステムを示す。
【図２４】図２４は、本発明の第４の局面の第１の好適な方法に従う通信シーケンスを示す。
【図２５】図２５は、本発明の第４の局面の第１の好適な方法に従ってＥＣのデジタル署名を作成する疑わしいデバイスによって実施される工程のフローチャートを示す。
【図２６】図２６は、本発明の第４の局面の第１の好適な方法に従って金融機関によって実施される工程のフローチャートを示す。
【図２７】図２７は、本発明の第４の局面の第１の好適な方法に従って保険引受エンティティによって実施される工程のフローチャートを示す。
【図２８】図２８は、本発明の第４の局面の第１の好適な方法に従って安全エンティティによって実施される工程のフローチャートを示す。
【図２９】図２９は、本発明の第４の局面の第２の好適な方法に従う通信シーケンスを示す。
【図３０】図３０は、本発明の第４の局面の第２の好適な方法に従ってＥＣのデジタル署名を作成する疑わしいデバイスによって実施される工程のフローチャートを示す。
【図３１】図３１は、本発明の第４の局面の第２の好適な方法に従って金融機関によって実施される工程のフローチャートを示す。
【図３２】図３２は、本発明の第４の局面の第２の好適な方法に従って保険引受エンティティによって実施される工程のフローチャートを示す。
【図３３】図３３は、本発明の第４の局面の第２の好適な方法に従う安全なエンティティによって実施される工程のフローチャートを示す。
【図３４】図３４は、本発明の第４の局面の第３の好適な方法に従って通信シーケンスを示す。
【図３５】図３５は、本発明の第４の局面の第３の好適な方法に従ってＥＣのデジタル署名を作成する疑わしいデバイスによって実施される工程のフローチャートを示す。
【図３６】図３６は、本発明の第４の局面の第２の好適な方法に従って金融機関によって実施される工程のフローチャートを示す。
【図３７】図３７は、本発明の第４の局面の第２の好適な方法に従って保険引受エンティティによって実施される工程のフローチャートを示す。
【図３８】図３８は、本発明の第４の局面の第２の好適な方法に従って安全なエンティティによって実施される工程のフローチャートを示す。
【図３９】図３９は、本発明の第４の局面の第４の好適な方法に従う通信シーケンスを示す。
【図４０】図４０は、本発明の第４の局面の第４の好適な方法に従ってＥＣのデジタル署名を作成する疑わしいデバイスによって実施される工程のフローチャートを示す。
【図４１】図４１は、本発明の第４の局面の第４の好適な方法に従って金融機関によって実施される工程のフローチャートを示す。
【図４２】図４２は、本発明の第４の局面の第４の好適な方法に従って保険引受エンティティによって実施される工程のフローチャートを示す。
【図４３】図４３は、本発明の第４の局面の第４の好適な方法に従って安全なエンティティによって実施される工程のフローチャートを示す。
【図４４】図４４は、本発明の第５の局面の好適な方法に従って金融機関を表す第三者の顧客の確立されたＰｕＫリンクされた口座データベースを示す。
【図４５】図４５は、本発明の第５の局面の好適な方法に従って口座により取引を実施するかどうかを考えるためのフローチャートを示す。
【図４６】図４６は、本発明の第６の局面に従う中央鍵オーソリティの口座データベースを示す。
【図４７】図４７は、本発明の第６の局面の好適な方法に従う通信シーケンスを示す。
【図４８】図４８は、図４７の本発明の第６の局面の好適な方法に従ってユーザによって実施される工程のフローチャートを示す。
【図４９】図４９は、図４７の本発明の第６の局面の好適な方法に従って中央鍵オーソリティによって実施される工程のフローチャートを示す。
【図５０】図５０は、図４７の本発明の第６の局面の好適な方法に従って第１の口座ソリティによって実施される工程のフローチャートを示す。
【図５１】図５１は、図４７の本発明の第６の局面の好適な方法に従って第２の口座ソリティによって実施される工程のフローチャートを示す。

Claims (109)

1. デジタル署名を生成するデバイスの情報が確実に識別される方法であって、
   （ａ）環境で製造された複数のデバイスの各々について、
   （ｉ）該環境内で一組の公開−秘密鍵を生成する工程と、
   （ｉｉ）該環境内で、公開鍵を、該デバイスと関連づけられた他の情報と安全な様式でリンクさせる工程と、
   （ｉｉｉ）該環境からの該デバイスのリリース前に、該秘密鍵を該デバイス内に格納して、電子メッセージ用のデジタル署名を生成する際に用いられるようにする工程と、
   （ｂ）その後、該リンクされた公開鍵がデジタル署名されたメッセージを首尾よく認証すると、該リンクされた公開鍵と関連づけれられた他の情報を、該メッセージにデジタル署名する際に用いた該秘密鍵が属する該デバイスに関連するものであると識別する工程と、
   を包含する方法。
2. 前記リンクする安全な様式が、前記リンクされた公開鍵およびセキュリティプロフィールをデータベース内に記録する工程と、該公開鍵がリンクされた各デバイスのセキュリティレベルに少なくとも匹敵するセキュリティ度を有する環境内に、該データベースを維持する工程とを含む、請求項１に記載の方法。
3. 前記リンクする安全な様式が、
   （ａ）前記リンクされた公開鍵と前記デバイスのセキュリティプロフィールとを含むレファレンス用のデジタル署名を作成する工程と、
   （ｂ）該レファレンスと該レファレンス用のデジタル署名を公開する工程と、
   （ｃ）該レファレンスが関連する該デバイスのセキュリティレベルに少なくとも匹敵するセキュリティ度を有する環境内に、該レファレンス用の該デジタル署名を作成する際に用いた秘密鍵を維持する工程と、
   とを含む、請求項１に記載の方法。
4. 前記デジタル署名されたメッセージの受信側によって前記他の情報が識別される、請求項１に記載の方法。
5. 前記デジタル署名されたメッセージの受信側に対して、前記他の情報が識別される、請求項１に記載の方法。
6. デジタル署名を生成するデバイスのセキュリティプロフィールを確実に識別するデータベースを管理する方法であって、
   （ａ）該データベースを安全な環境内に維持する工程と、
   （ｂ）該安全な環境で製造された複数のデバイスの各々のためのデータベースに
   （ｉ）該製造されたデバイスの一組の公開−秘密鍵の公開鍵と、これに関連して、
   （ｉｉ）該製造されたデバイスのセキュリティプロフィールと、
   を記録する工程であって、これにより該公開鍵および該セキュリティプロフィールが安全にリンクされる工程と、
   （ｃ）その後、該リンクされた公開鍵がデジタル署名されたメッセージを首尾よく認証すると、該リンクされた公開鍵と関連づけれられた該セキュリティプロフィールを、該メッセージにデジタル署名する際に用いた該秘密鍵が属する該製造されたデバイスに関連するものであると識別する工程と、
   を包含する方法。
7. 前記デジタル署名されたメッセージの受信側によって前記セキュリティプロフィールが識別される、請求項６に記載の方法。
8. 前記デジタル署名されたメッセージの受信側に対して、前記セキュリティプロフィールが識別される、請求項６に記載の方法。
9. デジタル署名を生成するデバイスのセキュリティプロフィールを確実に識別するデータベースを管理する方法であって、
   （ａ）該データベースを安全な環境内に維持する工程と、
   （ｂ）該安全な環境で製造された複数のデバイスの各々のためのデータベースに
   （ｉ）該製造されたデバイスの一組の公開−秘密鍵の公開鍵と、これに関連して、
   （ｉｉ）該製造されたデバイスのセキュリティプロフィールと、
   を記録する工程であって、これにより該公開鍵および該セキュリティプロフィールが安全にリンクされる工程と、
   （ｃ）レファレンスを安全な様式で通信する工程であって、該レファレンスが、該製造されたデバイスの少なくとも１つのための該公開鍵と該公開鍵にリンクされたセキュリティプロフィールとを含む、工程と、
   を包含する方法。
10. 前記レファレンスを安全な様式で通信する工程が、前記データベース内に維持されている製造されたデバイスのデータベース記録のためのデジタル署名を作成する工程と、該デジタル署名と該データベース記録とを公開する工程とを含む、請求項９に記載の方法。
11. 前記レファレンスを安全な様式で通信する工程が、前記レファレンスが関連する各製造されたデバイスのセキュリティレベルに少なくとも匹敵するセキュリティ度を有する様式で、デジタル署名されたメッセージの受信側に該レファレンスを通信する工程を含む、請求項９に記載の方法。
12. デジタル署名されたメッセージを、前記レファレンスの前記リンクされた公開鍵を用いて首尾よく認証し、それにより、該リンクされた公開鍵と関連づけられた前記セキュリティプロフィールを、該メッセージにデジタル署名する際に用いた前記秘密鍵が属する前記製造されたデバイスに関連するものであると識別する工程をさらに含む、請求項９に記載の方法。
13. 前記デジタル署名されたメッセージと前記デジタル署名とを受信側から受け取る工程をさらに含む、請求項６または１２に記載の方法。
14. 前記安全な環境が、内部で製造され前記公開鍵がリンクされている前記デバイスのいずれのセキュリティレベルをも落とさないために十分なセキュリティ度を有する、請求項６または９に記載の、データベースを管理する方法。
15. 前記製造されたデバイスの各々の前記公開鍵と前記セキュリティプロフィールとが、該製造されたデバイスの各々に割り当てられたデバイス識別子に基づいて前記データベースから取り出し可能である、請求項６または９に記載のデータベースを管理する方法。
16. 前記製造されたデバイスの各々のための前記識別子が、該製造されたデバイスのそれぞれの前記公開鍵を含む、請求項１５に記載のデータベースを管理する方法。
17. 前記製造されたデバイスの各々のための前記識別子が、該製造されたデバイスの各々に対応するシリアルナンバーを含む、請求項１５に記載の方法。
18. 前記製造されたデバイスの各々のための前記識別子が、該製造されたデバイスの各々と関連づけられた口座番号を含む、請求項１５に記載の方法。
19. 前記デジタル署名されたメッセージの受信側からデバイス識別子を受け取る工程と、該デバイス識別子と前記データベース内のデバイス識別子とを比較してマッチするか否かを調べる工程であって、該データベースでは、上記リンクされた公開鍵とセキュリティプロフィールとにインデックスが付けられている工程とをさらに含む、請求項６または９に記載のデータベースを管理する方法。
20. 前記デジタル署名されたメッセージの受信側から疑わしいデバイス公開鍵を受け取る工程と、該疑わしいデバイス公開鍵と、上記セキュリティプロフィールにインデックスが付けられている前記データベース内の上記リンクされた公開鍵とを比較してマッチするか否かを調べる工程とをさらに含む、請求項６または９に記載のデータベースを管理する方法。
21. 電子メッセージを認証するために用いられる前記公開鍵が、該電子メッセージ用の前記デジタル署名と共に送信される、請求項２０に記載の方法。
22. デジタル署名を生成するデバイスのセキュリティプロフィールを確実に識別することを可能にする方法であって、
    （ａ）安全な環境で製造された複数のデバイスの各々について、該製造されたデバイスの公開鍵をセキュリティプロフィールと共に記録する工程と、セキュリティ証明書をまとめて定義するためにデジタル署名を生成する工程であって、これにより該公開鍵と該セキュリティプロフィールとが安全にリンクされる工程と、
    （ｂ）各製造されたデバイスが該安全な環境からリリースされる前に、それぞれのセキュリティ証明書を該製造されたデバイスに組み込むことにより、該セキュリティ証明書が、該製造されたデバイスによって秘密鍵を用いて生成されたデジタル署名と共に送信される工程と、
    を含む、方法。
23. （ａ）前記製造されたデバイスの１つの前記秘密鍵を用いて、電子メッセージ用デジタル署名を生成する工程と、
    （ｂ）特定の該製造されたデバイスの前記セキュリティ証明書を、該電子メッセージ用の該デジタル署名と共に送信する工程と、
    （ｃ）該セキュリティ証明書に含まれる前記公開鍵を用いて、首尾よく該電子メッセージを認証する工程と、
    （ｄ）別の公開鍵を用いて首尾よく該セキュリティ証明書を認証する工程と、
    （ｅ）該セキュリティ証明書内のセキュリティ特性を、該電子メッセージの該デジタル署名を生成するために用いられた該秘密鍵が属する該特定の製造されたデバイスのセキュリティであると識別する工程と、
    をさらに含む、請求項２２に記載の方法。
24. 前記安全な環境が、内部で製造され前記公開鍵がリンクされている前記デバイスのいずれのセキュリティレベルをも落とさないために十分なセキュリティ度を有する、請求項２２に記載の方法。
25. 前記メッセージにデジタル署名するために前記秘密鍵が不正に用いられた可能性を、前記識別されたセキュリティプロフィールに少なくとも部分的に基づいて判定する工程をさらに含む、請求項１、６、１２または２３に記載の方法。
26. デバイスの前記セキュリティプロフィールが、該デバイスのセキュリティ特性を含む、請求項１、６、９または２２に記載の方法。
27. 各製造されたデバイスの前記セキュリティ特性が、デジタル署名を作成する際に該デバイスによって用いられたアルゴリズムを含む、請求項２６に記載の方法。
28. デバイスの前記セキュリティプロフィールが、該デバイスの認証能力を含む、請求項１、６、９または２２に記載の方法。
29. 前記認証能力が、前記デバイスがファクタＡおよびファクタＢエンティティ認証を行うか否かを含む、請求項２８に記載の方法。
30. デバイスの前記セキュリティプロフィールが、該デバイスのすべてのセキュリティ特性を含む、請求項１、６、９または２２に記載の方法。
31. デバイスの前記セキュリティプロフィールが、該デバイスの製造履歴を含む、請求項２８に記載の方法。
32. 前記製造履歴が、前記デバイスのバッチ識別子を含む、請求項３１に記載の方法。
33. 前記製造履歴が、前記デバイスの製造元のアイデンティティを含む、請求項３１に記載の方法。
34. 前記製造履歴が、前記デバイスの部品番号を含む、請求項３１に記載の方法。
35. 前記製造履歴が、前記デバイスの製造日付および場所を含む、請求項３１に記載の方法。
36. 前記製造履歴が、前記デバイスのリンクされた鍵を含む、請求項３１に記載の方法。
37. 前記製造履歴が、前記デバイスのシリアルナンバーを含む、請求項３１に記載の方法。
38. 前記製造されたデバイスの前記シリアルナンバーが、前記デバイスの前記公開鍵を含む、請求項３７に記載の方法。
39. 前記安全な環境内で製造された各デバイスが、安全なデバイス用に定義されたセキュリティレベルを満たす、請求項６、９または２２に記載の方法。
40. 前記安全な環境が、複数の物理的場所を含む、請求項２、３、６、９または２２に記載の方法。
41. 前記電子メッセージが、金融取引を表す、請求項１、６、１２または２２に記載の方法。
42. 前記電子メッセージが、法的行為を表す、請求項１、６、１２または２２に記載の方法。
43. 前記電子メッセージが、情報へのアクセスに対するリクエストを表す、請求項１、６、１２または２２に記載の方法。
44. 前記電子メッセージが、物理的場所へのアクセスに対するリクエストを表す、請求項１、６、１２または２２に記載の方法。
45. 製造されたデバイスの各一組の鍵が、対応する該デバイス内で作成される、請求項１、６、９または２２に記載の方法。
46. 各組の前記公開鍵のみが、対応する該デバイスからエクスポート可能である、請求項４５に記載の方法。
47. 前記秘密鍵が、対応する該デバイスからエクスポート不可能である、請求項４５に記載の方法。
48. 前記電子メッセージ用の前記デジタル署名が、前記識別されたセキュリティプロフィールに少なくとも部分的に基づいたプレミアムとの交換で不正に作成されたものではないことの金銭的保証を提供する工程をさらに含む、請求項１、６、１２または２３に記載の方法。
49. 前記電子通信が受信側に送信され、その後前記金銭的保証を提供するエンティティに転送される、請求項４８に記載の方法。
50. 前記認証が、前記金銭的保証を提供するエンティティによって行われる、請求項４８に記載の方法。
51. 前記金銭的保証を提供するエンティティによって保険をかけられた対象に、保証の確認を送信する工程をさらに含む、請求項４８に記載の方法。
52. 前記保証の確認が、前記製造されたデバイスのセキュリティ特徴を含む、請求項５１に記載の方法。
53. 前記保証の確認が、前記金銭的保証のためのプレミアムの指示をさらに含む、請求項５２に記載の方法。
54. 安全なエンティティが、前記安全な環境内で製造された各デバイスの公開鍵とセキュリティ特徴とをリンクし、該安全なエンティティが、前記製造されたデバイスの該リンクされたセキュリティ特徴の認証のために、該安全なエンティティの公開鍵を前記金銭的保証を提供するエンティティに通信する、請求項４８に記載の方法。
55. 前記金銭的保証の提供に対して、前記デバイスの異なるセキュリティプロフィールに基づいて、異なるプレミアムレートを請求する工程をさらに含む、請求項４８に記載の方法。
56. 前記電子メッセージ用の前記デジタル署名が、前記識別されたセキュリティプロフィールに少なくとも部分的に基づいたプレミアムとの交換で不正に作成されたものではないことの金銭的保証を提供する工程をさらに含み、該金銭的保証を提供するエンティティが、該電子メッセージを首尾よく認証する公開鍵を安全なエンティティに送信し、該安全なエンティティが、前記安全な環境で、それぞれの公開鍵を各製造されたデバイスに対応するセキュリティ特徴にリンクさせる、請求項１または６に記載の方法。
57. 前記安全なエンティティが、前記電子メッセージを首尾よく認証する前記公開鍵を、前記製造されたデバイスのセキュリティ特徴にリンクされた前記公開鍵と比較する、請求項５６に記載の方法。
58. 前記安全なエンティティが、前記金銭的保証を提供する前記エンティティにセキュリティ特徴を通信し、該セキュリティ特徴にリンクされた前記公開鍵が前記電子メッセージを首尾よく認証する前記公開鍵とマッチする、請求項５７に記載の方法。
59. 前記安全なエンティティが、前記セキュリティ特徴の前記通信にデジタル署名する、請求項５８に記載の方法。
60. 前記電子メッセージ用の前記デジタル署名が、前記識別されたセキュリティプロフィールに少なくとも部分的に基づいたプレミアムとの交換で不正に作成されたものではないことの金銭的保証を提供する工程をさらに含み、安全なエンティティが、前記製造されたデバイスの前記公開鍵と前記セキュリティ特徴とを含むレファレンスにデジタル署名することにより、該製造されたデバイスの該公開鍵とセキュリティ特徴とをリンクさせる、請求項１または９に記載の方法。
61. 前記安全なエンティティが、前記レファレンスを、前記電子通信の受信側に通信する、請求項６０に記載の方法。
62. 前記安全なエンティティが、前記レファレンスを、前記金銭的保証を提供するエンティティに通信する、請求項６０に記載の方法。
63. 前記金銭的保証を提供する前記エンティティが、前記安全なエンティティによって通信された前記デジタル署名されたレファレンスを認証する、請求項６２に記載の方法。
64. 初期ＰｕＫリンクされた口座データベースを確立する方法であって、
    （ａ）該データベースを安全な環境内に維持する工程と、
    （ｂ）該安全な環境内で製造された複数のデバイスの各々のための該データベースに、
    （ｉ）該製造されたデバイスの一組の公開−秘密鍵の公開鍵と、これに関連して、
    （ｉｉ）該製造されたデバイスのセキュリティプロフィールと、
    を記録する工程であって、これにより該公開鍵および該セキュリティプロフィールがリンクされる工程と、
    （ｃ）該製造されたデバイスを該安全な環境から複数のユーザに配信する工程と、
    （ｄ）該配信されたデバイスのデータベース記録を、該ユーザの初期ＰｕＫリンクされた口座データベースであると識別する工程と、
    を含む方法。
65. 前記製造されたデバイスが、潜在的顧客と現行の顧客とに配信される、請求項６４に記載の方法。
66. 前記識別する工程が、前記配信された製造されたデバイスの前記データベース記録を前記安全な環境から安全な様式で第三者に、該第三者の初期ＰｕＫリンクされた口座データベースとして通信する工程を含む、請求項６４に記載の方法。
67. 前記データベース記録を前記安全な環境から安全な様式で前記第三者に通信する工程が、該データベース記録が関連する各製造されたデバイスによって満たされるセキュリティレベルよりも高いセキュリティ度を有する様式で、該データベース記録を通信する工程を含む、請求項６６に記載の方法。
68. 前記データベース記録を前記安全な環境から安全な様式で前記第三者に通信する工程が、該データベース記録用のデジタル署名を作成する工程と、該データベース記録と該デジタル署名とを該第三者に通信する工程とを含む、請求項６６に記載の方法。
69. 顧客特定情報を用いて、前記初期ＰｕＫリンクされた口座データベースを更新する工程をさらに含む、請求項６６に記載の方法。
70. 前記初期ＰｕＫリンクされた口座データベースを、前記第三者の前から存在する口座データベースとマージする工程をさらに含む、請求項６６に記載の方法。
71. （ａ）前記製造されたデバイスの１つの秘密鍵を用いて、電子メッセージ用のデジタル署名を作成する工程と、
    （ｂ）公開鍵を用いて該メッセージを認証する工程と、
    （ｃ）該メッセージを認証するために用いられた該公開鍵と、前記初期ＰｕＫリンクされた口座データベース内に記録された鍵とを比較する工程と、
    （ｄ）該公開鍵が、該初期ＰｕＫリンクされた口座データベースの記録内に記録された鍵とマッチするとき、該記録に対応する口座を活性化させる工程と、
    により、該ＰｕＫリンクされた口座データベースの口座を活性化させる工程をさらに含む、請求項６４に記載の方法。
72. 前記電子メッセージを認証するために用いられた前記公開鍵が、該電子メッセージ用の前記デジタル署名と共に送信される、請求項７１に記載の方法。
73. ユーザの初期ＰｕＫリンクされた口座データベースを、複数の第三者の各々に関して確立する方法であって、
    （ａ）安全な環境内でデバイスを製造する工程と、
    （ｂ）各製造されたデバイスについて、
    （ｉ）非対称暗号法で用いられる一組の鍵を生成する工程と、
    （ｉｉ）該安全な環境からの該デバイスのリリース前に、該鍵の１つを、電子メッセージ用のデジタル署名を生成する際に用いるために製造された該デバイス内に格納する工程と、
    （ｉｉｉ）他の鍵および他の情報を、該安全な環境内に維持された安全なデータベース内に記録する工程と、
    （ｃ）該製造されたデバイスの１つを該安全な環境から該ユーザに配信する工程と、
    （ｄ）前記第三者の各々に対して、前記配信された製造されたデバイスの前記データベース記録を、該ユーザの該初期ＰｕＫリンクされた口座データベース記録であると識別する工程と、
    を含む、方法。
74. 前記データベース記録を識別する工程が、前記安全なデータベースからの前記データベース記録を前記第三者の各々に安全な様式で通信する工程を含む、請求項７３に記載の方法。
75. 前記ユーザが前記第三者の１つの潜在的顧客である、請求項７３に記載の方法。
76. 前記ユーザが前記第三者の１つの現行の顧客である、請求項７３に記載の方法。
77. 前記識別する工程が、前記配信された製造されたデバイスの前記データベース記録を前記安全な環境から安全な様式で前記第三者の各々に、前記ユーザ用の前記初期ＰｕＫリンクされた口座データベース記録として通信する工程を含む、請求項７３に記載の方法。
78. 前記データベース記録を前記安全な環境から安全な様式で通信する工程が、該データベース記録を、該データベース記録が関連する前記製造されたデバイスの匹敵するセキュリティレベルよりも高く規定されたセキュリティレベルを有する様式で通信する工程を含む、請求項７７に記載の方法。
79. 前記データベース記録を前記安全な環境から安全な様式で通信する工程が、該データベース記録用のデジタル署名を作成する工程と、前記第三者の各々に該データベース記録と該デジタル署名とを通信する工程とを含む、請求項７７に記載の方法。
80. ユーザ特定情報を用いて、前記第三者の１つによって受け取られた、該ユーザの前記初期ＰｕＫリンクされた口座データベースを更新する工程をさらに含む、請求項７７に記載の方法。
81. 前記第三者の１つによって受け取られた、前記ユーザの前記初期ＰｕＫリンクされた口座データベースを、前から存在する口座データベース記録とマージする工程をさらに含む、請求項８０に記載の方法。
82. （ａ）前記顧客に配信された、前記製造されたデバイスの秘密鍵を用いて、電子メッセージ用のデジタル署名を生成する工程と、
    （ｂ）前記第三者に該電子メッセージと該デジタル署名とを送信する工程と、
    （ｃ）公開鍵を用いて、該メッセージを認証する工程と、
    （ｄ）該メッセージを認証するために用いられた該公開鍵と、該第三者のＰｕＫリンクされた口座データベースに記録された鍵とを比較する工程と、
    （ｅ）該公開鍵が、該初期ＰｕＫリンクされた口座データベースの記録内に記録された鍵とマッチするとき、該記録に対応する口座を活性化させる工程と、
    により、該第三者の１つの該ＰｕＫリンクされた口座データベースの口座を活性化させる工程をさらに含む、請求項７３に記載の方法。
83. 前記電子メッセージを認証するために用いられた前記公開鍵が、該電子メッセージ用の前記デジタル署名と共に送信される、請求項８２に記載の方法。
84. 各デバイスが確実に且つ一意的に識別され得るようにデジタル署名を生成するデバイスを製造する方法であって、該デバイスが安全な環境内で製造され、
    （ａ）該安全な環境内で一組の公開−秘密鍵を作成する工程と、
    （ｂ）該デバイスによって該秘密鍵が暴露される可能性にもかかわらず、該デバイス内に該秘密鍵を格納する工程と、
    （ｃ）該安全な環境内で該公開鍵と他の情報とをセキュアにリンクさせる工程と、
    を含む、方法。
85. 各一組の公開−秘密鍵が、各デバイス内に設けられた乱数発生器によって生成された乱数に基づいて各デバイス内に作成される、請求項８４に記載の方法。
86. 前記乱数発生器が、高質乱数発生器である、請求項８５に記載の方法。
87. 前記公開鍵のみが前記デバイスからエクスポート可能である、請求項８５に記載の方法。
88. 各デバイスによって生成された各デジタル署名が乱数である、請求項８５に記載の方法。
89. 前記他の情報が、各デバイスのセキュリティ特徴を含む、請求項８５に記載の方法。
90. 前記他の情報が、各デバイスの製造履歴を含む、請求項８５に記載の方法。
91. 前記リンクされた公開鍵の１つを用いてメッセージを認証することにより、特定の製造されたデバイスを識別する工程をさらに含み、該特定の製造されたデバイスによって該メッセージ用のデジタル署名が生成される、請求項８５に記載の方法。
92. ユーザのＰｕＫリンクされた口座情報を含む中央鍵オーソリティ（ＣＫＡ）データベースであって、該ＰｕＫリンクされた口座情報が各ユーザ用のデータベース内に維持され、
    （ａ）デジタル署名を生成するユーザデバイスの公開鍵と、
    （ｂ）該デバイスの製造の安全な環境内で、該デバイスの該公開鍵と安全にリンクされた情報と、
    （ｃ）第三者口座識別子であって、各々が、該第三者に維持され且つ該第三者によって該ユーザの公開鍵に関連づけられている、該ユーザの口座を、該第三者に対して識別する、第三者口座識別子と、
    を備えた中央鍵オーソリティデータベース。
93. 前記公開鍵にリンクされた前記情報が、前記デバイスのセキュリティ特徴を含む、請求項９２に記載のデータベース。
94. 前記公開鍵にリンクされた前記情報が、前記デバイスの製造履歴を含む、請求項９２に記載のデータベース。
95. 前記公開鍵と該公開鍵にリンクされた情報が、安全なエンティティから取得される、請求項９２に記載のデータベース。
96. 各ユーザのＣＫＡデータベース内に維持されたＰｕＫリンクされた口座情報が、各第三者のアイデンティティであって、第三者口座識別子の１つによって識別される口座を維持する、アイデンティティを含む、請求項９２に記載のデータベース。
97. 前記ユーザの前記ＰｕＫリンクされた口座情報が、独自のＣＫＡ口座識別子によってＣＫＡデータベース内でインデックスを付けられ、それによりユーザ用の前記ＰｕＫリンクされた口座情報が、該口座識別子に基づいて該ＣＫＡデータベースから取り出し可能となっている、請求項９２に記載のデータベース。
98. 前記公開鍵が前記ＣＫＡ口座識別子である、請求項９７に記載のデータベース。
99. 各ユーザ用の前記ＣＫＡデータベース内に維持された、前記ＰｕＫリンクされた口座情報が、ユーザ特定情報をさらに含む、請求項９２に記載のデータベース。
100. 前記ユーザ特定情報が検証済みである、請求項９９に記載のデータベース。
101. 各ユーザ口座が、前記ユーザ特定情報を検証する際に採用された技術の記録をさらに含む、請求項１００に記載のデータベース。
102. 前記ユーザ特定情報が、該ユーザの氏名と住所とを含む、請求項９９に記載のデータベース。
103. 前記ユーザ特定情報が、該ユーザの年齢と性別とを含む、請求項９９に記載のデータベース。
104. ユーザの前記公開鍵と該公開鍵にリンクされた情報とを前記ＣＫＡデータベースから前記第三者に通信することにより、該第三者によって、該ユーザのために口座を確立する工程をさらに含む、請求項９２に記載のデータベース。
105. 前記ユーザの前記公開鍵と該公開鍵にリンクされた情報とが、これらが通信している前記第三者のリクエストにより通信される、請求項１０４に記載のデータベース。
106. 少なくとも２つの独立した第三者に維持されているユーザのＰｕＫリンクされた口座を、該ユーザの新しい公開鍵を用いて更新する工程をさらに含み、該工程が、
     （ａ）電子通信（「ＥＣ」）を受け取る工程であって、該ＥＣが、ＣＫＡ口座識別子の１つ、および該新しい公開鍵と該新しい公開鍵用のデジタル署名とを含むメッセージを含む、工程と、
     （ｂ）該ＣＫＡ口座識別子によって識別された前記ＣＫＡデータベース内の口座と関連づけられた前記公開鍵を用いて、該ＥＣの該メッセージを認証する工程と、
     （ｃ）該認証が首尾よくなされると、該第三者の各々にＥＣを送信する工程であって、各ＥＣが、該ＣＫＡデータベース内に維持され該ＣＫＡ口座識別子によって識別された口座と関連づけられた、各第三者の該新しい公開鍵と前記第三者口座識別子とを含む、工程と、
     を含む、請求項９２に記載のデータベース。
107. 前記ユーザの前記新しい公開鍵と前記第三者口座識別子とにデジタル署名する工程をさらに含む、請求項１０６に記載のデータベース。
108. 前記ユーザから受け取った前記ＥＣを前記第三者の各々に送信する工程をさらに含む、請求項１０６に記載のデータベース。
109. 前記デバイスの製造プロセス中に、前記情報が各デバイスの前記公開鍵にリンクされる、請求項９２に記載のデータベース。

Images