JP6790839B2

JP6790839B2 - セキュアエレメント、ｕｉｍカード、認証方法、及び認証プログラム

Info

Publication number: JP6790839B2
Application number: JP2017001249A
Authority: JP
Inventors: 歩小林
Original assignee: Dai Nippon Printing Co Ltd
Current assignee: Dai Nippon Printing Co Ltd
Priority date: 2017-01-06
Filing date: 2017-01-06
Publication date: 2020-11-25
Anticipated expiration: 2037-01-06
Also published as: JP2018113504A

Description

ＩＣチップ等のセキュアエレメント（Secure Element）の技術分野に関する。

近年、指紋、虹彩、静脈といった生体情報を取得するための生体センサがスマートフォン等に内蔵されることが増えてきている。生体センサがスマートフォン等に搭載されることにより、従来のパスワード認証に代えて又は加えて、生体情報による生体認証が実現可能となる。

一方で、生体認証の多くは生体情報をサーバで管理し、サーバにおいて認証（生体情報の照合）をすることが多い。この場合、スマートフォン等に生体情報を格納しておく必要がなく、セキュアなサーバで一元管理できるメリットがある。しかしながら、生体認証を用いたサービスが増える度に、サービスプロバイダー側のサーバに生体情報を管理する必要が出てくるため、個人の生体情報があらゆる場所で管理されるデメリットがある。また、生体情報を一元管理するサーバは標的型攻撃の対象にされる可能性が高くなり、生体情報を扱うサービスプロバイダー側のリスクや管理負担も増加する。

ところで、スマートフォン等にはセキュアエレメントとしてのＵＩＭ（User Identity Module）カードが挿入されているか、あるいは埋込型のセキュアエレメントが内蔵されており、セキュアエレメントにおいて電話番号などの機密情報を管理している。セキュアエレメントは、故障解析攻撃や電力解析攻撃などに耐性があり、暗号用の鍵などの重要なデータの保管、あるいは鍵を使った認証処理などをセキュアに行うことに向いている。

故にＵＩＭ（セキュアエレメント）は、生体情報を格納するストレージとして利用するのに有効である。例えば、特許文献１には、ＵＩＭが生体情報を管理するとともに、認証処理を行うことが開示されている。

特開２０１０−１４０１７４号公報

しかしながら、ＵＩＭ（セキュアエレメント）は、ＣＰＵの性能がスマートフォンのそれと比較して劣るため、生体認証に必要な特徴量抽出等の処理を行うことが困難である。こうした問題を解決するために生体情報の質を落として認証を行うことも考えられるが、認証精度が低下するという問題がある。

そこで、本発明は、サーバで生体情報を管理せずにすむように自ら生体情報を管理し、且つ、認証精度を下げることなく生体認証を行うことができるとともに、生体認証の結果を外部デバイスに安全に送信することができるセキュアエレメント等を提供することを目的とする。

上記課題を解決するために、請求項１に記載の発明は、処理部と記憶部を備え、利用者の認証の結果を外部デバイスに送信するセキュアエレメントであって、前記記憶部は前記認証を行うための認証プログラムを記憶し、前記認証プログラムは前記処理部を、前記利用者毎に、当該利用者の生体情報から抽出された特徴量データと、当該利用者の利用者ＩＤを取得する取得手段、前記利用者毎に、公開鍵暗号方式により秘密鍵及び公開鍵を生成する生成手段、前記利用者毎に、前記取得手段が取得した利用者ＩＤ及び特徴量データと、前記生成手段が生成した秘密鍵を対応付けて前記記憶部に記憶させる登録手段、前記利用者毎に、当該利用者について生成された公開鍵を、前記外部デバイスに送信する第１送信手段、前記外部デバイスから、認証対象である利用者に対応する利用者ＩＤと、当該認証対象である利用者の生体情報から抽出された特徴量データを受信し、前記記憶部に当該認証対象である利用者に対応する利用者ＩＤと同一の利用者ＩＤと対応付けて登録されている特徴量データと、当該受信した特徴量データを照合して当該利用者の認証を行う認証手段、前記認証対象である利用者に対応する利用者ＩＤと同一の利用者ＩＤと対応付けて登録されている秘密鍵を用いて署名データを作成する作成手段、前記認証対象である利用者に対応する利用者ＩＤの送信元である前記外部デバイスに対して、前記認証の結果と前記署名データを送信する第２送信手段、として機能させることを特徴とする。

請求項２に記載の発明は、請求項１に記載のセキュアエレメントであって、前記取得手段は、前記外部デバイスが提供するサービスを識別するためのサービスＩＤを更に取得し、前記登録手段は、前記利用者ＩＤ、前記特徴量データ及び前記秘密鍵と対応付けて前記サービスＩＤを更に登録し、前記第１送信手段は、前記公開鍵を前記外部デバイスで動作するプログラムに対して送信し、前記認証手段は、前記外部デバイスで動作するプログラムから、当該プログラムのサービスＩＤを更に受信し、受信した利用者ＩＤ及びサービスＩＤと同一の利用者ＩＤ及びサービスＩＤと対応付けて前記記憶部に登録されている特徴量データと、受信した特徴量データを照合して当該利用者の認証を行い、前記作成手段は、受信した利用者ＩＤ及びサービスＩＤと同一の利用者ＩＤ及びサービスＩＤと対応付けて前記記憶部に登録されている秘密鍵を用いて署名データを作成し、前記第２送信手段は、前記認証対象である利用者に対応する利用者ＩＤの送信元である前記プログラムに対して、前記認証の結果と前記署名データを送信することを特徴とする。

請求項３に記載の発明は、請求項１又は２に記載のセキュアエレメントであって、前記生成手段は、前記公開鍵暗号方式として楕円曲線暗号を用いることを特徴とする。

請求項４に記載の発明は、請求項１乃至３の何れか一項に記載のセキュアエレメントであって、前記認証プログラムは前記処理部を、外部のセキュア領域で実行されるセキュアアプリケーションプログラムと当該認証プログラムの間で通信を行うためのセキュアチャネルを開設する開設手段として更に機能させ、前記取得手段は、前記セキュアアプリケーションプログラムが前記利用者の生体情報から抽出した特徴量データを、当該セキュアアプリケーションプログラムから前記セキュアチャネルを介して取得し、前記認証手段は、前記セキュアアプリケーションプログラムが前記認証対象である利用者の生体情報から抽出した特徴量データを、当該セキュアアプリケーションプログラムから前記セキュアチャネルを介して受信することを特徴とする。

請求項５に記載の発明は、請求項１乃至４の何れか一項に記載のセキュアエレメントを搭載したＵＩＭカードである。

請求項６に記載の発明は、処理部と記憶部を備え、利用者の認証の結果を外部デバイスに送信するセキュアエレメントにおいて、前記処理部が前記記憶部に記憶された前記認証を行うための認証プログラムに基づいて行う認証方法であって、前記利用者毎に、当該利用者の生体情報から抽出された特徴量データと、当該利用者の利用者ＩＤを取得する取得工程と、前記利用者毎に、公開鍵暗号方式により秘密鍵及び公開鍵を生成する生成工程と、前記利用者毎に、前記取得工程により取得した利用者ＩＤ及び特徴量データと、前記生成手段により生成した秘密鍵を対応付けて前記記憶部に記憶させる登録工程と、前記利用者毎に、当該利用者について生成された公開鍵を、前記外部デバイスに送信する第１送信工程と、前記外部デバイスから、認証対象である利用者に対応する利用者ＩＤと、当該認証対象である利用者の生体情報から抽出された特徴量データを受信し、前記記憶部に当該認証対象である利用者に対応する利用者ＩＤと同一の利用者ＩＤと対応付けて登録されている特徴量データと、当該受信した特徴量データを照合して当該利用者の認証を行う認証工程と、前記認証対象である利用者に対応する利用者ＩＤと同一の利用者ＩＤと対応付けて登録されている秘密鍵を用いて署名データを作成する作成工程と、前記認証対象である利用者に対応する利用者ＩＤの送信元である前記外部デバイスに対して、前記署名データと前記署名データを送信する第２送信工程と、を含むことを特徴とする。

請求項７に記載の発明は、処理部と記憶部を備え、利用者の認証の結果を外部デバイスに送信するセキュアエレメントにおける、前記記憶部に記憶された前記認証を行うための認証プログラムであって、前記処理部を、前記利用者毎に、当該利用者の生体情報から抽出された特徴量データと、当該利用者の利用者ＩＤを取得する取得手段、前記利用者毎に、公開鍵暗号方式により秘密鍵及び公開鍵を生成する生成手段、前記利用者毎に、前記取得手段が取得した利用者ＩＤ及び特徴量データと、前記生成手段が生成した秘密鍵を対応付けて前記記憶部に記憶させる登録手段、前記利用者毎に、当該利用者について生成された公開鍵を、前記外部デバイスに送信する第１送信手段、前記外部デバイスから、認証対象である利用者に対応する利用者ＩＤと、当該認証対象である利用者の生体情報から抽出された特徴量データを受信し、前記記憶部に当該認証対象である利用者に対応する利用者ＩＤと同一の利用者ＩＤと対応付けて登録されている特徴量データと、当該受信した特徴量データを照合して当該利用者の認証を行う認証手段、前記認証対象である利用者に対応する利用者ＩＤと同一の利用者ＩＤと対応付けて登録されている秘密鍵を用いて署名データを作成する作成手段、前記認証対象である利用者に対応する利用者ＩＤの送信元である前記外部デバイスに対して前記署名データと前記署名データを送信する第２送信手段、として機能させることを特徴とする。

本発明によれば、認証前に外部において利用者の生体情報から抽出された特徴量データを記憶部に記憶するとともに、公開鍵暗号方式の公開鍵を外部デバイスに送信しておき、認証時に同じく外部において認証対象である利用者の生体情報から抽出された特徴量データと、登録してある特徴量データを照合して認証を行うことにより、生体情報を管理するサーバにアクセスせずに、且つ、認証精度を下げることなく生体認証を行うことができる。また、外部デバイスには認証結果とともに、先に送信した公開鍵とペアの秘密鍵で作成した署名データを送信することにより、認証の結果を安全に送信することができる。

本実施形態に係る携帯端末１の概要構成例を示すブロック図である。本実施形態に係るＵＩＭカード２に搭載されるＩＣチップＣの概要構成例を示すブロック図である。本実施形態に係る携帯端末１における指紋認証に関連する構成例を示すブロック図である。本実施形態に係るフラッシュメモリ２３上に設けられる特徴量テーブルＴの概要構成例を示す図である。本実施形態に係るセキュアチャネル開設処理の一例を示すシーケンス図である。本実施形態に係る指紋登録時のフローの一例を示す概念図である。本実施形態に係る指紋登録時のTrust Zoneにおける処理の一例を示すフローチャートである。本実施形態に係る指紋認証時のフローの一例を示す概念図である。本実施形態に係る指紋認証時のTrust Zoneにおける処理の一例を示すフローチャートである。

以下、図面を参照して本発明の実施形態について詳細に説明する。以下に説明する実施形態は、スマートフォン等の携帯端末に挿入されたＵＩＭカードに搭載されるＩＣチップ（セキュアエレメント）に対して本発明を適用した場合の実施の形態である。

［１．携帯端末１の構成］
図１は、本実施形態に係る携帯端末１の概要構成例を示すブロック図である。図１に示すように、携帯端末１は、制御部１１、記憶部１２、無線通信部１３、表示部１４、入力部１５、ＣＬＦインターフェース１６ａ、ＩＣカードインターフェース１６ｂ、指紋センサ１８及びＣＬＦ１９等を備えて構成され、これらの構成要素はバス１７を介して相互に接続される。また、携帯端末１にはＵＩＭカード２が挿入されており、ＩＣカードインターフェース１６ｂ及びＣＬＦ１９と接続されている。なお、携帯端末１は、例えば携帯電話機やスマートフォン、タブレット端末等である。

制御部１１は、ＣＰＵ（Central Processing Unit）、ＲＯＭ（Read Only Memory）、及びＲＡＭ（Random Access Memory）等により構成される。記憶部１２は、例えばフラッシュメモリ等の不揮発性メモリにより構成される。上記ＲＯＭまたは記憶部１２には、汎用ＯＳ（Operating System）及びミドルウェアが記憶される。また、記憶部１２には、携帯端末１にインストールされたＡＰＩ（Application Program Interface）及びサービスアプリ（ネットバンキング、オンライントレード、ショッピングカートといったサービスを提供するアプリケーションであって、指紋認証の正常終了をサービス提供の前提とする）を含むアプリケーションソフトウェア（アプリケーションプログラム言語から構成されるソフトウェア）等が記憶される。ＡＰＩは、アプリケーションソフトウェアからオペレーティングシステムの機能を利用するためのインターフェースである。アプリケーションソフトウェアは、例えば所定のサーバからダウンロード可能なプログラムである。

また、制御部１１は、いわゆるTrust Zoneを形成する。Trust Zoneは、汎用ＯＳが動作するメモリ空間と物理的に別個のメモリ空間であるセキュアな領域である。Trust ZoneではSecure OSと呼ばれる専用OSが動作し、セキュアな情報管理等を行う。Trust Zone側から通常の汎用OSの動作は見える一方で、汎用OS側からはTrust Zone内を認識できない。この仕組みにより、外部からの攻撃を防ぐことができる。本実施形態では、Trust Zoneにおいて、後述する指紋認証を行うための第１指紋アプリが動作する。なお、Trust ZoneはＡＲＭ社が開発したものであるが、同様の仕組みがGlobal Platformにて「TEE（Trusted Execution Environment）」として仕様が策定され、標準化されており、Trust Zoneの代わりに他のTEEを採用することもできる。

無線通信部１３は、アンテナを有し、移動体通信網における基地局との間で行われる無線通信を制御する。表示部１４は、例えばタッチパネル方式の表示パネルを有し、表示パネルへの表示制御、及び利用者Ｕからの操作指示の受け付けを行う。入力部１５は、利用者Ｕからの操作指示を入力するための操作ボタンを有し、操作ボタンに応じた信号を制御部１１に出力する。ＣＬＦインターフェースは、制御部１１とＣＬＦ１９との間のインターフェースを担い、ＩＣカードインターフェース１６ｂは、制御部１１とＵＩＭカード２との間のインターフェースを担う。

ＵＩＭカード２は、ＵＩＣＣ（Universal Integrated Circuit）の一つであり、例えば、従来のＳＩＭ（Subscriber Identity Module）をベースに機能を拡張された接触型ＩＣチップを搭載する。

指紋センサ１８は、指紋センサ１８上に置かれた指の指紋を示す指紋画像を検出する。

ＣＬＦ１９は、ＮＦＣの規格で規定される非接触通信を行う非接触型ＩＣチップであり、非接触通信のフィールド内で読取装置（図示せず）との間で各種信号の送受信を行うためのアンテナに接続されている。そして、利用者Ｕが携帯端末１を読取装置に翳すと、読取装置から送信されたコマンドを、インターフェイス（図示せず）を介してＵＩＭカード２へ送信し、ＵＩＭカード２から送信された、コマンドに対する応答を読取装置に返すようになっている。なお、ＣＬＦ１９は、携帯端末１のＯＳにより操作可能になっている。

［２．ＩＣチップＣの構成］
図２は、本実施形態に係るＵＩＭカード２に搭載されるＩＣチップＣの概要構成例を示すブロック図である。図２に示すように、ＩＣチップＣ（「セキュアエレメント」の一例）は、ＣＰＵ２１（「処理部」の一例）、ＲＡＭ２２、フラッシュメモリ２３及びＩ／Ｏ回路２４等を備え、これらの構成要素はバス２５を介して相互に接続される。

ＩＣチップＣは、いわゆるセキュアエレメントであって、外部からの悪意を持った解析攻撃に耐えられるように設計され、セキュアな環境を形成する。

ＲＡＭ２２には、例えばＯＳ、ミドルウェア、各種アプリケーションが機能するうえで一時的に必要となるデータが記憶される。

フラッシュメモリ２３（「記憶部」の一例）は、例えばＮＯＲ型フラッシュメモリであって、ＯＳ、ミドルウェア及びアプリケーション（ＴＥＬアプリ）等を記憶する。また、本実施形態では、フラッシュメモリ２３に指紋認証を行うための第２指紋アプリがインストールされており、ＣＰＵ２１により実行される。

Ｉ／Ｏ回路２４は、ＩＳＯ７８１６等によって定められた、Ｃ１〜Ｃ８の８個の接続端子を有する。ここで、Ｃ１端子は電源端子（ＶＣＣ）であり、Ｃ５端子はグランド端子（ＧＮＤ）である。また、Ｃ２端子は、リセット端子（ＲＳＴ）であり、Ｃ３端子は、クロック端子（ＣＬＫ）である。また、Ｃ７端子は、ＣＰＵ２１と制御部１１との間の通信のために用いられる。また、Ｃ６端子は、ＣＰＵ２１とＣＬＦ１９との間の通信のために用いられる。なお、ＣＰＵ２１とＣＬＦ１９間の通信プロトコルには、ＳＷＰ（Single Wire Protocol）が適用される。

次に、携帯端末２における指紋認証に係る構成について説明する。図３は、本実施形態に係る携帯端末１における生体認証に関連する構成例を示すブロック図である。まず、サービスアプリ３１は、サービスを提供するにあたり、指紋認証を行う際、Trust Zone３２で動作する第１指紋アプリ３３と、ＩＣチップＣ（セキュアエレメント）で動作する第２指紋アプリ２９との間で論理的なセキュアチャネルを構築する（セキュアチャネルの構築時の流れは後述する）。指紋センサ１８は、携帯端末１の利用者の指紋を検出し指紋画像を出力する。第１指紋アプリ３３及び第２指紋アプリ２９は指紋画像に基づいて指紋認証に係る処理を実行する。

次に、図４を用いて、フラッシュメモリ２３のうち、第２指紋アプリ２９に割り当てられた領域に設けられる特徴量テーブルＴについて説明する。特徴量テーブルＴは、ＩＣチップＣ（セキュアエレメント）に第２指紋アプリ２９がインストールされる際に作成され、指紋認証処理に係る認証情報を所定件数（本実施形態では「３件」）分記憶する。認証情報はサービスアプリ３１及び利用者毎に登録される情報であって、それぞれインデックスにより管理されている。

認証情報は、ＡＩＤ、利用者を識別するための利用者ＩＤ、特徴量データ（指紋画像の特徴点を数値化したデータ）、及び秘密鍵をそれぞれ示す情報により構成されている。ＡＩＤは、指紋認証を要求するサービスアプリを識別するための情報である。ＡＩＤを保持することにより、複数のサービスアプリについて指紋認証を行うことができ、サービスアプリ毎に認証用アプリをインストールする必要がない。秘密鍵は、第２指紋アプリ２９がＡＩＤ及び利用者ＩＤの組み合わせ毎に公開鍵暗号方式により作成する鍵ペア（秘密鍵と公開鍵）の一つである。なお、鍵ペアのもう一つの鍵である公開鍵は、サービスアプリ３１に送信され、保持される。特徴量データは、ＡＩＤ及び利用者ＩＤの組み合わせ毎に、指紋画像に対して特徴点抽出処理を実行することにより得られる情報である。

ＣＰＵ２１は、ＣＬＦ１９からコマンドを受信すると、当該コマンドに応じたコマンド処理を実行し、コマンドに対する応答をＣＬＦ１９に対して行う。また、ＣＰＵ２１は、制御部１１からコマンドを受信すると、当該コマンドに応じたコマンド処理を実行し、コマンドに対する応答を制御部１１に対して行う。

［３．セキュアチャネルの開設処理］
ここで、図５を用いてセキュアチャネルの開設処理について説明する。セキュアチャネル（セキュアな通信路）の開設処理は、セキュアチャンネルプロトコル（Secure Channel Protocol、以下、「ＳＣＰ」という)に従って行われる。

まず、第１指紋アプリ３３は第２指紋アプリ２９との通信路を形成するためにSELECTコマンドを送信する（ステップＳ１）。SELECTコマンドは、通信路の相手先となるアプリケーションを識別するＩＤであるＡＩＤ（ここでは第２指紋アプリ２９を示すＡＩＤ）と、当該アプリケーションとの通信路（ロジカルチャネル）を識別するロジカルチャネル番号を含む。これに対して、第２指紋アプリ２９はコマンドに応じて通信路を形成するための処理を実行し、応答する（ステップＳ２）。これにより、ロジカルチャネル番号で識別される通信路（ロジカルチャネル）が形成され、以降、第１指紋アプリ３３はコマンドに当該ロジカルチャネル番号を含ませることにより、当該ロジカルチャネル番号で識別される通信路を介して、第２指紋アプリ２９と通信を行うことができる。次いで、第１指紋アプリ３３は、通信路の機密性を高めるためにそれまでに形成した通信路（ロジカルチャネル）をセキュアな通信路にするセキュア処理（ＳＣＰでコマンドを保護するための相互認証処理）を実行する。

相互認証は、プロトコルで決められたアルゴリズムに従い、暗号演算の元となる鍵（Key ID01, Key ID02, Key ID03の3つの鍵）を互いが知っているという前提の基、第１指紋アプリ３３と第２指紋アプリ２９が互いを認証する行為である。具体的には、第１指紋アプリ３３が相互認証用のコマンドであるINITIALIZE UPDATEコマンド及びEXTERNAL AUTHENTICATEコマンドを送信し、第２指紋アプリ２９がそれぞれのコマンドに応じた処理を実行することにより行われる。

まず、第１指紋アプリ３３はHost challengeと呼ばれる乱数を生成し、Host challengeと、キーバージョンを示す値であるキーバージョン情報（「key version number」という場合がある）を含むINITIALIZE UPDATEコマンドを第２指紋アプリ２９へ送信する（ステップＳ３）。なお、第２指紋アプリ２９と第１指紋アプリ３３は互いに相互認証に使用する３つの鍵からなる鍵の組み合わせを複数のキーバージョン（「key version」という場合がある）分保有している。INITIALIZE UPDATEコマンドに含まれるkey version numberは、互いに保有する複数のkey versionのうち、セキュア処理に使用するkey versionを示している（すなわち、第１指紋アプリ３３がセキュア処理に使用するkey versionを指定する）。

これに対して第２指紋アプリ２９はCard challengeと呼ばれる乱数を生成し、Card challenge と、key version numberで指定されたkey versionの鍵（Key ID01, Key ID02, Key ID03の３つの鍵）を基に、各Key IDに対応した３つのセッションキーを生成する。例えば、Key ID01を基にKey ID01のセッションキーを生成する。各セッションキーの用途は各プロトコルに従った用途で使用される（例えば、MAC生成用セッションキー、データ暗号化用セッションキー、鍵暗号化用セッションキーの３つが生成される）。また、第２指紋アプリ２９は、生成したCard challengeと受信したHost challengeを材料に、セッションキーを用いてCard cryptogramと呼ばれる暗号文を演算し、第１指紋アプリ３３にCard challengeとCard cryptogramを送信する（ステップＳ４）。

次に、第１指紋アプリ３３は、第２指紋アプリ２９側と同様にCard challengeとkey version numberで指定したkey versionの鍵（第１指紋アプリ３３が保有する鍵）を基にセッションキーを生成し、Card challengeとHost challengeを材料に、セッションキーを用いてCard cryptogramを生成する。第１指紋アプリ３３は、自身で生成したCard cryptogramと第２指紋アプリ２９側から受信したCard cryptogramを比較し、一致するか確認することにより第２指紋アプリ２９が鍵値を知る正当な相手であることを確認する。第１指紋アプリ３３は、これを確認すると、Card challengeとHost challengeを材料に、セッションキーを用いてHost cryptogramと呼ばれる暗号文を演算し、Host cryptogramを含むEXTERNAL AUTHENTICATEコマンドを第２指紋アプリ２９に送信する（ステップＳ５）。

これに対して第２指紋アプリ２９は第１指紋アプリ３３側と同様にCard challengeとHost challengeを材料に、セッションキーを用いてHost cryptogramを生成し、自身で生成したHost cryptogramと第１指紋アプリ３３側から受信したHost cryptogramを比較し、一致するか確認することにより、第１指紋アプリ３３が鍵値を知る正当な相手であることを確認する。第２指紋アプリ２９は、これを確認すると、相互認証が完了したことを第１指紋アプリ３３に知らせる（ステップＳ６）。

相互認証完了以降は、互いに生成したセッションキーを用いてMAC（Message Authentication Code）と呼ばれるチェックコードを生成・検証することでコマンドを保護する（ステップＳ７〜ステップＳ１０）。

［４．指紋認証処理］
次に、サービスアプリ３１、第１指紋アプリ３３及び第２指紋アプリ２９による指紋認証処理について説明する。なお、サービスアプリ３１と、第１指紋アプリ３３及び第２指紋アプリ２９との間で指紋認証処理を行うためには、両者間で指紋認証処理を行うために必要な情報を登録する登録処理を事前に行う必要がある。よって、まず登録処理について説明した後に、認証処理について説明する。

図６及び図７を用いて登録処理について説明する。図６は、指紋登録時の大まかな流れを示す図であり、図７は、指紋登録時における第２指紋アプリによる登録時処理の動作例を示すフローチャートである。

図６に示すように、まず、指紋センサ１８が利用者の指紋画像を検出すると、Trust Zone３２の第１指紋アプリ３３に渡す。なお、ここでいう指紋画像は、予め利用者に「指紋を登録するので指を指紋センサ１８に置いてください」といったメッセージに従って指が指紋センサ１８に置かれることにより検出される。また、これと並行してサービスアプリ３１は、当該サービスアプリ３１を識別するＡＩＤと、指紋センサ１８に指を置いた利用者を識別する利用者ＩＤを第１指紋アプリ３３に渡す。

次に、第１指紋アプリ３３（を実行する制御部１１）は、指紋センサ１８から受け取った指紋画像に対して、特徴点抽出処理を行うためのフィルタ処理等の前処理を行い、次いで、特徴点抽出処理を行い、指紋画像に基づく特徴量データを得る。

次に、第１指紋アプリ３３（を実行する制御部１１）は、サービスアプリ３１から受け取ったＡＩＤ及び利用者ＩＤと、特徴量データをＩＣチップＣ（セキュアエレメント）の第２指紋アプリ２９に渡す。

次に、第２指紋アプリ２９（を実行するＣＰＵ２１）は、公開鍵暗号方式による鍵ペア（秘密鍵・公開鍵）を作成する。

次に、第２指紋アプリ２９（を実行するＣＰＵ２１）は、第１指紋アプリ３３から受け取ったＡＩＤ、利用者ＩＤ及び特徴量データと、秘密鍵を対応付けて特徴量テーブルＴに登録する。

次に、第２指紋アプリ２９（を実行するＣＰＵ２１）は、指紋登録が正常終了したことを示すレスポンスとともに公開鍵をサービスアプリ３１に渡すか、又は、指紋登録が異常終了したことを示すレスポンスをサービスアプリ３１に渡す。以上が指紋登録時の大まかな流れである。

次に、図７を用いて、第２指紋アプリ２９による登録時処理の動作例について説明する。なお、第２指紋アプリ２９による登録時処理は、第１指紋アプリ３３からＡＩＤ、利用者ＩＤ及び特徴量データを受け取ることを契機に実行される。

図７に示すように、まず、第２指紋アプリ２９（を実行するＣＰＵ２１）は、公開鍵暗号方式による鍵ペア（秘密鍵・公開鍵）を作成する（ステップＳ１１１）。なお、公開鍵暗号方式による鍵ペアの作成方法は、従来公知の手法を採用することができるが、作成処理に要する時間がＲＳＡ暗号よりも短い楕円曲線暗号であることが好ましい。

次に、第２指紋アプリ２９（を実行するＣＰＵ２１）は、第１指紋アプリ３３から受け取ったＡＩＤ及び利用者ＩＤの組み合わせと同一のＡＩＤ及び利用者ＩＤの組み合わせが特徴量テーブルＴに登録されているか否かを判定する（ステップＳ１１２）。このとき、第２指紋アプリ２９（を実行するＣＰＵ２１）は登録されていると判定した場合には（ステップＳ１１２：ＹＥＳ）、第１指紋アプリ３３から受け取った特徴量データと、ステップＳ１１１の処理で作成した秘密鍵により、上書き登録し（ステップＳ１１３）、ステップＳ１１７の処理に移行する。つまり、特徴量テーブルＴには、新たに取得された特徴データと、新たに作成された秘密鍵が登録される。同一のＡＩＤ及び利用者ＩＤの組み合わせについて上書き登録するのは、時間の経過に伴う生体情報の変化に対応するためである。生体認証の弱点として、加齢や体型の変化、指紋の場合は磨耗によって薄くなったり、傷がついたりした場合、同一人物でも認証精度が下がってしまう（登録済みの情報とズレが出てきてしまう）。そこで、認証精度が低下した場合や、前回の登録から一定期間が経過した際には、再度、生体情報を登録することが好ましいため、同一人物でも特徴量の再登録を許容する必要がある。

一方、第２指紋アプリ２９（を実行するＣＰＵ２１）は登録されていないと判定した場合には（ステップＳ１１２：ＮＯ）、次いで、特徴量テーブルＴの登録済み件数が最大であるか否かを判定する（ステップＳ１１４）。このとき、第２指紋アプリ２９（を実行するＣＰＵ２１）は、特徴量テーブルＴの登録済み件数が最大であると判定した場合には（ステップＳ１１４：ＹＥＳ）、特徴量データの登録が異常終了したことを示すレスポンス（ＮＧ）をサービスアプリ３１に出力し（ステップＳ１１６）、第２指紋アプリ２９による登録時処理を終了する。

一方、第２指紋アプリ２９（を実行するＣＰＵ２１）は、特徴量テーブルＴの登録済み件数が最大ではないと判定した場合には（ステップＳ１１４：ＮＯ）、特徴量テーブルＴの空き領域に、第１指紋アプリ３３から受け取ったＡＩＤ、利用者ＩＤ及び特徴量データと、ステップＳ１１１の処理で作成した秘密鍵を対応付けて特徴量テーブルＴに登録し（ステップＳ１１５）、ステップＳ１１７の処理に移行する。

第２指紋アプリ２９（を実行するＣＰＵ２１）は、ステップＳ１１３の処理又はステップＳ１１５の処理を終了すると、次いで、特徴量データの登録が正常終了したことを示すレスポンス（ＯＫ）と、ステップＳ１１１の処理で作成した公開鍵をサービスアプリ３１に出力し（ステップＳ１１７）、第２指紋アプリ２９による登録時処理を終了する。

なお、サービスアプリ３１は、第２指紋アプリ２９から受け取った公開鍵を、先に第２指紋アプリ２９に渡した利用者ＩＤと対応付けて保持しておく。

図８及び図９を用いて認証処理について説明する。図８は、指紋認証時の大まかな流れを示す図であり、図９は、指紋認証時における第２指紋アプリによる認証時処理の動作例を示すフローチャートである。

図８に示すように、まず、指紋センサ１８が利用者の指紋画像を検出すると、Trust Zone３２の第１指紋アプリ３３に渡す。なお、ここでいう指紋画像は、予め利用者に「指紋認証をするので指を指紋センサ１８に置いてください」といったメッセージに従って指が置かれたことに基づいて検出される。また、これと並行してサービスアプリ３１は、当該サービスアプリ３１を識別するＡＩＤと、指紋センサ１８に指を置いた利用者を識別する利用者ＩＤを第１指紋アプリ３３に渡す。

次に、第２指紋アプリ２９（を実行するＣＰＵ２１）は、特徴量テーブルＴから、第１指紋アプリ３３から受け取ったＡＩＤ及び利用者ＩＤの組み合わせと同一の組み合わせに対応付けられている特徴量データと、秘密鍵を取得する。次いで、第２指紋アプリ２９（を実行するＣＰＵ２１）は、当該取得した特徴量データと、第１指紋アプリ３３から受け取った特徴量データを照合してスコアを算出して、当該スコアが予め設定された閾値を超えているか判定する。このとき、スコアが当該閾値を超えている場合には認証ＯＫと判定し、スコアが当該閾値を超えていない場合には認証ＮＧと判定する。そして、認証ＯＫである場合には、特徴量テーブルＴから取得した秘密鍵により署名データを作成する。

次に、第２指紋アプリ２９（を実行するＣＰＵ２１）は、認証ＯＫを示すレスポンスとともに署名データをサービスアプリ３１に渡すか、又は、認証ＮＧを示すレスポンスをサービスアプリ３１に渡す。以上が指紋認証時の大まかな流れである。

次に、図９を用いて、第２指紋アプリ２９による認証時処理の動作例について説明する。なお、第２指紋アプリ２９による認証時処理は、第１指紋アプリ３３からＡＩＤ、認証対象の利用者に対応する利用者ＩＤ及び認証対象の利用者の指紋画像に基づく特徴量データを受け取ることを契機に実行される。

図９に示すように、まず、第２指紋アプリ２９（を実行するＣＰＵ２１）は、第１指紋アプリ３３から受け取ったＡＩＤ及び利用者ＩＤの組み合わせと同一のＡＩＤ及び利用者ＩＤの組み合わせが特徴量テーブルＴに登録されているか否かを判定する（ステップＳ１３１）。このとき、第２指紋アプリ２９（を実行するＣＰＵ２１）は登録されていないと判定した場合には（ステップＳ１３１：ＮＯ）、指紋認証が異常終了したことを示すレスポンス（ＮＧ）をサービスアプリ３１に出力し（ステップＳ１３２）、第２指紋アプリ２９による認証時処理を終了する。

一方、第２指紋アプリ２９（を実行するＣＰＵ２１）は登録されていると判定した場合には（ステップＳ１３１：ＹＥＳ）、第１指紋アプリ３３から受け取ったＡＩＤ及び利用者ＩＤの組み合わせと対応付けて特徴量テーブルＴに登録されている、特徴量データと秘密鍵を取得する（ステップＳ１３３）。

次に、第２指紋アプリ２９（を実行するＣＰＵ２１）は、第１指紋アプリ３３から受け取った特徴量データと、ステップＳ１３３の処理で取得した特徴量データを照合してスコアを算出する（ステップＳ１３４）。スコアの算出方法については、従来公知の手法を採用することができる。

次に、第２指紋アプリ２９（を実行するＣＰＵ２１）は、ステップＳ１３４の処理で算出したスコアが予め設定された閾値（指紋認証をどれだけ厳格に行うかに応じて任意に設定することができる）を超えているか否かを判定する（ステップＳ１３５）。このとき、第２指紋アプリ２９（を実行するＣＰＵ２１）は、スコアが予め設定された閾値を超えていないと判定した場合には（ステップＳ１３５：ＮＯ）、指紋認証が異常終了したことを示すレスポンス（ＮＧ）をサービスアプリ３１に出力し（ステップＳ１３２）、第２指紋アプリ２９による認証時処理を終了する。

一方、第２指紋アプリ２９（を実行するＣＰＵ２１）は、スコアが予め設定された閾値を超えていると判定した場合には（ステップＳ１３５：ＹＥＳ）、ステップＳ１３３の処理で取得した秘密鍵により署名データを作成する（ステップＳ１３６）。第２指紋アプリ２９（を実行するＣＰＵ２１）は、例えば、自らが生成した乱数を秘密鍵により暗号化することにより署名データを作成する。次いで、第２指紋アプリ２９（を実行するＣＰＵ２１）は、指紋認証が正常終了したことを示すレスポンス（ＯＫ）と、ステップＳ１３６の処理で作成した署名データをサービスアプリ３１に出力し（ステップＳ１３７）、第２指紋アプリ２９による登録時処理を終了する。

なお、サービスアプリ３１は、レスポンス（ＯＫ）を受け取った場合であって、且つ、第２指紋アプリ２９から受け取った署名データを、先に第２指紋アプリ２９に渡した利用者ＩＤと対応付けて保持している公開鍵により復号し、正常に復号できた場合には利用者を正当な利用者として判断し、サービスの提供を開始する。

以上のように、本実施形態のＩＣチップＣ（セキュアエレメント）は、ＣＰＵ２１（「処理部」の一例）とフラッシュメモリ２３（「記憶部」の一例）を備え、利用者の認証の結果を携帯端末１（「外部デバイス」の一例）のサービスアプリ３１に送信するものであって、フラッシュメモリ２３は第２指紋アプリ２９（「認証プログラム」の一例）を記憶し、ＣＰＵ２１（「取得手段」、「生成手段」、「登録手段」、「第１送信手段」、「認証手段」、「作成手段」、「第２送信手段」の一例）は、第２指紋アプリ２９に基づいて、利用者毎に、当該利用者の指紋画像（「生体情報」の一例）から抽出された特徴量データと、当該利用者の利用者ＩＤを取得し、利用者毎に、公開鍵暗号方式により秘密鍵及び公開鍵を生成し、利用者毎に、取得した利用者ＩＤ及び特徴量データと、生成した秘密鍵を対応付けてフラッシュメモリ２３に記憶させ、利用者毎に、当該利用者について生成された公開鍵を、携帯端末１に送信し、携帯端末１から、認証対象である利用者に対応する利用者ＩＤと、当該認証対象である利用者の指紋画像から抽出された特徴量データを受信し、フラッシュメモリ２３に当該認証対象である利用者に対応する利用者ＩＤと同一の利用者ＩＤと対応付けて登録されている特徴量データと、当該受信した特徴量データを照合して当該利用者の認証を行い、認証対象である利用者に対応する利用者ＩＤと同一の利用者ＩＤと対応付けて登録されている秘密鍵を用いて署名データを作成し、認証対象である利用者に対応する利用者ＩＤの送信元である携帯端末１に対して、認証の結果と署名データを送信する。

したがって、本実施形態のＩＣチップＣ（セキュアエレメント）によれば、認証前に外部（Trust Zone３２の第１指紋アプリ３３）において利用者の指紋画像から抽出された特徴量データをフラッシュメモリ２３に記憶するとともに、公開鍵暗号方式の公開鍵を携帯端末１に送信しておき、認証時に同じく外部（Trust Zone３２の第１指紋アプリ３３）において認証対象である利用者の指紋画像から抽出された特徴量データと、登録してある特徴量データを照合して認証を行うことにより、指紋画像を管理するサーバにアクセスせずに、且つ、認証精度を下げることなく生体認証を行うことができる。また、携帯端末１には認証結果とともに、先に送信した公開鍵とペアの秘密鍵で作成した署名データを送信することにより、認証の結果を安全に送信することができる。

また、本実施形態のＣＰＵ２１は、サービスアプリ３１を識別するためのＡＩＤ（「外部デバイスが提供するサービスを識別するためのサービスＩＤ」の一例）を更に取得し、利用者ＩＤ、特徴量データ及び秘密鍵と対応付けてＡＩＤを更に登録し、認証時には、サービスアプリ３１から利用者ID及び特徴量データに加えてＡＩＤを更に受信し、受信した利用者ＩＤ及びＡＩＤと同一の利用者ＩＤ及びＡＩＤと対応付けてフラッシュメモリ２３に登録されている特徴量データと、受信した特徴量データを照合して当該利用者の認証を行い、受信した利用者ＩＤ及びＡＩＤと同一の利用者ＩＤ及びＡＩＤと対応付けてフラッシュメモリ２３に登録されている秘密鍵を用いて署名データを作成し、認証対象である利用者に対応する利用者ＩＤの送信元であるサービスアプリ３１に対して、認証の結果と署名データを送信する。このように、特徴量テーブルＴにＡＩＤを更に対応付けて登録しておくことにより、複数のサービスアプリ３１について指紋認証を行うことができ、サービスアプリ３１毎に認証用アプリをインストールする必要がない。

更に、本実施形態のＣＰＵ２１は、公開鍵暗号方式として楕円曲線暗号を用いる。これにより、ＲＳＡ暗号を用いた場合よりも高速に鍵ペアを生成することができる。

更にまた、本実施形態の第２指紋アプリ２９と、Trust Zone３２（「外部のセキュア領域」の一例）で実行される第１指紋アプリ３３（「セキュアアプリケーションプログラム」の一例）との間で通信を行うためのセキュアチャネルが開設され、ＣＰＵ２１は、第１指紋アプリ３３が利用者の指紋画像から抽出した特徴量データを第１指紋アプリ３３からセキュアチャネルを介して取得し、第１指紋アプリ３３が認証対象である利用者の指紋画像から抽出した特徴量データを、第１指紋アプリ３３からセキュアチャネルを介して受信する。これにより、第２指紋アプリ２９は第１指紋アプリ３３から安全に特徴量データを取得することができ、認証時のセキュリティレベルを向上させることができる。

［５．変形例］
次に、上記実施形態の変形例について説明する。なお、以下に説明する変形例は適宜組み合わせることができる。

［５．１．変形例１］
上記実施形態では、ＩＣチップＣ（セキュアエレメント）を備えるＵＩＭカードが、携帯端末１に挿入されていることとしたが、ＩＣチップＣ（セキュアエレメント）が携帯端末１の基板上に埋め込まれていてもよい（いわゆる、embedded Secure Elementでもよい）。

［５．２．変形例２］
上記実施形態では、ＡＩＤ及び利用者ＩＤがサービスアプリ３１から第１指紋アプリ３３を介して第２指紋アプリに受け渡されているが（図６、図８参照）、第１指紋アプリ３３を介さずに、サービスアプリ３１が直接第２指紋アプリへ受け渡すこととしてもよい。

［５．３．変形例３］
上記実施形態では、指紋認証についてのみ説明したが、虹彩認証、静脈認証といった他の生体認証に本発明を適用することもできる。

１携帯端末
１１制御部
１２記憶部
１３無線通信部
１４表示部
１５入力部
１６ａＣＬＦインターフェース
１６ｂＩＣカードインターフェース
１７バス
１８指紋センサ
１９ＣＬＦ
２ＵＩＭカード
ＣＩＣチップ（セキュアエレメント）
２１ＣＰＵ
２２ＲＡＭ
２３フラッシュメモリ
２４Ｉ／Ｏ回路
２５バス

Claims

処理部と記憶部を備え、利用者の認証の結果を外部デバイスに送信するセキュアエレメントであって、
前記記憶部は前記認証を行うための認証プログラムを記憶し、
前記認証プログラムは前記処理部を、
前記利用者毎に、当該利用者の生体情報から抽出された特徴量データと、当該利用者の利用者ＩＤを取得する取得手段、
前記利用者毎に、公開鍵暗号方式により秘密鍵及び公開鍵を生成する生成手段、
前記利用者毎に、前記取得手段が取得した利用者ＩＤ及び特徴量データと、前記生成手段が生成した秘密鍵を対応付けて前記記憶部に記憶させる登録手段、
前記利用者毎に、当該利用者について生成された公開鍵を、前記外部デバイスに送信する第１送信手段、
前記外部デバイスから、認証対象である利用者に対応する利用者ＩＤと、当該認証対象である利用者の生体情報から抽出された特徴量データを受信し、前記記憶部に当該認証対象である利用者に対応する利用者ＩＤと同一の利用者ＩＤと対応付けて登録されている特徴量データと、当該受信した特徴量データを照合して当該利用者の認証を行う認証手段、
前記認証対象である利用者に対応する利用者ＩＤと同一の利用者ＩＤと対応付けて登録されている秘密鍵を用いて署名データを作成する作成手段、
前記認証対象である利用者に対応する利用者ＩＤの送信元である前記外部デバイスに対して、前記認証の結果と前記署名データを送信する第２送信手段、
として機能させることを特徴とするセキュアエレメント。
請求項１に記載のセキュアエレメントであって、
前記取得手段は、前記外部デバイスが提供するサービスを識別するためのサービスＩＤを更に取得し、
前記登録手段は、前記利用者ＩＤ、前記特徴量データ及び前記秘密鍵と対応付けて前記サービスＩＤを更に登録し、
前記第１送信手段は、前記公開鍵を前記外部デバイスで動作するプログラムに対して送信し、
前記認証手段は、前記外部デバイスで動作するプログラムから、当該プログラムのサービスＩＤを更に受信し、受信した利用者ＩＤ及びサービスＩＤと同一の利用者ＩＤ及びサービスＩＤと対応付けて前記記憶部に登録されている特徴量データと、受信した特徴量データを照合して当該利用者の認証を行い、
前記作成手段は、受信した利用者ＩＤ及びサービスＩＤと同一の利用者ＩＤ及びサービスＩＤと対応付けて前記記憶部に登録されている秘密鍵を用いて署名データを作成し、
前記第２送信手段は、前記認証対象である利用者に対応する利用者ＩＤの送信元である前記プログラムに対して、前記認証の結果と前記署名データを送信することを特徴とするセキュアエレメント。
請求項１又は２に記載のセキュアエレメントであって、
前記生成手段は、前記公開鍵暗号方式として楕円曲線暗号を用いることを特徴とするセキュアエレメント。
請求項１乃至３の何れか一項に記載のセキュアエレメントであって、
前記認証プログラムと、外部のセキュア領域で実行されるセキュアアプリケーションプログラムとの間で通信を行うためのセキュアチャネルが開設され、
前記取得手段は、前記セキュアアプリケーションプログラムが前記利用者の生体情報から抽出した特徴量データを、当該セキュアアプリケーションプログラムから前記セキュアチャネルを介して取得し、
前記認証手段は、前記セキュアアプリケーションプログラムが前記認証対象である利用者の生体情報から抽出した特徴量データを、当該セキュアアプリケーションプログラムから前記セキュアチャネルを介して受信することを特徴とするセキュアエレメント。
請求項１乃至４の何れか一項に記載のセキュアエレメントを搭載したＵＩＭカード。
処理部と記憶部を備え、利用者の認証の結果を外部デバイスに送信するセキュアエレメントにおいて、前記処理部が前記記憶部に記憶された前記認証を行うための認証プログラムに基づいて行う認証方法であって、
前記利用者毎に、当該利用者の生体情報から抽出された特徴量データと、当該利用者の利用者ＩＤを取得する取得工程と、
前記利用者毎に、公開鍵暗号方式により秘密鍵及び公開鍵を生成する生成工程と、
前記利用者毎に、前記取得工程により取得した利用者ＩＤ及び特徴量データと、前記生成手段により生成した秘密鍵を対応付けて前記記憶部に記憶させる登録工程と、
前記利用者毎に、当該利用者について生成された公開鍵を、前記外部デバイスに送信する第１送信工程と、
前記外部デバイスから、認証対象である利用者に対応する利用者ＩＤと、当該認証対象である利用者の生体情報から抽出された特徴量データを受信し、前記記憶部に当該認証対象である利用者に対応する利用者ＩＤと同一の利用者ＩＤと対応付けて登録されている特徴量データと、当該受信した特徴量データを照合して当該利用者の認証を行う認証工程と、
前記認証対象である利用者に対応する利用者ＩＤと同一の利用者ＩＤと対応付けて登録されている秘密鍵を用いて署名データを作成する作成工程と、
前記認証対象である利用者に対応する利用者ＩＤの送信元である前記外部デバイスに対して、前記署名データと前記署名データを送信する第２送信工程と、
を含むことを特徴とする認証方法。
処理部と記憶部を備え、利用者の認証の結果を外部デバイスに送信するセキュアエレメントにおける、前記記憶部に記憶された前記認証を行うための認証プログラムであって、
前記処理部を、
前記利用者毎に、当該利用者の生体情報から抽出された特徴量データと、当該利用者の利用者ＩＤを取得する取得手段、
前記利用者毎に、公開鍵暗号方式により秘密鍵及び公開鍵を生成する生成手段、
前記利用者毎に、前記取得手段が取得した利用者ＩＤ及び特徴量データと、前記生成手段が生成した秘密鍵を対応付けて前記記憶部に記憶させる登録手段、
前記利用者毎に、当該利用者について生成された公開鍵を、前記外部デバイスに送信する第１送信手段、
前記外部デバイスから、認証対象である利用者に対応する利用者ＩＤと、当該認証対象である利用者の生体情報から抽出された特徴量データを受信し、前記記憶部に当該認証対象である利用者に対応する利用者ＩＤと同一の利用者ＩＤと対応付けて登録されている特徴量データと、当該受信した特徴量データを照合して当該利用者の認証を行う認証手段、
前記認証対象である利用者に対応する利用者ＩＤと同一の利用者ＩＤと対応付けて登録されている秘密鍵を用いて署名データを作成する作成手段、
前記認証対象である利用者に対応する利用者ＩＤの送信元である前記外部デバイスに対して前記署名データと前記署名データを送信する第２送信手段、
として機能させることを特徴とする認証プログラム。