以下、本発明の実施の形態を図面に基づいて説明する。図1は本実施の形態の認証システムの構成の一例を示すブロック図である。本実施の形態の認証システムは、セキュアエレメント50が組み込まれたデバイス100、及びサーバ200などを備える。デバイス100は、「モノのインターネット」(IoT)でいうところの「モノ」に該当するデバイス(電子デバイスとも称する)を含む。デバイス100とサーバ200とは、インターネット等のネットワーク1を介して接続される。デバイス100は、人手を介さずにネットワーク1に自動接続され、サーバ200へ自動的にリクエスト(要求情報)を送信する。なお、本実施の形態では、デバイス100がサーバ200へ自動的にリクエストを送信する前に、後述のセキュアエレメント50による認証処理が行われ、デバイス100は、セキュアエレメント50から返信された署名付きリクエストをサーバ200に送信する。
デバイス100は、セキュアエレメント50の他に、デバイス本体10を備える。デバイス本体10とセキュアエレメント50との間は、I2C(Inter-Integrated Circuit)、SPI(Serial Peripheral Interface)等の通信路30で物理的に接続されている。なお、セキュアエレメント50は、UICC(Universal Integrated Circuit Card)のように着脱可能な構成とすることもできる。
デバイス本体10は、CPU11、ネットワーク通信部12、リクエスト生成部13、インタフェース部14などを備える。
CPU11は、デバイス本体10全体の制御、セキュアエレメント50との間の通信制御などを行う。
ネットワーク通信部12は、デバイス100をネットワークに接続する機能を有し、ネットワーク1上のサーバ200との間で情報の送受信を行うことができる。ネットワーク通信部12は、不図示のセンサ類で検出した情報を送信することができる。また、ネットワーク通信部12は、送信部としての機能を有し、インタフェース部14がセキュアエレメント50から取得した要求情報をサーバ200へ送信する。
リクエスト生成部13は、要求情報生成部としての機能を有し、データの送信又は受信を要求する要求情報を生成する。例えば、デバイス100が、ネットワーク上のサーバ200へデータを送信する場合、リクエスト生成部13は、送信したい当該データを含む所定の形式の要求情報を生成する。以下では、要求情報をリクエストと称し、要求情報の内容をリクエストメッセージ(リクエストの内容)と称する。
インタフェース部14は、通信路30を介してセキュアエレメント50との間のインタフェース機能を有する。インタフェース部14は、リクエスト生成部13で生成したリクエストをセキュアエレメント50へ出力する。また、インタフェース部14は、要求情報取得部としての機能を有し、セキュアエレメント50が生成した認証情報(署名)が添付されたリクエストをセキュアエレメント50から取得する。
セキュアエレメント50は、リクエスト検証処理部51、リクエスト署名処理部52、インタフェース部53、秘密鍵54、カウンタ55、ブロック状態フラグ56などを備える。
インタフェース部53は、通信路30を介してデバイス本体10との間のインタフェース機能を有する。インタフェース部53は、取得部としての機能を有し、デバイス本体10(リクエスト生成部13)が生成したリクエストを取得する。
リクエスト検証処理部51は、判定部としての機能を有し、インタフェース部53で取得したリクエストが正当であるか否か(正当性)を判定する。リクエスト検証処理部51は、リクエストメッセージを解析して、リクエストの正当性を判定する。判定処理の詳細は後述する。
リクエスト署名処理部52は、生成部としての機能を有し、リクエスト検証処理部51でリクエストが正当であると判定した場合、リクエストを認証する認証情報を生成する。なお、以下では、認証情報を署名と称する。リクエスト署名処理部52は、リクエストメッセージに生成した署名を添付する処理を行う。署名生成の詳細は後述する。
インタフェース部53は、出力部としての機能を有し、リクエスト署名処理部52で署名が添付されたリクエストをデバイス本体10へ出力する。
カウンタ55は、計数部としての機能を有し、インタフェース部53で正当でないリクエストを取得した回数を計数する。カウンタ55は、リクエスト検証処理部51が行う検証処理の回数を再試行可能な回数まで計数する。カウンタ55の計数値は、例えば、正又は0の整数とすることができる。最初は、計数値をある特定の初期値(正の整数)に設定し、不正なリクエストが取得される都度、1を減算する。計数値が0になると、ブロック状態フラグ56の状態を「ブロック」に遷移する。なお、計数値の初期値を0に設定しておき、不正なリクエストが取得される都度、1を加算し、計数値が所定の閾値(正の整数)になると、ブロック状態フラグ56の状態を「ブロック」に遷移するようにしてもよい。
ブロック状態フラグ56は、「ブロック」及び「非ブロック」の二値の状態を保持する。ブロック状態フラグ56は、初期値として「非ブロック」が設定されている。ブロック状態フラグ56は、停止部としての機能を有し、「ブロック」の状態になると、リクエスト検証処理部51及びリクエスト署名処理部52の少なくとも一方の処理を停止する。
秘密鍵54は、リクエスト署名処理部52で署名を生成する際に用いられる。
セキュアエレメント50は、耐タンパ性を有する。セキュアエレメント50の機能(例えば、リクエスト検証処理部51、リクエスト署名処理部52、秘密鍵54など)をハードウェアのモジュールで実現する場合、耐タンパ性を有するためには、セキュアエレメント50を1チップ化にしてもよく、あるいは、モジュール表面をコーティングしてもよい。また、セキュアエレメント50の機能をソフトウェアのモジュールで実現する場合、耐タンパ性を有するためには、実行コードを暗号化し、実行時に必要な部分だけをメモリ上で復号するようにすればよい。
セキュアエレメント50を耐タンパ性にすることによって、署名生成処理において使用する秘密鍵等の機密情報、あるいは署名生成処理自体を物理的に保護することができる。
サーバ200は、リクエスト署名処理部201、通信部202、秘密鍵203、リクエスト署名抽出部204、接続可否判定部205などを備える。なお、図1の例では、セキュアエレメント50の秘密鍵54に対応する鍵として、秘密鍵203を図示しており、共通鍵方式を例示しているが、秘密鍵54に対応する鍵としては、公開鍵方式の場合のように公開鍵とすることもできる。
通信部202は、ネットワーク1を介してデバイス100との間の通信機能を有する。通信部202は、取得部としての機能を有し、セキュアエレメント50が生成した署名が添付されたリクエストをデバイス本体10から取得する。なお、通信部202は、セキュアエレメント50が生成した署名が添付されたリクエストを直接セキュアエレメント50から取得することもできる。
リクエスト署名処理部201は、生成部としての機能を有し、通信部202で取得したリクエスト(セキュアエレメント50が生成した署名が添付されたリクエスト)を認証する署名を生成する。より具体的には、リクエスト署名処理部201は、取得したリクエストからセキュアエレメント50が生成した署名を取り除いた部分に対して、リクエスト署名処理部52と同じアルゴリズム及び秘密鍵203を用いて署名を生成する。
リクエスト署名抽出部204は、抽出部としての機能を有し、通信部202で取得したリクエスト(セキュアエレメント50が生成した署名が添付されたリクエスト)からセキュアエレメント50が生成した署名を抽出する。
接続可否判定部205は、判定部としての機能を有し、リクエスト署名処理部201で生成した署名及びリクエスト署名抽出部204で抽出した署名に基づいて、デバイス100との接続可否を判定する。例えば、リクエスト署名処理部201で生成した署名とリクエスト署名抽出部204で抽出した署名とが一致する場合、デバイス100が送信したリクエストが正当なものであるとしてデバイス100のサーバ200への接続を許可する。また、リクエスト署名処理部201で生成した署名とリクエスト署名抽出部204で抽出した署名とが一致しない場合、デバイス100が送信したリクエストは不正なものであるとしてデバイス100のサーバ200への接続を許可しない。これにより、デバイス100の認証の正当性を確保することができる。
図2は本実施の形態の認証システムのリクエスト認証時の動作の一例を示す説明図である。以下、符号P1〜P8で示す処理について説明する。以下では、デバイス100とサーバ200との間のプロトコルをHTTP(Hyper Text Transfer Protocol)とし、リクエストメッセージの形式として、HTTPリクエストを例として説明するが、プロトコル及びリクエストは、これに限定されない。
P1(リクエストの生成):デバイス本体10は、ネットワーク1上のサーバ200に対して送信したい情報を、単一のリクエストメッセージ(HTTP等)とするリクエストを生成する。
P2(リクエストをセキュアエレメント50へ送信):デバイス本体10は、生成したリクエストを物理的な通信路30を介してセキュアエレメント50へ送信(出力)する。
P3(リクエストの正当性を検証):セキュアエレメント50は、デバイス本体10から取得したリクエストを所定のアルゴリズムを用いて検証(判定)する。所定のアルゴリズムについては後述する。デバイス本体10から取得したリクエストが正当である場合、セキュアエレメント50は、後述のP4の署名生成処理を行う。デバイス本体10から取得したリクエストが不正である場合、セキュアエレメント50は、処理を終了する。
P4(署名を生成):セキュアエレメント50は、内部に保持している秘密鍵54を用い、所定のアルゴリズムを用いて署名を生成し、取得したリクエストに生成した署名を添付する。所定のアルゴリズムについては後述する。
P5(署名付きリクエストをデバイス本体10へ返信):セキュアエレメント50は、署名を添付したリクエストをデバイス本体10に返信(出力)する。
P6(署名付きリクエストをサーバ200へ送信):デバイス100は、セキュアエレメント50から取得した署名付きリクエストを、そのままサーバ200へ送信する。これにより、セキュアエレメント50から返信された署名付きリクエストをそのままサーバ200へ送信(転送)するだけで、デバイス100は、ネットワーク1上のサーバ200に接続するための認証を行うことができる。
P7(受信したリクエストから署名を生成):サーバ200は、受信した署名付きリクエストのリクエストメッセージの本体部分から、セキュアエレメント50が実行したアルゴリズムと同一のアルゴリズム及び秘密鍵203を用いて署名を生成する。
P8(署名を照合して接続可否を判定):サーバ200は、受信した署名付きリクエストのリクエストメッセージ内の署名(添付された署名)と、上述のP7において自ら生成した署名とを照合する。両者が一致する場合、デバイス100からのリクエストは正当なものであるとして接続を許可する。両者が一致しない場合、デバイス100からのリクエストは不正なものであるとして接続を許可しない。
本実施の形態の認証システムを実現するにあたっては、リクエストメッセージの形式、通信プロトコル、セキュアエレメント50でのリクエスト検証アルゴリズム、セキュアエレメント50及びサーバ200でのリクエスト署名アルゴリズムなどの要素技術を用いる。この場合、かかる要素技術として何を用いるかは適宜決定することができる。本実施の形態では、かかる要素技術として、以下のものを一例として説明する。
リクエストメッセージの形式として、HTTPリクエストを用いる。HTTPリクエストは、Web技術に広く用いられているプロトコルに基づくリクエストである。デバイス100とサーバ200との間の通信プロトコルとして、HTTPを用いる。なお、プロトコルは、HTTPに限定されるものではなく、MQTT(Message Queue Telemetry Transport)、AMQP(Advanced Message Queue Protocol)などの他のプロトコルを用いることもできる。セキュアエレメント50でのリクエスト検証アルゴリズム、セキュアエレメント50及びサーバ200でのリクエスト署名アルゴリズムについては後述する。
次に、リクエストの内容、及びリクエスト検証アルゴリズムについて説明する。
図3は本実施の形態の認証システムで用いるリクエストメッセージの一例を示す説明図である。上段の枠で囲まれた文字列は、HTTPリクエストメッセージの一例を示す。HTTPリクエストメッセージは、テキスト形式のデータである。符号Aで囲まれたデータは、URLであり、HTTP通信時に接続先を特定するための文字列である。図3では、URLの部分を抜き出して図示している。符号Bで囲まれたデータは、HTTPヘッダであり、HTTPリクエストの意味を表す情報である。HTTPヘッダは、ネットワーク1上のサーバのホスト名(HOST)、ペイロード長(Content-length)等、技術仕様を定めるRFC(Request for Comments)7230で規定された情報の他に、任意の拡張が可能である。図3では、HTTPヘッダの部分を抜き出して図示している。また、符号Cで囲まれたデータは、ペイロードであり、HTTP上で授受されるデータ本体である。Webページの閲覧用途では、HTML(Hyper Text Markup Language)で記述されたWebページコンテンツが格納されることが多いが、IoT用途では、例えば、JSON(Java Script(登録商標) Object Notation)等で記述された、何らかの構造化データであることが多い。図3では、ペイロードの部分を抜き出して図示している。
図4は本実施の形態の認証システムで用いるリクエスト検証アルゴリズムの一例を示す説明図である。セキュアエレメント50(リクエスト検証処理部51)は、HTTPリクエストをデバイス本体10から取得すると、HTTPリクエストに含まれるURL、HTTPヘッダ、ペイロードについて文字列のチェックを行う。セキュアエレメント50におけるポリシー(アクセスポリシー)に基づくチェック内容に応じて、リクエスト検証アルゴリズムは適宜決定することができるが、図4はその一例を示す。
ポリシーが、接続先ネットワークサーバ名による制限である場合、チェック処理は、URLに”hogehoge.co.jp”が含まれていない場合、不正なリクエストとする。これにより、例えば、攻撃者が詐取したデバイスによって不正なリクエスト(例えば、攻撃者のサーバへの接続)をネットワーク上に送信しようとした場合、セキュアエレメント50は、正当なリクエストではないと判定することができ、不正な要求情報の送信を抑止することが可能となる。
また、ポリシーが、接続先サービス(フォルダ名、クエリ文字列等)による制限である場合、チェック処理は、URLに”fugafuga”(フォルダ名)が含まれていない場合、あるいはクエリ文字列cmdで示される値が自然数(1〜)でない場合、不正なリクエストとする。
また、ポリシーが、HTTPヘッダの任意の属性による制限である場合、チェック処理は、HTTPヘッダX-Admin-Protocolの値が”globalplatform-remote-admin/1.1.1”でない場合、不正なリクエストとする。また、ポリシーが、ペイロードの内容による制限である場合、チェック処理は、ペイロードに”01”が含まれていない場合、不正なリクエストとする。なお、リクエスト検証アルゴリズムは、図4に示すチェック処理をすべて用いてもよく、一部だけを用いてもよい。なお、ポリシー例及びチェック処理の例は、図4に示すものに限定されない。
上述のように、リクエスト検証処理部51は、特定部としての機能を有し、リクエストの所定箇所(図3の例では、URL、HTTPヘッダ、ペイロード)に含まれるテキスト形式の対象情報を特定する。図3の例では、対象情報は、URL、HTTPヘッダ、ペイロードとして抽出される文字列である。なお、所定箇所は、リクエストが正当であるか否かを判定する際に判定可能な箇所であればよい。
リクエスト検証処理部51は、特定した対象情報に基づいてリクエストが正当であるか否かを判定する。これにより、リクエストメッセージの全体を判定対象とする必要がなくなり、処理労力を軽減することができる。
次に、リクエスト署名アルゴリズムについて説明する。
図5は本実施の形態の認証システムでの署名生成の流れの一例を示す説明図である。リクエスト検証処理部51によってリクエストが正当であると判定された場合、セキュアエレメント50(リクエスト署名処理部52)は、当該リクエストに対して署名を生成し、生成した署名を当該リクエストに添付する。以下、符号P11〜P14で示す処理について説明する。
P11(ペイロードに対するハッシュ演算):セキュアエレメント50は、元の(取得した)HTTPリクエストメッセージに含まれるペイロードに対してSHA−256演算を行ってハッシュ値を計算する。
リクエスト署名処理部52は、抽出部としての機能を有し、取得したHTTPリクエストから所定の認証用情報(図5の例では、ペイロードの部分)を抽出する。
P12(ハッシュ値の連結):セキュアエレメント50は、HTTPリクエスト(ペイロード以外)と、P11で計算したハッシュ値とを連結する。
P13(HMAC−SHA−256演算による署名生成):セキュアエレメント50は、P12で連結した文字列を入力とし、鍵値を指定してHMAC−SHA−256演算を行って署名を生成する。これにより、セキュアエレメント50は、リクエストに対して認証機能を提供することができる。
P14(元のリクエストに署名を添付):セキュアエレメント50は、元のHTTPリクエストにヘッダ”Signature”を加え、生成した署名を添付する。
セキュアエレメント50は、上述の手順によって、HTTPリクエストに生成した署名を添付し、デバイス本体10へ返信する。デバイス本体10は、署名付きHTTPリクエストをそのままサーバ200へ送信する。
サーバ200は、受信したHTTPリクエストからヘッダ”Signature”を取り除いた文字列に対して、図5と同一の演算を行う。サーバ200が生成した署名と、HTTPリクエストのヘッダ”Signature”指定の値とが同一である場合、サーバ200は、デバイス100からのHTTPリクエストが正当であると判定して、デバイス100との接続を許可する。
リクエスト署名処理部52は、サーバ200がリクエスト(デバイス100が送信したリクエスト)を認証する際に使用する秘密鍵203と同じ秘密鍵54に基づいて署名を生成する。これにより、サーバ200が、セキュアエレメント50が署名を生成する所定のアルゴリズムと同じアルゴリズムを用いることによって、サーバ200は、セキュアエレメント50が生成した署名と同じ署名を生成するので、デバイス100からのリクエストが正当なものであるとして接続が許可される。
図6は本実施の形態のセキュアエレメント50の処理手順の一例を示すフローチャートである。セキュアエレメント50は、デバイス本体10からリクエストを取得し(S11)、ブロック状態フラグ56を判定する(S12)。ブロック状態フラグ56の初期値は非ブロックとすることができる。ブロック状態フラグ56が非ブロックである場合(S12で非ブロック)、セキュアエレメント50は、リクエストは正当であるか否かを判定する(S13)。
リクエストが正当である場合(S13でYES)、セキュアエレメント50は、カウンタ55を最大値に設定する(S14)。最大値は、リクエスト検証処理の再試行可能な回数とすることができる。
セキュアエレメント50は、署名を生成し(S15)、署名付きリクエストをデバイス本体10へ出力し(S16)、処理を終了する。
リクエストが正当でない場合(S13でNO)、セキュアエレメント50は、カウンタ55を1減算し(S17)、カウンタ値が0であるか否かを判定する(S18)。カウンタ値が0である場合(S18でYES)、セキュアエレメント50は、ブロック状態フラグ56をブロックに設定し(S19)、処理を終了する。これにより、セキュアエレメント50は、以降のデバイス本体10からのリクエストに対して、リクエスト検証処理を実施しない。不正なリクエストを送信するような攻撃が複数回続いた場合、リクエスト検証処理部51及びリクエスト署名処理部52の少なくとも一方の処理を停止するので、攻撃者が不正なリクエストを送信することを確実に防止することができる。
カウンタ値が0でない場合(S18でNO)、あるいは、ブロック状態フラグ56がブロックである場合(S12でブロック)、セキュアエレメント50は、処理を終了する。なお、デバイス本体10が、リクエストをセキュアエレメント50へ出力する都度、図6の処理が繰り返される。
図6に示すような処理手順を定めたコンピュータプログラムをRAMにロードし、CPU(プロセッサ)により当該コンピュータプログラムを実行させることにより、セキュアエレメント50の各処理をコンピュータプログラムによって実現することができる。
上述のように、本実施の形態によれば、デバイス100は、セキュアエレメント50によって認証されたリクエストをネットワーク1上のサーバ200へ送信することができるので、デバイス100がネットワーク1上のサーバ200に接続するための認証を行うことができ、またデバイス100の認証の正当性を確保することができる。
また、本実施の形態によれば、攻撃者が詐取したデバイスによって不正なリクエスト(例えば、攻撃者のサーバへの接続)をネットワーク上に送信しようとした場合、セキュアエレメント50は、正当なリクエストではないと判定して署名を生成しないので、不正なリクエストの送信を抑止することができる。
本実施の形態によれば、IoTに用いられるデバイス100自身が、ネットワーク1上のサーバ200へ接続するための認証情報を保持する場合、セキュアエレメント50を備えることにより、認証情報を安全に保持することができる。また、デバイス100が、ネットワーク1上のサーバ200に対してリクエストを送信する場合、セキュアエレメント50による署名生成処理によって、当該リクエストの正当性を確保することができる。
本実施の形態では、セキュアエレメント50が署名付きリクエストをデバイス本体10へ出力し、デバイス本体10を介してリクエストをサーバ200へ送信する構成であるが、これに限定されるものではない。例えば、セキュアエレメント50が署名付きリクエストを直接サーバ200へ送信するようにしてもよい。いずれの場合も、サーバ200は、セキュアエレメント50によって認証された当該デバイス100に係るリクエストを取得することができる。
本実施の形態では、リクエストはテキスト形式であったが、これに限定されない。例えば、リクエストがバイナリ形式であっても、本実施の形態を適用して、リクエスト検証処理、署名生成処理を行うことができる。
本実施の形態では、署名生成のアルゴリズムに、SHA−256演算、HMAC−SHA−256演算を用いる構成であったが、ハッシュ関数、暗号ハッシュ関数は、これらに限定されるものではなく、適宜のものを使用することができる。また、ハッシュ関数、暗号ハッシュ関数に代えて、他の暗号化処理を用いることもできる。また、秘密鍵は、共通鍵方式に限定されるものではなく、RSA等の公開鍵暗号方式で用いられる非対称鍵(公開鍵で暗号化、秘密鍵で復号、あるいはその逆)でもよい。
本実施の形態に係るセキュアエレメントは、データの送信又は受信を要求する要求情報を生成するデバイス本体から要求情報を取得する取得部と、該取得部で取得した要求情報が正当であるか否かを判定する判定部と、該判定部で正当であると判定した場合、前記要求情報を認証する認証情報を生成する生成部と、該生成部で生成した認証情報を添付した前記要求情報を出力する出力部とを備える。
本実施の形態に係るコンピュータプログラムは、コンピュータに、データの送信又は受信を要求する要求情報を出力させるためのコンピュータプログラムであって、コンピュータに、前記要求情報を生成するデバイス本体から要求情報を取得する処理と、取得した要求情報が正当であるか否かを判定する処理と、正当であると判定した場合、前記要求情報を認証する認証情報を生成する処理と、生成した認証情報を添付した前記要求情報を出力する処理とを実行させる。
本実施の形態に係るデバイスは、本実施の形態に係るセキュアエレメントを備える。
本実施の形態に係るセキュアエレメントによる認証方法は、データの送信又は受信を要求する要求情報を生成するデバイス本体から要求情報を取得部が取得し、取得された要求情報が正当であるか否かを判定部が判定し、前記要求情報が正当であると判定された場合、前記要求情報を認証する認証情報を生成部が生成し、生成された認証情報を添付した前記要求情報を出力部が出力する。
取得部は、データの送信又は受信を要求する要求情報を生成するデバイス本体から要求情報を取得する。要求情報をリクエストとも称し、要求情報の内容をリクエストメッセージ(リクエストの内容)とも称する。例えば、デバイスが、ネットワーク上のサーバへデータを送信する場合、デバイスは、送信したい当該データを含む所定の形式の要求情報を生成する。取得部は、デバイスが生成した要求情報を取得する。なお、デバイスのうちセキュアエレメント以外の部分をデバイス本体と称する。
判定部は、取得部で取得した要求情報が正当であるか否かを判定する。要求情報が正当であるか否かは、要求情報に含まれる個々の情報が正当であるか否かによって判定することができる。一例としては、要求情報が送信される送信先(デバイスの接続先)が正当なサーバであるか否かに応じて、要求情報が正当であるか否かを判定することができる。これにより、例えば、攻撃者が詐取したデバイスによって不正な要求情報(例えば、攻撃者のサーバへの接続)をネットワーク上に送信しようとした場合、セキュアエレメントは、正当な要求情報ではないと判定することができ、不正な要求情報の送信を抑止することが可能となる。
生成部は、判定部で正当であると判定した場合、要求情報を認証する認証情報を生成する。認証情報は、署名又は署名値とも称される。認証情報の生成は、例えば、セキュアエレメントが保持する秘密鍵及び所定のアルゴリズムによって行うことができる。
出力部は、生成部で生成した認証情報を添付した要求情報を出力する。すなわち、出力部は、デバイス本体から取得した要求情報に生成された認証情報を添付して得られた要求情報(認証情報付き要求情報)をデバイス本体へ出力する。これにより、デバイスは、セキュアエレメントによって認証された要求情報をネットワーク上のサーバへ送信することができるので、デバイスがネットワーク上のサーバに接続するための認証を行うことができ、またデバイスの認証の正当性を確保することができる。
本実施の形態に係るセキュアエレメントにおいて、前記生成部は、前記判定部で正当でないと判定した場合、認証情報を生成しない。
生成部は、判定部で正当でないと判定した場合、認証情報を生成しない。例えば、攻撃者が詐取したデバイスによって不正な要求情報(例えば、攻撃者のサーバへの接続)をネットワーク上に送信しようとした場合、セキュアエレメントは、正当な要求情報ではないと判定して認証情報を生成しない。出力部は、認証情報付き要求情報を出力しないので、不正な要求情報の送信を抑止することができる。
本実施の形態に係るセキュアエレメントは、前記取得部で正当でない要求情報を取得した回数を計数する計数部と、該計数部で計数した回数に応じて前記判定部又は生成部での処理を停止する停止部とを備える。
計数部は、取得部で正当でない要求情報を取得した回数を計数する。なお、計数の方法は、初期値(≠0)から取得の都度、1を減算してもよく、初期値(=0)から取得の都度、1を加算してもよい。
停止部は、計数部で計数した回数に応じて判定部又は生成部での処理を停止する。例えば、正当でない要求情報を取得する都度、1を減算し計数値が0になった場合、判定部又は生成部での処理を停止する。あるいは、正当でない要求情報を取得する都度、1を加算し計数値が所定の閾値(≠0)になった場合、判定部又は生成部での処理を停止する。これにより、不正な要求情報を送信するような攻撃が複数回続いた場合、判定部又は生成部での処理を停止するので、攻撃者が要求情報を送信することを確実に防止することができる。
本実施の形態に係るセキュアエレメントは、前記要求情報の所定箇所に含まれるテキスト形式又はバイナリ形式の対象情報を特定する特定部を備え、前記判定部は、前記特定部で特定した対象情報に基づいて前記要求情報が正当であるか否かを判定する。
特定部は、要求情報の所定箇所に含まれるテキスト形式又はバイナリ形式の対象情報を特定する。すなわち、特定部は、要求情報の内容全体の中から所定箇所にある対象情報を特定する。所定箇所は、要求情報が正当であるか否かを判定する際に判定可能な箇所であればよい。
判定部は、特定部で特定した対象情報に基づいて要求情報が正当であるか否かを判定する。これにより、要求情報の全体を判定対象とする必要がなくなり、処理労力を軽減することができる。
本実施の形態に係るセキュアエレメントにおいて、前記生成部は、デバイスが送信する要求情報を受信するサーバが該要求情報を認証する際に使用する鍵に対応する秘密鍵に基づいて認証情報を生成する。
生成部は、デバイスが送信する要求情報を受信するサーバが当該要求情報を認証する際に使用する鍵に対応する秘密鍵に基づいて認証情報を生成する。秘密鍵に対応する鍵は、共通鍵方式の場合には秘密鍵とし、公開鍵方式の場合には公開鍵とすることができる。これにより、サーバが、セキュアエレメントが認証情報を生成する所定のアルゴリズムと同じアルゴリズムを用いることによって、サーバは、セキュアエレメントが生成した認証情報と同じ認証情報を生成するので、デバイスからの要求情報が正当なものであるとして接続が許可される。
本実施の形態に係るセキュアエレメントは、前記取得部で取得した要求情報から所定の認証用情報を抽出する抽出部を備え、前記生成部は、該抽出部で抽出した認証用情報を入力とし、秘密鍵を用いた鍵付きハッシュ関数を適用して認証情報を生成する。
抽出部は、取得部で取得した要求情報から所定の認証用情報を抽出する。認証用情報は、例えば、送信又は受信されるデータ(データ本体)とすることができる。
生成部は、抽出部で抽出した認証用情報を入力とし、秘密鍵を用いた鍵付きハッシュ関数を適用して認証情報を生成する。例えば、抽出部で抽出した認証用情報に対してハッシュ関数を適用して得られたハッシュ値を、認証用情報以外の要求情報に連結し、連結した情報を入力とし、秘密鍵を用いた鍵付きハッシュ関数を適用して得られた結果を認証情報とすることができる。これにより、要求情報に対して認証機能を提供することができる。
本実施の形態に係るセキュアエレメントにおいて、前記出力部は、前記生成部で生成した認証情報を添付した前記要求情報を前記デバイス本体又はデバイスが送信する要求情報を受信するサーバのいずれか一方へ出力する。
出力部は、生成部で生成した認証情報を添付した要求情報をデバイス本体又はデバイスが送信する要求情報を受信するサーバのいずれか一方へ出力する。生成部で生成した認証情報を添付した要求情報をデバイス本体へ出力すると、デバイスは、認証情報付き要求情報をサーバへ送信することができる。これにより、サーバは、セキュアエレメントによって認証された当該デバイスに係る要求情報を取得することができる。
本実施の形態に係るセキュアエレメントにおいて、前記セキュアエレメントは、耐タンパ性を有する。
セキュアエレメントは、耐タンパ性を有する。セキュアエレメントの機能(例えば、特に、生成部、秘密鍵など)をハードウェアのモジュールで実現する場合、耐タンパ性を有するためには、セキュアエレメントを1チップ化にする、モジュール表面をコーティングすることが含まれる。また、セキュアエレメントの機能をソフトウェアのモジュールで実現する場合、耐タンパ性を有するためには、実行コードを暗号化し、実行時に必要な部分だけをメモリ上で復号することが含まれる。
セキュアエレメントを耐タンパ性にすることによって、認証情報の生成処理、認証情報の生成に使用する秘密鍵等の機密情報を物理的に保護することができる。
本実施の形態に係るデバイスは、データの送信又は受信を要求する要求情報を生成する要求情報生成部と、前記セキュアエレメントが生成した認証情報が添付された要求情報を取得する要求情報取得部と、該要求情報取得部で取得した要求情報をサーバへ送信する送信部とを備える。
要求情報生成部は、データの送信又は受信を要求する要求情報を生成する。デバイスが、ネットワーク上のサーバへデータを送信する場合、デバイスは、送信したい当該データを含む所定の形式の要求情報を生成する。
要求情報取得部は、セキュアエレメントが生成した認証情報が添付された要求情報を取得する。送信部は、要求情報取得部で取得した要求情報をサーバへ送信する。
これにより、セキュアエレメントから返信された認証情報付き要求情報をそのままサーバへ送信(転送)するだけで、デバイスは、ネットワーク上のサーバに接続するための認証を行うことができる。
本発明の実施の形態に係るサーバは、セキュアエレメントが生成した認証情報が添付された要求情報を前記セキュアエレメント又はデバイス本体から取得する取得部と、該取得部で取得した要求情報を認証する認証情報を生成する生成部と、前記取得部で取得した要求情報に添付された認証情報を抽出する抽出部と、前記生成部で生成した認証情報及び前記抽出部で抽出した認証情報に基づいて、デバイスとの接続可否を判定する判定部とを備える。
取得部は、セキュアエレメントが生成した認証情報が添付された要求情報をセキュアエレメント又はデバイス本体から取得する。
生成部は、取得部で取得した要求情報を認証する認証情報を生成する。認証情報の生成は、セキュアエレメントによる認証情報の生成のためのアルゴリズム及び秘密鍵を用いる。
抽出部は、取得部で取得した要求情報に添付された認証情報を抽出する。
判定部は、生成部で生成した認証情報及び抽出部で抽出した認証情報に基づいて、デバイスとの接続可否を判定する。例えば、生成部で生成した認証情報と抽出部で抽出した認証情報とが一致する場合、デバイスが送信した要求情報が正当なものであるとしてデバイスのサーバへの接続を許可する。また、生成部で生成した認証情報と抽出部で抽出した認証情報とが一致しない場合、デバイスが送信した要求情報は不正なものであるとしてデバイスのサーバへの接続を許可しない。これにより、デバイスの認証の正当性を確保することができる。