JP2023503235A - パスワード認証による公開鍵確立 - Google Patents

パスワード認証による公開鍵確立 Download PDF

Info

Publication number
JP2023503235A
JP2023503235A JP2022526054A JP2022526054A JP2023503235A JP 2023503235 A JP2023503235 A JP 2023503235A JP 2022526054 A JP2022526054 A JP 2022526054A JP 2022526054 A JP2022526054 A JP 2022526054A JP 2023503235 A JP2023503235 A JP 2023503235A
Authority
JP
Japan
Prior art keywords
client
key
private key
server
authentication server
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.)
Pending
Application number
JP2022526054A
Other languages
English (en)
Inventor
クラウディオ・ソリエンテ
アントニオ・ファオニオ
マリア・イサベル・ゴンザレス・バスコ
アンヘル・ペレス・デル・ポソ
Original Assignee
エヌイーシー ラボラトリーズ ヨーロッパ ゲーエムベーハー
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 エヌイーシー ラボラトリーズ ヨーロッパ ゲーエムベーハー filed Critical エヌイーシー ラボラトリーズ ヨーロッパ ゲーエムベーハー
Publication of JP2023503235A publication Critical patent/JP2023503235A/ja
Pending legal-status Critical Current

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/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/085—Secret sharing or secret splitting, e.g. threshold 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/0861—Generation of secret information including derivation or calculation of cryptographic keys or passwords
    • H04L9/0869—Generation of secret information including derivation or calculation of cryptographic keys or passwords involving random numbers or seeds
    • 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/02—Network architectures or network communication protocols for network security for separating internal from external traffic, e.g. firewalls
    • H04L63/0281—Proxies
    • 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
    • H04L63/0442—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 wherein the sending and receiving network entities apply asymmetric encryption, i.e. different keys for encryption and decryption
    • 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/08—Network architectures or network communication protocols for network security for authentication of entities
    • H04L63/0823—Network architectures or network communication protocols for network security for authentication of entities using certificates
    • 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/08—Network architectures or network communication protocols for network security for authentication of entities
    • H04L63/083—Network architectures or network communication protocols for network security for authentication of entities using passwords
    • 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/08—Network architectures or network communication protocols for network security for authentication of entities
    • H04L63/0884—Network architectures or network communication protocols for network security for authentication of entities by delegation of authentication, e.g. a proxy authenticates an entity to be authenticated on behalf of this entity vis-à-vis an authentication entity
    • 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/12—Applying verification of the received information
    • H04L63/126—Applying verification of the received information the source of the received data
    • 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/3218—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 proof of knowledge, e.g. Fiat-Shamir, GQ, Schnorr, ornon-interactive zero-knowledge proofs
    • 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/3247—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 digital signatures
    • 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
    • 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/3271—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 challenge-response
    • H04L9/3273—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 challenge-response for mutual authentication
    • 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/50—Oblivious transfer

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)
  • Theoretical Computer Science (AREA)
  • Algebra (AREA)
  • General Physics & Mathematics (AREA)
  • Mathematical Analysis (AREA)
  • Mathematical Optimization (AREA)
  • Mathematical Physics (AREA)
  • Pure & Applied Mathematics (AREA)
  • Physics & Mathematics (AREA)
  • Storage Device Security (AREA)
  • Computer And Data Communications (AREA)

Abstract

暗号鍵プロビジョニングのための方法は、メイン認証サーバ(MAS)を介して第1の秘密鍵を生成するステップと、分散しきい値忘却型擬似ランダム関数の第1のインスタンスの第1の部分を実行することによってクライアントを登録するステップとを含む。この関数の第1のインスタンスによって、クライアントがルート秘密鍵を取得し、MASが対応するルート公開鍵を取得する。この方法は、分散しきい値忘却型擬似ランダム関数の第2のインスタンスの第1の部分を実行することによってクライアントをMASに認証するステップを含む。この関数の第2のインスタンスによって、クライアントがルート秘密鍵を取得する。クライアントによって記憶される情報、第1の秘密鍵、およびサポート認証サーバによって生成される第2の秘密鍵が、分散しきい値忘却型擬似ランダム関数の第1のインスタンスおよび第2のインスタンスのうちの少なくとも一方への入力である。

Description

関連出願の相互参照
2019年11月29日に出願された米国仮出願第62/941,908号の優先権を主張する。この出願の開示全体が参照により本明細書に組み込まれる。
本発明は、公開鍵確立のための方法およびシステム、ユーザを認証するための方法およびシステム、ならびに否認できないユーザメッセージを生成するための方法およびシステムに関する。
クライアント-サーバアプリケーション(たとえば、オンラインバンキング、モノのインターネット("IoT")など)の環境では、クライアントがサーバのデジタル証明書によってサーバを認証し、一方、たいていの場合、サーバがパスワード(たとえば、クライアントによって与えられるパスワード)によってクライアントを認証する。紛争が生じた場合、サーバからのメッセージは、サーバの非公開鍵を用いて署名されている場合には、メッセージの作成者を明確に特定することができる。しかし、これはクライアントからのメッセージについては不可能である。
Stanislaw Jareckiら、"TOPPSS: Cost-minimal Password-protected Secret Sharing based on Threshold OPRF"、ACNS (2017)
一実施形態では、本発明は、暗号鍵プロビジョニングのための方法であって、メイン認証サーバ(MAS)を介して第1の秘密鍵を生成するステップと、分散しきい値忘却型擬似ランダム関数の第1のインスタンスの第1の部分を実行することによってクライアントを登録するステップとを含む方法を提供する。この関数の第1のインスタンスによって、クライアントがルート秘密鍵を取得し、MASが対応するルート公開鍵を取得する。この方法は、分散しきい値忘却型擬似ランダム関数の第2のインスタンスの第1の部分を実行することによってクライアントをMASに認証するステップを含む。この関数の第2のインスタンスによって、クライアントがルート秘密鍵を取得する。クライアントによって記憶される情報、第1の秘密鍵、およびサポート認証サーバによって生成される第2の秘密鍵が、分散しきい値忘却型擬似ランダム関数の第1のインスタンスおよび第2のインスタンスのうちの少なくとも一方への入力である。
本発明の実施形態について例示的な図に基づいて以下にさらに詳しく説明する。本発明は、例示的な実施形態に限定されない。本明細書で説明しならびに/または図示するすべての特徴は、本発明の実施形態において単独で使用することができ、またはそれぞれに異なる組合せとして組み合わせることができる。本発明の様々な実施形態の特徴および利点は、以下のことを示す添付の図面を参照しながら以下の詳細な説明を読むことによって明らかになろう。
本発明の一実施形態による登録のための方法を示す図である。 本発明の一実施形態による認証のための方法を示す図である。 本明細書で開示するあらゆる動作を実行するように構成することができる例示的な処理システムのブロック図である。 本発明の一実施形態によるA2PAKE(登録フェーズ)のインスタンス化を示す図である。 本発明の一実施形態によるA2PAKE(認証フェーズ)のインスタンス化を示す図である。
一実施形態では、本発明は、暗号鍵確立のための方法を提供する。この方法は、メイン認証サーバ(MAS)を介して第1の秘密鍵を生成するステップを含む。サポート認証サーバ(SAS)は第2の秘密鍵を生成する。クライアントは、MASとしきい値忘却型擬似ランダム関数の一部を実行し、SASとしきい値忘却型擬似ランダム関数の残りの部分を実行し、クライアントがルート秘密鍵を取得し、一方、MASとSASが対応するルート公開鍵を取得することによってMASに登録する。
一実施形態では、クライアントは、MASとともにしきい値忘却型擬似ランダム関数の一部を実行し、SASとともにしきい値忘却型擬似ランダム関数の残りの部分を実行し、クライアントが登録時に取得されたのと同じルート秘密鍵を取得することによってMASに登録する。次に、クライアントは、MASによって与えられるランダムネスを含む新しい非対称鍵ペアを作成し、この鍵(たとえば、非対称鍵ペアの新しい公開鍵)にルート秘密鍵を用いて署名し、一方、サーバは対応するルート公開鍵を用いてこの署名を検証する。クライアント上に記憶されるパスワード、MASの第1の秘密鍵、およびSASの第2の秘密鍵が、登録時および認証時に使用される分散しきい値忘却型擬似ランダム関数への入力である。
一実施形態では、本発明は、暗号鍵プロビジョニングのための方法であって、メイン認証サーバ(MAS)を介して第1の秘密鍵を生成するステップを含む。サポート認証サーバ(SAS)は第2の秘密鍵を生成する。この方法は、分散しきい値忘却型擬似ランダム関数の第1のインスタンスの第1の部分をクライアントとともに実行することによってクライアントをMASに登録するステップを含む。SASは、しきい値忘却型擬似ランダム関数の第1のインスタンスの第2の部分をクライアントとともに実行する。したがって、クライアントはルート秘密鍵を取得し、MASは対応するルート公開鍵を取得し、SASは対応するルート公開鍵を取得する。
一実施形態では、この方法は、MASを介して、分散しきい値忘却型擬似ランダム関数の第2のインスタンスの第1の部分を実行することによってクライアントをMASに認証するステップを含む。SASは、しきい値忘却型擬似ランダム関数の第2のインスタンスの第2の部分を実行する。したがって、クライアントはルート秘密鍵を取得する。
一実施形態では、クライアントは、MASによって与えられるランダムネスに基づいて新しい非対称鍵ペアを作成し、新しい非対称鍵ペアの少なくとも一部にルート秘密鍵を用いて署名し、署名した部分をMASに送信する。この方法は、一実施形態によれば、MASを介して、署名された部分を対応するルート公開鍵を用いて検証するステップを含む。クライアントによって記憶されたパスワード、MASの第1の秘密鍵、およびSASの第2の秘密鍵が、分散しきい値忘却型擬似ランダム関数の第1および第2のインスタンスへの入力である。
いくつかのシナリオでは、ユーザメッセージの非否認が望ましい特性である。たとえば、オンラインバンキングアプリケーションでは、バンキングサーバが、たとえば資金を他のアカウントに転送するための要求の認証をユーザ(クライアント)に要求することがある。後で、紛争が生じた場合、サーバは、ユーザが本当に議論されている操作を要求したことをサードパーティ(たとえば、裁判所)に証明することを望むことがある。同様に、モノのインターネット(IoT)アプリケーションでは、処理サーバが、特定のデータレポートを生成したデバイスの所有者を特定することを望むことがある。
考えられる解決策では「クラウドベースPKI」が利用される。この場合の原則として、各ユーザは、クラウド内のサーバ上に記憶された一意の公開鍵インフラストラクチャ(PKI)証明書を有する。ユーザは、(パスワードまたはワンタイムコードを介して)サーバに認証し、ユーザに代わってメッセージに署名することをサーバに要求する。
しかし、この構成では、本当にユーザによって作成されたのはどの署名であるか、およびなりすましの試みによって作成されたのはどの署名であるか(たとえば、証明書を記憶しているサーバにユーザのパスワードを介して認証された悪意のあるパーティ)をサードパーティが確認することはできない。サーバがユーザの証明書を保持しているので、サーバが証明書を使用してユーザに代わって真正でないメッセージ(たとえば、証明書を記憶しているサーバにユーザのパスワードを介して認証された悪意のあるパーティによって生成されたメッセージ)に署名している可能性がある。したがって、ユーザは、署名がユーザの同意なしにサーバによって(たとえば、証明書を記憶しているサーバに対してユーザのパスワードにアクセスできる悪意のあるパーティによって)適用されたと主張することによって署名されたメッセージを作成したことを否定することができる。
さらに、署名鍵(たとえば、ユーザの証明書内の鍵)が(たとえば、PBKDF2などのパスワードベース鍵導出関数を使用することによって)ユーザのパスワードから(たとえば、ハッシングを介して)導出された場合でも、パスワードを記憶しているサーバは、同じ秘密鍵を導出し、そのユーザに代わってメッセージに署名することができる。サーバがパスワードの(ソルト付きの)一方向関数を保持している場合でも、ブルートフォース攻撃によって、サーバは正しい秘密鍵を判定することができる。
一実施形態では、本発明は、ユーザが新しい非対称鍵ペアの秘密鍵を非公開で取得し、一方、対応する公開鍵がユーザとサーバの両方によって認識されるパスワードベース認証プロトコルを提供する。鍵ペアを使用してクライアントからサーバへのメッセージに署名する(たとえば、クライアントが秘密鍵を介してメッセージに署名し、サーバが公開鍵を介して署名を検証する)場合、サーバは、署名されたメッセージが真正にユーザによって作成されたことを後でサードパーティに実証する(たとえば、証明する)ことができる。それによって、ユーザによって生成されたメッセージは、否認不能であり、または言い換えれば否認することができない。
この実施形態では、悪意あるサーバまたは他のエンティティは、(後述のようにある条件が満たされた場合に)ユーザによって作成されたメッセージでもユーザによって許可されたメッセージでもないメッセージに不正に署名することはできない(すなわち、悪意のあるエンティティはユーザに代わってメッセージに署名することはできない)ので、コンピュータネットワーキング認証プロトコル(たとえば、暗号プロトコル)のセキュリティが強化される。したがって、ユーザは(条件が存在する場合)署名されたメッセージを不当に放棄することはできない。したがって、認証システムは、メッセージが有効であり(たとえば、真正であり)、無効である(たとえば、真正でない)として放棄することができないことを保証することによって不当な電子情報および悪意のあるデバイスから守る。したがって、実施形態は、コンピュータネットワークおよび暗号通信プロトコルのセキュリティを改善する。
一実施形態では、本発明は、暗号鍵プロビジョニングのための方法であって、メイン認証サーバを介して第1の秘密鍵を生成するステップと、分散しきい値忘却型擬似ランダム関数の第1のインスタンスの第1の部分を実行することによってクライアントを登録するステップであって、関数の第1のインスタンスによって、クライアントがルート秘密鍵を取得し、メイン認証サーバが対応するルート公開鍵を取得する、ステップと、分散しきい値忘却型擬似ランダム関数の第2のインスタンスの第1の部分を実行することによってクライアントをメイン認証サーバに認証するステップであって、関数の第2のインスタンスによって、クライアントがルート秘密鍵を取得する、ステップとを含む方法を提供する。クライアントによって記憶される情報、第1の秘密鍵、およびサポート認証サーバによって生成される第2の秘密鍵が、分散しきい値忘却型擬似ランダム関数の第1および第2のインスタンスのうちの少なくとも一方への入力である。
一実施形態では、メイン認証サーバは、クライアントもサポート認証サーバも第1の秘密鍵を受信しないように第1の秘密鍵を非公開にする。一実施形態では、サポート認証サーバは、クライアントもメイン認証サーバも第2の秘密鍵を受信しないように第2の秘密鍵を非公開にする。
一実施形態では、メイン認証サーバは、クライアントとともに関数の第1のインスタンスの第1の部分を実行し、サポート認証サーバは、認証の前に、クライアントとともに関数の第1のインスタンスの第2の部分を実行しておく。一実施形態では、認証時に、サポート認証サーバが関数の第2のインスタンスの第2の部分を実行し、クライアントによって記憶される情報、第1の秘密鍵、および第2の秘密鍵が、分散しきい値忘却型擬似ランダム関数の第1のインスタンスと第2のインスタンスの両方への入力である。
一実施形態では、関数の第1のインスタンスによって、サポート認証サーバが対応するルート公開鍵を取得する。一実施形態では、メイン認証サーバは、クライアントによって署名された新しい非対称鍵ペアの少なくとも一部をクライアントから受信し、対応するルート公開鍵を用いて署名を検証する。
一実施形態では、クライアントは、メイン認証サーバによって与えられたランダムネスに基づいて新しい非対称鍵ペアを作成しており、新しい非対称鍵ペアの少なくとも一部にルート秘密鍵を用いて署名している。一実施形態では、新しい非対称鍵ペアは、新しい公開鍵と新しい非公開鍵とを含み、クライアントは、新しい公開鍵にルート秘密鍵を用いて署名しており、署名された新しい公開鍵をメイン認証サーバに送信している。
一実施形態では、登録が終了してから認証が開始するまでの間に、クライアントはメモリからルート秘密鍵を除去しており、登録時に取得されるルート秘密鍵は、認証時に取得されるルート秘密鍵に等しい。一実施形態では、クライアントによって記憶される情報はユーザパスワードを含む。
一実施形態では、新しい非対称鍵ペアは、クライアントによって与えられたランダムネスおよびメイン認証サーバによって与えられたランダムネスに基づいて算出される。一実施形態では、メイン認証サーバによって取得されたルート公開鍵は、新しい非対称鍵ペアが明確にユーザに結合されるようにサポート認証サーバが所有するデジタル署名を用いて証明されている。
一実施形態では、メイン認証サーバは、ユーザIDとクライアントによって記憶される情報のハッシュに基づく第1の出力の一方または両方を受信したことに応じて第1の秘密鍵を生成する。一実施形態では、メイン認証サーバは、第1の秘密鍵に基づいて第2の出力を算出し、第2の出力をクライアントに送信し、認証時にクライアントによって取得されたルート秘密鍵は、クライアントによって記憶される情報、第2の出力、第2の秘密鍵に基づいてサポート認証サーバによって算出される第3の出力に基づく。
一実施形態では、本発明は、有形非一時コンピュータ可読媒体であって、単独のまたは組み合わされた1つまたは複数のプロセッサによって実行されたときに、本明細書で開示される方法のいずれかの実行を可能にする命令を有する有形非一時コンピュータ可読媒体を提供する。
一実施形態では、本発明は、単独でまたは組み合わされて、暗号鍵プロビジョニングのための方法の実行を可能にするように構成された1つまたは複数のプロセッサを含むメイン認証サーバを提供する。一実施形態では、メイン認証サーバの1つまたは複数のプロセッサを介して、第1の秘密鍵を生成するステップと、分散しきい値忘却型擬似ランダム関数の第1のインスタンスの第1の部分を実行することによってクライアントを登録するステップであって、関数の第1のインスタンスによって、クライアントがルート秘密鍵を取得し、メイン認証サーバが対応するルート公開鍵を取得する、ステップと、分散しきい値忘却型擬似ランダム関数の第2のインスタンスの第1の部分を実行することによってクライアントをメイン認証サーバに認証するステップであって、関数の第2のインスタンスによって、クライアントがルート秘密鍵を取得する、ステップとを含む。一実施形態では、クライアントによって記憶される情報、第1の秘密鍵、およびサポート認証サーバによって生成される第2の秘密鍵が、分散しきい値忘却型擬似ランダム関数の第1のインスタンスおよび第2のインスタンスのうちの少なくとも一方への入力である。
上述のように、本発明の一実施形態は、ユーザメッセージを放棄することができない(すなわち、ユーザによって否認することができない)ように暗号署名方式を提供することによってコンピュータネットワーキング認証におけるセキュリティリスクに対処する。一実施形態では、本発明は、パスワードを使用することによって、クライアントが離散対数仮定に基づく署名方式についての非対称鍵ペアを作成するのを可能にする。このことは、オンラインバンキングまたはIoTなどのアプリケーションにおいて有利である。
オンラインバンキングにおいて、たとえば、本発明の一実施形態は、バンキングサーバ(たとえば、メインサーバ)が、当局(たとえば、裁判所などの政府当局)が所有する独立処理システムなどのサードパーティの前でクライアントがそのようなメッセージを放棄することができないようにクライアントのメッセージを認証するのを可能にする。
IoTシステムにおいて、本発明の一実施形態は、クライアント(たとえば、車両上のセンサ、モバイルデバイス、または電化機器)によって送信されたレポート内のデータが真正にレポートの作成者になりすましたデバイスによって生成されたことを保証する。一実施形態では、メインサーバ(たとえば、バンキングサーバまたはIoTシステムを制御するための中央サーバ)は、ユーザ登録および認証時にサポートサーバと協働する。このシナリオにおける様々な特徴は、現在のフェデレーション認証シナリオ、または複数のサーバがユーザを認証するために協働する多要素認証シナリオに類似している。
一実施形態では、ユーザアカウントは、(ユーザのアカウントのサーバへの登録時に)1つまたは複数の(たとえば、複数の)機構を介してユーザのIDに結合される。たとえば、ユーザがトランザクションにデジタル的に署名することができる電子ID(eID)ドキュメントを有する場合にユーザアカウントを国識別子(ID)に関連付けることができ、メインサーバとサポートサーバの一方または両方が登録トランスクリプトの少なくとも一部に署名するようにユーザに要求する。代替的に、または追加として、ユーザアカウントをeメールアドレスまたは電話番号に関連付けることができ、一方または両方のユーザが(たとえば、登録時に)そのeメールアドレスまたは電話番号の所有権を証明することを(たとえば、ユーザが提供しなければならないワンタイムコードをeメールまたはテキスト/SMSメッセージを介して送信することによって)要求する。したがって、登録では、ユーザはサーバに一意のユーザ名およびパスワードを有することができる。
いくつかの実施形態では、ユーザは、ユーザアカウントが処理システムのIDに他の一意のIDを介して(たとえば、処理システムに関連付けられた一意の通し番号、処理システム上でたとえば、読み取り専用メモリに記憶された鍵、処理システムに割り当てられた一意の電子アドレスを介して)結合されるような処理システムである。
ユーザ名およびパスワードを用いた登録されたユーザの認証時に、各々が秘密鍵(たとえば、後述の鍵シェア)を保持している2つのサーバ(たとえば、メインサーバおよびサポートサーバ)は、クライアントデバイスを所有する(たとえば、制御する、支配する)ユーザとの対話型プロトコルを実施する。ユーザが処理システムであるとき、クライアントデバイスを処理システムの一態様(たとえば、処理システムのセンサ、処理システムのコンピューティングモジュールなど)とすることができる。対話型プロトコルの終了時に、クライアントは、秘密鍵と公開鍵(それぞれsk、pk)とを含む鍵ペアを取得し、一方、メインサーバは公開鍵pkを取得する。クライアントは、認証されたメッセージ(たとえば、署名されたメッセージ)をメインサーバに送信するために秘密鍵skを適用することができる。メインサーバは、メッセージの真正性(たとえば、署名の真正性、したがって署名されたメッセージの基本的な実質的内容)を確認するために公開鍵pkを適用することができる。
このプロトコルは、紛争が生じた場合に、公開鍵pkを用いて検証される署名を作成することができたのはクライアント(たとえば、ユーザ)のみであることをサードパーティオーディター(たとえば、サードパーティ処理システム)に実証することができるように監査可能である。言い換えれば、クライアントによって送信され(かつ署名され)たメッセージは否認不能である。プロトコルのセキュリティによって、すべてのサーバ(たとえば、メインサーバとサポートサーバの両方)が悪意を有するのでない限り、ユーザを除くどのパーティも、公開鍵pkの所有者がユーザである鍵である非対称鍵ペアを導出することができなかったはずである。
したがって、所与のユーザが所有する公開鍵pkの証拠(たとえば、公開鍵pkによって検証される署名を有するメッセージ)を受信したオーディターは、すべてのサーバ(たとえば、両方のサーバ)に悪意があるのでない限り、対応する秘密鍵skを知っているのはユーザのみである(したがって、秘密鍵skを用いて署名されたメッセージを生成することができたのはユーザのみである)と結論することができる。言い換えれば、オーディターは、メインサーバとサポートサーバのうちの少なくとも一方は正当であることを確信した場合、公開鍵pkを用いて検証可能な署名されたメッセージが秘密鍵skを用いて作成されたことを確認することができる。
一実施形態では、クライアント、メインサーバおよび/もしくはサポートサーバの一方もしくは両方、および/またはオーディターは単独でまたは組み合わされて、離散対数の知識についての以下のゼロ知識証明を実行するように構成される。
Gを生成元gを有する素数位数pの巡回群とする。y=gxであるようなxの知識についてのゼロ知識証明は、プルーバーP(たとえば、クライアント)とベリファイアV(たとえば、メインサーバまたはオーディター)との間の2者間プロトコルであり、この場合、プルーバーPは非公開入力xを有し、両方のパーティは公開入力G、g、p、yを有する。一実施形態では、非公開入力xは、離散対数のゼロ知識証明の汎用記述である。したがって、非公開入力xは、最終秘密鍵へのクライアントのランダム化寄与とすることができる。一実施形態では、"G"は巡回群であり、"p"は巡回群の位数であり、"g"は"G"の生成元であり、"y"は、プルーバーのみが知るxについてy=g^xであるように構成される。パラメータG、g、およびpは、クライアントおよび一方または両方のサーバによって合意することができ、一方、"y"は(クライアントが"x"の知識を有すると仮定すると)クライアントによって算出しサーバに明らかにすることができる。最終公開鍵は、ランダムskについてpk=g^skとすることができる。
プロトコルは、以下のように動作することができる。プルーバーPがランダムな(たとえば、擬似ランダムな)r∈Zpを取り込み、a=grをベリファイアVに送信する。ベリファイアVはランダムなc∈Zpを取り込んでPに送信する。最後に、プルーバーPはs=r+c*xを計算してベリファイアVに送信する。ベリファイアVは、gsがa*ycに等しい場合に限り受け入れる(たとえば、y=g^xであるようにプルーバーがxを知っていると確信されるような証明を受け入れる)。一実施形態では、"Zp"は、pが素数である[1,...p-1]のセットである。図2において、完全証明が"π"として示されている。
本発明の一実施形態は、後述のようにしきい値忘却型擬似ランダム関数を適用する。
擬似ランダム関数(PRF)族は、多項式時間アルゴリズムAによって選択された入力を介して関数を算出するオラクルにアクセスするどの多項式時間アルゴリズムAも、オラクルがPRF族からランダムに選択された関数を使用するシナリオとオラクルが真にランダムな関数を使用するシナリオとをそれほど好都合に区別することができないような関数の集合である。 PRF族を仮定すると、忘却型PRFは、非公開入力xを有するクライアントCと非公開入力kを有するサーバS(たとえば、メインサーバとサポートサーバの一方または両方)との間の対話型2者間プロトコルであり、それによって、対話の終了時に、クライアントはy=Fk(x)を認識するがkについて何も知らず、一方、サーバはxについて何も知らない。一実施形態では、kは関数族内の関数の添え字である。
(t,n)しきい値忘却型PRF(TOPRF)は、非公開入力xを有するクライアントCと、各々が非公開入力kを共有するn個のサーバS1,...,Snとの間の対話型プロトコルであり、それによって、クライアントは、S1,..., SnにおけるサーバのサブセットS(たとえば、メインサーバおよびサポートサーバ)と対話し、サブセットSのサイズが既定のしきい値tを超える場合にのみy=Fk(x)を認識する。したがって、クライアントCは、kについて何も知らず、またいずれのサーバによって保持されているkのシェアについても何も知らず、さらにサーバはxについて何も知らない。Stanislaw Jareckiら、“TOPPSS: Cost-minimal Password-protected Secret Sharing based on Threshold OPRF”、ACNS (2017)が、参照により本明細書に組み込まれており、効率的なTOPRFについて説明している。このTOPRFについては、2つのサーバS1およびS2のみを使用するインスタンス化、すなわちn=t= 2によって以下において検討する。
Gを素数位数pの巡回群とし、H1およびH2を各々が任意の文字列をGに写像する2つのハッシュ関数とする。サーバ(たとえば、メインサーバおよびサポートサーバ)の非公開入力をk∈Zpとし、この非公開入力が、k=k1+k2(すなわち、kはk1およびk2に基づく)であるように共有されるものと仮定する。ここでk1はサーバS1(メインおよび一次サーバの一方)に対して非公開にされ、k2はサーバS2(たとえば、メインおよび一次サーバの他方)に対して非公開にされる。クライアントは、非公開入力x(たとえば、ユーザのパスワード)上で、Zpから一様にランダムにrを取り込み、H1(x)rをサーバS1とサーバS2の両方に送信する。クライアントからメッセージaを受信すると、サーバSi(i=1,2)は
Figure 2023503235000002
 を計算してクライアントに送信する。S1からメッセージb1を受信しS2からメッセージb2を受信すると、クライアントはy=H2(x,(b1*b2)1/r)を出力する。一実施形態では、rsk=yである。
図1を参照するとわかるように、本発明の一実施形態は、ユーザUが(たとえば、ユーザUによって制御されるクライアントを介して)メインサーバS1(「第1のサーバ」または「第1の認証サーバ」とも呼ばれる)およびサポートサーバS2(「第2のサーバ」または「第2の認証サーバ」とも呼ばれる)と対話するセットアップ(「登録」とも呼ばれる)を含む。さらに、メインサーバS1とユーザUとの間の紛争を解決するように構成されたオーディターA(「第3のサーバ」とも呼ばれる)が存在する。オーディターAと2つのサーバは、たとえば、各パーティが他の2つのパーティの公開鍵を事前に記憶しているデジタル署名方式によって、真正なチャネルを介して通信することができる。デジタル署名方式を前提として、PK1、PK2、およびPKAをメインサーバS1、サポートサーバS2、およびオーディターAの公開鍵とする。上記と同様に、Gを生成元gを有する素数位数pの巡回群とし、H1、H2を任意の文字列をGに写像するハッシュ関数とする。メインサーバおよび/またはオーディターAは、以下でさらに説明するようにベリファイアVとして働くことができる。
一実施形態は、図1に示すような登録を含む。登録時に、ユーザUは一意のユーザID(たとえば、ユーザ名)およびパスワードpw("pwd"とも呼ばれる)を取り込む。各サーバSi(i=1,2)はZpからランダム鍵kiを取り込む。一実施形態では、各サーバは、サーバのそれぞれの鍵の集計(たとえば、和)がkに等しくなるようにランダム鍵ki(「鍵シェア」とも呼ばれる)を取り込む。このことは、kを事前に決定し、次いで各サーバにそれぞれの和がkに等しくなるようにkiを取り込ませることとは異なる。集計/加算は、各鍵シェアkiを加算するときに行うことができる。たとえば、k1=53およびk2=57である場合、k1およびk2の集計/和を110とすることができる(すなわち、加算)。
ユーザUはユーザIDをサーバS1とサーバS2の両方に送信する(たとえば、ユーザUのクライアントがユーザIDを送信する)。さらに、ユーザはa=H1(pw)rを送信することができ、ここでH1はハッシュ関数であり(たとえば、両方のサーバに既知であるハッシュ関数)、rは、r∈Zpであるようにランダムに選択される。一実施形態では、Zpは[1,...p-1]のセットであり、ここで"p"は素数である。一実施形態では、Zpのセットにおけるすべての数が素数である。次に、ユーザUならびに2つのサーバS1およびS2は、たとえば上記で参照により組み込まれたStanislaw Jareckiらに記載されたようにTOPRFプロトコルを実施し、Stanislaw Jareckiらでは、ユーザUならびに2つのサーバS1およびS2の非公開入力はそれぞれ、pw、k1、およびk2である。
プロトコルの終了時に、ユーザUはy=Fk(pw)を認識する。ここでk=k1+k2である。この時点で、ユーザUはルート秘密鍵リスクrsk=yを設定し、対応するルート公開鍵rpk=grskを算出する。ユーザはルート公開鍵rpkを両方のサーバS1およびS2に送信する。ユーザUは、パスワードpwおよびuserID(たとえば、クライアントはパスワードpwおよびユーザIDをローカルに記憶する)。一実施形態では、"g"はグループ"G"の生成元であり、クライアント、一方もしくは両方のサーバ、および/またはベリファイアによって合意された公開パラメータのセットを表す。
ユーザUからサーバへの最後のメッセージ(すなわち、ルート公開鍵rpkを含むメッセージ)は、一実施形態では、2つのサーバS1およびS2によって相互に認識される認証機構によって認証される。このことは図1では"authID"によって示されている。たとえば、ユーザUがドキュメントにデジタル的に署名することを可能にされた電子IDカードを保持している場合、ユーザUはルート公開鍵rpkにデジタル的に署名してもよく、したがって、authIDはユーザのeIDを使用することによって作成されたデジタル署名である。ユーザUが上記のような電子IDカードを保持しない場合、2つのサーバS1およびS2の各々は、暗証コードをユーザUの電話番号またはeメールアドレス(たとえば、一意の電子アドレス)に(たとえば、ユーザUのクライアントに)送信し、ユーザがeメールアドレスまたは電話番号(たとえば、一意の電子アドレス)を有することを検証するために、ユーザUにそのコードを返すように依頼することができる。この場合、authIDはワンタイムコードである。
サポートサーバS2が、たとえば、上記の機構の一方によってユーザIDを検証する場合、サポートサーバS2はユーザUによって受信される<userID, authID, rpk>にデジタル的に署名し、署名σを(たとえば、ユーザUを介して)メインサーバS1に提供する。最後に、メインサーバS1はタプル<userID, authID, k1, rpk,σ>をそれぞれのユーザデータベース(メモリ)に記憶し、一方、サポートサーバS2は<userID, k2>をそれぞれのユーザデータベース(メモリ)に記憶する。サポートサーバはrpkまたはauthIDを記憶する必要はない。メインサーバおよびサポートサーバは、複数のユーザの各々についてそれぞれのタプルを記憶することができる。
図1は登録プロトコルを示す。一実施形態は認証(たとえば、登録後認証)を含む。認証プロトコルの一実施形態は図2に示されている。図2の認証プロトコルの間に算出されるルート秘密鍵rskおよびルート公開鍵rpkを図1の登録プロトコルの間に算出されるルート秘密鍵rskおよびルート公開鍵rpkと等しくすることができる。一実施形態では、各ユーザは一度登録するだけでよい。
登録後、ユーザは認証プロトコルを複数回(たとえば、無限に)実施することができる。たとえば、認証プロトコルは、すでに登録されたユーザが署名されたメッセージを送信することを望むたびに自動的に実施することができる。図2の認証プロトコルの間に算出されるルート秘密鍵rskおよびルート公開鍵rpkが図1の登録プロトコルの間に算出されるルート秘密鍵rskおよびルート公開鍵rpkと等しい実施形態では、ユーザ(たとえば、ユーザのクライアント)は、セキュリティを強化するために登録プロトコル後および認証プロトコル後にメモリからルート秘密鍵rskおよびルート公開鍵rpkを削除(除去)することができる。
図2に示すように、ユーザUがメインサーバS1に認証し、新しい非対称鍵ペアを生成することを望むとき、3つのパーティ(ユーザUならびにサーバS1およびS2)は以下のプロトコルを実施する。ユーザUがuserIDをサーバS1とサーバS2の両方に送信する。メインサーバS1はそれぞれのユーザデータベースから<userID, authID, k1, rpk,σ>を取り出し、一方、サポートサーバS2はそのそれぞれのデータベースから<userID, k2>を取り出す。
次に、ユーザUはZpからランダムXUを取り込み、
Figure 2023503235000003
 を算出し、z=H2(w)をサーバS1に送信する。さらに、ユーザはa=H1(pw)rを与えることができ、この場合、H1は両方のサーバに既知のハッシング関数であり、rはr∈Zpであるようにランダムに選択される。3つのパーティはここで、ユーザU、サーバS1、およびサーバS2についての非公開入力がそれぞれpw、k1、およびk2であるTOPRFプロトコルを実施する。反復の終了時に、ユーザUはルート秘密鍵rsk=Fk(pw)を認識し、この場合、k=k1+k2である(すなわち、kはk1およびk2に基づく)。この認証プロトコルの間に取得されるルート秘密鍵rskを図1の登録プロトコルの間に取得されるルート秘密鍵rskと等しくすることができる。
メインサーバS1はランダムXSをZpから取り込み、XSをユーザUに送信する。ユーザUは、新しい秘密鍵skをsk=XU+XSとして算出し、対応する新しい公開鍵pkをpk=gskとして算出する。ユーザUは、ルート秘密鍵rskを使用して、σ*が得られる署名である新しい公開鍵に署名する。
ユーザUは、πが底gにおけるwの離散対数の知識のゼロ知識証明であるpk、σ*、w、πをメインサーバS1に送信する。メインサーバS1は、zがH2(w)と一致すること、πが底gにおけるwの離散対数の知識の有効な証明であること、σ*がrpkに基づくpkの有効な署名であること、および
Figure 2023503235000004
 であることを検証する。すべての検査が成功した場合、メインサーバS1は、pkをユーザUの有効な公開鍵として受け入れる(たとえば、メインサーバは、公開鍵pkが、ユーザUのみが有する秘密鍵skと非対称鍵ペアを形成することを受け入れる)。この段階では、ユーザUは、メインサーバS1に送信されるメッセージに署名するために秘密鍵skを適用してもよく、メインサーバS1は、公開鍵pkを使用することによって署名を検証することができる。
ユーザが所与のセッションにおいてメッセージへの署名を終了すると、ユーザUは、セキュリティを強化するためにメモリから秘密鍵skを除去することができる。ユーザUは、同時にメモリ(たとえば、クライアントのメモリ)からルート秘密鍵rskを除去することができる。代替として、ユーザUは、秘密鍵skが生成された直後にメモリからルート秘密鍵を除去することができる。
セッションは、たとえば、ユーザUがある時間の間非アクティブ状態になったときに終了することができる(たとえば、ソフトウェアプログラムが、クライアントタイムアウトに関するメッセージに署名するために秘密鍵skを適用する)。代替的に、または追加として、セッションは、メインサーバが公開鍵pkを用いて検証されたメッセージの認証を停止することを決定したときに(たとえば、skおよびpkが生成されてからある時間が経過した後に)終了することができる。新しいセッションを開始するには、新しい非対称鍵ペアsk、pkを生成するために図2の認証プロトコルを自動的に再実施することができる。ユーザUは、前のセッションが満了し、クライアント上で実行されているソフトウェアがメッセージに署名するために秘密鍵skが必要になるたびに、新しいセッションを自動的に開始することができる。
この方法は、紛争が生じた場合にさらに監査を含むことができる。この場合、メインサーバS1は、公開鍵pkに基づいて検証される署名がユーザUによって作成されたことをサードパーティオーディターAに実証することを望むことがある。そうするために、メインサーバS1はオーディターAにタプル<userID, authID, rpk,σ>を提供することができる。この段階では、オーディターAは、σが公開鍵PK2に基づく<userID, authID, rpk>についての有効な署名であること、およびσ*がルート公開鍵rpkに基づく公開鍵pkについての有効な署名であることを確認する。両方の検査が成功した場合、オーディターAは、公開鍵pkはユーザUが所有する鍵である(たとえば、秘密鍵skを用いて署名されたメッセージは真正にユーザによって作成された)と結論する。
本発明の実装形態はいくつかの改良および利点を提供する。たとえば、本発明の実施形態による否認不能なメッセージを提供するための方法は、以下のステップのうちの1つまたは複数を含む。
1) ユーザがユーザのパスワードから秘密鍵(たとえば、ルート秘密鍵)を取り出すことができ、一方、対応する公開鍵(たとえば、ルート公開鍵)はユーザおよびメインサーバに既知であるように、ユーザとメインサーバおよびサポートサーバとの間でしきい値忘却型擬似ランダム関数を使用するステップ。一実施形態では、サポートサーバはルート公開鍵を知る必要がない。
2) ユーザによって、ユーザとメインサーバの両方によって与えられるランダムネスを使用して算出される新しい非対称鍵ペアを証明するためにステップ1)でユーザによって取り出された秘密鍵を適用するステップ。
3) ステップ2)の新しい非対称鍵ペアを明確にユーザに結合できるようにサポートサーバによって作成されたデジタル署名を用いてステップ1)の公開鍵を証明するステップ。
本発明の一実施形態では、ユーザ認証のための方法は、以下のステップのうちの1つまたは複数を含む。
1) 各サーバが秘密鍵を有する(たとえば、各サーバが図1におけるk1およびk2などのそれぞれの秘密鍵を有する)2つの認証サーバ、すなわち1つのメインサーバと1つのサポートサーバをセットアップするステップ。
2) パスワードを取り込むことによってユーザを認証サーバに登録し、ユーザがルート秘密鍵を取得し、一方、メインサーバがサポートサーバによって証明された対応する公開鍵(たとえば、ルート公開鍵)を取得するようにユーザと2つのサーバとの間でしきい値忘却型擬似ランダム関数を実行するステップ。
3) ユーザがルート秘密鍵を取得するように、パスワードを非公開入力として有するユーザと各々がそれぞれの秘密鍵を非公開入力として有する2つのサーバとの間でしきい値忘却型擬似ランダム関数を実行することによってユーザを認証するステップ。一実施形態では、ステップ3のルート秘密鍵はステップ2のルート秘密鍵と同じである。ルート秘密鍵を使用して新しい鍵ペアを認証することができる。一実施形態では、ユーザが認証を望むたびに、ユーザはルート秘密鍵を取り出し、このルート秘密鍵を使用して新しい鍵ペアを証明する。
この方法は、以下のステップの一方または両方をさらに含むことができる。
4) ユーザによって、新しい非対称鍵ペアを証明するためにルート秘密鍵を適用するステップ。
5) ルート公開鍵を使用することによって(すなわち、ルート公開鍵に基づいて)証明された新しい非対称鍵ペアの有効性を検出するステップ。
したがって、本発明の実施形態は、クライアントがパスワードを使用することによって非対称鍵ペアを生成するのを可能にし、有利には他のパーティがパスワードの知識なしに同じ鍵ペアを作成してしまい得ることがないようにする。これに対して、現在のパスワードベース鍵導出プロトコルは、対称鍵を作成するのを可能にし、対称鍵は、少なくともいくつかのデジタル署名アプリケーションでは非対称鍵よりも有効性が低い。
クライアントは、サーバと対話することを望むユーザによって制御される1つまたは複数のデバイス(たとえば、デスクトップ、ラップトップ、携帯電話、スマートカード、センサなど)とすることができる。ユーザによって実行されると記載されたあらゆるタスクは、一実施形態においてクライアントによって実行されると理解することができ、逆についても同様である。一実施形態では、ユーザとクライアントは同じ処理システムに相当する。一実施形態では、ユーザとクライアントの一方は、処理システム(たとえば、車両の処理システム、家庭電化製品を制御するための処理システム、モバイルデバイスの処理システム)であり、ユーザとクライアントの他方は、処理システムの一要素(たとえば、カメラ、全地球測位システム、加速度計、温度センサ、圧力センサ、運動センサなどのセンサ)である。本明細書で開示されたプロトコルは、ユーザとクライアントに自動的に秘密鍵skを取得するように協働させる。ユーザ/クライアントは、センサ読み取り値を含むメッセージに署名するために秘密鍵skを適用する。
一実施形態では、メインサーバおよびサポートサーバは、それぞれに異なる位置に離隔された互いに独立したプラットフォーム(たとえば、処理システム)である。メインサーバおよびサポートサーバは、インターネットを介して排他的に通信するように構成することができる(たとえば、インターネット以外のいずれのネットワークを介しても接続されないようにすることができる)。一実施形態では、メインサーバとサポートサーバは直接通信するわけではない。その代わり、メインサーバからサポートサーバに送信されるあらゆる情報がクライアントを通じて経路制御され、逆の経路についても同様である。
一実施形態では、オーディターは、メインサーバ、サポートサーバ、およびクライアントから独立したプラットフォーム(たとえば、処理システム)である。オーディターは、公開鍵pkがクライアントにのみ知られている公開鍵skと非対称ペアを形成していることを確認した後アクティビティを実行する(たとえば、メッセージをクライアントに送信する)ように構成することができる。オーディターからクライアントに送信されたメッセージは、非公開鍵skを有するクライアントのみがメッセージを解読できるように公開鍵pkを用いて暗号化することができる。
図3を参照するとわかるように、処理システム300は、1つまたは複数のプロセッサ302と、メモリ304と、1つまたは複数の入出力デバイス306と、1つまたは複数のセンサ308と、1つまたは複数のユーザインターフェース310と、1つまたは複数のアクチュエータ312とを含むことができる。処理システム300は、ユーザ/クライアント、メインサーバ、サポートサーバ、およびオーディターのうちの1つまたは複数(たとえば、すべて)を含む、本明細書で開示された各コンピューティングシステムを表すことができる。
プロセッサ302は、各々が1つまたは複数のコアを有する1つまたは複数の互いに異なるプロセッサを含むことができる。互いに異なるプロセッサの各々は、同じ構造を有することも、または互いに異なる構造を有することもできる。プロセッサ302は、1つまたは複数の中央処理装置(CPU)と、1つまたは複数のグラフィックス処理ユニット(GPU)と、回路(たとえば、特定用途向け集積回路(ASIC))、デジタル信号プロセッサ(DSP)などを含むことができる。プロセッサ302は、共通の基板または複数の異なる基板に取り付けることができる。
プロセッサ302は、少なくとも、1つまたは複数の互いに異なるプロセッサのうちの1つがある機能、方法、または動作を具現化する動作を実行できるときに、その機能、方法、または動作を実行するように構成される(たとえば、機能、方法、または動作の実行を可能にするように構成される)。プロセッサ302は、たとえばメモリ304上に記憶されたコードを実行し(たとえば、スクリプトを解釈し)、ならびに/または1つもしくは複数のASICを通じてデータの転送によって機能、方法、または動作を具現化する動作を実行することができる。プロセッサ302、したがって処理システム300は、本明細書で開示されるあらゆる機能、方法、および動作を自動的に実行するように構成することができる。したがって、処理システム300は、本明細書で説明するプロトコル、デバイス、機構、システム、および方法のうちのいずれか(たとえば、すべて)を実施するように構成することができる。
たとえば、本開示において、方法もしくはデバイスがタスク"X"を実行する(またはタスク"X"が実行される)と述べられるとき、そのような文は、処理システム300をタスク"X"を実行するように構成できると開示するものと理解すべきである。処理システム300は、少なくとも、プロセッサ302がある機能、方法、または動作を実行するように構成されるときにはその機能、方法、または動作を実行するように構成される。
メモリ304は、揮発性メモリと、不揮発性メモリと、データを記憶することができる任意の他の媒体とを含むことができる。揮発性メモリ、不揮発性メモリ、および任意の他の種類のメモリは、複数の異なる位置に位置し、異なる構造を有する複数の異なるメモリデバイスを含むことができる。メモリ304は、リモートに設けられた(たとえば、クラウド)ストレージを含むことができる。
メモリ304の例には、RAM、ROM、フラッシュメモリ、EEPROMなどの非一時的コンピュータ可読媒体、DVD、Blu-Ray(登録商標)ディスク、磁気記憶装置、ホログラフィック記憶装置、HDD、SSDなど任意の種類の光学記憶ディスク、命令またはデータ構造の形をしたプログラムコードを記憶するために使用できる任意の媒体などが含まれる。本明細書で説明するあらゆる方法、機能、および動作は、メモリ304に保存される有形および/または非一時的機械可読コード(たとえば、解釈可能なスクリプト)の形で完全に具体化することができる。
入出力デバイス306は、ポート、アンテナ(すなわち、トランシーバ)、プリント導電パスなどのデータを転送するための任意の構成要素を含むことができる。入出力デバイス306は、USB(登録商標)、Display Port(登録商標)、HDMI(登録商標)、Ethernetなどを介した有線通信を可能にすることができる。入出力デバイス306は、適切なメモリ306との電子、光学、磁気、およびホログラフィック通信を可能にすることができる。入出力デバイス306は、WiFi(登録商標)、Bluetooth(登録商標)、セルラー(たとえば、LTE(登録商標)、CDMA(登録商標)、GSM(登録商標)、WiMax(登録商標)、NFC(登録商標))、GPSなどを介したワイヤレス通信を可能にすることができる。入出力デバイス306は、有線通信経路および/またはワイヤレス通信経路を含むことができる。
センサ308は、環境の物理測定値を取り込んでプロセッサ302に報告することができる。ユーザインターフェース310は、ディスプレイ、物理ボタン、スピーカ、マイクロフォン、キーボードなどを含むことができる。アクチュエータ312は、プロセッサ302が機械的な力を制御するのを可能にすることができる。
処理システム300は分散させることができる。たとえば、処理システム300のいくつかの構成要素は、リモートホストネットワークサービス(たとえば、クラウドコンピューティング環境)に存在することができ、一方、処理システム300の他の構成要素は、ローカルコンピューティングシステムに存在することができる。処理システム300は、あるモジュールが図3に示す複数の特徴/機能を含むモジュール設計を有することができる。たとえば、入出力モジュールは揮発性メモリと1つまたは複数のプロセッサとを含むことができる。別の例として、個々のプロセッサモジュールは読み取り専用メモリおよび/またはローカルキャッシュを含むことができる。
本発明の実施形態について以下にさらに説明する。一実施形態は、監査可能な非対称パスワード認証による公開鍵確立に関する。
1. 概要
上述のように、ユーザによって生成されたメッセージの非否認は、オンラインバンキングシナリオからIOTシナリオまでの範囲のいくつかのアプリケーションにおいて望ましい機能である。しかし、この場合、証明された公開鍵が必要であり、その結果、ユーザが証明書を(スマートカードなどのクライアントデバイスのメモリに)記憶しなければならないので使い勝手が不十分であることが多い。使い勝手の良い代替手段は「クラウドベース」PKIを有する手段である。概して、各ユーザはクラウドにおけるサーバに記憶されたPKI証明書を有し、ユーザはパスワードまたはワンタイムコードを介してサーバに認証し、サーバにユーザに代わってメッセージに署名するよう要求する。したがって、所与のメッセージ上の署名がサードパーティではなくユーザによってユーザのパスワードを用いて許可されたものであることをサーバがサードパーティに証明することはできない。さらに、サーバがユーザの証明された鍵を記憶するので、サーバが、そのユーザになりすますことを試みて任意のメッセージに署名した可能性がある。言い換えれば、ユーザは、署名がサーバによって同意なしに作成されたと主張することによって、メッセージに署名したことを否定することができる。同じことが、秘密鍵がユーザのパスワードから確定的に導出される場合にも当てはまる。この場合も、サーバがパスワードを知ることによって、ユーザになりすます可能性がある。
一実施形態は、監査可能な非対称パスワード認証による公開鍵確立(A2PAKE)を導入することによってユーザメッセージの非否認のための「パスワード専用」解決手段を提供する。これは、公開鍵があらゆる参加者に出力されるが、秘密鍵は1つのパーティ(たとえば、ユーザ)のみに非公開出力される非対称鍵ペアを生成するPAKE型プロトコルである。さらに、このプロトコルは監査することができ、すなわち、公開鍵がユーザによって実行されるプロトコルによって出力されると仮定すると、サーバは、対応する秘密鍵がこの特定のユーザによって保持されることをサードパーティに証明することができる。したがって、ユーザがその秘密鍵を用いてメッセージに署名した場合、メッセージは否認不能である。A2PAKEの汎用的に結合可能な構成および分散忘却型擬似ランダム関数に基づくインスタンス化が提供される。
オンラインアプリケーションにおける非否認は、デジタル署名およびPKI証明書に基づくことが多い。たいていのサーバはPKI証明書を保持していると仮定すると、サーバによって生成されたメッセージの非否認を実現することができる。このことは、ユーザによって送信されるメッセージには当てはまらない。その理由は、ユーザがエントロピーのみのパスワードを使用してサーバに認証することが多いからである(ユーザメッセージの非否認は、ユーザがPKIクライアント証明書を有する場合には簡単に実現されるが、ユーザは証明書がインストールされたデバイスからしかサーバに接続できないのでPKIクライアント証明書はユーザエクスペリエンスを妨げる)。
しかし、ユーザメッセージの非否認は、いくつかのシナリオにおいて望ましい特性である。たとえば、オンラインバンキングアプリケーションにおいて、バンキングサーバは、たとえば資金を他のアカウントに転送する要求を認証することをユーザに要求することがあり、後で紛争が生じた場合、サーバは、ユーザが本当に特定の動作を要求したことをサードパーティに(たとえば、裁判所において)証明することを望む場合がある。同様に、IoTアプリケーションにおいて、処理サーバは特定のデータベースレポートを作成したデバイスの所有者を特定することを望む場合がある。
ある解決手段では、「クラウドベースPKI」が利用され、各ユーザはクラウドにおけるサーバに記憶されたPKI証明書を有し、ユーザは、パスワードまたはワンタイムコードを介してサーバに認証し、ユーザに代わってメッセージに署名することをサーバに要求する。この構成は、いくつかの会社および国家機関によって使用されている。しかし、この構成では、サードパーティは、真正にユーザによって作成されたのはどの署名であるかおよびユーザのパスワードを用いたサーバまたは悪意あるサードパーティによるなりすましの試みの結果はどれであるかを示すことはできない。サーバがユーザの証明書を保持しており、ユーザに代わって任意のメッセージに署名できるので、ユーザは、たとえばその署名がサーバによって同意なしに作成されたと主張することによって、メッセージに署名したことを否定することができる。
この問題は、署名鍵が(たとえば、PBKDF2鍵導出関数を使用することによって)ユーザのパスワードから導出される場合でも生じる。サーバは、パスワードを記憶することによって、同じ鍵を導出し、ユーザに代わってメッセージに署名する場合がある。同様に、サーバがパスワードの(ソルト付きの)一方向関数を保持している場合でも、ブルートフォース攻撃によって、サーバは正しい秘密鍵を導出することができる。
パスワード認証鍵交換(PAKE)は、2つのパーティが共通のパスワードにのみ依存することによって認証を行い協働して強力な暗号鍵を確立するのを可能にする。しかし、PAKEプロトコルは対称鍵を取り扱い、したがって、対称であることの認識によって2つのパーティのいずれも他方に代わってメッセージを認証することが可能になるので、特定のアプリケーションには適していない。
パスワードのみを使用するユーザについての非否認の問題の解決には、PAKE型プロトコルを含めることができ、この場合、公開鍵が公開出力されるが、秘密鍵が1つのパーティに非公開出力される非対称鍵ペアが生成される。非否認は監査可能である場合に適切であり、すなわち、サードパーティがメッセージを作成したのがメッセージの送信元であることを判定できるときに適切である。
したがって、一実施形態では、公開鍵のみを受信するパーティが、そのパーティのピアによって対応する秘密鍵が生成されていなければならないことを証明できると定めている。すなわち、一実施形態では、クライアントCが鍵ペアsk、pk(それぞれ秘密鍵および公開鍵)を受信し、サーバSのみが公開鍵pkを認識するクライアント-サーバプロトコルのトランスクリプトTを仮定すると、このサーバは、秘密鍵skがTによって出力される公開鍵pkと整合する(たとえば、非対称ペアを形成する)ことを認識する可能性があるのはCだけであることをサードパーティに証明できると定めている。
トランスクリプトを監査する、すなわち公開鍵の所有者を特定するには、ユーザ「ID」を確立し検証することが必要になることが多い。一実施形態は、ユーザのためにID作成および管理を行う。たとえば、ユーザがeIDを保持している場合、登録中のユーザのeIDを登録時に検証し、そのユーザの新しいアカウントに結合することができる。後で、監査時に、公開鍵が登録時に使用されたIDの所有者が所有する鍵であることを判定することができる。これは、IDブートストラッピング機構であり、(PCに取り付けられたスマートカードリーダーを使用することによって) ユーザのeIDを用いて登録トランスクリプトに署名するようユーザに要求する。別の選択肢では、ユーザが一意の電子アドレス(たとえば、eメールアドレス)を用いて登録し、登録時に、ユーザは(たとえば、ユーザのインボックスにワンタイムコードを受信することによって)eメールアドレスの所有権を証明しなければならず、新しいアカウントをそのeメールアドレスに結合しなければならない。監査時には、公開鍵が、登録時に使用されたそのeメールアドレスの所有者が所有する鍵であると判定することができる。同様に、携帯電話番号(たとえば、テキストメッセージを介して送信されるワンタイムコード)によってIDを検証することができる。
一実施形態では、サードパーティは、サーバがユーザに代わって鍵ペアを作成することによってユーザを陥れることができない場合にのみ特定の公開鍵がそのユーザによって作成されたことを確信することができる。鍵ペアがパスワードから生成される場合、一実施形態は、ユーザのみが完全なパスワードを認識することを保証し、しかもこの実施形態は、(i)サーバがユーザを認証するのを可能にし、(ii)サーバがオフラインブルートフォース攻撃をしかけるのを妨げる。
一実施形態は、サーバ違反に起因するパスワード漏れを軽減することを目標としていくつかのサーバ間でパスワードを分割する。したがって、一実施形態ではユーザを認証するための複数のサーバを導入し、それによって、すべてのサーバに悪意があるのでない限り、サーバが(たとえば、ユーザのパスワードを復元するためにオフラインブルートフォース攻撃を実行することによって)ユーザを陥れることができないようにする。2サーバシナリオでは、「メイン」サーバが、公開鍵をプロトコルの出力として取得し、後で監査を目的としてサードパーティとなり、すなわち、公開鍵が特定のユーザが所有する鍵であることを証明し、一方、「二次」サーバ(「サポートサーバ」とも呼ばれる)が、ユーザを認証する際に二次サーバのピアメインサーバをサポートし、協働して監査証拠を作成する。サーバのうちの1つが正当である限り、サードパーティは、プロトコルによって出力された公開鍵について、その実行に関わったユーザを特定することができる。
一実施形態は、A2PAKEと呼ばれる、2サーバシナリオについて上記の特性を有する暗号プロトコルを正式に提供する。一実施形態は、ユーザによって生成された鍵の非否認および悪意のあるサーバに対する陥れ不能性のセキュリティ要件を取り込むA2PAKEの理想的な機能を実現する。さらに、一実施形態は、A2PAKEの機能を実現するプロトコルを提供し、Canettiの汎用的結合可能性フレームワークにおいて安全であることを証明する。プロトコルの一実施形態の重要な要素は、分散忘却型擬似ランダム関数である。一実施形態は、Pythonで書かれたプロトタイプ実装形態を導入する。スループット、レイテンシ、および通信オーバヘッドを評価するために実施された評価の結果を示す。
2. パスワードベース暗号化の概要
パスワードベース暗号化の基本的な考えは、低エントロピーパスワードのみに依存することによって強力な暗号を確保するプロトコルを設計することである。
PKCS#5標準は、(対称)暗号化またはメッセージ認証に使用すべき対称鍵を導出するためにパスワードをどのように使用すべきかを示す。パスワード認証鍵交換(PAKE)は、同じパスワードを保持している2つのパーティが互いに認証し対称鍵を確立するのを可能にする。クライアント-サーバ環境では、パスワードを複数のサーバ間で分割することによってサーバにおけるパスワードデータベースの侵害が軽減されることがある。しきい値PAKE(TPAKE)は、しきい値ベース暗号化を借用し、クライアントが少なくともt<n個のサーバと協働する場合にのみクライアントが首尾よく認証されるように認証機能をn個のサーバにわたって分散させる。パスワードは、敵が侵害するサーバがt-1個以下である限り漏れない。たいていのTPAKEプロトコルは、クライアントが各サーバとともにペアごとの独立した鍵を確立するのを可能にする。
パスワード認証公開鍵暗号化(PAPKE)は、パスワードを用いて公開鍵暗号化を強化する。詳細には、鍵ペアの生成がパスワードに結合され、したがって、暗号化もパスワードに結合される。したがって、暗号文を解読すると、暗号化時に使用されたパスワードが鍵ペアが生成されたときに使用されたパスワードと一致する場合にのみ元のメッセージが明らかになる。したがって、PAPKEは、(受信側がその公開鍵を生成する際に敵が受信側のパスワードを推測しない限り)受信側の公開鍵に置き換わる中間者が存在するにもかかわらず機密性を維持する。
署名鍵がユーザとサーバとの間で分割され、ユーザのシェアが基本的にユーザのパスワードであり、それによって、ユーザがサーバの助けを得て署名を作成することができるパスワードベース署名が提案されている。サーバは、ユーザを認証せず、パスワードにブルートフォースを加えることによって任意のユーザの完全な署名鍵を復元することができる。ユーザがスマートカードなどのパーソナルデバイスを携帯することを必要とする に、パスワードベース署名についてのユーザ認証およびブルートフォース攻撃に対する耐性が導入された。
パスワードハードニングサービスは、パスワードデータベース漏れの影響を軽減しつつパスワードベース認証を可能にする。パスワードハードニングサービスの背景にある考えは、認証サーバとパスワードの(鍵付き)ハッシュをブラインドに算出する「暗号化サービス」をペアにすることである。認証サービスにおけるパスワードデータベースは、暗号化サービスの鍵が侵害されない限り、データベースの漏れによってパスワードが明らかになることがないようにそのようなハッシュを記憶する。
PASTAはパスワードベースしきい値トークンベース認証を提案しており、この場合、OAuth (https://oauth.net/)などのプロトコルにおけるIDプロバイダの役割がいくつかのパーティに分散され、ユーザがしきい値数のサーバに認証することによってのみ認証トークンを取得する。
パスワード付き秘密共有(PPSS)は、ユーザが秘密のシェア、たとえば暗号鍵をサーバのセット上に安全に記憶するのを可能にし、一方、復元は、正しいパスワードを使用するかまたは所与のしきい値よりも多くのサーバをコラプトすることによってのみ実現可能である。A2PAKEの実施形態とPPSSの実施形態には重要な違いがある。第1に、PPSSはユーザ認証の問題を解決しない。さらに、一実施形態では、A2PAKEは前方秘匿性をもたらし、パスワードの漏れが過去のセッションを侵害することはなく、悪意のあるクライアントまたはサーバにもかかわらず高エントロピー鍵を出力する。さらに、PPSSサーバの侵害が生じると、直ちにユーザパスワードが明らかになる。すべてのA2PAKEサーバが侵害された場合、一実施形態では、パスワードを知るには、この場合もブルートフォース攻撃が必要であり、したがって、この場合も高エントロピーパスワードがセキュリティを実現することがある。最後に、一実施形態は、A2PAKE機能に監査可能性を埋め込んでおり、一方、サードパーティによってPPSSSを監査可能にするにはどうしたらよいかは明らかではない。
3. A2PAKE
3.1 汎用的結合可能性モデル
汎用的結合可能性モデル("Canetti"とも呼ばれる)の基本的な特徴について検討する。一般的には、プロトコルПσUCは、どんなPPT環境Zでも、セットアップ仮定Gと対話できるプロトコルПの実行をPPTシミュレータSと理想機能Fとの協調実行と区別できなくなるようなPPTシミュレータSが存在する場合にセットアップ仮定Gを用いて理想機能Fを実現する。環境Zは、入力をプロトコルのすべてのパーティに提供し、どのパーティがコラプトされるかを決定し(静的コラプト(static corruption)が考慮され、この場合、環境はプロトコルが開始する前にコラプトされるパーティを決定する)、ネットワークにおけるメッセージの順序をスケジューリングする。理想機能を指定する際、Canettiの「遅延出力」という用語が使用される。すなわち、一実施形態は、機能Fが公開遅延出力MをパーティPiに送信したときには、Mがまずシミュレータに送信され、次いでシミュレータによって肯定応答された後にのみPiに転送され、機能Fが非公開遅延出力MをパーティPiに送信したときには、Mがまずシミュレータに通知され、次いでシミュレータによって肯定応答された後にのみPiに転送されるように構成される。
3.2 理想機能
TABLE 1に提示された理想機能
Figure 2023503235000005
 の一実施形態について説明する。上記で指摘したように、「クライアント」は、特定の「ユーザ」によって制御される1つまたは複数のデバイスを含む。したがって、クライアントは、「ユーザ」が実行すると記載されている任意の機能を実行し実現するように構成される。一実施形態は、いくつかのクライアント{C1, ..., Cn}と2つの非結託サーバS1、S2を提供する。理想機能は、3つ以上のサーバに拡張することができ、1つのサーバが正当である(すなわち、1つのサーバに悪意がない)限りセキュリティが取得されるが、説明を簡単にするために2つのサーバの例示的なケースについて説明する。
サーバS1は「メイン」サーバとして指定される。クライアントの鍵を認識しているのがサーバであり、したがって、サーバはクライアントによって署名されたメッセージを検証することができ、紛争が生じた場合にはオーディターとなる。他方のサーバS2は、「サポート」サーバ(「二次サーバ」とも呼ばれる)として指定され、メインサーバがユーザを認証するのを助け、重要なことには監査証拠を作成するように構成される。代替実施形態では、両方のサーバがクライアントの公開鍵を認識しており、後で監査を要求することができる。
登録時に、各クライアントはそのパスワードを理想機能に提出することができ、理想機能はパスワードを登録する。両方のサーバがコラプトされた場合でも、パスワードが漏れることはない。一実施形態では、攻撃者がパスワードを漏らす唯一の方法は、「試験パスワード」インターフェースを使用することである。理想機能は、敵が新しいパスワードを試験するときには必ず両方のサーバに通知し、したがって、(i)少なくとも一方のサーバが正当である場合、パスワードに対する「オンライン」ブルートフォース攻撃のみが可能であり、(ii)両方のサーバがコラプトされた場合、攻撃者はパスワードに対する「オフライン」ブルートフォース攻撃を継続することができる。
一実施形態では、後者の特性では、プロトコルのシミュレータが、理想モデルの敵の役割を果たし、実世界の敵によって行われるオフラインパスワード試験を検出することができる必要がある。しかし、両方のサーバがコラプトされたときには、敵は試験をローカルに、すなわち、メッセージを送信することなく継続することができる。したがって、一実施形態は、シミュレータが敵からパスワード試験を抽出するのを可能にする非ブラックボックス機能を含む。一実施形態は、ランダムオラクルモデルを使用してそのような抽出可能性特性を取得することによって同様の戦略に従う。
一実施形態では、理想機能は、あらゆる実行時に新しい鍵ペアを出力し、それによって前方秘匿性を実現するように構成され、すなわち、パスワードの漏れが、以前の実行によって出力された秘密鍵を侵害することはない。さらに、クライアントCjまたはサーバS1のいずれかが正当であり(たとえば、鍵ペアの生成にクライアントおよびサーバS1のみが関与することができる)、パスワードが漏れておらず、すなわち、corrupt(sid,j)≠1である限り、理想機能は正当性をもたらし、すなわち、サーバによって受信される公開鍵は、クライアントによって受信される秘密鍵に対応する。一実施形態では、理想機能は、サーバS1が正当であるときにのみ鍵ペアを鍵ペアのデータベースに登録する。サーバは、コラプトされたときは、常にプロトコルを実行したことを否定することができる。
最後に、理想機能は陥れ不能性および否認不能性を保証する。前者については、オーディターは、正当なクライアントが実際にはサーバと協働で鍵ペアを作成しなかった場合、公開鍵が、そのクライアントの所有する鍵であることを確信することができない。このことは、クライアントのパスワードがコラプトされない限り当てはまる。両方のサーバに悪意がある可能性があるが、この場合も、たとえば、クライアントのパスワードが高エントロピーであればクライアントを陥れることはできない。否認不能性については、(場合によっては悪意のある)クライアントとともに実行のトランスクリプトを有する正当なサーバは、トランスクリプトにおける公開鍵に整合する秘密鍵がそのクライアントが所有する鍵であると確信することができる。
4. UCセキュアプロトコル
4.1 セットアップ
一実施形態は機能FAUTH、FKRK、FRO、およびFCRCを利用し、機能FAUTH、FKRK、FRO、およびFCRCはそれぞれ、 認証済みチャネル、鍵登録、ランダムオラクル、および共通参照文字列をモデル化する。
さらに、一実施形態は、(2,2)しきい値忘却型PRFを実現する理想機能FTOPRFを利用する。理想機能FTOPRFの一実施形態を実現するためのコードはTABLE 2に示されている。上記で参照により組み込まれたJareckiらを参照されたい。
FTOPRFの一実施形態は、(2つのサーバによって共有される)関連する非公開鍵を敵が選択した場合でも一様にランダムな出力を作成する。この実施形態は、PRF評価を記憶するテーブルT(・,・)および各サーバについてのカウンタベクトルtr(・)を維持し、カウンタベクトルは、2つのサーバが各々の完了した評価に関与していることを保証するために使用される。一実施形態は、以下のように理想機能FTOPRFのマルチセッション拡張を使用する。
一実施形態は、この機能を呼び出す際、入力(sid, ssid, m)上で上付き文字機能
Figure 2023503235000006
 が問い合わされたときはいつでも、まずセッション識別子ssidを有するFTOPRFの使用中のコピー(たとえば、実行中のコピー、インスタンス化されたコピー)があるかどうかを検査し、ある場合にはメッセージmを用いてそのコピーをアクティブ化する(たとえば、実行する)ようにサブセッション識別子ssidを含む。上記のようなコピーがない場合、この実施形態は、入力(ssid, m)を有するFTOPRFの新しいコピーを呼び出し、このコピーにサブセッション識別子ssidを紐付ける。一実施形態(たとえば、TABLE 1、TABLE 3～TABLE 5、図4、および図5を参照されたい)では、2つの実行層があり、すなわち、クライアントのインデックス(j)がssidの役割を果たし、一方、各クライアントについて、クエリラベルqidによってタグ付けされた同じ関数(すなわち、固定された鍵についての関数)に対するそれぞれに異なる独立したクエリが考えられる。
4.2 プロトコルの説明
以下に、セットアップ機能FRO、FAUTH、FKRK、FTOPRF、およびFCRSから
Figure 2023503235000007
 を実現するプロトコルについて、TABLE 3～TABLE 5を参照しながら説明する。一実施形態では、これらの機能は暗号プリミティブの理想機能である。FAUTHは認証済みチャネルである。この機能は、たとえばデジタル署名方式によってインスタンス化することができ、この場合、送信側は鍵ペアを有し、受信側は対応する公開鍵を有する。FKRKは鍵登録関数とすることができる。この関数は、公開鍵をIDと一致させるブリテンボードによってインスタンス化することができる。FROは、ランダムオラクルとすることができ、ハッシュ関数によってインスタンス化することができる。FCRSは、共通参照文字列関数とすることができ、公開パラメータを取り込む信頼できる機関によってインスタンス化することができる。
一実施形態では、プロトコルは、3つのフェーズ、すなわち、(i)クライアントが2つのサーバS1およびS2に登録される登録と、(ii)クライアントおよびサーバS1が新しい認証済みの鍵ペアを作成する認証と、(iii)サーバがクライアントと公開鍵との関係をオーディターに証明することができる監査とを含む(たとえば、(i)登録と、(ii)認証と、(iii)監査とからなる)。
新しいクライアントの登録時に、サーバはFTOPRFの新しいインスタンス(プロトコルの一実施形態ではTOPRFプロトコルについての秘密鍵シェアのペアのサンプリングに変換される)を初期設定する。次いで、クライアントおよび2つのサーバはFTOPRFを実行し、この場合、クライアントの非公開入力はパスワードであり、一方、各サーバはその秘密鍵シェア(たとえば、総秘密鍵または総計秘密鍵の加法シェア)を非公開入力として使用する。クライアントは、DLOGベース署名方式についての秘密鍵
Figure 2023503235000008
 として解析されるOPRFの評価を受信する。プロトコルの他の実施形態は任意のEUF-CMAセキュア署名方式を使用することができる。最後に、クライアントは、FAUTHによって提供されるインターフェースを適用し、公開鍵pk*=gsk*を用いて認証済みのメッセージを両方のサーバに送信することができる。一実施形態では、クライアントIDに公開鍵pk*を結合するには最後のステップにFAUTHセットアップ仮定を使用する必要がある。さらに、サーバS2は作成された公開鍵pk*に署名し、したがって、クライアントの登録が成功したことを証明する。
認証時には、登録されたクライアントおよび2つのサーバがクライアントに関連するFTOPRFのインスタンスを再び実行する。この場合も、クライアントの非公開入力はパスワードであり、一方、各サーバは登録時に決定された秘密鍵シェアを入力する。したがって、クライアントは秘密鍵sk*を復元する。同時に、クライアントおよびサーバは、DLOG鍵ペアを作成するためにコイン投げプロトコル(ランダム化プロトコル)を実行することができる。そのようなプロトコルでは、鍵が確実にランダムに生成される。さらに、クライアントの最後のメッセージは、鍵ペアを一意に識別し、鍵pk*に基づく署名を用いて認証される。
監査時には、公開鍵pkがクライアントCjの所有する鍵であることを実証することをサーバS1が望む場合、サーバは、(1)登録時にS2によってpk*上で受信される署名およびクライアントのID jおよび(2)認証時にクライアントによってpk上で受信される署名をオーディターに提供することができる。
4.3 インスタンス化
次に、FTOPRFの2HashDH TDHインスタンス化を利用する
Figure 2023503235000009
 のインスタンス化(すなわち、実施形態)について説明する。説明を簡単にするために、一実施形態は、同じ巡回群を適用して
Figure 2023503235000010
 によって出力される鍵ペアを生成し、基本的な分散OPRFをインスタンス化する。
Gを生成元gを有する素数位数pの巡回群とする。さらに、H、H1、およびH2をそれぞれ、{0, 1}l、G、および
Figure 2023503235000011
 にわたる範囲の3つのハッシュ関数とする。入力xおよび
Figure 2023503235000012
 から得られる鍵kを仮定すると、関数fk(x)はH2(x, H1(x)k)である(鍵kはサーバ間で共有される(加法的に分割される))。
図4は、登録プロトコルの一実施形態を表す図であり、点線はブロードキャストメッセージを示す。クライアントCおよび2つのサーバS1およびS2は、それぞれ非公開入力のパスワードpw、鍵シェアk1、および鍵シェアk2を用いてOPRFプロトコルを実行する。なお、k1およびk2は、その特定のクライアントについてのプロトコル内で選択される。クライアントの非公開出力は、対応する公開鍵pk*を有するクライアントの秘密鍵sk*として設定される。公開鍵は、pk*をクライアントIDに結合できるように認証済みチャネルを介して両方のサーバに送信される。認証済みチャネルの例は上記の第1節に示されている。1つの選択肢は、クライアントが、クライアントのデジタルID(たとえば、eID)を用いてpk*に署名し、それによって公開鍵をID番号に結合することである。サーバS2は、クライアントによって受信される公開鍵に署名し、S1に署名を提供し、それによって、クライアントの登録が正しいことを証明する。登録の終了時に、ユーザはユーザ名Cおよびパスワードのみを覚えなければならない。一実施形態では、S2はクライアントのユーザ名および鍵シェアk2を覚え(すなわち、記憶し)、一方、S1はタプル(C, k1, pk*, σ)を記憶する。
次に、図5は、認証プロトコルの一実施形態を表す図である(この場合も、点線はブロードキャストチャネルを示す)。出力鍵ペアsk、pkは、クライアントとS1の両方によって与えられるランダムネスを使用することによって生成されるが、秘密鍵skはクライアントによってのみ認識される。分散OPRFプロトコルは、クライアントがsk*(たとえば、ルート秘密鍵)を復元し新たに生成された公開鍵pkを認証することができるように(登録時と同様に)実行される。サーバS1は、公開鍵がクライアントによって正しく生成された場合にのみ公開鍵を受け入れ、その公開鍵上の署名は鍵pk*に基づいて検証される。
監査手順の一実施形態について説明する。(出力pkを有する)クライアントCとの認証プロトコルのトランスクリプトを仮定すると、サーバS1は、登録時に記憶されたタプル(C, k1, pk*,σ2)を復元し、タプル(C, pk,σ*, pk*,σ2)をオーディターに送信する。オーディターは、(i)S2がクライアントCによるpk*の登録を証明したこと、および(ii)pkがpk*(たとえば、ルート公開鍵)によって証明されたことを確認する。言い換えれば、オーディターは、σ*が鍵pk*に基づく新しい公開鍵pkの有効な署名であること、σ2が鍵pk2、すなわちS2の公開鍵に基づくメッセージC||pk*の有効な署名であることを確認する。両方の検査が成功した場合、オーディターは、pkがクライアントCの所有する鍵であると結論する。
5. 評価
次に、前節で提示された
Figure 2023503235000013
 インスタンス化の一実施形態について説明する。この実施形態は、暗号化動作についてのCharm-cryptoライブラリ(http://charm-crypto.io/参照)を用いてpythonで書かれている。ECDSAは、デジタル署名方式として楕円曲線素数192v1を介してインスタンス化される。したがって、署名生成および検証ではそれぞれ、1点乗算および2点乗算が必要になる。さらなる各署名は、
Figure 2023503235000014
 における2つの要素に相当する。同じ曲線を使用して2HashDH TDH分散OPRFをインスタンス化した。ランダムオラクルをSHA256を用いてインスタンス化した。
理論的オーバヘッド。次に、図4および図5におけるプロトコルの計算および通信オーバヘッドの理論的評価を示す。楕円曲線演算について、点乗算(mults)の数について報告する。
登録時に、クライアントは、2つの乗算および2つのハッシュを算出し、ユーザ名を別として2つのグループ要素および署名を送信する。この署名は、図4における登録プロトコルの終了時にS2がS1に送信する署名である。クライアントは、2つのサーバ間のプロキシとして働き、2つのサーバは専用の接続を有さない(一実施形態では、他方のサーバのそれぞれの電子アドレスを認識していない)。認証時に、クライアントは、6つの乗算、1つの署名、および3つのハッシュを算出し、ユーザ名を別として3つのグループ要素、署名、離散ログの知識の証明(1つのグループ要素および
Figure 2023503235000015
における1つの要素)、ならびに1つのハッシュを送信する。
登録時に、サーバS1は、単一の指数を算出し、署名の有効性を検証し、1つのグループ要素を送信する。認証時に、S1は1つの指数および1つのハッシュを算出する。S1は、署名および離散ログの知識の証明(2つの乗算)を検証する。S1は1つのグループ要素および
Figure 2023503235000016
 における1つの要素を送信する。
登録時に、サーバS2は、1つの指数および1つの署名を算出し、1つのグループ要素および署名を(S1に転送するクライアントに)送信する。認証時に、S2は、1つの指数を算出し1つのグループ要素を送信する。
ベースライン比較。A2PAKEについてのベースライン比較として、一実施形態は、(i)サーバがクライアントを認証することと、(ii)秘密鍵がクライアントによってのみ認識されるようにサーバとクライアントの両方が非対称鍵ペアを生成することとを可能にするクライアント-サーバプロトコルを実施する。たとえば、クライアントとサーバは、図5の分散コイン投げプロトコル(すなわち、ランダム化プロトコル)と同様な分散コイン投げプロトコルを実行することができる(たとえば、クライアントはランダムxCについての
Figure 2023503235000017
 を送信し、サーバはランダムxSを送信し、クライアントはsk=xC・xSを設定し、pk=gskを送信する)。
さらに、クライアントは(たとえば、PBKDF2を介して)パスワードからMAC鍵を導出し、公開鍵pkを認証する。サーバは、パスワードを使用して同じMAC鍵を導出し、クライアントによって送信されたMACが有効である場合にのみpkを受け入れる。プロトコルのこの実施形態は、(いずれのパーティも鍵ペアを作成しMAC鍵ペアを導出した可能性があるので)非否認を保証しないが、パスワードを使用することによってクライアントを認証し新しい鍵ペアを作成するにはどうすべきかについての例として働く。
以下に示すTABLE 1は、理想機能
Figure 2023503235000018
 の一実施形態を含む。
Figure 2023503235000019
以下に示すTABLE 2は、理想機能FTOPRFの一実施形態を含む。ラベル0は正当な実行について予約される。
Figure 2023503235000020
以下に示すTABLE 3は、クライアントCjについてのプロトコルの一実施形態を含む。
Figure 2023503235000021
以下に示すTABLE 4は、サーバS1についてのプロトコルの一実施形態を含む。
Figure 2023503235000022
以下に示すTABLE 5は、サーバS2についてのプロトコルの一実施形態を含む。
Figure 2023503235000023
以下に示すTABLE 6は、オーディターAについてのプロトコルの一実施形態を含む。
Figure 2023503235000024
本発明の実施形態を図面および上記の説明において詳細に図示し説明したが、そのような図示および説明は例示または一例と見なされ、限定的なものではない。当業者によって以下の特許請求の範囲内で変更および修正が施されてもよいことが理解されよう。具体的には、本発明は、上記および以下で説明するそれぞれに異なる実施形態における特徴の任意の組合せを含むさらなる実施形態を対象とする。「一実施形態」を参照して説明する各特徴は、いくつかの実施例によれば、単一の実施形態として統合することができる。さらに、本明細書において本発明の特徴を示す記載事項は、本発明の一実施形態を指し、必ずしもすべての実施形態を指すわけではない。
特許請求の範囲で使用される用語は、上記の説明と整合する最も広義の合理的な解釈を有すると理解すべきである。たとえば、ある要素を導入する際に冠詞"a"または"the"を使用する場合、複数の要素が除外されると解釈すべきではない。同様に、「または」の記載は包含的なものと解釈すべきであり、「AまたはB」の記載は、文脈または上記の説明からAおよびBの一方のみが意図されることが明らかでない限り、「AおよびB」を除外しない。さらに、「A、B、およびCのうちの少なくとも1つ」の記載は、A、B、およびCからなる要素のグループのうちの1つもしくは複数と解釈すべきであり、A、B、およびCが範疇などとしての関係を有するにもかかわらず、列挙される要素A、B、およびCの各々の少なくとも1つを必要とすると解釈すべきではない。さらに、「A、B、および/もしくはC」または「A、B、もしくはCのうちの少なくとも1つ」の記載は、列挙される要素における任意の単一の実体、たとえばA、列挙される要素における任意のサブセット、たとえばAおよびB、または要素のリスト全体A、B、およびCを含むと解釈すべきである。
300 処理システム
302 プロセッサ
304 メモリ
306 入出力デバイス
308 センサ
310 ユーザインターフェース
312 アクチュエータ
A オーディター
b1、B2 メッセージ
C クライアント
Dpk 完了したセッションのデータベース
Dpw 登録されたパスワードのデータベース
F 理想機能
g 生成元
G 巡回群
G セットアップ仮定
H1、H2 ハッシュ関数
k 関数の添え字
p 素数位数
P プルーバー
pk 公開鍵
rpk ルート公開鍵
rsk ルート秘密鍵
S PPTシミュレータS
S1、S2 サーバ
sk 秘密鍵
ssid サブセッション識別子
T トランスクリプト
U ユーザ
V ベリファイア
Z 環境

Claims (15)

  1. 暗号鍵プロビジョニングのための方法であって、メイン認証サーバを介して、
    第1の秘密鍵を生成するステップと、
    分散しきい値忘却型擬似ランダム関数の第1のインスタンスの第1の部分を実行することによってクライアントを登録するステップであって、前記関数の前記第1のインスタンスによって、前記クライアントがルート秘密鍵を取得し、前記メイン認証サーバが対応するルート公開鍵を取得する、ステップと、
    前記分散しきい値忘却型擬似ランダム関数の第2のインスタンスの第1の部分を実行することによって前記クライアントを前記メイン認証サーバに認証するステップであって、前記関数の前記第2のインスタンスによって、前記クライアントが前記ルート秘密鍵を取得する、ステップと
    を含み、
    前記クライアントによって記憶される情報、前記第1の秘密鍵、およびサポート認証サーバによって生成される第2の秘密鍵が、前記分散しきい値忘却型擬似ランダム関数の前記第1のインスタンスおよび前記第2のインスタンスのうちの少なくとも一方への入力である、方法。
  2. 前記メイン認証サーバは、前記クライアントも前記サポート認証サーバも前記第1の秘密鍵を受信しないように前記第1の秘密鍵を非公開にする、請求項1に記載の方法。
  3. 前記サポート認証サーバは、前記クライアントも前記メイン認証サーバも前記第2の秘密鍵を受信しないように前記第2の秘密鍵を非公開にする、請求項1または2に記載の方法。
  4. 前記メイン認証サーバは、前記クライアントとともに前記関数の前記第1のインスタンスの前記第1の部分を実行し、前記サポート認証サーバは、前記認証の前に、前記クライアントとともに前記関数の前記第1のインスタンスの第2の部分を実行しておき、前記認証時に、前記サポート認証サーバが前記関数の前記第2のインスタンスの第2の部分を実行し、前記クライアントによって記憶される前記情報、前記第1の秘密鍵、および前記第2の秘密鍵が、前記分散しきい値忘却型擬似ランダム関数の前記第1のインスタンスと前記第2のインスタンスの両方への入力である、請求項1から3のいずれか一項に記載の方法。
  5. 前記関数の前記第1のインスタンスによって、前記サポート認証サーバが前記対応するルート公開鍵を取得する、請求項1から4のいずれか一項に記載の方法。
  6. 前記メイン認証サーバは、前記クライアントによって署名された新しい非対称鍵ペアの少なくとも一部を前記クライアントから受信し、前記対応するルート公開鍵を用いて前記署名を検証する、請求項1から5のいずれか一項に記載の方法。
  7. 前記クライアントは、前記メイン認証サーバによって与えられたランダムネスに基づいて前記新しい非対称鍵ペアを作成しており、前記新しい非対称鍵ペアの前記少なくとも一部に前記ルート秘密鍵を用いて署名している、請求項6に記載の方法。
  8. 前記新しい非対称鍵ペアは、新しい公開鍵と新しい非公開鍵とを含み、前記クライアントは、前記新しい公開鍵に前記ルート秘密鍵を用いて署名しており、前記署名された新しい公開鍵を前記メイン認証サーバに送信している、請求項6または7に記載の方法。
  9. 登録が終了してから認証が開始するまでの間に、前記クライアントはメモリから前記ルート秘密鍵を除去しており、登録時に取得される前記ルート秘密鍵は、認証時に取得される前記ルート秘密鍵に等しい、請求項1から8のいずれか一項に記載の方法。
  10. 前記クライアントによって記憶される前記情報はユーザパスワードを含む、請求項1から9のいずれか一項に記載の方法。
  11. 前記新しい非対称鍵ペアは、前記クライアントによって与えられたランダムネスおよび前記メイン認証サーバによって与えられたランダムネスに基づいて算出される、請求項1から10のいずれか一項に記載の方法。
  12. 前記メイン認証サーバによって取得された前記ルート公開鍵は、前記新しい非対称鍵ペアが明確に前記ユーザに結合されるように前記サポート認証サーバが所有するデジタル署名を用いて証明されている、請求項1から11のいずれか一項に記載の方法。
  13. 前記メイン認証サーバは、ユーザIDと前記クライアントによって記憶される前記情報のハッシュに基づく第1の出力の一方または両方を受信したことに応じて前記第1の秘密鍵を生成し、
    前記メイン認証サーバは、前記第1の秘密鍵に基づいて第2の出力を算出し、前記第2の出力を前記クライアントに送信し、
    前記認証時に前記クライアントによって取得された前記ルート秘密鍵は、前記クライアントによって記憶される前記情報、前記第2の出力、前記第2の秘密鍵に基づいて前記サポート認証サーバによって算出される第3の出力に基づく、請求項1から12のいずれか一項に記載の方法。
  14. 有形非一時コンピュータ可読媒体であって、単独のまたは組み合わされた1つまたは複数のプロセッサによって実行されたときに、請求項1から13のいずれか一項に記載の方法の実行を可能にする命令を有する有形非一時コンピュータ可読媒体。
  15. 単独でまたは組み合わされて、暗号鍵プロビジョニングのための方法の実行を可能にするように構成された1つまたは複数のプロセッサを備えるメイン認証サーバであって、前記方法が、前記メイン認証サーバの前記1つまたは複数のプロセッサを介して、
    第1の秘密鍵を生成するステップと、
    分散しきい値忘却型擬似ランダム関数の第1のインスタンスの第1の部分を実行することによってクライアントを登録するステップであって、前記関数の前記第1のインスタンスによって、前記クライアントがルート秘密鍵を取得し、前記メイン認証サーバが対応するルート公開鍵を取得する、ステップと、
    前記分散しきい値忘却型擬似ランダム関数の第2のインスタンスの第1の部分を実行することによって前記クライアントを前記メイン認証サーバに認証するステップであって、前記関数の前記第2のインスタンスによって、前記クライアントが前記ルート秘密鍵を取得する、ステップと
    を含み、
    前記クライアントによって記憶される情報、前記第1の秘密鍵、およびサポート認証サーバによって生成される第2の秘密鍵が、前記分散しきい値忘却型擬似ランダム関数の前記第1のインスタンスおよび前記第2のインスタンスのうちの少なくとも一方への入力であるメイン認証サーバ。
JP2022526054A 2019-11-29 2020-10-30 パスワード認証による公開鍵確立 Pending JP2023503235A (ja)

Applications Claiming Priority (5)

Application Number Priority Date Filing Date Title
US201962941908P 2019-11-29 2019-11-29
US62/941,908 2019-11-29
US16/831,844 US11296875B2 (en) 2019-11-29 2020-03-27 Password-authenticated public key establishment
US16/831,844 2020-03-27
PCT/EP2020/080546 WO2021104795A1 (en) 2019-11-29 2020-10-30 Password-authenticated public key establishment

Publications (1)

Publication Number Publication Date
JP2023503235A true JP2023503235A (ja) 2023-01-27

Family

ID=76091312

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2022526054A Pending JP2023503235A (ja) 2019-11-29 2020-10-30 パスワード認証による公開鍵確立

Country Status (4)

Country Link
US (1) US11296875B2 (ja)
EP (1) EP4066434B1 (ja)
JP (1) JP2023503235A (ja)
WO (1) WO2021104795A1 (ja)

Families Citing this family (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US11402814B2 (en) * 2020-04-22 2022-08-02 Capital One Services, Llc Interactive home system including wireless devices
EP4226573A1 (en) * 2020-10-05 2023-08-16 Redcom Laboratories, Inc. Zkmfa: zero-knowledge based multi-factor authentication system
US11308226B1 (en) * 2021-02-22 2022-04-19 CipherMode Labs, Inc. Secure collaborative processing of private inputs
US11855979B2 (en) 2021-05-28 2023-12-26 Microsoft Technology Licensing, Llc Proxy configured to dynamically failover authentication traffic to a backup authentication system
US12069052B2 (en) * 2021-05-28 2024-08-20 Microsoft Technology Licensing, Llc Client device capable of dynamically routing authentication requests to a backup authentication system
US20220385481A1 (en) * 2021-06-01 2022-12-01 International Business Machines Corporation Certificate-based multi-factor authentication
WO2023022728A1 (en) * 2021-08-20 2023-02-23 Visa International Service Association Method and system for generating a secret key using non-communicating entities
CN113904833B (zh) * 2021-09-30 2022-07-22 北京大学 一种基于门限的动态多因素身份认证方法和通信方法
CN116245669B (zh) * 2023-05-04 2023-08-25 南京青春信息科技有限公司 一种基于同态加密及分类优化的财务审计方法和系统

Family Cites Families (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US9565020B1 (en) * 2016-02-02 2017-02-07 International Business Machines Corporation System and method for generating a server-assisted strong password from a weak secret
EP3547601B1 (en) * 2017-11-21 2020-10-21 Shenzhen Goodix Technology Co., Ltd. Biometric information transmission establishing method , device, system, and storage medium
US10700859B2 (en) * 2018-04-02 2020-06-30 International Business Machines Corporation Efficient computation of a threshold partially-oblivious pseudorandom function
CN112106322B (zh) 2018-05-08 2024-05-24 维萨国际服务协会 基于密码的阈值令牌生成
US11411738B2 (en) * 2018-10-04 2022-08-09 Visa International Service Association Leveraging multiple devices to enhance security of biometric authentication

Also Published As

Publication number Publication date
EP4066434B1 (en) 2023-08-16
WO2021104795A1 (en) 2021-06-03
US20210167958A1 (en) 2021-06-03
US11296875B2 (en) 2022-04-05
EP4066434A1 (en) 2022-10-05

Similar Documents

Publication Publication Date Title
JP2023503235A (ja) パスワード認証による公開鍵確立
Jiang et al. Robust extended chaotic maps-based three-factor authentication scheme preserving biometric template privacy
Li et al. Privacy preserving cloud data auditing with efficient key update
Baum et al. PESTO: proactively secure distributed single sign-on, or how to trust a hacked server
US9268968B2 (en) Credential validation
US8627424B1 (en) Device bound OTP generation
Jarecki et al. Two-factor authentication with end-to-end password security
CN101534192B (zh) 一种提供跨域令牌的系统和方法
Reddy et al. A privacy preserving three-factor authenticated key agreement protocol for client–server environment
US9398024B2 (en) System and method for reliably authenticating an appliance
US11700125B2 (en) zkMFA: zero-knowledge based multi-factor authentication system
Munivel et al. New authentication scheme to secure against the phishing attack in the mobile cloud computing
Alhaidary et al. Vulnerability analysis for the authentication protocols in trusted computing platforms and a proposed enhancement of the offpad protocol
Manulis et al. Secure modular password authentication for the web using channel bindings
US12095753B2 (en) End-to-end verifiable multi-factor authentication service
Sharma et al. Advanced multi-factor user authentication scheme for E-governance applications in smart cities
Schwarz et al. Feido: Recoverable FIDO2 tokens using electronic ids
Jia et al. A Redesigned Identity-Based Anonymous Authentication Scheme for Mobile-Edge Computing
Baldimtsi et al. zklogin: Privacy-preserving blockchain authentication with existing credentials
Kamal et al. An efficient mCK signing and mobile based identity solution for authentication
Mir et al. Decentralized, Privacy‐Preserving, Single Sign‐On
Aiash A formal analysis of authentication protocols for mobile devices in next generation networks
WO2020144110A1 (en) Authentication system with reduced attack surface
Zhang et al. Strong Authentication without Temper-Resistant Hardware and Application to Federated Identities.
Li et al. A simple and robust anonymous two‐factor authenticated key exchange protocol

Legal Events

Date Code Title Description
A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20220713

A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20230914

A977 Report on retrieval

Free format text: JAPANESE INTERMEDIATE CODE: A971007

Effective date: 20240830

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20240909