Classifications

• • G—PHYSICS
  • G06—COMPUTING; CALCULATING OR COUNTING
  • G06F—ELECTRIC DIGITAL DATA PROCESSING
  • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
• • G—PHYSICS
  • G06—COMPUTING; CALCULATING OR COUNTING
  • G06F—ELECTRIC DIGITAL DATA PROCESSING
  • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
  • G06F21/70—Protecting specific internal or peripheral components, in which the protection of a component leads to protection of the entire computer
  • G06F21/78—Protecting specific internal or peripheral components, in which the protection of a component leads to protection of the entire computer to assure secure storage of data
• • G—PHYSICS
  • G06—COMPUTING; CALCULATING OR COUNTING
  • G06F—ELECTRIC DIGITAL DATA PROCESSING
  • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
  • G06F21/10—Protecting distributed programs or content, e.g. vending or licensing of copyrighted material ; Digital rights management [DRM]

Definitions

• This invention relates in general to encryption/decryption systems, and in particular a system for managing keys used for encryption and/or decryption and/or rights objects that control use of or access to content.
• Media content such as music, video and games is distributed increasingly as digital files.
• digital content has been distributed widely through a number of channels, including the internet and the use of storage devices.
• the digital content may be stored in a number of different types of devices, such as magnetic or optical disks, tapes, and non-volatile memories such as flash memories.
• the digital content in these storage devices can be played, stored and operated by a wide variety of devices such as personal computers of both the desk top and portable types, iPods and other types of embedded or stand alone media players, personal digital assistants ("PDA”), game controllers, MP3 players, and cellular phone handsets (referred to collectively herein as "host devices").
• DRM digital rights management
• a number of key management systems have been used.
• the content file is named so as to make it easier to identify and locate the encryption and/or decryption key.
• the encrypting file system (“EFS")
• EFS encrypting file system
• the key used for encrypting the file is itself encrypted and the encrypted key is stored in the header of the corresponding encrypted content file.
• each content file may be associated with rules regarding or controlling how the content file can be accessed and/or used.
• rules are referred to as rights objects in DRM.
• the rules may specify that the content file may only be accessed for a limited number of times, before certain expiration dates or only for certain time durations.
• a rights object is created, which may contain the above described rules as well as content encryption/decryption keys that are used for encrypting/decrypting a content file.
• the rights object is then also associated with the content file controlled by the rights object.
• the rights objects control use of and/or access to the content files by controlling access to content encryption/decryption keys that are used to encrypt/decrypt the content files.
• the rights objects in order to be able to use and/or access a protected content file, one would first retrieve or otherwise obtain the rights object associated with it, decipher the rules in the rights object, and then use or access the content file in accordance with the rules.
• the key(s) are retrieved from the associated rights object and used to decrypt the file before the content therein can be used or accessed.
• a rights object is created with rules governing use and/or access to the file and with any encryption/decryption keys that are used to encrypt/decrypt the content file, which object is associated with such content file.
• a key navigation file and one or more key storage files may be used to facilitate key management.
• the content files that are to be encrypted and/or decrypted each comprises a header portion containing location information which indicates which key storage file contains the key that is to be used for encrypting and/or decrypting the content file.
• the key navigation file contains status information that indicates whether a valid key is stored at one or more locations in the one or more key storage files. This facilitates a process of locating a location in the one or more key storage files for storing a key.
• the status information indicates one or more locations in the one or more key storage files at which one or more valid key(s) are not stored.
• a key navigation mechanism comprising the above described key navigation file and one or more key storage files may be stored in a non-volatile computer readable medium.
• the key navigation file is stored in the public unprotected area of a storage medium and the one or more key storage files for storing the keys are stored in a protected area of the medium which can be accessed only by authenticated users, applications or devices.
• the one or more key storage files are stored in the protected area not accessible to unauthorized access.
• the key navigation file and the one or more key storage files can be readily used in a process for encrypting/decrypting a content file.
• Each of the entries in the key navigation file corresponds to a location in the one or more key storage files for storing one of a plurality of encryption/decryption keys.
• the key navigation file may be opened to permit the finding of an entry therein which does not correspond to a valid key at a location in the 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 at the location in the one key storage file corresponding to the entry in the key navigation file that has been found.
• key navigation information may be derived from the location of the entry in the key navigation file found to not correspond to a valid key and this location information is inserted in the header portion of the encrypted file.
• this location information is inserted in the header portion of the encrypted file.
• the content file may be decrypted using a decryption key in a key storage file in a protected area of a storage medium.
• the header portion of the content file contains key navigation information that indicates location of the encryption/decryption key in the key storage file for /decrypting the content file.
• the key navigation information is retrieved from the header portion of the content file and the location in the key storage file at which the decryption key is stored is then derived from the key navigation information.
• the decryption key is then obtained from the protected area and used for decrypting the content file. This process can also be used to find a particular key in a key storage file for encrypting a content file, where the location information of such key can be found in the header of the content file.
• a plurality of key storage files are used for storing keys.
• the key navigation information in the header portion of the content file comprises an index, which can be an integer.
• Each of the key storage files contains m locations for storing keys.
• the index is divided by m to obtain a quotient.
• the integer portion of the quotient indicates which one of the plurality of key storage files stores the decryption/encryption key and the remainder portion, also called an offset herein, indicates the location in such key storage file at which the decryption/encryption key is stored.
• Yet another embodiment of the invention is directed to a method for invalidating an encryption/decryption key stored in a key storage file and used for encrypting/decrypting a content file by means of a key navigation file containing status information that indicates whether the key stored in the key storage file is valid or not.
• the content file comprises a header portion containing location information which indicates the location of the key in the key storage file. Location information of the key in the key file is obtained from the header portion of the content file. The status information of the key in the key navigation file is located using the location information.
• Any one of the methods described above may be performed by a computer program executed by a processor, where the program is stored in a computer readable storage medium.
• a computer program stored in a computer readable medium may be used to facilitate key management.
• the computer program creates a key navigation file and one or more key storage files when one or more of such files do not already exist.
• Each content file comprises a header portion containing location information indicating which key storage file contains the encryption/decryption key for such content file.
• the key navigation file contains status information that indicates whether one or more locations in the one or more key storage files contain a valid key or not.
• an entry is found in the key navigation file which does not correspond to a valid key in the at least one key storage file.
• Key navigation information for the content file is obtained from location of said 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 at a location in the at least one key storage file corresponding to the entry.
• a computer program stored a computer readable medium encrypts/decrypts a content file using an encryption/ decryption key in a key storage file in a protected area of the storage device.
• the content file header contains key navigation information that indicates the location of the encryption/decryption key in the key storage file.
• the computer program retrieves the key navigation information from the content file, derives from the key navigation information the location in the key storage file at which the encryption/decryption key is stored, obtains the encryption/decryption key and encrypts/decrypts the content file using such key.
• a plurality of key storage files each containing m locations are used for storing keys.
• the key navigation information comprises an index, which can be an integer
• the computer program finds which one of the key storage files stores the decryption/encryption key and the location in such key storage file at which the key is stored by dividing the index by m to obtain a quotient.
• the integer portion of the quotient indicates which one of the plurality of key storage files stores the decryption/encryption key and the remainder portion, also called an offset herein, indicates the location in such key storage file at which the decryption/encryption key is stored.
• a non-volatile computer readable medium stores a key navigation mechanism, where the medium comprises at least one protected area and at least one unprotected area.
• the mechanism comprises a key navigation file and at least one key storage file.
• Each key storage file contains a plurality of keys at corresponding locations in such key storage file, said keys used for encryption and/or decryption of a corresponding one of a plurality of content files.
• the mechanism includes a first directory tree in the at least one unprotected area of the medium, said first directory tree comprising a directory that contains a list of the plurality of content files and the key navigation file.
• the mechanism includes also a second directory tree in the at least one protected area of the medium, said second directory tree comprising a directory that contains a list of the keys in the at least one key storage file, said two directory trees having structures that mirror each other.
• the above described systems and methods may also be adapted for managing content protection information, such as the rules governing access to and/or use of content, instead of or in addition to managing keys.
• content protection information such as the rules governing access to and/or use of content
• the above described systems and methods may be adapted for managing rights objects that control use of and/or access to content files.
• a rights object navigation file and one or more rights object storage files may be used to facilitate rights object management.
• the content files that are to be controlled by means of the rights objects each comprises a header portion containing location information which indicates which rights object storage file contains the rights object that is to be used for controlling use of and/or access to the content file.
• the rights object navigation file contains status information that indicates whether a valid rights object is stored at one or more locations in the one or more rights object storage files. This facilitates a process of locating a location in the one or more rights object storage files for storing a rights object key.
• the status information indicates one or more locations in the one or more rights object storage files at which one or more valid key(s) are not stored.
• a rights object navigation mechanism comprising the above described rights object navigation file and one or more rights object storage files may be stored in a non- volatile computer readable medium.
• the rights object navigation file is stored in the public unprotected area of a storage medium and the one or more rights object storage files for storing the rights objects are stored in a protected area of the medium which can be accessed only by authenticated users, applications or devices.
• the one or more rights object storage files are stored in the protected area not accessible to unauthorized access.
• the rights object navigation file and the one or more rights object storage files can be readily used in a process for associating a rights object with a content file.
• Each of the entries in the rights object navigation file corresponds to a location in the one or more rights object storage files for storing one of a plurality of rights objects.
• the rights object navigation file may be opened to permit the finding of an entry therein which does not correspond to a valid rights object at a location in the one or more rights object storage files.
• a rights object is generated and the content file is associated with it.
• the rights object is then stored at the location in the one rights object storage file corresponding to the entry in the rights object navigation file that has been found.
• rights object navigation information may be derived from the location of the entry in the rights object navigation file found to not correspond to a valid rights object and this location information is inserted in the header portion of the encrypted file.
• this location information is inserted in the header portion of the encrypted file.
• the content file may be encrypted/decrypted using a encryption/decryption rights object in a rights object storage file in a protected area of a storage medium.
• the header portion of the content file contains rights object navigation information that indicates location of the rights object in the rights object storage file associated with the content file.
• the rights object navigation information is retrieved from the header portion of the content file and the location in the rights object storage file at which the rights object is stored is then derived from the rights object navigation information.
• the rights object is then obtained from the protected area and used for accessing and/or otherwise for using the content file.
• 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 a content file is desired, where the location information of such rights object can be found in the header of the content file.
• a plurality of rights object storage files are used for storing rights objects.
• the rights object navigation information in the header portion of the content file comprises an index, which can be an integer.
• Each of the rights object storage files contains m locations for storing rights objects.
• the index is divided by m to obtain a quotient.
• the integer portion of the quotient indicates which one of the plurality of rights object storage files stores the rights object and the remainder portion, also called an offset herein, indicates the location in such rights object storage file at which the rights object is stored.
• Yet another embodiment of the invention is directed to a method for invalidating a rights object stored in a rights object storage file and used for controlling use of and/or access to a content file by means of a rights object navigation file containing status information that indicates whether the rights object stored in the rights object storage file is valid or not.
• the content file comprises a header portion containing location information which indicates the location of the rights object in the rights object storage file. 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 located using the location information.
• the status information of the rights object in the rights object navigation file is altered to indicate that the rights object is invalid.
• a computer program stored in a computer readable medium may be used to facilitate rights object management.
• the computer program creates a rights object navigation file and one or more rights object storage files when one or more of such files do not already exist.
• Each content file comprises a header portion containing location information indicating which rights object storage file contains the rights object for such content file.
• the rights object navigation file contains status information that indicates whether one or more locations in the one or more rights object storage files contain a valid rights object or not.
• an entry is found in the rights object navigation file which does not correspond to a valid rights object in the at least one rights object storage file.
• Rights object navigation information for the content file is obtained from location of said entry in the rights object navigation file.
• a rights object is generated and is associated with the content file.
• the rights object is stored at a location in the at least one rights object storage file corresponding to the entry.
• a computer program stored in a computer readable medium controls use of and/or access to a content file by means of a rights object in a rights object storage file in a protected area of the storage device.
• the content file header contains rights object navigation information that indicates the location of the rights object in the rights object storage file.
• the computer program retrieves the rights object navigation information from the content file, derives from the rights object navigation information the location in the rights object storage file at which the rights object is stored, obtains the rights object and uses or accesses the content file by means of such rights object.
• a plurality of rights object storage files each containing m locations are used for storing rights objects.
• the rights object navigation information comprises an index, which can be an integer, and the computer program finds which one of the rights object storage files stores the rights object and the location in such rights object storage file at which the rights object is stored by dividing the index by m to obtain a quotient.
• the integer portion of the quotient indicates which one of the plurality of rights object storage files stores the rights object and the remainder portion, also called an offset herein, indicates the location in such rights object storage file at which the rights object is stored.
• a non-volatile computer readable medium stores a rights object navigation mechanism, where the medium comprises at least one protected area and at least one unprotected area.
• the mechanism comprises a rights object navigation file and at least one rights object storage file.
• Each rights object storage file contains a plurality of rights objects at corresponding locations in such rights object storage file, said rights objects used for controlling use of and/or access to a corresponding one of a plurality of content files.
• the mechanism includes a first directory tree in the at least one unprotected area of the medium, said first directory tree comprising a directory that contains a list of the plurality of content files and the rights object navigation file.
• the mechanism includes also a second directory tree in the at least one protected area of the medium, said second directory tree comprising a directory that contains a list of the rights objects in the at least one rights object storage file, said two directory trees having structures that mirror each other.
• Fig. 1 is a block diagram of a memory system in communication with a host device to illustrate the invention.
• Fig. 2 is a diagram illustrating the structure of a title key file.
• Fig. 3 A is a diagram illustrating the structure of a key navigation file.
• Fig. 3B is a diagram showing the key navigation file in Fig. 3A and a number of title key files of the type shown in Fig. 2, to illustrate the relationship between them.
• Fig. 4 is a diagram illustrating a directory tree in an unprotected user data area useful for key navigation and key management.
• Fig. 5 is a diagram of a directory tree in the protected area useful for key navigation and key management.
• Fig. 6 is a flow chart illustrating a key navigation mechanism for key management.
• Fig. 7 is a flow chart illustrating a key navigation mechanism for deleting a file to illustrate a further feature of a key management system.
• Fig. 8 is a flow chart illustrating a rights object navigation mechanism for rights object management.
• Fig. 9 is a flow chart illustrating a rights object navigation mechanism for deleting a file to illustrate a further feature of a rights object management system.
• the memory system 10 includes a central processing unit (CPU) 12, a buffer management unit (BMU) 14, a host interface module (HIM) 16 and a flash interface module (FIM) 18, a flash memory 20 and a peripheral access module (PAM) 22.
• Memory system 10 communicates with a host device 24 through a host interface bus 26 and port 26a.
• the flash memory 20 which may be of the NAND type, provides data storage for the host device 24.
• the software code for CPU 12 may also be stored in flash memory 20.
• FIM 18 connects to the flash memory 20 through a flash interface bus 28 and port 28a.
• HIM 16 is suitable for connection to a host system like a digital camera, desk top or portable personal computer, personal digital assistant (PDA), digital media player, MP-3 player, video game players and cellular telephone or other digital devices.
• PDA personal digital assistant
• the peripheral access module 22 selects the appropriate controller module such as FIM, HIM and BMU for communication with the CPU 12.
• controller module such as FIM, HIM and BMU for communication with the CPU 12.
• all of the components of system 10 within the dotted line box may be enclosed in a single unit such as in memory card or stick 10' and preferably encapsulated in the card or stick within the same housing or container.
• 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 crypto-engine 40.
• the arbiter 36 is a shared bus arbiter so that only one master or initiator (which can be HDMA 32, FDMA 34 or CPU 12) can be active at any time and the slave or target is BRAM 38.
• the arbiter is responsible for channeling the appropriate initiator request to the BRAM 38.
• the HDMA 32 and FDMA 34 are responsible for data transported between the HIM 16, FIM 18 and BRAM 38 or the CPU random access memory (CPU RAM) 12a.
• the operation of the HDMA 32 and of the FDMA 34 is conventional and need not be described in detail herein.
• the BRAM 38 is used to buffer data passed between the host device 24, flash memory 20 and the CPU RAM 12a.
• the HDMA 32 and FDMA 34 are responsible for transferring the data between HIM 16/FIM 18 and BRAM 38 or the CPU RAM 12a and for indicating sector transfer completion.
• the data from memory 20 may be decrypted and encrypted again by crypto engine 40 before it is sent to BRAM 38.
• the encrypted data in BRAM 38 is then sent to host device 24 as before. This illustrates the data stream during a reading process.
• the direction of the data stream is reversed. For example if unencrypted data is sent by host device, through bus 26, HIM 16, HDMA 32 to the crypto engine 40, such data may be encrypted by engine 40 before it is stored in BRAM 38. Alternatively, unencrypted data may be stored in BRAM 38.
• the data is then encrypted before it is sent to FDMA 34 on its way to memory 20.
• engine 40 completes such processing before the processed data is stored in BRAM 38.
• the memory system 10 in Fig. 1 contains a flash memory
• the system may alternatively contain another type of non-volatile memory instead, such as magnetic disks, optical CDs, as well as all other types of rewrite-able non volatile memory systems, and the various advantages described above will equally apply to such alternative embodiment.
• the memory is also preferably encapsulated within the same physical body (such as a memory card or stick) along with the remaining components of the memory system.
• Fig. 2 is a schematic diagram showing the structure of a title key file to illustrate one embodiment of the invention.
• the title key file 102 is designed with 127 slots or locations for containing up to 127 keys.
• file 102 contains a total of 128 slots or locations, where the very first slot or location 102a is reserved for a header and is not used for storing keys. Initially, the 127 slots or locations may contain all l 's or O's, or arbitrary values, which are not valid key values.
• valid title key entries are written consecutively to the 127 slots or locations by overwriting the initial values, so that when all 127 slots or locations are filled with valid key values, they contain the following values: TKEl, TKE2, ... TKE127.
• TKE valid title key entries
• whether a particular title key entry is a valid key or not is indicated by a title key status bit stored in a key navigation file illustrated in Fig. 3A.
• a title key status bit of any particular title key entry in file 102 it is possible to determine whether such entry consists of or contains a valid key or not, without having to actually access the title key file 102.
• Fig. 3A is a schematic view of a key navigation file to illustrate its structure.
• the key navigation file 104 includes a large number of key file status ("KFS") fields: KFSOOO, KFSOOl, ... KFS031, KFS032, KFS033 ... KFS063
• KFS key file status
• Each of the title key status fields contains the title key status bits of the corresponding title key file.
• the key file status field 104a titled KFSOOO contains the 127 title key status bits of the 127 title key entries in title key file 102, so that file 104a needs 16 bytes of storage.
• Fig. 3A illustrates a situation where at least 64 title key files have been created, so that the key navigation file 104 includes at least 64 title key status fields, from KFSOOO to KFS063. The relationship between the key navigation file 104 and the title key files is illustrated in more detail in Fig. 3B.
• the title key files are given the name in the format "key file.xxx," where xxx is the serial number of the title key file.
• the first created key file 102 is given the file name key file.OOO and the next created key file is assigned the name key file.OOl and so on.
• each slot or location and the entry therein in the key navigation file 104 has a known one-to-one correspondence relationship with a particular slot or location in one of the title key files, and the title key entry at such slot or location. In this manner, in order to check whether a particular title key entry contains a valid key or not, it would be necessary only to find the location or slot in the key navigation file 104 that corresponds to such title key entry in a title key file and check the key file status bits at that location in the key navigation file 104.
• the title key entries are labeled sequentially across the different title key files as shown in Fig. 3B.
• the title key entries in title key file key file.OOO are labeled TKE1-TKE127.
• the title key entries in title key file key file.OOl are labeled TKE129-TKE255.
• those in title key file key_file.002 are labeled TKE257-TKE383, and so on.
• the first location and entry of each of the title key file i.e. TKEO, TKE128, TKE256 ...) are reserved for the header, which may contain information such as size of the file, version number and other information about the file.
• each title key entry has a unique number associated therewith, which is one of the following: 1-127, 129-255, 257-383 and so on. This unique number is then preferably also used to identify the particular location in the key navigation file where the corresponding key file status bit is located.
• the key file status bits corresponding to the title key entries are stored at locations in the same sequence as the title key entries across the different title key files. For example, as illustrated in Fig.
• the key file status bit "KFS[i]" for indicating whether the title key entry TKE [i] contains a valid key or not is stored at the ith location in the key navigation file 104, counting from the first location at the top of the first key file status field KFSOOO, even where the ith location is in a key file status field that is different from KFSOOO.
• this unique number is unique across all key status fields, and it is numbered consecutively starting from the first entry at the top of KFSOOO across all key file status fields KFS 000, KFS 001 ... , until the last key file status entry in key navigation file 104.
• the process for finding the title key entry corresponding to a particular key file status bit in the key navigation file 104 can be implemented as follows.
• the unique number associated with each title key entry and its corresponding key file status bit is referred to as the key navigation index ("KNI").
• KNI key navigation index
• the KNI values 0, 128, 256, 384, ... (N+128) are illegal, where N is an integer.
• KNI is therefore also the offset of the key file status bit in the key navigation file 104 from the very first status bit in the header of KFSOOO.
• i has a value between 129 and 255, so that the integer portion of i divided by 128 is 1, so that it is readily determined that the title key file key file.OOl contains the corresponding title key entry i.
• each of the title key files contains 128 entries of 16 bytes each.
• the title key files may contain a number of entries different from 128 where each entry may have a number of bytes different from 16.
• m being any positive integer
• the above operation would need to be modified so that the KNI or key navigation index is divided by m instead of 128.
• the offset is found by i mod m instead to find the offset of the title key entry TKEi from the top entry in such title key file. All such variations are within the scope of the invention.
• the one-to-one correspondence relationship between an entry in the key navigation file and a TKE in each of the title key files can be established by means of a look up table.
• the CPU 12 will then need to check the look up table to find the location of a corresponding key given a location of a status bit in the key navigation file, and vice versa (i.e. to find the status bit in the key navigation file that reveals the key status given the location of a key in a particular title key file).
• Such and other variations are within the scope of the invention.
• each title key entry for the value of a key for encryption/decryption.
• the key value is ciphered or encrypted using another key.
• the title key status bit when the title key status bit is of value 0, this indicates that the title key entry is busy, meaning either that the bit has been reserved such as in the case of the header of each title key file, or that the corresponding title key entry contains a valid key, and therefore not available for storing a new key.
• title key status bit is of value 1 , this indicates that the corresponding title key entry is empty, or that it does not contain a valid key, so that the corresponding slot or location in the title key file is available for storing an encryption/decryption key by over writing the title key entry in such slot or location.
• the length of the key navigation file is not defined but is determined by the number of title key files.
• the key navigation file comprises 512-byte records. Therefore, even though the length of the file is not defined, it is in multiples of 512 bytes in the embodiment of Figs. 3A and 3B. New records may be added to the file as necessary.
• the title key status bit value is a Boolean number, while the serial number of the title key files, the key navigation index are decimal numbers in the embodiment of Figs. 3 A an 3B.
• Fig. 4 is a schematic view of directory tree structure 130 in an unprotected user data area used for illustrating one embodiment of the invention.
• the directory structure is a file stored in flash memory 20 where the directory structure may be accessed by any user, device or application without authentication, since it is stored in an unprotected user data area.
• the directory tree structure has a root directory and two side branches: A player 1 directory and a player 2 directory.
• Player 1 or 2 can be any user, device or application.
• the two branches allow easy access by two different players.
• the player 1 directory lists a number of different content files, such as "Mysong.MP3," "Another. MP3" ...
• the player 2 directory contains a similar list of content files and another key navigation file, "KNF.bin.”
• KNF.bin a key navigation file
• player 1 accesses the user data area
• player 1 is directed towards the player 1 directory and the content files and the key navigation file under such directory.
• player 2 which is directed towards the content files within the player 2 directory as well as the key navigation file in such directory.
• player 1 creates a content file
• this file is created and added to the list under the player 1 directory.
• this new content file is also listed in the player 2 directory.
• the content files in tree 130 are encrypted using keys stored in directories in tree 150 in Fig. 5.
• both encrypted and non-encrypted content files may also be stored in the same unprotected user data area which can be accessed without authentication.
• Fig. 5 is a schematic view of a directory tree 150 in a protected area in memory device 20 where the directory trees 130 and 150 of Figs. 4 and 5 mirror each other.
• the directory tree has a root directory as well as a player 1 directory and player 2 directory.
• the player 1 directory lists the title key file key file.000 which contains a number of different title key entries for encrypting and/or decrypting the content files in player 1 directory in tree 130.
• the player 2 directory also contains a title key file key file.000 containing a number of title key entries. It will be noted that even though the two title key files under the two directors have the same name (i.e. key file.000), they will not be confused since they are in different directories. The same is true for the key navigation files in the two directories in tree 130 in Fig. 4.
• the two directory trees 130 and 150 mirror each other since they have the same branches: player 1 directory and player 2 directory, even though the contents of the directories player 1 and player 2 differ between the two trees 130 and 150. It is possible for the two directories between each of the trees 130 and 150 to have more branches at the same level as player 1 and player 2, such as player 3 (not shown in Figs. 4 and 5) and so on. It is also possible for the two directories player 1 and player 2 to have subdirectories. For example, the player 1 directory in tree 130 may have two subdirectories: one for video files and one for audio files (not shown in Fig. 4). The audio file subdirectory will contain a list of audio files such as songs and a key navigation file for navigation among such audio files.
• the video subdirectory may contain video files and a key navigation file for navigation among such audio files.
• directory tree 150 in Fig. 5 will also have a similar tree structure.
• the player 1 directory in tree 150 may have two different subdirectories: an audio and a video subdirectory (not shown in Fig. 5).
• the video subdirectory contains a list of title key file or files each containing the title key entries used for encrypting/decrypting the video files in the video subdirectory of directory tree 130.
• Directory tree 150 will also have an audio subdirectory under the player 1 directory where the audio subdirectory will contain one or more title key files each containing title key entries used for encrypting/decrypting the corresponding audio files listed in the audio subdirectory of directory tree 130.
• having directory trees 130 and 150 that are mirrors of each other in the unprotected and protected areas greatly facilitates the operation of the key navigation mechanism.
• a key manager referred to herein as a key navigation mechanism also creates the key navigation file in the unprotected user area and a first title key storage file in the protected area.
• Fig. 6 is a flow chart illustrating the process or method carried out by a key navigation mechanism.
• the mechanism performing the process of Fig. 6 may comprise computer program code stored in and executed by the host device 24 which sends commands to the memory system where the content files, title key files and the key navigation files are stored.
• the mechanism may comprise computer program code stored in flash memory 20 that is loaded to and executed by CPU 12.
• the computer program for the key navigation mechanism of Figs. 6 and 7 may be stored in a computer readable medium which is a part of or connected to host device 24; alternatively, such computer program may be stored in flash memory 20 where the title key files, the key navigation file and content files are stored. All such variations are within the scope of the invention.
• the process of the mechanism of Fig. 6 starts if it is desired to either open a protected content file, or when a protected content file is to be created (Block 202).
• the key navigation mechanism determines whether a content file exists or not (diamond 204). If the content file does not exist, this means one needs to be created and host device 24 or CPU 12 proceeds to create the file (block 206), such as for player 1 in directory tree 130.
• the key navigation mechanism checks on whether a key navigation file already exists or has already been created (diamond 207a). If it has not been , then the mechanism creates a key navigation file (block 207b).
• the mechanism opens the key navigation file found in the same directory as the newly created content file, in a directory such as directory 130 illustrated in Fig. 4 (Block 208). In either case, the mechanism then checks the key navigation file in the player 1 directory in tree 130 and finds the first key entry with "empty" status. The offset of "empty" status in the key navigation file gives the key navigation index (KNI) (blocks 208 and 210), employing the embodiment above that uses KNI.
• KNI key navigation index
• the locations or title key entries in the title key files are used sequentially. This means that when one encryption/decryption key is created and needs to be stored in the title key files, the slots or locations in the title key files are used for storing keys sequentially, starting with the title key entry 1 in the title key file key file.000. After such key is stored and forms the key entry, TKEl, or a part of it, its corresponding key file status bit KFS[I] value is changed from 1 to 0, indicating that it is not empty and now is busy, meaning that it now contains a valid key, since this location is not one reserved for a header. Initially, all of the key file status bits have the value 1, except for the key file status bits for 0, 128, 256 ..., which have the value 0.
• the key navigation mechanism calculates the key file index or nnn which is equal to integer portion of KNI/ 128 (block 212), where each of the title key files has 128 slots or locations, nnn or the key file index is the integer portion of the number KNI/128. This nnn or the key file index value is the serial number of the title key file. Then the offset within such title key file is obtained by computing the quantity KNI %128 or KNI mod 128 (block 214).
• the content file is created within a directory, such as the player 1 directory in directory tree 130 in Fig. 4.
• the key navigation mechanism converts an access path constructed in accordance with the directory tree 130 in the unprotected user data area to one that is constructed in accordance with the directory tree 150 in the protected area or partition, by replacing the public partition name for the non-protected user data area with the protected partition name for the protected area (block 216).
• the key navigation mechanism then forms the key file name: "key f ⁇ le.nnn.” (Block 218)
• the key navigation mechanism then forms the full key file name (Block 220).
• the full key file name created will be "prot_partition/layerldirectory/key_file.nnn.”
• the key navigation mechanism then checks to see if a title key file exists with this key file name (diamond 221a). If this title key file does not exist, the mechanism creates one and adds it to the appropriate directory (e.g. player 1) in directory tree 150 (block 221b). If this title key file exists, the mechanism opens the title key file using the access path in accordance to the full key file name. (Block 222) The key navigation mechanism then checks whether the content file has existed originally before block 206 (diamond 224). In the example above, such content file did not exist prior to its creation in block 206, so that the key navigation mechanism proceeds to block 226 to put the KNI into the file header of the file created.
• the content encryption key (CEK) is created by crypto engine 40 and used to encrypt the file created (228).
• the encrypted newly created file is added to the directory player 1 in tree 130 in memory device 20.
• This created key is encrypted and put into the title key file identified in block 212 and at the location indicated by the offset obtained in block 214 (block 230), and added as a new title key entry to the title key file in directory player 1 in tree 150.
• 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 in tree 130 from 1 to 0 where the key file status bit is located by using the value of KNI as an offset in the key navigation file in the player 1 directory in tree 130.
• the key navigation file is then closed (blocks 234 and 236).
• the key navigation mechanism of Fig. 6 operates as follows.
• the key navigation mechanism would open the protected content file in a particular directory, such as player 1 directory in tree 130, and proceed to block 252, since the content file already exists.
• the key navigation mechanism retrieves the value KNI from the file header of the content file (block 252).
• the key navigation mechanism opens the protected content file, it is operating within the directory tree 130 in the unprotected user data area.
• the access path to such content file is constructed in accordance with the directory tree 130.
• the key navigation mechanism then performs the operations in blocks 212-222 in the manner described above to find the key file index or nnn of a certain title key file in which the decryption key for the decrypting (and/or encrypting) the content file is stored, and the offset indicating the location of the key in such title key file.
• the key navigation mechanism also converts an access path to the public or unprotected user data area in accordance with directory tree 130 to an access path constructed in accordance with directory tree 150 in the protected area and builds a full key file name for the decryption key in the protected area in accordance with blocks 216, 218 and 220.
• the key navigation mechanism then opens the title key file in the protected area in accordance with the full key file name constructed (block 222) so that the content decryption key is now readily available to be retrieved.
• the key navigation mechanism then checks whether the content file exists prior to the above-described operation. In this example, it does exist so that the mechanism proceeds to block 254 to retrieve the encrypted content encryption key from the key entry offset in the proper title key file (block 254).
• the content encryption key is then decrypted and used for decrypting/encrypting the content file that has been or will be protected by encryption, (block 256).
• the key navigation mechanism for this purpose, which may be a computer program stored in and executed by either the host device 24 or memory system 10, first identifies in a directory the protected content file that is to be deleted (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 and obtains 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).
• the bit offset is found in the key navigation file within the same directory as the content file (player 1 directory in this instance).
• the key navigation mechanism uses the KNI as the offset from the first entry in the key navigation file to find the position of the key file status bit that indicates the status of the title key entry in the title key file that is used to encrypt/decrypt the content file to be deleted. It then resets the key file status bit found at the offset location from 0 to a 1, thereby indicating that the corresponding title key entry (TKE) in the title key file of that file status bit does not contain a valid key. (block 308).
• the above described system for managing keys can also be used for managing other types of content protection information, such as rules specifying that the content file may only be accessed for a limited number of times, before certain expiration dates or only for certain time durations.
• DRM digital rights management
• rules are handled together with the content encryption/decryption keys that are used for protecting content in objects known as rights objects.
• rights objects In order to find out how an encrypted content file may be used and/or accessed, one would first locate its rights object, extract the encryption/decryption key from it, and the rules governing its use. Then the content file is decrypted/encrypted using the key, and the content may be accessed. Sometimes a content file may be downloaded or otherwise received, and its rights object will need to be found.
• the file is encrypted when downloaded, it may be necessary to purchase the rights for access; in such event, the rights object will be supplied and can be downloaded after purchase. If the downloaded file is not encrypted, then a rights object can be created to protect the content file. Once the rights object is obtained, the key in the rights object is then extracted from the rights object, and the content file encrypted or decrypted using the key. The file may then be further handled as appropriate. Conversely, after a file has been created, a rights object may be created for it, where the object includes a key used for its encryption/decryption.
• the decrypted content file may be re- encrypted using a key that is different from the one in the rights object.
• the user who downloaded the content file may generate a key that is different from the one in the rights object obtained from the rights issuer and re-encrypts the content file after it has been decrypted using the key in the rights object obtained from the rights issuer. The key in the rights object is then replaced by the key generated by the user.
• the user may simply encrypt the content file using a key he/she generated without first decrypting it, so that the content file is encrypted by two different keys: a key from the rights issuer (which means the content file can be decrypted by means of a first key in the rights object), and a second key generated by the user which second key is available only to the user who generated it. The user then stores the additional second key also in the rights object.
• a key from the rights issuer which means the content file can be decrypted by means of a first key in the rights object
• a second key generated by the user which second key is available only to the user who generated it.
• the user then stores the additional second key also in the rights object.
• Fig. 8 is a flow chart illustrating a rights object (RO) navigation mechanism for rights object management.
• the RO navigation mechanism performing the process of Fig. 8 may comprise computer program code stored in and executed by the host device 24 which sends commands to the memory system where the content files, RO files and the key navigation files are stored.
• the mechanism may comprise computer program code stored in flash memory 20 that is loaded to and executed by CPU 12.
• the computer program for the RO navigation mechanism of Figs. 8 and 9 may be stored in a computer readable medium which is a part of or connected to host device 24; alternatively, such computer program may be stored in flash memory 20 where the RO files, the rights object navigation file and content files are stored. All such variations are within the scope of the invention.
• a comparison of Figs. 6, 7 on one hand and Figs. 8 and 9 on the other will reveal that they are quite similar, so that the RO management process of Figs. 8 and 9 is quite similar to the key management process of Figs. 6 and 7 respectively.
• RO management similar to key management described above
• RONI used for labeling RO entries (ROE) across RO files (similar in concept to KNI), in a manner similar to that illustrated in Fig. 3B.
• Status bits ROS[i] in a RO navigation file are used for indicating whether the corresponding ith RO is valid or not in one of the RO files.
• the RO navigation file may be stored in a public partition or area along with the content files in directories in directory trees in the same manner as that shown in Fig. 4 involving key management.
• the RO files are stored in a protected partition or area in directories in directory trees in the same manner as that shown in Fig. 5 for key management, where the trees in the two areas are mirrors of each other (not shown).
• the process of the mechanism of Fig. 8 starts if it is desired to either open or download a protected content file (Block 402).
• the RO navigation mechanism determines whether a content file has been downloaded or not (diamond 404). If the content file has not been downloaded, this means that the content file exists already so that there is no need to download. 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 in the public domain (similar to the public area in Fig. 4).
• the RO navigation mechanism checks on whether a RO navigation file exists in the same directory (diamond 407a). If it does not, then the mechanism creates a RO navigation file (block 407b).
• the mechanism opens the RO navigation file found in the same directory as the downloaded content file, similar to that found in Fig. 4 (Block 408). In either case, the mechanism then checks the RO navigation file in the appropriate directory in a directory tree and finds the first RO entry with "empty" or "not valid” status. The offset of "empty" or “not valid” status in the RO navigation file gives the RO navigation index (RONI) (blocks 408 and 410), employing the embodiment above that uses RONI.
• the locations or RO entries in the RO files are used sequentially. This means that when one RO is created and needs to be stored in the RO files, the slots or locations in the RO files are used for storing ROs sequentially, starting with the RO entry 1 in the RO file RO file.OOO. After such RO is stored and forms the first RO entry, or a part of it, its corresponding RO file status bit ROS[I] value is changed from 1 to O, indicating that it is not empty and now is busy, meaning that it now contains a valid RO, since this location is not one reserved for a header.
• RO file status bits have the value 1, except for the RO file status bits for O, 128, 256 ..., which have the value O. It will be understood, however, that instead of this embodiment, a lookup table may be used instead as in the case of the key navigation mechanism; all such variations are within the scope of the invention.
• the RO navigation mechanism calculates the RO file index or nnn which is equal to integer portion of RONI/128 (block 412), where each of the RO files has 128 slots or locations, nnn or the RO file index is the integer portion of the number RONI/128. This nnn or the RO file index value is the serial number of the RO file. Then the offset within such RO file is obtained by computing the quantity RONI %128 or RONI mod 128 (block 414).
• the downloaded content file is assigned to a directory, (such as a directory analogous to the player 1 directory in directory tree 130 in Fig. 4).
• a directory such as a directory analogous to the player 1 directory in directory tree 130 in Fig. 4.
• the RO navigation mechanism converts an access path constructed in accordance with the directory tree in the unprotected user data area to one that is constructed in accordance with the directory tree in the protected area or partition, by replacing the public partition name for the non-protected user data area with the protected partition name for the protected area (block 416), again in a manner similar to that in Fig. 6.
• the RO navigation mechanism then forms the RO file name: "RO file.nnn.” (Block 418)
• the RO navigation mechanism then forms the full RO file name (Block 420).
• the full RO file name in which this RO is to be stored is constructed in accordance with blocks 408, 410, 412, 414, 416, 418 and 420. In such event, the full RO file name created will be "prot_partition/playerxdirectory/RO_file.nnn.”
• the RO navigation mechanism then checks to see if a RO file exists with this RO file name (diamond 421a). If this RO file does not exists, the mechanism creates one and adds it to the appropriate directory (e.g. player x) in a directory tree (block 421b) in the protected area or partition. If this RO file exists, the mechanism opens the RO file using the access path in accordance to the full RO file name. (Block 422) The RO navigation mechanism then checks whether the content file has been downloaded or not originally at block 406 (diamond 424). In the example above, such content file was downloaded, so that the RO navigation mechanism proceeds to block 426 to put the RONI into the file header of the file downloaded. Thus the RONI also serves to associate each RO with the content file it is controlling, while also serving the above described functions for RO navigation and management.
• the appropriate directory e.g. player x
• block 421b directory tree
• the RO (including key) is created by crypto engine 40 or otherwise obtained (e.g. downloaded after purchase) and the key generated or so obtained is used to encrypt the file downloaded (428).
• the encrypted newly downloaded file is added to the directory player x in the tree in the public area or partition in memory device 20.
• This RO is encrypted and put into the RO file identified in block 412 and at the location indicated by the offset obtained in block 414 (block 430), and added as a new RO entry to the RO file in the directory player x in the tree in the protected partition or area.
• 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 in the player x directory in tree in the public area from 1 to 0 where the RO file status bit is located by using the value of RONI as an offset in the RO navigation file in the player x directory in the tree in the public area.
• the RO navigation file is then closed (blocks 434 and 436).
• the RO navigation mechanism of Fig. 8 operates as follows.
• the RO navigation mechanism would open the protected content file in a particular directory, such as player x directory in the public area, and proceed to block 452, since the content file already exists.
• the RO navigation mechanism retrieves the value RONI from the file header of the content file (block 452).
• the RO navigation mechanism opens the protected content file, it is operating within the directory tree in the unprotected user data area.
• the access path to such content file is constructed in accordance with such directory tree.
• the RO navigation mechanism then performs the operations in blocks 412-422 in the manner described above to find the RO file index or nnn of a certain RO file in which the RO associated with the content file is stored, and the offset indicating the location of the RO in such RO file.
• the RO navigation mechanism also converts an access path to the public or unprotected user data area in accordance with directory tree in the public area to an access path constructed in accordance with directory tree in the protected area and builds a full RO file name for the decryption RO in the protected area in accordance with blocks 416, 418 and 420.
• Fig. 9 is a flow chart illustrating a rights object navigation mechanism for deleting a file to illustrate a further feature of a rights object management system.
• RO navigation mechanism for this purpose, which may be a computer program stored in and executed by either the host device 24 or memory system 10, first identifies in a directory the protected content file that is to be deleted (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 and obtains 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).
• the bit offset is found in the RO navigation file within the same directory as the content file (player x directory in this instance).
• the RO navigation mechanism uses the RONI as the offset from the first entry in the RO navigation file to find the position of the RO file status bit that indicates the status of the RO entry in the RO file that is associated with the content file to be deleted. It then resets the RO file status bit found at the offset location from O to a 1 , thereby indicating that the corresponding RO entry (ROE) in the RO file of that file status bit does not contain a valid RO. (block 508).

Landscapes

• Engineering & Computer Science (AREA)
• Theoretical Computer Science (AREA)
• Software Systems (AREA)
• Computer Security & Cryptography (AREA)
• Computer Hardware Design (AREA)
• Physics & Mathematics (AREA)
• General Engineering & Computer Science (AREA)
• General Physics & Mathematics (AREA)
• Multimedia (AREA)
• Technology Law (AREA)
• Storage Device Security (AREA)

Applications Claiming Priority (3)

Publications (1)

Family

ID=38371958

Family Applications (1)

Country Status (5)

Families Citing this family (4)

Family Cites Families (3)

• 2006
  • 2006-11-15 EP EP06850155A patent/EP1949294A2/de not_active Withdrawn
  • 2006-11-15 WO PCT/US2006/060928 patent/WO2007094874A2/en active Application Filing
  • 2006-11-15 JP JP2008541468A patent/JP2009516961A/ja not_active Withdrawn
  • 2006-11-15 KR KR1020087014728A patent/KR20080068757A/ko not_active Application Discontinuation
  • 2006-11-17 TW TW095142629A patent/TW200736954A/zh unknown

Non-Patent Citations (1)

Also Published As

Similar Documents

Legal Events