JP4073913B2 - 開放型汎用耐攻撃ｃｐｕ及びその応用システム - Google Patents

開放型汎用耐攻撃ｃｐｕ及びその応用システム Download PDF

Info

Publication number
JP4073913B2
JP4073913B2 JP2004519192A JP2004519192A JP4073913B2 JP 4073913 B2 JP4073913 B2 JP 4073913B2 JP 2004519192 A JP2004519192 A JP 2004519192A JP 2004519192 A JP2004519192 A JP 2004519192A JP 4073913 B2 JP4073913 B2 JP 4073913B2
Authority
JP
Japan
Prior art keywords
code
central processing
processing unit
program
key
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Expired - Fee Related
Application number
JP2004519192A
Other languages
English (en)
Other versions
JPWO2004006075A1 (ja
Inventor
卓久 畠山
秀史 丸山
恵一 牛若
高行 長谷部
直昭 前田
敦浩 須賀
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Fujitsu Ltd
Original Assignee
Fujitsu Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Fujitsu Ltd filed Critical Fujitsu Ltd
Publication of JPWO2004006075A1 publication Critical patent/JPWO2004006075A1/ja
Application granted granted Critical
Publication of JP4073913B2 publication Critical patent/JP4073913B2/ja
Anticipated expiration legal-status Critical
Expired - Fee Related legal-status Critical Current

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/10—Protecting distributed programs or content, e.g. vending or licensing of copyrighted material ; Digital rights management [DRM]
    • G06F21/12—Protecting executable software
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/70—Protecting specific internal or peripheral components, in which the protection of a component leads to protection of the entire computer
    • G06F21/71—Protecting specific internal or peripheral components, in which the protection of a component leads to protection of the entire computer to assure secure computing or processing of information

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • Computer Hardware Design (AREA)
  • Software Systems (AREA)
  • Computer Security & Cryptography (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Mathematical Physics (AREA)
  • Multimedia (AREA)
  • Technology Law (AREA)
  • Storage Device Security (AREA)

Description

本発明は、機器内部の情報を改ざんしたり、秘密情報を取り出したりしようとする攻撃に対して対抗する技術に関する。
近年、デジタルコンテンツの流通の促進に伴い、著作権などのコンテンツに係わる権利を保護する技術（ＤＲＭ：（Digital Rights Management）が提供されている。ＤＲＭの例として、例えば、三洋電機、日立、富士通の３社が共同開発したＵＤＡＣ（Universal Distribution with Access Control）が挙げられる。
ＵＤＡＣのようなＤＲＭを実装する際、コンテンツ保護のセキュリティを十分なレベルにするためには、利用者のシステムにおいてＤＲＭをＴＲＭ（Tamper Resistant Module）とすることが重要である。（以下、ＤＲＭをＴＲＭとすることをＤＲＭのＴＲＭ化という。） 現在、コンシューマ向けの製品で一般に実施されるＴＲＭ化には、大きく分けてハードウェアＴＲＭ及びソフトウェアＴＲＭの２つの方法がある。
ハードウェアＴＲＭとは、半導体の外部端子から秘密情報の読み出しなどができない構造にし、特殊コーティングや極微細化などを施すことによって実現されたＴＲＭである。ハードウェアＴＲＭをソフトウェアＴＲＭと比較して、特に「攻撃対抗容器」と呼ぶこともできる。ソフトウェアＴＲＭとは、暗号化させたいコードを解析困難な構造にして暗号化し、そのコードを実行の瞬間に復号することによって実現されたＴＲＭである。
しかし、従来のＴＲＭには、以下のような問題があった。
１． ハードウェアＴＲＭの問題
・コンシューマ向け用途ではコストを重視する関係上ＤＲＭを半導体パッケージ化する必要があるが、一つのチップに盛り込むことができるリソースには限りがあるため、多様な機能を提供することはできない。ライセンスキーやＣＲＬ（Certificate Revocation List）を記録する領域の大きさを拡張したい場合や、コンテンツ利用条件をＸｒＭＬ（eXtensible rights Markup Language）で表現したい場合などには、ハードウェアＴＲＭでは対応できない。
・安全性を重視すると、利用するプロセッサと記録媒体をすべてハードウェアＴＲＭ内に持つ必要があるが、このため製造後に機能を拡張させることが困難になっている。また、このことからソフトウェアが利用できる記録媒体が限定されるため、リソース消費が高い一般の（保護の必要がない）ソフトウェアを同時にプロセッサに実行させることは困難である。また、暗号鍵が異なる複数の保護ソフトウェアを同時にプロセッサに実行させることも困難である。つまり、ハードウェアＴＲＭには汎用性がない。
・コンテンツの種類の追加やＤＲＭのバーションアップごとに新たなチップの開発し、新たに半導体製造工程などのラインを起こすことが必要となるため製造コストが大きくなる。
・互換性を持つ汎用ＣＰＵチップ上にそれぞれのソフトウェアを開発・搭載するだけで何種類もの機能を利用者に提供することによりスムーズなバグ修正や機能拡張も実現してきた「情報技術の逐次進化」を阻害しかねなかった。
２． ソフトウェアＴＲＭの問題
・おおもとの秘密鍵は暗号化することができず、どのように分散などして保管してもソフトウェア解析だけで容易に秘密鍵を見つけ出すことができる。
・ハードウェアＩＣＥ（In Circuit Emulator）を用いれば実行内容をトレースすることにより、秘密鍵を始めとする各種秘密情報を容易に見つけ出すことができる。
特開２００１−２３０７７０号公報
本ＣＰＵ及びその応用システムの目的は、上記問題を解決し、ソフトウェアＴＲＭ並みの汎用性を持ちつつも、ハードウェアＴＲＭ並みの安全性を有するＴＲＭを提供することである。
上記目的を達成するために、本ＣＰＵ及びその応用システムの１態様によれば、中央演算装置において、秘密裏に隠された第１の秘密鍵と、暗号化及び復号を行う暗号手段とを備え、前記第１の秘密鍵は、公開鍵と対であり、前記暗号手段は、前記公開鍵を用いて暗号化された第１のプログラムの第１のライセンスを前記第１の秘密鍵を用いて復号することにより、前記第１のライセンスから前記第１のプログラムを復号するためのコード復号鍵を取得するように構成する。なお、コード復号鍵は、第１のプログラムを暗号化する際に使用されたコード暗号鍵と同じであってもよい。また、第１のライセンスは、第１のプログラムに埋め込まれる事としてもよいし、両者は別々に流通する事としても良い。
このように構成することにより、前記第１のプログラムを復号するための鍵を得るために必要な秘密鍵は、中央演算装置内に秘密裏に記録されているため、分散されて保管されることはない。従って、プログラムを解析する事によって秘密鍵が容易に発見されてしまうという問題を解決する事ができる。
また、上記中央演算装置は、キャッシュを更に備え、前記暗号手段は、前記第１のプログラムを構成する暗号化ブロックがメモリ領域から前記キャッシュに出力される際に、キャッシュ単位で前記暗号化ブロックを復号する、こととしてもよい。キャッシュ単位で暗号化ブロックを復号し、キャッシュに記録することにより、従来より安全性を向上させることが可能となる。
さらに、また、上記中央演算装置は、ユーザが参照したり改ざんしたりすることができない耐攻撃バッファを更に備え、前記コード復号鍵は、前記耐攻撃バッファに記録されることとしてもよい。耐攻撃バッファ内に記録された鍵は、カーネルモードであってもユーザが参照したり改ざんしたりする事ができないため、コード復号鍵を安全に保持することが可能となる。
ここで、前記耐攻撃バッファは、さらに、外部出力禁止情報及びキャッシュロック情報を含み、前記外部出力禁止情報は、対応する前記耐攻撃バッファ内の情報を前記耐攻撃バッファ外に出力しても良いか否かを示し、前記キャッシュロック情報は、対応する情報をキャッシュ外に出力しても良いか否かを示し、
前記外部出力禁止情報及び前記キャッシュロック情報に基づいて、第１のプログラム及び他のプログラムとの間における前記第１のライセンスの移動は管理されることとしてもよい。これにより、前記中央演算装置に、複製不能プライベートロッカーを実現させる事が可能となる。従って、例えば、複数のプログラム間においてライセンスを移動可能とする場合であっても、再送攻撃によるライセンスの不正コピーを防止することが可能となる。
また、上記中央演算装置において、前記第１のライセンスは、前記第１のプログラムの実行プロセスがメモリ領域にアクセスする際のアクセス条件を含み、前記第１のプログラムを構成する暗号化ブロックが記録される前記メモリ領域のアドレスと前記メモリ領域へのアクセス条件とを記録するＴＬＢ（Translation Lookaside Buffer）と、メモリ管理手段と、キャッシュと、プロセッサコアを更に備えるように構成してもよい。この構成において、前記耐攻撃バッファは前記ＴＬＢとリンクされ、前記メモリ管理手段は、前記暗号化ブロックを記録するメモリ領域のアドレスに基づいて前記ＴＬＢから前記メモリ領域へのアクセス条件を取得し、さらに、前記耐攻撃バッファから、前記メモリ領域に対応する前記コード復号鍵を取得する。前記プロセッサコアは、前記メモリ管理手段が取得した前記アクセス条件に基づいて、前記実行プロセスから前記メモリ領域へのアクセスを実行することが許可されているか否か判定し、前記メモリ領域へのアクセスを実行する事が許可されていると判定した場合、前記実行プロセスから前記メモリ領域へのアクセスを実行する。前記暗号手段は、前記メモリ管理手段が取得した前記コード復号鍵を用いて前記メモリ領域内の前記暗号化ブロックを復号して得られたコードを前記キャッシュに書き込む。
メモリ領域は、ＴＬＢを介して耐攻撃バッファと対応付けられており、そのメモリ領域に書きこまれたブロックを復号するための鍵は、この対応関係に基づいて取得される。さらに、メモリ領域へのアクセスも、ＴＬＢ内のアクセス条件に従って制御される。従って、安全にメモリ領域へのアクセス制御及びブロックのキャッシュへのロードを行うことが可能となる。
ここで、前記第１のプログラムの実行プロセスからアクセスされるメモリ領域が、第１のメモリ領域から第２のメモリ領域に切り替わった場合、前記メモリ管理手段は、さらに、前記耐攻撃バッファから取得された前記第１のメモリ領域に対応するコード復号鍵と、前記第２のメモリ領域に対応するコード復号鍵とが一致するか否か判定し、一致すると判定した場合、前記実行プロセスから前記第２のメモリ領域へのアクセスを実行し、一致しないと判定した場合、前記実行プロセスから前記第２のメモリ領域へのアクセスを実行しない、こととしてもよい。これにより、Call、JumpまたはReturn等の命令によって、あるメモリ領域から、そのメモリ領域に対応するコード復号鍵と異なる他のコード復号鍵が対応している他のメモリ領域に実行中アドレスが移動した際には、その実行プロセスから上記他のメモリ領域にはアクセスできないこととなる。これにより、あるオーナープロセスが、他のオーナープロセスのメモリ領域へアクセスすることを禁止することが可能となる。
さらにまた、上記中央演算装置において、前記耐攻撃バッファには前記コード暗号鍵ごとに、異なるデータ暗号鍵が記録され、前記暗号手段は、前記データ暗号鍵を用いて前記キャッシュ内のデータを暗号化した後、前記ＴＬＢを介して前記データ暗号鍵に対応付けられたメモリ領域に記録し、前記メモリ領域から暗号化されたデータを読み出して前記データ暗号鍵を用いて復号した後、前記キャッシュに書き込むこととしてもよい。これにより、データをメモリ領域に退避させたり、キャッシュにロードさせたりする操作を、安全に行う事が可能となる。
また、上記中央演算装置において、第１のコードを実行することにより得られた作業データを第２のコードで利用する場合、前記プロセッサコアは、前記作業データを記録するメモリ領域へのアクセス権を前記第２のコードに与えるように前記ＴＬＢを設定し、且つ、前記作業データを暗号化するためのコード暗号鍵を、前記第２のコードが前記作業データを前記メモリ領域から読み出す際に使用するように前記耐攻撃バッファを設定することとしてもよい。
これにより、通常、第１のコードのコード暗号鍵と、第２のコードのコード暗号鍵が異なる場合であっても、第１のコードと第２のコードとがデータ暗号鍵を共用することにより第１のコードを実行した結果得たデータを第２のコードが読み出す事が可能となる。従って、前記中央演算装置が２以上のソフトウェアを保護しながら実行する場合であっても、必要に応じて安全にメモリ領域を共有する事が可能となる。
また、上記中央演算装置において、レジスタと、レジスタへのアクセス制御を行うためのレジスタアクセス制御テーブルと、を更に備え、前記プロセッサコアは、前記レジスタアクセス制御テーブル内の封印フラグを用いて、前記レジスタの封印及び解放を制御する、こととしてもよい。これにより、プロセスがデータをレジスタに格納する場合には、現在実行中のプロセス以外からレジスタに格納されたデータにアクセスする事ができないように封印することが可能となる。
また、上記中央演算装置において、前記ＴＬＢの内容を外部のページテーブルに記録する際には、前記暗号手段は、記録する内容に署名を付与し、前記ページテーブルの内容を前記ＴＬＢに取り込む前には、前記暗号化手段は、前記署名が正しいことを確認する、こととしてもよい。これにより、ＴＬＢの内容を安全にページテーブルに保持させる事が可能となる。
また、上記中央演算装置において、前記耐攻撃バッファの内容を外部記憶装置内の暗号化キーテーブルに記録する際には、前記暗号手段は、記録する内容を暗号化することとしてもよい。これにより、耐攻撃バッファの内容を外部記憶装置に安全に保持する事が可能となる。
なお、ＴＬＢの内容の署名を作成する際に使用される秘密鍵、及び耐攻撃バッファの内容を暗号化する際に使用される秘密鍵は、ともに、中央演算装置内のプロセッサによって生成されることとしてもよい。
また、前記中央演算装置は、他の中央演算装置と接続され、前記中央演算装置は、前記他の中央演算装置と相互に認証を行う事にことによりセッション鍵を取得し、前記中央演算装置の前記暗号手段は、前記セッション鍵を用いて前記中央演算装置の前記キャッシュの内容を暗号化して、前記他の中央演算装置に同期転送する、こととしてもよい。これにより、上記構成を有する中央演算装置を複数有するマルチＣＰＵにおいて、キャッシュ内の内容を安全に同期させることが可能となる。
また、上記中央演算装置において、前記暗号手段は、前記第１のプログラムを実行する前に、前記公開鍵を用いて第２のプログラムに付加された前記第２のライセンスを復号する事により第２の秘密鍵を暗号化する際に用いられた秘密鍵暗号鍵を取得し、さらに、前記取得された秘密鍵暗号鍵を用いて前記第２の秘密鍵を復号する、こととしてもよい。
また、この際に、前記第２のライセンスには、第１のプログラムの実行プロセスから読み出しのみ可であることを示すアクセス条件が付加されており、前記第２の秘密鍵は、前記第１のプログラムの実行プロセスからの読み出しのみ可能であることとしてもよい。第２の秘密鍵を第１のプログラムの実行プロセスからのみ読むことができないこととすることにより、秘密情報を安全に維持管理することが可能となる。
なお、前記第１のプログラムは、ＴＲＭ化が要求されるどのようなソフトウェアであってよい。例えば、第１のプログラムとして、トラステッドコンピューティングモジュール、前記中央演算装置に電子財布を実現させるプログラム、個人情報を扱うソフトウェア、前記中央演算装置の実装コードのウィルスチェックソフトウェア、複数の中央演算装置間を移動する移動エージェント、ロボットの制御プログラム、ＩＣカード用のセキュリティプログラム等が挙げられる。
また、上記中央演算装置において、前記第１のプログラムを構成するブロックには様々な形態が考えられ、それに応じて中央演算装置に更なる手段を備える事としてもよい。
例えば、ブロックは、ブロックのハッシュ値の確認が必要であるか否かを示すハッシュ確認要否情報を含み、前記ハッシュ確認要否情報に基づいて、前記ブロックのハッシュ値を算出し、前記ブロックに付加するハッシュ手段と、前記ハッシュ確認要否情報に基づいて、前記ブロックの前記ハッシュ値を確認するハッシュ確認手段と、を更に備えることとしてもよい。
また、例えば、ブロックは、ブロックが保護を必要とするか否かを示す暗号化要否情報を含み、前記暗号化要否情報に基づいて、前記ブロックを前記暗号手段に出力するか、そのままキャッシュ又はメモリ領域に出力するか判定する保護ブロック選択手段を、更に備えることとしてもよい。
また、ブロックごとにブロックを選択する保護ブロック選択手段の付加を低減するために、以下のようにしてもよい。
例えば、第１のプログラムの実行ファイルのヘッダは、前記第１のプログラムを構成するブロックの構成を示す暗号化ブロックビットマップを含み、保護ブロック選択手段は、前記暗号化ブロックビットマップに基づいて、前記ブロックを前記暗号手段に出力するか、そのままキャッシュ又はメモリ領域に出力するか判定する。
また、例えば、第１のプログラムのコードの先頭は、前記第１のプログラムを構成する複数のブロックが、平文ブロックと暗号化ブロックの組合せの繰り返しであり、前記組合せにおいて平文ブロックが連続する数及び暗号化ブロックが連続する数を指定するコードであり、
プロセッサコアこのコードを実行することにより、前記ブロックを前記暗号手段に出力するか、そのままキャッシュ又はメモリ領域に出力するか判定する。
また、上記中央演算装置において、前記キャッシュとメモリの間に、前記暗号手段を介するキャッシュラインと、前記暗号手段を介さないキャッシュラインと、を更に備えることとしてもよい。これにより、処理の高速化を図る事ができる。
また、本ＣＰＵ及びその応用システムの他の態様として、中央演算装置に保護プログラムを実行する許諾を与える制御を行わせるプログラムであって、前記保護プログラムは、コード暗号鍵によって暗号化され、保護プログラムに対応して、前記コード暗号鍵を含み、且つ、前記中央演算装置に秘密裏に備えられた秘密鍵と対になる公開鍵によって暗号化されたライセンスが存在し、前記中央演算装置が前記保護プログラムを実行する前に、前記ライセンスを前記中央演算装置に投入し、前記中央演算装置に備えられた暗号手段に、前記秘密鍵を用いて前記ライセンスを復号することにより、前記ライセンスから前記コード暗号鍵を取得させ、前記暗号手段に、前記コード暗号鍵を用いて前記保護プログラムを復号させる、ことを含む処理を前記中央演算処理装置に実行させる、ように構成する。
このプログラムは、上記構成を有する中央演算装置によって行われる処理と同様の作用・効果を得ることができるものである。従って、このプログラムによっても、上記問題を解決する事ができる。また、上記プログラムを記録する記録装置も、上記プログラムを上記中央演算装置によって実行されることにより、上記構成を有する中央演算装置によって行われる処理と同様の作用・効果を得ることができるものである。
また、上記中央演算装置を構成する各手段によって行われる動作を手順として含むソフトウェア実行許諾方法も、上記構成を有する中央演算装置によって行われる処理と同様の作用・効果を得ることができるものである。
また、本ＣＰＵ及びその応用システムの更なる１態様によれば、コンピュータにおいて実行されるプログラムであって、コード暗号鍵によって暗号化されたプログラムと、前記保護プログラムに対応して、前記コード暗号鍵を含み、且つ、前記プログラムを実行するべきコンピュータに備えられた中央演算装置が秘密裏に備える秘密鍵と対になる公開鍵によって暗号化されたライセンスが存在し、前記ライセンスは、前記プログラムが実行される前に前記中央演算装置に投入され、前記中央演算装置によって前記秘密鍵を用いて復号され、前記プログラムは、前記ライセンスから取得された前記コード暗号鍵を用いて、前記中央演算装置によって復号される、ことを特徴とする。このプログラムは、上記中央演算装置によって保護されるソフトウェアであり、上記中央演算処理装置を有するコンピュータによって実行される事によって、ハードウェアＴＲＭ並みの安全性を得ることができる。
また、上記プログラムを記録する、前記コンピュータによって読み取り可能な記録媒体もまた、その記録媒体からプログラムをロードし、プログラムを上記中央演算処理装置を有するコンピュータによって実行される事によって、上記プログラムと同様の作用・効果を得ることができる。
また、本ＣＰＵ及びその応用システムの更なる別の態様によれば、上記構成を有する中央演算装置を備えるコンピュータにおいて実行されるプログラムを生成するプログラム生成装置であって、コードオブジェクトを入力する入力手段と、入力された前記コードオブジェクトを複数のブロックに分割し、それぞれのブロックにＮＯＰ命令を追加するリンカ前処理手段と、アドレス解決を行うリンカ手段と、コード暗号鍵を用いて各ブロックを暗号化することにより保護コード実行形式を生成する保護コード実行形式生成手段と、前記コード暗号鍵を含み、前記秘密鍵と対になる公開鍵によって暗号化されたライセンスを生成するライセンス生成手段とを備え、前記ライセンスは、前記コンピュータが前記保護コード実行形式を実行する前に前記中央演算装置に投入され、前記暗号手段によって前記秘密鍵を用いて復号され、前記保護コード実行形式は、前記ライセンスから取得された前記コード暗号鍵を用いて、前記暗号手段によって復号される、ことを特徴とする。
このプログラム生成装置によって、上記中央演算装置によって保護を受けることができない形式のコードモジュールから、上記中央演算装置によって保護を受けることが可能なプログラムを生成することが可能となる。生成されたプログラムは、上記中央演算処理装置を有するコンピュータによって実行される事によって、ハードウェアＴＲＭ並みの安全性を得ることができる。
本ＣＰＵ及びその応用システムによれば、ソフトウェアＴＲＭ並みの汎用性を持ちつつも、ハードウェアＴＲＭ並みの安全性を有するＴＲＭを提供することができる。
本発明の実施形態について図面を参照しながら説明する。なお、同じ装置等には同じ参照番号をつけ、説明を省略する。
本発明は、ＣＰＵに汎用ＴＲＭ機能を実装する事により、ＣＰＵを、汎用性を有する攻撃対抗容器とする。以下の説明において、本発明に係わる汎用ＴＲＭ機能を実装するＣＰＵを「Generic TRM」といい、ＧＴと略称する。
＜構成＞
ＧＴの構成について説明する前に、ＧＴと、そのＧＴによって実行されるソフトウェアの利用関係について説明する。図１に、ＧＴを実現するＣＰＵパッケージとそのＣＰＵパッケージによって実行されるＧＴ基本パッケージソフトウェアの利用関係モデルを示す。
図１に示すように、ＧＴ基本パッケージソフトウェアは、アプリケーション層、ＤＲＭ層、ＰＫＩライブラリ層に分けることができる。アプリケーション層には、保護されるアプリケーション（以下、保護アプリケーションという）が含まれる。ＤＲＭ層には、デコーダＤＲＭ３０及びメディアＤＲＭ４０が含まれる。ＰＫＩライブラリ層には、ＰＫＩライブラリ２０が含まれる。デコーダＤＲＭ３０、メディアＤＲＭ４０及びＰＫＩライブラリ２０は、ＯＳ（Operation System）の一部である。
各基本ソフトウェアパッケージはそれぞれ次のような機能を持つ。なお、これらの機能は、従来から知られているため説明は省略する。
ＰＫＩライブラリ：
・標準のPKIX (Public Key Infrastructure (X.509))ライブラリ
メディアＤＲＭ (Virtual Media DRM, Trusted Server DRMを含む)：
・ライセンス生成・管理・削除・移動・複製の制御
・保護コンテンツ管理
・UDAC-MB/LB/PI認証・ライセンス管理機能
・ライセンス変換機能：MB（Media Base）、PI（Protocol Independent）、GT間での変換など
デコーダＤＲＭ：
・メディアＤＲＭからのライセンス取得
・許諾ライセンス復号とコンテンツ復号鍵の維持
・コンテンツの復号、汎用利用制御とアプリケーションへの安全な転送
・利用制御機能拡張機能
図１に示すように、各ＤＲＭ３０及び４０は、ソフトウェアとして実現され、ハードウェアとして実現されるのではない。また、ＧＴ１０はＣＰＵとして実現される。ＧＴ１０（ＣＰＵ）は、ＤＲＭ３０及び４０、ＰＫＩライブラリ２０及び保護アプリケーション５０を実行する。
図２に、図１に示す基本パッケージ以外のモジュールを含めたＧＴ上でのプログラミングモデルを示す。
図２に示すように、ＯＳには、上述のＰＫＩライブラリ２０、デコーダＤＲＭ３０及びメディアＤＲＭ４０に加えて、ＯＳカーネル６０及びデバイスドライバ７０を備える。デバイスドライバ７０は、周辺ハードウェア６０を動作させるために必要なソフトウェアである。
保護アプリケーション５０及び保護されないアプリケーションを含む複数のアプリケーションは、このＯＳ上で動作する。つまり、ＧＴ１０上では、ＤＲＭ機能を用いた保護アプリケーションとともに、従来のＣＰＵ上で稼動する他のアプリケーションも稼動する。このように、ＧＴ１０は、一般の保護の必要がないアプリケーションを保護アプリケーションと同時に実行することが可能な汎用性を有する耐攻撃容器である。
なお、ＯＳカーネル６０は、従来の動作に加え、ＧＴ１０において、メモリ管理及びコンテキストの切り替え制御の際に、レジスタ封印等のＧＴ１０に固有の処理（後述)を行う。しかし、それらの処理をＯＳカーネル６０に行わせることは、ＧＴ１０のセキュリティに影響を及ぼさない。すなわち、ＯＳカーネル６０にセキュリティホールが存在している場合であっても、ＧＴ１０による保護の安全性には影響はない。
デコーダＤＲＭ３０、メディアＤＲＭ４０及びこれらのＤＲＭが用いるＰＫＩライブラリ２０内の暗号・復号ライブラリ、更には、ＴＲＭ化が必要なアプリケーションは、ＧＴ１０上で保護されるＧＴ保護コードとして流通し、実行される必要がある。そして、これらのソフトウェアモジュールは、ほぼ全文を暗文にされる必要がある。
上述のように、従来、ソフトウェアＴＲＭには、拡張性はあるが容易に破壊できるという性質があった。しかし、本発明によれば、ＧＴ１０によって保護されるＤＲＭソフトウェアモジュールを採用する事により、ＤＲＭソフトウェアモジュールにハードウェアＴＲＭ並みの強度を与える事を可能としている。一方で、ハードウェアＴＲＭには拡張性が無く、リソースも限られるという問題があったが、ＧＴ１０によれば、ＤＲＭソフトウェアを採用しているため、機能的な拡張には、ＧＴ１０を搭載するＣＰＵに変更を加える必要は無く、ＤＲＭソフトウェアのバージョンアップによって対応する事が可能である。
ＤＲＭ構築モデルは、ＵＤＡＣ−ＭＢ (Universal Distribution with Access Control-Media Base)ＵＤＡＣ−ＬＡ、ＵＤＡＣ−ＰＩそれぞれのアーキテクチャ及び仕様に従うこととしてもよい。
以下、図３を用いて、第１実施形態に係わるＧＴを実現するＣＰＵの構成について、データのやり取りについて言及しながら説明する。
図３に、平文又は暗文のみからなるコードブロック或いはデータブロックを想定した場合の（ebim=0, 1のみをサポートする場合）、ＧＴ内部の回路ブロックの構成と回路ブロック間のデータ交換モデルを示す。
ＧＴ１０は、プロセッサコア１１、命令キャッシュ１２、データキャッシュ１３、命令ＭＭＵ（Memory Management Unit）１４、データＭＭＵ１５、暗号エンジン１６を備え、ＲＡＭ（Random Access Memory）１７に接続されている。
本発明に係わるＧＴ１０の特徴の１つとして、コードブロック又はデータブロックを暗号化したり、復号したりする暗号エンジン１６を備え、この暗号エンジン１６を用いて暗号化されたコードブロックやデータブロックを復号してからＧＴ１０内部のキャッシュ１２又は１３に保持し、データキャッシュ１２からＲＡＭ１７に作業データを出力する際には、暗号エンジン１６を用いてそのデータを暗号化してから出力することがある。以下、ＧＴ１０におけるブロック間のデータ交換について説明する。
まず、ＲＡＭ１７から入力されたコードブロックは、プロセッサコア１１及び命令ＭＭＵ１４によって保護すべきコードブロック（以下、保護コードブロックという）又は平文コードブロックのいずれであるか識別される。ＲＡＭ１７から入力されたデータブロックは、プロセッサコア１１及びデータＭＭＵ１５によって保護すべきデータブロック（以下、保護データブロックという）又は平文データブロックのいずれであるか識別される。
保護コードブロック及び保護データブロックは暗号エンジン１６に送信されるよう、それぞれ命令ＭＭＵ１４及びデータＭＭＵ１５からＲＡＭ１７に対して保護ブロック転送先のアドレスの指定がされる。暗号エンジン１６に出力されたコードブロックやデータブロックは復号されて、それぞれ命令キャッシュ１２やデータキャッシュ１３に出力される。保護コードブロックを復号する際に用いられる鍵Kc及び保護データブロックを復号する際に用いられる鍵Kdは、プロセッサコア１１から暗号エンジン１６に出力される。平文コードブロック又は平文データブロックは、そのまま、それぞれ命令キャッシュ１４又はデータキャッシュ１５に出力される。
また、保護コードブロック及び保護データブロックの安全性を確保するために、ＧＴ１０によれば、作業データをデータキャッシュ１３からＲＡＭ１７に出力する際に、データキャッシュ１３の出口において作業データを暗号化する。そのために、まず、データキャッシュ１３から作業データが暗号エンジン１６に出力されるとともに、プロセッサコア１１から作業データを暗号化するための鍵Kd（保護データブロックを復号する際に用いる鍵と同じ）が暗号エンジン１６に出力される。暗号エンジン１６は、その鍵Kdを用いてその作業データを暗号化し、暗号化された作業データをＲＡＭ１７等に設けられた仮想メモリ領域に出力する。さらに、暗号化する際に、データブロックに乱数を付加することとしても良い。
なお、データブロックを仮想メモリ領域に出力する際には、そのデータブロックが保護されるべきデータブロックであるか否か、ＴＬＢ（Translation Look aside Buffer）（不図示、後述）に基づいてプロセッサコア１１によって判断され、判断結果に基づいて、データキャッシュ機能からのアドレス指定の際に暗号エンジン１６を通すかどうかが決定される。また、暗号化及び暗号の復号に用いる鍵Kc及びKdは、ＧＴ１０内の暗号エンジン１６がＧＴライセンスを復号することによって得られ、耐攻撃バッファ（以下、ＴＲＢ：Tamper Resistant Bufferという）（不図示、後述）に格納されている。
命令ＭＭＵ１４とデータＭＭＵ１５は、図３において、別々のブロックとして示されているが、一つのモジュールにしてもよい。命令キャッシュ１２とデータキャッシュ１３についても同様である。
上記のように、ＧＴ１０によれば、キャッシュの出入り口で暗号化されたコードブロックやデータブロックをキャッシュ単位で復号する。ところで、ＣＰＵ内でコードを１つずつ暗号化する場合、２バイト程度の単位で行う必要がある。しかし、十分な強度を得るためには現在の技術では８バイト程度を暗号化ブロックとすることが要求されるため、２バイト程度の単位では十分な強度が維持できない。しかし、ＧＴ１０によれば、ＲＡＭ１７からの暗号化されたコードブロックやデータブロックを復号する際にはキャッシュ単位で復号して維持する事により、保護コードブロック及び保護データブロックを安全に守る事が可能となる。
なお、ＧＴ１０に命令キャッシュ１２が備えられない場合、ＧＴ１０内にＲＡＭ領域を設け、全ての実行コードを内部で復号して内部のＲＡＭ領域に保存してから実行することとしてもよい。これにより、上記構成と同等の安全性を確保する事ができる。また、ＧＴ１０にデータキャッシュ１３が備えられない場合、ＧＴ１０の内部にＲＡＭ領域を設け、保護が必要な作業データをＧＴ１０の内部のＲＡＭ領域に記録する。これにより、上記構成と同等の安全性を確保する事ができる。
また、従来、ＣＰＵ内の作業データを一時的にＲＡＭに出力する際に、秘密にすべきデータが漏洩することがあった。また、そのデータの内容を監視することによって命令コードの推測を行うことによって、ＣＰＵ内に保持されている秘密鍵を推測することも可能であった。しかし、ＧＴ１０によれば、データキャッシュから作業データをＲＡＭに出力する際に暗号化し、キャッシュに復活させる時にそのデータを復号する事としているため、このような問題を回避する事が可能となる。
なお、キャッシュ１２及び１３とＲＡＭ１７の間に、平文のコードブロック用のキャッシュライン、平文のデータブロック用のキャッシュライン、保護コードブロックを復号するためのキャッシュライン、保護データブロックを暗号化するためのキャッシュライン及び、保護データブロックを復号するためのキャッシュラインのように、複数のキャッシュライン並列に備える事としても良い。これにより、ＧＴ１０による処理を高速化し、保護コードブロック及び保護データブロックの安全性を高めることが可能となる。
また、図３に示すように、プロセッサコア１１内には、レジスタが備えられる。 ＧＴ１０によれば、従来の仮想メモリ領域に、耐攻撃領域という機構を追加し、この耐攻撃領域内では、安全上のリスクが互いに影響することなく、複数の保護ソフトウェアを実行する事を可能としている。そのために、プロセッサコア１１は、耐攻撃セグメントセレクタ（以下、ＴＲＳＳという）フラグ、レジスタアクセスコントロールテーブル(以下、ＲＡＣＴという）及びレジスタ封印状態リストレジスタ（以下、ＲＳＳＬレジスタという）を備える(不図示）。
ＴＲＳＳフラグは、仮想メモリ領域内のセグメントを指定するセグメント指定レジスタ内のフィールドに記録される。プロセッサコア１１は、ＴＲＳＳフラグに基づいて、レジスタによって示される仮想アドレスが、耐攻撃セグメント空間内であるのか、一般の仮想セグメント空間内であるのかを判断する事ができる。また、複数の保護ソフトウェアを実行する際に、現在実行中のプロセス以外のプロセスからレジスタにアクセスすることができないように、プロセッサコア１１は、ＲＡＣＴを用いて、レジスタの封印及び解放を制御する。また、さらに、レジスタが封印されているのか解放されているのかを示す情報は、ＲＳＳＬレジスタに登録される。耐攻撃セグメント空間及び耐攻撃領域並びにレジスタの封印及び解放について詳しくは後述する。
このように、ＧＴ１０は、ＴＲＭ化した１ロットのＣＰＵを用いて実現される。そして、ＧＴ１０は、ＧＴ１０上で動作する、ＤＲＭソフトウェアモジュール又はその他の保護を要するモジュールをＴＲＭ化することができる。従って、ハードウェアＴＲＭを製造するコスト、特に初期ロットの開発コストを削減する事が可能となる。
以下、ＴＲＢ、ＴＬＢ、ＴＲＳＳレジスタ、ＲＡＣＴ及びＲＳＳＬレジスタについて順に説明する。
ＴＲＢは、プログラムコード（インストラクションの連結）を復号するための鍵Kc及びデータを暗号化／復号化する鍵Kd等を保持する。なお、Kd及びKcを合わせてソフトウェア暗号鍵という事もある。ＴＲＢは、カーネルモードであってもユーザが内部を参照・改ざんすることができない構造、すなわち耐攻撃構造をもつ。ＴＲＢ内でKcやKdを保持する位置の識別はKey IDによって行われ、ＴＬＢ内にもリンクした鍵の位置を識別するKey IDを持つ。このKey IDを用いて、ＴＲＢとＴＬＢをリンクさせる。
図４に、ＴＲＢ内の各行のフィールドの構成表を示す。図４の表に示すように、ＴＲＢ内の各行は、有効性フラグp、外部出力禁止フラグuo、キャッシュロックフラグcl、鍵識別情報ｋid、暗号鍵key、被許諾コード鍵ackey及び例外処理アドレスeadr等のフィールドを含む。また、これらのフィールドのサイズは、例としてあげたものであり、ＧＴ１０のアーキテクチャや用途によって他の最適な値にすることが可能である。
有効性フラグpは、ＴＲＢが有効であるか無効であるかを示すフラグであり、オン（１）である場合、ＴＲＢが有効であることを示す。
外部出力禁止フラグuoは、その行の内容を暗号化キーテーブルに出力しても良いか否かを示すフラグであり、オン（１）である場合、暗号化キーテーブルに出力されない。但し、この場合でも、管理情報として必要なp、uo、cl及びkidは、出力可能としてもよい。外部出力禁止フラグuoのデフォルト値は、オフ（０）であり、その場合はその行の内容は暗号化キーテーブルに出力される。この場合、ＴＲＢ内の内容と暗号化キーテーブル内の内容とを同期させる必要がある。なお、暗号化キーテーブルは、ＧＴ１０内のＴＲＢの内容を格納する格納手段である。暗号化キーテーブルについて詳しくは後述する。
キャッシュロックフラグclは、鍵識別情報kidによって指定された耐攻撃領域内のデータがキャッシュの外に出力されるか否かを示し、オン（１）である場合、そのデータ又はコードはキャッシュの外に出力されない。なお、clがオン(１)である場合、次の２つのモードを切り替える機能を更にＧＴ１０に備える事としても良い。
（ａ）CPU内蔵キャッシュまでしか保護データを出さないモード
（ｂ）外部（三次）キャッシュまで保護データを平文で記録するモード
（ａ）は保護データを記録する領域を少なくし、暗号・復号処理をしないことで処理性能を上げる必要がある場合にも利用することができる。（ｂ）は処理性能向上を期待できるが、保護強度のレベルは落ちることとなる。
鍵識別情報ｋidは、鍵を識別する情報であり、ＴＬＢとＴＲＢをリンクさせるために用いられる。
暗号鍵keyは、そのラインにリンクするページに書き込まれたコード又はデータを暗号化・復号するための暗号・復号鍵の値である。暗号鍵は、例えば、対称鍵（共通鍵）暗号法の鍵である。このフィールドにKcやKdが記録される。
被許諾コード鍵ackeyは、リンクするページにアクセス可能な保護プロセスの実行コードを復号するための復号鍵である。ここで、保護プロセスとは、保護コードが実行された状態をいう。その実行コードのページは、ＴＲＢ内の行の鍵識別情報kidと同じkidを含むＴＬＢ中の行で、ページ番号を用いて指定され、そのページへのアクセス権の種類もＴＬＢ中の行で指定される。通常、被許諾コード鍵ackeyは、他の行及び自行の暗号鍵keyである。ただし、ackeyの全ビットが’0’であれば、すべてのプロセスが、ＧＴライセンスを用いてアクセス権を許諾されたことを示すものとする。また、ACgt.ackey（ACgtのackeyフィールド(後述）の値）にackeyを公開鍵KPgt（後述）で暗号化された値が入っている場合（つまり、ACgt.aefがonの場合）には、これを復号した結果がTRB.ackeyに入る。
例外処理アドレスeadrは、keyが異なるページからこのＴＲＢ内の行にリンクしたページに復帰する直前に発生する例外処理コードの先頭アドレスを示す。
例外処理アドレス(eadr)は、ACgt.eadr（ACgt内のeadrフィールドの値）が含まれないAUTHORIZE命令によりTRB内に行が設定された時点では、デフォルト値として全ビットに'0'が設定される。保護プロセスへの復帰時等に、「耐攻撃コード復帰例外アドレス不正例外」が発生した際には、そのプロセスの実行を停止し、当該TRBの有効性フラグ(p)をoffにしなければならない。なお、将来、データページごとにアクセス例外を設ける必要がある場合には、TRB.eadr（ＴＲＢ内のeadrフィールドの値）は、TRB.ackey（TRB内のackeyフィールドの値）で暗号化されたコードの実行時に実行する例外処理コードのアドレスとして定義することもできる。
鍵keyフィールドに格納されるコード復号鍵Kc及びデータ暗号化・復号鍵Kdは、例えば、乱数として生成する対称鍵暗号方式の暗号鍵であり、ＧＴ１０において、暗号・復号の前と後でデータ長が同じになる暗号方式を選択することとしてもよい。鍵を乱数生成アルコリズムを用いて生成しても良いし、ＧＴ１０内の熱乱数発生機能などを用いて生成してもよい。前者の生成法より後者の生成法の方が安全である場合が多い。Kc及びKdは、後述のＧＴライセンスに含まれる。コード復号鍵Kc又はデータ復号鍵Kdと、アクセス権等を埋め込んだＧＴライセンスをパラメタとしてＣＰＵインストラクション「アクセス許諾命令（AUTHORIZE命令）」（後述）を実行する事により、耐攻撃領域内のＴＬＢ（後述）にリンクされたＴＲＢ行内の各フィールドに値が設定される。
ＴＬＢは、保護コード及び保護データを格納するアドレス並びにページへのアクセス権を管理する。図５に、ＴＬＢ内の各行の拡張フィールドの構成表を示す。図５に示すように、ＧＴ１０に係わるＴＬＢ内の各行は、従来のＴＬＢが持つフィールドに加え、有効性フラグp、領域識別子id、物理ページ番号ppn、仮想ページ番号vpn、アクセス権限rights、鍵識別情報kid、暗号化ブロック識別方式ebim及びデジタル署名sign等のフィールドを含む。なお、アクセス権限rightsフィールドは、権限レベルpl、アクセス権ar、耐攻撃性フラグtr、デバッグモードフラグdfに分けられる。これらのすべてのフィールドはＧＴ１０内ではこの耐攻撃領域内になければならない。また、図５において示されたフィールドのサイズは、例としてあげたものであり、ＧＴ１０のアーキテクチャや用途によって他の最適な値にすることが可能である。
有効性フラグpは、ＴＬＢが有効であることを示す。
領域識別子idは、ＴＬＢ内の当該行が示すページ領域の識別子である。
物理ページ番号ppnは、物理ページ番号を示す。仮想ページ番号vpnは、仮想ページ番号を示す。
アクセス権限rightsは、その当該行が示すページへのアクセス権限を示す。
権限レベルplはページにアクセス可能な権限のレベルを示し、アクセス権arは、ページへのアクセス権の種類を示す。権限レベルpl及びアクセス権arは、図６及び図７に示すようにしてＴＬＢの各フィールドの値に基づいて決定され、ＴＬＢに設定される。なお、図６は、ＦＲアーキテクチャの場合を示し、図７は、インテルアーキテクチャの場合を示す。
耐攻撃性フラグtrは、当該行が示すページが耐攻撃セグメント空間内（後述）内にあるか否かを示し、耐攻撃性フラグtrがオン（１）であれば、そのページは耐攻撃セグメント空間内にあり、その行に対応する行がＴＲＢ内にあることを示す。耐攻撃性フラグのオン・オフはＧＴ１０の認証時に行われる。
デバッグモードフラグdfは、デバッグモードが有効であるのか無効であるのを示す。デバッグモードフラグdfがオン（１）であれば、有効である。耐攻撃性フラグtrとデバッグモードフラグdfがオン（１）である場合、アクセス権arで指定された値に応じたデバッグモードが動作し、各arの値の意味は以下のようになる。
(a)ＰＲの場合、全プロセスから読み出しのみ可能：Ｒ
(b)Ｘの場合、全プロセスからの読み出しと実行が可能：ＲＸ
(c)ＰＲＷの場合、全プロセスからの読み出しと書き込みが可能：ＲＷ
(d)ＰＷＸの場合、全プロセスからの読み書きと実行が可能：ＲＷＸ
鍵識別情報kidは、ＴＲＢ内の鍵情報にリンクするためにＴＲＢ内の行（insertion）を識別する情報である。
暗号化ブロック識別方式ebimは、暗号化されているコードブロック又はデータブロックを識別する情報である。
ａ）ebim＝０の場合、ブロックは平文である。
ｂ）ebim＝１の場合、ブロックは暗文である。（デフォルト値であり、ebimフィールドが省略されている場合、ebim＝１として扱われる）
デジタル署名signは、上述のvpnからebimまでのフィールドを連結したフィールド連結データのデジタル署名であり、ＧＴ１０が生成する。
保護コード及び保護データが格納される領域を示すＴＬＢインサーション（行）内ラインのアクセス権限の値は、後述のTLB.trがオフの場合に限り、ＯＳが管理する。従来通り、本発明でもアクセス権限の値は３ビット程度で表現されるが、本発明によれば、さらにページが「耐攻撃領域内にあることを示すフィールドとして「耐攻撃性フラグtr」フィールドをＴＬＢに設ける。また、この耐攻撃領域を利用可能なコード実行状態を「耐攻撃モード(Tamper Resistant Mode)」と呼ぶものとする。
保護コードおよび保護データを格納するアドレスはそのページを利用する前にＴＬＢに設定される。アクセス権限rights及び暗号化ブロック識別方式ebim、被許諾コード鍵ackeyは、ＧＴライセンスに含まれるＧＴアクセス条件ACgt（後述）に基づいて、決定される。
コード復号鍵Kc又はデータ暗号・復号鍵Kdと、アクセス権とを埋め込んだＧＴライセンスをパラメタとしてＣＰＵインストラクション「アクセス許諾命令」（後述）を実行する事により、ＴＬＢ行内に、保護ページごとにKeyIDが指定され、各KeyIDに対応するＴＲＢ行内のkeyフィールドに復号鍵が設定される。
以下、ＴＲＢ及びＴＬＢが格納される場所について説明する。
ＴＲＢは、ＧＴ１０内に格納されるが、ＧＴ１０に備えられた記憶容量が一杯になる場合が想定される。この場合、ＧＴ１０内のＴＲＢの内容の少なくとも一部を暗号化し、暗号化された内容をＲＡＭ１７やハードディスク等の外部記憶装置に記録する。この外部に記録されたＴＲＢ内の行のリストを暗号化キーテーブルという。そして、ＧＴ１０は、ＴＲＢの内容を暗号化した状態で外部記憶装置内の暗号化キーテーブルに記録しながら管理し、必要な情報を暗号化キーテーブルから取り出してＧＴ１０内で復号して利用する。ＴＲＢの内容を暗号化したり復号したりする際に用いられる鍵Ktrbは、例えば、対称鍵暗号法の秘密鍵である。この暗号鍵Ktrbは、ＧＴ１０の入力電源が落ちたり、ＧＴ１０がリセットされたりした場合であっても、継続して維持されることが望ましい場合がある。
以下、図８を用いて暗号化キーテーブルの構造について説明する。図８に示すように、暗号化キーテーブルには、有効性フラグp、外部出力禁止フラグuo、鍵識別情報kid及び暗号化されたＴＲＢの内容を格納するフィールド等が含まれる。
図８に示すように、暗号化キーテーブルに記録する際、各行にヘッダとして平文のままのTRB.p（ＴＲＢ中の有効性フラグpフィールドの値）と平文のままのTRB.kid（ＴＲＢ中の鍵識別情報kidフィールドの値）を付加する。これにより、ＯＳ（スーパーバイザモード）によって暗号化キーテーブルを管理することが可能となるが、Key ID以外の暗号化されている内容は参照も改ざんもできないこととなる。ＴＲＢ内のフィールドのうち、pとkidとは平文の状態で特定レジスタなどからみえてもよい。
ＴＲＢの内容を外部記録装置に記録する際には、他の保護データブロックと同様にデータキャッシュ１３の暗号化ラインを通して行う。また、図８に示すように、ＴＲＢの各行を暗号化する際には行の先頭に乱数を付加してから暗号化しなければならない。これにより、Kc（コードの暗号鍵）を指定したソフトウェア開発者が故意にＴＲＢ中の暗号鍵keyフィールドの値を何度も入れなおして、平文と暗文のペアを大量に生成することにより、容易にＴＲＢを暗号化する暗号鍵Ktrbを解読することを防止する。
さらに、暗号化キーテーブルをＲＡＭ１７から不図示のハードディスクに記録しておき、ＧＴ１０の再起動後に再利用することとしてもよい。特にハードウェアＴＲＭレベルの強度をもつソフトウェアＤＲＭを構築するために暗号鍵Ktrbで暗号化されたままのKd（データ暗号化鍵）をハードディスクやフラッシュメモリなどに保存し管理する必要がある場合もあることから、ＴＲＢの暗号鍵Ktrbは、ＧＴ１０の電源切断後も耐攻撃領域内でＦｅＲＡＭ（Ferroelectric Random Access Memory）等の不揮発性メモリなどに維持し続けてもよい。
暗号化キーテーブルとＴＲＢの内容の同期方式にはつぎのような方式が考えられるが、本発明がそのいずれかに限定されるものではない。
（ａ）暗号化キーテーブルへのＴＲＢの内容の書き出しと暗号化キーテーブルからＴＲＢへの再取り込みは特定のレジスタへのＲＷ命令などを介して行う。
（ｂ）暗号化キーテーブルの先頭アドレスと行数を設定する（特別なインストラクションを実行する）ことにより、必要になった際にＧＴ１０が自動的にテーブルとＴＲＢの同期をとる。また、ユーザが必要な時に同期がとれるようにフラッシュインストラクションをＧＴ１０に実装する。
一方、ＴＬＢの内容は、一般のＣＰＵと同様にＧＴ１０でも、外部記憶装置にページテーブルとして記録し、ＧＴ内のＴＬＢの内容とページテーブルの内容とは同期させて管理される。そして、ＧＴ１０は、必要な情報を必要な時にページテーブルからＧＴ１０内に取り込んで利用することとしてもよい。
以下、ＴＬＢとページテーブルの間での内容の受け渡しについて説明する。ＴＬＢの内容をページテーブルに記録させる際には、TLB.tr（ＴＬＢ内のtrフィールドの値）がオンの場合、ＧＴ１０は、TLB.sign（ＴＬＢ内の署名signフィールドの値）を生成し、記録させたい内容につける。そして、ページテーブル内の内容をＧＴ内のＴＬＢに取り込む際には、ＧＴ１０は、内容に付されている署名を確認し、署名が正しくなければ、ＴＬＢ署名不正例外（後述）を発生させ、その行の有効性フラグ（TLB.p）と耐攻撃性フラグ（TLB.tr）を無効（オフ）にする。
図９に署名方式の一例を示す。図９に示すように、まず、ＧＴ１０は、TLB.vpn、TLB.rights、TLB.kid及びTLB.ebimを含むデータにＧＴ１０内の固定の乱数を連結する。続いて、連結されたデータをSHA-1でハッシュし、ＧＴ１０内の秘密鍵Ktlbを用いて暗号化する。これにより署名TLB.signを生成する。署名を付す対象となる内容が160ビットに満たない場合、例えば埋め草としての乱数フィールドをその内容に追加する事としてもよい。
以下、図１０を用いて、ＴＲＢ、ＴＬＢ、暗号化キーテーブル及びページテーブルの関係について説明する。
図１０に示すように、ＴＲＢ及びＴＬＢは、ＧＴ１０内に保持される。ＴＲＢには、鍵識別情報kid、コードブロックを復号する際に用いられるKc及びデータブロックを暗号化・復号する際に用いられるKd等が記録される。ＴＬＢには、領域識別子id、鍵識別情報kid、仮想ページ番号vpn、物理ページ番号ppn、アクセス権限rights等が格納される。領域識別子idは、コードブロックやデータブロックが格納されているＲＡＭ１７内のページに対応する。また、ＴＲＢとＴＬＢの内容は、鍵識別情報kidによって対応付けられている。
ＴＲＢの内容を暗号化キーテーブルに記録する場合、その内容に乱数を追加してから暗号鍵Ktrbを用いて暗号化する。暗号化キーテーブルの内容をＧＴ１０内に取り込む場合、暗号鍵Ktrbを用いてその内容を復号する。一方、ＴＬＢの内容をページテーブルに記録する場合、ＧＴ１０は、暗号鍵Ktlbを用いてその内容に基づく署名TLB.signを生成し、その内容に追加する。
続いて、ＧＴ１０内のキャッシュと、ＴＬＢと、ＴＲＢとの同期について説明する。上記のように、ＴＬＢやＴＲＢには、ページに記録された保護コードや保護データへのアクセス制御に関する情報が記録されている。そこで、同じ仮想アドレスをもつ２つのＴＬＢをハードウェアまたはソフトウェアで偽装することにより、保護コード又は保護データにアクセスしようとする攻撃が考え得る。このような攻撃に対処するため、ＧＴ１０において、プロセッサコア１１は、キャッシュとＴＬＢとＴＲＢの内容の同期を取りながら、アクセス制御の判断を実施することとしてもよい。より具体的には、命令キャッシュ１２内の保護コード又はデータキャッシュ１３内の保護データの内容は、ＴＬＢ行の仮想アドレス(TLB.vpn)だけでなく、そのＴＬＢ行のデジタル署名（TLB.sign）の値と仮想アドレスのペアにリンクすることとしてもよい。この場合、プロセッサコア１１は、このペアが不一致の際には異なるページとしてアクセス制御の判断をおこなう。
このように、GTライセンスにアクセス許可保護コードのコード復号鍵(Key)を被許諾コード鍵(Authorized Code Key)として埋め込んでおくことで、保護領域にアクセス可能な保護コードを指定することができる。そして、ＴＲＢのAuthorized Code Keyフィールド(ackey)で指定されたKeyをもつ仮想ページ上のコードを実行したコードからのみ保護コード及び保護データにアクセス可能とする。ただし、アクセス権がＸまたはＰＷＸ のコードを実行する場合に限り、そのページのackeyの値がすべて０であれば、すべてのコードからの実行を許諾するものとする。
ページＡのackeyとして指定された鍵に一致するkeyの値をページBが持つとき、ページＢ上の保護コードの実行状態をここではページＡ（上のコード／データ）の「オーナープロセス(Owner Process)」と呼ぶ。
なお、ＧＴにおける実行権（Ｘ）とは、TRB.ackey（ＴＲＢのackeyフィールド）に値を持つ耐攻撃ページ上の命令コードを実行する権利を意味する。この権利はその命令コードのひとつ手前で実行された命令コードに対して与えられるもので、つぎのようなケースがある。
（ａ）ひとつ手前で実行された命令のあとに現在実行すべき命令とが続いている場合。
（ｂ）ひとつ手前で実行された命令がCALLやJUMPなどの分岐命令である場合。
特に前の命令と次の命令の仮想ページが異なる場合、ＧＴ１０は、あらためて次に実行することを指定された命令コードが実行を許諾されているかどうかを確認しなければならない。この確認については後述する。
続いてＴＲＳＳフラグについて説明する。図１１に、ＴＲＳＳフラグを格納するフィールドの構成の一例を示す。ＧＴ１０はその仮想メモリ空間のセグメント指定レジスタに、ＴＲＳＳフラグを持つ。このフラグはコード・セグメント、データ・セグメント、スタック・セグメントのそれぞれに対して存在し、それぞれ耐攻撃コードセグメントセレクタ(TRCSS: Tamper Resistant Code Segment Selector)、耐攻撃データセグメントセレクタ(TRDSS: Tamper Resistant Data Segment Selector)、耐攻撃スタックセグメントセレクタ(TRSSS: Tamper Resistant Stack Segment Selector)と呼ぶ。ＴＲＳＳフラグがオンである場合、ページは耐攻撃空間内に設定され、オフである場合、ページは一般の仮想空間内に設定される。
続いて、ＲＡＣＴについて説明する。図１２に、ＲＡＣＴの各行のフィールド構成の一例を示す。ＧＴ１０によれば、レジスタの封印と解放の機能を実現するために、耐攻撃モジュール内にＲＡＣＴを備える。ＲＡＣＴの各行は、レジスタＩＤrid、封印フラグseal及び被許諾コード鍵ackey等のフィールドを含む。
レジスタＩＤridは、レジスタを指定するＩＤである。封印フラグseal、レジスタが封印中であるか否かを示し、オン（１）である場合レジスタは封印中であり、オフ（０）である場合レジスタは解放されている事を示す。非許諾コード鍵ackeyは、ＴＲＢのackeyと同様であり、レジスタへのアクセスが許可されているプロセスのコードページの鍵keyである。
続いて、ＲＳＳＬレジスタについて説明する。ＲＳＳＬレジスタは、ＧＴに必須の機能ではないが、オプション機能として備えることとしてもよい。ＲＳＳＬレジスタは、各レジスタの封印状態を示す情報を格納する。図１３にＲＳＳＬレジスタのフィールド構成の一例を示す。図１３に示すように、ＲＳＳＬレジスタは封印可能なレジスタの数と同じビット長を有し、各ビットは、そのビットに対応するレジスタの封印状態を示す。ビットがオン（１）である場合、当該レジスタが封印されていることを示し、オフ（０）である場合、当該レジスタが解放されていることを示す。例えば、ＲＳＳＬレジスタの第１ビットがレジスタｒ１の封印状態を示すように設定されている場合に、第１ビットがオンであれば、レジスタｒ１は封印されていることを意味する。
続いて、耐攻撃セグメント空間及び耐攻撃領域について説明する。上述のように、ＴＬＢ内の耐攻撃性フラグtrがオン（１）であるページは、耐攻撃セグメント空間内に含まれる耐攻撃領域である。また、このページに対応するセグメント指定レジスタ内の行において、ＴＲＳＳフラグはオンである。耐攻撃領域内のページには、保護データが格納される。図１４に、一般の仮想セグメント空間と耐攻撃セグメント空間との間でコード実行プロセスからデータにアクセスする際のポリシーを示す。一般仮想セグメント空間は、保護をする必要がないデータ及びコードが記録される空間であり、耐攻撃セグメント空間は保護データ及び保護コードが記録される空間である。
耐攻撃セグメント空間で実行されるコードから一般仮想セグメント空間内のデータにアクセスすることはできるが、一般仮想セグメント空間で実行されるプロセスから耐攻撃セグメント空間内のデータにアクセスはできない。また、ユーザレベル空間とスーパーバイザレベル空間とのアクセス制御関係は、耐攻撃セグメント空間内でもライセンスオーナーが同じであれば、一般仮想空間における場合と同じポリシーが維持される。
また、耐攻撃空間内であっても、ライセンスオーナーが異なる保護コード及び保護データの領域間では、相互にアクセスすることができない。ただし、後述の耐攻撃領域共有機能を用いることで、相互アクセスを可能にすることができる。
上述のアクセスポリシーにより、ＧＴ１０における保護プロセスは、他のプロセスからの影響を受けない。ＧＴ１０において、保護プロセスは自身が生成した耐攻撃ページを持ち、一般にＯＳによって管理される。
図１５に、ＧＴ１０上で保護プロセスが動作する様子を示す。図１５に示すように、ＧＴ１０上では、複数の保護プロセスが動作し、それぞれの保護プロセスは耐攻撃領域内にページを生成する。作業データは、ＧＴ１０内の暗号エンジン１６によって暗号化されてから耐攻撃領域（仮想メモリ領域）に格納される。従って、仮想ハードウェアＴＲＭの範囲は、ＲＡＭ１７やハードディスク等までも伸び縮みし、一定の形を持たないといえる。このため、ＧＴ１０が生成し動作する保護プロセスは「仮想ハードウェアＴＲＭ (Virtual Hardware Tamper Resistant Module :VHTRM)」内で動作しているということができる。故に、ＧＴ１０によれば、ハードウェアＴＲＭ並みの強度を持ちつつも、ハードウェアＴＲＭに伴うリソースの制限という問題を解消することが可能となる。
また、保護プロセスは、世界中のＣＰＵ（ＧＴ１０）空間を自在に移動することも可能である（後述のＧＲＩＤ計算）。このように、どのような攻撃にも耐え、自分の使命を果たして元のＧＴ１０に帰ってくるＶＨＴＲＭを纏った保護プロセスを擬人化して「耐攻撃エージェント(Tamper Resistant Agent)」と呼ぶこともできる。
＜インストラクションセット＞
次に、ＧＴ１０に与えられるインストラクションセットについて説明する。
まず、ＧＴを実装するＣＰＵが、従来のＣＰＵのインストラクションセットに加えて、ＧＴ１０としての機能を実現するために備える基本命令について説明する。基本命令には、以下の（１）から（９）がある。以下、各命令について順に説明する。
（１）ＧＴ証明書取り出し命令：Store GT certificate command
命令形式：STR_GT_CERT (certNum, certAdr)
入力レジスタ：
certNum：ＧＴ１０内でローカルに割り当てられた証明書番号。N枚の証明書があれば、0からN-1までの値が有効となる。
certAdr：証明書の内容を書き込むアドレス
出力（例外処理）：
errorCode：指定した番号の証明書がない場合などに設定される。
動作：certNumで指定された証明書をＧＴ１０内から取り出し、certAdrで指定されたアドレスに書き出す。
動作可能権限：全レベル
（２）アクセス許諾命令：Access authorization command
命令形式：AUTHORIZE (licenseAdr, resultAdr, startVPN, numOfVP, kid)
入力レジスタ：
licenseAdr：ＧＴライセンス（後述）を格納したアドレス
resultAdr：結果を格納するアドレス
startVPN：耐攻撃領域の先頭仮想ページ番号
numOfVP：連続する耐攻撃領域のページ数
kid：ＯＳがＴＬＢとＴＲＢの関係を管理するために割り当てる識別子
出力：
result：［ＧＴライセンス || startVPN || numOfVP］|| 以上の署名］がresultAdrに記録される。
errorCode（例外処理）：認証が失敗した場合などに設定される。
動作：指定レジスタのメモリ上にあるＧＴライセンスを認証し、ＧＴライセンスから取り出した耐攻撃領域のコード又はデータ復号鍵key (Kc又はKd)、kid、ackeyを耐攻撃領域内のＴＬＢにリンクするＴＲＢに設定する。さらに、ＴＬＢに「耐攻撃フラグ」(tr)とアクセス権（PR, X, PRW, PWX）、ebim、kid及びsignを設定する。正しく設定が完了すれば、入力データを連結してそのデジタル署名を付加し、resultAdrで指定されたアドレスに記録する。このとき、入力データの連結をハッシュし、結果をKgtを用いて暗号化し、その結果をデジタル署名として採用する。認証が失敗した場合やＴＬＢが存在しない場合など、設定が失敗した場合には例外を発生させる。
動作可能権限：スーパーバイザレベル（権限レベル０）のみ
（３）耐攻撃権限設定命令： Set Tamper Resistant Rights command
命令形式：SET_TR_RIGHTS (rights, startVPN, numOfVP)
入力レジスタ：
rights：アクセス権（ACgt.ar（後述）を指定）
startVPN：耐攻撃領域の先頭仮想ページ番号
numOfVP：耐攻撃領域のページ数
出力（例外処理）：
errorCode：入力に対応する行がＴＬＢ又はＴＲＢにない場合、又はすでに設定されているアクセス権よりも指定されたアクセス権の範囲が広い場合などに発生。
動作：startVP及びNnumOfVPで指定された仮想領域が耐攻撃空間である場合、その領域のＴＬＢに、rightsで指定されたアクセス権を設定する。ただし、rightsで指定されたアクセス権は、すでにＴＬＢに設定されているアクセス権の範囲でなければならない。
動作可能権限：スーパーバイザレベル（権限レベル０）のみ
（４）耐攻撃例外アドレス設定命令：Set Tamper Resistant Exception command
命令形式：SET_TR_EXCEPTION (startAdr)
入力（イミーディエイトまたは直接アドレッシングのみ）：
startAdr：ＴＲＢに設定する耐攻撃空間内の仮想アドレス。レジスタ解除・復帰例外などのジャンプ先として指定する。なお、封印したいレジスタの使用前にstartAdrを秘匿して実行する必要があることから、レジスタは入力パラメタとして利用できない。
出力（例外処理）：
errorCode：staetAdrで指定されたアドレスに対応する行がＴＲＢ内に存在しない（耐攻撃モードではない）。又はそのアドレスへのアクセス権がない。
動作：指定されたstartAdrを現在実行中のコードページのＴＲＢ.eadr（ＴＲＢ内のeadrフィールド）に設定する。
動作可能権限：全レベル
（５）レジスタ封印命令：Seal Register command
命令形式：SEAL_REG (registerList)
入力レジスタ： registerList：封印するレジスタ一覧（フラグリスト）。各レジスタに対応したフラグについて、オン（１）でレジスタを封印することを示し、オフ（０）で封印しないことを示す。
出力（例外処理）：
errorCode：指定したレジスタが存在しない。または、そのレジスタはすでに封印済である。
動作：指定したレジスタには、本命令を出したプロセス（コード実行状態）コードページの暗号鍵Kcと同じ鍵を持つコードページのプロセス以外からアクセスできなくなる。本命令の実行によって、対応するレジスタのRACT.ackey（RACTのackeyフィールド）に、本命例を実行したコードを暗号化したkeyの値を記録する。
動作可能権限：全レベル
（６）レジスタ解放命令：Release Register command
命令形式：RELEASE_REG (registerList)
入力レジスタ：
registerList：封印を解放するレジスタ一覧
出力（例外処理）：
errorCode：指定したレジスタが存在しない。または、そのレジスタは解放済である。
動作：指定した範囲のレジスタの値をすべて０にクリアし、封印を解除する。
動作可能権限：全レベル
（７）非許諾領域スタックストア命令：Store Stack to Unauthorized Area command
命令形式：STMEA_TO_UA (registerList)
入力：
registerList：スタックに記録されるレジスタの一覧。フラグのリスト。各レジスタに対応したフラグがオン（１）の場合、そのレジスタをスタックに記録することを示し、オフ（０）で記録しないことを示す。
出力（例外処理）：
errorCode：registerListで指定されたレジスタが封印されていない。
動作：スタックポインタが、許諾されていない耐攻撃領域を示す場合でも、指定されたレジスタのRACT.ackey（ＲＡＣＴ内のackeyフィールド）の値がその領域に対応するＴＲＢ.ackey（ＴＲＢ内のackeyフィールド）に一致すれば、指定されたレジスタがスタックポインタの位置に記録される。
動作可能権限：全レベル
（８）非許諾領域スタックロード命令：Load Stack from Unauthorized Area command
命令形式：LDMEA_FROM_UA (registerList)
入力：
registerList：スタックから読み出すレジスタ一覧
出力（例外処理）：
errorCode：指定レジスタが封印されている。
動作：スタックポインタが耐攻撃領域を示す場合、指定されたレジスタのRACT.ackeyにスタックポインタの領域のＴＲＢ.ackeyの値がコピーされ、指定されたレジスタのRACT.seal（ＲＡＣＴ内のsealフィールド）がオン（１）に設定される。さらに、指定されたレジスタにスタックポインタの位置のデータがロードされる。
動作可能権限：全レベル
（９）ライセンス削除命令：Delete License commnad
命令形式：DELETE_LICENSE(kid)
入力：
kid：ＯＳがＴＬＢとＴＲＢの関係を管理するために割り当てた識別子で、AUTHORIZE命令のパラメタとして用いた値。
出力（例外処理）：
errorCode：kidが誤っている場合、又は削除に失敗した場合等に設定される。
動作：指定されたkidのＴＲＢ及びそれにリンクするすべてのＴＬＢが削除され、対応するページテーブルと暗号化キーテーブルの有効性フラグもオフに設定される。また、それらのＴＬＢが示していた仮想領域のキャッシュロックも解除される。
動作可能権限：スーパーバイザレベル（権限０レベル）のみ
上述の（１）から（９）までの基本命令に加えて、性能や機能の向上のための拡張命令として、（１０）から（１５）までの命令等が考えられる。以下、順に拡張命令について説明する。
（１０）保護ブロック開始命令：Protected Block Start command
命令形式：PRT_BLOCK_START (encryption_flag)
入力（直接パラメタ）：
encryption_flag：オン（１）ならブロックが暗号化されていることを示す。
動作：
命令データの特定のビット位置が特定パターンにセットされていれば暗号化ブロック開始命令とする。本命令内の特定ビット列（７ビット程度）は暗号化ブロックの長さを指定するために用いられ、値を指定する単位は、キャッシュ可能なインストラクション長の最小値と同じとする。また指定可能な最大値はキャッシュ可能な長さの最大値と同じとする。本命令のその他のバイトには乱数を入れなければならない。本命令データの先頭の境界は命令キャッシュ単位の境界に一致しなければならない。
乱数の長さがセキュリティ上十分でない場合は、この命令を２つ以上連続する。連続した場合、最後の本命令以外はブロック長の値に０が入る。
保護コードブロック開始命令は、ＧＴ１０内で復号された後、同じ長さのNop命令となる。
TLB.ebimの第２ビットがオンの場合、ブロックに含まれるハッシュまたは署名（平文の場合）をチェックしなければならない。ハッシュまたは署名の位置は、例えばブロックの末尾とする。ブロックがハッシュや署名を含まない場合は、ハッシュ非実装例外を発生させる。
なお、この命令は、第２実施形態（後述）に対応する。
（１１）ＴＲＢ暗号鍵リフレッシュ命令：Refresh TRB Key command
命令形式：REFRESH_TRB_KEY
入出力レジスタ：なし
動作：ＴＲＢを外部に記録する際にはかならず用いる対称暗号法の暗号鍵Ktrbとページテーブルの署名確認に用いる暗号鍵Ktlbを新たな乱数値に置き換える。
この命令は、KtlbやKtrbが漏洩する可能性がある場合などに使用する。ただし、ＴＲＢを用いてライセンス情報などを暗号化して管理していた場合、この命令後は以前の暗号化情報を復号できなくなるので、注意が必要。このような場合には例えば、リフレッシュの前に別の鍵で暗号化して退避しておくなどの処理が必要になる。利用例の詳細は後述。
（１２）保護領域のキャッシュを優先する命令：
保護データの暗号・復号速度を重視する場合に利用する。
（１３）プロセス間で漏洩しない熱乱数生成命令：
（１４）内蔵暗号・復号コマンド
ＧＴ１０を実現のためにＣＰＵ内部に実装した対称鍵暗号法や公開鍵暗号法の暗号化・復号命令をインストラクションセットとしてソフトウェア開発者に見せることにより、ハードウェアリソース利用効率が高まる。
（１５）定期割り込み間隔設定コマンド
ＧＴ内蔵水晶発信機が発生する内部割込みの間隔を設定する。外部の信頼できる時計と安全に同期するセキュアクロックを耐攻撃プロセスとして実現する場合に用いることができる。
＜例外処理＞
ＧＴ１０を実現するＣＰＵは、従来の例外処理に加え、次のような例外処理を実装する。例外処理には、大きく分けて、耐攻撃ページアクセス権関連例外と、耐攻撃領域復帰関連例外と、レジスタ封印関連例外と、ハッシュ関連例外等とがある。以下、順に各例外処理について説明する。
・耐攻撃耐攻撃ページアクセス権関連例外
（１）証明書指定誤り
この例外処理は指定した番号あるいは識別情報のGT証明書（Cgt）がない場合に発生する。
（２）ＧＴライセンス認証フォールト
この例外処理はＧＴライセンスの認証に失敗した場合に発生する。
（３）耐攻撃空間ページフォールト
ＴＬＢ内の耐攻撃性フラグtrがオフ（耐攻撃モードではない）または、そのページに対応する行がＴＲＢ内に無いのに耐攻撃領域へのアクセス命令を実行しようとした。
（４）ＴＬＢ署名不一致例外
TLB.sign（ＴＬＢ内のsignフィールド）の値が、ブロックに含まれる署名と一致しない。本例外が発生した場合、ＧＴ１０は自動的に当該ＴＬＢのページテーブルからのロードを停止する。さらに、ＴＬＢ内の対応する行の有効性フラグ（TLB.p）及び耐攻撃性フラグ（TLB.tr）をオフにする。
（５）アクセス権不正拡大例外
AUTHORIZE命令で許可されたアクセス権よりも指定されたアクセス権の範囲が広い。本例外が発生した場合、ＧＴ１０は自動的にアクセス権設定命令を拒否する。
（６）暗号化キーテーブルアクセスフォールト
この例外は、ＴＲＢ中に存在しないkidその他の検索キーを指定した場合、又はTRBのページアウトに失敗した場合に発生する。
（７）ライセンス削除フォールト
この例外は、ライセンスの削除に失敗した場合に発生する。
・耐攻撃領域復帰関連例外
（８）耐攻撃コード復帰例外
:RETURN_TO_TAMPER_RESISTANT_CODE_EXCEPTION
call、jump又はreturnによって、一般の仮想領域又は耐攻撃領域からコード復号鍵Kcが異なる耐攻撃領域に実行中アドレスが移動した際には、必ず耐攻撃コード復帰例外が発生する。この例外の処理において、移動先耐攻撃領域の例外アドレスであるTRB.eadr（ＴＲＢ内のeadrフィールド）の内容が確認され、そのフィールドに例外アドレスが存在する場合、プロセッサコアは、その例外アドレスにアクセスする。例外アドレスが存在しない場合には、当該ＴＲＢ行が削除され、耐攻撃コード復帰例外アドレス不正例外が発生する。
（９）耐攻撃コード復帰例外アドレス不正例外
この例外は、耐攻撃コード復帰例外アドレスで指定された空間が、耐攻撃空間に存在しない場合に発生する。保護プロセスへの復帰時等に本例外が発生した際には、そのアドレスに対応するＴＲＢ内の行の有効性フラグ(p)をオフにし、ＯＳなどによって指定されたアドレスへ強制的にジャンプする。
・レジスタ封印関連例外
（１０）レジスタ封印済例外
この例外は、指定されたレジスタが既に同じKcを持つコードにより封印済みである場合に発生する。
（１１）レジスタ解放済例外
この例外は、指定レジスタが封印されていない場合に発生する。
（１２）封印レジスタアクセスフォールト
:SEALED_REGISTER_ACCESS_FAULT_EXCEPTION
この例外は、指定されたレジスタが既にKcが異なる他のコードによって封印済みである場合に発生する。
・ハッシュ関連例外
（１３）ハッシュ非実装例外
この例外は、ＧＴ１０がハッシュ生成機能やチェック機能を実装していない場合に発生する。
（１４）ハッシュ不一致例外
この例外は、ＧＴ１０が、保護コード又は保護データをキャッシュする際にハッシュ値の不一致が生じた場合に発生する。
＜動作＞
以下、ＧＴ１０によって行われる処理について説明する。
＜ＧＴの認証＞
まず、ＧＴ１０の認証手順について説明する。なお、以下の説明において、ＰＫＩの内容の理解を前提としている。
図１６に、ＧＴの認証を説明する図を示す。図１６に示すように、ＧＴの認証には、保護アプリケーション５０、ＤＲＭ３０及び４０、暗号モジュール（ＰＫＩライブラリ２０に含まれる）の各ソフトウェアパッケージを作成する各開発メーカー、ＧＴ１０を作成する開発メーカー、ＰＫＩライブラリモジュール用認証局CApki、ＤＲＭ用認証局CAdrm、ＤＲＭを利用するアプリケーション向け認証局CAap及びＧＴを認証する認証局CAgtが介在する。図１６において、細い矢印は、データの流れを示し、太い矢印は、ソフトウェアパッケージへのライセンス又は証明書の埋め込みを示す。また、図１６中の括弧中の数字は処理の順番を示す。また、各ＴＲＭソフトウェアは、各ＴＲＭソフトウェア開発メーカーが秘密裏に生成した対称鍵暗号方式の暗号鍵で暗号化されているものとする。
ＧＴライセンスの生成と利用は次のような各システム運用とプログラムソフトウェア実行許諾手順によって実現される。
（１）ＧＴメーカーは製品化するＧＴ１０の個別公開鍵KPgtをＧＴ専用の認証局CAgtに渡す。さらに、ＧＴメーカーは、ＧＴ１０内部には秘密鍵Kgtを埋め込む。
（２）ＧＴ専用の認証局CAgtは、ＧＴ１０の公開鍵証明書CgtをＧＴメーカーに発行する。なお、ＧＴ１０の公開鍵証明書Cgtは、クラス秘密鍵Kcgtで署名され、クラス公開鍵KPcgtは、ＧＴ専用の認証局CAgtのルート秘密鍵Kagtで署名された証明書の形で公開されていることとしてもよい。また、公開鍵証明書Cgtにおいて個別鍵とクラス鍵の双方を用いるのではなく、いずれか一方を用いることとしてもよい。クラス鍵がない場合、公開鍵証明書Cgtはルート秘密鍵Kagtで直接に署名されることとしてもよい。
（３）ＧＴメーカーは、公開鍵証明書Cgtをコピーし、ＴＲＭソフトウェア開発メーカーに配布する。
（４）各ＴＲＭソフトウェアの開発メーカーは、開発したソフトウェア実行コードを鍵Kcを用いて暗号化することにより、保護コードファイルを作成する。
（５）各ＴＲＭソフトウェアの開発メーカーは、公開証明書Cgtから取り出したＧＴ１０の公開鍵KPgtを用いて鍵Kcを暗号化し、（移動不可能な）ＧＴライセンスLxxを生成する。ＧＴライセンスの構造については後述する。
（６）各ＴＲＭソフトウェアメーカーは、ソフトウェアが実行される前にＯＳのイニシエーターがＧＴライセンスLxxをＧＴ１０に投入するように、ＧＴライセンスLxxをそのソフトウェアパッケージに埋め込む。
（７）各ソフトウェアの実行直前にそのＧＴライセンスがＧＴ１０に投入される。ＧＴ１０は、公開鍵のペアにあたる秘密鍵Kgtを用いて、ＧＴライセンスを復号する。つまり、ＧＴ１０内で各ソフトウェア開発メーカーによるＧＴ１０の認証が実行される。これにより、ＧＴ１０上でそのソフトウェアを実行することが許諾される。ＧＴで保護されるソフトウェアをフリーソフトウェア等にして流通させたい場合には、ＧＴライセンスを生成するためにクラス公開鍵KPcgtを用いる事としてもよい。また、ＧＴで保護されるソフトウェアを特定のＧＴ１０以外で使用できないようにしたい場合は、ＧＴライセンスを生成するために個別公開鍵KPgtを用いる事としてもよい。
（８）ＧＴ１０は、ＧＴライセンスから取り出した鍵Kcとアクセス権（Access rights）をＧＴ１０内のＴＲＢ及びＴＬＢに設定する。ユーザは、たとえカーネルモード（スーパーバイザレベル／リング０）でも、ＴＲＢに設定されたKcを参照することはできない。
このように、ＴＲＭソフトウェアパッケージには、ＧＴ１０に実行許諾を与えるためのＧＴライセンスが埋め込まれ、暗号化されたプログラムコードが実行される前にそのＧＴライセンスは、ＧＴ１０に投入される。ＧＴ１０は、個別秘密鍵Kgtを用いてＧＴライセンスを復号し、そのＧＴライセンスからプログラムコードの復号鍵Kcを取り出し、内部のＴＬＢにリンクしたＴＲＢに、保護コードごとにその復号鍵Kcを維持する。ＧＴ１０において、暗号化されたコードは復号鍵Kcを用いて復号されながら実行される。
ＰＫＩライブラリモジュール用認証局CApki、ＤＲＭ用認証局CAdrmとＤＲＭを利用するアプリケーション向け認証局CAapから構成されるＴＲＭソフトウェアパッケージ向け認証局は、各パッケージのソフトウェアプロセスが保護データを交換する際にデータ転送先パッケージを認証するために利用する証明書を発行する。また、これらのうちＤＲＭ用認証局はライセンス転送先ＤＲＭの認証に用いられることしてもよい。
ここで示した４種類の認証局はすべて異なる運用にすることでコンテンツ（情報）流通ビジネスのリスクが軽減することが可能となるが、そうした運用は必須ではない。なお、ＰＫＩライブラリ２０、デコーダＤＲＭ３０及びメディアＤＲＭ４０を含めて１つのＯＳとして評価し、このＯＳ製品全体に対してＧＴライセンスを生成し、また公開鍵証明書を発行することとしてもよい。
また、ＧＴライセンスを保護実行コードと同じファイルに挿入することとしてもよいが、パッケージ超流通の便を考慮すると、暗号化された実行コードと別のファイルとして管理することを推奨する。
次に、ＧＴライセンスの構造について説明する。
ライセンス生成側はライセンス許諾先ＧＴ（耐攻撃容器）の個別公開鍵KPgtの証明書Cgtを取得し、これを用いてＧＴライセンスを生成する。証明書CgtはX.509準拠の形式としてもよい。個別公開鍵KPgtの証明書Cgtはクラス鍵KPcgtで、また、クラス鍵KPcgtの証明書Ccgtは認証局CAgtのルート公開鍵KPagtで署名チェックした後、利用される。ライセンス生成側が生成するGTライセンスの形式は以下のとおりである。

LicenseID || ACgt.ar ||
E (KPgt, Ks ) || E ( Ks, Key || LicenseID || ACgt || Is ) ||
CgtID || CgtIDackey || else

ここで、各フィールドの意味は次のとおりである。
E (K, D)：データDを鍵Kで暗号化した結果
A || B：データ連結。データAとデータBが連結していることを示す。
Ks：セッション鍵（乱数）。対称鍵（共通鍵）暗号法の鍵。
Key：コード復号鍵／データ暗号化・復号鍵。Kc/Kd。
LicenseID：ライセンスシリアル番号。ライセンス生成側がライセンスごとにユニークな番号を生成する。上位にライセンス生成者のIDを入れ、中位にコンテンツのIDを入れることとしてもよい。
ACgt：ＧＴアクセス条件。ＧＴ内で強制可能なコード／データの利用条件を示し、次のフィールドを持つ。
ebim：暗号化ブロック識別方式。図５に示すTLB.ebimフィールドにコピーされる。各値の意味はＴＬＢのフィールドとして説明済みである。
aef：被許諾コード鍵暗号化フラグ(ackey encryption flag)。on(1)なら被許諾コード鍵ackeyが個別公開鍵KPgtを用いて暗号化されていることを示し、off(0)ならackeyの値がそのままACgt.ackey（ACgtのackeyフィールド）に入っていることを示す。
ackey：被許諾コード鍵。暗号鍵Kc又はKdで復号されたオブジェクトにアクセスが可能なプロセスのコードが記録されている保護ページの暗号鍵keyまたは暗号鍵keyを個別公開鍵KPgtで暗号化した値。個別公開鍵KPgtで暗号鍵keyを暗号化する場合で、GTが複数のKPgtを持つ場合には、さらにどのKPgtを用いているかを識別できる情報を付加する。なお、そのプロセスへのアクセス権の種類は、arで指定される。
eadr:例外処理アドレス。このフィールドはオプションである。keyが異なるページからこのＧＴライセンスの内容が設定されたページに復帰する直前に発生する例外処理コードの先頭アドレスである。
ar：基本アクセス権。次のような値をとる。詳細は図１７に示す。
(a) PR：ackeyで指定されたプロセスからの読み出しのみ可能
(b) X：ackeyで指定されたプロセスからの読み出しと実行が可能
(c) PRW：ackeyで指定されたプロセスからの読み出しと書き込みが可能
(d) PWX：ackeyで指定されたプロセスからの読み書きと実行が可能
uo：外部出力禁止フラグ。on(1)ならこのライセンスのキー情報を格納したＴＲＢ行は暗号化キーテーブルに出力(ページアウト）されない。このフラグのデフォルトはオフ(0)であり、外部に出力可能であることを示す。
cl:キャッシュロックフラグ。オプション機能である。このフラグがオンである場合、このＧＴライセンスで保護を指定された耐攻撃領域のデータはキャッシュの外に出ない。但し、arが書き込み権を含まない（PR又はXである）場合には、本フラグは無効となる。このフラグのデフォルト値は、オフであり、外部に出力可能である事を示す。
df：デバッグモードフラグ(Debug mode Flag)。dfがonなら、arの指定に応じた動作を示す。ＴＬＢについての説明参照。なお、ＧＴライセンス内のACgtのdfをオンにする事により、保護コードをデバッグモードで実行する事ができる。また、超流通など形態で保護コードファイルを販売する場合には、dfをオフにして販売することとしてもよい。
CgtID：KPgtのX.509証明書の識別子値。issuerとserialNumberを連結した値。
CgtIDackey：オプション。ackeyを暗号化したKPgtのX.509証明書の識別子値。issuerとserialNumberを連結した値。ACgt.aefがoffの場合には省略。また、CgtIDと同値の場合にも省略可能。
Is：その他の情報
図１７に、ＧＴライセンスに設定可能なアクセス権と被許諾権限の表を示す。耐攻撃性フラグ耐攻撃モードの際、プロセス（コード実行状態）からみた保護データ又は保護コード領域のアクセス権は、図１７の中から選択され、ＴＬＢに設定される。なお、図１７における「指定コード」とは、当該ＴＲＢ行内のKeyフィールド又はAckeyフィールドで指定された鍵で復号可能なコードをいう。
また、図１７において、「実行のみ可能」な権限がないが、ＦＲなど、「実行のみ可能」な権限と「読み出しと実行が可能」な権限の両方を指定できるＣＰＵもある。その場合の耐攻撃権限は、それぞれ、ＰＸ及びＰＲＸと表現する事ができる。同様に、「書き込みが可能」な権限についてもＰＷＸ及びＰＲＷＸの両方が指定できることとしても良い。
ＧＴライセンスは、移動不可を条件としているため、移動機能やＣＲＬ（Certificates Revocation List：証明書失効リスト）及びＬＲＬ（License Revocation List：ライセンス失効リスト）をもたない。ＣＲＬやＬＲＬを制御する必要がないため、ＧＴのＣＰＵへの実装が容易になる。ＤＲＭのＣＲＬ制御及びＬＲＬ制御はＯＳ又はアプリケーションにて行われる。これにより、高い拡張性を維持する事が可能となる。
また、上述のように、ソフトウェアＴＲＭをフリーソフトウェア等にしたい場合、ＧＴライセンスの生成にはクラス公開鍵を用いることとしても良い。また、逆に、特定のＧＴのみにソフトウェアを利用させたい場合には、ＧＴ個別鍵に対応する公開鍵を用いることとしても良い。
以下、図１８を用いて、上述のＧＴ認証処理における（８）の手順について詳しく説明する。ＧＴ認証処理において、ＧＴ１０は、アクセス許諾命令（AHTHORIZE命令）を実行することにより、ＧＴライセンスに基づいてＴＬＢ及びＴＲＢに鍵Keyやアクセス権等を設定する。
そのために、まず、ＧＴ１０は、ＧＴの公開鍵のペアにあたる秘密鍵Kgtを用いてＧＴライセンスを復号する（Ｓ１）。続いて、ＧＴ１０は、正常にＧＴライセンスを復号できたか否か判定し（Ｓ２）、正常に復号できた場合（Ｓ２:正常）、ＧＴ１０は、指定仮想領域のＴＬＢを検索する（Ｓ３）。正常に復号できなかった場合(Ｓ２：異常）、ＧＴ１０は、ＧＴライセンス認証フォールトを発生し（Ｓ１１）、Ｓ１６に進む。Ｓ１６において、ＧＴ１０は、エラー内容をresultAdrに設定し、メインフローに復帰する。
Ｓ３においてＴＬＢを検索した結果、指定仮想領域が得られた場合（Ｓ４：正常）、ＧＴ１０はＴＲＢに空きがあるか否か判定する（Ｓ５）。Ｓ３の検索の結果、指定仮想領域が得られなかった場合（Ｓ４：なし）、ＧＴ１０は、メモリが割り当てられていない旨を示す未割り当て例外を発生し（Ｓ１２）、Ｓ１６に進む。
Ｓ５においてＴＲＢの空きがあった場合（Ｓ５：あり）、ＧＴ１０は、GTライセンスに基づいて、ＴＲＢ内のuo、cl、kid、key、ackeyの各フィールドに値を設定する（Ｓ６）。Ｓ５において、ＴＲＢの空きが無かった場合（Ｓ５：なし）、ＧＴ１０は、ＴＲＢ内の一部の行を暗号化キーテーブルに出力（ページアウト）する（Ｓ１３）。ＧＴ１０は、ページアウトに成功した場合（Ｓ１４：成功）Ｓ６に進み、ページアウトに失敗した場合（Ｓ１４：失敗）、暗号化キーテーブルアクセスフォールトを発生させた後（Ｓ１５）、Ｓ１６に進む。
Ｓ６の後、ＧＴ１０は、ＴＬＢに格納する署名signを算出し（Ｓ７）、ar、tr、df、kid、ebim及びsignをＴＬＢに設定する（Ｓ８）。続いて、ＧＴ１０は、設定結果の署名を生成し（Ｓ９）、設定結果とＳ９で生成した署名とをresultAdrに設定し（Ｓ１０）、メインフローに復帰する。
＜保護コードファイルの構造＞
以下、保護コードファイルの構造について説明する。暗号化がほどこされた保護コードファイル(実行形式）は、保護コードブロックおよび平文コードブロックの繰り返し構造の先頭にヘッダを付加した構造を持つ。また、保護コードファイルを超流通に利用可能なファイルとする場合、そのファイルのヘッダには、さらに次のような情報が入る必要がある。
・コンテンツＩＤ：保護コードの暗号を解くためのコンテンツ復号鍵を持つＧＴライセンスとのリンク情報として必要である。
・コンテンツ暗号方式：保護コードの暗号化方式を特定する値として必要である。この値は復号鍵の長さを含むこととしてもよい。
図１９に、超流通ファイル形式として用いる場合の保護コード実行形式の一例を示す。図１９において、ＳＣＤＦ（超流通コンテンツ形式：Super Content Distribution Format）ファイルに、保護コード実行形式の内容が、ＳＣＤＦの要素として格納されている。
＜保護コードのロード及び実行並びに保護データの退避と維持＞
以下、図２０を用いて、保護コードのロードと実行手順、及び保護データの退避と維持について説明する。
上述のように、暗号化が施された保護コードファイルは、ヘッダ、保護コードブロック及び平文コードブロックで構成される。保護コードファイルは実行の際にＲＡＭ１７にロードされ、ＧＴ１０（ＣＰＵ）内での予測に従いブロックごとに命令キャッシュ１２にコピーされる。このうち、ヒットした命令のみがプロセッサコア１１で解釈され、実行される。図２０に示すように、コードブロックのうち、保護コードブロックは、復号キャッシュラインで復号されてから命令キャッシュ１２に記録される。
図２０では、命令キャッシュ１２とＲＡＭ１７の間に、暗号ブロックを復号して命令キャッシュ１２に書き込む復号キャッシュライン及び、平文ブロックを命令キャッシュ１２に書き込む平文キャッシュラインの２種のキャッシュラインが備えられている。このように複数のキャッシュラインを備えることにより、処理を高速化することが可能である。
また、図２０に示したように、保護コードの実行によって保護データをＲＡＭ１７に出力する際には、あらかじめ仮想メモリとして設定された耐攻撃領域に出力する。耐攻撃領域には、保護データを暗号化および復号するための対称鍵暗号法の鍵Kdが関連付けられ、その鍵Kdは秘密裏にＧＴ１０内に維持されている。鍵Kdは、コード復号鍵Kcごとに異なる乱数として割り当てられる。保護データは一旦ＧＴ１０（ＣＰＵ）内部のデータキャッシュ１３に記録されたのち、暗号化されてからＲＡＭ１７に出力される。また、ＲＡＭ１７上の保護データは、ＧＴ１０（ＣＰＵ）内部で復号されてデータキャッシュ１３に記録され、そのうちヒットしたものがプロセッサコア１１で利用される。
図２０では、データキャッシュ１３とＲＡＭ１７の間に、暗号ブロックを復号して命令キャッシュ１２に書き込む復号キャッシュライン、データキャッシュ１３の内容を暗号化してＲＡＭ１７内の耐攻撃領域に書き込む暗号キャッシュライン、及び、平文ブロックを命令キャッシュ１２に書き込む平文キャッシュラインの３種のキャッシュラインが備えられている。この構成によっても処理を高速化することが可能である。
なお、暗号化された保護データをＲＡＭ１７からストレージ１８内に退避させることが可能である。つまり、耐攻撃領域はＲＡＭ１７内のみならず、バス１８を介して接続されたストレージ１９内にまでも拡張することが可能である。
＜ページアクセス制御＞
以上のようにして、ＧＴ１０は、ＴＲＭプログラムコードを実行する許諾を得て、その保護コードファイルを構成するコードブロックをＲＡＭ１７にロードすると、保護コードブロックを復号して実行する。以下、保護コードを実行する際の保護コードを記録するページ（命令ページ又はコードページ）へのアクセス制御について図２１を用いて説明する。図２１において、矢印は、データの流れを示し、括弧内の数字は、処理の順番を示し、以下の説明における手順の番号に対応する。
保護コードを記録するページへのアクセス制御は次のように行われる。
（１）命令ＭＭＵ１４が、予測命令ポインタ(ip: instruction pointer)に記憶されている仮想アドレスを読み出す。
（２）命令ＭＭＵ１４は、仮想アドレスに対応する物理ページ番号ppnと耐攻撃フラグtr と耐攻撃モードのアクセス権arをＴＬＢから読み取る。
（３）耐攻撃フラグがonの場合、命令ＭＭＵ１４は、ＴＲＢからコード復号鍵(Kc)を取り出す。
（４）命令ＭＭＵ１４は、暗号エンジン１６にKcを設定する。
（５）命令ＭＭＵ１４は、キャッシュすべき保護コードブロックのアドレスを命令キャッシュ１２とＲＡＭ１７に指定する。
（６）ＲＡＭ１７から保護コードブロックを暗号エンジン１６に投入する。
（７）暗号エンジン１６で復号された保護コードブロックは、命令キャッシュ１２に記録される。
（８）命令ポインタが記憶する仮想アドレスが予測命令ポインタに一致した場合（つまりキャッシュヒットした場合）、プロセッサコア１１はip用レジスタからＴＲＳＳフラグを読み出し、次の手順に進む。一方、キャッシュヒットしなかった場合、上述の(２)の手順に戻る。
（９）プロセッサコア１１は、ip用レジスタから仮想アドレスを読み出す。
（１０）プロセッサコア１１は、命令ＭＭＵ１４からアクセス権arを取り出し、アクセス権を確認する。
（１１）プロセッサコア１１は、仮想アドレスの内容が記録された命令キャッシュ１２内から保護コードブロックを読み出して実行する。
なお、手順（１０）において、実行する命令を記録する命令ページが切り替わった時には、プロセッサコア１１は、手順（１１）で保護コードブロックの読み出しを行う前に、以下を確認する。
（ａ）次に実行する保護コードブロックが記録されているページの暗号鍵(TRB.key)または被許諾コード鍵 (TRB.ackey)が、直前に実行したコードブロックが記録されているページの暗号鍵(TRB.key)と一致すること
（ｂ）次に実行する保護コードブロックについてのTLB.arに記録されたアクセス条件と、次に実行するアクセスとが合致すること
（ａ）及び（ｂ）の少なくともいずれかが不一致の場合には、プロセッサコア１１は命令の実行を停止し、アクセス権例外を発生させる。
次に、保護データブロックが記録されているページへのアクセス制御について説明する。保護データブロックへのアクセス制御は、ＧＴライセンスの内容がTRB及びTLBに設定されることによって強制される。保護データブロックへのアクセスはTRB及びTLBに維持されている被許諾コード鍵ackey、暗号・復号鍵Kd、アクセス権arに従って制御される。
上述の保護コードブロックの場合のアクセス制御手順と、実行中の保護プロセスによる保護データブロックへのアクセス制御手順は、同様である。また、上記の手順（１０）において、実行する命令を記録するページが切り替わったとき、及びアクセスされる保護データを記録するページが切り替わったときには、保護データへのアクセスを実行する前に、プロセッサコア１１は、次の点を確認する。
（ａ）アクセスされる保護データを記録するページの暗号鍵(TRB.key)または被許諾コード鍵 (TRB.ackey)が実行コードを記録するページの暗号鍵(TRB.key)と一致すること
（ｂ）アクセスされる保護データを記録するページのアクセス権（TLB.ar）と、次に実行するアクセスとが合致すること
（ａ）及び（ｂ）の少なくともいずれかが不一致の場合には、プロセッサコア１１は、保護データへのアクセスを中止し、アクセス権例外を発生させる。
以下、図２２を用いてプロセッサコア１１によって行われる上述の保護コード及び保護データへのアクセス制御について、より詳しく説明する。
まず、プロセッサコア１１は、例外／割り込みイベントの発生を待つ（Ｓ２１）。例外／割り込みイベントが発生すると、プロセッサコア１１は、例外・割り込み処理を行い（Ｓ３５）、Ｓ２１に戻る。なお、例外・割り込み処理について詳しくは図２３に示す。図２３に示される各種例外処理については、上記＜例外処理＞において詳しく説明したため、説明を省略する。
例外／割り込みイベントが発生しない場合（Ｓ２１：なし）、プロセッサコア１１は、命令ページ切り替えが発生したか否か判定する（Ｓ２２）。
命令ページ切り替えが発生した場合（Ｓ２２：あり）、プロセッサコア１１は、命令ページへのアクセス権の有無を判断する処理を行う（Ｓ２３）。命令ページ切り替えが発生していない場合（Ｓ２２：なし）、Ｓ２８に進む。
Ｓ２３の判断処理において、プロセッサコア１１は、次に実行する保護コードブロックが記録されているページの暗号鍵(TRB.key)または被許諾コード鍵 (TRB.ackey)が、直前に実行したコードブロックが記録されているページの暗号鍵(TRB.key)と一致し、且つ、次に実行する保護コードブロックについてのTLB.arに記録されたアクセス条件によって次に実行するアクセスが許可されているか否か判定する。上記２つの条件を満たす場合、プロセッサコア１１は、次に実行するコードには、切り替わった命令ページへのアクセス権があると判断し（Ｓ２４：あり）、Ｓ２５に進む。そうでない場合（Ｓ２４：なし）、プロセッサコア１１は、ページアクセスフォールト例外をキューイングし（Ｓ２７）、Ｓ２１に戻る。
Ｓ２５において、プロセッサコア１１は、次に実行する保護コードブロックが記録されているページの暗号鍵(TRB.key)が、直前に実行したコードブロックが記録されているページの暗号鍵(TRB.key)と一致するか否か判定し、さらに、プロセッサコア１１は、そのページに対応するＴＲＢ内の行のeadrフィールドに既に値が設定されているか否か判定する。TRB.keyが一致せず、且つeadrフィールドに既に値が設定されている場合（Ｓ２５：ＹＥＳ）、プロセッサコア１１は、耐攻撃コード復帰例外をキューイングし（Ｓ２６）、Ｓ２１に戻る。TRB.keyが一致するか、又はeadrフィールドに値が設定されていない場合（Ｓ２５：ＮＯ）、Ｓ２８に進む。
Ｓ２８において、プロセッサコア１１は、命令ページから命令を読み出して、その命令を解析する。さらに、プロセッサコア１１は、現在実行されているコードが、命令の中で指定されたレジスタへのアクセス権を有するか否か確認する（Ｓ２９）。そのコードが指定されたレジスタへのアクセス権を有する場合（Ｓ２９：あり）、Ｓ３０に進む。そのコードが指定されたレジスタへのアクセス権を有しない場合（Ｓ２９：なし）、プロセッサコア１１は、封印レジスタアクセスフォールト例外をキューイングし（Ｓ３４）、Ｓ２１に戻る。
Ｓ３０において、プロセッサコア１１は、レジスタで示されたデータページが、前のデータページと切り替わっているか否か判定する。切り替わっていない場合（Ｓ３０：なし）、命令を実行し（Ｓ３３）、Ｓ２１にもどる。なお、命令実行処理について詳しくは図２４に示す。図２４に示される命令については、上記＜インストラクションセット＞において詳しく説明したため、説明を省略する。
データページが切り替わっていると判定した場合（Ｓ３０：あり）、プロセッサコア１１は、そのデータページへのアクセス権の有無を判断する処理を行う（Ｓ３１）。Ｓ３１の処理は、Ｓ２３で説明した保護コードの場合と同様であるので説明を省略する。Ｓ３１の判断の結果、プロセッサコア１１は、次に実行されるコードには、切り替わったデータページへのアクセス権があると判断する場合（Ｓ３２：あり）、Ｓ３３に進む。そうでない場合（Ｓ３２：なし）、Ｓ２７に進む。
＜保護ソフトウェアの起動＞
次に、図２５を用いて、ＧＴ１０上で保護されるソフトウェア、つまり保護コードファイルを起動する際における、ＯＳカーネル６０及びＧＴ１０の動作について説明する。図２５において、細い矢印がデータのリンクを示し、太い矢印がデータの流れを示す。また、括弧内の数字は、処理の順番を示し、以下の説明における手順の番号に対応する。
保護コードファイルを起動する手順は、以下のとおりである。
（１）ＯＳカーネル６０は、ＴＬＢを設定することにより、保護コード及び保護データをロードする領域となる仮想メモリ領域及び物理メモリ領域を確保し、仮想メモリと物理メモリ領域とをリンクさせる。
（２）ＯＳカーネル６０からのAUTHORIZE命令に基づいてＧＴ１０は、ＴＬＢにリンクするＴＲＢを設定する。
（３）ＯＳカーネル６０からのCALLなどのコードモジュール呼び出し命令に基づいて、ＧＴ１０は、ipレジスタを設定する（呼び出し先インストラクションにヒットしない場合、ＧＴ１０は該当するコードブロックを復号し、復号されたコードをキャッシュにコピーする）。
（４）ＧＴ１０は、ipで指定されたアドレスの命令を実行する権利をTLB.ar（ＴＬＢ内のarフィールド）の内容で確認する。
（５）命令を実行する権利を確認できた場合、ＧＴ１０は、ipで指定されたアドレスの命令（図ではSTR命令）を読み出し、デコードし、実行する。
＜保護データへのアクセス＞
次に、図２６を用いて、ＧＴ保護コードを実行するプロセスから保護データにアクセスするメカニズムについて説明する。この例では、保護データ領域は保護コード実行前に確保され、保護コードファイルから初期値もロードされていることを前提としている。また、ＯＳ６０からのAUTHORIZE命令をＧＴ１０が実行する事により、保護データ領域へのアクセス許諾とアクセス権設定は、既に行われているものとする。
以下、例として、命令"STR r0, [r1]"を実行する（レジスタｒ０の値が示す内容をレジスタｒ１の値が示すアドレスに書き込む命令）場合について、保護プロセスが保護データにアクセスする手順と、それに対応するＧＴ１０の動作について説明する。図２６において、矢印や括弧内の数字の意味は、図２５と同様である。
（１）保護コードは、メモリアクセス命令(STR やLDRなど)を実行する。
（２）ＧＴ１０は、アクセスするアドレスに対応するＴＬＢ内の行中のアクセス権情報TLB.ar（ＴＬＢ内のarフィールド）を確認する。
（３）保護コードは、TLB.vpn（ＴＬＢ内のvpnフィールド）に一致する仮想ページ番号を持つページのデータにアクセスする。（なお、データがキャッシュにない場合、保護コードは、その仮想ページに対応する物理ページからデータを復号してキャッシュにコピーする。）
＜保護プロセスからの保護モジュールの呼び出し＞
次に、保護プロセスから保護モジュールを呼び出す手順について説明する。保護プロセスから他の保護コードモジュール（ＤＬＬ（Dynamic Link Library）など）を起動する場合には、次の２ケースがある。
（ａ）呼び出される保護コードモジュールのコード復号鍵Kcが、そのモジュールを呼び出す保護プロセス（以下、親プロセスという）のコード復号鍵と同じケース
（ｂ）呼び出される保護コードモジュールのコード復号鍵Kcが親プロセスのコード復号鍵と異なるケース
（ｂ）の場合に、保護親プロセスから他の保護コードモジュールを呼び出す際に行う手順は図２７に示すようになる。図２７においても、矢印や括弧内の数字の内容は、図２５と同様である。なお、図２７において、保護コードモジュールはＤＬＬとなっているが、これは一例に過ぎない。
（１）親プロセスは、ＴＬＢの設定などにより、保護コードモジュールをロードするための仮想領域と、その仮想領域に対応する物理領域を確保する。
（２）親プロセスは、アクセス許諾（AUTHORIZE）命令によりＴＬＢにリンクするＴＲＢを生成してコード復号鍵Kcを設定し、ＴＬＢにアクセス条件を設定する。
（３）親プロセスは、利用している秘密情報用レジスタを、その親プロセスの保護データ領域内のスタック領域に格納する。（必要に応じ、保護データキャッシュ内のスタックデータは暗号化されて外部メモリに記録される。）
（４）親プロセスは、レジスタ解放（RELEASE_REG)命令を実行する。
（５）CALL命令などにより、親プロセスは、保護コードモジュールを呼び出す。
（６）親プロセスは、レジスタ封印(SEAL_REG)命令を実行する。
（７）呼び出しが返った場合、親プロセスは、退避したスタックをもとのレジスタに復帰させる。
図２８に、上記手順においてＯＳカーネルが行う処理のフローチャートを示す。
図２７の手順の（１）において親プロセスが、保護コードモジュールをロードするための仮想領域と、その仮想領域に対応する物理領域を確保することを要求すると、耐攻撃領域取得システムコールが呼び出される。この要求の際、親プロセスは、必要となる領域のサイズと、ＧＴライセンスをＯＳカーネル６０に通知する。このシステムコールにおいて、まず、ＯＳカーネル６０は、アプリケーションが利用しているレジスタの一覧を入力パラメタとする非許諾領域スタックストア（STMEA_TO_UA）命令をプロセッサコア１１に出力する（Ｓ９１）。このＳ９１は、図２７の手順（３）に対応する。
続いて、ＯＳカーネル６０は、アプリケーションが利用しているレジスタの一覧を入力パラメタとするレジスタ解放（RELEASE_REG）命令をプロセッサコア１１に出力する（Ｓ９２）。これにより、指定されたレジスタが解放される。このＳ９３は、図２７の手順（４）に対応する。
ＯＳカーネル６０は、ＯＳが利用しているレジスタの一覧を入力パラメタとするレジスタ封印（SEAL_REG）命令をプロセッサコア１１に出力する（Ｓ９３）。Ｓ９４において、これら命令のパラメタが正しい場合（Ｓ９４：正常）、これらの命令はプロセッサコア１１によって実行され、Ｓ９５に進む。そうでない場合（Ｓ９４：不正）、Ｓ１０３に進む。
Ｓ９５において、ＯＳカーネル６０は、親プロセッサによって指定された領域サイズのエントリをページテーブルに設定する（Ｓ９５）。指定されたサイズの領域を設定するための耐攻撃領域のリソースがあった場合（Ｓ９６：あり）、Ｓ９７に進む。耐攻撃領域のリソースが不足していた場合（Ｓ９６：不足）、Ｓ１０３に進む。
Ｓ９７において、ＯＳカーネル６０は、ＧＴライセンスと、設定したアドレス及びページ領域を入力レジスタに設定し、アクセス許諾（AUTHORIZE）命令をプロセッサコア１１に出力する。このＳ９７は、図２７の手順（２）に対応する。プロセッサコア１１が、正常に命令を実行した場合（Ｓ９９:正常）、Ｓ１００に進む。正常に命令を実行できなかった場合（Ｓ９９：例外発生）、Ｓ１０３に進む。
Ｓ１００において、ＯＳカーネル６０はアクセス許諾（AUTHORIZE）命令の結果を返却データとして設定する。この後、図２７の手順（５）が行われ、保護コードモジュールが呼び出される。続いて、ＯＳカーネル６０は、レジスタ解放（RELEASE_REG）命令をプロセッサコア１１に出力し、ＯＳが使用しているレジスタを解放させる（Ｓ１０１）。最後に、ＯＳカーネル６０は、被許諾領域スタックロード（LDMEA_FROM_UA）命令をプロセッサコア１１に出力し、スタックされていたデータをレジスタにロードさせ、通常状態に復帰する。このＳ９５は、図２７の手順（７）に対応する。
なお、パラメタの不正、リソースの不足及び例外が発生した場合、Ｓ１０３において、ＯＳカーネル６０はエラー内容を返却データとして設定し、Ｓ１０１に進む。
＜耐攻撃コードの復帰時の例外処理＞
call、jump又はreturn等の命令によって、一般の仮想領域又は耐攻撃領域からコード復号鍵Kcが異なる耐攻撃領域に実行中アドレスが移動した際には、耐攻撃コード復帰例外が発生する。この例外処理の中で、次の２つの処理を実施する必要がある。
（ａ）レジスタ封印の確認と、レジスタを解放済みの場合の封印の再設定。
（ｂ）耐攻撃セグメントセレクタの値の確認と、必要に応じた再設定。
ＧＴ１０は、保護コードのレジスタ封印の前に、解除・復帰例外の先頭アドレスをＴＲＢに設定する。また、外部からの割り込みによってレジスタが解放されたまま実行を継続することによって、レジスタに記録した秘密情報が漏洩することがないよう、保護コードは解除・復帰例外処理を含む必要がある。この解除・復帰例外処理において、ＧＴ１０は、封印したはずのレジスタが封印されているかを再度確認し、レジスタが封印されていなければ、封印しなおすか、保護コードの実行を中止するかしなければならない。
図２９に、耐攻撃コード復帰例外処理による封印レジスタ不正アクセス防止のためのシーケンス例を示す。図２９において、保護コードが不正なコードによって一時中断された後に復帰する際に、例外が発生した場合を示す。図２９において、保護コードを中断する前にレジスタ封印（SEAL_REG r1）命令が実行されているが、不正コードの実行中にレジスタ解放（RELEASE_REG r1）命令が実行されたため、復帰時に封印したはずのレジスタが封印されていない。
図２９に示す耐攻撃コード復帰例外のシーケンスの最初の３行は以下のとおりである。
TST RSSL.r1ss, r1ssBit
BNE chk_seg
SEAL_REG r1
この３行は、保護コードが利用するレジスタｒ１の封印状態をＲＳＳＬレジスタ内のレジスタｒ１に対応するビットr1ssの値を調べる事により確認し、ｒ１が封印されていない場合、ｒ１を封印しなおす処理を示す。
また、不正なコードが割り込み等によってプロセスを奪い、データやスタックのＴＲＳＳフラグをオフ（０）に設定する可能性もある。ＴＲＳＳフラグがオフになっているにもかかわらず保護コードが継続されると、耐攻撃領域ではなく一般仮想領域に保護データを書き込んでしまうことになる。このような事態を防止するために、耐攻撃コード復帰例外処理において、ip(命令ポインタ、ＣＰＵによってはPC（プログラムカウンタ）ともいう）が示す仮想アドレスごとの耐攻撃データ／スタックセグメントセレクタの再設定を行う必要がある。図２９に示す耐攻撃コード復帰例外のシーケンスにおける４行目から６行目は以下のとおりである。
ch_seg CMP ip, trSegmentHead
BMI ret
ORR trdss, trdss, trBit
この３行が、ipが示す仮想アドレスごとの耐攻撃データ／スタックセグメントセレクタの再設定を行う処理を示す。耐攻撃コード復帰例外処理が終了すると、プロセスは保護コードに復帰する。なお、図２９のシーケンスの最後において、不正なコードによって再度プロセスが中断され、不正なコードが保護コードが利用するレジスタｒ１の内容を一般仮想領域に書き込もうとしている（MOV r1, [unprotectedArea]）。しかし、耐攻撃コード復帰例外処理において、レジスタｒ１は封印しなおされているため、封印レジスタアクセスフォールト（SEALED_REGISTER_ACCESS_FAULT_EXCEPTION）が発生している。
このように、耐攻撃コード復帰例外のシーケンスによって、ＧＴ１０は、復帰時に保護コードの秘密データを守っている。
＜保護コンテキストの切り替えの管理＞
以下、耐攻撃ユーザプロセスからＯＳカーネルプロセスへのコンテキスト切り替えがおこり、全レジスタがスタックに退避されるケースを想定する。図３０に、ＯＳカーネルによる保護コンテキスト切り替え時のシーケンスの一例を示す。
図３０において、アプリケーション１からアプロケーション２に保護コンテキストを切り替えると仮定している。当初、アプリケーション１が利用するレジスタｒ１は、封印されている。その後、保護コンテキストを切り替える際に、ＯＳカーネル６０は、非許諾領域スタックストア（STMEA_TO_UA）命令を実行することにより、レジスタｒ１の値はデータ暗号・復号鍵Kdで暗号化されてから退避される。さらに、スタックされたレジスタｒ１は、レジスタ解放（RELEASE_REG）命令により０クリアされる。レジスタｒ１が解放されることにより、アプリケーション２のプロセスがレジスタｒ１を利用することが可能になる。
その後、保護コンテキストが元のプロセスにもどる際に、ＯＳカーネル６０は非許諾領域スタックロード（LDMEA_FROM_UA）命令を実行することにより、退避されていたレジスタの値が復号されて、レジスタｒ１に戻される。その後、レジスタｒ１は再度封印される。コンテキスト切り替えの際に、このような保護コンテキスト管理によって、封印レジスタを含めたレジスタの維持、復帰を保障することはＯＳカーネル６０の処理として位置付けられる。
なお、ＯＳカーネル６０が非保護システムコールを呼び出す際は、SPを一般仮想空間のアドレスに切り替えてから呼び出すなどの工夫が必要である。ＯＳは従来通り、システムコールの戻り値を一般仮想領域に記録すればよい。
一方、ＯＳカーネル６０が保護システムコールを呼び出す際には、戻り値を格納するスタック領域を共有するためのＧＴライセンスをパラメタなどとして渡す。ＯＳは受け取ったＧＴライセンスをパラメタとしてAUTHORIZEコマンドを実行することで、耐攻撃スタック領域をアプリケーションプロセスと共有することができる。
＜保護データ領域の安全な共有＞
上記において、耐攻撃空間内のプロセス同士であっても、ライセンスオーナーが異なるコード及びデータの領域間では、相互にアクセスすることができないと説明した。しかし、以下の耐攻撃領域共有機能を用いることで、ＧＴ１０で保護され、互いに異なるコード復号鍵Kcを持つソフトウェアパッケージ、ライブラリ、オブジェクト及びプロセス等の保護コードモジュール間で、保護データを安全に交換できるようにすることができる。
図３１に保護データ領域の共有の一例を示す。図３１は、ＧＴ１０上でプレーヤプロセス及びデコーダＤＲＭプロセスが動作している場合を説明する図である。
デコーダＤＲＭプロセスによってデコードされたデータは、ＤＲＭプロセス用の仮想ページに書き込まれる。このデコードされたデータは、データ暗号鍵Kdを用いて暗号化された後、ＲＡＭ１７内の共有物理ページに記録される。ＲＡＭ１７の共有物理ページに記録されたデータはデータ復号鍵Kdを用いて復号されて、ＤＲＭプロセス用の仮想ページに書き込まれる。プレーヤ（再生アプリケーション）プロセスはそのデータを読み出して再生する。
以下、このような保護データの共有を設定する手順について詳しく説明する。
まず、保護データを共有するために、共有されることになる保護データ領域を生成した生成元モジュールとその保護データ領域を生成元モジュールと共有する共有先モジュールを想定する。
生成元モジュールと共有先モジュールとがパッケージとして異なっている（すなわちKcが異なる）にもかかわらず、共有先モジュールが生成元モジュールの保護データ領域を読み出すことができるようにするためには、図３２に示すようにして、生成元モジュールは共有先モジュールを認証しなければならない。その認証が正常に完了できた上で、ＧＴ１０内部において、生成元モジュールの保護データ領域の暗号鍵Kdを共有先モジュールが利用できるようにＴＬＢおよびＴＲＢが設定されなければならない。
以下、図３２に沿って、モジュールの認証、並びに、保護データ復号鍵共有手順の設定手順について説明する。図３２において、括弧内の数字は、処理の順番を示し、以下の説明における手順の番号に対応する。また、図３２中の各記号の意味は次のとおりである。
RN：生成元モジュールが一時的に生成した乱数
KPacm：ソフトウェアモジュール向け認証局のルート公開鍵
Kacm：ソフトウェアモジュール向け認証局のルート秘密鍵
Kdp：共有先モジュールの秘密鍵
KPdp：共有先モジュールの公開鍵
C (KPdp, Kacm)：共有先パッケージの公開鍵証明書
Kc1:生成元モジュールのコード復号鍵
Kc2:共有先モジュールのコード復号鍵
（１）生成元モジュールが共有先モジュールに一時的に生成した乱数を渡す。
（２）共有先モジュールが、自身のプロセスが生成した仮想領域のＩＤとKc2をKPgtで暗号化した値と乱数とを連結したデータに、そのデータのデジタル署名と署名に用いた秘密鍵に対応する公開鍵の証明書とを付加する。この証明書はPKIライブラリ用認証局(CApki)、DRM用認証局(CAdrm)あるいはアプリケーション向け認証局(CAap)などの信頼できる第三者が発行したものでなければならない。なお、この説明では、証明書には、復号鍵Kc="YYYYYY"がKPgtで暗号化されているとする。
（３）共有先モジュールは、（２）で生成したデータを、生成元モジュールに一般のデータ共有／プロセス間通信などを利用して渡す。
（４）生成元モジュールは、署名をチェックし、その正当性を確認できた場合、受け付けた被許諾コード鍵Authorized Code Keyとアクセス権’PR’（耐攻撃モードで読み出し専用）と暗号・復号鍵Kdを埋め込んだＧＴライセンスと指定仮想領域をパラメタとして、アクセス許諾命令(AUTHORIZE)を実行する。
なお、この説明では、暗号・復号鍵Kd="AAAAAA"がＧＴライセンスに埋め込まれているとする。
（５）アクセス許諾命令を実行した結果、共有先モジュールのＴＬＢにリンクしたＴＲＢ内の行に、ＧＴライセンスの内容が設定される。これにより、共有先モジュールが共有保護領域から読み出すデータは、鍵Kdで正常に復号された状態でキャッシュされる。
この結果、図３２に示す例によれば、ＴＬＢの４行目には、物理ページ番号"002"へのアクセス権"PR"が設定され、このＴＬＢ内の行に対応するＴＲＢの４行目には、データ鍵Kd="AAAAAA"がKeyフィールドに設定される。これにより、生成元モジュールの保護データ領域（ＴＬＢの２行目に対応）を、共有先モジュールが、データ鍵Kd="AAAAAA"を用いて復号して読み出す事が可能となる。
なお、異なるモジュール間で相互認証を行う場合には、手順（２）において共有先モジュールは、生成元モジュールの公開鍵または公開鍵で暗号化した対称鍵暗号法の鍵で、生成した送信メッセージを暗号化して、生成元モジュールに渡せばよい。これにより、このメッセージは生成元モジュール以外では復号できないこととなる。
なお、図１０に示すＴＬＢ内で、ＩＤが２である行とＩＤが７である行は、保護領域を共有した場合を例として示したものである。
図３３に、耐攻撃領域共有システムコールを呼び出した際の処理の手順を示す。この手順（Ｓ１１０からＳ１２３）は、システムコール時の入力パラメタが領域サイズの代わりに領域の先頭のアドレスであることをのぞいて、図２８に示す手順（Ｓ９０からＳ１０３）と同様であるため、説明を省略する。
なお、コンテンツ再生(Player)アプリケーションは、上述のローカルデータ共有方式を用いてデコーダDRM４０からデータを得て、これを再生し、さらに編集することとしてもよい。編集し、その結果を記録する場合には、ＧＴライセンスにおいて指定されたアクセス条件に従わなければならない。また、再生アプリケーションはこれらの処理をＧＴ保護コードとして生成しなければならない。
再生時間や期限の制限を再生アプリケーションに強制するためにはセキュアタイマーが必要である。セキュアタイマーの構築は、ＧＴ１０の外に独立したハードウェアTRMとして実現することしてもよい。または、ＧＴ１０が水晶発信機などを内蔵することが可能である場合、上述の定期割り込み間隔設定コマンドを用いて耐攻撃ソフトウェアとして構築することとしてもよい。いずれの場合も、タイマーがなんらかの理由で停止する場合を想定すると、外部のTrusted Secure Timerと同期をとる機能を持つ必要がある。
＜ＤＲＭソフトウェア構築モデル＞
以下、ＤＲＭソフトウェアモジュールの構築モデルに説明する。デコーダＤＲＭ３０、メディアＤＲＭ４０及びこれらのＤＲＭが用いるＰＫＩライブラリ２０内の暗号・復号ライブラリ、更には、ＴＲＭ化が必要なその他のアプリケーションは、ＧＴ１０上で保護されるＧＴ保護コードとして流通し、実行される。これらのモジュールは、ほぼ全文を暗文とすることによりＧＴ１０で保護される。
図３４に、ＤＲＭソフトウェアモジュールの構築モデルの一例を示す。このモデルでは、上記４つのモジュールが異なる開発メーカーで開発され、異なるコード暗号鍵key (Kc)で暗号化されていることを想定している。図３４において、細い黒矢印は、暗号化されたライセンスキーのやり取りを示し、細い白矢印は、復号されたライセンスキーのやり取りを示し、太い黒矢印は、暗号化されたコンテンツのやり取りを示し、太い白矢印は、複合されたコンテンツのやり取りを示す。括弧内の数字は、手順の順番を示す。以下、図３４に沿って、コンテンツとそのライセンスキーのダウンロード、管理、再生手順について説明する。
（１）インターネット等のネットワークからダウンローダアプリケーションを介して、暗号化ライセンスキー及び暗号化コンテンツは記録媒体に記録される。
（２）ライセンスキーは暗号化された状態で、ダウンローダーを介してメディアDRM４０に転送される。
（３）メディアDRM４０内で復号されたライセンスキーは、後述の方法を用いて安全に管理され、暗号化された状態で記録媒体に記録される。ライセンスキーの再暗号化はＧＴ１０で保護されたPKI暗号ライブラリ２０を用いて実施される。
（４）ユーザの再生要求があった場合、メディアDRM４０は記録媒体からライセンスキーを取り出し、復号する。
（５）メディアDRM４０はデコーダDRM３０を認証し、デコーダDRM３０と共有するセッションキーを用いてライセンスキーを暗号化してデコーダDRM３０に転送する。なお、この鍵の共有及び手順（７）の保護データの共有については＜保護データ領域の安全な共有＞において説明した。
（６）デコーダDRM３０は記録媒体から取り出した暗号化コンテンツと、メディアDRM４０から得たライセンスキーとをパラメタとしてPKI暗号ライブラリ２０に復号処理を依頼する。
（７）復号されたコンテンツは共有保護データ領域を介してPlayerなど再生アプリケーションに渡される。
（８）再生アプリケーションがコンテンツを再生する。
以下、図３５から図４０を用いて、上述の手順をより詳しく説明する。
まず、図３５及び図３６を用いて、メディアＤＲＭによって行われる処理について説明する。
まず、メディアＤＲＭ４０は、耐攻撃権限設定（SET_TR_RIGHTS）命令及びレジスタの封印（SEAL_REG）命令を実行する（Ｓ１３１及びＳ１３２）。続いて、メディアＤＲＭ４０は、自身に埋め込まれた秘密情報を取り出す（Ｓ１３３）。メディアＤＲＭ４０は、取り出された秘密情報に対応するＧＴライセンスが、ライセンスを記録するライセンスＤＢに格納されているか否か判定する（Ｓ１３４）。既にライセンスＤＢに格納されている場合（Ｓ１３４：あり）、Ｓ１３６に進み、まだライセンスＤＢに格納されていない場合（Ｓ１３４：なし）、メディアＤＲＭ４０は、そのＧＴライセンスをライセンスＤＢに設定した後（Ｓ１３５）、Ｓ１３６に進む。
Ｓ１３６において、メディアＤＲＭ４０は、ライセンス管理用の耐攻撃データ領域を生成する。Ｓ１３６の処理について、詳しくは、図３６を用いて後述する。
ライセンス管理用の耐攻撃データ領域を生成できた場合（Ｓ１３７：NORMAL）、Ｓ１３８に進み、ライセンス管理用の耐攻撃データ領域を生成できなかった場合（Ｓ１３７：ERROR）、Ｓ１４２に進む。
Ｓ１３８において、メディアＤＲＭ４０は、ライセンス管理用の耐攻撃データ領域を初期化し（Ｓ１３８）、ライセンス受信要求、再生許諾要求又は終了要求を待つ。ライセンス受信要求を受けた場合（Ｓ１３９：あり）、メディアＤＲＭ４０はライセンスを受信して（Ｓ１４３）、Ｓ１３９にもどる。再生許諾要求を受けた場合、メディアＤＲＭ４０は再生許諾を行い（Ｓ１４４）、Ｓ１３９にもどる。終了要求を受けた場合（Ｓ１４１：あり）、レジスタ解放（RELEASE_REG）命令を実行し（Ｓ１４５）、処理を終了する。
ライセンス管理用の耐攻撃データ領域の生成に失敗した場合（Ｓ１３７：ERROR）、メディアＤＲＭ４０は、エラー表示を出力装置(不図示）に出力し（Ｓ１４２）、Ｓ１４５に進む。
次に、図３６を用いて、図３５のＳ１３６について説明する。ライセンス管理用耐攻撃データ領域を生成する際、まず、メディアＤＲＭ４０は、コード暗号鍵Kdを用いてアクセス権PRWのＧＴライセンスを生成する（Ｓ１５１）。続いて、メディアＤＲＭ４０は、耐攻撃領域取得システムコールを呼び出す（Ｓ１５２）。Ｓ１５２の処理については、上記のとおりである。
耐攻撃領域を取得する際にエラーが生じなかった場合（Ｓ１５３：なし）、途中に生成された署名を確認し（Ｓ１５４）、署名が正しければ（Ｓ１５５：一致）、正常にメインフローに戻る。耐攻撃領域を取得する際にエラーが生じた場合（Ｓ１５３：あり）、又は、署名が正しくない場合（Ｓ１５５：不一致）、エラーをメインフローに返す。
次に、図３７から図３９を用いて、デコーダＤＲＭによって行われる処理について説明する。まず、デコーダＤＲＭ３０は、耐攻撃権限設定（SET_TR_RIGHTS）命令及びレジスタの封印（SEAL_REG）命令を実行する（Ｓ１６１及びＳ１６２）。続いて、メディアＤＲＭ４０は、自身に埋め込まれた秘密情報を取り出す（Ｓ１６３）。
さらに、デコーダＤＲＭ３０は、復号されたコンテンツ用の共有保護データ領域を生成する（Ｓ１６４）。このＳ１６４について、詳しくは図３８を用いて後述する。
Ｓ１６４の処理が正常に行われた場合（Ｓ１６５：NORMAL）、デコーダＤＲＭ３０は、再生許諾要求、再生要求及び終了要求の何れかを受けるまで待つ。Ｓ１６４の処理が正常に行われなかった場合（Ｓ１６５：ERROR）、デコーダＤＲＭ３０は、出力装置（不図示）にエラーが生じた旨を表示し（Ｓ１６９）、Ｓ１７５に進む。
再生許諾要求を受けた場合（Ｓ１６６：あり）、デコーダＤＲＭ３０は、メディアＤＲＭ４０からコンテンツのライセンスキーを取得し（Ｓ１７０）、Ｓ１６６に戻る。
再生要求を受けた場合（Ｓ１６７：あり）、デコーダＤＲＭ３０は、コンテンツのライセンスキーを取得済みであるか否か判定する（Ｓ１７１）。コンテンツキーを取得済みである場合（Ｓ１７１：取得済）、デコーダＤＲＭ３０は暗号化ブロックを復号し、そのブロックを共有する処理を行う（Ｓ１７３）。Ｓ１７３についいて詳しくは図３９を用いて後述する。続いて、デコーダＤＲＭ３０は、再生アプリケーションに返却値を通知し（Ｓ１７４）、Ｓ１６６に戻る。Ｓ１７１の判定において、まだライセンスキーを取得していない場合（Ｓ１７１：なし）、出力装置（不図示）にエラー表示を行い（Ｓ１７２）、Ｓ１７５に進む。
終了要求を受けた場合（Ｓ１６８：あり）、Ｓ１７５に進み、デコーダＤＲＭ３０は、レジスタ解放（RELEASE_REG）命令を実行し、処理を終了する。
次に、図３８を用いて、図３７のＳ１６４について詳しく説明する。復号されたコンテンツ用の共有保護データ領域を生成するために、まず、デコーダＤＲＭ３０は、デコーダＤＲＭ３０によってデコードされたコンテンツを記録するための耐攻撃領域を取得するために耐攻撃領域取得システムコールを呼び出す（Ｓ１８１）。この処理については既に説明した。耐攻撃領域が生成できた場合（Ｓ１８２：NORMAL）、Ｓ１８４に進む。そうでない場合（Ｓ１８２：ERROR）、エラー表示を出力装置（不図示）に出力させ（Ｓ１８３）、メインフローに復帰する。
Ｓ１８４において、デコーダＤＲＭ３０は、ＧＴ１０に、暗号化されたコンテンツを復号するために用いるＰＫＩ暗号ライブラリを認証させる。なお、この認証手順は、＜保護データ領域の安全な共有＞において、図３２を用いて説明した認証手順と同様である。
Ｓ１８４の認証が正常に行われた場合（Ｓ１８５：NORMAL）、Ｓ１８７に進む。Ｓ１８４の認証が正常に行われなかった場合（Ｓ１８５：ERROR）、エラー表示を出力装置（不図示）に出力させ（Ｓ１８６）、メインフローに復帰する。
Ｓ１８７において、デコーダＤＲＭ３０は、耐攻撃領域共有システムコールを呼び出す。Ｓ１８４の処理が正常に行われた場合（Ｓ１８８：NORMAL）、メインフローに復帰する。これにより、デコーダＤＲＭ３０とＰＫＩライブラリが、耐攻撃領域に書きこまれた保護データを共有することができるようになる。Ｓ１８４の処理が正常に行われなかった場合（Ｓ１８８：ERROR）、エラー表示を出力装置（不図示）に出力させ、メインフローに復帰する。
次に、図３９を用いて、図３７のＳ１７３についてより詳しく説明する。まず、デコーダＤＲＭ３０は、再生アプリケーションは既に認証されているか否か判定する（Ｓ１９１）。既に認証されている場合（Ｓ１９１：認証済）、Ｓ１９６に進む。まだ認証されていない場合（Ｓ１９１：未認証）、Ｓ１９２からＳ１９５が行われる。この処理は、図３８のＳ１８４からＳ１８８と同様であるため、説明を省略する。Ｓ１９２からＳ１９５の処理においてエラーが発生した場合（Ｓ１９３及びＳ１９５でERROR）、エラー表示を出力装置（不図示）に出力させ（Ｓ１９８）、メインフローに復帰する。Ｓ１９２からＳ１９５が正常に行われた場合、再生アプリケーションとデコーダＤＲＭ３０とは耐攻撃領域を共有し、再生アプリケーションは、デコーダＤＲＭ３０によって耐攻撃領域に書きこまれたコンテンツを読み出すことができるようになる。
Ｓ１９６において、デコーダＤＲＭ３０は、暗号化されたコンテンツをＰＫＩ暗号ライブラリ２０を用いて復号する。復号されたコンテンツは、共有化された耐攻撃領域に書き込まれる。復号が正常に行われた場合（Ｓ１９７：NORMAL）、メインフローに復帰する。復号が正常に行われなかった場合（S１９７：ERROR）、Ｓ１９８に進む。
次に、図４０を用いて、再生アプリケーションによって行われる処理について説明する。
まず、再生アプリケーションは、耐攻撃権限設定（SET_TR_RIGHTS）命令及びレジスタの封印（SEAL_REG）命令を実行する（Ｓ２０１及びＳ２０２）。続いて、再生アプリケーションは、自身に埋め込まれた秘密情報を取り出す（Ｓ２０３）。続いて、再生アプリケーションは、デコーダＤＲＭ３０に認証を要求する（Ｓ２０４）。この認証要求に基づいて、上記Ｓ１９２が行われる。
認証が正常に行われた場合（Ｓ２０５：NORMAL）、再生アプリケーションは、再生要求、その他の要求又は終了要求を受けるのを待つ。認証が正常に行われなかった場合（Ｓ２０５：ERROR）、再生アプリケーションは、エラー表示を出力装置（不図示）に出力させ（Ｓ２１４）、Ｓ２１６に進む。
再生要求を受けた場合（Ｓ２０６：あり）、再生アプリケーションは、デコーダＤＲＭ３０に暗号ブロックを復号するよう要求する（Ｓ２１０）。デコーダＤＲＭ３０からの返却値が正常な場合（Ｓ２１１：NORMAL）、再生アプリケーションは、そのブロックを再生する（Ｓ２１２）。コンテンツの再生が終了するまで（Ｓ２１４：Ｎｏ）、Ｓ２１０からＳ２１２は繰り返される。コンテンツの再生が終了すると（Ｓ２１４：Ｙｅｓ）、Ｓ２０６にもどる。
再生要求以外の要求を受けると（Ｓ２０７：あり）、再生アプリケーションはその要求を実行し（Ｓ２０８）、Ｓ２０６にもどる。終了要求を受けると（Ｓ２０９：あり）、再生アプリケーションはＧＴ１０にレジスタ解放（RELEASE_REG）命令を実行させ（Ｓ２１６）、処理を終了する。
＜秘密情報の管理＞
証明書を発行された公開鍵暗号法の公開鍵に対応する秘密鍵Kdrmなど、DRMコードパッケージ開発者が生成する秘密情報を維持・管理する方式を図４１に示す。図４１において、細い矢印はデータの流れを示し、太い白矢印は、鍵等の埋め込みを示す。また、括弧内の数字は処理の順番を示し、以下の説明における手順の番号に対応する。
特に公開鍵証明書に対応する秘密鍵は、CRLの指定時などに、特定のGTと特定のDRMのセットのみを停止する必要性から、本方式を用いる必要がある。本方式の手順はおおよそつぎのようになる。
（１）開発者が生成した秘密鍵（Kdrmなど）は、クラス・個別いずれの場合も開発者が生成した対称鍵暗号法の鍵Kprdで暗号化され、パッケージ内に埋め込まれる。
（２）ＧＴライセンス化された、Kprdとアクセス条件’PR’とは、耐攻撃モードでのみ読み出し可能な形態で保護コード内に埋め込まれる。
（３）コード全体は、Kcで暗号化されDRMとして保護パッケージ化される。
（４）KcはKPgtで暗号化され、DRMライセンスとしてDRMパッケージに入れられる。
（５）DRM実行時にVHTRMからこのGTライセンスはＧＴ１０に投入され、ＧＴ１０内部でKprdが読み出される。
（６）KprdでKdrmは復号され、利用される。
これにより、開発者が指定したＧＴ上の指定プロセス以外のプロセスは、秘密鍵Kdrmを読むことができなくなる。特定のＧＴが破られた場合には、破られたＧＴの公開鍵暗号法の公開鍵証明書のみを失効すればよい。従って、同じDRM向けのものでも、他のGT向けの証明書（Cdrm2）は正当に利用することができる。
本方式はDRMの秘密鍵のみでなく、他の保護パッケージの秘密鍵を管理する方法としても利用できる。
＜ＵＤＡＣライセンス管理＞
保護コンテンツとUDACライセンスに関する一般情報の管理方式は、UDAC-MBおよびUDAC-LAの方式を引き継ぐことしてもよい。図４２にライセンス管理のためのメモリアクセスの方式を示す。
図４２に示すように、コンテンツ復号鍵などのライセンスの秘密情報は、ＲＡＭ１７内の保護データ領域に記録されて管理される。その保護データ領域内の情報は、ファイルとしてストレージやフラッシュメモリなどに記憶されることとしてもよい。秘密情報を記録する際にデータ暗号鍵Kdで暗号化することにより、ＣＰＵ（ＧＴ１０）の再起動時にもライセンスの秘密情報が安全に保護された状態で利用できる。このデータ暗号鍵KdはＴＲＢ暗号鍵Ktrbで暗号化された状態で、暗号化キーテーブルの行として一般の外部記憶装置に保持されることしてもよい。
なお、KtrbとKtlbの耐攻撃能力を高めるためには、一定の期間を置いてKtrbとKtlbの内容をリフレッシュする必要がある。リフレッシュの前にはライセンス情報をすべて、耐攻撃プロセスが生成した一時キーで暗号化してバックアップしなければならない。リフレッシュによるKtrb及びKtlb変更のあとに、ページテーブルと暗号化キーテーブルを再構築する。全ライセンス情報を復号し、再構築した耐攻撃領域にリストアすればよい。
上記の秘密鍵管理が前提としてＣＲＬの管理を行う事も可能である。また、ライセンスごとのCRL制御機能は上記のライセンス管理機能内に持つこととしてもよい。１つのDRMパッケージの証明書は、ＧＴ１０が持っている証明書の数だけ発行されることを原則とする。DRMパッケージ自体を失効する場合にはそれらの証明書のすべてが失効される。また特定のGTを失効する場合には、そのGT用に発行したDRMパッケージ証明書のみが失効される。
プログラムコンテンツを超流通し、UDACライセンスを扱う場合、DRMソフトウェアを利用せず、簡易版超流通機能として、GTライセンスをそのまま利用してもよい。また、GT上に構築したDRMソフトウェアを用いて、UDAC-MBやPIライセンスとして処理してもよい。 DRMソフトウェアを用いる場合、UDAC-MB/PIライセンスのうち、基本アクセス権(PR, X, PRW, PWX)のみはDRM内でGTライセンスに変換し、CPUのアクセス制御命令(AUTHORIZE)を用いて強制する。その他のアクセス条件については、GT保護DRM内で強制処理を行う。
当然ながら、UDACのみでなく、今日のソフトウェアTRMを用いた各社のDRMもGT保護化することで、ハードウェアTRMレベルの耐攻撃性を持つことができる。
＜変形例＞
上記において、ＧＴライセンスは移動しない事として説明したが、DRM間のライセンス移動機能の実現する事も可能である。同じＧＴ上で実行される２つのＤＲＭプロセス間でのライセンス移動・許諾は、＜保護データの安全な共有＞で認証された共有耐攻撃領域を介して実現することとしてもよいし、UDAC-MBやUDAC-PIなどのプロトコルを利用して実現する事としても良い。但し、ライセンスの移動機能を実装する場合、再送攻撃による不正コピーを防止するためには、ＴＲＭ内に、以下のUPL (Unreplicatable Private Locker：複製不能プライベートロッカー)にライセンス管理用秘密情報を格納しなければならない。このUPLをGTのみで実現したい場合には、TRB.uo（ＴＲＢ内のuoフィールドの値）およびTRB.cl（ＴＲＢ内のclフィールドの値）を両方ともonにした耐攻撃領域にライセンス管理用秘密情報を格納することでこれが可能になる。
ただし、GTの電源を切断後もUPLを用いて管理しているライセンスを維持する必要がある場合には、ライセンス管理用秘密情報を格納するUPLの領域だけでも不揮発性記憶素子にし、 Permanent UPL（半永久UPL）にする必要がある。耐攻撃空間の一部をPermanent UPLに割り当てる方法については、ここでは特定しない。
GTの外部にTRM化したUPLを実現するためには、UPLはUDAC-MBなどのTRM認証プロトコルをUPL内に実装する必要がある。外部に実現するPermanent UPLとしてはUDACを実装したSecure MMCなどを利用することができる。
次に、第２実施形態について説明する。第１実施形態において、コードブロック及びデータブロックは、平文又は暗文であった（ebim＝０又は１）。第２実施形態によれば、ブロックは、暗文及び平文更には他の情報の組合せであってもよい。
以下、図４３を用いて第２実施形態に係わるＧＴを実現するＣＰＵの構成について説明する。
なお、図４３において、図３に示す第１実施形態と同様の部分は省略されている。図４３に示すように、第２実施形態に係わるＧＴ１００は、第１実施形態にかかわる構成に加えて、さらに、保護ブロックセレクタ１０１及び１０４、ハッシュチェッカ１０２、及びハッシュエンジン１０３を備える。
保護ブロックセレクタ１０１は、キャッシュ１１又は１２から出力されるコードブロック又はデータブロックが、保護されるべきブロックであるか否かをebimの値に基づいて識別する。出力されたブロックが保護されるべきブロックである場合、保護ブロックセレクタ１０１は、そのブロックをハッシュエンジン１０３に出力する。ハッシュエンジン１０３はそのブロックのハッシュを生成し、ハッシュが生成された後に、暗号ブロック１６はそのブロックを暗号化し、ＲＡＭ１７に出力する。一方、キャッシュ１１又は１２から出力されたブロックが保護されるべきブロックではない場合、保護ブロックセレクタ１０１は、そのブロックをＲＡＭ１７に出力する。
また、保護ブロックセレクタ１０４は、ＲＡＭ１７から出力されるコードブロック又はデータブロックが、暗号化されているブロックであるのか平文のブロックであるのか識別する。出力されたブロックが暗号化されているブロック、つまり保護ブロックである場合、保護ブロックセレクタ１０４は、その保護ブロックを暗号エンジン１６に出力する。暗号エンジン１６は、その保護ブロックを復号し、復号されたブロックをハッシュエンジン１０３に出力する。ハッシュエンジンは、そのブロックのハッシュを生成し、ハッシュチェッカ１０２に出力する。ハッシュチェッカ１０２は、生成されたハッシュを確認し、ハッシュが正しい事を確認できた場合、そのブロックをキャッシュ１２又は１３に出力する。一方、ＲＡＭ１７から出力されたブロックが保護ブロックではない場合、保護ブロックセレクタ１０４は、そのブロックをキャッシュ１２又は１３に出力する。
なお、図４３において、保護ブロックセレクタ１０１及び１０４を備えることとしたが、保護ブロックセレクタ１０１及び１０４を１つの保護ブロックセレクタとして構成することとしてもよい。これにより、回路を小型化することが可能となる。
次に、第２実施形態に係わるＴＬＢ内のフィールドについて説明する。図５に示すＴＬＢには、ebimフィールドが含まれる。第１実施形態によれば、このebimの値は０又は１であった。第２実施形態によれば、このebimの取りうる値として、更に２から７が追加される。以下、ebimの値に応じるブロックの構造について説明する。
ａ）ebim＝０の場合、平文のみ（ダミーライセンス、第１実施形態と同様）
ｂ）ebim＝１の場合、暗文のみ（第１実施形態と同様）
ｃ）ebim＝２の場合、保護ブロック開始識別コード使用
ｄ）ebim＝３の場合、同上かつ暗号化ブロックのみ
ｅ）ebim＝４の場合、署名付平文ブロックのみ。
キャッシュロード時署名確認必須
ｆ）ebim＝５の場合、ハッシュ付暗号化保護ブロックのみ。
復号後ハッシュ確認必須
ｇ）ebim＝６の場合、保護ブロック開始識別コード使用。
署名／ハッシュ確認必須
ｈ）ebim＝７の場合、同上かつ暗号化ブロックのみ。ハッシュ確認必須
すなわち、本フィールドの各ビットは、次のような意味を持つ。
ビット０：暗号化フラグ。このフラグがオンである場合、ブロックが暗号化されている事を示す。
ビット１：保護ブロック開始識別コードフラグ。このフラグがオンである場合、ブロックに保護ブロック開始識別コードが付加されていることを示す。個フラグがオフである場合、ＧＴ１０は、保護ブロック開始識別コードを認識する必要はない。
ビット２：ハッシュ付加・確認フラグ。このフラグがオンである場合、データをＧＴ１０の外に掃出する際に、ＧＴ１０は、そのデータブロックにハッシュを付加する。また、コードやデータをＧＴ１０内に取り込む際には、ブロックに付加されたハッシュ値を確認する。このフラグがオフである場合、ブロックにハッシュを付加したり確認したりする必要はない。
これらのebimの値は、第１実施形態と同様に、ＧＴライセンスに含まれる被許諾コード鍵ACgt内のebimフィールドの値に基づいて設定される。
次に、図４４を用いて第２実施形態におけるブロックの構造について説明する。ＧＴ１０によれば、保護コードブロックと保護データブロックの構造を同じ形式にしても良い。これにより、ＣＰＵ内の回路リソースの利用率を向上させることが可能となる。図４４に示すように、開発者や創作者によって生成されたブロックは、乱数、一般命令やデータを含み、必要な場合さらにハッシュを含む。ebimが１又は５である場合、このブロックが暗号化されることにより、保護ブロックが生成される。ebimが２、３、６又は７である場合、このブロックが暗号化された後に、保護ブロックヘッド識別コードが平文で先頭に付加されることにより。保護ブロックが生成される。保護ブロックヘッド識別コードは、ブロックが保護ブロックであるか否かを示す暗号化フラグ及び、ブロックの最後にハッシュが付加されているか否かを示すハッシュフラグを含む。保護ブロックヘッド識別コード及び暗号化された乱数部分は、保護ブロック開始命令を構成する。
ＲＡＭ１７上の保護ブロックは、ＧＴ１０内で復号されることにより、平文の一般命令やデータが取得される。ebimが１又は５である場合、乱数部分やハッシュ部分は、コードやデータのアドレスがかわらないように、ＮＯＰ（No OPeration）命令に変換されてから、命令キャッシュ１２又はデータキャッシュ１３にロードされる。なお、ebimが１である場合は、第１実施形態と同じである。ebimが２、３、６又は７である場合、乱数部分、ハッシュ部分に加えて保護ブロックヘッド識別コードも、ＮＯＰ（No OPeration）に変換されてから、命令キャッシュ１２又はデータキャッシュ１３にロードされる。
なお、プロセッサコア１１上の作業データ等を暗号化した場合の保護ブロックの構造も、開発者又は創作者によって生成されたブロックを暗号化した場合の保護ブロックと同様の構造である。
図４５に、ebimが４である場合のブロックの構造を示す。図４５に示すように、ebimが４である場合、ＲＡＭ上のブロックは、平文のコード又は平文のデータに署名が付加された構造となっている。命令キャッシュ１２又はデータキャッシュ１３上にブロックをロードする際には、署名はＮＯＰ命令に変換される。なお、署名は、コード又はデータのハッシュ（ＳＨＡ−１など）を暗号鍵Kc又はKdで暗号化した値とすることとしてもよい。なお、Kc及びKdは、ＧＴライセンスで指定され、ＴＲＢの暗号鍵フィールド（TRB.key）に設定されている。
次に、第２実施形態に係わるＧＴによって行われる処理について説明する。基本的な動作は、第１実施形態と第２実施形態とは同様であるため、以下の説明において、第２実施形態において更に付加された構成によって行われる処理に重点をおいて説明する。
まず、図４６を用いて、保護ブロックセレクタ１０４によって行われる処理について説明する。
まず、保護ブロックセレクタ１０４は、ＲＡＭ１７（外部メモリ）からブロックのロード要求が出されるのを待つ（Ｓ２２１ ）。ＲＡＭ１７からブロックのロード要求が出されると（Ｓ２２１：要求）、保護ブロックセレクタ１０４は、予測されるブロックのアドレスと対応する行のebimフィールドの値をＴＬＢから読み込む（Ｓ２２２）。
保護ブロッセレクタ１０４は、ebimの第１ビットがオンであるか否か判定する（Ｓ２２３）。ebimの第１ビットは、ブロックに保護ブロック開始命令が付加されているか否かをしめす。ebimの第１ビットがオンである場合（Ｓ２２３：ｏｎ）、そのブロックには保護ブロック開始命令が付加されている。保護ブロックセレクタ１０４は、そのブロックの先頭に付加されている保護ブロック開始命令を読み出し（Ｓ２２４）、その保護ブロック開始命令において暗号化フラグがオンであるか否か判定する（Ｓ２２５）。暗号化フラグは、暗号化フラグがオンである場合（Ｓ２０５：ｏｎ）、Ｓ２２９に進む。Ｓ２２９において、保護ブロックセレクタ１０４は、そのブロックを暗号エンジン１６に出力し、Ｓ２０１に戻る。この場合、そのブロックは、復号された後にキャッシュ１２又は１３に転送される。
暗号化フラグがオフである場合（Ｓ２２５：ｏｆｆ）、保護ブロックセレクタ１０４は、さらに、ebimの第２ビットがオンであるか否か判定する（Ｓ２２６）。ebimの第２ビットは、そのブロックを転送する際にハッシュの確認が必要であるか否かを示す。ebimの第２ビットがオンである場合（Ｓ２２６：ｏｎ）、処理はＳ２０９に進む。ebimの第２ビットがオフである場合（Ｓ２２６：ｏｆｆ）、保護ブロックセレクタ１０４はそのブロックをキャッシュ１２又は１３に転送する（Ｓ２２７）。
Ｓ２２３の判定において、ebimの第１ビットがオフである場合（Ｓ２２３：ｏｆｆ）、保護ブロッセレクタ１０４は、更にebimの第０ビットがオンであるか否か判定する（Ｓ２２８）。ebimの第０ビットは、そのブロックを暗号化することが必要であるか否かを示す。ebimの第０ビットがオンである場合（Ｓ２２８：ｏｎ）、処理はＳ２２９に進む。ebimの第０ビットがオフである場合（Ｓ２２８：ｏｆｆ）、保護ブロックセレクタ１０４は、さらにebimの第２ビットがオンであるか否か判定する（Ｓ２３０）。ebimの第２ビットがオンである場合（Ｓ２３０：ｏｎ）、処理はＳ２２９に進む。ebimの第２ビットがオフである場合（Ｓ２３０：ｏｆｆ）、保護ブロックセレクタ１０４は、そのブロックをキャッシュ１２又は１３に転送し（Ｓ２３１）、Ｓ２２１に戻る。
続いて、図４７を用いて、ハッシュエンジン１０３によって行われる処理について説明する。
まず、ハッシュエンジン１０３は、ハッシュ要求のイベントが発生することを待つ（Ｓ２４１）。イベントが発生すると、ハッシュエンジン１０３は、ハッシュの要求が行われたブロックを読み込む（Ｓ２４２）。さらに、ハッシュエンジン１０３は、そのブロックのアドレスと対応するebimを読み込み、そのebimの第２ビットがオンであるか否か判定する（Ｓ２４３）。ebimの第２ビットがオンである場合（Ｓ２４３：ｏｎ）、ハッシュエンジン１０３は、そのブロックのハッシュを生成し（Ｓ２４４）、そのブロックと生成したハッシュの内容を次の回路ブロックに転送し（Ｓ２４５）、Ｓ２４１に戻る。一方、ebimの第２ビットがオフである場合（Ｓ２４３：ｏｆｆ）、ハッシュエンジン１０３は、ハッシュを生成しないでそのブロックを次の回路ブロックに転送し（Ｓ２４６）、処理はＳ２４１に戻る。
続いて、図４８を用いて、ハッシュチェッカ１０２によって行われる処理について説明する。
まず、ハッシュチェッカ１０２は、ハッシュ要求のイベントが発生する事を待つ（Ｓ２５１）。イベントが発生すると、ハッシュチェッカ１０２は、要求が行われたブロックを読み込む（Ｓ２５２）。続いて、ハッシュチェッカ１０２は、そのブロックのアドレスと対応するebimを読み込み、そのebimの第２ビットがオンであるか否か判定する（Ｓ２５３）。ebimの第２ビットがオンである場合（Ｓ２５３：ｏｎ）、ハッシュチェッカ１０２は、ハッシュエンジン１０３によって生成されたハッシュと、そのブロックに付加されているハッシュとを比較する（Ｓ２５４）。比較の結果、２つのハッシュが一致しない場合（Ｓ２５４：不一致）、プロセッサコア１１に、ハッシュ不一致例外が発生したことを通知し（Ｓ２５５）、Ｓ２５１に戻る。２つのハッシュが一致した場合（Ｓ２５４：一致）、ハッシュチェッカは、そのブロックを次の回路ブロックに転送し（Ｓ２５６）、Ｓ２３１に戻る。
次に、第２実施形態の変形例について説明する。第２実施形態では、ebimに基づいて、保護ブロックセレクタは、ブロックを選択するとして説明した。この方式以外の方式を以下に例示する。
１．実行ファイルのヘッダに暗号化ブロックビットマップを埋め込む方法。保護ブロックセレクタは、このビットマップを先に読み込んで、ブロックを一般ラインに出力するか、復号ラインに出力するかを判断する。
２．コードの先頭を平文にし、この先頭のコードにおいて、何ブロックの平文のあと、何ブロックの保護コードがきてこれを繰り返すかを指定し、ＧＴ１００は、最初にこのコード（インストラクション）を実行する。このコードは、途中で変更することも可能である。この方式によれば保護コードブロックセレクタの機能を縮小できる。アドレスの下位ビットだけで、保護コードをセレクトすることができれば、さらにセレクタの機能を縮小させることが可能になる。
次に、第３実施形態について説明する。第１及び第２実施形態によれば、保護コードや保護データがキャッシュ内に入る時には、乱数を変換した結果として得られたＮＯＰがキャッシュライン長ごとに存在することになる。これにより、キャッシュ内のリソースを無駄に使用するという問題が生じる。第３実施形態は、その問題を解決する技術にかかわる。第３実施形態によれば、以下の方法１から３によってキャッシュのリソースを有効に利用することを可能となる。
方法１）乱数長とブロック数の積に、仮想領域長を加算した長さを、物理領域長とする。（仮想領域長＋乱数長×ブロック数＝物理領域長）。ＲＡＭ１７上に仮想ページの大きさにはみ出す部分を持つことにより、はみ出した部分、つまり乱数を変換したＮＯＰが、キャッシュ内に記録されないようにする。
方法２）乱数長とブロック数の積に等しい長さを持つ領域を、ＮＯＰ専用の物理領域として設定する。
方法３）キャッシュ内にＮＯＰを記録しない。図４９に、本方法によるＮＯＰの処理を示す。図４９に示すように、ＲＡＭ１７における、保護コードブロック又は保護データブロックは、暗号化されている。なお、場合によっては、保護コードブロック又は保護データブロックは、保護ブロックヘッド識別コードを含む。この保護コードブロック又は保護データブロックがＧＴ１０内で復号されると、一般命令（又は一般データ）、乱数及びハッシュを含むブロックが得られるが、キャッシュ内には、このうちの一般命令又は一般データが記録され、ＮＯＰが記録されるべき仮想アドレスのデータは記録されない。コードがＮＯＰの仮想アドレスにアクセスした場合、ＮＯＰをコードに返す。なお、仮想メモリに記憶されるＮＯＰをＯＳ等から読むことができるようにしても良いし、読むことができないようにしても良い。
次に、第４実施形態について説明する。第４実施形態は、上記において説明したＧＴ１０を２以上備えるＣＰＵ、つまりマルチＣＰＵにおいて保護プロセスを動作させる場合に係わる。
マルチＣＰＵで保護プロセスを動作させる場合、以下のような場合に備える必要がある。
１．コード復号鍵Kcを１つだけ持つ保護プロセスが、複数のスレッドを複数のＣＰＵ上で平行に実行する場合
２．スヌープ機能による保護コードや保護データなど、キャッシュ内容の自動同期に対応する。
図５０に、ＧＴ１０Ａ及びＧＴ１０Ｂを備えるマルチＣＰＵの構成をしめす。図５０に示すように、ＧＴ１０Ａ、ＧＴ１０Ｂ及びＲＡＭ１７が、バスを介して接続されている。ＧＴ１０Ａ及びＧＴ１０Ｂは、それぞれキャッシュを備える。複数のスレッドをＧＴ１０Ａ及びＧＴ１０Ｂによって並行に実行する場合、実行に先立って、ＧＴ１０Ａ及びＧＴ１０Ｂは、ＤＣＴＰ（Digital Transmission Content Protection）の完全認証（Full Authentication）等の相互認証を行う事によってセッション鍵Ksnpを得る。ＧＴ１０Ａ及びＧＴ１０Ｂは、秘密情報、保護コード及び保護データを交換する場合、セッション鍵Ksnpを用いる。これにより、ＧＴ１０Ａ及びＧＴ１０ＢはKtrbやKc、Kd等を安全に交換することが可能となる。ＧＴ１０Ａ及びＧＴ１０Ｂは、セッション鍵Ksnpを用いてキャッシュ内のデータを暗号化し、互いに同期転送することにより、キャッシュ内容の同期を実現する。
次に、第４実施形態について説明する。従来のコンパイラやアッセンブラを用いて作成したプログラムコードオブジェクトは、ＧＴ保護関連の情報を持たない。これを図５１に示すような方式でＧＴでの保護コード実行形式、さらにSCDF（超流通コンテンツ形式：Super Content Distribution Format）に変換することができる。
図５１に、コードオブジェクトから保護コード実行形式を出力するツール群の例を示す。図５１では、保護コード実行形式とライセンスを生成し、さらに実行形式を超流通実施のためにSCDF生成ツールを通してSCDFデータを生成する例を提案している。
図５１に示すように、ＳＣＤＦ生成ツールは、リンカ前処理部、リンカ、保護コード実行形式生成部、及びＳＣＤＦ作成部を備える。まず、コードオブジェクトは、リンカ前処理部によって、複数のブロックに分割され、それぞれのブロックにＮＯＰ命令が追加される。続いて、リンカは、アドレス解決を行う。さらに、リンカの後、保護コード実行形式生成部は、コード暗号鍵を用いて各ブロックを暗号化することにより保護コード実行形式を生成する。一方、ＧＴライセンス生成部は、前記コード暗号鍵を含み、前記秘密鍵と対になる公開鍵によって暗号化されたライセンスを生成する。
次に、第５実施形態について説明する。ＧＴ１０による保護を実現するためには、ＧＴ１０と、ＧＴ１０で保護されるＤＲＭソフトウェアモジュールとが必要である。しかし当初はＧＴも普及しておらず、ＯＳもＧＴ１０の機能をサポートしていないため、次のようなシナリオで普及を推進する必要がある。
（１）当初はソフトウェアTRMにより、CPU拡張部分のハードウェア命令エミュレータを開発し、従来のＣＰＵ向けのＤＲＭソフトウェアをエミュレートする。これにより、従来のＣＰＵ向けのＤＲＭソフトウェアも、ＧＴ１０上で保護ソフトウェアとして稼動することが可能となる。
（２）DRM部分は既存DRMモジュールを流用する。
（３）ＯＳがＧＴ１０の機能をサポートするまでは耐攻撃空間管理、保護コンテキスト切り替え管理やDRMなどをＯＳパッケージの外に持つ必要がある。
また、当初はアプリケーションとデコーダDRMは一つのパッケージにし、Kc及びKdは同じとすることとしてもよい。
以下、上記各実施形態において説明したＧＴの応用例について、第６実施形態から第１２実施形態として説明する。
ＧＴの応用例について様々な例が挙げられるが、ここでは、例として、パーソナルコンピュータ、ワークステーション、ＰＤＡ（Personal Digital Assistance）、携帯電話（簡易型携帯電話を含む）、スマートカード等のＩＣカード、ＲＦＩＤメディア、ＡＶ（Audio Visual）機器、ＧＲＩＤ計算、ロボット等を例として挙げ、これらについて説明する。
まず、第６実施形態として、パーソナルコンピュータ及びワークステーションへのＧＴの応用について説明する。図５２に、ＧＴ１０又は１００を、パーソナルコンピュータ又はワークステーションに実装した場合のシステム構成例を示す。図５２に示すように、マザーボードにＧＴ１０又は１００が搭載されている。システムコントローラには、ＵＳＢ（Universal Serial Bus）コントローラ、ＩＤＥ（Integrated Drive Electronics）コントローラ、ＩＥＥＥ１３９４コントローラ、ビデオコントローラ及びオーディオコントローラ等が内蔵されている。
図５２において、デジタルコンテンツを記録するメモリカード、ＩＣカード、磁気ディスク、光磁気ディスク、デジタル多用途ディスク等の記録媒体には、メディアＤＲＭチップが埋め込まれている。このメディアＤＲＭチップは、ＧＴ１０又は１００上で保護されるモジュールである。このように構成することにより、特別に暗号・復号専用チップを組み込むことなく、ＧＴをコンピュータに採用することにより、ハードウェアＴＲＭと同じくらい強力に、デジタルコンテンツを保護することが可能となる。なお、図５２において、システムコントローラとしてNorth Bridgeが記載され、インタフェースとしてＵＳＢやＩＤＥが記載され、シリアルバスとしてＩＥＥＥ１３９４が記載されているが、システム構成を限定する趣旨ではない。
さらに、ソフトウェア開発・追加のみで、個人認証、TCPA、電子財布、個人情報保護、Trusted GRID ComputingなどをハードウェアTRMと同程度に強力なセキュリティレベルで実現する。
また、ＧＴ保護ソフトウェアとして作成された電子投票ソフトウェアをＰＣ等にロードする事により、ＰＣから電子投票を行うことが可能となる。また、ＧＴ保護ソフトウェアとして作成されたファイル管理ソフトウェアをＰＣ等にロードする事により、セキュアファイルシステムを構成することが可能となる。
次に、第７実施形態として、ＰＤＡや携帯電話等のモバイル機器への応用について説明する。
PCのTCPA (Trusted Computing Platform Alliance)機能についは、従来方式では別途特別なハードウェア装置をPCに接続する必要があったが、GTをＰＣに搭載すれば、そのPC上のソフトウェアで開発することのみで、この機能を実現できる。
携帯電話の端末認証機能も、同様に従来方式より強力なセキュリティ強度で実現できる。例えば、携帯電話のＳＩＭ（Subscriber Identity Module）カードを交換する機能は、ＧＴを実装する携帯電話間で保護データを交換するソフトウェアを用いる事により、より安全に実現される。
携帯電話やＰＤＡ（Personal Digital Assistance）などのモバイル製品にＧＴを適用する場合にも、特別に暗号・復号専用チップを組み込むことなく、ハードウェアTRMレベルの強力なコンテンツ保護を実現することができる。 さらに、
もちろん、ソフトウェアを追加すれば、携帯電話やＰＤＡに、個人認証機能、クレジットカード機能、プリペイドカード機能、個人情報保護、機能などを与える事ができ、これらの機能はハードウェアTRMと同等の強力なセキュリティレベルで実現される。
次に、第８実施形態としてＩＣカードやRFIDモジュールなどのセキュリティカードやモジュールへの応用について説明する。
ＩＣカードについては従来の方式ではＩＣカード内のセキュリティ機能をカスタマイズするごとにTRM化を施した個別のチップ生産を行う必要があった。しかも、個別のチップごとにハードウェアTRMの評価基準について審査を行う必要があった。
しかし、本実施形態によれば、ＧＴに保護すべきセキュリティ機能を後からファームウェアとして追加するだけで、ハードウェアTRMと同等のレベルの追加セキュリティ強度を持つＩＣカードを作成することができる。ＩＣカードのセキュリティ評価についても、ＧＴに追加したファームウェアについてのみ実施すればよい。
ＩＣカード、RFIDモジュールなどのセキュリティカードやモジュールにＧＴ１０又は１００を実装すれば、カスタマイズしたチップごとにTRM化を施す必要はなく、CPU部分のみTRM化を施しておけばよい。これで特別に暗号・復号専用チップなどを組み込むことなく、ハードウェアTRMレベルの強力なメディアDRMを実現できる。なお、ソフトウェア追加のみで個人認証機能、クレジットカード機能、プリペイドカード機能などをハードウェアTRMレベルの強力なセキュリティで実現することも可能である。
さらに、CPUと比較してGTの寿命が短い場合に、GT のコア制御部分のみを交換できることとしてもよい。なお、ＧＴコア制御とは、ＴＲＭ、ＴＬＢ等にかかわる部分をいう。但し、この場合、CPUとＩＣカードを超高速バスで接続する必要がある。
次に、第９実施形態としてＡＶ機器への応用について説明する。
ＧＴをＡＶ機器に搭載する場合、カスタマイズしたチップごとにTRM化を施す必要はなく、ＣＰＵ部分のみTRM化を施しておけばよい。これで特別に暗号・復号専用チップを組み込むことなく、ハードウェアTRMと同程度の強度を持つ強力なDRMを実現することができる。また、さらに、ＡＶ機器にＧＴに加えて、ソフトウェアを追加することにより個人認証、オンライン課金機能などをＡＶ機器に与える事も可能である。これらの機能も、ハードウェアTRMと同程度の強度で実現することができる。
続いて、第１０実施形態として、移動エージェント保護への応用について説明する。
ＧＴは、エージェントが移動先で、不正に耐えて使命を全うするための保護機能を実現することができる。つまり、ＧＴは、耐攻撃エージェントとして、VHTRMに対して安全な移動機能を提供することができる。移動エージェントを耐攻撃化することにより、第１１実施形態において説明するGRID計算へのGT適用時と同様のセキュリティ機能を実現することができる。
続いて、第１１実施形態としてＧＲＩＤ計算への応用について説明する。
ＧＲＩＤ計算やネットワークエージェントでは、従来、以下の問題があった。
１．完全性(Integrity)：GRID計算の依頼先において、依頼した実行コードが正しいCPUで、正しいデータを用いて、正しく実行されているかどうかを確認することはできなかった。そのため、依頼先ユーザがどのような不正を働いたとしても、また依頼先の計算機に実行コードを書き換えるウィルスが入ったとしても、確実に確認する手段がなかった。
２．秘匿(Confidentiality)：計算の依頼先において、コードやデータの漏洩や不正コピーが発生する怖れがあった。
３．課金(Accounting)：計算の依頼先において、課金処理の不正やCPU利用量データの改ざんが行われる怖れがあったため、課金処理や課金データの完全性を保証する必要があった。
４．上記の問題を解決するためにソフトウェアＴＲＭを用いると、処理が格段に遅くなってしまうため、処理速度を重視するGRID計算の要件には見合わなくなってしまっていた。しかも、計算機に関する特定の知識があればソフトウェアＴＲＭを容易に破ることができた。
このような問題があるため、GRID計算の依頼先として、一般のパーソナルコンピュータやワークステーションを積極的に利用することはできなかった。
しかし、ＧＴを実装したＣＰＵ上で稼動する保護コードとして、計算依頼先で実行されるソフトウェアを開発することにより、以下が実現されるため、上記問題が解決される。
１．安全なＣＰＵ（ＧＴ）の認証と実行コード改ざん防止保護
２．計算処理改ざん防止機能
３．安全な課金
４．実行コードの不正コピー、不正利用の防止
５．計算依頼先選択の最適化
６．信頼の必要なものはTRMのレベルと証明書の発効日などを指定できるようにする。
第１２実施形態として、ロボットへの応用について説明する。
人間や動物の作業や動作を肩代わりする自律型ロボットの研究やその発表が盛んであるが、その安全性についての検討もさらに重要になってくる。これまでは単なる情報処理装置としての計算機がウィルスなどにのっとられる脅威であったが、物理的に移動し、その用途によっては人間の力をも凌駕するロボットが同様の事態になることを想定する必要がある。しかし、ロボットに以下の機構を備える事により、このような問題を解決することが可能となる。
１．ロボット用の危険な部品のCPUにすべてGTを実装し、ロボット認定機関が発行した証明書が入っていることとする。
２．ロボット用のCPUは署名が確認できたコードしか実行しない機構を持つ。
３．ロボット用のCPUは証明書のないCPUとはセキュリティレベルの高い情報交換をしないこととする。
４．「殺人・傷害禁止ルール」をGT保護ソフトウェアとして実現し、認定機関が発行した証明書の秘密鍵を埋め込む。
５．「殺人・傷害禁止ルール」実現ソフトウェアをルールに従って利用したアプリケーションのみに認定機関が発行した証明書の秘密鍵を埋め込む。
６．ロボットの全入力処理と危害を与えうる動作処理のプログラムコードすべてから、このルールエンジンを利用するようにし、全体をGT保護化する。
７．プログラムコードにはかならずデジタル署名を付加して置くようにする。コードを実行する前に、署名チェックを行うようにし、実行許諾のない場合は停止する。
８．統合ソフトウェア全体をGT保護化する。
これにより、ロボットを凶悪犯化するウィルスや中央制御機能改ざんなどに対抗することが可能となる。
次に、第１３実施形態として、個人情報保護への応用について説明する。
今日、「.NET」のような万人からの信頼を獲得した個人情報管理サービスが多くの個人情報を管理しており、他のサービスは、自サービスを提供するために必要な個人情報およびそれらの統計情報程度しか得ることができない。従って、これらのサービスは、営業戦略上の顧客統計情報を獲得したり、広告メールサービスを提供したりするためには、特定の個人情報管理サービスを利用する必要がある。このような状況におけるセキュリティ上の課題は次のようなものである。
１．個人情報を回収するサービスが、サービス利用者に提示した「個人情報保護ポリシー」に従わない可能性がある。P3P（Platform for Privacy Preference：プライバシー制御のための基盤）を用いるなどにより、ポリシーを交換できたとしてもこれを強制する技術はない。
２．個人情報を扱うサービスにおいて、個人情報を処理する従業員自身が不正な個人情報漏洩を行う可能性がある。
これら問題を解決するために、本実施形態によれば、各サービスを提供するサーバのCPUにＧＴを実装し、その上でサーバに、個人情報を扱うサーバDRMソフトウェアやサーバアプリケーションをＧＴ保護コードとしてパッケージ化する。上述のように、ＧＴライセンスには、ソフトウェアを実行するプロセスに対してアクセス条件を設定する事ができる。従って、これまで、アクセス制御を外部から強制する事ができなかったサーバに対しても、アプリケーション操作におけるアクセス条件を強制する事ができるようになる。
これにより、一般消費者に対して、信頼できる個人情報管理サービスを提供することができるようになる。さらに、サービスサイトへの個人情報の積極的な提供を促し、利用者の要求に従ったサイト間の積極的な個人情報交換を可能とする事により、広告・営業活動と消費活動をより活性化することが可能となる。
次に、第１４実施形態として、ウィルス対抗手段への応用について説明する。
従来のウィルス対抗手段では、ソフトウェアのデジタル署名チェック機能とウィルスチェックソフトウェアを併用している。しかしこの方式では、最新のウィルスが、署名チェック機能またはウィルスチェックソフトが起動するまでに動作する実行ファイルを書き換えることによる攻撃に対しては無力である。
コード署名逐次確認機能を持つＧＴであれば、このようなウィルスに対抗できる。そのためには、ＣＰＵに第２実施形態に係わるＧＴを搭載し、実装コードチェックのためのソフトウェア（コードとデータ）をＧＴで保護する。そして、ブートからウィルスチェックソフトウェアが起動されるまでコード署名をＧＴ（ＣＰＵ）が逐次確認する。その上で、ウィルスチェックソフトウェアをＧＴの耐攻撃モードで実行する。ウィルスチェックソフトウェアは、各コードを実行する前にコードのハッシュを計算したり、著名を確認したりする。
これにより、新種ウィルスに対抗できなかったシステム上のセキュリティホールを壊滅することができる。なお、コード署名チェック機能については、既に説明した。
このように、ＧＴをウィルス対抗手段に採用することにより、従来の方式に比較して格段に強度の高いウィルス対抗ソフトを実現することができる。
以上、ＧＴの様々な応用例について説明した。このように、ＧＴを搭載したCPUを採用することにより、情報セキュリティ上の脅威により抑制されてきた各種先端的情報技術の社会基盤への適用が、促進されることが期待できる。例えば、次のような産業上の技術革新が期待できる。
１．コンテンツ保護の強度的及び機能的問題で積極的にPCに提供されなかったコンテンツが積極的にインターネットに流され、また各種P2P (Person to Person)技術を用いて積極的に超流通が促進される。
２．利用者認証、電子財布などへの応用により、一般の情報機器のみを利用した買い物がソフトウェアの追加だけで安全にできる。これにより、インターネットでのお買い物を恐れていた利用者も買い物をするようになる。売る側も安心してサイトに品物を置いて販売できるようになり、市場がひろがり、グローバルなインターネット販売ビジネスを促進する。
３．強力な個人情報保護機能の実現により、個人情報を安心して積極的に売り込むことによるインターネットを介した広告活動と消費活動のさらなる活性化を期待できる。
４．見ず知らずのCPUの利用を恐れたり、無償でCPUを貸し出す不公平感により積極的に計算パワーを提供できなかったりしていたGRID計算を積極的に活用できるようになる。これにより、一般の共用CPUの利用効率が10倍程度以上には向上すると考えられる。従って、単純に計算すれば、各コンピュータの処理速度が、ローカルなCPUだけで計算していた時に比較し、平均して10倍程度以上の速さが期待できる。あるいは、必要な計算に世界のCPU利用を集中できるようになる。
５．ソフトウェア部品の「超流通」とネットワークを越えた自律協調型分散開発を目標とする「超流用(Superappropriation)」を強力なウィルス対抗とモジュール利用料P2P課金のセキュリティで促進する。
６．GTによる安全性の保障が、強力な実用ロボットの社会への浸透を積極的に促進させる。
さらに将来、GTはいつでもどこでもだれにでも利用できる安全な汎用計算処理基盤として、高信頼ユービキタスコンピューティング（Trusted ubiquitous computing）のインフラにもなることができる。
以上、本発明の実施形態について説明したが、本発明は上述した実施形態に限定されるものではなく、他の様々な変更が可能である。
基本パッケージソフトウェアの利用関係モデルを示す図である。 プログラミングモデルを示す図である。 第１実施形態に係わるＧＴを実現するＣＰＵの構成図である。 ＴＲＢ内の各行のフィールドの構成を示す図である。 ＴＬＢ内の各行の拡張フィールドの構成を示す図である。 ＦＲアーキテクチャの場合について、ＴＬＢ内のフィールドの値とアクセス権限の対応を示す図である。 インテルアーキテクチャの場合について、ＴＬＢ内のフィールドの値とアクセス権限の対応を示す図である。 暗号化キーテーブルの構造を示す図である。 署名方式の一例を示す図である。 ＴＲＢ、ＴＬＢ、暗号化キーテーブル及びページテーブルの関係を示す図である。 ＴＲＳＳフラグを格納するフィールドの構成の一例を示す図である。 ＲＡＣＴの各行のフィールド構成の一例を示す図である。 ＲＳＳＬレジスタのフィールド構成の一例を示す図である。 一般の仮想セグメント空間と耐攻撃セグメント空間との間でコード実行プロセスからデータにアクセスする際のポリシーを示す図である。 ＧＴ１０上で保護プロセスが動作する様子を示す図である。 ＧＴの認証を説明する図である。 ＧＴライセンスに設定可能なアクセス権と被許諾権限を示す図である。 上述のＧＴ認証処理の一部を示すフローチャートである。 超流通ファイル形式として用いる場合の保護コード実行形式の一例を示す図である。 保護コードのロードと実行手順、及び保護データの退避と維持について説明する図である。 保護コードを実行する際の保護コードを記録するページへのアクセス制御について説明する図である。 プロセッサコアによって行われる保護コード及び保護データへのアクセス制御を示すフローチャートである。 例外・割り込み処理にかかわるフローチャートである。 命令処理にかかわるフローチャートである。 保護コードファイルを起動する際における、ＯＳカーネル６０及びＧＴの動作について説明する図である。 保護コードを実行するプロセスから保護データをアクセスするメカニズムについて説明する図である。 親プロセスから他の保護コードモジュールを呼び出す際に行う手順について説明する図である。 親プロセスから他の保護コードモジュールを呼び出す際にＯＳカーネルが行う処理のフローチャートを示す。 耐攻撃コード復帰例外処理による封印レジスタ不正アクセス防止のためのシーケンス例を示す図である。 ＯＳカーネルによる保護コンテキスト切り替え時のシーケンスの一例を示す図である。 保護データ領域の共有の一例を示す図である。 モジュールの認証、並びに、保護データ復号鍵共有手順の設定手順について説明する図である。 耐攻撃領域共有システムコールを呼び出した際の処理を示すフローチャートである。 ＤＲＭソフトウェアモジュールの構築モデルの一例を示す図である。 メディアＤＲＭによって行われる処理を示すフローチャート（その１）である。 メディアＤＲＭによって行われる処理を示すフローチャート（その２）である。 デコーダＤＲＭによって行われる処理を示すフローチャート（その１）である。 デコーダＤＲＭによって行われる処理を示すフローチャート（その２）である。 デコーダＤＲＭによって行われる処理を示すフローチャート（その３）である。 再生アプリケーションによって行われる処理を示すフローチャートである。 秘密情報を維持・管理する方式を示す図である。 ライセンス管理のためのメモリアクセスの方式を示す図である。 第２実施形態に係わるＧＴを実現するＣＰＵの構成図である。 第２実施形態におけるブロックの構造を示す図である。 ebimが４である場合のブロックの構造を示す図である。 保護ブロックセレクタによって行われる処理を示すフローチャートである。 ハッシュエンジンによって行われる処理を示すフローチャートである。 ハッシュチェッカによって行われる処理を示すフローチャートである。 ＮＯＰの処理について説明する図である。 マルチＣＰＵの構成図である。 コードオブジェクトから保護コード実行形式を出力するツール群の例を示す図である。 ＧＴを、パーソナルコンピュータ又はワークステーションに実装した場合のシステム構成例を示す図である。

Claims (36)

  1. プログラムを実行する中央演算装置であって、
    ブロックの暗号化及び暗号化ブロックの復号を行う暗号手段とキャッシュを備え、
    前記中央演算装置には、第１の秘密鍵が秘密裏に隠され、
    前記暗号手段は、前記第１の秘密鍵と対になった公開鍵を用いて暗号化された第１のプログラムの第１のライセンスを、前記第１の秘密鍵を用いて復号することにより、前記第１のライセンスから前記第１のプログラムを構成する暗号化ブロックを復号するためのコード復号鍵を取得し、前記第１のプログラムの実行によって前記キャッシュ内のデータをメモリ内に記録する際には、該データを該復号鍵を用いて暗号化した後、該メモリ領域に記録する、
    ことを特徴とする中央演算装置。
  2. 前記暗号手段は、前記第１のプログラムを構成する暗号化ブロックがメモリ領域から前記キャッシュに出力される際に、キャッシュ単位で前記暗号化ブロックを復号する、
    ことを特徴とする請求項１に記載の中央演算装置。
  3. ユーザが参照したり改ざんしたりすることができない耐攻撃バッファを更に備え、
    前記コード復号鍵は、前記耐攻撃バッファに記録される、
    ことを特徴とする請求項１又は２に記載の中央演算装置。
  4. 前記第１のライセンスは、前記第１のプログラムの実行プロセスがメモリ領域にアクセスする際のアクセス条件を含み、
    前記中央演算装置は、前記第１のプログラムを構成する暗号化ブロックが記録される前記メモリ領域のアドレスと前記メモリ領域へのアクセス条件とを記録するＴＬＢ（Translation Look aside Buffer）と、
    メモリ管理手段と、
    プロセッサコアを更に備え、
    前記ＴＬＢと前記耐攻撃バッファはリンクされ、
    前記メモリ管理手段は、暗号化ブロックを記録するメモリ領域のアドレスに基づいて前記ＴＬＢから前記メモリ領域へのアクセス条件を取得し、さらに、前記耐攻撃バッファから、前記メモリ領域に対応する前記コード復号鍵を取得し、
    前記プロセッサコアは、前記メモリ管理手段が取得した前記アクセス条件に基づいて、前記実行プロセスから前記メモリ領域へのアクセスを実行することが許可されているか否か判定し、前記メモリ領域へのアクセスを実行する事が許可されていると判定した場合、前記実行プロセスから前記メモリ領域へのアクセスを実行し、
    前記暗号手段は、前記メモリ管理手段が取得した前記コード復号鍵を用いて前記メモリ領域内の前記暗号化ブロックを復号して得られたコードを前記キャッシュに書き込む、
    ことを特徴とする請求項３に記載の中央演算装置。
  5. 前記第１のプログラムの実行プロセスからアクセスされるメモリ領域が、第１のメモリ領域から第２のメモリ領域に切り替わった場合、
    前記メモリ管理手段は、さらに、前記耐攻撃バッファから取得された前記第１のメモリ領域に対応するコード復号鍵と、前記第２のメモリ領域に対応するコード復号鍵とが一致するか否か判定し、一致すると判定した場合、前記実行プロセスから前記第２のメモリ領域へのアクセスを実行し、一致しないと判定した場合、前記実行プロセスから前記第２のメモリ領域へのアクセスを実行しない、
    ことを特徴とする請求項４に記載の中央演算装置。
  6. 前記第１のライセンスは、前記第１のプログラムに埋め込まれている、
    ことを特徴とする請求項１乃至５のいずれかに記載の中央演算装置。
  7. 前記耐攻撃バッファには前記コード復号鍵ごとに、異なるデータ暗号鍵が記録されており、
    前記暗号手段は、前記キャッシュ内のデータを前記メモリ領域に記録する際には、前記データを前記データ暗号鍵を用いて暗号化した後、前記ＴＬＢによって前記データ暗号鍵に対応付けられた前記メモリ領域に記録し、前記メモリ領域内の暗号化されたデータを読み出す際には、読み出された前記データを前記データ暗号鍵を用いて復号した後、前記キャッシュに書き込む、
    ことを特徴とする請求項４乃至６のいずれかに記載の中央演算装置。
  8. 第１のコードを実行することにより得られたデータを第２のコードで利用する場合、前記プロセッサコアは、前記データを記録するメモリ領域へのアクセス権を前記第２のコードに与えるように前記ＴＬＢを設定し、且つ、前記データを暗号化するためのデータ暗号鍵を、前記第２のコードが前記データを前記メモリ領域から読み出す際に使用するように前記ＴＬＢ及び前記耐攻撃バッファを設定する、
    ことを特徴とする請求項７に記載の中央演算装置。
  9. レジスタと、
    レジスタへのアクセス制御を行うためのレジスタアクセス制御テーブルと、を更に備え、
    前記プロセッサコアは、前記レジスタアクセス制御テーブル内の封印フラグを用いて、前記レジスタの封印及び解放を制御する、
    ことを特徴とする請求項４乃至８のいずれかに記載の中央演算装置。
  10. ＴＬＢの内容を外部記憶装置内のページテーブルに記録する際には、前記暗号手段は、記録する内容に署名を付与し、
    前記ページテーブルの内容を前記ＴＬＢに取り込む前には、前記暗号手段は、前記署名が正しいことを確認する、
    ことを特徴とする請求項４乃至９のいずれかに記載の中央演算装置。
  11. 前記耐攻撃バッファの内容を外部記憶装置内の暗号化キーテーブルに記録する際には、前記暗号手段は、記録する内容を暗号化する、
    ことを特徴とする請求項３乃至１０のいずれかに記載の中央演算装置。
  12. 前記中央演算装置は、他の中央演算装置と接続され、
    前記中央演算装置は、前記他の中央演算装置と相互に認証を行う事にことによりセッション鍵を取得し、前記中央演算装置の前記暗号手段は、前記セッション鍵を用いて前記中央演算装置の前記キャッシュの内容を暗号化して、前記他の中央演算装置に同期転送する、
    ことを特徴とする請求項１乃至１１のいずれかに記載の中央演算装置。
  13. 前記暗号手段は、前記第１のプログラムを実行する前に、第２のプログラムに付加された前記第２のライセンスを前記公開鍵を用いて復号する事により第２の秘密鍵を暗号化する際に用いられた秘密鍵暗号鍵を取得し、さらに、前記取得された秘密鍵暗号鍵を用いて前記第２の秘密鍵を復号する、
    ことを特徴とする請求項１乃至請求項１２のいずれかに記載の中央演算装置。
  14. 前記第２のライセンスには、前記第１のプログラムの実行プロセスから読み出しのみ可であることを示すアクセス条件が付加されており、
    前記第２の秘密鍵は、前記第１のプログラムの実行プロセスからの読み出しのみ可能である、
    ことを特徴とする請求項１３に記載の中央演算装置。
  15. 前記第２の秘密鍵は、データ暗号鍵によって暗号化されてメモリ領域に記録される、
    ことを特徴とする請求項１３又は１４に記載の中央演算装置。
  16. 前記耐攻撃バッファは、さらに、
    対応する前記耐攻撃バッファ内の情報を前記耐攻撃バッファ外に出力しても良いか否かを示す外部出力禁止情報と、
    対応する情報をキャッシュ外に出力しても良いか否かを示すキャッシュロック情報とを記録し、
    前記外部出力禁止情報及び前記キャッシュロック情報に基づいて、第１のプログラム及び他のプログラムとの間における前記第１のライセンスの移動は管理される、
    ことを特徴とする請求項３乃至１５のいずれかに記載の中央演算装置。
  17. 前第１のプログラムは、トラステッドコンピューティングモジュールである、
    ことを特徴とする請求項１乃至１６のいずれかに記載の中央演算装置。
  18. 前記第１のプログラムは、前記中央演算装置に電子財布を実現させるプログラムである、
    ことを特徴とする請求項１乃至１６のいずれかに記載の中央演算装置。
  19. 前記第１のプログラムは、個人情報を扱うプログラムである、
    ことを特徴とする請求項１乃至１６のいずれかに記載の中央演算装置。
  20. 前記第１のプログラムは、前記中央演算装置の実装コードのウィルスチェックプログラムである、
    ことを特徴とする請求項１乃至１６のいずれかに記載の中央演算装置。
  21. 前記第１のプログラムは複数の中央演算装置間を移動する移動エージェントである、
    ことを特徴とする請求項１乃至１６のいずれかに記載の中央演算装置。
  22. 前記第１のプログラムを構成するブロックは、前記ブロックのハッシュ値の確認が必要であるか否かを示すハッシュ確認要否情報を含み、
    前記ハッシュ確認要否情報に基づいて、前記ブロックのハッシュ値を算出し、前記ブロックに付加するハッシュ手段と、
    前記ハッシュ確認要否情報に基づいて、前記ブロックの前記ハッシュ値を確認するハッシュ確認手段と、
    を更に備えることを特徴とする請求項１乃至２１のいずれかに記載の中央演算装置。
  23. 前記第１のプログラムを構成するブロックは、前記ブロックが保護を必要とするか否かを示す暗号化要否情報を含み、
    前記暗号化要否情報に基づいて、前記ブロックを前記暗号手段に出力するか、そのままキャッシュ又はメモリ領域に出力するか判定する保護ブロック選択手段を、
    更に備えることを特徴とする請求項１乃至２２のいずれかに記載の中央演算装置。
  24. 前記第１のプログラムの実行ファイルのヘッダは、前記第１のプログラムを構成するブロックの構成を示す暗号化ブロックビットマップを含み、
    前記暗号化ブロックビットマップに基づいて、前記ブロックを前記暗号手段に出力するか、そのままキャッシュ又はメモリ領域に出力するか判定する保護ブロック選択手段を、
    更に含むことを特徴とする請求項１乃至２２のいずれかに記載の中央演算装置。
  25. 前記第１のプログラムのコードの先頭は、前記第１のプログラムを構成する複数のブロックが、平文ブロックと暗号化ブロックの組合せの繰り返しであることを指定し、且つ、前記組合せにおいて平文ブロックが連続する数及び暗号化ブロックが連続する数を指定するコードであり、
    前記コードを実行することにより、前記プロセッサコアは、前記ブロックを前記暗号手段に出力するか、そのままキャッシュ又はメモリ領域に出力するか判定する、
    更に含むことを特徴とする請求項１乃至２２のいずれかに記載の中央演算装置。
  26. 前記キャッシュとメモリの間に、
    前記暗号手段を介するキャッシュラインと、
    前記暗号手段を介さないキャッシュラインと、
    を更に備えることを特徴とする請求項２乃至２５のいずれかに記載の中央演算装置。
  27. 請求項１乃至２６のいずれかに記載の中央演算装置を有することを特徴とするコンピュータ。
  28. 請求項１乃至２６のいずれかに記載の中央演算装置を有することを特徴とするＩＣカード。
  29. 前記第１のプログラムは、前記ＩＣカードのセキュリティ機能を実現するプログラムである、
    ことを特徴とする請求項２８に記載のＩＣカード。
  30. 前記中央演算装置は、ロボットに搭載され、
    前記第１のプログラムは、前記ロボットを制御する制御プログラムである、
    ことを特徴とする請求項１乃至２６のいずれかに記載の中央演算装置。
  31. 中央演算装置に保護プログラムを実行する許諾を与える制御を行わせるプログラムであって、
    前記保護プログラムは、コード暗号鍵によって暗号化され、
    前記保護プログラムに対応して、前記コード暗号鍵を含み、且つ、前記中央演算装置に秘密裏に備えられた秘密鍵と対になる公開鍵によって暗号化されたライセンスが存在し、
    前記中央演算装置が前記保護プログラムを実行する前に、前記ライセンスを前記中央演算装置に投入し、
    前記中央演算装置に備えられた暗号手段に、前記秘密鍵を用いて前記ライセンスを復号することにより、前記ライセンスから前記コード暗号鍵を取得させ、
    前記暗号手段に、前記コード暗号鍵を用いて前記保護プログラムを復号させ、
    前記保護プログラムの実行により前記中央演算装置に備えられたキャッシュ内のデータをメモリ内に記録する際には、該データを該復号鍵を用いて暗号化した後、該メモリ領域に記録する、
    ことを含む処理を前記中央演算処理装置に実行させるプログラム。
  32. 中央演算装置に、保護プログラムを実行する許諾を与える制御を行わせるプログラムを記録する記録装置であって、
    前記保護プログラムは、コード暗号鍵によって暗号化され、
    前記保護プログラムに対応して、前記コード暗号鍵を含み、且つ、前記中央演算装置に秘密裏に備えられた秘密鍵と対になる公開鍵によって暗号化されたライセンスが存在し、
    前記中央演算装置が前記保護プログラムを実行する前に、前記ライセンスを前記中央演算装置に投入し、
    前記中央演算装置に備えら得た暗号手段に、前記秘密鍵を用いて前記ライセンスを復号することにより、前記ライセンスから前記コード暗号鍵を取得させ、
    前記暗号手段に、前記コード暗号鍵を用いて前記保護プログラムを復号させ、
    前記保護プログラムの実行により前記中央演算装置に備えられたキャッシュ内のデータをメモリ内に記録する際には、該データを該復号鍵を用いて暗号化した後、該メモリ領域に記録する、
    ことを含む処理を前記中央演算装置に実行させるプログラムを記録する記録装置。
  33. 中央演算装置に、保護プログラムを実行する許諾を与えるプログラム実行許諾方法であって、
    前記保護プログラムは、コード暗号鍵によって暗号化され、
    前記保護プログラムに対応して、前記コード暗号鍵を含み、且つ、前記中央演算装置に備えられた秘密鍵と対になる公開鍵によって暗号化されたライセンスが存在し、
    前記中央演算装置は、前記保護プログラムを実行する前に、前記ライセンスを取得し、
    前記中央演算装置は、前記秘密鍵を用いて前記ライセンスを復号することにより、前記ライセンスから前記コード暗号鍵を取得し、
    前記中央演算装置は、前記コード暗号鍵を用いて前記保護プログラムを復号し、
    前記中央演算装置は、前記保護プログラムの実行により前記中央演算装置に備えられたキャッシュ内のデータをメモリ内に記録する際には、該データを該復号鍵を用いて暗号化した後、該メモリ領域に記録する、
    ことを含むことを特徴とするプログラム実行許諾方法。
  34. コンピュータにおいて実行されるプログラムコードであって、
    前記プログラムコードは、コード暗号鍵によって暗号化され、
    前記プログラムコードに対応して、前記コード暗号鍵を含み、且つ、前記プログラムコードを実行するべきコンピュータに備えられた中央演算装置が秘密裏に備える秘密鍵と対になる公開鍵によって暗号化されたライセンスが存在し、
    前記ライセンスは前記プログラムコードが実行される前に前記中央演算装置に投入され、
    前記中央演算装置によって前記秘密鍵を用いて前記ライセンスが復号され、
    前記プログラムコードは、前記ライセンスから取得された前記コード暗号鍵を用いて、前記中央演算装置によって復号され、
    前記プログラムコードは、前記中央演算装置に備えられたキャッシュ内からメモリ内に記録される際には、前記コード暗号鍵を用いて暗号化された後、該メモリ領域に記録される、
    ことを特徴とするプログラムコード。
  35. コンピュータにおいて実行されるプログラムコードを記録する、前記コンピュータによって読み取り可能な記録媒体であって、
    前記プログラムコードは、コード暗号鍵によって暗号化され、
    前記プログラムコードに対応して、前記コード暗号鍵を含み、且つ、前記プログラムコードを実行するべきコンピュータに備えられた中央演算装置が秘密裏に備える秘密鍵と対になる公開鍵によって暗号化されたライセンスが存在し、
    前記ライセンスは前記プログラムコードが実行される前に前記中央演算装置に投入され、
    前記中央演算装置によって前記秘密鍵を用いて前記ライセンスが復号され、
    前記プログラムコードは、前記ライセンスから取得された前記コード暗号鍵を用いて、前記中央演算装置によって復号され、
    前記プログラムコードは、前記中央演算装置に備えられたキャッシュ内からメモリ内に記録される際には、前記コード暗号鍵を用いて暗号化された後、該メモリ領域に記録される、
    ことを特徴とするプログラムコードを記録する記録媒体。
  36. 秘密裏に隠された秘密鍵と、暗号化及び復号を行う暗号手段とキャッシュを備える中央演算装置を備えるコンピュータにおいて実行されるプログラムを生成するプログラム生成装置であって、
    コードオブジェクトを入力する入力手段と、
    入力された前記コードオブジェクトを複数のブロックに分割し、それぞれのブロックにＮＯＰ命令を追加するリンカ前処理手段と、
    アドレス解決を行うリンカ手段と、
    各ブロックをコード暗号鍵を用いて暗号化することにより保護コード実行形式を生成する保護コード実行形式生成手段と、
    前記コード暗号鍵を含み、前記秘密鍵と対になる公開鍵によって暗号化されたライセンスを生成するライセンス生成手段とを備え、
    前記ライセンスは、前記コンピュータが前記保護コード実行形式を実行する前に前記中央演算装置に投入され、前記暗号手段によって前記秘密鍵を用いて復号され、
    前記保護コード実行形式は、前記ライセンスから取得された前記コード暗号鍵を用いて、前記暗号手段によって復号され、
    前記保護コード実行形式は、前記キャッシュ内からメモリ内に記録される際には、前記コード暗号鍵を用いて暗号化された後、該メモリ領域に記録される、
    ことを特徴とするプログラム生成装置。
JP2004519192A 2002-07-09 2002-07-09 開放型汎用耐攻撃ｃｐｕ及びその応用システム Expired - Fee Related JP4073913B2 (ja)

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/JP2002/006955 WO2004006075A1 (ja) 2002-07-09 2002-07-09 開放型汎用耐攻撃ｃｐｕ及びその応用システム

Publications (2)

Publication Number Publication Date
JPWO2004006075A1 JPWO2004006075A1 (ja) 2005-11-04
JP4073913B2 true JP4073913B2 (ja) 2008-04-09

Family

ID=30022632

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2004519192A Expired - Fee Related JP4073913B2 (ja) 2002-07-09 2002-07-09 開放型汎用耐攻撃ｃｐｕ及びその応用システム

Country Status (6)

Country Link
US (1) US20040093505A1 (ja)
EP (1) EP1542112A4 (ja)
JP (1) JP4073913B2 (ja)
CN (1) CN100354786C (ja)
AU (1) AU2002346316A1 (ja)
WO (1) WO2004006075A1 (ja)

Families Citing this family (62)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN1276363C (zh) * 2002-11-13 2006-09-20 深圳市朗科科技有限公司 借助半导体存储装置实现数据安全存储和算法存储的方法
JP3880933B2 (ja) * 2003-01-21 2007-02-14 株式会社東芝 耐タンパマイクロプロセッサ及びキャッシュメモリ搭載プロセッサによるデータアクセス制御方法
JP4338989B2 (ja) * 2003-02-20 2009-10-07 パナソニック株式会社 メモリデバイス
JP4624732B2 (ja) * 2003-07-16 2011-02-02 パナソニック株式会社 アクセス方法
US8060756B2 (en) * 2003-08-07 2011-11-15 Rao G R Mohan Data security and digital rights management system
US7500264B1 (en) * 2004-04-08 2009-03-03 Cisco Technology, Inc. Use of packet hashes to prevent TCP retransmit overwrite attacks
US7475431B2 (en) * 2004-06-10 2009-01-06 International Business Machines Corporation Using security levels to improve permission checking performance and manageability
CN101057434A (zh) * 2004-11-10 2007-10-17 理查德·H·塞林弗罗因德 光学机器的锁定方法和系统
JP3810425B2 (ja) * 2004-12-16 2006-08-16 松下電器産業株式会社 改竄検出用データ生成方法、および改竄検出方法及び装置
US7757301B2 (en) * 2004-12-21 2010-07-13 Seagate Technology Llc Security hardened disc drive
US7818585B2 (en) * 2004-12-22 2010-10-19 Sap Aktiengesellschaft Secure license management
US7849512B2 (en) * 2005-03-21 2010-12-07 Fortressware, Inc. Method and system to create secure virtual project room
JP4667108B2 (ja) * 2005-04-11 2011-04-06 パナソニック株式会社 データ処理装置
JP4698285B2 (ja) * 2005-05-19 2011-06-08 富士通株式会社 情報処理装置、情報処理方法及びコンピュータプログラム
JP2007158618A (ja) * 2005-12-02 2007-06-21 Ricoh Co Ltd 画像処理装置、暗号モジュールのプロセス化方法
US8234505B2 (en) * 2006-01-20 2012-07-31 Seagate Technology Llc Encryption key in a storage system
US8214296B2 (en) * 2006-02-14 2012-07-03 Microsoft Corporation Disaggregated secure execution environment
JP4795812B2 (ja) 2006-02-22 2011-10-19 富士通セミコンダクター株式会社 セキュアプロセッサ
US8020001B2 (en) * 2006-02-23 2011-09-13 Qualcomm Incorporated Trusted code groups
JP2007304847A (ja) * 2006-05-11 2007-11-22 Megachips Lsi Solutions Inc メモリ装置
US8788829B2 (en) 2006-08-17 2014-07-22 Aol Inc. System and method for interapplication communications
US9860274B2 (en) 2006-09-13 2018-01-02 Sophos Limited Policy management
US20080244275A1 (en) * 2007-03-30 2008-10-02 Motorola, Inc. Instruction Transform for the Prevention and Propagation of Unauthorized Code Injection
US20100088528A1 (en) * 2007-05-03 2010-04-08 Radu Sion Method and apparatus for tamper-proof wirte-once-read-many computer storage
JP5052287B2 (ja) * 2007-10-23 2012-10-17 株式会社Ｉｈｉ ロボット不正使用防止装置およびロボット不正使用防止方法
TWI371691B (en) * 2007-12-16 2012-09-01 Infortrend Technology Inc Storage controller for handling data stream and method thereof
US8438385B2 (en) * 2008-03-13 2013-05-07 Fujitsu Limited Method and apparatus for identity verification
KR101511380B1 (ko) * 2008-05-22 2015-04-10 삼성전자주식회사 Ｓｒｍ 장치간의 안전 정보 교환 시스템 및 방법
GB0810695D0 (en) * 2008-06-12 2008-07-16 Metaforic Ltd Anti-tampering MMU defence
US20090313171A1 (en) * 2008-06-17 2009-12-17 Microsoft Corporation Electronic transaction verification
CN101587523B (zh) * 2009-07-02 2012-04-18 飞天诚信科技股份有限公司 保护软件的方法和装置
US8799411B2 (en) 2010-05-28 2014-08-05 Arvato Digital Services Canada, Inc. Method and apparatus for providing enhanced streaming content delivery with multi-archive support using secure download manager and content-indifferent decoding
US8856504B2 (en) * 2010-06-07 2014-10-07 Cisco Technology, Inc. Secure virtual machine bootstrap in untrusted cloud infrastructures
JP5316592B2 (ja) * 2011-06-09 2013-10-16 富士通セミコンダクター株式会社 セキュアプロセッサ用プログラム
US20120331303A1 (en) * 2011-06-23 2012-12-27 Andersson Jonathan E Method and system for preventing execution of malware
US9009855B2 (en) * 2011-09-11 2015-04-14 Microsoft Technology Licensing, Llc Generating developer license to execute developer application
WO2013077788A1 (en) * 2011-11-23 2013-05-30 Gunnebo Gateway Ab Method of booting a control unit in an electronic article surveillance system and control unit forming part of such a system
JP2013179453A (ja) * 2012-02-28 2013-09-09 Nippon Telegr & Teleph Corp <Ntt> 計算機システムおよび計算方法
US10515021B2 (en) * 2012-03-09 2019-12-24 Sony Corporation Information processing to set usage permission in content
EP2653992A1 (en) * 2012-04-17 2013-10-23 Itron, Inc. Microcontroller configured for external memory decryption
US20130298155A1 (en) * 2012-05-03 2013-11-07 Rawllin International Inc. Video personal identification code for video on demand services
WO2013175368A1 (en) * 2012-05-25 2013-11-28 Koninklijke Philips N.V. Method, system and device for protection against reverse engineering and/or tampering with programs
US9275223B2 (en) 2012-10-19 2016-03-01 Mcafee, Inc. Real-time module protection
GB2508052A (en) * 2012-11-18 2014-05-21 Nds Ltd Glitch resistant device
US8995658B2 (en) * 2013-02-13 2015-03-31 Honeywell International Inc. Physics-based key generation
US9430384B2 (en) * 2013-03-31 2016-08-30 Intel Corporation Instructions and logic to provide advanced paging capabilities for secure enclave page caches
CN103607279B (zh) * 2013-11-14 2017-01-04 中国科学院数据与通信保护研究教育中心 基于多核处理器的密钥保护方法及系统
US20150269357A1 (en) * 2014-03-20 2015-09-24 Adobe Systems Incorporated Method and apparatus for digital rights management that is file type and viewer application agnostic
US10223289B2 (en) 2015-07-07 2019-03-05 Qualcomm Incorporated Secure handling of memory caches and cached software module identities for a method to isolate software modules by means of controlled encryption key management
JP6872129B2 (ja) * 2015-11-27 2021-05-19 ソニーグループ株式会社 情報処理装置、情報処理方法、受信装置、および受信方法
US10565354B2 (en) * 2017-04-07 2020-02-18 Intel Corporation Apparatus and method for protecting content in virtualized and graphics environments
FR3069935A1 (fr) * 2017-08-01 2019-02-08 Maxim Integrated Products, Inc. Dispositifs et procedes de protection de propriete intellectuelle de logiciel pour des plates-formes integrees
US11093624B2 (en) 2017-09-12 2021-08-17 Sophos Limited Providing process data to a data recorder
US11151266B2 (en) * 2017-12-06 2021-10-19 International Business Machines Corporation Secure data storage and access during transition operations
US10592697B1 (en) * 2017-12-12 2020-03-17 John Almeida Virus immune computer system and method
CN108920188B (zh) * 2018-07-03 2021-04-27 中国人民解放军国防科技大学 一种扩展寄存器堆的方法及装置
JP7368184B2 (ja) * 2019-10-31 2023-10-24 株式会社野村総合研究所 リスク管理支援装置
US11755476B2 (en) 2020-04-13 2023-09-12 SK Hynix Inc. Memory controller, storage device including the memory controller, and method of operating the memory controller and the storage device
KR102435253B1 (ko) * 2020-06-30 2022-08-24 에스케이하이닉스 주식회사 메모리 컨트롤러 및 그 동작 방법
JPWO2022085420A1 (ja) * 2020-10-19 2022-04-28
US11409846B2 (en) * 2021-01-14 2022-08-09 Safelishare, Inc. User controlled trusted and isolated computing environments
CN114785514B (zh) * 2022-03-23 2023-11-14 国网上海能源互联网研究院有限公司 一种用于工业物联化终端应用许可授权的方法及系统

Family Cites Families (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH0383132A (ja) * 1989-08-28 1991-04-09 Fujitsu Ltd ソフトウェア保護制御方式
JP2000260121A (ja) * 1999-03-05 2000-09-22 Toshiba Corp 情報再生装置および情報記録装置
US7225333B2 (en) * 1999-03-27 2007-05-29 Microsoft Corporation Secure processor architecture for use with a digital rights management (DRM) system on a computing device
JP4226760B2 (ja) * 2000-05-08 2009-02-18 株式会社東芝 マイクロプロセッサ、これを用いたマルチタスク実行方法、およびマルチレッド実行方法
JP3801833B2 (ja) * 2000-02-14 2006-07-26 株式会社東芝 マイクロプロセッサ
US6983374B2 (en) * 2000-02-14 2006-01-03 Kabushiki Kaisha Toshiba Tamper resistant microprocessor

Also Published As

Publication number Publication date
EP1542112A1 (en) 2005-06-15
CN1668990A (zh) 2005-09-14
US20040093505A1 (en) 2004-05-13
JPWO2004006075A1 (ja) 2005-11-04
CN100354786C (zh) 2007-12-12
EP1542112A4 (en) 2008-04-09
WO2004006075A1 (ja) 2004-01-15
AU2002346316A1 (en) 2004-01-23

Similar Documents

Publication Publication Date Title
JP4073913B2 (ja) 開放型汎用耐攻撃ｃｐｕ及びその応用システム
US10303901B2 (en) Secure processor and a program for a secure processor
CN103221961B (zh) 包括用于保护多用户敏感代码和数据的架构的方法和装置
JP4498735B2 (ja) オペレーティングシステムおよびカスタマイズされた制御プログラムとインタフェースする安全なマシンプラットフォーム
JP4689946B2 (ja) 安全なデータを使用して情報処理を実行するシステム
US20050060568A1 (en) Controlling access to data
JP4689945B2 (ja) リソースアクセス方法
US8065521B2 (en) Secure processor architecture for use with a digital rights management (DRM) system on a computing device
US7805375B2 (en) Digital license migration from first platform to second platform
JP4822646B2 (ja) 分離実行環境で使用するためのキー階層の生成
EP1686504B1 (en) Flexible licensing architecture in content rights management systems
Dwoskin et al. Hardware-rooted trust for secure key management and transient trust
US20050060561A1 (en) Protection of data
JP5636371B2 (ja) 汎用コンピューティングデバイスにおけるコード実行制御および再帰的セキュリティプロトコルでのコード実行制御のための方法およびシステム
US8307215B2 (en) System and method for an autonomous software protection device
JP2015511050A (ja) プロセス作業セット隔離のための方法およびシステム
US20070074050A1 (en) System and method for software and data copy protection
US7603566B2 (en) Authenticated process switching on a microprocessor
KR100755708B1 (ko) 임시 라이센스를 사용하여 컨텐츠를 임시로 사용하는 방법및 장치
KR20200099041A (ko) 블록체인 기반 콘텐츠 이용 권한 관리 장치 및 방법
US20190044709A1 (en) Incorporating software date information into a key exchange protocol to reduce software tampering
Focardi et al. A formally verified configuration for hardware security modules in the cloud
JP2009064126A (ja) Ｉｃカードシステム、その端末装置、プログラム
Bove Secure Services for Standard RISC-V Architectures
US11748459B2 (en) Reducing software release date tampering by incorporating software release date information into a key exchange protocol

Legal Events

Date Code Title Description
A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20071002

A521 Written amendment

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20071203

TRDD Decision of grant or rejection written
A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

Effective date: 20080122

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20080123

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20110201

Year of fee payment: 3

R150 Certificate of patent or registration of utility model

Free format text: JAPANESE INTERMEDIATE CODE: R150

Ref document number: 4073913

Country of ref document: JP

Free format text: JAPANESE INTERMEDIATE CODE: R150

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20110201

Year of fee payment: 3

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20120201

Year of fee payment: 4

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20130201

Year of fee payment: 5

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20140201

Year of fee payment: 6

LAPS Cancellation because of no payment of annual fees