JP4956292B2 - 情報セキュリティ装置およびカウンタ制御方法 - Google Patents

Description

本発明は、セキュリティモジュール間でのセキュアなカウンタの共有方法に関するものである。

近年、情報セキュリティへの意識の高まりと共に、データを保護する技術ニーズが高まってきている。
これを背景として、セキュアなコンピュータプラットフォームを開発、普及させることを目的として、Ｔｒｕｓｔｅｄ Ｃｏｍｐｕｔｉｎｇ Ｇｒｏｕｐ（ＴＣＧ）が設立された。ＴＣＧでは、Ｔｒｕｓｔｅｄ Ｐｌａｔｆｏｒｍ Ｍｏｄｕｌｅ（ＴＰＭ）と呼ばれるセキュリティコアモジュールを利用し、安全な端末環境を実現している。安全な端末環境を実現するためのＴＣＧの一機能として、非特許文献１は、ＴＰＭ内で管理されているＭｏｎｏｔｏｎｉｃ Ｃｏｕｎｔｅｒと呼ばれるセキュアなカウンタ仕様がある。このカウンタは、端末内のプログラムや証明書を、古いバージョンのプログラムや証明書に書き変えるロールバック攻撃を防ぐために利用される。

上述したように、ＴＰＭでは、Ｍｏｎｏｔｏｎｉｃ Ｃｏｕｎｔｅｒの利用方法が制限されている。そのため、非特許文献２には、ＴＰＭ内のセキュアカウンタを新たに増やすことなく、ＴＰＭ外でＶｉｒｔｕａｌなＭｏｎｏｔｏｎｉｃ Ｃｏｕｎｔｅｒを実現する技術が開示されている。
また、特許文献１では、親カウンタと複数の子カウンタを利用したセキュアカウンタの実装方法が開示されている。
ＴＰＭ Ｍａｉｎ Ｐａｒｔ１ Ｄｅｓｉｇｎ Ｐｒｉｎｃｉｐｌｅｓ Ｓｐｅｃｉｆｉｃａｔｉｏｎ Ｖｅｒｓｉｏｎ１．２ Ｒｅｖｉｓｉｏｎ９４ 「Ｖｉｒｔｕａｌ Ｍｏｎｏｔｏｎｉｃ Cｏｕｎｔｅｒｓ ａｎｄＣｏｕｎｔ−Ｌｉｍｉｔｅｄ Ｏｂｊｅｃｔｓ ｕｓｉｎｇ ａ ＴＰＭ ｗｉｔｈｏｕｔ Ｔｒｕｓｔｅｄ ＯＳ（Ｅｘｔｅｎｄｅｄ Ｖｅｒｓｉｏｎ）」、Ｌｕｉｓ Ｆ．Ｇ．Ｓａｒｍｅｎｔａ（２００６） 特開２００４−３８９６８

非特許文献１記載の技術ではＴＰＭに搭載されるＭｏｎｏｔｏｎｉｃ Ｃｏｕｎｔｅｒの個数が少なく、且つそのカウンタの利用方法も制限されており、カウンタの追加や削除ができないという課題があった。さらには、Ｍｏｎｏｔｏｎｉｃ Ｃｏｕｎｔｅｒは、ＴＰＭ内で管理されるため、複数のＴＰＭ間でセキュアカウンタを共有することができないという課題があった。

また、非特許文献２記載の技術では、非特許文献１の課題を解決するために、ＴＰＭ内のセキュアカウンタを増やすことなく、ＴＰＭ外でＶｉｒｔｕａｌなＭｏｎｏｔｏｎｉｃ Ｃｏｕｎｔｅｒを実現している。しかしながら、複数のＴＰＭが１つの端末内にあるモデルにおいて、それら複数のＴＰＭ間でＶｉｒｔｕａｌなＭｏｎｏｔｏｎｉｃ Ｃｏｕｎｔｅｒを共有することができないというという課題があった。

また、特許文献１記載の技術も非特許文献２の記載の技術と同様に、１つのセキュアモジュールが、親カウンタと複数の子カウンタを管理する方法が開示されているが、１つのカウンタを複数のセキュアデバイス間で共有利用する仕組みがないという課題があった。
そこで、本発明は従来の課題を解決するもので、セキュアモリの使用量を抑えつつ、複数のセキュアモジュール間でツリー構造のカウンタを共有する方法と、共有したセキュアカウンタに対して柔軟な設定が可能なアクセス制御方法を提供することを目的とする。

上記の課題を解決するために、本発明に係る情報セキュリティ装置は、第１のプログラムと第２のプログラムを格納するプログラム格納手段と、第1のプログラムが利用する少なくとも１つ以上のカウンタから構成される第１カウンタ群と、第2のプログラムが利用する少なくとも１つ以上のカウンタから構成される第2のカウンタ群と、第１のカウンタ群と第２のカウンタ群を格納するカウンタ格納手段と、第１のカウンタ群の完全性を示すための情報である第1のカウンタ認証情報と、第２のカウンタ群の完全性を示すための情報である第２のカウンタ認証情報と、第１のカウンタ群のカウンタ認証情報、または、第２のカウンタ群のカウンタ認証情報を格納するセキュアメモリと、第１のカウンタ群の完全性を検証するために、第１のカウンタ認証情報と比較される値である第１のカウンタ算出情報、または、第２のカウンタ群の完全性を検証するために、第２のカウンタ認証情報と比較される値である第２のカウンタ算出情報を算出する測定手段と、測定手段にて算出された前記第１のカウンタ算出情報と前記第1のカウンタ認証情報との比較、または、第２のカウンタ算出情報と第２のカウンタ認証情報との比較する検証手段と、検証手段の比較結果によって、第１のプログラムからの第1のカウンタ群へのアクセス、または、第２のプログラムからの第２のカウンタ群へのアクセスを制御するカウンタ制御手段と、第１のカウンタ群を構成する少なくとも１つ以上のカウンタが、第２のカウンタ群を構成するカウンタであり、第２のカウンタ群を構成する少なくとも１つ以上のカウンタが、第１のカウンタ群を構成するカウンタである、少なくとも１つ以上の共有カウンタを備えることを特徴とする。

この構成によると、第１のプログラムで利用する第１のカウンタ群と、第２のプログラムで利用する第２のカウンタ群との間で、第１と第２のプログラムから、利用可能なカウンタを提供することが可能になる。さらには、セキュアメモリでは、カウンタ群を全てセキュアに記憶しておく必要はなく、カウンタ群から生成されるカウンタ認証情報のみを記憶しておけばよいため、必要となるセキュアなメモリサイズを抑えることが可能となる。さらには、従来はハードウェア内でカウンタを実装することでセキュアなカウンタを実現していたが、本発明により、セキュアメモリ外で複数のカウンタを有するカウンタ群を構築することが可能になるので、カウンタの個数を柔軟に設計することが可能となる。

また、本発明に係る情報セキュリティ装置は、第１のカウンタ群と第２のカウンタ群がそれぞれ、親ノードに、子ノードが格納しているデータを連結したデータに対する完全性を示すための情報であるハッシュ値を配置し、リーフノードに、カウンタの値を配置するツリー構造を備えることを特徴とする。
この構成によると、ツリー構造の中間のノードを共有するだけで、複数のカウンタの追加や削除や無効化といった設定が柔軟になる。さらには、各共有カウンタが、どのプログラムと共有化されているかの管理が容易になる。

また、本発明に係る情報セキュリティ装置は、カウンタ制御手段が、カウンタ管理テーブルを備え、カウンタ管理テーブルは、カウンタ群１、または、カウンタ群２を構成するノードを識別するノード識別情報と、ノードにアクセス可能なプログラムを識別するためのプログラム識別情報を含むことを特徴とする。
この構成によると、カウンタを利用可能なプログラムをプログラム識別情報で管理することが可能となる。

また、本発明に係る情報セキュリティ装置は、カウンタ管理テーブルに、前記共有カウンタに関連するノード識別情報と、共有カウンタにアクセス可能なプログラムを識別するためのプログラム識別情報を含むことを特徴とする。
この構成によると、共有カウンタを利用可能なプログラムをプログラム識別情報で管理することが可能となり、共有カウンタへアクセス可能なプログラムの追加や削除やアクセス制限の設定がより柔軟にできる。

また、本発明に係る情報セキュリティ装置は、カウンタ管理テーブルが、共有カウンタへアクセス可能なプログラムを識別するためのプログラム識別情報と共有カウンタへのアクセス可否情報とを対応づけて記憶しており、セキュアメモリが、共有カウンタを利用するプログラムの完全性を検証するためのプログラム認証情報を記憶し、測定手段が、プログラムの完全性を検証するためにプログラム認証情報と比較されるプログラム算出情報を算出し、検証手段が、プログラム算出情報と、プログラム認証情報を比較し、カウンタ制御手段が、検証手段から、比較の結果が等しいという結果情報を受信した時に、測定手段および検証手段により完全性を検証の対象であるプログラムのプログラム識別情報に対応するアクセス許可情報を、アクセス可に設定し、検証手段から、比較の結果が等しくないという結果を受信した時に、測定手段および前記検証手段により完全性を検証の対象であるプログラムのプログラム識別情報に対応するアクセス許可情報を、アクセス不可に設定することを特徴とする。

この構成によると、共有カウンタを利用可能なプログラムが改竄された場合に、改竄されたプログラムから共有カウンタへのアクセス制限をかけることが可能となる。
また、本発明に係る情報セキュリティ装置は、プログラムを更新するための更新手段を備え、更新手段が、共有カウンタ管理テーブルのアクセス許可情報が不可に設定されているプログラム識別情報に対応するプログラムの更新処理を行うことを特徴とする。

この構成によると、共有カウンタを利用可能なプログラムが改竄された場合に、アクセス許可情報を参照することで、更新すべきプログラムが端末内に存在するか確認できる。さらには、改竄されたプログラムが存在した場合、更新手段が、改竄されたプログラムを更新するため、端末内を、常に安全な環境にすることが可能となる。
また、本発明に係る情報セキュリティ装置は、セキュアモジュールを備え、セキュアモジュールが、測定手段と、検証手段と、カウンタ制御手段と前記セキュアメモリを含み、耐タンパ化されていることを特徴とする。

この構成によると、カウンタの操作に関連する各手段が、耐タンパ化されているので、カウンタがより安全に実装可能となる。
また、本発明に係る情報セキュリティ装置は、少なくとも2つ以上の前記セキュアモジュールを含むことを特徴とする。
この構成によると、複数のセキュアモジュール間での共有カウンタを構築することが可能となる。さらには、共有カウンタを利用して、セキュアモジュール間で共有して利用される共有データのバックアップ・リストア攻撃を防ぐことが可能となる。

また、本発明に係る情報セキュリティ装置は、前記セキュアモジュールが鍵生成手段と暗号化手段を備え、セキュアモジュールが共有して利用する共有データと、共有データを格納する共有データ格納手段とを備え、鍵生成手段が、共有カウンタを利用して共有データ暗号鍵を生成し、共有データを共有データ暗号鍵で暗復号処理することを特徴とする。
この構成によると、共有データをより安全に管理することが可能となる。具体的には、ＤＲＭアプリケーションにおける権利管理において、悪意のあるユーザが権利消費前の権利をバックアップしておき、権利を消費した後にバックアップしておいた権利消費前の権利をリストアすることで、永久に権利消費が行われないようなバックアップ・リストア攻撃を防止することが可能となる。

また、本発明に係る情報セキュリティ装置は、セキュアモジュールが、Ｔｒｕｓｔｅｄ Ｃｏｍｐｕｔｉｎｇ Ｇｒｏｕｐ（ＴＣＧ）で仕様化しているＴＰＭで実現されていることを特徴とする。
この構成によると、本発明に係る情報セキュリティ装置は、安全な実行環境を構築することができ、カウンタの制御もより安全に実行することが可能となる、
また、本発明に係る情報セキュリティ装置は、セキュアモジュールが、Ｔｒｕｓｔｅｄ Ｃｏｍｐｕｔｉｎｇ Ｇｒｏｕｐ（ＴＣＧ）で仕様化しているＭＴＭで実現されていることを特徴とする。

この構成によると、本発明に係る情報セキュリティ装置を携帯電話で実装することが可能となる。また、ＭＴＭの特徴であるマルチステークホルダー間でカウンタを共有することができる。さらには、共有カウンタを利用して、マルチステークホルダー間で利用する共有データに対するバックアップ・リストア攻撃を防ぐことが可能となる。
また、本発明に係るカウンタを制御方法は、少なくとも1つ以上のカウンタから構成される第１のカウンタ群と、少なくとも1つ以上のカウンタから構成される第２のカウンタ群をカウンタ格納手段に格納するステップと、カウンタ格納手段から、第１のカウンタ群、または前記第２のカウンタ群に対するアクセスするステップと、第１のカウンタ群を構成している第１のカウンタと、第２のカウンタ群を構成している第２のカウンタを共有するステップと、共有ステップにて共有したカウンタを読み出すリードステップと、共有ステップにて共有したカウンタの値を増加するインクリメントステップと、共有カウンタへアクセスするプログラムの完全性を検証するステップと、完全性検証ステップの結果、プログラムが改竄されていると判定された場合に前記プログラムが共有カウンタをアクセスを許可とするステップと、完全性検証ステップの結果、プログラムが改竄されていると判定された場合に前記プログラムが共有カウンタをアクセスを不許可とするステップとを含むことを特徴とする。

この構成によると、共有カウンタへアクセスするプログラムの完全性検証を行い、改竄されていないプログラムに対してのみ、共有カウンタを利用可能とすることができる。また、改竄されていると判定され、共有カウンタが利用不可となったプログラムが、正常にアップデートされた場合に、共有カウンタの利用を復活させることが可能となる。したがって、ユーザの故意でなくプログラムが壊れた場合にも、壊れたプログラムをアップデートさせることで再度カウンタを利用可能となる。

以下、本発明の実施の形態について、図面を参照しながら説明する。
（実施の形態１）
本発明の実施の形態について、以下に説明する
＜端末の構成＞
図１は、本実施の形態１における端末１０の全体構成図である。

本実施の形態１では、２つのアプリケーションＡｐｐ１（４１）、アプリケーションＡｐｐ２（４２）が、それぞれセキュアモジュール５０、６０内のカウンタ制御手段（５３、６３）が管理するカウンタ群（７１、７２）を利用して、共有データをアクセスして所望の処理を行う情報セキュリティ装置について説明する。
同図に示すように、情報セキュリティ装置１０は、ＣＰＵ２０、ＲＡＭ３０、プログラム格納手段４０、セキュアモジュール１（５０）、セキュアモジュール２（６０）、カウンタ格納手段７０、共有データ格納手段８０とから構成され、バス９０を介して互いに接続されている。

ＣＰＵ２０は、プログラム格納手段４０に格納されているプログラム、ＲＡＭ３０、セキュアモジュール１（５０）、セキュアモジュール（６０）に記憶されている各プログラムを実行することで、下記の各種の機能部を実現する。
ＲＡＭ３０は、揮発性の記憶媒体であって、プログラム格納手段４０に格納されているプログラムをロードし、記憶する。さらには、ＣＰＵ２０にて実行されるプログラムのワークメモリとして一時的なデータを記憶する。

プログラム格納手段４０は、不揮発性で、データの書込みおよび消去可能な記録媒体であり、例えば、ハードディスクやＦｌａｓｈメモリなどであり、本実施の形態では、アプリケーションＡｐｐ１（４１）とアプリケーションＡｐｐ２（４２）を記憶している。
セキュアモジュール１（５０）は、アプリケーションＡｐｐ１（４１）から利用され、検証手段５１、測定手段５２、カウンタ制御手段５３、暗号手段５４、セキュアメモリ５５、共有データアクセス手段５６から構成され、耐タンパ実装がされているモジュールである。

セキュアモジュール１（５０）内のセキュアメモリ５５は、不揮発性で、データの書込みおよび消去可能な記録媒体であり、カウンタ群１の認証ハッシュ値を格納する。ここで、認証ハッシュ値は、カウンタ群１の完全性を検証するために利用するハッシュ値である。この認証ハッシュ値の生成方法については、後述するので、ここでは説明を省略する。
セキュアモジュール１（５０）内の測定手段５２は、カウンタ群１（７１）の完全性を検証するために利用するハッシュ値を算出する手段であり、具体的には、ＳＨＡ（Ｓｅｃｕｒｅ Ｈａｓｈ Ａｌｇｏｒｉｔｈｍ）１アルゴリズムを用いる。

セキュアモジュール１（５０）内の検証手段５１は、測定手段５２によって算出されたカウンタ群１（７１）のハッシュ値と、認証されたカウンタ群１（７１）のハッシュ値を比較し、比較結果をカウンタ制御手段５３に通知する。
セキュアモジュール１（５０）内のカウンタ制御手段５３は、検証手段５１の結果に応じて、カウンタ群１（７１）のリード処理、インクリメント処理を制御し、それらに必要な情報をカウンタ管理情報に記憶している。ここで、リード処理とはカウンタの値を読み出す処理を、インクリメント処理とはカウンタの値を増加させる処理をいう。

暗号手段５４は、データの暗復号処理を行う。具体的な暗復号処理手段として、共通鍵暗号方式であるＡＥＳ（Ａｄｖａｎｃｅｄ Ｅｎｃｒｙｐｔｉｏｎ Ｓｔａｎｄａｒｄ）暗号や、公開鍵暗号方式であるＲＳＡ暗号、楕円暗号（Ｅｌｌｉｐｔｉｃ Ｃｕｒｖｅ Ｃｒｙｐｔｏｓｙｓｔｅｍ）である。
共有データアクセス手段は、Ａｐｐ１（４１）が共有データへアクセスする際に利用する手段であり、共有データ格納手段８０に対するリード・ライト処理や、暗号手段５４を利用して共有データの暗復号処理を行う。

セキュアモジュール２（６０）は、アプリケーションＡｐｐ２（４２）から利用され、検証手段６１、測定手段６２、カウンタ制御手段６３、暗号手段６４、セキュアメモリ６５、共有データアクセス手段６６から構成され、耐タンパ実装がされているモジュールである。
セキュアモジュール２（６０）内のセキュアメモリ６５は、不揮発性で、データの書込みおよび消去可能な記録媒体であり、カウンタ群２の認証ハッシュ値を格納する。認証ハッシュ値は、カウンタ群２の完全性を検証するために利用するハッシュ値である。この認証ハッシュ値の生成方法については、後述するので、ここでは説明を省略する。

セキュアモジュール２（６０）内の測定手段６２は、カウンタ群２（７２）の完全性を検証するために利用するハッシュ値を算出する手段であり、具体的には、ＳＨＡ1アルゴリズムを利用する。
セキュアモジュール２（６０）内の検証手段６１は、測定手段６２によって算出されたカウンタ群２（７２）のハッシュ値と、認証されたカウンタ群２（７２）のハッシュ値を比較し、比較結果をカウンタ制御手段６３に通知する。

セキュアモジュール２（６０）内のカウンタ制御手段６３は、検証手段６１の結果に応じて、カウンタ群２（７２）のリード処理、インクリメント処理を制御し、それらに必要な制御情報をカウンタ管理テーブルおよび共有カウンタ管理テーブルとしてカウンタ管理情報に記憶している。カウンタ管理テーブルおよび共有カウンタ管理テーブルについては後述する。

暗号手段６４は、データの暗復号処理を行う。具体的な暗復号処理手段として、共通鍵暗号であるＡＥＳ暗号や、公開鍵暗号方式であるＲＳＡ暗号、楕円暗号である。
共有データアクセス手段は、Ａｐｐ２（４２）が共有データへアクセスする際に利用する手段であり、共有データ格納手段８０に対するリード・ライト処理や、共有データの暗号手段６４を利用して暗復号処理を行う。

なお、セキュアモジュール１（５０）やセキュアモジュール（６０）は、Ｔｒｕｓｔｅｄ Ｐｌａｔｆｏｒｍ Ｍｏｄｕｌｅ（ＴＰＭ）で実現してもよい。またＴＣＧ Ｍｏｂｉｌｅ Ｐｈｏｎｅ ＷＧでは同等のセキュリティモジュールをＭｏｂｉｌｅ Ｔｒｕｓｔｅｄ Ｍｏｄｕｌｅ（ＭＴＭ）として定義しており、セキュアモジュール１（５０）やセキュアモジュール（６０）を、ＭＴＭとして実装してもよい。また、ＴＰＭ、ＭＴＭの実装方法は一般的には半導体を用いた実装により実現されるが、ソフトウェアで実現されてもよい。さらには、ハードウェアとソフトウェア組合せた実装方法でもよい。

また、測定手段（５２，６２）のハッシュ値算出にはＳＨＡ１を利用するとしたが、ＳＨＡ１処理に限定されるわけではなく、ＳＨＡ２５６や、鍵付きハッシュ関数であるＫｅｙｅｄ−Ｈａｓｈｉｎｇ ｆｏｒ Ｍｅｓｓａｇｅ Ａｕｔｈｅｎｔｉｃａｔｉｏｎ Ｃｏｄｅ（ＨＭＡＣ−ＳＨＡ１）でもよい。
なお、暗号手段（５４、６４）は、ＡＥＳ暗号、ＲＳＡ暗号、楕円暗号に限定されるわけではなく、共通鍵暗号方式、公開鍵暗号方式として一般に利用されている暗号方式であればよい。

なお、セキュアメモリ（５５，６５）は、セキュアモジュール内に存在していたが、セキュアモジュール外に配置してもよい。その場合、セキュアメモリは、セキュアモジュール外に存在することになるので、耐タンパ性を持たせるようにする。
カウンタ格納手段７０は、Ａｐｐ１（４１）がセキュアモジュール１（５０）を介して利用するカウンタ群１（７１）と、Ａｐｐ２がセキュアモジュール２（６０）を介して利用するカウンタ群２（７２）とを格納する手段であり、不揮発性で、データ書込み可能な記録媒体である。なお、カウンタ群１（７１）とカウンタ群（７２）が、それぞれセキュアモジュール１（５０）とセキュアモジュール２（５０）から利用されるときには、ＲＡＭ（３０）にロードしてから利用してもよい。その場合、カウンタのインクリメント処理等により、ＲＡＭ（３０）上でカウンタ群１（７１）、カウンタ群２（７２）が更新されれば、更新結果をカウンタ群格納手段７０へ反映する。

カウンタ群１（７１）とカウンタ群２（７２）は、１つ以上のカウンタと、そのカウンタから算出されるハッシュ値から構成され、ツリー構造で管理される。ツリー構造による管理については、図２を用いて後述する。
共有データ格納手段８０は、Ａｐｐ１（４１）とＡｐｐ２（４２）の両アプリケーションが利用する共有データを格納する手段である。共有データ格納手段８０へのアクセスは、Ａｐｐ１（４１）からはセキュアモジュール１（５０）の共有データアクセス手段５６を介して、Ａｐｐ２（４２）からはセキュアモジュール２（６０）の共有データアクセス手段６６を介してアクセスされる。本実施の形態１では、電子マネーや、ＤＲＭ（Ｄｉｇｉｔａｌ Ｒｉｇｈｔｓ Ｍａｎａｇｅｍｅｎｔｓ）での権利情報などの価値のある情報（以下、バリューと呼ぶ）をセキュアに扱うべき共有データ（セキュアデータ）とし、Ａｐｐ１（４１）とＡｐｐ２（４２）とが共にバリューを利用して、所望のアプリケーションサービスを実現するものとする。一般にこのようなセキュアデータを管理する場合、セキュアデータをバックアップして、バックアップしておいたデータを端末のメモリにリストア（再書込み）して古いバリューを使い、サービスを不正に受けるというバックアップ・リストア攻撃を防ぐ必要がある。そこで本実施の形態では、共有データを時変鍵で暗号化して管理するものとする。時変鍵とは、時間が経過するごとに、あるタイミングによって鍵の値が変化するものである。時変鍵については、後述する。

＜カウンタ群のツリー構造＞
図２は、Ａｐｐ１（４１）がセキュアモジュール１（５０）を介して利用するカウンタ群１（７１）のツリー構造を示している。
ここで、ルートノードとは親ノードを持たないノードであり、ツリー構造の頂点に位置する。また、中間ノードとは、親ノードと子ノードを持つノードである。また、リーフノードとは、親ノードのみを持つノードである。

同図に示すように、ここでは、カウンタ群１（７１）が、カウンタ（Ｃ１００、Ｃ１０１、Ｃ１０２、Ｃ１０３）の４つのカウンタを有しており、ツリー構造におけるリーフノードとして管理されている。また、ツリー構造の中間ノードであるｈ１００がカウンタＣ１００のハッシュ値、ｈ１０１がカウンタＣ１０１のハッシュ値、ｈ１０２がカウンタＣ１０２のハッシュ値、ｈ１０３がカウンタＣ１０３のハッシュ値を格納している。さらに、中間ノードのｈ１０は、ｈ１００とｈ１０１を連結した値のハッシュ値を格納しており、中間ノードｈ１１は、ｈ１０２とｈ１０３を連結した値のハッシュ値を格納している。さらに、ルートノードのｈ１は、ｈ１０とｈ１１を連結した値のハッシュ値を格納している。これらのリーフノードと中間ノードとルートノードは、双方向リストで実現されている。

セキュアモジュール１（５０）のセキュアメモリ５５は、認証ハッシュ値２００を記憶している。本実施の形態では、認証ハッシュ値２００は、セキュアカウンタ群の完全性を確認するために利用される値であり、ツリー構造のルートノードに格納されている値である。カウンタ群１（７１）は、セキュアメモリ外に格納されており、カウンタ群１（７１）を利用するには、ツリー構造のリーフノードからルートノード方向へと中間ノードに格納するためのハッシュ値を生成し、ルートノードに対応するハッシュ値と、セキュアメモリ５５内の認証ハッシュ値をと比較処理をして、比較結果が等しいときのみカウンタ群の利用を可能とする。このように、セキュアメモリ５５内でカウンタ群１（７１）を管理せず、ルートノードに対応するハッシュ値のみ、セキュアメモリ５５で管理することで、セキュアメモリ５５外にあるカウンタ群１（７１）の改竄を効果的に検知することが可能となる。さらには、カウンタ群１（７１）全体をセキュアメモリ５５内で管理する必要がないため、セキュアメモリのサイズを抑えることが可能となる。

また、図２に図示していないが、カウンタ群２（７２）も同様なツリー構造で管理される。
なお、本実施の形態では、カウンタ群は、二分木のツリー構造をとっているが、これに限定されるわけではなく、ツリー構造を有していればよい。
また、本実施の形態では、カウンタ群をツリー構造で実現しているが、ツリー構造に限定されるわけではなく、例えば、カウンタ値だけを持つ配列であってもよい。

＜カウンタ管理テーブル＞
図３は、カウンタ群１（７１）のリード処理、インクリメント処理を制御するために、セキュアモジュール１（５０）内のカウンタ制御手段５３が保持しているカウンタ管理テーブル３００である。カウンタ管理テーブ３００は、ツリーのルートアドレス３０１、ツリー構造情報（Ｎ分木）３０２、カウンタ個数３０３、カウンタ値アドレス管理テーブル３０４から構成される。カウンタアドレス管理テーブル３０６は、さらにカウンタＩＤ３０６と、カウンタアドレス３０７からなる。図３は、図２に示したカウンタ群１（７１）のカウンタ管理テーブルの例であり、ツリーのルートアドレス３０１が「０ｘ７０００４０００」、ツリー構造情報（Ｎ分木）３０２が、２分木を示す「２」、カウンタ個数３０３が「４」、カウンタＩＤ３０６「Ｃ１００」がアドレス「０ｘ８００００００」に、「Ｃ１０１」がアドレス「０ｘ８０００００４」に、「Ｃ１０２」がアドレス「０ｘ８０００００８」に、「Ｃ１０３」がアドレス「０ｘ８０００００Ｃ」に格納されていることを示している。カウンタ管理テーブル３０５を参照することで、カウンタ群１（７１）のリード処理、インクリメント処理が可能となる。

＜カウンタリード処理＞
続いて、カウンタ管理テーブル（３００、３０６）を参照して、Ａｐｐ１（４１）カウンタ群１（７１）のカウンタのリード処理について図４を用いて説明する。図４は、カウンタのリード処理のステップ処理である。
まず、Ａｐｐ１（４１）が、セキュアモジュール１（５０）のカウンタ制御手段５３に対して、カウンタのリード要求を出す。リード要求を受け付けたカウンタ制御手段５３は、リード対象のカウンタ値に対して、測定手段５２へハッシュ値計算を要求する（ステップＳ４０１）。具体的には、Ａｐｐ１（４１）がリード対象となるカウンタＩＤを指定して、カウンタ制御手段５３に対してカウンタのリード要求を出す。

次に、セキュアモジュール１（５０）の測定部５２が、カウンタ管理テーブル３００を参照し、要求されたカウンタ値のハッシュ値を計算する（ステップＳ４０２）。
次に、測定手段５２は、前のステップにて計算したハッシュ値とその兄弟にあたるハッシュ値とを連結した値のハッシュ値を生成し、ツリー構造のノード同士が双方向リストであることを利用し、１つ上の階層のノードへ参照先を移す（ステップＳ４０３）。

次に、カウンタアドレス管理テーブル３００のツリーのルートアドレス３０１を参照し、現在の参照ノードがルートノードかどうかを判定する（ステップＳ４０４）。ステップＳ４０４の判定の結果が、ＹＥＳ（現在参照中のノードがルートである）と判断されたなら、ステップＳ４０５へ処理を移す。一方、ステップＳ４０４の判定の結果が、ＮＯ（現在参照中のノードがルートでない）と判断されたなら、ステップＳ４０３へ処理を移す。

次に、検証手段５１が、ステップＳ４０３で算出された算出ハッシュ値と、セキュアメモリ内の認証ハッシュ値２００が等しいかどうかの比較をする（ステップＳ４０５）。
ステップＳ４０５の比較判定の結果が、ＹＥＳ（算出ハッシュ値と認証ハッシュ値が等しい）と判断されたなら、カウンタ制御手段は、カウンタをリードする（ステップＳ４０７）。

一方、ステップＳ４０５の比較判定の結果が、ＮＯ（算出ハッシュ値と認証ハッシュ値が等しくない）と判断されたなら、要求されたカウンタのリードは不許可とする（ステップＳ４０６）。
＜カウンタインクリメント処理＞
続いて、図５、図６を用いて、カウンタ管理テーブル３００を参照して、Ａｐｐ１（４１）カウンタ群１（７１）のカウンタのインクリメント処理について説明する。図５のステップＳ５０１からＳ５０５までは、図４のステップＳ４０１からＳ４０５と処理が同じであるため説明を省略する。異なるのは、ステップＳ５０５の判定の結果が、図４では、リードの許可／不許可であったのに対し、図５では、インクリメント許可／不許可である点のみである。インクリメントが許可されると、ステップＳ５０７にてカウンタのインクリメント処理がされる。

ここで、カウンタがインクリメントされると、ツリー構造におけるリーフノードの値が更新されたことになるので、ルートノードに格納するハッシュ値を再計算する必要があり、さらにはセキュアメモリ５５に保持している認証ハッシュ値を更新する必要がある。カウンタインクリメント時の認証ハッシュ値の更新処理が、図６である。
まず、カウンタ制御手段５３は、図５のステップＳ５０７にてインクリメントされたカウンタ値に対して、測定手段５２へハッシュ値計算を要求する（ステップＳ５０８）。

次に、セキュアモジュール１（５０）の測定手段５２が、カウンタ管理テーブル３００を参照し、要求されたカウンタ値のハッシュ値を計算する（ステップＳ５０９）。
次に、測定手段５２は、前のステップにて計算したハッシュ値とその兄弟にあたるハッシュ値とを連結した値のハッシュ値を生成し、ツリー構造のノード同士が双方向リストであることを利用し、１つ上の階層のノードへ参照先を移す（ステップＳ５１０）。

次に、カウンタアドレス管理テーブル３００のツリーのルートアドレス３０１を参照し、現在の参照ノードがルートノードかどうかを判定する（ステップＳ５１１）。ステップＳ５１１の判定の結果が、ＹＥＳ（現在参照ノードがルートである）と判断されたなら、ステップＳ５１２へ処理を移す。一方、ステップＳ５１１の比較判定の結果が、ＮＯ（現在参照ノードがルートでない）と判断されたなら、ステップＳ５１０へ処理を移す。

次に、測定手段５２により算出されたルートノードの値であるハッシュ値を認証ハッシュ値２００としてセキュアメモリ５５へ書き込み処理を行う（ステップＳ５１２）。
＜共有カウンタ作成＞
図７は、セキュアモジュール１（５０）で管理されている、Ａｐｐ１（４１）が利用するカウンタ群１（７１）と、セキュアモジュール２（６０）で管理されているＡｐｐ２（４２）が利用するカウンタ群２（７２）との間で、Ａｐｐ１（４１）とＡｐｐ２（４２）間でカウンタを共有するフロー図である。

まず、Ａｐｐ１（４１）が、Ａｐｐ２（４２）対してセキュアモジュール２（６０）が管理するカウンタの共有を依頼する（ステップＳ７０１）。
次に、Ａｐｐ２（４２）が、Ａｐｐ１（４１）を認証する（ステップＳ７０２）。認証方法は、予め各Ａｐｐに対して正当なＡｐｐであることを証明した証明書を関連付けておき、Ａｐｐ２（４２）がＡｐｐ１（４１）の証明書を検証する方法であるとする。具体的にはＰＫＩ（Ｐｕｂｌｉｃ Ｋｅｙ Ｉｎｆｒａｓｔｒｕｃｔｕｒｅ）で定めれた方法を用いるため、説明は省略する。なお、アプリケーション同士を認証しあう方法であれば特にこれに限定されない。

また、別の認証方法としては、セキュアモジュール１（５０）の測定手段５２と検証手段５１を利用し、Ａｐｐ１（４１）の改竄チェックを実行し、その結果をＡｐｐ２（４２）が受け取ってもよい。その場合、改竄チェックの結果は、暗号手段５４暗号化して送付するようにしてもよい。その際の暗号化に利用する鍵は、図示していないが、Ａｐｐ２（４２）の公開鍵やセキュアモジュール２の公開鍵を利用してもよい。また、Ａｐｐ１（４１）とＡｐｐ２（４２）間のＳＡＣ（Ｓｅｃｕｒｅ Ａｕｔｈｅｎｔｉｃａｔｉｏｎ Ｃｈａｎｎｅｌ）を用いて、セキュアな通信路を確立し、その通信路における送受信するデータの暗復号に利用するセッション鍵を共有して利用してもよい。

次に、ステップＳ７０３の検証の結果、Ａｐｐ１（４１）が正当であると判断された場合、ステップＳ７０４へ処理を移す。
一方、ステップＳ７０３の検証の結果、Ａｐｐ１（４１）が正当でないと判断された場合は、エラー結果をＡｐｐ２（４２）に返し、カウンタ共有処理を終了する。
Ａｐｐ１（４１）が正当であると判断された場合、セキュアモジュール２（６０）のカウンタ制御手段６３は、カウンタ群２（７２）に存在するカウンタを、Ａｐｐ1（４１）と共有するカウンタとして選択し、選択されたカウンタ情報（カウンタＩＤ/カウンタアドレス）に署名をつける（ステップＳ７０４）。具体的には、セキュアモジュール２（６０）は、セキュアモジュール２（６０）用に生成されたＲＳＡ鍵ペアの秘密鍵を有しており、暗号手段６４を利用しＲＳＡ署名生成する。なお、署名方法は、これに限定されず、ディジタル署名方式であれば他の方式でもよい。

次に、署名が付与された共有カウンタ情報がＡｐｐ２（４２）からＡｐｐ１（４１）へ送信される（ステップＳ７０５、Ｓ７０６）。
次に、Ａｐｐ１（４１）は、署名が付与された共有カウンタ情報の検証をセキュアモジュール１（５０）に依頼する（ステップＳ７０７）。
次に、セキュアモジュール１（５０）内のカウンタ制御手段５３は、暗号手段５４を利用して、署名検証する（ステップＳ７０８）。具体的には、セキュアモジュール１（５０）は、セキュアモジュール２（６０）用に生成されたＲＳＡ鍵ペアの公開鍵を有しており、暗号手段５４を利用しＲＳＡ署名生成する。なお、署名方法は、これに限定されず、、ディジタル署名方式で他の方式でもよい。

ステップＳ７０８の署名検証の結果、署名が正しいと判断されれば、ステップＳ７１０へ処理を移す。一方、署名が不正と判断されれば、エラー結果をＡｐｐ１（４１）に返し、カウンタ共有処理を終了する。
署名が正しいと判断された場合、セキュアモジュール１（５０）のカウンタ制御手段５３が、カウンタ制御手段５３が管理しているカウンタ管理テーブル３００に共有カウンタ情報を設定する。これにより、カウンタ群１（７１）を構成するツリー構造に共有カウンタがノードとして追加される。さらに、カウンタ群１（７１）は、共有カウンタがノードとして追加されたので、カウンタ群１のツリー構造の中間ノードとルートノードのハッシュ値を再計算する。再計算されたルートノードのハッシュ値は、セキュアメモリ５５に、カウンタ群１（７１）の認証ハッシュ値として格納される（ステップＳ７１０）。

次に、Ａｐｐ１（４１）は、設定完了通知を受信し（ステップＳ７１１）、設定完了通知をＡｐｐ２（４２）経由でセキュアモジュール２（６０）にも通知する（ステップＳ７１２、Ｓ７１３）。
最後に、セキュアモジュール２（６０）のカウンタ制御手段６３が、カウンタ制御手段６３が管理しているカウンタ管理テーブル３００に共有カウンタ情報を設定する（ステップＳ７１４）。

なお、ステップＳ７０４にて、カウンタ群２（７２）に存在するカウンタを共有カウンタとして選択しているが、共有用として新規にカウンタを生成してもよい。新規に生成したカウンタは、カウンタ群２のツリー構造のリーフノードとして追加される。そして、カウンタ群２のツリー構造の中間ノードとルートノードのハッシュ値を再計算し、再計算されたルートノードのハッシュ値は、セキュアメモリ６５に、カウンタ群２（７２）の認証ハッシュ値として格納されるようにしてもよい。

以上で、カウンタの共有フロー説明を終わる。
＜共有カウンタを有するカウンタ群ツリー＞
図８は、カウンタ群１（７１）とカウンタ群２（７２）の間で、複数のカウンタを共有したツリー構造を示した例である。
この図の場合は、Ａｐｐ１（４１）が利用し、セキュアモジュール１（５０）で管理されるカウンタ群１（７１）は、カウンタ（Ｃ１００、Ｃ１０１、Ｃ１０２、Ｃ１０３）と、中間ノード（ｈ１００、ｈ１０１、ｈ１０２、ｈ１０３、ｈ１０、ｈ１１）と、ルートノード（ｈ１）から構成されるツリー構造となる。一方、Ａｐｐ２（４２）が利用し、セキュアモジュール２（６０）で管理されるカウンタ群２（７２）は、カウンタ（Ｃ１０２、Ｃ１０３、Ｃ２０２、Ｃ２０３）と、中間ノードであるハッシュ値（ｈ１０２、ｈ１０３、ｈ２０２、ｈ２０３、ｈ１１、ｈ２１）と、ルートのハッシュ値（ｈ２）からなるツリー構造となる。共有カウンタ（８００）は、Ｃ１０２とＣ１０３である。

＜共有カウンタ管理テーブル＞
図９は、図８の場合の共有カウンタを、セキュアモジュール２（６０）のカウンタ制御手段３００が管理する共有カウンタテーブルを示している。
共有カウンタテーブル９００は、ノードＩＤ９０１、ノードアドレス９０２、共有カウンタ利用アプリＩＤ９０３からなる。ノードＩＤ９０１は、カウンタ群の各ノードを識別情報である。ノードアドレス９０２は、カウンタ群のノードがメモリ上のどこに記憶されているかを示すアドレス情報である。また、共有カウンタ利用アプリＩＤ９０３は、ノードＩＤ９０１が示すノードに対する利用可能なアプリケーションの識別情報である。

ここで、共有カウンタテーブルのデータ構造としては2種類のものが考えられる。
図９（ａ）は、共有カウンタである「Ｃ１０２」と「Ｃ１０３」が共有カウンタ管理テーブル９００として登録されている例である。この場合、共有カウンタＣ１０２が、アドレス「０ｘ８０００００００」に存在し、共有カウンタＣ１０２が、アドレス「０ｘ８００００００４」に存在し、それらは、Ａｐｐ１（４１）とＡｐｐ２（４２）で共有されていることを示している。図９（ａ）のようなデータ構造を用いて管理すると、各カウンタごとにそのカウンタを共有するアプリケーションを指定できるので、きめ細かな共有の制御ができる。

図９（ｂ）は、共有カウンタの親ノードであるｈ１１が共有カウンタ管理テーブル９１０として登録されている例である。この場合、「Ｃ１０２」と「Ｃ１０３」からルート方向へ辿り、Ｃ１０２とＣ１０３を両方含むノードＩＤ「ｈ１１」を共有カウンタ管理テーブル９１０に登録し、「ｈ１１」がアドレス「０ｘ７０００１１００」に存在し、「ｈ１１」がＡｐｐ１（４１）と、Ａｐｐ２（４２）とで共有されていることを示している。ここで、「ｈ１１」が共有可能なノードであれば、「ｈ１１」のノードから、リーフノードに至るまでのノード、すなわち「ｈ１１」、「ｈ１０２」、「ｈ１０３」、「Ｃ１０２」、「Ｃ１０３」がＡｐｐ１（４１）、Ａｐｐ２（４２）からアクセス可能なノードであることを示している。図９（ｂ）のようなデータ構造を用いて管理すると、ノードを指定するだけで、そのノードの子孫であるリーフノードに対応するカウンタ全てを共有する設定を一括してできる。そのため、特に共有するカウンタ数が多い場合に、管理が容易になる。さらには、共有管理テーブルのサイズを抑えることが可能となる。

＜３つのカウンタ群間における共有カウンタ＞
図８、図９では、２つのカウンタ群との間で、共有する例を説明したが、２つのカウンタ群に限定されることなく、複数のカウンタ群で共有してもよい。
図１０は、３つのカウンタ群であるカウンタ群１（１０１２）、カウンタ群２（１０２２）、カウンタ群３（１０３２）間でカウンタを共有する例を示している。

Ａｐｐ１（１０１０）は、セキュアモジュール１（１０１１）経由でカウンタ群１（１０１２）を利用し、Ａｐｐ２（１０２０）は、セキュアモジュール２（１０２１）経由でカウンタ群２（１０２２）を利用し、Ａｐｐ３（１０３０）は、セキュアモジュール３（１０３１）経由でカウンタ群３（１０３２）を利用する。
カウンタ群１（１０１２）は、カウンタ（Ｃ１００、Ｃ１０１、ＳＣ１００、ＳＣ１０１）と中間ノード（Ｎ１００、Ｎ１０１、ＳＮ１００、ＳＮ１０１）とルートノード（Ｎ１）からなるツリー構造を有している。

カウンタ群２（１０２２）は、カウンタ（ＳＣ１００、ＳＣ１０１、ＳＣ１１０、ＳＣ１１１）と中間ノード（ＳＮ１００、ＳＮ１０１、ＳＮ１１０、ＳＮ１１１、ＳＮ１０、ＳＮ１１）とルートノード（Ｎ２）からなるツリー構造を有している。
また、カウンタ群３（１０３２）は、カウンタ（ＳＣ１００、ＳＣ１０１、ＳＣ１１０、ＳＣ１１１、Ｃ３００、Ｃ３０１）と中間ノード（ＳＮ１００、ＳＮ１０１、ＳＮ１１０、ＳＮ１１１、Ｎ３００、Ｎ３０１、ＳＮ１０、ＳＮ１１、Ｎ３０）とルートノード（Ｎ３）からなるツリー構造を有している。

この図の場合の共有カウンタは、ＳＣ１００、ＳＣ１０１、ＳＣ１１０、ＳＣ１１１の４つである。
共有カウンタ群１０４０は、ＳＮ１０，ＳＮ１００、ＳＮ１０１、ＳＣ１００、ＳＣ１０１からなるツリーであって、Ａｐｐ１（１０１０）、Ａｐｐ２（１０２０）、Ａｐｐ３（１０３０）間で共有されるカウンタ群である。

共有カウンタ群１０５０は、ＳＮ１１，ＳＮ１１０、ＳＮ１１１、ＳＣ１１０、ＳＣ１１１からなるツリーであって、Ａｐｐ２（１０２０）、Ａｐｐ３（１０３０）間で共有されるカウンタ群である。
＜セキュアモジュール１，２，３の共有カウンタテーブル＞
図１１は、図１０に示した共有カウンタを、各セキュアモジュール（１０１１、１０１２、１０３２）がどのような共有カウンタ管理テーブルで管理するかを示した図である。

図１１（ａ）は、セキュアモジュール１（１０１１）が持つ共有カウンタ管理テーブル１１１０であり、図１１（ｂ）は、セキュアモジュール２（１０２１）が持つ共有カウンタ管理テーブル１１２０あり、図１１（ｃ）は、セキュアモジュール３（１０３１）が持つ共有カウンタ管理テーブル１０３２である。各共有カウンタ管理テーブル１１１０、１１２０、１１３０の項目は、図９（ｂ）で示した項目と同じであるので説明を省略する。このように、共有カウンタ管理テーブルを各セキュアモジュールのカウンタ制御手段が管理することで、より複雑な共有関係を有するカウンタを実現することができる。

以上のように、より柔軟でかつ、容易に、共有カウンタの追加が可能となる。
なお、本実施の形態では、共有カウンタを利用するアプリケーションIDを利用して、
共有カウンタの管理を行っているが、これに限定されない。例えば、セキュアモジュールに対してセキュアモジュールの識別情報であるセキュアモジュールIDを利用して共有カウンタを管理してもよい。

また、本実施の形態では、１つのセキュアモジュールに対して、ツリー構造を有するカウンタ群を対応しているが、１つのセキュアモジュールが、２つ以上のツリー構造を有するカウンタ群を管理してもよい。
また、本実施の形態では、カウンタ群格納手段に格納するカウンタ群を、平文の状態でおいているが、これに限定されるわけではない。例えば、図示していないが、各セキュアモジュールに対して、公開鍵暗号の鍵ペアを生成し、各セキュアモジュールが管理しているカウンタ群に対して、公開鍵で署名した形で保存してもよい。また署名でなく、ＡＥＳ暗号などの共通鍵暗号方式で暗号化して保存するようにしてもよい。さらには、カウンタ群のツリー構造におけるリーフノードであるカウンタ値に対してだけ、署名を付与してもよく、また、カウンタ群のツリー構造におけるリーフノードであるカウンタ値に対してだけ、暗号化してもよい。このようにすることで、カウンタ群に対する改竄をより困難にすることが可能となる。具体的には、セキュアモジュールがＴＰＭで実現されているならば、非特許文献２で開示している方法を利用してもよい。詳細は、非特許文献２に記載されているので、説明を省略する。

また、本実施の形態では、カウンタのリード処理、カウンタのインクリメント処理において、アプリケーションは、リード対象または、インクリメント対象のカウンタＩＤを指定するとしているが、アプリケーションの識別情報であるアプリIDも同時にカウンタ制御手段に通知してもよい。
＜マルチステークホルダーモデルにおける共有データ利用サービスシステム＞
続いて、共有カウンタを利用して、共有データのバックアップ・リストア攻撃を防ぐ実装方法について説明する。ここで、バックアップ・リストア攻撃とは、ある時点のデータをバックアップしておき、そのデータを再度メモリに書き戻して不正を行う攻撃である。バックアップ・リストア攻撃の対象となる具体的なデータとして、電子マネーのような価値のある情報（以降、バリューと呼ぶ）がある。特に、プリペイド型電子マネーは、ユーザが事前に現金を支払い、支払った金額に相当する情報が、バリューとして端末に書き込まれる。ユーザは、このバリューを消費することで、特定の商品やサービスを購入することが可能となる。バックアップ・リストア攻撃とは、消費前のバリューのデータをバックアップしておき、端末内のバリューを消費して特定の商品やサービスを購入した後、消費したバリューを復活させるために、バックアップしておいたバリューを再度、端末内に書き込む攻撃である。このような処理を繰り返すことで、不正ユーザは、永続的にバリューを使い続けることが可能になってしまう。また、電子マネーのようなバリューだけでなく、音楽コンテンツや映像コンテンツに対する再生回数や再生期限などの権利情報も同様にバックアップ・リストア攻撃の対象となる。

図１２は、複数のサービスアプリ間で共有データを利用し、ネットワークサービスを受けるサービスシステムである。
端末１２００は、ネットワーク１２６０経由でサービス１提供サーバー１２４０と、サービス２提供サーバー１２５０に接続する。
端末１２００は、サービス１アプリ１２１１とサービス２アプリ１２２１を有し、両アプリケーションは、共有データ格納手段１２３０に記憶されているバリュー１２３１を消費し、サービス１提供サーバー１２４０とサービス２提供サーバー１２５０からサービスを受ける。

サービス１アプリ１２１１は、セキュアモジュール１（１２１２）を利用し、バリュー１２３１にアクセスし、サービス１提供サーバー１２４０から所望のサービスを受ける。また、サービス２アプリ１２２１は、セキュアモジュール２（１２２２）利用して、バリュー１２３１にアクセスし、サービス２提供サーバー１２５０から所望のサービスを受ける。

ここで、サービス１アプリ（１２１１）とセキュアモジュール１（１２１２）は、サービス提供会社１から提供され、サービス２アプリ（１２２０）とセキュアモジュール２（１２２２）は、サービス提供会社２から提供される。このように１つの端末に複数の事業者のソフトウェアが搭載されるモデルは、ＭＴＭでは、マルチステークホルダーモデルと呼ばれる。

以降、サービス１アプリ１２１１と、セキュアモジュール１（１２１２）を１つのステークホルダー環境１２１０、サービス２アプリ１２２０と、セキュアモジュール２（１２２２）をもう１つのステークホルダー環境１２２０として、これら２つのステークホルダー間において、カウンタを共有し、その共有カウンタを利用して、共有データのバックアップ・リストア攻撃を防ぐ方法について説明する。

＜時変鍵前処理＞
本実施の形態では、共有データを時変鍵で暗号化することで、バックアップ・リストア攻撃に対処する。ここで時変鍵とは、時間の経過するごとに鍵の値が変化する暗号鍵を指す。以下、時変鍵の生成および利用方法について説明する。
図１３は、時変鍵を利用するための準備の処理を示したフローチャートである。

まず、共有カウンタを利用するアプリケーション間で相互認証する（ステップＳ１３０１）。相互認証の方法は、図７で説明した認証方法と同じである。
次に、ステップＳ１３０１の相互認証の結果を判定する（ステップＳ１３０２）。
相互認証の結果が「認証ＮＧ」であれば、時変鍵準備処理エラーとし、終了する。
一方、相互認証結果が「認証ＯＫ」であれば、ステップＳ１３０３へ処理を移す。

次に、相互認証されたアプリケーション同士で、時変鍵生成用の共有鍵を持ち合う（ステップＳ１３０４）。この共有鍵の設定方法は、相互に乱数を発生させて作成する。なお、乱数を生成する手段は図示していない乱数生成器を用いてもよいし、演算によって取得してもよい。なお、ここでの時変鍵生成用の共有鍵は、鍵データとしているが、これに限定されるわけではなく、共有カウンタを利用するアプリケーション同士のみが利用可能となるデータ情報であればよい。

最後に、時変鍵生成用の共有鍵を各アプリケーションが利用するセキュアモジュール内に共有鍵をセットする（ステップＳ１３０５）。具体的には、セキュアモジュール内のセキュアメモリ内に時変鍵生成用の共有鍵をセットする。
なお、時変鍵生成用の共有鍵の生成およびセキュアモジュールへの時変鍵生成用の共有鍵のセキュアメモリへのセット処理は、共有カウンタを利用するアプリケーション間で、一度行われれば良い。また、これに限定されることなく、共有データにアクセスする度に、毎回行っても良い。

なお、時変鍵生成用の共有鍵の設定方法は、これに限定されるわけではなく、予めセキュアモジュール内に埋め込んでおいてもよい。以降、時変鍵生成用の共有鍵を、共有鍵と略す。
＜時変鍵を用いた共有データの暗復号処理＞
続いて、図１４と図１５を用いて、時変鍵による共有データの暗復号処理について説明する。

ステップＳ１４０１からＳ１４０９は、時変鍵による共有データの暗号化ステップである。
まず、サービス１アプリ１２１１が、セキュアモジュール１（１２１２）に対して共有データ暗号化要求をする（ステップＳ１４０１）。
次に、セキュアモジュール１（１２１２）が、共有カウンタリード処理をする（ステップＳ１４０２）。カウンタリード処理は、図４で説明した処理であるので、説明を省略する。

次に、セキュアモジュール１（１２１２）が、リードした共有カウンタの値と、共有鍵から時変鍵を生成する（ステップＳ１４０３）。具体的には、共有カウンタと共有鍵とを連結したデータに対して、ＳＨＡ１アルゴリズムによりハッシュ値を算出し、算出されたハッシュ値から、共有データの暗号化に利用する鍵を生成し、そこで生成された鍵を時変鍵とする。ここで、共有データのヘッダには、暗号化アルゴリズムと、時変鍵の生成アルゴリズムが識別できる情報が付与されているものとする。具体的には、共有データの暗号化に、暗号アルゴリズムにＡＥＳ（鍵長１２８ビット）を用い、時変鍵の生成アルゴリズムにＳＨＡ１を用いる場合、それぞれを識別できる情報が関連づけられている。この場合、セキュアモジュールは、この共有データのヘッダを参照し、共有カウンタと共有鍵の値を連結して、ＳＨＡ１を用いて１６０ビットのハッシュ値を算出し、算出されたハッシュ値の上位１２８ビットを時変鍵とする。

なお、時変鍵生成方法は、これに限るものでなく、共有データをアクセスするアプリケーション同士で、同一の共有カウンタと共有鍵から同一の鍵が生成できる方法であればよい。
次に、暗号化対象の共有データをリードする（ステップＳ１４０４、Ｓ１４０５）。
次に、リードした共有データを、ステップＳ１４０３で生成した時変鍵１で暗号化する（ステップＳ１４０６）。

暗号化したデータを共有データとして書き込む（ステップＳ１４０７）。
サービスアプリ１（１２１１）は、書き込み完了通知（ステップＳ１４０８、Ｓ１４０９）を受信し、共有データの暗号化処理は終了する。
続いて、ステップＳ１４１０からＳ１４２４にて、時変鍵１で暗号化された共有データの復号ステップについて説明する。

まず、サービス２アプリ１２２１が、セキュアモジュール２（１２２２）に対して共有データ暗号化要求をする（ステップＳ１４１０）。
次に、セキュアモジュール２（１２２２）が、共有カウンタリード処理をする（ステップＳ１４１１）。カウンタリード処理は、図４で説明した処理であるので、説明を省略する。

次に、セキュアモジュール１（１２１２）が、リードした共有カウンタの値と、共有鍵から時変鍵１を生成する（ステップＳ１４１２）。時変鍵生成方法は、ステップＳ１４０３と同じであるため説明を省略する。
次に、復号対象の共有データを読み込み（ステップＳ１４１３、Ｓ１４１４）、ステップＳ１４１２で生成した時変鍵１で共有データを復号する（ステップＳ１４１５）。

次に、共有データを更新する（ステップＳ１４１６）。本実施の形態では、共有データを、バリューとし、バリューを消費することでサービスを受けるモデルなので、消費したバリューの値で共有データを更新する。
次に、共有カウンタをインクリメントする（ステップＳ１４１７）。共有カウンタのインクリメント処理は、図５、６で説明した処理と同じであるので、説明を省略する。

次に、インクリメントされた共有カウンタと共有鍵から、時変鍵１とは異なる鍵である時変鍵２を生成する（ステップＳ１４１８）。時変鍵２の生成方法は、ステップＳ１４０３と同じであるので説明を省略する。
次に、ステップＳ１４１８で生成した時変鍵２で、更新された共有データを暗号化する（ステップＳ１４１９）。

次に、時変鍵２で暗号化された共有データを、共有データ格納手段に書き込む（ステップＳ１４２０）。
次に、サービス２アプリ１２２１は、書き込み完了通知を受け取る（ステップＳ１４２１、Ｓ１４２２）。
次に、サービス２アプリ１２２１は、セキュアモジュール２（１２２２）が管理している共有カウンタ管理テーブルのアプリＩＤを参照することで、インクリメントした共有カウンタを利用している共有アプリを特定し、その共有アプリに共有カウンタを更新したことを通知する。ここでは、サービス２アプリ１２２１が、サービス１アプリ１２１１に対して、共有カウンタを更新したことを通知する（ステップＳ１４２３）。

次に、サービス１アプリ１２１１は、セキュアモジュール１（１２１２）に対して、共有カウンタ更新処理の要求をする（ステップＳ１４２４）。
セキュアモジュール１（１２１２）が管理する共有カウンタ値以外のノードは、共有カウンタがインクリメントされる前の情報となっているので、セキュアモジュール１（１２１２）が管理するツリー構造を有するカウンタ群の各ノードの更新処理と、認証ハッシュ値の更新処理を行う（ステップＳ１４２５）。

以上で、時変鍵を用いた共有データの暗復号処理についての説明を終わる。
なお、本実施の形態では、共有データを電子マネーのようなバリューとしたが、これに限定されるものでなく、音楽や映像などのデジタルコンテンツの権利情報、住所録、個人情報などのプライバシー情報なども考えられる。
（実施の形態２）
本実施の形態２では、ステークホルダーのアプリケーションの改竄検出時や更新時の共有カウンタのアクセス制御方法について説明する
＜更新システム＞
図１６は、端末１６００内のステークホルダーのアプリケーションを更新するための更新システムを示したものである。

端末１６００は、ネットワーク１６０３に接続し、更新サーバー１６０１から、端末内のステークホルダーのアプリケーションの更新プログラムをダウンロードする。
各ステークホルダーのアプリケーションには、アプリケーション識別子やバージョンが関連づけられており、端末１６００は、端末内のステークホルダー環境情報（アプリケーション識別子やバージョン情報）を、更新サーバーへ通知し、適切な更新プログラムをダウンロードする。

また、端末内のステークホルダー環境情報（アプリケーション識別子やバージョン情報）を、更新サーバーへ通知するとしているが、ＴＣＧ規格のＡｔｔｅｓｔａｔｉｏｎ処理を利用して更新してもよい。Ａｔｔｅｓｔａｔｉｏｎ処理については、ＴＣＧ規格で詳細が規定されているので、ここでの説明は省略する。
＜端末の全体構成＞
図１７は、実施の形態２における端末１６００の全体構成図である。端末１６００の構成要素としては、実施の形態１の図１で説明したものとほとんど同じであるので、図１と比べて新規な構成要素のみについて説明する。

図１７中、図１にない新規な構成要素は、更新手段１７９０と通信Ｉ／Ｆ１７９１である。
通信Ｉ／Ｆ１７９１は、端末１６００と外部の端末とのデータの送受信を行うインターフェースである。本実施の形態では、通信Ｉ／Ｆ１７１９を通して、更新サーバー１６０１とのデータの送受信を行う。

更新手段１７９０は、Ａｐｐ１（１７４１）とＡｐｐ２（１７４２）の更新プログラムのダウンロード要求を行い、ダウンロードした更新プログラムを利用して、プログラム格納手段に記憶しているＡｐｐ１（１７４１）またはＡｐｐ２（１７４２）の更新処理を行う。
＜共有カウンタのアクセス可否設定＞
続いて、図１８を用いてＡｐｐの改竄チェック処理と共有カウンタのアクセス可否設定処理について説明する。

本実施の形態では、セキュアモジュール１のセキュアメモリには、Ａｐｐ１（１７４１）の認証ハッシュ値が格納され、セキュアモジュール２のセキュアメモリには、Ａｐｐ２（１７４２）が格納されているものとする。なお、セキュアメモリへは、認証ハッシュ値でなく、Ｘ．５０９のような証明書を格納するようにしてもよい。その場合、証明書は、認証ハッシュ値を含むものとする。

まず、セキュアモジュールの測定手段が、プログラム格納手段に記憶されているＡｐｐのハッシュ値を算出する（ステップＳ１８０１）。
次に、セキュアモジュールの検証手段が、セキュアメモリ内の認証ハッシュ値と、ステップＳ１８０１で算出したハッシュ値を比較して、改竄チェックを行う（ステップＳ１８０２）。

ステップＳ１８０２の判定の結果、「改竄あり」と判定されたら、セキュアモジュールのカウンタ制御手段が、改竄のあったＡｐｐから共有カウンタへのアクセスを「不許可」に設定する（ステップＳ１８０３）。一方、「改竄なし」と判定されたら、セキュアモジュールのカウンタ制御手段が、改竄のないＡｐｐから共有カウンタへのアクセスを「許可」に設定する（ステップＳ１８０４）。

本実施の形態では、セキュアモジュール１（１７５０）が、Ａｐｐ１（１７４１）の改竄チェックを行い、セキュアモジュール２（１７６０）が、Ａｐｐ２（１７４２）の改竄チェックを行う。
このように、改竄チェック後に、共有カウンタへのアクセス許可／不許可設定を与えることで、改竄のあった不正なＡｐｐからの共有カウンタのアクセスを防止することが可能となる。また、改竄チェックのタイミングについては、端末起動（ブート）時であってもよいし、実行時に定期的なタイミングや、特定の処理をトリガーにして改竄チェックを行ってもよい。

＜Ａｐｐの改竄を検出後の共有カウンタテーブル＞
図１９は、セキュアモジュールがＡｐｐの改竄チェック後の共有カウンタテーブルの例である。具体的には、共有カウンタが実施の形態１の図８の状態で、セキュアモジュール２（１７６０）が、図１８のフローに基づきＡｐｐ２（１７４２）の改竄チェックを行い、Ａｐｐ２（１７４２）が改竄されていると判定された後のカウンタ制御手段１６６３が管理している共有カウンタテーブルを表している。共有カウンタ管理テーブル（１９１０、１９２０）は、図９と同じ構成要素については説明を省略する。図１９では、アクセス許可情報（１９１４、１９２４）が新項目として追加されている。

アクセス許可情報（１９１４、１９２４）は、共有カウンタへのアクセス許可に関する状態である「許可」また「不許可」が設定される。
図１９（ａ）は、図９（ａ）に対応しており、Ａｐｐ２（１７４２）の改竄チェックの結果、Ａｐｐ２（１７４２）が改竄されていると判定され、Ａｐｐ２（１７４２）が共有カウンタ「Ｃ１０２」「Ｃ１０３」へのアクセスが禁止されている状態を示している。図１９（ｂ）は、図９（ｂ）に対応しており、Ａｐｐ２（１７４２）の改竄チェックの結果、Ａｐｐ２（１７４２）が改竄されていると判定され、Ａｐｐ２（１７４２）が共有カウンタ「Ｃ１０２」「Ｃ１０３」へのアクセスが禁止されている状態を示している。

＜ネットワーク経由による更新フロー＞
図２０は、更新手段１７９０によるアプリケーションのネットワーク経由による更新フロー図である。
まず、更新手段１７９０が、セキュアモジュールに対して更新要否の確認を通知する（ステップＳ２００１）。

次に、セキュアモジュールが、共有カウンタ管理テーブルを確認する（ステップＳ２００２）。具体的には、共有カウンタ管理テーブル内のアクセス許可情報（１９１４、１９２４）を参照し、不許可となっているアプリＩＤを、更新要否結果として更新手段２００３に返す（ステップＳ２００２）。図１９のようにＡｐｐ２（１７４２）が不許可となっていれば、Ａｐｐ２（１７４２）のアプリＩＤ「Ａｐｐ００２」を返す。

次に、更新手段１７９０は、受信したアプリＩＤに対応するアプリケーションを更新するために、通信Ｉ／Ｆ１７１９を介して、更新サーバー１６０１にアプリＩＤと共に更新要求を出す（ステップＳ２００４、Ｓ２００５）。
次に、更新サーバー１６０１は、受信したアプリＩＤに対応する更新プログラムと、その更新プログラムの証明書を端末１６００に送信する（ステップＳ２００７）。ここで証明書は図示していないが、証明書には、更新プログラムのハッシュ値を含み、更新プログラムの完全性を検証する際に利用する。

端末１６００は、通信Ｉ／Ｆ１７９１を介して、更新サーバー１６０１から更新プログラムとその証明書を受信する（ステップＳ２００７、Ｓ２００８）。
次に、更新手段１７９０は、セキュアジュールに、受信した証明書をセキュアメモリ格納するように要求する（ステップＳ２００９）。
次に、セキュアモジュールは、証明書をセキュアメモリに格納する（ステップＳ２００９）。

最後に、更新手段１７９０が、更新プログラムで更新対象となるアプリケーションを更新する（ステップＳ２０１０）。
以上のフローにより、セキュアモジュールを利用するアプリケーションを、ネットワーク経由で更新することが可能となる。
なお、本実施の形態では、共有カウンタ管理テーブル内のアクセス許可情報（１９１４、１９２４）にアクセス不許可となっているアプリケーションを参照したことを契機に、ネットワーク経由で更新サーバー１６０１に対して更新プログラム１６０２のダウンロード要求を出しているが、更新プログラム１６０２のダウンロード要求のタイミングは、これに限定されない。更新サーバー１６０１からメッセージの受信時や、端末起動時であってもよい。また、アプリケーション実行時に、定期的なタイミングにより、アプリケーションに対する改竄検出を行って、改竄されていると判定されたら、更新プログラム１６０２のダウンロード要求を出すようにしても良い。

（その他変形例）
なお、本発明を上記実施の形態に基づいて説明してきたが、本発明は、上記の実施の形態に限定されないのはもちろんである。以下のような場合も本発明に含まれる。
（１）上記の各装置は、具体的には、マイクロプロセッサ、ＲＯＭ、ＲＡＭ、ハードディスクユニット、ディスプレイユニット、キーボード、マウスなどから構成されるコンピュータシステムである。前記ＲＡＭまたはハードディスクユニットには、コンピュータプログラムが記憶されている。前記マイクロプロセッサが、前記コンピュータプログラムにしたがって動作することにより、各装置は、その機能を達成する。ここでコンピュータプログラムは、所定の機能を達成するために、コンピュータに対する指令を示す命令コードが複数個組み合わされて構成されたものである。なお、各装置は、マイクロプロセッサ、ＲＯＭ、ＲＡＭ、ハードディスクユニット、ディスプレイユニット、キーボード、マウスなどの全てを含むコンピュータシステムには限らず、これらの一部から構成されているコンピュータシステムであってもよい。

（２）上記の各装置を構成する構成要素の一部または全部は、１個のシステムＬＳＩ（Ｌａｒｇｅ Ｓｃａｌｅ Ｉｎｔｅｇｒａｔｉｏｎ：大規模集積回路）から構成されているとしてもよい。システムＬＳＩは、複数の構成部を１個のチップ上に集積して製造された超多機能ＬＳＩであり、具体的には、マイクロプロセッサ、ＲＯＭ、ＲＡＭなどを含んで構成されるコンピュータシステムである。前記ＲＡＭには、コンピュータプログラムが記憶されている。前記マイクロプロセッサが、前記コンピュータプログラムにしたがって動作することにより、システムＬＳＩは、その機能を達成する。

また、上記の各装置を構成する構成要素の各部は、個別に１チップ化されていても良いし、一部又は全てを含むように１チップ化されてもよい。
また、ここでは、システムＬＳＩとしたが、集積度の違いにより、ＩＣ、ＬＳＩ、スーパーＬＳＩ、ウルトラＬＳＩと呼称されることもある。また、集積回路化の手法はＬＳＩに限るものではなく、専用回路又は汎用プロセッサで実現してもよい。ＬＳＩ製造後に、プログラムすることが可能なＦＰＧＡ（Ｆｉｅｌｄ Ｐｒｏｇｒａｍｍａｂｌｅ Ｇａｔｅ Ａｒｒａｙ）や、ＬＳＩ内部の回路セルの接続や設定を再構成可能なリコンフィギュラブル・プロセッサーを利用しても良い。

さらには、半導体技術の進歩又は派生する別技術によりＬＳＩに置き換わる集積回路化の技術が登場すれば、当然、その技術を用いて機能ブロックの集積化を行ってもよい。バイオ技術の適用等が可能性としてありえる。
（３）上記の各装置を構成する構成要素の一部または全部は、各装置に脱着可能なＩＣカードまたは単体のモジュールから構成されているとしてもよい。前記ＩＣカードまたは前記モジュールは、マイクロプロセッサ、ＲＯＭ、ＲＡＭなどから構成されるコンピュータシステムである。前記ＩＣカードまたは前記モジュールは、上記の超多機能ＬＳＩを含むとしてもよい。マイクロプロセッサが、コンピュータプログラムにしたがって動作することにより、前記ＩＣカードまたは前記モジュールは、その機能を達成する。このＩＣカードまたはこのモジュールは、耐タンパ性を有するとしてもよい。

（４）本発明は、上記に示す方法であるとしてもよい。また、これらの方法をコンピュータにより実現するコンピュータプログラムであるとしてもよいし、前記コンピュータプログラムからなるデジタル信号であるとしてもよい。
また、本発明は、前記コンピュータプログラムまたは前記デジタル信号をコンピュータ読み取り可能な記録媒体、例えば、フレキシブルディスク、ハードディスク、ＣＤ−ＲＯＭ、ＭＯ、ＤＶＤ、ＤＶＤ−ＲＯＭ、ＤＶＤ−ＲＡＭ、ＢＤ（Ｂｌｕ−ｒａｙ Ｄｉｓｃ）、半導体メモリなどに記録したものとしてもよい。また、これらの記録媒体に記録されている前記デジタル信号であるとしてもよい。

また、本発明は、前記コンピュータプログラムまたは前記デジタル信号を、電気通信回線、無線または有線通信回線、インターネットを代表とするネットワーク、データ放送等を経由して伝送するものとしてもよい。
また、本発明は、マイクロプロセッサとメモリを備えたコンピュータシステムであって、前記メモリは、上記コンピュータプログラムを記憶しており、前記マイクロプロセッサは、前記コンピュータプログラムにしたがって動作するとしてもよい。

また、前記プログラムまたは前記デジタル信号を前記記録媒体に記録して移送することにより、または前記プログラムまたは前記デジタル信号を前記ネットワーク等を経由して移送することにより、独立した他のコンピュータシステムにより実施するとしてもよい。
（５）上記実施の形態及び上記変形例をそれぞれ組み合わせるとしてもよい。

本発明にかかるツリー構造を有するカウンタ群に関するカウンタ制御方法を利用により、複数のセキュアモジュール間でセキュアなカウンタを共有することが可能となる。また、ツリー構造を有するカウンタでの共有設定を行うカウンタ制御方法により、共有カウンタの追加や、共有設定、共有解除といった操作が容易で、複雑な共有設定が可能になる。さらには、共有データに対する不正な書き戻し攻撃を防ぐことが可能となる。

本発明の実施の形態１における端末の全体構成を示す図 本発明の実施の形態１におけるツリー構造を有するカウンタ群１を示す図 本発明の実施の形態１におけるカウンタ管理テーブル示す図 本発明の実施の形態１におけるカウンタのリード手順を示すフローチャート 本発明の実施の形態１におけるカウンタのインクメント手順（前半）を示すフローチャート 本発明の実施の形態１におけるカウンタのインクメント手順（後半）を示すフローチャート 本発明の実施の形態１における共有カウンタ作成手順を示すフローチャート 本発明の実施の形態１におけるカウンタ群１とカウンタ群２間での共有カウンタを示す図 本発明の実施の形態１における共有カウンタ管理テーブルを示す図 本発明の実施の形態１におけるカウンタ群１とカウンタ群２とカウンタ群３間における共有カウンタを示す図 本発明の実施の形態１におけるセキュアモジュール１、２，３の共有カウンタ管理テーブルを示す図 本発明の実施の形態１におけるマルチステークホルダーモデルにおける共有データ利用サービスシステムを示す図 本発明の実施の形態１における時変鍵準備手順を示すフローチャート 本発明の実施の形態１における時変鍵による共有データ暗復号する手順を示すフローチャート 本発明の実施の形態１における時変鍵による共有データ暗復号する手順を示すフローチャート 本発明の実施の形態２における端末１６００内のステークホルダーのアプリケーションを更新するための更新システムを示す図 本発明の実施の形態２における端末の全体構成を示す図 本発明の実施の形態２における共有カウンタへのアクセス可否設定を示すフローチャート 本発明の実施の形態２における共有カウンタ管理テーブル 本発明の実施の形態２における端末内のステークホルダーの環境を更新する手順を示すフローチャート

符号の説明

１０ 情報セキュリティ装置
２０、１７２０ ＣＰＵ
３０、１７３０ ＲＡＭ
４０、１７４０ プログラム格納手段
４１、１０１０、１７４１ Ａｐｐ１
４２、１０２０、１７４２ Ａｐｐ２
１０３０ Ａｐｐ３
５０ 、１０１１、１２１２、１７５０ セキュアモジュール１
６０ 、１０２１、１２２２、１７６０ セキュアモジュール２
１０３１ セキュアモジュール３
５１、６１、１７５１、１７６１ 検証手段
５２、６２、１７５２、１７６２ 測定手段
５３、６３、１７５３、１７６３ カウンタ制御手段
５４、６４、１７５４、１７６４ 暗号手段
５５、６５、１７５５、１７６５ セキュアメモリ
５６、６６、１７５６、１７６６ 共有データアクセス手段
７０、１７７０ カウンタ格納手段
７１、１７７１ カウンタ群１
７２、１７７２ カウンタ群２
８０、１２３０、１７８０ 共有データ格納手段
９０、１７９０ バス
２００ 認証ハッシュ値
３００ カウンタ管理テーブル
３０１ ツリーのルートアドレス
３０２ ツリー構造情報
３０３ カウンタ個数
３０４、３０５ カウンタ値アドレス管理テーブル
３０６ カウンタＩＤ
３０７ カウンタアドレス
８００ 共有カウンタ群
９００、９１０、１１１０、１１２０、１１３０、１９１０、１９２０ 共有カウンタ管理テーブル
９０１、９１１、１１１１、１１２１、１１３１、１９１１、１９２１ ノードＩＤ
９０２、９１２ １１１２、１１２２、１１３２、１９１２、１９２２ ノードアドレス
９０３、９１３ １１１３、１１２３、１１３３、１９１３、１９２３ アプリＩＤ
１２００、１６００ 端末
１２１０、１２２０ ステークホルダー環境
１２１１ サービス１アプリ
１２２１ サービス２アプリ
１２３１ バリュー
１２４０ サービス１提供サーバー
１２５０ サービス２提供サーバー
１２６０、１６０３ ネットワーク
１６０１ 更新サーバー
１６０２ 更新プログラム
１７９０ 更新手段
１７９１ 通信Ｉ／Ｆ
１９１４、１９２４ アクセス許可情報

Claims (12)

1. 第１のプログラムと第２のプログラムを格納するプログラム格納手段と、
   前記第1のプログラムが利用する少なくとも１つ以上のカウンタから構成される第１カウンタ群と、
   前記第2のプログラムが利用する少なくとも１つ以上のカウンタから構成される第2のカウンタ群と、
   前記第１のカウンタ群と前記第２のカウンタ群を格納するカウンタ格納手段と、
   前記第１のカウンタ群の完全性を示すための情報である第1のカウンタ認証情報と、
   前記第２のカウンタ群の完全性を示すための情報である第２のカウンタ認証情報と、前記第１のカウンタ群のカウンタ認証情報、または、前記第２のカウンタ群のカウンタ認証情報を格納するセキュアメモリと、
   前記第１のカウンタ群の完全性を検証するために、前記第１のカウンタ認証情報と比較される値である第１のカウンタ算出情報、または、前記第２のカウンタ群の完全性を検証するために、前記第２のカウンタ認証情報と比較される値である第２のカウンタ算出情報を算出する測定手段と、
   前記測定手段にて算出された前記第１のカウンタ算出情報と前記第1のカウンタ認証情報との比較、または、前記第２のカウンタ算出情報と前記第２のカウンタ認証情報との比較する検証手段と、
   前記検証手段の比較結果によって、前記第１のプログラムからの前記第1のカウンタ群へのアクセス、または、前記第２のプログラムからの前記第２のカウンタ群へのアクセスを制御するカウンタ制御手段と、
   前記第１のカウンタ群を構成する少なくとも１つ以上のカウンタが、前記第２のカウンタ群を構成するカウンタであり、前記第２のカウンタ群を構成する少なくとも１つ以上のカウンタが、前記第１のカウンタ群を構成するカウンタである、少なくとも１つ以上の共有カウンタ
   を備えることを特徴とする情報セキュリティ処理装置。
2. 前記情報セキュリティ処理装置は、さらに、
   前記第１のカウンタ群と前記第２のカウンタ群がそれぞれ、親ノードに、子ノードが格納しているデータを連結したデータに対する完全性を示すための情報であるハッシュ値を配置し、リーフノードに、カウンタの値を配置するツリー構造
   を備えることを特徴とする請求項１に記載の情報セキュリティ装置。
3. 前記情報セキュリティ処理装置は、さらに、
   前記カウンタ制御手段が、カウンタ管理テーブルを備え、
   前記カウンタ管理テーブルは、前記カウンタ群１、または、カウンタ群２を構成するノードを識別するノード識別情報と、前記ノードにアクセス可能なプログラムを識別するためのプログラム識別情報を含むことを
   を特徴とする請求項２に記載の情報セキュリティ装置。
4. 前記情報セキュリティ装置は、さらに、
   前記カウンタ管理テーブルに、前記共有カウンタに関連するノード識別情報と、前記共有カウンタにアクセス可能なプログラムを識別するためのプログラム識別情報を含むこと
   を特徴とする請求項３記載の情報セキュリティ装置。
5. 前記情報セキュリティ装置は、さらに、
   前記カウンタ管理テーブルが、前記共有カウンタへアクセス可能なプログラムを識別するためのプログラム識別情報と前記共有カウンタへのアクセス可否情報とを対応づけて記憶しており、
   前記セキュアメモリが、前記共有カウンタを利用するプログラムの完全性を検証するためのプログラム認証情報を記憶し、
   前記測定手段が、前記プログラムの完全性を検証するために前記プログラム認証情報と比較されるプログラム算出情報を算出し、
   前記検証手段が、前記プログラム算出情報と、前記プログラム認証情報を比較し、
   前記カウンタ制御手段が、前記検証手段から、前記比較の結果が等しいという結果情報を受信した時に、前記測定手段および前記検証手段により完全性を検証の対象であるプログラムの前記プログラム識別情報に対応する前記アクセス許可情報を、アクセス可に設定し、
   前記検証手段から、前記比較の結果が等しくないという結果を受信した時に、前記測定手段および前記検証手段により完全性を検証の対象であるプログラムの前記プログラム識別情報に対応する前記アクセス許可情報を、アクセス不可に設定すること
   を特徴とする請求項４に記載の情報セキュリティ装置。
6. 前記情報セキュリティ装置は、さらに、
   前記プログラムを更新するための更新手段を備え、
   前記更新手段が、前記共有カウンタ管理テーブルの前記アクセス許可情報が不可に設定されている前記プログラム識別情報に対応するプログラムの更新処理を行う
   ことを特徴とする請求項５に記載の情報セキュリティ装置。
7. 前記情報セキュリティ装置は、さらに、
   セキュアモジュールを備え、
   前記セキュアモジュールが、前記測定手段と、前記検証手段と、前記カウンタ制御手段と前記セキュアメモリを含み、耐タンパ化されている
   ことを特徴とする請求項６に記載の情報セキュリティ装置。
8. 前記情報セキュリティ装置は、さらに、
   少なくとも2つ以上の前記セキュアモジュールを含むこと
   を特徴とする請求項７に記載の情報セキュリティ装置。
9. 前記情報セキュリティ装置は、さらに、
   前記セキュアモジュールが鍵生成手段と暗号化手段を備え、
   前記セキュアモジュールが共有して利用する共有データと、
   前記共有データを格納する共有データ格納手段とを備え、
   前記鍵生成手段が、前記共有カウンタを利用して共有データ暗号鍵を生成し、前記共有データを前記共有データ暗号鍵で暗復号処理する
   ことを特徴とする請求項８に記載の情報セキュリティ装置。
10. 前記情報セキュリティ装置は、さらに、
    前記セキュアモジュールが、Ｔｒｕｓｔｅｄ Ｃｏｍｐｕｔｉｎｇ Ｇｒｏｕｐ（ＴＣＧ）で仕様化しているＴＰＭで実現されていることを
    を特徴とする請求項９に記載の情報セキュリティ装置。
11. 前記情報セキュリティ装置は、さらに、
    前記セキュアモジュールが、Ｔｒｕｓｔｅｄ Ｃｏｍｐｕｔｉｎｇ Ｇｒｏｕｐ（ＴＣＧ）で仕様化しているＭＴＭで実現されていること
    を特徴とする請求項９に記載の情報セキュリティ装置。
12. カウンタを制御するカウンタ制御方法であって、
    少なくとも１つ以上のカウンタから構成される第１のカウンタ群と、少なくとも１つ以上のカウンタから構成される第２のカウンタ群をカウンタ格納手段に格納するステップと、
    前記カウンタ格納手段から、前記第１のカウンタ群、または前記第２のカウンタ群に対して、アクセスするステップと、
    前記第１のカウンタ群を構成している第１のカウンタと、前記第２のカウンタ群を構成している第２のカウンタを共有するステップと、
    前記共有ステップにて共有したカウンタを読み出すリードステップと、
    前記共有ステップにて共有したカウンタの値を増加するインクリメントステップと、
    前記共有カウンタへアクセスするプログラムの完全性を検証するステップと、
    前記完全性検証ステップの結果、プログラムが改竄されていると判定された場合に前記プログラムが共有カウンタをアクセスを許可とするステップと、
    前記完全性検証ステップの結果、プログラムが改竄されていると判定された場合に前記プログラムが共有カウンタをアクセスを不許可とするステップと
    を含むことを特徴とするカウンタ制御方法。

Images