(57)【要約】  パブリックおよびプライベートキー暗号技術を使用して、トークンホルダの属性を信頼性のある当事者に選択的に配信してもよいプライバシー強化された識別子スキーム。チャレンジメッセージは、｛Rnonce, ＲＩＤ｝であり、Rnonceはリーダnonceであり、ＲＩＤはリーダ識別子である。方法はまた、チャレンジメッセージに応答して、少なくとも、暗号化されたプライベートトークン識別子ＴＩＤとセッションキーｋとを含む応答メッセージを含む応答メッセージを送信する。リーダからのチャレンジに応答する。トークンは、同じトークンから送信された他の識別子に対してリンク不可能であるトークン識別子を含むメッセージを送信する。【選択図】      図３Ａ
2009535900.tif 000002
【特許請求の範囲】
【請求項１】
リンク不可能な識別子をトークンから送信する方法において、
Challengeメッセージをトークンに送信することと、
前記Challengeメッセージに応答して、Responseメッセージを受け取ることとを含み、
Challenge＝｛Rnonce, ＲＩＤ｝であり、Rnonceはリーダnonceであり、ＲＩＤはリーダ識別子であり、
Response＝｛signature（Ｈ（Tnonce, Rnonce, ＲＩＤ)), Tnonce, ＸＩＤ｝であり、signatureは前記トークンのプライベートキーを使用するデジタル署名であり、Ｈはハッシュ関数であり、Tnonceはトークンnonceであり、ＸＩＤは前記トークンのリンク不可能な識別子である方法。
【請求項２】
ＸＩＤ＝｛Ｅ（ｋ, Ｐ）, Ｅ(ＴＩＤ, ｋ）｝であり、ＴＩＤはトークン識別子であり、ｋはセッションキーであり、Ｐはレジストリのパブリックキーであり、Ｅ(ＴＩＤ, ｋ)は前記セッションキーｋを使用して暗号化されたＴＩＤであり、Ｅ（ｋ, Ｐ）は前記パブリックキーＰを使用して暗号化されたセッションキーｋである請求項１記載の方法。
【請求項３】
前記Responseメッセージを前記レジストリに送信することをさらに含む請求項２記載の方法。
【請求項４】
レジストリプライベートキーＱを使用して、前記レジストリにおいて前記セッションキーｋを解読し、前記解読されたセッションキーｋを使用して前記ＴＩＤを解読することをさらに含む請求項３記載の方法。
【請求項５】
データベースクエリにおいて、前記解読されたＴＩＤに基づいたキーを使用して、前記ＴＩＤに対して登録されている情報を取得することをさらに含む請求項４記載の方法。
【請求項６】
前記レジストリに送信されるメッセージは、｛Rnonce, ＲＩＤ｝をさらに含む請求項３記載の方法。
【請求項７】
signature（Ｈ（Tnonce, Renonce, ＲＩＤ））をチェックすることによって前記ＲＩＤを確認することをさらに含む請求項６記載の方法。
【請求項８】
ＲＩＤの確認が成功した場合、同様に、データベースクエリにおいて、ＲＩＤに基づくキーを使用して、ＴＩＤに対応するどの情報を受け取るように信頼性のある当事者が認証されているかを決定する請求項７記載の方法。
【請求項９】
前記Responseは、ワンタイムパスワード（ＯＴＰ）を含む請求項１記載の方法。
【請求項１０】
前記Responseは、生体測定データを含む請求項１記載の方法。
【請求項１１】
リンク不可能な識別子をトークンから送信する方法において、
Challengeメッセージをトークンに送信することと、
前記Challengeメッセージに応答して、少なくとも、暗号化されたプライベートトークン識別子ＴＩＤとセッションキーｋとを含むResponseメッセージを送信することとを含み、
Challenge＝｛Rnonce, ＲＩＤ｝であり、Rnonceはリーダnonceであり、ＲＩＤはリーダ識別子である方法。
【請求項１２】
前記Responseメッセージをレジストリに送信することをさらに含む請求項１１記載の方法。
【請求項１３】
レジストリプライベートキーＱを使用して、前記レジストリにおいて前記セッションキーｋを解読し、前記解読されたセッションキーｋを使用して前記ＴＩＤを解読することをさらに含む請求項１２記載の方法。
【請求項１４】
データベースクエリにおいて、前記解読されたＴＩＤに基づいたキーを使用して、前記ＴＩＤに対して登録されている情報を取得することをさらに含む請求項１３記載の方法。
【請求項１５】
前記レジストリに送信されるメッセージは、｛Rnonce, ＲＩＤ｝をさらに含む請求項１２記載の方法。
【請求項１６】
前記ＲＩＤを確認することをさらに含む請求項１５記載の方法。
【請求項１７】
ＲＩＤの確認が成功した場合、同様に、データベースクエリにおいて、ＲＩＤに基づくキーを使用して、ＴＩＤに対応するどの情報を受け取るように信頼性のある当事者が認証されているかを決定する請求項１６記載の方法。
【請求項１８】
前記Responseは、ワンタイムパスワード（ＯＴＰ）を含む請求項１１記載の方法。
【請求項１９】
前記Responseは、生体測定データを含む請求項１１記載の方法。
【請求項２０】
リンク不可能な識別子をトークンから送信して、信頼性のある当事者に対して、トークンホルダの属性を選択的に配信するシステムにおいて、
トークンと、
リーダを備えた信頼性のある当事者と、
トークンホルダの属性を記憶するように構成されている識別子レジストリとを具備し、
前記リーダは、Challengeメッセージを前記トークンに送信するように構成され、前記トークンはリンク不可能なトークン識別子を含むResponseメッセージを前記リーダに送信するように構成され、
前記リーダが前記識別子レジストリからの属性を要求したときに、前記識別子レジストリは、要求された属性を取得するための、信頼性のある当事者の認証を確認し、認証されている場合に、前記属性を前記リーダに送信するシステム。
【請求項２１】
Challenge＝｛Rnonce, ＲＩＤ｝であり、Rnonceはリーダnonceであり、ＲＩＤはリーダ識別子および前記トークンである請求項２０記載のシステム。
【請求項２２】
前記Responseは、少なくとも、暗号化されたプライベートトークン識別子ＴＩＤとセッションキーｋとを含む請求項２０記載のシステム。
【請求項２３】
前記識別子レジストリは、レジストリプライベートキーＱを使用して、前記レジストリにおいて前記セッションキーｋを解読し、前記解読されたセッションキーｋを使用して前記ＴＩＤを解読するように構成されている請求項２２記載のシステム。
【請求項２４】
前記識別子レジストリは、少なくとも１つの属性レジストリと通信する請求項２０記載のシステム。
【請求項２５】
前記トークンは、スマートカード、キー・フォブ、ポータブルワイヤレスタグ、およびＲＦＩＤタグのうちのいずれかの１つである請求項２０記載のシステム。
【請求項２６】
前記リーダは、前記トークン上に記憶されているデータを読み取るように構成されているハードウェアデバイスである請求項２０記載のシステム。
【請求項２７】
前記信頼性のある当事者は、マーチャント、サプライチェーン制御ポイント、ネットワークサーバ、ＲＦＩＤタグシステム、およびアクセス制御ポイントのうちのいずれかの１つである請求項２０記載のシステム。
【請求項２８】
前記識別子レジストリは、データベースである請求項２０記載のシステム。
【請求項２９】
前記Responseは、ワンタイムパスワード（ＯＴＰ）を含む請求項２０記載のシステム。
【請求項３０】
前記Responseは、生体測定データを含む請求項２０記載のシステム。
【請求項３１】
前記トークンは、ソフトトークンである請求項２０記載のシステム。
【請求項３２】
前記リーダは、コンピューティングデバイス上で実行しているアプリケーションである請求項２０記載のシステム。
【発明の詳細な説明】
【関連出願の相互参照】
【０００１】
本出願は、米国特許法１１９条の下、２００６年４月２５日に出願された米国仮出願第６０／７９４，５１６号の利益を主張しており、その全体の内容は参照によりここに明確に組み込まれている。
【発明の分野】
【０００２】
本発明は、一般的に、プライバシー強化された識別子スキームに関する。さらに詳細に説明すると、本発明は、パブリックおよびプライベートキー暗号化技術を使用して、信頼性のある当事者にトークンホルダの属性を選択的に配信するプライバシー強化された識別子スキームに関する。
【背景】
【０００３】
多くの国々では、国民識別子カードスキームを用いる可能性を論議している。例えば、イギリスが、最近、イギリス国民識別子カードスキームを導入する予定であると発表した。イギリス国民識別子カードスキームは、国民識別子データベースにリンクされるだろう。国民識別子データベースは、行政サービスの配信において重要な役割を果たす予定である。今後１０年以内に、イギリスでは、何らかの形態のイギリス国民識別子カードを持つであろう労働人口は、およそ８０パーセントに達すると見込まれている。イギリスは、行政サービスと引き換えに、国民識別子データベースへの情報の必須的なエントリを計画している。例えば、人々の個人識別情報は、パスポートや自動車免許証を取得したときに、国民識別子データベースに自動的に追加されるであろう。
【０００４】
イギリスの国民識別子カードスキームの観点は、イギリス国民識別子レジストリと呼ばれる中央コンピュータデータベースであるかもしれない。スキームの下、誰かを識別するために、例えば、生体測定スキャンを用いて、それをイギリス国民識別子レジストリと整合させることによって、イギリス国民識別子カードをチェックする必要がある。
【０００５】
イギリス国民識別子レジストリは、例えば、個人情報、識別情報、居住状態、個人参照番号、レコード経歴、登記およびＩＤカード履歴、確認情報、セキュリティ情報を含むさまざまな情報を記録して記憶する予定である。
【０００６】
その結果として、イギリス国民識別子データベース中に記憶される情報の量およびタイプが原因で、イギリス国民識別子カードスキームは、プライバシーおよびセキュリティ問題について大論議を引き起こした。
【０００７】
アメリカ合衆国で年齢確認のために使用されているもののような、いくつかの従来の識別子スキームでは、認証は、一般的に、２段階で行われる。最初に、対象の識別子は、写真を用いることによって認証される。次に、識別子に結び付けられた年齢または名前のような属性が評価される。
【０００８】
飲食業界では、一般的に、利用客が２１歳であることを確認するために、運転免許証が、信頼性のある当事者に提示される。しかしながら、年齢を確認することに加えて、多数の企業は、運転免許証の磁気ストライプ上のエンコードされた情報を取り込むことがある。例えば、ライセンスホルダの住所およびセキュリティ番号が、マーケティング目的で記録されることが多い。すなわち、情報は、消費者の行動のパターンを追跡するために記憶されることが多い。
【０００９】
したがって、人物が２１を超えていることを証明するために、免許証の磁気ストリップ上に記載されたすべての他の部分の情報を公表しなければならない。この認証されていない情報の使用およびプライバシーの侵害について、多くの考慮すべきことがある。
【００１０】
同様に、プライバシーの問題は、国民識別子カードスキームに関して起こっている。例えば、国民識別子カードスキームでは、本人の生体測定の特徴のみ記録しないが、個人経歴も記録することになる可能性が大きい。結果として、公務員は、データベースにアクセスして、人々の税金や健康に関するファイルをサーチするときに、個人の犯罪経歴に対するアクセスも持つ可能性がある。したがって、識別子データベースに対して制限されたアクセスを提供することは、プライバシー問題を軽減するために効果的である。
【００１１】
さらに他には、セキュリティ、特に、識別子の盗用と関係がある。セキュリティの専門家の中には、単一の識別子カードまたはデータベースを委任することは、識別子の盗用を助長する恐れがあると主張する者もいる。
【００１２】
現行のプライバシー強化スキームは、すべての当事者に対して比較的に強力なプライバシーの保証を提供するように設計されている。このようなスキームは、認証された目的のみにカードを使用できるように、リンク機構を制御することが望ましい国民識別子カードには適していない。
【００１３】
これらの問題を取り扱うために、本発明の実施形態したがうと、例えば、国民識別子カードとともに使用するためのように、リンク不可能な識別子を使用してプライバシー強化された識別子スキームが開示されており、この識別スキームによって、認証されており、かつ必要であり、比較的に正確な度合いの情報を、警察、政府機関、および認証された第三者のような信頼性のある当事者に対してホルダが提供し、プライバシーおよびセキュリティ問題を減少させることができる。
【詳細な説明】
【００１４】
本発明は、一般的に、国民識別子カードのようなトークンを使用してプライバシー強化された識別子スキームに関する。（マーチャントのような）信頼性のある当事者は、トークンリーダを持つことができ、トークンおよび識別子レジストリと対話することができる。マーチャントは、トークンおよびレジストリと対話して、レスジストリに記憶されているトークンホルダについての情報のサブセットのみを取得することができる。例えば、レストラン（信頼性のある当事者）は、トークンホルダが１８歳を超えており、アルコールを提供できることを確認するために、トークンおよびレジストリと対話することができる。トークンホルダについての他の情報はレストランに開示されないので、レジストリに記憶されているホルダの他の情報のプライバシーを保護する。
【００１５】
本発明の実施形態にしたがった方法は、パブリックおよびプライベートキー暗号化技術を使用して、信頼性のある当事者にトークンホルダの属性を選択的に配信することができる。方法は、Ｃ＝｛ＲＩＤ, Rnonce｝を計算することによって、リーダ識別子（ＲＩＤ）を持つリーダにおいてチャンレンジを生成することを含むことができる。ここでは、Rnonceは、リーダnonceである。チャレンジは、トークンに送信することができる。トークンは、応答、例えば、｛signature（Ｈ（Tnonce, Rnonce, ＲＩＤ））, Tnonce, ＸＩＤ｝を発生させることができ、ここで、Tnonceはトークンnonceであり、Ｈはハッシュ関数である。ＸＩＤは、トークンのリンク不可能な識別子、例えば、ＸＩＤ＝｛Ｅ（ｋ, Ｐ）, Ｅ（ＴＩＤ, Ｋ）｝であり、ここで、ＴＩＤはトークン識別子であり、ｋはセッションキーであり、Ｐはレジストリのパブリックキーであり、Ｅ（ＴＩＤ, Ｋ）はセッションキーｋを使用してＴＩＤ暗号化された関数であり、Ｅ（ｋ, ｐ）はパブリックキーＰを使用して暗号化されたセッションキーｋである。
【００１６】
本発明の実施形態にしたがうと、例えば、国民識別子カードとともに使用するためのように、リンク不可能な識別子を使用してプライバシー強化された識別子スキームによって、ホルダは、認証されており、かつ必要である、より正確な度合いが高い情報を、警察、政府機関、認証された第三者のような信頼性のある当事者に対して提供することができ、そしてプライバシーおよびセキュリティ問題を軽減している。
【００１７】
本発明の実施形態は、スキームの第三者の使用を制御する能力を可能にする。例えば、政府は、関連性のない情報を提供することなく、バーでの年齢確認のような使用を信頼性のある当事者に許可することができる。政府のようなユーザが、特定の当事者の使用を許可することも許可しないことも可能であり、そして、使用の許可を無効にすることも可能である。例えば、スキームの初期のインプリメンテーションは、未成年の飲酒問題が存在するあるバーで、年齢確認用のスキームを信頼性のある当事者が使用することを許可する。さらに、スキームは、カードが盗まれたことが報告された場合に、ユーザが特定のカードの使用を止めることを許可する。さらに、例えば、飲酒年齢が２１から１８に変わった場合に、スキームは、国家レベルで調整される。
【００１８】
本発明の実施形態にしたがった方法はまた、例えば、配給対策または災害救済支援を一時的に導入するために使用されてもよい。燃料不足のケースにおいて、政府が、短期配給スキームを設けて、１日あたりの燃料の購入を制限することを求めるかもしれない。このケースでは、トークンホルダは、災害エリアにいる住民であるので、トークンは、国民識別子レジストリにリンクされている国民識別子カードである。信頼性のある当事者は燃料供給所である。政府は、この場合、国民識別子レジストリにリンクされている燃料配給属性レジストリを少なくとも一時的にセットアップして、ドライバ、および、それぞれによって購入された燃料の量のレコードを維持してもよい。トークンホルダまたは信頼性のある当事者は、トークンホルダによって予め定められた購入数または各供給所によって販売される燃料の量に比例して、燃料供給所に対するアクセスを許可してもよい。従来の配給スキームに対して、この方法は、短期の災害に応えて、より迅速に使用することができる。
【００１９】
本発明の実施形態にしたがった方法はまた、例えば、医療業界において使用されてもよい。例えば、医者を訪れたときにインテイクフォームがない可能性があるので、中央データベースにおいて情報のすべてを管理することができる。患者がトークンを持っていてもよい。そして、例えば、患者がスルファベースの薬剤に対してアレルギーであった場合、この情報を中央データベースにリストアップすることができる。したがって、患者がインテイクフォームを記入しなかったとしても、認証された医療担当者は、信頼性のある当事者として、データベースを通して、これらのレコードにアクセスすることができる。
【００２０】
最初に、図１を参照すると、トークン１０およびトークンホルダ１２が示されている。例において、トークン１０は、組み込まれたマイクロプロセッサ１４とトークン通信手段１６とを有している。また、図１では、取り付けられた電子デバイス２０を有するリーダ１８が示されている。
【００２１】
トークンコミュニケータ１６は、何らかの適した標準規格のカード、ピンアレイ、ＵＳＢコネクタ、ＲＦＩＤワイヤレス配置、ブルートゥース（登録商標）、ＷｉＦｉ、あるいはトークンマイクロプロセッサ１４からおよび／またはトークンマイクロプロセッサ１４にメッセージを伝えるのに適した、これらのものを組み合わせたものを含んでいてもよい。
【００２２】
トークン１０は、リーダ１８によって充電できる電源２１（例えば、バッテリ、またはＲＦＩＤのケースではアンテナ等）を備えていてもよい。トークン１０は、コンタクトによってリーダ１８と通信してもよく、または、コンタクトなしでもよい。トークン１０は、それとの対話が望まれている情報源のキーを記憶している何らかのハードウェアデバイス、例えば、国民識別子カードスキームにおける識別子レジストリデータベースであってもよい。トークン１０は、何らかのスマートカード、キー・フォブ、セル電話機のようなポータブルワイヤレスデバイスに組み込まれた機能、トークンホルダに埋め込まれた何らかの組み込まれた機能、あるいはＲＦＩＤタグであってもよい。
【００２３】
例えば、トークンは、プロパティを識別する手段であってもよい。したがって、識別子能力を有する小型ＲＦＩＤトークンは、車ＶＩＮタグまたは車上の他の何らかの適した場所、例えば、隠れた場所にインストールされてもよい。したがって、法執行官は、スキャナデバイスでタグを点検して、例えば、乗り物が盗まれているものであるかどうか、および／または乗り物の税金状況を調査することができるかもしない。
【００２４】
さらに、ＲＦＩＤタイプのタグに関して、従来のタグは、リンク可能な識別子を使用している。したがって、ＲＦＩＤタイプのタグは、短距離からしか読み取ることができない非常に弱い無線信号を使用することが多い。これは、プライバシー問題を制限するが、システムを使用する実際の難しさを非常に増加させる。この後で説明するようなリンク不可能な識別子を使用することによって、至近距離に依存してプライバシー侵害を防ぐ必要性を取り扱うので、ＲＦＩＤタイプのタグの範囲が広がる。
【００２５】
トークン１０はまた、トークンホルダ１２を認証する何らかの統合した手段を有していてもよい。例えば、生体測定認証が、さまざまな技術を用いて使用されてもよい。例えば、指紋、虹彩／網膜スキャン、声、筆跡、歯型、ＤＮＡ情報、およびこれらを組み合わせたものが使用されてもよい。
【００２６】
トークン１０は、空白であっても、または、その上に印刷された情報を持っていてもよい。さらに、トークン１０は、機械読み取り可能な、または読み取り不可能な形態で、トークンホルダ１２の他の識別する特性を含んでいてもよい。
【００２７】
トークン１０は、異なる物理形態ファクタを持っていてもよい。トークンは、国際的に合意されたクレジット形態ファクタおよび／またはＲＦＩＤタグ標準規格に準拠しているカードであってもよい。例えば、国際標準化機構は、ＩＳＯ７８１０において、識別子または識別カードの３つのフォーマット、すなわち、ＩＤ−１、ＩＤ−２、およびＩＤ−３について規定している。
【００２８】
例えば、ＩＤ−１フォーマットは、３．３７０×２．１２５インチに等しい８５．６０×５３．９８ｍｍのサイズを明記している。このフォーマットは、一般的に、ＡＴＭカード、クレジットカード、デビットカード等の銀行取引カードに使用されている。また、このフォーマットはまた、今日、例えば、アメリカ合衆国や、欧州連合のメンバの国々のような多くの国々で運転免許証に使用されている。この標準規格はまた、小売業ロイヤリティカードにも使用されており、名刺向けの１つの極めて一般的なフォーマットである。
【００２９】
さらに、ＩＳＯ７８１３は、例えば０．７６ｍｍの厚さで３．１８ｍｍの半径で角が丸められているＩＤ−１プラスチック性の銀行取引カードの特性を規定している。
【００３０】
ＩＳＯ７８１１は、ＩＤ−１識別カード上にデータを記録するための従来技術、すなわち、エンボス文字のいくつかの異なる磁気記録フォーマットを規定している。ＩＳＯ７８１６は、スマートカード、ならびに、電力、クロック、リセット、およびシリアルデータ信号の接触面のような組み込まれたチップを用いたＩＤ−１識別カード規定している。
【００３１】
ＩＤ−２フォーマットは、４．１３４×２．９１３インチに等しい１０５×７４ｍｍのサイズを明記している。ＩＤ−２フォーマットは、顔写真用に十分なスペースが設けられているが、財布で十分に携帯できるようにさらに小さい。
【００３２】
ＩＤ−３は、４．９２１×３．４６５インチに等しい１２５×８８ｍｍのサイズを明記している。このフォーマットは、パスポートやビサ用に世界中で使用されている。
【００３３】
さらに、ＩＳＯ１４４４３は、組み込まれたチップ（近接カード）や、およそ１３．５６ＭＨｚで動作する、例えば、ＲＦＩＤ向けの、磁気ループアンテナを備えた識別カードを規定している。
【００３４】
ここで先に説明したように、トークンは、国際的に合意された形態ファクタおよび／またはＲＦＩＤタグ標準規格のうちのいずれのものに準拠している形態を採用してもよく、これらを組み合わせたもの、およびこれに適した代替実施形態を含んでいてもよい。トークンはまた、何らかの適した寸法および／または形態であってもよい。
【００３５】
トークンホルダ１２につき、複数のトークン１０が使用されてもよい。言い換えると、トークンホルダ１２が保有、発行される、または取得できる物理的なトークン１０の数に関する制限はない。このことによって、トークンホルダ１２が、トークン１０の故障および／または紛失のケースにおいて使用するために、複製のトークン１０を取得できるかもしれない。
【００３６】
トークン１０は、例えば、人、動物、製品等内に埋め込み可能であってもよい。
【００３７】
リーダ１８は、それとの対話を希望する情報源からデータを読み取る何らかのハードウェアデバイスであってもよい。言い換えると、リーダ１８は、トークン１２上に、または、例えば、識別子レジストリ中に記憶されているデータを読み取ることができる何らかのデバイスであってもよい。リーダ１８は、コンピュータ、キーボード、セル電話機、ＰＤＡ、ワイヤレスデバイス、ならびに他の適した電子デバイスに対して、プラグ接続および／または直接的に接続されていてもよい。さらに、ＦＢＩのような、いくつかの金融および政府エンティティはまた、特別なタイプの安全なリーダを必要とする。
【００３８】
一般的に、図２ａおよび２ｂで示したように、本発明の実施形態にしたがって使用されてもよいプライバシー強化されたスキームでは、トークンホルダ２１２は、信頼性のある当事者２２０のリーダ２１８にトークン２１０を提示してもよい。リーダ２１８は、１つ以上のチャレンジおよび応答を通してトークン２１０と対話してもよい。リーダ２１８には、識別子レジストリ２２２に関係する属性レジストリ２２４からの１つ以上の属性が必要である。識別子レジストリ２２２は、信頼性のある当事者２２０が要求された属性情報を取得することについて認証されているかどうかを確認してもよい。信頼性のある当事者２２０が認証されている場合、属性情報は、識別子レジストリ、１つ以上の属性レジストリ２２４、あるいはこれらを組み合わせたもののうちのいずれかから検索されてもよい。メッセージは、要求された属性を含んでいるかもしれないし、または含んでいないかもしれないが、信頼性のある当事者２２０のリーダ２１８に戻される。
【００３９】
例えば、信頼性のある当事者がマーチャントおよび／またはベンダであり、レジストリがロイヤリティスキームのマネージャおよび／または会社オフィスである場合に、カスタマロイヤリティカードとともに識別子スキームを使用してもよいことが意図されてもよい。このような識別子スキームにおいて、マーチャントは、特定のクラブのカスタマに対して値引きを提案するかもしれない。結果的に、レジストリを通して、マーチャントは、識別子スキームを使用して、カスタマがクラブのメンバであることと、カスタマに値引きを受ける権利があるかどうかとを確認することができる。
【００４０】
また、例えば、信頼性のある当事者が（例えば、ビルディングまたはコンピュータ上のリソースに対する）アクセス制御ポイントであり、レジストリがアクセス制御局である場合に、アクセス制御ポイントにおいて識別子スキームを使用できることも意図してもよい。例えば、このスキームにおいて、従業員が、アクセス制御ポイントで処理されるバッジを持っていてもよい。レジストリは、バッジおよびアクセス制御ポイントから受け取った情報に基づいて、従業員が特定のエリアにアクセスできるか否かを決定するために使用されてもよい。
【００４１】
さらに、信頼性のある当事者がＲＦＩＤリーダ（例えば、キャッシュレジスタ、サプライチェーン制御ポイント）と通信するコンポーネントあり、レジストリが、例えば、クレジットカード会社またはサプライチェーンマネージャーである場合に、ＲＦＩＤタグシステムにおいて識別子スキームを使用してもよいことを意図してもよい。このようなケースにおいて、ＲＦＩＤタグは、本発明の実施形態にしたがったプロトコルにおいてＴＩＤを提供することができる。さらに別の例では、信頼性のある当事者は、生体測定認証システムにおけるノードであってもよい。カスタマが生体測定および他の識別情報を提示したとき、確認のためにレジストリにその情報を送信することができる。例えば、上記のプロトコルでは、カスタマからの生体測定データ、例えば、指紋や、網膜スキャンや、色彩スキャン等が使用されてもよい。
【００４２】
図３ａおよび３ｂでは、パブリックおよびプライベートキー暗号化技術を使用して、信頼性のある当事者にトークンホルダの属性を選択的に配信する方法を示しており、これは本発明の実施形態にしたがって使用されてもよいものである。ここで説明して開示した方法は、例示であり、さまざまなシーケンスで実行されてもよく、開示したステップのうちのいくつか、またはすべては、依然として本発明の実施形態の精神または範囲内のままで、説明したものとは異なる順序で実行されてもよい。
【００４３】
以下のステップでは、説明したプライベートキー動作の代わりに、非対称キー動作を用いてもよく、または、その逆であってもよい。さらに、トークンとリーダとの間の通信は、デートスタンプ全体というよりむしろ、デートスタンプの一方向のダイジェスト関数、すなわちハッシュをトークンからリーダに送信することによって圧縮してもよい。
【００４４】
３１０から分かるように、トークンホルダは、信頼性のある当事者のリーダにトークンを提示してもよい。リーダは、リーダ識別子（ＲＩＤ）を持っていてもよい。リーダ識別子は、リーダに対して一意的な識別子であってもよい。
【００４５】
リーダは、ランダムnonce値、Rnonce３２０を発生させてもよい。Rnonceは、リーダによって発生されたランダム値であってもよい。カウンタ方法は、nonce値を発生させるために使用されるが、ランダムまたは擬似ランダムデータに適した情報源が使用されてもよい。例えば、リーダは、組み込まれた真のランダム数発生器を持っていてもよい。３３０において、Challenge＝｛Rnonce, （ＲＩＤ)｝のようなチャレンジが、リーダによって発生されてもよい。
【００４６】
デートスタンプが追加されてもよい。デートスタンプは、識別子レジストリによって確認可能である時間値を表わす不明瞭なビットシーケンスであってもよい。例えば、指定された時間ウィンドウ内に、トークンに対してチャレンジが提示されたことを証明するために、信頼されている情報源から取得されサインされた時間値が含まれていてもよい。信頼されていないデート値の使用は、リプライ攻撃が脅威でない状況において受け入れ可能であってもよい。
【００４７】
チャレンジは、レジストリから要求されるべき属性情報の記述を組み込んでいてもよい。
【００４８】
チャレンジは、リーダによってトークンに送信されてもよい。３４０において、トークンはチャレンジを受け取り、それ自体のnonce、すなわちTnonceを発生させる。
【００４９】
Tnonceは、カウンタ方法を使用して、発生されてもよく、またはランダムまたは擬似ランダムデータの何らかの適したデータ源を使用することができる。例えば、トークンは、組み込まれた真のランダム数発生器を持っていてもよい。
【００５０】
３５０では、TnonceおよびRnonceの２つのnonce値とリーダ識別子（ＲＩＤ）とが、ハッシュ関数（Ｈ）に入力されてもよい。ハッシュ関数（Ｈ）は、値、Ｈｖを生成することができ、この値は、ハッシュアルゴリズムを使用して、基本入力数から計算されてもよい。言い換えると、ハッシュ値は、入力数のサマリであってもよい。
【００５１】
値（Ｈｖ）は、トークンのみに知られているプライベートキーを使用してサインされてもよい。
【００５２】
Tnonce値およびハッシュ関数の使用は、平文テキスト攻撃として知られている暗号解析攻撃のクラスに対して保護を提供してもよい。リーダ識別子（ＲＩＤ）値のハッシュ値（Ｈｖ）への組み込みは、指定されたリーダから属性を要求するためにトークンが使用されたことを識別子レジストリが決定できることを確実にすることができる。類似したフォーマットの攻撃を防ぐために、付加的な情報をチャレンジ中に含めてもよい。
【００５３】
この時に、リーダに対してパブリックキー値が利用可能であった場合、リーダはハッシュ値を再構成する従来の暗号技術を使用して、トークンを認証することができるかもしれない。しかしながら、パブリックキーは、一般的に、リーダに対して利用可能であることはなく、代わりに、リーダは、リンク不可能な識別子（ＸＩＤ）値を持っており、これは、以下でより詳細に説明するが、識別子レジストリによってのみ解釈できる。
【００５４】
それにもかかわらず、選択された署名アルゴリズムが安全であり、かつ、Rnonce値が一意的であり、かつ、プライベートキー値がトークンにのみに知られているのであれば、トークンによってのみ署名値を生成することができる。
【００５５】
３６０において、リンク不可能な識別子（ＸＩＤ）を計算してもよい。トークンが提示されるごとに、異なるリンク不可能な識別子（ＸＩＤ）値が生成されるように、例えば、リンク不可能な識別子は、セッションキーを使用して、プライベートシリアル番号またはトークンの他の識別子、すなわち（ＴＩＤ）を暗号化することによって計算してもよい。セッションキー自体は、識別子レジストリのパブリック暗号キーを使用して暗号化することができる。トークンは、異なる目的に使用される複数のリンク不可能な識別子を含んでいてもよい。
【００５６】
３７０において、トークン応答が発生されてもよい。トークン応答は、リーダに対する、署名値（Ｈｖ）、値Tnonce、リンク不可能な識別子（ＸＩＤ）を含んでいてもよい。したがって、応答は、不明瞭でリンク不可能な応答であってもよい。例えば、応答は、  
Response＝｛signature（Ｈ（Tnonce, Rnonce, ＲＩＤ））, Tnonce, ＸＩＤ｝であってもよく、
ここで、ＸＩＤ＝｛Ｅ（ｋ, Ｐ）,Ｅ（ＴＩＤ, ｋ）｝であり、
Ｐ＝レジストリのパブリック暗号キーであり、
ＴＩＤ＝トークンのプライベート識別子であり、
ｋ＝ランダムに選択されたセッションキーであり、
Ｅ＝キーｋに基づいたメッセージの暗号であり、
Ｅ（ｋ, Ｐ）＝パブリックキーＰを使用して暗号化されたセッションキーｋであり、
Ｅ（ＴＩＤ, ｋ）＝セッションキーを使用して暗号化されたＴＩＤである。
【００５７】
応答はまた、ワンタイムパスワード（ＯＴＰ）、ならびに／あるいは、トークンおよび／またはトークンホルダによって発生された生体測定データを含んでいてもよい。
【００５８】
次に、ステップ３８０から分かるように、トークン応答は識別子レジストリに提示されてもよい。リーダが、属性のリストとともに、トークンからの応答と値Rnonceとを識別子レジストリに送ってもよい。識別子レジストリに対する属性要求は、リーダに対して一意的なプライベートキーを使用してサインしてもよい。ステップ３８０では、トークン応答はリーダ応答として提示されてもよい。例えば、リーダ応答は、Ｒ＝｛Token Response, Rnonce, AttributeList, Authentication Data｝であってもよく、要求が許可されるべきか否かをレジストリが決定できるように属性リストと認証データとを含んでいてもよい。属性リストは、リーダが要求する識別子に結びついた属性（例えば、年齢、性別、体重、アレルギー等）を含んでいてもよい。認証データは、要求が許可されるかどうかを決定する際に、識別子レジストリに役立つ何らかの情報であってもよい。
【００５９】
何らかの適したプレゼントメントプロトコルを使用してもよい。例えば、ＷＳ−セキュリティまたはＳＡＭＬのような、ウェブサービスベースのプロトコルを使用してもよい。望まれる場合に、基本プロトコルが、リーダのプライバシーに提供されてもよい。
【００６０】
図３ｂに移ると、３９０において、予測された値と適切に認証された要求者との一致を保証するために、署名値｛signature（Ｈ（Tnonce, Rnonce, ＲＩＤ））｝や、デートスタンプ値のような情報、ならびに／あるいは、ＯＴＰおよび／または生体測定データのような認証データを確認することによって、要求においてリストアップされている属性を受け取ることについてリーダが認証されているかどうかを識別子レジストリが決定してもよい。
【００６１】
３９５から分かるように、識別子レジストリは、そのプライベートキーを使用して、リンク不可能な識別子（ＸＩＤ）を解読して、一意的なトークン識別子（ＴＩＤ）を取得する。トークン識別子（ＴＩＤ）を使用して、トークンプロフィールをデータベースから検索してもよい。データベースは、トークンに対応しているパブリックキーと、おそらくは、トークンホルダの名前、社会保障番号、税金識別子のような他の情報、すなわち要求を確認するための他の関連情報とを含んでいてもよい。代わりに、同じ情報が、トークン識別子（ＴＩＤ）自体にエンコードされてもよい。この仕組みによって、ローカルデータベースの必要性を無くすことができる。
【００６２】
ステップ４００から分かるように、一度、識別子レジストリがトークンを識別すると、何らかの適したプロトコルを使用して、トークンホルダに関する属性表明を１つ以上の属性レジストリから検索し、ＳＡＭＬのような識別子レジストリのプライバシーを保護してもよい。
【００６３】
本発明の実施形態にしたがうと、認証データベースを使用することにより、トークンホルダのプライバシーを保護するために、認証されている属性のみがリーダに対して確実に送信することが可能になる。例えば、バーにおけるマーチャントにリーダが割り当てられている場合、リーダは、トークンホルダの「年齢」の属性のみを受け取ることについて認証されるかもしれない。リーダが病院である場合、リーダは、トークンホルダのメディカル情報（例えば、年齢、病歴、現在の投薬、等）を受け取ることについて認証されてもよい。いずれにしても、リーダによって提示されたトークンホルダ情報に対する要求を、例えば、レジストリによって、そのリーダに対する属性認証（または、リーダのタイプまたはクラス）と比較することができる。要求された属性情報を受け取ることについてリーダが認証されていると決定された場合のみに、要求された属性情報をリーダに戻すことができる。
【００６４】
４１０から分かるように、識別子レジストリは、メッセージをリーダに戻すが、このメッセージは、要求された属性を含むかもしれないし、含まないかもしれない。
【００６５】
例えば、４２０ａ、４２０ｂ、４２０ｃ、および４２０ｄから分かるように、さまざまなメッセージが、属性要求に応答して、識別子レジストリによって発生されてもよい。４２０ａないしｄの例は単なる例示であり、多くの適したメッセージが本発明の実施形態にしたがって発生されてもよいことを理解すべきである。４２０ａにおいて、要求に応じて、属性が、識別子レジストリからリーダに戻されてもよい。４２０ｂから分かるように、エラーメッセージが識別子レジストリからリーダに戻されてもよい。４２０ｃから分かるように、要求された属性が利用可能でないことを示しているメッセージが発生されてもよい。４２０ｄにおいて、アクセスを拒否するメッセージが、識別子レジストリからリーダに戻されてもよい。
【００６６】
発生されたメッセージは多数の可能性を網羅しているかもしれない。例えば、トークンが盗難または紛失であると報告されている場合や、信頼性のある当事者が何らかの情報を受け取るのを妨げる状況や、ハードウェア故障や、認証は成功したが、属性情報は利用可能でない場合を網羅している。
【００６７】
国民識別子データベースは、１つ以上の独立した属性レジストリを有していても、独立した属性レジストリを有していなくてもよい。国民識別子データベースおよび属性レジストリは以下のものに限定されないが、個人情報、識別情報、居住ステータス、個人参照番号、レコード経歴、登録およびＩＤカード履歴、確認情報、セキュリティ情報、情報の提供のレコードを記録してもよい。
【００６８】
個人情報は、フルネーム、それによってその人が知られている他の名前、誕生日、出生地、性別、居住地、過去の居住地を含んでいてもよい。識別情報は、上半身の写真、署名、指紋、および他の生体測定情報を含んでいてもよい。居住ステータスは、国籍、国に滞在する資格、入国または滞在に対する許可の期間および条件を含んでいてもよい。個人参照番号は、国民識別子登録番号、発行された何らかのＩＤカードの番号、何らかの国民保険番号、何らかの入国書類またはパスポートの番号、運転免許証番号、労働許可書、あるいは上記の書類を組み合わせたものを含んでいてもよい。レコード経歴は、以前に記載された情報の何らかのものに対する変更を含んでいてもよい。
【００６９】
登録およびＩＤカードの履歴は、申請、変更、確認、除外、効力、届け出（例えば、紛失、盗難、破損）、譲渡、およびカードの登録およびＩＤの副署の日付を含んでいてもよい。
【００７０】
レジストリのアクションは、監査を条件としてもよい。レジストリの動作は、信頼できるハードウェアによって監査されてもよい。本発明は、識別子レジストリと属性レジストリとの間の対話を監査するプロセスに役立つ手段を含んでいてもよい。
【００７１】
本発明の実施形態は、信頼性のある当事者に対して不明瞭になるようにトークン識別子を暗号化し、かつ、トークン識別子をレジストリによってのみトークンホルダにリンクできる他の実施形態を含んでいてもよい。トークンホルダについてのどのデータを受け取る権利が信頼性のある当事者に与えられているかを確立するプロフィール情報を、レジストリまたは認証された当事者が調査して、信頼性のある当事者に受け取る権利がある、トークンホルダについての情報（または、このサブセット）のみ配信してもよい。トークンホルダについての残りの情報のプライバシーは、信頼性のある当事者に対して不当に開示されることから保護される。互いに対して、またはトークンホルダに対して、リンク不可能なように、不明瞭な識別子にすることができる。これらの機能を実行するための何らかの適した技術は、本発明によって含められる。
【００７２】
トークンの使用によって、さまざまな信頼のある当事者が、異なるセットの情報を受け取ることができ、異なるセットの情報は、レジストリによってそれぞれに対して制御できる。レジストリは、信頼性のある当事者に対するＲＩＤ（リーダ識別子）を、認証データベースまたは他のオーソリティにおける１つ以上のエントリと相関させることによって、この機能を実行することができる。
【００７３】
さらに別の実施形態では、ソフトトークンを使用することができる。リーダは、パーソナルコンピュータ、ワイヤレスハンドセット、ゲームコンソール等（「コンピューティングデバイス」）のようなコンピューティングデバイス上で実行しているアプリケーションであってもよい。このような実施形態では、リーダアプリケーションが、ユーザ、ユーザアプリケーション、オペレーティングシステムのコンポーネント等（「ソフトトークン」）に対して、チャレンジを発行することができる。リーダアプリケーションは、ソフトトークンからの応答を受け取り、リーダアプリケーションはレジストリに情報に対する要求を送ることができ、ここでは、要求は、ソフトトークンから受け取られた応答に基づいたものであってもよい。
【００７４】
本発明を説明するためにさまざまな実施形態を選択してきたが、特許請求の範囲に規定したような、本発明の範囲から逸脱することなく、さまざまな変更および修正をここで行うことをできることが当業者によって理解されるであろう。
【図面の簡単な説明】
【００７５】
【図１】図１は、本発明の実施形態にしたがって使用されてもよいトークンおよびリーダを示している。
【図２Ａ】図２Ａは、チャレンジを発生させる図１のリーダと、応答を発生させる図１のトークンとを示している。
【図２Ｂ】図２Ｂは、本発明の実施形態にしたがって使用されてもよいトークン、トークンホルダ、信頼性のある当事者、信頼性のある当事者リーダ、識別子レジスタ、および複数の属性レジストリのブロック図を示している。
【図３Ａ】図３Ａは、パブリックおよびプライベートキー暗号化技術を使用して、トークンホルダの属性を選択的に信頼性のある当事者に配信する方法を示している。
【図３Ｂ】図３Ｂは、本発明の実施形態にしたがって使用されてもよい方法ステップを示している。
【図１】
2009535900.tif 000003
【図２Ａ】
2009535900.tif 000004
【図２Ｂ】
2009535900.tif 000005
【図３Ａ】
2009535900.tif 000006
【図３Ｂ】
2009535900.tif 000007
【国際調査報告】
2009535900.tif 000008