JP7231051B2 - 端末、サーバ、方法及びプログラム - Google Patents

端末、サーバ、方法及びプログラム Download PDF

Info

Publication number
JP7231051B2
JP7231051B2 JP2021550916A JP2021550916A JP7231051B2 JP 7231051 B2 JP7231051 B2 JP 7231051B2 JP 2021550916 A JP2021550916 A JP 2021550916A JP 2021550916 A JP2021550916 A JP 2021550916A JP 7231051 B2 JP7231051 B2 JP 7231051B2
Authority
JP
Japan
Prior art keywords
short
server
key
terminal
identifier
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
JP2021550916A
Other languages
English (en)
Other versions
JPWO2021064978A1 (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.)
Nippon Telegraph and Telephone Corp
Original Assignee
Nippon Telegraph and Telephone Corp
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 Nippon Telegraph and Telephone Corp filed Critical Nippon Telegraph and Telephone Corp
Publication of JPWO2021064978A1 publication Critical patent/JPWO2021064978A1/ja
Application granted granted Critical
Publication of JP7231051B2 publication Critical patent/JP7231051B2/ja
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/16—Implementing security features at a particular protocol layer
    • H04L63/166—Implementing security features at a particular protocol layer at the transport layer
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
    • H04L9/0816—Key establishment, i.e. cryptographic processes or cryptographic protocols whereby a shared secret becomes available to two or more parties, for subsequent use
    • H04L9/0819—Key transport or distribution, i.e. key establishment techniques where one party creates or otherwise obtains a secret value, and securely transfers it to the other(s)
    • H04L9/0825—Key transport or distribution, i.e. key establishment techniques where one party creates or otherwise obtains a secret value, and securely transfers it to the other(s) using asymmetric-key encryption or public key infrastructure [PKI], e.g. key signature or public key certificates
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • 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
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
    • H04L9/0894—Escrow, recovery or storing of secret information, e.g. secret key escrow or cryptographic key storage
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/14—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols using a plurality of keys or algorithms
    • H04L9/16—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols using a plurality of keys or algorithms the keys or algorithms being changed during operation
    • 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
    • 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/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
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/40—Network security protocols

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Signal Processing (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Computing Systems (AREA)
  • Theoretical Computer Science (AREA)
  • Computer Hardware Design (AREA)
  • General Engineering & Computer Science (AREA)
  • Mathematical Physics (AREA)
  • Pure & Applied Mathematics (AREA)
  • Physics & Mathematics (AREA)
  • Mathematical Optimization (AREA)
  • Mathematical Analysis (AREA)
  • General Physics & Mathematics (AREA)
  • Algebra (AREA)
  • Mobile Radio Communication Systems (AREA)
  • Computer And Data Communications (AREA)

Description

本発明は、端末、サーバ、方法及びプログラムに関する。
ＩｏＴ（Internet of Things）機器が普及するにつれて、互いに通信を行う機器同士が互いに正当な機器であることを保証する認証技術が重要になってきている。このような認証技術の１つとして、ＴＬＳ（Transport Layer Security）１．２が従来から知られている。また、ＴＬＳ１．２の後継として、ＴＬＳ１．３も知られており、ＨＴＴＰ（Hypertext Transfer Protocol）やＭＱＴＴ（Message Queuing Telemetry Transport）等による通信をセキュアに行うために利用されている。
ところで、ＩｏＴ機器は一般的なＰＣ（Personal Computer）等と比較してハードウェア資源が限られているため、ＩｏＴ機器での通信に対してＴＬＳを適用した場合、証明書利用のための処理性能と通信量が課題となる。この課題に対して、ＩＤベース暗号を用いた相互認証付き鍵交換をＴＬＳ１．２に適用したＴＬＳが提案されている（例えば、非特許文献１）。非特許文献１で提案されているＴＬＳでは、ＴＬＳ１．２の仕様を変更せずに、ＴＬＳ１．２の仕様の中でＩＤベース暗号を用いた認証と鍵交換を実現している。また、ＩＤベース暗号を用いることで、証明書利用のための通信が不要となっている。
酒見由美, 武仲正彦, 金岡晃, "IDベース暗号によるIoT向け相互認証方式の提案", SCIS2015
しかしながら、ＴＬＳ１．３はＴＬＳ１．２とは仕様が異なるため、ＴＬＳ１．３では、上記の非特許文献１で提案されているＴＬＳと同様にＩＤベース暗号を提供することができない。これは、ＴＬＳ１．３の仕様では、ハンドシェイクの中のＣｌｉｅｎｔＨｅｌｌｏとＳｅｒｖｅｒＨｅｌｌｏとが行われた後にそれ以降のメッセージが暗号化されるため、１ラウンドで暗号化のための鍵交換を行う必要があるためである。
本発明の実施形態は、上記の点に鑑みてなされたもので、ＩＤベース暗号を用いた相互認証付き鍵交換を適用したＴＬＳ１．３を実現することを目的とする。
上記目的を達成するため、本実施形態に係る端末は、通信ネットワークを介して接続されるサーバとの間でＴＬＳ１．３による認証を行う端末であって、ＩＤベース暗号を用いた相互認証付き鍵交換によって前記ＴＬＳ１．３のハンドシェイク中のメッセージを暗号化するための共有鍵の生成に必要な第１の識別子と第１の短期公開鍵とが含まれるＣｌｉｅｎｔＨｅｌｌｏメッセージを前記サーバに送信する送信手段と、前記共有鍵の生成に必要な第２の識別子と第２の短期公開鍵とが含まれるＳｅｒｖｅｒＨｅｌｌｏメッセージを前記サーバから受信する受信手段と、前記第１の識別子と前記第１の短期公開鍵と前記第２の識別子と前記第２の短期公開鍵とを用いて、前記共有鍵を生成する生成手段と、を有することを特徴とする。
ＩＤベース暗号を用いた相互認証付き鍵交換を適用したＴＬＳ１．３を実現することができる。
本実施形態に係る認証システムの全体構成の一例を示す図である。 本実施形態に係る端末のハードウェア構成の一例を示す図である。 本実施形態に係るサーバのハードウェア構成の一例を示す図である。 本実施形態に係る端末及びサーバの機能構成の一例を示す図である。 実施例１における認証処理の一例を示すシーケンス図である。 実施例２における認証処理の一例を示すシーケンス図である。 実施例３における認証処理の一例を示すシーケンス図である。
以下、本発明の実施形態について説明する。本実施形態では、ＩＤベース暗号を用いた相互認証付き鍵交換を適用したＴＬＳ１．３を実現する認証システム１について説明する。
上述したように、ＴＬＳ１．３はＴＬＳ１．２とは仕様が異なる。具体的には、以下の参考文献１に記載されているように、ＴＬＳ１．２ではハンドシェイクが暗号化されるまでに２ラウンドの通信が行われるのに対して、ＴＬＳ１．３ではハンドシェイクが暗号化されるまでに１ラウンドの通信（すなわち、ＣｌｉｅｎｔＨｅｌｌｏ及びＳｅｒｖｅｒＨｅｌｌｏ）しか行われない。
［参考文献１］
"SSL/TLS暗号設定ガイドライン～安全なウェブサイトのために（暗号設定対策編）～", インターネット＜ＵＲＬ：https://www.ipa.go.jp/security/ipg/documents/ipa-cryptrec-gl-3001-2.0.pdf＞
このため、ＩＤベース暗号を用いた相互認証付き鍵交換をＴＬＳ１．３に適用するためには、１ラウンドで鍵交換に必要な情報を交換する必要がある。例えば、ＭＢ方式と呼ばれるＩＤベース暗号を用いた相互認証付き鍵交換プロトコルでは、鍵交換に必要な情報を交換するために１．５ラウンドを要する。これは、ＭＢ方式では短期公開鍵を生成するために通信相手の識別子（ＩＤ）を必要とするためである。なお、ＭＢ方式については以下の参考文献２を参照されたい。
［参考文献２］
N. McCullagh and P. S. L. M. Barreto, "A New Two-Party Identity-Based Authenticated Key Agreement", CT-RSA 2005, LNCS 3376, pp. 262-274, Springer-Verlag, 2005.
したがって、ＩＤベース暗号を用いた相互認証付き鍵交換を適用したＴＬＳ１．３を実現するためには、１ラウンドで鍵交換に必要な情報を交換可能なＩＤベース暗号を用いた相互認証付き鍵交換プロトコルをＴＬＳ１．３に適用する必要がある。
そこで、本実施形態に係る認証システム１では、１ラウンドで鍵交換に必要な情報を交換可能なＩＤベース暗号を用いた相互認証付き鍵交換プロトコルをＴＬＳ１．３に適用する。これにより、ＴＬＳ１．３の仕様の中でＩＤベース暗号を用いた認証と鍵交換を行って、この鍵交換で得られた鍵を用いて、ＣｌｉｅｎｔＨｅｌｌｏ及びＳｅｒｖｅｒＨｅｌｌｏよりも後のメッセージを暗号化することが可能となる。
なお、上記のＭＢ方式であっても、例えば、通信相手の識別子（ＩＤ）が事前に得られている場合等には１ラウンドで鍵交換に必要な情報を交換することが可能であるが、本実施形態では、通信相手の識別子は事前に（つまり、通信を開始する前に）得ることはできないものとする。これは、実際には通信相手の識別子を事前に得ることができない場合が多く、また、仮に得られたとしても、通信相手が常に同じ識別子を使用するとは限らないためである。
＜全体構成＞
まず、本実施形態に係る認証システム１の全体構成について、図１を参照しながら説明する。図１は、本実施形態に係る認証システム１の全体構成の一例を示す図である。
図１に示すように、本実施形態に係る認証システム１には、１以上の端末１０と、サーバ２０とが含まれる。また、各端末１０とサーバ２０とは、例えばインターネット等の通信ネットワークＮを介して通信可能に接続されている。
端末１０は、例えば、各種センサデバイス、組み込み機器、ウェアラブルデバイス、デジタル家電、監視カメラ、照明機器、医療機器、産業用機器等の種々のＩｏＴ機器である。すなわち、端末１０は、一般的なＰＣ等と比較してハードウェア資源（例えば、プロセッサの処理性能やメモリ容量、通信性能等）が限られているＩｏＴ機器であるものとする。ただし、これに限られず、端末１０がＩｏＴ機器以外（例えば、ＰＣ、スマートフォン、タブレット端末等）であっても、本実施形態を同様に適用することが可能である。
サーバ２０は、例えば、端末１０との間でデータ通信を行うコンピュータ又はコンピュータシステムである。サーバ２０としては、例えば、端末１０がセンサデバイスである場合に、端末１０からセンシングデータを収集するコンピュータ等が挙げられる。
本実施形態に係る認証システム１では、端末１０とサーバ２０との間でＴＬＳ１．３による認証及び暗号化通信を行う際に、ＩＤベース暗号を用いた相互認証付き鍵交換プロトコルによって暗号化のための鍵交換を行う場合について説明する。ただし、本実施形態は、異なる端末１０間でＴＬＳ１．３による認証及び暗号化通信を行う際についても同様に適用することが可能である。
なお、図１に示す認証システム１の構成は一例であって、他の構成であってもよい。例えば、鍵生成局（ＫＧＣ：Key Generation Center）として機能する装置又はシステムが認証システム１に含まれていてもよい。
＜ハードウェア構成＞
次に、本実施形態に係る端末１０及びサーバ２０のハードウェア構成について説明する。
≪端末１０≫
以降では、本実施形態に係る端末１０のハードウェア構成について、図２を参照しながら説明する。図２は、本実施形態に係る端末１０のハードウェア構成の一例を示す図である。
図２に示すように、本実施形態に係る端末１０は、通信Ｉ／Ｆ１１と、プロセッサ１２と、メモリ装置１３とを有する。これら各ハードウェアは、それぞれバス１４を介して通信可能に接続されている。
通信Ｉ／Ｆ１１は、端末１０を通信ネットワークＮに接続するためのインタフェースである。端末１０は、通信Ｉ／Ｆ１１を介して、サーバ２０や他の端末１０等との間でデータ通信を行うことができる。
プロセッサ１２は、例えばＭＰＵ（Micro Processing Unit）やＣＰＵ（Central Processing Unit）等であり、メモリ装置１３からプログラムやデータを読み出して各種処理を実行する演算装置である。
メモリ装置１３は、例えばＲＡＭ（Random Access Memory）やＲＯＭ（Read Only Memory）、フラッシュメモリ等であり、各種データやプログラム等を記憶する記憶装置である。
本実施形態に係る端末１０は、図２に示すハードウェア構成を有することにより、後述する認証処理を実現することができる。なお、図２に示すハードウェア構成は一例であって、端末１０は、他のハードウェア構成を有していてもよい。例えば、端末１０は、複数のプロセッサ１２を有していてもよいし、複数のメモリ装置１３を有していてもよい。
≪サーバ２０≫
以降では、本実施形態に係るサーバ２０のハードウェア構成について、図３を参照しながら説明する。図３は、本実施形態に係るサーバ２０のハードウェア構成の一例を示す図である。
図３に示すように、本実施形態に係るサーバ２０は、入力装置２１と、表示装置２２と、外部Ｉ／Ｆ２３と、通信Ｉ／Ｆ２４と、プロセッサ２５と、メモリ装置２６とを有する。これら各ハードウェアは、それぞれがバス２７を介して通信可能に接続されている。
入力装置２１は、例えばキーボードやマウス、タッチパネル等であり、サーバ２０に対して各種操作を入力するのに用いられる。表示装置２２は、例えばディスプレイ等であり、サーバ２０の各種処理結果等を表示するのに用いられる。なお、サーバ２０は、入力装置２１及び表示装置２２のうちの少なくとも一方を有していなくてもよい。
外部Ｉ／Ｆ２３は、外部装置とのインタフェースである。外部装置には、記録媒体２３ａ等がある。サーバ２０は、外部Ｉ／Ｆを介して、記録媒体２３ａの読み取りや書き込み等を行うことができる。なお、記録媒体２３ａとしては、例えば、ＣＤ（Compact Disk）、ＤＶＤ（Digital Versatile Disk）、ＳＤメモリカード（Secure Digital memory card）、ＵＳＢ（Universal Serial Bus）メモリカード等が挙げられる。
通信Ｉ／Ｆ２４は、サーバ２０を通信ネットワークＮに接続するためのインタフェースである。サーバ２０は、通信Ｉ／Ｆ２４を介して、端末１０等との間でデータ通信を行うことができる。
プロセッサ２５は、例えばＣＰＵ等であり、メモリ装置２６からプログラムやデータを読み出して各種処理を実行する演算装置である。
メモリ装置２６は、例えばＲＡＭやＲＯＭ、フラッシュメモリ、ＨＤＤ（Hard Disk Drive）、ＳＳＤ（Solid State Drive）等であり、各種データやプログラム等を記憶する記憶装置である。
本実施形態に係るサーバ２０は、図３に示すハードウェア構成を有することにより、後述する認証処理を実現することができる。なお、図３に示すハードウェア構成は一例であって、サーバ２０は、他のハードウェア構成を有していてもよい。例えば、サーバ２０は、複数のプロセッサ２５を有していてもよいし、複数のメモリ装置２６を有していてもよい。
＜機能構成＞
次に、本実施形態に係る端末１０及びサーバ２０の機能構成について、図４を参照しながら説明する。図４は、本実施形態に係る端末１０及びサーバ２０の機能構成の一例を示す図である。
≪端末１０≫
図４に示すように、本実施形態に係る端末１０は、認証処理部１０１と、記憶部１０２とを有する。認証処理部１０１は、端末１０にインストールされた１以上のプログラムがプロセッサ１２に実行させる処理により実現される。また、記憶部１０２は、例えば、メモリ装置１３等を用いて実現可能である。
認証処理部１０１は、サーバ２０との間でＴＬＳ１．３による認証及び暗号化通信を行う。このとき、認証処理部１０１は、ＩＤベース暗号を用いた相互認証付き鍵交換プロトコルによってサーバ２０との間で暗号化のための鍵交換を行う。
記憶部１０２は、各種データを記憶する。記憶部１０２に記憶されているデータとしては、例えば、当該端末１０の識別子やユーザ秘密鍵等がある。また、サーバ２０との間でＴＬＳ１．３による認証及び暗号化通信を行う際の一時的なデータも記憶部１０２に記憶される。
なお、端末１０の識別子としては、任意の識別子を用いることが可能である。例えば、端末１０の識別子として、ユーザＩＤ、氏名、メールアドレス、電話番号、当該端末１０の製造固有番号、ＩＰ（Internet Protocol）アドレス、物理アドレス等を用いることが可能である。
≪サーバ２０≫
図４に示すように、本実施形態に係るサーバ２０は、認証処理部２０１と、記憶部２０２とを有する。認証処理部２０１は、サーバ２０にインストールされた１以上のプログラムがプロセッサ２５に実行させる処理により実現される。また、記憶部２０２は、例えば、メモリ装置２６等を用いて実現可能である。なお、記憶部２０２は、例えば、サーバ２０と通信ネットワークＮを介して接続される記憶装置等を用いて実現されていてもよい。
認証処理部２０１は、端末１０との間でＴＬＳ１．３による認証及び暗号化通信を行う。このとき、認証処理部２０１は、ＩＤベース暗号を用いた相互認証付き鍵交換プロトコルによって端末１０との間で暗号化のための鍵交換を行う。
記憶部２０２は、各種データを記憶する。記憶部２０２に記憶されているデータとしては、例えば、当該サーバ２０の識別子やユーザ秘密鍵等がある。また、端末１０との間でＴＬＳ１．３による認証及び暗号化通信を行う際の一時的なデータも記憶部２０２に記憶される。
なお、サーバ２０の識別子としては、任意の識別子を用いることが可能である。例えば、サーバ２０の識別子として、当該サーバ２０の製造固有番号、ＩＰアドレス、物理アドレス、Wｅｂサイト名、メールアドレス、電話番号等を用いることが可能である。
＜処理の詳細＞
次に、本実施形態に係る認証システム１の処理の詳細について説明する。本実施形態では、ＩＤベース暗号を用いた相互認証付き鍵交換を適用したＴＬＳ１．３による認証処理の実施例１～実施例３について説明する。実施例１～実施例３はいずれもその安全性は同じであるが、計算効率は実施例３が最も良い。なお、実施例１～実施例３で説明する方式以外にも、１ラウンドで鍵交換に必要な情報を交換可能なＩＤベース暗号を用いた相互認証付き鍵交換プロトコルであれば、ＴＬＳ１．３に適用可能である。
≪記号の定義≫
まず、以降の各実施例で共通に使用する記号を次のように定義する。
ＩＤＡ：端末１０の識別子
ＩＤＢ：サーバ２０の識別子
ｋ：セキュリティパラメータ
ｐ，ｑ：ｐ≠ｑを満たす素数
Ｇ１：有限体Ｆｐ上の楕円曲線をＥ１として、楕円曲線Ｅ１上の群Ｅ（Ｆｐ）の部分群
Ｇ２：有限体Ｆｐのｋ次拡大体上の楕円曲線をＥ２として、楕円曲線Ｅ２上の群
Figure 0007231051000001
 の部分群
ｇ１：Ｇ１の生成元
ｇ２：Ｇ２の生成元
ｅ：Ｇ１×Ｇ２上で定義されたペアリング
Ｚｑ：ｑを法とする剰余類
||：文字列の連結
Ｈ：鍵導出関数
Ｋ：共有鍵
≪認証処理（実施例１）≫
以降では、ＩＤベース暗号を用いた相互認証付き鍵交換を適用したＴＬＳ１．３による認証処理の実施例１について、図５を参照しながら説明する。図５は、実施例１における認証処理の一例を示すシーケンス図である。
実施例１では、鍵生成局のマスター秘密鍵をｚ∈Ｚｑ、マスター公開鍵をＺ１＝ｚｇ１及びＺ２＝ｚｇ２とする。また、端末１０のユーザ秘密鍵をＤＡ，１＝ｚＱＡ，１＝ｚＨ１（ＩＤＡ）∈Ｇ１、サーバ２０のユーザ秘密鍵をＤＢ，２＝ｚＱＢ，２＝ｚＨ２（ＩＤＢ）∈Ｇ２とする。ここで、Ｈ１は文字列からＧ１上の元を生成する関数であり、Ｈ２は文字列からＧ２上の元を生成する関数である。Ｈ１及びＨ２は公開情報である。なお、ユーザ秘密鍵ＤＡ，１及びＤＢ，２は鍵生成局で生成され、それぞれ任意の方法で端末１０及びサーバ２０に配布される。
端末１０の認証処理部１０１は、短期秘密鍵ｘＡ∈Ｚｑをランダムに選択した上で、短期公開鍵ＸＡ，１＝ｘＡｇ１∈Ｇ１及びＸＡ，２＝ｘＡｇ２∈Ｇ２を生成する（ステップＳ１０１）。なお、短期秘密鍵ｘＡと短期公開鍵ＸＡ，１及びＸＡ，２は、記憶部１０２に保存される。
サーバ２０の認証処理部２０１は、短期秘密鍵ｘＢ∈Ｚｑをランダムに選択した上で、短期公開鍵ＸＢ，１＝ｘＢｇ１∈Ｇ１及びＸＢ，２＝ｘＢｇ２∈Ｇ２を生成する（ステップＳ１０２）。なお、短期秘密鍵ｘＢと短期公開鍵ＸＢ，１及びＸＢ，２は、記憶部２０２に保存される。
次に、端末１０の認証処理部１０１は、ＣｌｉｅｎｔＨｅｌｌｏをサーバ２０に送信する（ステップＳ１０３）。このとき、認証処理部１０１は、当該端末１０の識別子ＩＤＡと短期公開鍵ＸＡ，１及びＸＡ，２とが含まれるＣｌｉｅｎｔＨｅｌｌｏをサーバ２０に送信する。ここで、識別子ＩＤＡと短期公開鍵ＸＡ，１及びＸＡ，２は、例えば、ＣｌｉｅｎｔＨｅｌｌｏの拡張領域（Ｅｘｔｅｎｓｉｏｎフィールド）に格納することができる。
次に、サーバ２０の認証処理部２０１は、ＳｅｒｖｅｒＨｅｌｌｏを端末１０に送信する（ステップＳ１０４）。このとき、認証処理部２０１は、当該サーバ２０の識別子ＩＤＢと短期公開鍵ＸＢ，１及びＸＢ，２とが含まれるＳｅｒｖｅｒＨｅｌｌｏを端末１０に送信する。ここで、識別子ＩＤＢと短期公開鍵ＸＢ，１及びＸＢ，２は、例えば、ＳｅｒｖｅｒＨｅｌｌｏの拡張領域（Ｅｘｔｅｎｓｉｏｎフィールド）に格納することができる。
上記のステップＳ１０３～ステップＳ１０４により鍵交換に必要な情報（つまり、通信相手の識別子と短期公開鍵）が交換される。すなわち、鍵交換に必要な情報が１ラウンドで交換される。
続いて、端末１０の認証処理部１０１は、ＸＢ，１及びＸＢ，２がそれぞれ楕円曲線Ｅ１及びＥ２上の点であること及びｅ（ＸＢ，１，ｇ２）＝ｅ（ｇ１，ＸＢ，２）であることを確認する（ステップＳ１０５）。
なお、上記のステップＳ１０５で「ＸＢ，１が楕円曲線Ｅ１上の点でない」、「ＸＢ，２が楕円曲線Ｅ２上の点でない」及び「ｅ（ＸＢ，１，ｇ２）≠ｅ（ｇ１，ＸＢ，２）」の少なくとも１つを満たす場合、認証処理が失敗したものとして、処理を終了するか又は上記のステップＳ１０１からやり直す。以降では、ＸＢ，１及びＸＢ，２がそれぞれ楕円曲線Ｅ１及びＥ２上の点であり、かつ、ｅ（ＸＢ，１，ｇ２）＝ｅ（ｇ１，ＸＢ，２）であることが確認されたものとする。
同様に、サーバ２０の認証処理部２０１は、ＸＡ，１及びＸＡ，２がそれぞれ楕円曲線Ｅ１及びＥ２上の点であること及びｅ（ＸＡ，１，ｇ２）＝ｅ（ｇ１，ＸＡ，２）であることを確認する（ステップＳ１０６）。
なお、上記のステップＳ１０６で「ＸＡ，１が楕円曲線Ｅ１上の点でない」、「ＸＡ，２が楕円曲線Ｅ２上の点でない」及び「ｅ（ＸＡ，１，ｇ２）≠ｅ（ｇ１，ＸＡ，２）」の少なくとも１つを満たす場合、認証処理が失敗したものとして、処理を終了するか又は上記のステップＳ１０１からやり直す。以降では、ＸＡ，１及びＸＡ，２がそれぞれ楕円曲線Ｅ１及びＥ２上の点であり、かつ、ｅ（ＸＡ，１，ｇ２）＝ｅ（ｇ１，ＸＡ，２）であることが確認されたものとする。
次に、端末１０の認証処理部１０１は、以下により共有値σ１，σ２，σ３，σ４を計算する（ステップＳ１０７）。
σ１＝ｅ（ＤＡ，１，ＱＢ，２）
σ２＝ｅ（ＤＡ，１＋ｘＡＺ１，ＱＢ，２＋ＸＢ，２）
σ３＝ｘＡＸＢ，１
σ４＝ｘＡＸＢ，２
同様に、サーバ２０の認証処理部２０１は、以下により共有値σ１，σ２，σ３，σ４を計算する（ステップＳ１０８）。
σ１＝ｅ（ＱＡ，１，ＤＢ，２）
σ２＝ｅ（ＱＡ，１＋ＸＡ，１，ＤＢ，２＋ｘＢＺ２）
σ３＝ｘＢＸＡ，１
σ４＝ｘＢＸＡ，２
次に、端末１０の認証処理部１０１は、以下によりｓｉｄを計算する（ステップＳ１０９）。なお、ｓｉｄはセッションＩＤを意味する。
ｓｉｄ＝（ＩＤＡ||ＩＤＢ||ＸＡ，１||ＸＡ，２||ＸＢ，１||ＸＢ，２）
同様に、サーバ２０の認証処理部２０１は、以下によりｓｉｄを計算する（ステップＳ１１０）。
ｓｉｄ＝（ＩＤＡ||ＩＤＢ||ＸＡ，１||ＸＡ，２||ＸＢ，１||ＸＢ，２）
そして、端末１０の認証処理部１０１は、以下により共有鍵Ｋを計算する（ステップＳ１１１）。
Ｋ＝Ｈ（σ１||σ２||σ３||σ４||ｓｉｄ）
なお、この共有鍵Ｋは記憶部１０２に保存される。
同様に、サーバ２０の認証処理部２０１は、以下により共有鍵Ｋを計算する（ステップＳ１１２）。
Ｋ＝Ｈ（σ１||σ２||σ３||σ４||ｓｉｄ）
なお、この共有鍵Ｋは記憶部２０２に保存される。
これにより、端末１０とサーバ２０は、共有鍵Ｋを用いて以降のメッセージ（つまり、ＣｌｉｅｎｔＨｅｌｌｏ及びＳｅｒｖｅｒＨｅｌｌｏよりも後のメッセージ）を暗号化してＴＬＳ１．３の処理を行うことができる（ステップＳ１１３）。
≪認証処理（実施例２）≫
以降では、ＩＤベース暗号を用いた相互認証付き鍵交換を適用したＴＬＳ１．３による認証処理の実施例２について、図６を参照しながら説明する。図６は、実施例２における認証処理の一例を示すシーケンス図である。
実施例２では、鍵生成局のマスター秘密鍵をｙ∈Ｚｑ及びｚ∈Ｚｑ、マスター公開鍵をＹ１＝ｙｇ１，Ｙ２＝ｙｇ２，Ｚ１＝ｚｇ１及びＺ２＝ｚｇ２とする。また、端末１０のユーザ秘密鍵をＤＡ，１＝ｚＱＡ，１＝ｚＨ１（ＩＤＡ）∈Ｇ１、サーバ２０のユーザ秘密鍵をＤＢ，２＝ｚＱＢ，２＝ｚＨ２（ＩＤＢ）∈Ｇ２とする。ここで、Ｈ１は文字列からＧ１上の元を生成する関数であり、Ｈ２は文字列からＧ２上の元を生成する関数である。Ｈ１及びＨ２は公開情報である。なお、ユーザ秘密鍵ＤＡ，１及びＤＢ，２は鍵生成局で生成され、それぞれ任意の方法で端末１０及びサーバ２０に配布される。
端末１０の認証処理部１０１は、短期秘密鍵ｘＡ∈Ｚｑをランダムに選択した上で、短期公開鍵ＸＡ，１＝ｘＡｇ１∈Ｇ１を生成する（ステップＳ２０１）。なお、短期秘密鍵ｘＡと短期公開鍵ＸＡ，１は、記憶部１０２に保存される。
サーバ２０の認証処理部２０１は、短期秘密鍵ｘＢ∈Ｚｑをランダムに選択した上で、短期公開鍵ＸＢ，２＝ｘＢｇ２∈Ｇ２を生成する（ステップＳ２０２）。なお、短期秘密鍵ｘＢと短期公開鍵ＸＢ，２は、記憶部２０２に保存される。
次に、端末１０の認証処理部１０１は、ＣｌｉｅｎｔＨｅｌｌｏをサーバ２０に送信する（ステップＳ２０３）。このとき、認証処理部１０１は、当該端末１０の識別子ＩＤＡと短期公開鍵ＸＡ，１とが含まれるＣｌｉｅｎｔＨｅｌｌｏをサーバ２０に送信する。ここで、識別子ＩＤＡと短期公開鍵ＸＡ，１は、例えば、ＣｌｉｅｎｔＨｅｌｌｏの拡張領域（Ｅｘｔｅｎｓｉｏｎフィールド）に格納することができる。
次に、サーバ２０の認証処理部２０１は、ＳｅｒｖｅｒＨｅｌｌｏを端末１０に送信する（ステップＳ２０４）。このとき、認証処理部２０１は、当該サーバ２０の識別子ＩＤＢと短期公開鍵ＸＢ，２とが含まれるＳｅｒｖｅｒＨｅｌｌｏを端末１０に送信する。ここで、識別子ＩＤＢと短期公開鍵ＸＢ，２は、例えば、ＳｅｒｖｅｒＨｅｌｌｏの拡張領域（Ｅｘｔｅｎｓｉｏｎフィールド）に格納することができる。
上記のステップＳ２０３～ステップＳ２０４により鍵交換に必要な情報（つまり、通信相手の識別子と短期公開鍵）が交換される。すなわち、鍵交換に必要な情報が１ラウンドで交換される。
次に、端末１０の認証処理部１０１は、以下により共有値σ１，σ２，σ３を計算する（ステップＳ２０５）。
σ１＝ｅ（ＤＡ，１，ＱＢ，２）
σ２＝ｅ（ＤＡ，１＋ｘＡＺ１，ＱＢ，２＋ＸＢ，２）
σ３＝ｅ（Ｚ１＋ｘＡＹ１，ＸＢ，２）
同様に、サーバ２０の認証処理部２０１は、以下により共有値σ１，σ２，σ３を計算する（ステップＳ２０６）。
σ１＝ｅ（ＱＡ，１，ＤＢ，２）
σ２＝ｅ（ＱＡ，１＋ＸＡ，１，ＤＢ，２＋ｘＢＺ２）
σ３＝ｅ（ＸＡ，１，Ｚ２＋ｘＢＹ２）
そして、端末１０の認証処理部１０１は、以下により共有鍵Ｋを計算する（ステップＳ２０７）。
Ｋ＝Ｈ（σ１，σ２，σ３，ＩＤＡ，ＩＤＢ，ＸＡ，１，ＸＢ，２）
なお、この共有鍵Ｋは記憶部１０２に保存される。
同様に、サーバ２０の認証処理部２０１は、以下により共有鍵Ｋを計算する（ステップＳ２０８）。
Ｋ＝Ｈ（σ１，σ２，σ３，ＩＤＡ，ＩＤＢ，ＸＡ，１，ＸＢ，２）
なお、この共有鍵Ｋは記憶部２０２に保存される。
これにより、端末１０とサーバ２０は、共有鍵Ｋを用いて以降のメッセージ（つまり、ＣｌｉｅｎｔＨｅｌｌｏ及びＳｅｒｖｅｒＨｅｌｌｏよりも後のメッセージ）を暗号化してＴＬＳ１．３の処理を行うことができる（ステップＳ２０９）。
≪認証処理（実施例３）≫
以降では、ＩＤベース暗号を用いた相互認証付き鍵交換を適用したＴＬＳ１．３による認証処理の実施例３について、図７を参照しながら説明する。図７は、実施例３における認証処理の一例を示すシーケンス図である。
実施例３では、鍵生成局のマスター秘密鍵をｚ∈Ｚｑ、マスター公開鍵をＺ＝ｚｇ１とする。また、端末１０のユーザ秘密鍵をＤＡ＝ｚＱＡ＝ｚＨ３（ＩＤＡ）∈Ｇ２、サーバ２０のユーザ秘密鍵をＤＢ＝ｚＱＢ＝ｚＨ３（ＩＤＢ）∈Ｇ２とする。ここで、Ｈ３は文字列からＧ２上の元を生成する関数であり、公開情報である。なお、ユーザ秘密鍵ＤＡ及びＤＢは鍵生成局で生成され、それぞれ任意の方法で端末１０及びサーバ２０に配布される。
端末１０の認証処理部１０１は、ｒＡ∈Ｚｑをランダムに選択した上で、短期秘密鍵ｘＡ＝Ｈ４（ＤＡ||ｒＡ）を生成すると共に、短期公開鍵ＸＡ＝ｘＡｇ１∈Ｇ１を生成する（ステップＳ３０１）。ここで、Ｈ４は文字列からＺｑ上の元を生成する関数であり、公開情報である。なお、短期秘密鍵ｘＡと短期公開鍵ＸＡは、記憶部１０２に保存される。
サーバ２０の認証処理部２０１は、ｒＢ∈Ｚｑをランダムに選択した上で、短期秘密鍵ｘＢ＝Ｈ４（ＤＢ||ｒＢ）を生成すると共に、短期公開鍵ＸＢ＝ｘＢｇ１∈Ｇ１を生成する（ステップＳ３０２）。なお、短期秘密鍵ｘＢと短期公開鍵ＸＢは、記憶部２０２に保存される。
次に、端末１０の認証処理部１０１は、短期秘密鍵ｘＡを記憶部１０２から削除する（ステップＳ３０３）。同様に、サーバ２０の認証処理部２０１は、短期秘密鍵ｘＢを記憶部２０２から削除する（ステップＳ３０４）。
なお、上記のステップＳ３０３で短期秘密鍵ｘＡを記憶部１０２から削除しているが、これは、識別子ＩＤＢ及び短期公開鍵ＸＢをサーバ２０から受信するまでの間に短期秘密鍵ｘＡが流出してしまう事態を防止するためである。同様に、上記のステップＳ３０４で短期秘密鍵ｘＢを記憶部２０２から削除しているのは、識別子ＩＤＡ及び短期公開鍵ＸＡを端末１０から受信するまでの間に短期秘密鍵ｘＢが流出してしまう事態を防止するためである。
次に、端末１０の認証処理部１０１は、ＣｌｉｅｎｔＨｅｌｌｏをサーバ２０に送信する（ステップＳ３０５）。このとき、認証処理部１０１は、当該端末１０の識別子ＩＤＡと短期公開鍵ＸＡとが含まれるＣｌｉｅｎｔＨｅｌｌｏをサーバ２０に送信する。ここで、識別子ＩＤＡと短期公開鍵ＸＡは、例えば、ＣｌｉｅｎｔＨｅｌｌｏの拡張領域（Ｅｘｔｅｎｓｉｏｎフィールド）に格納することができる。
次に、サーバ２０の認証処理部２０１は、ＳｅｒｖｅｒＨｅｌｌｏを端末１０に送信する（ステップＳ３０６）。このとき、認証処理部２０１は、当該サーバ２０の識別子ＩＤＢと短期公開鍵ＸＢとが含まれるＳｅｒｖｅｒＨｅｌｌｏを端末１０に送信する。ここで、識別子ＩＤＢと短期公開鍵ＸＢは、例えば、ＳｅｒｖｅｒＨｅｌｌｏの拡張領域（Ｅｘｔｅｎｓｉｏｎフィールド）に格納することができる。
上記のステップＳ３０５～ステップＳ３０６により鍵交換に必要な情報（つまり、通信相手の識別子と短期公開鍵）が交換される。すなわち、鍵交換に必要な情報が１ラウンドで交換される。
続いて、端末１０の認証処理部１０１は、短期秘密鍵ｘＡ＝Ｈ４（ＤＡ||ｒＡ）を再度生成する（ステップＳ３０７）。なお、短期秘密鍵ｘＡは、記憶部１０２に保存される。
同様に、サーバ２０の認証処理部２０１は、短期秘密鍵ｘＢ＝Ｈ４（ＤＢ||ｒＢ）を再度生成する（ステップＳ３０８）。なお、短期秘密鍵ｘＢは、記憶部２０２に保存される。
次に、端末１０の認証処理部１０１は、以下により共有値σ１，σ２，σ３を計算する（ステップＳ３０９）。
σ１＝ｅ（ＸＢ，ＤＡ）
σ２＝ｅ（ｘＡＺ，ＱＢ）
σ３＝ｘＡＸＢ
同様に、サーバ２０の認証処理部２０１は、以下により共有値σ１，σ２，σ３を計算する（ステップＳ３１０）。
σ１＝ｅ（ｘＢＺ，ＱＡ）
σ２＝ｅ（ＸＡ，ＤＢ）
σ３＝ｘＢＸＡ
次に、端末１０の認証処理部１０１は、以下によりｓｉｄを計算する（ステップＳ３１１）。
ｓｉｄ＝（ＩＤＡ||ＩＤＢ||ＸＡ||ＸＢ）
同様に、サーバ２０の認証処理部２０１は、以下によりｓｉｄを計算する（ステップＳ３１２）。
ｓｉｄ＝（ＩＤＡ||ＩＤＢ||ＸＡ||ＸＢ）
そして、端末１０の認証処理部１０１は、以下により共有鍵Ｋを計算する（ステップＳ３１３）。
Ｋ＝Ｈ（σ１||σ２||σ３||ｓｉｄ）
なお、この共有鍵Ｋは記憶部１０２に保存される。
同様に、サーバ２０の認証処理部２０１は、以下により共有鍵Ｋを計算する（ステップＳ３１４）。
Ｋ＝Ｈ（σ１||σ２||σ３||ｓｉｄ）
なお、この共有鍵Ｋは記憶部２０２に保存される。
これにより、端末１０とサーバ２０は、共有鍵Ｋを用いて以降のメッセージ（つまり、ＣｌｉｅｎｔＨｅｌｌｏ及びＳｅｒｖｅｒＨｅｌｌｏよりも後のメッセージ）を暗号化してＴＬＳ１．３の処理を行うことができる（ステップＳ３１５）。
＜評価＞
最後に、本実施形態に係る認証システム１が実行する認証処理（ＩＤベース暗号を用いた相互認証付き鍵交換を適用したＴＬＳ１．３による認証処理）の評価について説明する。一例として、上記の実施例３で説明した認証処理と、従来のＴＬＳとを比較した。比較対象としては、既存の暗号スイートの中で比較的通信量が少ないTLS1.3-X25519-Ed25519を採用した。
ＴＬＳのハンドシェイク中の各メッセージのパケットサイズを観測した結果とその合計とを以下の表１に示す。なお、表１では、ＩＤベース暗号に用いられる識別子のデータサイズは２０バイトとしている。また、表１では、参考として、TLS1.3-P256-RSAにおける各メッセージのパケットサイズとその合計も記載している。
Figure 0007231051000002
 上記の表１に示すように、実施例３は、TLS1.3-X25519-Ed25519と比較して通信量を約３４％に削減できていることがわかる。このため、実施例３は、例えば、ＩｏＴ機器向けの通信規格であるRoLaWANやSigfox等でＴＬＳを使用する場合にも有効であることがわかる。
本発明は、具体的に開示された上記の実施形態に限定されるものではなく、請求の範囲の記載から逸脱することなく、種々の変形や変更等が可能である。
１ 認証システム
１０ 端末
２０ サーバ
１０１ 認証処理部
１０２ 記憶部
２０１ 認証処理部
２０２ 記憶部
Ｎ 通信ネットワーク

Claims (7)

  1. 通信ネットワークを介して接続されるサーバとの間でＴＬＳ１．３による認証を行う端末であって、
    ＩＤベース暗号を用いた相互認証付き鍵交換によって前記ＴＬＳ１．３のハンドシェイク中のメッセージを暗号化するための共有鍵の生成に必要な第１の識別子と第１の短期公開鍵とが含まれるＣｌｉｅｎｔＨｅｌｌｏメッセージを前記サーバに送信する送信手段と、
    前記共有鍵の生成に必要な第２の識別子と第２の短期公開鍵とが含まれるＳｅｒｖｅｒＨｅｌｌｏメッセージを前記サーバから受信する受信手段と、
    前記第１の識別子と前記第１の短期公開鍵と前記第２の識別子と前記第２の短期公開鍵とを用いて、前記共有鍵を生成する生成手段と、
    を有することを特徴とする端末。
  2. 前記第１の識別子は前記端末を識別する識別情報、前記第２の識別子は前記サーバを識別する識別情報であり、
    前記第１の短期公開鍵は前記端末が生成した第１の短期秘密鍵と楕円曲線上の部分群の生成元とから生成され、前記第２の短期公開鍵は前記サーバが生成した第２の短期秘密鍵と楕円曲線上の部分群の生成元とから生成される、ことを特徴とする請求項１に記載の端末。
  3. 通信ネットワークを介して接続される端末との間でＴＬＳ１．３による認証を行うサーバであって、
    ＩＤベース暗号を用いた相互認証付き鍵交換によって前記ＴＬＳ１．３のハンドシェイク中のメッセージを暗号化するための共有鍵の生成に必要な第１の識別子と第１の短期公開鍵とが含まれるＣｌｉｅｎｔＨｅｌｌｏメッセージを前記端末から受信する受信手段と、
    前記共有鍵の生成に必要な第２の識別子と第２の短期公開鍵とが含まれるＳｅｒｖｅｒＨｅｌｌｏメッセージを前記端末に送信する送信手段と、
    前記第１の識別子と前記第１の短期公開鍵と前記第２の識別子と前記第２の短期公開鍵とを用いて、前記共有鍵を生成する生成手段と、
    を有することを特徴とするサーバ。
  4. 前記第１の識別子は前記端末を識別する識別情報、前記第２の識別子は前記サーバを識別する識別情報であり、
    前記第１の短期公開鍵は前記端末が生成した第１の短期秘密鍵と楕円曲線上の部分群の生成元とから生成され、前記第２の短期公開鍵は前記サーバが生成した第２の短期秘密鍵と楕円曲線上の部分群の生成元とから生成される、ことを特徴とする請求項３に記載のサーバ。
  5. 通信ネットワークを介して接続されるサーバとの間でＴＬＳ１．３による認証を行う端末が、
    ＩＤベース暗号を用いた相互認証付き鍵交換によって前記ＴＬＳ１．３のハンドシェイク中のメッセージを暗号化するための共有鍵の生成に必要な第１の識別子と第１の短期公開鍵とが含まれるＣｌｉｅｎｔＨｅｌｌｏメッセージを前記サーバに送信する送信手順と、
    前記共有鍵の生成に必要な第２の識別子と第２の短期公開鍵とが含まれるＳｅｒｖｅｒＨｅｌｌｏメッセージを前記サーバから受信する受信手順と、
    前記第１の識別子と前記第１の短期公開鍵と前記第２の識別子と前記第２の短期公開鍵とを用いて、前記共有鍵を生成する生成手順と、
    を実行することを特徴とする方法。
  6. 通信ネットワークを介して接続される端末との間でＴＬＳ１．３による認証を行うサーバが、
    ＩＤベース暗号を用いた相互認証付き鍵交換によって前記ＴＬＳ１．３のハンドシェイク中のメッセージを暗号化するための共有鍵の生成に必要な第１の識別子と第１の短期公開鍵とが含まれるＣｌｉｅｎｔＨｅｌｌｏメッセージを前記端末から受信する受信手順と、
    前記共有鍵の生成に必要な第２の識別子と第２の短期公開鍵とが含まれるＳｅｒｖｅｒＨｅｌｌｏメッセージを前記端末に送信する送信手順と、
    前記第１の識別子と前記第１の短期公開鍵と前記第２の識別子と前記第２の短期公開鍵とを用いて、前記共有鍵を生成する生成手順と、
    を実行することを特徴とする方法。
  7. コンピュータを、請求項１若しくは２に記載の端末における各手段、又は、請求項３若しくは４に記載のサーバにおける各手段、として機能させるためのプログラム。
JP2021550916A 2019-10-04 2019-10-04 端末、サーバ、方法及びプログラム Active JP7231051B2 (ja)

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/JP2019/039253 WO2021064978A1 (ja) 2019-10-04 2019-10-04 端末、サーバ、方法及びプログラム

Publications (2)

Publication Number Publication Date
JPWO2021064978A1 JPWO2021064978A1 (ja) 2021-04-08
JP7231051B2 true JP7231051B2 (ja) 2023-03-01

Family

ID=75337937

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2021550916A Active JP7231051B2 (ja) 2019-10-04 2019-10-04 端末、サーバ、方法及びプログラム

Country Status (3)

Country Link
US (1) US20220337403A1 (ja)
JP (1) JP7231051B2 (ja)
WO (1) WO2021064978A1 (ja)

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20100031042A1 (en) 2007-10-26 2010-02-04 Telcordia Technologies, Inc. Method and System for Secure Session Establishment Using Identity-Based Encryption (VDTLS)
EP2173055A1 (en) 2007-12-14 2010-04-07 Huawei Technologies Co., Ltd. A method, a system, a client and a server for key negotiating

Family Cites Families (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR20160140240A (ko) * 2015-05-29 2016-12-07 한밭대학교 산학협력단 Ｗａｖｅ 시스템을 위한 에러제어 기능을 개선한 보안통신 프로토콜을 이용한 데이터통신 방법 및 그 장치
JP6613909B2 (ja) * 2016-01-15 2019-12-04 富士通株式会社 相互認証方法、認証装置および認証プログラム
CN108111467B (zh) * 2016-11-24 2021-04-09 华为技术有限公司 身份认证方法与设备及系统
US10721219B2 (en) * 2018-06-28 2020-07-21 Nxp B.V. Method for establishing a secure communication session in a communications system
WO2020223319A1 (en) * 2019-05-01 2020-11-05 Nix John A Distributed eap-tls authentication for wireless networks with concealed subscriber identities

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20100031042A1 (en) 2007-10-26 2010-02-04 Telcordia Technologies, Inc. Method and System for Secure Session Establishment Using Identity-Based Encryption (VDTLS)
EP2173055A1 (en) 2007-12-14 2010-04-07 Huawei Technologies Co., Ltd. A method, a system, a client and a server for key negotiating

Non-Patent Citations (3)

* Cited by examiner, † Cited by third party
Title
HUANG, M.，Identity-Based Encryption (IBE) Cipher Suites for Transport Layer Security (TLS) draft-huang-tls-ibe，Internet-Draft，IETF，2009年07月03日，pp.1-16，[令和2年6月11日検索], インターネット:<URL:http://tools.ietf.org/html/draft-huang-tls-ibe-00>
酒見 由美 ほか，IDベース認証機能付鍵交換のTLS適用とその実装評価，2016 Symoposium on Cryptography and Information Security，日本，一般社団法人電子情報通信学会，2016年01月19日，pp.1-8
酒見 由美 ほか，事前共有鍵に基づくＴＬＳのＩＤベース暗号による拡張，研究報告コンピュータセキュリティ（ＣＳＥＣ），日本，情報処理学会，2013年07月11日，Vol.2013-CSEC-62, No.7，pp.1-7

Also Published As

Publication number Publication date
JPWO2021064978A1 (ja) 2021-04-08
WO2021064978A1 (ja) 2021-04-08
US20220337403A1 (en) 2022-10-20

Similar Documents

Publication Publication Date Title
RU2542911C2 (ru) Установление однорангового сеанса с малым временем ожидания
US9237133B2 (en) Detecting matched cloud infrastructure connections for secure off-channel secret generation
EP3205048B1 (en) Generating a symmetric encryption key
US20200195446A1 (en) System and method for ensuring forward &amp; backward secrecy using physically unclonable functions
JP5829574B2 (ja) 認証システム、認証装置、認証方法、及びプログラム
Srikanth et al. An efficient Key Agreement and Authentication Scheme (KAAS) with enhanced security control for IIoT systems
Djellali et al. User authentication scheme preserving anonymity for ubiquitous devices
US11791993B2 (en) Shared key system, information processing apparatus, equipment, shared key method and program
JP2022539458A (ja) エンティティに参加するためにネットワーク識別子を使用してブロックチェーンに関連するトランザクションを実現するためのコンピュータ実施システム及び方法
Chien et al. Efficient MQTT platform facilitating secure group communication
US20210051006A1 (en) Blind key generator and exchange
Nicholson et al. Lokey: Leveraging the sms network in decentralized, end-to-end trust establishment
JP4924943B2 (ja) 認証付鍵交換システム、認証付鍵交換方法およびプログラム
JP7231051B2 (ja) 端末、サーバ、方法及びプログラム
JP7298686B2 (ja) 鍵交換システム、通信装置及びプログラム
CN110572788B (zh) 基于非对称密钥池和隐式证书的无线传感器通信方法和系统
WO2021010444A1 (ja) 鍵交換システム、通信装置、鍵交換方法及びプログラム
Tsai et al. High-efficient multi-key exchange protocol based on three-party authentication
JP7289478B2 (ja) 鍵交換システム、機器、情報処理装置、鍵交換方法及びプログラム
JP7377495B2 (ja) 暗号システム及び方法
JP2011254146A (ja) 通信内容監査方法および通信内容監査システム
CN116112152B (zh) 跨企业网络的数据共享安全加密方法和装置
Belej et al. The features of security of transfer and storage data for the Internet of Things in Cloud Database
JP2023175540A (ja) 鍵交換システム、情報処理装置、方法、及びプログラム
CN115001705A (zh) 一种基于加密设备的网络协议安全提升方法

Legal Events

Date Code Title Description
A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20220311

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

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20230130

R150 Certificate of patent or registration of utility model

Ref document number: 7231051

Country of ref document: JP

Free format text: JAPANESE INTERMEDIATE CODE: R150