JP2009516961A - Method and system for managing key and / or rights objects - Google Patents

Abstract

  Using one or more rights object (RO) files to store the rights object (RO), preferably in a protected area that is accessible only to authorized users Can do. The RO navigation file is preferably stored in an unprotected public area that holds each status bit that identifies whether a location in the RO file has a valid RO. There is a one-to-one correspondence between the location of the RO in the RO file and the location of the status bit in the RO navigation file that identifies whether the corresponding location in the RO file has a valid RO. It is desirable that there is a corresponding relationship. Whether a particular location in the RO file has a valid RO can be found by examining its corresponding status bit in the RO navigation file. By determining in this manner whether a particular location in the RO file has a valid RO, it is possible to delete the RO without having to go through the authentication process. The process of finding an empty slot for storing a new RO in the RO file is also simplified. Thereby, the efficiency of RO management is remarkably improved. A similar system can be used for content encryption / encryption key management to protect content files.

Description

  The present invention relates generally to encryption / decryption systems, and more particularly to keys used for encryption and / or decryption and / or the right to control the use or access to content. The present invention relates to a system for managing objects.

  Media content such as music, video, and games is increasingly distributed as digital files. Such digital content is widely distributed over multiple channels, including the use of the Internet and storage devices. Digital content may be stored on a wide variety of devices, such as magnetic or optical disks, tapes, and non-volatile memory such as flash memory. The digital content of these storage devices includes both desktop and portable personal computers, iPod (TM) and other types of built-in or self-supporting media players, personal digital assistants ("PDA"), game controllers, MP3 players (TM) ), And various devices (generally referred to herein as “host devices”), such as mobile phone handsets, are played, stored, and operated.

  In order for digital content owners to reduce or prevent unauthorized access to content, digital content is often encrypted such that only authorized users can access the content. With the proliferation of a wide variety of digital files such as songs, the number of keys that need to be managed is increasing. In order to enhance security, a large number of keys are involved in the encryption and decryption of each digital file. Thus, one possible problem with digital rights management ("DRM") is to efficiently manage a large number of keys and encrypt any particular digital file. And / or the ability to determine a fair key for decryption.

  Multiple key management systems are used. In a first type of key management system, content files are named so that it is easier to identify and find encryption and / or decryption keys. In another type of key management system known as a file encryption system (“EFS”), the key itself used to encrypt the file is encrypted, and the encrypted key is stored in the encrypted file system. , Stored in the header of the corresponding encrypted content file. The key management system is useful for some applications, but each has its limitations. None of the above systems are entirely satisfactory. Accordingly, it is desired to provide a key management system that is more flexible and easier to use.

  In digital rights management (DRM), each content file may be associated with rules relating to or controlling how the content file is accessed and / or used. Such a rule is called a rights object in DRM. For example, a rule may define that a content file can be accessed only a limited number of times, only before a specific expiration date, or only during a specific period of time. Thus, when it is desired to control the use of and / or access to the content file, the rules described above and the content encryption / decryption key used to encrypt and / or decrypt the content file A rights object is created that can hold The rights object is then further associated with a content file controlled by the rights object. In many cases, rights objects control content file usage and / or access to content files by controlling access to content encryption / decryption keys used to encrypt / decrypt content files. To do. Thus, in order to be able to use and / or access a protected content file, first retrieve or otherwise obtain the rights object associated with it, and the rights The rule of the object is deciphered, and the content file is used or accessed according to the rule. If the content file is encrypted, take the key or keys from the associated rights object and use it to decrypt the file before using or converting it to the content for the first time Can be accessed. When it is desired to control the use and / or access to a content file, it is associated with that content file and has rules governing the use and / or access to the file; A rights object is created that has some encryption / decryption key used to encrypt / decrypt the content file.

  In DRM, there will be many rights objects that need to be managed. Thus, it may also be desirable to provide a management system for managing rights objects that is more flexible, easy to use, and capable of managing multiple rights objects.

  According to one embodiment of the present invention, a key navigation file and one or more key storage files may be used to facilitate key management. Each content file that is to be encrypted / decrypted indicates which key storage file has a key that will be used to encrypt and / or decrypt the content file. It has a header part that holds location information. The key navigation file holds state information indicating whether a valid key is stored at one or more locations in one or more key storage files. This facilitates the process of finding a place to store the key in one or more key storage files. The status information preferably indicates one or more locations in one or more key storage files where one or more valid keys are not stored.

  The key navigation mechanism comprising the key navigation file described above and one or more key storage files may be stored on a non-volatile computer readable medium.

  In one example of the above embodiment, the key navigation file is stored in a public unprotected area of the storage medium, and the one or more key storage files for storing the keys are authenticated. Stored in a protected area of the media that can only be accessed by a designated user, application or device. For obvious reasons, it is desirable to store one or more key storage files in a protected area that is not accessible for unauthorized access. Thus, key management performance is provided by providing a public area with a key navigation file that holds state information indicating whether one or more locations in the key storage file hold a valid key. Will be further strengthened. Thus, there is no need to access a protected area to determine if a particular key in a key storage file is valid, but instead this information can be accessed without authentication. Can be easily obtained in a file. This property also makes it particularly easy to delete a content file and its encryption / decryption key. In one embodiment, to delete a key, without having to actually access the key storage file of the protected area holding the key, simply change the state information in the key navigation file, Key deletion is accomplished.

  According to another embodiment of the present invention, the key navigation file and one or more key storage files are easily utilized in a process for encrypting / decrypting content files. Each entry in the key navigation file corresponds to a location for storing one of a plurality of encryption / decryption keys in one or more key storage files. The key navigation file may be opened to allow it to find an entry that does not correspond to a valid key at a location in one or more key storage files. An encryption / decryption key is generated and the content file is encrypted / decrypted thereby. The encryption / decryption key is then stored in the location corresponding to the entry found in the key navigation file in the one key storage file.

  In one example of the embodiment described above, the key navigation information is derived from the location of the entry found in the key navigation file that does not correspond to a valid key, and this location information is encrypted. Inserted in the header of the file. Thus, in the reverse process, by decrypting the location information in the header portion of the encrypted file, the location of the encryption / decryption key in one of the one or more key storage files is determined, Once extracted, the encrypted file is decrypted and / or encrypted.

  According to another embodiment of the invention, the content file is decrypted using the decryption key of the key storage file in the protected area of the storage medium. The header portion of the content file holds key navigation information indicating the location of the encryption / decryption key for decrypting / decrypting the content file in the key storage file. Key navigation information is retrieved from the header portion of the content file, and then the location in the key storage file where the decryption key is stored is derived from the key navigation information. A decryption key is then obtained from the protected area and used to decrypt the content file. This process can also be used to find a specific key in the key storage file for encrypting the content file, in which case the key location information can be found in the header of the content file .

  In one particular example of the embodiment just described, multiple key storage files are used to store the keys. In this embodiment, the key navigation information in the header portion of the content file includes an indesk, and this index is an integer. Each key storage file has m locations for storing keys. Divide the index by m to get the quotient. The integer part of the quotient indicates which one of the key storage files stores the decryption / encryption key, where the remainder, also referred to as an offset, is the encryption in such a key storage file. It shows where the decryption / encryption key is stored.

  Yet another embodiment of the present invention provides a content file using a key navigation file stored in a key storage file and having state information indicating whether or not the key stored in the key storage file is valid It focuses on a method for revoking the encryption / decryption key used for encryption / decryption. The content file includes a header portion that holds location information indicating the location of the key in the key storage file. The key location information in the key file is obtained from the header portion of the content file. This location information is used to find key status information in the key navigation file.

  The key status information in the key navigation file is changed to indicate that the key is invalid.

  Any of the methods described above may be performed by a computer program executed by a processor, and the program is stored in a computer-readable storage medium.

  According to another embodiment of the present invention, a computer program stored on a computer readable medium may be used to facilitate key management. The computer program creates a key navigation file and creates one or more key storage files if they do not already exist. Each content file has a header portion that holds location information indicating which key storage file holds the encryption / decryption key for that content file. The key navigation file holds state information indicating whether one or more locations in the one or more key storage files have valid keys.

  In one example of the above embodiment, an entry is found in the key navigation file that does not correspond to a valid key in at least one key storage file. The key navigation information of this content file is obtained from the location of the entry in the key navigation file. An encryption / decryption key is generated and used to encrypt / decrypt the content file. The encryption / decryption key is stored in a location corresponding to the entry in at least one key storage file.

  According to another embodiment of the present invention, a computer program stored on a computer readable medium uses an encryption / decryption key in a key storage file in a protected area of a storage device to Encrypt / decrypt files. The content file header holds key navigation information indicating the location of the encryption / decryption key in the key storage file. The computer program extracts the key navigation information from the content file, derives the location where the encryption / decryption key is stored in the key storage file from the key navigation information, and obtains the encryption / decryption key. , This key is used to encrypt / decrypt the content. In one example of this embodiment, a plurality of key storage files, each having m locations, are used to store the keys. The key navigation information includes an index, which is an integer, and the computer program divides this index by m to obtain the quotient, so that one of the key storage files stores the decryption / encryption key. And the location where the key is stored in the key storage file. The integer part of the quotient indicates which one of the plurality of key storage files stores the decryption / encryption key, and the remainder, also referred to herein as the offset, is in the key storage file, It shows where the decryption / encryption key is stored.

  The method implemented by the computer program described above is the subject of another aspect of the present invention.

  According to yet another embodiment of the invention, a non-volatile computer readable medium stores a key navigation mechanism, the medium comprising at least one protected area and at least one unprotected area. It has. This mechanism comprises a key navigation file and at least one key storage file. Each key storage file has a plurality of keys used for corresponding one encryption and / or decryption of a plurality of content files at a corresponding location in the key storage file. The mechanism includes a first directory tree comprising a directory holding a list of content files and a key navigation file in at least one unprotected area of the medium. The mechanism further includes a second directory tree comprising a directory holding a list of keys in at least one key storage file in at least one protected area of the medium, the 2 Two directory trees have structures that are mirror images of each other.

  The systems and methods described above may be adapted to manage content protection information such as rules governing access to and / or use of content instead of or in addition to key management. Good. Thus, in one use case, the systems and methods described above may be adapted to manage rights objects that control the use and / or access to content files.

  Thus, according to yet another embodiment of the present invention, a rights object navigation file and one or more rights object storage files may be used to facilitate rights object management. Each content file that is to be controlled with a rights object has a rights object that should be used to control which rights object storage file uses and / or accesses the content file. It has a header portion that holds location information indicating whether or not it exists. The rights object navigation file holds state information indicating whether a valid rights object is stored in one or more locations within one or more rights object storage files. This facilitates the process of finding a location for storing rights object keys in one or more rights object storage files. The status information preferably indicates one or more locations in the one or more rights object storage files where one or more valid keys are not stored.

  The rights object navigation mechanism comprising the rights object navigation file described above and one or more rights object storage files may be stored on a non-volatile computer readable medium.

  In one example of the above embodiment, the rights object navigation file is stored in a public unprotected area of the storage medium, and one or more rights object storage files for storing rights objects. Is stored in a protected area of the media that can only be accessed by authorized users, applications or devices. For obvious reasons, it is desirable to store one or more rights object storage files in a protected area that is not accessible for unauthorized access. Thus, by providing to the public area a rights object navigation file that holds state information indicating whether one or more locations of the rights object storage file have valid rights objects. The rights object management performance will be further enhanced. Thus, there is no need to access the protected area to determine whether a particular rights object in the rights object storage file is valid, instead this information can be accessed without authentication. It can be easily obtained in the rights object navigation file. This property also makes it particularly easy to delete content files and rights objects associated with them. In one embodiment, in order to delete a rights object, the state information in the rights object navigation file is simply stored without having to actually access the rights object storage file of the protected area holding the rights object. In other words, the deletion of the rights object is accomplished.

  In accordance with one or more embodiments of the present invention, the rights object navigation file and one or more rights object storage files can be readily utilized in the process of associating rights objects with content files. Each entry in the rights object navigation file corresponds to a location for storing one of a plurality of rights objects in one or more rights object storage files. The rights object navigation file may be opened to allow it to find an entry that does not correspond to a valid rights object at a location in one or more rights object storage files. A rights object is created and the content file is associated with it. Thus, the rights object is stored in a location in the one rights object storage file corresponding to the entry found in the rights object navigation file.

  In one example of the above embodiment, rights object navigation information is derived from the location of an entry found in the rights object navigation file that does not correspond to a valid rights object, and the location information is encrypted. It is inserted into the header part of the converted file. Thus, in the reverse process, the location information of the header portion of the content file is decrypted to determine the location of the rights object in one of the rights object storage file or files, and the rights object is the content object. Retrieved for file use and / or access.

  According to another embodiment of the invention, the content file may be encrypted / decrypted using the rights object storage file encryption / decryption rights object in the protected area of the storage medium. . The header portion of the content file holds rights object navigation information indicating the location of the rights object associated with the content file in the rights object storage file. Rights object navigation information is retrieved from the header portion of the content file, and then from the rights object navigation information, the location in the rights object storage file where the rights object is stored is derived. A rights object is then obtained from the protected area and utilized to access the content file and / or use the content file in some way. This process can also be used to find a particular rights object in a rights object storage file when use of and / or access to the content file is desired, in which case location information for that rights object Is found in the header of the content file.

  In one particular example of the embodiment just described, multiple rights object storage files are used to store rights objects. In this embodiment, the rights object navigation information in the header portion of the content file includes an indesk, and this index is an integer. Each rights object storage file has m locations for storing rights objects. Divide the index by m to get the quotient. The integer part of the quotient indicates which one of the plurality of rights object storage files stores the rights object, and the remainder part, also referred to as offset here, is the rights object in the rights object storage file. Indicates the location where is stored.

  Yet another embodiment of the present invention is stored in a rights object storage file using a rights object navigation file that holds state information indicating whether the rights object stored in the rights object storage file is valid. Focus on methods for revoking rights objects that are used to control the use of and / or access to content files. The content file has a header portion that holds location information indicating the location of the rights object in the rights object storage file. The location information of the rights object in the rights object file is obtained from the header portion of the content file. The status information of the rights object in the rights object navigation file is found using the location information. The status information of the rights object in the rights object navigation file is changed to indicate that the rights object is invalid.

  Any of the methods described above may be performed by a computer program executed by a processor, and the program is stored in a computer-readable storage medium.

  According to another embodiment of the invention, a computer program stored on a computer readable medium may be used to facilitate rights object management. The computer program creates a rights object navigation file and creates one or more rights object storage files if they do not already exist. Each content file has a header portion that holds location information indicating which rights object storage file holds the rights object of the content file. The rights object navigation file holds state information indicating whether one or more locations in the one or more rights object storage files have valid rights objects.

  In one example of the above embodiment, an entry is found in the rights object navigation file that does not correspond to a valid rights object in at least one rights object storage file. The rights object navigation information of the content file is obtained from the location of the entry in the rights object navigation file. A rights object is generated and associated with the content file. The rights object is stored in a location corresponding to the entry in at least one rights object storage file.

  According to another embodiment of the present invention, a computer program stored on a computer readable medium uses a rights object in a rights object storage file of a protected area of a storage device to use the content file and Control access to content files. The content file header holds rights object navigation information indicating the location of the rights object in the rights object storage file. The computer program extracts the rights object navigation information from the content file, derives from the rights object navigation information the location where the rights object is stored in the rights object storage file, obtains the rights object, and obtains the rights object. Use to use or access content files. In one example of this embodiment, multiple rights object storage files, each having m locations, are used to store rights objects. The rights object navigation information includes an index, the index is an integer, and the computer program divides the index by m to obtain the quotient, so that one of the rights object storage files stores the rights object. And the location where the rights object is stored in the rights object storage file. The integer part of the quotient indicates which one of the plurality of rights object storage files stores the rights object, and the remainder part, also referred to as offset here, is the rights object in the rights object storage file. Represents the location where is stored.

  According to yet another embodiment of the invention, a non-volatile computer readable medium stores a rights object navigation mechanism, the medium having at least one protected area and at least one unprotected. Has an area. This mechanism comprises a rights object navigation file and at least one rights object storage file. Each rights object storage file has a plurality of rights objects that are used to control one corresponding use of the plurality of content files and access to the file at a corresponding location in the rights object storage file. Yes. The mechanism includes a first directory tree comprising a directory holding a list of content files and a rights object navigation file in at least one unprotected area of the medium. The mechanism further includes a second directory tree comprising a directory holding a list of rights objects in the at least one rights object storage file in at least one protected area of the medium; The two directory trees have a structure in which each other is a mirror image.

  The method implemented by the computer program described above is the subject of another aspect of the present invention.

  The above properties may be used alone or together in any combination.

  For ease of explanation, in this application, identical components are identified with the same numbers.

  An example of a memory system in which various embodiments of the present invention can be implemented is shown in the block diagram of FIG. As shown in FIG. 1, the memory system 10 includes a central processing unit (CPU) 12, a buffer management unit (BMU) 14, a host interface module (HIM) 16, a flash interface module (FIM) 18, a flash memory 20, and A peripheral access module (PAM) 22 is included. The memory system 10 communicates with the host device 24 through the host interface bus 26 and the port 26a. The flash memory 20 may be a NAND type, but provides a data storage unit for the host device 24. The software code of the CPU 12 is also stored in the flash memory 20. The FIM 18 is connected to the flash memory 20 through the flash interface bus 28 and the port 28a. The HIM 16 is suitable for connection to host systems such as digital cameras, desktop or portable personal computers, personal digital assistants (PDAs), digital media players, MP3 players, video game players, and mobile phones or other digital devices. . Peripheral access module 22 selects an appropriate control module such as FIM, HIM, and BMU to communicate with CPU 12. In one embodiment, all of the components in the dotted box of system 10 may be enclosed in a single unit, such as a memory card or stick 10 ', preferably in the same housing or container. It may be encapsulated in a card or stick.

  The buffer management unit 14 includes a host direct memory access (HDMA) 32, a flash direct memory access (FDMA) controller 34, an arbiter 36, a buffer random access memory (BRAM) 38, and a cryptographic engine 40. The arbiter 36 is a shared bus arbiter so that only one master or initiator (possibly HDMA 32, FDMA 34, or CPU 12) is active at all times, and the slave or target is the BRAM 38. The arbiter is responsible for channeling the appropriate initiator request to the BRAM 38. HDMA 32 and FDMA 34 are responsible for data transported between HIM 16, FIM 18, and BRAM 38 or CPU random access memory (CPU RAM) 12a. Since the operation of each of the HDMA 32 and the FDMA 34 is conventional, it is not necessary to explain in detail here. The BRAM 38 is used to buffer data transmitted between the host device 24, the flash memory 20, and the CPU RAM 12a. HDMA 32 and FDMA 34 are responsible for transferring data between HIM 16 / FIM 18 and BRAM 38 or CPU RAM 12a and for indicating sector transfer completion.

  First, when data from the flash memory 20 is read by the host device 24, the encrypted data in the memory 20 is taken out through the bus 28, FIM 18, FDMA 34, and the cryptographic engine 40, and encrypted by the cryptographic engine 40. The data being decrypted is decrypted and stored in the BRAM 38. The decrypted data is then sent from the BRAM 38 through the HDMA 32, HIM 16, and bus 26 to the host device 24. Since the data retrieved from the BRAM 38 may be re-encrypted using the cryptographic engine 40 before being sent to the HDMA 32, the data sent to the host device 24 is re-encrypted but stored in the memory 20. The data being encrypted is encrypted using a key and / or algorithm that is different from the key and / or algorithm that was decrypted. Desirably, in an alternative embodiment, rather than storing the decrypted data in the process described above in the BRAM 38, such data is exposed to unauthorized access. Therefore, when the data from the memory 20 is decrypted, the data is encrypted again by the cryptographic engine 40 and then sent to the BRAM 38. The encrypted data in the BRAM 38 is then sent to the host device 24 as before. The flow of data during the reading process has been described above.

  When data is written into the memory 20 by the host device 24, the direction of the data flow is reversed. For example, if unencrypted data is sent by the host device through the bus 26, HIM 16, HDMA 32 to the cryptographic engine 40, the data may be encrypted by the engine 40 before being stored in the BRAM 38. Good. In the alternative, unencrypted data may be stored in the BRAM 38. In this case, the data is encrypted before being sent to the FDMA 34 on the way to the memory 20. When the data to be written is subjected to the multi-stage encryption process, it is desirable that the processed data is stored in the BRAM 38 only after the engine 40 completes the process.

Although the memory system 10 shown in FIG. 1 possesses flash memory, the system may alternatively be instead of another type of non-volatile memory, such as a magnetic disk, optical CD, or any other type. And the various advantages described above are equally applicable to such alternative embodiments. In an alternative embodiment, as is also desirable, the memory is encapsulated with the remaining components of the memory system in the same physical entity (eg, memory card, stick, etc.).
Title key management

  FIG. 2 is a schematic diagram illustrating the structure of a title key file to illustrate one embodiment of the present invention. If multiple encryption / decryption keys are employed for digital rights management, it may be convenient to organize and store these keys into a plurality of individual title key files as shown in FIG. In the embodiment of FIG. 2, the title key file 102 is designed to have 127 slots or locations and can hold up to 127 keys. As shown in FIG. 2, the file 102 has a total of 128 slots or locations, and the very first slot or location 102a is reserved for the header and is not used to store the key. Initially, 127 slots or locations may all contain 1 or 0, or any value, which is not a valid key value. By overwriting the initial value, it is desirable that a valid title key entry (“TKE”) be continuously written to 127 slots or locations, and all 127 slots or locations are filled with valid key values. Sometimes they will have the following values: TKE1, TKE2,... TKE127. Whether or not a particular title key entry is a valid key is preferably indicated by a title key status bit stored in the key navigation file illustrated in FIG. 3A. Thus, by examining the corresponding title key status bits of some particular title key entry in the file 102, whether the entry is composed of valid keys without actually accessing the title key file 102? Alternatively, it can be determined whether or not a valid key is held.

  FIG. 3A is a schematic diagram showing the structure of a key navigation file. As shown in FIG. 3A, the key navigation file 104 includes a number of key file status (“KFS”) fields, namely KFS000, KFS001,... KFS031, KFS032, KFS033,. . Each title key status field has a title key status bit of the corresponding title key file. Thus, since the key file status field 104a titled KFS000 holds 127 title key status bits of 127 title key entries of the title key file 102, the file 104a contains 16 title keys. Requires byte storage. When the number of keys used for encryption / decryption exceeds 127, all slots or places of the title key file 102 are used up, so the keys for the number exceeding 127 are stored. It is necessary to create a new title key file. Thus, a title key status field 104b is created in the key navigation file 104 to store title key status bits that indicate the status of excess title key entries in the new title key file. FIG. 3A illustrates a situation in which at least 64 title key files have been created, and the key navigation file 104 includes at least 64 title key status fields from KFS000 to KFS063. The relationship between the key navigation file 104 and the title key file is shown in more detail in FIG. 3B.

  As shown in FIGS. 3A and 3B, the title key file is named in the format “key_file.xxx”, where xxx is the serial number of the title key file. Thus, the first created key file 102 is given a file name key_file.000, the next created key file is assigned the name key_file.001, and so on.

  In one embodiment, each slot or location in key navigation file 104 and the entry therein is a particular slot or location in one of the title key files and the title key entry for that slot or location. And a known one-to-one correspondence. In this manner, to determine whether a particular title key entry has a valid key, find the location or slot in the key navigation file 104 corresponding to that title key entry in the key navigation file 104, and key navigation. All that is required is to examine the key file status bit at that location in file 104.

In this embodiment of the invention, title key entries are labeled sequentially across different title key files, as shown in FIG. 3B. Thus, the title key entries in the title key file key_file.000 are labeled TKE1-TKE127. The title key entry in the title key file key_file.001 is labeled TKE129-TKE255. Those in the title key file key_file.002 are labeled TKE257-TKE383, and so on. Each first location and entry of the title key file (ie, TKE0, TKE128, TKE256...) Can hold information such as file size, version number, and other information about the file. Reserved for header use. Thus, each title key entry has a unique number associated with it, which is one of the following numbers: 1-127, 129-255, 257-383, etc. It is. This unique number is then preferably also used to identify the specific location within the key navigation file where the corresponding key file status bit is located. As shown in FIG. 3B, the key file status bits corresponding to the title key entry are stored at each location in the same order as the title key entry across different title key files. For example, as shown in FIG. 3B, the title key entry TK
The key file status bit “KFS [i]” for indicating whether or not E [i] has a valid key is at the top of the first key file status field KFS000 in the key navigation file 104. This is true even if it is stored in the i th location counting from the first location, and the i th location is in a key file status field different from KFS000. In other words, this unique number is unique across all key status fields, starting from the first entry at the top of KFS000 across all key file status fields KSF000, KFS001. Numbers are assigned in order up to the last key file status entry in the key navigation file 104.

  In this manner, by examining the specific location of the key file status bit and the unique number in the serial unique number associated with that bit in the key navigation file 104, which particular title key file and its file Can be easily determined, and the corresponding title key entry can be found using the simple process described below. The reverse process is therefore also true. Knowing the unique number associated with a particular title key file and the location of that particular title key entry in that file, the corresponding key file status bits for that entry can also be found in the key navigation file 104. Can do.

  In this one embodiment, the process of finding a title key entry corresponding to a particular key file status bit in the key navigation file 104 is performed as follows. The unique number associated with each title key entry and its corresponding key file status bit is called a key navigation index (“KNI”). Thus, the KNI values 0, 128, 256, 384,... (N + 128) are rule violations, where N is an integer. KNI is therefore also the offset of the key file status bit in key navigation file 104 from the very first status bit in the KFS000 header. By noting the location, offset, and thus its corresponding KNI value of a particular status bit in the key navigation file 104, the location of the corresponding title key entry can be easily determined. This is done by dividing the KNI value by the number of slots in each of the title key file and key file status fields, ie 128 in the embodiment of FIG. 3B. Here, the integer part of the quotient provides the serial number of the title key file holding the corresponding title key entry. In other words, the serial number of the title key file holding the title key entry is given by the integer part of KNI / 128. The specific location of the title key entry in the title key file holding the entry can be found from the remainder of the part or by KNI% 128 or KNI mod 128, and this value is the title The offset from the top entry in the title key file where the title key entry will be found at the particular location of the key entry.

  In one embodiment shown in FIG. 3B, for a title key entry i (TKE i), i.e., an entry with a key navigation index (KNI) i, a situation is being attempted to find a specific title key file and the location within that file. Is assumed. Thus, the title key entry indicating the state of the title key entry is KFS [i] in the navigation file 104. In the particular embodiment shown in FIG. 3B, the status bits are found in the key file status field 001, ie KFS001. The particular title key file where the title key entry is found is given by i% 128 or i mod 128. In the embodiment illustrated in FIG. 3B, since i has a value between 129 and 255, the integer part of i divided by 128 is 1, so the title key file key_file.001 corresponds. It is easily required to have the title key entry i to be held. Next, the remainder of the division is obtained by performing operation i mod 128, and the offset of the title key entry TKEi from the top entry in the title key file key_file.001 is given from this remainder. Thus, with the two very simple operations described above, a place that has a particular title key file and a title key entry in that file that corresponds to a particular place in the key navigation file. ,can be found.

  In the above embodiment, each title key file has 128 entries of 16 bytes each. Obviously, the title key file may have a number of entries other than 128, in which case each entry may have a number of bytes other than 16. Thus, if m is any positive integer and each title key file has m entries, the above operation is changed to divide KNI or key navigation index by m instead of 128 There is a need to. The offset can be found by i mod m instead of finding the offset of the title key entry TKEi from the top entry in its title key file. All such variations are within the scope of the present invention.

  Instead of using the unique number KNI and the operations i / m and i mod m as described above to locate the key in the title key file or to locate the status bit in the key navigation file, A one-to-one correspondence between entries in the key navigation file and the TKE in each file of the title key file can be established using a lookup table. In this case, the CPU 12 needs to look up the lookup table to find the location of the corresponding key given the location of the status bit in the key navigation file, and vice versa (ie in a particular title key file). The same is true for finding a state bit in the key navigation file that presents the key state, assuming that the key location is given. These and other variations are within the scope of the present invention.

  In one embodiment, only 7 of the 16 bytes are used for each title key entry as the key value for encryption / decryption. The key value is preferably encrypted or decrypted using another key. In the embodiment of FIG. 3B, when the title key status bit has a value of 0, this indicates that the title key entry is busy, i.e., as in the header of each title key file. It means that either the bit is reserved or the corresponding title key entry has a valid key and therefore cannot be used to store a new key. If the title key status bit is a value of 1, this means that the corresponding title key entry is empty or does not have a valid key, so the corresponding slot or location in the title key file is , Indicating that it can be used to store the encryption / decryption key by overwriting the slot or location of the title key entry.

  The length of the key navigation file is not defined and is determined by the number of title key files. In the embodiment illustrated in FIGS. 3A and 3B, the key navigation file comprises a 512 byte record. Thus, even if the length of the file is not defined, it is a multiple of 512 bytes in the embodiment of FIGS. 3A and 3B. New records are added to the file as needed. The title key status bit value is a Boolean number, while the serial number of the title key file and the key navigation index are decimal numbers in the embodiment of FIGS. 3A and 3B.

  FIG. 4 is a schematic diagram of a directory tree structure 130 in an unprotected user data area used to illustrate one embodiment of the present invention. The directory tree structure 130 of FIG. 4 is a file stored in the flash memory 20, and here, since the directory structure is stored in an unprotected user data area, any user, device, or application can be accessed. Can be accessed without authentication. As shown in FIG. 4, the directory tree structure has a root directory and two side branches, namely a player 1 directory and a player 2 directory. Player 1 or 2 can be any user, device, or application. The two branches make it easily accessible to two different players. The player 1 directory includes a plurality of different content files such as “Myson.MP3”, “Another.MP3”, and the key navigation file “KNF.bin”. The player 2 directory holds a list of similar content files and another key navigation file “KNF.bin”. Thus, when the player 1 accesses the user data area, the player 1 is led to the player 1 directory and to the content file and key navigation file under the directory. The same is true for access by player 2, player 2 being directed to a content file in the player 2 directory as well as a key navigation file in that directory. In this way, when the player 1 creates a content file, this file is created and added to the list under the player 1 directory. When a content file is created for player 2, this new content file is also posted in the player 2 directory.

  The content files in the tree 130 (for example, “Myson.MP3”, “Another.MP3”...) Are encrypted using the keys stored in the directory of the tree 150 in FIG. In some applications, encrypted content files and unencrypted content files (not shown in FIG. 4) are both stored in the same unprotected user data area that can be accessed without authentication. May be.

  FIG. 5 is a schematic diagram of the directory tree 150 of the protected area of the memory device 20, and the directory trees 130 and 150 of FIGS. 4 and 5 are mirror images of each other. Accordingly, in FIG. 5, the directory tree has a root directory and a player 1 directory and a player 2 directory. The player 1 directory includes a title key file key_file.c that holds a plurality of different title key entries for encrypting and / or decrypting the content file of the player 1 directory in the tree 130. 000 is published. The player 2 directory also has a title key file key_file. 000. Note that even though two title key files under two directories have the same name (ie, key_file.000), they are not confused because they are in different directories. The same is true for the key navigation files in the two directories of the tree 130 of FIG.

  Since the two directory trees 130 and 150 have the same branch, namely the player 1 directory and the player 2 directory, the contents of the directory players 1 and 2 are different between the two trees 130 and 150. Even if they are mirror images of each other. Two directories may have more branches at the same level as Player 1 and Player 2 between each of the trees 130 and 150, such as Player 3 (not shown in FIGS. 4 and 5). . Two directory players 1 and 2 can also have subdirectories. For example, the Player 1 directory in the tree 130 has two subdirectories, one for video files and one for audio files (not shown in FIG. 4). The audio file subdirectory will hold a list of audio files such as songs and key navigation files for navigating between such audio files. The video subdirectory may have a key navigation file for navigating between video files and such audio files. In such a case, the directory tree 150 in FIG. 5 also has a similar tree structure. In this way, the Player 1 directory of the tree 150 may have two different subdirectories, an audio and video subdirectory (not shown in FIG. 5). Each video subdirectory holds a list of one or more title key files that each have a title key entry that is used to encrypt / decrypt video files in the video subdirectory of the directory tree 130. The directory tree 150 will also have an audio subdirectory under the player 1 directory, which encrypts / decrypts the corresponding audio files listed in the audio subdirectory of the directory tree 130, respectively. You will have one or more title key files that hold the title key entries that are used for this purpose. As will be described below, having directory trees 130 and 150 that are mirror images of each other in the unprotected area and the protected area makes the operation of the key navigation mechanism much smoother.

  Before a protected content file is created in the memory device 20, there is typically no key navigation file or key storage file in the memory device 20. In that case, when the first content file to be protected is created, the key manager, also referred to here as the key navigation mechanism, creates a key navigation file in the unprotected user area and first in the protected area. Create a title key storage file.

  FIG. 6 is a flowchart illustrating a process or method performed by the key navigation file mechanism. The mechanism for performing the process of FIG. 6 may comprise computer program code stored and executed on the host device 24 that sends commands to the memory system in which the content file, title key file, and key navigation file are stored. . Alternatively, the mechanism may comprise computer program code stored in flash memory 20 that is loaded into CPU 12 and executed. Thus, the computer program for the key navigation mechanism of FIGS. 6 and 7 may be stored on a computer readable medium that is part of or connected to the host device 24, but instead. Such a computer program may be stored in the flash memory 20 in which the title key file, the key navigation file, and the content file are stored. All such variations are within the scope of the present invention.

  Referring to FIG. 6, the process of the mechanism of FIG. 6 is initiated when it is desired to open a protected content file or when a protected content file is about to be created (block 202). ). The key navigation mechanism determines whether a content file exists (diamond 204). If the content file does not exist, this means that the content file should be created. Therefore, the host device 24 or the CPU 12 creates the file, for example, in the directory tree 130 in the player 1. (Block 206). When the content file is created, the key navigation mechanism checks whether the key navigation file already exists or has been created (diamond 207a). If not, the mechanism creates a key navigation file (block 207b). If so, the mechanism opens a key navigation file that is found in the same directory as the newly created content file in a directory such as directory 130 shown in FIG. 4 (block 208). In either case, the mechanism now looks in the key navigation file in the player 1 directory of the tree 130 and finds that the first key entry is in the “empty” state. The key navigation file offset is “empty”, so that a key navigation index (KNI) is provided (blocks 208 and 210) and the above embodiment using KNI is employed.

  When a title key file and a key navigation file are used in the above embodiment, the locations or title key entries in the title key file are used in turn. This means that when one encryption / decryption key is created and needs to be stored in the title key file, the slot or location in the title key file stores the key in the title key file key_file. . It means that the title key entries 1 are used in order starting from 000. After that key is stored and forms key entry TKE1 or a part thereof, the value of its corresponding key file status bit KFS [1] is changed from 1 to 0, so that it is now not busy and now busy That is, since this location is not reserved for the header, it is displayed that it now contains a valid key. Initially, all of the key file status bits have a value of 1, except for the 0, 128, 256... Key file status bits, which have the value 0.

  After obtaining the KNI, the key navigation mechanism then calculates a key file index or nnn equal to the integer part of KNI / 128 if each of the title key files has 128 slots or locations ( Block 212). The nnn or key file index is an integer part of several KNI / 128. The nnn or key file index value is a serial number of the title key file. The offset in the title key file is then obtained by calculating the quantity KNI% 128 or KNI mod 128 (block 214).

  As pointed out above, the content file is created in a directory such as the player 1 directory of the directory tree 130 of FIG. A key navigation mechanism to obtain a location in the protected area title key file to store the encryption / decryption key used to encrypt / decrypt this content file just created Is now constructed according to the directory tree 130 in the unprotected user data area by replacing the public partition name of the unprotected user data area with the protected partition name of the protected area The access path is converted to one constructed according to the directory tree 150 within the protected area or partition (block 216). The key navigation mechanism then forms a key file name, “key_file.nnn” (block 218). The key navigation mechanism then forms a complete key file name (block 220). As an example, assume that Player 1 is creating a new song file to be encrypted according to blocks 208, 210, 212, 214, 216, 218, and 220. In this case, the complete key file name to be created is “prot_partition / layer1directory / key_file.nnn”.

  The key navigation mechanism then determines whether there is a title key file having this key file name (diamond 221a). If this title key file does not exist, the mechanism creates one file and adds it to the appropriate directory (eg, player 1) in the directory tree 150 (block 221b). If this title key file exists, the mechanism opens the title key file using an access path based on the complete key file name (block 222). The key navigation mechanism then checks whether the content file was originally present before block 206 (diamond 224). In the above example, the content file exists before it was created at block 206, so the key navigation mechanism proceeds to block 226 and inserts the KNI into the file header of the created file. . A content encryption key (CEK) is created by the encryption engine 40 and is used to encrypt the created file (228). The newly created file that has been encrypted is added to the directory player 1 of the tree 130 in the memory device 20. This created key is encrypted and inserted into the title key file identified at block 212 at the location indicated by the offset obtained at block 214 (block 230) and the title of directory player 1 in tree 150. Added as a new title key entry to the key file. The key navigation mechanism then closes the title key file (block 232) and changes the value of its corresponding status bit in the key navigation file in the player 1 directory of the tree 130 from 1 to 0, but the key file status bit is , Using the value of KNI as an offset in the key navigation file of the player 1 directory of the tree 130. The key navigation file is then closed (blocks 234 and 236).

  The above is the process of a key navigation mechanism using two directory trees 130 and 150 when a content file to be encrypted (and / or decrypted) is first created. When it is desired to decrypt the content file, and thus the key navigation mechanism is required to find the decryption key required to decrypt the content file, the key navigation mechanism of FIG. To work. The key navigation mechanism opens the protected content file in a particular directory, such as the Player 1 directory of the tree 130, and proceeds to block 252 because the content file already exists. The key navigation mechanism then retrieves the value KNI from the file header of the content file (block 252). When the key navigation mechanism opens a protected content file, it will be operating in the directory tree 130 of the unprotected user data area. For example, if the protected content file is one of song files such as song “mysong.MP3” in the player 1 directory, the access path to the content file is constructed according to the directory tree 130. The key navigation mechanism then performs the operations of blocks 212 through 222 in the manner described above, and stores certain decryption keys that are used to decrypt (and / or encrypt) the content file. The key file index or nnn of the title key file and the offset indicating the location of the key in the title key file are found. The key navigation mechanism further converts the access path to the public or unprotected user data area according to the directory tree 130 into an access path constructed according to the protected area directory tree 150, block 216. Based on 218 and 220, the complete key file name of the decryption key for the protected area is established. After the authentication process, the key navigation mechanism then opens the title key file in the protected area according to the constructed full key file name (block 222) and the content decryption key can be easily obtained and retrieved. Like that. The key navigation mechanism then checks whether the content file existed before the operation. In this example, it actually exists, so the mechanism proceeds to block 254 and retrieves the encrypted content encryption key from the key entry offset of the proper title key file (block 254). The content encryption key is then decrypted and used to decrypt / encrypt the content file that is or will be protected by encryption. (Block 256).

Using the key navigation file and title key file structure described above is particularly easy when deleting content files. This is illustrated in the flowchart of FIG. Thus, the key navigation mechanism used for this purpose may be a computer program stored and executed in either the host device 24 or the memory system 10 and is first deleted in the directory. The content file to be protected is identified (block 302). The content file may be in an unprotected public area of the memory 20. The key navigation mechanism then opens the content file, gets the KNI from the file header, and closes the file (block 304). The mechanism then opens the key navigation file in the same directory as the content file (block 306). For example, if the content file to be deleted is in the player 1 directory of the directory tree 130, for example, the bit offset is found in the key navigation file in the same directory as the content file (player 1 directory in this example). The key navigation mechanism then uses the KNI as an offset from the first entry in the key navigation file and the title key of the title key entry used to encrypt / decrypt the content file to be deleted. Find the location of the key file status bit indicating the status in the file. The mechanism then resets the key file status bit found at the offset location from 0 to 1, so that the corresponding title key entry (TKE) in the title key file for that file status bit is valid. An indication that no key is held (block 308). This therefore indicates that its corresponding TKE location in the title key file can now be used to store the new key and is substantially "empty". In fact, there is no need to go into the protected area (usually requiring authentication) and delete the key at that location in the title key file. The key navigation mechanism then closes the key navigation file and proceeds to delete the content file (blocks 310 and 312).

(Rights object management)
The system for managing keys described above is like a rule that stipulates that a content file can be accessed only a limited number of times, only before a specific expiration date, or only during a specific period of time. It is also used to manage other types of content protection information. In DRM, such rules are handled with a content encryption / decryption key that is used to protect content in an object known as a rights object. To determine how an encrypted content file may be used and / or accessed, first locate the rights object, extract the encryption / decryption key from it, and use it Extract rules governing The content file can then be decrypted / encrypted using the key to access the content. A content file may be downloaded or otherwise received, in which case it will be necessary to find its rights object. If the file is encrypted at download time, it may be necessary to purchase access rights, in which case the rights object will be supplied after purchase and can be downloaded. If the downloaded file is not encrypted, a rights object can be created to protect the content file. When the rights object is obtained, the key in the rights object is extracted from the rights object and the content file is encrypted or decrypted using the key. The file is then further processed as needed. In contrast, after a file is created, a rights object may be created for the file, in which case this object contains the key used for the encryption / decryption .

  If additional security is required, the decrypted content file may be re-encrypted using a different key than that in the rights object. In this manner, unauthorized users who also have access to the rights object of the content file will not be able to access such re-encrypted content files. Thus, the user who downloaded the content file is different from the one in the rights object obtained from the rights issuer, and the content file is decrypted using the key in the rights object obtained from the rights issuer. After that, the content file may be encrypted again to generate a key. The key in the rights object is then replaced with the key generated by the user. In the alternative, the user simply encrypts the content file using his generated key without first decrypting the content file, which makes the content file two different A key, i.e. a key by the rights issuer (i.e. the content file can be decrypted using the first key in the rights object) and can be generated by the user and used only by that user Encrypted by the second key. The user then stores this additional second key in the rights object as well.

  FIG. 8 is a flowchart illustrating a rights object (RO) navigation mechanism for rights object management. The RO navigation mechanism that performs the process of FIG. 8 may comprise computer program code stored and executed in the host device 24 that sends commands to the memory system in which the content file, the RO file, and the key navigation file are stored. . Alternatively, the mechanism may comprise computer program code stored in flash memory 20 that is loaded into CPU 12 and executed. Accordingly, the computer program used in the RO navigation mechanism of FIGS. 8 and 9 may be stored on a computer readable medium that is part of or connected to the host device 24, or Such a computer program may be stored in the flash memory 20 in which the RO file, the rights object navigation file, and the content file are stored. All such variations are within the scope of the present invention. Comparing one of FIGS. 6 and 7 with the other of FIGS. 8 and 9, they are very similar, and the RO management process of FIGS. 8 and 9 is similar to the key management process of FIGS. You can see that they are very similar.

  In such an event, an architecture and concept for RO management that is very similar to the key management described above may be used, for example, for labeling RO entries (ROE) across RO files, see FIG. RONI is used in the same way as illustrated (similar concept to KNI). The status bit ROS [i] in the RO navigation file is used to indicate whether the corresponding i-th RO is valid in one of the RO files. The RO navigation file is stored in the public section or region along with the content files in the directory tree directory in the same way that key management is involved, as shown in FIG. The RO file is stored in a protected partition or area within the directory tree directory in the same manner as in the key management shown in FIG. 5, and the two area trees are mirror images of each other ( Not shown).

  Referring to FIG. 8, the process of the mechanism of FIG. 8 begins when it is desired to open or download a protected content file (block 402). The RO navigation mechanism determines whether the content file has been downloaded (diamond 404). If the content file has not been downloaded, it means that the content file already exists and there is no need for downloading. Assuming that the content file has been downloaded and needs to be protected, the mechanism proceeds to block 406 and stores the file in the assigned directory of the public domain (similar to the public area of FIG. 4). The RO navigation mechanism checks whether the RO navigation file exists in the same directory (diamond 407a). If not, the mechanism creates an RO navigation file (block 407b). If so, the mechanism opens the RO navigation file found in the same directory as the downloaded content file, similar to that seen in FIG. 4 (block 408). In either case, the mechanism looks in the RO navigation file in the appropriate directory of the directory tree and finds the first RO entry that has an “empty” or “invalid” state. The “empty” or “invalid” state offset of the RO navigation file gives the RO navigation index (RONI) (blocks 408 and 410) and the above embodiment using ROIN is employed.

  When RO files and RO navigation files are used in the above embodiment, the locations or RO entries in the RO file are used in sequence. This means that when one RO needs to be created and stored in the RO file, the slot or location in the RO file is stored in the RO file RO_file. Meaning that it is used to store ROs in sequence starting from RO entry 1 in 000. After such an RO is stored and forms the first RO entry or part thereof, its corresponding RO file status bit ROS [1] value is changed from 1 to 0 and it is not empty and is now busy It is indicated that there is a valid RO now because it is not reserved for the header. Initially, the RO file status bits all have the value 1, except for the RO file status bits of 0, 128, 256..., Which have the value 0. However, it should be understood that instead of this embodiment, a look-up table may be used instead as in the case of a key navigation mechanism, and all such variations are within the scope of the present invention.

  Having obtained the RONI, the RO navigation mechanism then calculates the RO file index or nnn equal to the integer portion of the RONI / 128 if each of the RO files has 128 slots or locations (block 412). ). The nnn or RO file index is the integer part of the number RONI / 128. This nnn or RO file index value is a serial number of the RO file. The offset in the RO file is then obtained by calculating the value of RONI% 128 or RONI mod 128 (block 414).

  As pointed out above, the downloaded content file is assigned to a directory (such as a directory similar to the player 1 directory in the directory tree 130 of FIG. 4). To obtain a location in the protected area RO file to store the RO used to control the use and / or access to the content file that has just been downloaded. The navigation mechanism replaces the public partition name of the unprotected user data area with the protected partition name of the protected area in a manner similar to that of FIG. The access path constructed according to the directory tree within is converted to a path constructed according to the directory tree within the protected area or partition (block 416). The RO navigation mechanism then forms the RO file name, “RO_file.nnn” (block 418). The RO navigation mechanism then forms a complete RO filename (block 420). As an example, assuming that player x creates a new content file that is controlled by RO and will be created or downloaded, the complete RO file name where this RO will be stored is block 408, 410, 412, 414, 416, 418, and 420. In that case, the complete RO file name to be created is “prot_partition / playerxdirectory / RO_file.nnn”.

  Next, the RO navigation mechanism determines whether or not there is an RO file having this RO file name (diamond 421a). If this RO file does not exist, the mechanism creates one file and adds it to the appropriate directory (eg, player x) in the directory tree of the protected area or partition (block 421b). If this RO file exists, the mechanism opens the RO file using an access path based on the complete RO file name (block 422). The RO navigation mechanism then checks to see if the content file was downloaded at block 406, i.e., was not present (diamond 424). In the above example, since the content file has been downloaded, the RO navigation mechanism proceeds to block 426 and inserts the RONI into the file header of the downloaded file. Thus, RONI not only serves to associate each RO with the content file it controls, but also performs the functions described above for RO navigation and management.

  When the RO (including the key) is created by the encryption engine 40 or otherwise obtained (eg, downloaded after purchase), the key generated or obtained as described above is used and downloaded. The file is encrypted (428). The newly downloaded file that has been encrypted is added to the directory player x in the tree of public areas or partitions in the memory device 20. This RO is encrypted and inserted into the RO file identified at block 412 at the location indicated by the offset obtained at block 414 (block 430) and a directory of the protected partition or area tree. It is added as a new RO entry to Player x's RO file. The RO navigation mechanism then closes the RO file (block 432) and changes the value of its corresponding status bit in the RO navigation file of the player x directory of the tree in the open area from 1 to 0, but the RO file The status bit is located using the value of RONI as an offset in the RO navigation file of the player x directory of the tree in the open area. The RO navigation file is then closed (blocks 434 and 436).

  The above is the process of the RO navigation mechanism using two directory trees when the content file to be associated with the RO is first downloaded and encrypted (and / or decrypted). If it is desired to access an existing content file (ie, a file that has not been downloaded) and therefore the RO navigation mechanism is required to find the RO needed to access the content file, FIG. The RO navigation mechanism operates as follows. The RO navigation mechanism opens the protected content file in a particular directory, such as the player x directory in the open area, and proceeds to block 452 because the content file already exists. The RO navigation mechanism then retrieves the value RONI from the file header of the content file (block 452). When the RO navigation mechanism opens a protected content file, it will be operating in the directory tree of the unprotected user data area. For example, if the protected content file is one of the song files in the player x directory, the access path to the content file is constructed according to the directory tree. The RO navigation mechanism then performs the operations of blocks 412 to 422 in the manner described above to store the RO file index or nnn of a particular RO file in which the RO associated with the content file is stored. , Find the offset indicating the location of the RO in the RO file. The RO navigation mechanism further converts the access path to the public or unprotected user data area according to the directory tree in the public area into an access path constructed according to the directory tree in the protected area. , Based on blocks 416, 418, and 420, establish the complete RO filename for the decrypted RO in the protected area. After the authentication process, the RO navigation mechanism then opens the RO file in the protected area based on the constructed full RO file name (block 422) and the RO is readily available and can be retrieved. It can be so. The RO navigation mechanism then checks whether the content file existed before the operation. In this example, because it exists, the mechanism proceeds to block 454 and retrieves the encrypted RO from the RO entry with the correct RO file offset (block 254). The RO will then be decrypted and the content file will be decrypted / encrypted using the keys therein according to the rules of the RO (block 456).

  FIG. 9 is a flowchart illustrating an operation for deleting a file of the rights object navigation mechanism in order to explain further characteristics of the rights object management system. Using the RO navigation file and RO file structure described above makes it particularly easy to delete content files. This is illustrated in the flowchart of FIG. Thus, the RO navigation mechanism used for this purpose may be a computer program that is stored and executed either in the host device 24 or the memory system 10 and is first deleted in the directory. A content file to be protected is identified (block 502). The content file may be in an unprotected public area of the memory 20. The RO navigation mechanism then opens the content file, obtains the RONI from the file header, and closes the file (block 504). The mechanism then opens the RO navigation file in the same directory as the content file (block 506). For example, if the content file to be deleted is in the player x directory of the directory tree in the public area or partition, for example, the bit offset is the RO navigation file in the same directory (player x directory in this example) Is found in. The RO navigation mechanism then uses RONI as an offset from the first entry in the RO navigation file to indicate the state in the RO file of the RO entry associated with the content file to be deleted. Find the location of the RO file status bit. The mechanism then resets the RO file status bit found at the offset location from 0 to 1, so that the corresponding RO entry (ROE) in the RO file for that file status bit sets a valid RO. It is displayed that it is not owned (block 508). This therefore indicates that the location of that corresponding ROE in the RO file can now be used to store the new RO and is substantially “empty” or “not valid”. Yes. In fact, it is not necessary to go into the protected area (usually requiring authentication) and delete the RO at that location in the RO file. The RO navigation mechanism then closes the RO navigation file and proceeds to delete the content file (blocks 510 and 512).

  The present invention has been described above with reference to various embodiments. However, changes and modifications can be made without departing from the scope of the present invention, and the scope of the present invention is defined by the claims and the scope thereof. It should be understood that it is defined only by the equivalents. For example, a process similar to that of FIG. 6 finds a place in one file of the title key storage file to store the created decryption key and 1 of the title key storage file. It can also be applied to find an existing encryption key for encrypting an existing file within one file. The key or RO may be used to protect any content, including songs, movies, media titles such as games, and other types of content with or without a title. Navigation or location information may be stored in a portion of the content file that is different from the header, eg, the file name. All references referred to herein are incorporated by reference.

1 is a block diagram of a memory system in communication with a host device illustrating the present invention. It is a figure which illustrates the structure of a title key file. It is a figure which illustrates the structure of the key navigation file. FIG. 3B is a diagram showing the key navigation file of FIG. 3A and a plurality of title key files of the type shown in FIG. 2, and illustrating the relationship between them. FIG. 6 illustrates a directory tree of unprotected user data areas useful for key navigation and key management. FIG. 3 is a diagram of a protected area directory tree useful for key navigation and key management. It is the flowchart which illustrates the key navigation mechanism of key management. FIG. 6 is a flowchart illustrating a key navigation mechanism for deleting files to illustrate further characteristics of the key management system. FIG. 6 is a flowchart illustrating a rights object navigation mechanism for rights object management. FIG. 6 is a flowchart illustrating a rights object navigation mechanism for deleting files to illustrate further properties of a rights object management system. FIG.

Claims (101)

  A computer readable medium storing a computer program that facilitates management of a plurality of keys, the computer program creating a key navigation file and storing one or more key storage files Create if not already present, and each key storage file is or will be used to hold one or more keys in the corresponding location in that key storage file; Each of the keys is used or used for encryption and / or decryption of a corresponding one of a plurality of content files, and each content file includes a header portion, The location information of each header portion of the content file includes the key where the corresponding key is placed. One of the storage files and the corresponding location of the key in the key storage file, wherein the key navigation file has one valid key in the one or more key storage files Or a computer readable medium having state information indicating whether it is stored in a location beyond that.   The key navigation file and one or more key storage files are stored in a storage device, the device comprising at least one protected area and at least one unprotected area; The at least one protected area is accessible only to authorized users, and the computer program stores the one or more key storage files for storing encrypted keys. The medium of claim 1, wherein the medium is created in the at least one protected area if it does not already exist.   The medium of claim 2, wherein the computer program creates the key navigation file in the at least one unprotected area if it does not already exist.   The key navigation file includes entries, and each of the entries of the key navigation file is a location for storing one of a plurality of encryption / decryption keys in the one or more key storage files. The medium of claim 1, wherein the medium provides status information about whether a valid key is stored at the location.   The computer program provides, from the state information provided by the entry of the key navigation file, state information indicating one corresponding location of the key storage file in which no valid key is stored. The medium of claim 4, wherein:   The computer program generates a key for encrypting and / or decrypting one of the plurality of content files, and the generated key is generated by the found entry of one of the key storage files. 6. The medium of claim 5, wherein the medium is stored at the corresponding location shown and the location information is inserted into a header portion of the content file.   Each of the entries in the key navigation file corresponds to a different value of index i, and each of the index values includes state information of the corresponding location in the one or more key storage files. Associated with which the computer program will encrypt / decrypt the index i of the entry found in the key navigation file using the generated key. The medium of claim 6, wherein the medium is inserted into a header portion of a file.   The computer program uses up to N key storage files numbered from 1 to N, where N is an integer greater than 1, and m is a positive integer. Each has m locations for storing m keys, and the integer part of the numerical value i / m stores the corresponding key in the N key storage files. I mod m indicates the location of the corresponding key in the particular key storage file corresponding to the found entry, and 8. The medium of claim 7, wherein a computer program performs operations to find an integer part of the numerical value i / m and to find i mod m.   9. The computer program of claim 8, wherein the computer program finds the key storage file to be used to store the generated key from the N key storage files by the integer portion. Medium.   10. The medium of claim 9, wherein the computer program uses i mod m to find the corresponding location in the key storage file that will be used to store the generated key. .   The key navigation file has a plurality of bits, each bit indicating whether a valid key is stored in a corresponding location in the one or more key storage files. Item 10. The medium according to Item 1.   The computer program creates the key navigation file and creates the one or more key storage files in a storage device that is separate from the medium if it does not already exist. The medium of claim 1.   The computer program creates the key navigation file and creates the one or more key storage files in a storage device if they do not already exist, and the medium is one of the devices. The medium according to claim 1, wherein the medium is a part.   The computer program identifies the corresponding location in the key storage file that is used or will be used to store the key corresponding to each content file in the header portion of the content file. The medium of claim 1, wherein the medium is found using location information.   A non-volatile computer readable medium storing a key navigation mechanism, the mechanism comprising a key navigation file and at least one key storage file, each key storage file corresponding to a corresponding key storage file A plurality of keys in a location that is used to encrypt and / or decrypt a corresponding one of the plurality of content files, each content file comprising a header portion And the information of the header portion of each of the content files indicates one of the key storage files where the corresponding keys are located and the corresponding location of the key in the key storage file And the key navigation file is one or more of the at least one key storage file. It holds information indicating whether or not more locations holds a valid key, a non-volatile computer-readable media.   The medium of claim 15, wherein the medium comprises non-volatile flash memory cells in a memory card.   The medium comprises at least one protected area and at least one unprotected area, the protected area being accessible only to an authenticated user, and the at least one key The medium of claim 15, wherein a storage file is stored in the at least one protected area and the key navigation file is stored in the at least one unprotected area. A non-volatile computer-readable medium comprising at least one protected area and at least one unprotected area and storing a key navigation mechanism, the mechanism comprising:
A key navigation file and at least one key storage file, each key storage file having a plurality of encrypted keys at corresponding locations in the key storage file, each of said keys being a plurality of A key navigation file and at least one key storage file used for a corresponding encryption and / or decryption of a content file of
A first directory tree comprising a directory holding the list of the plurality of content files and the key navigation file of the at least one unprotected area of the medium;
A second directory comprising a directory holding a list of the keys in the at least one key storage file of the at least one protected area of the medium; and A non-volatile computer-readable medium in which two directory trees have structures that are mirror images of each other. A computer readable medium storing a computer program for decrypting / encrypting a content file using a decryption / encryption key in a key storage file of a protected area of a storage device, comprising: The content file has key navigation information indicating an access path to the decryption / encryption key for decrypting / encrypting the content file in the key storage file, and the computer program includes:
Extracting the key navigation information from the content file;
Deriving from the key navigation information where the decryption / encryption key is stored in the key storage file of the protected area of the storage device;
Obtaining the decryption / encryption key from the key storage file of the protected area of the storage medium using the derived location;
A computer readable medium for decrypting / encrypting the content file using the decryption / encryption key.   The computer program uses a plurality of key storage files each having m locations for storing keys, the key navigation information includes an index, and the computer program stores the index. Divide by m to obtain the quotient to obtain an integer equal to the integer part of the quotient and obtain an offset equal to the remainder of the quotient, so that any one of the plurality of key storage files is 20. The medium of claim 19, wherein the medium finds whether the decryption / encryption key is stored and where the decryption / encryption key is stored in the key storage file.   The integer indicates which one of the one or more key storage files stores the decryption / encryption key, and the offset is within the key storage file, 21. The medium of claim 20, indicating the location where a decryption / encryption key is stored.   The storage device includes an unprotected area, and the computer program further accesses an access path to a certain place in the unprotected area to the protected area. The medium of claim 19, wherein the medium is converted to an access path. The storage device
A first directory tree comprising a directory comprising a list of a plurality of content files and at least one key navigation file of the unprotected area of the medium;
A second directory tree comprising a directory comprising one or more key storage files of the at least one protected area of the medium, wherein the two directory trees are They have structures that are mirror images of each other,
The computer program uses the two directory trees to store the encryption / decryption key in the key storage file for an access path for accessing a location in the unprotected area. 23. The medium of claim 22, wherein the medium translates to the access path for accessing the location.   The medium of claim 19, wherein the medium is part of the storage device.   A computer-readable medium storing a computer program for facilitating management of a plurality of rights objects, the computer program creating a rights object navigation file and storing one or more rights object storage files Create, if it does not already exist, each rights object storage file is used or used to hold one or more rights objects in corresponding locations in that rights object storage file Each of the rights objects is used or used to control a corresponding one of a plurality of content files and / or access to the files, The content file has a header part The location information of each header portion of the content file includes one of the rights object storage file in which the corresponding rights object is located, and the corresponding location of the rights object in the rights object storage file. And the rights object navigation file contains state information indicating whether valid rights objects are stored in one or more locations in the one or more rights object storage files. A computer readable medium.   The rights object navigation file and one or more rights object storage files are stored in a storage device, the device comprising at least one protected area and at least one unprotected area. The at least one protected area is accessible only to authenticated users, and the computer program stores the one or more rights object stores for storing encrypted rights objects. 26. The medium of claim 25, wherein a file is created in the at least one protected area if it does not already exist.   27. The medium of claim 26, wherein the computer program creates the rights object navigation file in the at least one unprotected area if it does not already exist.   The rights object navigation file has entries, each of the entries of the rights object navigation file storing one of a plurality of rights objects in the one or more rights object storage files. 26. The medium of claim 25, wherein the medium provides status information about whether a valid rights object is stored at that location.   The computer program obtains status information indicating one corresponding location in the rights object storage file where no valid rights object is stored from the status information provided by the entry of the rights object navigation file. 30. The medium of claim 28, wherein an entry to provide is found.   The computer program generates a rights object for controlling use of and / or access to the plurality of content files, and the generated rights object is stored in one of the rights object storage files. 30. The medium of claim 29, storing at the corresponding location displayed by the found entry and inserting the location information into a header portion of the content file.   Each of the entries in the rights object navigation file corresponds to a different value of index i, and each of the index values is a status of the corresponding location in the one or more rights object storage files. Associated with the information, and the computer program controls the index i of the entry found in the rights object navigation file using the rights object generated. The medium of claim 30, wherein the medium is inserted into a header portion of a file.   The computer program uses up to N rights object storage files numbered 1 to N, where N is an integer greater than 1, and the N rights object storage files, where m is a positive integer. Each of the files has m locations for storing m rights objects, and the integer part of the number i / m corresponds to the corresponding one of the N rights object storage files. Indicates a particular one where a rights object is stored or will be stored, i mod m is the corresponding rights object in the particular rights object storage file corresponding to the found entry Where the computer program finds the integer part of the number i / m, and i mod m Calculating the execution to give, medium of claim 31.   The computer program finds the rights object storage file to be used to store the generated rights object from the N rights object storage files by the integer portion. The medium described in 1.   36. The computer program of claim 33, wherein the computer program uses i mod m to find the corresponding location in the rights object storage file that will be used to store the generated rights object. Medium.   The rights object navigation file has a plurality of bits, each bit indicating whether a valid rights object is stored at a corresponding location in the one or more rights object storage files. 26. The medium of claim 25.   The computer program creates the rights object navigation file and creates the one or more rights object storage files in a storage device separate from the medium if it does not already exist. 26. The medium of claim 25.   The computer program creates the rights object navigation file and creates the one or more rights object storage files in a storage device if they do not already exist, the medium 26. The medium of claim 25, wherein is a part of the storage device.   The computer program identifies the corresponding location used or to be used to store the rights object corresponding to each content file in the rights object storage file in the header portion of the content file. 26. The medium of claim 25, wherein the medium is found using the location information.   A non-volatile computer-readable medium storing a rights object navigation mechanism, the mechanism comprising a rights object navigation file and at least one rights object storage file, each rights object storage file having its rights object Holding a plurality of rights objects in corresponding locations in the storage file, said rights objects being used for a corresponding one of a plurality of content files and / or access to the file, The content file includes a header portion, and the information of each header portion of the content file includes one of the rights object storage file in which the corresponding rights object is placed, and the rights object storage file The rights object navigation file displays whether or not one or more locations in the at least one rights object storage file contain valid rights objects. A non-volatile computer-readable medium having information indicating the above.   40. The medium of claim 39, wherein the medium comprises non-volatile flash memory cells in a memory card.   The medium comprises at least one protected area and at least one unprotected area, the protected area being accessible only to authenticated users, and the at least one right 40. The medium of claim 39, wherein an object storage file is stored in the at least one protected area, and the rights object navigation file is stored in the at least one unprotected area. A non-volatile computer readable medium comprising at least one protected area and at least one unprotected area and storing a rights object navigation mechanism, the mechanism comprising:
A rights object navigation file and at least one rights object storage file, each rights object storage file having a plurality of encrypted rights objects at corresponding locations in the rights object storage file, Each of the objects includes a rights object navigation file and at least one rights object storage file that control a corresponding use and / or access to the plurality of content files,
A first directory tree comprising a directory holding the list of the plurality of content files and the rights object navigation file of the at least one unprotected area of the medium;
A second directory comprising a directory holding a list of rights objects in the at least one rights object storage file of the at least one protected area of the medium; and A non-volatile computer-readable medium in which two directory trees have a structure that is a mirror image of each other. A computer readable medium storing a computer program for controlling the use of and / or access to a content file using a rights object in a rights object storage file of a protected area of a storage device. The content file has rights object navigation information indicating an access path to the rights object for controlling use of the content file and / or access to the content file in the rights object storage file. And the computer program is
Retrieving the rights object navigation information from the content file;
Deriving from the rights object navigation information the location where the rights object is stored in the rights object storage file of the protected area of the storage device;
Using the derived location to obtain the rights object from the rights object storage file of the protected area of the storage medium;
A computer readable medium for using and / or accessing the content file according to the rights object.   The computer program uses a plurality of rights object storage files each having m locations for storing rights objects, the rights object navigation information includes an index, and the computer program includes: By dividing the index by m, obtaining a quotient, obtaining an integer equal to the integer portion of the quotient and obtaining an offset equal to the remainder portion of the quotient, the plurality of rights object storage files 44. The medium of claim 43, wherein one of the: finds the rights object and where in the rights object storage file the rights object is stored.   The integer indicates which one of the one or more rights object storage files stores the rights object, and the offset is the rights object in the rights object storage file. 45. The medium of claim 44, wherein the medium indicates the location where it is stored.   The storage device includes an unprotected area, and the computer program further accesses an access path to a certain location in the unprotected area to the protected area. 44. The medium of claim 43, wherein the medium is converted to an access path. The storage device
A first directory tree comprising a directory comprising a list of the plurality of content files and a rights object navigation file of the unprotected area of the medium;
A second directory tree comprising a directory comprising a first or more rights object storage files of the at least one protected area of the medium, the two directory trees Have structures that are mirror images of each other,
The computer program uses the two directory trees to store an access path for accessing a certain location in the unprotected area, in which the rights object is stored in the rights object storage file. 47. The medium of claim 46, wherein the medium is converted into an access path for accessing the location.   44. The medium of claim 43, wherein the medium is part of the storage device. A computer readable medium storing a computer program for invalidating an encryption / decryption key stored in a key storage file and used to encrypt / decrypt a content file. The content file uses the key navigation file that holds state information indicating whether the key stored in the key storage file is valid or not, and the location of the key in the key storage file. Including a header portion holding location information indicating the computer program,
Obtaining the key location information in the key file from the header portion of the content file;
Using the location information to locate the state information of the key in the key navigation file;
A computer readable medium that changes the status information of the key in the key navigation file to indicate that the key is invalid.   A plurality of key storage files are used to store keys for protecting one or more content files, and the key navigation file includes the keys stored in the plurality of key storage files. Status information indicating whether it is valid, and the location information further indicates which one of the key storage files contains the key to be invalidated. 50. The medium of claim 49.   The key navigation file and the key storage file are stored in a storage device, the device comprising at least one protected area and at least one unprotected area, the at least one protection And the key storage file is stored in the at least one protected area, so that the key in the key storage file is stored in the key storage file. 50. The medium of claim 49, displayed as invalid without accessing at least one protected area. A computer readable storing a computer program for invalidating a rights object stored in a rights object storage file and used to control the use and / or access to the content file The content file is a medium that uses the rights object navigation file having status information indicating whether or not the rights object stored in the rights object storage file is valid. A header portion holding location information indicating the location of the rights object in a storage file;
Obtaining the location information of the rights object in the rights object file from the header portion of the content file;
Using the location information to locate the status information of the rights object in the rights object navigation file;
A computer readable medium for changing the status information of the rights object in the rights object navigation file to indicate that the rights object is invalid.   A plurality of rights object storage files are used to store rights objects for protecting one or more content files, and the rights object navigation file is stored in the plurality of rights object storage files. State information indicating whether the rights object is valid or not, and the location information further holds which one of the rights object storage files contains the rights object to be invalidated. 54. The medium of claim 52, wherein the medium is displayed.   The rights object navigation file and the rights object storage file are stored in a storage device, the device comprising at least one protected area and at least one unprotected area, the at least one Since one protected area is accessible only to authorized users and the rights object storage file is stored in the at least one protected area, the rights object storage file 53. The medium of claim 52, wherein a rights object is displayed as invalid without accessing the at least one protected area. A method for encrypting / decrypting a content file using a key navigation file and one or more key storage files, wherein each of the entries in the key navigation file is the one or Corresponds to a location for storing one of a plurality of encryption / decryption keys in a further key storage file;
Opening the key navigation file;
Finding an entry in the key navigation file that does not correspond to a valid key location in the one or more key storage files;
Generating an encryption / decryption key;
Encrypting / decrypting the content file using the encryption / decryption key;
Storing the encryption / decryption key in one of the key storage files at the location corresponding to the entry.   56. The method of claim 55, further comprising obtaining key navigation information for the content file from the location of the entry in the key navigation file.   The method uses a plurality of key storage files each having m entries, and the key navigation information comprises an index having a different value for each entry in the key navigation file, The method further includes finding a location in the one or more key storage files corresponding to the entry for storing the encryption / decryption key, the finding step comprising: 57. The method of claim 56, comprising: dividing m by m to obtain a quotient to obtain an integer equal to the integer portion of the quotient and an offset equal to a remainder portion of the quotient.   The integer indicates in which one or more of the one or more key storage files the encryption / decryption key will be stored by the storing step, and the offset is 58. The method of claim 57, wherein the encryption / decryption key in a key storage file indicates the location where the storing step will store it.   58. The method of claim 57, further comprising inserting the index into a header of the encrypted / decrypted content file.   56. The method of claim 55, further comprising modifying the entry in the key navigation file so that it corresponds to a valid key in the at least one key storage file. The key navigation file and the one or more key storage files are stored on a storage medium, the medium comprising at least one protected area and at least one unprotected area. The at least one protected area is accessible only to authorized users and the one or more key storage files are stored in the at least one protected area 56. The method of claim 55, wherein the storing step stores the encryption / decryption key in the at least one protected area.
  56. The method of claim 55, further comprising establishing an access path to the one key storage file holding the location corresponding to the entry for storing the encryption / decryption key. the method of.   The method of claim 62, wherein the building includes forming a key file name from the key navigation information.   The key navigation file and the one or more key storage files are stored on a storage medium, the medium comprising at least one protected area and at least one unprotected area. The protected area is accessible only to authorized users, and the one or more key storage files are stored in the at least one protected area and are constructed 64. The method of claim 63, wherein the step further comprises deriving an access path from the file name to the one key storage file of the at least one protected area.   The medium comprises at least one protected area and at least one unprotected area, and the building step comprises an access path to a location within the at least one unprotected area 64. The method of claim 62, wherein the method converts an access path to access the at least one protected area. The medium is
A first directory tree comprising a directory comprising the list of the plurality of content files and the key navigation file of the at least one unprotected area of the medium;
A second directory tree comprising a directory comprising the one or more key storage files of the at least one protected area of the medium, the two directory trees Are mirror images of each other,
In the converting step, using the two directory trees, an access path for accessing a certain place in the unprotected area is set in the one key storage file of the protected area. 66. The method of claim 65, wherein the method converts to an access path for accessing the location. A method for decrypting / encrypting a content file using a decryption / encryption key in a key storage file of a protected area of a storage medium, wherein the content file is the key storage file The key navigation information indicating the location of the decryption / encryption key for decrypting / encrypting the content file,
Retrieving the key navigation information from the content file;
Deriving from the key navigation information a location in the key storage file of the protected area of the storage device where the encryption / decryption key is stored;
Obtaining the encryption / decryption key from the key storage file of the protected area of the storage medium using the derived location;
Encrypting / decrypting the content file using the encryption / decryption key.   The method uses a plurality of key storage files each having m locations for storing keys, the key navigation information comprises an index, and the method includes the index in m By dividing and obtaining the quotient, obtaining an integer equal to the integer part of the quotient and obtaining an offset equal to the remainder part of the quotient, any one of the plurality of key storage files is the encrypted file. 68. The method of claim 67, further comprising: finding a decryption / encryption key and the location in the key storage file where the decryption / encryption key is stored. Method.   The integer indicates which one of the one or more key storage files stores the decryption / encryption key, and the offset is the encryption in the key storage file. 69. The method of claim 68, wherein the location where a decryption / encryption key is stored is indicated.   The medium includes an unprotected area, and in the deriving step, an access path to a certain place in the unprotected area is changed to an access path for accessing the protected area. 68. The method of claim 67, wherein the conversion is performed. The medium is
A first directory tree comprising a directory comprising a list of the plurality of content files and at least one key navigation file of the unprotected area of the medium;
A second directory tree comprising a directory comprising one or more key storage files of the at least one protected area of the medium, wherein the two directory trees are Have structures that are mirror images of each other,
The converting step uses the two directory trees to store an access path for accessing a location in the unprotected area by the decryption / encryption in the key storage file. 71. The method of claim 70, wherein the method translates to the access path for accessing the location being accessed. A method for encrypting / decrypting a content file, comprising:
If the key navigation file does not exist, create the file,
If at least one key storage file does not exist, creating at least one of the files, wherein each of the entries in the key navigation file includes a plurality of entries in the at least one key storage file; Creating a key storage file corresponding to a location for storing one of the encryption / decryption keys of
Finding an entry in the key navigation file that does not correspond to a valid key in the at least one key storage file;
Obtaining key navigation information of the content file from the location of the entry in the key navigation file;
Generating an encryption / decryption key;
Using the encryption / decryption key to encrypt / decrypt the content file;
Storing the encryption / decryption key in a location in the at least one key storage file corresponding to the entry. A method for controlling the use of and / or access to a content file using a rights object navigation file and one or more rights object storage files, the entries in the rights object navigation file Each corresponds to a location for storing one of a plurality of rights objects in the one or more rights object storage files;
Opening the rights object navigation file;
Finding an entry in the rights object navigation file that does not correspond to a valid rights object location in the one or more rights object storage files;
Obtaining a rights object;
Controlling the use of and / or access to the content file according to the rights object;
Storing the rights object at a location corresponding to the entry in the rights object storage file.   74. The method of claim 73, wherein the method further comprises obtaining rights object navigation information of the content file from a location of the entry in the rights object navigation file.   The method uses a plurality of rights object storage files each having m entries, and the rights object navigation information includes an index having a different value for each entry in the rights object navigation file. The method further comprises locating the location corresponding to the entry for storing the rights object in the one or more rights object storage files, wherein the finding step comprises the index. 75. The method of claim 74, comprising: dividing m by m to obtain a quotient to obtain an integer equal to the integer portion of the quotient and an offset equal to a remainder portion of the quotient.   The integer indicates in which one or more of the rights object storage files the rights object will be stored by the storing step, and the offset is the rights 76. The method of claim 75, wherein the rights object in the object storage file indicates the location where the storing step is to be stored.   76. The method of claim 75, further comprising inserting the index into a header of the content file.   74. The method of claim 73, further comprising modifying the entry in the rights object navigation file so that it corresponds to a valid rights object in the at least one rights object storage file.   The rights object navigation file and the one or more rights object storage files are stored on a storage medium, the medium comprising at least one protected area and at least one unprotected area. The at least one protected area is accessible only to authorized users, and the one or more rights object storage files are stored in the at least one protected area. 74. The method of claim 73, wherein the storing step stores the rights object in the at least one protected area.   74. The method of claim 73, further comprising building an access path to the one rights object storage file that holds the location corresponding to the entry for storing the rights object.   81. The method of claim 80, wherein the building comprises forming a rights object file name from the rights object navigation information.   The rights object navigation file and the one or more rights object storage files are stored in a storage medium, the medium comprising at least one protected area and at least one unprotected area. The protected area is accessible only to authorized users, and the one or more rights object storage files are stored in the at least one protected area. 83. The method of claim 81, wherein the building further comprises deriving an access path from the file name to the one rights object storage file of the at least one protected area.   The medium comprises at least one protected area and at least one unprotected area, and the building step comprises an access path to a location within the at least one unprotected area 81. The method of claim 80, wherein the method is converted to an access path for accessing the at least one protected area. The medium is
A first directory tree comprising a directory comprising the list of the plurality of content files and the rights object navigation file of the at least one unprotected area of the medium;
A second directory tree comprising a directory comprising the one or more rights object storage files of at least one protected area of the medium, the two directory trees Are mirror images of each other,
In the converting step, an access path for accessing a location in the unprotected area using the two directory trees is stored in the one rights object storage file in the protected area. 84. The method of claim 83, wherein the method translates to an access path for accessing the location.   74. The method of claim 73, wherein the obtaining comprises creating the rights object.   The method of claim 73, wherein the obtaining includes downloading the rights object.   87. The method of claim 86, further comprising generating a key and encrypting the content file using the generated key.   88. The method of claim 87, further comprising decrypting the content file using a key from the rights object, wherein the encrypting step occurs after the decrypting step.   88. The method of claim 87, further comprising replacing a key in the rights object with the generated key.   88. The method of claim 87, wherein the encrypting step encrypts the content file that has already been encrypted using a key in the rights object.   The method of claim 90, further comprising storing the generated key in the rights object. A method for controlling the use and / or access of a content file using a rights object in a rights object storage file of a protected area of a storage medium, the content file comprising: Possessing rights object navigation information indicating the location of the rights object for controlling use of and / or access to the content file in the rights object storage file;
Retrieving the rights object navigation information from the content file;
Deriving from the rights object navigation information the location where the rights object is stored in the rights object storage file of the protected area of the storage device;
Obtaining the rights object from the rights object storage file of the protected area of the storage medium using the derived location;
Controlling the use of and / or access to the content file according to the rights object.   The method uses a plurality of rights object storage files each having m locations for storing rights objects, and the rights object navigation information comprises an index, and the method comprises the index Divide m by m to obtain a quotient to obtain an integer equal to the integer part of the quotient and an offset equal to the remainder of the quotient, so that any one of the plurality of rights object storage files 94. The method of claim 92, further comprising: finding a rights object and where in the rights object storage file the rights object is stored.   The integer indicates which one of the one or more rights object storage files stores the rights object, and the offset is stored by the rights object in the rights object storage file. 94. The method of claim 93, wherein the location is indicated.   The medium includes an unprotected area, and the deriving step further includes an access path to a location in the unprotected area for accessing the protected area. 94. The method of claim 92, wherein the method converts to a path. The medium is
A first directory tree comprising a directory comprising a list of the plurality of content files and a rights object navigation file of the unprotected area of the medium;
A second directory tree comprising a directory comprising one or more rights object storage files of the at least one protected area of the medium, the two directory trees Have structures that are mirror images of each other,
In the converting step, the rights object in the rights object storage file is stored in an access path for accessing a location in the unprotected area using the two directory trees. 96. The method of claim 95, wherein the method translates to the access path for accessing the location. A method for controlling use of and / or access to a content file comprising:
Creating a rights object navigation file if it does not exist;
Creating at least one rights object storage file if it does not exist, each of the entries in the rights object navigation file comprising a plurality of entries in the at least one authority object storage file; Creating a rights object storage file corresponding to a location for storing one of the rights objects;
Finding an entry in the rights object navigation file that does not correspond to a valid rights object in the at least one rights object storage file;
Obtaining rights object navigation information of the content file from the location of the entry in the rights object navigation file;
Creating a rights object;
Controlling the use of and / or access to the content file according to the rights object;
Storing the rights object in a location in the at least one rights object storage file corresponding to the entry. A method for invalidating an encryption / decryption key stored in a key storage file and used to encrypt / decrypt a content file, wherein the content file is the key storage file Using a key navigation file that holds state information indicating whether or not the key stored in the key is valid, holding location information indicating the location of the key in the key storage file With a header part that
Obtaining the key location information in the key file from the header portion of the content file;
Using the location information to locate the state information of the key in the key navigation file;
Changing the status information of the key in the key navigation file to indicate that the key is invalid.   The key navigation file and the key storage file are stored in a storage device, the device comprising at least one protected area and at least one unprotected area, the at least one protection The authenticated area is accessible only to authorized users, and the key storage file is stored in the at least one protected area, so that the at least one protected area is accessed. 99. The method of claim 98, wherein, without doing so, the key in the key storage file is displayed as invalid. Use of a content object that is stored in a rights object storage file and comprises a header portion that holds location information indicating the location of the rights object in the rights object storage file and / or Rights object navigation that holds status information indicating whether or not the rights object stored in the rights object storage file is valid as a rights object used to control access to the file In a way to invalidate using a file,
Obtaining location information of the rights object in the rights object file from the header portion of the content file;
Using the location information to find the position of the state information of the rights object in the rights object navigation file;
Changing the status information of the rights object in the rights object navigation file to indicate that the rights object is invalid.   The rights object navigation file and the rights object storage file are stored in a storage device, the device comprising at least one protected area and at least one unprotected area, the at least one The one protected area is accessible only to authorized users and the rights object storage file is stored in the at least one protected area, so the at least one protected area 101. The method of claim 100, wherein without accessing an area, the rights object in the rights object storage file is displayed as invalid.

Images