EP1934878A2 - Mobile memory system for secure storage and delivery of media content - Google Patents
Mobile memory system for secure storage and delivery of media contentInfo
- Publication number
- EP1934878A2 EP1934878A2 EP06814382A EP06814382A EP1934878A2 EP 1934878 A2 EP1934878 A2 EP 1934878A2 EP 06814382 A EP06814382 A EP 06814382A EP 06814382 A EP06814382 A EP 06814382A EP 1934878 A2 EP1934878 A2 EP 1934878A2
- Authority
- EP
- European Patent Office
- Prior art keywords
- content
- rights
- access
- encrypted
- media
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Withdrawn
Links
- 230000015654 memory Effects 0.000 title claims description 188
- 238000003860 storage Methods 0.000 title claims description 43
- 238000009826 distribution Methods 0.000 claims abstract description 22
- 238000000034 method Methods 0.000 claims description 201
- 238000005192 partition Methods 0.000 claims description 135
- 238000009877 rendering Methods 0.000 claims description 48
- 230000006870 function Effects 0.000 claims description 27
- 238000013475 authorization Methods 0.000 claims description 11
- 230000004044 response Effects 0.000 claims description 11
- 230000004048 modification Effects 0.000 claims description 5
- 238000012986 modification Methods 0.000 claims description 5
- 238000009795 derivation Methods 0.000 claims 2
- 241000288140 Gruiformes Species 0.000 claims 1
- 208000037656 Respiratory Sounds Diseases 0.000 claims 1
- 206010037833 rales Diseases 0.000 claims 1
- 230000008569 process Effects 0.000 description 70
- 101150116940 AGPS gene Proteins 0.000 description 34
- 238000004519 manufacturing process Methods 0.000 description 28
- 238000010586 diagram Methods 0.000 description 22
- 239000003795 chemical substances by application Substances 0.000 description 19
- 238000004422 calculation algorithm Methods 0.000 description 17
- 239000010432 diamond Substances 0.000 description 15
- 229910003460 diamond Inorganic materials 0.000 description 14
- 238000007726 management method Methods 0.000 description 12
- 230000001413 cellular effect Effects 0.000 description 11
- 102100023593 Fibroblast growth factor receptor 1 Human genes 0.000 description 9
- 230000009471 action Effects 0.000 description 9
- 230000008859 change Effects 0.000 description 8
- 238000012217 deletion Methods 0.000 description 7
- 230000037430 deletion Effects 0.000 description 7
- 238000004891 communication Methods 0.000 description 6
- 238000012545 processing Methods 0.000 description 6
- 102100022443 CXADR-like membrane protein Human genes 0.000 description 5
- 101000901723 Homo sapiens CXADR-like membrane protein Proteins 0.000 description 5
- 238000012546 transfer Methods 0.000 description 5
- 230000000903 blocking effect Effects 0.000 description 4
- 230000007246 mechanism Effects 0.000 description 4
- 230000001737 promoting effect Effects 0.000 description 4
- 238000012795 verification Methods 0.000 description 4
- 241000197200 Gallinago media Species 0.000 description 3
- 238000011160 research Methods 0.000 description 3
- 230000004075 alteration Effects 0.000 description 2
- 230000000694 effects Effects 0.000 description 2
- 239000003999 initiator Substances 0.000 description 2
- 238000009434 installation Methods 0.000 description 2
- 230000005055 memory storage Effects 0.000 description 2
- 230000003287 optical effect Effects 0.000 description 2
- 230000002093 peripheral effect Effects 0.000 description 2
- 101100161875 Arabidopsis thaliana ACR2 gene Proteins 0.000 description 1
- 101100495264 Arabidopsis thaliana CDC25 gene Proteins 0.000 description 1
- 101100388057 Mus musculus Poln gene Proteins 0.000 description 1
- 101100380266 Saccharomyces cerevisiae (strain ATCC 204508 / S288c) ARR2 gene Proteins 0.000 description 1
- 101150004068 acrB gene Proteins 0.000 description 1
- 238000004458 analytical method Methods 0.000 description 1
- 230000004888 barrier function Effects 0.000 description 1
- 230000006399 behavior Effects 0.000 description 1
- 230000008901 benefit Effects 0.000 description 1
- 230000005540 biological transmission Effects 0.000 description 1
- 230000015572 biosynthetic process Effects 0.000 description 1
- 230000005465 channeling Effects 0.000 description 1
- 238000012790 confirmation Methods 0.000 description 1
- 239000013256 coordination polymer Substances 0.000 description 1
- 238000013500 data storage Methods 0.000 description 1
- 238000001514 detection method Methods 0.000 description 1
- 238000003745 diagnosis Methods 0.000 description 1
- VJYFKVYYMZPMAB-UHFFFAOYSA-N ethoprophos Chemical compound CCCSP(=O)(OCC)SCCC VJYFKVYYMZPMAB-UHFFFAOYSA-N 0.000 description 1
- 230000007717 exclusion Effects 0.000 description 1
- 208000008487 fibromuscular dysplasia Diseases 0.000 description 1
- 230000000977 initiatory effect Effects 0.000 description 1
- 238000011900 installation process Methods 0.000 description 1
- 238000004806 packaging method and process Methods 0.000 description 1
- 238000003752 polymerase chain reaction Methods 0.000 description 1
- 238000000638 solvent extraction Methods 0.000 description 1
- 230000009466 transformation Effects 0.000 description 1
- 230000005641 tunneling Effects 0.000 description 1
- 239000013598 vector Substances 0.000 description 1
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/10—Protecting distributed programs or content, e.g. vending or licensing of copyrighted material ; Digital rights management [DRM]
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- 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]
- G06F21/105—Arrangements for software license management or administration, e.g. for managing licenses at corporate level
-
- G—PHYSICS
- G11—INFORMATION STORAGE
- G11B—INFORMATION STORAGE BASED ON RELATIVE MOVEMENT BETWEEN RECORD CARRIER AND TRANSDUCER
- G11B20/00—Signal processing not specific to the method of recording or reproducing; Circuits therefor
- G11B20/00086—Circuits for prevention of unauthorised reproduction or copying, e.g. piracy
-
- G—PHYSICS
- G11—INFORMATION STORAGE
- G11B—INFORMATION STORAGE BASED ON RELATIVE MOVEMENT BETWEEN RECORD CARRIER AND TRANSDUCER
- G11B20/00—Signal processing not specific to the method of recording or reproducing; Circuits therefor
- G11B20/00086—Circuits for prevention of unauthorised reproduction or copying, e.g. piracy
- G11B20/0021—Circuits for prevention of unauthorised reproduction or copying, e.g. piracy involving encryption or decryption of contents recorded on or reproduced from a record carrier
-
- G—PHYSICS
- G11—INFORMATION STORAGE
- G11B—INFORMATION STORAGE BASED ON RELATIVE MOVEMENT BETWEEN RECORD CARRIER AND TRANSDUCER
- G11B20/00—Signal processing not specific to the method of recording or reproducing; Circuits therefor
- G11B20/00086—Circuits for prevention of unauthorised reproduction or copying, e.g. piracy
- G11B20/0071—Circuits for prevention of unauthorised reproduction or copying, e.g. piracy involving a purchase action
-
- G—PHYSICS
- G11—INFORMATION STORAGE
- G11B—INFORMATION STORAGE BASED ON RELATIVE MOVEMENT BETWEEN RECORD CARRIER AND TRANSDUCER
- G11B20/00—Signal processing not specific to the method of recording or reproducing; Circuits therefor
- G11B20/00086—Circuits for prevention of unauthorised reproduction or copying, e.g. piracy
- G11B20/0071—Circuits for prevention of unauthorised reproduction or copying, e.g. piracy involving a purchase action
- G11B20/00724—Circuits for prevention of unauthorised reproduction or copying, e.g. piracy involving a purchase action wherein a prepaid credit balance is registered on the recording medium
-
- G—PHYSICS
- G11—INFORMATION STORAGE
- G11B—INFORMATION STORAGE BASED ON RELATIVE MOVEMENT BETWEEN RECORD CARRIER AND TRANSDUCER
- G11B20/00—Signal processing not specific to the method of recording or reproducing; Circuits therefor
- G11B20/00086—Circuits for prevention of unauthorised reproduction or copying, e.g. piracy
- G11B20/00731—Circuits for prevention of unauthorised reproduction or copying, e.g. piracy involving a digital rights management system for enforcing a usage restriction
-
- G—PHYSICS
- G11—INFORMATION STORAGE
- G11B—INFORMATION STORAGE BASED ON RELATIVE MOVEMENT BETWEEN RECORD CARRIER AND TRANSDUCER
- G11B20/00—Signal processing not specific to the method of recording or reproducing; Circuits therefor
- G11B20/00086—Circuits for prevention of unauthorised reproduction or copying, e.g. piracy
- G11B20/00731—Circuits for prevention of unauthorised reproduction or copying, e.g. piracy involving a digital rights management system for enforcing a usage restriction
- G11B20/00746—Circuits for prevention of unauthorised reproduction or copying, e.g. piracy involving a digital rights management system for enforcing a usage restriction wherein the usage restriction can be expressed as a specific number
- G11B20/00797—Circuits for prevention of unauthorised reproduction or copying, e.g. piracy involving a digital rights management system for enforcing a usage restriction wherein the usage restriction can be expressed as a specific number wherein the usage restriction limits the number of times a content can be reproduced, e.g. using playback counters
-
- G—PHYSICS
- G11—INFORMATION STORAGE
- G11B—INFORMATION STORAGE BASED ON RELATIVE MOVEMENT BETWEEN RECORD CARRIER AND TRANSDUCER
- G11B20/00—Signal processing not specific to the method of recording or reproducing; Circuits therefor
- G11B20/00086—Circuits for prevention of unauthorised reproduction or copying, e.g. piracy
- G11B20/00855—Circuits for prevention of unauthorised reproduction or copying, e.g. piracy involving a step of exchanging information with a remote server
- G11B20/00862—Circuits for prevention of unauthorised reproduction or copying, e.g. piracy involving a step of exchanging information with a remote server wherein the remote server can grant the permission to use a content
-
- G—PHYSICS
- G11—INFORMATION STORAGE
- G11B—INFORMATION STORAGE BASED ON RELATIVE MOVEMENT BETWEEN RECORD CARRIER AND TRANSDUCER
- G11B20/00—Signal processing not specific to the method of recording or reproducing; Circuits therefor
- G11B20/00086—Circuits for prevention of unauthorised reproduction or copying, e.g. piracy
- G11B20/00978—Circuits for prevention of unauthorised reproduction or copying, e.g. piracy wherein the record carrier stores a trial version of a content
- G11B20/00985—Circuits for prevention of unauthorised reproduction or copying, e.g. piracy wherein the record carrier stores a trial version of a content the trial version being of lower quality than the original version
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
- H04N7/00—Television systems
- H04N7/16—Analogue secrecy systems; Analogue subscription systems
-
- G—PHYSICS
- G11—INFORMATION STORAGE
- G11B—INFORMATION STORAGE BASED ON RELATIVE MOVEMENT BETWEEN RECORD CARRIER AND TRANSDUCER
- G11B2220/00—Record carriers by type
- G11B2220/60—Solid state media
- G11B2220/61—Solid state media wherein solid state memory is used for storing A/V content
Definitions
- This invention is directed to systems that employ mobile storage devices to securely store media content and deliver such content to consumers.
- Non-volatile rewritable memory devices are particularly suitable as a vehicle for storing media content.
- flash memory cards now have capacities in the multi-gigabyte range, which is much higher than other storage media such as smartcards, and can be used to store movies, video games and a large number of music pieces.
- flash memory is rewritable, they are more flexible compared to high capacity non-rewritable memories such as compact discs.
- the one draw back with existing flash memory devices is that they do not provide adequate security to prevent unauthorized use or access to the media content stored on the cards.
- media content in non-volatile rewritable memory devices can be securely protected and controlled by or on behalf of the content owner, new avenues for distributing media content will be provided for media companies; the end user will then be able to access the media content in such devices through different mobile digital devices without having to subscribe to multiple media services.
- Service providers such as MNOs can also derive additional revenue by being able to charge for the service of securely storing media content and distributing media content in a controlled manner.
- a nonvolatile rewritable memory device may be pre-loaded with encrypted media titles so that such titles can be previewed without any restrictions.
- such previews may comprise unencrypted portions of the encrypted media titles or unencrypted lower quality versions of such titles.
- the previews may also comprise a limited number of plays or rendering of the full-length media titles.
- the end user will have to purchase the rights to access the encrypted and unabridged media titles. After the end user purchases the right to access the encrypted media titles, he or she will be able to access such titles.
- information concerning credentials or other types of authentication information and rights and/or rules for accessing the encrypted media titles that are available for preview are not pre-loaded into the device. These become available to the end user only after the purchase; after the purchase, such information is stored in the memory device.
- pre-loaded into the above described non-volatile rewritable memory device are encrypted media titles as well as rights and/or rules which specify that only selected portions of the encrypted media titles or lower quality versions of such titles are accessible without restriction or that such titles can be played for only a limited number of times.
- the rights and/or rules stored in the memory device are then updated to permit access to the encrypted media titles stored in the memory device either without further restriction or with more relaxed restrictions.
- Non-volatile rewritable memory devices with security features may also be advantageously used by service providers to control the distribution of media content.
- non-volatile rewritable memory devices may be provided with security features that enable service providers to create its own secure environment on the device.
- the service provider can control how the media content stored in the device is to be used in such environment.
- the non-volatile rewritable memory device is provided with a system agent which enables the service provider to create a control structure in a secure memory area of the device for controlling access to encrypted content stored in the device.
- the control structure enables a service provider to set up a scheme for distributing media content in a flexible manner.
- the 0 control structure can take the form of a hierarchical tree, through which the service provider has many options in controlling how the media content can be used and accessed.
- the control structure can also take the form of an object referred to below as a "rights object" where rights and/or rules are associated with access to specific media content and with certain authentication requirement(s), where access to such content is granted when such authentication requirement(s) is satisfied.
- a number of applications or end users may be able to access the same content but without sharing Keys or credentials, and may be able to delegate the right for access to certain keys used to decrypt and/or encrypt content.
- the control structure can also allow the service provider to exercise control over which terminals and accounts may access certain type of content.
- the media content in the device can be accessed without restriction through any end user terminal.
- these devices with security features can be accessed only by terminals with a particular credential, such as an identifier or ID of a particular service provider (e.g. MNO).
- a third category of memory devices with security features will then enable only a certain group of end users such as a family to access the content in the device by means of terminals having the particular credential, such as the ID of a mobile network operator.
- a fourth category of the rewritable nonvolatile memory devices would enable content stored in the device to be accessed only by a terminal with its own unique credential, together with the particular service provider credential, such as the ID of a mobile network operator.
- the control structure created by the service provider or any other entity may be such that it specifies certain permissions for access to one or more content encryption keys used to encrypt media content stored in the non-volatile rewritable memory device.
- the control structure permits access to the one or more content encryption keys (which may be only for certain specified purposes) when predetermined credentials are presented to the device.
- the device will determine whether credentials presented to the device are the pre-determined credentials and access to the one or more of the content encryption keys is granted according to permissions for decrypting the encrypted contents when the pre-determined credentials are presented.
- a non-volatile rewritable memory device may also enable more than one end user to access encrypted media content stored in the device, but where the different end users may have different rights for accessing the same content, or different content. Thus content visible and accessible to one end user may not be accessible or even visible by a different end user.
- the device may store control information including information on a plurality of accounts, each associated with a set of encrypted media titles stored in the device, where each account has corresponding credentials. When credentials associated with one account are presented by a host or terminal to the device, the device will check the credentials presented to determine whether encrypted media titles associated with a particular account should be accessible and/or visible.
- the device will then decrypt the encrypted media titles associated with a particular account and supply the decrypted media titles to the host for rendering when credentials presented by the host are checked to be in order, such as where the presented credentials match those credentials stored in the device for such account.
- the encrypted media titles associated with a particular account attempted to be accessed will not even be visible and will not be accessible either.
- the terms "host” and "terminal” are used interchangeably.
- the non-volatile rewritable memory device with security features may be such that each media file stored in the device will have its own content encryption keys or its own credentials required before access to such keys can be granted, and rights and/or rules in regard to how the decrypted media files or titles can be used.
- a rights object contains rights and/or rules regarding certain encrypted media content, content encryption keys for decrypting and/or encrypting such content and credentials required for accessing such keys.
- Such a rights object can be used as a form of the control structure referred to above.
- the memory device will store a number of content encryption keys available for decrypting a number of corresponding media files stored in the device and store corresponding rights objects.
- each of non-volatile rewritable memory devices manufactured it is possible for each of non-volatile rewritable memory devices manufactured to have unique keys that are different from the keys in any other memory device. This will require a unique set of content encryption keys to be generated for each of the memory devices.
- the rights object does not contain content encryption keys. Instead it contains the authentication information (e.g. credentials) needed for accessing the content encryption keys. In this manner, an added layer of security is provided.
- the devices are divided into a number of groups each having N devices, N being a positive integer.
- N sets of rights objects each containing a corresponding set of content encryption keys are generated!
- Each of the N sets of rights objects also has a corresponding set identification code for identifying one device in each of the groups into which such set of rights objects is to be loaded during manufacturing.
- Each device has a unique identification code, and a set identification code which preferably is derivable from its identification code.
- the installation process will first derive the set identification code of each of the devices to be manufactured from its unique identification code. From the set identification code, the corresponding rights object is then identified and loaded to the device.
- Corresponding media files that can be decrypted using the keys in such rights objects are also loaded to the device.
- the media files loaded can comprise paid media content as well as unpaid media content that requires payment before it can be accessed, and can comprise previews of such unpaid media content available for unrestricted access.
- the media content to be stored in the non-volatile rewritable memory devices is encrypted.
- the loading of the encrypted media content may be performed at non-secure facilities, which greatly simplifies the manufacturing process of the devices.
- rights objects containing content encryption keys may be loaded first into the devices at a secure facility. Thereafter, the devices may then be shipped to non-secure facilities for loading of the encrypted media content the access to which is controlled by the rights object already loaded in the memory devices, and the content encryption keys in the objects then may be used to decrypt the encrypted media contents.
- non-volatile rewritable memory devices with encrypted media titles and previews of such titles provide new avenue for media content distribution and revenue for media companies.
- Non-volatile rewritable memories with stored content different from the above type may yet provide other channels of revenue for media companies and other associated providers.
- media content is stored in a memory area of the non-volatile rewritable memory card where the content includes only selected and unencrypted portions of at least some media titles or lower quality unencrypted versions of such titles.
- Such cards may be useful for promotional purposes, and also useful for the end user to preview media content prior to purchase. After the end user has previewed such content, he or she may decide to purchase either the full-length media titles or the high quality versions of such titles. After the purchase, the end user may then download such media titles to the memory device as well as any rights object after payment.
- the devices will respond to a request from the end user by rendering the unencrypted portions of the media titles or low quality unencrypted versions of the titles or for a limited duration or number of times.
- the devices will also query the user as to whether the user wishes to purchase rights to access the full length or high quality versions of the titles. If the preview content is one where the end user can access the full length title a limited number of times, then the memory device will query the end user after accessing the title(s) as to whether the user wishes to purchase rights to unrestricted access of the title(s).
- the appropriate rights objects are then installed and the full length or high quality media title(s) are installed as well if they are not already stored on the device. After such process has been completed, the user may then have the full length or high quality media titles rendered for enjoyment, or can enjoy the titles without any restrictions.
- non-volatile rewritable memory card stores encrypted media titles without also storing the necessary keys for decrypting the titles. After purchasing the rights for rendering, the end user may then download the appropriate rights objects with the appropriate keys (or credentials for accessing such keys) for decrypting the media titles for enjoyment.
- a non-volatile rewritable memory card with unencrypted media titles stored therein may be used for market research purposes.
- rights object(s) or other control structures that will permit access to the media titles either within a certain time limit or a limited number of times, and the card tracks access to the media titles and compiles an access profile based oh the tracked access. The time limit or the number of times by which the media titles can be played or rendered can be extended if the access profile already compiled is downloaded to a server for purposes such as market research.
- a non-volatile rewritable memory card may store one or more rights object(s) or other control structures as applied to certain encrypted media content that can be accessed but where such content is not stored in a card.
- Such memory card may be used as a pre-paid media content card available for purchase by end users. Since the content encryption keys (or credentials for accessing such keys) and rights and/or rules are already stored in the card, the end user may be able to download the encrypted content specified under the rights and/or rules in the card and decrypt such content using the one or more content encryption keys that can be accessed by or that is stored in the card for rendering.
- One advantage of such card is that it permits the end user to repeatedly download encrypted content specified by the rights and/or rules, so that the end user may be able to delete the encrypted content and download the same content at a later time. This permits the user to access a large volume of media content without giving up the right to access such content.
- control structures controlling the access to these files allow delegation of the permission or authority to access these files to a another control structure, such as a designated control structure, which permits the user to access all of such media files when a particular set of credentials is presented.
- a designated control structure may be a playback access control record or rights object.
- the permission delegated is permission for access to keys for decrypting encrypted media files.
- the rights object contains keys used for decrypting and/or encrypting the content, and authentication requirements for accessing the keys. Additional embodiments similar to the ones above can be implemented using another embodiment of the rights object where rights and/or rules for accessing certain protected areas of the memory device are associated with corresponding authentication requirements, so that only authorized entities who have complied with such requirements are allowed to access the content stored in such areas. Such embodiment of the rights object may or may not contain keys. Where such embodiment of the rights object contains keys, the keys may be used for decrypting and/or encrypting the content stored in the protected areas or unprotected areas, where compliance with authentication requirements preferably different from those used for accessing the protected areas is needed for accessing the keys.
- valuable rights and/or content may be loaded to the memory card.
- it may be important to check the credentials of the card before such valuable content is loaded.
- the credentials of a non-volatile rewritable flash memory card are checked to determine whether the card is genuine or is a counterfeit and information on whether the card is genuine is then provided in response to the checking.
- This capability may be transferred from one server to another, such as from an authentication server to the service provider server.
- the rights object is backed up and restored in a manner that prevents one way of circumventing control of content by the rights object.
- Media content is stored in a first memory area.
- At least one rights object is stored in a second memory area for controlling access to media content stored in the first memory area.
- the second memory area is accessible for backup and restoration of said at least one rights object only by applications that are authorized to do so.
- the second memory area is a protected partition accessible only by applications with credentials that are different from those used to access the partition for read only functions.
- a rights object is accessible for read only functions when first credentials are presented to the device and is accessible to be copied, modified or erased when second credentials different from the first credentials are presented to the device.
- second credentials are presented to the device and the rights object is copied, modified or erased.
- credentials of an application that is accessing a non-volatile rewritable memory card is checked to determine whether it is authorized to do so.
- An indication that said application is not authorized to accessing the nonvolatile rewritable memory card is provided when the credentials of the application does not meet requirements.
- Fig. 1 is a block diagram of a memory system in communication with the host device useful for illustrating this invention.
- FIG. 2 is a schematic view of different partitions of a memory and of unencrypted and encrypted files stored in different partitions where access to certain partitions and the encrypted files is controlled by access policies and authentication procedures useful to illustrate aspects of the invention.
- FIG. 3 is a schematic view of a memory illustrating the different partitions in the memory.
- Fig. 4 is a schematic view of file location tables for the different partitions of the memory shown in Fig. 3 where some of the files in the partitions are encrypted.
- Fig. 5 is a schematic view of access control records in an access controlled record group and the associated key references which are useful to illustrate aspects of the invention.
- Fig. 6 is a schematic view of tree structures formed by access controlled records groups and access controlled records useful to illustrate an aspect of the invention.
- Fig. 7 is a schematic diagram of a tree illustrating three hierarchical trees of access controlled record groups to illustrate a process of formation of the trees.
- Fig. 8A and 8B are flow charts illustrating the processes carried out by a host device and a memory device such as a memory card for creating and using a system access control record.
- Fig. 9 is a flow chart illustrating a process using a system access control record to create an access controlled record group to illustrate an aspect of the invention.
- Fig. 10 is a flow chart illustrating a process for creating an access control record.
- FIG. 11 is a schematic view of two access control record groups useful for illustrating a particular application of the hierarchical tree.
- Fig. 12 is a flow chart illustrating a process for delegation of specific rights.
- Fig. 13 is a schematic view of an access controlled record group and an access control record to illustrate the process of delegation of Fig. 12.
- Fig. 14 is a flowchart illustrating the process for creating a key for the purpose of encryption and/or decryption.
- Fig. 15 is a flow chart illustrating a process for removing access rights and/or permission for data access according to an accessed controlled record.
- Fig. 16 is a flow chart illustrating a process for requesting access when access rights and/or permission to access has been deleted or has expired.
- Figs. 17A and 17B are flow diagrams illustrating sessions of authentication and access when some sessions are open.
- Fig. 18 illustrates an environment in which a memory device may be used for storing media content securely and for delivering the media content stored therein in a controlled manner.
- FIGs. 19A-19D are flow diagrams illustrating different avenues for media content distribution useful for illustrating various embodiments of the invention.
- Fig. 20 is a block diagram of one embodiment of a memory device where different functions are stored in different areas of the device.
- Fig. 21 is a block diagram of a system architecture used for implementing the different media content distribution schemes of Figs. 19A - 19D and other figures of this application.
- Fig. 22 is a block diagram illustrating a memory device containing paid media content and unpaid catalog media content to illustrate one possible avenue for distributing media contents.
- Figs. 23A-23C are flow charts illustrating a content unlocking process involving the device of Fig. 22.
- Fig. 24 is a block diagram illustrating yet another embodiment for unlocking locked catalog media content in the device of Fig. 22 using access control records (ACRs) and a delegation attribute.
- ACRs access control records
- Figs. 25A-25B are flow charts illustrating a process of content rendering.
- Fig. 26 is a block diagram of a security architecture or control structure in a non-volatile re-writable memory device to illustrate additional features of this invention.
- Fig. 27-32 illustrates an overall architecture for mutual authentication between an end user terminal and a memory device.
- Figs. 33A-35 are flow charts illustrating a process of generating and loading of keys and rights objects for prepaid as well as catalogue content.
- L0U57J Hgs. ⁇ bA- ⁇ bD are schematic diagrams of memory devices with encrypted media titles and previews of such titles to illustrate embodiments of the invention.
- Figs. 37A-37C are schematic diagrams of memory devices with preview content to illustrate further embodiments of the invention.
- FIGs. 38A and 38B are schematic diagrams of memory devices with encrypted media titles to illustrate additional embodiments of the invention.
- FIGs. 39A and 39B are schematic diagrams of memory devices with rights objects to illustrate more embodiments of the invention.
- Figs. 40-46 are flow charts illustrating processes for distributing media content using the memory devices of Figs. 36A-39B objects to illustrate embodiments of the invention.
- the memory system or device 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, personal computer, personal digital assistants (PDA), digital media players, MP-3 players, cellular telephones or other digital devices.
- 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.
- the buffer management unit 14 includes a host direct memory access (HDMA) 32, a flash direct memory access (FDMA) 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 are conventional and need not be described in detail herein.
- the BRAM 38 is used to store data passed between the host device 24 and flash memory 20.
- 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 completion.
- memory system 10 For improved security of the content stored in memory 20, memory system 10 generates the key value(s) that are used for encryption and/or decryption. However, encryption and decryption is typically done file by file, since the host device reads and writes data to memory system 10 in the form of files. Like many other types of storage devices, memory device 10 is not aware of files or file systems. While memory 20 does store a file allocation table (FAT) where the logical addresses of the files are identified, the FAT is typically accessed and managed by the host device 24 and not by the controller 12.
- FAT file allocation table
- the controller 12 will have to rely on the host device to send the logical addresses of the data in the file in memory 20, so that the data of the particular file can be found and encrypted and/or decrypted by system 10 using the key value(s) available only to system 10.
- the host device provides a reference for each of the key values generated by system 10, where such reference may simply be a key ID.
- the Host 24 associates each file that is cryptographically processed by system 10 with a key ID, and the system 10 associates each key value that is used to cryptographically process data with a key ID provided by the host.
- the host requests that a file be cryptographically processed, it will send the request along with a key ID along with the logical addresses of data to be fetched from or stored in memory 20 to system 10.
- System 10 generates a key value and associates the key ID provided by the host 24 with such value, and performs the cryptographic processing. In this manner, no change needs to be made in the manner memory system 10 operates while allowing it to control the cryptographic processing using the key(s), .
- system 10 continues to allow the host 24 to manage the files by having exclusive control of FAT, while it maintains control for the generation and management of the key value(s) used for cryptographic processing.
- the key ID provided by the host 24 and the key value generated by the memory system form two attributes of a quantity referred to below as the "content encryption key" or CEK. While the host 24 may associate each key ID with one or more files, host 24 may also associate each key ID with unorganized data or data organized in any manner, and not limited to data organized into complete files.
- system 10 In order for a user or application to gain access to protected content or area in system 10, it will need to be authenticated using a credential which is pre-registered with system 10.
- a credential is tied to the access rights granted to the particular user or application with such credential.
- system 10 stores a record of the identity and credential of the user or application, and the access rights associated with such identity and credential determined by the user or application and provided through the host 24.
- the pre-registration After the pre-registration has been completed, when the user or application requests to write data to memory 20, it will need to provide through the host device its identity and credential, a key ID for encrypting the data, and the logical addresses where the encrypted data is to be stored.
- System 10 generates a key value and associates this value with the key ID provided by the host device, and stores in its record or table for this user or application the key ID for the key value used to encrypt the data to be written. It then encrypts the data and stores the encrypted data at the addresses designated by the host as well as the key value it generated.
- system 10 Since system 10 maintains a record of the users or application identities and credentials, the key IDs they have access to, and the associated access rights to each of the key IDs, it is possible for system 10 to add or delete key IDs and alter access rights associated with such key IDs for particular users or applications, to delegate access rights from one user or application to another, or even to delete or add records or tables for users or applications, all as controlled by a properly authenticated host device.
- the record stored may specify that a secure channel is required for accessing certain keys. Authentication may be done using symmetric or asymmetric algorithms as well as passwords.
- the portability of the secured content in the memory system 10 Since the key value is generated by the memory system and substantially not available to external systems, when the memory system or a storage device incorporating the system is transferred from one external system to another, security of the content stored therein is maintained, and external systems are not able to access such content unless they have been authenticated in a manner completely controlled by the memory system. Even after being so authenticated, access is controlled by the memory system, and external systems can access only in a manner controlled according to preset records in the memory system. If a request does not comply with such records, the request will be denied.
- the flash memory 20 may have its storage capacity divided into a number of partitions: a user area or partition and custom partitions.
- the user area or partition PO is accessible to all users and applications without authentication. While all bit values of data stored in the user area can be read or written to by any application or user, if the data read is encrypted, the user or application without authority to decrypt would not be able to access the information represented by the bit values stored in a user area.
- files 102 and 104 stored in user area PO. Also stored in the user area are unencrypted files such as 106 which can be read arid understood by all applications and users. Thus, symbolically, the files that are encrypted are shown with locks associated with them such as for files 102 and 104.
- memory 20 also includes protected custom partitions such as partitions Pl and P2 which cannot be accessed without prior authentication. The authentication process permitted in the embodiments in this application is explained below.
- a variety of users or applications may access the files in memory 20.
- users 1 and 2, and applications 1-4 (running on devices) are shown in Fig. 2.
- they are first authenticated by an authentication process in a manner explained below.
- the entity that is requesting access needs to be identified at the host side for role based access control.
- the entity requesting access first identifies itself by supplying information such as "I am application 2 and I wish to read file 1.”
- Controller 12 matches the identity, authentication information and request against the record stored in memory 20 or controller 12. If all requirements are met, access is then granted to such entity.
- user 1 is allowed to read and write to file 101 in partition Pl, but can only read files 102 and 104 in addition to user 1 having unrestricted rights to read from and write to files 106 in PO.
- User 2 is not allowed access to file 101 and 104 but has read and write access to file 102.
- users 1 and 2 have the same login algorithm (AES) while applications 1 and 3 have different login algorithms (e.g. RSA and 001001) which are also different from those of users 1 and 2. Both users 1 and 2 can access files 106 without presenting any credentials and without any restrictions.
- AES login algorithm
- applications 1 and 3 have different login algorithms (e.g. RSA and 001001) which are also different from those of users 1 and 2. Both users 1 and 2 can access files 106 without presenting any credentials and without any restrictions.
- the Secure Storage Application is a security application in the firmware of the memory system 10, and illustrates an embodiment of the invention, which can be used to implement many of the above-identified features.
- SSA may be embodied as software or computer code with database stored in the memory 20 or a non-volatile memory (not shown) in CPU 12, and is read into RAM 12a and executed by CPU 12.
- the acronyms used in reference to the SSA are set forth in the table below:
- Data security, integrity and access control are the major roles of the SSA.
- the data are files that would otherwise be stored plainly on a mass-storage device of some kind.
- the SSA system sits atop of the storage system and adds the security layer for the stored host files.
- the main task of the SSA is to manage the different rights associated with the stored (and secured) content in the memory.
- the memory application needs to manage multiple users and content rights to multiple stored content.
- Host applications from their side see drives and partitions that are visible to such applications, and file allocation tables (FATs) that manage and portray the locations of the stored files on the storage device.
- FATs file allocation tables
- the storage device uses NAND flash chip divided to partitions, although other mobile storage devices may also be used and are within the scope of this invention.
- partitions are continuous threads of logical addresses, where a start and an end address define their boundaries. Restrictions may therefore be imposed on access to hidden partitions, if desired, by means of software (such as software stored in memory 20) that associates such restrictions with the addresses within such boundaries.
- Partitions are fully recognizable to the SSA by their logical address boundaries that are managed by it.
- the SSA system uses partitions to physically secure data from unauthorized host applications. To the host, the partitions are a mechanism of defining proprietary spaces in which to store data files. These partitions can either be public, where anyone with access to the storage device can see and be aware of the partition's presence on the device, or private or hidden, where only the selected host applications have access to and are aware of their presence in the storage device.
- FIG. 3 is a schematic view of a memory illustrating the partitions of the memory: PO, Pl, P2 and P3 (obviously fewer or more partitions than four may be employed), where PO is a public partition which can be accessed by any entity without authentication.
- a private partition (such as Pl, P2 or P3) hides the access to the files within it.
- the flash device e.g. flash card
- the flash device delivers protection of the data files inside the partition. This kind of protection, however, engulfs all of the files residing in the hidden partition by imposing restrictions on access to data stored at the logical addresses within the partition. In other words, the restrictions are associated with a range of logical addresses.
- the SSA system provides another level of security and integrity per file - or groups of files - using keys and key references or Key IDs.
- a key reference or key ID of a particular key value used for encrypting data at different memory addresses can be analogized to a container or domain that contains the encrypted data. For this reason, in Fig. 4, the key references or key IDs (e.g. "key 1" and "key 2”) are shown graphically as areas surrounding the files encrypted using the key values associated with the key IDs.
- File A is accessible to all entities without any authentication, since it is shown as not enclosed by any key ID.
- File B in the public partition can be read or overwritten by all entities, it contains data encrypted with a key with ID "key 1", so that the information contained in File B is not accessible to an entity unless such entity has access to such key.
- key values and key references or Key IDs provide logical protection only, as opposed to the type of protection provided by the partition described above.
- any host that can access a partition public or private
- unauthorized users can only corrupt it. They preferably cannot alter the data without detection or use it.
- this feature can allow only the authorized entities to use the data.
- Files B and C are also encrypted using a key with key ID "key 2" in PO.
- CEK Content Encryption Keys
- the CEKs are generated by the flash device (e.g. flash card), used internally only, and kept as secrets.
- the data that is encrypted or ciphered may also be either hashed or the cipher is chain block to ensure data integrity.
- the CEK are stored in a secure part of the memory not accessible to entities outside the card during normal operations.
- ACR Access Control Record
- ACRs are organized in groups called ACR Groups or AGPs. Once an ACR has successfully authenticated, the SSA system opens a Session through which any of the ACR' s actions can be executed..
- the SSA system manages one or more public partitions, also referred to as the user partition(s).
- This partition exists on the storage device and is a partition or partitions that can be accessed through the standard read write commands of the storage device. Getting information regarding the size of the partition(s) as well as its existence on the device preferably cannot be hidden from the host system.
- the SSA system enables accessing this partition(s) either through the standard read write commands or the SSA commands. Therefore, accessing the partition preferably cannot be restricted to specific ACRs.
- the SSA system can enable the host devices to restrict the access to the user partition. Read and write accesses can be enabled/disabled individually. All four combinations (e.g. write only, read only (write protect), read and write and no access) are allowed.
- the SSA system enables ACRs to associate key IDs with files within the user partition and encrypt individual files using keys associated with such key IDs.
- Accessing encrypted files within the user partitions as well as setting the access rights to the partitions will be done using the SSA command set (refer to Appendix A for detailed description of the SSA commands — In the Appendix, key ID is referred to as "domain” ).
- the SSA system will preferably not allow the host device to access an SSA partition, other than through a session (described below) established by logging onto an ACR. Similarly, preferably the SSA will not provide information regarding the existence, size and access permission of an SSA partition, unless this request is coming through an established session.
- Access rights to partitions are derived from the ACR permissions. Once an ACR is logged into the SSA system, it can share the partition with other ACRs (described below). When a partition is created, the host provides a reference name or ID (e.g. P0-P3 in Figs. 3 and 4) for the partition. This reference is used in further read and write commands to the partition.
- ID e.g. P0-P3 in Figs. 3 and 4
- All available storage capacity of the device is preferably allocated to the user partition and the currently configured SSA partitions. Therefore, any repartition operation may involve reconfiguration of the existing partitions. The net change to the device capacity (sum of sizes of all partitions) will be zero.
- the IDs of the partitions in the device memory space are defined by the host system.
- the host system can either repartition one of the existing partitions into two smaller ones or, merge two existing partitions (which may or may not be adjacent) into one.
- the data in the divided or merged partitions can be either erased or left untouched, at the host's discretion.
- repartitioning of the storage device may cause loss of data (either because it was erased or moved around in the logical address space of the storage device) severe restrictions on repartitioning are administered by the SSA system. Only an ACR residing in a root AGP (explained below) is allowed to issue a repartition command and it can only reference partitions owned by it. Since the SSA system is not aware of how data is organized in the partitions (FAT or other file system structure) it is the host's responsibility to reconstruct these structures any time the device is repartitioned.
- a file When a file is written to a certain hidden partition, it is physically hidden from the general public. But, once an entity (hostile or not) gets knowledge and access to this partition the file becomes available and plain to see. To further secure the file, the SSA can encrypt it in the hidden partition, where the credentials for accessing the key for decrypting the file are preferably different from those for accessing the partition. Due to the fact that files are not something that the SSA is aware of (totally controlled and managed by the host), associating a CEK with a file is a problem. Linking the file to something the SSA acknowledges - the key ID, rectifies this. Thus, when a key is created by the SSA, the host associates the key ID for this key with the data encrypted using the key created by the SSA.
- the key value and key ID provide logical security. All data associated with a given key ID, regardless of its location, is ciphered with the same content encryption key (CEK) whose reference name or key ID is uniquely provided at creation by the host application. If an entity obtains access to a hidden partition (by authenticating through an ACR) and wishes to either read or write an encrypted file within this partition, it needs to have access to the key ID that is associated with the file. When granting access to the key for this key ID, the SSA loads the key value in CEK associated with this key ID and either decrypts the data before sending it to the host or encrypts the data before writing it to the flash memory 20. A key value in CEK associated with a key ID is randomly created once by the SSA system and maintained by it. The key value is entirely managed by the SSA.
- CEK content encryption key
- the SSA system protects the data associated with the key ID using any one (user defined) of the following cipher modes (the actual cryptographic algorithms used, as well as the key values in CEKs, are system controlled and not revealed to the outside world):
- Block mode - Data is divided into blocks, each one of them, encrypted individually. This mode is generally considered less secure and susceptive to dictionary attacks, However, it will allow users to randomly access any one of the data blocks.
- Chained mode - Data is divided into blocks, which are chained during the encryption process. Every block is used as one of the inputs to the encryption process of the next one. This mode, although considered as more secure, requires that the data is always written and read sequentially from start to end, creating an overhead not always acceptable to the users.
- the SSA is designed to handle multiple applications where each one of them is represented as a tree of nodes in the system database. Mutual exclusion between the applications is achieved by ensuring no cross talk between the tree branches.
- the ACR is an individual login point to the SSA system.
- the ACR holds the login credentials and the authentication method.
- the login permissions within the SSA system among which are the read and write privileges.
- Fig. 5 illustrates n ACRs in the same AGP.
- ACR #1 and ACR #n share access to a key with key ID "key 3", where ACR#1 and ACR#n are the ACR IDs, and "key 3" is a key ID for the key that is used to encrypt data associated with "key 3".
- the same key can also be used to encrypt and/or decrypt multiple files, or multiple sets of data.
- the SSA system supports several types of login onto the system where authentication algorithms and user credentials may vary, as may the user's privileges in the system once he logged in successfully.
- Fig. 5 again illustrates different login algorithms and credentials.
- ACR#1 requires a password login algorithm and password as credential
- ACR#2 requires a PKI (public key infrastructure)login algorithm and public key as credential.
- PKI public key infrastructure
- ACRs may share common interests and privileges in the system such as in keys with which to read and write. To accomplish that, ACRs with something in common are grouped in AGPs - ACR Groups. Thus, ACR #1 and ACR
- AGPs and, the ACRs within are organized in hierarchical trees and so aside from creating secure keys that keep sensitive data secure; an ACR can preferably also create other ACR entries that correspond to his key ID/partitions. These ACR children will have the same or less permissions as their father - creator and, may be given permissions for keys the father ACR himself created. Needless to add, the children ACRs get access permissions to any key that they create. This is illustrated in Fig. 6. Thus, all of the ACRs in AGP 120 were created by ACR 122 and two of such ACRs inherit from ACR 122 permission(s) to access to data associated with "key 3".
- Logging onto the SSA system is done by specifying an AGP and an
- Every AGP has a unique ID (reference name), which is used as an index to its entry in the SSA database.
- the AGP name is provided to the SSA system, when the AGP is created. If the provided AGP name already exists in the system, the SSA will reject the creation operation.
- AGPs are used to administer restrictions on delegation of access and management permissions as will be described in the following sections.
- One of the functions served by the two trees in Fig. 6 is to administer the access by entirely separate entities, such as two different applications, or two different computer users.
- the SSA system when the SSA system is used in memory 10, this allows the memory system 10 to serve multiple applications simultaneously. It also allows the two applications to access two separate sets of data independently of one another (e.g.
- the data associated with "keys 3", “key X" and “key Z" for the application or user accessing via nodes (ACRs) in the tree in the top portion of Fig. 6 may comprise photographs.
- the data associated with "key 5" and "key Y” for the application or user accessing via nodes (ACRs) of the tree in the bottom portion of Fig. 6 may comprise songs.
- the ACR that created the AGP has the permission to delete it preferably only when the AGP is empty of ACR entries.
- An ACR in the SSA system describes the way the entity is permitted to log into the system. When an entity logs into the SSA system it needs to specify the ACR that corresponds to the authentication process it is about to perform.
- An ACR includes a Permissions Control Record (PCR) that illustrates the granted actions the user can execute once authenticated as defined in the ACR illustrated as in Fig. 5.
- PCR Permissions Control Record
- the host side entity provides all of the ACR data fields.
- an SSA system entity initiates the login process it needs to specify the ACR ID (as provided by the host when the ACR was created) that corresponds to the login method so that the SSA will set up the correct algorithms and select the correct PCR when all login requirements have been met.
- the ACR ID is provided to the SSA system when the ACR is created.
- the authentication algorithm specifies what sort of login procedure will be used by the entity, and what kind of credentials are needed to provide proof of user's identity.
- the SSA system supports several standard login algorithms, ranging from no procedure (and no credential) and password-based procedures to a two-way authentication protocols based on either symmetric or asymmetric cryptography.
- the entity's credentials correspond to the login algorithm and are used by the SSA to verify and authenticate the user.
- An example for credential can be a password/PIN-number for password authentication, AES-key for AES authentication, etc.
- the type/format of the credentials i.e. the PIN, the symmetric key, etc..
- the SSA system has no part in defining, distributing and managing these credentials, with the exception of PKI based authentication where the device (e.g. flash card) can be used to generate the RSA key pair and the public key can be exported for certificate generation.
- the PCR shows what is granted to the entity after logging into the SSA system and passing the ACR' s authentication process successfully.
- permission categories There are three types of permission categories: Creation permissions for partition and keys, Access permissions to partitions and keys and management permissions for Entity-ACR
- This section of the PCR contains the list of partitions (using their IDs as provided to the SSA system) the entity can access upon completing the ACR phase successfully.
- the access type may be restricted to write-only or read-only or may specify full write/read access rights.
- the ACR#1 in Fig. 5 has access to partition Wl and not partition #1.
- the restrictions specified in the PCR apply to the SSA partitions and the public partition.
- the public partition can be accessed either by regular read and write commands to the device (e.g. flash card) hosting the SSA system, or by SSA commands.
- the device e.g. flash card
- SSA commands e.g. a root ACR (explained below)
- An ACR can preferably only restrict the regular read and write commands from accessing the public partition.
- ACRs in the SSA system can be restricted preferably only upon their creation. Once an ACR has the permission to read/write from/to the public partition, preferably it cannot be taken away.
- This section of the PCR contains the data associated with the list of key IDs (as provided to the SSA system by the host) the entity can access when the ACR policies have been met by the entity's login process.
- the key ID specified is associated with a file/files that reside in the partition appearing in the PCR. Since the key IDs are not associated with logical addresses in the device (e.g. flash card), when more than one partition is associated with a specific ACR, the files can be in either one of the partitions.
- the key IDs specified in the PCR can have each, a different set of access rights. Accessing data pointed to by key IDs can be restricted to write-only or read-only or may specify full write/read access rights.
- ACR Attributes Management (ACAM)
- ACAM actions that may be permitted in the SSA system are:
- a father ACR preferably cannot edit ACAM permissions. This would preferably require the deletion and recreation of the ACR. Also the access permission to a key ID created by the ACR can preferably not be taken away.
- An ACR may have the capacity to create other ACRs and AGPs.
- Creating ACRs also may mean delegating them some or all of the ACAM permissions possessed by their creator. Having the permission to create ACRs means having the permission for the following actions:
- the authentication method preferably cannot be edited once set by the creating ACR.
- the credentials may be altered within the boundary of the authentication algorithm that is already defined for the child.
- An ACR with the permissions to create other ACRs has the permission to delegate the unblocking permission to ACRs it creates (although it probably does not have the permission to unblock ACRs). The father ACR will place in the child ACR a reference to his unblocker.
- ACR The father ACR is the only ACR that has the permission to delete his child ACR.
- ACR deletes a lower level ACR that he created, then all ACRs spawned by this lower-level ACR are automatically deleted as well.
- ACR is deleted then all the key IDs and partitions that it created are deleted.
- Passwords/PINs although set by the creator ACR, can be updated only by the ACR that includes them.
- a root ACR may delete itself and the AGP that it resides in.
- ACRs and their AGPs are assembled in hierarchical trees where the root AGP and the ACRs within are at the top of the tree (e.g. root AGPs 130 and 132 in Fig. 6). There can be several AGP trees in the SSA system though they are totally separated from one another.
- An ACR within an AGP can delegate access permissions to its keys to all ACRs within the same AGP that it is in, and to all the ACRs created by them.
- the permission to create keys preferably includes the permission to delegate access permissions to use the keys.
- the permission to delegate access rights may be stored as an attribute in the permission control record of the corresponding ACR.
- Access - this defines the access permissions for the key i.e. Read, Write.
- Ownership an ACR that created a key is by definition its owner. This ownership can be delegated from one ACR to another (provided that they are in the same AGP or in a child AGP). An ownership of a key provides the permission to delete it as well as delegate permissions to it. 3. Access Rights Delegation - this permission enables the ACR to delegate the rights he holds.
- An ACR can delegate access permissions to partitions he created as well as other partitions he has access permissions to.
- the permission delegation is done by adding the names of the partitions and key IDs to the designated ACR' s PCR.
- Delegating key access permissions may either be by the key ID or by stating that access permission is for all of the created keys of the delegating ACR.
- An ACR may have a blocking counter which increments when the entity's ACR authentication process with the system is unsuccessful. When a certain maximum number (MAX) of unsuccessful authentications is reached, the ACR will be blocked by the SSA system.
- MAX maximum number
- the blocked ACR can be unblocked by another ACR, referenced by the blocked ACR.
- the reference to the unblocking ACR is set by its creator.
- the unblocking ACR preferably is in the same AGP as the creator of the blocked ACR and has the "unblocking" permission.
- An ACR may be configured with a blocking counter but without an unblocker ACR. In this case, if this ACR get blocked it cannot be unblocked.
- the SSA system is designed to handle multiple applications and isolate the data of each one of them.
- the tree structure of the AGP system is the main tool used to identify and isolate application specific data.
- the root AGP is at the tip of an application SSA database tree and adheres to somewhat different behavior rules.
- Several root AGPs can be configured in the SSA system. Two root AGPs 130 and 132 are shown in Fig. 6. Obviously fewer or more AGPs may be used and are within the scope of this invention.
- Registering the device e.g. flash card
- Registering the device for a new application and/or issue credentials of a new applications for the device are done through the process of adding new AGP/ACR tree to the device.
- the SSA system supports three different modes of root AGP creation
- Open Any user or entity without requiring any sort of authentication, or users/entities authenticated through the system ACR (explained below), can create a new root AGP.
- the open mode enables creation of root AGPs either without any security measures while all data transfer is done on an open channel (i.e. in the secure environment of an issuance agency) or, through a secure channel established through the system ACR authentication (i.e. Over The Air (OTA) and post issuance procedures).
- OTA Over The Air
- Method configuration command Used to configure the SSA system to use any one of the three root AGP creation modes. Only the following mode change are allowed: Open -> Controlled, Controlled -> Locked (i.e. if the SSA system is currently configured as Controlled, it can only be changed to locked)
- Method configuration lock command Used to disable the method configuration command and permanently lock the currently selected method.
- root AGP Once a root AGP is put in standard mode it can be deleted only by logging into the system through one of its ACRs that is assigned with the permission to delete the root AGP. This is another exception of root AGP, in addition to the special initialization mode; it is preferably the only AGP that may contain an ACR with the permission to delete its own AGP, as opposed to AGPs in the next tree level.
- the third and last difference between a root ACR and a standard ACR is that it is the only ACR in the system that can have the permission to create and delete partitions.
- the system ACR may be used for the following two SSA operations:
- Identify and authenticate the device hosting the SSA system There may preferably be only one System ACR in the SSA and once defined it preferably cannot be changed. There is no need for system authentication when creating the System ACR; only a SSA command is needed.
- the create-system- ACR feature can be disabled (similarly to the create-root-AGP feature). After the system ACR is created, the create-system-ACR command has no effect, since preferably only one System ACR is allowed.
- the System ACR creates the root ACR/AGP in the SSA. It has permission to add/change the root level until such time that the host is satisfied with it and blocks it. Blocking the root AGP essentially cuts off its connection to the system ACR and renders it temper proof. At this point no one can change/edit the root AGP and the ACRs within. This is done through an SSA command. Disabling creation of root AGPs has a permanent effect and cannot be reversed. The above features involving the system ACR are illustrated in Fig. 7. The system ACR is used to create three different root AGPs.
- the SSA command is sent from the host to block the root AGPs from the system ACR, thereby disabling the create-root-AGP feature, as indicated by the dotted lines connecting the System ACR to the root AGPs in Fig. 7. This renders the three root AGPs temper proof.
- the three root AGPs may be used to create children AGPs to form three separate trees, before or after the root AGPs are blocked.
- Issuance is the process of putting identification keys by which the device can identify the host and vice versa. Identifying the device (e.g. flash card) enables the host to decide whether it can trust its secrets with it. On the other hand, identifying the host enables the device to enforce security policies (grant and execute a specific host command) only if the host is allowed to.
- Products that are designed to serve multiple applications will have several identification keys.
- the product can be "pre-issued” - keys stored during manufacturing before shipping, or "post issued” - new keys are added after shipping.
- the memory device e.g. memory card
- the memory device needs to contain some kind of master or device level keys which are being used to identify entities which are allowed to add applications to the device.
- the above described features enables a product to be configured to enable/disable post issuance.
- the post issuance configuration can be securely done after shipping.
- the device may be bought as a retail product with no keys on it in addition to the master or device level keys described above, and then be configured by the new owner to either enable further post issuance applications or disable them.
- system ACR feature provides the capability to accomplish the above objectives:
- - Memory devices with no system ACR will allow unlimited and uncontrolled addition of applications.
- - Memory devices without system ACR can be configured to disable the system ACR creation, which means there is no way to control adding of new applications (unless the feature of creating new root AGP is disabled as well)
- - Memory devices with system ACR may be configured to disable the application adding feature, before or after applications have been added.
- Key IDs are created per specific ACR request; however, in the memory system 10, they are used solely by the SSA system. When a key ID is created the following data is provided by or to the creating ACR:
- the ID is provided by the entity through the host and is used to reference the key and data that is encrypted or decrypted using the key in all further read or write accesses.
- Key ID Owner The ID of the ACR that is the owner. When a key ID is created the creator ACR is its owner. Key ID ownership may, however, be transferred to another ACR. Preferably only the key ID owner is allowed to transfer ownership of, and delegate, a key ID. Delegating access permission to the associated key, and revoking these rights can be administered either by the key ID owner or any other ACR assigned with delegation permissions. Whenever an attempt is made to exercise any one of these operations, the SSA system will grant it only if the requesting ACR is authorized.
- CEK This is the CEK used to cipher the content associated with or pointed to by the key ID.
- the CEK may be a 128 bit AES random key generated by the SSA system.
- MAC and IV values Dynamic information (message authentication codes and initiation vectors) used in the Chained Block Cipher (CBC) encryption algorithms.
- ⁇ ' to the left of a step means the operation is performed by the host
- 'C means the operation is performed by the card.
- the host issues to the SSA in the memory device 10 a command to create System ACR (block 202).
- the device 10 responds by checking whether a System ACR already exists (block 204, diamond 206). If it already exists, then device 10 returns failure and stops (oblong 208). K it does not, then memory 10 checks to see if System ACR creation is allowed (diamond 210), and returns a failure status if not allowed (block 212).
- the device issuer does not allow the creation of a System ACR, such as in the case where the security features needed have been predetermined so that no System ACR is needed. If this is allowed, the device 10 returns OK status and waits for System ACR credentials from the host (block 214). The host checks the SSA status and whether the device 10 has indicated that the creation of a System ACR is allowed (block 216 and diamond 218). If creation is not allowed or if a system ACR already exists, the host stops (oblong 220). If the device 10 has indicated that the creation of a System ACR is allowed, the host issues a SSA command to define its login credential and sends it to the device 10 (block 222).
- the device 10 updates a System ACR record with the credential received and returns OK status (block 224).
- the host issues SSA command indicating the system ACR is ready (block 226).
- the device 10 responds by locking the System ACR so that it cannot be updated or replaced (block 228). This locks in the features of the system ACR and its identity for identifying the device 10 to the host.
- system ACR does exist, the host may use it even if it is not required (not shown in the flow chart).
- the device e.g. flash card
- the newly created AGP and ACR in block 254 are now switched to Operational Mode so that the ACRs in such AGPs cannot be updated or otherwise changed, and no ACRs can be added to them (block 256).
- the system is then, optionally locked so that additional root AGPs cannot be created (block 258).
- the dotted line box 258 is a convention indicating that this step is an optional step. All the boxes in the flow charts of the figures of this application in dotted lines are optional steps. This allows the content owner to block the use of device 10 for other illicit purposes that may imitate a genuine memory device with legitimate content.
- ACRs other than the ACRs in the root AGP as described above
- An entity may attempt to enter through the host 24 by providing the entry point ACR identity, and the ACR with all the necessary attributes that it wishes to create (block 272).
- the SSA checks for a match to the ACR identity and whether the ACR with such identity has the permission to create an ACR (diamond 274). If the request is verified to be authorized, the SSA in device 10 creates an ACR (block 276).
- Fig. 11 shows two AGPs that illustrate a tree useful in security applications using the method of Fig. 10.
- the ACR with identity ml in the marketing AGP has the permission to create an ACR.
- the ACR ml also has the permission to use a key for reading and writing data associated with the key ID "Marketing Information" and data associated with the key ID "Price List”.
- Using the method of Fig. 10 it creates the Sales AGP with two ACRs: si and s2 with only read permission to the key for accessing pricing data associated with the key ID "Price List", but not to the key necessary for accessing data associated with the key ID "Marketing Information”.
- the ACR m2 has no permission to create ACRs, and has only read permission to the keys for accessing data associated with the key ID "Price List" and with the key ID "Marketing Information”.
- access rights may be delegated in the manner explained above where ml delegates rights to read pricing data to si and s2. This is particularly useful where large marketing and sales groups are involved. Where there are but one or a few sales people, there may be no need to use the method of Fig. 10. Instead, the access rights may be delegated, by an ACR to one at a lower or the same level within the same AGP, as illustrated in Fig. 12. First, the entity enters the tree for such AGP by specifying an ACR in the manner described above in the tree through the host (block 280). Next the host will specify the ACR and the rights to delegate to.
- the SSA checks the tree(s) for such ACR and whether the ACR has the permission to delegate rights to the specified another ACR (diamond 282). If it does, the rights are delegated (block 284); if not it stops. The result is illustrated in Fig. 13.
- the ACR ml in this case has the permission to delegate read permission to the ACR si, so that si will be able to use a key to access pricing data after the delegation. This may be performed if ml has the same or greater rights to access pricing data and the permission to so delegate. In one embodiment, ml retains its access rights after the delegation. Preferably access rights may be delegated under restricted conditions (rather then permanently) such as for a limited time, limited number of accesses, etc.
- the process for creating a key and key ID is illustrated in Fig. 14.
- the entity authenticates through an ACR (block 302).
- the entity requests the creation of a key with an ID specified by the host (block 304).
- the SSA checks and see if the ACR specified has the permission to do so (diamond 306). For example, if the key is to be used for accessing data in a particular partition, the SSA will check and see if the ACR may access such partition.
- the memory device 10 creates a key value associated with the key ID provided by the host (block 308), ands stores the key ID in the ACR, and the key value in its memory (either in the controller-associated memory or memory 20) and assigns rights and permissions according to information supplied by the entity (block 310) and modifies the PCR of such ACR with such assigned rights and permissions (block 312).
- the creator of the key has all available rights, such as read and write permissions, right to delegate and share with other ACRs in the same AGP or an ACR at a lower level, and the right to transfer ownership of the key.
- An ACR can change the permissions (or the existence altogether) of another ACR in the SSA system as illustrated in Fig. 15.
- An entity may enter a tree through an ACR as before; in one case the entity is authenticated and then it specifies an ACR (blocks 330, 332). It requests the deletion of a target ACR or the permission in a target ACR (block 334). If the ACR specified or the one active at such time has the right to do so (diamond 336), the target ACR is deleted, or the PCR of the target ACR is altered to delete such permission (block 338). If this is not authorized the system stops.
- an entity may attempt to enter at the target ACR (block 350) and finds that the authentication process fails, since the previously existing ACR ID is no longer present in the SSA, so that access rights are denied (diamond 352). Assuming that the ACR ID has not been deleted, the entity specifies an ACR (block 354) and the key ID and/or data in a particular partition (block 356), and the SSA then checks to see the key ID or partition access request is permitted according to the PCR of such ACR (diamond 358). If the permission has been deleted or has expired, then the request is again denied. Otherwise, the request is granted (block 360).
- the above process describes how access to protected data is managed by the device (e.g. flash card), regardless of whether the ACR and its PCR were just changed by another ACR or were so configured to begin with.
- the device e.g. flash card
- the SSA system is designed to handle multiple users, logged in concurrently. This feature requires that every command received by the SSA is associated with a specific entity and executed only if the ACR, used to authenticate this entity, has the permissions for the requested action.
- a session is established during the authentication process and assigned a session-id by the SSA system.
- the session-id is internally associated with the ACR used for logging into the system and is exported to the entity to be used in all further SSA commands.
- the SSA system supports two types of sessions: Open, and Secure sessions.
- the session type associated with a specific authentication process is defined in the ACR.
- the SSA system will enforce session establishment in a way similar to the way it enforces the authentication itself. Since the ACR defines the entity permissions, this mechanism enables system designers to associate secure tunneling either with accessing specific key IDs or invoking specific ACR management operations (i.e. creating new ACRs and setting credentials)
- Open session is a session identified with a session-id but without bus encryption, all commands and data are passed in the clear. This mode of operation is preferably used in a multi-user or multi-entity environment where the entities are not part of the threat model, nor is eavesdropping on the bus.
- the Open session mode enables the SSA system to allow access only to the information allowed for the currently authenticated ACRs.
- the Open session can also be used for cases where a partition or a key needs to be protected. However, after a valid authentication process, access is granted to all entities on the host. The only thing the various host applications need to share, in order to get the permissions of the authenticated ACR is the session-id. This is illustrated in Fig. 17A. The steps above the line 400 are those taken by the host 24. After an entity is authenticated (block 402) for ACRl, it requests access to a file associated with a key ID X in the memory device 10 (blocks 404, 406 and 408). If the PCR of the ACR 1 allows such access, device 10 grants the request (diamond 410). If not, the system returns to block 402.
- the memory system 10 identifies the entity issuing a command only by the assigned session id (and not the ACR credentials). Once the ACR 1 gains access to the data associated with the key IDs in its PCR, in an open session, any other application or user can access the same data by specifying the correct session ID which is shared between the different applications on the host 24.
- This feature is advantageous in applications where it is more convenient to the user to be able to log in only once, and be able to access all the data tied to the account through which the log in is performed for different applications.
- a cellular phone user may be able to access stored emails, and listen to stored music in memory 20 without having to log in multiple times.
- data not encompassed by the ACRl will not be accessible.
- the same cellular phone user may have valuable content such as games and photographs accessible through a separate account ACR2.
- This is data that he does not wish others who borrow his phone to access, even though he may not mind others accessing data available through his first account ACRl.
- Separating access to the data into two separate accounts while allowing access to ACRl in open session provides ease of use as well as affording protection of valuable data.
- the session id may be used as shown in Fig.
- the memory 10 then also stores the session ids of the active sessions.
- the entity in order to be able to access a file associated with key ID X, the entity will need to also provide a session id, such as session id "A" before it is allowed to access the file (blocks 404, 406, 412 and 414). In this manner, unless the requesting entity is aware of the correct session id, it cannot access the memory 10. Since the session id is deleted after the session is over and will be different for each session, an entity can gain access only when it has been able to provide the session number.
- the SSA system has no way to make sure that a command is really coming from the correct authenticated entity, other than by using the session number.
- the host application uses a secure session (a secure channel).
- the session-id is encrypted with the secure channel encryption (session) key and the security level is as high as the host side implementation.
- a session is terminated and, the ACR is logged off, in any one of the following scenarios:
- the entity issues an explicit end-session command.
- the SSA system verifies the integrity of the SSA database (which contains all the ACRs, PCRs, etc.). In addition data integrity services are offered for entity data through the key ID mechanism.
- Hash values are stored along side with the CEK and IV in the CEK record. Hash values are calculated and stored during write operation. Hash values are again calculated during read operations and compared with the values stored during the previous write operations. Every time the entity is accessing the key ID the additional data is concatenated (cryptographically) to the old data and the appropriate Hash value (for read or for write) updated. [0D ⁇ 77] Since only the host knows the data files associated with or pointed to by a key ID, the host explicitly manages several aspects of the data integrity function in the following manner:
- a data file associated with or pointed to by a key ID is written or read from the beginning to end. Any attempt to access portions of the file will mess it up since the SSA system is using a CBC encryption method and generates a hashed message digest of the entire data
- the SSA system provides a "dummy read” operation as well. This feature will stream the data through the encryption engines but will not send it out to the host. This feature can be used to verify data integrity before it is actually read out of the device (e.g. flash card).
- the SSA system will enable external entities to make use of the internal random number generator and request random numbers to be used outside of the SSA system. This service is available to any host and does not require authentication.
- the SSA system will enable external users to make use of the internal
- Fig. 18 illustrates an environment in which the above-described memory device 10 may be used for storing media content securely and for delivering the media content stored therein in a controlled manner.
- the media content in device 10 may be rendered by a variety of different end user terminals or hosts, including personal digital assistants, video game machines, cellular telephone handsets 502, media players such as MP3 players 506, and computers 508 such as desktop, notebook, or laptop computers.
- New avenues for media content distribution may be achieved using device 10 by service providers such as MNOs 504.
- MNO 504 may supply media content to device 10 through handsets 502.
- rights and/or rules may be downloaded from operator 504 to handsets 502 in order to access the media contents stored in device 10.
- the rights and/or rules governing access to the encrypted media content in device 10 could also apply even when the media content in device 10 is accessed not by handsets 502, but by other types of terminals such as media player 506 and computer 508.
- device 10 may instead receive such content and rights and/or rules through other servers such as the account management server 510 and computer 508 through the internet. Such content and rights and/or rules may be provided to computer 508 and server 510 by operator 504.
- FIG. 19A An avenue for distributing media content using a memory device pre-loaded with purchased content is illustrated in Fig. 19A. While a flash memory card is used as the example in Figs. 19A-19D, it will be understood that the same considerations will apply to formats other than cards and other types of non-volatile rewritable memories as well.
- a flash memory card manufacturer CM sells the card to a Content Issuer CI, who also buys media content from a content provider CP and receives the rights object(s) for controlling such content from a rights objects (RO) server.
- the CI Before such content and rights object(s) are loaded to the card, the CI first verifies whether the card is genuine by connection to an authentication server. The content and rights object(s) are loaded after the card has been verified to be genuine.
- Issuer has two branches: one pointing upwards to the Service Provider SP and the lower arrow pointing to the End User EU.
- the CI sells the card with content either directly to the end user EU along the lower arrow between CI and EU in Fig. 19A, or to a service provider SP along the upper arrow between CI and SP. The transaction along the upper arrow will now be described.
- the Content Issuer which may also be card manufacturer CM, sells the card to the Service Provider, such as a MNO.
- the Service Provider then sells the card together with an End User terminal such as a cellular phone handset provided by an Original Equipment Manufacturer (referred to hereinafter as "OEM") to an End User.
- OEM Original Equipment Manufacturer
- Figs. 19A - 19D an arrow with a dollar sign next to it indicates a possible flow of revenue between the parties along the direction of the arrow shown in the figures.
- the Content Issuer may install control structures of the type described herein.
- control structures are installed by the Service Provider as described below to enable the Service Provider to create its own secure environment so that it can control content distribution in the way it deems fit.
- the card is again verified to be genuine.
- the card is again authenticated by connecting to the authentication server.
- the card is also connected via a terminal to an authorization server to enable or activate any particular features or applications (e.g. media content rendering applications such as media players) in the card.
- the Service Provider then installs a control structure of the type described below to control access to the content in the card.
- the control structure will ensure that only authorized users may be able to access the content, and such access will comply with certain permissions in the control structure or with certain rights and/or rules.
- the Content Issuer may sell the card directly to the End User.
- the End User obtains a terminal such as a cellular phone handset from an OEM. Provided that such terminal and the card can mutually authenticate, such as in a manner described below, the End User will then be able to access the content in the card using the terminal.
- a terminal such as a cellular phone handset from an OEM.
- the End User will then be able to access the content in the card using the terminal.
- One process of mutual authentication is explained below.
- the above avenue for media distribution is one where the card contains only content already purchased by the End User.
- the End User is provided with the required authentication information such as credentials for accessing the content. This will prevent others who are not provided with such authentication means to access the content in an unauthorized manner.
- Fig. 19B is a flow diagram illustrating another avenue for media content distribution to illustrate another embodiment of the invention.
- the steps whereby content is installed in the card and by which the card reaches the End User are similar to those in Figs. 19A.
- the scheme in Fig. 19B differs from that of Fig. 19A in that the content loaded into the card can only be rendered with certain restrictions for preview purposes (e.g. accessing for rendering a portion or lower quality version of the content, or only for limited number of times or duration), instead of being able to render with no restrictions as in the scheme of Fig. 19A .
- the End User wishes to enjoy the media content fully, he or she will have to first purchase the right to access and render unabridged versions of such media content without restrictions instead of being content with their previews. Thus after the purchase, the End User may then access and render without restrictions the full unabridged versions of the media content from the Service Provider. Before the End User is allowed to download the appropriate rights for such purpose, however, the card is again verified to be genuine by means of the authentication server. After such authentication, the Rights Issuer then provides the control structure such as a rights object to the Service Provider, who in turn provides the same to the End User for downloading.
- the rights object may comprise credentials for the End User (or other entities such as applications on hosts) to access encrypted media content, and rights and/or rules governing such access.
- the rights object may contain the actual content encryption keys that can be used to decrypt the encrypted media content.
- the credentials in the rights object may be ones that are generated on the fly using a secret code and the memory device ID as seed values by means of a function such as a hash function. This scheme can also be applied even where the rights object does not contain the actual content encryption keys.
- the End User may also have the option to upgrade the preloaded content during the purchase, such as by downloading the high quality unabridged version of the preview content.
- such content may also include encrypted unabridged versions of the media content.
- the cards will have already stored the encrypted versions of the media content he or she wishes to purchase.
- the cards will also have stored therein rights and/or rules that restrict the end users rights to access only the abridged versions or portions of the content in the cards. In such circumstances, there is no need to download such content to the card again. Instead, all the End User will need are the content encryption keys for decrypting the media content and an update to the rights and/or rules governing such access to permit unrestricted or more relaxed access.
- Such information will be downloaded from the Rights Issuer through the Service Provider after authentication.
- Fig. 19C is a flow diagram illustrating yet another avenue for media content distribution.
- a comparison of Fig. 19A and 19C will reveal that the two schemes are substantially the same, except that in the scheme of Fig. 19C, the content in the card can be accessed by the End User only after the End User subscribes to a service, such as a service provided by the Service Provider.
- the card purchased by the End User will contain control information which does not allow the End User to access the content until the End User has subscribed.
- the End User may first purchase the card from the Content Issuer, but will not be able to access the media content therein until he or she has purchased a subscription from the Service Provider.
- the card in the End User's possession is verified to be genuine by the authentication server and the applications (e.g. media content rendering applications such as media players) therein optionally enabled or activated by the authorization server.
- the rights object provided by the Rights Issuer is then transmitted by the Service Provider to the End User for downloading to the card. Since the transaction is subscription based, the End User will need to pay for the subscription periodically so that the flow of revenue will be recurring from the End User to the Rights Issuer through the Service Provider.
- Fig. 19D is a flow diagram illustrating another avenue for media content distribution.
- the card purchased by the End User will have no pre-loaded media content.
- the End User will have to purchase the content from the Service Provider who in turn obtains content from the content provider server.
- the card is authenticated by the authentication server.
- Features and applications e.g. media content rendering applications such as media players
- the authorization server As part of the transaction, a rights object originating from the Rights Issuer is transmitted through the Service Provider to the End User for download to the card. This transaction may be subscription based so that the End User will have to periodically pay the Rights Issuer and the Service Provider.
- the card purchased by the End User may have no pre-loaded media content
- the card may have rights object(s) stored therein which entitle the End User to download such content. This is then a prepaid media content card, which enables the End User to repeatedly download content purchased.
- Fig. 20 is a block diagram of one embodiment of memory device 10 where different functions are stored in different areas of the device.
- device 10 has a content area which stores secured operator content, such as encrypted content associated or owned by an MNO, such as operator 504 of Fig. 18.
- secured operator content such as encrypted content associated or owned by an MNO, such as operator 504 of Fig. 18.
- Stored in the content area is also encrypted and/or unencrypted preloaded content described in more detail below.
- Also stored in the content area may be user content that is not restricted, as well as user content that is restricted and locked, such as by means of encryption.
- Security area of device 10 may contain a number of different functions implemented by software codes, such as the DRM agents described in more detail below. Security area of device 10 may be implemented using the hidden partitions described above. Content encryption keys, certificates, and an authorization manager may also be stored in the security area. Control structures such as AGP/ACR described above may form part of the authorization manager. Also stored in the security area are applications and management structures for MNO operators. In a communications area, device 10 stores a handset abstraction and server agent. These may be useful where device 10 is operated by a handset.
- Fig. 21 is a block diagram of a system architecture used for implementing the different media content distribution schemes of Figs. 19A - 19D.
- memory device 10 comprises a secure store which preferably utilizes the above-described features of hidden partitions and encryption using content encryption keys with access control records (ACRs) or rights objects ("RO") as possible embodiments.
- Device 10 also includes an access manager (which can include or be a part of the DRM agent stored in the security area of the device), which can interface with different digital rights management (DRM) agents now in use commercially. These include, for example, mobile DRM agents commonly used in handsets for cellular phones and the Windows 32 DRM agent now commonly used on personal computers.
- DRM digital rights management
- the access manager of device 10 can interface with different types of DRM agents in the End User terminals for the purpose of downloading content and rights objects (or updating rights objects) as well as altering the permissions in the access control records or rights objects in device 10.
- Figs. 19A - 19D the architecture of Fig. 21 implements such download by first passing the media content from the content server 522 to the DRM server 524.
- the content server 522 may be situated at a Service Provider which receives the content from the content provider server. Alternatively, if the media content is downloaded from the content provider directly without going through the Service Provider, the content server 522 may be located at a content provider's facility.
- DRM server 524 is in communication with payment servers 526 which manage payment to the MNOs and other entities for media content downloads through handsets, personal computers and other terminals as described above in reference to Figs. 18 and 19A- 19D.
- the DRM server 524 transmits rights objects and the media content from content server 522 to a terminal (handset 528 or personal computer 530 in Fig. 21).
- the DRM agent 528a or 530a then transmits the media content and rights objects to the access manager of device 10 where the access manager then stores such media content in a partition in device 10.
- the rights objects may be obtained by server 524 from the Rights Issuer not shown in Fig. 21.
- the DRM agents and the access manager may alter or update rights objects (e.g. after purchase of new or additional rights) already stored in device 10.
- control structures such as ACRs, AGPs and ROs
- the processes described herein where media content and rights objects are transmitted or altered are preferably performed via a secure session of the type described above using a session key.
- the credentials or other authentication information as well as decrypted media files may be encrypted with session keys before they are transmitted.
- other types of control structures such as ACRs, AGPs and hierarchical trees are created or altered in the memory device through a terminal in communication with a server.
- the access manager in device 10 includes a DRM agent which is able to interface and directly handle commands from DRM server 524, so that even if the End User terminals, such as handset 528 and computer 530, do not include a DRM agent, the access manager of device 10 will still be able to implement the above-described functions, such as the installation or alteration of control structures and the downloading of media content and rights objects.
- Fig. 22 is a block diagram illustrating a memory device containing paid media content and unpaid catalog media content to illustrate one possible avenue for distributing media contents.
- content including paid media content and unpaid catalog media content may be loaded into the memory device 10 so that the memory device containing such content is labeled 10" in Fig. 22.
- a corresponding rights object for controlling access to the paid content As illustrated in Fig. 22, in one implementation, the rights object permits unlimited access to the paid content via a terminal such as a cellular phone handset or personal computer, but only permits moving the content to a personal computer library three times, which may be an optional feature. Alternatively, the optional feature may be that whoever has the appropriate credentials will be able to export the paid media content by means of a software application operating in the terminal to other terminals for storage for only up to three times.
- the purchaser's rights can be limited or abridged in a number of different ways.
- the right to preview the catalog media content may be limited by time duration or by the number of times or count.
- only a selected portion (e.g., 15 seconds of a song or video) of the media title can be accessed without restriction, or what can be accessed is only a lower quality version.
- the rights purchased can be to a single media content file or an entire album of content files. In the embodiment illustrated in Fig.
- the full unabridged versions of the media titles cataloged are actually stored in device 10" but are encrypted so that the purchasers would not be able to access the full unabridged versions of the media titles.
- the media content file that is purchased is then unlocked to permit access by the purchaser.
- the full unabridged versions of the media titles cataloged in device 10" are not already stored in device 10".
- the purchaser purchases the rights for full access such media titles would then have to be downloaded, such as in the manner described above, along with the rights object for controlling the access to such titles.
- the content unlocking process involving device 10" is illustrated in the flow charts of Figs. 23A-23C. While a flash memory card is used as the example in Figs. 23A-23C, it will be understood that the same considerations will apply to formats other than cards and other types of non-volatile rewritable memories as well.
- the rendering device such as a terminal, responds to the End User's request to access a sample of restricted media content, such as encrypted media content cataloged in the device 10" (Block 552).
- Device 10 such as a flash memory card, responds to such request and provides to the rendering device or terminal the requested media sample (Block 554).
- the media sample file preferably contains information concerning the Internet address of a server from which the right to unlock can be purchased, such as the address of a Service Provider's server, as illustrated in reference to Figs. 19A - 19D or a DRM server as in Fig. 21.
- the rendering device plays or renders, by means of a software application operating in the device, the media sample from the flash card 10", prompts the user to purchase unrestricted rights to the media title sampled and provides the Internet address information of the server for handling the purchasing for the user.
- the rendering device or terminal queries the user as to whether the user wishes to purchase the rights to unlock the full unabridged media title that has been sampled (Block 556). If the user responds that he or she does not wish to purchase, the process ends. However if the user indicates a desire to purchase, the rendering device or terminal then connects to the server for handling the purchase in response to the user command (Block 558). The rendering device or terminal then sends the user purchase authorization inputted by the user and other user information to the server (SP server or DRM server) (Block 560).
- the server SP server or DRM server
- the rights object may contain content encryption keys and authentication information requiring the presentation of appropriate credentials before access to such keys can be granted, and rights and/or rules in regard to how the decrypted media files or titles can be used.
- no rights object is stored for any one of the catalog media titles in device 10". In such circumstances, the rights object for decrypting and controlling the catalog media titles would have to be downloaded, such as from the SP server or the DRM server.
- device 10" may already contain rights objects that would permit only restricted previewing of the catalog media titles.
- the catalog abridged media titles that can be previewed may be stored as separate files from the locked catalog unabridged encrypted media titles.
- the preview media titles may consist of portions (e.g., 15 seconds worth) of the full media title, or a lower quality version of such title.
- the preview media titles are not stored in separate files, where only a portion or a degraded version of the locked catalog encrypted media titles is made available without restriction for preview.
- Preview media titles may also comprise the full length catalog media title, but where previewing is limited by either time duration or count. The above described restrictions are imposed by the rights object already stored in device 10".
- the rendering device or terminal would cause (e.g., by means of the DRM agent) the rights object downloaded to be stored in the security area of device 10" in the case where device 10" does not already have a rights object, or would cause the rights object already in device 10" to be updated, thereby permitting access to the media title purchased in accordance with the current updated rights object (Blocks 562 and 564).
- a server responds by sending the user information to the billing server 526 of Fig. 21 to obtain payment from the End User (Block 566).
- the server e.g. SP/DRM
- the rights object includes keys and preferably information for generating credentials for accessing keys for decrypting the locked (encrypted) media title purchased. (Block 568).
- the rights object may contain the content encryption keys for decrypting the catalogue media titles.
- the keys are then stored in device 10" for decrypting the titles.
- Such credentials may be generated on the fly by the terminal and by the device 10" using the unique ID of the terminal as a seed value by means of a function such as hash function in both the device 10" and the terminal.
- device 10 will also be able to generate such credentials and access to the keys is granted only when the two sets of credentials (generated by the device 10" and the terminal) match.
- a similar process may be used to authenticate the device 10" using the unique ID of device 10". If both processes are performed, the scheme becomes a mutual authentication scheme.
- the rights object contains not the content encryption keys themselves for decrypting the catalogue media titles, but only certain credentials for accessing such keys.
- the credentials may be those that would enable access as governed by the ACR structure described above.
- each catalogue media title has a corresponding ACR with corresponding content encryption key(s) that can be used to decrypt the title
- supplying the credentials to such ACR from the rights object will enable the decryption of the title.
- the end user will then need to input the credentials in each of the ACRs of all the catalogue titles (as well as credentials for accessing the ACRs of paid content, if the paid content is similarly protected by the ACR structure) before such titles can be decrypted and rendered.
- the end user may then need to keep track of a large number of credentials.
- a more user friendly mechanism is described below in reference to Fig. 24.
- Fig. 24 is a block diagram illustrating yet another embodiment for unlocking locked catalog media content in device 10" using the access control records (ACRs) and delegation attribute described above.
- the control structure in device 10" contains two AGPs 572 and 574.
- AGP 572 contains the DRM_ACR.
- the DRM_ACR controls the rights objects for three different paid content media files. These rights objects control, for example, the limited right for moving content to personal computer libraries or to export the content to another terminal.
- AGP 574 contains seven access control records, including a playback
- arrows 582 pointing from the playback _ACR 576 to the three paid _ACRs 578 indicate that the three ⁇ aid_ACRs 578 have delegated their rights to the content encryption keys to the playback _ACR 576 so that there is no need to present credentials to the three paid _ACRs 578 in order to access the content encryption keys used for decrypting the three paid media titles controlled by the three paid_ACRs 578.
- the content encryption keys for decrypting the three paid media titles can be accessed, so that it is much more convenient for the End User to have to remember only one set of credentials instead of three or more sets.
- the rights object downloaded or updated contains credentials in the ACRs for accessing the keys for decrypting individual catalogue or paid media titles.
- the rights object downloaded or updated contains credentials to the DRM_ACR instead.
- the DRM_ACR has the permission to cause the catalog _ACRs 580 to also delegate their rights to access content encryption keys for decrypting the three unpaid catalog media titles also to the playback _ACR 576.
- the DRM agent in either the terminal or device 10" will access the DRM_ACR by-presenting credentials from the rights object, and causes the DRM-ACR to exercise its rights to cause the delegation.
- the catalog _ACRs 580 then delegate their rights to access content encryption keys for decrypting the three unpaid catalog media titles also to the playback _ACR 576, after the billing server confirms that payment has been received from the End User in Block 566 in Fig. 23C. This is illustrated by dotted lines 584 in Fig. 24.
- the content encryption keys for decrypting media titles controlled by catalog _ACR 580 may be accessed as well as those for decrypting the paid media titles controlled by ACRs 578.
- the rights object contains a secret code, instead of the credentials of DRM_ACR.
- the credentials of the DRM_ACR may be generated on the fly from the secret code and the ID of device 10" using a function.
- the credentials of the playback _ACR may be generated in a similar manner from a secret code and the ID of device 10" using a function.
- AU the end user needs to input is the secret code for generating the credentials of the playback _ACR 576.
- the above scheme can also be achieved using rights objects, where different rights objects controlling access to media files can contain the right to delegate the permission to access such files to a playback rights object.
- a trusted application on the rendering device or terminal presents a user request and credentials or secret code for access to a media title to device 10" (Block 590).
- Device 10" determines whether the proper credentials or secret code have been presented to it by the rendering device (diamond 592). If the proper credentials or secret code have not been presented, device 10" simply waits until such credentials have been presented. If the proper credentials or secret code have been presented, then access to the content encryption keys stored in device 10" is then granted. The keys are then used to decrypt ciphered media title requested. The decrypted media title is then sent to the trusted application (Block 594). The rendering device or terminal then renders the decrypted media title (Block 596).
- Fig. 26 is a block diagram of a security architecture or control structure in a non-volatile re-writable memory device to illustrate additional features of this invention.
- the security architecture 600 of Fig. 26 includes credentials of a service provider (SP) stored in a security area such as that shown in Fig. 20.
- SP credentials 602 points to pre-loaded media content 606 through arrow 604, content 606 including pictures 606a, music 606b, games 606c, and video 606d.
- pre-loaded content 606 also includes handset specific media content 606e, such as ring tones.
- the arrow 604 indicates that if an application operating in a terminal has the SP credentials 602, the application will be able to access the preloaded content 606a-606e.
- the service provider SP is a mobile network operator such as Sprint or Verizon
- the operator may load its credentials into cellular phone handsets issued by it. Then all such handsets may be used for accessing the pre-loaded content 606a-606e by supplying the credentials of such operator to the memory device with such pre-loaded content.
- the memory device may also store media content that is accessible only by certain subscribers. Thus, as illustrated in Fig.
- pictures 610a, music 610b, games 610c, video 61Od, handset specific information 61Oe, and personal media content 61Of are available only to subscriber 1, or one with subscriber l's credentials. Thus, only an application which can supply the credentials of subscriber 1 will be able to access the media content 610a-610f. Thus, if subscriber 1 wishes to access any one of the files 610a-610f, he or she would input his or her credentials by means of an application in the terminal such as a handset, and can then access any one of such files.
- the subscriber l's account 608 can be an individual account, or can be a shared account within a group, such as a member account of a family account. In such event, there can be more than one set of credentials that can be used to access the files 610a-610f. When any one of the sets of credentials is transmitted to the memory device with architecture 600, the files 610a-610f can be accessed.
- the architecture 600 enforces the policy that, before subscriber 1 even reaches the stage where the credentials of subscriber 1 are requested, SP credentials should first be presented. After the SP credentials have been presented to the memory device, the subscriber is then asked to input the credentials for subscriber 1, if the subscriber wishes to access any one of the restricted files 610a-610f.
- the subscriber l's account 608 points to files 610a-610f by arrows
- Arrows 612 symbolize a control structure of one of the types described above, such as by means of rights objects which may include rights and/or rules for using the content in files 610a-610f.
- the rights objects may also include keys for decrypting the encrypted files 610a-610f.
- the rights objects will include credentials for accessing access control records through which the content encryption keys may be obtained for decrypting files 610a-610f.
- Architecture 600 may be used to store the encrypted media content accessible by multiple subscribers, where the media content accessible to one subscriber may or may not be accessible to a different subscriber.
- architecture 600 also includes an account for subscriber X.
- media content files associated with subscriber X may be accessed only if proper credentials for subscriber X is presented to the media device containing architecture 600.
- memory device 10 may be used by multiple subscribers.
- Each of the subscribers is able to independently access the media content associated with his or her account without fear of a different subscriber gaining unauthorized access to such content.
- media content files accessible to two or more subscribers There may also be partial overlap between media content files accessible to two or more subscribers.
- certain media content files may be associated with more than one subscriber account, so that such media content file can be accessed and decrypted when the credentials of any one of the subscribers are presented to the memory device. This can be done without the subscribers having to share either their credentials or any keys.
- one possible control structure for the security architecture 600 in Fig. 26 is the access control records (ACRs) described above.
- ACRs access control records
- the ACRs for controlling CEKs for decrypting encrypted media content are created when the memory device is created, such as the ACRs shown in Fig. 24.
- credentials in the appropriate ACRs are supplied to the subscriber to allow the subscriber to access the CEKs.
- a system ACR has the ability to create AGPs and
- ACRs In general, any ACR or AGP having the authority to create ACRs may be used to create subscriber ACRs. Such ACR or AGP may be already created in device 10 when manufactured. The ACR may be created as the control structure in memory device 10 before or after any media content has been loaded into the device. Content loaded into the device may be encrypted using content encryption keys generated by or supplied to the device, where the content and encryption keys become associated and are controlled by the subscriber ACR. In such manner, the subscriber associated control structure may be used to control access to such encrypted media content.
- the security architecture in Fig. 26 illustrates one avenue for media content distribution, where the memory device is bound to a particular service provider, so that it can not be used by different service providers for storing and controlling media content in the device.
- the security architecture in memory 10 may contain no SP credentials 602, so that such credentials are not necessary for accessing the content in the device.
- each of a number of different service providers may be able to create its own control structure independently of the other service providers in the same memory device.
- Each of the service providers may interact with the memory device without crosstalk or interference by another service provider.
- the system ACR of the SSA system described above pre-loaded in device 10 will assist each of the different service providers to create its own hierarchical tree in the form of AGP- ACR structures in the manner described above.
- the control structures described above include the rights objects and ACRs and the associated hierarchical tree.
- Rights objects are typically created outside the memory device and are downloaded to the device.
- such objects are managed by the DRM agent in the DRM server or the terminal, and by structures such as the DRM ACR in the memory device.
- ACRs and the associated hierarchical tree may be structures created in the memory device and do not exist outside of it. Normally it is undesirable to export their content or features to entities outside the device.
- ACRs may include permissions as to how CEKs are to be used, such as for read, write or delegate functions.
- Rights objects on the other hand, can specify more precisely how the CEKs and the content encrypted thereby can be used, such as by limiting the time duration in which access is allowed or number of accesses and so forth.
- software code implementing a playlist manager stored (e.g. in the security area) in the memory device may be used to register the location in a media title where the End User stops the playback or other rendering process. This allows the End User to disconnect the memory device from one terminal and connect it to another terminal and resume the play or rendering at the point where he or she stopped.
- the security architecture 600 also includes authentication and set up features 622, such as a certification. This is explained in more detail below.
- control structures created by different service providers are stored in separate partitions so that each partition stores only the control structure (e.g. AGP-ACR and/or rights objects) of its corresponding service provider.
- control structure e.g. AGP-ACR and/or rights objects
- partitions are private and hidden so that each of at least some of the partitions is accessible to the corresponding service provider of the control structures stored therein and not to other service providers.
- FIG. 27 An overall architecture for mutual authentication between an end user terminal and a memory device is illustrated in Fig. 27.
- the certification of a memory device 630 as genuine and the certification of end user terminal 632 as genuine are both derived from the authority of the root CA server 634.
- Device 630 is manufactured by a production facility where a production CA server 636 is located.
- Terminal 632 is in turn manufactured at a facility where terminal CA server 638 (which may be the same as server 634) is located.
- device 630 provides to server 636 the device ID, type and the device public key.
- Server 636 provides the production server ID and the production server public key to server 634.
- Server 634 provides the Root CA certificate and a production CA certificate to server 636.
- Server 636 in turn provides the two certificates from server 634 along with a device certificate signed by the private key of server 636 to device 630.
- a similar process is carried out between servers 634, 638, and terminal 632.
- terminal 632 and device 630 each contains three certificates as shown in Fig. 28.
- the memory device includes three certificates: root CA certificate, production CA certificate, and the memory device certificate. Since both the device 630 and the terminal 632 have the root CA certificate and root public key, this key may be used for verification that the public keys and the certificates containing these keys in the device and the terminal are genuine in the manner explained below, during the first setup process.
- terminal 632 and device 630 will exchange certificates the first time the device is inserted into the terminal for a setup process.
- the device will send the device certificate and production CA certificate to the terminal, and the terminal will send the terminal certificate and terminal CA certificate to the device.
- the different keys and certificates contained in the device 630 and terminal 632 are illustrated in Fig. 30.
- the production CA certificate includes a production CA public key and a version of such public key which is signed (i.e. encrypted) by the root CA private key.
- the terminal 632 can verify whether this production CA certificate is genuine by using the root public key in its possession to decrypt the encrypted production CA public key and compare the result with the production CA public key in the production CA certificate received from device 630. If they match, this indicates that the production CA certificate received has not been tempered with and is genuine. Terminal 632 can then use the production CA public key so confirmed to decrypt the encrypted version of the Device public key and compare the results with the device public key in the device certificate received from device 630. If they match, this indicates that the device certificate received has not been tempered with and is genuine.
- Device 630 can perform a similar process to verify that the certificates received from the terminal are genuine and have not been tempered with. It will be evident from the above that the more levels of keys and certificates that are utilized, the more secure will be the system. Three levels are used in Figs. 27-32. Obviously, if a higher or lower level of security is desired, the above scheme can be altered accordingly.
- the terminal will create an ACR in the device 630 as illustrated in Fig. 31 using an ACR that has been created in the device during manufacturing.
- This ACR created will contain the root CA certificate with the root public key, so that the next time the terminal is connected with the device, the device will verify using the root public key that the terminal certificate provided by the terminal is genuine in a process similar to that described above. If the terminal certificate provided by the terminal is verified to be genuine, then the memory device will allow the terminal to access content according to the permissions in the ACR.
- the terminal will log in and send its certificate to the device.
- the device will then perform the verification process described above.
- the memory device 630 also sends its certificate to the terminal 632 for verification as illustrated in Fig. 32.
- the certificates stored in the device 630 can also be used for an authentication server, such as any one of those shown in Figs. 19A-19D to check whether the device is genuine. If the server also has the root CA certificate and root public key in the certificate, this key may be used in a manner similar to that described above to verify that the device is genuine or a counterfeit. The device 630 can also verify whether the server is genuine by a similar process.
- the authentication server may also transfer the root CA certificate and the software for performing the checking to a different server, such as the server for the service provider, so that the service provider server can perform the verification process instead.
- the process in Figs. 19A-19D would then be simplified in that the service provider server can then perform the functions of the authentication server as well.
- the memory device 10" of Fig. 22 is preloaded with paid media content such as songs, as well as catalog media content which is unpaid. Such catalog media content may comprise encrypted full-length and high quality versions, as well as previews of such versions. Stored in device 10" may also be promotional items as well as various applications.
- memory device 10" may comprise a number of different areas, including a content area and a security area. Preferably, the security area is accessed only during device production in a secure production facility. For example, rights objects and AGP/ACR structures and other digital rights management solutions are stored in the security area of the device 10 or 10" at the secure production facility.
- Content encryption keys may be loaded to the secure area at the secured facility, or may be generated after production by the device itself.
- Content such as operator content and other secured content in the content area typically has large files, such as video files.
- the secure facility for loading secure data in the security area may not have the capability to load a large number of large files in volume production. For this reason, it may be desirable for locked content as well as unlocked content to be loaded in a non-secure area of production facility. Since the locked media content is typically encrypted, such content may be sent to the non-secure facility in an encrypted form to reduce the chance of unauthorized exploitation.
- Each memory device has a unique identification such as serial number which may be sequential.
- the security area may include control structures for controlling the use of the media content stored in the content area, first loading these control structures into the security area before the encrypted content is loaded provides an additional security to prevent unauthorized exploitation of the media content.
- the keys used to encrypt content in each of the memory devices manufactured may be different from the keys preloaded in any other device. If this is indeed the case, a hacker who is able to obtain the encryption key in one memory device will not be able to access the content stored in any other memory device. However, generating and loading a large number of different content encryption keys into each device may be cumbersome. As a compromise, the same set of keys may be loaded into a batch of memory devices so that they will have the same set of keys. Therefore, if the set of keys in one of the memory devices in a batch has been obtained in an unauthorized manner, the media content stored in such batch of memory devices may become accessible without authorization. The person who has obtained such set of keys will, however, not be able to access the media content stored in a different batch of memory devices since the media content in such devices would be encrypted by a different set of keys than the one obtained illegally.
- the .50,000 devices may be divided into 1,000 sets, each including 50 memory devices, with each device in the set loaded with one of 50 different sets of keys.
- the 50,000 devices are divided into 50 batches, each batch of 1,000 devices will be loaded or will use the same set of keys.
- the 50 sets of keys may be denoted as KOmn where m ranges from 1-20 for a maximum of up to 20 purchased media titles, such as soundtracks and n goes from 1-N where N is 50 in this case.
- N sets of keys KPIn are also provided where 1 may range from 1-50 for a maximum of 50 unpaid media titles such as soundtracks and n ranges from 1-N. This sets of keys KPIn should be transmitted securely to the right issuer server for issuing rights objects when these tracks are being purchased.
- the content encryption keys KOmn for the purchased titles or tracks are packaged into N sets of objects for adding the business rules such as unlimited play and three exports, for example as described above.
- the N sets of rights objects (one for each purchased media title) may be denoted as ROmn where m ranges between 1-20 for a maximum of 20 purchased media titles and n ranges between 1 and N.
- the N sets of rights objects may be securely transferred to the secure facility.
- the unique serial number of the memory device may be used to determine which one of the 50 sets of rights objects is to be load into the cart: ROIn, R02n,... ROmn, where m is may be 20 for a maximum of up to 20 purchased media titles.
- n is determined by the sequential portion of the memory device serial number divided by 1,000 (i.e. integer portion of memory device serial number/1,000 + 1). For example, if the memory device serial number is 5, the n is of the value 1. Of the serial number is 1,200, the n would be 2. If the serial number is 35870, n would be 36.
- the purchased media titles (a maximum of 20) may be encrypted into
- N sets of encrypted files COmn where m ranges from 1-20, and n ranges between 1- N.
- these titles would be encrypted as files PCLRl 3 PCLR2,.... PCLRL where L is up to 50.
- a 15 second video snippets or a low quality version of each of such titles may be produced and are labeled as: SNIPl, SNIP2, SNIPL, where L is up to 50.
- the full length catalog media titles are encrypted into N sets of encrypted files: POIn, where 1 ranges from 1-L and n ranges from 1-N.
- the N sets of encryption keys for the catalog media title files are sent to the rights issuer.
- the master copy for content loading will then contain the following:
- N sets of encrypted purchased media titles COmn where m ranges from 1-20 and n ranges from 1-N.
- N sets of encrypted catalog media titles corresponding to the preview snippets, that are encrypted with different content encryption keys across N sets of memory devices POIn, where 1 ranges from 1-L and n ranges from 1-N.
- the master copy and content loading script may be used to load the content to the memory devices.
- the content loading script will read the memory device serial number first, and based on the serial number, calculate the batch or set number between 1 and N. Then based on this set number n, the content loading script will read the nth set of the purchased media title files: COIn, CO2n,....COmn, where m is the number of media titles in the purchased media content.
- the content loading script will also read the nth set of the catalog media title files POIn, PO2n,...POLn, where L is the number of catalog media title files for including on the devices.
- the set of preview snippet files and the set of promotional items in post application are also loaded onto each memory device. The content loading script will then write the above selected files into the content public area of the memory device illustrated in Fig. 20.
- the process of generating the keys for the prepaid content and loading of the titles; and issuing of rights objects by the rights issuer is illustrated in reference to Figs. 33A and 33B.
- the devices or cards to be loaded are divided into groups having N devices or cards, each of the N devices in each group having a different set number and corresponding set of keys and rights object (block 631), where the set number is derivable from the serial number of the device (block 632).
- N sets of content encryption keys are generated and sent to the rights issuer (block 634).
- the rights issuer derives the set identification number of each memory device such as a memory card from its serial number.
- rights objects for controlled access to the content is compiled, identified and sent to the facility for loading (blocks 638, 640). These are received at the facility for loading (block 642).
- the set identification number is derived at the facility from its unique serial number, and the corresponding set of keys and rights object identified (blocks 644).
- the corresponding rights object is then loaded into the device such as a memory card.
- the purchased media titles are encrypted at the secure facility, and a master copy sent to a contractor's facility for loading of the encrypted titles (blocks 646, 648).
- the DRM agent in either the memory device and/or the terminal may be used to handle the above actions for the device and/or terminal.
- the process of generating the keys for the catalogue content and loading of the titles and issuing of rights objects by the rights issuer is illustrated in reference to Figs. 34 and 35.
- the devices to be loaded are divided into groups having N devices or cards, each of the N devices in each group having a different set number and corresponding set of keys and rights object, where the set number is derivable from the serial number of the device (block 652).
- N sets of CEKs for the catalogue media titles are generated by the secure facility, and the CEKs and device ID numbers are sent to the rights issuer (blocks 654, 656).
- the set identification number is derived from its unique serial number, and the corresponding set of keys identified (blocks 658).
- the catalogue media titles are then encrypted using the corresponding set of keys identified (block 660).
- the catalogue media titles are then stored in the device such as a memory card (block 662).
- the set identification number is derived from the device serial number (block 672) by the rights issuer, and the appropriate rights object is compiled using the set number and the CEKs received from the facility in block 656 (block 674).
- the rights issuer provides the corresponding rights object to the secure facility (block 660).
- the DRM agent will send a serial number of the memory device and the ID of the media title purchased to the rights issuer server (block 670).
- the rights issuer server then calculates the set number of the memory device based on the serial number of the memory device (block 672).
- the rights issuer should already have the N sets of encryption keys for the catalog media title files. Based on the set number and the media title ID, the rights issuer will be able to issue the correct rights object with the corresponding content encryption keys to be downloaded to the memory device after the purchase, (block 676)
- PREV means preview content comprising media content that has been abridged (e.g. a portion or lower quality version);
- FULL means the unabridged encrypted version of PREV;
- RO means rights object of PREV.
- PREPAID means content that has been paid for when acquiring the memory device. For simplicity, the rights object(s) for prepaid content has been omitted from the figures.
- the memory devices such as device 10 can store other types of content, as illustrated in Figs. 37A-37C, 38A, 38B, 39A and 39B.
- the device may store only PREV, or both PREV and FULL as shown in Fig. 37B.
- the device can also store PREV and RO as in Fig. 37C.
- the device stores PREV in all configurations.
- the memory devices such as device 10 can store
- the memory devices such as device 10 can store RO in all configurations, as in Figs. 39A and 39B. In Fig. 39B, it also stores FULL.
- device 10 may be loaded only with preview content, such as the snippets or lower quality versions of the media title. Such titles are indicated at 702.
- the rights object 704 may be downloaded after purchase of content 702 as indicated by arrow 706 in Fig. 40.
- the end user will have the right to download the unabridged version 708 (FULL) of the media title that has been previewed.
- the end user may download the full and unabridged version (FULL) of the media title 708 first, as indicated by arrow 712 in Fig. 40.
- FULL full and unabridged version
- the end user still does not have the right to access the full media title 708, since such title is encrypted and access to the content encryption key necessary to decrypt such title has been provided to the end user.
- the end user will have the right to download the rights object 704 as indicated by arrow 714 in Fig. 40.
- the preview content 702 enables the user to first preview the catalog media titles.
- Memory device thus renders PREV and then prompts the end user, through an end user terminal, to purchase the catalog media title previewed (blocks 722, 724).
- the full media title and rights object are supplied to the memory device for storage (blocks 726, 728).
- the end user will be able to access the media title purchased by decrypting the title and render it.
- the preview content 702 enables the user to first preview the catalog media titles.
- the full media title is downloaded followed by receiving the rights object (this order can be reversed) after the purchase. Keys can then be used to decrypt the full title for rendering.
- memory device 10 may be distributed only with the full encrypted and unabridged media titles as illustrated in Fig. 38 A. If the end user has already purchased the rights to such media titles (Fig. 38B), then the memory device will also be provided with the rights object and access to the necessary content encryption keys for decrypting the media titles. If, however, that the memory device for the full media titles is distributed prior to purchase, the end user will have to purchase the rights to access. After the purchase, the appropriate rights objects are downloaded (arrow 732 in Fig. 43) to provide access to the content encryption keys necessary for decrypting the media titles purchased.
- a memory device with the full unabridged but encrypted media titles may be stored along with the rights object which permits only restricted viewing or access of such media titles.
- a tracking agent that tracks the usage pattern of the end user and compiles a user profile. See Fig. 44.
- the restriction may impose a time duration restriction, or the number of times the media title may be accessed (block 742 in Fig. 45).
- the access is tracked and the user access profile is compiled (block 744 in Fig. 45).
- the end user will no longer be able to access the media title, unless the end user then connects the memory device to a server.
- the memory device When the memory device is connected to a server through a host or terminal, such user profile is then downloaded to the server for purposes such as market research. After the access profile has been downloaded, the rights object may be modified or updated to permit the end user an extended time duration or count for accessing and enjoying the media titles on the memory device (block 746 in Fig. 45).
- memory device 10 may be distributed with only the rights object loaded shown in Fig. 39A. Such memory devices must be purchased and it functions similar to a prepaid service card such as a SIM card for phone service.
- the rights object will permit the end user to download the full unabridged media titles for enjoyment (block 752 in Fig. 46).
- the rights object may permit the end user to download a large number of media titles. Thus after the end user has enjoyed a number of the downloaded titles, it is possible then for the end user to delete these from the memory device and then download the same titles later. In this manner, the end user is not restricted to the storage capacity of the memory device, but can repeatedly download and delete media titles from the memory device. Backup and Reload Control
- a non-volatile memory device such as a flash card
- a non-volatile memory device such as a flash card
- the rights object permits the making of a limited number of copies such as three copies, the rights object will keep track of the number of copies made. Once the set limited number of copies have been made, then the rights object will prohibit any further copying.
- This restriction can be avoided if a back up copy of the rights object can be made to a storage region prior to copying and restored to the memory device after three copies have been made. By restoring the original rights object that allows three copies, the user can again make three more copies. This process can obviously be repeated, so that the restriction in the rights object can be circumvented altogether.
- the storage region can be in the same device from which a back up copy of the rights object is made, or in a different device.
- the rights object is stored in a protected partition, such as those described above in reference to Figs. 2-4.
- an application such as one on a host will need to supply the appropriate predetermined credentials to the memory device, before access can be granted.
- the end user normally will be able to access the rights object for the purpose of rendering or playing the content controlled by the rights object.
- the end user credentials permit the end user to only able to read the rights object from the partition, but not to back up and restore the rights object in the partition.
- credentials different from those available to the end user are used.
- Only applications with such credentials may back up and restore the rights object in the partition.
- the rights object is restored to a protected partition, so that the restored rights object will again be effective in controlling access to the corresponding content, such as by means of the two different sets of credentials: one set permitting only the reading of the rights object, and the other permitting back up and restore.
- the rights object is deleted from the memory device after the rights object has been backed up and stored in a back up storage region. After the rights object is restored to the memory device, it is preferably deleted from the back up storage region.
- the rights object may permit the making of a limited number of copies such as three copies. In order to enforce such rule, the rights object will keep track of the number of copies made. Thus, when an application copies the rights object, the rights object that remains on the memory device will need to be updated to keep track of the number of copies, if any, that are still permitted after a copy has been made. Moreover, the rights object that is copied will need to be altered during the copying so as to reflect accurately, whether further copies can be made from such copy. Thus, if the end user wishes to allow further copies to be made from such copy, it may be preferable to modify the rights object copied to make this possible.
- the rights object permits a total of n copies to be made from an original, where n is a positive integer.
- the rights object copied may specify that a total of m copies may be made from the copied rights object, where m is zero or a positive integer less than n.
- the rules in the original rights object will be updated to permit only (n-m) copies to be made from the original.
- the rights object (the original as well as the copied) will include the count or number of copies that can be made from it, and also the requirement that the copy count will need to be modified accordingly upon further transfers. When no more copies can be made from such object, this count or number will become zero.
- Rights object for controlling media content may specify the right for unlimited rendering or plays. Alternatively, the number of rendering or plays may be limited as well. If this is the case, the rights object will include the count or number of rendering or plays that can still be made.
- the credentials needed to access the rights object for the purpose of modifying, updating or deletion are different from those needed for read only functions.
- the credentials needed to access the rights object for the purpose of modifying, updating or deletion may be the same as those for backup and restoration.
- an attempt is made to make a copy of such object i.e. an object from which a copy cannot be made
- this will result in such object being deleted from the memory device (or other storage) when the copy is made to another device, as specified in the rights object, for example. After the deletion, the content cannot be accessed anymore, for rendering, play back or any other purpose.
- the right for limited or unlimited rendering or plays will be updated to indicate that no rendering or plays can be made, or access to the rights object can simply be blocked altogether except for limited purposes such as diagnosis, or failure analysis.
- the rights object is preferably encrypted by means of a key (preferably performed in device 10), and the proper credentials presented to the memory device will cause such key to become available for reading only or for writing (which means allowing deletion, modification or updates, backup and restoration) in the manner as described above.
- the rights object is first decrypted. Then any modification or deletion can be performed in the manner described above and the rights object encrypted.
- the crypto-engine 40 may be used to perform the encryption. If encryption of the rights object is not desired, a bypass path (not shown in tig. T) without any cryptographic operation on the data stream, as if the Crypto-Engine 40 is not present and the HDMA and FMDA are connected directly along this bypass path to BRAM 38 through arbiter 36.
- the rights object can be copied if copying is desired and permitted by the rules in the rights object.
- the decrypted rights object to be copied is encrypted using a session id or key and transmitted to another storage device.
- the rights object is decrypted using the session id or key, and then encrypted again using yet another key (which can be from the another storage device, or another source) and stored in the another storage device.
- This process can also be carried out for the rights object that is backed up and restored.
Landscapes
- Engineering & Computer Science (AREA)
- Computer Security & Cryptography (AREA)
- Signal Processing (AREA)
- Theoretical Computer Science (AREA)
- Software Systems (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)
- Two-Way Televisions, Distribution Of Moving Picture Or The Like (AREA)
Applications Claiming Priority (4)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US71552405P | 2005-09-08 | 2005-09-08 | |
US11/322,812 US20070043667A1 (en) | 2005-09-08 | 2005-12-30 | Method for secure storage and delivery of media content |
US11/322,766 US20070056042A1 (en) | 2005-09-08 | 2005-12-30 | Mobile memory system for secure storage and delivery of media content |
PCT/US2006/035155 WO2007030760A2 (en) | 2005-09-08 | 2006-09-07 | Mobile memory system for secure storage and delivery of media content |
Publications (1)
Publication Number | Publication Date |
---|---|
EP1934878A2 true EP1934878A2 (en) | 2008-06-25 |
Family
ID=37635873
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
EP06814382A Withdrawn EP1934878A2 (en) | 2005-09-08 | 2006-09-07 | Mobile memory system for secure storage and delivery of media content |
Country Status (4)
Country | Link |
---|---|
EP (1) | EP1934878A2 (ja) |
JP (1) | JP2009508412A (ja) |
KR (1) | KR20080043402A (ja) |
WO (1) | WO2007030760A2 (ja) |
Families Citing this family (21)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
KR101391152B1 (ko) | 2007-04-05 | 2014-05-02 | 삼성전자주식회사 | Ums 기기의 컨텐츠를 보호하기 위한 방법 및 장치 |
KR100911647B1 (ko) | 2007-04-18 | 2009-08-10 | 삼성전자주식회사 | 콘텐츠를 저장하는 메모리와 이의 티져 광고 생성 방법 및 이를 이용한 콘텐츠 제공 방법 |
US7822935B2 (en) * | 2007-05-03 | 2010-10-26 | Sandisk Il Ltd. | Methods for data-smuggling |
US8688588B2 (en) | 2007-06-08 | 2014-04-01 | Sandisk Technologies Inc. | Method for improving accuracy of a time estimate used in digital rights management (DRM) license validation |
US8869288B2 (en) | 2007-06-08 | 2014-10-21 | Sandisk Technologies Inc. | Method for using time from a trusted host device |
KR101465555B1 (ko) * | 2007-06-08 | 2014-11-26 | 샌디스크 테크놀로지스, 인코포레이티드 | 엔티티를 인증하기 위해 사용된 시간 평가의 정확성을 개선하기 위한 회로를 구비한 메모리 디바이스와, 상기 메모리 디바이스와 사용하기 위한 방법 |
US8688924B2 (en) | 2007-06-08 | 2014-04-01 | Sandisk Technologies Inc. | Method for improving accuracy of a time estimate from a memory device |
US8761402B2 (en) | 2007-09-28 | 2014-06-24 | Sandisk Technologies Inc. | System and methods for digital content distribution |
JP2011513804A (ja) * | 2008-01-02 | 2011-04-28 | サンディスク アイエル リミテッド | 直接ユーザアクセスを受ける記憶デバイス |
US9083685B2 (en) | 2009-06-04 | 2015-07-14 | Sandisk Technologies Inc. | Method and system for content replication control |
US8448009B2 (en) | 2009-08-17 | 2013-05-21 | Sandisk Il Ltd. | Method and memory device for generating a time estimate |
TW201112033A (en) | 2009-09-29 | 2011-04-01 | Inst Information Industry | Digital content management methods and systems, and computer program products thereof |
KR101954215B1 (ko) | 2011-07-12 | 2019-06-07 | 삼성전자주식회사 | 비휘발성 저장 장치의 이용 방법 및 장치 |
KR20130048035A (ko) * | 2011-11-01 | 2013-05-09 | 엘지전자 주식회사 | 미디어 장치, 컨텐츠 서버 및 그 동작방법 |
US9286477B2 (en) * | 2012-08-29 | 2016-03-15 | Symantec Corporation | Secure app ecosystem with key and data exchange according to enterprise information control policy |
US9100769B2 (en) * | 2013-02-08 | 2015-08-04 | Sprint Communications Company L.P. | System and method of storing service brand packages on a mobile device |
WO2015075796A1 (ja) | 2013-11-21 | 2015-05-28 | 株式会社 東芝 | コンテンツ管理システム、ホスト装置及びコンテンツ鍵アクセス方法 |
CN110569202A (zh) * | 2019-09-10 | 2019-12-13 | 深圳市得一微电子有限责任公司 | 一种用于可移动存储设备的多媒体文件播放方法及*** |
CN112199666B (zh) * | 2020-09-30 | 2023-02-03 | 江苏恒宝智能***技术有限公司 | 设备通信方法、装置、***和电子设备 |
KR102439880B1 (ko) * | 2022-01-26 | 2022-09-05 | 프라이빗테크놀로지 주식회사 | 애플리케이션의 파일 송신 및 수신을 제어하기 위한 시스템 및 그에 관한 방법 |
KR102460693B1 (ko) * | 2022-02-23 | 2022-10-31 | 프라이빗테크놀로지 주식회사 | 애플리케이션의 파일 송신 및 수신을 제어하기 위한 시스템 및 그에 관한 방법 |
Family Cites Families (15)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JPH08181966A (ja) * | 1994-12-27 | 1996-07-12 | Toshiba Corp | 送信装置並びに受信装置並びに通信処理システム |
JPH10260903A (ja) * | 1997-03-19 | 1998-09-29 | Hitachi Ltd | グループ暗号方法、及びファイル暗号システム |
JP2000348003A (ja) * | 1998-10-16 | 2000-12-15 | Matsushita Electric Ind Co Ltd | ディジタル著作物であるコンテンツを扱う著作物保護システム |
JP4713745B2 (ja) * | 2000-01-14 | 2011-06-29 | パナソニック株式会社 | 認証通信装置及び認証通信システム |
EP1512147A2 (en) * | 2000-12-07 | 2005-03-09 | SanDisk Corporation | System, method, and device for playing back recorded audio, video or other content from non-volatile memory cards, compact disks or other media |
JP4271876B2 (ja) * | 2001-02-20 | 2009-06-03 | 株式会社日立製作所 | ディジタルコンテンツ生成方法及び関連装置 |
CN100450176C (zh) * | 2001-12-11 | 2009-01-07 | 艾利森电话股份有限公司 | 用于流媒体的数字权利管理方法和客户设备 |
JP2004040741A (ja) * | 2002-06-28 | 2004-02-05 | Super Contents Distrubutions Ltd | コンテンツ流通方法 |
JP4314894B2 (ja) * | 2003-06-09 | 2009-08-19 | ソニー株式会社 | 楽曲データ処理装置及び楽曲データ販売システム |
EP1688875A4 (en) * | 2003-11-27 | 2011-12-07 | Panasonic Corp | Content Distribution Systems and Content Management Procedures |
JP4676749B2 (ja) * | 2004-12-02 | 2011-04-27 | パナソニック株式会社 | データ処理装置 |
EP1836641A2 (en) * | 2004-12-21 | 2007-09-26 | SanDisk Corporation | Versatile content control with partitioning |
EP1836640A2 (en) * | 2004-12-21 | 2007-09-26 | SanDisk Corporation | Memory system with versatile content control |
TW200700991A (en) * | 2004-12-21 | 2007-01-01 | Sandisk Corp | Control structure for versatile content control and method using structure |
TWI388985B (zh) * | 2004-12-21 | 2013-03-11 | Sandisk Technologies Inc | 控制一儲存裝置中資料存取的方法及儲存裝置 |
-
2006
- 2006-09-07 EP EP06814382A patent/EP1934878A2/en not_active Withdrawn
- 2006-09-07 JP JP2008530239A patent/JP2009508412A/ja active Pending
- 2006-09-07 WO PCT/US2006/035155 patent/WO2007030760A2/en active Application Filing
- 2006-09-07 KR KR1020087008338A patent/KR20080043402A/ko not_active Application Discontinuation
Also Published As
Publication number | Publication date |
---|---|
WO2007030760A8 (en) | 2008-07-31 |
JP2009508412A (ja) | 2009-02-26 |
WO2007030760A2 (en) | 2007-03-15 |
KR20080043402A (ko) | 2008-05-16 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US20070056042A1 (en) | Mobile memory system for secure storage and delivery of media content | |
WO2007030760A2 (en) | Mobile memory system for secure storage and delivery of media content | |
US8051052B2 (en) | Method for creating control structure for versatile content control | |
US8601283B2 (en) | Method for versatile content control with partitioning | |
US8504849B2 (en) | Method for versatile content control | |
KR101238848B1 (ko) | 파티셔닝을 포함한 다기능 컨텐트 제어 | |
KR101214497B1 (ko) | 다기능 컨텐츠 제어가 가능한 메모리 시스템 | |
US9075957B2 (en) | Backing up digital content that is stored in a secured storage device | |
US20060242150A1 (en) | Method using control structure for versatile content control | |
US20100077214A1 (en) | Host Device and Method for Protecting Data Stored in a Storage Device | |
US20060242151A1 (en) | Control structure for versatile content control | |
US20080034440A1 (en) | Content Control System Using Versatile Control Structure | |
US20080010685A1 (en) | Content Control Method Using Versatile Control Structure | |
US20060242066A1 (en) | Versatile content control with partitioning | |
US20060242067A1 (en) | System for creating control structure for versatile content control | |
US20090276474A1 (en) | Method for copying protected data from one secured storage device to another via a third party | |
EP1836643A2 (en) | System for creating control structure for versatile content control | |
WO2008008244A2 (en) | Content control system and method using versatile control structure | |
WO2006069311A2 (en) | Control structure for versatile content control and method using structure | |
KR20070057940A (ko) | 콘텐츠를 보호하기 위한 방법, 장치, 및 매체 |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
PUAI | Public reference made under article 153(3) epc to a published international application that has entered the european phase |
Free format text: ORIGINAL CODE: 0009012 |
|
17P | Request for examination filed |
Effective date: 20080225 |
|
AK | Designated contracting states |
Kind code of ref document: A2 Designated state(s): AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HU IE IS IT LI LT LU LV MC NL PL PT RO SE SI SK TR |
|
AX | Request for extension of the european patent |
Extension state: AL BA HR MK RS |
|
R17D | Deferred search report published (corrected) |
Effective date: 20080731 |
|
17Q | First examination report despatched |
Effective date: 20110323 |
|
RAP1 | Party data changed (applicant data changed or rights of an application transferred) |
Owner name: SANDISK TECHNOLOGIES INC. |
|
DAX | Request for extension of the european patent (deleted) | ||
STAA | Information on the status of an ep patent application or granted ep patent |
Free format text: STATUS: THE APPLICATION IS DEEMED TO BE WITHDRAWN |
|
18D | Application deemed to be withdrawn |
Effective date: 20140401 |