(57)【特許請求の範囲】
【請求項１】
アプリケーションが動作する端末と、当該端末に着脱可能に接続されるセキュアデバイスとを含むアプリケーション認証システムであって、
前記端末は、
当該端末上で動作し、前記セキュアデバイスが保持するデータを利用した処理を行うアプリケーションを記録するアプリケーション記録手段と、
前記アプリケーションを動作させる実行環境を記録する実行環境記録手段と
を備え、
前記セキュアデバイスは、
前記端末上で動作するアプリケーションが利用するデータを記録するデータ保持手段と、
前記実行環境の正当性および前記アプリケーションの正当性を認証する認証手段と、
前記実行環境と前記アプリケーションとの両方について正当性が認証された場合に、前記データ保持手段が記録しているデータへの前記アプリケーションからのアクセスを許可する許可手段と
を備え、
前記端末の実行環境は、前記セキュアデバイスの認証手段によって正当性が認証された後で、前記アプリケーションのダイジェストデータを計算して前記認証手段に送信し、
前記認証手段は、送信された前記ダイジェストデータを用いて前記アプリケーションの正当性を認証する
ことを特徴とするアプリケーション認証システム。
【請求項２】
アプリケーションを動作させる実行環境を持つ端末に着脱可能に接続されるセキュアデバイスであって、
前記アプリケーションによって利用されるデータを保持するデータ保持手段と、
前記実行環境および前記アプリケーションの正当性を認証する認証手段と、
前記実行環境と前記アプリケーションとの両方について正当性が認証された場合に、  前記データ保持手段が記録しているデータへの前記アプリケーションからのアクセスを許可する許可手段と
を備え、
前記端末の実行環境は、前記認証手段によって正当性が認証された後で、前記アプリケーションのダイジェストデータを計算して前記認証手段に送信し、
前記認証手段は、送信された前記ダイジェストデータを用いて前記アプリケーションの正当性を認証する
ことを特徴とするセキュアデバイス。
【請求項３】
請求項２に記載のセキュアデバイスであって、
前記アプリケーションは、認証局により署名が付されており、
前記実行環境は、さらに、前記アプリケーションに付された署名を前記セキュアデバイスに送信し、
前記認証手段は、前記認証局の公開鍵と前記ダイジェストデータとを用いて前記署名を検証し、前記検証結果が正常であるとき、前記アプリケーションを正当と認証する
ことを特徴とするセキュアデバイス。
【請求項４】
請求項２に記載のセキュアデバイスであって、
前記認証手段は、前記アプリケーションのダイジェストデータを予め保持しており、予め保持している前記ダイジェストデータと前記送信されたダイジェストデータとを照合し、照合結果が正常であるとき、前記アプリケーションを正当と認証する
ことを特徴とするセキュアデバイス。
【請求項５】
セキュアデバイスと着脱可能に接続される端末であって、
前記セキュアデバイスは、
前記端末で動作するアプリケーションが利用するデータを保持し、
前記アプリケーションを動作させる実行環境の正当性を認証し、
正当性が認証された前記実行環境が計算した前記アプリケーションのダイジェストデータを用いて前記アプリケーションの正当性を認証し、
前記実行環境と前記アプリケーションとの両方について正当性が認証された場合に前記データへの前記アプリケーションによるアクセスを許可し、
前記端末は、
当該端末上で動作し、前記セキュアデバイスが保持するデータを利用した処理を行うアプリケーションを記録するアプリケーション記録手段と、
前記アプリケーションを動作させる実行環境を記録する実行環境記録手段と
を備え、
前記実行環境は、前記セキュアデバイスによって正当であると認証された場合に、前記アプリケーションのダイジェストデータを計算して前記セキュアデバイスに送信する
ことを特徴とする端末。
【請求項６】
請求項５に記載の端末であって、
前記実行環境は、前記アプリケーションから前記セキュアデバイスが保持するデータの利用を要求された後に、前記ダイジェストデータを計算する
ことを特徴とする端末。
【請求項７】
請求項５に記載の端末であって、
前記実行環境は、前記端末内における、前記端末上の操作および前記端末の外部からのアクセスでは書き換えることのできない書き換え不可領域に記録されている
ことを特徴とする端末。
【請求項８】
アプリケーションを動作させる実行環境を持つ端末に対して着脱可能に接続されるセキュアデバイスで用いられる認証方法であって、
前記セキュアデバイスは、端末上で動作するアプリケーションが利用するデータを保持するデータ保持手段と、認証処理を行う認証手段と、データへのアクセスを許可する許可手段とを備え、
前記認証方法は、
前記認証手段により、前記アプリケーションを動作させる前記実行環境の正当性を認証する実行環境認証ステップと、
前記認証手段により、前記端末上の前記アプリケーションの正当性を認証するアプリケーション認証ステップと、
前記許可手段により、前記実行環境と前記アプリケーションとの両方についての正当性が認証された場合に、前記データ保持手段が記録しているデータへの前記アプリケーションからのアクセスを許可する許可ステップとを含み、
前記端末の実行環境は、前記実行環境認証ステップにおいて正当性が認証された場合、前記アプリケーションのダイジェストデータを計算して前記認証手段に送信し、
前記アプリケーション認証ステップにおいて、前記認証手段は、前記ダイジェストデータの送信を受けた場合に、前記ダイジェストデータを用いて前記アプリケーションの正当性を認証する
ことを特徴とする認証方法。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】
本発明は、ＩＣカードなどのセキュアデバイス上で動作するカードアプリケーションが、携帯端末などの端末上で動作するアプリケーションを認証するアプリケーション認証システムと、そのセキュアデバイスと端末に関し、特に、端末上のアプリケーションがセキュアデバイスを利用する際に必要となる認証処理を実現するものである。
【０００２】
【従来の技術】
近年、情報をセキュアに格納することが可能なＩＣカードなどのセキュアデバイスは、電子商取引や入退出管理、定期券など、多方面で利用されており、今後、携帯端末などのモバイル機能を活用して、その利用範囲は、益々広がるものと見られている。
【０００３】
図８には、携帯端末３０上で動作するアプリケーション（以下、省略して「アプリ」と言う）が、セキュアデバイス１０に格納されたセキュアなデータを利用して実行可能となると見られているサービスの数々を模式的に示している。
セキュアデバイス内で動作するアプリ（カードアプリ）は、下記非特許文献１に記載されているように、Java(登録商標)などのプログラミング言語で作成されてセキュアデバイスに搭載される。カードアプリは、セキュアデバイスに格納したセキュアなデータの利用を求める外部アプリに対して、認証を行い、安全性を確認してから、外部アプリのコマンドを受け付ける。
【０００４】
【非特許文献１】
「Ｉｎｔｅｒｆａｃｅ」２００３年３月号、ＣＱ出版社、ｐ．８２〜９０
【０００５】
【発明が解決しようとする課題】
しかし、従来のセキュアデバイスは、携帯端末にダウンロードされたアプリに対する認証手段を有しておらず、そのため、携帯端末にダウンロードされたアプリは、セキュアデバイスに格納されたデータを利用することができない。
これは、次のような事情に拠る。
通常、認証処理では、当人しか知り得ない情報を知っているかどうかを確認し、知っている場合に、当人と認める。図９は、この方式による相互認証をセキュアデバイス１０のカードアプリ１１と、携帯端末３０の端末アプリ（ここではJava(登録商標)言語で記述されたJava(登録商標)アプリとする）３１とに当て嵌めたときの様子を模式的に示している。機密データの保管機能を持つセキュアデバイス１０は、ハードウエア的に安全に作られた耐タンパ性の領域に秘密の情報（暗号鍵など）を保持することができる。一方、携帯端末３０が秘密情報を扱うには、セキュリティが要求されるため、領域３１全体が耐タンパ性であるか、秘密情報を保持する耐タンパ性の領域３５が在って、領域３１が領域３５に認証されている必要がある。こうした状況にあれば、カードアプリ１１と、携帯端末３０のＯＳ（あるいはＶＭ（virtual machine））３２の制御の下で動作するJava(登録商標)アプリ３１とが情報を交換し、互いに共通の秘密情報を保持していることが確認できれば、相互認証は成立する。
【０００６】
しかし、実際には、携帯端末３０は、秘密情報を安全に保持できる領域を有していない。そのため、カードアプリ１１は、共通の秘密情報を用いて相手認証を行うことができず、従って、携帯端末３０にダウンロードされたJava(登録商標)アプリ３１は、これまで、セキュアデバイス１０に格納されたデータを利用することができなかった。
こうした事情から、携帯端末３０にセキュアデバイス１０を装着して、ネットワークを通じてサービスサーバからサービスを受ける場合でも、これまでは、セキュアデバイス１０と相互認証したサービスサーバは、セキュアデバイス１０に格納されたデータを利用できるが、携帯端末３０は、データをスルーする土管の役割しか果たすことができなかった。そのため、図８に示すように、携帯端末３０のアプリがセキュアデバイス１０のデータを読み／書きして、計算や表示などの高度の処理を行うシステムは実現することができなかった。
【０００７】
本発明は、こうした従来の問題点を解決するものであり、安全な情報秘匿領域を持たない端末上のアプリに対するセキュアデバイスの認証が可能なアプリケーション認証システムを提供し、そのシステムを構成するセキュアデバイス及び端末を提供することを目的としている。
【０００８】
【課題を解決するための手段】
本発明のアプリケーション認証システムは、
アプリケーションが動作する端末と、当該端末に着脱可能に接続されるセキュアデバイスとを含むアプリケーション認証システムであって、
前記端末は、
当該端末上で動作し、前記セキュアデバイスが保持するデータを利用した処理を行うアプリケーションを記録するアプリケーション記録手段と、
前記アプリケーションを動作させる実行環境を記録する実行環境記録手段と
を備え、
前記セキュアデバイスは、
前記端末上で動作するアプリケーションが利用するデータを記録するデータ保持手段と、
前記実行環境の正当性および前記アプリケーションの正当性を認証する認証手段と、
前記実行環境と前記アプリケーションとの両方について正当性が認証された場合に、前記データ保持手段が記録しているデータへの前記アプリケーションからのアクセスを許可する許可手段と
を備え、
前記端末の実行環境は、前記セキュアデバイスの認証手段によって正当性が認証された後で、前記アプリケーションのダイジェストデータを計算して前記認証手段に送信し、
前記認証手段は、送信された前記ダイジェストデータを用いて前記アプリケーションの正当性を認証する
ことを特徴とする。
【０００９】
また、本発明のセキュアデバイスは、
アプリケーションを動作させる実行環境を持つ端末に着脱可能に接続されるセキュアデバイスであって、
前記アプリケーションによって利用されるデータを保持するデータ保持手段と、
前記実行環境および前記アプリケーションの正当性を認証する認証手段と、
前記実行環境と前記アプリケーションとの両方について正当性が認証された場合に、  前記データ保持手段が記録しているデータへの前記アプリケーションからのアクセスを許可する許可手段と
を備え、
前記端末の実行環境は、前記認証手段によって正当性が認証された後で、前記アプリケーションのダイジェストデータを計算して前記認証手段に送信し、
前記認証手段は、送信された前記ダイジェストデータを用いて前記アプリケーションの正当性を認証する
ことを特徴とする。
【００１０】
また、本発明の端末は、
セキュアデバイスと着脱可能に接続される端末であって、
前記セキュアデバイスは、
前記端末で動作するアプリケーションが利用するデータを保持し、
前記アプリケーションを動作させる実行環境の正当性を認証し、
正当性が認証された前記実行環境が計算した前記アプリケーションのダイジェストデータを用いて前記アプリケーションの正当性を認証し、
前記実行環境と前記アプリケーションとの両方について正当性が認証された場合に前記データへの前記アプリケーションによるアクセスを許可し、
前記端末は、
当該端末上で動作し、前記セキュアデバイスが保持するデータを利用した処理を行うアプリケーションを記録するアプリケーション記録手段と、
前記アプリケーションを動作させる実行環境を記録する実行環境記録手段と
を備え、
前記実行環境は、前記セキュアデバイスによって正当であると認証された場合に、前記アプリケーションのダイジェストデータを計算して前記セキュアデバイスに送信する
ことを特徴とする。
また、本発明の認証方法は、
アプリケーションを動作させる実行環境を持つ端末に対して着脱可能に接続されるセキュアデバイスで用いられる認証方法であって、
前記セキュアデバイスは、端末上で動作するアプリケーションが利用するデータを保持するデータ保持手段と、認証処理を行う認証手段と、データへのアクセスを許可する許可手段とを備え、
前記認証方法は、
前記認証手段により、前記アプリケーションを動作させる前記実行環境の正当性を認証する実行環境認証ステップと、
前記認証手段により、前記端末上の前記アプリケーションの正当性を認証するアプリケーション認証ステップと、
前記許可手段により、前記実行環境と前記アプリケーションとの両方についての正当性が認証された場合に、前記データ保持手段が記録しているデータへの前記アプリケーションからのアクセスを許可する許可ステップとを含み、
前記端末の実行環境は、前記実行環境認証ステップにおいて正当性が認証された場合、前記アプリケーションのダイジェストデータを計算して前記認証手段に送信し、
前記アプリケーション認証ステップにおいて、前記認証手段は、前記ダイジェストデータの送信を受けた場合に、前記ダイジェストデータを用いて前記アプリケーションの正当性を認証する
ことを特徴とする。
【００１１】
このように、セキュアデバイスが、端末上でアプリを動作させる実行環境の正当性を検証し、この検証に成功した実行環境が作ったアプリのダイジェストデータを使って、アプリの認証を行うことで、安全な情報秘匿領域を持たない端末上で動作するアプリに対して、セキュアデバイスによる認証が可能になる。
【００１２】
【発明の実施の形態】
（第１の実施形態）
本発明の第１の実施形態におけるアプリケーション認証システムでは、携帯端末上で動作する端末アプリを認証するため、セキュアデバイスのカードアプリは、端末アプリが正規のアプリであるか否かを確認する。カードアプリは、端末アプリが正規のアプリと確認できたとき、認証処理が正常に終了したものとして、端末アプリのアクセス要求を受け付ける。
【００１３】
図２は、このシステムを構成するセキュアデバイス１０と携帯端末３０とを模式的に示している。携帯端末３０は、工場出荷時に情報がＲＯＭやフラッシュメモリに書き込まれ、以後、情報の書き換えができない「書き換え不可領域３０２」と、ダウンロードされたアプリが書き込まれる「ユーザ書き換え領域３０１」とを備えており、ユーザ書き換え領域３０１には、電子署名３４が付されたJava(登録商標)アプリ３１が格納され、また、書き換え不可領域３０２には、ＯＳ３２や、Java(登録商標)言語で記述されたプログラムを実行するためのJava(登録商標)実行環境（ＪＡＭ）３３が格納されている。
【００１４】
なお、「書き換え不可領域３０２」は、端末上の操作（例えば、アプリケーション３１）や、外部（例えば、カード１０）からのアクセスなどにより、そこに格納された情報が書き換えられることがない領域を意味し、その領域自身が物理的書き換え不可能な仕組み（例えばＲＯＭ）を有しているか否かは問わない。
【００１５】
Java(登録商標)アプリ３１の電子署名３４は、Java(登録商標)アプリ３１の正当性を証明する認証局によって付されており、Java(登録商標)アプリ３１のデータにハッシュ演算を行ってダイジェストデータを生成し、このダイジェストデータを認証局の秘密鍵で暗号化して生成されている。
また、ＪＡＭ３３には、携帯端末３０がセキュアデバイス１０との相互認証に用いる端末認証情報と、電子署名３４の検証用公開鍵を含む認証局のアプリ証明書とが入力される（ここで「入力される」とは、それぞれの情報が、コードとしてＪＡＭ３３に埋め込まれたり、必要なときにファイルとして取得可能であることを意味する）。
【００１６】
一方、セキュアデバイス１０は、携帯端末３０に対する認証処理を行う共通ライブラリ（カードマネージャ）１３と、携帯端末３０で動作するJava(登録商標)アプリ３１の認証処理を行うカードアプリ１１と、認証局の公開鍵を証明する署名検証用ルート証明書１４とを備えている。
【００１７】
また、カードマネージャ１３には、セキュアデバイス１０が携帯端末３０との相互認証に用いる端末認証情報が入力される（ここで「入力される」とは、それぞれの情報が、コードとしてカードマネージャ１３に埋め込まれたり、必要なときにファイルとして取得可能であることを意味する）。
【００１８】
なお、本発明では、セキュアデバイス１０が携帯端末３０を認証することは必要であるが、携帯端末３０がセキュアデバイス１０を認証することは必ずしも必要ではない。各実施形態では、セキュアデバイス１０と携帯端末３０とが「相互認証」する場合について示しているが、相互認証は必須では無く、セキュアデバイス１０が携帯端末３０を認証する「片側認証」で良い。
【００１９】
図１には、このシステムにおいて、セキュアデバイス１０のカードアプリ１１が、携帯端末３０で動作するJava(登録商標)アプリ３１を認証するまでの手順を矢印で示している。
セキュアデバイス１０が携帯端末３０に装着されると、セキュアデバイス１０のカードマネージャ１３は、携帯端末３０のＪＡＭ３３との間で、それぞれの端末認証情報を用いて、装置間の相互認証処理を行う（１）。相互認証に成功すると、カードマネージャ１３は、その成功を示すフラグ（相互認証パスフラグ）をセキュアデバイス１０内に立てる。
【００２０】
なお、セキュアデバイスによる端末の認証方式については、種々のものが知られており、このシステムでも、それらの方式を用いることができる。例えば、ＴＣＰＡ（Trusted Computing Platform Alliance）の方式を用いて、セキュアデバイスがＢＩＯＳ（Basic Input Output System）を認証後、ＢＩＯＳがＯＳを認証し、次に、ＯＳがJava(登録商標)実行環境を認証するようにしてもよい。また、耐タンパ性のＳＩＭカードやセキュアＬＳＩを持つ携帯端末の場合には、チャレンジ＆レスポンス（challenge＆response）方式を用いることができる。要は、正規端末であることの認証が出来れば良く、特定機器へのバインド方式であっても一向構わない。
【００２１】
携帯端末３０のＪＡＭ３３は、セキュアデバイス１０との相互認証に成功すると、セキュアデバイス１０へのアクセス機能を開始し、Java(登録商標)アプリ３１は、ＪＡＭ３３に対してセキュアデバイス１０へのアクセスを要求する（２−１）。この要求を受けたＪＡＭ３３は、アプリ証明書に含まれる公開鍵を用いてJava(登録商標)アプリ３１の電子署名３４を検証し、それによりJava(登録商標)アプリ３１を認証する（２−２）。
【００２２】
電子署名３４の検証は、Java(登録商標)アプリ３１のデータにハッシュ演算を行ってダイジェストデータを生成し、このダイジェストデータと、電子署名３４を公開鍵で復号化したデータとを比較することによって行われる。それらが一致する場合には、ＪＡＭ３３は、Java(登録商標)アプリ３１の正当性を認証し、データが改ざんされていないことを確認することができる。
【００２３】
Java(登録商標)アプリ３１を認証したＪＡＭ３３は、生成したダイジェストデータと、Java(登録商標)アプリ３１の電子署名３４とをセキュアデバイス１０のカードアプリ１１に提示する（２−３）。これを受けて、カードアプリ１１は、署名検証用ルート証明書１４から得た公開鍵を用いて電子署名３４を復号化し、ＪＡＭ３３から送られたダイジェストデータとの一致を検証する。
Java(登録商標)アプリ３１を認証したＪＡＭ３３は、Java(登録商標)アプリ３１からのアクセス要求を実行し、カードアプリ１１にコマンドを送信する（３）。ダイジェストデータの検証に成功したカードアプリ１１は、カードマネージャ１３による機器認証が完了していることを相互認証パスフラグで確認した後、このコマンドを受け付ける。
【００２４】
このように、このアプリケーション認証システムのセキュアデバイスは、携帯端末で動作するアプリが正規のものであることを確認することで、そのアプリを認証する。そして、この確認を行うため、第１段階では、携帯端末を認証することにより、携帯端末の書き換え不可領域に格納されたJava(登録商標)実行環境（アプリ実行手段）の正当性を確認する。この確認が一度得られれば、アプリ実行手段の書き換えは不可能であるため、アプリ実行手段に対する信頼性は、その後も継続することとなる。
【００２５】
第２段階では、携帯端末の中でセキュアデバイスの信頼性を得たアプリ実行手段が、電子署名付きのアプリを認証し、このアプリのダイジェストデータと電子署名とをセキュアデバイスに渡す。
セキュアデバイスは、信頼を置くアプリ実行手段から、生成直後に渡されたダイジェストデータを信頼に足るものと見て、第３段階では、このダイジェストデータを電子署名によって検証する。
【００２６】
この検証結果が正常である場合、セキュアデバイスは、第１段階、第２段階、及び、第３段階の認証処理に基づいて、端末で動作するアプリが正規のアプリであると確認することができる。
このように、このアプリケーション認証システムでは、第１段階、第２段階、及び、第３段階の認証処理の連鎖により、セキュアデバイスが、安全な情報秘匿領域を持たない端末上のアプリに対して認証することを可能にしている。
【００２７】
（第２の実施形態）
本発明の第２の実施形態では、アプリを特定するための認証情報が格納されて発行されるセキュアデバイスと、そのアプリが動作する携帯端末とから成るアプリケーション認証システムについて説明する。
このセキュアデバイスは、携帯端末にダウンロードされるアプリと組になってサービスを実現するために作成されており、例えば、図８に示す「電子チケットアプリ」が携帯端末３０にダウンロードされる場合では、セキュアデバイス１０は、電子チケット用のセキュアデバイスと言うことになる。
【００２８】
図４は、このシステムを構成するセキュアデバイス１０と携帯端末３０とを模式的に示している。携帯端末３０のユーザ書き換え領域３０１に格納されているJava(登録商標)アプリ３１は、署名を有していない。そのため、ＪＡＭ３３へのアプリ証明書の入力は無い。また、セキュアデバイス１０には、Java(登録商標)アプリ３１を特定するためのダイジェストデータ１５などのアプリ認証情報が予め格納されている。その他の構成は、第１の実施形態と変わりが無い。
【００２９】
図３には、このシステムにおける認証手順を矢印で示している。
セキュアデバイス１０が携帯端末３０に装着されると、第１の実施形態（図１）と同様に、セキュアデバイス１０のカードマネージャ１３と、携帯端末３０のＪＡＭ３３との間で、装置間の相互認証処理が行われ（１）、相互認証に成功すると、カードマネージャ１３は、その成功を示す相互認証パスフラグをセキュアデバイス１０内に立てる。また、携帯端末３０のＪＡＭ３３は、セキュアデバイス１０との相互認証に成功すると、セキュアデバイス１０へのアクセス機能を開始し、Java(登録商標)アプリ３１は、ＪＡＭ３３に対してセキュアデバイス１０へのアクセスを要求する（２−１）。
【００３０】
この要求を受けたＪＡＭ３３は、Java(登録商標)アプリ３１のデータにハッシュ演算を行ってダイジェストデータを生成し（２−２）、このダイジェストデータをセキュアデバイス１０のカードアプリ１１に提示する（２−３）。カードアプリ１１は、相互認証パスフラグを参照して、カードマネージャ１３による機器認証が完了していることを確認した後、ＪＡＭ３３から提示されたダイジェストデータと、セキュアデバイス１０内で密かに保持されているダイジェストデータ１５とを照合し、認証結果をＪＡＭ３３に返す（２−４）。Java(登録商標)アプリ３１が認証されたことを知ったＪＡＭ３３は、Java(登録商標)アプリ３１からのアクセス要求を実行し、カードアプリ１１にコマンドを送信する（３）。
【００３１】
このように、このアプリケーション認証システムでは、アプリに対する電子署名が不要（勿論、有っても構わない）であり、システムを簡略化できる。
また、オペレータがアプリに署名を付けるシステムでは、オペレータによる統制を排除できないが、アプリに対する電子署名が不要なこのシステムでは、オペレータの影響を受けずにビジネスを展開することができ、アプリのダウンロードが可能な体制を整えた上で、アプリの認証情報を埋め込んだセキュアデバイスをユーザに配布すれば、直ぐにサービスを開始することができる。
【００３２】
なお、アプリ実行手段からセキュアデバイスへのアプリケーション認証のためのデータ（ダイジェストデータ）の提示処理である処理（２−３）のより具体的な方法としては、次のようなものが考えられる。例えば、ＰＩＮの照合などを行うときに使用する既存のコマンドのＶｅｒｉｆｙを使用して、ＰＩＮの替わりにアプリ認証用のデータを提示する手法や、ＩＣカードの外部認証で使用するchallenge＆responce方式用の既存のコマンドである GetChallenge と ExternalAutheticate において、秘密鍵の替わりにアプリ認証用のデータを使用して、データを提示する手法などである。
【００３３】
後者の場合、通常のchallenge-response方式では、機器Ｂが機器Ａを認証する場合、機器Ａから機器Ｂに対してchallenge-response処理のトリガにあたるGet Challengeを送信すると、機器Ｂにて、あらかじめ保持されている情報や任意に生成される情報（乱数など）である第一の情報を機器Ａに返信して、機器Ａにて前記第一の情報をあらかじめ保持している秘密鍵（秘密情報Ａ）などで暗号化した上で機器Ａに送信し（ExternalAutheticate）、機器Ｂにて暗号化された情報をあらかじめ保持している秘密鍵（秘密情報Ｂ：秘密情報Ａに対応した秘密情報）にて復号をし、復号によって得られる情報が、前記第一の情報と適合しているかを判断することになる。これを本発明に応用した場合、機器Ａはアプリ実行手段３３に、また、機器Ｂがカードアプリ１１に相当するが、機器Ａは秘密情報Ａに相当するデータをセキュアに保持しておく領域を有しないため、秘密情報Ａに替えてアプリ実行手段３３が生成したダイジェストデータを、また、秘密情報Ｂに替えてセキュアデバイスがあらかじめ保持しているダイジェストデータ１５をそれぞれ用いることで可能となる。
【００３４】
（第３の実施形態）
本発明の第３の実施形態では、携帯端末の中でセキュアデバイスの信頼性を得たアプリ実行手段が、電子署名付きのアプリを認証し、この認証結果をセキュアデバイスが受け入れるアプリケーション認証システムについて説明する。
図６は、このシステムを構成するセキュアデバイス１０と携帯端末３０とを模式的に示している。セキュアデバイス１０は、署名検証用ルート証明書を有していない。その他の構成は、第１の実施形態と変わりが無い。
【００３５】
図５には、このシステムにおける認証手順を矢印で示している。
セキュアデバイス１０が携帯端末３０に装着されると、第１の実施形態（図１）と同様に、セキュアデバイス１０のカードマネージャ１３と、携帯端末３０のＪＡＭ３３との間で、装置間の相互認証処理が行われ（１）、相互認証に成功すると、カードマネージャ１３は、その成功を示す相互認証パスフラグをセキュアデバイス１０内に立てる。また、携帯端末３０のＪＡＭ３３は、セキュアデバイス１０との相互認証に成功すると、セキュアデバイス１０へのアクセス機能を開始し、Java(登録商標)アプリ３１は、ＪＡＭ３３に対してセキュアデバイス１０へのアクセスを要求する（２−１）。この要求を受けたＪＡＭ３３は、アプリ証明書に含まれる公開鍵を用いてJava(登録商標)アプリ３１の電子署名３４を検証し、それによりJava(登録商標)アプリ３１を認証する（２−２）。このＪＡＭ３３によるJava(登録商標)アプリ３１の認証処理は、第１の実施形態で説明したものと同じである。
【００３６】
Java(登録商標)アプリ３１を認証したＪＡＭ３３は、Java(登録商標)アプリ３１からのアクセス要求を実行し、カードアプリ１１にコマンドを送信する（３）。セキュアデバイス１０のカードアプリ１１は、カードマネージャ１３による機器認証が完了していることを相互認証パスフラグで確認した後、このコマンドを受け付ける。
このように、このアプリケーション認証システムのセキュアデバイスは、携帯端末との相互認証で、携帯端末の書き換え不可領域に格納されたJava(登録商標)実行環境（アプリ実行手段）を認証すると、このアプリ実行手段により行われた、電子署名付きアプリの認証結果を信用して、このアプリを認証する。
【００３７】
このアプリケーション認証システムでは、アプリに署名を付ける方式を規定している既存方式（Ｊ２ＳＥなど）がそのまま利用可能であり、また、こうした方式を用いてアプリへ署名を付けているシステムは、この実施形態のシステムに、障害無く移行することができる。
また、このシステムでは、第２の実施形態の場合とは逆に、アプリへの署名付けの権利を持つオペレータなどの主体は、ビジネスをコントロールすることができる。
【００３８】
なお、セキュアデバイスには、各実施形態で示したように、格納されているデータへのアクセスをカードアプリが制御するプログラムアプリ型のデバイスと、格納したファイルにアクセスするためのセキュリティ条件を決めるファイルアプリ型のデバイスとがある。後者のセキュアデバイスでは、図７に示すように、Java(登録商標)実行環境がカードマネージャの認証をパスした場合に、Java(登録商標)実行環境が選択するＤＦ（Dedicated File）の傘下のＥＦ（Elementary File）へのアクセスが可能になり、また、各実施形態の方式でアプリが認証された場合に、そのアプリが選択するＤＦの傘下のＥＦへのアクセスが可能になるようにセキュリティ条件を設定することができる。
【００３９】
なお、セキュアデバイスがアプリ実行手段を認証した後でも、セキュアデバイスにおける端末への装着部にある端子から、悪意のある人間によって、アプリ実行手段になりすましてあたかもアプリ実行手段からの信号であるかのようにセキュアデバイスに指示を送ることも不可能とは言い切れなく、そのような場合、このなりすましを防ぐためには、確かにアプリ実行手段からの指示であることを確認できる工夫があると更に好ましい。その工夫としては次のようなものが考えられる。
【００４０】
つまり、カードマネージャ１３がアプリ実行手段３３を認証する処理（１）にて、カードマネージャ１３からアプリ実行手段３３へ任意の情報を送信して両者で共有するか、両者に共通の情報が保持されている（あるいは生成する）場合はその情報を記憶しておく。この情報を第二の情報とすると、アプリ実行手段３３からカードアプリ１１へアクセス要求を行う処理（３）にて、前記第二の情報も加味する。カードアプリ１１では、受信したアクセス要求に第二の情報が加味されている要求のみを受付、加味されていなければなりすましなど不正なアクセスとみなしその処理を受け付けない。なお、ここで「第二の情報を加味」とは、アクセス要求に第二の情報を付加したり、アクセス要求の全部または一部の情報を、そのまま乃至加工したものを暗号化したりすることなどを意味する。
【００４１】
【発明の効果】
以上の説明から明らかなように、本発明のアプリケーション認証システムでは、安全な情報秘匿領域を持たない端末上で動作するアプリに対して、セキュアデバイスによる認証が可能になる。そのため、端末上のアプリは、端末に装着されたセキュアデバイスのデータへのアクセスが可能になり、高度な処理を実行することができる。
【図面の簡単な説明】
【図１】本発明の第１の実施形態におけるアプリケーション認証システムの手順を示す図
【図２】本発明の第１の実施形態におけるアプリケーション認証システムの構成を示す図
【図３】本発明の第２の実施形態におけるアプリケーション認証システムの手順を示す図
【図４】本発明の第２の実施形態におけるアプリケーション認証システムの構成を示す図
【図５】本発明の第３の実施形態におけるアプリケーション認証システムの手順を示す図
【図６】本発明の第３の実施形態におけるアプリケーション認証システムの構成を示す図
【図７】本発明の実施形態におけるファイルアプリ型セキュアデバイスでのファイルアクセスを示す図
【図８】セキュアデバイスを装着した携帯端末で実現可能なサービスを示す図
【図９】携帯端末上のアプリをセキュアデバイスが認証するときの問題点を示す図
【符号の説明】
１０  セキュアデバイス
１１  カードアプリ
１３  共通ライブラリ（カードマネージャ）
１４  署名検証用ルート証明書
１５  ダイジェストデータ
３０  携帯端末
３１  Java(登録商標)アプリ
３２  ＯＳ
３３  Java(登録商標)実行環境（ＪＡＭ）
３４  電子署名
３５  秘密情報格納領域
３０１  ユーザ書き換え領域
３０２  書き換え不可領域
【図１】
0004067985.tif 000002
【図２】
0004067985.tif 000003
【図３】
0004067985.tif 000004
【図４】
0004067985.tif 000005
【図５】
0004067985.tif 000006
【図６】
0004067985.tif 000007
【図７】
0004067985.tif 000008
【図８】
0004067985.tif 000009
【図９】
0004067985.tif 000010