特表 2023-519081 拡張可能なサーバを用いるデジタル署名システム

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】公表特許公報(A)

(11)【公表番号】

(43)【公表日】2023-05-10

(54)【発明の名称】拡張可能なサーバを用いるデジタル署名システム

(51)【国際特許分類】

   G09C 1/00 20060101AFI20230428BHJP

   H04L 9/32 20060101ALI20230428BHJP

   G06F 21/64 20130101ALI20230428BHJP

【ＦＩ】

G09C1/00 650Z

H04L9/32 200B

G06F21/64

【審査請求】有

【予備審査請求】未請求

(21)【出願番号】P 2022543429

(86)(22)【出願日】2020-01-15

(85)【翻訳文提出日】2022-08-18

(86)【国際出願番号】 US2020013712

(87)【国際公開番号】W WO2021145874

(87)【国際公開日】2021-07-22

(81)【指定国・地域】

(71)【出願人】

【識別番号】520127764

【氏名又は名称】プラネットウェイ コーポレイション

(74)【代理人】

【識別番号】100087642

【弁理士】

【氏名又は名称】古谷 聡

(74)【代理人】

【識別番号】100082946

【弁理士】

【氏名又は名称】大西 昭広

(74)【代理人】

【識別番号】100195693

【弁理士】

【氏名又は名称】細井 玲

(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】

【図1】単一の秘密鍵を用いる従来の非対称暗号を利用するシステムを示す。

【0010】

【図2】単一の秘密鍵に依存する複数の秘密鍵シェアを使用する分割鍵非対称暗号を利用するシステムを示す。

【0011】

【図3】互いに無関係である複数の秘密鍵を使用する複合鍵非対称暗号を利用するシステムを示す。

【0012】

【図4】特定のサーバ情報を用いて総合的公開鍵および最終決定された署名（最終決定署名と称する）を生成するシステムを示す。

【0013】

【図5】署名要求に応答して、１つ又は複数の遠隔のセキュリティデバイスと協働して、署名を生成することを容易にする署名オーソリティのブロック図である。

【図6】署名要求に応答して、１つ又は複数の遠隔のセキュリティデバイスと協働して、署名を生成することを容易にする署名オーソリティのブロック図である。

【0014】

【図7】図５及び図６の署名オーソリティを含む例示的なシステムを示す。

【0015】

【図8】図５、図６及び図７の非対称暗号のデバイス側部分を具現化するセキュアデバイスを示す。

【0016】

【図9】図８のセキュアデバイスの電子的構成要素のブロック図である。

【0017】

【図10】図５、図６及び図７のシステムにより具現化され得る、デジタルドキュメント用の署名を生成するための方法の流れ図である。

【0018】

【図11A】図５、図６及び図７のシステムにより具現化され得る、デジタルドキュメント用の署名を生成するための方法の流れ図である。

【図11B】図５、図６及び図７のシステムにより具現化され得る、デジタルドキュメント用の署名を生成するための方法の流れ図である。

【0019】

例示的な実施形態の詳細な説明
本発明は様々な形態で具現化され得るが、本開示が本発明の例示であると考えられるべきであり且つ本発明を図示された特定の実施形態に制限することを意図されていないという理解の下に、幾つかの例示的で制限しない実施形態が図面に示され、以下で説明される。

【0020】

デジタル署名の台頭と共に、コンピュータインフラストラクチャーは、多数の署名を毎日生成するタスクを確実に処理する必要がある。署名は、サードパーティのアプリケーションサーバにより要求される場合が多い。例えば、署名は、顧客がウエブサイトのプライバシーポリシー及び個人データポリシーを読んだことを承認するために必要とされる場合があり、又は署名は、顧客が税務書類または商事契約（例えば、住宅ローンの申し込みなど）のような政府文書に署名する際に必要とされる場合がある。しかしながら、サードパーティのアプリケーションサーバは、デジタル署名方式に無関係であり、実際の署名プロセスを処理するために配備されていない。署名生成プロセスは、１つ又は複数の物理的なセキュリティデバイスが署名生成プロセスで使用される場合に、より複雑になる。サードパーティのアプリケーションサーバが物理的なセキュリティデバイスに如何にして連絡するかを知ることは実用的ではない。更に、デジタル署名の役割が至る所に存在するにつれて、インフラストラクチャー機構は、信頼できる方法でセキュリティデバイスを追加する及び署名の生成を処理することが必要とされる。

【0021】

後述されるように、署名オーソリティ（Signature Authority:ＳＡ）は、バックエンドサーバ及びフロントエンドサーバを含む。バックエンドサーバは、署名機能を実行し、特定のセキュリティデバイス及び／又はセキュリティトークンと通信する。各バックエンドサーバは、一意の識別子（「ＢＥＳＩＤ」）を有する。フロントエンドサーバは、署名要求を処理するためにサードパーティのアプリケーションサーバと通信する。顧客は署名オーソリティに登録する。登録プロセス中、顧客は、それら自体を１つ又は複数の物理的なセキュリティデバイス及び／又は物理的なセキュリティトークンと関連付ける。セキュリティデバイス（単数または複数）及び／又はセキュリティトークン（単数または複数）は、特定のバックエンドサーバに割り当てられ、その特定のバックエンドサーバが特定のセキュリティデバイス及び／又はセキュリティトークンと通信するのに必要な情報を有するようになっている。

【0022】

複合鍵方式が使用される場合、（ａ）セキュリティデバイスが秘密鍵および公開鍵を生成して、指定されたバックエンドサーバに公開鍵を供給し、及び／又は（ｂ）セキュリティトークンが使用される場合、割り当てられたバックエンドサーバが秘密鍵および顧客と関連付けられた公開鍵を生成する。２つ以上の独立した公開鍵を用いて、バックエンドサーバは、複合公開鍵を作成する。次いで、バックエンドサーバは、複合公開鍵およびＢＥＳＩＤに基づいて、総合的公開鍵を作成する。この総合的公開鍵は、顧客の身元を確認するためのデータと共に、公開鍵リポジトリ（証明書オーソリティ（Certificate Authority：ＣＡ）のような）に転送される。また、バックエンドサーバは、署名生成中に使用されるべきＢＥＳＩＤに基づいて、最終決定鍵も生成する。

【0023】

分割鍵方式が使用される場合、バックエンドサーバは、２つ以上の鍵シェア及び公開鍵を生成する。バックエンドサーバは、鍵シェアの１つをセキュリティデバイスと共有（共用）し、鍵シェアの１つを保持する。次いで、バックエンドサーバは、公開鍵およびＢＥＳＩＤに基づいて総合的公開鍵を作成する。この総合的公開鍵は、顧客の身元を確認するためのデータと共に、公開鍵リポジトリ（証明書オーソリティ（Certificate Authority：ＣＡ）のような）に転送される。また、バックエンドサーバは、署名生成中に使用されるべきＢＥＳＩＤに基づいて、最終決定鍵も生成する。

【0024】

セキュリティデバイスは、（ａ）別個に生成された秘密鍵を安全に格納する、（ｂ）署名者からの入力を受け取る、（ｃ）その入力に基づいて署名者の身元を信頼できるように認証する、（ｄ）署名を生成するためにメッセージを受け取る、（ｅ）別個に生成された秘密鍵およびメッセージでもって署名を生成する、及び（ｆ）署名を要求するコンピューティングデバイス（例えば、サーバなど）に署名を送信することができる任意の携帯用電子デバイスであることができる。幾つかの例において、セキュリティデバイスは、スマートフォン、スマートウォッチ、タブレット型コンピュータ、電子機器が埋め込まれた宝石類（例えば、ブレスレット、指輪、ブローチなど）、スマートカード（例えば、クレジットカード、ＩＤカードなど）、及び／又は電子印鑑などであることができる。幾つかの例において、各セキュリティデバイスは、任意の他のセキュリティデバイスから別個に署名者から入力（例えば、指紋のような生体識別子、パスワードなど）を物理的に受け取るように構成される。幾つかの例において、各セキュリティデバイスは、コンピューティングデバイスと通信する（例えば、インターネットに対する無線接続を介してなど）。代案として、幾つかの例において、セキュリティデバイスの１つは、コンピューティングデバイスと通信する（例えば、インターネットに対する無線接続を介してなど）一次デバイスとしての役割を果たす一方で、他のセキュリティデバイスは、コンピューティングデバイスと通信するためにローカルエリアネットワーク（例えば、無線ローカルエリアネットワーク、ブルートゥース（登録商標）ローエナジー接続など）を介して一次デバイスと通信する。

【0025】

セキュリティトークンは、バックエンドサーバがデジタル署名を生成している際に、顧客の身元を認証するためにバックエンドサーバと直接的に又は間接的に（例えば、モバイルデバイスを介して）通信する。セキュリティトークンは、任意のモバイルデバイスであることができ、当該モバイルデバイスは、バックエンドサーバと通信する且つユーザが当該モバイルデバイスに認証を提供する際にユーザに信用証明物（認証情報）を安全に提供することができる。例えば、当該デバイスは、生体認証センサ及び／又は生体認証入力（例えば、虹彩スキャナ、指紋スキャナなど）を有することができる。別の例として、当該デバイスは、ＧＰＳを有する場合があり、ユーザを認証するためにジオフェンシング又は別のデバイス（例えば、セキュリティデバイス）に対するその近接性に依存する場合がある。幾つかの例において、セキュリティトークンは、現在の署名生成に関与していない別のセキュリティデバイスであることができる。幾つかの例において、セキュリティトークンは、電子機器が埋め込まれた宝石類（例えば、ブレスレット、指輪、ブローチなど）又はスマートカード（例えば、クレジットカード、ＩＤカードなど）である。

【0026】

デジタル署名が作成されるべきである場合、顧客は、信用証明物（認証情報）をアプリケーションサーバ（例えば、顧客を確認するためにアプリケーションサーバにより管理された信用証明物）に提供する。アプリケーションサーバは、公開鍵リポジトリ（証明書オーソリティのような）から総合的公開鍵を検索して取り出すために、顧客の身元を使用する。アプリケーションサーバは、署名オーソリティのフロントエンドサーバと確立された関係（例えば、アプリケーションサーバが署名オーソリティに登録する際に確立されたなど）を有する。アプリケーションサーバは、フロントエンドサーバに署名要求を送信し、当該署名要求は、公開鍵リポジトリから検索して取り出された総合的公開鍵およびメッセージを含む。当該メッセージは、原初のメッセージ（例えば、署名されるべきデジタルドキュメント）、又は当該原初のメッセージに暗号学的ハッシュ関数（例えば、SHA-256など）を適用することにより当該原初のメッセージから算出されたメッセージダイジェストであることができる。フロントエンドサーバは、総合的公開鍵からＢＥＳＩＤを抽出して（取り出して）、当該ＢＥＳＩＤと関連したバックエンドサーバに署名要求を転送する。バックエンドサーバは、セキュリティデバイス及び／又はセキュリティトークンと連係して、メッセージで署名を生成する。次いで、バックエンドサーバは、最終決定署名を生成するために最終決定鍵を使用する。バックエンドサーバは、署名要求を送信したフロントエンドサーバに最終決定署名を送る。次いで、フロントエンドサーバは、署名を要求したアプリケーションサーバに、最終決定署名を転送する。次いで、アプリケーションサーバは、最終決定署名をデジタルドキュメントに付加する。その後、必要な場合に、デジタル署名は、公開鍵リポジトリの総合的公開署名を用いて検証され得る。

【0027】

図１は、単一の秘密鍵を用いる従来の非対称暗号を利用するシステム、及び概して、署名を検証するためのシステムを示す。デジタル署名に使用される一般的な非対称暗号システム（場合によっては、「公開鍵暗号システム」と呼ばれる）は、リベスト－シャミア－エーデルマン（ＲＳＡ）である。図１に示されるように、ＲＳＡ暗号システムは、４つの関数を使用する。第１の関数は、２つの異なる素数ｐ及びｑに基づいて秘密鍵１０２を生成する秘密鍵生成関数（ｆ_１）である。整数ｐ及びｑは、ランダムに選択されて秘密に保たれる。第２の関数は、２つの素数ｐ及びｑに基づいて、公開鍵１０４を生成する公開鍵生成関数（ｆ_２）である。公開鍵１０４は、公開モジュラス（ｎ）及び公開指数（ｅ）からなる。公開モジュラス（ｎ）は、以下の式１に従って計算される。公開指数（ｅ）は、以下の式２が真であるように選択される。即ち、
ｎ＝ｐｑ （式１）
gcd（ｐ－１,ｅ）＝gcd（ｑ－１,ｅ）＝１ （式２）
上記の式２において、gcdは、入力のそれぞれを除算する最大の正の整数を返す最大公約数関数である。ＲＳＡ暗号システムは、秘密鍵１０２でメッセージ（ｍ）１０６に署名するために署名関数（ｆ_３）を使用する。ここで、

ＲＳＡ暗号システムは、メッセージ（ｍ）１０６の署名１０８を計算するために秘密指数（ｄ）を使用する。秘密指数（ｄ）は、以下の式３に従って計算される。即ち、

【数1】

メッセージ（ｍ）１０６の署名１０８は、σ（ｍ）であり、それは以下の式４に従って計算される。即ち、
σ（ｍ）＝ｍ^ｄmodｎ （式４）
受け取った署名（σ）１０８及び添付のメッセージ（ｍ）１０６を検証するために、ＲＳＡ暗号システムは、公開モジュラス（ｎ）及び公開指数（ｅ）に基づいて第４の関数（ｆ_４）を使用する。署名（σ）１０８は、以下の式５が真である際に立証される。即ち
σ^ｅmodｎ＝ｍ （式５）。

【0028】

ＲＳＡに基づいた署名方式の安全（セキュア）な具現化形態は、署名者（例えば、人、又は人のグループ）が関数、即ち、秘密鍵生成関数（ｆ_１）、公開鍵生成関数（ｆ_２）、及びセキュリティ境界内の署名関数（ｆ_３）の唯一の制御を有することを必要とする。一般に、ＲＳＡ署名方式を具現化するデバイスは、（ａ）デバイスの存続期間中に一度だけ秘密鍵生成関数（ｆ_１）及び公開鍵生成関数（ｆ_２）を実行し、（ｂ）認可された署名者だけが署名関数（ｆ_３）を実行することができることを保証する。秘密鍵（例えば、秘密鍵１０２）は、当該デバイスから決して離れてはいけない。当該デバイスは常に、署名関数（ｆ_３）を実行する前に署名者を確実に認証することができなければいけない。かくして、セキュリティデバイスは、セキュリティ境界内で、（ａ）当該関数を計算するための計算能力、（ｂ）当該鍵を格納するためのメモリ、（ｃ）入力／出力（Ｉ／Ｏ）デバイス、及び（ｄ）認証解法を要求する。セキュリティ境界は、それぞれが部分的な機能を具現化する別個の電子装置からなることができる。例えば、鍵生成関数、秘密鍵生成関数（ｆ_１）及び公開鍵生成関数（ｆ_２）は、一組の電子装置により具現化されることができ、署名関数（ｆ_３）は、電子装置の別個の組として具現化され得る。

【0029】

（上述されたＲＳＡ暗号システムのような）署名方式の暗号攻撃耐性は、計算の複雑性理論の観点から定義され、数学的および物理的成分を有する。数学的攻撃耐性の尺度は、当該方式を破壊する（即ち、秘密鍵にアクセスせずにメッセージに署名する）のに必要である計算資源（ステップの数、ビットのメモリ、プログラムサイズなど）を考慮する。当該方式を破壊する計算コストは、セキュリティレベルとして表現される。セキュリティレベルは通常、「ビット」で表される。「Ｎビットセキュリティ」は、悪意のある当事者が当該方式を破壊するために２^Ｎ演算を実行する必要があることを意味する。例えば、署名方式は、１２８ビットセキュリティ又は２５６ビットセキュリティを有することができる。当該方式を破壊する金銭的コストは、計算コストに比例すると考えられる。セキュリティデバイスの物理的攻撃耐性は、署名方式を数学的に破壊せずに署名を偽造するコストを意味する（例えば、セキュリティデバイスを改ざんする）。

【0030】

署名方式に必要な数学的および物理的攻撃耐性は、リスク分析から導出され、署名解法が使用されているアプリケーションを考慮に入れる。多くの場合、セキュリティデバイスの物理的設計は、ＲＳＡベースの署名方式において弱点である。物理的攻撃耐性を向上させるための一手法は、複数のデバイス間の協働を必要とすることになる。係る手法において、署名鍵（例えば、マスター秘密鍵）は、幾つかのセキュリティデバイス間で共用される。そのため、署名は、セキュリティデバイスが協働する際にだけ作成され得る。１つのデバイスを攻撃すること（例えば、１つのデバイスを物理的に改ざんして、１つのデバイス上のマスター秘密鍵の一部を暴露する）は、署名を偽造するのには不十分である。これらの問題に対処するための暗号方式は、以下で図２及び図３に関連して説明される。

【0031】

図２において、マスター秘密鍵２０２は、２つの秘密鍵シェア２０４及び２０６に分割される（時として、分割鍵署名方式と呼ばれる）。マスター秘密鍵２０２は、第１の秘密鍵シェア（ｄ’）２０４及び第２の秘密鍵シェア（ｄ”）２０６を作成するためにマスター秘密鍵２０２を鍵分割関数（ｆ_１０）で分割する、信頼されているディーラー２０８により生成される。信頼されているディーラー２０８は、加法的分散（シェアリング）又は乗法分散のために、マスター秘密鍵２０２を分割することができる。図２は、加法的分散のためにマスター秘密鍵２０２を分割する、信頼されているディーラー２０８を示す。加法的分散のために分割する際、信頼されているディーラー２０８は、以下の式６に従って、マスター秘密鍵２０２の秘密指数（ｄ）に基づいて、第１の秘密鍵シェア（ｄ’）２０４及び第２の秘密鍵シェア（ｄ”）２０６を導出するために、鍵分割関数（ｆ_１０）を使用する。即ち、
ｄ≡ｄ’＋ｄ”（modψ（ｎ）） （式６）
乗算分散のために分割する際、信頼されているディーラー２０８は、以下の式７に従って、第１の秘密鍵シェア（ｄ’）２０４及び第２の秘密鍵シェア（ｄ”）２０６を導出するために、鍵分割関数（ｆ_１０）を使用する。即ち、
ｄ≡ｄ’ｄ”（modψ（ｎ）） （式７）
信頼されているディーラー２０８は、第１の秘密鍵シェア（ｄ’）２０４を第１のセキュリティデバイス２１０に送り、第２の秘密鍵シェア（ｄ”）を第２のセキュリティデバイス２１２に送る。署名を生成する際、セキュリティデバイス２１０及び２１２は、第１の署名シェア（σ’）２１４及び第２の署名シェア（σ”）２１６を生成するためにそれらの個々の秘密鍵シェアと共に、署名関数（ｆ_３）を実行する。署名（σ）１０８は、第１の署名シェア（σ’）２１４及び第２の署名シェア（σ”）２１６と共に、分割鍵結合関数（ｆ_１１）を用いて、生成される。加法的分散の場合、分割鍵結合関数（ｆ_１１）は、以下の式８に従って計算される。即ち、

【数2】

乗法分散の場合、分割鍵結合関数（ｆ_１１）は、以下の式９に従って計算される。即ち、

【数3】

生成された署名１０８は、従来のＲＳＡ署名方式と共に、上述されたように使用される。

【0032】

幾つかの例において、秘密鍵シェアの１つは、セキュリティデバイスにより保持され、他の秘密鍵シェアは、バックエンドサーバ（例えば、以下の図５、図６、及び図７のバックエンドサーバ５１２）により保持される。分割鍵署名方式は、マスター秘密鍵２０２を署名シェア２０４及び２０６へ分割し、次いで署名シェア２１４及び２１６をセキュリティデバイスに安全に送るために、信頼されているディーラー２０８を必要とする場合が多い。幾つかの例において、信頼されているディーラー２０８は、使用されるシェアの分散された生成を使用し、この場合、第１の署名シェア（σ’）２１４及び第２の署名シェア（σ”）２１６及び共通の公開鍵１０４は、マスター秘密鍵２０２が決して全体として存在しないマルチパーティ暗号プロトコル（例えば、マルチパーティ暗号プロトコルII）の結果として生成される。

【0033】

図３は、複数のデバイス間の協働を用いた署名生成を用いる暗号化方式を示す。マスター秘密鍵またはマルチパーティ暗号プロトコルに依存する一組の署名シェアを生成する代わりに、別個に生成された秘密鍵に基づいている個別に生成された署名から、複合署名が構成され得る。これは、場合によっては複合鍵方式と呼ばれる。本明細書で使用される限り、別個に生成された秘密鍵は、任意のマスター秘密鍵またはマルチパーティ暗号プロトコル（例えば、分割鍵署名方式の秘密鍵シェアとは対照的に）を用いて生成されていない秘密鍵である。システムは、２つ以上のデバイスを含み、当該２つ以上のデバイスはそれぞれ、それ自体の公開鍵と関連付けられている別個に生成された秘密鍵を格納する。幾つかの例において、システムは、２つ以上のセキュリティデバイスを含む。幾つかの例において、システムは、１つ又は複数のセキュリティデバイス及びバックエンドサーバ（例えば、セキュリティトークンにより認証された）を含む。

【0034】

図３は、互いと無関係である複数の秘密鍵を使用する複合鍵の鍵非対称暗号を利用するシステムを示す。図３は、第１のセキュリティデバイス３０２及び第２のセキュリティデバイス３０４を使用する複合鍵署名方式を示す。幾つかの例において、第１のセキュリティデバイス３０２又は第２のセキュリティデバイス３０４の一方は、バックエンドサーバ（例えば、以下の図５、図６及び図７のバックエンドサーバ５１２）である。セキュリティデバイス３０２及び３０４はそれぞれ、（上述されたような）秘密鍵生成関数（ｆ_１）を用いて、秘密鍵３０６及び３０８を別個に生成する。更に、セキュリティデバイス３０２及び３０４はそれぞれ、公開モジュラス（ｎ）（例えば、上記の式１に従って計算された）及び公開指数（ｅ）（例えば、上記の式２に従って求められた）を用いて、公開鍵３１０及び３１２を生成する。公開鍵３１０及び３１２は、バックエンドサーバに送られる。セキュリティデバイス３０２及び３０４が署名を生成するために使用するためのメッセージ３１４を受け取る場合、セキュリティデバイスがそれぞれ別個に署名者を認証した後、セキュリティデバイス３０２及び３０４は、（上述されたような）署名関数（ｆ_３）を用いて、署名３１６及び３１８をそれぞれ別個に生成する。

【0035】

デジタルドキュメントを署名するために、複合署名３２０が、第１の署名（σ_１）３１６及び第２の署名（σ_２）３１８から生成される。図示された例において、複合署名（σ_ｃ）３２０は、以下の式１０に従って複合署名関数（ｆ_６）を用いて生成される。即ち、
σ_ｃ＝（ｂｎ_１σ_１＋ａｎ_２σ_２）mod（ｎ_１ｎ_２） （式１０）
上記の式１０において、ｎ_１は、第１の公開鍵３１０の公開モジュラスであり、ｎ_２は、第２の公開鍵３１２の公開モジュラスである。更に、係数ａ及びｂは、ａｎ_１＋ｂｎ_２＝１を満たす。複合署名（σ_ｃ）３２０は更に、バックエンドサーバにより変更され、次いでデジタルドキュメントを添付するために使用される。

【0036】

署名されたドキュメントを検証するために、複合公開鍵３２２の複合公開モジュラス（ｎ_ｃ）が、以下の式１１に従って、複合公開鍵関数（ｆ_５）を用いて計算される。即ち、
ｎ_ｃ＝ｎ_１ｎ_２ （式１１）
複合公開鍵３２２の複合公開モジュラス（ｎ_ｃ）は、第１の公開鍵３１０の公開モジュラス（ｎ_１）及び第２の公開鍵３１２の第２の公開モジュラス（ｎ_２）に基づく。

【0037】

複合公開鍵３２２（＜ｎ_ｃ、ｅ＞）及びメッセージ３１４を用いて、署名されたデジタルドキュメントと関連した署名（σ_ｓ）が、（上述されたような）関数ｆ_４を用いて検証される。

【0038】

図４は、一意のバックエンドサーバ識別子（ＢＥＳＩＤ）４０６を用いて、総合的公開鍵４０２及び最終決定鍵４０４を生成するシステムを示す。システムは、ＢＥＳＩＤ４０６を総合的公開鍵４０２及び最終決定鍵４０４へ埋め込む。以下の説明は、複合鍵方式を使用するが、分割鍵方式も使用され得る。

【0039】

システムは、身元埋込み関数（ｆ_２０）を用いて、総合的公開鍵４０２及び最終決定署名４０８を生成する。身元埋込み関数（ｆ_２０）は、総合的公開鍵４０２及び最終決定署名４０８を生成するために、複合公開鍵３２２（又は任意の他の適用可能な公開鍵）及びＢＥＳＩＤ４０６を使用する。図示された例において、身元埋込み関数（ｆ_２０）は、以下の式１２～式１７に従って計算される。第１に、システムは、以下の式１２に従ってＬバウンドを計算する。即ち、

【数4】

システムは、以下の式１３に従ってＲバウンドを計算する。即ち、

【数5】

上記の式１２及び式１３において、ｃはｍビット長のＢＥＳＩＤであり、ｋは信頼性パラメータであり、ｎ’は、ＲＳＡモジュラス（この場合、

）（複合公開鍵３２２のモジュラス（ｎ_ｃ）などのような）である。次いで、システムは、素数（ｐ）を求め、この場合、以下の式１４が真である。即ち、
Ｌ≦ｐ≦Ｒ、及びgcd（ｐ－１，ｅ）＝１ （式１４）
上記の式１４において、ｅは公開指数であり、gcdは、入力のそれぞれを除算する最も大きい正の整数を返す最大公約数関数である。

【0040】

システムは、以下の式１５に従って、総合的公開鍵４０２のモジュラス（ｎ_ＴＰ）を計算する。即ち、
ｎ_ＴＰ＝ｎ’・ｐ （式１５）
結果として、身元埋込み関数（ｆ_２０）は、総合的公開鍵４０２を＜ｎ_ＴＰ，ｅ＞として出力する。

【0041】

システムは、以下の式１６に従って最終決定指数（ｄ_ｆ）を計算する。即ち、

【数6】

次いで、システムは、以下の式１７が満たされるように、ベズー係数ａ’及びｂ’を求める。即ち、
ａ’・ｐ＋ｂ’・ｎ’＝１ （式１７）
結果として、身元埋込み関数（ｆ_２０）は、最終決定鍵４０４を（ｎ、ａ’、ｂ’、ｐ、ｄ_ｆ）として出力する。

【0042】

バックエンドサーバが複合署名３２０を生成した後、システムは、要求しているアプリケーションサーバに転送されるようにフロントエンドサーバに送るために最終決定署名（σ_Ｆ）４０８を生成する。最終決定署名（σ_Ｆ）４０８は、最終決定関数（ｆ_３０）を用いてそれに埋め込まれるバックエンドサーバのＢＥＳＩＤ４０６を有する。最終決定関数（ｆ_３０）は、ＲＳＡ署名（σ’）（複合署名（σ_ｃ）３２０などのような）、パディングされたメッセージＰ、及び最終決定署名（σ_Ｆ）を生成するための最終決定鍵４０４（例えば、（ｎ，ａ’，ｂ’，ｐ，ｄ_ｆ）など）を使用する。図示された例において、最終決定関数（ｆ_３０）は、以下の式１８～式２０に従って計算される。最初に、システムは、以下の式１８に従って、パディングされたメッセージＰを切り詰める。即ち、
Ｐ_ｆ＝Ｐmodｐ （式１８）
上記の式１８において、Ｐ_ｆは切り詰められたメッセージである。次いで、システムは、以下の式１９に従って、部分的な最終署名（σ_ｆ）を計算する。即ち、

【数7】

次いで、システムは、以下の式２０に従って、最終決定署名（σ_Ｆ）４０８を計算する。即ち、

【数8】

次いで、システムは、最終決定署名（σ_Ｆ）をフロントエンドサーバに転送する。

【0043】

フロントエンドサーバが、アプリケーションサーバから署名要求を受け取る場合、署名要求は、総合的公開鍵４０２＜ｎ_ＴＰ，ｅ＞を含む。フロントエンドサーバは、身元抽出関数（ｆ_４０）を用いて、総合的公開鍵４０２からＢＥＳＩＤ４０６を抽出する。ＢＥＳＩＤ４０６は、ｍビット長を有する。図示された例において、身元抽出関数（ｆ_４０）は、総合的公開鍵４０２のモジュラス（ｎ_ＴＰ）のｍ最上位ビットを抽出することにより、ＢＥＳＩＤを抽出する。モジュラス（ｎ_ＴＰ）のｍ最上位ビットは、ＢＥＳＩＤ４０６である。

【0044】

図５及び図６は、署名要求５０４に応答して、１つ又は複数の遠隔のセキュリティデバイス５０２と協働して署名を生成することを容易にする署名オーソリティ５００のブロック図である。顧客５０６は、アプリケーションサーバ５０８が署名要求５０４を生成するように、アプリケーションサーバ５０８と対話する。例えば、顧客５０６は、ドキュメントに署名する、又はウエブサイト上のプライバシーポリシー及びデータ使用ポリシーを受諾することができる。署名オーソリティ５００は、署名プロセスを管理し、必要とされるセキュリティデバイス５０２と通信する。

【0045】

署名オーソリティ５００は、１つ又は複数のフロントエンドサーバ５１０及び１つ又は複数のバックエンドサーバ５１２を含む。フロントエンドサーバ５１０のそれぞれは、バックエンドサーバ５１２のそれぞれに通信可能に結合される。より多くのアプリケーションサーバ５０８が署名オーソリティ５００を使用する際、署名オーソリティは、より多くのフロントエンドサーバ５１０を追加する。特定のアプリケーションサーバ５０８は、特定のフロントエンドサーバ５１０又はフロントエンドサーバ５１０のリストと関連付けられ得る。アプリケーションサーバ５０８が署名要求５０４を送る場合、それは、関連したフロントエンドサーバ５１０にそれを送る。幾つかの例において、アプリケーションサーバ５０８は、アプリケーション・プログラミング・インターフェース（ＡＰＩ）を用いて、フロントエンドサーバ５１０と通信する。

【0046】

より多くのセキュリティデバイス５０２が配置される場合、署名オーソリティ５００は、より多くのバックエンドサーバ５１２を追加する。バックエンドサーバ５１２は、セキュリティデバイス５０２の特定のものと通信する。バックエンドサーバ５１２は、割り当てられたセキュリティデバイス５０２と通信するのに必要な情報を有する、セキュリティデバイス５０２のデータベースを含む。

【0047】

フロントエンドサーバ５１０及びバックエンドサーバ５１２は、バーチャルマシン又はコンテナなどのような、仮想計算資源を用いて、同じ物理的マシン又は物理的マシンの組で動作することができる。幾つかの例において、フロントエンドサーバ５１０及びバックエンドサーバ５１２は、一方が破壊された場合に、他方が全然影響を受けないように、互いから分離される。例えば、１つのフロントエンドサーバ５１０が破壊された場合、他のフロントエンドサーバ５１０及びバックエンドサーバ５２１は影響を受けない。

【0048】

顧客５０６は、アプリケーションサーバ５０８と対話する。アプリケーションサーバ５０８により確立されるように、アプリケーションサーバ５０８は、顧客５０６を認証し且つ身元を確認する。例えば、アプリケーションサーバ５０８は、公開鍵リポジトリ５１４（証明書オーソリティのような）から顧客５０６と関連付けられた公開鍵を検索して取り出すことができるように、ログイン認証情報および十分な個人情報で顧客５０６がアカウントを作成することを要求することができる。デジタル署名を要求する顧客５０６との対話（相互作用）に基づいて、アプリケーションサーバ５０８は、署名要求５０４を生成する。署名要求５０４を生成するために、アプリケーションサーバ５０８は、（ａ）公開鍵リポジトリ５１４から総合的公開鍵（例えば、上記図４の総合的公開鍵４０２）を検索して取り出し、（ｂ）メッセージを生成する。メッセージは、原初のメッセージ（例えば、署名されるべきデジタルドキュメント）、又は当該原初のメッセージに暗号学的ハッシュ関数（例えば、SHA-256など）を適用することにより当該原初のメッセージから算出されたメッセージダイジェストであることができる。アプリケーションサーバ５０８は、署名要求５０４を署名オーソリティ５００に送る。アプリケーションサーバ５０８は、署名要求５０４を、関連したバックエンドサーバ５１０に送る。

【0049】

フロントエンドサーバ５１０は、アプリケーションサーバ５０８から署名要求５０４を受け取る。身元抽出関数（ｆ_４０）を用いて、フロントエンドサーバ５１０は、総合的公開鍵４０２からバックエンドサーバ５１２のＢＥＳＩＤ４０６を抽出する。ＢＥＳＩＤ４０６は、顧客５０６のセキュリティデバイス（単数または複数）５０２と関係があるバックエンドサーバ５１２に対応する。フロントエンドサーバ５１０は、ＢＥＳＩＤ４０６と関連付けられたバックエンドサーバ５１２に署名要求を転送する。

【0050】

バックエンドサーバ５１２は、総合的公開鍵４０２を用いて、顧客５０６の身元を確認する。

【0051】

図５は、バックエンドサーバ５１２が顧客５０６と関連付けられた秘密鍵（例えば、複合鍵方式用の別個の秘密鍵、又は分割鍵署名方式用の鍵シェアなど）を含む例示的な実施形態を示す。図５において、バックエンドサーバ５１２は、（例えば、セキュリティトークン５１６を介して）顧客５０６の身元を認証することを試みる。バックエンドサーバ５１２が顧客５０６の身元を首尾よく認証する場合、それは、メッセージ及び顧客５０６と関連した秘密鍵を用いて第１の署名（又は第１の署名シェア）を生成するために署名関数（ｆ_３）を使用する。また、バックエンドサーバ５１２は、顧客５０６と関連付けられたセキュリティデバイス５０２に署名要求（又はその一部）も送る。セキュリティデバイス５０２が顧客５０６の身元を認証した後、セキュリティデバイス５０２は、第２の署名（又は第２の署名シェア）５１８を生成し、それをバックエンドサーバ５１２に送る。複合鍵の実施形態において、バックエンドサーバ５１２は、複合署名関数（ｆ_６）を用いて、複合署名３２０を生成する。分割鍵の実施形態において、バックエンドサーバ５１２は、分割鍵結合関数（ｆ_１１）を用いて、署名を生成する。最終決定鍵４０４を用いて、バックエンドサーバ５１２は、最終決定関数（ｆ_３０）を用いて最終決定署名４０８を生成する。

【0052】

図６は、バックエンドサーバ５１２が２つ以上のセキュリティデバイス５０２と通信する例示的な実施形態を示す。バックエンドサーバ５０６は、顧客５０６と関連付けられたセキュリティデバイス５０２のそれぞれに署名要求（又はその一部）を送る。セキュリティデバイス５０２のそれぞれは、別個に顧客５０６を認証し、署名（又は署名シェア）５１８を生成し、それをバックエンドサーバ５１２に送る。係る実施形態において、バックエンドサーバ５１２は、顧客５０６と関連付けられた秘密鍵を格納しない。複合鍵の実施形態において、バックエンドサーバ５１２は、複合署名関数（ｆ_６）を用いて、複合署名３２０を生成する。分割鍵の実施形態において、バックエンドサーバ５１２は、分割鍵結合関数（ｆ_１１）を用いて、署名を生成する。最終決定鍵４０４を用いて、バックエンドサーバ５１２は、最終決定関数（ｆ_３０）を用いて最終決定署名４０８を生成する。

【0053】

バックエンドサーバ５１２は、署名要求５０４を送ったフロントエンドサーバ５１０に、最終決定署名４０８を送る。フロントエンドサーバ４０８は、署名要求５０４を送ったアプリケーションサーバ５０８に、最終決定署名４０８を送る。アプリケーションサーバ５０８は、署名されるべきデジタルドキュメントに最終決定署名４０８を添付する。

【0054】

顧客５０６が署名オーソリティ５００に登録し及び／又はそれらと関連付けられるべきセキュリティデバイス５０２を追加する場合、バックエンドサーバ５１２は、総合的公開鍵４０２及び最終決定鍵４０４を作成し、それらの鍵の双方を顧客５０６と関連付ける（例えば、顧客の一意の識別子およびセキュリティデバイスの一意の識別子を用いてなど）。公開鍵（例えば、複合公開鍵関数（ｆ_５）を用いて作成された複合公開鍵３２２、又は共通公開鍵１０４など）及びバックエンドサーバ５１２のＢＥＳＩＤ４０６を用いて、バックエンドサーバ５１２は、身元埋込み関数（ｆ_２０）を用いて、総合的公開鍵４０２及び最終決定鍵４０４を作成する。総合的公開鍵４０２は、顧客５０６と関連付けられるべき公開鍵リポジトリ５１４に送られる。

【0055】

図７は、図５及び図６の署名オーソリティ５００を含む例示的なシステムを示す。図７に示された例において、署名オーソリティ５００は、複数のアプリケーションサーバ５０８に接続された複数のフロントエンドサーバ５１０のインスタンスを含む。また、図７は、複数の顧客５０６と関連付けられた複数のセキュリティデバイス５０２にそれぞれ接続されたバックエンドサーバ５１２の複数のインスタンスも示す。図示された例において、アプリケーションサーバ５０４の１つは、フロントエンドサーバ５１０の１つに署名要求５０４を送る。フロントエンドサーバ５１０は、身元抽出関数（ｆ_４０）を用いて、署名要求５０４に含まれる総合的公開鍵４０２に暗号学的に埋め込まれているＢＥＳＩＤ４０６を求める。抽出されたＢＥＳＩＤ４０６に基づいて、フロントエンドサーバ５１０は、署名要求５０４を、対応するバックエンドサーバ５１２に転送する。

【0056】

図８は、図１、図２、図３、図５、図６及び図７の署名方式のデバイス側の部分を具現化するセキュアデバイス５０２を示す。セキュリティデバイス５０２は、関数、即ち秘密鍵生成関数（ｆ_１）、公開鍵生成関数（ｆ_２）及び署名関数（ｆ_３）を具現化する。セキュリティデバイス５０２は、制御インターフェース８０２及び入力／出力（Ｉ／Ｏ）インターフェース８０４を含む。制御インターフェース８０２は、セキュリティデバイス５０２が署名（例えば、署名３１６及び３１８）を生成する前に、署名者の身元を認証するために署名者（例えば、顧客５０６など）からの入力を受け取る。Ｉ／Ｏインターフェース８０４は、署名および公開鍵を送る、及び署名を生成するために使用されるメッセージを受け取るために、署名オーソリティ（例えば、上記の図５、図６及び図７の署名オーソリティ５００）と直接的または間接的に通信する。

【0057】

図９は、図８のセキュリティデバイス５０２の電子構成要素９００のブロック図である。図示された例において、電子構成要素９００は、制御インターフェース８０２、Ｉ／Ｏインターフェース８０４、プロセッサ又はコントローラ９０２、及びメモリ９０４、並びに他の電子構成要素を接続するデータバス９０６を含む。

【0058】

制御インターフェース８０２は、セキュリティデバイス５０２と署名者との間に物理的なインターフェースを提供する。制御インターフェース８０２は、デジタルカメラ（例えば、イメージキャプチャ、視覚による指示の認識、顔認識、虹彩認識などのために）、タッチスクリーン及び／又はキーボード（例えば、認証情報の入力のために）、音声入力デバイス（例えば、音声認識用のマイクロフォンなど）、生体認証入力デバイス（例えば、指紋スキャナなど）、及び／又は生体認証センサ（例えば、血中酸素濃度計、脈拍センサなど）を含むことができる。例えば、制御インターフェース８０２は、スマートフォンのタッチスクリーン及び指紋同定センサを含むことができる。署名者から制御インターフェース８０２への入力は、署名者の身元を認証するために使用される。幾つかの例において、署名者を識別および認証する２つ以上の方法が含まれる。例えば、署名者は、指紋とパスワードの双方を提供する必要がある場合がある。幾つかの例において、制御インターフェース８０２は、２つの協働するセキュリティデバイス５０２間で異なる場合がある。例えば、一方のセキュリティデバイス５０２は顔認識を行うためにカメラを有することができ、他方のセキュリティデバイス５０２は指紋スキャナを有することができる。

【0059】

Ｉ／Ｏインターフェース８０４は、公開鍵および署名を送る且つメッセージを受け取るために他のデバイスと通信するためのインターフェースを提供する。Ｉ／Ｏインターフェース８０４は、通信コントローラ、及び１つ又は複数の標準ベースのネットワーク（例えば、グローバル・システム・フォー・モバイル・コミュニケーションズ（ＧＳＭ）、ユニバーサル・モバイル・テレコミュニケーション・システム（ＵＭＴＳ）、ロング・ターム・エボリューション（ＬＴＥ）、符号分割多元接続（ＣＤＭＡ）、ＷｉＭＡＸ（IEEE 802.16m）；近距離無線通信（ＮＦＣ）；無線ＬＡＮ（IEEE 802.11 a/b/g/n/ac又は他を含む）、ブルートゥース（登録商標）及びブルートゥース（登録商標）ローエナジー、及びワイヤレスギガビット（IEEE 802.11ad）など）用のアンテナを含む。Ｉ／Ｏインターフェース８０４は、外部ネットワークと直接的または間接的に（例えば、別のセキュリティデバイス５０２を介して）通信する。外部ネットワークは、インターネットのような公共ネットワーク、イントラネットのような私的ネットワーク、又はそれらの組合わせであることができ、以下に限定されないが、ＴＣＰ／ＩＰベースのネットワークプロトコルを含む現在利用可能な又は後に開発される様々なネットワークプロトコルを利用することができる。

【0060】

プロセッサ又はコントローラ９０２は、以下に限定されないが、マイクロプロセッサ、マイクロコントローラベースのプラットフォーム、適切な集積回路、１つ又は複数のフィールド・プログラマブル・ゲート・アレイ（ＦＰＧＡ）、及び／又は１つ又は複数の特定用途向け集積回路（ＡＳＩＣ）のような、任意の適切な処理デバイス又は処理デバイスの組であることができる。メモリ９０４は、揮発性メモリ、不揮発性メモリ、不変メモリ、読み出し専用メモリ、及び／又は大容量記憶デバイス（例えば、ハードドライブ、半導体ドライブなど）であることができる。幾つかの例において、メモリ９０４は、複数種類のメモリ、特に揮発性メモリ及び不揮発性メモリを含む。更に、メモリ９０４は、情報を安全に格納するためにそれ自体の認証鍵を備える埋め込まれたハードウェア暗号化エンジンを含むセキュアメモリ（時として、「クリプトメモリ（CryptoMemory）（登録商標）」と呼ばれる）を含むことができる。

【0061】

図１０は、図５、図６及び図７のシステムにより具現化され得る、デジタルドキュメント用の署名を生成するための方法の流れ図である。最初に、ブロック１００２において、アプリケーションサーバ５０８は、デジタル署名の生成を開始する顧客５０６からの入力を受け取る。例えば、顧客５０６は、認証情報を提供して、プライバシーポリシー及びデータ保護ポリシーに対する承諾を認めるために、ウエブサイト上の「承諾」ボタンをクリックすることができる。ブロック１００４において、アプリケーションサーバ５０８は、公開鍵リポジトリ５１４から顧客５０６と関連付けられた総合的公開鍵４０２を検索して取り出す。ブロック１００６において、アプリケーションサーバ５０８は、署名要求５０４をフロントエンドサーバ５１０に送る。

【0062】

ブロック１００６において、フロントエンドサーバ５１０は、署名要求５０４に含まれる総合的公開鍵４０２から暗号学的に埋め込まれたＢＥＳＩＤ４０６を抽出するために身元抽出関数（ｆ_４０）を使用する。ブロック１００８において、フロントエンドサーバ５１０は、抽出されたＢＥＳＩＤ４０６に対応するバックエンドサーバ５１２に署名要求を転送する。バックエンドサーバ５１２が顧客５０６と関連付けられた秘密鍵を格納している場合、方法は、ブロック１１０２（図１１Ａ）に進む。バックエンドサーバ５１２が顧客５０６と関連付けられた秘密鍵を格納しない場合、方法はブロック１１２０（図１１Ｂ）に進む。

【0063】

ブロック１００８において、フロントエンドサーバ５１０は、バックエンドサーバ５１２から最終決定署名４０８を受け取り、最終決定署名４０８をアプリケーションサーバ５０８に転送する。

【0064】

ブロック１０１０において、アプリケーションサーバ５０８は、最終決定署名４０８を、デジタルドキュメントに添付することにより、デジタルドキュメントにデジタル的に署名する。

【0065】

図１１Ａは、図５、図６及び図７のシステムにより具現化され得る、バックエンドサーバ５１２が顧客５０６の秘密鍵を格納する場合にデジタルドキュメント用の署名を生成するための流れ図である。ブロック１１０２において、バックエンドサーバ５１２は、署名要求５０４をセキュリティデバイス５０２に送る。ブロック１１０４において、セキュリティデバイス５０２は顧客５０６を認証する。例えば、セキュリティデバイス５０２は、指紋および／または一組の認証情報を受け取ることに応じて、顧客５０６を認証することができる。ブロック１１０６において、セキュリティデバイス５０２は、署名関数（ｆ_３）を用いて、その格納された秘密鍵でもって第１の署名を生成する。ブロック１１０８において、セキュリティデバイス５０２は、第１の署名をバックエンドサーバ５１２に送る。

【0066】

ブロック１１１０において、バックエンドサーバ５１２は、顧客５０６を認証する。幾つかの例において、バックエンドサーバ５１２は、認証情報または他の認証トークンを受け取るためにセキュリティトークン５１６と通信することができる。例えば、セキュリティトークン５１６は、顧客５０６からの入力を受け取るための指紋スキャナ、及びセキュリティトークン５１６がセキュリティデバイス５０２の閾値距離内にあるか否かを（例えば、ＲＳＳＩ測定値などを用いて）判断するための無線トランシーバを有することができる。ブロック１１１２において、バックエンドサーバ５１２は、署名関数（ｆ_３）を用いて第２の署名を生成する。ブロック１１１４において、バックエンドサーバ５１２は、結合署名（例えば、複合署名関数（ｆ_６）を用いた複合署名、又は分割鍵結合関数（ｆ_１１）を用いた分割鍵署名など）を生成する。ブロック１１１６において、バックエンドサーバ５１２は、結合署名、及び顧客５０６と関連付けられた最終決定鍵４０４に基づいて、最終決定関数（ｆ_３０）を用いて、最終決定署名を生成する。ブロック１１１８において、バックエンドサーバ５１２は、最終決定署名をフロントエンドサーバ５１０に送る。方法はブロック１０１２（図１０）に進む。

【0067】

図１１Ｂは、図５、図６及び図７のシステムにより具現化され得る、顧客５０６の秘密鍵をバックエンドサーバ５１２が格納しない場合に、デジタルドキュメント用の署名を生成するための流れ図である。ブロック１１２０において、バックエンドサーバ５１２は、署名要求５０４をセキュリティデバイス５０２に送る。

【0068】

ブロック１１２２において、第１のセキュリティデバイス５０２は、顧客５０６を認証する。例えば、第１のセキュリティデバイス５０２は、指紋および／または一組の認証情報を受け取ることに応じて、顧客５０６を認証することができる。ブロック１１２４において、第１のセキュリティデバイス５０２は、署名関数（ｆ_３）を用いて、その格納された秘密鍵でもって第１の署名を生成する。ブロック１１２６において、第１のセキュリティデバイス５０２は、第１の署名をバックエンドサーバ５１２に送る。

【0069】

ブロック１１２８において、第２のセキュリティデバイス５０２は、顧客５０６を認証する。ブロック１１３０において、第２のセキュリティデバイス５０２は、署名関数（ｆ_３）を用いて、その格納された秘密鍵でもって第２の署名を生成する。ブロック１１３２において、第２のセキュリティデバイス５０２は、第２の署名をバックエンドサーバ５１２に送る。

【0070】

ブロック１１３４において、バックエンドサーバ５１２は、結合署名（例えば、複合署名関数（ｆ_６）を用いた複合署名、又は分割鍵結合関数（ｆ_１１）を用いた分割鍵署名など）を生成する。ブロック１１１８において、バックエンドサーバ５１２は、結合署名、及び顧客５０６と関連付けられた最終決定鍵４０４に基づいて、最終決定関数（ｆ_３０）を用いて、最終決定署名を生成する。ブロック１１３６において、バックエンドサーバ５１２は、最終決定署名をフロントエンドサーバ５１０に送る。方法は、ブロック１０１２（図１０）に進む。

【0071】

本明細書において、離接語の使用は、接続語を含むことが意図されている。定冠詞または不定冠詞の使用は、個数を示すことが意図されていない。特に、「the」物体または「a」物体および「an」物体に対する言及は、考えられる複数の係る物体の１つも意味することが意図されている。更に、接続詞「又は」は、相互に排他的な二者択一の代わりに同時に存在している特徴要素を伝えるために使用され得る。言い換えれば、接続詞「又は」は、「及び／又は」を含むと理解されるべきである。本明細書で使用される限り、用語「モジュール」及び「ユニット」は、多くの場合、センサと連係して、通信能力、制御能力および／または監視能力を提供するための回路を備えるハードウェアを意味する。「モジュール」及び「ユニット」は、回路上で実行するファームウェアも含むことができる。用語「遠隔（リモート）」は、地理的に離れており且つイントラネット又はインターネットのような、内部ネットワーク又は外部ネットワークを介して通信可能に結合されていることを意味する。用語「含む」及び「含んでいる」は、包括的であり、「備える」、及び「備えている」とそれぞれ同じ範囲を有する。

【0072】

上述された実施形態、及び特に任意の「好適な」実施形態は、具現化形態の考えられる例であり、本発明の原理を明確に理解するために単に記載されている。本明細書で説明された技術の思想および原理から実質的に逸脱せずに、多くの変形および変更が、上述された実施形態（単数または複数）になされ得る。全ての変更は、本開示の範囲内に本明細書に含まれることが意図されており、以下の特許請求の範囲により保護される。

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】

【図9】

【図10】

【図11A】

【図11B】

【国際調査報告】