JP6670395B2 - 身元情報ベース鍵素材及び証明書の配布のためのシステム及び方法 - Google Patents

身元情報ベース鍵素材及び証明書の配布のためのシステム及び方法 Download PDF

Info

Publication number
JP6670395B2
JP6670395B2 JP2018551282A JP2018551282A JP6670395B2 JP 6670395 B2 JP6670395 B2 JP 6670395B2 JP 2018551282 A JP2018551282 A JP 2018551282A JP 2018551282 A JP2018551282 A JP 2018551282A JP 6670395 B2 JP6670395 B2 JP 6670395B2
Authority
JP
Japan
Prior art keywords
key
certificate
network node
unit
certification authority
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.)
Active
Application number
JP2018551282A
Other languages
English (en)
Other versions
JP2019514269A (ja
Inventor
モーション オスカー ガルシア
モーション オスカー ガルシア
ロナルド リートマン
ロナルド リートマン
ルドヴィクス マリヌス ジェラルダス マリア トルフィツェン
ルドヴィクス マリヌス ジェラルダス マリア トルフィツェン
マールテン ペーター ボドラエンデル
マールテン ペーター ボドラエンデル
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.)
Koninklijke Philips NV
Original Assignee
Koninklijke Philips NV
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 Koninklijke Philips NV filed Critical Koninklijke Philips NV
Publication of JP2019514269A publication Critical patent/JP2019514269A/ja
Application granted granted Critical
Publication of JP6670395B2 publication Critical patent/JP6670395B2/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
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3263—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving certificates, e.g. public key certificate [PKC] or attribute certificate [AC]; Public key infrastructure [PKI] arrangements
    • H04L9/3268—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving certificates, e.g. public key certificate [PKC] or attribute certificate [AC]; Public key infrastructure [PKI] arrangements using certificate validation, registration, distribution or revocation, e.g. certificate revocation list [CRL]
    • 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/0819—Key transport or distribution, i.e. key establishment techniques where one party creates or otherwise obtains a secret value, and securely transfers it to the other(s)
    • H04L9/0825—Key transport or distribution, i.e. key establishment techniques where one party creates or otherwise obtains a secret value, and securely transfers it to the other(s) using asymmetric-key encryption or public key infrastructure [PKI], e.g. key signature or public key certificates
    • 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/0819—Key transport or distribution, i.e. key establishment techniques where one party creates or otherwise obtains a secret value, and securely transfers it to the other(s)
    • H04L9/083—Key transport or distribution, i.e. key establishment techniques where one party creates or otherwise obtains a secret value, and securely transfers it to the other(s) involving central third party, e.g. key distribution center [KDC] or trusted third party [TTP]
    • 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/0847—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 identity based encryption [IBE] schemes
    • 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/0894—Escrow, recovery or storing of secret information, e.g. secret key escrow or cryptographic key storage
    • 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/30—Public key, i.e. encryption algorithm being computationally infeasible to invert or user's encryption keys not requiring secrecy
    • H04L9/3066—Public key, i.e. encryption algorithm being computationally infeasible to invert or user's encryption keys not requiring secrecy involving algebraic varieties, e.g. elliptic or hyper-elliptic curves
    • H04L9/3073—Public key, i.e. encryption algorithm being computationally infeasible to invert or user's encryption keys not requiring secrecy involving algebraic varieties, e.g. elliptic or hyper-elliptic curves involving pairings, e.g. identity based encryption [IBE], bilinear mappings or bilinear pairings, e.g. Weil or Tate pairing
    • 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/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3236—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using cryptographic hash functions
    • H04L9/3242—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using cryptographic hash functions involving keyed hash functions, e.g. message authentication codes [MACs], CBC-MAC or HMAC
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L2209/00—Additional information or applications relating to cryptographic mechanisms or cryptographic arrangements for secret or secure communication H04L9/00
    • H04L2209/80—Wireless
    • H04L2209/805—Lightweight hardware, e.g. radio-frequency identification [RFID] or sensor

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Theoretical 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)
  • Power Engineering (AREA)
  • Computing Systems (AREA)
  • Storage Device Security (AREA)

Description

本発明は、暗号システム、ネットワーク・ノード、証明機関デバイス、ネットワーク・ノードの方法、証明機関の方法、コンピュータ・プログラム、及びコンピュータ可読媒体に関する。
現在の多くの暗号インフラストラクチャにおいて、いわゆる証明書が使用される。普及している１つの証明書システムは、ＲＦＣ５２８０に記載されるような、Ｘ．５０９証明書を用いる。Ｘ．５０９体系では、証明書は公開鍵及び公開鍵の所有者に関する情報を収める。公開鍵の所有者は対応する秘密鍵も有する。公開鍵及び秘密鍵は、例えば、暗号化又は署名化等といった、非対称暗号方式で使用するためのキー・ペアを互いに形成する。
Ｘ．５０９では証明機関が証明書に署名する。その後、証明書が使用されると、署名が検証されることが可能になる。署名の検証は、証明機関が公開鍵と他の情報の組合せを証明したことを立証する。
証明書はいくつかのタイプのセキュア通信では、至る所にあるものになってきた。例えばＸ．５０９証明書はｈｔｔｐｓプロトコルでは、ウェブサイトの乗っ取りに対抗して使用される。残念ながら証明書は、いくつかのアプリケーションには、証明書をあまり適さないものにするという、いくつかの欠点も持つ。
署名された証明書はかなり大きくなることがある。例えば、１０２４ビットＲＳＡキーを使用する典型的なＸ．５０９証明書は、約１キロバイトになることがある。２０４８ビット・キーに対する証明書のサイズは、さらにかなり大きい。これは、通信のオーバヘッドが小さくなければならないネットワークには、証明書をあまり適さないものにする。例えば、モノのインターネット、センサ・ネットワーク等では、通信のオーバヘッドは最小化されるのが好ましい。さらに、受け取られた証明書上の署名は検証されなければならないので、証明書の使用には、証明書のセットアップ中だけでなく通常の使用中も、かなり十分な計算能力を要する。ＲＳＡ及び同様のものなどの非対称暗号法は典型的には大きい数の計算を要し、これには、低リソースのデバイス上の通常の通信にとって、長い時間が掛かり過ぎる。
したがってこれらの問題、及び本明細書で提示されるような他の問題に対処したいという要望がある。
証明書を配布し、検証するための改善された方式を有することが有利である。特許請求の範囲において説明されるような暗号システムが提供され、この中で証明書は検証可能になるように署名される必要はない。証明書とは別に、ネットワーク・ノードは、ルート鍵素材及び識別子に対して、身元情報ベース鍵事前配布方式のローカル鍵素材生成アルゴリズムを適用することによって生成された、ネットワーク・ノードに固有のローカル鍵素材を受け取る。本明細書に記述されるように、身元情報ベース鍵事前配布方式は、ユーザの身元情報に基づく共有鍵の鍵合意（ｋｅｙ ａｇｒｅｅｍｅｎｔ）を可能にする。身元情報は証明書から取得される。
ネットワーク・ノードＢによって検証されることをネットワーク・ノードＡが望むパラメータは、Ａの識別子に埋め込まれるので、暗黙的証明及び検証はこのようにして実現される。例えばＡの識別子は、証明書のハッシュ関数として計算される。
証明書が明示的に署名されなくても、ネットワーク・ノードは、共有鍵を使用する通信に参加できることによってその信憑性を立証する。このようにして認証は、署名の受動的検証ではなく、２つのノード間のメッセージの能動的交換を通じて行われる。認証は、２つの当事者間の手順を伴うが、証明書上に署名を含む必要がないという長所がオーバヘッドを低減させる。その上、多くのアプリケーションでは、いずれにしてもネットワークは、認証が組み合わされるネットワーク通信に従事する。
実施形態において、ネットワーク・ノードは、複数の証明機関からローカル鍵素材を受け取る。このローカル鍵素材は、ネットワーク・ノードによって組み合わされる。したがって、証明機関デバイスがハッキングされても、ネットワーク・ノードのローカル鍵素材は直接的に危険にさらされない。
ネットワーク・ノード及び証明機関は電子デバイスである。例えば、ネットワーク・ノードは、センサ、又は例えば、携帯電話、セット・トップ・ボックス、スマート・カード、コンピュータ等といったモバイル電子デバイスである。証明機関デバイスは、コンピュータ、サーバ等である。
本発明による方法は、コンピュータに実装された方法として、コンピュータ上に、又は専用ハードウェアに、又は両方の組合せの中に実装される。本発明による方法のための実行可能コードは、コンピュータ・プログラム製品に格納される。コンピュータ・プログラム製品の例は、メモリ・デバイス、光ストレージ・デバイス、集積回路、サーバ、オンライン・ソフトウェア等を含む。コンピュータ・プログラム製品は、前記プログラム製品がコンピュータ上で実行されるときに本発明による方法を実施するための、コンピュータ可読媒体に格納された非一時的プログラム・コードを含むのが好ましい。
好ましい実施形態において、コンピュータ・プログラムは、コンピュータ・プログラムがコンピュータ上で動くときに、本発明による方法のステップすべてを実施するように適応されたコンピュータ・プログラム・コードを含む。コンピュータ・プログラムはコンピュータ可読媒体上で具体化されるのが好ましい。
本発明の別の態様は、コンピュータ・プログラムをダウンロードできるようにする方法を提供する。この態様は、コンピュータ・プログラムが、例えば、Ａｐｐｌｅ社の Ａｐｐ Ｓｔｏｒｅ、Ｇｏｏｇｌｅ社の Ｐｌａｙ Ｓｔｏｒｅ、又はＭｉｃｒｏｓｏｆｔ社の Ｗｉｎｄｏｗｓ Ｓｔｏｒｅにアップロードされるとき、及びコンピュータ・プログラムが、このようなストアからのダウンロードに利用できるときに使用される。
本発明のさらなる詳細、態様、及び実施形態は、図面を参照しながら、ほんの一例として説明される。図中の要素は簡潔さ及び明瞭さのために示され、必ずしも規模を変更するように描かれていない。図では、既に説明された要素に対応する要素は同じ参照番号を有する。
暗号システム１００の実施形態の例を概略的に示す図である。 暗号システム１０１の実施形態の例を概略的に示す図である。 証明書を配布する実施形態の例を概略的に示す図である。 証明書を使用する実施形態の例を概略的に示す図である。 証明書を使用する実施形態の例を概略的に示す図である。 実施形態による、コンピュータ・プログラムを含む書込み可能な部分を有するコンピュータ可読媒体を概略的に示す図である。 実施形態による、プロセッサ・システムの描写を概略的に示す図である。
本発明は多くの形で具体化することが可能だが、本開示は本発明の諸原理の例示と見なされるべきであり、示され、説明される特定の実施形態に本発明を限定することを意図するものではないという理解の下で、１つ又は複数の特定の実施形態が図面の中に示され、本明細書で詳細に説明される。
以下において、理解のために、動作中の実施形態の要素が説明される。しかし、個々の要素によって行われるものとして説明される機能を行うように、個々の要素が配置されるということが明白であろう。
さらに、本発明は実施形態に限定されず、本発明は、本明細書で説明された、又は様々な従属請求項に相互に列挙された、それぞれの及びあらゆる斬新な特徴、又は特徴の組合せの中にある。
現在の公開鍵インフラストラクチャは、証明書を発行する証明機関を信頼する。例えばクライアントとサーバ、例えば２つのセンサ・ノード等といった、２つのネットワーク・ノードが通信することを望むとき、これらのノードは、これらのノードの公開鍵を収めるこれらのノードの証明書を交換する。このようにして、これらのノードは、公開鍵を相互に検証し、これらのノードの公開鍵及び秘密鍵を使用する共有鍵について合意することができる。例えば、２つのネットワーク・ノードによってアクセスできる共通の秘密といった、共有鍵は、将来、クライアントとサーバとの間で送られるメッセージを暗号化し、認証するために使用される。
しかしリソースの制約により、例えばワイヤレス・センサ・ネットワークにおいて鍵合意を実現することは簡単ではない。例えば、公開鍵ベースの方式は、例えば、センサ・ノードの限られた計算能力のためにワイヤレス・センサ・ネットワークには適していない。
いわゆる身元情報ベース鍵事前配布方式は、鍵合意を簡素化できる方式を提供する。身元情報ベース鍵事前配布方式は、鍵事前配布及び鍵導出という２つのフェーズを有する。ローカル鍵素材生成アルゴリズム及び鍵確立アルゴリズムという２つのアルゴリズムがそれぞれ、身元情報ベース鍵事前配布方式の２つのフェーズと関連付けられる。
身元情報ベース鍵事前配布方式は、例えば証明機関といった信頼できる第３の当事者に、ルート鍵素材を提供することによってセットアップされる。鍵事前配布中、ローカル鍵素材は、ルート鍵素材及びそれぞれのネットワーク・ノードの識別子に対してローカル鍵素材生成アルゴリズムを適用することによって、それぞれのネットワーク・ノードに対して生成され、ネットワーク・ノードに格納される。鍵導出フェーズ中、２つのネットワーク・ノードは、これらのノードのローカル鍵素材、及び他のネットワーク・ノードの識別子に対して鍵確立アルゴリズムを適用することによって共有鍵を導出する。例えば、第１のネットワーク・ノードは、第２のネットワーク・ノードの第２の識別子、及び第１のネットワーク・ノード自体の第１のローカル鍵素材に対して鍵確立アルゴリズムを適用し、一方、第２のネットワーク・ノードは、第１のネットワーク・ノードの第１の識別子、及び第２のネットワーク・ノードの第２のローカル鍵素材に対して鍵確立アルゴリズムを適用する。鍵確立アルゴリズムの結果は、２つのネットワーク・ノード間で共有される身元情報ベース鍵である。
いくつかの身元情報ベース鍵事前配布方式が存在する。例えば、身元情報ベース鍵事前配布方式は、Ｏｓｃａｒ Ｇａｒｃｉａ−Ｍｏｒｃｈｏｎ、Ｄｏｍｉｎｇｏ Ｇｏｍｅｚ−Ｐｅｒｅｚ、Ｊａｉｍｅ Ｇｕｔｉｅｒｒｅｚ、Ｒｏｎａｌｄ Ｒｉｅｔｍａｎ、Ｂｅｒｒｙ Ｓｃｈｏｅｎｍａｋｅｒｓ、及びＬｕｄｏ Ｔｏｌｈｕｉｚｅｎによる、「ＨＩＭＭＯ−Ａ ｌｉｇｈｔｗｅｉｇｈｔ ｃｏｌｌｕｓｉｏｎ−ｒｅｓｉｓｔａｎｔ ｋｅｙ ｐｒｅｄｉｓｔｒｉｂｕｔｉｏｎ ｓｃｈｅｍｅ」の中に記述される。Ｃｒｙｐｔｏｌｏｇｙ ｅＰｒｉｎｔ Ａｒｃｈｉｖｅ内にＲｅｐｏｒｔ２０１４／６９８が刊行されている。ＨＩＭＭＯの改良版は、同じ出願人の代理人整理番号２０１５ＰＦ０１７２５号の、出願番号第ＥＰ１５２００８５７．９号の、２０１５年１２月１７日にＥＰＯに出願された欧州特許出願「Ｉｍｐｒｏｖｅｄ ｓｙｓｔｅｍ ｆｏｒ ｋｅｙ ｓｈａｒｉｎｇ」の中に記述され、参照により組み込まれる。ＨＩＭＭＯには、他のいくつかの身元情報ベース鍵配布方式のように、時として鍵合意が失敗する、又は追加の鍵調整データ（ヘルパー・データとも呼ばれる）が共有鍵に到達するために必要とされるという、短所がある。鍵調整データは通常、例えば、第１のネットワーク・ノードが鍵合意を始めた場合、第２のネットワーク・ノードといった、両方の身元情報にアクセスできる第１のネットワーク・ノードによって生成される。
ＨＩＭＭＯは、隠蔽情報（ＨＩ：Ｈｉｄｉｎｇ Ｉｎｆｏｒｍａｔｉｏｎ）及びミキシング・モジューラ・オペレーション（ＭＭＯ：Ｍｉｘｉｎｇ Ｍｏｄｕｌａｒ Ｏｐｅｒａｔｉｏｎｓ）問題に基づく身元情報ベース鍵事前配布方式である。ＨＩＭＭＯは、すべての既存の攻撃が格子によって決まるので軽量且つより耐量子（ｑｕａｎｔｕｍ−ｓａｆｅ）的である。ＨＩＭＭＯにおいて、ＴＴＰには、例えば２変数関数Ｒ（ｘ，ｙ）といった、いくつかの秘密のルート・キーイング素材（ｋｅｙｉｎｇ ｍａｔｅｒｉａｌ）がある。ＴＴＰは、ノードＡに対する秘密関数Ｇ＿Ａ（ｘ）を、このルート・キーイング素材から抽出することができる（Ｇ＿Ａ（ｘ）＝Ｒ（Ａ，ｙ）、ここで本演算は、ＨＩＭＭＯの中に記述されるように行われる）。ＡとＢが共通の鍵を確立することを望むとき、ＡはＧ＿Ａ（ｘ＝Ｂ）を評価し、ＢはＧ＿Ｂ（ｘ＝Ａ）を評価する。
別の使用可能な身元情報ベース鍵事前配布方式は、Ｃａｒｌｏ Ｂｌｕｎｄｏらによる「Ｐｅｒｆｅｃｔｌｙ−Ｓｅｃｕｒｅ Ｋｅｙ Ｄｉｓｔｒｉｂｕｔｉｏｎ ｆｏｒ Ｄｙｎａｍｉｃ Ｃｏｎｆｅｒｅｎｃｅｓ」の中に記述される。この方式には、鍵合意が失敗することがないこと、及び鍵調整データが必要とされないことという長所がある。その一方でＢｌｕｎｄｏの方式は共謀攻撃に対抗する回復力がずっと低い。さらなる身元情報ベース鍵配布方式は、Ｓａｋａｉ−Ｏｈｇｉｓｈｉ−Ｋａｓａｈａｒａの身元情報ベースの非対話式鍵交換（ＩＤ−ＮＩＫＥ：ｉｄｅｎｔｉｔｙ−ｂａｓｅｄ ｎｏｎ−ｉｎｔｅｒａｃｔｉｖｅ ｋｅｙ ｅｘｃｈａｎｇｅ）方式である。
実施形態において、ルート鍵素材は２変数多項式を含み、ローカル鍵素材は１変数多項式を含む。例えば、Ｂｌｕｎｄｏの身元情報ベース鍵事前配布方式において、ルート鍵素材は、２変数多項式ｆ（ｘ，ｙ）によって形成される。識別子ＩＤ１に対するローカル鍵素材ｇ、及び識別子ＩＤ１を有する第１のネットワーク・ノードは、２変数多項式を１変数多項式ｇ（ｙ）＝ｆ（ＩＤ１，ｙ）に折り畳むことによって形成される。ローカル鍵素材ｇ、及び第２のネットワーク・ノードの識別子ＩＤ２を有するノードは、ｇ（ＩＤ２）を計算することによって共有鍵を取得する。すべての多項式計算は係数ｍを法として行われる。
図１ａは、暗号システム１００の実施形態の例を概略的に示す。システム１００は複数のネットワーク・ノードを備える。ネットワーク・ノード１４０、１５０、及び１６０が示される。複数のネットワーク・ノードのうち、ネットワーク・ノード１４０のさらに詳細な実施形態が示される。ネットワーク・ノード１５０及び１６０は、ネットワーク・ノード１４０と同じ実施形態を使用する。システム１００の中には２つ又は４つ以上のネットワーク・ノードがある。
システム１００は証明機関デバイス１１０をさらに備える。証明機関デバイス１１０は、複数のネットワーク・ノードに対して信頼できる当事者として振る舞う。
ネットワーク・ノード１４０は通信ユニット１４２を備え、証明機関デバイス１１０は通信ユニット１１１を備える。通信ユニットは互いに通信するように配置される。通信ユニットは、ワイヤレス若しくは有線の通信技術、又はその組合せを使用して通信する。通信ユニットはデジタル通信を使用する。例えば、通信ユニット１４２及び１１１は、Ｗｉ−Ｆｉ及び／又はイーサネット（登録商標）の通信ユニット等である。実施形態において、ネットワーク・ノード１４０と１１０との間の通信が攻撃者によって危険にさらされる可能性があるという受容されたリスクがある。攻撃者は間で通信を盗聴し、通信を変化させることさえある。
ネットワーク・ノード１４０は、公開鍵及び対応する秘密鍵を生成するように配置されたキー・ペア生成ユニット１４１を備える。公開鍵は、非対称鍵暗号方式に従って暗号化するために配置される。対応する秘密鍵は、非対称鍵暗号方式に従って復号化するために配置される。使用され得る利用可能ないくつかの公開鍵／秘密鍵方式がある。例えば、非対称鍵暗号方式はＲＳＡ又はＥｌＧａｍａｌ等である。ネットワーク・ノード１４０は、秘密鍵を使用してメッセージを復号化するように配置された復号化ユニット１４３を備える。公開鍵／秘密鍵はまた、例えば、製造中にデバイスに格納されるデバイス識別子から始めて生成される。
キー・ペア生成ユニット１４１はキー・ペアをランダムに生成するように配置される。例えば、キー・ペア生成ユニット１４１はシードを生成するように配置された乱数発生器を備える。シードは、使用される特定の非対称暗号法に従ってランダムな公開鍵及び秘密鍵を生成するための出発点として使用される。例えば、ＲＳＡが使用される場合、２つのランダムな素数がシードに基づいて選択され、公開鍵及び秘密鍵が素数から生成される。例えば、ＥｌＧａｍａｌに関して、キー・ペア生成ユニット１４１は、シードを使用する秘密鍵の一部としてランダムな秘密の指数ｘを選択し、公開鍵の一部としてこの秘密の指数から始めて指数ｇｘを計算する。
通信ユニット１４２は、キー・ペア生成ユニット１４１によって生成された公開鍵で暗号化された、身元情報ベース鍵事前配布方式のためのローカル鍵素材を証明機関デバイス１１０から受け取るように配置される。
復号化ユニット１４３は、秘密鍵で、暗号化されたローカル鍵素材を復号化するように配置される。ネットワーク・ノード１４０は、復号化ユニット１４３によって取得されたローカル鍵素材を少なくとも格納するように配置されたキー・ストレージ１４４を備える。キー・ストレージ１４４は、ネットワーク・ノード１４０の秘密鍵も格納する。キー・ストレージ１４４は、例えば不揮発性メモリ、磁気ストレージ等として実装される。実施形態において、キー・ストレージ１４４は、例えば、耐タンパ性（ｔａｍｐｅｒ ｒｅｓｉｓｔａｎｔ）メモリといった、セキュアなメモリとして実装される。
公開鍵は証明機関デバイス１１０に送られる。実施形態において、公開鍵は、ネットワーク・ノード１４０の身元情報の基礎を形成する。公開鍵に加えて、ネットワーク・ノードの通信ユニット１４２は識別情報も送る。追加情報は、例えばユーザの名前、例えばデバイスＩＤ、例えばＭＡＣアドレス又はＩＰアドレスといった例えばネットワーク・アドレスを含む。追加の識別情報は証明書の一部になり、後でシステムのユーザに見え、システムのユーザによって認証される。ネットワーク・ノード１４０は複数の公開鍵を証明機関デバイス１１０に送り、このように複数の証明書を取得する。これは機密保持上の理由から有利であり、ネットワーク・ノード１４０は、他のネットワーク・ノードによってリンクされることのない様々な身元情報を使用する。一方、ネットワーク・ノード１４０は、複数の証明書を取得するために、同じ公開鍵だが複数の追加情報を送る。さらに別の代替において、証明書は公開鍵によって全く決まらず、ネットワーク・ノード１４０は、ネットワーク・ノード１４０によって送られた追加情報に部分的に基づいて、及び／又は証明機関デバイスによって含められたさらなる情報に部分的に基づいて、１つ又は複数の証明書を取得する。これは、ネットワーク・ノード１４０の機密保持が重要な場合、やはり有利である。
ネットワーク・ノード１４０は、証明書を格納するように配置された証明書ストレージ１４５を備える。ネットワーク・ノード１４０が証明書を取得する複数の方式があり、下記を参照されたい。
証明機関デバイス１１０は、ネットワーク・ノード１４０に対して証明書を生成するように配置された証明書ユニット１１２を備える。これは、証明書が少なくともネットワーク・ノード１４０から受け取られた公開鍵を含む場合、中間者攻撃（ｍａｎ ｉｎ ｔｈｅ ｍｉｄｄｌｅ ａｔｔａｃｋｓ）を防ぐのに有利である。証明書は、ネットワーク・ノード１４０から受け取られた追加の識別情報も含む。証明書ユニット１１２は証明書にさらなる情報も追加する。例えば、証明書ユニット１１２は、証明書の有効期限、証明機関の名前等を証明書に含むように配置される。このようにして証明書は、ネットワーク・ノード１４０の公開鍵、ネットワーク・ノード１４０から受け取られた情報、及びネットワーク・ノード１４０から受け取られない情報という、３つのタイプの情報を有する。
証明機関デバイス１１０が追加情報を追加しない場合、ネットワーク・ノード１４０は証明書自体を作るように配置される。これは、証明機関デバイス１１０が証明書をネットワーク・ノード１４０に送る必要がなく、したがって帯域幅を節約すること意味する。その一方で、証明機関デバイス１１０は、証明書ユニット１１２によって作られた証明書をネットワーク・ノード１４０に送るように配置される。証明機関デバイス１１０はまた、データベースに証明書を保存するか、又は証明書を発行する。証明書は署名される必要がないことに留意されたい。実施形態において、証明機関デバイスは証明書に署名し、及び／又は追加のセキュリティのために、作成された証明書に証明書チェーンを含めるが、どちらも必要ではない。証明書ユニット１１２はデジタル構造を使用して情報を記録し、例えば、ＸＭＬ又はＡＳＮ．１などのデータ構造言語を使用する。
証明機関デバイス１１０は、身元情報形成関数を証明書に適用することによって識別子を形成するように配置された身元情報ユニット１１３を備える。例えば、身元情報形成関数は、例えばＳＨＡ−１、ＳＨＡ−２、ＲＩＰＥＭＤ等といった暗号学的ハッシュ関数である。ハッシュ関数の出力は、システム１００内の複数のノードによって生成された公開鍵の数を考慮して、必要に応じて且つ受入れ可能な場合、短縮される。識別子は少なくとも公開鍵を識別する。すなわち、複数のノード１４０〜１６０の中で使用される識別子及びすべての公開鍵を考慮して、識別子は一意の公開鍵に対応する。
証明機関デバイス１１０は、キー・ストレージ１１４及びローカル鍵素材ユニット１１５を備える。キー・ストレージ１１４は、身元情報ベース鍵事前配布方式のためのルート鍵素材を格納する。いくつかの身元情報ベース鍵事前配布方式が可能であり、上述される。ローカル鍵素材ユニット１１５は、ルート鍵素材及び識別子に対して、身元情報ベース鍵事前配布方式のローカル鍵素材生成アルゴリズムを適用することによって、ネットワーク・ノードに固有のローカル鍵素材を生成するように配置される。
公開鍵は一意の識別子に結びつき、これはこの識別子にリンクされた特定のローカル鍵素材に結びつく。証明機関デバイス１１０は、ネットワーク・ノードの公開鍵によって少なくともネットワーク・ノードに固有のローカル鍵素材を暗号化するように配置された暗号化ユニット１１６を備える。暗号化されたローカル鍵素材は、例えば通信ユニット１１１を使用してネットワーク・ノード１４０に送られる。証明機関デバイス１１０によって情報が証明書に追加されると、証明書はネットワーク・ノード１４０にも送られる。証明書は証明機関デバイス１１０によって署名される必要はないということに留意されたい。例えば、公開鍵／秘密鍵署名システムを使用して、証明機関デバイス１１０に証明書に署名させることは要求されない。実施形態において、証明機関デバイス１１０からネットワーク・ノード１４０に送られた証明書は署名されない。
証明書は、ローカル鍵素材を提供することによって、証明機関デバイスによって認証される。署名を検証する代わりに、この暗黙認証は、当事者がローカル鍵素材を有することを検証することによって検証されることが可能である。後者は、当事者が共有鍵を正しく計算できることを検証することによって確認される。例えば、ネットワーク・ノード１４０は、証明書から取得された共有鍵にネットワーク・ノード１４０がアクセスできることを立証することによって暗黙的に認証される。
例えば、第１及び第２のネットワーク・ノードが証明書を交換すると仮定する。第１及び第２のネットワーク・ノードは、証明書から第２及び第１の識別子をそれぞれ計算し、共有鍵をそれぞれ計算する。次に、第２のネットワーク・ノードが共有鍵にアクセスできることを立証する共有鍵で保護された通信を第１のネットワークが受け取ると仮定する。第１のネットワーク・ノードは、第２のネットワーク・ノードが共有鍵にアクセスできるので、共有鍵を計算するために第２の識別子に対応するローカル鍵素材を第２のネットワーク・ノードが有しているに違いないと現時点で推論できる。第２のネットワーク・ノードは、証明機関からのローカル鍵素材を受け取ることしかできず、したがって証明機関デバイスは、ローカル鍵素材を計算するために第２の識別子にアクセスできた。証明機関デバイスは、証明書から識別子を計算した。識別子がマッチするので、証明機関デバイスがローカル鍵素材を提供した証明書、すなわち証明機関デバイスが認証した証明書は、第１のネットワーク・ノードが第２のネットワーク・ノードから受け取ったものと同じである。
このようにして、必要に応じてネットワーク・ノードは、ローカル鍵素材を知っていることを立証することによってネットワーク・ノード自体を認証することができる。後者が証明書にリンクされるので、これは証明書も同様に暗黙的に認証する。証明書を配布するこのシステムは、図２を参照しながらさらに説明される。
暗号システム１００にはいくつかの長所がある。
証明書は署名される必要はなく、したがって証明書上の長い署名の問題は避けられる。このことが特に有利ないくつかの状況がある。例えば、署名を避けることは、多くのメッセージが交換され、及び／又はオーバヘッドが低減されるべきネットワークにおいて、証明書が使用され得ることを含意する。特に頻繁な、小さいメッセージを伴うネットワークにおいて、このようなオーバヘッドは問題となる。例えば、このようなオーバヘッドは、センサ・ネットワーク、又はいわゆるモノのインターネットにおいて問題となる。
例えば、２０４８ビットのＲＳＡキーが使用される場合、署名及び公開鍵はそれぞれ約２５６バイトの長さになり、証明書のサイズの約半分の署名を取り除く。量子コンピュータにアクセスできる攻撃者の存在下でさえ、システムがセキュアであることに注意しなければならないという高いセキュリティ状況下において、別の特に有利な状況が存在する。今のところ量子コンピュータは、コンピュータ通信を攻撃できるところまで進化していないが、量子コンピュータに対して攻撃が行われると、ほとんどの知られている署名アルゴリズムが脆弱であることが知られている。署名された証明書では、Ｍｅｒｋｌｅ署名方式などのいわゆる耐量子署名を使用することによってこの脅威に対処することができる。しかしＭｅｒｋｌｅ署名にはいくつかの短所があり、実際にはこの署名をあまり適切ではないようにする。例えばＭｅｒｋｌｅ署名方式は、署名化の容量が制限される１回限りの署名方式である。その上、Ｍｅｒｋｌｅ署名は、非常に長くなる傾向がある。したがって、量子の脅威に対抗するセキュリティが要求されるとき、証明書上に署名がない実施形態による証明書はこの問題を回避する。
高いセキュリティのアプリケーションに関して、非量子攻撃に対抗する署名のセキュリティは、証明機関デバイス１１０の署名鍵（秘密鍵）を使用して証明書に署名することによって、量子攻撃に対抗するセキュリティと組み合わされてよい。例えば、証明書はＲＳＡ、ＥＣＤＳＡ等によって署名されることが可能である。
証明書上に署名がないことは、中間者攻撃に手順を開放しないということに留意されたい。ネットワーク・ノード１４０と証明機関デバイス１１０との間の中間者を考える。潜在的に中間者は、公開鍵を伴う証明書を得ようとしてネットワーク・ノード１４０のリクエストを横取りすることができ、この公開鍵を、対応する秘密鍵を有する中間者の公開鍵と置き換える。証明書及び暗号化されたローカル鍵素材が証明機関から戻ると、中間者はローカル鍵素材を復号して複製を保存でき、証明書の中の公開鍵をネットワーク・ノード１４０の公開鍵と入れ替えて戻す。中間者はこのようにして、ネットワーク・ノード１４０又は証明機関デバイス１１０が気づくことなく、ローカル鍵素材の複製を取得するものと思われる。しかし、このようにして取得されたローカル鍵素材は、中間者には役に立たない。ネットワーク・ノード１４０は、身元情報ベース鍵合意方式を使用して鍵に合意することができない。ネットワーク・ノード１４０は証明書を使用して自分の身元情報を知らせる。身元情報は証明書から計算されるので、他のネットワーク・ノードは、ローカル鍵素材を計算すると、証明機関デバイスによって使用されたものとは異なる身元情報に到達する。この成果は、ネットワーク・ノードが、危険にさらされた鍵素材を使用して全く知らせることができないということである。
言い換えると、中間者はローカル鍵素材を使用してネットワーク・ノード１４０の通信を攻撃できないので、中間者がローカル鍵素材を入手するために攻撃を行ったとしてもこれは引き合わない勝利であり、なぜなら、このような通信は決して存在しないからである。発明者は、暗号システム１００を、ＨＩＭＭＯベースの方式などの、強力に共謀防止（ａｎｔｉ−ｃｏｌｌｕｓｉｏｎ）を行う身元情報ベース鍵事前配布システムと組み合わせることが有利であるという見識をもっている。ローカル鍵素材は、中間者が秘密鍵にアクセスできない公開鍵を使用して暗号化されるので、通信を改ざんすることなく盗聴するだけの中間者の攻撃もまた、うまくいかないということに留意されたい。
実施形態において、証明書ユニット１１２はノンスを生成し、識別子を形成する前に証明書にノンスを含めるように配置される。ノンスは、一度だけ使用される数字である。例えば、ノンスは、乱数、タイム・スタンプ、シリアル番号等である。ノンスは一度だけ使用されるので、証明書ユニット１１２によって生成された２つの証明書は、すべての入力情報が同じであったとしても同じではない。これには、攻撃者が公開鍵及び対応する秘密鍵を盗む場合に長所がある。この場合、攻撃者は証明機関デバイスに証明書を申請しようとし、ローカル鍵素材の新しい複製を入手することを望む。攻撃者がこれに成功すると、攻撃者によって取得され、ローカル鍵素材によって保護された以前の通信は危険にさらされる可能性がある。しかし証明書にノンスが含まれていると、これはうまくいかない。
ノード１４０、１５０、及び１６０を含む複数のネットワーク・ノードが証明書及びローカル鍵素材を提供された後、ネットワーク・ノードのうちの任意の２つは、ネットワーク・ノードのこのペアに関する固有の共有鍵に合意することができる。
図２は、例えばネットワーク・ノード１４０といったネットワーク・ノード２４０、及び例えば証明機関デバイス１１０といった証明機関デバイス２１０が、証明書を配布するためにどのように連携するかをシーケンス図の形で示す。時間は図の最上部から最下部まで垂直軸に沿って増える。手順において、必要なら普通の手順の要素が追加される。例えば、特定の手順内のメッセージは、手順のセッションを識別するためにセッションの識別子を含んでよい。このようなセッションの識別子は、例えば認証トークン等といった暗号要素にも含まれる。
ネットワーク・ノード２４０は、公開鍵及び対応する秘密鍵を生成し２４０．１、公開鍵を証明機関デバイス２１０に送る（２４０．２）。証明機関デバイス２１０は、公開鍵、場合によってはノンス、及び場合によっては他の情報を含む証明書を生成し（２１０．１）、身元情報形成関数を証明書に適用することによって識別子を形成する（２１０．２）。識別子は公開鍵及び他の情報によって決まる。証明機関デバイス２１０は次に、ルート鍵素材及び識別子に対して身元情報ベース鍵事前配布方式のローカル鍵素材生成アルゴリズムを適用することによって、ネットワーク・ノードに固有のローカル鍵素材を生成する（２１０．３）。少なくともネットワーク・ノードに固有のローカル鍵素材は、ネットワーク・ノードの公開鍵によって暗号化される（２１０．４）。実施形態において、同様に証明書は公開鍵で暗号化される。最終的に、暗号化されたローカル鍵素材は、ネットワーク・ノードに送られる（２１０．５）。任意選択で、証明書はネットワーク・ノード２４０にも送られる。
ネットワーク・ノードにおいて、送られた暗号化されたローカル鍵素材は、秘密鍵を使用して復号化され（２４０．３）、このようにしてローカル鍵素材を取得する。ローカル鍵素材、秘密鍵、及び証明書は、例えばキー・ストレージ及び証明書ストレージといった、例えばローカルなストレージに格納される（２４０．４）。
実施形態において、ネットワーク・ノード２４０と証明機関デバイス２１０との間の手順は、ここで終了される。実施形態において、さらなるステップが行われる。例えば、ネットワーク・ノード２４０及び証明機関デバイス２１０は、ネットワーク・ノード２４０が正しく提供されることをネットワーク・ノード２４０及び／又は証明機関デバイス２１０が検証できるように、チャレンジ・レスポンスの手順を実行する。例えば、証明機関デバイス２１０及びネットワーク・ノード２４０は、例えば、本明細書に記述されるような鍵合意の手順の実施形態を使用して、例えば、ネットワーク・ノード２４０と合意された共有鍵を使用して、共有鍵に合意する。共有鍵に到達するために、証明機関デバイス２４０は、証明機関デバイス２４０に対して生成された証明書及びローカル鍵素材を使用する。例えば、証明機関デバイス２４０は、これ自体に対する証明書及びローカル鍵素材を生成し、例えばこのために、これ自体のルート鍵素材を使用する。
例えば、ネットワーク・ノード１４０はノンスを選択し、ノンスを証明機関デバイス２１０に送る。証明機関デバイス２１０は、例えばノンスを暗号化するか、又は共有鍵を使用してノンスに対するＭＡＣを計算するなどして、ノンス及び共有鍵から認証トークンを作成し、トークンをネットワーク・ノード２４０に送り返す。ネットワーク・ノード２４０は、共有鍵で認証トークンを検証し、このようにしてネットワーク・ノードが正しく提供されていることを検証する。
このオペレーションは、証明機関の代わりに別のネットワーク・ノードで行われることも可能である。証明機関デバイスは、ネットワーク・ノードが正しく提供されていることを検証するために、類似のチャレンジ・レスポンスの手順を逆方向に実施することができる。
例えば、実施形態において、ネットワーク・ノード２４０及び証明機関デバイス２１０は、以下のメッセージを交換する。
１．ネットワーク・ノード２４０から証明機関デバイス２１０に、ネットワーク・ノード２４０によって選択された公開鍵及び第１のノンス。
２．証明機関デバイス２１０からネットワーク・ノード２４０に、公開鍵で暗号化されたローカル鍵素材、証明機関デバイス２１０によって選択された第２のノンス、暗号化されたローカル鍵素材に対応する証明機関デバイス２１０によって生成されたネットワーク・ノードの証明書、証明機関の証明書、証明機関デバイス２１０のネットワーク・ノードの識別子及びローカル鍵素材から取得された共有鍵、並びに必要なら証明機関デバイス２４０によって計算されたヘルパー・データで、第１のノンス（及び場合によっては第２のノンス）に対して計算された第１の認証トークン。
３．ネットワーク・ノード２４０から証明機関デバイス２１０に、第２のノンス（及び場合によっては第１のノンス）に対して計算された第２の認証トークン。第１及び第２の認証トークンは、これらが等しくなることを避けるために、異なるように計算されるべきであるということに留意されたい。
後者のステップ及び第２のノンスは、正しく提供することを証明機関が検証する必要がない場合、省略される。興味深いことに、証明機関の証明書は、証明機関デバイスよって同様に自ら生成されるローカル鍵素材と共に使用するために、証明機関デバイスによって自ら生成される。実施形態において、証明機関の証明書及びそのローカル鍵素材は、このために生成される。例えば、証明機関の証明書は、第１のノンスなどの新しいデータ（ｆｒｅｓｈｎｅｓｓ ｄａｔａ）を含む。後者は、ネットワーク・ノードに対して、全体の鍵合意が新しいことを確認する。例えば、証明機関の証明書は証明機関の名前を含む。証明機関の証明書は公開鍵を含む必要はない。
メッセージ２４０．２は、公開鍵及び情報を含む証明書リクエストである。公開鍵が署名鍵として２重の用途（例えば、ＲＳＡの暗号化及び署名化、又はＥｌＧａｍａｌの暗号化及びＥＣＤＳＡの署名化を組み合わせること）を有する場合、リクエストは、公開鍵に対応する秘密鍵によって署名される。この署名は証明機関によって検証される。リクエストには、他の認証情報又は必要に応じて証明機関による身元情報の証拠が付属する。
２４０．４までの手順の別の拡張は、複数の証明機関を使用することである。図２はさらなる証明機関デバイス２２０を示す。ネットワーク・ノード２４０は、証明書をさらなる証明機関２２０に送るように配置される。例えば、ネットワーク・ノード２４０は、証明書を自ら作るか、又は証明機関デバイス２１０から証明書を受け取る。ネットワーク・ノード２４０がローカル鍵素材を受け取り、この身元情報を定義する証明書は次に、ネットワーク・ノード２４０によってさらなる証明機関２２０に送られる。一方、さらなる証明機関２２０は、証明機関デバイス２１０から証明書を受け取る。
さらなる証明機関２２０は、以下を備える。
− 例えばネットワーク・ノード２４０又は証明機関デバイス２１０から証明書を受け取るように配置された通信ユニット。
− 身元情報形成関数を証明書に適用することによってネットワーク・ノード２４０の識別子を形成するように配置された身元情報ユニット１１３。
− 身元情報ベース鍵事前配布方式のためのルート鍵素材を格納するためのキー・ストレージ１１４。証明機関２１０及び２２０は、同じ身元情報ベース鍵事前配布方式を使用するが、証明機関２１０及び２２０のルート鍵素材は異なるものの、証明機関２１０及び２２０によって生成されたローカル鍵素材がネットワーク・ノード２４０によって組み合わされるように互換性がある。
− さらなる証明機関２２０のルート鍵素材及びネットワーク・ノード２４０の識別子に対して、身元情報ベース鍵事前配布方式のローカル鍵素材生成アルゴリズムを適用することによって、ネットワーク・ノード２４０に固有のさらなるローカル鍵素材を生成するように配置されたローカル鍵素材ユニット１１５。
さらなる証明機関２２０は、例えばネットワーク・ノードの公開鍵によって、少なくともネットワーク・ノード２４０に固有のさらなるローカル鍵素材を暗号化するように配置された暗号化ユニットを含む。暗号化ユニットは、例えば、本明細書に記述されるような鍵合意の手順の実施形態を使用して、ネットワーク・ノード３４０と合意された共有鍵を使用して、さらなるローカル鍵素材を代わりに又はさらに暗号化する。
さらなる証明機関２２０は、生成されたローカル鍵素材をネットワーク・ノード２４０に送るように配置される。ネットワーク・ノード２４０はこのようにして、さらなるローカル鍵素材を取得する。
ネットワーク・ノード２４０は、証明機関デバイスから受け取られたローカル鍵素材、及びさらなる証明機関デバイスから受け取られたさらなるローカル鍵素材を単一のローカル鍵素材に組み合わせる。組合せは、組み合わされたローカル鍵素材を取得するために、例えば、ローカル鍵素材を追加することによって、ローカル鍵素材を受け取った後に行われる。組み合わされたローカル鍵素材は、鍵合意のために使用される。組合せは、可能ではあるが、情報を受け取った後に直接的に行われる必要はない。
鍵合意に必要とされるまで鍵素材を組み合わせながら待つことには、ネットワーク・ノードがＴＴＰ（証明機関）のネゴシエーションに従事できるという長所がある。ＨＩＭＭＯでは、ローカル鍵素材は、モジュールの追加によって直接に組み合わされることが可能なので、ＨＩＭＭＯに基づく身元情報ベース鍵事前配布方式は本実施形態に特に有利である。実施形態において、２つのネットワーク・ノードは、手順の始めに、例えばハロー・メッセージの中でどの証明機関を２つのネットワーク・ノードがサポートするかを互いに知らせる。これらのノード間で生成された鍵は次に、両方のネットワーク・ノードによってサポートされる証明機関によって生成されたローカルなキーイング素材に基づく。この場合、複数の証明機関デバイスのローカルなキーイング素材は格納される。
図２は、本実施形態に対応する以下の任意選択の追加のステップを示す。ネットワーク・ノードは、証明書をさらなる証明機関デバイス２２０に送る（２４０．５）。さらなる証明機関デバイス２２０は、身元情報形成関数を証明書に適用することによって識別子を形成し（２２０．２）、ネットワーク・ノードに固有のローカル鍵素材を生成し（２２０．３）、ネットワーク・ノードの公開鍵によって少なくともネットワーク・ノードに固有のローカル鍵素材を暗号化し（２２０．４）、暗号化されたローカル鍵素材をネットワーク・ノードに送る（２２０．５）。ネットワーク・ノード２４０は、証明機関デバイスとさらなる証明機関デバイスとから受け取られたローカル鍵素材を組み合わせる。
図１ｂは、１１０、１２０、及び１３０が示される複数の証明機関、並びに１４０、１５０、及び１６０が示される複数のネットワーク・ノードを使用する暗号システム１０１の実施形態を概略的に示す。すべてのネットワーク・ノードは、少なくとも２つの異なる証明機関からローカル鍵素材を受け取る。任意選択で、ネットワーク・ノードの中には、別のノードより多くの証明機関からローカル鍵素材を受け取るものもある。後者のオプションは図１ｂに示される。
ネットワーク・ノード１４０は、証明機関１１０、１２０、及び１３０からローカル鍵素材を受け取る。ネットワーク・ノード１５０は、証明機関１１０及び１３０からローカル鍵素材を受け取る。ネットワーク・ノード１６０は、証明機関１１０及び１２０からローカル鍵素材を受け取る。
複数の証明機関からローカル鍵素材を受け取ることは、証明機関に対する攻撃に対してシステムをさらに回復力のあるものにする。すべてのネットワーク・ノードが、少なくとも１つのさらなる証明機関からのローカル鍵素材を有するので、証明機関デバイスが危険にさらされたとしても、依然としてシステムはセキュアである。ＨＩＭＭＯに関する複数のローカル鍵素材を組み合わせる例は、同じ出願人のＰＣＴ／ＥＰ２０１５／０６９３８４に示され、参照により組み込まれる。
従来の証明機関では、いくつもの証明機関によって証明するのは難しい。しかし、実施形態による証明書が複数の証明機関の証明を組み合わせるのは問題ではない。例えば、実施形態において、３つ以上、例えば５０の証明機関が組み合わされる。例えば、あらゆる携帯電話事業者が証明機関を動作させることができる。ネットワーク・ノードは、第１の証明機関デバイスを使用して、証明書及び第１のローカル鍵素材を入手する。次にネットワーク・ノードは、証明書を４９のさらなる証明機関に送り、４９回、追加のローカル鍵素材を受け取る。ネットワーク・ノードがローカル鍵素材を受け取ると、暗号化及び／又は認証は同様に、公開鍵の代わりに又は加えて共有鍵を使用して行われる。実施形態において、すべてのローカル鍵素材は、送信中にネットワーク・ノードの公開鍵で、及び／又は共有鍵で暗号化される。少なくともネットワーク・ノードの公開鍵を使用することによって、第１の証明機関が危険にさらされているとしても、ネットワーク・ノードは、危険にさらされていない、それに続く証明機関から、危険にさらされていない鍵素材を受け取る。
図３ａ及び図３ｂは、鍵合意を行うためにシステムがどのように動作されるかという１つのオプションを示す。図３ａは、第１のネットワーク・ノード３４０及び第２のネットワーク・ノード３５０を示す。これらのネットワーク・ノードは、ネットワーク・ノード１４０及び１５０の実施形態である。第１及び第２のネットワーク・ノード３４０及び３５０は、第１及び第２の証明書並びに第１及び第２のローカル鍵素材のそれぞれを証明機関デバイスによって提供された。ネットワーク・ノード３４０及び３５０は、鍵合意の手順を実施するための追加のハードウェア又はソフトウェアを有する。ネットワーク・ノード３４０はさらに詳細に示される。ネットワーク・ノード３５０は、例えばネットワーク・ノード３４０と同じデザインの実施形態を使用する。
ネットワーク・ノード３４０は身元情報ユニット１４６をさらに備える。身元情報ユニット１４６は、証明書に対応する識別子を計算することができる。身元情報ユニット１４６は、証明機関デバイス１１０の身元情報ユニット１１３と同じである。システム、ネットワーク・ノード、及び証明機関内のすべての参加者は、同じ識別子を計算することができる。例えば証明書に適用される身元情報形成関数は、例えばＭＡＣ、ＨＭＡＣ等といった、例えば鍵付きハッシュといった、鍵付きであるが、この場合、システム内のすべての参加者は、身元情報形成関数において使用される同じキーにアクセスすることができる。これは、システムへの参加を、鍵にアクセスできるデバイスに制限する。このような鍵は、製造中にネットワーク・ノード内に提供される。
ネットワーク・ノード３４０の証明書ストレージ１４５は、例えば、図３ａ及び図３ｂという状況下で第１の証明書と呼ばれる証明機関から受け取られた証明書を格納する。ネットワーク・ノード３４０は、身元情報ベース共有鍵ユニット１４７をさらに備える。ネットワーク・ノード３４０は、通信ユニットを通じて第２のネットワーク・ノード３５０から第２の証明書を取得するように配置される。身元情報ユニット１４６は、身元情報形成関数を第２の証明書に適用することによって、第２の証明書から第２の身元情報を取得するように配置される。第２の識別子は、第２のネットワーク・ノード３５０のローカル鍵素材を生成するために証明機関デバイスによって使用された同じ識別子であることに留意されたい。
ネットワーク・ノード３４０は、証明機関によって使用されるものと同じ身元情報ベース鍵事前配布方式に対応する鍵確立アルゴリズムのために配置された身元情報ベース共有鍵ユニット１４７を備える。共有鍵ユニット１４７は、第２の身元情報及び第１のローカル鍵素材に対して身元情報ベース鍵事前配布方式の鍵確立アルゴリズムを適用することによって、身元情報ベース共有鍵を生成するように配置される（ＫＩＢ＝ＧＡ（ＩＤＢ））。
共有鍵が生成された後、共有鍵は、ネットワーク・ノード３４０と３５０との間の通信を保護するために使用されることが可能である。例えば、共有鍵は認証するために使用され、又は共有鍵を使用してメッセージに対するＭＡＣを計算することによって整合性がメッセージも保護する。例えば、共有鍵は、共有鍵を使用してメッセージを暗号化することによって秘匿性を保護するために使用される。共有鍵が使用される前に、鍵導出が、身元情報ベースのアルゴリズムによってリンクをセキュアにするために適用され、及び／又は鍵多様化アルゴリズムが、例えばＭＡＣ、及び同じ共有鍵とは異なる暗号化キーといった、複数の鍵を生成するために適用される。
実施形態において、ネットワーク・ノード３４０は、
− 少なくとも身元情報ベース共有鍵から第１の認証トークンを計算すること、及び第１の認証トークンを第２のネットワーク・ノードに送ること、並びに／又は
− 第２のネットワーク・ノードから受け取られた第２の認証トークンを少なくとも身元情報ベース共有鍵から検証すること
を行うように配置された認証ユニット１４８を備える。
例えば、実施形態において、認証ユニット１４８は、双方向認証のために、認証トークンを検証すること及び計算することの両方が行われる。しかし、これはいつも要求されるわけではない。例えば、クライアントとサーバの関係の中には、クライアントがサーバを認証すること又はその逆しか要求しないものもある。
図３ｂは、ネットワーク・ノード３４０と３５０との間の手順の可能な実施形態を伴うシーケンス図を示す。例えば、第１のネットワーク・ノード３４０は、第１の証明書を第２のネットワーク・ノードに送り（３４０．２）、第２のネットワーク・ノード３５０は、第２の証明書を第１のネットワーク・ノードに送る（３５０．２）。
第１のネットワーク・ノードは、身元情報形成関数を適用することによって第２の証明書から第２の身元情報を取得し（３４０．４）、第２の身元情報及び第１のローカル鍵素材から身元情報ベース共有鍵を生成する（３４０．６）。
第２のネットワーク・ノードは、身元情報形成関数を適用することによって第１の証明書から第１の身元情報を取得し（３５０．４）、第１の身元情報及び第２のローカル鍵素材から身元情報ベース共有鍵を生成する（３５０．６）。
身元情報ベース鍵事前配布方式がヘルパー・データを使用して、（例えば、ＨＩＭＭＯのいくつかの実施形態において行われるように）共有鍵の形成を誘く場合、ヘルパー・データは、任意のネットワーク・ノードによって、しかし好ましくは第２のネットワーク・ノード３５０によって計算される。第２のネットワーク・ノード３５０は、他の当事者の身元情報に（この場合、第１の証明書を通じて）最初にアクセスできることになる。第２のネットワーク・ノード３５０は、ヘルパー・データをネットワーク・ノード３４０に、ヘルパー・データと共に送る。
ネットワーク・ノード３４０及び３５０の任意の１つ又は両方は、共有鍵を使用して、認証トークン、例えば、他の当事者から受け取られたノンス、又はタイム・スタンプ等に対するＭＡＣ又はＨＭＡＣをさらに計算する。認証トークンを受け取る当事者は、共有鍵を使用してトークンを検証することができる。例えば、ネットワーク・ノード３４０及び３５０の両方は、ノンスを証明書と共に送る。
例えば、実施形態において、ネットワーク・ノード３４０及びネットワーク・ノード３５０は、以下のメッセージを交換する。
１．ネットワーク・ノード３４０からネットワーク・ノード３５０に、ネットワーク・ノード３４０の証明書及び第１のノンス。
２．ネットワーク・ノード３５０からネットワーク・ノード３４０に、ネットワーク・ノード３５０の証明書、第２のノンス、少なくとも第１のノンス及び共有鍵に対する認証トークン、並びに必要ならヘルパー・データ。
３．ネットワーク・ノード３４０からネットワーク・ノード３５０に、少なくとも第２のノンスに対する認証トークン。
実施形態において、さらなる証明機関デバイスは最初に実施形態による鍵合意を行い、例えば、証明機関デバイス自体又は異なる証明機関によって生成された、証明機関デバイス自体のローカル鍵素材及び証明書を使用して、認証トークンを検証することを含む。
上述の実施形態において、証明機関デバイス１１０は、公開鍵を含む証明書を生成するように配置された証明書ユニット１１２、及び身元情報形成関数を証明書に適用することによって識別子を形成するように配置された身元情報ユニット１１３を備える。これには、識別子が本当に証明書に対応していることを証明機関デバイス１１０が自ら検証できるという長所がある。これは必須というわけではないが、実施形態において、証明書ユニット及び身元情報ユニットはネットワーク・ノードに含まれる。ネットワーク・ノードは、証明機関デバイスに、公開鍵及び識別子を送る。これは、証明機関デバイスが、識別子を通じて証明書にリンクされたローカル鍵素材を作成すること、及び公開鍵を使用して伝送中にローカル鍵素材を保護することを行うのに充分な情報である。後者の長所は、証明書が証明機関との間を行き来しないので、証明書の作成中に帯域幅が低減されるというものである。後者は、証明書をさらなる証明機関に送るのではなく、例えば、識別子及び公開鍵を１つ又は複数のさらなる証明機関に送ることによって、同様に複数のローカル鍵素材を取得するときに使用される。実施形態において、当初の証明書は第１の証明機関から受け取られ、その一方でさらなる証明機関は、識別子及び公開鍵しか受け取らず、必ずしも十分な証明書ではない。
実施形態において、第１のネットワーク・ノードは、身元情報形成関数を証明書に適用することによって識別子を形成するように配置された身元情報ユニット（１４６）と、第２のネットワーク・ノードから第２の証明書を取得するように配置された通信ユニット（１４２）と、身元情報ユニットは第２の証明書から第２の身元情報を取得するように配置され、第２の身元情報及び第１のローカル鍵素材に対して身元情報ベース鍵事前配布方式の鍵確立アルゴリズムを適用することによって、身元情報ベース共有鍵を生成するように配置された身元情報ベース共有鍵ユニット（１４７）と、少なくとも身元情報ベース共有鍵から第１の認証トークンを計算すること、及びこれを第２のネットワーク・ノードに送ること、及び／又は第２のネットワーク・ノードから受け取られた第２の認証トークンを少なくとも身元情報ベース共有鍵から検証することを行うように配置された認証ユニット（１４８）とを備える。
第１のネットワーク・ノードによって使用されるローカル鍵素材は、単一の証明機関から、又は複数の証明機関から取得され、ネットワーク・ノードが上記の手順を開始する前に組み合わされる。これは必須というわけではないが、ネットワーク・ノードは、手順の最中にどのローカル鍵素材を使用すべきかを同様に選択する。例えば、実施形態において、通信ノードは、第１のネットワーク・ノードがローカル鍵素材を受け取った証明機関の第２のネットワーク・ノードに送ること、及び第２のネットワーク・ノードがローカル鍵素材を受け取った証明機関の第２のネットワーク・ノードから受け取ることを行うように配置され、身元情報ベース共有鍵ユニットは、例えば、すべての共通の証明機関に対するローカルなキーイング素材を組み合わせるために、第１と第２の両方のネットワーク・ノードがローカル鍵素材を受け取った証明機関によって生成されたローカルなキーイング素材を組み合わせるように配置される。
証明機関の合意には以下の例に見られるような長所がある。第１のネットワーク・ノードが、証明機関ＣＡ１及びＣＡ２からローカルなキーイング素材を、並びに第２のネットワーク・ノードが証明機関ＣＡ２及びＣＡ３からローカルなキーイング素材を受け取ったと仮定する。２つのネットワーク・ノードは、ＣＡ２からのキーイング素材だけを使用して互いに通信することができる。これらのノードは、第１のネットワーク・ノードが、ＣＡ１とＣＡ２との素材を組み合わせ、その一方で第２のネットワーク・ノードが、ＣＡ２とＣＡ３との素材を組み合わせた場合、互いに通信することができない。ネットワーク・ノードを操って弱い証明機関を使わせるという考えられるリスクを低減させるために、少なくとも２つの共通の証明機関からのローカルなキーイング素材が、通信に必要とされることをネットワーク・ノードが要求することができる。
ローカル鍵素材及び／又は証明書を使用するさらなる手順が、本特許出願と同じ発明者及び出願人の、同じ特許庁に同じ日に出願された代理人整理番号２０１６ＰＦ００３３８の「ｈａｎｄｓｈａｋｅ ｐｒｏｔｏｃｏｌｓ ｆｏｒ ｉｄｅｎｔｉｔｙ−ｂａｓｅｄ ｋｅｙ ｍａｔｅｒｉａｌ ａｎｄ ｃｅｒｔｉｆｉｃａｔｅｓ」という名称の特許出願に定められており、本特許は参照により本明細書に組み込まれる。
典型的には、ネットワーク・ノード及び証明機関はそれぞれ、ネットワーク・ノード及び証明機関に格納された適正なソフトウェアを実行するマイクロプロセッサ（単独に図示せず）を備え、例えば、このソフトウェアは、例えばＲＡＭなどの揮発性メモリ、又はフラッシュなどの不揮発性メモリ（単独に図示せず）といった、対応するメモリにダウンロードされ、及び／又は格納される。一方、ネットワーク・ノード及び証明機関は、例えば、フィールド・プログラマブル・ゲート・アレイ（ＦＰＧＡ：ｆｉｅｌｄ−ｐｒｏｇｒａｍｍａｂｌｅ ｇａｔｅ ａｒｒａｙ）のようなプログラマブル論理回路に全体的に又は部分的に実装される。ネットワーク・ノード及び証明機関は、いわゆる特定用途向け集積回路（ＡＳＩＣ：ａｐｐｌｉｃａｔｉｏｎ−ｓｐｅｃｉｆｉｃ ｉｎｔｅｇｒａｔｅｄ ｃｉｒｃｕｉｔ）、すなわちこれらの特定用途のためにカスタマイズされた集積回路（ＩＣ：ｉｎｔｅｇｒａｔｅｄ ｃｉｒｃｕｉｔ）として全体的に又は部分的に実装される。例えば回路は、例えばＶｅｒｉｌｏｇ、ＶＨＤＬ等などのハードウェア記述言語を使用してＣＭＯＳに実装される。
実施形態において、ネットワーク・ノードは、キー・ペア生成回路、通信回路、復号化回路、キー・ストレージ回路、証明書ストレージ、身元情報回路、共有鍵回路、及び認証回路の１つ又は複数を備える。証明機関デバイスは、通信回路、証明書回路、身元情報回路、キー・ストレージ回路、ローカル鍵素材回路、及び暗号化回路の１つ又は複数を備える。回路はプロセッサ回路及びストレージ回路であり、プロセッサ回路は、ストレージ回路内に電子的に表現された命令を実行する。回路はまた、ＦＰＧＡ、ＡＳＩＣ、又は同様のものである。
例えば、図２及び図３ｂに示すような、ネットワーク・ノードの方法及び証明機関の方法の実施形態は、当業者に明白なように、多くの方式で実行される。例えば、ステップの順序は変えることができ、またステップの中には並列に実行されるものもある。その上、ステップの間に他の方法のステップが挿入されることもある。挿入されたステップは、本明細書に記述されるような方法の改良を表すこともあり、また本方法には関係ないこともある。例えば、ステップは、少なくとも部分的に並列に実行される。その上、所与のステップは、次のステップが開始される前に完全に終了していないこともある。
本発明による方法は、実施形態による方法をプロセッサ・システムに行わせる命令を含むソフトウェアを使用して実行される。ソフトウェアは、システムの特定のサブエンティティによって行われるこれらのステップしか含まない。ソフトウェアは、ハードディスク、フロッピー、メモリ、光ディスク等などの適切なストレージ媒体に格納される。ソフトウェアは、ワイヤ若しくはワイヤレスに沿って、又は例えばインターネットといったデータ・ネットワークを使用して、信号として送られる。ソフトウェアはダウンロードできるようにされ、及び／又はサーバ上で遠隔使用できるようにされる。本発明による方法は、方法を実施するために、例えばフィールド・プログラマブル・ゲート・アレイ（ＦＰＧＡ）といった、プログラマブル論理回路を構成するように配置されたビットストリームを使用して実行される。
本発明はまた、コンピュータ・プログラム、具体的には、本発明を実践するために適応される、キャリア上又はその中にあるコンピュータ・プログラムに及ぶということが理解されよう。プログラムは、ソース・コード、オブジェクト・コード、コードの中間ソース、及び部分的にコンパイルされた形式などのオブジェクト・コードの形式であり、又は本発明による方法の実装形態における使用に適した任意の他の形式である。コンピュータ・プログラム製品に関する実施形態は、示された方法のうちの少なくとも１つの処理ステップのそれぞれに対応するコンピュータ実行可能命令を含む。これらの命令はサブルーチンに再分割され、及び／又は静的若しくは動的にリンクされた１つ若しくは複数のファイルに格納される。コンピュータ・プログラム製品に関する別の実施形態は、示されたシステム及び／又は製品のうちの少なくとも１つの手段のそれぞれに対応するコンピュータ実行可能命令を含む。
図４ａは、コンピュータ・プログラム１０２０を備える書込み可能な部分１０１０を有するコンピュータ可読媒体１０００を示し、コンピュータ・プログラム１０２０は、実施形態によるネットワーク・ノードの方法及び／又は証明機関の方法をプロセッサ・システムに行わせる命令を含む。コンピュータ・プログラム１０２０は、物理的なマークとして、又はコンピュータ可読媒体１０００の磁化によって、コンピュータ可読媒体１０００上で具体化される。しかし、他の任意の適切な実施形態も同様に考えられる。さらに、コンピュータ可読媒体１０００はここでは光ディスクとして示されるが、コンピュータ可読媒体１０００は、ハードディスク、ソリッド・ステート・メモリ、フラッシュ・メモリ等などの任意の適切なコンピュータ可読媒体であってもよく、書込み不能又は書込み可能であってもよいということが理解されよう。コンピュータ・プログラム１０２０は、実施形態によるネットワーク・ノードの方法及び／又は証明機関の方法をプロセッサ・システムに行わせる命令を含む。証明書、公開鍵、ノンス、及び認証トークン等は、デジタル・データである。
図４ｂは、実施形態によるプロセッサ・システム１１４０を概略的に表現して示す。プロセッサ・システムは、１つ又は複数の集積回路１１１０を備える。１つ又は複数の集積回路１１１０のアーキテクチャは、図４ｂに概略的に示される。回路１１１０は、実施形態による方法を実行するため、及び／又はこのモジュール若しくはユニットを実施するために、例えば、コンピュータ・プログラム構成要素を動かすためのＣＰＵといった、処理ユニット１１２０を備える。回路１１１０は、プログラム・コード、データ等を格納するためのメモリ１１２２を備える。メモリ１１２２の一部は読出し専用である。回路１１１０は、例えば、アンテナ、コネクタ、又は両方、及び同様のものといった、通信要素１１２６を備える。回路１１１０は、方法の中で定義される処理の一部又はすべてを行うための専用集積回路１１２４を備える。プロセッサ１１２０、メモリ１１２２、専用ＩＣ１１２４、及び通信要素１１２６は、例えばバスといった、相互接続１１３０を介して互いに接続される。プロセッサ・システム１１１０は、アンテナ及び／又はコネクタをそれぞれ使用して、接触通信及び／又は非接触通信のために配置される。
上述の実施形態は、本発明を限定することなく示すこと、及び当業者が多くの代替実施形態を設計できるということに留意されたい。
特許請求の範囲において、丸括弧の間にある任意の引用符号は、特許請求の範囲を限定するものとして解釈されるべきではない。動詞「備える（ｃｏｍｐｒｉｓｅ）」とその語形変化の使用は、請求項で述べられる要素又はステップ以外の要素又はステップの存在を除外しない。要素の直前の冠詞「ａ」又は「ａｎ」は、複数のこのような要素の存在を除外しない。本発明は、いくつかの別個の要素を備えるハードウェアを用いて、及び適切にプログラムされたコンピュータを用いて実施される。いくつかの手段を列挙するデバイスの請求項において、これらの手段のいくつかはハードウェアの１つ及び同じアイテムによって具体化される。一定の方策が相互に異なる従属請求項に列挙されるという単なる事実は、これらの方策の組合せが有利に使用されることがないということを示さない。
特許請求の範囲において、丸括弧内の参照は、実施形態の図面における引用符号又は実施形態の公式を指し、このようにして特許請求の範囲の理解のしやすさを増大させる。これらの参照は、特許請求の範囲を限定するものとして解釈されるべきではない。
図１ａ〜図３ｂにおける参照番号のリスト
１００ 暗号システム
１１０、１２０、１３０ 証明機関デバイス
１１１ 通信ユニット
１１２ 証明書ユニット
１１３ 身元情報ユニット
１１４ キー・ストレージ
１１５ ローカル鍵素材ユニット
１１６ 暗号化ユニット
１４０、１５０、１６０ ネットワーク・ノード
１４１ キー・ペア生成ユニット
１４２ 通信ユニット
１４３ 復号化ユニット
１４４ キー・ストレージ
１４５ 証明書ストレージ
１４６ 身元情報ユニット
１４７ 共有鍵ユニット
１４８ 認証ユニット
２１０ 証明機関デバイス
２２０ さらなる証明機関デバイス
２４０ ネットワーク・ノード
３４０ 第１のネットワーク・ノード
３５０ 第２のネットワーク・ノード
２４０．１ 公開鍵及び対応する秘密鍵を生成する
２４０．２ 公開鍵を証明機関デバイスに送る
２４０．３ 秘密鍵を使用して、送られた暗号化されたローカル鍵素材を復号化し、ローカル鍵素材を取得する
２４０．４ 少なくともローカル鍵素材、秘密鍵、証明書を格納する
２４０．５ 証明書をさらなる証明機関デバイスに送る
２４０．６ 証明機関デバイスとさらなる証明機関デバイスとから受け取られたローカル鍵素材を組み合わせる
２１０．１ 公開鍵を含む証明書を生成する
２１０．２ 身元情報形成関数を証明書に適用することによって識別子を形成する
２１０．３ ネットワーク・ノードに固有のローカル鍵素材を生成する
２１０．４ ネットワーク・ノードの公開鍵によって少なくともネットワーク・ノードに固有のローカル鍵素材を暗号化する
２１０．５ 暗号化されたローカル鍵素材をネットワーク・ノードに送る
２２０．２ 身元情報形成関数を証明書に適用することによって識別子を形成する
２２０．３ ネットワーク・ノードに固有のローカル鍵素材を生成する
２２０．４ ネットワーク・ノードの公開鍵によって少なくともネットワーク・ノードに固有のローカル鍵素材を暗号化する
２２０．５ 暗号化されたローカル鍵素材をネットワーク・ノードに送る
３４０．２ 第１の証明書を第２のネットワーク・ノードに送る
３５０．２ 第２の証明書を第１のネットワーク・ノードに送る
３４０．４ 第２の証明書から第２の身元情報を取得する
３４０．６ 第２の身元情報及び第１のローカル鍵素材から身元情報ベース共有鍵を生成する
３５０．４ 第１の証明書から第１の身元情報を取得する
３５０．６ 第１の身元情報及び第２のローカル鍵素材から身元情報ベース共有鍵を生成する

Claims (15)

  1. 証明機関デバイス及び複数のネットワーク・ノードを備える、証明書を配布するための
    暗号システムであって、前記暗号システムは、
    前記複数のネットワーク・ノードのうちの１つのネットワーク・ノードが、
    公開鍵及び対応する秘密鍵を生成するキー・ペア生成ユニットであって、前記公開鍵が非対称鍵暗号方式に従って暗号化され、前記秘密鍵が前記非対称鍵暗号方式に従って復号化される、キー・ペア生成ユニットと、
    前記公開鍵を前記証明機関デバイスに送る通信ユニットと
    を備え、
    前記証明機関デバイスは、
    前記ネットワーク・ノードから前記公開鍵を受け取る通信ユニットと、
    身元情報ベース鍵事前配布方式のためのルート鍵素材を格納するためのキー・ストレージであって、前記ネットワーク・ノード及び前記証明機関デバイスのうちの少なくとも１つが、
    前記ネットワーク・ノードのための証明書を生成する証明書ユニット、及び
    身元情報形成関数を前記証明書に適用することによって識別子を形成する身元情報ユニットであって、前記身元情報形成関数は暗号学的ハッシュ関数を含む、身元情報ユニット、
    を備える、キー・ストレージと
    を備え、
    前記証明機関デバイスは、
    前記ルート鍵素材及び前記識別子に対して、前記身元情報ベース鍵事前配布方式のローカル鍵素材生成アルゴリズムを適用することによって、前記ネットワーク・ノードに固有のローカル鍵素材を生成するローカル鍵素材ユニットと、
    前記ネットワーク・ノードの前記公開鍵によって少なくとも前記ネットワーク・ノードに固有の前記ローカル鍵素材を暗号化する暗号化ユニットと
    をさらに備え、
    前記通信ユニットが、さらに、暗号化された前記ローカル鍵素材を前記ネットワーク・ノードに送り、
    前記ネットワーク・ノードは、
    前記秘密鍵を使用して、送られた暗号化された前記ローカル鍵素材を復号化し、前記ローカル鍵素材を取得する復号化ユニットと、
    少なくとも前記ローカル鍵素材及び前記秘密鍵を格納するキー・ストレージと、
    前記証明書を格納する証明書ストレージと
    をさらに備え、
    前記証明書が前記公開鍵を含み、前記識別子が少なくとも前記公開鍵を識別する、暗号
    システム。
  2. 前記ネットワーク・ノードの前記通信ユニットが、前記公開鍵を前記証明機関デバイスに送るのに加えて、ユーザの名前といった、識別情報を送り、
    前記証明書ユニットが前記証明書の中に前記識別情報を含ませる、
    請求項１に記載の暗号システム。
  3. 前記証明機関デバイスが、前記公開鍵を含む証明書を生成する前記証明書ユニット、及び身元情報形成関数を前記証明書に適用することによって識別子を形成する前記身元情報ユニットを備える、請求項１又は２に記載の暗号システム。
  4. 前記証明書ユニットが、前記識別子を形成する前に、証明書の有効期限といったさらなる情報を前記証明書に含める、請求項３に記載の暗号システム。
  5. 前記証明書ユニットが、ノンスを生成し、前記識別子を形成する前に、前記ノンスを前記証明書に含める、請求項３又は４に記載の暗号システム。
  6. 前記ネットワーク・ノードの前記通信ユニットが、前記証明書をさらなる証明機関デバイスに送り、このようにしてさらなるローカル鍵素材を取得し、前記ネットワーク・ノードが、前記証明機関デバイスから受け取られた前記ローカル鍵素材と前記さらなる証明機関デバイスから受け取られた前記さらなるローカル鍵素材とを単一のローカル鍵素材に組み合わせる、請求項３、４、又は５に記載の暗号システム。
  7. 前記証明書が署名されない、請求項１乃至６のいずれか一項に記載の暗号システム。
  8. 前記ネットワーク・ノードが、ノンスを選択し、前記ネットワーク・ノードの前記通信ユニットが、前記ノンスを前記証明機関デバイスに送り、
    前記証明機関デバイスが、
    証明機関の証明書、及び前記身元情報ユニットによって前記証明機関の証明書から取得された識別子に対して生成された証明機関のローカル鍵素材を取得すること、
    前記ネットワーク・ノードの識別子及び前記証明機関のローカル鍵素材から共有鍵を生成すること、
    前記ノンス及び前記共有鍵から認証トークンを計算することであって、前記証明機関デバイスの前記通信ユニットが、前記証明機関の証明書及び認証トークンを前記ネットワーク・ノードに送る、認証トークンを計算すること
    を行い、
    前記ネットワーク・ノードが、
    前記証明機関の証明書及び前記ネットワーク・ノードの前記ローカル鍵素材から前記共有鍵を生成すること、及び前記認証トークンを検証すること
    を行う、請求項１乃至７のいずれか一項に記載の暗号システム。
  9. 前記ネットワーク・ノードは、
    前記身元情報形成関数を証明書に適用することによって識別子を形成する身元情報ユニットと、
    第２のネットワーク・ノードから第２の証明書を取得する通信ユニットであって、前記身元情報ユニットが、前記第２の証明書から第２の身元情報を取得する、通信ユニットと、
    前記第２の身元情報及び前記ローカル鍵素材に対して前記身元情報ベース鍵事前配布方式の鍵確立アルゴリズムを適用することによって、身元情報ベース共有鍵を生成する身元情報ベース共有鍵ユニットと
    を備える、請求項１乃至８のいずれか一項に記載の暗号システム。
  10. 前記ネットワーク・ノードが、
    少なくとも前記身元情報ベース共有鍵から第１の認証トークンを計算し、前記第１の認証トークンを前記第２のネットワーク・ノードに送ること、及び／又は
    前記第２のネットワーク・ノードから受け取られた第２の認証トークンを少なくとも前記身元情報ベース共有鍵から検証すること
    を行う認証ユニットを備える、請求項９に記載の暗号システム。
  11. 前記身元情報ベース鍵事前配布方式が、ＨＩＭＭＯ方式である、請求項１乃至１０のいずれか一項に記載の暗号システム。
  12. ネットワーク・ノードから公開鍵を受け取る通信ユニットと、
    身元情報ベース鍵事前配布方式のためのルート鍵素材を格納するためのキー・ストレージと、
    前記ネットワーク・ノードの証明書を生成する証明書ユニットと、
    前記ルート鍵素材及び識別子に対して前記身元情報ベース鍵事前配布方式のローカル鍵素材生成アルゴリズムを適用することによって、前記ネットワーク・ノードに固有のローカル鍵素材を生成するローカル鍵素材ユニットであって、前記識別子が、身元情報形成関数を前記ネットワーク・ノードの証明書に適用することによって取得され、前記身元情報形成関数が、暗号学的ハッシュ関数を含む、ローカル鍵素材ユニットであって、前記証明書は前記公開鍵と少なくとも前記公開鍵を識別する識別子とを有する、ローカル鍵素材ユニットと、
    前記ネットワーク・ノードの前記公開鍵によって少なくとも前記ネットワーク・ノードに固有の前記ローカル鍵素材を暗号化する暗号化ユニットと
    を備え、
    前記通信ユニットが、暗号化された前記ローカル鍵素材を前記ネットワーク・ノードに送る、
    証明機関デバイス。
  13. ネットワーク・ノードから公開鍵を受け取るステップと、
    前記ネットワーク・ノードの証明書を生成するステップと、
    ルート鍵素材及び識別子に対して身元情報ベース鍵事前配布方式のローカル鍵素材生成アルゴリズムを適用することによって、前記ネットワーク・ノードに固有のローカル鍵素材を生成するステップであって、前記ルート鍵素材が、身元情報ベース鍵事前配布方式のためのものであり、前記識別子が、身元情報形成関数を前記ネットワーク・ノードの証明書に適用することによって取得され、前記身元情報形成関数が、暗号化ハッシュ関数を含み、前記証明書は前記公開鍵と少なくとも前記公開鍵を識別する識別子とを有する、生成するステップと、
    前記ネットワーク・ノードの前記公開鍵によって少なくとも前記ネットワーク・ノードに固有のローカル鍵素材を暗号化するステップと、
    暗号化された前記ローカル鍵素材を前記ネットワーク・ノードに送るステップとを有する、証明機関の方法。
  14. コンピュータ・プログラムであって、
    前記コンピュータ・プログラムがコンピュータ上で動くと、請求項１３に記載の方法を行うコンピュータ・プログラム命令を備える、コンピュータ・プログラム。
  15. 請求項１４に記載のコンピュータ・プログラムを備える、コンピュータ可読媒体。
JP2018551282A 2016-03-29 2017-03-28 身元情報ベース鍵素材及び証明書の配布のためのシステム及び方法 Active JP6670395B2 (ja)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
EP16162597 2016-03-29
EP16162597.5 2016-03-29
PCT/EP2017/057298 WO2017167741A1 (en) 2016-03-29 2017-03-28 System and method for distribution of identity based key material and certificate

Publications (2)

Publication Number Publication Date
JP2019514269A JP2019514269A (ja) 2019-05-30
JP6670395B2 true JP6670395B2 (ja) 2020-03-18

Family

ID=55637280

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2018551282A Active JP6670395B2 (ja) 2016-03-29 2017-03-28 身元情報ベース鍵素材及び証明書の配布のためのシステム及び方法

Country Status (6)

Country Link
US (1) US10951423B2 (ja)
EP (1) EP3437247B1 (ja)
JP (1) JP6670395B2 (ja)
CN (1) CN108886468B (ja)
RU (1) RU2018137847A (ja)
WO (1) WO2017167741A1 (ja)

Families Citing this family (20)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN106533665B (zh) * 2016-10-31 2018-08-07 北京百度网讯科技有限公司 用于存储网站私钥明文的方法、系统和装置
US11552795B2 (en) * 2018-01-22 2023-01-10 Microsoft Technology Licensing, Llc Key recovery
US10999081B2 (en) * 2018-04-12 2021-05-04 Microsoft Technology Licensing, Llc Dynamic certificate management for a distributed authentication system
WO2020010515A1 (en) 2018-07-10 2020-01-16 Apple Inc. Identity-based message integrity protection and verification for wireless communication
RU2695487C1 (ru) 2018-09-26 2019-07-23 Олег Дмитриевич Гурин Способ и система обеспечения взаимодействия устройств интернета вещей (iot)
CN109462481B (zh) * 2018-11-23 2022-04-26 上海扈民区块链科技有限公司 一种基于非对称双线性对的匿签密方法
DE102019100335A1 (de) * 2019-01-08 2020-07-09 Bundesdruckerei Gmbh Verfahren zum sicheren Bereitstellen einer personalisierten elektronischen Identität auf einem Endgerät
US11290285B2 (en) * 2019-02-08 2022-03-29 Bank Of America Corporation Centralized identification for certificate using natural language processing
US11665539B2 (en) * 2019-03-18 2023-05-30 Hitachi Kokusai Electric Inc. Communication system
WO2021016577A1 (en) * 2019-07-24 2021-01-28 Arris Enterprises Llc Key ladder generating a device public key
CN110808827A (zh) * 2019-09-20 2020-02-18 北京电信易通信息技术股份有限公司 基于量子加密的空中发证方法及系统
US11509467B2 (en) 2020-02-25 2022-11-22 Microsoft Technology Licensing, Llc Story assisted mnemonic phrase
US11652616B2 (en) * 2020-02-26 2023-05-16 International Business Machines Corporation Initializing a local key manager for providing secure data transfer in a computing environment
US11184160B2 (en) 2020-02-26 2021-11-23 International Business Machines Corporation Channel key loading in a computing environment
US11973887B2 (en) * 2020-10-09 2024-04-30 Unho Choi Chain of authentication using public key infrastructure
CN112636906A (zh) * 2020-12-11 2021-04-09 海光信息技术股份有限公司 密钥协商方法及装置
US11870919B2 (en) 2020-12-18 2024-01-09 Visa International Service Association Method and system for authentication credential
CN113515538B (zh) * 2021-06-08 2023-07-07 四川新网银行股份有限公司 一种基于多方安全计算的机构间隐私数据查询及预警方法
CN114124378B (zh) * 2021-11-26 2024-03-08 北京神经元网络技术有限公司 基于autbus总线的通信方法、系统、设备及介质
US20230318826A1 (en) * 2022-03-30 2023-10-05 International Business Machines Corporation Key import with hybrid cryptography

Family Cites Families (33)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH0697931A (ja) * 1992-09-14 1994-04-08 Fujitsu Ltd パーソナル通信端末登録制御方式
JP2001111539A (ja) * 1999-10-05 2001-04-20 Dainippon Printing Co Ltd 暗号鍵生成装置および暗号鍵伝送方法
US7269726B1 (en) * 2000-01-14 2007-09-11 Hewlett-Packard Development Company, L.P. Lightweight public key infrastructure employing unsigned certificates
JP2001350406A (ja) * 2000-06-07 2001-12-21 Mitsubishi Electric Corp 証明書発行装置および証明書検証方式
AU2003262908A1 (en) * 2002-08-28 2004-03-19 Docomo Communications Laboratories Usa, Inc. Certificate-based encryption and public key infrastructure
US7860254B2 (en) * 2003-03-13 2010-12-28 Hamdy Soliman Computer system security via dynamic encryption
US7401215B2 (en) 2003-09-29 2008-07-15 Sun Microsystems, Inc. Method and apparatus for facilitating cryptographic layering enforcement
US7657739B2 (en) 2003-11-25 2010-02-02 Panasonic Corporation Authentication system
JP2006129143A (ja) * 2004-10-29 2006-05-18 Toppan Printing Co Ltd 秘密情報送受信システム及び方法、サーバー装置及びプログラム、並びに鍵情報保持装置
EP1906587A3 (en) 2004-10-29 2008-04-16 Thomson Licensing, Inc. Secure authenticated channel
US7370202B2 (en) * 2004-11-02 2008-05-06 Voltage Security, Inc. Security device for cryptographic communications
US7266692B2 (en) * 2004-12-17 2007-09-04 Ntt Docomo, Inc. Use of modular roots to perform authentication including, but not limited to, authentication of validity of digital certificates
JP4794970B2 (ja) * 2005-09-30 2011-10-19 株式会社エヌ・ティ・ティ・データ 秘密情報の保護方法及び通信装置
TWI356611B (en) * 2006-07-06 2012-01-11 O2Micro Int Ltd Secured method and apparatus thereof for accessin
EP2272202B1 (en) * 2008-04-14 2020-06-10 Philips Intellectual Property & Standards GmbH Method for distributed identification, a station in a network
US8837736B2 (en) * 2008-04-14 2014-09-16 Koninklijke Philips N.V. Method for distributing encryption means
KR101594553B1 (ko) * 2008-10-20 2016-02-18 코닌클리케 필립스 엔.브이. 암호화 키를 생성하는 방법, 이를 위한 네트워크 및 컴퓨터 프로그램
US8510558B2 (en) * 2009-02-17 2013-08-13 Alcatel Lucent Identity based authenticated key agreement protocol
US8509448B2 (en) * 2009-07-29 2013-08-13 Motorola Solutions, Inc. Methods and device for secure transfer of symmetric encryption keys
CN106230872A (zh) * 2009-11-25 2016-12-14 安全第公司 对移动中数据进行保护的系统和方法
DE102010030590A1 (de) * 2010-06-28 2011-12-29 Bundesdruckerei Gmbh Verfahren zur Erzeugung eines Zertifikats
US20140244998A1 (en) * 2010-11-09 2014-08-28 Secure64 Software Corporation Secure publishing of public-key certificates
WO2012092399A2 (en) * 2010-12-29 2012-07-05 Secureall Corporation Cryptographic communication with mobile devices
US9698979B2 (en) * 2011-04-15 2017-07-04 Quintessencelabs Pty Ltd. QKD key management system
CN102420691B (zh) * 2011-12-16 2014-04-16 河海大学 基于证书的前向安全签名方法及系统
US9059977B2 (en) * 2013-03-13 2015-06-16 Route1 Inc. Distribution of secure or cryptographic material
US9363259B2 (en) * 2013-05-23 2016-06-07 Symantec Corporation Performing client authentication using onetime values recovered from barcode graphics
US9961073B2 (en) * 2013-09-30 2018-05-01 Digicert, Inc. Dynamic certificate generation on a certificate authority cloud
US9602500B2 (en) * 2013-12-20 2017-03-21 Intel Corporation Secure import and export of keying material
EP3189618B1 (en) * 2014-09-04 2020-06-17 Koninklijke Philips N.V. Cryptographic system arranged for key sharing
WO2017103226A1 (en) 2015-12-17 2017-06-22 Koninklijke Philips N.V. Improved system for key sharing
JP6613909B2 (ja) * 2016-01-15 2019-12-04 富士通株式会社 相互認証方法、認証装置および認証プログラム
WO2017167771A1 (en) 2016-03-29 2017-10-05 Koninklijke Philips N.V. Handshake protocols for identity-based key material and certificates

Also Published As

Publication number Publication date
US20190089546A1 (en) 2019-03-21
CN108886468A (zh) 2018-11-23
JP2019514269A (ja) 2019-05-30
RU2018137847A (ru) 2020-04-29
US10951423B2 (en) 2021-03-16
EP3437247A1 (en) 2019-02-06
EP3437247B1 (en) 2019-10-23
CN108886468B (zh) 2022-06-07
RU2018137847A3 (ja) 2020-04-29
WO2017167741A1 (en) 2017-10-05

Similar Documents

Publication Publication Date Title
JP6670395B2 (ja) 身元情報ベース鍵素材及び証明書の配布のためのシステム及び方法
US11323276B2 (en) Mutual authentication of confidential communication
US10903991B1 (en) Systems and methods for generating signatures
US9794249B1 (en) Using a digital certificate with multiple cryptosystems
JP4527358B2 (ja) 鍵供託を使用しない、認証された個別暗号システム
WO2017167771A1 (en) Handshake protocols for identity-based key material and certificates
WO2018236908A1 (en) SECURE COMMUNICATIONS PROVIDING PERSISTENT CONFIDENTIALITY
CN112104453B (zh) 一种基于数字证书的抗量子计算数字签名系统及签名方法
WO2013112901A1 (en) System and method for securing private keys issued from distributed private key generator (d-pkg) nodes
US11722466B2 (en) Methods for communicating data utilizing sessionless dynamic encryption
CN113098681B (zh) 云存储中口令增强且可更新的盲化密钥管理方法
GB2543359A (en) Methods and apparatus for secure communication
CN110572257B (zh) 基于身份的数据来源鉴别方法和系统
KR20080005344A (ko) 인증서버가 사용자단말기를 인증하는 시스템
Yao et al. Post Quantum KEM authentication in SPDM for secure session establishment
EP2600647B1 (en) Derived certificate based on changing identity
Dugardin et al. A New Fair Identity Based Encryption Scheme
JP2015186101A (ja) 鍵交換装置、及び鍵交換方法
CN117749413B (zh) 基于tlcp商密协议的安全通信方法及安全通信系统
Lum IEEE 2030.5 security overview
Heins Cryptographic Toolkit
WO2022218544A1 (en) Device and method for decision-making
CN114785487A (zh) 基于ca和国密算法的抗量子计算https通信方法及系统

Legal Events

Date Code Title Description
A529 Written submission of copy of amendment under article 34 pct

Free format text: JAPANESE INTERMEDIATE CODE: A529

Effective date: 20180928

A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20180928

A871 Explanation of circumstances concerning accelerated examination

Free format text: JAPANESE INTERMEDIATE CODE: A871

Effective date: 20180928

A975 Report on accelerated examination

Free format text: JAPANESE INTERMEDIATE CODE: A971005

Effective date: 20190212

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20190423

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20190625

A02 Decision of refusal

Free format text: JAPANESE INTERMEDIATE CODE: A02

Effective date: 20190924

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20191225

C60 Trial request (containing other claim documents, opposition documents)

Free format text: JAPANESE INTERMEDIATE CODE: C60

Effective date: 20191225

A911 Transfer to examiner for re-examination before appeal (zenchi)

Free format text: JAPANESE INTERMEDIATE CODE: A911

Effective date: 20200109

C21 Notice of transfer of a case for reconsideration by examiners before appeal proceedings

Free format text: JAPANESE INTERMEDIATE CODE: C21

Effective date: 20200121

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: 20200204

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20200228

R150 Certificate of patent or registration of utility model

Ref document number: 6670395

Country of ref document: JP

Free format text: JAPANESE INTERMEDIATE CODE: R150

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250