図面 (/)

技術 周辺機器、無線通信チップ、アプリケーションプログラム、情報処理システム、および情報処理方法

出願人 任天堂株式会社
発明者 児島陽平黒田良治白井達広和田純平
出願日 2015年10月5日 (5年4ヶ月経過) 出願番号 2015-197851
公開日 2017年4月13日 (3年10ヶ月経過) 公開番号 2017-073609
状態 特許登録済
技術分野 オンライン・システムの機密保護 暗号化・復号化装置及び秘密通信
主要キーワード 粗悪品 動作確認済み 無線通信チップ ブルートゥースチップ 専用アプリ 送信主体 スマートデバイス 体調管理
関連する未来課題
重要な関連分野

この項目の情報は公開日時点(2017年4月13日)のものです。
また、この項目は機械的に抽出しているため、正しく解析できていない場合があります

図面 (20)

課題

周辺機器情報処理機器で用いようとする際に、その周辺機器を認証できるシステム等を提供すること。

解決手段

第1通信部は、暗号化キーと、周辺機器を一意に特定可能な特定情報と、当該特定情報の署名情報とを認証用サーバに送信する。第2通信部は、第1通信部で送信した特定情報および署名情報に基づいて認証用のサーバで行なわれた認証処理に基づくデータを受信した後、第2データの送信要求情報を暗号化して認証用のサーバに送信する。第3通信部は、第2通信部で送信した要求情報に応じて認証用のサーバから送信される暗号化された第2データを受信した後、これを復号化して認証用サーバに送信する。通信処理実行部は、第3通信部で送信した第2データの正当性が認証用のサーバで確認された結果に基づく第3データを受信した後、所定の通信機器との間で暗号化通信を行う。

概要

背景

従来から、スマートフォン等の情報処理機器と、ブルートゥース(Bluetooth:登録商標)などの非接触型インターフェースを用いて接続可能な周辺機器が知られている(例えば、非特許文献1)。上記ブルートゥースの規格では、機器の種類ごとにプロトコルを定義したプロファイルと呼ばれるものが策定されている。通信しようとする機器同士が同じプロファイルを有していれば、そのプロファイルの機能を利用した通信が可能となっている。例えば、周辺機器がキーボードであれば、HID(Human Interface Device Profile)と呼ばれるプロファイルをお互いに有していれば、両者の間で接続を確立させ、キーボードを用いて情報処理機器へ文字入力等が可能となる。また、例えば周辺機器がヘッドフォンであれば、A2DP(Advanced Audio Distribution Profile)と呼ばれるプロファイルをお互いに有していれば、両者の間で接続を確立させ、情報処理機器からヘッドフォンに音声伝送することができる。

概要

周辺機器を情報処理機器で用いようとする際に、その周辺機器を認証できるシステム等を提供すること。第1通信部は、暗号化キーと、周辺機器を一意に特定可能な特定情報と、当該特定情報の署名情報とを認証用サーバに送信する。第2通信部は、第1通信部で送信した特定情報および署名情報に基づいて認証用のサーバで行なわれた認証処理に基づくデータを受信した後、第2データの送信要求情報を暗号化して認証用のサーバに送信する。第3通信部は、第2通信部で送信した要求情報に応じて認証用のサーバから送信される暗号化された第2データを受信した後、これを復号化して認証用サーバに送信する。通信処理実行部は、第3通信部で送信した第2データの正当性が認証用のサーバで確認された結果に基づく第3データを受信した後、所定の通信機器との間で暗号化通信を行う。

目的

本発明の目的は、上記のような周辺機器を情報処理機器で用いようとする際に、その周辺機器を認証できるシステム等を提供する

効果

実績

技術文献被引用数
0件
牽制数
0件

この技術が所属する分野

ライセンス契約や譲渡などの可能性がある特許掲載中! 開放特許随時追加・更新中 詳しくはこちら

請求項1

所定の通信機器との間でデータ通信が可能な周辺機器であって、暗号化通信のための暗号化キーと、前記周辺機器を一意に特定可能な情報である特定情報と、当該特定情報のデジタル署名である署名情報とを認証用サーバに送信するための第1通信部と、前記第1通信部で送信した特定情報及び署名情報に基づいて前記認証用のサーバで行なわれた認証処理の結果に基づくデータである第1データを当該認証用のサーバから受信した後、第2データの送信要求を示す要求情報を前記暗号化キーで暗号化し、当該認証用のサーバに送信する第2通信部と、前記第2通信部で送信した要求情報に応じて前記認証用のサーバから送信される暗号化された前記第2データを受信した後、前記暗号化キーを用いて当該暗号化された第2データを復号化し、当該復号化した第2データを当該認証用サーバに送信する第3通信部と、前記第3通信部で送信した第2データの正当性が前記認証用のサーバにおいて確認された結果に基づくデータである第3データを当該認証用のサーバから受信した後、前記所定の通信機器との間で、前記暗号化キーで暗号化した第4データを用いた通信処理を実行する通信処理実行部、とを備える、周辺機器。

請求項2

前記第2データとして、乱数が用いられる、請求項1に記載の周辺機器。

請求項3

前記周辺機器は、一旦接続が確立した実績のある所定の通信機器と再接続する際に用いる情報であるボンディング情報を、その有効期限を設定したうえで記憶部に記憶する記憶部と前記所定の通信機器との通信の際に、前記有効期限が経過しているか否かを判定する期限判定部とを更に備え、前記期限判定部によって前記有効期限を経過していると判定されたとき、前記第1送信部、第2送信部、第3送信部による処理を再度実行した後に、前記通信処理実行部による通信処理を実行する、請求項1または2に記載の周辺機器。

請求項4

ブルートゥース通信が可能な無線通信チップであって、所定の通信機器とのブルートゥース通信が許可される期限である有効期限の情報を記憶する有効期限情報記憶部を備える、無線通信チップ。

請求項5

前記有効期限の情報は、日付けを示す情報である、請求項4に記載の無線通信チップ。

請求項6

前記有効期限の情報は、所定の回数カウントするためのカウンタである、請求項4に記載の無線通信チップ。

請求項7

所定の通信機器との間でデータ通信が可能な周辺機器であって、前記所定の通信機器と近距離無線通信で接続する接続部と、前記接続部によって一旦接続が確立した前記所定の通信機器と再接続する際に用いる情報であるボンディング情報を記憶部に記憶するボンディング情報記憶部と、周辺機器と所定の認証用サーバとの間で行なわれた、当該周辺機器を認証するための認証処理の結果に基づき、前記ボンディング情報の有効期限を示す有効期限情報を前記記憶部に記憶する有効期限記憶部と、前記所定の通信機器との通信の際に、前記有効期限が経過しているか否かを判定する期限判定部と、前記有効期限を経過していると判定されたとき、前記所定の認証用サーバを用いる認証処理を再度実行する再認証部とを備える、周辺機器。

請求項8

前記周辺機器は、前記所定の通信機器との間の通信をブルートゥース登録商標)通信によって行なう、請求項1、2、7のいずれかに記載の周辺機器。

請求項9

通信可能に接続された所定の周辺機器を利用する所定の通信機器のコンピュータに実行させるアプリケーションプログラムであって、アプリケーションIDの送信要求を前記周辺機器から受信する要求受信手段と前記送信要求に応じて、起動中のアプリケーションプログラムのアプリケーションIDを前記周辺機器に送信するID送信手段と、前記周辺機器における前記アプリケーションIDの検証が成功した場合に、当該周辺機器との通信処理を伴う所定の処理を実行する処理実行手段、として前記コンピュータを機能させる、アプリケーションプログラム。

請求項10

所定のサーバと通信可能に接続された所定の通信機器のコンピュータに実行させるアプリケーションプログラムであって、アプリケーションIDの送信要求を前記サーバから受信する要求受信手段と、前記送信要求に応じて、起動中のアプリケーションプログラムのアプリケーションIDを前記サーバに送信するID送信手段と、所定の周辺機器との通信処理を伴う所定の処理を実行する処理実行手段、として前記コンピュータを機能させ、前記ID送信手段によるアプリケーションIDの送信の後、前記サーバにおける当該アプリケーションIDの検証が成功した場合に、前記所定の周辺機器との通信処理を伴う所定の処理の実行が許可される、アプリケーションプログラム。

請求項11

前記アプリケーションIDは、アプリケーション毎固有のIDである、請求項9または10に記載のアプリケーションプログラム。

請求項12

所定のサーバと通信可能に接続された所定の通信機器のコンピュータに実行させるアプリケーションプログラムであって、クライアント証明書の送信要求を前記サーバから受信する要求受信手段と、前記送信要求に応じて、前記所定の通信機器の記憶部に記憶されているクライアント証明書を前記サーバに送信する証明書送信手段と、所定の周辺機器との通信処理を伴う所定の処理を実行する処理実行手段、として前記コンピュータを機能させ、前記証明書送信手段によるクライアント証明書の送信の後、前記サーバにおける当該クライアント証明書の正当性の検証が成功した場合に、前記所定の周辺機器との通信処理を伴う所定の処理の実行が許可される、アプリケーションプログラム。

請求項13

サーバと、所定の通信機器と、当該所定の通信機器との間でデータ通信が可能な周辺機器とを備える情報処理システムであって、前記周辺機器は、暗号化通信のための暗号化キーと、前記周辺機器を一意に特定可能な情報である特定情報と、当該特定情報のデジタル署名である署名情報とを前記サーバに送信するための第1通信部と、前記第1通信部で送信した特定情報及び署名情報に基づいて前記サーバで行なわれた認証処理の結果に基づくデータである第1データを当該サーバから受信した後、第2データの送信要求を示す要求情報を前記暗号化キーで暗号化し、当該サーバに送信する第2通信部と、前記第2通信部で送信した要求情報に応じて前記サーバから送信される暗号化された前記第2データを受信した後、前記暗号化キーを用いて当該暗号化された第2データを復号化し、当該復号化した第2データを当該サーバに送信する第3通信部と、前記第3通信部で送信した第2データの正当性が前記サーバにおいて確認された結果に基づくデータである第3データを当該サーバから受信した後、前記所定の通信機器との間で、前記暗号化キーで暗号化した第4データを用いた通信処理を実行する通信処理実行部とを備え、前記サーバは、前記第1通信部から送信された前記特定情報及び署名情報に基づいて前記周辺機器に関する認証処理を行う認証処理部と、当該認証処理の結果に基づく前記第1データを前記周辺機器に送信する第1データ送信部と、前記第2通信部から送信された要求情報に応じて、前記暗号化キーを用いて前記第2データを暗号化して前記周辺機器に送信する第2データ送信部と、前記第3通信部から送信された前記第2データの正当性を確認し、その結果に基づく前記第3データを前記周辺機器に送信する第3データ送信部とを備え、前記周辺機器と前記サーバとの間のデータの送受信は、前記所定の通信機器を経由して行われる、情報処理システム。

請求項14

前記周辺機器および前記認証用のサーバの間で行なわれるデータは、暗号化されて送受信される、請求項13に記載の情報処理システム。

請求項15

前記周辺機器は、第5データを共通鍵で暗号化して前記サーバに送信する暗号データ送信部と、前記サーバで復号化された第5データを当該サーバから受信する復号化データ受信部と、前記暗号化する前の第5データと、前記復号化データ受信部で受信した第5データが一致するか否かを判定することにより、前記サーバの正当性を判定する判定部とを更に備え、前記サーバは、前記暗号データ送信部から送られた前記暗号化された第5データを復号化し、送信元の前記周辺機器に当該復号化した第5データを送信するデータ復号化部を更に備える、請求項13に記載の情報処理システム。

請求項16

所定の通信機器との間でデータ通信が可能な周辺機器を制御するための情報処理方法であって、暗号化通信のための暗号化キーと、前記周辺機器を一意に特定可能な情報である特定情報と、当該特定情報のデジタル署名である署名情報とを認証用のサーバに送信するための第1通信ステップと、前記第1通信ステップで送信した特定情報及び署名情報に基づいて前記認証用のサーバで行なわれた認証処理の結果に基づくデータである第1データを当該認証用のサーバから受信した後、第2データの送信要求を示す要求情報を前記暗号化キーで暗号化し、当該認証用のサーバに送信する第2通信ステップと、前記第2通信ステップで送信した要求情報に応じて前記認証用のサーバから送信される暗号化された前記第2データを受信した後、前記暗号化キーを用いて当該暗号化された第2データを復号化し、当該復号化した第2データを当該認証用サーバに送信する第3通信ステップと、前記第3通信ステップで送信した第2データの正当性が前記認証用のサーバにおいて確認された結果に基づくデータである第3データを当該認証用のサーバから受信した後、前記所定の通信機器との間で、前記暗号化キーで暗号化した第4データを用いた通信処理を実行する通信処理実行ステップ、とを有する、情報処理方法。

請求項17

所定の通信機器との間でデータ通信が可能な周辺機器を制御するための情報処理方法であって、前記所定の通信機器と近距離無線通信で接続する接続ステップと、前記接続ステップによって一旦接続が確立した前記所定の通信機器と再接続する際に用いる情報であるボンディング情報を記憶部に記憶するボンディング情報記憶ステップと、周辺機器と所定の認証用サーバとの間で行なわれた、当該周辺機器を認証するための認証処理の結果に基づき、前記ボンディング情報の有効期限を示す有効期限情報を前記記憶部に記憶する有効期限記憶ステップと、前記所定の通信機器との通信の際に、前記有効期限が経過しているか否かを判定する期限判定ステップと、前記有効期限を経過していると判定されたとき、前記所定の認証用サーバを用いる認証処理を再度実行する再認証ステップとを有する、情報処理方法。

請求項18

通信可能に接続された所定の周辺機器を利用する所定の通信機器のコンピュータを制御するための情報処理方法あって、アプリケーションIDの送信要求を前記周辺機器から受信する要求受信ステップと、前記送信要求に応じて、起動中のアプリケーションプログラムのアプリケーションIDを前記周辺機器に送信するID送信ステップと、前記周辺機器における前記アプリケーションIDの検証が成功した場合に、当該周辺機器との通信処理を伴う所定の処理を実行する処理実行ステップと、を有する、情報処理方法。

請求項19

所定のサーバと通信可能に接続された所定の通信機器のコンピュータを制御するための情報処理方法であって、アプリケーションIDの送信要求を前記サーバから受信する要求受信ステップと、前記送信要求に応じて、起動中のアプリケーションプログラムのアプリケーションIDを前記サーバに送信するID送信ステップと、所定の周辺機器との通信処理を伴う所定の処理を実行する処理実行ステップ、とを有し、前記ID送信ステップにおけるアプリケーションIDの送信の後、前記サーバにおける当該アプリケーションIDの検証が成功した場合に、前記処理実行ステップにおける所定の処理の実行が許可される、情報処理方法。

請求項20

所定のサーバと通信可能に接続された所定の通信機器のコンピュータを制御するための情報処理方法であって、クライアント証明書の送信要求を前記サーバから受信する要求受信ステップと、前記送信要求に応じて、前記所定の通信機器の記憶部に記憶されているクライアント証明書を前記サーバに送信する証明書送信ステップと、所定の周辺機器との通信処理を伴う所定の処理を実行する処理実行ステップとを有し、前記証明書送信ステップにおけるクライアント証明書の送信の後、前記サーバにおける当該クライアント証明書の正当性の検証が成功した場合に、前記処理実行ステップにおける所定の処理の実行が許可される、情報処理方法。

技術分野

0001

本発明は、例えばスマートデバイス等の通信機器通信可能な周辺機器に関し、より特定的には、周辺機器の認証処理に関する。

背景技術

0002

従来から、スマートフォン等の情報処理機器と、ブルートゥース(Bluetooth:登録商標)などの非接触型インターフェースを用いて接続可能な周辺機器が知られている(例えば、非特許文献1)。上記ブルートゥースの規格では、機器の種類ごとにプロトコルを定義したプロファイルと呼ばれるものが策定されている。通信しようとする機器同士が同じプロファイルを有していれば、そのプロファイルの機能を利用した通信が可能となっている。例えば、周辺機器がキーボードであれば、HID(Human Interface Device Profile)と呼ばれるプロファイルをお互いに有していれば、両者の間で接続を確立させ、キーボードを用いて情報処理機器へ文字入力等が可能となる。また、例えば周辺機器がヘッドフォンであれば、A2DP(Advanced Audio Distribution Profile)と呼ばれるプロファイルをお互いに有していれば、両者の間で接続を確立させ、情報処理機器からヘッドフォンに音声伝送することができる。

先行技術

0003

任天堂株式会社、”ニンテンドーワイヤレスキーボードについて”、[online]、[平成27年5月20日検索]、インターネット(URL:http://www.nintendo.co.jp/ds/uzpj/keyboard/)

発明が解決しようとする課題

0004

ところで、従来の技術においては、上記のようなブルートゥースを用いる周辺機器を情報処理機器で用いようとする際に、当該周辺機器を認証するものではなかった。すなわち、上記のようなプロファイルを有していれば、どのような周辺機器でも接続して利用することが可能であった。

0005

それ故に、本発明の目的は、上記のような周辺機器を情報処理機器で用いようとする際に、その周辺機器を認証できるシステム等を提供することである。

課題を解決するための手段

0006

上記目的を達成するために、例えば以下のような構成例が挙げられる。

0007

構成例の一例は、所定の通信機器との間でデータ通信が可能な周辺機器であって、第1通信部と、第2通信部と、第3通信部と、通信処理実行部、とを備える。第1通信部は、暗号化通信のための暗号化キーと、周辺機器を一意に特定可能な情報である特定情報と、当該特定情報のデジタル署名である署名情報とを認証用サーバに送信する。第2通信部は、第1送信部で送信した特定情報および署名情報に基づいて認証用のサーバで行なわれた認証処理の結果に基づくデータである第1データを当該認証用のサーバから受信した後、第2データの送信要求を示す要求情報を暗号化キーで暗号化し、当該認証用のサーバに送信する。第3通信部は、第2通信部で送信した要求情報に応じて認証用のサーバから送信される暗号化された第2データを受信した後、暗号化キーを用いて当該暗号化された第2データを復号化し、当該復号化した第2データを当該認証用サーバに送信する。通信処理実行部は、第3通信部で送信した第2データの正当性が認証用のサーバにおいて確認された結果に基づくデータである第3データを当該認証用のサーバから受信した後、所定の通信機器との間で、前記暗号化キーで暗号化した第4データを用いた通信処理を実行する。

0008

上記構成例によれば、所定の通信機器から周辺機器を使用する際に、周辺機器の認証を行ってから、暗号化通信による通信処理を実行することでき、周辺機器の利用の安全性を高めることができる。

0009

更に他の構成例として、第2データとして、乱数が用いられるように構成しても良い。

0010

上記構成例によれば、認証処理の際の安全性をより高めることが可能となる。

0011

更に他の構成例として、周辺機器は、一旦接続が確立した所定の通信機器と再接続する際に用いる情報であるボンディング情報を、その有効期限を設定したうえで記憶部に記憶する記憶部と、所定の通信機器との通信の際に、有効期限が経過しているか否かを判定する期限判定部とを更に備えていてもよい。そして、期限判定部によって有効期限を経過していると判定されたとき、第1送信部、第2送信部、第3送信部による処理を再度実行した後に、通信処理実行部による通信処理を実行するようにしてもよい。

0012

上記構成例によれば、汎用性の高い無線通信規格を利用しつつ、周辺機器の定期的な認証処理も実行することができ、利便性を高めつつ、周辺機器の利用の安全性を確保することもできる。

0013

他の構成例の一例は、ブルートゥース通信が可能な無線通信チップであって、所定の通信機器とのブルートゥース通信が許可される期限である有効期限の情報を記憶する有効期限情報記憶部を備える。更に、有効期限の情報は、日付けを示す情報であってもよいし、あるいは、有効期限の情報は、所定の回数カウントするためのカウンタであってもよい。

0014

上記構成例によれば、所定の通信機器との間の通信について、その通信が許可される有効期限を設けることができ、有効期限外となったときに、例えば認証処理等の、通信を許可するための所定の処理を実行させることが可能となる。

0015

他の構成例の一例は、所定の通信機器との間でデータ通信が可能な周辺機器であって、接続部と、ボンディング情報記憶部と、有効期限記憶部と、期限判定部と、再認証部とを備える。接続部は、所定の通信機器と近距離無線通信で接続する。ボンディング情報記憶部は、接続部によって一旦接続が確立した所定の通信機器と再接続する際に用いる情報であるボンディング情報を記憶部に記憶する。有効期限記憶部は、周辺機器と所定の認証用サーバとの間で行なわれた、当該周辺機器を認証するための認証処理の結果に基づき、ボンディング情報の有効期限を示す有効期限情報を記憶部に記憶する。期限判定部は、所定の通信機器との通信の際に、有効期限が経過しているか否かを判定する。再認証部は、有効期限を経過していると判定されたとき、所定の認証用サーバを用いる再度の認証処理を実行する。

0016

上記構成例によれば、ボンディング情報に有効期限を設定することができ、これが有効期限外となったとき、再度の認証処理を行わせることができる。

0017

更に他の構成例として、周辺機器と前記所定の通信機器との間の通信は、ブルートゥース(登録商標)通信によって行なわれるようにしてもよい。

0018

上記構成例によれば、汎用性の高い無線通信規格を利用しつつ、周辺機器の定期的な認証処理も実行することができ、利便性を高めつつ、周辺機器の利用の安全性を確保することができる。

0019

他の構成例の一例は、通信可能に接続された所定の周辺機器を利用する所定の通信機器のコンピュータに実行させるアプリケーションプログラムであって、コンピュータを、要求受信手段と、ID送信手段と、処理実行手段として機能させる。要求受信手段は、アプリケーションIDの送信要求を前記周辺機器から受信する。ID送信手段は、送信要求に応じて、起動中のアプリケーションプログラムのアプリケーションIDを周辺機器に送信する。処理実行手段は、周辺機器におけるアプリケーションIDの検証が成功した場合に、当該周辺機器との通信処理を伴う所定の処理を実行する。なお、当該アプリケーションIDは、アプリケーション毎固有のIDであってもよい。

0020

上記構成例によれば、周辺機器の利用に際して、当該周辺機器の正当性を確認することができる、また、周辺機器側において、その通信相手となるアプリケーションの正当性確認を行わせることもできる。

0021

他の構成例の一例は、所定のサーバと通信可能に接続された所定の通信機器のコンピュータに実行させるアプリケーションプログラムであって、コンピュータを、要求受信手段と、ID送信手段と、処理実行手段、として機能させる。要求受信手段は、アプリケーションIDの送信要求をサーバから受信する。ID送信手段は、送信要求に応じて、起動中のアプリケーションプログラムのアプリケーションIDをサーバに送信する。処理実行手段は、所定の周辺機器との通信処理を伴う所定の処理を実行する。そして、ID送信手段によるアプリケーションIDの送信の後、サーバにおける当該アプリケーションIDの検証が成功した場合に、所定の周辺機器との通信処理を伴う所定の処理の実行が許可される。なお、当該アプリケーションIDは、アプリケーション毎に固有のIDであってもよい。

0022

上記構成例によれば、周辺機器の認証処理の際に、周辺機器の通信相手となるアプリケーションの正当性確認を行うことができる。

0023

他の構成例の一例は、所定のサーバと通信可能に接続された所定の通信機器のコンピュータに実行させるアプリケーションプログラムであって、コンピュータを、要求受信手段と、証明書送信手段と、処理実行手段として機能させる。要求受信手段は、クライアント証明書の送信要求をサーバから受信する。証明書送信手段と、送信要求に応じて、所定の通信機器の記憶部に記憶されているクライアント証明書をサーバに送信する。処理実行手段は、所定の周辺機器との通信処理を伴う所定の処理を実行する。そして、証明書送信手段によるクライアント証明書の送信の後、サーバにおける当該クライアント証明書の正当性の検証が成功した場合に、所定の周辺機器との通信処理を伴う所定の処理の実行が許可される。

0024

上記構成例によれば、周辺機器の利用に際して、その周辺機器の通信相手となる通信機器やアプリケーションプログラムの信頼性の高さを確認することができる。

0025

他の構成例の一例は、サーバと、所定の通信機器と、当該所定の通信機器との間でデータ通信が可能な周辺機器とを備える情報処理システムであって、周辺機器は、第1通信部と、第2通信部と、第3通信部と、通信処理実行部とを備える。第1通信部は、暗号化通信のための暗号化キーと、周辺機器を一意に特定可能な情報である特定情報と、当該特定情報のデジタル署名である署名情報とをサーバに送信する。第2通信部は、第1通信部で送信した特定情報及び署名情報に基づいてサーバで行なわれた認証処理の結果に基づくデータである第1データを当該サーバから受信した後、第2データの送信要求を示す要求情報を暗号化キーで暗号化し、当該サーバに送信する。第3通信部は、第2通信部で送信した要求情報に応じてサーバから送信される暗号化された第2データを受信した後、暗号化キーを用いて当該暗号化された第2データを復号化し、当該復号化した第2データを当該サーバに送信する。通信処理実行部は、第3通信部で送信した第2データの正当性がサーバにおいて確認された結果に基づくデータである第3データを当該サーバから受信した後、所定の通信機器との間で、暗号化キーで暗号化した第4データを用いた通信処理を実行する。
また、サーバは、認証処理部と、第1データ送信部と、第2データ送信部と、第3データ送信部とを備える。認証処理部は、第1通信部から送信された特定情報及び署名情報に基づいて周辺機器に関する認証処理を行う。第1データ送信部は、認証処理の結果に基づく第1データを周辺機器に送信する。第2データ送信部は、第2通信部から送信された要求情報に応じて、暗号化キーを用いて第2データを暗号化して周辺機器に送信する。第3データ送信部は、第3通信部から送信された第2データの正当性を確認し、その結果に基づく第3データを周辺機器に送信する。そして、周辺機器とサーバとの間のデータの送受信は、所定の通信機器を経由して行われる。

0026

上記構成例によれば、所定の通信機器から周辺機器を使用する際に、周辺機器の認証を行ってから、暗号化通信による通信処理を実行することでき、周辺機器の利用の安全性を高めることができ、更に、当該周辺機器の汎用性を高めることができる。

0027

更に他の構成例として、周辺機器および認証用のサーバの間で行なわれるデータは、暗号化されて送受信されるよう構成しても良い。また、周辺機器は、第5データを共通鍵で暗号化してサーバに送信する暗号データ送信部と、サーバで復号化された第5データを当該サーバから受信する復号化データ受信部と、暗号化する前の第5データと、復号化データ受信部で受信した第5データが一致するか否かを判定することにより、サーバの正当性を判定する判定部とを更に備え、サーバは、暗号データ送信部から送られた暗号化された第5データを復号化し、送信元の周辺機器に当該復号化した第5データを送信するデータ復号化部を更に備える構成としても良い。

0028

上記構成例によれば、周辺機器の認証処理について、より安全な認証処理を行うことができる。

発明の効果

0029

本実施形態によれば、周辺機器を使用する際に、当該周辺機器の認証処理を行い、認証されてから使用を許可することが可能となる。これにより、周辺機器の利用に際しての安全性を高めることができる。

図面の簡単な説明

0030

本実施形態における認証システム全体を示す模式図
認証サーバ100のハードウェア構成を示す模式図
スマートデバイス200のハードウェア構成を示す模式図
周辺機器300のハードウェア構成を示す模式図
認証サーバ100の記憶部102に記憶されるデータを示す図
アプリテーブル114の構成の一例
周辺機器300の不揮発メモリ303に記憶されるデータを示す図
拡張ボンディング情報316のデータ構成の一例
スマートデバイス200の記憶部204に記憶されるデータを示す図
第1の実施形態における認証処理の概要を説明するための図
第1の実施形態における第1フェーズ処理の詳細を示すフローチャート
第1の実施形態における第2フェーズ処理の詳細を示すフローチャート
第1の実施形態における第3フェーズ処理の詳細を示すフローチャート
第1の実施形態における第4フェーズ処理の詳細を示すフローチャート
第1の実施形態における第4フェーズ処理の詳細を示すフローチャート
第1の実施形態における第5フェーズ処理の詳細を示すフローチャート
第1の実施形態における第6フェーズ処理の詳細を示すフローチャート
第2の実施形態にかかる周辺機器400のハードウェア構成を示す模式図
第2の実施形態において認証サーバ100の記憶部102に記憶されるデータを示す図
周辺機器400のセキュアメモリ405に記憶されるデータを示す図
周辺機器400の不揮発メモリ403に記憶されるデータを示す図
第2の実施形態における認証処理の概要を説明するための図
第2の実施形態における第2フェーズ処理の詳細を示すフローチャート
第2の実施形態における第3フェーズ処理の詳細を示すフローチャート
第2の実施形態における第4フェーズ処理の詳細を示すフローチャート
第2の実施形態における第5フェーズ処理の詳細を示すフローチャート
第2の実施形態における第5フェーズ処理の詳細を示すフローチャート
第2の実施形態における第6フェーズ処理の詳細を示すフローチャート
第2の実施形態における第7フェーズ処理の詳細を示すフローチャート

実施例

0031

以下、本発明の実施形態について説明する。

0032

まず、本実施形態では、次のような利用の態様を想定している。まず、所定のサーバとの通信が可能な通信機器、具体的にはスマートフォンなどのスマートデバイスがあるとする。更に、当該スマートデバイスで利用可能な周辺機器があるとする。この周辺機器は、ブルートゥース(Bluetooth:登録商標)技術でスマートデバイスと接続可能であるとする。換言すれば、周辺機器はブルートゥースデバイスであるとする。また、当該スマートデバイスには、所定のアプリケーションがインストールされる。そして、上記周辺機器と連携させながら当該アプリケーションをユーザが利用する、というような場合を想定する。例えば、上記周辺機器は、体調管理フィットネスに関する機器であって、上記アプリケーションは、ユーザが当該周辺機器を利用した健康管理トレーニング等を行うことが可能なアプリケーションである。以下では、当該アプリケーションのことを「専用アプリ」と呼ぶ。

0033

上記のような専用アプリの利用に際しては、まず、上記周辺機器をスマートデバイスと接続して、当該アプリケーションから利用可能な状態とする必要がある。ここで、当該周辺機器に関しては、粗悪品等による使用感の低下等の防止や、所定の規格を満たすことによる安全性の確保(安全規格を満たさない周辺機器による事故防止等)という観点から、いわゆる「正規品純正品」や「動作確認済み」のものを利用することが好ましい。例えば上記専用アプリのメーカで動作確認がとれた周辺機器や、あるいは、上記専用アプリのメーカによって開発・販売されている周辺機器である。特に、専用アプリのメーカによって開発・販売されている周辺機器(いわゆる純正品)であれば、使用に際しての安全性は高いものと考えられる。

0034

このような観点から、本実施形態では、上記のような利用態様に際し、周辺機器として上記専用アプリのメーカによる「純正品」を利用する場合を想定する。例えば、メーカが、上記周辺機器および専用アプリをセットで提供するような場合を考える。そして、本実施形態で説明する技術は、上記専用アプリを利用する際に、当該専用アプリと連携して使用する上記のような周辺機器の正当性(例えば純正品であるか)を認証するための技術に関するものである。すなわち、専用アプリの実行開始に先立って、上記周辺機器が純正品であるか否かをチェックするという処理(周辺機器の認証処理)が本実施形態では行なわれる。

0035

ここで、上記のような周辺機器の認証処理を行なう場合、一般に、スマートデバイス上において認証処理を行うことが考えられる。しかし、昨今では、スマートデバイスは多種多様機種が存在しており、また、汎用的なデバイスであるともいえる。そのため、どのユーザがどのようなスマートデバイスを利用しているかを専用アプリのメーカ側で把握したり、予測したりすることは困難であるという側面がある。また、上記専用アプリが改ざんされたり、あるいは、他のアプリを介在させたりすることで周辺機器の認証が回避されるリスクも想定される。例えば、純正品ではない周辺機器が存在するとして、上記専用アプリが何らかの形で改ざんされる等し、上記のような認証処理が行なわれずに、純正品ではない周辺機器が用いられてしまうことも考えられる。

0036

そこで、本実施形態では、上記のような周辺機器の認証処理を、スマードデバイス側では行なわないようにしている。具体的には、認証用のサーバ(以下、認証サーバ)を用意し、スマートデバイス(専用アプリ)が中継する形で、周辺機器とサーバとの間における認証処理を行ない、周辺機器を専用アプリから利用可能な状態とするものである。また、本実施形態では、更に、専用アプリ自体の正当性をチェックする処理も実行される。

0037

なお、以下の説明では、「認証」という用語と「検証」という用語を用いる。以下の説明では、「認証」は、周辺機器の正当性を確認することを意図し、後述する一連のプロセスが該当する。すなわち、後述の一連の処理が「認証処理」に該当する。一方、「検証」は、後述の一連の認証プロセスにおいて適宜行なわれる処理を意図し、主にこの認証プロセスの間にやりとりされるデータの正当性をチェックする処理である。例えば受信した「証明書」の送信主体が、正しい送信主体であるのかの確証を得るために行なわれる処理である。

0038

(第1の実施形態)
以下、第1の実施形態を説明する。まず、第1の実施形態で想定する周辺機器認証システムの全体像について説明する。図1は、本実施形態における認証システム全体を示す模式図である。図1では、認証サーバ100、スマートデバイス200、スマートデバイス用周辺機器300(以下、単に周辺機器と呼ぶ)が示されている。認証サーバ100は、インターネットに接続されている。スマートデバイス200もインターネットに接続されている。認証サーバ100およびスマートデバイス200は、インターネットを介して通信可能となっている。また、スマートデバイス200と周辺機器300は、上記のようにブルートゥース技術を用いて無線接続されている。そのため、スマートデバイス200と周辺機器300との間は、基本的にはブルートゥース規格に沿った無線通信が行なわれる。

0039

次に、認証サーバ100、スマートデバイス200、周辺機器300のハードウェア構成について説明する。図2は、認証サーバ100のハードウェア構成を示す模式図である。認証サーバ100は、処理部101、記憶部102、通信部103を備える。処理部101は、所定のプロセッサ等であり、本実施形態にかかる認証処理におけるサーバ側での各種情報処理を実行する。記憶部102は、当該処理で用いる各種データ(データベース等)が記憶される。通信部103は、処理部101の制御に基づき、インターネットに接続し、上記スマートデバイス200と通信を行なう。また、図示は省略するが、認証サーバ100には、サーバとしての機能を果たすためのその他の各種コンポーネントも含まれている。

0040

次に、図3は、スマートデバイス200のハードウェア構成を示す模式図である。スマートデバイス200は、例えばスマートフォンやタブレット端末等の情報機器である。スマートデバイス200は、処理部201、第1通信部202、第2通信部203、記憶部204、入力部205等を備える。処理部201は、専用アプリの実行等の、各種情報処理を実行する。第1通信部202は、処理部201の制御に基づいて、インターネットに接続し、通信する機能を有する。本実施形態では、第1通信部202は、無線LAN機能を有する無線モジュールであるとする。第1通信部202は、処理部201による制御に基づき、インターネットを介して上記認証サーバ100との間で各種データの送受信を行う。第2通信部203は、周辺機器300と通信するための機能を有する。本実施形態では、第2通信部203は、ブルートゥースモジュールであるとする。第2通信部203は、処理部201による制御に基づき、ブルートゥース技術を用いて周辺機器300との通信を行う。記憶部204は、例えばフラッシュメモリであり、アプリケーションプログラムや各種データ等が記憶される。入力部205は、スマートデバイスに対するユーザからの入力を受け付けるためのものであり、タッチパネルや各種のボタン等である。表示部206は、各種情報処理の結果等を表示するための画面である。

0041

次に、図4は、周辺機器300のハードウェア構成を示す模式図である。周辺機器300は、通信部301を備える。また、図示は省略するが、操作ボタンや各種センサ等、専用アプリの実行において必要な各種ハードウェアコンポーネントも備えている。通信部301は、例えば通信チップ(より具体的には、ブルートゥースチップやブルートゥースモジュール)であり、スマートデバイス200と近距離無線通信を行なうための機能を有する。通信部301は、マイコン302、不揮発メモリ303、RAM304を有する。不揮発メモリ303には、後述するような処理を実行するためのプログラムやデータが記憶されている。当該プログラムはマイコン302によって実行されることになる。RAM304には、後述の処理において必要な各種データが適宜記憶される。

0042

次に、本実施形態で実行される認証処理の処理概要について説明する。本実施形態では、概ね次のような動作の流れを想定している。まず、ユーザが専用アプリをスマートデバイス200にインストールし、起動を行なう。このときは、初回起動となるため、周辺機器の認証処理が実行される。詳細は後述するが、この認証処理の最初に、まず、スマートデバイス200と周辺機器300との間で無線接続が確立され、両者の間で通信可能な状態とされる。この時点では、両者の間で最低限の通信ができる状態であり、専用アプリから周辺機器が利用できるかどうかはまだ不明な状態である(つまり、周辺機器300はまだ認証されていない状態である)。その後、スマートデバイス200を中継するような形で周辺機器300と認証サーバ100との間で各種データの送受信等が行なわれることによって、認証処理が進行する。そのため、認証処理の実行に際しては、スマートデバイス200はインターネット通信(認証サーバ100との通信)が可能な状態であることが必要となる。認証処理の結果、周辺機器300が正常に認証されたときは、所定の情報(後述のボンディング情報等)が周辺機器300の不揮発メモリ303に記憶される。認証処理が終われば、専用アプリから周辺機器300が利用可能(両者の暗号化通信が可能)となる。そして、周辺機器300が通常起動し、専用アプリによる、当該周辺機器300を利用した所定の処理が実行される。

0043

周辺機器300が一旦正常に認証されれば、専用アプリの次回起動時は、周辺機器300において上記不揮発メモリ303に記憶された所定の情報に基づく簡易的なチェック処理が実行される。これは、周辺機器300側から見た通信相手である専用アプリ(スマートデバイス200)の正当性を検証するための簡易的な処理である。そして、検証に成功すれば、周辺機器300が通常起動される。つまり、周辺機器300が一旦正常に認証されれば、基本的は上記認証サーバ100を用いた認証処理を省略することが可能となっている。これにより、ユーザの利便性を高めることができる。

0044

また、本実施形態では、周辺機器300の正常認証時に不揮発メモリ303に記憶される所定の情報について、有効期限を設ける構成とする。そして、この期限が経過した場合は、認証サーバ100を用いる再度の認証処理が必要となる。つまり、本実施形態では、純正品の周辺機器300を用いていても、定期的に認証処理の実行を要求するという構成を採っている。

0045

上記のような処理を行うことで、本実施形態では、周辺機器300の正当性や安全性の確認と、ユーザの利便性の確保とを両立することが可能となっている。

0046

次に、本実施形態における認証処理の動作をより詳細に説明する。まず、本処理において用いられる各種データに関して説明する。

0047

図5は、認証サーバ100の記憶部102に記憶されるデータを示す図である。記憶部102には、Vf_Key111、Pvt_Key112、データベース113等が記憶されている。Vf_Key111は、後述するデジタル署名であるBT_Signの検証用検証鍵(Verification Key)である。Pvt_Key112は、暗号化方式のひとつである公開鍵方式における「秘密鍵」であり、後述の周辺機器300において記憶されているPub_Key313と対になるものである。

0048

データベース113は、純正品の周辺機器300に関するデータベースである。データベース113には、複数のアプリテーブル114が含まれている。このアプリテーブル114については、1つの専用アプリに対して1つのアプリテーブル114が用意される。例えば、周辺機器300を用いる専用アプリとして、アプリA、アプリB、アプリCの3つのアプリがあるとする(それぞれのアプリで実現される機能は異なるものとする)。この場合は、アプリテーブル114としては3つのテーブルが用意される。すなわち、アプリA用のアプリテーブル114と、アプリB用のアプリテーブル114と、アプリC用のアプリテーブル114である。

0049

図6に、アプリテーブル114の構成の一例を示す。アプリテーブル114は、BT_Addr115、ユーザID116、PWD117等の項目を有する。BT_Addr115は、周辺機器300を一意に識別するためのデータである。本実施例では、周辺機器300がブルートゥースデバイスである場合を例として説明しているため、ブルートゥースデバイスに固有のアドレス(BDデバイスアドレスやBDアドレスと呼ばれることもある)を当該BT_Addr115として利用している。ここで、当該BT_Addr115のデータ登録に関して補足説明する。まず、周辺機器300が製造された際に、各周辺機器300の上記固有のアドレスが所定のリストとして記録される。換言すれば、製造された全ての周辺機器300の上記固有のアドレスのリストが用意されることになる。そして、当該リストに基づいて(例えば当該リストからデータをインポートする等)、BT_Addr115のデータが登録される。このようにして生成されたアプリテーブル114は、いわば、BT_Addr115のホワイトリストとしての役割も有する。

0050

次に、ユーザID116、および、PWD117は、ユーザアカウントの情報である。後述するが、本実施例では、上記専用アプリの利用に際して、ユーザアカウント情報を要求する。例えば、専用アプリの初回起動時には、ユーザアカウント作成のための処理が実行される。当該ユーザID116とPWD117は、このアカウント作成処理でユーザに入力されたユーザIDとパスワードを示すデータである。つまり、このアカウント作成処理において、当該データベース113に登録される。

0051

なお、本実施形態では、説明の便宜上、1つのBT_Addr115(1台の周辺機器300)に対して、1人分のユーザID/パスワードが登録可能であるとして説明する。但し、他の実施形態では、1つのBT_Addr115に対して複数人分のユーザID/パスワードが登録可能なように構成しても良い。例えば、1台の周辺機器を家族がそれぞれ所有するスマートデバイス(専用アプリ)から利用することが想定される場合、このような構成としても良い。

0052

次に、周辺機器300に記憶されるデータについて説明する。図7は、周辺機器300の不揮発メモリ303に記憶されるデータを示す図である。不揮発メモリ303には、BT_Addr311、BT_Sign312、Pub_Key313、ボンディング情報314、APP_ID317、BT_Key318等が記憶される。

0053

BT_Addr311は、その周辺機器300に固有のアドレスであり、製造時に決定されるアドレスである。換言すれば、その周辺機器300を一意に識別するための機器識別情報ともいえる。また、当該BT_Addr311は、上記データベース113のアプリテーブル114に記憶されるBT_Addr115として登録されるデータでもある。なお、以下の説明においては、BT_Addr311および上記BT_Addr115に関して、「周辺機器300に固有のアドレス」を示す意図で、単にBT_Addrと呼ぶこともある。

0054

BT_Sign312は、その周辺機器300の製造時に生成され、記憶(書き込み)されるデジタル署名である。具体的には、上記BT_Addr311を、署名鍵Sign_Key(図示せず)を用いて暗号化したものが、BT_Sign312として、不揮発メモリ303に記憶される。なお、この署名鍵Sign_Keyは、上記認証サーバに記憶されているVf_Key111と対になるものである。

0055

Pub_Key313は、暗号化通信における公開鍵パブリックキー)であり、上記認証サーバ100で記憶されているPvt_Key112と対になるものである。

0056

なお、BT_Addr311、BT_Sign312、Pub_Key313については、周辺機器300の製造時に不揮発メモリ303に書き込まれる。つまり、ユーザが周辺機器300を購入等した時点で、これらのデータは既に周辺機器300に記憶されている状態となっている。一方、以下に説明するボンディング情報314、APP_ID317、BT_Key318は、本実施形態にかかる認証処理等を経て、最終的に周辺機器300に記憶されるものである。

0057

ボンディング情報314は、スマートデバイス200と周辺機器300との接続の組み合わせに関する情報である。ここで、本実施形態では、「ボンディング」とは、スマートデバイス200と周辺機器300とで接続情報共有することを意味するものとする。このような接続情報がボンディング情報であり、スマートデバイス200と周辺機器300との再接続時の手続きを簡略化するために利用される。例えば、ある周辺機器300と、あるスマートデバイス200とが互いに一度も接続したことがない状態から、ユーザが所定の接続確立操作を行うことで、両者の間で接続が確立したとき(接続の実績ができたとき)、お互いの情報(固有アドレス等の接続相手の情報)を交換して記憶しておく。次回接続時には、この情報に基づくことで、ユーザによる所定の接続確立操作を行うことなく、自動的に再度の接続確立が可能となる。このような自動的な再度の接続のための情報がボンディング情報である。なお、以下の説明では、このような接続情報が記憶されていない状態のことを「未ボンディング」、ボンディング情報が記憶済みの状態のことを「ボンディング済み」と呼ぶこともある。

0058

本実施形態では、当該ボンディング情報314には、基本ボンディング情報315と拡張ボンディング情報316とが含まれている。基本ボンディング情報315は、ブルートゥース規格に基づいた所定のデータであり、接続相手のアドレスや識別情報等が含まれている。また、当該基本ボンディング情報315が設定されているときは、「ボンディング済み」であり、設定されていないときは「未ボンディング」でると判定することが可能である。

0059

拡張ボンディング情報316は、本実施形態において使用される独自の拡張データである。具体的には、ボンディング情報314(基本ボンディング情報315)に「有効期限」を設定するためのデータが含まれている。図8に、当該拡張ボンディング情報316のデータ構成の一例を示す。拡張ボンディング情報316には、期限切れフラグ319、期限カウンタ320等が含まれている。期限切れフラグ319は、ボンディング情報314が有効期限内であるか、期限切れであるかを示すフラグである。本実施形態では、Trueの場合は期限切れであることを示し、Falseの場合は有効期限内であることを示す。また、期限カウンタ320は、有効期限を示すデータであり、また、カウントするためのカウンタである。例えば、ボンディング情報314の有効期限が「60日」であるとする。この場合、例えばボンディング情報314更新されたタイミングで、当該期限カウンタに「60」という値が設定されるようにする。そして、周辺機器300のマイコン302は、1日単位で当該期限カウンタ320を1ずつカウントダウンする処理を行ない、有効期限が終了した場合(当該カウンタが0になったとき)、上記期限切れフラグ319にTrueを設定する処理を行なう。このような拡張ボンディング情報316は、換言すれば、スマートデバイス200(専用アプリ)と周辺機器300との接続が許可されるか否かを示すための情報であるともいえる。

0060

なお、他の実施例では、上述した「未ボンディング」であるか「ボンディング済み」であるかを示すフラグを、当該拡張ボンディング情報316に持たせるようにしてもよい。そして、このフラグを用いてボンディング済みか否かを判定するような構成としても良い。

0061

図7戻り、APP_ID317は、専用アプリを識別するためのアプリケーションIDである。本実施形態では、このデータは主に専用アプリの正当性の確認等のために用いられる。また、一旦周辺機器が正常に認証された後、専用アプリが再度起動された際、認証サーバを用いた認証処理を省略するために、このデータを利用したチェック処理が行なわれる。

0062

BT_Key318は、周辺機器300とスマートデバイス200(専用アプリ)との間で暗号化通信を行なう際に「鍵」として用いられるデータである。これは、後述の認証処理の過程で生成される。周辺機器が正常に認証された後、周辺機器300とスマートデバイス200(専用アプリ)との間では、当該BT_Key318で各種データを暗号化したうえで送受信が行なわれる。

0063

また、図示は省略するが、周辺機器300のRAM304には、後述の認証処理において必要となる各種データが適宜生成されて記憶される。

0064

次に、スマートデバイス200の記憶部204に記憶されるデータについて説明する。図9は、スマートデバイス200の記憶部204に記憶されるデータを示す図である。
記憶部204には、専用アプリプログラム211と、APP_ID212と、ボンディング情報213と、クライアント証明書214と、BT_Key215等が記憶される。

0065

専用アプリプログラム211は、後述する認証処理のうち、スマートデバイス側での処理を実行するためのプログラムである。APP_ID212は、当該専用アプリプログラムに対応するアプリケーションIDである。なお、認証処理が正常に行われたことを前提とすれば、上記周辺機器300に記憶されているAPP_ID317は当該APP_ID212と同じものとなる。以下の説明では、APP_ID317およびAPP_ID212を総称し、「アプリケーションID」の意味で単にAPP_IDと記載することもある。

0066

ボンディング情報213は、スマートデバイス200と周辺機器300との接続の組み合わせに関する情報である。上記周辺機器300におけるボンディング情報314と対になる関係である。その構成としては、上記周辺機器300におけるボンディング情報314のデータ構成のうち、拡張ボンディング情報316を省いた構成(つまり、実質的に基本ボンディング情報315のみ)となる。

0067

クライアント証明書214は、認証サーバ100への正当アクセス権を有すること等を証明するためのデータである(いわゆるアクセスコントロールのために用いられるデータである)。専用アプリのユーザアカウントの登録の際に生成されるデータである(認証局も兼ねた認証サーバ100から発行される)。また、当該クライアント証明書214には、いわゆるクライアント公開鍵およびクライアント秘密鍵も含まれている。この鍵を用いることで、スマートデバイス200と通信相手(認証サーバ100)との間での暗号化通信が可能となる。

0068

BT_Key215は、周辺機器300とスマートデバイス200(専用アプリ)との間で暗号化通信を行なうための鍵となるデータである。認証処理が正常終了すれば、最終的に、当該データが記憶されていることになる。そして、その内容は、上記BT_Key318と同じ内容である。なお、以下の説明では、BT_Key318、BT_Key215(更には、認証サーバ100で一時的に記憶されるBT_Key)が同じ内容であることに鑑み、暗号化通信用の「鍵」という意図で、総称してBT_Keyと呼ぶこともある。

0069

また、図示は省略するが、本実施形態の処理で必要なその他のデータも適宜記憶部204に記憶される。

0070

次に、本実施形態にかかる認証処理の流れについて説明する。なお、説明の便宜上、以下では当該認証処理をいくつかの「フェーズ」に分けて説明する。まず、図10を用いて、本実施形態にかかる認証処理のフローの全体像と、各フェーズで行なわれる処理の概略を説明する。その後、各フェーズにおける処理の詳細を説明する。図10では、左から認証サーバ100、スマートデバイス200、周辺機器300の順でそれぞれにおける処理のフェーズを示している。各フェーズは縦方向に時系列で並べている。横方向の矢印は、データの送受信が行なわれることを示す。

0071

まず、第1フェーズ処理での処理概要について説明する。このフェーズの処理は、スマートデバイス200と周辺機器300との間で行なわれる処理である。主に、スマートデバイス200(専用アプリ)と周辺機器300との間の接続確立の処理と、認証サーバ100との通信を伴う認証処理の必要性を判定する処理が実行される。認証サーバ100との通信を伴う認証処理が不要と判断された場合は、周辺機器側にて、通信相手であるスマートデバイス200(専用アプリ)の正当性を検証するための比較的簡易な検証処理が行なわれる。検証に成功すれば、当該プロセスにかかる認証処理が終了し、周辺機器300が通常起動することになる。

0072

次に、第2フェーズ処理の概要について説明する。このフェーズの処理は、認証サーバ100、スマートデバイス200、周辺機器300の3者間で行なわれる。主に、このフェーズでは、上記BT_Key318の生成処理や、認証サーバ側における周辺機器300や専用アプリの正当性を検証する処理が実行される。

0073

次に、第3フェーズ処理の概要について説明する。このフェーズの処理は、認証サーバ100とスマートデバイス200との間で行なわれる。主に、スマートデバイス200(専用アプリ)から認証サーバ100にクライアント証明書を送信し、認証サーバ100側で当該クライアント証明書を検証する処理が実行される。つまり、クライアント証明書に基づいて、スマートデバイス200のアクセス権限の正当性(認証サーバ100へのアクセスが許可される端末であるか否か)をチェックする処理が実行される。なお、専用アプリの初回起動時は、クライアント証明書がまだ作成されていない(ユーザアカウントがまだ作成されていない)ため、ユーザアカウントの作成処理が行なわれる(その結果、クライアント証明書も作成される)。

0074

次に、第4フェーズ処理の概要を説明する。このフェーズの処理は、認証サーバ100、スマートデバイス200、周辺機器300の3者間で行なわれる。但し、スマートデバイス200は主に中継役であり、実質的には認証サーバ100と周辺機器300との間でのやりとりとなる。このフェーズでは、以降のフェーズで行なわれる暗号化通信に先立って、認証サーバ100と周辺機器300との間で、信頼できる通信相手であるかをお互いに確認するための処理が行なわれる。

0075

次に、第5フェーズ処理の概要を説明する。このフェーズの処理も、認証サーバ100、スマートデバイス200、周辺機器300の3者間で行なわれるが、スマートデバイス200は主に中継役であり、実質的には認証サーバ100と周辺機器300との間でのやりとりとなる。このフェーズの処理では、主に、次回以降の認証処理を省略できるようにするためのデータを、認証サーバ100から周辺機器300に暗号化して送信する処理等が実行される。

0076

次に、第6フェーズ処理の概要について説明する。このフェーズの処理は、認証サーバ100とスマートデバイス200との間で行なわれる。このフェーズでは、認証サーバ100からスマートデバイス200(専用アプリ)に、周辺機器300との間で暗号化通信を行なう際の「鍵」データ(上記BT_Key)を送信する処理が実行される。

0077

以下、各フェーズの処理の詳細を説明する。ここで、以下の説明においては、図面(フローチャート)で示される各処理について参照符号を付している。この参照符号については、以下の命名規則に沿うものとする。すなわち、”フェーズ番号略称”−”実行主体略称”−”ステップ番号”、という命名規則に沿って付すものとする。フェーズ番号略称は、例えばフェーズ1は”Ph1”と示す。実行主体略称は、認証サーバを”SV”、スマートデバイスを”SD”、周辺機器を”PP”とする。ステップ番号は、”Sn(nは整数)”とする。例えば、フェーズ1において周辺機器で行なわれる一つ目の処理の場合は、「Ph1−PP−S1」のように示す。

0078

なお、当該処理の開始に際しては、周辺機器300が通電しており、正常に利用可能な状態であって、また、スマートデバイス200もインターネット通信が可能な状態(認証サーバ100と通信可能な状態)であるものとする。このよう状態で、スマートデバイス200において上記専用アプリが起動されると、以下に説明する処理が開始される。

0079

また、以下の説明において、各処理の実行主体は、認証サーバ100は処理部101が実行主体となり、スマートデバイス200は処理部201が実行主体となり、周辺機器300はマイコン302が実行主体であるものとする。

0080

まず、第1フェーズ処理の詳細について説明する。図11は、第1フェーズ処理の詳細を示すフローチャートである。図11における左側のフローがスマートデバイス(専用アプリ)側の処理、右側のフローが周辺機器300側の処理の流れを示している。上記のように、この処理では、主にスマートデバイス200と周辺機器300との間の接続の確立と、認証処理の必要性を判定する処理が実行される。認証処理が不要と判断された場合は、その時点で当該プロセスにかかる認証処理が終了し、周辺機器300が通常起動することになる。まず、専用アプリが起動されると、周辺機器300とスマートデバイスとの間の接続を確立するための処理が実行される(Ph1−SD−S1およびPh1−PP−S1)。この接続の確立処理は、ブルートゥース規格に沿った手法で行なわれる。

0081

なお、本実施形態では、専用アプリの起動時にスマートデバイス200と周辺機器300との接続を確立させる例を示しているが、他の実施例では、専用アプリの起動前に、スマートデバイス200と周辺機器300との接続の確立を済ませておくようにしてもよい(例えばシステム側の制御で接続確立だけが行なわれる等)。この場合でも、両者の接続が確立しているだけであり、まだ専用アプリから周辺機器300が使用できるかどうかは不明な状態である。

0082

スマートデバイス200と周辺機器300との間で接続が確立されれば、次に、ボンディング情報をチェックする処理が実行される(Ph1−SD−S2およびPh1−PP−S2)。具体的には、まず、「ボンディング済み」であるか「未ボンディング」であるかの判定が行なわれる。これは、スマートデバイス200では、ボンディング情報213を参照することで、周辺機器300では、ボンディング情報314を参照することで判定される(例えば、通信相手のBT_Addrが記憶されているか否か等で判定可能)。そして、それぞれでの判定結果を互いに送受信することで、「ボンディング済み」か「未ボンディング」かが判定される。この結果、「ボンディング済み」と判定された場合は、更に、ボンディング情報314の有効期限が終了しているか否かの判定も実行される。これは、周辺機器300において、拡張ボンディング情報316の期限切れフラグ319を参照することで判定される。そして、その結果を示すデータが周辺機器300からスマートデバイス200に送信されることで、スマートデバイス側でも有効期限が終了しているか否かを把握することが可能である。

0083

上記のボンディング情報をチェックの結果、「未ボンディング」の場合、あるいは、「ボンディング済み」ではあるがその有効期限が終了していると判定された場合は、以下の処理はスキップされて、後述の第2フェーズ処理へと処理が進められる。

0084

一方、「ボンディング済み」であり且つその有効期限内である場合は、次のような処理が実行される。まず、周辺機器300からスマートデバイス200に対して、APP_ID212の送信要求が送られる(Ph1−PP−S3)。この要求を受けたスマートデバイス200では、APP_ID212が記憶部から読み出され、これが周辺機器300に返信される(Ph1−SD−S3)。次に、周辺機器300において、返信されてきたAPP_ID212を検証する処理が実行される(Ph1−PP−S4)。この検証処理は、次のようにして行なわれる。すなわち、周辺機器300において、不揮発メモリ303に記憶されているAPP_ID317と、返信されてきたAPP_ID212が一致するか否かを判定し、一致すれば、検証成功と判定する。なお、不揮発メモリ303に記憶されているAPP_ID317は、この後説明する処理の過程で(換言すれば、認証処理が正常終了した場合に)当該不揮発メモリ303に記憶されたものである。

0085

上記のAPP_IDの検証の結果、検証が成功すれば、認証サーバ100を用いた認証処理が不要であると判断されることになる。その結果、この時点で本実施形態にかかる認証処理は終了し、周辺機器300が通常起動することになる。

0086

一方、周辺機器300側におけるAPP_IDの検証が失敗した場合は、認証サーバ100を用いた認証処理を行なうための処理が実行される。具体的には、ボンディング情報314の期限切れフラグ319にTrueを設定する処理が実行される。つまり、強制的にボンディング情報を有効期限切れの状態とする処理が実行される。その後、上記ボンディング情報のチェック処理(Ph1−SD−S2およびPh1−PP−S2)に戻るような制御が行なわれる。その結果、ボンディング情報の有効期限切れと判定され、フェーズ2の処理へと進むことになる。

0087

なお、周辺機器300側におけるAPP_IDの検証が失敗する場合としては、初回起動時や所定期間接続していないことによるボンディングの有効期限の経過の他、周辺機器300に記憶されているAPP_ID212とは異なるAPP_IDがスマートデバイス200から返信された場合もあり得る。例えば専用アプリA、専用アプリBという2種類の異なる専用アプリがある場合において、専用アプリAを起動して認証処理を一旦行なったとする。その結果、専用アプリAのAPP_IDが周辺機器300に記憶される状態となる。その後、専用アプリBを起動して当該周辺機器300に接続しにいった場合に、このような異なるAPP_IDが周辺機器300に送られてくることになる。このような場合、上記のように強制的にボンディング情報を有効期限切れの状態として、改めて専用アプリBを用いた認証処理が実行されることになる。その結果、周辺機器300には、専用アプリBのAPP_IDが記憶されることになる。

0088

また、例えば、仮に専用アプリ以外のアプリから当該接続確立済みの周辺機器300にアクセスし、当該周辺機器300の機能を利用しようとしたような場合も、上記のようなAPP_IDのチェック処理の結果、実質的に利用できないという結果になる。例えば、周辺機器300からのAPP_ID212の送信要求に対して、専用アプリ以外のアプリでは、この要求に応えられない場合や、上記のように、周辺機器300の不揮発メモリ303に記憶されているAPP_ID317とは一致しないAPP_ID212が送られる場合である。

0089

また、例えば周辺機器300が純正品ではないような場合は、上記ボンディング情報のチェック処理の後、周辺機器300からのAPP_ID212の送信要求がスマートデバイス200側に送られてこないと考えられる。そのため、例えば、専用アプリにおいて、上記ボンディング情報のチェック処理の後、所定時間経過しても周辺機器側からAPP_IDの送信要求が来ない場合(タイムアウトした場合)、認証失敗と判断して、失敗時を想定した所定の処理を実行するようにしてもよい。

0090

次に、第2フェーズ処理の詳細について説明する。図12は、第2フェーズ処理の詳細を示すフローチャートである。図12では、左側のフローが認証サーバ100側の処理、中央のフローがスマートデバイス(専用アプリ)側の処理、右側のフローが周辺機器300側の処理の流れを示している。このフェーズでは、BT_Key318の生成処理や、認証サーバ100側における周辺機器300や専用アプリの正当性を検証する処理が実行される。

0091

まず、周辺機器300において、BT_Key318を生成する処理が実行される(Ph2−PP−S1)。具体的には、BT_Addr311および所定の乱数(後述の第1乱数RAND1や第2乱数RAND2とは異なる乱数である)を用い、所定の処理によってBT_Key318が生成され、不揮発メモリ303に記憶される。この所定の処理としては、例えば、いわゆるAES(Advanced Encryption Standard)のアルゴリズムを用いてBT_Key318を生成する処理がある。

0092

次に、周辺機器300において、第1乱数RAND1を生成する処理が実行される。そして、当該RAND1を上記BT_Key318を用いて暗号化する処理が実行される(Ph2−PP−S2)。なお、ここでいう「乱数」には、「真性乱数」の他、「疑似乱数」も含むものとする。また、BT_Key318がAES鍵であるため、RAND1はAES方式で暗号化されることになる。

0093

次に、周辺機器300において、不揮発メモリ303から読み出したBT_Addr311およびBT_Sign312と、上記生成したBT_Key318および、BT_Key318で暗号化された第1乱数RAND1を、Pub_Key313で暗号化する処理が実行される(Ph2−PP−S3)。

0094

続いて、周辺機器300において、上記暗号化されたBT_Addr311、BT_Sign312、BT_Key318、および第1乱数RAND1を、その送信宛先を認証サーバ100に設定して、スマートデバイス200に送信する処理が実行される(Ph2−PP−S4)。

0095

次に、スマートデバイス200において、上記送信宛先を判別し、周辺機器300から受信したデータを認証サーバ100に送信する(中継する)処理が実行される(Ph2−SD−S1)。つまり、スマートデバイス200を経由して、周辺機器300から認証サーバ100へ上記暗号化されたBT_Addr311、BT_Sign312、BT_Key313、および第1乱数RAND1が送信されることになる。

0096

次に、認証サーバ100において、スマートデバイス200から送られてきた上記各データを受信し、記憶部102に記憶する処理が実行される(Ph2−SV−S1)。

0097

次に、認証サーバ100において、スマートデバイス200(専用アプリ)に対して、「APP_ID212の送信要求」を送る処理が実行される(Ph2−SV−S2)。この要求を受けたスマートデバイス200では、APP_ID212を記憶部204から読み出し、これを認証サーバ100に返信する処理が実行される(Ph2−SD−S2)。次に、認証サーバ100において、返信されてきたAPP_ID212を検証する処理が実行される(Ph2−SV−S3)。この検証処理は、次のようにして行なわれる。すなわち、認証サーバ100において、返信されてきたAPP_ID212と同じ名前のアプリテーブル114をデータベース113から検索する。その結果、見つからない場合は、現在通信相手となっている専用アプリは正規の専用アプリではない可能性があると判断される。その結果、検証は失敗したとして、検証失敗時を想定した所定の処理が実行される(例えば、所定のエラーメッセージをスマートデバイスに送信する等)。本実施形態にかかる認証処理も、この時点で終了することになる。

0098

一方、アプリテーブル114が検索できた場合(APP_ID212の検証に成功したことになる)は、認証サーバ100において、次に、上記スマートデバイス200から受信した暗号化データを復号化する処理が実行される(Ph2−SV−S4)。具体的には、認証サーバ100において、Pvt_Key112を用いて上記暗号化データをそれぞれ復号化する処理が実行される。なお、第1乱数RAND1に関しては、BT_Key318で暗号化されたうえで、更にPub_Key313で暗号化されて送信されている(つまり2重で暗号化されている)。そのため、この復号化の時点では、BT_Key318によりまだ暗号化されている状態のものが得られることになる。

0099

次に、認証サーバ100において、上記復号化処理で得られたBT_Sign312を検証する処理が実行される(Ph2−SV−S5)。具体的には、認証サーバ100において、BT_Sign312をVf_Key111で検証する処理が実行される。これにより、BT_Addr311が通信路の途中で改ざんされていないか、通信相手となる周辺機器300が純正品であるかどうか、についてチェックすることができる。検証の結果、検証に失敗した場合は、検証失敗時を想定した所定の処理が実行され、本実施形態にかかる認証処理も、この時点で終了する。

0100

一方、BT_Sign312の検証に成功した場合は、次に、認証サーバ100において、上記復号化で得られたBT_Addr311を検証する処理が実行される(Ph2−SV−S6)。具体的には、認証サーバ100において、上記検索されたアプリテーブル114から、上記周辺機器300から得られたBT_Addr311と一致するBT_Addr115を検索する処理が実行される。その結果、見つからない場合は、周辺機器300が純正品ではない可能性があるとして、検証は失敗したと判定される。そして、検証失敗時を想定した所定の処理が実行される。一方、一致するBT_Addr115が見つかった場合は、検証に成功したと判定される。このとき、図示は省略するが、BT_Addrの検証に成功した旨を示す所定のメッセージを認証サーバ100から(スマートデバイス200経由で)周辺機器300に送信するようにしてもよい(つまり、この時点で検証成功を通知してもよい)。そして、認証処理のプロセスは、次に説明する第3フェーズ処理へ進められる。

0101

次に、第3フェーズ処理の詳細を説明する。図13は、第3フェーズ処理の詳細を示すフローチャートである。図13では、左側のフローが認証サーバ100側の処理、右側のフローがスマートデバイス(専用アプリ)側の処理の流れを示している。このフェーズでは、主にスマートデバイス200のクライアント証明書を検証するための処理が実行される。つまり、認証サーバ100からみて、通信相手となるスマートデバイス200が信頼できる通信相手であるか否かをチェックする処理が実行される。

0102

図13において、まず、認証サーバ100からスマートデバイス200に対して、クライアント証明書要求を送信する処理が実行される(Ph3−SV−S1)。この要求を受けたスマートデバイス200では、まず、要求されたクライアント証明書214を有しているか(記憶されているか)否かの判定が行なわれる(Ph3−SD−S1)。その結果、クライアント証明書214を有していない場合は(Ph3−SD−S1でNO)、ユーザアカウントの作成処理が実行される(Ph3−SD−S2)。例えば、専用アプリを使用するためのユーザIDとパスワードを登録するための画面が表示され、これに対してユーザが任意のユーザIDとパスワードを入力する。これが認証サーバ100に送信され、専用アプリのユーザとして、適宜アプリテーブル114に登録される。その後、既知の手法を用いてクライアント証明書が生成され(当該生成に際しての認証局は、例えば認証サーバ100となる)、これがクライアント証明書214として記憶部204に記憶される。

0103

一方、既にクライアント証明書214を既に有している場合は(Ph3−SD−S1でYES)、上記のアカウント作成処理は行なわれない。

0104

次に、スマートデバイス200において、クライアント証明書214を認証サーバ100に返信する処理が実行される(Ph3−SD−S3)。続いて、認証サーバ100において、既知の手法を用いて、クライアント証明書214を検証する処理が実行される(Ph3−SV−S2)。例えば、クライアント証明書214に含まれる署名(クライアント証明書を発行したサーバがクライアント公開鍵につけた署名)を、当該クライアント証明書発行サーバの公開鍵を用いて検証する処理が実行される。クライアント証明書の検証が成功すれば、次の第4フェーズの処理へと進む。

0105

次に、第4フェーズ処理の詳細について説明する。図14および図15は、第4フェーズ処理の詳細を示すフローチャートである。図14および図15では、左側のフローが認証サーバ100側の処理、中央のフローがスマートデバイス(専用アプリ)側の処理、右側のフローが周辺機器300側の処理の流れを示している。このフェーズでは、主に認証サーバ100と周辺機器300との間で、お互いに信頼できる通信相手であるかを確認するための処理が行なわれる。

0106

まず、周辺機器側から見て、認証サーバ100が、暗号化通信する相手として信頼できる相手であるか否か(認証サーバ100の暗号化通信相手としての正当性)をチェックする処理が実行される。具体的には、まず、認証サーバ100において、上記第2フェーズ処理(上記Ph2−SV−S4の処理)で得られた第1乱数RAND1(その時点ではまだBT_Key318で暗号化されている状態である)を、同じく第2フェーズ処理で得られたBT_Keyを用いて復号化する処理が実行される。その結果、暗号化されていない第1乱数RAND1が得られる。そして、当該RAND1をスマートデバイス200(を経由して周辺機器300)に送信する処理が実行される(Ph4−SV−S1)。つまり、送信宛先としては周辺機器300を設定して、スマートデバイス200に送信する。

0107

次に、スマートデバイス200では、上記宛先を判別することで、認証サーバ100から受信した当該データを周辺機器300に送信する処理が実行される(Ph4−SD−S1)。

0108

次に、周辺機器300において、スマートデバイス200経由で認証サーバから送られてきたRAND1と、自身が生成したRAND1(上記Ph2-PP-S2参照)とが一致するか否かを確認する処理が実行される(Ph4−PP−S1)。一致しなかった場合は、認証サーバ100の正当性が確認できなかったとして、確認失敗時を想定した所定の処理が実行される。一方、一致した場合は、次に、周辺機器300において、第1乱数RAND1を用いた確認処理が完了した旨を示す所定のメッセージを生成する。ここで、当該所定のメッセージは、周辺機器300から認証サーバ100に対する、後述の第2乱数RAND2の送信依頼発行依頼)のメッセージという性質も有する。そして、周辺機器300において、当該所定のメッセージをBT_Key318で暗号化する処理が実行される。そして、当該暗号化されたメッセージを、その送信宛先を認証サーバ100に設定したうえで、スマートデバイス200に送信する処理が実行される(Ph4−PP−S2)。スマートデバイス200では、周辺機器300から受信した当該メッセージを認証サーバ100に送信する処理が実行される(Ph4−SD−S2)。

0109

次に、認証サーバ100において、スマートデバイス200から中継されてきた上記の暗号化メッセージを受信し、これを第2フェーズ処理で得られたBT_Keyで復号化する処理が実行される(Ph4−SV−S2)。これにより、認証サーバ100では、周辺機器300における上記認証サーバ100の暗号化通信相手としての正当性をチェックする処理が完了したことが把握できる。そして、次に、認証サーバ100から見て、周辺機器300が暗号化通信の相手として信頼できる相手であるか否か(周辺機器300の暗号化通信相手としての正当性)をチェックする処理が実行される。

0110

まず、認証サーバ100において、第2乱数RAND2が生成される。そして、上記第2フェーズ処理で得られたBT_Keyによって当該RAND2が暗号化される。更に、その送信宛先を周辺機器300に設定したうえで、当該暗号化された第2乱数RAND2(以下、暗号化RAND2)をスマートデバイス200に送信する処理が実行される(Ph4−SV−S3)。スマートデバイス200では、上記宛先を判別することで、認証サーバ100から受信した当該暗号化RAND2を周辺機器300に送信する処理が実行される(Ph4−SD−S3)。

0111

次に、周辺機器300において、受信した暗号化RAND2をBT_Key318で復号化する処理が実行される。そして、復号化したRAND2を、その送信宛先を認証サーバ100に設定したうえで、スマートデバイス200に送信する処理が実行される(Ph4−PP−S3)。スマートデバイス200では、周辺機器300から受信した当該RAND2を認証サーバ100に送信する処理が実行される(Ph4−SD−S4)。

0112

次に、認証サーバ100において、スマートデバイス200から受信した第2乱数RAND2と、先ほど生成した第2乱数RAND2とが一致しているか否かを確認する処理が実行される(Ph4−SV-S4)。一致しなかった場合は、周辺機器300の正当性が確認できなかったとして、確認失敗時を想定した所定の処理が実行される。一方、一致した場合は、認証サーバ100と周辺機器300との間でお互いに暗号化通信相手として信頼できることが確認されたことになる。そのため、次の第5フェーズ処理へと進む。

0113

次に、第5フェーズ処理の詳細について説明する。図16は、第5フェーズ処理の詳細を示すフローチャートである。図16では、左側のフローが認証サーバ100側の処理、中央のフローがスマートデバイス(専用アプリ)側の処理、右側のフローが周辺機器300側の処理の流れを示している。このフェーズでは、APP_ID317を周辺機器に登録あるいは更新する処理等が実行される(その結果、例えば専用アプリの次回起動時には、このAPP_ID317が、上記第1フェーズ処理において用いられることになる)。

0114

まず、認証サーバ100において、上記第2フェーズ処理でスマートデバイスから得られたAPP_IDを、おなじく第2フェーズ処理で周辺機器300から得たBT_Keyで暗号化する処理が実行される。そして、当該暗号化されたAPP_ID(以下、暗号化APP_ID)をスマートデバイス200経由で周辺機器300に送信する処理が実行される(Ph5−SV−S1)。スマートデバイス200では、認証サーバ100から受信した暗号化APP_IDを周辺機器300に送信する処理が実行される(Ph5−SD−S1)。

0115

周辺機器300では、受信した暗号化APP_IDを、BT_Key318で復号化する処理が実行される。そして、不揮発メモリ303に記憶されているAPP_ID317を当該復号化したAPP_IDで更新する処理が実行される。また、不揮発メモリ303にAPP_ID317がまだ記憶されていない場合は(初回起動時の場合等)、これが新たに記憶される。これにより、最新のAPP_ID317が周辺機器300に記憶されることになる。例えば、専用アプリがバージョンアップしたような場合に、APP_IDも新しいものが割り当てられるとする。この場合、最新バージョンのAPP_IDが周辺機器300に記憶されることで、古いバージョンの専用アプリからは当該周辺機器300が利用できないことになる(なお、このような場合、上記第1フェーズ処理において、専用アプリのバージョンアップを促すようなメッセージをスマートデバイス200側に表示するような構成としても良い)。

0116

次に、周辺機器300において、次回以降に専用アプリを起動した際に認証サーバ100を用いた認証処理が不要な状態となるようにボンディング情報314を更新するための処理が実行される。すなわち、基本ボンディング情報315の内容を適宜更新すると共に、拡張ボンディング情報316における期限切れフラグ319をFalseに更新する処理も実行される。また、期限カウンタ320にも、有効期限をカウントするための値が適宜設定される。周辺機器300においては、認証処理はこれで終了する。

0117

次に、第6フェーズ処理の詳細について説明する。図17は、第6フェーズ処理の詳細を示すフローチャートである。図17では、左側のフローが認証サーバ100側の処理、右側のフローがスマートデバイス(専用アプリ)側の処理の流れを示している。この処理では、暗号化通信のための鍵であるBT_Keyを認証サーバ100からスマートデバイス200に渡す処理が実行される。すなわち、まず、認証サーバ100において、上記第2フェーズ処理で周辺機器300から得たBT_Keyをクライアント公開鍵で暗号化する処理が実行される。当該クライアント公開鍵は、上記第3フェーズ処理で得られたクライアント証明書に含まれているものである。そして、認証サーバ100において、当該暗号化されたBT_Keyをスマートデバイス200に送信する処理が実行される(Ph6-SV-S1)。

0118

次に、スマートデバイス200において、当該暗号化されたBT_Keyが受信される。そして、スマートデバイス200がクライアント証明書の発行を受ける際に生成された秘密鍵(上記クライアント公開鍵と対になる鍵)を用いて、当該BT_Keyyを復号化する処理が実行される(Ph6-SD-S1)。そして、スマートデバイス200において、当該復号化されたBT_KeyがBT_Key215として記憶部204に記憶される。

0119

以上で、認証サーバ100およびスマートデバイス200における認証処理も終了する。この後は、周辺機器300が通常起動し、専用アプリと周辺機器300との間の通信については、上記BT_Keyによる暗号化が行なわれることになる。このBT_Keyによる暗号化は、次に上記のような認証処理が行なわれるまで実行される(つまり、次に認証処理が行なわれるまでは、当該BT_Keyが暗号化のために用いられる)。更に、本実施形態では、ブルートゥース規格に基づく暗号化(例えばLTK:Long Term Key等)も行なわれる。例えば、専用アプリで用いる各種データそのものはBT_Keyで暗号化される。このデータが、送受信に適したパケットに含まれ、このパケット自体を、ブルートゥース規格に基づいて暗号化して送受信する。つまり、専用アプリと周辺機器300間の通信については、BT_Keyによる暗号化とブルートゥース規格による暗号化の2重の暗号化が行なわれた状態となる。そのため、仮に、ブルートゥース規格による暗号化に関して盗聴されたとしても、BT_Keyによる暗号化が有効であるため、データの盗聴をより強固に防止することが可能となる。

0120

このように、本実施形態では、スマートデバイスと通信可能な周辺機器の認証を行なうものである。そして、その認証処理に際して、認証サーバ100を利用している。更に、周辺機器300と認証サーバ100との間にスマートデバイスを介在させる構成ではあるが、当該スマートデバイスには直接的な認証処理を行なわせないようにしている。これにより、周辺機器300は、専用アプリがインストールされていればどのようなスマートデバイスが用いられても、セキュアな環境下での認証処理を実行することが可能となる。

0121

また、本実施形態では、周辺機器に記憶される上記ボンディング情報に有効期限を設けるようにしている。これにより、有効期限内はユーザの利便性を高めることができ、また、有効期限切れのタイミングで再度の認証処理を実行させることができる。つまり、ユーザの利便性と、周辺機器や専用アプリの正当性のチェックとの両立を図ることができる。

0122

(第2の実施形態)
次に、第2の実施形態について説明する。第2の実施形態では、上記周辺機器におけるデータ記憶部として、いわゆるセキュアメモリ(セキュア領域を有するメモリ)を利用した場合を説明する。当該セキュアメモリに記憶されたデータは、上記マイコン302のような、周辺機器内部のコンポーネントからのアクセスしかできないように構成されている。周辺機器の外部からは、当該セキュアメモリに記憶されているデータにはアクセスできない。例えば、当該周辺機器と無線あるいは有線接続された他の情報処理機器からは、当該セキュアメモリに記憶されているデータにはアクセスできない。

0123

第2の実施形態にかかる認証システムの全体像は、上記第1の実施形態における図1で示したシステム構成と基本的には同様である。また、ハードウェア構成については、認証サーバ100、スマートデバイス200については、上記第1の実施形態におけるものと同様である。そのため、これらについての詳細な説明は省略する。一方、周辺機器に関しては、上記のようなセキュアメモリが設けられている点が異なる。

0124

図18は、第2の実施形態にかかる周辺機器400のハードウェア構成を示す模式図である。周辺機器400は、通信部401を備える。また、図示は省略するが、操作ボタンや各種センサ等、専用アプリの実行において必要な各種ハードウェアコンポーネントも備えている。通信部401は、例えば通信チップであり、スマートデバイス200と無線通信を行なうための機能を有する。通信部401は、マイコン402、不揮発メモリ403、RAM404、セキュアメモリ405、を有する。不揮発メモリ403には、後述するような処理を実行するためのプログラムやデータが記憶されている。当該プログラムはマイコン402によって実行されることになる。RAM404には、後述の処理において必要な各種データが適宜記憶される。セキュアメモリ405は、上記のようにそのアクセスに制限が設けられているメモリである。本実施形態では、当該セキュアメモリ405に記憶されているデータにはマイコン402しかアクセスできないものとする。

0125

次に、第2の実施形態で実行される認証処理の処理概要について説明する。基本的には、第2の実施形態では、上記第1の実施形態と同じ目的の処理が実行される。そのため、認証処理の一部は、上記第1の実施形態と共通している。その一方で、認証処理の過程で用いるデータの一部が上記セキュアメモリ405に記憶される。当該セキュアメモリ405に記憶されているデータについては、その信頼性が高いものであるといえる。そのため、第2の実施形態では、その信頼性の高さに基づき、認証処理の一部を上記第1の実施形態と異なる処理としている。

0126

次に、第2の実施形態の処理で用いられる各種データに関して説明する。まず、認証サーバ100に記憶されるデータについて説明する。図19は、認証サーバ100の記憶部102に記憶されるデータを示す図である。記憶部102には、BT_Sign_Pubkey501と、AS_Seckey502と、AS_Certificate503と、アプリIDリスト506とが記憶されている。更に、記憶部102には、AS_Sign_Seckey507と、BT_Sign_Seckey508とが記憶されている。

0127

BT_Sign_Pubkey501は、後述する周辺機器400に記憶されるBT_Certificate603を検証するための鍵データである。また、後述のBT_Sign_Seckey508(秘密鍵)と対になる公開鍵でもある。

0128

AS_Seckey502は、認証サーバ100の秘密鍵である。AS_Certificate503は、認証サーバ100の証明書データである。当該AS_Certificate503は、AS_Pubkey504とSignature505とで構成されている。AS_Pubkey504は、上記AS_Seckey502と対の関係になる公開鍵である。Signature505は、いわゆるデジタル署名である。具体的には、AS_Pubkey504のハッシュを計算し、これを後述のAS_Sign_Seckey507を用いて暗号化したものである。つまり、AS_Certificate503は、暗号化前のAS_Pubkey504と、暗号化されたAS_Pubkey504(=Signature505)とから構成されていることになる。

0129

アプリIDリスト506は、専用アプリのアプリケーションIDのリストデータである。複数の専用アプリがリリースされている場合、各専用アプリの最新バーションのアプリケーションIDが当該リストに格納されている。

0130

AS_Sign_Seckey507、および、BT_Sign_Seckey508は、認証サーバ100をいわゆる「認証局」として機能させるためのデータである。本実施形態では、説明の便宜上、これらデータを認証サーバ100に記憶させた例を示しているが、他の実施形態では、別途「認証局」としての役割を果たすサーバ等を設けてもよい。この場合、当該「認証局」となる機器の方にAS_Sign_Seckey507、および、BT_Sign_Seckey508を記憶させておけばよい。

0131

AS_Sign_Seckey507は、認証サーバの署名鍵である。すなわち、上記AS_Certificate503のSignature505を生成するために用いられる署名鍵である。また、BT_Sign_Seckey508は、周辺機器400の署名鍵である。後述する上記BT_Certificate603のSignature605を生成するために用いられる署名鍵である。

0132

次に、周辺機器400に記憶されるデータについて説明する。図20および図21は、周辺機器400に記憶されるデータを示す図である。まず、図20を用いて、セキュアメモリ405に記憶されるデータについて説明する。セキュアメモリ405には、AS_Sign_Pubkey601と、BT_Seckey602と、BT_Certificate603とが記憶されている。これらのデータについては、セキュアメモリ405に記憶されるため、その信頼度が高い(改ざんの危険性が低い等)データであるといえる。

0133

AS_Sign_Pubkey601は、認証サーバ100の証明書、すなわち、上記AS_Certificate503を検証するための鍵データである。また、上記AS_Sign_Seckey507(秘密鍵)と対になる公開鍵でもある。BT_Seckey602は、周辺機器400の秘密鍵である。BT_Certificate603は、周辺機器400の証明書データである。当該BT_Certificate603は、BT_Pubkey604とSignature605とで構成されている。BT_Pubkey604は、上記BT_Seckey602と対の関係になる公開鍵である。Signature605は、デジタル署名であり、BT_Pubkey604のハッシュを計算し、これを上記BT_Sign_Seckey508を用いて暗号化したものである。つまり、BT_Certificate603は、暗号化前のBT_Pubkey604と、暗号化されたBT_Pubkey604(=Signature605)とから構成されていることになる。

0134

次に、図21を用いて、周辺機器400の不揮発メモリ403に記憶されるデータについて説明する。不揮発メモリ403には、ボンディング情報701と、APP_ID704と、BT_Key705等が記憶されている。これらのデータの内容については、上述の第1の実施形態におけるボンディング情報314、APP_ID317、BT_Key318と同じであるため、ここでは説明を省略する。

0135

なお、第2の実施形態でのスマートデバイス200で記憶されるデータについては、基本的に、上述の第1の実施形態と同じものが記憶される(上記図9参照)。そのため、当該スマートデバイス200で記憶されるデータについても、その詳細な説明は省略するが、専用アプリプログラム211については、以下に説明する処理を実行するためのプログラムが記憶される。すなわち、実現される機能としては第1の実施形態のものとは少し異なる専用アプリプログラム211が記憶されることになる。

0136

次に、第2の実施形態にかかる認証処理の流れについて説明する。説明の便宜上、以下では当該認証処理をいくつかの「フェーズ」に分けて説明する。まず、図22を用いて、第2の実施形態にかかる認証処理のフローの全体像と、各フェーズで行なわれる処理の概略を説明する。その後、各フェーズにおける処理の詳細を説明する。

0137

図22では、左から認証サーバ100、スマートデバイス200、周辺機器400の順でそれぞれにおける処理のフェーズを示している。各フェーズは縦方向に時系列で並べている。横方向の矢印は、データの送受信が行なわれることを示す。

0138

まず、第1フェーズ処理の概要について説明する。当該処理では、上述の第1の実施形態における第1フェーズ処理を同様の処理が行なわれる。すなわち、スマートデバイス200(専用アプリ)と周辺機器400との間の接続確立の処理と、認証サーバ100との通信を伴う認証処理の必要性を判定する処理等が実行される。

0139

次に、第2フェーズ処理の概要について説明する。このフェーズの処理は、認証サーバ100、スマートデバイス200、周辺機器400の3者間で行なわれる。主に、このフェーズでは、上記周辺機器400の証明書を認証サーバ100で検証することで、周辺機器の正当性を判断する処理が実行される。

0140

次に、第3フェーズ処理の概要について説明する。このフェーズの処理は、認証サーバ100とスマートデバイス200との間で行なわれる。このフェーズでは、主に、認証サーバ100において、専用アプリのアプリケーションIDをチェックする処理や、クライアント証明書を検証する処理が実行される。

0141

次に、第4フェーズ処理の概要について説明する。このフェーズの処理は、認証サーバ100、スマートデバイス200、周辺機器400の3者間で行なわれるが、スマートデバイス200は主に中継役であり、実質的には認証サーバ100と周辺機器400との間でのやりとりとなる。このフェーズでは、主に認証サーバ100の証明書を周辺機器400側で検証する処理が実行される。

0142

次に、第5フェーズの処理の概要について説明する。このフェーズの処理は、認証サーバ100、スマートデバイス200、周辺機器400の3者間で行なわれる。但し、ここでもスマートデバイス200は主に中継役であり、実質的には認証サーバ100と周辺機器400との間でのやりとりとなる。このフェーズでは、主に、認証サーバ100と周辺機器400との間で、暗号化通信の共通鍵を生成するために必要なデータ(後述の第1乱数RAND1および第2乱数RAND2)を交換する処理が行なわれる。

0143

次に、第6フェーズの処理の概要について説明する。このフェーズでは、主に、認証サーバ100において暗号化通信に用いる共通鍵を生成し、スマートデバイス200へ送信する処理と、周辺機器400側でも当該共通鍵を生成する処理が行なわれる。

0144

次に、第7フェーズの処理の概要について説明する。このフェーズでは、主に、次回以降の認証処理を省略できるようにするため設定処理が実行される。

0145

以下、各フェーズの処理の詳細を説明する。以下の説明においては、図面(フローチャート)で示される各処理について参照符号を付している。この参照符号の命名規則は、上記第1の実施形態に準ずるが、ステップ番号については第1の実施形態との区別のため、3桁の数字で示す。

0146

また、上記第1の実施形態の場合と同様に、当該処理の開始に際しては、周辺機器400が通電しており、また、スマートデバイス200もインターネット通信が可能な状態(認証サーバ100と通信可能な状態)であるものとする。このよう状態で、スマートデバイス200において上記専用アプリが起動されると、以下に説明する処理が開始される。

0147

また、各処理の実行主体は、上記第1の実施形態と同様に、認証サーバ100は処理部101が実行主体となり、スマートデバイス200は処理部201が実行主体となり、周辺機器400はマイコン402が実行主体であるものとする。

0148

まず、第2の実施形態における第1フェーズ処理について説明する。このフェーズの処理は、上記第1の実施形態における第1フェーズと同様の処理が実行される。すなわち、スマートデバイス200と周辺機器400との間の接続の確立と、認証サーバ100を用いた認証処理の必要性を判定する処理等が実行される。認証サーバ100を用いた認証処理が不要と判断されれば、周辺機器300が通常起動する。認証サーバ100を用いた認証処理が必要と判断されれば、以下の第2フェーズ処理に進むことになる。当該第1フェーズでの処理内容は、上記図11を用いて説明した上記第1の実施形態における第1フェーズと同様であるため、ここではその詳細な説明は省略する。

0149

次に、第2の実施形態における第2フェーズ処理の詳細について説明する。図23は、当該第2の実施形態にかかる第2フェーズ処理の詳細を示すフローチャートである。このフェーズでは、認証サーバ100において周辺機器400の正当性を確認するための処理が実行される。まず、周辺機器400において、セキュアメモリ405からBT_Certificate603が読み出される。そして、当該読み出されたBT_Certificate603をスマートデバイス200に送信する処理が実行される(Ph2-PP-S101)。次に、スマートデバイス200において、周辺機器400から受信したBT_Certificate603を認証サーバ100に送信する処理が実行される(Ph2-SD-S101)。

0150

次に、認証サーバ100において、スマートデバイス200から受信したBT_Certificate603を、BT_Sign_Pubkey501を用いて検証する処理が実行される。具体的には、BT_Certificate603に含まれているSignature605を復号化し、当該Signature605を復号化した値とBT_Pubkey604のハッシュ値と一致するか否かを判断する。一致すれば、検証に成功したことになる。また、当該BT_Certificate603は、後の処理で用いられるため、記憶部102に記憶される。一方、一致しなければ、検証に失敗したことになる。この場合は、検証失敗時を想定した所定の処理が実行され、本実施形態にかかる認証処理も、この時点で終了する。

0151

次に、第3フェーズ処理の詳細について説明する。ここでは、主に、スマートデバイス200についての検証を行なう処理が実行される。図24は、第2の実施形態にかかる第3フェーズ処理の詳細を示すフローチャートである。まず、認証サーバ100において、スマートデバイス200(専用アプリ)に対し、当該専用アプリに対応しているAPP_ID212の送信要求を送る処理が実行される。この要求を受けたスマートデバイス200では、APP_ID212を記憶部204から読み出し、これを認証サーバ100に返信する処理が実行される(Ph2−SD−S102)。

0152

次に、認証サーバ100において、スマートデバイス200から送られてきたAPP_ID212を検証する処理が実行される(Ph2−SV−S3)。この検証処理は、次のようにして行なわれる。すなわち、認証サーバ100において、返信されてきたAPP_ID212をアプリIDリスト506から検索する処理が実行される。その結果、見つからない場合は、現在通信相手となっている専用アプリは正規の専用アプリではない可能性があると判断される。その結果、検証は失敗したとして、検証失敗時を想定した所定の処理が実行される(例えば、所定のエラーメッセージをスマートデバイスに送信する等)。本実施形態にかかる認証処理も、この時点で終了することになる。

0153

一方、アプリIDリスト506を検索した結果、APP_ID212が見つかった場合(検証に成功した場合)は、次に、認証サーバ100において、スマートデバイス200に対して、クライアント証明書要求を送信する処理が実行される(Ph3−SV-S101)。この要求を受けたスマートデバイス200では、まず、クライアント証明書214を既に有している否かの判定が行なわれる(Ph3−SD−S102)。その結果、クライアント証明書214を有していない場合は(Ph3−SD−S102でNO)、ユーザアカウントの作成処理が実行される(Ph3−SD−S103)。この処理は、上記第1の実施形態における第3フェーズ処理でのアカウント作成処理を同様である。そのため、詳細な説明は省略する。

0154

一方、既にクライアント証明書214を有している場合は(Ph3−SD−S102でYES)、上記のアカウント作成処理は行なわれない。

0155

次に、スマートデバイス200において、クライアント証明書214を認証サーバ100に返信する処理が実行される(Ph3−SD−S104)。続いて、認証サーバ100において、クライアント証明書214を検証する処理が実行される(Ph3−SV−S104)。当該検証処理は、上記第1の実施形態の第3フェーズ処理でのクライアント証明書検証処理と同様の処理が行なわれる。クライアント証明書の検証が成功すれば、次の第4フェーズの処理へと進む。

0156

次に、第4フェーズ処理の詳細について説明する。このフェーズでは、周辺機器400側で認証サーバ100について検証する処理が実行される。図25は、第2の実施形態における第4フェーズ処理の詳細を示すフローチャートである。まず、認証サーバ100において、AS_Certificate503(認証サーバ証明書)を記憶部102から読み出し、これをスマートデバイス200に送信する処理が実行される。次に、スマートデバイス200において、認証サーバ100から受信したAS_Certificate503を周辺機器400に送信する処理が実行される(Ph4-SD-S101)。つまり、スマートデバイス200を中継して、認証サーバ100から周辺機器400にAS_Certificate503が送信されることになる。

0157

次に、周辺機器400において、スマートデバイス200から受信したAS_Certificate503を、セキュアメモリ405に記憶されているAS_Sign_Pubkey601を用いて検証する処理が実行される。具体的には、AS_Certificate503の署名、すなわちSignature505を検証する処理が実行される。その結果、検証に失敗した場合は、検証失敗時を想定した所定の処理が実行され、第2の実施形態にかかる認証処理も、この時点で終了する。一方、検証に成功すれば、次の第5フェーズの処理へと進む。

0158

次に、第5フェーズ処理の詳細について説明する。図26および図27は、第2の実施形態における第5フェーズ処理の詳細を示すフローチャートである。図26および図27では、左側のフローが認証サーバ100側の処理、中央のフローがスマートデバイス(専用アプリ)側の処理、右側のフローが周辺機器400側の処理の流れを示している。このフェーズでは、主に認証サーバ100と周辺機器400との間で、第1乱数RAND1と第2乱数RAND2を交換するための処理が実行される。これらの乱数は、専用アプリと周辺機器400間の暗号化通信のために利用される共通鍵を作成するためのデータでもある。換言すれば、当該共通鍵の「種」となるデータとも言える。

0159

まず周辺機器400において、第1乱数RAND1が生成される。そして、当該第1乱数RAND1を、上記受信したAS_Certificate503に含まれているAS_Pubkey504を用いて暗号化する処理が実行される(Ph5−PP−S101)。

0160

次に、周辺機器400において、BT_Certificate603に含まれているBT_Pubkey604を、AS_Pubkey504で暗号化する処理が実行される(Ph5−PP−S102)。当該AS_Pubkey504は、上記第4フェーズ処理において認証サーバ100から送られてきたAS_Certificate503に含まれているものが用いられる。

0161

次に、周辺機器400において、上記暗号化した第1乱数RAND1、および、暗号化したBT_Pubkey604を、スマードデバイス200に送信する処理が実行される(Ph5−PP−S103)。スマートデバイス200では、これを認証サーバ100に送信する処理が実行される(Ph5−SD−S101)。つまり、暗号化された第1乱数RAND1、および、BT_Pubkey604がスマートデバイス200を経由して周辺機器400から認証サーバ100に送信されることになる。

0162

次に、認証サーバ100では、受信したBT_Pubkey604を検証する処理が実行される(Ph5−SV−S101)。具体的には、受信したBT_Pubkey604をAS_Seckey502で復号化する。そして、上記第2フェーズ処理において周辺機器400から取得したBT_Pubkey604(上記Ph2−SV−S101参照)と一致するか否かを判定する処理が行なわれる。一致すれば、検証は成功となり、不一致の場合は検証に失敗したことになる。当該検証の結果、検証に失敗した場合は、検証失敗時を想定した所定の処理が実行され、本実施形態にかかる認証処理も、この時点で終了する。

0163

一方、検証に成功した場合は、次に、認証サーバ100において、第2乱数RAND2が生成される。そして、BT_Pubkey604を用いて(上記第2フェーズ処理において取得したものでも、上記検証処理に成功したものでも、いずれを用いても良い)、当該第2乱数RAND2を暗号化する処理する処理が実行される(Ph5−SV−S102)。

0164

次に、認証サーバ100において、上記受信した第1乱数RAND1と記憶部に記憶されているAS_Pubkey504とを、上記同様にBT_Pubkey604で暗号化する処理が実行される(Ph5−SV−S103)。

0165

次に、認証サーバ100において、上記暗号化したAS_Pubkey504、第1乱数RAND1、および第2乱数RAND2をスマードデバイス200に送信する処理が実行される(Ph5−SV−S104)。スマートデバイス200では、これを周辺機器400に送信する処理が実行される(Ph5−SD−S102)。

0166

次に、周辺機器400では、スマートデバイス200経由で認証サーバ100から送られてきた上記暗号化された各データを、BT_Seckey602で復号化する処理が実行される。更に、復号化した第1乱数RAND1、および、AS_Pubkey504を検証する処理が実行される(Ph5−PP−S104)。すなわち、認証サーバ100から送られてきた第1乱数RAND1、および、AS_Pubkey504が、自身が送信したものと一致するか否かを判定することで、検証が行われる。この検証に失敗した場合は、検証失敗時を想定した所定の処理が実行される。当該検証に成功した場合は、次の第6フェーズ処理へと進む。

0167

なお、当該第5フェーズ処理において、周辺機器からBT_Pubkey604を認証サーバ100に送信しているのは、BT_Pubkey604が、いわば「発信元証明書」のような役目を有するためである。つまり、BT_Pubkey604は、その周辺機器400のみが知っている情報であり、かつ、セキュアメモリ405に記憶されているため、改ざん等の可能性も低い。そのため、発信元の証明としての信頼性は極めて高いといえる。換言すれば、セキュアメモリ405に記憶されている、周辺機器を特定可能な情報を用いて、認証サーバ100での検証を行なっている。そのため、他の実施形態では、BT_Pubkey604の代わりに、例えばBT_Certificate603全体を用いるようにしてもよい。

0168

また、他の実施形態では、上記第5フェーズ処理において、第1乱数RAND1については周辺機器400で生成せずに、認証サーバ100で生成するようにしても良い。例えば、上記Ph5−SV-S102の処理で、認証サーバ100で第1乱数RAND1と第2乱数RAND2の双方を生成し、これらをBT_Pubkey604で暗号化して周辺機器400に送信するようにしても良い。

0169

次に、第6フェーズ処理の詳細について説明する。このフェーズでは、スマートデバイス200および周辺機器400との間の暗号化通信に用いられる共通鍵Com_keyを準備(生成)するための処理が実行される。図28は、第2の実施形態における第6フェーズ処理の詳細を示すフローチャートである。図28では、左側のフローが認証サーバ100側の処理、中央のフローがスマートデバイス(専用アプリ)側の処理、右側のフローが周辺機器400側の処理の流れを示している。

0170

まず、認証サーバ100において、上記第1乱数RAND1および第2乱数RAND2を用いて、共通鍵Com_keyを生成する処理が実行される(Ph6−SV−S101)。次に、認証サーバ100において、当該共通鍵Com_keyを、クライアント公開鍵で暗号化する処理が実行されるこのクライアント公開鍵は、上記クライアント証明書に含まれているものが用いられる。そして、暗号化された共通鍵Com_keyをスマートデバイス200に送信する処理が実行される(Ph6−SV−S102)。

0171

スマートデバイス200においては、受信した共通鍵Com_keyを、自身が有するクライアント秘密鍵(クライアント証明書に含まれているもの)を用いて復号化する処理が実行される(Ph6−SD−S101)。更に、復号化した共通鍵Com_keyを記憶部204に記憶する処理も実行される。これにより、スマートデバイス200で、周辺機器400との暗号化通信に必要な共通鍵を入手できたことになる。

0172

一方、周辺機器400においては、上記第1乱数RAND1および第2乱数RAND2を用いて、共通鍵Com_keyを生成する処理が実行される(Ph6−PP−S101)。これらの乱数は、認証サーバ100で用いられているものと同じものであるため、結果として、認証サーバ100で生成されたものと同じ共通鍵Com_keyが生成されることになる。以上で、第6フェーズの処理は終了する。

0173

次に、第7フェーズの処理の詳細を説明する。このフェーズでは、主に、次回以降の認証処理を省略できるようにするため設定処理等が実行される。図29は、第2の実施形態における第7フェーズ処理の詳細を示すフローチャートである。まず、認証サーバ100において、上記第3フェー処理でスマートデバイス200から得たAPP_IDを上記共通鍵Com_keyで暗号化し、AS_Seckey502を用いて署名する処理が実行される。そして、当該暗号化したAPP_IDをスマートデバイス200に送信する処理が実行される(Ph7−SV−S101)。スマートデバイス200では、当該受信したデータを周辺機器400に送信する処理が実行される(Ph7−SD−S101)。

0174

次に、周辺機器400において、スマートデバイス200経由で認証サーバ100から送られてきた上記暗号化された共通鍵Com_keyを受信する処理が実行される。更に、上記署名を検証する処理が実行される。検証に成功すれば、上記暗号化されたAPP_IDを共通鍵Com_keyで復号化する処理が実行される。そして、これで得られたAPP_IDで既存のAPP_ID704を更新する(あるいは新規に格納する)処理が実行される(Ph7−PP−S101)。

0175

次に、周辺機器400において、ボンディング情報701を更新する処理が実行される(Ph7−SV−S102)。この処理は、上記第1の実施形態の第5フェーズ処理におけるボンディング情報の更新処理を同様である。そのため、ここでは詳細な説明は省略する。

0176

以上で、第2の実施形態にかかる認証処理は正常終了したことになる。この後は、専用アプリと周辺機器400との間の通信については、共通鍵Com_keyを用いた暗号化が行なわれる。更に、第1の実施形態と同様、ブルートゥース規格に基づく暗号化も行なわれる。つまり、2重の暗号化によって両者の間の通信が行なわれることになる。

0177

このように、第2の実施形態では、周辺機器400側にセキュアメモリ405を有する構成としている。そして、このセキュアメモリ405に鍵や証明書のデータを記憶する構成としている。換言すれば、上記共通鍵Com_keyの生成にために利用される情報がセキュアメモリ405に記憶されていることになる。このような構成により、上記第1の実施形態に比べて、認証サーバの運用コストを低減することが可能となる。例えば、第1の実施形態では、認証サーバ100の運用において、データベース113(特に、BT_Addr)の更新が必要となるが、第2の実施形態では、この更新の手間が不要となる。また、周辺機器の製造工程におけるコストを削減することも可能となる。例えば、第1の実施形態では、周辺機器の製造工程において署名(BT_Sign)を書き込む工程が必要となるが、第2の実施形態であれば、この工程が不要となる。

0178

なお、上述した実施形態では、認証サーバ100と周辺機器300(第2の実施形態では周辺機器400)との間の通信をスマートデバイス200が中継する構成を例として説明した。他の実施形態では、スマートデバイス200を介さずに、周辺機器300と認証サーバ100とで通信を行ない、認証処理を行なうようにしても良い。例えば、周辺機器300に無線LAN機能を実装し、上記認証用サーバ100と通信可能なように構成する。例えば、認証用サーバ100と接続するためのサーバのアドレス等、所定の設定を不揮発メモリ303に記憶させておく。また、周辺機器自体に、簡易なユーザインターフェース(小さな液晶画面数個の操作ボタン等)を備えておくよう構成する。ユーザは、周辺機器300の当該ユーザインターフェースを操作して、自宅内に設置されている所定のアクセスポイントに接続するような所定の設定操作を行う。そして、周辺機器300の初回起動時に、スマートデバイス200を介さずに認証サーバ100との通信を行ない、認証処理を行なうようにしてもよい(なお、この場合は、アクセスポイントという通信機器を介する構成ともいえる)。換言すれば、スマートデバイス(専用アプリ)との接続に先立って認証処理を行ない、APP_ID317を周辺機器300に記憶させることになる。このような場合、例えば、認証サーバ100のデータベースの持ち方として、BT_Addr115を主キーとしたテーブルを有するように構成しておく(いわゆるホワイトリストに相当する)。周辺機器300からは、BT_Key318、BT_Addr311、BT_Sign312、第1乱数RAND1を暗号化して認証用サーバ100に(スマートデバイスを介さずに)送信する。認証用サーバ100では、これらのデータに基づく検証を行なう。周辺機器300の正当性が確認できれば、最終的に認証用サーバ100からAPP_IDが周辺機器300に送信される。そして、これを受信した周辺機器300において、APP_ID317の更新やボンディング情報314の更新を行なうような構成としても良い。

0179

また、認証処理が実行されるタイミングについては、周辺機器300の初回起動時に限らず、例えば、専用アプリの起動をトリガとして、周辺機器300と認証サーバ100との間で認証処理を行なうような構成としても良い。専用アプリから周辺機器に接続要求が行なわれたときに、周辺機器300においてボンディング情報の有無や有効期限のチェックを行ない、その後、認証処理が必要な場合は、周辺機器300と認証サーバ100との間で、スマートデバイス200を介さない認証処理が行なわれるような構成としても良い。

0180

また、有効期限の判定に関して、上記実施例では、期限カウンタ320を用い、一日単位でカウントダウンする例を示した。この他、例えば、ボンディング情報314更新されたタイミングで、所定のカウンタに所定の値(例えば100)を設定し、周辺機器300とスマートデバイス200が接続されるたびに当該カウンタを1ずつ減らすような処理を行うようにしても良い(いわば、接続回数をカウントしている)。そして、周辺機器300とスマートデバイス200との接続時に当該カウンタが0であるか否かを判定するようにして、0であれば、上記のような認証処理の実行を要求するような構成としてもよい。このようなカウンタも、上記有効期限を示す情報であるといえる。

0181

また、認証処理を実行するタイミングに関しては、以下のようなタイミングで行われるように構成しても良い。例えば、スマートデバイスがインターネットにオンライン接続されている状態(つまり、認証サーバと通信可能な状態)であれば、周辺機器が当該スマートデバイスに接続されるたびに、上記の認証サーバを用いた認証処理を実行するようにしても良い。また、例えば、上記専用アプリがセーブデータを保存するような構成となっている場合に、当該セーブデータが消去されたときは、(その後に周辺機器と接続されたときの)上記認証サーバを用いた認証処理の実行を必須とするような構成としてもよい。

0182

また、周辺機器300に、携帯電話回線網に接続できる機能を備えるように構成し、上記のようなスマートデバイス200を介さずに、認証サーバ100とで通信を行うような構成としてもよい。この場合は、上記のようなユーザによる自宅のアクセスポイントへの接続設定作業は不要となる。

0183

また、上記説明でも少し触れていたが、認証サーバ100に記憶されるアプリテーブル114に関して、他の実施形態では、1つのBT_Addrに対して複数人分のユーザID/パスワードが登録可能なように構成しても良い。そして、このような場合、次のような制御を行なうようにしても良い。認証サーバ100において、1つの(同一の)BT_Addr115に対して登録されているユーザID116の数が、所定数を越えたか否かを判定する。その結果、ユーザID116の数が所定数を越えている場合は、該当するBT_Addr115に対応する周辺機器300の使用を許可しないような制御を行なっても良い。例えば、当該BT_Addr115を有する周辺機器300からの認証の要求が来ても、認証処理を行なわないようにする。このように構成することで、例えば、1つのBT_Addr115に対して、不自然に多くのユーザIDが登録されているような場合、BT_Addr311、BT_Sign312、Pub_key313が不正にコピーされている(すなわち純正品でない周辺機器が存在している)可能性もあるが、このような場合の被害拡大を防止することが可能となる。

0184

また、上述の例では、周辺機器300において、APP_IDは一つ分しか記憶しない例を挙げていた。これに限らず、他の実施形態では、周辺機器300において複数のAPP_IDが記憶可能なように構成しても良い。例えば、周辺機器300に対応する専用アプリA、専用アプリB、専用アプリCの3種類の専用アプリがあると想定する。このような場合、それぞれのアプリの初回起動時をトリガとして、それぞれのアプリで認証処理が行なわれ、その結果、3つの異なるAPP_IDが周辺機器に記憶されるような構成としても良い、そして、上記第1フェーズの処理において、周辺機器300側では、専用アプリから送信されてきたAPP_IDが、自身の記憶している複数のAPP_IDのいずれかと一致するか否かを判定するように構成すれば良い。

0185

また、上記の例では、スマートフォン等のスマートデバイス上で専用アプリを実行し、この専用アプリから周辺機器300を利用するという例を挙げた。このスマートデバイスに関しては、他の実施形態では、パーソナルコンピュータ等の通信機器であってもよい。また、例えば、通信機能を備えた家電製品という形での通信機器であってもよい。

0186

100認証サーバ
101 処理部
102 記憶部
103通信部
200スマートデバイス
201 処理部
202 第1通信部
203 第2通信部
204 記憶部
205 入力部
206 表示部
300周辺装置
301 通信部
302マイコン
303不揮発メモリ
304 RAM
400 周辺装置
401 通信部
402 マイコン
403 不揮発メモリ
404 RAM
405 セキュアメモリ

ページトップへ

この技術を出願した法人

この技術を発明した人物

ページトップへ

関連する挑戦したい社会課題

関連する公募課題

ページトップへ

技術視点だけで見ていませんか?

この技術の活用可能性がある分野

分野別動向を把握したい方- 事業化視点で見る -

ページトップへ

おススメ サービス

おススメ astavisionコンテンツ

新着 最近 公開された関連が強い技術

この 技術と関連性が強い技術

関連性が強い 技術一覧

この 技術と関連性が強い人物

関連性が強い人物一覧

この 技術と関連する社会課題

関連する挑戦したい社会課題一覧

この 技術と関連する公募課題

関連する公募課題一覧

astavision 新着記事

サイト情報について

本サービスは、国が公開している情報(公開特許公報、特許整理標準化データ等)を元に構成されています。出典元のデータには一部間違いやノイズがあり、情報の正確さについては保証致しかねます。また一時的に、各データの収録範囲や更新周期によって、一部の情報が正しく表示されないことがございます。当サイトの情報を元にした諸問題、不利益等について当方は何ら責任を負いかねることを予めご承知おきのほど宜しくお願い申し上げます。

主たる情報の出典

特許情報…特許整理標準化データ(XML編)、公開特許公報、特許公報、審決公報、Patent Map Guidance System データ