知財求人 - 知財ポータルサイト「IP Force」
(19)【発行国】日本国特許庁(JP)
(12)【公報種別】公表特許公報(A)
(11)【公表番号】
(43)【公表日】2024-12-03
(54)【発明の名称】プライベート証明書の否認不能な承認
(51)【国際特許分類】
H04L 9/32 20060101AFI20241126BHJP
H04L 9/08 20060101ALI20241126BHJP
【ＦＩ】
H04L9/32 200D
H04L9/32 200E
H04L9/08 F
【審査請求】有
【予備審査請求】未請求
(21)【出願番号】P 2024533204
(86)(22)【出願日】2022-12-02
(85)【翻訳文提出日】2024-07-29
(86)【国際出願番号】 EP2022084289
(87)【国際公開番号】W WO2023099767
(87)【国際公開日】2023-06-08
(31)【優先権主張番号】21306698.8
(32)【優先日】2021-12-03
(33)【優先権主張国・地域又は機関】EP
(81)【指定国・地域】
【公序良俗違反の表示】
（特許庁注：以下のものは登録商標）
１．ＢＬＵＥＴＯＯＴＨ
２．ＪＡＶＡ
３．ＰＹＴＨＯＮ
(71)【出願人】
【識別番号】522230381
【氏名又は名称】タレス ディアイエス フランス エスアーエス
(74)【代理人】
【識別番号】110001173
【氏名又は名称】弁理士法人川口國際特許事務所
(72)【発明者】
【氏名】フレデリック ロマーン
(72)【発明者】
【氏名】ジョルジュ ドゥボワ
(72)【発明者】
【氏名】ムラド ファエール
(57)【要約】
プライベート証明書（１１１）の否認不能な承認のための方法（２００）が提供される。方法は、証明書を宣言するユーザからの要求に応答してプライベート属性プロバイダ（１１０）から証明書を受信すること、発行局（１２０）に認証された後、ユーザが選択した証明書内の極めて重要な属性を安全にバインドすること、及び接続されたデバイス（１００）を介してユーザを証明書に安全にバインドすることを含む。方法は、署名されたサーバプルーフ（３６０）を含む承認された証明書（４００）を生成する。これは、サービス（１５１）を受けるために、ユーザによって接続されたデバイスを介してサービスプロバイダに提供され、そうでなければ第三者の信頼できる証明を必要とする。他の実施形態も開示される。
【選択図】 図３
【選択図】 図３
【特許請求の範囲】
【請求項1】
プライベート証明書の否認不能な承認のための方法（２００）であって、前記方法が、対応する属性名及び属性値を有する属性（３０３）と、任意選択のＰＡＰ署名（３０４）とを含む証明書（１１１）をプライベート属性プロバイダ（ＰＡＰ）から受信する（２０２）ことを含み、
前記方法が、
・ 接続されたデバイス（１００）のユーザを前記証明書（１１１）にバインドする（４０７）ことを、
ユーザ認証属性名のセット（３０２）を前記ユーザが選択した前記属性（３０２）から収集し、
前記ユーザを発行局（１２０）に対して認証し、
公開鍵（ＰｕＫ）及び秘密鍵（ＰｒＫ）（１０２）からなる、前記ユーザの鍵ペアを生成し、
前記公開鍵（ＰｕＫ）を前記発行局（１２０）に送信すること
によって行うこと、及び
・ 極めて重要な属性（３０２）を前記発行局の同等の属性にバインドする（４０８）ことを、
前記発行局にユーザを認可し、それに基づいて前記証明書を承認するように要求し、
前記ユーザ認証属性名のセット（３０２）を検証し、
検証された場合に、
前記発行局から署名されたサーバプルーフ（３６０）を受信すること
によって行うことを特徴とする方法。
【請求項2】
前記署名されたサーバプルーフ（３６０）を検証者チャレンジ（３４２）と集約して検証者ブロブ（３４０）を生成すること、前記検証者ブロブ（３４０）に前記秘密鍵（ＰｒＫ）（１０２）で署名してモバイル署名済みブロブを生成すること、
前記証明書（１１１）を前記モバイル署名済みブロブ（３２０）とパッケージ化して承認済み証明書（４００）を生成すること、及び
前記承認済み証明書（４００）を検証者（１３０）に提示して、前記検証者が提供するサービス（１５１）にアクセスすることを更に含む、請求項１の方法。
【請求項3】
前記極めて重要な属性をバインドするステップについて、前記発行局が、前記ユーザ認証属性名のセットの同等の対応する属性値に対する有効性をチェックする（２１０）ステップ、
有効である場合に、前記証明書を、前記ユーザ認証属性名のセット及びハッシュ化された証明書及びハッシュ化された公開鍵とともに承認するステップ、
前記署名されたサーバプルーフを返す（２１２）ステップ、そうではなく
有効でない場合に、前記証明書を承認しないステップを実行し、
前記承認することが、前記サーバプルーフに署名して、前記ハッシュ化された証明書（３７０）、前記ユーザ認証属性名のハッシュ（３７１）、発行局チャレンジ（３７２）、及び前記ハッシュ化された公開鍵（３７３）を含む前記署名されたサーバプルーフを生成する、請求項１の方法。
【請求項4】
前記承認済み証明書（４００）が、前記証明書（３００）及び、任意選択で前記ＰＡＰ署名（３０４）と、
前記モバイル署名済みブロブ（３２０）とを含み、
前記モバイル署名済みブロブ（３２０）が、
秘密鍵（ＰｒＫ）を使用する前記検証者ブロブ上の接続デバイス署名と、
前記検証者ブロブ（３４０）とを含み、
前記検証者ブロブ（３４０）が、
前記検証者チャレンジ（３７２）と、
前記署名されたサーバプルーフ（３６０）とを含み、
前記署名されたサーバプルーフ（３６０）が、
前記ハッシュ化された証明書（３７０）と、
前記ユーザ認証属性名の前記ハッシュ（３７３）と、
前記発行局チャレンジ（３４２）と、
前記ハッシュ化された公開鍵（３７３）と、
発行局署名（３２２）とを含む、請求項３の方法。
【請求項5】
前記証明書を、前記ユーザ認証属性名のセット及びハッシュ化された証明書及びハッシュ化された公開鍵とともに承認するステップが、前記ユーザを前記接続されたデバイスの前記鍵ペアにバインドする（４０７）ことによって、前記ユーザが前記接続デバイス署名を否定することを防ぐ、請求項４の方法。
【請求項6】
前記有効性をチェックする（２１０）ステップが、前記ユーザ認証属性名を、市民登録簿、身分証明書登録簿、行政登録簿、又は前記接続デバイスのユーザの接続デバイス認証のための事前に登録された情報の任意のソースに対して認証することを含む、請求項２の方法。
【請求項7】
前記サービスへの前記アクセスが、前記デバイス鍵を保持するデバイスのユーザに権利又は特権を与え、前記証明書が更に、前記ＰＡＰによる前記アクセスを制限する前記属性の使用目的を含み、前記証明書における前記目的が、利用規約、有効期限、又は前記承認済み証明書を使用するための他の条件付き手段を含む、請求項１の方法。
【請求項8】
前記発行局による前記承認済み証明書の使用を制限するために利用規約、有効期限、又は他の条件付き手段を前記発行局チャレンジに含むことを更に含む、請求項１の方法。
【請求項9】
接続されたデバイス（１００）を介したプライベート証明書の否認不能な事前承認のための方法（６００）であって、前記方法が、無署名の証明書（２９９）をプライベート属性プロバイダ（ＰＡＰ）（１１０）から受信することを含み、前記方法が更に、
前記証明書が、属性、対応する属性名及び値、並びにＰＡＰチャレンジ（６０４）を含むこと、
・ 前記接続されたデバイスのユーザを前記証明書にバインドする（６０２）ことを、
前記ユーザが選択した前記属性からユーザ認証属性名のセットを収集し、
前記ユーザを発行局に対して認証し、
公開鍵（ＰｕＫ）及び秘密鍵（ＰｒＫ）を含む、前記ユーザの鍵ペアを生成し、
前記公開鍵（ＰｕＫ）を前記発行局に送信すること
によって行うこと、及び
・ 極めて重要な属性を発行局の同等の属性にバインドする（６０８）ことを、
前記発行局にそれに基づいて前記証明書を承認する許可を要求し、
前記ユーザ認証属性名のセットを検証し、
検証された場合に、
前記発行局から署名されたサーバプルーフを受信し、
前記署名されたサーバプルーフを前記ＰＡＰチャレンジと集約して事前承認されたブロブを生成し、
前記事前承認されたブロブに前記秘密鍵で署名して、モバイル署名済み事前承認ブロブを生成し、
前記モバイル署名済み事前承認ブロブ（６３０）を前記ＰＡＰ（１１０）に認証のために提示し（６１０）、認証された（６１２）場合に、
ＰＡＰ署名済み（３８８）証明書（３００）を受信し（６１４）、
承認済み証明書（４００）を検証者チャレンジ（３４２）で再構築する（６１６）こと
によって行うことを特徴とする方法（６００）。
【請求項10】
前記承認済み証明書を再構築するステップが、前記署名されたサーバプルーフを前記検証者チャレンジと集約して検証者ブロブ（６３０）を生成すること、
前記検証者ブロブに前記秘密鍵（ＰｒＫ）で署名してモバイル署名済みブロブを生成すること、
前記ＰＡＰ署名済み証明書（３００）を前記モバイル署名済みブロブ（６３０）とパッケージ化して承認済み証明書（４００）を生成すること、及び
前記承認済み証明書（４００）を前記検証者（１３０）に提示して、前記検証者が提供するサービス（１５１）にアクセスすることを含む、請求項９の方法。
【請求項11】
プライベート証明書の否認不能な承認のためのシステムであって、発行局（１２０）と、
検証者（１３０）と、
属性及び対応する属性値を含む証明書（４００）を提供するプライベート属性プロバイダ（ＰＡＰ）（１１０）と、
ユーザが操作する接続デバイス（１００）とを備え、前記接続デバイスが更に、
・ 前記ユーザを前記証明書にバインドし、
・ 極めて重要な属性を前記発行局の同等の属性にバインドし、
前記バインドすることに応答して、
前記発行局から受信した署名されたサーバプルーフを前記検証者からの検証者チャレンジと集約して検証者ブロブを生成し、
前記検証者ブロブに署名してモバイル署名済みブロブを生成し、
前記証明書を前記モバイル署名済みブロブとパッケージ化して承認済み証明書を生成し、
前記承認済み証明書を前記検証者に提示して、前記検証者が提供するサービスにアクセスすることを特徴とするシステム。
【請求項12】
前記接続されたデバイスが、前記ユーザを前記証明書にバインドすることが、前記ユーザが選択した前記属性から、属性値ではなくユーザ認証属性名のセットを収集し、
前記ユーザを前記発行局に対して認証し、
公開鍵（ＰｕＫ）及び秘密鍵（ＰｒＫ）を含む、前記ユーザの鍵ペアを生成し、
前記公開鍵（ＰｕＫ）を前記発行局に送信する
ことによって行われる、請求項１１のシステム。
【請求項13】
前記接続されたデバイスが、極めて重要な属性を前記発行局の同等の属性にバインドすることが、前記発行局にそれに基づいて前記証明書を承認する許可を要求し、
前記ユーザ認証属性名のセットを検証し、
検証された場合に、
前記発行局から前記署名されたサーバプルーフを受信する
ことによって行われる、請求項１２のシステム。
【請求項14】
前記発行局が、前記ユーザ認証属性名のセットのそれ自体の対応する属性値に対する有効性をチェックし、
有効である場合に、前記証明書を、前記ユーザ認証属性名のセット及びハッシュ化された証明書及びハッシュ化された公開鍵とともに承認し、
前記署名されたサーバプルーフを返し、そうではなく、
有効でない場合に、前記証明書を承認せず、
前記発行局が、前記サーバプルーフに署名して、前記ハッシュ化された証明書、前記ユーザ認証属性名のハッシュ、発行局チャレンジ、及び前記ハッシュ化された公開鍵を含む前記署名されたサーバプルーフを生成する、請求項１３のシステム。
【請求項15】
プライベート証明書の否認不能な承認のための接続デバイス（１００）であって、電力を供給する電源（８７０）と、
命令及びデータを格納するメモリ（８２０）と、
データを送受信する通信モジュール（８５０）と、
情報を提示し、ユーザ入力を受信するディスプレイ（８８０）と、
コンピュータプログラムを実行するプロセッサ（８１０）とを備え、
前記コンピュータプログラムが、計算環境において少なくとも１つの中央処理装置（ＣＰＵ）により実行されるプログラムコードを格納する非一時的コンピュータ可読媒体を備え、前記プログラムコードの実行が、前記少なくとも１つのＣＰＵに、プライベート属性プロバイダ（ＰＡＰ）から属性及び対応する属性値を含む証明書を受信することを含む動作を実行させ、更に、
・ 前記接続されたデバイスのユーザを前記証明書にバインドすることを、
前記ユーザが前記ディスプレイを介して選択した前記属性から、属性値ではなくユーザ認証属性名のセットを収集し、
前記ユーザを発行局に対して認証し、
公開鍵（ＰｕＫ）及び秘密鍵（ＰｒＫ）を含む、前記ユーザの鍵ペアを生成し、前記メモリに格納し、
前記公開鍵（ＰｕＫ）を前記発行局に前記通信モジュールを介して送信すること
によって行うこと、及び
・ 前記属性の極めて重要な属性を発行局の同等の属性にバインドすることを、
前記発行局にそれに基づいて前記証明書を承認する許可を要求し、
前記ユーザ認証属性名のセットを検証し、
検証された場合に、
前記発行局から署名されたサーバプルーフを受信し、
前記署名されたサーバプルーフを検証者チャレンジと集約して検証者ブロブを生成し、
前記検証者ブロブに前記秘密鍵（ＰｒＫ）で署名して、モバイル署名済みブロブを生成し、
前記証明書を前記モバイル署名済みブロブとパッケージ化して承認済み証明書を生成し、
前記承認済み証明書を検証者に提示して、前記検証者が提供するサービスにアクセスすること
によって行うことを特徴とする接続デバイス（１００）。
【発明の詳細な説明】
【技術分野】
【0001】
本発明は、電子認証及び証明の技術分野に関する。本発明の１つ以上の実施形態は、概して暗号認証の分野に関する。より具体的には、実施形態は証明の確認のための方法及びシステムに関する。
【0002】
本発明は、トラストチェーンが存在しない場合に、属性プロバイダにより独立したサービスプロバイダに発行された個人文書の真正性を検証及び証明するための新しく開発された方法に関する。
【0003】
本発明は、私的に証明された文書の真正性に関する信頼性の懸念を和らげる手段を想定している。有利には、本発明は、プライベート証明書の信頼性を高めたいと考えているユーザに、証明書の承認のための技術的なメカニズムを提供する。
【背景技術】
【0004】
認証とは、個人がシステムにアクセスする権限を与えるシステムでユーザのＩＤを確認するセキュリティプロセス、例えばサインオンプロセスである。認証が重要なのは、ユーザが作成する、変更する、又は見るエントリに対する責任をユーザに割り当てるためである。オーサーシップとは、特定の情報単位の創作又は創造を、特定の時点で行動する特定の個人又はエンティティに帰属させることである。
【0005】
証明とは、公文書の署名に立会い、またその内容に拘束される人々によって適切に署名されたことを確認するために署名する行為である。証明とは、文書の真正性を法的に認め、適切なプロセスが踏まれたことを確認することである。証明はまた、特定の情報単位のオーサーシップと法的責任を示す、コンテンツに電子署名を施す行為である可能性がある。電子署名とは、電子記録に署名し、証明するさまざまな方法を指す、一般的な技術的に中立な用語である。
【0006】
問題：プライベート属性プロバイダ（例えば学術機関、企業、協会など）からのデジタル証明書（例えば卒業証書、資格証明書など）は、たとえ正式又は公式な手段で配送されたとしても、一般的には疑わしいものと見なされる。これらの証明書は、信頼度が一定ではなく、マスターリストや信頼リストに結び付けられていない。多くの場合、プライベート属性プロバイダは、依拠当事者の観点からは未知の発行局である。そのようなプライベート証明書は、ユーザが単独で依拠当事者に配送した場合に、ユーザが変更したり、偽造コピーであったりする可能性があるため、信頼できるものでないことになる。したがって、依拠当事者がユーザにプライベート属性プロバイダ（例えば学術機関）により発行されたデジタル証明書の提示を要求する場合に、依拠当事者は、デジタル証明書がそれを提示するユーザのものであり、信頼できるソースによってその真正性が確認されていることを確信したいと考える。
【0007】
現在、組織は、電子署名、証明、及びユーザ文書のオーサーシップに関する特定的な既存の情報を確認するために、個別のリソースにアクセスする必要がある。そのようなタイプの確認は、コストと時間のかかる作業である。特に、ユーザ識別に関連する確認では、ユーザ情報と個人データの共有に関するプライバシーの問題が問題になる。個々のユーザのすべてのＩＤ情報を保持する共通システムはない。また、ユーザのＩＤのデバイス証明のための、圧倒的に受け入れられている単一の標準、法律、又は規則はない。
【0008】
特定の仕様（ＧＰ、ＩＳＯ、ＥＴＳＩ、ＣＥＮ／ＣＥＮＥＬＥＣ、Ｗ３Ｃ、ＧＳＭＡ）は、デジタルユーザ識別文書の認証及び信頼に関する抽象的な概念を広めているが、具体的な実装を提供していない。この点に関して、ＩＳＯ／ＩＥＣ １８０１３－５は、ＩＤ及び運転権限の使用例について、モバイルＩＤ（ｍＩＤ）及びモバイル運転免許証（ｍＤＬ）と対話する標準化された方法を提案している。グローバルな相互運用性標準に準拠するオープンなｍＤＬ／ｍＩＤエコシステムが、従来のパスポート又はユーザ識別に匹敵する信頼レベルを提供する。ＩＳＯ／ＩＥＣ １８０１３－５の国際ｍＤＬ標準草案は、モバイル運転免許証からＩＤ文書データを取得して信頼するためのメカニズムを提供することを目指しているが、仕様は複雑で、実装の詳細については何も述べていない。
【0009】
これらの標準提案の問題点は、プライベート属性プロバイダからのデジタル証明書の承認の実施を提供していないことである。そのようなＩＤ証明は時間及びコストがかかり、依拠当事者が複雑な資格情報を独自に確認することのメリットは一般的にあまりない。また、政府又は公的機関は、デジタル資格情報の確認を求められた場合に、保険責任が認めるよりも多くのデータを提供することに同意したがらない。
【0010】
本発明は、既存の限界を克服し、例えば接続されたデバイスを介してユーザがプライベート証明書の信頼性を高めようとしている暗号化エコシステムにおいて、プライベート属性プロバイダと民間サービスプロバイダのより密接な関与を有利に提供するソリューションを提供する。
【発明の概要】
【0011】
第１の実施形態では、プライベート証明書の否認不能な承認のための方法が提供される。この方法は、プライベート属性プロバイダ（ＰＡＰ）から証明書を受信するステップを含み、証明書は、対応する属性名及び値を有する属性、並びにＰＡＰにより署名された任意選択のＰＡＰ署名を含み、
・ 接続されたデバイスのユーザを証明書にバインドすること、及び
・ 極めて重要な属性を発行局の同等の属性にバインドすること
によって更に特徴付けられる。
・ 接続されたデバイスのユーザを証明書にバインドすること、及び
・ 極めて重要な属性を発行局の同等の属性にバインドすること
によって更に特徴付けられる。
【0012】
上記の２つのバインディングにより、最新技術よりも強力な信頼性の強化がもたらされる。接続されたデバイスのユーザを証明書にバインドするステップは、ユーザが選択した属性からユーザ認証属性名のセットを収集すること、発行局に対してユーザを認証すること、公開鍵（ＰｕＫ）及び秘密鍵（ＰｒＫ）を含むユーザの鍵ペアを生成すること、及び公開鍵（ＰｕＫ）を発行局に送信することを含む。極めて重要な属性を発行局の同等の属性にバインドするステップは、発行局にユーザを認証し、それに基づいて証明書を承認するように要求すること、及びユーザ認証属性名のセットを検証することを含む。検証された場合に、方法は、発行局から署名されたサーバプルーフ（Ｓｅｒｖｅｒ Ｐｒｏｏｆ）を受信すること、署名されたサーバプルーフを検証者チャレンジ（Ｖｅｒｉｆｉｅｒ Ｃｈａｌｌｅｎｇｅ）と集約して検証者ブロブ（Ｖｅｒｉｆｉｅｒ Ｂｌｏｂ）を生成すること、検証者ブロブに秘密鍵（ＰｒＫ）で署名してモバイル署名済みブロブ（Ｍｏｂｉｌｅ Ｓｉｇｎｅｄ Ｂｌｏｂ）を生成すること、証明書をモバイル署名済みブロブとパッケージ化して承認済み証明書（Ｅｎｄｏｒｓｅｄ Ａｔｔｅｓｔａｔｉｏｎ）を生成すること、そして、承認済み証明書を検証者に提示して検証者が提供するサービスにアクセスすることを含む。極めて重要な属性をバインドするステップでは、発行局は、ユーザ認証属性名のセットの同等の対応する属性値に対する有効性をチェックし、有効である場合に、ユーザ認証属性名のセット及びハッシュ化された証明書及びハッシュ化された公開鍵とともに証明書を承認するステップと、署名されたサーバプルーフを返すステップと、そうではなく、有効でない場合に、証明書を承認しないステップとを実行する。
【0013】
承認するステップは、サーバプルーフに署名して、ハッシュ化された証明書、ユーザ認証属性名のハッシュ、発行局チャレンジ、及びハッシュ化された公開鍵を含む署名されたサーバプルーフを生成することを含む。承認済み証明書は、証明書及び任意選択のＰＡＰ署名、並びに秘密鍵（ＰｒＫ）を使用した検証者ブロブに対する接続デバイス署名、及び検証者ブロブを含むモバイル署名済みブロブを含む。検証者ブロブは、検証者チャレンジ、及び署名されたサーバプルーフを含む。署名されたサーバプルーフは、ハッシュ化された証明書、ユーザ認証属性名のハッシュ、発行局チャレンジ、ハッシュ化された公開鍵、及び発行局署名を含む。有効性をチェックするステップは、ユーザ認証属性名を、市民登録簿、身分証明書登録簿、行政登録簿、又は接続デバイスのユーザの接続デバイス認証のための事前に登録された情報の任意のソースに対して認証することを含む。サービスへのアクセスは、デバイス鍵を保持するデバイスのユーザに権利又は特権を与える。
【0014】
証明書は更に、ＰＡＰによるアクセスを制限する属性を使用する目的を含む可能性があり、証明書内の目的は、利用規約、有効期限、又は承認済み証明書を使用するための他の条件付き手段を含む。利用規約、有効期限、又は他の条件付き手段は、発行局チャレンジに含められて、発行局による承認済み証明書の使用を制限する可能性がある。証明書をユーザ認証属性名のセット及びハッシュ化された証明書及びハッシュ化された公開鍵とともに承認することが、ユーザを接続されたデバイスの鍵ペアにバインドし、これによってユーザが接続デバイス署名を否定できないようにする。
【0015】
第２の実施形態では、接続されたデバイスを介したプライベート証明書の否認不能な事前承認のための方法が提供される。この方法は、プライベート属性プロバイダ（ＰＡＰ）から証明書を受信するステップを含み、証明書は、属性、対応する属性名及び値、並びにＰＡＰチャレンジを含み、更に１）接続されたデバイスのユーザを証明書にバインドすること、及び２）極めて重要な属性を発行局の同等の属性にバインドすることによって特徴付けられる。接続されたデバイスのユーザを証明書にバインドするステップは、ユーザが選択した属性からユーザ認証属性名のセットを収集すること、ユーザを発行局に対して認証すること、公開鍵（ＰｕＫ）及び秘密鍵（ＰｒＫ）を含むユーザの鍵ペアを生成すること、及び公開鍵（ＰｕＫ）を発行局に送信することを含む。極めて重要な属性を発行局の同等の属性にバインドするステップは、発行局にそれに基づいて証明書を承認する許可を要求し、ユーザ認証属性名のセットを検証することを含む。
【0016】
検証された場合に、方法は更に、発行局から署名されたサーバプルーフを受信すること、署名されたサーバプルーフをＰＡＰチャレンジと集約して事前承認されたブロブを生成すること、事前承認されたブロブに秘密鍵で署名してモバイル署名済み事前承認ブロブを生成すること、及びモバイル署名済み事前承認ブロブをＰＡＰに認証のために提示することを含む。認証が成功した場合、方法は、ＰＡＰ署名済み証明書を受信すること、及び承認済み証明書を検証者チャレンジで再構築することを含む。承認済み証明書を再構築するステップは、署名されたサーバプルーフを検証者チャレンジと集約して検証者ブロブを生成すること、検証者ブロブに秘密鍵（ＰｒＫ）で署名してモバイル署名済みブロブを生成すること、ＰＡＰ署名済み証明書をモバイル署名済みブロブとパッケージ化して承認済み証明書を生成すること、及び承認済み証明書を検証者に提示して、検証者が提供するサービスにアクセスすることを含む。
【0017】
第３の実施形態では、プライベート証明書の否認不能な承認のためのシステムが提供される。このシステムは、発行局、検証者、並びに属性及び対応する属性値を含む証明書を提供するためのプライベート属性プロバイダ（ＰＡＰ）を備える。ユーザが操作する接続デバイスが更に、ユーザを証明書にバインドし、極めて重要な属性を発行局の同等の属性にバインドするという特徴がある。バインドすることに応答して、発行局から受信した署名されたサーバプルーフを検証者からの検証者チャレンジと集約して検証者ブロブを生成し、検証者ブロブに署名してモバイル署名済みブロブを生成し、証明書をモバイル署名済みブロブとパッケージ化して承認済み証明書を生成し、承認済み証明書を検証者に提示して、検証者が提供するサービスにアクセスする。接続されたデバイスは、ユーザが選択した属性から、属性値ではなくユーザ認証属性名のセットを収集し、ユーザを発行局に対して認証し、公開鍵（ＰｕＫ）及び秘密鍵（ＰｒＫ）を含むユーザの鍵ペアを生成し、公開鍵（ＰｕＫ）を発行局に送信することによってユーザを証明書にバインドする。
【0018】
接続されたデバイスは、発行局にそれに基づいて証明書を承認する許可を要求し、ユーザ認証属性名のセットを検証し、検証された場合に、発行局から署名されたサーバプルーフを受信することによって、極めて重要な属性を発行局の同等の属性にバインドする。発行局は、ユーザ認証属性名のセットのそれ自体の対応する属性値に対する有効性をチェックし、有効である場合に、証明書をユーザ認証属性名のセット及びハッシュ化された証明書及びハッシュ化された公開鍵とともに承認し、署名されたサーバプルーフを返信し、そうではなく、有効でない場合に証明書を承認しない。発行局は、サーバプルーフに署名して、ハッシュ化された証明書、ユーザ認証属性名のハッシュ、発行局チャレンジ、及びハッシュ化された公開鍵を含む署名されたサーバプルーフを生成する。
【0019】
第４の実施形態では、プライベート証明書の否認不能な承認のための接続デバイスが提供される。このデバイスは、電力を供給する電源、命令及びデータを格納するメモリ、データを送受信する通信モジュール、情報を提示し、ユーザ入力を受信するディスプレイ、及びコンピュータプログラムを実行するプロセッサを備える。コンピュータプログラムは、計算環境において少なくとも１つの中央処理装置（ＣＰＵ）により実行されるプログラムコードを格納する非一時的コンピュータ可読媒体を備え、これにより、プログラムコードの実行が、少なくとも１つのＣＰＵに上記の方法の動作を実行させる。１つの構成では、方法は、プライベート属性プロバイダ（ＰＡＰ）から証明書を受信することを含み、証明書は属性及び対応する属性値を含み、更に接続デバイスのユーザを証明書にバインドし、属性の極めて重要な属性を発行局の同等の属性にバインドすることによって特徴付けられる。
【0020】
本明細書に示されるシステムは、電子取引のための電子識別及びトラストサービス（ｅｌＤＡＳ２）規則と互換性があるように設計されている。例えば、ｅｌＤＡＳ適格トラストサービスプロバイダ（ＴＳＰ）によって制定される「Ｇｏｖサーバ」と呼ばれる役割を導入することによって、システムはｅｌＤＡＳ２コンテキストに適用され、規則に従うことがある。この実践を通じて、ユーザはＴＳＰに、任意のプライベート属性プロバイダにより配送されるプライベート証明書を承認する役割を果たすことになるＱＥＡＡ（属性の適格証明書）を提供するように求めることができる。この構成では、ＴＳＰは「署名済みＧｏｖプルーフ」と呼ばれる複合物（例えば、属性、証明書、プルーフなど）に署名する。このようにプライベート証明書は、ＱＥＡＡ（属性の適格／電子証明書）のＥＡＡを検証することによる場合を除き、ＴＳＰによって承認される可能性があり、プライバシーを保護しながらプライベート証明書とパブリック証明書の間の橋渡しを実現する確かな方法を提供する。
【図面の簡単な説明】
【0021】
本発明の特徴は新規であると考えられており、添付の特許請求の範囲に詳細に記載されている。本発明、並びにその更なる目的及び利点は、添付の図面と併せて以下の説明を参照することにより、最もよく理解されることがある。いくつかの図では、同様の参照番号が同様の要素を特定する。
【0022】
【図1】ある実施形態によるプライベート証明書を承認するための使用例図。
【図2】ある実施形態によるプライベート証明書の否認不能な承認のための方法を示す図。
【図5】ある実施形態による承認済み証明書における署名されたサーバプルーフを再利用する方法を示す図。
【図6】ある実施形態によるプライベート証明書の否認不能な事前承認のための方法を示す図。
【図7】ある実施形態による本方法を実行するための使用に適したマシンの例示的な概略図。
【図8】ある実施形態による本方法を実行するための使用に適したハードウェアプラットフォームを示す図。
【発明を実施するための形態】
【0023】
本明細書は、新規であるとみなされる本発明の特徴を定義する請求項で終了するが、本発明は、同様の参照番号を引き継ぐ図面と併せて以下の説明を考慮することにより、よりよく理解されると考えられる。
【0024】
コンピューティングにおいて、属性とは、オブジェクト、要素、又はファイルのプロパティを定義する仕様である。また、特定のインスタンスの特定の値を参照したり、設定したりすることもある。多くのオブジェクト指向言語では、特定の属性をプライベートと宣言することもでき、これにより、あるクラスのユーザがその値を直接見たり変更したりすることが、不可能ではないにしても困難になる。クラスの開発者は、これらの属性を操作又は使用できる方法を制御する方法を提供する。ここで説明するプライベート証明書を承認するためのプロトコルは、ユーザが自分の選択した属性で署名された証明書を承認するために使用される可能性がある。また、プライベート属性プロバイダが証明書に署名を適用する前に、このプロトコルを要求することもできる。
【0025】
プライベート属性プロバイダからの属性を、１）所有者との結びつき、及び２）発行局からの認定された極めて重要な属性との結びつきという２つの強力な性能強化で承認する必要がある。身元証明はコストがかかり、そのような立場に置かれた依拠当事者は、複雑な資格情報を独自にチェックすることからほとんど利益を得られない。また、政府公的機関などの第三者が、証明を支援する信頼できるソースとして含まれる場合、契約上の責任が一般的に課題となる。デジタル資格情報の承認要求に応じて同意を得てデータを配信することは困難である。本明細書の実施形態は、これらの限界を克服するソリューションを提供する。
【0026】
図１を参照すると、第１の実施形態に従って、プライベート証明書を承認するための高レベルの使用例図が示されている。この使用例では、ユーザは最終的にサービスプロバイダ１３０からサービス１５１を取得することを望んでいる。サービスプロバイダは、検証者（１３０）又は依拠当事者とも考えられる。サービス１５１を受けるために、サービスプロバイダはプライベート属性プロバイダ（ＰＡＰ）１１０からのプライベート証明書１１１を必要とし、証明書１１１が実際に信頼できるものであることが保証されなければならない。この保証を提供するために、発行局１２０はユーザの信頼を高める当事者として含まれる。
【0027】
発行局は、本明細書に記載の手段によって、プライベート証明書を承認して、承認されたプライベート証明書を生成する。承認によって、サービスプロバイダは、プライベート証明書１１１が本物で信頼できるものであることを確信する。次に、ユーザは、サービス１５１を受ける条件として、承認されたプライベート証明書をサービスプロバイダ１３０に提示する。サービス１５１へのアクセスが、デバイス鍵を保持するモバイルデバイスのユーザに権利又は特権を与える。
【0028】
使用例図１００は、サービスプロバイダ１３０（又は依拠当事者）に配送する前に、ユーザが自分のプライベート証明書の信頼度を高めるためのソリューションとして、プライベート証明書の否認不能な承認のための一般的な高レベルの方法（ステップ１４１～１４６）を例示している。これは、発行局１２０を承認のための信頼できるソース及び仲介者としてユーザ及びサービスプロバイダに紹介するものである。この使用例では、サービスプロバイダ１３０は、プライベート属性プロバイダにより発行されたデジタル証明書をユーザに要求し、発行局から承認された証明書を介して、受け取ったデジタル文書がユーザのものであり、証明書で取り上げられている主要な（極めて重要な）ユーザＩＤ属性が検証及び妥当性確認されたという保証を受け取る。
【0029】
例えば、ユーザが学術機関（例えば、ＰＡＰ１１０）を卒業した元学生であり、同窓会（例えば、サービスプロバイダ１３０）から特権を求めているとする。ユーザは、ユーザに学位を授与したＰＡＰ１１０から、関連するユーザ識別情報を含むデジタル卒業証書を取得し、学位には、ユーザの名前、卒業日、授与機関、及び学問分野領域が記載されている。この例では、サービスプロバイダ１３０は、ユーザに特権（例えば、サービス１５１）を付与できる同窓会であるが、サービス又は特権、つまりサービスの条件を受け取るためには、ユーザが出席して機関から卒業証書を受け取っていることが必要である。サービスプロバイダ１３０は、同窓会に代わってユーザを認可するために働く第三者検証者である可能性もある。ユーザは卒業証書のコピー、或いは卒業証書の写真（実物、又はモバイルデバイス上）を同窓会に証拠として提示するために有する可能性があるが、卒業証書（コピー又は写真）の真正性を確認するために、同窓会（又は第三者の関連会社）に時間とコストの労力を課すことになる。卒業証書は学位授与機関から直接受け取るのが好ましい。なぜなら、ユーザ単独よりも信頼できるソースであるためである。しかし、この場合も、ＰＡＰ（例えば学術機関）とサービスプロバイダ（例えば同窓会）の両方に、コミュニケーションを取り、信頼の基盤を確立するという負担が課される。
【0030】
この例では、ステップ１４１で、ユーザがユーザを識別するデジタル文書を要求し、ＰＡＰ１１０はステップ１４２においてプライベート証明書１１１でこれに応答する。すなわち、提供されたデジタル文書が実際に真実かつ本物であることの証明である。これは、デジタル文書中の個人情報を証明する。ユーザは、この時点でプライベート証明書を提示することができる。先に考察した使用例１００の別の構成は、プライベート属性プロバイダ（ＰＡＰ）が事前承認を要求するソリューションを提供して証明書の「誤った配送」のリスクを軽減する。
【0031】
しかしながら、前述のように、ユーザ以外の信頼できるソースからの証明書を承認する必要がある。承認（ｅｎｄｏｒｓｅｍｅｎｔ）とは、何かの真正性を証明するためのデジタル証明書に似た承認である。この保証を提供するために、ユーザはステップ１４３において発行局１２０に対して認証を行い、認証時に、発行局１２０が独立に検証するためのプライベート証明書１１１内の極めて重要な属性（例えば名、姓、生年月日、出生地）を選択する。発行局は、ステップ１４４において極めて重要な属性を検証すると、サーバプルーフで応答する、すなわちプライベート証明書はユーザに対応している。ステップ１４５において、サーバプルーフはプライベート証明書と結合されて、承認されたプライベート証明書４００を生成する。ステップ１４６において、ユーザは承認されたプライベート証明書をサービスプロバイダ１３０に提示して、サービス１５１を受ける。
【0032】
図２を参照すると、モバイルデバイスによるプライベート証明書の否認不能な承認のための方法２００が示されている。この方法は、示されているよりも多い又は少ない数のステップを含む可能性があり、示されているステップの順序に限定されるものではない。この方法について考察する際、使用可能コンポーネントを示すために他の図を参照する。この方法は、接続されたデバイス１００を有するユーザが検証者１３０により提供されるサービスを要求する計算エコシステムの文脈で示されている。接続されたデバイスは、携帯電話、ラップトップ、又はその他の電子通信機器である場合がある。
【0033】
方法２００は、ステップ２０１から開始することができ、ステップ２０１では、ユーザは接続されたデバイス１００に、ＰＡＰ１１０からの（プライベート）証明書を要求する。ユーザはＰＡＰから証明書を収集する。この例では、証明書は、１９８０年１０月２３日にユートピアで生まれたジョンスミス氏に認められた卒業を主張する。ＰＡＰは、プライベート属性を証明し得る方法を制御する。例えば、学術機関は、特定の学位が特定の日に特定の学生に授与されたことを証明できるＰＡＰである。ユーザ識別バッジ（ＩＤ）を提供する企業は、特定のバッジが特定の従業員に特定の期間、特定のエリアへの入場又は特定のコンピュータシステムへのアクセスのために与えられたことを証明し得るＰＡＰの別の例である。登録ユーザにサービスへのアクセスを提供する団体は、証明サービスを提供し得るＰＡＰの別の例である。
【0034】
ステップ２０２において、ＰＡＰは証明書で応答し、接続されたデバイス１００は証明書を保存する。証明書は対応する属性値を有する属性を含む。図１の例示的な使用例において、属性名と属性値の例示的なリストを以下に示す。
【0035】
【表1】
【0036】
ステップ２０６において、モバイルデバイスは、ユーザに証明書内の属性名のリストを提示し、プライバシーを保護するために、属性値ではなく属性名のサブセットを選択するようにユーザを促す。これは、ユーザ認証属性名のセットであり、同様に「極めて重要な」属性と考えられる。図３を簡単に参照すると、ユーザにより選択された極めて重要な属性３０２は、すべての属性を含む証明書３００内で特定され、（例えばＡ、Ｂ、Ｃと）マークされる。特に、属性値は、証明書３００内に対応する属性名とともに含められることがあるが、承認された証明書４００が生成される方法は、ユーザにより選択された（ユーザ認証）属性名のみに依存し、属性値を必要としない。このステップでは、ユーザは、その構成属性（属性名と値のペア）を変数ソース（例えばユーザ入力、ｅｌＤＣａｒｄ、クラウドサービス、Ｇｏｖサービス）の同等の属性（属性名と値のペア）にバインドすることによって証明書を承認することができる。ユーザは、証明書の承認に使用することを望む極めて重要な属性（例えば、名、姓、生年月日、出生地）として、属性名（属性値ではない）を選択するように促される。
【0037】
ステップ２０８において、ユーザは接続されたデバイス１００を介して発行局１２０に対して認証を行う。ユーザは自分のモバイルから、発行局１２０、例えば政府サーバ（例えば、ログイン／パス又は追加の認証ベクトル又はｅｌＤＣａｒｄ、又はＯＯＢ事前取得シークレットなど）に対して認証を行う。このステップにおいて、ユーザは自分のモバイルで鍵ペア＜ユーザ公開鍵（ＰｕＫ）及びユーザ秘密鍵（ＰｒＫ）＞を生成し、政府サーバに、極めて重要な属性名のセット｛例えば、ｆｉｒｓｔ＿ｎａｍｅ、ｌａｓｔ＿ｎａｍｅ、ｂｉｒｔｈｄａｔｅ、ｐｌａｃｅ＿ｏｆ＿ｂｉｒｔｈ｝、証明書のハッシュ（プライバシー上の理由から証明書は平文で明らかにされない）及びユーザ公開鍵（ＨＰｕＫ）のハッシュとともに証明書を承認するための承認要求を送信する。ユーザ認証属性名のセット及びハッシュ化された証明書及びハッシュ化された公開鍵とともに証明書を承認するステップは、ユーザをモバイルデバイスの生成された鍵ペアにバインドし、これによってユーザが証明書の承認（及びモバイルデバイス署名）を拒否することを防止する。
【0038】
ステップ２１０において、発行局１２０は、１）ユーザ属性を取得し、２）ユーザ属性をハッシュ化し、３）サーバプルーフとしてトークンに署名し、４）{ハッシュ（ＰＡＰ．証明書）＋ＵＩＤ＋使用属性のハッシュ}を記録する。具体的には、発行局１２０は、極めて重要な属性名を独立に検証し、ユーザの承認から既に有している属性値、又は独自の信頼できるソースの検索を通じて見つけた属性値に対して検証を行う。極めて重要な属性を発行局の同等の属性に対して検証することは確認作業である。これは、サーバプルーフの１つの要素である。発行サーバ１２０は、選択された極めて重要な属性名について独自の独立した属性値を取得すると、証明書を調べて、対応する属性名と値のペアが一貫していること、つまり、証明書内の名前の属性値が独自の調査／検索の観点から正しいことを確認することになる。例えば、政府サーバは、認証されたユーザが属性名／値のペアが、例えば民事登録簿、身分証明書登録簿、行政登録簿内の属性名／値のペアと一致することを確かめるために、証明書内の属性の有効性をチェックする。
【0039】
ステップ２１２において、発行局１２０は、調査の結果のマッチング演習が成功した場合に、署名されたサーバプルーフを返す。例えば、政府サーバが、チェックが成功した場合、署名されたＧｏｖサーバプルーフを返すことになる。このプルーフは、属性のハッシュ、チャレンジ（又は一意の識別子ＵＩＤ）及びハッシュ化された証明書で構成される。ステップ２１４において、モバイルデバイスは、署名されたサーバプルーフを後で使用するために保存する。この時点で、ユーザは、検証者のユーザ識別要求を満たすために必要となるサーバプルーフを有する。発行局１２０との通信を終了することができる。ユーザは、これより検証者１３０との通信に進む。
【0040】
ステップ２１６において、ユーザは検証者（又はソースプロバイダ又は依拠当事者）が提供するサービスへのアクセスを要求する。続く例では、サービスは特定の学術機関に通っていた生徒の卒業生特権である可能性がある。ユーザはモバイルデバイスで検証者サービスにログインし、サービスを要求する。検証者１３０は、ステップ２１８において、ユーザのモバイルデバイスに提供される検証者チャレンジで応答する。この時点で、ユーザは、ステップ２２０が示すように、モバイルデバイスに承認された証明書を生成するように指示することになる。接続されたデバイス１００は、ユーザの指示の下に検証者／ＳＰ／ＲＰからの検証者チャレンジを用いてＧｏｖサーバプルーフを集約し、パッケージ全体に署名し（ユーザのデバイス鍵－ユーザ秘密鍵ＰｒＫを使用）、結果として承認された証明書を生成する。例示的な承認された証明書４００の詳細な説明は、図３に示され提供されている。
【0041】
モバイルデバイスが承認された証明書４００を生成すると、ユーザはステップ２２２においてそれを検証者１３０に送信する。つまり、ユーザは、サービスにアクセスしたり、例えば卒業生ウェブページアクセス権などの権利を付与されたりするために、承認された証明書を検証者／ＳＰ／ＲＰに配送する。検証者１３０は、承認された証明書４００のペイロード（図３参照）をチェックして、ユーザが供給した証明書がサーバプルーフと一致するかどうかを判定する。これにより、検証者は証明書から必要な属性名／値を抽出し、ユーザに対するサービスを決定して提供することになる。検証者は、鍵の使用と証明書を確認するのに必要な通常のＰＫＩアクションを実行することになる。
【0042】
図３を参照すると、承認済み証明書４００の概略図が示されている。承認済み証明書４００は、証明書３００とモバイル署名済みブロブ３２０とから構成される。属性３０３の特定の選択が、極めて重要な属性３０２（例えば、Ａ、Ｂ、Ｃ、ユーザ認証属性名とも呼ばれる）と考えられる。これらは、ユーザが証明書内から特定の属性名（値ではない）を選択し、発行局が独立に検証するという意味において「極めて重要」である。承認済み証明書４００は、任意選択のＰＡＰ署名３０４を備えた証明書３００と、モバイル署名済みブロブ３２０とから構成される。ＰＡＰ署名は任意選択であり、承認された証明書の必須要素ではないことに留意されたい。むしろ、証明書の承認とは、ＰＡＰ署名が存在するかどうかに関係なく、証明書３００とモバイル署名済みブロブ３２０の組み合わせた提示（組み合わせ）を指す。
【0043】
証明書３００は、各属性の使用目的、例えば使用条件、有効期限、又は承認済み証明書４００を使用するためのその他の条件付き手段を含む。目的は、ＰＡＰ１１０又はユーザによって提供されることがある。証明書３００は、ＰＡＰによって署名されたことを確認する署名３０４を含む。ただし、発行局が証明書３００を承認するための前提条件と見なされる場合は、ＰＡＰ署名３０４が証明書４００に添付されることは任意選択である。
【0044】
モバイル署名済みブロブ３２０は、検証者ブロブ３４０及びモバイル署名３２２（鍵として示される）を備える。モバイル署名３２２は、接続されたデバイス１００（図２及び図３Ｂ参照）が保存されているユーザ秘密鍵（ＰｒＫ）を使用して検証者ブロブ３４０に署名するときに、接続されたデバイス１００によって作成される。検証者ブロブ３４０は、署名されたサーバプルーフ３６０及び検証者チャレンジ３４２を備える。署名されたサーバプルーフ３６０は、発行局１２０により提供されたサーバプルーフを、発行局１２０によって署名されたことを確認するための発行局署名３６２（鍵として示される）と共に備える。サーバプルーフ３６０は、証明書３００のハッシュ（ハッシュ化された証明書３７０）、ユーザ認証属性名のハッシュ（ハッシュ化されたユーザ認証属性３７１）、発行局チャレンジ３７２、及びユーザ公開鍵（ＰｕＫ）のハッシュ（ハッシュ化されたユーザ公開鍵３７３）を備える。ユーザ秘密鍵（ＰｒＫ）とユーザ公開鍵（ＰｕＫ）は、ユーザが接続デバイス１００上で作成し、そこに保存されている対応する鍵ペアである。鍵ペアは、公開鍵インフラストラクチャ（ＰＫＩ）のガイドラインと推奨事項に従って生成される。したがって、署名されたサーバプルーフ３６０は、サーバプルーフ（要素３７０～３７３）及び発行局署名３６２を備える。
【0045】
簡単に言えば、図４Ａ及び図４Ｂはそれぞれ、図２の承認済み証明書４００（図３参照）を作成するための方法２００によって提供され、その結果生じる証明書の承認に関与するさまざまなエンティティのバインディングパス及びバインディングポイントを示している。バインディングポイントは、ユーザ又は関与するエンティティ（発行局又は検証者）が、承認済み証明書４００（図３）の組み立てられた／パッケージ化されたコンポーネントの有効性を否定できない対応する否認防止バインディングパスの作成の結果である。バインディングポイント及びパスはまた、コンポーネントをどのように再利用し得るか確立する。例えば承認されると、ユーザは、さまざまな検証者にサービスを求めるときに、署名されたサーバプルーフを再利用することができる。ただし、ユーザは、同じ証明書でしか署名されたサーバプルーフを再利用することができない。
【0046】
ここで図４Ａを参照すると、証明書を承認することに関わるさまざまなエンティティのバインディングパスが示されている。バインディングパス４０１は、ＰＡＰ１１０が証明書を作成してこれに署名し、それによってＰＡＰ署名３６２（図３Ａ）を生成するときに、ＰＡＰ１１０と証明書３００の間で生じる。バインディングパス４０２は、ＰＡＰ１０１が極めて重要な属性３０２を使用する１つ以上の目的を含み、証明書に署名するときに発生する。バインディングパス４０３は、ハッシュ化された証明書３７０を含んでいる発行局１２０が、その発行局署名３６２でサーバプルーフに署名するときに発生する。バインディングパス４０４は、ハッシュ化されたユーザ認証属性名３７１を含む発行局１２０が、その発行局署名３６２でサーバプルーフに署名するときに発生する。これにより、ユーザが選択した極めて重要な属性（ユーザ認証属性名３０２、例えば、Ａ、Ｂ及びＣ）が、発行局により検証された同等の属性にバインドされる。バインディングパス４０５は、発行局１２０が、署名されたサーバプルーフ３６０を生成する際に、その発行局署名３６２でサーバプルーフに署名するときに発生する。バインディングパス４０６は、発行局１２０が、署名されたサーバプルーフ３６０内に発行局チャレンジ３７２を含むために発生する。
【0047】
バインディング４０７～４０８は、接続されたデバイス１００のユーザを証明書３００にバインドすることによって、ユーザが要求した証明書を承認するために発行局が使用した極めて重要な属性を選択したことを否定したり、検証者１３０にサービスを要求するために検証者ブロブ３４０を作成しなかったことを否定したりすることをユーザができない否認防止パスを作成する。バインディングパス４０７は、ユーザのモバイルデバイスが、ユーザの秘密鍵（ＰｒＫ）で検証者ブロブ３４０に署名して、モバイル署名済みブロブ３２０を生成するときに発生する。バインディングパス４０８は、ユーザが発行局にユーザの公開鍵（ＰｕＫ）を提供し、認証と証明書３００に対する承認を要求するときに発生する。バインディング３８８は、ハッシュ化されたユーザ公開鍵（ＰｕＫ）３７３が署名されたサーバプルーフ３６０に埋め込まれているため否認不能である。バインディングパス４０９は、モバイルデバイスが検証者（又はソースプロバイダ、又は依拠当事者）により提供されたチャレンジに固有の承認済み証明書４００を構築するときに、ユーザを検証者１３０にバインドする。
【0048】
ここで図４Ｂを参照すると、承認済み証明書４００の作成に関わるさまざまなエンティティのバインディングポイントが示されている。図４Ｂに以前に示されたコンポーネントも数値で参照されることになる。バインディングポイント４２０は、極めて重要な属性（ユーザ認証属性名３０２、図３）のみが発行局によって承認され得ることを確立する。バインディングポイント４２１は、証明書３００をモバイルデバイスに接続し、ユーザのコミットメントを確立する。この時点で、発行局はユーザの要求に応じて証明書を承認し、証明書にはユーザが選択した極めて重要な属性３０２が含まれているため、これはユーザのコミットメントである。バインディングポイント４２２は、ユーザが証明書を進んで承認したことを否定できないことを立証する。バインディングポイント４２３は、ユーザが承認に関係する極めて重要な属性の選択を否定できないことを立証する。
【0049】
バインディングポイント４２４は、同じ証明書に対してのみサーバプルーフを再生することをユーザに義務付ける。ポイント４２５は、ユーザを発行サーバからの許可にバインドする。このバインディングは、証明書の目的フィールドと同様に、発行局により確立されたプロパティ又は使用条件、すなわちサーバプルーフの使用期限やその他の条件を含む可能性がある。バインディングポイント４２６は、ユーザを、ユーザがモバイルデバイスで作成して保存したユーザ秘密鍵（ＰｒＫ）にバインドする。したがって、ユーザは、署名されたサーバプルーフが対応するユーザ公開鍵（ＰｕＫ）のコピーを含んでいるため署名を拒否することができない。
【0050】
バインディングポイント４２７は、選択された検証者の一意性を確立し、承認済み証明書をその特定の検証者にバインドする。検証者チャレンジ３４２を検証者ブロブ３４０に含めることは、ユーザ及び接続されたデバイス１００の制御下にあるため、ユーザは、他の検証者に固有の他の承認済み証明書を作成することができる。つまり、検証者チャレンジ３４２を検証者ブロブ３４０に埋め込み、モバイルデバイスのユーザ秘密鍵（ＰｒＫ）でパッケージに署名することによって、検証者に固有のモバイル署名済みブロブ３２０を生成する。モバイル署名済みブロブに検証者チャレンジ３４２を含めるこの構成能力は、「一度承認して何度も使用する」アプローチを可能にするものである。ユーザは署名されたサーバプルーフを再利用できるが、同じ証明書を使用することによってのみ実行できるものもある。
【0051】
図５を参照すると、別のサービス又は特権への加入申込のために異なる検証者で署名されたサーバプルーフを再利用する方法５００が示されている。この方法では、ユーザは、例えば図２の方法ステップ２０１～２１４に従って、署名されたサーバプルーフを既に受け取っている。その図に見られるように、ステップ２１４において、署名されたサーバプルーフは、例えば、ユーザが別の検証者からのサービスを希望するこの例のように、後の使用のために保存される。
【0052】
方法５００では、ステップ５０２において、ユーザが検証者１３０にサービスを要求する。ステップ５０４において、検証者１３０は検証者チャレンジで返す。ステップ５０６において、ユーザは接続されたデバイス１００を介して、図２に示すステップ及び説明と同様に、承認された証明書４００を生成する。ただし、ここでモバイルデバイスは新しい（異なる）検証者チャレンジを検証者ブロブ３４０に埋め込み、接続されたデバイス１００に保存されているユーザ秘密鍵（ＰｒＫ）１０２でこのブロブに署名する。方法５００の手順は方法２００の手順と同様であるが、異なる検証者チャレンジを含む。
【0053】
ステップ５０８において、ユーザは承認された証明書を検証者１３０に提示する。検証者は、ステップ５１０においてパッケージをその内容と正確性についてチェックし（ユーザ署名及び属性をチェックし）、ＯＫの場合にサービスへのアクセスを許可するステップ５１２において、すなわち、提供された証明書がサーバプルーフと一致することを確認した後に、提供すべきサービスを決定する。これによりユーザは、政府サーバからの同じサーバプルーフを複数の異なる検証者（サービスプロバイダ又は依拠当事者）で再利用することができる。特に、検証者／ＲＰのチャレンジのみがユーザを検証者／ＲＰにバインドする。したがって、政府サーバプルーフは、使用条件で許可されている限り、複数の検証者／ＲＰで再利用することができる。
【0054】
図６を参照すると、モバイルデバイスを介してプライベート証明書の否認不能な事前承認のための方法６００が提供される。方法６００は、示されているよりも多い又は少ない数のステップを含む可能性があり、示されているステップの順序に限定されない。この方法について考察する際、使用可能コンポーネントを示すために他の図を参照することになる。この方法は、接続されたデバイス１００を有するユーザがＰＡＰ１１０により提供される証明書を要求する計算エコシステムの文脈で示されている。ここで、ユーザは、ＰＡＰ１１０に提供される情報の通信に関連して、デジタル証明書を受信するために、図２の方法ステップ２０１～２０４を補足している。この使用例は、ＰＡＰがユーザの証明書要求の正当性に確信が持てず、証明書をユーザにリリースする前に、発行局による事前承認の形で保証を得たい場合に発生する。つまり、ユーザはまず署名されたサーバプルーフを探し求め、それを証明書を受け取る条件としてＰＡＰ１１０に返送する必要がある。これは、ＰＡＰ１１０がユーザ（要求者）を認証する簡単な手段を有さず、証明書を詐欺師に引き渡すことを避けたいために必要である。したがって、ＰＡＰ１１０は証明書を発行する条件として発行局への依存を要求する。
【0055】
ステップ６０２において、ユーザはＰＡＰ１１０に証明書（例えば卒業証書）の要求を送信する。ユーザはプライベート属性プロバイダ（ＰＡＰ）から、属性、対応する属性値、及びＰＡＰチャレンジ６０４を含む証明書を受信する。ただし、ステップ６０６において、ＰＡＰ１１０は、証明書に署名３８８を追加する前に事前承認を要求する。特に、ステップ６０６においてＰＡＰ１１０が返した無署名の証明書２９９は署名を含まない。むしろ、事前承認のシグナリングとしてＰＡＰチャレンジ６０４が含まれている。したがって、ユーザは、ＰＡＰ署名がこのステップ６０６において存在しないため、方法２００で行われたように証明書２９９を使用し続けることができない。この時点では「無署名の」証明書であることに留意されたい。
【0056】
方法２００で行われたのと同様に、方法６００は、ここでモバイルデバイスのユーザを証明書にバインドすることを含む。したがって、同様に、ユーザはまず、無署名の証明書２９９で識別された属性から、属性値ではなく、ユーザ認証属性名（極めて重要な属性）のセットを選択しなければならない。ユーザは発行局１２０（図２参照）に対して認証を行い、公開鍵（ＰｕＫ）と秘密鍵（ＰｒＫ）を含むユーザの鍵ペアを生成し、公開鍵（ＰｕＫ）を発行局に送信する。発行局は、次いで極めて重要な属性を発行局の同等の属性にバインドする。ユーザは、モバイルデバイスを介して発行局に、それに基づいて無署名の証明書２９９（依然としてＰＡＰ署名がない）を承認する許可を要求し、ユーザ認証属性名（極めて重要な属性）のセットを検証し、検証された場合に、発行局から署名されたサーバプルーフを受信する。これは、ステップ６０８（事前承認の実行）の一部であり、モバイルデバイスが署名されたサーバプルーフをＰＡＰチャレンジと集約して事前承認されたブロブを生成すること、事前承認されたブロブに秘密鍵（ＰｒＫ）１０２で署名してモバイル署名済み事前承認ブロブを生成すること、及びモバイル署名済み事前承認ブロブをステップ６１０において認証のためにＰＡＰに提示することを含む。ハッシュ（証明書）は、ここでは「無署名の」証明書のものであることに留意されたい。
【0057】
ステップ６１２において、ＰＡＰは、モバイル署名済み事前承認ブロブ（承認された証明書４００に類似しているが、検証者チャレンジ３４２の代わりにＰＡＰチャレンジ６０４を含む）の署名及びハッシュ化された属性をチェックすることによって、事前承認されたデータパッケージを認証する。認証された場合に、ＰＡＰはステップ６１４において、ＰＡＰ署名３８８を含み、接続されたデバイス１００によって受信されるＰＡＰ署名済み証明書を送信する。ここで証明書が「署名済み」であることに留意されたい。この際、証明書３００は、図２の方法２００における証明書と同じ形式であり、ＰＡＰは、いまやＰＡＰ署名３８８が含まれるために任意選択で証明書に署名する。ステップ６１６において、モバイルデバイスは、図５の方法５００により説明／図示されるように、選択した検証者チャレンジを使用して承認済み証明書を再構築する。すなわちサーバプルーフの再利用。承認済み証明書の再構築は、署名されたサーバプルーフを検証者チャレンジと集約して検証者ブロブ６２０を生成すること、秘密鍵（ＰｒＫ）で検証者ブロブに署名してモバイル署名済みブロブ６３０を生成すること、ＰＡＰ署名済み証明書をモバイル署名済みブロブとパッケージ化して承認済み証明書を生成すること、及び、検証者が提供するサービスにアクセスするために、承認済み証明書を検証者に提示することを含む。
【0058】
本明細書の実施形態により得られる利点には、以下が含まれるが、これらに限定されない。
ユーザについて：
・使いやすい証明書とＲＰに向けて簡素化されたステップ（ＩＤ証明プロセスなし）
・参照属性を有するプライベート証明書の価値を高めるプライバシー対応の承認（図１及び図２参照）
・さまざまなソース（ｅｌＤＣａｒｄ、クラウド、直接入力など）からの参照属性を使用する可能性
・複数の検証者／ＲＰで同じＧｏｖサーバプルーフを再利用する可能性（図５参照）
検証者／ＳＰ／ＲＰについて：
・コストのかかるＩＤ証明が不要（ＲＰに対するＩＤ検証のコストを節約する）
・証明書の強力な否認防止性、信頼性レベルの向上（図４Ａ／Ｂ参照）
プライベート属性プロバイダについて：
・なりすましや、証明書を権限のない人に転送するリスクがない
・実際の追加コストなしに「誤配送」のリスクを軽減する任意選択の事前承認
・証明書に署名する前に事前承認を要求することによって、本発明から利益を受けることができる（図６参照）
発行局（政府サーバ）について：
・政府はプライベート証明書コンテンツ（ＧＤＰＲ準拠）にアクセスできず、いずれにしてもそれを検証する適切な立場にない
・政府は属性値を一切公開しない（ユーザ認証後、政府は選択された属性のハッシュの署名と、それをユーザと文書ハッシュにバインドする方法を提供するに過ぎない）
・政府からのプルーフは、任意選択で使用条件と有効期間をもたらす可能性がある（図４Ｂ参照）
ユーザについて：
・使いやすい証明書とＲＰに向けて簡素化されたステップ（ＩＤ証明プロセスなし）
・参照属性を有するプライベート証明書の価値を高めるプライバシー対応の承認（図１及び図２参照）
・さまざまなソース（ｅｌＤＣａｒｄ、クラウド、直接入力など）からの参照属性を使用する可能性
・複数の検証者／ＲＰで同じＧｏｖサーバプルーフを再利用する可能性（図５参照）
検証者／ＳＰ／ＲＰについて：
・コストのかかるＩＤ証明が不要（ＲＰに対するＩＤ検証のコストを節約する）
・証明書の強力な否認防止性、信頼性レベルの向上（図４Ａ／Ｂ参照）
プライベート属性プロバイダについて：
・なりすましや、証明書を権限のない人に転送するリスクがない
・実際の追加コストなしに「誤配送」のリスクを軽減する任意選択の事前承認
・証明書に署名する前に事前承認を要求することによって、本発明から利益を受けることができる（図６参照）
発行局（政府サーバ）について：
・政府はプライベート証明書コンテンツ（ＧＤＰＲ準拠）にアクセスできず、いずれにしてもそれを検証する適切な立場にない
・政府は属性値を一切公開しない（ユーザ認証後、政府は選択された属性のハッシュの署名と、それをユーザと文書ハッシュにバインドする方法を提供するに過ぎない）
・政府からのプルーフは、任意選択で使用条件と有効期間をもたらす可能性がある（図４Ｂ参照）
【0059】
システム
一実施形態では、プライベート証明書の否認不能な承認のためのシステムが提供される。このシステムは、発行局、検証者、プライベート属性プロバイダ（ＰＡＰ）、及びモバイルデバイスを備える。ＰＡＰは、属性及び対応する属性値を含む証明書を提供する。ユーザが操作するモバイルデバイスは、ユーザを証明書にバインドし、極めて重要な属性を発行局の同等の属性にバインドする。このバインドすることに応答して、モバイルデバイスは、発行局から受信した署名されたサーバプルーフと検証者からの検証者チャレンジを集約して検証者ブロブを生成し、検証者ブロブに署名してモバイル署名済みブロブを生成し、証明書をモバイル署名済みブロブとパッケージ化して承認済み証明書を生成し、承認済み証明書を検証者に提示して、検証者が提供するサービスにアクセスする。
一実施形態では、プライベート証明書の否認不能な承認のためのシステムが提供される。このシステムは、発行局、検証者、プライベート属性プロバイダ（ＰＡＰ）、及びモバイルデバイスを備える。ＰＡＰは、属性及び対応する属性値を含む証明書を提供する。ユーザが操作するモバイルデバイスは、ユーザを証明書にバインドし、極めて重要な属性を発行局の同等の属性にバインドする。このバインドすることに応答して、モバイルデバイスは、発行局から受信した署名されたサーバプルーフと検証者からの検証者チャレンジを集約して検証者ブロブを生成し、検証者ブロブに署名してモバイル署名済みブロブを生成し、証明書をモバイル署名済みブロブとパッケージ化して承認済み証明書を生成し、承認済み証明書を検証者に提示して、検証者が提供するサービスにアクセスする。
【0060】
モバイルデバイスは、ユーザが選択した属性から属性値ではなくユーザ認証属性名のセットを収集することによって、ユーザを証明書にバインドする。モバイルデバイスは、発行局に対してユーザを認証し、公開鍵（ＰｕＫ）と秘密鍵（ＰｒＫ）を含むユーザの鍵ペアを生成し、公開鍵（ＰｕＫ）を発行局に送信する。モバイルデバイスは、発行局に、それに基づいて証明書を承認する許可を要求し、ユーザ認証属性名のセットを検証することによって、極めて重要な属性を発行局の同等の属性にバインドする。検証された場合に、モバイルデバイスは、発行局から署名されたサーバプルーフを受信する。
【0061】
発行局は、ユーザ認証属性名セットの自身の対応する属性値に対する有効性をチェックし、有効である場合に、ユーザ認証属性名セット及びハッシュ化された証明書及びハッシュ化された公開鍵とともに証明書を承認する。発行局は、署名されたサーバプルーフを返す。或いは、有効でない場合に証明書を承認しない。発行局は、サーバプルーフに署名して署名されたサーバプルーフを生成する。署名されたサーバプルーフは、ハッシュ化された証明書、ユーザ認証属性名のハッシュ、発行局チャレンジ、及びハッシュ化された公開鍵を含む。
【0062】
図７は、コンピュータシステム７００の形態のマシン７００の例示的な概略図を示しており、その中の一連の命令が実行されるとき、マシンに上で考察した（例えば、ＰＡＰ１１０、発行局１２０、又はサービスプロバイダ１３０による）手法のいずれか１つ以上を実行させることがある。一部の実施形態では、マシンは、コンピュータ、ラップトップ、モバイルデバイス、リモートコントロール、又はディスプレイなどのスタンドアロンデバイスとして動作する。一部の実施形態では、マシンは他のマシンに（例えば、ネットワークを使用して）接続されることがある。ネットワーク化された展開では、マシンは、サーバクライアントユーザネットワーク環境のサーバ又はクライアントユーザマシンとしての立場で、又はピアツーピア（又は分散）ネットワーク環境のピアマシンとして動作することがある。
【0063】
マシンは、サーバコンピュータ、クライアントユーザコンピュータ、パーソナルコンピュータ（ＰＣ）、タブレットＰＣ、ラップトップコンピュータ、デスクトップコンピュータ、モバイルデバイス、携帯電話、制御システム、ネットワークルータ、スイッチ若しくはブリッジ、又はそのマシンがとるアクションを指定する一連の命令（逐次的又はそれ以外）を実行できる任意のマシンを含むことがある。本開示のデバイスが、音声、ビデオ又はデータ通信を提供するあらゆる電子デバイスを広く含むことが理解されるであろう。更に、単一のマシンが図示されているが、「マシン」という用語は、本明細書で考察される手法のいずれか１つ以上を実行するための命令セット（又は複数のセット）を個別に又は共同で実行するマシンの集合も含むと考えられるべきである。
【0064】
コンピュータシステム７００は、プロセッサ７０２（例えば、中央処理装置（ＣＰＵ）、グラフィックス処理装置（ＧＰＵ、又はその両方）、メインメモリ７０４及び静的メモリ７０６を備えることがあり、これらはバス７０８を介して互いに通信する。コンピュータシステム７００は更に、ビデオ表示装置７１０（例えば、液晶ディスプレイ又はＬＣＤ）、フラットパネル、ソリッドステートディスプレイ、又はブラウン管（ＣＲＴ）を備えることがある。コンピュータシステム７００は、入力デバイス７１２（例えば、キーボード、タッチレスセンシングユニット１１０）、カーソル制御デバイス７１４（例えば、マウス、タッチレスセンシングユニット１１０）、ディスクドライブユニット７１６、信号生成デバイス７１８（例えば、スピーカー又はリモコン）及びネットワークインターフェイスデバイス７２０を備えることがある。
【0065】
ディスクドライブユニット７１６は、マシン可読媒体７２２を含み、この媒体には、上で説明した方法を含む、本明細書で説明した手法又は機能のいずれか１つ以上を具体化する１つ以上の命令セット（例えば、ソフトウェア７２４）が格納されている。命令７２４は、コンピュータシステム７００によって実行されている間、メインメモリ７０４、静的メモリ７０６、及び／又はプロセッサ７０２内に完全に又は少なくとも部分的に常駐することもある。メインメモリ７０４及びプロセッサ７０２もマシン可読媒体を構成することがある。
【0066】
本明細書で説明する方法を実装するために、特定用途向け集積回路、プログラマブルロジックアレイ及びその他のハードウェアデバイスを含むがこれらに限定されない専用のハードウェア実装も構築することができる。さまざまな実施形態の装置及びシステムを含み得るアプリケーションには、さまざまな電子システム及びコンピュータシステムが広く含まれる。一部の実施形態は、関連する制御及びデータ信号がモジュール間で通信されるか、モジュールを介して通信されるか、又は特定用途向け集積回路の一部として、２つ以上の特定の相互接続されたハードウェアモジュール又はデバイスに機能を実装する。したがって、この例示的なシステムは、ソフトウェア、ファームウェア、及びハードウェア実装に適用可能である。
【0067】
本開示のさまざまな実施形態によれば、本明細書に記載の方法は、コンピュータプロセッサ上で実行されるソフトウェアプログラムとして動作することを意図している。更に、ソフトウェア実装には、分散処理又はコンポーネント／オブジェクト分散処理、並列処理が含まれるが、これらに限定されない。又は、本明細書に記載の方法を実行するために、仮想マシン処理も構築することができる。
【0068】
マシン可読媒体７２２は、例示的な実施形態では単一の媒体として示されているが、「マシン可読媒体」という用語は、１つ以上の命令セットを格納する単一の媒体又は複数の媒体（例えば、集中型又は分散型データベース、及び／又は関連するキャッシュ及びサーバ）を含むものと解釈されるべきである。また、「マシン可読媒体」という用語は、マシンによって実行される命令セットを格納、エンコード又は搬送することができ、マシンに本開示の手法のいずれか１つ以上を実行させるあらゆる媒体を含むものと解釈されるべきである。
【0069】
したがって、「マシン可読媒体」という用語は、１つ以上の読み取り専用（不揮発性）メモリ、ランダムアクセスメモリ、若しくはその他の再書き込み可能（揮発性）メモリを収容するメモリカード若しくはその他のパッケージなどのソリッドステートメモリ、ディスク若しくはテープなどの磁気光若しくは光媒体、及び伝送媒体にコンピュータ命令を具体化する信号などの搬送波信号を含むが、これらに限定されないものとみなされるものとする、並びに／又は電子メール又はその他の自己完結型情報アーカイブ若しくはアーカイブセットへのデジタルファイル添付が、有形記憶媒体と同等の配布媒体とみなされる。したがって、開示は、本明細書に列挙され、本明細書のソフトウェア実装が保存される、技術的に認識されている同等物及び後継媒体を含む、マシン可読媒体又は配布媒体のいずれか１つ以上を含むものとみなされる。
【0070】
本明細書に記載の実施形態の図は、さまざまな実施形態の構造の一般的な理解を提供することを意図しており、本明細書に記載の構造を利用し得る装置及びシステムのすべての要素及び特徴の完全な説明として機能することを意図したものではない。上記の説明を検討すると、当業者には他の多くの実施形態が明らかになるであろう。他の実施形態を利用し、そこから派生させて、本開示の範囲から逸脱することなく、構造的及び論理的な置換及び変更が行われることがある。図はまた、単に代表的なものであり、縮尺通りに描かれていないことがある。それらの特定の比率は誇張されることがある一方、他の比率は最小化されることがある。したがって、本明細書及び図面は、限定的な意味ではなく、例示的な意味としてみなされるべきである。
【0071】
発明の主題のこのような実施形態は、本明細書では、便宜上、個々に及び／又は集合的に「発明」という用語で言及されることがあるが、これは、複数の発明又は発明概念が実際に開示されている場合に、本出願の範囲を任意の単一の発明又は発明概念に自発的に限定する意図はない。したがって、本明細書では特定の実施形態が図示及び説明されているが、同じ目的を達成するように計算された任意の構成が、示された特定の実施形態の代わりに使用され得ることを理解されたい。本開示は、さまざまな実施形態のあらゆる適応又は変形を網羅することを意図している。上記実施形態の組み合わせ、及び本明細書で具体的に説明されていない他の実施形態は、上記の説明を検討すれば当業者には明らかであろう。
【0072】
モバイルデバイス（１１０）
一実施形態では、プライベート証明書の否認不能な承認のためのモバイルデバイスが提供される。デバイスは、電力を供給する電源、命令及びデータを格納するメモリ、データを送受信する通信モジュール、情報を提示し、ユーザ入力を受信するディスプレイ、及びコンピュータプログラムを実行するプロセッサを備える可能性がある。コンピュータプログラムは、計算環境において少なくとも１つの中央処理装置（ＣＰＵ）により実行されるプログラムコードを格納する非一時的コンピュータ可読媒体を含み、プログラムコードの実行が、少なくとも１つのＣＰＵに、プライベート属性プロバイダ（ＰＡＰ）から属性及び対応する属性値を含む証明書を受信すること、モバイルデバイスのユーザを証明書にバインドすること、及び属性の極めて重要な属性を発行局の同等の属性にバインドすることを含む動作を実行させる。
一実施形態では、プライベート証明書の否認不能な承認のためのモバイルデバイスが提供される。デバイスは、電力を供給する電源、命令及びデータを格納するメモリ、データを送受信する通信モジュール、情報を提示し、ユーザ入力を受信するディスプレイ、及びコンピュータプログラムを実行するプロセッサを備える可能性がある。コンピュータプログラムは、計算環境において少なくとも１つの中央処理装置（ＣＰＵ）により実行されるプログラムコードを格納する非一時的コンピュータ可読媒体を含み、プログラムコードの実行が、少なくとも１つのＣＰＵに、プライベート属性プロバイダ（ＰＡＰ）から属性及び対応する属性値を含む証明書を受信すること、モバイルデバイスのユーザを証明書にバインドすること、及び属性の極めて重要な属性を発行局の同等の属性にバインドすることを含む動作を実行させる。
【0073】
ユーザをバインドすることは、ディスプレイを介してユーザが選択した属性から、属性値ではなく、ユーザ認証属性名のセットを収集すること、発行局に対してユーザを認証すること、公開鍵（ＰｕＫ）と秘密鍵（ＰｒＫ）を含むユーザの鍵ペアを生成しメモリに格納すること、通信モジュールを介して発行局に公開鍵（ＰｕＫ）を送信すること、それに基づいて証明書を承認する許可を発行局に要求すること、及びユーザ認証属性名のセットを検証することを含む。検証された場合に、それは、発行局から署名されたサーバプルーフを受信すること、署名されたサーバプルーフと検証者チャレンジを集約して検証者ブロブを生成すること、秘密鍵（ＰｒＫ）で検証者ブロブに署名してモバイル署名ブロブを生成すること、証明書をモバイル署名ブロブとパッケージ化して承認済み証明書を生成すること、及び承認済み証明書を検証者に提示して、検証者が提供するサービスにアクセスすることを含む。
【0074】
図８は、接続デバイス１００の前述の方法ステップを実行するための計算処理環境として、又はその内部で使用するのに適したハードウェアプラットフォーム８００を示している。プラットフォーム８００は、プロセッサ８１０、メモリ８２０、及びセキュリティ８３０、センサ２４０、有線インターフェイス８５０及び／又は無線インターフェイスとして示される通信モジュール、電源８７０、バッテリ８７５、及びユーザインターフェイス（ＵＩ）８８０を備える。これらのコンポーネントは、図に示すように、又は適切な場合に、電子機器、回路、配線、ライン、ロジック、又はゲートを含むがこれらに限定されない、それらの間の直接的なハードウェアインターフェイスによって通信可能に結合されることがある。
【0075】
プロセッサ８１０は、汎用プロセッサ及び／又は専用プロセッサ、例えばマイクロプロセッサ及び／又はデジタル信号プロセッサ（例えば、ＧＰＵ、□Ｐ、ＡＳＩＣ、ＤＳＰ、ＣＰＬＤ、ＩＣなど）などの１つ以上のデータ処理回路を含むことがある。プロセッサ８１０は、非一時的コンピュータ可読媒体として以下に説明するメモリ８２０内のコンピュータプログラムコードを実行し、特定のコンポーネント、モジュール又はソフトウェアブロックによって実行されると本明細書で説明する動作の少なくとも一部を実行するように構成される。コンピュータプログラムコードは、プロセッサ８１０によって実行されるときに、プロセッサ８１０に本明細書で開示される１つ以上の実施形態に従って動作を実行させるコンピュータ命令、アセンブリコード、ファームウェア、又は埋め込みコード、マシンコードを含む可能性がある。
【0076】
メモリ８２０により例示されるコンピュータ可読記憶媒体の具体的な例（非網羅的リスト）は、ハードディスク、ランダムアクセスメモリ（ＲＡＭ）、読み取り専用メモリ（ＲＯＭ）、消去可能プログラマブル読み取り専用メモリ（ＥＰＲＯＭ）、フラッシュメモリ（ＮＡＮＤ、ＮＯＲ）、ソリッドステートデバイス（ＳＳＤ）、リピータを備えた適切な光ファイバ（ＦＩＣＯＮ）、光記憶デバイス、磁気記憶デバイス、又は前述の任意の適切な組み合わせを含む可能性がある。
【0077】
プロセッサ８１０はまた、計算タスク又は処理タスクのオフロードを支援するコプロセッサ８１１（オンボード又はオフボード）、１つ以上のＣＰＵコア８１２及び１つ以上の暗号プロセッサ８１３（例えば、ＨＷ暗号アクセラレータ）に通信可能に取り付けられることがある。
【0078】
センサ８４０は、物理的特性を検出又は測定し、その知覚情報を記録し、示し、或いはこれに応答することができる。センサ８４０は、温度、湿度、無線周波数、電磁気、光、力、圧力、加速度、動き、位置、傾き、及びその他の物理的相互作用及び環境条件の測定を行う。センサ８４０は更に、信号コンパレータ、位相コンパレータ、アナログ－デジタルコンバータ、増幅器、信号フィルタなど、プロセッサ８１０が１つ以上のセンサから信号を受信し処理できるようにするものを含むことがある。
【0079】
セキュリティモジュール８３０は、プラットフォーム８００に対するセキュリティ違反、セキュリティリスク、不正使用及び攻撃の監視を行う。セキュリティモジュール８３０は、決定ロジック、メモリ又はソフトウェアを備え、センサ８４０及びプロセッサ８１０と通信可能に結合する混合信号低電力マイクロコントローラである場合がある。セキュリティモジュール８３０は、改ざんレベル、閾値、及び条件などのセキュリティイベントを検出するために、ソフトウェア及びロジックを含むか、又はプロセッサ８１０とリソース及び責任を共有することがある。
【0080】
プラットフォーム８００は、有線ネットワーク通信インターフェイス８５０及び／又は無線インターフェイス８６０、例えば無線アクセス通信トランシーバを備えることがある。有線ネットワークインターフェイスは、ローカルエリアネットワーク（ＬＡＮ）、ワイドエリアネットワーク（ＷＡＮ）、クラウド経由、インターネット、及びその他のフレームベース又はパケットベースのネットワークで使用される標準のコンピュータネットワーキングインターフェイスを含む可能性がある。イーサネットインターフェイスは、標準のＣａｔ５、Ｃａｔ５ｅ、又はＣａｔ６ケーブル経由の１０／１００／１０００Ｍｂｐｓ伝送用のＴＣＰ／ＩＰ及びＵＤＰプロトコルを使用することができる。無線アクセス通信トランシーバは、ＬＴＥ又はその他のセルラートランシーバ、ＷＬＡＮトランシーバ（ＩＥＥＥ８０２.１１）、ＷｉＭＡＸトランシーバ、Ｂｌｕｅｔｏｏｔｈトランシーバ、ＮＦＣトランシーバ、無線自動識別（ＲＦＩＤ）、又はネットワークノードと直接又は間接的に（例えば、無線アクセスノードを介して）通信するように構成されたその他の無線通信トランシーバを含むことがあるが、これらに限定されない。
【0081】
プラットフォーム８００は、例えば、ユニバーサルシリアルバス（ＵＳＢ）、ＲＳ－２３２シリアルポート、スマートカードリーダ、グラフィカルユーザインターフェイス（ＧＵＩ）、発光ダイオード（ＬＥＤ）、又はその他のユーザ関連Ｉ／Ｏインターフェイスなどの電子データ交換又は汎用通信などのユーザインターフェイス（ＵＩ）通信（ＣＯＭＭ）モジュール８８０を備えることがある。
【0082】
電源８７０は、プラットフォーム８００の電子部品に電力を供給し、必要な電圧及び電流要件を提供するレギュレータ及びコンバータを含む可能性がある。バッテリ８７５は、例えば低電力モードや、保護されたメモリの中身を維持するなどのセキュリティ上の理由で必要なときにも電力を供給することができる。
【0083】
更なる定義と実施形態：
消費者は、電子署名のさまざまな用途にモバイルデバイスを使用することが増えている。例えば、クレジットカード取引の承認にクレジットカードを安全に保存して使用することなどである。携帯電話をＩＤ管理デバイスとして使用するというアイデアは以前にも提案されている。このような構成では、鍵認証プロセスが、デバイスの出所を認証局までさかのぼって示すＸ.５０９証明書チェーンをもたらす一連のステップを実行するサービスプロバイダ（ＳＰ）に依存する可能性がある。ただし、個々の電話は完全に信頼されているわけではないため、業界では共通の信頼できるアプローチが必要である。ここで説明するプライベート証明書を承認するためのプロトコルは、モバイルデバイスでの属性の使用に対する強力な差別化要因になる可能性がある。これは、モバイルウォレット、ＣＮＩｅ、ＭｕｌｔｉＡｐｐｖＸ、モバイルＩＤ、ｅ－ＩＤ、モバイルウォレット、ＩＳＯ ＳＣ１７ ＷＧ４委員会のモバイルＩＤのビルディングブロックに関するＩＳＯ ＩＥＣ２３２２０など、さまざまなビジネスに適用可能である。ＣＮＩｅは、カード物理に基づくフランスのデジタルＩＤであるｃａｒｔｅ ｎａｔｉｏｎａｌｅ ｉｄｅｔｅｎｔｉｔｅ ｅｌｅｃｔｒｏｎｉｃｉｑｕｅである。
消費者は、電子署名のさまざまな用途にモバイルデバイスを使用することが増えている。例えば、クレジットカード取引の承認にクレジットカードを安全に保存して使用することなどである。携帯電話をＩＤ管理デバイスとして使用するというアイデアは以前にも提案されている。このような構成では、鍵認証プロセスが、デバイスの出所を認証局までさかのぼって示すＸ.５０９証明書チェーンをもたらす一連のステップを実行するサービスプロバイダ（ＳＰ）に依存する可能性がある。ただし、個々の電話は完全に信頼されているわけではないため、業界では共通の信頼できるアプローチが必要である。ここで説明するプライベート証明書を承認するためのプロトコルは、モバイルデバイスでの属性の使用に対する強力な差別化要因になる可能性がある。これは、モバイルウォレット、ＣＮＩｅ、ＭｕｌｔｉＡｐｐｖＸ、モバイルＩＤ、ｅ－ＩＤ、モバイルウォレット、ＩＳＯ ＳＣ１７ ＷＧ４委員会のモバイルＩＤのビルディングブロックに関するＩＳＯ ＩＥＣ２３２２０など、さまざまなビジネスに適用可能である。ＣＮＩｅは、カード物理に基づくフランスのデジタルＩＤであるｃａｒｔｅ ｎａｔｉｏｎａｌｅ ｉｄｅｔｅｎｔｉｔｅ ｅｌｅｃｔｒｏｎｉｃｉｑｕｅである。
【0084】
デバイス認証により、組織はネットワークアプリやワークスペースに接続しようとしているデバイスのセキュリティ状態を知ることができる。認証の目的は、何かについて信頼できる証拠や証明を提供することである。ＩＤ認証により、デバイスはシリアル番号やＩＭＥＩなどのハードウェア識別子を証明することができる。デバイス認証の概念は、デバイスのユーザ又は所有者にも同様に適用されることがある。例えば、サイバーセキュリティエコシステムの場合、これは、銀行やクラウドプロバイダなどの依拠当事者（ＲＰ）が、デバイスから受信しているデータ、例えばデバイスを提示するユーザの識別に関連するユーザ文書について確信を持てることを示唆することになる。
【0085】
本開示のさまざまな実施形態の上記説明において、本開示の態様は、任意の新規かつ有用なプロセス、マシン、製造、又は組成物、又はそれらの任意の新規かつ有用な改良を含む多数の特許可能なクラス又は文脈のいずれかにおいて本明細書に例示及び説明されることがある。したがって、本開示の態様は、完全にハードウェア、完全にソフトウェア（ファームウェア、常駐ソフトウェア、マイクロコードなどを含む）又はソフトウェアとハードウェアを組み合わせた実装で実施されることがあり、これらはすべて、本明細書において概して「回路」、「モジュール」、「コンポーネント」、又は「システム」と称されることがある。更に、本開示の態様は、その上に具現化されたコンピュータ可読プログラムコードを有する１つ以上のコンピュータ可読媒体を含むコンピュータプログラム製品の形態を取ることがある。
【0086】
１つ以上のコンピュータ可読媒体の任意の組み合わせが使用されることがある。コンピュータ可読媒体は、コンピュータ可読信号媒体又はコンピュータ可読記憶媒体である場合がある。コンピュータ可読記憶媒体は、例えば、電子、磁気、光、電磁気、又は半導体システム、装置、又はデバイス、又は前述の任意の適切な組み合わせである場合があるが、これらに限定されない。この文書の文脈では、コンピュータ可読記憶媒体は、命令実行システム、装置、又はデバイスによって、又はそれらに関連して使用されるプログラムを格納又は保存し得る任意の有形媒体である場合がある。
【0087】
コンピュータ可読信号媒体は、コンピュータ可読プログラムコードが具現化された伝搬データ信号を、例えば、ベースバンドで、又は搬送波の一部として含むことがある。そのような伝播信号は、電気磁気、光学、又はそれらの任意の好適な組み合わせを含むがこれらに限定されないさまざまな形態のいずれかを取ることがある。コンピュータ可読信号媒体は、コンピュータ可読記憶媒体ではなく、命令実行システム、装置、又はデバイスによって、若しくはそれに関連してプログラムを通信、伝搬、又は輸送し得る任意のコンピュータ可読媒体である場合がある。コンピュータ可読信号媒体上で具現化されたプログラムコードは、無線、有線、光ファイバケーブル、ＲＦなど、又は前述の任意の適切な組み合わせを含むがこれらに限定されない任意の適切な媒体を用いて伝送されることがある。
【0088】
本開示の態様のための動作を実行するためのコンピュータプログラムコードは、Ｊａｖａ、Ｓｃａｌａ、Ｓｍａｌｌｔａｌｋ、Ｓｃｈｅｍｅ、Ｇｏ、Ｃ＋＋、Ｃ＃、ＶＢ．ＮＥＴ、Ｐｙｔｈｏｎなどのオブジェクト指向プログラミング言語、「Ｃ」プログラミング言語、Ｐｅｒｌ、ＰＨＰなどの従来の手続き型プログラミング言語、Ｐｙｔｈｏｎ、Ｒｕｂｙ及びＧｒｏｏｖｙなどの動的プログラミング言語、又は他のプログラミング言語を含む、１つ以上のプログラミング言語の任意の組み合わせで書かれることがある。プログラムコードは、ユーザのコンピュータ上で完全に、ユーザのコンピュータ上で部分的に、スタンドアロンのソフトウェアパッケージとして、ユーザのコンピュータ上で部分的にかつリモートコンピュータ上で部分的に、リモートコンピュータ又はサーバ上で完全に、又はクラウド若しくは他のコンピュータネットワーク内で実行することがある。後者のシナリオでは、リモートコンピュータは、ローカルエリアネットワーク（ＬＡＮ）又は広域ネットワーク（ＷＡＮ）を含む任意のタイプのネットワークを通してユーザのコンピュータに接続されることがあるか、又は接続は外部コンピュータ（例えば、インターネットサービスプロバイダを使用してインターネットを通して）に対して、又はクラウドコンピューティング環境において、又はＳｏｆｔｗａｒｅ ａｓ ａ Ｓｅｒｖｉｃｅ（ＳａａＳ）、モバイルアプリをクラウドベースのサービスに接続するためのＢａｃｋｅｎｄ ａｓ ａ Ｓｅｒｖｉｃｅ（ＢａａＳ）、及びＳｅｃｕｒｉｔｙ ａｓ ａ Ｓｅｒｖｉｃｅ（ＳＥＣａａｓ）などのサービスとして提供されることがある。
【0089】
本開示の態様は、本開示の実施形態による方法、装置（システム）、及びコンピュータプログラム製品のフローチャート図及び／又はブロック図を参照して、本明細書で説明される。フローチャート図及び／又はブロック図の各ブロック、並びにフローチャート図及び／又はブロック図におけるブロックの組み合わせが、コンピュータプログラム命令によって実装され得ることが理解されるであろう。これらのコンピュータプログラム命令は、汎用コンピュータ、専用コンピュータ、又は他のプログラム可能データ処理装置のプロセッサに提供されて、コンピュータ又は他のプログラム可能命令実行装置のプロセッサを介して実行される命令が、フローチャート及び／又はブロック図のブロック又は複数のブロックで指定された機能／作用を実装するための機構を作成するように、マシンを生成することがある。
【0090】
これらのコンピュータプログラム命令はまた、コンピュータ可読媒体に格納されることがあり、実行されたときに、コンピュータ、他のプログラム可能データ処理装置、又は他のデバイスが特定の方法で機能するように指示することができるため、コンピュータ可読媒体に記憶されている場合、命令は、実行されたときに、コンピュータにフローチャート及び／又はブロック図のブロック又は複数のブロック内で指定された機能／作用を実装させる命令を含む製品を生成する。コンピュータプログラム命令はまた、コンピュータ、他のプログラム可能命令実行装置、又は他のデバイスにロードされて、一連の動作ステップをコンピュータ、他のプログラム可能装置、又は他のデバイス上で実施させ、コンピュータ実装プロセスを生成することができるので、コンピュータ又は他のプログラム可能装置上で実行する命令は、フローチャート及び／又はブロック図のブロック又は複数のブロック内で指定された機能／作用を実装するためのプロセスを提供する。
【0091】
本明細書で使用される用語が、特定の実施形態のみを説明する目的のためであり、本発明を限定することを意図するものではないことを理解されたい。別途定義されない限り、本明細書で使用されるすべての用語（技術用語及び科学用語を含む）は、本開示が属する技術分野の当業者によって一般に理解されるのと同じ意味を有する。一般的に使用される辞書で定義されるものなどの用語が、本明細書及び関連技術に照らしてそれらの意味と一致する意味を有すると解釈されるべきであり、本明細書で明示的にそのように定義されない限り、理想的又は過度に形式的な意味で解釈されるべきではないことが更に理解されるであろう。
【0092】
図のフローチャート及びブロック図は、本開示のさまざまな態様によるシステム、方法、及びコンピュータプログラム製品の可能な実装のアーキテクチャ、機能、及び動作を示す。これに関して、フローチャート又はブロック図の各ブロックは、指定された論理機能を実装するための１つ以上の実行可能命令を含む、コードのモジュール、セグメント、又は部分を表すことがある。また、一部の代替的な実装形態では、ブロックに記載された機能が、図に記載された順序から発生し得ることにも留意されたい。例えば、連続して示される２つのブロックは、実際には実質的に同時に実行されることがあるか、又はブロックは、関与する機能に応じて、逆の順序で実行されることがある。ブロック図及び／又はフローチャート図の各ブロック、並びにブロック図及び／又はフローチャート図におけるブロックの組み合わせが、特定の機能又は作用を実施する専用ハードウェアベースのシステム、又は専用ハードウェアとコンピュータ命令との組み合わせによって実施され得ることにも留意されたい。
【0093】
本明細書で使用される用語は、特定の態様のみを説明する目的のためであり、本開示を限定することを意図するものではない。本明細書で使用される場合、単数形「ａ」、「ａｎ」、及び「ｔｈｅ」は、文脈が別途明確に示さない限り、複数形も含むことが意図される。本明細書で使用される場合、「含む」及び／又は「含んでいる」という用語が、記載された特徴、整数、ステップ、動作、要素、及び／又はコンポーネントの存在を指定するが、１つ以上の他の特徴、整数、ステップ、動作、要素、コンポーネント、及び／又はそれらのグループの存在又は追加を排除しないことが更に理解されるであろう。本明細書で使用される場合、「及び／又は」という用語は、関連する列挙された項目のうちの１つ以上のいずれか及びすべての組み合わせを含む。図面の説明を通して、同様の参照番号は同様の要素を示す。
【0094】
以下の特許請求の範囲における任意の手段又はステップ並びに機能要素の対応する構造、材料、作用、及び等価物は、特に請求される他の特許請求される要素と組み合わせて機能を実施するための任意の開示された構造、材料、又は作用を含むことが意図される。本開示の説明は、例示及び説明の目的で提示されており、網羅的であること、又は開示された形態の開示に限定されることを意図するものではない。本開示の範囲及び趣旨から逸脱することなく、多くの修正及び変形が当業者には明らかであろう。本明細書の開示の態様は、本開示の原理及び実際の用途を最もよく説明するために選択及び記載され、当業者が、企図される特定の使用に適したさまざまな修正を伴う本開示を理解することを可能にする。
【図1】
【図2】
【図3】
【図4A】
【図4B】
【図5】
【図6】
【図7】
【図8】
【国際調査報告】