特許 6896940 第１のアプリケーションと第２のアプリケーションとの間の対称型相互認証方法

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

(12)【公報種別】特許公報(B2)

(11)【特許番号】6896940

(24)【登録日】2021年6月11日

(45)【発行日】2021年6月30日

(54)【発明の名称】第１のアプリケーションと第２のアプリケーションとの間の対称型相互認証方法

(51)【国際特許分類】

   H04L 9/08 20060101AFI20210621BHJP

【ＦＩ】

   H04L9/00 601C

   H04L9/00 601E

【請求項の数】10

【全頁数】21

(21)【出願番号】特願2020-519833(P2020-519833)

(86)(22)【出願日】2018年4月4日

(65)【公表番号】特表2020-526146(P2020-526146A)

(43)【公表日】2020年8月27日

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

(87)【国際公開番号】WO2018228732

(87)【国際公開日】20181220

【審査請求日】2019年12月18日

(31)【優先権主張番号】17305728.2

(32)【優先日】2017年6月14日

(33)【優先権主張国】EP

(73)【特許権者】

【識別番号】519283417

【氏名又は名称】タレス ディアイエス フランス エスアー

(73)【特許権者】

【識別番号】519445749

【氏名又は名称】タレス ディアイエス シーピーエル カナダ インク．

(74)【代理人】

【識別番号】100086368

【弁理士】

【氏名又は名称】萩原 誠

(72)【発明者】

【氏名】ルイス ミグエル， ヒューアパヤ

(72)【発明者】

【氏名】アンネ マリー， プラデン

【審査官】 寺谷 大亮

(56)【参考文献】

【文献】 特開２０００−３３２７４８（ＪＰ，Ａ）

【文献】 特開２０１１−２１７０３７（ＪＰ，Ａ）

【文献】 特開２００６−１０７４０６（ＪＰ，Ａ）

【文献】 米国特許出願公開第２００３／０１４５２０３（ＵＳ，Ａ１）

【文献】 米国特許出願公開第２０１０／０３０６５３１（ＵＳ，Ａ１）

(58)【調査した分野】（Int.Cl.，ＤＢ名）

Ｇ０９Ｃ １／００−５／００

Ｈ０４Ｌ ９／００−９／３８

(57)【特許請求の範囲】

【請求項1】

第１のアプリケーション（１０２）と第２のアプリケーション（１１０）との間の対称型相互認証方法（４０）であって、
− 分散トラストチェーン内に含まれる第１のエレメントである第１のサーバ（１０４）が、前記分散トラストチェーン内に含まれる第２のエレメントである少なくとも１つの第２のサーバ（１０８）に対して、少なくとも１つのマスタ対称鍵を送信するステップと、
− 前記第１のサーバが、前記少なくとも１つのマスタ対称鍵を前記第１のアプリケーションに送信するステップ（２８）と、
− 前記第２のサーバが、少なくとも１つの鍵生成パラメータと、前記少なくとも１つのマスタ対称鍵に含まれる第１のマスタ対称鍵とを使用することによって、第１の派生対称鍵を動的に生成するステップ（３８）と、
− 前記第２のサーバが、前記第１の派生対称鍵と、前記少なくとも１つの鍵生成パラメータとを前記第２のアプリケーションに送信するステップ（３１０）と、
− 前記第２のアプリケーションが、前記第１の派生対称鍵を使用することによって第１の鍵所有証明を生成するステップ（４２）と、
− 前記第２のアプリケーションが、前記第１の鍵所有証明と、前記少なくとも１つの鍵生成パラメータとを前記第１のアプリケーションに送信するステップ（４４）と、
− 前記第１のアプリケーションが、前記第１の派生対称鍵を使用することによって前記第１の鍵所有証明が生成されたものであることの検証に、前記少なくとも１つの鍵生成パラメータと、前記第１のマスタ対称鍵と、前記第１の鍵所有証明とを使用することによって成功するステップ（４１０）と、
− 前記第１のアプリケーションが、前記第１の派生対称鍵を使用することによって第２の鍵所有証明を生成するステップ（４１４）と、
− 前記第１のアプリケーションが、少なくとも前記第２の鍵所有証明を前記第２のアプリケーションに送信するステップ（４１６）と、
− 前記第２のアプリケーションが、動的に生成され証明された共有鍵である前記第１の派生対称鍵を使用することによって前記第２の鍵所有証明が生成されたものであることの検証に、前記第２の鍵所有証明を使用することによって成功するステップ（４１８）と、
を含む方法。

【請求項2】

前記少なくとも１つのマスタ対称鍵を前記第１のアプリケーションに送信するのに先立って、前記分散トラストチェーン内の第１の信頼の基点である前記第１のサーバが、前記第１のアプリケーションの証明の検証に成功する（２６）、及び／又は前記第１のアプリケーションの認証に成功し、結果として提供された前記少なくとも１つのマスタ対称鍵が前記第１のアプリケーションの真正性及び完全性の証明及び／又は認証された第１のアプリケーションの証明になり、及び／又は、前記第１の派生対称鍵を前記第２のアプリケーションに送信するのに先立って、前記分散トラストチェーン内の第２の信頼の基点である前記第２のサーバが、前記第２のアプリケーションの証明の検証に成功する（３４）、及び／又は前記第２のアプリケーションの認証に成功し、結果として提供された前記第１の派生対称鍵が、前記第２のアプリケーションの真正性及び完全性の証明及び／又は認証された第２のアプリケーションの証明になる、請求項１に記載の方法。

【請求項3】

前記第１のサーバが前記少なくとも１つのマスタ対称鍵を前記第１のアプリケーションに送信し、前記第１のサーバが、前記少なくとも１つのマスタ対称鍵のそれぞれに関連する一意の識別子に関するデータをさらに前記第１のアプリケーションに送信し、前記第２のアプリケーションが前記少なくとも１つの鍵生成パラメータを前記第２のサーバから受信し、前記第２のアプリケーションが、前記第１のマスタ対称鍵に関連する一意の識別子に関するデータをさらに受信し、さらに前記第１のアプリケーションに送信する、請求項１又は２に記載の方法。

【請求項4】

前記第１の派生対称鍵が所定の第１の寿命時間有効である、請求項１乃至３の何れかに記載の方法。

【請求項5】

前記第２のサーバが、前記少なくとも１つの鍵生成パラメータに含まれる少なくとも１つの鍵生成パラメータ及び／又は前記第１のマスタ対称鍵を変更することによって、前記第１の派生対称鍵と異なる第２の派生対称鍵を生成する、請求項１乃至４の何れかに記載の方法。

【請求項6】

前記第１の鍵所有証明が、暗号化された第１のノンス及び／又は暗号化された前記第１のノンスのハッシュ値を含む、請求項１乃至５の何れかに記載の方法。

【請求項7】

前記第２の鍵所有証明が、暗号化された第２のノンス及び／又は暗号化された前記第２のノンスのハッシュ値を含む、請求項１乃至６の何れかに記載の方法。

【請求項8】

前記第１のアプリケーション及び前記第２のアプリケーションが、前記第１の鍵所有証明及び／又は前記第２の鍵所有証明に基づいてセッション鍵を別々に生成する、請求項１乃至７の何れかに記載の方法。

【請求項9】

前記第１のアプリケーションが、
− 前記第１のマスタ対称鍵と異なる第２のマスタ対称鍵を使用することにより前もって暗号化されているセッション鍵と、
− 前記第２のマスタ対称鍵に関連する一意の識別子に関するデータと、
− 前記セッション鍵が有効である所定の寿命時間と、
からなる群のうちの少なくとも１つのエレメントを、セッション鍵情報として前記第２のアプリケーションに送信する、請求項１乃至８の何れかに記載の方法。

【請求項10】

前記方法がさらに、
− 前記第１のサーバ、前記第２のサーバ、又は前記分散トラストチェーン内に含まれる第３のエレメントであり、前記第１のサーバ及び前記第２のサーバと異なる第３のサーバが、前記少なくとも１つのマスタ対称鍵を、前記第１のアプリケーション及び前記第２のアプリケーションと異なる第３のアプリケーションに送信すること、及び
− 前記第１のアプリケーション又は前記第２のアプリケーションが、前記セッション鍵情報を前記第３のアプリケーションに送信して、前記セッション鍵を使用して前記第３のアプリケーションと安全に交換を行うこと、
を含む請求項９に記載の方法。

【発明の詳細な説明】

【技術分野】

【0001】

本発明は、概して第１のアプリケーションと第２のアプリケーションとの間の対称型相互認証方法に関する。

【0002】

本発明は特に、サーバが、例えばネットワーク仮想機能（すなわちＮＶＦ）を実行し得るＩｎｔｅｌ（登録商標）Ｓｏｆｔｗａｒｅ Ｇｕａｒｄ ｅＸｔｅｎｓiｏｎｓ（ソフトウェアガードエクステンション）（すなわちＳＧＸ）といったハードウェア介在エンクレーブ（すなわちＨＭＥ）などの、第１及び第２のアプリケーションの１つをサポートするクラウドコンピューティングネットワークに適用できる可能性がある。

【0003】

本明細書では、ＨＭＥが、エンクレーブ内のコードとデータの両方に、エンクレーブ内のデータにアクセスするコードだけがエンクレーブ内のセキュアコードとなるように機密性及び完全性を提供する、例えば中央処理装置（すなわちＣＰＵ）などのプロセッサにより実行されるセキュアコードを含む。このような保証は、特にホストオペレーティングシステム（すなわちＯＳ）に関係なくプロセッサ自体によって行われる。換言すれば、（管理者／ルート権限を含む）いかなる権限レベルで実行される（カーネルレベルコードを含む）いかなる他のコードもエンクレーブ内のセキュアコードにアクセスしない。

【0004】

本発明は特に、独立したエンティティである、又は例えばセキュアエレメント（すなわちＳＥ）などのデバイスと連携する、例えば携帯電話などの携帯端末が第１及び第２のアプリケーションの１つをサポートする携帯無線通信分野に適用できる可能性がある。

【0005】

本明細書では、ＳＥは、耐タンパ性コンポーネントとして格納データへのアクセスを保護するチップを含み、例えば（携帯）電話といったＳＥホストデバイスなどのデバイスとデータ通信を行うことが意図されたスマートオブジェクトである。

【0006】

本発明は特に、１つ以上の鍵を提供できるサーバである２つ以上のハードウェアセキュリティモジュール（すなわちＨＳＭ）タイプサーバに適用できる可能性がある。ＨＳＭタイプサーバは、好ましくは別々のＨＳＭタイプサーバが互いとの信頼を構築できるようにする、例えばブロックチェーンメカニズムなどの安全なデータ交換メカニズムによって互いに接続される。

【背景技術】

【0007】

２つのアプリケーション間を公開鍵基盤（すなわちＰＫＩ）技術を用いることによって相互認証することは知られている。

【0008】

しかしながら、そのようなＰＫＩ技術は、各アプリケーションをサポートするデバイスを、デバイスに鍵ペア、すなわち秘密鍵及び対応する公開鍵を提供すると同時に製造時に構成する必要があるため実装にかなりの費用がかかる。

【0009】

また、そのようなＰＫＩ技術は、デバイスの否認防止を検証するための認証局との通信を伴う重い処理を実行する必要があるため運用にかなりの時間がかかる。

【0010】

最後に、そのような非対称暗号に基づくＰＫＩ技術は量子計算に対して無抵抗であることが知られている。知られているように、非対称暗号とは、公開鍵が暗号化に使用され、公開鍵と異なる対応する秘密鍵が復号に使用されることを意味する。

【0011】

ＰＫＩ技術を用いた既知の解決策よりも安価で、速く、より安全な代替的解決策が必要である。

【発明の概要】

【発明が解決しようとする課題】

【0012】

本発明は、第１のアプリケーションと第２のアプリケーションとの間の対称型相互認証方法を提供することによって、上記で特定したばかりの必要性を満たすための解決策を提案する。

【課題を解決するための手段】

【0013】

本発明による方法は以下のステップを含む。分散トラストチェーン内に含まれる第１のエレメントである第１のサーバが、分散トラストチェーン内に含まれる第２のエレメントである少なくとも１つの第２のサーバに対して、少なくとも１つのマスタ対称鍵を送受信する。第１のサーバは、少なくとも１つのマスタ対称鍵を第１のアプリケーションに送信する。第２のサーバは、少なくとも１つの鍵生成パラメータと、少なくとも１つのマスタ対称鍵に含まれる第１のマスタ対称鍵とを使用することによって第１の派生対称鍵を動的に生成する。第２のサーバは、第１の派生対称鍵及び少なくとも１つの鍵生成パラメータを第２のアプリケーションに送信する。第２のアプリケーションは、第１の派生対称鍵を使用することによって第１の鍵所有証明を生成する。第２のアプリケーションは、第１の鍵所有証明及び少なくとも１つの鍵生成パラメータを第１のアプリケーションに送信する。第１のアプリケーションは、第１の鍵所有証明が第１の派生対称鍵を使用することによって生成されたものであることの検証に、少なくとも１つの鍵生成パラメータ、第１のマスタ対称鍵及び第１の鍵所有証明を使用することによって成功する。第１のアプリケーションは、第１の派生対称鍵を使用することによって第２の鍵所有証明を生成する。第１のアプリケーションは、少なくとも第２の鍵所有証明を第２のアプリケーションに送信する。第２のアプリケーションは、第２の鍵所有証明が動的に生成され証明された共有鍵である第１の派生対称鍵を使用することによって生成されたものであることの検証に、第２の鍵所有証明を使用することによって成功する。

【0014】

本発明の原理は、（分散）トラストチェーン内に含まれる、例えばＨＳＭタイプサーバなどの第１及び第２のサーバを使用することにある。第１のサーバは、サーバ間で交換される１つ（又は複数）のマスタ対称鍵を第１のアプリケーションに提供する。第２のサーバは、１つ又は複数のパラメータと、第１のサーバにより第１のアプリケーションに提供された第１のマスタ対称鍵とに基づいて、第２のサーバによりオンザフライで生成される第１の派生対称鍵を第２のアプリケーションに提供する。第２のアプリケーションは、第１の派生対称鍵を使用して第１の鍵所有証明を生成する。第２のアプリケーションは、第１の派生対称鍵を生成するのに使用されたパラメータが添付された第１の鍵所有証明を第１のアプリケーションに送信する。第１のアプリケーションは、第１のマスタ対称鍵と、第１の鍵所有証明と、第１の派生対称鍵を生成するのに使用されたパラメータとを使用しながら、第１の鍵所有証明が第１の派生対称鍵を使用して生成されたものであるか否かを確認する。第１の鍵所有証明が第１の派生対称鍵を使用して生成されたものであることを第１のアプリケーションが確認した場合にのみ、第１のアプリケーションは、第２のアプリケーションが動的に生成された第１の派生対称鍵を所有していることを知る。第１のアプリケーションは、第１の派生対称鍵を使用して第２の鍵所有証明を生成する。第１のアプリケーションは、第２のアプリケーションに少なくとも第２の鍵所有証明を送信する。第２のアプリケーションは、第１の派生対称鍵を使用しながら、第２の鍵所有証明が第１の派生対称鍵を使用して生成されたものであるか否かを確認する。第２の鍵所有証明が第１の派生対称鍵を使用して生成されたものであることを第２のアプリケーションが確認した場合にのみ、第２のアプリケーションは、第１及び第２のアプリケーションが共に動的に生成された第１の派生対称鍵を共有していることを知る。

【0015】

本発明の解決策は、動的に生成された対称鍵に基づいており、対称暗号を使用することによって第１及び第２のアプリケーション間の相互認証を実行する。知られているように、対称暗号とは、同じ鍵が暗号化と復号の両方に使用されることを意味する。

【0016】

したがって、本発明の解決策は、既知のＰＫＩ技術と異なり、第１及び第２のアプリケーションのそれぞれをサポートするデバイスを、デバイスに何らかの鍵を提供すると同時に製造時に構成する必要がない。

【0017】

本発明の解決策は、対称暗号に基づいており、例えば２つのアプリケーションがフィールドで使用される場合に、第１及び第２のアプリケーション間の相互認証を行うのに使用される対称鍵が動的に生成されるため、例えば０．数マイクロ秒未満と高速である。

【0018】

本発明の解決策は、第１及び第２のアプリケーションのそれぞれが、検証後に第１及び第２のアプリケーションの他方が動的に生成された対称鍵を所有していることを確認するため安全である。

【0019】

本発明の解決策は、特に量子計算に対してより抵抗力があると知られている対称暗号に基づいているため、ＰＫＩ技術を用いた既知の解決策の場合よりも安全である。

【0020】

したがって、本発明の解決策は、対称暗号を使用することによって、既知のＰＫＩに基づいた解決策に対してセキュリティを強化する。

【0021】

例えば動的に生成された対称鍵を生成するのに使用されたマスタ対称鍵などのデータを、分散トラストチェーンのエレメントである第１及び第２のサーバ間で安全に交換するのに使用されるメカニズムは、例えばブロックチェーン技術などの任意の安全なデータ交換技術に基づくことができることに留意されたい。

【図面の簡単な説明】

【0022】

本発明の追加の特徴及び利点は、示唆的で非制限的な例である本発明の１つの好適な実施形態の詳細な説明及び関連する以下の図面から明らかになるだろう。

【0023】

【図1】本発明に係る、第１及び第２のＨＳＭと、第１のアプリケーションをサポートするクラウドサーバと、第２のアプリケーションをサポートするクライアントデバイスとを備え、動的に生成された第１の派生対称鍵に基づく第１及び第２のアプリケーション間の対称型相互認証方法の特定の実施形態を実装するように適合されたシステムの実施形態の簡略図。

【図2】本発明に係る、トラストチェーン内の第１の信頼の基点である第１のＨＳＭが、第１のアプリケーションの認証に成功した、及び／又は第１のアプリケーションの証明の検証に成功した後に第１のアプリケーションに１つ又は複数のマスタ対称鍵を提供する、第１のアプリケーションと図１の第１のＨＳＭとの間の簡略化したメッセージフロー。

【図3】本発明に係る、トラストチェーン内の第２の信頼の基点である第２のＨＳＭが、ＨＳＭと第１のアプリケーションとの間で共有された第１のマスタ対称鍵に基づいて第１の派生対称鍵を動的に生成し、第２のアプリケーションの認証に成功した、及び／又は第２のアプリケーションの証明の検証に成功した後に第２のアプリケーションに第１の派生対称鍵を提供する、第２のアプリケーションと図１の第２のＨＳＭとの間の簡略化したメッセージフロー。

【図4】本発明に係る、２つのアプリケーションのそれぞれが、２つのアプリケーションの他方が、一方でＨＳＭ間で安全に共有され、他方で第１のアプリケーションに提供される第１のマスタ対称鍵に基づいてオンザフライで前もって生成された第１の派生対称鍵を所有していることを証明する、図１の第１及び第２のアプリケーション間の簡略化したメッセージフロー。

【発明を実施するための形態】

【0024】

以下では、本発明による第１及び第２のアプリケーション間の対称型相互認証方法が、２つのサーバである２つのＨＳＭタイプサーバと、第１のデバイスであるクラウドサーバによりサポートされた第１のアプリケーションであるＨＭＥと、第２のデバイスである携帯電話によりサポートされた第２のアプリケーションであるモバイルアプリケーションとによって実行される例示的な実施形態を考える。

【0025】

別の例示的な実施形態（図示せず）によれば、本発明による第１及び第２のアプリケーション間の対称型相互認証方法は、ＨＳＭタイプサーバと、第１のデバイスによりサポートされた第１のアプリケーションと、第２のデバイス（又は第１のデバイス）によりサポートされた第２のアプリケーションとによって実行される。換言すれば、ＨＳＭタイプサーバはいかなる他のＨＳＭタイプサーバとも連携しない、すなわち２つのアプリケーションは同一のＨＳＭタイプサーバによって管理される。このような例示的な実施形態によれば、ＨＳＭタイプサーバは、２つのＨＳＭタイプサーバにより実行される、以下に記載の機能を実行するように適合される。

【0026】

当然ながら、以下に記載の実施形態は単に例示のためのものに過ぎず、本発明の範囲を減縮するものとは認められない。

【0027】

図１は、ＨＭＥ１０２と、第１のＨＳＭ１０４と、モバイルアプリケーション１１０と、第２のＨＳＭ１０８とを備えたシステム１００を模式的に示している。

【0028】

クラウドサーバ１０１は、クラウドコンピューティングネットワーク（図示せず）内に含まれる。

【0029】

データセンターにある可能性があるクラウドサーバ１０１はホストアプリケーションをサポートする。

【0030】

クラウドサーバ１０１は、データ処理手段である１つ又は複数のＣＰＵ（図示せず）と、データ格納手段である１つ又は複数のメモリ（図示せず）と、全てが内部で互いに接続される１つ又は複数の入出力（Ｉ／Ｏ）インターフェイス（図示せず）とを備える。

【0031】

クラウドサーバメモリはオペレーティングシステム（すなわちＯＳ）を格納している。

【0032】

ホストアプリケーションは、第１のアプリケーションであるＨＭＥ１０２をホストする。ホストアプリケーションは、ホストアプリケーションの一部（サブセット）であるＨＭＥ１０２と連携する。ＨＭＥ１０２は、実行されるときネットワーク仮想機能（すなわちＮＶＦ）を実行することができる。

【0033】

例えばＩｎｔｅｌ ＳＧＸなどのＨＭＥ１０２は、クラウドサーバＣＰＵ、又はクラウドサーバ１０１にある専用プロセッサ（又はマイクロプロセッサ）によって実行する又は走らせることができる。

【0034】

ＨＭＥ１０２は、１つ又は複数の中間ネットワークエンティティ（図示せず）を介して、好ましくは双方向リンク１０３経由で第１のＨＳＭ１０４に接続される。

【0035】

第１のＨＳＭ１０４は第１のサービスプロバイダ（又はその代理）によって運用される。第１のＨＳＭ１０４は、双方向リンク１０５経由でブロックチェーンメカニズム１０６又は任意の他の安全なデータ交換メカニズムに接続される。

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

図２に示されているように、第１のＨＳＭ１０４は、好ましくは安全に、すなわち１つ又は複数の所定のセキュリティ制約がＨＭＥ１０２によって満たされていることを検証した後に、ＨＭＥ１０２に第１のマスタ対称鍵セットである１つ又は複数のマスタ対称鍵を提供する。

【0095】

このように１つ又は複数の所定のセキュリティ制約がＨＭＥ１０２によって満たされていることを安全に検証することによって、ＨＭＥ１０２と第１のＨＳＭ１０４との間に事前の信頼を構築することが可能になる。これによって、ＨＭＥ１０２は第１のＨＳＭ１０４にテザリングされ、その結果、ＨＭＥ１０２と第１のＨＳＭ１０４との間に強いトラストバインディングが生じる。

【0096】

クラウドサーバ１０１（より厳密にはホストアプリケーション）は、対応する開始要求２２をＨＭＥ１０２に送信することによってＨＭＥ１０２の実行を開始する。

【0097】

ＨＭＥ１０２は、例えばアプリケーション証明プロセス、アプリケーション認証プロセス及び／又はユーザ認証プロセスなどの１つ又は複数の所定のセキュリティプロセスを、１つ又は複数の鍵を使用することによって実行しながら実行される。

【0098】

所定のセキュリティプロセスは、例えばＨＭＥ１０２により安全に格納されている所定の非対称鍵と、メッセージ認証コード（すなわちＭＡＣ）アルゴリズムなどの所定の証明アルゴリズムとを使用することによるアプリケーション証明プロセスを含んでよい。

【0099】

所定のセキュリティプロセスは、例えばＨＭＥ１０２により安全に格納されている所定の認証鍵と、所定の認証アルゴリズムとを使用することによるコード（すなわちアプリケーション）認証プロセスを含んでよい。

【0100】

所定のセキュリティプロセスは、例えばＨＭＥ１０２により安全に格納されている所定のユーザ認証鍵と、所定のユーザ認証アルゴリズムとを使用することによるユーザ認証プロセスを含んでよい。

【0101】

ＨＭＥ１０２は、証明レポートと、提出データであるコード認証データ及び／又はユーザ認証データとを含む１つ又は複数のメッセージ２４を第１のＨＳＭ１０４に送信する。

【0102】

第１のＨＳＭ１０４は、（受信した）提出データが、例えば予想されるアプリケーション証明プロセス結果、予想されるアプリケーション認証プロセス結果及び／又は予想されるユーザ認証プロセス結果などの、予想される（すなわち所定の）セキュリティプロセス結果と一致するか否かを検証する（２６）。

【0103】

提出データが予想されるセキュリティプロセス結果と一致しない場合、第１のＨＳＭ１０４は、セキュリティプロセスがＨＭＥ１０２によって満たされていることを検証することができない。第１のＨＳＭ１０４は、エラーコード又は障害コードを含むメッセージ（図示せず）をＨＭＥ１０２へ送信することができる。このようなエラーコード又は障害コードによって、ＨＭＥ１０２が必要なセキュリティプロセスを満たしていない旨をＨＭＥ１０２に知らせることが可能になる。

【0104】

そうでない場合、すなわち提出データが予想されるセキュリティプロセス結果と一致する場合にのみ、第１のＨＳＭ１０４は、例えばＨＭＥ１０２の証明の検証に成功する、ＨＭＥ１０２の認証に成功する、及び／又はＨＭＥ１０２のユーザの認証に成功するなど、セキュリティプロセスが満たされていることの検証に成功する。

【0105】

検証に成功すると、分散トラストチェーン内の第１の信頼の基点である第１のＨＳＭ１０４は、例えばＨＭＥ１０２の真正性及び完全性の証明、認証されたＨＭＥ１０２の証明、及び／又は認証されたＨＭＥユーザの証明などのセキュリティ証明である第１のマスタ対称鍵セット（及び／又は第２のマスタ対称鍵セット）を含む１つ又は複数のメッセージ２８をＨＭＥ１０２へ送信する。これによって、第１のＨＳＭ１０４はＨＭＥ１０２との信頼を構築する。

【0106】

ＨＭＥ１０２は、セキュリティ証明として第１のマスタ対称鍵セット（及び／又は第２のマスタ対称鍵セット）を受信すると、第２のＨＳＭ１０８により管理されたモバイルアプリケーション１１０（及び／又は任意の他のモバイルアプリケーション）との相互認証（すなわち信頼）を構築することができる。

【0107】

図３に示されているように、第２のＨＳＭ１０８は、好ましくは安全に、すなわち１つ又は複数の所定のセキュリティ制約がモバイルアプリケーション１１０によって満たされていることを検証した後に、モバイルアプリケーション１１０に第１の派生対称鍵を提供する。

【0108】

このように１つ又は複数の所定のセキュリティ制約がモバイルアプリケーション１１０によって満たされていることを安全に検証することによって、モバイルアプリケーション１１０と第２のＨＳＭ１０８との間に事前の信頼を構築することが可能になる。これによって、モバイルアプリケーション１１０は第２のＨＳＭ１０８にテザリングされ、その結果、モバイルアプリケーション１１０と第２のＨＳＭ１０８との間にトラストバインディングが生じる。

【0109】

電話１１１（より厳密にはホストアプリケーション）は、対応する開始要求３２をモバイルアプリケーション１１０に送信することによってモバイルアプリケーション１１０の実行を開始する。

【0110】

モバイルアプリケーション１１０は、例えばアプリケーション証明プロセス、アプリケーション認証プロセス及び／又はユーザ認証プロセスなどの１つ又は複数の所定のセキュリティプロセスを、１つ又は複数の鍵を使用することによって実行しながら実行される。

【0111】

所定のセキュリティプロセスは、例えばモバイルアプリケーション１１０により安全に格納されている所定の非対称鍵、及びＭＡＣアルゴリズムなどの所定の証明アルゴリズムを使用することによるアプリケーション証明プロセスを含んでよい。

【0112】

所定のセキュリティプロセスは、例えばモバイルアプリケーション１１０により安全に格納されている所定の認証鍵、及び所定の認証アルゴリズムを使用することによるコード（すなわちアプリケーション）認証プロセスを含んでよい。

【0113】

所定のセキュリティプロセスは、例えばモバイルアプリケーション１１０により安全に格納されている所定のユーザ認証鍵、及び所定のユーザ認証アルゴリズムを使用することによるユーザ認証プロセスを含んでよい。

【0114】

モバイルアプリケーション１１０は、証明レポート、提出データであるコード認証データ及び／又はユーザ認証データを含む１つ又は複数のメッセージ３４を第２のＨＳＭ１０８に送信する。

【0115】

第２のＨＳＭ１０８は、（受信した）提出データが、例えば予想されるアプリケーション証明プロセス結果、予想されるアプリケーション認証プロセス結果及び／又は予想されるユーザ認証プロセス結果などの、予想される（すなわち所定の）セキュリティプロセス結果と一致するか否かを検証する（３４）。

【0116】

提出データが予想されるセキュリティプロセス結果と一致しない場合、第２のＨＳＭ１０８は、セキュリティプロセスがモバイルアプリケーション１１０によって満たされていることを検証することができない。第２のＨＳＭ１０８は、エラーコード又は障害コードを含むメッセージ３６をモバイルアプリケーション１１０へ送信することができる。このようなエラーコード又は障害コードによって、モバイルアプリケーション１１０が必要なセキュリティプロセスを満たしていない旨をモバイルアプリケーション１１０に知らせることが可能になる。

【0117】

そうでない場合、すなわち提出データが予想されるセキュリティプロセス結果と一致する場合にのみ、第２のＨＳＭ１０８は、例えばモバイルアプリケーション１１０の証明の検証に成功する、モバイルアプリケーション１１０の認証に成功する、及び／又はモバイルアプリケーション１１０のユーザの認証に成功するなど、セキュリティプロセスが満たされていることの検証に成功する。

【0118】

モバイルアプリケーション１１０が必要なセキュリティプロセスを満たす（ことに成功する）と、第２のＨＳＭ１０８は、例えば第１の派生対称鍵を生成するのに使用される鍵生成パラメータである、好ましくは大きい、すなわち２５６ビットより大きいノンス、及び好ましくは（２つ以上のマスタ対称鍵を含む場合の）第２の（又は第１の）マスタ対称鍵セットから選択される第１のマスタ対称鍵を使用することによって、（一意の）第１の派生対称鍵を動的に生成する（３８）。

【0119】

第１の派生対称鍵が生成されると、分散トラストチェーン内の第２の信頼の基点である第２のＨＳＭ１０８は、例えばモバイルアプリケーション１１０の真正性及び完全性の証明、認証されたモバイルアプリケーション１１０の証明、及び／又は認証されたモバイルアプリケーション１１０のユーザの証明などのセキュリティ証明として、第１の派生対称鍵と、鍵生成パラメータと、場合により第１のマスタ対称鍵に関連する一意の識別子に関するデータとを含む、１つ又は複数のメッセージ３１０をモバイルアプリケーション１１０へ送信する。これによって、第２のＨＳＭ１０８は、モバイルアプリケーション１１０との信頼を構築する。

【0120】

モバイルアプリケーション１１０は、セキュリティ証明として、第１の派生対称鍵と、鍵生成パラメータと、場合により第１のマスタ対称鍵に関連する一意の識別子に関するデータとを受信すると、第１のＨＳＭ１０４により管理されたＨＭＥ１０２（及び／又は任意の他のＨＭＥ）との相互認証（すなわち信頼）を構築することができる。

【0121】

図４は、モバイルアプリケーション１１０とＨＭＥ１０２との間で交換されるメッセージ４０の例示的な実施形態を示している。

【0122】

ＨＭＥ１０２が、（第２のマスタ対称鍵セットに含まれている）各マスタ対称鍵に関連する一意の識別子に関するデータである各対応するＵＵＩＤと関連する第２のマスタ対称鍵セットをセキュリティ証明として受信していると仮定される。

【0123】

さらに、モバイルアプリケーション１１０が、第１の派生対称鍵と、鍵生成パラメータと、第１のマスタ対称鍵に関連する一意の識別子に関するデータである第１のマスタ対称鍵のＵＵＩＤｘとをセキュリティ証明として受信していると仮定される。

【0124】

さらにまた、第１の派生対称鍵が、例えば大きいノンスを一意の鍵生成パラメータとして使用することによって生成されていると仮定される。

【0125】

さらにまた、第１のマスタ対称鍵が、前もって第２のＨＳＭ１０８により生成され、第１のＨＳＭ１０４に送信又は伝搬されている第２のマスタ対称鍵セット内に含まれていると仮定される。

【0126】

初めに、モバイルアプリケーション１１０は、第１の派生対称鍵を使用することによって第１の鍵所有証明を生成する（４２）。

【0127】

モバイルアプリケーション１１０は、第１の鍵所有証明を生成するために、第１のノンスを生成し、次に第１の派生対称鍵を使用することによって第１のノンスを暗号化することができる。モバイルアプリケーション１１０はまた、好ましくは第１のノンスのハッシュ値を生成し、次に第１の派生対称鍵を使用することによって第１のノンスのハッシュ値を暗号化することができる。暗号化された第１のノンスのハッシュ値によって、ＨＭＥ１０２が第１の鍵所有証明の検証中に比較される第１の基準を生成することが可能になる。

【0128】

第１の鍵所有証明が生成されると、モバイルアプリケーション１１０は、第１の鍵所有証明である暗号化された第１のノンスと、好ましくは暗号化された第１のノンスのハッシュ値と、第１のマスタ対称鍵のＵＵＩＤｘと、第１の派生対称鍵を生成するのに使用された鍵生成パラメータである大きいノンスとを含む１つ又は複数のメッセージ４４をＨＭＥ１０２へ送信する。

【0129】

メッセージ４４がＨＭＥ１０２によって受信されると、ＨＭＥ１０２は、第１のマスタ対称鍵のＵＵＩＤｘに基づいて、第１の派生対称鍵を生成するのに使用された第１のマスタ対称鍵を特定する（４６）。

【0130】

第１のマスタ対称鍵が特定されると、ＨＭＥ１０２は、第１のマスタ対称鍵と、鍵生成パラメータである大きいノンスとを使用することによって第１の派生対称鍵を生成する（４８）。ＨＭＥ１０２は、第２のＨＳＭ１０８により使用される所定の鍵生成アルゴリズムを使用して第１の派生対称鍵を生成する。

【0131】

第１の派生対称鍵が生成されると、ＨＭＥ１０２は、第１の鍵所有証明が第１の派生対称鍵を使用することによって生成されたものであるか否かを、鍵生成パラメータと、（特定された）第１のマスタ対称鍵と、第１の鍵所有証明とを使用することによって検証する（４１０）。

【0132】

そのような検証４１０を行うために、ＨＭＥ１０２は、例えば暗号化された第１のノンスを、第１の派生対称鍵を使用することによって復号し、結果として平文の第１のノンスを入手する。次いでＨＭＥ１０２は第１のノンスのハッシュ値を生成し、（生成したばかりの）第１のノンスのハッシュ値を受信した比較対象の第１の基準と比較する。

【0133】

比較が失敗した、すなわち第１のノンスのハッシュ値が受信した比較対象の第１の基準と一致しない場合は、第１の鍵所有証明は、第１の派生対称鍵を使用することによって生成されたものではなく、ＨＭＥ１０２はモバイルアプリケーション１１０を認証することができない。ＨＭＥ１０２は、エラーコード又は障害コードを含むメッセージ４１２を送信することができる。このようなエラーコード又は障害コードによって、ＨＭＥ１０２がモバイルアプリケーション１１０を認証できないことをモバイルアプリケーション１１０に知らせることが可能になる。

【0134】

比較が成功した、すなわち第１のノンスのハッシュ値が受信した比較対象の第１の基準と一致した場合は、第１の鍵所有証明は、第１の派生対称鍵を使用することによって生成されたものであり、ＨＭＥ１０２はモバイルアプリケーション１１０の認証に成功する。

【0135】

モバイルアプリケーション１１０の認証が成功すると、ＨＭＥ１０２は、第１の派生対称鍵を使用することによって第２の鍵所有証明を生成する（４１４）。

【0136】

ＨＭＥ１０２は、第２の鍵所有証明を生成するために、第２のノンスを生成し、次に第１の派生対称鍵を使用することによって第２のノンスを暗号化することができる。ＨＭＥ１０２はまた、好ましくは第２のノンスのハッシュ値を生成し、次に第１の派生対称鍵を使用することによって第２のノンスのハッシュ値を暗号化することができる。暗号化された第２のノンスのハッシュ値によって、モバイルアプリケーション１１０が第２の鍵所有証明の検証中に比較される第２の基準を生成することが可能になる。

【0137】

第２の鍵所有証明が生成されると、ＨＭＥ１０２は、第２の鍵所有証明である暗号化された第２のノンスと、好ましくは（必須ではないが）暗号化された第２のノンスのハッシュ値とを含む１つ又は複数のメッセージ４１６をモバイルアプリケーション１１０へ送信する。

【0138】

第２の鍵所有証明が受信されると、モバイルアプリケーション１１０は、第２の鍵所有証明が第１の派生対称鍵を使用することによって生成されたものであるか否かを、少なくとも第２の鍵所有証明を使用することによって検証する（４１６）。

【0139】

そのような検証４１６を行うために、モバイルアプリケーション１１０は、例えば暗号化された第２のノンスを、第１の派生対称鍵を使用することによって復号し、結果として平文の第２のノンスを入手する。次いでモバイルアプリケーション１１０は第２のノンスのハッシュ値を生成し、（生成したばかりの）第２のノンスのハッシュ値を受信した比較対象の第２の基準と比較する。

【0140】

比較が失敗した、すなわち第２のノンスのハッシュ値が受信した比較対象の第２の基準と一致しない場合は、第２の鍵所有証明は、第１の派生対称鍵を使用することによって生成されたものではなく、モバイルアプリケーション１１０はＨＭＥ１０２を認証することができない。モバイルアプリケーション１１０は、エラーコード又は障害コードを含むメッセージ４２０を送信することができる。このようなエラーコード又は障害コードによって、モバイルアプリケーション１１０がＨＭＥ１０２を認証できないことをＨＭＥ１０２に知らせることが可能になる。

【0141】

比較が成功した、すなわち第２のノンスのハッシュ値が受信した比較対象の第２の基準と一致した場合は、第２の鍵所有証明は、第１の派生対称鍵を使用することによって生成されたものであり、モバイルアプリケーション１１０はＨＭＥ１０２の認証に成功する。

【0142】

モバイルアプリケーション１１０がＨＭＥ１０２の認証に成功すると、モバイルアプリケーション１１０及びＨＭＥ１０２は、ＨＭＥ１０２及びモバイルアプリケーション１１０が結果として動的に生成され証明された共有鍵である第１の派生対称鍵をそれぞれ所有していることを互いに証明することによって、相互認証に成功する（４２２）。

【0143】

これによって、トラストチェーンネットワークは、第１のＨＳＭ１０４及び第２のＨＳＭ１０８に加えて、トラストチェーンの追加のエレメントであるＨＭＥ１０２とモバイルアプリケーション１１０とを含む。

【0144】

第１の派生対称鍵は、１時間や３０分などの所定の第１の寿命時間有効であってよい。

【0145】

第２のＨＳＭ１０８は、第１のマスタ対称鍵、及び／又は第１の派生対称鍵を生成するのに使用された１つ又は複数のパラメータを変更することによって、第１の派生対称鍵と異なる第２の派生対称鍵を生成することができる。

【0146】

ＨＭＥ１０２及びモバイルアプリケーション１１０は、例えば第１の鍵所有証明及び／又は第２の鍵所有証明をそれぞれ生成するのに使用された可能性があり、ＨＭＥ１０２及びモバイルアプリケーション１１０により共有されるデータである第１のノンス及び／又は第２のノンスに基づいて、セッション鍵を別々に生成することができる（図示せず）。

【0147】

ＨＭＥ１０２及びモバイルアプリケーション１１０が、例えば第１の派生対称鍵、及び／又は他方のアプリケーションが第１の派生対称鍵を所有していることを証明するのに使用されたデータなどの共有データに基づく同じセッション鍵を共有すると、ＨＭＥ１０２及びモバイルアプリケーション１１０は、（このセッション鍵を使用しながら）連続的かつ安全に処理を行うことができる。

【0148】

セッション鍵は、第１のマスタ対称鍵と異なる第２のマスタ対称鍵を使用することによって暗号化することができる。第２のマスタ対称鍵は、第１のＨＳＭ１０４及び第２のＨＳＭ１０８間で共有される。

【0149】

ＨＭＥ１０２（又はモバイルアプリケーション１１０）は、セッション鍵情報として、第１のマスタ対称鍵と異なる第２のマスタ対称鍵を使用することにより前もって暗号化されるセッション鍵、第２のマスタ対称鍵に関連する一意の識別子に関するデータ、及び／又はセッション鍵が有効である所定の寿命時間を含む１つ又は複数のメッセージ（図示せず）を、モバイルアプリケーション１１０（又はＨＭＥ１０２）へ（それぞれ）送信することができる。このようなセッション鍵情報は、ヘッダ内容が暗号化されていない、すなわち平文であるため、好ましくは各メッセージのヘッダに挿入される。

【0150】

第１のＨＳＭ１０４、第２のＨＳＭ１０８、及び分散トラストチェーン内に含まれているが第１のＨＳＭ１０４及び第２のＨＳＭ１０８と異なる第３のＨＳＭは、ＨＭＥ１０２及びモバイルアプリケーション１１０と異なる第３のアプリケーションに、第１のマスタ対称鍵セット及び／又は第２のマスタ対称鍵セットを送信することができる。そしてＨＭＥ１０２又はモバイルアプリケーション１１０は、第３のアプリケーションにセッション鍵情報を送信し、結果として同一のセッション鍵を使用して第３のアプリケーションと安全に交換を行う。このようなセッション鍵情報の送信によって、セッション鍵情報の第３のアプリケーションへの伝搬が可能となる。このようなセッション鍵情報の送信によって、特にペイロードバランシング又は仮想ペイロードバランシングとの関連における、第１又は第２のアプリケーションから第３のアプリケーションへの通信の移植性を確保することが可能となる。そして、第３のアプリケーションとの通信は、あらゆるデータ交換においてセッション鍵情報を使用して安全性が保護される。そして第３のアプリケーションは、セッション鍵情報を使用して、第３のアプリケーションにより受信されるデータを復号し、第３のアプリケーションから送信されるデータを暗号化する。

【0151】

例えば第１のマスタ対称鍵などの、ＨＳＭトラストチェーン内で管理された１つ又は複数のマスタ対称鍵を使用するいかなるサービスプロバイダ、エンドユーザ及び／又はアプリケーションも、関与するサービスプロバイダ自体でさえも当該マスタ対称鍵を危殆化し得ないことを信じることができる。

【0152】

本発明の解決策は、好ましくはセキュアコード／データ（例えばＨＭＥなど）の高い保証された機密性及び完全性を提供することを可能にする。

【0153】

本発明の解決策は、好ましくは対称鍵を使用する高速認証メカニズムを提供することを可能にする。このような高速認証メカニズムによって、少なくとも一方がセキュアコード／データであるＨＭＥ（など）内で終端する２つのエンドポイントが、高速対称暗号を使用して互いとの信頼を迅速に構築することが可能になる。

【0154】

本発明の解決策は、セキュアコード／データ（例えばＨＭＥなど）と安全性が低い（すなわち安全でない）コード（例えばモバイルアプリケーションなど）との高い保証された隔離を提供することを可能にする。このような隔離によって、サイドチャネル攻撃や悪意のあるクラウド管理者などの内部関係者からの攻撃から安全を確保しながら、機密コード及び機密情報を仮想ペイロード内にホストすることが可能になる。

【0155】

本発明の解決策は、別々のサービスプロバイダが、一方のサービスプロバイダにより運営される（ＨＳＭタイプサーバを備えた）システム上で動作するアプリケーション及び場合により安全なペイロードが、他方のサービスプロバイダにより運営される（別のＨＳＭタイプサーバを備えた）別のシステム上で動作する別のアプリケーション及び別の安全なペイロードとの信頼（すなわち認証）を構築できるように相互間の信頼を構築する方法を提供することを可能にする。本発明の解決策は、セキュアコード（例えばＨＭＥなど）及びＨＳＭタイプサーバネットワークを伴いながら、信頼が広く分散したシステムに広がることを可能にする。

【0156】

本発明の解決策は、両面否認を提供することを可能にする。すなわち第１のアプリケーションは第２のアプリケーションが本物であることを知っており、またその逆も言える。

【0157】

本発明の解決策は、いかなる測度、すなわちＰＫＩ技術に基づくいかなる署名も必要としない。

【0158】

本発明の解決策は、動的に導出された鍵を使用する対称暗号に基づいているため単純で安全性が高い。

【0159】

本発明の解決策は、対称暗号に基づいているため高速である。

【図1】

【図2】

【図3】

【図4】