JP2018182736A - 秘密かつ相互認証される鍵交換 - Google Patents

秘密かつ相互認証される鍵交換 Download PDF

Info

Publication number
JP2018182736A
JP2018182736A JP2018072089A JP2018072089A JP2018182736A JP 2018182736 A JP2018182736 A JP 2018182736A JP 2018072089 A JP2018072089 A JP 2018072089A JP 2018072089 A JP2018072089 A JP 2018072089A JP 2018182736 A JP2018182736 A JP 2018182736A
Authority
JP
Japan
Prior art keywords
ciphertext
key
message
hipe
signature
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Granted
Application number
JP2018072089A
Other languages
English (en)
Other versions
JP7024563B2 (ja
Inventor
フェレイラ アブダラ・ミシェル
Ferreira Abdalla Michel
フェレイラ アブダラ・ミシェル
チェン・ウェイ−ペン
Wei-Peng Chen
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Fujitsu Ltd
Original Assignee
Fujitsu Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Fujitsu Ltd filed Critical Fujitsu Ltd
Publication of JP2018182736A publication Critical patent/JP2018182736A/ja
Application granted granted Critical
Publication of JP7024563B2 publication Critical patent/JP7024563B2/ja
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/06—Network architectures or network communication protocols for network security for supporting key management in a packet data network
    • H04L63/061—Network architectures or network communication protocols for network security for supporting key management in a packet data network for key exchange, e.g. in peer-to-peer networks
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/04—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks
    • H04L63/0428—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the data content is protected, e.g. by encrypting or encapsulating the payload
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
    • H04L9/0816—Key establishment, i.e. cryptographic processes or cryptographic protocols whereby a shared secret becomes available to two or more parties, for subsequent use
    • H04L9/0838—Key agreement, i.e. key establishment technique in which a shared key is derived by parties as a function of information contributed by, or associated with, each of these
    • H04L9/0841—Key agreement, i.e. key establishment technique in which a shared key is derived by parties as a function of information contributed by, or associated with, each of these involving Diffie-Hellman or related key agreement protocols
    • H04L9/0844—Key agreement, i.e. key establishment technique in which a shared key is derived by parties as a function of information contributed by, or associated with, each of these involving Diffie-Hellman or related key agreement protocols with user authentication or key authentication, e.g. ElGamal, MTI, MQV-Menezes-Qu-Vanstone protocol or Diffie-Hellman protocols using implicitly-certified keys
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
    • H04L9/088—Usage controlling of secret information, e.g. techniques for restricting cryptographic keys to pre-authorized uses, different access levels, validity of crypto-period, different key- or password length, or different strong and weak cryptographic algorithms

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computing Systems (AREA)
  • Computer Hardware Design (AREA)
  • General Engineering & Computer Science (AREA)
  • Algebra (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Mathematical Analysis (AREA)
  • Mathematical Optimization (AREA)
  • Mathematical Physics (AREA)
  • Pure & Applied Mathematics (AREA)
  • Theoretical Computer Science (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)

Abstract

【課題】秘密かつ相互認証される鍵交換の方法が提供される。
【解決手段】本方法は、第一の装置において、第二の装置から送信された、階層的内積暗号化（HIPE）暗号文を含むメッセージを受け取ることを含んでいてもよい。さらに、本方法は、第一の装置において、前記HIPE暗号文を復号して、第一の認証付き暗号化（AE）暗号文を生成することを含んでいてもよい。本方法はさらに、第一の装置において、第一のAE暗号文を復号することを含んでいてもよい。さらに、本方法は、第一の装置の署名および一つまたは複数の属性を含む第二のAE暗号文を暗号化することを含んでいてもよい。さらに、本方法は、第二の装置に、前記第二のAE暗号文を含む別のメッセージを送信することを含んでいてもよい。
【選択図】図１

Description

本稿で論じられる実施形態は、電子装置の間の認証された鍵交換に関する。
二つ以上の電子装置はネットワークを介してデータを送受信しうる。さまざまな鍵交換プロトコルにより、電子装置は、ネットワークを介して暗号化されたメッセージを交換するための共通の鍵について合意することができる。
本願で特許請求される主題は、何らかの欠点を解決する、あるいは上記のような環境でのみ動作する実施形態に限定されない。この背景は、本稿に記載されるいくつかの実施形態が実施されうる一つの例示的な技術分野を示すために与えられているだけである。
ある実施形態のある側面によれば、方法が、第一の装置から第二の装置に、公開鍵を含む第一のメッセージを送信することを含んでいてもよい。本方法はまた、第一の装置において、階層的内積暗号化（HIPE: hierarchical inner-product encryption）暗号文を含む第二の装置からの第二のメッセージを受け取ることをも含んでいてもよい。さらに、本方法は、第一の装置において、HIPE暗号文を解読して、第一の認証付き暗号化（AE: authenticated encryption）暗号文を生成することを含んでいてもよい。さらに、本方法は、第一の装置において、第一のAE暗号文を解読することを含んでいてもよい。さらに、本方法は、解読された第一のAE暗号文に基づいて、第二の装置の署名および一つまたは複数の属性を判別することを含んでいてもよい。本方法はさらに、第一の装置において、第一の装置の署名および一つまたは複数の属性を含む第二のAE暗号文を生成することを含んでいてもよい。さらに、本方法は、第二の装置に、第二のAE暗号文を含む第三のメッセージを送信することを含んでいてもよい。
実施形態の目的および利点は、少なくとも、請求項において具体的に指摘される要素、特徴および組み合わせによって、実現され、達成されるであろう。
上記の概括的な技術および以下の詳細な記述はいずれも例示および説明するものであり、特許請求される発明を制約するものではないことは理解しておくものとする。
例示的実施形態について、さらに具体的かつ詳細に、付属の図面を使って記述し、説明する。
複数の通信上結合された電子装置を含むシステムを描く図である。 装置間の秘密かつ相互認証される鍵交換の例示的な方法のフローチャートである。 装置間の秘密かつ相互認証される鍵交換の例示的な方法のフローチャートである。 装置間の秘密かつ相互認証される鍵交換の例示的な方法のフローチャートである。 装置間の秘密かつ相互認証される鍵交換の例示的な方法のフローチャートである。 装置間の秘密かつ相互認証される鍵交換の例示的な方法のフローチャートである。 例示的なコンピューティング装置のブロック図である。
本稿で論じられる実施形態は、電子装置の間の、秘密で、相互認証される鍵交換に関する。さまざまな実施形態は、内積機能のための一つまたは複数の階層的述語暗号化（hierarchical predicate encryption）方式を介したポリシー構築（たとえば諸ポリシーのクラス）を提供してもよい。さまざまな実施形態において、許諾ポリシーは、選言、多項式、連言標準形（CNF）／選言標準形（DNF）公式および／または閾値述語を評価するよう構成されてもよい。さまざまな実施形態によれば、暗号化方式は、階層的内積暗号化（HIPE）方式の匿名属性を介して、認証（authentication）の間に使われる許諾ポリシー（authorization policy）を隠してもよい。さらに、さまざまな実施形態は、離散対数ベースのおよび／または格子ベースの方式を含んでいてもよい。
本開示のいくつかの実施形態は、受動攻撃に対して安全な一つまたは複数の鍵交換プロトコル（たとえばディフィー・ヘルマン（Diffie-Hellman）鍵交換およびニューホープ・シンプル（NewHope-Simple）鍵交換）に基づいていてもよい。格子ベースのHIPEおよび／または受動的に安全な鍵交換方式を含むいくつかの実施形態では、ポリシーの安全性は、量子計算機のセッティングで維持されうる。これは、従来の方式については成り立たないことがありうる。
認証される鍵交換プロトコルは、安全な通信チャネル（単数または複数）を確立するために、当事者が共通の秘密鍵について、認証された仕方で合意できるようにしうる。しかしながら、たいていの従来の認証される鍵交換プロトコルは単にセッション鍵の秘匿性を保証するだけである。たとえばモノのインターネット（IoT）のコンテキストでは、当事者は、サーバーのような別の装置との安全な確立を確立しようとしているときに、装置についての敏感な情報を漏らすことを避けることを望むことがありうる。さまざまな実施形態によれば、秘密の、相互認証される鍵交換プロトコルが、受動攻撃および能動攻撃の場合において、セッション鍵の秘匿性およびユーザー素性の秘匿性の両方を提供しうる。特に、いくつかの秘密の相互認証される鍵交換プロトコル（たとえば、アフィリエーション隠蔽認証付き鍵交換（AH-AKE: affiliation-hiding authenticated key exchange）、クレデンシャル・ベースの認証付き鍵交換（CAKE: credential-based authenticated key exchange）および言語ベースの認証付き鍵交換（LAKE: language-based authenticated key exchange））は、装置属性についての種々の型のポリシーの実装を、これらの属性を権限のないユーザーに対して明かすことなく、許容しうる。
さまざまな実施形態は、対称暗号（SE: symmetric encryption）方式、鍵導出関数（KDF: key derivation function）、署名（Sig: signature）方式、正準的な鍵交換（KE: key exchange）プロトコルおよびHIPE方式のような、一つまたは複数の暗号ツールを利用してもよい。
対称暗号化（SE）方式は、ランダム化鍵生成アルゴリズム（KG）、暗号化アルゴリズム（ENC）および復号アルゴリズム（DEC）を含むさまざまなアルゴリズムを含みうる。ランダム化鍵生成アルゴリズム（KG）は、入力としてセキュリティー・パラメータを受け取り、鍵を返してもよい。暗号化アルゴリズム（ENC）は、入力として鍵および平文を受け取って、暗号文を返してもよい。復号アルゴリズムDECは、入力として鍵およびストリングを受け取って、対応する平文または失敗記号（たとえば失敗記号⊥）を返してもよい。
データ秘匿性に加えて、対称暗号化（SE）方式は、認証されてもよく、「認証付き暗号化」（authenticated encryption）と称されてもよい。こうして、データ秘匿性および暗号文完全性が維持されてもよい。鍵導出関数（KDF）は、本稿で「シード（seed）鍵」と称されることのある単一の鍵から複数の計算上独立な鍵を生成することを提供しうる。それぞれの独立なKDF関数iは本稿ではKDFi(seed)と称されることがある。
署名（Sig）方式は、鍵生成アルゴリズム（KeyGen）、署名アルゴリズム（Sign）および検証アルゴリズム（Verify）を含むさまざまな確率的な多項式時間のアルゴリズムを含みうる。鍵生成アルゴリズム（KeyGen）は、入力としてセキュリティー・パラメータを受け取ってもよく、公開検証鍵および秘密署名鍵を出力してもよい。署名アルゴリズム（Sign）は、入力としてメッセージおよび署名鍵を受け取ってもよく、署名を出力してもよい。検証アルゴリズム（Verify）は、入力としてメッセージ、署名および公開鍵を受け取ってもよく、たとえば署名が正しければ「1」、そうでなければ「0」を出力してもよい。
二当事者（たとえば装置Aと装置B）間での正準的な鍵交換（KE）プロトコルは、メッセージ生成アルゴリズム（たとえばGenMsgAおよびGenMsgB）および鍵生成アルゴリズム（たとえばGenKeyAおよびGenKeyB）を含むさまざまなアルゴリズムを利用してもよい。（たとえば装置Aにおける）メッセージ生成アルゴリズム（たとえばGenMsgA）は、入力として一つまたは複数の共通パラメータ（たとえば「pars」）を受け取ってもよく、装置Bに送られるべき、秘密状態（stA）およびメッセージ（MA）を含む多項組〔タプル〕（stA,MA）を出力してもよい。（たとえば装置Bにおける）メッセージ生成アルゴリズム（たとえばGenMsgB）は、入力として前記共通パラメータ（pars）および装置Aによって送られたメッセージ（MA）を受け取ってもよく、装置Aに送られるべき、秘密状態（stB）およびメッセージ（MB）（本稿では「公開鍵」とも称される）を含む多項組〔タプル〕（stB,MB）を出力してもよい。
さらに、（たとえば装置Aにおける）鍵生成アルゴリズム（たとえばGenKeyA）は入力として、秘密状態（stA）および装置Bによって送られたメッセージ（MB）を受け取ってもよく、セッション鍵（skA）を出力してもよい。（たとえば装置Bにおける）鍵生成アルゴリズム（たとえばGenKeyB）は入力として、秘密状態（stB）および装置Aによって送られたメッセージ（MA）を受け取ってもよく、セッション鍵（skB）を出力してもよい。
正準的な鍵交換（たとえば正準的な二者鍵交換）は、プロトコルの誠実な実行において当事者（たとえば二人の当事者）によって計算されたセッション鍵が同じ定義域からのランダムな値と区別できないとすれば、受動的な敵に関して安全であると考えられてもよい。
さまざまな実施形態において、HIPE方式は、セットアップ・アルゴリズム（Setup）、導出アルゴリズム（Derive）、暗号化アルゴリズム（Enc）および復号アルゴリズム（Dec）といったさまざまな確率的多項式時間アルゴリズムを含んでいてもよい。セットアップ・アルゴリズム（Setup）は入力として、入力セキュリティー・パラメータ（たとえばセキュリティー・パラメータλ）および階層フォーマット（たとえば階層フォーマットμ）を受け取ってもよく、公開パラメータ（たとえばマスター公開鍵（mpk））およびマスター秘密鍵（たとえばマスター秘密鍵（msk））を出力してもよい。導出アルゴリズム（Derive）はマスター公開鍵（たとえばマスター公開鍵（mpk）、マスター秘密鍵（たとえばマスター秘密鍵（msk））およびベクトル（たとえばベクトルw）を入力として受け取ってもよく、ベクトル（たとえばベクトルw）についての秘密鍵（たとえば秘密鍵dw）を出力してもよい。暗号化アルゴリズム（Enc）は、（たとえば何らかの関連するメッセージ空間における）メッセージ（たとえばメッセージM）、公開パラメータ（たとえばマスター公開鍵（mpk））およびポリシー・ベクトル（たとえばポリシー・ベクトルp）を入力として受け取ってもよく、暗号文（C）を出力してもよい。復号アルゴリズム（Dec）は公開パラメータ（たとえばマスター公開鍵（mpk））、暗号文（たとえば暗号文C）および秘密鍵（たとえば秘密鍵dw）を入力として受け取って、メッセージ（たとえばメッセージM）または失敗を示す記号（たとえば⊥）を出力してもよい。
たとえば、ベクトルpについて暗号文C＝Enc(mpk,p,M)であり、ベクトルwについて秘密復号鍵dw＝Derive(msk,w)であれば、安全なHIPE方式は、<w,p>＝0である場合にかつその場合にのみ、秘密の復号鍵（たとえば秘密復号鍵dw）を所有している復号装置が暗号文Cからメッセージ（たとえばメッセージM）を回復しうることを保証しうる。ここで、pは暗号文Cに関連付けられた許諾ポリシー・ベクトルであり、wは秘密復号鍵dwに関連付けられた属性ベクトルである。
本開示のさまざまな実施形態は、各当事者が署名方式のための公開鍵秘密鍵ペアに関連付けられる公開鍵インフラストラクチャーの存在を前提としてもよい。いくつかの実施形態では、各当事者は、証明書チェーンを介して公開鍵に結びつけられているいくつかの関連付けられた属性を有していてもよい。さらに、さまざまな実施形態によれば、各当事者は、自分の属性に基づく、HIPE方式のための秘密の復号鍵を有していてもよい。いくつかの実施形態では、秘密の復号鍵は、各当事者の属性を検証した後に、信頼されるサードパーティー（TTP: trusted third party）によって生成されてもよい。いくつかの例では、これらの鍵は、エンドユーザー装置によって、該装置の所有者の名前で、そのピアとの安全なセッション鍵を確立するために使われてもよい。
さまざまな実施形態によれば、当事者によって生成されたセッション鍵は、たとえ通信ネットワークを制御することができうる仲介者攻撃者（man-in-the-middle adversary）がいても、同じ定義域からランダムに一様に選ばれた鍵とは識別不能であってもよい。さらに、許諾プロトコルは、プロトコルに関わる当事者の素性を隠してもよい。より具体的には、たとえば、装置は、ピアの許諾ポリシーを満たす場合にピアの素性を知るのみであってもよい。この目標を達成するために、装置は、HIPE方式を使ってその素性および属性を暗号化してもよく、こうして、その許諾ポリシーを満たすピアのみが該装置の素性および属性を復号できてもよい。
さらに、許諾プロトコルは、たとえ能動攻撃があるときでも、それらの装置によって使用される許諾ポリシーを隠蔽してもよい。HIPE方式は暗号化の間に使われた許諾ポリシーを隠しうるので、この目標は、素性の秘匿性のために使われるのと同じ技法を使って達成されうる。
IoTのコンテキストでは、たとえば、ポリシーが漏れて、別の装置（たとえばサーバー）への安全な接続を確立しようとしている装置についての敏感な情報を漏らすことがありうる。これはたとえば、プレフィックス・ベースのおよびその他の比較的単純な許諾ポリシーの場合に成り立ちうる。敵はサーバーによって使われる許諾ポリシーから、装置の属性についての情報を推定できうるからである。
さまざまな実施形態によれば、識別情報は、プレフィックス・ベースの暗号化ではなく、HIPEを使って暗号化されてもよい。こうして、より一般的な許諾ポリシーが使用されてもよく、ポリシーは（たとえば権限のない装置から）隠されてもよい。さらに、方式の安全性が維持されてもよく、方式の機能が高められてもよい（たとえば、各当事者の署名検証鍵がその素性に結びつけられるため）。
いくつかの実施形態では、（たとえばディフィー・ヘルマン鍵交換を想定する代わりに）一般的な受動的に安全な鍵交換が使われてもよく、こうして、種々のインスタンス化を許容してもよい。さらに、格子ベースの方式のような根底にあるプリミティブを適正にインスタンス化することによって、量子計算機時代の安全性が達成されうる。
ディフィー・ヘルマン鍵交換のような数論ベースの暗号システムは、量子計算機セッティングにおいては安全ではないと考えられうる。量子計算機は離散対数問題および因数分解問題のようなその基礎になっている計算問題を多項式時間で解くことができる可能性があるからである。よって、格子ベースの問題は、量子計算機時代でも安全でありうる。
HIPEを介して実装されうるさまざまな例示的な許諾ポリシーについてここで述べる。一つの例示的なポリシーは、匿名IDベース暗号化（A-IBE: anonymous identity-based encryption）方式を含む。A-IBE方式では、ユーザーの素性〔アイデンティティー〕（たとえば電子メール・アドレス、ユーザー名など）がユーザー属性（たとえば素性Id）を含んでいてもよく、ポリシーは、暗号化されたメッセージが送られるユーザーの素性を含んでいてもよい。
HIPE方式を使ってA-IBE許諾ポリシーを実装するためには、秘密鍵についての素性Idが属性ベクトルにマッピングされてもよく（たとえばw＝(Id,1)）、暗号文についての素性Idがポリシー・ベクトルにマッピングされてもよい（たとえばπ＝(−1,Id)）。いくつかの実施形態では、暗号文の素性が受領装置の素性に一致する場合（たとえば<w,p>＝0）、受領装置が暗号化されたメッセージを復元できてもよい。
もう一つの例示的なポリシーは、プレフィックス・ベースのポリシーを含む。この例では、秘密鍵および／または暗号文は名前に関連付けられてもよい。たとえば、秘密鍵は「alice/devices/security/」であってもよく、暗号文は「alice/devices」を含んでいてもよい。この例では、暗号文における名前が秘密鍵における名前のプレフィックスに一致する場合に、復号が成功してもよい。
いくつかの実施形態では、プレフィックス・ベースの暗号化は、A-IBE方式を使って実装されてもよい。たとえば、名前についての秘密鍵がIBE秘密鍵のコレクション（たとえば各プレフィックスについて一つの秘密鍵）を含んでいてもよい。より特定的には、「alice/」、「alice/devices/」および「alice/devices/security/」についての秘密鍵は、「alice/devices/security」の任意のプレフィックスを復号しうる。
もう一つの例示的な許諾ポリシーは、多項式評価ポリシーを含む。この例では、ユーザー属性は値y mod Nに対応してもよい。ここで、Nは比較的大きな整数である。この例では、暗号文ポリシーは多項式に対応してもよい（たとえば、(ad,…,a1,a0)によって定義される次数dの多項式p(x)＝adxd＋……＋a1＋x0 mod N）。さまざまな実施形態によれば、復号はp(y)＝0 mod Nの場合に可能であってもよい。
HIPE方式を使って多項式評価ポリシーを実装するためには、秘密鍵のための属性yは属性ベクトルにマッピングされてもよく（たとえばw＝(yd,yd-1,…,y,1)）、暗号文についての多項式p(x)はポリシー・ベクトルにマッピングされてもよい（たとえばp＝(ad,ad-1,…,a1,a0)）。暗号文多項式が属性yについて0であると評価される場合（（たとえばp(y)＝0）、<w,p>＝0）、受領装置は暗号化されたメッセージを復号できてもよい。
もう一つの例示的な許諾ポリシーは、選言を含む。この例では、送信装置（たとえばサーバー）は暗号文をポリシーA1またはポリシーA2のもとで暗号化してもよい。それにより、属性A1または属性A2をもつ装置のみが暗号文を復号しうる。さらに、この例において、受信装置はその属性が送信装置のポリシーを満たすことを知りうるが、ポリシー自身を知ることはない。
HIPE方式を使って選言ポリシーを実装するためには、暗号文多項式はたとえばp(x)＝(x−A1)(x−A2)(x−A3)に設定されてもよく、秘密鍵属性が暗号文ポリシーにおける属性の一つに一致するときは常に、暗号文多項式は属性Aについて0として評価されうる（たとえばp(A)＝0）。
もう一つの例示的な許諾ポリシーは連言を含む。この例では、ポリシーA1およびポリシーA2のようなポリシーは、属性A1および属性A2を同時に有する装置のみが装置（たとえばサーバー）によって送られた暗号文を復号できうるよう実装されてもよい。連言ポリシーは、暗号化の間にランダムなrを選び、p(x1,x2)＝r(x1−A1)＋(x2−A2)と設定することによって、二変数多項式ポリシーを使って実装されてもよい。これにより、秘密鍵がポリシーA1およびポリシーA2の両方に関連付けられている場合に、p(A1,A2)＝0となる。
二変数多項式ポリシーはHIPEを使って、各変数組み合わせ（たとえばx1,x2,x1,x2,1）をHIPEベクトルの異なるエントリーにマッピングすることによって、（単変数）多項式ポリシーとして実装されうる。
さらに、さまざまな実施形態によれば、HIPE方式は、二つ以上の許諾技法を組み合わせることを介して、より複雑なCNFおよびDNF公式を実装してもよい。たとえば、CNFは技法Aおよび（技法Bもしくは技法C）および（技法Dもしくは技法E）を含んでいてもよい。さらに、DNFは（技法Aおよび技法Bおよび技法D）または（技法Aおよび技法Bおよび技法E）または（技法Aおよび技法Cおよび技法D）または（技法Aおよび技法Cおよび技法E）を含んでいてもよい。任意のブール公式がCNFまたはDNF公式として書かれてもよい。いくつかの実施形態では、公式中の変数の数が制限されてもよい。方式の効率が変数の数とともに指数関数的に増大しうるからである。
本開示の実施形態について、付属の図面を参照して説明する。
図１は、ネットワーク１０２を介して通信上結合されている装置Aおよび装置Bを含むシステム１００を描いている。装置Aはプロセッサ１０４を含んでいてもよく、装置Bはプロセッサ１０６を含んでいてもよい。さらに、装置Aはデータ１０８を含んでいてもよく、該データ１０８はたとえば装置Aの許諾ポリシーπA、装置Aの一つまたは複数の属性wAおよび装置Aの識別子IDAを含んでいてもよい。さらに、装置Bはデータ１１０を含んでいてもよく、該データ１１０はたとえば装置Bの許諾ポリシーπB、装置Bの一つまたは複数の属性wBおよび装置Bの識別子IDBを含んでいてもよい。例として、装置Aおよび装置Bのそれぞれは、認証される秘密プロセスを介して秘密鍵を確立することを望むことがありうる。この例において、装置Aはクライアント装置であってもよく、「開始者」と称されてもよく、装置Bはサーバー装置であってもよく、「応答者」と称されてもよい。装置Aおよび装置Bのそれぞれにとってアクセス可能な情報（たとえば公開情報）はたとえば、公開パラメータ（pars）および／またはマスター公開鍵（mpk）を含みうる。
いくつかの例では、識別子（たとえば識別子ID）はある当事者の公開鍵をその属性に結びつける〔バインドする〕証明書チェーンを表わしていてもよく、「SignP(m)」は当事者の、メッセージmに対する署名を表わしてもよく、「{m}sk」は鍵skのもとでのメッセージmの認証付き暗号化「AE.Enc」を指してもよい。さらに、鍵交換プロトコルのそれぞれのインスタンス化はセッションと称されてもよく、各セッションは一意的なセッション識別子（sid）によって同定されてもよい。
鍵導出関数KDF1およびKDF2は二つの独立な鍵導出関数を表わしていてもよく、一つまたは複数の公開パラメータ（たとえばpars）が鍵交換プロトコル（たとえば正準的な二者の受動的に安全な鍵交換プロトコル）に関連付けられていてもよく、マスター公開鍵（mpk）はHIPE方式に関連付けられた公開鍵を含んでいてもよい。
いくつかの実施形態では、たとえばセットアップ・プロセス（たとえばオフラインのセットアップ・プロセス）の間、開始者（たとえばクライアント）（たとえば装置A）は信頼されるサードパーティー（TTP）に接触して、開始者の属性（wA）に基づく秘密の復号鍵（dwA）を取得してもよい。HIPE方式のマスター秘密鍵（msk）を所有していてもよいTTPは、クライアント装置Aの属性（wA）を検証した後、秘密復号鍵（dwA）を発行してもよい。いくつかの実施形態では、秘密復号鍵はDerive(msk,wA)を介して生成されてもよい。
TTPは、いかなる好適な仕方で実装されることもできる。一例として、クライアントがTTPを含んでいてもよい。この例では、クライアントはマスター秘密鍵（msk）を所有していてもよく、その諸装置の任意のものに鍵を発行しうる。もう一つの例では、組織（たとえば企業）がTTPを含んでいてもよい。この例では、該組織はその諸構成員（たとえば従業員）のために、その属性（たとえば職能、階層レベル）に依存して鍵を発行してもよい。さらに、構成員（たとえば従業員）は、受け取った鍵を使って、さらに、関連する装置に鍵を発行してもよい。HIPE方式は鍵の委譲を許容しうるので、このセッティングが可能でありうる。
図２Ａ〜２Ｄは、本稿に記載される少なくとも一つの実施形態に基づいて構成された、秘密かつ相互認証される鍵交換の方法２００の例示的な流れ図を示している。離散的なブロックとして図示されているが、所望される実装に依存して、さまざまなブロックは追加的なブロックに分割されたり、より少数のブロックに組み合わされたり、あるいはなくされたりしてもよい。
いくつかの実施形態では、方法２００は、図１の装置Aおよび／または装置Bおよび／または図３の装置３００のような一つまたは複数の装置によって実行されてもよい。たとえば、図３の処理装置３２０は、方法２００のブロックの一つまたは複数によって表わされる機能および動作を実行するためにメモリ３３０上に記憶されたコンピュータ命令を実行するよう構成されてもよい。
図１および図２Ａを参照するに、この実施形態において開始者（たとえばクライアント）装置である装置Aが、たとえば正準的な鍵交換プロトコル（たとえば正準的な二者鍵交換プロトコル）を介して一時的公開鍵を生成して、該一時的公開鍵を、この例において応答者（たとえばサーバー）装置である装置Bに送信してもよい。
方法２００は、ブロック２０２で始まってもよい。ブロック２０２では、メッセージおよび秘密状態（本稿で「秘密鍵」とも称される）が関数を介して生成されてもよく、方法２００はブロック２０４に進んでもよい。より具体的には、たとえば、メッセージ生成関数（たとえばGenMsgA関数）が入力として共通パラメータparsを受け取ってもよく、装置Aのための秘密鍵stAおよびメッセージ（たとえば公開鍵）MAを生成してもよい。より具体的には、たとえば、秘密状態stAおよびメッセージMAは装置Aにおいて（たとえばプロセッサ１０４によって）生成されてもよい。
ブロック２０４では、セッション識別子および前記メッセージを含むデータが送信されてもよい。たとえば、前記データは、セッション識別子sidおよび前記メッセージ（たとえば公開鍵）MAを含んでいてもよく、装置Aから装置Bに送信されてもよい。
図１および図２Ｂを参照するに、この例で応答者である装置Bが、正準的な鍵交換を介して一時的公開鍵を生成し、対応するセッション鍵を計算し、認証付き暗号化（AE）方式を使ってその属性および署名を暗号化してもよい。さらに、装置Bは、一時的公開鍵と、AE暗号文をHIPE暗号化したものとを装置Aに送ってもよい。
ブロック２０５では、セッション識別子およびメッセージを含むブロック２０４での送信されたデータが第二の装置において受信されてもよく、方法２００はブロック２０６に進んでもよい。
ブロック２０６では、メッセージおよび秘密状態が関数を介して生成されてもよく、方法２００はブロック２０８に進んでもよい。より具体的には、たとえば、メッセージ生成関数（たとえばGenMsgB関数）が入力として一つまたは複数の共通パラメータ（たとえばpars）を受け取ってもよく、装置Bのための秘密状態stBおよびメッセージ（たとえば公開鍵）MBを生成してもよい。より具体的には、たとえば、秘密状態stBおよびメッセージ（たとえば公開鍵）MBは装置Bにおいて（たとえばプロセッサ１０６によって）生成されてもよい。
ブロック２０８では、セッション鍵が生成されてもよく、方法２００はブロック２１０に進んでもよい。たとえば、鍵生成関数（たとえばGenKeyB関数）が秘密状態stBおよびメッセージMAを入力として受け取って、セッション鍵skBを出力してもよい。より具体的には、たとえば、セッション鍵skBは装置Bにおいて（たとえばプロセッサ１０６によって）生成されてもよい。
ブロック２１０では、認証暗号化鍵が生成されてもよく、方法２００はブロック２１２に進んでもよい。たとえば、鍵導出関数がセッション鍵skBを入力として受け取って、認証暗号化鍵htkを出力してもよい。より具体的には、たとえば、認証暗号化鍵は装置Bにおいて（たとえばプロセッサ１０６によって）生成されてもよい。
ブロック２１２では、署名が生成されてもよく、方法２００はブロック２１４に進んでもよい。たとえば、署名関数はセッション識別子sid、識別子IDB（たとえばユーザー名、電子メール・アドレスなど）、公開鍵MAおよび公開鍵MBを入力として受け取って、署名σBを出力してもよい。より具体的には、たとえば、署名は装置Bにおいて（たとえばプロセッサ１０６によって）生成されてもよい。
ブロック２１４では、認証された暗号化された暗号文が生成されてもよく、方法２００はブロック２１６に進んでもよい。たとえば、関数（たとえばAE.Enc関数）が、認証暗号化鍵htk、セッション識別子sid、メッセージMB、識別子IDB、メッセージMAおよび署名σBに基づいて、認証された暗号化された暗号文AECBを生成してもよい。より具体的には、たとえば、AE.Enc(mpk,HCB,dwA)は認証された暗号化された暗号文AECBを生成してもよい。たとえば、認証された暗号化された暗号文AECBは装置Bにおいて（たとえばプロセッサ１０６によって）生成されてもよい。
ブロック２１６では、HIPE暗号文が生成されてもよく、方法２００はブロック２１８に進んでもよい。たとえば、関数（たとえばHIPE.Enc関数）が、マスター公開鍵（mpk）、装置Bについてのポリシー・ベクトルπBおよび認証された暗号化された暗号文AECBに基づいて、HIPE暗号文HCBを生成してもよい。より具体的には、HIPE.Enc(mpk,πB,AECB)はHIPE暗号文HCBを生成してもよい。たとえば、HIPE暗号文HCBは装置Bにおいて（たとえばプロセッサ１０６によって）生成されてもよい。
ブロック２１８では、HIPE暗号文を含むデータが送信されてもよく、方法２００はブロック２２０に進んでもよい。たとえば、HIPE暗号文HCBを含むことに加えて、前記データはセッション識別子sidおよびメッセージMBをも含んでいてもよい。より具体的には、たとえば、HIPE暗号文を含むデータは装置Bから装置Aに送信されてもよい。
図１、図２Ｃおよび２Ｄを参照するに、この例では開始者である装置AはHIPE暗号文を復号し、対応するセッション鍵を計算し、AE方式についての暗号文を復号することを試みてもよい。すべての署名有効性検査および復号が成功であれば、装置Aはその署名および属性を、AE方式のもとで暗号化して、応答者、装置Bに送り返してもよい。装置Aは最終的なセッション鍵をも生成してもよい。
ブロック２２０では、HIPE暗号文を含むデータが受領されてもよく、方法２２０はブロック２２２に進んでもよい。たとえば、HIPE暗号文を含むデータが装置Aにおいて受信されてもよい。
ブロック２２２では、セッション鍵が生成されてもよく、方法２００はブロック２２４に進んでもよい。たとえば、鍵生成関数（たとえばGenKeyA関数）が秘密stAおよびメッセージMBを入力として受け取って、セッション鍵skAを出力してもよい。より具体的には、たとえば、セッション鍵skAは装置Aにおいて（たとえばプロセッサ１０４によって）生成されてもよい。
ブロック２２４では、認証暗号化鍵が生成されてもよく、方法２００はブロック２２６に進んでもよい。たとえば、鍵導出関数がセッション鍵skAを入力として受け取って、認証暗号化鍵htkを出力してもよい。より具体的には、たとえば、認証暗号化鍵は装置Aにおいて（たとえばプロセッサ１０４により）生成されてもよい。
ブロック２２６では、HIPE暗号文HCBが復号されてもよく、方法２００はブロック２２８に進んでもよい。たとえば、関数（たとえばHIPE.Dec関数）を使って、マスター公開鍵（mpk）および秘密鍵（dwA）に基づいてHIPE暗号文HCBを復号してHIPEメッセージ（HM）を生成してもよい。たとえば、HIPE暗号文HCBは装置Aにおいて（たとえばプロセッサ１０４により）復号されてもよい。
ブロック２２８では、HIPEメッセージHMが有効であるかどうかについて判定がなされてもよい。HIPEメッセージHMが無効であれば、方法２００は終了してもよい。HIPEメッセージHMが有効であれば、ブロック２３０に進んでもよい。HIPEメッセージHMが有効であるかどうかについての判定は、装置Aにおいて（たとえばプロセッサ１０４により）なされてもよい。
ブロック２３０では、HIPEメッセージHMは暗号文AECBを生成するためにパースされてもよく、方法２００はブロック２３２に進んでもよい。たとえば、HIPEメッセージHMは装置Aにおいて（たとえばプロセッサ１０４により）パースされてもよい。
ブロック２３２では、暗号文AECBが復号されてもよく、方法２００はブロック２３４に進んでもよい。たとえば、関数（たとえばAEC.Dec関数）を使って、認証暗号化鍵htkに基づいてHIPE暗号文HCBを復号してもよい。より具体的には、AE.Dec(htk,AECB)がAEMBを生成してもよい。たとえば、暗号文AECBは装置Aにおいて（たとえばプロセッサ１０４により）復号されてもよい。
ブロック２３４では、認証された暗号化された暗号文メッセージAEMBが有効であるかどうかについて判定がなされてもよい。認証された暗号化された暗号文メッセージAEMBが無効であれば、方法２００は終了してもよい。認証された暗号化された暗号文メッセージAEMBが有効であれば、方法２００はブロック２３６に進んでもよい。たとえば、認証された暗号化された暗号文メッセージAEMBが有効であるかどうかについての判定は、装置Aにおいて（たとえばプロセッサ１０４により）実行されてもよい。
ブロック２３６では、暗号文AEMBがすべての必要とされるデータを含んでいるかどうかを判定するために、認証された暗号化された暗号文メッセージAEMBがパースされてもよく、方法２００はブロック２３８に進んでもよい。たとえば、認証された暗号化された暗号文メッセージAEMBは装置Aにおいて（たとえばプロセッサ１０４により）、暗号文AEMBがセッション識別子sid、公開鍵MB、識別子IDBおよび署名σBを含んでいるかどうかを判定するために、パースされてもよい。
ブロック２３８では、署名σBが有効な署名であるかどうかについて判定がなされてもよい。署名σBが有効な署名ではないと判定される場合には、方法２００は終了してもよい。署名σBが有効な署名であると判定される場合には、方法２００はブロック２４０に進んでもよい。たとえば、署名σBが有効な署名であるかどうかについての判定は、装置Aにおいて（たとえばプロセッサ１０４により）実行されてもよい。
ブロック２４０では、装置Aについての署名が生成されてもよく、方法２００はブロック２４２に進んでもよい。たとえば、関数（たとえばSign関数）が、セッション識別子sid、識別子IDA、公開鍵MAおよび公開鍵MBに基づいて署名を生成してもよい。より具体的には、SignA(sid,IDA,MA,MB)が署名σAを生成してもよい。たとえば、署名σAは装置Aにおいて（たとえばプロセッサ１０４により）生成されてもよい。
ブロック２４２では、認証された暗号化された暗号文が生成されてもよく、方法２００はブロック２４４に進んでもよい。たとえば、（たとえばAE.Enc関数）が、認証暗号化鍵htk、識別子IDAおよび署名σAに基づいて、認証された暗号化された暗号文AECAを生成してもよい。より具体的には、AE.Enc(htk,(IDA,σA))が認証された暗号化された暗号文AECAを生成してもよい。たとえば、認証された暗号化された暗号文AECAは装置Aにおいて（たとえばプロセッサ１０４により）生成されてもよい。
ブロック２４４では、認証された暗号化された暗号文AECAを含むデータが送信されてもよく、方法２００はブロック２４６に進んでもよい。たとえば、認証された暗号化された暗号文AECAを含むことに加えて、前記データは、セッション識別子sidをも含んでいてもよい。より具体的には、たとえば、認証された暗号化された暗号文AECAを含むメッセージが装置Aから装置Bに送信されてもよい。
ブロック２４６では、セッション鍵が生成されてもよい。たとえば、鍵導出関数（たとえばKDF関数）がセッション鍵skAを入力として受け取って、別のセッション鍵SKAを出力してもよい。より具体的には、たとえば、セッション鍵は装置Aにおいて（たとえばプロセッサ１０４により）生成されてもよい。
図１および図２Ｅを参照するに、この例では応答者である装置Bが、AE暗号文を復号して、前記署名と、この例では開始装置である装置Aの属性とを取得することを試みてもよい。署名が有効であり、復号が成功の場合、装置Bは最終的なセッション鍵を（たとえばプロセッサ１０６により）生成してもよい。
ブロック２４８では、認証された暗号化された暗号文AECAを含むデータが受領されてもよく、方法２００はブロック２５０に進んでもよい。たとえば、装置Aから送られた、認証された暗号化された暗号文AECAを含むデータが、装置Bにおいて受領されてもよい。
ブロック２５０では、暗号文AECAが復号されてもよく、方法２００はブロック２５２に進んでもよい。たとえば、関数（たとえばAE.Dec関数）を使って、認証暗号化鍵htkに基づいて暗号文AECAを復号して、認証された暗号化された暗号文メッセージAEMBを生成してもよい。より具体的には、たとえば、AE.Dec(htk,AECA)が、認証された暗号化された暗号文メッセージAEMBを生成してもよい。たとえば、暗号文AECAは装置Bにおいて（たとえばプロセッサ１０６により）復号されてもよい。
ブロック２５２では、認証された暗号化された暗号文メッセージAEMBが有効であるかどうかについて判定がなされてもよい。認証された暗号化された暗号文メッセージAEMBが無効であれば、方法２００は終了してもよい。認証された暗号化された暗号文メッセージAEMBが有効であれば、方法２００はブロック２５４に進んでもよい。たとえば、認証された暗号化された暗号文メッセージAEMBが有効であるかどうかについての判定は、装置Bにおいて（たとえばプロセッサ１０６により）なされてもよい。
ブロック２５４では、認証された暗号化された暗号文メッセージAEMBがすべての必要とされるデータを含んでいるかどうかを判定するために、認証された暗号化された暗号文メッセージAEMBがパースされてもよく、方法２００はブロック２５６に進んでもよい。たとえば、認証された暗号化された暗号文メッセージAEMBが識別子IDAおよび署名σAを含んでいるかどうかを判定するために、認証された暗号化された暗号文メッセージAEMBがパースされてもよい。たとえば、認証された暗号化された暗号文メッセージAEMBは装置Bにおいて（たとえばプロセッサ１０６により）パースされてもよい。
ブロック２５６では、署名σAが有効な署名であるかどうかについて判定がなされてもよい。署名σAが有効な署名でないと判定される場合、方法２００は終了してもよい。署名σAが有効な署名であると判定される場合、方法２００はブロック２５８に進んでもよい。たとえば、署名σAが有効な署名であるかどうかについての判定は、装置Bにおいて（たとえばプロセッサ１０６により）なされてもよい。
ブロック２５８では、セッション鍵が生成されてもよい。たとえば、鍵導出関数（たとえばKDF関数）がセッション鍵skBを入力として受け取って、別のセッション鍵SKBを出力してもよい。より具体的には、たとえば、セッション鍵は装置Bにおいて（たとえばプロセッサ１０６により）生成されてもよい。
さまざまな実施形態によれば、セッション鍵SKAおよびセッション鍵SKBが、暗号化されたメッセージを交換するために、装置Aおよび装置Bによって使われてもよい。
本開示の範囲から外れることなく、方法２００に対して修正、追加または省略がなされてもよい。たとえば、方法２００の動作は異なる順序で実装されてもよい。さらに、概説された動作およびアクションは例として与えられているだけであって、開示される実施形態の本質を損なうことなく、動作およびアクションの一部は任意的であったり、より少数の動作およびアクションに組み合わされたり、あるいは追加的な動作およびアクションに展開されたりしてもよい。
上記のように、従来のシステムとは対照的に、本開示のさまざまな実施形態は、一つまたは複数の基礎になる暗号学的ツールを適正にインスタンス化することを通じて、耐量子計算機のセキュリティーを提供しうる。たとえば、格子ベースの構築をもつHIPE方式および格子ベースのニューホープ・シンプル鍵交換をもつ正準的な鍵交換をインスタンス化することを通じて、耐量子計算機のセキュリティーが提供されうる。
さらに、いくつかの実施形態では、サーバー装置の許諾ポリシーを満たすクライアント装置が、サーバーの素性を判別しうる。サーバー装置の、その属性を含む素性およびその署名が両方とも、階層的内積述語暗号化（hierarchical inner-product predicate encryption）方式を使って暗号化されて送られるからである。同様に、クライアント装置は、サーバーの属性がクライアントの許諾ポリシーを満たすことを検証した後に、その素性をサーバー装置に明かしてもよい。しかしながら、上記のように、サーバー装置の許諾ポリシーを満たす誠実なクライアント装置は、サーバー装置に関連付けられた属性を判別しうる。
いくつかの実施形態では、誠実なクライアントでさえ、サーバー装置によって使用されるポリシーを判別することができなくてもよい。基礎になる階層的内積述語暗号化方式が、サーバーによって使用される許諾ポリシーを隠しうるからである。より具体的には、HIPE暗号文を復号成功することによって、クライアントによって判別される情報が、クライアントがサーバーの許諾ポリシーを満たしていることを知ることに制限されうる。さらに、いくつかの許諾ポリシーが選言、多項式、CNF/DNF公式および／または任意のブール公式の評価に対応してもよい。
図３は、本開示の少なくとも一つの実施形態に基づく例示的なコンピューティング装置３００のブロック図である。たとえば、図１の装置Aおよび／または装置Bがコンピューティング装置３００として実装されてもよい。コンピューティング装置３００は、デスクトップ・コンピュータ、ラップトップ・コンピュータ、サーバー・コンピュータ、タブレット・コンピュータ、携帯電話、スマートフォン、携帯情報端末（PDA）、電子書籍リーダー装置、ネットワーク・スイッチ、ネットワーク・ルーター、ネットワーク・ハブ、他のネットワーキング装置または他の好適なコンピューティング装置を含んでいてもよい。
コンピューティング装置３００は、プロセッサ３１０、記憶装置３２０、メモリ３３０および通信装置３4０を含んでいてもよい。プロセッサ３１０、記憶装置３２０、メモリ３３０および／または通信装置３4０はみな、各コンポーネントが他のコンポーネントと通信しうるよう、通信上結合されていてもよい。コンピューティング装置３００は、本開示において記述される動作の任意のものを実行しうる。
一般に、プロセッサ１０４および／またはプロセッサ１０６（図１参照）を含んでいてもよいプロセッサ３１０は、さまざまなコンピュータ・ハードウェアまたはソフトウェア・モジュールを含むいかなる好適な専用または汎用コンピュータ、コンピューティング・エンティティまたは処理装置を含んでいてもよく、いかなる適用可能なコンピュータ可読記憶媒体上に記憶された命令を実行するよう構成されていてもよい。たとえば、プロセッサ３１０はマイクロプロセッサ、マイクロコントローラ、デジタル信号プロセッサ（DSP）、特定用途向け集積回路（ASIC）、フィールドプログラマブルゲートアレイ（FPGA）またはプログラム命令をインタープリットおよび／または実行するおよび／またはデータを処理するよう構成された他の任意のデジタルもしくはアナログ回路を含んでいてもよい。図３では単一のプロセッサとして示されているが、プロセッサ３１０は、本開示に記載される任意の数の動作を個々にまたは集団的に実行するよう構成された任意の数のプロセッサを含んでいてもよい。
いくつかの実施形態では、プロセッサ３１０は、プログラム命令をインタープリットおよび／または実行するおよび／または記憶装置３２０、メモリ３３０または記憶装置３２０とメモリ３３０に記憶されたデータを処理することを行なってもよい。いくつかの実施形態では、プロセッサ３１０は記憶装置３２０からプログラム命令を取ってきて、該プログラム命令をメモリ３３０にロードしてもよい。プログラム命令がメモリ３３０にロードされた後、プロセッサ３１０はプログラム命令を実行してもよい。
たとえば、いくつかの実施形態において、装置（たとえばクライアント、サーバーなど）の処理動作の一つまたは複数がデータ記憶３２０にプログラム命令として含められてもよい。プロセッサ３１０は、前記処理動作のうち一つまたは複数の前記プログラム命令を取ってきて、前記処理動作の前記プログラム命令をメモリ３３０にロードしてもよい。前記処理動作のプログラム命令がメモリ３３０にロードされた後、プロセッサ３１０はプログラム命令を実行してもよく、それによりコンピューティング装置３００はプログラム命令によって指令されるように、前記処理動作に関連する動作を実装しうる。
記憶装置３２０およびメモリ３３０は、コンピュータ実行可能な命令またはデータ構造を担持するまたは記憶するコンピュータ可読記憶媒体を含んでいてもよい。そのようなコンピュータ可読記憶媒体は、プロセッサ３１０のような汎用または特殊目的コンピュータによってアクセスされうるいかなる利用可能な媒体を含んでいてもよい。限定ではなく例として、そのようなコンピュータ可読記憶媒体は、RAM、ROM、EEPROM、CD-ROMまたは他の光ディスク記憶、磁気ディスク記憶または他の磁気記憶デバイス、フラッシュメモリ・デバイス（たとえば半導体メモリ・デバイス）またはコンピュータ実行可能な命令またはデータ構造の形で所望されるプログラム・コードを担持または記憶するために使用されうる、汎用または特殊目的コンピュータによってアクセスされうる他の任意の記憶媒体を含む、有体または非一時的なコンピュータ可読記憶媒体を含んでいてもよい。上記のものの組み合わせも、コンピュータ可読記憶媒体の範囲内に含まれうる。コンピュータ実行可能な命令はたとえば、プロセッサ３１０に、ある動作または動作群を実行させるよう構成された命令およびデータを含んでいてもよい。
いくつかの実施形態では、記憶装置３２０および／またはメモリ３３０は、鍵交換に関連するデータを記憶してもよい。たとえば、記憶装置３２０および／またはメモリ３３０は、関数、公開情報（たとえばパラメータ（pars）、マスター公開鍵（mpk）など）、秘密鍵、メッセージまたは鍵交換のための任意のデータを記憶してもよい。
通信装置３４０は、コンピューティング装置３００と別の電子装置との間の通信を許容するまたは容易にするよう構成された任意の装置、システム、コンポーネントまたはコンポーネントの集まりを含んでいてもよい。たとえば、通信装置３４０は、限定なしに、モデム、ネットワーク・カード（無線または有線）、赤外線通信装置、光通信装置、無線通信装置（たとえばアンテナ）および／またはチップセット（たとえばブルートゥース（登録商標）装置、802.6装置（たとえば都市圏ネットワーク（MAN））、Wi-Fi装置、WiMAX装置、セルラー通信設備など）および／またはその他を含んでいてもよい。通信装置３４０は、若干の例を挙げるとセルラー・ネットワーク、Wi-Fiネットワーク、MAN、光ネットワークなどのような任意のネットワークおよび／またはリモート装置を含め本開示に記載される他の任意の装置と、データが交換されることを許容しうる。
本開示の範囲から外れることなく、図３に修正、追加または省略がなされてもよい。たとえば、コンピューティング装置３００は、本開示において図示され、記述されているより多数または少数の要素を含んでいてもよい。たとえば、コンピューティング装置３００は、タブレットまたは携帯電話の画面のような統合された表示装置を含んでいてもよく、あるいはコンピューティング装置３００とは別個でありコンピューティング装置３００に通信上結合されているのでもよい外部モニター、プロジェクター、テレビジョンまたは他の好適な表示装置を含んでいてもよい。
本開示での用法では、用語「モジュール」または「コンポーネント」は、該モジュールまたはコンポーネントの動作を実行するよう構成された特定のハードウェア実装および／またはたとえば装置A、装置Bおよび／または装置３００に記憶および／または実行さうれるソフトウェア・オブジェクトまたはソフトウェア・ルーチンを指しうる。いくつかの実施形態では、本稿に記載される種々のコンポーネントおよびモジュールは、（たとえば別個のスレッドとして）コンピューティング・システム上で実行されるオブジェクトまたはプロセスとして実装されてもよい。本稿に記載されるシステムおよび方法のいくつかは、一般に、（装置３００に記憶および／または実行される）ソフトウェアで実装されるものとして記述されるが、個別のハードウェア実装またはソフトウェアと個別のハードウェア実装の組み合わせも可能であり、考えられている。本稿において、「コンピューティング・エンティティ」は、本稿で定義したような任意のコンピューティング・システムまたは装置３００のようなコンピューティング・システム上で走る任意のモジュールもしくはモジュールの組み合わせでありうる。
本開示での用法では、用語「モジュール」または「コンポーネント」は、該モジュールまたはコンポーネントのアクションを実行するよう構成された特定のハードウェア実装および／またはコンピューティング・システムの汎用ハードウェア（たとえばコンピュータ可読媒体、処理装置など）に記憶および／または実行さうれるソフトウェア・オブジェクトまたはソフトウェア・ルーチンを指しうる。いくつかの実施形態では、本開示に記載される種々のコンポーネント、モジュール、エンジンおよびサービスは、（たとえば別個のスレッドとして）コンピューティング・システム上で実行されるオブジェクトまたはプロセスとして実装されてもよい。本開示に記載されるシステムおよび方法のいくつかは、一般に、（汎用ハードウェアに記憶および／または実行される）ソフトウェアで実装されるものとして記述されるが、個別のハードウェア実装またはソフトウェアと個別のハードウェア実装の組み合わせも可能であり、考えられている。本開示において、「コンピューティング・エンティティ」は、本開示で先に定義したような任意のコンピューティング・システムまたはコンピューティング・システム上で走る任意のモジュールもしくはモジュールの組み合わせでありうる。
本開示および特に付属の請求項（たとえば付属の請求項の本文）において使われる用語は一般に「オープン」な用語として意図されている（たとえば、用語「含む」は「含むがそれに限られない」と解釈されるべきであり、用語「もつ」は「少なくとも…をもつ」と解釈されるべきであり、用語「含む」は「含むがそれに限られない」と解釈されるべきであるなど）。
さらに、導入される請求項の記載の特定の数が意図される場合、そのような意図は請求項において明示的に記載される。そのような記載のない場合には、そのような意図はない。たとえば、理解の助けとして、以下の付属の請求項は、請求項の記載を導入するために「少なくとも一つの」および「一つまたは複数の」という導入句の使用を含むことがありうる。しかしながら、たとえ同じ請求項が導入句「一つまたは複数の」または「少なくとも一つの」および「a」または「an」のような不定冠詞を含むときでも、そのような句の使用は、不定冠詞「a」または「an」による請求項の記載の導入が、そのように導入された請求項の記載を含む何らかの特定の請求項を、そのような記載を一つだけ含む実施形態に限定することを含意していると解釈されるべきではない（たとえば、「a」および／または「an」は、「少なくとも一つの」または「一つまたは複数の」を意味するものと解釈されるべきである）。同じことは、請求項の記載を導入する定冠詞の使用についても成り立つ。
さらに、たとえ導入される請求項の記載の特定の数が明示的に記載されていたとしても、当業者は、そのような記載が、少なくともその記載された数を意味すると解釈されるべきであることを認識するであろう（たとえば、他の修飾語なしで単に「二つの記載」という記載は、少なくとも二つの記載または二つ以上の記載を意味する）。さらに、「Ａ、ＢおよびＣなどのうちの少なくとも一つ」または「Ａ、ＢおよびＣなどの一つまたは複数」に類似する慣用句が使われる事例においては、一般に、そのような構文はＡだけ、Ｂだけ、Ｃだけ、ＡおよびＢ両方、ＡおよびＣ両方、ＢおよびＣ両方またはＡ、ＢおよびＣ全部などを含むことが意図される。
さらに、明細書であれ請求項であれ図面であれ、二つ以上の代替的な用語を呈示するあらゆる選言的な語句は、該用語の一つを含む、該用語のいずれかを含むまたは該用語の両方を含む可能性を考えているものと理解されるべきである。たとえば、「ＡまたはＢ」という句は、「Ａ」または「Ｂ」または「ＡおよびＢ」の可能性を含むと理解されるべきである。
本開示において記載されるすべての例および条件付きの言辞は、本発明および発明者によって当技術分野の発展のために寄与される概念の理解において読者を助ける教育目的を意図されており、そのような特定的に記載される例および条件に限定することなく解釈されるものとする。本開示の実施形態について詳細に述べてきたが、本開示の精神および範囲から外れることなく、これにさまざまな変化、代替および変更をなすことができることは理解しておくべきである。
以上の実施例を含む実施形態に関し、さらに以下の付記を開示する。
（付記１）
秘密であり相互認証される鍵交換のための、一つまたは複数のプロセッサを有するシステムであって、前記一つまたは複数のプロセッサは：
第一の装置から第二の装置に、公開鍵を含む第一のメッセージを送信する段階と；
第一の装置において、前記第二の装置から送信された、階層的内積暗号化（HIPE）暗号文を含む第二のメッセージを受け取る段階と；
前記第一の装置において、前記HIPE暗号文を復号して、第一の認証付き暗号化（AE）暗号文を生成する段階と；
前記第一の装置において、前記第一のAE暗号文を復号する段階と；
前記第一の装置において、復号された第一のAE暗号文に基づいて、前記第二の装置の署名および一つまたは複数の属性を判別する段階と；
前記第一の装置において、前記第一の装置の署名および一つまたは複数の属性を含む第二のAE暗号文を生成する段階と；
前記第一の装置から前記第二の装置に、前記第二のAE暗号文を含む第三のメッセージを送信する段階とを実行するよう構成されている、
システム。
（付記２）
前記一つまたは複数のプロセッサがさらに、前記第一の装置の一つまたは複数の属性の、信頼されるサードパーティー（TTP）による検証に基づいて、前記第一の装置のための秘密復号鍵を前記第一の装置において生成するよう構成されている、付記１記載のシステム。
（付記３）
前記一つまたは複数のプロセッサが、HIPEに関連するマスター公開鍵および前記秘密復号鍵に基づいて、前記第一の装置において前記HIPE暗号文を復号するよう構成されている、付記２記載のシステム。
（付記４）
前記TTPが前記第一の装置および組織の一方を含む、付記２記載のシステム。
（付記５）
前記一つまたは複数のプロセッサがさらに：
前記第二のメッセージに基づいて前記第一の装置のためのセッション鍵を生成し；
前記セッション鍵に基づいてAE鍵を生成するよう構成されている、
付記１記載のシステム。
（付記６）
前記一つまたは複数のプロセッサがさらに、前記第一の装置の前記一つまたは複数の属性、前記第一のメッセージおよび前記第二のメッセージのうちの少なくとも一つに基づいて、前記第一の装置において、前記第一の装置の署名を生成するよう構成されている、付記１記載のシステム。
（付記７）
HIPEが格子ベースのHIPEである、付記１記載のシステム。
（付記８）
秘密の相互認証される鍵交換の方法であって：
第一の装置から第二の装置に、公開鍵を含む第一のメッセージを送信する段階と；
前記第一の装置において、第二の装置から送信された、階層的内積暗号化（HIPE）暗号文を含む第二のメッセージを受け取る段階と；
前記第一の装置において、前記HIPE暗号文を復号して、第一の認証付き暗号化（AE）暗号文を生成する段階と；
前記第一の装置において、前記第一のAE暗号文を復号する段階と；
前記第一の装置において、復号された第一のAE暗号文に基づいて、前記第二の装置の署名および一つまたは複数の属性を判別する段階と；
前記第一の装置において、前記第一の装置の署名および一つまたは複数の属性を含む第二のAE暗号文を生成する段階と；
前記第一の装置から前記第二の装置に、前記第二のAE暗号文を含む第三のメッセージを送信する段階とを含む、
方法。
（付記９）
前記第二の装置から受信された前記第二のメッセージに基づいて、前記第一の装置においてセッション鍵を生成し；
前記セッション鍵に基づいて、前記第一の装置においてAE鍵を生成することをさらに含む、
付記８記載の方法。
（付記１０）
前記第二の装置の署名が有効な署名であるかどうかを前記第一の装置において検証することをさらに含む、付記８記載の方法。
（付記１１）
信頼されるサードパーティー（TTP）に秘密復号鍵を要求し；
前記秘密復号鍵を前記第一の装置において受け取ることをさらに含む、
付記８記載の方法。
（付記１２）
前記HIPE暗号文を復号することが、前記HIPE暗号文に関連するマスター公開鍵および前記秘密復号鍵に基づいて前記HIPE暗号文を復号することを含む、付記１１記載の方法。
（付記１３）
前記秘密復号鍵を要求することが、前記第一の装置および第三の装置の一方に秘密復号鍵を要求することの一方を含む、付記１１記載の方法。
（付記１４）
前記第一の装置の前記一つまたは複数の属性、前記第一のメッセージおよび前記第二のメッセージのうちの少なくとも一つに基づいて、前記第一の装置において、前記第一の装置の署名を生成することをさらに含む、付記８記載の方法。
（付記１５）
処理装置によって実行可能なコンピュータ命令が記憶されている非一時的なコンピュータ可読媒体であって、前記命令は：
第一の装置から第二の装置に、公開鍵を含む第一のメッセージを送信する段階と；
前記第一の装置において、前記第二の装置からの、階層的内積暗号化（HIPE）暗号文を含む第二のメッセージを受け取る段階と；
前記第一の装置において、前記HIPE暗号文を復号して、第一の認証付き暗号化（AE）暗号文を生成する段階と；
前記第一の装置において、前記第一のAE暗号文を復号する段階と；
前記第一の装置において、復号された第一のAE暗号文に基づいて、前記第二の装置の署名および一つまたは複数の属性を判別する段階と；
前記第一の装置において、前記第一の装置の署名および一つまたは複数の属性を含む第二のAE暗号文を生成する段階と；
前記第一の装置から前記第二の装置に、前記第二のAE暗号文を含む第三のメッセージを送信する段階とを含む動作を実行するまたは該動作の実行を制御するためのものである、
非一時的なコンピュータ可読媒体。
（付記１６）
前記動作が：
信頼されるサードパーティー（TTP）に秘密復号鍵を要求し；
前記秘密復号鍵を前記第一の装置において受け取ることをさらに含む、
付記１５記載の非一時的なコンピュータ可読媒体。
（付記１７）
前記HIPE暗号文を復号することが、HIPEに関連するマスター公開鍵および前記秘密復号鍵に基づいて前記HIPE暗号文を復号することを含む、付記１６記載の非一時的なコンピュータ可読媒体。
（付記１８）
前記動作がさらに、前記第二の装置の署名が有効な署名であるかどうかを前記第一の装置において検証することを含む、付記１５記載の非一時的なコンピュータ可読媒体。
（付記１９）
前記動作がさらに、前記第一の装置の前記一つまたは複数の属性、前記第一のメッセージおよび前記第二のメッセージのうちの少なくとも一つに基づいて、前記第一の装置において、前記第一の装置の署名を生成することを含む、付記１５記載の非一時的なコンピュータ可読媒体。
（付記２０）
前記第一のAE暗号文を復号することが、前記第二のメッセージに基づいて生成されたAE鍵に基づいて前記第一のAE暗号文を復号することを含む、付記１５記載の非一時的なコンピュータ可読媒体。
２０２ メッセージおよび秘密状態を生成
２０４ セッション識別子および前記メッセージを含むデータを送信
２０５ セッション識別子および前記メッセージを含むデータを受信
２０６ メッセージおよび秘密状態を生成
２０８ セッション鍵を生成
２１０ 認証暗号化鍵を生成
２１２ 署名を生成
２１４ 認証付き暗号化の暗号文を生成
２１６ HIPEの暗号文を生成
２１８ HIPEの暗号文を含むデータを送信
２２０ HIPE暗号文を含むデータを受信
２２２ セッション鍵を生成
２２４ 認証付き暗号化の鍵を生成
２２６ HIPE暗号文を復号してHIPEメッセージ（HM）を生成
２２８ HMは有効か？
２３０ HMをパースして認証暗号化の暗号文AECBを生成
２３２ AECBを復号して、認証付き暗号化のメッセージAEMBを生成
２３４ AEMBは有効か？
２３６ AEMBをパース
２３８ 署名σBは有効な署名か？
２４０ 署名を生成
２４２ 認証付き暗号化の暗号文AECAを生成
２４４ AECAを含むデータを送信
２４６ セッション鍵を生成
２４８ 認証暗号化暗号文AECAを含むデータを受信
２５０ AE暗号文AECAを復号して認証付き暗号化のメッセージAEMBを生成
２５２ AEMBは有効か？
２５４ AEMBをパース
２５６ 署名σAは有効な署名か？
２５８ セッション鍵を生成

Claims (20)

  1. 秘密であり相互認証される鍵交換のための、一つまたは複数のプロセッサを有するシステムであって、前記一つまたは複数のプロセッサは：
    第一の装置から第二の装置に、公開鍵を含む第一のメッセージを送信する段階と；
    第一の装置において、前記第二の装置から送信された、階層的内積暗号化（HIPE）暗号文を含む第二のメッセージを受け取る段階と；
    前記第一の装置において、前記HIPE暗号文を復号して、第一の認証付き暗号化（AE）暗号文を生成する段階と；
    前記第一の装置において、前記第一のAE暗号文を復号する段階と；
    前記第一の装置において、復号された第一のAE暗号文に基づいて、前記第二の装置の署名および一つまたは複数の属性を判別する段階と；
    前記第一の装置において、前記第一の装置の署名および一つまたは複数の属性を含む第二のAE暗号文を生成する段階と；
    前記第一の装置から前記第二の装置に、前記第二のAE暗号文を含む第三のメッセージを送信する段階とを実行するよう構成されている、
    システム。
  2. 前記一つまたは複数のプロセッサがさらに、前記第一の装置の一つまたは複数の属性の、信頼されるサードパーティー（TTP）による検証に基づいて、前記第一の装置のための秘密復号鍵を前記第一の装置において生成するよう構成されている、請求項１記載のシステム。
  3. 前記一つまたは複数のプロセッサが、HIPEに関連するマスター公開鍵および前記秘密復号鍵に基づいて、前記第一の装置において前記HIPE暗号文を復号するよう構成されている、請求項２記載のシステム。
  4. 前記TTPが前記第一の装置および組織の一方を含む、請求項２記載のシステム。
  5. 前記一つまたは複数のプロセッサがさらに：
    前記第二のメッセージに基づいて前記第一の装置のためのセッション鍵を生成し；
    前記セッション鍵に基づいてAE鍵を生成するよう構成されている、
    請求項１記載のシステム。
  6. 前記一つまたは複数のプロセッサがさらに、前記第一の装置の前記一つまたは複数の属性、前記第一のメッセージおよび前記第二のメッセージのうちの少なくとも一つに基づいて、前記第一の装置において、前記第一の装置の署名を生成するよう構成されている、請求項１記載のシステム。
  7. HIPEが格子ベースのHIPEである、請求項１記載のシステム。
  8. 秘密の相互認証される鍵交換の方法であって：
    第一の装置から第二の装置に、公開鍵を含む第一のメッセージを送信する段階と；
    前記第一の装置において、第二の装置から送信された、階層的内積暗号化（HIPE）暗号文を含む第二のメッセージを受け取る段階と；
    前記第一の装置において、前記HIPE暗号文を復号して、第一の認証付き暗号化（AE）暗号文を生成する段階と；
    前記第一の装置において、前記第一のAE暗号文を復号する段階と；
    前記第一の装置において、復号された第一のAE暗号文に基づいて、前記第二の装置の署名および一つまたは複数の属性を判別する段階と；
    前記第一の装置において、前記第一の装置の署名および一つまたは複数の属性を含む第二のAE暗号文を生成する段階と；
    前記第一の装置から前記第二の装置に、前記第二のAE暗号文を含む第三のメッセージを送信する段階とを含む、
    方法。
  9. 前記第二の装置から受信された前記第二のメッセージに基づいて、前記第一の装置においてセッション鍵を生成し；
    前記セッション鍵に基づいて、前記第一の装置においてAE鍵を生成することをさらに含む、
    請求項８記載の方法。
  10. 前記第二の装置の署名が有効な署名であるかどうかを前記第一の装置において検証することをさらに含む、請求項８記載の方法。
  11. 信頼されるサードパーティー（TTP）に秘密復号鍵を要求し；
    前記秘密復号鍵を前記第一の装置において受け取ることをさらに含む、
    請求項８記載の方法。
  12. 前記HIPE暗号文を復号することが、前記HIPE暗号文に関連するマスター公開鍵および前記秘密復号鍵に基づいて前記HIPE暗号文を復号することを含む、請求項１１記載の方法。
  13. 前記秘密復号鍵を要求することが、前記第一の装置および第三の装置の一方に秘密復号鍵を要求することの一方を含む、請求項１１記載の方法。
  14. 前記第一の装置の前記一つまたは複数の属性、前記第一のメッセージおよび前記第二のメッセージのうちの少なくとも一つに基づいて、前記第一の装置において、前記第一の装置の署名を生成することをさらに含む、請求項８記載の方法。
  15. 処理装置によって実行可能なコンピュータ命令が記憶されている非一時的なコンピュータ可読媒体であって、前記命令は：
    第一の装置から第二の装置に、公開鍵を含む第一のメッセージを送信する段階と；
    前記第一の装置において、前記第二の装置からの、階層的内積暗号化（HIPE）暗号文を含む第二のメッセージを受け取る段階と；
    前記第一の装置において、前記HIPE暗号文を復号して、第一の認証付き暗号化（AE）暗号文を生成する段階と；
    前記第一の装置において、前記第一のAE暗号文を復号する段階と；
    前記第一の装置において、復号された第一のAE暗号文に基づいて、前記第二の装置の署名および一つまたは複数の属性を判別する段階と；
    前記第一の装置において、前記第一の装置の署名および一つまたは複数の属性を含む第二のAE暗号文を生成する段階と；
    前記第一の装置から前記第二の装置に、前記第二のAE暗号文を含む第三のメッセージを送信する段階とを含む動作を実行するまたは該動作の実行を制御するためのものである、
    非一時的なコンピュータ可読媒体。
  16. 前記動作が：
    信頼されるサードパーティー（TTP）に秘密復号鍵を要求し；
    前記秘密復号鍵を前記第一の装置において受け取ることをさらに含む、
    請求項１５記載の非一時的なコンピュータ可読媒体。
  17. 前記HIPE暗号文を復号することが、HIPEに関連するマスター公開鍵および前記秘密復号鍵に基づいて前記HIPE暗号文を復号することを含む、請求項１６記載の非一時的なコンピュータ可読媒体。
  18. 前記動作がさらに、前記第二の装置の署名が有効な署名であるかどうかを前記第一の装置において検証することを含む、請求項１５記載の非一時的なコンピュータ可読媒体。
  19. 前記動作がさらに、前記第一の装置の前記一つまたは複数の属性、前記第一のメッセージおよび前記第二のメッセージのうちの少なくとも一つに基づいて、前記第一の装置において、前記第一の装置の署名を生成することを含む、請求項１５記載の非一時的なコンピュータ可読媒体。
  20. 前記第一のAE暗号文を復号することが、前記第二のメッセージに基づいて生成されたAE鍵に基づいて前記第一のAE暗号文を復号することを含む、請求項１５記載の非一時的なコンピュータ可読媒体。
JP2018072089A 2017-04-05 2018-04-04 秘密かつ相互認証される鍵交換 Active JP7024563B2 (ja)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US15/480,156 US10205713B2 (en) 2017-04-05 2017-04-05 Private and mutually authenticated key exchange
US15/480,156 2017-04-05

Publications (2)

Publication Number Publication Date
JP2018182736A true JP2018182736A (ja) 2018-11-15
JP7024563B2 JP7024563B2 (ja) 2022-02-24

Family

ID=63710439

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2018072089A Active JP7024563B2 (ja) 2017-04-05 2018-04-04 秘密かつ相互認証される鍵交換

Country Status (2)

Country Link
US (1) US10205713B2 (ja)
JP (1) JP7024563B2 (ja)

Families Citing this family (15)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US11025615B2 (en) 2019-05-28 2021-06-01 Bank Of America Corporation Dynamic multi-device authentication and access control system
US10848469B1 (en) * 2019-05-28 2020-11-24 Bank Of America Corporation Dynamic multi-device authentication and access control system
KR102315632B1 (ko) * 2019-08-08 2021-10-21 한국과학기술원 신뢰 서버의 준동형 암호 기반 확장 가능한 그룹 키 생성 방법 및 시스템
US11240014B1 (en) 2019-09-10 2022-02-01 Wells Fargo Bank, N.A. Systems and methods for post-quantum cryptography optimization
US11477016B1 (en) * 2019-09-10 2022-10-18 Wells Fargo Bank, N.A. Systems and methods for post-quantum cryptography optimization
US11626983B1 (en) 2019-09-10 2023-04-11 Wells Fargo Bank, N.A. Systems and methods for post-quantum cryptography optimization
US11343270B1 (en) * 2019-09-10 2022-05-24 Wells Fargo Bank, N.A. Systems and methods for post-quantum cryptography optimization
CN110933672B (zh) * 2019-11-29 2021-11-30 华为技术有限公司 一种密钥协商方法及电子设备
CN111464289B (zh) * 2020-01-13 2021-07-27 华中科技大学 一种后量子密钥交换协议的实现方法、设备及系统
US11533175B1 (en) * 2020-01-30 2022-12-20 Wells Fargo Bank, N.A. Systems and methods for post-quantum cryptography on a smartcard
US11322050B1 (en) * 2020-01-30 2022-05-03 Wells Fargo Bank, N.A. Systems and methods for post-quantum cryptography optimization
US11838410B1 (en) 2020-01-30 2023-12-05 Wells Fargo Bank, N.A. Systems and methods for post-quantum cryptography optimization
US11449799B1 (en) 2020-01-30 2022-09-20 Wells Fargo Bank, N.A. Systems and methods for post-quantum cryptography optimization
KR102222080B1 (ko) * 2020-02-24 2021-03-04 한국전자통신연구원 양자 개체 인증 장치 및 방법
CN111935693B (zh) * 2020-08-26 2022-05-06 支付宝(杭州)信息技术有限公司 蓝牙设备连接方法和蓝牙设备

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2006171711A (ja) * 2004-12-14 2006-06-29 Microsoft Corp カースルズ−テイトペアリングに基づくデータの暗号処理
JP2012079192A (ja) * 2010-10-05 2012-04-19 Nippon Telegr & Teleph Corp <Ntt> 検索可能暗号システム、検索可能暗号方法、ストレージ装置、検索装置、及び登録者装置
JP2013217970A (ja) * 2012-04-04 2013-10-24 Nippon Telegr & Teleph Corp <Ntt> 格子問題に基づく階層型内積暗号システム，格子問題に基づく階層型内積暗号方法，装置
WO2015107641A1 (ja) * 2014-01-16 2015-07-23 三菱電機株式会社 暗号システム、鍵生成装置、再暗号化装置及びユーザ端末
JP2016134722A (ja) * 2015-01-19 2016-07-25 日本電信電話株式会社 鍵共有装置、鍵共有システム、鍵共有方法、プログラム

Family Cites Families (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20030221102A1 (en) * 2002-05-24 2003-11-27 Jakobsson Bjorn Markus Method and apparatus for performing multi-server threshold password-authenticated key exchange
JP5349261B2 (ja) * 2009-04-23 2013-11-20 三菱電機株式会社 暗号処理システム、鍵生成装置、鍵委譲装置、暗号化装置、復号装置、暗号処理方法及び暗号処理プログラム
US8577030B2 (en) * 2009-11-20 2013-11-05 Mitsubishi Electric Corporation Cryptographic processing system, key generation device, key delegation device, encryption device, decryption device, cryptographic processing method, and cryptographic processing program
JP5334873B2 (ja) * 2010-01-08 2013-11-06 三菱電機株式会社 暗号処理システム、鍵生成装置、鍵委譲装置、暗号化装置、復号装置、暗号処理方法及び暗号処理プログラム
JP5693206B2 (ja) * 2010-12-22 2015-04-01 三菱電機株式会社 暗号処理システム、鍵生成装置、暗号化装置、復号装置、暗号処理方法及び暗号処理プログラム
US8516244B2 (en) * 2011-06-10 2013-08-20 Zeutro Llc System, apparatus and method for decentralizing attribute-based encryption information
JP5677273B2 (ja) * 2011-11-18 2015-02-25 三菱電機株式会社 暗号処理システム、暗号処理方法、暗号処理プログラム及び鍵生成装置
JP5680007B2 (ja) * 2012-03-06 2015-03-04 三菱電機株式会社 暗号システム、暗号方法及び暗号プログラム
US8566601B1 (en) * 2012-09-12 2013-10-22 Zeutro Llc Systems and methods for functional encryption using a string of arbitrary length

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2006171711A (ja) * 2004-12-14 2006-06-29 Microsoft Corp カースルズ−テイトペアリングに基づくデータの暗号処理
JP2012079192A (ja) * 2010-10-05 2012-04-19 Nippon Telegr & Teleph Corp <Ntt> 検索可能暗号システム、検索可能暗号方法、ストレージ装置、検索装置、及び登録者装置
JP2013217970A (ja) * 2012-04-04 2013-10-24 Nippon Telegr & Teleph Corp <Ntt> 格子問題に基づく階層型内積暗号システム，格子問題に基づく階層型内積暗号方法，装置
WO2015107641A1 (ja) * 2014-01-16 2015-07-23 三菱電機株式会社 暗号システム、鍵生成装置、再暗号化装置及びユーザ端末
JP2016134722A (ja) * 2015-01-19 2016-07-25 日本電信電話株式会社 鍵共有装置、鍵共有システム、鍵共有方法、プログラム

Also Published As

Publication number Publication date
US20180295114A1 (en) 2018-10-11
US10205713B2 (en) 2019-02-12
JP7024563B2 (ja) 2022-02-24

Similar Documents

Publication Publication Date Title
JP7024563B2 (ja) 秘密かつ相互認証される鍵交換
Sun Security and privacy protection in cloud computing: Discussions and challenges
Miao et al. Practical attribute-based multi-keyword search scheme in mobile crowdsourcing
CN109478223B (zh) 区块链实现的方法和系统
JP5562687B2 (ja) 第１のユーザによって第２のユーザに送信される通信の安全化
Barker Guideline for using cryptographic standards in the federal government: Cryptographic mechanisms
Zhou et al. TR-MABE: White-box traceable and revocable multi-authority attribute-based encryption and its applications to multi-level privacy-preserving e-healthcare cloud computing systems
US20170214664A1 (en) Secure connections for low power devices
Shen et al. Toward data privacy preservation with ciphertext update and key rotation for IoT
Odelu et al. A secure anonymity preserving authentication scheme for roaming service in global mobility networks
Zhou et al. Certificateless public key encryption with cryptographic reverse firewalls
Trivedi et al. Design of secure authentication protocol for dynamic user addition in distributed Internet-of-Things
Zheng et al. An adaptive access control scheme based on trust degrees for edge computing
Wang et al. A blockchain-based conditional privacy-preserving authentication scheme for edge computing services
Nikooghadam et al. HAKECC: Highly efficient authentication and key agreement scheme based on ECDH for RFID in IOT environment
Whelihan et al. Shamrock: a synthesizable high assurance cryptography and key management coprocessor
Shi et al. Secure obfuscation for encrypted group signatures
KR102400260B1 (ko) 속성 기반 접근 제어를 이용하는 엣지 컴퓨팅 기반의 차량-내 통신 시스템 및 그 방법
Deng et al. Group public key encryption with equality test under standard model
CN106230595B (zh) 一种可信平台控制模块的授权协议
Yoo et al. Confidential information protection system for mobile devices
Yan et al. Research on data access scheme based on attribute-based encryption in blockchain environment
Basavarajegowda et al. Enhanced CP-ABE with RSA for Secure and Revocable Data Transmission of Big Data in Cloud.
Touati Grouping-proofs based access control using kp-abe for iot applications
Elganzoury et al. A Provably Secure Android-Based Mobile Banking Protocol

Legal Events

Date Code Title Description
A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20210113

A977 Report on retrieval

Free format text: JAPANESE INTERMEDIATE CODE: A971007

Effective date: 20210915

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20210928

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20211015

TRDD Decision of grant or rejection written
A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

Effective date: 20220111

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20220124

R150 Certificate of patent or registration of utility model

Ref document number: 7024563

Country of ref document: JP

Free format text: JAPANESE INTERMEDIATE CODE: R150