JP2003085143A

JP2003085143A - パスワード管理システム、パスワード管理方法、および情報処理装置、並びにコンピュータ・プログラム

Info

Publication number: JP2003085143A
Application number: JP2001274745A
Authority: JP
Inventors: Makoto Oka; 誠岡; Yoshito Ishibashi; 義人石橋; Hiroshi Abe; 博阿部; Noboru Shimada; 昇島田; Kenji Yoshino; 賢治吉野; Takanori Saneto; 隆則實藤; Tetsuo Sasaki; 鉄雄佐々木; Shinya Kimura; 真也木村; Akihiro Hokimoto; 晃弘保木本
Original assignee: Sony Corp
Current assignee: Sony Corp
Priority date: 2001-09-11
Filing date: 2001-09-11
Publication date: 2003-03-20

Abstract

(57)【要約】【課題】複数のパスワードの管理をセキュアにかつ効
率的に実行可能としたパスワード管理システムを実現す
る。【解決手段】情報処理装置において設定されるパスワ
ードの上位パスワードとしてマスターパスワードを設定
し、各パスワードのリセットまたは変更処理時にマスタ
ーパスワードの一致検証を行なう。マスターパスワード
は、デバイスＩＤに、マスターキーを適用した暗号処理
によって生成され、メモリに格納することなく、一致検
証処理の実行に際して生成する。またマスターパスワー
ドの管理を実行するサポートセンタを設定し、マスター
パスワード再発行処理を実行する構成としたので、ユー
ザにおけるパスワード管理の負担の軽減が可能となる。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】本発明は、パスワード管理シ
ステム、パスワード管理方法、および情報処理装置、並
びにコンピュータ・プログラムに関する。特に、情報処
理装置におけるデータ処理の開始条件として設定される
パスワードの管理を、セキュアにかつ効率的に実行する
ことを可能としたパスワード管理システム、パスワード
管理方法、および情報処理装置、並びにコンピュータ・
プログラムに関する。

【０００２】

【従来の技術】昨今、音楽データ、画像データ、ゲーム
プログラム等、様々なソフトウエアデータ（以下、これ
らをコンテンツ（Content）と呼ぶ）を、インターネッ
ト、衛星を介した通信他、有線、無線の各種通信網を介
して配信するサービスが盛んになってきている。また、
ＤＶＤ、ＣＤ、メモリカード等の流通可能な記憶媒体を
介したコンテンツ流通も盛んになってきている。これら
の流通コンテンツは、ユーザの所有する例えば、ＴＶ、
ＰＣ（Personal Computer）、再生専用器、あるいはゲ
ーム機器等において、再生、利用される。

【０００３】通信網を介して配信されるコンテンツは、
例えば通信機能を有するセットトップボックスによって
受信され、ＴＶ他の再生装置において再生可能なデータ
に変換されて再生されたり、あるいは通信インタフェー
スを備えたＴＶ、再生装置、ゲーム機器、ＰＣ等の情報
機器によって受信されて再生される。

【０００４】ゲームプログラム、音楽データ、画像デー
タ等、多くのソフトウエア・コンテンツは、一般的にそ
の作成者、販売者に頒布権等が保有されている。従っ
て、これらのコンテンツの配布に際しては、一定の利用
制限、すなわち、正規なユーザに対してのみ、ソフトウ
エアの使用を許諾し、許可のない複製等が行われないよ
うにする、すなわちセキュリティを考慮した構成をとる
のが一般的となっている。

【０００５】ユーザに対する利用制限を実現する１つの
手法が、配布コンテンツの暗号化処理である。例えば著
作権保護の要請されるコンテンツを衛星通信あるいはイ
ンターネット通信等を介した配信、あるいはＤＶＤ等の
メディアに格納して配布する場合にコンテンツを暗号化
して配信または格納し、正規ユーザに対してのみコンテ
ンツ復号に利用可能な復号鍵を配布する。正規ユーザは
配布された復号鍵によって暗号化コンテンツの復号を実
行し、コンテンツを再生する構成である。

【０００６】暗号化データは、復号鍵を用いた復号化処
理によって復号データ（平文）に戻すことができる。デ
ータ暗号化処理に暗号化鍵を用い、復号化処理に復号化
鍵を用いるデータ暗号化、復号化方法は従来からよく知
られている。

【０００７】暗号化鍵と復号化鍵を用いるデータ暗号化
・復号化方法の態様には様々な種類あるが、その１つの
例としていわゆる共通鍵暗号化方式と呼ばれている方式
がある。共通鍵暗号化方式は、データの暗号化処理に用
いる暗号化鍵とデータの復号化に用いる復号化鍵を共通
のものとして、正規のユーザにこれら暗号化処理、復号
化に用いる共通鍵を付与して、鍵を持たない不正ユーザ
によるデータアクセスを排除するものである。この方式
の代表的な方式にＤＥＳ（データ暗号標準：Data encry
ption standard）がある。

【０００８】上述の暗号化処理、復号化に用いられる暗
号化鍵、復号化鍵は、例えばあるパスワード等に基づい
てハッシュ関数等の一方向性関数を適用して得ることが
できる。一方向性関数とは、その出力から逆に入力を求
めるのは非常に困難となる関数である。例えばユーザが
決めたパスワードを入力として一方向性関数を適用し
て、その出力に基づいて暗号化鍵、復号化鍵を生成する
ものである。このようにして得られた暗号化鍵、復号化
鍵から、逆にそのオリジナルのデータであるパスワード
を求めることは実質上不可能となる。

【０００９】また、暗号化するときに使用する暗号化鍵
による処理と、復号するときに使用する復号化鍵の処理
とを異なる鍵で行なう方式がいわゆる公開鍵暗号方式と
呼ばれる方式である。公開鍵暗号方式は、不特定のユー
ザが使用可能な公開鍵を使用する方法であり、特定個人
に対する暗号化文書を、その特定個人が生成した公開鍵
を用いて暗号化処理を行なう。公開鍵によって暗号化さ
れた文書は、その暗号化処理に使用された公開鍵に対応
する秘密鍵によってのみ復号化処理が可能となる。秘密
鍵は、公開鍵を生成した個人のみが所有するので、その
公開鍵によって暗号化された文書は秘密鍵を持つ個人の
みが復号することができる。公開鍵暗号方式の代表的な
ものには、楕円曲線暗号、あるいはＲＳＡ（Rivest-Sha
mir-Adleman）暗号がある。このような暗号化方式を利
用することにより、暗号化コンテンツを正規ユーザに対
してのみ復号可能とするシステムが可能となる。

【００１０】

【発明が解決しようとする課題】上記のようなコンテン
ツ利用管理システムでは、コンテンツを暗号化してユー
ザにネットワーク、あるいはＤＶＤ、ＣＤ等の記録媒体
に格納して提供し、暗号化コンテンツを復号するコンテ
ンツ鍵を正当なユーザにのみ提供する構成が多く採用さ
れている。コンテンツ鍵自体の不正な利用等を防ぐため
のコンテンツ鍵を暗号化して正当なユーザに提供し、正
当なユーザのみが有する復号キーを用いて暗号化コンテ
ンツ鍵を復号してコンテンツ鍵を使用可能とする構成が
提案されている。

【００１１】正当なユーザであるか否かの判定は、一般
には、例えばコンテンツの送信者であるコンテンツプロ
バイダとユーザデバイス間において、コンテンツ、ある
いはコンテンツ鍵の配信前に認証処理を実行することに
よって行なう。一般的な認証処理においては、相手の確
認を行なうとともに、その通信でのみ有効なセッション
キーを生成して、認証が成立した場合に、生成したセッ
ションキーを用いてデータ、例えばコンテンツあるいは
コンテンツ鍵を暗号化して通信を行なう。

【００１２】例えば上述の認証処理に必要な鍵データ、
ユーザデバイスＩＤなどのデータは第三者に漏洩するこ
とのないように管理することが必要となる。従って、こ
のような秘密データは第三者によるアクセスがなされな
いよう、パスワード等によってアクセス権を確認するこ
とが行なわれる。

【００１３】しかし、このようなパスワード管理を行な
った場合には、パスワード自体の漏洩の問題、パスワー
ド忘れなどの問題が発生する。さらに、様々なサービス
プロバイダとの取り引きを行なう場合においては、各サ
ービスプロバイダ毎にパスワードを設定する必要が生
じ、ユーザが複数のパスワードを管理することが要求さ
れ、ユーザによるパスワード管理の困難性が増大するこ
とになる。

【００１４】本発明は、上述の問題点に鑑みてなされた
ものであり、パスワードの管理におけるユーザの負担を
軽減し、パスワードの漏洩防止のためのパスワード変更
処理を効率的にかつセキュアに実行し、さらに、パスワ
ードを忘れた場合の対応としてのパスワード再設定処理
も効率的にかつセキュアに実行することを可能としたパ
スワード管理システム、パスワード管理方法、および情
報処理装置、並びにコンピュータ・プログラムを提供す
ることを目的とする。

【００１５】

【課題を解決するための手段】本発明の第１の側面は、
情報処理装置におけるデータ処理の開始条件として設定
されるパスワードの管理を実行するパスワード管理シス
テムであり、情報処理装置は、設定パスワードのリセッ
トまたは変更処理に際し、該情報処理装置に対応して設
定されたマスターパスワードとユーザ入力マスターパス
ワードとの一致検証処理を実行し、該一致検証処理にお
ける検証成立を条件として設定パスワードのリセットま
たは変更処理を実行する構成を有することを特徴とする
パスワード管理システムにある。

【００１６】さらに、本発明のパスワード管理システム
の一実施態様において、前記マスターパスワードは、前
記情報処理装置に対応して設定されたデバイス識別子と
してのデバイスＩＤに、前記情報処理装置個々または一
群の情報処理装置に対応して設定されたマスターキーを
適用した暗号処理によって生成されるデータであること
を特徴とする。

【００１７】さらに、本発明のパスワード管理システム
の一実施態様において、前記パスワード管理システムに
おいて、さらに、前記マスターパスワードの管理を実行
するサポートセンタを有し、前記サポートセンタは、前
記情報処理装置に対応して設定されたデバイス識別子と
してのデバイスＩＤと、マスターパスワードとを対応さ
せたデータベースを有し、前記サポートセンタは、前記
情報処理装置からのマスターパスワード再発行要求に応
じて、前記データベースから取得したマスターパスワー
ドの前記情報処理装置に対する送付処理を実行する構成
であることを特徴とする。

【００１８】さらに、本発明のパスワード管理システム
の一実施態様において、前記パスワード管理システムに
おいて、さらに、マスターパスワードの管理を実行する
サポートセンタを有し、前記サポートセンタは、前記情
報処理装置に対応して設定されたデバイス識別子として
のデバイスＩＤと、前記情報処理装置個々または一群の
情報処理装置に対応して設定されたマスターキーとを対
応させたデータベースを有し、前記サポートセンタは、
前記情報処理装置からのマスターパスワード再発行要求
に応じて、前記デバイスＩＤに対する、前記マスターキ
ーを適用した暗号処理によるマスターパスワード生成処
理を実行し、生成したマスターパスワードを前記情報処
理装置に送付する処理を実行する構成であることを特徴
とする。

【００１９】さらに、本発明のパスワード管理システム
の一実施態様において、前記マスターパスワードは、情
報処理装置におけるデータ処理の開始条件として設定さ
れる複数の異なるパスワードのリセットまたは変更処理
に際して共通に使用される構成であることを特徴とす
る。

【００２０】さらに、本発明のパスワード管理システム
の一実施態様において、前記パスワードは、情報処理装
置内のメモリに設定された複数のデータ格納領域の各々
に対応して設定された複数の異なるパスワードであり、
各パスワードは、各データ格納領域内の格納データに対
するアクセス可否を判定するパスワードであることを特
徴とする。

【００２１】さらに、本発明の第２の側面は、情報処理
装置におけるデータ処理の開始条件として設定されるパ
スワードの管理を実行するパスワード管理方法であり、
前記情報処理装置において、設定パスワードのリセット
または変更処理に際し、該情報処理装置に対応して設定
されたマスターパスワードとユーザ入力マスターパスワ
ードとの一致検証処理を実行するステップと、前記一致
検証処理における検証成立を条件として設定パスワード
のリセットまたは変更処理を実行するステップと、を有
することを特徴とするパスワード管理方法にある。

【００２２】さらに、本発明のパスワード管理方法の一
実施態様において、前記マスターパスワードは、前記情
報処理装置に対応して設定されたデバイス識別子として
のデバイスＩＤに、前記情報処理装置個々または一群の
情報処理装置に対応して設定されたマスターキーを適用
した暗号処理によって生成されるデータであることを特
徴とする。

【００２３】さらに、本発明のパスワード管理方法の一
実施態様において、前記パスワード管理方法において、
さらに、前記マスターパスワードの管理を実行するサポ
ートセンタを有し、前記サポートセンタは、前記情報処
理装置に対応して設定されたデバイス識別子としてのデ
バイスＩＤと、マスターパスワードとを対応させたデー
タベースを有し、前記サポートセンタは、前記情報処理
装置からのマスターパスワード再発行要求に応じて、前
記データベースから取得したマスターパスワードの前記
情報処理装置に対する送付処理を実行することを特徴と
する。

【００２４】さらに、本発明のパスワード管理方法の一
実施態様において、前記パスワード管理方法において、
さらに、マスターパスワードの管理を実行するサポート
センタを有し、前記サポートセンタは、前記情報処理装
置に対応して設定されたデバイス識別子としてのデバイ
スＩＤと、前記情報処理装置個々または一群の情報処理
装置に対応してマスターキーとを対応させたデータベー
スを有し、前記サポートセンタは、前記情報処理装置か
らのマスターパスワード再発行要求に応じて、前記デバ
イスＩＤに対する、前記マスターキーを適用した暗号処
理によるマスターパスワード生成処理を実行し、生成し
たマスターパスワードを前記情報処理装置に送付する処
理を実行することを特徴とする。

【００２５】さらに、本発明のパスワード管理方法の一
実施態様において、前記マスターパスワードは、情報処
理装置におけるデータ処理の開始条件として設定される
複数の異なるパスワードのリセットまたは変更処理に際
して共通に使用されることを特徴とする。

【００２６】さらに、本発明のパスワード管理方法の一
実施態様において、前記パスワードは、情報処理装置内
のメモリに設定された複数のデータ格納領域の各々に対
応して設定された複数の異なるパスワードであり、各パ
スワードは、各データ格納領域内の格納データに対する
アクセス可否を判定するパスワードであることを特徴と
する。

【００２７】さらに、本発明の第３の側面は、データ処
理を実行する情報処理装置であり、情報処理装置におけ
るデータ処理の開始条件として設定されるパスワードの
リセットまたは変更処理に際し、該情報処理装置に対応
して設定されたマスターパスワードとユーザ入力マスタ
ーパスワードとの一致検証処理を実行し、該一致検証処
理における検証成立を条件として設定パスワードのリセ
ットまたは変更処理を実行する構成を有することを特徴
とする情報処理装置にある。

【００２８】さらに、本発明の情報処理装置の一実施態
様において、前記マスターパスワードは、前記情報処理
装置に対応して設定されたデバイス識別子としてのデバ
イスＩＤに、前記情報処理装置個々または一群の情報処
理装置に対応して設定されたマスターキーを適用した暗
号処理によって生成されるデータであることを特徴とす
る。

【００２９】さらに、本発明の情報処理装置の一実施態
様において、前記マスターパスワードは、情報処理装置
におけるデータ処理の開始条件として設定される複数の
異なるパスワードのリセットまたは変更処理に際して共
通に使用される構成であることを特徴とする。

【００３０】さらに、本発明の情報処理装置の一実施態
様において、前記パスワードは、情報処理装置内のメモ
リに設定された複数のデータ格納領域の各々に対応して
設定された複数の異なるパスワードであり、各パスワー
ドは、各データ格納領域内の格納データに対するアクセ
ス可否を判定するパスワードであることを特徴とする。

【００３１】さらに、本発明の第４の側面は、情報処理
装置におけるデータ処理の開始条件として設定されるパ
スワードの管理を実行するパスワード管理処理をコンピ
ュータ・システム上で実行せしめるコンピュータ・プロ
グラムであって、設定パスワードのリセットまたは変更
処理に際し、該情報処理装置に対応して設定されたマス
ターパスワードとユーザ入力マスターパスワードとの一
致検証処理を実行するステップと、前記一致検証処理に
おける検証成立を条件として設定パスワードのリセット
または変更処理を実行するステップと、を有することを
特徴とするコンピュータ・プログラムにある。

【００３２】なお、本発明のコンピュータ・プログラム
は、例えば、様々なプログラム・コードを実行可能なコ
ンピュータ・システムに対して、コンピュータ可読な形
式で提供する記憶媒体、通信媒体、例えば、ＣＤやＦ
Ｄ、ＭＯなどの記録媒体、あるいは、ネットワークなど
の通信媒体によって提供可能なコンピュータ・プログラ
ムである。このようなプログラムをコンピュータ可読な
形式で提供することにより、コンピュータ・システム上
でプログラムに応じた処理が実現される。

【００３３】本発明のさらに他の目的、特徴や利点は、
後述する本発明の実施例や添付する図面に基づくより詳
細な説明によって明らかになるであろう。なお、本明細
書においてシステムとは、複数の装置の論理的集合構成
であり、各構成の装置が同一筐体内にあるものには限ら
ない。

【００３４】

【発明の実施の形態】［システム概要］図１に本発明の
コンテンツ利用管理システムにおける各エンティテイ、
および各エンティテイの処理の概要を説明する図を示
す。

【００３５】ユーザデバイス１０１は、コンテンツを利
用する各ユーザの端末であり、具体的には、ＰＣ、ゲー
ム端末、ＤＶＤ，ＣＤ等の再生装置、記録再生装置等で
ある。これらの端末には、後段で説明する暗号処理、コ
ンテンツ利用処理を制御する制御手段を備えた耐タンパ
構成のセキュリティチップが装着されている。コンテン
ツ配信エンティテイ（コンテンツディストリビュータ）
としてのサービスプロバイダ（ＳＰ−ＣＤ）１０２、そ
の他のエンティテイとユーザデバイス１０１間で実行さ
れるデータ転送等におけるユーザデバイス１０１側のセ
キュアな処理の多くは、セキュリティチップ内で制御、
実行される。

【００３６】サービスプロバイダ（コンテンツディスト
リビュータ）（ＳＰ−ＣＤ）１０２は、セキュリティチ
ップを持つユーザデバイス１０１に対してコンテンツを
提供するサービスプロバイダである。コンテンツクリエ
ータ１０３は、サービスプロバイダ（コンテンツディス
トリビュータ）（ＳＰ−ＣＤ）１０２に対してサービス
に供するためのコンテンツを提供する。ユーザデバイス
製造者（Manufacturer）１０４は、ユーザデバイス１０
１を製造するエンティテイである。

【００３７】サポートセンタ１０５は、ユーザデバイス
１０１に装着されたユーザデバイスでの様々な処理に対
するサポートを実行するセンタであり、例えばユーザが
認証情報として利用するパスワードを忘れた場合のパス
ワードのリカバリ処理、あるいはユーザデバイスが生成
したコンテンツのバックアップデータを利用したリスト
ア（復旧）処理など、ユーザデバイスに対する様々なサ
ポート処理を実行する。認証局（ＣＡ：Certification
Authority）１０６は各エンティテイに対して公開鍵証
明書(ＰＫＣ：Public Key Certificate)を発行する。

【００３８】なお、ユーザデバイス１０１、サービスプ
ロバイダ（コンテンツディストリビュータ）（ＳＰ−Ｃ
Ｄ）１０２、コンテンツクリエータ１０３、ユーザデバ
イス製造者（Manufacturer）１０４、サポートセンタ１
０５、認証局（ＣＡ：Certification Authority）１０
６、各エンティテイの数は任意である。特に、図１にお
いて、認証局（ＣＡ：Certification Authority）１０
６を１つのみ示してあるが、認証局は、各エンティテイ
での処理に応じて必要となる公開鍵証明書を発行する複
数の認証局が存在してよい。

【００３９】ユーザデバイス１０１は、衛星通信、イン
ターネット通信、あるいはその他、有線、無線のデータ
通信ネットワークを介してサービスプロバイダ（コンテ
ンツディストリビュータ）１０２から暗号化されたコン
テンツを受信し、コンテンツを利用する。暗号化コンテ
ンツを復号するための鍵：コンテンツ鍵：Ｋｃは暗号化
されてコンテンツ利用権限を示す権限情報証明書として
のコンテンツ利用権限証明書、例えば属性証明書（Ａ
Ｃ：Attribute Certificate）１１０に格納されてお
り、ユーザ端末１０１がコンテンツを復号して利用する
ためには、サービスプロバイダ（コンテンツディストリ
ビュータ）１０２から属性証明書（ＡＣ：Attribute Ce
rtificate）１１０を受領し、セキュリティチップを持
つユーザデバイスにおいて属性証明書から鍵を取り出し
て復号することが必要となる。

【００４０】コンテンツ利用権限を示す権限情報証明書
としてのコンテンツ利用権限証明書、例えば属性証明書
（ＡＣ：Attribute Certificate）１１０には、暗号化
されたコンテンツ鍵：Ｋｃの他に、コンテンツの利用制
限回数や利用期限など、コンテンツの利用制限情報が記
録されており、ユーザデバイス１０１は、コンテンツ利
用権限証明書としての属性証明書（ＡＣ）１１０に記録
されたコンテンツ利用制限に従ったコンテンツの利用が
可能となる。

【００４１】なお、以下、実施例の説明では、属性証明
書（ＡＣ：Attribute Certificate）１１０にコンテン
ツの利用情報、暗号化コンテンツ鍵を格納した構成とし
て説明するが、コンテンツの利用情報、暗号化コンテン
ツ鍵を格納した証明書は、いわゆる規定に従った属性証
明書（ＡＣ）に限らず、任意のデータフォーマットの証
明書として構成可能である。すなわちコンテンツの利用
権限を証明するデータを格納し、データ改竄検証のため
の発行エンティテイの署名データが付加された構成であ
れば、任意のデータ形式のコンテンツ利用権限証明書が
利用可能である。

【００４２】なお、サービスプロバイダからユーザデバ
イスに対するコンテンツ配信あるいは属性証明書（Ａ
Ｃ：Attribute Certificate）の配信形態としては、ユ
ーザ側からサービスプロバイダに対する要求に基づいて
実行される形態と、ユーザの要求の有無に関係なく例え
ばサブスクライバ契約を結んでいるユーザに対して、サ
ービスプロバイダから一方的に送信するいわゆるプッシ
ュ型の形態(プッシュ型モデル)のいずれの形態も可能で
ある。

【００４３】図１で示す各エンティテイ中、認証局１０
６以外のエンティテイ、すなわちユーザデバイス１０
１、サービスプロバイダ（コンテンツディストリビュー
タ）（ＳＰ−ＣＤ）１０２、コンテンツクリエータ１０
３、およびユーザデバイス製造者（Manufacturer）１０
４、サポートセンタ１０５のエンティテイは、所定のル
ールに従ってコンテンツ利用、コンテンツ配信を可能と
するため、各エンティテイでの処理を所定のルールに従
って実行する。このルールを設定し、管理するエンティ
テイとして図示しないシステムホルダ（ＳＨ:System Ho
lder）がある。図１の１０１〜１０５の各エンティテイ
は、システムホルダ（ＳＨ）の設定したコンテンツ利用
インフラ、ルールの下で各エンティテイでの処理を実行
する。

【００４４】例えばユーザデバイス製造者（Manufactur
er）１０４は、製造するユーザデバイス内の耐タンパ構
成を持つセキュリティチップ内に、コンテンツ配信にお
いて適用するデバイス識別子（ＩＤ）、および各種の暗
号処理鍵を格納する。ユーザデバイス１０１、サービス
プロバイダ（コンテンツディストリビュータ）１０２、
コンテンツクリエータ（ＣＣ）１０３、サポートセンタ
１０５間でのコンテンツ転送、属性証明書の転送、その
他のデータ転送処理においては、システムホルダ（Ｓ
Ｈ）の設定したルールに基づいて、例えば相互認証処
理、データ暗号化処理を実行する。

【００４５】また、ユーザデバイス１０１におけるコン
テンツ利用に際しては、属性証明書に記録された利用制
限を遵守したコンテンツ利用を実行する。例えば回数制
限の設定されたコンテンツの利用に際してデバイス内の
セキュリティチップの制御部の制御の下に、コンテンツ
利用可能回数を係数するカウンタを更新する処理等を実
行する。このような各エンティテイでの処理のルールを
規定したプラットホームを構築し、管理するエンティテ
イがシステムホルダ（ＳＨ）である。

【００４６】［公開鍵証明書，属性証明書］図１の構成
において利用される公開鍵証明書、属性証明書につい
て、その概要を説明する。

【００４７】（公開鍵証明書（ＰＫＣ））公開鍵証明書
について図２，図３、図４を用いて説明する。公開鍵証
明書は、認証局（ＣＡ：Certification Authority）が
発行する証明書であり、ユーザ、各エンティテイが自己
のＩＤ、公開鍵等を認証局に提出することにより、認証
局側が認証局のＩＤや有効期限等の情報を付加し、さら
に認証局による署名を付加して作成される証明書であ
る。

【００４８】公開鍵証明書のフォーマット例を図２〜図
４に示す。これは、公開鍵証明書フォーマットＩＴＵ−
ＴＸ．５０９に準拠した例である。

【００４９】バージョン（version）は、証明書フォー
マットのバージョンを示す。シリアルナンバ（Serial N
umber）は、公開鍵証明書発行局（ＣＡ）によって設定
される公開鍵証明書のシリアルナンバである。シグネチ
ャ（Signature）は、証明書の署名アルゴリズムであ
る。なお、署名アルゴリズムとしては、楕円曲線暗号お
よびＲＳＡがあり、楕円曲線暗号が適用されている場合
はパラメータおよび鍵長が記録され、ＲＳＡが適用され
ている場合には鍵長が記録される。発行者（issuer）
は、公開鍵証明書の発行者、すなわち公開鍵証明書発行
局（ＩＡ）の名称が識別可能な形式（Distinguished Na
me）で記録されるフィールドである。有効期限(validit
y)は、証明書の有効期限である開始日時、終了日時が記
録される。サブジェクト公開鍵情報(subject Public Ke
y Info)は、証明書所有者の公開鍵情報として鍵のアル
ゴリズム、鍵が格納される。

【００５０】証明局鍵識別子（authority Key Identifi
er−key Identifier、authority Cert Issuer、authori
ty Cert Serial Number）は、署名検証に用いる証明書
発行者の鍵を識別する情報であり、鍵識別子、機関証明
書発行者の名称、機関証明書シリアル番号を格納する。
サブジェクト鍵識別子（subject key Identifier）は、
複数の鍵を公開鍵証明書において証明する場合に各鍵を
識別するための識別子を格納する。鍵使用目的（key us
age）は、鍵の使用目的を指定するフィールドであり、
（０）ディジタル署名用、（１）否認防止用、（２）鍵
の暗号化用、（３）メッセージの暗号化用、（４）共通
鍵配送用、（５）認証の署名確認用、（６）失効リスト
の署名確認用の各使用目的が設定される。秘密鍵有効期
限(private Key Usage Period)は、証明書に格納した公
開鍵に対応する秘密鍵の有効期限を記録する。認証局ポ
リシー（certificate Policies）は、公開鍵証明書発行
者の証明書発行ポリシーを記録する。例えばＩＳＯ／Ｉ
ＥＣ９３８４−１に準拠したポリシーＩＤ、認証基準で
ある。ポリシー・マッピング（policy Mapping）は、認
証パス中のポリシー関係の制限に関する情報を格納する
フィールドであり、認証局（ＣＡ）証明書にのみ必要と
なる。サブジェクト別名（subject Alt Name）は、証明
書所有者の別名を記録するフィールドである。発行者別
名（issuer Alt Name）は、証明書発行者の別名を記録
するフィールドである。サブジェクト・ディレクトリ・
アトリビュート（subject Directory Attribute）は、
証明書所有者のために必要とされるディレクトリの属性
を記録するフィールドである。基本制約（basic Constr
aint）は、証明対象の公開鍵が認証局（ＣＡ）の署名用
か、証明書所有者のものかを区別するためのフィールド
である。許容サブツリー制約名（name Constraints per
mitted Subtrees）は、発行者が発行する証明書の名前
の制限情報を格納するフィールドである。制約ポリシー
（policy Constraints）は、認証パス中のポリシーの関
係の制限情報を格納するフィールドである。ＣＲＬ参照
ポイント（Certificate Revocation List Distribution
Points）は、証明書所有者が証明書を利用する際に、
証明書が失効していないか、どうかを確認するための失
効リストの参照ポイントを記述するフィールドである。
署名アルゴリズム（Signature Algotithm）は、証明書
の署名付けに用いるアルゴリズムを格納するフィールド
である。署名は、公開鍵証明書発行者の署名フィールド
である。電子署名は、証明書全体に対しハッシュ関数を
適用してハッシュ値を生成し、そのハッシュ値に対して
発行者の秘密鍵を用いて生成したデータである。署名付
けやハッシュをとるだけでは改竄は可能であるが、検出
できれば実質的に改竄できないことと同様の効果があ
る。

【００５１】認証局は、図２〜図４に示す公開鍵証明書
を発行するとともに、有効期限が切れた公開鍵証明書を
更新し、不正を行った利用者の排斥を行うための失効リ
スト（Revocation List）の作成、管理、配布（これを
リボケーション：Revocationと呼ぶ）を行う。また、必
要に応じて公開鍵・秘密鍵の生成も行う。

【００５２】一方、この公開鍵証明書を利用する際に
は、利用者は自己が保持する認証局の公開鍵を用い、当
該公開鍵証明書の電子署名を検証し、電子署名の検証に
成功した後に公開鍵証明書から公開鍵を取り出し、当該
公開鍵を利用する。従って、公開鍵証明書を利用する全
ての利用者は、共通の認証局の公開鍵を保持している必
要がある。

【００５３】（属性証明書（ＡＣ））属性証明書につい
て図５を用いて説明する。属性証明書には大きく分けて
２つの種類があり、１つは、コンテンツの利用権といっ
た権利や権限に関する所有者の属性情報を含む証明書で
ある。もう１つは、サービスプロバイダ（ＳＰ）用領域
確保または削除用属性証明書（ＡＣ）であり、ユーザデ
バイス内のメモリにサービスプロバイダ（ＳＰ）用情報
格納領域を確保または削除する場合の領域確保または削
除の許諾情報を含む属性証明書（ＡＣ）である。

【００５４】属性証明書フォーマットはITU-T X.509で
規定されており，IETF PKIX WGでProfileを策定してい
る。公開鍵証明書とは異なり所有者の公開鍵を含まな
い。しかし属性証明書認証局(Attribute Certificate A
uthority)の署名がついているため、改竄されていない
かどうかの判定はこの署名を検証することで行える、と
いう点は公開鍵証明書と同様である。

【００５５】本発明の構成においては、属性証明書（Ａ
Ｃ）の発行管理を行なう属性証明書認証局(Attribute C
ertificate Authority)は、サービスプロバイダ（コン
テンツディストリビュータ）（ＳＰ−ＣＤ）１０２が兼
務することが可能である。別の構成としてもよい。属性
証明書は常に公開鍵証明書と関連づけて利用する。すな
わち所有者の本人性自体は公開鍵証明書で確認し、その
上で所有者にいかなる権限が与えられているかのみを示
すものが属性証明書である。属性証明書の検証にあたっ
ては，当該証明書の署名検証を行った後、それに関連づ
けられている公開鍵証明書の検証も行う。

【００５６】なお、その際、原則的には証明書連鎖をた
どって最上位の公開鍵証明書まで順に検証を実施するこ
とが好ましい。複数の認証局（ＣＡ）が存在し、階層構
成をなす認証局構成では、下位の認証局自身の公開鍵証
明書は、その公開鍵証明書を発行する上位認証局によっ
て署名されている。すなわち、下層の公開鍵証明書発行
局（ＣＡ−Ｌｏｗ）に対して上位の公開鍵証明書発行局
（ＣＡ−Ｈｉｇｈ）が公開鍵証明書を発行するという連
鎖的な公開鍵証明書発行構成をとる。公開鍵証明書の連
鎖検証とは、下位から上位へ証明書連鎖をたどって最上
位の公開鍵証明書までの連鎖情報を取得して、最上位
（ル−トＣＡ）までの公開鍵証明書の署名検証を行なう
ことを意味する。

【００５７】属性証明書の有効期間を短期間とすること
により、失効処理を行わないことも可能である。この場
合、証明書の失効手続きや失効情報の参照手順等を省く
ことができ、システムが簡易となる長所がある。ただし
証明書の不正利用に対しては失効以外の何らかの対策が
必要となるため、十分に注意しなければならない。本認
証システムにおいては、コンテンツに対する利用権限の
他に、コンテンツを復号するためのコンテンツ鍵を属性
証明書に埋め込んでおく構成であるので、正当なコンテ
ンツ利用権限のあるユーザデバイスは、正当な属性証明
書を受領することにより、コンテンツを利用可能であ
る。

【００５８】図５に示す属性証明書の構成について説明
する。証明書のバージョン番号は、証明書フォーマット
のバージョンを示す。ＡＣ保持者の公開鍵証明書情報、
これは属性証明書（ＡＣ）の発行者に対応する公開鍵証
明書（ＰＫＣ）に関する情報であり、ＰＫＣ発行者名、
ＰＫＣシリアル番号、ＰＫＣ発行者固有識別子等の情報
であり、対応公開鍵証明書を関連づけるリンクデータと
しての機能を持つ。属性証明書の発行者の名前は、属性
証明書の発行者、すなわち属性証明書認証局（ＡＡ）の
名称が識別可能な形式（Distinguished Name）で記録さ
れるフィールドである。署名アルゴリズム識別子は、属
性証明書の署名アルゴリズム識別子を記録するフィール
ドである。証明書の有効期限は、証明書の有効期限であ
る開始日時、終了日時が記録される。属性情報フィール
ドは、属性証明書の利用形態に応じて、（１）メモリ領
域確保、削除情報、または、（２）コンテンツ利用条件
関連情報のいずれかが格納される。コンテンツ利用条件
関連情報には、暗号化されたコンテンツ鍵を含む。

【００５９】（１）メモリ領域確保、削除情報は、サー
ビスプロバイダがユーザデバイスのセキュリティチップ
内のメモリにサービスプロバイダ毎の管理領域を登録設
定、または削除処理を目的として発行される属性証明書
に記録される。記録情報は、例えば以下の情報である。サービスプロバイダ識別子（ＩＤ）サービスプロバイダ・ネーム処理：メモリ領域確保、メモリ領域削除のいずれか領域サイズ：メモリ領域のサイズ

【００６０】サービスプロバイダは、上記各項目を属性
情報フィールドに格納した属性証明書をユーザデバイス
に対して送付し、ユーザデバイスは属性証明書の検証の
後、自己のセキュリティチップ内のメモリに、受信した
属性証明書の属性情報フィールドの記録に従ったメモリ
領域の確保処理、または確保済みのメモリ領域の削除処
理を実行する。

【００６１】（２）コンテンツ利用条件関連情報は、サ
ービスプロバイダの提供するコンテンツに対応して発行
される属性証明書の属性情報フィールドに格納する情報
であり、コンテンツの利用制限回数、利用期限等の様々
な利用条件を含み、さらにコンテンツを暗号化したコン
テンツ鍵の暗号化データを含む。記録情報は、例えば以
下の情報である。サービスプロバイダ識別子（ＩＤ）サービスプロバイダ・ネームアプリケーション識別子（ＩＤ）：コンテンツの識別情
報である。条件：オンライン利用コンテンツか、オフライン利用コ
ンテンツか、さらに、買い切りコンテンツ、期間制限コ
ンテンツ、オンライン回数制限コンテンツ、オフライン
回数制限コンテンツのいずれであるかを示す情報であ
る。有効期限：期間制限の場合の有効期限情報利用制限回数：回数制限の場合の利用可能回数支払条件：コンテンツの対価の支払条件を記録コンテンツ鍵：暗号化されたコンテンツ鍵を暗号化アル
ゴリズム情報とともに格納

【００６２】コンテンツの利用態様には、上記条件フィ
ールドに記載のように、（１）オンライン利用か、
（２）オフライン利用かの区別と、（ａ）コンテンツを
買い切りし、買い切り以後のコンテンツ利用をフリーと
する態様、（ｂ）期間制限を設けてコンテンツの利用期
間を設定した態様、（ｃ）回数制限を設けてコンテンツ
の利用回数を制限した態様の各態様がある。また期間制
限と回数制限の両制限を伴うコンビネーション制限態様
もある。ユーザデバイスでは、属性証明書に記録された
これらの態様に従ってコンテンツの利用が実行される。
これらの具体的な処理態様については、後段で説明す
る。

【００６３】また、暗号化コンテンツの復号鍵として適
用するコンテンツ鍵：Ｋｃを暗号化した暗号化コンテン
ツ鍵が格納される。コンテンツ鍵：Ｋｃの暗号化処理に
直接あるいは間接的に適用する鍵の主な種類は以下に示
す通りである。（ａ）ユーザデバイスのセキュリティチップの各サービ
スプロバイダ管理領域に格納されたＳＰ対応ストレージ
秘密鍵に対応するサービスプロバイダ（ＳＰ）対応スト
レージ公開鍵：ＳＣ．Ｓｔｏｐｕｂ．ＳＰ．Ｋ、（公開
鍵方式）（ｂ）ユーザデバイスのセキュリティチップの各サービ
スプロバイダ管理領域に格納されたＳＰ対応ストレージ
鍵（共通鍵方式）（ｃ）サービスプロバイダの保有する秘密鍵：ＳＰ．Ｓ
ｔｏ．Ｋ（ｄ）システムホルダ（ＳＨ）とユーザデバイスで共有
する鍵として生成されるグローバル共通鍵：Ｋｇこれらの鍵を適用した処理については後段で詳細に説明
する。

【００６４】属性証明書には、さらに、署名アルゴリズ
ムが記録され、属性証明書発行者である属性証明書認証
局（ＡＡ）によって署名が施される。電子署名は、属性
証明書全体に対しハッシュ関数を適用してハッシュ値を
生成し、そのハッシュ値に対して属性証明書発行者（Ａ
Ａ）の秘密鍵を用いて生成したデータである。

【００６５】［セキュリティチップ構成］次にコンテン
ツを利用する情報処理装置としてのユーザデバイス内に
構成されるセキュリティチップの構成について、図６を
参照しながら説明する。なお、ユーザデバイスは、デー
タ処理手段としてのＣＰＵ、通信機能を備えたＰＣ、ゲ
ーム端末、ＤＶＤ，ＣＤ等の再生装置、記録再生装置等
によって構成されるものであり、これらのユーザデバイ
スの中に耐タンパ構造を持つセキュリティチップが実装
されることになる。ユーザデバイス自体の構成例は本明
細書の末尾において説明する。セキュリティチップを持
つユーザデバイスは、図１におけるユーザデバイス製造
者１０４において製造される。

【００６６】図６に示すように、ユーザデバイス２００
には、セキュリティチップ２１０が、ユーザデバイス側
制御部２２１に対して、相互にデータ転送可能な構成と
して内蔵される。セキュリティチップ２１０は、プログ
ラム実行機能、演算処理機能を持つＣＰＵ（Central Pr
ocessing Unit）２０１を有し、データ通信用のインタ
フェース機能を持つ通信インタフェース２０２、ＣＰＵ
２０１によって実行される各種プログラム、例えば暗号
処理プログラム、デバイスの製造時に格納されるマスタ
ー鍵：Ｋｍなどを記憶するＲＯＭ（Read Only Memory）
２０３、実行プログラムのロード領域、また、各プログ
ラム処理におけるワーク領域として機能するＲＡＭ（Ra
ndom Access Memory）２０４、外部機器との認証処理、
電子署名の生成、検証処理、格納データの暗号化、復号
化処理等の暗号処理を実行する暗号処理部２０５、前述
したサービスプロバイダ毎の情報、各種鍵データを含む
デバイスの固有情報を格納した例えばＥＥＰＲＯＭ(Ele
ctrically Erasable Programmable ROM)によって構成さ
れるメモリ部２０６を有する。これら格納情報の詳細に
ついては後述する。

【００６７】ユーザデバイス２００は、暗号化コンテン
ツ等を格納する領域としてのＥＥＰＲＯＭ、ハードディ
スク等によって構成される外部メモリ部２２２を有す
る。外部メモリ部２２２は、公開鍵証明書、属性証明書
の格納領域としても利用可能であり、また後段で説明す
るコンテンツの利用回数管理ファイルの格納領域として
も利用される。

【００６８】セキュリティチップを搭載したユーザデバ
イスが、外部エンティテイ、例えばサービスプロバイダ
と接続し、データ転送処理を実行する場合には、必要に
応じて、セキュリティチップ２１０と、外部エンティテ
イ間の相互認証が行われ、また転送データの暗号化が行
なわれる。これらの処理の詳細については、後段で詳述
する。

【００６９】ユーザデバイスのセキュリティチップでの
処理対象となるデータ例を図７に示す。これらの多く
は、不揮発性メモリの一形態であるフラッシュメモリ等
のＥＥＰＲＯＭ(Electrically Erasable Programmable
ROM)によって構成されるメモリ部２０６に格納される
が、製造時に格納し、書き換え不可能とするデータ、例
えばマスター鍵：Ｋｍは、ＲＯＭ（Read Only Memory）
２０３に格納される。公開鍵証明書、属性証明書は、セ
キュリティチップ内のメモリに格納しても、外部メモリ
に格納してもよい。

【００７０】各データについて説明する。公開鍵証明書（ＰＫＣ）：公開鍵証明書は、第三者に対
して正当な公開鍵であることを示す証明書で、証明書に
は配布したい公開鍵を含み、信頼のおける認証局により
ディジタル署名されている。ユーザデバイスには、前述
した階層構成の最上位認証局（ルートＣＡ）の公開鍵証
明書、ユーザデバイスに登録されたサービスプロバイ
ダ、すなわち、ユーザデバイス内にメモリ領域が確保さ
れているサービスプロバイダの公開鍵証明書、さらに、
パスワード復帰処理等のサポートを実行するサポートセ
ンタの公開鍵証明書を格納する。

【００７１】属性証明書（ＡＣ）：公開鍵証明書が証明
書利用者（所有者）の“本人性”を示すのに対し、属性
証明書は証明書利用者の利用権限を示すものである。利
用者は属性証明書を提示することにより、属性証明書に
記載された権利・権限に基づいて、アプリケーションの
利用や、領域の確保などが行えるようになる。以下に、
属性証明書の種類を示し、それぞれの果たす役割を示
す。

【００７２】（ａ）アプリケーション利用管理用属性証
明書（ＡＣ）：アプリケーションとは、一般に言われる
コンテンツを広い意味で使用した表現であり、アプリケ
ーションの種類としては、ゲーム、音楽、映画、金融情
報等の各種アプリケーションがある。アプリケーション
利用管理用属性証明書（ＡＣ）では、アプリケーション
の利用権限に関しての記述があり、属性証明書（ＡＣ）
をサービスプロバイダ（ＳＰ）に対して提示して検証、
もしくは、ローカルで検証することにより、属性証明書
（ＡＣ）に記述された利用権限範囲内でのアプリケーシ
ョンの利用許諾が得られる。アプリケーションの利用権
限に関する記述としては、アプリケーションのオンライ
ン利用が可能であるかオフライン利用が可能であるか、
さらに、オンライン利用可能なコンテンツの場合には、
利用期間制限、利用回数制限情報があり、オフライン利
用可能なコンテンツの場合には、利用回数制限、買い切
りを示す記述がある。

【００７３】（ｂ）サービスプロバイダ（ＳＰ）用メモ
リ領域管理（確保）用属性証明書（ＡＣ）：ユーザデバ
イスにサービスプロバイダ（ＳＰ）を登録する場合、Ｓ
Ｐに関する情報格納領域をユーザデバイス内に確保する
必要がある。この時の領域確保の許諾情報を属性証明書
（ＡＣ）に格納し、ユーザデバイスでは、属性証明書
（ＡＣ）に格納された情報に従って、ユーザデバイス内
にＳＰ用の領域を確保する。

【００７４】（ｃ）サービスプロバイダ（ＳＰ）用メモ
リ領域管理（削除）用属性証明書（ＡＣ）：ユーザデバ
イス内に確保したＳＰ用領域の削除の許諾情報を格納し
た属性証明書（ＡＣ）である。ユーザデバイスでは、属
性証明書（ＡＣ）に格納された情報に従って、ユーザデ
バイス内のＳＰ用の領域の削除処理を実行する。

【００７５】鍵データ：鍵データとしては、デバイスに
対して設定される公開鍵、秘密鍵のペア、コンテンツ等
のデータ保存の際の暗号処理用鍵として用いられるスト
レージ鍵、さらに、乱数生成用鍵、相互認証用鍵等が格
納される。

【００７６】ストレージ鍵は、デバイスに保存するコン
テンツ鍵の暗号化または復号化処理の少なくともいずれ
かに適用する鍵である。ストレージ鍵には、デバイス対
応ストレージ鍵、サービスプロバイダ対応ストレージ鍵
があり、サービスプロバイダ対応ストレージ鍵は、デバ
イスに登録された個々のサービスプロバイダ毎に各サー
ビスプロバイダ管理領域内に格納される鍵であり、対応
するサービスプロバイダの提供するコンテンツ鍵に対応
して適用される。デバイス対応ストレージ鍵には、シス
テムホルダと、デバイスのみが共有する鍵として構成さ
れるグローバル共通鍵が含まれ、グローバル共通鍵は、
サービスプロバイダにおける復号化処理を防止した暗号
化コンテンツ鍵の配信処理を実行する際に用いられる。
これらの鍵を適用した処理の詳細については後段で説明
する。

【００７７】識別情報：識別情報としては、ユーザデバ
イス自身の識別子としてのデバイスＩＤ、ユーザデバイ
スに登録したサービスプロバイダ（ＳＰ）の識別子とし
てのサービスプロバイダＩＤ、ユーザデバイスを利用す
るユーザに付与されたユーザＩＤ、なお、ユーザＩＤは
サービスプロバイダ等、外部エンティテイ毎に異なるユ
ーザＩＤが付与可能である。アプリケーションＩＤは、
サービスプロバイダ（ＳＰ）によって提供されるサービ
ス、コンテンツに対応する識別情報としてのＩＤであ
る。

【００７８】その他：ユーザデバイスには、さらに、認
証情報として、ユーザデバイス内に登録したサービスプ
ロバイダ（ＳＰ）情報の利用許諾を得るための認証情報
（例えばパスワード）が格納される。パスワードを入力
することにより、ユーザデバイス内に登録したサービス
プロバイダ（ＳＰ）情報の取得が可能となり、情報取得
後、サービスプロバイダの提供するアプリケーション、
コンテンツの利用が許可される。認証情報（パスワー
ド）を忘れた場合には、マスターパスワードを用いて認
証情報（パスワード）の初期化（リセット）処理が可能
である。

【００７９】さらに乱数生成用のシード情報が格納され
る。乱数は、認証処理、暗号処理等の際に、例えばＡＮ
ＳＩＸ９．１７に従って生成する。

【００８０】さらに、コンテンツ利用回数情報、あるい
はコンテンツ利用回数情報に基づいて算出されるハッシ
ュ値が格納される。これは、アプリケーション、コンテ
ンツに対応する属性証明書に格納された利用回数制限内
でのコンテンツ利用を厳格に実行するために必要となる
情報であり、コンテンツに対応する属性証明書の識別情
報としてのアプリケーションＩＤ、属性証明書のシリア
ル番号、コンテンツの利用制限回数を保存する。署名付
けやハッシュをとるだけでは改竄は可能であるが、検出
できれば実質的に改竄できないことと同様の効果があ
る。

【００８１】［ユーザデバイス内のメモリ構成］不揮発
性メモリの一形態であるフラッシュメモリ等のＥＥＰＲ
ＯＭ(Electrically Erasable Programmable ROM)によっ
て構成されるメモリ部２０６には、上述した様々なデー
タの少なくとも一部が格納されるが、これらは、メモリ
部２０６領域に分割管理された３つの領域、すなわち、
（１）デバイス管理領域、（２）システム管理領域、
（３）サービス・プロバイダ管理領域に区分されて格納
される。以下、これらの各領域毎の格納データについて
説明する。

【００８２】（１）デバイス管理領域デバイス管理領域は、デバイス固有のシステムに依存し
ない情報が保持されている。この領域はデバイス製造時
に、最初に領域が確保され、不揮発性メモリの先頭の複
数ブロックを占める領域である。デバイス管理領域で
は、少なくとも以下のデータを保持・管理する。デバイスＩＤ乱数生成用シード乱数生成用暗号鍵相互認証鍵デバイス対応ストレージ鍵

【００８３】相互認証鍵は、セキュリティチップ内のデ
ータをセキュリティチップ外部に出力する場合等に出力
先となるエンティテイとの認証用の鍵である。なお、エ
ンティテイは、セキュリティチップを装着した例えばゲ
ーム端末、ＤＶＤ，ＣＤ等の再生装置、記録再生装置で
あるユーザデバイスも含む。セキュリティチップと、セ
キュリティチップを持つユーザデバイス間でのデータ転
送、さらにはユーザデバイスを介した外部のサービスプ
ロバイダとのデータ通信時などに相互認証鍵を適用した
相互認証処理が実行される。相互認証の成立を条件とし
て、相互認証時に生成したセッション鍵で暗号化してセ
キュリティチップ内部と外部間のデータ転送が実行され
る。

【００８４】デバイス対応ストレージ鍵は、セキュリテ
ィチップ内部のデータを外部に保持する場合に、データ
を暗号化し、閲覧・改竄を防ぐための鍵である。デバイ
ス・ストレージ鍵は、公開鍵系でも共通鍵系でもどちら
でもよい。乱数生成用シードは、擬似乱数を算術演算に
より求める際に、初期シードとして用いるデータであ
る。乱数生成用暗号鍵を用いて擬似乱数を算術演算して
乱数を生成する。

【００８５】共通鍵系デバイス対応ストレージ鍵には、
システムホルダと、デバイスのみが共有する鍵として構
成されるグローバル共通鍵が含まれ、グローバル共通鍵
は、サービスプロバイダにおける復号化処理を防止した
暗号化コンテンツ鍵の配信処理を実行する際に用いられ
る。グローバル共通鍵については、後段で詳細に説明す
る。

【００８６】（２）システム管理領域システム管理領域は、デバイス管理領域と同様にメモリ
領域に確保される。システム管理領域では、以下のデー
タを保持・管理する。ルート認証局（ＣＡ）公開鍵証明書デバイス公開鍵証明書デバイス秘密鍵

【００８７】ルート認証局（ＣＡ）公開鍵証明書は、セ
キュリティチップ内の認証系すべての根源となる証明書
で、他の証明書の署名検証を辿って、前述の連鎖検証を
行なうと、最後にはルート認証局（ＣＡ）の公開鍵証明
書に辿り着くことになる。

【００８８】デバイス公開鍵証明書は、サービスプロバ
イダとの相互認証時に用いる公開鍵証明書である。デバ
イス秘密鍵を外部で生成し、インポートする場合には、
デバイス公開鍵証明書も同時に生成される。デバイス側
でデバイス秘密鍵・公開鍵を生成する場合には、デバイ
ス内でデバイス秘密鍵・公開鍵が生成された後に、デバ
イス公開鍵がデバイスから読み出され、デバイス公開鍵
証明書の発行処理を行ない、発行されたデバイス公開鍵
証明書のインポートが行われる。

【００８９】デバイス秘密鍵は、データに対して署名付
けおよび認証するための鍵である。秘密鍵は、公開鍵と
ペアで生成されるが、予め外部で生成して、デバイスに
セキュアにインポートする構成とするか、デバイス内部
で生成し、決して外部に出さない構成とするかのいずれ
かの構成とする。

【００９０】（３）サービスプロバイダ管理領域サービスプロバイダ（ＳＰ）管理領域は、サービスプロ
バイダ（ＳＰ）管理テーブルとサービスプロバイダ（Ｓ
Ｐ）管理情報とからなる。サービスプロバイダ（ＳＰ）
管理テーブルは、サービスプロバイダ（ＳＰ）管理領域
内で各サービスプロバイダ（ＳＰ）情報の所在を示すた
めのテーブルでありサービスプロバイダの識別子に対応
させてメモリの各サービスプロバイダ（ＳＰ）情報の格
納位置情報を持つ。

【００９１】なお、サービスプロバイダ（ＳＰ）管理領
域には、ユーザデバイスがサービスプロバイダ（ＳＰ）
毎に会員登録を行うことにより、サービスプロバイダ
（ＳＰ）毎の領域がデバイス内のメモリ領域に確保され
る。なお、領域確保あるいは削除処理は、属性証明書の
記述に基づいて実行される。サービスプロバイダ（Ｓ
Ｐ）管理領域には、以下の情報を保持する。

【００９２】サービスプロバイダ（ＳＰ）対応秘密鍵サービスプロバイダ（ＳＰ）対応ストレージ秘密鍵（公
開鍵方式）サービスプロバイダ（ＳＰ）対応ストレージ鍵（共通鍵
方式）外部管理情報のハッシュ値コンテンツ利用回数管理データ認証情報ユーザ情報

【００９３】サービスプロバイダ（ＳＰ）対応秘密鍵
は、登録サービスプロバイダ（ＳＰ）毎に対応して生成
した登録サービスプロバイダ（ＳＰ）との相互認証処理
または暗号化データ転送処理等に適用する公開鍵と秘密
鍵のペアの秘密鍵である。登録サービスプロバイダ（Ｓ
Ｐ）と、セキュリティチップとが相互認証する場合に必
要とする鍵である。

【００９４】サービスプロバイダ（ＳＰ）対応ストレー
ジ秘密鍵（公開鍵方式）は、サービスプロバイダの提供
するコンテンツ利用をオフラインで利用可能である場
合、すなわち、取得したコンテンツを利用する毎にサー
ビスプロバイダとの接続を必要としないコンテンツであ
る場合、コンテンツに対応する暗号化コンテンツ鍵の復
号用の鍵である。暗号化コンテンツ鍵は、サービスプロ
バイダ（ＳＰ）対応ストレージ秘密鍵に対応するサービ
スプロバイダ（ＳＰ）対応ストレージ公開鍵によってサ
ービスプロバイダにおいて暗号化されて属性証明書（Ａ
Ｃ）に格納されてユーザデバイスに送信され、ユーザデ
バイスのセキュリティチップ内でサービスプロバイダ
（ＳＰ）対応ストレージ秘密鍵で復号してコンテンツ鍵
の取得が可能となる。

【００９５】サービスプロバイダ（ＳＰ）対応ストレー
ジ鍵（共通鍵方式）は、サービスプロバイダの提供する
コンテンツ利用をオフラインで利用可能である場合、す
なわち、取得したコンテンツを利用する毎にサービスプ
ロバイダとの接続を必要としないコンテンツである場
合、コンテンツに対応する暗号化コンテンツ鍵の復号用
の鍵であり、暗号化、復号化処理に共通に適用可能な鍵
である。なお、サービスプロバイダ（ＳＰ）対応ストレ
ージ秘密鍵（公開鍵方式）と、サービスプロバイダ（Ｓ
Ｐ）対応ストレージ鍵（共通鍵方式）は、いずれか一方
のみを格納し適用する構成としてもよい。。

【００９６】外部管理情報のハッシュ（Ｈａｓｈ）値
は、セキュリティチップ内部で管理するには大きすぎる
データを外部メモリの特定領域に出し、その領域のハッ
シュ値をセキュリティチップ内で管理することにより、
改竄ができないようにするものである。例えば、コンテ
ンツの回数利用制限をかける場合に、残回数などがハッ
シュ値による管理対象となる。回数管理コンテンツの場
合、回数情報の閲覧自体は問題ないが、改竄は防がなく
てはならない。署名付けやハッシュをとるだけでは改竄
は可能であるが、検出できれば実質的に改竄できないこ
とと同様の効果がある。

【００９７】コンテンツ利用回数管理データアプリケーション（コンテンツ）の利用可能回数をセキ
ュリティチップがローカルで管理する場合がある。この
時、セキュリティチップ内部では、アプリケーションＩ
Ｄ、属性証明書（ＡＣ）のシリアル、利用可能回数とを
保持・管理する。コンテンツ利用回数管理データの管理
処理については、後段で詳細に説明する。

【００９８】認証情報認証情報とは、サービスプロバイダ（ＳＰ）管理領域で
管理される管理情報を保護する目的の情報である。ユー
ザはサービスプロバイダ（ＳＰ）接続時にはサービスプ
ロバイダ（ＳＰ）との相互認証が必要となるが、相互認
証に必要な情報は、サービスプロバイダ（ＳＰ）管理領
域に格納される。この管理領域から必要情報を取得する
ために用いるのが認証情報である。認証情報は具体的に
は、例えばパスワードである。認証情報（パスワード）
をユーザが忘れた場合には、サービスプロバイダ（Ｓ
Ｐ）管理領域の管理情報の利用許諾が得られなくなる。
この場合には、マスター・パスワードを入力することに
より認証情報自体のリセット、または変更を行うことが
できる。これらの処理構成については、後段で詳細に説
明する。

【００９９】ユーザ情報ユーザ情報は、サービスプロバイダ（ＳＰ）により割り
振られたユーザＩＤなどのユーザ固有情報である。

【０１００】［パスワード管理］以下、図１に示すユー
ザデバイス１０１が、サービスプロバイダ（コンテンツ
ディストリビュータ）１０２の提供するコンテンツを受
領し、属性証明書に従った利用制限の下にコンテンツを
利用する処理、およびコンテンツ利用に際して必要とな
る各種処理の詳細について説明する。まず、コンテンツ
を提供するサービスプロバイダに関する情報を格納した
ユーザデバイス内のメモリ領域のサービスプロバイダ管
理領域へのアクセス制御用の認証情報（パスワード）に
ついて説明する。

【０１０１】（１）認証情報（パスワード）登録処理ユーザデバイスを購入したユーザがシステムホルダの管
理下にある様々なサービスプロバイダからコンテンツを
購入する処理、あるいは購入したコンテンツを利用する
処理を行なうためには、ユーザデバイス内のメモリ領域
にサービスプロバイダ管理領域を設定し、このサービス
プロバイダ管理領域にサービスプロバイダ毎の管理情報
を格納する処理が必要となる。ユーザデバイス内のメモ
リ領域にサービスプロバイダ管理領域の設定されたサー
ビスプロバイダを、以下登録サービスプロバイダと呼
ぶ。サービスプロバイダ管理領域の設定には、前述の属
性証明書を適用し、ユーザデバイスがサービスプロバイ
ダから受信した属性証明書に基づいて、ユーザデバイス
内のメモリ領域に属性証明書の記録に従ったサービスプ
ロバイダ管理領域の設定処理を実行する。

【０１０２】サービスプロバイダ管理領域を持つ登録サ
ービスプロバイダに対して、ユーザデバイスがアクセス
してコンテンツの購入、あるいは利用を行なうために
は、先ず、ユーザデバイス内のサービスプロバイダ管理
領域内の情報を取得することが必要となる。サービスプ
ロバイダ管理領域には、ユーザデバイスとサービスプロ
バイダ間の相互認証処理に必要な情報が格納されてお
り、これらの情報を取得してサービスプロバイダとの相
互認証を行なうことが必要となるからである。

【０１０３】このサービスプロバイダ管理領域にアクセ
スするためにユーザは各登録サービスプロバイダ毎に設
定される認証情報(パスワード)を、ユーザデバイスの入
力手段を介して入力することが必要となる。なお、以下
の説明において、「サービスプロバイダ毎に」との記述
は、「各登録サービス毎かつ各ユーザ毎」と同義であ
る。セキュリティチップ側で入力パスワードと登録パス
ワードの一致検証を行ない、一致した場合に限り、セキ
ュリティチップ内のメモリに形成されたサービスプロバ
イダ管理領域内の情報取得が可能となり、その後のサー
ビスプロバイダとの相互認証処理、へのアクセスが可能
となる。

【０１０４】認証情報（パスワード）は、ユーザデバイ
スに登録されたサービスプロバイダ毎に設定される。こ
れらのパスワードの初期登録は、ユーザ自身が実行す
る。パスワードの初期登録処理について、図８を参照し
て説明する。図８のシーケンス図において、左側がセキ
ュリティチップ、右側がセキュリティチップを持つユー
ザデバイスにおけるユーザインタフェース側処理であ
る。

【０１０５】まず、（１）パスワード登録対象となる対
応するサービスプロバイダを指定して認証情報（パスワ
ード）初期登録処理開始要求をユーザが入力する。
（２）セキュリティチップ側では、ユーザの指定したサ
ービスプロバイダが、セキュリティチップ内のメモリに
すでに管理領域を設定済みの登録サービスプロバイダで
あり、パスワード設定されていない状態であるか等のス
テータス確認処理を行ない、これらが確認された場合
に、（３）認証情報（パスワード）初期登録処理を許可
する。

【０１０６】次に、ユーザはユーザインタフェース側か
らキーボード等の入力手段を介し、（４）パスワードを
入力し、（５）セキュリティチップの制御部は入力され
た認証情報（パスワード）をテンポラリにメモリに保持
し、（６）同一パスワードの再入力要求を行ない、
（７）ユーザにより認証情報（パスワード）の再入力が
なされると、（８）セキュリティチップの制御部は再入
力認証情報（パスワード）とテンポラリにメモリに保持
してある認証情報（パスワード）の照合を実行し、照合
が成立した場合には、（９）認証情報（パスワード）の
書き込み処理を実行し、（１０）書き込み結果をユーザ
に通知し、ＯＫなら終了する。（１１）ＮＧの場合は、
（１）の処理に戻る。

【０１０７】（２）認証情報（パスワード）変更処理図９および図１０にパスワードの変更処理のシーケンス
図を示す。パスワード変更は、登録済みパスワードを用
いた変更処理（通常時）と、マスターパスワードを用い
た変更処理（緊急時）の２つの処理態様がある。

【０１０８】まず、図９のシーケンス図に基づいて、通
常時のパスワード変更処理、すなわち、登録済みパスワ
ードを用いた変更処理について説明する。左側がセキュ
リティチップ、右側がセキュリティチップを持つユーザ
デバイスのユーザインタフェース側処理である。

【０１０９】まず、（１）パスワード変更処理対象とな
る対応するサービスプロバイダを指定して認証情報（パ
スワード）変更処理開始要求をユーザが入力する。
（２）セキュリティチップ側では、ユーザの指定したサ
ービスプロバイダがメモリに管理領域を設定され登録済
みのサービスプロバイダ（ＳＰ）であり、パスワードの
設定されたＳＰであるか等のステータス確認を処理を行
ない、これらが確認されたことを条件として、（３）登
録済みの認証情報（パスワード）入力要求を行なう。ユ
ーザはユーザインタフェース側からキーボード等の入力
手段を介し、（４）登録済みパスワードを入力し、
（５）セキュリティチップの制御部は入力を確認する
と、サービスプロバイダ管理領域に書き込まれている登
録認証情報（パスワード）との照合処理を実行する。

【０１１０】照合が成立すると、（６）変更処理許可を
通知する。ユーザはユーザインタフェース側からキーボ
ード等の入力手段を介し、（７）新たな認証情報（パス
ワード）を入力し、（８）セキュリティチップの制御部
は入力された認証情報（パスワード）をテンポラリにメ
モリに保持し、（９）同一パスワードの再入力要求を行
ない、（１０）ユーザにより認証情報（パスワード）の
再入力がなされると、（１１）セキュリティチップの制
御部は再入力認証情報（パスワード）とテンポラリにメ
モリに保持してある認証情報（パスワード）の照合を実
行し、照合が成立した場合には、（１２）認証情報（パ
スワード）の書き込み処理を実行し、（１３）書き込み
結果をユーザに通知し、ＯＫなら終了する。（１４）Ｎ
Ｇの場合は、（１）の処理に戻る。

【０１１１】（３）マスターパスワードを用いた認証情
報（パスワード）リセット処理次に、図１０のシーケンス図に基づいて、緊急時のパス
ワード変更処理等において実行されるマスターパスワー
ドを用いた認証情報（パスワード）リセット処理につい
て説明する。左側がセキュリティチップ、右側がセキュ
リティチップを持つユーザデバイスを装着した端末にお
けるユーザインタフェース側処理である。

【０１１２】まず、（１）パスワード変更処理対象とな
る対応するサービスプロバイダを指定して認証情報（パ
スワード）リセット処理開始要求をユーザが入力する。
（２）セキュリティチップ側では、ユーザの指定したサ
ービスプロバイダがメモリに管理領域を設定され登録済
みのサービスプロバイダ（ＳＰ）であり、パスワードの
設定されたＳＰであるか等のステータス確認を処理を行
ない、これらの条件を満足する場合に、（３）マスター
パスワード入力要求を行なう。ユーザはユーザインタフ
ェース側からキーボード等の入力手段を介し、（４）マ
スターパスワードを入力し、（５）セキュリティチップ
の制御部は入力されたマスターパスワードの照合処理を
実行し、正しいマスターパスワードの入力であるか否か
を判定し、検証の結果、正しいマスターパスワード入力
であると判定すると、（６）サービスプロバイダ管理領
域に書き込まれている登録認証情報（パスワード）の初
期化、すなわち登録済み認証情報（パスワード）のリセ
ット処理を実行する。

【０１１３】セキュリティチップの制御部は、リセット
処理の後、（７）処理結果通知をユーザに通知し、ＯＫ
であれば、例えば、ユーザは前述の認証情報（パスワー
ド）登録処理を実行する。これらの処理は、先に図８を
参照して説明した処理と同様であるので説明を省略す
る。（８）リセット処理結果がＮＧの場合は、（１）の
処理に戻る。

【０１１４】図１０の処理シーケンスを用いて説明した
ように、マスターパスワードは、各登録サービスプロバ
イダについて登録済みの認証情報(パスワード)の初期化
処理、すなわちリセットする際に適用される。マスター
パスワードを用いた認証情報初期化（リセット）処理
は、セキュリティチップに登録されたサービスプロバイ
ダすべての認証情報に対して有効である。

【０１１５】図１１にマスターパスワードと各登録サー
ビスプロバイダの認証情報（パスワード）との関係図を
示す。図１１に示すようにマスターパスワードは、各サ
ービスプロバイダ対応認証情報に対する上位パスワード
として存在し、マスターパスワードの入力により、各各
登録サービスプロバイダの認証情報（パスワード）の初
期化（リセット）が実行され、新たな認証情報を各登録
サービスプロバイダの認証情報（パスワード）として再
登録することが可能となる。

【０１１６】マスターパスワードは、図１２に示すよう
に、ユーザデバイスの購入時に例えばプリントされた用
紙がデバイスに添付されて配布される。マスターパスワ
ードはデバイスの製造時に工場で書き込まれるが、ユー
ザによるマスターパスワードのデバイスからの読み出し
はできない構成となっている。マスターパスワードは、
デバイスに固有の識別子であるデバイスＩＤと、マスタ
ーキーに基づいて生成される。マスターキーは情報処理
装置個々または一群の情報処理装置に対応して設定され
るキーである。

【０１１７】マスターパスワードをユーザが忘れた場合
には、サポートセンターへの登録を条件としてマスター
パスワードの再発行処理が可能となる。図１３にサポー
トセンタへのユーザ登録処理および、マスターパスワー
ドの再発行処理シーケンス図を示す。

【０１１８】図１３の上段が、サポートセンタに対する
ユーザ登録処理シーケンス図を示す。ユーザは購入デバ
イスに添付された登録用紙の郵送、あるいはデバイスを
設定した端末を介してサポートセンタに接続してユーザ
登録を行なうことができる。ユーザ登録は、ユーザ住
所、電話番号、デバイスのＩＤ等のデータをサポートセ
ンタに登録する処理として実行され、サポートセンタに
おいてユーザ登録が完了すると、ユーザ登録完了通知が
サポートセンタからユーザに送付または送信される。

【０１１９】図１３の下段が、ユーザがマスターパスワ
ードを忘れた場合に、ユーザと、サポートセンタ間で実
行されるマスターパスワード再発行処理のシーケンスで
ある。ユーザは、デバイスＩＤを伴うユーザ情報データ
とともに、マスターパスワードの再発行要求をサポート
センタに対して送信し、サポートセンタが要求を受信す
ると、サポートセンタは、ユーザ情報、ユーザＩＤが登
録済みデータと一致するかを判定し、一致した場合は、
ユーザデバイスＩＤに基づくマスターパスワードの検索
あるいはマスターキーを用いたマスターパスワードの生
成処理を実行する。サポートセンタは、情報処理装置と
してのユーザデバイスに対応して設定されたデバイス識
別子としてのデバイスＩＤと、マスターパスワードとを
対応させたマスターパスワード格納データベースを有す
る。あるいは、デバイスＩＤと、デバイス個々に固有の
キー、または一群のデバイスに共通するキーとして設定
されたマスターキーとを対応させたマスターキー格納デ
ータベースのいずれかを有し、マスターパスワード格納
データベースを有する場合には、デバイスＩＤに基づい
てデータベース検索を実行してマスターパスワードを取
得する。マスターキー格納データベースを有する場合に
は、デバイスＩＤに対する、マスターキーを適用した暗
号処理によるマスターパスワード生成処理を実行し、生
成したマスターパスワードをユーザデバイスに送付する
処理を実行する。

【０１２０】ユーザデバイスＩＤに基づくマスターキー
によるマスターパスワードの生成処理フローを図１４に
示す。図１４のフローについて説明する。まず、ステッ
プＳ１０１において、マスターキーＫｍ１を用いてデバ
イスＩＤの暗号化処理を実行する。その結果をステップ
Ｓ１０２において、ＭＰａとする。さらに、結果ＭＰａ
に対してマスタキーＫｍ２を適用した暗号化処理を実行
してパスワードＭＰを得て、ステップＳ１０３におい
て、ＡＳＣＩＩコードに変換する。暗号化処理は例えば
ＤＥＳ，トリプルＤＥＳ等の暗号化アルゴリズムが適用
可能である。マスターキーＫｍ１，Ｋｍ２は、複数のデ
バイスに対して共通に設定されたキーであり、サポート
センタはユーザデバイスＩＤに基づいて、サポートセン
タで保持する複数のキーから適用すべきマスターキーを
選択して使用する。

【０１２１】図１３のシーケンス図に戻って説明を続け
る。サポートセンタでマスターパスワードの生成が実行
されると、サポートセンタは、マスターパスワードをオ
ンラインまたはオフラインでユーザまたはユーザデバイ
スに対して送信または送付する。

【０１２２】以上のシーケンスに従って、ユーザは、サ
ポートセンタを利用してマスターパスワードの再発行処
理を行なうことができる。なお、ユーザデバイスと、サ
ポートセンタ間においては、データ送受信の前処理とし
て相互認証処理を実行し、送受信する秘密データ、例え
ばユーザＩＤ、マスターパスワード等は相互認証時に生
成したセッションキーで暗号化し、またデータの改竄防
止のために署名の生成、検証を行なうことが好ましい。
なお、これら相互認証処理、署名生成、検証処理等の詳
細については、コンテンツの配信処理の項目で詳しく説
明する。

【０１２３】また、ユーザは、サポートセンタを利用し
たマスターパスワードの再発行処理をオフラインで行な
うことも可能である。この場合は、ハガキなどに本人確
認のための情報を記入して送付するなどの処理が行なわ
れることになる。

【０１２４】［コンテンツ配信処理］ユーザデバイス内
のセキュリティチップ内のメモリ領域にサービスプロバ
イダの管理領域が登録され、サービスプロバイダとの認
証に必要な情報、上記パスワード等が登録されると、こ
れらの情報を用いてサービスプロバイダとの通信による
コンテンツ購入が可能となる。以下、コンテンツ購入処
理の詳細について説明する。

【０１２５】コンテンツ購入処理における概要を説明す
るシーケンス図を図１５に示す。左側がセキュリティチ
ップを持つユーザデバイス側処理であり、右側がサービ
スプロバイダ側処理である。

【０１２６】ユーザデバイスは、まず、コンテンツの購
入要求をサービスプロバイダに出力する。サービスプロ
バイダがコンテンツ購入要求を受信すると、ユーザデバ
イスとサービスプロバイダ間において相互認証が実行さ
れる。相互認証が成立し、双方の正当性が確認される
と、サービスプロバイダは、購入要求コンテンツに対応
する属性証明書（ＡＣ:Attribute Certificate）を生成
し、ユーザデバイスに送信する。属性証明書には、コン
テンツを復号するためのコンテンツ鍵：Ｋｃが暗号化さ
れて格納され、また、利用回数、利用期限等のコンテン
ツ利用条件が記録されている。また格納データに対して
属性証明書発行者である属性証明書認証局（ＡＡ:Attri
bute Certificate Authority）の署名がなされており、
改竄防止を考慮したものとなっている。

【０１２７】属性証明書を受信したユーザデバイスは、
属性証明書の署名検証処理を実行し、改竄なしの判定に
基づいて属性証明書をメモリに保存する。さらに、ユー
ザデバイスは、コンテンツの要求をサービスプロバイダ
に対して行ない、サービスプロバイダは、先にユーザデ
バイスに送付した属性証明書内に格納されたコンテンツ
鍵：Ｋｃで暗号化したコンテンツをユーザデバイスに送
付する。ユーザデバイス側では、属性証明書から取り出
した暗号化されたコンテンツ鍵の復号化処理を実行して
コンテンツ鍵を取り出し、取り出したコンテンツ鍵を適
用した暗号化コンテンツの復号化処理によりコンテンツ
を取得し、利用する。なお、属性証明書に格納したコン
テンツ鍵の復号化処理をサービスプロバイダ側で実行す
る態様（オンライン復号）もある。これらの具体的処理
例については、後段で説明する。

【０１２８】コンテンツ配信に伴う大まかな流れは、以
上、図１５を用いて説明した通りである。以下、各処理
の詳細について説明する。なお、図１５に示した処理シ
ーケンスでは、コンテンツに対応する属性証明書を暗号
化コンテンツ送付の先に実行しているが、暗号化コンテ
ンツの配信と、属性証明書の配信はいずれが先でもよ
く、同時に配信する処理としてもよい。また、それぞれ
をディスク等の記録媒体に格納して配信するオフライン
配信を行なう構成とすることも可能である。

【０１２９】また、サービスプロバイダからユーザデバ
イスに対するコンテンツ配信あるいは属性証明書（Ａ
Ｃ：Attribute Certificate）の配信形態としては、ユ
ーザ側からサービスプロバイダに対する要求に基づいて
実行される形態と、ユーザの要求の有無に関係なく例え
ばサブスクライバ契約を結んでいるユーザに対して、サ
ービスプロバイダから一方的に送信するいわゆるプッシ
ュ型の形態(プッシュ型モデル)のいずれの形態も可能で
ある。プッシュ型モデルにおいては、サービスプロバイ
ダが予め目標ユーザ向けの属性証明書（ＡＣ）を作成し
て配信することになる。

【０１３０】（１）相互認証処理、コンテンツの購入要求エンティテイであるユーザデバイ
ス、およびコンテンツの提供元であるサービスプロバイ
ダ間では、まず相互認証処理が実行される。データ送受
信を実行する２つの手段間では、相互に相手が正しいデ
ータ通信者であるか否かを確認して、その後に必要なデ
ータ転送を行なうことが行われる。相手が正しいデータ
通信者であるか否かの確認処理が相互認証処理である。
相互認証処理時にセッション鍵の生成を実行して、生成
したセッション鍵を共有鍵として暗号化処理を実行して
データ送信を行なう構成が１つの好ましいデータ転送方
式である。相互認証方式としては、公開鍵暗号方式、共
通鍵暗号方式等、各方式の適用が可能である。

【０１３１】ここでは、公開鍵暗号方式の１つの認証処
理方式であるハンドシェイクプロトコル（ＴＬＳ１．
０）について図１６のシーケンス図を参照して説明す
る。

【０１３２】図１６において、左側がユーザデバイス
(クライアント)の処理、右側がサービスプロバイダ（サ
ーバ）側の処理を示している。まず、（１）サービスプ
ロバイダ（サーバ）が暗号化仕様を決定するためのネゴ
シエーション開始要求をハローリクエストとしてユーザ
デバイス（クライアント）に送信する。（２）ユーザデ
バイス（クライアント）はハローリクエストを受信する
と、利用する暗号化アルゴリズム、セッションＩＤ、プ
ロトコルバージョンの候補をクライアントハローとし
て、サービスプロバイダ（サーバ）側に送信する。

【０１３３】（３）サービスプロバイダ（サーバ）側
は、利用を決定した暗号化アルゴリズム、セッションＩ
Ｄ、プロトコルバージョンをサーバーハローとしてユー
ザデバイス（クライアント）に送信する。（４）サービ
スプロバイダ（サーバ）は、自己の所有するルートＣＡ
までの公開鍵証明書（Ｘ．５０９ｖ３）一式をユーザデ
バイス（クライアント）に送信（サーバ・サーティフィ
ケート）する。なお、証明書連鎖をたどって最上位の公
開鍵証明書まで順に検証を実施しない場合には、必ずし
もルートＣＡまでの公開鍵証明書（Ｘ．５０９ｖ３）一
式を送付する必要はない。（５）サービスプロバイダ
（サーバ）は、ＲＳＡ公開鍵またはＤｉｆｆｉｅ＆Ｈｅ
ｌｌｍａｎ公開鍵情報をユーザデバイス（クライアン
ト）に送信（サーバ・キー・エクスチェンジ）する。こ
れは証明書が利用できない場合に一時的に適用する公開
鍵情報である。

【０１３４】（６）次にサービスプロバイダ（サーバ）
側は、ユーザデバイス（クライアント）に対してサーテ
ィフイケート・リクエストとして、ユーザデバイス（ク
ライアント）の有する証明書を要求し、（７）サービス
プロバイダ（サーバ）によるネゴシエーション処理の終
了を知らせる（サーバハロー終了）。

【０１３５】（８）サーバハロー終了を受信したユーザ
デバイス（クライアント）は、自己の所有するルートＣ
Ａまでの公開鍵証明書（Ｘ．５０９ｖ３）一式をサービ
スプロバイダ（サーバ）に送信（クライアント・サーテ
ィフィケート）する。なお、公開鍵証明書の連鎖検証を
行なわない場合は公開鍵証明書の一式送付は必須ではな
い。（９）ユーザデバイス（クライアント）は、４８バ
イト乱数をサービスプロバイダ（サーバ）の公開鍵で暗
号化してサービスプロバイダ（サーバ）に送信する。サ
ービスプロバイダ（サーバ）、ユーザデバイス（クライ
アント）は、この値をもとに送受信データ検証処理のた
めのメッセージ認証コード：ＭＡＣ（Message Authenti
cation Code）生成用のデータ等を含むマスターシーク
レットを生成する。

【０１３６】（１０）ユーザデバイス（クライアント）
は、クライアント証明書の正しさを確認するため、ここ
までのメッセージのダイジェストをクライアントの秘密
鍵で暗号化してサービスプロバイダ（サーバ）に送信
（クライアントサーティフィケート確認）し、（１１）
先に決定した暗号化アルゴリズム、鍵利用の開始を通知
（チェンジ・サイファー・スペック）し、（１２）認証
の終了を通知する。一方、（１３）サービスプロバイダ
（サーバ）側からユーザデバイス（クライアント）に対
しても、先に決定した暗号化アルゴリズム、鍵利用の開
始を通知（チェンジ・サイファー・スペック）し、（１
４）認証の終了を通知する。

【０１３７】上記処理において決定された暗号化アルゴ
リズムに従ってユーザデバイス（クライアント）とサー
ビスプロバイダ（サーバ）間のデータ転送が実行される
ことになる。

【０１３８】データ改竄の検証は、上述の認証処理でユ
ーザデバイス（クライアント）とサービスプロバイダ
（サーバ）間の合意のもとに生成されたマスターシーク
レットから算出されるメッセージ認証コード：ＭＡＣ
（Message Authentication Code）を各エンティテイの
送信データに付加することでメッセージの改竄検証を行
なう。

【０１３９】図１７にメッセージ認証コード：ＭＡＣ
（Message Authentication Code）の生成構成を示す。
データ送信側は、送信データに対して、認証処理におい
て生成したマスターシークレットに基づいて生成される
ＭＡＣシークレットを付加し、これらの全体データから
ハッシュ値を計算し、さらにＭＡＣシークレット、パデ
ィング、ハッシュ値に基づいてハッシュ算出を行なって
メッセージ認証コード（ＭＡＣ）を生成する。この生成
したＭＡＣを送信データに付加して、受信側で受信デー
タに基づいて生成したＭＡＣと受信ＭＡＣとの一致が認
められればデータ改竄なしと判定し、一致が認められな
い場合には、データの改竄があったものと判定する。

【０１４０】（２）コンテンツ利用権限情報証明書（属
性証明書）の生成、送信ユーザデバイスからコンテンツの要求がなされたサービ
スプロバイダは、要求コンテンツの復号化処理に適用可
能なコンテンツ鍵：Ｋｃを暗号化して格納し、コンテン
ツの利用制限情報を格納したコンテンツ利用権限情報証
明書、例えば属性証明書（ＡＣ）を生成して、ユーザに
対して送信する。

【０１４１】コンテンツ利用権限情報証明書、例えば属
性証明書（ＡＣ）を生成する主体は、サービスプロバイ
ダ自身であっても、またコンテンツ管理を実行する外部
エンティティであってもよい。外部エンティテイが属性
証明書（ＡＣ）を生成する場合は、サービスプロバイダ
の要求に従ってその外部エンティテイが属性証明書（Ａ
Ｃ）を生成する。

【０１４２】属性証明書には対応暗号化コンテンツの復
号に適用可能なコンテンツ鍵：Ｋｃが暗号化されて格納
される。コンテンツ鍵Ｋｃの暗号化に適用する鍵には、
例えば、（ａ）ユーザデバイスのセキュリティチップの各サービ
スプロバイダ管理領域に格納されたＳＰ対応ストレージ
秘密鍵に対応するサービスプロバイダ（ＳＰ）対応スト
レージ公開鍵：ＳＣ．Ｓｔｏｐｕｂ．ＳＰ．Ｋ（ｂ）サービスプロバイダの保有する秘密鍵（共通鍵
系）：ＳＰ．Ｓｔｏ．Ｋ（ｃ）システムホルダ（ＳＨ）とユーザデバイスで共有
する鍵として生成されるグローバル共通鍵：Ｋｇの各態様がある。なお、この他にも、いくつかの態様が
可能である。例えばサービスプロバイダの保有する公開
鍵で暗号化することも可能である。この場合は、ユーザ
デバイスから属性証明書（ＡＣ）を受信してサービスプ
ロバイダの保有する秘密鍵で復号化することになる。

【０１４３】なお、いずれの暗号化態様を適用した場合
でも、サービスプロバイダからユーザデバイスに対する
コンテンツ配信あるいは属性証明書（ＡＣ：Attribute
Certificate）の配信形態としては、ユーザ側からサー
ビスプロバイダに対する要求に基づいて実行される形態
と、ユーザの要求の有無に関係なく例えばサブスクライ
バ契約を結んでいるユーザに対して、サービスプロバイ
ダから一方的に送信するいわゆるプッシュ型の形態(プ
ッシュ型モデル)のいずれの形態も可能である。プッシ
ュ型モデルにおいては、サービスプロバイダが予め目標
ユーザ向けの属性証明書（ＡＣ）を作成して配信するこ
とになる。以下、上記（ａ）〜（ｃ）の態様における処
理の詳細について説明する。

【０１４４】（ａ）ＳＰ対応ストレージ秘密鍵に対応す
るサービスプロバイダ（ＳＰ）対応ストレージ公開鍵：
ＳＣ．Ｓｔｏｐｕｂ．ＳＰ．Ｋを適用した場合前述したユーザデバイスのセキュリティチップのメモリ
領域についての説明中で示したように、ユーザデバイス
に登録された各登録サービスプロバイダについては、メ
モリに形成された各サービスプロバイダ管理領域にＳＰ
対応ストレージ秘密鍵：ＳＣ．Ｓｔｏｐｒｉ．ＳＰ．Ｋ
が格納される。ユーザデバイスのセキュリティチップで
は、サービスプロバイダから提供されるコンテンツに対
応する属性証明書の中からＳＰ対応ストレージ秘密鍵に
対応するサービスプロバイダ（ＳＰ）対応ストレージ公
開鍵：ＳＣ．Ｓｔｏｐｕｂ．ＳＰ．Ｋで暗号化されたコ
ンテンツ鍵：Ｋｃ、すなわち、［ＳＣ．Ｓｔｏｐｕｂ．
ＳＰ．Ｋ（Ｋｃ）］を取り出して、ＳＰ対応ストレージ
秘密鍵：ＳＣ．Ｓｔｏｐｒｉ．ＳＰ．Ｋで復号化処理を
実行することにより、コンテンツ鍵：Ｋｃを取得する。
なお、［Ａ（Ｂ）］は、Ａで暗号化されたＢからなるデ
ータを示すものとする。本形態では、ユーザデバイス
は、コンテンツの利用時、すなわち復号時にサービスプ
ロバイダと接続することなくユーザデバイス内の処理と
してコンテンツ復号、すなわちオフライン復号が可能と
なる。

【０１４５】なお、上記例では、公開鍵暗号方式を適用
し、コンテンツ鍵の暗号化にＳＰ対応ストレージ公開
鍵：ＳＣ．Ｓｔｏｐｕｂ．ＳＰ．Ｋを用い、コンテンツ
鍵の復号にＳＰ対応ストレージ秘密鍵：ＳＣ．Ｓｔｏｐ
ｒｉ．ＳＰ．Ｋを用いた構成例について説明したが、共
通鍵方式を適用することも可能であり、共通鍵方式を適
用する場合は、コンテンツ鍵の暗号化、復号化の双方の
処理にＳＰ対応ストレージ鍵（共通鍵）：ＳＣ．Ｓｔ
ｏ．ＳＰ．Ｋを用いる。この場合、ＳＰ対応ストレージ
鍵（共通鍵）：ＳＣ．Ｓｔｏ．ＳＰ．Ｋは、セキュリテ
ィチップのメモリの対応するサービスプロバイダのサー
ビスプロバイダ管理領域に格納する。

【０１４６】（ｂ）サービスプロバイダの保有する秘密
鍵（共通鍵系）：ＳＰ．Ｓｔｏ．Ｋを適用した場合サービスプロバイダは、ユーザデバイスに対して提供す
るコンテンツに対応して設定される属性証明書に格納す
るコンテンツ鍵：Ｋｃをサービスプロバイダが保有する
秘密鍵：ＳＰ．Ｓｔｏ．Ｋを適用して暗号化する。ユー
ザデバイスは、属性証明書を受信しても、属性証明書に
格納された暗号化コンテンツ鍵：［ＳＰ．Ｓｔｏ．Ｋ
（Ｋｃ）］を復号することはできない。サービスプロバ
イダの保有する秘密鍵：ＳＰ．Ｓｔｏ．Ｋはユーザデバ
イスは保有していないからである。

【０１４７】従って、コンテンツを利用（復号化）する
ためには、次のような処理が必要となる。まず、ユーザ
デバイスは、サービスプロバイダに属性証明書を送付し
てコンテンツ鍵の復号要求を行ない、サービスプロバイ
ダにおいては、サービスプロバイダの保有する秘密鍵：
ＳＰ．Ｓｔｏ．Ｋによってコンテンツ鍵：Ｋｃの復号化
を行なう。ユーザデバイスはサービスプロバイダより復
号化されたコンテンツ鍵：Ｋｃを取得し、該コンテンツ
鍵：Ｋｃで暗号化コンテンツの復号を行なう。本形態で
は、上述の（ａ）の形態と異なり、ユーザデバイスは、
コンテンツの利用時、すなわち復号時にサービスプロバ
イダと接続することが必須となる。すなわちオンライン
処理が必要となる。

【０１４８】（ｃ）システムホルダ（ＳＨ）とユーザデ
バイスで共有する鍵として生成されるグローバル共通
鍵：Ｋｇを適用した場合このグローバル共通鍵を利用する形態は、コンテンツの
配信を実行するサービスプロバイダにおいて、システム
ホルダの許可なくコンテンツが配布、利用されることを
防止し、システムホルダ（ＳＨ）による管理されたコン
テンツ配信を行なうための構成である。サービスプロバ
イダに対してコンテンツを提供するコンテンツクリエー
タの有するコンテンツ製作者鍵、コンテンツ配信を行な
うサービスプロバイダの有するコンテンツ配信者鍵、そ
してシステムホルダ（ＳＨ）とユーザデバイスで共有す
る鍵として生成されるグローバル共通鍵：Ｋｇの各鍵を
組み合わせた暗号化処理を行なった暗号化鍵データを属
性証明書に格納し、コンテンツ利用者としてのエンドエ
ンティテイであるユーザデバイスに配布することで、サ
ービスプロバイダ自体もコンテンツ鍵を取り出すことを
防止し、ユーザデバイスにおいてのみコンテンツ鍵：Ｋ
ｃを取り出すことを可能とした構成である。

【０１４９】以下、これらの各形態について詳細に説明
する。まず、上記（ａ）〜（ｃ）に共通する属性証明書
の発行処理シーケンスについて図１８を用いて説明す
る。

【０１５０】図１８の処理シーケンスは、先に説明した
図１５のコンテンツ購入処理シーケンスの一部として構
成される属性証明書の生成、送信処理を詳細に説明した
ものである。ユーザデバイスはセキュリティチップを内
蔵し、セキュリティチップ内のメモリにはサービスプロ
バイダ管理領域が生成されており、サービスプロバイダ
管理情報が格納済みであるとする。

【０１５１】図１８の処理について説明する。ユーザデ
バイスとサービスプロバイダ間の相互認証が成立後、
（１）セキュリティチップを持つユーザデバイスは、サ
ービスプロバイダに対して属性証明書（ＡＣ）の要求を
行なう。属性証明書（ＡＣ）要求には、サービスプロバ
イダ管理領域に登録されたユーザＩＤ、コンテンツの指
定識別子としてのアプリケーションＩＤ、さらにユーザ
が選択した利用条件データにユーザの秘密鍵（サービス
プロバイダ対応秘密鍵）で署名したデータにユーザの公
開鍵証明書（ＰＫＣ）を添付して送信する。利用条件デ
ータは、例えばコンテンツ利用制限回数、利用期限等の
指定データであり、ユーザによって選択可能である場合
にユーザ指定データとして含まれる。

【０１５２】署名は、データ改竄の検証を可能とするた
めに付加されるものであり、前述のＭＡＣ値を用いるこ
とも可能であり、公開鍵暗号方式を用いた電子署名を適
用することも可能である。

【０１５３】公開鍵暗号方式を用いた電子署名の生成方
法について、図１９を用いて説明する。図１９に示す処
理は、ＥＣ−ＤＳＡ（（Elliptic Curve Digital Signa
tureAlgorithm）、IEEE P1363/D3）を用いた電子署名デ
ータの生成処理フローである。なお、ここでは公開鍵暗
号として楕円曲線暗号（Elliptic Curve Cryptosystem
（以下、ＥＣＣと呼ぶ））を用いた例を説明する。な
お、本発明のデータ処理装置においては、楕円曲線暗号
以外にも、同様の公開鍵暗号方式における、例えばＲＳ
Ａ暗号（（Rivest、Shamir、Adleman）など（ANSI X9.3
1））を用いることも可能である。

【０１５４】図１９の各ステップについて説明する。ス
テップＳ１において、ｐを標数、a、bを楕円曲線の係数
（楕円曲線：ｙ²＝ｘ³＋ａｘ＋ｂ，４ａ³＋２７ｂ²≠０
（ｍｏｄｐ））、Ｇを楕円曲線上のベースポイント、r
をＧの位数、Ｋｓを秘密鍵（０＜Ｋｓ＜ｒ）とする。ス
テップＳ２おいて、メッセージＭのハッシュ値を計算
し、f=Hash(M)とする。

【０１５５】ここで、ハッシュ関数を用いてハッシュ値
を求める方法を説明する。ハッシュ関数とは、メッセー
ジを入力とし、これを所定のビット長のデータに圧縮
し、ハッシュ値として出力する関数である。ハッシュ関
数は、ハッシュ値（出力）から入力を予測することが難
しく、ハッシュ関数に入力されたデータの1ビットが変
化したとき、ハッシュ値の多くのビットが変化し、ま
た、同一のハッシュ値を持つ異なる入力データを探し出
すことが困難である特徴を有する。ハッシュ関数として
は、ＭＤ４、ＭＤ５、ＳＨＡ−１などが用いられる場合
もあるし、ＤＥＳ−ＣＢＣが用いられる場合もある。こ
の場合は、最終出力値となるＭＡＣ（チェック値：ＩＣ
Ｖに相当する）がハッシュ値となる。

【０１５６】続けて、ステップＳ３で、乱数ｕ（０＜ｕ
＜ｒ）を生成し、ステップＳ４でベースポイントをｕ倍
した座標Ｖ（Ｘｖ，Ｙｖ）を計算する。なお、楕円曲線
上の加算、２倍算は次のように定義されている。

【０１５７】

【数１】P=(Ｘａ，Ｙａ),Q=(Ｘｂ，Ｙｂ),R=(Ｘｃ,Ｙ
ｃ)=P+Qとすると、 P≠Qの時（加算）、 Xｃ=λ²−Ｘａ−ＸｂＹｃ=λ×(Ｘａ−Ｘｃ)−Ｙａ λ=(Ｙｂ−Ｙａ)／(Ｘｂ−Ｘａ) P=Qの時（2倍算）、Ｘｃ=λ²−２ＸａＹｃ=λ×(Ｘａ−Ｘｃ)−Ｙａ λ=(３(Ｘａ)²＋ａ)／(２Ｙａ)

【０１５８】これらを用いて点Ｇのｕ倍を計算する（速
度は遅いが、最もわかりやすい演算方法として次のよう
に行う。Ｇ、２×Ｇ、４×Ｇ・・を計算し、uを2進数展
開して1が立っているところに対応する２ⁱ×Ｇ（Ｇをｉ
回２倍算した値（ｉはｕのＬＳＢから数えた時のビット
位置））を加算する。

【０１５９】ステップＳ５で、ｃ＝Ｘｖｍｏｄｒを計
算し、ステップＳ６でこの値が０になるかどうか判定
し、０でなければステップＳ７でｄ＝［（ｆ＋ｃＫｓ）
／ｕ］ｍｏｄｒを計算し、ステップＳ８でｄが０であ
るかどうか判定し、ｄが０でなければ、ステップＳ９で
ｃおよびｄを電子署名データとして出力する。仮に、ｒ
を１６０ビット長の長さであると仮定すると、電子署名
データは３２０ビット長となる。

【０１６０】ステップＳ６において、ｃが０であった場
合、ステップＳ３に戻って新たな乱数を生成し直す。同
様に、ステップＳ８でｄが０であった場合も、ステップ
Ｓ３に戻って乱数を生成し直す。

【０１６１】次に、公開鍵暗号方式を用いた電子署名の
検証方法を、図２０を用いて説明する。ステップＳ１１
で、Ｍをメッセージ、pを標数、a、bを楕円曲線の係数
（楕円曲線：ｙ²=ｘ³＋ａｘ＋ｂ，４ａ³＋２７ｂ²≠０
（ｍｏｄｐ））、Ｇを楕円曲線上のベースポイント、r
をＧの位数、ＧおよびＫｓ×Gを公開鍵（０＜Ｋｓ＜
ｒ）とする。ステップＳ１２で電子署名データｃおよび
ｄが０＜ｃ＜ｒ、０＜ｄ＜ｒを満たすか検証する。これ
を満たしていた場合、ステップＳ１３で、メッセージＭ
のハッシュ値を計算し、ｆ＝Ｈａｓｈ（Ｍ）とする。次
に、ステップＳ１４でh=1/d mod rを計算し、ステップ
Ｓ１５でｈ１＝ｆｈｍｏｄｒ、ｈ２=ｃｈｍｏｄ
ｒを計算する。

【０１６２】ステップＳ１６において、既に計算したｈ
１およびｈ２を用い、点Ｐ＝（Ｘｐ，Ｙｐ）＝ｈ１×Ｇ
＋ｈ２・Ｋｓ×Ｇを計算する。電子署名検証者は、ベー
スポイントＧおよびＫｓ×Ｇを知っているので、図１９
のステップＳ４と同様に楕円曲線上の点のスカラー倍の
計算ができる。そして、ステップＳ１７で点Ｐが無限遠
点かどうか判定し、無限遠点でなければステップＳ１８
に進む（実際には、無限遠点の判定はステップＳ１６で
できてしまう。つまり、Ｐ＝（Ｘ，Ｙ）、Ｑ＝（Ｘ，−
Ｙ）の加算を行うと、λが計算できず、Ｐ＋Ｑが無限遠
点であることが判明している）。ステップＳ１８でＸｐ
ｍｏｄｒを計算し、電子署名データｃと比較する。最
後に、この値が一致していた場合、ステップＳ１９に進
み、電子署名が正しいと判定する。

【０１６３】電子署名が正しいと判定された場合、デー
タは改竄されておらず、公開鍵に対応した秘密鍵を保持
する者が電子署名を生成したことがわかる。

【０１６４】ステップＳ１２において、電子署名データ
ｃまたはｄが、０＜ｃ＜ｒ、０＜ｄ＜ｒを満たさなかっ
た場合、ステップＳ２０に進む。また、ステップＳ１７
において、点Ｐが無限遠点であった場合もステップＳ２
０に進む。さらにまた、ステップＳ１８において、Ｘｐ
ｍｏｄｒの値が、電子署名データｃと一致していなか
った場合にもステップＳ２０に進む。

【０１６５】ステップＳ２０において、電子署名が正し
くないと判定された場合、データは改竄されているか、
公開鍵に対応した秘密鍵を保持する者が電子署名を生成
したのではないことがわかる。上述したように、署名付
けやハッシュをとるだけでは改竄は可能であるが、検出
により実質的に改竄できないことと同様の効果がある。

【０１６６】属性証明書（ＡＣ）要求を受信したサービ
スプロバイダは、上述の署名検証処理等によって要求デ
ータに改竄がないことを確認すると、アプリケーション
ＩＤで特定されるコンテンツに対応するコンテンツ鍵：
Ｋｃを暗号化する。このコンテンツ鍵：Ｋｃの暗号化に
適用する鍵は、前述の（ａ）ユーザデバイスのセキュリ
ティチップの各サービスプロバイダ管理領域に格納され
たＳＰ対応ストレージ秘密鍵：ＳＣ．Ｓｔｏｐｒｉ．Ｓ
Ｐ．Ｋ、（ｂ）サービスプロバイダの保有する秘密鍵：
ＳＰ．Ｓｔｏ．Ｋ、（ｃ）システムホルダ（ＳＨ）とユ
ーザデバイスで共有する鍵として生成されるグローバル
共通鍵：Ｋｇのいずれかである。

【０１６７】さらに、サービスプロバイダは、コンテン
ツの利用条件データ他の必要データを格納し、前述した
図５に示す属性証明書を生成する。生成した属性証明書
には、サービスプロバイダの秘密鍵を用いた電子署名が
付加される。電子署名の生成処理は、図１９の処理フロ
ーと同様の処理に従って実行される。サービスプロバイ
ダによって生成された属性証明書はユーザデバイスに送
付され、ユーザデバイスにおいて、上述の図２０の処理
フローと同様のシーケンスに従って署名検証処理を実行
する。

【０１６８】さらに、必要に応じてユーザデバイスは、
属性証明書（ＡＣ）内のＡＣ保持者の公開鍵証明書情報
に従ってリンクする公開鍵証明書を取得して、公開鍵証
明書の検証を行なうことが好ましい。例えば属性証明書
（ＡＣ）の発行者の信頼度が不確かである場合には、属
性証明書（ＡＣ）の発行者の公開鍵証明書の検証を行な
うことによって、認証局の公開鍵証明書を正当に有して
いるか否かの判定が可能となる。なお、公開鍵証明書が
前述したように階層構成をなしている場合は、経路を上
位に辿って連鎖的な検証を行ない、ルート認証局（Ｃ
Ａ）の発行した公開鍵証明書の検証まで実行することが
好ましい。なお、この連鎖検証が必須の場合もある。

【０１６９】属性証明書（ＡＣ）と公開鍵証明書（ＰＫ
Ｃ）との関連確認処理、および各証明書の検証処理の詳
細について、図を参照して説明する。図２１のフロー
は、属性証明書（ＡＣ）の検証を実行する際に行なわれ
る属性証明書（ＡＣ）に関連する公開鍵証明書（ＰＫ
Ｃ）の確認処理である。

【０１７０】確認対象の属性証明書（ＡＣ）がセット
（Ｓ２１）されると、属性証明書のＡＣ保持者の公開鍵
証明書情報（ｈｏｌｄｅｒ）フィールドを抽出（Ｓ２
２）し、抽出した公開鍵証明書情報（ｈｏｌｄｅｒ）フ
ィールド内に格納された公開鍵証明書の発行者情報（Ｐ
ＫＣｉｓｓｕｅｒ）、公開鍵証明書シリアル番号（Ｐ
ＫＣｓｅｒｉａｌ）を確認（Ｓ２３）し、公開鍵証明
書の発行者情報（ＰＫＣｉｓｓｕｅｒ）、公開鍵証明書
シリアル番号（ＰＫＣｓｅｒｉａｌ）に基づいて公開
鍵証明書（ＰＫＣ）を検索（Ｓ２４）して、属性証明書
（ＡＣ）に関連付けられた公開鍵証明書（ＰＫＣ）を取
得（Ｓ２５）する。

【０１７１】図２１に示すように、属性証明書（ＡＣ）
と公開鍵証明書（ＰＫＣ）とは、属性証明書に格納され
た公開鍵証明書情報（ｈｏｌｄｅｒ）フィールド内の公
開鍵証明書発行者情報（ＰＫＣｉｓｓｕｅｒ）、およ
び公開鍵証明書シリアル番号（ＰＫＣｓｅｒｉａｌ）
により関連付けがなされている。

【０１７２】次に、図２２を参照して公開鍵証明書（Ｐ
ＫＣ）の検証処理について説明する。図２２に示す公開
鍵証明書（ＰＫＣ）の検証は、下位から上位へ証明書連
鎖をたどって最上位の公開鍵証明書までの連鎖情報を取
得して、最上位（ル−トＣＡ）までの公開鍵証明書の署
名検証を行なう連鎖検証処理フローである。まず、検証
対象となる公開鍵証明書（ＰＫＣ）をセット（Ｓ３１）
し、公開鍵証明書（ＰＫＣ）格納情報に基づいて、公開
鍵証明書（ＰＫＣ）署名者を特定（Ｓ３２）する。さら
に、検証対象となる証明書連鎖の最上位の公開鍵証明書
であるかを判定（Ｓ３３）し、最上位でない場合は、最
上位公開鍵証明書を直接あるいはリポジトリなどから取
得（Ｓ３４）する。最上位公開鍵証明書が取得されセッ
ト（Ｓ３５）されると、署名検証に必要な検証鍵（公開
鍵）を取得（Ｓ３６）し、検証対象の署名が自己署名で
あるか否かを判定し（Ｓ３７）、自己署名でない場合
は、下位ＰＫＣをセット（Ｓ３９）して、上位の公開鍵
証明書から取得した検証鍵（公開鍵）に基づいて署名検
証を実行（Ｓ４０）する。なお、ステップＳ３７におけ
る自己署名判定において、自己署名の場合は自己の公開
鍵を検証鍵とした検証を実行（Ｓ３８）し、ステップＳ
４１に進む。

【０１７３】署名検証に成功した場合（Ｓ４１：Ｙｅ
ｓ）は、目的とするＰＫＣの検証が完了したか否かを判
定（Ｓ４２）し、完了している場合は、ＰＫＣ検証を終
了する。完了していない場合は、ステップＳ３６に戻
り、署名検証に必要な検証鍵（公開鍵）の取得、下位の
公開鍵証明書の署名検証を繰り返し実行する。なお、署
名検証に失敗した場合（Ｓ４１：Ｎｏ）は、ステップＳ
４３に進み、エラー処理、例えばその後の手続きを停止
する等の処理を実行する。

【０１７４】次に、図２３を参照して属性証明書（Ａ
Ｃ）の検証処理（例１）について説明する。まず、検証
対象となる属性証明書（ＡＣ）をセット（Ｓ５１）し、
属性証明書（ＡＣ）格納情報に基づいて、属性証明書
（ＡＣ）の所有者および署名者を特定（Ｓ５２）する。
さらに、属性証明書（ＡＣ）の所有者の公開鍵証明書を
直接あるいはリポジトリなどから取得（Ｓ５３）して、
公開鍵証明書の検証処理を実行（Ｓ５４）する。

【０１７５】公開鍵証明書の検証に失敗した場合（Ｓ５
５でＮｏ）は、ステップＳ５６に進み、エラー処理を行
なう。例えばその後の処理を中止する。公開鍵証明書の
検証に成功した場合（Ｓ５５でＹｅｓ）は、属性証明書
（ＡＣ）の署名者に対応する公開鍵証明書を直接あるい
はリポジトリなどから取得（Ｓ５７）して、公開鍵証明
書の検証処理を実行（Ｓ５８）する。公開鍵証明書の検
証に失敗した場合（Ｓ５９でＮｏ）は、ステップＳ６０
に進み、エラー処理を行なう。例えばその後の処理を中
止する。公開鍵証明書の検証に成功した場合（Ｓ５９で
Ｙｅｓ）は、属性証明書（ＡＣ）の署名者に対応する公
開鍵証明書から公開鍵を取り出し（Ｓ６１）て、取り出
した公開鍵を用いて属性証明書（ＡＣ）の署名検証処理
を実行（Ｓ６２）する。署名検証に失敗した場合（Ｓ６
３でＮｏ）は、ステップＳ６４に進み、エラー処理を行
なう。例えばその後の処理を中止する。署名検証に成功
した場合（Ｓ６３でＹｅｓ）は、属性証明書検証を終了
し、その後の処理、例えば属性証明書内の暗号化コンテ
ンツ鍵の取得等に移行する。

【０１７６】次に、図２４を参照して属性証明書（Ａ
Ｃ）の検証処理（例２）について説明する。本例は、自
デバイス内に属性証明書（ＡＣ）の検証処理に必要とな
る公開鍵証明書が格納されているか否かを判定し、公開
鍵証明書が格納されている場合は、その検証を省略する
こととした例である。まず、検証対象となる属性証明書
（ＡＣ）をセット（Ｓ７１）し、属性証明書（ＡＣ）格
納情報に基づいて、属性証明書（ＡＣ）の所有者および
署名者を特定（Ｓ７２）する。さらに、属性証明書（Ａ
Ｃ）の所有者の公開鍵証明書（ＰＫＣ）が自デバイス内
のメモリに格納保存されていないかを検索（Ｓ７３）す
る。保存されている場合（Ｓ７４でＹｅｓ）は、属性証
明書（ＡＣ）の所有者の公開鍵証明書を取り出し（Ｓ７
５）て、ステップＳ８１に進む。

【０１７７】属性証明書（ＡＣ）の所有者の公開鍵証明
書（ＰＫＣ）が自デバイス内のメモリに保存されていな
い場合（Ｓ７４でＮｏ）は、属性証明書（ＡＣ）の所有
者の公開鍵証明書（ＰＫＣ）を直接あるいはリポジトリ
などから取得（Ｓ７６）して、属性証明書（ＡＣ）の所
有者の公開鍵証明書（ＰＫＣ）の検証処理を実行（Ｓ７
７）する。公開鍵証明書の検証に失敗した場合（Ｓ７８
でＮｏ）は、ステップＳ７９に進み、エラー処理を行な
う。例えばその後の処理を中止する。公開鍵証明書の検
証に成功した場合（Ｓ７８でＹｅｓ）は、公開鍵証明書
の検証結果を保存（Ｓ８０）した後、属性証明書（Ａ
Ｃ）の署名者に対応する公開鍵証明書（ＰＫＣ）が自デ
バイス内のメモリに格納保存されていないかを検索（Ｓ
８１）する。保存されている場合（Ｓ８２でＹｅｓ）
は、属性証明書（ＡＣ）の署名者の公開鍵証明書を取り
出し（Ｓ８３）て、ステップＳ８８に進む。

【０１７８】属性証明書（ＡＣ）の署名者の公開鍵証明
書（ＰＫＣ）が自デバイス内のメモリに保存されていな
い場合（Ｓ８２でＮｏ）は、属性証明書（ＡＣ）の署名
者の公開鍵証明書（ＰＫＣ）を直接あるいはリポジトリ
などから取得（Ｓ８４）して、属性証明書（ＡＣ）の署
名者の公開鍵証明書（ＰＫＣ）の検証処理を実行（Ｓ８
５）する。公開鍵証明書の検証に失敗した場合（Ｓ８６
でＮｏ）は、ステップＳ８７に進み、エラー処理を行な
う。例えばその後の処理を中止する。公開鍵証明書の検
証に成功した場合（Ｓ８６でＹｅｓ）は、公開鍵証明書
から属性証明書（ＡＣ）の署名検証に適用する鍵（公開
鍵）を取り出し（Ｓ８８）、属性証明書（ＡＣ）の署名
検証処理を実行（Ｓ８９）する。署名検証に失敗した場
合（Ｓ９０でＮｏ）は、ステップＳ９１に進み、エラー
処理を行なう。例えばその後の処理を中止する。署名検
証に成功した場合（Ｓ９０でＹｅｓ）は、属性証明書検
証を終了し、その後の処理、例えば属性証明書内の暗号
化コンテンツ鍵の取得等に移行する。

【０１７９】ユーザデバイスによる属性証明書の検証が
なされると、属性証明書はユーザデバイス内のセキュリ
ティチップのメモリ、あるいはセキュリティチップ外の
ユーザデバイス制御部の管理下の外部メモリに格納さ
れ、コンテンツの利用時に、属性証明書内の暗号化コン
テンツ鍵の取得、復号化処理を実行することになる。属
性証明書から暗号化されたコンテンツ鍵を取得して復号
する処理について、以下説明する。

【０１８０】（ａ）ＳＰ対応ストレージ秘密鍵に対応す
るサービスプロバイダ（ＳＰ）対応ストレージ公開鍵：
ＳＣ．Ｓｔｏｐｕｂ．ＳＰ．Ｋを適用した場合まず、前述の（ａ）ＳＰ対応ストレージ秘密鍵に対応す
るサービスプロバイダ（ＳＰ）対応ストレージ公開鍵：
ＳＣ．Ｓｔｏｐｕｂ．ＳＰ．Ｋをコンテンツ鍵：Ｋｃの
暗号化に適用し、［ＳＣ．Ｓｔｏｐｕｂ．ＳＰ．Ｋ（Ｋ
ｃ）］を格納した属性証明書に基づくコンテンツ利用処
理について説明する。

【０１８１】ＳＰ対応ストレージ秘密鍵：ＳＣ．Ｓｔｏ
ｐｒｉ．ＳＰ．Ｋは、サービスプロバイダ管理領域に格
納され、ユーザは前述した認証情報（パスワード）入力
により、この鍵を取り出して利用することができる。従
って、コンテンツ鍵：Ｋｃはサービスプロバイダに接続
することなくオフライン処理として取得可能であり、コ
ンテンツの復号が可能となる。

【０１８２】図２５に属性証明書からの暗号化コンテン
ツ鍵取得、復号、コンテンツ鍵によるコンテンツ復号化
処理のシーケンスを説明する図を示す。

【０１８３】図２５のシーケンス図に従って説明する。
図２５は左からセキュリティチップ内部のメモリ、セキ
ュリティチップ制御部、ユーザデバイス制御部の処理を
示している。まず、ユーザデバイスに対してユーザの入
力したコンテンツ識別情報としてのアプリケーションＩ
Ｄをセキュリティチップ制御部に送信し、メモリからア
プリケーションＩＤに対応する属性証明書（ＡＣ）を取
得する。ユーザデバイスでは、アプリケーションＩＤに
対応する属性証明書であるかの検証を行ない、セキュリ
ティチップ制御部に属性証明書をセットし、コンテンツ
鍵：Ｋｃの取得（復号）処理を要求する。

【０１８４】セキュリティチップ制御部は、属性証明書
の署名検証を実行し、データ改竄のないことを確認し、
属性証明書内に格納された暗号化コンテンツ鍵：［Ｓ
Ｃ．Ｓｔｏｐｕｂ．ＳＰ．Ｋ（Ｋｃ）］を取り出して、
サービスプロバイダ管理領域に格納されたＳＰ対応スト
レージ秘密鍵：ＳＣ．Ｓｔｏｐｒｉ．ＳＰ．Ｋを適用し
て復号化処理を実行し、コンテンツ鍵：Ｋｃを取得す
る。コンテンツ鍵：Ｋｃの取得に成功すると、セキュリ
ティチップ制御部は、ユーザデバイス制御部にコンテン
ツの復号準備が完了したことを通知する。

【０１８５】次にユーザデバイス制御部は、取得したコ
ンテンツ鍵を適用して復号すべき暗号化コンテンツを、
セキュリティチップ制御部を介してメモリから取得す
る。暗号化コンテンツがセキュリティチップ内のメモリ
ではなく、外部メモリ（例えばハードディスク）等に格
納されている場合は、外部メモリから暗号化コンテンツ
を取得する。さらに、取得した暗号化コンテンツをセキ
ュリティチップに送信し、セキュリティチップ内で暗号
化コンテンツに対してコンテンツ鍵：Ｋｃを適用した復
号化処理を実行し、復号化処理結果として得られるコン
テンツをユーザデバイス制御部に出力する。

【０１８６】なお、上記構成例では、公開鍵暗号方式を
適用し、コンテンツ鍵の暗号化にＳＰ対応ストレージ公
開鍵：ＳＣ．Ｓｔｏｐｕｂ．ＳＰ．Ｋを用い、暗号化コ
ンテンツ鍵の復号にＳＰ対応ストレージ秘密鍵：ＳＣ．
Ｓｔｏｐｒｉ．ＳＰ．Ｋを用いた構成としたが、共通鍵
方式を適用することも可能であり、共通鍵方式を適用す
る場合は、コンテンツ鍵の暗号化、復号化の双方の処理
にＳＰ対応ストレージ鍵（共通鍵）：ＳＣ．Ｓｔｏ．Ｓ
Ｐ．Ｋを用いる。この場合、ＳＰ対応ストレージ鍵（共
通鍵）：ＳＣ．Ｓｔｏ．ＳＰ．Ｋは、セキュリティチッ
プのメモリの対応するサービスプロバイダのサービスプ
ロバイダ管理領域に格納される。

【０１８７】（ｂ）サービスプロバイダの保有する秘密
鍵（共通鍵系）：ＳＰ．Ｓｔｏ．Ｋを適用した場合次に、前述の（ｂ）サービスプロバイダの保有する秘密
鍵：ＳＰ．Ｓｔｏ．Ｋをコンテンツ鍵：Ｋｃの暗号化に
適用し、［ＳＰ．Ｓｔｏ．Ｋ（Ｋｃ）］を格納した属性
証明書に基づくコンテンツ利用処理について説明する。

【０１８８】サービスプロバイダの保有する秘密鍵：Ｓ
Ｐ．Ｓｔｏ．Ｋは、サービスプロバイダが保有し、ユー
ザデバイスには格納されていない鍵である。従って、ユ
ーザデバイスがコンテンツ鍵：Ｋｃを取得するために
は、サービスプロバイダに接続して、コンテンツ鍵の復
号化処理をサービスプロバイダに対して要求することが
必要となり、オンライン処理によるコンテンツ復号を実
行することとなる。

【０１８９】図２６に属性証明書からのコンテンツ鍵取
得、復号、コンテンツ鍵によるコンテンツ復号化処理の
シーケンスを説明する図を示す。

【０１９０】図２６のシーケンス図に従って説明する。
図２６は左からセキュリティチップ内部のメモリ、セキ
ュリティチップ制御部、ユーザデバイス制御部、サービ
スプロバイダにおける処理を示している。

【０１９１】まず、ユーザデバイスに対してユーザの入
力したコンテンツ識別情報としてのアプリケーションＩ
Ｄをセキュリティチップ制御部に送信し、メモリからア
プリケーションＩＤに対応する属性証明書（ＡＣ）を取
得する。ユーザデバイスでは、アプリケーションＩＤに
対応する属性証明書であるかの検証を行ない、セキュリ
ティチップ制御部に属性証明書をセットし、コンテンツ
鍵：Ｋｃの取得（復号）処理を要求する。

【０１９２】セキュリティチップ制御部は、属性証明書
の検証の後、属性証明書の発行元であるサービスプロバ
イダに対してユーザデバイスを介して接続し、セキュリ
ティチップとサービスプロバイダ間の相互認証処理を実
行する。この相互認証処理は、先に説明した図１６のＴ
ＬＳ１．０処理または、その他の方式、例えば公開鍵方
式による相互認証処理として実行される。この相互認証
処理においては、相互の公開鍵証明書の検証がなされ、
必要に応じてルート認証局（ＣＡ）までの公開鍵証明書
が連鎖的に検証される。この認証処理において、セキュ
リティチップと、サービスプロバイダはセッション鍵
（Ｋｓｅｓ）を共有する。

【０１９３】相互認証が成立すると、セキュリティチッ
プの制御部は、サービスプロバイダに対して属性証明書
を送付する。属性証明書には、サービスプロバイダの保
有する秘密鍵：ＳＰ．Ｓｔｏ．Ｋで暗号化されたコンテ
ンツ鍵のデータ、すなわち、［ＳＰ．Ｓｔｏ．Ｋ（Ｋ
ｃ）］が格納されている。

【０１９４】セキュリティチップから属性証明書を受信
したサービスプロバイダは、属性証明書の署名検証処理
を実行する。また、この際、属性証明書にリンクする公
開鍵証明書、およびその上位公開鍵証明書を連鎖的に検
証することが好ましい。なお、この連鎖検証が必須の場
合もある。これらの検証処理により、属性証明書の正当
性が確認されると、サービスプロバイダは、自己の所有
する秘密鍵：ＳＰ．Ｓｔｏ．Ｋを用いて、属性証明書に
格納された暗号化コンテンツ鍵：［ＳＰ．Ｓｔｏ．Ｋ
（Ｋｃ）］の復号化処理を実行し、コンテンツ鍵：Ｋｃ
を取り出す。さらに、取り出したコンテンツ鍵：Ｋｃを
先の相互認証処理において生成したセッションキー（Ｋ
ｓｅｓ）で暗号化して、ユーザデバイスのセキュリティ
チップに対して送信する。

【０１９５】セキュリティチップの制御部は、サービス
プロバイダからセッションキーで暗号化されたコンテン
ツ鍵、すなわち、［Ｋｓｅｓ（Ｋｃ）］を受信すると、
相互認証時に保有したセッションキーを用いて復号化処
理を実行してコンテンツ鍵：Ｋｃを取得する。

【０１９６】コンテンツ鍵：Ｋｃの取得に成功すると、
セキュリティチップ制御部は、ユーザデバイス制御部に
コンテンツの復号準備が完了したことを通知する。次に
ユーザデバイス制御部は、取得したコンテンツ鍵を適用
して復号すべき暗号化コンテンツをセキュリティチップ
制御部を介してメモリから取得する。暗号化コンテンツ
がセキュリティチップ内のメモリではなく、外部メモリ
（例えばハードディスク）等に格納されている場合は、
外部メモリから暗号化コンテンツを取得する。さらに、
取得した暗号化コンテンツをセキュリティチップに送信
し、セキュリティチップ内で暗号化コンテンツに対して
コンテンツ鍵：Ｋｃを適用した復号化処理を実行し、復
号化処理結果として得られるコンテンツをユーザデバイ
ス制御部に出力する。

【０１９７】（ｃ）システムホルダ（ＳＨ）とユーザデ
バイスで共有する鍵として生成されるグローバル共通
鍵：Ｋｇを適用した場合次に、システムホルダ（ＳＨ）とユーザデバイスで共有
する鍵として生成されるグローバル共通鍵：Ｋｇを、コ
ンテンツ鍵：Ｋｃの暗号化に間接的に適用して属性証明
書に格納する処理形態について説明する。このグローバ
ル共通鍵を利用する形態は、ユーザデバイスにおいての
みコンテンツ鍵：Ｋｃを取り出すことを可能とし、コン
テンツの配信を実行するサービスプロバイダはコンテン
ツ鍵の取り出しを不可能とすることで、システムホルダ
の許可なくコンテンツが配布、利用されることを防止
し、システムホルダ（ＳＨ）による管理されたコンテン
ツ配信を行なうことが可能となる。

【０１９８】具体的には、サービスプロバイダに対して
コンテンツを提供するコンテンツクリエータの有するコ
ンテンツ製作者鍵、コンテンツ配信を行なうサービスプ
ロバイダの有するコンテンツ配信者鍵、そしてシステム
ホルダ（ＳＨ）とユーザデバイスで共有する鍵として生
成されるグローバル共通鍵：Ｋｇの各鍵を組み合わせた
暗号化処理を行なった暗号化鍵データを属性証明書に格
納する。

【０１９９】図２７に、グローバル共通鍵：Ｋｇをコン
テンツ鍵：Ｋｃの暗号化に間接的に適用してコンテンツ
鍵：Ｋｃの暗号化データを属性証明書に格納して配布す
る処理の詳細を説明する図を示す。

【０２００】図２７には、コンテンツ配信のプラットホ
ームを構築、管理するシステムホルダ３０１、コンテン
ツ配信を実行するサービスプロバイダ（ＣＤ：コンテン
ツディストリビュータ）３０２、コンテンツを生成また
は管理し、サービスプロバイダ３０２に対して暗号化コ
ンテンツを提供するコンテンツクリエータ３０３、サー
ビスプロバイダ３０２からコンテンツを受領するエンド
エンティテイとしてのユーザデバイス３０４を示してい
る。なお、ユーザデバイス３０４は、前述の（ａ），
（ｂ）の例と同様、セキュリティチップを有し、セキュ
リティチップ内のメモリ領域にはサービスプロバイダ管
理領域が生成されている。

【０２０１】図２７の処理について説明する。まず、コ
ンテンツクリエータ３０３は、配信対象となるコンテン
ツを暗号化するための鍵：Ｋｃを例えば乱数により生成
し、生成したコンテンツ鍵（共通鍵系）：Ｋｃを用い
て、（１）コンテンツを暗号化してサービスプロバイダ
３０２に提供する。

【０２０２】さらに、システムホルダ３０１は、（２）
コンテンツクリエータ３０３から、コンテンツクリエー
タ３０３の保有するコンテンツクリエータ鍵（共通鍵
系）：Ｋｃｃを受信し、（３）サービスプロバイダ（Ｃ
Ｄ：コンテンツディストリビュータ）３０２からサービ
スプロバイダ３０２の保有するサービスプロバイダ鍵
（共通鍵系）：Ｋｃｄを受信する。なお、これらの鍵は
事前に受け渡しを行なってもよい。

【０２０３】システムホルダ３０１は、コンテンツクリ
エータ鍵：Ｋｃｃをサービスプロバイダ鍵：Ｋｃｄで暗
号化し、さらに、この暗号化データをグローバル共通
鍵：Ｋｇで暗号化する。すなわち暗号化鍵データ：［Ｋ
ｇ（［Ｋｃｄ（Ｋｃｃ）］）］を生成し、（４）これを
コンテンツクリエータ３０３に送付する。なお、［Ｋｇ
（［Ｋｃｄ（Ｋｃｃ）］）］は事前に受け渡しを行なっ
てもよい。グローバル共通鍵：Ｋｇは、システムホルダ
３０１と、ユーザデバイス３０４が共有する鍵である。
ユーザデバイス３０４には、（５）デバイス製造時、デ
バイス販売時まで、あるいは少なくともコンテンツの購
入開始前までに、１以上のグローバル共通鍵：Ｋｇ１〜
Ｋｇｎが格納され、これらはシステムホルダの管理の下
に更新処理が実行される。更新処理については、後述す
る。

【０２０４】コンテンツクリエータ３０３は、コンテン
ツ鍵：Ｋｃをコンテンツクリエータ鍵：Ｋｃｃで暗号化
したデータ：［Ｋｃｃ（Ｋｃ）］を生成し、（６）これ
をサービスプロバイダ３０２に対して送信するととも
に、システムホルダ３０１から受信した、コンテンツク
リエータ鍵：Ｋｃｃをサービスプロバイダ鍵：Ｋｃｄで
暗号化し、さらに、この暗号化データをグローバル共通
鍵：Ｋｇで暗号化した暗号化鍵データ：［Ｋｇ（［Ｋｃ
ｄ（Ｋｃｃ）］）］をサービスプロバイダ３０２に対し
て送信する。なお、［Ｋｇ（［Ｋｃｄ（Ｋｃｃ）］）］
は事前に受け渡しを行なってもよい。

【０２０５】ユーザデバイス３０４がサービスプロバイ
ダ３０２に対して（７）コンテンツ購入要求を行なう
と、（８）サービスプロバイダは、要求コンテンツに対
応する属性証明書を生成して、ユーザデバイス３０４に
送信する。生成する属性証明書（ＡＣ）には、前述の暗
号鍵データ：［Ｋｇ（［Ｋｃｄ（Ｋｃｃ）］）］、すな
わち、コンテンツクリエータ鍵：Ｋｃｃをサービスプロ
バイダ鍵：Ｋｃｄで暗号化し、さらに、この暗号化デー
タをグローバル共通鍵：Ｋｇで暗号化したデータ、およ
び、コンテンツ鍵：Ｋｃをコンテンツクリエータ鍵：Ｋ
ｃｃで暗号化したデータ：［Ｋｃｃ（Ｋｃ）］が格納さ
れる。その他、コンテンツの利用条件等のデータが格納
され、サービスプロバイダ３０２の電子署名がなされて
ユーザデバイス３０４に送信される。ユーザデバイス３
０４は、受信した属性証明書（ＡＣ）をメモリに格納す
る。

【０２０６】コンテンツの利用時には、ユーザデバイス
３０４は、サービスプロバイダ３０２との間で（９）相
互認証を行なった後、（１０）先に受信済みの属性証明
書（ＡＣ）をサービスプロバイダ３０２に送信する。相
互認証処理は、ユーザデバイスのセキュリティチップと
サービスプロバイダ間の相互認証処理として実行され
る。この相互認証処理は、先に説明した図１６のＴＬＳ
１．０処理または、その他の方式、例えば公開鍵方式に
よる相互認証処理として実行される。この相互認証処理
においては、相互の公開鍵証明書の検証がなされ、必要
に応じてルート認証局（ＣＡ）までの公開鍵証明書が連
鎖的に検証される。この認証処理において、セキュリテ
ィチップと、サービスプロバイダはセッション鍵（Ｋｓ
ｅｓ）を共有する。

【０２０７】属性証明書には、前述のコンテンツクリエ
ータ鍵：Ｋｃｃをサービスプロバイダ鍵：Ｋｃｄで暗号
化し、さらに、この暗号化データをグローバル共通鍵：
Ｋｇで暗号化したデータ：［Ｋｇ（［Ｋｃｄ（Ｋｃ
ｃ）］）］、および、コンテンツ鍵：Ｋｃをコンテンツ
クリエータ鍵：Ｋｃｃで暗号化したデータ：［Ｋｃｃ
（Ｋｃ）］が格納されている。

【０２０８】セキュリティチップから属性証明書を受信
したサービスプロバイダは、属性証明書の署名検証処理
を実行する。また、この際、属性証明書にリンクする公
開鍵証明書、およびその上位公開鍵証明書を連鎖的に検
証することが好ましい。なお、この連鎖検証が必須の場
合もある。これらの検証処理により、属性証明書の正当
性が確認されると、（１１）サービスプロバイダは、自
己の所有するサービスプロバイダ鍵：Ｋｃｄを、相互認
証時に生成したセッション鍵：Ｋｓｅｓで暗号化して、
暗号化鍵データ［Ｋｓｅｓ（Ｋｃｄ）］を生成し、これ
をユーザデバイスに送信する。

【０２０９】ユーザデバイス３０４のセキュリティチッ
プ制御部は、（１２）サービスプロバイダ３０２から受
信した暗号化鍵データ［Ｋｓｅｓ（Ｋｃｄ）］につい
て、セッションキーを用いた復号化処理を実行してサー
ビスプロバイダ鍵：Ｋｃｄを取得する。なお、サービス
プロバイダ鍵：Ｋｃｄを事前にサービスプロバイダメモ
リ領域に保管しておいてもよい。

【０２１０】ユーザデバイス３０４のセキュリティチッ
プ制御部は、次に、（１３）属性証明書中のコンテンツ
クリエータ鍵：Ｋｃｃをサービスプロバイダ鍵：Ｋｃｄ
で暗号化し、さらに、この暗号化データをグローバル共
通鍵：Ｋｇで暗号化したデータ：［Ｋｇ（［Ｋｃｄ（Ｋ
ｃｃ）］）］について、まず、自己の所有するグローバ
ル共通鍵：Ｋｇで復号し、［Ｋｃｄ（Ｋｃｃ）］を取得
する。さらに、（１４）サービスプロバイダ３０２から
受信した暗号化鍵データの復号により取得したサービス
プロバイダ鍵：Ｋｃｄを適用した復号化処理により、コ
ンテンツクリエータ鍵：Ｋｃｃを取得する。

【０２１１】さらに、（１５）ユーザデバイス３０４の
セキュリティチップ制御部は、属性証明書中のコンテン
ツ鍵：Ｋｃをコンテンツクリエータ鍵：Ｋｃｃで暗号化
したデータ：［Ｋｃｃ（Ｋｃ）］を取り出して、前記処
理によって取得したコンテンツクリエータ鍵：Ｋｃｃを
適用した復号化処理を実行してコンテンツ鍵：Ｋｃを取
得する。

【０２１２】コンテンツ鍵：Ｋｃの取得に成功すると、
ユーザデバイス３０４のセキュリティチップ制御部は、
ユーザデバイス制御部にコンテンツの復号準備が完了し
たことを通知する。

【０２１３】ユーザデバイス３０４は、サービスプロバ
イダ３０２から取得した暗号化コンテンツ（（１６）の
処理）をセキュリティチップに送信し、セキュリティチ
ップ内で暗号化コンテンツに対してコンテンツ鍵：Ｋｃ
を適用した復号化処理を実行する。

【０２１４】なお、上述の各エンティテイ間における
鍵、暗号化鍵等のデータ送受信の前には、データ送受信
を実行するエンティテイ間で相互認証を実行し、認証成
立を条件としたデータ送受信を行なうことが好ましく、
また送受信データはセッションキーで暗号化し、署名を
付与した構成とすることが好ましい。

【０２１５】このように、グローバル共通鍵は、ユーザ
デバイスとシステムホルダのみが所有し、その他のエン
ティテイは保有することがなく、他のエンティテイでは
取得不可能な鍵として構成される。従って、サービスプ
ロバイダにおいてもコンテンツ鍵の取得は不可能であ
り、システムホルダの許可のないコンテンツ鍵の流通、
コンテンツの流通が防止可能となる。

【０２１６】グローバル共通鍵は、必要に応じて更新さ
れる。更新を実行するのは、システムホルダの管理下に
あるサポートセンタである。サポートセンタとユーザデ
バイス間で実行されるグローバル共通鍵更新処理シーケ
ンスを図２８に示す。ユーザデバイスのセキュリティチ
ップ内のメモリ領域には、２つのグローバル共通鍵Ｋｇ
１，Ｋｇ２が格納されているものとする。これらのいず
れかを使用して属性証明書内の鍵データの暗号化がなさ
れ、復号化処理が実行される。あるいは例えばトリプル
ＤＥＳアルゴリズムを適用して２つの鍵を用いて属性証
明書内の鍵データの暗号化を行ない、２つの鍵を用いた
復号化処理を実行する構成としてもよい。

【０２１７】図２８の処理シーケンスに示す各処理につ
いて説明する。図２８は左からセキュリティチップ制御
部、ユーザデバイス制御部、システムホルダの管理下に
あるサポートセンタにおける処理を示している。

【０２１８】まず、ユーザデバイス制御部がグローバル
共通鍵：Ｋｇ更新要求をセキュリティチップ制御部に送
信すると、セキュリティチップ制御部は、システムホル
ダの管理下にあるサポートセンタに対してユーザデバイ
スを介して接続し、セキュリティチップとサポートセン
タ間の相互認証処理を実行する。この相互認証処理は、
先に説明した図１６のＴＬＳ１．０処理または、その他
の方式、例えば公開鍵方式による相互認証処理として実
行される。この相互認証処理においては、相互の公開鍵
証明書の検証がなされ、必要に応じてルート認証局（Ｃ
Ａ）までの公開鍵証明書が連鎖的に検証される。この認
証処理において、セキュリティチップと、サポートセン
タはセッション鍵（Ｋｓｅｓ）を共有する。

【０２１９】相互認証が成立すると、セキュリティチッ
プの制御部は、サポートセンタに対してグローバル共通
鍵：Ｋｇ更新要求を出力する。サポートセンタは、すで
に生成済みの更新用グローバル共通鍵：Ｋｇ３、あるい
は要求に応じて生成したグローバル共通鍵：Ｋｇ３を認
証処理において生成したセッション鍵：Ｋｓｅｓで暗号
化し、暗号化鍵データ：［Ｋｓｅｓ（Ｋｇ３）］をユー
ザデバイスのセキュリティチップに対して送信する。

【０２２０】セキュリティチップの制御部は、サポート
センタからセッションキーで暗号化されたグローバル共
通鍵：Ｋｇ３、すなわち、［Ｋｓｅｓ（Ｋｇ３）］を受
信すると、相互認証時に保有したセッションキーを用い
て復号化処理を実行してグローバル共通鍵：Ｋｇ３を取
得する。

【０２２１】グローバル共通鍵：Ｋｇ３の取得に成功す
ると、セキュリティチップ制御部は、グローバル共通
鍵：Ｋｇ１を、取得したグローバル共通鍵：Ｋｇ３に置
き換える。これにより、ユーザデバイスの保有するグロ
ーバル共通鍵は、Ｋｇ２、Ｋｇ３となる。ユーザデバイ
スの保有するグローバル共通鍵は、その順序関係も含め
て意味があるため、［Ｋｇ１，Ｋｇ２］の順序関係も併
せて［Ｋｇ２，Ｋｇ３］と修正する。グローバル共通鍵
は、鍵データと共にユーザデバイス内で保持されている
順序関係も合わせてデータを保持しているものとする。

【０２２２】図２９は、ユーザデバイスとサポートセン
タが直接データ送受信を行なうことなく、サービスプロ
バイダが仲介を行なってグローバル共通鍵の更新を実行
する処理シーケンス例を示した図である。

【０２２３】図２９の処理シーケンスに示す各処理につ
いて説明する。図２９は左からセキュリティチップ制御
部、ユーザデバイス制御部、サービスプロバイダ、シス
テムホルダの管理下にあるサポートセンタにおける処理
を示している。

【０２２４】サポートセンタでは、更新される新たなグ
ローバル共通鍵：Ｋｇ３を事前生成し、グローバル共通
鍵：Ｋｇ３をすでにユーザデバイスに配布済みのグロー
バル共通鍵：Ｋｇ２で暗号化してデータ：［Ｋｇ２（Ｋ
ｇ３）］を生成し、これに、サポートセンタの秘密鍵：
Ｋｓｓで署名を付してサービスプロバイダに送付する。
サービスプロバイダは、データ［Ｋｇ２（Ｋｇ３）］，
Ｓｉｇ［Ｋｓｓ］を有する。なお、Ａ，Ｓｉｇ［Ｂ］
は、データＡに鍵Ｂで署名を付加したデータ構成を示す
ものとする。

【０２２５】次に、ユーザデバイス制御部がグローバル
共通鍵：Ｋｇ更新要求をセキュリティチップ制御部に送
信すると、セキュリティチップ制御部は、サービスプロ
バイダに対してユーザデバイスを介して接続し、セキュ
リティチップとサービスプロバイダ間の相互認証処理を
実行する。この相互認証処理は、先に説明した図１６の
ＴＬＳ１．０処理または、その他の方式、例えば公開鍵
方式による相互認証処理として実行される。この相互認
証処理においては、相互の公開鍵証明書の検証がなさ
れ、必要に応じてルート認証局（ＣＡ）までの公開鍵証
明書が連鎖的に検証される。この認証処理において、セ
キュリティチップと、サービスプロバイダはセッション
鍵（Ｋｓｅｓ）を共有する。

【０２２６】相互認証が成立すると、セキュリティチッ
プの制御部は、サービスプロバイダに対してグローバル
共通鍵：Ｋｇ更新要求を出力する。サービスプロバイダ
はサポートセンタから受信済みのデータ［Ｋｇ２（Ｋｇ
３）］，Ｓｉｇ［ＳｕＣ］をユーザデバイスのセキュリ
ティチップに対して送信する。

【０２２７】セキュリティチップの制御部は、サービス
プロバイダから、サポートセンタからのデータ［Ｋｇ２
（Ｋｇ３）］，Ｓｉｇ［ＳｕＣ］の転送を受けると、署
名検証処理を実行し、データ改竄のないことを確認した
後、自己の所有するグローバル共通鍵：Ｋｇ２で暗号化
されたグローバル共通鍵：Ｋｇ３、すなわち、［Ｋｇ２
（Ｋｇ３）］に対して、グローバル共通鍵：Ｋｇ２を用
いた復号化処理を実行してグローバル共通鍵：Ｋｇ３を
取得する。なお、サポートセンタの署名検証にサポート
センタの公開鍵を適用する場合は、サポートセンタの公
開鍵証明書をユーザデバイスに対してデータ［Ｋｇ２
（Ｋｇ３）］，Ｓｉｇ［ＳｕＣ］とともに送信するか、
あるいはユーザデバイスに予め配布しておく。

【０２２８】グローバル共通鍵：Ｋｇ３の取得に成功す
ると、セキュリティチップ制御部は、メモリの鍵格納領
域、例えば前述のデバイス管理領域内のグローバル共通
鍵：Ｋｇ１書き込み領域にグローバル共通鍵：Ｋｇ３を
上書きする。この更新処理により、ユーザデバイスの保
有するグローバル共通鍵は、Ｋｇ２、Ｋｇ３の２つに更
新される。

【０２２９】［デコーダを利用した復号化処理］暗号化
コンテンツ、あるいは暗号化コンテンツ鍵は、専用の復
号化処理機能を持つデコーダに処理を実行させる構成と
すると処理の高速化が可能となる。ただし、デコーダは
セキュリティチップと独立したハード構成を持つため、
デコーダの信頼性を確認した上でデコーダ内でのコンテ
ンツ鍵、コンテンツの復号化を行なうことが必要とな
る。以下、デコーダを用いた暗号化コンテンツ、あるい
は暗号化コンテンツ鍵の復号化処理について図を参照し
て説明する。

【０２３０】図３０にユーザデバイスにセキュリティチ
ップと、デコーダを有する場合のコンテンツ鍵、コンテ
ンツの復号化処理シーケンスを説明する図を示す。

【０２３１】ユーザデバイスは、セキュリティチップ２
１０と、デコーダ２８０、ハードディスク、フラッシュ
メモリ等からなるメモリ部２２２と、上位ソフトウェア
によりセキュリティチップ２１０と、デコーダ２８０、
メモリ部２２２に対してデータ入出力、各種処理実行命
令を行なうユーザデバイス側制御部２２１がある。

【０２３２】コンテンツ復号化処理時のシーケンスにつ
いて説明する。まず、ユーザによる入力手段の操作によ
り、コンテンツを指定したコンテンツ利用要求がユーザ
デバイス側制御部２２１に入力されると、ユーザデバイ
ス側制御部２２１は、メモリ部２２２に格納された指定
コンテンツに対応する属性証明書（ＡＣ）を検索する。
検索により抽出された属性証明書（ＡＣ）はセキュリテ
ィチップ２１０に転送され、セキュリティチップ２１０
内で、属性証明書（ＡＣ）の検証処理が実行される。

【０２３３】属性証明書（ＡＣ）検証処理に成功する
と、セキュリティチップ２１０とデコーダ２８０間にお
いて相互認証およびセッション鍵の共有処理が実行され
る。相互認証が成立した後、セキュリティチップ２１０
は、属性証明書（ＡＣ）から取り出した暗号化コンテン
ツ鍵を復号化した後、相互認証時にデコーダ２８０と共
有したセッション鍵を用いてコンテンツ鍵を再暗号化し
てデコーダ２８０に送信する。暗号化コンテンツ鍵を受
信したデコーダ２８０は、セッション鍵を適用して暗号
化コンテンツ鍵の復号化を実行してコンテンツ鍵を取得
する。

【０２３４】次に、ユーザデバイス側制御部２２１は、
メモリ部２２２に格納された暗号化コンテンツを検索し
て取り出し、デコーダ２８０に送信する。デコーダ２８
０は、入力された暗号化コンテンツを先に取得したコン
テンツ鍵を適用して復号化処理を実行する。

【０２３５】上述したデコーダを適用した処理では、コ
ンテンツ鍵はセキュリティチップ２１０内では使用され
ない。また、デコーダは、暗号化コンテンツを復号化し
て、アナログ出力として音声または映像データを外部出
力する。なお、属性証明書（ＡＣ）には、認証するデコ
ーダのＩＤや認証方式を記述してもよく、この場合、セ
キュリティチップ２１０は、相互認証時にデコーダが属
性証明書（ＡＣ）に記述されたデコーダＩＤや認証方式
に適合するか否かを判定して、適合する場合にのみコン
テンツ鍵をデコーダに出力する。

【０２３６】デコーダを用いた処理シーケンスについて
図３１を用いて説明する。図３１において、左からセキ
ュリティチップ、上位ソフトウェア（ユーザデバイス側
制御部）、デコーダの各処理を示している。

【０２３７】利用者による入力手段の操作により、コン
テンツを指定したコンテンツ利用要求が上位ソフトウェ
ア（ユーザデバイス側制御部）に入力されると、上位ソ
フトウェア（ユーザデバイス側制御部）は指定コンテン
ツに対応するアプリケーションＩＤを取得し、アプリケ
ーションＩＤに基づいて、ハードディスク等のメモリに
格納されたアプリケーションＩＤに対応する属性証明書
（ＡＣ）を検索する。

【０２３８】検索により抽出された属性証明書（ＡＣ）
は、属性証明書（ＡＣ）検証処理命令とともにセキュリ
ティチップに転送され、セキュリティチップは、属性証
明書（ＡＣ）の検証処理を実行し、属性証明書（ＡＣ）
検証処理に成功すると、セキュリティチップは、属性証
明書（ＡＣ）から暗号化コンテンツ鍵を取り出して、復
号化処理を実行するとともに、上位ソフトウェア（ユー
ザデバイス側制御部）に応答メッセージを出力する。

【０２３９】次に、セキュリティチップとデコーダ間に
おいて、上位ソフトウェア（ユーザデバイス側制御部）
を介して相互認証およびセッション鍵の共有処理が実行
される。相互認証が成立した後、セキュリティチップ
は、属性証明書（ＡＣ）から取り出した暗号化コンテン
ツ鍵を復号化した後、相互認証時にデコーダと共有した
セッション鍵を用いてコンテンツ鍵を再暗号化してデコ
ーダに送信する。暗号化コンテンツ鍵を受信したデコー
ダは、セッション鍵を適用して暗号化コンテンツ鍵の復
号化を実行してコンテンツ鍵を取得する。

【０２４０】次に、ユーザデバイス側制御部は、メモリ
に格納された暗号化コンテンツを検索して取り出し、デ
コーダに送信する。デコーダは、入力された暗号化コン
テンツを先に取得したコンテンツ鍵を適用して復号化処
理を実行する。

【０２４１】次に、デコーダを用いたコンテンツ復号化
処理について、図３２のフローを参照して説明する。

【０２４２】ステップＳ１０１において、利用者による
入力手段の操作により、コンテンツを指定したコンテン
ツ利用要求が上位ソフトウェア（ユーザデバイス側制御
部）に入力されると、ステップＳ１０２において、上位
ソフトウェア（ユーザデバイス側制御部）は指定コンテ
ンツに対応するアプリケーションＩＤを取得し、ステッ
プＳ１０３において、アプリケーションＩＤに基づい
て、ハードディスク等のメモリに格納されたアプリケー
ションＩＤに対応する属性証明書（ＡＣ）を検索する。
検索により抽出された属性証明書（ＡＣ）は、ステップ
Ｓ１０４において、属性証明書（ＡＣ）検証処理命令と
ともにセキュリティチップに転送され、セキュリティチ
ップは、ステップＳ１０５において、属性証明書（Ａ
Ｃ）の検証処理を実行し、属性証明書（ＡＣ）検証処理
に成功すると、セキュリティチップは、属性証明書（Ａ
Ｃ）から暗号化コンテンツ鍵を取り出して、復号化処理
を実行する。また、ステップＳ１０６において、上位ソ
フトウェア（ユーザデバイス側制御部）に応答メッセー
ジを出力する。

【０２４３】属性証明書（ＡＣ）検証処理に成功しなか
った場合は、その後の処理は中止される。検証成功の場
合は、セキュリティチップとデコーダ間において、上位
ソフトウェア（ユーザデバイス側制御部）を介して相互
認証およびセッション鍵の共有処理が実行される。具体
的には、ステップＳ１０８において、上位ソフトウェア
（ユーザデバイス側制御部）からセキュリティチップに
第１認証コマンドが発行され、ステップＳ１０９におい
てセキュリティチップからの応答を上位ソフトウェア
（ユーザデバイス側制御部）が受信し、さらに、ステッ
プＳ１１０において、上位ソフトウェア（ユーザデバイ
ス側制御部）からデコーダに第２認証コマンドが発行さ
れ、ステップＳ１１１においてデコーダからの応答を上
位ソフトウェア（ユーザデバイス側制御部）が受信し、
さらに、ステップＳ１１２において、上位ソフトウェア
（ユーザデバイス側制御部）からセキュリティチップに
第３認証コマンドが発行され、ステップＳ１１３におい
てセキュリティチップからの応答を上位ソフトウェア
（ユーザデバイス側制御部）が受信する処理によって、
セキュリティチップによるデコーダの認証処理が実行さ
れる。認証処理が失敗した場合（Ｓ１１４でＮＧ）は、
その後の処理は中止され、成功した場合は、ステップＳ
１１５に進む。

【０２４４】ステップＳ１１５において、上位ソフトウ
ェア（ユーザデバイス側制御部）からデコーダに第４認
証コマンドが発行され、ステップＳ１１６においてデコ
ーダからの応答を上位ソフトウェア（ユーザデバイス側
制御部）が受信する。この処理によって、デコーダによ
るセキュリティチップの認証の成否が判定される。認証
処理が失敗の場合（Ｓ１１７でＮＧ）は、その後の処理
は中止され、成功した場合は、ステップＳ１１８に進
む。

【０２４５】ステップＳ１１８において、セキュリティ
チップは、属性証明書（ＡＣ）から取り出した暗号化コ
ンテンツ鍵を復号化した後、相互認証時にデコーダと共
有したセッション鍵を用いてコンテンツ鍵を再暗号化
（Ｓ１１８）して、上位ソフトウェア（ユーザデバイス
側制御部）に送信（Ｓ１１９）する。上位ソフトウェア
（ユーザデバイス側制御部）は、受信した暗号化コンテ
ンツ鍵をデコーダに送信（Ｓ１２０）する。

【０２４６】暗号化コンテンツ鍵を受信したデコーダ
は、セッション鍵を適用して暗号化コンテンツ鍵の復号
化を実行してコンテンツ鍵を取得（Ｓ１２１）する。上
位ソフトウェア（ユーザデバイス側制御部）は、メモリ
に格納された暗号化コンテンツを検索（Ｓ１２２）して
取り出し、デコーダに送信（Ｓ１２３）する。デコーダ
は、入力された暗号化コンテンツを先に取得したコンテ
ンツ鍵を適用して復号化処理を実行（Ｓ１２４）する。

【０２４７】このように、デコーダを用いた復号化処理
においては、セキュリティチップとデコーダ間の相互認
証が実行されて、相互認証の成立を条件として、セッシ
ョン鍵で暗号化したコンテンツ鍵がデコーダに出力する
構成としたので、信頼される機器においてのみ復号が実
行され、正当なコンテンツ利用を確保することができ
る。

【０２４８】［コンテンツの利用制限］先に説明したよ
うに、コンテンツの利用制限情報を格納したコンテンツ
対応の属性証明書中の属性情報フィールドに格納される
コンテンツ利用条件関連情報には、サービスプロバイダ
の提供するコンテンツの利用制限回数、利用期限等の様
々な利用条件が含まれる。すなわち、以下の情報であ
る。条件：オンライン利用コンテンツか、オフライン利用コ
ンテンツか、さらに、買い切りコンテンツ、期間制限コ
ンテンツ、オンライン回数制限コンテンツ、オフライン
回数制限コンテンツのいずれであるかを示す情報有効期限：期間制限の場合の有効期限情報利用制限回数：回数制限の場合の利用可能回数

【０２４９】コンテンツを買い切りし、買い切り以後の
コンテンツ利用をフリーとするコンテンツに対応する属
性証明書は、上記条件が買い切りとして設定される。利
用期間を設定したコンテンツに対応する属性証明書は、
上記条件が期間制限として設定され、有効期限が設定さ
れる。利用回数制限を設定したコンテンツに対応する属
性証明書は、上記条件が回数制限として設定され、利用
制限回数に設定値（回数値）が設定される。なお、回数
制限処理の場合には、ユーザデバイス内で利用可能回数
を管理してコンテンツ利用を実行するオフライン回数制
限と、サービスプロバイダにおいて回数検証をした後、
属性証明書に記録された設定回数以内のコンテンツ利用
を許可するオンライン回数制限がある。また期間制限と
回数制限の両制限を伴うコンビネーション制限態様もあ
る。ユーザデバイスでは、属性証明書に記録されたこれ
らの態様に従ってコンテンツが利用される。これらの具
体的な処理態様について、以下、説明する。

【０２５０】ユーザデバイスにおいてコンテンツを利用
するためには、利用対象となるコンテンツに対応する属
性証明書中から暗号化コンテンツ鍵を取り出して復号化
処理を実行してコンテンツ鍵：Ｋｃを取得することが必
要となる。このコンテンツ鍵の取得処理には、デバイス
のセキュリティチップ内で実行するオフライン処理、サ
ービスプロバイダに属性証明書を送付して復号を依頼す
るオンライン処理があることは先に述べた通りである。
属性証明書に記載されたコンテンツの利用条件に従った
コンテンツ利用処理においても、利用条件をユーザデバ
イス内で確認するオフライン処理、サービスプロバイダ
での確認を必要とするオンライン処理がある。これらの
どちらを適用するかは、属性証明書の属性情報フィール
ドの記載に従って決定する。

【０２５１】図３３にコンテンツ利用時におけるユーザ
デバイスで実行される属性証明書（ＡＣ）の利用処理フ
ローを示す。処理フローの各ステップについて説明す
る。

【０２５２】ユーザデバイスは、利用対象コンテンツに
対応する属性証明書をアプリケーションＩＤ（コンテン
ツ識別情報）に基づいて選択すると、まず、属性証明書
のフォーマット確認処理を実行（Ｓ２０１）する。属性
証明書に必要事項が記録され、証明書の有効期限が有効
であるか等である。フォーマット確認処理が済むと、ス
テップＳ２０２において署名検証が実行される。先にも
説明したように属性証明書には、属性証明書発行者（例
えばサービスプロバイダ）の電子署名が付加されてお
り、ユーザデバイスは、属性証明書発行者の公開鍵証明
書から公開鍵を取り出して署名検証処理（図２０参照）
を行なう。なお、この際使用する公開鍵証明書の検証、
連鎖的公開鍵証明書の検証処理も必要に応じて実行する
ことが好ましい。なお、この連鎖検証が必須の場合もあ
る。

【０２５３】ステップＳ２０２の署名検証処理過程にお
いて、検証が成立し、属性証明書に改竄がないと判定さ
れた場合はステップＳ２０３に進む。一方、ステップＳ
２０２の署名検証処理過程において、検証が非成立とな
り、属性証明書に改竄ありと判定された場合は、ステッ
プＳ２０５に進み、その属性証明書を適用した処理は実
行されず、以降の処理、すなわちコンテンツ利用処理が
中止される。

【０２５４】属性証明書に改竄がないと判定され、ステ
ップＳ２０３に進むと、属性証明書内の属性情報フィー
ルド内のコンテンツ利用条件情報を取得する。すなわ
ち、オンライン利用コンテンツか、オフライン利用コン
テンツか、さらに、買い切りコンテンツ、期間制限コン
テンツ、オンライン回数制限コンテンツ、オフライン回
数制限コンテンツのいずれであるかである。この条件に
従って、ステップＳ２０４のオンライン処理であるか、
オフラインである場合は、ステップＳ２０６において買
い切りか、回数制限であるかが判定される。

【０２５５】ステップＳ２０４において、オンライン利
用であると判定されると、先に図２６を用いて説明した
と同様、属性証明書をサービスプロバイダに送付して属
性証明書内の利用制限情報の検証が実行される。オンラ
イン処理の場合は、期間制限、または回数制限のいずれ
かであり、サービスプロバイダはこれらのコンテンツ利
用条件情報を属性証明書から取得して利用制限内のコン
テンツ利用請求であれば、コンテンツ鍵の取得を可能と
する処理を行なう。利用制限を超えたコンテンツ利用請
求であれば、コンテンツ鍵の取得を可能とする処理を実
行せず、コンテンツ利用不可であるメッセージをユーザ
デバイスに送信する。

【０２５６】また、ステップＳ２０４において、オフラ
イン利用であると判定され、ステップＳ２０６で買い切
りコンテンツであると判定された場合には、属性証明書
には、ユーザデバイスのセキュリティチップのサービス
プロバイダ管理領域に格納されたＳＰ対応ストレージ秘
密鍵に対応するサービスプロバイダ（ＳＰ）対応ストレ
ージ公開鍵：ＳＣ．Ｓｔｏｐｕｂ．ＳＰ．Ｋで暗号化さ
れたコンテンツ鍵データ：［ＳＣ．Ｓｔｏｐｕｂ．Ｓ
Ｐ．Ｋ（Ｋｃ）］が格納されており、ユーザデバイスで
は、サービスプロバイダ管理領域に格納されたＳＰ対応
ストレージ秘密鍵ＳＣ．Ｓｔｏｐｒｉ．ＳＰ．Ｋを用い
て復号化処理を実行してコンテンツ鍵：Ｋｃを取得し
て、コンテンツの復号によりコンテンツを利用する。

【０２５７】さらに、ステップＳ２０４において、オフ
ライン利用であると判定され、ステップＳ２０６で回数
制限のコンテンツであると判定された場合には、ユーザ
デバイス内で、属性証明書の設定条件に基づいて回数管
理を実行して、コンテンツ利用の可否判定を実行した
後、利用可であるとの判定結果の取得を条件として、属
性証明書内に格納された暗号化コンテンツ鍵の復号化処
理を実行し、かつ、デバイス内で管理するコンテンツ利
用回数管理データの更新処理等を実行する。このために
デバイス内にコンテンツ利用回数の管理データを持つこ
とが必要となる。

【０２５８】ステップＳ２０７の利用回数管理データの
インポート処理は、コンテンツ利用回数の管理データ生
成処理である。なお、利用回数管理データのインポート
処理は、属性証明書に基づいて実行される。コンテンツ
利用回数の管理態様には、コンテンツ利用可能回数をユ
ーザデバイス内のセキュリティチップで管理する態様
と、回数管理ファイルをセキュリティチップ外の外部メ
モリ（例えばハードディスク）に格納管理し、管理デー
タのハッシュ値のみをセキュリティチップ内のメモリに
格納する２つの態様がある。これらの詳細については後
述する。ステップＳ２０８の属性証明書適用完了メッセ
ージ生成ステップは、上述のＳ２０７の利用回数管理デ
ータのインポート処理が完了したことをセキュリティチ
ップからセキュリティチップ外のユーザデバイスに通知
する処理である。

【０２５９】以下、属性証明書（ＡＣ）に記載されたコ
ンテンツ利用条件を以下の４態様に区別して、順次、説
明する。（Ａ）オンライン−利用期間制限コンテンツ（Ｂ）オンライン−利用回数制限コンテンツ（Ｃ）オフライン−買い切りコンテンツ（Ｄ）オフライン−利用回数制限コンテンツ

【０２６０】（Ａ）オンライン−利用期間制限コンテン
ツまず、属性証明書に記録されたコンテンツ利用条件がオ
ンライン処理であり、利用期間が制限されたコンテンツ
である場合の属性証明書の取得から、コンテンツ取得ま
での処理を図３４のシーケンス図に従って説明する。

【０２６１】図３４に示す処理シーケンスは、すでにサ
ービスプロバイダから暗号化コンテンツを受領済みであ
り、また、コンテンツに対応する利用条件、暗号化コン
テンツ鍵を格納した属性証明書を受領済みであるユーザ
デバイスにおける処理を示しており、左からユーザデバ
イス内のセキュリティチップ制御部、ユーザデバイス制
御部（上位ソフトウェア）、およびサービスプロバイダ
の処理を示している。

【０２６２】図３４では、最上段（ａ）は、属性証明書
がセキュリティチップの内部メモリに格納されている場
合における属性証明書からのサービスプロバイダＩＤ取
得処理、（ｂ）は、属性証明書がセキュリティチップの
外部メモリ、すなわちユーザデバイス制御部単独の制御
でアクセス可能なメモリに格納されている場合における
属性証明書からのサービスプロバイダＩＤ取得処理を示
し、これら（ａ），（ｂ）は属性証明書の格納位置に応
じて選択的に実行する。（ｃ）の相互認証処理、（ｄ）
のコンテンツ取得処理は共通に実行される。

【０２６３】まず、（ａ）の処理から説明する。（ａ
１）ユーザデバイス制御部は、利用対象コンテンツに対
応する属性証明書の検索をセキュリティチップ制御部に
要求する。（ａ２）セキュリティチップ制御部は、チッ
プのメモリに格納済みの属性証明書のリストをユーザデ
バイス制御部に出力し、（ａ３）ユーザデバイスでは付
属のブラウザによりリストを表示する。（ａ４）ユーザ
は表示されたリストから利用予定コンテンツに対応する
属性証明書（ＡＣ）を指定し、読み出し命令をセキュリ
ティチップ制御部に送信する。（ａ５）セキュリティチ
ップ制御部は、指定された属性証明書を内部メモリから
読み出してユーザデバイス制御部に出力し、（ａ６）ユ
ーザデバイスでは付属のブラウザにより属性証明書を表
示し、属性証明書格納データ中のサービスプロバイダ識
別子（ＳＰＩＤ）を取得する。

【０２６４】属性証明書がセキュリティチップの外部メ
モリ、すなわちユーザデバイス制御部単独の制御でアク
セス可能なメモリに格納されている場合は、（ｂ）の処
理となる。（ｂ１）ユーザデバイス制御部は、利用対象
コンテンツに対応する属性証明書の検索を実行し、（ｂ
２）ユーザデバイスでは付属のブラウザにより表示され
たＡＣリストから利用予定コンテンツに対応する属性証
明書（ＡＣ）を指定し、（ｂ３）読み出して属性証明書
を表示し、（ｂ４）属性証明書格納データ中のサービス
プロバイダ識別子（ＳＰＩＤ）を取得する。

【０２６５】上記（ａ）、（ｂ）のいずれかの処理によ
って取得されたサービスプロバイダ識別子（ＳＰＩ
Ｄ）は、サービスプロバイダ管理領域から、相互認証に
必要な情報を取得するために用いられる。前述したよう
に、サービスプロバイダ管理領域へのアクセスにはサー
ビスプロバイダ毎に設定されたパスワード入力が必要で
あり、ユーザは、属性証明書から取得したサービスプロ
バイダ識別子（ＳＰＩＤ）に対応するパスワード入力
により、サービスプロバイダ管理領域へのアクセスを実
行し、図３４の（ｃ１）に示すセキュリティチップとサ
ービスプロバイダ間の相互認証処理を実行する。

【０２６６】この相互認証処理は、先に説明した図１６
のＴＬＳ１．０処理または、その他の方式、例えば公開
鍵方式による相互認証処理として実行される。この相互
認証処理においては、相互の公開鍵証明書の検証がなさ
れ、必要に応じてルート認証局（ＣＡ）までの公開鍵証
明書が連鎖的に検証される。この認証処理において、セ
キュリティチップと、サポートセンタはセッション鍵
（Ｋｓｅｓ）を共有する。相互認証が成立すると、次
に、図３４（ｄ）に示す処理、すなわちコンテンツ取得
処理を実行する。

【０２６７】（ｄ１）ユーザは、ユーザデバイスの付属
のブラウザにより表示された属性証明書の権限情報（コ
ンテンツ利用条件）を確認し、属性証明書を適用したコ
ンテンツ利用要求をセキュリティチップに対して出力す
る。この例における属性証明書に記録されたコンテンツ
利用条件は、オンライン期間制限である。

【０２６８】（ｄ２）セキュリティチップ制御部は、ユ
ーザデバイス制御部からの属性証明書（ＡＣ）適用要求
を受信すると、属性証明書の検証処理を実行する。検証
処理には、権限情報（コンテンツ利用条件）の確認、フ
ォーマット確認、署名検証処理が含まれる。署名検証処
理は、例えば先に説明した図２０の処理フローと同様の
シーケンスに従って実行される。

【０２６９】さらに、必要に応じてセキュリティチップ
の制御部は、属性証明書（ＡＣ）内のＡＣ保持者の公開
鍵証明書情報に従ってリンクする公開鍵証明書を取得し
て、公開鍵証明書の検証を行なうことが好ましい。例え
ば属性証明書（ＡＣ）の発行者の信頼度が不確かである
場合には、属性証明書（ＡＣ）の発行者の公開鍵証明書
の検証を行なうことによって、認証局の公開鍵証明書を
正当に有しているか否かの判定が可能となる。なお、公
開鍵証明書が前述したように階層構成をなしている場合
は、経路を上位に辿って連鎖的な検証を行ない、ルート
認証局（ＣＡ）の発行した公開鍵証明書の検証まで実行
することが好ましい。なお、この連鎖検証が必須の場合
もある。

【０２７０】（ｄ３）属性証明書の検証により、属性証
明書の改竄なしの判定が得られると、セキュリティチッ
プの制御部は、サービスプロバイダに対して属性証明書
を送付する。属性証明書には、利用条件としてオンライ
ン期間制限コンテンツであることが記録され、また有効
期限データが格納されている。さらに、サービスプロバ
イダの保有する秘密鍵：ＳＰ．Ｓｔｏ．Ｋで暗号化され
たコンテンツ鍵のデータ、すなわち、［ＳＰ．Ｓｔｏ．
Ｋ（Ｋｃ）］が格納されている。

【０２７１】（ｄ４）セキュリティチップから属性証明
書を受信したサービスプロバイダは、属性証明書の署名
検証処理を実行する。また、この際、属性証明書にリン
クする公開鍵証明書、およびその上位公開鍵証明書を連
鎖的に検証することが好ましい。なお、この連鎖検証が
必須の場合もある。これらの検証処理により、属性証明
書の正当性が確認されると、属性証明書に格納された利
用条件データ、有効期限データを確認する。属性証明書
に記録されている利用条件としての有効期限内のコンテ
ンツ利用要求であると判定されると、属性証明書中に格
納されたコンテンツの復号に適用するコンテンツ鍵：Ｋ
ｃの暗号化データ：［ＳＰ．Ｓｔｏ．Ｋ（Ｋｃ）］の復
号を実行する。

【０２７２】サービスプロバイダは、自己の所有する秘
密鍵：ＳＰ．Ｓｔｏ．Ｋを用いて、属性証明書に格納さ
れた暗号化コンテンツ鍵：［ＳＰ．Ｓｔｏ．Ｋ（Ｋ
ｃ）］の復号化処理を実行し、コンテンツ鍵：Ｋｃを取
り出す。さらに、取り出したコンテンツ鍵：Ｋｃを先の
相互認証処理において生成したセッションキー（Ｋｓｅ
ｓ）で暗号化して、ユーザデバイスのセキュリティチッ
プに対して送信する。

【０２７３】（ｄ５）セキュリティチップの制御部は、
サービスプロバイダからセッションキーで暗号化された
コンテンツ鍵、すなわち、［Ｋｓｅｓ（Ｋｃ）］を受信
すると、相互認証時に保有したセッションキーを用いて
復号化処理を実行してコンテンツ鍵：Ｋｃを取得する。
コンテンツ鍵：Ｋｃの取得に成功すると、セキュリティ
チップ制御部は、ユーザデバイス制御部にコンテンツの
復号準備が完了したことを通知する。

【０２７４】（ｄ６）次にユーザデバイス制御部は、取
得したコンテンツ鍵を適用して復号すべき暗号化コンテ
ンツ［Ｋｃ（Ｃｏｎｔｅｎｔ）］をユーザデバイス内の
メモリ（例えばハードディスク）、あるいはセキュリテ
ィチップ制御部を介してセキュリティチップ内のメモリ
から取得する。さらに、取得した暗号化コンテンツをセ
キュリティチップに送信し、（ｄ７）セキュリティチッ
プ内で暗号化コンテンツに対してコンテンツ鍵：Ｋｃを
適用した復号化処理を実行し、復号化処理結果として得
られるコンテンツをユーザデバイス制御部に出力し、
（ｄ８）ユーザデバイスは、コンテンツを取得する。こ
れらの処理が終了すると、（ｄ９）セキュリティチップ
の制御部は、復号化処理によって取得したコンテンツ
鍵：Ｋｃ、およびコンテンツ（Ｃｏｎｔｅｎｔ）を破棄
する。

【０２７５】これらの処理によって、サービスプロバイ
ダによる属性証明書（ＡＣ）に基づく利用期間の確認処
理が行われ、制限された利用期間内である場合にのみ、
コンテンツ鍵：Ｋｃがセキュリティチップにおいて復号
可能な状態で再暗号化されて送付され、セキュリティチ
ップにおいてコンテンツ鍵が取得され、取得したコンテ
ンツ鍵によるコンテンツの復号が実行されてユーザデバ
イスにおいてコンテンツ利用が可能となる。

【０２７６】なお、サービスプロバイダからユーザデバ
イスに対するコンテンツ配信あるいは属性証明書（Ａ
Ｃ：Attribute Certificate）の配信形態としては、ユ
ーザ側からサービスプロバイダに対する要求に基づいて
実行される形態と、ユーザの要求の有無に関係なく例え
ばサブスクライバ契約を結んでいるユーザに対して、サ
ービスプロバイダから一方的に送信するいわゆるプッシ
ュ型の形態(プッシュ型モデル)のいずれの形態も可能で
ある。プッシュ型モデルにおいては、サービスプロバイ
ダが予め目標ユーザ向けの属性証明書（ＡＣ）を作成し
て配信することになる。

【０２７７】（Ｂ）オンライン−利用回数制限コンテン
ツ次に、属性証明書に記録されたコンテンツ利用条件がオ
ンライン処理であり、利用回数が制限されたコンテンツ
である場合の属性証明書の取得から、コンテンツ取得ま
での処理を図３５のシーケンス図に従って説明する。

【０２７８】図３５に示す処理シーケンスは、先に説明
した図３４の処理シーケンスと同様、すでにサービスプ
ロバイダから暗号化コンテンツを受領済みであり、ま
た、コンテンツに対応する利用条件、暗号化コンテンツ
鍵を格納した属性証明書を受領済みであるユーザデバイ
スにおける処理を示しており、左からユーザデバイス内
のセキュリティチップ制御部、ユーザデバイス制御部
（上位ソフトウェア）、およびサービスプロバイダの処
理を示している。

【０２７９】図３５に示す処理中、最上段（ａ）は、属
性証明書がセキュリティチップの内部メモリに格納され
ている場合における属性証明書からのサービスプロバイ
ダＩＤ取得処理、（ｂ）は、属性証明書がセキュリティ
チップの外部メモリ、すなわちユーザデバイス制御部単
独の制御でアクセス可能なメモリに格納されている場合
における属性証明書からのサービスプロバイダＩＤ取得
処理を示し、これら（ａ），（ｂ）は属性証明書の格納
位置に応じて選択的に実行する。（ａ）、（ｂ）の各処
理と、（ｃ）の相互認証処理は、図３４を参照して説明
したオンライン期間制限の場合の処理と同様であるので
説明を省略する。（ｃ）の相互認証が成立すると、次
に、図３５（ｄ）に示す処理、すなわちコンテンツ取得
処理を実行する。

【０２８０】（ｄ１）ユーザは、ユーザデバイスの付属
のブラウザにより表示された属性証明書の権限情報（コ
ンテンツ利用条件）を確認し、属性証明書を適用したコ
ンテンツ利用要求をセキュリティチップに対して出力す
る。この例における属性証明書に記録されたコンテンツ
利用条件は、オンライン回数制限である。

【０２８１】（ｄ２）セキュリティチップ制御部は、ユ
ーザデバイス制御部からの属性証明書（ＡＣ）適用要求
を受信すると、属性証明書の検証処理を実行する。検証
処理には、権限情報（コンテンツ利用条件）の確認、フ
ォーマット確認、署名検証処理が含まれる。署名検証処
理は、例えば先に説明した図２０の処理フローと同様の
シーケンスに従って実行される。この検証処理におい
て、セキュリティチップの制御部は、属性証明書（Ａ
Ｃ）内のＡＣ保持者の公開鍵証明書情報に従ってリンク
する公開鍵証明書から、上位に辿って連鎖的な検証を行
ない、ルート認証局（ＣＡ）の発行した公開鍵証明書の
検証まで実行することが好ましい。なお、この連鎖検証
が必須の場合もある。

【０２８２】（ｄ３）属性証明書の検証により、属性証
明書の改竄なしの判定が得られると、セキュリティチッ
プの制御部は、サービスプロバイダに対して属性証明書
を送付する。属性証明書には、利用条件としてオンライ
ン回数制限コンテンツであることが記録され、また利用
制限回数が格納されている。さらに、サービスプロバイ
ダの保有する秘密鍵：ＳＰ．Ｓｔｏ．Ｋで暗号化された
コンテンツ鍵のデータ、すなわち、［ＳＰ．Ｓｔｏ．Ｋ
（Ｋｃ）］が格納されている。

【０２８３】（ｄ４）セキュリティチップから属性証明
書を受信したサービスプロバイダは、属性証明書の署名
検証処理を実行する。また、この際、属性証明書にリン
クする公開鍵証明書、およびその上位公開鍵証明書を連
鎖的に検証することが好ましい。なお、この連鎖検証が
必須の場合もある。これらの検証処理により、属性証明
書の正当性が確認されると、属性証明書に格納された利
用条件データ、利用制限回数を確認する。利用可能回数
は、サービスプロバイダ内のデータベースに格納されて
おり、サービスプロバイダでは、データベース内の管理
データを参照して属性証明書に記録された回数制限内の
コンテンツ利用であるか否かを判定する。

【０２８４】属性証明書に記録された回数制限内のコン
テンツ利用であると判定されると、属性証明書中に格納
されたコンテンツの復号に適用するコンテンツ鍵：Ｋｃ
の暗号化データ：［ＳＰ．Ｓｔｏ．Ｋ（Ｋｃ）］の復号
を実行する。サービスプロバイダは、自己の所有する秘
密鍵：ＳＰ．Ｓｔｏ．Ｋを用いて、属性証明書に格納さ
れた暗号化コンテンツ鍵：［ＳＰ．Ｓｔｏ．Ｋ（Ｋ
ｃ）］の復号化処理を実行し、コンテンツ鍵：Ｋｃを取
り出す。

【０２８５】さらに、サービスプロバイダは、データベ
ース内のコンテンツ利用回数管理データを更新し、利用
対象コンテンツの対応する利用可能回数を１デクリメン
トする処理を行なう。さらに、サービスプロバイダで
は、取り出したコンテンツ鍵：Ｋｃを先の相互認証処理
において生成したセッションキー（Ｋｓｅｓ）で暗号化
して、ユーザデバイスのセキュリティチップに対して送
信する。

【０２８６】（ｄ５）セキュリティチップの制御部は、
サービスプロバイダからセッションキーで暗号化された
コンテンツ鍵、すなわち、［Ｋｓｅｓ（Ｋｃ）］を受信
すると、相互認証時に保有したセッションキーを用いて
復号化処理を実行してコンテンツ鍵：Ｋｃを取得する。
コンテンツ鍵：Ｋｃの取得に成功すると、セキュリティ
チップ制御部は、ユーザデバイス制御部にコンテンツの
復号準備が完了したことを通知する。

【０２８７】（ｄ６）次にユーザデバイス制御部は、取
得したコンテンツ鍵を適用して復号すべき暗号化コンテ
ンツ［Ｋｃ（Ｃｏｎｔｅｎｔ）］をユーザデバイス内の
メモリ（例えばハードディスク）、あるいはセキュリテ
ィチップ制御部を介してセキュリティチップ内のメモリ
から取得する。さらに、取得した暗号化コンテンツをセ
キュリティチップに送信し、（ｄ７）セキュリティチッ
プ内で暗号化コンテンツに対してコンテンツ鍵：Ｋｃを
適用した復号化処理を実行し、復号化処理結果として得
られるコンテンツをユーザデバイス制御部に出力し、
（ｄ８）ユーザデバイスは、コンテンツを取得する。こ
れらの処理が終了すると、（ｄ９）セキュリティチップ
の制御部は、復号化処理によって取得したコンテンツ
鍵：Ｋｃ、およびコンテンツ（Ｃｏｎｔｅｎｔ）を破棄
する。

【０２８８】これらの処理によって、サービスプロバイ
ダによる属性証明書（ＡＣ）に基づくコンテンツ利用回
数の確認処理が行われ、制限された利用回数内である場
合にのみ、コンテンツ鍵：Ｋｃがセキュリティチップに
おいて復号可能な状態で再暗号化されて送付され、セキ
ュリティチップにおいてコンテンツ鍵が取得され、取得
したコンテンツ鍵によるコンテンツの復号が実行されて
ユーザデバイスにおいてコンテンツ利用が可能となる。

【０２８９】なお、サービスプロバイダからユーザデバ
イスに対するコンテンツ配信あるいは属性証明書（Ａ
Ｃ：Attribute Certificate）の配信形態としては、ユ
ーザ側からサービスプロバイダに対する要求に基づいて
実行される形態と、ユーザの要求の有無に関係なく例え
ばサブスクライバ契約を結んでいるユーザに対して、サ
ービスプロバイダから一方的に送信するいわゆるプッシ
ュ型の形態(プッシュ型モデル)のいずれの形態も可能で
ある。プッシュ型モデルにおいては、サービスプロバイ
ダが予め目標ユーザ向けの属性証明書（ＡＣ）を作成し
て配信することになる。

【０２９０】（Ｃ）オフライン−買い切りコンテンツ次に、属性証明書に記録されたコンテンツ利用条件がオ
フライン処理であり、買い切りコンテンツである場合の
属性証明書の取得から、コンテンツ取得までの処理を図
３６のシーケンス図に従って説明する。

【０２９１】図３６に示す処理シーケンスは、先に説明
した図３４、図３５の処理シーケンスと同様、すでにサ
ービスプロバイダから暗号化コンテンツを受領済みであ
り、また、コンテンツに対応する利用条件、暗号化コン
テンツ鍵を格納した属性証明書を受領済みであるユーザ
デバイスにおける処理を示しており、左からユーザデバ
イス内のセキュリティチップ制御部、ユーザデバイス制
御部（上位ソフトウェア）、およびサービスプロバイダ
の処理を示している。

【０２９２】図３６に示す処理中、最上段（ａ）は、属
性証明書がセキュリティチップの内部メモリに格納され
ている場合における属性証明書からのサービスプロバイ
ダＩＤ取得処理、（ｂ）は、属性証明書がセキュリティ
チップの外部メモリ、すなわちユーザデバイス制御部単
独の制御でアクセス可能なメモリに格納されている場合
における属性証明書からのサービスプロバイダＩＤ取得
処理を示し、これら（ａ），（ｂ）は属性証明書の格納
位置に応じて選択的に実行する。（ａ）、（ｂ）の各処
理は、図３４を参照して説明したオンライン期間制限の
場合の処理と同様であるので説明を省略する。（ａ）、
（ｂ）のいずれかの処理によって、サービスプロバイダ
ＩＤが取得されると、次に、図３６（ｃ）に示す処理、
すなわちコンテンツ取得処理を実行する。

【０２９３】（ｃ１）ユーザは、ユーザデバイスの付属
のブラウザにより表示された属性証明書の権限情報（コ
ンテンツ利用条件）を確認し、属性証明書を適用したコ
ンテンツ利用要求をセキュリティチップに対して出力す
る。この例における属性証明書に記録されたコンテンツ
利用条件は、オフライン買い切りである。

【０２９４】（ｃ２）セキュリティチップ制御部は、ユ
ーザデバイス制御部からの属性証明書（ＡＣ）適用要求
を受信すると、属性証明書の検証処理を実行する。検証
処理には、権限情報（コンテンツ利用条件）の確認、フ
ォーマット確認、署名検証処理が含まれる。署名検証処
理は、例えば先に説明した図２０の処理フローと同様の
シーケンスに従って実行される。この検証処理におい
て、セキュリティチップの制御部は、属性証明書（Ａ
Ｃ）内のＡＣ保持者の公開鍵証明書情報に従ってリンク
する公開鍵証明書から、上位に辿って連鎖的な検証を行
ない、ルート認証局（ＣＡ）の発行した公開鍵証明書の
検証まで実行することが好ましい。なお、この連鎖検証
が必須の場合もある。

【０２９５】（ｃ３）属性証明書の検証により、属性証
明書の改竄なしの判定が得られると、セキュリティチッ
プ制御部は、属性証明書内に格納された暗号化コンテン
ツ鍵：［ＳＣ．Ｓｔｏｐｕｂ．ＳＰ．Ｋ（Ｋｃ）］を取
り出して、サービスプロバイダ管理領域に格納されたＳ
Ｐ対応ストレージ秘密鍵：ＳＣ．Ｓｔｏｐｒｉ．ＳＰ．
Ｋを適用して復号化処理を実行し、コンテンツ鍵：Ｋｃ
を取得する。コンテンツ鍵：Ｋｃの取得に成功すると、
セキュリティチップ制御部は、ユーザデバイス制御部に
コンテンツの復号準備が完了したことを通知する。

【０２９６】（ｃ４）次にユーザデバイス制御部は、取
得したコンテンツ鍵を適用して復号すべき暗号化コンテ
ンツ［Ｋｃ（Ｃｏｎｔｅｎｔ）］をユーザデバイス内の
メモリ（例えばハードディスク）、あるいはセキュリテ
ィチップ制御部を介してセキュリティチップ内のメモリ
から取得する。さらに、取得した暗号化コンテンツをセ
キュリティチップに送信し、（ｃ５）セキュリティチッ
プ内で暗号化コンテンツに対してコンテンツ鍵：Ｋｃを
適用した復号化処理を実行し、復号化処理結果として得
られるコンテンツをユーザデバイス制御部に出力し、
（ｃ６）ユーザデバイスは、コンテンツを取得する。こ
れらの処理が終了すると、（ｃ７）セキュリティチップ
の制御部は、復号化処理によって取得したコンテンツ
鍵：Ｋｃ、およびコンテンツ（Ｃｏｎｔｅｎｔ）を破棄
する。

【０２９７】これらの処理によって、属性証明書（Ａ
Ｃ）に基づく買い切りコンテンツであることの確認処理
が行われ、コンテンツ鍵：Ｋｃがセキュリティチップに
おいて復号され、コンテンツ鍵が取得され、取得したコ
ンテンツ鍵によるコンテンツの復号が実行されてユーザ
デバイスにおいてコンテンツ利用が可能となる。

【０２９８】なお、上記構成例では、公開鍵暗号方式を
適用し、コンテンツ鍵の暗号化にＳＰ対応ストレージ公
開鍵：ＳＣ．Ｓｔｏｐｕｂ．ＳＰ．Ｋを用い、コンテン
ツ鍵の復号にＳＰ対応ストレージ秘密鍵：ＳＣ．Ｓｔｏ
ｐｒｉ．ＳＰ．Ｋを用いた構成としたが、共通鍵方式を
適用することも可能であり、共通鍵方式を適用する場合
は、コンテンツ鍵の暗号化、復号化の双方の処理にＳＰ
対応ストレージ鍵（共通鍵）：ＳＣ．Ｓｔｏ．ＳＰ．Ｋ
を用いる。この場合、ＳＰ対応ストレージ鍵（共通
鍵）：ＳＣ．Ｓｔｏ．ＳＰ．Ｋは、セキュリティチップ
のメモリの対応するサービスプロバイダのサービスプロ
バイダ管理領域に格納される。

【０２９９】なお、サービスプロバイダからユーザデバ
イスに対するコンテンツ配信あるいは属性証明書（Ａ
Ｃ：Attribute Certificate）の配信形態としては、ユ
ーザ側からサービスプロバイダに対する要求に基づいて
実行される形態と、ユーザの要求の有無に関係なく例え
ばサブスクライバ契約を結んでいるユーザに対して、サ
ービスプロバイダから一方的に送信するいわゆるプッシ
ュ型の形態(プッシュ型モデル)のいずれの形態も可能で
ある。プッシュ型モデルにおいては、サービスプロバイ
ダが予め目標ユーザ向けの属性証明書（ＡＣ）を作成し
て配信することになる。

【０３００】（Ｄ）オフライン−利用回数制限コンテン
ツ次に、属性証明書に記録されたコンテンツ利用条件がオ
フライン処理であり、利用回数の制限されたコンテンツ
である場合の属性証明書の取得から、コンテンツ取得ま
での処理について説明する。属性証明書の利用条件がオ
フライン利用で、回数制限のあるコンテンツである場
合、ユーザデバイス内で、属性証明書の設定条件に基づ
いて回数管理を実行するために、デバイス内にコンテン
ツ利用回数の管理データを持つことが必要となる。コン
テンツ利用回数の管理データの保有処理が利用回数管理
データのインポート処理である。

【０３０１】（Ｄ−１）インポート処理まず、利用回数管理データのインポート処理について説
明する。コンテンツ利用回数の管理態様には、コンテン
ツ利用可能回数をユーザデバイス内のセキュリティチッ
プで管理する態様と、回数管理ファイルをセキュリティ
チップ外の外部メモリ（例えばハードディスク）に格納
管理し、管理データのハッシュ値のみをセキュリティチ
ップ内のメモリに格納する２つの態様がある。

【０３０２】最初に図３７を参照して、コンテンツ利用
可能回数をユーザデバイス内のセキュリティチップで管
理する態様とした場合の利用回数管理データのインポー
ト処理シーケンスを説明する。左からユーザデバイス内
のセキュリティチップ制御部、ユーザデバイス制御部
（上位ソフトウェア）、およびサービスプロバイダの処
理を示している。図３７の処理シーケンスは、すでにコ
ンテンツ購入処理に伴うセキュリティチップと、サービ
スプロバイダ間の相互認証が成立し、サービスプロバイ
ダからセキュリティチップに対する、購入コンテンツに
対応する属性証明書の発行処理以降の処理を示してい
る。ここで、サービスプロバイダの発行する属性証明書
は、コンテンツ利用条件として、オフライン利用での利
用回数制限コンテンツであることが記録され、コンテン
ツ利用制限回数が記録されている。

【０３０３】（１）属性証明書がサービスプロバイダか
ら発行され、送信されると、（２）セキュリティチップ
の制御部は、属性証明書の検証処理を実行する。検証処
理には、権限情報（コンテンツ利用条件）の確認、フォ
ーマット確認、署名検証処理が含まれる。署名検証処理
は、例えば先に説明した図２０の処理フローと同様のシ
ーケンスに従って実行される。この検証処理において、
セキュリティチップの制御部は、属性証明書（ＡＣ）内
のＡＣ保持者の公開鍵証明書情報に従ってリンクする公
開鍵証明書から、上位に辿って連鎖的な検証を行ない、
ルート認証局（ＣＡ）の発行した公開鍵証明書の検証ま
で実行することが好ましい。なお、この連鎖検証が必須
の場合もある。

【０３０４】（３）セキュリティチップの制御部は、属
性証明書に記録されたコンテンツ利用条件がオフライン
利用回数制限コンテンツであると判定すると、属性証明
書からコンテンツ識別子に対応するアプリケーションＩ
Ｄ、属性証明書（ＡＣ）シリアル番号、コンテンツ利用
制限回数の各データを取得する。さらに、コンテンツの
購入処理時にユーザにより入力されたユーザＩＤ、サー
ビスプロバイダＩＤの各データをユーザデバイス制御部
を介して取得し、これらの取得したアプリケーションＩ
Ｄ、属性証明書（ＡＣ）シリアル番号、ユーザＩＤの各
データに対応するコンテンツ利用回数管理データが、セ
キュリティチップ内のメモリのサービスプロバイダ管理
領域に登録済みであるか否かを検証する。なお、ユーザ
がユーザデバイスにログインしている場合には、ユーザ
ＩＤ等は保持されているので、ユーザＩＤ、サービスプ
ロバイダＩＤはユーザが入力する代わりにユーザデバイ
スが送信してもよい。

【０３０５】セキュリティチップのメモリには、前述し
たように、登録されたサービスプロバイダ毎にサービス
プロバイダ管理領域が設定され、その管理領域内にコン
テンツ利用回数管理データが登録されることになる。図
３８にセキュリティチップ内のメモリのサービスプロバ
イダ管理領域内に設定されるコンテンツ利用回数管理デ
ータの構成例を示す。

【０３０６】図３８に示すように、サービスプロバイダ
管理領域には、サービスプロバイダＩＤ、ユーザＩＤ毎
に、コンテンツ識別子としてのアプリケーションＩＤ
（Ａｐｐ．ＩＤ＃ｎ）、対応する属性証明書（ＡＣ）の
識別子であるＡＣシリアル（ＡＣＳｅｒｉａｌ＃
ｎ）、さらに残りの利用可能回数データ（Ｃｏｕｎｔ＃
ｎ）が対応付けられて格納される。同一のコンテンツで
あっても利用ユーザ毎に異なる属性証明書に基づく利用
回数カウントを可能としたデータ構成となっている。

【０３０７】図３７に戻って利用回数管理データのイン
ポート処理のシーケンスについて説明を続ける。（３）
セキュリティチップの制御部は、属性証明書から取得し
たコンテンツ識別子に対応するアプリケーションＩＤ、
属性証明書（ＡＣ）シリアル番号、コンテンツ利用制限
回数の各データ、ユーザにより入力されたユーザＩＤ、
サービスプロバイダＩＤの各データに対応するコンテン
ツ利用回数管理データが、セキュリティチップ内のメモ
リのサービスプロバイダ管理領域に登録済みであるか否
かを検証し、コンテンツ利用回数管理データが登録され
ていないことを確認すると、（４）コンテンツ利用回数
管理データをサービスプロバイダ管理領域に追加登録
し、（５）追加登録の終了後、属性証明書受信メッセー
ジを生成して、サービスプロバイダに送信する。

【０３０８】図３７の例では、サービスプロバイダから
受領した属性証明書（ＡＣ）は、アプリケーションＩＤ：０００１属性証明書（ＡＣ）シリアル：１３４５コンテンツ利用制限回数：５の各データが記録され、ユーザ入力データは、ユーザＩＤ：６７３７サービスプロバイダＩＤ：５６７８である。

【０３０９】セキュリティチップの制御部は、これらの
データに対応するコンテンツ利用回数管理データがメモ
リ内の対応するサービスプロバイダ管理領域にあるか否
かを検証する。図３７に示すＳＰ管理領域データ（更新
前）のデータ中には、サービスプロバイダＩＤ：５６７
８、ユーザＩＤ：６７３７に対応するコンテンツ利用回
数管理データとして、アプリケーションＩＤ：０００
１、属性証明書（ＡＣ）シリアル：１３４５に対応する
データは存在しない。

【０３１０】従って、今回サービスプロバイダから受領
した属性証明書に対応するコンテンツ利用回数管理デー
タをサービスプロバイダＩＤ：５６７８、ユーザＩＤ：
６７３７に対応するコンテンツ利用回数管理データとし
て、新たに追加する処理を行なう。その結果、図の下段
に示すＳＰ管理領域データ（更新後）のデータ中に、ア
プリケーションＩＤ：０００１、属性証明書（ＡＣ）シ
リアル：１３４５の回数管理データが追加され、利用可
能回数として、受領した属性証明書に記録されたコンテ
ンツ利用制限回数：５が設定される。

【０３１１】コンテンツの利用時には、このコンテンツ
利用回数管理データが参照され、利用毎に利用可能回数
を１デクリメントして、５→４→３→２→１→０とする
データ更新が実行され、利用可能回数が０となった以後
のコンテンツ利用が拒否され、属性証明書に記録された
利用制限回数内でのコンテンツ利用が可能となる。この
コンテンツ利用処理については、後述する。

【０３１２】なお、サービスプロバイダから受領した属
性証明書のアプリケーションＩＤ、属性証明書（ＡＣ）
シリアルと同一のデータがすでに、対応するサービスプ
ロバイダＩＤ、ユーザＩＤのサービスプロバイダ管理領
域内のコンテンツ利用回数管理データとして登録済みで
ある場合には、重複した属性証明書の発行であると判定
し、その属性証明書に基づくコンテンツ利用回数管理デ
ータの追加登録は実行しない。

【０３１３】また、サービスプロバイダから受領した属
性証明書のアプリケーションＩＤと同一であるが、属性
証明書（ＡＣ）シリアルが異なるデータがすでに、対応
するサービスプロバイダＩＤ、ユーザＩＤのサービスプ
ロバイダ管理領域内のコンテンツ利用回数管理データと
して登録済みである場合には、異なる属性証明書に基づ
く同一コンテンツの新たな利用を可能とする属性証明書
であると判定し、その属性証明書に基づくコンテンツ利
用回数管理データの追加登録を実行する。

【０３１４】すなわち、同一のサービスプロバイダＩ
Ｄ、同一ユーザＩＤのサービスプロバイダ管理領域内の
コンテンツ利用回数管理データとして、すでに、例えばアプリケーションＩＤ：０００１、ＡＣシリアル：０００１残りコンテンツ利用回数：２のデータが存在する場合であっても、

【０３１５】アプリケーションＩＤ：０００１ＡＣシリアル：０００２残りコンテンツ利用回数：５の新たな管理データが追加登録される。

【０３１６】図３９に、コンテンツ利用可能回数をユー
ザデバイス内のセキュリティチップで管理する態様とし
た場合のセキュリティチップ内で実行される利用回数管
理データのインポート処理フローを示す。各ステップに
ついて説明する。

【０３１７】まず、ステップＳ２２１において、属性証
明書（検証済み）からアプリケーションＩＤ、利用制限
回数、属性証明書シリアル番号を取り出す。ステップＳ
２２２において、セキュリティチップ内のメモリに設定
済みのサービスプロバイダ管理領域内に、属性証明書に
格納されたと同一のアプリケーションＩＤの回数管理デ
ータがあるか否かを検索する。

【０３１８】ステップＳ２２３で、同一のアプリケーシ
ョンＩＤの回数管理データの登録がないと判定された場
合は、ステップＳ２２５に進み、属性証明書に従ってア
プリケーションＩＤ：ｎｎｎｎ、属性証明書（ＡＣ）シ
リアル：ｍｍｍｍ、利用可能回数として、受領した属性
証明書に記録されたコンテンツ利用制限回数：ｘを設定
して利用回数管理データ登録を行なう。

【０３１９】一方、ステップＳ２２３において、同一の
アプリケーションＩＤの回数管理データが登録済みと判
定された場合は、ステップＳ２２４に進み、さらに、属
性証明書から取得した属性証明書（ＡＣ）シリアルと一
致する回数管理データがメモリ内のサービスプロバイダ
管理領域に登録済みであるか否かを判定し、登録済みで
ある場合は、同一の属性証明書に対する重複処理である
と判定して、新たなデータ登録は実行せず処理を終了す
る。一方、属性証明書から取得した属性証明書（ＡＣ）
シリアルと一致する回数管理データがメモリ内のサービ
スプロバイダ管理領域に登録済みでないと判定した場合
は、ステップＳ２２５に進み、属性証明書に従ってアプ
リケーションＩＤ：ｎｎｎｎ、属性証明書（ＡＣ）シリ
アル：ｍｍｍｍ、利用可能回数データとして、受領した
属性証明書に記録されたコンテンツ利用制限回数：ｘを
設定して利用回数管理データの登録を行なう。

【０３２０】次に、図４０を参照して、回数管理ファイ
ルをセキュリティチップ外の外部メモリ（例えばハード
ディスク）に格納管理し、管理データのハッシュ値のみ
をセキュリティチップ内のメモリに格納する処理態様と
した場合の利用回数管理データのインポート処理シーケ
ンスを説明する。左からユーザデバイス内のセキュリテ
ィチップ制御部、ユーザデバイス制御部（上位ソフトウ
ェア）、およびサービスプロバイダの処理を示してい
る。図４０の処理シーケンスは、すでにコンテンツ購入
処理に伴うセキュリティチップと、サービスプロバイダ
間の相互認証が成立し、サービスプロバイダからセキュ
リティチップに対する、購入コンテンツに対応する属性
証明書の発行処理以降の処理を示している。ここで、サ
ービスプロバイダの発行する属性証明書は、コンテンツ
利用条件として、オフライン利用での利用回数制限コン
テンツであることが記録され、コンテンツ利用制限回数
が記録されている。

【０３２１】この処理態様は、セキュリティチップ内の
限られたメモリ領域を有効に活用する構成であり、回数
管理データの実データファイルをセキュリティチップ外
の外部メモリ（例えばハードディスク）に格納管理し、
この外部管理ファイル情報のハッシュ（Ｈａｓｈ）値
を、セキュリティチップ内部で管理することで、外部管
理ファイル情報の改竄を検証することを可能としたもの
である。ハッシュ関数とは、メッセージを入力とし、こ
れを所定のビット長のデータに圧縮し、ハッシュ値とし
て出力する関数である。ハッシュ関数は、ハッシュ値
（出力）から入力を予測することが難しく、ハッシュ関
数に入力されたデータの1ビットが変化したとき、ハッ
シュ値の多くのビットが変化し、また、同一のハッシュ
値を持つ異なる入力データを探し出すことが困難である
特徴を有する。ハッシュ関数としては、ＭＤ４、ＭＤ
５、ＳＨＡ−１などが用いられる場合もあるし、ＤＥＳ
−ＣＢＣが用いられる場合もある。この場合は、最終出
力値となるＭＡＣがハッシュ値となる。

【０３２２】図４０に示す処理シーケンスについて説明
する。（１）属性証明書がサービスプロバイダから発行
され、送信されると、（２）セキュリティチップの制御
部は、属性証明書の検証処理を実行する。検証処理に
は、権限情報（コンテンツ利用条件）の確認、フォーマ
ット確認、署名検証処理が含まれる。署名検証処理は、
例えば先に説明した図２０の処理フローと同様のシーケ
ンスに従って実行される。この検証処理において、セキ
ュリティチップの制御部は、属性証明書（ＡＣ）内のＡ
Ｃ保持者の公開鍵証明書情報に従ってリンクする公開鍵
証明書から、上位に辿って連鎖的な検証を行ない、ルー
ト認証局（ＣＡ）の発行した公開鍵証明書の検証まで実
行することが好ましい。なお、この連鎖検証が必須の場
合もある。

【０３２３】セキュリティチップの制御部は、属性証明
書に記録されたコンテンツ利用条件がオフライン利用回
数制限コンテンツであると判定すると、外部のメモリか
らの回数管理ファイルの読み出し処理を実行する。図で
はユーザデバイス制御部の管理するＨＤＤに回数管理フ
ァイルがあり、（３）ユーザデバイス制御部において回
数管理ファイルが読み出されてセキュリティチップに出
力される。この読み出し対象は、管理ファイル全データ
であっても、あるいはコンテンツに対応するサービスプ
ロバイダに関するデータのみであってもよい。

【０３２４】次に、セキュリティチップの制御部は、
（４）ユーザデバイス制御部から受信した回数管理ファ
イルをセキュリティチップ内のＲＡＭに展開し、展開デ
ータに基づいてハッシュ値を計算する。回数管理データ
は、サービスプロバイダＩＤとユーザＩＤに対応付けら
れた複数の回数管理データを格納したフィールド構成を
持つ。セキュリティチップのメモリ内のサービスプロバ
イダ管理領域には、サービスプロバイダＩＤとユーザＩ
Ｄに対応付けられたフィールドデータに対してハッシュ
値が生成され格納されている。

【０３２５】セキュリティチップの制御部は、ユーザデ
バイス制御部から受信し、ＲＡＭに展開した回数管理フ
ァイルから、ユーザにより指定されているサービスプロ
バイダＩＤ、ユーザＩＤに対応するフィールドデータを
抽出してハッシュ値を計算し、計算された値と、セキュ
リティチップ内のメモリのサービスプロバイダ管理領域
に格納されたハッシュ値とを比較する。算出ハッシュ値
と、格納ハッシュ値が一致すれば、データに改竄がない
と判定し、次の処理に進む。

【０３２６】図の例では、ＲＡＭ展開データの、サービ
スプロバイダＩＤ：５６７８、ユーザＩＤ：６７３７の
フィールドデータに基づいてハッシュ値が算出され、セ
キュリティチップ内の対応するサービスプロバイダ（Ｓ
Ｐ）管理領域内に格納された対応するフィールド、すな
わち、サービスプロバイダＩＤ：５６７８、ユーザＩ
Ｄ：６７３７のハッシュ値：２９０ａと比較することに
なる。

【０３２７】（５）ハッシュ値が一致した場合は、一致
した旨を示す通知をユーザデバイス制御部に送信し、一
致が得られなかった場合はエラーメッセージをユーザデ
バイス制御部に送信する。（６）次に、セキュリティチ
ップの制御部は、属性証明書からコンテンツ識別子に対
応するアプリケーションＩＤ、属性証明書（ＡＣ）シリ
アル番号、コンテンツ利用制限回数の各データを取得す
る。さらに、コンテンツの購入処理時にユーザにより入
力されたユーザＩＤ、サービスプロバイダＩＤの各デー
タをユーザデバイス制御部を介して取得し、これらの取
得したアプリケーションＩＤ、属性証明書（ＡＣ）シリ
アル番号、ユーザＩＤの各データに対応するコンテンツ
利用回数管理データが、ユーザデバイス制御部から受信
し、ＲＡＭに展開した回数管理ファイルに登録済みであ
るか否かを検証する。

【０３２８】コンテンツ利用回数管理データが登録され
ていないことを確認すると、（７）コンテンツの利用回
数管理データを属性証明書（ＡＣ）から取り出し、ＲＡ
Ｍに展開した回数管理ファイルに追加登録し、（８）追
加データに基づく新たなハッシュ値を計算して、（９）
セキュリティチップ内の対応するサービスプロバイダ
（ＳＰ）管理領域内に格納された対応するフィールドに
格納する。（１０）追加登録の終了後、属性証明書受信
メッセージを更新した回数管理ファイルとともに、ユー
ザデバイスに送信し、（１１）ユーザデバイスは、受信
した回数管理ファイルをハードデイスクに格納する。

【０３２９】図４０の例では、サービスプロバイダから
受領した属性証明書（ＡＣ）は、アプリケーションＩＤ：０００１属性証明書（ＡＣ）シリアル：１３４５コンテンツ利用制限回数：５の各データが記録され、ユーザ入力データは、ユーザＩＤ：６７３７サービスプロバイダＩＤ：５６７８である。

【０３３０】セキュリティチップの制御部は、これらの
データに対応するコンテンツ利用回数管理データがＲＡ
Ｍに展開した回数管理ファイルに登録済みであるか否か
を検証する。図４０に示す最上段のＳＣ内ＲＡＭのデー
タ中には、サービスプロバイダＩＤ：５６７８、ユーザ
ＩＤ：６７３７に対応するコンテンツ利用回数管理デー
タとして、アプリケーションＩＤ：０００１、属性証明
書（ＡＣ）シリアル：１３４５に対応するデータは存在
しない。

【０３３１】従って、今回サービスプロバイダから受領
した属性証明書に対応するコンテンツ利用回数管理デー
タをサービスプロバイダＩＤ：５６７８、ユーザＩＤ：
６７３７に対応するコンテンツ利用回数管理データとし
て、新たに追加する処理を行なう。その結果、図の中段
に示すＳＣ内ＲＡＭのデータ中に、アプリケーションＩ
Ｄ：０００１、属性証明書（ＡＣ）シリアル：１３４５
の回数管理データが追加され、利用可能回数として、受
領した属性証明書に記録されたコンテンツ利用制限回
数：５が設定される。

【０３３２】さらに、サービスプロバイダＩＤ：５６７
８、ユーザＩＤ：６７３７に対応するフィールドデータ
に基づいてハッシュ値が算出される。図の例では、デー
タ更新前のハッシュ値は２９０ａであり、データ更新後
のハッシュ値が８７３１であり、図の最下段のＳＰ管理
領域のハッシュ値：８７３１が更新値として格納される
ことになる。

【０３３３】コンテンツの利用時には、このコンテンツ
利用回数管理データが参照され、利用毎に利用可能回数
を１デクリメントして、５→４→３→２→１→０とする
データ更新が実行されるとともに、更新データに基づい
て新たなハッシュ値が算出されて、更新処理が実行され
ることになる。このコンテンツ利用処理については、後
述する。

【０３３４】なお、サービスプロバイダから受領した属
性証明書のアプリケーションＩＤ、属性証明書（ＡＣ）
シリアルと同一のデータがすでに、ユーザデバイスから
受信し、ＲＡＭに展開した回数管理ファイルの対応する
サービスプロバイダＩＤ、ユーザＩＤのフィールドのコ
ンテンツ利用回数管理データとして登録済みである場合
には、重複した属性証明書の発行であると判定し、その
属性証明書に基づくコンテンツ利用回数管理データの追
加登録は実行しない。

【０３３５】また、サービスプロバイダから受領した属
性証明書のアプリケーションＩＤと同一であるが、属性
証明書（ＡＣ）シリアルが異なるデータがすでに、ユー
ザデバイスから受信し、ＲＡＭに展開した回数管理ファ
イルの対応するサービスプロバイダＩＤ、ユーザＩＤの
フィールドのコンテンツ利用回数管理データとして登録
済みである場合には、異なる属性証明書に基づく同一コ
ンテンツの新たな利用を可能とする属性証明書であると
判定し、その属性証明書に基づくコンテンツ利用回数管
理データの追加登録、ハッシュ値更新処理を実行する。

【０３３６】図４１に、回数管理ファイルをセキュリテ
ィチップ外の外部メモリ（例えばハードディスク）に格
納管理し、管理データのハッシュ値のみをセキュリティ
チップ内のメモリに格納する処理態様とした場合の利用
回数管理データのインポート処理フローを示す。各ステ
ップについて説明する。

【０３３７】まず、ステップＳ２４１において、外部メ
モリから回数管理ファイルを読み込み、ステップＳ２４
２において、サービスプロバイダＩＤ、ユーザＩＤに基
づいて特定されるフィールドデータに基づくハッシュ値
を算出し、算出ハッシュ値と、セキュリティチップのメ
モリ内のサービスプロバイダ管理領域に格納ずみのハッ
シュ値と一致するか否かを検証（Ｓ２４３）する。一致
しない場合は、外部メモリから読み出した回数管理ファ
イルが改竄されていると判定し、エラー処理、例えばそ
の後の処理を中止する。

【０３３８】ハッシュ値が一致し、外部メモリから読み
出した回数管理ファイルが改竄されていないと判定した
場合は、ステップＳ２４４に進み、属性証明書（検証済
み）からアプリケーションＩＤ、利用制限回数、属性証
明書シリアル番号を取り出す。次に、ステップＳ２４５
において、ユーザデバイス制御部から受信し、ＲＡＭに
展開した回数管理ファイルに、属性証明書に格納された
ものと同一のアプリケーションＩＤの回数管理データが
あるか否かを検索する。

【０３３９】ステップＳ２４６で、同一のアプリケーシ
ョンＩＤの回数管理データの登録がないと判定された場
合は、ステップＳ２４７に進み、属性証明書に従ってア
プリケーションＩＤ：ｎｎｎｎ、属性証明書（ＡＣ）シ
リアル：ｍｍｍｍ、利用可能回数として、受領した属性
証明書に記録されたコンテンツ利用制限回数：ｘを設定
して利用回数管理データの登録を行なう。

【０３４０】一方、ステップＳ２４６において、同一の
アプリケーションＩＤの回数管理データの登録が登録済
みと判定された場合は、ステップＳ２５１に進み、さら
に、属性証明書から取得した属性証明書（ＡＣ）シリア
ルと一致する回数管理データがＲＡＭに展開した回数管
理ファイルに登録済みであるか否かを判定し、登録済み
である場合は、同一の属性証明書に対する重複処理であ
ると判定して、新たなデータ登録は実行せず処理を終了
する。一方、属性証明書から取得した属性証明書（Ａ
Ｃ）シリアルと一致する回数管理データがＲＡＭに展開
した回数管理ファイルに登録済みでないと判定した場合
は、ステップＳ２４７に進み、属性証明書に従ってアプ
リケーションＩＤ：ｎｎｎｎ、属性証明書（ＡＣ）シリ
アル：ｍｍｍｍ、利用可能回数として、受領した属性証
明書に記録されたコンテンツ利用制限回数：ｘを設定し
て利用回数管理データ登録を行なう。

【０３４１】ステップＳ２４７において、属性証明書に
従って、新たな回数管理データが、ＲＡＭに展開した回
数管理ファイルに書き込まれると、ステップＳ２４８に
おいて、新規追加データを含めたデータに基づいて新た
なハッシュ値が計算され、新たなハッシュ値をセキュリ
ティチップ内の対応するサービスプロバイダ（ＳＰ）管
理領域内に格納された対応するフィールドに格納する。
さらに、ステップＳ２４９において、更新した回数管理
ファイルに基づいて外部メモリ（例えばハードディス
ク）に格納された回数管理ファイルの更新が実行され
る。

【０３４２】次に、属性証明書に記録されたコンテンツ
利用条件がオフライン処理であり、利用回数制限コンテ
ンツである場合の属性証明書の取得から、コンテンツ取
得までの処理を図４２のシーケンス図に従って説明す
る。

【０３４３】図４２に示す処理シーケンスは、先に説明
した図３４、図３５、図３６の処理シーケンスと同様、
すでにサービスプロバイダから暗号化コンテンツを受領
済みであり、また、コンテンツに対応する利用条件、暗
号化コンテンツ鍵を格納した属性証明書を受領済みであ
るユーザデバイスにおける処理を示しており、左からユ
ーザデバイス内のセキュリティチップ制御部、ユーザデ
バイス制御部（上位ソフトウェア）、およびサービスプ
ロバイダの処理を示している。

【０３４４】図４２に示す処理中、最上段（ａ）は、属
性証明書がセキュリティチップの内部メモリに格納され
ている場合における属性証明書からのサービスプロバイ
ダＩＤ取得処理、（ｂ）は、属性証明書がセキュリティ
チップの外部メモリ、すなわちユーザデバイス制御部単
独の制御でアクセス可能なメモリに格納されている場合
における属性証明書からのサービスプロバイダＩＤ取得
処理を示し、これら（ａ），（ｂ）は属性証明書の格納
位置に応じて選択的に実行する。（ａ）、（ｂ）の各処
理は、図３４を参照して説明したオンライン期間制限の
場合の処理と同様であるので説明を省略する。（ａ）、
（ｂ）のいずれかの処理によって、サービスプロバイダ
ＩＤが取得されると、次に、図４２（ｃ）に示す処理、
すなわちコンテンツ取得処理を実行する。

【０３４５】（ｃ１）ユーザは、ユーザデバイスの付属
のブラウザにより表示された属性証明書の権限情報（コ
ンテンツ利用条件）を確認し、属性証明書を適用したコ
ンテンツ利用要求をセキュリティチップに対して出力す
る。この例における属性証明書に記録されたコンテンツ
利用条件は、オフライン利用回数制限である。

【０３４６】（ｃ２）セキュリティチップ制御部は、ユ
ーザデバイス制御部からの属性証明書（ＡＣ）適用要求
を受信すると、属性証明書の検証処理を実行する。検証
処理には、権限情報（コンテンツ利用条件）の確認、フ
ォーマット確認、署名検証処理が含まれる。署名検証処
理は、例えば先に説明した図２０の処理フローと同様の
シーケンスに従って実行される。この検証処理におい
て、セキュリティチップの制御部は、属性証明書（Ａ
Ｃ）内のＡＣ保持者の公開鍵証明書情報に従ってリンク
する公開鍵証明書から、上位に辿って連鎖的な検証を行
ない、ルート認証局（ＣＡ）の発行した公開鍵証明書の
検証まで実行することが好ましい。なお、この連鎖検証
が必須の場合もある。

【０３４７】（ｃ３）属性証明書の検証により、属性証
明書の改竄なしの判定が得られると、セキュリティチッ
プ制御部は、回数管理データの更新処理を実行する。回
数管理データの更新処理の詳細については、後述する。
さらに、セキュリティチップ制御部は、（ｃ４）属性証
明書内に格納された暗号化コンテンツ鍵：［ＳＣ．Ｓｔ
ｏｐｕｂ．ＳＰ．Ｋ（Ｋｃ）］を取り出して、サービス
プロバイダ管理領域に格納されたＳＰ対応ストレージ秘
密鍵：ＳＣ．Ｓｔｏｐｒｉ．ＳＰ．Ｋを適用して復号化
処理を実行し、コンテンツ鍵：Ｋｃを取得する。コンテ
ンツ鍵：Ｋｃの取得に成功すると、セキュリティチップ
制御部は、ユーザデバイス制御部にコンテンツの復号準
備が完了したことを通知する。

【０３４８】（ｃ５）次にユーザデバイス制御部は、取
得したコンテンツ鍵を適用して復号すべき暗号化コンテ
ンツ［Ｋｃ（Ｃｏｎｔｅｎｔ）］をユーザデバイス内の
メモリ（例えばハードディスク）、あるいはセキュリテ
ィチップ制御部を介してセキュリティチップ内のメモリ
から取得する。さらに、取得した暗号化コンテンツをセ
キュリティチップに送信し、（ｃ６）セキュリティチッ
プ内で暗号化コンテンツに対してコンテンツ鍵：Ｋｃを
適用した復号化処理を実行し、復号化処理結果として得
られるコンテンツをユーザデバイス制御部に出力し、
（ｃ７）ユーザデバイスは、コンテンツを取得する。こ
れらの処理が終了すると、（ｃ８）セキュリティチップ
の制御部は、復号化処理によって取得したコンテンツ
鍵：Ｋｃ、およびコンテンツ（Ｃｏｎｔｅｎｔ）を破棄
する。

【０３４９】これらの処理によって、属性証明書（Ａ
Ｃ）に基づくコンテンツの利用回数制限内のコンテンツ
利用である場合に限り、コンテンツ鍵：Ｋｃがセキュリ
ティチップにおいて復号され、コンテンツ鍵が取得さ
れ、取得したコンテンツ鍵によるコンテンツの復号が実
行されてユーザデバイスにおいてコンテンツ利用が可能
となる。

【０３５０】なお、上記構成例では、公開鍵暗号方式を
適用し、コンテンツ鍵の暗号化にＳＰ対応ストレージ公
開鍵：ＳＣ．Ｓｔｏｐｕｂ．ＳＰ．Ｋを用い、コンテン
ツ鍵の復号にＳＰ対応ストレージ秘密鍵：ＳＣ．Ｓｔｏ
ｐｒｉ．ＳＰ．Ｋを用いた構成としたが、共通鍵方式を
適用することも可能であり、共通鍵方式を適用する場合
は、コンテンツ鍵の暗号化、復号化の双方の処理にＳＰ
対応ストレージ鍵（共通鍵）：ＳＣ．Ｓｔｏ．ＳＰ．Ｋ
を用いる。この場合、ＳＰ対応ストレージ鍵（共通
鍵）：ＳＣ．Ｓｔｏ．ＳＰ．Ｋは、セキュリティチップ
のメモリの対応するサービスプロバイダのサービスプロ
バイダ管理領域に格納される。

【０３５１】なお、サービスプロバイダからユーザデバ
イスに対するコンテンツ配信あるいは属性証明書（Ａ
Ｃ：Attribute Certificate）の配信形態としては、ユ
ーザ側からサービスプロバイダに対する要求に基づいて
実行される形態と、ユーザの要求の有無に関係なく例え
ばサブスクライバ契約を結んでいるユーザに対して、サ
ービスプロバイダから一方的に送信するいわゆるプッシ
ュ型の形態(プッシュ型モデル)のいずれの形態も可能で
ある。プッシュ型モデルにおいては、サービスプロバイ
ダが予め目標ユーザ向けの属性証明書（ＡＣ）を作成し
て配信することになる。

【０３５２】次に、図４３、図４４を参照して、利用回
数管理データの更新処理について説明する。コンテンツ
利用可能回数の管理態様には、前述したようにコンテン
ツ利用可能回数をユーザデバイス内のセキュリティチッ
プで管理する態様と、回数管理ファイルをセキュリティ
チップ外の外部メモリ（例えばハードディスク）に格納
管理し、管理データのハッシュ値のみをセキュリティチ
ップ内のメモリに格納する２つの態様がある。図４３は
前者、図４４は後者の態様における回数管理データの更
新処理シーケンスを説明する図である。

【０３５３】最初に図４３を参照して、コンテンツ利用
可能回をユーザデバイス内のセキュリティチップで管理
する態様とした場合の回数管理データの更新処理シーケ
ンスを説明する。左からユーザデバイス内のセキュリテ
ィチップ制御部、ユーザデバイス制御部（上位ソフトウ
ェア）の処理を示している。図４３の処理シーケンス
は、すでにセキュリティチップ内で属性証明書の検証が
済んでいるものとして、その後の処理を示している。

【０３５４】（１）セキュリティチップの制御部は、検
証済みの属性証明書に記録されたコンテンツ利用条件が
オフライン利用回数制限コンテンツであると判定する
と、属性証明書からコンテンツ識別子に対応するアプリ
ケーションＩＤ、属性証明書（ＡＣ）シリアル番号、コ
ンテンツ利用制限回数の各データを取得する。さらに、
コンテンツの購入処理時にユーザにより入力されたユー
ザＩＤ、サービスプロバイダＩＤの各データをユーザデ
バイス制御部を介して取得し、これらの取得したアプリ
ケーションＩＤ、属性証明書（ＡＣ）シリアル番号、ユ
ーザＩＤの各データに対応するコンテンツ利用回数管理
データが、セキュリティチップ内のメモリのサービスプ
ロバイダ管理領域に登録済みであるか否かを検証する。

【０３５５】セキュリティチップのメモリには、前述し
たように、登録されたサービスプロバイダ毎にサービス
プロバイダ管理領域が設定され、その管理領域内にコン
テンツ利用回数管理データが登録されることになる。

【０３５６】図４３に示す例では、属性証明書（ＡＣ）
は、アプリケーションＩＤ：０００２属性証明書（ＡＣ）シリアル：３２７８コンテンツ利用制限回数：１０の各データが記録され、ユーザ入力データは、ユーザＩＤ：６７３７サービスプロバイダＩＤ：５６７８である。

【０３５７】セキュリティチップの制御部は、これらの
データに対応するコンテンツ利用回数管理データがメモ
リ内の対応するサービスプロバイダ管理領域にあるか否
かを検証する。図４３に示すＳＰ管理領域データ（更新
前）のデータ中には、サービスプロバイダＩＤ：５６７
８、ユーザＩＤ：６７３７に対応するコンテンツ利用回
数管理データとして、アプリケーションＩＤ：０００
２、属性証明書（ＡＣ）シリアル：３２７８に対応する
データが存在し、利用可能回数（残回数）：７と設定さ
れている。

【０３５８】（２）セキュリティチップ制御部は、この
抽出データから利用可能回数（残回数）：７＞０である
こと、さらに、属性証明書に記録された制限回数以下、
１０≧７であることを確認し、これらが確認されたこと
を条件としてコンテンツの利用を許可、すなわち、属性
証明書に格納された（３）暗号化コンテンツ鍵の復号化
処理を実行する。

【０３５９】（４）さらに、セキュリティチップ制御部
は、メモリ内の対応するサービスプロバイダ管理領域の
対応データの利用可能回数を１減少させるデータ更新処
理を実行する。この場合は、アプリケーションＩＤ：０
００２、属性証明書（ＡＣ）シリアル：３２７８に対応
するデータ中の、利用可能回数（残回数）：７を６に更
新する処理を実行する。なお、（３）の暗号化コンテン
ツ鍵の復号化処理と、（４）の回数管理データの更新処
理は、処理手順を（４）を先に（３）を後にする構成と
してもよく、また並列に実行してもよい。

【０３６０】次に、図４４を参照して、回数管理ファイ
ルをセキュリティチップ外の外部メモリ（例えばハード
ディスク）に格納管理し、管理データのハッシュ値のみ
をセキュリティチップ内のメモリに格納する態様とした
場合の回数管理データの更新処理シーケンスを説明す
る。左からユーザデバイス内のセキュリティチップ制御
部、ユーザデバイス制御部（上位ソフトウェア）の処理
を示している。図４４の処理シーケンスは、すでにセキ
ュリティチップ内で属性証明書の検証が済んでいるもの
として、その後の処理を示している。

【０３６１】セキュリティチップの制御部は、属性証明
書に記録されたコンテンツ利用条件がオフライン利用回
数制限コンテンツであると判定すると、外部のメモリか
らの回数管理ファイルの読み出し処理を実行する。図で
はユーザデバイス制御部の管理するＨＤＤに回数管理フ
ァイルがあり、（１）ユーザデバイス制御部において回
数管理ファイルが読み出されてセキュリティチップに出
力される。この読み出し対象は、管理ファイル全データ
であっても、あるいはコンテンツに対応するサービスプ
ロバイダに関するデータのみであってもよい。

【０３６２】次に、セキュリティチップの制御部は、
（２）ユーザデバイス制御部から受信した回数管理ファ
イルをセキュリティチップ内のＲＡＭに展開し、展開デ
ータに基づいてハッシュ値を計算する。回数管理データ
は、サービスプロバイダＩＤとユーザＩＤに対応付けら
れた複数の回数管理データを格納したフィールド構成を
持つ。セキュリティチップのメモリ内のサービスプロバ
イダ管理領域には、サービスプロバイダＩＤとユーザＩ
Ｄに対応付けられたフィールドデータに対してハッシュ
値が生成され格納されている。

【０３６３】セキュリティチップの制御部は、ユーザデ
バイスから受信し、ＲＡＭに展開した回数管理ファイル
から、ユーザにより指定されているサービスプロバイダ
ＩＤ、ユーザＩＤに対応するフィールドデータを抽出し
てハッシュ値を計算し、計算された値と、セキュリティ
チップ内のメモリのサービスプロバイダ管理領域に格納
されたハッシュ値とを比較する。算出ハッシュ値と、格
納ハッシュ値が一致すれば、データに改竄がないと判定
し、次の処理に進む。

【０３６４】図の例では、ＲＡＭ展開データの、サービ
スプロバイダＩＤ：５６７８、ユーザＩＤ：６７３７の
フィールドデータに基づいてハッシュ値が算出され、セ
キュリティチップ内の対応するサービスプロバイダ（Ｓ
Ｐ）管理領域内に格納された対応するフィールド、すな
わち、サービスプロバイダＩＤ：５６７８、ユーザＩ
Ｄ：６７３７のハッシュ値：８７３１と比較することに
なる。

【０３６５】（３）ハッシュ値が一致した場合は、一致
した旨を示す通知をユーザデバイスに送信し、一致が得
られなかった場合はエラーメッセージをユーザデバイス
に送信する。（４）次に、セキュリティチップの制御部
は、属性証明書からコンテンツ識別子に対応するアプリ
ケーションＩＤ、属性証明書（ＡＣ）シリアル番号、コ
ンテンツ利用制限回数の各データを取得する。さらに、
コンテンツの購入処理時にユーザにより入力されたユー
ザＩＤ、サービスプロバイダＩＤの各データをユーザデ
バイス制御部を介して取得し、これらの取得したアプリ
ケーションＩＤ、属性証明書（ＡＣ）シリアル番号、ユ
ーザＩＤの各データに対応するコンテンツ利用回数管理
データが、ユーザデバイスから受信し、ＲＡＭに展開し
た回数管理ファイルに登録済みであるか否かを検証す
る。

【０３６６】図４４に示す例では、属性証明書（ＡＣ）
は、アプリケーションＩＤ：０００２属性証明書（ＡＣ）シリアル：３２７８コンテンツ利用制限回数：１０の各データが記録され、ユーザ入力データは、ユーザＩＤ：６７３７サービスプロバイダＩＤ：５６７８である。

【０３６７】セキュリティチップの制御部は、これらの
データに対応するコンテンツ利用回数管理データがＲＡ
Ｍに展開した回数管理ファイルに登録済みであるか否か
を検証する。図４４に示す最上段のＳＣ内ＲＡＭのデー
タ中には、サービスプロバイダＩＤ：５６７８、ユーザ
ＩＤ：６７３７に対応するコンテンツ利用回数管理デー
タとして、アプリケーションＩＤ：０００２、属性証明
書（ＡＣ）シリアル：３２７８に対応するデータが存在
し、利用可能回数（残回数）：７と設定されている。

【０３６８】（５）セキュリティチップ制御部は、この
抽出データから利用可能回数（残回数）：７＞０である
こと、さらに、属性証明書に記録された制限回数以下、
１０≧７であることを確認し、これらが確認されたこと
を条件としてコンテンツの利用を許可、すなわち、属性
証明書に格納された（６）暗号化コンテンツ鍵の復号化
処理を実行する。

【０３６９】（７）さらに、セキュリティチップ制御部
は、ＲＡＭに展開した回数管理ファイルの対応データの
利用可能回数を１減少させるデータ更新処理を実行す
る。この場合は、アプリケーションＩＤ：０００２、属
性証明書（ＡＣ）シリアル：３２７８に対応するデータ
中の、利用可能回数（残回数）：７を６に更新する処理
を実行する。

【０３７０】さらに、セキュリティチップ制御部は、
（８）更新データに基づく新たなハッシュ値を計算し
て、（９）セキュリティチップ内の対応するサービスプ
ロバイダ（ＳＰ）管理領域内に格納された対応するフィ
ールドに格納する。図４４の例では、更新前のアプリケ
ーションＩＤ：０００２、属性証明書（ＡＣ）シリア
ル：３２７８に対応するフィールドデータに基づくハッ
シュ値は８７３１であり、更新後の同フィールドのデー
タに基づくハッシュ値はｂｃ３５となり、サービスプロ
バイダＩＤ：５６７８、ユーザＩＤ：６７３７に対応す
る図の最下段のＳＰ管理領域のハッシュ値：ｂｃ３５が
更新ハッシュ値として格納されることになる。

【０３７１】（１０）更新処理の終了後、更新した回数
管理ファイルを、ユーザデバイス制御部に送信し、ユー
ザデバイス制御部は、受信した回数管理ファイルをハー
ドデイスクに格納する。

【０３７２】このように、コンテンツの利用時には、こ
のコンテンツ利用回数管理データが参照され、利用毎に
利用可能回数を１デクリメントして、５→４→３→２→
１→０とするデータ更新が実行されるとともに、更新デ
ータに基づいて新たなハッシュ値が算出されて、更新処
理が実行され、属性証明書に記録された利用制限回数内
でのコンテンツ利用が可能となる。

【０３７３】以上、属性証明書のコンテンツ利用条件に
従ったコンテンツの利用について説明した。なお、上記
説明においては、期間制限と回数制限とを別々に説明し
たが、期間制限と回数制限の両制限を持つ属性証明書も
可能であり、これらの場合は２つの条件に基づいてコン
テンツ利用可否を判定した上で、属性証明書に設定され
た利用条件内の期限内、回数内のコンテンツ利用である
ことの確認を条件として、コンテンツ鍵の復号を行なう
ものとする。

【０３７４】［アップグレード処理］属性証明書には、
コンテンツの利用条件として期間制限、回数制限、買い
切り等の各種利用条件が設定され、これらの利用条件に
基づいてセキュリティチップを持つユーザデバイスにお
いてコンテンツの利用が行なわれることを説明した。次
に、例えば属性証明書に設定されたコンテンツ利用制限
回数の変更、あるいは期間制限の延長など、コンテンツ
の利用制限を変更する処理、すなわちアップグレード処
理について説明する。

【０３７５】アップグレード処理には、具体的には、以
下に説明する各種の態様がある。（１）利用回数制限をコンテンツ利用条件として記録し
た属性証明書の利用可能回数を増やす。例えば、１０回
券を買って、５回残っていて、１０回に増やす。１０回
券を買って、使い切って、１０回券に増やす。（２）利用期間制限をコンテンツ利用条件として記録し
た属性証明書の利用期間を延長する。例えば、１週間後
までしか使えないものを、１ヶ月後まで使えるように期
間を延長する。期間が切れて使えなくなったものを、１
ヶ月後まで使えるように期間を延長する。（３）回数制限や期間制限をコンテンツ利用条件として
記録した属性証明書の利用条件の変更。例えば、回数制
限を期間制限に変更する。期間制限を回数制限に変更す
る。回数制限を買い切りに変更する。期間制限を買い切
りに変更する。（４）アルバム化アップグレード一連のアルバム化されたコンテンツデータ、例えば１枚
のＣＤあるいはＤＶＤ等に格納された複数（ｎ）のコン
テンツ１〜ｎ、あるいは何らかのシリーズ化されたコン
テンツ１〜ｎがあり、これらのいくつかを購入済であ
り、購入済みコンテンツに対応する属性証明書１〜属性
証明書ｎの複数をユーザがユーザデバイス内に保持して
いる場合、例えば、コンテンツ１に対応する属性証明書
１、コンテンツ３に対応する属性証明書３、コンテンツ
５に対応する属性証明書５、をユーザデバイスに保持し
ている場合、これらの属性証明書をサービスプロバイダ
に提示することにより、アルバムを構成する他のコンテ
ンツ、すなわち、コンテンツ２，４，６〜ｎのコンテン
ツを割引価格で一括（アルバム）購入できる。

【０３７６】属性証明書に基づくアップグレード処理に
は、上述した様々な態様がある。このアップグレード処
理の実行シーケンスの概略は、次の通りである。まず、
サービスプロバイダ（ＳＰ）がアップグレードメニュー
をユーザデバイスに提示し、ユーザがアップグレードメ
ニューを選択する。ユーザデバイスは、ユーザの指定に
従って、アップグレード処理対象とする取得済みの属性
証明書の指定データとともに、アップグレード要求コマ
ンドをセキュリティチップに送信する。セキュリティチ
ップの制御部は、サービスプロバイダとの通信を実行し
て、アップグレード処理対象とする取得済みの属性証明
書をサービスプロバイダに送信する。サービスプロバイ
ダは、受信した属性証明書を検証した後、ユーザの指定
したアップグレード処理を実行し、新たな属性証明書を
発行しセキュリティチップに送信する。ユーザデバイス
では、新たな属性証明書の利用条件に従ってコンテンツ
を利用することが可能となる。

【０３７７】以下、アップグレードのベースとして用い
る属性証明書（ＡＣ）に記載されたコンテンツ利用条件
が以下の３態様である場合のアップグレード処理につい
て、順次、説明する。（Ａ）オンライン−利用期間制限コンテンツ（Ｂ）オンライン−利用回数制限コンテンツ（Ｃ）オフライン−利用回数制限コンテンツ

【０３７８】（Ａ）オンライン−利用期間制限属性証明
書（ＡＣ）をベースとしたアップグレード処理まず、属性証明書に記録されたコンテンツ利用条件がオ
ンライン処理であり、利用期間制限が設定された属性証
明書を保有する場合、このオンライン−利用期間制限属
性証明書をベースとしたアップグレード処理を図４５の
シーケンス図に従って説明する。図４５には、左からユ
ーザデバイス内のセキュリティチップ制御部、ユーザデ
バイス制御部（上位ソフトウェア）、およびサービスプ
ロバイダの処理を示している。

【０３７９】図４５では、最上段（ａ）は、属性証明書
がセキュリティチップの内部メモリに格納されている場
合における属性証明書からのサービスプロバイダＩＤ取
得処理、（ｂ）は、属性証明書がセキュリティチップの
外部メモリ、すなわちユーザデバイス制御部単独の制御
でアクセス可能なメモリに格納されている場合における
属性証明書からのサービスプロバイダＩＤ取得処理を示
し、これら（ａ），（ｂ）は属性証明書の格納位置に応
じて選択的に実行する。（ｃ）の相互認証処理、（ｄ）
のコンテンツ取得処理は共通に実行される。

【０３８０】まず、（ａ）の処理から説明する。（ａ
１）ユーザデバイス制御部は、アップグレード処理対象
の属性証明書の検索をセキュリティチップ制御部に要求
する。（ａ２）セキュリティチップ制御部は、チップの
メモリに格納済みの属性証明書のリストをユーザデバイ
ス制御部に出力し、（ａ３）ユーザデバイスでは付属の
ブラウザによりリストを表示する。（ａ４）ユーザは表
示されたリストからアップグレード処理対象の属性証明
書（ＡＣ）を指定し、読み出し命令をセキュリティチッ
プ制御部に送信する。（ａ５）セキュリティチップ制御
部は、指定された属性証明書を内部メモリから読み出し
てユーザデバイス制御部に出力し、（ａ６）ユーザデバ
イスでは付属のブラウザにより属性証明書を表示し、属
性証明書格納データ中のサービスプロバイダ識別子（Ｓ
ＰＩＤ）を取得する。

【０３８１】属性証明書がセキュリティチップの外部メ
モリ、すなわちユーザデバイス制御部単独の制御でアク
セス可能なメモリに格納されている場合は、（ｂ）の処
理となる。（ｂ１）ユーザデバイス制御部は、アップグ
レード処理対象の属性証明書の検索を実行し、（ｂ２）
ユーザデバイスでは付属のブラウザにより表示されたＡ
Ｃリストからアップグレード処理対象の属性証明書（Ａ
Ｃ）を指定し、読み出して属性証明書を表示し、（ｂ
４）属性証明書格納データ中のサービスプロバイダ識別
子（ＳＰＩＤ）を取得する。

【０３８２】上記（ａ）、（ｂ）のいずれかの処理によ
って取得されたサービスプロバイダ識別子（ＳＰＩ
Ｄ）は、サービスプロバイダ管理領域から、相互認証に
必要な情報を取得するために用いられる。前述したよう
に、サービスプロバイダ管理領域へのアクセスにはサー
ビスプロバイダ毎に設定されたパスワード入力が必要で
あり、ユーザは、属性証明書から取得したサービスプロ
バイダ識別子（ＳＰＩＤ）に対応するパスワード入力
により、サービスプロバイダ管理領域へのアクセスを実
行し、図４５の（ｃ１）に示すセキュリティチップとサ
ービスプロバイダ間の相互認証処理を実行する。

【０３８３】この相互認証処理は、先に説明した図１６
のＴＬＳ１．０処理または、その他の方式、例えば公開
鍵方式による相互認証処理として実行される。この相互
認証処理においては、相互の公開鍵証明書の検証がなさ
れ、必要に応じてルート認証局（ＣＡ）までの公開鍵証
明書が連鎖的に検証される。この認証処理において、セ
キュリティチップと、サービスプロバイダはセッション
鍵（Ｋｓｅｓ）を共有する。相互認証が成立すると、次
に、図４５（ｄ）に示す処理、すなわちアップグレード
属性証明書取得処理を実行する。

【０３８４】（ｄ１）ユーザは、ユーザデバイスの付属
のブラウザにより表示された属性証明書の権限情報（コ
ンテンツ利用条件）を確認し、属性証明書のアップグレ
ード適用要求と、アップグレード条件をセキュリティチ
ップに対して出力する。この例におけるアップグレード
処理対象の属性証明書に記録されたコンテンツ利用条件
は、オンライン期間制限であり、ユーザの指定するアッ
プグレード条件は、例えば、期間制限の変更（延長）期間制限→オンライン回数制限へ変更期間制限→オフライン回数制限へ変更期間制限→買い切りへ変更等の条件である。

【０３８５】（ｄ２）セキュリティチップ制御部は、ユ
ーザデバイス制御部からの属性証明書（ＡＣ）アップグ
レード適用要求を受信すると、属性証明書の検証処理を
実行する。検証処理には、権限情報（コンテンツ利用条
件）の確認、フォーマット確認、署名検証処理が含まれ
る。署名検証処理は、例えば先に説明した図２０の処理
フローと同様のシーケンスに従って実行される。

【０３８６】さらに、必要に応じてセキュリティチップ
の制御部は、属性証明書（ＡＣ）内のＡＣ保持者の公開
鍵証明書情報に従ってリンクする公開鍵証明書を取得し
て、公開鍵証明書の検証を行なうことが好ましい。例え
ば属性証明書（ＡＣ）の発行者の信頼度が不確かである
場合には、属性証明書（ＡＣ）の発行者の公開鍵証明書
の検証を行なうことによって、認証局の公開鍵証明書を
正当に有しているか否かの判定が可能となる。なお、公
開鍵証明書が前述したように階層構成をなしている場合
は、経路を上位に辿って連鎖的な検証を行ない、ルート
認証局（ＣＡ）の発行した公開鍵証明書の検証まで実行
することが好ましい。なお、この連鎖検証が必須の場合
もある。

【０３８７】（ｄ３）属性証明書の検証により、属性証
明書の改竄なしの判定が得られると、セキュリティチッ
プの制御部は、サービスプロバイダに対してアップグレ
ード処理対象の属性証明書を、ユーザにより指定された
アップグレード条件情報とともに送付する。アップグレ
ード処理対象の属性証明書には、利用条件としてオンラ
イン期間制限コンテンツであることが記録され、また有
効期限データが格納されている。さらに、サービスプロ
バイダの保有する秘密鍵：ＳＰ．Ｓｔｏ．Ｋで暗号化さ
れたコンテンツ鍵のデータ、すなわち、［ＳＰ．Ｓｔ
ｏ．Ｋ（Ｋｃ）］が格納されている。

【０３８８】（ｄ４）セキュリティチップから属性証明
書を受信したサービスプロバイダは、属性証明書の署名
検証処理を実行する。また、この際、属性証明書にリン
クする公開鍵証明書、およびその上位公開鍵証明書を連
鎖的に検証することが好ましい。なお、この連鎖検証が
必須の場合もある。これらの検証処理により、属性証明
書の正当性が確認されると、（ｄ５）ユーザにより指定
されたアップグレード条件情報に基づくアップグレード
属性証明書生成処理を実行する。

【０３８９】アップグレード属性証明書生成処理は、ユ
ーザにより指定されたコンテンツ利用条件を記録した新
たな属性証明書、すなわちセキュリティチップから受信
した属性証明書と異なるシリアル番号を持つ属性証明書
を発行する処理として実行する。なお、この際、新たに
発行するアップグレード属性証明書中には、アップグレ
ードのベースとなった属性証明書のシリアルを含む履歴
データを格納する。

【０３９０】なお、アップグレードの態様は、前述した
ように、期間制限の変更（延長）期間制限→オンライン回数制限へ変更期間制限→オフライン回数制限へ変更期間制限→買い切りへ変更のいずれかであり、期間制限の変更の場合は、利用期間
を新たに設定したアップグレード属性証明書を生成す
る。また、オンラインまたはオフライン回数制限へ変更
する場合は、利用制限回数を格納したアップグレード属
性証明書を生成する。また、買い切りへ変更する場合
は、コンテンツ利用条件を買い切りとしたアップグレー
ド属性証明書を生成する。

【０３９１】期間制限の変更、あるいはオンライン回数
制限へ変更する場合は、アップグレード属性証明書に格
納するコンテンツ鍵は、元の属性証明書と同様、サービ
スプロバイダの秘密鍵で暗号化したコンテンツ鍵［Ｓ
Ｐ．Ｓｔｏ．Ｋ（Ｋｃ）］として格納するが、オフライ
ン回数制限へ変更、または買い切りへ変更する場合は、
アップグレード属性証明書には、元の属性証明書とは異
なり、ユーザデバイスのセキュリティチップのサービス
プロバイダ管理領域に格納されたＳＰ対応ストレージ秘
密鍵：ＳＣ．Ｓｔｏｐｒｉ．ＳＰ．Ｋに対応する公開鍵
で暗号化したコンテンツ鍵、すなわち、［ＳＣ．Ｓｔｏ
ｐｕｂ．ＳＰ．Ｋ（Ｋｃ）］を格納する。

【０３９２】なお、オフライン処理とする場合であっ
て、公開鍵方式ではなく、共通鍵方式の適用を行なって
いる場合は、ユーザデバイスのセキュリティチップのサ
ービスプロバイダ管理領域に格納されたＳＰ対応ストレ
ージ鍵（共通鍵）によって暗号化したコンテンツ鍵を格
納する。なお、サービスプロバイダがこの共通鍵を保有
していない場合は、図４５のステップ（ｄ３）のセキュ
リティチップからサービスプロバイダへの属性証明書の
送付時に、併せてＳＰ対応ストレージ鍵（共通鍵）を送
付する。この場合は、相互認証時に生成したセッション
鍵で暗号化して送付する。

【０３９３】サービスプロバイダは、アップグレード属
性証明書を生成すると、これをセキュリティチップに送
付する。

【０３９４】（ｄ６）セキュリティチップ制御部は、サ
ービスプロバイダからのアップグレード属性証明書（Ａ
Ｃ）を受信すると、属性証明書の検証処理を実行する。
検証処理には、格納された権限情報（コンテンツ利用条
件）が指定条件と一致するかの確認、フォーマット確
認、署名検証処理が含まれる。署名検証処理は、例えば
先に説明した図２０の処理フローと同様のシーケンスに
従って実行される。さらに、必要に応じてセキュリティ
チップの制御部は、属性証明書（ＡＣ）内のＡＣ保持者
の公開鍵証明書情報に従って、公開鍵証明書の連鎖検証
を行なうことが好ましい。なお、この連鎖検証が必須の
場合もある。

【０３９５】（ｄ７）属性証明書の検証により、属性証
明書の改竄なしの判定が得られると、セキュリティチッ
プの制御部は、サービスプロバイダに対してアップグレ
ード属性証明書受信確認を送信し、（ｄ８）アップグレ
ード属性証明書をメモリに格納する。

【０３９６】さらに、セキュリティチップの制御部は、
アップグレード属性証明書がオフライン回数制限である
場合には、コンテンツの利用時までに前述した利用回数
管理データのインポート処理を実行する。利用回数管理
データのインポート処理の詳細は、先に図３７〜図４１
を参照して説明した通りであり、セキュリティチップ内
部に利用可能回数を格納する態様と、外部メモリに利用
可能回数を格納し、セキュリティチップにハッシュ値の
みを格納する態様がある。

【０３９７】以上の処理により、ユーザデバイスは、す
でに保持する属性証明書に基づいて新たなアップクレー
ド属性証明書を取得し、アップクレード属性証明書に従
った利用条件にしたがったコンテンツの利用が可能とな
る。

【０３９８】（Ｂ）オンライン−利用回数制限属性証明
書（ＡＣ）をベースとしたアップグレード処理次に、属性証明書に記録されたコンテンツ利用条件がオ
ンライン処理であり、利用回数制限が設定された属性証
明書を保有する場合、このオンライン−利用回数制限属
性証明書をベースとしたアップグレード処理を図４６の
シーケンス図に従って説明する。図４６には、左からユ
ーザデバイス内のセキュリティチップ制御部、ユーザデ
バイス制御部（上位ソフトウェア）、およびサービスプ
ロバイダの処理を示している。

【０３９９】図４６では、最上段（ａ）は、属性証明書
がセキュリティチップの内部メモリに格納されている場
合における属性証明書からのサービスプロバイダＩＤ取
得処理、（ｂ）は、属性証明書がセキュリティチップの
外部メモリ、すなわちユーザデバイス制御部単独の制御
でアクセス可能なメモリに格納されている場合における
属性証明書からのサービスプロバイダＩＤ取得処理を示
し、（ｃ）はセキュリティチップとサービスプロバイダ
の相互認証処理である。これらの処理は、前述の図４５
の場合と同様であり、説明を省略する。

【０４００】相互認証後成立後の処理から説明する。
（ｄ１）ユーザは、ユーザデバイスの付属のブラウザに
より表示された属性証明書の権限情報（コンテンツ利用
条件）を確認し、属性証明書のアップグレード適用要求
と、アップグレード条件をセキュリティチップに対して
出力する。この例におけるアップグレード処理対象の属
性証明書に記録されたコンテンツ利用条件は、オンライ
ン回数制限であり、ユーザの指定するアップグレード条
件は、例えば、利用可能回数の変更（回数増加）オンライン回数制限→期間制限へ変更オンライン回数制限→オフライン回数制限へ変更オンライン回数制限→買い切りへ変更等の条件である。

【０４０１】（ｄ２）セキュリティチップ制御部は、ユ
ーザデバイス制御部からの属性証明書（ＡＣ）アップグ
レード適用要求を受信すると、属性証明書の検証処理を
実行する。検証処理には、権限情報（コンテンツ利用条
件）の確認、フォーマット確認、署名検証処理が含まれ
る。署名検証処理は、例えば先に説明した図２０の処理
フローと同様のシーケンスに従って実行される。さら
に、必要に応じてセキュリティチップの制御部は、属性
証明書（ＡＣ）内のＡＣ保持者の公開鍵証明書、さら
に、連鎖公開鍵証明書の検証を行ない、ルート認証局
（ＣＡ）の発行した公開鍵証明書の検証まで実行するこ
とが好ましい。なお、この連鎖検証が必須の場合もあ
る。

【０４０２】（ｄ３）属性証明書の検証により、属性証
明書の改竄なしの判定が得られると、セキュリティチッ
プの制御部は、サービスプロバイダに対してアップグレ
ード処理対象の属性証明書を、ユーザにより指定された
アップグレード条件情報とともに送付する。アップグレ
ード処理対象の属性証明書には、利用条件としてオンラ
イン回数制限コンテンツであることが記録され、また利
用制限回数が格納されている。さらに、サービスプロバ
イダの保有する秘密鍵：ＳＰ．Ｓｔｏ．Ｋで暗号化され
たコンテンツ鍵のデータ、すなわち、［ＳＰ．Ｓｔｏ．
Ｋ（Ｋｃ）］が格納されている。

【０４０３】（ｄ４）セキュリティチップから属性証明
書を受信したサービスプロバイダは、属性証明書の署名
検証処理を実行する。また、この際、属性証明書にリン
クする公開鍵証明書、およびその上位公開鍵証明書を連
鎖的に検証することが好ましい。なお、この連鎖検証が
必須の場合もある。これらの検証処理により、属性証明
書の正当性が確認されると、（ｄ５）ユーザにより指定
されたアップグレード条件情報に基づくアップグレード
属性証明書生成処理を実行する。

【０４０４】アップグレード属性証明書生成処理は、ユ
ーザにより指定されたコンテンツ利用条件を記録した新
たな属性証明書、すなわちセキュリティチップから受信
した属性証明書と異なるシリアル番号を持つ属性証明書
を発行する処理として実行する。なお、この際、新たに
発行するアップグレード属性証明書中には、アップグレ
ードのベースとなった属性証明書のシリアルを含む履歴
データを格納する。

【０４０５】なお、アップグレードの態様は、前述した
ように、利用制限回数の変更（回数増加）オンライン回数制限→期間制限へ変更オンライン回数制限→オフライン回数制限へ変更オンライン回数制限→買い切りへ変更のいずれかであり、回数制限の変更の場合は、利用制限
回数を新たに設定したアップグレード属性証明書を生成
する。また、期間制限へ変更する場合は、期間制限情報
を格納したアップグレード属性証明書を生成する。

【０４０６】オンライン回数制限として利用制限回数を
変更する場合、期間制限へ変更する場合は、アップグレ
ード属性証明書に格納するコンテンツ鍵は、元の属性証
明書と同様、サービスプロバイダの秘密鍵で暗号化した
コンテンツ鍵［ＳＰ．Ｓｔｏ．Ｋ（Ｋｃ）］として格納
するが、オフライン回数制限へ変更、または買い切りへ
変更する場合は、アップグレード属性証明書には、元の
属性証明書とは異なり、ユーザデバイスのセキュリティ
チップのサービスプロバイダ管理領域に格納されたＳＰ
対応ストレージ秘密鍵：ＳＣ．Ｓｔｏｐｒｉ．ＳＰ．Ｋ
に対応する公開鍵で暗号化したコンテンツ鍵、すなわ
ち、［ＳＣ．Ｓｔｏｐｕｂ．ＳＰ．Ｋ（Ｋｃ）］を格納
する。

【０４０７】なお、オフライン処理とする場合であっ
て、公開鍵方式ではなく、共通鍵方式の適用を行なって
いる場合は、ユーザデバイスのセキュリティチップのサ
ービスプロバイダ管理領域に格納されたＳＰ対応ストレ
ージ鍵（共通鍵）によって暗号化したコンテンツ鍵を格
納する。なお、サービスプロバイダがこの共通鍵を保有
していない場合は、図４６のステップ（ｄ３）のセキュ
リティチップからサービスプロバイダへの属性証明書の
送付時に、併せてＳＰ対応ストレージ鍵（共通鍵）を送
付する。この場合は、相互認証時に生成したセッション
鍵で暗号化して送付する。

【０４０８】サービスプロバイダは、アップグレード属
性証明書を生成すると、これをセキュリティチップに送
付する。

【０４０９】（ｄ６）セキュリティチップ制御部は、サ
ービスプロバイダからのアップグレード属性証明書（Ａ
Ｃ）を受信すると、属性証明書の検証処理を実行する。
検証処理には、格納された権限情報（コンテンツ利用条
件）が指定条件と一致するかの確認、フォーマット確
認、署名検証処理が含まれる。署名検証処理は、例えば
先に説明した図２０の処理フローと同様のシーケンスに
従って実行される。さらに、必要に応じてセキュリティ
チップの制御部は、属性証明書（ＡＣ）内のＡＣ保持者
の公開鍵証明書情報に従って、公開鍵証明書の連鎖検証
を行なうことが好ましい。なお、この連鎖検証が必須の
場合もある。

【０４１０】（ｄ７）属性証明書の検証により、属性証
明書の改竄なしの判定が得られると、セキュリティチッ
プの制御部は、サービスプロバイダに対してアップグレ
ード属性証明書受信確認を送信し、（ｄ８）アップグレ
ード属性証明書をメモリに格納する。

【０４１１】さらに、セキュリティチップの制御部は、
アップグレード属性証明書がオフライン回数制限である
場合には、コンテンツの利用時までに前述した利用回数
管理データのインポート処理を実行する。利用回数管理
データインポート処理の詳細は、先に図３７〜図４１を
参照して説明した通りであり、セキュリティチップ内部
に利用可能回数を格納する態様と、外部メモリに利用可
能回数を格納し、セキュリティチップにハッシュ値のみ
を格納する態様がある。

【０４１２】以上の処理により、ユーザデバイスは、す
でに保持する属性証明書に基づいて新たなアップクレー
ド属性証明書を取得し、アップクレード属性証明書に従
った利用条件にしたがったコンテンツの利用が可能とな
る。

【０４１３】（Ｃ）オフライン−利用回数制限属性証明
書（ＡＣ）をベースとしたアップグレード処理次に、属性証明書に記録されたコンテンツ利用条件がオ
フライン処理であり、利用回数制限が設定された属性証
明書を保有する場合、このオフライン−利用回数制限属
性証明書をベースとしたアップグレード処理を図４７の
シーケンス図に従って説明する。図４７には、左からユ
ーザデバイス内のセキュリティチップ制御部、ユーザデ
バイス制御部（上位ソフトウェア）、およびサービスプ
ロバイダの処理を示している。

【０４１４】図４７では、最上段（ａ）は、属性証明書
がセキュリティチップの内部メモリに格納されている場
合における属性証明書からのサービスプロバイダＩＤ取
得処理、（ｂ）は、属性証明書がセキュリティチップの
外部メモリ、すなわちユーザデバイス制御部単独の制御
でアクセス可能なメモリに格納されている場合における
属性証明書からのサービスプロバイダＩＤ取得処理を示
し、（ｃ）はセキュリティチップとサービスプロバイダ
の相互認証処理である。これらの処理は、前述の図４５
の場合と同様であり、説明を省略する。

【０４１５】相互認証後成立後の処理から説明する。
（ｄ１）ユーザは、ユーザデバイスの付属のブラウザに
より表示された属性証明書の権限情報（コンテンツ利用
条件）を確認し、属性証明書のアップグレード適用要求
と、アップグレード条件をセキュリティチップに対して
出力する。この例におけるアップグレード処理対象の属
性証明書に記録されたコンテンツ利用条件は、オフライ
ン回数制限であり、ユーザの指定するアップグレード条
件は、例えば、利用可能回数の変更（回数増加）オフライン回数制限→期間制限へ変更オフライン回数制限→オンライン回数制限へ変更オフライン回数制限→買い切りへ変更等の条件である。

【０４１６】（ｄ２）セキュリティチップ制御部は、ユ
ーザデバイス制御部からの属性証明書（ＡＣ）アップグ
レード適用要求を受信すると、属性証明書の検証処理を
実行する。検証処理には、権限情報（コンテンツ利用条
件）の確認、フォーマット確認、署名検証処理が含まれ
る。署名検証処理は、例えば先に説明した図２０の処理
フローと同様のシーケンスに従って実行される。さら
に、必要に応じてセキュリティチップの制御部は、属性
証明書（ＡＣ）内のＡＣ保持者の公開鍵証明書、さら
に、連鎖公開鍵証明書の検証を行ない、ルート認証局
（ＣＡ）の発行した公開鍵証明書の検証まで実行するこ
とが好ましい。なお、この連鎖検証が必須の場合もあ
る。

【０４１７】（ｄ３）属性証明書の検証により、属性証
明書の改竄なしの判定が得られると、セキュリティチッ
プの制御部は、サービスプロバイダに対してアップグレ
ード処理対象の属性証明書を、ユーザにより指定された
アップグレード条件情報とともに送付する。アップグレ
ード処理対象の属性証明書には、利用条件としてオフラ
イン回数制限コンテンツであることが記録され、また利
用制限回数が格納されている。さらに、ユーザデバイス
のセキュリティチップのサービスプロバイダ管理領域に
格納されたＳＰ対応ストレージ秘密鍵：ＳＣ．Ｓｔｏｐ
ｒｉ．ＳＰ．Ｋに対応する公開鍵で暗号化したコンテン
ツ鍵、すなわち、［ＳＣ．Ｓｔｏｐｕｂ．ＳＰ．Ｋ（Ｋ
ｃ）］が格納されている。

【０４１８】（ｄ４）セキュリティチップから属性証明
書を受信したサービスプロバイダは、属性証明書の署名
検証処理を実行する。また、この際、属性証明書にリン
クする公開鍵証明書、およびその上位公開鍵証明書を連
鎖的に検証することが好ましい。なお、この連鎖検証が
必須の場合もある。これらの検証処理により、属性証明
書の正当性が確認されると、（ｄ５）ユーザにより指定
されたアップグレード条件情報に基づくアップグレード
属性証明書生成処理を実行する。

【０４１９】アップグレード属性証明書生成処理は、ユ
ーザにより指定されたコンテンツ利用条件を記録した新
たな属性証明書、すなわちセキュリティチップから受信
した属性証明書と異なるシリアル番号を持つ属性証明書
を発行する処理として実行する。なお、この際、新たに
発行するアップグレード属性証明書中には、アップグレ
ードのベースとなった属性証明書のシリアルを含む履歴
データを格納する。

【０４２０】なお、アップグレードの態様は、前述した
ように、利用制限回数の変更（回数増加）オフライン回数制限→期間制限へ変更オフライン回数制限→オンライン回数制限へ変更オフライン回数制限→買い切りへ変更のいずれかであり、回数制限の変更の場合は、利用制限
回数を新たに設定したアップグレード属性証明書を生成
する。また、期間制限へ変更する場合は、期間制限情報
を格納したアップグレード属性証明書を生成する。

【０４２１】オフライン回数制限として利用制限回数を
変更する場合、買い切りへ変更する場合は、アップグレ
ード属性証明書に格納するコンテンツ鍵は、元の属性証
明書と同様、サービスプロバイダ管理領域に格納された
ＳＰ対応ストレージ秘密鍵：ＳＣ．Ｓｔｏｐｒｉ．Ｓ
Ｐ．Ｋに対応する公開鍵で暗号化したコンテンツ鍵、す
なわち、［ＳＣ．Ｓｔｏｐｕｂ．ＳＰ．Ｋ（Ｋｃ）］と
して格納するが、期間制限へ変更、またはオンライン回
数制限へ変更する場合は、元の属性証明書とは異なり、
アップグレード属性証明書に格納するコンテンツ鍵は、
サービスプロバイダの秘密鍵で暗号化したコンテンツ鍵
［ＳＰ．Ｓｔｏ．Ｋ（Ｋｃ）］とする。

【０４２２】なお、オフライン処理とする場合であっ
て、公開鍵方式ではなく、共通鍵方式の適用を行なって
いる場合は、ユーザデバイスのセキュリティチップのサ
ービスプロバイダ管理領域に格納されたＳＰ対応ストレ
ージ鍵（共通鍵）によって暗号化したコンテンツ鍵を格
納する。なお、サービスプロバイダがこの共通鍵を保有
していない場合は、図４７のステップ（ｄ３）のセキュ
リティチップからサービスプロバイダへの属性証明書の
送付時に、併せてＳＰ対応ストレージ鍵（共通鍵）を送
付する。この場合は、相互認証時に生成したセッション
鍵で暗号化して送付する。

【０４２３】サービスプロバイダは、アップグレード属
性証明書を生成すると、これをセキュリティチップに送
付する。

【０４２４】（ｄ６）セキュリティチップ制御部は、サ
ービスプロバイダからのアップグレード属性証明書（Ａ
Ｃ）を受信すると、属性証明書の検証処理を実行する。
検証処理には、格納された権限情報（コンテンツ利用条
件）が指定条件と一致するかの確認、フォーマット確
認、署名検証処理が含まれる。署名検証処理は、例えば
先に説明した図２０の処理フローと同様のシーケンスに
従って実行される。さらに、必要に応じてセキュリティ
チップの制御部は、属性証明書（ＡＣ）内のＡＣ保持者
の公開鍵証明書情報に従って、公開鍵証明書の連鎖検証
を行なうことが好ましい。なお、この連鎖検証が必須の
場合もある。

【０４２５】（ｄ７）属性証明書の検証により、属性証
明書の改竄なしの判定が得られると、セキュリティチッ
プの制御部は、サービスプロバイダに対してアップグレ
ード属性証明書受信確認を送信し、（ｄ８）アップグレ
ード属性証明書をメモリに格納する。

【０４２６】さらに、セキュリティチップの制御部は、
アップグレード属性証明書がオフライン回数制限である
場合には、コンテンツの利用時までに前述した利用回数
管理データのインポート処理を実行する。利用回数管理
データインポート処理の詳細は、先に図３７〜図４１を
参照して説明した通りであり、セキュリティチップ内部
に利用可能回数を格納する態様と、外部メモリに利用可
能回数を格納し、セキュリティチップにハッシュ値のみ
を格納する態様がある。

【０４２７】以上の処理により、ユーザデバイスは、す
でに保持する属性証明書に基づいて新たなアップクレー
ド属性証明書を取得し、アップクレード属性証明書に従
った利用条件にしたがったコンテンツの利用が可能とな
る。

【０４２８】（Ｄ）アルバム購入型アップグレード次に、一連のアルバム化されたコンテンツデータ、例え
ば１枚のＣＤあるいはＤＶＤ等に格納された複数（ｎ）
のコンテンツ１〜ｎ、あるいは何らかのシリーズ化され
たコンテンツ１〜ｎがあり、これらのいくつかを購入済
であり、購入済みコンテンツに対応する属性証明書１〜
属性証明書ｎの複数をユーザがユーザデバイス内に保持
している場合、これらの属性証明書をサービスプロバイ
ダに提示することにより、アルバムを構成する他のコン
テンツ、すなわち、コンテンツ２，４，６〜ｎのコンテ
ンツを割引価格で一括（アルバム）購入する処理とした
アップグレード処理について、図４８を参照して説明す
る。

【０４２９】図４８は、左からユーザデバイス内のセキ
ュリティチップ制御部、ユーザデバイス制御部（上位ソ
フトウェア）、およびサービスプロバイダの処理を示し
ている。最上段（ａ）は、属性証明書がセキュリティチ
ップの内部メモリに格納されている場合における属性証
明書からのサービスプロバイダＩＤ取得処理、（ｂ）
は、属性証明書がセキュリティチップの外部メモリ、す
なわちユーザデバイス制御部単独の制御でアクセス可能
なメモリに格納されている場合における属性証明書から
のサービスプロバイダＩＤ取得処理を示し、（ｃ）はセ
キュリティチップとサービスプロバイダの相互認証処理
である。これらの処理は、前述の図４５の場合と同様で
あり、説明を省略する。

【０４３０】相互認証後成立後の処理から説明する。
（ｄ１）ユーザは、ユーザデバイスの付属のブラウザに
より表示された属性証明書の権限情報（コンテンツ利用
条件）を確認し、属性証明書のアップグレード適用要求
と、アップグレード条件をセキュリティチップに対して
出力する。この例におけるアップグレード処理対象の属
性証明書は、ある複数のコンテンツの集合対として識別
されるアルバムを構成する一部のコンテンツに対応する
１以上の属性証明書である。ユーザの指定するアップグ
レード条件は、例えば、アルバムを構成する他の一部コンテンツの購入アルバムを構成する他の全コンテンツの購入等の条件である。

【０４３１】（ｄ２）セキュリティチップ制御部は、ユ
ーザデバイス制御部からの属性証明書（ＡＣ）アップグ
レード適用要求を受信すると、属性証明書の検証処理を
実行する。検証処理には、権限情報（コンテンツ利用条
件）の確認、フォーマット確認、署名検証処理が含まれ
る。署名検証処理は、例えば先に説明した図２０の処理
フローと同様のシーケンスに従って実行される。さら
に、必要に応じてセキュリティチップの制御部は、属性
証明書（ＡＣ）内のＡＣ保持者の公開鍵証明書、さら
に、連鎖公開鍵証明書の検証を行ない、ルート認証局
（ＣＡ）の発行した公開鍵証明書の検証まで実行するこ
とが好ましい。なお、この連鎖検証が必須の場合もあ
る。

【０４３２】（ｄ３）属性証明書の検証により、属性証
明書の改竄なしの判定が得られると、セキュリティチッ
プの制御部は、サービスプロバイダに対してアップグレ
ード処理対象の属性証明書を、ユーザにより指定された
アップグレード条件情報とともに送付する。

【０４３３】（ｄ４）セキュリティチップから属性証明
書を受信したサービスプロバイダは、属性証明書の署名
検証処理を実行する。また、この際、属性証明書にリン
クする公開鍵証明書、およびその上位公開鍵証明書を連
鎖的に検証することが好ましい。なお、この連鎖検証が
必須の場合もある。これらの検証処理により、属性証明
書の正当性が確認されると、（ｄ５）ユーザにより指定
されたアップグレード条件情報に基づくアップグレード
属性証明書生成処理を実行する。

【０４３４】アップグレード属性証明書生成処理は、ユ
ーザにより指定されたコンテンツ利用条件を記録した新
たな属性証明書、すなわちセキュリティチップから受信
した属性証明書と異なるシリアル番号を持つ属性証明書
を発行する処理として実行する。なお、この際、新たに
発行するアップグレード属性証明書中には、アップグレ
ードのベースとなった属性証明書のシリアルを含む履歴
データを格納する。

【０４３５】なお、アップグレードの態様は、前述した
ように、アルバムを構成する他の一部コンテンツの購入アルバムを構成する他の全コンテンツの購入のいずれかであり、アルバムを構成する他の一部コンテ
ンツの購入の場合は、購入指定の一部コンテンツに対応
するアップグレード属性証明書を生成する。また、アル
バムを構成する他の全コンテンツの購入の場合は、アル
バムを構成する他の全コンテンツに対応するアップグレ
ード属性証明書を生成する。

【０４３６】なお、この場合の利用条件は、ユーザが予
め指定することも可能であり、また、サービスプロバイ
ダが決定する構成としてもよい。ユーザが指定する場合
は、図４８のステップ（ｄ１）において指定し、（ｄ
３）のセキュリティチップからサービスプロバイダへの
属性証明書の送付時に、指定条件を併せて送付する。

【０４３７】サービスプロバイダは、オフライン利用と
するアップグレード属性証明書を生成する場合は、サー
ビスプロバイダ管理領域に格納されたＳＰ対応ストレー
ジ秘密鍵：ＳＣ．Ｓｔｏｐｒｉ．ＳＰ．Ｋに対応する公
開鍵で暗号化したコンテンツ鍵［ＳＣ．Ｓｔｏｐｕｂ．
ＳＰ．Ｋ（Ｋｃ）］を格納し、オンライン利用とするア
ップグレード属性証明書を生成する場合は、アップグレ
ード属性証明書に格納するコンテンツ鍵は、サービスプ
ロバイダの秘密鍵で暗号化したコンテンツ鍵［ＳＰ．Ｓ
ｔｏ．Ｋ（Ｋｃ）］とする。

【０４３８】なお、オフライン処理とする場合であっ
て、公開鍵方式ではなく、共通鍵方式の適用を行なって
いる場合は、ユーザデバイスのセキュリティチップのサ
ービスプロバイダ管理領域に格納されたＳＰ対応ストレ
ージ鍵（共通鍵）によって暗号化したコンテンツ鍵を格
納する。なお、サービスプロバイダがこの共通鍵を保有
していない場合は、図４８のステップ（ｄ３）のセキュ
リティチップからサービスプロバイダへの属性証明書の
送付時に、併せてＳＰ対応ストレージ鍵（共通鍵）を送
付する。この場合は、相互認証時に生成したセッション
鍵で暗号化して送付する。

【０４３９】サービスプロバイダは、アップグレード属
性証明書を生成すると、これをセキュリティチップに送
付する。

【０４４０】（ｄ６）セキュリティチップ制御部は、サ
ービスプロバイダからのアップグレード属性証明書（Ａ
Ｃ）を受信すると、属性証明書の検証処理を実行する。
検証処理には、格納された権限情報（コンテンツ利用条
件）が指定条件と一致するかの確認、フォーマット確
認、署名検証処理が含まれる。署名検証処理は、例えば
先に説明した図２０の処理フローと同様のシーケンスに
従って実行される。さらに、必要に応じてセキュリティ
チップの制御部は、属性証明書（ＡＣ）内のＡＣ保持者
の公開鍵証明書情報に従って、公開鍵証明書の連鎖検証
を行なうことが好ましい。なお、この連鎖検証が必須の
場合もある。

【０４４１】（ｄ７）属性証明書の検証により、属性証
明書の改竄なしの判定が得られると、セキュリティチッ
プの制御部は、サービスプロバイダに対してアップグレ
ード属性証明書受信確認を送信し、（ｄ８）アップグレ
ード属性証明書をメモリに格納する。

【０４４２】さらに、セキュリティチップの制御部は、
アップグレード属性証明書がオフライン回数制限である
場合には、コンテンツの利用時までに前述した利用回数
管理データのインポート処理を実行する。利用回数管理
データインポート処理の詳細は、先に図３７〜図４１を
参照して説明した通りであり、セキュリティチップ内部
に利用可能回数を格納する態様と、外部メモリに利用可
能回数を格納し、セキュリティチップにハッシュ値のみ
を格納する態様がある。

【０４４３】以上の処理により、ユーザデバイスは、す
でに保持する属性証明書に基づいて新たなアップクレー
ド属性証明書を取得し、アップクレード属性証明書に従
った利用条件にしたがったコンテンツの利用が可能とな
る。

【０４４４】［データバックアップおよびリストア処
理］ユーザがサービスプロバイダから購入し、セキュリ
ティチップを有するユーザデバイス内の記憶手段に格納
した権利情報や、証明書類は、消失の事態に備えてバッ
クアップしておくことが好ましい。バックアップすべき
情報には、見られてもいい情報と、セキュアに保持しな
ければいけない情報がある。見られてもいい情報とは、
公開鍵証明書、属性証明書などの証明書類である。セキ
ュアに保持する情報とは、例えばセキュリティチップの
サービスプロバイダ管理領域に書き込まれているサービ
ス加入の証拠情報などがある。

【０４４５】公開鍵証明書、属性証明書などの証明書類
については、ユーザが適宜、ハードディスクやフラッシ
ュメモリを搭載したメモリカードなどに複製情報を格納
しておくことで十分である。属性証明書にはコンテンツ
鍵が格納されているが、オンライン利用の場合には、サ
ービスプロバイダとの接続が必要となり、この際の相互
認証時にデバイス（セキュリティチップ）の正当性が確
認されるので、コンテンツが不正に利用されることはな
い。また、オフライン利用の場合でも、コンテンツ鍵を
復号するための鍵は、セキュリティチッブのサービスプ
ロバイダ管理領域に格納されているので、正当なユーザ
デバイスのセキュリティチップを保持し、かつ前述した
パスワードによるアクセスが許可されたユーザのみが暗
号化コンテンツ鍵を復号することが可能となる。従っ
て、属性証明書が第三者に渡ったとしてもコンテンツの
不正利用が発生することはない。

【０４４６】しかし、セキュリティチップ内の秘密情報
に関しては、テンポラリのストレージにセキュアに保持
しておかねばならない。例えばセキュリティチップのサ
ービスプロバイダ管理領域には、サービスプロバイダと
の相互認証に必要なＩＤ情報、鍵情報、パスワード等が
格納されており、これらは第三者に漏洩することを防止
することが必要である。従って外部の記憶媒体（テンポ
ラリのストレージ）にバックアップする際には、これら
のバックアップデータは、暗号化しておくことが必要で
ある。

【０４４７】ユーザが秘密情報をテンポラリのストレー
ジに格納した場合、ストレージメディアの盗難によりデ
ータ漏洩が発生する暗号化では意味がない。また、ユー
ザデバイスから容易に取り出せる鍵によって復号できる
構成とすると、ユーザデバイスから取り出した鍵によっ
て、セキュリティデバイスの複製を生成することが可能
となってしまい、ユーザサイドで全く同様のサービスプ
ロバイダ管理領域データを有する第２のセキュリティデ
バイスを生成することが可能となるおそれがある。ま
た、複製したセキュリティチップを搭載した可搬メディ
アを他のユーザデバイスに装着することで、複数のユー
ザデバイスで全く同様のサービスを受けることが可能と
なってしまう。そこで本発明のシステムでは、テンポラ
リのストレージに秘密情報をバックアップデータとして
格納した場合でも、不正な第三者によって復号できない
態様とするとともに、ユーザデバイスを保持するユーザ
自身もシステムホルダの許可なくリストア等、他のセキ
ュリティチップに格納して使用することのできない構成
とし、データの復号、リストアはサポートセンタにおい
てのみ実行可能とした。

【０４４８】すなわち、ユーザデバイス内で確実な情報
管理を実行し、データ消失を完全に防ぐことの困難性に
鑑み、本発明のシステムにおいては、サポートセンタに
おいて、データのバックアップ・サービスを提供し、必
要に応じてサポートセンタにおいて、バックアップデー
タを用いてデータ復旧、すなわちリストア処理を実行す
る。リストアは、サポートセンターにて行い、テンポラ
リのストレージからデータを読み出し、ユーザデバイス
のセキュリティデバイスに対してインポートする処理と
して実行する。以下、サポートセンタによるデータバッ
クアップ処理、およびリストア処理について説明する。

【０４４９】図４９に、ユーザデバイス内の秘密情報の
バックアップ処理、サポートセンタにおけるリストア処
理の概要を説明する図を示す。

【０４５０】図４９において、ユーザデバイス４１０
は、セキュリティチップ４１１を有し、セキュリティチ
ップには様々なシークレット、すなわち秘密情報が格納
されている。秘密情報は、例えばセキュリティチップの
サービスプロバイダ管理領域の格納情報であり、サービ
スプロバイダとの相互認証に必要なＩＤ情報、鍵情報、
パスワード等である。また、ユーザデバイスのセキュリ
ティチップ外のメモリには、公開鍵証明書、属性証明書
が格納される。

【０４５１】ユーザは、ユーザデバイスの損壊、あるい
はデータの消失等に備え、これらの情報をユーザデバイ
ス以外の外部の記憶媒体にバックアップして保存する。
例えば公開鍵証明書、属性証明書等を外部のＰＣのハー
ドディスクに格納したり、フラッシュメモリを備えたカ
ード型記憶媒体などの外部記憶媒体４２１に格納する。
これらは、前述したように、漏洩により、コンテンツの
不正利用を発生させるおそれがなく、暗号化されること
なく外部の記憶媒体４２１に格納し、必要に応じてユー
ザが記憶媒体４２１からユーザデバイス４１０にリスト
アすることが可能である。

【０４５２】一方、セキュリティチップに格納された秘
密情報は、外部の記憶媒体４２２にバックアップデータ
として保存する場合は、ユーザデバイスにおいて一時的
な鍵として乱数からバックアップ鍵：Ｋｂ（共通鍵系）
を生成し、バックアップ鍵：Ｋｂによって、各種の秘密
情報（ＳｅｃＤａｔａ）を暗号化し、暗号化データ：
［Ｋｂ（ＳｅｃＤａｔａ）］として記憶媒体４２２に格
納する。さらに、生成したバックアップ鍵：Ｋｂをサポ
ートセンタの公開鍵：Ｋｐｓによって暗号化した暗号鍵
データ［Ｋｐｓ（Ｋｂ）］を併せて外部記憶媒体４２２
に格納する。秘密情報を外部の記憶媒体４２２に格納し
た後、バックアップ鍵：Ｋｂはユーザデバイスに保持す
ることなく消去する。

【０４５３】記憶媒体４２２に格納した暗号化データ：
［Ｋｂ（ＳｅｃＤａｔａ）］は、たとえ記憶媒体４２２
が第三者の手に渡ったとしても、その復号のための鍵で
あるバックアップ鍵：Ｋｂが、サポートセンタの公開
鍵：Ｋｐｓによって暗号化されており、バックアップ
鍵：Ｋｂを取得するためには、サポートセンタの秘密
鍵：Ｋｓｓによる復号化処理が必要となるので、第三者
による復号は不可能である。また、ユーザデバイスを保
持する正当なユーザも復号により第２のセキュリティデ
バイスを生成することはできない。

【０４５４】データのリストア（復旧）処理は、ユーザ
サイト側からサポートセンタ４５０に対して記憶媒体４
２２を送付することによって実行される。リストア処理
は、元のユーザデバイスが損壊した場合は、新たなユー
ザデバイス４３０に対して実行される。元のユーザデバ
イス自体をサポートセンタに送付して、修理された元の
ユーザデバイスに対してリストアを実行することも可能
である。なお、新たなユーザデバイスに対するリストア
処理を実行する場合は、元のユーザデバイスを無効化す
る処理、すなわちリボーク処理を併せて実行する。この
リボーク処理は、例えばユーザデバイスに対応して発行
されている公開鍵証明書をリボケーションリストに登録
することによって行われる。リボケーションリストは、
不正デバイス、無効化されたデバイス、ユーザ等に対応
する公開鍵証明書のリストとして構成されるものであ
る。リボケーションリストは、デバイスとの相互認証時
に参照され、リストに記載されたデバイスであると判定
されると認証を不成立として、その後のデータ通信を中
止することを可能としたものである。

【０４５５】サポートセンタ４５０におけるリストア処
理は、まず、ユーザサイトから送付された記憶媒体４２
２’に格納されたサポートセンタの公開鍵：Ｋｐｓによ
って暗号化した暗号鍵データ［Ｋｐｓ（Ｋｂ）］を取り
出して、サポートセンタの秘密鍵：Ｋｓｓによって復号
してバックアップ鍵:Ｋｂを取り出す。その後、取得し
たバックアップ鍵:Ｋｂを適用して、バックアップ鍵に
より暗号化された秘密情報暗号化データ：［Ｋｂ（Ｓｅ
ｃＤａｔａ）］の復号化処理を実行し、復号データ：Ｓ
ｅｃＤａｔａをユーザデバイス４３０のセキュリティチ
ップ内に格納する処理として実行される。具体的なリス
トア処理シーケンスについては、後述する。

【０４５６】上述したように、ユーザデバイス内の秘密
情報のバックアップデータのリストアをサポートセンタ
のみにおいて実行可能とした構成により、秘密情報の複
製利用を防止することが可能となる。

【０４５７】図５０にリストア処理時の手順概要を説明
する図を示す。ユーザサイトでは、ユーザが使用してい
るユーザデバイス４７０内のセキュリティチップに格納
された秘密情報をバックアップストレージメディア４７
１に格納する。前述したように、ユーザデバイスは、バ
ックアップ鍵：Ｋｂ（共通鍵系）を生成し、バックアッ
プ鍵：Ｋｂによって秘密情報（ＳｅｃＤａｔａ）を暗号
化したデータ：［Ｋｂ（ＳｅｃＤａｔａ）］と、バック
アップ鍵：Ｋｂをサポートセンタの公開鍵：Ｋｐｓによ
って暗号化した暗号鍵データ［Ｋｐｓ（Ｋｂ）］をバッ
クアップストレージメディア４７１に格納する。

【０４５８】ユーザデバイス４７０が損壊する等の理由
により、使用できなくなった場合、ユーザは、バックア
ップストレージメディア４７１をサポートセンタ４７５
に送付する。

【０４５９】サポートセンタ４７５は、新規のユーザデ
バイス、あるいは損壊したユーザデバイスを修理した元
のユーザデバイスに対して、バックアップストレージメ
ディア４７１のデータを復号してリストアし、秘密情報
をリストアしたユーザデバイス４７２と、リストアに使
用したバックアップストレージメディア４７１をユーザ
に返却する。サポートセンタ４７５は、このリストア処
理において、新規デバイスに対してリストア処理を実行
し、元のデバイスを使用しない場合には、前述したリボ
ーケーションリストへの登録によるリボーク処理を実行
する。またサポートセンタ４７５は、リストア処理に対
する課金を実行してもよい。

【０４６０】図５１を参照して、ユーザサイトで実行す
るバックアップストレージメディアに対するデータバッ
クアップ処理シーケンスについて説明する。図５１は、
左からバックアップストレージメディア、ユーザデバイ
ス内のセキュリティチップ制御部、ユーザデバイス制御
部（上位ソフトウェア）の処理を示している。まず、
（１）ユーザデバイス制御部は、セキュリティチップ制
御部に対してバックアップ処理要求を送信する。これ
は、ユーザがユーザデバイス側の入力部に対するユーザ
によるバックアップ処理実行指示に基づいて行われる。

【０４６１】セキュリティチップの制御部は、バックア
ップ要求を受信すると、（２）バックアップデータの暗
号化に適用するバックアップ鍵（キー）：Ｋｂを生成す
る。バックアップ鍵（キー）：Ｋｂは例えば乱数生成手
段によって生成した乱数に基づいて生成するバックアッ
プ専用の一時的な鍵であり、バックアップストレージメ
ディアに対するバックアップ処理の後、セキュリティチ
ップに保持されることなく、消去される。

【０４６２】セキュリティチップの制御部は、（３）バ
ックアップ鍵（キー）：Ｋｂの生成後、生成したバック
アップ鍵（キー）で、バックアップデータの暗号化を行
ない、暗号化データ：［Ｋｂ（ＳｅｃＤａｔａ）］を生
成する。データ暗号化が終了すると、さらに、（４）セ
キュリティチップの制御部は、バックアップ鍵（キ
ー）：Ｋｂをサポートセンタの公開鍵：Ｋｐｓを用いて
暗号化して暗号鍵データ：［Ｋｐｓ（Ｋｂ）］を生成す
る。

【０４６３】上記処理の後、セキュリティチップの制御
部は、（５）暗号化データ：［Ｋｂ（ＳｅｃＤａｔ
ａ）］と、暗号鍵データ：［Ｋｐｓ（Ｋｂ）］をバック
アップストレージメディアに格納する。なお、これらの
処理の後、バックアップ鍵（キー）：Ｋｂは、セキュリ
ティチップから消去される。

【０４６４】なお、バックアップストレージメディアに
暗号化データ：［Ｋｂ（ＳｅｃＤａｔａ）］と、暗号鍵
データ：［Ｋｐｓ（Ｋｂ）］を格納することなく、これ
らのデータを直接サポートセンタに送信し、サポートセ
ンタ内の記憶手段にユーザデバイスＩＤ、またはセキュ
リティチップＩＤに対応させてバックアップデータを保
存する構成としてもよい。このような構成とした場合
は、バックアップデータに基づくリストア処理は、ユー
ザデバイス（セキュリティチップ）側からサポートセン
タに対する通信ネットワークを介したリクエストに応じ
て実行可能となり、バックアップストレージメディアを
送付することなく、リストア処理を実行することが可能
となる。

【０４６５】次に、図５２を参照して、サポートセンタ
で実行するバックアップストレージメディアからのバッ
クアップデータの取得処理について説明する。サポート
センタでは、まず、ユーザサイトから送付されたバック
アップストレージメデイアに格納されたデータを読み出
す。読み出しデータは、バックアップ鍵（キー）：Ｋｂ
で暗号化されたバックアップデータ：［Ｋｂ（ＳｅｃＤ
ａｔａ）］と、バックアップ鍵（キー）：Ｋｂをサポー
トセンタの公開鍵：Ｋｐｓを用いて暗号化した暗号鍵デ
ータ：［Ｋｐｓ（Ｋｂ）］である。なお、前述したよう
に、サポートセンタ内の記憶手段にユーザデバイスＩ
Ｄ、またはセキュリティチップＩＤに対応させてバック
アップデータを保存した構成とした場合は、サポートセ
ンタは、ユーザサイトからのリストア処理リクエストに
基づいて、記憶手段からこれらのデータの読み出しを行
なう。

【０４６６】サポートセンタは、データの読み出しの
後、まずサポートセンタの公開鍵：Ｋｐｓで暗号化した
バックアップ鍵（キー）：Ｋｂデータ：［Ｋｐｓ（Ｋ
ｂ）］を、サポートセンタの公開鍵に対応する秘密鍵：
Ｋｓｓで復号化処理を実行し、バックアップ鍵（キ
ー）：Ｋｂを取り出す。さらに、バックアップ鍵（キ
ー）：Ｋｂで暗号化されたバックアップデータ：［Ｋｂ
（ＳｅｃＤａｔａ）］を、取り出したバックアップ鍵
（キー）：Ｋｂを適用して復号化処理を実行し、バック
アップデータ：ＳｅｃＤａｔａを取り出す。

【０４６７】次に、図５３を参照して、サポートセンタ
で実行するリストア処理のシーケンスについて説明す
る。図５３は、左から、リストア処理によりデータを格
納する新たなユーザデバイスのセキュリティチップ制御
部、およびユーザデバイス制御部、サポートセンタサー
バ、さらに、属性証明書発行者である属性証明書認証局
（ＡＡ：Attribute Certificate Authority）の処理を
示している。なお、属性証明書発行局は、属性証明書を
発行する機関であり、例えばサービスプロバイダ内に構
成される。ここで属性証明書発行局は、ユーザデバイス
のセキュリティチップ内のメモリにサービスプロバイダ
管理領域を生成するための属性証明書である。

【０４６８】前述したように、サービスプロバイダ管理
領域生成用の属性証明書は、サービスプロバイダがユー
ザデバイスのセキュリティチップ内のメモリにサービス
プロバイダ毎の管理領域を登録設定することを目的とし
て発行される属性証明書であり、属性情報フィールドに
は、サービスプロバイダ識別子（ＩＤ）、サービスプロ
バイダ・ネーム、処理態様：メモリ領域確保、領域サイ
ズ：メモリ領域のサイズ等が記録される。

【０４６９】図５３の処理シーケンスについて説明す
る。まず、（１）ユーザデバイス制御部からセキュリテ
ィチップ制御部に対してリストア処理要求が出力され
る。これは、サポートセンタのオペーレータによってユ
ーザデバイス側の入力部に対して実行するリストア処理
実行指示に基づいて行われる。

【０４７０】セキュリティチップ制御部は、（２）ユー
ザデバイス制御部からリストア処理要求を受信すると、
（３）セキュリティチップとサービスプロバイダ間の相
互認証処理を実行する。この相互認証処理は、先に説明
した図１６のＴＬＳ１．０処理または、その他の方式、
例えば公開鍵方式による相互認証処理として実行され
る。この相互認証処理においては、相互の公開鍵証明書
の検証がなされ、必要に応じてルート認証局（ＣＡ）ま
での公開鍵証明書が連鎖的に検証される。この認証処理
において、セキュリティチップと、サポートセンタはセ
ッション鍵（Ｋｓｅｓ）を共有する。相互認証が成立す
ると、次に、（４）セキュリティチップ制御部は、サポ
ートセンタに対してリストア処理要求を送信する。

【０４７１】サポートセンタは、セキュリティチップか
らのリストア処理要求を受信すると、（５）バックアッ
プデータの検索処理を行なう。これは、サポートセンタ
が、ユーザサイトからバックアップデータを受領済みで
あるか否かの確認として実行される。

【０４７２】サポートセンタは、次に、（６）メモリ領
域確保用属性証明書（ＡＣ）の発行要求を属性証明書発
行局（者である）に対して送信する。（７）属性証明書
（ＡＣ）の発行要求を受信した属性証明書発行者である
属性証明書認証局（ＡＡ）は、メモリ領域確保用属性証
明書（ＡＣ）を生成する。なお、属性証明書（ＡＣ）
は、予め属性証明書認証局（ＡＡ）から発行を受けてお
いてもよい。

【０４７３】メモリ領域確保用属性証明書は、属性情報
フィールドに、サービスプロバイダ識別子（ＩＤ）、サ
ービスプロバイダ・ネーム、処理態様：メモリ領域確
保、領域サイズ：メモリ領域のサイズ等が記録されたも
のであり、例えば各サービスプロバイダの管理の下に発
行される。従って、リストア処理が１つのサービスプロ
バイダ管理領域内のデータについてのみ実行される場合
は、１つのメモリ領域確保用属性証明書によりセキュリ
ティチップ制御部内のメモリに１つのサービスプロバイ
ダ管理領域が設定され、データのリストアが実行される
が、複数のサービスプロバイダ管理領域内のデータにつ
いてリストアを実行する場合は、複数のメモリ領域確保
用属性証明書の発行を受けて、セキュリティチップ制御
部内のメモリに複数のサービスプロバイダ管理領域を設
定した上で、各利用域についてデータ格納を行なうこと
になる。

【０４７４】（８）属性証明書発行者である属性証明書
認証局（ＡＡ）は、生成したメモリ領域確保用属性証明
書（ＡＣ）をサポートセンタサーバに送信する。サポー
トセンタは、属性証明書発行者である属性証明書認証局
（ＡＡ）からメモリ領域確保用属性証明書（ＡＣ）を受
信すると、（９）属性証明書、およびバックアップデー
タをセキュリティチップ制御部に送信する。バックアッ
プデータは、メモリ領域確保用属性証明書（ＡＣ）によ
って、セキュリティチップのメモリに確保されるサービ
スプロバイダ管理領域に格納するデータであり、例え
ば、サービスプロバイダ（ＳＰ）対応秘密鍵、サービス
プロバイダ（ＳＰ）対応ストレージ秘密鍵、外部管理情
報のハッシュ値、利用回数管理データ、認証情報、ユー
ザ情報等の各データである。

【０４７５】（１０）セキュリティチップ制御部は、サ
ポートセンタサーバからのメモリ領域確保用属性証明書
（ＡＣ）を受信すると、属性証明書の検証処理を実行す
る。検証処理には、フォーマット確認、署名検証処理が
含まれる。署名検証処理は、例えば先に説明した図２０
の処理フローと同様のシーケンスに従って実行される。

【０４７６】さらに、必要に応じてセキュリティチップ
の制御部は、属性証明書（ＡＣ）内のＡＣ保持者の公開
鍵証明書情報に従ってリンクする公開鍵証明書を取得し
て、公開鍵証明書の検証を行なうことが好ましい。例え
ば属性証明書（ＡＣ）の発行者の信頼度が不確かである
場合には、属性証明書（ＡＣ）の発行者の公開鍵証明書
の検証を行なうことによって、認証局の公開鍵証明書を
正当に有しているか否かの判定が可能となる。なお、公
開鍵証明書が前述したように階層構成をなしている場合
は、経路を上位に辿って連鎖的な検証を行ない、ルート
認証局（ＣＡ）の発行した公開鍵証明書の検証まで実行
することが好ましい。なお、この連鎖検証が必須の場合
もある。

【０４７７】（１１）属性証明書の検証により、属性証
明書の改竄なしの判定が得られると、セキュリティチッ
プの制御部は、メモリ領域確保用属性証明書（ＡＣ）に
記録された条件に従って、セキュリティチップ内のメモ
リにサービスプロバイダ管理領域を設定する。（１２）
さらに、セキュリティチップの制御部は、メモリに設定
されたサービスプロバイダ管理領域内にサポートセンタ
サーバから受信したバックアップデータを格納する。

【０４７８】以上の処理により、ユーザデバイスのセキ
ュリティチップのメモリに、メモリ領域確保用属性証明
書に記録された条件に従ってサービスプロバイダ管理領
域が確保され、確保されたサービスプロバイダ管理領域
にバックアップデータが格納される。なお、複数のサー
ビスプロバイダ管理領域に対応するバックアップデータ
のリストアを行なう場合は、複数のメモリ領域確保用属
性証明書の発行に基づいて同様の処理を繰り返し実行す
る。

【０４７９】なお、上述の処理シーケンスの後、あるい
はその途中において、サポートセンタは、廃棄対象とな
る元のユーザデバイスのリボーク処理を実行する。さら
に、リストアを要求してきたユーザに対する課金処理を
実行してもよい。

【０４８０】［各エンティテイの構成］次に、上述した
コンテンツ利用管理システムを構成する各エンティテイ
の構成例について図を参照しながら、説明する。まずサ
ービスプロバイダからのコンテンツを受領するサービス
受領デバイスとしてのユーザデバイスの構成例を図５４
を参照して説明する。

【０４８１】ユーザデバイスはデータ処理、制御を実行
するＣＰＵ、サービスプロバイダ他と通信可能な通信手
段を備えたＰＣ等のデータ処理手段によって実現するこ
とができる。図５４にデバイスの構成例を示す。なお、
図５４に示すデバイス構成例は１つの例であり、デバイ
スは、ここに示すべての機能を必ずしも備えることが要
求されるものではない。図５４に示すＣＰＵ(Central p
rocessing Unit)５０１は、各種アプリケーションプロ
グラムや、ＯＳ（Operating System）を実行するプロセ
ッサである。ＲＯＭ（Read-Only-Memory）５０２は、Ｃ
ＰＵ５０１が実行するプログラム、あるいは演算パラメ
ータとしての固定データを格納する。ＲＡＭ（Random A
ccess Memory）５０３は、ＣＰＵ５０１の処理において
実行されるプログラム、およびプログラム処理において
適宜変化するパラメータの格納エリア、ワーク領域とし
て使用される。

【０４８２】ＨＤＤ５０４はハードディスクの制御を実
行し、ハードディスクに対する各種データ、プログラム
の格納処理および読み出し処理を実行する。セキュリテ
ィチップ５１２は、前述したように耐タンパ構造を持つ
構成であり、暗号処理に必要な鍵データ、アクセス許可
書の格納領域としてのメモリ、制御部を有する。

【０４８３】バス５１０はＰＣＩ（Peripheral Compone
nt Interface）バス等により構成され、各モジュール、
入出力インタフェース５１１を介した各入手力装置との
データ転送を可能にしている。

【０４８４】入力部５０５は、例えばキーボード、ポイ
ンティングデバイス等によって構成され、ＣＰＵ５０１
に各種のコマンド、データを入力するためにユーザによ
り操作される。出力部５０６は、例えばＣＲＴ、液晶デ
ィスプレイ等であり、各種情報をテキストまたはイメー
ジ等により表示する。

【０４８５】通信部５０７はデバイスの接続したエンテ
ィテイ、例えばサービスプロバイダ等との通信処理を実
行し、ＣＰＵ５０１の制御の下に、各記憶部から供給さ
れたデータ、あるいはＣＰＵ５０１によって処理された
データ、暗号化されたデータ等を送信したり、他エンテ
ィテイからのデータを受信する処理を実行する。

【０４８６】ドライブ５０８は、フロッピー（登録商
標）ディスク、ＣＤ−ＲＯＭ(Compact Disc Read Only
Memory)，ＭＯ(Magneto optical)ディスク，ＤＶＤ(Dig
ital Versatile Disc)、磁気ディスク、半導体メモリな
どのリムーバブル記録媒体５０９の記録再生を実行する
ドライブであり、各リムーバブル記録媒体５０９からの
プログラムまたはデータ再生、リムーバブル記録媒体５
０９に対するプログラムまたはデータ格納を実行する。

【０４８７】各記憶媒体に記録されたプログラムまたは
データを読み出してＣＰＵ５０１において実行または処
理を行なう場合は、読み出したプログラム、データはイ
ンタフェース５１１、バス５１０を介して例えば接続さ
れているＲＡＭ５０３に供給される。

【０４８８】前述の説明内に含まれるユーザデバイスに
おける処理を実行するためのプログラムは例えばＲＯＭ
５０２に格納されてＣＰＵ５０１によって処理される
か、あるいはハードディスクに格納されＨＤＤ５０４を
介してＣＰＵ５０１に供給されて実行される。

【０４８９】次に、本発明のシステムの構成エンティテ
イであるサービスプロバイダ、サポートセンタ、コンテ
ンツクリエータ、属性証明書発行局等の各エンティテイ
を構成するデータ処理装置の構成例について説明する。
これらのエンティテイは例えば図５５に構成によって実
現することができる。なお、図５５に示すデータ処理装
置構成例は１つの例であり、各エンティテイは、ここに
示すべての機能を必ずしも備えることが要求されるもの
ではない。

【０４９０】図５５に示すＣＰＵ(Central processing
Unit)６０１は、各種アプリケーションプログラムや、
ＯＳ（Operating System）を実際に実行する。ＲＯＭ
（Read-Only-Memory）６０２は、ＣＰＵ６０１が実行す
るプログラム、あるいは演算パラメータとしての固定デ
ータを格納する。ＲＡＭ（Random Access Memory）６０
３は、ＣＰＵ６０１の処理において実行されるプログラ
ム、およびプログラム処理において適宜変化するパラメ
ータの格納エリア、ワーク領域として使用される。ＨＤ
Ｄ６０４はハードディスクの制御を実行し、ハードディ
スクに対する各種データ、プログラムの格納処理および
読み出し処理を実行する。暗号処理手段６０５は、送信
データの暗号処理、復号化処理等を実行する。なお、こ
こでは、暗号処理手段を個別モジュールとした例を示し
たが、このような独立した暗号処理モジュールを設け
ず、例えば暗号処理プログラムをＲＯＭ６０２に格納
し、ＣＰＵ６０１がＲＯＭ格納プログラムを読み出して
実行するように構成してもよい。

【０４９１】ドライブ６０６は、フロッピーディスク、
ＣＤ−ＲＯＭ(Compact Disc Read Only Memory)，ＭＯ
(Magneto optical)ディスク，ＤＶＤ(Digital Versatil
e Disc)、磁気ディスク、半導体メモリなどのリムーバ
ブル記録媒体６０７の記録再生を実行するドライブであ
り、各リムーバブル記録媒体６０７からのプログラムま
たはデータ再生、リムーバブル記録媒体６０７に対する
プログラムまたはデータ格納を実行する。各記憶媒体に
記録されたプログラムまたはデータを読み出してＣＰＵ
６０１において実行または処理を行なう場合は、読み出
したプログラム、データはバス６１０を介して例えば接
続されているＲＡＭ６０３、通信部６０８、通信部６０
９に供給される。

【０４９２】通信部６０８、通信部６０９は、それぞれ
異なるエンティテイを通信相手として通信する処理を想
定して複数の通信部を設けた例を示している。例えばサ
ービスプロバイダであれば、一方はユーザデバイスとの
通信、他方はコンテンツクリエータとの通信処理に使用
される。各通信部を介して通信相手との相互認証、暗号
化データの送受信処理等が実行される。

【０４９３】前述した説明内に含まれるサービスプロバ
イダ、サポートセンタ、コンテンツクリエータ、属性証
明書発行局を構成するデータ処理装置における各処理を
実行するためのプログラムは例えばＲＯＭ６０２に格納
されてＣＰＵ６０１によって処理されるか、あるいはハ
ードディスクに格納されＨＤＤ６０４を介してＣＰＵ６
０１に供給されて実行される。

【０４９４】以上、特定の実施例を参照しながら、本発
明について詳解してきた。しかしながら、本発明の要旨
を逸脱しない範囲で当業者が該実施例の修正や代用を成
し得ることは自明である。すなわち、例示という形態で
本発明を開示してきたのであり、限定的に解釈されるべ
きではない。本発明の要旨を判断するためには、冒頭に
記載した特許請求の範囲の欄を参酌すべきである。

【０４９５】なお、明細書中において説明した一連の処
理はハードウェア、またはソフトウェア、あるいは両者
の複合構成によって実行することが可能である。ソフト
ウェアによる処理を実行する場合は、処理シーケンスを
記録したプログラムを、専用のハードウェアに組み込ま
れたコンピュータ内のメモリにインストールして実行さ
せるか、あるいは、各種処理が実行可能な汎用コンピュ
ータにプログラムをインストールして実行させることが
可能である。

【０４９６】例えば、プログラムは記録媒体としてのハ
ードディスクやＲＯＭ（Read OnlyMemory)に予め記録し
ておくことができる。あるいは、プログラムはフロッピ
ーディスク、ＣＤ−ＲＯＭ(Compact Disc Read Only Me
mory)，ＭＯ(Magneto optical)ディスク，ＤＶＤ(Digit
al Versatile Disc)、磁気ディスク、半導体メモリなど
のリムーバブル記録媒体に、一時的あるいは永続的に格
納（記録）しておくことができる。このようなリムーバ
ブル記録媒体は、いわゆるパッケージソフトウエアとし
て提供することができる。

【０４９７】なお、プログラムは、上述したようなリム
ーバブル記録媒体からコンピュータにインストールする
他、ダウンロードサイトから、コンピュータに無線転送
したり、ＬＡＮ(Local Area Network)、インターネット
といったネットワークを介して、コンピュータに有線で
転送し、コンピュータでは、そのようにして転送されて
くるプログラムを受信し、内蔵するハードディスク等の
記録媒体にインストールすることができる。

【０４９８】なお、明細書に記載された各種の処理は、
記載に従って時系列に実行されるのみならず、処理を実
行する装置の処理能力あるいは必要に応じて並列的にあ
るいは個別に実行されてもよい。また、本明細書におい
てシステムとは、複数の装置の論理的集合構成であり、
各構成の装置が同一筐体内にあるものには限らない。

【０４９９】

【発明の効果】以上、説明したように、本発明のパスワ
ード管理システム、パスワード管理方法、および情報処
理装置、並びにコンピュータ・プログラムによれば、情
報処理装置におけるデータ処理の開始条件として設定さ
れるパスワードの上位パスワードとしてマスターパスワ
ードを設定し、各パスワードのリセットまたは変更処理
時にマスターパスワードの一致検証を行なうように構成
したので、複数のパスワードの管理をセキュアにかつ効
率的に実行可能となる。

【０５００】さらに、本発明のパスワード管理システ
ム、パスワード管理方法、および情報処理装置、並びに
コンピュータ・プログラムによれば、マスターパスワー
ドを、情報処理装置に対応して設定されたデバイス識別
子としてのデバイスＩＤに、情報処理装置に格納された
マスターキーを適用した暗号処理によって生成されるデ
ータとして構成し、マスターパスワードをメモリに格納
することなく、一致検証処理の実行に際して生成する構
成としたので、マスターパスワードの第三者への漏洩の
おそれが低減される。

【０５０１】さらに、本発明のパスワード管理システ
ム、パスワード管理方法、および情報処理装置、並びに
コンピュータ・プログラムによれば、マスターパスワー
ドの管理を実行するサポートセンタを設定し、サポート
センタによる、デバイスＩＤに基づくマスターパスワー
ドの検索、生成による再発行処理を実行する構成とした
ので、ユーザにおけるパスワード管理の負担軽減が可能
となる。

【図面の簡単な説明】

【図１】本発明のコンテンツ利用管理システム構成の概
要を説明する図である。

【図２】本発明のコンテンツ利用管理システムにおいて
適用可能な公開鍵証明書のフォーマットを示す図であ
る。

【図３】本発明のコンテンツ利用管理システムにおいて
適用可能な公開鍵証明書のフォーマットを示す図であ
る。

【図４】本発明のコンテンツ利用管理システムにおいて
適用可能な公開鍵証明書のフォーマットを示す図であ
る。

【図５】本発明のコンテンツ利用管理システムにおいて
適用可能な権限情報証明書としての属性証明書のフォー
マットを示す図である。

【図６】ユーザデバイスにおけるセキュリティチップの
構成を示す構成図である。

【図７】ユーザデバイス内での処理対象となる主なデー
タを示す図である。

【図８】認証情報（パスワード）の初期登録処理シーケ
ンスを示す図である。

【図９】認証情報（パスワード）の変更処理シーケンス
を示す図である。

【図１０】認証情報（パスワード）の変更処理シーケン
スを示す図である。

【図１１】認証情報（パスワード）とマスタパスワード
との対応について説明する図である。

【図１２】マスタパスワードの配布処理について説明す
る図である。

【図１３】マスタパスワードの再発行処理シーケンスを
示す図である。

【図１４】マスタパスワードの算出処理を示すフロー図
である。

【図１５】属性証明書（ＡＣ）発行、コンテンツ受信処
理シーケンスを示す図である。

【図１６】相互認証処理の例であるＴＬＳ１．０ハンド
シェイクプロトコルのシーケンスを示す図である。

【図１７】データ改竄検証に適用するＭＡＣの生成処理
を説明する図である。

【図１８】属性証明書（ＡＣ）の発行処理シーケンスを
示す図である。

【図１９】署名生成処理の例であるＥＣＤＳＡ署名生成
手順を説明するフロー図である。

【図２０】署名検証処理の例であるＥＣＤＳＡ署名検証
手順を説明するフロー図である。

【図２１】公開鍵証明書（ＰＫＣ）と属性証明書（Ａ
Ｃ）との関連付けについて説明する図である。

【図２２】公開鍵証明書（ＰＫＣ）の検証処理フローを
示す図である。

【図２３】属性証明書（ＡＣ）の検証処理フロー（例
１）を示す図である。

【図２４】属性証明書（ＡＣ）の検証処理フロー（例
２）を示す図である。

【図２５】属性証明書（ＡＣ）を利用したコンテンツ利
用処理（オフライン）を説明するシーケンス図である。

【図２６】属性証明書（ＡＣ）を利用したコンテンツ利
用処理（オンライン）を説明するシーケンス図である。

【図２７】グローバル共通鍵によるコンテンツ鍵の暗号
化データを格納した属性証明書（ＡＣ）を利用したコン
テンツ利用処理（オフライン）を説明する図である。

【図２８】グローバル共通鍵の更新処理を説明するシー
ケンス図である。

【図２９】グローバル共通鍵の更新処理を説明するシー
ケンス図である。

【図３０】デコーダを用いた復号化処理について説明す
る図である。

【図３１】デコーダを用いた復号化処理シーケンスにつ
いて説明する図である。

【図３２】デコーダを用いた復号化処理フローについて
説明する図である。

【図３３】ユーザデバイス側における属性証明書（Ａ
Ｃ）の適用処理を説明するフロー図である。

【図３４】属性証明書（ＡＣ）を利用したオンライン期
間制限コンテンツの利用処理を説明するシーケンス図で
ある。

【図３５】属性証明書（ＡＣ）を利用したオンライン回
数制限コンテンツの利用処理を説明するシーケンス図で
ある。

【図３６】属性証明書（ＡＣ）を利用したオフライン買
い切りコンテンツの利用処理を説明するシーケンス図で
ある。

【図３７】オフライン回数制限コンテンツに対応する利
用回数管理データのインポート処理を説明する図であ
る。

【図３８】オフライン回数制限コンテンツに対応する利
用回数管理データのデータ構成例を示す図である。

【図３９】オフライン回数制限コンテンツに対応する利
用回数管理データのインポート処理を説明するフロー図
である。

【図４０】オフライン回数制限コンテンツに対応するハ
ッシュ値管理型の利用回数管理データのインポート処理
を説明する図である。

【図４１】オフライン回数制限コンテンツに対応するハ
ッシュ値管理型の利用回数管理データのインポート処理
を説明するフロー図である。

【図４２】オフライン回数制限コンテンツの属性証明書
を適用したコンテンツ利用処理を説明する図である。

【図４３】オフライン回数制限コンテンツに対応する回
数管理データの更新処理を説明する図である。

【図４４】オフライン回数制限コンテンツに対応するハ
ッシュ値管理型の回数管理データの更新処理を説明する
図である。

【図４５】オンライン期間制限属性証明書をベースとし
て適用したアップグレード処理を説明する図である。

【図４６】オンライン回数制限属性証明書をベースとし
て適用したアップグレード処理を説明する図である。

【図４７】オフライン回数制限属性証明書をベースとし
て適用したアップグレード処理を説明する図である。

【図４８】アルバム購入型のアップグレード処理を説明
する図である。

【図４９】サポートセンタによるデータリストア処理の
概要を説明する図である。

【図５０】サポートセンタによるデータリストア処理の
処理シーケンス概要を説明する図である。

【図５１】ユーザデバイス側で実行するデータバックア
ップ処理シーケンスを説明する図である。

【図５２】サポートセンタによるバックアップデータ読
み出し処理の概要を説明する図である。

【図５３】サポートセンタによるデータリストア処理シ
ーケンスを説明する図である。

【図５４】ユーザデバイスの構成例を示す図である。

【図５５】サービスプロバイダ、サポートセンタ、コン
テンツクリエータ等の各エンティテイの構成例を示す図
である。

【符号の説明】

１０１ユーザデバイス１０２サービスプロバイダ１０３コンテンツクリエータ１０４ユーザデバイス製造者１０５サポートセンタ１０６認証局１１０属性証明書２００ユーザデバイス２０１ＣＰＵ (Central processing Unit) ２０２インタフェース２０３ＲＯＭ（Read-Only-Memory）２０４ＲＡＭ（Random Access Memory）２０５暗号処理部２０６メモリ部２１０セキュリティチップ２２１ユーザデバイス側制御部２２２外部メモリ部２８０デコーダ３０１システムホルダ３０２サービスプロバイダ３０３コンテンツクリエータ３０４ユーザデバイス４１０ユーザデバイス４１１セキュリティチップ４２１記憶手段４２２ストレージメディア４３０ユーザデバイス４５０サポートセンタ４７０ユーザデバイス４７１ストレージメディア４７２ユーザデバイス４７５サポートセンタ５０１ＣＰＵ (Central processing Unit) ５０２ＲＯＭ（Read-Only-Memory）５０３ＲＡＭ（Random Access Memory）５０４ＨＤＤ５０５入力部５０６出力部５０７通信部５０８ドライブ５０９リムーバブル記録媒体５１０バス５１１入出力インタフェース５１２セキュリティチップ６０１ＣＰＵ(Central processing Unit) ６０２ＲＯＭ（Read-Only-Memory）６０３ＲＡＭ（Random Access Memory）６０４ＨＤＤ６０５暗号処理手段６０６ドライブ６０７リムーバブル記録媒体６０８，６０９通信部６１０バス

───────────────────────────────────────────────────── フロントページの続き (72)発明者阿部博東京都品川区北品川６丁目７番35号ソニー株式会社内 (72)発明者島田昇東京都品川区北品川６丁目７番35号ソニー株式会社内 (72)発明者吉野賢治東京都品川区北品川６丁目７番35号ソニー株式会社内 (72)発明者實藤隆則東京都品川区北品川６丁目７番35号ソニー株式会社内 (72)発明者佐々木鉄雄東京都品川区北品川６丁目７番35号ソニー株式会社内 (72)発明者木村真也東京都品川区北品川６丁目７番35号ソニー株式会社内 (72)発明者保木本晃弘東京都品川区北品川６丁目７番35号ソニー株式会社内Ｆターム(参考） 5B017 AA01 BA05 CA16 5B085 AE03 AE04 AE09 AE13 5J104 AA07 AA16 EA01 EA03 EA26 KA01 KA06 MA01 NA05 PA07

Claims

【特許請求の範囲】

【請求項１】情報処理装置におけるデータ処理の開始条
件として設定されるパスワードの管理を実行するパスワ
ード管理システムであり、情報処理装置は、設定パスワードのリセットまたは変更
処理に際し、該情報処理装置に対応して設定されたマス
ターパスワードとユーザ入力マスターパスワードとの一
致検証処理を実行し、該一致検証処理における検証成立
を条件として設定パスワードのリセットまたは変更処理
を実行する構成を有することを特徴とするパスワード管
理システム。
【請求項２】前記マスターパスワードは、前記情報処理
装置に対応して設定されたデバイス識別子としてのデバ
イスＩＤに、前記情報処理装置個々または一群の情報処
理装置に対応して設定されたマスターキーを適用した暗
号処理によって生成されるデータであることを特徴とす
る請求項１に記載のパスワード管理システム。
【請求項３】前記パスワード管理システムにおいて、さ
らに、前記マスターパスワードの管理を実行するサポートセン
タを有し、前記サポートセンタは、前記情報処理装置に対応して設
定されたデバイス識別子としてのデバイスＩＤと、マス
ターパスワードとを対応させたデータベースを有し、前記サポートセンタは、前記情報処理装置からのマスターパスワード再発行要求
に応じて、前記データベースから取得したマスターパス
ワードの前記情報処理装置に対する送付処理を実行する
構成であることを特徴とする請求項１に記載のパスワー
ド管理システム。
【請求項４】前記パスワード管理システムにおいて、さ
らに、マスターパスワードの管理を実行するサポートセンタを
有し、前記サポートセンタは、前記情報処理装置に対応して設
定されたデバイス識別子としてのデバイスＩＤと、前記
情報処理装置個々または一群の情報処理装置に対応して
設定されたマスターキーとを対応させたデータベースを
有し、前記サポートセンタは、前記情報処理装置からのマスターパスワード再発行要求
に応じて、前記デバイスＩＤに対する、前記マスターキ
ーを適用した暗号処理によるマスターパスワード生成処
理を実行し、生成したマスターパスワードを前記情報処
理装置に送付する処理を実行する構成であることを特徴
とする請求項１に記載のパスワード管理システム。
【請求項５】前記マスターパスワードは、情報処理装置におけるデータ処理の開始条件として設定
される複数の異なるパスワードのリセットまたは変更処
理に際して共通に使用される構成であることを特徴とす
る請求項１に記載のパスワード管理システム。
【請求項６】前記パスワードは、情報処理装置内のメモ
リに設定された複数のデータ格納領域の各々に対応して
設定された複数の異なるパスワードであり、各パスワー
ドは、各データ格納領域内の格納データに対するアクセ
ス可否を判定するパスワードであることを特徴とする請
求項１に記載のパスワード管理システム。
【請求項７】情報処理装置におけるデータ処理の開始条
件として設定されるパスワードの管理を実行するパスワ
ード管理方法であり、前記情報処理装置において、設定パスワードのリセットまたは変更処理に際し、該情
報処理装置に対応して設定されたマスターパスワードと
ユーザ入力マスターパスワードとの一致検証処理を実行
するステップと、前記一致検証処理における検証成立を条件として設定パ
スワードのリセットまたは変更処理を実行するステップ
と、を有することを特徴とするパスワード管理方法。
【請求項８】前記マスターパスワードは、前記情報処理
装置に対応して設定されたデバイス識別子としてのデバ
イスＩＤに、前記情報処理装置個々または一群の情報処
理装置に対応して設定されたマスターキーを適用した暗
号処理によって生成されるデータであることを特徴とす
る請求項７に記載のパスワード管理方法。
【請求項９】前記パスワード管理方法において、さら
に、前記マスターパスワードの管理を実行するサポートセン
タを有し、前記サポートセンタは、前記情報処理装置に対応して設
定されたデバイス識別子としてのデバイスＩＤと、マス
ターパスワードとを対応させたデータベースを有し、前記サポートセンタは、前記情報処理装置からのマスターパスワード再発行要求
に応じて、前記データベースから取得したマスターパス
ワードの前記情報処理装置に対する送付処理を実行する
ことを特徴とする請求項７に記載のパスワード管理方
法。
【請求項１０】前記パスワード管理方法において、さら
に、マスターパスワードの管理を実行するサポートセンタを
有し、前記サポートセンタは、前記情報処理装置に対応して設
定されたデバイス識別子としてのデバイスＩＤと、前記
情報処理装置個々または一群の情報処理装置に対応して
設定されたマスターキーとを対応させたデータベースを
有し、前記サポートセンタは、前記情報処理装置からのマスターパスワード再発行要求
に応じて、前記デバイスＩＤに対する、前記マスターキ
ーを適用した暗号処理によるマスターパスワード生成処
理を実行し、生成したマスターパスワードを前記情報処
理装置に送付する処理を実行することを特徴とする請求
項７に記載のパスワード管理方法。
【請求項１１】前記マスターパスワードは、情報処理装置におけるデータ処理の開始条件として設定
される複数の異なるパスワードのリセットまたは変更処
理に際して共通に使用されることを特徴とする請求項７
に記載のパスワード管理方法。
【請求項１２】前記パスワードは、情報処理装置内のメ
モリに設定された複数のデータ格納領域の各々に対応し
て設定された複数の異なるパスワードであり、各パスワ
ードは、各データ格納領域内の格納データに対するアク
セス可否を判定するパスワードであることを特徴とする
請求項７に記載のパスワード管理方法。
【請求項１３】データ処理を実行する情報処理装置であ
り、情報処理装置におけるデータ処理の開始条件として設定
されるパスワードのリセットまたは変更処理に際し、該
情報処理装置に対応して設定されたマスターパスワード
とユーザ入力マスターパスワードとの一致検証処理を実
行し、該一致検証処理における検証成立を条件として設
定パスワードのリセットまたは変更処理を実行する構成
を有することを特徴とする情報処理装置。
【請求項１４】前記マスターパスワードは、前記情報処
理装置に対応して設定されたデバイス識別子としてのデ
バイスＩＤに、前記情報処理装置個々または一群の情報
処理装置に対応して設定されたマスターキーを適用した
暗号処理によって生成されるデータであることを特徴と
する請求項１３に記載の情報処理装置。
【請求項１５】前記マスターパスワードは、情報処理装置におけるデータ処理の開始条件として設定
される複数の異なるパスワードのリセットまたは変更処
理に際して共通に使用される構成であることを特徴とす
る請求項１３に記載の情報処理装置。
【請求項１６】前記パスワードは、情報処理装置内のメ
モリに設定された複数のデータ格納領域の各々に対応し
て設定された複数の異なるパスワードであり、各パスワ
ードは、各データ格納領域内の格納データに対するアク
セス可否を判定するパスワードであることを特徴とする
請求項１３に記載の情報処理装置。
【請求項１７】情報処理装置におけるデータ処理の開始
条件として設定されるパスワードの管理を実行するパス
ワード管理処理をコンピュータ・システム上で実行せし
めるコンピュータ・プログラムであって、設定パスワードのリセットまたは変更処理に際し、該情
報処理装置に対応して設定されたマスターパスワードと
ユーザ入力マスターパスワードとの一致検証処理を実行
するステップと、前記一致検証処理における検証成立を条件として設定パ
スワードのリセットまたは変更処理を実行するステップ
と、を有することを特徴とするコンピュータ・プログラム。