特表 2023-519082 信頼できるサーバを用いるデジタル署名システム

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

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

(11)【公表番号】

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

(54)【発明の名称】信頼できるサーバを用いるデジタル署名システム

(51)【国際特許分類】

   H04L 9/32 20060101AFI20230428BHJP

   H04L 9/14 20060101ALI20230428BHJP

【ＦＩ】

H04L9/32 200B

H04L9/14

【審査請求】有

【予備審査請求】未請求

(21)【出願番号】P 2022543431

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

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

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

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

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

前記第１のバックエンドサーバが利用可能でないという判断は、前記署名要求を転送することに応じて、前記フロントエンドサーバが前記第１のバックエンドサーバから肯定応答を受け取ることができない際に判断することを含む、請求項１２に記載の方法。

【請求項16】

前記フロントエンドサーバは、前記フロントエンドサーバが時間の閾値期間内に前記第２の署名を受け取ることができない際に、前記第１のバックエンドサーバが利用可能でないと判断する、請求項１２に記載の方法。

【発明の詳細な説明】

【技術分野】

【0001】

本開示は概して、安全（セキュア）な電子通信および電子商取引に関し、より具体的には、信頼できるサーバを用いるデジタル署名システムに関する。

【背景技術】

【0002】

ますます、ドキュメント（文書、書類）はデジタル的に署名されている。デジタル署名は、（ａ）ドキュメントに署名する人が、署名する際に申告した本人であることを認証し、（ｂ）署名されたドキュメントが認証されていることを法的に有効にするシステムを利用する。このように、当該ドキュメントを信頼する人は、ドキュメントが認証されたものであり且つ当該ドキュメントに署名した人がそれを署名したことを否認することができないことを確信することができる。これらデジタル署名システムは、秘密鍵および個人と関連付けられた公開鍵に依存する非対称暗号を使用することが多い。署名を偽造するために、悪意のある当事者は、秘密鍵を取得する又は（可能なら）署名方式を破壊する（即ち、秘密鍵を持たずにメッセージに署名する）計算コストをかける必要がある。デジタル署名システムの耐攻撃性（攻撃耐性）は、数学的耐性（例えば、署名を数学的に破壊することによりデジタル署名を偽造する能力）、又は物理的耐性（例えば、署名を偽造するために物理的デバイスを改ざんするなど）に分類され得る。デジタル署名の成長は、追跡される必要がある公開鍵および処理される必要がある署名要求の成長に付随して起こる。数学的耐性および物理的耐性が向上するにつれて、信頼性があり且つ拡張可能なデジタル署名インフラストラクチャーの必要性が増加している。

【0003】

概要
添付の特許請求の範囲は、本出願を定義する。本開示は、実施形態の態様を要約し、特許請求の範囲を制限するために使用されるべきではない。以下の図面および詳細な説明を検討する際に当業者には明らかになるように、本明細書で説明される技術に従って、他の具現化形態が企図され、これら具現化形態は、本出願の範囲内にあることが意図される。

【0004】

デジタル署名を生成するための例示的なシステムは、第１のバックエンドサーバ、第２のバックエンドサーバ、及びフロントエンドサーバを含む。フロントエンドサーバは、遠隔のアプリケーションサーバから署名要求を受け取る。その署名要求は暗号学的に埋め込まれた第１のサーバ識別子を備える第１の総合的公開鍵、及び暗号学的に埋め込まれた第２のサーバ識別子を備える第２の総合的公開鍵を含む。フロントエンドサーバは、第１の総合的公開鍵から暗号学的に埋め込まれた第１のサーバ識別子を抽出する。次いで、フロントエンドサーバは、第１のサーバ識別子に対応する第１のバックエンドサーバに署名要求を転送する。第１のバックエンドサーバが利用可能でないという判断に応答して、フロントエンドサーバは、第２の総合的公開鍵から暗号学的に埋め込まれた第２のサーバ識別子を抽出し、第２のサーバ識別子に対応する第２のバックエンドサーバに署名要求を転送する。バックエンドサーバに応答することは、総合的公開鍵と関連付けられた複数の遠隔のセキュリティデバイスに署名要求を転送する。次いで、バックエンドサーバは、前記複数の遠隔のセキュリティデバイスのそれぞれから第１の署名を受け取り、第１の署名に基づいて、結合署名を生成する。次いで、バックエンドサーバは、結合署名および最終決定鍵に基づいて第２の署名を生成する。最終決定鍵は、バックエンドサーバのサーバ識別子に基づいて暗号学的に生成される。バックエンドサーバは、第２の署名をフロントエンドサーバに転送する。次いで、フロントエンドサーバは、第２の署名を遠隔のアプリケーションサーバに転送する。

【0005】

本発明のより良い理解のために、以下の図面に示された実施形態を参照することができる。図面の構成要素は、必ずしも一律の縮尺に従っておらず、関連した要素が省略される場合があり、又は場合によっては、本明細書で説明される新規な特徴要素を強調する及び明確に示すように、一部は誇張され得る。更に、システムの構成要素は、当該技術で知られるように、様々に構成され得る。更に、図面において、同様の参照符号は、幾つかの図面の全体にわたって、対応する部品を示す。

【図面の簡単な説明】

【0006】

【図1】本開示の技術による、信頼できるサーバを用いるデジタル署名システムを具現化するためのシステムを示す。

【0007】

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

【0008】

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

【0009】

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

【0010】

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

【0011】

【図6A】署名オーソリティと協働して、ユーザと関連付けられることになる証明書を生成する証明書オーソリティのブロック図である。

【図6B】署名オーソリティと協働して、ユーザと関連付けられることになる証明書を生成する証明書オーソリティのブロック図である。

【0012】

【図7】ユーザと関連付けられた複数の証明書を生成するためのシステムのブロック図である。

【0013】

【図8】デジタル署名により署名されたドキュメントを生成するためにユーザと関連付けられた冗長な証明書を使用するシステムのブロック図である。

【0014】

【図9】図７と図８の非対称暗号のデバイス側部分を具現化するセキュリティデバイスを示す。

【0015】

【図10】図９のセキュリティデバイスの電子的構成要素のブロック図である。

【0016】

【図11】図１と図８のアプリケーションサーバにより具現化され得る、デジタル署名により署名されたドキュメントを生成するためにユーザと関連付けられた冗長な証明書を使用するための方法の流れ図である。

【0017】

【図12】図８のフロントエンドサーバ（単数または複数）により具現化され得る、デジタル署名により署名されたドキュメントを生成するためにユーザと関連付けられた冗長な証明書を使用するための方法の流れ図である。

【0018】

【図13】図１と図８のシステムにより具現化され得るデジタルドキュメントの署名を生成するための方法の流れ図である。

【図14】図１と図８のシステムにより具現化され得るデジタルドキュメントの署名を生成するための方法の流れ図である。

【0019】

【図15】証明書を再発行するための方法の流れ図である。

【0020】

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

【0021】

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

【0022】

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

【0023】

複合鍵方式が使用される場合、（ａ）セキュリティデバイスが秘密鍵および公開鍵を生成して、指定されたバックエンドサーバに公開鍵を供給し、及び／又は（ｂ）セキュリティトークンが使用される場合、割り当てられたバックエンドサーバが秘密鍵および顧客と関連付けられた公開鍵を生成する。２つ以上の独立した公開鍵を用いて、バックエンドサーバはそれぞれ、複合公開鍵を作成する。次いで、バックエンドサーバはそれぞれ、複合公開鍵およびＢＥＳＩＤに基づいて、総合的公開鍵を作成する。バックエンドサーバはそれぞれ、別個に総合的公開鍵、そのＢＥＳＩＤ及び一意のクライアント識別子（「ＣＩＤ」）を、証明書オーソリティ（ＣＡ）に送信する。証明書オーソリティは、ＣＩＤと関連した別個の証明書を生成する。幾つかの例において、証明書オーソリティ（ＣＡ）は、証明書の１つを「一次証明書」として指定し、他の証明書を「二次証明書」として指定する。証明書オーソリティ（ＣＡ）は、ＣＩＤが添付してある要求を受け取ることに応じて証明書を供給する、これら証明書の公開リポジトリである。

【0024】

分割鍵方式が使用される場合、各バックエンドサーバは、２つ以上の鍵シェア及び公開鍵を生成する。各バックエンドサーバは、鍵シェアの１つをセキュリティデバイスと共有（共用）し、鍵シェアの１つを保持する。セキュリティデバイスは、鍵シェアを生成したバックエンドサーバのＢＥＳＩＤと関連した鍵シェアのそれぞれを格納する。次いで、バックエンドサーバはそれぞれ、公開鍵およびそれらのＢＥＳＩＤに基づいて総合的公開鍵を作成する。バックエンドサーバはそれぞれ、総合的公開鍵、そのＢＥＳＩＤ及び一意のクライアント識別子（「ＣＩＤ」）を証明書オーソリティ（ＣＡ）に別個に送信する。

【0025】

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

【0026】

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

【0027】

デジタル署名が作成されるべきである場合、顧客は、信用証明物および／または顧客のＣＩＤをアプリケーションサーバ（例えば、顧客を確認するためにアプリケーションサーバにより管理された信用証明物）に提供する。アプリケーションサーバは、証明書オーソリティ（ＣＡ）から複数の証明書を検索して取り出すために、顧客の身元を使用する。アプリケーションサーバは、署名オーソリティの少なくとも２つのフロントエンドサーバと確立された関係（例えば、アプリケーションサーバが署名オーソリティに登録する際に確立されたなど）を有する。幾つかの例において、フロントエンドサーバの一方は、「一次サーバ」として指定されることができ、フロントエンドサーバの他方は、「二次サーバ」として指定され得る。２つより多いフロントエンドサーバがアプリケーションサーバと関連付けられる場合、署名オーソリティ（ＳＡ）は、バックエンドサーバの順序または優先順位を指定することができる。アプリケーションサーバは、一次（又は第１の）フロントエンドサーバに署名要求を送信する。署名要求は、証明書オーソリティ（ＣＡ）から検索して取り出された複数の証明書およびメッセージを含む。当該メッセージは、原初のメッセージ（例えば、署名されるべきデジタルドキュメント）、又は当該原初のメッセージに暗号学的ハッシュ関数（例えば、SHA-256など）を適用することにより当該原初のメッセージから算出されたメッセージダイジェストであることができる。アプリケーションサーバが時間の閾値期間（例えば、５００ミリ秒、１秒など）内に一次フロントエンドサーバからその要求の肯定応答を受け取らない場合、アプリケーションサーバは、署名要求を二次フロントエンドサーバに再送する。２つより多い指定されたフロントエンドサーバが存在する場合、このプロセスは、アプリケーションサーバがその要求の肯定応答を受け取るまで繰り返される。肯定応答が受け取られない場合、アプリケーションサーバは、ユーザにエラーメッセージを生成する。

【0028】

フロントエンドサーバは、一次（又は第１の）証明書からＢＥＳＩＤを抽出して（取り出して）、当該ＢＥＳＩＤと関連したバックエンドサーバに署名要求を転送する。フロントエンドサーバが時間の閾値期間（例えば、５００ミリ秒、１秒など）内に一次バックエンドサーバからその要求の肯定応答を受け取らない場合、フロントエンドサーバは二次証明書からＢＥＳＩＤを取り出して、そのバックエンドサーバに署名要求を転送する。署名要求を添付する２つより多い証明書が存在する場合、このプロセスは、フロントエンドサーバがその要求の肯定応答を受け取るまで、繰り返される。肯定応答が受け取られない場合、フロントエンドサーバは、エラーメッセージを生成して、署名要求を送信したアプリケーションサーバにそれを送る。

【0029】

バックエンドサーバは、セキュリティデバイス及び／又はセキュリティトークンと連係して、メッセージで署名を生成する。次いで、バックエンドサーバは、最終決定署名を生成するために最終決定鍵を使用する。バックエンドサーバは、署名要求を送信したフロントエンドサーバに最終決定署名を送る。次いで、フロントエンドサーバは、署名を要求したアプリケーションサーバに、最終決定署名を転送する。次いで、アプリケーションサーバは、最終決定署名をデジタルドキュメントに付加する。その後、必要な場合に、デジタル署名は、証明書を用いて検証され得る。

【0030】

図１は、本開示の教示による、信頼できるサーバを用いてデジタル署名システムを具現化するためのシステム１００を示す。システム１００は、安全かつ信頼できるデジタル署名を生成する。図示された例において、システム１００は、署名オーソリティ１０２、証明書オーソリティ１０４、及び１つ又は複数のアプリケーションサーバ１０６を含む。

【0031】

署名オーソリティ１０２は、アプリケーションサーバ１０６とアプリケーションサーバ１０６のユーザ１１０により処理される１つ又は複数のセキュリティデバイス１０８との間の仲介装置としての役割を果たす。セキュリティデバイス１０８が署名オーソリティ１０２に登録される場合、署名オーソリティ１０２は、セキュリティデバイス（単数または複数）１０８と関連した複数の証明書を生成するために、証明書オーソリティ１０４に関する情報を収集および／または生成する。署名オーソリティ１０２は、セキュリティデバイス（単数または複数）１０８と連係して、アプリケーションサーバ１０６の１つにより送信される証明書を含む署名要求に応答して、デジタル署名を生成する。

【0032】

証明書オーソリティ１０４は、証明書を生成および格納する。証明書オーソリティ１０４は、署名オーソリティ１０２からの入力に基づいて、証明書を生成する。当該入力は、公開鍵およびクライアント識別子（ＣＩＤ）を含む。証明書オーソリティ１０４は、生成された証明書をデータベース（場合によっては、「証明書リポジトリ」又は「公開鍵リポジトリ」と呼ばれる）に格納する。証明書オーソリティ１０４は、証明書と関連したＣＩＤを受け取ることに応じて、格納された証明書をアプリケーションサーバ１０６に供給する（例えば、証明書は、ＣＩＤを用いてそれらを要求するエンティティが自由に利用できる）。

【0033】

顧客１１０は、アプリケーションサーバ１０６が署名要求を生成するように、アプリケーションサーバ１０６と対話することができる。例えば、顧客１１０は、ドキュメントに署名している、又はウェブサイト上でプライバシーポリシー及びデータ使用ポリシーを受諾している場合がある。アプリケーションサーバ１０６が、デジタル署名を要求する場合、アプリケーションサーバ１０６は、直接的または間接的に顧客１１０により供給されるＣＩＤに関連した証明書を証明書オーソリティ１０４から取得する。署名オーソリティ１０４は、アプリケーションサーバ１０６が顧客１１０のセキュリティデバイス（単数または複数）１０８との直接的関係を必要としないように、署名プロセスを管理する。アプリケーションサーバ１０６は、予め確立された関係を介して、署名オーソリティ１０２に通信可能に結合される。例えば、アプリケーションサーバ１０６の所有者が署名オーソリティ１０２からのデジタル署名を受け入れることを望む場合、署名オーソリティ１０２は、如何にして署名要求を送るべきかに関する設定を提供することができる。

【0034】

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

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

【数1】

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

【0035】

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

【0036】

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

【0037】

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

【0038】

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

【数2】

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

【数3】

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

【0039】

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

【0040】

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

【0041】

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

【0042】

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

【0043】

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

【0044】

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

【0045】

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

【数4】

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

【数5】

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

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

【0046】

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

【0047】

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

【数6】

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

【0048】

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

【数7】

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

【数8】

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

【0049】

図６Ａ及び図６Ｂは、署名オーソリティ１０２と協働して、ユーザと関連付けられるべき証明書６０２を生成する、証明書オーソリティ１０４のブロック図である。図６Ａは、証明書オーソリティ１０４が署名オーソリティ１０２の内部情報（ＢＥＳＩＤ５０６などのような）にアクセスできる際の例を示す。例えば、証明書オーソリティ１０４は、署名オーソリティ１０２（例えば、同じエンティティにより動作されるなど）に密接に関連付けられ得る、又は署名オーソリティ１０２へ組み込まれ得る。図６Ｂは、証明書オーソリティ１０４が署名オーソリティ１０２の内部情報にアクセスできない際の例を示す。例えば、証明書オーソリティ１０４は、署名オーソリティ１０２として別個のエンティティにより動作され得る。図６Ａ及び図６Ｂの図示された例において、証明書オーソリティ１０４は、証明書オーソリティ（ＣＡ）秘密鍵６０４及び証明書生成器６０６を含む。ＣＡ秘密鍵６０４は、任意の適切な手段（例えば、上述されたような秘密鍵生成関数（ｆ_１））によって、証明書オーソリティ１０４により生成され得る。証明書生成器６０６は、署名オーソリティ１０２から入力を受け取って、証明書６０２を生成する。

【0050】

図６Ａにおいて、証明書生成器６０６は、公開鍵（例えば、上記の図４の複合公開鍵４２２）、ＢＥＳＩＤ５０６及びクライアント識別子（ＣＩＤ）６１０を用いて、証明ステートメント６０８を生成する組合わせ関数（ｆ_５０）を含む。公開鍵、ＢＥＳＩＤ５０６及びＣＩＤ６１０は、署名オーソリティ１０２から受け取られる。組合わせ関数（ｆ_５０）は、公開鍵、ＢＥＳＩＤ５０６及びＣＩＤ６１０のリスト又は連鎖（コンカチネーション）である証明ステートメント６０８を生成する。

【0051】

図６Ｂにおいて、証明書生成器６０６は、総合的公開鍵（例えば、上記の図５の総合的公開鍵５０２）及びＣＩＤ６１０を用いて、証明ステートメント６０８を生成する組合わせ関数（ｆ_７０）を含む。総合的公開鍵およびＣＩＤ６１０は、署名オーソリティ１０２から受け取られる。組合わせ関数（ｆ_７０）は、総合的公開鍵、及びＣＩＤ６１０のリスト又は連鎖（コンカチネーション）である証明ステートメント６０８を生成する。

【0052】

証明書生成器６０６は、ＣＡ秘密鍵６０４を用いて、証明ステートメント６０８に署名関数（ｆ_３）を適用することにより、証明書６０２を生成する。次いで、証明書生成器６０６は、ＣＩＤ６１０と関連付けられた証明書６０２をデータベースに格納する。

【0053】

証明書６０２が署名要求に含まれる場合（例えば、以下の図８の署名要求８０４）、署名オーソリティ１０２は、身元抽出関数（ｆ_６０）を用いて、ＢＥＳＩＤ５０６を証明書６０２から抽出する。身元抽出関数（ｆ_６０）は、ＣＡ秘密鍵６０４に対応する証明書オーソリティ１０４の公開鍵を用いて証明書を解読することにより、証明書６０２からＢＥＳＩＤ５０６を抽出し、ＢＥＳＩＤ５０６を証明ステートメント６０８から抽出する。

【0054】

図７は、顧客１１０と関連付けられた複数の証明書６０２を生成するためのシステムのブロック図である。セキュリティデバイス１０８が最初に活性化される際、それは秘密鍵（例えば、上記の図２の秘密鍵２０２）及び公開鍵２０４を生成する。セキュリティデバイス１０８は、公開鍵２０４を署名オーソリティ１０２に送り、署名オーソリティ１０２は公開鍵２０４を少なくとも２つのバックエンドサーバ７０２に経路指定する。これらバックエンドサーバ７０２は、セキュリティデバイス１０８と通信するために必要な情報（例えば、ＩＰアドレス、認証情報（信用証明物）など）を有するサーバになる。また、バックエンドサーバ７０２は、セキュリティデバイス１０８と関連付けられたＣＩＤ６１０（例えば、活性化プロセスを介して取得されるなど）も受け取る、又は別の方法で検索して取り出す。

【0055】

図示された例において、バックエンドサーバ７０２ａ及び７０２ｂは独立して、公開鍵を生成し、その生成された公開鍵を、複合公開鍵関数（ｆ_５）を用いて、セキュリティデバイス１０８から受け取った公開鍵と組合わせる。代案として、顧客１１０は、２つ以上のセキュリティデバイス１０８を登録し、バックエンドサーバ７０２は、複合公開鍵関数（ｆ_５）を用いて、受け取った公開鍵を組合わせる。図示された例において、一次バックエンドサーバ７０２ａは、一次複合公開鍵４２２ａを生成する。一次バックエンドサーバ７０２ａは、複合公開鍵４２２ａ、そのＢＥＳＩＤ５０６ａ及びＣＩＤ６１０をフロントエンドサーバ７０４に転送する。フロントエンドサーバ７０４は、複合公開鍵４２２ａ、ＣＩＤ６１０及びＢＥＳＩＤ５０６ａを証明書オーソリティ１０４に送る。証明書オーソリティ１０４は、証明書生成器６０６を用いて、一次証明書７０６ａを、複合公開鍵４２２ａ、ＣＩＤ６１０及びＢＥＳＩＤ５０６ａを用いて生成する。

【0056】

二次バックエンドサーバ７０２ｂは、二次複合公開鍵４２２ｂを生成する。二次バックエンドサーバ７０２ｂにより生成された公開鍵が一次バックエンドサーバ７０２ａにより生成された公開鍵と異なるので、二次複合公開鍵４２２ｂは、一次複合公開鍵４２２ａと異なる。二次バックエンドサーバ７０２ｂは、複合公開鍵４２２ｂ、そのＢＥＳＩＤ５０６ｂ及びＣＩＤ６１０をフロントエンドサーバ７０４に転送する。フロントエンドサーバ７０４は、複合公開鍵４２２ｂ、ＣＩＤ６１０及びＢＥＳＩＤ５０６ｂを証明書オーソリティ１０４に送る。証明書オーソリティ１０４は、証明書生成器６０６を用いて、二次証明書７０６ｂを、複合公開鍵４２２ｂ、ＣＩＤ６１０及びＢＥＳＩＤ５０６ｂを用いて生成する。

【0057】

図８は、ドキュメントを署名するためにデジタル署名（例えば、最終決定署名５０８）を生成するように顧客１１０と関連付けられた冗長な証明書（例えば、一次証明書７０６ａ及び二次証明書７０６ｂ）を使用するシステムのブロック図である。図示された例において、顧客１１０は、アプリケーションサーバ１０６が署名されたドキュメントを生成する必要があるように、アプリケーションサーバ１０６と対話する。アプリケーションサーバ１０６は、ＣＩＤ６１０を受け取る及び／又は別な方法で検索して取り出す（例えば、顧客１１０を介して）。ＣＩＤ６１０を用いて、アプリケーションサーバは、ＣＩＤ６１０と関連付けられた証明書を要求する（例えば、一次証明書７０６ａ及び二次証明書７０６ｂなど）。アプリケーションサーバ１０６は、（i）証明書７０６ａ及び７０６ｂ、及び（ii）メッセージ４１４を含む署名要求８０４を生成する。メッセージは、原初のメッセージ（例えば、署名されるべきデジタルドキュメント）又は原初のメッセージに暗号学的ハッシュ関数（例えば、SHA-256など）を適用することにより、原初のメッセージから計算されたメッセージダイジェストであることができる。

【0058】

アプリケーションサーバ１０６は、署名オーソリティ１０２（例えば、アプリケーションサーバ１０６が署名オーソリティ１０２に登録する際に確立されたなど）の少なくとも２つのフロントエンドサーバ（例えば、一次フロントエンドサーバ７０４ａ及び二次フロントエンドサーバ７０４ｂ）との確立された関係を有する。複数のフロントエンドサーバとの関係は、フロントエンドサーバの１つが利用できない際のための冗長性を提供する。署名オーソリティ１０２は、トラフィック管理原理に基づいて、どの特定のフロントエンドサーバがアプリケーションサーバ１０６に割り当てられるかを選択することができる。例えば、同じ一次フロントエンドサーバ７０４ａに割り当てられたアプリケーションサーバ１０６は、一次フロントエンドサーバ７０４ａの利用できないことが二次フロントエンドサーバ７０４ｂのどれにもストレスを加えないように、異なる二次フロントエンドサーバ７０４ｂに割り当てられ得る。１つのアプリケーションサーバ１０６の一次フロントエンドサーバ７０４ａとしての役割を果たすフロントエンドサーバは、別のアプリケーションサーバ１０６の二次フロントエンドサーバ７０４ｂであることができる。

【0059】

アプリケーションサーバ１０６は、署名要求８０４を一次フロントエンドサーバ７０４ａに送る。アプリケーションサーバ１０６が署名要求８０４の肯定応答を獲得しない及び／又は一次フロントエンドサーバ７０４ａが利用できないという任意の他のしるしを受け取る場合、アプリケーションサーバ１０６は、署名要求８０４を二次フロントエンドサーバ７０４ｂに送る。アプリケーションサーバ１０６が２つより多いフロントエンドサーバと関連付けられる例において、これは、関連付けられているフロントエンドサーバの全てを、アプリケーションサーバ１０６が試みるまで、続けることができる。フロントエンドサーバが利用可能でない場合、アプリケーションサーバ１０６はエラーを生成する。

【0060】

署名要求８０４を受け取るフロントエンドサーバ（例えば、一次フロントエンドサーバ７０４ａ又は二次フロントエンドサーバ７０４ｂ）は、身元抽出関数（ｆ_６０）を用いて、一次証明書７０６ａから一次バックエンドサーバ７０２ａのＢＥＳＩＤ５０６ａを抽出する。次いで、フロントエンドサーバは、署名要求８０４を一次バックエンドサーバ７０２ａに転送する。フロントエンドサーバが署名要求８０４の肯定応答を獲得しない及び／又は一次バックエンドサーバ７０２ａが利用できないという任意の他のしるしを受け取る場合、フロントエンドサーバは（i）身元抽出関数（ｆ_６０）を用いて、二次証明書７０６ｂから二次バックエンドサーバ７０２ｂのＢＥＳＩＤ５０６ｂを抽出し、（ii）署名要求８０４を二次バックエンドサーバ７０２ｂに送る。署名要求８０４が２つより多い証明書を含む例において、これは、フロントエンドサーバが証明書の全てを用いて署名要求８０４を転送することを試みるまで、続けることができる。バックエンドサーバが利用可能でない場合、フロントエンドサーバはエラーメッセージをアプリケーションサーバ１０６に送る。

【0061】

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

【0062】

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

【0063】

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

【0064】

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

【0065】

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

【0066】

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

【0067】

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

【0068】

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

【0069】

図１１は、図１及び図８のアプリケーションサーバ１０６により具現化され得る、デジタル署名により署名されるドキュメントを生成するために顧客１１０と関連付けられた冗長な証明書６０２を使用するための方法の流れ図である。最初に、ブロック１１０２において、アプリケーションサーバ１０６は、署名するためのデジタルドキュメントという結果になる入力を顧客１１０から受け取る。例えば、顧客１１０は、アプリケーションサーバ１０６と関連付けられたウェブサイトのプライバシーポリシーの承諾を示すために承諾ボタンをクリックすることができる。ブロック１１０４において、アプリケーションサーバ１０６は、顧客１１０と関連付けられた２つ以上の証明書６０２を証明書オーソリティ１０４から検索して取り出す。ブロック１１０６において、アプリケーションサーバ１０６は、署名要求８０４を一次フロントエンドサーバ７０４ａに送る。アプリケーションサーバ１０６は、少なくとも２つのフロントエンドサーバに通信可能に結合するように構成される。幾つかの例において、フロントエンドサーバの順序（例えば、どのフロントエンドサーバが一次フロントエンドサーバ７０４ａになり、どのフロントエンドサーバが二次フロントエンドサーバ７０４ｂになるかなど）は、アプリケーションサーバ１０６が署名オーソリティ１０２に登録する際に、署名オーソリティ１０２により指定される。代案として、幾つかの例において、アプリケーションサーバ１０６は、署名要求８０４を最初に送るためのフロントエンドサーバの１つを選択する。

【0070】

ブロック１１０８において、アプリケーションサーバ１０６は、フロントエンドサーバが利用可能でないしるしを受け取ったか否かを判断する。例えば、アプリケーションサーバ１０６は、（ａ）フロントエンドサーバから署名を受け取るために時間の閾値期間だけ待つ、（ｂ）フロントエンドサーバが利用可能でないというメッセージを受け取る、及び／又は（ｃ）署名要求８０４に応答してフロントエンドサーバからの肯定応答を受信できない場合がある。フロントエンドサーバが利用可能である場合、方法はブロック１１１０で継続する。それ以外では、フロントエンドサーバが利用可能でない場合、方法はブロック１１１４で継続する。

【0071】

ブロック１１１０において、アプリケーションサーバ１０６は、フロントエンドサーバから最終決定署名５０８を受け取る。ブロック１１１２において、アプリケーションサーバ１０６は、最終決定署名をデジタルドキュメントに添付する。

【0072】

ブロック１１１４において、アプリケーションサーバ１０６は、署名要求を送信するための別のフロントエンドサーバが存在するか否かを判断する。別のフロントエンドサーバが存在する場合、方法はブロック１１１６に進む。それ以外では、別のフロントエンドサーバが存在しない場合、方法はブロック１１１８に進む。

【0073】

ブロック１１１６において、アプリケーションサーバ１０６は、署名要求８０４を次のフロントエンドサーバ（例えば、二次フロントエンドサーバ７０４ｂなど）に送る。次いで、方法は、ブロック１１０８に戻る。

【0074】

ブロック１１１８において、アプリケーションサーバ１０６は、エラーメッセージを生成する。

【0075】

図１２は、図１及び図８のフロントエンドサーバ（単数または複数）７０４により具現化され得る、デジタル署名により署名されるドキュメントを生成するために顧客１１０と関連付けられた冗長な証明書を使用するための方法の流れ図である。最初に、ブロック１２０２において、フロントエンドサーバ７０４は、複数の証明書（例えば、一次証明書７０６ａ及び二次証明書７０６ｂなど）を含む署名要求８０４を、アプリケーションサーバ１０６から受け取る。ブロック１２０４において、フロントエンドサーバ７０４は、身元抽出関数（ｆ_６０）を用いて一次証明書７０６ａからＢＥＳＩＤ５０６を抽出する。ブロック１２０６において、フロントエンドサーバ７０４は、ブロック１２０４で抽出されたＢＥＳＩＤ５０６に対応するバックエンドサーバに署名要求８０４を送る。

【0076】

ブロック１２０８において、フロントエンドサーバ７０４は、バックエンドサーバ７０２が利用可能でないというしるしを受け取ったか否かを判断する。例えば、フロントエンドサーバは、（ａ）バックエンドサーバ７０２から署名を受け取るために時間の閾値期間だけ待つ、（ｂ）バックエンドサーバ７０２が利用可能でないというメッセージを受け取る、及び／又は（ｃ）署名要求８０４に応答してバックエンドサーバ７０２からの肯定応答を受信できない場合がある。バックエンドサーバ７０２が利用可能である場合、方法はブロック１２１０で継続する。それ以外では、バックエンドサーバ７０２が利用可能でない場合、方法はブロック１２１４で継続する。

【0077】

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

【0078】

ブロック１２１４において、フロントエンドサーバ７０４は、別の証明書（例えば、二次証明書７０６ｂ）が存在するか否かを判断する。別の証明書が存在する場合、方法はブロック１２１６に進む。それ以外では、別の証明書が存在しない場合、方法はブロック１２２０に進む。ブロック１２１６において、フロントエンドサーバ７０４は、身元抽出関数（ｆ_６０）を用いて、二次証明書７０６ｂからＢＥＳＩＤ５０６を抽出する。ブロック１２１８において、フロントエンドサーバ７０４は、ブロック１２１６で抽出されたＢＥＳＩＤ５０６に対応するバックエンドサーバ７０２に署名要求８０４を送る。次いで、方法はブロック１２０８に戻る。

【0079】

ブロック１２２０において、フロントエンドサーバ７０４はエラーメッセージをアプリケーションサーバ１０６に送る。

【0080】

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

【0081】

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

【0082】

図１４は、図１及び図８のシステムにより具現化され得るデジタルドキュメント用の署名を生成するための方法の流れ図である。図１４において、バックエンドサーバ７０２は、顧客１１０用の秘密鍵を格納しない。ブロック１４０２において、バックエンドサーバ７０２は、署名要求８０４に含まれる対応する証明書６０２と関連付けられたセキュリティデバイス１０８に署名要求８０４を送る。

【0083】

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

【0084】

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

【0085】

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

【0086】

図１５は、証明書６０２を再発行するための方法の流れ図である。証明書は、例えばバックエンドサーバ７０２の１つが機能しなくなる際に、再発行され得る。新たなバックエンドサーバが設置されることができ、新たな証明書が既存の証明書に基づいて発行され得る。後述されるように、このプロセスは、自動であり、幾つかの例において、証明書オーソリティ１０４に特定の要求を送る必要がない。２つの異なるバックエンドサーバ７０２が使用されており、それらの１つが機能していない場合、この自動的な証明書発行手順は、何らかのダウンタイムなしでシステムの回復を可能にする。最初に、証明書オーソリティ１０４は、ＢＥＳＩＤ５０６及び新たなバックエンドサーバ７０２の公開鍵を受け取る。

【0087】

ブロック１５０２において、証明書オーソリティ１０４は、一次および二次バックエンドサーバ７０２ａ及び７０２ｂと関連付けられた一次および二次証明書７０６ａ及び７０６ｂを検証する。ブロック１５０４において、証明書オーソリティ１０４は、ＣＩＤ６１０、一次証明書７０６ａの公開鍵、及び二次証明書７０６ｂの公開鍵を抽出する。ブロック１５０６において、証明書オーソリティ１０４は、一次証明書７０６ａの公開鍵、及び二次証明書７０６ｂの公開鍵を用いて、顧客のセキュリティデバイス１０８に対する公開鍵を計算する。ブロック１５０８において、証明書オーソリティ１０４は、顧客のセキュリティデバイス１０８に対する公開鍵、及び新たなバックエンドサーバ７０２の公開鍵を用いて（例えば、複合公開鍵関数（ｆ_５）などを用いて）新たな公開鍵を作成する。ブロック１５１０において、証明書オーソリティ１０４は、新たなバックエンドサーバ７０２のＢＥＳＩＤ５０６、新たな公開鍵、及び一次及び二次証明書７０６ａと７０６ｂに関連付けられたＣＩＤ６１０に基づいて、新たなバックエンドサーバ７０２用の新たな証明書６０２を作成する。ブロック１５０６において、証明書オーソリティ１０４は、機能していないバックエンドサーバ７０２と関連付けられた証明書を新たな証明書と置き換える。

【0088】

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

【0089】

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

【図1】

【図2】

【図3】

【図4】

【図5】

【図6A】

【図6B】

【図7】

【図8】

【図9】

【図10】

【図11】

【図12】

【図13】

【図14】

【図15】

【国際調査報告】