JP6613909B2 - 相互認証方法、認証装置および認証プログラム - Google Patents

相互認証方法、認証装置および認証プログラム Download PDF

Info

Publication number
JP6613909B2
JP6613909B2 JP2016005919A JP2016005919A JP6613909B2 JP 6613909 B2 JP6613909 B2 JP 6613909B2 JP 2016005919 A JP2016005919 A JP 2016005919A JP 2016005919 A JP2016005919 A JP 2016005919A JP 6613909 B2 JP6613909 B2 JP 6613909B2
Authority
JP
Japan
Prior art keywords
identification information
authentication
encrypted data
data
random number
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
JP2016005919A
Other languages
English (en)
Other versions
JP2017126943A (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.)
Fujitsu Ltd
Original Assignee
Fujitsu Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Fujitsu Ltd filed Critical Fujitsu Ltd
Priority to JP2016005919A priority Critical patent/JP6613909B2/ja
Priority to EP16204705.4A priority patent/EP3193486B1/en
Priority to US15/405,830 priority patent/US10419430B2/en
Priority to CN201710026296.8A priority patent/CN107040373B/zh
Publication of JP2017126943A publication Critical patent/JP2017126943A/ja
Application granted granted Critical
Publication of JP6613909B2 publication Critical patent/JP6613909B2/ja
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/08Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
    • H04L9/0861Generation of secret information including derivation or calculation of cryptographic keys or passwords
    • H04L9/0869Generation of secret information including derivation or calculation of cryptographic keys or passwords involving random numbers or seeds
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00Network architectures or network communication protocols for network security
    • H04L63/08Network architectures or network communication protocols for network security for authentication of entities
    • H04L63/0869Network architectures or network communication protocols for network security for authentication of entities for achieving mutual authentication
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00Network architectures or network communication protocols for network security
    • H04L63/04Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks
    • H04L63/0428Network 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
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00Network architectures or network communication protocols for network security
    • H04L63/06Network architectures or network communication protocols for network security for supporting key management in a packet data network
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00Network architectures or network communication protocols for network security
    • H04L63/06Network architectures or network communication protocols for network security for supporting key management in a packet data network
    • H04L63/061Network architectures or network communication protocols for network security for supporting key management in a packet data network for key exchange, e.g. in peer-to-peer networks
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/08Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
    • H04L9/0816Key establishment, i.e. cryptographic processes or cryptographic protocols whereby a shared secret becomes available to two or more parties, for subsequent use
    • H04L9/0838Key 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/0841Key agreement, i.e. key establishment technique in which a shared key is derived by parties as a function of information contributed by, or associated with, each of these involving Diffie-Hellman or related key agreement protocols
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/08Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
    • H04L9/0816Key establishment, i.e. cryptographic processes or cryptographic protocols whereby a shared secret becomes available to two or more parties, for subsequent use
    • H04L9/0838Key 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/0841Key agreement, i.e. key establishment technique in which a shared key is derived by parties as a function of information contributed by, or associated with, each of these involving Diffie-Hellman or related key agreement protocols
    • H04L9/0844Key agreement, i.e. key establishment technique in which a shared key is derived by parties as a function of information contributed by, or associated with, each of these involving Diffie-Hellman or related key agreement protocols with user authentication or key authentication, e.g. ElGamal, MTI, MQV-Menezes-Qu-Vanstone protocol or Diffie-Hellman protocols using implicitly-certified keys
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/08Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
    • H04L9/0816Key establishment, i.e. cryptographic processes or cryptographic protocols whereby a shared secret becomes available to two or more parties, for subsequent use
    • H04L9/0838Key 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/0847Key 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
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/08Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
    • H04L9/0861Generation of secret information including derivation or calculation of cryptographic keys or passwords
    • H04L9/0877Generation of secret information including derivation or calculation of cryptographic keys or passwords using additional device, e.g. trusted platform module [TPM], smartcard, USB or hardware security module [HSM]
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/14Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols using a plurality of keys or algorithms
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/30Public key, i.e. encryption algorithm being computationally infeasible to invert or user's encryption keys not requiring secrecy
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32Cryptographic 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/3271Cryptographic 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/3273Cryptographic 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
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W12/00Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/04Key management, e.g. using generic bootstrapping architecture [GBA]
    • H04W12/041Key generation or derivation
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W12/00Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/04Key management, e.g. using generic bootstrapping architecture [GBA]
    • H04W12/043Key management, e.g. using generic bootstrapping architecture [GBA] using a trusted network node as an anchor
    • H04W12/0431Key distribution or pre-distribution; Key agreement
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W12/00Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/04Key management, e.g. using generic bootstrapping architecture [GBA]
    • H04W12/043Key management, e.g. using generic bootstrapping architecture [GBA] using a trusted network node as an anchor
    • H04W12/0433Key management protocols
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W12/00Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/06Authentication
    • H04W12/069Authentication using certificates or pre-shared keys
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/30Public key, i.e. encryption algorithm being computationally infeasible to invert or user's encryption keys not requiring secrecy
    • H04L9/3066Public 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/3073Public 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

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)
  • Computer And Data Communications (AREA)
  • Storage Device Security (AREA)

Description

本発明は相互認証方法、認証装置および認証プログラムに関する。
複数の情報処理装置がネットワークを介してデータ通信を行う場合、第三者によりデータが盗聴されるリスク、通信経路上でデータが改竄されるリスク、第三者が正規の情報処理装置になりすましているリスクなど、セキュリティ上のリスクが存在する。そこで、セキュリティを維持するために暗号通信技術が用いられることがある。暗号通信技術の例としては、SSL(Secure Sockets Layer)やTLS(Transport Layer Security)などが挙げられる。SSLやTLSは、WWW(World Wide Web)通信、電子メールの送信、VPN(Virtual Private Network)通信などの様々なデータ通信に利用可能である。
暗号通信技術では、公開鍵暗号技術を用いてハンドシェークが行われることがある。例えば、ハンドシェークにおいて、データ通信を行おうとする2つの情報処理装置それぞれが、通信相手の公開鍵を用いて乱数などの鍵材料を暗号化して送信する。公開鍵で暗号化された鍵材料は、その公開鍵に対応する秘密鍵をもつ正規の情報処理装置のみが復号できる。よって、暗号化された鍵材料を通信相手が正しく認識できたことを確認することで、2つの情報処理装置はそれぞれ通信相手を認証することができる。
また、例えば、ハンドシェークにおいて、2つの情報処理装置が独立に、当該2つの情報処理装置の間でやり取りした鍵材料と所定の鍵生成アルゴリズムとに基づいて共有鍵を生成する。2つの情報処理装置が正規の情報処理装置であれば、当該2つの情報処理装置によって生成される共有鍵は同一となる。よって、共有鍵そのものを送信しなくても、2つの情報処理装置が共有鍵を合意することができる。以降は、合意した共有鍵に基づいてデータを暗号化して送信することが可能となる。
なお、公開鍵暗号技術の1つとしてIDベース暗号技術(Identity Based Cryptography)が提案されている。IDベース暗号技術では、数学的に生成された数値を公開鍵として用いる代わりに、ネットワークアドレスやホスト名や機器番号などの人が認識する識別子または当該識別子から変換された数値を公開鍵として用いる。IDベース暗号技術では、通信相手の識別子を知れば暗号処理を行うことが可能であり、ある公開鍵が通信相手の公開鍵であることを証明する証明書が不要となることもある。
特開2010−4288号公報
暗号通信技術では、例えば、次のような手順で2つの情報処理装置がハンドシェークを行うことが考えられる。一方の情報処理装置が他方の情報処理装置にアクセスする。後者の情報処理装置は、前者の情報処理装置の公開鍵を用いて暗号化した鍵材料を返信する。前者の情報処理装置は、後者の情報処理装置の公開鍵を用いて暗号化した鍵材料を送信すると共に、鍵材料から共有鍵が正しく生成されたか確認するための検証データを生成して送信する。後者の情報処理装置も、検証データを生成して返信する。2つの情報処理装置がそれぞれ検証データを検証することで、共有鍵を合意したことを確認する。
しかし、上記のハンドシェークの手順によれば、2つの情報処理装置の間で4回の通信が行われる。もし通信回数を減らすことができれば、認証時間を短縮することができ、データ通信を開始するまでのオーバヘッドを減らすことができる。
1つの側面では、本発明は、認証時間が短縮された相互認証方法、認証装置および認証プログラムを提供することを目的とする。
1つの態様では、第1の情報処理装置と第2の情報処理装置との間の相互認証方法が提供される。第1の情報処理装置により、第2の情報処理装置に関する第2の識別情報に応じた第2の公開鍵を用いて、第1の乱数を暗号化することで第1の暗号データを生成する。第1の情報処理装置から第2の情報処理装置に、第1の情報処理装置に関する第1の識別情報と第2の識別情報と第1の暗号データとを送信する。第2の情報処理装置により、第1の識別情報に応じた第1の公開鍵を用いて、第2の乱数を暗号化することで第2の暗号データを生成し、また、第2の乱数と第1の暗号データと第2の公開鍵に対応する第2の秘密鍵とから第2の共有鍵候補を生成し、第2の共有鍵候補を用いて第2の検証データを生成する。第2の情報処理装置から第1の情報処理装置に、第2の暗号データと第2の検証データとを送信する。第1の情報処理装置により、第1の乱数と第2の暗号データと第1の公開鍵に対応する第1の秘密鍵とから第1の共有鍵候補を生成し、第1の共有鍵候補を用いて第1の検証データを生成する。第1の情報処理装置により、第1の共有鍵候補を用いて第2の検証データを検証する。第1の情報処理装置から第2の情報処理装置に、第1の検証データを送信する。第2の情報処理装置により、第2の共有鍵候補を用いて第1の検証データを検証する。
また、1つの態様では、通信部と制御部とを有する認証装置が提供される。また、1つの態様では、コンピュータに実行させる認証プログラムが提供される。
1つの側面では、認証時間を短縮することができる。
第1の実施の形態の認証システムの例を示す図である。 第2の実施の形態に係るシステムの一例を示した図である。 第2の実施の形態に係るクライアント装置の機能を実現可能なハードウェアの一例を示した図である。 第2の実施の形態に係るクライアント装置が有する機能の一例を示したブロック図である。 第2の実施の形態に係るサーバ装置が有する機能の一例を示したブロック図である。 第2の実施の形態に係る認証処理の流れ(エラーなし)を示したシーケンス図である。 第2の実施の形態に係る認証処理の流れ(エラーあり)を示したシーケンス図である。 TLSのハンドシェークに係る認証処理の流れ(比較例:エラーなし)を示したシーケンス図である。 第2の実施の形態に係るクライアント装置の状態遷移を示した図である。 第2の実施の形態に係るサーバ装置の状態遷移を示した図である。 第2の実施の形態の一変形例に係る認証処理の流れ(エラーあり)を示したシーケンス図である。 第2の実施の形態の一変形例に係るクライアント装置の状態遷移を示した図である。 第2の実施の形態の一変形例に係るサーバ装置の状態遷移を示した図である。
以下、本実施の形態を図面を参照して説明する。
<1.第1の実施の形態>
第1の実施の形態を説明する。
図1は、第1の実施の形態の認証システムの例を示す図である。
第1の実施の形態の認証システムは、認証装置10,20を有する。認証装置10,20は、相互認証を行うと共にデータ通信に用いる共有鍵を合意する。認証装置10,20は、ネットワークを介して通信を行う。第1の実施の形態で説明する各種情報は、例えば、TCP(Transmission Control Protocol)/IP(Internet Protocol)などのプロトコル上のメッセージに含めて送信できる。第1の実施の形態で説明する通信手順は、例えば、SSL/TLSなどの暗号通信技術に適用することができる。
認証装置10,20は、情報処理装置やコンピュータと呼ばれるものであってもよい。認証装置10,20は、携帯電話機やノートPC(Personal Computer)などの移動型装置でもよいし、デスクトップPCやサーバコンピュータなどの固定型装置でもよい。第1の実施の形態では、最初に認証装置10が認証装置20にアクセスする。このため、認証装置10をクライアントと言うこともでき、認証装置20をサーバと言うこともできる。
認証装置10は、通信部11および制御部12を有する。認証装置20は、通信部21および制御部22を有する。通信部11,21は、他の装置と通信を行う通信インタフェースである。通信部11,21は、ケーブルを介して通信を行う有線インタフェースでもよいし、無線リンクを介して通信を行う無線インタフェースでもよい。
制御部12,22は、例えば、CPU(Central Processing Unit)やDSP(Digital Signal Processor)などのプロセッサである。ただし、制御部12,22は、ASIC(Application Specific Integrated Circuit)やFPGA(Field Programmable Gate Array)などの特定用途の電子回路を含んでもよい。プロセッサは、RAM(Random Access Memory)などのメモリに記憶されたプログラムを実行する。プログラムには、以下に説明する処理を記載した認証プログラムが含まれる。複数のプロセッサの集合(マルチプロセッサ)を「プロセッサ」と言うこともある。
認証装置10には、識別情報13(第1の識別情報)が関連付けられる。識別情報13は、認証装置10または認証装置10のユーザに関する何らかの情報である。識別情報13としては、例えば、認証装置10のIPアドレス、ホスト名、機器番号などを用いることができ、認証装置10のユーザのユーザID、電話番号などを用いることもできる。同様に、認証装置20には、識別情報23(第2の識別情報)が関連付けられる。識別情報23は、認証装置20または認証装置20のユーザに関する何らかの情報である。
認証装置10に関して、公開鍵暗号技術に用いられる公開鍵14(第1の公開鍵)と秘密鍵15(第1の秘密鍵)とが定義される。公開鍵14は公開されている一方、秘密鍵15は認証装置10のみが秘密に保持している。公開鍵14によって暗号化されたデータは、秘密鍵15によってのみ復号できる。公開鍵14および秘密鍵15は、識別情報13に対応付けられる。同様に、認証装置20に関して、公開鍵暗号技術に用いられる公開鍵24(第2の公開鍵)と秘密鍵25(第2の秘密鍵)とが定義される。公開鍵24は公開されている一方、秘密鍵25は認証装置20のみが秘密に保持している。公開鍵24によって暗号化されたデータは、秘密鍵25によってのみ復号できる。公開鍵24および秘密鍵25は、識別情報23に対応付けられる。
公開鍵暗号技術としてIDベース暗号技術を用いた場合、認証装置10は、識別情報23から公開鍵24を生成することが可能である。また、認証装置20は、識別情報13から公開鍵14を生成することが可能である。ただし、第1の実施の形態では、IDベース暗号技術以外の公開鍵暗号技術を用いることも可能である。認証装置10は、識別情報23に対応する公開鍵24を、認証装置10の内部または外部に存在するデータベースから検索してもよいし、認証装置20から直接取得してもよい。認証装置20は、識別情報13に対応する公開鍵14を、認証装置20の内部または外部に存在するデータベースから検索してもよいし、認証装置10から直接取得してもよい。
ここで、通信部11は、認証装置20と次のような通信を行う。通信部11は、識別情報13,23と暗号データ18(第1の暗号データ)を認証装置20に送信する。通信部11は、暗号データ18を送信した後、暗号データ28(第2の暗号データ)と検証データ29(第2の検証データ)を認証装置20から受信する。通信部11は、検証データ29を受信した後、検証データ19(第1の検証データ)を認証装置20に送信する。
制御部12は、乱数17(第1の乱数)を生成し、識別情報23に応じた公開鍵24を用いて乱数17を暗号化することで暗号データ18を生成する。制御部12は、暗号データ28が受信されると、乱数17と暗号データ28と秘密鍵15とから共有鍵候補16(第1の共有鍵候補)を生成する。制御部12は、共有鍵候補16を用いて検証データ19を生成する。検証データ19は、例えば、共有鍵候補16により暗号化される。また、制御部12は、検証データ29が受信されると、共有鍵候補16を用いて検証データ29を検証する。例えば、制御部12は、認証装置20と同様の方法で検証データ29に相当する検証データを作成し、検証データ29と比較する。この場合、両者が一致していれば検証成功であり、一致していなければ検証失敗となる。
通信部21は、認証装置10と次のような通信を行う。通信部21は、識別情報13,23と暗号データ18を認証装置10から受信する。通信部21は、暗号データ18を受信した後に、暗号データ28と検証データ29を認証装置10に送信する。通信部21は、検証データ29を送信した後に、検証データ19を認証装置10から受信する。
制御部22は、識別情報13が受信されると、乱数27(第2の乱数)を生成し、識別情報13に応じた公開鍵14を用いて乱数27を暗号化することで暗号データ28を生成する。また、制御部22は、暗号データ18が受信されると、乱数27と暗号データ18と秘密鍵25から共有鍵候補26(第2の共有鍵候補)を生成する。制御部22は、共有鍵候補26を用いて検証データ29を生成する。検証データ29は、例えば、共有鍵候補26により暗号化される。制御部22は、検証データ19が受信されると、共有鍵候補26を用いて検証データ19を検証する。例えば、制御部22は、認証装置10と同様の方法で検証データ19に相当する検証データを作成し、検証データ19と比較する。この場合、両者が一致していれば検証成功であり、一致していなければ検証失敗となる。
検証データ19,29の検証に成功することで、共有鍵候補16と共有鍵候補26とが同一であることが確認される。すなわち、認証装置10と認証装置20の間で共有鍵が合意される。以降、認証装置10は共有鍵候補16を共有鍵として用いて暗号通信を行い、認証装置20は共有鍵候補26を共有鍵として用いて暗号通信を行う。
また、乱数17は認証装置20の公開鍵24で暗号化されるため、公開鍵24に対応する秘密鍵25を有する認証装置20のみが乱数17を認識できる。また、乱数27は認証装置10の公開鍵14で暗号化されるため、公開鍵14に対応する秘密鍵15を有する認証装置10のみが乱数27を認識できる。よって、同一の共有鍵が生成されたことを確認することで、認証装置10,20は互いに通信相手を認証することができる。
なお、制御部22は、識別情報13,23が受信されたとき、識別情報13,23を許容するか否か判定してもよい。識別情報13,23を許容する場合、制御部22は上記の処理を続行する。一方、識別情報13,23の少なくとも一方を許容しない場合、制御部22は認証装置10との通信を終了してもよい。識別情報13を許容しない場合としては、例えば、識別情報13が所定のホワイトリストに載っていない場合や所定のブラックリストに載っている場合などが挙げられる。識別情報23を許容しない場合としては、例えば、識別情報23が認証装置20を表していない場合や期限切れである場合などが挙げられる。その場合、制御部22は、認証装置20が識別情報23として別の識別情報を選択し暗号データ18を再送するための機会を与えてもよい。
ここで、第1の実施の形態の通信手順の効率性について検討する。
認証装置10,20の通信手順の他の例として、次のような手順が考えられる。まず、認証装置10が識別情報13を認証装置20に送信する。認証装置20は、認証装置10からのアクセスに応答して、識別情報23と暗号データ28を認証装置10に送信する。暗号データ18をまだ受け取っていないため、この時点では検証データ29は送信されない。認証装置10は、暗号データ18と検証データ19を認証装置20に送信する。認証装置20は、検証データ29を認証装置10に送信する。通信手順の他の例によれば、認証装置10,20の間で4回の通信が行われることになる。
これに対し、第1の実施の形態の通信手順によれば、識別情報13と共に暗号データ18が認証装置10から認証装置20に早期に送信される。すなわち、暗号データ28より前に暗号データ18が送信される。よって、これに対する応答として、暗号データ28と共に検証データ29を認証装置20から認証装置10に送信することが可能となる。すなわち、検証データ19より前に検証データ29が送信される。その結果、検証データ19が認証装置10から認証装置20に送信された後、検証データ29を認証装置20から認証装置10に送信する通信が不要となり、通信回数を3回に削減することができる。以上から、認証装置10,20の間の認証時間を短縮することが可能となる。
<2.第2の実施の形態>
次に、第2の実施の形態について説明する。第2の実施の形態は、SSLやTLSなどの暗号通信技術を用いてハンドシェークを行う際の通信負荷を低減する仕組みを提供する。
TLSの通信開始時に行われるハンドシェークでは、ClientHello、ServerHello、ServerHelloDone、ChangeCipherSpec、Certificate(S)、ServerKeyExchange、ClientKeyExchange、Finished(C)、Finished(S)などのメッセージが送受信される。相互認証でephemeral Diffie-Hellman(DHE)鍵交換を行う場合、ハンドシェークのイニシエータとして動作するクライアント装置と、レスポンダとして動作するサーバ装置との間では以下のようなメッセージの送受信が行われる。
まず、クライアント装置がClientHelloを送信する。ClientHelloを受信したサーバ装置は、ServerHello、Certificate(S)、ServerKeyExchangeをクライアント装置に送信する。Certificate(S)には証明書が含まれる。ServerKeyExchangeには、クライアント装置が共有鍵を生成する際に用いる鍵材料(サーバ生成鍵材料)が含まれる。なお、サーバ生成鍵材料の生成方法については後述する。
ServerKeyExchangeを受信したクライアント装置は、Certificate(S)に含まれる証明書を検証し、証明書に含まれるサーバ装置の公開鍵を用いて鍵材料(クライアント生成鍵材料)を生成する。また、クライアント装置は、サーバ装置が共有鍵を生成する際に用いる鍵材料(クライアント生成鍵材料)と、サーバ生成鍵材料とを用いてマスター秘密情報を生成し、マスター秘密情報を用いて検証子(クライアント生成検証子)を生成する。なお、クライアント生成鍵材料およびマスター秘密情報の生成方法については後述する。
クライアント装置は、ClientKeyExchangeにクライアント生成鍵材料を含め、クライアント生成検証子をFinished(C)に含め、ClientKeyExchangeおよびFinished(C)をサーバ装置に送信する。ClientKeyExchangeおよびFinished(C)を受信したサーバ装置は、サーバ生成鍵材料とクライアント生成鍵材料とを用いて、クライアント装置が生成するマスター秘密情報と同じマスター秘密情報を生成する。サーバ装置は、クライアント生成検証子を検証し、マスター秘密情報を用いて検証子(サーバ生成検証子)を生成する。
サーバ装置は、Finished(S)にサーバ生成検証子を含め、Finished(S)をクライアント装置に送信する。Finished(S)を受信したクライアント装置は、Finished(S)に含まれるサーバ生成検証子を検証する。クライアント生成検証子およびサーバ生成検証子の検証が成功すれば、処理途中で鍵材料が改ざんされていないと言え、鍵交換/鍵合意が正しく行われたことが確認できる。以降、クライアント装置およびサーバ装置は、マスター秘密情報を用いることで安全なデータ通信を行うことができる。
なお、上記のシーケンスは一例であり、例えば、Certificate(S)などの処理および証明書の検証処理を省略する変形が可能である。また、ServerKeyExchange、ClientKeyExchangeに含まれる鍵材料の生成、およびマスター秘密情報の生成にIDベース暗号技術を用いる変形も可能である。ClientHelloやServerHelloに識別子を含めて送信する変形や、ClientHelloにIDベース暗号技術用の公開パラメータを含める変形も可能である。
第2の実施の形態に係る技術は、上記のようなハンドシェークを行う際に、相手の応答を待たずに続けて送信できるメッセージ群の送受信回数を低減する仕組みを提供する。
ここで、鍵および鍵材料の生成方法を含む鍵交換の仕組みについて説明する。
以下、標数をpとして、素体Fpで定義される楕円曲線上の加法巡回群をE(Fp)と表記する。また、E(Fp)の位数#E(Fp)を割り切る最大素数をrとし、r|pk-1を満たすkを埋め込み次数と呼ぶ。r|pk-1はrがpk-1の約数であることを表す。また、E(Fp)における位数rの部分加法群をE(Fp){r}とする。
ここで、下記の式(1)により双線形写像eを定義する。双線形写像eは、巡回群G1の元および巡回群G2の元を入力として拡大体G3上の元を出力する関数(ペアリング関数)で表現される。なお、G/HはGのHに対する商群又は剰余群である。また、Fp k*/(Fp k*rは、r乗すると1になるFp k*の元からなる巡回群である。
e:G2×G1→G3 (又は、e:G1×G2→G3),
但し、
G1:E(Fp){r},
G2:E(Fp k){r},
G3:Fp k*/(Fp k*)r
…(1)
また、0から(r-1)までの整数でなる群をZrと表記する。Zrの元α(α∈Zr)、巡回群G1又はG2の元P(P∈G1又はG2)について、スカラー倍算αPは、Pをα個加算する演算と定義される。さらに、拡大体G3の元x(x∈G3)について、べき乗算xαは、xをα個乗算する演算計算と定義される。このとき、双線形性とは、下記の式(2)を満たす性質をいう。
e(xP,Q) = e(P,xQ) = e(P,Q)x
…(2)
マスター秘密鍵s(s∈Zr)を決定して秘密に保持するPKG(Private Key Generator)は、公開パラメータとしてP(P∈G1)、Q(Q∈G2)、e、H(ハッシュ関数)、P0(P0=sP∈G1)を決定し、(P,Q,e,H,P0)を公開する。なお、マスター秘密鍵sは上述したマスター秘密情報とは異なる。
例えば、サーバ装置が識別子IDAに対応し、クライアント装置が識別子IDBに対応し、サーバ装置およびクライアント装置はそれぞれ識別子IDA、IDBを知っているとする。識別子IDAに対応する公開鍵PAは、下記の式(3)で定義され、公開パラメータを用いて誰でも算出できる。同様に、識別子IDBに対応する公開鍵PBは、下記の式(4)で定義され、公開パラメータを用いて誰でも算出できる。
識別子IDAに対応するプライベート鍵SAは、下記の式(5)で定義され、マスター秘密鍵sを保持しているPKGだけが算出できる。同様に、識別子IDBに対応するプライベート鍵SBは、下記の式(6)で定義され、マスター秘密鍵sを保持しているPKGだけが算出できる。PKGは、識別子IDAで認証を受ける権利のある正しい主体(サーバ装置)にプライベート鍵SAを通知する。また、PKGは、識別子IDBで認証を受ける権利のある正しい主体(クライアント装置)にプライベート鍵SBを通知する。
PA = aP + P0= (a+s)P,
但し、a = H(IDA)
…(3)
PB = bP + P0 = (b+s)P,
但し、b = H(IDB)
…(4)
SA = (a+s)-1Q
…(5)
SB = (b+s)-1Q
…(6)
クライアント装置とサーバ装置との間で鍵交換を行う場合、サーバ装置は、乱数rAを生成し、公開鍵PBを用いてサーバ生成鍵材料RA(RA=rAPB)を生成する。そして、サーバ装置は、サーバ生成鍵材料RAをクライアント装置に送信する。クライアント装置は、乱数rBを生成し、公開鍵PAを用いてクライアント生成鍵材料RB(RB=rBPA)を生成する。そして、クライアント装置は、クライアント生成鍵材料RBをサーバ装置に送信する。
サーバ生成鍵材料RAを受信したクライアント装置は、プライベート鍵SB、サーバ生成鍵材料RA、乱数rB、および公開パラメータを用いて共有鍵ZB(ZB=e(RA,rBSB))を計算する。一方、クライアント生成鍵材料RBを受信したサーバ装置は、プライベート鍵SA、クライアント生成鍵材料RB、乱数rA、および公開パラメータを用いて共有鍵ZA(ZA=e(RB,rASA))を計算する。なお、上記の共有鍵は、セッション鍵と呼ばれることもあるが、本稿では共有鍵と呼ぶことにする。
上記の共有鍵ZA、ZBは、サーバ生成鍵材料RAおよびクライアント生成鍵材料RBが途中で改ざんされていなければ、下記の式(7)および式(8)より一致する。つまり、サーバ装置およびクライアント装置は共有鍵を得ることができ、鍵交換が成立する。なお、上述したTLSの通信開始時に行われるハンドシェークでは、クライアント生成検証子およびサーバ生成検証子を用いて改ざんの有無が検証されている。
ZB=e(RA,rBSB)=e(rAPB,rBSB)
=e(PB,SB)rArB
=e((b+s)P,(b+s)-1Q)rArB
=e(P,Q)rArB
…(7)
ZA=e(RB,rASA)=e(rBPA,rASA)
=e(PA,SA)rArB
=e((a+s)P,(a+s)-1Q)rArB
=e(P,Q)rArB
…(8)
なお、IDベース暗号技術を利用して鍵交換を行う方式には、上記の他にも、乱数を相手の公開鍵で暗号化したものを鍵材料として利用する方法などがある。この場合、鍵材料を受け取った相手が秘密鍵で鍵材料から乱数を復号できるため、復号された乱数を共有鍵として利用することができる。
TLSでは、上記の共有鍵ZA、ZBがプリマスター秘密情報として利用され、プリマスター秘密情報に基づいてマスター秘密情報が生成される。そして、マスター秘密情報を用いて通信データを暗号化することで、クライアント装置とサーバ装置との間で暗号通信が実現される。プリマスター秘密情報からマスター秘密情報を生成する仕組みは、TLS仕様の中で以下のように決められている。
プリマスター秘密情報(pre_master_secret)からマスター秘密情報(master_secret)を生成する処理は、TLSの仕様(例えば、「T.Dierks and C.Allen. The TLS Protocol Version 1.0, IETF Request for Comments (RFC) 2246, January 1999」を参照)で下記の式(9)のように定義されている。
master_secret = PRF(pre_master_secret,"master secret",
ClientHello.random + ServerHello.random) {0..47}
…(9)
上記の式(9)の中で"master secret"は、「master secret」という固定文字列(ラベル)のバイト列を表す。また、ClientHello.random、ServerHello.randomは、それぞれClientHello、ServerHelloで送られる乱数である。{0..47}は、任意長のバイト列を出力できるPRFが出力する出力値の先頭48バイトを意味する。PRFは、下記の式(10)のように定義されている。
PRF(secret,label,seed) = P_MD5(S01,label+seed) XOR P_SHA-1(S02,label+seed)
…(10)
上記の式(10)の中でsecretは秘密鍵である。S01は、secretをバイト単位で前後2分割したとき前半部のバイト列である。一方、S02は、secretをバイト単位で前後2分割したとき後半部のバイト列である。但し、secretが奇数バイトの場合は、secretの中央の1バイトがS01の最後のバイトとS02の最初のバイトとに重複して使われる。「+」はバイト列の連結を意味する。
P_hash(secret,seed)は、秘密値secretおよび付加情報seedからハッシュ関数hashによって任意の長さのバイト列を生成する関数である。P_hash(secret,seed)は、下記の式(11)のように定義される。HMAC_hash(secret,value)はvalueに対するHMAC(Hash-based Message Authentication Code)である。また、関数Aは、i=1,2,3,...について、下記の式(12)のように定義される。
P_hash(secret,seed) = HMAC_hash(secret,A(1)+seed) +
HMAC_hash(secret,A(2)+seed) +
HMAC_hash(secret,A(3)+seed) + ...
…(11)
A(0) = seed,
A(i) = HMAC_hash(secret,A(i-1))
…(12)
マスター秘密情報は、プリマスター秘密情報を秘密鍵とし、ClientHelloとServerHelloに含まれる乱数の連結を付加情報(シード)として、HMAC-MD1で48バイトに引き伸ばした値とHMAC-SHA-1で48バイトに引き伸ばした値をXORしたものとして与えられる。
[2−1.システム]
次に、図2を参照しながら、第2の実施の形態に係るシステムについて説明する。図2は、第2の実施の形態に係るシステムの一例を示した図である。
図2に示すように、第2の実施の形態に係るシステムは、ネットワーク74を介して接続されたクライアント装置100とサーバ装置200とを有する。
クライアント装置100およびサーバ装置200はコンピュータである。例えば、クライアント装置100は、携帯電話機、スマートフォン、タブレット端末、PCなどのコンピュータである。サーバ装置200は、例えば、PCや汎用計算機などのコンピュータである。
なお、クライアント装置100は、ハンドシェークの際にイニシエータ(Initiator)として動作するコンピュータである。サーバ装置200は、ハンドシェークの際にレスポンダ(Responder)として動作するコンピュータである。
ネットワーク74は、有線又は無線のネットワークである。クライアント装置100は、例えば、TCP/IPなどのプロトコル上のメッセージに含めて情報をサーバ装置200に送信できる。サーバ装置200は、例えば、TCP/IPなどのプロトコル上のメッセージに含めて情報をクライアント装置100に送信できる。
以下、図2のシステムを例に説明を進める。
[2−2.ハードウェア]
まず、図3を参照しながら、クライアント装置100のハードウェアについて説明する。図3は、第2の実施の形態に係るクライアント装置の機能を実現可能なハードウェアの一例を示した図である。
クライアント装置100は、CPU101、RAM102、HDD103、画像信号処理部104、入力信号処理部105、媒体リーダ106および通信インタフェース107を有する。CPU101は、第1の実施の形態の制御部12の一例である。
CPU101は、プログラムの命令を実行する演算回路を含むプロセッサである。CPU101は、HDD103に記憶されているプログラムやデータの少なくとも一部をRAM102にロードし、プログラムを実行する。
なお、CPU101は複数のプロセッサコアを備えてもよく、クライアント装置100は複数のプロセッサを備えてもよく、以下で説明する処理を複数のプロセッサまたはプロセッサコアを用いて並列実行してもよい。また、複数のプロセッサの集合(マルチプロセッサ)を「プロセッサ」と呼んでもよい。
RAM102は、CPU101が実行するプログラムやCPU101が演算に用いるデータを一時的に記憶する揮発性メモリである。なお、クライアント装置100は、RAM以外の種類のメモリを備えてもよく、複数個のメモリを備えてもよい。
HDD103は、OS(Operating System)やアプリケーションソフトウェアなどのソフトウェアのプログラム、および、データを記憶する不揮発性の記憶装置である。なお、クライアント装置100は、フラッシュメモリやSSD(Solid State Drive)などの他の種類の記憶装置を備えてもよく、複数の不揮発性の記憶装置を備えてもよい。
画像信号処理部104は、CPU101からの命令に従って、クライアント装置100に接続されたディスプレイ71に画像を出力する。ディスプレイ71としては、CRT(Cathode Ray Tube)ディスプレイ、液晶ディスプレイ(LCD:Liquid Crystal Display)、プラズマディスプレイ(PDP:Plasma Display Panel)、有機EL(OEL:Organic Electro-Luminescence)ディスプレイなどを用いることができる。
入力信号処理部105は、クライアント装置100に接続された入力デバイス72から入力信号を取得し、CPU101に出力する。
入力デバイス72としては、マウスやタッチパネルやタッチパッドやトラックボールなどのポインティングデバイス、キーボード、リモートコントローラ、ボタンスイッチなどを用いることができる。また、クライアント装置100に、複数の種類の入力デバイスが接続されていてもよい。なお、ディスプレイ71および入力デバイス72の少なくとも一方が、クライアント装置100の筐体と一体に形成されていてもよい。
媒体リーダ106は、記録媒体73に記録されたプログラムやデータを読み取る読み取り装置である。記録媒体73として、例えば、フレキシブルディスク(FD:Flexible Disk)やHDDなどの磁気ディスク、CD(Compact Disc)やDVD(Digital Versatile Disc)などの光ディスク、光磁気ディスク(MO:Magneto-Optical disk)、半導体メモリなどを使用できる。媒体リーダ106は、例えば、記録媒体73から読み取ったプログラムやデータをRAM102またはHDD103に格納する。
通信インタフェース107は、ネットワーク74に接続され、ネットワーク74を介して他の情報処理装置と通信を行うインタフェースである。通信インタフェース107は、スイッチなどの通信装置とケーブルで接続される有線通信インタフェースでもよいし、基地局と無線リンクで接続される無線通信インタフェースでもよい。
以上、クライアント装置100のハードウェアについて説明した。なお、サーバ装置200の機能も図3に例示したクライアント装置100のハードウェアと同様のハードウェアを用いて実現可能である。そのため、サーバ装置200が有する機能を実現可能なハードウェアの詳細な説明は省略する。
[2−3.機能]
次に、クライアント装置100およびサーバ装置200が有する機能について説明する。
(クライアント装置100)
まず、図4を参照しながら、クライアント装置100の機能について説明する。図4は、第2の実施の形態に係るクライアント装置が有する機能の一例を示したブロック図である。
図4に示すように、クライアント装置100は、記憶部111、鍵材料生成部112、通信部113、共有鍵生成部114、および検証処理部115を有する。
なお、記憶部111の機能は、上述したRAM102やHDD103などを用いて実現できる。鍵材料生成部112、共有鍵生成部114、および検証処理部115の機能は、上述したCPU101などを用いて実現できる。通信部113の機能は、上述したCPU101や通信インタフェース107などを用いて実現できる。
記憶部111には、クライアント識別情報111aおよびサーバ識別情報111bが格納されている。クライアント識別情報111aは、クライアント装置100を識別するための識別情報である。サーバ識別情報111bは、サーバ装置200を識別するための識別情報である。なお、記憶部111には、PKGにより公開されている公開パラメータおよびPKGから通知されたプライベート鍵が格納されているものとする。
鍵材料生成部112は、乱数を生成し、生成した乱数およびサーバ装置200の公開鍵を用いてクライアント生成鍵材料を生成する。通信部113は、ClientHello、ClientKeyExchange、Finished(C)などのメッセージをサーバ装置200に送信する。また、通信部113は、サーバ装置200からServerHello、ServerKeyExchange、Finished(S)などのメッセージを受信する。
共有鍵生成部114は、サーバ装置200から受信したメッセージに含まれるサーバ生成鍵材料、鍵材料生成部112が生成した乱数、公開パラメータ、およびPKGから通知されているプライベート鍵を用いてマスター秘密情報を生成する。検証処理部115は、共有鍵生成部114が生成したマスター秘密情報を用いてクライアント生成検証子を生成する。また、検証処理部115は、サーバ装置200から受信したメッセージに含まれるサーバ生成検証子を検証する。
(サーバ装置200)
次に、図5を参照しながら、サーバ装置200の機能について説明する。図5は、第2の実施の形態に係るサーバ装置が有する機能の一例を示したブロック図である。
図5に示すように、サーバ装置200は、記憶部211、通信部212、鍵材料生成部213、共有鍵生成部214、および検証処理部215を有する。
なお、記憶部211の機能は、上述したRAM102やHDD103などに相当するハードウェア資源を用いて実現できる。鍵材料生成部213、共有鍵生成部214、および検証処理部215の機能は、上述したCPU101などに相当するハードウェア資源を用いて実現できる。通信部212の機能は、上述したCPU101や通信インタフェース107などに相当するハードウェア資源を用いて実現できる。
記憶部211には、サーバ識別情報211aが格納されている。サーバ識別情報211aは、サーバ装置200を識別するための識別情報である。なお、記憶部211には、PKGにより公開されている公開パラメータおよびPKGから通知されたプライベート鍵が格納されているものとする。また、記憶部211には、許容するクライアント装置を特定するためのクライアント識別情報のリストが格納されていてもよい。
通信部212は、ClientHello、ClientKeyExchange、Finished(C)などのメッセージをクライアント装置100から受信する。また、通信部212は、ServerHello、ServerKeyExchange、Finished(S)などのメッセージをクライアント装置100に送信する。鍵材料生成部213は、乱数を生成し、生成した乱数およびクライアント装置100の公開鍵を用いてサーバ生成鍵材料を生成する。
共有鍵生成部214は、クライアント装置100から受信したメッセージに含まれるクライアント生成鍵材料、鍵材料生成部213が生成した乱数、公開パラメータ、およびPKGから通知されているプライベート鍵を用いてマスター秘密情報を生成する。検証処理部215は、共有鍵生成部214が生成したマスター秘密情報を用いてサーバ生成検証子を生成する。また、検証処理部215は、クライアント装置100から受信したメッセージに含まれるクライアント生成検証子を検証する。
以上、クライアント装置100およびサーバ装置200が有する機能について説明した。
[2−4.処理の流れ]
次に、クライアント装置100およびサーバ装置200がハンドシェーク時に実行する認証処理の流れについて説明する。
(シーケンス:サーバ識別情報のエラーなし)
まず、図6を参照しながら、認証処理に用いるサーバ識別情報としてクライアント装置100がサーバ装置200に送信した識別子をサーバ装置200が許容する場合(エラーなしの場合)について認証処理の流れを説明する。図6は、第2の実施の形態に係る認証処理の流れ(エラーなし)を示したシーケンス図である。
なお、クライアント装置100およびサーバ装置200は、PKGが公開している公開パラメータ(P,Q,e,H,P0)を保持しているものとする。但し、Pは巡回群G1の生成元、Qは巡回群G2の生成元、eは上記の式(1)で与えられる双線形写像、Hはハッシュ関数、P0はPKGが秘密に保持するマスター秘密鍵sとPから生成される巡回群G1の生成元(P0=sP∈G1)である。
また、クライアント装置100は、PKGから通知されるプライベート鍵SC(SC=(H(IDC)+s)-1Q)を保持しているものとする。一方、サーバ装置200は、PKGから通知されるプライベート鍵SS0(SS0=(H(IDS0)+s)-1Q)およびSS1(SS1=(H(IDS1)+s)-1Q)の少なくとも1つを保持しているものとする。また、サーバ装置200を識別するための識別子として、識別子IDS0、IDS1の少なくとも1つが利用できるものとする。
(S101)通信部113は、認証処理に用いるクライアント識別情報111a(識別子IDC)およびサーバ識別情報111b(識別子IDS0)をClientHelloに含める。なお、識別子IDCおよびIDS0を含むClientHelloをClientHello{IDC,IDS0}と表記する場合がある。通信部113は、ClientHello{IDC,IDS0}をサーバ装置200に送信する。
(S102)鍵材料生成部112は、乱数rCを生成する。また、鍵材料生成部112は、公開パラメータH、P、P0と、識別子IDS0とを用いてサーバ装置200の公開鍵PS0(PS0=H(IDS0)P+P0)を生成する。そして、鍵材料生成部112は、乱数rCおよびサーバ装置200の公開鍵PS0を用いてクライアント生成鍵材料RC0(RC0=rCPS0)を生成する。
通信部113は、クライアント生成鍵材料RC0をClientKeyExchangeに含める。なお、クライアント生成鍵材料RC0を含むClientKeyExchangeをClientKeyExchange{RC0}と表記する場合がある。通信部113は、ClientKeyExchange{RC0}をサーバ装置200に送信する。
ところで、ClientHelloおよびClientKeyExchangeは、それぞれサーバ装置200の応答を待たずに送信することができる。そのため、図6の例では、ClientHello{IDC,IDS0}およびClientKeyExchange{RC0}の送信は、サーバ装置200の応答を待たずに送信可能なメッセージ群(Com#1)の送信となる。このようなメッセージ群の送信をフライトと呼ぶ場合がある。例えば、Com#1は1回のフライトとなる。
(S103)通信部212は、ClientHello{IDC,IDS0}およびClientKeyExchange{RC0}を受信する。
鍵材料生成部213は、乱数rS0を生成する。また、鍵材料生成部213は、公開パラメータH、P、P0と、ClientHelloから取り出した識別子IDCとを用いてクライアント装置100の公開鍵PC(PC=H(IDC)P+P0)を生成する。そして、鍵材料生成部213は、乱数rS0および公開鍵PCを用いてサーバ生成鍵材料RS0(RS0=rS0PC)を生成する。
共有鍵生成部214は、ClientKeyExchangeから取り出したクライアント生成鍵材料RC0と、乱数rS0と、識別子IDS0に対応するプライベート鍵SS0と、公開パラメータeとを用いて共有鍵ZSを生成する。この場合、共有鍵ZSは下記の式(13)で与えられる。そして、共有鍵生成部214は、TLS仕様(上記の式(9)から式(12)を参照)に従い、共有鍵ZSをプリマスター秘密情報としてマスター秘密情報MSを生成する。
ZS=e(RC0,rS0SS0)
…(13)
(S104)通信部212は、S103で共有鍵ZSの生成に用いられた識別子IDS0をServerHelloに含める。なお、識別子IDS0を含むServerHelloをServerHello{IDS0}と表記する場合がある。通信部212は、ServerHello{IDS0}をクライアント装置100に送信する。
(S105)通信部212は、S103で生成されたサーバ生成鍵材料RS0をServerKeyExchangeに含める。なお、サーバ生成鍵材料RS0を含むServerKeyExchangeをServerKeyExchange{RS0}と表記する場合がある。通信部212は、ServerKeyExchange{RS0}をクライアント装置100に送信する。
(S106)検証処理部215は、マスター秘密情報MSを用いてサーバ生成検証子(検証子verify_data)を生成する。検証子verify_dataは12バイトのバイト列である。TLS仕様で検証子verify_dataは下記の式(14)のように定義されている。
verify_data = PRF(master_secret,finished_label,
MD5(handshake_messages)+SHA-1(handshake_messages)){0..11}
…(14)
上記の式(14)の中でmaster_secretはマスター秘密情報MS、finished_labelは固定文字列(ラベル)のバイト列である。なお、サーバ生成検証子の場合、finished_labelは"server finished"のバイト列に設定される。後述するクライアント生成検証子の場合、finished_labelは"client finished"のバイト列に設定される。handshake_messagesは、ハンドシェーク内で、verify_dataを含めるFinishedより前に送受信された全てのメッセージを連結したバイト列である。
検証子verify_dataは、マスター秘密情報を秘密鍵とし、このverify_dataを含めるFinishedより前の全てのメッセージを連結したバイト列のMD5ハッシュ値とSHA-1ハッシュ値とを連結したバイト列を付加情報(シード)として、HMAC-MD1で12バイトに引き伸ばした値とHMAC-SHA-1で12バイトに引き伸ばした値とをXORしたものである。{0..11}は、任意長のバイト列を出力できるPRFが出力する出力値の先頭11バイトを意味する。
検証処理部215は、上記の式(14)に従い、マスター秘密情報MSを用いて検証子verify_dataを生成し、生成した検証子verify_dataをサーバ生成検証子とする。通信部212は、サーバ生成検証子をFinished(S)に含める。そして、通信部212は、Finished(S)をクライアント装置100に送信する。
ところで、ServerHello、ServerKeyExchange、Finished(S)は、それぞれクライアント装置100の応答を待たずに送信することができる。そのため、図6の例では、ServerHello{IDS0}、ServerKeyExchange{RS0}、およびFinished(S)の送信は、クライアント装置100の応答を待たずに送信可能なメッセージ群(Com#2)の送信となる。つまり、Com#2は1回のフライトとなる。
(S107)通信部113は、ServerHello{IDS0}、ServerKeyExchange{RS0}、およびFinished(S)を受信する。
共有鍵生成部114は、ServerKeyExchangeから取り出したサーバ生成鍵材料RS0と、乱数rCと、識別子IDCに対応するプライベート鍵SCと、公開パラメータeとを用いて共有鍵ZCを生成する。この場合、共有鍵Z C は下記の式(15)で与えられる。そして、共有鍵生成部114は、TLS仕様(上記の式(9)から式(12)を参照)に従い、共有鍵ZCをプリマスター秘密情報としてマスター秘密情報MCを生成する。
ZC = e(RS0,rCSC)
…(15)
(S108)検証処理部115は、マスター秘密情報MCを用いてクライアント生成検証子(検証子verify_data)を生成する。このとき、検証処理部115は、上述したマスター秘密情報MSと同様の方法で検証子verify_dataを生成する。但し、master_secretにマスター秘密情報MCを利用する点、finished_labelに"client finished"のバイト列を利用する点などが異なる。
検証処理部115は、Finished(S)から取り出したサーバ生成検証子とクライアント生成検証子とが一致するかを検証する。サーバ生成検証子とクライアント生成検証子とが一致した場合には認証成功となる。一方、サーバ生成検証子とクライアント生成検証子とが一致しなかった場合には認証失敗となる。
(S109)通信部113は、クライアント生成検証子をFinished(C)に含める。そして、通信部113は、Finished(C)をサーバ装置200に送信する。なお、Finished(C)の送信(Com#3)も他のメッセージに対するサーバ装置200の応答を待たずに行えるため、1回のフライトとなる。
(S110)検証処理部215は、Finished(C)から取り出したクライアント生成検証子と、S106で生成したサーバ生成検証子とが一致するかを検証する。サーバ生成検証子とクライアント生成検証子とが一致した場合には認証成功となる。一方、サーバ生成検証子とクライアント生成検証子とが一致しなかった場合には認証失敗となる。
S110の処理が完了すると、図6に示した一連の処理は終了する。上記のように、図6のシーケンスでは、ハンドシェークの際に生じるフライトの回数は3回(Com#1、#2、#3)となる。
(シーケンス:サーバ識別情報のエラーあり)
次に、図7を参照しながら、認証処理に用いるサーバ識別情報としてクライアント装置100がサーバ装置200に送信した識別子をサーバ装置200が許容しない場合(エラーありの場合)について認証処理の流れを説明する。図7は、第2の実施の形態に係る認証処理の流れ(エラーあり)を示したシーケンス図である。
(S121)通信部113は、認証処理に用いるクライアント識別情報111a(識別子IDC)およびサーバ識別情報111b(識別子IDS0)をClientHelloに含める。通信部113は、ClientHello{IDC,IDS0}をサーバ装置200に送信する。
(S122)鍵材料生成部112は、乱数rC0を生成する。また、鍵材料生成部112は、公開パラメータH、P、P0と、識別子IDS0とを用いてサーバ装置200の公開鍵PS0(PS0=H(IDS0)P+P0)を生成する。そして、鍵材料生成部112は、乱数rC0およびサーバ装置200の公開鍵PS0を用いてクライアント生成鍵材料RC0(RC0=rC0PS0)を生成する。
通信部113は、クライアント生成鍵材料RC0をClientKeyExchangeに含める。そして、通信部113は、ClientKeyExchange{RC0}をサーバ装置200に送信する。
(S123)通信部212は、ClientHelloから識別子IDS0を取り出し、認証に用いる識別子としてIDS0を許容するかを判定する。図7の例では、識別子IDS0は許容されない。例えば、識別子IDS0の有効期限が切れている場合などに識別子IDS0が許容されない。
(S124)通信部212は、エラーの発生を示す情報errorと、認証に用いる識別子として許容可能な識別子IDS1とをServerHelloに含める。なお、error、IDS1を含むServerHelloをServerHello{error,IDS1}と表記する場合がある。通信部212は、ServerHello{error,IDS1}をクライアント装置100に送信する。
(S125)ServerHello{error,IDS1}を受信した通信部113は、識別子IDS1を許容して、識別子IDS1を用いた認証処理を進めるかを判断する。図7の例では識別子IDS1が許容される。
鍵材料生成部112は、乱数rC1を生成する。また、鍵材料生成部112は、公開パラメータH、P、P0と、識別子IDS1とを用いてサーバ装置200の公開鍵PS1(PS1=H(IDS1)P+P0)を生成する。そして、鍵材料生成部112は、乱数rC1およびサーバ装置200の公開鍵PS1を用いてクライアント生成鍵材料RC1(RC1=rC1PS1)を生成する。
通信部113は、クライアント生成鍵材料RC1をClientKeyExchangeに含める。そして、通信部113は、ClientKeyExchange{RC1}をサーバ装置200に送信する。
(S126)通信部212は、ClientKeyExchange{RC1}を受信する。鍵材料生成部213は、乱数rS1を生成する。また、鍵材料生成部213は、公開パラメータH、P、P0と、ClientHelloから取り出した識別子IDCとを用いてクライアント装置100の公開鍵PC(PC=H(IDC)P+P0)を生成する。そして、鍵材料生成部213は、乱数rS1および公開鍵PCを用いてサーバ生成鍵材料RS1(RS1=rS1PC)を生成する。
共有鍵生成部214は、ClientKeyExchangeから取り出したクライアント生成鍵材料RC1と、乱数rS1と、識別子IDS1に対応するプライベート鍵SS1と、公開パラメータeとを用いて共有鍵ZSを生成する。この場合、共有鍵ZSは下記の式(16)で与えられる。そして、共有鍵生成部214は、TLS仕様(上記の式(9)から式(12)を参照)に従い、共有鍵ZSをプリマスター秘密情報としてマスター秘密情報MSを生成する。
ZS=e(RC1,rS1SS1)
…(16)
(S127)通信部212は、S126で生成されたサーバ生成鍵材料RS1をServerKeyExchangeに含める。通信部212は、ServerKeyExchange{RS1}をクライアント装置100に送信する。
(S128)検証処理部215は、マスター秘密情報MSを用いてサーバ生成検証子(検証子verify_data)を生成する。通信部212は、サーバ生成検証子をFinished(S)に含める。そして、通信部212は、Finished(S)をクライアント装置100に送信する。
(S129)通信部113は、ServerKeyExchange{RS1}、およびFinished(S)を受信する。
共有鍵生成部114は、ServerKeyExchangeから取り出したサーバ生成鍵材料RS1と、乱数rC1と、識別子IDCに対応するプライベート鍵SCと、公開パラメータeとを用いて共有鍵ZCを生成する。この場合、共有鍵Z C は下記の式(17)で与えられる。そして、共有鍵生成部114は、TLS仕様(上記の式(9)から式(12)を参照)に従い、共有鍵ZCをプリマスター秘密情報としてマスター秘密情報MCを生成する。
ZC=e(RS1,rC1SC)
…(17)
(S130)検証処理部115は、マスター秘密情報MCを用いてクライアント生成検証子(検証子verify_data)を生成する。また、検証処理部115は、Finished(S)から取り出したサーバ生成検証子とクライアント生成検証子とが一致するかを検証する。サーバ生成検証子とクライアント生成検証子とが一致した場合には認証成功となる。一方、サーバ生成検証子とクライアント生成検証子とが一致しなかった場合には認証失敗となる。
(S131)通信部113は、クライアント生成検証子をFinished(C)に含める。そして、通信部113は、Finished(C)をサーバ装置200に送信する。
(S132)検証処理部215は、Finished(C)から取り出したクライアント生成検証子と、S128で生成したサーバ生成検証子とが一致するかを検証する。サーバ生成検証子とクライアント生成検証子とが一致した場合には認証成功となる。一方、サーバ生成検証子とクライアント生成検証子とが一致しなかった場合には認証失敗となる。
S132の処理が完了すると、図7に示した一連の処理は終了する。図7のシーケンスでは、ハンドシェークの際に生じるフライトの回数は5回(Com#1、#2、…、#5)となる。
(シーケンス:比較例)
ここで、比較例として、図8を参照しながら、TLSのハンドシェークに係る認証処理の流れ(比較例:エラーなし)について述べる。図8は、TLSのハンドシェークに係る認証処理の流れ(比較例:エラーなし)を示したシーケンス図である。
(S901)クライアント装置は、クライアント識別情報として識別子IDCを選択し、識別子IDCをClientHelloに含めてサーバ装置に送信する。ClientHello{IDC}の送信(Com#1)は1回のフライトとなる。
(S902)ClientHello{IDC}を受信したサーバ装置は、認証に利用するサーバ識別情報として識別子IDSを選択し、識別子IDSをServerHelloに含めてクライアント装置に送信する。
(S903)サーバ装置は、サーバ生成鍵材料RSを生成し、サーバ生成鍵材料RSをServerKeyExchangeに含めてクライアント装置に送信する。
ServerHello{IDS}およびServerKeyExchange{RS}の送信(Com#2)は1回のフライトとなる。
(S904)ServerHello{IDS}およびServerKeyExchange{RS}を受信したクライアント装置は、マスター秘密情報MCを生成する。
(S905)クライアント装置は、クライアント生成鍵材料RCを生成し、クライアント生成鍵材料RCをClientKeyExchangeに含めてサーバ装置に送信する。
(S906)クライアント装置は、マスター秘密情報MCを用いてクライアント生成検証子を生成し、クライアント生成検証子をFinished(C)に含めてサーバ装置に送信する。
ClientKeyExchange{RC}およびFinished(C)の送信(Com#3)は1回のフライトとなる。
(S907)ClientKeyExchange{RC}およびFinished(C)を受信したサーバ装置は、マスター秘密情報MSを生成する。
(S908)サーバ装置は、マスター秘密情報MSを用いてサーバ生成検証子を生成し、サーバ生成検証子を用いて、Finished(C)に含まれるクライアント生成検証子を検証する。
(S909)サーバ装置は、サーバ生成検証子をFinished(S)に含めてクライアント装置に送信する。Finished(S)の送信(Com#4)は1回のフライトとなる。
(S910)Finished(S)を受信したクライアント装置は、クライアント生成検証子を用いて、Finished(S)に含まれるサーバ生成検証子を検証する。
上記のように、比較例のようなTLSのハンドシェークに係る認証処理(エラーなし)の場合、フライトの回数は4回となる。一方、図6に示した認証処理の場合、フライトの回数は3回となる。つまり、図6の方法を用いれば、フライトの回数を削減することができ、ハンドシェークの際に通信負荷を低減することが可能になる。
(状態遷移:クライアント装置100)
ここで、図9を参照しながら、クライアント装置100の状態遷移について説明する。図9は、第2の実施の形態に係るクライアント装置の状態遷移を示した図である。
(状態C0、C1、C2、C3について)
図6および図7に示したように、クライアント装置100は相手から送信される特定のメッセージを待ち受け、そのメッセージを受けて処理を実行する。クライアント装置100は、図9に示すように、ハンドシェークを実行する前の初期状態(状態C0)、サーバ装置200から送信されるメッセージを待ち受ける待ち受け状態(状態C1、C3)、およびハンドシェークの処理を完了した完了状態(状態C2)をとる。
クライアント装置100は、特定の条件を満たした場合に状態を遷移させる。図9の例では、状態C0から状態C1への遷移を遷移C01、状態C0から状態C3への遷移を遷移C03、状態C1から状態C2への遷移を遷移C12、および状態C3から状態C2への遷移を遷移C32と表現している。遷移C01、C03、C12、C32の条件、およびその条件を満たした場合に実行される処理の内容は以下のように設定されている。
(遷移C01について)
遷移C01の条件は、状態C0にあるクライアント装置100が「TLS通信を始めるとき」である。
遷移C01の中で、通信部113は、認証処理に用いるクライアント識別情報111a(識別子IDC)およびサーバ識別情報111b(識別子IDS0)を決定する。
鍵材料生成部112は、乱数rC0を生成する。また、鍵材料生成部112は、公開パラメータH、P、P0と、識別子IDS0とを用いてサーバ装置200の公開鍵PS0(PS0=H(IDS0)P+P0)を生成する。そして、鍵材料生成部112は、乱数rC0およびサーバ装置200の公開鍵PS0を用いてクライアント生成鍵材料RC0(RC0=rC0PS0)を生成する。
通信部113は、識別子IDC、IDS0をClientHelloに含める。そして、通信部113は、ClientHello{IDC,IDS0}をサーバ装置200に送信する。また、通信部113は、クライアント生成鍵材料RC0をClientKeyExchangeに含める。そして、通信部113は、ClientKeyExchange{RC0}をサーバ装置200に送信する。
(遷移C03について)
遷移C03の条件は、状態C0にあるクライアント装置100が「ServerHello(エラーあり)を受信したとき」である。
通信部113が送信したClientHello{IDC,IDS0}に対し、サーバ装置200が識別子IDS0を許容しない場合(図7参照)、例えば、サーバ装置200からServerHello{error,IDS1}が送信される。このように、errorを含むServerHelloをクライアント装置100が受信したとき、遷移C03が生じる。
遷移C03の中で、通信部113は、ServerHelloから識別子IDS1を取り出し、識別子IDS1を許容して、識別子IDS1を用いた認証処理を進めるかを判断する。通信部113が識別子IDS1を許容しない場合、ハンドシェークは失敗となる。
通信部113が識別子IDS1を許容する場合、鍵材料生成部112は、乱数rC1を生成する。また、鍵材料生成部112は、公開パラメータH、P、P0と、識別子IDS1とを用いてサーバ装置200の公開鍵PS1(PS1=H(IDS1)P+P0)を生成する。そして、鍵材料生成部112は、乱数rC1およびサーバ装置200の公開鍵PS1を用いてクライアント生成鍵材料RC1(RC1=rC1PS1)を生成する。
通信部113は、クライアント生成鍵材料RC1をClientKeyExchangeに含める。そして、通信部113は、ClientKeyExchange{RC1}をサーバ装置200に送信する。
(遷移C12について)
遷移C12の条件は、状態C1にあるクライアント装置100が「ServerHello、ServerKeyExchange、Finished(S)を受信したとき」である。
遷移C12の中で、共有鍵生成部114は、ServerKeyExchangeからサーバ生成鍵材料RS0を取り出し、サーバ生成鍵材料RS0と、乱数rC0と、識別子IDCに対応するプライベート鍵SCと、公開パラメータeとを用いて共有鍵ZCを生成する。そして、共有鍵生成部114は、TLS仕様に従い、共有鍵ZCをプリマスター秘密情報としてマスター秘密情報MCを生成する。
検証処理部115は、マスター秘密情報MCを用いてクライアント生成検証子(検証子verify_data)を生成する。また、検証処理部115は、Finished(S)から取り出したサーバ生成検証子とクライアント生成検証子とが一致するかを検証する。サーバ生成検証子とクライアント生成検証子とが一致しなかった場合、ハンドシェークは失敗となる。
サーバ生成検証子とクライアント生成検証子とが一致した場合、通信部113は、クライアント生成検証子をFinished(C)に含め、Finished(C)をサーバ装置200に送信する。
(遷移C32について)
遷移C32の条件は、状態C3にあるクライアント装置100が「ServerKeyExchange、Finished(S)を受信したとき」である。
遷移C32の中で、共有鍵生成部114は、ServerKeyExchangeからサーバ生成鍵材料RS1を取り出す。また、共有鍵生成部114は、サーバ生成鍵材料RS1と、乱数rC1と、識別子IDCに対応するプライベート鍵SCと、公開パラメータeとを用いて共有鍵ZCを生成する。そして、共有鍵生成部114は、TLS仕様に従い、共有鍵ZCをプリマスター秘密情報としてマスター秘密情報MCを生成する。
検証処理部115は、マスター秘密情報MCを用いてクライアント生成検証子(検証子verify_data)を生成する。また、検証処理部115は、Finished(S)から取り出したサーバ生成検証子とクライアント生成検証子とが一致するかを検証する。
サーバ生成検証子とクライアント生成検証子とが一致しなかった場合、ハンドシェークは失敗となる。サーバ生成検証子とクライアント生成検証子とが一致した場合、通信部113は、クライアント生成検証子をFinished(C)に含め、Finished(C)をサーバ装置200に送信する。
(状態遷移:サーバ装置200)
次に、図10を参照しながら、サーバ装置200の状態遷移について説明する。図10は、第2の実施の形態に係るサーバ装置の状態遷移を示した図である。
(状態S0、S1、S2、S3について)
図6および図7に示したように、サーバ装置200はクライアント装置100から送信される特定のメッセージを待ち受け、そのメッセージを受けて処理を実行する。サーバ装置200は、図10に示すように、クライアント装置100から送信されるメッセージを待ち受ける待ち受け状態(状態S0、S1、S3)、およびハンドシェークの処理を完了した完了状態(状態S2)をとる。
サーバ装置200は、特定の条件を満たした場合に状態を遷移させる。図10の例では、状態S0から状態S1への遷移を遷移S01、状態S0から状態S3への遷移を遷移S03、状態S1から状態S2への遷移を遷移S12、および状態S3から状態S1への遷移を遷移S31と表現している。遷移S01、S03、S12、S31の条件、およびその条件を満たした場合に実行される処理の内容は以下のように設定されている。
(遷移S01について)
遷移S01の条件は、状態S0にあるサーバ装置200が「ClientHello、ClientKeyExchangeを受信し、ClientHelloのIDS0を許容するとき」である。
遷移S01の中で、通信部212は、ClientHelloから識別子IDCを取り出し、認証処理の相手となるクライアント装置100の識別子として識別子IDCを許容するかを判断する。
例えば、識別子IDCに有効期限が設定されている場合、通信部212は、識別子IDCが有効期限内であれば許容する。また、ハンドシェークの相手として許容可能なクライアント装置100の識別子を列挙したリストをサーバ装置200が保持している場合、通信部212は、識別子IDCがリストにある場合に識別子IDCを許容する。通信部212が識別子IDCを許容しない場合、ハンドシェークは失敗となる。
識別子IDCが許容された場合、鍵材料生成部213は、ClientKeyExchangeからクライアント生成鍵材料RC0を取り出し、乱数rS0を生成する。また、鍵材料生成部213は、公開パラメータH、P、P0と、ClientHelloから取り出した識別子IDCとを用いてクライアント装置100の公開鍵PC(PC=H(IDC)P+P0)を生成する。そして、鍵材料生成部213は、乱数rS0および公開鍵PCを用いてサーバ生成鍵材料RS0(RS0=rS0PC)を生成する。
共有鍵生成部214は、ClientKeyExchangeから取り出したクライアント生成鍵材料RC0と、乱数rS0と、識別子IDS0に対応するプライベート鍵SS0と、公開パラメータeとを用いて共有鍵ZSを生成する。そして、共有鍵生成部214は、TLS仕様に従い、共有鍵ZSをプリマスター秘密情報としてマスター秘密情報MSを生成する。
通信部212は、識別子IDS0をServerHelloに含める。また、通信部212は、サーバ生成鍵材料RS0をServerKeyExchangeに含める。そして、通信部212は、ServerHello{IDS0}、ServerKeyExchange{RS0}をクライアント装置100に送信する。検証処理部215は、マスター秘密情報MSを用いてサーバ生成検証子(検証子verify_data)を生成する。通信部212は、サーバ生成検証子をFinished(S)に含め、Finished(S)をクライアント装置100に送信する。
(遷移S03について)
遷移S03の条件は、状態S0にあるサーバ装置200が「ClientHello、ClientKeyExchangeを受信し、ClientHelloのIDS0を許容しないとき」である。例えば、識別子IDS0の有効期限が切れている場合などに識別子IDS0が許容されない。
遷移S03の中で、通信部212は、ClientHelloから識別子IDCを取り出し、認証処理の相手となるクライアント装置100の識別子として識別子IDCを許容するかを判断する。
例えば、識別子IDCに有効期限が設定されている場合、通信部212は、識別子IDCが有効期限内であれば許容する。また、ハンドシェークの相手として許容可能なクライアント装置100の識別子を列挙したリストをサーバ装置200が保持している場合、通信部212は、識別子IDCがリストにある場合に識別子IDCを許容する。通信部212が識別子IDCを許容しない場合、ハンドシェークは失敗となる。
識別子IDCを許容しない場合、通信部212は、認証に用いる識別子として許容可能な代替の識別子IDS1を決定する。そして、通信部212は、エラーの発生を示す情報errorと、識別子IDS1とをServerHelloに含め、ServerHello{error,IDS1}をクライアント装置100に送信する。
(遷移S31について)
遷移S31の条件は、状態S3にあるサーバ装置200が「ClientKeyExchangeを受信したとき」である。
遷移S31の中で、鍵材料生成部213は、ClientKeyExchangeからクライアント生成鍵材料RC1を取り出し、乱数rS1を生成する。また、鍵材料生成部213は、公開パラメータH、P、P0と、ClientHelloから取り出した識別子IDCとを用いてクライアント装置100の公開鍵PC(PC=H(IDC)P+P0)を生成する。そして、鍵材料生成部213は、乱数rS1および公開鍵PCを用いてサーバ生成鍵材料RS1(RS1=rS1PC)を生成する。
共有鍵生成部214は、ClientKeyExchangeから取り出したクライアント生成鍵材料RC1と、乱数rS1と、識別子IDS1に対応するプライベート鍵SS1と、公開パラメータeとを用いて共有鍵ZSを生成する。そして、共有鍵生成部214は、TLS仕様に従い、共有鍵ZSをプリマスター秘密情報としてマスター秘密情報MSを生成する。
通信部212は、サーバ生成鍵材料RS1をServerKeyExchangeに含め、ServerKeyExchange{RS1}をクライアント装置100に送信する。検証処理部215は、マスター秘密情報MSを用いてサーバ生成検証子(検証子verify_data)を生成する。通信部212は、サーバ生成検証子をFinished(S)に含め、Finished(S)をクライアント装置100に送信する。
(遷移S12について)
遷移S12の条件は、状態S1にあるサーバ装置200が「Finished(C)を受信したとき」である。
検証処理部215は、Finished(C)から取り出したクライアント生成検証子と、サーバ生成検証子とが一致するかを検証する。サーバ生成検証子とクライアント生成検証子とが一致しなかった場合、ハンドシェークは失敗となる。
以上、クライアント装置100およびサーバ装置200がハンドシェーク時に実行する認証処理の流れについて説明した。
[2−5.変形例]
ここで、第2の実施の形態の一変形例について説明する。
(シーケンス:サーバ識別子のエラーあり)
図11を参照しながら、認証処理に用いるサーバ識別情報としてクライアント装置100がサーバ装置200に送信した識別子をサーバ装置200が許容しない場合(エラーありの場合)について本変形例に係る認証処理の流れを説明する。図11は、第2の実施の形態の一変形例に係る認証処理の流れ(エラーあり)を示したシーケンス図である。
(S201)通信部113は、認証処理に用いるクライアント識別情報111a(識別子IDC)およびサーバ識別情報111b(識別子IDS0)をClientHelloに含める。通信部113は、ClientHello{IDC,IDS0}をサーバ装置200に送信する。
(S202)鍵材料生成部112は、乱数rC0を生成する。また、鍵材料生成部112は、公開パラメータH、P、P0と、識別子IDS0とを用いてサーバ装置200の公開鍵PS0(PS0=H(IDS0)P+P0)を生成する。そして、鍵材料生成部112は、乱数rC0およびサーバ装置200の公開鍵PS0を用いてクライアント生成鍵材料RC0(RC0=rC0PS0)を生成する。
通信部113は、クライアント生成鍵材料RC0をClientKeyExchangeに含める。そして、通信部113は、ClientKeyExchange{RC0}をサーバ装置200に送信する。
(S203)通信部212は、ClientHelloから識別子IDS0を取り出し、認証に用いる識別子としてIDS0を許容するかを判定する。図11の例では、識別子IDS0は許容されない。例えば、識別子IDS0の有効期限が切れている場合などに識別子IDS0が許容されない。
(S204)通信部212は、エラーの発生を示す情報errorと、認証に用いる識別子として許容可能な識別子IDS1とをServerHelloに含める。そして、通信部212は、ServerHello{error,IDS1}をクライアント装置100に送信する。
(S205)鍵材料生成部213は、乱数rS1を生成する。また、鍵材料生成部213は、公開パラメータH、P、P0と、ClientHelloから取り出した識別子IDCとを用いてクライアント装置100の公開鍵PC(PC=H(IDC)P+P0)を生成する。そして、鍵材料生成部213は、乱数rS1および公開鍵PCを用いてサーバ生成鍵材料RS1(RS1=rS1PC)を生成する。
通信部212は、サーバ生成鍵材料RS1をServerKeyExchangeに含める。通信部212は、ServerKeyExchange{RS1}をクライアント装置100に送信する。
(S206)ServerHello{error,IDS1}、ServerKeyExchange{RS1}を受信した通信部113は、識別子IDS1を許容して、識別子IDS1を用いた認証処理を進めるかを判断する。図11の例では識別子IDS1が許容される。
鍵材料生成部112は、乱数rC1を生成する。また、鍵材料生成部112は、公開パラメータH、P、P0と、識別子IDS1とを用いてサーバ装置200の公開鍵PS1(PS1=H(IDS1)P+P0)を生成する。そして、鍵材料生成部112は、乱数rC1およびサーバ装置200の公開鍵PS1を用いてクライアント生成鍵材料RC1(RC1=rC1PS1)を生成する。
共有鍵生成部114は、ServerKeyExchangeから取り出したサーバ生成鍵材料RS1と、乱数rC1と、識別子IDCに対応するプライベート鍵SCと、公開パラメータeとを用いて共有鍵ZCを生成する。そして、共有鍵生成部114は、TLS仕様に従い、共有鍵ZCをプリマスター秘密情報としてマスター秘密情報MCを生成する。
(S207)通信部113は、クライアント生成鍵材料RC1をClientKeyExchangeに含める。そして、通信部113は、ClientKeyExchange{RC1}をサーバ装置200に送信する。
(S208)検証処理部115は、マスター秘密情報MCを用いてクライアント生成検証子(検証子verify_data)を生成する。通信部113は、クライアント生成検証子をFinished(C)に含める。そして、通信部113は、Finished(C)をサーバ装置200に送信する。
(S209)通信部212は、ClientKeyExchange{RC1}、Finished(C)を受信する。共有鍵生成部214は、ClientKeyExchangeから取り出したクライアント生成鍵材料RC1と、乱数rS1と、識別子IDS1に対応するプライベート鍵SS1と、公開パラメータeとを用いて共有鍵ZSを生成する。そして、共有鍵生成部214は、TLS仕様に従い、共有鍵ZSをプリマスター秘密情報としてマスター秘密情報MSを生成する。
(S210)検証処理部215は、マスター秘密情報MSを用いてサーバ生成検証子(検証子verify_data)を生成する。検証処理部215は、Finished(C)から取り出したクライアント生成検証子と、サーバ生成検証子とが一致するかを検証する。サーバ生成検証子とクライアント生成検証子とが一致した場合には認証成功となる。一方、サーバ生成検証子とクライアント生成検証子とが一致しなかった場合には認証失敗となる。
(S211)通信部212は、サーバ生成検証子をFinished(S)に含める。そして、通信部212は、Finished(S)をクライアント装置100に送信する。
(S212)通信部113は、Finished(S)を受信する。検証処理部115は、Finished(S)から取り出したサーバ生成検証子とクライアント生成検証子とが一致するかを検証する。サーバ生成検証子とクライアント生成検証子とが一致した場合には認証成功となる。一方、サーバ生成検証子とクライアント生成検証子とが一致しなかった場合には認証失敗となる。
S212の処理が完了すると、図11に示した一連の処理は終了する。図11のシーケンスでは、ハンドシェークの際に生じるフライトの回数は4回(Com#1、#2、…、#4)となる。つまり、本変形例によれば、図7のシーケンスに比べてフライトの回数を低減することができる。
(状態遷移:クライアント装置100)
ここで、図12を参照しながら、本変形例に係るクライアント装置100の状態遷移について説明する。図12は、第2の実施の形態の一変形例に係るクライアント装置の状態遷移を示した図である。
(遷移C01について)
遷移C01の条件は、状態C0にあるクライアント装置100が「TLS通信を始めるとき」である。
遷移C01の中で、通信部113は、認証処理に用いるクライアント識別情報111a(識別子IDC)およびサーバ識別情報111b(識別子IDS0)を決定する。
鍵材料生成部112は、乱数rC0を生成する。また、鍵材料生成部112は、公開パラメータH、P、P0と、識別子IDS0とを用いてサーバ装置200の公開鍵PS0(PS0=H(IDS0)P+P0)を生成する。そして、鍵材料生成部112は、乱数rC0およびサーバ装置200の公開鍵PS0を用いてクライアント生成鍵材料RC0(RC0=rC0PS0)を生成する。
通信部113は、識別子IDC、IDS0をClientHelloに含める。そして、通信部113は、ClientHello{IDC,IDS0}をサーバ装置200に送信する。また、通信部113は、クライアント生成鍵材料RC0をClientKeyExchangeに含める。そして、通信部113は、ClientKeyExchange{RC0}をサーバ装置200に送信する。
(遷移C03について)
遷移C03の条件は、状態C0にあるクライアント装置100が「ServerHello(エラーあり)、ServerKeyExchangeを受信したとき」である。
遷移C03の中で、通信部113は、ServerHelloから識別子IDS1を取り出し、識別子IDS1を許容して、識別子IDS1を用いた認証処理を進めるかを判断する。通信部113が識別子IDS1を許容しない場合、ハンドシェークは失敗となる。
通信部113が識別子IDS1を許容する場合、鍵材料生成部112は、乱数rC1を生成する。また、鍵材料生成部112は、公開パラメータH、P、P0と、識別子IDS1とを用いてサーバ装置200の公開鍵PS1(PS1=H(IDS1)P+P0)を生成する。そして、鍵材料生成部112は、乱数rC1およびサーバ装置200の公開鍵PS1を用いてクライアント生成鍵材料RC1(RC1=rC1PS1)を生成する。
共有鍵生成部114は、ServerKeyExchangeからサーバ生成鍵材料RS1を取り出す。また、共有鍵生成部114は、サーバ生成鍵材料RS1と、乱数rC1と、識別子IDCに対応するプライベート鍵SCと、公開パラメータeとを用いて共有鍵ZCを生成する。そして、共有鍵生成部114は、TLS仕様に従い、共有鍵ZCをプリマスター秘密情報としてマスター秘密情報MCを生成する。
通信部113は、クライアント生成鍵材料RC1をClientKeyExchangeに含める。そして、通信部113は、ClientKeyExchange{RC1}をサーバ装置200に送信する。また、通信部113は、クライアント生成検証子をFinished(C)に含め、Finished(C)をサーバ装置200に送信する。
(遷移C12について)
遷移C12の条件は、状態C1にあるクライアント装置100が「ServerHello、ServerKeyExchange、Finished(S)を受信したとき」である。
遷移C12の中で、共有鍵生成部114は、ServerKeyExchangeからサーバ生成鍵材料RS0を取り出し、サーバ生成鍵材料RS0と、乱数r C0 と、識別子IDCに対応するプライベート鍵SCと、公開パラメータeとを用いて共有鍵ZCを生成する。そして、共有鍵生成部114は、TLS仕様に従い、共有鍵ZCをプリマスター秘密情報としてマスター秘密情報MCを生成する。
検証処理部115は、マスター秘密情報MCを用いてクライアント生成検証子(検証子verify_data)を生成する。また、検証処理部115は、Finished(S)から取り出したサーバ生成検証子とクライアント生成検証子とが一致するかを検証する。サーバ生成検証子とクライアント生成検証子とが一致しなかった場合、ハンドシェークは失敗となる。
サーバ生成検証子とクライアント生成検証子とが一致した場合、通信部113は、クライアント生成検証子をFinished(C)に含め、Finished(C)をサーバ装置200に送信する。
(遷移C32について)
遷移C32の条件は、状態C3にあるクライアント装置100が「Finished(S)を受信したとき」である。
検証処理部115は、Finished(S)から取り出したサーバ生成検証子とクライアント生成検証子とが一致するかを検証する。サーバ生成検証子とクライアント生成検証子とが一致しなかった場合、ハンドシェークは失敗となる。
(状態遷移:サーバ装置200)
次に、図13を参照しながら、本変形例に係るサーバ装置200の状態遷移について説明する。図13は、第2の実施の形態の一変形例に係るサーバ装置の状態遷移を示した図である。
(遷移S01について)
遷移S01の条件は、状態S0にあるサーバ装置200が「ClientHello、ClientKeyExchangeを受信し、ClientHelloのIDS0を許容するとき」である。
遷移S01の中で、通信部212は、ClientHelloから識別子IDCを取り出し、認証処理の相手となるクライアント装置100の識別子として識別子IDCを許容するかを判断する。
例えば、識別子IDCに有効期限が設定されている場合、通信部212は、識別子IDCが有効期限内であれば許容する。また、ハンドシェークの相手として許容可能なクライアント装置100の識別子を列挙したリストをサーバ装置200が保持している場合、通信部212は、識別子IDCがリストにある場合に識別子IDCを許容する。通信部212が識別子IDCを許容しない場合、ハンドシェークは失敗となる。
識別子IDCが許容された場合、鍵材料生成部213は、ClientKeyExchangeからクライアント生成鍵材料RC0を取り出し、乱数rS0を生成する。また、鍵材料生成部213は、公開パラメータH、P、P0と、ClientHelloから取り出した識別子IDCとを用いてクライアント装置100の公開鍵PC(PC=H(IDC)P+P0)を生成する。そして、鍵材料生成部213は、乱数rS0および公開鍵PCを用いてサーバ生成鍵材料RS0(RS0=rS0PC)を生成する。
共有鍵生成部214は、ClientKeyExchangeから取り出したクライアント生成鍵材料RC0と、乱数rS0と、識別子IDS0に対応するプライベート鍵SS0と、公開パラメータeとを用いて共有鍵ZSを生成する。そして、共有鍵生成部214は、TLS仕様に従い、共有鍵ZSをプリマスター秘密情報としてマスター秘密情報MSを生成する。
通信部212は、識別子IDS0をServerHelloに含める。また、通信部212は、サーバ生成鍵材料RS0をServerKeyExchangeに含める。そして、通信部212は、ServerHello{IDS0}、ServerKeyExchange{RS0}をクライアント装置100に送信する。検証処理部215は、マスター秘密情報MSを用いてサーバ生成検証子(検証子verify_data)を生成する。通信部212は、サーバ生成検証子をFinished(S)に含め、Finished(S)をクライアント装置100に送信する。
(遷移S03について)
遷移S03の条件は、状態S0にあるサーバ装置200が「ClientHello、ClientKeyExchangeを受信し、ClientHelloのIDS0を許容しないとき」である。例えば、識別子IDS0の有効期限が切れている場合などに識別子IDS0が許容されない。
遷移S03の中で、通信部212は、ClientHelloから識別子IDCを取り出し、認証処理の相手となるクライアント装置100の識別子として識別子IDCを許容するかを判断する。
例えば、識別子IDCに有効期限が設定されている場合、通信部212は、識別子IDCが有効期限内であれば許容する。また、ハンドシェークの相手として許容可能なクライアント装置100の識別子を列挙したリストをサーバ装置200が保持している場合、通信部212は、識別子IDCがリストにある場合に識別子IDCを許容する。通信部212が識別子IDCを許容しない場合、ハンドシェークは失敗となる。
識別子IDCを許容しない場合、通信部212は、認証に用いる識別子として許容可能な代替の識別子IDS1を決定する。鍵材料生成部213は、ClientKeyExchangeからクライアント生成鍵材料RC1を取り出し、乱数rS1を生成する。また、鍵材料生成部213は、公開パラメータH、P、P0と、ClientHelloから取り出した識別子IDCとを用いてクライアント装置100の公開鍵PC(PC=H(IDC)P+P0)を生成する。そして、鍵材料生成部213は、乱数rS1および公開鍵PCを用いてサーバ生成鍵材料RS1(RS1=rS1PC)を生成する。
通信部212は、エラーの発生を示す情報errorと、識別子IDS1とをServerHelloに含め、ServerHello{error,IDS1}をクライアント装置100に送信する。また、通信部212は、サーバ生成鍵材料RS1をServerKeyExchangeに含め、ServerKeyExchange{RS1}をクライアント装置100に送信する。
(遷移S32について)
遷移S32の条件は、状態S3にあるサーバ装置200が「ClientKeyExchangeを受信したとき」である。
遷移S32の中で、鍵材料生成部213は、ClientKeyExchangeからクライアント生成鍵材料RC1を取り出し、乱数rS1を生成する。また、鍵材料生成部213は、公開パラメータH、P、P0と、ClientHelloから取り出した識別子IDCとを用いてクライアント装置100の公開鍵PC(PC=H(IDC)P+P0)を生成する。そして、鍵材料生成部213は、乱数rS1および公開鍵PCを用いてサーバ生成鍵材料RS1(RS1=rS1PC)を生成する。
共有鍵生成部214は、ClientKeyExchangeから取り出したクライアント生成鍵材料RC1と、乱数rS1と、識別子IDS1に対応するプライベート鍵SS1と、公開パラメータeとを用いて共有鍵ZSを生成する。そして、共有鍵生成部214は、TLS仕様に従い、共有鍵ZSをプリマスター秘密情報としてマスター秘密情報MSを生成する。
検証処理部215は、マスター秘密情報MSを用いてサーバ生成検証子(検証子verify_data)を生成する。また、検証処理部215は、Finished(C)から取り出したクライアント生成検証子と、サーバ生成検証子とが一致するかを検証する。サーバ生成検証子とクライアント生成検証子とが一致しなかった場合、ハンドシェークは失敗となる。サーバ生成検証子とクライアント生成検証子とが一致した場合、通信部212は、サーバ生成検証子をFinished(S)に含め、Finished(S)をクライアント装置100に送信する。
(遷移S12について)
遷移S12の条件は、状態S1にあるサーバ装置200が「Finished(C)を受信したとき」である。
検証処理部215は、Finished(C)から取り出したクライアント生成検証子と、サーバ生成検証子とが一致するかを検証する。サーバ生成検証子とクライアント生成検証子とが一致しなかった場合、ハンドシェークは失敗となる。
以上、第2の実施の形態について説明した。
10,20 認証装置
11,21 通信部
12,22 制御部
13,23 識別情報
14,24 公開鍵
15,25 秘密鍵
16,26 共有鍵候補
17,27 乱数
18,28 暗号データ
19,29 検証データ

Claims (6)

  1. 第1の情報処理装置と第2の情報処理装置との間の相互認証方法であって、
    前記第1の情報処理装置により、前記第2の情報処理装置を示す第2の識別情報に応じた第2の公開鍵を用いて、第1の乱数を暗号化することで第1の暗号データを生成し、
    前記第1の情報処理装置から前記第2の情報処理装置に、前記第1の情報処理装置を示す第1の識別情報と前記第2の識別情報とを含む第1のメッセージを送信し、前記第1の暗号データを含む第2のメッセージを送信し、
    前記第2の情報処理装置により、認証処理に用いる識別情報として、前記第1のメッセージに含まれる前記第2の識別情報を使用することを許可するか拒否するか判定し、
    前記第2の識別情報の使用が許可される場合、
    前記第2の情報処理装置により、前記第1の識別情報に応じた第1の公開鍵を用いて、第2の乱数を暗号化することで第2の暗号データを生成し、また、前記第2の乱数と前記第1の暗号データと前記第2の公開鍵に対応する第2の秘密鍵とから第2の共有鍵候補を生成し、前記第2の共有鍵候補を用いて第2の検証データを生成し、
    前記第2の情報処理装置から前記第1の情報処理装置に、前記第2の暗号データを含む第3のメッセージを送信し、前記第2の検証データを含む第4のメッセージを送信し、
    前記第1の情報処理装置により、前記第1の乱数と前記第2の暗号データと前記第1の公開鍵に対応する第1の秘密鍵とから第1の共有鍵候補を生成し、前記第1の共有鍵候補を用いて第1の検証データを生成し、
    前記第1の情報処理装置により、前記第2の情報処理装置から受信された前記第2の検証データと前記第1の検証データとが一致するか検証し、
    前記第1の情報処理装置から前記第2の情報処理装置に、前記第1の検証データを含む第5のメッセージを送信し、
    前記第2の情報処理装置により、前記第1の情報処理装置から受信された前記第1の検証データと前記第2の検証データとが一致するか検証
    前記第2の識別情報の使用が拒否される場合、
    前記第1の情報処理装置により、前記第2の情報処理装置を示す他の第2の識別情報に応じた他の第2の公開鍵を用いて、前記第1の乱数または他の第1の乱数を暗号化することで他の第1の暗号データを生成し、
    前記第1の情報処理装置から前記第2の情報処理装置に、前記他の第1の暗号データを含む第6のメッセージを送信し、
    前記第2の共有鍵候補は、前記第1の暗号データに代えて前記他の第1の暗号データを用いて生成される、
    相互認証方法。
  2. 前記第2の識別情報の使用が拒否される場合、前記第2の情報処理装置は、前記他の第1の暗号データを受信する前に前記第2の暗号データを含む前記第3のメッセージを送信し、前記他の第1の暗号データを受信した後に前記第2の検証データを含む前記第4のメッセージを送信する、
    請求項記載の相互認証方法。
  3. 認証装置であって、
    他の認証装置を示す第1の識別情報と前記認証装置を示す第2の識別情報とを含む第1のメッセージを前記他の認証装置から受信し、第1の暗号データを含む第2のメッセージを前記他の認証装置から受信し、前記第1の暗号データを受信した後に第2の暗号データを含む第3のメッセージを前記他の認証装置に送信し、第2の検証データを含む第4のメッセージを前記他の認証装置に送信し、前記第2の検証データを送信した後に第1の検証データを含む第5のメッセージを前記他の認証装置から受信する通信部と、
    認証処理に用いる識別情報として、前記第1のメッセージに含まれる前記第2の識別情報を使用することを許可するか拒否するか判定し、前記第2の識別情報の使用を許可する場合、前記第1の識別情報に応じた公開鍵を用いて乱数を暗号化することで前記第2の暗号データを生成し、前記乱数と前記第1の暗号データと前記第2の識別情報に応じた秘密鍵とから共有鍵候補を生成し、前記共有鍵候補を用いて前記第2の検証データを生成し、前記他の認証装置から受信された前記第1の検証データと前記第2の検証データとが一致するか検証する制御部と、
    を有し、
    前記第2の識別情報の使用を拒否する場合、前記通信部が、他の第1の暗号データを含む第6のメッセージを前記他の認証装置から受信し、前記制御部が、前記第1の暗号データに代えて前記他の第1の暗号データを用いて前記共有鍵候補を生成する認証装置。
  4. 認証装置であって、
    前記認証装置を示す第1の識別情報と他の認証装置を示す第2の識別情報とを含む第1のメッセージを前記他の認証装置に送信し、第1の暗号データを含む第2のメッセージを前記他の認証装置に送信し、前記第1の暗号データを送信した後に第2の暗号データを含む第3のメッセージを前記他の認証装置から受信し、第2の検証データを含む第4のメッセージを前記他の認証装置から受信し、前記第2の検証データを受信した後に第1の検証データを含む第5のメッセージを前記他の認証装置に送信する通信部と、
    前記第2の識別情報に応じた公開鍵を用いて乱数を暗号化することで前記第1の暗号データを生成し、前記他の認証装置により、認証処理に用いる識別情報として前記第1のメッセージに含まれる前記第2の識別情報を使用することが許可された場合、前記乱数と前記第2の暗号データと前記第1の識別情報に応じた秘密鍵とから共有鍵候補を生成し、前記共有鍵候補を用いて前記第1の検証データを生成し、前記他の認証装置から受信された前記第2の検証データと前記第1の検証データとが一致するか検証する制御部と、
    を有し、
    前記他の認証装置により、前記第2の識別情報を使用することが拒否された場合、前記制御部が、前記他の認証装置を示す他の第2の識別情報に応じた他の公開鍵を用いて、前記乱数または他の乱数を暗号化することで他の第1の暗号データを生成し、前記通信部が、前記他の第1の暗号データを含む第6のメッセージを前記他の認証装置に送信する認証装置。
  5. コンピュータに、
    のコンピュータを示す第1の識別情報と前記コンピュータを示す第2の識別情報とを含む第1のメッセージを前記他のコンピュータから受信し、第1の暗号データを含む第2のメッセージを前記他のコンピュータから受信し、
    認証処理に用いる識別情報として、前記第1のメッセージに含まれる前記第2の識別情報を使用することを許可するか拒否するか判定し、
    記第2の識別情報の使用を許可する場合、
    前記第1の識別情報に応じた公開鍵を用いて、乱数を暗号化することで第2の暗号データを生成し、
    前記乱数と前記第1の暗号データと前記第2の識別情報に応じた秘密鍵とから共有鍵候補を生成し、前記共有鍵候補を用いて第2の検証データを生成し、
    前記第2の暗号データを含む第3のメッセージを前記他のコンピュータに送信し、前記第2の検証データを含む第4のメッセージを前記他のコンピュータに送信し、
    前記第2の検証データを送信した後に第1の検証データを含む第5のメッセージを前記他のコンピュータから受信し
    前記他のコンピュータから受信された前記第1の検証データと前記第2の検証データとが一致するか検証し、
    前記第2の識別情報の使用を拒否する場合、
    他の第1の暗号データを含む第6のメッセージを前記他のコンピュータから受信し、
    前記第1の暗号データに代えて前記他の第1の暗号データを用いて前記共有鍵候補を生成する、
    処理を実行させる認証プログラム。
  6. コンピュータに、
    他のコンピュータを示す第2の識別情報に応じた公開鍵を用いて、乱数を暗号化することで第1の暗号データを生成し、
    前記コンピュータを示す第1の識別情報と前記第2の識別情報とを含む第1のメッセージを前記他のコンピュータに送信し、前記第1の暗号データを含む第2のメッセージを前記他のコンピュータに送信し、
    前記他のコンピュータにより、認証処理に用いる識別情報として前記第1のメッセージに含まれる前記第2の識別情報を使用することが許可された場合、
    前記第1の暗号データを送信した後に第2の暗号データを含む第3のメッセージを前記他のコンピュータから受信し、第2の検証データを含む第4のメッセージを前記他のコンピュータから受信し
    前記乱数と前記第2の暗号データと前記第1の識別情報に応じた秘密鍵とから共有鍵候補を生成し、前記共有鍵候補を用いて第1の検証データを生成し、
    記他のコンピュータから受信された前記第2の検証データと前記第1の検証データとが一致するか検証し、
    記第2の検証データを受信した後に記第1の検証データを含む第5のメッセージ前記他のコンピュータに送信し、
    前記他のコンピュータにより、前記第2の識別情報を使用することが拒否された場合、
    前記他のコンピュータを示す他の第2の識別情報に応じた他の公開鍵を用いて、前記乱数または他の乱数を暗号化することで他の第1の暗号データを生成し、
    前記他の第1の暗号データを含む第6のメッセージを前記他のコンピュータに送信する、
    処理を実行させる認証プログラム。
JP2016005919A 2016-01-15 2016-01-15 相互認証方法、認証装置および認証プログラム Active JP6613909B2 (ja)

Priority Applications (4)

Application Number Priority Date Filing Date Title
JP2016005919A JP6613909B2 (ja) 2016-01-15 2016-01-15 相互認証方法、認証装置および認証プログラム
EP16204705.4A EP3193486B1 (en) 2016-01-15 2016-12-16 Mutual authentication method, authentication apparatus, and authentication program
US15/405,830 US10419430B2 (en) 2016-01-15 2017-01-13 Mutual authentication method and authentication apparatus
CN201710026296.8A CN107040373B (zh) 2016-01-15 2017-01-13 相互认证方法及认证设备

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
JP2016005919A JP6613909B2 (ja) 2016-01-15 2016-01-15 相互認証方法、認証装置および認証プログラム

Publications (2)

Publication Number Publication Date
JP2017126943A JP2017126943A (ja) 2017-07-20
JP6613909B2 true JP6613909B2 (ja) 2019-12-04

Family

ID=57570401

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2016005919A Active JP6613909B2 (ja) 2016-01-15 2016-01-15 相互認証方法、認証装置および認証プログラム

Country Status (4)

Country Link
US (1) US10419430B2 (ja)
EP (1) EP3193486B1 (ja)
JP (1) JP6613909B2 (ja)
CN (1) CN107040373B (ja)

Families Citing this family (33)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP6613909B2 (ja) * 2016-01-15 2019-12-04 富士通株式会社 相互認証方法、認証装置および認証プログラム
RU2018137847A (ru) * 2016-03-29 2020-04-29 Конинклейке Филипс Н.В. Система и способ для распространения основанного на идентификационной информации ключевого материала и сертификата
CN109391594B (zh) * 2017-08-09 2021-07-30 中国电信股份有限公司 安全认证系统和方法
US10541804B2 (en) * 2017-08-18 2020-01-21 Intel Corporation Techniques for key provisioning in a trusted execution environment
CN107395654A (zh) * 2017-09-14 2017-11-24 浪潮软件股份有限公司 一种安全认证方法、客户端、服务端及系统
CN107682150B (zh) * 2017-10-27 2020-03-10 武汉大学 一种适用于计算资源非对称领域的共享密钥建立方法
CN107911223B (zh) * 2017-11-23 2021-03-09 上海众人网络安全技术有限公司 一种交叉签名的方法及装置
CN107819576A (zh) * 2017-11-28 2018-03-20 苏州朗捷通智能科技有限公司 通信认证方法和系统
CN107733645B (zh) * 2017-11-28 2021-03-19 苏州朗捷通智能科技有限公司 加密通信认证方法和系统
CN108171831B (zh) * 2017-12-22 2020-08-21 武汉瑞纳捷电子技术有限公司 一种基于nfc手机和智能锁的双向安全认证方法
CN108599925B (zh) * 2018-03-20 2022-03-08 如般量子科技有限公司 一种基于量子通信网络的改进型aka身份认证系统和方法
JP6634171B2 (ja) * 2018-05-11 2020-01-22 株式会社bitFlyer Blockchain 公開鍵の信頼性を証明するための装置、方法及びそのためのプログラム
EP3817277A4 (en) * 2018-05-11 2022-01-12 bitFlyer Blockchain, Inc. DEVICE AND METHOD FOR CERTIFICATION OF THE RELIABILITY OF A PUBLIC KEY AND PROGRAM THEREFOR
CN114499925A (zh) * 2018-08-06 2022-05-13 华为技术有限公司 一种签约信息配置方法及通信设备
CN110839240B (zh) * 2018-08-17 2022-07-05 阿里巴巴集团控股有限公司 一种建立连接的方法及装置
CN109471610B (zh) * 2018-10-25 2021-03-19 北京链化未来科技有限公司 一种串行随机数生成方法、装置和存储介质
CN109245886A (zh) * 2018-11-02 2019-01-18 美的集团股份有限公司 密钥协商方法、设备、存储介质以及系统
CN109005028A (zh) * 2018-11-02 2018-12-14 美的集团股份有限公司 密钥协商方法、云服务器、设备、存储介质以及系统
CN109831303B (zh) * 2018-12-24 2021-09-14 华升智建科技(深圳)有限公司 一种可用低端8位单片机实现的高强度随机加密方法
US11616774B2 (en) * 2019-01-17 2023-03-28 Blackberry Limited Methods and systems for detecting unauthorized access by sending a request to one or more peer contacts
CN109981264B (zh) * 2019-03-11 2020-08-04 北京纬百科技有限公司 一种应用密钥生成方法及密码机设备组件
US11128454B2 (en) 2019-05-30 2021-09-21 Bong Mann Kim Quantum safe cryptography and advanced encryption and key exchange (AEKE) method for symmetric key encryption/exchange
CN110427762B (zh) * 2019-07-23 2021-03-23 湖南匡安网络技术有限公司 一种实现电力监控系统视频安全传输的加密和解密方法
WO2021064978A1 (ja) * 2019-10-04 2021-04-08 日本電信電話株式会社 端末、サーバ、方法及びプログラム
US11615196B2 (en) * 2020-04-02 2023-03-28 Cyberus Labs sp. z o.o. Lightweight encryption
CN111756535A (zh) * 2020-06-30 2020-10-09 北京海泰方圆科技股份有限公司 通信密钥的协商方法、装置、存储介质及电子设备
KR20220038922A (ko) * 2020-09-21 2022-03-29 주식회사 엘지에너지솔루션 상호 인증 방법 및 그 방법을 제공하는 인증장치
CN112233759A (zh) * 2020-10-15 2021-01-15 刘明 冠心病管理云平台系统及智能药盒
CN115250180A (zh) * 2021-04-28 2022-10-28 Oppo广东移动通信有限公司 数据的加密、解密方法及装置
US12095744B2 (en) * 2021-10-01 2024-09-17 TrustFour Technologies, Inc. Mutual key management service system and method
CN115276972A (zh) * 2022-07-20 2022-11-01 蔚来汽车科技(安徽)有限公司 数据传输方法、存储介质及车辆
US11997105B2 (en) * 2022-08-03 2024-05-28 1080 Network, Inc. Network-level user validation for network-based exchanges that leverages universally unique ephemeral key to eliminate use of persistent credentials
CN115001717B (zh) * 2022-08-03 2022-10-25 中国电力科学研究院有限公司 一种基于标识公钥的终端设备认证方法及系统

Family Cites Families (11)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP3278612B2 (ja) * 1998-05-22 2002-04-30 日本電気株式会社 ユーザ相互認証装置、クライアント装置およびサーバ装置
US8588415B2 (en) * 2004-11-25 2013-11-19 France Telecom Method for securing a telecommunications terminal which is connected to a terminal user identification module
CN101433014A (zh) * 2006-04-28 2009-05-13 松下电器产业株式会社 通信装置及通信系统
JP5027742B2 (ja) 2008-06-19 2012-09-19 日本電信電話株式会社 秘密情報送信システム、秘密情報送信方法、秘密情報管理サーバ、暗号装置、秘密情報送信プログラム
EP2228942B1 (en) * 2009-03-13 2012-06-06 Sap Ag Securing communications sent by a first user to a second user
US8850203B2 (en) * 2009-08-28 2014-09-30 Alcatel Lucent Secure key management in multimedia communication system
KR20120072032A (ko) * 2010-12-23 2012-07-03 한국전자통신연구원 모바일 단말의 상호인증 시스템 및 상호인증 방법
JP5762991B2 (ja) * 2012-02-03 2015-08-12 株式会社東芝 通信装置、サーバ装置、中継装置、およびプログラム
JP6187251B2 (ja) 2013-12-27 2017-08-30 富士通株式会社 データ通信方法、およびデータ通信装置
EP3110066B1 (en) * 2014-02-18 2018-06-27 Panasonic Intellectual Property Corporation of America Authentication method and authentication system
JP6613909B2 (ja) * 2016-01-15 2019-12-04 富士通株式会社 相互認証方法、認証装置および認証プログラム

Also Published As

Publication number Publication date
CN107040373A (zh) 2017-08-11
JP2017126943A (ja) 2017-07-20
EP3193486A1 (en) 2017-07-19
US10419430B2 (en) 2019-09-17
CN107040373B (zh) 2020-04-28
EP3193486B1 (en) 2020-06-17
US20170208062A1 (en) 2017-07-20

Similar Documents

Publication Publication Date Title
JP6613909B2 (ja) 相互認証方法、認証装置および認証プログラム
US11722316B2 (en) Cryptographic communication system and cryptographic communication method based on blockchain
EP2491672B1 (en) Low-latency peer session establishment
WO2017045552A1 (zh) 一种在ssl或tls通信中加载数字证书的方法和装置
CN108377190B (zh) 一种认证设备及其工作方法
US10516543B2 (en) Communication protocol using implicit certificates
US12047516B2 (en) Combined digital signature algorithms for security against quantum computers
JP2020523806A (ja) モノのインターネット(iot)デバイスの管理
CN104639534A (zh) 网站安全信息的加载方法和浏览器装置
CN104580189A (zh) 一种安全通信系统
CN111010277B (zh) 密钥交换方法、装置和存储介质、计算装置
CN104160656A (zh) 用于将客户端设备与网络相连的系统和方法
CN104580190A (zh) 安全浏览器的实现方法和安全浏览器装置
US11367065B1 (en) Distributed ledger system for electronic transactions
EP3282639B1 (en) Method for operating server and client, server, and client apparatus
US20210306135A1 (en) Electronic device within blockchain based pki domain, electronic device within certification authority based pki domain, and cryptographic communication system including these electronic devices
WO2015135398A1 (zh) 一种基于协商密钥的数据处理方法
TW202232913A (zh) 共享金鑰產生技術
US20240187221A1 (en) Agile cryptographic deployment service
WO2021064978A1 (ja) 端末、サーバ、方法及びプログラム
WO2024216792A1 (zh) 网络通信方法、装置、计算机设备和存储介质
WO2022135377A1 (zh) 身份鉴别方法、装置、设备、芯片、存储介质及程序
Smyth TLS 1.3 for engineers: An exploration of the TLS 1.3 specification and OpenJDK's Java implementation
Yanyan Design of a PKI-Based Secure Architecture for Mobile E-Commerce
CN116545630A (zh) 一种数字签名的生成和验证方法、装置、设备、存储介质

Legal Events

Date Code Title Description
A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20180912

A977 Report on retrieval

Free format text: JAPANESE INTERMEDIATE CODE: A971007

Effective date: 20190618

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20190723

A521 Written amendment

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20190913

RD02 Notification of acceptance of power of attorney

Free format text: JAPANESE INTERMEDIATE CODE: A7422

Effective date: 20190913

RD04 Notification of resignation of power of attorney

Free format text: JAPANESE INTERMEDIATE CODE: A7424

Effective date: 20190913

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

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20191021

R150 Certificate of patent or registration of utility model

Ref document number: 6613909

Country of ref document: JP

Free format text: JAPANESE INTERMEDIATE CODE: R150