JP2019213085A - データ通信システム - Google Patents

データ通信システム Download PDF

Info

Publication number
JP2019213085A
JP2019213085A JP2018108639A JP2018108639A JP2019213085A JP 2019213085 A JP2019213085 A JP 2019213085A JP 2018108639 A JP2018108639 A JP 2018108639A JP 2018108639 A JP2018108639 A JP 2018108639A JP 2019213085 A JP2019213085 A JP 2019213085A
Authority
JP
Japan
Prior art keywords
common key
server
iot device
temporary common
temporary
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
JP2018108639A
Other languages
English (en)
Inventor
高秀 等々力
Takahide Todoroki
高秀 等々力
佐藤　浩一
Koichi Sato
浩一 佐藤
和彦 野藤
Kazuhiko Nofuji
和彦 野藤
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.)
Renesas Electronics Corp
Original Assignee
Renesas Electronics 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 Renesas Electronics Corp filed Critical Renesas Electronics Corp
Priority to JP2018108639A priority Critical patent/JP2019213085A/ja
Priority to US16/409,424 priority patent/US11178137B2/en
Publication of JP2019213085A publication Critical patent/JP2019213085A/ja
Pending legal-status Critical Current

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/08—Network architectures or network communication protocols for network security for authentication of entities
    • H04L63/083—Network architectures or network communication protocols for network security for authentication of entities using passwords
    • H04L63/0838—Network architectures or network communication protocols for network security for authentication of entities using passwords using one-time-passwords
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/06—Network architectures or network communication protocols for network security for supporting key management in a packet data network
    • H04L63/062—Network architectures or network communication protocols for network security for supporting key management in a packet data network for key distribution, e.g. centrally by trusted party
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/60—Protecting data
    • G06F21/602—Providing cryptographic facilities or services
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/60—Protecting data
    • G06F21/606—Protecting data by securing the transmission between two devices or processes
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/06—Network architectures or network communication protocols for network security for supporting key management in a packet data network
    • H04L63/067—Network architectures or network communication protocols for network security for supporting key management in a packet data network using one-time keys
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
    • H04L63/0892—Network architectures or network communication protocols for network security for authentication of entities by using authentication-authorization-accounting [AAA] servers or protocols
    • 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)
    • 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/0891—Revocation or update of secret information, e.g. encryption key update or rekeying
    • 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/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3247—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving digital signatures
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/04—Key management, e.g. using generic bootstrapping architecture [GBA]
    • H04W12/043—Key management, e.g. using generic bootstrapping architecture [GBA] using a trusted network node as an anchor
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/06—Authentication
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/50—Secure pairing of devices
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W4/00—Services specially adapted for wireless communication networks; Facilities therefor
    • H04W4/70—Services for machine-to-machine communication [M2M] or machine type communication [MTC]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L2209/00—Additional information or applications relating to cryptographic mechanisms or cryptographic arrangements for secret or secure communication H04L9/00
    • H04L2209/80—Wireless
    • H04L2209/805—Lightweight hardware, e.g. radio-frequency identification [RFID] or sensor

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer Hardware Design (AREA)
  • General Engineering & Computer Science (AREA)
  • Computing Systems (AREA)
  • Theoretical Computer Science (AREA)
  • Bioethics (AREA)
  • General Health & Medical Sciences (AREA)
  • Software Systems (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Health & Medical Sciences (AREA)
  • Business, Economics & Management (AREA)
  • Accounting & Taxation (AREA)
  • Telephonic Communication Services (AREA)
  • Computer And Data Communications (AREA)

Abstract

【課題】ＩｏＴデバイスに認証情報を設定する際、悪意ある第三者によるスマートデバイスへの攻撃によって、ＩｏＴデバイスの認証情報が外部に流出する危険を防ぐデータ通信システムを提供する。【解決手段】データ通信システム１は、ＩｏＴデバイス３００と、ＩｏＴデバイスと通信可能なスマートデバイス１００と、ＩｏＴデバイス及びスマートデバイスと通信可能なサーバ２００とを備える。スマートデバイスは、ＩｏＴデバイスからの接続要求を受信した場合に、仮の共通鍵をサーバに要求する。サーバは、スマートデバイスからの仮の共通鍵の要求を受信した場合に、仮の共通鍵を生成し、仮の共通鍵をスマートデバイスに送信する。スマートデバイスは、受信した仮の共通鍵をＩｏＴデバイスに送信する。ＩｏＴデバイスとサーバは、当該仮の共通鍵を用いて、認証を行う。【選択図】図１

Description

本発明はデータ通信システムに関する。
ＩｏＴ（Internet of Things）デバイスがサーバなどの機器とデータ通信を行うシステムでは、データ通信において認証情報が必要となる。このＩｏＴデバイスがサーバなどの機器とデータ通信を行う際に必要となる認証情報は、ＩｏＴデバイスとサーバの両者で共有する必要がある情報である。ＩｏＴデバイスへの認証情報の設定は、スマートデバイスなどのユーザインターフェイスを備えた機器から対象となるＩｏＴデバイスに指示されることにより実行される。
ＩｏＴデバイスとサーバは、ユーザインターフェイスを持たないなどの理由により、認証情報を渡す相手が本当に認証情報を渡すべき相手かどうか確認することができない。したがって、上述のようにＩｏＴデバイスとサーバ間で直接認証情報の受け渡しを行わず、スマートデバイスなどの機器を介してＩｏＴデバイスに認証情報の設定を行うことになる。
例えば、ＰＣとＷＩ−ＦＩルータの接続設定では、ＰＣにＷＩ−ＦＩルータのパスワードを設定する必要がある。この場合、ＷＩ−ＦＩルータからＰＣにＷＩ−ＦＩルータのパスワードを直接送信せずに、人がＰＣにＷＩ−ＦＩルータのパスワードを直接入力する。これは、認証情報（パスワード）を渡す相手（ＰＣ）が本当に認証情報を渡すべき相手かどうか確認していることに等しい。他方、ＩｏＴデバイスの場合は、ＰＣと異なり自身でユーザインターフェイスを持たないため、スマートデバイスなどの機器を代わりに使用する。
非特許文献１には、スマートデバイスを用いてＩｏＴデバイスとサーバの認証を行うシステムが記載されている。非特許文献１において、”ｎＲＦ５２”は、ＩｏＴデバイスに相当する。”ｎＲＦ５２”は直接インターネットにアクセスするための通信手段を持たずＢＬＥ通信を用いて”Ｅｄｇｅ ｒｏｕｔｅｒ”と接続する。”Ｅｄｇｅ ｒｏｕｔｅｒ”は、ＢＬＥ接続とインターネットに接続する機能を持ち、”ｎＲＦ５２”は”Ｅｄｇｅ ｒｏｕｔｅｒ”を介してインターネットに接続する。”Ｅｄｇｅ ｒｏｕｔｅｒ”は、”ｎＲＦ５２”からの接続に対してパスワードを要求する。このパスワードは、”ｎＲＦ５２”と”Ｅｄｇｅ ｒｏｕｔｅｒ”の２者で共有する情報であり、第三者に流出してはならない情報である。このパスワードは、”Ｅｄｇｅ ｒｏｕｔｅｒ”には予め登録済みで、”ｎＲＦ５２”には”ｓｍａｒｔ ｄｅｖｉｃｅ”を使用して設定する。
nRF5 IoT SDK v0.9.0http://infocenter.nordicsemi.com/index.jsp?topic=%2Fcom.nordic.infocenter.iotsdk.v0.9.0%2Findex.html
しかし、非特許文献１のシステムでは、ＩｏＴデバイスに認証情報を設定する際に、スマートデバイスに認証情報が保管されるため、悪意ある第三者によるスマートデバイスへの攻撃やスマートデバイスの紛失によって、認証情報が外部に流出する危険性があるという問題があった。
その他の課題と新規な特徴は、本明細書の記述および添付図面から明らかになるであろう。
一実施の形態によれば、スマートデバイスがＩｏＴデバイスからの接続要求を受信した場合に、スマートデバイスは一時的に有効な仮の共通鍵をサーバに要求し、
サーバは、スマートデバイスからの仮の共通鍵の要求を受信した場合に、仮の共通鍵を生成し、仮の共通鍵をスマートデバイスに送信し、
スマートデバイスは、受信した仮の共通鍵をＩｏＴデバイスに送信し、
ＩｏＴデバイスとサーバは、当該仮の共通鍵を用いて、認証を行うようにした。
前記一実施の形態によれば、悪意ある第三者によるスマートデバイスへの攻撃やスマートデバイスの紛失によって、認証情報が外部に流出する危険を防ぐことができる。
実施の形態の概要に係る制御装置の構成を示すブロック図である。 実施の形態１に係るデータ通信システムの構成を示すブロック図である。 実施の形態１に係るスマートデバイスの構成を示すブロック図である。 実施の形態１に係るサーバの構成を示すブロック図である。 実施の形態１に係るＩｏＴデバイスの構成を示すブロック図である。 実施の形態１に係るゲートウェイの構成を示すブロック図である。 実施の形態１に係るデータ通信システムの認証処理の一例を示すシーケンス図である。 実施の形態１に係るデータ通信システムの認証情報の受け渡しの一例を示すシーケンス図である。 実施の形態３に係るデータ通信システムの認証情報の受け渡しの一例を示すシーケンス図である。 実施の形態４に係るデータ通信システムの構成を示すブロック図である。 実施の形態４に係るサービスサーバの構成を示すブロック図である。 実施の形態４に係る共通鍵管理サーバの構成を示すブロック図である。 実施の形態４に係るデータ通信システムの共通鍵管理の一例を示すシーケンス図である。 実施の形態５に係るデータ通信システムの構成を示すブロック図である。 実施の形態５に係る認可サーバの構成を示すブロック図である。 実施の形態５に係る認可判定機器の構成を示すブロック図である。 実施の形態５に係るデータ通信システムの認証情報の受け渡しの一例を示すシーケンス図である。
説明の明確化のため、以下の記載及び図面は、適宜、省略、及び簡略化がなされている。また、様々な処理を行う機能ブロックとして図面に記載される各要素は、ハードウェア的には、ＣＰＵ、メモリ、その他の回路で構成することができ、ソフトウェア的には、メモリにロードされたプログラムなどによって実現される。したがって、これらの機能ブロックがハードウェアのみ、ソフトウェアのみ、またはそれらの組合せによっていろいろな形で実現できることは当業者には理解されるところであり、いずれかに限定されるものではない。なお、各図面において、同一の要素には同一の符号が付されており、必要に応じて重複説明は省略されている。
また、上述したプログラムは、様々なタイプの非一時的なコンピュータ可読媒体（ｎｏｎ−ｔｒａｎｓｉｔｏｒｙ ｃｏｍｐｕｔｅｒ ｒｅａｄａｂｌｅ ｍｅｄｉｕｍ）を用いて格納され、コンピュータに供給することができる。非一時的なコンピュータ可読媒体は、様々なタイプの実体のある記録媒体（ｔａｎｇｉｂｌｅ ｓｔｏｒａｇｅ ｍｅｄｉｕｍ）を含む。非一時的なコンピュータ可読媒体の例は、磁気記録媒体（例えばフレキシブルディスク、磁気テープ、ハードディスクドライブ）、光磁気記録媒体（例えば光磁気ディスク）、ＣＤ−ＲＯＭ（Ｒｅａｄ Ｏｎｌｙ Ｍｅｍｏｒｙ）ＣＤ−Ｒ、ＣＤ−Ｒ／Ｗ、半導体メモリ（例えば、マスクＲＯＭ、ＰＲＯＭ（Ｐｒｏｇｒａｍｍａｂｌｅ ＲＯＭ）、ＥＰＲＯＭ（Ｅｒａｓａｂｌｅ ＰＲＯＭ）、フラッシュＲＯＭ、ＲＡＭ（Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ））を含む。また、プログラムは、様々なタイプの一時的なコンピュータ可読媒体（ｔｒａｎｓｉｔｏｒｙ ｃｏｍｐｕｔｅｒ ｒｅａｄａｂｌｅ ｍｅｄｉｕｍ）によってコンピュータに供給されてもよい。一時的なコンピュータ可読媒体の例は、電気信号、光信号、及び電磁波を含む。一時的なコンピュータ可読媒体は、電線及び光ファイバ等の有線通信路、又は無線通信路を介して、プログラムをコンピュータに供給できる。
（実施形態の概要）
図１は、実施の形態の概要に係る制御装置の構成を示すブロック図である。図１において、データ通信システム１は、スマートデバイス１００と、サーバ２００と、ＩｏＴデバイス３００とを備える。
スマートデバイス１００は、サーバ２００及びＩｏＴデバイス３００と通信可能なデバイスである。スマートデバイス１００は、IｏＴデバイス３００からの接続要求を受信した場合に、一時的に有効な仮の共通鍵をサーバ２００に要求する。また、スマートデバイス１００は、受信した仮の共通鍵をＩｏＴデバイス３００に送信する。
サーバ２００は、スマートデバイス１００及びＩｏＴデバイス３００と通信可能なサーバである。サーバ２００は、スマートデバイス１００からの仮の共通鍵の要求を受信した場合に、仮の共通鍵を生成し、仮の共通鍵をスマートデバイス１００に送信する。
ＩｏＴデバイス３００は、スマートデバイス１００及びサーバ２００と通信可能なデバイスである。ＩｏＴデバイス３００は、スマートデバイス１００から送信された仮の共通鍵を受信する。
そして、ＩｏＴデバイス３００とサーバ２００は、仮の共通鍵を用いて、認証を行う。
このように、実施の形態の概要に係るデータ通信システムによれば、スマートデバイスはＩｏＴデバイスからの接続要求に応じて一時的に有効な仮の共通鍵をサーバに要求し、サーバで生成された仮の共通鍵をＩｏＴデバイスに送信することにより、悪意ある第三者によるスマートデバイスへの攻撃やスマートデバイスの紛失によって、認証情報が外部に流出する危険を防ぐことができる。
（実施の形態１）
実施の形態１では、実施の形態の概要で説明したデータ通信システム１の詳細な構成について説明する。図２は、実施の形態１に係るデータ通信システムの構成を示すブロック図である。図２において、データ通信システム１０は、スマートデバイス１００と、サーバ２００と、ＩｏＴデバイス３００と、ゲートウェイ４００とを備える。
スマートデバイス１００は、サーバ２００及びＩｏＴデバイス３００と通信可能なデバイスである。スマートデバイス１００は、IｏＴデバイス３００からの接続要求を受信した場合に、一時的に有効な仮の共通鍵をサーバ２００に要求する。また、スマートデバイス１００は、受信した仮の共通鍵をＩｏＴデバイス３００に送信する。
サーバ２００は、スマートデバイス１００及びゲートウェイ４００と通信可能なサーバである。サーバ２００は、スマートデバイス１００からの仮の共通鍵の要求を受信した場合に、仮の共通鍵を生成し、仮の共通鍵をスマートデバイス１００に送信する。
ＩｏＴデバイス３００は、スマートデバイス１００及びゲートウェイ４００と通信可能なデバイスである。ＩｏＴデバイス３００は、スマートデバイス１００から送信された仮の共通鍵を受信する。
ゲートウェイ４００は、サーバ２００とＩｏＴデバイス３００の通信を仲介する。またゲートウェイ４００は、サーバ２００とＩｏＴデバイス３００の通信について、必要に応じて信号及びプロトコルの変換を行う。
そして、ＩｏＴデバイス３００とサーバ２００は、仮の共通鍵を用いて、認証を行う。そして、認証に成功した場合、仮の共通鍵を公開鍵暗号方式のサーバ２００の公開鍵として使用し、サーバ２００とＩｏＴデバイス３００間で公開鍵暗号方式を用いて認証情報の受け渡しを行う。
なお、図２では、通信方式の違いでＩｏＴデバイス３００がサーバ２００と直接データ通信ができない場合に、ゲートウェイ４００などの機器を介してＩｏＴデバイス３００がサーバ２００とデータ通信を行う例を示している。したがって、ＩｏＴデバイス３００がサーバ２００と直接データ通信する機能を持っている場合は、ゲートウェイ４００は必ずしも必要ではない。
次に、スマートデバイス１００の構成について説明する。図３は、実施の形態１に係るスマートデバイスの構成を示すブロック図である。図３において、スマートデバイス１００は、通信部１０１と、通信部１０２と、ユーザインターフェイス１０３と、仮の共通鍵の設定処理部１０４とを備える。
通信部１０１は、ＩｏＴデバイス３００と通信を行う通信部である。例えば、通信部１０１は、無線通信回路で構成されてもよい。そして、通信部１０１は、ＩｏＴデバイス３００と通信可能になった場合、ＩｏＴデバイス３００の存在をユーザインターフェイス１０３に通知する。
通信部１０２は、サーバ２００と通信を行う通信部である。例えば、通信部１０２は、無線通信回路で構成されてもよい。そして、通信部１０２は、ＩｏＴデバイス３００からの仮の共通鍵の要求をサーバ２００に送信する。また、通信部１０２は、サーバ２００から送信された仮の共通鍵を受信する。通信部１０２は、サーバ２００とセキュアな通信を行うことが望ましい。
ユーザインターフェイス１０３は、操作する人からの指示を受け付けるインターフェイスである。また、ユーザインターフェイス１０３は、情報を表示するインターフェイスでもある。例えば、ユーザインターフェイス１０３は、タッチパネルで構成されてもよい。ユーザインターフェイス１０３は、通信可能なＩｏＴデバイスの存在を表示する。そして、ユーザインターフェイス１０３は、通信可能なＩｏＴデバイスの選択を受け付ける。
仮の共通鍵の設定処理部１０４は、ユーザインターフェイス１０３が受け付けた指示に従い、ＩｏＴデバイス３００の認証を指示する処理を行う。指示内容は通信部１０１を介して送信される。
以上の構成により、スマートデバイス１００は、ＩｏＴデバイス３００の認証情報の受け渡しを行う。
なお、スマートデバイス１００は、ＩｏＴデバイス３００とサーバ２００の双方とデータ通信が可能であり、ユーザインターフェイス１０３を備え、接続先のＩｏＴデバイス３００の選択が可能である情報処理装置であってもよい。例えば、スマートデバイス１００をノートＰＣやモバイルＰＣであってもよい。またスマートデバイス１００は、スマートフォン、タブレットデバイス、スマートウォッチ、スマートグラスまたはウェアラブルコンピュータを含む。
次にサーバ２００の構成について説明する。図４は、実施の形態１に係るサーバの構成を示すブロック図である。図４において、サーバ２００は、通信部２０１と、アクセス制限管理部２０２と、仮の共通鍵管理部２０３と、仮の共通鍵設定処理部２０４と、認証情報管理部２０５と、認証情報設定処理部２０６と、データ記憶部２０７とを備える。
通信部２０１は、スマートデバイス１００及びゲートウェイ４００と通信を行う通信部である。例えば、通信部２０１は、有線通信回路で構成されてもよい。
アクセス制限管理部２０２は、仮の共通鍵の払い出しは、ユーザ名とパスワードなどによる認証を要求する。仮の共通鍵は、個々のＩｏＴデバイス３００ごとに生成される。
仮の共通鍵管理部２０３は、データ記憶部２０７を参照して、個々のＩｏＴデバイス３００に設定する仮の共通鍵を管理する。
仮の共通鍵設定処理部２０４は、スマートデバイス１００からの要求により仮の共通鍵を払い出す。例えば、仮の共通鍵設定処理部２０４は、要求毎に異なる仮の共通鍵を生成するようにしてもよい。具体的には、仮の共通鍵設定処理部２０４は、仮の共通鍵管理部２０３に記憶された仮の共通鍵とは異なる仮の共通鍵を生成するようにしてもよい。
認証情報管理部２０５は、データ記憶部２０７を参照して、個々のＩｏＴデバイス３００に設定する認証情報を管理する。
認証情報設定処理部２０６は、ＩｏＴデバイス３００に認証情報を設定するか、否か判断する。例えば、認証情報設定処理部２０６は、以下の条件に該当する場合、ＩｏＴデバイス３００に認証情報を設定しないようにしてもよい。
・既に認証情報の設定を行ったことのあるＩｏＴデバイス３００に対する設定処理
・認証情報に対応する仮の共通鍵を払い出してから、予め設定した時間が経過した場合
・払い出していない仮の共通鍵が使用された場合
具体的には、認証情報設定処理部２０６は、毎回異なる仮の共通鍵を使用する。そして、認証情報設定処理部２０６は、認証情報管理部２０５を参照して、認証要求時の仮の共通鍵が、既に認証情報の受け渡しに使用した仮の共通鍵と一致するか否か判断するようにしてもよい。そして、認証情報設定処理部２０６は、認証要求時の仮の共通鍵が、既に認証情報の受け渡しに使用した仮の共通鍵と一致する場合、認証情報設定処理部２０６は、通信部２０１に通信を拒否し、認証情報の受け渡しを拒否するように指示するようにしてもよい。
また、具体的には、認証情報設定処理部２０６は、認証情報管理部２０５を参照して、認証情報に対応する仮の共通鍵を払い出してから、予め設定した時間が経過したか否か判断するようにしてもよい。そして、認証情報に対応する仮の共通鍵を払い出してから、予め設定した時間が経過した場合、認証情報設定処理部２０６は、通信部２０１に通信を拒否し、認証情報の受け渡しを拒否するように指示するようにしてもよい。
また、具体的には、認証情報設定処理部２０６は、認証情報管理部２０５を参照して、払い出していない仮の共通鍵が使用された否か判断するようにしてもよい。そして、払い出していない仮の共通鍵が使用された場合、認証情報設定処理部２０６は、通信部２０１に通信を拒否し、認証情報の受け渡しを拒否するように指示するようにしてもよい。
上記の”予め設定した時間”は、仮の共通鍵が流出した場合で、正規のＩｏＴデバイス３００に認証情報が設定されるより前に、偽のＩｏＴデバイス３００に認証情報が設定されることを防止するため、サーバ２００が管理する仮の共通鍵の有効期間は、仮の共通鍵の払い出しから認証情報の設定に要する必要最小限の時間（例えば十数秒程度）にする。
データ記憶部２０７は、各種データを記憶する記憶部である。具体的には、データ記憶部２０７は、メモリ回路で構成される。メモリ回路の種類は特に限定されない。例えば、データ記憶部２０７は、生成した仮の共通鍵を記憶するようにしてもよい。また、データ記憶部２０７は、生成した仮の共通鍵とＩｏＴデバイス３００の識別子とを組み合わせて記憶するようにしてもよい。また、データ記憶部２０７は、認証情報の受け渡しに使用した仮の共通鍵のパターンを記憶するようにしてもよい。また、データ記憶部２０７は、既に認証情報の受け渡しに使用した仮の共通鍵を記憶するようにしてもよい。また、データ記憶部２０７は、仮の共通鍵を払い出した時刻を記憶するようにしてもよい。また、データ記憶部２０７は、払い出した仮の共通鍵を記憶するようにしてもよい。
次に、ＩｏＴデバイス３００の構成について説明する。図５は、実施の形態１に係るＩｏＴデバイスの構成を示すブロック図である。図５において、ＩｏＴデバイス３００は、通信部３０１と、仮の共通鍵処理部３０２と、認証情報設定処理部３０３と、固有識別子３０４と、データ記憶部３０５とを備える。
通信部３０１は、スマートデバイス１００及びゲートウェイ４００と通信を行う通信部である。例えば、通信部３０１は、無線通信回路で構成されてもよい。具体的には、ＢＬＥ（Bluetooth（登録商標） Low Energy）などの近距離無線通信機能を有する無線通信回路で構成されてもよい。
仮の共通鍵処理部３０２は、通信可能なスマートデバイス１００に対して接続要求の処理を行う。また、仮の共通鍵処理部３０２は、スマートデバイス１００から仮の共通鍵を受け取る処理を行う。
認証情報設定処理部３０３は、仮の共通鍵を用いてサーバ２００と認証情報の受け渡しの処理を行う。また、認証情報設定処理部３０３は、認証情報の設定処理を行う。
固有識別子記憶部３０４は、個々のＩｏＴデバイス３００を区別するための固有の識別子を記憶する。
データ記憶部３０５は、スマートデバイス１００から受け取った仮の共通鍵を記憶する。また、データ記憶部３０５は、認証情報を記憶する。
次に、ゲートウェイ４００の構成について説明する。図６は、実施の形態１に係るゲートウェイの構成を示すブロック図である。図６において、ゲートウェイ４００は、通信部４０１と、通信部４０２と、データ変換処理部４０３と、データ変換処理部４０４とを備える。
通信部４０１は、ＩｏＴデバイス３００と通信を行う通信部である。例えば、通信部４０１は、無線通信回路で構成されてもよい。
通信部４０２は、サーバ２００と通信を行う通信部である。例えば、通信部４０１は、無線通信回路で構成されてもよい。
データ変換処理部４０３は、ＩｏＴデバイス３００から送信されたデータをサーバ２００との通信に適したデータに変換する。変換されたデータは、通信部４０２から送信される。
データ変換処理部４０４は、サーバ２００から送信されたデータをＩｏＴデバイス３００との通信に適したデータに変換する。変換されたデータは、通信部４０１から送信される。
以上の構成により、ＩｏＴデバイス３００の持つ通信装置の都合でサーバ２００に直接接続できない場合に、ゲートウェイ４００とのデータ通信を仲介してＩｏＴデバイスとサーバ間のデータ通信を実現する。
これらスマートデバイス１００、サーバ２００及びＩｏＴデバイス３００（必要に応じてゲートウェイ４００）の構成により、データ通信システム１０は、認証処理及び認証情報の受け渡しを行う。次に、データ通信システム１０の動作について説明する。図７は、実施の形態１に係るデータ通信システムの認証処理の一例を示すシーケンス図である。図７では、仮の共通鍵を使用したＩｏＴデバイス３００の認証が行われる。
前提として、ＩｏＴデバイス３００は、個々のＩｏＴデバイス３００を識別するための固有識別子を持っており、サーバ２００は、各ＩｏＴデバイス３００の固有識別子と固有識別子に対応する認証情報を予め記憶している。また、サーバ２００は、各ＩｏＴデバイス３００に対して認証情報を設定したかどうかの状態を管理している。
スマートデバイス１００とＩｏＴデバイス３００間の通信経路にて、仮の共通鍵の受け渡しを行い、仮の共通鍵を使用してメッセージ認証符号を用いてＩｏＴデバイス３００の認証を行う。ここで言う認証は、サーバが払い出した仮の共通鍵が認証情報の設定対象のＩｏＴデバイス３００に正しく設定されたことの確認を意味する。
認証処理は以下の手順で行われる。まず、図７において、まずＩｏＴデバイス３００は、スマートデバイス１００に接続要求と固有識別子（以下、「ＩｏＴデバイスＩＤ」という）を送信する（Ｓ１０１）。
次に、スマートデバイス１００は、ＩｏＴデバイス３００からの接続要求を受けてＩｏＴデバイス３００と接続を確立する（Ｓ１０２）。そして、スマートデバイス１００は、スマートデバイス１００から接続先のＩｏＴデバイス３００の選択と確認を行うことでＩｏＴデバイス３００のなりすましが防止される。
スマートデバイス１００とＩｏＴデバイス３００の接続が確立した後、スマートデバイス１００は、操作対象のＩｏＴデバイス３００に設定する仮の共通鍵をサーバ２００に要求する（Ｓ１０３）。
サーバ２００は、スマートデバイス１００の認証を行う。この認証は、例えばユーザ名とパスワードによるアクセス制限である。このように認証は、Ｂａｓｉｃ認証などの適用を想定しているが、認証の方法に特に制限はなく、不特定多数の第三者が任意に仮の共通鍵の発行の要求が行えない仕組みであればどのような仕組みでも良い。（Ｓ１０４）。
サーバ２００は、スマートデバイス１００から指定されたＩｏＴデバイス３００に設定する仮の共通鍵を公開鍵暗号方式の公開鍵としてＩｏＴデバイス３００ごとに生成する（Ｓ１０５）。
サーバ２００は、生成した仮の共通鍵をスマートデバイス１００に送信する（Ｓ１０６）。
スマートデバイス１００は、受信した仮の共通鍵をＩｏＴデバイス３００に送信する（Ｓ１０７）。
ＩｏＴデバイス３００は、乱数１を生成する。そしてＩｏＴデバイス３００は、乱数１と仮の共通鍵を用いてメッセージ認証符号を生成する（Ｓ１０８）。
ＩｏＴデバイス３００は、サーバ２００とＩｏＴデバイス３００の通信経路にて、乱数１とメッセージ認証符号をサーバ２００に送信する（Ｓ１０９）。
サーバ２００は、スマートデバイス１００に払い出した仮の共通鍵とＩｏＴデバイス３００から受信した乱数１を使用してメッセージ認証符号を生成する。そして、サーバ２００は、生成したメッセージ認証符号とＩｏＴデバイス３００から受信したメッセージ認証符号とを比較する（Ｓ１１０）。
メッセージ認証符号の比較結果をＩｏＴデバイス３００に通知する（Ｓ１１１）。生成したメッセージ認証符号とＩｏＴデバイス３００から受信したメッセージ認証符号とが一致すれば、通信相手のＩｏＴデバイス３００は、Ｓ１０１からＳ１０７の手順で仮の共通鍵を設定したＩｏＴデバイス３００であることが保証される。
なお、図７のＳ１０１〜Ｓ１０３の手順の説明では、ＩｏＴデバイス３００を識別するためのＩｏＴデバイスＩＤは、予めＩｏＴデバイス３００が保持しているものとしているが、スマートデバイス１００からＩｏＴデバイス３００に設定されたＩＤであっても良い。
また、図７では、ＩｏＴデバイス３００からスマートデバイス１００に接続の要求を行っているが、逆にスマートデバイス１００からＩｏＴデバイス３００に対して接続の要求を行っても良い。そして、ＩｏＴデバイス３００とスマートデバイス１００間で使用する通信方式に応じて適切な方法を選択して、最終的に、ＩｏＴデバイス３００にＩｏＴデバイスＩＤが割り当てられても良い。
以上の動作により、認証処理が行われる。認証処理の後では、ＩｏＴデバイス３００が仮の共通鍵として渡されたサーバ２００の公開鍵を保有している。そして、サーバ２００は、この公開鍵と対になる秘密鍵を持っている。これらの公開鍵と秘密鍵の鍵を用い、公開鍵暗号方式でサーバ２００とＩｏＴデバイス３００の間で認証情報の受け渡しが行われる。次に認証情報の受け渡しについて説明する。図８は、実施の形態１に係るデータ通信システムの認証情報の受け渡しの一例を示すシーケンス図である。
認証情報の受け渡し処理は以下の手順で行われる。図８において、まずＩｏＴデバイス３００は、乱数２を生成する。そして、ＩｏＴデバイス３００は、仮の共通鍵を公開鍵暗号方式の暗号鍵として用い、乱数２を暗号化する（Ｓ２０１）。
次に、ＩｏＴデバイス３００は、暗号化したデータ（以下、暗号化データ１）をサーバ２００に送信する（Ｓ２０２）。
サーバ２００は、仮の共通鍵に対応する秘密鍵を用いて、受信した暗号化データ１を復号化する。この結果、サーバ２００は、乱数２を取得することができる（Ｓ２０３）。
サーバ２００は、認証情報を乱数２で暗号化する（Ｓ２０４）。
サーバ２００は、暗号化したデータ（以下、暗号化データ２という）をＩｏＴデバイス３００に送信する（Ｓ２０５）。
ＩｏＴデバイス３００は、受信した暗号化データ２を乱数２で復号化することにより、認証情報を取得する（Ｓ２０６）。
以上の動作により、サーバ２００とＩｏＴデバイス３００間でサーバの発行する認証情報の共有が完了する。
なお、図８のＳ２０１〜Ｓ２０６において、所謂ハイブリッド暗号方式という手法が使われている。サーバ２００からＩｏＴデバイス３００に認証情報を送信する際に、サーバ２００が持つ秘密鍵で認証情報を暗号化して送信すると、ＩｏＴデバイス３００が持つ公開鍵で復号が可能になる。ＩｏＴデバイス３００が持つ公開鍵は仮の共通鍵としてスマートデバイス１００から送信されたものであるので、仮の共通鍵がスマートデバイス１００から流出した場合、認証情報が復号できてしまう。そのことを防止するためにハイブリッド暗号方式を使用することが好ましい。
以上の手順を実行することにより、認証情報の安全性を高めることができる。具体的には、以下のような理由により認証情報の安全性を高めることができる。
１．サーバ２００とＩｏＴデバイス３００以外の機器に認証情報が渡らない。
２．Ｓ２０１〜Ｓ２０６の手順でＩｏＴデバイス３００のなりすましの防止が行われているため、Ｓ２０１〜Ｓ２０６の手順実施中の場でなりすましを行おうとしている偽のＩｏＴデバイスに認証情報は設定されない。
３．仮の共通鍵は、不特定多数人が任意にサーバ２００から取得できるものではなく、サーバ２００のユーザ名とパスワードなとの認証情報を知り得ない限り取得することができない。
４．仮にスマートデバイス１００から仮の共通鍵が流出した場合、サーバ２００は、既に設定処理済みの認証情報をＩｏＴデバイス３００に設定しないため、流出した仮の共通鍵を認証情報の設定に使用することはできない。
５．仮にスマートデバイス１００から仮の共通鍵が流出した場合で、流出した仮の共通鍵を使用して正規のＩｏＴデバイス３００に認証情報の設定が行われていない場合、仮の共通鍵はサーバ２００から払い出された後、予めサーバ２００に設定された時間を経過すると無効になるため、正規の手続きに要する必要最小限の時間を設定することで、仮の共通鍵の流出による不正な認証情報の設定処理は防止される。
６．認証情報は、サーバ２００とＩｏＴデバイス３００間において、ＩｏＴデバイス３００が生成した乱数と組み合わせて公開鍵暗号方式を用いて暗号化して渡されるため、サーバ２００とＩｏＴデバイス３００以外は認証情報を復号することができない。
このように、実施の形態１のデータ通信システムによれば、スマートデバイスが、認証情報を扱わずサーバから認証情報を設定するための仮の共通鍵の受け渡しのみを行うようにしたので、スマートデバイスを紛失しても、認証情報が流出する危険性が無くなる。
なお、仮の共通鍵を一時的に有効にする条件は、以下の条件を適用してもよい。また、以下の条件を複数または全て適用しても良い。
・仮の共通鍵は毎回異なるものを使用する。
・認証情報の受け渡しが完了したら、認証情報の受け渡しに使用した仮の共通鍵は無効にする。
・認証情報の受け渡しがある一定時間内に完了しない場合も、仮の共通鍵は無効にする。
このように、実施の形態１のデータ通信システムによれば、仮の共通鍵は毎回異なるものを使用し、認証情報の受け渡しが完了したら、認証情報の受け渡しに使用した仮の共通鍵を無効にすることにより、認証情報の受け渡し後に、悪意ある第三者にスマートデバイスが渡ったとしても、そこに格納されているのは既に無効となっている仮の共通鍵であり、セキュリティ上の問題は発生しない。
また、実施の形態１のデータ通信システムによれば、認証情報の受け渡しがある一定時間内に完了しない場合も、仮の共通鍵は無効にすることにより、認証情報の受け渡し前に、悪意ある第三者にスマートデバイスが渡ったとしても、そこに格納されている仮の共通鍵を何らかの手段で取り出すにはある程度の時間が必要であり、その間に仮の共通鍵は無効になるので、セキュリティ上の問題は発生しない。
（実施の形態２）
実施の形態２では、スマートデバイスがＩｏＴデバイスと通信可能になった場合に、通信可能となったＩｏＴデバイスを、認証処理を指示する対象として選択する例について説明する。
実施の形態２のスマートデバイスは、図３に示す実施の形態１のスマートデバイスと同様の構成であってもよい。また、図３のスマートデバイス１００からユーザインターフェイス１０３を省略したものであってもよい。
更に、通信部１０１は、ＩｏＴデバイス３００と通信を行うことが可能になった場合、通信可能になったＩｏＴデバイス３００を仮の共通鍵の設定処理部１０４に通知する。
仮の共通鍵の設定処理部１０４は、通信可能になったＩｏＴデバイス３００の認証を指示する処理を行う。指示内容は通信部１０２を介して送信される。
このように、実施の形態２のデータ通信システムによれば、スマートデバイスを操作対象のＩｏＴデバイスに近接させることで、操作対象のＩｏＴデバイスを明示的に指定することが可能になるので、スマートデバイスから接続先のＩｏＴデバイスの選択を行うためのユーザインターフェイスが不要にできる。
なお、通信部１０１は、近距離の無線通信に適した通信方式が望ましい。例えば、通信部１０１は、スマートデバイス１００とＩｏＴデバイス３００間のデータ通信に、ISO/IEC 14443, ISO/IEC 18092, ISO/IEC 15693, ISO/IEC 21481(NFC IP-2) などのNFC(Near Field Communication)を用いてもよい。
（実施の形態３）
実施の形態３では、サーバとＩｏＴデバイスが共有する認証情報が共通鍵の場合、仮の共通鍵によるＩｏＴデバイスの認証データとＩｏＴデバイスで生成した共通鍵を同時に送信することで、ＩｏＴデバイスの認証とＩｏＴデバイスとサーバ間での認証情報の共有を一度に行う例について説明する。図９は、実施の形態３に係るデータ通信システムの認証情報の受け渡しの一例を示すシーケンス図である。図９のシーケンス図は、図７のＳ１０８までの処理を行った後の処理を示すシーケンス図である。
認証情報の受け渡しは以下の手順で行われる。図９において、まずＩｏＴデバイス３００は、乱数１の生成と仮の共通鍵と乱数１からメッセージ認証符号を生成（以下、署名）し、乱数２を生成する。そして、ＩｏＴデバイス３００は、乱数２を仮の共通鍵を公開鍵暗号方式の公開鍵として使用して乱数２の暗号化（以下、暗号化データ１）を行う（Ｓ３０１）。
次に、ＩｏＴデバイス３００は、サーバ２００にＩｏＴデバイスＩＤと乱数１と署名と暗号化データ１を送信する（Ｓ３０２）。
サーバ２００は、仮の共通鍵と乱数１からメッセージ認証符号を生成してＩｏＴデバイス３００から受信した署名と比較する。生成したメッセージ認証符号と受信した署名が一致し場合、サーバ２００は、認証成功として仮の共通鍵に対応する秘密鍵を使用して暗号化データ１を復号化して乱数２を取得する。乱数２は、ＩｏＴデバイス３００とサーバ２００で共有する共通鍵である（Ｓ３０３）。
このように実施の形態３のデータ通信システムによれば、サーバからＩｏＴデバイス方向にはデータ通信を行わないシステムにおいても、認証を実行することができる。
なお、構築するシステムの仕様や各使用機器の制約条件に応じて、実施の形態３のデータ通信システムを適用することができる。例えば、ＩｏＴデバイスが、Bluetooth low energyを使用したビーコンをサーバに通知するシステムであり、サーバからＩｏＴデバイス方向にはデータ通信を行わないシステムにおいても、実施の形態３のデータ通信システムを適用することができる。
（実施の形態４）
実施の形態４では、ＩｏＴデバイスとサーバ間でデータ通信を行うシステムにおいて、ＩｏＴデバイスとサーバ間でやり取りするデータの共通鍵による暗号化と署名を行う仕組みを外部サービス化する例について説明する。図１０は、実施の形態４に係るデータ通信システムの構成を示すブロック図である。図１０において、データ通信システム２０は、スマートデバイス１００と、ＩｏＴデバイス３００と、ゲートウェイ４００と、サービスサーバ６００と、共通鍵管理サーバ７００とを備える。
実施の形態１との違いは、サーバ２００に相当する部分が、サービスサーバ６００と共通鍵管理サーバ７００の２つに分かれて構成されていることである。
図１１は、実施の形態４に係るサービスサーバの構成を示すブロック図である。図１１において、サービスサーバ６００は、通信部６０１と、データ管理部６０２と、データ処理部６０３と、データ記憶部６０４とを備える。
通信部６０１は、スマートデバイス１００、ゲートウェイ４００及び共通鍵管理サーバ７００とデータ通信を行う通信部である。
データ管理部６０２は、ＩｏＴデバイス３００から収集したデータを扱う。
データ処理部６０３は、暗号化されたデータを復号化するために共通鍵管理サーバ７００に処理を移譲する。
データ記憶部６０４は、ＩｏＴデバイス３００から収集したデータを記憶する。
図１２は、実施の形態４に係る共通鍵管理サーバの構成を示すブロック図である。図１２において、共通鍵管理サーバ７００は、通信部７０１と、アクセス制限管理部２０２と、仮の共通鍵管理部２０３と、仮の共通鍵設定処理部２０４と、認証情報管理部２０５と、認証情報設定処理部２０６と、データ記憶部２０７と、暗号化データ処理部７０２と、とを備える。
通信部７０１は、サービスサーバ６００と通信を行う通信部である。例えば、通信部７０１は、有線通信回路で構成されてもよい。
アクセス制限管理部２０２は、仮の共通鍵の払い出しは、ユーザ名とパスワードなどによる認証を要求する。仮の共通鍵は、個々のＩｏＴデバイス３００ごとに生成される。
仮の共通鍵管理部２０３は、データ記憶部２０７を参照して、個々のＩｏＴデバイス３００に設定する仮の共通鍵を管理する。
仮の共通鍵設定処理部２０４は、スマートデバイス１００からの要求により仮の共通鍵を払い出す。例えば、仮の共通鍵設定処理部２０４は、要求毎に異なる仮の共通鍵を生成するようにしてもよい。具体的には、仮の共通鍵設定処理部２０４は、仮の共通鍵管理部２０３に記憶された仮の共通鍵とは異なる仮の共通鍵を生成するようにしてもよい。
認証情報管理部２０５は、データ記憶部２０７を参照して、個々のＩｏＴデバイス３００に設定する認証情報を管理する。
認証情報設定処理部２０６は、ＩｏＴデバイス３００に認証情報を設定するか、否か判断する。
暗号化データ処理部７０２は、サービスサーバ６００からの要求によって、暗号化されたデータの復号化や署名の検証を行う。
データ記憶部２０７は、各種データを記憶する記憶部である。
次に、データ通信システム２０の動作について説明する。図１３は、実施の形態４に係るデータ通信システムの共通鍵管理の一例を示すシーケンス図である。
共通鍵管理は以下の手順で行われる。図１３において、まずＩｏＴデバイス３００と共通鍵管理サーバ７００の間で共通鍵を共有する。共通鍵の共有方法は実施の形態１の方法を使用する（Ｓ４０１）。
次に、ＩｏＴデバイス３００は、サービスサーバ６００に送信するデータを共通鍵で暗号化（以下、暗号化データ１）する。そして、ＩｏＴデバイス３００は、乱数１を生成共通鍵で暗号化したものを署名として、ＩｏＴデバイスＩＤと暗号化データ１と乱数１と署名をサービスサーバ６００に送信する（Ｓ４０２）。
ここで、ＩｏＴデバイス３００は、送信するデータを暗号化しているが、送信するデータの暗号化が不要であれば暗号化しなくても良い。乱数１と共通鍵を使用して生成したメッセージ認証符号で送信するデータになりすましと改ざんが行われていないことは保証される。
サービスサーバ６００は、受信したデータを共通鍵管理サーバ７００に送信する（Ｓ４０３）。
共通鍵管理サーバ７００は、ＩｏＴデバイスＩＤに対応する共通鍵を使用して署名を検証する。検証結果が正しければ認証成功として、暗号化データ１を共通鍵で復号化して（以下、復号化データ１）、サービスサーバ６００に送信する。サービスサーバ６００は、復号化データ１を受信する。復号化データ１は、ＩｏＴデバイス３００が送信した暗号化されていない平文データと同一である。
このように、実施の形態４のデータ通信システムによれば、サービスと、ＩｏＴデバイスとサーバ間でやり取りするデータの暗号化・復号化をそれぞれ独立した機能として分離することができる。
例えば、ＩｏＴデバイスに接続された温度センサーなどの値をサーバに集約して管理・分析するなどの通信システム本来の目的であるサービスと、ＩｏＴデバイスとサーバ間でやり取りするデータの暗号化・復号化を行うサービスをそれぞれ独立した機能として分離することができる。この結果、ＩｏＴデバイス３００とサービスサーバ６００の通信システムから独立した共通鍵管理機能として外部サービスとすることができる。
（実施の形態５）
実施の形態５では、認証情報を設定する前に、認可サーバに認証情報の設定対象のＩｏＴデバイスに認証情報を設定して良いか確認する。
図１４は、実施の形態５に係るデータ通信システムの構成を示すブロック図である。図１４において、データ通信システム３０は、スマートデバイス１００と、サーバ２００と、ＩｏＴデバイス３００と、ゲートウェイ４００と、認可サーバ８００と、認可判定機器９００とを備える。
図１５は、実施の形態５に係る認可サーバの構成を示すブロック図である。図１５において、認可サーバ８００は、通信部８０１と、認可判定処理部８０２と、データ記憶部８０３とを備える。
通信部８０１は、サーバ２００及び認可判定機器９００と通信を行う通信部である。
認可判定処理部８０２は、認証情報の設定対象のＩｏＴデバイス３００に認証情報を設定して良いか判定する。
データ記憶部８０３は、各種データを記憶する記憶部である。例えば、データ記憶部８０３は、認証情報の設定及び判断に必要な情報を記憶する。
図１６は、実施の形態５に係る認可判定機器の構成を示すブロック図である。図１６において、認可判定機器９００は、通信部９０１と、認可判定処理部９０２と、ユーザインターフェイス９０３と、データ記憶部９０４とを備える。
通信部９０１は、認可サーバ８００とデータ通信を行う通信部である。
認可判定処理部９０２は、認証情報の設定の可否を行う。具体的には、認可判定処理部９０２は、ユーザインターフェイス９０３が受け付けた指示に従い、認証情報の設定の可否を行う。
ユーザインターフェイス９０３は、操作する人からの指示を受け付けるインターフェイスである。また、ユーザインターフェイス９０３は、情報を表示するインターフェイスでもある。例えば、ユーザインターフェイス９０３は、タッチパネルで構成されてもよい。ユーザインターフェイス９０３は、認証情報の設定の可否を行うＩｏＴデバイス３００を表示し、当該ＩｏＴデバイス３００に認証情報の設定を行うか否かの指示を受け付ける。
データ記憶部９０４は、各種データを記憶する記憶部である。
以上の構成により、認可判定機器９００は、認可サーバ８００に認証情報の設定の可否を通知する。
認可サーバでの認証情報の設定可否の判断は、人、機械の種類を問わない。例えば、認証情報の設定可否の判断は以下の方法が考えられる。
・予め指定されたＰＣやスマートフォンに通知して、ユーザ（設定権限者）が判定
・仮の共通鍵を払い出してから一定の時間が経過したら拒否するなど、自動設定による判定
次に、認証情報の受け渡しの動作について説明する。図１７は、実施の形態５に係るデータ通信システムの認証情報の受け渡しの一例を示すシーケンス図である。
認証情報の受け渡し処理は以下の手順で行われる。まず図１７において、ＩｏＴデバイス３００は、乱数１を生成して乱数１と仮の共通鍵を使用してメッセージ認証符号を生成する。そして、ＩｏＴデバイス３００は、サーバ２００とＩｏＴデバイス３００間の通信経路にて、ＩｏＴデバイス３００の固有識別子と乱数１とメッセージ認証符号をサーバに送信する（Ｓ５０１）。
次に、サーバ２００は、スマートデバイス１００に払い出した仮の共通鍵を使用してＩｏＴデバイス３００から受信したメッセージ認証符号を検証する（Ｓ５０２）。
検証結果が正しい場合、サーバ２００は、認可サーバ８００に認証情報を設定して良いか問い合わせる（Ｓ５０３）。
認可サーバ８００は、予め設定された方法によってＩｏＴデバイスに認証情報を設定してよいか否か判定する。例えば、予め登録された認可判定機器９００に確認の通知要求を送信して認証情報を設定して良い否か確認を行う（Ｓ５０５）。また、認可判定機器９００での上述の確認の代わりに、仮の共通鍵を払い出してから一定の時間が経過したら拒否、特定のＩｏＴデバイスＩＤは拒否、時間帯によって拒否など、予め設定した条件で判定する方法としてもよい。
認可サーバ８００は、サーバ２００に認証情報の設定の可否を送信する（Ｓ１０６）。
サーバ２００は、認可サーバ８００から認証情報の設定の許可を受け取った場合は、認証情報の設定を行う（Ｓ５０７）。
サーバ２００は、サーバ２００から認証情報の設定の許可を受け取った場合は、認証情報の設定を行う（Ｓ５０８）。
このように、実施の形態５のデータ通信システムによれば、認証情報を設定する前に、認可サーバ８００に認証情報の設定対象のＩｏＴデバイス３００に認証情報を設定して良いか確認することにより、認証情報の漏洩防止を強化することができる。
また、実施の形態５のデータ通信システムによれば、認証情報の設定処理と認証情報の設計権限を分離することにより、認証情報の漏洩防止を強化することができる。
以上、本発明者によってなされた発明を実施の形態に基づき具体的に説明したが、本発明は既に述べた実施の形態に限定されるものではなく、その要旨を逸脱しない範囲において種々の変更が可能であることはいうまでもない。また、実施の形態１〜５は組み合わせてもよい。
１０、２０、３０ データ通信システム
１００ スマートデバイス
１０１、１０２、２０１、３０１、４０１、４０２、６０１、７０１、８０１、９０１ 通信部
１０３、９０３ ユーザインターフェイス
１０４ 設定処理部
２００ サーバ
２０２ アクセス制限管理部
２０３ 共通鍵管理部
２０４ 共通鍵設定処理部
２０５ 認証情報管理部
２０６、３０３ 認証情報設定処理部
２０７、３０５、６０４、８０３、９０４ データ記憶部
３００ ＩｏＴデバイス
３０２ 共通鍵処理部
３０４ 固有識別子記憶部
４００ ゲートウェイ
４０３、４０４ データ変換処理部
６００ サービスサーバ
６０２ データ管理部
６０３ データ処理部
７００ 共通鍵管理サーバ
７０２ 暗号化データ処理部
８００ 認可サーバ
８０２、９０２ 認可判定処理部
９００ 認可判定機器

Claims (15)

  1. ＩｏＴデバイスと、
    前記ＩｏＴデバイスと通信可能な情報処理装置と、
    前記ＩｏＴデバイス及び前記情報処理装置と通信可能なサーバとを備えるデータ通信システムであって、
    前記情報処理装置は、前記ＩｏＴデバイスからの接続要求を受信した場合に、一時的に有効な仮の共通鍵を前記サーバに要求し、
    前記サーバは、前記情報処理装置からの仮の共通鍵の要求を受信した場合に、仮の共通鍵を生成し、仮の共通鍵を前記情報処理装置に送信し、
    前記情報処理装置は、受信した仮の共通鍵を前記ＩｏＴデバイスに送信し、
    前記ＩｏＴデバイスと前記サーバは、当該仮の共通鍵を用いて、認証を行うデータ通信システム。
  2. 認証に成功した場合、仮の共通鍵を公開鍵として、サーバとＩｏＴデバイス間で公開鍵暗号方式を用いて認証情報の受け渡しを行う請求項１に記載のデータ通信システム。
  3. 前記サーバは、要求毎に異なる仮の共通鍵を生成する請求項１に記載のデータ通信システム。
  4. 前記サーバは、
    生成された仮の共通鍵を記憶する仮の共通鍵管理部と、
    前記仮の共通鍵管理部に記憶された仮の共通鍵とは異なる仮の共通鍵を生成する仮の共通鍵設定処理部と、を備える請求項２に記載のデータ通信システム。
  5. 前記サーバは、認証時に使用した後に、仮の共通鍵を無効とする請求項１に記載のデータ通信システム。
  6. 前記サーバは、
    認証に使用した後の仮の共通鍵のパターンを記憶する記憶部と、
    認証要求時の仮の共通鍵が、前記記憶部に記憶された仮の共通鍵と一致するか否か判断する仮の共通鍵管理部と、
    認証要求時の仮の共通鍵が、前記記憶部に記憶された仮の共通鍵と一致する場合、通信を拒否する通信部、を備える請求項５に記載のデータ通信システム。
  7. 前記サーバは、仮の共通鍵を生成してから所定の期間が経過した場合に、当該仮の共通鍵を無効とする請求項１に記載のデータ通信システム。
  8. 前記サーバは、
    仮の共通鍵と、当該仮の共通鍵を生成した時刻とを組み合わせて記憶する記憶部と、
    前記記憶部に基づいて、認証要求時の当該仮の共通鍵が、当該仮の共通鍵を生成した時刻から所定の期間を経過したか否か判断する仮の共通鍵管理部と、
    認証要求時の当該仮の共通鍵が、当該仮の共通鍵を生成した時刻から所定の期間を経過した場合、通信を拒否する通信部、を備える請求項７に記載のデータ通信システム。
  9. 前記サーバは、受信した認証要求の仮の共通鍵が、生成されていない仮の共通鍵のパターンである場合、を無効とする請求項１に記載のデータ通信システム。
  10. 前記サーバは、
    生成された仮の共通鍵を記憶する記憶部と、
    前記記憶部に基づいて、受信した認証要求の仮の共通鍵が生成された仮の共通鍵と一致するか否か判断する仮の共通鍵管理部と、
    受信した認証要求の仮の共通鍵が、既に生成された仮の共通鍵と一致しない場合、通信を拒否する通信部、を備える請求項９に記載のデータ通信システム。
  11. 前記情報処理装置は、前記ＩｏＴデバイスの選択を受け付けるユーザインターフェイスと、前記ＩｏＴデバイスと通信可能な通信部を有する請求項１に記載のデータ通信システム。
  12. 前記情報処理装置は、前記ＩｏＴデバイスと通信可能な通信部を有し、
    前記通信部は、前記ＩｏＴデバイスと通信可能になった場合に、前記ＩｏＴデバイスのための共通鍵を前記サーバに要求する請求項１に記載のデータ通信システム。
  13. 前記ＩｏＴデバイスは、共通鍵と暗号化データとを同時に前記サーバに送信し、
    前記サーバは、前記共通鍵に基づいて認証が成功しているか否か確認し、認証が成功している場合、暗号化データを復号化する請求項１に記載のデータ通信システム。
  14. 前記データ通信システムは、前記サーバと通信可能な認可サーバと、
    前記認可サーバと通信可能な認可判定機器を備え、
    前記認可サーバは、認証を要求されたＩｏＴデバイスを前記認可判定機器に通知し、
    前記認可判定機器は、認証を許可するか否かの指示を受け付け、指示内容を前記認可サーバに送信し、
    前記認可サーバは、前記認可判定機器の指示に従って、ＩｏＴデバイスの認証を許可または拒否する請求項１に記載のデータ通信システム。
  15. ＩｏＴデバイスと、
    前記ＩｏＴデバイスと通信可能な情報処理装置と、
    前記ＩｏＴデバイス及び前記情報処理装置と通信可能なサービスサーバと、
    前記サービスサーバと通信可能な共通鍵管理サーバとを備えるデータ通信システムであって、
    前記情報処理装置は、前記ＩｏＴデバイスからの接続要求を受信した場合に、一時的に有効な仮の共通鍵を前記共通鍵管理サーバに要求し、
    前記共通鍵管理サーバは、前記情報処理装置からの仮の共通鍵の要求を受信した場合に、仮の共通鍵を生成し、仮の共通鍵を前記情報処理装置に送信し、
    前記情報処理装置は、受信した仮の共通鍵を前記ＩｏＴデバイスに送信し、
    前記ＩｏＴデバイスと前記共通鍵管理サーバは、当該仮の共通鍵を用いて、認証を行い、
    前記サービスサーバは、認証が行われたＩｏＴデバイスに通信サービスを提供するデータ通信システム。
JP2018108639A 2018-06-06 2018-06-06 データ通信システム Pending JP2019213085A (ja)

Priority Applications (2)

Application Number Priority Date Filing Date Title
JP2018108639A JP2019213085A (ja) 2018-06-06 2018-06-06 データ通信システム
US16/409,424 US11178137B2 (en) 2018-06-06 2019-05-10 System for IoT devices communicating with server using a tentative common key

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
JP2018108639A JP2019213085A (ja) 2018-06-06 2018-06-06 データ通信システム

Publications (1)

Publication Number Publication Date
JP2019213085A true JP2019213085A (ja) 2019-12-12

Family

ID=68764343

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2018108639A Pending JP2019213085A (ja) 2018-06-06 2018-06-06 データ通信システム

Country Status (2)

Country Link
US (1) US11178137B2 (ja)
JP (1) JP2019213085A (ja)

Families Citing this family (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US11374918B2 (en) * 2017-09-29 2022-06-28 Interdigital Ce Patent Holdings Smart gateway enabled low cost smart building solution
JP7262964B2 (ja) * 2018-10-12 2023-04-24 株式会社東芝 情報処理装置、及び情報処理システム

Family Cites Families (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US9503437B2 (en) * 2014-12-12 2016-11-22 Gn Resound A/S Apparatus for secure hearing device communication and related method
EP3286871B1 (en) * 2015-04-24 2020-07-22 PCMS Holdings, Inc. Systems, methods, and devices for device credential protection
CN110176987B (zh) * 2016-02-02 2022-08-09 斑马智行网络(香港)有限公司 一种设备认证的方法、装置、设备和计算机存储介质
CN108156126B (zh) * 2016-12-02 2020-12-08 阿里巴巴集团控股有限公司 物联网设备的烧录校验方法及装置、身份认证方法及装置
US10943005B2 (en) * 2017-11-22 2021-03-09 Aeris Communications, Inc. Secure authentication of devices for internet of things
US10587400B2 (en) * 2018-02-12 2020-03-10 Afero, Inc. System and method for securely configuring a new device with network credentials
US20190313246A1 (en) * 2018-04-06 2019-10-10 Iot And M2M Technologies, Llc Device default wifi credentials for simplified and secure configuration of networked transducers

Also Published As

Publication number Publication date
US11178137B2 (en) 2021-11-16
US20190379655A1 (en) 2019-12-12

Similar Documents

Publication Publication Date Title
JP6382272B2 (ja) ある装置を使用して別の装置をアンロックする方法
CN111049660B (zh) 证书分发方法、***、装置及设备、存储介质
JP6586446B2 (ja) 通信端末および関連システムのユーザーの識別情報を確認するための方法
CN104798083B (zh) 用于验证访问请求的方法和***
US11245526B2 (en) Full-duplex password-less authentication
KR101706117B1 (ko) 휴대용 단말기에서 다른 휴대용 단말기를 인증하는 장치 및 방법
EP2879421B1 (en) Terminal identity verification and service authentication method, system, and terminal
KR20160129839A (ko) 블루투스 인터페이스를 갖는 인증 장치
CN104115464A (zh) 控制访问
US20220116385A1 (en) Full-Duplex Password-less Authentication
JP7135569B2 (ja) 端末登録システムおよび端末登録方法
US20180176223A1 (en) Use of Personal Device for Convenient and Secure Authentication
JP2017152880A (ja) 認証システム、鍵処理連携方法、および、鍵処理連携プログラム
US20210256102A1 (en) Remote biometric identification
KR20180028351A (ko) 신뢰된 실행 환경 기반의 사용자 단말을 이용한 무선 도어키 공유 서비스 방법 및 시스템
JP2018148463A (ja) 認証システム、認証情報生成装置、被認証装置及び認証装置
US11178137B2 (en) System for IoT devices communicating with server using a tentative common key
KR101745482B1 (ko) 스마트홈 시스템에서의 통신 방법 및 그 장치
KR20150005789A (ko) 인증서를 이용한 사용자 인증 방법
JP2017139026A (ja) 信頼できる認証およびログオンのための方法および装置
KR101451163B1 (ko) 무선 네트워크 접속 인증 방법 및 그 시스템
KR20170111809A (ko) 대칭키 기반의 보안 토큰을 이용한 양방향 인증 방법
JP2015111440A (ja) 信頼できる認証およびログオンのための方法および装置
KR101645414B1 (ko) 클라이언트 단말 장치 및 클라이언트 단말 장치가 모바일 서비스 서버에 접속하기 위한 방법
KR101298216B1 (ko) 복수 카테고리 인증 시스템 및 방법