JP5036406B2 - コンテンツデータ管理システム及び方法 - Google Patents

コンテンツデータ管理システム及び方法 Download PDF

Info

Publication number
JP5036406B2
JP5036406B2 JP2007143396A JP2007143396A JP5036406B2 JP 5036406 B2 JP5036406 B2 JP 5036406B2 JP 2007143396 A JP2007143396 A JP 2007143396A JP 2007143396 A JP2007143396 A JP 2007143396A JP 5036406 B2 JP5036406 B2 JP 5036406B2
Authority
JP
Japan
Prior art keywords
usage pass
data
transfer
primal
module
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Expired - Fee Related
Application number
JP2007143396A
Other languages
English (en)
Other versions
JP2008299494A (ja
Inventor
達哉 平井
Original Assignee
エイチジーエスティーネザーランドビーブイ
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 エイチジーエスティーネザーランドビーブイ filed Critical エイチジーエスティーネザーランドビーブイ
Priority to JP2007143396A priority Critical patent/JP5036406B2/ja
Priority to EP08005858A priority patent/EP1998268A1/en
Priority to CN2008100955708A priority patent/CN101315796B/zh
Priority to US12/156,209 priority patent/US8195960B2/en
Publication of JP2008299494A publication Critical patent/JP2008299494A/ja
Application granted granted Critical
Publication of JP5036406B2 publication Critical patent/JP5036406B2/ja
Expired - Fee Related legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/10—Protecting distributed programs or content, e.g. vending or licensing of copyrighted material ; Digital rights management [DRM]

Description

本発明は、コンテンツデータ管理システム及び方法に係り、より詳しく言えば、暗号化されたコンテンツデータを一方の装置から他方の装置へ転送する場合に、その可否を判断するための情報を記憶装置内に記録及び保持する方法、コンテンツデータ及び制御情報を転送元装置から転送先装置へ転送するためのプロトコルに関するものである。
音楽データや画像データ等のコンテンツデータに著作権が存在する場合、著作権保護のための適切な方策が取られていないと、著作者の権利が侵害される恐れがある。一方、著作権保護の目的を最優先し、コンテンツデータの流通を阻害してしまうと、著作物の複製に際して著作権料を徴収することが可能な著作権者にとっても、かえって不利益となる。
著作権保護の対象となるコンテンツデータの配信は、主にディジタル通信網や、放送波などを介して行なわれる。これらのデータを利用者が利用する際は、一度何らかの記憶媒体に記録した後、再生装置で再生する場合が多い。現状、容量が大きくアクセス性能が高い制御機能付きの記憶装置として磁気ディスク装置が知られている。磁気ディスク装置は、記録再生装置に固定的に内蔵されているものがほとんどで、磁気ディスク装置に記録されたデータを他の再生装置で利用できるようなものは未だ知られていない。しかし、利便性の面から、今後は可搬型の記憶装置の利用が進む可能性がある。一方で、容量は磁気ディスク装置に比べ少ないが、著作権保護機能を伴った可搬型の記憶装置としてメモリカードが知られている。
データを再生する装置としては、このようなデータの配信を受ける時に用いた記録再生装置や、可搬型の専用の再生装置が使用される。
可搬型の記憶装置を接続できる記録再生装置において、記憶装置に記録されたデータの著作権を保護するためには、記憶装置に記録されたデータを、著作権者が主張する条件の範囲を超えて再生できないように、記録再生装置及び記憶装置にセキュリティ対策を施すことが重要である。セキュリティ対策を機器に施す際には、その装置の内部及び外部から自由にアクセス可能な領域で行なわれるデータの授受に関しては、データの授受が行われる装置の間で認証処理を行ったり、データ自体に暗号化処理等を施したりして、平文で自由にデータへのアクセスが行われることがないようにする必要がある。一方で、このような認証処理や暗号化処理が厳重になるほど、利用者がデータ利用要求を発してから、実際に利用が出来るようになるまでに多くの処理が必要となり、結果としてデータの再生を円滑に行うことができない事態が生じる可能性がある。
例えば、特許文献１及び２には、利用目的のディジタルデータを暗号化する一方で、それを復号するための鍵及び復号した際の利用条件を、不正に取得，改竄などができないようにすることで、著作権を保護することが提案されている。また、特許文献３には、記憶装置とホスト装置との間で秘匿すべきデータを暗号化して入出力するときの耐タンパ性を向上させるために、ホスト装置から送られる複数の暗号入出力処理を複数の手順に分割して、並行して処理する記憶装置に関する技術が開示されている。
ＷＯ０１/０１３３５８公報 ＷＯ０１/０４３３３９公報 特開２００４−３０２７０１公報
上記特許文献は、いずれもディジタルデータを暗号化し、そしてそれを復号するための鍵と利用条件を二つの機器間で転送するための処理に関して記載したものである。しかし、コンテンツは暗号化されていたとしても、それが記録されている機器から他の機器への無尽蔵な転送や複製は、実行できないようにしたいという要望も出ている。
本発明の目的は、正当な装置の間で、コンテンツデータを復号するための鍵及びデータの利用条件を含む制御情報を安全に転送することができ、暗号化されたデータが、標準の命令で読み出し可能な領域に記録されているコンテンツデータの無尽蔵な出力を制限することにある。
本発明に係るコンテンツデータ管理システムは、好ましくは、記憶装置の記憶領域に記憶された、暗号化されたコンテンツデータを転送するコンテンツデータ管理システムであって、記憶領域は、外部からアドレス指定によりアクセス可能であって、コンテンツデータの出力を制御する制御情報及びエントリ識別情報を記憶するアクセス可能領域と、認証条件に充足した所定の場合のみ外部からアクセス可能であって、エントリ識別情報とコンテンツを識別するコンテンツ識別子のフィールドから構成されるエントリを有する隠し領域を有し、制御情報は、コンテンツデータを、外部の装置に復号可能な情報があった場合に、所定のプロトコルに従って、該外部の装置に対しその出力を許可する第１のモードと、制限なしでその出力を許可する第２のモード、を制御する情報を含むコンテンツデータ管理システムとして構成される。
より好ましい例としては、本発明は、記憶装置（第2の装置）と、記憶装置から出力されたコンテンツデータを利用する利用装置（第1の装置）との間で相互に正当性の認証処理を行い、認証処理の結果、正当な場合に第1及び第2の装置で鍵データ（共有鍵データ）を共有し、処理部は、共通鍵データを用いて第1及び第2の装置間で転送されるデータを検証して、隠し領域に記録されたコンテンツ識別子に関するエントリがあるかを確認し、
第２の装置は読み出し命令を受信し、アクセス可能領域に記録された制御情報の前記第1モードか又は第2モードかを確認して、読み出し命令が通常命令であった場合は処理は中断し、読み出し命令が特殊命令であった場合は、共有鍵データからハッシュ値を計算し、ハッシュ値を、制御情報、コンテンツ識別子、読み出し予定のコンテンツデータにを連結し、出力し、
第１の装置は、書き込み命令を受信し、受信したデータに含まれているハッシュ値を検証して成功した場合、コンテンツ識別子を含むエントリを確認して、コンテンツデータを記録するセクタに、エントリ識別情報をコンテンツ識別子と関連させて記録するコンテンツデータ管理システムとして構成される。
また、好ましくは、認証処理の結果、正当な場合に第1及び第2の装置で２つのセッション鍵を共有し、
セッション鍵及び前記エントリ識別情報及び前記コンテンツ識別子を少なくとも含む、マスクされたUsage Pss(Masked Usage Pass)及び共有したセッション鍵からハッシュデータを生成し、ハッシュデータをMasked Usage Passに連結して、転送元の第１又は第２の装置に送信し、
転送元の第1又は第２の装置では、受信したデータを検証して、Masked Usage Passに含まれるコンテンツ識別子を用いて、前記エントリ識別情報とコンテンツ識別子の関係を確認するコンテンツデータ管理システムとして構成される。
本発明はまた、上記処理動作を行うコンテンツデータ管理方法としても把握される。
本発明によれば、正当な装置の間で、複数のデータを復号するための鍵及びデータの利用条件を含む制御情報を安全に転送することができ、暗号化されたデータが、標準の命令で読み出し可能な領域に記録されているコンテンツデータの、無尽蔵な出力を制限することが可能である。
本発明は、以下のような好ましい例において実施される。
本発明は、保護が必要なデータは暗号化されること、及び、該データを復号するために必要な鍵データと、復号が許容される条件は1つにまとめられ、そのデータは、記憶装置内の記憶領域のうち、利用者が自由にアクセスすることができない領域に記録されることを前提とする。該鍵データと復号が許容される条件を一つにまとめたものを、以下の例ではユーセジパス（Usage Pass）と呼ぶ。
本発明は、ある記憶装置に記録されている、復号のためには適切なUsage Passが必要なデータを、他の記憶装置に複製する場合に、それの可否を判断するための方法、及びそれを判断するための情報を記録するための方法を開示するものである。本発明の詳細を述べる前に、記憶装置間でUsage Passを転送するための方法について説明する。
Usage Passを一方の記憶装置から他の記憶装置へ転送する方法は、2種類ある。その1つは、Usage Passの転送方向が一意に決まるUT（Unidirectional Transfer mode）モードであり、他の1つは双方向にUsage Passを転送することができるBT（Bidirectional Transfer mode）モードである。好ましい例として、このUsage Passの特徴的な転送方法を、２つの機器、例えば記録再生装置と記憶装置の間の転送に適用した場合について述べる。
記録再生装置と記憶装置の間でUsage Pass転送を行なうためには、初めに、２つのモードのうち、いずれのモードでUsage Pass転送を実行するか、記録再生装置内の処理部（以下の例では、ホストモジュール（Host Modules）という）が選択し、それぞれの装置におけるUsage Pass送信あるいは受信処理を行うモジュールに、選択したモードを通知する処理を行う。以下では、UTモードがUsage Pass送信あるいは受信処理を行うモジュールに設定された場合について、先ず説明する。
UTモードが設定されると、Usage Passを最終的に受信するモジュールが、自身に埋め込まれているDevice Class証明書を、Usage Passを送信するモジュールへ送信する。Device Class証明書には、Device Class公開鍵が含まれる。尚、UTモードでは、Usage Passを送信するモジュールを含む機器をPrimal Device、受信するモジュールを含む機器をInceptive Deviceと呼ぶ。その意味で、該Device Class証明書をInceptive Device Class証明書、該Device Class公開鍵をInceptive Device Class公開鍵と呼ぶ。
Primal Deviceでは、受信した証明書の正当性を検証し、検証の結果、受信した証明書の正当性が確認されると、一時的な共通鍵暗号化のための鍵であるPrimal Challenge鍵を生成する。続いて、受信したDevice Class公開鍵を用いてPrimal Challenge鍵を暗号化し、生成された暗号化データにPrimal Device Class公開鍵を含むPrimal Device Class証明書を連結し、Inceptive Deviceに送信する。
Inceptive Deviceでは、受信した該データを、自身のDevice Class秘密鍵を用いて復号し、Primal Challenge鍵を取得する。続いてInceptive Deviceは、一時的な共通鍵暗号化のための鍵である0次Inceptive セッション鍵を生成する。この鍵の生成を終えると、自身に埋め込まれているInceptive Device公開鍵と連結し、受信したPrimal Device Class鍵で暗号化する。更に、得られたデータに対し、自身に記録されている失効Device Classリスト（Inceptive RDCL）を連結し、受信したPrimal Challenge鍵で暗号化する。以上の処理を終了すると、得られたデータをPrimal Deviceへ送信する。
Primal Deviceは、受信したデータをPrimal Challenge鍵で復号し、その結果からInceptive RDCLを取り出す。RDCLには、該データの発行日情報が含まれているので、Inceptive RDCLの発行日情報と、自身に記録されているRDCL（Primal RDCL）の発行日情報とを比較する。その結果、Inceptive RDCLの発行日の方が新しければ、Primal RDCLをInceptive RDCLで上書きする。RDCLの発行日比較を終えると、残りのデータをPrimal Device秘密鍵で復号する。続いて、一時的な共通鍵暗号化のための鍵である0次Primal セッション鍵を生成する。この鍵の生成を終えると、先に受信した0次Inceptive セッション鍵で暗号化する。ここで、先に行ったRDCLの発行日情報の比較結果において、Primal RDCLの発行日の方が新しいことが判明した場合は、先に暗号化したデータに、Primal RDCLを連結する。得られたデータは、先に受信したInceptive Device公開鍵で暗号化する。暗号化を終えると、該データをInceptive Deviceへ送信する。
Inceptive Deviceは、受信したデータをInceptive Device秘密鍵で復号する。この復号結果にPrimal RDCLが含まれていた場合は、Inceptive RDCLをPrimal RDCLで上書きする。続いて、残りのデータを0次Inceptive セッション鍵で復号し、0次Primal セッション鍵を得る。
以上が、UTモードにおける認証処理である。これをUT Connection Stageと呼ぶ。UT Connection Stageを完了すると、0次Primal セッション鍵、0次Inceptive セッション鍵、Inceptive Device公開鍵による暗号化と同秘密鍵による復号化の過程で得られる共有Inceptive Device鍵が共有される。
認証処理を終えると、Usage Pass転送を実行することができる。UTモードにおけるUsage Pass転送は、次のように行われる。尚、UTモードにおけるUsage Pass転送は、Primal DeviceからInceptive Deviceへのみ行われる。
まず、Primal Deviceにおいて、目的のUsage Passを、Usage Pass転送用モジュールに準備する。続いて、ホストモジュールは目的のUsage Passを識別するための識別子（UPID）をInceptive Deviceへ送る。
Inceptive Deviceは、Usage Passを暗号化するためのn次Inceptive セッション鍵を生成し、UPIDと共に、Inceptive Transaction Logと呼ばれるログに記録する。ログには、転送処理段階（RP）も記録する。ログは、Usage Pass転送処理が正常に完了しなかった場合に、元の状態にUsage Passを復旧するために用いられるものである。n次Inceptive セッション鍵の生成を終えると、1つ前のUsage Pass転送時に生成したInceptive セッション鍵（n-1次Inceptive セッション鍵）と0次Primal セッション鍵で暗号化し、Primal Deviceへ送信する。
Primal Deviceは、受信したデータを0次Primal セッション鍵及びn-1次Inceptive セッション鍵で復号する。そして、転送対象Usage PassのUPID、Inceptive Device Class証明書に含まれる一部のパラメータ、Connection Stageにおいて受信したInceptive Device公開鍵、復号結果得られたn次Inceptive セッション鍵、転送処理段階（SP）、転送対象Usage Passに含まれるデータの復号可能条件、Usage Passが記録されていたアドレスを、Primal Transaction Logへ記録する。
続いて、Usage Pass送信用モジュールに準備されたUsage Passから、実際に送信するUsage Passを生成後、該Usage Passに利用目的（複製、移動、再生のいずれか）を示すパラメータやChecksumを連結し、n次Inceptive セッション鍵と共有Inceptive Device鍵で暗号化する。暗号化を終えると、Primal Transaction Logにおける転送処理段階要素をSCに更新し、そのデータをInceptive Deviceへ送信する。
Inceptive Deviceは、受信したデータを共有Inceptive Device鍵及び0次Inceptive セッション鍵で復号する。そして、Inceptive Transaction Logにおける転送処理段階要素をRCに更新し、またUsage Passの記録先アドレスをInceptive Transaction Logに記録し、該データをUsage Pass記憶領域へ記録する。
以上が、UTモードにおけるUsage Pass転送処理である。これをUT Transfer Stageと呼ぶ。以上に説明したように、UTモードではUsage Passの転送方向は、Primal DeviceからInceptive Deviceに固定されている。
Usage Passの転送処理を実行中に、記録再生装置に電源供給停止等の異常が発生して、Usage Pass転送元及びUsage Pass転送先双方からUsage Passが失われてしまった場合、以下の処理を行うことで、Usage Passを復旧することができる。
異常時には、UT Connection Stageにおいて共有された0次Primal セッション鍵、0次Inceptive セッション鍵、共有Device鍵は、記録再生装置及び記憶装置から失われてしまうので、新たにこれらの鍵を共有しなければならない。ただし、UT Connection Stageを実行する必要はなく、以下に記す処理を実行すれば良い。
初めに、Hostが、復旧対象のUsage PassのUPIDを、Primal Deviceに送信する。Primal Deviceでは、UPIDを用いて、Primal Transaction Logを検索する。その結果、UPIDを含むPrimal Transaction Logが見つかると、新しい0次Primal セッション鍵を生成する。そして、生成した該セッション鍵を、見つけられたPrimal Transaction Logに記録されていたセッション鍵及びInceptive Device公開鍵で暗号化し、Inceptive Deviceへ送信する。
Inceptive Deviceは、受信したデータを復号し、新しい0次Primal セッション鍵及び共有Devce鍵を得る。
以上が、UTモードにおける再認証処理である。これを、UT Reconnection Stageと呼ぶ。UT Reconnection Stageを完了すると、新しい0次Primal セッション鍵、Inceptive Device公開鍵による暗号化と同秘密鍵による復号化の過程で得られる新しい共有Inceptive Device鍵が共有される。
UT Reconnection Stageを終えると、Primal Deviceにおいて、以下のようにしてUsage Passの復旧処理が行われる。
ホストモジュールが、復旧対象のUsage PassのUPIDを、Inceptive Deviceに送信する。Inceptive Deviceでは、UPIDを用いて、Inceptive Transaction Logを検索する。その結果、UPIDを含むInceptive Transaction Logが見つかると、Transaction Logに記録されている処理段階情報とUsage Passの存在状態情報を連結し、Primal Deviceへ送信する。この時送信されるデータには、データ、0次Primal セッション鍵、Inceptive Transaction Logに記録されていたInceptive セッション鍵から計算されたHash値も連結される。
Primal Deviceは、受信したHash値を検証し、受信したデータに改竄が行われていないことを確認する。この検証を終えると、受信したUPIDを含むPrimal Transaction Logを検索する。Logが見出されると、Logに記録されている転送前の復号可能条件を、現在存在しているUsage Passに上書きする。
以上が、UTモードにおけるUsage Passの復旧処理である。これを、UT Recovery Stageと呼ぶ。このStageを完了すると、Primal Deviceには、送信を行う前のUsage Passが存在するようになる。
次に、BTモードがUsage Pass送信あるいは受信処理を行うモジュールに設定された場合について、説明する。
BTモードでは、Usage Passを転送する方向が固定されておらず、Primal DeviceとInceptive Deviceの双方が、Usage Passの送受信を実行できる。BTモードの下で、記録再生装置にあって相互認証処理やUsage Passの送受信処理を実行するモジュールをPrimal Device、記憶装置にあって相互認証処理やUsage Passの送受信処理を実行するモジュールをInceptive Deviceと呼ぶ。Device Class証明書をInceptive Device Class証明書、Device Class公開鍵をInceptive Device Class公開鍵と呼ぶ。
Primal Deviceでは、受信した証明書の正当性を検証し、検証の結果受信した証明書の正当性が確認されると、一時的な共通鍵暗号化のための鍵であるPrimal Challenge鍵を生成する。続いて、受信したDevice Class公開鍵を用いてPrimal Challenge鍵を暗号化し、生成された暗号化データにPrimal Device Class公開鍵を含むPrimal Device Class証明書を連結し、Inceptive Deviceに送信する。
Inceptive Deviceでは、受信した該データを、自身のDevice Class秘密鍵を用いて復号し、Primal Challenge鍵を取得する。
続いてInceptive Deviceは、一時的な共通鍵暗号化のための鍵であるInceptive セッション鍵を生成する。この鍵の生成を終えると、自身に埋め込まれているInceptive Device公開鍵と連結し、受信したPrimal Device Class鍵で暗号化する。更に、得られたデータ（即ち、Primal Device Class鍵で暗号化されたデータ）に対し、自身に記録されている失効Device Classリスト（Inceptive RDCL）を連結し、受信したPrimal Challenge鍵で暗号化する。以上の処理を終了すると、得られたデータをPrimal Deviceへ送信する。
Primal Deviceは、受信したデータ（即ち、暗号化されたデータ）をPrimal Challenge鍵で復号し、その結果からInceptive RDCLを取り出す。RDCLには、データの発行日情報が含まれているので、Inceptive RDCLの発行日情報と、自身に記録されているRDCL（Primal RDCL）の発行日情報とを比較する。その結果、Inceptive RDCLの発行日の方が新しければ、Primal RDCLをInceptive RDCLで上書きする。RDCLの発行日比較を終えると、残りのデータをPrimal Device秘密鍵で復号する。続いて、一時的な共通鍵暗号化のための鍵である0次Primal セッション鍵を生成する。該鍵の生成を終えると、先に受信したInceptive Device公開鍵で暗号化する。ここで、先に行ったRDCLの発行日情報の比較結果において、Primal RDCLの発行日の方が新しいことが判明した場合は、先に暗号化したデータに、Primal RDCLを連結する。得られたデータは、先に受信したInceptive Challenge鍵で暗号化する。暗号化を終えると、データをInceptive Deviceへ送信する。
Inceptive Deviceは、受信したデータをInceptive Challenge鍵で復号する。この復号結果にPrimal RDCLが含まれていた場合は、Inceptive RDCLをPrimal RDCLで上書きする。続いて、残りのデータをPrimal Device公開鍵で復号し、0次Primal セッション鍵を得る。
Primal Deviceは、受信したデータをPrimal Device秘密鍵及び0次Primal セッション鍵で復号し、0次Inceptive セッション鍵を得る。続いて、Inceptive Device公開鍵、0次Inceptive セッション鍵、0次Primal セッション鍵、Inceptive Device Class証明書に含まれる一部のパラメータを、Primal Connection Logに記録する。
以上が、BTモードにおける認証処理である。これをBT Connection Stageと呼ぶ。BT Connection Stageを完了すると、0次Primal セッション鍵、0次Inceptive セッション鍵、Primal Device公開鍵による暗号化と同秘密鍵による復号化の過程で得られる共有Primal Device鍵、及びInceptive Device公開鍵による暗号化と同秘密鍵による復号化の過程で得られる共有Inceptive Device鍵が共有される。
認証処理を終えると、Usage Pass転送を実行することができる。初めに、Primal DeviceからInceptive DeviceへのUsage Pass転送について説明する。
まず、Primal Deviceにおいて、目的のUsage Passを、Usage Pass転送用モジュールに準備する。
続いて、Inceptive Deviceは、Usage Passを暗号化するためのn次Inceptive セッション鍵を生成する。この鍵の生成を終えると、1つ前のPrimal DeviceからInceptive DeviceへのUsage Pass転送時に生成したInceptive セッション鍵（n-1次Inceptive セッション鍵）と、その時点で最新のPrimal セッション鍵で暗号化し、Primal Deviceへ送信する。
Primal Deviceは、受信したデータをその時点で最新のPrimal セッション鍵及びn-1次Inceptive セッション鍵で復号する。そして、転送対象Usage PassのUPID、転送における自身の役割（転送元）、送信予定のUsage Passを、Transaction Logへ記録する。尚、BTモードでは、Transaction Logの記録は、Primal Deviceのみが行う。
続いて、Usage Pass送信用モジュールに準備されたUsage Passから、実際に送信するUsage Passを生成する。そして、Inceptive DeviceにおけるUsage Passの記録先アドレスをTransaction Logに記録した後、Usage Passに利用目的（複製、移動、再生のいずれか）を示すパラメータやChecksumを連結し、n次Inceptive セッション鍵と共有Inceptive Device鍵で暗号化する。暗号化を終えると、データをInceptive Deviceへ送信する。
Inceptive Deviceは、受信したデータを共有Inceptive Device鍵及びn次Inceptive セッション鍵で復号する。そして、該データをInceptive Device内のUsage Pass記憶領域へ記録する。
以上が、BTモードにおけるPrimal DeviceからInceptive DeviceへのUsage Pass転送処理である。これをBT PI Transfer Stageと呼ぶ。
初めに、Primal DeviceからInceptive DeviceへのUsage Pass転送について説明する。
まず、Inceptive Deviceにおいて、目的のUsage Passを、Usage Pass転送用モジュールに準備する。
続いてInceptive Deviceは、Usage Passに対し、データ暗号鍵部分を０で置き換え、Usage Passの状態情報を連結した（該データをMasked Usage Passと呼ぶ）後、データに最新のPrimal セッション鍵とInceptive セッション鍵連結してHash値計算する。そして、得られたHash値を、Masked Usage Passに連結し、Primal Deviceへ送信する。
Primal Deviceは、受信したHash値を検証し、受信したデータに改竄が行われていないことを確認する。この検証を終えると、受信したUsage PassのUPID、データの復号可能条件、Inceptive DeviceにおいてUsage Passが記録されているアドレスを、Transaction Logに記録する。続いて、m次Primal セッション鍵を生成し、1つ前のInceptive DeviceからPrimal DeviceへのUsage Pass転送で生成されたPrimal セッション鍵（m-1次Primal セッション鍵）と、その時点で最新のInceptive セッション鍵で暗号化し、Inceptive Deviceへ送信する。
Inceptive Deviceは、受信したデータをその時点で最新のInceptive セッション鍵及びm-1次Primal セッション鍵で復号する。続いて、Usage Pass送信用モジュールに準備されたUsage Passから、実際に送信するUsage Passを生成する。そして、Usage Passに利用目的（複製、移動、再生のいずれか）を示すパラメータやChecksumを連結し、m次Inceptive セッション鍵と共有Primal Device鍵で暗号化する。該暗号化を終えると、該データをPrimal Deviceへ送信する。
Primal Deviceは、受信したデータを共有Primal Device鍵及びm次Primal セッション鍵で復号する。
以上が、BTモードにおけるInceptive DeviceからPrimal DeviceへのUsage Pass転送処理である。これをBT IP Transfer Stageと呼ぶ。
UTモードと同様に、記録再生装置に異常が発生して、Usage Pass転送元及びUsage Pass転送先双方からUsage Passが失われてしまった場合、以下の処理を行うことで、Usage Passを復旧することができる。BTモードによる再認証処理は、UTモードとは若干異なり、過去にBT PI Transfer StageやBT IP Transfer Stageが実行されている必要はなく、BT Connection Stageのみが完了していれば良い。
異常時には、BT Connection Stageにおいて共有された0次Primal セッション鍵、0次Inceptive セッション鍵、共有Primal Device鍵、共有Inceptive Device鍵は、記録再生装置及び記憶装置から失われてしまうので、新たにこれらの鍵を共有しなければならない。ただし、BT Connection Stageを実行する必要はなく、以下に記す処理を実行すれば良い。
初めに、Primal Deviceにおいて、新たな0次Primal セッション鍵を生成し、Primal Connection Logに記録されているInceptive セッション鍵とInceptive Device公開鍵で、生成した該鍵を暗号化する。そして、得られたデータをInceptive Deviceへ送信する。
Inceptive Deviceは、受信したデータをInceptive Connection Logに記録されているInceptive Device秘密鍵及びInceptive セッション鍵で復号する。そして、新たな0次Inceptive セッション鍵を生成し、Inceptive Connection Logに記録されているPrimal セッション鍵とPrimal Device公開鍵で、生成した該鍵を暗号化する。続いて、受信した0次Primal セッション鍵及び生成した0次Inceptive セッション鍵を、Inceptive Connection Logに上書き記録し、先に暗号化したデータを、Primal Deviceへ送信する。
Primal Deviceは、受信したデータをPrimal Device秘密鍵及びInceptive Connection Logに記録されている0次Primal セッション鍵で復号する。そして、得られた新しい0次Inceptive セッション鍵と、先に生成した0次Primal セッション鍵を、Primal Connection Logに上書き記録する。
以上が、BTモードにおける再認証処理である。これを、BT Reconnection Stageと呼ぶ。BT Reconnection Stageを完了すると、新しい0次Primal セッション鍵、0次Inceptive セッション鍵、Primal Device公開鍵による暗号化と同秘密鍵による復号化の過程で得られる新しい共有Primal Device鍵Primal Device公開鍵による暗号化と同秘密鍵による復号化の過程で得られる新しい共有Inceptive Device鍵が共有される。
BT Connection StageやBT Reconnection Stageが完了すると、過去に転送処理を完了できなかったUsage Passについて、以下に述べる方法により、転送処理の前の状態に復旧することができる。初めにBT PI Transfer Stageに対する復旧処理について、続いてBT IP Transfer Stageに対する復旧処理について説明する。
BT PI Transfer Stageで転送されたUsage Passを転送処理実行前の状態に戻す処理を行うにあたり、まず初めにHostが復旧対象のUsage PassのUPIDを、Primal Deviceに送信する。
Primal Deviceは、このUPIDを用いて、Primal Transaction Logを検索する。その結果、該UPIDを含むPrimal Transaction Logが見つかると、Logに記録されているInceptive DeviceにおけるUsage Passの記録先アドレス（受信したUsage Passを記録する予定だったアドレス）をInceptive Deviceへ送信する。
Inceptive Deviceは、受信したアドレスでアクセスされるUsage Pass記憶領域へアクセスし、Usage Passの記録状態を調べる。そして、その結果をUsage Pass Statusに設定する。次に、UPID、検索されたUsage Passの復号可能条件、生成されたUsage Pass Status、Usage Passの記録先アドレスを連結し、Primal Deviceへ送信する。この時送信されるデータには、該データ、m次Primal セッション鍵、n次Inceptive セッション鍵から計算されたHash値も連結される。
Primal Deviceは、受信したHash値を検証し、受信したデータに改竄が行われていないこと、及びInceptive Deviceに先に転送したUsage Passが存在しないことを確認する。検証を終えると、受信したUPIDを含むPrimal Transaction Logを検索する。Logが見出されると、該Logに記録されている転送前の復号可能条件を、現在Usage Pass送信用モジュールに用意されているUsage Passに上書きする。
以上が、BTモードにおけるBT PI Transfer Stageに対するUsage Passの復旧処理である。これを、BT PI Recovery Stageと呼ぶ。このStageを完了すると、Primal Deviceには、送信を行う前のUsage Passが存在するようになる。
次に、BT IP Transfer Stageに対するUsage Passの復旧処理について説明する。
BT PI Transfer Stageで転送されたUsage Passを転送処理実行前の状態に戻す処理を行うにあたり、まず初めにホストモジュールが復旧対象のUsage PassのUPIDを、Primal Deviceに送信する。
Primal Deviceは、このUPIDを用いて、Primal Transaction Logを検索する。その結果、このUPIDを含むPrimal Transaction Logが見つかると、Logに記録されているInceptive DeviceにおけるUsage Passの記録先アドレス（転送対象のUsage Passが元来記録されていた領域を指し示すアドレス）をInceptive Deviceへ送信する。
Inceptive Deviceは、受信したアドレスでアクセスされるUsage Pass記憶領域へアクセスし、Usage Passの記録状態を調べる。そして、その結果をUsage Pass Statusに設定する。次に、UPID、検索されたUsage Passの復号可能条件、生成されたUsage Pass Status、Usage Passの記録先アドレスを連結し、Primal Deviceへ送信する。この時送信されるデータには、該データ、m次Primal セッション鍵、n-1次Inceptive セッション鍵から計算されたHash値も連結される。尚、この時点で共有されている最新のInceptive セッション鍵は、n-1次のものとする。
Primal Deviceは、受信したHash値を検証し、受信したデータに改竄が行われていないこと、及びInceptive Deviceに先に転送したUsage Passが、過去の転送（送信）処理によって、変化してしまったかどうかを確認する。
上記検証に並行して、Inceptive Deviceでは、n次Inceptive セッション鍵の生成を行う。この鍵の生成を終えると、n-1次Inceptive セッション鍵及びm次Primal セッション鍵で暗号化し、Primal Deviceへ送信する。
Primal Deviceでは、データを受信後、先に述べた検証処理によって、Usage Passが送信処理を実行することによって変化してしまっていることが確認されると、以下に記すUsage Passの復旧処理を実行する。まず、受信したデータを、m次Primal セッション鍵及びn-1次Inceptive セッション鍵で復号する。続いて、先に検索の結果見つけられたTransaction Logに記録されている復号可能条件を、Usage PassのUPIDに連結し、n次Inceptive セッション鍵及び共有Inceptive Device鍵で暗号化する。暗号化を終えると、そのデータをInceptive Deviceへ送信する。
Inceptive Deviceは、受信したデータを、共有Inceptive Device鍵及びn次Inceptive セッション鍵で復号する。そして、復号結果に含まれるUPIDが、復旧対象Usage PassのUPIDと一致しているか確認する。UPIDの一致が確認されると、復号結果に含まれる復号可能条件を、Inceptive Device中に存在するUsage Passに上書き記録する。
以上が、BTモードにおけるBT IP Transfer Stageに対するUsage Passの復旧処理である。これを、BT IP Recovery Stageと呼ぶ。このStageを完了すると、Inceptive Deviceには、送信を行う前のUsage Passが存在するようになる。
検証を終えると、受信したUPIDを含むPrimal Transaction Logを検索する。Logが見出されると、そのLogに記録されている転送前の復号可能条件を、現在Usage Pass送信用モジュールに用意されているUsage Passに上書きする。
以上が、BTモードにおけるBT PI Transfer Stageに対するUsage Passの復旧処理である。これを、BT PI Recovery Stageと呼ぶ。このStageを完了すると、Primal Deviceには、送信を行う前のUsage Passが存在するようになる。
以下、図面を参照して本発明の実施例について説明する。
[システム構成]
まず、図１及び図２を用いて、一実施例におけるデータ記録再生装置及びそれに接続可能な記憶装置を含むシステムの全体構成について説明する。
この実施例は、放送されたディジタル映像データや、配信サーバ（Distribution Server）から配信されたディジタルデータ、また他の機器と接続したディジタル信号線を介して送信されたディジタルデータを脱着可能な記憶装置に記録し、また記憶装置に記憶されたディジタルデータを、記録再生装置のディスプレイ装置やスピーカーなどで再生する記録再生システムに適用した例について説明する。以下では、ディジタルデータ記録再生装置を単に記録再生装置といい、記録再生装置が受信する映像や音楽、テキストなどのディジタルデータを、コンテンツデータという。ここで、コンテンツデータを記録する脱着可能な記憶装置は、例えば、磁気ディスク装置や半導体メモリデバイスなどであり、何れも本発明に特徴的な制御機能を有する。以下では、記憶装置として磁気ディスク装置を例に説明するが、これに限るものではない、以下に説明するような本発明に特徴的な機能を有するものであれば、磁気ディスク装置以外の他の周知な記憶装置にも適用できる。
著作権の保護が求められるコンテンツデータは、放送波を介してアンテナ131で受信したり、配信サーバ150から配信されたものをネットワークインタフェース （Network Interface）100を介して受信したりすることによって、記録再生装置112に取り込まれる。配信されるコンテンツデータは、放送波発信元130や配信サーバ150において、所定の暗号方式により暗号化されている。その暗号方式は、それぞれのコンテンツ保護仕様によって、独自に規定されていてよい。その際、コンテンツデータを復号するための鍵データ（以下ではこれをコンテンツ鍵と呼ぶ）と、コンテンツデータの利用条件も、別途、記録再生装置112に送信される。これらのコンテンツデータを復号するための情報を、以下ではコンテンツデータの復号制御情報と呼ぶ。この復号制御情報は、コンテンツデータの送信元と同一の送信元から送信される場合もあるし、他の送信元から送信される場合もある。
記録再生装置112は、脱着可能な記憶装置、例えば磁気ディスク装置125、126を接続することができる構成を有する。磁気ディスク装置125及び126には、放送波に乗って送信されたり、配信サーバ 150から送信されたりした暗号化されたコンテンツデータ及びコンテンツデータの復号制御情報が、記録モジュール（Recording Module）102及び保護情報転送モジュール（Protected Information Transmit Module）104を介して記録される。また、再生モジュール（Playback Module）103には、脱着可能な磁気ディスク装置125や126から、暗号化されたコンテンツデータや、コンテンツデータの復号制御情報が、保護情報転送モジュール104を介して送信される。コンテンツデータの復号及び再生は、記録再生装置112内の再生モジュール103において行われる。
ところで、コンテンツデータの不正利用を防止するためには、復号制御情報に含まれるコンテンツ鍵が不正に取り出されたり、利用条件が不正に複製されたり、書き換えられたりすることがないようにする必要がある。そのためには、記録再生装置112や脱着可能な磁気ディスク装置125及び126内において復号制御情報の送受信を行ったり、情報を記録したり読み出したりする部分は、高度な対タンパ性を持つように実装することが重要である。更に、本発明の記憶装置は、コンテンツデータは暗号化されていた場合でも、その無尽蔵な複製を行えないようにする機能を有し、またそれを正しく実現するために、暗号化されたデータを記録したり読み出したりする部分も対タンパ性を有するものとする。ここで、復号制御情報の送受信を行ったり情報を記録したり読み出したりする部分を、記録再生装置112ではホストセキュリティマネージャ（Host Security Manager）111、磁気ディスク装置においては、ストレージセキュリティマネージャ（Storage Security Manager）225と呼ぶ。また、磁気ディスク装置内で、媒体200上に記録されているデータの読み出しや書き込みを制御し、データを一時的に保持したりすることができる機能を有する部分を、記憶装置制御部（Storage Controller）と呼ぶ。記憶装置制御部230には、媒体200から読み出されたデータのうち、媒体200上の隠し領域（Hidden area）に記録されているデータを一時的に保持しておいたり、該領域に記録されている特殊なデータを隠し領域に記録したりするために、一時的にデータを記憶しておく記憶装置制御部内一時データ記憶領域（SC Buffer）231が設けられている。隠し領域の定義及び該領域に記録されるデータについては、図28，図29，図30を利用して、後で説明する。尚、ホストセキュリティマネージャ 111内の保護情報領域（Protected Information Storage）101の役割や、ストレージセキュリティマネージャ 225内のUsage Pass転送モジュール（Usage Pass Transfer Module）221、制限記憶コントローラ（制限記憶部 Controller）222、制限記憶部（Qualified Storage）223の具体的な役割については、後に説明する。本発明に係る実施例では、ホストセキュリティマネージャ（Host Security Manger）112及びストレージセキュリティマネージャ225内にあるモジュール間で、復号制御情報を送受信し合うための転送プロトコルに関するものである。尚、ここで、記録再生装置112及び磁気ディスク装置125、126における各モジュール及びセキュリティマネージャ等の機能の実現手段としてはハードウェア又はソフトウェア（プログラム）の何れによって構成されてもよい。
一方で、記録再生装置112の中で、ネットワークとの間のネットワークインタフェース100や、入力デバイスとの間のインタフェースブリッジ部105、磁気ディスク装置との間のインタフェース（Host Interface Unit）106及び107、及びこれらを制御するプロセッサ（PU）108などは、全体として、システム内部を流れるデータの処理や受け渡しを制御する機能を有する。その意味で、以下ではこれらをまとめてホストモジュール（Host Moduless）110と呼ぶ。
[モジュール間での相互認証とUsage Pass転送方式の概略]
放送波に乗せられて送信されるコンテンツデータや、他の媒体に記録されているコンテンツデータは、一般的には独自に規定された方式で暗号化されている。また、データには、その復号制御情報も含まれていることが多い。これらのデータを、アンテナ131やディジタル信号線132を介して記録再生装置112が取り込む場合、記録モジュール102は、規定された方式に従ってコンテンツデータを復号し、また復号制御情報を取り出す。取り出された復号制御情報は、本実施例において定める特定の形式を持った1つのデータにまとめられる。これを、以下ではUsage Passと呼ぶ。Usage Passの具体的な構造については、後に図4を用いて説明する。
記録モジュール 102はUsage Passを生成すると、それを磁気ディスク装置125あるいは126に対して送信する。ただし、本送信が完了するためには、それに先立って、記録モジュール102もしくは保護情報転送モジュール104とUsage Pass転送モジュール221の間では、相互認証が完了しなければならない。認証処理が完了すると、いくつかの鍵データが共有される。そして、転送対象のUsage Passは、共有された鍵を用いて、暗号化された後、記録モジュール102からUsage Pass転送モジュール221に対して送信される。
まず、鍵を共有するまでの認証処理方法と、認証処理によって共有された鍵を用いてUsage Passを暗号化し、転送する処理方法について説明する。その処理方法は、2種類ある。その1つは、2つのモジュール間で相互認証が終了すると、Usage Passの転送方向が一意に確定してしまう方法であり、他の1つは双方向にUsage Passを転送することができる方法である。以下では、前者による相互認証及びUsage Pass転送方式を単一方向転送モード（Unidirectional Transfer mode）（略してUTモード）と呼び、後者による相互認証及びUsage Pass転送方式を双方向転送モード（Bidirectional Transfer mode）（略してBTモード）と呼ぶ。これらのモードを総称して、制限アクセス（Qualified Access）モードと呼ぶ。モジュール間でUsage Passを転送する際、いずれのモードで相互認証及びUsage Pass転送を行うかは、記録再生装置を起動する際、ホストモジュール（Host Modules）110が決定する。
磁気ディスク装置では、Usage Pass転送モジュール 221がUsage Passを受信すると、それを制限記憶コントローラ222へ送信する。制限記憶コントローラは、制限記憶部223を制御するモジュールである。Usage Pass本体は、最終的には制限記憶部223に記録される。尚、配信サーバ150が磁気ディスク装置へUsage Passを送信する場合や、ある磁気ディスク装置から他の磁気ディスク装置へUsage Passを転送する場合は、Usage Passの転送元となるモジュールが、転送先となる磁気ディスク装置内のUsage Pass転送モジュールに対して、本発明で定める方式に従って、直接Usage Passを送信しても良い。この場合、記録再生装置112内のネットワークインタフェース100や記録モジュール102は、データの一方から他方のモジュールへの転送を制御するたけで、相互認証処理やUsage Passの暗号化には直接関係しない。
次に、図2を参照して、磁気ディスク装置の構成について説明する。
磁気ディスク装置には、インタフェース部220を介してデータが入出力される。Usage Passのような保護が必要なデータ以外のデータが外部から入力される場合、コントローラ230を介して、ヘッド部202から磁気ディスク円盤200上に記録される。暗号化されたコンテンツデータも、このフローに従って、磁気ディスク円盤200上に記録される。読み出す場合は、前述を逆にデータが流れる。本発明では、コントローラ230は、コンテンツデータの記録または再生に際して、特殊な制御を行う。コントローラ230の詳細な動作については、図28から図32を用いて、後で説明する。尚、Usage Pass転送モジュール221や制限記憶コントローラ222同様に、コントローラ230はプロセッサ（PU）231からも制御される。
図2では、制限記憶部223は磁気ディスク円盤200とは別に設けられているが、暗号化されたコンテンツデータの読み出しと書き込みとは異なる特殊なアクセス方法でのみアクセスが許容されていて、また本装置を分解等し内部のデータを直接読み出す等を行うことが不可能な構成になっていれば、制限記憶部は磁気ディスク円盤200上に設けても良い。
[システムの鍵およびデータの構成]
図3は、図1及び図2に示した機器において、記録モジュール102、再生モジュール103、及びUsage Pass転送モジュール221の間でUsage Pass転送を実行する際、それを暗号化するために用いられる鍵データ、及び配信するデータ等の一覧を示すものである。
通常、鍵データXが対称暗号用の鍵データである場合は、対象のデータは鍵データXを用いて暗号化されており、その復号も同一の鍵データXを用いて行われる。一方、鍵データXが非対称暗号用の秘密鍵あるいは公開鍵であった場合は、暗号化対象のデータは、Xとは異なるこれらに対応する公開鍵あるいは秘密鍵Yを用いて暗号化されている。Yを用いて暗号化されたデータは、Xを用いて復号される。以下では、非対称暗号用公開鍵データを公開鍵、非対称暗号用秘密鍵データを秘密鍵、対称暗号用鍵データを共通鍵と略す。
データに電子署名が付けられている場合、データを一部に含むデータ集合のハッシュ値が、公開鍵Xに対応する秘密鍵Yで暗号化されていることを意味する。
尚、本明細書中でK_xのように表記されているものは、全ての図ではxは添え字として表現されている。
コンテンツデータの暗号化、復号及び再生処理、Usage Passの暗号化及び復号化、記録モジュール 102、再生モジュール103、磁気ディスク装置125及び126、配信サーバ150の認証に関わる鍵として、以下のものがある。
コンテンツデータを暗号化および復号するための鍵は、コンテンツ鍵K_cである。配信サーバ150、記録モジュール102、再生モジュール103、Usage Pass転送モジュール 221には、それぞれ個別に互いに認証を行うための電子署名付き公開鍵KP_dcがそれぞれ割り当てられる。ただし、ホストセキュリティマネージャ 111を全体として1つの対タンパ性を持つ機能単位として実装する場合、ホストセキュリティマネージャ 111に対して1つのKP_dcを割り当てても良い。
公開鍵KP_dcにより暗号化されたデータは、これに対応する秘密鍵K_dcによって復号可能である。これらの秘密鍵データは、配信サーバ150、記録モジュール102、Usage Pass転送モジュール221、再生モジュール103について、それぞれのある有限個に対して、1つ割り当てられる。有限個という意味は、1つでも複数個でも良いことを意味する。KP_dc及びK_dcを共有する単位をClassと呼ぶ。1つのClassに対しては、Usage Passを転送したり、記録したりする部分が、実装する際に満たさなければならない安全性のレベルや、1つのUsage Pass転送方式が規定される。つまり、あるClassに属する複数のモジュールは、全てがそのClassで規定された安全性のレベルを満たす形で実装されており、また1つの共通したUsage Pass転送方法を実現するための機能を持つ。尚、以下ではこのような機器やモジュールを、総称してDeviceと呼ぶ。
KP_dcは、他の一般情報と連結された後、所定の認証局によって電子署名が与えられ、各デバイスに対する証明書としての役割を果たす。電子署名を与えるための認証局の公開鍵をKP_CA、これに対応する秘密鍵をK_CAと記す。以降では、これらの認証局公開鍵及び認証局秘密鍵と呼ぶ。証明書に記載される一般情報とは、その証明書の発行元や証明書のシリアル番号などである。以降では、KP_dcの正当性を示すための証明書をDevice Class証明書、公開鍵KP_dcをDevice Class公開鍵、鍵で暗号化されたデータを復号するために用いられる秘密鍵をDevice Class秘密鍵と呼ぶ。Device Class証明書やDevice Class秘密鍵は、出荷時に各デバイスに埋め込まれる。
各デバイスに対しては、個別に埋め込まれる公開鍵KP_dと、鍵で暗号化されたデータを復号するための秘密鍵K_dも埋め込まれる。以降では、これらをDevice公開鍵、Device秘密鍵と呼ぶ。Device公開鍵とDevice秘密鍵は、全てのデバイスに異なったものが埋め込まれる。
尚、公開鍵による暗号化の過程では、暗号化に用いられる公開鍵を元にして、1つの共通鍵が生成される。これは、*KP_dのように表される。同様に、秘密鍵による復号化の過程では、復号に用いられる秘密鍵を元にして、1つの共通鍵が生成される。これは、*K_dのように表される。*KP_dと*K_dは、実際には同一の値であり、*KP_dで暗号化されたデータは、*K_dで復号することができる。これらの共通鍵を、それぞれ共有Device公開鍵及び共有Device秘密鍵と呼ぶ。これらの鍵の生成方法については、後に公開鍵暗号化方法に関する説明をする際、更に詳細に説明する。
さらに、図1に示したシステムにおいて、使用される鍵等として以下のものがある。異なる2つのデバイス間でUsage Pass転送を行う度に、Usage Passを暗号化するために、主にUsage Passの転送先において生成される共通鍵K_sn（n ≧0）、及びデバイス間で相互認証処理の最終段階において両デバイスで共有されるK_s0を暗号化するために生成される共通鍵K_chである。K_ch及びK_s0は、デバイス間の相互認証処理において共有される鍵で、Usage Pass転送の際にそれを暗号化するためには利用されない。一方K_sn（n ≧ 1）については、Usage Pass転送を実行する度に、必ずK_snからK_sn+1へ更新されてから利用される。以後、K_chをChallenge鍵、K_sn（n ≧ 0）をセッション（Session）鍵と呼ぶ。特に、nが0の場合のセッション鍵を、0次のセッション鍵と呼ぶ。
各鍵に対しては、[P]もしくは[I]の添え字が与えられる。これは、鍵が、Primal Device及びInceptive Deviceのいずれで生成された（あるいは埋め込まれた）か、を示すものである。ここでPrimal Deviceとは、あるデバイスが他のデバイスとの間で相互認証を行う場合に、相手となるデバイスから送信されたDevice Class証明書の検証を最初の処理で行うもののことである。一方、Inceptive Deviceとは、同様の場合に、自身のDevice Class証明書を相手となるデバイスに送信することを最初の処理で行うもののことである。
以上に説明した鍵を用いて行う暗号化をE(X, Y)と表す。これは、データYを、鍵データXを用いて暗号化することを表す。同様に復号化を、D(X, Y)と表す。これは、データYを、鍵データXを用いて復号することを表す。また、H(X)はデータXのハッシュ値を、X || YはデータXとデータYを連結することを表す。これらの表記法は、UTモード、BTモードいずれの場合にも全て共通のものである。
尚、UTモードではUsage Passの転送方向が一意に確定してしまうと以前に述べたが、その方向は常にPrimal DeviceからInceptive Deviceである。従ってUTモードでは、記録モジュール102は常にPrimal Deviceとなり、再生モジュール 103は常にInceptive Deviceとなる。一方、磁気ディスク装置は、記録モジュールから送信されたUsage Passを記録する場合はInceptive Deviceとなり、コンテンツデータの復号再生などを目的に自身からUsage Passを再生モジュールへ送信する場合は、Primal Deviceとなる。
これに対し、BTモードでは、ホストセキュリティマネージャを有する装置が常にPrimal Deviceとなり、磁気ディスク装置は常にInceptive Deviceとなるが、Usage Passの転送は、Primal DeviceからInceptive DeviceへもInceptive DeviceからPrimal Deviceへも可能である。
[Usage Passの構成]
Usage Passの構造について、図4を用いて説明する。
Usage Passには、自身がどのような種類のモジュールに出力可能なものであるかを示すUsage Pass Format400、それぞれに一意に割り当てられた識別子UPID401、対象コンテンツデータの利用を制限するための条件402及び404、暗号化されたコンテンツデータを解くための鍵データK_c 403、対応するコンテンツデータを特定するための識別子CID405、コンテンツの著作権情報406が含まれる。対象コンテンツデータの利用を制限するための条件には、Usage Passの転送元で内容を解釈しその出力を制御するための制御情報UR_s 4020（Usage Passの転送元には、通常記録モジュールや磁気ディスク装置がなりうる）と、再生モジュール 103がUsage Pass及びコンテンツデータを受信後、モジュールにおけるコンテンツデータの復号処理を制御するための制限情報UR_p 4040とがある。UR_s 4020には、Usage Passが複製された場合の世代情報を表すGeneration Count、自身からUsage Passの複製可能な回数を表すCopy Count、自身のUsage Passを使ってコンテンツデータの復号可能な回数を表すPlay Countなどが含まれる。
[UTモードでのUsage Pass転送が実行可能なUsage Pass転送モジュールの構成]
図5を用いて、UTモードでのUsage Pass転送が実行可能なUsage Pass転送モジュール221の構成について説明する。
Usage Pass転送モジュール530の中には、他のデバイスとの間で相互認証を行う場合に、自身がPrimal Deviceとなって必要な処理を行うための機能を持ったモジュール500、自身がPrimal DeviceとなってUsage Passの転送を行うための機能を持ったモジュール501、自身がInceptive Deviceとなって必要な処理を行うための機能を持ったモジュール502、自身がInceptive DeviceとなってUsage Passの転送を行うための機能を持ったモジュール503、利用者の意思による書き換えが行えないような静的な記憶領域504、Usage Pass転送を実行した際、処理が正常に終了しなかった場合に、対象のUsage Passが転送元デバイス及び転送先デバイスいずれからも失われてしまうことを避けるための、Usage Passの復旧機能を有するモジュール505、及び制限記憶コントローラ222へUsage Passを送信する前に一時的にそれを蓄積しておいたり、制限記憶部から読み出したUsage Passを一時的に蓄積しておいたりするためのUsage Pass Buffer 510が設けられている。認証用モジュール 500及び502、Usage Pass暗号化及び送信用モジュール 501、Usage Pass受信及び復号化モジュール503、Usage Pass復旧用モジュール505などは、必要に応じて、記憶領域504へアクセスする。記憶領域504は、保護情報領域と呼ばれる。
磁気ディスク装置の外部と各モジュールとの間でのデータのやりとりは、Storage Interface Unit 520及びバス540を介して行なわれる。PU521は、図2における231と同じものである。
各モジュールが実際に持っている機能については、図17から図20を用いて相互認証処理及びUsage Pass転送処理を具体的に説明する中で、詳細に説明する。また、保護情報領域 504に記録されるデータの種類等については、図9を用いて後で説明する。
[UTモードでのUsage Pass送信が実行可能な記録再生装置内の記録モジュールの構成]
図6を用いて、UTモードでのUsage Pass送信が実行可能な記録モジュール 102の構成について説明する。尚、UTモードによるUsage Passの転送を行う機能を記録再生装置で実現する場合は、図1における保護情報転送モジュール104は、特に必要ではないため、描かれていない。
UTモードでは、記録モジュールは常にPrimal Deviceとなる。そこで、記録モジュール 625の中には、他のデバイスとの間で相互認証を行う場合に、自身がPrimal Deviceとなって必要な処理を行うための機能を持ったモジュール600、自身がPrimal DeviceとなってUsage Passの送信を行うための機能を持ったモジュール601、Usage Pass送信処理を実行した際、処理が正常に終了しなかった場合に、対象のUsage Passが転送元デバイス及び転送先デバイスいずれからも失われてしまうことを避けるための、Usage Passの復旧機能を有するモジュール605、及び外部からコンテンツデータ及び利用権情報を入手し、コンテンツ鍵を生成し、鍵でコンテンツを暗号化し、鍵を含むUsage Passを生成する機能を有するモジュール606が設けられている。暗号化されたコンテンツは、モジュール606からデータバス640へ、Host Modules 620を介して、磁気ディスク装置へ記録される。
記録モジュールを含むホストセキュリティマネージャ630には、利用者の意思による書き換えが行えないような静的な記憶領域604が設けられており、認証用モジュール600やUsage Pass暗号化及び送信用モジュール601、Usage Pass復旧用モジュール605などは、必要に応じて、記憶領域へアクセスする。記憶領域604は、保護情報領域と呼ばれる。
各モジュールが実際に持っている機能については、図17から図20を用いて相互認証処理及びUsage Pass転送処理を具体的に説明する中で、詳細に説明する。また、保護情報領域504に記録されるデータの種類等については、図8を用いて後で説明する。
UTモードでのUsage Pass受信が実行可能な記録再生装置内の再生モジュールの構成
図7を用いて、UTモードでのUsage Pass受信が実行可能な再生モジュール103の構成について説明する。記録モジュールと同様に、UTモードでUsage Passの転送を行う機能を記録再生装置で実現する場合は、図1における保護情報転送モジュール104は、特に必要ではないため、描かれていない。
UTモードでは、再生モジュールは常にInceptive Deviceとなる。そこで、再生モジュール725の中には、他のデバイスとの間で相互認証を行う場合に、自身がInceptive Deviceとなって必要な処理を行うための機能を持ったモジュール700、自身がInceptive DeviceとなってUsage Passの受信を行うための機能を持ったモジュール703、Usage Pass受信処理を実行した際、処理が正常に終了しなかった場合に、対象のUsage Passが転送元デバイス及び転送先デバイスいずれからも失われてしまうことを避けるための、Usage Passの復旧機能を有するモジュール605、及び受信したUsage Passから、Usage Passに含まれるUR_pに記載されている内容を解釈し、それに従って暗号化されたコンテンツデータを復号する機能を有するモジュール 706が設けられている。この時、暗号化されたコンテンツデータは、Host Modules 720及びデータバス740を介して、モジュール706に送信される。復号されたコンテンツデータは、保護されたデータ通信路等を通る形で、モジュール706から直接再生モジュール外へ出力される。
再生モジュールを含むホストセキュリティマネージャ730には、利用者の意思による書き換えが行えないような静的な記憶領域704が設けられており、認証用モジュール 702や、Usage Pass受信及び復号化用モジュール703、Usage Pass復旧用モジュール 705などは、必要に応じて、この記憶領域をアクセスする。記憶領域704は、保護情報領域と呼ばれる。
各モジュールが実際に持っている機能については、図17から図20を用いて相互認証処理及びUsage Pass転送処理を具体的に説明する中で、詳細に説明する。また、保護情報領域504に記録されるデータの種類等については、図8を用いて後で説明する。
[ホストセキュリティマネージャ内にあるUTモード用保護情報領域の構成]
図8を用いて、記録再生装置におけるUTモード用の保護情報領域の構成を説明する。
記憶領域819は、記録モジュール102がアクセスする領域である。一方、記憶領域839は、再生モジュール103がアクセスする領域である。記憶領域819と839には、同じ種類のデータが保持もしくは記録される。それらは、次の通りである。
801及び821は、Device Class証明書である。Device Class証明書801には、Device Class公開鍵800が、同様にDevice Class証明書821にはDevice Class公開鍵820が含まれる。Device Class証明書は、含まれるDevice Class公開鍵の正当性を証明するものであり、電子署名が含まれる。電子署名部は、認証局秘密鍵K_CAで暗号化されている。
803及び823は認証局公開鍵、804及び824はDevice Class秘密鍵、805及び825はDevice公開鍵、806及び826はDevice秘密鍵である。
以上の証明書及び鍵情報は、初期の実装時に埋め込まれているもので、後で更新されるものではない。
これに対し、802及び822、810、811、830、831は、相互認証処理やUsage Pass転送処理において、更新される情報である。ここで802及び822は、失効したDevice Classのリストである。このリストを、以下ではRDCLと呼ぶ。あるDevice Class公開鍵KP_dcの安全性が失われると、KP_dcを含む証明書の固有番号を、このリストに登録する。他のデバイスから送られたDevice Class証明書の検証を行う際には、電子署名部を用いて証明書に改竄が行われていないことを確認すると共に、証明書の固有番号が、リストに登録されていないかどうかについても確認する。また、810、811、830、831はTransaction Logと呼ばれる記憶領域である。Transaction Logとしては、転送対象Usage PassのUPID、及び認証相手から送信されたDevice Class証明書中に含まれる「受信可能なUsage Pass Formatに関する情報」（記録するのはPrimal Deviceのみ、以下ではこれをType Mapと呼ぶ）。相互認証を実行中の相手のDevice公開鍵（記録するのはInceptive Deviceのみ）、転送過程において生成されるセッション鍵、Session Statusと呼ばれるUsage Pass転送処理の進行状況、転送を実行する前のUR_s（記録するのはPrimal Deviceのみ）、Usage Passが記録されているアドレスあるいは記録先のアドレスが、Usage Pass転送が実行される際に記録される。これらのデータをUsage Pass転送実行時に各段階において記録しておくことで、不慮の事故等により、転送元及び転送先いずれからもUsage Passが失われてしまった場合にも、Usage Passを復旧することができるようになる。これらのデータを記録するタイミングについては、図17から図20を用いて相互認証処理及びUsage Pass転送処理を具体的に説明する中で、詳細に説明する。
ここで、Type Mapについて説明しておく。Type Mapは、前述の通り、「受信可能なUsage Pass Formatに関する情報」を示すものである。この情報はDevice Class証明書に含まれており、その意味で認証処理中に認証相手となるデバイスに送られる。認証相手のデバイスは、自身がUsage Pass転送元であった場合に、どういった類のUsage Passであれば相手のデバイスが受信可能であるかを、Type Mapによって判断する。例えば、あるUsage PassのUsage Pass Formatが「Type 0」を示していた場合に、認証相手デバイスから送信された証明書中のType Mapが「Type 0受信不可」となっていた場合、Usage Passの転送元デバイスは、Usage Passの転送処理を行わない。
尚、図8では、保護情報領域において、記録モジュール用の記憶領域と、Playback用の記憶領域が分離され、それぞれの記憶領域にDevice Class証明書や認証局公開鍵、Device Class秘密鍵、Device公開鍵、Device秘密鍵、Transaction Log記録領域、失効されたDevice Classのリスト等が記録される形となっているが、必ずしもそのように実装する必要はない。つまり、1つのDevice Class証明書や認証局公開鍵、Device Class秘密鍵、Device公開鍵、Device秘密鍵を、記録モジュールと再生モジュール双方が用い、Transaction Log記録領域やRDCLの記録領域は共用領域として実装する形でも良い。
[Usage Pass転送モジュール221内にある保護情報領域の構成]
図9を用いて、磁気ディスク装置におけるUTモード用の保護情報領域の構成を説明する。図示するように、Usage Pass転送モジュール221内に設けられる保護情報領域504に記録されるデータは、図8における記録モジュール用に保持及び記録されるProtected Information819、あるいは再生モジュール用に保持及び記録されるProtected Information 839と同じである。つまり、1つのDevice Class証明書901、1つの認証局公開鍵903、1つのDevice Class秘密鍵904、1つのDevice公開鍵905、1つのDevice秘密鍵906が埋め込まれ、また1つのRDCLを記録する領域902、適切な数のTransaction Logを記録する領域が設けられる。Device Class証明書901とそれぞれの鍵903、904、905、906は、磁気ディスク装置がPrimal Deviceとなる場合もInceptive Deviceとなる場合も利用される。Transaction Log記録領域も同様である。RDCLの更新は、磁気ディスク装置がPrimal Deviceとなる場合もInceptive Deviceとなる場合も、更新されうる。RDCLの更新基準は、後に図17を用いて説明する。
[制限記憶部223の構成]
図10を用いて、制限記憶部223の構成について説明する。制限記憶部223は、磁気ディスク装置の中にあって、記録モジュールや他の磁気ディスク装置から送られてきたUsage Passを記録し、保持する部分である。Usage Passの記録は、制限記憶コントローラ222によって制御される。制限記憶部223は、Usage Pass本体が記録される領域1000、1010、1020等と、Usage Passの有効性を示すフラグを記録する領域1001、1011、1021等から成る。以降、フラグを有効性指示フラグと呼ぶ。1001に書き込まれた有効性指示フラグは領域1000に書き込まれたUsage Passの有効性を、1011に書き込まれた有効性指示フラグは領域1010に書き込まれたUsage Passの有効性を、1021に書き込まれた有効性指示フラグは領域1020に書き込まれたUsage Passの有効性を示すものである。Usage Pass及び有効性指示フラグを記録する領域は、前記のようにペアを構成し、前記と同様に制限記憶部223内に多数設けられる。各々の有効性指示フラグ領域には、フラグとペアとなっている領域に有効なUsage Passが書き込まれると、制限記憶コントローラ 222によって、「有効」を示す値が記録される。一方、一度書き込まれたUsage Passを再生モジュールや他の磁気ディスク装置へ出力して後は、領域には「無効」を示す値が記録される。また、完全な初期状態においては、「未記録」を示す値が記録される。尚、制限記憶部に記録されているUsage Passの読み出しは、制限記憶コントローラ 222によって行われる。
[BTモードでのUsage Pass転送が実行可能なUsage Pass転送モジュールの構成]
図11を用いて、BTモードでのUsage Pass転送が実行可能なUsage Pass転送モジュールの構成について説明する。
BTモードでは、磁気ディスク装置は常にInceptive Deviceとなる。そこで、Usage Pass転送モジュール1130の中には、他のデバイスとの間で相互認証を行う場合に、自身がInceptive Deviceとなって必要な処理を行うための機能を持ったモジュール 1102、自身がInceptive DeviceとなってUsage Passの転送を行うための機能を持ったモジュール1103、利用者の意思による書き換えが行えないような静的な記憶領域1104、Usage Pass転送を実行した際、処理が正常に終了しなかった場合に、対象のUsage Passが転送元Device及び転送先Deviceいずれからも失われてしまうことを避けるための、Usage Passの復旧機能を有するモジュール1105、及び制限記憶コントローラ222へUsage Passを送信する前に一時的にそれを蓄積しておいたり、制限記憶部から読み出したUsage Passを一時的に蓄積しておいたりするためのUsage Pass Buffer 1110が設けられている。また、静的な記憶領域1104は、UTモードの場合と同様に保護情報領域と呼ばれる。ただし、ここに記録されるデータは、504に記録されるデータとは、若干異なる。認証用モジュール1100は、必要に応じて、記憶領域へアクセスする。
磁気ディスク装置の外部と各モジュールとの間でのデータのやりとりは、Storage Interface Unit 1120及びバス1140を介して行なわれる。PU1121は、図2における231と同じものである。各モジュールが実際に持っている機能、保護情報領域 1104に記録されるデータの種類等については、図15及び図21から図26を用いて、後で説明する。
[BTモードでのUsage Pass送信が実行可能な記録再生装置内の記録モジュールの構成]
図12を用いて、BTモードでのUsage Pass送信が実行可能な記録モジュール102の構成について説明する。
BTモードでは、Host Security Manager 111全体が常にPrimal Deviceとして動作し、Usage Passは、Host Security Manager 111に対して双方向に流れる。そこで、記録モジュール1225は、Usage Passを出力するために必要な機能のみ包含し、Inceptive Deviceとの間で相互認証を行うための機能などは、保護情報転送モジュール104が含む構成とした方が適切である。そこで記録モジュールには、自身がPrimal DeviceとなってUsage Passの送信を行うための機能を持ったモジュール1201、Usage Pass送信処理を実行した際、処理が正常に終了しなかった場合に、対象のUsage Passが転送元デバイス及び転送先デバイスいずれからも失われてしまうことを避けるための、Usage Passの復旧機能を有するモジュール1205、及び外部からコンテンツデータ及び利用権情報を入手し、コンテンツ鍵を生成し、鍵でコンテンツを暗号化し、鍵を含むUsage Passを生成する機能を有するモジュール1206が設けられている。暗号化されたコンテンツデータは、モジュール1206からデータバス1240へ、Host Modules 1220を介して、磁気ディスク装置へ記録される。
記録モジュールを含むホストセキュリティマネージャ1230には、利用者の意思による書き換えが行えないような静的な記憶領域1204が設けられており、認証用モジュール1200やUsage Pass暗号化及び送信用モジュール1201、Usage Pass復旧用モジュール1205などは、必要に応じて、この記憶領域へアクセスする。記憶領域1204は、保護情報領域と呼ばれる。
各モジュールが実際に持っている機能については、図22から図27を用いて相互認証処理及びUsage Pass転送処理を具体的に説明する中で、詳細に説明する。また、保護情報領域 1204に記録されるデータの種類等については、図15を用いて後で説明する。
[BTモードでのUsage Pass受信が実行可能な記録再生装置内の再生モジュールの構成]
図13を用いて、BTモードでのUsage Pass受信が実行可能な再生モジュール103の構成について説明する。
BTモードでは、再生モジュールは、記録モジュールと同様に、常にPrimal Deviceとなる。記録モジュールについて説明した際にも述べたように、ホストセキュリティマネージャがPrimal DeviceとなってInceptive Deviceと相互認証を行うための機能は、保護情報転送モジュール104が担う。そこで、再生モジュール1325には、自身がPrimal DeviceとなってUsage Passの受信を行うための機能を持ったモジュール1303、Usage Pass受信処理を実行した際、処理が正常に終了しなかった場合に、対象のUsage Passが転送元デバイス及び転送先デバイスいずれからも失われてしまうことを避けるための、Usage Passの復旧機能を有するモジュール1305及び1301、及び受信したUsage Passから、Usage Passに含まれるUR_pに記載されている内容を解釈し、それに従って暗号化されたコンテンツデータを復号する機能を有するモジュール1306が設けられている。この時、暗号化されたコンテンツデータは、Host Modules 1320及びデータバス1340を介して、モジュール1306に送信される。復号されたコンテンツデータは、保護されたデータ通信路等を通る形で、モジュール1306から直接再生モジュール外へ出力される。
再生モジュールを含むホストセキュリティマネージャ1330には、利用者の意思による書き換えが行えないような静的な記憶領域1304が設けられており、認証用モジュール 1302や、Usage Pass受信及び復号化用モジュール1303、Usage Pass復旧用モジュール1305及び1301は、必要に応じて、記憶領域へアクセスする。記憶領域1304は、保護情報領域と呼ばれる。
各モジュールが実際に持っている機能については、図22から図27を用いて相互認証処理及びUsage Pass転送処理を具体的に説明する中で、詳細に説明する。また、保護情報領域1304に記録されるデータの種類等については、図15を用いて後で説明する。
[BTモード用保護情報転送モジュールの構成]
図14を用いて、BTモード用の保護情報転送モジュールの構成について説明する。
記録モジュールや再生モジュールに関する説明においても述べたように、BTモードでは、保護情報転送モジュールがInceptive Deviceとの間の相互認証を実行する構成の方が適切である。そこで、保護情報転送モジュール1410には、自身がPrimal DeviceとなってInceptive Deviceとの間で相互認証処理を実行するためのモジュール1400、再生モジュール1416の中のUsage Pass受信用モジュール1403が生成した最新のセッション鍵を一時的に保持し、必要に応じて記録モジュール内のUsage Pass送信用モジュールへ送信するモジュール1405が含まれる。尚、Usage Pass受信用モジュール1403における最新のセッション鍵生成タイミング、及びUsage Pass送信用モジュール1401におけるセッション鍵の利用方法などについては、図23及び図24を用いて処理シークエンスを説明する際に、詳細に述べる。
[ホストセキュリティマネージャ内にあるBTモード用保護情報領域の構成]
図15を用いて、記録再生装置におけるBTモード用の保護情報領域の構成を説明する。
BTモードは、Usage Passを転送する向きに拠らず、ホストセキュリティマネージャ111が全体として常にPrimal Deviceとなり、磁気ディスク装置が常にInceptive DeviceとなってUsage Pass転送をいずれの方向にも実行できるように考案された方式である。それ故、通常記録モジュール102と再生モジュール103は、1つの保護情報領域を共有する形で実装した方が、記録再生装置に設ける静的記憶領域を小さくすることができる。
図15は、このような状況を想定して保護情報領域を実装した場合の内部構成を示している。尚、UTモードの場合に説明したように、記録モジュール102用と再生モジュール103用の別の記憶領域を用意し、それぞれにDevice Class証明書や、相互認証に必要な鍵を記憶させておいても良い。この場合、記録モジュールと再生モジュールはそれぞれが相互認証実行用モジュールを含まなければならなくなる。そのような場合は、本実施例では説明しない。
1501は、Device Class証明書である。Device Class証明書1501には、Device Class公開鍵1500が含まれる。Device Class証明書は、含まれるDevice Class公開鍵の正当性を証明するものであり、電子署名が含まれる。電子署名部は、認証局秘密鍵K_CAで暗号化されている。
1503は認証局公開鍵、1504はDevice Class秘密鍵、1505はDevice公開鍵、1506はDevice秘密鍵である。
以上の証明書及び鍵情報は、初期の実装時に埋め込まれているもので、後で更新されるものではない。
これに対し、領域1502と1510に記録される情報は、RDCＬ及びConnection Logであり、これらは相互認証処理において更新される情報である。RDCLに含まれるデータの意味や、その役割は、UTモードの場合と同じである。一方、Connection Logは、BTモードに固有のログ情報である。ログに記録されるのは、認証相手となるデバイスのDevice公開鍵、認証処理実行中に自身及び相手によって生成される0次セッション鍵、及びType Mapである。図示のように、Connection Logは複数のエントリを持たない。ある2つのDevice間で相互認証処理を実行した後、一方を異なるDeviceと接続し直した場合、Connection Logは上書きされてしまう。
領域1520及び1521には、Transaction Logが記録される。Transaction Logは、Usage Pass転送処理において更新される情報であるが、記録される内容は、UTモードの場合と異なる。BTモードにおいて、Transaction Logとして記録されるのは、転送対象Usage PassのUPID、転送の種類（自身がUsage Passの転送元であるか転送先であるか）、転送を実行する前のUR_s（ただし、Primal DeviceがUsage Passの転送先であった場合のみ）、転送を実行する前のUsage Pass（但し、Primal DeviceがUsage Passの転送元であった場合のみ）、Usage Passが記録されているアドレス（但し、Primal Deviceが転送元であった場合のみ）あるいは記録先のアドレス（但し、Primal DeviceがUsage Passの転送先であった場合のみ）が、Usage Pass転送が実行される際に記録される。これらのデータをUsage Pass転送を行う際に記録しておくことで、不慮の事故等により、転送元及び転送先いずれからもUsage Passが失われてしまった場合にも、復旧することができるようになる。これらのデータを記録するタイミングについては、図23、図24、図26、図27を用いてUsage Pass転送処理を具体的に説明する中で、詳細に説明する。
[Usage Pass転送モジュール内にある保護情報領域の構成]
図16を用いて、磁気ディスク装置におけるBTモード用の保護情報領域の構成を説明する。
前述の通り、BTモードは、Usage Passを転送する向きに拠らず、ホストセキュリティマネージャ 111が全体として常にPrimal Deviceとなり、磁気ディスク装置が常にInceptive DeviceとなってUsage Pass転送をいずれの方向にも実行できるように考案された方式である。
図示の通り、Usage Pass転送モジュール内に設けられる保護情報領域に記録されるデータは、Transaction Logを除き、ホストセキュリティマネージャ 111に記録されるデータと同一である。つまり、1601はDevice Class公開鍵1600を含むDevice Class証明書であり、1603は認証局公開鍵、1604はDevice Class秘密鍵、1605はDevice公開鍵、1606はDevice秘密鍵、そして1610はConnection Logの記録領域である。
また、図示されている通り、制限記憶部223内の保護情報領域には、Transaction Logの記録領域が設けられていない。これは、Usage Pass転送実行時には、磁気ディスク装置はTransaction Logの記録を行わないことを意味する。ログの記録処理がない分、BTモードでのUsage Pass転送時の磁気ディスク装置の処理負荷は、UTモードに比べて、軽くなるという特徴がある。
上記の証明書及び鍵情報は、初期の実装時に埋め込まれているもので、後で更新されるものではない点、及びConnection LogはUsage Passを実行しようとするデバイス間で行われる相互認証処理において更新される点も、ホストセキュリティマネージャ111内の保護情報領域101と同じである。
次に、図17から図27を参照して、ホストモジュール110、Primal Device、Inceptive Deviceの三者の間で行われる、相互認証処理、Usage Pass転送処理の詳細について説明する。これらの図は、ホストモジュールが発行する命令と、それに付随してデータバスを流れるデータ、及び命令とデータを受信または送信し、相互認証あるいはUsage Pass転送を実行するために各デバイスもしくはモジュールに求められる処理及び機能を示すものである。
[Usage Pass転送モード設定処理]
Usage Pass転送を実行するためには、まず初めに、ホストモジュール110が仲介する形で、自身に接続されている脱着可能な記憶装置125，126及び自身に備わっているホストセキュリティマネージャ111に対して、UTモードあるいはBTモードいずれの方式でUsage Pass転送を実行するか、を設定する必要がある。図17は、これを実現するために各Deviceもしくはモジュールに求められる処理及び機能を、ホストモジュールが発行する命令とそれに付随して流れるデータの流れという観点で示したものである。
尚、図17では、ホストモジュールを介して接続されている2つのDeviceのインタフェースを、便宜的にDevice1 Interface，Device2 Interfaceと記してある。Device1あるいはDevice2が記録再生装置であった場合は、ホストセキュリティマネージャ630あるいは1230内のいずれかのモジュールであり、記憶装置であった場合はStorage Interface Unitがこれらに相当する。
まず、ホストモジュールは、Device2に対し、制限アクセスモード取得（GET QUALIFIED ACCESS MODE）命令17000を発行する。これに対しDevice2は、自身がUTモードによるUsage Pass転送を実行する機能とBTモードによるUsage Pass転送を実行する機能のいずれか、もしくは双方を有しているかを、応答17001としてホストモジュール110へ通知する。
次に、ホストモジュール110は、Device1に対しても同様の命令17010を発行する。Device1は、Device2と同様に、自身がUTモードによるUsage Pass転送を実行する機能とBTモードによるUsage Pass転送を実行する機能のいずれか、もしくは双方を有しているかを、応答17011としてホストモジュール110へ通知する。
このようにして、ホストモジュール110は、Device2及びDevice1がそれぞれ実装しているUsage Pass転送モードの種類を知ることができ、ホストモジュール110は、双方のDeviceが実装しているモードを選び、双方のDeviceにモードを設定する。Device2に対しては、オープンチャネル（OPEN CHANNEL）命令17020、Device1に対しては、OPEN CHANNEL命令17030が、それらを設定するためのものである。これらの命令に付随して、いずれの制限アクセスモードでUsage Pass転送を実行するか、及び複数の転送処理を同時並列的に実行する場合にそれらを分離可能にするための識別子を、データ17021及びデータ17031で双方のDeviceに送信する。以下では、識別子のことをChannel識別子と呼ぶ。図17では、Device1に対して設定されるChannel識別子はID_[D1]、Device2に対して設定されるChannel識別子はID_[D2]と記されている。
ここで、同時並列的とは、例えば以下のような状況を言う。認証の確立後、Usage Pass転送が実行される場合は、Channel IDが特定されて、そのChannel IDの下でのみ転送が行われる。特に、UTモードの場合、Device2（磁気ディスク装置）に対して書き込みを行いながら、読み出しを行なう場合、ホストモジュールが発行する命令は、インターリーブ的になる場合がある。この様子を図28に示す。
図28において、PUT USAGE PASSの後には、ホストモジュールからDevice2にUsage Passが転送され、GET USAGE PASSの後には、Device 2からホストモジュールにUsage Passが転送される。太線で示す命令群（＊1、＊2、＊3印の命令）は、それ自体に処理順序が規定されおり、不規則な順序で該命令を受信した場合は、Device2はそれに関連した処理を中断する（abort）。しかし、途中に、細線で示す命令（＊＊1、＊＊2、＊＊3印の命令）が来ても、＊1、＊2、＊3印の命令については、それら自体の実行順序が規定通りであれば、Device2は関連した処理の実行を中断しない。太線の命令群は、それ自体規定された順序を守ってDevice2に命令が送られる限り、問題はないからである。
このような状況において、Device2はChannel IDを使って太線で示す処理系列と細線で示す処理系列を判別する。つまり、同時並列的な処理とは、このような状況を想定しており、太線で示す命令だけ先に初めから最後まで実行しUsage Pass転送を終了してから細線で示す処理を実行するというようなやり方ではなく、上記のように、お互いに属する命令が間に差し挟まれながら全体として処理を行なうような状況をいう。尚、上記のように2つの処理系列に限らず、3つ以上がお互い差し挟まれながら実行される場合も該当する。
説明を図17に戻す。Channel識別子は、具体的には次のように利用される。
例えば、記録再生装置に唯一の脱着型記憶装置が接続されていたとする。このような状況において、UTモードで記録モジュール102から記憶装置（例えば125、以下同じ）へのUsage Passの書き込み行いながら、同様にUTモードで記憶装置125から再生モジュール103へ、既に記録されているUsage Passの読み出しを行うような場合、記憶装置125では、それぞれのUsage Pass転送処理を分離して管理できるようにする必要がある。このような二つの処理系列に異なるChannel識別子を割り当てることで、脱着型の記憶装置は、ホストモジュール110から送信されてきた命令が、どちらの処理系列に関連するものなのかを判断できるようになる。
Device2及びDevice1は、それぞれデータ17021及び17031を受信すると、Channel識別子と、この識別子に関連付けられた制限アクセスモードを設定する処理を、17022及び17032において実行する。
Channel識別子と制限アクセスモードが設定されると、Device1とDevice2の間で相互認証処理17040、及びそれに引き続く実際のUsage Pass転送処理17041が実行される。これらの詳細は、図18から図27を用いて、後で詳細に説明する。
必要なUsage Pass転送処理を終えると、ホストモジュール110は、Device2とDevice1に対し、それぞれクローズチャネル（CLOSE CHANNEL）命令17050及び17060命令を発行する。この命令には、付随してChannel識別子17051及び17061がそれぞれのDeviceに送信される。それぞれのDeviceは、命令を受信すると、命令に続いて受信したChannel識別子で特定される処理系列に関する状態情報をすべてリセットし、Channel識別子も開放する。一度Channel識別子が開放されると、再度OPEN CHANNEL命令によってChannel識別子及び制限アクセスモードを設定しない限り、Deviceは認証処理やUsage Pass転送を実行するためにホストモジュールが発行する命令において、Channel識別子が指定されても、命令に関する処理を中断する。
[公開鍵暗号化による共有Device公開鍵共有方法]
相互認証及びUsage Pass転送に関する詳細な処理シークエンスについて説明する前に、本発明の実施例で用いられる公開鍵暗号化の方法について説明する。
本実施例では、公開鍵暗号化の方法として楕円暗号を利用する。楕円暗号は、2次元のある楕円曲線の方程式で表される曲線上の固定点（これをベースポイントG = (Gx, Gy)と呼ぶ）に対し、そのn倍点、すなわちGをn回加算するという演算を暗号化に際して利用するものである。ここで用いられる加算法は、通常の十進法の加算方式と異なり、Gを整数回加算した結果は、Gとは異なる楕円曲線上の点となるようなものである。
説明に際し、Device1とDevice2の二つのDeviceを想定する。そして、Device1には暗号化すべきメッセージMが、Device2には、ある公開鍵KPuとペアとなる秘密鍵KPrが記録されているものとする。ここで、KPrは自然数、KPuは楕円曲線上の座標点（KPux, KPuy）であり、両者及びベースポイントは、KPu = KPr × Gという関係で結ばれている。言い換えると、KPuは、ベースポイントのKPｒ回加算点であるということである。
まず、Device1における暗号化処理について説明する。
(E1) Device2からDevice1へ、KPuを送信する。
(E2) Device1において、あるランダム自然数rを生成する。
(E3) r × G = R = (Rx, Ry)を計算する。
(E4) r × KPu = P = (Px, Py)を計算する
(E5) Px, Pyを用いて、ある自然数*KPuを生成する: *KPu = f(Px, Py) ここで、関数fは、事前に決めてあれば、任意でよい。
(E6) *KPuを共通鍵として用い、暗号化対象のメッセージMを、対称暗号化する: E(*KPu, M)
(E7) (6)で得られたデータに、(3)で得られたデータを連結し、Device2へ送信する。送信されるデータは、Rx || Ry || E(*KPu, M)である。ここで、*KPuを共有Device公開鍵と呼ぶ。
次に、Device2における復号化処理について説明する。
(D1) Rx, Ry, KPrを用いて、Pを計算する: KPr × R = KPr × r × G = r × (KPr × G) = r × KPu = P = (Px, Py)
(D2) Px, Pyを用いて、*KPrを求める。ここで、*KPrと*KPuは、全く同一の数である。前者は、KPrを用いて得られたという意味で、*KPrと表現されている: *KPr = f(Px, Py)
(D3) r × KPu = P = (Px, Py)を求める。
(D4) *KPrを共通鍵として用い、受信したデータを、対称復号化する: D(*KPr, E(*KPu, M)), 本発明では、これをD(KPr, E(KPu, M))と記載する。ここで、*KPrを共有Device秘密鍵と呼ぶ。
以上に説明した、共通鍵*KPu、*KPrを共有するためのアルゴリズムは、一般にはECDHアルゴリズムと呼ばれている。
尚、本明細書では、処理E2から処理E7全てを行う暗号化を、E(KPu, M)と記載する。既に*KPuが求められていて、処理E6のみ行う場合は、E(*KPu, M)と記載する。同様に、処理D1から処理D4まで全てを行う復号化を、D(KPr, E(KPu, M))と記載する。既に*KPrを求められていて、処理D4のみ行う場合は、D(*KPr, E(*KPu, M))と記載する。
[図18から図32に表れる記号短縮名に関する説明]
図18から図27には、UTモード及びBTモードでの相互認証処理シークエンス及びUsage Pass転送処理シークエンスを、また図28から図32には本発明の本質である複製条件付きデータの読み出し及び書き込みシークエンスを示す。これらの図中では、短縮形として以下の表記が用いられる。
ID: Usage Pass Identifier（識別子）
DCC: Device Class Certificate
PD.C.key: Primal Deviceで生成されるChallenge鍵
ID.C.key: Inceptive Deviceで生成されるChallenge鍵
PD.S.key: Primal Deviceで生成されるセッション鍵
ID.S.key: Inceptive Deviceで生成されるセッション鍵
RDCL: 失効させられたDevice Classのリスト
UP: Usage Pass
UPL: Usage Pass Locationの略で、Primal Deviceに記録されている、あるいはInceptive Deviceに記録する予定の、Usage Passのアドレスである。アドレッシングの方法は、さまざまな機器毎に異なるので、ここでは特定しない。
MUP: Masked Usage Pass．Usage Pass中のコンテンツ鍵の部分が0に置き換えられたUsage Passに、Usage Pass Stautsを連結したもの。
AI: Action Indicator．ENCRYPT USAGE PASS COPY/MOVE/PLAYのいずれの命令を受信したかを示すもの。詳細は、図19、図23、図24の説明において述べる。
CKS: Checksum。一方のDeviceから他方のDeviceに対してデータを転送する際、転送元において、データの完全性保証を目的に、データに対して連結されるもの。詳細は、図19、図23、図24の説明において述べる。
TL: Transaction Log
CL: Connection Log
TS_UT: UTモードにおいて用いられるTransaction Status．詳細は、図21の説明において述べる。
TS_BT: BTモードにおいて用いられるTransaction Status．詳細は、図21の説明において述べる。
Status:
SS: Session Status．Usage Passの転送処理の段階．詳細は、図21の説明において述べる。
UPS: Usage Pass Status．Usage Passの検索あるいは読み出しを行なった結果判明した、記録されているUsage Passの状態。図10における有効性指示フラグに記載されている値と同一である。有効、無効、未記録の3状態がある。
図18から図27では、Host Modulesが送信した命令やデータを受信する実体を、単にPrimal Device及びInceptive Deviceと記載している。これは、図17で説明したものと同様で、Primal DeviceあるいはInceptive Deviceが記録再生装置であった場合は、ホストセキュリティマネージャ630あるいは1230内のいずれかのモジュールであり、記憶装置であった場合はStorage Interface Unitがこれらに相当する。
[UTモードにおけるDevice間相互認証処理シークエンス]
図18を用いて、UTモードにおける、Primal DeviceとInceptive Deviceの間で相互認証を行う場合の処理シークエンスについて説明する。
尚、UTモードにおける相互認証処理段階のことを、以下ではUTコネクションステージ（Connection Stage）と呼ぶ。二つの脱着可能な記憶装置間でUsage Passを転送するということは、Primal Deviceが記憶装置125におけるモジュール500、Inceptive Deviceが記憶装置126におけるモジュール502であるような場合である。記録モジュールなどで新たに生成したUsage Passを、脱着可能な記憶装置へ記録するような場合は、Primal Deviceがモジュール600、Inceptive Deviceがモジュール502である。磁気ディスク装置に記録されているUsage Passを再生モジュールへ送信し、コンテンツデータの復号や再生などを行う場合は、Primal Deviceがモジュール500、Inceptive Deviceがモジュール702となる。これらの関係は、図19から図21におけるUTモードでの各処理シークエンスについての説明でも同様である。
まず初めに、ホストモジュールは、Inceptive Deviceに対してデバイスクラス証明書取得（GET DEVICE CLASS CERTIFICATE）命令18000を発行する。すると、Inceptive Deviceは、自身に埋め込まれているデバイスクラス（Device Class）証明書を、ホストモジュール110へ送信する（18001）。Device Class証明書を、以降ではDCC（K_CA, KP_dc[I]）と記載する。これは、証明書が、KP_dc[I]の正当性を示すもので、K_CAを用いて電子署名部が暗号化されていることを表している。
ホストモジュール110は、DCC（K_CA, KP_dc[I]）を受信すると、Primal Deviceに対しデバイスクラス証明書検証（VERIFY DEVICE CLASS CERTIFICATE）命令18010を発行し、それに続いてDCC（K_CA, KP_dc[I]）をPrimal Deviceへ送信する（18012）
Primal Deviceは、DCC（K_CA, KP_dc[I]）を受信すると、18012に示す1つの処理（処理UT1.1.1）を実行する。
処理UT1.1.1: DCC（K_CA, KP_dc[I]）の検証を行う。検証は、証明書中のデータに対して改竄が行われていないか、及び含まれる証明書を特定する番号が、自身に記録されているRDCL_[P]に載っていないか、を調査することによって達成される。改竄の有無は、KP_dc[I]を含む電子署名部以外のデータのハッシュ値を計算した後、それがDCC（K_CA, KP_dc[I]）における電子署名部をKP_CAで復号した結果と一致しているか否かで判定される。両者が一致していた場合、改竄は行われていないことになる。証明書を特定する番号がRDCL_[P]に載っていた場合、認証処理は中断される。
Primal DeviceがDCC（K_CA, KP_dc[I]）を検証中に、ホストモジュール110は、処理が終了するタイミングを見計らって、Primal Deviceに対し、プライマルチャレンジキーUTコネクション取得（GET PRIMAL CHALLENGE KEY UT CONNECTION）命令18020を発行する。Primal Deviceは命令を受信すると、18021に示す、下記3つの処理を実行する。
処理UT1.2.1: Challenge鍵K_ch[P]を生成する。
処理UT1.2.2: 処理UT1.2.1で生成したK_ch[P]を、DCC（K_CA, KP_dc[I]）中のKP_dc[I]で暗号化する。得られるデータは、E(KP_dc[I], K_ch[P])である。
処理UT1.2.3: 処理UT1.2.2で得られたデータに対し、自身に埋め込まれているDevice Class証明書を連結。得られるデータは、E(KP_dc[I], K_ch[P]) || DCC(K_CA, KP_dc[P])である。
処理UT1.2.3においてE(KP_dc[I], K_ch[P]) || DCC(K_CA, KP_dc[P])の生成を終えると、Primal Deviceは、データをホストモジュールへ送信する（18022）。
ホストモジュールは、E(KP_dc[I], K_ch[P]) || DCC(K_CA, KP_dc[P])を受信すると、Inceptive Deviceに対してPUT PRIMAL CHALLENGE KEY UT CONNECTION命令18030命令を発行後、受信したデータをInceptive Deviceに送信する（18031）。
Inceptive Deviceは、E(KP_dc[I], K_ch[P]) || DCC(K_CA, KP_dc[P])を受信すると、18032に示す、下記の3つの処理を実行する。
処理UT1.3.1: DCC(K_CA, KP_dc[P])を検証する。検証手段は、処理UT1.1.1で説明した方法と同じである。但し、参照するRDCLは、RDCL_[I]である。
処理UT1.3.2: 受信したデータのうち、E(KP_dc[I], K_ch[P])を分離し、復号する。復号は、自身の保護情報領域に埋め込まれているK_dc[I]を用いて行う。
処理UT1.3.3: 処理UT1.3.2の結果として、K_ch[P]が正当な形で含まれていたかどうかを確認する。確認は、次のようにして行う。まず、処理UT1.3.2においてK_ch[P]を暗号化する際、K_ch[P]に対し固有の番号を連結して暗号化するということをあらかじめ規定しておく。そして、処理UT1.3.2において受信したデータを復号した際、その結果において、規定された番号が得られれば、データの破壊等は起こっていないと判断する。
処理UT1.3.1から処理UT1.3.3を実行中、ホストモジュール110は、処理が終了するタイミングを予測し、適切なタイミングでGET INCEPTIVE SESSION KEY UT CONNECTION命令18040を発行する。Inceptive Deviceは命令を受信すると、18041に示す下記の2つの処理を実行する。
処理UT1.4.1: 0次セッション鍵K_s[I]0を生成する。
処理UT1.4.2: 処理UT1.4.1で生成したK_s[I]0に対し、自身に埋め込まれているDevice公開鍵KP_d[I]を連結し、処理UT1.3.1で受信したKP_dc[P]で暗号化する。暗号化によって得られたデータに、自身に記録されているRDCL_[I]を連結し、得られたデータ全体に対するChecksumを計算し、該Checksumを該データに連結する。そして、得られたデータ全体を、処理UT1.3.3で得られたK_ch[P]で暗号化する。最終的に得られるデータは、E(K_ch[P], E(KP_dc[P], K_s[I]0 || KP_d[I]) || RDCL_[I] || CKS)である。
Inceptive Deviceにおいて、E(K_ch[P], E(KP_dc[P], K_s[I]0 || KP_d[I]) || RDCL_[I] || CKS)が生成されると、Deviceは、生成されたデータをホストモジュールへ送信する（18042）。
ホストモジュールは、E(K_ch[P], E(KP_dc[P], K_s[I]0 || KP_d[I]) || RDCL_[I] || CKS)を受信すると、Primal Deviceに対して、インセンプティブセッションキーUTコネクション送信（PUT INCEPTIVE SESSION KEY UT CONNECTION）命令18050を発行後、受信したデータをPrimal Deviceへ送信する（18051）。
Primal Deviceは、E(K_ch[P], E(KP_dc[P], K_s[I]0 || KP_d[I]) || RDCL_[I] || CKS)を受信すると、18052に示す、下記の5つの処理を実行する。
処理UT1.5.1: 受信したデータを、K_ch[P]で復号する。K_ch[P]は、処理UT1.2.1において自身で生成された鍵である。
処理UT1.5.2: 処理UT1.5.1の結果から、RDCL_[I]を分離し、RDCL_[I]が正当な形で含まれていたかどうかを確認する。確認するための手段は、Checksum計算による構造確認、及び処理UT1.3.3に記したものと同じである。
処理UT1.5.3: 自身に記録されているRDCL_[P]と、送信されたRDCL_[I]について、それらが発行された日付情報を比較する。RDCLの発行日情報は、RDCL内に含まれるものとする。比較した結果、受信したRDCL_[I]の発行日情報が、自身に記録されているRDCL_[P]の発行日情報より新しかった場合は、RDCL_[P]をRDCL_[I]で上書きする。
処理UT1.5.4: 残りのデータE(KP_dc[P], K_s[I]0 || KP_d[I])を、K_dc[P]で復号する。
処理UT1.5.5: 処理UT1.5.4で得られたデータについて、K_s[I]0 || KP_d[I]が正当な形で含まれていたかどうかを確認する。確認するための手段は、処理UT1.3.3に記したものと同じである。
処理UT1.5.1から処理UT1.5.5をPrimal Deviceが実行中、ホストモジュールは処理が終了するタイミングを予測し、適切なタイミングでGET PRIMAL SESSION KEY UT CONNECTION命令18061を発行する。Primal Deviceは命令を受信すると、18061に示す、下記の2つの処理を実行する。
処理UT1.6.1: 0次セッション鍵K_s[P]0生成する。
処理UT1.6.2: 処理UT1.6.1で生成したK_s[P]0を、処理UT1.5.5で受信した0次セッション鍵K_s[I]0で暗号化する。得られるデータはE(K_s[I]0, K_s[P]0)である。ここで、処理UT1.5.3におけるRDCL_[P]とRDCL_[I]の発行日情報の比較の結果、RDCL_[P]の発行日の方が新しかった場合は、E(K_s[I]0, K_s[P]0)に対しRDCL_[P]を連結し、更に得られたデータ全体についてのChecksumを計算し、連結する。その後、得られたデータ全体を、処理UT1.5.5で得られたKP_d[I]で暗号化する。最終的に得られるデータは、E(KP_d[I], E(K_s[I]0, K_s[P]0 || KP_d[P]) || RDCL_[P] || CKS)である。
Primal Deviceにおいて、E(KP_d[I], E(K_s[I]0, K_s[P]0 || KP_d[P]) || RDCL_[P] || CKS)の生成を終えると、Deviceは、データをホストモジュール110へ送信する（18062）。
ホストモジュール110は、E(KP_d[I], E(K_s[I]0, K_s[P]0 || KP_d[P]) || RDCL_[P] || CKS)を受信すると、Inceptive Deviceに対してPUT PRIMAL SESSION KEY UT CONNECTION命令18070命令を発行後、受信したデータをDeviceに送信する（18071）。
Inceptive Deviceは、E(KP_d[I], E(K_s[I]0, K_s[P]0 || KP_d[P]) || RDCL_[P] || CKS)を受信すると、18072に示す、下記の5つの処理を実行する。
処理UT1.7.1: 受信したデータを、K_d[I]で復号する。K_d[I]は、自身の保護情報領域に埋め込まれている。
処理UT1.7.2: 処理UT1.7.1の結果にRDCL_[P]が含まれていた場合、データを分離し、データが正当な形で含まれていたかどうかを確認する。確認するための手段は、Checksum計算による構造確認、及び処理UT1.3.3に記したものと同じである。
処理UT1.7.3: 処理UT1.7.1と処理UT1.7.2の結果、受信したデータにRDCL_[P]が含まれていて、それが正当な形で含まれていたことが確認できた場合、自身に記録されているRDCL_[I]を、受信したRDCL_[P]で上書きする。
処理UT1.7.4: 残りのデータE(K_s[I]0, K_s[P]0)を、K_s[I]0で復号する。K_s[I]0は、処理UT1.4.1において、自身で生成した鍵データである。
処理UT1.7.5: 処理UT1.7.4で得られたデータについて、K_s[P]0が正当な形で含まれていたかどうかを確認する。確認するための手段は、処理UT1.3.3に記したものと同じである。
以上、処理UT1.7.5までを完了すると、共有Device公開鍵*KP_d[I]（共有Device秘密鍵*K_d[I]と同じ）、K_s[P]0、K_s[I]0の共有が完了する。
[UTモードにおけるDevice間Usage Pass転送処理シークエンス]
UTモードにより、Primal DeviceとInceptive Deviceの間で相互認証が完了すると、Primal DeviceからInceptive Deviceに対して、Usage Passを転送することができる。次に、図19を用いて、Usage Passの転送処理シークエンスについて説明する。尚、UTモードにおけるUsage Pass転送処理段階のことを、以下ではUT Transfer Stageと呼ぶ。
まず初めに、ホストモジュール110は、Primal Deviceに対してユーセジパスリード（READ USAGE PASS）命令19000を発行する。そして、命令に続いて、Usage Passが記録されている場所及び読み出すUsage Passの数を、19001においてPrimal Deviceに通知する。Primal Deviceは、命令とUsage Passが記録されている場所及び読み出すUsage Passの数についての情報を受信すると、19002に示す、下記の処理を実行する。
処理UT2.1.1: 転送対象のUsage Passを、Usage Pass送信用モジュール内へ準備する。例えば、Primal Deviceが磁気ディスク装置であった場合、目的のUsage Passを制限記憶部 223からUsage Pass Buffer 510を介してモジュール501内に送るような処理に相当する。同様に、Primal Deviceが記録モジュールであった場合、目的のUsage PassをUsage Pass Creator and Content Encrypter606からモジュール601へ送るような処理に相当する。
ホストモジュール110は、目的のUsage Passが、Usage Pass送信用モジュール内に準備されると、続いてマスクユーセジパス取得（GET MASKED USAGE PASS）命令19010を、Primal Deviceに対して発行する。Primal Deviceはこの命令を受信すると、Masked Usage Passを作成し、19011においてホストモジュール110へデータを送信する。先に説明したように、Masked Usage Passは、Usage Pass中のコンテンツ鍵データ部を0で置き換えたものに、Usage Pass Statusを連結したものである。ホストモジュール110は、Masked Usage Passを受信すると、データ中のUR_sを解析し、Usage Pass送信用モジュール内に読み出されたUsage Passが、転送可能であるかどうかを判断する。転送可能であると判断された場合は、以下のUsage Pass転送処理を継続する。
Usage Pass転送処理を継続する場合、次にホストモジュール110は、Inceptive Deviceに対して、インセプティブセッション鍵UT転送生成（CREATE INCEPTVE DEVICE SESSION KEY UT TRANSFER）命令19020命令を発行する。そして、この命令に続いて、転送対象となるUsage PassのUsage Pass識別子をInceptive Deviceへ送信する（19021）。Inceptive Deviceは、受信対象Usage PassのUsage Pass識別子を受信すると、19022に示す、下記の3つの処理を実行する。
処理UT2.2.1: セッション鍵K_s[I]nを生成する。セッション鍵は、Usage Pass転送を行う度に生成される共通鍵であり、その意味から、nはn回目のUsage Pass転送用に生成されたことであることを意味する。n ≧ 1である。
処理UT2.2.2: Transaction Logを生成する。ここで記録されるのは、転送対象Usage PassのUsage Pass識別子、処理UT2.2.1で生成したセッション鍵K_s[I]n、Session Statusである。要素には、Usage Passを受信する準備が整ったという意味で、RP（Receive Prepared）が設定される。残りの要素には、不定U（Unspecified）が記録される。
処理UT2.2.3: 処理UT2.2.1で生成したK_s[I]nを、1つ前のUsage Pass転送実行時に生成したセッション鍵K_s[I]n-1及びConnection StageにおいてPrimal Deviceで生成された0次セッション鍵K_s[P]0を用いて、暗号化する。本処理の前に一度のUsage Pass転送が行われていない場合は、Connection Stage中の処理UT1.4.1において自身で生成した0次セッション鍵を用いる。得られるデータは、E(K_s[P]0, E(K_s[I]n-1, K_s[I]n))である。
処理UT2.2.1及び処理UT2.2.2をInceptive Deviceが実行中、ホストモジュールは処理が終了するタイミングを予測し、適切なタイミングで、インセプティブセッション鍵UT転送取得（GET INCEPIVE DEVICE SESSION KEY UT TRANSFER）命令19030を発行する。Inceptive Deviceはこの命令を受信すると、処理UT2.2.3において生成されたデータを、ホストモジュール110へ送信する（19031）。
ホストモジュール110は、E(K_s[P]0, E(K_s[I]n-1, K_s[I]n))を受信すると、Primal Deviceに対して、インセプティブセッション鍵UT転送送信（PUT INCEPTIVE SESSION KEY UT TRANSFER）命令19040を発行した後、受信したデータにUsage Pass識別子を連結し、Primal Deviceへ送信する（19041）。送信されるデータは、UPID || E(K_s[P]0, E(K_s[I]n-1, K_s[I]n))である。
Primal Deviceは、UPID || E(K_s[P]0, E(K_s[I]n-1, K_s[I]n))を受信すると、19042に示す、下記の5つの処理を実行する。
処理UT2.3.1: 受信したUPIDと、処理UT2.1.1でUsage Pass送信用モジュール内に準備したUsage PassのUPIDが一致しているか調べる。一致していなければ、ここでUsage Pass転送処理を中断する。
処理UT2.3.2: 受信したデータを、K_s[P]0及びK_s[I]n-1で復号する。K_s[P]0は処理UT1.6.1において自身で生成したものであり、K_s[I]n-1は処理UT.2.2.3において説明したものと同じである。
処理UT2.3.3: 処理UT2.3.2で得られたデータについて、K_s[I]nが正当な形で含まれていたかどうかを確認する。確認するための手段は、処理UT1.3.3に記したものと同じである。
処理UT2.3.4: Transaction Logを生成する。ここで記録されるのは、転送対象Usage PassのUsage Pass識別子、処理UT1.1.1で得たInceptive DeviceのDevice Class証明書に含まれるType Map、処理処理UT2.3.3で得たセッション鍵K_s[I]n、Session Status、転送対象Usage PassのUR_s、処理UT2.1.1で読み出したUsage PassのUsage Pass Locationである。Session Statusには、Usage Passを送信する準備が整ったという意味で、SP（Send Prepared）が設定される。
以上、処理UT2.3.1から処理UT2.3.4をPrimal Deviceが実行中、ホストモジュールは処理が終了するタイミングを予測し、適切なタイミングでENCRYPT USAGE PASS COPYあるいはENCRYPT USAGE PASS MOVEあるいはENCRYPT USAGE PASS PLAY命令19050を発行する。尚、どの命令を受信した場合にどのようなUR_sのUsage Passを送信するか、そして複製や再生の場合Primal Deviceに残るUsage PassのUR_sはどのように変更しなければならないか等については、あらかじめ全て規定されているものとする。そこで、命令を受信すると、Primal Deviceは、19051に示す、下記の2つの処理を実行する。
処理UT2.4.1: Inceptive Deviceに対して送信するUsage Passを、処理UT2.1.1においてUsage Pass送信用モジュール内に準備されたUsage Passを元に、生成する。通常、UPIDやK_cなどはそのまま複製され、UR_sのみ規定に従う形で変更される。
処理UT2.4.2: 処理UT2.4.1において生成された送信用Usage Passに対し、受信した命令がENCRYPT USAGE PASS COPY/MOVE/PLAYのいずれであるかを示す識別子情報Action Indicator、及びUsage Pass || Action Indicatorに対するChecksumを計算し、連結する。連結処理の後、得られたデータをK_s[I]n及び*KP_d[I]を用いて暗号化する。即ち、共通鍵による二重暗号化である。得られるデータは、E(*KP_d[I], E(K_s[I]n, Usage Pass || Action Indicator || Checksum))である。尚、Checksumの計算は、例えば次のように行えば良い。
まず、計算対象とするデータUsage Pass || Action Indicatorを、固定長ごとに分割する。そして、得られたそれぞれのブロックデータを全て足し合わせた後、全てのビット値を反転し、更に1を加える。これは、Usage Pass || Action Indicatorの2の補数を求めていることに他ならない。検証時は、Checksumを含めたデータ全体Usage Pass || Action Indicator || Checksumを先と同じ固定長に分割後、各ブロックデータを全て足し合わせる。その結果が0となれば、途中でデータに変化がないということになる。
上記の処理UT2.4.1及び処理UT2.4.2をPrimal Deviceが実行中、ホストモジュール110は処理が終了するタイミングを予測し、適切なタイミングでGET USAGE PASS命令19060を発行する。Primal Deviceは、命令を受信すると、19062に示す、下記の3つの処理を実行する。
処理UT2.5.1: Transaction LogにおけるSession Statusを更新する。Usage Passの送信が完了したことで、Session StatusをSC（Send Completed）に設定する。
処理UT2.5.2: 処理2.4.2において生成されたデータE(*KP_d[I], E(K_s[I]n, Usage Pass || Action Indicator || Checksum))をホストモジュールへ送信する。
処理UT2.5.3: 元のUsage Pass中のUR_sを規定に従って変更する。Primal Deviceが磁気ディスク装置であった場合は、UR_sが変更されたUsage Passを、Usage Passが制限記憶部中で元来記録されていた場所に、上書きする。尚、命令19050がENCRYPT USAGE PASS MOVEであった場合、有効性指示フラグの値は「無効」にされる。
ホストモジュール110は、E(*KP_d[I], E(K_s[I]n, Usage Pass || Action Indicator || Checksum))を受信すると、Inceptive Deviceに対して、ユーセジパス送信（PUT USAGE PASS）命令19070を発行し、またDeviceに対し、E(*KP_d[I], E(K_s[I]n, Usage Pass || Action Indicator || Checksum))を送信する（19071）。Inceptive Deviceは、命令及びデータを受信すると、19072に示す、下記の3つの処理を実行する。
処理UT2.5.1: 受信したデータを、*K_d[I]及びK_s[I]nで復号する。*K_d[I]は、処理UT1.7.1において得た共通鍵である。また、K_s[I]nは処理UT2.2.1において自身で生成したセッション鍵である。
処理UT2.5.2: 処理UT2.5.1で得られたデータについて、Usage Pass || Action Indicator || Checksumが正当な形で含まれていたかどうかを確認する。確認は、Checksumを検証すること及び処理UT1.3.3に記した手段を用いて行われる。Checksumによる検証方法は、処理UT2.4.2に記載してある。
処理UT2.5.3: Transaction LogにおけるSession Status及びUsage Pass Locationを更新する。Session Status には、Usage Passの受信が完了したということを表すRC（Receive Completed）を設定する。Usage Pass Locationには、Usage Passの記録先アドレスを記載する。
尚、Inceptive Deviceが磁気ディスク装置の場合、処理UT2.5.3の後、受信したUsage Passを制限記憶部223に記録する。Usage Passの記録を行う際には、有効性指示フラグを「有効」に設定する。
その後、Inceptive DeviceにおけるUsage Passの受信もしくは制限記憶部223への記録が正常に終了したか否かを確認するために、ホストモジュール110は、Inceptive Deviceに対し、実行ステータスチェック（CHECK EXECUTION STATUS）命令19080を発行しても良い。Inceptive Deviceからホストモジュールへは、実行状態が19081において送信される。
以上のように、UT Transfer Stageを繰り返すことにより、Connection Stageを繰り返し行わなくても、連続的にUsage Pass転送を実行することができる。
[UTモードにおけるDevice間再相互認証処理シークエンス]
Primal DeviceとInceptive Deviceの間で1回以上のUT Transfer Stageが行われ、両Deviceの間でセッション鍵K_s[I]nの共有及び鍵のTransaction Logへの記録が終了した後、記録再生装置に異常が発生して、Usage Pass送信用モジュール及び同受信用モジュールからセッション鍵が失われてしまった場合、Connection Stageと比べ、少ない処理で相互認証を再完了することができる。
次に、図20を用いて、この再相互認証処理について説明する。尚、UTモードにおける本処理段階のことを、以下ではUT Reconnection Stageと呼ぶ。
まず、UT Transfer Stageにおいて、Inceptive Deviceはユーセジパス送信（PUT USAGE PASS）命令20000及びそれに続いてUsage Pass 20001を受信しているという状況を想定する。そして、Usage Passの受信処理が完全に完了しないうちに、異常発生の理由により、Primal DeviceとInceptive Deviceの間で分断が発生し、20001で流れるUsage Passを暗号化するために用いられていたセッション鍵K_s[I]や共有Device公開鍵*KP_d[I]が、両Deviceから失われてしまったとする（20010）。
上記の場合、ホストモジュール110は、まずPrimal Deviceに対し、トランザクションログ再認証検索（SEARCH TRANSACTION LOG RECONNECTION）命令20020を発行する。そして、命令に続き、20001で送信中であったUsage PassのUsage Pass識別子を、送信する（20021）。
Primal Deviceは、識別子を受信すると、20022に示す下記の1つの処理を実行する。
処理UT3.1.1: 保護情報領域の中で、識別子と同じ識別子値が記録されているTransaction Logを検索する。
処理UT3.1.1を実行中、ホストモジュール110は処理が終了するタイミングを予測し、適切なタイミングで、プライマルセッション鍵UT再認証取得（GET PRIMAL SESSION KEY UT RECONNECTION）命令20030を発行する。Primal Deviceは、命令を受信すると、20031に示す下記の2つの処理を実行する。
処理UT3.2.1: 新しい0次セッション鍵K_s[P]0'を生成する。
処理UT3.2.2: 処理UT3.2.1で生成したK_s[P]0'を、処理UT3.1.1で見出された自身のTransaction Logに記録されているセッション鍵K_s[I]TL及びDevice公開鍵KP_d[I]TLで暗号化する。鍵K_s[I]TL及びKP_d[I]TLは、Transaction Logに記録されていた鍵データであるということを表している。最終的に得られるデータは、E(KP_d[I]TL, E(K_s[I]TL, K_s[P]0'))である。
処理UT3.2.2における暗号化を終えると、Primal Deviceは、その暗号化されたデータをホストモジュールへ送信する（20032）。
ホストモジュール110は、E(KP_d[I]TL, E(K_s[I]TL, K_s[P]0'))を受信すると、Inceptive Deviceに対して、プライマルセッション鍵UT再認証送信（PUT PRIMAL SESSION KEY UT RECONNECTION）命令20040命令を発行した後、受信したデータに20021でPrimal Deviceに対して送信したUsage Pass識別子と同一の識別子を連結し、Inceptive Deviceに送信する（20041）。
Inceptive Deviceは、E(KP_d[I]TL, E(K_s[I]TL, K_s[P]0'))を受信すると、20042に示す下記の3つの処理を実行する。
処理UT3.3.1: 保護情報領域の中で、識別子と同じ識別子値が記録されているTransaction Logを検索する。
処理UT3.3.2: 受信したデータを復号する。復号は、自身の保護情報領域に埋め込まれているK_d[I]及び処理UT3.3.1で見出されたTransaction Log中に含まれるセッション鍵K_s[I]TLである。
処理UT3.3.3: 処理UT3.3.2の結果として、K_s[P]0'が正当な形で含まれていたかどうかを確認する。確認するための手段は、処理UT1.3.3に記したものと同じである。
処理UT3.3.2が完了すると、*KP_d[I]（*K_d[I]と同じ）、K_s[P]0'の共有が完了する。以上の処理に続いてUT Transfer Stageを実行する場合、K_s[I]n-1としては、K_s[I]TLを用いる。
[UTモードにおけるUsage Pass復旧処理シークエンス]
UT Transfer StageにおいてUsage Passの移動が行われている最中に、記録再生装置に電源断などの異常が発生して、Primal DeviceからもInceptive Deviceからも転送処理中のUsage Passが失われてしまった場合や、Primal DeviceからInceptive Deviceに対して再生用のUsage Pass転送を行い、Primal DeviceにおけるUsage PassのPlay Countは減ぜられたが、Inceptive Deviceでは全く再生を実行しなかった場合などに、Primal Deviceに元来存在したUsage PassのPlay Countを伴った形で、Usage Passを復旧することができるような仕組みを設けることは有意義である。
次に、図２１を用いて、このようなUsage Pass復旧処理について説明する。UTモードにおける本処理段階のことを、以下ではUT Recovery Stageと呼ぶ。
まず、UT Transfer Stageにおいて、Inceptive Deviceがユーセジパス設定（PUT USAGE PASS）命令21000及びそれに続いてUsage Pass 21001を受信しているという状況を想定する。そして、Usage Passの受信処理が完全に完了しないうちに、異常が発生して、Primal DeviceとInceptive Deviceの間で分断が発生し、21001で流れるUsage Passを暗号化するために用いられていたセッション鍵K_s[I]が、両Deviceから失われてしまったとする（21010）。この場合、まず前節に記したUT Reconnection Stageが実行され、*KP_d[I]（*K_d[I]と同じ）、K_s[P]0'が新たに共有される。
UT Reconnection Stageを終えると、ホストモジュール110は、まずInceptive Deviceに対し、ユーセジパスUT復旧検索（SEARCH USAGE PASS UT RECOVERY）命令21020を発行する。そして、命令に続き、21001で送信中であったUsage PassのUsage Pass識別子を、送信する（21021）。
Primal Deviceは、識別子を受信すると、21022に示す4つの処理を実行する。
処理UT4.1.1: 保護情報領域の中で、識別子と同じ識別子値が記録されているTransaction Logを検索する。
処理UT4.1.2: 処理UT.4.1.1で見出されたTransaction Logに記録されていたUsage Pass Locationで指定される制限記憶部中のUsage Pass記憶領域を検索する。
処理UT4.1.3: 処理UT4.1.2で見出されたUsage Passについて、その有効性指示フラグの値を調べ、Usage Pass Statusに「有効」「無効」「未記録」のいずれかの値を設定する。
処理UT4.1.4: UTモード用Transaction Statusを生成する。Transaction Statusは、復旧対象Usage PassのUPID || Transaction Log中に記録されているSession Status || 処理UT4.1.3で設定したUsage Pass Status || Hash値である。ここでHash値は、K_s[P]0' || K_s[I]TL || UPID || Session Status || Usage Pass Statusから計算される。本処理で生成されたTransaction Statusを、以下ではUT Transaction Statusと呼ぶ。
処理UT4.1.1から処理UT4.1.4をInceptive Deviceが実行中、ホストモジュールは処理が終了するタイミングを予測し、適切なタイミングでトランザクションステータスUT復旧取得（GET TRANSACTION STATUS UT RECOVERY）命令21030を発行する。Inceptive Deviceは命令を受信すると、処理UT4.1.4において生成されたUT Transaction Statusを、ホストモジュール110へ送信する（21031）。
ホストモジュール110は、Transaction Statusを受信すると、Primal Deviceに対し、トランザクションステータスUT復旧検証（VERIFY TRANSACTION STATUS UT RECOVERY）命令21040を発行し、続いて受信したデータを送信する（21041）。送信されるデータは、UT Transaction Statusである。
Primal Deviceは、UT Transaction Statusを受信すると、21042に示す下記の３つの処理を実行する。
処理UT4.2.1: UT Transaction Statusの検証と、UT Transaction Statusに含まれるUsage Pass識別子、Session Status、Usage Pass Statusの確認を行う。UT Transaction Statusの検証は、データに含まれるHash値を、自身が保持しているK_s[P]0'とK_s[I]TLから計算することによって行う。計算結果が含まれているHash値と一致すれば、データの改竄は行われていないと判断される。また、Usage Pass識別子は、今回復旧対象のものであるどうかの確認、Session Status及びUsage Pass Statusは復旧可否を判定するために用いられる。Session StatusがRPであった場合や、Session StatusがRPであるがUsage Pass Statusが「無効」や「未記録」であった場合は、Primal Deviceにおける復旧処理（下記処理4.2.2）が行われる。
処理UT4.2.2: 保護情報領域の中で、識別子と同じ識別子値が記録されているTransaction Logを検索する。
処理UT4.2.3: Usage Pass復旧処理を実行する。Usage Passの復旧は、対象のUsage Passの有効性指示フラグが「無効」となっていた場合はそれを「有効」にし、復旧対象のUsage PassのUR_sを、処理UT4.2.2で見出されたTransaction Logに記録されていたUR_sで上書きすることによって達成される。
その後、Primal DeviceにおけるUsage Passの復旧処理が正常に終了したか否かを確認するために、ホストモジュールは、Primal Deviceに対し、CHECK EXECUTION STATUS命令21050を発行しても良い。Primal Deviceからホストモジュールへは、実行状態が21051において送信される。
処理UT4.2.2が完了すると、Primal Deviceには、送信する以前のUsage Passが存在するようになる。
[BTモードにおけるDevice間相互認証処理シークエンス]
次に、図２２を参照して、BTモードにおける、Primal DeviceとInceptive Deviceの間で相互認証を行う場合の処理シークエンスについて説明する。尚、BTモードにおける相互認証処理段階のことを、以下ではBT Connection Stageと呼ぶ。
図１１から図１３の説明でも述べたように、BTモードでは、Primal Deviceは記録再生装置内のホストセキュリティマネージャ111全体である。Managerに含まれるモジュールの中で、相互認証処理は保護情報転送モジュール内のモジュール1400が、Usage Passの送信や受信は記録モジュールと再生モジュール内のモジュール1201やモジュール1303が担う。また、Inceptive Deviceは、磁気ディスク装置内のUsage Pass転送モジュール1130である。これらの関係は、以後図２２から図２７において説明するBTモードでの各処理シークエンスにおいても同様である。
まず初めに、ホストモジュール110は、Inceptive Deviceに対してGET DEVICE CLASS CERTIFICATE命令22000を発行する。すると、Inceptive Deviceは、自身に埋め込まれているDevice Class証明書DCC（K_CA, KP_dc[I]）を、ホストモジュールへ送信する（22001）。
ホストモジュール110は、DCC（K_CA, KP_dc[I]）を受信すると、Primal Deviceに対してVERIFY DEVICE CLASS CERTIFICATE命令22010を発行し、それに続いてDCC（K_CA, KP_dc[I]）をPrimal Deviceへ送信する（22012）。
Primal Deviceは、DCC（K_CA, KP_dc[I]）を受信すると、22012に示す下記の4つの処理を実行する。
処理BT1.1.1: DCC（K_CA, KP_dc[I]）を検証する。証明書について改竄が行われていないか、及び含まれる証明書を特定する番号が自身に記録されているRDCL_[P]に載っていないか、検証する。検証方法は、UT1.1.1に記載した方法と同じである。
処理BT1.1.2: Challenge鍵K_ch[P]を生成する。
処理BT1.1.3:処理BT1.1.3で生成したK_ch[P]を、DCC（K_CA, KP_dc[I]）中のKP_dc[I]で暗号化する。この暗号方式は、公開鍵暗号化である。得られるデータは、E(KP_dc[I], K_ch[P])である。
処理BT1.1.4: 処理BT1.1.3で得られたデータに対し、自身に埋め込まれているDevice Class証明書を連結。得られるデータは、E(KP_dc[I], K_ch[P]) || DCC(K_CA, KP_dc[P])である。
Primal Deviceが処理BT1.1.1から処理BT1.1.4を実行中に、ホストモジュール110は、処理が終了するタイミングを見計らって、Primal Deviceに対し、GET PRIMAL CHALLENGE KEY BT CONNECTION命令22030を発行する。Primal Deviceは、命令を受信すると、処理B1.1.4で生成したデータを、ホストモジュールへ送信する（22031）。
ホストモジュール110は、E(KP_dc[I], K_ch[P]) || DCC(K_CA, KP_dc[P])を受信すると、Inceptive Deviceに対してPUT PRIMAL CHALLENGE KEY BT CONNECTION命令22040命令を発行後、受信したデータをInceptive Deviceに送信する（22041）。
Primal Deviceは、E(KP_dc[I], K_ch[P]) || DCC(K_CA, KP_dc[P]を受信すると、22042に示す下記の3つの処理を実行する。
処理BT1.2.1: DCC(K_CA, KP_dc[P])を検証する。検証手段は、処理UT1.1.1で説明した方法と同じである。但し、参照するRDCLは、RDCL_[I]である。
処理BT1.2.2: 受信したデータのうち、E(KP_dc[I], K_ch[P])を分離し、復号する。復号は、自身の保護情報領域に埋め込まれているK_dc[I]を用いて行う。
処理BT1.2.3: 処理BT1.2.2の結果として、K_ch[P]が正当な形で含まれていたかどうかを確認する。確認の方法は、処理UT1.3.3に記載した方法と同じである。
処理BT1.2.1から処理BT1.2.3を実行中、ホストモジュール110は、処理が終了するタイミングを予測し、適切なタイミングでGET INCEPTIVE CHALLENGE KEY BT CONNECTION命令22050を発行する。Inceptive Deviceは命令を受信すると、22051に示す下記の2つの処理を実行する。
処理BT1.3.1: Challenge鍵K_ch[I]を生成する。
処理BT1.3.2: 処理BT1.3.1で生成したK_ch[I]に対し、自身に埋め込まれているDevice公開鍵KP_d[I]を連結し、処理BT1.2.1で受信したKP_dc[P]で暗号化する。暗号化によって得られたデータに、自身に記録されているRDCL_[I]を連結し、得られたデータ全体に対するChecksumを計算し、該Checksumを該データに連結する。そして、得られたデータ全体を処理BT1.2.3で得られたK_ch[P]で暗号化する。最終的に得られるデータは、E(K_ch[P], E(KP_dc[P], K_ch[I] || KP_d[I]) || RDCL_[I] || CKS)である。
Inceptive Deviceにおいて、E(K_ch[P], E(KP_dc[P], K_ch[I] || KP_d[I]) || RDCL_[I] || CKS)が生成されると、Deviceは、生成されたデータをホストモジュールへ送信する（22052）。
ホストモジュール110は、E(K_ch[P], E(KP_dc[P], K_ch[I] || KP_d[I]) || RDCL_[I] || CKS)を受信すると、Primal Deviceに対しPUT INCEPTIVE CHALLENGE KEY BT CONNECTION命令22060を発行した後、受信したデータをPrimal Deviceへ送信する（22061）。
Primal Deviceは、E(K_ch[P], E(KP_dc[P], K_ch[I] || KP_d[I]) || RDCL_[I] || CKS)を受信すると、22062に示す下記の7つの処理を実行する。
処理BT1.4.1: 受信したデータを、K_ch[P]で復号する。K_ch[P]は、処理BT1.1.2において自身で生成された鍵である。
処理BT1.4.2: 処理UT1.4.1の結果から、RDCL_[I]を分離し、RDCL_[I]が正当な形で含まれていたかどうかを確認する。確認するための手段は、Checksum計算による構造確認、及び処理UT1.3.3に記したものと同じである。
処理BT1.4.3: 自身に記録されているRDCL_[P]と、送信されたRDCL_[I]について、それらが発行された日付情報を比較する。RDCLの発行日情報は、RDCL内に含まれるものとする。比較した結果、受信したRDCL_[I]の発行日情報が、自身に記録されているRDCL_[P]の発行日情報より新しかった場合は、RDCL_[P]をRDCL_[I]で上書きする。
処理BT1.4.4: 残りのデータE(KP_dc[P], K_ch[I] || KP_d[I])を、K_dc[P]で復号する。
処理BT1.4.5: 処理BT1.4.4で得られたデータについて、K_ch[I] || KP_d[I]が正当な形で含まれていたかどうかを確認する。確認するための手段は、処理UT1.2.3に記したものと同じである。
処理BT1.4.6: 0次セッション鍵K_s[P]0生成する。
処理BT1.4.7: 処理BT1.4.6で生成したK_s[P]0に自身に埋め込まれているDevice公開鍵KP_d[P]を連結し、処理BT1.4.5で受信したDevice公開鍵KP_d[I]で暗号化する。得られるデータはE(KP_d[I], K_s[P]0 || KP_d[P])である。ここで、処理BT1.4.3におけるRDCL_[P]とRDCL_[I]の発行日情報の比較の結果、RDCL_[P]の発行日の方が新しかった場合は、E(KP_d[I], K_s[P]0 || KP_d[P])に対しRDCL_[P]を連結し、更に得られたデータ全体についてのChecksumを計算し、連結する。その後、得られたデータ全体を処理BT1.4.5で得られたK_ch[I]で暗号化する。最終的に得られるデータは、E(K_ch[I], E(KP_d[I], K_s[P]0 || KP_d[P]) || RDCL_[P] || CKS)である。
処理BT1.4.1から処理BT1.4.7をPrimal Deviceが実行中、ホストモジュールは処理が終了するタイミングを予測し、適切なタイミングでGET PRIMAL SESSION KEY BT CONNECTION命令22071を発行する。Primal Deviceは命令を受信すると、処理BT1.4.7で生成したE(K_ch[I], E(KP_d[I], K_s[P]0 || KP_d[P]) || RDCL_[P] || CKS)を、ホストモジュールへ送信する（22071）。
ホストモジュール110は、E(K_ch[I], E(KP_d[I], K_s[P]0 || KP_d[P]) || RDCL_[P] || CKS)を受信すると、Inceptive Deviceに対してPUT PRIMAL SESSION KEY BT CONNECTION命令22080命令を発行後、受信したデータをDeviceに送信する（22081）。
Inceptive Deviceは、E(K_ch[I], E(KP_d[I], K_s[P]0 || KP_d[P]) || RDCL_[P] || CKS)を受信すると、22082に示す下記の5つの処理を実行する。
処理BT1.5.1: 受信したデータを、K_ch[I]で復号する。K_ch[I]は、処理BT1.3.1において、自身で生成した鍵データである。
処理BT1.5.2: 処理BT1.5.1の結果にRDCL_[P]が含まれていた場合、データを分離し、データが正当な形で含まれていたかどうかを確認する。確認するための手段は、Checksum計算による構造確認、及び処理UT1.3.3に記したものと同じである。
処理BT1.5.3: 処理BT1.5.1と処理BT1.5.2の結果、受信したデータにRDCL_[P]が含まれていて、それが正当な形で含まれていたことが確認できた場合、自身に記録されているRDCL_[I]を、受信したRDCL_[P]で上書きする。
処理BT1.5.4: 残りのデータE(KP_d[I], K_s[P]0 || KP_d[P])を、K_d[I]0で復号する。K_d[I]は、自身の保護情報領域に埋め込まれている。
処理BT1.5.5: 処理UT1.5.4で得られたデータについて、K_s[P]0 || KP_d[P]が正当な形で含まれていたかどうかを確認する。確認するための手段は、処理UT1.3.3に記したものと同じである。
処理BT1.5.1から処理BT1.5.5をInceptive Deviceが実行中、ホストモジュールは処理が終了するタイミングを予測し、適切なタイミングでGET INCEPTIVE SESSION KEY BT CONNECTION命令22090を発行する。Inceptive Deviceは命令を受信すると、22091に示す下記の3つの処理を実行する。
処理BT1.6.1: 0次セッション鍵K_s[I]0を生成する。
処理BT1.6.2: Connection Logに、処理BT1.5.5で受信したK_s[P]0及びKP_d[P]、処理BT1.6.1で生成したK_s[I]0、処理BT1.2.1で受信したDCC（K_CA, KP_dc[P]）に含まれていたPrimal DeviceのType Map TM_[P]を記録する。
処理BT1.6.3: 処理BT1.6.1で生成したK_s[I]0を、処理BT1.5.5で受信したK_s[P]0及びKP_d[P]で暗号化する。得られるデータは、E(KP_d[P], E(K_s[P]0, K_s[I]0))である。
Inceptive Deviceにおいて、E(KP_d[P], E(K_s[P]0, K_s[I]0))が生成されると、Deviceは、生成されたデータをホストモジュール110へ送信する（22092）。
ホストモジュール110は、E(KP_d[P], E(K_s[P]0, K_s[I]0))を受信すると、Primal Deviceに対してPUT INCEPTIVE SESSION KEY BT CONNECTION命令22100命令を発行後、受信したデータをDeviceに送信する（22101）。
Primal Deviceは、E(KP_d[P], E(K_s[P]0, K_s[I]0))を受信すると、22102に示す下記の3つの処理を実行する。
処理BT1.7.1: 受信したデータを、K_d[P]及びK_s[P]0で復号する。K_d[P]は、自身の保護情報領域に埋め込まれている鍵データであり、K_s[P]0は処理BT1.4.6において自身で生成した鍵データである。
処理UT1.7.2: 処理UT1.7.1で得られたデータについて、K_s[I]0が正当な形で含まれていたかどうかを確認する。確認するための手段は、処理UT1.3.3に記したものと同じである。
処理BT1.7.3: Connection Logに、処理BT1.4.5で受信したKP_d[I]、処理BT1.7.2で受信したK_s[I]0、処理BT1.4.6で生成したK_s[P]0、処理BT1.1.1で受信したDCC（K_CA, KP_dc[I]）に含まれていたPrimal DeviceのType Map TM_[I]を記録する。
以上処理BT1.7.3までを完了すると、共有Device公開鍵*KP_d[P]（共有Device秘密鍵*K_d[P]と同じ）、K_s[P]0、K_s[I]0の共有が完了する。
[BTモードにおけるPrimal DeviceからInceptive DeviceへのUsage Pass転送処理シークエンス]
BTモードにより、Primal DeviceとInceptive Deviceの間で相互認証が完了すると、Primal DeviceからInceptive Deviceあるいはその逆の方向に関して、Usage Passを転送することができる。
まず、Primal DeviceからInceptive DeviceへUsage Passを転送する場合について、図２３を用いて説明する。記録モジュール102がPrimal Deviceとなって、磁気ディスク装置にUsage Passを転送する場合が、その一例である。尚、BTモードにおけるPrimal DeviceからInceptive DeviceへのUsage Pass転送処理段階のことを、以下ではBT PI Transfer Stageと呼ぶ。
まず初めに、ホストモジュール110は、Primal Deviceに対してREAD USAGE PASS命令23000を発行する。そして、命令に続いて、Usage Passが記録されている場所及び読み出すUsage Passの数を、23001においてPrimal Deviceに通知する。Primal Deviceは、命令とUsage Passが記録されている場所及び読み出すUsage Passの数についての情報を受信すると、23002に示す下記の1つの処理を実行する。
処理BT2.1.1: 転送対象のUsage Passを、Usage Pass送信用モジュール内へ準備する。Primal Deviceが記録モジュールである場合、目的のUsage PassをUsage Pass Creator and Content Encrypter 606からモジュール 601へ送るような処理に相当する。
ホストモジュール110は、Primal Deviceに処理BT2.1.1を実行させている間に、Inceptive Deviceに対しCREATE INCEPTVE DEVICE SESSION KEY UT TRANSFER命令19020命令を発行する。Inceptive Deviceは、命令を受信すると、23012に示す下記の2つの処理を実行する。
処理BT2.2.1: セッション鍵K_s[I]nを生成する。ここでnは、ここでnは、BT Connection Stage完了後、本処理がn回目のBT PI Transfer Stageであることを意味する。
処理BT2.2.2: 処理BT2.2.1で生成したK_s[I]nを、1つ前のUsage Pass転送実行時に生成したセッション鍵K_s[I]n-1及びPrimal Deviceにおいて生成された最新のセッション鍵K_s[P]mを用いて、暗号化する。K_s[P]mは、Inceptive DeviceからPrimal Deviceに対してUsage Pass転送処理が実行される度に生成されるものであり、BT Connection Stageが完了してから、m回の転送処理が実行されたことを意味する。Inceptive DeviceからPrimal DeviceへのUsage Pass転送処理シークエンスの詳細は、図24を用いて後述する。もし、一度もInceptive DeviceからPrimal Deviceに対してUsage Pass転送処理が実行されていなかった場合は、BT Connection Stageにおいて共有される0次セッション鍵K_s[P]0を、K_s[P]mとして用いる。得られるデータは、E(K_s[P]m, E(K_s[I]n-1, K_s[I]n))である。
処理BT2.2.1及び処理BT2.2.2をInceptive Deviceが実行中、ホストモジュールは処理が終了するタイミングを予測し、適切なタイミングでGET INCEPIVE DEVICE SESSION KEY BT TRANSFER命令23020を発行する。Inceptive Deviceは命令を受信すると、処理BT2.2.2において生成されたデータE(K_s[P]m, E(K_s[I]n-1, K_s[I]n))を、ホストモジュールへ送信する（23021）。
ホストモジュール110は、E(K_s[P]m, E(K_s[I]n-1, K_s[I]n))を受信すると、Primal Deviceに対しPUT INCEPTIVE SESSION KEY BT TRANSFER命令22030を発行し、続いて受信したデータをPrimal Deviceへ送信する（23031）。
Primal Deviceは、E(K_s[P]m, E(K_s[I]n-1, K_s[I]n))を受信すると、23032に示す下記の3つの処理を実行する。
処理BT2.3.1: 受信したデータを、K_s[P]m及びK_s[I]n-1で復号する。両鍵データについては、処理BT2.2.2で説明した通りである。
処理BT2.3.2: 処理BT2.3.1で得られたデータについて、K_s[I]nが正当な形で含まれていたかどうかを確認する。確認するための手段は、処理UT1.3.3に記したものと同じである。
処理BT2.3.3: Transaction Logを生成する。BTモードでのUsage Pass転送処理では、Primal DeviceのみTransaction Logの記録を行う。BTモードにおけるTransaction Logの要素は、転送対象Usage PassのUsage Pass識別子、当Usage Pass転送処理におけるPrimal Deviceの役割（即ち、Usage Pass転送元「Source」であるか、同転送先「Destination」であるか）、Primal DeviceがUsage Passの転送先であった場合のみ受信予定のUsage Passの受信以前のUR_s、Primal DeviceがUsage Passの転送元であった場合のみ送信予定のUsage Passの送信以前のUsage Pass、Primal DeviceがUsage Passの転送先であった場合は同転送元におけるUsage Pass Location（読み出し元のアドレス）、Primal DeviceがUsage Passの転送元であった場合は同転送先におけるUsage Pass Location（記録先のアドレス）である。それらのうち、ここで記録されるのは、転送対象Usage PassのUsage Pass識別子、このUsage Pass転送処理におけるPrimal Deviceの役割「Source」（図中では短縮形「S」）、送信対象Usage Passの送信前の当該Usage Pass、Usage PassのUsage Pass Location（記録先アドレス）である。
処理BT2.3.1から処理BT2.3.3をPrimal Deviceが実行中、ホストモジュールは処理が終了するタイミングを予測し、適切なタイミングでENCRYPT USAGE PASS COPYあるいはENCRYPT USAGE PASS MOVEあるいはENCRYPT USAGE PASS PLAY命令23040を発行する。命令に続き、Inceptive DeviceへのUsage Passの記録先アドレス情報を、23041においてPrimal Deviceに対し送信する。尚、UTモードの場合と同様、どの命令を受信した場合にどのようなUR_sのUsage Passを送信するか、そして複製や再生の場合Primal Deviceに残るUsage PassのUR_sはどのように変更しなければならないか等については、あらかじめ全て規定されているものとする。そこで、命令を受信すると、Primal Deviceは、23042に示す下記の3つの処理を実行する。
処理BT2.4.1: Inceptive Deviceに対して送信するUsage Passを、処理BT2.1.1においてUsage Pass送信用モジュール内に準備されたUsage Passを元に、生成する。通常、UPIDやK_cなどはそのまま複製され、UR_sのみ規定に従う形で変更される。
処理BT2.4.2: Transaction LogにおけるUsage Pass Locationに、23041で受信したInceptive DeviceでのUsage Passの記録先アドレスを記録する。
処理BT2.4.3: 処理BT2.4.1において生成された送信用Usage Passに対し、受信した命令がENCRYPT USAGE PASS COPY/MOVE/PLAYのいずれであるかを示す識別子情報Action Indicator、及びUsage Pass || Action Indicatorに対するChecksumを計算し、連結する。連結処理の後、得られたデータをK_s[I]n及び*KP_d[I]を用いて暗号化する。即ち、共通鍵による二重暗号化である。得られるデータは、E(*KP_d[I], E(K_s[I]n, Usage Pass || Action Indicator || Checksum))である。Checksumの計算は、UT2.4.2に記載した通りである。
処理BT2.4.1から処理BT2.4.3をPrimal Deviceが実行中、ホストモジュールは処理が終了するタイミングを予測し、適切なタイミングでGET USAGE PASS命令23050を発行する。Primal Deviceは、命令を受信すると、E(*KP_d[I], E(K_s[I]n, Usage Pass || Action Indicator || Checksum))をホストモジュールへ送信する（23052）。
ホストモジュール110はE(*KP_d[I], E(K_s[I]n, Usage Pass || Action Indicator || Checksum))を受信すると、Inceptive Deviceに対しPUT USAGE PASS命令23060を発行し、続いてE(*KP_d[I], E(K_s[I]n, Usage Pass || Action Indicator || Checksum))を送信する（23061）。
Inceptive Deviceは、命令及びデータを受信すると、23062に示す下記の3つの処理を実行する。
処理BT2.5.1: 受信したデータを、*K_d[I]及びK_s[I]nで復号する。*K_d[I]は、処理BT1.5.4において得た共通鍵である。また、K_s[I]nは処理BT2.2.1において自身で生成したセッション鍵である。
処理BT2.5.2: 処理UT2.5.1で得られたデータについて、Usage Pass || Action Indicator || Checksumが正当な形で含まれていたかどうかを確認する。確認は、Checksumを検証すること及び処理UT1.3.3に記した手段を用いて行われる。Checksumによる検証方法は、処理UT2.4.2に記載してある。
処理UT2.5.3: 受信したUsage Passを制限記憶部へ記録する。Usage Passの記録を行う際には、有効性指示フラグを「有効」に設定する。
その後、Inceptive Deviceにおける制限記憶部223へのUsage Passの記録が正常に終了したか否かを確認するために、ホストモジュールは、Inceptive Deviceに対し、CHECK EXECUTION STATUS命令23070を発行しても良い。Inceptive Deviceからホストモジュールへは、実行状態が23071において送信される。
以上に記したBT Transfer Stageを繰り返すことにより、Connection Stageを繰り返し行わなくても、Primal DeviceからInceptive Deviceに対し、連続的にUsage Pass転送を実行することができる。
[BTモードにおけるInceptive DeviceからPrimal DeviceへのUsage Pass転送処理シークエンス]
次に、図２４を参照して、Inceptive DeviceからPrimal DeviceへUsage Passを転送する場合について説明する。磁気ディスク装置がPrimal Deviceとなって、再生モジュール104にUsage Passを転送する場合が、その一例である。尚、BTモードにおけるInceptive DeviceからPrimal DeviceへのUsage Pass転送処理段階のことを、以下ではBT IP Transfer Stageと呼ぶ。
まず初めに、ホストモジュール110は、Inceptive Deviceに対してREAD USAGE PASS命令24000を発行する。そして、この命令に続いて、Usage Passが記録されている場所及び読み出すUsage Passの数を、24001においてPrimal Deviceに通知する。Inceptive Deviceは、この命令とUsage Passが記録されている場所及び読み出すUsage Passの数についての情報を受信すると、24002に示す下記の1つの処理を実行する。
処理BT3.1.1: 制限記憶部において指定されたアドレスから転送対象のUsage Passを読み出し、Usage Pass Buffer 1110へ送信する。
処理BT3.1.1をInceptive Deviceが実行中、ホストモジュールは処理が終了するタイミングを予測し、適切なタイミングで、Primal Deviceに対し、GET MASKED USAGE PASS WITH KEYED HASH命令24010を発行する。Inceptive Deviceは、命令を受信すると、24011に示す下記の2つの処理を実行する。
処理BT3.2.1: READ USAGE PASS命令24000で制限記憶部から読み出したUsage PassからMasked Usage Passを生成し、それに対しGET MASKED USAGE PASS WITH KEYED HASH命令24010を受信した時点で最新のセッション鍵K_s[P]m-1及びK_s[I]nを連結したデータを元に、Hash値を計算する。命令24000で複数のUsage Passを一度に読み出している場合は、個々のUsage Passに対してHash値を計算する。
処理BT3.2.2: 処理BT3.2.1で生成した個々のHash値を、個々のMasked Usage Passに連結する。得られるデータは、MUP || H(K_s[P]m-1 || K_s[I]n || MUP)である。
Inceptive Deviceは処理BT3.2.2を終えると、生成されたデータMUP || H(K_s[P]m-1 || K_s[I]n || MUP)を、ホストモジュールへ送信する（24012）。
ホストモジュール110は、MUP || H(K_s[P]m-1 || K_s[I]n || MUP)受信すると、Primal Deviceに対し、PUT MASKED USAGE PASS WITH KEYED HASH命令を発行し、続いてデータをPrimal Deviceへ送信する。
Primal Deviceは、データを受信すると、24022に示す下記の1つの処理を実行する。
処理BT3.3.1: 受信したデータについて、改竄が行われていないかどうかを検証する。自身が保持しているセッション鍵K_s[P]m-1及びK_s[I]n及び受信したMUPを用いてHash値H(K_s[P]m-1 || K_s[I]n || MUP)を計算し、それが受信したHasht値と一致していれば、改竄が行われていないと判断する。
処理BT3.3.1をPrimal Deviceが実行中、ホストモジュールは処理が終了するタイミングを予測し、適切なタイミングで、Primal Deviceに対し、CREATE PRIMAL SESSION KEY BT TRANSFER命令24030を発行し、続いて転送対象Usage PassのUsage Pass識別子を送信する（24031）。
Primal Deviceは、命令及びデータを受信すると、24032に示す下記の4つの処理を実行する。
処理BT3.4.1: 24031で受信したUsage Pass識別子と、24021で受信したMasked Usage PassのUsage Pass識別子が一致しているか確認する。
処理BT3.4.2: Transaction Logを生成する。ここで記録されるのは、転送対象Usage PassのUsage Pass識別子、当Usage Pass転送処理におけるPrimal Deviceの役割「Destination」（図中では短縮形「D」）、24021で受信したMasked Usage Pass中に含まれるUR_s、Inceptive Device中の制限記憶部におけるUsage Pass Location（記録元アドレス）である。
処理BT3.4.3: セッション鍵K_s[P]mを生成する。ここでmは、BT Connection Stage完了後、m回目のBT IP Transfer Stageにおいて生成されたセッション鍵であることを意味する。
処理BT3.4.4: 処理BT3.4.3で生成したK_s[P]mを、1つ前のUsage Pass転送実行時に生成したセッション鍵K_s[P]m-1及びInceptive Deviceにおいて生成された最新のセッション鍵K_s[P]nを用いて、暗号化する。K_s[I]nは、BT PI Transfer Stageが実行される度に生成されるものであり、BT Connection Stageが完了してから、n回の転送処理が実行されたことを意味する。尚、BT PI Transfer Stageについては、図23を用いて前節で説明済みである。もし、一度もPrimal DeviceからInceptive Deviceに対してUsage Pass転送処理が実行されていなかった場合は、BT Connection Stageにおいて共有される0次セッション鍵K_s[I]0を、K_s[I]nとして用いる。得られるデータは、E(K_s[I]n, E(K_s[P]m-1, K_s[P]m))である。
処理BT3.4.1から処理BT3.4.4をPrimal Deviceが実行中、ホストモジュールは処理が終了するタイミングを予測し、適切なタイミングでGET PRIMAL SESSION KEY BT TRANSFER命令24040を発行する。Primal Deviceは命令を受信すると、処理BT3.4.4において生成されたデータを、ホストモジュールへ送信する（24041）。
ホストモジュール110は、E(K_s[I]n, E(K_s[P]m-1, K_s[P]m))を受信すると、Inceptive Deviceに対しPUT PRIMAL SESSION KEY BT TRANSFER命令24050を発行後、受信したデータをInceptive Deviceへ送信する（24051）。
Inceptive Deviceは、E(K_s[I]n, E(K_s[P]m-1, K_s[P]m))を受信すると、24052に示す下記の2つの処理を実行する。
処理BT3.5.1: 受信したデータを、K_s[I]n及びK_s[P]m-1で復号する。両鍵データについては、処理BT3.2.1及び処理BT3.4.4で説明した通りである。
処理BT3.5.2: 処理UT3.5.1で得られたデータについて、K_s[P]mが正当な形で含まれていたかどうかを確認する。確認するための手段は、処理UT1.3.3に記したものと同じである。
処理BT3.5.1及び処理BT3.5.2をInceptive Deviceが実行中、ホストモジュールは処理が終了するタイミングを予測し、適切なタイミングでENCRYPT USAGE PASS COPYあるいはENCRYPT USAGE PASS MOVEあるいはENCRYPT USAGE PASS PLAY命令24060を発行する。尚、UTモードの場合と同様に、どの命令を受信した場合にどのようなUR_sのUsage Passを送信するか、そして複製や再生の場合Primal Deviceに残るUsage PassのUR_sはどのように変更しなければならないか等については、あらかじめ全て規定されているものとする。
そこで、この命令を受信すると、Inceptive Deviceは、24062に示す下記の2つの処理を実行する。
処理BT3.6.1: Primal Deviceに対して送信するUsage Passを、処理BT3.1.1においてUsage Pass Bufferへ送信されたUsage Passを元に、モジュール 1103内に生成する。通常、UPIDやK_cなどはそのまま複製され、UR_sのみ規定に従う形で変更される。
処理BT3.6.2: 処理BT3.6.1において生成された送信用Usage Passに対し、受信した命令がENCRYPT USAGE PASS COPY/MOVE/PLAYのいずれであるかを示す識別子情報Action Indicator、及びUsage Pass || Action Indicatorに対するChecksumを計算し、連結する。連結処理の後、得られたデータをK_s[P]m及び*KP_d[P]を用いて暗号化する。即ち、共通鍵による二重暗号化である。得られるデータは、E(*KP_d[P], E(K_s[P]m, Usage Pass || Action Indicator || Checksum))である。Checksumの計算は、UT2.4.2に記載した通りである。
以上、処理BT3.6.1及び処理BT3.6.2をInceptive Deviceが実行中、ホストモジュールは、処理が終了するタイミングを予測し、適切なタイミングでGET USAGE PASS命令24070を発行する。Inceptive Deviceは、命令を受信すると、24071に示す下記の1つの処理を実行する。
処理BT3.7.1: Usage Pass Buffer中のUsage PassのUR_sを、規定に従って変更する。そして、Usage PassをUsage Passが制限記憶部中で元来記録されていた場所に、上書きする。尚、命令24060がENCRYPT USAGE PASS MOVEであった場合、有効性指示フラグの値は「無効」にされる。
Inceptive Deviceは、処理BT3.7.1を終了すると、処理で生成されたデータを、ホストモジュールへ送信する（24072）。
ホストモジュール110はE(*KP_d[P], E(K_s[P]m, Usage Pass || Action Indicator || Checksum))を受信すると、Primal Deviceに対しPUT USAGE PASS命令24080を発行し、またDeviceに対し、E(*KP_d[P], E(K_s[P]m, Usage Pass || Action Indicator || Checksum))を送信する（24081）。
Inceptive Deviceは、命令及びデータを受信すると、24082に示す下記の2つの処理を実行する。
処理BT3.8.1: 受信したデータを、*K_d[P]及びK_s[P]mで復号する。*K_d[P]は、処理BT1.7.1において得た共通鍵である。また、K_s[P]mは処理BT3.4.3において自身で生成したセッション鍵である。
処理BT3.8.2: 処理UT3.8.1で得られたデータについて、Usage Pass || Action Indicator || Checksumが正当な形で含まれていたかどうかを確認する。確認は、Checksumを検証すること及び処理UT1.3.3に記した手段を用いて行われる。Checksumによる検証方法は、処理UT2.4.2に記載した通りである。
その後、Inceptive DeviceにおけるUsage Passの受信が正常に終了したか否かを確認するために、ホストモジュールは、Primal Deviceに対し、CHECK EXECUTION STATUS命令24090を発行しても良い。Primal Deviceからホストモジュールへは、実行状態が24091において送信される。
以上に記したBT Transfer Stageを繰り返すことにより、Connection Stageを繰り返し行わなくても、Inceptive DeviceからPrimal Deviceに対し、連続的にUsage Pass転送を実行することができる。
[BTモードにおけるDevice間再相互認証処理シークエンス]
Primal DeviceとInceptive Deviceの間で1度BT Connection Stageが行われ、両Deviceの間で互いの共有Device公開鍵KP_d[P]及びKP_d[I]、0次セッション鍵K_s[P]0及びK_s[I]0、の共有及び鍵のConnection Logへの記録が終了した後、記録再生装置に電源供給停止等の異常が発生して、Usage Pass送信用モジュール及び同受信用モジュールからセッション鍵が失われてしまった場合、Connection Stageと比べ、少ない処理で相互認証を再完了することができる。この再相互認証処理について、図２５を用いて説明する。尚、BTモードにおける本処理段階のことを、以下ではBT Reconnection Stageと呼ぶ。
まず、BT Connection Stageが25000において完了した後、異常発生の理由により、Primal DeviceとInceptive Deviceの間で分断が発生し、その時点までで最新のセッション鍵K_s[P]m及びK_s[I]nや、共有Device公開鍵*KP_d[P]や*KP_d[I]が、両Deviceから失われてしまったとする（25010）。
この場合、ホストモジュール110は、まずPrimal Deviceに対し、CREATE PRIMAL SESSION KEY BT RECONNECTION命令25010を発行する。
Primal Deviceは、命令を受信すると、25011に示す下記の2つの処理を実行する。
処理BT4.1.1: 新しい0次セッション鍵K_s[P]0'を生成する。
処理BT4.1.2: 処理BT4.1.1で生成したK_s[P]0'を、自身のConnection Logに記録されているセッション鍵K_s[I]CL及びDevice公開鍵KP_d[I]CLで暗号化する。鍵K_s[I]CL及びKP_d[I]CLは、Connection Logに記録されていた鍵データであるということを表している。最終的に得られるデータは、E(KP_d[I]CL, E(K_s[I]CL, K_s[P]0'))である。
処理BT4.1.1及び処理BT4.1.2を実行中、ホストモジュールは処理が終了するタイミングを予測し、適切なタイミングでGET PRIMAL SESSION KEY BT RECONNECTION命令25020を発行する。Primal Deviceは、命令を受信すると、処理BT4.1.2で生成したデータE(KP_d[I]CL, E(K_s[I]CL, K_s[P]0'))を、ホストモジュールへ送信する。
ホストモジュール110は、E(KP_d[I]CL, E(K_s[I]CL, K_s[P]0'))を受信すると、Inceptive Deviceに対してPUT PRIMAL SESSION KEY BT RECONNECTION命令25030命令を発行した後、受信したデータをInceptive Deviceに送信する（25031）。
Inceptive Deviceは、E(KP_d[I]CL, E(K_s[I]CL, K_s[P]0'))を受信すると、25032に示す下記の2つの処理を実行する。
処理BT4.2.1: 受信したデータを復号する。復号は、自身の保護情報領域に埋め込まれているK_d[I]及びConnection Log中に含まれるセッション鍵K_s[I]CLである。
処理BT4.2.2: 処理UT4.2.1の結果として、K_s[P]0'が正当な形で含まれていたかどうかを確認する。確認するための手段は、処理UT1.3.3に記したものと同じである。
処理BT4.2.1及び処理BT4.2.2を実行中、ホストモジュールは処理が終了するタイミングを予測し、適切なタイミングでGET INCEPTIVE SESSION KEY BT RECONNECTION命令25040を発行する。Inceptive Deviceは、命令を受信すると、25041に示す下記の3つの処理を実行する。
処理BT4.3.1: 新しい0次セッション鍵K_s[I]0'を生成する。
処理BT4.3.2: 処理BT4.3.1で生成したK_s[I]0'を、自身のConnection Logに記録されているセッション鍵K_s[P]CL及びDevice公開鍵KP_d[P]CLで暗号化する。鍵K_s[P]CL及びKP_d[P]CLは、Connection Logに記録されていた鍵データであるということを表している。最終的に得られるデータは、E(KP_d[P]CL, E(K_s[P]CL, K_s[I]0'))である。
処理BT4.3.3: 処理BT4.2.2で受信したK_s[P]0'、処理BT4.3.1で生成したK_s[I]0'を、Connection Logに上書き記録する。KP_d[P]及びTM_[P]は、そのまま保持する。
Inceptive Deviceは、処理BT4.3.3を終了すると、処理BT4.3.2で生成したデータE(KP_d[P]CL, E(K_s[P]CL, K_s[I]0'))をホストモジュールへ送信する（25040）。
ホストモジュール110は、E(KP_d[P]CL, E(K_s[P]CL, K_s[I]0'))を受信すると、Primal Deviceに対してPUT INCEPTIVE SESSION KEY BT RECONNECTION命令25050命令を発行後、受信したデータをPrimal Deviceに送信する（25051）。
Primal Deviceは、E(KP_d[P]CL, E(K_s[P]CL, K_s[I]0'))を受信すると、25052に示す下記の3つの処理を実行する。
処理BT4.4.1: 受信したデータを復号する。復号は、自身の保護情報領域に埋め込まれているK_d[P]及びConnection Log中に含まれるセッション鍵K_s[P]CLである。
処理BT4.4.2: 処理UT4.4.1の結果として、K_s[I]0'が正当な形で含まれていたかどうかを確認する。確認するための手段は、処理UT1.3.3に記したものと同じである。
処理BT4.4.3: 処理BT4.4.2で受信したK_s[I]0'、処理BT4.1.1で生成したK_s[P]0'を、Connection Logに上書き記録する。KP_d[I]及びTM_[I]は、そのまま保持する。
処理UT4.4.3が完了すると、*KP_d[P]（*K_d[P]と同じ）、*KP_d[I]（*K_d[I]と同じ）、K_s[P]0'、K_s[I]0'の共有が完了する。以上の処理に続いてBT PI Transfer Stageを実行する場合、K_s[I]n-1としては、K_s[I]0'を、BT IP Transfer Stageを実行する場合、K_s[P]m-1としてはK_s[P]0'を用いる。
[BT PI Transfer Stageに対するUsage Pass復旧処理シークエンス]
BT PI Transfer StageにおいてUsage Passの移動が行われている最中に、記録再生装置に異常が発生して、Primal DeviceからもInceptive Deviceからも転送処理中のUsage Passが失われてしまった場合、Primal Deviceにおいて、元来存在したものと同じUR_sを伴った形で、Usage Passを復旧する。このUsage Pass復旧処理について、図２６を用いて説明する。BTモードにおける本処理段階のことを、以下ではBT PI Recovery Stageと呼ぶ。
まず、BT PI Transfer Stageにおいて、Inceptive DeviceがPUT USAGE PASS命令26010及びそれに続いてUsage Pass 26011を受信しているという状況を想定する。そして、Usage Passの受信処理が完全に完了しないうちに、異常が発生して、Primal DeviceとInceptive Deviceの間で分断が生じ、26011で流れるUsage Passを暗号化するために用いられていたセッション鍵K_s[I]n及び*KP_d[I]（*K_d[I]）が、両Deviceから失われてしまったとする（26020）。この場合、まず前節で説明したBT Reconnection Stageが実行され、*KP_d[P]（*K_d[P]と同じ）、*KP_d[I]（*K_d[I]と同じ）、K_s[P]0'、K_s[I]0'が新たに共有される。
BT Reconnection Stageを終えると、ホストモジュール110は、まずPrimal Deviceに対し、SEARCH TRANSACTION LOG BT RECOVERY命令26030を発行する。そして、命令に続き、21011で送信中であったUsage PassのUsage Pass識別子を、送信する（26031）。
Primal Deviceは、識別子を受信すると、26032に示す下記の1つの処理を実行する。
処理BT5.1.1: 保護情報領域の中で、識別子と同じ識別子値が記録されているTransaction Logを検索する。
処理BT5.1.1をPrimal Deviceが実行中、ホストモジュールは処理が終了するタイミングを予測し、適切なタイミングでGET USAGE PASS LOCATION命令26040を発行する。命令を受信すると、Primal Deviceは、処理BT5.1.1で見出されたTransaction Log中に記録されているUsage Pass Location情報を、ホストモジュールへ送信する（26041）。
ホストモジュール110は、Usage Pass Location情報を受信すると、Inceptive Deviceに対し、SEARCH USAGE PASS BT RECOVERY命令26050を発行し、続いて受信したデータを送信する（26051）。
Inceptive Deviceは、Usage Pass Location情報を受信すると、26052に示す下記の３つの処理を実行する。
処理BT5.2.1: 制限記憶部において、受信したUsage Pass Locationで指定される制限記憶部中のUsage Pass記憶領域を検索する。
処理BT5.2.2: 処理UT5.2.1で見出されたUsage Passについて、その有効性指示フラグの値を調べ、Usage Pass Statusに「有効」「無効」「未記録」のいずれかの値を設定する。
処理BT5.2.3: BTモード用Transaction Statusを生成する。Transaction Statusは、復旧対象Usage PassのUPID || 処理BT5.2.1で見出されたUsage PassのUR_s || 処理BT5.2.2で設定したUsage Pass Status || 26041で受信したUsage Pass Location || Hash値である。ここでHash値は、K_s[P]m || K_s[I]n || UPID || UR_s || Usage Pass Status || Usage Pass Locationから計算される。ここで用いられるK_s[P]m |及びK_s[I]nは、Connection StageあるいはReconnection Stage完了後、その時点で共有されている最新のセッション鍵である。Stage完了後、m回のBT PI Transfer Stage及びn回のBT IP Transfer Stageが実行されたことを意味している。本処理で生成されるTransaction Statusを、以下ではBT PI Transaction Statusと呼ぶ。
処理BT5.2.1から処理BT5.2.3をInceptive Deviceが実行中、ホストモジュールは処理が終了するタイミングを予測し、適切なタイミングでGET TRANSACTION STATUS BT RECOVERY命令26060を発行する。命令を受信すると、Inceptive Deviceは、処理BT5.2.3で生成されたBT PI Transaction Statusを、ホストモジュールへ送信する（26061）。
ホストモジュール110は、BT PI Transaction Statusを受信すると、Primal Deviceに対し、VERIFY TRANSACTION STATUS BT PI RECOVERY命令26070を発行し、続いて受信したBT PI Transaction Statusを送信する（26071）。
Primal Deviceは、BT PI Transaction Statusを受信すると、26072に示す下記の２つの処理を実行する。
処理BT5.3.1: BT PI Transaction Statusの検証と、BT PI Transaction Statusに含まれるUsage Pass識別子、Usage Pass Status、Usage Pass Locationの確認を行う。BT PI Transaction Statusの検証は、データに含まれるHash値を、自身が保持しているK_s[P]mとK_s[I]nから計算することによって行う。計算結果が含まれているHash値と一致すれば、データの改竄は行われていないと判断される。また、Usage Pass識別子は、今回復旧対象のものであるどうかの確認、Usage Pass Statusは復旧可否の判定、Usage Pass Locationは自身に記録されていたUsage Pass Locationで指定される制限記憶部内のUsage Pass記憶領域を正しく検索したかを確認するために用いられる。Usage Pass Statusが「無効」や「未記録」であった場合は、Primal Deviceにおいて、Usage Passの復旧処理が行われる。一方、Usage Pass Locationが、自身のTransaction Logに記録されていたものと異なっていた場合は、Usage Passの復旧処理は行われない。
処理UT5.3.2: Usage Pass復旧処理を実行する。Usage Passの復旧は、対象のUsage Passの有効性指示フラグが「無効」となっていた場合はそれを「有効」にし、復旧対象のUsage Passを、Transaction Logに記録されていたUsage Passで上書きすることによって達成される。
処理BT5.3.2が完了すると、Primal Deviceには、送信する以前のUsage Passが存在するようになる。
[BT IP Transfer Stageに対するUsage Pass復旧処理シークエンス]
BT IP Transfer StageにおいてUsage Passの移動が行われている最中に、記録再生装置に異常が発生して、Primal DeviceからもInceptive Deviceからも転送処理中のUsage Passが失われてしまった場合、Inceptive Deviceにおいて、元来存在したものと同じUR_sを伴った形で、Usage Passを復旧することができる。このUsage Pass復旧処理について、図２７を用いて説明する。BTモードにおける本処理段階のことを、以下ではBT IP Recovery Stageと呼ぶ。
まず、BT IP Transfer Stageにおいて、Primal DeviceがPUT USAGE PASS命令27010及びそれに続いてUsage Pass 27011を受信しているという状況を想定する。そして、Usage Passの受信処理が完全に完了しないうちに、異常が発生して、Primal DeviceとInceptive Deviceの間で分断が生じ、27001で流れるUsage Passを暗号化するために用いられていたセッション鍵K_s[P]n及び*KP_d[P]（*K_d[P]）が、両Deviceから失われてしまったとする（27020）。この場合、まず前節に記したBT Reconnection Stageが実行され、*KP_d[P]（*K_d[P]と同じ）、*KP_d[I]（*K_d[I]と同じ）、K_s[P]0'、K_s[I]0'が新たに共有される。
BT Reconnection Stageを終えると、ホストモジュールは、まずPrimal Deviceに対し、SEARCH TRANSACTION LOG BT RECOVERY命令27030を発行する。そして、命令に続き、27011で送信中であったUsage PassのUsage Pass識別子を、送信する（27031）。
Primal Deviceは、識別子を受信すると、27032に示す下記の1つの処理を実行する。
処理BT6.1.1: 保護情報領域の中で、識別子と同じ識別子値が記録されているTransaction Logを検索する。
処理BT6.1.1をPrimal Deviceが実行中、ホストモジュールは処理が終了するタイミングを予測し、適切なタイミングでGET USAGE PASS LOCATION命令26040を発行する。命令を受信すると、Primal Deviceは、処理BT6.1.1で見出されたTransaction Log中に記録されているUsage Pass Location情報を、ホストモジュールへ送信する（27041）。
ホストモジュール110は、Usage Pass Location情報を受信すると、Inceptive Deviceに対し、SEARCH USAGE PASS BT RECOVERY命令27050を発行し、続いて受信したデータを送信する（27051）。
Inceptive Deviceは、Usage Pass Location情報を受信すると、27052に示す下記の３つの処理を実行する。
処理BT6.2.1: 制限記憶部において、受信したUsage Pass Locationで指定される制限記憶部中のUsage Pass記憶領域を検索する。
処理BT6.2.2: 処理UT6.2.1で見出されたUsage Passについて、その有効性指示フラグの値を調べ、Usage Pass Statusに「有効」「無効」「未記録」のいずれかの値を設定する。
処理BT6.2.3: BTモード用Transaction Statusを生成する。Transaction Statusは、復旧対象Usage PassのUPID || 処理BT6.2.1で見出されたUsage PassのUR_s || 処理BT6.2.2で設定したUsage Pass Status || 27041で受信したUsage Pass Location || Hash値である。ここでHash値は、K_s[P]m || K_s[I]n-1 || UPID || UR_s || Usage Pass Status || Usage Pass Locationから計算される。ここで用いられるK_s[P]m |及びK_s[I]n-1は、Connection StageあるいはReconnection Stage完了後、その時点で共有されている最新のセッション鍵である。Stage完了後、m回のBT PI Transfer Stage及びn-1回のBT IP Transfer Stageが実行されたことを意味している。本処理で生成されるTransaction Statusを、以下ではBT IP Transaction Statusと呼ぶ。
処理BT6.2.1から処理BT6.2.3をInceptive Deviceが実行中、ホストモジュールは処理が終了するタイミングを予測し、適切なタイミングでGET TRANSACTION STATUS BT RECOVERY命令27060を発行する。命令を受信すると、Inceptive Deviceは、処理BT6.2.3で生成されたBT IP Transaction Statusを、ホストモジュールへ送信する（27061）。
ホストモジュール110は、BT IP Transaction Statusを受信すると、Primal Deviceに対し、VERIFY TRANSACTION STATUS BT IP RECOVERY命令27070を発行し、続いて受信したBT IP Transaction Statusを送信する（27071）。
Primal Deviceは、BT IP Transaction Statusを受信すると、27072に示す下記の1つの処理を実行する。
処理BT6.3.1: BT IP Transaction Statusの検証と、BT IP Transaction Statusに含まれるUsage Pass識別子、UR_s、Usage Pass Status、Usage Pass Locationの確認を行う。BT IP Transaction Statusの検証は、データに含まれるHash値を、自身が保持しているK_s[P]mとK_s[I]n-1から計算することによって行う。計算結果が含まれているHash値と一致すれば、データの改竄は行われていないと判断される。また、Usage Pass識別子は、今回復旧対象のものであるどうかの確認、UR_s及びUsage Pass Statusは復旧可否の判定、Usage Pass Locationは自身に記録されていたUsage Pass Locationで指定される制限記憶部内のUsage Pass記憶領域を正しく検索したかを確認するために用いられる。Usage Pass Statusが「無効」であったり、BT IP Transaction Statusに含まれるUR_sを処理BT6.1.1で見出されたTransaction Logに記録されているUR_sに照らし合わせた結果、Inceptive Deviceに残っている目的のUsage PassのUR_sが変化してしまっていることが判明したりした場合は、以降のUsage Pass復旧処理が実行される。
処理BT6.3.1をPrimal Deviceが実行中、それに並列して、ホストモジュール110はCREATE INCEPTIVE SESSION KEY BT TRANSFER命令27080を発行する。
Inceptive Deviceは、命令を受信すると、27081に示す下記の2つの処理を実行する。
処理BT6.4.1: セッション鍵K_s[I]nを生成する。ここでnは、ここでnは、BT Connection Stage完了後、本処理がn回目のBT IP Transfer Stageであることを意味する。
処理BT6.4.2: 処理BT6.4.1で生成したK_s[I]nを、1つ前のUsage Pass転送実行時に生成したセッション鍵K_s[I]n-1及びPrimal Deviceにおいて生成された最新のセッション鍵K_s[P]mを用いて、暗号化する。K_s[P]mは、BT Connection Stageが完了してから、m回のBT IP Transfer Stageが実行されたことを意味する。もし、一度もInceptive DeviceからPrimal Deviceに対してUsage Pass転送処理が実行されていなかった場合は、BT Reconnection Stageにおいて共有される0次セッション鍵K_s[P]0'を、K_s[P]mとして用いる。得られるデータは、E(K_s[P]m, E(K_s[I]n-1, K_s[I]n))である。
処理BT6.4.1及び処理BT6.4.2をInceptive Deviceが実行中、ホストモジュールは処理が終了するタイミングを予測し、適切なタイミングでGET INCEPIVE DEVICE SESSION KEY BT TRANSFER命令27090を発行する。Inceptive Deviceは命令を受信すると、処理BT6.4.2において生成されたデータE(K_s[P]m, E(K_s[I]n-1, K_s[I]n))を、ホストモジュールへ送信する（27091）。
ホストモジュール110は、E(K_s[P]m, E(K_s[I]n-1, K_s[I]n))を受信すると、Primal Deviceに対しPUT INCEPTIVE SESSION KEY BT RETRANSFER命令27100を発行し、続いて受信したデータをPrimal Deviceへ送信する（27101）。
Primal Deviceは、E(K_s[P]m, E(K_s[I]n-1, K_s[I]n))を受信し、処理BT6.3.1においてInceptive Device中のUsage Passの復旧処理が必要であることが判明すると、27102に示す下記の2つの処理を実行する。
処理BT6.5.1: 受信したデータを、K_s[P]m及びK_s[I]n-1で復号する。両鍵データについては、処理BT6.2.3で説明した通りである。
処理BT6.5.2: 処理BT6.5.1で得られたデータについて、K_s[I]nが正当な形で含まれていたかどうかを確認する。確認するための手段は、処理UT1.3.3に記したものと同じである。
処理BT6.5.1及び処理BT6.5.2をPrimal Deviceが実行中、ホストモジュールは処理が終了するタイミングを予測し、適切なタイミングでENCRYPT USAGE PASS RECOVER命令27110を発行する。命令を受信すると、Primal Deviceは、27111に示す下記の2つの処理を実行する。
処理BT6.6.1: 処理BT6.2.1で見出されたTransaction Logに記録されているUPIDとUR_sを連結し、Usage Pass送信用モジュール1301へ送信する。
処理BT6.6.2: 処理BT6.6.1においてUsage Pass送信用モジュール 1301に準備されたUPID || UR_sについて、Checksumを計算し、データに連結する。そして、得られたデータを、K_s[I]n及び*KP_d[I]を用いて暗号化する。即ち、共通鍵による二重暗号化である。得られるデータは、E(*KP_d[I], E(K_s[I]n, UPID || UR_s || Checksum))である。Checksumの計算は、UT2.4.2に記載した通りである。
処理BT6.6.1及び処理BT6.6.2をPrimal Deviceが実行中、ホストモジュールは処理が終了するタイミングを予測し、適切なタイミングでGET RECOVER USAGE PASS命令27120を発行する。Primal Deviceは、命令を受信すると、E(*KP_d[I], E(K_s[I]n, UPID || UR_s || Checksum))をホストモジュールへ送信する（27121）。
ホストモジュール110はE(*KP_d[I], E(K_s[I]n, UPID || UR_s || Checksum))を受信すると、Inceptive Deviceに対しRECOVER USAGE PASS命令27130を発行し、続いてE(*KP_d[I], E(K_s[I]n, UPID || UR_s || Checksum))及びデータの書き込み先Usage Pass Locationを送信する（27131）。
Inceptive Deviceは、命令及びデータを受信すると、23062に示す下記の4つの処理を実行する。
処理BT6.7.1: 受信したデータE(*KP_d[I], E(K_s[I]n, UPID || UR_s || Checksum))を、*K_d[I]及びK_s[I]nで復号する。*K_d[I]は、Reconnection Stage 27021において得た共通鍵である。また、K_s[I]nは処理BT6.4.1において自身で生成したセッション鍵である。
処理BT6.7.2: 処理BT6.7.1で得られたデータについて、UPID || UR_s || Checksumが正当な形で含まれていたかどうかを確認する。確認は、Checksumを検証すること及び処理UT1.3.3に記した手段を用いて行われる。Checksumによる検証方法は、処理UT2.4.2に記載してある。
処理BT6.7.3: 受信したUsage Pass Locationで指定される制限記憶部のUsage Pass記録領域からUsage PassをUsage Pass Bufferへ読み出し、Usage PassのUPIDが、処理BT6.7.2で復号した結果得られたUPIDと一致するか確認する。一致しない場合は、処理を中断する。
処理BT6.7.4: 受信したUsage Passを制限記憶部へ記録する。Usage Passの記録を行う際には、有効性指示フラグを「有効」に設定する。
その後、Inceptive DeviceにおけるUsage Passの制限記憶部への記録が正常に終了したか否かを確認するために、ホストモジュールは、Inceptive Deviceに対し、CHECK EXECUTION STATUS命令27140を発行しても良い。Inceptive Deviceからホストモジュールへは、実行状態が27141において送信される。
処理BT6.7.2が完了すると、Inceptive Deviceには、送信する以前のUsage Passが存在するようになる。
[データ記憶領域の領域分割]
暗号化されたコンテンツデータの記憶領域である、記憶媒体200上の論理空間の分割法について、図２８を用いて説明する。記憶媒体200上に構成される記憶領域は、その領域を指し示すアドレスを指定した命令をStorage Interface Unit 220にセットすることによって、コンテンツデータそのものを書き込んだり読み出したりできるアクセス可能領域（Accessible area）28001と、ユーザが意図的にアクセスすることはできない隠し領域（Hidden area）28000からなる。隠し領域28000は、記憶媒体200とは物理的に異なる別の媒体上に設けても良い。
次に、隠し領域28000に記録するデータについて、図２９を用いて説明する。隠し領域29010には、複数のエントリが記録できる。個々のエントリは、コンテンツ識別子（CID，29001）を記録する領域と、CIDが記録されているエントリを指定する識別子を記録する領域（EN_CID，29000）からなる。EN_CIDは、磁気ディスク装置が記録可能なCIDの種類を特定できれば良いので、通常CIDの長さに比べると、短くて構わない。例えば、1セクタ長が512バイトであるような1テラバイトの磁気ディスク装置の全セクタに、全てCIDが異なるコンテンツデータを記録する場合でも、３１ビットあれば全てのCIDを判別することができる。一方、CIDは全てのコンテンツデータに固有に割り当てられる識別子なので、十分な長さが必要である。本実施例では、その長さを仮に３２バイトとする。
一方、アクセス可能領域28001へコンテンツデータを記録する場合、図３０に示すように、通常の磁気ディスク装置と同様に、コンテンツデータそのものは各セクタ（通常は512バイト）に記録される。特徴的なことは、各セクタには、コンテンツデータの記録領域30010の他に、コンテンツデータの出力制御情報（ODCI，30000）、及びコンテンツデータが対応するCIDのEntry Number（EN_CID，30001；29000に記したものに相当）、等の付加データを記録する拡張領域が設けられる。出力制御情報30000は、
０: 出力先装置に対して、該セクタに記録されているコンテンツデータの出力を、制限無しに実行可能、
１: 出力先装置に対して、該セクタに記録されているコンテンツデータの出力は、該データを復号するためのUsage Passが、出力先装置に存在することが確認できた場合のみ、該データの出力が可能、
を意味するものとする。
拡張領域については、記憶装置に対する通常の読み出し命令による読み出しや、書き込み命令による書き込みは、実行できない。この領域に記録されているデータの読み出しや、この領域へのデータの書き込みは、以下で説明する特殊な命令でのみ実行可能である。
[1つのConnectionの元でのコンテンツデータの転送処理シークエンス]
目的のコンテンツデータが記録されている装置（記憶装置）か、あるいはコンテンツデータを生成している装置（記録装置）と、コンテンツデータの出力先装置（記憶装置もしくは再生装置）の間で、ホストモジュール110を介してUTモードあるいはBTモードいずれかによってConnectionを確立した場合に、コンテンツデータの転送元である装置（以下、転送元装置という）から転送先である装置（以下、転送先装置という）へ該データを転送する処理シークエンスについて、図３１を中心に、適宜、図２８，図２９，図３０，図１８を用いて説明する。尚、図３１に示す処理シークエンスは、下記２点を前提とする。
(1) 転送元装置と転送先装置は、図1に示したような1つの記録再生装置に共に接続されている。
(2) 転送元装置及び転送先装置は、共に記憶装置である。
以降では、上記２つの前提条件に基づいて、転送元装置から転送先装置に対して、コンテンツデータの転送を行う場合の処理シークエンスについて説明する。前提条件(2)に記したように、以下では転送元装置と転送先装置が共に記憶装置であることを前提として説明するが、転送元装置が記録装置であったり、転送先装置が再生装置であったりしても良い。そのような場合については、文中で適宜説明する。
まず、コンテンツデータ記録再生装置を起動すると（31000）、転送元記憶装置と転送先記憶装置は、それぞれ隠し領域 28000に記録されているEN_CID CID tableを記憶媒体200から読み出して、高速にアクセスすることが可能な記憶装置制御部230内のSC Buffer 231に一時的に保持しておく。転送元記憶装置における本処理は31001であり、同様に転送先記憶装置における本処理は31002である。尚、EN_CID CID tableは、必ずしも前記のように起動時に読み出してSC Bufferに保持しておくのではなく、アクセス可能領域に記録されているデータを読み出す度に、記憶装置内部で毎度読み出すようにしても良い。尚、双方の装置が記憶装置でなかった場合は、EN_CID CID tableを、隠し領域からSC Bufferへ読み出す処理実行する必要がない場合もある。このような装置の場合、通常は該tableが、装置内の一時記憶領域に通常は記録されている。
続いて、目的のコンテンツデータの転送を行うために、ホストモジュール110が転送元装置に対してREAD SECTORS命令31010を送信する場合を考える。この命令は、転送元装置に記録されているデータを読み出すための、従来規定されていた標準的な読み出し命令とする。この命令をホストモジュール110が転送元装置に対して送信する場合は、読み出すためのデータが記録されている領域のアドレス情報を、31011において転送元装置に通知する。従来の記憶装置は、本命令を受信すると、31011で指定された該アドレス情報で指し示される領域に記録されているデータを、ホストモジュール110へ送信する。
一方、本発明による機能を有する記憶装置は、本命令31010及びデータが記録されているアドレス情報31011を受信すると、そのアドレス情報で指定される領域から目的のデータを読み出して記憶装置制御部230へ転送する際、装置内部において、その領域の出力制御情報30000を確認する。そして、本出力制御情報が1であった場合は、本命令の処理を中断する。この時、記憶装置からは中断された理由がホストモジュール110へパラメータとして通知されるようになっていると、ホストモジュール110は本命令が中断された理由を知ることができるという利点があるが、そのような機能は必須ではない。実際、例えばAT Attachmet等の磁気ディスク装置用のインタフェース規格では、そのような読み出し命令は規定されていない。
転送元記憶装置に対するコンテンツデータの読み出し命令が、記憶装置によって中断されると、ホストモジュール110は、転送元装置と転送先装置の間で、図１８に示したConnection Stage 31020を実行させる。ここで、転送元装置及び転送先装置が記憶装置であるという前提を離れると、Connection Stageを実行する際、転送元装置と転送先装置としては、果たす役割及びConnectionの方法によって、次に記す６種類が存在する。
(1CN_UT1) UTモードによるConnection; 転送元装置: Storage Security Manager（Primal Device）; 転送先装置: Storage Security Manager（Inceptive Device）
(1CN_UT2) UTモードによるConnection; 転送元装置: Storage Security Manager（Inceptive Device）; 転送先装置: Storage Security Manager（Primal Device）
(1CN_UT3) UTモードによるConnection; 転送元装置: Storage Security Manager（Primal Device）; 転送先装置: Host Security Manager（Inceptive DeviceとしてのPlayback Module）
(1CN_UT4) UTモードによるConnection転送元装置: Host Security Manager（Primal DeviceとしてのRecording Module）; 転送先装置: Storage Security Manager（Inceptive Device）
(1CN_BT1) BTモードによるConnection; 転送元装置: Storage Security Manager（Inceptive Device）; 転送先装置: Host Security Manager（Primal DeviceとしてのPlayback Module）
(1CN_BT2) BTモードによるConnection; 転送元装置: Host Security Manager（Primal DeviceとしてのRecording Module）; 転送先装置: Storage Security Manager（Inceptive Device）
上記６種類のいずれの方法でConnection Stageを完了したとしても、転送元装置と転送先装置の間で、２つの0次セッション鍵K_s[P]0とK_s[I]0が共有される。従って、両装置が記憶装置である限定を付けても、本質的な意味では何らかの制限を加えていることにはならない。
Connection Stage 31020の完了後、転送元装置と転送先装置の間で、UTモードの下でTransfer Stage 31021がn回実行されると（方向は問わない）、転送先装置で生成されるセッション鍵が転送処理毎に生成されるので、最終的に共有されているセッション鍵は、K_s[P]0とK_s[I]nとなる。同様に、BTモードの下で、転送先装置から転送元装置に対してn回、逆向きにm回、Transfer Stage 31021が実行されると、最終的に共有されている鍵セッション鍵は、K_s[P]mとK_s[I]nとなる。そこで32021には、最終的に共有されるセッション鍵を、仮にK_s[P]mとK_s[I]nと記載したが、Transfer Stageを一度も実行しない場合は、nやmの値は0のままである。
Connection Statgeを完了すると、ホストモジュール110は、転送先記憶装置に対して、READ USAGE PASS命令31030を送信する。本命令では、Usage Passが記録されている領域を指し示すアドレス31031を、同時に転送先記憶装置に送信する。本命令の目的は、転送しようとしているコンテンツデータを復号可能なUsage Passを、Qualified Storageから読み出すことである。READ USAGE PASS命令を受信した場合の記憶装置内での処理は、図１９における19000，19001，19002や、図２３における23000，23001，23001等に説明したものと同じである。一方、転送先装置が記憶装置でなかった場合は、Qualified Storageから目的のUsage Passを読み出すといった処理ではなく、転送先装置内に保持されているUsage Passの中から、必要なUsage Passを特定するといった処理のみが行なわれる。
続いて、ホストモジュール110は、転送先記憶装置に対して、GET MASKED USAGE PASS WITH KEYED HASH命令を送信する。転送先記憶装置では、READ USAGE PASS命令31030でUsgae Pass Buffer 510へ読み出されたUsage Passから、Masked Usage Passが生成される。それと並行して、その時点で共有されている、Primal DeviceとInceptive Deviceそれぞれで生成された最新のセッション鍵K_s[P]mとK_s[I]nを用いて、Keyed Hash値を計算する。得られた２つのデータは次のように連結され、ホストモジュール110へ送信される（31042）: MUP || H(K_s[P]m || K_s[I]n || MUP)。GET MASKED USAGE PASS WITH KEYED HASH命令を受信した場合の記憶装置内での処理は、共有されている最新のセッション鍵の値が異なる点を除き、処理BT3.2.1及び処理BT3.2.2に記載したものと同じである。転送先装置が記憶装置でなかった場合も、内部に保持されているUsage Passから、上記同様にMasked Usage Passを生成する。
Keyed Hashが連結されたMasked Usage Passを受信すると、ホストモジュール110は、該データをそのまま転送元記憶装置に送信する（31051）。送信は、PUT MASKED USAGE PASS WITH KEYED HASH命令31050によって実行される。
転送元記憶装置は、Keyed Hashが連結されたMasked Usage Passを受信すると、受信したデータについて改竄が行われていないかどうかを検証する。検証方法は、共有されている最新のセッション鍵の値が異なる点を除き、処理BT3.3.1に記載したものと同じである。転送元装置が記憶装置でなかった場合も、上記同様である。
ホストモジュール110は、PUT MASKED USAGE PASS WITH KEYED HASH命令31050に続き、READ SECTORS PROTECTED命令31060を、目的のコンテンツデータが記録されている領域を指し示すアドレス情報や転送データ長31061と共に、転送元記憶装置に送信する。本命令及びアドレス情報を受信すると、転送元記憶装置内の記憶装置制御部230では、以下の処理を行なう。
処理1CN_CT1.1.1: 受信したアドレス情報で指し示される領域に記録されている出力制御情報30000及び、EN_CID値30001を確認する。出力制御情報が1であった場合は、EN_CID値を確認し、SC Buffer 231に保持されているEN_CID CID tableから、指定された領域に記録されているデータが、どのCIDのものなのか把握する。
処理1CN_CT1.1.2: 処理1CN_CT1.1.1の結果把握することができた、指定された領域に記録されているデータが対応するコンテンツ識別子を、PUT MASKED USAGE PASS WITH KEYED HASH命令により転送先から送られたUsage Passに含まれるコンテンツ識別子と比較する。比較の結果、コンテンツ識別子の値が一致した場合は、転送先記憶装置に、該コンテンツデータを復号するためのUsage Passが存在することが確認できたことになり、以下の処理を継続する。比較の結果、コンテンツ識別子の値が一致しなかった場合は、処理を中断する。
処理1CN_CT1.1.3: その時点で共有されている2つの最新のセッション鍵K_s[P]m及びK_s[I]n，該データに関する出力制御情報30000，CID 29001，出力する該データを連結し、Keyed Hash値を計算する。コンテンツ識別子は、EN_CID CID tableを参照することにより、確定する。
処理1CN_CT1.1.4: 出力制御情報30000，CID，処理1CN_CT1.1.3で得られたKeyed Hash値を連結する。得られるデータは、ODCI || CID || Content data || H(K_s[P]m || K_s[I]n || ODCI || CID || Content data)である。ここで、Content dataが、実際に転送元記憶装置に記録されていた、転送対象データである。
以上、処理1CN_CT1.1.1から1CN_CT1.1.4については、転送元装置が記憶装置でなかった場合でも、出力制御情報や目的のコンテンツデータが記録または保持されているところが異なる点を除き、基本的に同じである。
転送元記憶装置は、処理1CN_CT1.1.4を完了すると、生成されたデータODCI || CID || Content data || H(K_s[P]m || K_s[I]n || ODCI || CID || Content data)をホストモジュールへ送信する。尚、31061においてホストモジュールが指定する転送データ長は、コンテンツデータのみの長さとしても良い。この場合でも、出力制御情報やコンテンツ識別子の長さを固定しておき、READ SECTORS PROTECTED命令を記憶装置が受信した場合は、該データを連結したコンテンツデータが出力されるという運用にしておけば問題はない。このことは、次に記すWRITE SECTORS PROTECTEDについても同様である。
ホストモジュール110は、READ SECTORS PROTECTED命令に対する応答データを受信すると、WRITE SECTORS PROTECTED命令31070に続けて、該データをそのまま転送先記憶装置に送信する(31071)。この時、31071では、記録先領域を示すアドレス情報も指定する。本命令及びアドレス情報を受信すると、転送先記憶装置内の記憶装置制御部230では、以下の処理を行なう。
処理1CN_CT1.2.1: 受信したデータ及び、自身が保持している最新の２つのセッション鍵K_s[P]m及びK_s[I]nを用いて、Keyed Hash値の検証を行う。受信した出力制御情報，コンテンツ識別子，コンテンツデータ及び該2つのセッション鍵からKeyed Hash値を計算し、それが受信したKeyed Hash値と一致すれば、改竄が行われていないと判断する。Keyed Hash値が一致しなかった場合は、処理を中断する。
処理1CN_CT1.2.2: 受信したコンテンツ識別子を用いて、EN_CID CID tableを検索する。該コンテンツ識別子が記録されたエントリがあった場合はそのEN_CID値を、なかった場合は新たなEN_CID CIDエントリをtable内に生成し、該EN_CID値を受信したコンテンツデータに割り当てる。
処理1CN_CT1.2.3: 31071で指定されたアドレス情報で指定される領域に、受信したコンテンツデータ，出力制御情報、及び処理1CN_CT1.2.2で決定したEN_CID情報を加えて、図３０に示したような形式でデータを記録する。転送先装置が記憶装置でなかった場合は、本書き込み処理は実行されない。
尚、転送先装置は、Connection Stage 31020を完了すると、書き込み命令については、WRITE SECTORS PROTECTEDのような特殊命令以外の通常の書き込み命令を受信した場合は、処理を中断する。これにより、ホストモジュール110が、READ SECTORS PROTECTEDの結果として出力制御情報，コンテンツ識別子及びKeyed Hash付きのコンテンツデータを受信した後、該制御情報，該識別子，該Keyed Hashを削除して転送先に送信したり記録しようとする処理は、実行できないことになる。
また上記では、出力制御情報の値に拠ったり、あるいはConnection Stage完了後であった場合は、読み出し命令及び書き込み命令は拡張命令（READ SECTORS PROTECTED，WRITE SECTORS PROTECTED）以外は実行しないとしたが、READ SECTORS 31010のような標準命令も実行可としても良い。但しこの場合、Connection Stageの完了後は、転送されるデータには、常に特定の位置に出力制御情報やコンテンツ識別子、及びKeyed Hash値が含まれるという規定を設けておく必要がある。そのような例を、図３４に示す。
図３４は、Connection Stageの完了後に、標準命令で1セクタのデータを読み出す場合のデータ構造を示している。各セクタには、出力制御情報（ODCI）33000，コンテンツ識別子(CID)33001，コンテンツデータ33010，Keyed Hash値33011が含まれる。標準の書き込み命令を受信した転送先機器は、Keyed Hash値が埋め込まれている位置を特定し、Keyed Hash値を検証する。もし検証を失敗したら、処理を中断する。
上記は、転送元装置と転送先装置は1つのConnectionを確立している場合について説明したが、それぞれの装置は別々の記録再生装置に接続されていて、両記録再生装置はネットワークで繋がれているような状態であっても良い。この場合、図の上ではホストモジュール110は２つに分割されるような形となり、両者の間には、ネットワーク通信を制御するネットワークインタフェース部100が設けられる。その場合、設けられたネットワークインタフェース部は、転送元や転送先となっているHost Security ManagerやStorage Security Managerに対して、それらが接続されているホストモジュールを介して該データの受け渡しを行うだけである。
以上に記した方法により、暗号化されたコンテンツデータであっても、転送先記憶装置にそのコンテンツデータを復号するための情報がない場合は、転送元記憶装置からコンテンツデータの出力を制止することができる。
[２つのConnectionの元でのコンテンツデータの転送処理シークエンス]
目的のコンテンツデータが記録されている装置（記憶装置）か、あるいはコンテンツデータを生成している装置（記録装置）と、コンテンツデータの出力先装置（記憶装置もしくは再生装置）の間で、２つの異なるConnectionを確立する場合に、コンテンツデータの転送元である装置（以下、転送元装置という）から転送先である装置（以下、転送先装置という）へコンテンツデータを転送する処理シークエンスについて、図３２，図３３を中心に、適宜、図２８，図２９，図３０，図２２を用いて説明する。尚、図３２、３３に示す処理シークエンスは、下記２点を前提とする。
(1) 転送元装置と転送先装置の間には、２つの異なるConnectionが存在する。
(2) 転送元装置及び転送先装置は、共に記憶装置である。
以降では、上記２つの前提条件に基づいて、転送元装置から転送先装置に対して、コンテンツデータの転送を行う場合の処理シークエンスについて説明する。以下では転送元装置と転送先装置が共に記憶装置であることを前提として説明する。
まず、転送元装置及び転送先装置を起動すると（32000，32003）、転送元記憶装置と転送先記憶装置は、それぞれ隠し領域 28000に記録されているEN_CID CID tableを記憶媒体200上から読み出して、高速にアクセスすることが可能な記憶装置制御部230内のSC Buffer 231に一時的に保持しておく。転送元記憶装置における本処理は32001であり、同様に転送先記憶装置における本処理は32002である。尚、EN_CID CID tableは、必ずしも前記のように起動時に読み出してSC Bufferに保持しておくのではなく、アクセス可能領域に記録されているデータを読み出す度に、記憶装置内部で毎度読み出すようにしても良い。
続いて、目的のコンテンツデータの転送を行うために、転送元ホストモジュールが転送元記憶装置に対してREAD SECTORS命令31010を送信する場合を考える。この命令は、転送元記憶装置に記録されているデータを読み出すための、従来規定されていた標準的な読み出し命令とする。本命令をホストモジュールが転送元記憶装置に対して送信する場合は、読み出すためのデータが記録されている領域のアドレス情報を、32011において転送元装置に通知する。従来の記憶装置は、本命令を受信すると、32011で指定されたアドレス情報で指定される領域に記録されているデータを、ホストモジュールへ送信する。
一方、本発明による機能を有する記憶装置は、本命令32010及びデータが記録されているアドレス情報32011を受信すると、そのアドレス情報で指定される領域から目的のデータを読み出して記憶装置制御部230へ転送する際、装置内部において、その領域の出力制御情報30000を確認する。そして、本出力制御情報が1であった場合は、本命令の処理を中断する。この時、記憶装置からは中断された理由がホストモジュールへパラメータとして通知されるようになっていると、ホストモジュールは本命令が中断された理由を知ることができるという利点があるが、そのような機能は必須ではない。実際、例えばAT Attachmet等の磁気ディスク装置用のインタフェース規格では、そのような読み出し命令は規定されていない。
転送元記憶装置に対するコンテンツデータの読み出し命令が、記憶装置によって中断されると、転送元ホストモジュールは、転送元装置内のHost Security Moduleと転送元記憶装置内のStorage Security Moduleの間で、図２２に示したConnection Stage 32020を実行させる。同様に、転送先ホストモジュールは、転送先装置内のHost Security Moduleと転送先記憶装置内のStorage Security Moduleの間で、Connection Stage 32022を実行させる。また転送元装置内のHost Security Moduleと転送先装置内のHost Secuirty Moduleの間では、Connection Stage 32015を実行する。このような場合に、転送元装置と転送先装置内にあるHost Security Manager及びStorage Security Managerの間で確立されるConnectionは、次に記す９種類が存在する。
(2CN_UTUT1) UTモードによるConnection; 転送元装置内: Storage Security Manager（Primal Device）Host Security Manager（Inceptive Device）; 転送先装置内: Host Security Manager（Primal Device）Storage Security Manager（Inceptive Device）
(2CN_UTUT2) UTモードによるConnection; 転送元装置内: Storage Security Manager（Primal Device），Host Security Manager（Inceptive Device）; 転送先装置内: Host Security Manager（Inceptive Device），Storage Security Manager（Primal Device）
(2CN_UTUT3) UTモードによるConnection; 転送元装置内: Storage Security Manager（Inceptive Device），Host Security Manager（Primal Device）; 転送先装置内: Host Security Manager（Primal Device），Storage Security Manager（Inceptive Device）
(2CN_UTUT4) UTモードによるConnection; 転送元装置内: Storage Security Manager（Incptive Device），Host Security Manager（Primal Device）; 転送先装置内: Host Security Manager（Inceptive Device），Storage Security Manager（Primal Device）
(2H_CNBTBT1) BTモードによるConnection; 転送元装置内: Storage Security Manager（Inceptive Device），Host Security Manager（Primal Device）; 転送先装置内: Host Security Manager（Primal Device），Storage Security Manager（Inceptive Device）
(2H_CNUTBT1) 転送元装置内: UTモードによるConnection; Storage Security Manager（Primal Device），Host Security Manager（Inceptive Device）; 転送先装置内: BTモードによるConnection; Host Security Manager（Primal Device），Storage Security Manager（Inceptive Device）
(2CN_UTBT2) 転送元装置内: UTモードによるConnection; Storage Security Manager（Inceptive Device），Host Security Manager（Primal Device）; 転送先装置内: BTモードによるConnection; Host Security Manager（Primal Device），Storage Security Manager（Inceptive Device）
(2CN_BTUT1) 転送元装置内: BTモードによるConnection; Storage Security Manager（Inceptive Device），Host Security Manager（Primal Device）; 転送先装置内: UTモードによるConnection; Host Security Manager（Primal Device），Storage Security Manager（Inceptive Device）
(2CN_BTUT2) 転送元装置内: BTモードによるConnection; Storage Security Manager（Inceptive Device），Host Security Manager（Primal Device）; 転送先装置内: UTモードによるConnection; Host Security Manager（Inceptive Device），Storage Security Manager（Primal Device）
上記９種類のいずれの方法でConnection Stageを完了したとしても、転送元装置内及び転送先装置内のStorage Security ManagerとHost Security Managerの間で、２つの０次セッション鍵K_s[P]src0とK_s[I]src0，K_s[P]dst0とK_s[I]dst0が共有される。尚、転送元装置内のHost Security Managerと転送先装置内のHost Security Managerの間で実行されるSHSM DHSM Connection Stage 32015は、一般に知られているDTCP（http://www.dtcp.com/）や、SSL（http://wp.netscape.com/eng/ssl3/）などで実現してもよい。あるいは、命令体系は別として、図１８や図２２を用いて説明した方法と同様の方法で、メッセージデータを交換することにより、両装置間で認証を完了し、秘密情報を共有する形としても良い。いずれの方法であったとしても、Connection Stage 32015を完了した時点で、転送元装置内のHost Security Managerと転送先装置内のHost Security Managerの間では、K_s[H]src0とK_s[H]dst0の共有が完了しているものとする。
転送元装置におけるConnection Stage 32020及び転送先装置におけるConnection Stage 32022の完了後、転送元装置内あるいは転送先装置内において、UTモードの下でそれぞれTransfer Stage 32021，32023がn及びm回実行されると（方向は問わない）、転送元装置内で最終的に共有されているセッション鍵はK_s[P]src0とK_s[I]srcn，転送先装置内で最終的に共有されているセッション鍵はK_s[P]dst0とK_s[I]dstmとなる。一方、転送元装置内において、BTモードの下で、Primal DeviceからInceptive DeviceへのTransfer Stage 32021がp回，Inceptive DeviceからPrimal DeviceへのTransfer Stage 32021がq回実行されると、転送元装置内で最終的に共有されているセッション鍵はK_s[P]srcpとK_s[I]srcqとなる。同様に、転送先装置内において、BTモードの下で、Primal DeviceからInceptive DeviceへのTransfer Stage 32023がr回，Inceptive DeviceからPrimal DeviceへのTransfer Stage 32023がs回実行されると、転送元装置内で最終的に共有されているセッション鍵はK_s[P]dstrとK_s[I]dstsとなる。
上記を受けて、32021及び32023の結果、最終的に共有されるセッション鍵を仮にK_s[P]srcp，K_s[I]srcq，K_s[P]dstr，K_s[I]dstsと記載したが、Transfer Stageを一度も実行しない場合は、p，q，r，sの値は、０のままである。転送元装置内で実行されるTransfer Stage 32021と、転送先装置内で実行されるTransfer Stage 32023を接続するために両装置間で実行されるSHSM DHSM Transfer Stage 32022は、上述のようにDTCP，SSLあるいは図１９や図２４を用いて説明した方法と同様の方法で、メッセージデータを交換することにより、目的のUsage Pass転送を実現しても良い。いずれの方法であったとしても、SHSM DHSM Transfer Stageを完了した時点で、転送元装置内のHost Security Managerと転送先装置内のHost Security Managerの間では、K_s[H]srciとK_s[H]dstjの共有が完了しているものとする。尚、方法によっては、Usage Pass転送処理を繰り返しても、i，j値は一定値を続け、鍵データの更新は行われない場合もある。
Connection Stageを完了すると、転送先ホストモジュールは、転送先記憶装置に対して、READ USAGE PASS命令32030を送信する。本命令では、Usage Passが記録されている領域を指し示すアドレス32031を、同時に該記憶装置に送信する。本命令の目的は、転送しようとしているコンテンツデータを復号可能なUsage Passを、Qualified Storageから読み出すことである。READ USAGE PASS命令を受信した場合の記憶装置内での処理は、図１９における19000，19001，19002や、図２３における23000，23001，23001等に説明したものと同じである。一方、転送先装置が記憶装置でなかった場合は、Qualified Storageから目的のUsage Passを読み出すといった処理ではなく、転送先装置内に保持されているUsage Passの中から、必要なUsage Passを特定するといった処理のみが行なわれる。
続いて、転送先ホストモジュールは、転送先記憶装置に対して、GET MASKED USAGE PASS WITH KEYED HASH命令を送信する。転送先記憶装置では、READ USAGE PASS命令32030でUsgae Pass Buffer 510へ読み出されたUsage Passから、Masked Usage Passが生成される。それと並行して、その時点で共有されている、Primal DeviceとInceptive Deviceそれぞれで生成された最新のセッション鍵K_s[P]dstrとK_s[I]dstsを用いて、Keyed Hash値を計算する。得られた２つのデータは次のように連結され、転送先ホストモジュールへ送信32042される: MUP || H(K_s[P]dstr || K_s[I]dsts || MUP)。GET MASKED USAGE PASS WITH KEYED HASH命令を受信した場合の記憶装置内での処理は、共有されている最新のセッション鍵の値が異なる点を除き、処理BT3.2.1及び処理BT3.2.2に記載したものと同じである。転送先装置が記憶装置でなかった場合も、内部に保持されているUsage Passから、上記同様にMasked Usage Passを生成する。
Keyed Hashが連結されたMasked Usage Passを受信すると、転送先ホストモジュールは、該データをHost Security Managerへそのまま送信する。続いてHost Security Managerは、受信したデータについて改竄が行われていないかどうかを検証する。検証方法は、共有されている最新のセッション鍵の値が異なる点を除き、処理BT3.3.1に記載したものと同じである。検証が完了すると、Host Security Managerと転送元装置内のHost Security Managerとの間で共有されている最新のセッション鍵K_s[H]srci及びK_s[H]dstjを用いて、上記同様の方法でKeyed Hash計算を行い、受信したMasked Usage Passに連結する。得られるデータは、MUP || H(K_s[H]srci || K_s[H]dstj || MUP)である(32050)。そして、該メッセージデータを転送元装置へ送信する(32053)。
転送元装置は、Keyed Hashが連結されたMasked Usage Passを受信すると、Host Security Managerにおいて、受信したデータに改竄が加えられていないかどうかを検証する。検証方法は、共有されている最新のセッション鍵の値が異なる点を除き、処理BT3.3.1に記載したものと同じである。検証が完了すると、Host Security ManagerとStorage Security Managerの間で共有されている最新のセッション鍵K_s[P]srcp及びK_s[I]srcqを用いて、上記同様の方法でKeyed Hash計算を行い、受信したMasked Usage Passに連結する。得られるデータは、MUP || H(K_s[P]srcp || K_s[I]srcq || MUP)である(32054)。
Keyed Hashが連結されたMasked Usage Passの生成が完了すると、転送元ホストモジュールは、該データを転送元記憶装置に送信する（32061）。送信は、PUT MASKED USAGE PASS WITH KEYED HASH命令32060によって実行される。
転送元記憶装置は、Keyed Hashが連結されたMasked Usage Passを受信すると、受信したデータについて改竄が行われていないかどうかを検証する。検証方法は、共有されている最新のセッション鍵の値が異なる点を除き、処理BT3.3.1に記載したものと同じである。転送元装置が記憶装置でなかった場合も、前記同様である。
転送元ホストモジュールは、PUT MASKED USAGE PASS WITH KEYED HASH命令31060に続き、READ SECTORS PROTECTED命令32070を、目的のコンテンツデータが記録されている領域を指し示すアドレス情報や転送データ長31071と共に、転送元記憶装置に送信する。本命令及びアドレス情報を受信すると、転送元記憶装置内の記憶装置制御部230では、以下の処理を行なう。
処理2CN_CT1.1.1: 受信したアドレス情報で指し示される領域に記録されている出力制御情報30000及び、EN_CID値30001を確認する。出力制御情報が1であった場合は、EN_CID値を確認し、SC Buffer 231に保持されているEN_CID CID tableから、指定された領域に記録されているデータが、どのCIDのものなのか把握する。
処理2CN_CT1.1.2: 処理2CN_CT1.1.1の結果把握することができた、指定された領域に記録されているデータが対応するコンテンツ識別子を、PUT MASKED USAGE PASS WITH KEYED HASH命令により転送先から送られたUsage Passに含まれるコンテンツ識別子と比較する。比較の結果、コンテンツ識別子の値が一致した場合は、転送先記憶装置に、該コンテンツデータを復号するためのUsage Passが存在することが確認できたことになり、以下の処理を継続する。比較の結果、コンテンツ識別子の値が一致しなかった場合は、処理を中断する。
処理2CN_CT1.1.3: その時点で共有されている2つの最新のセッション鍵K_s[P]srcp及びK_s[I]srcq，該データに関する出力制御情報30000，CID 29001，出力する該データを連結し、Keyed Hash値を計算する。コンテンツ識別子は、EN_CID CID tableを参照することにより、確定する。
処理2CN_CT1.1.4: 出力制御情報30000，CID，処理2CN_CT1.1.3で得られたKeyed Hash値を連結する。得られるデータは、ODCI || CID || Content data || H(K_s[P]srcp || K_s[I]srcq || ODCI || CID || Content data)である。ここで、Content dataが、実際に転送元記憶装置に記録されていた、転送対象データである。
転送元記憶装置は、処理2CN_CT1.1.4を完了すると、生成されたデータODCI || CID || Content data || H(K_s[P]srcp || K_s[I]srcq || ODCI || CID || Content data)を、転送元ホストモジュールへ送信する。尚、32071において転送元ホストモジュールが指定する転送データ長は、コンテンツデータのみの長さとしても良い。この場合でも、出力制御情報やコンテンツ識別子の長さを固定しておき、READ SECTORS PROTECTED命令を記憶装置が受信した場合は、該データを連結したコンテンツデータが出力されるという運用にしておけば問題はない。このことは、後に記すWRITE SECTORS PROTECTEDについても同様である。
転送元装置は、Keyed Hashが連結されたODCI || CID || Content dataを受信すると、Host Security Managerにおいて、受信したデータに改竄が加えられていないかどうかを検証する。検証方法は、共有されている最新のセッション鍵の値が異なる点を除き、処理BT3.3.1に記載したものと同じである。検証が完了すると、Host Security ManagerとStorage Security Managerの間で共有されている最新のセッション鍵K_s[P]srcp及びK_s[I]srcqを用いて、上記同様の方法でKeyed Hash計算を行い、受信したODCI || CID || Content dataに連結する。得られるデータは、ODCI || CID || Content data || H(K_s[H]srci || K_s[H]dstj || ODCI || CID || Content data)である(32080)。そして、該メッセージデータを転送元装置へ送信する（32083）。
Keyed Hashが連結された ODCI || CID || Content dataを受信すると、転送先Host Security Managerは、受信したデータについて改竄が加えられていないかどうかを検証する。検証方法は、共有されている最新のセッション鍵の値が異なる点を除き、処理BT3.3.1に記載したものと同じである。検証が完了すると、Host Security ManagerがStorage Security Managerと共有している最新のセッション鍵を用いて、前記同様の方法でKeyed Hash計算を行い、受信したODCI || CID || Content dataに連結する。得られるデータは、ODCI || CID || Content data || H(K_s[P]dstr || K_s[I]dsts || ODCI || CID || Content data)である(32080)。
転送先ホストモジュールは、生成されたデータODCI || CID || Content data || H(K_s[P]dstr || K_s[I]dsts || ODCI || CID || Content data)を、WRITE SECTORS PROTECTED命令32090に続けて、転送先記憶装置に送信する(32091)。この時、31091では、記録先領域を示すアドレス情報も指定する。本命令及びアドレス情報を受信すると、転送先記憶装置内の記憶装置制御部230では、以下の処理を行なう。
処理2CN_CT1.2.1: 受信したデータ及び、自身が保持している最新の２つのセッション鍵K_s[P]dstr及びK_s[I]dstsを用いて、Keyed Hash値の検証を行う。受信した出力制御情報，コンテンツ識別子，コンテンツデータ及びこの２つのセッション鍵からKeyed Hash値を計算し、それが受信したKeyed Hash値と一致すれば、改竄が行われていないと判断する。Keyed Hash値が一致しなかった場合は、処理を中断する。
処理2CN_CT1.2.2: 受信したコンテンツ識別子を用いて、EN_CID CID tableを検索する。該コンテンツ識別子が記録されたエントリがあった場合はそのEN_CID値を、なかった場合は新たなEN_CID CIDエントリをtable内に生成し、該EN_CID値を受信したコンテンツデータに割り当てる。
処理2CN_CT1.2.3: 31071で指定されたアドレス情報で指定される領域に、受信したコンテンツデータ，出力制御情報、及び処理2CN_CT1.2.2で決定したEN_CID情報を加えて、図30に記載したような形式でデータを記録する。転送先装置が記憶装置でなかった場合は、本書き込み処理は実行されない。
尚、転送先装置は、Connection Stage 31020を完了すると、書き込み命令については、WRITE SECTORS PROTECTEDのような特殊命令以外の通常の書き込み命令を受信した場合は、処理を中断する。これにより、ホストモジュールが、READ SECTORS PROTECTEDの結果として出力制御情報，コンテンツ識別子及びKeyed Hash付きのコンテンツデータを受信後、該制御情報，該識別子，該Keyed Hashを削除して転送先に送信したり記録したりしようとする処理は、実行できないことになる。
また上記では、出力制御情報の値に拠ったり、あるいはConnection Stage完了後であったりした場合は、読み出し命令及び書き込み命令は拡張命令（READ SECTORS PROTECTED，WRITE SECTORS PROTECTED）以外は実行しないとしたが、READ SECTORS 31010のような標準命令も実行可としても良い。但しこの場合、Connection Stage完了後は、転送されるデータには、常に特定の位置に出力制御情報やコンテンツ識別子、及びKeyed Hash値が含まれるという規定を設けておく必要がある。そのような例を、図３４に示す。
上記は、転送元装置と転送先装置は1つのConnectionを確立している場合について説明したが、それぞれの装置は別々の記録再生装置に接続されていて、両記録再生装置はネットワークで繋がれているような状態であっても良い。この場合、図の上では転送元ホストモジュールと転送先ホストモジュールの間に命令及びデータが流れる部分ができることになる。この場合、転送元Host Security Managerと転送先Host Security Managerの間でConnection Stageを実行し（UTモードでもBTモードであっても良い）、それらの間でのみ共有されるセッション鍵を共有する。そして、共有されたセッション鍵を用いて、32050，32080におけるKeyed Hash値計算を行ない、通信相手のホストモジュールへ送信し、検証後、転送元記憶装置や転送先記憶装置との間で共有されているセッション鍵を用いて、新たにKeyed Hash計算をし直すようにすれば良い。
上記した方法により、暗号化されたコンテンツデータであっても、転送先記憶装置にコンテンツデータを復号するための情報がない場合は、転送元記憶装置からコンテンツデータの出力を制止することができる。
以上、実施例について説明したが、本発明は上記実施例に限定されない。また、種々変形して実施したり、また他の装置やシステムにも応用したりすることができるであろう。例えば、上記実施例において説明された命令やモジュール等の呼び名は、あくまで一例であって上記の例に限定されない。例えば、上記実施例におけるユーセジパス（Usage Pass）は、ライセンス情報、或いは機密情報と呼ばれる場合もあろう。
また、上記実施例では、記録再生装置と磁気ディスク装置を含むシステムにおけるコンテンツデータのセキュリティ管理について述べたものであるが、他の例によるシステム及びその構成装置としては、記録再生装置や磁気ディスク装置以外の装置に適用することも可能である。即ち、本発明に係る、コンテンツデータの復号化を管理するための制御情報を取扱う特徴的な処理機能を有すれば、記録再生装置及び磁気ディスク装置に限定されない。この特徴的な処理機能を有する限りにおいて、例えば、記憶装置は、磁気ディスク装置以外のもの、例えば半導体メモリ等でもよく、また、記録再生装置は、記憶装置が接続されるホストコンピュータでもよい。
また、他の変形例においては、上記実施例の鍵データ等を記憶する保護記憶領域は、論理的に対タンパ性が確保されていれば、必ずしも物理的に対タンパ性を有するメモリであることを要しない。
一実施例による記録再生装置を含むのデータ保護システムを示す概略構成図。 一実施例による脱着可能な磁気ディスク装置の構成図。 一実施例において使用されるデータ、情報、及び記号法等を示す表図。 一実施例において使用されるデータの復号条件や復号鍵をまとめたデータ（Usage Pass）の構成図。 一実施例による図２の磁気ディスク装置におけるUTモードを実現するUsage Pass Tranfer モジュール530を示す図。 一実施例による記録再生装置におけるUTモードを実現する記録専用の機能モジュールを示す図。 一実施例による記録再生装置におけるUTモードを実現する復号専用の機能モジュールを示す図。 一実施例による記録再生装置におけるUTモードにおいて用いられる、証明書、公開鍵、秘密鍵、Usage Pass転送処理のログ情報などの秘匿情報を記録する、対タンパ性を有する静的な記憶領域を示す図。 一実施例による磁気ディスク装置におけるUTモードにおいて用いられる、証明書、公開鍵、秘密鍵、Usage Pass転送処理のログ情報などの秘匿情報を記録する、対タンパ性を有する静的な記憶領域を示す図。 一実施例による磁気ディスク装置における、Usage Passを記録する、対タンパ性を有する静的な記憶領域を示す図。 磁気ディスク装置における、BTモードを実現する機能モジュールを示す図。 記録再生装置における、BTモードに従って、Usage Pass送信を実現する記録専用の機能モジュールを示す図。 記録再生装置における、BTモードに従って、Usage Pass受信を実現する復号専用の機能モジュールを示す図。 記録再生装置における、BTモードに従って、磁気ディスク装置との間で相互認証処理を実現する機能モジュールを示す図。 記録再生装置における、BTモードにおいて用いられる、証明書、公開鍵、秘密鍵、相互認証処理のログ情報、Usage Pass転送処理のログ情報などの秘匿情報を記録する、対タンパ性を有する静的な記憶領域を示す図。 磁気ディスク装置における、UTモードにおいて用いられる、証明書、公開鍵、秘密鍵、相互認証処理のログ情報などの秘匿情報を記録する、対タンパ性を有する静的な記憶領域を示す図。 一実施例によるUsage Pass転送処理におけるアクセスモードの認識、設定のための処理シークエンスを示す図。 一実施例における、UTモードに従って記録再生装置と記憶装置の間で行われる相互認証処理シークエンスを示す図。 一実施例における、UTモードに従って記録再生装置と磁気ディスク装置の間で行われるUsage Pass転送処理シークエンスを示す図。 一実施例における、UTモードに従って記録再生装置と磁気ディスク装置の間で行われる簡略化された再相互認証処理シークエンスを示す図。 一実施例における、UTモードに従って記録再生装置と磁気ディスク装置の間で行われる、消失したUsage Passの復旧処理シークエンスを示す図。 一実施例における、BTモードに従って記録再生装置と磁気ディスク装置の間で行われる相互認証処理シークエンスを示す図。 一実施例における、BTモードに従って記録再生装置から磁気ディスク装置に対して送信される、Usage Pass転送処理シークエンスを示す図。 一実施例における、BTモードに従って磁気ディスク装置から記録再生装置に対して送信される、Usage Pass転送処理シークエンスを示す図。 一実施例における、BTモードに従って記録再生装置と磁気ディスク装置の間で行われる簡略化された再相互認証処理シークエンスを示す図。 一実施例における、BTモードに従って記録再生装置から磁気ディスク装置に対して送信されたUsage Passが消失した場合における、消失したUsage Passの復旧処理シークエンスを示す図。 一実施例における、BTモードに従って磁気ディスク装置から記録再生装置に対して送信されたUsage Passが消失した場合における、消失したUsage Passの復旧処理シークエンスを示す図。 記憶媒体200の記憶領域の論理的な区分け構成を示す図。 記憶領域の隠し領域28000に記録されるデータの構成を示す図。 記憶装置にコンテンツデータを記録する場合の、記録フォーマットを示す図。 出力制御が必要なコンテンツについて、一つのConnectionが確立されている場合の、一方の機器から他方の機器への出力処理シークエンスを示す図。 出力制御が必要なコンテンツについて、二つのConnectionが確立されている場合の、一方の機器から他方の機器への出力処理シークエンスを示す図。 出力制御が必要なコンテンツについて、二つのConnectionが確立されている場合の、一方の機器から他方の機器への出力処理シークエンスを示す図。 標準の読み出し及び書き込み命令で、出力制御が必要なデータを、一方の機器から他方の機器へ転送する場合の、データのフォーマットを示す図。
符号の説明
100：ネットワークインタフェース、 101：保護情報領域 102：記録モジュール 103：再生モジュール 105：ユーザインタフェースブリッジ 106，107：外部ストレージインタフェース 108：プロセッサ 110：ホストモジュール 111：ホストセキュリティマネージャ 112：記録再生装置 150：配信サーバ 125、126、240：磁気ディスク装置 220：記憶媒体
221：ユーザパス転送モジュール 222：制限記憶制御部 223：制限記憶部 231：プロセッサ

Claims (6)

  1. 記憶装置の記憶領域に記憶された、暗号化されたコンテンツデータを前記記憶装置が外部の転送先装置に転送するコンテンツデータ管理システムであって、
    前記記憶領域は、
    認証条件に充足した所定の場合のみ外部からアドレス指定によりアクセス可能であって、コンテンツデータの出力を制御する制御情報及びエントリ識別情報を当該コンテンツデータと共に記憶するアクセス可能領域と、
    認証条件に充足した所定の場合のみ外部からアクセス可能であって、エントリ識別情報とコンテンツを識別するコンテンツ識別子のフィールドから構成されるエントリを有する隠し領域を有し、
    前記制御情報は、外部の転送先装置にコンテンツデータを復号するための情報があった場合に、コンテンツデータを所定のプロトコルに従って前記外部の転送先装置に対しその出力を許可する第１のモードと、制限なしでその出力を許可する第２のモード、を制御する情報を含み、
    前記記憶装置である第２の装置は、
    前記第２の装置から出力されたコンテンツデータを受信する前記外部の転送先装置である第１の装置との間で相互に正当性の認証処理を行う処理部を有し、
    前記処理部は、
    前記認証処理の結果、正当な場合に前記第１及び第２の装置で鍵データ（共有鍵データ）を共有し、
    前記共通鍵データを用いて該第１及び第２の装置間で転送されるデータを検証し、
    前記隠し領域に記録された前記コンテンツ識別子に関するエントリがあるかを確認し、
    前記第２の装置は、
    読み出し命令を受信し、
    前記アクセス可能領域に記録された前記制御情報が前記第１のモードか又は第２のモードのいずれが設定されているかを確認して、
    前記第１のモードが設定されている場合に、
    読み出し命令が通常命令であった場合は処理を中断し、
    読み出し命令が所定の特殊命令であった場合は、前記共有鍵データからハッシュ値を計算し、前記ハッシュ値を、前記制御情報、コンテンツ識別子、読み出し予定のコンテンツデータに連結し、出力し、
    前記第１の装置は、
    前記第１の装置が記憶装置である場合に、
    書き込み命令を受信し、
    受信したデータに含まれている前記ハッシュ値を検証して成功した場合、前記コンテンツ識別子を含むエントリを確認して、
    前記コンテンツデータを記録するセクタに、前記エントリ識別情報を前記コンテンツ識別子と関連させて記録する、
    ことを特徴とするコンテンツデータ管理システム。
  2. 前記処理部は、
    前記認証処理の結果、正当な場合に前記第１及び第２の装置で２つのセッション鍵を共有し、
    前記セッション鍵及び前記エントリ識別情報及び前記コンテンツ識別子を少なくとも含む、マスクされたUsage Pass（Masked Usage Pass）及び共有した前記セッション鍵からハッシュデータを生成し、
    前記ハッシュデータを前記Masked Usage Passに連結して、転送元の第１又は第２の装置に送信し、
    転送元の前記第１又は第２の装置では、受信したデータを検証して、前記Masked Usage Passに含まれる前記コンテンツ識別子を用いて、前記エントリ識別情報とコンテンツ識別子の関係を確認する、
    ことを特徴とする請求項１のコンテンツデータ管理システム。
  3. 前記処理部は、
    前記処理部の制御によって、前記第１及び第２の両方の装置に対して、前記装置が持つデータの転送機能に関する問合せを行い、
    前記問合せの結果、両装置間のデータ転送に関して、前記制御情報の転送を前記第１の装置から前記第２の装置へ一方向に行なう第１転送モードか、又は前記制御情報の転送を前記両装置の間で双方向に行なう第２転送モードか、のいずれかの転送モードを設定し、
    前記第１及び第２の装置で相互に正当性の認証処理を行い、
    前記認証処理の結果、正当な場合に前記第１及び第２の装置で鍵データ（共有鍵データ）を共有し、
    前記共有鍵データを用いて、前記第１又は前記第２の装置で前記制御情報を暗号化処理し、
    前記設定された前記第１又は第２転送モードに従って、一方の装置で暗号化された前記制御情報を他方の装置へ転送し、
    前記制御情報を受信した前記第１の装置は、前記共有鍵データを用いて前記制御情報を復号化し、
    復号化された前記制御情報を用いてコンテンツデータを復号処理する、
    ことを特徴とする請求項１又は２のコンテンツデータ管理システム。
  4. 前記第１の装置は、
    前記隠し領域から、前記エントリ識別情報と前記コンテンツ識別子のフィールドのエントリを読み出して、テーブル形式で記憶するバッファを有し、
    前記処理部は、
    前記テーブルを検索することで、関連したコンテンツ識別子を記録したエントリが有るかを確認する、
    ことを特徴とする請求項1乃至３のいずれかのコンテンツデータ管理システム。
  5. 前記第１の装置は、
    第２の装置を接続するインタフェースと、
    取得された前記コンテンツデータを記録するための処理を行なう記録モジュールと、
    外部から又は前記インタフェースを介して前記第２の装置から送られた前記コンテンツデータを再生するための処理を行なう再生モジュールと、
    少なくとも前記コンテンツデータを暗号化するために使用される鍵データを保持する第１の保護記憶領域と、
    暗号化された前記コンテンツデータを復号するための鍵データと、
    前記コンテンツデータを復号するための条件を含む制御情報を生成するホストセキュリティマネージャと、
    前記第２の装置との間で行なわれるデータ転送を制御するホスト処理部と、を有し、
    前記第２の装置は、
    少なくとも前記インタフェースを介して前記第１の装置から送られた前記コンテンツデータを記憶するコンテンツ記憶部と、
    少なくとも前記制御情報を保持する前記アクセス可能領域と、
    前記インタフェースを介して前記第１の装置との間でやり取りされる情報の転送制御を行なう転送モジュールと、を有し、
    前記ホスト処理部は、
    前記記録モジュール又は前記再生モジュール、及び前記第２の装置に対して、前記装置が持つデータの転送機能に関する問合せを行い、その問合せの結果、前記第１及び第２の装置間のデータ転送に関して、前記制御情報の転送を前記第１の装置から前記第２の装置へ一方向に行なう第１転送モードか、又は前記制御情報の転送を前記両装置の間で双方向に行なう第２転送モードか、のいずれかの転送モードを設定し、
    前記ホストセキュリティマネージャは、前記第２の装置の特性に関する情報を検証して認証を行い、
    前記第２の装置の前記転送モジュールは、
    前記第１の装置の前記記録モジュール又は前記再生モジュールの特性に関する情報を検証して認証を行い、
    前記認証処理の結果、正当な場合に前記第１の装置及び第２の装置で鍵データ（共有鍵データ）を共有し、
    前記第１転送モードに設定された場合、前記ホストセキュリティマネージャは、生成された前記制御情報を、前記共有鍵データを用いて暗号化処理し、前記暗号化された制御情報を前記インタフェースを介して前記第２の装置へ転送し、
    前記第２転送モードに設定された場合、前記ホストセキュリティマネージャは、生成された前記制御情報を、前記共有鍵データを用いて暗号化処理し、
    前記暗号化された制御情報を前記インタフェースを介して前記第２の装置へ転送し、
    または前記転送モジュールは前記制御情報を前記共有鍵データを用いて暗号化処理し、前記暗号化された制御情報を前記インタフェースを介して前記第１の装置へ転送し、
    前記第１の装置の前記再生モジュールは、
    前記共通鍵データを用いて、受信した前記制御情報を復号化し、
    前記復号化された制御情報を用いて前記コンテンツデータを復号化処理する、
    ことを特徴とする請求項１乃至４のいずれかのコンテンツデータ管理システム。
  6. 前記第２転送モードにおける前記制御情報の転送において、
    前記第１の装置は、
    前記制御情報の処理に関連するトランザクションログを生成して、第１の保護記憶領域に格納し、
    前記制御情報の転送時に正常に処理が行なわれなかった場合、前記第１の装置は前記第１の保護記憶領域に記憶された前記トランザクションログを参照して共有鍵データを生成し、
    前記第２の装置へ送ること、
    を特徴とする請求項１乃至５のいずれかのコンテンツデータ管理システム。
JP2007143396A 2007-05-30 2007-05-30 コンテンツデータ管理システム及び方法 Expired - Fee Related JP5036406B2 (ja)

Priority Applications (4)

Application Number Priority Date Filing Date Title
JP2007143396A JP5036406B2 (ja) 2007-05-30 2007-05-30 コンテンツデータ管理システム及び方法
EP08005858A EP1998268A1 (en) 2007-05-30 2008-03-27 Content data management system and method
CN2008100955708A CN101315796B (zh) 2007-05-30 2008-04-29 内容数据管理系统以及方法
US12/156,209 US8195960B2 (en) 2007-05-30 2008-05-30 Content data management system and method

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
JP2007143396A JP5036406B2 (ja) 2007-05-30 2007-05-30 コンテンツデータ管理システム及び方法

Publications (2)

Publication Number Publication Date
JP2008299494A JP2008299494A (ja) 2008-12-11
JP5036406B2 true JP5036406B2 (ja) 2012-09-26

Family

ID=39580662

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2007143396A Expired - Fee Related JP5036406B2 (ja) 2007-05-30 2007-05-30 コンテンツデータ管理システム及び方法

Country Status (4)

Country Link
US (1) US8195960B2 (ja)
EP (1) EP1998268A1 (ja)
JP (1) JP5036406B2 (ja)
CN (1) CN101315796B (ja)

Families Citing this family (29)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7958370B2 (en) * 2005-09-29 2011-06-07 Hitachi Global Storage Technologies, Netherlands, B.V. System and device for managing control data
DE102008001548B4 (de) * 2008-05-05 2017-03-02 Robert Bosch Gmbh Teilnehmerknoten eines Kommunikationssystems, Kommunikationssystem und Verfahren zum Übertragen einer Nachricht in dem Kommunikationssystem
US20120219269A1 (en) * 2009-09-09 2012-08-30 Hiroyuki Koreeda Content receiver apparatus
JP5657672B2 (ja) * 2009-09-17 2015-01-21 ロイヤル カナディアン ミントＲｏｙａｌ Ｃａｎａｄｉａｎ Ｍｉｎｔ 高信頼性メッセージ記憶、転送プロトコルおよびシステム
US8479011B2 (en) * 2009-10-07 2013-07-02 Gemalto Sa Method and apparatus for using cryptographic mechanisms to provide access to a portable device using integrated authentication using another portable device
US8750683B2 (en) 2009-10-30 2014-06-10 Hitachi Consumer Electronics Co., Ltd. Content-receiving device
JP5018919B2 (ja) * 2010-03-19 2012-09-05 コニカミノルタビジネステクノロジーズ株式会社 情報処理装置、コンテンツ管理方法およびコンテンツ管理プログラム
CN102859539B (zh) 2010-04-23 2016-06-01 日立麦克赛尔株式会社 内容接收装置和内容发布系统
US20120016999A1 (en) * 2010-07-14 2012-01-19 Sap Ag Context for Sharing Data Objects
US9240965B2 (en) 2010-08-31 2016-01-19 Sap Se Methods and systems for business interaction monitoring for networked business process
KR101775971B1 (ko) 2010-10-29 2017-09-07 삼성전자주식회사 저장 장치, 저장 장치의 인증 방법 및 인증 장치
US9170843B2 (en) 2011-09-24 2015-10-27 Elwha Llc Data handling apparatus adapted for scheduling operations according to resource allocation based on entitlement
US9798873B2 (en) 2011-08-04 2017-10-24 Elwha Llc Processor operable to ensure code integrity
US9443085B2 (en) 2011-07-19 2016-09-13 Elwha Llc Intrusion detection using taint accumulation
US9575903B2 (en) * 2011-08-04 2017-02-21 Elwha Llc Security perimeter
US9471373B2 (en) 2011-09-24 2016-10-18 Elwha Llc Entitlement vector for library usage in managing resource allocation and scheduling based on usage and priority
US9460290B2 (en) 2011-07-19 2016-10-04 Elwha Llc Conditional security response using taint vector monitoring
US9298918B2 (en) 2011-11-30 2016-03-29 Elwha Llc Taint injection and tracking
US9465657B2 (en) 2011-07-19 2016-10-11 Elwha Llc Entitlement vector for library usage in managing resource allocation and scheduling based on usage and priority
US9558034B2 (en) 2011-07-19 2017-01-31 Elwha Llc Entitlement vector for managing resource allocation
US9098608B2 (en) 2011-10-28 2015-08-04 Elwha Llc Processor configured to allocate resources using an entitlement vector
FR2984063A1 (fr) * 2011-12-12 2013-06-14 France Telecom Enrichissement, gestion de contenus multimedia et etablissement d'une communication en fonction de contenus multimedia enrichis
EP3629181B1 (en) * 2012-01-24 2022-10-05 SSH Communications Security Oyj Privileged access auditing
KR102186609B1 (ko) 2014-03-07 2020-12-03 삼성전자주식회사 무결성 검증 장치를 포함하는 전자 시스템
US10205658B1 (en) * 2015-01-08 2019-02-12 Marvell Israel (M.I.S.L) Ltd. Reducing size of policy databases using bidirectional rules
CN106909309B (zh) 2015-12-22 2019-12-24 阿里巴巴集团控股有限公司 一种数据信息处理方法以及数据存储系统
CN108632197B (zh) * 2017-03-15 2021-03-05 华为技术有限公司 一种内容验证方法及设备
CN112771890B (zh) * 2018-12-07 2022-05-10 华为技术有限公司 一种点对多点的数据传输方法及电子设备
CN110162438B (zh) * 2019-05-30 2024-03-26 上海市信息网络有限公司 仿真调试装置和仿真调试方法

Family Cites Families (16)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2000347851A (ja) 1999-03-30 2000-12-15 Sony Corp 情報処理装置および方法、並びにプログラム格納媒体
JP3389186B2 (ja) * 1999-04-27 2003-03-24 松下電器産業株式会社 半導体メモリカード及び読み出し装置
JP4127587B2 (ja) * 1999-07-09 2008-07-30 株式会社東芝 コンテンツ管理方法およびコンテンツ管理装置および記録媒体
AU6321200A (en) 1999-08-10 2001-03-13 Fujitsu Limited Memory card
US6898708B2 (en) * 1999-12-07 2005-05-24 Sanyo Electric Co., Ltd. Device for reproducing data
CN1503953A (zh) * 2000-12-08 2004-06-09 ���µ�����ҵ��ʽ���� 分配装置、终端装置以及其中所用的程序和方法
JP2002229861A (ja) * 2001-02-07 2002-08-16 Hitachi Ltd 著作権保護機能つき記録装置
EP1396815B1 (en) * 2001-06-04 2010-11-17 Renesas Electronics Corporation Memory card
JP4891521B2 (ja) 2003-03-28 2012-03-07 三洋電機株式会社 データ入出力方法、およびその方法を利用可能な記憶装置およびホスト装置
JP2005011151A (ja) * 2003-06-20 2005-01-13 Renesas Technology Corp メモリカード
JP4730004B2 (ja) 2004-07-21 2011-07-20 ソニー株式会社 コンテンツ共有システム及びコンテンツ共有方法
JP2006041737A (ja) * 2004-07-23 2006-02-09 Toshiba Corp コンテンツ利用方法及びプログラム
WO2006095335A2 (en) * 2005-03-07 2006-09-14 Noam Camiel System and method for a dynamic policies enforced file system for a data storage device
JP4764103B2 (ja) * 2005-08-18 2011-08-31 株式会社東芝 コンテンツデータ配信システム、及び情報処理装置
US20070056042A1 (en) * 2005-09-08 2007-03-08 Bahman Qawami Mobile memory system for secure storage and delivery of media content
JP4848163B2 (ja) * 2005-09-29 2011-12-28 ヒタチグローバルストレージテクノロジーズネザーランドビーブイ コンテンツデータ管理システム及び装置

Also Published As

Publication number Publication date
US8195960B2 (en) 2012-06-05
CN101315796A (zh) 2008-12-03
EP1998268A1 (en) 2008-12-03
JP2008299494A (ja) 2008-12-11
US20090327718A1 (en) 2009-12-31
CN101315796B (zh) 2012-09-05

Similar Documents

Publication Publication Date Title
JP5036406B2 (ja) コンテンツデータ管理システム及び方法
JP4848163B2 (ja) コンテンツデータ管理システム及び装置
JP4755472B2 (ja) データ転送方法及びシステム
US7958370B2 (en) System and device for managing control data
TW514844B (en) Data processing system, storage device, data processing method and program providing media
JP4555046B2 (ja) データ転送システム及びデータ転送方法
JP4690600B2 (ja) データ保護方法
US8423794B2 (en) Method and apparatus for upgrading a memory card that has security mechanisms for preventing copying of secure content and applications
CN102084373B (zh) 备份存储在安全存储设备中的数字内容
JP4884535B2 (ja) 装置間でのデータオブジェクトの転送
JP5139028B2 (ja) コンテンツデータ管理システム及び方法
US7793041B2 (en) Method for controlling access to data of a tape data storage medium
US20070219917A1 (en) Digital License Sharing System and Method
US20070014403A1 (en) Controlling distribution of protected content
WO2012037247A1 (en) Secure transfer and tracking of data using removable non-volatile memory devices
EP2466511B1 (en) Media storage structures for storing content and devices for using such structures
JP5076546B2 (ja) コンテンツデータ管理システム及び装置
JP2010146635A (ja) コンテンツ記録再生装置並びにコンテンツの書き込み及び読み出し方法
US8345868B2 (en) Data transfer system, data transfer method, data transmission device and data receiving device
JPS63127334A (ja) 保護されたアプリケーションの実行権に条件を付ける方法
KR20070022257A (ko) 디지털 라이센스 공유 시스템 및 방법
JP2011118504A (ja) 記憶装置
AU2005226064A1 (en) Digital license sharing system and method

Legal Events

Date Code Title Description
A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20100204

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20110830

A601 Written request for extension of time

Free format text: JAPANESE INTERMEDIATE CODE: A601

Effective date: 20111125

A602 Written permission of extension of time

Free format text: JAPANESE INTERMEDIATE CODE: A602

Effective date: 20111130

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20120216

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20120306

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20120517

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: 20120605

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: 20120703

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

Free format text: PAYMENT UNTIL: 20150713

Year of fee payment: 3

R150 Certificate of patent or registration of utility model

Free format text: JAPANESE INTERMEDIATE CODE: R150

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

LAPS Cancellation because of no payment of annual fees