JP2004015527A - Data processing right management system, information processor and method, and computer program - Google Patents

Data processing right management system, information processor and method, and computer program Download PDF

Info

Publication number
JP2004015527A
JP2004015527A JP2002167480A JP2002167480A JP2004015527A JP 2004015527 A JP2004015527 A JP 2004015527A JP 2002167480 A JP2002167480 A JP 2002167480A JP 2002167480 A JP2002167480 A JP 2002167480A JP 2004015527 A JP2004015527 A JP 2004015527A
Authority
JP
Japan
Prior art keywords
attribute certificate
execution
certificate
signature
key
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Granted
Application number
JP2002167480A
Other languages
Japanese (ja)
Other versions
JP4207465B2 (en
JP2004015527A5 (en
Inventor
Takayoshi Kawaguchi
川口　貴義
Noboru Shimada
島田　昇
Makoto Oka
岡　誠
Madoka Masugi
間杉　円
Yoshito Ishibashi
石橋　義人
Hiroshi Abe
阿部　博
Nobutaka Toyoshima
豊島　信隆
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Sony Corp
Original Assignee
Sony Corp
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Sony Corp filed Critical Sony Corp
Priority to JP2002167480A priority Critical patent/JP4207465B2/en
Publication of JP2004015527A publication Critical patent/JP2004015527A/en
Publication of JP2004015527A5 publication Critical patent/JP2004015527A5/ja
Application granted granted Critical
Publication of JP4207465B2 publication Critical patent/JP4207465B2/en
Anticipated expiration legal-status Critical
Expired - Fee Related legal-status Critical Current

Links

Images

Abstract

<P>PROBLEM TO BE SOLVED: To realize a data processing right management system which limitedly and strictly enables only a user who has the legal right to receive services to use the services. <P>SOLUTION: An execution property certificate having as stored data a ciphered execution instruction and an address (Ad) indicating the storage area of a registered key for deciphering the ciphered execution key in an in-device memory is provided for a user device, which applies a registered key obtained from a memory of the user device according to the address stored in the execution property certificate to decipher the ciphered execution instruction stored in the execution property certificate, thereby performing data processing based upon the deciphered instruction. Only the user device capable of obtaining the registered key according to the specified address of the execution property certificate can execute the execution instruction of the execution property certificate and services for which the user having the service use right is severely limited can be provided. <P>COPYRIGHT: (C)2004,JPO

Description

【０００１】
【発明の属する技術分野】
本発明は、データ処理権限管理システム、情報処理装置、および方法、並びにコンピュータ・プログラムに関する。例えばコンテンツ利用、あるいはサービス利用処理等において確認が要求されるユーザ等のサービス受領権限の管理を行い、正当なサービス受領権限を有するユーザに対してのみサービスが実行可能となる構成として、サービスの利用を厳格に制限することを可能としたデータ処理権限管理システム、情報処理装置、および方法、並びにコンピュータ・プログラムに関する。
【０００２】
【従来の技術】
昨今、インターネット等の通信網、あるいは、ＤＶＤ、ＣＤ、ＩＣカード等の流通可能な記憶媒体を介した音楽データ、画像データ、ゲームプログラム等、様々なソフトウエアデータ（以下、これらをコンテンツ（Ｃｏｎｔｅｎｔ）と呼ぶ）の配信、あるいは端末間のデータ送受信処理を伴う決済等、端末間の通信処理を伴ったサービス提供処理が盛んに実行されている。例えばＰＣ、携帯通信端末、ポータブルデバイス、あるいはＩＣカード等の様々なユーザデバイスを有するユーザが、自宅、外出先等においてユーザデバイスをサービスプロバイダのサービス提供デバイスと接続し、デバイス間で情報の交換、あるいはコンテンツ、サービスの受領を行なうことが日常的になりつつある。
【０００３】
具体的なサービス利用例としては、例えば、ＰＣ、携帯端末等を用いて、コンテンツ配信サービスプロバイダにアクセスし、音楽、動画、ゲームプログラム等の様々なコンテンツをダウンロードしたり、あるいは、個人情報、銀行口座情報、利用可能金額情報等を格納したＩＣチップ内蔵のメモリカード等を用いて、ショッピングに利用したり、振替処理を行なったり、あるいは、駅の改札、バス等において切符の代替手段として用いるなど、様々な利用がなされつつある。
【０００４】
このように通信網あるいは媒体を介したコンテンツあるいはサービス等の流通が盛んになる一方、コンテンツ、あるいはサービスの不正利用、すなわち正当な権限を有しないユーザによるサービス利用の問題が発生しており、正当な利用権限を有するユーザにのみ確実にコンテンツあるいはサービス等の提供を行ない、サービスの不正利用を排除するシステムの構築が望まれている。
【０００５】
例えば、音楽データ、画像データ、ゲームプログラム等、多くのソフトウエア・コンテンツは、一般的にその作成者、販売者に頒布権等が保有されており、これらのコンテンツの配布に際しては、一定の利用制限、すなわち、正規なユーザに対してのみ、ソフトウエアの使用を許諾し、許可のない複製等が行われないようにセキュリティを考慮したシステムが採用されている。
【０００６】
サービスを受領する機器あるいはユーザの利用制限を実現する１つの手法が、暗号化処理である。例えばコンテンツあるいはサービス情報を機器またはユーザに提供する際に、暗号化して提供し、正規の機器またはユーザのみに利用可能な復号鍵を配布し、コンテンツあるいはサービス利用を可能とする形態がある。暗号化データは、復号鍵を用いた復号化処理によって復号データ（平文）に戻すことができる。
【０００７】
暗号化鍵と復号化鍵を用いるデータ暗号化・復号化方法の態様には様々な種類あるが、その１つの例としていわゆる共通鍵暗号化方式と呼ばれている方式がある。共通鍵暗号化方式は、データの暗号化処理に用いる暗号化鍵とデータの復号化に用いる復号化鍵を共通のものとして、正規のユーザにこれら暗号化処理、復号化に用いる共通鍵を付与して、鍵を持たない不正ユーザによるデータアクセスを排除するものである。この方式の代表的な方式にＤＥＳ（データ暗号標準：Ｄａｔａ　ｅｎｃｒｙｐｔｉｏｎ　ｓｔａｎｄａｒｄ）がある。
【０００８】
また、暗号化するときに使用する暗号化鍵による処理と、復号するときに使用する復号化鍵の処理とを異なる鍵で行なう方式がいわゆる公開鍵暗号方式と呼ばれる方式である。公開鍵暗号方式は、不特定のユーザが使用可能な公開鍵を使用する方法であり、特定個人に対する暗号化文書を、その特定個人が生成した公開鍵を用いて暗号化処理を行なう。公開鍵によって暗号化された文書は、その暗号化処理に使用された公開鍵に対応する秘密鍵によってのみ復号化処理が可能となる。秘密鍵は、公開鍵を生成した個人のみが所有するので、その公開鍵によって暗号化された文書は秘密鍵を持つ個人のみが復号することができる。公開鍵暗号方式の代表的なものには、楕円曲線暗号、あるいはＲＳＡ（Ｒｉｖｅｓｔ−Ｓｈａｍｉｒ−Ａｄｌｅｍａｎ）暗号がある。このような暗号化方式を利用することにより、暗号化コンテンツを正規ユーザに対してのみ復号可能とするシステムが可能となる。
【０００９】
上記のようなコンテンツあるいはサービスの利用管理構成において、正当なユーザであるか否かの判定は、例えばコンテンツあるいはサービスの提供者であるサービスプロバイダとＰＣ、携帯端末、ＩＣカード等のユーザデバイス間において、コンテンツ、サービス情報等の暗号化データ、あるいは復号鍵の提供前の認証処理によって行なう方法が知られている。一般的な認証処理においては、相手の確認を行なうとともに、その通信でのみ有効なセッションキーを生成して、認証が成立した場合に、生成したセッションキーを用いてコンテンツ、あるいは復号鍵等のデータを暗号化して通信を行なう。
【００１０】
【発明が解決しようとする課題】
ユーザ権限を確認するシステムとしては、上述のように、サービスを提供するサービスプロバイダとユーザ間で１対１の認証処理を実行し、ユーザ権限の確認を実行する手法があるが、コンテンツ提供サービス、その他の情報利用サービス、決済サービス等、ユーザ端末で実行可能なサービスが多様化するにつれ、個々のユーザ、あるいはユーザ端末のサービス利用権限の有無を効率的に確実にかつセキュアに実行するシステムの構築が望まれている。
【００１１】
本発明は、上記問題点に鑑みてなされたものであり、様々なサービスをＰＣ、通信端末装置、携帯端末、ＩＣカード等のユーザデバイスを介してサービスプロバイダの提供するデバイス等から受領する際、ユーザのサービス利用権限を効率的に確実にかつセキュアに確認して、正当なサービス受領権限を有するユーザに対してのみサービスが実行可能となる構成として、サービスの利用を厳格に制限することを可能としたデータ処理権限管理システム、情報処理装置、および方法、並びにコンピュータ・プログラムを提供することを目的とする。
【００１２】
【課題を解決するための手段】
本発明の第１の側面は、
サービスプロバイダの提供するサービスを実行するユーザデバイスにおけるデータ処理権限を管理するデータ処理権限管理システムであり、
サービスプロバイダは、
暗号化処理のなされたデータ処理実行命令を含む暗号化実行命令と、該暗号化実行命令の復号処理に適用する登録鍵のユーザデバイス内メモリの格納領域を示すアドレス（Ａｄ）情報とを格納データとして有する実行属性証明書をサービス受領デバイスであるユーザデバイスに対して提供し、
ユーザデバイスは、
前記実行属性証明書に格納されたアドレス（Ａｄ）情報に従って、該ユーザデバイスのメモリから取得した登録鍵を適用して、該実行属性証明書に格納された暗号化実行命令の復号を行ない、復号結果に基づくデータ処理を実行する構成としたことを特徴とするデータ処理権限管理システムにある。
【００１３】
さらに、本発明のデータ処理権限管理システムの一実施態様において、前記実行属性証明書は、前記暗号化実行命令および前記アドレス（Ａｄ）情報とを含む格納データに対する発行者電子署名を有し、前記ユーザデバイスは、前記実行属性証明書の電子署名検証処理を実行し、該検証の成立を条件として、前記アドレス（Ａｄ）情報に従った登録鍵の取得処理を実行する構成であることを特徴とする。
【００１４】
さらに、本発明のデータ処理権限管理システムの一実施態様において、前記データ処理権限管理システムにおいて、ユーザデバイスに対する新たな実行属性証明書の発行処理は、実行属性証明書発行エンティテイが、実行属性証明書発行要求ユーザデバイスから、特定機器または特定ユーザの集合からなるグループに対応して設定されるグループ識別情報を格納情報として有し発行者電子署名を有するグループ属性証明書を受領し、該受領グループ属性証明書についての検証を実行し、該検証の成立を条件として実行する構成であることを特徴とする。
【００１５】
さらに、本発明のデータ処理権限管理システムの一実施態様において、前記サービスプロバイダは、前記ユーザデバイスから登録鍵格納予定アドレス情報を取得し、該登録鍵格納予定アドレス情報と、登録鍵の格納命令をユーザデバイスの取得可能な鍵を適用して暗号化した暗号化実行命令とを有するデータ部と、該データ部に対する電子署名を含む登録鍵生成実行属性証明書を生成してユーザデバイスに提供する構成を有し、ユーザデバイスは、前記電子署名の検証、前記登録鍵生成実行属性証明書に格納された暗号化実行命令の復号、および復号により取得した実行命令の処理により、登録鍵を前記登録鍵格納予定アドレスに対応するメモリ領域に格納する処理を実行する構成であることを特徴とする。
【００１６】
さらに、本発明のデータ処理権限管理システムの一実施態様において、前記登録鍵は、前記ユーザデバイスにおいて、乱数に基づいて生成される鍵であることを特徴とする。
【００１７】
さらに、本発明のデータ処理権限管理システムの一実施態様において、前記ユーザデバイスは、前記実行属性証明書に格納されたアドレス（Ａｄ）情報に従って、該ユーザデバイスのメモリから取得した登録鍵を適用して、該実行属性証明書に格納された暗号化実行命令の復号を行ない、復号結果に基づくデータ処理を実行するとともに、前記登録鍵格納領域を指定したアドレス（Ａｄ）に対応するメモリ領域に、リセット鍵データを書き込むことにより登録鍵の破棄処理を実行する構成であることを特徴とする。
【００１８】
さらに、本発明のデータ処理権限管理システムの一実施態様において、前記実行属性証明書に格納された暗号化実行命令には、実行命令の適用可能回数識別値が格納され、前記ユーザデバイスは、実行命令の実行に応じて前記適用可能回数識別値を更新して、更新された適用可能回数識別値を含む新たな実行属性証明書の生成を行なう構成であることを特徴とする。
【００１９】
さらに、本発明のデータ処理権限管理システムの一実施態様において、前記実行属性証明書に格納された暗号化実行命令には、実行命令の適用可能回数識別値が格納され、前記ユーザデバイスは、実行命令の実行に応じて前記適用可能回数識別値を更新して、更新された適用可能回数識別値が０である場合に、前記登録鍵格納領域を指定したアドレス（Ａｄ）に対応するメモリ領域に、リセット鍵データを書き込むことにより登録鍵の破棄処理を実行する構成であることを特徴とする。
【００２０】
さらに、本発明のデータ処理権限管理システムの一実施態様において、前記実行属性証明書に格納された暗号化実行命令は、他デバイスへの譲渡用実行属性証明書の生成処理命令を含み、前記ユーザデバイスは、前記譲渡用実行属性証明書の生成処理命令に従い、新たな譲渡用実行属性証明書の生成処理を実行し、他デバイスへの提供処理を実行する構成であることを特徴とする。
【００２１】
さらに、本発明のデータ処理権限管理システムの一実施態様において、前記実行属性証明書に格納された暗号化実行命令には、他デバイスの属性を証明する証明書としての審査代行属性証明書の発行処理命令、および該審査代行属性証明書の生成に必要とする署名生成用鍵を含み、前記ユーザデバイスは、前記審査代行属性証明書の発行処理命令に従い、前記署名生成用鍵を適用して署名を実行した審査代行属性証明書の生成処理を行い、他のサービス受領デバイスへの提供処理を実行する構成であることを特徴とする。
【００２２】
さらに、本発明のデータ処理権限管理システムの一実施態様において、前記審査代行属性証明書の生成を実行したユーザデバイスは、前記他のサービス受領デバイスへの前記審査代行属性証明書の提供に併せて、前記署名生成用鍵に対応する署名検証用鍵を格納し発行者署名を有する代理署名鍵証明書を提供し、前記他のサービス受領デバイスは、サービス提供エンティテイに対して、前記審査代行属性証明書および、代理署名鍵証明書を提示し、前記サービス提供エンティテイは、前記代理署名鍵証明書から取得した署名検証用鍵に基づく前記審査代行属性証明書の検証処理を実行する構成であることを特徴とする。
【００２３】
さらに、本発明のデータ処理権限管理システムの一実施態様において、前記実行属性証明書に格納された暗号化実行命令には、他デバイスの属性を証明する証明書としての代理署名属性証明書の発行処理命令、および該代理署名属性証明書の生成に必要とする署名生成用鍵を含み、前記ユーザデバイスは、前記代理署名属性証明書の発行処理命令に従い、該代理署名属性証明書の検証を実行する検証デバイスから受領した検証用乱数（Ｒａ）を格納データとして含み、前記署名生成用鍵を適用した署名を有する代理署名属性証明書の生成処理を行い、生成した前記代理署名属性証明書、および前記署名生成用鍵に対応する署名検証用鍵を格納し発行者署名を有する代理署名鍵証明書を検証デバイスとしてのサービス提供エンティテイに提示する処理を実行し、前記サービス提供エンティテイは、前記代理署名鍵証明書から取得した署名検証用鍵に基づく、署名検証、および前記代理署名属性証明書の実行命令から抽出した乱数照合による前記代理署名鍵証明書の検証処理を実行する構成であることを特徴とする。
【００２４】
さらに、本発明の第２の側面は、
データ処理を実行する情報処理装置であり、
暗号化データの復号処理に適用する登録鍵を格納するメモリ部と、
暗号化処理のなされたデータ処理実行命令を含む暗号化実行命令と、該暗号化実行命令の復号処理に適用する登録鍵の情報処理装置内のメモリにおける格納領域を示すアドレス（Ａｄ）情報とを格納データとして有し、発行者署名のなされた実行属性証明書を入力し、署名検証処理を実行するとともに、署名検証の成立を条件として、前記アドレス（Ａｄ）情報に従って、前記メモリ部から取得した登録鍵を適用して前記暗号化実行命令を復号する暗号処理部と、
前記暗号処理部において復号された実行命令を実行するデータ処理部と、
を有することを特徴とする情報処理装置にある。
【００２５】
さらに、本発明の情報処理装置の一実施態様において、前記データ処理部は、前記登録鍵格納領域を指定したアドレス（Ａｄ）に対応するメモリ領域に、リセット鍵データを書き込むことにより登録鍵の破棄処理を実行する構成であることを特徴とする。
【００２６】
さらに、本発明の情報処理装置の一実施態様において、前記実行属性証明書に格納された暗号化実行命令には、実行命令の適用可能回数識別値が格納され、前記データ処理部は、実行命令の実行に応じて前記適用可能回数識別値を更新して、更新された適用可能回数識別値を含む新たな実行属性証明書の生成を行なう構成であることを特徴とする。
【００２７】
さらに、本発明の情報処理装置の一実施態様において、前記実行属性証明書に格納された暗号化実行命令には、実行命令の適用可能回数識別値が格納され、前記データ処理部は、実行命令の実行に応じて前記適用可能回数識別値を更新して、更新された適用可能回数識別値が０となった場合に、前記登録鍵格納領域を指定したアドレス（Ａｄ）に対応するメモリ領域に、リセット鍵データを書き込むことにより登録鍵の破棄処理を実行する構成であることを特徴とする。
【００２８】
さらに、本発明の情報処理装置の一実施態様において、前記実行属性証明書に格納された暗号化実行命令は、他デバイスへの譲渡用実行属性証明書の生成処理命令を含み、前記データ処理部は、前記譲渡用実行属性証明書の生成処理命令に従い、新たな譲渡用実行属性証明書の生成処理を実行し、他デバイスへの提供処理を実行する構成であることを特徴とする。
【００２９】
さらに、本発明の情報処理装置の一実施態様において、前記実行属性証明書に格納された暗号化実行命令には、他デバイスの属性を証明する証明書としての審査代行属性証明書の発行処理命令、および該審査代行属性証明書の生成に必要とする署名生成用鍵を含み、前記データ処理部は、前記審査代行属性証明書の発行処理命令に従い、前記署名生成用鍵を適用して署名を実行した審査代行属性証明書の生成処理を実行する構成であることを特徴とする。
【００３０】
さらに、本発明の情報処理装置の一実施態様において、前記実行属性証明書に格納された暗号化実行命令には、他デバイスの属性を証明する証明書としての代理署名属性証明書の発行処理命令、および該代理署名属性証明書の生成に必要とする署名生成用鍵を含み、記データ処理部は、前記代理署名属性証明書の発行処理命令に従い、該代理署名属性証明書の検証を実行する検証デバイスから受領した検証用乱数（Ｒａ）を格納データとして含み、前記署名生成用鍵を適用した署名を有する代理署名属性証明書の生成処理を実行する構成であることを特徴とする。
【００３１】
さらに、本発明の第３の側面は、
サービスプロバイダの提供するサービスを実行するユーザデバイスにおけるデータ処理権限を管理するデータ処理権限管理方法であり、
サービスプロバイダにおける実行ステップとして、
暗号化処理のなされたデータ処理実行命令を含む暗号化実行命令と、該暗号化実行命令の復号処理に適用する登録鍵のユーザデバイス内メモリの格納領域を示すアドレス（Ａｄ）情報とを格納データとして有する実行属性証明書をサービス受領デバイスであるユーザデバイスに対して提供するステップを有し、
ユーザデバイスにおける実行ステップとして、
前記実行属性証明書に格納されたアドレス（Ａｄ）情報に従って、該ユーザデバイスのメモリから登録鍵を取得するステップと、
取得した登録鍵を適用して、該実行属性証明書に格納された暗号化実行命令の復号を実行するステップと、
復号結果に基づくデータ処理を実行するステップと、
を有することを特徴とするデータ処理権限管理方法にある。
【００３２】
さらに、本発明のデータ処理権限管理方法の一実施態様において、前記実行属性証明書は、前記暗号化実行命令および前記アドレス（Ａｄ）情報とを含む格納データに対する発行者電子署名を有し、前記ユーザデバイスは、前記実行属性証明書の電子署名検証処理を実行し、該検証の成立を条件として、前記アドレス（Ａｄ）情報に従った登録鍵の取得処理を実行することを特徴とする。
【００３３】
さらに、本発明のデータ処理権限管理方法の一実施態様において、前記データ処理権限管理方法において、ユーザデバイスに対する新たな実行属性証明書の発行処理は、実行属性証明書発行エンティテイが、実行属性証明書発行要求ユーザデバイスから、特定機器または特定ユーザの集合からなるグループに対応して設定されるグループ識別情報を格納情報として有し発行者電子署名を有するグループ属性証明書を受領し、該受領グループ属性証明書についての検証を実行し、該検証の成立を条件として実行することを特徴とする。
【００３４】
さらに、本発明のデータ処理権限管理方法の一実施態様において、前記データ処理権限管理方法は、さらに、前記サービスプロバイダにおける実行ステップとして、前記ユーザデバイスから登録鍵格納予定アドレス情報を取得するステップと、該登録鍵格納予定アドレス情報と、登録鍵の格納命令をユーザデバイスの取得可能な鍵を適用して暗号化した暗号化実行命令とを有するデータ部と、該データ部に対する電子署名を含む登録鍵生成実行属性証明書を生成して、ユーザデバイスに提供するステップとを有し、ユーザデバイスにおける実行ステップとして、前記電子署名の検証、前記登録鍵生成実行属性証明書に格納された暗号化実行命令の復号、および復号により取得した実行命令の処理により、登録鍵を前記登録鍵格納予定アドレスに対応するメモリ領域に格納する処理ステップと、を有することを特徴とする。
【００３５】
さらに、本発明のデータ処理権限管理方法の一実施態様において、前記データ処理権限管理方法において、さらに、前記ユーザデバイスにおける実行ステップとして、乱数に基づいて前記登録鍵を生成するステップを有することを特徴とする。
【００３６】
さらに、本発明のデータ処理権限管理方法の一実施態様において、前記ユーザデバイスは、さらに、前記登録鍵格納領域を指定したアドレス（Ａｄ）に対応するメモリ領域に、リセット鍵データを書き込むことにより登録鍵の破棄処理を実行することを特徴とする。
【００３７】
さらに、本発明のデータ処理権限管理方法の一実施態様において、前記実行属性証明書に格納された暗号化実行命令には、実行命令の適用可能回数識別値が格納され、前記ユーザデバイスは、実行命令の実行に応じて前記適用可能回数識別値を更新して、更新された適用可能回数識別値を含む新たな実行属性証明書の生成を行なうことを特徴とする。
【００３８】
さらに、本発明のデータ処理権限管理方法の一実施態様において、前記実行属性証明書に格納された暗号化実行命令には、実行命令の適用可能回数識別値が格納され、前記ユーザデバイスは、実行命令の実行に応じて前記適用可能回数識別値を更新して、更新された適用可能回数識別値が０となった場合に、前記登録鍵格納領域を指定したアドレス（Ａｄ）に対応するメモリ領域にリセット鍵データを書き込むことにより登録鍵の破棄処理を実行することを特徴とする。
【００３９】
さらに、本発明のデータ処理権限管理方法の一実施態様において、前記実行属性証明書に格納された暗号化実行命令は、他デバイスへの譲渡用実行属性証明書の生成処理命令を含み、前記ユーザデバイスは、前記譲渡用実行属性証明書の生成処理命令に従い、新たな譲渡用実行属性証明書の生成処理を実行し、他デバイスへの提供処理を実行することを特徴とする。
【００４０】
さらに、本発明のデータ処理権限管理方法の一実施態様において、前記実行属性証明書に格納された暗号化実行命令には、他デバイスの属性を証明する証明書としての審査代行属性証明書の発行処理命令、および該審査代行属性証明書の生成に必要とする署名生成用鍵を含み、前記ユーザデバイスは、前記審査代行属性証明書の発行処理命令に従い、前記署名生成用鍵を適用して署名を実行した審査代行属性証明書の生成処理を行い、他のサービス受領デバイスへの提供処理を実行する構成であることを特徴とする。
【００４１】
さらに、本発明のデータ処理権限管理方法の一実施態様において、前記審査代行属性証明書の生成を実行したユーザデバイスは、前記他のサービス受領デバイスへの前記審査代行属性証明書の提供に併せて、前記署名生成用鍵に対応する署名検証用鍵を格納し、発行者署名を有する代理署名鍵証明書を提供し、前記他のサービス受領デバイスは、サービス提供エンティテイに対して、前記審査代行属性証明書および、代理署名鍵証明書を提示し、前記サービス提供エンティテイは、前記代理署名鍵証明書から取得した署名検証用鍵に基づく前記審査代行属性証明書の検証処理を実行する構成であることを特徴とする。
【００４２】
さらに、本発明のデータ処理権限管理方法の一実施態様において、前記実行属性証明書に格納された暗号化実行命令には、他デバイスの属性を証明する証明書としての代理署名属性証明書の発行処理命令、および該代理署名属性証明書の生成に必要とする署名生成用鍵を含み、前記ユーザデバイスは、前記代理署名属性証明書の発行処理命令に従い、該代理署名属性証明書の検証を実行する検証デバイスから受領した検証用乱数（Ｒａ）を含み、前記署名生成用鍵を適用した署名を有する代理署名属性証明書の生成処理を行い、生成した前記代理署名属性証明書、および前記署名生成用鍵に対応する署名検証用鍵を格納し、発行者署名を有する代理署名鍵証明書を検証デバイスとしてのサービス提供エンティテイに提示する処理を実行し、前記サービス提供エンティテイは、前記代理署名鍵証明書から取得した署名検証用鍵に基づく、署名検証、および前記代理署名属性証明書の実行命令から抽出した乱数照合による前記代理署名鍵証明書の検証処理を実行することを特徴とする。
【００４３】
さらに、本発明の第４の側面は、
データ処理を実行する情報処理装置における情報処理方法であり、
暗号化処理のなされたデータ処理実行命令を含む暗号化実行命令と、該暗号化実行命令の復号処理に適用する登録鍵の情報処理装置内のメモリにおける格納領域を示すアドレス（Ａｄ）情報とを格納データとして有し発行者署名のなされた実行属性証明書を入力するステップと、
署名検証処理を実行するとともに、署名検証の成立を条件として、前記アドレス（Ａｄ）情報に従って、前記メモリから登録鍵を取得するステップと、
取得した登録鍵を適用して前記暗号化実行命令を復号するステップと、
復号された実行命令を実行するデータ処理ステップと、
を有することを特徴とする情報処理方法にある。
【００４４】
さらに、本発明の情報処理管理方法の一実施態様において、前記情報処理方法において、さらに、前記登録鍵格納領域を指定したアドレス（Ａｄ）に対応するメモリ領域に、リセット鍵データを書き込むことにより登録鍵の破棄処理を実行するステップを有することを特徴とする。
【００４５】
さらに、本発明の情報処理管理方法の一実施態様において、前記実行属性証明書に格納された暗号化実行命令には、実行命令の適用可能回数識別値が格納され、前記情報処理方法は、さらに、実行命令の実行に応じて前記適用可能回数識別値を更新して、更新された適用可能回数識別値を含む新たな実行属性証明書の生成を行なうことを特徴とする。
【００４６】
さらに、本発明の情報処理管理方法の一実施態様において、前記実行属性証明書に格納された暗号化実行命令には、実行命令の適用可能回数識別値が格納され、前記情報処理方法は、さらに、実行命令の実行に応じて前記適用可能回数識別値を更新して、更新された適用可能回数識別値が０となった場合に、前記登録鍵格納領域を指定したアドレス（Ａｄ）に対応するメモリ領域に、リセット鍵データを書き込むことにより登録鍵の破棄処理を実行することを特徴とする。
【００４７】
さらに、本発明の情報処理管理方法の一実施態様において、前記実行属性証明書に格納された暗号化実行命令は、他デバイスへの譲渡用実行属性証明書の生成処理命令を含み、前記情報処理方法は、さらに、前記譲渡用実行属性証明書の生成処理命令に従い、新たな譲渡用実行属性証明書の生成処理を実行し、他デバイスへの提供処理を実行することを特徴とする。
【００４８】
さらに、本発明の情報処理管理方法の一実施態様において、前記実行属性証明書に格納された暗号化実行命令には、他デバイスの属性を証明する証明書としての審査代行属性証明書の発行処理命令、および該審査代行属性証明書の生成に必要とする署名生成用鍵を含み、前記情報処理方法は、さらに、前記審査代行属性証明書の発行処理命令に従い、前記署名生成用鍵を適用して署名を実行した審査代行属性証明書の生成処理を実行することを特徴とする。
【００４９】
さらに、本発明の情報処理管理方法の一実施態様において、前記実行属性証明書に格納された暗号化実行命令には、他デバイスの属性を証明する証明書としての代理署名属性証明書の発行処理命令、および該代理署名属性証明書の生成に必要とする署名生成用鍵を含み、前記情報処理方法は、さらに、前記代理署名属性証明書の発行処理命令に従い、該代理署名属性証明書の検証を実行する検証デバイスから受領した検証用乱数（Ｒａ）を格納データとして含み、前記署名生成用鍵を適用した署名を有する代理署名属性証明書の生成処理を実行することを特徴とする。
【００５０】
さらに、本発明の第５の側面は、
データ処理を実行する情報処理装置における情報処理を実行せしめるコンピュータ・プログラムであって、
暗号化処理のなされたデータ処理実行命令を含む暗号化実行命令と、該暗号化実行命令の復号処理に適用する登録鍵の情報処理装置内のメモリにおける格納領域を示すアドレス（Ａｄ）情報とを格納データとして有し発行者署名のなされた実行属性証明書を入力するステップと、
署名検証処理を実行するとともに、署名検証の成立を条件として、前記アドレス（Ａｄ）情報に従って、前記メモリから登録鍵を取得するステップと、
取得した登録鍵を適用して前記暗号化実行命令を復号するステップと、
復号された実行命令を実行するデータ処理ステップと、
を有することを特徴とするコンピュータ・プログラムにある。
【００５１】
【作用】
本発明の構成によれば、暗号化処理のなされたデータ処理実行命令を含む暗号化実行命令と、暗号化実行命令の復号処理に適用する登録鍵のユーザデバイス内メモリの格納領域を示すアドレス（Ａｄ）情報とを格納データとして有する実行属性証明書をサービス受領デバイスであるユーザデバイスに対して提供し、ユーザデバイスにおいて、実行属性証明書に格納されたアドレス（Ａｄ）情報に従って、ユーザデバイスのメモリから取得した登録鍵を適用して、実行属性証明書に格納された暗号化実行命令の復号を行ない、復号結果に基づくデータ処理を実行する構成としたので、登録鍵を実行属性証明書に格納したアドレスに従って取得可能なユーザデバイスにおいてのみ実行属性証明書に格納した実行命令を実行することが可能となり、サービス利用権限を有するユーザに対して厳格に限定したサービスの提供が可能となる。
【００５２】
さらに、本発明の構成によれば、サービス提供実行属性証明書に適用する登録鍵の格納を登録鍵生成実行属性証明書に従って実行する構成としたので、不正な登録鍵の格納が防止され、不正なサービス受領を確実に防止できる。
【００５３】
さらに、本発明の構成によれば、リセット鍵の書き込みによる登録鍵の破棄処理を実行する構成としたので、不正な登録鍵の保持を防止することが可能となる。
【００５４】
さらに、本発明の構成によれば、実行命令内に適用可能回数識別値を格納し、実行命令の実行に応じて適用可能回数識別値を更新して、更新された適用可能回数識別値を含む新たな実行属性証明書の生成を行なう構成としたので、利用回数制限のあるサービスの受領を確実な回数制限の下に実行可能となる。
【００５５】
さらに、本発明の構成によれば、譲渡用実行属性証明書の生成処理命令、審査代行属性証明書の発行処理命令、代理署名属性証明書の発行処理命令等の各種の実行命令を実行属性証明書に格納することにより、様々な属性証明書の利用形態が実現される。
【００５６】
なお、本発明のコンピュータ・プログラムは、例えば、様々なプログラム・コードを実行可能なコンピュータ・システムに対して、コンピュータ可読な形式で提供する記憶媒体、通信媒体、例えば、ＣＤやＦＤ、ＭＯなどの記録媒体、あるいは、ネットワークなどの通信媒体によって提供可能なコンピュータ・プログラムである。このようなプログラムをコンピュータ可読な形式で提供することにより、コンピュータ・システム上でプログラムに応じた処理が実現される。
【００５７】
本発明のさらに他の目的、特徴や利点は、後述する本発明の実施例や添付する図面に基づくより詳細な説明によって明らかになるであろう。なお、本明細書においてシステムとは、複数の装置の論理的集合構成であり、各構成の装置が同一筐体内にあるものには限らない。
【００５８】
【発明の実施の形態】
以下、本発明について図面を参照して詳細に説明する。なお、以下、下記に示す項目順に説明する。
（１）権限管理システム構成概要
（２）ユーザデバイス構成
（３）グループ属性証明書発行、利用処理
（３−１）グループ属性証明書発行前準備処理
（３−２）グループ属性証明書発行処理
（３−３）グループ属性証明書利用処理
（４）ユーザデバイス間におけるグループ属性証明書の発行、利用処理
（５）グループ属性証明書の具体的利用例
（５−１）コンテンツ配信サービス
（５−２）リモートコントロールサービス
（５−３）リモートメンテナンスサービス
（５−４）パーソナルコミュニュケーションサービス
（６）実行属性証明書（実行ＡＣ）
（６−１）実行属性証明書概要
（６−２）実行属性証明書発行処理
（６−３）実行属性証明書適用処理
（６−４）登録鍵リセット処理
（６−５）実行属性証明書リセット（破棄）処理
（７）実行属性証明書の具体的利用処理
（７−１）回数制限付きサービス提供実行属性証明書
（７−２）譲渡機能付きサービス提供実行属性証明書
（７−３）代理発行実行属性証明書
（８）各エンティテイの構成
【００５９】
［（１）権限管理システム概要］
本発明の権限管理システムは、図１に示すように、公開鍵証明書（ＰＫＣ：ＰｕｂｌｉｃＫｅｙｃｅｒｔｉｆｉｃａｔｅ）１２１に基づく公開鍵基盤（ＰＫＩ：ＰｕｂｌｉｃＫｅｙｉｎｆｒａｓｔｒｕｃｔｕｒｅ）１０１、属性証明書（ＡＣ：Ａｔｔｒｉｂｕｔｅｃｅｒｔｉｆｉｃａｔｅ）１２２に基づく権限管理基盤（ＰＭＩ：ＰｒｉｖｉｌｅｇｅｍａｎａｇｅｍｅｎｔＩｎｆｒａｓｔｒｕｃｔｕｒｅ）１０２を基本インフラとし、これらのインフラの下で、耐タンパ性のセキュリティチップ（あるいはセキュリティモジュール）を持つユーザデバイス１１１、１１３およびサービスプロバイダ側のサービスプロバイダデバイス１１２間、あるいはユーザデバイス１１１、１１３相互間において権限確認処理を実行するとともに、権限確認に基づくサービス提供処理を実行する構成を持つ。
【００６０】
ユーザデバイス１１１，１１３は、例えば、サービスプロバイダ１１２から音楽、画像、プログラム等の各種コンテンツ提供サービス、その他の情報利用サービス、決済サービス等の各種サービスの提供を受領するユーザの端末であり、具体的には、ＰＣ、ゲーム端末、ＤＶＤ，ＣＤ等の再生装置、携帯通信端末、ＰＤＡ、メモリカード等である。
【００６１】
また、ユーザデバイス１１１，１１３は、ユーザデバイス相互間における通信処理が実行可能な端末であり、各ユーザデバイスに対するアクセス可否等の処理を権限確認に基づいて実行する。ユーザデバイスは、耐タンパ構成のセキュリティチップを搭載している。ユーザデバイスの詳細については後述する。
【００６２】
サービスプロバイダ１１２は、セキュリティチップを持つユーザデバイス１１１，１１３に対してコンテンツ提供、決済処理等の各種サービス提供を行なうサービスプロバイダである。図１には、ユーザデバイスを２つとサービスプロバイダを１つのみ示してあるが、公開鍵基盤（ＰＫＩ）１０１、権限管理基盤（ＰＭＩ）１０２のインフラの下には、多数のユーザデバイスおよびサービスプロバイダが存在し、それぞれが権限確認に基づくサービス提供を実行する。なお、サービスは、サービスプロバイダがユーザデバイスに対して提供するのみならず、ユーザデバイス間においても相互にサービスの提供が行なわれる。
【００６３】
（公開鍵証明書：ＰＫＣ）
次に、公開鍵基盤について説明する。公開鍵基盤（ＰＫＩ：ＰｕｂｌｉｃＫｅｙｉｎｆｒａｓｔｒｕｃｔｕｒｅ）１０１は、公開鍵証明書（ＰＫＣ：ＰｕｂｌｉｃＫｅｙｃｅｒｔｉｆｉｃａｔｅ）を適用して通信エンティテイ間の認証処理、あるいは転送データの暗号処理等を実行可能とした基盤（インフラ）である。（公開鍵証明書（ＰＫＣ））について図２，図３、図４を用いて説明する。公開鍵証明書は、認証局（ＣＡ：Ｃｅｒｔｉｆｉｃａｔｉｏｎ　Ａｕｔｈｏｒｉｔｙ）が発行する証明書であり、ユーザ、各エンティテイが自己のＩＤ、公開鍵等を認証局に提出することにより、認証局側が認証局のＩＤや有効期限等の情報を付加し、さらに認証局による署名を付加して作成される証明書である。
【００６４】
なお、認証局（ＣＡ）の事務代理機関として、登録局（ＲＡ：Ｒｅｇｉｓｔｒａｔｉｏｎ　Ａｕｔｈｏｒｉｔｙ）を設け、登録局（ＲＡ）において、公開鍵証明書（ＰＫＣ）の発行申請受理、申請者の審査、管理を行なう構成が一般的となっている。
【００６５】
公開鍵証明書のフォーマット例を図２〜図４に示す。これは、公開鍵証明書フォーマットＩＴＵ−Ｔ　Ｘ．５０９に準拠した例である。
【００６６】
バージョン（ｖｅｒｓｉｏｎ）は、証明書フォーマットのバージョンを示す。
シリアルナンバ（Ｓｅｒｉａｌ　Ｎｕｍｂｅｒ）は、公開鍵証明書の認証局（ＣＡ）によって設定される公開鍵証明書のシリアルナンバである。
シグネチャ（Ｓｉｇｎａｔｕｒｅ）は、証明書の署名アルゴリズムである。なお、署名アルゴリズムとしては、楕円曲線暗号およびＲＳＡがあり、楕円曲線暗号が適用されている場合はパラメータおよび鍵長が記録され、ＲＳＡが適用されている場合には鍵長が記録される。
発行者（ｉｓｓｕｅｒ）は、公開鍵証明書の発行者、すなわち公開鍵証明書発行局（ＩＡ）の名称が識別可能な形式（Ｄｉｓｔｉｎｇｕｉｓｈｅｄ　Ｎａｍｅ）で記録されるフィールドである。
有効期限（ｖａｌｉｄｉｔｙ）は、証明書の有効期限である開始日時、終了日時が記録される。
サブジェクト公開鍵情報（ｓｕｂｊｅｃｔ　Ｐｕｂｌｉｃ　Ｋｅｙ　Ｉｎｆｏ）は、証明書所有者の公開鍵情報として鍵のアルゴリズム、鍵が格納される。
【００６７】
証明局鍵識別子（ａｕｔｈｏｒｉｔｙ　Ｋｅｙ　Ｉｄｅｎｔｉｆｉｅｒ−ｋｅｙ　Ｉｄｅｎｔｉｆｉｅｒ、ａｕｔｈｏｒｉｔｙ　Ｃｅｒｔ　Ｉｓｓｕｅｒ、ａｕｔｈｏｒｉｔｙ　Ｃｅｒｔ　Ｓｅｒｉａｌ　Ｎｕｍｂｅｒ）は、署名検証に用いる証明書発行者の鍵を識別する情報であり、鍵識別子、機関証明書発行者の名称、機関証明書シリアル番号を格納する。
サブジェクト鍵識別子（ｓｕｂｊｅｃｔ　ｋｅｙ　Ｉｄｅｎｔｉｆｉｅｒ）は、複数の鍵を公開鍵証明書において証明する場合に各鍵を識別するための識別子を格納する。
鍵使用目的（ｋｅｙ　ｕｓａｇｅ）は、鍵の使用目的を指定するフィールドであり、（０）ディジタル署名用、（１）否認防止用、（２）鍵の暗号化用、（３）メッセージの暗号化用、（４）共通鍵配送用、（５）認証の署名確認用、（６）失効リストの署名確認用の各使用目的が設定される。
秘密鍵有効期限（ｐｒｉｖａｔｅ　Ｋｅｙ　Ｕｓａｇｅ　Ｐｅｒｉｏｄ）は、証明書に格納した公開鍵に対応する秘密鍵の有効期限を記録する。
認証局ポリシー（ｃｅｒｔｉｆｉｃａｔｅ　Ｐｏｌｉｃｉｅｓ）は、公開鍵証明書発行者の証明書発行ポリシーを記録する。例えばＩＳＯ／ＩＥＣ９３８４−１に準拠したポリシーＩＤ、認証基準である。
ポリシー・マッピング（ｐｏｌｉｃｙ　Ｍａｐｐｉｎｇ）は、認証パス中のポリシー関係の制限に関する情報を格納するフィールドであり、認証局（ＣＡ）証明書にのみ必要となる。
サブジェクト別名（ｓｕｂｊｅｃｔ　Ａｌｔ　Ｎａｍｅ）は、証明書所有者の別名を記録するフィールドである。
発行者別名（ｉｓｓｕｅｒ　Ａｌｔ　Ｎａｍｅ）は、証明書発行者の別名を記録するフィールドである。
サブジェクト・ディレクトリ・アトリビュート（ｓｕｂｊｅｃｔ　Ｄｉｒｅｃｔｏｒｙ　Ａｔｔｒｉｂｕｔｅ）は、証明書所有者のために必要とされるディレクトリの属性を記録するフィールドである。
基本制約（ｂａｓｉｃ　Ｃｏｎｓｔｒａｉｎｔ）は、証明対象の公開鍵が認証局（ＣＡ）の署名用か、証明書所有者のものかを区別するためのフィールドである。
許容サブツリー制約名（ｎａｍｅ　Ｃｏｎｓｔｒａｉｎｔｓ　ｐｅｒｍｉｔｔｅｄ　Ｓｕｂｔｒｅｅｓ）は、発行者が発行する証明書の名前の制限情報を格納するフィールドである。
制約ポリシー（ｐｏｌｉｃｙ　Ｃｏｎｓｔｒａｉｎｔｓ）は、認証パス中のポリシーの関係の制限情報を格納するフィールドである。
ＣＲＬ参照ポイント（Ｃｅｒｔｉｆｉｃａｔｅ　Ｒｅｖｏｃａｔｉｏｎ　Ｌｉｓｔ　Ｄｉｓｔｒｉｂｕｔｉｏｎ　Ｐｏｉｎｔｓ）は、証明書所有者が証明書を利用する際に、証明書が失効していないか、どうかを確認するための失効リストの参照ポイントを記述するフィールドである。
署名アルゴリズム（Ｓｉｇｎａｔｕｒｅ　Ａｌｇｏｒｉｔｈｍ）は、証明書の署名付けに用いるアルゴリズムを格納するフィールドである。
署名は、公開鍵証明書発行者の署名フィールドである。電子署名は、証明書全体に対しハッシュ関数を適用してハッシュ値を生成し、そのハッシュ値に対して発行者の秘密鍵を用いて生成したデータである。署名付けやハッシュをとるだけでは改竄は可能であるが、検出できれば実質的に改竄できないことと同様の効果がある。
【００６８】
認証局は、図２〜図４に示す公開鍵証明書を発行するとともに、有効期限が切れた公開鍵証明書を更新し、不正を行った利用者の排斥を行うための失効リスト（Ｒｅｖｏｃａｔｉｏｎ　Ｌｉｓｔ）の作成、管理、配布（これをリボケーション：Ｒｅｖｏｃａｔｉｏｎと呼ぶ）を行う。また、必要に応じて公開鍵・秘密鍵の生成も行う。
【００６９】
一方、この公開鍵証明書を利用する際には、利用者は自己が保持する認証局の公開鍵を用い、当該公開鍵証明書の電子署名を検証し、電子署名の検証に成功した後に公開鍵証明書から公開鍵を取り出し、当該公開鍵を利用する。従って、公開鍵証明書を利用する全ての利用者は、共通の認証局の公開鍵を保持している必要がある。
【００７０】
（属性証明書：ＡＣ）
権限管理基盤（ＰＭＩ：ＰｒｉｖｉｌｅｇｅｍａｎａｇｅｍｅｎｔＩｎｆｒａｓｔｒｕｃｔｕｒｅ）１０２は、属性証明書（ＡＣ：Ａｔｔｒｉｂｕｔｅｃｅｒｔｉｆｉｃａｔｅ）１２２を適用した権限確認処理を実行可能とする基盤（インフラ）である。属性証明書の１形態としてのグループ属性証明書（グループＡＣ）について図５乃至図７を参照して説明する。属性証明書の機能は、サービス利用権限の確認機能であり、属性証明書には、例えばサービスプロバイダの提供するコンテンツ、あるいはサービスの利用権といった権利関連情報や権限に関する所有者の属性情報が記述される。
【００７１】
属性証明書は、基本的には属性認証局（ＡＡ：Ａｔｔｒｉｂｕｔｅ　Ａｕｔｈｏｒｉｔｙ）が発行する証明書であり、証明書発行対象の属性情報を格納し、属性認証局側がＩＤや有効期限等の情報を付加し、さらに属性認証局の秘密鍵による署名を付加して作成される証明書である。ただし、以下において説明するグループ属性証明書、実行属性証明書は、必ずしも属性認証局（ＡＡ：Ａｔｔｒｉｂｕｔｅ　Ａｕｔｈｏｒｉｔｙ）が発行機関として限定されるものではなく、サービスプロバイダ、ユーザデバイスにおける発行処理が可能である。
【００７２】
なお、属性認証局（ＡＡ）の事務代理機関として、属性証明書登録局（ＡＲＡ：Ａｔｔｒｉｂｕｔｅ　Ｒｅｇｉｓｔｒａｔｉｏｎ　Ａｕｔｈｏｒｉｔｙ）を設け、属性証明書登録局（ＡＲＡ）において、属性証明書（ＡＣ）の発行申請受理、申請者の審査、管理を行なう構成により、処理負荷の分散が可能である。
【００７３】
本発明の構成において適用されるグループ属性証明書（グループＡＣ）は、複数の対象、例えば複数のユーザ、あるいは複数のユーザ機器を１つの同一属性集合としたグループとして設定し、設定したグループを単位として、グループの構成機器または構成ユーザに対して発行される属性証明書である。グループ属性証明書は、特定機器または特定ユーザの集合からなるグループに対応して設定されるグループ識別情報を格納情報とするとともに発行者の電子署名の付加された証明書である。
【００７４】
例えば複数人が所属している会社、組織、学校といった属性、あるいは家族といったグループに属する各ユーザまたはユーザ機器に対して発行される。あるいは、１つのサービスプロバイダの提供するサービスを受領する複数のユーザ単位といったグループのメンバ（ユーザ、ユーザ機器）に対して発行される。グループについては、様々な設定が可能であり、具体例については、後述する。
【００７５】
なお、後段で説明する実行属性証明書は、暗号化処理のなされたデータ処理実行命令を含む暗号化実行命令と、該暗号化実行命令の復号処理に適用する登録鍵のユーザデバイス内メモリの格納領域を示すアドレス（Ａｄ）情報とを格納データとして有する。実行属性証明書の詳細については、後段で詳細に説明する。
【００７６】
属性証明書の基本フォーマットはＩＴＵ−Ｔ　Ｘ．５０９で規定されており，ＩＥＴＦ　ＰＫＩＸ　ＷＧでＰｒｏｆｉｌｅを策定している。公開鍵証明書とは異なり所有者の公開鍵を含まない。しかし属性認証局（Ａｔｔｒｉｂｕｔｅ　Ｃｅｒｔｉｆｉｃａｔｅ　Ａｕｔｈｏｒｉｔｙ）の署名がついているため、改竄されていないかどうかの判定はこの署名を検証することで行える、という点は公開鍵証明書と同様である。
【００７７】
なお、本発明において適用するグループ属性証明書、あるいは実行属性証明書は、属性証明書の基本フォーマットに準拠したものとして構成可能である。ただし、ＩＴＵ−Ｔ　Ｘ．５０９で規定されたフォーマットに従うことが必須ではなく、独自フォーマットとした属性証明書構成としてもよい。
【００７８】
本発明の構成においては、属性証明書（ＡＣ）の発行管理を行なう属性認証局（ＡＡ：Ａｔｔｒｉｂｕｔｅ　Ｃｅｒｔｉｆｉｃａｔｅ　Ａｕｔｈｏｒｉｔｙ）、および属性証明書登録局（ＡＲＡ）の機能を、サービスプロバイダ、あるいはユーザデバイスが兼務することが可能である。すなわち、サービスプロバイダあるいはユーザデバイス自身が、属性認証局（ＡＡ）、属性証明書登録局（ＡＲＡ）の各機能を果たす構成が可能である。
【００７９】
属性証明書は基本的に公開鍵証明書と関連づけて利用する。すなわち属性証明書所有者の本人性自体は公開鍵証明書で確認し、その上で所有者にいかなる権限が与えられているかを属性証明書によって確認する。例えばサービスプロバイダがユーザ、あるいはユーザ機器に対するサービスを提供する際、サービスを受領する権利を有するか否かを属性証明書を検証して確認する。属性証明書の検証にあたっては、当該証明書の署名検証を行った後、その属性証明書に関連づけられている公開鍵証明書の検証も行う。
【００８０】
なお、その際、原則的には証明書連鎖をたどって最上位の公開鍵証明書まで順に検証を実施することが好ましい。複数の認証局（ＣＡ）が存在し、階層構成をなす認証局構成では、下位の認証局自身の公開鍵証明書は、その公開鍵証明書を発行する上位認証局によって署名されている。すなわち、下層の認証局（ＣＡ−Ｌｏｗ）に対して上位の認証局（ＣＡ−Ｈｉｇｈ）が公開鍵証明書を発行するという連鎖的な公開鍵証明書発行構成をとる。公開鍵証明書の連鎖検証とは、下位から上位へ証明書連鎖をたどって最上位の公開鍵証明書までの連鎖情報を取得して、最上位（ル−トＣＡ）までの公開鍵証明書の署名検証を行なうことを意味する。
【００８１】
属性証明書の有効期間を短期間とすることにより、失効処理を行わないことも可能である。この場合、証明書の失効手続きや失効情報の参照手順等を省くことができ、システムが簡易となる長所がある。ただし証明書の不正利用に対しては失効以外の何らかの対策が必要となるため、十分に注意しなければならない。
【００８２】
図５を参照してグループ属性証明書の構成について説明する。
証明書のバージョン番号は、証明書フォーマットのバージョンを示す。
ＡＣ保持者の公開鍵証明書情報、これは属性証明書（ＡＣ）の発行者に対応する公開鍵証明書（ＰＫＣ）に関する情報であり、ＰＫＣ発行者名、ＰＫＣシリアル番号、ＰＫＣ発行者固有識別子等の情報であり、対応公開鍵証明書を関連づけるリンクデータとしての機能を持つ。
属性証明書の発行者の名前は、属性証明書の発行者、すなわち属性認証局（ＡＡ）の名称が識別可能な形式（Ｄｉｓｔｉｎｇｕｉｓｈｅｄ　Ｎａｍｅ）で記録されるフィールドである。
署名アルゴリズム識別子は、属性証明書の署名アルゴリズム識別子を記録するフィールドである。
証明書の有効期限は、証明書の有効期限である開始日時、終了日時が記録される。
属性情報フィールドには、グループ属性証明書のグループを識別するグループ識別情報としてグループＩＤが格納される。グループＩＤは、このグループ属性証明書を利用した権限確認を行なうサービスプロバイダの有するサービスプロバイダ（ＳＰ）管理グループ情報データベース（図５右下欄参照）のエントリと対応する識別子（ＩＤ）である。
【００８３】
サービスプロバイダの有するサービスプロバイダ（ＳＰ）管理グループ情報データベースは、図５右下欄に示すように、例えば、グループ属性証明書の発行者（ＡＲＡ）と、グループ識別子としてのグループ識別情報（グループＩＤ）、および「Ａ者の社員」、「Ｂさんの家族」といったグループ情報を対応付けたテーブルである。サービスプロバイダは、グループ証明書に基づく権限確認処理において、証明書格納データとしてのグループ識別情報（グループＩＤ）に基づいてテーブルから対応エントリを抽出し、グループ情報を含むグループ属性証明書情報を取得する。
【００８４】
なお、属性情報フィールドには、グループ識別情報（グループＩＤ）以外にも、様々な情報が格納可能であり、例えば、コンテンツ利用期限等のコンテンツ利用制限情報、サービス利用制限情報等の権限に関する詳細情報、さらにはサービスプロバイダ識別子（ＩＤ）、サービスプロバイダ・ネーム等の各種情報を格納することが可能である。また、詳細は、後述するが、暗号化コンテンツの復号に適用するコンテンツ鍵を取得するために必要となる情報を格納するフィールドとしての適用も可能である。
【００８５】
サービスプロバイダは、グループ属性証明書をユーザデバイスに対して送付し、ユーザデバイスは属性証明書の検証の後、自己のセキュリティチップ内のメモリに格納する。
【００８６】
属性証明書には、さらに、署名アルゴリズムが記録され、属性証明書発行者、例えば属性認証局（ＡＡ）によって署名が施される。発行者がサービスプロバイダ、あるいはユーザデバイスである場合は、各発行者の署名がなされる。電子署名は、属性証明書全体に対しハッシュ関数を適用してハッシュ値を生成し、そのハッシュ値に対して属性証明書発行者の秘密鍵を用いて生成したデータである。
【００８７】
図６にグループ属性証明書（グループＡＣ）の発行者、所有者、検証者、属性情報の構成例を示す。例えば同一の会社、あるいは１つの家族に属するユーザの所有する複数のユーザ機器グループの各々に対してグループ属性証明書が発行される場合、発行されたグループ属性証明書は、ユーザの所有する機器内のセキュリティチップ（ＳＣ：Ｓｅｃｕｒｉｔｙ　Ｃｈｉｐ、あるいはＵＳＣ：Ｕｓｅｒ　Ｓｅｃｕｒｉｔｙ　Ｃｈｉｐ）に格納される。ユーザデバイスの詳細については後述する。
【００８８】
ユーザデバイスに対して発行されたグループ属性証明書に基づいて権限確認を実行する検証者は、サービス提供エンティテイ、例えばサービスプロバイダの機器内のセキュリティモジュール（ＳＭ：Ｓｅｃｕｒｉｔｙ　Ｍｏｄｕｌｅ）、あるいはユーザデバイスのセキュリティチップ（ＳＣ：Ｓｅｃｕｒｉｔｙ　Ｃｈｉｐ）である。なお、ユーザデバイスのセキュリティチップ、サービスプロバイダの機器内のセキュリティモジュールは、外部からのデータ読み出しの制限された耐タンパ構成を持つことが好ましい。
【００８９】
グループ属性証明書には、例えば同一の会社、あるいは１つの家族等を識別可能な識別情報としてのグループ識別情報（グループＩＤ）を属性情報として有することとなる。
【００９０】
図７にグループ属性証明書の発行ポリシーテーブルの構成例を示す。グループ属性証明書の発行ポリシーテーブルは、グループ属性証明書を発行するエンティテイ、例えば属性認証局（ＡＡ：Ａｔｔｒｉｂｕｔｅ　Ｃｅｒｔｉｆｉｃａｔｅ　Ａｕｔｈｏｒｉｔｙ）、属性認証局（ＡＡ）の事務代行を行なう属性証明書登録局（ＡＲＡ：Ａｔｔｒｉｂｕｔｅ　Ｒｅｇｉｓｔｒａｔｉｏｎ　Ａｕｔｈｏｒｉｔｙ）、あるいはサービスプロバイダ、ユーザデバイスにおいて管理されるテーブルであり、発行したグループ属性証明書のグループ識別情報（グループＩＤ）、グループ情報、発行基準等の発行ポリシーとを対応付けたテーブルである。例えば、グループ属性証明書の新規発行、追加発行、更新処理等に際し、グループ属性証明書の発行ポリシーテーブルに基づいて、審査が実行され、ポリシーを満足する場合に限り、発行、更新等の手続きがなされる。
【００９１】
図８に権限管理システムに参加する各エンティテイの信頼関係構成を説明するトラストモデルを示す。
【００９２】
システムホルダ（ＳＨ：Ｓｙｓｔｅｍ　Ｈｏｌｄｅｒ）１３０は、本発明の権限管理システム全体の統括的管理を行なう主体、すなわちシステム運用主体であり、システムに参加する各エンティテイのセキュリティチップ（ＳＣ）、セキュリティモジュール（ＳＭ）の正当性を保証するとともに、公開鍵証明書（ＰＫＣ）の発行責任を持つ。システムホルダ（ＳＨ）１３０は、最上位認証局としてのルートＣＡ（ＲｏｏｔＣＡ）１３１、階層構成の複数の認証局（ＣＡ）１３２、および公開鍵証明書発行事務局としての登録局（ＲＡ）１３３を有する。
【００９３】
システムホルダ（ＳＨ：Ｓｙｓｔｅｍ　Ｈｏｌｄｅｒ）１３０は、属性認証局（ＡＡ）１４０、属性証明書登録局（ＡＲＡ）１５０、サービスプロバイダ１６０、およびユーザデバイス１７０としてのユーザ識別デバイス（ＵＩＤ：Ｕｓｅｒ　Ｉｄｅｎｔｉｆｉｃａｔｉｏｎ　Ｄｅｖｉｃｅ）１７１、エンドエンティテイ（ＥＥ：Ｅｎｄ　Ｅｎｔｉｔｙ）１７２の各エンティテイに対応する公開鍵証明書（ＰＫＣ）を発行し、各エンティテイは、必要とするエンティテイの公開鍵証明書をそれぞれの機器内の耐タンパ構成を持つセキュリティチップ（ＳＣ）またはセキュリティモジュール（ＳＭ）、もしくは、場合によっては外部の記憶装置に公開鍵証明書（ＰＫＣ）を格納する。
【００９４】
また、グループ属性証明書（グループＡＣ）は、サービスプロバイダ１６０、およびユーザデバイス１７０としてのユーザ識別デバイス（ＵＩＤ：Ｕｓｅｒ　Ｉｄｅｎｔｉｆｉｃａｔｉｏｎ　Ｄｅｖｉｃｅ）１７１、エンドエンティテイ（ＥＥ：Ｅｎｄ　Ｅｎｔｉｔｙ）１７２の各エンティテイ等からの属性証明書発行要求を、例えば属性証明書登録局（ＡＲＡ）１５０において受領し、先に図７を参照して説明したポリシーテーブル１５１のポリシー（発行条件等）に従って属性証明書発行審査を行ない、発行可と判定された場合に属性認証局（ＡＡ）１４０に対して、属性証明書登録局（ＡＲＡ）１５０から発行依頼を転送する。
【００９５】
属性認証局（ＡＡ）１４０は、グループ属性証明書発行依頼に基づいて、グループ識別情報（グループＩＤ）を属性情報として格納し、属性認証局（ＡＡ）１４０の秘密鍵による署名を付加したグループ属性証明書（図５参照）を発行要求者に対して発行する。
【００９６】
なお、前述したように、これら属性認証局（ＡＡ）１４０、および属性証明書登録局（ＡＲＡ）１５０は、サービスプロバイダ、あるいはユーザデバイスがその機能を実行する構成とすることも可能である。
【００９７】
［（２）ユーザデバイス構成］
次にサービスを利用する情報処理装置としてのユーザデバイスの構成について説明する。ユーザデバイスは、その機能に基づいて、２つのカテゴリに分類される。一方はサービスを実際に利用する機器としてのエンドエンティテイ（ＥＥ）であり、サービスプロバイダの提供するサービス情報を受領するインタフェースを持つ例えばＰＣ、ホームサーバ、ＰＤＡ等の携帯端末、ＩＣカード等、各種データ処理装置である。これらの機器は、耐タンパ構成を持つセキュリティチップ（ＳＣ）またはモジュール（ＳＭ）を有し、機器対応の公開鍵証明書、機器対応のグループ属性証明書が必要に応じて格納される。
【００９８】
もう一方は、個人認証処理に適用するデバイスとしてのユーザ識別デバイス（ＵＩＤ）である。ユーザ識別デバイス（ＵＩＤ）もエンドエンティテイと同様の機器によって構成されるが、サービスプロバイダの提供するサービス情報を直接受領するためのインタフェースを必ずしも有することのない機器である。サービスプロバイダ機器との通信は、エンドエンティテイ（ＥＥ）を介して実行する。ユーザ識別デバイス（ＵＩＤ）は、ユーザの認証に適用される機器である。これらの機器は、耐タンパ構成を持つセキュリティチップ（ＳＣ）またはセキュリティモジュール（ＳＭ）を有し、ユーザ対応の公開鍵証明書、機器対応のグループ属性証明書が必要に応じて格納される。
【００９９】
なお、エンドエンティテイ（ＥＥ）とユーザ識別デバイス（ＵＩＤ）は個別の機器としてそれぞれ構成することも可能であるが、１つの機器内に両機能を備えた構成とすることも可能である。
【０１００】
個別の構成具体例としては、例えばＩＣカード等の機器をユーザ識別デバイス（ＵＩＤ）として構成し、エンドエンティテイ（ＥＥ）をＰＣとした構成がある。この構成では、ＩＣカードをＰＣにデータ転送可能な状態にセットし、まずＩＣカードとサービスプロバイダ間との通信をＰＣを介して実行して公開鍵証明書、グループ属性証明書を適用したユーザ認証、ユーザ権限確認処理を実行し、さらにこれらの処理の後にエンドエンティテイとしてのＰＣとサービスプロバイダ間での認証、権限確認を行なう等の処理が実行可能となる。これらの権限確認処理の詳細については、後述する。
【０１０１】
ユーザデバイスとしてのエンドエンティテイ（ＥＥ）とユーザ識別デバイス（ＵＩＤ）に構成されるセキュリテイチップの構成例について、図９を参照して説明する。なお、エンドエンティテイ（ＥＥ）は、データ処理手段としてのＣＰＵ、通信機能を備えた例えばＰＣ、ゲーム端末、携帯端末、ＰＤＡ、ＩＣカード（メモリカード）、ＤＶＤ，ＣＤ等の再生装置、記録再生装置等によって構成され、耐タンパ構造を持つセキュリティチップ（ＳＣ）が実装される。
【０１０２】
図９に示すように、エンドエンティテイ（ＥＥ）またはユーザ識別デバイス（ＵＩＤ）により構成されるユーザデバイス２００には、セキュリティチップ２１０が、ユーザデバイス側制御部２２１に対して、相互にデータ転送可能な構成として内蔵される。
【０１０３】
セキュリティチップ２１０は、プログラム実行機能、演算処理機能を持つＣＰＵ（Ｃｅｎｔｒａｌ　Ｐｒｏｃｅｓｓｉｎｇ　Ｕｎｉｔ）２０１を有し、データ通信用のインタフェース機能を持つ通信インタフェース２０２、ＣＰＵ２０１によって実行される各種プログラム、例えば暗号処理プログラムなどを記憶するＲＯＭ（Ｒｅａｄ　Ｏｎｌｙ　Ｍｅｍｏｒｙ）２０３、実行プログラムのロード領域、また、各プログラム処理におけるワーク領域として機能するＲＡＭ（Ｒａｎｄｏｍ　Ａｃｃｅｓｓ　Ｍｅｍｏｒｙ）２０４、外部機器との認証処理、電子署名の生成、検証処理、格納データの暗号化、復号化処理等の暗号処理を実行する暗号処理部２０５、サービスプロバイダ毎の情報、各種鍵データを含むデバイスの固有情報を格納した例えばＥＥＰＲＯＭ（Ｅｌｅｃｔｒｉｃａｌｌｙ　Ｅｒａｓａｂｌｅ　Ｐｒｏｇｒａｍｍａｂｌｅ　ＲＯＭ）によって構成されるメモリ部２０６を有する。
【０１０４】
ユーザデバイス２００は、暗号化コンテンツあるいはサービス情報等を格納する領域としてのＥＥＰＲＯＭ、ハードディスク等によって構成される外部メモリ部２２２を有する。外部メモリ部２２２は、公開鍵証明書、グループ属性証明書の格納領域としても利用可能である。
【０１０５】
セキュリティチップを搭載したユーザデバイスが、外部エンティテイ、例えばサービスプロバイダと接続し、データ転送処理を実行する場合には、ネットワークインタフェース２３２を介したサービスプロバイダとの接続を実行する。ただし、前述したようにサービスプロバイダとの接続を実行するインタフェースを有するのは、エンドエンティテイ（ＥＥ）であり、ユーザ識別デバイス（ＵＩＤ）は、必ずしもネットワークインタフェース２３２を持つとは限らないので、ユーザ識別デバイス（ＵＩＤ）の接続機器インタフェース２３１を介してエンドエンティテイ（ＥＥ）の接続機器インタフェース２３１に接続し、エンドエンティテイのネットワークインタフェース２３２を介した通信を実行する。
【０１０６】
すなわち、ユーザ識別デバイス（ＵＩＤ）は、エンドエンティテイを介してサービスプロバイダの機器との通信を実行する。
【０１０７】
エンドエンティテイ（ＥＥ）、ユーザ識別デバイス（ＵＩＤ）等のユーザデバイスのセキュリティチップ２１０とサービスプロバイダ間でデータ転送を実行する場合には、必要に応じて、セキュリティチップ２１０と、外部エンティテイ間の相互認証が行われ、また転送データの暗号化が行なわれる。これらの処理の詳細については、後段で詳述する。
【０１０８】
ユーザデバイスのセキュリティチップの格納データ例を図１０に示す。これらの多くは、不揮発性メモリの一形態であるフラッシュメモリ等のＥＥＰＲＯＭ（Ｅｌｅｃｔｒｉｃａｌｌｙ　Ｅｒａｓａｂｌｅ　Ｐｒｏｇｒａｍｍａｂｌｅ　ＲＯＭ）によって構成されるメモリ部２０６に格納されるが、公開鍵証明書、グループ属性証明書、あるいは後述する実行属性証明書は、セキュリティチップ内のメモリに格納しても、外部メモリに格納してもよい。
【０１０９】
各データについて説明する。
公開鍵証明書（ＰＫＣ）：公開鍵証明書は、第三者に対して正当な公開鍵であることを示す証明書で、証明書には配布したい公開鍵を含み、信頼のおける認証局により電子署名がなされている。ユーザデバイスには、前述した階層構成の最上位認証局（ルートＣＡ）の公開鍵証明書、ユーザデバイスに対するサービスを提供するサービスプロバイダの公開鍵証明書等、ユーザデバイスとのデータ通信を実行する際の認証、暗号化、復号処理等に適用する公開鍵を取得するために必要となる公開鍵証明書が格納される。
【０１１０】
グループ属性証明書（ＡＣ）：公開鍵証明書が証明書利用者（所有者）の“本人性”を示すのに対し、グループ属性証明書は証明書利用者のグループを識別しグループの構成メンバに付与された利用権限を確認するものである。利用者はグループ属性証明書を提示することにより、グループ属性証明書に記載された権利・権限情報に基づいて、サービス利用が行えるようになる。なお、グループ属性証明書は所定の発行手続きに基づいて発行されグループ属性証明書を受領した各エンティテイは、機器内の耐タンパ構成を持つセキュリティチップ（ＳＣ）またはセキュリティモジュール（ＳＭ）、もしくは、場合によっては外部の記憶装置に格納する。発行、格納処理の詳細は後述する。
【０１１１】
実行属性証明書：暗号化処理のなされたデータ処理実行命令を含む暗号化実行命令と、該暗号化実行命令の復号処理に適用する登録鍵のユーザデバイス内メモリの格納領域を示すアドレス（Ａｄ）情報とを格納データとして有する属性証明書であり、アドレス情報に基づいてユーザデバイス内メモリから取得する登録鍵を適用して暗号化実行命令を復号して実行命令を取得し、実行命令を実行することで各種サービスが実行される。これらの処理の詳細は後述する。
【０１１２】
鍵データ：鍵データとしては、セキュリティチップに対して設定される公開鍵、秘密鍵のペア、上述した実行属性証明書に格納された暗号化実行命令を復号する際に適用する登録鍵、登録鍵の破棄（リセット）処理に適用するリセット鍵、さらに、乱数生成用鍵、相互認証用鍵等が格納される。なお、登録鍵の格納領域は、あらかじめ決められたアドレスによって決定されるメモリ領域に格納される。登録鍵、リセット鍵については、後段で詳細に説明する。
【０１１３】
識別情報：識別情報としては、セキュリティチップ自身の識別子としてのセキュリティチップＩＤが格納される。さらに継続的なサービス提供を受けるサービスプロバイダ（ＳＰ）の識別子としてのサービスプロバイダＩＤ、ユーザデバイスを利用するユーザに付与されたユーザＩＤ、サービスプロバイダの提供するサービスに対応するアプリケーションを識別するアプリケーションＩＤ等が格納可能である。
【０１１４】
その他：ユーザデバイスには、さらに、乱数生成用のシード情報、すなわち認証処理、暗号処理等の際に適用する乱数をＡＮＳＩ　Ｘ９．１７に従って生成するための情報や、様々な利用制限が付加されたサービスに関する利用情報、例えば、コンテンツ利用回数制限が付加されたコンテンツを利用した際に更新されるコンテンツ利用回数情報、あるいは決済情報等の情報、あるいは、各情報に基づいて算出されるハッシュ値が格納される。
【０１１５】
なお、図１０に示すデータ構成例は、一例であり、この他にも必要に応じて、ユーザデバイスの受領するサービスに関連する各種の情報が格納可能である。
【０１１６】
なお、例えばサービス提供側のサービスプロバイダ側の有するセキュリティチップ、あるいはセキュリティモジュールも図９に示すユーザデバイスにおけるセキュリティチップ構成と同様の構成によって実現可能であり、以下に説明するグループ属性証明書の検証処理、生成処理、あるいは実行属性証明書の検証処理、生成処理の各実行手段として機能する。例えば、データ送受信部であるネットワークインタフェースを介して受信したグループ属性証明書あるいは実行属性証明書の検証処理の実行、あるいは、グループ属性証明書あるいは実行属性証明書の生成処理の実行手段として、図９に示すセキュリティチップとと同様の構成が適用可能である。
【０１１７】
［（３）グループ属性証明書発行、利用処理］
次に、同一の学校、会社等の組織、あるいは１つの家族等、様々な集合に属するユーザ、あるいは、同一メーカの機器、同一サービスプロバイダのサービスを受領するユーザ、機器等、複数のユーザまたは機器をグループとして設定し、グループに属するユーザまたは機器の各々に対して発行するグループ属性証明書の発行処理、および利用処理について説明する。
【０１１８】
グループ属性証明書は、サービスを受けようとするユーザまたは機器（ユーザデバイス）が特定のグループに属することを確認可能な証明書であり、サービス受領時等に、サービス提供エンティテイ、例えばサービスプロバイダに提示する。サービスプロバイダは、提示されたグループ属性証明書の検証処理を実行して、ユーザまたはユーザデバイスが特定のグループに属することが確認されたことを条件としてサービスを提供する。
【０１１９】
グループ属性証明書は、特定機器または特定ユーザの集合からなるグループに対応して設定されるグループ識別情報を格納情報とするとともに発行者の電子署名を有する証明書である。
【０１２０】
図１１にグループ属性証明書の発行申請、発行処理、利用処理の流れの概略を説明する図を示す。グループ属性証明書に基づいたグループ所属証明の確認を条件としたサービス提供を行なうサービスプロバイダ３１４の提供するサービスを受領しようとするユーザデバイス３１１、すなわちセキュリティチップを有するエンドエンティテイ（ＥＥ）またはユーザ識別デバイス（ＵＩＤ）は、まず、グループ属性証明書の発行エンティテイに発行要求を行なう。例えば、属性証明書登録局（ＡＲＡ：Ａｔｔｒｉｂｕｔｅ　Ｒｅｇｉｓｔｒａｔｉｏｎ　Ａｕｔｈｏｒｉｔｙ）３１２にグループ属性証明書の発行申請を行なう。
【０１２１】
属性証明書登録局（ＡＲＡ）３１２は、発行申請に基づいて、発行ポリシーテーブル３１３を参照し、ポリシーを満足する場合には、属性認証局（ＡＡ：Ａｔｔｒｉｂｕｔｅ　Ｃｅｒｔｉｆｉｃａｔｅ　Ａｕｔｈｏｒｉｔｙ）に対して属性証明書の発行を依頼し、属性認証局（ＡＡ）の発行したグループ属性証明書３１６をユーザデバイス３１１に送信する。
【０１２２】
グループ属性証明書３１６には、グループ識別子としてのグループＩＤが、属性情報フィールドに格納される（図５参照）。ユーザデバイス３１１は、サービスプロバイダ３１４の提供するサービス、例えばコンテンツ配信、決済処理等の何らかのサービスを受領する際に、グループ属性証明書３１６をサービスプロバイダ３１４に提示する。サービスプロバイダ３１４は、グループ属性証明書の検証処理、グループ情報データベース３１５の参照により、サービス提供を要求してきたユーザデバイス３１１がサービスを受領する権限を有するか否かを判定して、権限ありと判断した場合には、ユーザデバイス３１１に対するサービス提供を実行する。
【０１２３】
以下、グループ属性証明書発行、利用処理について、
（３−１）グループ属性証明書発行前準備処理
（３−２）グループ属性証明書発行処理
（３−３）グループ属性証明書利用処理
以上、３項目について、順次説明する。
【０１２４】
（３−１）グループ属性証明書発行前準備処理
まず、グループ属性証明書発行前準備処理について説明する。先に説明したように、グループ属性証明書は、基本的に属性認証局（ＡＡ）が発行し、属性証明書登録局（ＡＲＡ）が属性証明書発行要求エンティテイからの発行要求を受理し、ポリシー審査等を実行して、発行可と判定した後、属性認証局（ＡＡ）に属性証明書発行要求を転送し、属性認証局（ＡＡ）の発行した属性証明書を属性証明書登録局（ＡＲＡ）を介して、発行要求エンティテイに対して送付する処理構成が通常のスタイルである。ただし、以下、説明するように、サービスプロバイダ（ＳＰ）、ユーザデバイスにおいて、それぞれのポリシーの下に発行することも可能である。
【０１２５】
本発明のグループ属性証明書は、識別可能なグループ、例えば家族、学校、会社、あるいは特定のメーカーの機器等、何らかのグループを特定した上で、そのグループ構成メンバ（機器またはユーザ）に対して発行するものであり、一方、サービスを提供するサービスプロバイダは、サービスを要求してきたユーザまたは機器が、特定のグループに属するか否かをグループ属性証明書に基づいて判定する。従って、グループ属性証明書の発行処理実行エンティテイと、グループ属性証明書に基づく権限確認（検証処理）を実行しサービスを提供するエンティテイは、グループ属性証明書に対応して定義されるグループについて共通の認識を持つことが必要な場合、グループ属性証明書に対応して定義されるグループに関する情報、すなわちグループ情報を、グループ属性証明書発行エンティテイと、サービス提供エンティテイとが共有化する処理がグループ属性証明書発行前準備処理として必要となる。
【０１２６】
以下、グループ属性証明書発行エンティテイを属性認証局（ＡＡ）または属性証明書登録局（ＡＲＡ）とし、サービス提供エンティテイをサービスプロバイダ（ＳＰ）とした場合のグループ情報共有化処理について、図１２を参照して説明する。
【０１２７】
なお、以下に説明する例では、属性認証局（ＡＡ）と属性証明書登録局（ＡＲＡ）は信頼関係にあり、属性証明書登録局（ＡＲＡ）がグループ属性証明書の発行審査を行ない、属性証明書登録局（ＡＲＡ）の審査結果に基づいて、属性認証局（ＡＡ）がグループ属性証明書の発行処理を行なう構成を例として説明する。従って、グループ情報の共有エンティテイは、サービスプロバイダ（ＳＰ）と属性証明書登録局（ＡＲＡ）の２つのエンティテイとなる。
【０１２８】
図１２に示す処理シーケンス図に従ってサービスプロバイダ（ＳＰ）と属性証明書登録局（ＡＲＡ）のグループ情報共有処理について説明する。
【０１２９】
まずステップＳ１０１において、サービスプロバイダ（ＳＰ）とグループ属性証明書の発行審査を実行する属性証明書登録局（ＡＲＡ）との間で相互認証処理が実行される。なお、グループ属性証明書の発行審査を行なう属性証明書登録局（ＡＲＡ）を、以下、グループ属性証明書登録局（ＡＲＡ）とする。
【０１３０】
サービスプロバイダ（ＳＰ）とグループ属性証明書登録局（ＡＲＡ）との間で実行される相互認証は、データ送受信を実行する２つのエンティテイ間で相互に相手が正しいデータ通信者であるか否かの確認のために実行される処理である。認証成立を条件として必要なデータ転送を行なう。また、相互認証処理時にセッション鍵の生成を実行して、生成したセッション鍵を共有鍵として、その後は、セッション鍵に基づく暗号化処理を施したデータ転送を行なう構成が好ましい。相互認証方式としては、公開鍵暗号方式、共通鍵暗号方式等、各方式の適用が可能である。
【０１３１】
ここでは、公開鍵暗号方式の１つの認証処理方式であるハンドシェイクプロトコル（ＴＬＳ１．０）について図１３のシーケンス図を参照して説明する。
【０１３２】
図１３において、エンティテイＡ（クライアント）、エンティテイＢ（サーバ）が、通信を実行する２エンティテイであり、ここではサービスプロバイダ（ＳＰ）またはグループ属性証明書登録局（ＡＲＡ）に対応する。まず、（１）エンティテイＢが暗号化仕様を決定するためのネゴシエーション開始要求をハローリクエストとしてエンティテイＡに送信する。（２）エンティテイＡはハローリクエストを受信すると、利用する暗号化アルゴリズム、セッションＩＤ、プロトコルバージョンの候補をクライアントハローとして、エンティテイＢ側に送信する。
【０１３３】
（３）エンティテイＢ側は、利用を決定した暗号化アルゴリズム、セッションＩＤ、プロトコルバージョンをサーバーハローとしてエンティテイＡに送信する。（４）エンティテイＢは、自己の所有するルートＣＡまでの公開鍵証明書（Ｘ．５０９ｖ３）一式をエンティテイＡに送信（サーバ・サーティフィケート）する。なお、証明書連鎖をたどって最上位の公開鍵証明書まで順に検証を実施しない場合には、必ずしもルートＣＡまでの公開鍵証明書（Ｘ．５０９ｖ３）一式を送付する必要はない。（５）エンティテイＢは、ＲＳＡ公開鍵またはＤｉｆｆｉｅ＆Ｈｅｌｌｍａｎ公開鍵情報をエンティテイＡに送信（サーバ・キー・エクスチェンジ）する。これは証明書が利用できない場合に一時的に適用する公開鍵情報である。
【０１３４】
（６）次にエンティテイＢ側は、エンティテイＡに対してサーティフイケート・リクエストとして、エンティテイＡの有する証明書を要求し、（７）エンティテイＢによるネゴシエーション処理の終了を知らせる（サーバハロー終了）。
【０１３５】
（８）サーバハロー終了を受信したエンティテイＡは、自己の所有するルートＣＡまでの公開鍵証明書（Ｘ．５０９ｖ３）一式をエンティテイＢに送信（クライアント・サーティフィケート）する。なお、公開鍵証明書の連鎖検証を行なわない場合は公開鍵証明書の一式送付は必須ではない。（９）エンティテイＡは、４８バイト乱数をエンティテイＢの公開鍵で暗号化してエンティテイＢに送信する。エンティテイＢ、エンティテイＡは、この値をもとに送受信データ検証処理のためのメッセージ認証コード：ＭＡＣ（Ｍｅｓｓａｇｅ　Ａｕｔｈｅｎｔｉｃａｔｉｏｎ　Ｃｏｄｅ）生成用のデータ等を含むマスターシークレットを生成する。
【０１３６】
（１０）エンティテイＡは、クライアント証明書の正しさを確認するため、ここまでのメッセージのダイジェストをクライアントの秘密鍵で暗号化してエンティテイＢに送信（クライアントサーティフィケート確認）し、（１１）先に決定した暗号化アルゴリズム、鍵利用の開始を通知（チェンジ・サイファー・スペック）し、（１２）認証の終了を通知する。一方、（１３）エンティテイＢ側からエンティテイＡに対しても、先に決定した暗号化アルゴリズム、鍵利用の開始を通知（チェンジ・サイファー・スペック）し、（１４）認証の終了を通知する。
【０１３７】
上記処理において決定された暗号化アルゴリズムに従ってエンティテイＡとエンティテイＢ間のデータ転送が実行されることになる。
【０１３８】
データ改竄の検証は、上述の認証処理でエンティテイＡとエンティテイＢ間の合意のもとに生成されたマスターシークレットから算出されるメッセージ認証コード：ＭＡＣ（Ｍｅｓｓａｇｅ　Ａｕｔｈｅｎｔｉｃａｔｉｏｎ　Ｃｏｄｅ）を各エンティテイの送信データに付加することでメッセージの改竄検証を行なう。
【０１３９】
図１４にメッセージ認証コード：ＭＡＣ（Ｍｅｓｓａｇｅ　Ａｕｔｈｅｎｔｉｃａｔｉｏｎ　Ｃｏｄｅ）の生成構成を示す。データ送信側は、送信データに対して、認証処理において生成したマスターシークレットに基づいて生成されるＭＡＣシークレットを付加し、これらの全体データからハッシュ値を計算し、さらにＭＡＣシークレット、パディング、ハッシュ値に基づいてハッシュ算出を行なってメッセージ認証コード（ＭＡＣ）を生成する。この生成したＭＡＣを送信データに付加して、受信側で受信データに基づいて生成したＭＡＣと受信ＭＡＣとの一致が認められればデータ改竄なしと判定し、一致が認められない場合には、データの改竄があったものと判定する。
【０１４０】
図１２に示すステップＳ１０１において、サービスプロバイダ（ＳＰ）とグループ属性証明書の発行審査を実行する属性証明書登録局（ＡＲＡ）との間で、例えば上述したシーケンスに従った相互認証処理が実行され、双方が正しい通信相手であることの確認がなされると、ステップＳ１０２において、サービスプロバイダ（ＳＰ）と、属性証明書登録局（ＡＲＡ）との間で、グループ情報の共有処理を実行する。
【０１４１】
グループ情報の共有とは、具体的には、グループ属性証明書の発行エンティテイ（例えば属性証明書登録局（ＡＲＡ））の管理する発行ポリシーテーブルと、グループ属性証明書の検証および検証に基づくサービス提供エンティテイ（例えばサービスプロバイダ（ＳＰ））の有するグループ情報データベースとが整合した情報を保有する状態に設定する処理として行われる。
【０１４２】
先に説明したように、グループ属性証明書の発行エンティテイ（例えば属性証明書登録局（ＡＲＡ））は、発行ポリシーテーブルを有し、グループ属性証明書の検証および検証に基づくサービス提供エンティテイ（例えばサービスプロバイダ（ＳＰ））は、グループ情報データベースを有する。図１５に各情報構成例を示す。
【０１４３】
（Ａ）発行ポリシーテーブルは、属性証明書登録局（ＡＲＡ）が保持管理し、グループ属性証明書の発行処理等において参照する。一方、（Ｂ）グループ情報データベース（ＤＢ）は、サービスプロバイダ（ＳＰ）が保持管理し、サービス提供時のグループ属性証明書検証時に参照する。
【０１４４】
属性証明書登録局（ＡＲＡ）が保持管理する（Ａ）発行ポリシーテーブルと、サービスプロバイダ（ＳＰ）が保持管理する（Ｂ）グループ情報データベース（ＤＢ）は、整合性を有することが必要となる。図１５の例では、（Ａ）発行ポリシーテーブルのエントリ３４１は、（Ｂ）グループ情報データベース（ＤＢ）のエントリ３５１と整合しており、（Ａ）発行ポリシーテーブルのエントリ３４２は、（Ｂ）グループ情報データベース（ＤＢ）のエントリ３５２と整合している。このように、属性証明書登録局（ＡＲＡ）が保持管理する（Ａ）発行ポリシーテーブルと、サービスプロバイダ（ＳＰ）が保持管理する（Ｂ）グループ情報データベース（ＤＢ）との整合性保持処理が図１２のシーケンス図におけるステップＳ１０２のグループ情報共有処理である。
【０１４５】
なお、グループ情報共有処理の態様としては、以下の２例がある。
ポリシー受諾型：グループ属性証明書の検証および検証に基づくサービス提供エンティテイ（例えばサービスプロバイダ（ＳＰ））は、種々のグループ属性証明書の発行エンティテイ（例えば属性証明書登録局（ＡＲＡ））の発行ポリシーを検討し、自身のサービスに適合するグループＡＲＡを選択し、その選択したグループＡＲＡが管理するグループ情報をサービスプロバイダ（ＳＰ）が取得する。
【０１４６】
発行委託型：独自の属性証明書発行ポリシーを持たずに、単にグループ属性証明書の発行を請け負う形態のグループ属性証明書の発行エンティテイ（例えばグループ属性証明書登録局（ＡＲＡ））に対して、グループ属性証明書の検証および検証に基づくサービス提供エンティテイ（例えばサービスプロバイダ（ＳＰ））が設定した発行ポリシーをグループ属性証明書登録局（ＡＲＡ）に提示して、グループ属性証明書登録局（ＡＲＡ）が提示されたポリシーに従って、グループ属性証明書の発行処理を行なう。
【０１４７】
具体的なグループ情報共有処理の形態としては、グループ属性証明書に関するグループＩＤ、発行者、グループ情報、発行ポリシー等の情報をグループ属性証明書の発行エンティテイ（例えばグループ属性証明書登録局（ＡＲＡ））が設定し、グループ属性証明書の検証および検証に基づくサービス提供エンティテイ（例えばサービスプロバイダ（ＳＰ））に提示して、双方のエンティテイが合意する態様、または、これらの情報をサービスプロバイダが設定し、グループＡＲＡに提示して、双方のエンティテイが合意する態様、あるいは、それぞれの情報を双方で分担して設定し、総合した情報に関して合意に至る態様、あるいはサービスプロバイダがグループ属性証明書登録局（ＡＲＡ）を一方的に信頼した態様等が可能である。
【０１４８】
なお、発行委託型の場合には、新規なサービスプロバイダ（ＳＰ）が、グループ属性証明書を利用した新たなサービスを開始する場合には、属性証明書登録局（ＡＲＡ）がサービスプロバイダ（ＳＰ）自体の登録審査を行ない、その後に、上述のグループ情報共有処理を実行することになる。
【０１４９】
ステップＳ１０２のグループ情報共有処理が終了すると、サービスプロバイダ（ＳＰ）は、ステップＳ１０３において、自己の管理するグループ情報データベースについて、合意した情報に基づくデータ更新処理を実行する。図１５に示すように、グループ情報データベースには、発行者、グループ識別情報（グループＩＤ）、グループ情報の各データが格納され、これらの情報に関するデータ登録、更新を実行する。一方、属性証明書登録局（ＡＲＡ）は、ステップＳ１０４において、自己の管理する発行ポリシーテーブルについて、合意した情報に基づくデータ更新処理を実行する。図１５に示すように、発行ポリシーテーブルには、グループＩＤ、グループ情報、発行ポリシーの各データが格納され、これらの情報に関するデータ登録、更新を実行する。
【０１５０】
なお、上述した処理は、サービスプロバイダ（ＳＰ）と、属性証明書登録局（ＡＲＡ）とが、独立したエンティテイとして構成されている場合に必要となる処理であり、サービスプロバイダ（ＳＰ）が、属性証明書登録局（ＡＲＡ）を兼ねている場合は、サービスプロバイダ（ＳＰ）自身が、グループ情報データベースおよび発行ポリシーテーブルの両者を保持管理することになり、上述したサービスプロバイダ（ＳＰ）と、属性証明書登録局（ＡＲＡ）間でのグループ情報共有処理は省略可能となる。
【０１５１】
また、上述した例は、グループ属性証明書の発行エンティテイをグループ属性証明書登録局（ＡＲＡ）とし、グループ属性証明書の検証および検証に基づくサービス提供エンティテイをサービスプロバイダ（ＳＰ）とした例を説明したが、それぞれのエンティテイの組み合わせに応じて、上述の処理が実行されることになる。
【０１５２】
（３−２）グループ属性証明書発行処理
次に、グループ属性証明書発行処理について説明する。グループ属性証明書発行処理は、基本的には、属性認証局（ＡＡ）が実行することが原則である。ただし、サービスプロバイダ、ユーザデバイスにおいても独自の発行ポリシーに基づいて発行することが可能である。以下では、属性認証局（ＡＡ）によるグループ属性証明書の発行処理シーケンスについて説明する。
【０１５３】
属性証明書登録局（ＡＲＡ）が属性証明書発行要求エンティテイからの発行要求を受理し、ポリシー審査等を実行して、発行可と判定した後、属性認証局（ＡＡ）に属性証明書発行要求を転送し、属性認証局（ＡＡ）の発行した属性証明書を属性証明書登録局（ＡＲＡ）を介して、発行要求エンティテイに対して送付する処理構成が通常の属性証明書発行シーケンスである。
【０１５４】
図１６を参照して、ユーザデバイスであるエンドエンティテイ（ＥＥ）のセキュリティチップ（ＳＣ）がグループ属性証明書の発行要求主体である場合の処理について説明する。なお、図１６において、
ＵＩＤ：ユーザ識別デバイス（ユーザデバイス）制御部、
ＵＳＣ：ＵＩＤ内に構成されるユーザセキュリティチップ、
ＥＥ：エンドエンティテイ（ユーザデバイス）制御部、
ＳＣ：ＥＥ内に構成されるセキュリティチップ、
グループＡＲＡ：グループ属性証明書登録局制御部、
グループＡＡ：グループ属性認証局制御部、
である。
【０１５５】
まず、ステップＳ１１１において、ユーザがエンドエンティテイ（ＥＥ）の入力インタフェースを介して、グループ属性証明書（Ｇｐ．ＡＣ）の発行要求コマンドを入力する。この際、ユーザはグループ属性証明書発行に必要となる属性値を入力する。属性値は、グループＩＤ、あるいはグループに属することを証明する情報等である。
【０１５６】
エンドエンティテイ（ＥＥ）がユーザからのグループ属性証明書（Ｇｐ．ＡＣ）の発行要求の入力を受領すると、ステップＳ１１２において、エンドエンティテイ（ＥＥ）は、グループＡＲＡに対する接続要求を行ない、一方、ステップＳ１１３において、エンドエンティテイ（ＥＥ）内のセキュリティチップ（ＳＣ）に対して、相互認証開始要求を出力する。
【０１５７】
ステップＳ１１４において、セキュリティチップと、グループＡＲＡ間の相互認証が実行される。これは例えば先に図１３を参照して説明した公開鍵方式の相互認証処理として実行される。ステップＳ１１５では、セキュリティチップからエンドエンティテイに対して、相互認証の成立、不成立の結果情報を含む相互認証完了通知が出力される。相互認証不成立の場合は、処理の続行は中止される。相互認証が成立すると、ステップＳ１１６において、エンドエンティテイ（ＥＥ）は、グループＡＲＡに対してグループ属性証明書（Ｇｐ．ＡＣ）発行要求を送信する。このグループ属性証明書（Ｇｐ．ＡＣ）発行要求には、エンドエンティテイ情報、属性値（例えばグループＩＤ、グループ情報）が含まれる。
【０１５８】
エンドエンティテイ（ＥＥ）からグループ属性証明書（Ｇｐ．ＡＣ）発行要求を受信したグループＡＲＡは、ステップＳ１１７において、発行ポリシーテーブルを参照して、ポリシーに準拠したグループ属性証明書の発行が可能か否かを判定し、可であれば、ステップＳ１１８に進み、不可であれば、発行不可メッセージをエンドエンティテイに通知する。
【０１５９】
ステップＳ１１８では、グループＡＲＡが属性値（グループＩＤ）を伴うグループ属性証明書（Ｇｐ．ＡＣ）発行要求をグループＡＡに送信し、ステップＳ１１９において、グループＡＡが、グループＩＤを属性情報として格納し、電子署名を施したグループ属性証明書（図５参照）を生成し、グループＡＲＡに送信する。
【０１６０】
ステップＳ１２０において、グループＡＲＡが、発行されたグループ属性証明書（Ｇｐ．ＡＣ）をエンドエンティテイ（ＥＥ）に送信する。エンドエンティテイ（ＥＥ）は、受信したグループ属性証明書（Ｇｐ．ＡＣ）をメモリに格納する。この際、グループ属性証明書（Ｇｐ．ＡＣ）の電子署名の検証を実行して、改竄の無いことを確認した後。メモリに格納する。
【０１６１】
グループ属性証明書の生成時にグループＡＡが実行する電子署名の生成、および、グループ属性証明書の格納時にエンドエンティテイが実行する電子署名の検証処理について、図１７、図１８を参照して説明する。
【０１６２】
署名は、データ改竄の検証を可能とするために付加されるものであり、前述のＭＡＣ値を用いることも可能であり、公開鍵暗号方式を用いた電子署名を適用することも可能である。
【０１６３】
まず、公開鍵暗号方式を用いた電子署名の生成方法について、図１７を用いて説明する。図１７に示す処理は、ＥＣ−ＤＳＡ（（Ｅｌｌｉｐｔｉｃ　Ｃｕｒｖｅ　Ｄｉｇｉｔａｌ　Ｓｉｇｎａｔｕｒｅ　Ａｌｇｏｒｉｔｈｍ）、ＩＥＥＥ　Ｐ１３６３／Ｄ３）を用いた電子署名データの生成処理フローである。なお、ここでは公開鍵暗号として楕円曲線暗号（Ｅｌｌｉｐｔｉｃ　Ｃｕｒｖｅ　Ｃｒｙｐｔｏｓｙｓｔｅｍ（以下、ＥＣＣと呼ぶ））を用いた例を説明する。なお、本発明のデータ処理装置においては、楕円曲線暗号以外にも、同様の公開鍵暗号方式における、例えばＲＳＡ暗号（（Ｒｉｖｅｓｔ、Ｓｈａｍｉｒ、Ａｄｌｅｍａｎ）など（ＡＮＳＩ　Ｘ９．３１））を用いることも可能である。
【０１６４】
図１７の各ステップについて説明する。ステップＳ１において、ｐを標数、ａ、ｂを楕円曲線の係数（楕円曲線：ｙ２＝ｘ３＋ａｘ＋ｂ，４ａ３＋２７ｂ２≠０（ｍｏｄｐ））、Ｇを楕円曲線上のベースポイント、ｒをＧの位数、Ｋｓを秘密鍵（０＜Ｋｓ＜ｒ）とする。ステップＳ２おいて、メッセージＭのハッシュ値を計算し、ｆ＝Ｈａｓｈ（Ｍ）とする。
【０１６５】
ここで、ハッシュ関数を用いてハッシュ値を求める方法を説明する。ハッシュ関数とは、メッセージを入力とし、これを所定のビット長のデータに圧縮し、ハッシュ値として出力する関数である。ハッシュ関数は、ハッシュ値（出力）から入力を予測することが難しく、ハッシュ関数に入力されたデータの１ビットが変化したとき、ハッシュ値の多くのビットが変化し、また、同一のハッシュ値を持つ異なる入力データを探し出すことが困難である特徴を有する。ハッシュ関数としては、ＭＤ４、ＭＤ５、ＳＨＡ−１などが用いられる場合もあるし、ＤＥＳ−ＣＢＣが用いられる場合もある。この場合は、最終出力値となるＭＡＣ（チェック値：ＩＣＶに相当する）がハッシュ値となる。
【０１６６】
続けて、ステップＳ３で、乱数ｕ（０＜ｕ＜ｒ）を生成し、ステップＳ４でベースポイントをｕ倍した座標Ｖ（Ｘｖ，Ｙｖ）を計算する。なお、楕円曲線上の加算、２倍算は次のように定義されている。
【０１６７】
【数１】
Ｐ＝（Ｘａ，Ｙａ），Ｑ＝（Ｘｂ，Ｙｂ），Ｒ＝（Ｘｃ，Ｙｃ）＝Ｐ＋Ｑとすると、
Ｐ≠Ｑの時（加算）、
Ｘｃ＝λ２−Ｘａ−Ｘｂ
Ｙｃ＝λ×（Ｘａ−Ｘｃ）−Ｙａ
λ＝（Ｙｂ−Ｙａ）／（Ｘｂ−Ｘａ）
Ｐ＝Ｑの時（２倍算）、
Ｘｃ＝λ２−２Ｘａ
Ｙｃ＝λ×（Ｘａ−Ｘｃ）−Ｙａ
λ＝（３（Ｘａ）２＋ａ）／（２Ｙａ）
【０１６８】
これらを用いて点Ｇのｕ倍を計算する（速度は遅いが、最もわかりやすい演算方法として次のように行う。Ｇ、２×Ｇ、４×Ｇ・・を計算し、ｕを２進数展開して１が立っているところに対応する２ｉ×Ｇ（Ｇをｉ回２倍算した値（ｉはｕのＬＳＢから数えた時のビット位置））を加算する。
【０１６９】
ステップＳ５で、ｃ＝Ｘｖｍｏｄｒを計算し、ステップＳ６でこの値が０になるかどうか判定し、０でなければステップＳ７でｄ＝［（ｆ＋ｃＫｓ）／ｕ］ｍｏｄｒを計算し、ステップＳ８でｄが０であるかどうか判定し、ｄが０でなければ、ステップＳ９でｃおよびｄを電子署名データとして出力する。仮に、ｒを１６０ビット長の長さであると仮定すると、電子署名データは３２０ビット長となる。
【０１７０】
ステップＳ６において、ｃが０であった場合、ステップＳ３に戻って新たな乱数を生成し直す。同様に、ステップＳ８でｄが０であった場合も、ステップＳ３に戻って乱数を生成し直す。
【０１７１】
次に、公開鍵暗号方式を用いた電子署名の検証方法を、図１８を用いて説明する。ステップＳ１１で、Ｍをメッセージ、ｐを標数、ａ、ｂを楕円曲線の係数（楕円曲線：ｙ２＝ｘ３＋ａｘ＋ｂ，４ａ３＋２７ｂ２≠０（ｍｏｄｐ））、Ｇを楕円曲線上のベースポイント、ｒをＧの位数、ＧおよびＫｓ×Ｇを公開鍵（０＜Ｋｓ＜ｒ）とする。ステップＳ１２で電子署名データｃおよびｄが０＜ｃ＜ｒ、０＜ｄ＜ｒを満たすか検証する。これを満たしていた場合、ステップＳ１３で、メッセージＭのハッシュ値を計算し、ｆ＝Ｈａｓｈ（Ｍ）とする。次に、ステップＳ１４でｈ＝１／ｄ　ｍｏｄ　ｒを計算し、ステップＳ１５でｈ１＝ｆｈ　ｍｏｄ　ｒ、ｈ２＝ｃｈ
ｍｏｄ　ｒを計算する。
【０１７２】
ステップＳ１６において、既に計算したｈ１およびｈ２を用い、点Ｐ＝（Ｘｐ，Ｙｐ）＝ｈ１×Ｇ＋ｈ２・Ｋｓ×Ｇを計算する。電子署名検証者は、ベースポイントＧおよびＫｓ×Ｇを知っているので、図１７のステップＳ４と同様に楕円曲線上の点のスカラー倍の計算ができる。そして、ステップＳ１７で点Ｐが無限遠点かどうか判定し、無限遠点でなければステップＳ１８に進む（実際には、無限遠点の判定はステップＳ１６でできてしまう。つまり、Ｐ＝（Ｘ，Ｙ）、Ｑ＝（Ｘ，−Ｙ）の加算を行うと、λが計算できず、Ｐ＋Ｑが無限遠点であることが判明している）。ステップＳ１８でＸｐｍｏｄｒを計算し、電子署名データｃと比較する。最後に、この値が一致していた場合、ステップＳ１９に進み、電子署名が正しいと判定する。
【０１７３】
電子署名が正しいと判定された場合、データは改竄されておらず、公開鍵に対応した秘密鍵を保持する者が電子署名を生成したことがわかる。
【０１７４】
ステップＳ１２において、電子署名データｃまたはｄが、０＜ｃ＜ｒ、０＜ｄ＜ｒを満たさなかった場合、ステップＳ２０に進む。また、ステップＳ１７において、点Ｐが無限遠点であった場合もステップＳ２０に進む。さらにまた、ステップＳ１８において、Ｘｐｍｏｄｒの値が、電子署名データｃと一致していなかった場合にもステップＳ２０に進む。
【０１７５】
ステップＳ２０において、電子署名が正しくないと判定された場合、データは改竄されているか、公開鍵に対応した秘密鍵を保持する者が電子署名を生成したのではないことがわかる。上述したように、署名付けやハッシュをとるだけでは改竄は可能であるが、検出により実質的に改竄できないことと同様の効果がある。
【０１７６】
次に、図１９を参照して、ユーザ識別デバイス（ＵＩＤ）内のユーザセキュリティチップ（ＵＳＣ）対応のグループ属性証明書を発行する手順について説明する。先に説明したように、ＵＩＤは、エンドエンティテイ（ＥＥ）を介して外部と通信が可能な構成であるので、属性証明書の取得処理もエンドエンティテイ（ＥＥ）を介して実行される。
【０１７７】
ステップＳ１３１〜Ｓ１３５の処理は、図１６を参照して説明したステップＳ１１１〜Ｓ１１５の処理と同様の処理であり、説明を省略する。
【０１７８】
ステップＳ１３４におけるエンドエンティテイ内のセキュリティチップ（ＳＣ）とグループＡＲＡ間の相互認証が成立すると、ステップＳ１３７において、ユーザ識別デバイス（ＵＩＤ）内のユーザセキュリティチップ（ＵＳＣ）と、エンドエンティテイ内のセキュリティチップ（ＳＣ）との間における相互認証処理が実行される。この認証処理は、エンドエンティテイ（ＥＥ）と、ユーザ識別デバイス（ＵＩＤ）との接続機器インタフェース２３１（図９参照）を介して実行される。この認証処理は、セキュリティチップ、セキュリテイモジュールの暗号処理部（図９参照）を中心とした処理として先に図１３を参照して説明した公開鍵方式に基づく認証処理として実行可能である。ステップＳ１３８において、認証の成立情報を含む認証完了通知がエンドエンティテイ（ＥＥ）に通知され、認証成立を条件として次ステップに進む。
【０１７９】
ステップＳ１３９では、エンドエンティテイ（ＥＥ）からユーザセキュリティチップ（ＵＳＣ）相互認証開始要求が出力され、ステップＳ１４０において、ＵＳＣと、グループＡＲＡ間の相互認証処理が実行される。ステップＳ１４１において、認証の成立情報を含む認証完了通知がＵＳＣからエンドエンティテイ（ＥＥ）に通知され、認証成立を条件として、エンドエンティテイ（ＥＥ）は、ステップＳ１４２において、グループＡＲＡに対してグループ属性証明書（Ｇｐ．ＡＣ）発行要求を送信する。このグループ属性証明書（Ｇｐ．ＡＣ）発行要求には、エンドエンティテイ情報、属性値（例えばグループＩＤ、グループ情報）が含まれる。
【０１８０】
エンドエンティテイ（ＥＥ）からグループ属性証明書（Ｇｐ．ＡＣ）発行要求を受信したグループＡＲＡは、ステップＳ１４３において、発行ポリシーテーブルを参照して、ポリシーに準拠したグループ属性証明書の発行が可能か否かを判定し、可であれば、ステップＳ１４４に進み、不可であれば、発行不可メッセージをエンドエンティテイに通知する。
【０１８１】
ステップＳ１４４では、グループＡＲＡが属性値（グループＩＤ）を伴うグループ属性証明書（Ｇｐ．ＡＣ）発行要求をグループＡＡに送信し、ステップＳ１４５において、グループＡＡが、グループＩＤを属性情報として格納し、電子署名を施したグループ属性証明書（図５参照）を生成し、グループＡＲＡに送信する。
【０１８２】
ステップＳ１４６において、グループＡＲＡが、発行されたグループ属性証明書（Ｇｐ．ＡＣ）をエンドエンティテイ（ＥＥ）を介してＵＩＤに送信する。ＵＩＤは、受信したグループ属性証明書（Ｇｐ．ＡＣ）をメモリに格納する。この際、グループ属性証明書（Ｇｐ．ＡＣ）の電子署名の検証を実行して、改竄の無いことを確認した後、メモリに格納する。
【０１８３】
上述したように、ダイレクトにグループＡＲＡとの通信機能を持たないユーザ識別デバイス（ＵＩＤ）がユーザセキュリティチップ（ＵＳＣ）に対応するグループ属性証明書を取得するためには、エンドエンティテイ（ＥＥ）を介する処理が必要となる。その際、ユーザセキュリティチップ（ＵＳＣ）とグループＡＲＡとの間で相互に認証を行なうためには、たとえば、
（１）ＥＥのＳＣとグループＡＲＡとの相互認証、
（２）ＥＥのＳＣとＵＩＤのＵＳＣとの相互認証、
（３）ＵＩＤのＵＳＣとグループＡＲＡとの相互認証、
のすべてが成立することが条件となる。あるいは、簡便な方式として、ＵＩＤがＥＥに接続されることで、ＥＥは基本的にこれを受け入れる（認証したものとする）という処理構成としてもよく、この場合は、上記（２）の相互認証の省略が可能となる。さらに、上記３種の相互認証の様々な組み合わせによる認証構成が可能である。
【０１８４】
（３−３）グループ属性証明書利用処理
ユーザデバイス内のセキュリティチップ（ＳＣ）、あるいはユーザセキュリティチップ（ＵＳＣ）に格納したグループ属性証明書を利用した処理について説明する。なお、ここでは、具体的なサービス形態については言及せず、サービス提供開始に至るまでのグループ属性証明書に基づくサービス利用権限確認処理について説明する。具体的なサービス形態については、後段の別項目において説明する。
【０１８５】
図２０以下を参照して、ユーザデバイスとしてのエンドエンティテイ（ＥＥ）内のセキュリティチップ（ＳＣ）に対して発行されたグループ属性証明書を利用したサービス利用権限確認を含むサービス開始までの処理について説明する。なお、図２０において、
ＵＩＤ：ユーザ識別デバイス（ユーザデバイス）制御部、
ＵＳＣ：ＵＩＤ内に構成されるユーザセキュリティチップ、
ＥＥ：エンドエンティテイ（ユーザデバイス）制御部、
ＳＣ：ＥＥ内に構成されるセキュリティチップ、
ＳＰ：サービスプロバイダ制御部、
ＳＭ：ＳＰ内のセキュリティモジュール、
である。
【０１８６】
なお、ユーザデバイス（ＥＥ）のセキュリティチップ（ＳＣ）、ユーザ識別デバイス（ＵＩＤ）のユーザセキュリティチップ（ＵＳＣ）、およびサービスプロバイダ（ＳＰ）のセキュリティモジュールは、例えば先に説明した図９のセキュリティチップと同様の構成を持つ。
【０１８７】
まず、ステップＳ１５１において、ユーザがエンドエンティテイ（ＥＥ）の入力インタフェースを介して、グループ属性証明書（Ｇｐ．ＡＣ）の利用要求コマンドを入力する。この際、ユーザは利用するグループ属性証明書に設定されたグループＩＤを指定する。ただし、特定のサービスを指定することにより唯一のグループＩＤが決定可能である場合は、サービスの指定のみとしてもよい。
【０１８８】
エンドエンティテイ（ＥＥ）がユーザからのグループ属性証明書（Ｇｐ．ＡＣ）の利用要求入力を受領すると、ステップＳ１５２において、エンドエンティテイ（ＥＥ）は、サービスプロバイダ（ＳＰ）に対する接続要求を行ない、一方、ステップＳ１５３において、エンドエンティテイ（ＥＥ）内のセキュリティチップ（ＳＣ）に対して、相互認証開始要求を出力する。
【０１８９】
ステップＳ１５４において、セキュリティチップと、サービスプロバイダ（ＳＰ）のセキュリティモジュール（ＳＭ）間の相互認証が実行される。これは、セキュリティチップと、サービスプロバイダ（ＳＰ）のセキュリティモジュール（ＳＭ）内に構成される、例えば図９に示す暗号処理部２０５を中心とした処理として、例えば先に図１３を参照して説明した公開鍵方式の相互認証処理として実行される。
【０１９０】
ステップＳ１５５では、セキュリティチップからエンドエンティテイに対して、相互認証の成立、不成立の結果情報を含む相互認証完了通知が出力される。相互認証不成立の場合は、処理の続行は中止される。相互認証が成立すると、ステップＳ１５６において、エンドエンティテイ（ＥＥ）は、サービスプロバイダ（ＳＰ）のセキュリティモジュール（ＳＭ）に対して自己のメモリに格納したグループ属性証明書（Ｇｐ．ＡＣ）を送信する。なお、グループ属性証明書（Ｇｐ．ＡＣ）の送信は、サービスプロバイダ（ＳＰ）からの送信要求に応答する形で実行する構成としてもよい。また、エンドエンティテイ（ＥＥ）は、グループ属性証明書（Ｇｐ．ＡＣ）の送信に併せて、グループ属性証明書（Ｇｐ．ＡＣ）の利用要求を行なう場合もある。このグループ属性証明書（Ｇｐ．ＡＣ）には、グループ識別情報（グループＩＤ）が属性値として格納されている。
【０１９１】
サービスプロバイダは、例えば図９に示すユーザデバイスと同様の構成を持つネットワークインタフェースを受信部として、エンドエンティテイ（ＥＥ）からグループ属性証明書（Ｇｐ．ＡＣ）を受信し、セキュリティモジュール（ＳＭ）に転送する。セキュリティモジュール（ＳＭ）は、ステップＳ１５７において、グループ属性証明書検証処理を実行する。セキュリティモジュールは、先に説明したように、図９に示すユーザデバイスのセキュリティチップと同様の構成を持ち、セキュリティモジュールが、グループ属性証明書検証処理部として機能することになる。
【０１９２】
グループ属性証明書の検証処理の詳細について、図２１乃至図２３を参照して説明する。まず、属性証明書（ＡＣ）と公開鍵証明書（ＰＫＣ）との関連確認処理について、図２１を参照して説明する。図２１のフローは、属性証明書（ＡＣ）の検証を実行する際に行なわれる属性証明書（ＡＣ）に関連する公開鍵証明書（ＰＫＣ）の確認処理である。
【０１９３】
確認対象の属性証明書（ＡＣ）がセット（Ｓ２１）されると、属性証明書のＡＣ保持者の公開鍵証明書情報（ホルダー）フィールドを抽出（Ｓ２２）し、抽出した公開鍵証明書情報（ホルダー）フィールド内に格納された公開鍵証明書の発行者情報（ＰＫＣ発行者）、公開鍵証明書シリアル番号（ＰＫＣシリアル）を確認（Ｓ２３）し、公開鍵証明書の発行者情報（ＰＫＣ発行者）、公開鍵証明書シリアル番号（ＰＫＣシリアル）に基づいて公開鍵証明書（ＰＫＣ）を検索（Ｓ２４）して、属性証明書（ＡＣ）に関連付けられた公開鍵証明書（ＰＫＣ）を取得（Ｓ２５）する。
【０１９４】
図２１に示すように、属性証明書（ＡＣ）と公開鍵証明書（ＰＫＣ）とは、属性証明書に格納された公開鍵証明書情報（ホルダー）フィールド内の公開鍵証明書発行者情報（ＰＫＣ発行者）、および公開鍵証明書シリアル番号（ＰＫＣシリアル）により関連付けがなされている。
【０１９５】
次に、図２２を参照して属性証明書（ＡＣ）の検証処理について説明する。まず、検証対象となる属性証明書（ＡＣ）をセット（Ｓ５１）し、属性証明書（ＡＣ）格納情報に基づいて、属性証明書（ＡＣ）の所有者および署名者を特定（Ｓ５２）する。さらに、属性証明書（ＡＣ）の所有者の公開鍵証明書を直接あるいはリポジトリなどから取得（Ｓ５３）して、公開鍵証明書の検証処理を実行（Ｓ５４）する。
【０１９６】
図２３を参照して公開鍵証明書（ＰＫＣ）の検証処理について説明する。図２３に示す公開鍵証明書（ＰＫＣ）の検証は、下位から上位へ証明書連鎖をたどって最上位の公開鍵証明書までの連鎖情報を取得して、最上位（ル−トＣＡ）までの公開鍵証明書の署名検証を行なう連鎖検証処理フローである。まず、検証対象となる公開鍵証明書（ＰＫＣ）をセット（Ｓ３１）し、公開鍵証明書（ＰＫＣ）格納情報に基づいて、公開鍵証明書（ＰＫＣ）署名者を特定（Ｓ３２）する。さらに、検証対象となる証明書連鎖の最上位の公開鍵証明書であるかを判定（Ｓ３３）し、最上位でない場合は、最上位公開鍵証明書を直接あるいはリポジトリなどから取得（Ｓ３４）する。最上位公開鍵証明書が取得されセット（Ｓ３５）されると、署名検証に必要な検証鍵（公開鍵）を取得（Ｓ３６）し、検証対象の署名が自己署名であるか否かを判定し（Ｓ３７）、自己署名でない場合は、下位ＰＫＣをセット（Ｓ３９）して、上位の公開鍵証明書から取得した検証鍵（公開鍵）に基づいて署名検証を実行（Ｓ４０）する。なお、ステップＳ３７における自己署名判定において、自己署名の場合は自己の公開鍵を検証鍵とした検証を実行（Ｓ３８）し、ステップＳ４１に進む。
【０１９７】
署名検証に成功した場合（Ｓ４１：Ｙｅｓ）は、目的とするＰＫＣの検証が完了したか否かを判定（Ｓ４２）し、完了している場合は、ＰＫＣ検証を終了する。完了していない場合は、ステップＳ３６に戻り、署名検証に必要な検証鍵（公開鍵）の取得、下位の公開鍵証明書の署名検証を繰り返し実行する。なお、署名検証に失敗した場合（Ｓ４１：Ｎｏ）は、ステップＳ４３に進み、エラー処理、例えばその後の手続きを停止する等の処理を実行する。
【０１９８】
図２２に戻り、属性証明書検証処理の説明を続ける。図２３で説明した公開鍵証明書の検証に失敗した場合（Ｓ５５でＮｏ）は、ステップＳ５６に進み、エラー処理を行なう。例えばその後の処理を中止する。公開鍵証明書の検証に成功した場合（Ｓ５５でＹｅｓ）は、属性証明書（ＡＣ）の署名者に対応する公開鍵証明書を直接あるいはリポジトリなどから取得（Ｓ５７）して、属性証明書（ＡＣ）の署名者に対応する公開鍵証明書の検証処理を実行（Ｓ５８）する。
【０１９９】
属性証明書（ＡＣ）の署名者に対応する公開鍵証明書の検証に失敗した場合（Ｓ５９でＮｏ）は、ステップＳ６０に進み、エラー処理を行なう。例えばその後の処理を中止する。公開鍵証明書の検証に成功した場合（Ｓ５９でＹｅｓ）は、属性証明書（ＡＣ）の署名者に対応する公開鍵証明書から公開鍵を取り出し（Ｓ６１）て、取り出した公開鍵を用いて属性証明書（ＡＣ）の署名検証処理を実行（Ｓ６２）する。署名検証に失敗した場合（Ｓ６３でＮｏ）は、ステップＳ６４に進み、エラー処理を行なう。例えばその後の処理を中止する。署名検証に成功した場合（Ｓ６３でＹｅｓ）は、属性証明書検証を終了し、その後の処理、すなわちサービス提供のために実行すべきその他の条件確認処理に移行する。
【０２００】
図２０のシーケンス図に戻って説明を続ける。ステップＳ１５７のグループ属性証明書（Ｇｐ．ＡＣ）の検証が上述した処理によって実行されると、セキュリティモジュール（ＳＭ）は、検証結果をサービスプロバイダ（ＳＰ）に出力し、検証不成功の場合は、エラー処理として、サービス提供を実行せず処理を中止する。この場合、グループＡＣの検証が不成立であった旨をエンドエンティテイに通知する処理を実行してもよい。
【０２０１】
グループ属性証明書（Ｇｐ．ＡＣ）の検証が成功し、グループ属性証明書（Ｇｐ．ＡＣ）の正当性が確認されるとステップＳ１６１に進む。ステップＳ１６１以下の処理を図２４を参照して説明する。ステップＳ１６１では、グループ属性証明書（Ｇｐ．ＡＣ）の審査を実行する。審査は、サービスプロバイダの保有するグループ情報データベースに基づいて実行する。
【０２０２】
グループ属性証明書（Ｇｐ．ＡＣ）の審査処理について、図２５を参照して説明する。ステップＳ１６１−１において、サービスプロバイダ（ＳＰ）は、検証済みのグループ属性証明書（Ｇｐ．ＡＣ）から発行者情報を取得する。さらに、ステップＳ１６１−２において、属性フィールドから属性値、すなわちグループ識別情報（グループＩＤ）を取得する。
【０２０３】
ステップＳ１６１−３において、グループ属性証明書（Ｇｐ．ＡＣ）から取得したＡＣ発行者、およびグループＩＤに基づいて、グループ情報データベースを検索し、登録されたエントリーの有無を確認する。対応する登録エントリーがある場合は、ステップＳ１６１−４において、グループ情報データベースからグループ情報を取得する。
【０２０４】
図２４のシーケンス図に戻り説明を続ける。グループ属性証明書（Ｇｐ．ＡＣ）に対応するグループ情報が登録されていない場合、あるいはユーザがグループ情報に示された条件を満足していない場合は、審査不成功（Ｓ１６２：Ｎｏ）となり、ステップＳ１６３のエラー処理を実行する。例えばグループＡＣの審査不成立であり、サービス実行ができない旨のメッセージをエンドエンティテイ（ＥＥ）に通知する。また、サービス提供に際して複数のグループ属性証明書の検証・審査が必要な場合は、この条件をサービス情報データベースで管理する。
【０２０５】
なお、サービス情報データベースは、サービスを提供するにあたり、どのグループＡＣが必要であるかという情報を格納しているデータベースである。ただし、前述したグループ情報データベースとサービス情報データベースを各々個別に保有することは必須ではなく、グループ情報データベースとサービス情報データベースとを融合あるいはリンクさせたデータベース構成を持つことが可能である。すなわち、サービス提供にどのグループＡＣが必要であるかというデータを、前述のグルーブ情報データベース、あるいはグルーブ情報データベースのリンク情報から取得する構成も可能である。以下の説明において、グループ情報データベースは、サービス情報データベースとしての機能も併せ持つものとして説明する。
【０２０６】
図２４のシーケンス図に戻り説明を続ける。審査成功（Ｓ１６２：Ｙｅｓ）の場合は、サービス実行のための他の条件の必要性の有無を判定する。この条件は、サービスプロバイダが任意に設定可能な条件である。さらに、ステップＳ１６５において、サービス提供のために他のグループ属性証明書が必要であるか否かを判定する。
【０２０７】
これは、図２６に示すように、サービスを提供条件として、ユーザあるいはユーザ機器が異なる複数のグループに属することが条件とされる場合を想定したものである。例えば、図２６（ａ）に示すように、２つの異なるグループに属することの証明により、サービスを提供するという設定ができる。
【０２０８】
具体的には、例えばユーザの居住地が特定の地域に属することを証明するグループ属性証明書Ａ（グループＡ）と、ユーザ機器が特定メーカーの機器であることを示すグループ属性証明書Ｂ（グループＢ）との２つのグループ属性証明書の提示、検証によりサービスを提供するといった設定である。
【０２０９】
さらに、図２６（ｂ）に示すように、３つ以上の異なるグループに属することの証明により、サービスを提供するという設定もできる。具体的には、例えばユーザの居住地が特定の地域に属することを証明するグループ属性証明書Ａ（グループＡ）と、ユーザ機器が特定メーカーの機器であることを示すグループ属性証明書Ｂ（グループＢ）と、さらに、ユーザの年齢が所定の範囲に属することを示すグループ属性証明書Ｃ（グループＣ）の３つのグループ属性証明書の提示、検証によりサービスを提供するといった設定である。
【０２１０】
このように、ユーザあるいはユーザ機器に対して発行された異なる２以上のグループ属性証明書を適用して、ユーザあるいはユーザ機器が複数の異なるグループに属していることの検証を条件としたサービス提供を行なう場合、サービスプロバイダ（ＳＰ）は、ステップＳ１６６において、エンドエンティテイ（ＥＥ）に対して他のグループ属性証明書（Ｇｐ．ＡＣ）の提示を要求する。他のグループ属性証明書の提示を求められたエンドエンティテイ（ＥＥ）は、ステップＳ１６７において、求めに応じたグループ属性証明書をサービスプロバイダ（ＳＰ）のセキュリティモジュール（ＳＭ）に送信する。セキュリティモジュール（ＳＭ）はエンドエンティテイ（ＥＥ）から受信した新たなグループ属性証明書について、図２０に示すステップＳ１５７以下の処理、すなわち、グループ属性証明書の検証処理、審査処理等を実行する。
【０２１１】
サービス提供に必要となるグループ属性証明書の検証、審査に成功したことを条件として、ステップＳ１６８においてサービス提供が実行される。このサービスは、サービスプロバイダの提供するコンテンツ配信、決済処理、ユーザデバイスとしての機器（例えば家電機器）のリモートコントロール、リモートメンテナンス処理、コミュニュケーションサービス等、様々である。これらサービスの具体例については、後段で説明する。
【０２１２】
次に、図２７、図２８を参照して、ユーザデバイスとしてのユーザ識別デバイス（ＵＩＤ）内のユーザセキュリティチップ（ＵＳＣ）に対応して発行されたグループ属性証明書に基づくサービス提供までの処理について説明する。ユーザ識別デバイス（ＵＩＤ）は個人識別デバイスとして機能する機器である。グループ属性証明書は、エンドエンティテイおよびユーザ識別デバイス各々に対して個別に発行可能である。基本的には、ユーザ識別デバイスに発行されるグループ属性証明書は、ユーザ自体がある特定のグループのメンバであるか否かの確認を可能とする証明書として発行される。ＵＩＤは、エンドエンティテイ（ＥＥ）を介して外部と通信が可能な構成であるので、属性証明書の利用処理もエンドエンティテイ（ＥＥ）を介して実行される。
【０２１３】
図２７において、ステップＳ１７１〜Ｓ１７５は、図２０に示すステップＳ１５１〜Ｓ１５５と同様の処理、すなわち、エンドエンティテイ（ＥＥ）内のセキュリティチップ（ＳＣ）とサービスプロバイダ（ＳＰ）のセキュリティモジュール（ＳＭ）間の相互認証を中心とした処理である。
【０２１４】
ステップＳ１７４に示すエンドエンティテイ内のセキュリティチップ（ＳＣ）とサービスプロバイダ（ＳＰ）のセキュリティモジュール（ＳＭ）間の相互認証が成立すると、ステップＳ１７７において、ユーザ識別デバイス（ＵＩＤ）内のユーザセキュリティチップ（ＵＳＣ）と、エンドエンティテイ内のセキュリティチップ（ＳＣ）との間における相互認証処理が実行される。この認証処理は、エンドエンティテイ（ＥＥ）と、ユーザ識別デバイス（ＵＩＤ）との接続機器インタフェース２３１（図９参照）を介して実行される。この認証処理は、セキュリティチップ、セキュリテイモジュールの暗号処理部（図９参照）を中心とした処理として先に図１３を参照して説明した公開鍵方式に基づく認証処理として実行可能である。ステップＳ１７８において、認証の成立情報を含む認証完了通知がエンドエンティテイ（ＥＥ）に通知され、認証成立を条件として次ステップに進む。
【０２１５】
ステップＳ１７９では、エンドエンティテイ（ＥＥ）からユーザセキュリティチップ（ＵＳＣ）に相互認証開始要求が出力され、ステップＳ１８０において、ＵＳＣと、サービスプロバイダ（ＳＰ）のセキュリティモジュール（ＳＭ）間の相互認証処理が実行される。ステップＳ１８１において、認証の成立情報を含む認証完了通知がＵＳＣからエンドエンティテイ（ＥＥ）に通知され、認証成立を条件として、ユーザ識別デバイス（ＵＩＤ）は、ステップＳ１８２において、サービスプロバイダ（ＳＰ）のセキュリティモジュール（ＳＭ）に対してグループ属性証明書（Ｇｐ．ＡＣ）を提示する。このグループ属性証明書（Ｇｐ．ＡＣ）は、ユーザ識別デバイス（ＵＩＤ）のユーザセキュリティチップ（ＵＳＣ）に対応して発行されたグループ属性証明書（Ｇｐ．ＡＣ）である。
【０２１６】
ユーザセキュリティチップ（ＵＳＣ）からグループ属性証明書（Ｇｐ．ＡＣ）を受信したサービスプロバイダ（ＳＰ）のセキュリティモジュール（ＳＭ）は、ステップＳ１８３において、受信したグループ属性証明書の検証処理を実行する。この検証処理は、図２１〜図２３を参照して説明したと同様の処理である。以下、ステップＳ１８４〜ステップＳ１９８（図２８）の処理は、図２０および図２４を用いて説明したエンドエンティテイのセキュリティチップ（ＳＣ）対応のグループ属性証明書に対する処理と基本的に同様であるので説明を省略する。ただし、図２８に示すステップＳ１９７では、新たなグループ属性証明書の送信は、ユーザ識別デバイス（ＵＩＤ）が実行することになる。
【０２１７】
上述したように、ダイレクトにサービスプロバイダ（ＳＰ）との通信機能を持たないユーザ識別デバイス（ＵＩＤ）がユーザセキュリティチップ（ＵＳＣ）に対応するグループ属性証明書の利用を行なうためには、エンドエンティテイ（ＥＥ）を介する処理が必要となる。その際、ユーザセキュリティチップ（ＵＳＣ）とサービスプロバイダ（ＳＰ）との間で相互に認証を行なうためには、たとえば、
（１）ＥＥのＳＣとサービスプロバイダ（ＳＰ）との相互認証、
（２）ＥＥのＳＣとＵＩＤのＵＳＣとの相互認証、
（３）ＵＩＤのＵＳＣとサービスプロバイダ（ＳＰ）との相互認証、
のすべてが成立することが条件となる。あるいは、簡便な方式として、ＵＩＤがＥＥに接続されることで、ＥＥは基本的にこれを受け入れる（認証したものとする）という処理構成としてもよく、この場合は、上記（２）の相互認証の省略が可能となる。さらに、上記３種の相互認証の様々な組み合わせによる認証構成が可能である。
【０２１８】
なお、図２０および図２４では、エンドエンティテイ（ＥＥ）のセキュリテイチップ（ＳＣ）対応のグループ属性証明書を利用した処理を説明し、図２７、図２８では、ユーザ識別デバイス（ＵＩＤ）のユーザセキュリティチップ（ＵＳＣ）に対応して発行されたグループ属性証明書を利用した処理を説明したが、エンドエンティテイ（ＥＥ）のセキュリテイチップ（ＳＣ）対応のグループ属性証明書と、ユーザ識別デバイス（ＵＩＤ）のユーザセキュリティチップ（ＵＳＣ）に対応して発行されたグループ属性証明書との双方の複数の属性証明書の検証および審査に基づいてサービスを提供する構成、例えば先に図２６を参照して説明したような構成も可能である。この場合は、図２７、図２８に示す処理と、図２０、図２４に示す処理とを組み合わせた処理を実行することになる。
【０２１９】
例えば、サービスプロバイダは、ユーザデバイスとしてのエンドエンティテイ（機器）をグループのメンバとしたグループ定義に基づく第１のグループ属性証明書から取得される第１のグループ識別情報に基づいて、サービス許容対象であるか否かの審査を行うとともに、ユーザ識別デバイスから送付されるユーザをグループのメンバとしたグループ定義に基づく第２のグループ属性証明書から取得される第２のグループ識別情報に基づいて、サービス許容対象であるか否かの審査を行い、全てのグループ識別情報がサービス許容対象であることの判定を条件としてサービス提供可の判定処理を実行する構成が可能である。
【０２２０】
［（４）ユーザデバイス間におけるグループ属性証明書の発行、利用処理］上述した説明において、グループ属性証明書は、主としてサービスプロバイダがユーザデバイスに対して提供するサービスの利用権限を確認するための証明書として適用するものとして説明した。グループ属性証明書の発行主体は、基本的には、グループ属性認証局（グループＡＡ）であるが、サービスプロバイダ（ＳＰ）がグループ属性認証局（グループＡＡ）およびグループＡＲＡの機能を実行し、サービスプロバイダ（ＳＰ）が独自のポリシーの下にグループ属性証明書を発行する形態も可能である。さらにユーザデバイス自身がグループ属性認証局（グループＡＡ）およびグループＡＲＡの機能を実行し、ユーザデバイスが独自のポリシーの下にグループ属性証明書を発行する形態も可能である。以下、ユーザデバイスがグループ属性証明書を発行し、ユーザデバイスに対するアクセス制限をグループ属性証明書を利用して実行する構成について説明する。
【０２２１】
具体的な利用形態としては、例えば通信機能を有する通信処理装置としてのユーザデバイス（エンドエンティテイ）が特定のメンバーからのアクセスのみを許可したい場合、特定メンバーをグループとして設定したグループ属性証明書を発行して、アクセスを要求してきた他のユーザデバイスから、その発行済みのグループ属性証明書の提示を求めて、提示されたグループ属性証明書の検証を実行して、アクセスを許可するアクセス権限管理形態がある。
【０２２２】
このサービス提供形態、すなわちアクセス許可サービスの提供形態は、サービスプロバイダ（ＳＰ）がグループ属性証明書を発行する構成も可能であるが、ユーザデバイスにおいて、例えば特定の友人、家族、同一の会社、学校等のメンバー等をグループとして設定し、設定したグループに対応するグループ識別情報として格納してグループ属性証明書を生成して発行することにより、個人ベースでのアクセス管理が可能となる。
【０２２３】
まず、図２９を参照して、ユーザデバイス間においてグループ属性証明書を発行し、格納する処理について説明する。
【０２２４】
図２９において、ユーザデバイスである通信処理装置としてのエンドエンティテイ（ＥＥ）のセキュリティチップ（ＳＣ）がグループ属性証明書の発行要求主体である場合の処理について説明する。なお、図２９において、
ＵＩＤ：アクセス要求元ユーザ識別デバイス（ユーザデバイス）制御部、
ＵＳＣ：アクセス要求元ＵＩＤ内に構成されるユーザセキュリティチップ、
アクセス元ＥＥ：アクセス要求元エンドエンティテイ（ユーザデバイス）制御部、
ＳＣ１：アクセス要求元ＥＥ内に構成されるセキュリティチップ、
アクセス先ＥＥ：アクセス要求先エンドエンティテイ（ユーザデバイス）制御部、
ＳＣ２：アクセス要求先ＥＥ内に構成されるセキュリティチップ、
である。
【０２２５】
ここでは、アクセス元ＥＥ、アクセス先ＥＥはそれぞれ異なるユーザの通信処理装置である。また、セキュリティチップ（ＳＣ１，ＳＣ２）、ユーザセキュリティチップ（ＵＳＣ）は先に説明した図９のセキュリティチップと同様の構成を持ち、セキュリティチップにおいてグループ属性証明書の検証によるアクセス権限判定処理等が実行される。
【０２２６】
すなわち、アクセス要求元デバイスからアクセス要求先に送付されたグループ属性証明書をネットワークインタフェース等の受信部で受信したアクセス要求先デバイスは、受信したグループ属性証明書をアクセス権限判定処理部としてのセキュリティチップに渡し、セキュリティチップ内で受信したグループ属性証明書に基づいて、アクセス権限判定処理が実行される。
【０２２７】
なお、図２９以下の処理シーケンス図では、アクセス権限を有することを証明するグループ属性証明書の発行処理段階からの処理手続きについて説明する。すなわち、まず、通信処理装置のセキュリティチップがグループ属性証明書生成処理を実行し、アクセス権限を有することを証明するグループ属性証明書の発行処理を行なう。その後、発行されたグループ属性証明書を通信処理装置間で送受信してアクセス権限確認を行なう処理シーケンスである。従って、通信処理装置のセキュリティチップは、グループ属性証明書の生成手段、および検証手段として機能する。
【０２２８】
図２９のシーケンス図に従って処理手順を説明する。まず、ステップＳ２０１において、アクセス要求元のユーザがエンドエンティテイ（アクセス元ＥＥ）の入力インタフェースを介して、グループ属性証明書（Ｇｐ．ＡＣ）の新規発行要求コマンドを入力する。
【０２２９】
エンドエンティテイ（アクセス元ＥＥ）がユーザからのグループ属性証明書（Ｇｐ．ＡＣ）の発行要求の入力を受領すると、ステップＳ２０２において、エンドエンティテイ（アクセス元ＥＥ）は、アクセス要求先のエンドエンティテイ（アクセス先ＥＥ）に対する接続要求を行ない、一方、ステップＳ２０３において、アクセス元エンドエンティテイ（アクセス元ＥＥ）内のセキュリティチップ（ＳＣ）に対して、相互認証開始要求を出力する。
【０２３０】
ステップＳ２０４において、アクセス要求元のユーザデバイスのセキュリティチップ（ＳＣ１）と、アクセス要求先のエンドエンティテイ（アクセス先ＥＥ）に対応するセキュリティチップ（ＳＣ２）間の相互認証が実行される。これは例えば先に図１３を参照して説明した公開鍵方式の相互認証処理として実行される。ステップＳ２０５では、アクセス要求元のセキュリティチップ（ＳＣ１）とユーザセキュリティチップ（ＵＳＣ）間の相互認証が実行され、ステップＳ２０６では、アクセス要求元のユーザセキュリティチップ（ＵＳＣ）と、アクセス要求先のエンドエンティテイ（アクセス先ＥＥ）に対応するセキュリティチップ（ＳＣ２）間の相互認証が実行される。ステップＳ２０７では、アクセス要求元のユーザセキュリティチップ（ＵＳＣ）からエンドエンティテイ（ＥＥ）に対して、相互認証の成立、不成立の結果情報を含む相互認証完了通知が出力される。
【０２３１】
なお、ステップＳ２０５〜Ｓ２０７の処理は、アクセス要求元のユーザセキュリティチップ（ＵＳＣ）に対応するグループ属性証明書を発行する場合に必要となる処理であり、アクセス要求元のセキュリティチップ（ＳＣ１）に対応するグループ属性証明書を発行する場合には省略可能である。
【０２３２】
上記各相互認証のいずれかが不成立の場合は、処理の続行は中止される。すべての相互認証が成立すると、ステップＳ２０８において、アクセス要求元のエンドエンティテイ（ＥＥ）は、アクセス要求先のセキュリティチップ（ＳＣ２）に対して、すでに保有済みのグループ属性証明書（Ｇｐ．ＡＣ）を提示して、新たなグループ属性証明書（Ｇｐ．ＡＣ）の発行要求を行なう。
【０２３３】
ここでの処理は、アクセス要求元がすでに保有するグループ属性証明書（Ｇｐ．ＡＣ）を検証して新たな異なる定義のグループ属性証明書（Ｇｐ．ＡＣ）を発行する処理例である。すなわち新規発行のグループ属性証明書（Ｇｐ．ＡＣ）の発行ポリシーとして、既存のグループ属性証明書（Ｇｐ．ＡＣ）による属性の確認が含まれることになる。例えばユーザ本人であることの確認や、あるいは特定のメーカーの機器であることの確認を既存のグループ属性証明書（Ｇｐ．ＡＣ）に基づいて実行して、これらの確認がなされたことを条件として新規のグループ属性証明書（Ｇｐ．ＡＣ）の発行処理を行なうものである。
【０２３４】
既存のグループ属性証明書（Ｇｐ．ＡＣ）の例としては、例えばユーザ識別デバイス（ＵＩＤ）のユーザセキュリティチップ（ＵＳＣ）との相互認証を行なってユーザに対応して発行されるクレジットカード会社発行のグループ属性証明書がある。また、通信処理装置としての通信端末や、ＰＣ等エンドエンティテイ（ＥＥ）のセキュリティチップ（ＳＣ）との相互認証の結果としてエンドエンティテイ（ＥＥ）に格納されるメーカーの発行するメーカー製の端末であることを証明するグループ属性証明書等がある。
【０２３５】
アクセス要求先デバイスのセキュリティチップ（ＳＣ２）は、アクセス要求元デバイスのエンドエンティテイ（ＥＥ）から受領した既発行のグループ属性証明書を検証する。この検証処理は、先に図２１〜図２３を参照して説明したと同様の処理であり、属性証明書の署名検証、対応および連鎖公開鍵証明書の検証等を含む処理である。
【０２３６】
アクセス要求先セキュリティチップ（ＳＣ２）は、検証結果をアクセス要求先エンドエンティテイ（ＥＥ）に出力し、検証不成功の場合は、エラー処理として、その後の処理を実行せず処理を中止する。この場合、エラー通知をアクセス要求元エンドエンティテイ（ＥＥ）に送信する処理を行なってもよい。
【０２３７】
グループ属性証明書（Ｇｐ．ＡＣ）の検証が成功し、グループ属性証明書（Ｇｐ．ＡＣ）の正当性が確認されるとステップＳ２１１に進む。ステップＳ２１１では、グループ属性証明書（Ｇｐ．ＡＣ）の審査を実行する。審査は、アクセス要求先エンドエンティテイ（ＥＥ）の保有するグループ情報データベースに基づいて実行する。この審査処理は、先に図２５を参照して説明した処理と同様の処理である。すなわち、検証済みのグループ属性証明書（Ｇｐ．ＡＣ）から発行者情報、グループ識別情報（グループＩＤ）を取得し、取得したＡＣ発行者、およびグループＩＤに基づいて、グループ情報データベースを検索し、登録されたエントリーの有無を確認する。対応する登録エントリーがある場合は、グループ情報データベースからグループ情報を取得する。
【０２３８】
グループ属性証明書（Ｇｐ．ＡＣ）に対応するグループ情報が登録されていない場合、あるいはグループ情報の条件を満たさない場合は、審査不成功となり、エラーとして処理を中止する。一方、審査成功の場合はステップＳ２１２において、要求に従って、新たなグループ属性証明書の生成要求をセキュリティチップ（ＳＣ２）に出力し、セキュリティチップ（ＳＣ２）は、ステップＳ２１３において、要求に従って、グループ属性証明書を生成して、ステップＳ２１４において、アクセス先エンドエンティテイ（ＥＥ）からアクセス要求元ユーザデバイスのユーザ識別デバイス（ＵＩＤ）に対して新たなグループ属性証明書（Ｇｐ．ＡＣ）を発行する。
【０２３９】
この新規発行グループ属性証明書は、例えば、アクセス要求先ユーザデバイスが会社Ｂのセキュアな情報を格納したＰＣ等の通信端末装置である場合、属性として、
「会社ＢからＵＩＤに発行された“会社Ｂの社員”という属性」
「会社ＢからＵＩＤに発行された“Ｃプロジェクトのメンバ”という属性」
等の属性に対応するものとなる。
【０２４０】
会社Ｂのセキュアな情報を格納したＰＣ等の通信端末装置であるアクセス要求先ユーザデバイスは、不特定のユーザデバイスからのアクセス要求時に、グループ属性証明書の提示を要求して、提示されたグループ属性証明書の検証、審査を実行してアクセスの可否を決定することが可能となる。
【０２４１】
次に、図３０を参照してアクセス許可情報を属性として持つグループ属性証明書の発行処理シーケンスについて説明する。図３０において、ステップＳ２２１〜Ｓ２３５は、図２９におけるステップＳ２０１〜Ｓ２１５に対応し、その処理も同様である。
【０２４２】
図３０では、ステップＳ２２８において、アクセス要求元エンドエンティテイ（アクセス元ＥＥ）がアクセス要求先ユーザデバイスのセキュリティチップ（ＳＣ２）に対して提示するグループ属性証明書が、「会社ＢからＵＩＤに発行された“会社Ｂの社員”という属性」を持つ証明書であり、アクセス要求先ユーザデバイスのセキュリティチップ（ＳＣ２）は、この属性証明書の検証、審査を実行して、新たなグループ属性証明書、すなわち、属性として、この機器（アクセス要求先ユーザデバイス）に対するアクセス可とした属性情報を持つ証明書を発行する構成である。
【０２４３】
なお、この機器（アクセス要求先ユーザデバイス）に対するアクセス可としたグループ情報としての属性情報を持つ証明書を発行する条件として、「会社ＢからＵＩＤに発行された“会社Ｂの社員”という属性」を持つグループ属性証明書以外に、他のグループ属性証明書による証明が必要な場合は、ステップＳ２２８〜Ｓ２３１の処理を必要なグループ属性証明書の数に対応する回数繰り返し実行する。
【０２４４】
図３１を参照して、アクセス許可情報をグループ情報として持つグループ属性証明書と、他のグループ属性証明書との対応例について説明する。（ａ）は、アクセス許可情報をグループ情報として持つグループ属性証明書は、グループδに対応し、例えばこのグループδに対応するグループ属性証明書の発行条件は、グループαのメンバーであることが条件となる。例えばグループαのメンバーであることは、「会社ＢからＵＩＤに発行された“会社Ｂの社員”という属性」を証明するグループ属性証明書によって証明可能であり、グループδに対応するグループ属性証明書は、グループαのメンバーであることを証明するグループ属性証明書が提示され、その検証、審査が成功したことを条件として発行されることになる。
【０２４５】
図３１（ｂ）は、アクセス許可情報をグループ情報として持つグループ属性証明書は、グループδに対応し、例えばこのグループδに対応するグループ属性証明書の発行条件は、グループαのメンバーであり、グループβのメンバーであり、グループγのメンバーであることすべての条件を満足することが条件となる。
【０２４６】
具体的には、例えばユーザの居住地が特定の地域に属することを証明するグループ属性証明書α（グループα）と、ユーザ機器が特定メーカーの機器であることを示すグループ属性証明書β（グループβ）と、さらに、ユーザの年齢が所定の範囲に属することを示すグループ属性証明書γ（グループγ）の３つのグループ属性証明書の提示、検証によりグループδに対応するアクセス許可情報をグループ情報として持つグループ属性証明書を発行するといった設定である。
【０２４７】
なお、アクセス要求元デバイスを構成する個人識別デバイスとしてのユーザ識別デバイスに対してグループ属性証明書を発行することにより、通信処理装置としてのエンドエンティテイ（ＥＥ）を変更した場合であっても、個人識別デバイスとしてのユーザ識別デバイスに対して発行したグループ属性証明書に基づく審査においてアクセスを許可することが可能となり、通信処理装置（エンドエンティテイ（ＥＥ））の変更によってアクセスが拒否されてしまうといったことを防止できる。
【０２４８】
次に、図３２を参照して、アクセス要求先ユーザデバイスが、自ら属性証明書の発行処理を実行せずに属性証明書の発行処理を他のユーザデバイスに依頼して実行する処理シーケンスについて説明する。図３２において、
ＵＩＤ：アクセス要求元ユーザ識別デバイス（ユーザデバイス）制御部、
ＵＳＣ：アクセス要求元ＵＩＤ内に構成されるユーザセキュリティチップ、
アクセス元ＥＥ：アクセス要求元エンドエンティテイ（ユーザデバイス）制御部、
ＳＣ１：アクセス要求元ＥＥ内に構成されるセキュリティチップ、
アクセス先ＥＥ：アクセス要求先エンドエンティテイ（ユーザデバイス）制御部、
ＳＣ２：アクセス要求先ＥＥ内に構成されるセキュリティチップ、
他ＥＥ：第３のユーザデバイス（手続き代行ユーザデバイス）
ＳＣ３：他ＥＥのセキュリティチップ、
である。
【０２４９】
図３２において、ステップＳ２４１〜Ｓ２４８は、図２９におけるステップＳ２０１〜Ｓ２０８に対応し、その処理も同様であり、説明を省略する。ステップＳ２４８において、アクセス要求先ユーザデバイスのエンドエンティテイ（アクセス先ＥＥ）は、アクセス要求元エンドエンティテイ（アクセス元ＥＥ）から提示されたグループ属性証明書を手続き代行ユーザデバイスのセキュリティチップ（ＳＣ３）に転送し、セキュリティチップ（ＳＣ３）が転送されたグループ属性証明書の検証（Ｓ２５０）を実行し、手続き代行ユーザデバイスのエンドエンティテイ（他ＥＥ）が検証結果通知（Ｓ２５１）に基づいて、さらに審査（Ｓ２５２）を実行する。
【０２５０】
さらに、検証、審査に成功したことを条件として、グループ属性証明書の生成要求をセキュリティチップ（ＳＣ３）に出力（Ｓ２５３）し、セキュリティチップ（ＳＣ３）は、ステップＳ２５４において、要求に従って、グループ属性証明書を生成して、ステップＳ２５５において、手続き代行エンドエンティテイ（他ＥＥ）からアクセス要求元ユーザデバイスのユーザ識別デバイス（ＵＩＤ）に対して新たなグループ属性証明書（Ｇｐ．ＡＣ）を発行し、ステップＳ２５７においてアクセス要求元ユーザデバイスのユーザ識別デバイス（ＵＩＤ）が受領したグループ属性証明書を格納する。
【０２５１】
図３２に示す処理シーケンスは、アクセス要求先ユーザデバイスが属性証明書の検証、審査、および発行機能を持たない場合に第３のデバイスにこれらの処理を委託して実行可能とした構成である。なお、手続き代行ユーザデバイスは、サービスプロバイダ（ＳＰ）等によって構成してもよい。
【０２５２】
次に、アクセス許可情報をグループ情報として定義したグループ属性証明書を利用したアクセス可否判定処理を伴うサービス利用シーケンスについて、図３３を参照して説明する。
【０２５３】
まず、ステップＳ２６１において、アクセス要求元のユーザがエンドエンティテイ（アクセス元ＥＥ）の入力インタフェースを介して、グループ属性証明書（Ｇｐ．ＡＣ）の利用処理としてのアクセス要求コマンドを入力する。
【０２５４】
エンドエンティテイ（アクセス元ＥＥ）がユーザからの要求を受領すると、ステップＳ２６２において、エンドエンティテイ（アクセス元ＥＥ）は、アクセス要求先のエンドエンティテイ（アクセス先ＥＥ）に対する接続要求を行ない、一方、ステップＳ２６３において、アクセス元エンドエンティテイ（アクセス元ＥＥ）内のセキュリティチップ（ＳＣ１）に対して、相互認証開始要求を出力する。
【０２５５】
ステップＳ２６４において、アクセス要求元のユーザデバイスのセキュリティチップ（ＳＣ１）と、アクセス要求先のエンドエンティテイ（アクセス先ＥＥ）に対応するセキュリティチップ（ＳＣ２）間の相互認証が実行される。これは例えば先に図１３を参照して説明した公開鍵方式の相互認証処理として実行される。ステップＳ２６５では、アクセス要求元のセキュリティチップ（ＳＣ１）とユーザセキュリティチップ（ＵＳＣ）間の相互認証が実行され、ステップＳ２６６では、アクセス要求元のユーザセキュリティチップ（ＵＳＣ）と、アクセス要求先のエンドエンティテイ（アクセス先ＥＥ）に対応するセキュリティチップ（ＳＣ２）間の相互認証が実行される。ステップＳ２６７では、アクセス要求元のユーザセキュリティチップ（ＵＳＣ）からエンドエンティテイ（ＥＥ）に対して、相互認証の成立、不成立の結果情報を含む相互認証完了通知が出力される。
【０２５６】
なお、ステップＳ２６５〜Ｓ２６７の処理は、アクセス要求元のユーザセキュリティチップ（ＵＳＣ）に対応するグループ属性証明書を利用した処理の場合に必要となる処理であり、アクセス要求元のセキュリティチップ（ＳＣ１）に対応するグループ属性証明書を利用した処理の場合には省略可能である。
【０２５７】
上記各相互認証のいずれかが不成立の場合は、処理の続行は中止される。すべての相互認証が成立すると、ステップＳ２６８において、アクセス要求元のエンドエンティテイ（ＥＥ）は、アクセス要求先のセキュリティチップ（ＳＣ２）に対して、グループ属性証明書（Ｇｐ．ＡＣ）を提示して、アクセス許可を要求する。
【０２５８】
アクセス要求先のセキュリティチップ（ＳＣ２）は、アクセス要求元のエンドエンティテイ（ＥＥ）から受領したグループ属性証明書を検証（Ｓ２６９）する。この検証処理は、先に図２１〜図２３を参照して説明したと同様の処理であり、属性証明書の署名検証、対応および連鎖公開鍵証明書の検証等を含む処理である。
【０２５９】
アクセス要求先セキュリティチップ（ＳＣ２）は、検証結果をアクセス要求先エンドエンティテイ（ＥＥ）に出力（Ｓ２７０）し、検証不成功の場合は、エラー処理として、その後の処理を実行せず処理を中止する。この場合、エラー通知をアクセス要求元エンドエンティテイ（ＥＥ）に送信する処理を行なってもよい。
【０２６０】
グループ属性証明書（Ｇｐ．ＡＣ）の検証が成功し、グループ属性証明書（Ｇｐ．ＡＣ）の正当性が確認されるとステップＳ２７１に進む。ステップＳ２７１では、グループ属性証明書（Ｇｐ．ＡＣ）の審査を実行する。審査は、アクセス要求先エンドエンティテイ（ＥＥ）の保有するグループ情報データベースに基づいて実行する。この審査処理は、先に図２５を参照して説明した処理と同様の処理である。すなわち、検証済みのグループ属性証明書（Ｇｐ．ＡＣ）から発行者情報、グループＩＤを取得し、取得したＡＣ発行者、およびグループＩＤに基づいて、グループ情報データベースを検索し、登録されたエントリーの有無を確認する。対応する登録エントリーがある場合は、グループ情報データベースからグループ情報を取得する。グループ情報には、例えば「この機器にアクセス可」、あるいは「データ読み出しのみ可」等の情報が含まれ、これらの情報に従ってサービスが提供される。
【０２６１】
グループ属性証明書（Ｇｐ．ＡＣ）に対応するグループ情報が登録されていない場合、あるいはグループ情報の条件を満足しない場合は、審査不成功となり、エラーとして処理を中止する。一方、審査成功の場合はステップＳ２７２において、サービス提供、すなわち、グループ情報として登録されたサービス、例えば機器に対するアクセスを許可する。
【０２６２】
［（５）グループ属性証明書の具体的利用例］
次に、グループ属性証明書の具体的利用例について説明する。以下、利用形態を、
（５−１）コンテンツ配信サービス
（５−２）リモートコントロールサービス
（５−３）リモートメンテナンスサービス
（５−４）パーソナルコミュニュケーションサービス
以上の各利用形態について各々説明する。
【０２６３】
上記の各サービスにおいて利用されるグループ属性証明書の例を図３４に示す。図３４には、グループ属性証明書の発行者、発行タイミング、所有者、検証者、属性を対応付けて示してある。発行者は、前述したように、グループ属性証明書の発行処理のみを実行するグループＡＲＡの他、サービスプロバイダ、ユーザデバイス等、様々な発行主体が可能であり、サービスプロバイダとしては、例えばクレジットカードを発行する「カード会社Ａ」、所定の組織、例えば「会社Ｂ」、「役所」、さらにユーザ個人としての「甲さん」、さらにＰＣ、通信端末、ゲーム機等のエンドエンティテイ（ＥＥ）を製造する「ＥＥメーカーＣ」等がある。
【０２６４】
グループ属性証明書の発行タイミングは、任意のタイミング、ＰＣ、通信端末、ゲーム機等のエンドエンティテイ（ＥＥ）の購入時、製造時、購入後等、証明書に基づいて提供するサービスに応じて、様々な設定が可能である。
【０２６５】
グループ属性証明書の所有者は、所定のグループのメンバとしてのユーザ、あるいはユーザ機器であり、ユーザ、例えば「甲さん」を所有者として発行されるグループ属性証明書は、甲さんのユーザ識別デバイス（ＵＩＤ）のユーザセキュリティチップ（ＵＳＣ）を対象としてユーザセキュリティチップ（ＵＳＣ）の認証に基づいて発行され、例えばある家族の各メンバに提供されるグループ属性証明書は、家族各々のユーザ識別デバイス（ＵＩＤ）のユーザセキュリティチップ（ＵＳＣ）を対象としてユーザセキュリティチップ（ＵＳＣ）の認証に基づいて発行され、また、ＰＣ、通信端末、ゲーム機等のユーザ機器、すなわちエンドエンティテイ（ＥＥ）を対象として提供されるグループ属性証明書は、エンドエンティテイ（ＥＥ）のセキュリティチップ（ＳＣ）を対象としてユーザセキュリティチップ（ＵＳＣ）の認証に基づいて発行される。
【０２６６】
これらのグループ属性証明書の検証処理の実行者は、グループ属性証明書によって証明される属性に基づいてサービスを提供するサービスプロバイダ（ＳＰ）のセキュリティモジュール（ＳＭ）、あるいは図には示されていないが、ユーザデバイスのセキュリティチップ（ＳＣ，ＵＳＣ）である。
【０２６７】
各グループ属性証明書の証明する所有者属性は、例えば「カード会社Ａ会員」、「会社Ｂの社員」、「甲さんの家族」、「登録されたユーザ」、「登録されたユーザデバイス」、「属性証明書発行者の所有機器（ＥＥ）」、「甲さんの所有機器（ＥＥ）」等であり、グループ属性証明書の検証、審査により、グループ属性証明書の提示ユーザまたは提示機器について、上記の各属性が証明されることになる。サービスプロバイダ等の属性証明書検証者は、証明された所有者属性に基づいて所定のサービスを提供する。
【０２６８】
（５−１）コンテンツ配信サービス
まず、グループ属性証明書を利用したコンテンツ配信サービスについて説明する。コンテンツ配信におけるコンテンツの利用権限について、グループ属性証明書を適用して確認する態様としては、様々な態様がある。
【０２６９】
まず、一例として、クレジットカード会社の発行するクレジットカード会員であることを証明する第１のグループ属性証明書Ａに基づいて、コンテンツの利用許可情報をグループ情報として含むコンテンツ配信サービス主体であるコンテンツ配信サービスプロバイダの発行する第２のグループ属性証明書Ｂの発行を行ない、この第２のグループ属性証明書Ｂを適用してコンテンツ利用権限の確認を実行してコンテンツ配信サービスを実行する処理例について説明する。
【０２７０】
図３５を参照して、ユーザデバイスが、クレジットカード会員であることを証明する第１のグループ属性証明書Ａに基づいて、コンテンツの利用許可情報をグループ情報として含む第２のグループ属性証明書Ｂを発行する処理について説明する。
【０２７１】
図３５の例においては、ユーザ識別デバイス（ＵＩＤ）のユーザセキュリティチップ（ＵＳＣ）を対象として発行したクレジットカード会員であることを証明する第１のグループ属性証明書Ａをグループ属性証明書登録局（Ｇｐ．ＡＲＡ）に提示して、グループ属性認証局（Ｇｐ．ＡＡ）からコンテンツ配信サービスプロバイダが発行主体である第２のグループ属性証明書Ｂの発行処理例である。ここでは、コンテンツ配信サービスプロバイダは、グループ属性証明書登録局（Ｇｐ．ＡＲＡ）と、グループ属性証明書発行ポリシーについて合意しているものとする。
【０２７２】
図３５において、
ＵＩＤ：ユーザ識別デバイス（ユーザデバイス）制御部、
ＵＳＣ：ＵＩＤ内に構成されるユーザセキュリティチップ、
ＥＥ：エンドエンティテイ（ユーザデバイス）制御部、
ＳＣ：ＥＥ内に構成されるセキュリティチップ、
グループＡＲＡ：グループ属性証明書登録局制御部、
グループＡＡ：グループ属性認証局制御部、
である。
【０２７３】
まず、ステップＳ３０１において、ユーザがエンドエンティテイ（ＥＥ）の入力インタフェースを介して、グループ属性証明書（Ｇｐ．ＡＣ）の発行要求コマンドを入力する。この際、ユーザはグループ属性証明書発行に必要となる属性値を入力する。属性値は、グループＩＤ、あるいはグループに属することを証明する情報等である。
【０２７４】
エンドエンティテイ（ＥＥ）がユーザからのグループ属性証明書（Ｇｐ．ＡＣ）の発行要求の入力を受領すると、ステップＳ３０２において、ユーザセキュリティチップ（ＵＳＣ）と、グループＡＲＡ間の相互認証が実行される。なお、ここでは省略して示してあるが、ダイレクトにグループＡＲＡとの通信機能を持たないユーザ識別デバイス（ＵＩＤ）の場合は、
（１）ＥＥのＳＣとグループＡＲＡとの相互認証、
（２）ＥＥのＳＣとＵＩＤのＵＳＣとの相互認証、
（３）ＵＩＤのＵＳＣとグループＡＲＡとの相互認証、
のすべてを実行することになる。あるいは、簡便な方式として、ＵＩＤがＥＥに接続されることで、ＥＥは基本的にこれを受け入れる（認証したものとする）という処理構成としてもよく、この場合は、上記（２）の相互認証の省略が可能となる。さらに、上記３種の相互認証の様々な組み合わせによる認証構成が可能である。
【０２７５】
認証処理は、各デバイスのセキュリティチップの暗号処理部（図９参照）における暗号処理を主とした処理によって実行され、例えば先に図１３を参照して説明した公開鍵方式の相互認証処理として実行される。ステップＳ３０３では、ユーザセキュリティチップ（ＵＳＣ）からエンドエンティテイに対して、相互認証の成立、不成立の結果情報を含む相互認証完了通知が出力される。相互認証不成立の場合は、処理の続行は中止される。相互認証が成立すると、ステップＳ３０４において、エンドエンティテイ（ＥＥ）は、グループＡＲＡに対してグループ属性証明書（Ｇｐ．ＡＣ）発行要求を送信する。このグループ属性証明書（Ｇｐ．ＡＣ）発行要求には、エンドエンティテイ情報、属性値（例えばグループＩＤ、グループ情報）が含まれ、さらに、コンテンツ配信サービスプロバイダが発行主体である第２のグループ属性証明書Ｂの発行条件として提示すべき、クレジットカード会員であることを証明する第１のグループ属性証明書Ａが含まれる。
【０２７６】
エンドエンティテイ（ＥＥ）からグループ属性証明書（Ｇｐ．ＡＣ）発行要求を受信したグループＡＲＡは、クレジットカード会員であることを証明する第１のグループ属性証明書Ａの検証の後、ステップＳ３０５において、発行ポリシーテーブルを参照して、ポリシーに準拠したグループ属性証明書の発行が可能か否かを判定し、可であれば、ステップＳ３０６に進み、不可であれば、発行不可メッセージをエンドエンティテイに通知する。
【０２７７】
ステップＳ３０６では、グループＡＲＡが属性値（グループＩＤ）を伴うグループ属性証明書（Ｇｐ．ＡＣ）発行要求をグループＡＡに送信し、ステップＳ３０７において、グループＡＡが、グループＩＤを属性情報として格納し、電子署名を施したグループ属性証明書、すなわち、コンテンツの利用許可情報をグループ情報として含む第２のグループ属性証明書Ｂを生成し、グループＡＲＡに送信する。
【０２７８】
ステップＳ３０８において、グループＡＲＡが、発行されたグループ属性証明書Ｂ（Ｇｐ．ＡＣ）をユーザ識別デバイス（ＵＩＤ）に送信する。ユーザ識別デバイス（ＵＩＤ）は、受信したグループ属性証明書（Ｇｐ．ＡＣ）をメモリに格納する。この際、グループ属性証明書（Ｇｐ．ＡＣ）の電子署名の検証を実行して、改竄の無いことを確認した後、メモリに格納する。
【０２７９】
次に、図３６を参照して、上述の処理によって発行されたグループ属性証明書Ｂ、すなわちコンテンツの利用許可情報をグループ情報として含む第２のグループ属性証明書Ｂをサービスプロバイダに提示して、コンテンツ利用権限のあることの確認を行なって、サービス提供、すなわちコンテンツ配信サービスを受領する処理について説明する。図３６において、
ＵＩＤ：ユーザ識別デバイス（ユーザデバイス）制御部、
ＵＳＣ：ＵＩＤ内に構成されるユーザセキュリティチップ、
ＥＥ：エンドエンティテイ（ユーザデバイス）制御部、
ＳＣ：ＥＥ内に構成されるセキュリティチップ、
ＳＰ：サービスプロバイダ制御部、
ＳＭ：ＳＰ内のセキュリティモジュール、
である。
【０２８０】
セキュリティチップ（ＳＣ）、ユーザセキュリティチップ（ＵＳＣ）、セキュリティモジュール（ＳＭ）は先に説明した図９のセキュリティチップと同様の構成を持ち、セキュリティチップにおいてグループ属性証明書の検証による権限判定処理等が実行される。すなわち、サービス要求元デバイスからサービス要求先に送付されたグループ属性証明書をネットワークインタフェース等の受信部で受信したサービスプロバイダは、受信したグループ属性証明書を権限判定処理部としてのセキュリティモジュール（チップ）に渡し、セキュリティモジュール（チップ）内で受信したグループ属性証明書に基づいて、権限判定処理が実行される。
【０２８１】
まず、ステップＳ３１１において、ユーザがエンドエンティテイ（ＥＥ）の入力インタフェースを介して、グループ属性証明書（Ｇｐ．ＡＣ）の利用要求コマンドを入力する。この際、ユーザは利用するグループ属性証明書に設定されたグループＩＤを指定する。ただし、特定のサービスを指定することにより唯一のグループＩＤが決定可能である場合は、サービスの指定のみとしてもよい。
【０２８２】
エンドエンティテイ（ＥＥ）がユーザからのグループ属性証明書（Ｇｐ．ＡＣ）の利用要求入力を受領すると、ステップＳ３１２において、ユーザセキュリティチップ（ＵＳＣ）と、サービスプロバイダのセキュリティモジュール（ＳＭ）間の相互認証が実行される。なお、ここでは省略して示してあるが、ダイレクトにＳＰとの通信を実行できないユーザ識別デバイス（ＵＩＤ）の場合は、
（１）ＥＥのＳＣとＳＰ−ＳＭとの相互認証、
（２）ＥＥのＳＣとＵＩＤのＵＳＣとの相互認証、
（３）ＵＩＤのＵＳＣとＳＰ−ＳＭとの相互認証、
のすべてを実行することになる。あるいは、簡便な方式として、ＵＩＤがＥＥに接続されることで、ＥＥは基本的にこれを受け入れる（認証したものとする）という処理構成としてもよく、この場合は、上記（２）の相互認証の省略が可能となる。さらに、上記３種の相互認証の様々な組み合わせによる認証構成が可能である。
【０２８３】
認証処理は、セキュリティチップ、セキュリテイモジュールの暗号処理部を中心として先に図１３を参照して説明した公開鍵方式の相互認証処理として実行される。ステップＳ３１３では、セキュリティチップからエンドエンティテイに対して、相互認証の成立、不成立の結果情報を含む相互認証完了通知が出力される。相互認証不成立の場合は、処理の続行は中止される。相互認証が成立すると、ステップＳ３１４において、ユーザセキュリティチップ（ＵＳＣ）は、サービスプロバイダ（ＳＰ）のセキュリティモジュール（ＳＭ）に対して自己のメモリに格納したグループ属性証明書（Ｇｐ．ＡＣ）を送信する。このグループ属性証明書（Ｇｐ．ＡＣ）は、先に図３５を参照して説明した処理により取得したコンテンツの利用許可情報をグループ情報として含む第２のグループ属性証明書Ｂである。
【０２８４】
ユーザセキュリティチップ（ＵＳＣ）からグループ属性証明書（Ｇｐ．ＡＣ）を受信したセキュリティモジュール（ＳＭ）は、ステップＳ３１５において、グループ属性証明書検証処理を実行する。グループ属性証明書の検証処理については、先に図２１乃至図２３を参照して説明した通りであり、属性証明書の署名検証、関連の公開鍵証明書（ＰＫＣ）および連鎖公開鍵証明書の確認処理等を含む処理として実行される。
【０２８５】
グループ属性証明書（Ｇｐ．ＡＣ）の検証処理後、セキュリティモジュール（ＳＭ）は、検証結果をサービスプロバイダ（ＳＰ）に出力し、検証不成立の場合は、エラー処理として、サービス提供を実行せず処理を中止する。この場合、グループＡＣの検証が不成立であった旨をエンドエンティテイ通知する処理を実行してもよい。
【０２８６】
グループ属性証明書（Ｇｐ．ＡＣ）の検証が成功し、グループ属性証明書（Ｇｐ．ＡＣ）の正当性が確認されるとステップＳ３１７に進む。ステップＳ３１７では、先に図２５を参照して説明したグループ属性証明書（Ｇｐ．ＡＣ）の審査を実行する。審査は、サービスプロバイダの保有するグループ情報データベースに基づいて実行する。すなわち、サービスプロバイダ（ＳＰ）は、検証済みのグループ属性証明書（Ｇｐ．ＡＣ）から発行者情報、グループＩＤを取得し、取得情報に基づいて、グループ情報データベースを検索し、登録されたエントリーの有無を確認する。対応する登録エントリーがある場合は、グループ情報データベースからグループ情報を取得する。
【０２８７】
この場合のグループ情報は、コンテンツの利用許可情報をグループ情報、例えばコンテンツとしてのゲームＸを３ヶ月利用可能とする情報等である。サービスプロバイダ（ＳＰ）は、ステップＳ３１８において、サービス提供処理、すなわち、グループ情報に従って、３ヶ月の利用期間を設定したゲームプログラムをユーザデバイスのエンドエンティテイ（ＥＥ）に対して配信する。
【０２８８】
上述したコンテンツ配信サービス処理は、１つのグループ属性証明書によってコンテンツ利用権の確認を行なう例であったが、次に、異なるグループ属性を証明する複数の異なる属性証明書を適用してユーザあるいはユーザ機器のコンテンツ利用権を確認してサービスを提供する処理例について説明する。
【０２８９】
図３７に本処理例で適用する複数のグループ属性証明書を示す。グループ属性証明書（Ｇｐ．ＡＣ）ＡＣ０１は、Ａ大学によって発行され、Ａ大学の学生であることを証明する学生証であり、Ｃ君のユーザ識別デバイス（ＵＩＤ）のユーザセキュリティチップ（ＵＳＣ）との認証に基づいて発行されたグループ属性証明書（Ｇｐ．ＡＣ）である。グループ属性証明書（Ｇｐ．ＡＣ）ＡＣ０２は、Ａ大学によって発行され、美術講座の受講権利を有することを証明する美術講座受講証であり、Ｃ君のユーザ識別デバイス（ＵＩＤ）のユーザセキュリティチップ（ＵＳＣ）との認証に基づいて発行されたグループ属性証明書（Ｇｐ．ＡＣ）である。
【０２９０】
グループ属性証明書（Ｇｐ．ＡＣ）ＡＣ０３は、Ａ大学によって発行され、Ａ大学の管理する機器であることを証明する管理機器証明書であり、エンドエンティテイ（ＥＥ）としてのテレビＤのセキュリティチップ（ＳＣ）との認証に基づいて発行されたグループ属性証明書（Ｇｐ．ＡＣ）である。グループ属性証明書（Ｇｐ．ＡＣ）ＡＣ０４は、文部科学省によって発行され、教育使用目的の機器であることを証明する教育用機器証明書であり、エンドエンティテイ（ＥＥ）としてのテレビＤのセキュリティチップ（ＳＣ）との認証に基づいて発行されたグループ属性証明書（Ｇｐ．ＡＣ）である。
【０２９１】
これらＡＣ０１〜ＡＣ０４の４種類の異なるグループ属性証明書を適用したコンテンツ利用権限確認および、サービス提供処理について図３８を参照して説明する。
【０２９２】
図３８は、ユーザデバイス側処理を左に、サービスプロバイダ側処理を右側に示している。なお、ユーザデバイスは、エンドエンティテイ（ＥＥ）、ＥＥ内に構成されるセキュリティチップ（ＳＣ）、ユーザ識別デバイス（ＵＩＤ）、ＵＩＤ内に構成されるユーザセキュリティチップ（ＵＳＣ）を含む。
【０２９３】
ステップＳ３２１，Ｓ３３１において、ユーザデバイスと、サービスプロバイダ間の相互認証処理が実行される。なお、相互認証は、提示するグループ属性証明書の発行対象機に応じて実行し、ＥＥのＳＣとＳＰ−ＳＭとの相互認証、あるいは、ＵＩＤのＵＳＣとＳＰ−ＳＭとの相互認証のいずれか、あるいはその双方が実行される。
【０２９４】
本例の場合は、図３７に示す４つのグループ属性証明書中ＡＣ０１，ＡＣ０２は、Ｃ君のユーザ識別デバイス（ＵＩＤ）のユーザセキュリティチップ（ＵＳＣ）を対象として発行されたものであり、ＡＣ０３，ＡＣ０４は、エンドエンティテイ（ＥＥ）としてのテレビＤに構成されるセキュリティチップ（ＳＣ）に対して発行されているものであるので、処理としては、Ｃ君のユーザ識別デバイス（ＵＩＤ）をエンドエンティテイ（ＥＥ）としてのテレビＤに接続機器インタフェース２３１（図９参照）を介して接続し、エンドエンティテイ（ＥＥ）としてのテレビＤのネットワークインタフェース２３２（図９参照）を介してサービスプロバイダ（ＳＰ）のセキュリティモジュール（ＳＭ）と接続し、ＥＥのＳＣとＳＰ−ＳＭとの相互認証、および、ＵＩＤのＵＳＣとＳＰ−ＳＭとの相互認証の双方を実行する。
【０２９５】
認証処理は、セキュリティチップ、セキュリテイモジュールの暗号処理部を中心とした処理として例えば先に図１３を参照して説明した公開鍵方式の相互認証処理として実行される。相互認証不成立の場合は、処理の続行は中止される。相互認証が成立すると、ステップＳ３２２において、ユーザデバイスは、サービスプロバイダ（ＳＰ）のセキュリティモジュール（ＳＭ）に対して自己のメモリに格納した複数のグループ属性証明書（Ｇｐ．ＡＣ）ＡＣ０１〜ＡＣ０４を送信する。このグループ属性証明書（Ｇｐ．ＡＣ）ＡＣ０１〜ＡＣ０４は、図３７に示す４種類のグループ属性証明書である。
【０２９６】
なお、サービス提供にあたり、必要となるグループ属性証明書の組み合わせデータは、サービスプロバイダ側からユーザ側に通知する構成としてもよい。サービスプロバイダは、例えば図３９に示すサービス提供条件として設定されるグループ属性証明書の組み合わせテーブルデータを保有する。図３９に示す例では、例えばサービスとしてコンテンツＢの視聴のためには、Ａ大学発行の学生証としてのグループ属性証明書、文部科学省発行の教育用機器証明書としてのグループ属性証明書等が必要であることを示すデータが格納され、このテーブルを適用して、必要となるグループ属性証明書の提示をユーザデバイスに対して通知する。
【０２９７】
ステップＳ３３２において、ユーザデバイスから本例におけるサービス提供に必要となる４種類のグループ属性証明書（Ｇｐ．ＡＣ）ＡＣ０１〜ＡＣ０４を受信したセキュリティモジュール（ＳＭ）は、ステップＳ３３３において、複数のグループ属性証明書から、順次１つのグループ属性証明書を選択し、検証処理を実行する。グループ属性証明書の検証処理については、先に図２１乃至図２３を参照して説明した通りであり、属性証明書の署名検証、関連の公開鍵証明書（ＰＫＣ）および連鎖公開鍵証明書の確認処理等を含む処理として実行される。
【０２９８】
グループ属性証明書（Ｇｐ．ＡＣ）の検証処理後、検証不成立（Ｓ３３４：Ｎｏ）の場合は、エラー処理（Ｓ３３９）として、サービス提供を実行せず処理を中止する。この場合、グループＡＣの検証が不成立であった旨をエンドエンティテイ通知する処理を実行してもよい。
【０２９９】
グループ属性証明書（Ｇｐ．ＡＣ）の検証が成立（Ｓ３３４：Ｙｅｓ）し、グループ属性証明書（Ｇｐ．ＡＣ）の正当性が確認されるとステップＳ３３５に進む。ステップＳ３３５では、先に図２５を参照して説明したグループ属性証明書（Ｇｐ．ＡＣ）の審査を実行する。審査は、サービスプロバイダの保有するグループ情報データベースに基づいて実行する。すなわち、サービスプロバイダ（ＳＰ）は、検証済みのグループ属性証明書（Ｇｐ．ＡＣ）から発行者情報、グループＩＤを取得し、取得情報に基づいて、グループ情報データベースを検索し、登録されたエントリーの有無を確認する。対応する登録エントリーがある場合は、グループ情報データベースからグループ情報を取得する。この場合のグループ情報は、コンテンツの配信許可情報を含む情報である。
【０３００】
グループ属性証明書の審査が不成立（Ｓ３３６：Ｎｏ）の場合、例えば、グループ情報の取得に失敗した場合は、エラー処理（Ｓ３３９）として、サービス提供を実行せず処理を中止する。この場合、グループＡＣの検証が不成立であった旨をエンドエンティテイ通知する処理を実行してもよい。
【０３０１】
グループ属性証明書の審査が成立（Ｓ３３６：Ｙｅｓ）した場合、ステップＳ３３７に進み、提示されたグループ属性証明書の全ての検証、審査が終了したか否かを判定し、未終了分がある場合は、ステップＳ３３３以下の検証、審査処理を未終了分のグループ属性証明書について実行する。
【０３０２】
ステップＳ３３７において、提示されたグループ属性証明書の全ての検証、審査が終了したと判定した場合は、ステップＳ３３８において、サービス提供を実行し、ユーザデバイスにおいてステップＳ３４０のサービス受領を実行する。具体的には、エンドエンティテイとしてのテレビＤ（図３７参照）において、ユーサＣ君が配信コンテンツの視聴を可能となる。
【０３０３】
上述した複数のグループ属性証明書を適用した利用権限確認処理を模式図で示すと、図４０のように示される。すなわち、４種類の異なる属性を定義したグループ属性証明書の定義領域が、図４０に示すグループＡＣ０１〜ＡＣ０４によって示されるとき、上述したコンテンツの利用権限が認められるためには、（ａ）に示すように、ユーザのグループ属性としての学生証（グループ属性証明書（ＡＣ０１）と美術講座受講証（ＡＣ０２）の両グループに属していること、および利用機器のグループ属性として、（ｂ）に示すように、機器のグループ属性として、管理機器証明書と、教育機器証明書を保有する機器であることの両条件を満足することが必要となる。
【０３０４】
（ａ）に示すユーザのグループ属性としての学生証（グループ属性証明書（ＡＣ０１）と美術講座受講証（ＡＣ０２）の両グループに属していることの証明は、ユーザ識別デバイス（ＵＩＤ）のユーザセキュリティチップ（ＵＳＣ）対応のグループ属性証明書の検証、審査によって確認され、（ｂ）に示す機器のグループ属性としての管理機器証明書と、教育機器証明書を保有する機器であることの証明はエンドエンティテイ（ＥＥ）のセキュリティチップ（ＳＣ）対応のグループ属性証明書の検証、審査によって確認される。
【０３０５】
なお、図３９を参照して説明したフローにおいては、４つのグループ属性証明書の検証、審査が成功したことを条件としてサービスを提供する処理としたが、４つのグループ属性証明書の検証、審査が成功したことを条件としてサービスを実行するのではなく、サービス提供を認める新たなグループ属性証明書を発行する処理を行ない、ユーザが新たにこの１つの新規発行のグループ属性証明書を提示し、その検証を実行することによりサービスの提供を受けることが可能となる。
【０３０６】
ただし、この場合、この新規発行されたグループ属性証明書は、ユーザグループおよび機器グループの両グループを定義するものとなり、グループ定義に合致するユーザ識別デバイス（ＵＩＤ）をグループ定義に合致する機器（ＥＥ）に設定し、ＵＩＤのセキュリティチップ（ＵＳＣ）とサービスプロバイダ（ＳＰ）のセキュリティモジュール（ＳＭ）との相互認証により、ＵＩＤのセキュリティチップ（ＵＳＣ）認証が成立し、さらに、エンドエンティテイ（ＥＥ）のセキュリティチップ（ＳＣ）とサービスプロバイダ（ＳＰ）のセキュリティモジュール（ＳＭ）との相互認証によりセキュリティチップ（ＳＣ）の認証が成立し、さらに、上述の新規発行グループ属性証明書の検証、審査が成立することがサービス利用条件となる。
【０３０７】
（５−２）リモートコントロールサービス
次に、グループ属性証明書に基づく、データ処理システム構成の一例として権限確認を実行してエンドエンティテイ（ＥＥ）としての機器のリモートコントロールを実行するサービス利用例について説明する。
【０３０８】
ここでは、医療機器をエンドエンティテイ（ＥＥ）として、自宅等に設置した医療機器と、サービスプロバイダとしての病院側の医療機器（ＳＰ）との間で通信を実行して、病院側の医療機器（ＳＰ）から送信する命令に基づいて、自宅設置の医療機器（ＥＥ）によりユーザの医療診断、検査等を実行し、検査データ等の取得情報を自宅設置の医療機器（ＥＥ）から病院側の医療機器（ＳＰ）に送信する医療処理例について説明する。
【０３０９】
上述の医療処理を実行するデータ処理システムにおける各処理の実行の際、それぞれグループ属性証明書の検証、審査に基づいて処理の実行可否を確認する処理が行なわれ、実行可否確認の後、医療処理手続きに係る様々なデータ処理が実行される。適用するグループ属性証明書の例を図４１に示す。
【０３１０】
グループ属性証明書ＡＣ０１は、発行者が、サービスプロバイダ（ＳＰ）としての病院側医療機器であり、所有者、すなわちグループ属性証明書ＡＣ０１の発行時に発行者である病院側医療機器（ＳＰ）と認証処理を行なうことによりグループ属性証明書の発行対象となった所有者は、自宅側医療機器（ＥＥ）によって医療サービスを受けるユーザ甲さんのユーザ識別デバイス（ＵＩＤ）のユーザセキュリティチップ（ＵＳＣ）である。あるいは自宅側医療機器（ＥＥ）のセキュリティチップ（ＳＣ）であってもよい。
【０３１１】
このグループ属性証明書ＡＣ０１は、医療プログラムの実行可否を判定する確認処理の際に適用され、所有者であるユーザデバイスのＵＳＣあるいはＳＣから病院側医療機器（ＳＰ）に送付されて、病院側医療機器（ＳＰ）において、グループ属性証明書ＡＣ０１の検証、審査の後、サービス、すなわち医療診断プログラムの実行が許可される。
【０３１２】
グループ属性証明書ＡＣ０２は、発行者が、自宅側医療機器（ＥＥ）であり、所有者、すなわちグループ属性証明書ＡＣ０２の発行時に発行者である自宅側医療機器（ＥＥ）と認証処理を行なうことによりグループ属性証明書の発行対象となった所有者は、サービスプロバイダ（ＳＰ）としての病院側医療機器のセキュリティモジュール（ＳＭ）である。
【０３１３】
このグループ属性証明書ＡＣ０２は、医療プログラムの実行によって診断対象者（甲さん）から取得し、診断データ、例えば血圧値、脈拍、採血データ等の診断データを、自宅側医療機器（ＥＥ）から病院側医療機器（ＳＰ）に対して送信する処理の実行可否判定処理に適用される。
【０３１４】
このグループ属性証明書ＡＣ０２は、病院側医療機器（ＳＰ）から自宅側医療機器（ＥＥ）に送付されて、自宅側医療機器（ＥＥ）において、グループ属性証明書ＡＣ０２の検証、審査の後、サービス、すなわち医療診断結果データの送付処理が実行される。
【０３１５】
なお、グループ属性証明書ＡＣ０１，ＡＣ０２の発行処理は、病院側医療機器（ＳＰ）あるいは自宅側医療機器（ＥＥ）、あるいはユーザ識別デバイス（ＵＩＤ）自体が、グループ属性認証局（グループＡＡ）およびグループ属性証明書登録局（グループＡＲＡ）の機能を実行して、みずから発行することが可能であるが、グループ属性認証局（グループＡＡ）およびグループ属性証明書登録局（グループＡＲＡ）に依頼して発行処理を行なう構成も可能である。ただし、この場合には発行者のポリシーに従った処理が実行されることが条件である。
【０３１６】
例えばグループ属性証明書ＡＣ０１の発行処理は、発行者である病院側医療機器（ＳＰ）あるいは、発行代理を行なうグループ属性証明書登録局（グループＡＲＡ）が、医療診断対象者としての甲さんから、甲さんであることを証明する既発行のグループ属性証明書、例えばクレジットカード会社の発行したグループ属性証明書を提示させ、その提出されたグループ属性証明書の検証を実行した後、新たなグループ属性証明書ＡＣ０１の発行処理を行なう方法をとることが好ましい。このような既発行のグループ属性証明書の検証を条件として、新たなグループ属性証明書を発行する処理シーケンスは、先に図２９、図３０、図３２等を参照して説明した処理シーケンスと同様となる。
【０３１７】
また、グループ属性証明書ＡＣ０２の発行処理においても、同様に、発行者である自宅側医療機器（ＥＥ）あるいは、発行代理を行なうグループ属性証明書登録局（グループＡＲＡ）が、病院側医療機器（ＳＰ）から、病院側医療機器（ＳＰ）であることを証明する既発行のグループ属性証明書、例えばメーカーあるいは公の管理組織の発行したグループ属性証明書を提示させて、その提出されたグループ属性証明書の検証を実行した後、グループ属性証明書ＡＣ０２の発行処理を行なう方法をとることが好ましい。
【０３１８】
医療処理を行なうリモートコントロールのシステムにおいて、各機器に格納される属性証明書は、図４２に示す通りとなる。サービスプロバイダとしての病院側医療機器（ＳＰ）４０１と、エンドエンティテイとしての自宅側医療機器（ＥＥ）４１１は通信ネットワークにより相互にデータ転送可能であり、自宅側医療機器（ＥＥ）４１１と、ユーザ識別デバイス（ＵＩＤ）４２１は、双方の接続機器インタフェース２３１（図９参照）を介して相互にデータ転送が可能である。
【０３１９】
それぞれの機器には、耐タンパ構成を持つ（ユーザ）セキュリティチップ４１２，４２３またはセキュリティモジュール４０３が備えられ、データ通信処理の際の相互認証処理、あるいは転送データの暗号化、復号処理等を実行する。またグループ属性証明書の検証処理も（ユーザ）セキュリティチップ４１２，４２３またはセキュリティモジュールにおいて実行される。
【０３２０】
ユーザ識別デバイス４２１には、先に図４１を参照して説明したグループ属性証明書ＡＣ０１，４２２が格納される。グループ属性証明書ＡＣ０１，４２２は、発行者が、サービスプロバイダとしての病院側医療機器（ＳＰ）４０１であり、医療プログラムの実行可否を判定する確認処理の際に適用され、所有者であるユーザデバイスのＵＳＣ４２１から病院側医療機器（ＳＰ）４０１に送付されて、病院側医療機器（ＳＰ）４０１のセキュリティモジュール（ＳＭ）４０３において、グループ属性証明書ＡＣ０１の検証、審査の後、サービス、すなわち医療診断プログラムが実行される。
【０３２１】
また、サービスプロバイダとしての病院側医療機器（ＳＰ）４０１には、グループ属性証明書ＡＣ０２，４０２が格納される。グループ属性証明書ＡＣ０２，４０２は、発行者が、自宅側医療機器（ＥＥ）４１１であり、所有者が病院側医療機器（ＳＰ）４０１であり、病院側医療機器（ＳＰ）から自宅側医療機器（ＥＥ）に送付され、診断対象者（甲さん）から取得した診断データを、自宅側医療機器（ＥＥ）４１１から病院側医療機器（ＳＰ）４０１に対する送信処理の前に、自宅側医療機器（ＥＥ）４１１のセキュリティチップ（ＳＣ）４１２においてグループ属性証明書ＡＣ０２，４０２の検証、審査が実行され、検証、審査成立を条件として診断結果データの送信が実行される。
【０３２２】
図４３を参照して、ユーザ識別デバイス４２１に格納されたグループ属性証明書ＡＣ０１，４２２を適用して医療診断プログラムの実行サービスの利用権限確認処理を行ない、サービスを開始する処理シーケンスについて説明する。図４３において、
ＵＩＤ：ユーザ識別デバイス（ユーザデバイス）制御部、
ＵＳＣ：ＵＩＤ内に構成されるユーザセキュリティチップ、
ＥＥ：自宅側医療機器（ＥＥ）制御部、
ＳＣ：ＥＥ内に構成されるセキュリティチップ、
ＳＰ：病院側医療機器（ＳＰ）制御部、
ＳＭ：ＳＰ内のセキュリティモジュール、
である。
【０３２３】
セキュリティチップ（ＳＣ）、ユーザセキュリティチップ（ＵＳＣ）、セキュリティモジュール（ＳＭ）は先に説明した図９のセキュリティチップと同様の構成を持ち、セキュリティモジュールまたはチップにおいてグループ属性証明書の検証による権限判定処理等が実行される。すなわち、サービス、ここではデータ処理要求元デバイスからデータ処理要求先に送付されたグループ属性証明書をネットワークインタフェース等の受信部で受信したサービスプロバイダまたはユーザデバイスは、受信したグループ属性証明書を権限判定処理部としてのセキュリティモジュール（チップ）に渡し、セキュリティモジュール（チップ）内で受信したグループ属性証明書に基づいて、権限判定処理が実行し、権限ありの判定に基づいて、様々なデータ処理を実行する。
【０３２４】
まず、ステップＳ３２１において、ユーザがエンドエンティテイとしての自宅側医療機器（ＥＥ）の入力インタフェースを介して、グループ属性証明書（Ｇｐ．ＡＣ）＝ＡＣ０１の利用要求コマンドを入力する。このグループ属性証明書（Ｇｐ．ＡＣ）は、図４１、図４２に示すＡＣ０１である。この処理の際、ユーザは利用するグループ属性証明書ＡＣ０１に設定されたグループＩＤを指定する。ただし、特定のサービスを指定することにより唯一のグループＩＤが決定可能である場合は、サービスの指定のみとしてもよい。
【０３２５】
自宅側医療機器（ＥＥ）がユーザからのグループ属性証明書（Ｇｐ．ＡＣ）ＡＣ０１の利用要求入力を受領すると、ステップＳ３２２において、ユーザセキュリティチップ（ＵＳＣ）と、サービスプロバイダとしての病院側医療機器（ＳＰ）のセキュリティモジュール（ＳＭ）間の相互認証が実行される。なお、ここでは省略して示してあるが、ダイレクトにＳＰとの通信を実行できないユーザ識別デバイス（ＵＩＤ）の場合は、
（１）ＥＥのＳＣとＳＰ−ＳＭとの相互認証、
（２）ＥＥのＳＣとＵＩＤのＵＳＣとの相互認証、
（３）ＵＩＤのＵＳＣとＳＰ−ＳＭとの相互認証、
のすべてを実行することになる。あるいは、簡便な方式として、ＵＩＤがＥＥに接続されることで、ＥＥは基本的にこれを受け入れる（認証したものとする）という処理構成としてもよく、この場合は、上記（２）の相互認証の省略が可能となる。さらに、上記３種の相互認証の様々な組み合わせによる認証構成が可能である。
【０３２６】
認証処理は、セキュリティチップ、セキュリテイモジュールの暗号処理部（図９参照）を中心とした処理として例えば先に図１３を参照して説明した公開鍵方式の相互認証処理として実行される。ステップＳ３２３では、ユーザセキュリティチップからエンドエンティテイに対して、相互認証の成立、不成立の結果情報を含む相互認証完了通知が出力される。相互認証不成立の場合は、処理の続行は中止される。相互認証が成立すると、ステップＳ３２４において、ユーザセキュリティチップ（ＵＳＣ）は、サービスプロバイダ（ＳＰ）のセキュリティモジュール（ＳＭ）に対して自己のメモリに格納したグループ属性証明書（Ｇｐ．ＡＣ）ＡＣ０１を送信する。このグループ属性証明書（Ｇｐ．ＡＣ）は、先に図４１、図４２を参照して説明したように、医療プログラムのサービス受領資格権限を判定する処理に適用するグループ属性証明書ＡＣ０１である。
【０３２７】
ユーザセキュリティチップ（ＵＳＣ）からグループ属性証明書（Ｇｐ．ＡＣ）ＡＣ０１を受信した病院側医療機器（ＳＰ）のセキュリティモジュール（ＳＭ）は、ステップＳ３２５において、グループ属性証明書検証処理を実行する。グループ属性証明書の検証処理については、先に図２１乃至図２３を参照して説明した通りであり、属性証明書の署名検証、関連の公開鍵証明書（ＰＫＣ）および連鎖公開鍵証明書の確認処理等を含む処理として実行される。
【０３２８】
グループ属性証明書（Ｇｐ．ＡＣ）の検証処理後、セキュリティモジュール（ＳＭ）は、検証結果を病院側医療機器（ＳＰ）に出力し、検証不成立の場合は、エラー処理として、サービス提供を実行せず処理を中止する。この場合、グループＡＣの検証が不成立であった旨をエンドエンティテイ通知する処理を実行してもよい。
【０３２９】
グループ属性証明書（Ｇｐ．ＡＣ）の検証が成功し、グループ属性証明書（Ｇｐ．ＡＣ）の正当性が確認されるとステップＳ３２７に進む。ステップＳ３２７では、先に図２５を参照して説明したグループ属性証明書（Ｇｐ．ＡＣ）の審査を実行する。審査は、サービスプロバイダとしての病院側医療機器（ＳＰ）の保有するグループ情報データベースに基づいて実行する。すなわち、病院側医療機器（ＳＰ）は、検証済みのグループ属性証明書（Ｇｐ．ＡＣ）ＡＣ０１から発行者情報、グループＩＤを取得し、取得情報に基づいて、グループ情報データベースを検索し、登録されたエントリーの有無を確認する。対応する登録エントリーがある場合は、グループ情報データベースからグループ情報を取得する。
【０３３０】
この場合のグループ情報は、医療診断プログラムの実行許可情報を含むものである。サービスプロバイダとしての病院側医療機器（ＳＰ）は、ステップＳ３２８において、サービス提供処理、すなわち、グループ情報に従って、医療診断プログラムの実行を行なう。すなわち、リモートコントロールによる医療診断処理、すなわち各種診断プログラムの実行コマンドを自宅側医療機器（ＥＥ）に送信して自宅側医療機器（ＥＥ）を介してユーザの診断を実行する。
【０３３１】
次に、図４４を参照して、病院側医療機器（ＳＰ）４０１に格納されたグループ属性証明書ＡＣ０２，４０２を適用して医療診断プログラムの実行結果としての診断データ引き取り処理サービスの利用権限確認処理を行ない、サービスを開始する処理シーケンスについて説明する。
【０３３２】
まず、ステップＳ３３１において、病院側のシステムを操作するユーザが病院側医療機器（ＳＰ）の入力インタフェースを介して、グループ属性証明書（Ｇｐ．ＡＣ）＝ＡＣ０２の利用要求コマンドを入力する。このグループ属性証明書（Ｇｐ．ＡＣ）は、図４１、図４２に示すＡＣ０２である。この処理の際、病院側のシステムを操作するユーザは利用するグループ属性証明書ＡＣ０２に設定されたグループＩＤを指定する。ただし、特定のサービスを指定することにより唯一のグループＩＤが決定可能である場合は、サービスの指定のみとしてもよい。
【０３３３】
病院側医療機器（ＳＰ）がグループ属性証明書（Ｇｐ．ＡＣ）ＡＣ０２の利用要求入力を受領すると、ステップＳ３３２において、ユーザセキュリティチップ（ＵＳＣ）と、サービスプロバイダとしての病院側医療機器（ＳＰ）のセキュリティモジュール（ＳＭ）間の相互認証が実行される。なお、ここでは省略して示してあるが、ダイレクトにＳＰとの通信を実行できないユーザ識別デバイス（ＵＩＤ）の場合は、
（１）ＥＥのＳＣとＳＰ−ＳＭとの相互認証、
（２）ＥＥのＳＣとＵＩＤのＵＳＣとの相互認証、
（３）ＵＩＤのＵＳＣとＳＰ−ＳＭとの相互認証、
のすべてを実行することになる。あるいは、簡便な方式として、ＵＩＤがＥＥに接続されることで、ＥＥは基本的にこれを受け入れる（認証したものとする）という処理構成としてもよく、この場合は、上記（２）の相互認証の省略が可能となる。さらに、上記３種の相互認証の様々な組み合わせによる認証構成が可能である。
【０３３４】
認証処理は、セキュリティチップ、セキュリテイモジュールの暗号処理部（図９参照）を中心とした処理として例えば先に図１３を参照して説明した公開鍵方式の相互認証処理として実行される。ステップＳ３３３では、セキュリティモジュール（ＳＭ）から病院側医療機器（ＳＰ）に対して、相互認証の成立、不成立の結果情報を含む相互認証完了通知が出力される。相互認証不成立の場合は、処理の続行は中止される。相互認証が成立すると、ステップＳ３３４において、病院側医療機器（ＳＰ）のセキュリティモジュール（ＳＭ）は、自宅側医療機器側のユーザセキュリティチップ（ＵＳＣ）に対して自己のメモリに格納したグループ属性証明書（Ｇｐ．ＡＣ）ＡＣ０２を送信する。このグループ属性証明書（Ｇｐ．ＡＣ）は、先に図４１、図４２を参照して説明したように、診断結果データの引き取り処理権限を判定する処理に適用するグループ属性証明書ＡＣ０２である。
【０３３５】
病院側医療機器（ＳＰ）のセキュリティモジュール（ＳＭ）からグループ属性証明書（Ｇｐ．ＡＣ）ＡＣ０２を受信したユーザセキュリティチップ（ＵＳＣ）は、ステップＳ３３５において、グループ属性証明書検証処理を実行する。グループ属性証明書の検証処理については、先に図２１乃至図２３を参照して説明した通りであり、属性証明書の署名検証、関連の公開鍵証明書（ＰＫＣ）および連鎖公開鍵証明書の確認処理等を含む処理として実行される。
【０３３６】
グループ属性証明書（Ｇｐ．ＡＣ）の検証処理後、ユーザセキュリティチップ（ＵＳＣ）は、検証結果を自宅側医療機器（ＥＥ）に出力（Ｓ３３６）し、検証不成立の場合は、エラー処理として、診断結果の送信サービスを実行せず処理を中止する。この場合、グループＡＣの検証が不成立であった旨を病院側医療機器（ＳＰ）に通知する処理を実行してもよい。
【０３３７】
グループ属性証明書（Ｇｐ．ＡＣ）の検証が成功し、グループ属性証明書（Ｇｐ．ＡＣ）の正当性が確認されるとステップＳ３３７に進む。ステップＳ３３７では、先に図２５を参照して説明したグループ属性証明書（Ｇｐ．ＡＣ）の審査を実行する。審査は、自宅側医療機器（ＥＥ）の保有するグループ情報データベースに基づいて実行する。すなわち、自宅側医療機器（ＥＥ）は、検証済みのグループ属性証明書（Ｇｐ．ＡＣ）ＡＣ０２から発行者情報、グループＩＤを取得し、取得情報に基づいて、グループ情報データベースを検索し、登録されたエントリーの有無を確認する。対応する登録エントリーがある場合は、グループ情報データベースからグループ情報を取得する。
【０３３８】
この場合のグループ情報は、医療診断プログラムの診断結果送信許可情報を含むものである。自宅側医療機器（ＥＥ）は、ステップＳ３３８において、サービス提供処理、すなわち、グループ情報に従って、医療診断プログラムの診断結果送信処理を実行する。すなわち、医療診断処理結果を自宅側医療機器（ＥＥ）から病院側医療機器（ＳＰ）に送信する処理を実行する。
【０３３９】
（５−３）リモートメンテナンスサービス
次に、グループ属性証明書に基づいて権限確認を実行してデータ処理の実行を行なうデータ処理システムの構成例として、エンドエンティテイ（ＥＥ）としての機器、例えば家電製品のリモートメンテナンスを実行するサービス利用例について説明する。
【０３４０】
ここでは、通信機能を有するＡＶ機器、エアコン、冷蔵庫等の様々な家電機器をエンドエンティテイ（ＥＥ）として、自宅等に設置したこれらの家電機器と、サービスプロバイダとしての家電機器メーカー側のサービス提供機器（ＳＰ）との間で通信を実行して、メーカー側のサービス提供機器（ＳＰ）から送信する命令に基づいて、自宅設置の家電機器（ＥＥ）の修理、メンテナンス、アップグレード、その他コントロール処理を実行する例について説明する。
【０３４１】
上述の各処理の実行の際、それぞれグループ属性証明書の検証、審査に基づいて処理の実行可否を確認する処理が行なわれ、実行可否確認の後、各処理が実行される。適用するグループ属性証明書の例を図４５に示す。グループ属性証明書は、大きく２つのカテゴリに分類される。１つはサービス属性証明書（ＡＣ）であり、他方はコントロール属性証明書（ＡＣ）である。
【０３４２】
サービス属性証明書（ＡＣ）は、発行者が、サービスプロバイダ（ＳＰ）としての家電機器メーカー側機器であり、所有者、すなわちサービス属性証明書（ＡＣ）の発行時に発行者である家電機器メーカー側機器（ＳＰ）と認証処理を行なうことにより属性証明書の発行対象となった所有者は、自宅等に設置した家電機器（ＥＥ）を利用するユーザのユーザ識別デバイス（ＵＩＤ）のユーザセキュリティチップ（ＵＳＣ）、あるいは家電機器（ＥＥ）のセキュリティチップ（ＳＣ）である。
【０３４３】
このサービス属性証明書は、家電機器を購入したユーザとメーカー側との間で、家電機器購入時にサブスクライバ契約を交わすことで、その後の家電機器（ＥＥ）の修理、メンテナンス、アップグレード、その他コントロール処理に関するサービスを受領する権限を認めた家電機器購入者グループ、あるいは家電機器グループに対して発行されるものである。従って、サービス属性証明書は、家電機器購入者グループ、あるいは家電機器グループを対象として発行されるグループ属性証明書である。
【０３４４】
家電機器購入者グループを対象として発行する場合は、ユーザ識別デバイス（ＵＩＤ）のユーザセキュリティチップ（ＵＳＣ）と家電機器メーカー（ＳＰ）のセキュリティモジュール間の相互認証の成立を条件とした発行処理がなされ、家電機器グループを対象として発行する場合は、家電機器（ＥＥ）のセキュリティチップ（ＳＣ）と家電機器メーカー（ＳＰ）のセキュリティモジュール間の相互認証の成立を条件とした発行処理がなされる。
【０３４５】
このサービス属性証明書は、家電機器（ＥＥ）の修理、メンテナンス、アップグレード、その他コントロールサービスの要求の際に、家電機器（ＥＥ）あるいはユーザ識別デバイス（ＵＩＤ）からメーカー側機器（ＳＰ）に送付されて、メーカー側機器（ＳＰ）において、サービス属性証明書の検証、審査の後、サービスの提供に移行することになる。
【０３４６】
コントロール属性証明書は、発行者が、修理、メンテナンス、アップグレード、その他コントロールサービスを受領する家電機器（ＥＥ）であり、所有者、すなわちコントロール属性証明書の発行時に発行者である家電機器（ＥＥ）と認証処理を行なうことによりグループ属性証明書の発行対象となった所有者は、サービスプロバイダ（ＳＰ）としてのメーカー側機器のセキュリティモジュール（ＳＭ）である。
【０３４７】
このコントロール属性証明書は、家電機器を購入したユーザとメーカー側との間で、家電機器購入以後に、サービス属性証明書の保有を条件として発行される証明書であり、例えば同一メーカーの複数の家電機器を有するユーザーが、各々の家電機器に対するメンテナンスサービス実行範囲を権限情報とした証明書として、各家電機器に対応して、サービス提供者であるメーカー側機器に対して発行する。あるいは、１つの家電機器に対して、異なるコントロール権限情報を各々記録した証明書として発行することも可能である。例えば、家電機器のコントロール情報として、ソフトウェアのアップグレード処理依頼のために、アップグレード処理のみを受領サービスとして許容することを示す属性証明書、あるいは、定期点検のための点検処理のみを許容することを示す属性証明書等である。
【０３４８】
コントロール属性証明書は、例えば１ユーザの所有する複数の家電機器グループ、あるいは１つの家電機器を対象として複数発行可能なグループ属性証明書である。１ユーザの所有する複数の家電機器グループを対象として発行する場合は、ユーザ識別デバイス（ＵＩＤ）のユーザセキュリティチップ（ＵＳＣ）と家電機器メーカー（ＳＰ）のセキュリティモジュール間の相互認証の成立を条件とした発行処理がなされ、１つの特定の家電機器を対象として発行する場合は、上述のＵＩＤのＵＳＣ、あるいは特定の家電機器（ＥＥ）のセキュリティチップ（ＳＣ）と家電機器メーカー（ＳＰ）のセキュリティモジュール間の相互認証の成立を条件とした発行処理がなされる。
【０３４９】
このコントロール属性証明書は、ユーザ側（ＥＥまたはＵＩＤ）から発行されてサービスを提供するメーカー側機器に格納され、家電機器（ＥＥ）の修理、メンテナンス、アップグレード、その他コントロールサービスの実行時にメーカー側機器から、ユーザ側（ＥＥまたはＵＩＤ）に送信されて、ユーザ側（ＥＥまたはＵＩＤ）において、コントロール属性証明書の検証、審査の後、サービスの提供に移行することになる。
【０３５０】
なお、サービス属性証明書、コントロール属性証明書の発行処理は、メーカー側機器（ＳＰ）あるいは家電機器（ＥＥ）、あるいはユーザ識別デバイス（ＵＩＤ）自体が、グループ属性認証局（グループＡＡ）およびグループ属性証明書登録局（グループＡＲＡ）の機能を実行して、みずから発行することが可能であるが、グループ属性認証局（グループＡＡ）およびグループ属性証明書登録局（グループＡＲＡ）に依頼して発行処理を行なう構成も可能である。ただし、この場合には発行者のポリシーに従った処理が実行されることが条件である。
【０３５１】
例えばサービス属性証明書の発行処理は、発行者であるメーカー側機器（ＳＰ）あるいは、発行代理を行なうグループ属性証明書登録局（グループＡＲＡ）が、サービス提供を受けようとするユーザから、ユーザ自身を証明する既発行のグループ属性証明書、例えばクレジットカード会社の発行したグループ属性証明書を提示させ、その提出されたグループ属性証明書の検証を実行した後、新たなグループ属性証明書として、サービス属性証明書を発行したり、あるいは家電機器に対して、製造時にメーカーが格納したメーカー製の製品グループに属することを証明するグループ属性証明書を提示させ、その提出されたグループ属性証明書の検証を実行した後、新たなグループ属性証明書として、サービス属性証明書を発行するといった発行処理を行なうことが好ましい。このような既発行のグループ属性証明書の検証を条件として、新たなグループ属性証明書を発行する処理シーケンスは、先に図２９、図３０、図３２等を参照して説明した処理シーケンスと同様となる。
【０３５２】
また、コントロール属性証明書の発行処理においても、同様に、発行者である家電機器（ＥＥ）あるいは、発行代理を行なうグループ属性証明書登録局（グループＡＲＡ）が、メーカー側機器（ＳＰ）から、メーカー側の真正な機器であることを証明する既発行のグループ属性証明書、例えば、前述したようにメーカーの発行したグループ属性証明書としてのサービス属性証明書を提示させて、その提出証明書の検証を実行した後、新たなグループ属性証明書としてのコントロール属性証明書の発行処理を行なう方法をとることが好ましい。
【０３５３】
メンテナンスサービスを行なうシステムにおいて、各機器に格納される属性証明書は、図４６に示す通りとなる。サービスプロバイダとしてのメーカー側機器（ＳＰ）４５１と、エンドエンティテイとしてのユーザー側家電療機器（ＥＥ）４６１は通信ネットワークにより相互にデータ転送可能であり、ユーザー側家電機器（ＥＥ）４６１と、ユーザ識別デバイス（ＵＩＤ）４７１は、双方の接続機器インタフェース２３１（図９参照）を介して相互にデータ転送が可能である。
【０３５４】
それぞれの機器には、耐タンパ構成を持つ（ユーザ）セキュリティチップ４６３，４７２またはセキュリティモジュール４５３が備えられ、データ通信処理の際の相互認証処理、あるいは転送データの暗号化、復号処理等を実行する。またグループ属性証明書の検証処理も（ユーザ）セキュリティチップ４６３，４７２またはセキュリティモジュール４５３において実行される。
【０３５５】
ユーザ側家電機器（ＥＥ）４６１には、先に図４５を参照して説明したサービス属性証明書４６２が格納される。サービス属性証明書４６２は、発行者が、サービスプロバイダとしてのメーカー側機器（ＳＰ）４５１であり、家電メンテナンス、修理等の実行可否を判定する確認処理の際に適用され、所有者であるユーザ側家電機器（ＥＥ）４６１のＳＣ４６３からメーカー側機器（ＳＰ）４５１に送付される。メーカー側機器（ＳＰ）４５１のセキュリティモジュール（ＳＭ）４５３において検証、審査の後、サービス、すなわちコントロール属性証明書送信、およびコントロール属性証明書によって許可された権限範囲でのメンテナンス等の処理が実行される。
【０３５６】
サービスプロバイダとしてのメーカー側機器（ＳＰ）４５１には、コントロール属性証明書４５２が格納される。コントロール属性証明書４５２は、発行者が、ユーザ側家電機器（ＥＥ）４６１であり、所有者がメーカー側機器（ＳＰ）４５１であり、メーカー側機器（ＳＰ）からユーザー側家電機器（ＥＥ）４６１に送付され、メンテナンス等のサービス実行の前に、ユーザー側家電機器（ＥＥ）４６１のセキュリティチップ（ＳＣ）４６３においてコントロール属性証明書の検証、審査が実行され、検証、審査成立を条件としてメンテナンス、修理、あるいはアップグレード等の処理が、コントロール属性証明書によって確認された権限範囲内で実行される。
【０３５７】
サービス実行時におけるサービス属性証明書およびコントロール属性証明書の利用形態について、図４７を参照して説明する。まず、メンテナンス、修理、点検、アップグレード等のサービスを受領したい家電機器（ＥＥ）あるいは家電機器に接続したユーザ識別デバイス（ＵＩＤ）側から、サービス属性証明書（ＡＣ）４８４をメーカー側機器（ＳＰ）４８２に提示する。メーカー側機器（ＳＰ）４８２は、セキュリティモジュール（ＳＭ）におけるサービス属性証明書の検証の後、サービス属性証明書に対応するグループＩＤに基づいて、グループ情報データベース４８３を検索して、グループ情報としてのコントロールＡＣあるいはコントロールＡＣの識別データを抽出して、サービスＡＣに対応するコントロールＡＣを取得する。
【０３５８】
メーカー側機器（ＳＰ）４８２は、取得したコントロール属性証明書（ＡＣ）４８５を家電機器（ＥＥ）あるいは家電機器に接続したユーザ識別デバイス（ＵＩＤ）に送信し、家電機器（ＥＥ）あるいは家電機器に接続したユーザ識別デバイス（ＵＩＤ）におけるセキュリティチップで検証の後、コントロール属性証明書（ＡＣ）で許容されたコントロール情報に従って家電機器（ＥＥ）に対してメンテナンス等のサービスが実行される。
【０３５９】
なお、メンテナンス、修理、アップグレード等の実行プログラムは、予め家電機器内のメモリに格納したものを利用してもよく、あるいは、必要に応じて、メーカー側機器から家電機器に対して送信して実行する構成としてもよい。なお、実行プログラムの送信の際には、認証処理、送信データの暗号化処理を実行することが好ましい。
【０３６０】
次に、図４８以下を参照して、ユーザデバイスとしての家電機器（ＥＥ）に格納されたサービス属性証明書、サービスプロバイダに格納されたコントロール属性証明書を適用して家電機器のメンテナンス等のサービスに関する利用権限確認処理を行ない、サービスを開始する処理シーケンスについて説明する。図４８において、
ＥＥ：ユーザ側家電機器（ＥＥ）制御部、
ＳＣ：ＥＥ内に構成されるセキュリティチップ、
ＳＰ：メーカー側機器（ＳＰ）制御部、
ＳＭ：ＳＰ内のセキュリティモジュール、
である。
【０３６１】
セキュリティチップ（ＳＣ）、ユーザセキュリティチップ（ＵＳＣ）、セキュリティモジュール（ＳＭ）は先に説明した図９のセキュリティチップと同様の構成を持ち、セキュリティモジュールまたはチップにおいてグループ属性証明書の検証による権限判定処理等が実行される。すなわち、サービス、ここではメンテナンス処理等のデータ処理要求元デバイスからデータ処理要求先に送付されたグループ属性証明書をネットワークインタフェース等の受信部で受信したサービスプロバイダまたはユーザデバイスは、受信したグループ属性証明書を権限判定処理部としてのセキュリティモジュール（チップ）に渡し、セキュリティモジュール（チップ）内で受信したグループ属性証明書に基づいて、権限判定処理が実行し、権限ありの判定に基づいて、様々なデータ処理を実行する。
【０３６２】
まず、ステップＳ３４１において、ユーザがエンドエンティテイとしてのユーザ側家電機器（ＥＥ）の入力インタフェースを介して、グループ属性証明書（Ｇｐ．ＡＣ）であるサービス属性証明書（ＡＣ）の利用要求コマンドを入力する。この処理の際、ユーザは利用するサービス属性証明書（ＡＣ）に設定されたグループＩＤを指定する。ただし、特定のサービスを指定することにより唯一のグループＩＤが決定可能である場合は、サービスの指定のみとしてもよい。
【０３６３】
ユーザ側家電機器（ＥＥ）がユーザからのサービス属性証明書（ＡＣ）の利用要求入力を受領すると、ステップＳ３４２において、セキュリティチップ（ＳＣ）と、サービスプロバイダとしてのメーカー側機器（ＳＰ）のセキュリティモジュール（ＳＭ）間の相互認証が実行される。なお、ここでは、家電機器（ＥＥ）のセキュリティチップ（ＳＣ）を発行対象としたサービス属性証明書の利用例を示してあるが、ユーザ識別デバイス（ＵＩＤ）のユーザセキュリティチップ（ＳＣ）を発行対象としたサービス属性証明書を利用した処理も同様に可能である。ただし、ダイレクトにＳＰとの通信を実行できないユーザ識別デバイス（ＵＩＤ）の場合は、
（１）ＥＥのＳＣとＳＰ−ＳＭとの相互認証、
（２）ＥＥのＳＣとＵＩＤのＵＳＣとの相互認証、
（３）ＵＩＤのＵＳＣとＳＰ−ＳＭとの相互認証、
のすべてを実行することになる。あるいは、簡便な方式として、ＵＩＤがＥＥに接続されることで、ＥＥは基本的にこれを受け入れる（認証したものとする）という処理構成としてもよく、この場合は、上記（２）の相互認証の省略が可能となる。さらに、上記３種の相互認証の様々な組み合わせによる認証構成が可能である。
【０３６４】
認証処理は、セキュリティチップ、セキュリテイモジュールの暗号処理部（図９参照）を中心とした処理として例えば先に図１３を参照して説明した公開鍵方式の相互認証処理として実行される。ステップＳ３４３では、セキュリティチップからエンドエンティテイに対して、相互認証の成立、不成立の結果情報を含む相互認証完了通知が出力される。相互認証不成立の場合は、処理の続行は中止される。相互認証が成立すると、ステップＳ３４４において、セキュリティチップ（ＳＣ）は、メーカー側機器であるサービスプロバイダ（ＳＰ）のセキュリティモジュール（ＳＭ）に対して自己のメモリに格納したサービス属性証明書を送信する。
【０３６５】
ユーザ側家電機器のセキュリティチップ（ＳＣ）からサービス属性証明書を受信したメーカー側機器（ＳＰ）のセキュリティモジュール（ＳＭ）は、ステップＳ３４５において、サービス属性証明書の検証処理を実行する。サービス属性証明書の検証処理については、先に図２１乃至図２３を参照して説明した通りであり、属性証明書の署名検証、関連の公開鍵証明書（ＰＫＣ）および連鎖公開鍵証明書の確認処理等を含む処理として実行される。
【０３６６】
サービス属性証明書の検証処理後、セキュリティモジュール（ＳＭ）は、検証結果をメーカー側機器（ＳＰ）に出力し、検証不成立の場合は、エラー処理として、サービス提供を実行せず処理を中止する。この場合、サービス属性証明書の検証が不成立であった旨をエンドエンティテイ通知する処理を実行してもよい。
【０３６７】
サービス属性証明書の検証が成功し、サービス属性証明書の正当性が確認されるとステップＳ３４７に進む。ステップＳ３４７では、サービス属性証明書の審査を実行する。審査は、サービスプロバイダとしてのメーカー側機器（ＳＰ）の保有するグループ情報データベースに基づいて実行する。
【０３６８】
サービス属性証明書の審査処理について、図４９を参照して説明する。ステップＳ３５１において、サービスプロバイダ（ＳＰ）は、検証済みのサービス属性証明書から属性値としてのグループＩＤを取得する。ステップＳ３５２において、サービス属性証明書から取得したグループＩＤに基づいて、グループ情報データベースを検索（Ｓ３５２）し、登録されたエントリーから、コントロール属性証明書情報、例えばコントロール属性証明書の識別子（ＩＤ）を取得（Ｓ３５３）する。
【０３６９】
図４９に示すように、サービスプロバイダの保有するグループ情報データベース（ＤＢ）には、発行者、サービスＡＣのグループＩＤ、およびグループ情報としての対応コントロール属性証明書情報、例えばＩＤが対応付けられて格納され、サービスプロバイダ（ＳＰ）は、ユーザ側家電機器から受領し、検証の成立したサービス属性証明書（ＡＣ）から取得したグループＩＤに基づいて、グループ情報データベース（ＤＢ）を検索してグループ情報として、サービスＡＣに対応するコントロール属性証明書（ＡＣ）の特定情報を取得する。
【０３７０】
次に、サービスプロバイダとしてのメーカー側機器（ＳＰ）は、ステップＳ３４８（図４８）において、グループ情報データベース（ＤＢ）から取得したコントロール属性証明書（ＡＣ）のＩＤに基づいて、コントロール属性証明書（ＡＣ）を取得する。
【０３７１】
次に、サービス属性証明書を受領したサービスプロバイダが、コントロール属性証明書に基づくサービス、例えば家電機器に対するメンテナンス、点検、修理、アップグレード、あるいはコントロール等の処理を実行するシーケンスについて、図５０以下を参照して説明する。
【０３７２】
図５０のステップＳ３７０において、メーカー側機器を操作するオペレータがメーカー側機器（ＳＰ）の入力インタフェースを介して、コントロール属性証明書を適用したメンテナンス処理実行コマンドを入力する。この処理の際、オペレータは利用するコントロール属性証明書に設定されたグループＩＤを指定する。
【０３７３】
メーカー側機器（ＳＰ）がコントロール属性証明書を適用したメンテナンス処理実行要求入力を受領すると、ステップＳ３７１において、家電機器（ＥＥ）のセキュリティチップ（ＳＣ）と、サービスプロバイダとしてのメーカー側機器（ＳＰ）のセキュリティモジュール（ＳＭ）間の相互認証が実行される。なお、先に図４８を参照して説明したサービス属性証明書の検証処理シーケンスと同一セッションで図５０に示すコントロール属性証明書に基づくサービス提供シーケンスが実行される場合は、この相互認証処理は不要となる。
【０３７４】
認証処理が実行された場合は、ステップＳ３７２で、セキュリティモジュール（ＳＭ）からメーカー側機器（ＳＰ）に対して、相互認証の成立、不成立の結果情報を含む相互認証完了通知が出力される。相互認証不成立の場合は、処理の続行は中止される。相互認証が成立すると、ステップＳ３７３において、メーカー側機器（ＳＰ）のセキュリティモジュール（ＳＭ）は、ユーザ側家電機器側のセキュリティチップ（ＳＣ）に対して、受信したサービス属性証明書に基づいて抽出したコントロール属性証明書を送信する。このコントロール属性証明書は、先に説明したように、家電機器に対するコントロール範囲処理権限を確認する処理に適用するグループ属性証明書である。
【０３７５】
メーカー側機器（ＳＰ）のセキュリティモジュール（ＳＭ）からコントロール属性証明書を受信したセキュリティチップ（ＳＣ）は、ステップＳ３７４において、コントロール属性証明書検証処理を実行する。コントロール属性証明書の検証処理は、先に図２１乃至図２３を参照して説明した通りであり、属性証明書の署名検証、関連の公開鍵証明書（ＰＫＣ）および連鎖公開鍵証明書の確認処理等を含む処理として実行される。
【０３７６】
コントロール属性証明書の検証処理後、セキュリティチップ（ＳＣ）は、検証結果をユーザ側家電機器（ＥＥ）に出力（Ｓ３７５）し、検証不成立の場合（Ｓ３７６：ＮＧ）は、エラー処理（Ｓ３７７）として、メンテナンス等の処理の実行を中止する。この場合、コントロール属性証明書の検証が不成立であった旨をメーカー側機器（ＳＰ）に通知する処理を実行してもよい。
【０３７７】
コントロール属性証明書の検証が成功（Ｓ３７６：ＯＫ）し、コントロール属性証明書の正当性が確認されるとステップＳ３７８に進む。ステップＳ３７８では、家電機器（ＥＥ）がメンテナンス実行プログラムの検索を行なう。このメンテナンス実行プログラムは、あらかじめ家電機器（ＥＥ）にコントロール属性証明書ＩＤ、あるいはグループＩＤに対応付けられてメモリに格納されているか、あるいは処理実行時にメーカー側機器（ＳＰ）から送信されるプログラムであり、必要に応じて暗号化されている。このシーケンス図においては、メンテナンス実行プログラムは、あらかじめ家電機器（ＥＥ）にコントロール属性証明書ＩＤ、あるいはグループＩＤに対応付けられて格納されている場合の例である。
【０３７８】
ステップＳ３７９では、家電機器（ＥＥ）が抽出した暗号化メンテナンスプログラムをセキュリティチップ（ＳＣ）に転送し、ステップＳ３８０において、セキュリティチップ（ＳＣ）側において復号処理を実行する。復号処理は、例えばサービスプロバイダ（ＳＰ）側から提供された鍵、あるいは各ユーザデバイスに固有の鍵等に基づいて実行される。プログラムの暗号化処理態様としては、公開鍵方式、共通鍵方式等、各種の処理方式が採用可能である。なお、鍵を格納した属性証明書を利用して鍵をセキュリティチップに提供する構成としてもよい。
【０３７９】
ステップＳ３８１において、セキュリティチップ（ＳＣ）から復号されたメンテナンスプログラムが家電機器としてのエンドエンティテイ（ＥＥ）に出力され、ステップＳ３８２において、メンテナンスプログラムが実行され、プログラム実行完了の後、ステップＳ３８３において、実行結果がサービスプロバイダ（ＳＰ）に送信される。
【０３８０】
図５１は、図５０と同様、サービス属性証明書を受領したサービスプロバイダが、コントロール属性証明書に基づくサービス、例えば家電機器に対するメンテナンス、点検、修理、アップグレード、あるいはコントロール等の処理を実行するシーケンスであり、メンテナンス実行プログラムをメーカー側機器（ＳＰ）からユーザ側家電機器（ＥＥ）に対して送信する処理とした例である。ステップＳ３８４〜Ｓ３９２は、図５０のステップＳ３７０〜Ｓ３７７に対応する。
【０３８１】
コントロールＡＣの検証ＯＫの後のステップＳ３９３において、ユーザ側家電機器（ＥＥ）からメーカー側機器（ＳＰ）に対してメンテナンスプログラムの送信要求が出力され、ステップＳ３９４において、サービスプロバイダとしてのメーカー側機器がメンテナンスプログラムの検索を実行し、ステップＳ３９５において検索したプログラムをユーザ側家電機器（ＥＥ）に対して送信する処理部分が、図５０の処理シーケンスと異なっている。
【０３８２】
なお、送信プログラムは、必要に応じて暗号化される。例えばセッション鍵、サービスプロバイダ（ＳＰ）側から提供された鍵、あるいは各ユーザデバイスに固有の鍵等に基づいて復号可能な態様で暗号化がなされて送信される。プログラムの暗号化処理態様としては、公開鍵方式、共通鍵方式等、各種の処理方式が採用可能である。なお、鍵を格納した属性証明書を利用して鍵をセキュリティチップに提供する構成としてもよい。
【０３８３】
図５２の処理シーケンスは、図５０、図５１と同様、サービス属性証明書を受領したサービスプロバイダが、コントロール属性証明書に基づくサービス、例えば家電機器に対するメンテナンス、点検、修理、アップグレード、あるいはコントロール等の処理を実行するシーケンスであるが、メンテナンス実行プログラムをメーカー側機器（ＳＰ）から、逐次コマンドを家電機器（ＥＥ）に送信し、コマンド実行に基づく応答を家電機器（ＥＥ）から受信しながらレスポンス対応の処理を実行する構成としたものである。
【０３８４】
ステップＳ４１０〜Ｓ４２０は、図５１のステップＳ３８４〜Ｓ３９４に対応する。サービスプロバイダ（ＳＰ）は、ステップＳ４２１でメンテナンスプログラムに従ったコマンドを必要に応じて暗号化して家電機器（ＥＥ）に送信し、家電機器（ＥＥ）はステップＳ４２２において、暗号化コマンドをセキュリティチップに渡し、セキュリティチップ（ＳＣ）における復号（Ｓ４２３）、セキュリティチップ（ＳＣ）から復号コマンドの引き渡し（Ｓ４２４）の後、家電機器（ＥＥ）においてコマンドを実行（Ｓ４２５）し、実行結果をコマンド実行レスポンスとして家電機器（ＥＥ）からサービスプロバイダ（ＳＰ）に送信し、レスポンスを受信したサービスプロバイダ（ＳＰ）がレスポンスに基づく次実行コマンドを家電機器（ＥＥ）に送信する構成としている。
【０３８５】
メンテナンスプログラムに従ったコマンドの実行がすべて終了すると、ステップＳ４２７において、メンテナンスプログラム実行処理を終了する。
【０３８６】
上述したメンテナンス処理形態は、ユーザ側の家電機器からサービス属性証明書を、メーカー側機器に提示し、一方、メーカー側機器がコントロール属性証明書を家電機器に提示して、相互に各属性証明書の検証、審査を実行して、サービスの受領あるいは提供範囲の権限確認を行なう形態である。
【０３８７】
サービス属性証明書、コントロール属性証明書の利用形態は上述した処理形態に限らず、例えば図５３に示すように、両属性証明書をユーザー側機器４９１に格納して、サービス提供要求時にサービス属性証明書４９３、コントロール属性証明書４９４をメーカー側（ＳＰ）４９２に提示し、メーカー側（ＳＰ）４９２において、サービス属性証明書４９３、コントロール属性証明書４９４の検証、審査を実行するとともに、両者の対応関係を確認の後、コントロール属性証明書４９４によって示される権限の範囲でのメンテナンス処理をユーザー側機器４９１に対して実行する形態としてもよい。
【０３８８】
また、家電機器において一定時間毎にメンテナンス自動実行を行なうプログラムを格納し、プログラムされた時間間隔でサービス属性証明書を伴うメンテナンス要求をメーカー側に送信し、メーカー側が要求受信に基づいて、コントロール属性証明書の送信およびメンテナンス処理を実行する形態としてもよい。
【０３８９】
（５−４）パーソナルコミュニュケーションサービス
次に、グループ属性証明書に基づいて権限確認を実行してエンドエンティテイ（ＥＥ）としてのＰＣ、ＰＤＡ、その他の通信端末を利用したコミュニケーションサービス利用例について説明する。
【０３９０】
ここでは、ＰＣ、ＰＤＡ、その他の通信端末をエンドエンティテイ（ＥＥ）として、自宅等に設置した通信端末が、チャットルームを提供するサービスプロバイダのサーバに接続して、チャットルームを介した通信端末間のコミュニケーション、およびエンドエンティテイ（ＥＥ）間の直接通信において、グループ属性証明書を利用したアクセス制限処理を実行してコミュニケーションサービスを行なう例を説明する。コミュニケーションサービスにおいて適用するグループ属性証明書の例を図５４に示す。
【０３９１】
グループ属性証明書ＡＣ０１は、発行者が、サービスプロバイダ（ＳＰ）としてのチャット運営者であり、所有者、すなわちグループ属性証明書ＡＣ０１の発行時に発行者であるチャット運営サービスプロバイダ（ＳＰ）と認証処理を行なうことによりグループ属性証明書ＡＣ０１の発行対象となった所有者は、ユーザ甲さんの通信端末としてのエンドエンティテイ（ＥＥ）のセキュリティチップ（ＳＣ）、あるいはユーザ甲さんのユーザ識別デバイス（ＵＩＤ）のユーザセキュリティチップ（ＵＳＣ）である。
【０３９２】
このグループ属性証明書ＡＣ０１は、チャット運営サービスプロバイダ（ＳＰ）の提供するチャットルームを構成するサーバに対するアクセス権を有することを証明する属性証明書であり、チャットルームに対して参加する権限を有するユーザーグループあるいはユーザ機器グループに対して発行される。
【０３９３】
グループ属性証明書ＡＣ０２は、発行者が、乙さんのユーザデバイス、（ＥＥまたはＵＩＤ）であり、所有者、すなわちグループ属性証明書ＡＣ０２の発行時に発行者である乙さんのユーザデバイスのセキュリティチップ（ＳＣまたはＵＳＣ）と認証処理を行なうことによりグループ属性証明書ＡＣ０２の発行対象となった所有者は、甲さんのユーザデバイスのセキュリティチップ（ＳＣまたはＵＳＣ）である。
【０３９４】
このグループ属性証明書ＡＣ０２は、乙さんのユーザデバイスの管理サーバーヘのアクセス権を有することを証明する属性証明書であり、乙さんのユーザデバイスの管理サーバーにアクセスする権限を有するユーザーグループあるいはユーザ機器グループに対して発行される。
【０３９５】
なお、グループ属性証明書ＡＣ０１，ＡＣ０２の発行処理は、サービスプロバイダ（ＳＰ）あるいは乙さんユーザデバイスとしてのエンドエンティテイ（ＥＥ）あるいはユーザ識別デバイス（ＵＩＤ）自体が、グループ属性認証局（グループＡＡ）およびグループ属性証明書登録局（グループＡＲＡ）の機能を実行して、みずから発行することが可能であるが、グループ属性認証局（グループＡＡ）およびグループ属性証明書登録局（グループＡＲＡ）に依頼して発行処理を行なう構成も可能である。ただし、この場合には発行者のポリシーに従った処理が実行されることが条件である。
【０３９６】
例えばグループ属性証明書ＡＣ０１、ＡＣ０２の発行処理は、発行者であるサービスプロバイダ（ＳＰ）、乙さんのユーザデバイス（ＥＥ，ＵＩＤ）、あるいは、発行代理を行なうグループ属性証明書登録局（グループＡＲＡ）が、発行要求者としての甲さんから、甲さんであることを証明する既発行のグループ属性証明書、例えばクレジットカード会社の発行したグループ属性証明書を提示させ、その提出されたグループ属性証明書の検証を実行した後、新たなグループ属性証明書ＡＣ０１、ＡＣ０２の発行処理を行なう方法をとることが好ましい。このような既発行のグループ属性証明書の検証を条件として、新たなグループ属性証明書を発行する処理シーケンスは、先に図２９、図３０、図３２等を参照して説明した処理シーケンスと同様となる。
【０３９７】
図５４に示すグループ属性証明書の発行、格納形態は、図５５に示す通りとなる。チャットルーム提供サービスプロバイダ（ＳＰ）５０１と、エンドエンティテイとしての甲さん通信端末（ＥＥ）５１１、乙さん通信端末（ＥＥ）５３１は通信ネットワークにより相互にデータ転送可能であり、通信端末（ＥＥ）５１１とユーザ識別デバイス（ＵＩＤ）５２１、通信端末（ＥＥ）５３１とユーザ識別デバイス（ＵＩＤ）５３３は、双方の接続機器インタフェース２３１（図９参照）を介して相互にデータ転送が可能である。
【０３９８】
それぞれの機器には、耐タンパ構成を持つ（ユーザ）セキュリティチップ５１２，５２２，５３２，５３４またはセキュリティモジュール５０２が備えられ、データ通信処理の際の相互認証処理、あるいは転送データの暗号化、復号処理等を実行する。またグループ属性証明書の検証処理もこれらセキュリティチップ、セキュリティモジュールにおいて実行される。
【０３９９】
甲さんのユーザ識別デバイス５２１には、先に図５４を参照して説明したグループ属性証明書ＡＣ０１，５２３が格納される。グループ属性証明書ＡＣ０１，５２３は、発行者が、チャットルーム提供サービスプロバイダ（ＳＰ）５０１であり、チャットルーム参加権限確認処理に適用され、所有者である甲さんユーザデバイスのＵＳＣ５２１からチャットルーム提供サービスプロバイダ（ＳＰ）５０１に送付されて、チャットルーム提供サービスプロバイダ（ＳＰ）５０１のセキュリティモジュール（ＳＭ）５０２において、グループ属性証明書ＡＣ０１の検証、審査の後、サービス、すなわちチャットルーム参加が認められる。
【０４００】
また、甲さんのユーザ識別デバイス５２１には、先に図５４を参照して説明したグループ属性証明書ＡＣ０２，５２４も格納される。グループ属性証明書ＡＣ０２，５２４は、発行者が、乙さんユーザデバイス（ＥＥ５３１またはＵＩＤ５３３）であり、乙さんのユーザデバイスの管理サーバーに対するアクセス権限確認処理に適用され、所有者である甲さんユーザデバイスのＵＳＣ５２１から乙さんユーザデバイス（ＥＥ５３１またはＵＩＤ５３３）に送付されて、乙さんユーザデバイス（ＥＥ５３１またはＵＩＤ５３３）のセキュリティチップ（ＳＣ５３２またはＵＳＣ５３４）において、グループ属性証明書ＡＣ０２の検証、審査の後、サービス、すなわち乙さんデバイスの管理サーバーに対するアクセスが認められる。
【０４０１】
図５６を参照して、甲さんのユーザ識別デバイス４２１に格納されたグループ属性証明書ＡＣ０１，５２３を適用してチャットルーム参加サービスの利用権限確認処理を行ない、サービスを開始する処理シーケンスについて説明する。図５６において、
ＵＩＤ：甲さんユーザ識別デバイス（ユーザデバイス）制御部、
ＵＳＣ：ＵＩＤ内に構成されるユーザセキュリティチップ、
ＥＥ：甲さん通信端末（ＥＥ）制御部、
ＳＣ：ＥＥ内に構成されるセキュリティチップ、
ＳＰ：チャットルーム提供サービスプロバイダ（ＳＰ）制御部、
ＳＭ：ＳＰ内のセキュリティモジュール、
である。
【０４０２】
まず、ステップＳ４５１において、ユーザ（甲さん）がエンドエンティテイとしての甲さん通信端末（ＥＥ）の入力インタフェースを介して、グループ属性証明書（Ｇｐ．ＡＣ）＝ＡＣ０１の利用要求コマンドを入力する。このグループ属性証明書（Ｇｐ．ＡＣ）は、図５４、図５５に示すＡＣ０１である。この処理の際、ユーザは利用するグループ属性証明書ＡＣ０１に設定されたグループＩＤを指定する。ただし、特定のサービスを指定することにより唯一のグループＩＤが決定可能である場合は、サービスの指定のみとしてもよい。
【０４０３】
甲さん通信端末（ＥＥ）がユーザからのグループ属性証明書（Ｇｐ．ＡＣ）ＡＣ０１の利用要求入力を受領すると、ステップＳ４５２において、ユーザセキュリティチップ（ＵＳＣ）と、サービスプロバイダとしてのチャットルーム提供サービスプロバイダ（ＳＰ）のセキュリティモジュール（ＳＭ）間の相互認証が実行される。なお、ここでは省略して示してあるが、ダイレクトにＳＰとの通信を実行できないユーザ識別デバイス（ＵＩＤ）の場合は、
（１）ＥＥのＳＣとＳＰ−ＳＭとの相互認証、
（２）ＥＥのＳＣとＵＩＤのＵＳＣとの相互認証、
（３）ＵＩＤのＵＳＣとＳＰ−ＳＭとの相互認証、
のすべてを実行することになる。あるいは、簡便な方式として、ＵＩＤがＥＥに接続されることで、ＥＥは基本的にこれを受け入れる（認証したものとする）という処理構成としてもよく、この場合は、上記（２）の相互認証の省略が可能となる。さらに、上記３種の相互認証の様々な組み合わせによる認証構成が可能である。
【０４０４】
認証処理は、セキュリティチップ、セキュリテイモジュールの暗号処理部（図９参照）を中心とした処理として例えば先に図１３を参照して説明した公開鍵方式の相互認証処理として実行される。ステップＳ４５３では、ユーザセキュリティチップからエンドエンティテイに対して、相互認証の成立、不成立の結果情報を含む相互認証完了通知が出力される。相互認証不成立の場合は、処理の続行は中止される。相互認証が成立すると、ステップＳ４５４において、ユーザセキュリティチップ（ＵＳＣ）は、サービスプロバイダ（ＳＰ）のセキュリティモジュール（ＳＭ）に対して自己のメモリに格納したグループ属性証明書（Ｇｐ．ＡＣ）ＡＣ０１を送信する。このグループ属性証明書（Ｇｐ．ＡＣ）は、先に図５４、図５５を参照して説明したように、チャットルームへの参加資格権限を判定する処理に適用するグループ属性証明書ＡＣ０１である。
【０４０５】
ユーザセキュリティチップ（ＵＳＣ）からグループ属性証明書（Ｇｐ．ＡＣ）ＡＣ０１を受信したチャットルーム提供サービスプロバイダ（ＳＰ）のセキュリティモジュール（ＳＭ）は、ステップＳ４５５において、グループ属性証明書検証処理を実行する。グループ属性証明書の検証処理については、先に図２１乃至図２３を参照して説明した通りであり、属性証明書の署名検証、関連の公開鍵証明書（ＰＫＣ）および連鎖公開鍵証明書の確認処理等を含む処理として実行される。
【０４０６】
グループ属性証明書（Ｇｐ．ＡＣ）の検証処理後、セキュリティモジュール（ＳＭ）は、検証結果をチャットルーム提供サービスプロバイダ（ＳＰ）に出力し、検証不成立の場合は、エラー処理として、サービス提供を実行せず処理を中止する。この場合、グループＡＣの検証が不成立であった旨をエンドエンティテイに通知する処理を実行してもよい。
【０４０７】
グループ属性証明書（Ｇｐ．ＡＣ）の検証が成功し、グループ属性証明書（Ｇｐ．ＡＣ）の正当性が確認されるとステップＳ４５７に進む。ステップＳ４５７では、先に図２５を参照して説明したグループ属性証明書（Ｇｐ．ＡＣ）の審査を実行する。審査は、サービスプロバイダとしてのチャットルーム提供サービスプロバイダ（ＳＰ）の保有するグループ情報データベースに基づいて実行する。すなわち、チャットルーム提供サービスプロバイダ（ＳＰ）は、検証済みのグループ属性証明書（Ｇｐ．ＡＣ）ＡＣ０１から発行者情報、グループＩＤを取得し、取得情報に基づいて、グループ情報データベースを検索し、登録されたエントリーの有無を確認する。対応する登録エントリーがある場合は、グループ情報データベースからグループ情報を取得する。
【０４０８】
この場合のグループ情報は、チャットルームへの参加許可情報を含むものである。サービスプロバイダとしてのチャットルーム提供サービスプロバイダ（ＳＰ）は、ステップＳ４５８において、サービス提供処理、すなわち、グループ情報に従って、チャットルームへの参加許可を行なう。すなわち、チャットルームを提供するサーバーヘのアクセスを許可する処理を行なう。
【０４０９】
次に、図５７を参照して、甲さんのユーザ識別デバイス４２１に格納されたグループ属性証明書ＡＣ０２，５２４を適用して乙さんのユーザデバイスへのアクセス権限確認処理を行ない、甲さんおよび乙さんとのコミュニケーションを開始する処理シーケンスについて説明する。図５７において、
ＵＩＤ：甲さんユーザ識別デバイス（ユーザデバイス）制御部、
ＵＳＣ：ＵＩＤ内に構成されるユーザセキュリティチップ、
ＥＥ１：甲さん通信端末（ＥＥ）制御部、
ＳＣ１：ＥＥ１内に構成されるセキュリティチップ、
ＥＥ２：乙さん通信端末（ＥＥ）制御部、
ＳＣ２：ＥＥ２内に構成されるセキュリティチップ、
である。
【０４１０】
まず、ステップＳ４６１において、ユーザ（甲さん）がエンドエンティテイとしての甲さん通信端末（ＥＥ１）の入力インタフェースを介して、グループ属性証明書（Ｇｐ．ＡＣ）＝ＡＣ０２の利用要求コマンドを入力する。このグループ属性証明書（Ｇｐ．ＡＣ）は、図５４、図５５に示すＡＣ０２である。この処理の際、ユーザは利用するグループ属性証明書ＡＣ０２に設定されたグループＩＤを指定する。
【０４１１】
甲さん通信端末（ＥＥ１）がユーザからのグループ属性証明書（Ｇｐ．ＡＣ）ＡＣ０２の利用要求入力を受領すると、ステップＳ４６２において、ユーザセキュリティチップ（ＵＳＣ）と、乙さんユーザデバイスのセキュリティチップ（ＳＣ２）間の相互認証が実行される。なお、ここでは、グループ属性証明書（Ｇｐ．ＡＣ）ＡＣ０２は、乙さん通信端末（ＥＥ）のセキュリティチップ（ＳＣ２）が発行主体であった例を説明する。発行主体が乙さんのユーザ識別デバイス（ＵＩＤ）である場合は、乙さんのユーザ識別デバイス（ＵＩＤ）のユーザセキュリティチップ（ＵＳＣ）との認証を行なうことになる。
【０４１２】
認証処理は、セキュリティチップ、セキュリテイモジュールの暗号処理部（図９参照）を中心とした処理として例えば先に図１３を参照して説明した公開鍵方式の相互認証処理として実行される。ステップＳ４６３では、甲さんのユーザセキュリティチップ（ＵＳＣ）からエンドエンティテイ（ＥＥ１）に対して、相互認証の成立、不成立の結果情報を含む相互認証完了通知が出力される。相互認証不成立の場合は、処理の続行は中止される。相互認証が成立すると、ステップＳ４６４において、ユーザセキュリティチップ（ＵＳＣ）は、乙さん通信端末（ＥＥ）のセキュリティチップ（ＳＣ２）に対して自己のメモリに格納したグループ属性証明書（Ｇｐ．ＡＣ）ＡＣ０２を送信する。このグループ属性証明書（Ｇｐ．ＡＣ）は、先に図５４、図５５を参照して説明したように、乙さんのユーザデバイスのサーバーへのアクセス権限を判定する処理に適用するグループ属性証明書ＡＣ０２である。
【０４１３】
ユーザセキュリティチップ（ＵＳＣ）からグループ属性証明書（Ｇｐ．ＡＣ）ＡＣ０２を受信した乙さん通信端末（ＥＥ）のセキュリティチップ（ＳＣ２）は、ステップＳ４６５において、グループ属性証明書検証処理を実行する。グループ属性証明書の検証処理については、先に図２１乃至図２３を参照して説明した通りであり、属性証明書の署名検証、関連の公開鍵証明書（ＰＫＣ）および連鎖公開鍵証明書の確認処理等を含む処理として実行される。
【０４１４】
グループ属性証明書（Ｇｐ．ＡＣ）の検証処理後、乙さん通信端末（ＥＥ）のセキュリティチップ（ＳＣ２）は、検証結果を乙さん通信端末（ＥＥ）に出力し、検証不成立の場合は、エラー処理として、サービス提供を実行せず処理を中止する。この場合、グループＡＣの検証が不成立であった旨を甲さん側に通知する処理を実行してもよい。
【０４１５】
グループ属性証明書（Ｇｐ．ＡＣ）の検証が成功し、グループ属性証明書（Ｇｐ．ＡＣ）の正当性が確認されるとステップＳ４６７に進む。ステップＳ４６７では、先に図２５を参照して説明したグループ属性証明書（Ｇｐ．ＡＣ）の審査を実行する。審査は、乙さん通信端末（ＥＥ）の保有するグループ情報データベースに基づいて実行する。すなわち、乙さん通信端末（ＥＥ）は、検証済みのグループ属性証明書（Ｇｐ．ＡＣ）ＡＣ０２から発行者情報、グループＩＤを取得し、取得情報に基づいて、グループ情報データベースを検索し、登録されたエントリーの有無を確認する。対応する登録エントリーがある場合は、グループ情報データベースからグループ情報を取得する。
【０４１６】
この場合のグループ情報は、乙さんユーザデバイスのサーバーへのアクセス権限情報を含むものである。乙さん通信端末（ＥＥ）は、ステップＳ４６８において、サービス提供処理、すなわち、グループ情報に従って、乙さんユーザデバイスのサーバーへのアクセス許可を行なう。
【０４１７】
［（６）実行属性証明書（実行ＡＣ）］
次に、属性証明書を利用した権限確認に基づくサービス提供処理態様において、属性証明書に基づいてサービス受領権限を判定するのみならず、サービスの実行自体を属性証明書によって制限することを可能とした実行属性証明書（実行ＡＣ）について説明する。
【０４１８】
（６−１）実行属性証明書概要
上述したグループ属性証明書、あるいは従来から知られる一般的な属性証明書は、所有者の属性としての権限情報等、属性証明書の格納データが改竄されていないことを署名検証により検証することができる。以下、説明する実行属性証明書（実行ＡＣ）は、検証により、証明書が改竄されていないことの確認を実行するのみならず、さらに、証明書所有者が実行属性証明書に格納した暗号化データ（プログラム）を復号して、暗号化データ（プログラム）の復号に基づいてサービスを受領する構成を持つ。
【０４１９】
実行属性証明書に格納した暗号化データ（プログラム）を復号するために適用する鍵（登録鍵）は、実行属性証明書発行者と、実行属性証明書の所有者としてのサービス受領者に対応するユーザデバイスのセキュリティチップ（ＳＣ）のみが知り得る秘密の共通鍵である。従って、特定のユーザデバイスにおいてのみ実行属性証明書に基づくサービス実行が可能となる。
【０４２０】
なお、以下の説明においては、ユーザデバイスであるエンドエンティテイ（ＥＥ）のセキュリティチップ（ＳＣ）が実行属性証明書の処理を行なうものとして説明するが、以下に説明するセキュリティチップ（ＳＣ）での処理は、前述したグループ属性証明書における処理と同様、ユーザ識別デバイス（ＵＩＤ）のユーザセキュリティチップ（ＵＳＣ）においても同様に実行可能な処理である。
【０４２１】
実行属性証明書は、図５８（ａ）に示すように、提供サービスの実行に必要となるプログラム等の実行命令を登録鍵で暗号化したデータと、登録鍵を格納したセキュリティチップのメモリ、例えば図５８（ｃ）に示すセキュリティチップのＥＥＰＲＯＭ２０６内に形成される共通鍵メモリ領域２０７における登録鍵格納領域を示すアドレスデータとしてのメモリ領域ブロックアドレスを有する。その他、各種の属性証明書データ（図５参照）を有し、発行者署名を付したものである。データの改竄検証は、署名検証により実行可能である。署名生成、検証処理は、先に図１７、図１８を参照して説明した処理に従って実行可能である。
【０４２２】
なお、実行属性証明書は、属性証明書の基本フォーマット、例えばＩＴＵ−Ｔ　Ｘ．５０９に準拠したものとして構成可能である。ただし、ＩＴＵ−Ｔ　Ｘ．５０９で規定されたフォーマットに従うことが必須ではなく、独自フォーマットとした実行属性証明書を構成してもよい。
【０４２３】
セキュリティチップ（ＳＣ）の共通鍵メモリ領域２０７には、図５８（ｂ）に示すように、ユーザデバイスとしてのエンドエンティテイ（ＥＥ）の有する複数の実行属性証明書に対応する複数の登録鍵が所定のブロックアドレスに対して格納される。
【０４２４】
共通鍵メモリ領域２０７は、例えば６４ビットなどある固定されたサイズのブロックから構成される不揮発性メモリのメモリ領域である。登録鍵の格納処理、およびリセット処理は、所定の手続きに従って実行される。この処理については後述する。リセット命令を除き、登録鍵格納メモリ領域へのアクセスは、アクセスするブロックに格納された登録鍵で暗号化された命令を用いることによってのみ実行可能となる。また、秘密鍵についても、秘密鍵を読み出せない仕組みに加え、入力したデータを秘密鍵で暗号化または復号化した結果を直接読み出すことは出来ないような、仕組みを持っているものとする。ここで、直接読み出すことが出来ないというのは、例えば、ハッシュをかけた後、秘密鍵で暗号化することや、公開鍵で暗号化した命令を、秘密鍵で復号して実行することはできることを意味する。以下、実行属性証明書の所有者であるセキュリティチップあるいはモジュールは、この仕組みを持つものとする。
【０４２５】
実行属性証明書の利用手続き概要を図５９に示すフローに従って説明する。図５９は、例えば実行属性証明書の発行者としてのサービスプロバイダ（ＳＰ）と、実行属性証明書によるサービス受領者としてのユーザデバイスにおける処理の該略を示すフローである。ステップＳ５０１において、サービスプロバイダ（ＳＰ）とユーザデバイス間で相互認証が実行され、ステップＳ５０２において、例えば前述したグループ属性証明書に基づくサービス利用権限の審査が実行される。ここでの処理は、前述したグループ属性証明書における認証処理、検証処理と同様であり、認証処理は、セキュリティチップ、セキュリテイモジュールの暗号処理部（図９参照）を中心とした処理として例えば先に図１３を参照して説明した公開鍵方式の相互認証処理として実行される。検証処理は、先に図２１乃至図２３を参照して説明した、属性証明書の署名検証、関連の公開鍵証明書（ＰＫＣ）および連鎖公開鍵証明書の確認処理等を含む処理として実行される。
【０４２６】
次にステップＳ５０３の処理として、実行属性証明書（実行ＡＣ）に基づくサービス提供処理が行なわれる。実行属性証明書（実行ＡＣ）に基づくサービス提供処理は、ステップＳ５０４に示す実行属性証明書（実行ＡＣ）の発行処理、ステップＳ５０５に示す実行属性証明書（実行ＡＣ）の適用処理、ステップＳ５０６に示す実行属性証明書（実行ＡＣ）の破棄処理のいずれかの態様で実行されることになる。以下、これらの処理の詳細について、図を参照して説明する。
【０４２７】
（６−２）実行属性証明書発行処理
まず、実行属性証明書発行処理について説明する。図６０に実行属性証明書の発行シーケンス図を示す。図６０において、
ＥＥ：ユーザデバイスのエンドエンティテイ（ＥＥ）制御部、
ＳＣ：ＥＥ内に構成されるセキュリティチップ、
実行ＡＣテーブル：実行ＡＣの管理テーブル格納メモリおよびメモリ制御部
ＳＰ：実行ＡＣの発行処理を実行するサービスプロバイダ機器（ＳＰ）制御部、
ＳＭ：ＳＰ内のセキュリティモジュール、
である。
【０４２８】
まず、ステップＳ５１１において、ユーザがユーザデバイスとしてのエンドエンティテイ（ＥＥ）の入力インタフェースを介して、実行属性証明書（実行ＡＣ）発行要求コマンドを入力する。エンドエンティテイ（ＥＥ）がユーザからの実行属性証明書の発行要求を受領すると、ステップＳ５１２において、セキュリティチップ（ＳＣ）と、サービスプロバイダ（ＳＰ）のセキュリティモジュール（ＳＭ）間の相互認証、および実行属性証明書（実行ＡＣ）発行条件として適用される発行済みのグループ属性証明書の検証、審査処理が行なわれる。
【０４２９】
認証処理は、セキュリティチップ、セキュリテイモジュールの暗号処理部（図９参照）を中心とした処理として例えば先に図１３を参照して説明した公開鍵方式の相互認証処理として実行される。検証処理は、先に図２１乃至図２３を参照して説明した、属性証明書の署名検証、関連の公開鍵証明書（ＰＫＣ）および連鎖公開鍵証明書の確認処理等を含む処理として実行される。
【０４３０】
なお、ここでは、エンドエンティテイ（ＥＥ）のセキュリティチップ（ＳＣ）を発行対象とした実行属性証明書の発行処理例を示してあるが、ユーザ識別デバイス（ＵＩＤ）のユーザセキュリティチップ（ＵＳＣ）を発行対象とした実行属性証明書発行処理の場合は、
（１）ＥＥのＳＣとＳＰ−ＳＭとの相互認証、
（２）ＥＥのＳＣとＵＩＤのＵＳＣとの相互認証、
（３）ＵＩＤのＵＳＣとＳＰ−ＳＭとの相互認証、
のすべてを実行することになる。あるいは、簡便な方式として、ＵＩＤがＥＥに接続されることで、ＥＥは基本的にこれを受け入れる（認証したものとする）という処理構成としてもよく、この場合は、上記（２）の相互認証の省略が可能となる。さらに、上記３種の相互認証の様々な組み合わせによる認証構成が可能である。
【０４３１】
ステップＳ５１２の認証、グループ属性証明書の検証、審査がすべて成立すると、サービスプロバイダ（ＳＰ）は、ユーザデバイスのエンドエンティテイ（ＥＥ）に対して、登録鍵生成実行ＡＣ生成情報要求処理を行なう。これは、具体的には、実行属性証明書の実行命令（図５８参照）の暗号化、復号化処理に適用する登録鍵の格納領域として使用するメモリのメモリ領域空きアドレスを要求する処理である。
【０４３２】
エンドエンティテイ（ＥＥ）は、登録鍵生成実行ＡＣ生成情報要求を受信すると、ステップＳ５１４において、登録鍵の格納領域として使用するメモリのメモリ領域空きアドレス検索を実行ＡＣテーブル制御部に対して出力し、実行ＡＣテーブル（制御部）がこの要求に応じて、実行ＡＣテーブルを参照して、新規登録用の登録鍵を格納すべきメモリ領域空きアドレスをエンドエンティテイに通知する。実行ＡＣテーブルは、例えば図６２に示すように、サービスプロバイダの識別データとしてのＳＰ情報、サービスプロバイダの提供するサービス情報、例えば暗号化コンテンツ情報、サービスプロバイダの提供するサービス情報利用のために必要となるプログラムを実行命令として格納した実行ＡＣとを対応付けたテーブルである。実行ＡＣテーブルは、エンドエンティテイ（ＥＥ）またはセキュリティチップ（ＳＣ）内のメモリに格納される。
【０４３３】
実行ＡＣテーブル（制御部）は、すでに格納済みの実行ＡＣに対応する登録鍵のメモリ領域ブロックアドレスを参照して、自己のセキュリティチップにおける空きアドレスを検出して、新規登録用の登録鍵を格納すべきメモリ領域空きアドレスをエンドエンティテイに通知する。実行ＡＣテーブル制御部は、実行ＡＣテーブルを格納したメモリのアクセス制御、データ抽出を実行し、エンドエンティテイ（ＥＥ）またはセキュリティチップ（ＳＣ）のメモリアクセス制御処理を実行するＣＰＵ等により構成される制御部である。
【０４３４】
エンドエンティテイ（ＥＥ）は、ステップＳ５１６において、空きアドレスをサービスプロバイダ（ＳＰ）に送信する。新規登録鍵のメモリ領域ブロックアドレスを受信したサービスプロバイダ（ＳＰ）は、ステップＳ５１７において、登録鍵生成実行ＡＣの生成要求をセキュリティモジュール（ＳＭ）に出力し、ステップＳ５１８において、セキュリティモジュール（ＳＭ）は、登録鍵生成実行ＡＣの生成処理を行なう。サービスプロバイダ（ＳＰ）からセキュリティモジュール（ＳＭ）に対して出力される登録鍵生成実行ＡＣの生成要求には、セキュリティチップ公開鍵（ＫｐＳＣ）を格納したセキュリティチップ公開鍵証明書、登録鍵のリセット時に適用するリセット鍵（Ｋｒｅｓｅｔ）、登録鍵生成命令（ＧｅｎＫｅｒ）、メモリ領域ブロックアドレス（Ａｄ）が含まれる。
【０４３５】
図６３を参照して、セキュリティモジュール（ＳＭ）における登録鍵生成実行ＡＣの生成処理の詳細を説明する。
【０４３６】
セキュリティモジュール（ＳＭ）６０１は、先に図９を参照して説明したセキュリティチップ構成と同様の構成であり、図６３は、その構成中の暗号処理部、メモリ部を抽出して示すものである。暗号処理部としては、公開鍵暗号エンジン６０２、共通鍵暗号エンジン６０３を有する。セキュリティモジュール（ＳＭ）６０１は、先に、図９を参照して説明したように、ＣＰＵ，ＲＡＭ，ＲＯＭ等の構成を持ち、その他のデータ処理、データ入出力処理が可能である。
【０４３７】
公開鍵暗号エンジン６０２は、楕円曲線暗号、あるいはＲＳＡ（Ｒｉｖｅｓｔ−Ｓｈａｍｉｒ−Ａｄｌｅｍａｎ）暗号処理等の公開鍵方式の暗号処理を実行し、データの暗号化、復号化、署名生成、検証処理等を行なう。共通鍵暗号エンジン６０３は、例えばＤＥＳ、トリプルＤＥＳ等の共通鍵暗号方式の暗号処理を実行し、データの暗号化、復号化等を行なう。なお、セキュリティモジュール（ＳＭ）６０１は、さらにハッシュ生成処理、乱数発生処理機能を持つ。
【０４３８】
セキュリティモジュール（ＳＭ）は、上述したように登録鍵生成実行ＡＣ生成要求に伴い、セキュリティチップ公開鍵（ＫｐＳＣ）を格納したセキュリティチップ公開鍵証明書、登録鍵のリセット時に適用するリセット鍵（Ｋｒｅｓｅｔ）、登録鍵生成命令（ＧｅｎＫｅｒ）、メモリ領域ブロックアドレス（Ａｄ）を入力する。
【０４３９】
ステップＳ５４１の乱数発生処理において、発生した乱数に基づくセッション鍵（Ｋｃｓ）と登録鍵生成命令（ＧｅｎＫｅｒ）がステップＳ５４２において、セキュリティチップ公開鍵（ＫｐＳＣ）を用いて暗号化され、暗号化データ（Ｅｐ（ＧｅｎＫｃｒ｜｜Ｋｃｓ；ＫｐＳＣ）が生成される。なお、ａ｜｜ｂはａ，ｂの連結データを示し、Ｅｐ（ａ；ｂ）は、鍵ｂを適用したａの公開鍵暗号方式に基づく暗号化メッセージを示す。
【０４４０】
次に、ステップＳ５４３において、実行命令付加処理が行なわれる。Ｄｐｃ［ａ］は、公開鍵暗号方式に基づく秘密鍵による復号に基づいてデータａ内のコマンドを実行する実行命令を示す。さらに、ステップＳ５４４において、リセット鍵（Ｋｒｅｓｅｔ）に基づく共通鍵方式の暗号化処理が実行され、暗号化データ（Ｅｃ（Ｄｐｃ［Ｅｐ（ＧｅｎＫｃｒ｜｜Ｋｃｓ；ＫｐＳＣ）］；Ｋｒｅｓｅｔ）が生成される。なお、Ｅｃ（ａ；ｂ）は、鍵ｂを適用したａの共通鍵暗号方式に基づく暗号化メッセージを示す。
【０４４１】
さらに、ステップＳ５４５において、上記暗号化データ（Ｅｃ（Ｄｐｃ［Ｅｐ（ＧｅｎＫｃｒ｜｜Ｋｃｓ；ＫｐＳＣ）］；Ｋｒｅｓｅｔ）と、新規登録鍵の格納領域を示すメモリ領域ブロックアドレス（Ａｄ）との連結データに対して、セキュリティモジュール（ＳＭ）の秘密鍵（ＫｓＳＭ）を適用した署名処理が実行される。これらの処理の結果、登録鍵生成実行ＡＣ６１１が生成される。
【０４４２】
登録鍵生成実行ＡＣ６１１は、
新規登録鍵の格納領域を示すメモリ領域ブロックアドレス（Ａｄ）、
暗号化データ（Ｅｃ（Ｄｐｃ［Ｅｐ（ＧｅｎＫｃｒ｜｜Ｋｃｓ；ＫｐＳＣ）］；Ｋｒｅｓｅｔ））、および、
署名データ、Ｅｐ（Ｈ（Ａｄ｜｜Ｅｃ（Ｄｐｃ［Ｅｐ（ＧｅｎＫｃｒ｜｜Ｋｃｓ；ＫｐＳＣ）］；Ｋｒｅｓｅｔ；ＫｓＳＭ）を含む構成となる。なお、Ｈ（ａ）は、ａのハッシュ値を示す。
【０４４３】
図６０のシーケンス図に戻り、説明を続ける。ステップＳ５１８においてセキュリティモジュール（ＳＭ）における登録鍵生成実行ＡＣ生成処理が終了すると、セキュリティモジュール（ＳＭ）からサービスプロバイダ（ＳＰ）に登録鍵生成実行ＡＣが送付され、ステップＳ５１９において、サービスプロバイダ（ＳＰ）から、ユーザデバイスのエンドエンティテイ（ＥＥ）に登録鍵生成実行ＡＣが送付される。
【０４４４】
ステップＳ５２０において、ユーザデバイスのエンドエンティテイ（ＥＥ）は、実行ＡＣテーブル（図６２参照）の更新要求を実行ＡＣテーブル（制御部）に送信し、実行ＡＣテーブル（制御部）は、ステップＳ５２１において実行ＡＣテーブル更新を行なう。実行ＡＣテーブル（図６２参照）の更新要求には、新規登録鍵を適用して利用可能なコンテンツ情報、サービスプロバイダ情報、メモリ領域ブロックアドレスが含まれ、実行ＡＣテーブルに対する新規エントリデータとして、これらの情報を登録する。
【０４４５】
さらに、ユーザデバイスのエンドエンティテイ（ＥＥ）は、ステップＳ５２２において、セキュリティチップ（ＳＣ）に対して、登録鍵生成要求を出力する。この要求は、登録鍵生成実行ＡＣをセキュリティチップ（ＳＣ）に対して送付する処理として行われる。
【０４４６】
セキュリティチップ（ＳＣ）は、ステップＳ５２３において登録鍵生成処理を実行する。セキュリティチップで実行される登録鍵生成実行ＡＣに基づく登録鍵生成処理について、図６４を参照して説明する。
【０４４７】
セキュリティチップ（ＳＣ）６０５は、先に図９を参照して説明したセキュリティチップ構成と同様の構成である。ただし、図５８において説明したように、共通鍵メモリ領域を有する。図６４は、その構成中の暗号処理部、メモリ部を抽出して示すものである。暗号処理部としては、公開鍵暗号エンジン６０６、共通鍵暗号エンジン６０７を有し、メモリ部として共通鍵メモリ領域６０８を有する。セキュリティチップ（ＳＣ）６０５は、先に、図９を参照して説明したように、ＣＰＵ，ＲＡＭ，ＲＯＭ等の構成を持ち、その他のデータ処理、例えば暗号処理部において復号された実行命令に基づくデータ処理、データ入出力処理等も実行可能である。例えば共通鍵メモリ６０８に対するデータの書き込み、読み取り、外部からのデータ入力、外部へのデータ出力、各素子間のデータ転送等のデータ処理はＣＰＵの制御を中心として実行される。
【０４４８】
公開鍵暗号エンジン６０６は、楕円曲線暗号、あるいはＲＳＡ（Ｒｉｖｅｓｔ−Ｓｈａｍｉｒ−Ａｄｌｅｍａｎ）暗号処理等の公開鍵方式の暗号処理を実行し、データの暗号化、復号化、署名生成、検証処理等を行なう。共通鍵暗号エンジン６０７は、例えばＤＥＳ、トリプルＤＥＳ等の共通鍵暗号方式の暗号処理を実行し、データの暗号化、復号化等を行なう。共通鍵メモリ領域６０８は、登録鍵を格納するメモリであり、例えば６４ビットなどある固定されたサイズのブロックから構成される不揮発性メモリからなるメモリである。なお、セキュリティチップ（ＳＣ）６０５は、さらにハッシュ生成処理、乱数発生処理機能を持つ。
【０４４９】
セキュリティチップ（ＳＣ）は、上述したようにエンドエンティテイからの登録鍵生成要求に伴い、登録鍵生成実行ＡＣ６１１を入力する。
【０４５０】
ステップＳ５５１において、リセット鍵（Ｋｒｅｓｅｔ）を適用した共通鍵方式の復号処理によって、登録鍵生成実行ＡＣ６１１の実行命令データ（Ｄｐｃ［Ｅｐ（ＧｅｎＫｃｒ｜｜Ｋｃｓ；ＫｐＳＣ）］が取り出され、さらに、ステップＳ５５２において、復号した実行命令に対応するデータ処理として、セキュリティチップの秘密鍵（ＫｓＳＣ）を適用した公開鍵方式の復号処理によって、登録鍵生成命令（ＧｅｎＫｅｒ）と、セッション鍵（Ｋｃｓ）との連結データが取り出される。
【０４５１】
次のステップＳ５５３も、復号実行命令に対応するデータ処理であり、登録鍵生成命令（ＧｅｎＫｅｒ）の実行処理ステップである。ステップＳ５５４において乱数に基づく登録鍵（Ｋｃｒ）を生成し、ステップＳ５５５において、登録鍵（Ｋｃｒ）を登録鍵の格納領域アドレスであるメモリ領域ブロックアドレス（Ａｄ）に従って、共通鍵メモリ領域６０８に書き込む。
【０４５２】
さらに、ステップＳ５５６において、登録鍵（Ｋｃｒ）とメモリ領域ブロックアドレス（Ａｄ）との連結データをセッション鍵（Ｋｃｓ）で暗号化して、登録鍵生成結果６１２として、エンドエンティテイ（ＥＥ）に出力する。
【０４５３】
登録鍵生成結果６１２のエンドエンティテイ（ＥＥ）への出力ステップは図６１におけるステップＳ５２４に相当する。
【０４５４】
登録鍵（Ｋｃｒ）とメモリ領域ブロックアドレス（Ａｄ）との連結データをセッション鍵（Ｋｃｓ）で暗号化した登録鍵生成結果は、ユーザデバイスのエンドエンティテイ（ＥＥ）から、サービスプロバイダ（ＳＰ）に送信される。
【０４５５】
サービスプロバイダ（ＳＰ）は、登録鍵生成結果を受信すると、ステップＳ５２６において、登録鍵生成結果をセキュリティモジュール（ＳＭ）に送付することにより、サービス提供実行ＡＣの生成要求を行なう。セキュリティモジュール（ＳＭ）は、ステップＳ５２７において、サービス提供実行ＡＣの生成処理を実行する。
【０４５６】
セキュリティモジュール（ＳＭ）によるサービス提供実行ＡＣの生成処理を図６５を参照して説明する。
【０４５７】
まず、ステップＳ５６１において、セッション鍵（Ｋｃｓ）を適用して、登録鍵生成結果の復号処理を実行し、登録鍵（Ｋｃｒ）とメモリ領域ブロックアドレス（Ａｄ）との連結データ（Ａｄ｜｜Ｋｃｒ）を取得する。さらに、ステップＳ５６２において、サービス提供実行ＡＣに格納する実行命令（ＤｅｃＥＤａｔａ｜｜Ｋｃｄ）６１３を登録鍵（Ｋｃｒ）を適用して暗号化する。なお、実行命令は、サービス提供実行ＡＣに応じて設定される実行プログラム等の実行命令である。ここでは、データ復号鍵（Ｋｃｄ）と、暗号化データの復号命令（ＤｅｃＥＤａｔａ）との連結データによって構成された実行命令を例として示している。
【０４５８】
さらに、ステップＳ５６３において、実行命令（ＤｅｃＥＤａｔａ｜｜Ｋｃｄ）６１３を登録鍵（Ｋｃｒ）で暗号化したデータ（Ｅｃ（ＤｅｃＥＤａｔａ｜｜Ｋｃｄ）；Ｋｃｒ）と、登録鍵（Ｋｃｒ）を格納するユーザデバイスにおけるセキュリティチップのメモリ領域ブロックアドレス（Ａｄ）とのデータに対して、セキュリティモジュールの秘密鍵（ＫｓＳＭ）によって署名（図１７参照）が生成され、サービス提供実行ＡＣ６１４が生成される。ここでは、サービス提供実行ＡＣ６１４は、暗号化データの復号処理をサービスとして実行する実行属性証明書である。
【０４５９】
この実行属性証明書に格納される実行命令を復号するためには、登録鍵（Ｋｃｒ）の適用が必須となり、登録鍵の情報を有するのは、ここでは、このサービス提供実行ＡＣの生成プロセスに参加しているユーザデバイスのセキュリティチップ（ＳＣ）およびサービスプロバイダのセキュリティモジュール（ＳＭ）のみとなる。
【０４６０】
図６１に戻りシーケンス図の説明を続ける。ステップＳ５２７において、セキュリティモジュール（ＳＭ）がサービス提供実行ＡＣを生成すると、サービス提供実行ＡＣはステップＳ５２８において、サービスプロバイダ（ＳＰ）からユーザデバイスのエンドエンティテイ（ＥＥ）に送付され、さらに、ステップＳ５２９において、実行ＡＣテーブル制御部に送付されて、ステップＳ５３０において、実行ＡＣテーブル（図６２参照）内に格納される。
【０４６１】
上述のプロセスにより、図５８（ａ）に示すように、登録鍵を格納したユーザデバイスのセキュリティチップのメモリ領域ブロックアドレスと、その登録鍵で暗号化された実行命令と、さらに発行者署名、以上の各データを有する実行属性証明書（実行ＡＣ）がユーザデバイスに格納されることになる。なお、これらのデータ以外にも、先に図５を参照して説明したグループ属性証明書の各フィールドのデータを格納することは任意である。ただし、署名は、改竄チェック対象となるデータ全体に対して実行することが必要となる。
【０４６２】
（６−３）実行属性証明書適用処理
次に、上述の手続きにおいて発行された実行属性証明書の適用処理について説明する。図６６は、サービス提供実行ＡＣのユーザデバイス側における適用シーケンスをまとめた図である。すでに、前述の処理によって、ユーザデバイスの実行ＡＣテーブルにサービス提供実行ＡＣが格納済みである。
【０４６３】
ステップＳ５７１において、ユーザがエンドエンティテイ（ＥＥ）のユーザインタフェースを介してサービス提供実行ＡＣの適用処理要求を入力する。この処理要求には、実行ＡＣの識別子、またはサービスプロバイダ（ＳＰ）情報、サービス内容を特定するデータ、例えば利用コンテンツ、利用プログラムの指定データが含まれる。エンドエンティテイ（ＥＥ）は、ステップＳ５７２において、ユーザ指定のサービス提供実行ＡＣの検索要求を実行ＡＣテーブルに出力する。検索キーは、例えばコンテンツ情報やサービスプロバイダ（ＳＰ）情報等である。
【０４６４】
ステップＳ５７３において、実行ＡＣテーブルは、エンドエンティテイからの入力キーに基づいて、対応するサービス提供実行ＡＣを検索し、ステップＳ５７４において、テーブルから抽出したサービス提供実行ＡＣをエンドエンティテイ（ＥＥ）に出力する。
【０４６５】
ステップＳ５７５において、エンドエンティテイ（ＥＥ）は、受領ＡＣをセキュリティチップ（ＳＣ）に出力し、サービス提供実行ＡＣの適用処理要求を行なう。セキュリティチップは、ステップＳ５７６において、受領ＡＣの提供処理、すなわち、実行属性証明書（実行ＡＣ）に従ったサービス提供を行なう。
【０４６６】
セキュリティチップ（ＳＣ）におけるステップＳ５７６のサービス提供処理の詳細を図６７を参照して説明する。セキュリティチップ６０５は、サービス提供実行ＡＣ６１４を入力する。
【０４６７】
サービス提供実行ＡＣ６１４は、実行命令（ＤｅｃＥＤａｔａ｜｜Ｋｃｄ）を登録鍵（Ｋｃｒ）で暗号化したデータ（Ｅｃ（ＤｅｃＥＤａｔａ｜｜Ｋｃｄ）；Ｋｃｒ）と、登録鍵（Ｋｃｒ）を格納するユーザデバイスにおけるセキュリティチップのメモリ領域ブロックアドレス（Ａｄ）と、各データに対して、セキュリティモジュールの秘密鍵（ＫｓＳＭ）によって署名したデータを含む。
【０４６８】
セキュリティチップ６０５は、ステップＳ５８１において、サービス提供実行ＡＣ内のメモリ領域ブロックアドレス（Ａｄ）に従って、共通鍵メモリ領域６０８から登録鍵（Ｋｃｒ）を取得し、取得した登録鍵（Ｋｃｒ）によって、サービス提供実行ＡＣ内の暗号化データ（Ｅｃ（ＤｅｃＥＤａｔａ｜｜Ｋｃｄ）；Ｋｃｒ）の復号処理を実行し、データ復号鍵（Ｋｃｄ）と、暗号化データの復号命令（ＤｅｃＥＤａｔａ）を取得する。
【０４６９】
ステップＳ５８２において、復号した実行命令に基づくデータ処理が実行される。すなわち、データ復号鍵（Ｋｃｄ）を適用して、外部から入力される復号対象の暗号化データ（Ｅｃ（データ；Ｋｃｄ））６１５の復号処理を実行し、復号されたデータ６１６を出力する。復号対象の暗号化データ（Ｅｃ（データ；Ｋｃｄ））６１５は、例えば画像、音楽、プログラム等のコンテンツを、鍵（Ｋｃｄ）により暗号化したデータであり、サービス提供実行ＡＣ内の格納実行命令を登録鍵（Ｋｃｒ）によって復号することによって取得可能なデータ復号鍵（Ｋｃｄ）によって復号可能となる。
【０４７０】
図６６のシーケンス図に戻り説明を続ける。ステップＳ５７６のサービス提供の後、セキュリティチップ（ＳＣ）は、ステップＳ５７７において、登録鍵破棄処理を行なう。この登録鍵破棄処理は、サービス提供実行ＡＣに応じて実行する場合と実行不要となる場合とがある。サービス提供実行ＡＣに基づくサービス提供処理を一度限りとして設定した実行ＡＣである場合は、この破棄処理をサービス提供処理に続いて実行する。
【０４７１】
ステップＳ５７７のＳＣ（セキュリティチップ）登録鍵破棄処理について、図６８を参照して説明する。登録鍵のリセット処理は、共通鍵メモリ領域６０８の登録鍵の格納領域にリセット鍵（Ｋｒｅｓｅｔ）を上書きすることによって行われる。破棄対象となる登録鍵（Ｋｃｒ）のメモリ領域ブロックアドレス（Ａｄ）とリセット鍵（Ｋｒｅｓｅｔ）とからなるリセット処理命令６１７が例えばエンドエンティテイ（ＥＥ）から入力されると、ステップＳ５８３において、リセット処理命令６１７に格納されたメモリ領域ブロックアドレス（Ａｄ）に対応するメモリ領域に、リセット鍵（Ｋｒｅｓｅｔ）の書き込み処理が実行され、登録鍵の削除が完了する。
【０４７２】
図６６のシーケンス図に戻り説明を続ける。ステップＳ５７７において、登録鍵の破棄が完了すると、ステップＳ５７８において登録鍵破棄通知がエンドエンティテイ（ＥＥ）に出力され、エンドエンティテイ（ＥＥ）は、ステップＳ５７９において、実行ＡＣテーブルに対してサービス提供実行ＡＣの削除要求を出力し、実行ＡＣテーブル（制御部）は、実行ＡＣテーブルから対応する実行ＡＣを削除する。
【０４７３】
（６−４）登録鍵リセット処理
なお、登録鍵の破棄処理は、サービス提供実行ＡＣの提供処理に続いて実行されるとは限らず、任意タイミングのリセット要求に基づいて登録鍵の破棄処理としてのリセット処理を実行することが可能である。このリセット要求に基づく処理について、図６９を参照して説明する。
【０４７４】
ステップＳ６０１において、ユーザがエンドエンティテイ（ＥＥ）のユーザインタフェースを介してユーザデバイスに格納されているサービス提供実行ＡＣに対応する登録鍵のリセット要求を入力する。エンドエンティテイ（ＥＥ）は、ステップＳ６０２において、実行ＡＣテーブルに検索要求を出力する。リセット要求の態様は２通ある。第１の態様は、ユーザが実行ＡＣテーブルのあるメモリ領域ブロックアドレスに書き込んだサービス内容を忘れた場合、メモリ領域ブロックアドレスをキーとして実行ＡＣテーブルを検索し、出力されたＳＰ情報・コンテンツ情報に対応する登録鍵をユーザが不要であると判断するとリセット実行要求を行う態様である。この処理要求には、例えば実行ＡＣの識別子、またはサービス内容を特定するデータ、例えばコンテンツ、プログラム、あるいはサービスプロバイダ（ＳＰ）情報データが含まれる。第２の態様は、ユーザがＳＰ情報・コンテンツ情報を既知の場合、これらをキーとして実行ＡＣテーブルを検索し、出力されたメモリ領域ブロックアドレスをリセット実行要求と共にＳＣへ送信する態様である。なお、登録鍵のメモリ領域ブロックアドレスは、コンテンツ、あるいはサービスプロバイダに対応するデータとしてエンドエンティテイにおいて、任意に格納することが可能である。
【０４７５】
ステップＳ６０３において、実行ＡＣテーブルは、エンドエンティテイからの入力キーに基づいて、対応するサービス提供実行ＡＣを検索し、サービス提供実行ＡＣに対応するサービスプロバイダ、利用可能コンテンツを検索し、ステップＳ６０４において、エンドエンティテイ（ＥＥ）に出力する。
【０４７６】
エンドエンティテイ（ＥＥ）では、サービスプロバイダ、利用可能コンテンツ情報を表示し、ユーザが不要であると判定すると、ステップＳ６０６において、セキュリティチップに対してリセット実行要求を出力する。
【０４７７】
登録鍵のリセット処理は、共通鍵メモリ領域の登録鍵の格納領域にリセット鍵（Ｋｒｅｓｅｔ）を上書きすることによって行われ、破棄対象となる登録鍵（Ｋｃｒ）のメモリ領域ブロックアドレス（Ａｄ）とリセット鍵（Ｋｒｅｓｅｔ）とからなるリセット処理命令をエンドエンティテイ（ＥＥ）から入力し、ステップＳ６０７において、先に図６８を参照して説明した通りの、メモリ領域ブロックアドレス（Ａｄ）に対応するメモリ領域に、リセット鍵（Ｋｒｅｓｅｔ）の書き込み処理が実行され、登録鍵がリセットされる。ステップＳ６０７において、登録鍵のリセットが完了すると、ステップＳ６０８においてリセット完了通知がエンドエンティテイ（ＥＥ）に出力される。
【０４７８】
（６−５）実行属性証明書リセット（破棄）処理
次に、ユーザデバイスに格納された実行属性証明書を破棄し、破棄が間違いなく実行されたことをサービスプロバイダに通知する実行属性証明書リセット（破棄）処理について説明する。
【０４７９】
図７０、図７１の処理シーケンス図に従って説明する。図７０、図７１において、
ＥＥ：ユーザデバイスのエンドエンティテイ（ＥＥ）制御部、
ＳＣ：ＥＥ内に構成されるセキュリティチップ、
実行ＡＣテーブル：実行ＡＣの管理テーブル格納メモリおよびメモリ制御部
ＳＰ：実行ＡＣの発行処理を実行するサービスプロバイダ機器（ＳＰ）制御部、
ＳＭ：ＳＰ内のセキュリティモジュール、
である。
【０４８０】
まず、ステップＳ６１１において、ユーザがエンドエンティテイ（ＥＥ）の入力インタフェースを介して、実行属性証明書（実行ＡＣ）破棄申請要求コマンドを入力する。この要求に基づき、実行属性証明書破棄申請がサービスプロバイダに送信される。申請には、例えば実行属性証明書（実行ＡＣ）ＩＤ、あるいはコンテンツ、サービス指定データ等、破棄対象とする実行属性証明書（実行ＡＣ）を特定可能なデータが含まれる。
【０４８１】
サービスプロバイダ機器制御部（ＳＰ）が実行属性証明書破棄申請を受領すると、ステップＳ６１２において、セキュリティチップ（ＳＣ）と、サービスプロバイダ（ＳＰ）のセキュリティモジュール（ＳＭ）間の相互認証、および、必要に応じて実行属性証明書（実行ＡＣ）破棄処理条件として適用されるサービスプロバイダに発行済みのグループ属性証明書の検証、審査処理が行なわれる。実行属性証明書破棄処理をひとつのサービスと見立てた場合、エンドエンティティがサービスプロバイダの役割をになうことになる。
【０４８２】
認証処理は、セキュリティチップ、セキュリテイモジュールの暗号処理部（図９参照）を中心とした処理として例えば先に図１３を参照して説明した公開鍵方式の相互認証処理として実行される。検証処理は、先に図２１乃至図２３を参照して説明した、属性証明書の署名検証、関連の公開鍵証明書（ＰＫＣ）および連鎖公開鍵証明書の確認処理等を含む処理として実行される。
【０４８３】
なお、ここでは、エンドエンティテイ（ＥＥ）のセキュリティチップ（ＳＣ）を発行対象とした実行属性証明書の破棄処理例を示してあるが、ユーザ識別デバイス（ＵＩＤ）のユーザセキュリティチップ（ＵＳＣ）を発行対象とした実行属性証明書の破棄処理の場合は、
（１）ＥＥのＳＣとＳＰ−ＳＭとの相互認証、
（２）ＥＥのＳＣとＵＩＤのＵＳＣとの相互認証、
（３）ＵＩＤのＵＳＣとＳＰ−ＳＭとの相互認証、
のすべてを実行することになる。あるいは、簡便な方式として、ＵＩＤがＥＥに接続されることで、ＥＥは基本的にこれを受け入れる（認証したものとする）という処理構成としてもよく、この場合は、上記（２）の相互認証の省略が可能となる。さらに、上記３種の相互認証の様々な組み合わせによる認証構成が可能である。
【０４８４】
ステップＳ６１２の認証、グループ属性証明書の検証、審査がすべて成立すると、ユーザデバイスのエンドエンティテイ（ＥＥ）は、ステップＳ６１３において、破棄対象の実行ＡＣの検索要求を実行ＡＣテーブルに出力する。検索キーは、例えばコンテンツ情報やサービスプロバイダ（ＳＰ）情報等である。
【０４８５】
ステップＳ６１４において、実行ＡＣテーブルは、エンドエンティテイからの入力キーに基づいて、対応するサービス提供実行ＡＣを検索し、ステップＳ６１５において、テーブルから抽出したサービス提供実行ＡＣをエンドエンティテイ（ＥＥ）に出力する。さらに、実行ＡＣテーブル（制御部）は、ステップＳ６１６において、破棄対象実行ＡＣのエントリを実行ＡＣテーブルから削除する。
【０４８６】
ステップＳ６１７において、エンドエンティテイ（ＥＥ）は、セキュリティチップに対してリセット実行要求を出力する。ステップＳ６１８において、登録鍵のリセット処理として、共通鍵メモリ領域の登録鍵の格納領域にリセット鍵（Ｋｒｅｓｅｔ）を上書きする処理（図６８参照）が実行され、リセット完了通知がエンドエンティテイ（ＥＥ）に出力される。
【０４８７】
さらに、エンドエンティテイ（ＥＥ）は、図７１に示すステップＳ６２１において、リセット完了通知をサービスプロバイダ（ＳＰ）に送信する。このリセット完了通知は、破棄対象実行ＡＣを伴う。破棄対象実行ＡＣを受領したサービスプロバイダ（ＳＰ）は、ステップＳ６２２において、リセット確認実行ＡＣの生成要求をセキュリティモジュール（ＳＭ）に出力する。この要求は破棄対象実行ＡＣを伴って実行される。
【０４８８】
ステップＳ６２３において、セキュリティモジュール（ＳＭ）は、破棄対象の実行ＡＣから、対応する登録鍵を格納したメモリ領域ブロックアドレス情報を抽出し、ステップＳ６２４においてリセット確認実行ＡＣの生成処理を実行する。リセット確認実行ＡＣは、破棄対象の実行ＡＣの対応登録鍵を格納したメモリ領域ブロックアドレス情報（Ａｄ）と、リセット確認実行ＡＣによって、ユーザデバイスのセキュリティチップ（ＳＣ）において実行すべき命令としての実行命令と、発行者、すなわちセキュリティモジュール（ＳＭ）の署名とを含むデータ構成（図７２、リセット確認実行ＡＣ６２１参照）である。
【０４８９】
生成されたリセット確認実行ＡＣは、ステップＳ６２５においてサービスプロバイダ（ＳＰ）からエンドエンティテイ（ＥＥ）に送信され、さらに、ステップＳ６２６において、セキュリティチップ（ＳＣ）に転送される。
【０４９０】
セキュリティチップ（ＳＣ）では、ステップＳ６２７において、リセット確認実行ＡＣに基づくリセット確認結果生成処理を実行する。ステップＳ６２７のリセット確認結果生成処理の詳細について図７２を参照して説明する。
【０４９１】
図７２に示すように、セキュリティチップ６０５は、ステップＳ６４１において、リセット確認実行ＡＣの実行命令を、リセット確認実行ＡＣ６２１に格納されたアドレスに基づいて共通鍵メモリ領域６０８から取り出したリセット鍵（Ｋｒｅｓｅｔ）を適用して復号し、セキュリティチップの公開鍵（ＫｐＳＣ）で暗号化されたデータ（Ｅｐ（ＣｏｎｆＲｅｓｅｔ｜｜Ｋｃｓ；ＫｐＳＣ））の復号命令データ（Ｄｐｃ［Ｅｐ（ＣｏｎｆＲｅｓｅｔ｜｜Ｋｃｓ；ＫｐＳＣ）］を取得し、ステップＳ６４２において、セキュリティチップの秘密鍵（ＫｓＳＣ）を適用して復号し、リセット確認結果作成コマンド（ＣｏｎｆＲｅｓｅｔ）、セッション鍵（Ｋｃｓ）、を取得し、ステップＳ６４３のリセット確認結果作成処理を実行する。
【０４９２】
ステップＳ６４３のリセット確認結果作成処理では、まず、ステップＳ６４４において、リセット確認実行ＡＣ６２１に格納されたアドレスに基づいて共通鍵メモリ領域６０８からリセット鍵（Ｋｒｅｓｅｔ）が読み出され、さらに、ステップＳ６４５において、メモリ領域ブロックアドレス情報（Ａｄ）と、リセット鍵（Ｋｒｅｓｅｔ）の連結データをセッション鍵（Ｋｃｓ）で暗号化し、暗号化データ（Ｅｃ（Ａｄ｜｜Ｋｒｅｓｅｔ；Ｋｃｓ））からなるリセット確認結果６２２をエンドエンティテイ（ＥＥ）に出力する。
【０４９３】
エンドエンティテイ（ＥＥ）は、図７１のステップＳ６２８においてリセット確認結果をサービスプロバイダ（ＳＰ）に送信し、サービスプロバイダ（ＳＰ）は、ステップＳ６２９においてリセット確認結果をセキュリティモジュール（ＳＭ）に送信し、セキュリティモジュール（ＳＭ）はサービスプロバイダ（ＳＰ）にリセット確認結果通知を送信して処理が終了する。
【０４９４】
上述した処理によって、発行済みの実行ＡＣの破棄処理が、サービスプロバイダの確認の下に確実に実行されることになる。
【０４９５】
なお、登録鍵の破棄処理については、実行ＡＣに基づいて行なうことが可能である。図７３を参照して実行ＡＣに基づく登録鍵の破棄処理について説明する。登録鍵実行ＡＣは、例えば対応するサービス提供実行ＡＣを発行したサービスプロバイダ（ＳＰ）によって発行され、ユーザデバイスのエンドエンティテイ（ＥＥ）を介してセキュリティチップ（ＳＣ）に入力される。
【０４９６】
登録鍵破棄実行ＡＣ６２３は、図７３に示すように、破棄対象となる登録鍵を格納した共通鍵メモリ領域のメモリ領域ブロックアドレス情報（Ａｄ）、登録鍵で暗号化した登録鍵破棄コマンド（ＲｅｖＫ）、発行者署名を持つ実行ＡＣである。
【０４９７】
ステップＳ６５１において、登録鍵破棄実行ＡＣ６２３のメモリ領域ブロックアドレス情報（Ａｄ）に基づいて、共通鍵メモリ領域６０８から取得した登録鍵（Ｋｃｒ）に基づいて、登録鍵破棄実行ＡＣ６２３の実行命令を復号して、破棄コマンド（ＲｅｖＫ）を取得して、ステップＳ６５２においてコマンドに基づく破棄処理を実行する。ステップＳ６５３では、登録鍵破棄実行ＡＣ６２３のメモリ領域ブロックアドレス情報（Ａｄ）に基づいて、対応メモリ領域にリセット鍵（Ｋｒｅｓｅｔ）が上書きされ、登録鍵が破棄（リセット）される。
【０４９８】
（７）実行属性証明書の具体的利用処理
次に、上述した実行属性証明書（実行ＡＣ）を適用した具体的な利用処理について説明する。利用処理例として、以下の項目について各々説明する。
（７−１）回数制限付きサービス提供実行属性証明書
（７−２）譲渡機能付きサービス提供実行属性証明書
（７−３）代理発行実行属性証明書
以下、上記項目毎に説明する。
【０４９９】
（７−１）回数制限付きサービス提供実行属性証明書
まず、回数制限付きサービス提供実行属性証明書の適用処理について説明する。図７４、図７５に、回数制限付きサービス提供実行属性証明書をユーザデバイスにおいて適用してサービス、すなわち、回数制限付き暗号化データ、例えば画像、音楽、プログラム等のコンテンツを復号して利用する処理シーケンスを示す。各ステップに従って処理シーケンスについて説明する。
【０５００】
ユーザデバイスには、すでに回数制限付きサービス提供実行属性証明書がメモリ、例えば前述した実行ＡＣテーブルに格納されており、その残利用回数はｎ回であるものとする。回数制限付きサービス提供実行属性証明書の実行命令中に実行命令の適用可能回数識別値としての残利用回数データ（例えばｎ回）が記録される。記録例については後述する。
【０５０１】
ステップＳ７０１において、ユーザがエンドエンティテイ（ＥＥ）のユーザインタフェースを介してサービス提供実行ＡＣ、この例では、暗号化データ復号実行ＡＣの適用処理要求を入力する。この処理要求には、実行ＡＣの識別子、またはサービスプロバイダ（ＳＰ）情報、サービス内容を特定するデータ、例えば利用コンテンツ指定データが含まれる。エンドエンティテイ（ＥＥ）は、ステップＳ７０２において、ユーザ指定のサービス提供実行ＡＣ（暗号化データ復号実行ＡＣ）の検索要求を実行ＡＣテーブルに出力する。検索キーは、例えばコンテンツ情報やサービスプロバイダ（ＳＰ）情報等である。
【０５０２】
ステップＳ７０３において、実行ＡＣテーブルは、エンドエンティテイからの入力キーに基づいて、対応する暗号化データ復号実行ＡＣを検索し、ステップＳ７０４において、テーブルから抽出した暗号化データ復号実行ＡＣをエンドエンティテイ（ＥＥ）に出力する。この暗号化データ復号実行ＡＣには、残利用回数＝ｎ回の情報が記録されている。
【０５０３】
ステップＳ７０４において、エンドエンティテイ（ＥＥ）は、受領ＡＣをセキュリティチップ（ＳＣ）に出力し、サービス提供実行ＡＣ（暗号化データ復号実行ＡＣ）の適用処理要求を行なう。この適用処理は以下のように行なう。まず、ステップＳ７０５において、暗号化データ復号実行ＡＣの実行命令を登録鍵で復号して、復号鍵のセット処理を実行し、復号鍵セット完了通知をエンドエンティテイ（ＥＥ）に出力（Ｓ７０６）し、ＥＥにおいて、例えば外部メモリから復号対象の暗号化データを取得（Ｓ７０７）し、ＳＣに対して復号要求を行ない（Ｓ７０８）、ＳＣにおいてデータ復号処理を実行（Ｓ７０９）し、復号データをＳＣからＥＥに送信する（Ｓ７１０）データ復号処理を行ない、さらに、ステップＳ７１１において、暗号化データ復号実行ＡＣ中の実行命令中の残利用回数データをｎからｎ−１に更新する。
【０５０４】
さらに、更新後の残利用回数の判定（Ｓ７１２）の後、残利用回数≧１の場合は、図７５（ａ）に示すシーケンスに従い、登録鍵の再生成、保存（Ｓ７２１）、暗号化データ復号実行ＡＣの再生成（Ｓ７２２）、ＥＥへの送信、ＥＥからの暗号化データ復号実行ＡＣ保存要求（Ｓ７２３）に応じて、実行ＡＣテーブルへの保存（Ｓ７２４）が実行される。
【０５０５】
一方、残利用回数＝０の場合は、図７５（ｂ）に示すシーケンスに従い、ＳＣにおいて、登録鍵の破棄処理（Ｓ７２５）が実行され、ＥＥに対する登録鍵破棄通知（Ｓ７２６）の後、ＥＥからの暗号化データ復号実行ＡＣ削除要求（Ｓ７２７）に応じて、実行ＡＣテーブルの暗号化データ復号実行ＡＣ削除（Ｓ７２８）が実行される。
【０５０６】
ステップＳ７０５以下のセキュリティチップ（ＳＣ）における処理を図７６および図７７を参照して説明する。図７６は、更新後の残利用回数≧１の場合の処理であり、図７７は、更新後の残利用回数＝０の場合の処理である。
【０５０７】
まず、図７６を参照して、更新後の残利用回数≧１の場合のセキュリティチップ（ＳＣ）における処理について説明する。
【０５０８】
回数制限付きサービス提供実行属性証明書７０１は、実行命令（Ｅｃ（ＤｅｃＥＤａｔａ｜｜Ｋｃｄ｜｜ＮｕｍＴｒ（ｎ）；Ｋｃｒ１））と、実行命令を復号する登録鍵を格納した共通鍵メモリ領域におけるブロックアドレス（Ａｄ）と、発行者署名を有する。実行命令には、暗号化データ復号コマンド（ＤｅｃＥＤａｔａ）、データ復号鍵（Ｋｃｄ）、残利用回数（ｎ）に応じた回数処理実行コマンド（ＮｕｍＴｒ（ｎ））が含まれ、登録鍵（Ｋｃｒ１）によってこれらのデータが暗号化された実行命令（Ｅｃ（ＤｅｃＥＤａｔａ｜｜Ｋｃｄ｜｜ＮｕｍＴｒ（ｎ）；Ｋｃｒ１））である。
【０５０９】
まず、セキュリティチップ（ＳＣ）は、ステップＳ７３１において、実行ＡＣ中のブロックアドレス（Ａｄ）に基づいて共通鍵メモリ領域から取り出した登録鍵（Ｋｃｒ１）を適用して実行ＡＣ７０１の実行命令を復号し、データ（ＤｅｃＥＤａｔａ｜｜Ｋｃｄ｜｜ＮｕｍＴｒ（ｎ））を取り出して、さらに、ステップＳ７３２において、データ復号鍵（Ｋｃｄ）を適用して、外部から入力される暗号化コンテンツ等の暗号化データ７０２（Ｅｃ（Ｄａｔａ；Ｋｃｄ））の復号を実行して、復号コンテンツ（データ）７０３をエンドエンティテイに出力する。
【０５１０】
さらに、ステップＳ７３３において、回数処理実行コマンド（ＮｕｍＴｒ（ｎ））に基づく処理を実行する。この処理は、残回数を更新した新たな回数制限付きサービス提供実行属性証明書７０４を生成することを目的とする処理である。
【０５１１】
乱数発生処理（Ｓ７３４）により、新たな登録鍵Ｋｃｒ２を生成し、これを元の回数制限付きサービス提供実行属性証明書７０１に書き込まれていたプロックアドレスに対応する共通鍵メモリ領域６０８に書き込む。これにより、先に書き込まれていた登録鍵（Ｋｃｒ１）が新たな登録鍵（Ｋｃｒ２）に置き換えられることになる。
【０５１２】
ステップＳ７３６において、回数処理実行コマンド（ＮｕｍＴｒ（ｎ））に基づいて抽出される残利用回数＝ｎをコンテンツの復号処理に伴い（−１）する更新を実行する。すなわち、実行命令中のデータ（ＤｅｃＥＤａｔａ｜｜Ｋｃｄ｜｜ＮｕｍＴｒ（ｎ））を（ＤｅｃＥＤａｔａ｜｜Ｋｃｄ｜｜ＮｕｍＴｒ（ｎ−１））に書き替え、ステップＳ７３７において、新規生成登録鍵（Ｋｃｒ２）を適用した暗号化処理を実行する。この暗号化データは、新たな回数制限付きサービス提供実行属性証明書７０４中の実行命令（Ｅｃ（ＤｅｃＥＤａｔａ｜｜Ｋｃｄ｜｜ＮｕｍＴｒ（ｎ−１）；Ｋｃｒ２））に相当する。
【０５１３】
ステップＳ７３８では、ブロックアドレス（Ａｄ）と、ステップＳ７３７において生成した更新した残回数データを持つ実行命令に基づく電子署名をセキュリティチップの秘密鍵（ＫｓＳＣ）によって実行し、新たな更新した回数制限付きサービス提供実行属性証明書７０４を生成する。この場合の署名は、セキュリティチップにおいてなされることになる。
【０５１４】
この新たな回数制限付きサービス提供実行属性証明書７０４が、図７５のステップＳ７２２においてセキュリティチップ（ＳＣ）からエンドエンティテイ（ＥＥ）に出力後、ステップＳ７２４で実行ＡＣテーブルに保存される。
【０５１５】
一方、図７４の処理ステップＳ７１２の残利用回数審査において、残利用回数＝０と判定された場合のセキュリティチップ（ＳＣ）における処理を図７７を参照して説明する。
【０５１６】
回数制限付きサービス提供実行属性証明書７０５は、実行命令（Ｅｃ（ＤｅｃＥＤａｔａ｜｜Ｋｃｄ｜｜ＮｕｍＴｒ（１）；Ｋｃｒ１））と、実行命令を復号する登録鍵を格納した共通鍵メモリ領域におけるブロックアドレス（Ａｄ）と、発行者署名を有する。
【０５１７】
まず、セキュリティチップ（ＳＣ）は、ステップＳ７４１において、実行ＡＣ中のブロックアドレス（Ａｄ）に基づいて共通鍵メモリ領域から取り出した登録鍵（Ｋｃｒ１）を適用して実行ＡＣ７０５の実行命令を復号し、データ（ＤｅｃＥＤａｔａ｜｜Ｋｃｄ｜｜ＮｕｍＴｒ（ｎ））を取り出して、さらに、ステップＳ７４２において、データ復号鍵（Ｋｃｄ）を適用して、外部から入力される暗号化コンテンツ等の暗号化データ７０６Ｅｃ（Ｄａｔａ；Ｋｃｄ））の復号を実行して、復号コンテンツ（データ）７０７をエンドエンティテイに出力する。
【０５１８】
さらに、ステップＳ７４３において、回数処理実行コマンド（ＮｕｍＴｒ（１））に基づく処理を実行する。この処理は、さらなる実行ＡＣを利用したサービス利用、すなわち暗号化データの復号を停止するため、登録鍵の破棄を実行する処理として行われる。すなわち、ステップＳ７４４において登録鍵（Ｋｃｒ１）の破棄を実行する。登録鍵の破棄は、回数制限付きサービス提供実行属性証明書７０５に記録された登録鍵を格納した共通鍵メモリ領域中のブロックアドレス（Ａｄ）の対応領域にリセット鍵を上書きする処理として実行される。
【０５１９】
この処理により、回数制限付きサービス提供実行属性証明書７０５の格納された実行命令を復号する登録鍵（Ｋｃｒ１）が破棄され、実行命令を復号することが不可能になり、実行ＡＣを適用したサービス利用が停止される。この処理の後、図７５に示すステップＳ７２７，Ｓ７２８が実行されて、実行ＡＣテーブルから対応する実行ＡＣが削除される。
【０５２０】
（７−２）譲渡機能付きサービス提供実行属性証明書
次に、譲渡機能付きサービス提供実行属性証明書の適用処理について説明する。図７８に、譲渡機能付きサービス提供実行属性証明書の適用処理、すなわち、ユーザデバイス間で譲渡機能付きサービス提供実行属性証明書に基づく処理を実行して、新たな譲渡機能付きサービス提供実行属性証明書、あるいはサービス提供実行ＡＣを生成して他のユーザデバイス（譲渡先）に送付するとともに、自デバイス（譲渡元）の登録鍵を破棄する処理を行なうことで、他のユーザデバイスにおいて暗号化データ（例えば暗号化コンテンツ）を利用することを可能とした処理シーケンスを示す。
【０５２１】
図７８において、
ＥＥ１：譲渡元ユーザデバイスのエンドエンティテイ（ＥＥ）制御部、
ＳＣ１：譲渡元ＥＥ内に構成されるセキュリティチップ、
実行ＡＣテーブル１：譲渡元エンドエンティテイ（ＥＥ）実行ＡＣテーブル制御部、
ＥＥ２：譲渡先ユーザデバイスのエンドエンティテイ（ＥＥ）制御部、
ＳＣ２：譲渡先ＥＥ内に構成されるセキュリティチップ、
実行ＡＣテーブル２：譲渡先エンドエンティテイ（ＥＥ）実行ＡＣテーブル制御部、
である。
【０５２２】
まず、ステップＳ７５２において、譲渡先のユーザがエンドエンティテイ（ＥＥ２）の入力インタフェースを介して、譲渡機能付きサービス提供実行属性証明書に基づく譲渡処理、すなわち暗号化データの利用を譲渡先ユーザデバイスで実行可能とするための譲渡要求を入力する。譲渡要求には、譲渡機能付きサービス提供実行属性証明書のＩＤ、および所有者情報、あるいは利用コンテンツ（暗号化データ）、あるいはサービスプロバイダ情報等、適用する譲渡機能付きサービス提供実行属性証明書を特定するための情報が含まれる。
【０５２３】
エンドエンティテイ（ＥＥ２）がユーザからの譲渡要求の入力を受領すると、エンドエンティテイ（ＥＥ２）は、ステップＳ７５２において、譲渡機能付きサービス提供実行属性証明書を所有する譲渡元ユーザデバイスのエンドエンティテイ（ＥＥ１）に対する接続要求を行ない、各ユーザデバイスのセキュリティチップ（ＳＣ１）、（ＳＣ２）間において相互認証を実行する。これは例えば先に図１３を参照して説明した公開鍵方式の相互認証処理として実行される。
【０５２４】
相互認証が成立すると、ステップＳ７５３において、譲渡元のユーザデバイスのエンドエンティテイ（ＥＥ１）は、指定された譲渡機能付きサービス提供実行属性証明書の検索要求を実行ＡＣテーブル１に出力する。検索キーは、例えばコンテンツ情報やサービスプロバイダ（ＳＰ）情報等である。
【０５２５】
ステップＳ７５４において、実行ＡＣテーブル１は、エンドエンティテイ（ＥＥ１）からの入力キーに基づいて、対応する譲渡機能付きサービス提供実行属性証明書を検索し、テーブルから抽出した実行ＡＣをエンドエンティテイ（ＥＥ）に出力する。
【０５２６】
ステップＳ７５５において、エンドエンティテイ（ＥＥ）は、受領ＡＣをセキュリティチップ（ＳＣ）に出力し、譲渡機能付きサービス提供実行属性証明書の適用処理要求を行なう。セキュリティチップは、ステップＳ７５６において、受領ＡＣの処理、すなわち、実行属性証明書（譲渡機能付きサービス提供実行属性証明書）に格納されたアドレス（Ａｄ）によって指定された領域から取得される登録鍵に基づく実行命令の復号（Ｓ７５６）を行なう。
【０５２７】
さらに、ステップＳ７５７において、エンドエンティテイ（ＥＥ１）から譲渡処理要求がセキュリティチップ（ＳＣ）に出力し、エンドエンティテイ（ＥＥ１）はステップＳ７５８において、譲渡処理のために必要とするグループ属性証明書の提示を譲渡先のユーザデバイス（ＥＥ２）に対して要求する。このグループ属性証明書は、例えば、譲渡機能付きサービス提供実行属性証明書を生成発行したサービスプロバイダ（ＳＰ）によって管理された譲渡可能ユーザデバイスあるいはユーザのグループであることを証明するグループ属性証明書等である。
【０５２８】
譲渡先ユーザデバイスのエンドエンティテイ（ＥＥ２）は、ステップＳ７５９において、指定のグループ属性証明書（Ｇｐ．ＡＣ）を譲渡元ユーザデバイスのエンドエンティテイ（ＥＥ１）に送信し、エンドエンティテイ（ＥＥ１）は、受領ＡＣをセキュリティチップ（ＳＣ１）に転送し、セキュリティチップ（ＳＣ１）が、グループ属性証明書を検証する（Ｓ７６１）。この検証処理は、先に図２１〜図２３を参照して説明したと同様の処理であり、属性証明書の署名検証、対応および連鎖公開鍵証明書の検証等を含む処理である。
【０５２９】
検証不成立の場合は、エラー処理として、その後の処理を実行せず処理を中止する。この場合、エラー通知を譲渡先エンドエンティテイ（ＥＥ２）に送信する処理を行なってもよい。
【０５３０】
グループ属性証明書（Ｇｐ．ＡＣ）の検証が成功し、グループ属性証明書（Ｇｐ．ＡＣ）の正当性が確認されるとステップＳ７６２に進む。ステップＳ７６２では、譲渡先ユーザデバイスにおいて暗号化データの利用を可能とするための実行属性証明書の生成、送信が行なわれることになる。これらの処理は、先に図６０、図６１を参照して説明した登録鍵生成実行ＡＣの生成、検証、サービス提供実行ＡＣの生成送信に対応する処理であり、図６０、図６１におけるサービスプロバイダ（ＳＰ）の処理を譲渡元ユーザデバイスが実行するものである。
【０５３１】
ステップＳ７６２において、新たなサービス提供実行ＡＣ、この例では、サービス提供実行属性証明書が生成されて、譲渡先ユーザデバイスに送付される。さらに、ステップＳ７６３において、譲渡元ユーザデバイスが保有していた譲渡機能付きサービス提供実行属性証明書の実行命令を復号するために適用する登録鍵の削除が実行される。この処理は、前述したリセット鍵の上書きによって行なわれるものである。なおここでは、譲渡の機能について述べたが、登録鍵の削除を行わない実行属性証明書を用いれば、譲渡ではなく複製の機能を持たせることが出来る。
【０５３２】
譲渡元ユーザデバイスのセキュリティチップ（ＳＣ１）で実行するステップＳ７５６の譲渡機能付きサービス提供実行属性証明書の復号処理以下の処理の詳細について、図７９、図８０を参照して説明する。
【０５３３】
譲渡機能付きサービス提供実行属性証明書（ＡＣ）７１１には、実行命令、実行命令を復号するための登録鍵を格納した共通鍵メモリ領域６０８のブロックアドレス（Ａｄ１）、発行者署名の各データを有する。実行命令（Ｅｃ（Ｓｅｌ｜｜Ｊｄｇ（ＳＤＢ）｜｜ＧｅｎＡＣ（ＧｅｎＫｃｒ）｜｜ＧｅｎＡＣ（Ｅｘ）｜｜ＲｅｖＫ｜｜ＤｅｃＥＤａｔａ｜｜Ｋｃｄ；Ｋｃｒ１））には、処理選択コマンド（Ｓｅｌ）、検証審査コマンド（Ｊｄｇ（ＳＤＢ））、登録鍵生成実行ＡＣ作成コマンド（ＧｅｎＡＣ（ＧｅｎＫｃｒ）、実行ＡＣ作成コマンド（ＧｅｎＡＣ（Ｅｘ）、登録鍵破棄コマンド（ＲｅｖＫ）、暗号化データ復号コマンド（ＤｅｃＥＤａｔａ）、データ復号鍵（Ｋｃｄ）が含まれ、これらを登録鍵（Ｋｃｒ１）で暗号化したデータ構成である。
【０５３４】
なお、検証審査コマンド（Ｊｄｇ（ＳＤＢ））は、サービス情報データベース（ＳＤＢ）に基づく実行ＡＣの検証審査処理コマンドである。なお、サービス情報データベース（ＳＤＢ）は、サービス提供に必要となるＡＣ情報、および先に説明したグループ情報データベース（図１５参照）と同様のデータ構成を持ち、発行者、グループＩＤ、グループ情報の各データを有する。
【０５３５】
譲渡機能付きサービス提供実行属性証明書（ＡＣ）７１１を入力して、譲渡先に新たな譲渡機能付きサービス提供実行属性証明書を発行する処理を実行する譲渡元セキュリテイチップ（ＳＣ）は、まず、譲渡機能付きサービス提供実行属性証明書（ＡＣ）７１１のアドレス（Ａｄ１）に基づいて共通鍵メモリ領域６０８から登録鍵を取得し、譲渡機能付きサービス提供実行属性証明書（ＡＣ）７１１内の実行命令を復号する。次に、譲渡実行トリガ７１２をエンドエンティテイから入力すると、ステップＳ７７２以下の譲渡実行処理を行なう。
【０５３６】
ここで、譲渡実行トリガ７１２は、譲渡機能付きサービス提供実行属性証明書（ＡＣ）７１１に基づく、譲渡処理を実行することのエンドエンティテイからの要求処理を示す。譲渡機能付きサービス提供実行属性証明書（ＡＣ）７１１は、譲渡処理のみならず、暗号化データの復号処理の際にも適用される実行ＡＣであり、そのいずれの処理を実行するかをエンドエンティテイからの要求（トリガ）によって選択する。譲渡機能付きサービス提供実行属性証明書（ＡＣ）７１１の実行命令（Ｅｃ（Ｓｅｌ｜｜Ｊｄｇ（ＳＤＢ）｜｜ＧｅｎＡＣ（ＧｅｎＫｃｒ）｜｜ＧｅｎＡＣ（Ｅｘ）｜｜ＲｅｖＫ｜｜ＤｅｃＥＤａｔａ｜｜Ｋｃｄ；Ｋｃｒ１））から選択処理によって、譲渡実行処理に対応する実行命令（Ｊｄｇ（ＳＤＢ）｜｜ＧｅｎＡＣ（ＧｅｎＫｃｒ）｜｜ＧｅｎＡＣ（Ｅｘ）｜｜ＲｅｖＫ）が取得され、ステップＳ７７２以下の処理を実行命令に従って実行する。
【０５３７】
ステップＳ７７２では、検証審査コマンド（Ｊｄｇ（ＳＤＢ））に従って、譲渡先から取得したグループ属性証明書（Ｇｐ．ＡＣ）７１３の検証、審査を行なう。この検証処理は、先に図２１〜図２３を参照して説明したと同様の処理であり、属性証明書の署名検証、対応および連鎖公開鍵証明書の検証等を含む処理である。検証不成立の場合は、エラー処理として、その後の処理を実行せず処理を中止する。グループ属性証明書（Ｇｐ．ＡＣ）の検証が成功し、グループ属性証明書（Ｇｐ．ＡＣ）の正当性が確認されるとステップＳ７７３に進む。
【０５３８】
ステップＳ７７３以下では、譲渡先ユーザデバイスにおいて暗号化データの利用を可能とするための実行属性証明書の生成、送信が行なわれることになる。これらの処理は、先に図６０、図６１、図６３〜図６５を参照して説明した登録鍵生成実行ＡＣの生成、検証、サービス提供実行ＡＣの生成送信に対応する処理であり、図６０、図６１におけるサービスプロバイダ（ＳＰ）の処理を譲渡元ユーザデバイスが実行するものである。
【０５３９】
これらの処理に必要なリセット鍵（Ｋｒｅｓｅｔ）、譲渡先の共通鍵メモリの登録鍵格納領域のプロックアドレス（Ａｄ２）、譲渡先のセキュリティチップの公開鍵（ＫｐＳＣ２）等のデータ７１４は、譲渡先のユーザデバイス等から取得する。これらの必要データに基づいて、まず、ステップＳ７７３において、実行命令中の登録鍵生成実行ＡＣ作成コマンド（ＧｅｎＡＣ（ＧｅｎＫｃｒ）に従って、登録鍵生成実行ＡＣ７１５の生成処理がなされる。この処理は、先に図６３を参照して説明した登録鍵生成実行ＡＣの生成処理と同様である。
【０５４０】
次に、譲渡元ユーザデバイスのセキュリティチップから、登録鍵生成実行ＡＣを受信した譲渡先ユーザデバイスのセキュリティチップは、実行命令中の実行ＡＣ作成コマンド（ＧｅｎＡＣ（Ｅｘ）に従い、先に図６４を参照して説明した処理に従って、登録鍵生成実行結果（図８０，７２１）を生成して譲渡元ユーザデバイスのセキュリティチップに送信する。
【０５４１】
譲渡先ユーザデバイスのセキュリティチップから、登録鍵生成実行結果（図８０，７２１）を受信した譲渡元ユーザデバイスのセキュリティチップは、図８０に従った処理を行なって、新たな譲渡機能付きサービス提供実行属性証明書（ＡＣ）７２２を生成して譲渡先ユーザデバイスに送信するとともに、自己の共通鍵メモリ領域中の登録鍵を破棄する処理を実行する。
【０５４２】
図８０のステップＳ７８１において、セッション鍵（Ｋｃｓ）を適用して、登録鍵生成結果の復号処理を実行し、登録鍵（Ｋｃｒ２）とメモリ領域ブロックアドレス（Ａｄ２）を取得する。さらに、ステップＳ７８２において、新たな譲渡機能付きサービス提供実行属性証明書（ＡＣ）７２２に格納する実行命令（Ｅｃ（Ｓｅｌ｜｜Ｊｄｇ（ＳＤＢ）｜｜ＧｅｎＡＣ（ＧｅｎＫｃｒ）｜｜ＧｅｎＡＣ（Ｅｘ）｜｜ＲｅｖＫ｜｜ＤｅｃＥＤａｔａ｜｜Ｋｃｄ；Ｋｃｒ２））を、譲渡先ユーザデバイスの登録鍵（Ｋｃｒ２）を適用して暗号化する。なお、実行命令は、サービス提供実行ＡＣとしての新たな譲渡機能付きサービス提供実行属性証明書（ＡＣ）７２２に設定される実行プログラム等の実行命令である。
【０５４３】
さらに、ステップＳ７８３において、実行命令を登録鍵（Ｋｃｒ２）で暗号化したデータと、登録鍵（Ｋｃｒ２）を格納する譲渡先ユーザデバイスにおけるセキュリティチップのメモリ領域ブロックアドレス（Ａｄ２）とのデータに対して、譲渡元のセキュリティチップ（ＳＣ１）の秘密鍵（ＫｓＳＣ１）によって署名（図１７参照）が生成され、新たな譲渡機能付きサービス提供実行属性証明書（ＡＣ）７２２が生成されて、譲渡先ユーザデバイスに送信される。
【０５４４】
さらに、ステップＳ７８４では、元の譲渡機能付きサービス提供実行属性証明書（ＡＣ）７１１に格納されたアドレス（Ａｄ１）、すなわち、譲渡元のユーザデバイスの共通鍵メモリ領域の登録鍵格納アドレスに対するリセット鍵の書き込みが実行されて、登録鍵の破棄処理が実行される。
【０５４５】
なお、上記説明では、譲渡元から譲渡先に対して新たな譲渡機能付きサービス提供実行属性証明書（ＡＣ）７２２を生成して送付する構成例を示したが、新たな譲渡機能付きサービス提供実行属性証明書（ＡＣ）７２２ではなく、通常の、すなわち譲渡機能を持たないサービス提供実行属性証明書（ＡＣ）を生成して送付する構成としてもよい。
【０５４６】
譲渡機能付きサービス提供実行属性証明書（ＡＣ）は、先に説明したように、譲渡処理のみならず、暗号化データの復号処理の際にも適用される実行ＡＣである。そのいずれの処理を実行するかをエンドエンティテイからの要求（トリガ）によって選択する。トリガが暗号化データの復号処理の要求である場合のセキュリティチップにおける処理を図８１を参照して説明する。
【０５４７】
譲渡機能付きサービス提供実行属性証明書（ＡＣ）７３１には、実行命令、実行命令を復号するための登録鍵を格納した共通鍵メモリ領域６０８のブロックアドレス（Ａｄ１）、発行者署名の各データを有する。
【０５４８】
譲渡機能付きサービス提供実行属性証明書（ＡＣ）７３１を入力したセキュリテイチップ（ＳＣ）は、まず、譲渡機能付きサービス提供実行属性証明書（ＡＣ）７３１のアドレス（Ａｄ１）に基づいて共通鍵メモリ領域６０８から登録鍵を取得し、譲渡機能付きサービス提供実行属性証明書（ＡＣ）７３１内の実行命令を復号する。次に、暗号化データ復号トリガ７３２をエンドエンティテイから入力すると、ステップＳ７８６において、トリガに基づく選択処理、すなわち、データ復号実行の選択を行ない、ステップＳ７８７において、復号処理を実行する。
【０５４９】
すなわち、譲渡機能付きサービス提供実行属性証明書（ＡＣ）７３１の実行命令（Ｅｃ（Ｓｅｌ｜｜Ｊｄｇ（ＳＤＢ）｜｜ＧｅｎＡＣ（ＧｅｎＫｃｒ）｜｜ＧｅｎＡＣ（Ｅｘ）｜｜ＲｅｖＫ｜｜ＤｅｃＥＤａｔａ｜｜Ｋｃｄ；Ｋｃｒ１））から選択処理によって、データ復号処理に対応する実行命令（ＤｅｃＥＤａｔａ｜｜Ｋｃｄ）が取得され、ステップＳ７８７において、データ復号鍵（Ｋｃｄ）を適用して、外部から入力される復号対象の暗号化データ（Ｅｃ（Ｄａｔａ；Ｋｃｄ））７３３の復号処理を実行し、復号されたデータ７３４を出力する。復号対象の暗号化データ（Ｅｃ（Ｄａｔａ；Ｋｃｄ））７３３は、例えば画像、音楽、プログラム等のコンテンツを、鍵（Ｋｃｄ）により暗号化したデータであり、譲渡機能付きサービス提供実行属性証明書（ＡＣ）７３１内の格納実行命令を登録鍵（Ｋｃｒ１）によって復号することによって取得可能なデータ復号鍵（Ｋｃｄ）によって復号可能となる。
【０５５０】
譲渡機能と回数制限を組み合わせた適用例も考えられる。例えば、譲渡される実行ＡＣは、譲渡を行う実行ＡＣの回数情報が一つ減ったものとなるように設定すれば、移動回数を制限できる。また、複製機能と回数制限を組み合わせた適用例も考えられる。例えば、複製を行うたびに実行属性証明書の回数情報が一つ減ったものとなるように設定すれば、複製回数を制限できる。ここで、複製というのは、複製機能を持たないサービス提供実行属性証明書に対して行う。さらに、一旦複製したサービス提供実行属性証明書を破棄する代わりに、回数情報を一つ増える機能を持たせれば、チェックイン・チェックアウト機能が実現できる。
【０５５１】
チェックイン・チェックアウトについて簡単に説明する。サービス利用権限を他の機器に転送することをチェックアウトといい、さらにチェックアウトした機器から元の機器に転送することをチェックインという。サービス利用権限がチェックアウトした機器から元の機器以外に転送することの出来ない時、チェックイン・チェックアウト機能を持つという。
【０５５２】
（７−３）代理発行実行属性証明書
次に代理発行実行属性証明書について説明する。（６−３）実行属性証明書適用処理では、コンテンツを暗号化したデータの復号サービスについて述べたが、サービスプロバイダしか知らない暗号鍵を実行属性証明書に書き込み、その暗号鍵を使って署名付けした証明書を発行するサービスも実行属性証明書を用いて行うことが出来る。このサービス提供実行属性証明書が代理発行実行属性証明書である。
【０５５３】
この暗号鍵として、共通鍵を用いる方法と秘密鍵を用いる方法がある。以下では、秘密鍵を用いる場合について述べる。代理発行実行属性証明書を用いて発行する証明書を検証するには、検証者は、上記秘密鍵に対応した公開鍵を知る必要がある。そのため、代理発行実行属性証明書発行者は、上記公開鍵の証明書を発行し、代理発行実行属性証明書を用いて発行する証明書所有者は、検証者に、上記公開鍵証明書を提示する。この公開鍵証明書を代理署名鍵証明書と呼ぶ。この代理発行実行属性証明書として、以下の項目について各々説明する。
（７−３−１）審査代行実行属性証明書
（７−３−２）代理署名実行属性証明書
以下、上記項目ごとに説明する。
【０５５４】
（７−３−１）審査代行実行属性証明書
まず、審査代行実行属性証明書について説明する。属性証明書登録局が、直接情報をやり取りするのが難しいエンドエンティティに属性証明書を発行する際、発行ポリシーを規定した状態で、予め属性証明書登録局が直接情報をやり取りすることの出来る別のエンドエンティティに、発行の審査を代行させることを可能とさせるのが、審査代行実行属性証明書である。
【０５５５】
図８２を参照して審査代行実行属性証明書の概要を説明する。図８２（ａ）は、通常の属性証明書の発行形態を示し、属性証明書（ＡＣ）の利用者である属性保持者から例えば属性認証局（ＡＡ）、属性証明書登録局（ＡＲＡ）あるいはサービスプロバイダ（ＳＰ）等の発行者に対して属性証明書、ここではグループ属性証明書（Ｇｐ．ＡＣ）の発行要求（Ｓ８０１）を行なう。例えばこの場合、ＡＣ利用者の属性を証明するデータの提出が必要となる。前述した実施例では、例えばクレジットカード会社がすでにＡＣ利用者に対して発行済みのグループ属性証明書の提示をする例を説明した。
【０５５６】
発行者は、ＡＣ利用者の属性等のユーザ確認としての審査を実行（Ｓ８０２）して、審査成立と判定すると、ＡＣ利用者の属性を証明する属性証明書（ここではＧｐ．ＡＣ）８０１を利用者に発行（Ｓ８０３）する。
【０５５７】
（ｂ）に示す例は、以下において詳細に説明する審査代行実行属性証明書を適用したグループ属性証明書（Ｇｐ．ＡＣ）発行シーケンスである。
【０５５８】
まず、ＡＣ利用者に対してグループ属性証明書を代理発行する審査代行者が、本来の発行者、例えば属性認証局（ＡＡ）、属性証明書登録局（ＡＲＡ）あるいはサービスプロバイダ（ＳＰ）に対して、審査代行実行属性証明書の発行要求（Ｓ８１１）を行ない、真の発行者である属性認証局（ＡＡ）、属性証明書登録局（ＡＲＡ）あるいはサービスプロバイダ（ＳＰ）等が、審査代行者の審査（Ｓ８１２）を行なう。これは、従来と同様、審査代行者の属性等を証明するデータ、あるいは既発行の属性証明書の提示等に基づいて実行する。審査成立後、発行者は、代理署名鍵証明書８０４と、審査代行実行属性証明書８０３を審査代行者に付与（Ｓ８１３）する。
【０５５９】
代理署名鍵証明書８０４は、代理署名生成、検証の際に用いる公開鍵（Ｋｐａ）と、発行者署名データを有する。また、審査代行実行属性証明書８０３は、前述の実行証明書と同様、審査代行者のユーザデバイスの共通鍵メモリの登録鍵（Ｋｃｒ）の格納領域を示すブロックアドレス（Ａｄ）、登録鍵（Ｋｃｒ）で暗号化された実行命令（Ｅｃ（代行審査命令｜｜属性情報｜｜Ｋｓａ；Ｋｃｒ））、発行者署名からなる。
【０５６０】
実行命令に含まれる秘密鍵（Ｋｓａ）は、代理署名生成、検証の際に用いる秘密鍵であり、前述の公開鍵（Ｋｐａ）に対応する秘密鍵である。
【０５６１】
ステップＳ８１１〜Ｓ８１３は、代行委託フェーズであり、この代行委託フェーズの完了の後、代行実行フェーズが開始される。ＡＣ利用者（属性保持者）から、属性証明書（Ｇｐ．ＡＣ）の発行要求が審査代行者になされる（Ｓ８１４）。ここでは、審査代行者の発行するグループ属性証明書を審査代行グループ属性証明書と呼ぶ。
【０５６２】
審査代行グループ属性証明書の発行要求を受領した審査代行者は、利用者の審査（Ｓ８１５）を行なう。ここでの審査は、審査代行者とＡＣ利用者との信頼関係に基づいて実行することも可能であり、審査代行者の属性等を証明するデータ、あるいは既発行の属性証明書の提示等を必ずしも必要としない。例えば審査代行者をある家族の１人とし、利用者をその家族とする設定であれば、審査代行者が家族であることを認定すれば、審査成立とする等、審査代行者とＡＣ利用者との信頼関係に基づいて任意の審査を行なうことが可能である。
【０５６３】
審査成立の後、審査代行者は、審査代行グループ属性証明書８０２を生成する。審査代行グループ属性証明書８０２は、ＡＣ利用者（属性保持者）のセキュリティチップに対して発行された公開鍵証明書（ＰＫＣ）シリアル番号、属性情報等、先に図５を参照して説明した各情報を持つ。さらに、先に、審査代行者が発行者から受領した審査代行実行属性証明書８０２の実行命令中に格納された秘密鍵（Ｋｓａ）を適用した署名が付加される。
【０５６４】
審査代行者は、生成した審査代行グループ属性証明書８０２と、代理署名鍵証明書８０４を併せてＡＣ利用者に送付（Ｓ８１６）する。ＡＣ利用者は、審査代行グループ属性証明書８０２を、例えばサービスプロバイダ（ＳＰ）に提示して属性を証明してサービスを受領する。
【０５６５】
サービス提供も含めた各エンティテイ間でのデータの流れを図８３を参照して説明する。まず、代行委託フェーズにおいて、発行者８１１から審査代行実行ＡＣ８２２、代理署名鍵証明書８２１が審査代行者８１２に送付される。次に、代行実行フェーズにおいて、審査代行グループ属性証明書８２３と、代理署名鍵証明書８２１がＡＣ利用者（属性所有者）８１３に送付される。さらに、サービスプロバイダ（ＳＰ）等の検証者８１４に対して、審査代行グループ属性証明書８２３と、代理署名鍵証明書８２１がＡＣ利用者（属性所有者）８１３から送付され、検証者８１４が、審査代行グループ属性証明書８２３と、代理署名鍵証明書８２１に基づくＡＣ利用者の属性検証を実行し、検証成立を条件としてサービスを提供する。
【０５６６】
サービスプロバイダ（ＳＰ）等の検証者８１４は、代理署名鍵証明書８２１の署名検証の後、代理署名鍵証明書８２１に格納された代理署名検証用の公開鍵（Ｋｐａ）を取り出して、取り出した公開鍵（Ｋｐａ）を適用して、審査代行グループ属性証明書８２３の署名検証を実行することができる。
【０５６７】
次に、発行者から審査代行実行ＡＣ８２２、代理署名鍵証明書８２１を受領した審査代行者がＡＣ利用者の要求に基づいて、審査代行グループ属性証明書８２３を生成、発行する処理について、図８４を参照して説明する。図８４において、
ＥＥ１：属性証明書利用ユーザデバイスのエンドエンティテイ（ＥＥ）制御部、
ＳＣ１：ＥＥ１内に構成されるセキュリティチップ、
ＥＥ２：審査代行者ユーザデバイスのエンドエンティテイ（ＥＥ）制御部、
ＳＣ２：ＥＥ２内に構成されるセキュリティチップ、
実行ＡＣテーブル：ＥＥ２の実行ＡＣテーブル制御部、
である。
【０５６８】
なお、審査代行者は、ユーザデバイスに限らず、例えばサービスプロバイダ（ＳＰ）が実行する構成も可能である。ここでは一例としてユーザデバイスが審査代行者として機能する例を説明する。
【０５６９】
まず、ステップＳ８２１において、ＡＣ利用者（属性所有者）としてのユーザがエンドエンティテイ（ＥＥ１）の入力インタフェースを介して、審査代行グループ属性証明書（Ｇｐ．ＡＣ）の発行要求を入力する。要求には、審査代行者の指定データ、および利用予定のコンテンツあるいはサービスプロバイダ情報等、審査代行グループ属性証明書（Ｇｐ．ＡＣ）の生成に必要となる情報を含む。
【０５７０】
エンドエンティテイ（ＥＥ１）がユーザからの審査代行グループ属性証明書（Ｇｐ．ＡＣ）の発行要求を受領すると、エンドエンティテイ（ＥＥ１）は、ステップＳ８２２において、審査代行者のユーザデバイスのエンドエンティテイ（ＥＥ２）に対する接続要求を行ない、各ユーザデバイスのセキュリティチップ（ＳＣ１）、（ＳＣ２）間において相互認証を実行する。これは例えば先に図１３を参照して説明した公開鍵方式の相互認証処理として実行される。
【０５７１】
相互認証が成立すると、ステップＳ８２３において、審査代行者ユーザデバイスのエンドエンティテイ（ＥＥ２）は、審査代行実行ＡＣの検索要求を実行ＡＣテーブルに出力する。検索キーは、例えばコンテンツ情報やサービスプロバイダ（ＳＰ）情報等である。
【０５７２】
ステップＳ８２４において、実行ＡＣテーブルは、エンドエンティテイ（ＥＥ２）からの入力キーに基づいて、対応する審査代行実行ＡＣを検索し、テーブルから抽出した実行ＡＣとそのＡＣに付帯して発行者から発行された代理署名鍵証明書（図８２，８０４参照）をエンドエンティテイ（ＥＥ２）に出力する。
【０５７３】
ステップＳ８２５において、エンドエンティテイ（ＥＥ２）は、受領ＡＣをセキュリティチップ（ＳＣ２）に出力し、実行属性証明書の適用処理要求を行なう。セキュリティチップ（ＳＣ２）は、ステップＳ８２６において、受領ＡＣの処理、すなわち、実行属性証明書（審査代行実行ＡＣ）に格納されたアドレス（Ａｄ）によって指定された領域から取得される登録鍵に基づく実行命令の復号を行なう。
【０５７４】
さらに、ステップＳ８２７において、ＡＣ利用者の審査のためのグループ属性証明書がＡＣ利用者のエンドエンティテイ（ＥＥ１）から審査代行者のエンドエンティテイ（ＥＥ２）に入力され、審査代行者のセキュリティチップ（ＳＣ２）において検証処理が実行される。
【０５７５】
前述したように、審査代行者は、ＡＣ利用者の審査を審査代行者とＡＣ利用者との信頼関係に基づいて実行可能であり、審査代行者の属性等を証明するデータ、あるいは既発行の属性証明書の提示等を必ずしも必要としないが、ここでは、既発行のグループ属性証明書の提示、検証を条件として審査代行グループ属性証明書を発行する例を示している。
【０５７６】
セキュリティチップ（ＳＣ２）によるグループ属性証明書の検証は、先に図２１〜図２３を参照して説明したと同様の処理であり、属性証明書の署名検証、対応および連鎖公開鍵証明書の検証等を含む処理である。検証不成立の場合は、エラー処理として、その後の処理を実行せず処理を中止する。この場合、エラー通知をＡＣ利用者エンドエンティテイ（ＥＥ１）に送信する処理を行なってもよい。
【０５７７】
グループ属性証明書（Ｇｐ．ＡＣ）の検証が成功し、グループ属性証明書（Ｇｐ．ＡＣ）の正当性が確認されるとステップＳ８３０において、審査代行グループ属性証明書の生成に必要とする追加情報（Ａｄｄｉｎｆｏ）をエンドエンティテイ（ＥＥ２）からセキュリティチップ（ＳＣ２）に入力し、セキュリティチップ（ＳＣ２）は審査代行グループ属性証明書を生成し、エンドエンティテイ（ＥＥ２）に送付の後、エンドエンティテイ（ＥＥ２）からＡＣ利用者のエンドエンティテイ（ＥＥ１）に送付（Ｓ８３２）される。この送付処理に際しては、生成した審査代行グループ属性証明書に代理署名鍵証明書を付加して送付する。
【０５７８】
審査代行者のセキュリティチップ（ＳＣ２）で実行する処理、すなわち審査代行実行属性証明書を入力して審査代行グループ属性証明書を生成する処理の詳細を図８５を参照して説明する。審査代行実行属性証明書（ＡＣ）８５１には、実行命令、実行命令を復号するための登録鍵（Ｋｃｒ）を格納した審査代行者セキュリティチップ（ＳＣ）８６１の共通鍵メモリ領域８６４のブロックアドレス（Ａｄ）、発行者署名の各データを有する。実行命令（Ｅｃ（Ｊｄｇ（ＳＤＢ）｜｜ＧｅｎＡＣ（Ｇｐ）｜｜ａｔｔ｜｜Ｋｓａ；Ｋｃｒ））には、検証審査コマンド（Ｊｄｇ（ＳＤＢ））、グループ属性証明書作成コマンド（ＧｅｎＡＣ（Ｇｐ）、属性情報（ａｔｔ）、代理署名用秘密鍵（Ｋｓａ）が含まれ、これらを登録鍵（Ｋｃｒ）で暗号化したデータ構成である。
【０５７９】
審査代行実行属性証明書（ＡＣ）８５１を入力すると、まず、審査代行実行属性証明書（ＡＣ）８５１のアドレス（Ａｄ）に基づいて共通鍵メモリ領域８６４から登録鍵を取得し、審査代行実行属性証明書（ＡＣ）８５１内の実行命令を復号する。次に、ステップＳ８４２において、検証審査コマンド（Ｊｄｇ（ＳＤＢ））に基づいて、ＡＣ利用者からエンドエンティテイを介して入力するグループ属性証明書の検証を実行する。この検証処理は、先に図２１〜図２３を参照して説明したと同様の処理であり、属性証明書の署名検証、対応および連鎖公開鍵証明書の検証等を含む処理である。検証不成立の場合は、エラー処理として、その後の処理を実行せず処理を中止する。グループ属性証明書（Ｇｐ．ＡＣ）の検証が成功し、グループ属性証明書（Ｇｐ．ＡＣ）の正当性が確認されるとステップＳ８４３に進む。
【０５８０】
ステップＳ８４３では、審査代行実行ＡＣ８５１内の実行命令中のグループ属性証明書作成コマンド（ＧｅｎＡＣ（Ｇｐ））に基づいて、審査代行グループ属性証明書の生成、送信が行なわれることになる。これらの処理は、先に図６０、図６１、図６３〜図６５を参照して説明した登録鍵生成実行ＡＣの生成、検証、サービス提供実行ＡＣの生成送信に対応する処理であり、図６３〜図６５におけるサービスプロバイダ（ＳＰ）のセキュリテイモジュールにおける処理と同様である。なお、例えば審査代行属性証明書であることを示す追加情報（ａｄｄｉｎｆｏ）８５３を審査代行属性証明書に付加して、通常の属性証明書と異なることを示すものとすることが好ましい。
【０５８１】
ステップＳ８４４では、審査代行実行属性証明書（ＡＣ）８５１の実行命令中から取得した代理署名用の秘密鍵（Ｋｓａ）を適用して、追加情報（ａｄｄｉｎｆｏ）および属性情報（ａｔｔ）に対する署名を行ない、審査代行グループ属性証明書８５４を生成し、エンドエンティテイ（ＥＥ２）を介してＡＣ利用者（属性所有者）に送信する。なお、ＡＣ利用者には、生成した審査代行グループ属性証明書に代理署名鍵証明書を付加して送付する。
【０５８２】
ＡＣ利用者は、上述の処理によって発行された審査代行グループ属性証明書と、代理署名鍵証明書を、サービスプロバイダ等の検証者に提示して、属性検証を条件としたサービスを受領することになる。サービスプロバイダ等の検証者は、代理署名鍵証明書から取得可能な鍵を適用して審査代行グループ属性証明書の署名検証が可能となる。
【０５８３】
上述した審査代行グループ属性証明書の適用例としては、例えばアカウント数を制限した審査代行グループ属性証明書の発行例がある。サービスプロバイダ（ＳＰ）がＡさんの家族全員にサービスを提供する時に、Ａさんの家族であるかどうかＡ家の家族であることを証明するグループ属性証明書（Ｇｐ．ＡＣ）を用いて審査するとする。
【０５８４】
このとき、Ａ家の家族であることを証明するグループ属性証明書（Ｇｐ．ＡＣ）として、役所など住民の基本情報を持った第三者機関が発行した属性証明書（ＡＣ）を用いることができれば、信頼性の高い属性審査が可能となるが、このような属性証明書が利用可能な状態にあるとは限らない。一方、Ａさん自身にＡ家の家族であることを証明するグループ属性証明書（ＧｐＡＣ）を発行させることはＡさんの意思に応じて可能となる。しかし、属性証明書の真の発行主体である属性認証局（ＡＡ）としてＡさん等の個人を信頼できると判定することは難しい。
【０５８５】
そこで、上述した審査代行実行ＡＣを適用した審査代行グループ属性証明書を発行する。この場合、Ａさんの家族の代表者としてのＡさんが審査代行者として、審査代行実行ＡＣを適用した審査代行グループ属性証明書の発行を行なう。この時の審査代行グループ属性証明書の発行審査は、審査代行者（Ａさん）とＡＣ利用者（Ａさんの家族）との信頼関係に基づいて実行することが可能であり、審査代行者の属性等を証明するデータ、あるいは既発行の属性証明書の提示等を必ずしも必要としない。審査代行者が家族であることを認定すれば、審査成立とする等、審査代行者とＡＣ利用者との信頼関係に基づいて審査代行グループ属性証明書を発行することが可能である。
【０５８６】
ただし、Ａさんは、本当は家族でない友人のＢさんにもＡさんの家族であることを属性として示す審査代行グループ属性証明書を発行してしまうかもしれない。このような可能性を抑えるため、審査代行グループ属性証明書の発行枚数に制限、例えば上限＝５とした設定をするなど、発行処理における制限を付帯することで、極端な不正利用の発生を防止することが可能である。
【０５８７】
上述の審査代行グループ属性証明書の発行処理態様は、Ａさんの所有機器をグループとして設定したグループ属性証明書においても同様に処理可能であり、審査代行実行ＡＣを適用した審査代行グループ属性証明書としてＡさんが審査代行者として審査代行実行ＡＣに基づいて審査代行グループ属性証明書をＡさんの所有機器各々に発行することが可能となる。
【０５８８】
さらに、審査代行グループ属性証明書を適用した処理例として、選挙における投票に適用する例がある。審査代行グループ属性証明書を利用することで、有権者が、投票する候補者以外、選挙管理委員にすら誰に投票したかわからないようにして選挙を行うことができる。
【０５８９】
この処理例では、
審査代行者：有権者
ＡＣ利用者（属性所持者）：候補者
とする。この選挙システムは、投票時に有権者は選挙管理委員と通信する代わりに候補者と通信すればよいというモデルであり、現実の選挙とは異なる。まず、サービスプロバイダ（ＳＰ）は、有権者に審査代行実行ＡＣを発行する。有権者は、投票予定の候補者から、ユニークな識別値、すなわち他の投票とかぶらない識別値を教えてもらい、その数と投票予定の候補者のＰＫＣシリアルＮｏ．を属性として持つ審査代行グループ属性証明書（Ｇｐ．ＡＣ）を審査代行実行ＡＣに基づいて、発行して候補者に送付する。審査代行実行ＡＣは、この審査代行グループ属性証明書（Ｇｐ．ＡＣ）の生成後、自動的に破棄される。
【０５９０】
各候補者に対して発行された審査代行グループ属性証明書（Ｇｐ．ＡＣ）数に基づいて、得票数がカウントされ、当落を決定する。同じ識別値の書かれた審査代行グループ属性証明書は、コピーしたとみなされ一票にしかならない。
【０５９１】
（７−３−２）代理署名実行属性証明書
次に、代理署名実行属性証明書について説明する。代理署名実行ＡＣはＡＣ利用者（属性保持者）自身が、自らサービスに適用するためのグループ属性証明書（代理署名グループ属性証明書）を発行することを可能とした実行属性証明書である。
【０５９２】
図８６を参照して代理署名実行属性証明書の概要を説明する。図８６（ａ）は、通常の属性証明書の発行、適用処理形態を示す。属性証明書（ＡＣ）の利用者である属性保持者から例えば属性認証局（ＡＡ）、属性証明書登録局（ＡＲＡ）あるいはサービスプロバイダ（ＳＰ）等の発行者に対して属性証明書、ここではグループ属性証明書（Ｇｐ．ＡＣ）の発行要求（Ｓ９０１）を行なう。例えばこの場合、ＡＣ利用者の属性を証明するデータの提出が必要となる。前述した実施例では、例えばクレジットカード会社がすでにＡＣ利用者に対して発行済みのグループ属性証明書の提示をする例を説明した。
【０５９３】
発行者は、ＡＣ利用者の属性等のユーザ確認としての審査を実行（Ｓ９０２）して、審査成立と判定すると、ＡＣ利用者の属性を証明する属性証明書（ここではＧｐ．ＡＣ）９２１を利用者に発行（Ｓ９０３）する。
【０５９４】
ＡＣ利用者（属性保持者）は、発行されたグループ属性証明書（Ｇｐ．ＡＣ）をサービスプロバイダ（ＳＰ）等の検証者に提示してサービスの適用を受けることが可能であり、検証者からのグループ属性証明書（Ｇｐ．ＡＣ）提示要求（Ｓ９０４）に応じて、ＡＣ利用者（属性保持者）が提示（Ｓ９０５）を行ない、検証者がグループ属性証明書（Ｇｐ．ＡＣ）の検証（Ｓ９０６）を実行する。
【０５９５】
（ｂ）に示す例は、以下において詳細に説明する代理署名実行属性証明書を適用したグループ属性証明書（Ｇｐ．ＡＣ）発行、適用処理シーケンスである。
【０５９６】
まず、ＡＣ利用者（属性保持者）は、例えば属性認証局（ＡＡ）、属性証明書登録局（ＡＲＡ）あるいはサービスプロバイダ（ＳＰ）等の発行者に対して代理署名実行属性証明書（ＡＣ）の発行要求（Ｓ９１１）を行なう。発行者は、ＡＣ利用者の属性を証明するデータ、例えば発行済みのグループ属性証明書等に基づいて審査（Ｓ９１２）を実行し、審査成立と判定すると、代理署名実行属性証明書９２３を発行する。発行者は、この際、代理署名鍵証明書９２４も併せてＡＣ利用者（属性保持者）に提供する。
【０５９７】
代理署名鍵証明書９２４は、代理署名生成、検証の際に用いる公開鍵（Ｋｐａ）と、発行者署名データを有する。また、代理署名実行属性証明書９２３は、前述の実行証明書と同様、審査代行者のユーザデバイスの共通鍵メモリの登録鍵（Ｋｃｒ）の格納領域を示すブロックアドレス（Ａｄ）、登録鍵（Ｋｃｒ）で暗号化された実行命令（Ｅｃ（代理署名命令｜｜属性情報｜｜Ｋｓａ；Ｋｃｒ））、発行者署名からなる。
【０５９８】
実行命令に含まれる秘密鍵（Ｋｓａ）は、代理署名生成、検証の際に用いる秘密鍵であり、前述の公開鍵（Ｋｐａ）に対応する秘密鍵である。
【０５９９】
ステップＳ９１１〜Ｓ９１３は、発行フェーズであり、この発行フェーズの完了の後、検証フェーズが開始される。ステップＳ９１４において、サービスプロバイダ（ＳＰ）等の検証者は、ＡＣ利用者（属性保持者）に対して代理署名グループ属性証明書（Ｇｐ．ＡＣ）の提示要求を実行する。この提示要求に際して、サービスプロバイダ（ＳＰ）等の検証者は、代理署名グループ属性証明書（Ｇｐ．ＡＣ）の検証用乱数（Ｒａ）をＡＣ利用者（属性保持者）に対して送信する。
【０６００】
ＡＣ利用者（属性保持者）は、ステップＳ９１５において、サービスプロバイダ（ＳＰ）等の検証者からの代理署名グループ属性証明書（Ｇｐ．ＡＣ）の提示要求に応じて、先に発行者から受領した代理署名実行属性証明書を適用して代理署名グループ属性証明書（Ｇｐ．ＡＣ）９２２を生成する。この生成処理の詳細については後述する。代理署名グループ属性証明書（Ｇｐ．ＡＣ）９２２は、ＡＣ利用者（属性保持者）の公開鍵証明書（ＰＫＣ）のシリアル番号、属性情報等の情報に、検証者から受信した検証用乱数（Ｒａ）を含み、先に、発行者から受領した代理署名実行属性証明書９２３の実行命令中に格納された秘密鍵（Ｋｓａ）を適用した署名が付加される。
【０６０１】
ＡＣ利用者（属性保持者）は、生成した代理署名グループ属性証明書９２２と、代理署名鍵証明書９２４を併せて検証者に送付（Ｓ９１６）する。検証者は、代理署名鍵証明書９２４の署名検証の後、代理署名鍵証明書９２４に格納された代理署名検証用の公開鍵（Ｋｐａ）を取り出して、取り出した公開鍵（Ｋｐａ）を適用して、代理署名グループ属性証明書９２２の署名検証を実行する。さらに、代理署名グループ属性証明書中に格納された乱数と自己が先に生成した乱数の一致を検証することにより、今回の検証で、検証者の要求に対して提示された代理署名グループ属性証明書であることを確認できる。
【０６０２】
サービス提供も含めた各エンティテイ間でのデータの流れを図８７を参照して説明する。まず、発行フェーズにおいて、発行者９３１からＡＣ利用者（属性保持者）９３２に対して代理署名鍵証明書９４１、および代理署名実行属性証明書９４２がＡＣ利用者（属性保持者）９３２に送付される。次に、ＡＣ利用者（属性保持者）９３２からサービスプロバイダ（ＳＰ）等の検証者９３３にサービス要求がなされると、検証者９３３は、ＡＣ利用者（属性保持者）９３２に対して代理署名グループ属性証明書（Ｇｐ．ＡＣ）の提示要求を実行する。この提示要求に際して、検証者９３３は、代理署名グループ属性証明書（Ｇｐ．ＡＣ）の検証用乱数（Ｒａ）をＡＣ利用者（属性保持者）９３２に対して送信する。
【０６０３】
ＡＣ利用者（属性保持者）９３２は、検証者９３３からの代理署名グループ属性証明書（Ｇｐ．ＡＣ）の提示要求に応じて、先に発行者から受領した代理署名実行属性証明書を適用して代理署名グループ属性証明書（Ｇｐ．ＡＣ）９４３を生成する。代理署名グループ属性証明書（Ｇｐ．ＡＣ）９４３は、ＡＣ利用者（属性保持者）９３２の公開鍵証明書（ＰＫＣ）のシリアル番号、属性情報等の情報に、検証者から受信した検証用乱数（Ｒａ）を含み、先に、発行者から受領した代理署名実行属性証明書９４２の実行命令中に格納された秘密鍵（Ｋｓａ）を適用した署名が付加される。
【０６０４】
次に、ＡＣ利用者（属性所有者）９３２は、代理署名グループ属性証明書９４３と、代理署名鍵証明書９４１を検証者に送付し、検証者が、代理署名グループ属性証明書９４３と、代理署名鍵証明書９４１に基づくＡＣ利用者の属性検証を実行し、検証成立を条件としてサービスを提供する。
【０６０５】
サービスプロバイダ（ＳＰ）等の検証者９３３は、代理署名鍵証明書９４１の署名検証の後、代理署名鍵証明書９４１に格納された代理署名検証用の公開鍵（Ｋｐａ）を取り出して、取り出した公開鍵（Ｋｐａ）を適用して代理署名グループ属性証明書９４３の署名検証を実行し、また代理署名グループ属性証明書９４３の格納乱数の照合により検証を行なう。
【０６０６】
次に、発行者の発行した代理署名実行属性証明書と代理署名鍵証明書とを有するＡＣ利用者が、サービスプロバイダ（ＳＰ）等の検証者からの代理署名グループ属性証明書の提示要求に際して実行する処理の詳細を図８８を参照して説明する。図８８において、
ＳＰ：属性証明書の検証を実行するサービスプロバイダ制御部、
ＳＭ：ＳＰのセキュリティモジュール
ＥＥ：属性証明書利用ユーザデバイスのエンドエンティテイ（ＥＥ）制御部、
ＳＣ：ＥＥ内に構成されるセキュリティチップ、
実行ＡＣテーブル：ＥＥの実行ＡＣテーブル制御部、
である。
【０６０７】
図８８の処理は、サービスプロバイダ（ＳＰ）のセキュリティモジュール（ＳＭ）と、ユーザデバイスのセキュリティチップ（ＳＣ）間で相互認証が成立した後の処理を示している。
【０６０８】
相互認証成立の後、サービスプロバイダ（ＳＰ）は、セキュリティモジュール（ＳＭ）に対して、属性証明書検証時に適用する乱数の生成要求（Ｓ９５１）を行なう、ステップＳ９５２において、セキュリティモジュール（ＳＭ）は、要求に応じて乱数を生成しサービスプロバイダ（ＳＰ）に出力する。
【０６０９】
ステップＳ９５３において、サービスプロバイダ（ＳＰ）は、エンドエンティテイ（ＥＥ）に対して代理署名グループ属性証明書の提示要求を実行する。この際、サービスプロバイダ（ＳＰ）は、エンドエンティテイ（ＥＥ）に対して代理署名グループ属性証明書（Ｇｐ．ＡＣ）の検証用乱数（Ｒａ）を併せて送信する。
【０６１０】
ステップＳ９５４において、エンドエンティテイ（ＥＥ）は、代理署名グループ属性証明書（Ｇｐ．ＡＣ）の生成に適用する代理署名実行属性証明書の検索を実行ＡＣテーブルに対して行ない、実行ＡＣテーブルは、ステップＳ９５５において、代理署名実行属性証明書およびそれに対応する代理署名鍵証明書をエンドエンティテイ（ＥＥ）に対して出力する。
【０６１１】
ステップＳ９５６において、エンドエンティテイ（ＥＥ）は、代理署名実行属性証明書の適用処理、すなわち、代理署名グループ属性証明書の生成処理をセキュリティチップ（ＳＣ）に要求し、ステップＳ９５８において、セキュリティチップ（ＳＣ）は、代理署名グループ属性証明書の生成処理を実行する。この代理署名グループ属性証明書の生成処理の詳細は、先に図８５を参照して説明した審査代行実行属性証明書に基づく審査代行グループ属性証明書の処理と同様である。ただし、代理署名グループ属性証明書には、検証者から受信した乱数（Ｒａ）が格納される。
【０６１２】
ステップＳ９５８において、セキュリティチップ（ＳＣ）は、生成した代理署名グループ属性証明書をエンドエンティテイ（ＥＥ）に送付する。エンドエンティテイ（ＥＥ）は、ステップＳ９５９において、代理署名グループ属性証明書、および、先に発行者から受領済みの代理署名鍵証明書をサービスプロバイダ側のセキュリティモジュール（ＳＭ）に送信する。
【０６１３】
サービスプロバイダ側のセキュリティモジュール（ＳＭ）が、代理署名グループ属性証明書と、代理署名鍵証明書を受信すると、代理署名鍵証明書に格納された代理署名検証用の公開鍵（Ｋｐａ）を取り出して、取り出した公開鍵（Ｋｐａ）を適用して代理署名グループ属性証明書の署名検証を実行し、また代理署名グループ属性証明書の格納乱数の照合処理に基づく検証を行ない、検証結果をサービスプロバイダ（ＳＰ）に通知する。サービスプロバイダ（ＳＰ）は応答結果に応じて、検証成立の場合はサービス提供を実行し、検証不成立の場合はサービス提供の停止処理を行なうことになる。
【０６１４】
代理署名実行属性証明書の適用例として、通常の属性証明書がある。すなわち、通常の属性証明書の代わりに、代理署名実行属性証明書を用いれば、実行属性証明書の破棄処理機能を用いることが出来るので、検証のたびに破棄リストを参照するなどの、失効処理による煩雑さ、信頼性の低下を解決することが出来る。
【０６１５】
さらなる適用例としては、属性証明回数を制限した代理署名属性証明書がある。すなわち、アクセス許可など、暗号化データの復号以外のサービスに対しても、サービス提供を認めるグループ属性証明書として、回数制限の機能を持った代理署名実行属性証明書を用いれば、サーバ等外部に回数情報を持たせるなどの処理の煩雑さ、処理効率の低下なく、制限されたサービス提供を行うことが出来る。
【０６１６】
［（８）各エンティテイの構成］
次に、上述した処理、すなわち属性証明書の生成、検証、送受信等を実行するユーザデバイスとしてのセキュリティチップ（ＳＣ）を備えたエンドエンティテイ（ＥＥ）、あるいはセキュリティチップ（ＳＣ）を備えたユーザ識別デバイス（ＵＩＤ）、あるいはサービスプロバイダ（ＳＰ）等、各エンティテイの情報処理装置としての構成例について図を参照しながら、説明する。
【０６１７】
ユーザデバイス、サービスプロバイダ等、各エンティテイの情報処理装置は、各種のデータ処理、および制御を実行するＣＰＵを有し、かつ他エンティテイと通信可能な通信手段を備えた例えば、サーバ、ＰＣ、ＰＤＡ、携帯通信端末装置等の各種の情報処理装置によって構成可能である。
【０６１８】
図８９に情報処理装置構成例を示す。なお、図８９に示す構成例は１つの例であり、各エンティテイは、ここに示すべての機能を必ずしも備えることが要求されるものではない。図８９に示すＣＰＵ（Ｃｅｎｔｒａｌ　ｐｒｏｃｅｓｓｉｎｇ　Ｕｎｉｔ）９５１は、各種アプリケーションプログラムや、ＯＳ（Ｏｐｅｒａｔｉｎｇ　Ｓｙｓｔｅｍ）を実行するプロセッサである。ＲＯＭ（Ｒｅａｄ−Ｏｎｌｙ−Ｍｅｍｏｒｙ）９５２は、ＣＰＵ９５１が実行するプログラム、あるいは演算パラメータとしての固定データを格納する。ＲＡＭ（Ｒａｎｄｏｍ　Ａｃｃｅｓｓ　Ｍｅｍｏｒｙ）９５３は、ＣＰＵ９５１の処理において実行されるプログラム、およびプログラム処理において適宜変化するパラメータの格納エリア、ワーク領域として使用される。
【０６１９】
ＨＤＤ９５４はハードディスクの制御を実行し、ハードディスクに対する各種データ、プログラムの格納処理および読み出し処理を実行する。セキュリティチップ９６２は、前述したように耐タンパ構造を持つ構成であり、暗号処理に必要な鍵データ等を格納し、権限確認処理としての属性証明書の検証、あるいは生成処理等を実行する暗号処理部、データ処理部、メモリを有する。
【０６２０】
バス９６０はＰＣＩ（Ｐｅｒｉｐｈｅｒａｌ　Ｃｏｍｐｏｎｅｎｔ　Ｉｎｔｅｒｆａｃｅ）バス等により構成され、各モジュール、入出力インタフェース９６１を介した各入出力装置とのデータ転送を可能にしている。
【０６２１】
入力部９５５は、例えばキーボード、ポインティングデバイス等によって構成され、ＣＰＵ９５１に各種のコマンド、データを入力するためにユーザにより操作される。出力部９５６は、例えばＣＲＴ、液晶ディスプレイ等であり、各種情報をテキストまたはイメージ等により表示する。
【０６２２】
通信部９５７はデバイスの接続したエンティテイ、例えばサービスプロバイダ等との通信処理を実行するネットワークインタフェース、接続機器インタフェース等からなり、ＣＰＵ９５１の制御の下に、各記憶部から供給されたデータ、あるいはＣＰＵ９５１によって処理されたデータ、暗号化されたデータ等を送信したり、他エンティテイからのデータを受信する処理を実行する。
【０６２３】
ドライブ９５８は、フレキシブルディスク、ＣＤ−ＲＯＭ（Ｃｏｍｐａｃｔ　Ｄｉｓｃ　ＲｅａｄＯｎｌｙ　Ｍｅｍｏｒｙ），ＭＯ（Ｍａｇｎｅｔｏ　ｏｐｔｉｃａｌ）ディスク，ＤＶＤ（Ｄｉｇｉｔａｌ　Ｖｅｒｓａｔｉｌｅ　Ｄｉｓｃ）、磁気ディスク、半導体メモリなどのリムーバブル記録媒体９５９の記録再生を実行するドライブであり、各リムーバブル記録媒体９５９からのプログラムまたはデータ再生、リムーバブル記録媒体９５９に対するプログラムまたはデータ格納を実行する。
【０６２４】
各記憶媒体に記録されたプログラムまたはデータを読み出してＣＰＵ９５１において実行または処理を行なう場合は、読み出したプログラム、データはインタフェース９６１、バス９６０を介して例えば接続されているＲＡＭ９５３に供給される。
【０６２５】
前述の説明内に含まれるユーザデバイス、サービスプロバイダ等における処理を実行するためのプログラムは例えばＲＯＭ９５２に格納されてＣＰＵ９５１によって処理されるか、あるいはハードディスクに格納されＨＤＤ９５４を介してＣＰＵ９５１に供給されて実行される。
【０６２６】
以上、特定の実施例を参照しながら、本発明について詳解してきた。しかしながら、本発明の要旨を逸脱しない範囲で当業者が該実施例の修正や代用を成し得ることは自明である。すなわち、例示という形態で本発明を開示してきたのであり、限定的に解釈されるべきではない。本発明の要旨を判断するためには、冒頭に記載した特許請求の範囲の欄を参酌すべきである。
【０６２７】
なお、明細書中において説明した一連の処理はハードウェア、またはソフトウェア、あるいは両者の複合構成によって実行することが可能である。ソフトウェアによる処理を実行する場合は、処理シーケンスを記録したプログラムを、専用のハードウェアに組み込まれたコンピュータ内のメモリにインストールして実行させるか、あるいは、各種処理が実行可能な汎用コンピュータにプログラムをインストールして実行させることが可能である。
【０６２８】
例えば、プログラムは記録媒体としてのハードディスクやＲＯＭ（Ｒｅａｄ　Ｏｎｌｙ　Ｍｅｍｏｒｙ）に予め記録しておくことができる。あるいは、プログラムはフレキシブルディスク、ＣＤ−ＲＯＭ（Ｃｏｍｐａｃｔ　Ｄｉｓｃ　Ｒｅａｄ　Ｏｎｌｙ　Ｍｅｍｏｒｙ），ＭＯ（Ｍａｇｎｅｔｏ　ｏｐｔｉｃａｌ）ディスク，ＤＶＤ（Ｄｉｇｉｔａｌ　Ｖｅｒｓａｔｉｌｅ　Ｄｉｓｃ）、磁気ディスク、半導体メモリなどのリムーバブル記録媒体に、一時的あるいは永続的に格納（記録）しておくことができる。このようなリムーバブル記録媒体は、いわゆるパッケージソフトウエアとして提供することができる。
【０６２９】
なお、プログラムは、上述したようなリムーバブル記録媒体からコンピュータにインストールする他、ダウンロードサイトから、コンピュータに無線転送したり、ＬＡＮ（Ｌｏｃａｌ　Ａｒｅａ　Ｎｅｔｗｏｒｋ）、インターネットといったネットワークを介して、コンピュータに有線で転送し、コンピュータでは、そのようにして転送されてくるプログラムを受信し、内蔵するハードディスク等の記録媒体にインストールすることができる。
【０６３０】
なお、明細書に記載された各種の処理は、記載に従って時系列に実行されるのみならず、処理を実行する装置の処理能力あるいは必要に応じて並列的にあるいは個別に実行されてもよい。また、本明細書においてシステムとは、複数の装置の論理的集合構成であり、各構成の装置が同一筐体内にあるものには限らない。
【０６３１】
【発明の効果】
以上、説明したように、本発明のデータ処理権限管理システム、情報処理装置、および方法によれば、暗号化処理のなされたデータ処理実行命令を含む暗号化実行命令と、暗号化実行命令の復号処理に適用する登録鍵のユーザデバイス内メモリの格納領域を示すアドレス（Ａｄ）情報とを格納データとして有する実行属性証明書をサービス受領デバイスであるユーザデバイスに対して提供し、ユーザデバイスにおいて、実行属性証明書に格納されたアドレス（Ａｄ）情報に従って、ユーザデバイスのメモリから取得した登録鍵を適用して、実行属性証明書に格納された暗号化実行命令の復号を行ない、復号結果に基づくデータ処理を実行する構成としたので、登録鍵を実行属性証明書に格納したアドレスに従って取得可能なユーザデバイスにおいてのみ実行属性証明書に格納した実行命令を実行することが可能となり、サービス利用権限を有するユーザに対して厳格に限定したサービスの提供が可能となる。
【０６３２】
さらに、本発明のデータ処理権限管理システム、情報処理装置、および方法によれば、サービス提供実行属性証明書に適用する登録鍵の格納を登録鍵生成実行属性証明書に従って実行する構成としたので、不正な登録鍵の格納が防止され、不正なサービス受領を確実に防止できる。
【０６３３】
さらに、本発明のデータ処理権限管理システム、情報処理装置、および方法によれば、リセット鍵の書き込みによる登録鍵の破棄処理を実行する構成としたので、不正な登録鍵の保持を防止することが可能となる。
【０６３４】
さらに、本発明のデータ処理権限管理システム、情報処理装置、および方法では、実行命令に適用可能回数識別値を格納し、実行命令の実行に応じて適用可能回数識別値を更新して、更新された適用可能回数識別値を含む新たな実行属性証明書の生成を行なう構成としたので、利用回数制限のあるサービスの受領を確実な回数制限の下に実行可能となる。
【０６３５】
さらに、本発明のデータ処理権限管理システム、情報処理装置、および方法によれば、譲渡用実行属性証明書の生成処理命令、審査代行属性証明書の発行処理命令、代理署名属性証明書の発行処理命令等の各種の実行命令を実行属性証明書に格納することにより、様々な属性証明書の利用形態が実現される。
【図面の簡単な説明】
【図１】権限管理システムにおける公開鍵基盤、権限管理基盤構成について説明する図である。
【図２】公開鍵証明書のフォーマットを示す図である。
【図３】公開鍵証明書のフォーマットを示す図である。
【図４】公開鍵証明書のフォーマットを示す図である。
【図５】権限情報証明書としての属性証明書のフォーマットを示す図である。
【図６】グループ属性証明書（グループＡＣ）の発行者、所有者、検証者、属性情報の構成例を示す図である。
【図７】グループ属性証明書の発行ポリシーテーブルを示す図である。
【図８】権限管理システムに参加する各エンティテイの信頼関係構成を説明するトラストモデルを示す図である。
【図９】ユーザデバイスとしてのエンドエンティテイ（ＥＥ）とユーザ識別デバイス（ＵＩＤ）に構成されるセキュリテイチップの構成例を示す図である。
【図１０】ユーザデバイスのセキュリティチップの格納データ例を示す図である。
【図１１】グループ属性証明書の発行申請、発行処理、利用処理の流れの概略を説明する図である。
【図１２】サービスプロバイダ（ＳＰ）と、属性認証局（ＡＡ）または属性証明書登録局（ＡＲＡ）のグループ情報共有化処理について説明する図である。
【図１３】公開鍵暗号方式の１つの認証処理方式であるハンドシェイクプロトコル（ＴＬＳ１．０）について示す図である。
【図１４】メッセージ認証コード：ＭＡＣ（Ｍｅｓｓａｇｅ　Ａｕｔｈｅｎｔｉｃａｔｉｏｎ　Ｃｏｄｅ）の生成構成を示す図である。
【図１５】発行ポリシーテーブル、グループ情報データベースの情報構成例を示す図である。
【図１６】ユーザデバイスであるエンドエンティテイ（ＥＥ）のセキュリティチップ（ＳＣ）がグループ属性証明書の発行要求主体である場合の処理シーケンスを示す図である。
【図１７】電子署名の生成処理を説明するフロー図である。
【図１８】電子署名の検証処理を説明するフロー図である。
【図１９】ユーザ識別デバイス（ＵＩＤ）内のユーザセキュリティチップ（ＵＳＣ）対応のグループ属性証明書を発行する手順について説明するシーケンス図である。
【図２０】グループ属性証明書を利用したサービス利用権限確認を含むサービス開始までの処理について説明するシーケンス図である。
【図２１】公開鍵証明書（ＰＫＣ）と属性証明書（ＡＣ）との関連について説明する図である。
【図２２】属性証明書（ＡＣ）の検証処理フローを示す図である。
【図２３】公開鍵証明書（ＰＫＣ）の検証処理フローを示す図である。
【図２４】
グループ属性証明書を利用したサービス利用権限確認を含むサービス開始までの処理について説明するシーケンス図である。
【図２５】グループ属性証明書（Ｇｐ．ＡＣ）の審査処理を説明するシーケンス図である。
【図２６】サービスを提供条件として、ユーザあるいはユーザ機器が異なる複数のグループに属することが条件とされる場合の概念を説明する図である。
【図２７】ユーザ識別デバイス（ＵＩＤ）内のユーザセキュリティチップ（ＵＳＣ）に対応して発行されたグループ属性証明書に基づくサービス提供までの処理について説明するシーケンス図である。
【図２８】ユーザ識別デバイス（ＵＩＤ）内のユーザセキュリティチップ（ＵＳＣ）に対応して発行されたグループ属性証明書に基づくサービス提供までの処理について説明するシーケンス図である。
【図２９】ユーザデバイス間においてグループ属性証明書を発行し、格納する処理について説明するシーケンス図である。
【図３０】アクセス許可情報を属性として持つグループ属性証明書の発行処理シーケンスについて説明する図である。
【図３１】アクセス許可情報をグループ情報として持つグループ属性証明書と、他のグループ属性証明書との対応例について説明する図である。
【図３２】アクセス要求先ユーザデバイスが、自ら属性証明書の発行処理を実行せずに属性証明書の発行処理を他のユーザデバイスに依頼して実行する処理シーケンスについて説明する図である。
【図３３】アクセス許可情報をグループ情報として定義したグループ属性証明書を利用したアクセス可否判定処理を伴うサービス利用シーケンスについて説明する図である。
【図３４】各サービスにおいて利用されるグループ属性証明書の例を示す図である。
【図３５】第１のグループ属性証明書Ａに基づいて、コンテンツの利用許可情報をグループ情報として含む第２のグループ属性証明書Ｂを発行する処理について説明するシーケンス図である。
【図３６】グループ属性証明書Ｂをサービスプロバイダに提示して、コンテンツ利用権限のあることの確認を行なって、サービス提供、すなわちコンテンツ配信サービスを受領する処理について説明するシーケンス図である。
【図３７】複数の異なる属性証明書を適用してユーザあるいはユーザ機器のコンテンツ利用権を確認してサービスを提供する処理に適用する属性証明書例を説明する図である。
【図３８】異なるグループ属性証明書を適用したコンテンツ利用権限確認および、サービス提供処理について説明するフロー図である。
【図３９】サービス提供条件として設定されるグループ属性証明書の組み合わせテーブルデータ構成例を示す図である。
【図４０】複数のグループ属性証明書を適用した利用権限確認処理を説明する図である。
【図４１】医療処理において適用するグループ属性証明書の例を示す図である。
【図４２】医療処理を行なうリモートコントロールのシステムにおいて、各機器に格納される属性証明書について説明する図である。
【図４３】ユーザ識別デバイスに格納されたグループ属性証明書を適用して医療診断プログラムの実行サービスの利用権限確認処理を行ない、サービスを開始する処理シーケンスについて説明する図である。
【図４４】グループ属性証明書を適用して医療診断プログラムの実行結果としての診断データ引き取り処理サービスの利用権限確認処理を行ない、サービスを開始する処理シーケンスについて説明する図である。
【図４５】リモートメンテナンス処理において適用するグループ属性証明書の例を示す図である。
【図４６】メンテナンスサービスを行なうシステムにおいて、各機器に格納される属性証明書を説明する図である。
【図４７】サービス実行時におけるサービス属性証明書およびコントロール属性証明書の利用形態について説明する図である。
【図４８】家電機器（ＥＥ）に格納されたサービス属性証明書、サービスプロバイダに格納されたコントロール属性証明書を適用したメンテナンス等のサービス処理を説明するシーケンス図である。
【図４９】サービス属性証明書の審査処理について説明する図である。
【図５０】コントロール属性証明書に基づくサービス、例えば家電機器に対するメンテナンス処理を実行するシーケンスについて説明する図である。
【図５１】メンテナンス実行プログラムをメーカー側機器（ＳＰ）からユーザ側家電機器（ＥＥ）に対して送信する処理とした例を説明する図である。
【図５２】メンテナンス実行プログラムをメーカー側機器（ＳＰ）から、逐次コマンドを家電機器（ＥＥ）に送信し、コマンド実行に基づく応答を家電機器（ＥＥ）から受信しながらレスポンス対応の処理を実行する例を説明する図である。
【図５３】サービス提供要求時にサービス属性証明書、コントロール属性証明書をメーカー側（ＳＰ）に提示する処理例を説明する図である。
【図５４】コミュニケーションサービスにおいて適用するグループ属性証明書の例を説明する図である。
【図５５】コミュニケーションサービスにおいて適用するグループ属性証明書の格納構成例を示す図である。
【図５６】グループ属性証明書を適用してチャットルーム参加サービスの利用権限確認処理を行ない、サービスを開始する処理シーケンスについて説明する図である。
【図５７】グループ属性証明書を適用してアクセス権限確認処理を行ない、コミュニケーションを開始する処理シーケンスについて説明する図である。
【図５８】実行属性証明書の概要について説明する図である。
【図５９】実行属性証明書の利用手続き概要を説明するフロー図である。
【図６０】実行属性証明書の発行シーケンス図である。
【図６１】実行属性証明書の発行シーケンス図である。
【図６２】実行ＡＣテーブルの構成例を示す図である。
【図６３】セキュリティモジュール（ＳＭ）における登録鍵生成実行ＡＣの生成処理を説明する図である。
【図６４】セキュリティチップで実行される登録鍵生成実行ＡＣに基づく登録鍵生成処理について、説明する図である。
【図６５】セキュリティモジュール（ＳＭ）によるサービス提供実行ＡＣの生成処理を説明する図である。
【図６６】サービス提供実行ＡＣのユーザデバイス側における適用シーケンスをまとめた図である。
【図６７】セキュリティチップ（ＳＣ）におけるサービス提供処理における処理詳細を説明する図である。
【図６８】セキュリティチップ（ＳＣ）登録鍵破棄処理について説明する図である。
【図６９】リセット要求に基づく登録鍵の破棄処理としてのリセット処理を説明する図である。
【図７０】実行属性証明書をサービスプロバイダ（ＳＰ）の承認の下に破棄し、破棄が間違いなく実行されたことをサービスプロバイダに通知する実行属性証明書リセット（破棄）処理について説明する図である。
【図７１】実行属性証明書をサービスプロバイダ（ＳＰ）の承認の下に破棄し、破棄が間違いなく実行されたことをサービスプロバイダに通知する実行属性証明書リセット（破棄）処理について説明する図である。
【図７２】リセット確認結果生成処理の詳細について説明する図である。
【図７３】実行ＡＣに基づく登録鍵の破棄処理について説明する図である。
【図７４】回数制限付きサービス提供実行属性証明書をユーザデバイスにおいて適用してサービスを適用する処理を説明する図である。
【図７５】回数制限付きサービス提供実行属性証明書をユーザデバイスにおいて適用してサービスを適用する処理を説明する図である。
【図７６】更新後の残利用回数≧１の場合のセキュリティチップ（ＳＣ）における処理を説明する図である。
【図７７】更新後の残利用回数＝０の場合のセキュリティチップ（ＳＣ）における処理を説明する図である。
【図７８】譲渡機能付きサービス提供実行属性証明書の適用処理を説明する図である。
【図７９】譲渡機能付きサービス提供実行属性証明書の復号処理以降の処理詳細を説明する図である。
【図８０】譲渡機能付きサービス提供実行属性証明書の復号処理以降の処理詳細を説明する図である。
【図８１】譲渡機能付きサービス提供実行属性証明書を適用した暗号化データ復号処理を説明する図である。
【図８２】審査代行実行属性証明書の概要を説明する図である。
【図８３】審査代行実行属性証明書を適用した処理を説明する図である。
【図８４】審査代行グループ属性証明書を生成、発行する処理について説明する図である。
【図８５】審査代行実行属性証明書を入力して審査代行グループ属性証明書を生成する処理を説明する図である。
【図８６】代理署名実行属性証明書の概要を説明する図である。
【図８７】代理署名実行属性証明書を適用した処理を説明する図である。
【図８８】サービスプロバイダ（ＳＰ）等の検証者からの代理署名グループ属性証明書の提示要求に際して実行する処理を説明する図である。
【図８９】ユーザデバイス、サービスプロバイダ等、各エンティテイの情報処理装置構成例を示す図である。
【符号の説明】
１０１　公開鍵基盤
１０２　権限管理基盤
１１１，１１３　ユーザデバイス
１１２　サービスプロバイダ
１２１　公開鍵証明書
１２２　属性証明書
１３０　システムホルダ
１３１　ルート認証局（ＣＡ）
１３２　認証局（ＣＡ）
１３３　登録局（ＲＡ）
１４０　属性認証局（ＡＡ）
１５０　属性証明書登録局（ＡＲＡ）
１５１　ポリシーテーブル
１６０　サービスプロバイダ（ＳＰ）
１７０　ユーザデバイス
１７１　ユーザ識別デバイス（ＵＩＤ）
１７２　エンドエンティテイ（ＥＥ）
２００　ユーザデバイス
２０１　ＣＰＵ　（Ｃｅｎｔｒａｌ　ｐｒｏｃｅｓｓｉｎｇ　Ｕｎｉｔ）
２０２　インタフェース
２０３　ＲＯＭ（Ｒｅａｄ−Ｏｎｌｙ−Ｍｅｍｏｒｙ）
２０４　ＲＡＭ（Ｒａｎｄｏｍ　Ａｃｃｅｓｓ　Ｍｅｍｏｒｙ）
２０５　暗号処理部
２０６　メモリ部
２０７　共通鍵メモリ領域
２１０　セキュリティチップ
２２１　ユーザデバイス側制御部
２２２　外部メモリ部
２３１　接続機器インタフェース
２３２　ネットワークインタフェース
３１１　ユーザデバイス
３１２　属性証明書登録局（ＡＲＡ）
３１３　発行ポリシーテーブル
３１４　サービスプロバイダ
３１５　グループ情報データベース
３１６　グループ属性証明書
４０１　病院側医療機器（ＳＰ）
４０２　グループ属性証明書ＡＣ０２
４０３　セキュリティモジュール
４１１　自宅側医療機器（ＥＥ）
４１２　セキュリティチップ
４２１　ユーザ識別デバイス
４２２　グループ属性証明書ＡＣ０１
４２３　ユーザセキュリティチップ
４５１　メーカー側機器（ＳＰ）
４５２　コントロール属性証明書
４５３　セキュリティモジュール
４６１　ユーザ側家電機器（ＥＥ）
４６２　サービス属性証明書
４６３　セキュリティチップ
４７１　ユーザ識別デバイス
４７２　ユーザセキュリティチップ
４８１　ユーザデバイス
４８２　メーカー側機器（ＳＰ）
４８３　サービス情報データベース
４８４　サービス属性証明書
４８５　コントロール属性証明書
４９１　ユーザデバイス
４９２　メーカー側機器（ＳＰ）
４９３　サービス属性証明書
４９４　コントロール属性証明書
５０１　チャットルーム提供サービスプロバイダ（ＳＰ）
５０２　セキュリティモジュール
５１１　甲さん通信端末（ＥＥ）
５１２　セキュリティチップ
５２１　ユーザ識別デバイス
５２２　ユーザセキュリティチップ
５２３　グループ属性証明書ＡＣ０１
５２４　グループ属性証明書ＡＣ０２
５３１　乙さん通信端末（ＥＥ）
５３２　セキュリティチップ
５３３　ユーザ識別デバイス（ＵＩＤ）
５３４　ユーザセキュリティチップ（ＵＳＣ）
６０１　セキュリティモジュール
６０２　公開鍵暗号エンジン
６０３　共通鍵暗号エンジン
６０５　セキュリティチップ
６０６　公開鍵暗号エンジン
６０７　共通鍵暗号エンジン
６０８　共通鍵メモリ領域
６１１　登録鍵生成実行属性証明書（ＡＣ）
６１２　登録鍵生成実行結果
６１３　実行命令
６１４　サービス提供実行属性証明書（ＡＣ）
６１５　暗号化データ
６１６　データ
６１７　リセット処理命令
６２１　リセット確認実行属性証明書（ＡＣ）
６２２　リセット確認結果
６２３　登録鍵破棄実行属性証明書（ＡＣ）
７０１　回数制限付きサービス提供実行属性証明書（ＡＣ）
７０２　暗号化データ
７０３　データ
７０４　回数制限付きサービス提供実行属性証明書（ＡＣ）
７０５　回数制限付きサービス提供実行属性証明書（ＡＣ）
７０６　暗号化データ
７０７　データ
７１１　譲渡機能付きサービス提供実行属性証明書（ＡＣ）
７１２　譲渡実行トリガ
７１３　グループ属性証明書
７１４　データ
７１５　登録鍵生成実行属性証明書（ＡＣ）
７２１　登録鍵生成実行結果
７２２　譲渡機能付きサービス提供実行属性証明書（ＡＣ）
７３１　譲渡機能付きサービス提供実行属性証明書（ＡＣ）
７３２　暗号化データトリガ
７３３　暗号化データ
７３４　データ
８０１　グループ属性証明書
８０２　審査代行グループ属性証明書
８０３　審査代行実行属性証明書
８０４　代理署名鍵証明書
８１１　発行者
８１２　審査代行者
８１３　ＡＣ利用者（属性保持者）
８１４　検証者
８２１　代理署名鍵証明書
８２２　審査代行実行属性証明書
８２３　審査代行グループ属性証明書
８５１　審査代行実行属性証明書（代理署名実行属性証明書）
８５２　グループ属性証明書
８５３　付加情報
８５４　審査代行グループ属性証明書（代理署名グループ属性証明書）
９２１　グループ属性証明書
９２２　代理署名グループ属性証明書
９２３　代理署名実行属性証明書
９２４　代理署名鍵証明書
９３１　発行者
９３２　ＡＣ利用者（属性保持者）
９３３　検証者
９４１　代理署名鍵証明書
９４２　代理署名実行属性証明書
９４３　代理署名グループ属性証明書
９５１　ＣＰＵ　（Ｃｅｎｔｒａｌ　ｐｒｏｃｅｓｓｉｎｇ　Ｕｎｉｔ）
９５２　ＲＯＭ（Ｒｅａｄ−Ｏｎｌｙ−Ｍｅｍｏｒｙ）
９５３　ＲＡＭ（Ｒａｎｄｏｍ　Ａｃｃｅｓｓ　Ｍｅｍｏｒｙ）
９５４　ＨＤＤ
９５５　入力部
９５６　出力部
９５７　通信部
９５８　ドライブ
９５９　リムーバブル記録媒体
９６０　バス
９６１　入出力インタフェース
９６２　セキュリティチップ[0001]
TECHNICAL FIELD OF THE INVENTION
The present invention relates to a data processing authority management system, an information processing apparatus and method, and a computer program. For example, it manages the service receiving authority such as the user who is required to confirm in the content use or service use process, etc., and the service can be executed only by the user who has the legitimate service receiving authority. The present invention relates to a data processing authority management system, an information processing apparatus, and a method, and a computer program, which can strictly restrict the data processing authority.
[0002]
[Prior art]
Recently, various software data such as music data, image data, game programs, and the like via a communication network such as the Internet or a circulating storage medium such as a DVD, a CD, or an IC card (hereinafter referred to as content) ), Or service providing processing involving communication processing between terminals, such as settlement involving data transmission / reception processing between terminals. For example, a user having various user devices, such as a PC, a mobile communication terminal, a portable device, or an IC card, connects the user device to a service providing device of a service provider at home or on the road, and exchanges information between devices. Or, it is becoming more common to receive contents and services.
[0003]
Specific examples of service utilization include, for example, accessing a content distribution service provider using a PC, a mobile terminal, or the like, downloading various contents such as music, moving images, and game programs, or using personal information, a bank, or the like. Using a memory card or the like with a built-in IC chip that stores account information, available amount information, etc., it is used for shopping, transfer processing, or as an alternative to tickets at station ticket gates, buses, etc. , And various uses are being made.
[0004]
As described above, while the distribution of contents or services via a communication network or a medium has become popular, the problem of unauthorized use of contents or services, that is, the problem of using services by users without proper authority has arisen. There is a demand for a system that reliably provides contents, services, and the like only to users having proper use authority, and eliminates unauthorized use of services.
[0005]
For example, many software contents, such as music data, image data, game programs, etc., generally have their distribution rights reserved by their creators and sellers. Restrictions, that is, a system that considers security so that only authorized users are allowed to use the software and unauthorized copying is not performed.
[0006]
One method of realizing the use restriction of a device or a user who receives a service is an encryption process. For example, when content or service information is provided to a device or a user, there is a form in which the content or service is encrypted and provided, and a decryption key that can be used only by an authorized device or user is distributed, so that the content or service can be used. The encrypted data can be returned to decrypted data (plaintext) by a decryption process using a decryption key.
[0007]
There are various types of data encryption / decryption methods using an encryption key and a decryption key, and one example is a so-called common key encryption method. In the common key encryption method, an encryption key used for data encryption processing and a decryption key used for data decryption are used in common, and a common user used for these encryption processing and decryption is assigned to an authorized user. Thus, data access by an unauthorized user having no key is excluded. As a typical method of this method, there is DES (Data encryption standard).
[0008]
In addition, a method of performing processing using an encryption key used for encryption and processing for a decryption key used for decryption using different keys is a so-called public key encryption method. The public key cryptosystem is a method of using a public key that can be used by an unspecified user, and performs an encryption process on an encrypted document for a specific individual using a public key generated by the specific individual. A document encrypted with a public key can be decrypted only with a private key corresponding to the public key used for the encryption processing. Since the private key is owned only by the individual who generated the public key, a document encrypted with the public key can be decrypted only by the individual having the private key. Representative public key cryptosystems include elliptic curve cryptography or RSA (Rivest-Shamir-Adleman) cryptography. By using such an encryption method, a system that enables encrypted content to be decrypted only for authorized users is possible.
[0009]
In the content or service usage management configuration as described above, the determination as to whether or not the user is a legitimate user is made, for example, between a service provider as a provider of the content or service and a user device such as a PC, a mobile terminal, or an IC card. A method is known in which authentication is performed before providing encrypted data such as content, service information, or a decryption key. In a general authentication process, a party key is confirmed and a session key valid only for the communication is generated. When the authentication is established, data such as contents or a decryption key is generated using the generated session key. For communication.
[0010]
[Problems to be solved by the invention]
As a system for confirming user authority, as described above, there is a method of performing one-to-one authentication processing between a service provider that provides a service and a user to confirm user authority. With the diversification of services that can be executed on user terminals, such as other information use services and payment services, the construction of a system that efficiently, reliably and securely checks whether each user or user terminal has the right to use the service. Is desired.
[0011]
The present invention has been made in view of the above problems, and when receiving various services from a device provided by a service provider via a user device such as a PC, a communication terminal device, a mobile terminal, and an IC card, Efficiently and securely check the user's service usage authority, and enable the service to be executed only to the user who has the legitimate service receiving authority. It is an object of the present invention to provide a data processing authority management system, an information processing device, a method, and a computer program.
[0012]
[Means for Solving the Problems]
According to a first aspect of the present invention,
A data processing authority management system that manages data processing authority in a user device that executes a service provided by a service provider,
The service provider
The stored data includes an encryption execution instruction including an encrypted data processing execution instruction, and address (Ad) information indicating a storage area of a memory in the user device of a registration key applied to the decryption processing of the encryption execution instruction. Providing the execution attribute certificate having as a to the user device which is the service receiving device,
The user device
According to the address (Ad) information stored in the execution attribute certificate, a registration key obtained from the memory of the user device is applied to decrypt the encryption execution instruction stored in the execution attribute certificate, and decrypt the encrypted execution instruction. A data processing authority management system is characterized in that data processing is performed based on the result.
[0013]
Further, in one embodiment of the data processing authority management system of the present invention, the execution attribute certificate has an issuer digital signature for stored data including the encrypted execution instruction and the address (Ad) information, The user device performs a digital signature verification process of the execution attribute certificate, and executes a registration key acquisition process according to the address (Ad) information on condition that the verification is established. I do.
[0014]
Further, in one embodiment of the data processing authority management system of the present invention, in the data processing authority management system, the process of issuing a new execution attribute certificate to the user device is performed by executing the execution attribute certificate issuing entity with the execution attribute certificate. Receiving, from the issuance requesting user device, a group attribute certificate having group identification information set corresponding to a group consisting of a specific device or a set of specific users as storage information and having an issuer electronic signature; It is characterized in that the certificate is verified and executed on condition that the verification is established.
[0015]
Further, in one embodiment of the data processing authority management system of the present invention, the service provider acquires registration key storage planned address information from the user device, and transmits the registration key storage planned address information and a registration key storage instruction. A configuration in which a data part having an encryption execution instruction encrypted by applying a key obtainable by a user device and a registration key generation execution attribute certificate including an electronic signature for the data part are generated and provided to the user device The user device verifies the digital signature, decrypts the encryption execution instruction stored in the registration key generation execution attribute certificate, and processes the execution instruction obtained by decryption, thereby registering the registration key with the registration key. It is characterized in that it is configured to execute a process of storing data in a memory area corresponding to a storage scheduled address.
[0016]
Further, in one embodiment of the data processing authority management system according to the present invention, the registration key is a key generated based on a random number in the user device.
[0017]
Further, in one embodiment of the data processing authority management system of the present invention, the user device applies a registration key obtained from a memory of the user device according to address (Ad) information stored in the execution attribute certificate. Then, the encryption execution instruction stored in the execution attribute certificate is decrypted, data processing is performed based on the decryption result, and the registration key storage area is stored in the memory area corresponding to the specified address (Ad). The configuration is such that the registration key is destroyed by writing the reset key data.
[0018]
Further, in one embodiment of the data processing authority management system of the present invention, the encryption execution instruction stored in the execution attribute certificate stores an identification number of an applicable number of times of the execution instruction, and the user device executes the execution instruction. The present invention is characterized in that the applicable number identification value is updated in accordance with the execution of the instruction, and a new execution attribute certificate including the updated applicable number identification value is generated.
[0019]
Further, in one embodiment of the data processing authority management system of the present invention, the encryption execution instruction stored in the execution attribute certificate stores an identification number of an applicable number of times of the execution instruction, and the user device executes the execution instruction. The applicable number identification value is updated in accordance with the execution of the instruction, and when the updated applicable number identification value is 0, the registration key storage area is stored in the memory area corresponding to the specified address (Ad). , The configuration is such that the registration key is destroyed by writing the reset key data.
[0020]
Further, in one embodiment of the data processing authority management system of the present invention, the encryption execution instruction stored in the execution attribute certificate includes a generation processing instruction of an execution attribute certificate for transfer to another device, The device is characterized in that, in accordance with the transfer execution attribute certificate generation processing instruction, the device executes a new transfer execution attribute certificate generation process and executes a provision process to another device.
[0021]
Further, in one embodiment of the data processing authority management system of the present invention, the encryption execution instruction stored in the execution attribute certificate includes the issuance of an examination proxy attribute certificate as a certificate certifying the attribute of another device. A processing command, and a signature generation key required for generating the screening proxy attribute certificate, wherein the user device applies the signature generating key according to the screening proxy attribute certificate issuing Is performed to generate a screening proxy attribute certificate, and to provide the service to another service receiving device.
[0022]
Further, in one embodiment of the data processing authority management system of the present invention, the user device that has executed the generation of the screening proxy attribute certificate includes a step of providing the screening proxy attribute certificate to the other service receiving device. Providing a proxy signing key certificate that stores a signature verification key corresponding to the signature generation key and has an issuer signature, and the other service receiving device sends the examination proxy attribute certificate to a service providing entity. And a proxy signing key certificate, and the service providing entity is configured to execute a verification process of the examination proxy attribute certificate based on a signature verification key obtained from the proxy signing key certificate. Features.
[0023]
Further, in one embodiment of the data processing authority management system of the present invention, the encryption execution instruction stored in the execution attribute certificate includes issuing a proxy signature attribute certificate as a certificate for certifying the attribute of another device. A processing instruction and a signature generation key required for generating the proxy signature attribute certificate, wherein the user device executes the proxy signature attribute certificate verification according to the proxy signature attribute certificate issuance processing instruction And performing a process of generating a proxy signature attribute certificate having a signature to which the signature generation key is applied, including a verification random number (Ra) received from the verification device to be executed, and the generated proxy signature attribute certificate; A signature verification key corresponding to the signature generation key is stored, and a proxy signature key certificate having an issuer signature is presented to a service providing entity as a verification device. The service providing entity executes a process based on the signature verification key obtained from the proxy signing key certificate, based on the signature verification, and the proxy signature key by random number collation extracted from the proxy signature attribute certificate execution instruction. It is characterized in that it is configured to execute certificate verification processing.
[0024]
Further, a second aspect of the present invention provides
An information processing device that performs data processing,
A memory unit for storing a registration key applied to the decryption processing of the encrypted data,
An encryption execution instruction including an encrypted data processing execution instruction, and address (Ad) information indicating a storage area in a memory in the information processing device of a registration key to be applied to the decryption processing of the encryption execution instruction. An execution attribute certificate having an issuer signature is input as input data, and a signature verification process is executed. The signature is obtained from the memory unit in accordance with the address (Ad) information on condition that signature verification is established. An encryption processing unit that applies a registration key to decrypt the encryption execution instruction,
A data processing unit that executes the execution instruction decrypted in the encryption processing unit;
An information processing apparatus characterized by having:
[0025]
Further, in one embodiment of the information processing device of the present invention, the data processing unit writes the reset key data into a memory area corresponding to an address (Ad) that specifies the registration key storage area, thereby destroying the registration key. It is characterized by performing processing.
[0026]
Further, in one embodiment of the information processing apparatus of the present invention, the encryption execution instruction stored in the execution attribute certificate stores an identification number of an applicable number of times of the execution instruction, and the data processing unit executes the execution instruction. And updating the applicable number identification value in accordance with the execution of, and generating a new execution attribute certificate including the updated applicable number identification value.
[0027]
Further, in one embodiment of the information processing apparatus of the present invention, the encryption execution instruction stored in the execution attribute certificate stores an identification number of an applicable number of times of the execution instruction, and the data processing unit executes the execution instruction. Is updated in accordance with the execution of the above, and when the updated applicable number identification value becomes 0, the registration key storage area is stored in the memory area corresponding to the specified address (Ad). , The configuration is such that the registration key is destroyed by writing the reset key data.
[0028]
Further, in one embodiment of the information processing apparatus of the present invention, the encryption execution instruction stored in the execution attribute certificate includes a generation processing instruction of an execution attribute certificate for transfer to another device, and the data processing unit Is characterized in that, in accordance with the transfer execution attribute certificate generation processing instruction, a new transfer execution attribute certificate generation processing is performed, and a provision processing to another device is performed.
[0029]
Further, in one embodiment of the information processing apparatus of the present invention, the encryption execution instruction stored in the execution attribute certificate includes an examination processing attribute certificate issuing process instruction as a certificate certifying the attribute of another device. And a signature generation key required for generation of the screening proxy attribute certificate, wherein the data processing unit applies the signature generating key and applies a signature in accordance with the screening proxy attribute certificate issuing processing instruction. It is characterized in that it is configured to execute the process of generating the executed examination proxy attribute certificate.
[0030]
Further, in one embodiment of the information processing apparatus of the present invention, the encryption execution instruction stored in the execution attribute certificate includes a proxy signature attribute certificate issuance processing instruction as a certificate certifying an attribute of another device. And a signature generation key required for generating the proxy signature attribute certificate. The data processing unit performs verification of the proxy signature attribute certificate according to the proxy signature attribute certificate issuance processing instruction. It is characterized in that it includes a verification random number (Ra) received from a verification device as storage data and executes a process of generating a proxy signature attribute certificate having a signature to which the signature generation key is applied.
[0031]
Further, a third aspect of the present invention provides
A data processing authority management method for managing data processing authority in a user device that executes a service provided by a service provider,
As an execution step in the service provider,
The stored data includes an encryption execution instruction including an encrypted data processing execution instruction, and address (Ad) information indicating a storage area of a memory in the user device of a registration key applied to the decryption processing of the encryption execution instruction. Providing an execution attribute certificate having as a user device which is a service receiving device,
As an execution step in the user device,
Obtaining a registration key from the memory of the user device according to the address (Ad) information stored in the execution attribute certificate;
Executing the decryption of the encrypted execution instruction stored in the execution attribute certificate by applying the obtained registration key;
Performing data processing based on the decryption result;
And a data processing authority management method.
[0032]
Further, in one embodiment of the data processing authority management method of the present invention, the execution attribute certificate has an issuer electronic signature for stored data including the encrypted execution instruction and the address (Ad) information, The user device executes a digital signature verification process of the execution attribute certificate, and executes a registration key acquisition process according to the address (Ad) information on condition that the verification is established.
[0033]
Further, in one embodiment of the data processing authority management method according to the present invention, in the data processing authority management method, the process of issuing a new execution attribute certificate to the user device includes the step of: Receiving, from the issuance requesting user device, a group attribute certificate having group identification information set corresponding to a group consisting of a specific device or a set of specific users as storage information and having an issuer electronic signature; The verification of the certificate is performed, and the verification is performed on condition that the verification is established.
[0034]
Further, in one embodiment of the data processing authority management method of the present invention, the data processing authority management method further includes, as an execution step in the service provider, acquiring registration key storage scheduled address information from the user device; A data part having the registration key storage scheduled address information, an encryption execution instruction obtained by encrypting the registration key storage instruction by applying a key obtainable by a user device, and a registration key including an electronic signature for the data part Generating a generation execution attribute certificate and providing it to the user device, wherein the execution steps in the user device include verification of the electronic signature, and an encryption execution instruction stored in the registration key generation execution attribute certificate. Decryption and processing of the execution instruction acquired by decryption, the registration key is stored in the registration key storage address. And having a processing step of storing in the corresponding memory region.
[0035]
Further, in one embodiment of the data processing authority management method of the present invention, the data processing authority management method further includes a step of generating the registration key based on a random number as an execution step in the user device. And
[0036]
Further, in one embodiment of the data processing authority management method according to the present invention, the user device further registers the registration key storage area by writing reset key data to a memory area corresponding to the specified address (Ad). A key destruction process is performed.
[0037]
Further, in one embodiment of the data processing authority management method of the present invention, the encryption execution instruction stored in the execution attribute certificate stores an identification number of the number of times the execution instruction can be applied, and the user device executes the execution instruction. The method is characterized in that the applicable number identification value is updated in accordance with the execution of the instruction, and a new execution attribute certificate including the updated applicable number identification value is generated.
[0038]
Further, in one embodiment of the data processing authority management method of the present invention, the encryption execution instruction stored in the execution attribute certificate stores an identification number of the number of times the execution instruction can be applied, and the user device executes the execution instruction. The applicable number identification value is updated in accordance with the execution of the instruction, and when the updated applicable number identification value becomes 0, the memory area corresponding to the address (Ad) specifying the registration key storage area The registration key is destroyed by writing the reset key data to the register key.
[0039]
Further, in one embodiment of the data processing authority management method of the present invention, the encryption execution instruction stored in the execution attribute certificate includes a generation processing instruction of an execution attribute certificate for transfer to another device, The device executes a process for generating a new execution attribute certificate for transfer in accordance with the instruction for a process for generating an attribute certificate for transfer, and executes a process for providing it to another device.
[0040]
Further, in one embodiment of the data processing authority management method of the present invention, the encryption execution instruction stored in the execution attribute certificate includes the issuance of a screening proxy attribute certificate as a certificate certifying the attribute of another device. A processing command, and a signature generation key required for generating the screening proxy attribute certificate, wherein the user device applies the signature generating key according to the screening proxy attribute certificate issuing Is performed to generate a screening proxy attribute certificate, and to provide the service to another service receiving device.
[0041]
Further, in one embodiment of the data processing authority management method of the present invention, the user device that has executed the generation of the screening proxy attribute certificate is provided with the provision of the screening proxy attribute certificate to the other service receiving device. Storing a signature verification key corresponding to the signature generation key, providing a proxy signature key certificate having an issuer signature, and providing the other service receiving device with the service providing entity, A certificate and a proxy signing key certificate are presented, and the service providing entity is configured to execute verification processing of the examination proxy attribute certificate based on a signature verification key obtained from the proxy signing key certificate. It is characterized by.
[0042]
Further, in one embodiment of the data processing authority management method of the present invention, the encryption execution instruction stored in the execution attribute certificate includes issuing a proxy signature attribute certificate as a certificate certifying the attribute of another device. A processing instruction and a signature generation key required for generating the proxy signature attribute certificate, wherein the user device executes the proxy signature attribute certificate verification according to the proxy signature attribute certificate issuance processing instruction Generating a proxy signature attribute certificate including a verification random number (Ra) received from the verification device to be executed and having a signature to which the signature generation key is applied, and generating the proxy signature attribute certificate and the signature generation A signature verification key corresponding to the verification key is stored, and a process of presenting a proxy signing key certificate having an issuer signature to a service providing entity as a verification device is executed. The service providing entity performs a signature verification based on the signature verification key obtained from the proxy signature key certificate and a verification process of the proxy signature key certificate by random number collation extracted from an execution instruction of the proxy signature attribute certificate. It is characterized by executing.
[0043]
Further, a fourth aspect of the present invention provides
An information processing method in an information processing apparatus that performs data processing,
An encryption execution instruction including an encrypted data processing execution instruction, and address (Ad) information indicating a storage area in a memory in the information processing device of a registration key to be applied to the decryption processing of the encryption execution instruction. Inputting an execution attribute certificate which is stored data and signed by an issuer;
Executing a signature verification process and obtaining a registration key from the memory in accordance with the address (Ad) information, provided that the signature verification is established;
Decrypting the encryption execution instruction by applying the obtained registration key;
A data processing step for executing the decrypted execution instruction;
An information processing method comprising:
[0044]
Further, in one embodiment of the information processing management method according to the present invention, in the information processing method, the registration is performed by writing reset key data to a memory area corresponding to an address (Ad) that specifies the registration key storage area. The method has a step of executing a key destruction process.
[0045]
Further, in one embodiment of the information processing management method of the present invention, the encryption execution instruction stored in the execution attribute certificate stores an identification number of the number of times that the execution instruction can be applied. And updating the applicable number identification value according to the execution of the execution instruction, and generating a new execution attribute certificate including the updated applicable number identification value.
[0046]
Further, in one embodiment of the information processing management method of the present invention, the encryption execution instruction stored in the execution attribute certificate stores an identification number of the number of times that the execution instruction can be applied. And updating the applicable number identification value according to the execution of the execution instruction, and when the updated applicable number identification value becomes 0, it corresponds to the address (Ad) specifying the registration key storage area. It is characterized in that the registration key is destroyed by writing the reset key data in the memory area.
[0047]
Further, in one embodiment of the information processing management method of the present invention, the encryption execution instruction stored in the execution attribute certificate includes a generation processing instruction of an execution attribute certificate for transfer to another device, The method is further characterized in that, in accordance with the transfer execution attribute certificate generation processing instruction, the transfer execution attribute certificate generation processing is performed, and the provision processing to another device is performed.
[0048]
Further, in one embodiment of the information processing management method of the present invention, the encryption execution instruction stored in the execution attribute certificate includes a process of issuing an examination proxy attribute certificate as a certificate for certifying the attribute of another device. Instructions, and a signature generation key required for generation of the screening proxy attribute certificate. The information processing method further includes applying the signature generating key according to the screening proxy attribute certificate issuing processing command. And performing a process of generating a screening proxy attribute certificate that has been signed.
[0049]
Further, in one embodiment of the information processing management method of the present invention, the encryption execution instruction stored in the execution attribute certificate includes a process of issuing a proxy signature attribute certificate as a certificate certifying the attribute of another device. Instructions, and a signature generation key required for generation of the proxy signature attribute certificate. The information processing method further includes verifying the proxy signature attribute certificate in accordance with the proxy signature attribute certificate issuance processing instruction. The verification random number (Ra) received from the verification device that executes the above is stored as storage data, and a proxy signature attribute certificate generation process having a signature to which the signature generation key is applied is executed.
[0050]
Furthermore, a fifth aspect of the present invention provides
A computer program for executing information processing in an information processing apparatus that executes data processing,
An encryption execution instruction including an encrypted data processing execution instruction, and address (Ad) information indicating a storage area in a memory in the information processing device of a registration key to be applied to the decryption processing of the encryption execution instruction. Inputting an execution attribute certificate which is stored data and signed by an issuer;
Executing a signature verification process and obtaining a registration key from the memory in accordance with the address (Ad) information, provided that the signature verification is established;
Decrypting the encryption execution instruction by applying the obtained registration key;
A data processing step for executing the decrypted execution instruction;
A computer program characterized by having:
[0051]
[Action]
According to the configuration of the present invention, an encryption execution instruction including an encryption-executed data processing execution instruction and an address indicating a storage area of a memory in the user device of a registration key applied to the decryption processing of the encryption execution instruction ( Ad) providing an execution attribute certificate having information as storage data to a user device which is a service receiving device, and in the user device, according to the address (Ad) information stored in the execution attribute certificate, a memory of the user device By applying the registration key obtained from, the encryption execution instruction stored in the execution attribute certificate is decrypted and the data processing is executed based on the decryption result, so the registration key is stored in the execution attribute certificate It is possible to execute the execution instruction stored in the execution attribute certificate only in a user device that can be obtained according to the address, Providing strictly limited service to users having-bis use authority can be performed.
[0052]
Further, according to the configuration of the present invention, since the storage of the registration key applied to the service providing execution attribute certificate is executed in accordance with the registration key generation execution attribute certificate, the storage of the unauthorized registration key is prevented, Service reception can be reliably prevented.
[0053]
Furthermore, according to the configuration of the present invention, since the registration key is destroyed by writing the reset key, it is possible to prevent unauthorized registration key from being held.
[0054]
Further, according to the configuration of the present invention, the applicable number identification value is stored in the execution instruction, the applicable number identification value is updated according to the execution of the execution instruction, and the updated applicable number identification value is included. Since the configuration is such that a new execution attribute certificate is generated, it is possible to execute the reception of a service with a limited number of usages under a certain number of times.
[0055]
Further, according to the configuration of the present invention, various execution instructions such as a transfer execution attribute certificate generation processing instruction, a screening proxy attribute certificate issuance processing instruction, and a proxy signature attribute certificate issuance processing instruction are executed. By storing the attribute certificate in a certificate, various usage forms of the attribute certificate are realized.
[0056]
The computer program of the present invention is provided, for example, in a computer-readable format for a computer system capable of executing various program codes, in a storage medium or communication medium provided in a computer-readable format, such as a CD, FD, or MO. It is a computer program that can be provided by a recording medium or a communication medium such as a network. By providing such a program in a computer-readable format, processing according to the program is realized on a computer system.
[0057]
Further objects, features, and advantages of the present invention will become apparent from the following detailed description based on embodiments of the present invention and the accompanying drawings. In this specification, the term “system” refers to a logical set of a plurality of devices, and is not limited to a device having each configuration in the same housing.
[0058]
BEST MODE FOR CARRYING OUT THE INVENTION
Hereinafter, the present invention will be described in detail with reference to the drawings. Hereinafter, the description will be made in the order of the following items.
(1) Outline of authority management system configuration
(2) User device configuration
(3) Issuing and using group attribute certificate
(3-1) Preparation process before issuing a group attribute certificate
(3-2) Group attribute certificate issuance processing
(3-3) Group attribute certificate use processing
(4) Issuing and using group attribute certificates between user devices
(5) Specific usage example of group attribute certificate
(5-1) Content distribution service
(5-2) Remote control service
(5-3) Remote maintenance service
(5-4) Personal communication service
(6) Execution attribute certificate (execution AC)
(6-1) Outline of execution attribute certificate
(6-2) Execution attribute certificate issuance processing
(6-3) Execution attribute certificate application processing
(6-4) Registration key reset processing
(6-5) Execution attribute certificate reset (discard) processing
(7) Specific use process of execution attribute certificate
(7-1) Attribute certificate for service provision execution with limited number of times
(7-2) Service providing execution attribute certificate with transfer function
(7-3) Attribute certificate for execution by proxy
(8) Composition of each entity
[0059]
[(1) Outline of authority management system]
As shown in FIG. 1, the authority management system of the present invention is based on a public key infrastructure (PKI) 101 based on a public key certificate (PKC) 121 and an authority management 122 based on an attribute certificate (AC: Attribute certificate) 122. A base (PMI: Privacy management Infrastructure) 102 is used as a basic infrastructure. Under these infrastructures, between user devices 111 and 113 having a tamper-resistant security chip (or security module) and service provider devices 112 on the service provider side, or between users Execute authority confirmation processing between the devices 111 and 113 and confirm authority It has a configuration to execute a service providing processing based.
[0060]
The user devices 111 and 113 are, for example, terminals of users who receive various content providing services such as music, images, programs, and the like, other information use services, and payment services from the service provider 112. Are a PC, a game terminal, a playback device such as a DVD and a CD, a portable communication terminal, a PDA, a memory card, and the like.
[0061]
The user devices 111 and 113 are terminals capable of executing communication processing between the user devices, and execute processing such as access permission / prohibition for each user device based on authority confirmation. The user device is equipped with a tamper-resistant security chip. Details of the user device will be described later.
[0062]
The service provider 112 is a service provider that provides various services such as content provision and payment processing to the user devices 111 and 113 each having a security chip. FIG. 1 shows only two user devices and only one service provider. Under the infrastructure of a public key infrastructure (PKI) 101 and an authority management infrastructure (PMI) 102, a large number of user devices and service providers are provided. Exist, each of which performs service provision based on authority confirmation. It should be noted that the service is provided not only by the service provider to the user devices but also between the user devices.
[0063]
(Public key certificate: PKC)
Next, the public key infrastructure will be described. A public key infrastructure (PKI: Public Key Infrastructure) 101 is an infrastructure (infrastructure) that can execute authentication processing between communication entities or encryption processing of transfer data by applying a public key certificate (PKC: Public Key Certificate). (Public key certificate (PKC)) will be described with reference to FIGS. 2, 3, and 4. FIG. The public key certificate is a certificate issued by a certification authority (CA), and the user and each entity submit their own ID, public key, etc. to the certificate authority, and the certificate authority determines the ID of the certificate authority. This is a certificate created by adding information such as a certificate and an expiration date, and further adding a signature by a certificate authority.
[0064]
A Registration Authority (RA) is established as an administrative agency of the Certification Authority (CA), and the Registration Authority (RA) is responsible for accepting applications for issuance of public key certificates (PKCs), examining and managing applicants. The configuration to perform is common.
[0065]
Examples of the format of the public key certificate are shown in FIGS. This is the public key certificate format ITU-TX. 509 is an example.
[0066]
The version indicates the version of the certificate format.
The serial number is a serial number of a public key certificate set by a public key certificate authority (CA).
Signature is the signature algorithm of the certificate. Note that the signature algorithm includes elliptic curve cryptography and RSA. When elliptic curve cryptography is applied, parameters and key length are recorded, and when RSA is applied, key length is recorded.
The issuer (issuer) is a field in which the name of the issuer of the public key certificate, that is, the name of the public key certificate issuing authority (IA) is recorded in an identifiable format (Distinguished Name).
The expiration date (validity) records the start date and time and the end date and time that are the expiration dates of the certificate.
In the subject public key information (subject Public Key Info), a key algorithm and a key are stored as public key information of the certificate owner.
[0067]
The certificate authority key identifier (authority key identifier-key identifier, authority certificate issuer, and authority certificate serial number) is information for identifying the key of the certificate issuer used for signature verification, and includes the key identifier and the name of the institution certificate issuer. , Store the institution certificate serial number.
The subject key identifier (subject key Identifier) stores an identifier for identifying each key when a plurality of keys are certified in a public key certificate.
The key usage purpose (key usage) is a field for designating the usage purpose of the key, and is used for (0) digital signature, (1) non-repudiation prevention, (2) key encryption, and (3) message encryption. , (4) common key delivery, (5) authentication signature confirmation, and (6) revocation list signature confirmation are set.
The private key validity period (private Key Usage Period) records the validity period of the private key corresponding to the public key stored in the certificate.
The Certificate Authority Policies records the certificate issuing policy of the public key certificate issuer. For example, a policy ID and an authentication standard based on ISO / IEC9384-1.
Policy mapping is a field for storing information related to restrictions on policy relations in a certification path, and is required only for a certificate authority (CA) certificate.
The subject alternative name (subject Alt Name) is a field for recording the alternative name of the certificate owner.
The issuer alias (issuer Alt Name) is a field for recording the alias of the certificate issuer.
The subject directory attribute (subject Directory Attribute) is a field for recording a directory attribute required for the certificate holder.
The basic constraint is a field for distinguishing whether the public key to be certified is for the signature of a certificate authority (CA) or the certificate owner.
The allowable subtree constraint name (name Constraints permitted Subtrees) is a field for storing restriction information on the name of a certificate issued by the issuer.
A constraint policy (policy constraints) is a field for storing restriction information of a policy relationship in a certification path.
The CRL reference point (Certificate Revocation List Distribution Points) is a field that describes a reference point of a revocation list for checking whether a certificate has been revoked when a certificate holder uses the certificate. is there.
The signature algorithm (Signature Algorithm) is a field for storing an algorithm used for signing a certificate.
The signature is the signature field of the public key certificate issuer. The electronic signature is data generated by applying a hash function to the entire certificate, generating a hash value, and using the hash value with the private key of the issuer. Although tampering is possible only by adding a signature or hash, if it can be detected, there is an effect similar to the fact that tampering cannot be performed substantially.
[0068]
The certificate authority issues the public key certificate shown in FIGS. 2 to 4, renews the expired public key certificate, and revocation list (Revocation List) for rejecting an illegal user. ) Is created, managed, and distributed (this is called Revocation). Further, a public key and a secret key are generated as needed.
[0069]
On the other hand, when using this public key certificate, the user verifies the electronic signature of the public key certificate by using the public key of the certificate authority held by the user, and after the verification of the electronic signature succeeds, The public key is extracted from the key certificate, and the public key is used. Therefore, all users who use the public key certificate need to hold a common certificate authority public key.
[0070]
(Attribute certificate: AC)
An authority management infrastructure (PMI: Privacy management Infrastructure) 102 is an infrastructure (infrastructure) that can execute an authority confirmation process to which an attribute certificate (AC: Attribute certificate) 122 is applied. A group attribute certificate (group AC) as one form of the attribute certificate will be described with reference to FIGS. The function of the attribute certificate is a function of confirming the right to use the service, and the attribute certificate describes, for example, content provided by the service provider, or right-related information such as the right to use the service and attribute information of the owner regarding the right. You.
[0071]
An attribute certificate is basically a certificate issued by an attribute authority (AA), stores attribute information to be issued, and the attribute certificate authority adds information such as ID and expiration date. The certificate is created by adding a signature using the private key of the attribute certificate authority. However, the group attribute certificate and the execution attribute certificate described below are not necessarily limited to an attribute authority (AA: Attribute Authority) as an issuing authority, and can be issued by a service provider or a user device. .
[0072]
Note that an attribute certificate registration authority (ARA) is provided as an administrative agency of the attribute certificate authority (AA), and the attribute certificate registration authority (ARA) accepts application for issuance of an attribute certificate (AC). The configuration for conducting the examination and management of the applicant makes it possible to distribute the processing load.
[0073]
The group attribute certificate (group AC) applied in the configuration of the present invention is set as a group in which a plurality of objects, for example, a plurality of users or a plurality of user devices are set to one and the same attribute set, and the set group is set as a unit. Is an attribute certificate issued to a constituent device or a constituent user of the group. The group attribute certificate is a certificate to which group identification information set corresponding to a group consisting of a specific device or a specific user set is stored and to which an electronic signature of an issuer is added.
[0074]
For example, it is issued to each user or user device belonging to an attribute such as a company, an organization, a school to which a plurality of persons belong, or a group such as a family. Alternatively, it is issued to a group member (user, user equipment) such as a plurality of user units that receive a service provided by one service provider. Various settings are possible for the group, and specific examples will be described later.
[0075]
The execution attribute certificate to be described later includes an encryption execution instruction including an encrypted data processing execution instruction, and a storage of a registration key applied to decryption processing of the encryption execution instruction in a memory in the user device. And address (Ad) information indicating the area as storage data. The details of the execution attribute certificate will be described later in detail.
[0076]
The basic format of the attribute certificate is ITU-TX. 509, and the IETF PKIX WG defines a profile. Unlike a public key certificate, it does not include the owner's public key. However, it is similar to the public key certificate in that a signature of an attribute certificate authority (Attribute Certificate Authority) is attached, so that it is possible to determine whether or not falsification has been performed by verifying the signature.
[0077]
Note that the group attribute certificate or the execution attribute certificate applied in the present invention can be configured as conforming to the basic format of the attribute certificate. However, ITU-TX. It is not essential to follow the format specified in 509, and an attribute certificate configuration in a unique format may be used.
[0078]
In the configuration of the present invention, the function of an attribute certificate authority (AA) for performing issuance management of an attribute certificate (AC) and the function of an attribute certificate registration authority (ARA) are shared by a service provider or a user device. It is possible to do. That is, a configuration is possible in which the service provider or the user device itself performs the functions of the attribute certification authority (AA) and the attribute certificate registration authority (ARA).
[0079]
Attribute certificates are basically used in association with public key certificates. That is, the identity of the owner of the attribute certificate itself is confirmed by the public key certificate, and then the authority to which the owner has been given is confirmed by the attribute certificate. For example, when a service provider provides a service to a user or a user device, the attribute certificate is verified to confirm whether or not the service provider has a right to receive the service. In verifying the attribute certificate, the signature of the certificate is verified, and then the public key certificate associated with the attribute certificate is also verified.
[0080]
In this case, in principle, it is preferable to perform the verification in order up to the highest public key certificate by following the certificate chain in principle. In a certificate authority configuration in which a plurality of certificate authorities (CA) exist and have a hierarchical configuration, a public key certificate of a lower certificate authority itself is signed by an upper certificate authority that issues the public key certificate. In other words, a public key certificate issuance configuration is adopted in which a higher-level certificate authority (CA-High) issues a public key certificate to a lower-level certificate authority (CA-Low). Chain verification of a public key certificate refers to a chain of certificates from a lower level to an upper level, and obtains chain information from the highest public key certificate to the highest public key certificate (the root CA). Verification of the signature.
[0081]
By setting the validity period of the attribute certificate to a short period, the revocation processing can not be performed. In this case, there is an advantage that the system can be simplified because the certificate revocation procedure and the revocation information reference procedure can be omitted. However, due care must be taken against unauthorized use of certificates, as some measure other than revocation is required.
[0082]
The configuration of the group attribute certificate will be described with reference to FIG.
The certificate version number indicates the version of the certificate format.
The public key certificate information of the AC holder, which is information on the public key certificate (PKC) corresponding to the issuer of the attribute certificate (AC), and includes the PKC issuer name, PKC serial number, and PKC issuer unique identifier. And has a function as link data for associating the corresponding public key certificate.
The name of the issuer of the attribute certificate is a field in which the name of the issuer of the attribute certificate, that is, the name of the attribute certificate authority (AA) is recorded in a identifiable form (Distinguished Name).
The signature algorithm identifier is a field for recording the signature algorithm identifier of the attribute certificate.
As the expiration date of the certificate, the start date and time and the end date and time, which are the expiration dates of the certificate, are recorded.
In the attribute information field, a group ID is stored as group identification information for identifying a group of the group attribute certificate. The group ID is an identifier (ID) corresponding to an entry in the service provider (SP) management group information database (see the lower right column in FIG. 5) of the service provider that performs authority confirmation using the group attribute certificate.
[0083]
As shown in the lower right column of FIG. 5, the service provider (SP) management group information database of the service provider includes, for example, an issuer (ARA) of a group attribute certificate and group identification information (group ID) as a group identifier. , And a table in which group information such as “employee of A person” and “family of B” is associated. In the authority confirmation processing based on the group certificate, the service provider extracts the corresponding entry from the table based on the group identification information (group ID) as the certificate storage data, and acquires the group attribute certificate information including the group information. .
[0084]
In the attribute information field, various information can be stored in addition to the group identification information (group ID). For example, detailed information on authority such as content usage restriction information such as content usage expiration date, service usage restriction information, etc. Further, various information such as a service provider identifier (ID) and a service provider name can be stored. As will be described later in detail, the present invention can also be applied as a field for storing information necessary for acquiring a content key to be applied to decrypting encrypted content.
[0085]
The service provider sends the group attribute certificate to the user device, and after verifying the attribute certificate, the user device stores it in a memory in its own security chip.
[0086]
The attribute certificate further records a signature algorithm, and is signed by an attribute certificate issuer, for example, an attribute certificate authority (AA). If the publisher is a service provider or a user device, each publisher is signed. The electronic signature is data generated by applying a hash function to the entire attribute certificate to generate a hash value and using the secret value of the attribute certificate issuer for the hash value.
[0087]
FIG. 6 shows a configuration example of the issuer, owner, verifier, and attribute information of the group attribute certificate (group AC). For example, when a group attribute certificate is issued for each of a plurality of user device groups owned by a user belonging to the same company or one family, the issued group attribute certificate is stored in a device owned by the user. Is stored in a security chip (SC: Security Chip or USC: User Security Chip). Details of the user device will be described later.
[0088]
A verifier that performs authority confirmation based on the group attribute certificate issued to the user device is a service providing entity, for example, a security module (SM) in a device of a service provider, or a security chip of the user device. (SC: Security Chip). It is preferable that the security chip of the user device and the security module in the device of the service provider have a tamper-resistant configuration in which data reading from outside is restricted.
[0089]
The group attribute certificate has, for example, group identification information (group ID) as identification information that can identify the same company or one family as attribute information.
[0090]
FIG. 7 shows a configuration example of the issuance policy table of the group attribute certificate. The issuance policy table of the group attribute certificate includes an entity that issues the group attribute certificate, for example, an attribute certificate authority (AA) and an attribute certificate authority (ARA: Attribute Registration Authority) or a table managed by the service provider and the user device, and is a table in which issuance policies such as group identification information (group ID) of the issued group attribute certificate, group information, and issuance criteria are associated. is there. For example, when new, additional, or renewal processing of a group attribute certificate is performed, examination is performed based on the issuance policy table of the group attribute certificate, and only when the policy is satisfied, procedures for issuance and renewal are performed. Done.
[0091]
FIG. 8 shows a trust model for explaining the trust relationship configuration of each entity participating in the authority management system.
[0092]
A system holder (SH) 130 is a subject that performs overall management of the entire authority management system of the present invention, that is, a system operation subject, and a security chip (SC) and a security module (SM) of each entity participating in the system. ), And is responsible for issuing public key certificates (PKC). The system holder (SH) 130 includes a root CA (RootCA) 131 as a top-level certificate authority, a plurality of certificate authorities (CA) 132 in a hierarchical configuration, and a registration authority (RA) 133 as a public key certificate issuing office. Have.
[0093]
A system holder (SH: System Holder) 130 includes an attribute certificate authority (AA) 140, an attribute certificate registration authority (ARA) 150, a service provider 160, and a user identification device (UID: User Identification Device) 171 as a user device 170. Issues a public key certificate (PKC) corresponding to each entity of an end entity (EE: End Entity) 172. The public key certificate (PKC) is stored in a security chip (SC) or a security module (SM) having, or in some cases, an external storage device.
[0094]
In addition, the group attribute certificate (group AC) is transmitted from the service provider 160 and each entity of the user identification device (UID: User Identification Device) 171 as the user device 170, the end entity (EE: End Entity) 172, and the like. The attribute certificate issuance request is received, for example, at the attribute certificate registration authority (ARA) 150, and the attribute certificate issuance examination is performed in accordance with the policy (issuing conditions and the like) of the policy table 151 described above with reference to FIG. If it is determined that the issuance is permitted, an issuance request is transferred from the attribute certificate authority (ARA) 150 to the attribute certificate authority (AA) 140.
[0095]
The attribute certificate authority (AA) 140 stores group identification information (group ID) as attribute information based on the group attribute certificate issuance request, and adds a signature using the secret key of the attribute certificate authority (AA) 140 to the group attribute. A certificate (see FIG. 5) is issued to the requester.
[0096]
As described above, the attribute certificate authority (AA) 140 and the attribute certificate registration authority (ARA) 150 may be configured so that a service provider or a user device executes the function.
[0097]
[(2) User device configuration]
Next, the configuration of a user device as an information processing apparatus using a service will be described. User devices are classified into two categories based on their functions. One is an end entity (EE) as a device that actually uses the service. For example, a PC, a home server, a portable terminal such as a PDA, an IC card, etc. having an interface for receiving service information provided by a service provider are provided. It is a data processing device. These devices include a security chip (SC) or a module (SM) having a tamper-resistant configuration, and store a public key certificate corresponding to the device and a group attribute certificate corresponding to the device as necessary.
[0098]
The other is a user identification device (UID) as a device applied to personal authentication processing. The user identification device (UID) is also configured by the same device as the end entity, but is a device that does not necessarily have an interface for directly receiving service information provided by a service provider. Communication with the service provider device is performed via an end entity (EE). A user identification device (UID) is a device applied for user authentication. These devices have a security chip (SC) or a security module (SM) having a tamper-resistant configuration, and store a public key certificate for a user and a group attribute certificate for a device as necessary.
[0099]
Note that the end entity (EE) and the user identification device (UID) can be configured as individual devices, respectively, but it is also possible to configure both devices in one device.
[0100]
As a specific configuration specific example, for example, there is a configuration in which a device such as an IC card is configured as a user identification device (UID) and the end entity (EE) is a PC. In this configuration, the IC card is set in a state in which data can be transferred to the PC, and communication between the IC card and the service provider is first executed via the PC to perform user authentication using a public key certificate and a group attribute certificate. Then, the user authority confirmation process is executed, and after these processes, processes such as authentication and authority confirmation between the PC and the service provider as the end entity can be executed. The details of these authority confirmation processes will be described later.
[0101]
An example of the configuration of a security chip configured by an end entity (EE) as a user device and a user identification device (UID) will be described with reference to FIG. The end entity (EE) includes a CPU as a data processing means, a PC having a communication function, such as a PC, a game terminal, a portable terminal, a PDA, an IC card (memory card), a DVD, a CD, etc., and a recording / reproducing device. A security chip (SC) configured by a device or the like and having a tamper resistant structure is mounted.
[0102]
As shown in FIG. 9, in the user device 200 including the end entity (EE) or the user identification device (UID), the security chip 210 can mutually transfer data to the user device side control unit 221. Built-in as a simple configuration.
[0103]
The security chip 210 includes a CPU (Central Processing Unit) 201 having a program execution function and an arithmetic processing function, a communication interface 202 having an interface function for data communication, and various programs executed by the CPU 201, for example, an encryption processing program. (Read Only Memory) 203 for storing a program, a RAM (Random Access Memory) 204 functioning as a load area for an execution program and a work area in each program processing, an authentication process with an external device, a generation of a digital signature, and a verification process , An encryption processing unit 205 that performs encryption processing such as encryption and decryption processing of stored data, and stores information specific to each service provider and device-specific information including various key data. Having constituted the memory unit 206 by the PROM (Electrically Erasable Programmable ROM).
[0104]
The user device 200 includes an external memory unit 222 including an EEPROM, a hard disk, and the like as an area for storing encrypted content, service information, and the like. The external memory unit 222 can also be used as a storage area for a public key certificate and a group attribute certificate.
[0105]
When the user device equipped with the security chip connects to an external entity, for example, a service provider and executes data transfer processing, the user device connects to the service provider via the network interface 232. However, it is the end entity (EE) that has the interface for executing the connection with the service provider as described above, and the user identification device (UID) does not always have the network interface 232. It connects to the connection device interface 231 of the end entity (EE) via the connection device interface 231 of the identification device (UID), and executes communication via the network interface 232 of the end entity.
[0106]
That is, the user identification device (UID) performs communication with the service provider device via the end entity.
[0107]
When data transfer is performed between the service chip and the security chip 210 of a user device such as an end entity (EE) or a user identification device (UID), mutual communication between the security chip 210 and an external entity may be performed as necessary. Authentication is performed, and encryption of the transfer data is performed. Details of these processes will be described later.
[0108]
FIG. 10 shows an example of data stored in the security chip of the user device. Many of these are stored in a memory unit 206 constituted by an EEPROM (Electrically Erasable Programmable ROM) such as a flash memory, which is a form of a nonvolatile memory. The execution attribute certificate may be stored in a memory in the security chip or in an external memory.
[0109]
Each data will be described.
Public key certificate (PKC): A public key certificate is a certificate that indicates to a third party that it is a legitimate public key. An electronic signature has been made. When the user device performs data communication with the user device, such as the public key certificate of the highest-order certificate authority (root CA) in the hierarchical configuration described above, the public key certificate of a service provider that provides services to the user device, and the like. A public key certificate required to obtain a public key applied to authentication, encryption, decryption processing, and the like is stored.
[0110]
Group attribute certificate (AC): A public key certificate indicates the "identity" of a certificate subscriber (owner), while a group attribute certificate identifies a group of certificate subscribers and constitutes a member of the group This is to confirm the use authority given to. By presenting the group attribute certificate, the user can use the service based on the right / right information described in the group attribute certificate. Note that the group attribute certificate is issued based on a predetermined issuing procedure, and each entity that receives the group attribute certificate is a security chip (SC) or security module (SM) having a tamper-resistant configuration in the device, or Some are stored in an external storage device. Details of the issuing and storing processes will be described later.
[0111]
Execution attribute certificate: an address (Ad) indicating the storage area of the memory in the user device of the encryption execution instruction including the encrypted data processing execution instruction and the registration key applied to the decryption processing of the encryption execution instruction. Is an attribute certificate having information as storage data, based on the address information, applying a registration key obtained from the memory in the user device, decrypting the encrypted execution instruction, obtaining the execution instruction, and executing the execution instruction. Various services are thus executed. Details of these processes will be described later.
[0112]
Key data: a pair of a public key and a secret key set for the security chip, a registration key applied when decrypting the encryption execution instruction stored in the above-described execution attribute certificate, a registration key , A reset key applied to the discarding (reset) process, a random number generation key, a mutual authentication key, and the like. The storage area for the registration key is stored in a memory area determined by a predetermined address. The registration key and the reset key will be described later in detail.
[0113]
Identification information: As the identification information, a security chip ID as an identifier of the security chip itself is stored. Further, a service provider ID as an identifier of a service provider (SP) that receives continuous service provision, a user ID assigned to a user using a user device, an application ID for identifying an application corresponding to a service provided by the service provider, and the like. Can be stored.
[0114]
Others: The user device is further provided with seed information for generating random numbers, that is, information for generating random numbers applied in authentication processing, encryption processing, and the like according to ANSI X9.17, and various usage restrictions. Stores usage information related to the service, for example, content usage count information updated when using content with content usage limit added, or information such as payment information, or a hash value calculated based on each information. Is done.
[0115]
Note that the data configuration example shown in FIG. 10 is an example, and other various types of information related to the service received by the user device can be stored as needed.
[0116]
Note that, for example, a security chip or a security module possessed by a service provider on the service providing side can also be realized by a configuration similar to the security chip configuration of the user device shown in FIG. , Generation processing, or execution attribute certificate verification processing and generation processing. For example, as a means for executing a process of verifying a group attribute certificate or an execution attribute certificate received via a network interface which is a data transmission / reception unit, or a process of generating a group attribute certificate or an execution attribute certificate, FIG. The same configuration as the security chip shown in FIG.
[0117]
[(3) Group attribute certificate issuance and use processing]
Next, a plurality of users or devices, such as users belonging to various groups such as an organization such as the same school or company, or one family, or devices of the same maker, users who receive services of the same service provider, or devices. Will be described as a group, and a process of issuing and using a group attribute certificate issued to each of the users or devices belonging to the group will be described.
[0118]
The group attribute certificate is a certificate that can confirm that a user or a device (user device) who wants to receive a service belongs to a specific group, and is presented to a service providing entity, for example, a service provider when a service is received. I do. The service provider performs a verification process of the presented group attribute certificate, and provides a service on condition that the user or the user device is confirmed to belong to a specific group.
[0119]
The group attribute certificate is a certificate having group identification information set corresponding to a group consisting of a specific device or a specific user set as storage information and having an electronic signature of the issuer.
[0120]
FIG. 11 is a diagram for explaining an outline of the flow of the issuance application, issuance processing, and use processing of the group attribute certificate. A user device 311 that wants to receive a service provided by a service provider 314 that provides a service on condition of confirming a group belonging certificate based on a group attribute certificate, that is, an end entity (EE) having a security chip or a user identification First, the device (UID) issues an issuance request to the issuance entity of the group attribute certificate. For example, a request for issuance of a group attribute certificate is made to an attribute certificate registration authority (ARA: Attribute Registration Authority) 312.
[0121]
The attribute certificate registration authority (ARA) 312 refers to the issuance policy table 313 based on the issuance application, and if the policy is satisfied, the attribute certificate authority (AA) notifies the attribute certificate authority (AA) of the attribute certificate. Request issuance, and transmit the group attribute certificate 316 issued by the attribute certificate authority (AA) to the user device 311.
[0122]
In the group attribute certificate 316, a group ID as a group identifier is stored in an attribute information field (see FIG. 5). The user device 311 presents the group attribute certificate 316 to the service provider 314 when receiving a service provided by the service provider 314, for example, any service such as content distribution and settlement processing. The service provider 314 determines whether or not the user device 311 that has requested service provision has the right to receive the service by verifying the group attribute certificate and referring to the group information database 315, and determines that the user device 311 has the right. In this case, the service is provided to the user device 311.
[0123]
In the following, regarding the group attribute certificate issuance and use processing,
(3-1) Preparation process before issuing a group attribute certificate
(3-2) Group attribute certificate issuance processing
(3-3) Group attribute certificate use processing
The above three items will be sequentially described.
[0124]
(3-1) Preparation process before issuing a group attribute certificate
First, the preparation process before issuance of a group attribute certificate will be described. As described above, the group attribute certificate is basically issued by the attribute certificate authority (AA), and the attribute certificate registration authority (ARA) receives the issuance request from the attribute certificate issuance request entity and sets the policy. After performing an examination and determining that the attribute certificate can be issued, the attribute certificate issuing request is transferred to the attribute certificate authority (AA), and the attribute certificate issued by the attribute certificate authority (AA) is transferred to the attribute certificate authority (ARA). ) Is sent in a normal style to the issue request entity. However, as described below, it is also possible for the service provider (SP) and the user device to issue under the respective policies.
[0125]
The group attribute certificate of the present invention is issued to a group member (equipment or user) after specifying a group that can be identified, for example, a family, a school, a company, or a device of a specific manufacturer. On the other hand, the service provider that provides the service determines whether the user or device that has requested the service belongs to a specific group based on the group attribute certificate. Therefore, the entity for issuing the group attribute certificate and the entity for executing the authority confirmation (verification process) based on the group attribute certificate and providing the service are common to the group defined corresponding to the group attribute certificate. If it is necessary to have the recognition, the process of sharing the information on the group defined corresponding to the group attribute certificate, that is, the group information between the group attribute certificate issuing entity and the service providing entity is performed by the group attribute certificate. This is required as a pre-issue issue preparation process.
[0126]
The group information sharing process when the group attribute certificate issuing entity is the attribute certificate authority (AA) or the attribute certificate registration authority (ARA) and the service providing entity is the service provider (SP) is described below with reference to FIG. Will be explained.
[0127]
In the example described below, the attribute certificate authority (AA) and the attribute certificate registration authority (ARA) have a trust relationship, and the attribute certificate registration authority (ARA) examines the issuance of the group attribute certificate, and A configuration in which the attribute certificate authority (AA) performs a process of issuing a group attribute certificate based on the examination result of the certificate registration authority (ARA) will be described as an example. Therefore, the shared entity of the group information is two entities of the service provider (SP) and the attribute certificate authority (ARA).
[0128]
The group information sharing processing between the service provider (SP) and the attribute certificate registration authority (ARA) will be described with reference to the processing sequence diagram shown in FIG.
[0129]
First, in step S101, a mutual authentication process is performed between the service provider (SP) and the attribute certificate authority (ARA) that executes the issuance of a group attribute certificate. Note that an attribute certificate authority (ARA) that performs group attribute certificate issuance examination is hereinafter referred to as a group attribute certificate authority (ARA).
[0130]
Mutual authentication performed between the service provider (SP) and the group attribute certificate registration authority (ARA) determines whether or not the two entities performing data transmission / reception are mutually correct data correspondents. This is a process executed for confirmation. Necessary data transfer is performed on condition that authentication is established. In addition, it is preferable that a session key is generated during the mutual authentication process, the generated session key is used as a shared key, and thereafter, data transfer with an encryption process based on the session key is performed. As the mutual authentication method, various methods such as a public key encryption method and a common key encryption method can be applied.
[0131]
Here, a handshake protocol (TLS 1.0), which is one authentication processing method of the public key cryptosystem, will be described with reference to a sequence diagram of FIG.
[0132]
In FIG. 13, an entity A (client) and an entity B (server) are two entities that execute communication and correspond to a service provider (SP) or a group attribute certificate registration authority (ARA). First, (1) the entity B transmits a negotiation start request for determining an encryption specification to the entity A as a hello request. (2) Upon receiving the hello request, the entity A transmits a candidate for the encryption algorithm, session ID, and protocol version to be used to the entity B side as a client hello.
[0133]
(3) The entity B sends the encryption algorithm, the session ID, and the protocol version determined to be used to the entity A as a server hello. (4) The entity B transmits a set of public key certificates (X.509v3) up to the root CA owned by the entity B to the entity A (server certificate). In the case where verification is not performed sequentially up to the highest public key certificate in the certificate chain, it is not always necessary to send the complete public key certificate (X.509v3) up to the root CA. (5) Entity B transmits the RSA public key or Diffie & Hellman public key information to entity A (server key exchange). This is public key information that is temporarily applied when a certificate cannot be used.
[0134]
(6) Next, the entity B requests the certificate held by the entity A as a certificate request to the entity A, and (7) notifies the end of the negotiation process by the entity B (server hello end).
[0135]
(8) Upon receiving the server hello end, the entity A transmits a set of public key certificates (X.509v3) up to the root CA owned by the entity A to the entity B (client certificate). If chain verification of public key certificates is not performed, it is not necessary to send a set of public key certificates. (9) The entity A encrypts the 48-byte random number with the public key of the entity B and transmits the random number to the entity B. The entity B and the entity A generate a master secret including data for generating a message authentication code: MAC (Message Authentication Code) for transmission / reception data verification processing based on the value.
[0136]
(10) To confirm the correctness of the client certificate, the entity A encrypts the digest of the message so far with the client's private key and sends it to the entity B (client certificate confirmation). (12) Notify the start of use of the determined encryption algorithm and key (change cipher specification), and (12) notify the end of authentication. On the other hand, (13) the entity B also notifies the entity A of the start of use of the encryption algorithm and key determined previously (change cipher specification), and (14) notifies the end of the authentication.
[0137]
Data transfer between the entity A and the entity B is executed according to the encryption algorithm determined in the above processing.
[0138]
In the verification of data tampering, a message authentication code: MAC (Message Authentication Code) calculated from a master secret generated based on the agreement between the entity A and the entity B in the above-described authentication processing is added to the transmission data of each entity. By doing so, the falsification of the message is verified.
[0139]
FIG. 14 shows a configuration for generating a message authentication code: MAC (Message Authentication Code). The data transmitting side adds the MAC secret generated based on the master secret generated in the authentication process to the transmission data, calculates a hash value from the entire data, and further converts the hash value into the MAC secret, padding, and hash value. Based on the hash calculation, a message authentication code (MAC) is generated. The generated MAC is added to the transmission data. If the reception side finds a match between the MAC generated based on the reception data and the reception MAC, it is determined that there is no data tampering. Is determined to have been tampered with.
[0140]
In step S101 shown in FIG. 12, for example, a mutual authentication process is performed between the service provider (SP) and the attribute certificate authority (ARA) that executes the issuance of a group attribute certificate according to the above-described sequence. When it is confirmed that both parties are correct communication partners, in step S102, a process of sharing group information is performed between the service provider (SP) and the attribute certificate registration authority (ARA).
[0141]
Specifically, the sharing of group information refers to an issuance policy table managed by an issuance entity of a group attribute certificate (for example, an attribute certificate authority (ARA)), and verification of a group attribute certificate and provision of a service based on the verification. This is performed as a process of setting a state in which information matching with a group information database of an entity (for example, a service provider (SP)) is held.
[0142]
As described above, the issuing entity of the group attribute certificate (for example, the attribute certificate registration authority (ARA)) has an issuing policy table, and verifies the group attribute certificate and provides a service providing entity based on the verification (for example, the service). The provider (SP) has a group information database. FIG. 15 shows an example of each information configuration.
[0143]
(A) The attribute policy registration authority (ARA) holds and manages the issuance policy table, and refers to the group attribute certificate issuance processing and the like. On the other hand, (B) the group information database (DB) is maintained and managed by the service provider (SP), and is referred to when verifying the group attribute certificate when providing the service.
[0144]
It is necessary that the (A) issuance policy table held and managed by the attribute certificate registration authority (ARA) and the (B) group information database (DB) held and managed by the service provider (SP) have consistency. In the example of FIG. 15, (A) the entry 341 of the issuance policy table matches the (B) entry 351 of the group information database (DB), and (A) the entry 342 of the issuance policy table corresponds to the (B) group It is consistent with the entry 352 of the information database (DB). As described above, the consistency maintenance process between the (A) issuance policy table maintained and managed by the attribute certificate registration authority (ARA) and the (B) group information database (DB) maintained and managed by the service provider (SP) is illustrated. 12 is a group information sharing process of step S102 in the sequence diagram of FIG.
[0145]
In addition, there are the following two examples of the mode of the group information sharing process.
Policy acceptance type: Verification of the group attribute certificate and a service providing entity based on the verification (for example, a service provider (SP)) can issue various group attribute certificate issuing entities (for example, an attribute certificate authority (ARA)). Is examined, a group ARA suitable for the service is selected, and the service provider (SP) acquires group information managed by the selected group ARA.
[0146]
Issuance entrustment type: A group attribute certificate issuance entity (for example, a group attribute certificate authority (ARA)) that does not have its own attribute certificate issuance policy but simply undertakes issuance of a group attribute certificate. The verification of the group attribute certificate and the issuance policy set by the service providing entity (for example, the service provider (SP)) based on the verification are presented to the group attribute certificate authority (ARA), and the group attribute certificate authority (ARA) is presented. Is issued in accordance with the presented policy.
[0147]
As a specific form of group information sharing processing, information such as group ID, issuer, group information, and issuance policy relating to the group attribute certificate is stored in the issuance entity of the group attribute certificate (for example, a group attribute certificate authority (ARA) ) Is set and presented to the service providing entity (for example, a service provider (SP)) based on the verification of the group attribute certificate and the verification, and the service provider sets an aspect in which both entities agree or this information is set. , And present it to the group ARA, in which both entities agree, or in which each information is shared and set by both parties to reach an agreement on comprehensive information, or the service provider determines whether the group attribute certificate registration authority ( ARA) can be unilaterally trusted.
[0148]
In the case of the issue consignment type, when a new service provider (SP) starts a new service using a group attribute certificate, the attribute certificate registration authority (ARA) calls the service provider (SP). A registration examination of itself is performed, and thereafter, the above-described group information sharing processing is executed.
[0149]
When the group information sharing process in step S102 ends, in step S103, the service provider (SP) executes a data update process for the group information database managed by the service provider based on the agreed information. As shown in FIG. 15, the group information database stores data of an issuer, group identification information (group ID), and group information, and executes data registration and update for these pieces of information. On the other hand, in step S104, the attribute certificate registration authority (ARA) executes a data update process on the issuance policy table managed by itself, based on the agreed information. As shown in FIG. 15, the issuance policy table stores group ID, group information, and issuance policy data, and executes data registration and update for these pieces of information.
[0150]
The above-described processing is necessary when the service provider (SP) and the attribute certificate registration authority (ARA) are configured as independent entities. In the case where the service provider (SP) also serves as the certificate registration authority (ARA), the service provider (SP) itself holds and manages both the group information database and the issuance policy table. The process of sharing group information between the registration authorities (ARA) can be omitted.
[0151]
The above-described example describes an example in which the issuing entity of the group attribute certificate is the group attribute certificate authority (ARA) and the verification of the group attribute certificate and the service providing entity based on the verification are the service provider (SP). However, the above-described processing is executed according to the combination of each entity.
[0152]
(3-2) Group attribute certificate issuance processing
Next, the group attribute certificate issuing process will be described. The process of issuing a group attribute certificate is basically performed by an attribute certificate authority (AA). However, service providers and user devices can issue issuance based on their own issuance policies. Hereinafter, a sequence of a process of issuing a group attribute certificate by the attribute certificate authority (AA) will be described.
[0153]
The attribute certificate registration authority (ARA) receives the issuance request from the attribute certificate issuance request entity, executes policy examination and the like, determines that the issuance is possible, and then requests the attribute certificate authority (AA) to issue the attribute certificate issuance request. Is a normal attribute certificate issuance sequence in which the attribute certificate issued by the attribute certificate authority (AA) is transmitted to the issuance request entity via the attribute certificate registration authority (ARA).
[0154]
With reference to FIG. 16, a description will be given of a process in a case where the security chip (SC) of the end entity (EE), which is a user device, is an issue requesting entity of the group attribute certificate. In FIG. 16,
UID: user identification device (user device) control unit,
USC: User security chip configured in UID,
EE: end entity (user device) control unit,
SC: security chip configured in EE,
Group ARA: Group attribute certificate registration authority control unit,
Group AA: group attribute certificate authority control unit,
It is.
[0155]
First, in step S111, the user inputs a group attribute certificate (Gp. AC) issuance request command via the input interface of the end entity (EE). At this time, the user inputs an attribute value required for issuing the group attribute certificate. The attribute value is a group ID, information proving that the user belongs to the group, or the like.
[0156]
When the end entity (EE) receives the input of the issuance request of the group attribute certificate (Gp. AC) from the user, in step S112, the end entity (EE) issues a connection request to the group ARA. In step S113, a mutual authentication start request is output to the security chip (SC) in the end entity (EE).
[0157]
In step S114, mutual authentication between the security chip and the group ARA is performed. This is executed, for example, as the public key mutual authentication process described above with reference to FIG. In step S115, the security chip outputs a mutual authentication completion notification including information on the result of the establishment or non-establishment of the mutual authentication to the end entity. If the mutual authentication is not established, the continuation of the processing is stopped. When mutual authentication is established, in step S116, the end entity (EE) transmits a group attribute certificate (Gp. AC) issuance request to the group ARA. This group attribute certificate (Gp. AC) issuance request includes end entity information and attribute values (for example, group ID and group information).
[0158]
In step S117, the group ARA having received the group attribute certificate (Gp. AC) issuance request from the end entity (EE) refers to the issuance policy table and can issue the group attribute certificate compliant with the policy. It is determined whether or not it is possible. If it is possible, the process proceeds to step S118.
[0159]
In step S118, the group ARA transmits a group attribute certificate (Gp. AC) issuance request with an attribute value (group ID) to the group AA. In step S119, the group AA stores the group ID as attribute information, A group attribute certificate (see FIG. 5) with an electronic signature is generated and transmitted to the group ARA.
[0160]
In step S120, the group ARA transmits the issued group attribute certificate (Gp. AC) to the end entity (EE). The end entity (EE) stores the received group attribute certificate (Gp. AC) in the memory. At this time, after verifying the digital signature of the group attribute certificate (Gp. AC), it is confirmed that there is no tampering. Store in memory.
[0161]
The generation of the digital signature executed by the group AA when the group attribute certificate is generated and the verification processing of the electronic signature executed by the end entity when the group attribute certificate is stored will be described with reference to FIGS. .
[0162]
The signature is added to enable verification of data tampering, and the above-described MAC value can be used, and an electronic signature using a public key cryptosystem can be applied.
[0163]
First, a method of generating a digital signature using a public key cryptosystem will be described with reference to FIG. The process illustrated in FIG. 17 is a flow of a process of generating electronic signature data using EC-DSA ((Elliptic Curve Digital Signature Algorithm), IEEE P1363 / D3). Here, an example in which an elliptic curve cryptosystem (hereinafter, referred to as ECC) is used as the public key cryptosystem will be described. In the data processing device of the present invention, for example, an RSA encryption (such as (Rivest, Shamir, Adleman) or the like (ANSI X9.31)) in a similar public key encryption method can be used other than the elliptic curve encryption. It is.
[0164]
Each step of FIG. 17 will be described. In step S1, p is a characteristic, and a and b are coefficients of an elliptic curve (elliptic curve: y 2 = X 3 + Ax + b, 4a 3 + 27b 2 ≠ 0 (modp)), G is a base point on an elliptic curve, r is an order of G, and Ks is a secret key (0 <Ks <r). In step S2, the hash value of the message M is calculated, and f = Hash (M).
[0165]
Here, a method of obtaining a hash value using a hash function will be described. The hash function is a function that receives a message, compresses the message into data having a predetermined bit length, and outputs the data as a hash value. The hash function has difficulty in predicting an input from a hash value (output). When one bit of data input to the hash function changes, many bits of the hash value change, and the same hash value is output. It has a feature that it is difficult to find different input data. As the hash function, MD4, MD5, SHA-1, or the like may be used, or DES-CBC may be used. In this case, the MAC (check value: equivalent to ICV), which is the final output value, is the hash value.
[0166]
Subsequently, in step S3, a random number u (0 <u <r) is generated, and in step S4, a coordinate V (Xv, Yv) obtained by multiplying the base point by u is calculated. The addition and doubling on the elliptic curve are defined as follows.
[0167]
(Equation 1)
If P = (Xa, Ya), Q = (Xb, Yb), and R = (Xc, Yc) = P + Q,
When P ≠ Q (addition),
Xc = λ 2 -Xa-Xb
Yc = λ × (Xa−Xc) −Ya
λ = (Yb−Ya) / (Xb−Xa)
When P = Q (doubling)
Xc = λ 2 -2Xa
Yc = λ × (Xa−Xc) −Ya
λ = (3 (Xa) 2 + A) / (2Ya)
[0168]
Calculate u times of point G using these (the speed is slow, but the most obvious operation method is as follows. G, 2 × G, 4 × G,. 2 corresponding to where 1 stands i × G (a value obtained by doubling G i times (i is a bit position when counting from the LSB of u)) is added.
[0169]
In step S5, c = Xvmodr is calculated. In step S6, it is determined whether or not this value becomes 0. If not 0, d = [(f + cKs) / u] modr is calculated in step S7, and d is calculated in step S8. Is determined to be 0, and if d is not 0, c and d are output as electronic signature data in step S9. Assuming that r has a length of 160 bits, the digital signature data has a length of 320 bits.
[0170]
If c is 0 in step S6, the process returns to step S3 to generate a new random number again. Similarly, if d is 0 in step S8, the process returns to step S3 to generate a random number again.
[0171]
Next, a method of verifying an electronic signature using a public key cryptosystem will be described with reference to FIG. In step S11, M is a message, p is a characteristic, a and b are coefficients of an elliptic curve (elliptic curve: y 2 = X 3 + Ax + b, 4a 3 + 27b 2 ≠ 0 (modp)), G is a base point on an elliptic curve, r is an order of G, and G and Ks × G are public keys (0 <Ks <r). In step S12, it is verified whether the digital signature data c and d satisfy 0 <c <r and 0 <d <r. If this is satisfied, the hash value of the message M is calculated in step S13, and f = Hash (M). Next, h = 1 / d mod r is calculated in step S14, and h1 = fh mod r and h2 = ch in step S15.
Calculate mod r.
[0172]
In step S16, the point P = (Xp, Yp) = h1 × G + h2 · Ks × G is calculated using h1 and h2 already calculated. Since the electronic signature verifier knows the base point G and Ks × G, the scalar multiplication of the point on the elliptic curve can be calculated as in step S4 of FIG. Then, in step S17, it is determined whether or not the point P is an infinite point. If not, the process proceeds to step S18 (actually, the determination of the infinite point can be made in step S16. That is, P = (X , Y) and Q = (X, -Y), it is known that λ cannot be calculated and P + Q is a point at infinity.) In step S18, Xpmodr is calculated and compared with the digital signature data c. Finally, if the values match, the process proceeds to step S19, where it is determined that the electronic signature is correct.
[0173]
When it is determined that the electronic signature is correct, it is known that the data has not been tampered with and the person holding the private key corresponding to the public key has generated the electronic signature.
[0174]
If the digital signature data c or d does not satisfy 0 <c <r and 0 <d <r in step S12, the process proceeds to step S20. Also, in step S17, if the point P is a point at infinity, the process proceeds to step S20. Furthermore, if the value of Xpmodr does not match the digital signature data c in step S18, the process proceeds to step S20.
[0175]
If it is determined in step S20 that the electronic signature is incorrect, it is known that the data has been falsified or that the person holding the private key corresponding to the public key has not generated the electronic signature. As described above, tampering is possible only by adding a signature or hash, but has the same effect as that tampering cannot be substantially achieved by detection.
[0176]
Next, a procedure for issuing a group attribute certificate corresponding to the user security chip (USC) in the user identification device (UID) will be described with reference to FIG. As described above, since the UID is configured to be able to communicate with the outside via the end entity (EE), the attribute certificate acquisition process is also executed via the end entity (EE).
[0177]
The processing in steps S131 to S135 is the same as the processing in steps S111 to S115 described with reference to FIG. 16, and a description thereof will be omitted.
[0178]
If the mutual authentication between the security chip (SC) in the end entity and the group ARA in step S134 is established, in step S137, the user security chip (USC) in the user identification device (UID) and the security in the end entity Mutual authentication processing with the chip (SC) is executed. This authentication processing is executed via the connection device interface 231 (see FIG. 9) between the end entity (EE) and the user identification device (UID). This authentication process can be executed as the authentication process based on the public key method described above with reference to FIG. 13 as a process centering on the encryption processing unit (see FIG. 9) of the security chip and the security module. In step S138, an end-of-authentication notification including authentication completion information is sent to the end entity (EE), and the process proceeds to the next step on condition that the authentication is completed.
[0179]
In step S139, the end entity (EE) outputs a user security chip (USC) mutual authentication start request, and in step S140, mutual authentication processing between the USC and the group ARA is executed. In step S141, the USC notifies the end entity (EE) of an authentication completion notification including authentication establishment information. On condition that the authentication is established, the end entity (EE) transmits the group ARA to the group ARA in step S142. An attribute certificate (Gp. AC) issuance request is transmitted. This group attribute certificate (Gp. AC) issuance request includes end entity information and attribute values (for example, group ID and group information).
[0180]
In step S143, the group ARA that has received the group attribute certificate (Gp. AC) issuance request from the end entity (EE) refers to the issuance policy table and can issue a group attribute certificate compliant with the policy. It is determined whether or not it is possible. If it is possible, the process proceeds to step S144.
[0181]
In step S144, the group ARA transmits a group attribute certificate (Gp. AC) issuance request with the attribute value (group ID) to the group AA. In step S145, the group AA stores the group ID as attribute information. A group attribute certificate (see FIG. 5) with an electronic signature is generated and transmitted to the group ARA.
[0182]
In step S146, the group ARA transmits the issued group attribute certificate (Gp. AC) to the UID via the end entity (EE). The UID stores the received group attribute certificate (Gp. AC) in the memory. At this time, the electronic signature of the group attribute certificate (Gp. AC) is verified to confirm that there is no tampering, and then stored in the memory.
[0183]
As described above, in order for a user identification device (UID) having no direct communication function with the group ARA to obtain a group attribute certificate corresponding to a user security chip (USC), an end entity (EE) is required. Process is required. At this time, in order to mutually authenticate between the user security chip (USC) and the group ARA, for example,
(1) Mutual authentication between the EE SC and the group ARA,
(2) Mutual authentication between EE SC and UID USC,
(3) Mutual authentication between USC of UID and group ARA,
Must be satisfied. Alternatively, as a simple method, the EE may be connected to the EE so that the EE basically accepts (authenticates) the EE. In this case, the mutual authentication described in (2) above is performed. Can be omitted. Further, an authentication configuration based on various combinations of the above three types of mutual authentication is possible.
[0184]
(3-3) Group attribute certificate use processing
Processing using a security attribute (SC) in a user device or a group attribute certificate stored in a user security chip (USC) will be described. Here, a specific service form will not be referred to, and the service use authority confirmation processing based on the group attribute certificate until the start of service provision will be described. A specific service form will be described in another item at a later stage.
[0185]
Referring to FIG. 20 et seq., Processing until service start including service use right confirmation using group attribute certificate issued to security chip (SC) in end entity (EE) as a user device explain. In FIG. 20,
UID: user identification device (user device) control unit,
USC: User security chip configured in UID,
EE: end entity (user device) control unit,
SC: security chip configured in EE,
SP: service provider control unit,
SM: Security module in SP,
It is.
[0186]
Note that the security chip (SC) of the user device (EE), the user security chip (USC) of the user identification device (UID), and the security module of the service provider (SP) are, for example, the security chip of FIG. It has a similar configuration.
[0187]
First, in step S151, the user inputs a group attribute certificate (Gp. AC) use request command via the input interface of the end entity (EE). At this time, the user specifies the group ID set in the group attribute certificate to be used. However, when a unique group ID can be determined by specifying a specific service, only the service may be specified.
[0188]
When the end entity (EE) receives the use request input of the group attribute certificate (Gp. AC) from the user, in step S152, the end entity (EE) issues a connection request to the service provider (SP). On the other hand, in step S153, a mutual authentication start request is output to the security chip (SC) in the end entity (EE).
[0189]
In step S154, mutual authentication between the security chip and the security module (SM) of the service provider (SP) is performed. This is, for example, a process mainly performed by the cryptographic processing unit 205 shown in FIG. 9 which is configured in the security module (SM) of the security chip and the service provider (SP). This is executed as a public key mutual authentication process.
[0190]
In step S155, the security chip outputs a mutual authentication completion notification including information on the result of establishment or non-establishment of mutual authentication to the end entity. If the mutual authentication is not established, the continuation of the processing is stopped. If mutual authentication is established, in step S156, the end entity (EE) transmits the group attribute certificate (Gp. AC) stored in its own memory to the security module (SM) of the service provider (SP). . The transmission of the group attribute certificate (Gp. AC) may be executed in response to a transmission request from the service provider (SP). In addition, the end entity (EE) may request the use of the group attribute certificate (Gp. AC) in conjunction with the transmission of the group attribute certificate (Gp. AC). In this group attribute certificate (Gp. AC), group identification information (group ID) is stored as an attribute value.
[0191]
The service provider receives the group attribute certificate (Gp. AC) from the end entity (EE) by using, for example, a network interface having the same configuration as that of the user device shown in FIG. Forward. In step S157, the security module (SM) performs a group attribute certificate verification process. As described above, the security module has the same configuration as that of the security chip of the user device shown in FIG. 9, and the security module functions as a group attribute certificate verification processing unit.
[0192]
Details of the verification process of the group attribute certificate will be described with reference to FIGS. First, the process of confirming the association between the attribute certificate (AC) and the public key certificate (PKC) will be described with reference to FIG. The flow of FIG. 21 is a process of confirming a public key certificate (PKC) related to the attribute certificate (AC), which is performed when the attribute certificate (AC) is verified.
[0193]
When the attribute certificate (AC) to be confirmed is set (S21), the public key certificate information (holder) field of the AC holder of the attribute certificate is extracted (S22), and the extracted public key certificate information ( The public key certificate issuer information (PKC issuer) and the public key certificate serial number (PKC serial) stored in the (holder) field are checked (S23), and the public key certificate issuer information (PKC issuance) ), Retrieves the public key certificate (PKC) based on the public key certificate serial number (PKC serial) (S24), and obtains the public key certificate (PKC) associated with the attribute certificate (AC) (S25).
[0194]
As shown in FIG. 21, the attribute certificate (AC) and the public key certificate (PKC) are the public key certificate issuer information (public key certificate information (holder)) field stored in the attribute certificate. PKC issuer) and a public key certificate serial number (PKC serial).
[0195]
Next, the attribute certificate (AC) verification processing will be described with reference to FIG. First, an attribute certificate (AC) to be verified is set (S51), and the owner and signer of the attribute certificate (AC) are specified based on the attribute certificate (AC) storage information (S52). Further, the public key certificate of the owner of the attribute certificate (AC) is obtained directly or from a repository or the like (S53), and the public key certificate is verified (S54).
[0196]
The verification process of the public key certificate (PKC) will be described with reference to FIG. The verification of the public key certificate (PKC) shown in FIG. 23 is performed by following the certificate chain from the lower level to the upper level and obtaining chain information from the highest public key certificate to the highest level (root CA). 5 is a chain verification processing flow for verifying the signature of the public key certificate of FIG. First, a public key certificate (PKC) to be verified is set (S31), and a signer of the public key certificate (PKC) is specified based on the public key certificate (PKC) storage information (S32). Further, it is determined whether the certificate is the highest public key certificate in the certificate chain to be verified (S33). If not, the highest public key certificate is obtained directly or from a repository or the like (S34). . When the highest public key certificate is obtained and set (S35), a verification key (public key) required for signature verification is obtained (S36), and it is determined whether or not the signature to be verified is a self-signature. (S37) If not self-signed, lower PKC is set (S39), and signature verification is executed based on the verification key (public key) obtained from the upper public key certificate (S40). In the self-signature determination in step S37, in the case of a self-signature, verification is performed using its own public key as a verification key (S38), and the process proceeds to step S41.
[0197]
If the signature verification has succeeded (S41: Yes), it is determined whether the verification of the target PKC has been completed (S42). If the verification has been completed, the PKC verification ends. If not completed, the process returns to step S36 to repeatedly execute acquisition of a verification key (public key) necessary for signature verification and signature verification of a lower public key certificate. If the signature verification has failed (S41: No), the process proceeds to step S43, where error processing, for example, processing for stopping the subsequent procedure is executed.
[0198]
Returning to FIG. 22, the description of the attribute certificate verification process is continued. If the verification of the public key certificate described with reference to FIG. 23 has failed (No in S55), the process proceeds to step S56, and error processing is performed. For example, the subsequent processing is stopped. When the verification of the public key certificate is successful (Yes in S55), the public key certificate corresponding to the signer of the attribute certificate (AC) is obtained directly or from a repository (S57), and the attribute certificate (AC) is acquired. The verification process of the public key certificate corresponding to the signer of AC) is executed (S58).
[0199]
If the verification of the public key certificate corresponding to the signer of the attribute certificate (AC) fails (No in S59), the process proceeds to step S60, and an error process is performed. For example, the subsequent processing is stopped. If the verification of the public key certificate is successful (Yes in S59), the public key is extracted from the public key certificate corresponding to the signer of the attribute certificate (AC) (S61), and the extracted public key is used. The signature verification process of the attribute certificate (AC) is executed (S62). If the signature verification fails (No in S63), the process proceeds to step S64, and an error process is performed. For example, the subsequent processing is stopped. If the signature verification has succeeded (Yes in S63), the attribute certificate verification ends, and the process proceeds to the subsequent process, that is, another condition confirmation process to be executed for service provision.
[0200]
Returning to the sequence diagram of FIG. 20, the description will be continued. When the verification of the group attribute certificate (Gp. AC) in step S157 is performed by the above-described processing, the security module (SM) outputs a verification result to the service provider (SP). As the error processing, the processing is stopped without providing the service. In this case, a process of notifying the end entity that the verification of the group AC has failed may be executed.
[0201]
When the verification of the group attribute certificate (Gp. AC) succeeds and the validity of the group attribute certificate (Gp. AC) is confirmed, the process proceeds to step S161. The processing after step S161 will be described with reference to FIG. In step S161, examination of the group attribute certificate (Gp. AC) is executed. The examination is performed based on the group information database held by the service provider.
[0202]
The examination process of the group attribute certificate (Gp. AC) will be described with reference to FIG. In step S161-1, the service provider (SP) acquires issuer information from the verified group attribute certificate (Gp. AC). Further, in step S161-2, an attribute value, that is, group identification information (group ID) is obtained from the attribute field.
[0203]
In step S161-3, the group information database is searched based on the AC issuer and the group ID acquired from the group attribute certificate (Gp. AC), and the presence or absence of a registered entry is confirmed. If there is a corresponding registration entry, in step S161-4, group information is acquired from the group information database.
[0204]
Returning to the sequence diagram of FIG. 24, the description will be continued. If the group information corresponding to the group attribute certificate (Gp. AC) is not registered, or if the user does not satisfy the conditions indicated in the group information, the examination is unsuccessful (S162: No), and The error processing of S163 is executed. For example, a message that the examination of the group AC is not established and the service cannot be executed is notified to the end entity (EE). Further, when a plurality of group attribute certificates need to be verified / examined for providing a service, the conditions are managed in a service information database.
[0205]
The service information database is a database that stores information on which group AC is required for providing a service. However, it is not essential that the above-described group information database and service information database are individually held, and it is possible to have a database configuration in which the group information database and the service information database are integrated or linked. That is, a configuration is also possible in which data indicating which group AC is required for service provision is obtained from the above-described groove information database or link information of the groove information database. In the following description, it is assumed that the group information database also has a function as a service information database.
[0206]
Returning to the sequence diagram of FIG. 24, the description will be continued. If the examination is successful (S162: Yes), it is determined whether other conditions for service execution are necessary. This condition can be arbitrarily set by the service provider. Further, in step S165, it is determined whether another group attribute certificate is required for providing the service.
[0207]
This is based on the assumption that, as shown in FIG. 26, the service or the provision condition is that the user or the user device belongs to a plurality of different groups. For example, as shown in FIG. 26A, it can be set to provide a service by proving that the user belongs to two different groups.
[0208]
Specifically, for example, a group attribute certificate A (group A) for proving that the user's place of residence belongs to a specific area, and a group attribute certificate B (group) for indicating that the user device is a device of a specific manufacturer This is a setting for providing a service by presenting and verifying the two group attribute certificates B).
[0209]
Furthermore, as shown in FIG. 26B, it is possible to set to provide a service by proving that the user belongs to three or more different groups. Specifically, for example, a group attribute certificate A (group A) for proving that the user's place of residence belongs to a specific area, and a group attribute certificate B (group) for indicating that the user device is a device of a specific manufacturer B), and setting of providing a service by presenting and verifying three group attribute certificates of a group attribute certificate C (group C) indicating that the age of the user belongs to a predetermined range.
[0210]
As described above, by applying two or more different group attribute certificates issued to a user or a user device, service provision can be performed on the condition that the user or the user device belongs to a plurality of different groups. If so, the service provider (SP) requests the end entity (EE) to present another group attribute certificate (Gp. AC) in step S166. In step S167, the end entity (EE) requested to present another group attribute certificate transmits the requested group attribute certificate to the security module (SM) of the service provider (SP). The security module (SM) performs the processing from step S157 shown in FIG. 20 on the new group attribute certificate received from the end entity (EE), that is, the verification processing and the examination processing of the group attribute certificate.
[0211]
The service is provided in step S168 on condition that the verification and examination of the group attribute certificate required for providing the service are successful. This service includes various services such as content distribution provided by a service provider, settlement processing, remote control of a device (for example, a home electric appliance) as a user device, remote maintenance processing, a communication service, and the like. Specific examples of these services will be described later.
[0212]
Next, with reference to FIGS. 27 and 28, processing up to service provision based on a group attribute certificate issued corresponding to a user security chip (USC) in a user identification device (UID) as a user device. explain. A user identification device (UID) is a device that functions as a personal identification device. The group attribute certificate can be individually issued to each of the end entity and the user identification device. Basically, the group attribute certificate issued to the user identification device is issued as a certificate that enables confirmation of whether the user itself is a member of a certain group. Since the UID can communicate with the outside through the end entity (EE), the use process of the attribute certificate is also executed through the end entity (EE).
[0213]
27, steps S171 to S175 are the same as steps S151 to S155 shown in FIG. 20, that is, the security chip (SC) in the end entity (EE) and the security module (SM) of the service provider (SP). This is a process centered on mutual authentication between the two.
[0214]
If the mutual authentication between the security chip (SC) in the end entity and the security module (SM) of the service provider (SP) shown in step S174 is established, in step S177, the user security chip (UID) in the user identification device (UID) is obtained. USC) and the security chip (SC) in the end entity perform mutual authentication processing. This authentication processing is executed via the connection device interface 231 (see FIG. 9) between the end entity (EE) and the user identification device (UID). This authentication process can be executed as the authentication process based on the public key method described above with reference to FIG. 13 as a process centering on the encryption processing unit (see FIG. 9) of the security chip and the security module. In step S178, an end-of-authentication notification is sent to the end entity (EE) including authentication establishment information, and the process proceeds to the next step on condition that the authentication is established.
[0215]
In step S179, a mutual authentication start request is output from the end entity (EE) to the user security chip (USC). In step S180, mutual authentication processing between the USC and the security module (SM) of the service provider (SP) is performed. Be executed. In step S181, the USC notifies the end entity (EE) of an authentication completion notification including authentication establishment information. On condition that the authentication is established, the user identification device (UID) transmits the authentication information of the service provider (SP) to the end entity (EE) in step S182. The group attribute certificate (Gp. AC) is presented to the security module (SM). This group attribute certificate (Gp. AC) is a group attribute certificate (Gp. AC) issued corresponding to the user security chip (USC) of the user identification device (UID).
[0216]
In step S183, the security module (SM) of the service provider (SP) that has received the group attribute certificate (Gp. AC) from the user security chip (USC) performs a process of verifying the received group attribute certificate. This verification processing is the same processing as described with reference to FIGS. Hereinafter, the processing of steps S184 to S198 (FIG. 28) is basically the same as the processing for the group attribute certificate corresponding to the security chip (SC) of the end entity described with reference to FIGS. Description is omitted. However, in step S197 shown in FIG. 28, the transmission of the new group attribute certificate is executed by the user identification device (UID).
[0219]
As described above, in order for a user identification device (UID) having no direct communication function with a service provider (SP) to use a group attribute certificate corresponding to a user security chip (USC), an end entity is required. Processing via (EE) is required. At this time, in order to mutually authenticate between the user security chip (USC) and the service provider (SP), for example,
(1) Mutual authentication between EE SC and service provider (SP),
(2) Mutual authentication between EE SC and UID USC,
(3) Mutual authentication between UID USC and service provider (SP),
Must be satisfied. Alternatively, as a simple method, the EE may be connected to the EE so that the EE basically accepts (authenticates) the EE. In this case, the mutual authentication described in (2) above is performed. Can be omitted. Further, an authentication configuration based on various combinations of the above three types of mutual authentication is possible.
[0218]
FIGS. 20 and 24 illustrate processing using a group attribute certificate corresponding to the security chip (SC) of the end entity (EE), and FIGS. 27 and 28 illustrate the processing of the user of the user identification device (UID). Although the processing using the group attribute certificate issued in correspondence with the security chip (USC) has been described, the group attribute certificate corresponding to the security chip (SC) of the end entity (EE) and the user identification device (UID) )), A service is provided based on verification and examination of a plurality of attribute certificates both with a group attribute certificate issued corresponding to a user security chip (USC), for example, referring first to FIG. The configuration as described is also possible. In this case, the processing shown in FIGS. 27 and 28 and the processing shown in FIGS. 20 and 24 are combined.
[0219]
For example, the service provider may set a service permission target based on first group identification information obtained from a first group attribute certificate based on a group definition in which an end entity (equipment) as a user device is a member of a group. And whether the user is sent from the user identification device as a member of the group, based on the second group identification information obtained from the second group attribute certificate based on the group definition. A configuration is possible in which a judgment is made as to whether or not the service is a service permitting object, and a service provision possible judgment process is executed on condition that all group identification information is a service permitting object.
[0220]
[(4) Issuance and Use Process of Group Attribute Certificate Between User Devices] In the above description, the group attribute certificate is a certificate mainly for confirming the use authority of the service provided by the service provider to the user device. It has been described as being applied as a letter. The issuer of the group attribute certificate is basically the group attribute certificate authority (group AA), but the service provider (SP) executes the functions of the group attribute certificate authority (group AA) and the group ARA to provide the service. It is also possible that the provider (SP) issues a group attribute certificate under its own policy. Further, a form is also possible in which the user device itself performs the functions of a group attribute certificate authority (group AA) and a group ARA, and the user device issues a group attribute certificate under its own policy. Hereinafter, a configuration in which a user device issues a group attribute certificate and executes access restriction on the user device using the group attribute certificate will be described.
[0221]
As a specific usage form, for example, when a user device (end entity) as a communication processing device having a communication function wants to permit only access from a specific member, a group attribute certificate in which the specific member is set as a group is used. Access authority management for requesting the presentation of the issued group attribute certificate from another user device that has issued and requested access, performs verification of the presented group attribute certificate, and permits access. There is a form.
[0222]
In this service providing mode, that is, a service providing service providing mode, a configuration in which a service provider (SP) issues a group attribute certificate is also possible. However, in a user device, for example, a specific friend, family, the same company, By setting members and the like as a group, storing them as group identification information corresponding to the set group, and generating and issuing a group attribute certificate, access management on an individual basis becomes possible.
[0223]
First, a process of issuing and storing a group attribute certificate between user devices will be described with reference to FIG.
[0224]
Referring to FIG. 29, a description will be given of a process when the security chip (SC) of the end entity (EE) as the communication processing device which is a user device is a subject of a request for issuing a group attribute certificate. In FIG. 29,
UID: access request source user identification device (user device) control unit,
USC: user security chip configured in access request source UID,
Access source EE: access request source end entity (user device) control unit,
SC1: a security chip configured in the access request source EE;
Access destination EE: access request destination end entity (user device) control unit,
SC2: Security chip configured in access request destination EE
It is.
[0225]
Here, the access source EE and the access destination EE are communication processing devices of different users. The security chips (SC1 and SC2) and the user security chip (USC) have the same configuration as the security chip of FIG. 9 described above, and the security chip executes an access authority determination process by verifying a group attribute certificate. Is done.
[0226]
That is, the access request destination device, which has received the group attribute certificate sent from the access request source device to the access request destination by the receiving unit such as the network interface, transmits the received group attribute certificate to the security chip as the access authority determination processing unit. The access right determination processing is executed based on the group attribute certificate received in the security chip.
[0227]
In the processing sequence diagram of FIG. 29 and subsequent drawings, a description will be given of the processing procedure from the stage of issuing a group attribute certificate for proving that the user has the access right. That is, first, the security chip of the communication processing device executes a group attribute certificate generation process, and performs a process of issuing a group attribute certificate proving that it has the access right. After that, this is a processing sequence in which the issued group attribute certificate is transmitted and received between the communication processing devices to confirm the access authority. Therefore, the security chip of the communication processing device functions as a generation unit and a verification unit of the group attribute certificate.
[0228]
The processing procedure will be described with reference to the sequence diagram of FIG. First, in step S201, the access requesting user inputs a new issuance request command for the group attribute certificate (Gp. AC) via the input interface of the end entity (accessing source EE).
[0229]
When the end entity (access source EE) receives an input of a group attribute certificate (Gp. AC) issuance request from the user, in step S202, the end entity (access source EE) determines the end entity of the access request destination. A connection request is issued to the tee (access destination EE). On the other hand, in step S203, a mutual authentication start request is output to the security chip (SC) in the access source end entity (access source EE).
[0230]
In step S204, mutual authentication is performed between the security chip (SC1) of the user device of the access request source and the security chip (SC2) corresponding to the end entity (access destination EE) of the access request destination. This is executed, for example, as the public key mutual authentication process described above with reference to FIG. In step S205, mutual authentication between the security chip (SC1) of the access request source and the user security chip (USC) is executed. In step S206, the user security chip (USC) of the access request source and the end entity of the access request destination are executed. Mutual authentication between the security chips (SC2) corresponding to the tee (access destination EE) is executed. In step S207, the user authentication chip (USC) that has issued the access request outputs a mutual authentication completion notification including information on the result of the establishment or failure of the mutual authentication to the end entity (EE).
[0231]
Note that the processing in steps S205 to S207 is necessary when issuing a group attribute certificate corresponding to the user security chip (USC) of the access request source, and corresponds to the security chip (SC1) of the access request source. This can be omitted when a group attribute certificate to be issued is issued.
[0232]
If any of the above mutual authentications is not established, the continuation of the processing is stopped. When all the mutual authentications are established, in step S208, the end entity (EE) of the access request source sends the already held group attribute certificate (Gp. AC) to the security chip (SC2) of the access request destination. Is requested to issue a new group attribute certificate (Gp. AC).
[0233]
This processing is an example of processing for verifying the group attribute certificate (Gp. AC) already held by the access request source and issuing a new, differently defined group attribute certificate (Gp. AC). That is, the issuance policy of the newly issued group attribute certificate (Gp. AC) includes confirmation of the attribute by the existing group attribute certificate (Gp. AC). For example, confirmation of the identity of the user or confirmation of the device of a specific manufacturer is performed based on the existing group attribute certificate (Gp. AC), and on condition that these confirmations are made. A new group attribute certificate (Gp. AC) is issued.
[0234]
As an example of the existing group attribute certificate (Gp. AC), for example, a mutual identification with a user security chip (USC) of a user identification device (UID) is performed and issued by a credit card company issued for a user. There is a group attribute certificate. In addition, a communication terminal as a communication processing device or a terminal manufactured by a maker issued by a maker stored in the end entity (EE) as a result of mutual authentication with a security chip (SC) of the end entity (EE) such as a PC. There is a group attribute certificate or the like that certifies that
[0235]
The security chip (SC2) of the access request destination device verifies the already issued group attribute certificate received from the end entity (EE) of the access request source device. This verification processing is the same processing as described above with reference to FIGS. 21 to 23, and includes processing such as signature verification of an attribute certificate, correspondence, and verification of a chained public key certificate.
[0236]
The access request destination security chip (SC2) outputs the verification result to the access request destination end entity (EE). If the verification is unsuccessful, the process is stopped without executing subsequent processes as an error process. In this case, a process of transmitting an error notification to the access requesting end entity (EE) may be performed.
[0237]
If the verification of the group attribute certificate (Gp. AC) succeeds and the validity of the group attribute certificate (Gp. AC) is confirmed, the process proceeds to step S211. In step S211, examination of the group attribute certificate (Gp. AC) is executed. The examination is performed based on the group information database held by the access request destination end entity (EE). This examination process is similar to the process described above with reference to FIG. That is, issuer information and group identification information (group ID) are acquired from the verified group attribute certificate (Gp. AC), and a group information database is searched based on the acquired AC issuer and group ID, Check for registered entries. If there is a corresponding registration entry, the group information is acquired from the group information database.
[0238]
If the group information corresponding to the group attribute certificate (Gp. AC) is not registered, or if the condition of the group information is not satisfied, the examination is unsuccessful and the processing is stopped as an error. On the other hand, if the examination is successful, in step S212, a request to generate a new group attribute certificate is output to the security chip (SC2) in accordance with the request, and the security chip (SC2) in step S213 outputs the group attribute certificate in accordance with the request. In step S214, a new group attribute certificate (Gp. AC) is issued from the access destination end entity (EE) to the user identification device (UID) of the access requesting user device.
[0239]
For example, when the access request destination user device is a communication terminal device such as a PC storing secure information of company B, the newly issued group attribute certificate has the following attributes:
"Attribute issued from Company B to UID" Employee of Company B ""
"Attribute" C project member "issued from company B to UID"
And so on.
[0240]
The access request destination user device, which is a communication terminal device such as a PC storing the secure information of the company B, requests the presentation of the group attribute certificate at the time of an access request from an unspecified user device, and requests the presented group attribute certificate. It is possible to determine whether access is possible by performing verification and examination of the attribute certificate.
[0241]
Next, a sequence for issuing a group attribute certificate having access permission information as an attribute will be described with reference to FIG. 30, steps S221 to S235 correspond to steps S201 to S215 in FIG. 29, and the processing is the same.
[0242]
In FIG. 30, in step S228, the group attribute certificate presented by the access request source end entity (access source EE) to the security chip (SC2) of the access request destination user device is issued from “Company B to UID. The security chip (SC2) of the access-requested user device verifies and examines the attribute certificate to obtain a new group attribute certificate. That is, a certificate having attribute information indicating that access to the device (access request destination user device) is permitted is issued as an attribute.
[0243]
As a condition for issuing a certificate having attribute information as group information that allows access to the device (access request destination user device), a condition that “an attribute of“ employee of company B ”issued to UID from company B” If a proof by another group attribute certificate other than the group attribute certificate having is required, the processes of steps S228 to S231 are repeatedly executed the number of times corresponding to the number of necessary group attribute certificates.
[0244]
With reference to FIG. 31, an example of correspondence between a group attribute certificate having access permission information as group information and another group attribute certificate will be described. (A), the group attribute certificate having the access permission information as the group information corresponds to the group δ. For example, the condition for issuing the group attribute certificate corresponding to the group δ is that the group attribute certificate is a member of the group α. It becomes. For example, being a member of group α can be proved by a group attribute certificate proving “attribute“ employee of company B ”issued by company B to the UID”, and a group attribute certificate corresponding to group δ Will be issued on condition that the verification and examination have been successful.
[0245]
FIG. 31B shows that the group attribute certificate having the access permission information as the group information corresponds to the group δ. For example, the issuing condition of the group attribute certificate corresponding to the group δ is a member of the group α, It is a condition to be a member of the group β and a member of the group γ and satisfy all the conditions.
[0246]
Specifically, for example, a group attribute certificate α (group α) proving that the user's place of residence belongs to a specific area, and a group attribute certificate β (group β) and three group attribute certificates γ (group γ) indicating that the age of the user belongs to a predetermined range are presented and verified, and the access permission information corresponding to the group δ is group information. This is a setting to issue a group attribute certificate held as.
[0247]
It should be noted that even if the end entity (EE) as the communication processing device is changed by issuing a group attribute certificate to the user identification device as the personal identification device constituting the access request source device, Access can be permitted in the examination based on the group attribute certificate issued to the user identification device as the personal identification device, and the access is denied due to a change in the communication processing device (end entity (EE)). Can be prevented.
[0248]
Next, with reference to FIG. 32, a description will be given of a processing sequence in which the access request destination user device requests the other user device to execute the attribute certificate issuing process without executing the attribute certificate issuing process by itself. I do. In FIG. 32,
UID: access request source user identification device (user device) control unit,
USC: user security chip configured in access request source UID,
Access source EE: access request source end entity (user device) control unit,
SC1: a security chip configured in the access request source EE;
Access destination EE: access request destination end entity (user device) control unit,
SC2: Security chip configured in access request destination EE
Other EE: Third user device (procedure acting user device)
SC3: Security chip of other EE
It is.
[0249]
In FIG. 32, steps S241 to S248 correspond to steps S201 to S208 in FIG. 29, and the processing is the same, and a description thereof will be omitted. In step S248, the end entity (access destination EE) of the access request destination user device sends the group attribute certificate presented from the access request source end entity (access source EE) to the security chip (SC3) of the proxy user device. The security chip (SC3) verifies the transferred group attribute certificate (S250), and the end entity (other EE) of the procedure proxy user device further performs the verification based on the verification result notification (S251). The examination (S252) is executed.
[0250]
Further, on condition that the verification and examination are successful, a request for generating a group attribute certificate is output to the security chip (SC3) (S253), and in step S254, the security chip (SC3) outputs the group attribute certificate in accordance with the request. In step S255, a procedure group end entity (other EE) issues a new group attribute certificate (Gp. AC) to the user identification device (UID) of the access requesting user device. In step S257, the group attribute certificate received by the user identification device (UID) of the access requesting user device is stored.
[0251]
The processing sequence shown in FIG. 32 has a configuration in which, when the access request destination user device does not have the function of verifying, examining, and issuing the attribute certificate, the third device can outsource these processes and execute it. The procedure proxy user device may be configured by a service provider (SP) or the like.
[0252]
Next, a service use sequence involving an access permission / inhibition determination process using a group attribute certificate in which access permission information is defined as group information will be described with reference to FIG.
[0253]
First, in step S261, the user of the access request source inputs an access request command as a process of using the group attribute certificate (Gp. AC) via the input interface of the end entity (access source EE).
[0254]
When the end entity (access source EE) receives the request from the user, in step S262, the end entity (access source EE) issues a connection request to the access request destination end entity (access destination EE). In step S263, a mutual authentication start request is output to the security chip (SC1) in the access source end entity (access source EE).
[0255]
In step S264, mutual authentication is performed between the security chip (SC1) of the user device of the access request source and the security chip (SC2) corresponding to the end entity (access destination EE) of the access request destination. This is executed, for example, as the public key mutual authentication process described above with reference to FIG. In step S265, mutual authentication between the security chip (SC1) of the access request source and the user security chip (USC) is executed. In step S266, the user security chip (USC) of the access request source and the end entity of the access request destination are executed. Mutual authentication between the security chips (SC2) corresponding to the tee (access destination EE) is executed. In step S267, a mutual authentication completion notification including information on the result of successful or unsuccessful mutual authentication is output from the user security chip (USC) as the access request source to the end entity (EE).
[0256]
Note that the processing of steps S265 to S267 is required in the case of processing using a group attribute certificate corresponding to the user security chip (USC) of the access request source, and is the security chip (SC1) of the access request source. Can be omitted in the case of processing using a group attribute certificate corresponding to.
[0257]
If any of the above mutual authentications is not established, the continuation of the processing is stopped. When all the mutual authentications are established, in step S268, the end entity (EE) of the access request source presents the group attribute certificate (Gp. AC) to the security chip (SC2) of the access request destination. Request permission.
[0258]
The security chip (SC2) of the access request destination verifies the group attribute certificate received from the end entity (EE) of the access request source (S269). This verification processing is the same processing as described above with reference to FIGS. 21 to 23, and includes processing such as signature verification of an attribute certificate, correspondence, and verification of a chained public key certificate.
[0259]
The access request destination security chip (SC2) outputs the verification result to the access request destination end entity (EE) (S270). If the verification is unsuccessful, the process is stopped without executing subsequent processes as an error process. I do. In this case, a process of transmitting an error notification to the access requesting end entity (EE) may be performed.
[0260]
If the verification of the group attribute certificate (Gp. AC) succeeds and the validity of the group attribute certificate (Gp. AC) is confirmed, the process proceeds to step S271. In step S271, examination of the group attribute certificate (Gp. AC) is executed. The examination is performed based on the group information database held by the access request destination end entity (EE). This examination process is similar to the process described above with reference to FIG. That is, issuer information and a group ID are acquired from the verified group attribute certificate (Gp. AC), a group information database is searched based on the acquired AC issuer and the acquired group ID, and a registered entry is registered. Check for presence. If there is a corresponding registration entry, the group information is acquired from the group information database. The group information includes, for example, information such as “accessible to this device” or “only data reading is possible”, and a service is provided according to the information.
[0261]
If the group information corresponding to the group attribute certificate (Gp. AC) is not registered, or if the condition of the group information is not satisfied, the examination is unsuccessful and the processing is stopped as an error. On the other hand, if the examination is successful, in step S272, service provision, that is, access to a service registered as group information, for example, a device, is permitted.
[0262]
[(5) Specific usage example of group attribute certificate]
Next, a specific usage example of the group attribute certificate will be described. Below, the usage form
(5-1) Content distribution service
(5-2) Remote control service
(5-3) Remote maintenance service
(5-4) Personal communication service
Each of the above usage modes will be described.
[0263]
FIG. 34 shows an example of a group attribute certificate used in each of the above services. FIG. 34 shows the group attribute certificate issuer, issue timing, owner, verifier, and attributes in association with each other. As described above, the issuer can be various issuers such as a service provider and a user device, in addition to the group ARA that executes only the issuance processing of the group attribute certificate. As the service provider, for example, a credit card is used. Manufactures "Card company A" to be issued, predetermined organization, for example, "Company B", "Government office", "Kosan" as a user personally, and also PCs, communication terminals, game machines and other end entities (EE). "EE maker C".
[0264]
The timing of issuing the group attribute certificate depends on the service provided based on the certificate, such as at an arbitrary timing, at the time of purchase of an end entity (EE) such as a PC, a communication terminal, a game machine, at the time of manufacture, or after purchase. Various settings are possible.
[0265]
The owner of the group attribute certificate is a user or a user device as a member of a predetermined group, and the group attribute certificate issued with the user, for example, “Ko” as an owner, is a user identification device of Mr. Ko. The group attribute certificate issued to the user security chip (USC) of the (UID) based on the authentication of the user security chip (USC) and provided to each member of a family, for example, is a user identification device (USC) of each family. UID) for the user security chip (USC) based on the authentication of the user security chip (USC), and for the user equipment such as a PC, a communication terminal, and a game machine, that is, the end entity (EE). The provided group attribute certificate is for end entity (EE) security. It issued based on the authentication of Yuritichippu user security chip (SC) as the target (USC).
[0266]
The person who performs the verification processing of these group attribute certificates is not shown in the security module (SM) of the service provider (SP) that provides the service based on the attributes certified by the group attribute certificate, or is not shown in the figure. Is a security chip (SC, USC) of the user device.
[0267]
The owner attributes to be proved by each group attribute certificate include, for example, “member of card company A”, “employee of company B”, “family of Ko”, “registered user”, “registered user device”, "Equipment owned by the attribute certificate issuer (EE)", "Mr. Ko's own equipment (EE)", etc. Each of the above attributes will be proved. An attribute certificate verifier such as a service provider provides a predetermined service based on a certified owner attribute.
[0268]
(5-1) Content distribution service
First, a content distribution service using a group attribute certificate will be described. There are various modes for confirming the use right of the content in the content distribution by applying the group attribute certificate.
[0269]
First, as an example, based on a first group attribute certificate A proving that the user is a credit card member issued by a credit card company, a content distribution service which is a content distribution service subject including content use permission information as group information is provided. A description will be given of a processing example in which a second group attribute certificate B issued by a service provider is issued, a content use right is confirmed by applying the second group attribute certificate B, and a content distribution service is executed. I do.
[0270]
Referring to FIG. 35, based on the first group attribute certificate A proving that the user device is a credit card member, the second group attribute certificate B including the content use permission information as group information Will be described.
[0271]
In the example of FIG. 35, the first group attribute certificate A for certifying that the user is a credit card member issued for the user security chip (USC) of the user identification device (UID) is assigned to the group attribute certificate registration authority ( Gp.ARA), and is an example of issuance processing of a second group attribute certificate B, which is issued by a content distribution service provider from a group attribute certificate authority (Gp.AA). Here, it is assumed that the content distribution service provider has agreed with the group attribute certificate registration authority (Gp. ARA) on the group attribute certificate issuance policy.
[0272]
In FIG. 35,
UID: user identification device (user device) control unit,
USC: User security chip configured in UID,
EE: end entity (user device) control unit,
SC: security chip configured in EE,
Group ARA: Group attribute certificate registration authority control unit,
Group AA: group attribute certificate authority control unit,
It is.
[0273]
First, in step S301, the user inputs a group attribute certificate (Gp. AC) issuance request command via the input interface of the end entity (EE). At this time, the user inputs an attribute value required for issuing the group attribute certificate. The attribute value is a group ID, information proving that the user belongs to the group, or the like.
[0274]
When the end entity (EE) receives an input of a request to issue a group attribute certificate (Gp. AC) from a user, in step S302, mutual authentication between the user security chip (USC) and the group ARA is executed. . Although omitted here, in the case of a user identification device (UID) having no direct communication function with the group ARA,
(1) Mutual authentication between the EE SC and the group ARA,
(2) Mutual authentication between EE SC and UID USC,
(3) Mutual authentication between USC of UID and group ARA,
Will do everything. Alternatively, as a simple method, the EE may be connected to the EE so that the EE basically accepts (authenticates) the EE. In this case, the mutual authentication described in (2) above is performed. Can be omitted. Further, an authentication configuration based on various combinations of the above three types of mutual authentication is possible.
[0275]
The authentication process is executed by a process mainly including an encryption process in an encryption processing unit (see FIG. 9) of the security chip of each device, and is executed, for example, as a mutual authentication process of the public key method described above with reference to FIG. Is done. In step S303, the user security chip (USC) outputs a mutual authentication completion notification including information on the result of successful or unsuccessful mutual authentication to the end entity. If the mutual authentication is not established, the continuation of the processing is stopped. If mutual authentication is established, in step S304, the end entity (EE) transmits a group attribute certificate (Gp. AC) issuance request to the group ARA. This group attribute certificate (Gp. AC) issuance request includes end entity information and attribute values (for example, group ID and group information), and further includes a second group attribute issued by the content distribution service provider. A first group attribute certificate A for certifying that the user is a credit card member to be presented as a condition for issuing the certificate B is included.
[0276]
The group ARA that has received the group attribute certificate (Gp. AC) issuance request from the end entity (EE) verifies the first group attribute certificate A that certifies that it is a credit card member, and then proceeds to step S305. It is determined with reference to the issuance policy table whether it is possible to issue a group attribute certificate compliant with the policy. If it is possible, the process proceeds to step S306. Notify.
[0277]
In step S306, the group ARA transmits a group attribute certificate (Gp. AC) issuance request with the attribute value (group ID) to the group AA. In step S307, the group AA stores the group ID as attribute information, A group attribute certificate with an electronic signature, that is, a second group attribute certificate B including content use permission information as group information is generated and transmitted to the group ARA.
[0278]
In step S308, the group ARA transmits the issued group attribute certificate B (Gp. AC) to the user identification device (UID). The user identification device (UID) stores the received group attribute certificate (Gp. AC) in the memory. At this time, the electronic signature of the group attribute certificate (Gp. AC) is verified to confirm that there is no tampering, and then stored in the memory.
[0279]
Next, referring to FIG. 36, the group attribute certificate B issued by the above-described process, that is, the second group attribute certificate B including the content use permission information as group information is presented to the service provider. A process of confirming that the user has the content use authority and providing the service, that is, receiving the content distribution service will be described. In FIG. 36,
UID: user identification device (user device) control unit,
USC: User security chip configured in UID,
EE: end entity (user device) control unit,
SC: security chip configured in EE,
SP: service provider control unit,
SM: Security module in SP,
It is.
[0280]
The security chip (SC), the user security chip (USC), and the security module (SM) have the same configuration as the security chip of FIG. 9 described above, and the security chip performs authority determination processing by verifying the group attribute certificate. Be executed. That is, the service provider, which has received the group attribute certificate sent from the service request source device to the service request destination by a receiving unit such as a network interface, uses the received group attribute certificate as a security module (chip) as an authority determination processing unit. The authority determination processing is executed based on the group attribute certificate received in the security module (chip).
[0281]
First, in step S311, the user inputs a use request command of the group attribute certificate (Gp. AC) via the input interface of the end entity (EE). At this time, the user specifies the group ID set in the group attribute certificate to be used. However, when a unique group ID can be determined by specifying a specific service, only the service may be specified.
[0282]
When the end entity (EE) receives the use request input of the group attribute certificate (Gp. AC) from the user, in step S312, the mutual communication between the user security chip (USC) and the security module (SM) of the service provider is performed. Authentication is performed. Although omitted here, in the case of a user identification device (UID) that cannot directly execute communication with the SP,
(1) Mutual authentication between EE SC and SP-SM,
(2) Mutual authentication between EE SC and UID USC,
(3) Mutual authentication between USC of UID and SP-SM,
Will do everything. Alternatively, as a simple method, the EE may be connected to the EE so that the EE basically accepts (authenticates) the EE. In this case, the mutual authentication described in (2) above is performed. Can be omitted. Further, an authentication configuration based on various combinations of the above three types of mutual authentication is possible.
[0283]
The authentication processing is executed as the mutual authentication processing of the public key method described above with reference to FIG. 13 centering on the encryption processing unit of the security chip and the security module. In step S313, the security chip outputs a mutual authentication completion notification including information on the result of establishment or non-establishment of mutual authentication to the end entity. If the mutual authentication is not established, the continuation of the processing is stopped. When the mutual authentication is established, in step S314, the user security chip (USC) transmits the group attribute certificate (Gp. AC) stored in its own memory to the security module (SM) of the service provider (SP). . This group attribute certificate (Gp. AC) is a second group attribute certificate B including, as group information, content use permission information acquired by the processing described above with reference to FIG.
[0284]
The security module (SM) that has received the group attribute certificate (Gp. AC) from the user security chip (USC) executes a group attribute certificate verification process in step S315. The verification process of the group attribute certificate is as described above with reference to FIGS. 21 to 23, and the signature verification of the attribute certificate, the related public key certificate (PKC) and the chain public key certificate are performed. It is executed as a process including a confirmation process and the like.
[0285]
After the verification processing of the group attribute certificate (Gp. AC), the security module (SM) outputs the verification result to the service provider (SP). If the verification is not successful, the processing is performed without executing the service provision as an error processing. To stop. In this case, a process of notifying the end entity that the verification of the group AC has failed may be executed.
[0286]
When the verification of the group attribute certificate (Gp. AC) is successful and the validity of the group attribute certificate (Gp. AC) is confirmed, the process proceeds to step S317. In step S317, examination of the group attribute certificate (Gp. AC) described above with reference to FIG. 25 is executed. The examination is performed based on the group information database held by the service provider. That is, the service provider (SP) obtains the issuer information and the group ID from the verified group attribute certificate (Gp. AC), searches the group information database based on the obtained information, and searches for the registered entry. Check for presence. If there is a corresponding registration entry, the group information is acquired from the group information database.
[0287]
In this case, the group information is content permission information, which is, for example, information that allows the game X as content to be used for three months. In step S318, the service provider (SP) distributes a service program, that is, a game program in which a usage period of three months is set according to the group information to the end entity (EE) of the user device.
[0288]
The content distribution service processing described above is an example in which the content use right is confirmed using one group attribute certificate. Next, a plurality of different attribute certificates that certify different group attributes are applied to the user or the user. A description will be given of a processing example of providing a service by confirming the content usage right of the device.
[0289]
FIG. 37 shows a plurality of group attribute certificates applied in this processing example. The group attribute certificate (Gp. AC) AC01 is a student ID card issued by University A and certifying that it is a student of University A. The user identification chip (USC) of the user identification device (UID) of Mr. C Is a group attribute certificate (Gp. AC) issued based on the authentication of (i). The group attribute certificate (Gp. AC) AC02 is an art course attendance certificate issued by the University A and certifying that the user has the art course attendance right. The user security chip (C) of Mr. C's user identification device (UID) is used. USC) and a group attribute certificate (Gp. AC) issued based on the authentication with the USC.
[0290]
The group attribute certificate (Gp. AC) AC03 is a management device certificate issued by the University A and certifying that the device is managed by the University A. The security chip of the television D as an end entity (EE) (SC) is a group attribute certificate (Gp. AC) issued based on the authentication. The group attribute certificate (Gp. AC) AC04 is an educational device certificate issued by the Ministry of Education, Culture, Sports, Science and Technology and certifying that the device is for educational use. The security of the television D as an end entity (EE) is This is a group attribute certificate (Gp. AC) issued based on authentication with the chip (SC).
[0291]
With reference to FIG. 38, a description will be given of the content use authority confirmation and service provision processing to which the four different group attribute certificates AC01 to AC04 are applied.
[0292]
FIG. 38 shows user device-side processing on the left and service provider-side processing on the right. The user device includes an end entity (EE), a security chip (SC) configured in the EE, a user identification device (UID), and a user security chip (USC) configured in the UID.
[0293]
In steps S321 and S331, a mutual authentication process is performed between the user device and the service provider. The mutual authentication is performed according to the machine to which the presented group attribute certificate is to be issued, and the mutual authentication between the EE SC and the SP-SM or the mutual authentication between the UID USC and the SP-SM is performed. , Or both.
[0294]
In the case of this example, AC01 and AC02 in the four group attribute certificates shown in FIG. 37 are issued for the user security chip (USC) of C's user identification device (UID). Since AC04 is issued to the security chip (SC) included in the television D as the end entity (EE), the processing is performed by using the user identification device (UID) of Mr. C as the end entity. The TV D serving as an end (EE) is connected via a connection device interface 231 (see FIG. 9), and the service provider (SP) is connected via a network interface 232 (see FIG. 9) of the TV D serving as an end entity (EE). ), Security module (SM), and mutual authentication between EE SC and SP-SM And, to perform both of the mutual authentication with the UID of USC and SP-SM.
[0295]
The authentication processing is executed as processing centering on the encryption processing unit of the security chip and the security module, for example, as the mutual authentication processing of the public key method described above with reference to FIG. If the mutual authentication is not established, the continuation of the processing is stopped. When the mutual authentication is established, in step S322, the user device transmits a plurality of group attribute certificates (Gp. AC) AC01 to AC04 stored in its own memory to the security module (SM) of the service provider (SP). I do. The group attribute certificates (Gp. AC) AC01 to AC04 are the four types of group attribute certificates shown in FIG.
[0296]
It should be noted that the service provider may notify the user of the combination data of the group attribute certificate required for providing the service. The service provider holds, for example, combination table data of group attribute certificates set as service provision conditions shown in FIG. In the example shown in FIG. 39, for example, in order to view content B as a service, a group attribute certificate as a student ID issued by University A, a group attribute certificate as an educational device certificate issued by MEXT, or the like is used. Data indicating the necessity is stored, and this table is applied to notify the user device of the presentation of the required group attribute certificate.
[0297]
In step S332, the security module (SM) that has received the four types of group attribute certificates (Gp. AC) AC01 to AC04 necessary for providing the service in this example from the user device sets the plurality of group attribute certificates in step S333. From the certificate, one group attribute certificate is sequentially selected and a verification process is executed. The verification process of the group attribute certificate is as described above with reference to FIGS. 21 to 23, and the signature verification of the attribute certificate, the related public key certificate (PKC) and the chain public key certificate are performed. It is executed as a process including a confirmation process and the like.
[0298]
After the verification process of the group attribute certificate (Gp. AC), if the verification is not successful (S334: No), the process is stopped without executing the service provision as an error process (S339). In this case, a process of notifying the end entity that the verification of the group AC has failed may be executed.
[0299]
If the verification of the group attribute certificate (Gp. AC) is established (S334: Yes) and the validity of the group attribute certificate (Gp. AC) is confirmed, the process proceeds to step S335. In step S335, the examination of the group attribute certificate (Gp. AC) described above with reference to FIG. 25 is executed. The examination is performed based on the group information database held by the service provider. That is, the service provider (SP) obtains the issuer information and the group ID from the verified group attribute certificate (Gp. AC), searches the group information database based on the obtained information, and searches for the registered entry. Check for presence. If there is a corresponding registration entry, the group information is acquired from the group information database. The group information in this case is information including content distribution permission information.
[0300]
If the examination of the group attribute certificate is not established (S336: No), for example, if acquisition of group information fails, the process is stopped without executing service provision as error processing (S339). In this case, a process of notifying the end entity that the verification of the group AC has failed may be executed.
[0301]
If the examination of the group attribute certificate is successful (S336: Yes), the process proceeds to step S337, and it is determined whether all the verifications and examinations of the presented group attribute certificate have been completed. Executes the verification and examination processing of step S333 and subsequent steps on the group attribute certificates for unfinished parts.
[0302]
If it is determined in step S337 that all the verifications and examinations of the presented group attribute certificate have been completed, the service is provided in step S338, and the service reception in step S340 is performed in the user device. Specifically, on the television D (see FIG. 37) as the end entity, the user C can view the distribution content.
[0303]
FIG. 40 is a schematic diagram showing the usage authority confirmation processing to which the above-described plurality of group attribute certificates are applied. That is, when the definition area of the group attribute certificate in which four types of different attributes are defined is indicated by the groups AC01 to AC04 shown in FIG. Thus, as shown in (b), the user ID belongs to the student ID card (group attribute certificate (AC01) and art class attendance certificate (AC02) belong to both groups) In addition, it is necessary to satisfy both conditions that the device has a management device certificate and an educational device certificate as device attributes.
[0304]
The proof of belonging to both the student ID card (group attribute certificate (AC01) and the art course attendance certificate (AC02)) as the user's group attribute shown in (a) is based on the user security of the user identification device (UID). The verification of the chip (USC) compatible group attribute certificate is confirmed and examined, and the management device certificate as the device group attribute shown in (b) and the certificate of the device holding the educational device certificate are end. It is confirmed by verification and examination of the group attribute certificate corresponding to the security chip (SC) of the entity (EE).
[0305]
In the flow described with reference to FIG. 39, the service is provided on condition that the verification and the examination of the four group attribute certificates are successful. However, the verification and the examination of the four group attribute certificates are performed. Performs a process of issuing a new group attribute certificate for permitting service provision, instead of executing the service on condition that the user succeeds, and presents the newly issued group attribute certificate to the user, By performing the verification, service can be provided.
[0306]
However, in this case, the newly issued group attribute certificate defines both the user group and the device group, and a user identification device (UID) that matches the group definition is replaced with a device (EE) that matches the group definition. ), Mutual authentication between the UID security chip (USC) and the service provider (SP) security module (SM) establishes the UID security chip (USC) authentication, and furthermore, the end entity (EE) Authentication of the security chip (SC) is achieved by mutual authentication between the security chip (SC) of the service provider (SP) and the security module (SM) of the service provider (SP), and the verification and examination of the above-mentioned new issuance group attribute certificate are completed. Is the service usage condition.
[0307]
(5-2) Remote control service
Next, as an example of the data processing system configuration based on the group attribute certificate, a service usage example of executing authority confirmation and executing remote control of a device as an end entity (EE) will be described.
[0308]
Here, a medical device is set as an end entity (EE), communication is performed between a medical device installed at home or the like and a hospital-side medical device (SP) as a service provider, and the hospital-side medical device is operated. Based on the command transmitted from the (SP), the medical equipment (EE) installed at home performs medical diagnosis, examination, and the like of the user, and obtains information such as test data from the medical equipment (EE) installed at home to the hospital. A medical processing example transmitted to the medical device (SP) will be described.
[0309]
At the time of execution of each process in the data processing system that executes the above-described medical process, a process of checking whether or not the process is executable based on verification and examination of the group attribute certificate is performed. Various data processing related to the procedure is executed. FIG. 41 shows an example of a group attribute certificate to be applied.
[0310]
The group attribute certificate AC01 authenticates the issuer with the hospital-side medical device as a service provider (SP) and the owner, that is, the hospital-side medical device (SP) as the issuer when the group attribute certificate AC01 is issued. The owner whose group attribute certificate is to be issued by performing the process is the user security chip (USC) of the user identification device (UID) of the user Ko who receives medical service by the home-side medical device (EE). . Alternatively, the security chip (SC) of the home-side medical device (EE) may be used.
[0311]
This group attribute certificate AC01 is applied at the time of confirmation processing for determining whether or not the medical program can be executed. The group attribute certificate AC01 is sent from the USC or SC of the user device, which is the owner, to the hospital-side medical device (SP), and the hospital-side medical device (SP) is After the device (SP) verifies and examines the group attribute certificate AC01, the service, that is, the execution of the medical diagnosis program is permitted.
[0312]
The issuer of the group attribute certificate AC02 is that the issuer is the home-side medical device (EE) and performs authentication processing with the owner, that is, the issuer home-side medical device (EE) when the group attribute certificate AC02 is issued. The owner for whom the group attribute certificate has been issued is the security module (SM) of the hospital-side medical device as the service provider (SP).
[0313]
The group attribute certificate AC02 is obtained from the person to be diagnosed (Mr. Ko) by executing the medical program, and diagnostic data such as blood pressure value, pulse, blood sampling data, etc. is transferred from the home medical device (EE) to the hospital. This is applied to the execution possibility determination process of the process to be transmitted to the medical device (SP).
[0314]
The group attribute certificate AC02 is sent from the hospital-side medical device (SP) to the home-side medical device (EE), and the home-side medical device (EE) verifies and examines the group-attribute certificate AC02. That is, transmission processing of medical diagnosis result data is executed.
[0315]
The issuance processing of the group attribute certificates AC01 and AC02 is performed by the hospital-side medical device (SP) or the home-side medical device (EE), or the user identification device (UID) itself by the group attribute certification authority (group AA) and the group It is possible to execute the function of the attribute certificate registration authority (group ARA) and issue it on its own, but issue it by requesting the group attribute certificate authority (group AA) and the group attribute certificate registration authority (group ARA) A configuration for performing the processing is also possible. However, in this case, it is a condition that processing according to the policy of the issuer is executed.
[0316]
For example, the issuance processing of the group attribute certificate AC01 is performed by the hospital side medical device (SP), which is the issuer, or the group attribute certificate registration authority (group ARA), which performs issuance proxy, from Mr. Ko as a medical diagnosis subject. A group attribute certificate that has already been issued to prove Mr. Ko, for example, a group attribute certificate issued by a credit card company is presented, and after the submitted group attribute certificate is verified, a new group attribute is issued. It is preferable to adopt a method of performing a process of issuing the certificate AC01. The processing sequence for issuing a new group attribute certificate on condition that such an already issued group attribute certificate is verified is similar to the processing sequence described above with reference to FIGS. 29, 30, 32, and the like. It becomes.
[0317]
Similarly, in the issuance processing of the group attribute certificate AC02, the home side medical device (EE), which is the issuer, or the group attribute certificate registration authority (group ARA), which performs the issuance proxy, also sends the hospital side medical device (EE). SP), an already issued group attribute certificate for certifying that the device is a hospital-side medical device (SP), for example, a group attribute certificate issued by a manufacturer or a public management organization is presented, and the submitted group attribute is presented. It is preferable to adopt a method of performing a process of issuing a group attribute certificate AC02 after verifying the certificate.
[0318]
In a remote control system for performing medical processing, attribute certificates stored in each device are as shown in FIG. The hospital-side medical device (SP) 401 as a service provider and the home-side medical device (EE) 411 as an end entity can mutually transfer data through a communication network, and the home-side medical device (EE) 411 and the user The identification device (UID) 421 can mutually transfer data via both connected device interfaces 231 (see FIG. 9).
[0319]
Each device is provided with a (user) security chip 412 or 423 or a security module 403 having a tamper-resistant configuration, and executes mutual authentication processing during data communication processing, encryption and decryption processing of transfer data, and the like. . The verification process of the group attribute certificate is also executed in the (user) security chip 412, 423 or the security module.
[0320]
The user identification device 421 stores the group attribute certificates AC01 and 422 described above with reference to FIG. The group attribute certificates AC01 and 422 are applied when the issuer is the hospital-side medical device (SP) 401 as a service provider and is used in a confirmation process for determining whether a medical program can be executed. Is transmitted to the hospital-side medical device (SP) 401 from the USC 421, and the security module (SM) 403 of the hospital-side medical device (SP) 401 verifies and examines the group attribute certificate AC01, and then provides a service, that is, a medical diagnosis. The program runs.
[0321]
The hospital-side medical device (SP) 401 as a service provider stores group attribute certificates AC02 and AC402. In the group attribute certificates AC02 and 402, the issuer is the home medical device (EE) 411, the owner is the hospital medical device (SP) 401, and the hospital medical device (SP) is the home medical device. (EE), and transmits the diagnostic data obtained from the diagnosis target person (Mr. Ko) to the home-side medical device (EE) 411 prior to transmission processing from the home-side medical device (EE) 411 to the hospital-side medical device (SP) 401. In the security chip (SC) 412 of the EE) 411, the verification and examination of the group attribute certificates AC02 and 402 are executed, and the transmission of the diagnosis result data is executed on condition that the verification and examination are successful.
[0322]
With reference to FIG. 43, a description will be given of a processing sequence in which the use right confirmation processing of the execution service of the medical diagnosis program is performed by applying the group attribute certificates AC01 and 422 stored in the user identification device 421, and the service is started. In FIG. 43,
UID: user identification device (user device) control unit,
USC: User security chip configured in UID,
EE: Home side medical device (EE) controller,
SC: security chip configured in EE,
SP: Hospital side medical device (SP) control unit,
SM: Security module in SP,
It is.
[0323]
The security chip (SC), the user security chip (USC), and the security module (SM) have a configuration similar to that of the security chip of FIG. 9 described above, and the authority determination processing by verifying the group attribute certificate in the security module or chip. Etc. are executed. That is, the service provider or the user device, which receives the service, here the group attribute certificate sent from the data processing request source device to the data processing request destination by the receiving unit such as the network interface, determines the authority of the received group attribute certificate. It passes to the security module (chip) as a processing unit, executes authority determination processing based on the group attribute certificate received in the security module (chip), and executes various data processing based on authority determination. I do.
[0324]
First, in step S321, the user inputs a use request command of group attribute certificate (Gp. AC) = AC01 via the input interface of the home-side medical device (EE) as the end entity. This group attribute certificate (Gp. AC) is AC01 shown in FIGS. In this process, the user specifies the group ID set in the group attribute certificate AC01 to be used. However, when a unique group ID can be determined by specifying a specific service, only the service may be specified.
[0325]
When the home medical device (EE) receives the use request input of the group attribute certificate (Gp. AC) AC01 from the user, in step S322, the user medical chip (USC) and the hospital medical device ( Mutual authentication between the security modules (SM) of the SP) is performed. Although omitted here, in the case of a user identification device (UID) that cannot directly execute communication with the SP,
(1) Mutual authentication between EE SC and SP-SM,
(2) Mutual authentication between EE SC and UID USC,
(3) Mutual authentication between USC of UID and SP-SM,
Will do everything. Alternatively, as a simple method, the EE may be connected to the EE so that the EE basically accepts (authenticates) the EE. In this case, the mutual authentication described in (2) above is performed. Can be omitted. Further, an authentication configuration based on various combinations of the above three types of mutual authentication is possible.
[0326]
The authentication process is performed as a process centered on the encryption processing unit (see FIG. 9) of the security chip and the security module, for example, as a mutual authentication process of the public key method described above with reference to FIG. In step S323, the user security chip outputs a mutual authentication completion notification including information on the result of successful or unsuccessful mutual authentication to the end entity. If the mutual authentication is not established, the continuation of the processing is stopped. When the mutual authentication is established, in step S324, the user security chip (USC) transmits the group attribute certificate (Gp. AC) AC01 stored in its own memory to the security module (SM) of the service provider (SP). I do. This group attribute certificate (Gp. AC) is a group attribute certificate AC01 applied to the processing for determining the service receiving qualification authority of the medical program, as described above with reference to FIGS.
[0327]
In step S325, the security module (SM) of the hospital-side medical device (SP) that has received the group attribute certificate (Gp. AC) AC01 from the user security chip (USC) executes a group attribute certificate verification process. The verification process of the group attribute certificate is as described above with reference to FIGS. 21 to 23, and the signature verification of the attribute certificate, the related public key certificate (PKC) and the chain public key certificate are performed. It is executed as a process including a confirmation process and the like.
[0328]
After the verification process of the group attribute certificate (Gp. AC), the security module (SM) outputs the verification result to the hospital-side medical device (SP). If the verification is not successful, the security module (SM) executes service provision as error processing. Cancel processing. In this case, a process of notifying the end entity that the verification of the group AC has failed may be executed.
[0329]
When the verification of the group attribute certificate (Gp. AC) succeeds and the validity of the group attribute certificate (Gp. AC) is confirmed, the process proceeds to step S327. In step S327, examination of the group attribute certificate (Gp. AC) described above with reference to FIG. 25 is executed. The examination is performed based on the group information database held by the hospital-side medical device (SP) as a service provider. That is, the hospital-side medical device (SP) acquires issuer information and group ID from the verified group attribute certificate (Gp. AC) AC01, searches the group information database based on the acquired information, and registers the acquired information. Check for entries. If there is a corresponding registration entry, the group information is acquired from the group information database.
[0330]
The group information in this case includes the execution permission information of the medical diagnosis program. In step S328, the hospital-side medical device (SP) as a service provider performs a service providing process, that is, executes a medical diagnosis program according to group information. That is, a medical diagnosis process by a remote control, that is, an execution command of various diagnostic programs is transmitted to the home medical device (EE) and the user is diagnosed via the home medical device (EE).
[0331]
Next, referring to FIG. 44, by using the group attribute certificate AC02, 402 stored in the hospital-side medical device (SP) 401, the use authority check of the diagnostic data collection processing service as the execution result of the medical diagnostic program is confirmed. A processing sequence for performing processing and starting a service will be described.
[0332]
First, in step S331, the user who operates the hospital system inputs a use request command of group attribute certificate (Gp. AC) = AC02 via the input interface of the hospital medical device (SP). This group attribute certificate (Gp. AC) is AC02 shown in FIGS. In this process, the user who operates the hospital system specifies the group ID set in the group attribute certificate AC02 to be used. However, when a unique group ID can be determined by specifying a specific service, only the service may be specified.
[0333]
When the hospital-side medical device (SP) receives the use request input of the group attribute certificate (Gp. AC) AC02, in step S332, the user-side security chip (USC) and the hospital-side medical device (SP) as a service provider are received. Mutual authentication between security modules (SM) is performed. Although omitted here, in the case of a user identification device (UID) that cannot directly execute communication with the SP,
(1) Mutual authentication between EE SC and SP-SM,
(2) Mutual authentication between EE SC and UID USC,
(3) Mutual authentication between USC of UID and SP-SM,
Will do everything. Alternatively, as a simple method, the EE may be connected to the EE so that the EE basically accepts (authenticates) the EE. In this case, the mutual authentication described in (2) above is performed. Can be omitted. Further, an authentication configuration based on various combinations of the above three types of mutual authentication is possible.
[0334]
The authentication process is performed as a process centered on the encryption processing unit (see FIG. 9) of the security chip and the security module, for example, as a mutual authentication process of the public key method described above with reference to FIG. In step S333, the security module (SM) outputs a mutual authentication completion notification including information on the result of establishment / failure of the mutual authentication to the hospital-side medical device (SP). If the mutual authentication is not established, the continuation of the processing is stopped. If the mutual authentication is established, in step S334, the security module (SM) of the hospital-side medical device (SP) transmits the group attribute certificate stored in its own memory to the user security chip (USC) of the home-side medical device. (Gp. AC) AC02 is transmitted. This group attribute certificate (Gp. AC) is the group attribute certificate AC02 applied to the process of determining the right to process the diagnosis result data as described above with reference to FIGS.
[0335]
The user security chip (USC) that has received the group attribute certificate (Gp. AC) AC02 from the security module (SM) of the hospital-side medical device (SP) executes a group attribute certificate verification process in step S335. The verification process of the group attribute certificate is as described above with reference to FIGS. 21 to 23, and the signature verification of the attribute certificate, the related public key certificate (PKC) and the chain public key certificate are performed. It is executed as a process including a confirmation process and the like.
[0336]
After the verification process of the group attribute certificate (Gp. AC), the user security chip (USC) outputs the verification result to the home-side medical device (EE) (S336). Cancels processing without executing the result transmission service. In this case, a process of notifying the hospital-side medical device (SP) that the verification of the group AC has failed may be executed.
[0337]
If the verification of the group attribute certificate (Gp. AC) succeeds and the validity of the group attribute certificate (Gp. AC) is confirmed, the process proceeds to step S337. In step S337, examination of the group attribute certificate (Gp. AC) described above with reference to FIG. 25 is performed. The examination is performed based on the group information database held by the home-side medical device (EE). That is, the home-side medical device (EE) acquires the issuer information and the group ID from the verified group attribute certificate (Gp. AC) AC02, searches the group information database based on the acquired information, and registers the information. Check for entries. If there is a corresponding registration entry, the group information is acquired from the group information database.
[0338]
The group information in this case includes the diagnosis result transmission permission information of the medical diagnosis program. In step S338, the home-side medical device (EE) executes a service providing process, that is, a diagnosis result transmission process of the medical diagnosis program according to the group information. That is, a process of transmitting the medical diagnosis processing result from the home medical device (EE) to the hospital medical device (SP) is executed.
[0339]
(5-3) Remote maintenance service
Next, as a configuration example of a data processing system that executes data processing by executing authority confirmation based on a group attribute certificate, a service that executes remote maintenance of a device as an end entity (EE), for example, a home electric appliance A usage example will be described.
[0340]
Here, various home appliances such as AV devices, air conditioners, and refrigerators having a communication function are provided as end entities (EEs), and these home appliances installed at homes and the like, and services provided by home appliance manufacturers as service providers are provided. Executes communication with the device (SP) and performs repair, maintenance, upgrade, and other control processing of the home electric appliance (EE) installed at home based on an instruction transmitted from the service providing device (SP) on the manufacturer side. An example of execution will be described.
[0341]
When each of the above-described processes is executed, a process of checking whether or not the process can be executed is performed based on verification and examination of the group attribute certificate. After the execution is confirmed, each process is executed. FIG. 45 shows an example of a group attribute certificate to be applied. Group attribute certificates are roughly classified into two categories. One is a service attribute certificate (AC) and the other is a control attribute certificate (AC).
[0342]
The service attribute certificate (AC) is a device in which the issuer is a home appliance maker side device as a service provider (SP), and the owner, that is, the home appliance maker that is the issuer when the service attribute certificate (AC) is issued. The owner whose attribute certificate has been issued by performing the authentication process with the device (SP) can use the user security chip (UID) of the user identification device (UID) of the user who uses the home electric appliance (EE) installed at home or the like. USC) or a security chip (SC) of an electric home appliance (EE).
[0343]
This service attribute certificate is used for the subsequent repair, maintenance, upgrade, and other control processing of the home electric appliance (EE) by signing a subscriber contract between the user who purchased the home electric appliance and the manufacturer when purchasing the home electric appliance. It is issued to a home appliance purchaser group or a home appliance group that has been authorized to receive the service. Therefore, the service attribute certificate is a group attribute certificate issued to the household electric appliance purchaser group or the household electric appliance group.
[0344]
In the case of issuance for a household appliance purchaser group, issuance processing is performed on condition that mutual authentication between the user security chip (USC) of the user identification device (UID) and the security module of the household appliance manufacturer (SP) is established. When the home appliance group is issued, the issuance process is performed on condition that mutual authentication between the security chip (SC) of the home appliance (EE) and the security module of the home appliance manufacturer (SP) is established.
[0345]
The service attribute certificate is sent from the home electric appliance (EE) or the user identification device (UID) to the manufacturer's device (SP) when a request for repair, maintenance, upgrade, or other control service of the electric home appliance (EE) is made. Then, in the maker-side device (SP), after verification and examination of the service attribute certificate, the service is shifted to providing the service.
[0346]
The control attribute certificate is an electric home appliance (EE) whose issuer receives repair, maintenance, upgrade, and other control services, and the owner, ie, the electric home appliance (EE) that is the issuer when the control attribute certificate is issued. The owner whose group attribute certificate is to be issued by performing the authentication process is the security module (SM) of the maker-side device as the service provider (SP).
[0347]
The control attribute certificate is a certificate issued between the user who purchased the home electric appliance and the manufacturer on condition that the service attribute certificate is held after the purchase of the home electric appliance. A user having a home electric appliance issues a certificate to the manufacturer side device, which is a service provider, in correspondence with each electric home appliance as a certificate in which a maintenance service execution range for each home electric appliance is authority information. Alternatively, it is also possible to issue different control authority information to one home electric appliance as a certificate in which each is recorded. For example, as control information of a home appliance, an attribute certificate indicating that only an upgrade process is permitted as a receiving service for a software upgrade process request, or indicating that only an inspection process for a periodic check is permitted. Attribute certificate, etc.
[0348]
The control attribute certificate is, for example, a group attribute certificate that can be issued for a plurality of home electric appliance groups owned by one user or a plurality of home electric appliances. In the case where a plurality of home electric appliance groups owned by one user are issued, mutual authentication between a user security chip (USC) of a user identification device (UID) and a security module of an electric home appliance manufacturer (SP) is required. When the issuance process is performed and a specific home electric appliance is issued, the security chip (SC) of the above-mentioned UID USC or the specific home electric appliance (EE) and the security module of the home electric appliance manufacturer (SP) are used. Issuance processing is performed on condition that mutual authentication between the parties is established.
[0349]
This control attribute certificate is issued by the user (EE or UID) and stored in the maker device that provides the service, and is used when repairing, maintaining, upgrading the home electric appliance (EE), and performing other control services. Is transmitted to the user side (EE or UID), and the user side (EE or UID) verifies and examines the control attribute certificate, and then shifts to service provision.
[0350]
The service attribute certificate and the control attribute certificate are issued by the manufacturer device (SP) or the home electric appliance (EE) or the user identification device (UID) by the group attribute certificate authority (group AA) and the group attribute. It is possible to issue a certificate by executing the function of a certificate registration authority (Group ARA), but it issuance processing by requesting a group attribute certificate authority (Group AA) and a group attribute certificate registration authority (Group ARA). Is also possible. However, in this case, it is a condition that processing according to the policy of the issuer is executed.
[0351]
For example, the service attribute certificate issuance processing is performed by the maker device (SP), which is the issuer, or the group attribute certificate registration authority (group ARA), which performs issuance proxy, from the user who intends to provide the service to the user himself. A group attribute certificate that has already been issued, for example, a group attribute certificate issued by a credit card company is presented. After verifying the submitted group attribute certificate, the service is provided as a new group attribute certificate. Issue an attribute certificate or have home appliances present a group attribute certificate that proves that they belong to the manufacturer's product group stored by the manufacturer at the time of manufacture, and verify the submitted group attribute certificate And then issue a service attribute certificate as a new group attribute certificate It is preferred to carry out the management. The processing sequence for issuing a new group attribute certificate on condition that such an already issued group attribute certificate is verified is similar to the processing sequence described above with reference to FIGS. 29, 30, 32, and the like. It becomes.
[0352]
Similarly, in the process of issuing the control attribute certificate, the home appliance (EE), which is the issuer, or the group attribute certificate registration authority (group ARA), which performs the issuing proxy, sends the control attribute certificate from the manufacturer device (SP). An already issued group attribute certificate that proves that the device is a genuine device on the manufacturer side, for example, as described above, a service attribute certificate as a group attribute certificate issued by the manufacturer is presented, and the After performing the verification, it is preferable to adopt a method of performing a process of issuing a control attribute certificate as a new group attribute certificate.
[0353]
In the system for performing the maintenance service, the attribute certificates stored in each device are as shown in FIG. The maker-side device (SP) 451 as a service provider and the user-side home electric appliance (EE) 461 as an end entity can mutually transfer data through a communication network, and the user-side home electric appliance (EE) 461 and the user The identification device (UID) 471 can mutually transfer data via both connection device interfaces 231 (see FIG. 9).
[0354]
Each device is provided with a (user) security chip 463, 472 or a security module 453 having a tamper-resistant configuration, and executes mutual authentication processing during data communication processing, encryption and decryption processing of transfer data, and the like. . The verification process of the group attribute certificate is also executed by the (user) security chip 463, 472 or the security module 453.
[0355]
The user side home electric appliance (EE) 461 stores the service attribute certificate 462 described above with reference to FIG. The service attribute certificate 462 is applied when the issuer is the manufacturer's device (SP) 451 as a service provider, and is applied at the time of confirmation processing for determining whether or not maintenance or repair of home appliances can be performed. It is sent from the SC 463 of the home electric appliance (EE) 461 to the manufacturer's device (SP) 451. After verification and examination in the security module (SM) 453 of the maker-side device (SP) 451, processing such as service, that is, transmission of the control attribute certificate, and maintenance in the authority range permitted by the control attribute certificate are executed. You.
[0356]
A control attribute certificate 452 is stored in a maker-side device (SP) 451 as a service provider. In the control attribute certificate 452, the issuer is the user-side home electric appliance (EE) 461, the owner is the maker-side electric device (SP) 451, and the manufacturer-side electric device (SP) is the user-side electric home appliance (EE) 461. Before the execution of services such as maintenance, the security attribute (SC) 463 of the user-side home electric appliance (EE) 461 performs verification and examination of the control attribute certificate. Processing such as repair or upgrade is executed within the authority range confirmed by the control attribute certificate.
[0357]
A usage pattern of the service attribute certificate and the control attribute certificate when executing the service will be described with reference to FIG. First, a service attribute certificate (AC) 484 is provided by a manufacturer device (SP) from a home appliance (EE) or a user identification device (UID) connected to the home appliance that wants to receive services such as maintenance, repair, inspection, and upgrade. 482. After verifying the service attribute certificate in the security module (SM), the manufacturer-side device (SP) 482 searches the group information database 483 based on the group ID corresponding to the service attribute certificate, and searches for the group information as group information. The control AC or the identification data of the control AC is extracted, and the control AC corresponding to the service AC is obtained.
[0358]
The maker-side device (SP) 482 transmits the obtained control attribute certificate (AC) 485 to the home electric appliance (EE) or the user identification device (UID) connected to the home electric appliance, and transmits the control attribute certificate (AC) 485 to the home electric appliance (EE) or the home electric appliance. After verification by the security chip of the connected user identification device (UID), a service such as maintenance is performed on the home electric appliance (EE) according to the control information permitted by the control attribute certificate (AC).
[0359]
The execution program for maintenance, repair, upgrade, etc. may use a program stored in the memory of the home appliance in advance, or may be transmitted from the manufacturer device to the home appliance as needed and executed. It is good also as a structure which performs. In transmitting the execution program, it is preferable to execute an authentication process and a transmission data encryption process.
[0360]
Next, referring to FIG. 48 et seq., A service attribute certificate stored in a home appliance (EE) as a user device and a control attribute certificate stored in a service provider are applied to provide services such as maintenance of the home appliance. A description will be given of a processing sequence for performing a use authority confirmation process for starting a service. In FIG. 48,
EE: user-side home electric appliance (EE) control unit,
SC: security chip configured in EE,
SP: Manufacturer side device (SP) control unit,
SM: Security module in SP,
It is.
[0361]
The security chip (SC), the user security chip (USC), and the security module (SM) have a configuration similar to that of the security chip of FIG. 9 described above, and the authority determination processing by verifying the group attribute certificate in the security module or chip. Etc. are executed. That is, the service provider or the user device, which receives the service, here the group attribute certificate sent from the data processing request source device for maintenance processing to the data processing request destination by the receiving unit such as the network interface, receives the received group attribute certificate. The certificate is passed to a security module (chip) as an authority determination processing unit, and authority determination processing is executed based on the group attribute certificate received in the security module (chip). Perform data processing.
[0362]
First, in step S341, the user issues a use request command for a service attribute certificate (AC), which is a group attribute certificate (Gp. AC), via an input interface of the user-side home electric appliance (EE) as an end entity. input. In this process, the user specifies the group ID set in the service attribute certificate (AC) to be used. However, when a unique group ID can be determined by specifying a specific service, only the service may be specified.
[0363]
When the user-side home electric appliance (EE) receives the use request input of the service attribute certificate (AC) from the user, in step S342, the security chip (SC) and the security module of the maker-side device (SP) as a service provider are provided. (SM) mutual authentication is performed. Here, an example of using the service attribute certificate for the security chip (SC) of the home electric appliance (EE) is shown, but the user security chip (SC) of the user identification device (UID) is issued. A process using the service attribute certificate described above is also possible. However, in the case of a user identification device (UID) that cannot execute communication with the SP directly,
(1) Mutual authentication between EE SC and SP-SM,
(2) Mutual authentication between EE SC and UID USC,
(3) Mutual authentication between USC of UID and SP-SM,
Will do everything. Alternatively, as a simple method, the EE may be connected to the EE so that the EE basically accepts (authenticates) the EE. In this case, the mutual authentication described in (2) above is performed. Can be omitted. Further, an authentication configuration based on various combinations of the above three types of mutual authentication is possible.
[0364]
The authentication process is performed as a process centered on the encryption processing unit (see FIG. 9) of the security chip and the security module, for example, as a mutual authentication process of the public key method described above with reference to FIG. In step S343, the security chip outputs a mutual authentication completion notification including information on the result of establishment or non-establishment of mutual authentication to the end entity. If the mutual authentication is not established, the continuation of the processing is stopped. When the mutual authentication is established, in step S344, the security chip (SC) transmits the service attribute certificate stored in its own memory to the security module (SM) of the service provider (SP), which is the manufacturer side device.
[0365]
In step S345, the security module (SM) of the maker-side device (SP) that has received the service attribute certificate from the security chip (SC) of the user-side home electric device executes a service attribute certificate verification process. The verification process of the service attribute certificate is as described above with reference to FIGS. 21 to 23. The signature verification of the attribute certificate, the related public key certificate (PKC) and the chain public key certificate are performed. It is executed as a process including a confirmation process and the like.
[0366]
After the service attribute certificate verification process, the security module (SM) outputs the verification result to the manufacturer device (SP). If the verification is not successful, the security module (SM) stops the process without providing the service as an error process. In this case, a process of notifying the end entity that the verification of the service attribute certificate has failed may be executed.
[0367]
If the service attribute certificate is successfully verified and the validity of the service attribute certificate is confirmed, the process proceeds to step S347. In step S347, examination of the service attribute certificate is performed. The examination is performed based on the group information database held by the manufacturer device (SP) as a service provider.
[0368]
The examination process of the service attribute certificate will be described with reference to FIG. In step S351, the service provider (SP) acquires a group ID as an attribute value from the verified service attribute certificate. In step S352, a group information database is searched based on the group ID acquired from the service attribute certificate (S352), and control attribute certificate information, for example, an identifier (ID) of the control attribute certificate is obtained from the registered entry. It is acquired (S353).
[0369]
As shown in FIG. 49, the issuer, the group ID of the service AC, and the corresponding control attribute certificate information as the group information, for example, the ID are stored in association with the group information database (DB) held by the service provider. The service provider (SP) searches the group information database (DB) based on the group ID obtained from the service attribute certificate (AC) received from the user-side home electric appliance and verified and obtains the group information as group information. , And acquires the specific information of the control attribute certificate (AC) corresponding to the service AC.
[0370]
Next, in step S348 (FIG. 48), the maker-side device (SP) as a service provider determines the control attribute certificate (AC) based on the ID of the control attribute certificate (AC) acquired from the group information database (DB). AC).
[0371]
Next, see FIG. 50 et seq. For the sequence in which the service provider receiving the service attribute certificate executes a service based on the control attribute certificate, for example, processing such as maintenance, inspection, repair, upgrade, or control of home electric appliances. Will be explained.
[0372]
In step S370 in FIG. 50, the operator operating the maker-side device inputs a maintenance process execution command to which the control attribute certificate is applied, via the input interface of the maker-side device (SP). At this time, the operator specifies the group ID set in the control attribute certificate to be used.
[0373]
When the manufacturer device (SP) receives the maintenance processing execution request input to which the control attribute certificate is applied, in step S371, the security chip (SC) of the home electric appliance (EE) and the manufacturer device (SP) as a service provider are provided. Mutual authentication between the security modules (SM) is performed. Note that when the service providing sequence based on the control attribute certificate shown in FIG. 50 is executed in the same session as the service attribute certificate verification process sequence described with reference to FIG. 48, this mutual authentication process is unnecessary. It becomes.
[0374]
If the authentication process has been executed, in step S372, a mutual authentication completion notification including information on the result of the establishment or non-establishment of the mutual authentication is output from the security module (SM) to the manufacturer device (SP). If the mutual authentication is not established, the continuation of the processing is stopped. If the mutual authentication is established, in step S373, the security module (SM) of the maker-side device (SP) extracts the security module (SC) of the user-side home appliance based on the received service attribute certificate. Send the control attribute certificate. As described above, this control attribute certificate is a group attribute certificate applied to the process of confirming the control range processing authority for the home electric appliance.
[0375]
In step S374, the security chip (SC) that has received the control attribute certificate from the security module (SM) of the manufacturer device (SP) executes a control attribute certificate verification process. The verification process of the control attribute certificate is as described above with reference to FIGS. 21 to 23. The signature verification of the attribute certificate and the confirmation of the related public key certificate (PKC) and the chain public key certificate are performed. It is executed as processing including processing.
[0376]
After the control attribute certificate verification processing, the security chip (SC) outputs the verification result to the user-side home electric appliance (EE) (S375). If the verification is not successful (S376: NG), the security chip (SC) performs error processing (S377). The execution of processing such as maintenance is stopped. In this case, a process for notifying the manufacturer device (SP) that the verification of the control attribute certificate has failed may be executed.
[0377]
If the verification of the control attribute certificate is successful (S376: OK) and the validity of the control attribute certificate is confirmed, the process proceeds to step S378. In step S378, the home electric appliance (EE) searches for a maintenance execution program. The maintenance execution program is a program stored in advance in the memory in the home electric appliance (EE) in association with the control attribute certificate ID or the group ID, or transmitted from the manufacturer device (SP) at the time of executing the process. Yes, encrypted as needed. In the sequence diagram, the maintenance execution program is an example in which the home appliance (EE) is stored in advance in association with the control attribute certificate ID or the group ID.
[0378]
In step S379, the home appliance (EE) transfers the extracted encryption maintenance program to the security chip (SC). In step S380, the security chip (SC) executes decryption processing. The decryption processing is executed based on, for example, a key provided from a service provider (SP) side, a key unique to each user device, or the like. Various processing methods such as a public key method and a common key method can be adopted as the encryption processing mode of the program. The key may be provided to the security chip using an attribute certificate storing the key.
[0379]
In step S381, the maintenance program decrypted from the security chip (SC) is output to the end entity (EE) as the home electric appliance. In step S382, the maintenance program is executed. After the execution of the program is completed, in step S383, The execution result is transmitted to the service provider (SP).
[0380]
FIG. 51 shows a sequence in which the service provider that has received the service attribute certificate executes a service based on the control attribute certificate, for example, processing such as maintenance, inspection, repair, upgrade, control, or the like for home electric appliances, as in FIG. This is an example in which the maintenance execution program is transmitted from the manufacturer device (SP) to the user home electric appliance (EE). Steps S384 to S392 correspond to steps S370 to S377 in FIG.
[0381]
In step S393 after the verification of the control AC is completed, a request for transmitting a maintenance program is output from the user-side home electric appliance (EE) to the maker-side device (SP). In step S394, the maker-side device as a service provider is activated. The processing sequence for executing the search for the maintenance program and transmitting the program searched for in step S395 to the user-side home electric appliance (EE) is different from the processing sequence in FIG.
[0382]
Note that the transmission program is encrypted as necessary. For example, it is encrypted and transmitted based on a session key, a key provided by a service provider (SP), or a key unique to each user device, and transmitted. Various processing methods such as a public key method and a common key method can be adopted as the encryption processing mode of the program. The key may be provided to the security chip using an attribute certificate storing the key.
[0383]
The processing sequence in FIG. 52 is similar to that in FIGS. 50 and 51. In the processing sequence shown in FIGS. 50 and 51, the service provider receiving the service attribute certificate performs a service based on the control attribute certificate, such as maintenance, inspection, repair, upgrade, control, or the like for home electric appliances. In this sequence, the maintenance execution program is sent from the maker's device (SP) to the home appliance (EE), and a response based on the command execution is received from the home appliance (EE). Is executed.
[0384]
Steps S410 to S420 correspond to steps S384 to S394 in FIG. In step S421, the service provider (SP) encrypts the command according to the maintenance program as necessary and transmits the command to the home electric appliance (EE). In step S422, the home electric appliance (EE) transmits the encrypted command to the security chip. Handover, decryption in the security chip (SC) (S423), and delivery of a decryption command from the security chip (SC) (S424), and then execute the command in the home electric appliance (EE) (S425), and use the execution result as a command execution response. The service is transmitted from the home electric appliance (EE) to the service provider (SP), and the service provider (SP) having received the response transmits a next execution command based on the response to the home electric appliance (EE).
[0385]
When the execution of all the commands according to the maintenance program ends, in step S427, the maintenance program execution processing ends.
[0386]
In the above-described maintenance processing mode, the service attribute certificate is presented from the user's home appliance to the manufacturer's device, while the manufacturer's device presents the control attribute certificate to the home appliance, and the attribute certificates are mutually exchanged. This is a form in which verification and examination of the service are executed to confirm the authority of receiving or providing the service.
[0387]
The use form of the service attribute certificate and the control attribute certificate is not limited to the above-described processing form. For example, as shown in FIG. 493 and the control attribute certificate 494 are presented to the maker (SP) 492, and the maker (SP) 492 performs verification and examination of the service attribute certificate 493 and the control attribute certificate 494, and copes with both. After confirming the relationship, the maintenance process within the range of authority indicated by the control attribute certificate 494 may be performed on the user-side device 491.
[0388]
In addition, the home appliance stores a program for automatically executing maintenance at regular intervals, sends a maintenance request with a service attribute certificate to the manufacturer at a programmed time interval, and the manufacturer receives the control attribute based on the received request. The form of transmitting the certificate and executing the maintenance processing may be adopted.
[0389]
(5-4) Personal communication service
Next, an example of using a communication service using a PC, PDA, or other communication terminal as an end entity (EE) by executing authority confirmation based on a group attribute certificate will be described.
[0390]
Here, a PC, PDA, or other communication terminal is used as an end entity (EE), and a communication terminal installed at home or the like connects to a server of a service provider that provides a chat room, and communicates via the chat room. An example will be described in which communication service is performed by executing access restriction processing using a group attribute certificate in communication between end entities (EE) and direct communication between end entities (EE). FIG. 54 shows an example of a group attribute certificate applied in the communication service.
[0391]
In the group attribute certificate AC01, the issuer is a chat operator as a service provider (SP), and performs authentication processing with the owner, that is, the chat operation service provider (SP) as the issuer when the group attribute certificate AC01 is issued. The owner who becomes the subject of issuing the group attribute certificate AC01 by performing the above is the security chip (SC) of the end entity (EE) as the communication terminal of the user Ko or the user identification device (UID) of the user Ko ) Is a user security chip (USC).
[0392]
The group attribute certificate AC01 is an attribute certificate for certifying that the user has an access right to a server constituting a chat room provided by a chat operation service provider (SP), and a user who has authority to participate in the chat room. Issued to a group or user equipment group.
[0393]
The group attribute certificate AC02 is a security chip of the user device (EE or UID) of the issuer, and the owner, that is, the issuer of the user device of the issuer when the group attribute certificate AC02 is issued. The owner who has been issued the group attribute certificate AC02 by performing the authentication process with the SC or USC is the security chip (SC or USC) of Mr. Ko's user device.
[0394]
The group attribute certificate AC02 is an attribute certificate for certifying that the user has an access right to the management server of the user device, and is a user group or a user having the authority to access the management server of the user device of the user. Issued to a device group.
[0395]
The issuance processing of the group attribute certificates AC01 and AC02 is performed by the service provider (SP), the end entity (EE) as the user's user device, or the user identification device (UID) itself by the group attribute certificate authority (group AA). It is possible to execute the functions of the Group Attribute Certificate Registration Authority (Group ARA) and issue it on its own, but request the Group Attribute Certification Authority (Group AA) and Group Attribute Certificate Registration Authority (Group ARA) It is also possible to employ a configuration in which the issuing process is performed. However, in this case, it is a condition that processing according to the policy of the issuer is executed.
[0396]
For example, the issuance processing of the group attribute certificates AC01 and AC02 is performed by the service provider (SP) as the issuer, the user device (EE, UID) of the second party, or the group attribute certificate registration authority (group ARA) that performs the issuing proxy. Has been issued a request from the party, and has issued an already issued group attribute certificate, such as a group attribute certificate issued by a credit card company, and the submitted group attribute certificate It is preferable to take a method of performing a process of issuing new group attribute certificates AC01 and AC02 after performing the verification of. The processing sequence for issuing a new group attribute certificate on condition that such an already issued group attribute certificate is verified is similar to the processing sequence described above with reference to FIGS. 29, 30, 32, and the like. It becomes.
[0397]
The issuing and storing form of the group attribute certificate shown in FIG. 54 is as shown in FIG. The chat room providing service provider (SP) 501 and the communication terminal (EE) 511 and the communication terminal (EE) 531 as end entities can mutually transfer data through a communication network, and the communication terminal (EE) 511 and a user identification device (UID) 521, and a communication terminal (EE) 531 and a user identification device (UID) 533 can mutually transfer data via both connected device interfaces 231 (see FIG. 9).
[0398]
Each device is provided with a (user) security chip 512, 522, 532, 534 or a security module 502 having a tamper-resistant configuration, and performs mutual authentication processing during data communication processing, or encryption and decryption processing of transfer data. And so on. The verification process of the group attribute certificate is also executed in these security chips and security modules.
[0399]
In the user identification device 521 of Mr. Ko, the group attribute certificates AC01 and 523 described above with reference to FIG. 54 are stored. The group attribute certificate AC01, 523 is issued by the chat room providing service provider (SP) 501, which is applied to the chat room participation authority confirmation processing, and the chat room providing service is provided from USC 521 of the owner user device, Mr. Ko. After being sent to the provider (SP) 501, the security module (SM) 502 of the chat room providing service provider (SP) 501 verifies and examines the group attribute certificate AC01, and then, the service, that is, the chat room participation is approved.
[0400]
The user identification device 521 of Mr. Ko also stores the group attribute certificates AC02 and 524 described above with reference to FIG. The group attribute certificate AC02,524 is applied to the process of confirming the access authority of the user device of the second party to the management server of the second party user device (EE531 or UID533). Of the group attribute certificate AC02 in the security chip (SC532 or USC534) of the user's user device (EE531 or UID533) from the USC521 of the company. That is, access to the management server of Otsu device is permitted.
[0401]
With reference to FIG. 56, a description will be given of a processing sequence in which the use authority of the chat room participation service is confirmed by applying the group attribute certificate AC01, 523 stored in the user identification device 421 of Mr. Ko, and the service is started. . In FIG. 56,
UID: Mr. Ko user identification device (user device) control unit,
USC: User security chip configured in UID,
EE: Mr. Ko's communication terminal (EE) control unit,
SC: security chip configured in EE,
SP: Chat room providing service provider (SP) control unit,
SM: Security module in SP,
It is.
[0402]
First, in step S451, the user (Mr. Ko) inputs a use request command of the group attribute certificate (Gp. AC) = AC01 via the input interface of the Ms. communication terminal (EE) as the end entity. This group attribute certificate (Gp. AC) is AC01 shown in FIGS. In this process, the user specifies the group ID set in the group attribute certificate AC01 to be used. However, when a unique group ID can be determined by specifying a specific service, only the service may be specified.
[0403]
When Mr. Ko's communication terminal (EE) receives the use request input of the group attribute certificate (Gp. AC) AC01 from the user, in step S452, the user security chip (USC) and the chat room providing service provider as a service provider are provided. Mutual authentication between the security modules (SM) of (SP) is performed. Although omitted here, in the case of a user identification device (UID) that cannot directly execute communication with the SP,
(1) Mutual authentication between EE SC and SP-SM,
(2) Mutual authentication between EE SC and UID USC,
(3) Mutual authentication between USC of UID and SP-SM,
Will do everything. Alternatively, as a simple method, the EE may be connected to the EE so that the EE basically accepts (authenticates) the EE. In this case, the mutual authentication described in (2) above is performed. Can be omitted. Further, an authentication configuration based on various combinations of the above three types of mutual authentication is possible.
[0404]
The authentication process is performed as a process centered on the encryption processing unit (see FIG. 9) of the security chip and the security module, for example, as a mutual authentication process of the public key method described above with reference to FIG. In step S453, the user security chip outputs a mutual authentication completion notification including information on the result of successful or unsuccessful mutual authentication to the end entity. If the mutual authentication is not established, the continuation of the processing is stopped. When the mutual authentication is established, in step S454, the user security chip (USC) transmits the group attribute certificate (Gp. AC) AC01 stored in its own memory to the security module (SM) of the service provider (SP). I do. This group attribute certificate (Gp. AC) is a group attribute certificate AC01 applied to the process of determining the right to participate in a chat room, as described above with reference to FIGS.
[0405]
In step S455, the security module (SM) of the chat room providing service provider (SP) that has received the group attribute certificate (Gp. AC) AC01 from the user security chip (USC) executes a group attribute certificate verification process. The verification process of the group attribute certificate is as described above with reference to FIGS. 21 to 23, and the signature verification of the attribute certificate, the related public key certificate (PKC) and the chain public key certificate are performed. It is executed as a process including a confirmation process and the like.
[0406]
After the verification process of the group attribute certificate (Gp. AC), the security module (SM) outputs the verification result to the chat room providing service provider (SP). If the verification is not successful, the service is provided as an error process. Cancel processing without executing. In this case, a process of notifying the end entity that the verification of the group AC has failed may be executed.
[0407]
If the verification of the group attribute certificate (Gp. AC) succeeds and the validity of the group attribute certificate (Gp. AC) is confirmed, the process proceeds to step S457. In step S457, the examination of the group attribute certificate (Gp. AC) described above with reference to FIG. 25 is executed. The examination is performed based on a group information database held by a chat room providing service provider (SP) as a service provider. That is, the chat room providing service provider (SP) acquires issuer information and group ID from the verified group attribute certificate (Gp. AC) AC01, searches the group information database based on the acquired information, and registers Check if any entries have been made. If there is a corresponding registration entry, the group information is acquired from the group information database.
[0408]
The group information in this case includes permission information for participation in the chat room. In step S458, the chat room providing service provider (SP) as a service provider performs service providing processing, that is, permits participation in the chat room according to the group information. That is, a process for permitting access to the server that provides the chat room is performed.
[0409]
Next, referring to FIG. 57, by applying the group attribute certificate AC02, 524 stored in Ko's user identification device 421, the access right to the user's user device is confirmed. A processing sequence for starting communication with Mr. will be described. In FIG. 57,
UID: Mr. Ko user identification device (user device) control unit,
USC: User security chip configured in UID,
EE1: Mr. Ko's communication terminal (EE) control unit,
SC1: security chip configured in EE1,
EE2: Otsusan communication terminal (EE) control unit,
SC2: security chip configured in EE2,
It is.
[0410]
First, in step S461, the user (Mr. Ko) inputs a use request command of the group attribute certificate (Gp. AC) = AC02 via the input interface of the Ms. Ko communication terminal (EE1) as the end entity. This group attribute certificate (Gp. AC) is AC02 shown in FIGS. In this process, the user specifies the group ID set in the group attribute certificate AC02 to be used.
[0411]
When Mr. Ko's communication terminal (EE1) receives the use request input of the group attribute certificate (Gp. AC) AC02 from the user, in step S462, the user security chip (USC) and the security chip (SC2) ) Is performed. Here, an example will be described in which the group attribute certificate (Gp. AC) AC02 is issued by the security chip (SC2) of the second party communication terminal (EE). If the issuer is your own user identification device (UID), authentication of your own user identification device (UID) with the user security chip (USC) will be performed.
[0412]
The authentication process is performed as a process centered on the encryption processing unit (see FIG. 9) of the security chip and the security module, for example, as a mutual authentication process of the public key method described above with reference to FIG. In step S463, Mr. Ko's user security chip (USC) outputs a mutual authentication completion notification including information on the result of the mutual authentication establishment or non-establishment to the end entity (EE1). If the mutual authentication is not established, the continuation of the processing is stopped. When the mutual authentication is established, in step S464, the user security chip (USC) transmits the group attribute certificate (Gp. AC) AC02 stored in its own memory to the security chip (SC2) of the second party communication terminal (EE). Send This group attribute certificate (Gp. AC) is a group attribute certificate applied to the process of determining the access right of the user device of the user to the server, as described above with reference to FIGS. AC02.
[0413]
In step S465, the security chip (SC2) of the second party communication terminal (EE) that has received the group attribute certificate (Gp. AC) AC02 from the user security chip (USC) executes a group attribute certificate verification process. The verification process of the group attribute certificate is as described above with reference to FIGS. 21 to 23, and the signature verification of the attribute certificate, the related public key certificate (PKC) and the chain public key certificate are performed. It is executed as a process including a confirmation process and the like.
[0414]
After the verification process of the group attribute certificate (Gp. AC), the security chip (SC2) of the communication terminal (EE) outputs the verification result to the communication terminal (EE). If the verification is not successful, an error occurs. As the processing, the processing is stopped without providing the service. In this case, a process of notifying Mr. Ko that the verification of the group AC has failed may be executed.
[0415]
If the verification of the group attribute certificate (Gp. AC) succeeds and the validity of the group attribute certificate (Gp. AC) is confirmed, the process proceeds to step S467. In step S467, the examination of the group attribute certificate (Gp. AC) described above with reference to FIG. 25 is executed. The examination is performed based on the group information database held by the second party communication terminal (EE). That is, the second party communication terminal (EE) acquires the issuer information and the group ID from the verified group attribute certificate (Gp. AC) AC02, searches the group information database based on the acquired information, and registers the information. Check for entries. If there is a corresponding registration entry, the group information is acquired from the group information database.
[0416]
In this case, the group information includes access authority information to the server of the Otsu user device. In step S468, the user's communication terminal (EE) performs service provision processing, that is, permits access to the server of the user's user device according to the group information.
[0417]
[(6) Execution attribute certificate (execution AC)]
Next, in the service providing processing mode based on the authority confirmation using the attribute certificate, it is possible not only to determine the service receiving authority based on the attribute certificate, but also to limit the execution of the service itself by the attribute certificate. The executed attribute certificate (execution AC) will be described.
[0418]
(6-1) Outline of execution attribute certificate
With the above-described group attribute certificate or a conventionally known general attribute certificate, it is possible to verify by signature verification that data stored in the attribute certificate such as authority information as an attribute of the owner has not been tampered with. it can. The execution attribute certificate (execution AC) described below not only verifies that the certificate has not been tampered with but also verifies the encryption stored in the execution attribute certificate by the certificate owner. The data (program) is decrypted, and the service is received based on the decryption of the encrypted data (program).
[0419]
The key (registration key) applied to decrypt the encrypted data (program) stored in the execution attribute certificate corresponds to the execution attribute certificate issuer and the service receiver as the owner of the execution attribute certificate. This is a secret common key that can be known only by the security chip (SC) of the user device. Therefore, the service can be executed based on the execution attribute certificate only in a specific user device.
[0420]
In the following description, it is assumed that the security chip (SC) of the end entity (EE), which is a user device, performs the processing of the execution attribute certificate. The process is a process that can be executed similarly in the user security chip (USC) of the user identification device (UID), similarly to the process in the group attribute certificate described above.
[0421]
The execution attribute certificate includes, as shown in FIG. 58A, data obtained by encrypting an execution instruction of a program or the like necessary to execute the provided service with a registration key, and a memory of a security chip storing the registration key, for example, It has a memory area block address as address data indicating a registration key storage area in a common key memory area 207 formed in the EEPROM 206 of the security chip shown in FIG. In addition, it has various types of attribute certificate data (see FIG. 5) and is attached with an issuer signature. Data tampering verification can be executed by signature verification. The signature generation and verification processing can be executed according to the processing described above with reference to FIGS.
[0422]
Note that the execution attribute certificate is a basic format of the attribute certificate, for example, ITU-TX. 509 can be configured. However, ITU-TX. It is not essential to follow the format specified in 509, and an execution attribute certificate in a unique format may be configured.
[0423]
In the common key memory area 207 of the security chip (SC), as shown in FIG. 58B, a plurality of registration keys corresponding to a plurality of execution attribute certificates possessed by the end entity (EE) as a user device. It is stored for a predetermined block address.
[0424]
The common key memory area 207 is a memory area of a non-volatile memory composed of blocks of a fixed size such as 64 bits. The process of storing the registration key and the process of resetting are performed according to a predetermined procedure. This processing will be described later. Except for the reset instruction, access to the registration key storage memory area can be executed only by using an instruction encrypted with the registration key stored in the block to be accessed. In addition, the secret key has a mechanism that cannot read the result of encrypting or decrypting the input data with the secret key, in addition to a mechanism that cannot read the secret key. Here, the fact that it is not possible to read directly means that, for example, after hashing, it is possible to encrypt with a secret key, or to decrypt and execute an instruction encrypted with a public key with a secret key. Means Hereinafter, it is assumed that the security chip or module that is the owner of the execution attribute certificate has this mechanism.
[0425]
The outline of the procedure for using the execution attribute certificate will be described with reference to the flowchart shown in FIG. FIG. 59 is a flow showing, for example, the service provider (SP) as the issuer of the execution attribute certificate and the abbreviation of the processing in the user device as the service receiver by the execution attribute certificate. In step S501, mutual authentication is performed between the service provider (SP) and the user device. In step S502, the examination of the service use authority based on, for example, the above-described group attribute certificate is performed. The processing here is the same as the above-described authentication processing and verification processing for the group attribute certificate. The authentication processing is performed mainly by the encryption processing unit (see FIG. 9) of the security chip and the security module. This is executed as the public key mutual authentication process described with reference to FIG. The verification processing is executed as processing including signature verification of the attribute certificate, verification processing of the related public key certificate (PKC) and chained public key certificate, and the like described with reference to FIGS. You.
[0426]
Next, as a process in step S503, a service providing process based on an execution attribute certificate (execution AC) is performed. The service providing process based on the execution attribute certificate (execution AC) includes an execution attribute certificate (execution AC) issuance process shown in step S504, an execution attribute certificate (execution AC) application process shown in step S505, and step S506. The execution attribute certificate (execution AC) shown in FIG. Hereinafter, details of these processes will be described with reference to the drawings.
[0427]
(6-2) Execution attribute certificate issuance processing
First, the execution attribute certificate issuance processing will be described. FIG. 60 shows an issuance sequence diagram of the execution attribute certificate. In FIG.
EE: end entity (EE) control unit of the user device,
SC: security chip configured in EE,
Execution AC table: execution AC management table storage memory and memory control unit
SP: a service provider device (SP) control unit that executes a process of issuing an execution AC,
SM: Security module in SP,
It is.
[0428]
First, in step S511, the user inputs an execution attribute certificate (execution AC) issuance request command via an input interface of an end entity (EE) as a user device. When the end entity (EE) receives the request for issuing the execution attribute certificate from the user, in step S512, mutual authentication and execution between the security chip (SC) and the security module (SM) of the service provider (SP) are performed. Verification and examination of the issued group attribute certificate applied as an attribute certificate (execution AC) issuance condition are performed.
[0429]
The authentication process is performed as a process centered on the encryption processing unit (see FIG. 9) of the security chip and the security module, for example, as a mutual authentication process of the public key method described above with reference to FIG. The verification processing is executed as processing including signature verification of the attribute certificate, verification processing of the related public key certificate (PKC) and chained public key certificate, and the like described with reference to FIGS. You.
[0430]
Here, an example of processing for issuing an execution attribute certificate for the security chip (SC) of the end entity (EE) is shown, but the user security chip (USC) of the user identification device (UID) is In the case of the execution attribute certificate issuance process targeted for issuance,
(1) Mutual authentication between EE SC and SP-SM,
(2) Mutual authentication between EE SC and UID USC,
(3) Mutual authentication between USC of UID and SP-SM,
Will do everything. Alternatively, as a simple method, the EE may be connected to the EE so that the EE basically accepts (authenticates) the EE. In this case, the mutual authentication described in (2) above is performed. Can be omitted. Further, an authentication configuration based on various combinations of the above three types of mutual authentication is possible.
[0431]
When all of the authentication, the verification of the group attribute certificate, and the examination in step S512 are established, the service provider (SP) performs a registration key generation execution AC generation information request process for the end entity (EE) of the user device. Specifically, this is a process for requesting a memory area free address of a memory used as a storage area of a registration key applied to encryption and decryption processing of an execution instruction (see FIG. 58) of an execution attribute certificate. .
[0432]
Upon receiving the registration key generation execution AC generation information request, the end entity (EE) outputs a search for a memory area free address of a memory used as a storage area for the registration key to the execution AC table control unit in step S514. In response to this request, the execution AC table (control unit) refers to the execution AC table and notifies the end entity of a memory area free address in which a registration key for new registration is to be stored. For example, as shown in FIG. 62, the execution AC table is necessary for using SP information as service provider identification data, service information provided by the service provider, for example, encrypted content information, and service information provided by the service provider. Is a table in which an execution AC that stores a program as an execution instruction is associated with the execution AC. The execution AC table is stored in a memory in the end entity (EE) or the security chip (SC).
[0433]
The execution AC table (control unit) refers to the memory area block address of the registration key corresponding to the already stored execution AC, detects a free address in its own security chip, and stores the registration key for new registration. The end entity is notified of the memory area free address to be used. The execution AC table control unit is configured by a CPU or the like that executes access control and data extraction of a memory storing the execution AC table, and executes a memory access control process of an end entity (EE) or a security chip (SC). It is a control unit.
[0434]
The end entity (EE) transmits a free address to the service provider (SP) in step S516. The service provider (SP) having received the memory area block address of the newly registered key outputs a registration key generation execution AC generation request to the security module (SM) in step S517, and in step S518, the security module (SM) , A registration key generation execution AC is generated. The generation request of the registration key generation execution AC output from the service provider (SP) to the security module (SM) includes the security chip public key certificate storing the security chip public key (KpSC) and the registration key reset. A reset key (Kreset) to be applied, a registration key generation instruction (GenKer), and a memory area block address (Ad) are included.
[0435]
With reference to FIG. 63, details of the registration key generation execution AC generation processing in the security module (SM) will be described.
[0436]
The security module (SM) 601 has the same configuration as the security chip configuration described above with reference to FIG. 9, and FIG. 63 shows an encryption processing unit and a memory unit extracted from the configuration. . The encryption processing unit includes a public key encryption engine 602 and a common key encryption engine 603. As described above with reference to FIG. 9, the security module (SM) 601 has a configuration of a CPU, a RAM, a ROM, and the like, and can perform other data processing and data input / output processing.
[0437]
The public key encryption engine 602 performs a public key encryption process such as an elliptic curve encryption or a RSA (Rivest-Shamir-Adleman) encryption process, and performs data encryption, decryption, signature generation, verification processing, and the like. . The common key encryption engine 603 performs encryption processing of a common key encryption method such as DES and triple DES, and performs data encryption and decryption. Note that the security module (SM) 601 further has a hash generation process and a random number generation process function.
[0438]
As described above, the security module (SM), upon the registration key generation execution AC generation request, stores the security chip public key certificate (KpSC) and the reset key (Kreset) to be applied when resetting the registration key. , A registration key generation instruction (GenKer), and a memory area block address (Ad).
[0439]
In the random number generation process in step S541, the session key (Kcs) and the registration key generation command (GenKer) based on the generated random number are encrypted using the security chip public key (KpSC) in step S542, and the encrypted data (Ep (GenKcr || Kcs; KpSC) is generated, where a || b indicates the concatenated data of a and b, and Ep (a; b) is based on the public key cryptosystem of a to which the key b is applied. Indicates an encrypted message.
[0440]
Next, in step S543, an execution instruction adding process is performed. Dpc [a] indicates an execution instruction for executing a command in data a based on decryption using a secret key based on a public key cryptosystem. Further, in step S544, a common key encryption process based on the reset key (Kreset) is performed to generate encrypted data (Ec (Dpc [Ep (GenKcr || Kcs; KpSC)]; Kreset)). Ec (a; b) indicates an encrypted message based on the common key encryption method of a to which the key b is applied.
[0441]
Further, in step S545, the link data of the encrypted data (Ec (Dpc [Ep (GenKcr || Kcs; KpSC)]; Kreset) and the memory area block address (Ad) indicating the storage area of the new registration key is added. On the other hand, a signature process using the secret key (KsSM) of the security module (SM) is performed, and as a result of these processes, a registration key generation execution AC 611 is generated.
[0442]
The registration key generation execution AC 611 is
A memory area block address (Ad) indicating a storage area for a newly registered key;
Encrypted data (Ec (Dpc [Ep (GenKcr || Kcs; KpSC)]; Kreset)), and
The signature data includes Ep (H (Ad│Ec (Dpc [Ep (GenKcr││Kcs; KpSC)); Kreset; KsSM), where H (a) indicates the hash value of a.
[0443]
Returning to the sequence diagram of FIG. 60, the description will be continued. When the registration key generation execution AC generation processing in the security module (SM) ends in step S518, the registration key generation execution AC is sent from the security module (SM) to the service provider (SP). In step S519, the service provider (SP) Sends the registration key generation execution AC to the end entity (EE) of the user device.
[0444]
In step S520, the end entity (EE) of the user device transmits an update request for the execution AC table (see FIG. 62) to the execution AC table (control unit), and the execution AC table (control unit) returns to step S521. Update the execution AC table. The update request for the execution AC table (see FIG. 62) includes content information, service provider information, and a memory area block address that can be used by applying the new registration key. Register information.
[0445]
Further, in step S522, the end entity (EE) of the user device outputs a registration key generation request to the security chip (SC). This request is performed as a process of sending the registration key generation execution AC to the security chip (SC).
[0446]
The security chip (SC) executes a registration key generation process in step S523. A registration key generation process based on a registration key generation execution AC executed by the security chip will be described with reference to FIG.
[0447]
The security chip (SC) 605 has the same configuration as the security chip configuration described above with reference to FIG. However, as described in FIG. 58, it has a common key memory area. FIG. 64 shows the cryptographic processing unit and the memory unit in the configuration extracted and shown. The encryption processing unit includes a public key encryption engine 606 and a common key encryption engine 607, and a memory unit includes a common key memory area 608. As described above with reference to FIG. 9, the security chip (SC) 605 has a configuration of a CPU, a RAM, a ROM, and the like, and is based on other data processing, for example, an execution instruction decrypted in an encryption processing unit. Data processing, data input / output processing, and the like can also be performed. For example, data processing such as writing and reading of data to and from the common key memory 608, input of data from the outside, output of data to the outside, and transfer of data between elements are performed mainly by control of the CPU.
[0448]
The public key cryptographic engine 606 executes public key cryptography such as elliptic curve cryptography or RSA (Rivest-Shamir-Adleman) cryptography, and performs data encryption, decryption, signature generation, and verification. . The common key encryption engine 607 performs encryption processing of a common key encryption method such as DES and triple DES, and performs data encryption and decryption. The common key memory area 608 is a memory for storing a registration key, and is a non-volatile memory composed of blocks of a fixed size, such as 64 bits. Note that the security chip (SC) 605 further has a hash generation processing and a random number generation processing function.
[0449]
As described above, the security chip (SC) inputs the registration key generation execution AC 611 in response to the registration key generation request from the end entity.
[0450]
In step S551, the execution instruction data (Dpc [Ep (GenKcr || Kcs; KpSC)] of the registration key generation execution AC 611 is extracted by the decryption process of the common key system to which the reset key (Kreset) is applied, and further, step S552. , As a data process corresponding to the decrypted execution command, a connection process of a registration key generation command (GenKer) and a session key (Kcs) is performed by a public key decryption process using a security chip secret key (KsSC). Is taken out.
[0451]
The next step S553 is also data processing corresponding to the decryption execution instruction, and is an execution processing step of the registration key generation instruction (GenKer). In step S554, a registration key (Kcr) based on a random number is generated, and in step S555, the registration key (Kcr) is written to the common key memory area 608 according to the memory area block address (Ad) that is the storage area address of the registration key.
[0452]
Further, in step S556, the concatenated data of the registration key (Kcr) and the memory area block address (Ad) is encrypted with the session key (Kcs) and output to the end entity (EE) as a registration key generation result 612. .
[0453]
The step of outputting the registration key generation result 612 to the end entity (EE) corresponds to step S524 in FIG.
[0454]
A registration key generation result obtained by encrypting concatenated data of the registration key (Kcr) and the memory area block address (Ad) with the session key (Kcs) is transmitted from the end entity (EE) of the user device to the service provider (SP). Sent.
[0455]
Upon receiving the registration key generation result, the service provider (SP) sends a registration key generation result to the security module (SM) in step S526 to request generation of a service providing execution AC. In step S527, the security module (SM) executes a process of generating a service providing execution AC.
[0456]
The generation process of the service providing execution AC by the security module (SM) will be described with reference to FIG.
[0457]
First, in step S561, a decryption process of the registration key generation result is performed by applying the session key (Kcs), and concatenated data (Ad || Kcr) of the registration key (Kcr) and the memory area block address (Ad). To get. Further, in step S562, the execution instruction (DecData || Kcd) 613 stored in the service providing execution AC is encrypted by applying the registration key (Kcr). The execution command is an execution command of an execution program or the like set according to the service providing execution AC. Here, an execution instruction composed of linked data of a data decryption key (Kcd) and a decryption instruction (DecEDData) of encrypted data is shown as an example.
[0458]
Further, in step S563, data (Ec (DecEDData || Kcd); Kcr) obtained by encrypting the execution instruction (DecEDData || Kcd) 613 with the registration key (Kcr) and the user device storing the registration key (Kcr) A signature (see FIG. 17) is generated for the data with the memory area block address (Ad) of the security chip by the secret key (KsSM) of the security module, and the service providing execution AC 614 is generated. Here, the service providing execution AC 614 is an execution attribute certificate for executing the decryption processing of the encrypted data as a service.
[0459]
In order to decrypt the execution instruction stored in the execution attribute certificate, it is necessary to apply a registration key (Kcr). In this case, the registration key information is included in the service providing execution AC generation process. Only the security chip (SC) of the participating user device and the security module (SM) of the service provider.
[0460]
Referring back to FIG. 61, the description of the sequence diagram is continued. When the security module (SM) generates the service providing execution AC in step S527, the service providing execution AC is sent from the service provider (SP) to the end entity (EE) of the user device in step S528, and further, in step S529. Is sent to the execution AC table control unit, and stored in the execution AC table (see FIG. 62) in step S530.
[0461]
By the above process, as shown in FIG. 58 (a), the memory area block address of the security chip of the user device storing the registration key, the execution instruction encrypted with the registration key, and the issuer signature The execution attribute certificate (execution AC) having the above data is stored in the user device. In addition to these data, it is optional to store the data of each field of the group attribute certificate described above with reference to FIG. However, it is necessary to execute the signature on the entire data to be tampered with.
[0462]
(6-3) Execution attribute certificate application processing
Next, an application process of the execution attribute certificate issued in the above-described procedure will be described. FIG. 66 is a diagram summarizing an application sequence of the service providing execution AC on the user device side. The service providing execution AC has already been stored in the execution AC table of the user device by the above-described processing.
[0463]
In step S571, the user inputs a service providing execution AC application processing request via the user interface of the end entity (EE). This processing request includes the identifier of the execution AC, service provider (SP) information, and data for specifying the service content, for example, the used content and the specified data of the used program. In step S572, the end entity (EE) outputs a search request for a user-specified service providing execution AC to the execution AC table. The search key is, for example, content information or service provider (SP) information.
[0464]
In step S573, the execution AC table searches for the corresponding service provision execution AC based on the input key from the end entity, and in step S574, the service provision execution AC extracted from the table is stored in the end entity (EE). Output.
[0465]
In step S575, the end entity (EE) outputs the received AC to the security chip (SC), and makes a request to apply the service providing execution AC. In step S576, the security chip performs a process of providing the received AC, that is, provides a service in accordance with the execution attribute certificate (execution AC).
[0466]
Details of the service providing process in step S576 in the security chip (SC) will be described with reference to FIG. The security chip 605 inputs the service providing execution AC 614.
[0467]
The service providing execution AC 614 is a security device for storing data (Ec (DecEDData || Kcd); Kcr) obtained by encrypting an execution instruction (DecEDData || Kcd) with a registration key (Kcr) and a user device storing the registration key (Kcr) It includes a memory area block address (Ad) of the chip and data signed with a security module secret key (KsSM) for each data.
[0468]
In step S581, the security chip 605 acquires the registration key (Kcr) from the common key memory area 608 according to the memory area block address (Ad) in the service provision execution AC, and provides the service with the acquired registration key (Kcr). The decryption processing of the encrypted data (Ec (DecEDData || Kcd); Kcr) in the execution AC is executed, and the data decryption key (Kcd) and the decryption instruction (DecEDData) of the encrypted data are obtained.
[0469]
In step S582, data processing based on the decrypted execution instruction is performed. That is, by applying the data decryption key (Kcd), decryption processing of encrypted data (Ec (data; Kcd)) 615 to be decrypted, which is input from the outside, is executed, and decrypted data 616 is output. The encrypted data (Ec (data; Kcd)) 615 to be decrypted is, for example, data obtained by encrypting a content such as an image, music, or a program with a key (Kcd), and stores a storage execution instruction in the service providing execution AC. Decryption is possible with a data decryption key (Kcd) that can be obtained by decryption with a registration key (Kcr).
[0470]
Returning to the sequence diagram of FIG. 66, the description will be continued. After providing the service in step S576, the security chip (SC) performs registration key destruction processing in step S577. The registration key discarding process may be executed in accordance with the service providing execution AC or may not be necessary. In the case of an execution AC in which service provision processing based on the service provision execution AC is set as one-time execution, this discard processing is executed following the service provision processing.
[0471]
The SC (security chip) registration key discarding process in step S577 will be described with reference to FIG. The reset processing of the registration key is performed by overwriting the storage area of the registration key in the common key memory area 608 with the reset key (Kreset). When a reset processing instruction 617 including the memory area block address (Ad) of the registration key (Kcr) to be discarded and the reset key (Kreset) is input from, for example, the end entity (EE), the reset processing is performed in step S583. The process of writing the reset key (Kreset) is executed in the memory area corresponding to the memory area block address (Ad) stored in the instruction 617, and the deletion of the registration key is completed.
[0472]
Returning to the sequence diagram of FIG. 66, the description will be continued. When the destruction of the registration key is completed in step S577, a registration key destruction notification is output to the end entity (EE) in step S578, and the end entity (EE) provides a service to the execution AC table in step S579. An execution AC deletion request is output, and the execution AC table (control unit) deletes the corresponding execution AC from the execution AC table.
[0473]
(6-4) Registration key reset processing
Note that the registration key destruction processing is not always performed following the provision processing of the service provision execution AC, and the reset processing as the registration key destruction processing can be performed based on a reset request at an arbitrary timing. It is. The processing based on this reset request will be described with reference to FIG.
[0474]
In step S601, the user inputs a request for resetting the registration key corresponding to the service providing execution AC stored in the user device via the user interface of the end entity (EE). The end entity (EE) outputs a search request to the execution AC table in step S602. There are two modes of the reset request. The first mode is that, when the user forgets the service content written in a certain memory area block address of the execution AC table, the execution AC table is searched using the memory area block address as a key, and the output SP information / content information is In this mode, a reset execution request is made when the user determines that the corresponding registration key is unnecessary. The processing request includes, for example, an identifier of the execution AC or data for specifying the service content, for example, content, a program, or service provider (SP) information data. In the second mode, when the user knows the SP information / content information, the user searches the execution AC table using the information as a key, and transmits the output memory area block address to the SC together with the reset execution request. The memory area block address of the registration key can be arbitrarily stored in the end entity as data corresponding to the content or the service provider.
[0475]
In step S603, the execution AC table searches for the corresponding service providing execution AC based on the input key from the end entity, and searches for the service provider and available content corresponding to the service providing executing AC. , To the end entity (EE).
[0476]
In the end entity (EE), the service provider and the available content information are displayed, and if it is determined that the user is unnecessary, a reset execution request is output to the security chip in step S606.
[0477]
The registration key reset processing is performed by overwriting the storage area of the registration key in the common key memory area with the reset key (Kreset), and resets the memory area block address (Ad) of the registration key (Kcr) to be discarded and the reset. A reset processing command including a key (Kreset) is input from the end entity (EE), and in step S607, the memory area corresponding to the memory area block address (Ad) as described above with reference to FIG. Next, a reset key (Kreset) writing process is executed, and the registration key is reset. When the reset of the registration key is completed in step S607, a reset completion notification is output to the end entity (EE) in step S608.
[0478]
(6-5) Execution attribute certificate reset (discard) processing
Next, a description will be given of an execution attribute certificate reset (destruction) process of discarding the execution attribute certificate stored in the user device and notifying the service provider that the destruction has been executed without fail.
[0479]
This will be described with reference to the processing sequence diagrams of FIGS. 70 and 71. 70 and 71,
EE: end entity (EE) control unit of the user device,
SC: security chip configured in EE,
Execution AC table: execution AC management table storage memory and memory control unit
SP: a service provider device (SP) control unit that executes a process of issuing an execution AC,
SM: Security module in SP,
It is.
[0480]
First, in step S611, the user inputs an execution attribute certificate (execution AC) discard request request command via the input interface of the end entity (EE). Based on this request, an application for canceling the execution attribute certificate is transmitted to the service provider. The application includes, for example, an execution attribute certificate (execution AC) ID, or data that can specify an execution attribute certificate (execution AC) to be discarded, such as content or service designation data.
[0481]
When the service provider device control unit (SP) receives the application for canceling the execution attribute certificate, in step S612, mutual authentication between the security chip (SC) and the security module (SM) of the service provider (SP) and, if necessary, Accordingly, verification and examination of the group attribute certificate issued to the service provider applied as the execution attribute certificate (execution AC) discarding condition are performed. If the execution attribute certificate destruction process is regarded as one service, the end entity plays the role of the service provider.
[0482]
The authentication process is performed as a process centered on the encryption processing unit (see FIG. 9) of the security chip and the security module, for example, as a mutual authentication process of the public key method described above with reference to FIG. The verification processing is executed as processing including signature verification of the attribute certificate, verification processing of the related public key certificate (PKC) and chained public key certificate, and the like described with reference to FIGS. You.
[0483]
Here, an example of a process of discarding the execution attribute certificate for the security chip (SC) of the end entity (EE) is shown, but the user security chip (USC) of the user identification device (UID) is used. In the case of destroying the execution attribute certificate that was issued,
(1) Mutual authentication between EE SC and SP-SM,
(2) Mutual authentication between EE SC and UID USC,
(3) Mutual authentication between USC of UID and SP-SM,
Will do everything. Alternatively, as a simple method, the EE may be connected to the EE so that the EE basically accepts (authenticates) the EE. In this case, the mutual authentication described in (2) above is performed. Can be omitted. Further, an authentication configuration based on various combinations of the above three types of mutual authentication is possible.
[0484]
When all of the authentication, the verification of the group attribute certificate, and the examination in step S612 are established, in step S613, the end entity (EE) of the user device outputs a search request for the execution AC to be discarded to the execution AC table. The search key is, for example, content information or service provider (SP) information.
[0485]
In step S614, the execution AC table searches for the corresponding service providing execution AC based on the input key from the end entity, and in step S615, the service providing execution AC extracted from the table is used as the end entity (EE). Output. Further, in step S616, the execution AC table (control unit) deletes the entry of the execution AC to be discarded from the execution AC table.
[0486]
In step S617, the end entity (EE) outputs a reset execution request to the security chip. In step S618, as the registration key reset process, a process of overwriting the storage area of the registration key in the common key memory area with the reset key (Kreset) is performed (see FIG. 68), and a reset completion notification is sent to the end entity (EE). Is output to
[0487]
Furthermore, the end entity (EE) transmits a reset completion notification to the service provider (SP) in step S621 shown in FIG. This reset completion notification accompanies the discard target execution AC. In step S622, the service provider (SP) that has received the discard target execution AC outputs a reset confirmation execution AC generation request to the security module (SM). This request is executed with the execution AC to be discarded.
[0488]
In step S623, the security module (SM) extracts memory area block address information storing the corresponding registration key from the execution AC to be discarded, and executes a process of generating a reset confirmation execution AC in step S624. The reset confirmation execution AC is executed as an instruction to be executed in the security chip (SC) of the user device by the memory area block address information (Ad) storing the corresponding registration key of the execution AC to be discarded and the reset confirmation execution AC. This is a data configuration including an instruction and a signature of an issuer, that is, a security module (SM) (see FIG. 72, reset confirmation execution AC621).
[0489]
The generated reset confirmation execution AC is transmitted from the service provider (SP) to the end entity (EE) in step S625, and further transferred to the security chip (SC) in step S626.
[0490]
In step S627, the security chip (SC) executes a reset confirmation result generation process based on the reset confirmation execution AC. Details of the reset confirmation result generation processing in step S627 will be described with reference to FIG.
[0490]
As shown in FIG. 72, in step S641, the security chip 605 extracts the execution instruction of the reset confirmation execution AC from the common key memory area 608 based on the address stored in the reset confirmation execution AC 621 (Kreset). And decryption instruction data (Dpc [Ep (ConfReset || Kcs; KpSC)] of the data (Ep (ConfReset || Kcs; KpSC)) encrypted with the public key (KpSC) of the security chip. In step S642, the secret key (KsSC) of the security chip is applied and decrypted to obtain a reset confirmation result creation command (ConfReset) and a session key (Kcs), and the reset confirmation result creation processing in step S643 is performed. Execute.
[0492]
In the reset confirmation result creation processing in step S643, first, in step S644, the reset key (Kreset) is read from the common key memory area 608 based on the address stored in the reset confirmation execution AC621, and further, in step S645, The concatenated data of the memory area block address information (Ad) and the reset key (Kreset) is encrypted with the session key (Kcs), and the reset confirmation result 622 including the encrypted data (Ec (Ad || Kreset; Kcs)) ends. Output to the entity (EE).
[0493]
The end entity (EE) transmits the reset confirmation result to the service provider (SP) in step S628 of FIG. 71, and the service provider (SP) transmits the reset confirmation result to the security module (SM) in step S629, The security module (SM) transmits a reset confirmation result notification to the service provider (SP), and the process ends.
[0494]
By the above-described process, the process of discarding the issued execution AC is surely executed under the confirmation of the service provider.
[0495]
Note that the registration key discarding process can be performed based on the execution AC. The registration key destruction processing based on the execution AC will be described with reference to FIG. The registration key execution AC is issued, for example, by the service provider (SP) that has issued the corresponding service provision execution AC, and is input to the security chip (SC) via the end entity (EE) of the user device.
[0496]
As shown in FIG. 73, the registration key destruction execution AC 623 includes the memory area block address information (Ad) of the common key memory area storing the registration key to be destroyed, the registration key destruction command (RevK) encrypted with the registration key. , The execution AC having the issuer signature.
[0497]
In step S651, the execution instruction of the registration key destruction execution AC 623 is decrypted based on the registration key (Kcr) obtained from the common key memory area 608 based on the memory area block address information (Ad) of the registration key destruction execution AC 623. Then, a discard command (RevK) is acquired, and discard processing based on the command is executed in step S652. In step S653, the reset key (Kreset) is overwritten in the corresponding memory area based on the memory area block address information (Ad) of the registration key discard execution AC623, and the registration key is discarded (reset).
[0498]
(7) Specific use process of execution attribute certificate
Next, a specific use process to which the above-described execution attribute certificate (execution AC) is applied will be described. The following items will be described as usage processing examples.
(7-1) Attribute certificate for service provision execution with limited number of times
(7-2) Service providing execution attribute certificate with transfer function
(7-3) Attribute certificate for execution by proxy
Hereinafter, each of the above items will be described.
[0499]
(7-1) Attribute certificate for service provision execution with limited number of times
First, the process of applying the service providing execution attribute certificate with a limited number of times will be described. FIGS. 74 and 75 show a process of applying a service providing execution attribute certificate with a limited number of times on a user device to decrypt and use a service, that is, encrypted data with a limited number of times, for example, contents such as images, music, and programs. Shows the sequence. The processing sequence will be described according to each step.
[0500]
It is assumed that the user device has already stored a service providing execution attribute certificate with a limited number of times in a memory, for example, the above-described execution AC table, and the remaining number of times of use is n. Remaining usage count data (for example, n times) is recorded as an application count identification value of the execution instruction in the execution instruction of the service providing execution attribute certificate with the number of times limitation. A recording example will be described later.
[0501]
In step S701, the user inputs an application processing request of the service providing execution AC, in this example, the encrypted data decryption execution AC via the user interface of the end entity (EE). This processing request includes an identifier of the execution AC, service provider (SP) information, and data for specifying the service content, for example, usage content designation data. In step S702, the end entity (EE) outputs a search request for a user-specified service providing execution AC (encrypted data decryption execution AC) to the execution AC table. The search key is, for example, content information or service provider (SP) information.
[0502]
In step S703, the execution AC table searches for the corresponding encrypted data decryption execution AC based on the input key from the end entity, and in step S704, searches the encrypted data decryption execution AC extracted from the table for the end entity. (EE). In the encrypted data decryption execution AC, information on the number of remaining uses = n is recorded.
[0503]
In step S704, the end entity (EE) outputs the received AC to the security chip (SC), and issues a service providing execution AC (encryption data decryption execution AC) application processing request. This application processing is performed as follows. First, in step S705, the execution command of the encrypted data decryption execution AC is decrypted with the registration key, the decryption key is set, and a decryption key set completion notification is output to the end entity (EE) (S706). , EE, for example, obtains encrypted data to be decrypted from an external memory (S707), issues a decryption request to the SC (S708), executes data decryption processing in the SC (S709), and converts the decrypted data from the SC. The data is transmitted to the EE (S710), the data is decrypted, and in step S711, the remaining use count data in the execution instruction in the encrypted data decryption execution AC is updated from n to n-1.
[0504]
Further, after the determination of the number of remaining uses after the update (S712), if the number of remaining uses ≧ 1, the registration key is regenerated and stored (S721), and the encrypted data is decrypted according to the sequence shown in FIG. The execution AC is regenerated (S722), transmitted to the EE, and stored in the execution AC table (S724) in response to the encrypted data decryption execution AC storage request from the EE (S723).
[0505]
On the other hand, when the remaining number of uses = 0, the registration key discarding process (S725) is executed in the SC according to the sequence shown in FIG. 75 (b), and after the registration key discard notification to the EE (S726), The encrypted data decryption execution AC deletion (S728) of the execution AC table is executed in response to the encrypted data decryption execution AC deletion request (S727).
[0506]
The processing in the security chip (SC) after step S705 will be described with reference to FIGS. 76 and 77. FIG. 76 shows a process when the remaining number of uses after update ≧ 1 and FIG. 77 shows a process when the remaining number of uses after update = 0.
[0507]
First, with reference to FIG. 76, processing in the security chip (SC) in the case where the number of remaining uses after update ≧ 1 will be described.
[0508]
The service providing execution attribute certificate 701 with a limited number of times includes an execution instruction (Ec (DecData || Kcd || NumTr (n); Kcr1)) and a block address in a common key memory area storing a registration key for decrypting the execution instruction. (Ad) and an issuer signature. The execution instruction includes an encrypted data decryption command (DecData), a data decryption key (Kcd), and a number processing execution command (NumTr (n)) according to the remaining number of uses (n). These data are encrypted execution instructions (Ec (DecEDData || Kcd || NumTr (n); Kcr1)).
[0509]
First, in step S731, the security chip (SC) applies the registration key (Kcr1) extracted from the common key memory area based on the block address (Ad) in the execution AC to decrypt the execution instruction of the execution AC 701, The data (DecEDData || Kcd || NumTr (n)) is extracted, and further, in step S732, the data decryption key (Kcd) is applied to encrypt the encrypted data 702 (Ec) such as encrypted content input from the outside. (Data; Kcd)), and outputs the decrypted content (data) 703 to the end entity.
[0510]
Further, in step S733, a process based on the number-of-times process execution command (NumTr (n)) is executed. This process is a process for generating a new service-limited execution attribute certificate 704 with a limited number of times with the remaining number updated.
[0511]
By the random number generation processing (S734), a new registration key Kcr2 is generated and written into the common key memory area 608 corresponding to the block address written in the original service-limited execution attribute certificate 701 with the limited number of times. As a result, the previously written registration key (Kcr1) is replaced with a new registration key (Kcr2).
[0512]
In step S736, an update is performed in which the remaining number of uses = n extracted based on the number-of-times processing execution command (NumTr (n)) is (-1) in accordance with the content decryption process. That is, the data (DecEDData || Kcd || NumTr (n)) in the execution instruction is rewritten to (DecEDData || Kcd || NumTr (n-1)), and in step S737, the newly generated registration key (Kcr2) is changed. Execute the applied encryption processing. This encrypted data corresponds to the execution instruction (Ec (DecEDData || Kcd || NumTr (n-1); Kcr2)) in the service providing execution attribute certificate 704 with a limited number of times.
[0513]
In step S738, an electronic signature based on the block address (Ad) and the execution instruction having the updated remaining number data generated in step S737 is executed by using the secret key (KsSC) of the security chip, and the new updated number-limited service is executed. A provision execution attribute certificate 704 is generated. The signature in this case is made in the security chip.
[0514]
The new service-limited execution attribute certificate 704 with the limited number of times is output from the security chip (SC) to the end entity (EE) in step S722 in FIG. 75, and is stored in the execution AC table in step S724.
[0515]
On the other hand, the processing in the security chip (SC) when it is determined that the number of remaining uses = 0 in the remaining use number examination in the processing step S712 in FIG. 74 will be described with reference to FIG.
[0516]
The service providing execution attribute certificate 705 with a limited number of times includes an execution instruction (Ec (DecEDData || Kcd || NumTr (1); Kcr1)) and a block address in a common key memory area storing a registration key for decrypting the execution instruction. (Ad) and an issuer signature.
[0517]
First, in step S741, the security chip (SC) applies the registration key (Kcr1) extracted from the common key memory area based on the block address (Ad) in the execution AC to decrypt the execution instruction of the execution AC 705, Data (DecEDData || Kcd || NumTr (n)) is extracted, and in step S742, a data decryption key (Kcd) is applied to encrypt data 706Ec (Data) such as encrypted content input from the outside. Kcd)), and outputs the decrypted content (data) 707 to the end entity.
[0518]
Further, in step S743, a process based on the number-of-times process execution command (NumTr (1)) is executed. This process is performed as a process of executing the registration key discarding in order to stop the use of the service using the further execution AC, that is, to stop the decryption of the encrypted data. That is, in step S744, the registration key (Kcr1) is discarded. The registration key is discarded as a process of overwriting the area corresponding to the block address (Ad) in the common key memory area storing the registration key recorded in the service providing execution attribute certificate with a limited number of times with the reset key. .
[0519]
By this processing, the registration key (Kcr1) for decrypting the execution instruction stored in the service providing execution attribute certificate with a limited number of times 705 is destroyed, and the execution instruction cannot be decrypted. Use is suspended. After this processing, steps S727 and S728 shown in FIG. 75 are executed, and the corresponding execution AC is deleted from the execution AC table.
[0520]
(7-2) Service providing execution attribute certificate with transfer function
Next, an application process of the service providing execution attribute certificate with the transfer function will be described. FIG. 78 shows a process of applying the service providing execution attribute certificate with the transfer function, that is, a process based on the service providing execution attribute certificate with the transfer function between the user devices, to obtain a new service providing execution attribute certificate with the transfer function. By generating a certificate or a service providing execution AC and sending it to another user device (transfer destination), and performing a process of discarding the registration key of the own device (transfer source), the encrypted data is transmitted to the other user device. 7 shows a processing sequence that makes it possible to use (for example, encrypted content).
[0521]
In FIG. 78,
EE1: End entity (EE) control unit of the transfer source user device;
SC1: a security chip configured in the transfer source EE,
Execution AC table 1: Transfer source end entity (EE) execution AC table control unit,
EE2: End entity (EE) control unit of the transfer destination user device;
SC2: Security chip configured in transferee EE,
Execution AC table 2: Transfer destination end entity (EE) execution AC table control unit,
It is.
[0522]
First, in step S752, the transfer destination user performs transfer processing based on the service providing execution attribute certificate with transfer function, that is, the use of the encrypted data by the transfer destination user device via the input interface of the end entity (EE2). Enter a transfer request to make it executable. The transfer request specifies the service providing execution attribute certificate with the transfer function to be applied, such as the ID of the service providing execution attribute certificate with the transfer function, the owner information, the used content (encrypted data), or the service provider information. Information is included.
[0523]
When the end entity (EE2) receives the input of the transfer request from the user, the end entity (EE2) determines in step S752 that the end entity of the transfer source user device owning the service providing execution attribute certificate with the transfer function. A connection request is issued to (EE1), and mutual authentication is performed between the security chips (SC1) and (SC2) of each user device. This is executed, for example, as the public key mutual authentication process described above with reference to FIG.
[0524]
If the mutual authentication is established, in step S753, the end entity (EE1) of the transfer source user device outputs a search request for the specified service providing execution attribute certificate with transfer function to the execution AC table 1. The search key is, for example, content information or service provider (SP) information.
[0525]
In step S754, the execution AC table 1 searches the corresponding service providing execution attribute certificate with the transfer function based on the input key from the end entity (EE1), and extracts the execution AC extracted from the table into the end entity (EE). EE).
[0526]
In step S755, the end entity (EE) outputs the received AC to the security chip (SC), and requests the application of the service providing execution attribute certificate with transfer function. In step S756, the security chip processes the received AC, that is, registers the registration key acquired from the area specified by the address (Ad) stored in the execution attribute certificate (service providing execution attribute certificate with transfer function). The execution instruction is decoded based on the execution instruction (S756).
[0527]
Further, in step S757, a transfer processing request is output from the end entity (EE1) to the security chip (SC). In step S758, the end entity (EE1) outputs the group attribute certificate required for the transfer processing. The presentation is requested to the transferee user device (EE2). The group attribute certificate is, for example, a group attribute certificate for certifying that the group is a transferable user device or a user managed by a service provider (SP) that has generated and issued a service providing execution attribute certificate with a transfer function. It is.
[0528]
In step S759, the end entity (EE2) of the transfer destination user device transmits the designated group attribute certificate (Gp. AC) to the end entity (EE1) of the transfer source user device, and the end entity (EE1). Transfers the received AC to the security chip (SC1), and the security chip (SC1) verifies the group attribute certificate (S761). This verification processing is the same processing as described above with reference to FIGS. 21 to 23, and includes processing such as signature verification of an attribute certificate, correspondence, and verification of a chained public key certificate.
[0529]
If the verification is not satisfied, the processing is stopped without executing subsequent processing as error processing. In this case, a process of transmitting an error notification to the transferee end entity (EE2) may be performed.
[0530]
When the verification of the group attribute certificate (Gp. AC) is successful and the validity of the group attribute certificate (Gp. AC) is confirmed, the process proceeds to step S762. In step S762, generation and transmission of an execution attribute certificate for enabling the transfer destination user device to use the encrypted data are performed. These processes correspond to the generation and verification of the registration key generation execution AC described above with reference to FIGS. 60 and 61, and the generation and transmission of the service providing execution AC. The service provider shown in FIGS. The process of (SP) is executed by the transfer source user device.
[0531]
In step S762, a new service providing execution AC, in this example, a service providing execution attribute certificate is generated and sent to the transfer destination user device. Further, in step S763, the registration key applied to decrypt the execution instruction of the service providing execution attribute certificate with transfer function held by the transfer source user device is deleted. This process is performed by overwriting the above-described reset key. Here, the transfer function has been described, but if an execution attribute certificate that does not delete the registration key is used, a copy function can be provided instead of a transfer function.
[0532]
The process of decrypting the service providing execution attribute certificate with transfer function in step S756 executed by the security chip (SC1) of the transfer source user device The details of the following process will be described with reference to FIGS. 79 and 80.
[0533]
The service providing execution attribute certificate with transfer function (AC) 711 includes an execution command, a block address (Ad1) of the common key memory area 608 storing a registration key for decrypting the execution command, and data of an issuer signature. Have. The execution instruction (Ec (Sel || Jdg (SDB) || GenAC (GenKcr) || GenAC (Ex) || RevK || DecData || Kcd; Kcr1)) includes a process selection command (Sel) and a verification examination command. (Jdg (SDB)), registration key generation execution AC creation command (GenAC (GenKcr)), execution AC creation command (GenAC (Ex), registration key destruction command (RevK), encrypted data decryption command (DecEDData), data decryption key (Kcd) is included, and these are encrypted with the registration key (Kcr1).
[0534]
The verification examination command (Jdg (SDB)) is a verification examination processing command of the execution AC based on the service information database (SDB). The service information database (SDB) has the same data configuration as the AC information required for providing the service and the group information database (see FIG. 15) described above, and includes a publisher, a group ID, and group information. Have data.
[0535]
The transfer source security chip (SC), which inputs the service providing execution attribute certificate with transfer function (AC) 711 and executes a process of issuing a new service providing execution attribute certificate with transfer function to the transfer destination, A registration key is acquired from the common key memory area 608 based on the address (Ad1) of the service providing execution attribute certificate with transfer function (AC) 711, and the execution instruction in the service providing execution attribute certificate with transfer function (AC) 711 is acquired. Is decrypted. Next, when the transfer execution trigger 712 is input from the end entity, the transfer execution processing from step S772 is performed.
[0536]
Here, the transfer execution trigger 712 indicates a request process from the end entity to execute the transfer process based on the service providing execution attribute certificate (AC) 711 with the transfer function. The service providing execution attribute certificate (AC) 711 with transfer function is an execution AC that is applied not only to transfer processing but also to decryption processing of encrypted data, and the end entity determines which processing to execute. Select by request (trigger) from tee. Instruction to execute service providing execution attribute certificate (AC) 711 with transfer function (Ec (Sel || Jdg (SDB) || GenAC (GenKcr) || GenAC (Ex) || RevK || DecEDData || Kcd; Kcr1) ), An execution instruction (Jdg (SDB) || GenAC (GenKcr) || GenAC (Ex) || RevK) corresponding to the transfer execution processing is acquired, and the processing in step S772 and subsequent steps is executed according to the execution instruction. .
[0537]
In step S772, the verification and examination of the group attribute certificate (Gp. AC) 713 obtained from the transferee are performed according to the examination command (Jdg (SDB)). This verification processing is the same processing as described above with reference to FIGS. 21 to 23, and includes processing such as signature verification of an attribute certificate, correspondence, and verification of a chained public key certificate. If the verification is not satisfied, the processing is stopped without executing subsequent processing as error processing. If the verification of the group attribute certificate (Gp. AC) succeeds and the validity of the group attribute certificate (Gp. AC) is confirmed, the flow advances to step S773.
[0538]
In step S773 and thereafter, generation and transmission of an execution attribute certificate for enabling use of the encrypted data in the transfer destination user device are performed. These processes correspond to the generation and verification of the registration key generation execution AC described above with reference to FIGS. 60, 61 and 63 to 65, and the generation and transmission of the service provision execution AC. 61, the transfer source user device executes the process of the service provider (SP) in FIG.
[0539]
Data 714 such as a reset key (Kreset) required for these processes, a block address (Ad2) of a registration key storage area of a transfer destination common key memory, and a public key (KpSC2) of a transfer destination security chip are stored in the transfer destination. Acquired from a user device or the like. Based on these necessary data, first, in step S773, the registration key generation execution AC 715 is generated in accordance with the registration key generation execution AC creation command (GenAC (GenKcr)) included in the execution instruction. This is the same as the generation process of the registration key generation execution AC described with reference to FIG.
[0540]
Next, the security chip of the transfer destination user device that has received the registration key generation execution AC from the security chip of the transfer source user device, according to the execution AC creation command (GenAC (Ex)) included in the execution command, first refer to FIG. In accordance with the process described above, a registration key generation execution result (721 in FIG. 80) is generated and transmitted to the security chip of the transfer source user device.
[0541]
The security chip of the transfer source user device that has received the registration key generation execution result (FIG. 80, 721) from the security chip of the transfer destination user device performs the processing according to FIG. 80 to provide a new service with a transfer function. An attribute certificate (AC) 722 is generated and transmitted to the transfer destination user device, and a process of destroying the registration key in its own common key memory area is executed.
[0542]
In step S781 in FIG. 80, the registration key generation result is decrypted by applying the session key (Kcs), and the registration key (Kcr2) and the memory area block address (Ad2) are obtained. Further, in step S782, the execution instruction (Ec (Sel || Jdg (SDB) || GenAC (GenKcr) || GenAC (Ex) ||) stored in the new service providing execution attribute certificate (AC) 722 with a transfer function RevK || DecData || Kcd; Kcr2)) is encrypted by applying the registration key (Kcr2) of the transfer destination user device. The execution instruction is an execution instruction such as an execution program set in a new service providing execution attribute certificate (AC) 722 with a transfer function as a service providing execution AC.
[0543]
Further, in step S783, the data of the execution command encrypted with the registration key (Kcr2) and the data of the memory area block address (Ad2) of the security chip in the transfer destination user device storing the registration key (Kcr2) are compared. A signature (see FIG. 17) is generated by the secret key (KsSC1) of the transfer source security chip (SC1), a new service providing execution attribute certificate (AC) 722 with a transfer function is generated, and the transfer destination user device is generated. Sent to.
[0544]
Further, in step S784, the address (Ad1) stored in the original service providing execution attribute certificate with transfer function (AC) 711, that is, the reset key for the registration key storage address of the common key memory area of the transfer source user device Is written, and the registration key is destroyed.
[0545]
In the above description, a configuration example in which the transfer source generates and sends a new service providing execution attribute certificate (AC) 722 with a transfer function from the transfer source to the transfer destination has been described. Instead of the attribute certificate (AC) 722, a normal, that is, a service providing execution attribute certificate (AC) having no transfer function may be generated and transmitted.
[0546]
As described above, the service providing execution attribute certificate (AC) with transfer function is an execution AC that is applied not only to transfer processing but also to decryption processing of encrypted data. Which of the processes is to be executed is selected by a request (trigger) from the end entity. The processing in the security chip when the trigger is a request for decryption processing of encrypted data will be described with reference to FIG.
[0547]
The service providing execution attribute certificate with transfer function (AC) 731 includes an execution command, a block address (Ad1) of the common key memory area 608 storing a registration key for decrypting the execution command, and data of the issuer signature. Have.
[0548]
The security chip (SC) to which the service providing execution attribute certificate with transfer function (AC) 731 is input first receives the common key memory area based on the address (Ad1) of the service providing execution attribute certificate with transfer function (AC) 731. The registration key is obtained from 608, and the execution command in the service providing execution attribute certificate (AC) 731 with the transfer function is decrypted. Next, when the encrypted data decryption trigger 732 is input from the end entity, selection processing based on the trigger, that is, selection of data decryption execution is performed in step S786, and decryption processing is performed in step S787.
[0549]
That is, the execution instruction (Ec (Sel || Jdg (SDB) || GenAC (GenKcr) || GenAC (Ex) || RevK || DecData || Kcd;) of the service providing execution attribute certificate (AC) 731 with transfer function; Kcr1)), an execution instruction (DecEDData || Kcd) corresponding to the data decryption process is obtained by the selection process, and in step S787, the data decryption key (Kcd) is applied and the decryption target encryption to be input from the outside is performed. The decoding processing of the encrypted data (Ec (Data; Kcd)) 733 is performed, and the decoded data 734 is output. The encrypted data (Ec (Data; Kcd)) 733 to be decrypted is, for example, data obtained by encrypting a content such as an image, music, or a program with a key (Kcd). AC) 731 can be decrypted with a data decryption key (Kcd) that can be obtained by decrypting the storage execution instruction with the registration key (Kcr1).
[0550]
An application example in which the transfer function and the limit on the number of times are combined may be considered. For example, if the execution AC to be transferred is set so that the information on the number of times of execution of the execution AC to be transferred is reduced by one, the number of movements can be limited. Further, an application example in which the copy function and the limit on the number of times are combined may be considered. For example, if the setting is made such that the number-of-times information of the execution attribute certificate is reduced by one each time copying is performed, the number of times of copying can be limited. Here, copying is performed for a service providing execution attribute certificate that does not have a copying function. Furthermore, instead of discarding the duplicated service providing execution attribute certificate, if a function for increasing the number of times information by one is provided, a check-in / check-out function can be realized.
[0551]
Check-in / check-out will be briefly described. Transferring the service usage right to another device is called check-out, and transferring the checked-out device to the original device is called check-in. It has a check-in / check-out function when the service usage authority cannot transfer from the checked-out device to other than the original device.
[0552]
(7-3) Attribute certificate for execution by proxy
Next, the proxy issue execution attribute certificate will be described. (6-3) In the execution attribute certificate application processing, the service of decrypting data obtained by encrypting the content has been described. However, an encryption key known only to the service provider is written in the execution attribute certificate, and signature is performed using the encryption key. The service that issues the certificate can also be performed using the execution attribute certificate. This service providing execution attribute certificate is a proxy issuing execution attribute certificate.
[0553]
As the encryption key, there are a method using a common key and a method using a secret key. Hereinafter, a case where a secret key is used will be described. In order to verify a certificate issued using the proxy issuance execution attribute certificate, the verifier needs to know a public key corresponding to the private key. Therefore, the proxy issue execution attribute certificate issuer issues the above-mentioned public key certificate, and the certificate holder issuing using the proxy issue execution attribute certificate presents the above public key certificate to the verifier. I do. This public key certificate is called a proxy signing key certificate. The following items will be described as the proxy issue execution attribute certificate.
(7-3-1) Examination agency execution attribute certificate
(7-3-2) Proxy signature execution attribute certificate
Hereinafter, each of the above items will be described.
[0554]
(7-3-1) Examination agency execution attribute certificate
First, the examination proxy execution attribute certificate will be described. When the attribute certificate authority issues an attribute certificate to an end entity for which it is difficult to directly exchange information, another attribute that allows the attribute certificate authority to directly exchange information in advance with the issuing policy specified It is the examination proxy execution attribute certificate that enables the end entity to perform the examination of issuance.
[0555]
The outline of the examination proxy execution attribute certificate will be described with reference to FIG. FIG. 82 (a) shows a normal attribute certificate issuance mode. For example, an attribute certificate authority (AA), an attribute certificate registration authority (ARA), A request for issuing an attribute certificate, here, a group attribute certificate (Gp. AC) is issued to an issuer such as a service provider (SP) (S801). For example, in this case, it is necessary to submit data proving the attribute of the AC user. In the above-described embodiment, for example, an example has been described in which a credit card company presents an issued group attribute certificate to an AC user.
[0556]
The issuer executes an examination as user confirmation of the attribute of the AC user (S802), and when it is determined that the examination is successful, the issuer issues an attribute certificate (here, Gp. AC) 801 for certifying the attribute of the AC user. It is issued to the user (S803).
[0557]
The example illustrated in (b) is a group attribute certificate (Gp. AC) issuance sequence to which the examination proxy execution attribute certificate described in detail below is applied.
[0558]
First, a screening agent that issues a group attribute certificate to an AC user by proxy issues to the original issuer, for example, an attribute certificate authority (AA), an attribute certificate registration authority (ARA), or a service provider (SP). Then, a request for issuance of an attribute certificate for examination agent execution (S811) is performed, and the true issuer, such as the attribute certificate authority (AA), the attribute certificate registration authority (ARA) or the service provider (SP), etc. (S812). This is performed based on the data proving the attributes and the like of the examination agent or the presentation of the already-issued attribute certificate, as in the related art. After the examination, the issuer gives the proxy signing key certificate 804 and the examination proxy execution attribute certificate 803 to the examination agent (S813).
[0559]
The proxy signature key certificate 804 includes a public key (Kpa) used for generating and verifying a proxy signature, and issuer signature data. The examination proxy execution attribute certificate 803 includes a block address (Ad) indicating the storage area of the registration key (Kcr) in the common key memory of the user device of the examination proxy and the registration key (Kcr), similarly to the above-described execution certificate. ), An execution instruction (Ec (proxy examination instruction || attribute information || Ksa; Kcr)) and an issuer signature.
[0560]
The secret key (Ksa) included in the execution instruction is a secret key used for generation and verification of a proxy signature, and is a secret key corresponding to the above-described public key (Kpa).
[0561]
Steps S811 to S813 are a proxy commission phase, and after the proxy commission phase is completed, a proxy execution phase is started. An AC user (attribute holder) issues an attribute certificate (Gp. AC) issuance request to the examination agent (S814). Here, the group attribute certificate issued by the screening agent is referred to as a screening agent group attribute certificate.
[0562]
The screening agent who has received the request for issuance of the screening agent group attribute certificate performs a screening of the user (S815). The examination here can also be executed based on the trust relationship between the examination agent and the AC user, and data for certifying the attributes, etc. of the examination agent, or presentation of an already issued attribute certificate, etc. Not necessarily required. For example, if the examination agent is one of a family member and the user is a family member, if the examination agent is recognized as a family, the examination will be approved. Arbitrary examinations can be conducted based on the trusting relationship with.
[0563]
After the completion of the examination, the examination agent generates an examination agent group attribute certificate 802. The examination proxy group attribute certificate 802 includes the public key certificate (PKC) serial number issued to the security chip of the AC user (attribute holder), the attribute information, and the like described above with reference to FIG. With each information. Further, a signature to which the private key (Ksa) stored in the execution instruction of the screening proxy execution attribute certificate 802 received by the screening proxy from the issuer is added first.
[0564]
The examination agent sends the generated examination agent group attribute certificate 802 and the proxy signing key certificate 804 together to the AC user (S816). The AC user presents the screening agent group attribute certificate 802 to, for example, a service provider (SP), certifies the attribute, and receives the service.
[0565]
The flow of data between the entities including the provision of services will be described with reference to FIG. First, in the agency commissioning phase, the issuer 811 sends the examination agency execution AC 822 and the proxy signing key certificate 821 to the examination agency 812. Next, in the proxy execution phase, the screening proxy group attribute certificate 823 and the proxy signing key certificate 821 are sent to the AC user (attribute owner) 813. Further, an examination agent group attribute certificate 823 and a proxy signing key certificate 821 are sent from an AC user (attribute owner) 813 to a verifier 814 such as a service provider (SP). The attribute verification of the AC user based on the examination proxy group attribute certificate 823 and the proxy signature key certificate 821 is executed, and a service is provided on condition that the verification is successful.
[0566]
After verifying the signature of the proxy signing key certificate 821, the verifier 814 such as a service provider (SP) extracts the public key (Kpa) for proxy signature verification stored in the proxy signing key certificate 821 and extracts it. By applying the public key (Kpa), the signature verification of the screening agent group attribute certificate 823 can be executed.
[0567]
Next, a process in which an examination agent who receives the examination agent execution AC 822 and the proxy signing key certificate 821 from the issuer generates and issues an examination agent group attribute certificate 823 based on the request of the AC user will be described with reference to FIG. This will be described with reference to FIG. In FIG. 84,
EE1: an end entity (EE) control unit of the user device using the attribute certificate;
SC1: security chip configured in EE1,
EE2: End entity (EE) control unit of the screening agent user device;
SC2: security chip configured in EE2,
Execution AC table: EE2 execution AC table control unit,
It is.
[0568]
Note that the examination agent is not limited to the user device, and may be configured to be executed by, for example, a service provider (SP). Here, an example in which the user device functions as a screening agent will be described as an example.
[0569]
First, in step S821, the user as an AC user (attribute owner) inputs an issuance request for a screening agent group attribute certificate (Gp. AC) via the input interface of the end entity (EE1). The request includes information required for generating the screening agent group attribute certificate (Gp. AC), such as the designation data of the screening agent and the content or service provider information to be used.
[0570]
When the end entity (EE1) receives an issuance request of the screening agent group attribute certificate (Gp. AC) from the user, the end entity (EE1) determines in step S822 that the end entity of the user device of the screening agent A connection request is issued to (EE2), and mutual authentication is performed between the security chips (SC1) and (SC2) of each user device. This is executed, for example, as the public key mutual authentication process described above with reference to FIG.
[0571]
If the mutual authentication is established, in step S823, the end entity (EE2) of the screening proxy user device outputs a search request for the screening proxy execution AC to the execution AC table. The search key is, for example, content information or service provider (SP) information.
[0572]
In step S824, the execution AC table searches the corresponding examination agency execution AC based on the input key from the end entity (EE2), and issues the execution AC extracted from the table and the AC attached to the AC from the issuer. The obtained proxy signature key certificate (see FIGS. 82 and 804) is output to the end entity (EE2).
[0573]
In step S825, the end entity (EE2) outputs the received AC to the security chip (SC2), and makes a request to apply the execution attribute certificate. In step S826, the security chip (SC2) performs the process of the received AC, that is, the execution based on the registration key acquired from the area specified by the address (Ad) stored in the execution attribute certificate (examination agency execution AC). Performs instruction decoding.
[0574]
Further, in step S827, the group attribute certificate for examination of the AC user is input from the end entity (EE1) of the AC user to the end entity (EE2) of the examination agent, and the security chip of the examination agent is input. In (SC2), a verification process is performed.
[0575]
As described above, the screening agent can perform the screening of the AC user based on the trust relationship between the screening agent and the AC user, and can provide data that certifies the attributes of the screening agent or data already issued. Although it is not always necessary to present an attribute certificate or the like, here, an example is shown in which a screening proxy group attribute certificate is issued on condition that an already issued group attribute certificate is presented and verified.
[0576]
The verification of the group attribute certificate by the security chip (SC2) is the same processing as described above with reference to FIGS. 21 to 23. The signature verification of the attribute certificate, the correspondence and the verification of the chained public key certificate are performed. And the like. If the verification is not satisfied, the processing is stopped without executing subsequent processing as error processing. In this case, a process of transmitting an error notification to the AC user end entity (EE1) may be performed.
[0577]
If the verification of the group attribute certificate (Gp. AC) succeeds and the validity of the group attribute certificate (Gp. AC) is confirmed, in step S830, additional information required for generation of a screening proxy group attribute certificate (Addinfo) is input from the end entity (EE2) to the security chip (SC2), and the security chip (SC2) generates a screening agent group attribute certificate and sends it to the end entity (EE2), and then sends the end entity (EE2). It is sent from (EE2) to the end entity (EE1) of the AC user (S832). In this sending process, a proxy signing key certificate is added to the generated screening agent group attribute certificate and sent.
[0578]
The details of the process executed by the security agent (SC2) of the screening agent, that is, the process of inputting the screening agent execution attribute certificate and generating the screening agent group attribute certificate will be described with reference to FIG. The screening proxy execution attribute certificate (AC) 851 includes a block address of the common key memory area 864 of the screening proxy security chip (SC) 861 storing an execution command and a registration key (Kcr) for decrypting the execution command. Ad), and each data of the issuer signature. The execution instruction (Ec (Jdg (SDB) || GenAC (Gp) || att || Ksa; Kcr)) includes a verification examination command (Jdg (SDB)), a group attribute certificate creation command (GenAC (Gp), The data structure includes attribute information (att) and a secret key for proxy signature (Ksa), and these are encrypted with a registration key (Kcr).
[0579]
When the examination proxy execution attribute certificate (AC) 851 is input, first, a registration key is acquired from the common key memory area 864 based on the address (Ad) of the examination proxy execution attribute certificate (AC) 851 and the examination proxy execution attribute The execution instruction in the certificate (AC) 851 is decrypted. Next, in step S842, the verification of the group attribute certificate input from the AC user via the end entity is executed based on the verification examination command (Jdg (SDB)). This verification processing is the same processing as described above with reference to FIGS. 21 to 23, and includes processing such as signature verification of an attribute certificate, correspondence, and verification of a chained public key certificate. If the verification is not satisfied, the processing is stopped without executing subsequent processing as error processing. When the verification of the group attribute certificate (Gp. AC) is successful and the validity of the group attribute certificate (Gp. AC) is confirmed, the process proceeds to step S843.
[0580]
In step S843, based on the group attribute certificate creation command (GenAC (Gp)) included in the execution command in the screening proxy execution AC 851, the generation and transmission of the screening proxy group attribute certificate are performed. These processes correspond to the generation and verification of the registration key generation execution AC described above with reference to FIGS. 60, 61, and 63 to 65, and the generation and transmission of the service provision execution AC. 65 is the same as the processing in the security module of the service provider (SP) in FIG. For example, it is preferable that additional information (addinfo) 853 indicating that the certificate is a screening proxy attribute certificate is added to the screening proxy attribute certificate to indicate that the certificate is different from a normal attribute certificate.
[0581]
In step S844, a signature is applied to the additional information (addinfo) and the attribute information (att) by applying the secret key (Ksa) for the proxy signature obtained from the execution instruction of the examination proxy execution attribute certificate (AC) 851. , And generates an examination proxy group attribute certificate 854 and transmits it to the AC user (attribute owner) via the end entity (EE2). In addition, a proxy signing key certificate is added to the generated screening agent group attribute certificate and sent to the AC user.
[0582]
The AC user presents the screening agent group attribute certificate and the proxy signing key certificate issued by the above process to a verifier such as a service provider to receive a service conditioned on attribute verification. Become. A verifier such as a service provider can apply the key obtainable from the proxy signing key certificate to verify the signature of the screening agent group attribute certificate.
[0583]
As an application example of the above-described screening agent group attribute certificate, there is an example of issuing a screening agent group attribute certificate in which the number of accounts is limited. When the service provider (SP) provides services to the entire family of Mr. A, whether or not the family is Mr. A is examined using a group attribute certificate (Gp. AC) that proves that he / she is a family of Family A. I do.
[0584]
At this time, an attribute certificate (AC) issued by a third-party organization having basic information of residents such as a government office may be used as a group attribute certificate (Gp. AC) for certifying that the family is the family of Family A. If possible, highly reliable attribute examination can be performed, but such an attribute certificate is not always available. On the other hand, it is possible for Mr. A to issue a group attribute certificate (GpAC) certifying that he is a family of Family A, according to Mr. A's intention. However, it is difficult to determine that an individual such as Mr. A can be trusted as an attribute certificate authority (AA) that is a true issuer of an attribute certificate.
[0585]
Therefore, an examination agent group attribute certificate to which the above-described examination agent execution AC is applied is issued. In this case, Mr. A as a representative of Mr. A's family issues a screening agent group attribute certificate to which the screening agent execution AC is applied, as a screening agent. At this time, the issuance examination of the examination agent group attribute certificate can be executed based on the trust relationship between the examination agent (Mr. A) and the AC user (A's family). It is not always necessary to present data for certifying the attribute or the like, or the presentation of an already issued attribute certificate. If it is determined that the screening agent is a family member, it is possible to issue a screening agent group attribute certificate based on the trust relationship between the screening agent and the AC user, for example, to determine that the screening has been completed.
[0586]
However, Mr. A may issue a screening agent group attribute certificate indicating that he is a family member of A to his friend B who is not actually a family. In order to suppress such a possibility, by limiting the number of issued screening agent group attribute certificates, for example, by setting the upper limit to 5, a limit in the issuing process is added, thereby preventing the occurrence of extreme unauthorized use. It is possible to do.
[0587]
The above described issuance processing mode of the examination proxy group attribute certificate can be similarly processed in the group attribute certificate in which the device owned by Mr. A is set as a group, and the examination proxy group attribute certificate to which the examination proxy execution AC is applied. As a result, it becomes possible for Mr. A to issue a screening agent group attribute certificate to each of the devices owned by Mr. A based on the screening agent execution AC.
[0588]
Further, as an example of processing using the screening agent group attribute certificate, there is an example of application to voting in an election. By using the screening proxy group attribute certificate, voters can conduct elections without knowing who has voted, even to the election commissioner, except for the candidates to vote.
[0589]
In this processing example,
Examination agent: voters
AC user (attribute holder): Candidate
And This election system is different from the actual election in that electorates need to communicate with candidates instead of communicating with the Election Commissioner at the time of voting. First, the service provider (SP) issues a screening agency execution AC to a voters. Voters are asked to provide a unique identification value, that is, an identification value that does not overlap with other votes, from the candidate to be voted, and the number and the PKC serial No. of the candidate to be voted. Is issued and sent to the candidate based on the screening agent execution AC. The screening agent execution AC is automatically destroyed after the generation of the screening agent group attribute certificate (Gp. AC).
[0590]
The number of votes is counted based on the number of screening agent group attribute certificates (Gp. AC) issued to each candidate, and the winning is determined. The screening agent group attribute certificate with the same identification value is considered to be copied, and can only be counted as one vote.
[0591]
(7-3-2) Proxy signature execution attribute certificate
Next, the proxy signature execution attribute certificate will be described. The proxy signature execution AC is an execution attribute certificate that enables the AC user (attribute holder) to issue a group attribute certificate (proxy signature group attribute certificate) to be applied to the service by itself.
[0592]
The outline of the proxy signature execution attribute certificate will be described with reference to FIG. FIG. 86A shows a normal attribute certificate issuance and application processing mode. The attribute holder, who is a user of the attribute certificate (AC), issues an attribute certificate to an issuer such as an attribute certificate authority (AA), an attribute certificate registration authority (ARA), or a service provider (SP). A request for issuing a group attribute certificate (Gp. AC) is made (S901). For example, in this case, it is necessary to submit data proving the attribute of the AC user. In the above-described embodiment, for example, an example has been described in which a credit card company presents an issued group attribute certificate to an AC user.
[0593]
The issuer executes an examination as a user confirmation of the attributes of the AC user (S902), and determines that the examination is successful, and issues an attribute certificate (here, Gp. AC) 921 proving the attributes of the AC user. It is issued to the user (S903).
[0594]
The AC user (attribute holder) can present the issued group attribute certificate (Gp. AC) to a verifier such as a service provider (SP) to receive the service, and receive the service from the verifier. In response to the group attribute certificate (Gp. AC) presentation request (S904), the AC user (attribute holder) presents (S905), and the verifier verifies the group attribute certificate (Gp. AC) (S905). S906) is executed.
[0595]
The example shown in (b) is a group attribute certificate (Gp. AC) issuance and application processing sequence to which a proxy signature execution attribute certificate described in detail below is applied.
[0596]
First, an AC user (attribute holder) issues a proxy signature execution attribute certificate (AC) to an issuer such as an attribute certificate authority (AA), an attribute certificate registration authority (ARA), or a service provider (SP). Is issued (S911). The issuer executes the examination (S912) based on the data proving the attribute of the AC user, for example, the issued group attribute certificate and the like, and issues the proxy signature execution attribute certificate 923 when judging that the examination is successful. . At this time, the issuer also supplies the proxy signature key certificate 924 to the AC user (attribute holder).
[0597]
The proxy signature key certificate 924 has a public key (Kpa) used for generation and verification of a proxy signature, and issuer signature data. Further, the proxy signature execution attribute certificate 923 includes the block address (Ad) indicating the storage area of the registration key (Kcr) in the common key memory of the user device of the examination agent and the registration key (Kcr), similarly to the execution certificate described above. ), An execution instruction (Ec (proxy signature instruction || attribute information || Ksa; Kcr)) and an issuer signature.
[0598]
The secret key (Ksa) included in the execution instruction is a secret key used for generation and verification of a proxy signature, and is a secret key corresponding to the above-described public key (Kpa).
[0599]
Steps S911 to S913 are an issuing phase, and after the issuance phase is completed, a verification phase is started. In step S914, the verifier such as the service provider (SP) makes a request to the AC user (attribute holder) for the presentation of the proxy signature group attribute certificate (Gp. AC). Upon this presentation request, a verifier such as a service provider (SP) transmits a verification random number (Ra) of the proxy signature group attribute certificate (Gp. AC) to the AC user (attribute holder).
[0600]
In step S915, the AC user (attribute holder) received the proxy signature group attribute certificate (Gp. AC) from the issuer in response to a request from the verifier such as the service provider (SP) to present the certificate. By applying the proxy signature execution attribute certificate, a proxy signature group attribute certificate (Gp. AC) 922 is generated. Details of this generation processing will be described later. The proxy signature group attribute certificate (Gp. AC) 922 includes the serial number and attribute information of the public key certificate (PKC) of the AC user (attribute holder) in addition to the verification random number ( Ra), and a signature to which the private key (Ksa) stored in the execution command of the proxy signature execution attribute certificate 923 received from the issuer is added first.
[0601]
The AC user (attribute holder) sends the generated proxy signature group attribute certificate 922 and the proxy signature key certificate 924 together to the verifier (S916). After verifying the signature of the proxy signature key certificate 924, the verifier extracts the public key (Kpa) for proxy signature verification stored in the proxy signature key certificate 924, and applies the extracted public key (Kpa). Then, the signature verification of the proxy signature group attribute certificate 922 is executed. In addition, by verifying the match between the random number stored in the proxy signature group attribute certificate and the random number generated earlier by the self, the proxy signature group attribute certificate presented in response to the verifier's request in this verification is verified. You can confirm that it is a letter.
[0602]
The flow of data between the entities including the provision of services will be described with reference to FIG. First, in the issuance phase, a proxy signing key certificate 941 and a proxy signature execution attribute certificate 942 are sent from the issuer 931 to the AC user (attribute holder) 932 to the AC user (attribute holder) 932. You. Next, when a service request is made from an AC user (attribute holder) 932 to a verifier 933 such as a service provider (SP), the verifier 933 substitutes a signature for the AC user (attribute holder) 932. A presentation request for a group attribute certificate (Gp. AC) is executed. Upon this presentation request, the verifier 933 transmits the verification random number (Ra) of the proxy signature group attribute certificate (Gp. AC) to the AC user (attribute holder) 932.
[0603]
The AC user (attribute holder) 932 applies the proxy signature execution attribute certificate previously received from the issuer in response to the presentation request of the proxy signature group attribute certificate (Gp. AC) from the verifier 933. To generate a proxy signature group attribute certificate (Gp. AC) 943. The proxy signature group attribute certificate (Gp. AC) 943 includes the information such as the serial number and attribute information of the public key certificate (PKC) of the AC user (attribute holder) 932 and the verification random number received from the verifier. (Ra), and a signature to which the private key (Ksa) stored in the execution instruction of the proxy signature execution attribute certificate 942 received from the issuer is added first.
[0604]
Next, the AC user (attribute owner) 932 sends the proxy signature group attribute certificate 943 and the proxy signature key certificate 941 to the verifier, and the verifier sends the proxy signature group attribute certificate 943 and the proxy The attribute verification of the AC user based on the signature key certificate 941 is executed, and a service is provided on condition that the verification is successful.
[0605]
After verifying the signature of the proxy signing key certificate 941, the verifier 933 such as a service provider (SP) extracts and extracts the public key (Kpa) for proxy signature verification stored in the proxy signing key certificate 941. The signature verification of the proxy signature group attribute certificate 943 is performed by applying the public key (Kpa), and the verification is performed by comparing the stored random number of the proxy signature group attribute certificate 943.
[0606]
Next, an AC user having a proxy signature execution attribute certificate and a proxy signature key certificate issued by the issuer executes the request when a verifier such as a service provider (SP) requests presentation of a proxy signature group attribute certificate. Details of the processing to be performed will be described with reference to FIG. In FIG. 88,
SP: a service provider control unit that executes verification of an attribute certificate;
SM: Security module for SP
EE: end entity (EE) control unit of the user device using the attribute certificate;
SC: security chip configured in EE,
Execution AC table: EE execution AC table control unit,
It is.
[0607]
The processing in FIG. 88 illustrates processing after mutual authentication is established between the security module (SM) of the service provider (SP) and the security chip (SC) of the user device.
[0608]
After the mutual authentication is established, the service provider (SP) requests the security module (SM) to generate a random number to be applied at the time of attribute certificate verification (S951). In step S952, the security module (SM) A random number is generated according to a request and output to a service provider (SP).
[0609]
In step S953, the service provider (SP) issues a request for a proxy signature group attribute certificate to the end entity (EE). At this time, the service provider (SP) also transmits the verification random number (Ra) of the proxy signature group attribute certificate (Gp. AC) to the end entity (EE).
[0610]
In step S954, the end entity (EE) searches the execution AC table for a proxy signature execution attribute certificate to be applied to the generation of the proxy signature group attribute certificate (Gp. AC). In step S955, the proxy signature execution attribute certificate and the corresponding proxy signature key certificate are output to the end entity (EE).
[0611]
In step S956, the end entity (EE) requests the security chip (SC) to apply the proxy signature execution attribute certificate, that is, generate a proxy signature group attribute certificate, and in step S958, the security chip ( SC) executes a proxy signature group attribute certificate generation process. The details of the process of generating the proxy signature group attribute certificate are the same as the processes of the examination proxy group attribute certificate based on the examination proxy execution attribute certificate described above with reference to FIG. However, the random number (Ra) received from the verifier is stored in the proxy signature group attribute certificate.
[0612]
In step S958, the security chip (SC) sends the generated proxy signature group attribute certificate to the end entity (EE). In step S959, the end entity (EE) transmits the proxy signature group attribute certificate and the proxy signature key certificate previously received from the issuer to the security module (SM) on the service provider side.
[0613]
When the security module (SM) on the service provider side receives the proxy signature group attribute certificate and the proxy signature key certificate, the security module (SM) extracts the public key (Kpa) for proxy signature verification stored in the proxy signature key certificate. The signature verification of the proxy signature group attribute certificate is executed by applying the extracted public key (Kpa), the verification based on the collation processing of the stored random number of the proxy signature group attribute certificate is performed, and the verification result is determined by the service provider ( SP). According to the response result, the service provider (SP) executes the service provision if the verification is established, and performs the service provision stop processing if the verification is not established.
[0614]
As an application example of the proxy signature execution attribute certificate, there is a normal attribute certificate. That is, if a proxy signature execution attribute certificate is used instead of a normal attribute certificate, the execution attribute certificate destruction processing function can be used. , And a reduction in reliability can be solved.
[0615]
As a further application example, there is a proxy signature attribute certificate in which the number of times of attribute certification is limited. In other words, for a service other than decryption of encrypted data, such as access permission, if a proxy signature execution attribute certificate with a function of limiting the number of times is used as a group attribute certificate that allows the service to be provided, it can be externalized to a server or the like. It is possible to provide a limited service without complicating processing such as providing information on the number of times and reducing processing efficiency.
[0616]
[(8) Configuration of each entity]
Next, an end entity (EE) having a security chip (SC) as a user device or a user having a security chip (SC) as a user device for executing the above-described processing, ie, generation, verification, transmission and reception of an attribute certificate, and the like. A configuration example of each entity as an information processing device such as an identification device (UID) or a service provider (SP) will be described with reference to the drawings.
[0617]
An information processing apparatus of each entity such as a user device and a service provider has a CPU for executing various data processing and control, and includes communication means capable of communicating with other entities. For example, a server, a PC, a PDA, It can be configured by various information processing devices such as a mobile communication terminal device.
[0618]
FIG. 89 shows a configuration example of an information processing apparatus. The configuration example shown in FIG. 89 is one example, and each entity is not necessarily required to have all the functions shown here. A CPU (Central processing Unit) 951 illustrated in FIG. 89 is a processor that executes various application programs and an OS (Operating System). A ROM (Read-Only-Memory) 952 stores a program executed by the CPU 951 or fixed data as operation parameters. A RAM (Random Access Memory) 953 is used as a storage area and a work area for a program executed in the processing of the CPU 951 and parameters appropriately changed in the program processing.
[0619]
The HDD 954 controls the hard disk, and executes processing for storing and reading various data and programs to and from the hard disk. The security chip 962 has a tamper-resistant structure as described above, stores key data and the like necessary for encryption processing, and performs encryption processing for performing verification or generation processing of an attribute certificate as authority confirmation processing. Unit, a data processing unit, and a memory.
[0620]
The bus 960 is configured by a PCI (Peripheral Component Interface) bus or the like, and enables data transfer with each module and each input / output device via the input / output interface 961.
[0621]
The input unit 955 includes, for example, a keyboard, a pointing device, and the like, and is operated by a user to input various commands and data to the CPU 951. The output unit 956 is, for example, a CRT, a liquid crystal display, or the like, and displays various types of information as text or images.
[0622]
The communication unit 957 includes an entity connected to the device, for example, a network interface for executing communication processing with a service provider or the like, a connection device interface, and the like. Under the control of the CPU 951, data supplied from each storage unit or the CPU 951 A process for transmitting processed data, encrypted data, and the like, and receiving data from another entity is executed.
[0623]
The drive 958 is a drive that performs recording and reproduction of a removable recording medium 959 such as a flexible disk, a CD-ROM (Compact Disc Only Memory), an MO (Magneto optical) disk, a DVD (Digital Versatile Disc), a magnetic disk, and a semiconductor memory. Yes, it executes the reproduction of the program or data from the removable recording medium 959, and the storage of the program or data in the removable recording medium 959.
[0624]
When a program or data recorded in each storage medium is read and executed or processed in the CPU 951, the read program or data is supplied to, for example, the connected RAM 953 via the interface 961 and the bus 960.
[0625]
A program for executing processing in a user device, a service provider, or the like included in the above description is stored in, for example, the ROM 952 and processed by the CPU 951, or stored in a hard disk and supplied to the CPU 951 via the HDD 954 for execution. Is done.
[0626]
The present invention has been described in detail with reference to the specific embodiments. However, it is obvious that those skilled in the art can modify or substitute the embodiment without departing from the spirit of the present invention. That is, the present invention has been disclosed by way of example, and should not be construed as limiting. In order to determine the gist of the present invention, the claims described at the beginning should be considered.
[0627]
The series of processes described in the specification can be executed by hardware, software, or a combined configuration of both. When executing the processing by software, the program recording the processing sequence is installed in a memory in a computer embedded in dedicated hardware and executed, or the program is stored in a general-purpose computer capable of executing various processing. It can be installed and run.
[0628]
For example, the program can be recorded in a hard disk or a ROM (Read Only Memory) as a recording medium in advance. Alternatively, the program is temporarily or permanently stored on a removable recording medium such as a flexible disk, a CD-ROM (Compact Disc Only Memory), an MO (Magneto optical) disk, a DVD (Digital Versatile Disc), a magnetic disk, or a semiconductor memory. It can be stored (recorded). Such a removable recording medium can be provided as so-called package software.
[0629]
The program is installed in the computer from the removable recording medium as described above, and is wirelessly transferred from the download site to the computer, or is transferred to the computer by wire via a network such as a LAN (Local Area Network) or the Internet. The computer can receive the program transferred in this way and install it on a recording medium such as a built-in hard disk.
[0630]
The various processes described in the specification may be executed not only in chronological order according to the description but also in parallel or individually according to the processing capability of the device that executes the processes or as necessary. Further, in this specification, a system is a logical set configuration of a plurality of devices, and is not limited to a device having each configuration in the same housing.
[0631]
【The invention's effect】
As described above, according to the data processing authority management system, information processing apparatus, and method of the present invention, an encryption execution instruction including an encrypted data processing execution instruction and a decryption of the encryption execution instruction An execution attribute certificate having, as stored data, address (Ad) information indicating the storage area of the memory in the user device of the registration key applied to the process is provided to the user device as the service receiving device, and the execution is executed by the user device. According to the address (Ad) information stored in the attribute certificate, the registration key acquired from the memory of the user device is applied to decrypt the encryption execution instruction stored in the execution attribute certificate, and the data based on the decryption result Since the process is configured to execute, the registration key can be obtained from the user device that can be obtained according to the address stored in the execution attribute certificate. There only it is possible to execute the execution command stored in the execution attribute certificate, it is possible to provide a strictly limited service to users having a service use authority.
[0632]
Further, according to the data processing authority management system, the information processing apparatus, and the method of the present invention, the storage of the registration key applied to the service providing execution attribute certificate is performed according to the registration key generation execution attribute certificate. An unauthorized registration key is prevented from being stored, and an unauthorized service reception can be reliably prevented.
[0633]
Further, according to the data processing authority management system, the information processing apparatus, and the method of the present invention, since the registration key is destroyed by writing the reset key, it is possible to prevent unauthorized registration key from being held. It becomes possible.
[0634]
Further, in the data processing authority management system, information processing apparatus, and method of the present invention, the applicable number identification value is stored in the execution instruction, and the applicable number identification value is updated according to the execution of the execution instruction. Since a new execution attribute certificate including the applicable number-of-applicable times identification value is generated, it is possible to receive a service with a limited number of times of use under a certain number of times.
[0635]
Further, according to the data processing authority management system, the information processing apparatus, and the method of the present invention, a transfer processing execution attribute certificate generation processing instruction, a screening proxy attribute certificate issuance processing instruction, and a proxy signature attribute certificate issuance processing By storing various execution instructions such as instructions in the execution attribute certificate, various usage forms of the attribute certificate are realized.
[Brief description of the drawings]
FIG. 1 is a diagram illustrating a public key infrastructure and an authority management infrastructure configuration in an authority management system.
FIG. 2 is a diagram showing a format of a public key certificate.
FIG. 3 is a diagram showing a format of a public key certificate.
FIG. 4 is a diagram showing a format of a public key certificate.
FIG. 5 is a diagram showing a format of an attribute certificate as an authority information certificate.
FIG. 6 is a diagram illustrating a configuration example of an issuer, an owner, a verifier, and attribute information of a group attribute certificate (group AC).
FIG. 7 is a diagram illustrating an issuance policy table of a group attribute certificate.
FIG. 8 is a diagram showing a trust model for explaining a trust relationship configuration of each entity participating in the authority management system.
FIG. 9 is a diagram illustrating a configuration example of a security chip configured in an end entity (EE) as a user device and a user identification device (UID).
FIG. 10 illustrates an example of data stored in a security chip of a user device.
FIG. 11 is a diagram illustrating an outline of a flow of a group attribute certificate issuance application, an issuance process, and a use process.
FIG. 12 is a diagram illustrating group information sharing processing between a service provider (SP) and an attribute certificate authority (AA) or an attribute certificate registration authority (ARA).
FIG. 13 is a diagram showing a handshake protocol (TLS1.0), which is one authentication processing method of the public key encryption method.
FIG. 14 is a diagram illustrating a configuration for generating a message authentication code: MAC (Message Authentication Code).
FIG. 15 is a diagram illustrating an information configuration example of an issuance policy table and a group information database.
FIG. 16 is a diagram showing a processing sequence in a case where a security chip (SC) of an end entity (EE) which is a user device is a subject of a request for issuing a group attribute certificate.
FIG. 17 is a flowchart illustrating a process of generating a digital signature.
FIG. 18 is a flowchart illustrating a digital signature verification process.
FIG. 19 is a sequence diagram illustrating a procedure for issuing a group attribute certificate corresponding to a user security chip (USC) in a user identification device (UID).
FIG. 20 is a sequence diagram illustrating processing up to service start including service use authority confirmation using a group attribute certificate.
FIG. 21 is a diagram illustrating the relationship between a public key certificate (PKC) and an attribute certificate (AC).
FIG. 22 is a diagram illustrating a flow of an attribute certificate (AC) verification process.
FIG. 23 is a diagram showing a verification processing flow of a public key certificate (PKC).
FIG. 24
FIG. 9 is a sequence diagram illustrating a process up to service start including service use authority confirmation using a group attribute certificate.
FIG. 25 is a sequence diagram illustrating a process of examining a group attribute certificate (Gp. AC).
FIG. 26 is a diagram illustrating a concept in a case where a service or a provision condition is that a user or a user device belongs to a plurality of different groups.
FIG. 27 is a sequence diagram illustrating a process up to service provision based on a group attribute certificate issued corresponding to a user security chip (USC) in a user identification device (UID).
FIG. 28 is a sequence diagram illustrating a process up to service provision based on a group attribute certificate issued corresponding to a user security chip (USC) in a user identification device (UID).
FIG. 29 is a sequence diagram illustrating a process of issuing and storing a group attribute certificate between user devices.
FIG. 30 is a diagram illustrating a sequence of a process of issuing a group attribute certificate having access permission information as an attribute.
FIG. 31 is a diagram illustrating an example of correspondence between a group attribute certificate having access permission information as group information and another group attribute certificate.
FIG. 32 is a diagram illustrating a processing sequence in which an access request destination user device requests another user device to execute an attribute certificate issuing process without executing the attribute certificate issuing process by itself.
FIG. 33 is a diagram illustrating a service use sequence including an access permission / inhibition determination process using a group attribute certificate in which access permission information is defined as group information.
FIG. 34 is a diagram showing an example of a group attribute certificate used in each service.
FIG. 35 is a sequence diagram illustrating a process of issuing a second group attribute certificate B including content use permission information as group information based on the first group attribute certificate A.
FIG. 36 is a sequence diagram illustrating a process of presenting a group attribute certificate B to a service provider, confirming that the user has content use authority, and providing a service, that is, receiving a content distribution service.
FIG. 37 is a diagram illustrating an example of an attribute certificate applied to a process of providing a service by confirming a content use right of a user or a user device by applying a plurality of different attribute certificates.
FIG. 38 is a flowchart for explaining content use authority confirmation and service provision processing to which different group attribute certificates are applied.
FIG. 39 is a diagram illustrating a configuration example of a combination table data of group attribute certificates set as service provision conditions.
FIG. 40 is a diagram illustrating a usage authority confirmation process to which a plurality of group attribute certificates are applied.
FIG. 41 is a diagram showing an example of a group attribute certificate applied in medical processing.
FIG. 42 is a diagram illustrating an attribute certificate stored in each device in a remote control system that performs medical processing.
FIG. 43 is a diagram illustrating a processing sequence for performing a use right confirmation process of an execution service of a medical diagnosis program by applying a group attribute certificate stored in a user identification device, and starting the service.
FIG. 44 is a diagram illustrating a processing sequence for performing a use right confirmation process of a diagnostic data collection processing service as a result of executing a medical diagnostic program by applying a group attribute certificate, and starting the service.
FIG. 45 is a diagram illustrating an example of a group attribute certificate applied in the remote maintenance process.
FIG. 46 is a diagram illustrating an attribute certificate stored in each device in a system for performing a maintenance service.
FIG. 47 is a diagram illustrating a use mode of a service attribute certificate and a control attribute certificate when executing a service.
FIG. 48 is a sequence diagram illustrating service processing such as maintenance to which a service attribute certificate stored in a home electric appliance (EE) and a control attribute certificate stored in a service provider are applied.
FIG. 49 is a diagram illustrating a service attribute certificate examination process.
FIG. 50 is a diagram illustrating a sequence for executing a service based on a control attribute certificate, for example, a maintenance process for a home electric appliance.
FIG. 51 is a diagram illustrating an example in which a maintenance execution program is transmitted from a manufacturer device (SP) to a user home electric appliance (EE).
FIG. 52 transmits a maintenance execution program from the manufacturer-side device (SP) to the home appliance (EE) sequentially, and executes a response-corresponding process while receiving a response based on the command execution from the home appliance (EE). It is a figure explaining an example.
FIG. 53 is a diagram illustrating an example of processing for presenting a service attribute certificate and a control attribute certificate to a manufacturer (SP) when a service provision request is made.
FIG. 54 is a diagram illustrating an example of a group attribute certificate applied in the communication service.
FIG. 55 is a diagram illustrating a storage configuration example of a group attribute certificate applied in the communication service.
FIG. 56 is a diagram illustrating a processing sequence for performing a use right confirmation process of the chat room participation service by applying the group attribute certificate and starting the service.
FIG. 57 is a diagram illustrating a processing sequence for performing access right confirmation processing by applying a group attribute certificate and starting communication.
FIG. 58 is a diagram illustrating an outline of an execution attribute certificate.
FIG. 59 is a flowchart illustrating an outline of a procedure for using an execution attribute certificate.
FIG. 60 is an issuance sequence diagram of an execution attribute certificate.
FIG. 61 is an issuance sequence diagram of an execution attribute certificate.
FIG. 62 is a diagram illustrating a configuration example of an execution AC table.
FIG. 63 is a diagram illustrating a process of generating a registration key generation execution AC in the security module (SM).
FIG. 64 is a diagram illustrating a registration key generation process based on a registration key generation execution AC executed by the security chip.
FIG. 65 is a diagram illustrating a process of generating a service providing execution AC by a security module (SM).
FIG. 66 is a diagram summarizing an application sequence of the service providing execution AC on the user device side.
FIG. 67 is a diagram for explaining processing details in service provision processing in the security chip (SC).
FIG. 68 is a diagram for describing security chip (SC) registration key destruction processing.
FIG. 69 is a diagram illustrating a reset process as a process of destroying a registration key based on a reset request.
FIG. 70 is a diagram for explaining an execution attribute certificate reset (destruction) process of discarding an execution attribute certificate under the approval of a service provider (SP) and notifying the service provider that the destruction has been performed without error. is there.
FIG. 71 is a diagram for describing an execution attribute certificate reset (destruction) process of discarding an execution attribute certificate under the approval of a service provider (SP) and notifying the service provider that the destruction has been performed without error. is there.
FIG. 72 is a diagram illustrating details of a reset confirmation result generation process.
FIG. 73 is a diagram illustrating a registration key destruction process based on an execution AC.
FIG. 74 is a diagram illustrating a process of applying a service by applying a service providing execution attribute certificate with a limited number of times to a user device.
FIG. 75 is a diagram illustrating a process of applying a service by applying a service providing execution attribute certificate with a limited number of times to a user device.
FIG. 76 is a diagram for describing processing in the security chip (SC) when the number of remaining uses after update ≧ 1.
FIG. 77 is a view for explaining processing in the security chip (SC) when the number of remaining uses after update = 0.
FIG. 78 is a diagram illustrating an application process of a service providing execution attribute certificate with a transfer function.
FIG. 79 is a diagram illustrating details of processing after the decryption processing of the service providing execution attribute certificate with the transfer function.
FIG. 80 is a diagram illustrating details of processing after decryption processing of the service providing execution attribute certificate with the transfer function.
FIG. 81 is a diagram illustrating an encrypted data decryption process to which a service providing execution attribute certificate with a transfer function is applied.
FIG. 82 is a view for explaining an outline of an examination proxy execution attribute certificate.
FIG. 83 is a view for explaining processing to which a screening proxy execution attribute certificate is applied;
FIG. 84 is a diagram illustrating a process of generating and issuing a screening proxy group attribute certificate.
FIG. 85 is a diagram illustrating a process of generating a screening proxy group attribute certificate by inputting a screening proxy execution attribute certificate.
FIG. 86 is a view for explaining an outline of a proxy signature execution attribute certificate.
FIG. 87 is a view for explaining processing to which a proxy signature execution attribute certificate is applied;
FIG. 88 is a diagram for describing processing executed when a verifier such as a service provider (SP) requests presentation of a proxy signature group attribute certificate.
FIG. 89 is a diagram illustrating an example of an information processing device configuration of each entity such as a user device and a service provider.
[Explanation of symbols]
101 Public Key Infrastructure
102 Authority management platform
111, 113 User device
112 Service Provider
121 public key certificate
122 attribute certificate
130 System holder
131 Root Certificate Authority (CA)
132 Certificate Authority (CA)
133 Registration Authority (RA)
140 Attribute Certificate Authority (AA)
150 Attribute Certificate Authority (ARA)
151 Policy table
160 Service Provider (SP)
170 User Device
171 User Identification Device (UID)
172 End Entity (EE)
200 user devices
201 CPU (Central processing Unit)
202 Interface
203 ROM (Read-Only-Memory)
204 RAM (Random Access Memory)
205 Cryptographic processing unit
206 Memory section
207 Common key memory area
210 Security Chip
221 User device side control unit
222 External memory unit
231 Connection Device Interface
232 network interface
311 User device
312 Attribute Certificate Authority (ARA)
313 Issuance policy table
314 Service Provider
315 Group Information Database
316 Group attribute certificate
401 Hospital side medical equipment (SP)
402 Group attribute certificate AC02
403 Security Module
411 Home medical equipment (EE)
412 Security Chip
421 User identification device
422 Group attribute certificate AC01
423 User Security Chip
451 Manufacturer's equipment (SP)
452 Control attribute certificate
453 Security Module
461 User's Home Appliance (EE)
462 Service attribute certificate
463 Security Chip
471 User identification device
472 User Security Chip
481 User Device
482 Manufacturer's equipment (SP)
483 Service Information Database
484 Service attribute certificate
485 Control attribute certificate
491 User Device
492 Manufacturer side equipment (SP)
493 Service attribute certificate
494 Control Attribute Certificate
501 Chat Room Service Provider (SP)
502 Security Module
511 Mr. Ko's communication terminal (EE)
512 Security Chip
521 User Identification Device
522 User Security Chip
523 Group attribute certificate AC01
524 Group attribute certificate AC02
531 Otsusan communication terminal (EE)
532 Security Chip
533 User Identification Device (UID)
534 User Security Chip (USC)
601 Security Module
602 public key encryption engine
603 secret key encryption engine
605 security chip
606 Public Key Cryptographic Engine
607 Symmetric key encryption engine
608 Common key memory area
611 Registration key generation execution attribute certificate (AC)
612 Registration key generation execution result
613 Execution instruction
614 Service Provision Execution Attribute Certificate (AC)
615 Encrypted data
616 data
617 Reset processing instruction
621 Reset confirmation execution attribute certificate (AC)
622 Reset confirmation result
623 Registration key destruction execution attribute certificate (AC)
701 Service offer execution attribute certificate (AC) with limited number of times
702 Encrypted data
703 data
704 Service offer execution attribute certificate with limited number of times (AC)
705 Service offer execution attribute certificate (AC) with limited number of times
706 Encrypted data
707 data
711 Service providing execution attribute certificate with transfer function (AC)
712 Transfer execution trigger
713 Group attribute certificate
714 data
715 Registration Key Generation Execution Attribute Certificate (AC)
721 Registration key generation execution result
722 Service providing execution attribute certificate with transfer function (AC)
731 Service providing execution attribute certificate with transfer function (AC)
732 Encrypted data trigger
733 Encrypted data
734 data
801 Group attribute certificate
802 Examination Agency Group Attribute Certificate
803 Examination agency execution attribute certificate
804 Proxy signing key certificate
811 Issuer
812 Examination agent
813 AC user (attribute holder)
814 Verifier
821 Proxy Signing Key Certificate
822 Examination Agency Execution Attribute Certificate
823 Examination Agency Group Attribute Certificate
851 Examination Agency Execution Attribute Certificate (Proxy Signature Execution Attribute Certificate)
852 Group attribute certificate
853 Additional information
854 Examination agency group attribute certificate (proxy signature group attribute certificate)
921 Group Attribute Certificate
922 Proxy Signature Group Attribute Certificate
923 Proxy Signature Execution Attribute Certificate
924 Proxy signing key certificate
931 Issuer
932 AC user (attribute holder)
933 Verifier
941 Proxy Signing Key Certificate
942 Proxy Signature Execution Attribute Certificate
943 Proxy Signature Group Attribute Certificate
951 CPU (Central processing Unit)
952 ROM (Read-Only-Memory)
953 RAM (Random Access Memory)
954 HDD
955 Input section
956 Output unit
957 Communication unit
958 drive
959 Removable recording medium
960 bus
961 I / O interface
962 Security Chip

Claims (39)

サービスプロバイダの提供するサービスを実行するユーザデバイスにおけるデータ処理権限を管理するデータ処理権限管理システムであり、
サービスプロバイダは、
暗号化処理のなされたデータ処理実行命令を含む暗号化実行命令と、該暗号化実行命令の復号処理に適用する登録鍵のユーザデバイス内メモリの格納領域を示すアドレス（Ａｄ）情報とを格納データとして有する実行属性証明書をサービス受領デバイスであるユーザデバイスに対して提供し、
ユーザデバイスは、
前記実行属性証明書に格納されたアドレス（Ａｄ）情報に従って、該ユーザデバイスのメモリから取得した登録鍵を適用して、該実行属性証明書に格納された暗号化実行命令の復号を行ない、復号結果に基づくデータ処理を実行する構成としたことを特徴とするデータ処理権限管理システム。A data processing authority management system that manages data processing authority in a user device that executes a service provided by a service provider,
The service provider
The stored data includes an encryption execution instruction including an encrypted data processing execution instruction, and address (Ad) information indicating a storage area of a memory in the user device of a registration key applied to the decryption processing of the encryption execution instruction. Providing the execution attribute certificate having as a to the user device which is the service receiving device,
The user device
According to the address (Ad) information stored in the execution attribute certificate, a registration key obtained from the memory of the user device is applied to decrypt the encryption execution instruction stored in the execution attribute certificate, and decrypt the encrypted execution instruction. A data processing authority management system, wherein data processing is performed based on a result. 前記実行属性証明書は、
前記暗号化実行命令および前記アドレス（Ａｄ）情報とを含む格納データに対する発行者電子署名を有し、
前記ユーザデバイスは、
前記実行属性証明書の電子署名検証処理を実行し、該検証の成立を条件として、前記アドレス（Ａｄ）情報に従った登録鍵の取得処理を実行する構成であることを特徴とする請求項１に記載のデータ処理権限管理システム。The execution attribute certificate includes:
An issuer electronic signature for stored data including the encryption execution instruction and the address (Ad) information;
The user device comprises:
2. A configuration in which a digital signature verification process of the execution attribute certificate is executed, and a process of acquiring a registration key according to the address (Ad) information is executed on condition that the verification is established. 2. A data processing authority management system according to item 1. 前記データ処理権限管理システムにおいて、
ユーザデバイスに対する新たな実行属性証明書の発行処理は、
実行属性証明書発行エンティテイが、実行属性証明書発行要求ユーザデバイスから、特定機器または特定ユーザの集合からなるグループに対応して設定されるグループ識別情報を格納情報として有し発行者電子署名を有するグループ属性証明書を受領し、該受領グループ属性証明書についての検証を実行し、該検証の成立を条件として実行する構成であることを特徴とする請求項１に記載の権限管理システム。In the data processing authority management system,
The process of issuing a new execution attribute certificate for a user device
The execution attribute certificate issuing entity has, as storage information, group identification information set corresponding to a group consisting of a specific device or a set of specific users from the execution attribute certificate issuance request user device, and has an issuer electronic signature. The authority management system according to claim 1, wherein the authority management system is configured to receive a group attribute certificate, execute verification of the received group attribute certificate, and execute the verification on condition that the verification is established. 前記サービスプロバイダは、
前記ユーザデバイスから登録鍵格納予定アドレス情報を取得し、
該登録鍵格納予定アドレス情報と、登録鍵の格納命令をユーザデバイスの取得可能な鍵を適用して暗号化した暗号化実行命令とを有するデータ部と、該データ部に対する電子署名を含む登録鍵生成実行属性証明書を生成してユーザデバイスに提供する構成を有し、
ユーザデバイスは、
前記電子署名の検証、前記登録鍵生成実行属性証明書に格納された暗号化実行命令の復号、および復号により取得した実行命令の処理により、登録鍵を前記登録鍵格納予定アドレスに対応するメモリ領域に格納する処理を実行する構成であることを特徴とする請求項１に記載のデータ処理権限管理システム。The service provider,
Obtain registration key storage scheduled address information from the user device,
A data part having the registration key storage scheduled address information, an encryption execution instruction obtained by encrypting the registration key storage instruction by applying a key obtainable by a user device, and a registration key including an electronic signature for the data part A configuration for generating a generation execution attribute certificate and providing it to the user device;
The user device
The verification of the electronic signature, the decryption of the encryption execution instruction stored in the registration key generation execution attribute certificate, and the processing of the execution instruction obtained by the decryption, cause the registration key to be stored in the memory area corresponding to the registration key storage scheduled address. 2. The data processing authority management system according to claim 1, wherein the data processing authority management system is configured to execute a process of storing the authority in the data processing authority. 前記登録鍵は、前記ユーザデバイスにおいて、乱数に基づいて生成される鍵であることを特徴とする請求項４に記載のデータ処理権限管理システム。The data processing authority management system according to claim 4, wherein the registration key is a key generated based on a random number in the user device. 前記ユーザデバイスは、
前記実行属性証明書に格納されたアドレス（Ａｄ）情報に従って、該ユーザデバイスのメモリから取得した登録鍵を適用して、該実行属性証明書に格納された暗号化実行命令の復号を行ない、復号結果に基づくデータ処理を実行するとともに、
前記登録鍵格納領域を指定したアドレス（Ａｄ）に対応するメモリ領域に、リセット鍵データを書き込むことにより登録鍵の破棄処理を実行する構成であることを特徴とする請求項１に記載のデータ処理権限管理システム。The user device comprises:
According to the address (Ad) information stored in the execution attribute certificate, a registration key obtained from the memory of the user device is applied to decrypt the encryption execution instruction stored in the execution attribute certificate, and decrypt the encrypted execution instruction. Perform data processing based on the results,
2. The data processing according to claim 1, wherein a registration key is destroyed by writing reset key data in a memory area corresponding to an address (Ad) specifying the registration key storage area. 3. Authority management system. 前記実行属性証明書に格納された暗号化実行命令には、
実行命令の適用可能回数識別値が格納され、
前記ユーザデバイスは、
実行命令の実行に応じて前記適用可能回数識別値を更新して、更新された適用可能回数識別値を含む新たな実行属性証明書の生成を行なう構成であることを特徴とする請求項１に記載のデータ処理権限管理システム。The encryption execution instruction stored in the execution attribute certificate includes:
The identification number of the applicable number of execution instructions is stored,
The user device comprises:
The configuration according to claim 1, wherein the applicable number identification value is updated in response to execution of the execution instruction, and a new execution attribute certificate including the updated applicable number identification value is generated. Data processing authority management system described. 前記実行属性証明書に格納された暗号化実行命令には、
実行命令の適用可能回数識別値が格納され、
前記ユーザデバイスは、
実行命令の実行に応じて前記適用可能回数識別値を更新して、更新された適用可能回数識別値が０である場合に、前記登録鍵格納領域を指定したアドレス（Ａｄ）に対応するメモリ領域に、リセット鍵データを書き込むことにより登録鍵の破棄処理を実行する構成であることを特徴とする請求項１に記載のデータ処理権限管理システム。The encryption execution instruction stored in the execution attribute certificate includes:
The identification number of the applicable number of execution instructions is stored,
The user device comprises:
The applicable number identification value is updated according to the execution of the execution instruction, and when the updated applicable number identification value is 0, the memory area corresponding to the address (Ad) specifying the registration key storage area 2. The data processing authority management system according to claim 1, wherein a registration key is destroyed by writing reset key data into the system. 前記実行属性証明書に格納された暗号化実行命令は、
他デバイスへの譲渡用実行属性証明書の生成処理命令を含み、
前記ユーザデバイスは、
前記譲渡用実行属性証明書の生成処理命令に従い、
新たな譲渡用実行属性証明書の生成処理を実行し、他デバイスへの提供処理を実行する構成であることを特徴とする請求項１に記載のデータ処理権限管理システム。The encryption execution instruction stored in the execution attribute certificate includes:
Includes an instruction to generate an execution attribute certificate for transfer to another device,
The user device comprises:
According to the generation processing instruction of the transfer execution attribute certificate,
2. The data processing authority management system according to claim 1, wherein the data processing authority management system is configured to execute a process of generating a new assignment execution attribute certificate and execute a process of providing the certificate to another device. 前記実行属性証明書に格納された暗号化実行命令には、
他デバイスの属性を証明する証明書としての審査代行属性証明書の発行処理命令、および該審査代行属性証明書の生成に必要とする署名生成用鍵を含み、
前記ユーザデバイスは、
前記審査代行属性証明書の発行処理命令に従い、
前記署名生成用鍵を適用して署名を実行した審査代行属性証明書の生成処理を行い、他のサービス受領デバイスへの提供処理を実行する構成であることを特徴とする請求項１に記載のデータ処理権限管理システム。The encryption execution instruction stored in the execution attribute certificate includes:
Including a processing instruction for issuing a screening proxy attribute certificate as a certificate for certifying the attribute of another device, and a signature generation key required for generating the screening proxy attribute certificate;
The user device comprises:
According to the processing instruction for issuing the examination proxy attribute certificate,
The configuration according to claim 1, wherein a process of generating a screening proxy attribute certificate in which the signature is executed by applying the signature generation key is performed, and a process of providing the certificate to another service receiving device is performed. Data processing authority management system. 前記審査代行属性証明書の生成を実行したユーザデバイスは、
前記他のサービス受領デバイスへの前記審査代行属性証明書の提供に併せて、前記署名生成用鍵に対応する署名検証用鍵を格納し発行者署名を有する代理署名鍵証明書を提供し、
前記他のサービス受領デバイスは、サービス提供エンティテイに対して、前記審査代行属性証明書および、代理署名鍵証明書を提示し、
前記サービス提供エンティテイは、
前記代理署名鍵証明書から取得した署名検証用鍵に基づく前記審査代行属性証明書の検証処理を実行する構成であることを特徴とする請求項１０に記載のデータ処理権限管理システム。The user device that has executed the generation of the screening proxy attribute certificate,
Along with providing the screening proxy attribute certificate to the other service receiving device, a proxy signature key certificate that stores a signature verification key corresponding to the signature generation key and has an issuer signature is provided,
The other service receiving device presents the examination proxy attribute certificate and the proxy signing key certificate to a service providing entity,
The service providing entity is:
11. The data processing authority management system according to claim 10, wherein a verification process of the examination proxy attribute certificate is performed based on a signature verification key acquired from the proxy signature key certificate. 前記実行属性証明書に格納された暗号化実行命令には、
他デバイスの属性を証明する証明書としての代理署名属性証明書の発行処理命令、および該代理署名属性証明書の生成に必要とする署名生成用鍵を含み、
前記ユーザデバイスは、
前記代理署名属性証明書の発行処理命令に従い、
該代理署名属性証明書の検証を実行する検証デバイスから受領した検証用乱数（Ｒａ）を格納データとして含み、前記署名生成用鍵を適用した署名を有する代理署名属性証明書の生成処理を行い、生成した前記代理署名属性証明書、および前記署名生成用鍵に対応する署名検証用鍵を格納し発行者署名を有する代理署名鍵証明書を検証デバイスとしてのサービス提供エンティテイに提示する処理を実行し、
前記サービス提供エンティテイは、
前記代理署名鍵証明書から取得した署名検証用鍵に基づく、署名検証、および前記代理署名属性証明書の実行命令から抽出した乱数照合による前記代理署名鍵証明書の検証処理を実行する構成であることを特徴とする請求項１に記載のデータ処理権限管理システム。The encryption execution instruction stored in the execution attribute certificate includes:
A command for issuing a proxy signature attribute certificate as a certificate for certifying the attribute of another device, and a signature generation key required for generating the proxy signature attribute certificate,
The user device comprises:
According to the proxy signature attribute certificate issuance processing instruction,
A proxy signature attribute certificate including a verification random number (Ra) received from a verification device that executes verification of the proxy signature attribute certificate as storage data and having a signature to which the signature generation key is applied is generated. A process for storing the generated proxy signature attribute certificate and the signature verification key corresponding to the signature generation key and presenting the proxy signature key certificate having the issuer signature to the service providing entity as a verification device is executed. ,
The service providing entity is:
It is configured to execute signature verification based on a signature verification key obtained from the proxy signature key certificate and verification processing of the proxy signature key certificate by random number collation extracted from an execution command of the proxy signature attribute certificate. 2. The data processing authority management system according to claim 1, wherein: データ処理を実行する情報処理装置であり、
暗号化データの復号処理に適用する登録鍵を格納するメモリ部と、
暗号化処理のなされたデータ処理実行命令を含む暗号化実行命令と、該暗号化実行命令の復号処理に適用する登録鍵の情報処理装置内のメモリにおける格納領域を示すアドレス（Ａｄ）情報とを格納データとして有し、発行者署名のなされた実行属性証明書を入力し、署名検証処理を実行するとともに、署名検証の成立を条件として、前記アドレス（Ａｄ）情報に従って、前記メモリ部から取得した登録鍵を適用して前記暗号化実行命令を復号する暗号処理部と、
前記暗号処理部において復号された実行命令を実行するデータ処理部と、
を有することを特徴とする情報処理装置。An information processing device that performs data processing,
A memory unit for storing a registration key applied to the decryption processing of the encrypted data,
An encryption execution instruction including an encrypted data processing execution instruction, and address (Ad) information indicating a storage area in a memory in the information processing device of a registration key to be applied to the decryption processing of the encryption execution instruction. An execution attribute certificate having an issuer signature is input as input data, and a signature verification process is executed. The signature is obtained from the memory unit in accordance with the address (Ad) information on condition that signature verification is established. An encryption processing unit that applies a registration key to decrypt the encryption execution instruction,
A data processing unit that executes the execution instruction decrypted in the encryption processing unit;
An information processing apparatus comprising: 前記データ処理部は、
前記登録鍵格納領域を指定したアドレス（Ａｄ）に対応するメモリ領域に、リセット鍵データを書き込むことにより登録鍵の破棄処理を実行する構成であることを特徴とする請求項１３に記載の情報処理装置。The data processing unit includes:
14. The information processing according to claim 13, wherein the registration key is written in a memory area corresponding to an address (Ad) in which the registration key storage area is specified, thereby executing a registration key discarding process. apparatus. 前記実行属性証明書に格納された暗号化実行命令には、
実行命令の適用可能回数識別値が格納され、
前記データ処理部は、
実行命令の実行に応じて前記適用可能回数識別値を更新して、更新された適用可能回数識別値を含む新たな実行属性証明書の生成を行なう構成であることを特徴とする請求項１３に記載の情報処理装置。The encryption execution instruction stored in the execution attribute certificate includes:
The identification number of the applicable number of execution instructions is stored,
The data processing unit includes:
14. The configuration according to claim 13, wherein the applicable number identification value is updated in accordance with the execution of the execution instruction, and a new execution attribute certificate including the updated applicable number identification value is generated. An information processing apparatus according to claim 1. 前記実行属性証明書に格納された暗号化実行命令には、
実行命令の適用可能回数識別値が格納され、
前記データ処理部は、
実行命令の実行に応じて前記適用可能回数識別値を更新して、更新された適用可能回数識別値が０となった場合に、前記登録鍵格納領域を指定したアドレス（Ａｄ）に対応するメモリ領域に、リセット鍵データを書き込むことにより登録鍵の破棄処理を実行する構成であることを特徴とする請求項１３に記載の情報処理装置。The encryption execution instruction stored in the execution attribute certificate includes:
The identification number of the applicable number of execution instructions is stored,
The data processing unit includes:
The applicable number of times identification value is updated according to the execution of the execution instruction, and when the updated applicable number of times identification value becomes 0, the memory corresponding to the address (Ad) specifying the registration key storage area 14. The information processing apparatus according to claim 13, wherein the registration key is destroyed by writing reset key data to the area. 前記実行属性証明書に格納された暗号化実行命令は、
他デバイスへの譲渡用実行属性証明書の生成処理命令を含み、
前記データ処理部は、
前記譲渡用実行属性証明書の生成処理命令に従い、
新たな譲渡用実行属性証明書の生成処理を実行し、他デバイスへの提供処理を実行する構成であることを特徴とする請求項１３に記載の情報処理装置。The encryption execution instruction stored in the execution attribute certificate includes:
Includes an instruction to generate an execution attribute certificate for transfer to another device,
The data processing unit includes:
According to the generation processing instruction of the transfer execution attribute certificate,
14. The information processing apparatus according to claim 13, wherein the information processing apparatus is configured to execute a process of generating a new transfer execution attribute certificate and execute a process of providing the certificate to another device. 前記実行属性証明書に格納された暗号化実行命令には、
他デバイスの属性を証明する証明書としての審査代行属性証明書の発行処理命令、および該審査代行属性証明書の生成に必要とする署名生成用鍵を含み、
前記データ処理部は、
前記審査代行属性証明書の発行処理命令に従い、
前記署名生成用鍵を適用して署名を実行した審査代行属性証明書の生成処理を実行する構成であることを特徴とする請求項１３に記載の情報処理装置。The encryption execution instruction stored in the execution attribute certificate includes:
Including a processing instruction for issuing a screening proxy attribute certificate as a certificate for certifying the attribute of another device, and a signature generation key required for generating the screening proxy attribute certificate;
The data processing unit includes:
According to the processing instruction for issuing the examination proxy attribute certificate,
The information processing apparatus according to claim 13, wherein the information processing apparatus is configured to execute a process of generating a screening proxy attribute certificate in which a signature is executed by applying the signature generation key. 前記実行属性証明書に格納された暗号化実行命令には、
他デバイスの属性を証明する証明書としての代理署名属性証明書の発行処理命令、および該代理署名属性証明書の生成に必要とする署名生成用鍵を含み、
前記データ処理部は、
前記代理署名属性証明書の発行処理命令に従い、
該代理署名属性証明書の検証を実行する検証デバイスから受領した検証用乱数（Ｒａ）を格納データとして含み、前記署名生成用鍵を適用した署名を有する代理署名属性証明書の生成処理を実行する構成であることを特徴とする請求項１３に記載の情報処理装置。The encryption execution instruction stored in the execution attribute certificate includes:
A command for issuing a proxy signature attribute certificate as a certificate for certifying the attribute of another device, and a signature generation key required for generating the proxy signature attribute certificate,
The data processing unit includes:
According to the proxy signature attribute certificate issuance processing instruction,
A verification random number (Ra) received from a verification device that performs verification of the proxy signature attribute certificate is included as storage data, and a process of generating a proxy signature attribute certificate having a signature to which the signature generation key is applied is performed. The information processing apparatus according to claim 13, wherein the information processing apparatus has a configuration. サービスプロバイダの提供するサービスを実行するユーザデバイスにおけるデータ処理権限を管理するデータ処理権限管理方法であり、
サービスプロバイダにおける実行ステップとして、
暗号化処理のなされたデータ処理実行命令を含む暗号化実行命令と、該暗号化実行命令の復号処理に適用する登録鍵のユーザデバイス内メモリの格納領域を示すアドレス（Ａｄ）情報とを格納データとして有する実行属性証明書をサービス受領デバイスであるユーザデバイスに対して提供するステップを有し、
ユーザデバイスにおける実行ステップとして、
前記実行属性証明書に格納されたアドレス（Ａｄ）情報に従って、該ユーザデバイスのメモリから登録鍵を取得するステップと、
取得した登録鍵を適用して、該実行属性証明書に格納された暗号化実行命令の復号を実行するステップと、
復号結果に基づくデータ処理を実行するステップと、
を有することを特徴とするデータ処理権限管理方法。A data processing authority management method for managing data processing authority in a user device that executes a service provided by a service provider,
As an execution step in the service provider,
The stored data includes an encryption execution instruction including an encrypted data processing execution instruction, and address (Ad) information indicating a storage area of a memory in the user device of a registration key applied to the decryption processing of the encryption execution instruction. Providing an execution attribute certificate having as a user device which is a service receiving device,
As an execution step in the user device,
Obtaining a registration key from the memory of the user device according to the address (Ad) information stored in the execution attribute certificate;
Executing the decryption of the encrypted execution instruction stored in the execution attribute certificate by applying the obtained registration key;
Performing data processing based on the decryption result;
And a data processing authority management method. 前記実行属性証明書は、
前記暗号化実行命令および前記アドレス（Ａｄ）情報とを含む格納データに対する発行者電子署名を有し、
前記ユーザデバイスは、
前記実行属性証明書の電子署名検証処理を実行し、該検証の成立を条件として、前記アドレス（Ａｄ）情報に従った登録鍵の取得処理を実行することを特徴とする請求項２０に記載のデータ処理権限管理方法。The execution attribute certificate includes:
An issuer electronic signature for stored data including the encryption execution instruction and the address (Ad) information;
The user device comprises:
21. The digital signature verification process of the execution attribute certificate, and a registration key acquisition process according to the address (Ad) information is executed on condition that the verification is established. Data processing authority management method. 前記データ処理権限管理方法において、
ユーザデバイスに対する新たな実行属性証明書の発行処理は、
実行属性証明書発行エンティテイが、実行属性証明書発行要求ユーザデバイスから、特定機器または特定ユーザの集合からなるグループに対応して設定されるグループ識別情報を格納情報として有し発行者電子署名を有するグループ属性証明書を受領し、該受領グループ属性証明書についての検証を実行し、該検証の成立を条件として実行することを特徴とする請求項２０に記載の権限管理方法。In the data processing authority management method,
The process of issuing a new execution attribute certificate for a user device
The execution attribute certificate issuing entity has, as storage information, group identification information set corresponding to a group consisting of a specific device or a set of specific users from the execution attribute certificate issuance request user device, and has an issuer electronic signature. 21. The authority management method according to claim 20, wherein a group attribute certificate is received, verification of the received group attribute certificate is executed, and the verification is executed on condition that the verification is established. 前記データ処理権限管理方法は、さらに、
前記サービスプロバイダにおける実行ステップとして、
前記ユーザデバイスから登録鍵格納予定アドレス情報を取得するステップと、
該登録鍵格納予定アドレス情報と、登録鍵の格納命令をユーザデバイスの取得可能な鍵を適用して暗号化した暗号化実行命令とを有するデータ部と、該データ部に対する電子署名を含む登録鍵生成実行属性証明書を生成して、ユーザデバイスに提供するステップとを有し、
ユーザデバイスにおける実行ステップとして、
前記電子署名の検証、前記登録鍵生成実行属性証明書に格納された暗号化実行命令の復号、および復号により取得した実行命令の処理により、登録鍵を前記登録鍵格納予定アドレスに対応するメモリ領域に格納する処理ステップと、
を有することを特徴とする請求項２０に記載のデータ処理権限管理方法。The data processing authority management method further includes:
As an execution step in the service provider,
Obtaining registration key storage scheduled address information from the user device;
A data part having the registration key storage scheduled address information, an encryption execution instruction obtained by encrypting the registration key storage instruction by applying a key obtainable by a user device, and a registration key including an electronic signature for the data part Generating a generated execution attribute certificate and providing the generated execution attribute certificate to a user device;
As an execution step in the user device,
The verification of the electronic signature, the decryption of the encryption execution instruction stored in the registration key generation execution attribute certificate, and the processing of the execution instruction obtained by the decryption, cause the registration key to be stored in the memory area corresponding to the registration key storage scheduled address. Processing steps to be stored in
21. The data processing authority management method according to claim 20, comprising: 前記データ処理権限管理方法において、さらに、
前記ユーザデバイスにおける実行ステップとして、乱数に基づいて前記登録鍵を生成するステップを有することを特徴とする請求項２３に記載のデータ処理権限管理方法。In the data processing authority management method,
24. The data processing authority management method according to claim 23, further comprising a step of generating the registration key based on a random number as an execution step in the user device. 前記ユーザデバイスは、さらに、
前記登録鍵格納領域を指定したアドレス（Ａｄ）に対応するメモリ領域に、リセット鍵データを書き込むことにより登録鍵の破棄処理を実行することを特徴とする請求項２０に記載のデータ処理権限管理方法。The user device further comprises:
21. The data processing authority management method according to claim 20, wherein the registration key is destroyed by writing reset key data in a memory area corresponding to an address (Ad) that designates the registration key storage area. . 前記実行属性証明書に格納された暗号化実行命令には、
実行命令の適用可能回数識別値が格納され、
前記ユーザデバイスは、
実行命令の実行に応じて前記適用可能回数識別値を更新して、更新された適用可能回数識別値を含む新たな実行属性証明書の生成を行なうことを特徴とする請求項２０に記載のデータ処理権限管理方法。The encryption execution instruction stored in the execution attribute certificate includes:
The identification number of the applicable number of execution instructions is stored,
The user device comprises:
21. The data according to claim 20, wherein the applicable number identification value is updated in response to execution of the execution instruction, and a new execution attribute certificate including the updated applicable number identification value is generated. Processing authority management method. 前記実行属性証明書に格納された暗号化実行命令には、
実行命令の適用可能回数識別値が格納され、
前記ユーザデバイスは、
実行命令の実行に応じて前記適用可能回数識別値を更新して、更新された適用可能回数識別値が０となった場合に、前記登録鍵格納領域を指定したアドレス（Ａｄ）に対応するメモリ領域にリセット鍵データを書き込むことにより登録鍵の破棄処理を実行することを特徴とする請求項２０に記載のデータ処理権限管理方法。The encryption execution instruction stored in the execution attribute certificate includes:
The identification number of the applicable number of execution instructions is stored,
The user device comprises:
The applicable number of times identification value is updated according to the execution of the execution instruction, and when the updated applicable number of times identification value becomes 0, the memory corresponding to the address (Ad) specifying the registration key storage area 21. The data processing authority management method according to claim 20, wherein the registration key is destroyed by writing reset key data in the area. 前記実行属性証明書に格納された暗号化実行命令は、
他デバイスへの譲渡用実行属性証明書の生成処理命令を含み、
前記ユーザデバイスは、
前記譲渡用実行属性証明書の生成処理命令に従い、
新たな譲渡用実行属性証明書の生成処理を実行し、他デバイスへの提供処理を実行することを特徴とする請求項２０に記載のデータ処理権限管理方法。The encryption execution instruction stored in the execution attribute certificate includes:
Includes an instruction to generate an execution attribute certificate for transfer to another device,
The user device comprises:
According to the generation processing instruction of the transfer execution attribute certificate,
21. The data processing authority management method according to claim 20, wherein a process of generating a new transfer execution attribute certificate is executed, and a process of providing the certificate to another device is executed. 前記実行属性証明書に格納された暗号化実行命令には、
他デバイスの属性を証明する証明書としての審査代行属性証明書の発行処理命令、および該審査代行属性証明書の生成に必要とする署名生成用鍵を含み、
前記ユーザデバイスは、
前記審査代行属性証明書の発行処理命令に従い、
前記署名生成用鍵を適用して署名を実行した審査代行属性証明書の生成処理を行い、他のサービス受領デバイスへの提供処理を実行する構成であることを特徴とする請求項２０に記載のデータ処理権限管理方法。The encryption execution instruction stored in the execution attribute certificate includes:
Including a processing instruction for issuing a screening proxy attribute certificate as a certificate for certifying the attribute of another device, and a signature generation key required for generating the screening proxy attribute certificate;
The user device comprises:
According to the processing instruction for issuing the examination proxy attribute certificate,
21. The configuration according to claim 20, wherein a process of generating a screening proxy attribute certificate in which a signature is executed by applying the signature generation key is performed, and a process of providing the certificate to another service receiving device is performed. Data processing authority management method. 前記審査代行属性証明書の生成を実行したユーザデバイスは、
前記他のサービス受領デバイスへの前記審査代行属性証明書の提供に併せて、前記署名生成用鍵に対応する署名検証用鍵を格納し、発行者署名を有する代理署名鍵証明書を提供し、
前記他のサービス受領デバイスは、サービス提供エンティテイに対して、前記審査代行属性証明書および、代理署名鍵証明書を提示し、
前記サービス提供エンティテイは、
前記代理署名鍵証明書から取得した署名検証用鍵に基づく前記審査代行属性証明書の検証処理を実行する構成であることを特徴とする請求項２９に記載のデータ処理権限管理方法。The user device that has executed the generation of the screening proxy attribute certificate,
Along with the provision of the screening proxy attribute certificate to the other service receiving device, a signature verification key corresponding to the signature generation key is stored, and a proxy signature key certificate having an issuer signature is provided.
The other service receiving device presents the examination proxy attribute certificate and the proxy signing key certificate to a service providing entity,
The service providing entity is:
30. The data processing authority management method according to claim 29, wherein a verification process of the examination proxy attribute certificate is performed based on a signature verification key acquired from the proxy signature key certificate. 前記実行属性証明書に格納された暗号化実行命令には、
他デバイスの属性を証明する証明書としての代理署名属性証明書の発行処理命令、および該代理署名属性証明書の生成に必要とする署名生成用鍵を含み、
前記ユーザデバイスは、
前記代理署名属性証明書の発行処理命令に従い、
該代理署名属性証明書の検証を実行する検証デバイスから受領した検証用乱数（Ｒａ）を含み、前記署名生成用鍵を適用した署名を有する代理署名属性証明書の生成処理を行い、生成した前記代理署名属性証明書、および前記署名生成用鍵に対応する署名検証用鍵を格納し、発行者署名を有する代理署名鍵証明書を検証デバイスとしてのサービス提供エンティテイに提示する処理を実行し、
前記サービス提供エンティテイは、
前記代理署名鍵証明書から取得した署名検証用鍵に基づく、署名検証、および前記代理署名属性証明書の実行命令から抽出した乱数照合による前記代理署名鍵証明書の検証処理を実行することを特徴とする請求項２０に記載のデータ処理権限管理方法。The encryption execution instruction stored in the execution attribute certificate includes:
A command for issuing a proxy signature attribute certificate as a certificate for certifying the attribute of another device, and a signature generation key required for generating the proxy signature attribute certificate,
The user device comprises:
According to the proxy signature attribute certificate issuance processing instruction,
A proxy signature attribute certificate including a verification random number (Ra) received from a verification device that executes verification of the proxy signature attribute certificate and having a signature to which the signature generation key is applied is generated. Executing a process of storing a proxy signature attribute certificate and a signature verification key corresponding to the signature generation key, and presenting a proxy signature key certificate having an issuer signature to a service providing entity as a verification device;
The service providing entity is:
Performing signature verification based on a signature verification key obtained from the proxy signature key certificate and verifying the proxy signature key certificate by random number verification extracted from an execution command of the proxy signature attribute certificate. 21. The data processing authority management method according to claim 20, wherein: データ処理を実行する情報処理装置における情報処理方法であり、
暗号化処理のなされたデータ処理実行命令を含む暗号化実行命令と、該暗号化実行命令の復号処理に適用する登録鍵の情報処理装置内のメモリにおける格納領域を示すアドレス（Ａｄ）情報とを格納データとして有し発行者署名のなされた実行属性証明書を入力するステップと、
署名検証処理を実行するとともに、署名検証の成立を条件として、前記アドレス（Ａｄ）情報に従って、前記メモリから登録鍵を取得するステップと、
取得した登録鍵を適用して前記暗号化実行命令を復号するステップと、
復号された実行命令を実行するデータ処理ステップと、
を有することを特徴とする情報処理方法。An information processing method in an information processing apparatus that performs data processing,
An encryption execution instruction including an encrypted data processing execution instruction, and address (Ad) information indicating a storage area in a memory in the information processing device of a registration key to be applied to the decryption processing of the encryption execution instruction. Inputting an execution attribute certificate which is stored data and signed by an issuer;
Executing a signature verification process and obtaining a registration key from the memory in accordance with the address (Ad) information, provided that the signature verification is established;
Decrypting the encryption execution instruction by applying the obtained registration key;
A data processing step for executing the decrypted execution instruction;
An information processing method comprising: 前記情報処理方法において、さらに、
前記登録鍵格納領域を指定したアドレス（Ａｄ）に対応するメモリ領域に、リセット鍵データを書き込むことにより登録鍵の破棄処理を実行するステップを有することを特徴とする請求項３２に記載の情報処理方法。In the information processing method,
33. The information processing according to claim 32, further comprising a step of executing a registration key discarding process by writing reset key data in a memory area corresponding to an address (Ad) specifying the registration key storage area. Method. 前記実行属性証明書に格納された暗号化実行命令には、
実行命令の適用可能回数識別値が格納され、
前記情報処理方法は、さらに、
実行命令の実行に応じて前記適用可能回数識別値を更新して、更新された適用可能回数識別値を含む新たな実行属性証明書の生成を行なうことを特徴とする請求項３２に記載の情報処理方法。The encryption execution instruction stored in the execution attribute certificate includes:
The identification number of the applicable number of execution instructions is stored,
The information processing method further includes:
33. The information according to claim 32, wherein the applicable number identification value is updated in accordance with the execution of the execution instruction, and a new execution attribute certificate including the updated applicable number identification value is generated. Processing method. 前記実行属性証明書に格納された暗号化実行命令には、
実行命令の適用可能回数識別値が格納され、
前記情報処理方法は、さらに、
実行命令の実行に応じて前記適用可能回数識別値を更新して、更新された適用可能回数識別値が０となった場合に、前記登録鍵格納領域を指定したアドレス（Ａｄ）に対応するメモリ領域に、リセット鍵データを書き込むことにより登録鍵の破棄処理を実行することを特徴とする請求項３２に記載の情報処理方法。The encryption execution instruction stored in the execution attribute certificate includes:
The identification number of the applicable number of execution instructions is stored,
The information processing method further includes:
The applicable number of times identification value is updated according to the execution of the execution instruction, and when the updated applicable number of times identification value becomes 0, the memory corresponding to the address (Ad) specifying the registration key storage area 33. The information processing method according to claim 32, wherein the registration key is destroyed by writing reset key data to the area. 前記実行属性証明書に格納された暗号化実行命令は、
他デバイスへの譲渡用実行属性証明書の生成処理命令を含み、
前記情報処理方法は、さらに、
前記譲渡用実行属性証明書の生成処理命令に従い、
新たな譲渡用実行属性証明書の生成処理を実行し、他デバイスへの提供処理を実行することを特徴とする請求項３２に記載の情報処理方法。The encryption execution instruction stored in the execution attribute certificate includes:
Includes an instruction to generate an execution attribute certificate for transfer to another device,
The information processing method further includes:
According to the generation processing instruction of the transfer execution attribute certificate,
33. The information processing method according to claim 32, wherein a process of generating a new transfer execution attribute certificate is performed, and a process of providing the certificate to another device is performed. 前記実行属性証明書に格納された暗号化実行命令には、
他デバイスの属性を証明する証明書としての審査代行属性証明書の発行処理命令、および該審査代行属性証明書の生成に必要とする署名生成用鍵を含み、
前記情報処理方法は、さらに、
前記審査代行属性証明書の発行処理命令に従い、
前記署名生成用鍵を適用して署名を実行した審査代行属性証明書の生成処理を実行することを特徴とする請求項３２に記載の情報処理方法。The encryption execution instruction stored in the execution attribute certificate includes:
Including a processing instruction for issuing a screening proxy attribute certificate as a certificate for certifying the attribute of another device, and a signature generation key required for generating the screening proxy attribute certificate;
The information processing method further includes:
According to the processing instruction for issuing the examination proxy attribute certificate,
33. The information processing method according to claim 32, wherein a process of generating a screening proxy attribute certificate in which a signature is executed by applying the signature generation key is executed. 前記実行属性証明書に格納された暗号化実行命令には、
他デバイスの属性を証明する証明書としての代理署名属性証明書の発行処理命令、および該代理署名属性証明書の生成に必要とする署名生成用鍵を含み、
前記情報処理方法は、さらに、
前記代理署名属性証明書の発行処理命令に従い、
該代理署名属性証明書の検証を実行する検証デバイスから受領した検証用乱数（Ｒａ）を格納データとして含み、前記署名生成用鍵を適用した署名を有する代理署名属性証明書の生成処理を実行することを特徴とする請求項３２に記載の情報処理方法。The encryption execution instruction stored in the execution attribute certificate includes:
A command for issuing a proxy signature attribute certificate as a certificate for certifying the attribute of another device, and a signature generation key required for generating the proxy signature attribute certificate,
The information processing method further includes:
According to the proxy signature attribute certificate issuance processing instruction,
A verification random number (Ra) received from a verification device that performs verification of the proxy signature attribute certificate is included as storage data, and a process of generating a proxy signature attribute certificate having a signature to which the signature generation key is applied is performed. 33. The information processing method according to claim 32, wherein: データ処理を実行する情報処理装置における情報処理を実行せしめるコンピュータ・プログラムであって、
暗号化処理のなされたデータ処理実行命令を含む暗号化実行命令と、該暗号化実行命令の復号処理に適用する登録鍵の情報処理装置内のメモリにおける格納領域を示すアドレス（Ａｄ）情報とを格納データとして有し発行者署名のなされた実行属性証明書を入力するステップと、
署名検証処理を実行するとともに、署名検証の成立を条件として、前記アドレス（Ａｄ）情報に従って、前記メモリから登録鍵を取得するステップと、
取得した登録鍵を適用して前記暗号化実行命令を復号するステップと、
復号された実行命令を実行するデータ処理ステップと、
を有することを特徴とするコンピュータ・プログラム。A computer program for executing information processing in an information processing apparatus that executes data processing,
An encryption execution instruction including an encrypted data processing execution instruction, and address (Ad) information indicating a storage area in a memory in the information processing device of a registration key to be applied to the decryption processing of the encryption execution instruction. Inputting an execution attribute certificate which is stored data and signed by an issuer;
Executing a signature verification process and obtaining a registration key from the memory in accordance with the address (Ad) information, provided that the signature verification is established;
Decrypting the encryption execution instruction by applying the obtained registration key;
A data processing step for executing the decrypted execution instruction;
A computer program comprising:
JP2002167480A 2002-06-07 2002-06-07 Data processing authority management system, information processing apparatus and method, and computer program Expired - Fee Related JP4207465B2 (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
JP2002167480A JP4207465B2 (en) 2002-06-07 2002-06-07 Data processing authority management system, information processing apparatus and method, and computer program

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
JP2002167480A JP4207465B2 (en) 2002-06-07 2002-06-07 Data processing authority management system, information processing apparatus and method, and computer program

Publications (3)

Publication Number Publication Date
JP2004015527A true JP2004015527A (en) 2004-01-15
JP2004015527A5 JP2004015527A5 (en) 2005-10-13
JP4207465B2 JP4207465B2 (en) 2009-01-14

Family

ID=30434711

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2002167480A Expired - Fee Related JP4207465B2 (en) 2002-06-07 2002-06-07 Data processing authority management system, information processing apparatus and method, and computer program

Country Status (1)

Country Link
JP (1) JP4207465B2 (en)

Cited By (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2006311425A (en) * 2005-05-02 2006-11-09 Kddi Corp Method and system for user authentication
JP2008009717A (en) * 2006-06-29 2008-01-17 Megachips Lsi Solutions Inc Information processing terminal and content writing system
JP2008538033A (en) * 2005-04-08 2008-10-02 エレクトロニクス アンド テレコミュニケーションズ リサーチ インスチチュート Domain context showing user and device based domain system and management method thereof
JP2009129214A (en) * 2007-11-26 2009-06-11 Nippon Telegr & Teleph Corp <Ntt> Authority transfer system, authority transfer method and authority transfer program
JP2009175910A (en) * 2008-01-23 2009-08-06 Nippon Telegr & Teleph Corp <Ntt> Right transfer system, right transfer method and right transfer program
CN110061894A (en) * 2019-03-29 2019-07-26 国民技术股份有限公司 A kind of appliance control method, system and household master control set
JP2022509794A (en) * 2018-11-21 2022-01-24 タレス・ディス・フランス・エス・ア Circuit chip and how to operate it

Cited By (10)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2008538033A (en) * 2005-04-08 2008-10-02 エレクトロニクス アンド テレコミュニケーションズ リサーチ インスチチュート Domain context showing user and device based domain system and management method thereof
JP4856169B2 (en) * 2005-04-08 2012-01-18 エレクトロニクス アンド テレコミュニケーションズ リサーチ インスチチュート Domain context showing user and device based domain system and management method thereof
US8533858B2 (en) 2005-04-08 2013-09-10 Electronics And Telecommunications Research Institute Domain management method and domain context of users and devices based domain system
JP2006311425A (en) * 2005-05-02 2006-11-09 Kddi Corp Method and system for user authentication
JP2008009717A (en) * 2006-06-29 2008-01-17 Megachips Lsi Solutions Inc Information processing terminal and content writing system
US9092648B2 (en) 2006-06-29 2015-07-28 Megachips Corporation Information processing terminal and content writing system
JP2009129214A (en) * 2007-11-26 2009-06-11 Nippon Telegr & Teleph Corp <Ntt> Authority transfer system, authority transfer method and authority transfer program
JP2009175910A (en) * 2008-01-23 2009-08-06 Nippon Telegr & Teleph Corp <Ntt> Right transfer system, right transfer method and right transfer program
JP2022509794A (en) * 2018-11-21 2022-01-24 タレス・ディス・フランス・エス・ア Circuit chip and how to operate it
CN110061894A (en) * 2019-03-29 2019-07-26 国民技术股份有限公司 A kind of appliance control method, system and household master control set

Also Published As

Publication number Publication date
JP4207465B2 (en) 2009-01-14

Similar Documents

Publication Publication Date Title
JP3786055B2 (en) Data processing system, data processing apparatus and method, and computer program
EP1505765A1 (en) Data processing system, data processing device, data processing method, and computer program
JP5025009B2 (en) Authentication method, host computer and recording medium
CN103348623B (en) Termination, checking device, key distribution device, content reproducing method and cryptographic key distribution method
US6990583B2 (en) Public-key-encryption data-communication system and data-communication-system forming method
US7496756B2 (en) Content usage-right management system and management method
JP4082717B2 (en) Anonymous signature method and apparatus using shared private key
JP5815525B2 (en) Information processing apparatus, controller, key issuing authority, revocation list validity determination method, and key issuance method
JP4644900B2 (en) Service providing system, service providing method, service mediating apparatus, and program providing medium via communication means
CN1973480A (en) Content providing system, information processing device, and memory card
WO2002089048A1 (en) Data processing system, memory device, data processor, data processing method, and program
JP2002014929A (en) Access control system, access control method, device, access control server, access control server, access control server registration server, data processor and program storage medium
JP2002207426A (en) System and method for issuing public key certificate, electronic certification device, and program storage medium
KR20170141976A (en) System and method for providing electronic signature service
JPWO2015193945A1 (en) Update program and method, and management program and method
JP2002297548A (en) Terminal registration system, and device and method for constituting the same
JP2004015507A (en) Access right management system, communication processor and method, and computer program
JP4884509B2 (en) Content management server, content management system, and content management method
JP4207465B2 (en) Data processing authority management system, information processing apparatus and method, and computer program
JP2004015495A (en) Authority management system, information processing apparatus and method therefor, as well as computer program
JP2004140636A (en) System, server, and program for sign entrustment of electronic document
JP2003085048A (en) Backup data management system, backup data management method, and information processing device, and computer program
JP2003087237A (en) Contents utilization management system, its method, information processor, and computer program
CN109146684B (en) Decentralized transaction verification method
KR101118424B1 (en) System for Processing Automatic Renewal with Certificate of Attestation

Legal Events

Date Code Title Description
A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20050606

A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20050606

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20080314

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20080507

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

Free format text: JAPANESE INTERMEDIATE CODE: A01

Effective date: 20080930

A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20081013

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

Free format text: PAYMENT UNTIL: 20111031

Year of fee payment: 3

LAPS Cancellation because of no payment of annual fees