JP4755472B2 - データ転送方法及びシステム - Google Patents

データ転送方法及びシステム Download PDF

Info

Publication number
JP4755472B2
JP4755472B2 JP2005283878A JP2005283878A JP4755472B2 JP 4755472 B2 JP4755472 B2 JP 4755472B2 JP 2005283878 A JP2005283878 A JP 2005283878A JP 2005283878 A JP2005283878 A JP 2005283878A JP 4755472 B2 JP4755472 B2 JP 4755472B2
Authority
JP
Japan
Prior art keywords
data
key
usage pass
transfer
devices
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
JP2005283878A
Other languages
English (en)
Other versions
JP2007096783A (ja
JP2007096783A5 (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 JP2005283878A priority Critical patent/JP4755472B2/ja
Priority to TW095130998A priority patent/TW200718144A/zh
Priority to EP06017824A priority patent/EP1770577A1/en
Priority to KR1020060090547A priority patent/KR20070036667A/ko
Priority to CN2006101595946A priority patent/CN101047495B/zh
Priority to US11/541,463 priority patent/US20070168663A1/en
Publication of JP2007096783A publication Critical patent/JP2007096783A/ja
Publication of JP2007096783A5 publication Critical patent/JP2007096783A5/ja
Application granted granted Critical
Publication of JP4755472B2 publication Critical patent/JP4755472B2/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
    • G06F15/00—Digital computers in general; Data processing equipment in general
    • 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]
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F1/00—Details not covered by groups G06F3/00 - G06F13/00 and G06F21/00
    • 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/30—Authentication, i.e. establishing the identity or authorisation of security principals
    • G06F21/44—Program or device authentication
    • G06F21/445—Program or device authentication by mutual authentication, e.g. between devices or programs
    • 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/50—Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems
    • G06F21/57—Certifying or maintaining trusted computer platforms, e.g. secure boots or power-downs, version controls, system software checks, secure updates or assessing vulnerabilities
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/70—Protecting specific internal or peripheral components, in which the protection of a component leads to protection of the entire computer
    • G06F21/78—Protecting specific internal or peripheral components, in which the protection of a component leads to protection of the entire computer to assure secure storage of data
    • G06F21/80—Protecting specific internal or peripheral components, in which the protection of a component leads to protection of the entire computer to assure secure storage of data in storage media based on magnetic or optical technology, e.g. disks with sectors
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/04—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks
    • H04L63/0428—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the data content is protected, e.g. by encrypting or encapsulating the payload
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
    • H04L63/0823—Network architectures or network communication protocols for network security for authentication of entities using certificates
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
    • H04L63/0869—Network architectures or network communication protocols for network security for authentication of entities for achieving mutual authentication
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/06—Protocols specially adapted for file transfer, e.g. file transfer protocol [FTP]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
    • H04L9/0816—Key establishment, i.e. cryptographic processes or cryptographic protocols whereby a shared secret becomes available to two or more parties, for subsequent use
    • H04L9/0838—Key agreement, i.e. key establishment technique in which a shared key is derived by parties as a function of information contributed by, or associated with, each of these
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3263—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving certificates, e.g. public key certificate [PKC] or attribute certificate [AC]; Public key infrastructure [PKI] arrangements
    • H04L9/3268—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving certificates, e.g. public key certificate [PKC] or attribute certificate [AC]; Public key infrastructure [PKI] arrangements using certificate validation, registration, distribution or revocation, e.g. certificate revocation list [CRL]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3271—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using challenge-response
    • H04L9/3273—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using challenge-response for mutual authentication
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/14—Error detection or correction of the data by redundancy in operation
    • G06F11/1402—Saving, restoring, recovering or retrying
    • G06F11/1471—Saving, restoring, recovering or retrying involving logging of persistent data for recovery
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F2221/00—Indexing scheme relating to security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F2221/21—Indexing scheme relating to G06F21/00 and subgroups addressing additional information or applications relating to security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F2221/2129—Authenticate client device independently of the user
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L2209/00—Additional information or applications relating to cryptographic mechanisms or cryptographic arrangements for secret or secure communication H04L9/00
    • H04L2209/56—Financial cryptography, e.g. electronic payment or e-cash
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L2209/00—Additional information or applications relating to cryptographic mechanisms or cryptographic arrangements for secret or secure communication H04L9/00
    • H04L2209/60—Digital content management, e.g. content distribution
    • H04L2209/603—Digital right managament [DRM]

Description

本発明は、データ転送方法及びシステムに係り、更に詳しく言えば、暗号化されたデータの利用を制御するための情報を、記録装置間で転送したり、或いは記憶装置から記録再生装置へ転送するためのプロトコル、及びそのプロトコル処理を行う記録再生装置と記憶装置を含むシステムに関するものである。
音楽データや画像データ等のデジタルデータに著作権が存在する場合、著作権保護のための適切な方策が取られていないと、著作者の権利が侵害される恐れがある。一方、著作権保護の目的を最優先し、ディジタルデータの流通を阻害してしまうと、著作物の複製に際して著作権料を徴収することが可能な著作権者にとっても、かえって不利益となる。
著作権の保護が必要なデータの配信は、主にディジタル通信網や、放送波などを介して行なわれる。これらのデータを利用者が利用する際は、一度何らかの記憶媒体に記録した後、再生装置で再生する場合が多い。現状、容量が大きくアクセス性能が高い制御機能付きの記憶装置としては磁気ディスク装置がある。磁気ディスク装置は、記録再生装置に固定的に内蔵されているものがほとんどで、磁気ディスク装置に記録されたデータを他の再生装置で利用できるようなものは未だ知られていない。しかし、利便性の面から、今後は可搬型の記憶装置の利用が進む可能性がある。一方で、容量は磁気ディスク装置に比べ少ないが、著作権保護機能を伴った可搬型の記憶装置として、いくつかのメモリカードがある。
データを再生する装置としては、このようなデータの配信を受けるのに用いた記録再生装置や、可搬型の専用の再生装置を用いられる。
可搬型の記憶装置を接続できる記録再生装置において、記憶装置に記録されたデータの著作権を保護するためには、記憶装置に記録されたデータを、著作権者が主張する条件の範囲を超えて再生できないように、記録再生装置及び記憶装置にセキュリティ対策を施すことが重要である。セキュリティ対策を機器に施す際には、その装置の内部及び外部から自由にアクセス可能な領域で行なわれるデータの授受に関しては、データの授受が行われる装置の間で認証処理を行ったり、データ自体に暗号化処理等を施したりして、平文で自由にデータへのアクセスが行われることがないようにする必要がある。一方で、このような認証処理や暗号化処理が厳重になるほど、利用者がデータ利用要求を発してから、実際に利用が出来るようになるまでに多くの処理が必要となり、結果としてデータの再生を円滑に行うことができない事態が生じる可能性がある。
例えば、特許文献１及び２には、利用目的のディジタルデータを暗号化する一方で、それを復号するための鍵及び復号した際の利用条件を、不正に取得，改竄などができないようにすることで、著作権を保護することが提案されている。
ＷＯ０１/０１３３５８ ＷＯ０１/０４３３３９
上記文献１及び２に開示された方法は、ディジタルデータを復号するための鍵と利用条件を２つの機器の間で転送する場合、処理の負荷が高い公開鍵の暗復号演算及び証明書の検証処理を必要とする。然るに、上記の従来技術には、下記のようないくつかの問題点がある。
１つには、転送元が正しい機器であるか否かを転送先が認証することが考慮されておらず、それゆえ不正な機器から鍵や利用条件が転送先に送信された場合、それを記録してしまうので、不正アクセスに対して防御できない。
２つには、複数の鍵と利用条件を連続的に送信するような状況についてあまり考慮されておらず、それゆえこれらのデータを送信する度に、転送元と転送先の両機器で、負荷の高い公開鍵暗号演算を行わなければならない。
３つには、証明書で各機器の正当性を判別する場合、証明書と並んで、失効した証明書のリストがシステム全体として用いられるが、上記方法では、転送先の証明書失効リストしか更新できない。
４つには、２つの機器間で鍵や利用条件を転送する場合、認証処理と、鍵や利用条件の転送の方向が固定されており、逆向きの転送を行うためには、認証処理も逆方向で最初からやり直さなくてはならない。これでは、記録再生装置及び記憶装置の双方に大きな負荷を与える。
本発明の目的は、上記のような問題点を解決したデータ転送方法、プログラム及びシステムを提供することにある。
本発明に係る転送方法は、暗号化されたコンテンツデータを復号するための鍵データと、コンテンツデータの利用条件を含む所定の情報を一方の装置から他方の装置へ転送する転送処理方法において、両方の装置で相互に正当性の認証処理を行い、認証処理の過程で得られた共有の鍵データを用いて、一方の装置で所定の情報を暗号化し、予め決められた複数の転送処理方法から、両方の装置間で行なわれる１つの転送処理方法を選択し、選択された転送処理方法に従って、一方の装置で暗号化された所定の情報を他方の装置へ転送する転送処理方法である。
好ましい例では、前記複数の転送処理方法は、所定の情報を一方の装置から他方の装置に対して一定方向へ転送する第１転送モードと、所定の情報を一方の装置と他方の装置との間で双方向に転送する第２転送モード、を含み、
選択されたいずれかの転送モードに従って転送された所定の情報を受信した側の装置は、共有の鍵データを用いて所定の情報を復号化し、復号化された所定の情報を用いて、取得されたコンテンツデータを復号処理する。
また、好ましい例では、暗号化されたコンテンツデータを復号するための鍵データと、コンテンツデータを復号するための条件を含む所定の情報を一方の装置から他方の装置へ転送する転送処理方法において、両装置間のデータ転送を制御する処理手段の制御によって、両方の装置に対して、装置が持つデータの転送機能に関する問合せを行い、問合せの結果、両装置間のデータ転送に関して、所定の情報の転送を一方の方向へ行なう第１転送モードか、又は所定の情報の転送を双方向に行なう第２転送モードか、のいずれかの転送モードを設定し、両方の装置で相互に正当性の認証処理を行い、認証処理の結果、正当な場合に両方の装置で鍵データを共有し、共有された鍵データを用いて、一方の装置で所定の情報を暗号化し、選択された転送モードに従って、一方の装置で暗号化された所定の情報を他方の装置へ転送する転送処理方法として構成される。
また、好ましくは、所定の情報の転送処理時において、両方の装置は、所定の情報の処理に関連するトランザクションログを生成して、記憶手段に記憶し、正当性の認証処理時に鍵データが失われた場合、両方の装置は記憶手段に記憶されたトランザクションログを参照して共有すべき鍵データを生成し、他方の装置へ送る。
また、好ましくは、他方の装置は、記憶手段に記憶されたトランザクションログを参照して、トランザクションログに記録されている処理段階情報と所定の情報の存在状態情報を連結して、一方の装置へ送信し、
一方の装置は、受信した情報を検証して、改竄が行われていないことを確認した後、記憶手段に格納されたトランザクションログを参照して、トランザクションログに記録されている転送前の復号可能条件を、現在存在している所定の情報に上書きする。
また、好ましい例では、前記第２転送モードに設定された場合、前記正当性の認証処理において、他方の装置は、自身の公開鍵が含まれる証明書を一方の装置へ送信し、
一方の装置では、受信した証明書の正当性を検証して、一時的な共通鍵暗号化のための鍵である第１チャレンジ鍵を生成し、受信した公開鍵を用いて第１チャレンジ鍵を暗号化し、生成された暗号化データに自身の公開鍵を含む証明書を連結して、他方の装置に送信し、
他方の装置では、受信したデータを、自身の秘密鍵を用いて復号し、第１チャレンジ鍵を取得し、かつ、一時的な共通鍵暗号化のための鍵である第２チャレンジ鍵を生成し、第２チャレンジ鍵と自身に埋め込まれている公開鍵と連結して、受信した公開鍵で暗号化し、得られた暗号化データに対して、自身の証明書失効リストを連結し、連結したデータを受信した第１チャレンジ鍵で暗号化し、暗号化したデータを一方の装置へ送信し、
一方の装置は、受信したデータを第１チャレンジ鍵で復号し、証明書失効リスト中にあるリストの発行日情報と自身の証明書失効リストが持つ発効日情報とを比較し、その結果、受信した他方の装置の証明書失効リストの発行日が新しければ、他方の装置の証明書失効リストを自らのリストとして更新し、
かつ、復号化したデータから証明書失効リストを除いたデータを自身の秘密鍵で復号化し、更に、一時的な共通鍵暗号化のための鍵である０次第１セッション鍵を生成し、先に受信した他方の装置の公開鍵及び第２チャレンジ鍵で暗号化し、暗号化されたデータを他方の装置へ送信し、
他方の装置は、受信した暗号化データを第２チャレンジ鍵で復号し、この復号化データに一方の装置の証明書失効リストが含まれていた場合は、自らの証明書失効リストを受信した証明書失効リストにより更新し、かつ、証明書失効リスト以外の復号化データを自身に埋め込まれている秘密鍵で復号化し、０次第１セッション鍵を取得する。
また、好ましい例では、前記第２転送モードに設定された場合、前記所定の情報の転送処理において、他方の装置は、n次第２セッション鍵を生成し、以前に生成されたn-１次第２セッション鍵と、その時点で最新のm次第１セッション鍵を用いて、ｎ次第２セッション鍵を暗号化して、暗号化データを一方の装置へ送信し、
一方の装置は、受信した暗号化データをその時点で最新のm次第１セッション鍵及びn-１次第２セッション鍵で復号化し、かつ、転送対象となる所定の情報の識別子、転送における自身の役割、送信予定の所定の情報、及び他方の装置における所定の情報の記録先アドレスを、トランザクションログに記録し、
かつ、所定の情報にその利用目的（少なくとも複製、移動、再生のいずれかを含む）を示すパラメータ及びチェックサムを連結し、n次第２セッション鍵と共有鍵で暗号化し、暗号化されたデータを他方の装置へ送信し、
他方の装置は、受信した暗号化データを共有鍵及びn次第２セッション鍵で復号化し、
復号化されたデータを他方の装置内の記憶領域へ記録する。
また、好ましくは、前記所定の情報は、コンテンツデータの復号化を許容するため条件を含むライセンス情報であって、ライセンス情報を受信した他方の装置は、一方の装置から送信され、記憶手段に記憶していたコンテンツデータを、ライセンス情報を用いて復号化する。
また、好ましくは、前記一方の装置は、取得したコンテンツデータを記録再生する、記録モジュール及び再生モジュールを有する記録再生装置であり、前記他方の装置は、記録再生装置に接続されて、記録再生装置から転送されるコンテンツデータを記憶する記憶装置であり、所定の情報は記録再生装置がコンテンツデータを取得する時に取得され、かつ記憶装置に記録されたコンテンツデータは記憶装置から記録再生装置に転送されて、再生モジュールで再生される。
本発明は、また、特徴的な転送方法の１つとして、次の転送方法を提唱する。すなわち、暗号化されたコンテンツデータを復号するための鍵データと、コンテンツデータを復号するための条件を含む所定の情報を処理して、一方の装置から他方の装置へ転送する処理方法において、
両方の装置で相互に正当性の認証処理を行い、認証処理の結果、正当な場合に両方の装置で鍵データを共有する認証過程（ａ）と、共有された鍵データを用いて、一方の装置で所定の情報を暗号化し、暗号化された所定の情報を一方の装置から他方の装置へ転送する転送過程（ｂ）とを有し、
（ａ）認証処理においては：
他方の装置は、自身の公開鍵が含まれる証明書を一方の装置へ送信し、
一方の装置では、受信した証明書の正当性を検証して、一時的な共通鍵暗号化のための鍵である第１チャレンジ鍵を生成し、受信した公開鍵を用いて第１チャレンジ鍵を暗号化し、生成された暗号化データに自身の公開鍵を含む証明書を連結して、他方の装置に送信し、
他方の装置では、受信したデータを、自身の秘密鍵を用いて復号し、第１チャレンジ鍵を取得し、かつ、一時的な共通鍵暗号化のための鍵である第２チャレンジ鍵を生成し、第２チャレンジ鍵と自身に埋め込まれている公開鍵と連結して、受信した公開鍵で暗号化し、得られた暗号化データに対して、自身の証明書失効リストを連結し、連結したデータを受信した第１チャレンジ鍵で暗号化し、暗号化したデータを一方の装置へ送信し、
一方の装置は、受信したデータを第１チャレンジ鍵で復号し、証明書失効リスト中にあるリストの発行日情報と自身の証明書失効リストが持つ発効日情報とを比較し、その結果、受信した他方の装置の証明書失効リストの発行日が新しければ、他方の装置の証明書失効リストを自らのリストとして更新し、
かつ、復号化したデータから証明書失効リストを除いたデータを自身の秘密鍵で復号化し、更に、一時的な共通鍵暗号化のための鍵である０次第１セッション鍵を生成し、先に受信した他方の装置の公開鍵及び第2チャレンジ鍵で暗号化し、暗号化されたデータを他方の装置へ送信し、
他方の装置は、受信した暗号化データを第２チャレンジ鍵で復号し、この復号化データに一方の装置の証明書失効リストが含まれていた場合は、自らの証明書失効リストを受信した証明書失効リストにより更新し、かつ、証明書失効リスト以外の復号化データを自身に埋め込まれている秘密鍵で復号化し、０次第１セッション鍵を取得する処理を行ない、
（ｂ）転送過程においては：
他方の装置は、n次第２セッション鍵を生成し、以前に生成されたn-１次第２セッション鍵と、その時点で最新のm次第１セッション鍵を用いて、ｎ次第２セッション鍵を暗号化して、暗号化データを一方の装置へ送信し、
一方の装置は、受信した暗号化データをその時点で最新のm次第１セッション鍵及びn-１次第２セッション鍵で復号化し、かつ、転送対象となる所定の情報の識別子、転送における自身の役割、送信予定の所定の情報、及び他方の装置における所定の情報の記録先アドレスを、トランザクションログに記録し、
かつ、所定の情報にその利用目的（少なくとも複製、移動、再生のいずれかを含む）を示すパラメータを連結し、n次第２セッション鍵と共有鍵で暗号化し、暗号化されたデータを他方の装置へ送信し、
他方の装置は、受信した暗号化データを共有鍵及びn次第２セッション鍵で復号化し、
復号化されたデータを他方の装置内の記憶領域へ記録する処理を行なう、転送方法である。
一例では、前記所定の情報には、自身がどのような種類のものに対して出力可能なものであるかを示すフォーマットと、それぞれそれぞれに一意に割り当てられた識別子と、コンテンツデータの利用を制限するための条件を示す情報と、暗号化されたコンテンツデータを解くための鍵データと、関連するコンテンツデータを特定するための識別子と、及びコンテンツの著作権情報が含まれる。
本発明は、また、上記の方法における処理動作をコンピュータ上で実行するためのプログラムとしても把握される。
また、本発明は、上記方法の処理動作を行なうシステムとしても把握される。
本発明によれば、データを復号するための鍵及びデータの利用条件を含む所定の情報を一方の装置から他方の装置へ転送する場合に、両装置の暗号演算に関する負荷を軽減する適切な方法を提供することができる。
また、正当な装置の間で、当該所定の情報を安全に転送することができる。不正な装置へ所定の情報を転送することは転送元の装置によって拒絶され、また不正な装置から所定の情報が送られた場合には、転送先の装置はその受信を拒絶できる。
更に、当該所定の情報を、一方の装置から他方の装置へ転送するシステムにおいて、転送先の装置が有する失効した証明書のリストの方が、転送元の装置が有するリストより新しかった場合、それらの装置間で相互認証処理を実行する間に、転送元のリストで、転送先のリストを更新することができる。
本発明は、以下のような好ましい例において実施される。
前提として、保護が必要なデータは暗号化されること、及び、該データを復号するために必要な鍵データと、復号が許容される条件を１つにまとめられ、それは利用者が自由にアクセスすることができない記憶領域に記録される。この鍵データと、復号が許容される条件を関連付けたものを、以下の例ではユーセジパス（Usage Pass）と呼ぶ。
本発明は、Usage Passを一方のモジュールから他方のモジュールへ転送する場合の、さまざまな処理及びその処理系列について開示するものである。処理系列の種類は２種類ある。その１つは、Usage Passの転送方向が一意に決まるＵＴ（Unidirectional Transfer mode）モードであり、他の１つは双方向にUsage Passを転送することができるＢＴ（Bidirectional Transfer mode）モードである。好ましい例として、このUsage Passの特徴的な転送方法を、２つの機器、例えば記録再生装置と記憶装置の間の転送に適用した場合について述べる。
記録再生装置と記憶装置の間でUsage Pass転送を行なうためには、初めに、２つのモードのうち、いずれのモードでUsage Pass転送を実行するか、記録再生装置内の処理部（以下の例では、ホスト（Host）モジュールという）を選択し、それぞれの装置におけるUsage Pass送信あるいは受信処理を行うモジュールに、選択したモードを通知する処理を行う。以下では、ＵＴモードがUsage Pass送信あるいは受信処理を行うモジュールに設定された場合について、先ず説明する。
ＵＴモードが設定されると、Usage Passを最終的に受信するモジュールが、自身に埋め込まれているDevice Class証明書を、Usage Passを送信するモジュールへ送信する。Device Class証明書には、Device Class公開鍵が含まれる。尚、ＵＴモードでは、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は、一時的な共通鍵暗号化のための鍵である０次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秘密鍵で復号する。続いて、一時的な共通鍵暗号化のための鍵である０次Primal セッション鍵を生成する。この鍵の生成を終えると、先に受信した０次Inceptive セッション鍵で暗号化する。ここで、先に行ったRDCLの発行日情報の比較結果において、Primal RDCLの発行日の方が新しいことが判明した場合は、先に暗号化したデータに、Primal RDCLを連結する。得られたデータは、先に受信したInceptive Device公開鍵で暗号化する。暗号化を終えると、該データをInceptive Deviceへ送信する。
Inceptive Deviceは、受信したデータをInceptive Device秘密鍵で復号する。この復号結果にPrimal RDCLが含まれていた場合は、Inceptive RDCLをPrimal RDCLで上書きする。続いて、残りのデータを０次Inceptive セッション鍵で復号し、０次Primal セッション鍵を得る。
以上が、ＵＴモードにおける認証処理である。これをUT Connection stageと呼ぶ。UT Connection stageを完了すると、０次Primal セッション鍵、０次Inceptive セッション鍵、Inceptive Device公開鍵による暗号化と同秘密鍵による復号化の過程で得られる共有Inceptive Device鍵が共有される。
認証処理を終えると、Usage Pass転送を実行することができる。ＵＴモードにおけるUsage Pass転送は、次のように行われる。尚、ＵＴモードにおける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 セッション鍵の生成を終えると、１つ前のUsage Pass転送時に生成したInceptive セッション鍵（n-１次Inceptive セッション鍵）と０次Primal セッション鍵で暗号化し、Primal Deviceへ送信する。
Primal Deviceは、受信したデータを０次Primal セッション鍵及びn-１次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鍵及び０次Inceptive セッション鍵で復号する。そして、Inceptive Transaction Logにおける転送処理段階要素をRCに更新し、またUsage Passの記録先アドレスをInceptive Transaction Logに記録し、該データをUsage Pass記憶領域へ記録する。
以上が、ＵＴモードにおけるUsage Pass転送処理である。これをUT Transfer stageと呼ぶ。以上に説明したように、ＵＴモードではUsage Passの転送方向は、Primal DeviceからInceptive Deviceに固定されている。
Usage Passの転送処理を実行中に、記録再生装置に電源供給停止等の異常が発生して、Usage Pass転送元及びUsage Pass転送先双方からUsage Passが失われてしまった場合、以下の処理を行うことで、Usage Passを復旧することができる。
異常時には、UT Connection stageにおいて共有された０次Primal セッション鍵、０次Inceptive セッション鍵、共有Device鍵は、記録再生装置及び記憶装置から失われてしまうので、新たにこれらの鍵を共有しなければならない。ただし、UT Connection stageを実行する必要はなく、以下に記す処理を実行すれば良い。
初めに、Hostが、復旧対象のUsage PassのUPIDを、Primal Deviceに送信する。Primal Deviceでは、UPIDを用いて、Primal Transaction Logを検索する。その結果、UPIDを含むPrimal Transaction Logが見つかると、新しい０次Primal セッション鍵を生成する。そして、生成した該セッション鍵を、見つけられたPrimal Transaction Logに記録されていたセッション鍵及びInceptive Device公開鍵で暗号化し、Inceptive Deviceへ送信する。
Inceptive Deviceは、受信したデータを復号し、新しい０次Primal セッション鍵及び共有Devce鍵を得る。
以上が、ＵＴモードにおける再認証処理である。これを、UT Reconnection stageと呼ぶ。UT Reconnection stageを完了すると、新しい０次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へ送信する。この時送信されるデータには、データ、０次Primal セッション鍵、Inceptive Transaction Logに記録されていたInceptive セッション鍵から計算されたHash値も連結される。
Primal Deviceは、受信したHash値を検証し、受信したデータに改竄が行われていないことを確認する。この検証を終えると、受信したUPIDを含むPrimal Transaction Logを検索する。Logが見出されると、Logに記録されている転送前の復号可能条件を、現在存在しているUsage Passに上書きする。
以上が、ＵＴモードにおけるUsage Passの復旧処理である。これを、UT Recovery stageと呼ぶ。このstageを完了すると、Primal Deviceには、送信を行う前のUsage Passが存在するようになる。
次に、ＢＴモードがUsage Pass送信あるいは受信処理を行うモジュールに設定された場合について、説明する。
ＢＴモードでは、Usage Passを転送する方向が固定されておらず、Primal DeviceとInceptive Deviceの双方が、Usage Passの送受信を実行できる。ＢＴモードの下で、記録再生装置にあって相互認証処理や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秘密鍵で復号する。続いて、一時的な共通鍵暗号化のための鍵である０次Primal セッション鍵を生成する。該鍵の生成を終えると、先に受信したInceptive Device公開鍵で暗号化する。ここで、先に行ったRDCLの発行日情報の比較結果において、Primal RDCLの発行日の方が新しいことが判明した場合は、先に暗号化したデータに、Primal RDCLを連結する。得られたデータは、先に受信したInceptive Challenge鍵で暗号化する。暗号化を終えると、データをInceptive Deviceへ送信する。
Inceptive Deviceは、受信したデータをInceptive Challenge鍵で復号する。この復号結果にPrimal RDCLが含まれていた場合は、Inceptive RDCLをPrimal RDCLで上書きする。続いて、残りのデータをPrimal Device公開鍵で復号し、０次Primal セッション鍵を得る。
Primal Deviceは、受信したデータをPrimal Device秘密鍵及び０次Primal セッション鍵で復号し、０次Inceptive セッション鍵を得る。続いて、Inceptive Device公開鍵、０次Inceptive セッション鍵、０次Primal セッション鍵、Inceptive Device Class証明書に含まれる一部のパラメータを、Primal Connection Logに記録する。
以上が、ＢＴモードにおける認証処理である。これをBT Connection stageと呼ぶ。BT Connection stageを完了すると、０次Primal セッション鍵、０次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 セッション鍵を生成する。この鍵の生成を終えると、１つ前のPrimal DeviceからInceptive DeviceへのUsage Pass転送時に生成したInceptive セッション鍵（n-１次Inceptive セッション鍵）と、その時点で最新のPrimal セッション鍵で暗号化し、Primal Deviceへ送信する。
Primal Deviceは、受信したデータをその時点で最新のPrimal セッション鍵及びn-１次Inceptive セッション鍵で復号する。そして、転送対象Usage PassのUPID、転送における自身の役割（転送元）、送信予定のUsage Passを、Transaction Logへ記録する。尚、ＢＴモードでは、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記憶領域へ記録する。
以上が、ＢＴモードにおける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 セッション鍵を生成し、１つ前のInceptive DeviceからPrimal DeviceへのUsage Pass転送で生成されたPrimal セッション鍵（m-１次Primal セッション鍵）と、その時点で最新のInceptive セッション鍵で暗号化し、Inceptive Deviceへ送信する。
Inceptive Deviceは、受信したデータをその時点で最新のInceptive セッション鍵及びm-１次Primal セッション鍵で復号する。続いて、Usage Pass送信用モジュールに準備されたUsage Passから、実際に送信するUsage Passを生成する。そして、Usage Passに利用目的（複製、移動、再生のいずれか）を示すパラメータやChecksumを連結し、m次Inceptive セッション鍵と共有Primal Device鍵で暗号化する。該暗号化を終えると、該データをPrimal Deviceへ送信する。
Primal Deviceは、受信したデータを共有Primal Device鍵及びm次Primal セッション鍵で復号する。
以上が、ＢＴモードにおけるInceptive DeviceからPrimal DeviceへのUsage Pass転送処理である。これをBT IP Transfer stageと呼ぶ。
ＵＴモードと同様に、記録再生装置に異常が発生して、Usage Pass転送元及びUsage Pass転送先双方からUsage Passが失われてしまった場合、以下の処理を行うことで、Usage Passを復旧することができる。ＢＴモードによる再認証処理は、ＵＴモードとは若干異なり、過去にBT PI Transfer stageやBT IP Transfer stageが実行されている必要はなく、BT Connection stageのみが完了していれば良い。
異常時には、BT Connection stageにおいて共有された０次Primal セッション鍵、０次Inceptive セッション鍵、共有Primal Device鍵、共有Inceptive Device鍵は、記録再生装置及び記憶装置から失われてしまうので、新たにこれらの鍵を共有しなければならない。ただし、BT Connection stageを実行する必要はなく、以下に記す処理を実行すれば良い。
初めに、Primal Deviceにおいて、新たな０次Primal セッション鍵を生成し、Primal Connection Logに記録されているInceptive セッション鍵とInceptive Device公開鍵で、生成した該鍵を暗号化する。そして、得られたデータをInceptive Deviceへ送信する。
Inceptive Deviceは、受信したデータをInceptive Connection Logに記録されているInceptive Device秘密鍵及びInceptive セッション鍵で復号する。そして、新たな０次Inceptive セッション鍵を生成し、Inceptive Connection Logに記録されているPrimal セッション鍵とPrimal Device公開鍵で、生成した該鍵を暗号化する。続いて、受信した０次Primal セッション鍵及び生成した０次Inceptive セッション鍵を、Inceptive Connection Logに上書き記録し、先に暗号化したデータを、Primal Deviceへ送信する。
Primal Deviceは、受信したデータをPrimal Device秘密鍵及びInceptive Connection Logに記録されている０次Primal セッション鍵で復号する。そして、得られた新しい０次Inceptive セッション鍵と、先に生成した０次Primal セッション鍵を、Primal Connection Logに上書き記録する。
以上が、ＢＴモードにおける再認証処理である。これを、BT Reconnection stageと呼ぶ。BT Reconnection stageを完了すると、新しい０次Primal セッション鍵、０次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 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-１次Inceptive セッション鍵から計算されたHash値も連結される。尚、この時点で共有されている最新のInceptive セッション鍵は、n-１次のものとする。
Primal Deviceは、受信したHash値を検証し、受信したデータに改竄が行われていないこと、及びInceptive Deviceに先に転送したUsage Passが、過去の転送（送信）処理によって、変化してしまったかどうかを確認する。
上記検証に並行して、Inceptive Deviceでは、n次Inceptive セッション鍵の生成を行う。この鍵の生成を終えると、n-１次Inceptive セッション鍵及びm次Primal セッション鍵で暗号化し、Primal Deviceへ送信する。
Primal Deviceでは、データを受信後、先に述べた検証処理によって、Usage Passが送信処理を実行することによって変化してしまっていることが確認されると、以下に記すUsage Passの復旧処理を実行する。まず、受信したデータを、m次Primal セッション鍵及びn-１次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 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 PI Transfer stageに対するUsage Passの復旧処理である。これを、BT PI Recovery stageと呼ぶ。該stageを完了すると、Primal Deviceには、送信を行う前のUsage Passが存在するようになる。
以下、図面を参照して本発明の実施例について説明する。
システム構成
まず、図１及び図２を用いて、一実施例におけるデータ記録再生装置及びそれに接続可能な記憶装置を含むシステムの全体構成について説明する。
この実施例は、放送されたディジタル映像データや、配信サーバ（Distribution Server）から配信されたディジタルデータ、また他の機器と接続したディジタル信号線を介して送信されたディジタルデータを脱着可能な記憶装置に記録し、また記憶装置に記憶されたデジタルデータを、記録再生装置のディスプレイ装置やスピーカーなどで再生する記録再生システムに適用した例について説明する。以下では、ディジタルデータ記録再生装置を単に記録再生装置といい、記録再生装置が受信する映像や音楽、テキストなどのディジタルデータを、コンテンツデータという。ここで、コンテンツデータを記録する脱着可能な記憶装置は、例えば、磁気ディスク装置や半導体メモリデバイスなどであり、何れも本発明に特徴的な制御機能を有する。以下では、記憶装置として磁気ディスク装置を例に説明するが、これに限るものではない、以下に説明するような本発明に特徴的な機能を有するものであれば、磁気ディスク装置以外の他の周知な記憶装置にも適用できる。
著作権の保護が求められるコンテンツデータは、放送波を介してアンテナ１３１で受信したり、配信サーバ１５０から配信されたものをネットワークインタフェース （Network Interface）１００を介して受信することによって、記録再生装置１１２に取り込まれる。配信されるコンテンツデータは、放送波発信元１３０や配信サーバ１５０において、所定の暗号方式により暗号化されている。その暗号方式は、それぞれのコンテンツ保護仕様によって、独自に規定されていてよい。その際、コンテンツデータを復号するための鍵データ（以下ではこれをコンテンツ鍵と呼ぶ）と、コンテンツデータの利用条件も、別途、記録再生装置１１２に送信される。これらのコンテンツデータを復号するための情報を、以下ではコンテンツデータの復号制御情報と呼ぶ。この復号制御情報は、コンテンツデータの送信元と同一の送信元から送信される場合もあるし、他の送信元から送信される場合もある。
記録再生装置１１２は、脱着可能な記憶装置、例えば磁気ディスク装置１２５、１２６を接続することができる構成を有する。磁気ディスク装置１２５及び１２６には、放送波に乗って送信されたり、配信サーバ １５０から送信されたりした暗号化されたコンテンツデータ及びコンテンツデータの復号制御情報が、記録モジュール（Recording Module）１０２及び保護情報転送モジュール（Protected Information Transmit Module）１０４を介して記録される。また、再生モジュール（Playback Module）１０３には、脱着可能な磁気ディスク装置１２５や１２６から、暗号化されたコンテンツデータや、コンテンツデータの復号制御情報が、保護情報転送モジュール１０４を介して送信される。コンテンツデータの復号及び再生は、記録再生装置１１２内の再生モジュール１０３において行われる。
ところで、コンテンツデータの不正利用を防止するためには、復号制御情報に含まれるコンテンツ鍵が不正に取り出されたり、利用条件が不正に複製されたり、書き換えられたりすることがないようにする必要がある。そのためには、記録再生装置１１２や脱着可能な磁気ディスク装置１２５及び１２６内において復号制御情報の送受信を行ったり、情報を記録したり読み出したりする部分は、対タンパ性を持つように実装することが重要である。そのような部分は、記録再生装置１１２ではホストセキュリティマネージャ（Host Security Manager）１１１であり、磁気ディスク装置においては、ストレージセキュリティマネージャ（Storage Security Manager）２２５である。尚、ホストセキュリティマネージャ １１１内の保護情報領域（Protected Information Storage）１０１の役割や、ストレージセキュリティマネージャ ２２５内のUsage Pass転送モジュール（Usage Pass Transfer Module）２２１、制限記憶コントローラ（制限記憶部 Controller）２２２、制限記憶部（Qualified Storage）２２３の具体的な役割については、後に説明する。本発明に係る実施例では、ホストセキュリティマネージャ（Host Security Manger）１１２及びストレージセキュリティマネージャ２２５内にあるモジュール間で、復号制御情報を送受信し合うための転送プロトコルに関するものである。尚、ここで、記録再生装置１１２及び磁気ディスク装置１２５、１２６における各モジュール及びセキュリティマネージャ等の機能の実現手段としてはハードウェア又はソフトウェアの何れによって構成されてもよい。
一方で、記録再生装置１１２の中で、ネットワークとの間のネットワークインタフェース１００や、入力デバイスとの間のインタフェースブリッジ部１０５、磁気ディスク装置との間のインタフェース１０６及び１０７、及びこれらを制御するプロセッサ（ＰＵ）１０８などは、全体として、システム内部を流れるデータの処理や受け渡しを制御する機能を有する。その意味で、以下ではこれらをまとめてホストモジュール（Host Modules）１１０と呼ぶ。
モジュール間での相互認証とUsage Pass転送方式の概略
放送波に乗せられて送信されるコンテンツデータや、他の媒体に記録されているコンテンツデータは、一般的には独自に規定された方式で暗号化されている。また、データには、その復号制御情報も含まれていることが多い。これらのデータを、アンテナ１３１やディジタル信号線１３２を介して記録再生装置１１２が取り込む場合、記録モジュール１０２は、規定された方式に従ってコンテンツデータを復号し、また復号制御情報を取り出す。取り出された復号制御情報は、本実施例において定める特定の形式を持った１つのデータにまとめられる。これを、以下ではUsage Passと呼ぶ。Usage Passの具体的な構造については、後に図４を用いて説明する。
記録モジュール １０２はUsage Passを生成すると、それを磁気ディスク装置１２５あるいは１２６に対して送信する。ただし、本送信が完了するためには、それに先立って、記録モジュール１０２もしくは保護情報転送モジュール１０４とUsage Pass転送モジュール２２１の間では、相互認証が完了しなければならない。認証処理が完了すると、いくつかの鍵データが共有される。そして、転送対象のUsage Passは、共有された鍵を用いて、暗号化された後、記録モジュール１０２からUsage Pass転送モジュール２２１に対して送信される。
本発明は、鍵を共有するまでの認証処理方法と、認証処理によって共有された鍵を用いてUsage Passを暗号化し、転送する処理方法に関するものである。その処理方法は、２種類ある。その１つは、２つのモジュール間で相互認証が終了すると、Usage Passの転送方向が一意に確定してしまう方法であり、他の１つは双方向にUsage Passを転送することができる方法である。以下では、前者による相互認証及びUsage Pass転送方式を単一方向転送モード（Unidirectional Transfer mode）（略してＵＴモード）と呼び、後者による相互認証及びUsage Pass転送方式を双方向転送モード（Bidirectional Transfer mode）（略してＢＴモード）と呼ぶ。これらのモードを総称して、制限アクセス（Qualified Access）モードと呼ぶ。モジュール間でUsage Passを転送する際、いずれのモードで相互認証及びUsage Pass転送を行うかは、記録再生装置を起動する際、ホストモジュール（Host Module）１１０が決定する。
磁気ディスク装置では、Usage Pass転送モジュール ２２１がUsage Passを受信すると、それを制限記憶コントローラ２２２へ送信する。制限記憶コントローラは、制限記憶部２２３を制御するモジュールである。Usage Pass本体は、最終的には制限記憶部２２３に記録される。尚、配信サーバ１５０が磁気ディスク装置へUsage Passを送信する場合や、ある磁気ディスク装置から他の磁気ディスク装置へUsage Passを転送する場合は、Usage Passの転送元となるモジュールが、転送先となる磁気ディスク装置内のUsage Pass転送モジュールに対して、本発明で定める方式に従って、直接Usage Passを送信しても良い。この場合、記録再生装置１１２内のネットワークインタフェース１００や記録モジュール１０２は、データの一方から他方のモジュールへの転送を制御するたけで、相互認証処理やUsage Passの暗号化には直接関係しない。
次に、図２を参照して、磁気ディスク装置の構成について説明する。
磁気ディスク装置には、インタフェース部２２０を介してデータが入出力される。Usage Passのような保護が必要なデータ以外のデータが外部から入力される場合、コントローラ２３０を介して、ヘッド部２０２から磁気ディスク円盤２００上に記録される。暗号化されたコンテンツデータも、このフローに従って、磁気ディスク円盤２００上に記録される。読み出す場合は、前述を逆にデータが流れる。コントローラ２００は、プロセッサ（ＰＵ）２３１からも制御される。Usage Pass転送モジュール２２１や制限記憶コントローラ２２２なども、プロセッサ２３１によって制御される。図２では、制限記憶部２２３は磁気ディスク円盤２００とは別に設けられているが、暗号化されたコンテンツデータの読み出しと書き込みとは異なる特殊なアクセス方法でのみアクセスが許容されていて、また本装置を分解等し内部のデータを直接読み出す等を行うことが不可能な構成になっていれば、制限記憶部は磁気ディスク円盤２００上に設けても良い。
システムの鍵およびデータの構成
図３は、図１及び図２に示した機器において、記録モジュール１０２、再生モジュール１０３、及びUsage Pass転送モジュール２２１の間でUsage Pass転送を実行する際、それを暗号化するために用いられる鍵データ、及び配信するデータ等の一覧を示すものである。
通常、鍵データＸが対称暗号用の鍵データである場合は、対象のデータは鍵データＸを用いて暗号化されており、その復号も同一の鍵データＸを用いて行われる。一方、鍵データＸが非対称暗号用の秘密鍵あるいは公開鍵であった場合は、暗号化対象のデータは、Ｘとは異なるこれらに対応する公開鍵あるいは秘密鍵Yを用いて暗号化されている。Ｙを用いて暗号化されたデータは、Ｘを用いて復号される。以下では、非対称暗号用公開鍵データを公開鍵、非対称暗号用秘密鍵データを秘密鍵、対称暗号用鍵データを共通鍵と略す。
データに電子署名が付けられている場合、データを一部に含むデータ集合のハッシュ値が、公開鍵Ｘに対応する秘密鍵Ｙで暗号化されていることを意味する。
尚、本明細書中でK_xのように表記されているものは、全ての図ではxは添え字として表現されている。
コンテンツデータの暗号化、復号及び再生処理、Usage Passの暗号化及び復号化、記録モジュール １０２、再生モジュール１０３、磁気ディスク装置１２５及び１２６、配信サーバ１５０の認証に関わる鍵として、以下のものがある。
コンテンツデータを暗号化および復号するための鍵は、コンテンツ鍵K_cである。配信サーバ１５０、記録モジュール１０２、再生モジュール１０３、Usage Pass転送モジュール ２２１には、それぞれ個別に互いに認証を行うための電子署名付き公開鍵KP_dcがそれぞれ割り当てられる。ただし、ホストセキュリティマネージャ １１１を全体として１つの対タンパ性を持つ機能単位として実装する場合、ホストセキュリティマネージャ １１１に対して１つのKP_dcを割り当てても良い。
公開鍵KP_dcにより暗号化されたデータは、これに対応する秘密鍵K_dcによって復号可能である。これらの秘密鍵データは、配信サーバ１５０、記録モジュール１０２、Usage Pass転送モジュール２２１、再生モジュール１０３について、それぞれのある有限個に対して、１つ割り当てられる。有限個という意味は、１つでも複数個でも良いことを意味する。KP_dc及びK_dcを共有する単位をClassと呼ぶ。１つのClassに対しては、Usage Passを転送したり、記録したりする部分が、実装する際に満たさなければならない安全性のレベルや、１つのUsage Pass転送方式が規定される。つまり、あるClassに属する複数のモジュールは、全てがそのClassで規定された安全性のレベルを満たす形で実装されており、また１つの共通した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秘密鍵は、全てのデバイスに異なったものが埋め込まれる。
尚、公開鍵による暗号化の過程では、暗号化に用いられる公開鍵を元にして、１つの共通鍵が生成される。これは、*KP_dのように表される。同様に、秘密鍵による復号化の過程では、復号に用いられる秘密鍵を元にして、１つの共通鍵が生成される。これは、*K_dのように表される。*KP_dと*K_dは、実際には同一の値であり、*KP_dで暗号化されたデータは、*K_dで復号することができる。これらの共通鍵を、それぞれ共有Device公開鍵及び共有Device秘密鍵と呼ぶ。これらの鍵の生成方法については、後に公開鍵暗号化方法に関する説明をする際、更に詳細に説明する。
さらに、図１に示したシステムにおいて、使用される鍵等として以下のものがある。異なる２つのデバイス間でUsage Pass転送を行う度に、Usage Passを暗号化するために、主にUsage Passの転送先において生成される共通鍵K_sn（n ≧０）、及びデバイス間で相互認証処理の最終段階において両デバイスで共有されるK_s０を暗号化するために生成される共通鍵K_chである。K_ch及びK_s０は、デバイス間の相互認証処理において共有される鍵で、Usage Pass転送の際にそれを暗号化するためには利用されない。一方K_sn（n ≧ １）については、Usage Pass転送を実行する度に、必ずK_snからK_sn+１へ更新されてから利用される。以後、K_chをChallenge鍵、K_sn（n ≧ ０）をセッション（Session）鍵と呼ぶ。特に、nが０の場合のセッション鍵を、０次のセッション鍵と呼ぶ。
各鍵に対しては、[P]もしくは[I]の添え字が与えられる。これは、鍵が、Primal Device及びInceptive Deviceのいずれで生成された（あるいは埋め込まれた）か、を示すものである。ここでPrimal Deviceとは、あるデバイスが他のデバイスとの間で相互認証を行う場合に、相手となるデバイスから送信されたDevice Class証明書の検証を最初の処理で行うもののことである。一方、Inceptive Deviceとは、同様の場合に、自身のDevice Class証明書を相手となるデバイスに送信することを最初の処理で行うもののことである。
以上に説明した鍵を用いて行う暗号化をE(X, Y)と表す。これは、データＹを、鍵データＸを用いて暗号化することを表す。同様に復号化を、D(X, Y)と表す。これは、データＹを、鍵データＸを用いて復号することを表す。また、H(X)はデータXのハッシュ値を、X || YはデータXとデータYを連結することを表す。これらの表記法は、ＵＴモード、ＢＴモードいずれの場合にも全て共通のものである。
尚、ＵＴモードではUsage Passの転送方向が一意に確定してしまうと以前に述べたが、その方向は常にPrimal DeviceからInceptive Deviceである。従ってＵＴモードでは、記録モジュール１０２は常にPrimal Deviceとなり、再生モジュール １０３は常にInceptive Deviceとなる。一方、磁気ディスク装置は、記録モジュールから送信されたUsage Passを記録する場合はInceptive Deviceとなり、コンテンツデータの復号再生などを目的に自身からUsage Passを再生モジュールへ送信する場合は、Primal Deviceとなる。
これに対し、ＢＴモードでは、ホストセキュリティマネージャを有する装置が常にPrimal Deviceとなり、磁気ディスク装置は常にInceptive Deviceとなるが、Usage Passの転送は、Primal DeviceからInceptive DeviceへもInceptive DeviceからPrimal Deviceへも可能である。
Usage Passの構成
Usage Passの構造について、図４を用いて説明する。
Usage Passには、自身がどのような種類のモジュールに出力可能なものであるかを示すUsage Pass Format４００、それぞれに一意に割り当てられた識別子ＵＰＩＤ４０１、対象コンテンツデータの利用を制限するための条件４０２及び４０４、暗号化されたコンテンツデータを解くための鍵データK_c ４０３、対応するコンテンツデータを特定するための識別子ＣＩＤ４０５、コンテンツの著作権情報４０６が含まれる。対象コンテンツデータの利用を制限するための条件には、Usage Passの転送元で内容を解釈しその出力を制御するための制御情報UR_s ４０２０（Usage Passの転送元には、通常記録モジュールや磁気ディスク装置がなりうる）と、再生モジュール １０３がUsage Pass及びコンテンツデータを受信後、モジュールにおけるコンテンツデータの復号処理を制御するための制限情報UR_p ４０４０とがある。UR_s ４０２０には、Usage Passが複製された場合の世代情報を表すGeneration Count、自身からUsage Passの複製可能な回数を表すCopy Count、自身のUsage Passを使ってコンテンツデータの復号可能な回数を表すPlay Countなどが含まれる。
ＵＴモードでのUsage Pass転送が実行可能なUsage Pass転送モジュールの構成
図５を用いて、ＵＴモードでのUsage Pass転送が実行可能なUsage Pass転送モジュール２２１の構成について説明する。
Usage Pass転送モジュール５３０の中には、他のデバイスとの間で相互認証を行う場合に、自身がPrimal Deviceとなって必要な処理を行うための機能を持ったモジュール５００、自身がPrimal DeviceとなってUsage Passの転送を行うための機能を持ったモジュール５０１、自身がInceptive Deviceとなって必要な処理を行うための機能を持ったモジュール５０２、自身がInceptive DeviceとなってUsage Passの転送を行うための機能を持ったモジュール５０３、利用者の意思による書き換えが行えないような静的な記憶領域５０４、Usage Pass転送を実行した際、処理が正常に終了しなかった場合に、対象のUsage Passが転送元デバイス及び転送先デバイスいずれからも失われてしまうことを避けるための、Usage Passの復旧機能を有するモジュール５０５、及び制限記憶コントローラ２２２へUsage Passを送信する前に一時的にそれを蓄積しておいたり、制限記憶部から読み出したUsage Passを一時的に蓄積しておいたりするためのUsage Pass Buffer ５１０が設けられている。認証用モジュール ５００及び５０２、Usage Pass暗号化及び送信用モジュール ５０１、Usage Pass受信及び復号化モジュール５０３、Usage Pass復旧用モジュール５０５などは、必要に応じて、記憶領域５０４へアクセスする。記憶領域５０４は、保護情報領域と呼ばれる。
磁気ディスク装置の外部と各モジュールとの間でのデータのやりとりは、インタフェース５２０及びバス５４０を介して行なわれる。ＰＵ５２１は、図２における２３１と同じものである。
各モジュールが実際に持っている機能については、図１７から図２０を用いて相互認証処理及びUsage Pass転送処理を具体的に説明する中で、詳細に説明する。また、保護情報領域 ５０４に記録されるデータの種類等については、図９を用いて後で説明する。
ＵＴモードでのUsage Pass送信が実行可能な記録再生装置内の記録モジュールの構成
図６を用いて、ＵＴモードでのUsage Pass送信が実行可能な記録モジュール １０２の構成について説明する。尚、ＵＴモードによるUsage Passの転送を行う機能を記録再生装置で実現する場合は、図１における保護情報転送モジュール１０４は、特に必要ではないため、描かれていない。
ＵＴモードでは、記録モジュールは常にPrimal Deviceとなる。そこで、記録モジュール ６２５の中には、他のデバイスとの間で相互認証を行う場合に、自身がPrimal Deviceとなって必要な処理を行うための機能を持ったモジュール６００、自身がPrimal DeviceとなってUsage Passの送信を行うための機能を持ったモジュール６０１、Usage Pass送信処理を実行した際、処理が正常に終了しなかった場合に、対象のUsage Passが転送元デバイス及び転送先デバイスいずれからも失われてしまうことを避けるための、Usage Passの復旧機能を有するモジュール６０５、及び外部からコンテンツデータ及び利用権情報を入手し、コンテンツ鍵を生成し、鍵でコンテンツを暗号化し、鍵を含むUsage Passを生成する機能を有するモジュール６０６が設けられている。暗号化されたコンテンツは、モジュール６０６からデータバス６４０へ、External Storage Interface ６２０を介して、磁気ディスク装置へ記録される。
記録モジュールを含むホストセキュリティマネージャ６３０には、利用者の意思による書き換えが行えないような静的な記憶領域６０４が設けられており、認証用モジュール６００やUsage Pass暗号化及び送信用モジュール６０１、Usage Pass復旧用モジュール６０５などは、必要に応じて、記憶領域へアクセスする。記憶領域６０４は、保護情報領域と呼ばれる。
各モジュールが実際に持っている機能については、図１７から図２０を用いて相互認証処理及びUsage Pass転送処理を具体的に説明する中で、詳細に説明する。また、保護情報領域５０４に記録されるデータの種類等については、図８を用いて後で説明する。
ＵＴモードでのUsage Pass受信が実行可能な記録再生装置内の再生モジュールの構成
図７を用いて、ＵＴモードでのUsage Pass受信が実行可能な再生モジュール１０３の構成について説明する。記録モジュールと同様に、ＵＴモードでUsage Passの転送を行う機能を記録再生装置で実現する場合は、図１における保護情報転送モジュール１０４は、特に必要ではないため、描かれていない。
ＵＴモードでは、再生モジュールは常にInceptive Deviceとなる。そこで、再生モジュール７２５の中には、他のデバイスとの間で相互認証を行う場合に、自身がInceptive Deviceとなって必要な処理を行うための機能を持ったモジュール７００、自身がInceptive DeviceとなってUsage Passの受信を行うための機能を持ったモジュール７０３、Usage Pass受信処理を実行した際、処理が正常に終了しなかった場合に、対象のUsage Passが転送元デバイス及び転送先デバイスいずれからも失われてしまうことを避けるための、Usage Passの復旧機能を有するモジュール６０５、及び受信したUsage Passから、Usage Passに含まれるUR_pに記載されている内容を解釈し、それに従って暗号化されたコンテンツデータを復号する機能を有するモジュール ７０６が設けられている。この時、暗号化されたコンテンツデータは、External Storage Interface７２０及びデータバス７４０を介して、モジュール７０６に送信される。復号されたコンテンツデータは、保護されたデータ通信路等を通る形で、モジュール７０６から直接再生モジュール外へ出力される。
再生モジュールを含むホストセキュリティマネージャ７３０には、利用者の意思による書き換えが行えないような静的な記憶領域７０４が設けられており、認証用モジュール ７０２や、Usage Pass受信及び復号化用モジュール７０３、Usage Pass復旧用モジュール ７０５などは、必要に応じて、この記憶領域をアクセスする。記憶領域７０４は、保護情報領域と呼ばれる。
各モジュールが実際に持っている機能については、図１７から図２０を用いて相互認証処理及びUsage Pass転送処理を具体的に説明する中で、詳細に説明する。また、保護情報領域５０４に記録されるデータの種類等については、図８を用いて後で説明する。
ホストセキュリティマネージャ内にあるＵＴモード用保護情報領域の構成
図８を用いて、記録再生装置におけるＵＴモード用の保護情報領域の構成を説明する。
記憶領域８１９は、記録モジュール１０２がアクセスする領域である。一方、記憶領域８３９は、再生モジュール１０３がアクセスする領域である。記憶領域８１９と８３９には、同じ種類のデータが保持もしくは記録される。それらは、次の通りである。
８０１及び８２１は、Device Class証明書である。Device Class証明書８０１には、Device Class公開鍵８００が、同様にDevice Class証明書８２１にはDevice Class公開鍵８２０が含まれる。Device Class証明書は、含まれるDevice Class公開鍵の正当性を証明するものであり、電子署名が含まれる。電子署名部は、認証局秘密鍵K_CAで暗号化されている。
８０３及び８２３は認証局公開鍵、８０４及び８２４はDevice Class秘密鍵、８０５及び８２５はDevice公開鍵、８０６及び８２６はDevice秘密鍵である。
以上の証明書及び鍵情報は、初期の実装時に埋め込まれているもので、後で更新されるものではない。
これに対し、８０２及び８２２、８１０、８１１、８３０、８３１は、相互認証処理やUsage Pass転送処理において、更新される情報である。ここで８０２及び８２２は、失効したDevice Classのリストである。このリストを、以下ではRDCLと呼ぶ。あるDevice Class公開鍵KP_dcの安全性が失われると、KP_dcを含む証明書の固有番号を、このリストに登録する。他のデバイスから送られたDevice Class証明書の検証を行う際には、電子署名部を用いて証明書に改竄が行われていないことを確認すると共に、証明書の固有番号が、リストに登録されていないかどうかについても確認する。また、８１０、８１１、８３０、８３１は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を復旧することができるようになる。これらのデータを記録するタイミングについては、図１７から図２０を用いて相互認証処理及びUsage Pass転送処理を具体的に説明する中で、詳細に説明する。
ここで、Type Mapについて説明しておく。Type Mapは、前述の通り、「受信可能なUsage Pass Formatに関する情報」を示すものである。この情報はDevice Class証明書に含まれており、その意味で認証処理中に認証相手となるデバイスに送られる。認証相手のデバイスは、自身がUsage Pass転送元であった場合に、どういった類のUsage Passであれば相手のデバイスが受信可能であるかを、Type Mapによって判断する。例えば、あるUsage PassのUsage Pass Formatが「Type ０」を示していた場合に、認証相手デバイスから送信された証明書中のType Mapが「Type ０受信不可」となっていた場合、Usage Passの転送元デバイスは、Usage Passの転送処理を行わない。
尚、図８では、保護情報領域において、記録モジュール用の記憶領域と、Playback用の記憶領域が分離され、それぞれの記憶領域にDevice Class証明書や認証局公開鍵、Device Class秘密鍵、Device公開鍵、Device秘密鍵、Transaction Log記録領域、失効されたDevice Classのリスト等が記録される形となっているが、必ずしもそのように実装する必要はない。つまり、１つのDevice Class証明書や認証局公開鍵、Device Class秘密鍵、Device公開鍵、Device秘密鍵を、記録モジュールと再生モジュール双方が用い、Transaction Log記録領域やRDCLの記録領域は共用領域として実装する形でも良い。
Usage Pass転送モジュール２２１内にある保護情報領域の構成
図９を用いて、磁気ディスク装置におけるＵＴモード用の保護情報領域の構成を説明する。図示するように、Usage Pass転送モジュール２２１内に設けられる保護情報領域５０４に記録されるデータは、図８における記録モジュール用に保持及び記録されるProtected Information８１９、あるいは再生モジュール用に保持及び記録されるProtected Information８３９と同じである。つまり、１つのDevice Class証明書９０１、１つの認証局公開鍵９０３、１つのDevice Class秘密鍵９０４、１つのDevice公開鍵９０５、１つのDevice秘密鍵９０６が埋め込まれ、また１つのRDCLを記録する領域９０２、適切な数のTransaction Logを記録する領域が設けられる。Device Class証明書９０１とそれぞれの鍵９０３、９０４、９０５、９０６は、磁気ディスク装置がPrimal Deviceとなる場合もInceptive Deviceとなる場合も利用される。Transaction Log記録領域も同様である。RDCLの更新は、磁気ディスク装置がPrimal Deviceとなる場合もInceptive Deviceとなる場合も、更新されうる。RDCLの更新基準は、後に図１７を用いて説明する。
制限記憶部２２３の構成
図１０を用いて、制限記憶部２２３の構成について説明する。制限記憶部２２３は、磁気ディスク装置の中にあって、記録モジュールや他の磁気ディスク装置から送られてきたUsage Passを記録し、保持する部分である。Usage Passの記録は、制限記憶コントローラ２２２によって制御される。制限記憶部２２３は、Usage Pass本体が記録される領域１０００、１０１０、１０２０等と、Usage Passの有効性を示すフラグを記録する領域１００１、１０１１、１０２１等から成る。以降、フラグを有効性指示フラグと呼ぶ。１００１に書き込まれた有効性指示フラグは領域１０００に書き込まれたUsage Passの有効性を、１０１１に書き込まれた有効性指示フラグは領域１０１０に書き込まれたUsage Passの有効性を、１０２１に書き込まれた有効性指示フラグは領域１０２０に書き込まれたUsage Passの有効性を示すものである。Usage Pass及び有効性指示フラグを記録する領域は、前記のようにペアを構成し、前記と同様に制限記憶部２２３内に多数設けられる。各々の有効性指示フラグ領域には、フラグとペアとなっている領域に有効なUsage Passが書き込まれると、制限記憶コントローラ ２２２によって、「有効」を示す値が記録される。一方、一度書き込まれたUsage Passを再生モジュールや他の磁気ディスク装置へ出力して後は、領域には「無効」を示す値が記録される。また、完全な初期状態においては、「未記録」を示す値が記録される。尚、制限記憶部に記録されているUsage Passの読み出しは、制限記憶コントローラ ２２２によって行われる。
ＢＴモードでのUsage Pass転送が実行可能なUsage Pass転送モジュールの構成
図１１を用いて、ＢＴモードでのUsage Pass転送が実行可能なUsage Pass転送モジュールの構成について説明する。
ＢＴモードでは、磁気ディスク装置は常にInceptive Deviceとなる。そこで、Usage Pass転送モジュール１１３０の中には、他のデバイスとの間で相互認証を行う場合に、自身がInceptive Deviceとなって必要な処理を行うための機能を持ったモジュール １１０２、自身がInceptive DeviceとなってUsage Passの転送を行うための機能を持ったモジュール１１０３、利用者の意思による書き換えが行えないような静的な記憶領域１１０４、Usage Pass転送を実行した際、処理が正常に終了しなかった場合に、対象のUsage Passが転送元Device及び転送先Deviceいずれからも失われてしまうことを避けるための、Usage Passの復旧機能を有するモジュール１１０５、及び制限記憶コントローラ２２２へUsage Passを送信する前に一時的にそれを蓄積しておいたり、制限記憶部から読み出したUsage Passを一時的に蓄積しておいたりするためのUsage Pass Buffer １１１０が設けられている。また、静的な記憶領域１１０４は、ＵＴモードの場合と同様に保護情報領域と呼ばれる。ただし、ここに記録されるデータは、５０４に記録されるデータとは、若干異なる。認証用モジュール１１００は、必要に応じて、記憶領域へアクセスする。
磁気ディスク装置の外部と各モジュールとの間でのデータのやりとりは、インタフェース１１２０及びバス１１４０を介して行なわれる。ＰＵ１１２１は、図２における２３１と同じものである。各モジュールが実際に持っている機能、保護情報領域 １１０４に記録されるデータの種類等については、図１５及び図２１から図２６を用いて、後で説明する。
ＢＴモードでのUsage Pass送信が実行可能な記録再生装置内の記録モジュールの構成
図１２を用いて、ＢＴモードでのUsage Pass送信が実行可能な記録モジュール１０２の構成について説明する。
ＢＴモードでは、Host Security Manager１１１全体が常にPrimal Deviceとして動作し、Usage Passは、Host Security Manager１１１に対して双方向に流れる。そこで、記録モジュール１２２５は、Usage Passを出力するために必要な機能のみ包含し、Inceptive Deviceとの間で相互認証を行うための機能などは、保護情報転送モジュール１０４が含む構成とした方が適切である。そこで記録モジュールには、自身がPrimal DeviceとなってUsage Passの送信を行うための機能を持ったモジュール１２０１、Usage Pass送信処理を実行した際、処理が正常に終了しなかった場合に、対象のUsage Passが転送元デバイス及び転送先デバイスいずれからも失われてしまうことを避けるための、Usage Passの復旧機能を有するモジュール１２０５、及び外部からコンテンツデータ及び利用権情報を入手し、コンテンツ鍵を生成し、鍵でコンテンツを暗号化し、鍵を含むUsage Passを生成する機能を有するモジュール１２０６が設けられている。暗号化されたコンテンツデータは、モジュール１２０６からデータバス１２４０へ、External Storage Interface１２２０を介して、磁気ディスク装置へ記録される。
記録モジュールを含むホストセキュリティマネージャ１２３０には、利用者の意思による書き換えが行えないような静的な記憶領域１２０４が設けられており、認証用モジュール１２００やUsage Pass暗号化及び送信用モジュール１２０１、Usage Pass復旧用モジュール１２０５などは、必要に応じて、この記憶領域へアクセスする。記憶領域１２０４は、保護情報領域と呼ばれる。
各モジュールが実際に持っている機能については、図２２から図２７を用いて相互認証処理及びUsage Pass転送処理を具体的に説明する中で、詳細に説明する。また、保護情報領域 １２０４に記録されるデータの種類等については、図１５を用いて後で説明する。
ＢＴモードでのUsage Pass受信が実行可能な記録再生装置内の再生モジュールの構成
図１３を用いて、ＢＴモードでのUsage Pass受信が実行可能な再生モジュール１０３の構成について説明する。
ＢＴモードでは、再生モジュールは、記録モジュールと同様に、常にPrimal Deviceとなる。記録モジュールについて説明した際にも述べたように、ホストセキュリティマネージャがPrimal DeviceとなってInceptive Deviceと相互認証を行うための機能は、保護情報転送モジュール１０４が担う。そこで、再生モジュール１３２５には、自身がPrimal DeviceとなってUsage Passの受信を行うための機能を持ったモジュール１３０３、Usage Pass受信処理を実行した際、処理が正常に終了しなかった場合に、対象のUsage Passが転送元デバイス及び転送先デバイスいずれからも失われてしまうことを避けるための、Usage Passの復旧機能を有するモジュール１３０５及び１３０１、及び受信したUsage Passから、Usage Passに含まれるUR_pに記載されている内容を解釈し、それに従って暗号化されたコンテンツデータを復号する機能を有するモジュール１３０６が設けられている。この時、暗号化されたコンテンツデータは、External Storage Interface １３２０及びデータバス１３４０を介して、モジュール１３０６に送信される。復号されたコンテンツデータは、保護されたデータ通信路等を通る形で、モジュール１３０６から直接再生モジュール外へ出力される。
再生モジュールを含むホストセキュリティマネージャ１３３０には、利用者の意思による書き換えが行えないような静的な記憶領域１３０４が設けられており、認証用モジュール １３０２や、Usage Pass受信及び復号化用モジュール１３０３、Usage Pass復旧用モジュール１３０５及び１３０１は、必要に応じて、記憶領域へアクセスする。記憶領域１３０４は、保護情報領域と呼ばれる。
各モジュールが実際に持っている機能については、図２２から図２７を用いて相互認証処理及びUsage Pass転送処理を具体的に説明する中で、詳細に説明する。また、保護情報領域１３０４に記録されるデータの種類等については、図１５を用いて後で説明する。
ＢＴモード用保護情報転送モジュールの構成
図１４を用いて、ＢＴモード用の保護情報転送モジュールの構成について説明する。
記録モジュールや再生モジュールに関する説明においても述べたように、ＢＴモードでは、保護情報転送モジュールがInceptive Deviceとの間の相互認証を実行する構成の方が適切である。そこで、保護情報転送モジュール１４１０には、自身がPrimal DeviceとなってInceptive Deviceとの間で相互認証処理を実行するためのモジュール１４００、再生モジュール１４１６の中のUsage Pass受信用モジュール１４０３が生成した最新のセッション鍵を一時的に保持し、必要に応じて記録モジュール内のUsage Pass送信用モジュールへ送信するモジュール１４０５が含まれる。尚、Usage Pass受信用モジュール１４０３における最新のセッション鍵生成タイミング、及びUsage Pass送信用モジュール１４０１におけるセッション鍵の利用方法などについては、図２３及び図２４を用いて処理シーケンスを説明する際に、詳細に述べる。
ホストセキュリティマネージャ内にあるＢＴモード用保護情報領域の構成
図１５を用いて、記録再生装置におけるＢＴモード用の保護情報領域の構成を説明する。
ＢＴモードは、Usage Passを転送する向きに拠らず、ホストセキュリティマネージャ１１１が全体として常にPrimal Deviceとなり、磁気ディスク装置が常にInceptive DeviceとなってUsage Pass転送をいずれの方向にも実行できるように考案された方式である。それ故、通常記録モジュール１０２と再生モジュール１０３は、１つの保護情報領域を共有する形で実装した方が、記録再生装置に設ける静的記憶領域を小さくすることができる。
図１５は、このような状況を想定して保護情報領域を実装した場合の内部構成を示している。尚、ＵＴモードの場合に説明したように、記録モジュール１０２用と再生モジュール１０３用の別の記憶領域を用意し、それぞれにDevice Class証明書や、相互認証に必要な鍵を記憶させておいても良い。この場合、記録モジュールと再生モジュールはそれぞれが相互認証実行用モジュールを含まなければならなくなる。そのような場合は、本実施例では説明しない。
１５０１は、Device Class証明書である。Device Class証明書１５０１には、Device Class公開鍵１５００が含まれる。Device Class証明書は、含まれるDevice Class公開鍵の正当性を証明するものであり、電子署名が含まれる。電子署名部は、認証局秘密鍵K_CAで暗号化されている。
１５０３は認証局公開鍵、１５０４はDevice Class秘密鍵、１５０５はDevice公開鍵、１５０６はDevice秘密鍵である。
以上の証明書及び鍵情報は、初期の実装時に埋め込まれているもので、後で更新されるものではない。
これに対し、領域１５０２と１５１０に記録される情報は、RDCＬ及びConnection Logであり、これらは相互認証処理において更新される情報である。RDCLに含まれるデータの意味や、その役割は、ＵＴモードの場合と同じである。一方、Connection Logは、ＢＴモードに固有のログ情報である。ログに記録されるのは、認証相手となるデバイスのDevice公開鍵、認証処理実行中に自身及び相手によって生成される０次セッション鍵、及びType Mapである。図示のように、Connection Logは複数のエントリを持たない。ある２つのDevice間で相互認証処理を実行した後、一方を異なるDeviceと接続し直した場合、Connection Logは上書きされてしまう。
領域１５２０及び１５２１には、Transaction Logが記録される。Transaction Logは、Usage Pass転送処理において更新される情報であるが、記録される内容は、ＵＴモードの場合と異なる。ＢＴモードにおいて、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が失われてしまった場合にも、復旧することができるようになる。これらのデータを記録するタイミングについては、図２３、図２４、図２６、図２７を用いてUsage Pass転送処理を具体的に説明する中で、詳細に説明する。
Usage Pass転送モジュール内にある保護情報領域の構成
図１６を用いて、磁気ディスク装置におけるＢＴモード用の保護情報領域の構成を説明する。
前述の通り、ＢＴモードは、Usage Passを転送する向きに拠らず、ホストセキュリティマネージャ １１１が全体として常にPrimal Deviceとなり、磁気ディスク装置が常にInceptive DeviceとなってUsage Pass転送をいずれの方向にも実行できるように考案された方式である。
図示の通り、Usage Pass転送モジュール内に設けられる保護情報領域に記録されるデータは、Transaction Logを除き、ホストセキュリティマネージャ １１１に記録されるデータと同一である。つまり、１６０１はDevice Class公開鍵１６００を含むDevice Class証明書であり、１６０３は認証局公開鍵、１６０４はDevice Class秘密鍵、１６０５はDevice公開鍵、１６０６はDevice秘密鍵、そして１６１０はConnection Logの記録領域である。
また、図示されている通り、制限記憶部２２３内の保護情報領域には、Transaction Logの記録領域が設けられていない。これは、Usage Pass転送実行時には、磁気ディスク装置はTransaction Logの記録を行わないことを意味する。ログの記録処理がない分、ＢＴモードでのUsage Pass転送時の磁気ディスク装置の処理負荷は、ＵＴモードに比べて、軽くなるという特徴がある。
上記の証明書及び鍵情報は、初期の実装時に埋め込まれているもので、後で更新されるものではない点、及びConnection LogはUsage Passを実行しようとするデバイス間で行われる相互認証処理において更新される点も、ホストセキュリティマネージャ１１１内の保護情報領域１０１と同じである。
次に、図１７から図２７を参照して、ホストモジュール１１０、Primal Device、Inceptive Deviceの三者の間で行われる、相互認証処理、Usage Pass転送処理の詳細について説明する。これらの図は、ホストモジュールが発行する命令と、それに付随してデータバスを流れるデータ、及び命令とデータを受信または送信し、相互認証あるいはUsage Pass転送を実行するために各デバイスもしくはモジュールに求められる処理及び機能を示すものである。
Usage Pass転送モード設定処理
Usage Pass転送を実行するためには、まず初めに、ホストモジュール１１０が仲介する形で、自身に接続されている脱着可能な記憶装置１２５，１２６及び自身に備わっているホストセキュリティマネージャ１１１に対して、ＵＴモードあるいはＢＴモードいずれの方式でUsage Pass転送を実行するか、を設定する必要がある。図１７は、これを実現するために各Deviceもしくはモジュールに求められる処理及び機能を、ホストモジュールが発行する命令とそれに付随して流れるデータの流れという観点で示したものである。
尚、図１７では、ホストモジュールを介して接続されている２つのDeviceを、便宜的にDevice１、Device２と呼んでいるが、これらはいずれも、ホストセキュリティマネージャ（より機能を特定して記録モジュールあるいは再生モジュールの場合もある）、脱着可能な記憶装置内のUsage Pass転送モジュールのいずれかである。これらのモジュールであれば、何れでもよい。
まず、ホストモジュールは、Device２に対し、制限アクセスモード取得（GET QUALIFIED ACCESS MODE）命令１７０００を発行する。これに対しDevice２は、自身がＵＴモードによるUsage Pass転送を実行する機能とＢＴモードによるUsage Pass転送を実行する機能のいずれか、もしくは双方を有しているかを、応答１７００１としてホストモジュール１１０へ通知する。
次に、ホストモジュール１１０は、Device１に対しても同様の命令１７０１０を発行する。Device１は、Device２と同様に、自身がＵＴモードによるUsage Pass転送を実行する機能とＢＴモードによるUsage Pass転送を実行する機能のいずれか、もしくは双方を有しているかを、応答１７０１１としてホストモジュール１１０へ通知する。
このようにして、ホストモジュール１１０は、Device２及びDevice１がそれぞれ実装しているUsage Pass転送モードの種類を知ることができ、ホストモジュール１１０は、双方のDeviceが実装しているモードを選び、双方のDeviceにモードを設定する。Device２に対しては、オープンチャネル（OPEN CHANNEL）命令１７０２０、Device１に対しては、OPEN CHANNEL命令１７０３０が、それらを設定するためのものである。これらの命令に付随して、いずれの制限アクセスモードでUsage Pass転送を実行するか、及び複数の転送処理を同時並列的に実行する場合にそれらを分離可能にするための識別子を、データ１７０２１及びデータ１７０３１で双方のDeviceに送信する。以下では、識別子のことをChannel識別子と呼ぶ。図１７では、Device１に対して設定されるChannel識別子はID_[D１]、Device２に対して設定されるChannel識別子はID_[D２]と記されている。
ここで、同時並列的とは、例えば以下のような状況を言う。認証の確立後、Usage Pass転送が実行される場合は、Channel IDが特定されて、そのChannel IDの下でのみ転送が行われる。特に、UTモードの場合、Device２（磁気ディスク装置）に対して書き込みを行いながら、読み出しを行なう場合、ホストモジュールが発行する命令は、インターリーブ的になる場合がある。この様子を図２８に示す。
図２８において、PUT USAGE PASSの後には、ホストモジュールからDevice２にUsage Passが転送され、GET USAGE PASSの後には、Device ２からホストモジュールにUsage Passが転送される。太線で示す命令群（＊１、＊２、＊３印の命令）は、それ自体に処理順序が規定されおり、不規則な順序で命令を受信しても、Device２はそれを失敗させる（abort）。しかし、途中に、細線で示す命令（＊＊１、＊＊２、＊＊３印の命令）が来ても、それは失敗させない。太線の命令群は、それ自体規定された順序を守ってDevice２に命令が送られる限り、問題はないからである。
このような状況において、Device２はChannel IDを使って太線で示す処理系列と細線で示す処理系列を判別する。つまり、同時並列的な処理とは、このような状況を想定しており、太線で示す命令だけ先に初めから最後まで実行しUsage Pass転送を終了してから細線で示す処理を実行するというようなやり方ではなく、上記のように、お互いに属する命令が間に差し挟まれながら全体として処理を行なうような状況をいう。尚、上記のように２つの処理系列に限らず、３つ以上がお互い差し挟まれながら実行される場合も該当する。
説明を図１７に戻す。Channel識別子は、具体的には次のように利用される。
例えば、記録再生装置に唯一の脱着型記憶装置が接続されていたとする。このような状況において、ＵＴモードで記録モジュール１０２から記憶装置（例えば１２５、以下同じ）へのUsage Passの書き込み行いながら、同様にＵＴモードで記憶装置１２５から再生モジュール１０３へ、既に記録されているUsage Passの読み出しを行うような場合、記憶装置１２５では、それぞれのUsage Pass転送処理を分離して管理できるようにする必要がある。このような二つの処理系列に異なるChannel識別子を割り当てることで、脱着型の記憶装置は、ホストモジュール１１０から送信されてきた命令が、どちらの処理系列に関連するものなのかを判断できるようになる。
Device２及びDevice１は、それぞれデータ１７０２１及び１７０３１を受信すると、Channel識別子と、この識別子に関連付けられた制限アクセスモードを設定する処理を、１７０２２及び１７０３２において実行する。
Channel識別子と制限アクセスモードが設定されると、Device１とDevice２の間で相互認証処理１７０４０、及びそれに引き続く実際のUsage Pass転送処理１７０４１が実行される。これらの詳細は、図１８から図２７を用いて、後で詳細に説明する。
必要なUsage Pass転送処理を終えると、ホストモジュール１１０は、Device２とDevice１に対し、それぞれクローズチャネル（CLOSE CHANNEL）命令１７０５０及び１７０６０命令を発行する。この命令には、付随してChannel識別子１７０５１及び１７０６１がそれぞれのDeviceに送信される。それぞれのDeviceは、命令を受信すると、命令に続いて受信したChannel識別子で特定される処理系列に関する状態情報をすべてリセットし、Channel識別子も開放する。一度Channel識別子が開放されると、再度OPEN CHANNEL命令によってChannel識別子及び制限アクセスモードを設定しない限り、Deviceは認証処理やUsage Pass転送を実行するためにホストモジュールが発行する命令において、Channel識別子が指定されても、命令に関する処理を中断する。
公開鍵暗号化による共有Device公開鍵共有方法
相互認証及びUsage Pass転送に関する詳細な処理シーケンスについて説明する前に、本発明の実施例で用いられる公開鍵暗号化の方法について説明する。
本実施例では、公開鍵暗号化の方法として楕円暗号を利用する。楕円暗号は、２次元のある楕円曲線の方程式で表される曲線上の固定点（これをベースポイントG = (Gx, Gy)と呼ぶ）に対し、そのn倍点、すなわちGをn回加算するという演算を暗号化に際して利用するものである。ここで用いられる加算法は、通常の十進法の加算方式と異なり、Gを整数回加算した結果は、Gとは異なる楕円曲線上の点となるようなものである。
説明に際し、Device１とDevice２の二つのDeviceを想定する。そして、Device１には暗号化すべきメッセージMが、Device２には、ある公開鍵KPuとペアとなる秘密鍵KPrが記録されているものとする。ここで、KPrは自然数、KPuは楕円曲線上の座標点（KPux, KPuy）であり、両者及びベースポイントは、KPu = KPr × Gという関係で結ばれている。言い換えると、KPuは、ベースポイントのKPｒ回加算点であるということである。
まず、Device１における暗号化処理について説明する。
(E１) Device２からDevice１へ、KPuを送信する。
(E２) Device１において、あるランダム自然数rを生成する。
(E３) r × G = R = (Rx, Ry)を計算する。
(E４) r × KPu = P = (Px, Py)を計算する
(E５) Px, Pyを用いて、ある自然数*KPuを生成する: *KPu = f(Px, Py) ここで、関数fは、事前に決めてあれば、任意でよい。
(E６) *KPuを共通鍵として用い、暗号化対象のメッセージMを、対称暗号化する: E(*KPu, M)
(E７) (６)で得られたデータに、(３)で得られたデータを連結し、Device２へ送信する。送信されるデータは、Rx || Ry || E(*KPu, M)である。ここで、*KPuを共有Device公開鍵と呼ぶ。
次に、Device２における復号化処理について説明する。
(D１) Rx, Ry, KPrを用いて、Pを計算する: KPr × R = KPr × r × G = r × (KPr × G) = r × KPu = P = (Px, Py)
(D２) Px, Pyを用いて、*KPrを求める。ここで、*KPrと*KPuは、全く同一の数である。前者は、KPrを用いて得られたという意味で、*KPrと表現されている: *KPr = f(Px, Py)
(D３) r × KPu = P = (Px, Py)を求める。
(D４) *KPrを共通鍵として用い、受信したデータを、対称復号化する: D(*KPr, E(*KPu, M)), 本発明では、これをD(KPr, E(KPu, M))と記載する。ここで、*KPrを共有Device秘密鍵と呼ぶ。
以上に説明した、共通鍵*KPu、*KPrを共有するためのアルゴリズムは、一般にはECDHアルゴリズムと呼ばれている。
尚、本明細書では、処理E２から処理E７全てを行う暗号化を、E(KPu, M)と記載する。既に*KPuが求められていて、処理E６のみ行う場合は、E(*KPu, M)と記載する。同様に、処理D１から処理D４まで全てを行う復号化を、D(KPr, E(KPu, M))と記載する。既に*KPrを求められていて、処理D４のみ行う場合は、D(*KPr, E(*KPu, M))と記載する。
図１８から図２７に表れる記号短縮名に関する説明
図１８から図２７には、ＵＴモード及びＢＴモードでの、相互認証処理シーケンス及びUsage Pass転送処理シーケンスを示す。これらの図中では、短縮形として以下の表記が用いられる。
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中のコンテンツ鍵の部分が０に置き換えられたUsage Passに、Usage Pass Stautsを連結したもの。
AI: Action Indicator．ENCRYPT USAGE PASS COPY/MOVE/PLAYのいずれの命令を受信したかを示すもの。詳細は、図１９、図２３、図２４の説明において述べる。
CKS: Checksum。Usage Passを暗号化して転送する際、転送元においてUsage PassとAction Indicatorを連結したデータから計算し、データに対して連結するもの。詳細は、図１９、図２３、図２４の説明において述べる。
TL: Transaction Log
CL: Connection Log
TS_UT: ＵＴモードにおいて用いられるTransaction Status．詳細は、図２１の説明において述べる。
TS_BT: ＢＴモードにおいて用いられるTransaction Status．詳細は、図２１の説明において述べる。
Status:
SS: Session Status．Usage Passの転送処理の段階．詳細は、図２１の説明において述べる。
UPS: Usage Pass Status。Usage Passの検索あるいは読み出しを行なった結果判明した、記録されているUsage Passの状態。図１０における有効性指示フラグに記載されている値と同一である。有効、無効、未記録の３状態がある。
ＵＴモードにおけるDevice間相互認証処理シーケンス
図１８を用いて、ＵＴモードにおける、Primal DeviceとInceptive Deviceの間で相互認証を行う場合の処理シーケンスについて説明する。
尚、ＵＴモードにおける相互認証処理段階のことを、以下ではＵＴコネクションステージ（Connection stage）と呼ぶ。二つの脱着可能な記憶装置間でUsage Passを転送するということは、Primal Deviceが記憶装置１２５におけるモジュール５００、Inceptive Deviceが記憶装置１２６におけるモジュール５０２であるような場合である。記録モジュールなどで新たに生成したUsage Passを、脱着可能な記憶装置へ記録するような場合は、Primal Deviceがモジュール６００、Inceptive Deviceがモジュール５０２である。磁気ディスク装置に記録されているUsage Passを再生モジュールへ送信し、コンテンツデータの復号や再生などを行う場合は、Primal Deviceがモジュール５００、Inceptive Deviceがモジュール７０２となる。これらの関係は、図１９から図２１におけるＵＴモードでの各処理シーケンスについての説明でも同様である。
まず初めに、ホストモジュールは、Inceptive Deviceに対してデバイスクラス証明書取得（GET DEVICE CLASS CERTIFICATE）命令１８０００を発行する。すると、Inceptive Deviceは、自身に埋め込まれているデバイスクラス（Device Class）証明書を、ホストモジュール１１０へ送信する（１８００１）。Device Class証明書を、以降ではDCC（K_CA, KP_dc[I]）と記載する。これは、証明書が、KP_dc[I]の正当性を示すもので、K_CAを用いて電子署名部が暗号化されていることを表している。
ホストモジュール１１０は、DCC（K_CA, KP_dc[I]）を受信すると、Primal Deviceに対しデバイスクラス証明書検証（VERIFY DEVICE CLASS CERTIFICATE）命令１８０１０を発行し、それに続いてDCC（K_CA, KP_dc[I]）をPrimal Deviceへ送信する（１８０１２）
Primal Deviceは、DCC（K_CA, KP_dc[I]）を受信すると、１８０１２に示す１つの処理（処理UT１.１.１）を実行する。
処理UT１.１.１: 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]）を検証中に、ホストモジュール１１０は、処理が終了するタイミングを見計らって、Primal Deviceに対し、プライマルデバイスチャレンジキーＵＴコネクション取得（GET PRIMAL DEVICE CHALLENGE KEY UT CONNECTION）命令１８０２０を発行する。Primal Deviceは命令を受信すると、１８０２１に示す、下記３つの処理を実行する。
処理UT１.２.１: Challenge鍵K_ch[P]を生成する。
処理UT１.２.２: 処理UT１.２.１で生成したK_ch[P]を、DCC（K_CA, KP_dc[I]）中のKP_dc[I]で暗号化する。得られるデータは、E(KP_dc[I], K_ch[P])である。
処理UT１.２.３: 処理UT１.２.２で得られたデータに対し、自身に埋め込まれているDevice Class証明書を連結。得られるデータは、E(KP_dc[I], K_ch[P]) || DCC(K_CA, KP_dc[P])である。
処理UT１.２.３においてE(KP_dc[I], K_ch[P]) || DCC(K_CA, KP_dc[P])の生成を終えると、Primal Deviceは、データをホストモジュールへ送信する（１８０２２）。
ホストモジュールは、E(KP_dc[I], K_ch[P]) || DCC(K_CA, KP_dc[P])を受信すると、Inceptive Deviceに対してPUT PRIMAL DEVICE CHALLENGE KEY UT CONNECTION命令１８０３０命令を発行後、受信したデータをInceptive Deviceに送信する（１８０３１）。
Inceptive Deviceは、E(KP_dc[I], K_ch[P]) || DCC(K_CA, KP_dc[P])を受信すると、１８０３２に示す、下記の３つの処理を実行する。
処理UT１.３.１: DCC(K_CA, KP_dc[P])を検証する。検証手段は、処理UT１.１.１で説明した方法と同じである。但し、参照するRDCLは、RDCL_[I]である。
処理UT１.３.２: 受信したデータのうち、E(KP_dc[I], K_ch[P])を分離し、復号する。復号は、自身の保護情報領域に埋め込まれているK_dc[I]を用いて行う。
処理UT１.３.３: 処理UT１.３.２の結果として、K_ch[P]が正当な形で含まれていたかどうかを確認する。確認は、次のようにして行う。まず、処理UT１.３.２においてK_ch[P]を暗号化する際、K_ch[P]に対し固有の番号を連結して暗号化するということをあらかじめ規定しておく。そして、処理UT１.３.２において受信したデータを復号した際、その結果において、規定された番号が得られれば、データの破壊等は起こっていないと判断する。
処理UT１.３.１から処理UT１.３.３を実行中、ホストモジュール１１０は、処理が終了するタイミングを予測し、適切なタイミングでGET INCEPTIVE DEVICE SESSION KEY UT CONNECTION命令１８０４０を発行する。Inceptive Deviceは命令を受信すると、１８０４１に示す下記の２つの処理を実行する。
処理UT１.４.１: ０次セッション鍵K_s[I]０を生成する。
処理UT１.４.２: 処理UT１.４.１で生成したK_s[I]０に対し、自身に埋め込まれているDevice公開鍵KP_d[I]を連結し、処理UT１.３.１で受信したKP_dc[P]で暗号化する。暗号化によって得られたデータに、自身に記録されているRDCL_[I]を連結し、得られたデータ全体を処理UT１.３.３で得られたK_ch[P]で暗号化する。最終的に得られるデータは、E(K_ch[P], E(KP_dc[P], K_s[I]０ || KP_d[I]) || RDCL_[I])である。
Inceptive Deviceにおいて、E(K_ch[P], E(KP_dc[P], K_s[I]０ || KP_d[I]) || RDCL_[I])が生成されると、Deviceは、生成されたデータをホストモジュールへ送信する（１８０４２）。
ホストモジュールは、E(K_ch[P], E(KP_dc[P], K_s[I]０ || KP_d[I]) || RDCL_[I])を受信すると、Primal Deviceに対して、インセンプティブデバイスセッションキーＵＴコネクション送信（PUT INCEPTIVE DEVICE SESSION KEY UT CONNECTION）命令１８０５０を発行後、受信したデータをPrimal Deviceへ送信する（１８０５１）。
Primal Deviceは、E(K_ch[P], E(KP_dc[P], K_s[I]０ || KP_d[I]) || RDCL_[I])を受信すると、１８０５２に示す、下記の５つの処理を実行する。
処理UT１.５.１: 受信したデータを、K_ch[P]で復号する。K_ch[P]は、処理UT１.２.１において自身で生成された鍵である。
処理UT１.５.２: 処理UT１.５.１の結果から、RDCL_[I]を分離し、RDCL_[I]が正当な形で含まれていたかどうかを確認する。確認するための手段は、処理UT１.３.３に記したものと同じである。
処理UT１.５.３: 自身に記録されているRDCL_[P]と、送信されたRDCL_[I]について、それらが発行された日付情報を比較する。RDCLの発行日情報は、RDCL内に含まれるものとする。比較した結果、受信したRDCL_[I]の発行日情報が、自身に記録されているRDCL_[P]の発行日情報より新しかった場合は、RDCL_[P]をRDCL_[I]で上書きする。
処理UT１.５.４: 残りのデータE(KP_dc[P], K_s[I]０ || KP_d[I])を、K_dc[P]で復号する。
処理UT１.５.５: 処理UT１.５.４で得られたデータについて、K_s[I]０ || KP_d[I]が正当な形で含まれていたかどうかを確認する。確認するための手段は、処理UT１.３.３に記したものと同じである。
処理UT１.５.１から処理UT１.５.５をPrimal Deviceが実行中、ホストモジュールは処理が終了するタイミングを予測し、適切なタイミングでGET PRIMAL DEVICE SESSION KEY UT CONNECTION命令１８０６１を発行する。Primal Deviceは命令を受信すると、１８０６１に示す、下記の２つの処理を実行する。
処理UT１.６.１: ０次セッション鍵K_s[P]０生成する。
処理UT１.６.２: 処理UT１.６.１で生成したK_s[P]０を、処理UT１.５.５で受信した０次セッション鍵K_s[I]０で暗号化する。得られるデータはE(K_s[I]０, K_s[P]０)である。ここで、処理UT１.５.３におけるRDCL_[P]とRDCL_[I]の発行日情報の比較の結果、RDCL_[P]の発行日の方が新しかった場合は、E(K_s[I]０, K_s[P]０)に対し、RDCL_[P]を連結後、得られたデータ全体を処理UT１.５.５で得られたKP_d[I]で暗号化する。最終的に得られるデータは、E(KP_d[I], E(K_s[I]０, K_s[P]０ || KP_d[P]) || RDCL_[P])である。
Primal Deviceにおいて、E(KP_d[I], E(K_s[I]０, K_s[P]０ || KP_d[P]) || RDCL_[P])の生成を終えると、Deviceは、データをホストモジュール１１０へ送信する（１８０６２）。
ホストモジュール１１０は、E(KP_d[I], E(K_s[I]０, K_s[P]０ || KP_d[P]) || RDCL_[P])を受信すると、Inceptive Deviceに対してPUT PRIMAL DEVICE SESSION KEY UT CONNECTION命令１８０７０命令を発行後、受信したデータをDeviceに送信する（１８０７１）。
Inceptive Deviceは、E(KP_d[I], E(K_s[I]０, K_s[P]０ || KP_d[P]) || RDCL_[P])を受信すると、１８０７２に示す、下記の５つの処理を実行する。
処理UT１.７.１: 受信したデータを、K_d[I]で復号する。K_d[I]は、自身の保護情報領域に埋め込まれている。
処理UT１.７.２: 処理UT１.７.１の結果にRDCL_[P]が含まれていた場合、データを分離し、データが正当な形で含まれていたかどうかを確認する。確認するための手段は、処理UT１.３.３に記したものと同じである。
処理UT１.７.３: 処理UT１.７.１と処理UT１.７.２の結果、受信したデータにRDCL_[P]が含まれていて、それが正当な形で含まれていたことが確認できた場合、自身に記録されているRDCL_[I]を、受信したRDCL_[P]で上書きする。
処理UT１.７.４: 残りのデータE(K_s[I]０, K_s[P]０)を、K_s[I]０で復号する。K_s[I]０は、処理UT１.４.１において、自身で生成した鍵データである。
処理UT１.７.５: 処理UT１.７.４で得られたデータについて、K_s[P]０が正当な形で含まれていたかどうかを確認する。確認するための手段は、処理UT１.３.３に記したものと同じである。
以上処理UT１.７.５までを完了すると、共有Device公開鍵*KP_d[I]（共有Device秘密鍵*K_d[I]と同じ）、K_s[P]０、K_s[I]０の共有が完了する。
ＵＴモードにおけるDevice間Usage Pass転送処理シーケンス
ＵＴモードにより、Primal DeviceとInceptive Deviceの間で相互認証が完了すると、Primal DeviceからInceptive Deviceに対して、Usage Passを転送することができる。次に、図１９を用いて、Usage Passの転送処理シーケンスについて説明する。尚、ＵＴモードにおけるUsage Pass転送処理段階のことを、以下ではUT Transfer stageと呼ぶ。
まず初めに、ホストモジュール１１０は、Primal Deviceに対してユーセジパスリード（READ USAGE PASS）命令１９０００を発行する。そして、命令に続いて、Usage Passが記録されている場所及び読み出すUsage Passの数を、１９００１においてPrimal Deviceに通知する。Primal Deviceは、命令とUsage Passが記録されている場所及び読み出すUsage Passの数についての情報を受信すると、１９００２に示す、下記の処理を実行する。
処理UT２.１.１: 転送対象のUsage Passを、Usage Pass送信用モジュール内へ準備する。例えば、Primal Deviceが磁気ディスク装置であった場合、目的のUsage Passを制限記憶部 ２２３からUsage Pass Buffer ５１０を介してモジュール５０１内に送るような処理に相当する。同様に、Primal Deviceが記録モジュールであった場合、目的のUsage PassをUsage Pass Creator and Content Encrypter６０６からモジュール６０１へ送るような処理に相当する。
ホストモジュール１１０は、目的のUsage Passが、Usage Pass送信用モジュール内に準備されると、続いてマスクユーセジパス取得（GET MASKED USAGE PASS）命令１９０１０を、Primal Deviceに対して発行する。Primal Deviceはこの命令を受信すると、Masked Usage Passを作成し、１９０１１においてホストモジュール１１０へデータを送信する。先に説明したように、Masked Usage Passは、Usage Pass中のコンテンツ鍵データ部を０で置き換えたものに、Usage Pass Statusを連結したものである。ホストモジュール１１０は、Masked Usage Passを受信すると、データ中のUR_sを解析し、Usage Pass送信用モジュール内に読み出されたUsage Passが、転送可能であるかどうかを判断する。転送可能であると判断された場合は、以下のUsage Pass転送処理を継続する。
Usage Pass転送処理を継続する場合、次にホストモジュール１１０は、Inceptive Deviceに対して、インセプティブデバイスセッション鍵ＵＴ転送生成（CREATE INCEPTVE DEVICE SESSION KEY UT TRANSFER）命令１９０２０命令を発行する。そして、この命令に続いて、転送対象となるUsage PassのUsage Pass識別子をInceptive Deviceへ送信する（１９０２１）。Inceptive Deviceは、受信対象Usage PassのUsage Pass識別子を受信すると、１９０２２に示す、下記の３つの処理を実行する。
処理UT２.２.１: セッション鍵K_s[I]nを生成する。セッション鍵は、Usage Pass転送を行う度に生成される共通鍵であり、その意味から、nはn回目のUsage Pass転送用に生成されたことであることを意味する。n ≧ １である。
処理UT２.２.２: Transaction Logを生成する。ここで記録されるのは、転送対象Usage PassのUsage Pass識別子、処理UT２.２.１で生成したセッション鍵K_s[I]n、Session Statusである。要素には、Usage Passを受信する準備が整ったという意味で、RP（Receive Prepared）が設定される。残りの要素には、不定U（Unspecified）が記録される。
処理UT２.２.３: 処理UT２.２.１で生成したK_s[I]nを、１つ前のUsage Pass転送実行時に生成したセッション鍵K_s[I]n-１及びConnection stageにおいてPrimal Deviceで生成された０次セッション鍵K_s[P]０を用いて、暗号化する。本処理の前に一度のUsage Pass転送が行われていない場合は、Connection stage中の処理UT１.４.１において自身で生成した０次セッション鍵を用いる。得られるデータは、E(K_s[P]０, E(K_s[I]n-１, K_s[I]n))である。
処理UT２.２.１及び処理UT２.２.２をInceptive Deviceが実行中、ホストモジュールは処理が終了するタイミングを予測し、適切なタイミングで、インセプティブデバイスセッション鍵ＵＴ転送取得（GET INCEPIVE DEVICE SESSION KEY UT TRANSFER）命令１９０３０を発行する。Inceptive Deviceはこの命令を受信すると、処理UT２.２.３において生成されたデータを、ホストモジュール１１０へ送信する（１９０３１）。
ホストモジュール１１０は、E(K_s[P]０, E(K_s[I]n-１, K_s[I]n))を受信すると、Primal Deviceに対して、インセプティブデバイスセッション鍵ＵＴ転送送信（PUT INCEPTIVE DEVICE SESSION KEY UT TRANSFER）命令１９０４０を発行した後、受信したデータにUsage Pass識別子を連結し、Primal Deviceへ送信する（１９０４１）。送信されるデータは、UPID || E(K_s[P]０, E(K_s[I]n-１, K_s[I]n))である。
Primal Deviceは、UPID || E(K_s[P]０, E(K_s[I]n-１, K_s[I]n))を受信すると、１９０４２に示す、下記の５つの処理を実行する。
処理UT２.３.１: 受信したUPIDと、処理UT２.１.１でUsage Pass送信用モジュール内に準備したUsage PassのUPIDが一致しているか調べる。一致していなければ、ここでUsage Pass転送処理を中断する。
処理UT２.３.２: 受信したデータを、K_s[P]０及びK_s[I]n-１で復号する。K_s[P]０は処理UT１.６.１において自身で生成したものであり、K_s[I]n-１は処理UT.２.２.３において説明したものと同じである。
処理UT２.３.３: 処理UT２.３.２で得られたデータについて、K_s[I]nが正当な形で含まれていたかどうかを確認する。確認するための手段は、処理UT１.３.３に記したものと同じである。
処理UT２.３.４: Transaction Logを生成する。ここで記録されるのは、転送対象Usage PassのUsage Pass識別子、処理UT１.１.１で得たInceptive DeviceのDevice Class証明書に含まれるType Map、処理処理UT２.３.３で得たセッション鍵K_s[I]n、Session Status、転送対象Usage PassのUR_s、処理UT２.１.１で読み出したUsage PassのUsage Pass Locationである。Session Statusには、Usage Passを送信する準備が整ったという意味で、SP（Send Prepared）が設定される。
以上、処理UT２.３.１から処理UT２.３.４をPrimal Deviceが実行中、ホストモジュールは処理が終了するタイミングを予測し、適切なタイミングでENCRYPT USAGE PASS COPYあるいはENCRYPT USAGE PASS MOVEあるいはENCRYPT USAGE PASS PLAY命令１９０５０を発行する。尚、どの命令を受信した場合にどのようなUR_sのUsage Passを送信するか、そして複製や再生の場合Primal Deviceに残るUsage PassのUR_sはどのように変更しなければならないか等については、あらかじめ全て規定されているものとする。そこで、命令を受信すると、Primal Deviceは、１９０５１に示す、下記の２つの処理を実行する。
処理UT２.４.１: Inceptive Deviceに対して送信するUsage Passを、処理UT２.１.１においてUsage Pass送信用モジュール内に準備されたUsage Passを元に、生成する。通常、UPIDやK_cなどはそのまま複製され、UR_sのみ規定に従う形で変更される。
処理UT２.４.２: 処理UT２.４.１において生成された送信用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を、固定長ごとに分割する。そして、得られたそれぞれのブロックデータを全て足し合わせた後、全てのビット値を反転し、更に１を加える。これは、Usage Pass || Action Indicatorの２の補数を求めていることに他ならない。検証時は、Checksumを含めたデータ全体Usage Pass || Action Indicator || Checksumを先と同じ固定長に分割後、各ブロックデータを全て足し合わせる。その結果が０となれば、途中でデータに変化がないということになる。
上記の処理UT２.４.１及び処理UT２.４.２をPrimal Deviceが実行中、ホストモジュール１１０は処理が終了するタイミングを予測し、適切なタイミングでGET USAGE PASS命令１９０６０を発行する。Primal Deviceは、命令を受信すると、１９０６２に示す、下記の３つの処理を実行する。
処理UT２.５.１: Transaction LogにおけるSession Statusを更新する。Usage Passの送信が完了したことで、Session StatusをSC（Send Completed）に設定する。
処理UT２.５.２: 処理２.４.２において生成されたデータE(*KP_d[I], E(K_s[I]n, Usage Pass || Action Indicator || Checksum))をホストモジュールへ送信する。
処理UT２.５.３: 元のUsage Pass中のUR_sを規定に従って変更する。Primal Deviceが磁気ディスク装置であった場合は、UR_sが変更されたUsage Passを、Usage Passが制限記憶部中で元来記録されていた場所に、上書きする。尚、命令１９０５０がENCRYPT USAGE PASS MOVEであった場合、有効性指示フラグの値は「無効」にされる。
ホストモジュール１１０は、E(*KP_d[I], E(K_s[I]n, Usage Pass || Action Indicator || Checksum))を受信すると、Inceptive Deviceに対して、ユーセジパス送信（PUT USAGE PASS）命令１９０７０を発行し、またDeviceに対し、E(*KP_d[I], E(K_s[I]n, Usage Pass || Action Indicator || Checksum))を送信する（１９０７１）。Inceptive Deviceは、命令及びデータを受信すると、１９０７２に示す、下記の３つの処理を実行する。
処理UT２.５.１: 受信したデータを、*K_d[I]及びK_s[I]nで復号する。*K_d[I]は、処理UT１.７.１において得た共通鍵である。また、K_s[I]nは処理UT２.２.１において自身で生成したセッション鍵である。
処理UT２.５.２: 処理UT２.５.１で得られたデータについて、Usage Pass || Action Indicator || Checksumが正当な形で含まれていたかどうかを確認する。確認は、Checksumを検証すること及び処理UT１.３.３に記した手段を用いて行われる。Checksumによる検証方法は、処理UT２.４.２に記載してある。
処理UT２.５.３: Transaction LogにおけるSession Status及びUsage Pass Locationを更新する。Session Status には、Usage Passの受信が完了したということを表すRC（Receive Completed）を設定する。Usage Pass Locationには、Usage Passの記録先アドレスを記載する。
尚、Inceptive Deviceが磁気ディスク装置の場合、処理UT２.５.３の後、受信したUsage Passを制限記憶部２２３に記録する。Usage Passの記録を行う際には、有効性指示フラグを「有効」に設定する。
その後、Inceptive DeviceにおけるUsage Passの受信もしくは制限記憶部２２３への記録が正常に終了したか否かを確認するために、ホストモジュール１１０は、Inceptive Deviceに対し、実行ステータスチェック（CHECK EXECUTION STATUS）命令１９０８０を発行しても良い。Inceptive Deviceからホストモジュールへは、実行状態が１９０８１において送信される。
以上のように、UT Transfer stageを繰り返すことにより、Connection stageを繰り返し行わなくても、連続的にUsage Pass転送を実行することができる。
ＵＴモードにおけるDevice間再相互認証処理シーケンス
Primal DeviceとInceptive Deviceの間で１回以上のUT Transfer stageが行われ、両Deviceの間でセッション鍵K_s[I]nの共有及び鍵のTransaction Logへの記録が終了した後、記録再生装置に異常が発生して、Usage Pass送信用モジュール及び同受信用モジュールからセッション鍵が失われてしまった場合、Connection stageと比べ、少ない処理で相互認証を再完了することができる。
次に、図２０を用いて、この再相互認証処理について説明する。尚、ＵＴモードにおける本処理段階のことを、以下ではUT Reconnection stageと呼ぶ。
まず、UT Transfer stageにおいて、Inceptive Deviceはユーセジパス送信（PUT USAGE PASS）命令２００００及びそれに続いてUsage Pass ２０００１を受信しているという状況を想定する。そして、Usage Passの受信処理が完全に完了しないうちに、異常発生の理由により、Primal DeviceとInceptive Deviceの間で分断が発生し、２０００１で流れるUsage Passを暗号化するために用いられていたセッション鍵K_s[I]や共有Device公開鍵*KP_d[I]が、両Deviceから失われてしまったとする（２００１０）。
上記の場合、ホストモジュール１１０は、まずPrimal Deviceに対し、トランザクションログ再認証検索（SEARCH TRANSACTION LOG RECONNECTION）命令２００２０を発行する。そして、命令に続き、２０００１で送信中であったUsage PassのUsage Pass識別子を、送信する（２００２１）。
Primal Deviceは、識別子を受信すると、２００２２に示す下記の１つの処理を実行する。
処理UT３.１.１: 保護情報領域の中で、識別子と同じ識別子値が記録されているTransaction Logを検索する。
処理UT３.１.１を実行中、ホストモジュール１１０は処理が終了するタイミングを予測し、適切なタイミングで、プライマルデバイスセッション鍵ＵＴ再認証取得（GET PRIMAL DEVICE SESSION KEY UT RECONNECTION）命令２００３０を発行する。Primal Deviceは、命令を受信すると、２００３１に示す下記の２つの処理を実行する。
処理UT３.２.１: 新しい０次セッション鍵K_s[P]０'を生成する。
処理UT３.２.２: 処理UT３.２.１で生成したK_s[P]０'を、処理UT３.１.１で見出された自身の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]０'))である。

処理UT３.２.２における暗号化を終えると、Primal Deviceは、その暗号化されたデータをホストモジュールへ送信する（２００３２）。
ホストモジュール１１０は、E(KP_d[I]TL, E(K_s[I]TL, K_s[P]０'))を受信すると、Inceptive Deviceに対して、プライマルデバイスセッション鍵ＵＴ再認証送信（PUT PRIMAL DEVICE SESSION KEY UT RECONNECTION）命令２００４０命令を発行した後、受信したデータに２００２１でPrimal Deviceに対して送信したUsage Pass識別子と同一の識別子を連結し、Inceptive Deviceに送信する（２００４１）。
Inceptive Deviceは、E(KP_d[I]TL, E(K_s[I]TL, K_s[P]０'))を受信すると、２００４２に示す下記の３つの処理を実行する。
処理UT３.３.１: 保護情報領域の中で、識別子と同じ識別子値が記録されているTransaction Logを検索する。
処理UT３.３.２: 受信したデータを復号する。復号は、自身の保護情報領域に埋め込まれているK_d[I]及び処理UT３.３.１で見出されたTransaction Log中に含まれるセッション鍵K_s[I]TLである。
処理UT３.３.３: 処理UT３.３.２の結果として、K_s[P]０'が正当な形で含まれていたかどうかを確認する。確認するための手段は、処理UT１.３.３に記したものと同じである。
処理UT３.３.２が完了すると、*KP_d[I]（*K_d[I]と同じ）、K_s[P]０'の共有が完了する。以上の処理に続いてUT Transfer stageを実行する場合、K_s[I]n-１としては、K_s[I]TLを用いる。
ＵＴモードにおける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 Recovery stageと呼ぶ。
まず、UT Transfer stageにおいて、Inceptive Deviceがユーセジパス設定（PUT USAGE PASS）命令２１０００及びそれに続いてUsage Pass ２１００１を受信しているという状況を想定する。そして、Usage Passの受信処理が完全に完了しないうちに、異常が発生して、Primal DeviceとInceptive Deviceの間で分断が発生し、２１００１で流れるUsage Passを暗号化するために用いられていたセッション鍵K_s[I]が、両Deviceから失われてしまったとする（２１０１０）。この場合、まず前節に記したUT Reconnection stageが実行され、*KP_d[I]（*K_d[I]と同じ）、K_s[P]０'が新たに共有される。
UT Reconnection stageを終えると、ホストモジュール１１０は、まずInceptive Deviceに対し、ユーセジパスＵＴ復旧検索（SEARCH USAGE PASS UT RECOVERY）命令２１０２０を発行する。そして、命令に続き、２１００１で送信中であったUsage PassのUsage Pass識別子を、送信する（２１０２１）。
Primal Deviceは、識別子を受信すると、２１０２２に示す４つの処理を実行する。
処理UT４.１.１: 保護情報領域の中で、識別子と同じ識別子値が記録されているTransaction Logを検索する。
処理UT４.１.２: 処理UT.４.１.１で見出されたTransaction Logに記録されていたUsage Pass Locationで指定される制限記憶部中のUsage Pass記憶領域を検索する。
処理UT４.１.３: 処理UT４.１.２で見出されたUsage Passについて、その有効性指示フラグの値を調べ、Usage Pass Statusに「有効」「無効」「未記録」のいずれかの値を設定する。
処理UT４.１.４: ＵＴモード用Transaction Statusを生成する。Transaction Statusは、復旧対象Usage PassのUPID || Transaction Log中に記録されているSession Status || 処理UT４.１.３で設定したUsage Pass Status || Hash値である。ここでHash値は、K_s[P]０' || K_s[I]TL || UPID || Session Status || Usage Pass Statusから計算される。本処理で生成されたTransaction Statusを、以下ではUT Transaction Statusと呼ぶ。
処理UT４.１.１から処理UT４.１.４をInceptive Deviceが実行中、ホストモジュールは処理が終了するタイミングを予測し、適切なタイミングでトランザクションステータスＵＴ復旧取得（GET TRANSACTION STATUS UT RECOVERY）命令２１０３０を発行する。Inceptive Deviceは命令を受信すると、処理UT４.１.４において生成されたUT Transaction Statusを、ホストモジュール１１０へ送信する（２１０３１）。
ホストモジュール１１０は、Transaction Statusを受信すると、Primal Deviceに対し、トランザクションステータスＵＴ復旧検証（VERIFY TRANSACTION STATUS UT RECOVERY）命令２１０４０を発行し、続いて受信したデータを送信する（２１０４１）。送信されるデータは、UT Transaction Statusである。
Primal Deviceは、UT Transaction Statusを受信すると、２１０４２に示す下記の３つの処理を実行する。
処理UT４.２.１: UT Transaction Statusの検証と、UT Transaction Statusに含まれるUsage Pass識別子、Session Status、Usage Pass Statusの確認を行う。UT Transaction Statusの検証は、データに含まれるHash値を、自身が保持しているK_s[P]０'とK_s[I]TLから計算することによって行う。計算結果が含まれているHash値と一致すれば、データの改竄は行われていないと判断される。また、Usage Pass識別子は、今回復旧対象のものであるどうかの確認、Session Status及びUsage Pass Statusは復旧可否を判定するために用いられる。Session StatusがRPであった場合や、Session StatusがRPであるがUsage Pass Statusが「無効」や「未記録」であった場合は、Primal Deviceにおける復旧処理（下記処理４.２.２）が行われる。
処理UT４.２.２: 保護情報領域の中で、識別子と同じ識別子値が記録されているTransaction Logを検索する。
処理UT４.２.３: Usage Pass復旧処理を実行する。Usage Passの復旧は、対象のUsage Passの有効性指示フラグが「無効」となっていた場合はそれを「有効」にし、復旧対象のUsage PassのUR_sを、処理UT４.２.２で見出されたTransaction Logに記録されていたUR_sで上書きすることによって達成される。
その後、Primal DeviceにおけるUsage Passの復旧処理が正常に終了したか否かを確認するために、ホストモジュールは、Primal Deviceに対し、CHECK EXECUTION STATUS命令２１０５０を発行しても良い。Primal Deviceからホストモジュールへは、実行状態が２１０５１において送信される。
処理UT４.２.２が完了すると、Primal Deviceには、送信する以前のUsage Passが存在するようになる。
ＢＴモードにおけるDevice間相互認証処理シーケンス
次に、図２２を参照して、ＢＴモードにおける、Primal DeviceとInceptive Deviceの間で相互認証を行う場合の処理シーケンスについて説明する。尚、ＢＴモードにおける相互認証処理段階のことを、以下ではBT Connection stageと呼ぶ。
図１１から図１３の説明でも述べたように、ＢＴモードでは、Primal Deviceは記録再生装置内のホストセキュリティマネージャ１１１全体である。Managerに含まれるモジュールの中で、相互認証処理は保護情報転送モジュール内のモジュール１４００が、Usage Passの送信や受信は記録モジュールと再生モジュール内のモジュール１２０１やモジュール１３０３が担う。また、Inceptive Deviceは、磁気ディスク装置内のUsage Pass転送モジュール１１３０である。これらの関係は、以後図２２から図２７において説明するＢＴモードでの各処理シーケンスにおいても同様である。
まず初めに、ホストモジュール１１０は、Inceptive Deviceに対してGET DEVICE CLASS CERTIFICATE命令２２０００を発行する。すると、Inceptive Deviceは、自身に埋め込まれているDevice Class証明書DCC（K_CA, KP_dc[I]）を、ホストモジュールへ送信する（２２００１）。
ホストモジュール１１０は、DCC（K_CA, KP_dc[I]）を受信すると、Primal Deviceに対してVERIFY DEVICE CLASS CERTIFICATE命令２２０１０を発行し、それに続いてDCC（K_CA, KP_dc[I]）をPrimal Deviceへ送信する（２２０１２）。
Primal Deviceは、DCC（K_CA, KP_dc[I]）を受信すると、２２０１２に示す下記の４つの処理を実行する。
処理BT１.１.１: DCC（K_CA, KP_dc[I]）を検証する。証明書について改竄が行われていないか、及び含まれる証明書を特定する番号が自身に記録されているRDCL_[P]に載っていないか、検証する。検証方法は、UT１.１.１に記載した方法と同じである。
処理BT１.１.２: Challenge鍵K_ch[P]を生成する。
処理BT１.１.３:処理BT１.１.３で生成したK_ch[P]を、DCC（K_CA, KP_dc[I]）中のKP_dc[I]で暗号化する。この暗号方式は、公開鍵暗号化である。得られるデータは、E(KP_dc[I], K_ch[P])である。
処理BT１.１.４: 処理BT１.１.３で得られたデータに対し、自身に埋め込まれているDevice Class証明書を連結。得られるデータは、E(KP_dc[I], K_ch[P]) || DCC(K_CA, KP_dc[P])である。
Primal Deviceが処理BT１.１.１から処理BT１.１.４を実行中に、ホストモジュール１１０は、処理が終了するタイミングを見計らって、Primal Deviceに対し、GET PRIMAL DEVICE CHALLENGE KEY BT CONNECTION命令２２０３０を発行する。Primal Deviceは、命令を受信すると、処理B１.１.４で生成したデータを、ホストモジュールへ送信する（２２０３１）。
ホストモジュール１１０は、E(KP_dc[I], K_ch[P]) || DCC(K_CA, KP_dc[P])を受信すると、Inceptive Deviceに対してPUT PRIMAL DEVICE CHALLENGE KEY BT CONNECTION命令２２０４０命令を発行後、受信したデータをInceptive Deviceに送信する（２２０４１）。
Primal Deviceは、E(KP_dc[I], K_ch[P]) || DCC(K_CA, KP_dc[P]を受信すると、２２０４２に示す下記の３つの処理を実行する。
処理BT１.２.１: DCC(K_CA, KP_dc[P])を検証する。検証手段は、処理UT１.１.１で説明した方法と同じである。但し、参照するRDCLは、RDCL_[I]である。
処理BT１.２.２: 受信したデータのうち、E(KP_dc[I], K_ch[P])を分離し、復号する。復号は、自身の保護情報領域に埋め込まれているK_dc[I]を用いて行う。
処理BT１.２.３: 処理BT１.２.２の結果として、K_ch[P]が正当な形で含まれていたかどうかを確認する。確認の方法は、処理UT１.３.３に記載した方法と同じである。
処理BT１.２.１から処理BT１.２.３を実行中、ホストモジュール１１０は、処理が終了するタイミングを予測し、適切なタイミングでGET INCEPTIVE DEVICE CHALLENGE KEY BT CONNECTION命令２２０５０を発行する。Inceptive Deviceは命令を受信すると、２２０５１に示す下記の２つの処理を実行する。
処理BT１.３.１: Challenge鍵K_ch[I]を生成する。
処理BT１.３.２: 処理BT１.３.１で生成したK_ch[I]に対し、自身に埋め込まれているDevice公開鍵KP_d[I]を連結し、処理BT１.２.１で受信したKP_dc[P]で暗号化する。暗号化によって得られたデータに、自身に記録されているRDCL_[I]を連結し、得られたデータ全体を処理BT１.２.３で得られたK_ch[P]で暗号化する。最終的に得られるデータは、E(K_ch[P], E(KP_dc[P], K_ch[I] || KP_d[I]) || RDCL_[I])である。
Inceptive Deviceにおいて、E(K_ch[P], E(KP_dc[P], K_ch[I] || KP_d[I]) || RDCL_[I])が生成されると、Deviceは、生成されたデータをホストモジュールへ送信する（２２０５２）。
ホストモジュール１１０は、E(K_ch[P], E(KP_dc[P], K_ch[I] || KP_d[I]) || RDCL_[I])を受信すると、Primal Deviceに対しPUT INCEPTIVE DEVICE CHALLENGE KEY BT CONNECTION命令２２０６０を発行した後、受信したデータをPrimal Deviceへ送信する（２２０６１）。
Primal Deviceは、E(K_ch[P], E(KP_dc[P], K_ch[I] || KP_d[I]) || RDCL_[I])を受信すると、２２０６２に示す下記の７つの処理を実行する。
処理BT１.４.１: 受信したデータを、K_ch[P]で復号する。K_ch[P]は、処理BT１.１.２において自身で生成された鍵である。
処理BT１.４.２: 処理UT１.４.１の結果から、RDCL_[I]を分離し、RDCL_[I]が正当な形で含まれていたかどうかを確認する。確認するための手段は、処理UT１.３.３に記したものと同じである。
処理BT１.４.３: 自身に記録されているRDCL_[P]と、送信されたRDCL_[I]について、それらが発行された日付情報を比較する。RDCLの発行日情報は、RDCL内に含まれるものとする。比較した結果、受信したRDCL_[I]の発行日情報が、自身に記録されているRDCL_[P]の発行日情報より新しかった場合は、RDCL_[P]をRDCL_[I]で上書きする。
処理BT１.４.４: 残りのデータE(KP_dc[P], K_ch[I] || KP_d[I])を、K_dc[P]で復号する。
処理BT１.４.５: 処理BT１.４.４で得られたデータについて、K_ch[I] || KP_d[I]が正当な形で含まれていたかどうかを確認する。確認するための手段は、処理UT１.２.３に記したものと同じである。
処理BT１.４.６: ０次セッション鍵K_s[P]０生成する。
処理BT１.４.７: 処理BT１.４.６で生成したK_s[P]０に自身に埋め込まれているDevice公開鍵KP_d[P]を連結し、処理BT１.４.５で受信したDevice公開鍵KP_d[I]で暗号化する。得られるデータはE(KP_d[I], K_s[P]０ || KP_d[P])である。ここで、処理BT１.４.３におけるRDCL_[P]とRDCL_[I]の発行日情報の比較の結果、RDCL_[P]の発行日の方が新しかった場合は、E(KP_d[I], K_s[P]０ || KP_d[P])に対し、RDCL_[P]を連結後、得られたデータ全体を処理BT１.４.５で得られたK_ch[I]で暗号化する。最終的に得られるデータは、E(K_ch[I], E(KP_d[I], K_s[P]０ || KP_d[P]) || RDCL_[P])である。
処理BT１.４.１から処理BT１.４.７をPrimal Deviceが実行中、ホストモジュールは処理が終了するタイミングを予測し、適切なタイミングでGET PRIMAL DEVICE SESSION KEY BT CONNECTION命令２２０７１を発行する。Primal Deviceは命令を受信すると、処理BT１.４.７で生成したE(K_ch[I], E(KP_d[I], K_s[P]０ || KP_d[P]) || RDCL_[P])を、ホストモジュールへ送信する（２２０７１）。
ホストモジュール１１０は、E(K_ch[I], E(KP_d[I], K_s[P]０ || KP_d[P]) || RDCL_[P])を受信すると、Inceptive Deviceに対してPUT PRIMAL DEVICE SESSION KEY BT CONNECTION命令２２０８０命令を発行後、受信したデータをDeviceに送信する（２２０８１）。
Inceptive Deviceは、E(K_ch[I], E(KP_d[I], K_s[P]０ || KP_d[P]) || RDCL_[P])を受信すると、２２０８２に示す下記の５つの処理を実行する。
処理BT１.５.１: 受信したデータを、K_ch[I]で復号する。K_ch[I]は、処理BT１.３.１において、自身で生成した鍵データである。
処理BT１.５.２: 処理BT１.５.１の結果にRDCL_[P]が含まれていた場合、データを分離し、データが正当な形で含まれていたかどうかを確認する。確認するための手段は、処理UT１.３.３に記したものと同じである。
処理BT１.５.３: 処理BT１.５.１と処理BT１.５.２の結果、受信したデータにRDCL_[P]が含まれていて、それが正当な形で含まれていたことが確認できた場合、自身に記録されているRDCL_[I]を、受信したRDCL_[P]で上書きする。
処理BT１.５.４: 残りのデータE(KP_d[I], K_s[P]０ || KP_d[P])を、K_d[I]０で復号する。K_d[I]は、自身の保護情報領域に埋め込まれている。
処理BT１.５.５: 処理UT１.５.４で得られたデータについて、K_s[P]０ || KP_d[P]が正当な形で含まれていたかどうかを確認する。確認するための手段は、処理UT１.３.３に記したものと同じである。
処理BT１.５.１から処理BT１.５.５をInceptive Deviceが実行中、ホストモジュールは処理が終了するタイミングを予測し、適切なタイミングでGET INCEPTIVE DEVICE SESSION KEY BT CONNECTION命令２２０９０を発行する。Inceptive Deviceは命令を受信すると、２２０９１に示す下記の３つの処理を実行する。
処理BT１.６.１: ０次セッション鍵K_s[I]０を生成する。
処理BT１.６.２: Connection Logに、処理BT１.５.５で受信したK_s[P]０及びKP_d[P]、処理BT１.６.１で生成したK_s[I]０、処理BT１.２.１で受信したDCC（K_CA, KP_dc[P]）に含まれていたPrimal DeviceのType Map TM_[P]を記録する。
処理BT１.６.３: 処理BT１.６.１で生成したK_s[I]０を、処理BT１.５.５で受信したK_s[P]０及びKP_d[P]で暗号化する。得られるデータは、E(KP_d[P], E(K_s[P]０, K_s[I]０))である。
Inceptive Deviceにおいて、E(KP_d[P], E(K_s[P]０, K_s[I]０))が生成されると、Deviceは、生成されたデータをホストモジュール１１０へ送信する（２２０９２）。
ホストモジュール１１０は、E(KP_d[P], E(K_s[P]０, K_s[I]０))を受信すると、Primal Deviceに対してPUT INCEPTIVE DEVICE SESSION KEY BT CONNECTION命令２２１００命令を発行後、受信したデータをDeviceに送信する（２２１０１）。
Primal Deviceは、E(KP_d[P], E(K_s[P]０, K_s[I]０))を受信すると、２２１０２に示す下記の３つの処理を実行する。
処理BT１.７.１: 受信したデータを、K_d[P]及びK_s[P]０で復号する。K_d[P]は、自身の保護情報領域に埋め込まれている鍵データであり、K_s[P]０は処理BT１.４.６において自身で生成した鍵データである。
処理UT１.７.２: 処理UT１.７.１で得られたデータについて、K_s[I]０が正当な形で含まれていたかどうかを確認する。確認するための手段は、処理UT１.３.３に記したものと同じである。
処理BT１.７.３: Connection Logに、処理BT１.４.５で受信したKP_d[I]、処理BT１.７.２で受信したK_s[I]０、処理BT１.４.６で生成したK_s[P]０、処理BT１.１.１で受信したDCC（K_CA, KP_dc[I]）に含まれていたPrimal DeviceのType Map TM_[I]を記録する。
以上処理BT１.７.３までを完了すると、共有Device公開鍵*KP_d[P]（共有Device秘密鍵*K_d[P]と同じ）、K_s[P]０、K_s[I]０の共有が完了する。
ＢＴモードにおけるPrimal DeviceからInceptive DeviceへのUsage Pass転送処理シーケンス
ＢＴモードにより、Primal DeviceとInceptive Deviceの間で相互認証が完了すると、Primal DeviceからInceptive Deviceあるいはその逆の方向に関して、Usage Passを転送することができる。
まず、Primal DeviceからInceptive DeviceへUsage Passを転送する場合について、図２３を用いて説明する。記録モジュール１０２がPrimal Deviceとなって、磁気ディスク装置にUsage Passを転送する場合が、その一例である。尚、ＢＴモードにおけるPrimal DeviceからInceptive DeviceへのUsage Pass転送処理段階のことを、以下ではBT PI Transfer stageと呼ぶ。
まず初めに、ホストモジュール１１０は、Primal Deviceに対してREAD USAGE PASS命令２３０００を発行する。そして、命令に続いて、Usage Passが記録されている場所及び読み出すUsage Passの数を、２３００１においてPrimal Deviceに通知する。Primal Deviceは、命令とUsage Passが記録されている場所及び読み出すUsage Passの数についての情報を受信すると、２３００２に示す下記の１つの処理を実行する。
処理BT２.１.１: 転送対象のUsage Passを、Usage Pass送信用モジュール内へ準備する。Primal Deviceが記録モジュールである場合、目的のUsage PassをUsage Pass Creator and Content Encrypter ６０６からモジュール ６０１へ送るような処理に相当する。
ホストモジュール１１０は、Primal Deviceに処理BT２.１.１を実行させている間に、Inceptive Deviceに対しCREATE INCEPTVE DEVICE SESSION KEY UT TRANSFER命令１９０２０命令を発行する。Inceptive Deviceは、命令を受信すると、２３０１２に示す下記の２つの処理を実行する。
処理BT２.２.１: セッション鍵K_s[I]nを生成する。ここでnは、ここでnは、BT Connection stage完了後、本処理がn回目のBT PI Transfer stageであることを意味する。
処理BT２.２.２: 処理BT２.２.１で生成したK_s[I]nを、１つ前のUsage Pass転送実行時に生成したセッション鍵K_s[I]n-１及び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転送処理シーケンスの詳細は、図２４を用いて後述する。もし、一度もInceptive DeviceからPrimal Deviceに対してUsage Pass転送処理が実行されていなかった場合は、BT Connection stageにおいて共有される０次セッション鍵K_s[P]０を、K_s[P]mとして用いる。得られるデータは、E(K_s[P]m, E(K_s[I]n-１, K_s[I]n))である。
処理BT２.２.１及び処理BT２.２.２をInceptive Deviceが実行中、ホストモジュールは処理が終了するタイミングを予測し、適切なタイミングでGET INCEPIVE DEVICE SESSION KEY BT TRANSFER命令２３０２０を発行する。Inceptive Deviceは命令を受信すると、処理BT２.２.２において生成されたデータE(K_s[P]m, E(K_s[I]n-１, K_s[I]n))を、ホストモジュールへ送信する（２３０２１）。
ホストモジュール１１０は、E(K_s[P]m, E(K_s[I]n-１, K_s[I]n))を受信すると、Primal Deviceに対しPUT INCEPTIVE DEVICE SESSION KEY BT TRANSFER命令２２０３０を発行し、続いて受信したデータをPrimal Deviceへ送信する（２３０３１）。
Primal Deviceは、E(K_s[P]m, E(K_s[I]n-１, K_s[I]n))を受信すると、２３０３２に示す下記の３つの処理を実行する。
処理BT２.３.１: 受信したデータを、K_s[P]m及びK_s[I]n-１で復号する。両鍵データについては、処理BT２.２.２で説明した通りである。
処理BT２.３.２: 処理BT２.３.１で得られたデータについて、K_s[I]nが正当な形で含まれていたかどうかを確認する。確認するための手段は、処理UT１.３.３に記したものと同じである。
処理BT２.３.３: Transaction Logを生成する。ＢＴモードでのUsage Pass転送処理では、Primal DeviceのみTransaction Logの記録を行う。ＢＴモードにおける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（記録先アドレス）である。
処理BT２.３.１から処理BT２.３.３をPrimal Deviceが実行中、ホストモジュールは処理が終了するタイミングを予測し、適切なタイミングでENCRYPT USAGE PASS COPYあるいはENCRYPT USAGE PASS MOVEあるいはENCRYPT USAGE PASS PLAY命令２３０４０を発行する。命令に続き、Inceptive DeviceへのUsage Passの記録先アドレス情報を、２３０４１においてPrimal Deviceに対し送信する。尚、ＵＴモードの場合と同様、どの命令を受信した場合にどのようなUR_sのUsage Passを送信するか、そして複製や再生の場合Primal Deviceに残るUsage PassのUR_sはどのように変更しなければならないか等については、あらかじめ全て規定されているものとする。そこで、命令を受信すると、Primal Deviceは、２３０４２に示す下記の３つの処理を実行する。
処理BT２.４.１: Inceptive Deviceに対して送信するUsage Passを、処理BT２.１.１においてUsage Pass送信用モジュール内に準備されたUsage Passを元に、生成する。通常、UPIDやK_cなどはそのまま複製され、UR_sのみ規定に従う形で変更される。
処理BT２.４.２: Transaction LogにおけるUsage Pass Locationに、２３０４１で受信したInceptive DeviceでのUsage Passの記録先アドレスを記録する。
処理BT２.４.３: 処理BT２.４.１において生成された送信用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の計算は、UT２.４.２に記載した通りである。
処理BT２.４.１から処理BT２.４.３をPrimal Deviceが実行中、ホストモジュールは処理が終了するタイミングを予測し、適切なタイミングでGET USAGE PASS命令２３０５０を発行する。Primal Deviceは、命令を受信すると、E(*KP_d[I], E(K_s[I]n, Usage Pass || Action Indicator || Checksum))をホストモジュールへ送信する（２３０５２）。
ホストモジュール１１０はE(*KP_d[I], E(K_s[I]n, Usage Pass || Action Indicator || Checksum))を受信すると、Inceptive Deviceに対しPUT USAGE PASS命令２３０６０を発行し、続いてE(*KP_d[I], E(K_s[I]n, Usage Pass || Action Indicator || Checksum))を送信する（２３０６１）。
Inceptive Deviceは、命令及びデータを受信すると、２３０６２に示す下記の３つの処理を実行する。
処理BT２.５.１: 受信したデータを、*K_d[I]及びK_s[I]nで復号する。*K_d[I]は、処理BT１.５.４において得た共通鍵である。また、K_s[I]nは処理BT２.２.１において自身で生成したセッション鍵である。
処理BT２.５.２: 処理UT２.５.１で得られたデータについて、Usage Pass || Action Indicator || Checksumが正当な形で含まれていたかどうかを確認する。確認は、Checksumを検証すること及び処理UT１.３.３に記した手段を用いて行われる。Checksumによる検証方法は、処理UT２.４.２に記載してある。
処理UT２.５.３: 受信したUsage Passを制限記憶部へ記録する。Usage Passの記録を行う際には、有効性指示フラグを「有効」に設定する。
その後、Inceptive Deviceにおける制限記憶部２２３へのUsage Passの記録が正常に終了したか否かを確認するために、ホストモジュールは、Inceptive Deviceに対し、CHECK EXECUTION STATUS命令２３０７０を発行しても良い。Inceptive Deviceからホストモジュールへは、実行状態が２３０７１において送信される。
以上に記したBT Transfer stageを繰り返すことにより、Connection stageを繰り返し行わなくても、Primal DeviceからInceptive Deviceに対し、連続的にUsage Pass転送を実行することができる。
ＢＴモードにおけるInceptive DeviceからPrimal DeviceへのUsage Pass転送処理シーケンス
次に、図２４を参照して、Inceptive DeviceからPrimal DeviceへUsage Passを転送する場合について説明する。磁気ディスク装置がPrimal Deviceとなって、再生モジュール１０４にUsage Passを転送する場合が、その一例である。尚、ＢＴモードにおけるInceptive DeviceからPrimal DeviceへのUsage Pass転送処理段階のことを、以下ではBT IP Transfer stageと呼ぶ。
まず初めに、ホストモジュール１１０は、Inceptive Deviceに対してREAD USAGE PASS命令２４０００を発行する。そして、この命令に続いて、Usage Passが記録されている場所及び読み出すUsage Passの数を、２４００１においてPrimal Deviceに通知する。Inceptive Deviceは、この命令とUsage Passが記録されている場所及び読み出すUsage Passの数についての情報を受信すると、２４００２に示す下記の１つの処理を実行する。
処理BT３.１.１: 制限記憶部において指定されたアドレスから転送対象のUsage Passを読み出し、Usage Pass Buffer １１１０へ送信する。
処理BT３.１.１をInceptive Deviceが実行中、ホストモジュールは処理が終了するタイミングを予測し、適切なタイミングで、Primal Deviceに対し、GET MASKED USAGE PASS WITH KEYED HASH命令２４０１０を発行する。Inceptive Deviceは、命令を受信すると、２４０１１に示す下記の２つの処理を実行する。
処理BT３.２.１: READ USAGE PASS命令２４０００で制限記憶部から読み出したUsage PassからMasked Usage Passを生成し、それに対しGET MASKED USAGE PASS WITH KEYED HASH命令２４０１０を受信した時点で最新のセッション鍵K_s[P]m-１及びK_s[I]nを連結したデータを元に、Hash値を計算する。命令２４０００で複数のUsage Passを一度に読み出している場合は、個々のUsage Passに対してHash値を計算する。
処理BT３.２.２: 処理BT３.２.１で生成した個々のHash値を、個々のMasked Usage Passに連結する。得られるデータは、MUP || H(K_s[P]m-１ || K_s[I]n || MUP)である。
Inceptive Deviceは処理BT３.２.２を終えると、生成されたデータMUP || H(K_s[P]m-１ || K_s[I]n || MUP)を、ホストモジュールへ送信する（２４０１２）。
ホストモジュール１１０は、MUP || H(K_s[P]m-１ || K_s[I]n || MUP)受信すると、Primal Deviceに対し、PUT MASKED USAGE PASS WITH KEYED HASH命令を発行し、続いてデータをPrimal Deviceへ送信する。
Primal Deviceは、データを受信すると、２４０２２に示す下記の１つの処理を実行する。
処理BT３.３.１: 受信したデータについて、改竄が行われていないかどうかを検証する。自身が保持しているセッション鍵K_s[P]m-１及びK_s[I]n及び受信したMUPを用いてHash値H(K_s[P]m-１ || K_s[I]n || MUP)を計算し、それが受信したHasht値と一致していれば、改竄が行われていないと判断する。
処理BT３.３.１をPrimal Deviceが実行中、ホストモジュールは処理が終了するタイミングを予測し、適切なタイミングで、Primal Deviceに対し、CREATE PRIMAL DEVICE SESSION KEY BT TRANSFER命令２４０３０を発行し、続いて転送対象Usage PassのUsage Pass識別子を送信する（２４０３１）。
Primal Deviceは、命令及びデータを受信すると、２４０３２に示す下記の４つの処理を実行する。
処理BT３.４.１: ２４０３１で受信したUsage Pass識別子と、２４０２１で受信したMasked Usage PassのUsage Pass識別子が一致しているか確認する。
処理BT３.４.２: Transaction Logを生成する。ここで記録されるのは、転送対象Usage PassのUsage Pass識別子、当Usage Pass転送処理におけるPrimal Deviceの役割「Destination」（図中では短縮形「D」）、２４０２１で受信したMasked Usage Pass中に含まれるUR_s、Inceptive Device中の制限記憶部におけるUsage Pass Location（記録元アドレス）である。
処理BT３.４.３: セッション鍵K_s[P]mを生成する。ここでmは、BT Connection stage完了後、m回目のBT IP Transfer stageにおいて生成されたセッション鍵であることを意味する。
処理BT３.４.４: 処理BT３.４.３で生成したK_s[P]mを、１つ前のUsage Pass転送実行時に生成したセッション鍵K_s[P]m-１及びInceptive Deviceにおいて生成された最新のセッション鍵K_s[P]nを用いて、暗号化する。K_s[I]nは、BT PI Transfer stageが実行される度に生成されるものであり、BT Connection stageが完了してから、n回の転送処理が実行されたことを意味する。尚、BT PI Transfer stageについては、図２３を用いて前節で説明済みである。もし、一度もPrimal DeviceからInceptive Deviceに対してUsage Pass転送処理が実行されていなかった場合は、BT Connection stageにおいて共有される０次セッション鍵K_s[I]０を、K_s[I]nとして用いる。得られるデータは、E(K_s[I]n, E(K_s[P]m-１, K_s[P]m))である。
処理BT３.４.１から処理BT３.４.４をPrimal Deviceが実行中、ホストモジュールは処理が終了するタイミングを予測し、適切なタイミングでGET PRIMAL DEVICE SESSION KEY BT TRANSFER命令２４０４０を発行する。Primal Deviceは命令を受信すると、処理BT３.４.４において生成されたデータを、ホストモジュールへ送信する（２４０４１）。
ホストモジュール１１０は、E(K_s[I]n, E(K_s[P]m-１, K_s[P]m))を受信すると、Inceptive Deviceに対しPUT PRIMAL DEVICE SESSION KEY BT TRANSFER命令２４０５０を発行後、受信したデータをInceptive Deviceへ送信する（２４０５１）。
Inceptive Deviceは、E(K_s[I]n, E(K_s[P]m-１, K_s[P]m))を受信すると、２４０５２に示す下記の２つの処理を実行する。
処理BT３.５.１: 受信したデータを、K_s[I]n及びK_s[P]m-１で復号する。両鍵データについては、処理BT３.２.１及び処理BT３.４.４で説明した通りである。
処理BT３.５.２: 処理UT３.５.１で得られたデータについて、K_s[P]mが正当な形で含まれていたかどうかを確認する。確認するための手段は、処理UT１.３.３に記したものと同じである。
処理BT３.５.１及び処理BT３.５.２をInceptive Deviceが実行中、ホストモジュールは処理が終了するタイミングを予測し、適切なタイミングでENCRYPT USAGE PASS COPYあるいはENCRYPT USAGE PASS MOVEあるいはENCRYPT USAGE PASS PLAY命令２４０６０を発行する。尚、ＵＴモードの場合と同様に、どの命令を受信した場合にどのようなUR_sのUsage Passを送信するか、そして複製や再生の場合Primal Deviceに残るUsage PassのUR_sはどのように変更しなければならないか等については、あらかじめ全て規定されているものとする。
そこで、この命令を受信すると、Inceptive Deviceは、２４０６２に示す下記の２つの処理を実行する。
処理BT３.６.１: Primal Deviceに対して送信するUsage Passを、処理BT３.１.１においてUsage Pass Bufferへ送信されたUsage Passを元に、モジュール １１０３内に生成する。通常、UPIDやK_cなどはそのまま複製され、UR_sのみ規定に従う形で変更される。
処理BT３.６.２: 処理BT３.６.１において生成された送信用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の計算は、UT２.４.２に記載した通りである。
以上、処理BT３.６.１及び処理BT３.６.２をInceptive Deviceが実行中、ホストモジュールは、処理が終了するタイミングを予測し、適切なタイミングでGET USAGE PASS命令２４０７０を発行する。Inceptive Deviceは、命令を受信すると、２４０７１に示す下記の１つの処理を実行する。
処理BT３.７.１: Usage Pass Buffer中のUsage PassのUR_sを、規定に従って変更する。そして、Usage PassをUsage Passが制限記憶部中で元来記録されていた場所に、上書きする。尚、命令２４０６０がENCRYPT USAGE PASS MOVEであった場合、有効性指示フラグの値は「無効」にされる。
Inceptive Deviceは、処理BT３.７.１を終了すると、処理で生成されたデータを、ホストモジュールへ送信する（２４０７２）。
ホストモジュール１１０はE(*KP_d[P], E(K_s[P]m, Usage Pass || Action Indicator || Checksum))を受信すると、Primal Deviceに対しPUT USAGE PASS命令２４０８０を発行し、またDeviceに対し、E(*KP_d[P], E(K_s[P]m, Usage Pass || Action Indicator || Checksum))を送信する（２４０８１）。
Inceptive Deviceは、命令及びデータを受信すると、２４０８２に示す下記の２つの処理を実行する。
処理BT３.８.１: 受信したデータを、*K_d[P]及びK_s[P]mで復号する。*K_d[P]は、処理BT１.７.１において得た共通鍵である。また、K_s[P]mは処理BT３.４.３において自身で生成したセッション鍵である。
処理BT３.８.２: 処理UT３.８.１で得られたデータについて、Usage Pass || Action Indicator || Checksumが正当な形で含まれていたかどうかを確認する。確認は、Checksumを検証すること及び処理UT１.３.３に記した手段を用いて行われる。Checksumによる検証方法は、処理UT２.４.２に記載した通りである。
その後、Inceptive DeviceにおけるUsage Passの受信が正常に終了したか否かを確認するために、ホストモジュールは、Primal Deviceに対し、CHECK EXECUTION STATUS命令２４０９０を発行しても良い。Primal Deviceからホストモジュールへは、実行状態が２４０９１において送信される。
以上に記したBT Transfer stageを繰り返すことにより、Connection stageを繰り返し行わなくても、Inceptive DeviceからPrimal Deviceに対し、連続的にUsage Pass転送を実行することができる。
ＢＴモードにおけるDevice間再相互認証処理シーケンス
Primal DeviceとInceptive Deviceの間で１度BT Connection stageが行われ、両Deviceの間で互いの共有Device公開鍵KP_d[P]及びKP_d[I]、０次セッション鍵K_s[P]０及びK_s[I]０、の共有及び鍵のConnection Logへの記録が終了した後、記録再生装置に電源供給停止等の異常が発生して、Usage Pass送信用モジュール及び同受信用モジュールからセッション鍵が失われてしまった場合、Connection stageと比べ、少ない処理で相互認証を再完了することができる。この再相互認証処理について、図２５を用いて説明する。尚、ＢＴモードにおける本処理段階のことを、以下ではBT Reconnection stageと呼ぶ。
まず、BT Connection stageが２５０００において完了した後、異常発生の理由により、Primal DeviceとInceptive Deviceの間で分断が発生し、その時点までで最新のセッション鍵K_s[P]m及びK_s[I]nや、共有Device公開鍵*KP_d[P]や*KP_d[I]が、両Deviceから失われてしまったとする（２５０１０）。
この場合、ホストモジュール１１０は、まずPrimal Deviceに対し、CREATE PRIMAL DEVICE SESSION KEY BT RECONNECTION命令２５０１０を発行する。
Primal Deviceは、命令を受信すると、２５０１１に示す下記の２つの処理を実行する。
処理BT４.１.１: 新しい０次セッション鍵K_s[P]０'を生成する。
処理BT４.１.２: 処理BT４.１.１で生成したK_s[P]０'を、自身の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]０'))である。
処理BT４.１.１及び処理BT４.１.２を実行中、ホストモジュールは処理が終了するタイミングを予測し、適切なタイミングでGET PRIMAL DEVICE SESSION KEY BT RECONNECTION命令２５０２０を発行する。Primal Deviceは、命令を受信すると、処理BT４.１.２で生成したデータE(KP_d[I]CL, E(K_s[I]CL, K_s[P]０'))を、ホストモジュールへ送信する。
ホストモジュール１１０は、E(KP_d[I]CL, E(K_s[I]CL, K_s[P]０'))を受信すると、Inceptive Deviceに対してPUT PRIMAL DEVICE SESSION KEY BT RECONNECTION命令２５０３０命令を発行した後、受信したデータをInceptive Deviceに送信する（２５０３１）。
Inceptive Deviceは、E(KP_d[I]CL, E(K_s[I]CL, K_s[P]０'))を受信すると、２５０３２に示す下記の２つの処理を実行する。
処理BT４.２.１: 受信したデータを復号する。復号は、自身の保護情報領域に埋め込まれているK_d[I]及びConnection Log中に含まれるセッション鍵K_s[I]CLである。
処理BT４.２.２: 処理UT４.２.１の結果として、K_s[P]０'が正当な形で含まれていたかどうかを確認する。確認するための手段は、処理UT１.３.３に記したものと同じである。
処理BT４.２.１及び処理BT４.２.２を実行中、ホストモジュールは処理が終了するタイミングを予測し、適切なタイミングでGET INCEPTIVE DEVICE SESSION KEY BT RECONNECTION命令２５０４０を発行する。Inceptive Deviceは、命令を受信すると、２５０４１に示す下記の３つの処理を実行する。
処理BT４.３.１: 新しい０次セッション鍵K_s[I]０'を生成する。
処理BT４.３.２: 処理BT４.３.１で生成したK_s[I]０'を、自身の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]０'))である。
処理BT４.３.３: 処理BT４.２.２で受信したK_s[P]０'、処理BT４.３.１で生成したK_s[I]０'を、Connection Logに上書き記録する。KP_d[P]及びTM_[P]は、そのまま保持する。
Inceptive Deviceは、処理BT４.３.３を終了すると、処理BT４.３.２で生成したデータE(KP_d[P]CL, E(K_s[P]CL, K_s[I]０'))をホストモジュールへ送信する（２５０４０）。
ホストモジュール１１０は、E(KP_d[P]CL, E(K_s[P]CL, K_s[I]０'))を受信すると、Primal Deviceに対してPUT INCEPTIVE DEVICE SESSION KEY BT RECONNECTION命令２５０５０命令を発行後、受信したデータをPrimal Deviceに送信する（２５０５１）。
Primal Deviceは、E(KP_d[P]CL, E(K_s[P]CL, K_s[I]０'))を受信すると、２５０５２に示す下記の３つの処理を実行する。
処理BT４.４.１: 受信したデータを復号する。復号は、自身の保護情報領域に埋め込まれているK_d[P]及びConnection Log中に含まれるセッション鍵K_s[P]CLである。
処理BT４.４.２: 処理UT４.４.１の結果として、K_s[I]０'が正当な形で含まれていたかどうかを確認する。確認するための手段は、処理UT１.３.３に記したものと同じである。
処理BT４.４.３: 処理BT４.４.２で受信したK_s[I]０'、処理BT４.１.１で生成したK_s[P]０'を、Connection Logに上書き記録する。KP_d[I]及びTM_[I]は、そのまま保持する。
処理UT４.４.３が完了すると、*KP_d[P]（*K_d[P]と同じ）、*KP_d[I]（*K_d[I]と同じ）、K_s[P]０'、K_s[I]０'の共有が完了する。以上の処理に続いてBT PI Transfer stageを実行する場合、K_s[I]n-１としては、K_s[I]０'を、BT IP Transfer stageを実行する場合、K_s[P]m-１としてはK_s[P]０'を用いる。
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 PI Recovery stageと呼ぶ。
まず、BT PI Transfer stageにおいて、Inceptive DeviceがPUT USAGE PASS命令２６０１０及びそれに続いてUsage Pass ２６０１１を受信しているという状況を想定する。そして、Usage Passの受信処理が完全に完了しないうちに、異常が発生して、Primal DeviceとInceptive Deviceの間で分断が生じ、２６０１１で流れるUsage Passを暗号化するために用いられていたセッション鍵K_s[I]n及び*KP_d[I]（*K_d[I]）が、両Deviceから失われてしまったとする（２６０２０）。この場合、まず前節で説明したBT Reconnection stageが実行され、*KP_d[P]（*K_d[P]と同じ）、*KP_d[I]（*K_d[I]と同じ）、K_s[P]０'、K_s[I]０'が新たに共有される。
BT Reconnection stageを終えると、ホストモジュール１１０は、まずPrimal Deviceに対し、SEARCH TRANSACTION LOG BT RECOVERY命令２６０３０を発行する。そして、命令に続き、２１０１１で送信中であったUsage PassのUsage Pass識別子を、送信する（２６０３１）。
Primal Deviceは、識別子を受信すると、２６０３２に示す下記の１つの処理を実行する。
処理BT５.１.１: 保護情報領域の中で、識別子と同じ識別子値が記録されているTransaction Logを検索する。
処理BT５.１.１をPrimal Deviceが実行中、ホストモジュールは処理が終了するタイミングを予測し、適切なタイミングでGET USAGE PASS LOCATION命令２６０４０を発行する。命令を受信すると、Primal Deviceは、処理BT５.１.１で見出されたTransaction Log中に記録されているUsage Pass Location情報を、ホストモジュールへ送信する（２６０４１）。
ホストモジュール１１０は、Usage Pass Location情報を受信すると、Inceptive Deviceに対し、SEARCH USAGE PASS BT RECOVERY命令２６０５０を発行し、続いて受信したデータを送信する（２６０５１）。
Inceptive Deviceは、Usage Pass Location情報を受信すると、２６０５２に示す下記の３つの処理を実行する。
処理BT５.２.１: 制限記憶部において、受信したUsage Pass Locationで指定される制限記憶部中のUsage Pass記憶領域を検索する。
処理BT５.２.２: 処理UT５.２.１で見出されたUsage Passについて、その有効性指示フラグの値を調べ、Usage Pass Statusに「有効」「無効」「未記録」のいずれかの値を設定する。
処理BT５.２.３: ＢＴモード用Transaction Statusを生成する。Transaction Statusは、復旧対象Usage PassのUPID || 処理BT５.２.１で見出されたUsage PassのUR_s || 処理BT５.２.２で設定したUsage Pass Status || ２６０４１で受信した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と呼ぶ。
処理BT５.２.１から処理BT５.２.３をInceptive Deviceが実行中、ホストモジュールは処理が終了するタイミングを予測し、適切なタイミングでGET TRANSACTION STATUS BT RECOVERY命令２６０６０を発行する。命令を受信すると、Inceptive Deviceは、処理BT５.２.３で生成されたBT PI Transaction Statusを、ホストモジュールへ送信する（２６０６１）。
ホストモジュール１１０は、BT PI Transaction Statusを受信すると、Primal Deviceに対し、VERIFY TRANSACTION STATUS BT PI RECOVERY命令２６０７０を発行し、続いて受信したBT PI Transaction Statusを送信する（２６０７１）。
Primal Deviceは、BT PI Transaction Statusを受信すると、２６０７２に示す下記の２つの処理を実行する。
処理BT５.３.１: 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の復旧処理は行われない。
処理UT５.３.２: Usage Pass復旧処理を実行する。Usage Passの復旧は、対象のUsage Passの有効性指示フラグが「無効」となっていた場合はそれを「有効」にし、復旧対象のUsage Passを、Transaction Logに記録されていたUsage Passで上書きすることによって達成される。
処理BT５.３.２が完了すると、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 IP Recovery stageと呼ぶ。
まず、BT IP Transfer stageにおいて、Primal DeviceがPUT USAGE PASS命令２７０１０及びそれに続いてUsage Pass ２７０１１を受信しているという状況を想定する。そして、Usage Passの受信処理が完全に完了しないうちに、異常が発生して、Primal DeviceとInceptive Deviceの間で分断が生じ、２７００１で流れるUsage Passを暗号化するために用いられていたセッション鍵K_s[P]n及び*KP_d[P]（*K_d[P]）が、両Deviceから失われてしまったとする（２７０２０）。この場合、まず前節に記したBT Reconnection stageが実行され、*KP_d[P]（*K_d[P]と同じ）、*KP_d[I]（*K_d[I]と同じ）、K_s[P]０'、K_s[I]０'が新たに共有される。
BT Reconnection stageを終えると、ホストモジュールは、まずPrimal Deviceに対し、SEARCH TRANSACTION LOG BT RECOVERY命令２７０３０を発行する。そして、命令に続き、２７０１１で送信中であったUsage PassのUsage Pass識別子を、送信する（２７０３１）。
Primal Deviceは、識別子を受信すると、２７０３２に示す下記の１つの処理を実行する。
処理BT６.１.１: 保護情報領域の中で、識別子と同じ識別子値が記録されているTransaction Logを検索する。
処理BT６.１.１をPrimal Deviceが実行中、ホストモジュールは処理が終了するタイミングを予測し、適切なタイミングでGET USAGE PASS LOCATION命令２６０４０を発行する。命令を受信すると、Primal Deviceは、処理BT６.１.１で見出されたTransaction Log中に記録されているUsage Pass Location情報を、ホストモジュールへ送信する（２７０４１）。
ホストモジュール１１０は、Usage Pass Location情報を受信すると、Inceptive Deviceに対し、SEARCH USAGE PASS BT RECOVERY命令２７０５０を発行し、続いて受信したデータを送信する（２７０５１）。
Inceptive Deviceは、Usage Pass Location情報を受信すると、２７０５２に示す下記の３つの処理を実行する。
処理BT６.２.１: 制限記憶部において、受信したUsage Pass Locationで指定される制限記憶部中のUsage Pass記憶領域を検索する。
処理BT６.２.２: 処理UT６.２.１で見出されたUsage Passについて、その有効性指示フラグの値を調べ、Usage Pass Statusに「有効」「無効」「未記録」のいずれかの値を設定する。
処理BT６.２.３: ＢＴモード用Transaction Statusを生成する。Transaction Statusは、復旧対象Usage PassのUPID || 処理BT６.２.１で見出されたUsage PassのUR_s || 処理BT６.２.２で設定したUsage Pass Status || ２７０４１で受信した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 IP Transaction Statusと呼ぶ。
処理BT６.２.１から処理BT６.２.３をInceptive Deviceが実行中、ホストモジュールは処理が終了するタイミングを予測し、適切なタイミングでGET TRANSACTION STATUS BT RECOVERY命令２７０６０を発行する。命令を受信すると、Inceptive Deviceは、処理BT６.２.３で生成されたBT IP Transaction Statusを、ホストモジュールへ送信する（２７０６１）。
ホストモジュール１１０は、BT IP Transaction Statusを受信すると、Primal Deviceに対し、VERIFY TRANSACTION STATUS BT IP RECOVERY命令２７０７０を発行し、続いて受信したBT IP Transaction Statusを送信する（２７０７１）。
Primal Deviceは、BT IP Transaction Statusを受信すると、２７０７２に示す下記の１つの処理を実行する。
処理BT６.３.１: 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-１から計算することによって行う。計算結果が含まれている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を処理BT６.１.１で見出されたTransaction Logに記録されているUR_sに照らし合わせた結果、Inceptive Deviceに残っている目的のUsage PassのUR_sが変化してしまっていることが判明したりした場合は、以降のUsage Pass復旧処理が実行される。
処理BT６.３.１をPrimal Deviceが実行中、それに並列して、ホストモジュール１１０はCREATE INCEPTIVE DEVICE SESSION KEY BT TRANSFER命令２７０８０を発行する。
Inceptive Deviceは、命令を受信すると、２７０８１に示す下記の２つの処理を実行する。
処理BT６.４.１: セッション鍵K_s[I]nを生成する。ここでnは、ここでnは、BT Connection stage完了後、本処理がn回目のBT IP Transfer stageであることを意味する。
処理BT６.４.２: 処理BT６.４.１で生成したK_s[I]nを、１つ前のUsage Pass転送実行時に生成したセッション鍵K_s[I]n-１及び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において共有される０次セッション鍵K_s[P]０'を、K_s[P]mとして用いる。得られるデータは、E(K_s[P]m, E(K_s[I]n-１, K_s[I]n))である。
処理BT６.４.１及び処理BT６.４.２をInceptive Deviceが実行中、ホストモジュールは処理が終了するタイミングを予測し、適切なタイミングでGET INCEPIVE DEVICE SESSION KEY BT TRANSFER命令２７０９０を発行する。Inceptive Deviceは命令を受信すると、処理BT６.４.２において生成されたデータE(K_s[P]m, E(K_s[I]n-１, K_s[I]n))を、ホストモジュールへ送信する（２７０９１）。
ホストモジュール１１０は、E(K_s[P]m, E(K_s[I]n-１, K_s[I]n))を受信すると、Primal Deviceに対しPUT INCEPTIVE DEVICE SESSION KEY BT RETRANSFER命令２７１００を発行し、続いて受信したデータをPrimal Deviceへ送信する（２７１０１）。
Primal Deviceは、E(K_s[P]m, E(K_s[I]n-１, K_s[I]n))を受信し、処理BT６.３.１においてInceptive Device中のUsage Passの復旧処理が必要であることが判明すると、２７１０２に示す下記の２つの処理を実行する。
処理BT６.５.１: 受信したデータを、K_s[P]m及びK_s[I]n-１で復号する。両鍵データについては、処理BT６.２.３で説明した通りである。
処理BT６.５.２: 処理BT６.５.１で得られたデータについて、K_s[I]nが正当な形で含まれていたかどうかを確認する。確認するための手段は、処理UT１.３.３に記したものと同じである。
処理BT６.５.１及び処理BT６.５.２をPrimal Deviceが実行中、ホストモジュールは処理が終了するタイミングを予測し、適切なタイミングでENCRYPT USAGE PASS RECOVER命令２７１１０を発行する。命令を受信すると、Primal Deviceは、２７１１１に示す下記の２つの処理を実行する。
処理BT６.６.１: 処理BT６.２.１で見出されたTransaction Logに記録されているUPIDとUR_sを連結し、Usage Pass送信用モジュール１３０１へ送信する。
処理BT６.６.２: 処理BT６.６.１においてUsage Pass送信用モジュール １３０１に準備された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の計算は、UT２.４.２に記載した通りである。
処理BT６.６.１及び処理BT６.６.２をPrimal Deviceが実行中、ホストモジュールは処理が終了するタイミングを予測し、適切なタイミングでGET RECOVER USAGE PASS命令２７１２０を発行する。Primal Deviceは、命令を受信すると、E(*KP_d[I], E(K_s[I]n, UPID || UR_s || Checksum))をホストモジュールへ送信する（２７１２１）。
ホストモジュール１１０はE(*KP_d[I], E(K_s[I]n, UPID || UR_s || Checksum))を受信すると、Inceptive Deviceに対しRECOVER USAGE PASS命令２７１３０を発行し、続いてE(*KP_d[I], E(K_s[I]n, UPID || UR_s || Checksum))及びデータの書き込み先Usage Pass Locationを送信する（２７１３１）。
Inceptive Deviceは、命令及びデータを受信すると、２３０６２に示す下記の４つの処理を実行する。
処理BT６.７.１: 受信したデータ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 ２７０２１において得た共通鍵である。また、K_s[I]nは処理BT６.４.１において自身で生成したセッション鍵である。
処理BT６.７.２: 処理BT６.７.１で得られたデータについて、UPID || UR_s || Checksumが正当な形で含まれていたかどうかを確認する。確認は、Checksumを検証すること及び処理UT１.３.３に記した手段を用いて行われる。Checksumによる検証方法は、処理UT２.４.２に記載してある。
処理BT６.７.３: 受信したUsage Pass Locationで指定される制限記憶部のUsage Pass記録領域からUsage PassをUsage Pass Bufferへ読み出し、Usage PassのUPIDが、処理BT６.７.２で復号した結果得られたUPIDと一致するか確認する。一致しない場合は、処理を中断する。
処理BT６.７.４: 受信したUsage Passを制限記憶部へ記録する。Usage Passの記録を行う際には、有効性指示フラグを「有効」に設定する。
その後、Inceptive DeviceにおけるUsage Passの制限記憶部への記録が正常に終了したか否かを確認するために、ホストモジュールは、Inceptive Deviceに対し、CHECK EXECUTION STATUS命令２７１４０を発行しても良い。Inceptive Deviceからホストモジュールへは、実行状態が２７１４１において送信される。
処理BT６.７.２が完了すると、Inceptive Deviceには、送信する以前のUsage Passが存在するようになる。
以上、実施例について説明したが、本発明は上記実施例に限定されない。また、種々変形して実施したり、また他の装置やシステムにも応用できるであろう。
例えば、上記実施例において説明された命令やモジュール等の呼び名は、あくまで一例であって上記の例に限定されない。例えば、上記実施例におけるユーセジパス（Usage Pass）は、ライセンス情報、或いは機密情報と呼ばれる場合もあろう。
本発明の一実施例が適用される記録再生装置を含むのデータ保護システムを示す概略構成図。 一実施例による脱着可能な磁気ディスク装置の構成図。 一実施例において使用されるデータ、情報、及び記号法等を示す表。 一実施例において使用されるデータの復号条件や復号鍵をまとめたデータ（Usage Pass）の構成図。 一実施例による図２の磁気ディスク装置におけるＵＴモードを実現するUsage Pass Tranfer モジュール５３０を示す図。 一実施例による記録再生装置におけるＵＴモードを実現する記録専用の機能モジュールを示す図。 一実施例による記録再生装置におけるＵＴモードを実現する復号専用の機能モジュールを示す図。 一実施例による記録再生装置におけるＵＴモードにおいて用いられる、証明書、公開鍵、秘密鍵、Usage Pass転送処理のログ情報などの秘匿情報を記録する、対タンパ性を有する静的な記憶領域を示す図。 一実施例による磁気ディスク装置におけるＵＴモードにおいて用いられる、証明書、公開鍵、秘密鍵、Usage Pass転送処理のログ情報などの秘匿情報を記録する、対タンパ性を有する静的な記憶領域を示す図。 一実施例による磁気ディスク装置における、Usage Passを記録する、対タンパ性を有する静的な記憶領域を示す図。 磁気ディスク装置における、ＢＴモードを実現する機能モジュールを示す図。 記録再生装置における、ＢＴモードに従って、Usage Pass送信を実現する記録専用の機能モジュールを示す図。 記録再生装置における、ＢＴモードに従って、Usage Pass受信を実現する復号専用の機能モジュールを示す図。 記録再生装置における、ＢＴモードに従って、磁気ディスク装置との間で相互認証処理を実現する機能モジュールを示す図。 記録再生装置における、ＢＴモードにおいて用いられる、証明書、公開鍵、秘密鍵、相互認証処理のログ情報、Usage Pass転送処理のログ情報などの秘匿情報を記録する、対タンパ性を有する静的な記憶領域を示す図。 磁気ディスク装置における、ＵＴモードにおいて用いられる、証明書、公開鍵、秘密鍵、相互認証処理のログ情報などの秘匿情報を記録する、対タンパ性を有する静的な記憶領域を示す図。 一実施例によるUsage Pass転送処理におけるアクセスモードの認識、設定のための処理シーケンスを示す図。 一実施例における、ＵＴモードに従って記録再生装置と記憶装置の間で行われる相互認証処理シーケンスを示す図。 一実施例における、ＵＴモードに従って記録再生装置と磁気ディスク装置の間で行われるUsage Pass転送処理シーケンスを示す図。 一実施例における、ＵＴモードに従って記録再生装置と磁気ディスク装置の間で行われる簡略化された再相互認証処理シーケンスを示す図。 一実施例における、ＵＴモードに従って記録再生装置と磁気ディスク装置の間で行われる、消失したUsage Passの復旧処理シーケンスを示す図。 一実施例における、ＢＴモードに従って記録再生装置と磁気ディスク装置の間で行われる相互認証処理シーケンスを示す図。 一実施例における、ＢＴモードに従って記録再生装置から磁気ディスク装置に対して送信される、Usage Pass転送処理シーケンスを示す図。 一実施例における、ＢＴモードに従って磁気ディスク装置から記録再生装置に対して送信される、Usage Pass転送処理シーケンスを示す図。 一実施例における、ＢＴモードに従って記録再生装置と磁気ディスク装置の間で行われる簡略化された再相互認証処理シーケンスを示す図。 一実施例における、ＢＴモードに従って記録再生装置から磁気ディスク装置に対して送信されたUsage Passが消失した場合における、消失したUsage Passの復旧処理シーケンスを示す図。 一実施例における、ＢＴモードに従って磁気ディスク装置から記録再生装置に対して送信されたUsage Passが消失した場合における、消失したUsage Passの復旧処理シーケンスを示す図。 一実施例における、ホストモジュールとデバイス２間における命令の転送のシーケンスを示す図。
符号の説明
１００：ネットワークインタフェース、 １０１：保護情報領域 １０２：記録モジュール １０３：再生モジュール １０５：ユーザインタフェースブリッジ １０６，１０７：外部ストレージインタフェース １０８：プロセッサ
１１０：ホストモジュール １１１：ホストセキュリティマネージャ １１２：記録再生装置 １５０：配信サーバ １２５，１２６：磁気ディスク装置
２２１：ユーザパス転送モジュール ２２２：制限記憶制御部 ２２３：制限記憶部 ２３１：プロセッサ

Claims (13)

  1. 暗号化されたコンテンツデータを復号化する鍵データと、前記コンテンツデータの利用条件を含む所定の情報を一方の装置から他方の装置へ転送し、或いは２つの装置の装置間でデータ転送を行うために与えられた、予め決められた複数の転送処理モードから１つの転送処理モードを選択する転送処理方法であって、この転送処理方法は、
    前記２つの装置間で相互認証を行い、
    認証の過程で得られた共通鍵データを用いて、前記２つの装置のうち一方の装置で所定の情報を暗号化し、
    選択された転送処理モードに従って、前記２つの装置のうち一方の装置で暗号化された所定の情報を他方の装置へ転送し、
    予め決められた複数の転送処理モードは、前記２つの装置のうち一方の装置から他方の装置に対して前記所定の情報を一方向へ転送する第１転送モード、及び前記２つの装置間における前記所定の情報の双方向転送が可能な第２転送モードであり、前記第１及び前記第２転送モードから選択されたいずれかの転送モードに従って前記所定の情報を受信したいずれか一方の装置は、共通鍵データを用いて前記所定の情報を復号化し、復号化された前記所定の情報を用いて、受信した前記コンテンツデータを復号化する転送処理方法。
  2. 請求項１に記載の方法であって、前記第１転送モードは、先に認証を行う認証情報を送信した前記２つの装置のうち一方の装置から他方の装置へ前記制御情報を一方向へ転送する方法。
  3. 暗号化されたコンテンツデータを復号化する鍵データと、前記コンテンツデータを使用する条件を含む所定の情報を一方の装置から他方の装置へ転送する転送処理方法であって、この転送処理方法は、２つの装置間のデータ転送を制御する処理装置の制御によって、前記２つの装置に対して、これら装置のそれぞれの内部データの転送機能に関する問合せを行い、問合せの結果、前記２つの装置間のデータ転送の前に、前記２つの装置のうち一方の装置から他方の装置へ所定の情報を一方向へ転送する第１転送モード、及び前記２つの装置間における所定の情報の双方向の転送が可能な第２転送モードのいずれかの転送モードを選択し、前記２つの装置間で相互の認証を行い、認証の結果、前記２つの装置が正当な場合は、前記２つの装置間で鍵データを共有し、この共有された鍵データを用いて、前記２つの装置のうち一方の装置で所定の情報を暗号化し、選択された転送モードに従って、前記２つの装置のうち一方の装置で暗号化された所定の情報を他方の装置へ転送する方法。
  4. 請求項３に記載の方法であって、所定の情報の転送時において、前記２つの装置の両方の装置は、前記所定の情報の処理に関連するトランザクションログを生成して、このトランザクションログを記憶装置に記憶し、正当性の認証時に鍵データが失われた場合、前記２つの装置はそれぞれ記憶装置に記憶された適切な前記トランザクションログを参照して共有すべき鍵データを生成し、この共有の鍵データを他方の装置へ送る方法。
  5. 請求項４に記載の方法であって、前記他方の装置は、前記記憶装置に記憶された前記トランザクションログを参照して、このトランザクションログに記録されている処理段階情報と前記所定の情報の存在状態情報を連結して、連結された情報を送信し、前記２つの装置のうち一方の装置は、受信した情報を検証して、改竄が行われていないことを確認した後、前記記憶装置に格納された適切な前記トランザクションログを参照して、前記トランザクションログに記録されている転送前のデータの復号条件を、現在存在している所定の情報により上書きする方法。
  6. 請求項１又は３に記載の方法であって、前記第２転送モードが選択された場合、正当性の認証時において、他方の装置は、自身の公開鍵が含まれる証明書を２つの装置のうち一方の装置へ送信し、前記２つの装置のうち一方の装置では、受信した証明書の正当性を検証して、一時的な共通鍵暗号化の鍵である第１チャレンジ鍵を生成し、受信した公開鍵を用いて前記第１チャレンジ鍵を暗号化し、生成された暗号化データに自身の公開鍵を含む証明書を連結して、連結したデータを他方の装置に送信し、この他方の装置では、受信したデータを、自身の秘密鍵を用いて復号化して前記第１チャレンジ鍵を取得し、一時的な共通鍵暗号化の鍵である第２チャレンジ鍵を生成し、この第２チャレンジ鍵と自身の情報領域に埋め込まれている公開鍵を連結して、受信した公開鍵で暗号化を行い、得られた暗号化データに対して、他方の装置に記録された証明書失効リストを連結し、連結したデータを前記第１チャレンジ鍵で暗号化し、暗号化したデータを前記２つの装置のうち一方の装置へ送信し、前記２つの装置のうち一方の装置は、受信したデータを前記第１チャレンジ鍵で復号化し、証明書失効リストにある発行日を比較し、その結果、受信した証明書失効リストの発行日が前記２つの装置のうち一方の装置に記録された証明書失効リストの発効日より新しければ、その装置の証明書失効リストを受信した証明書失効リストにより更新し、かつ、前記２つの装置のうち一方の装置はすべての復号化したデータから証明書失効リストを除いたデータを自身の秘密鍵で復号化し、更に、一時的な共通鍵暗号化の鍵である０次第１セッション鍵を生成し、先に受信した他方の装置の公開鍵及び前記第２チャレンジ鍵で暗号化を行い、暗号化されたデータを前記他方の装置へ送信し、この他方の装置は、受信した暗号化データを前記第２チャレンジ鍵で復号化し、この復号化データに前記２つの装置のうち一方の装置の証明書失効リストが含まれていた場合は、前記他方の装置に記録された証明書失効リストを受信した証明書失効リストにより更新し、この証明書失効リスト以外のすべての復号化データを自身の情報領域に埋め込まれている秘密鍵で復号化して前記０次第１セッション鍵を取得する方法。
  7. 請求項２又は３に記載の方法であって、前記第２転送モードが選択された場合、所定の情報の転送時において、前記他方の装置は、ｎ次第２セッション鍵を生成し、以前に生成されたｎ−１次第２セッション鍵と、その時点で最新のｍ次第１セッション鍵を用いて、ｎ次第２セッション鍵を暗号化して、暗号化データを前記２つの装置のうち一方の装置へ送信し、前記２つの装置のうち一方の装置は、暗号化したデータを受信した後、暗号化データをその時点で最新のｍ次第１セッション鍵及びｎ−１次第２セッション鍵を用いて復号化し、転送対象となる所定の情報の識別子、転送における自身の役割、送信予定の所定の情報、及び他方の装置における所定の情報の記録先アドレスを、トランザクションログに記録し、かつ、前記２つの装置のうち一方の装置は、所定の情報にその利用目的（つまり、少なくとも複製、移動、再生のいずれかを含む）を示すパラメータ及びチェックサムを連結し、ｎ次第２セッション鍵と共有鍵で暗号化を行い、暗号化されたデータを他方の装置へ送信し、この他方の装置は、暗号化データを受信した後、暗号化データを共有鍵及びｎ次第２セッション鍵を用いて復号化し、復号化されたデータを前記他方の装置の内部記憶領域に記録する方法。
  8. 請求項１又は３に記載の方法であって、前記所定の情報は、前記コンテンツデータの復号化を許容する条件を含むライセンス情報であって、ライセンス情報を受信した他方の装置は、前記２つの装置のうち一方の装置から送信され、前記記憶装置に記憶された前記コンテンツデータを、前記ライセンス情報を用いて復号化する方法。
  9. 請求項１又は３に記載の方法であって、前記２つの装置のうち一方の装置は、取得した前記コンテンツデータをそれぞれ記録再生する、記録モジュール及び再生モジュールを有する記録再生装置であり、他方の装置は、前記記録再生装置に接続されて、前記記録再生装置から転送される前記コンテンツデータを記憶する記憶装置であり、前記所定の情報は、前記記録再生装置が前記コンテンツデータを取得する時に取得され、前記記憶装置に記録されたコンテンツデータは前記記憶装置から前記記録再生装置に転送されて、再生モジュールで再生される方法。
  10. 請求項１又は３に記載の方法であって、所定の情報には、自身がどのような種類のモジュールに対して出力可能なものであるかを示すフォーマットと、特定の情報に一意に割り当てられた識別子と、前記コンテンツデータの利用を制限する条件と、暗号化されたコンテンツデータを復号化する鍵データと、関連するコンテンツデータを特定する識別子と、及び前記コンテンツの著作権情報が含まれる方法。
  11. 暗号化されたコンテンツデータを復号化する鍵データと、前記コンテンツデータを使用する条件を含む所定の情報を処理して、前記鍵データ及び前記所定の情報を一方の装置から他方の装置へ転送する処理方法であって、この処理方法は、
    ２つの装置間で相互に正当性を認証し、認証の結果、両方の装置が正当な場合は、前記２つの装置間で鍵データを共有する認証過程（ａ）と、共有された鍵データを用いて、前記２つの装置のうち一方の装置で所定の情報を暗号化し、暗号化された所定の情報を前記２つの装置のうち一方の装置から他方の装置へ転送する転送過程（ｂ）とを有し、（ａ）認証過程においては、他方の装置は、自身の公開鍵が含まれる証明書を前記２つの装置のうち一方の装置へ送信し、前記２つの装置のうち一方の装置では、受信した証明書の正当性を検証して、一時的な共通鍵暗号化の鍵である第１チャレンジ鍵を生成し、受信した公開鍵を用いて第１チャレンジ鍵を暗号化し、生成された暗号化データに自身の公開鍵を含む証明書を連結して、連結したデータを他方の装置へ送信し、他方の装置では、受信したデータを、自身の秘密鍵を用いて復号化して前記第１チャレンジ鍵を取得し、一時的な共通鍵暗号化の鍵である第２チャレンジ鍵を生成し、この第２チャレンジ鍵と自身の情報領域に埋め込まれている公開鍵を連結して、受信した公開鍵で暗号化を行い、得られた暗号化データに対して、他方の装置に記録された証明書失効リストを連結し、連結した２組のデータを前記第１チャレンジ鍵で暗号化し、暗号化したデータを２つの装置のうち一方の装置へ送信し、前記２つの装置のうち一方の装置は、受信したデータを前記第１チャレンジ鍵で復号化し、証明書失効リストにある発行日を比較し、その結果、受信した前記証明書失効リストの発行日が２つの装置のうち一方の装置に記録された証明書失効リストの発行日より新しければ、受信した証明書失効リストにより２つの装置のうち一方の装置に記録された前記証明書失効リストを更新し、かつ、前記２つの装置のうち一方の装置は、すべての復号化したデータから前記証明書失効リストを除いたデータを自身の秘密鍵で復号化し、更に、一時的な共通鍵暗号化の鍵である０次第１セッション鍵を生成し、先に受信した他方の装置の公開鍵及び前記第２チャレンジ鍵で暗号化を行い、暗号化されたデータを前記他方の装置へ送信し、この他方の装置は、受信した暗号化データを前記第２チャレンジ鍵で復号化し、復号化データに前記２つの装置のうち一方の装置の証明書失効リストが含まれていた場合は、自らの証明書失効リストを受信した証明書失効リストを用いて更新し、証明書失効リスト以外の復号化データのすべてを自身の情報領域に埋め込まれている秘密鍵で復号化して０次第１セッション鍵を取得し、（ｂ）転送過程においては、他方の装置は、ｎ次第２セッション鍵を生成し、先に生成されたｎ−１次第２セッション鍵と、その時点で最新のｍ次第１セッション鍵を用いて、ｎ次第２セッション鍵を暗号化して、暗号化データを前記２つの装置のうち一方の装置へ送信し、前記２つの装置のうち一方の装置は、暗号化したデータを受信した後、暗号化データをその時点で最新のｍ次第１セッション鍵及びｎ−１次第２セッション鍵を用いて復号化し、転送対象となる所定の情報の識別子、転送における自身の役割、送信予定の所定の情報、及び他方の装置における所定の情報の記録先アドレスを、トランザクションログに記録し、かつ、前記２つの装置のうち一方の装置は、所定の情報に、その利用目的（つまり、少なくとも複製、移動、再生のいずれかを含む）を示すパラメータ及びチェックサムを連結し、ｎ次第２セッション鍵と共有鍵で暗号化を行い、暗号化されたデータを前記他方の装置へ送信し、この他方の装置は、暗号化データを受信した後、受信した暗号化データを共有鍵及びｎ次第２セッション鍵を用いて復号化し、復号化されたデータを他方の装置の内部記憶領域に記録する方法。
  12. 請求項１１に記載の方法であって、所定の情報には、自身がどのような種類のモジュールに対して出力可能なものであるかを示すフォーマットと、特定の情報に一意に割り当てられた識別子と、前記コンテンツデータの利用を制限する条件と、暗号化されたコンテンツデータを復号化する鍵データと、関連するコンテンツデータを特定する識別子と、及びコンテンツの著作権情報が含まれる方法。
  13. 請求項１、３又は１１に記載の方法においてコンピュータ処理を実行するプログラム。
JP2005283878A 2005-09-29 2005-09-29 データ転送方法及びシステム Expired - Fee Related JP4755472B2 (ja)

Priority Applications (6)

Application Number Priority Date Filing Date Title
JP2005283878A JP4755472B2 (ja) 2005-09-29 2005-09-29 データ転送方法及びシステム
TW095130998A TW200718144A (en) 2005-09-29 2006-08-23 Method and system for transferring data
EP06017824A EP1770577A1 (en) 2005-09-29 2006-08-25 Method and system for transferring data
KR1020060090547A KR20070036667A (ko) 2005-09-29 2006-09-19 데이터 전송 방법 및 시스템
CN2006101595946A CN101047495B (zh) 2005-09-29 2006-09-28 用于传送数据的方法和系统
US11/541,463 US20070168663A1 (en) 2005-09-29 2006-09-29 Method and system for transferring data

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
JP2005283878A JP4755472B2 (ja) 2005-09-29 2005-09-29 データ転送方法及びシステム

Publications (3)

Publication Number Publication Date
JP2007096783A JP2007096783A (ja) 2007-04-12
JP2007096783A5 JP2007096783A5 (ja) 2008-10-23
JP4755472B2 true JP4755472B2 (ja) 2011-08-24

Family

ID=37684366

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2005283878A Expired - Fee Related JP4755472B2 (ja) 2005-09-29 2005-09-29 データ転送方法及びシステム

Country Status (6)

Country Link
US (1) US20070168663A1 (ja)
EP (1) EP1770577A1 (ja)
JP (1) JP4755472B2 (ja)
KR (1) KR20070036667A (ja)
CN (1) CN101047495B (ja)
TW (1) TW200718144A (ja)

Families Citing this family (17)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2007235323A (ja) * 2006-02-28 2007-09-13 Toshiba Corp 高度機密情報の保存／記録方法、高度機密情報を利用する再生装置および高度機密情報を格納するメモリ
JP5139028B2 (ja) * 2007-10-24 2013-02-06 エイチジーエスティーネザーランドビーブイ コンテンツデータ管理システム及び方法
JP5209945B2 (ja) * 2007-12-12 2013-06-12 株式会社日立製作所 記憶装置、暗号化コンテンツの有効化方法及び端末装置
US8619977B2 (en) * 2008-01-15 2013-12-31 Inside Secure Representation change of a point on an elliptic curve
US8082582B2 (en) * 2008-05-21 2011-12-20 Mediatek Inc. Authorization system of navigation device and associated authorization method
JPWO2011039913A1 (ja) * 2009-09-29 2013-02-21 パナソニック株式会社 映像音声信号伝送システムおよび映像音声信号切替・分配装置
CN101815290B (zh) * 2010-03-08 2014-02-05 北京英福生科技有限公司 一种运动监测数据的安全传输方法
JP5648531B2 (ja) * 2010-03-09 2015-01-07 ソニー株式会社 サーバ装置、クライアント装置、配信方法、プログラム
BR112014000515B1 (pt) * 2011-07-10 2021-04-27 Blendology Limited Dispositivo de compartilhamento de dados eletrônico e modo de uso
US9497682B2 (en) * 2013-06-07 2016-11-15 Intel Corporation Central processing unit and methods for supporting coordinated multipoint transmission in an LTE network
US10277559B2 (en) * 2014-05-21 2019-04-30 Excalibur Ip, Llc Methods and systems for data traffic control and encryption
US9584492B2 (en) * 2014-06-23 2017-02-28 Vmware, Inc. Cryptographic proxy service
CN105320894A (zh) * 2014-08-01 2016-02-10 国家电网公司 一种保护传输数据和存储数据的方法及装置
CN110140300B (zh) * 2016-11-04 2022-07-15 瑞典爱立信有限公司 用于波束跟踪过程管理和索引的方法和系统
CN108735043B (zh) * 2018-08-03 2021-05-28 苏州承儒信息科技有限公司 一种教育用递进式作业提交设备及其工作方法
US11038698B2 (en) * 2018-09-04 2021-06-15 International Business Machines Corporation Securing a path at a selected node
CN113114610B (zh) * 2020-01-13 2022-11-01 杭州萤石软件有限公司 一种取流方法、装置及设备

Family Cites Families (11)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP1212747A1 (en) * 1999-09-16 2002-06-12 Hanseulsoft Co., Ltd. Method and apparatus for playing musical instruments based on a digital music file
AU1557401A (en) * 1999-12-02 2001-06-12 Fujitsu Limited Memory card and data distribution system using it
US6898708B2 (en) * 1999-12-07 2005-05-24 Sanyo Electric Co., Ltd. Device for reproducing data
US7061899B2 (en) * 2001-05-01 2006-06-13 Hewlett-Packard Development Company, L.P. Method and apparatus for providing network security
CN1679102B (zh) * 2002-08-28 2010-12-01 松下电器产业株式会社 密钥传递设备、终端设备、记录介质以及密钥传递系统
US20050154889A1 (en) * 2004-01-08 2005-07-14 International Business Machines Corporation Method and system for a flexible lightweight public-key-based mechanism for the GSS protocol
JP4576853B2 (ja) * 2004-03-05 2010-11-10 ソニー株式会社 情報処理装置、および認証処理方法、並びにコンピュータ・プログラム
EP1738283A4 (en) * 2004-03-22 2013-08-21 Samsung Electronics Co Ltd METHOD AND DEVICE FOR ADMINISTERING DIGITAL RIGHTS BY CERTIFICATE RESTRICTIONS LIST
JP4663436B2 (ja) * 2004-07-21 2011-04-06 三洋電機株式会社 コンテンツ利用情報送信方法およびその方法を利用可能なコンテンツ利用情報提供装置およびコンテンツ利用情報享受装置
JP4795727B2 (ja) * 2005-06-14 2011-10-19 ヒタチグローバルストレージテクノロジーズネザーランドビーブイ コンテンツの利用端末を制限する方法、記憶装置およびシステム
US7958370B2 (en) * 2005-09-29 2011-06-07 Hitachi Global Storage Technologies, Netherlands, B.V. System and device for managing control data

Also Published As

Publication number Publication date
JP2007096783A (ja) 2007-04-12
KR20070036667A (ko) 2007-04-03
EP1770577A1 (en) 2007-04-04
CN101047495A (zh) 2007-10-03
TW200718144A (en) 2007-05-01
US20070168663A1 (en) 2007-07-19
CN101047495B (zh) 2012-07-04

Similar Documents

Publication Publication Date Title
JP4848163B2 (ja) コンテンツデータ管理システム及び装置
JP4755472B2 (ja) データ転送方法及びシステム
JP5036406B2 (ja) コンテンツデータ管理システム及び方法
US7958370B2 (en) System and device for managing control data
JP4555046B2 (ja) データ転送システム及びデータ転送方法
TW514844B (en) Data processing system, storage device, data processing method and program providing media
TW514845B (en) Data storage regenerator and data storage processing method and program providing media
CN102084373B (zh) 备份存储在安全存储设备中的数字内容
JP4884535B2 (ja) 装置間でのデータオブジェクトの転送
JP5139028B2 (ja) コンテンツデータ管理システム及び方法
US20080162947A1 (en) Methods of upgrading a memory card that has security mechanisms that prevent copying of secure content and applications
US20060106721A1 (en) Method for retransmitting or restoring contents key for decrypting encrypted contents data
JP2008009631A (ja) 記憶装置及び記憶方法
US20060069650A1 (en) Device and method for reproducing encrypted contents
US8156339B2 (en) Method for transmission/reception of contents usage right information in encrypted form, and device thereof
JP2002368735A (ja) マスタ用ｉｃ装置、マスタ用ｉｃ装置のためのバックアップ用ｉｃ装置、マスタ用ｉｃ装置にダミー鍵を与えるダミー鍵格納装置、マスタ用ｉｃ装置とバックアップ用ｉｃ装置とのための補助装置、及び二つ以上の補助装置を用いた鍵バックアップシステム
JP5076546B2 (ja) コンテンツデータ管理システム及び装置
JP2010146635A (ja) コンテンツ記録再生装置並びにコンテンツの書き込み及び読み出し方法
US8345868B2 (en) Data transfer system, data transfer method, data transmission device and data receiving device
JP4604523B2 (ja) データの移管方法およびデータの保管装置
JP3843566B2 (ja) ユーザ認証装置および方法
KR20070022257A (ko) 디지털 라이센스 공유 시스템 및 방법

Legal Events

Date Code Title Description
A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20080904

A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20080904

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

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

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

Free format text: PAYMENT UNTIL: 20140603

Year of fee payment: 3

R150 Certificate of patent or registration of utility model

Free format text: JAPANESE INTERMEDIATE CODE: R150

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

Free format text: PAYMENT UNTIL: 20140603

Year of fee payment: 3

S533 Written request for registration of change of name

Free format text: JAPANESE INTERMEDIATE CODE: R313533

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

Free format text: PAYMENT UNTIL: 20140603

Year of fee payment: 3

R350 Written notification of registration of transfer

Free format text: JAPANESE INTERMEDIATE CODE: R350

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

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