WO2004038568A2 - Method and device for authorizing content operations - Google Patents

Method and device for authorizing content operations Download PDF

Info

Publication number
WO2004038568A2
WO2004038568A2 PCT/IB2003/004538 IB0304538W WO2004038568A2 WO 2004038568 A2 WO2004038568 A2 WO 2004038568A2 IB 0304538 W IB0304538 W IB 0304538W WO 2004038568 A2 WO2004038568 A2 WO 2004038568A2
Authority
WO
WIPO (PCT)
Prior art keywords
user
content
domain
authorized
perform
Prior art date
Application number
PCT/IB2003/004538
Other languages
French (fr)
Other versions
WO2004038568A3 (en
Inventor
Franciscus L. A. J. Kamperman
Geert J. Schrijen
Original Assignee
Koninklijke Philips Electronics N.V.
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Koninklijke Philips Electronics N.V. filed Critical Koninklijke Philips Electronics N.V.
Priority to US10/531,939 priority Critical patent/US20060021065A1/en
Priority to BR0315550-1A priority patent/BR0315550A/en
Priority to AU2003267764A priority patent/AU2003267764A1/en
Priority to EP03748459A priority patent/EP1556748A2/en
Priority to JP2004546260A priority patent/JP2006504176A/en
Publication of WO2004038568A2 publication Critical patent/WO2004038568A2/en
Publication of WO2004038568A3 publication Critical patent/WO2004038568A3/en

Links

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/10Protecting distributed programs or content, e.g. vending or licensing of copyrighted material ; Digital rights management [DRM]
    • G06F21/101Protecting distributed programs or content, e.g. vending or licensing of copyrighted material ; Digital rights management [DRM] by binding digital rights to specific entities
    • G06F21/1012Protecting distributed programs or content, e.g. vending or licensing of copyrighted material ; Digital rights management [DRM] by binding digital rights to specific entities to domains
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F15/00Digital computers in general; Data processing equipment in general
    • G06F15/16Combinations of two or more digital computers each having at least an arithmetic unit, a program unit and a register, e.g. for a simultaneous processing of several programs
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F1/00Details not covered by groups G06F3/00 - G06F13/00 and G06F21/00
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F17/00Digital computing or data processing equipment or methods, specially adapted for specific functions
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/10Protecting distributed programs or content, e.g. vending or licensing of copyrighted material ; Digital rights management [DRM]
    • G06F21/101Protecting distributed programs or content, e.g. vending or licensing of copyrighted material ; Digital rights management [DRM] by binding digital rights to specific entities
    • G06F21/1015Protecting distributed programs or content, e.g. vending or licensing of copyrighted material ; Digital rights management [DRM] by binding digital rights to specific entities to users
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F2221/00Indexing scheme relating to security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F2221/21Indexing scheme relating to G06F21/00 and subgroups addressing additional information or applications relating to security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F2221/2153Using hardware token as a secondary aspect

Definitions

  • the invention relates to methods of authorizing an operation requested by a first user on a content item.
  • the invention further relates to devices arranged to perform an operation requested by a first user on a content item.
  • CP Copy Protection
  • CE consumer electronics
  • the second category is known under several names.
  • systems of this category are generally known as conditional access (CA) systems, while in the Internet world they are generally known as Digital Rights Management (DRM) systems.
  • CA conditional access
  • DRM Digital Rights Management
  • Recently new content protection systems have been introduced in which a set of devices can authenticate each other through a bi-directional connection. Based on this authentication, the devices will trust each other and this will enable them to exchange protected content.
  • the licenses accompanying the content it is described which rights the user has and what operations he/she is allowed to perform on the content.
  • the license is protected by means of some general network secret, which is only exchanged between the devices within a certain household, or, more generally, within a certain domain. This network of devices is thus called an Authorized Domain (AD).
  • AD Authorized Domain
  • authorized domains tries to find a solution to both serve the interests of the content owners (that want protection of their copyrights) and the content consumers (that want unrestricted use of the content).
  • the basic principle is to have a controlled network environment in which content can be used relatively freely as long as it does not cross the border of the authorized domain.
  • authorized domains are centered around the home environment, also referred to as home networks.
  • home networks also referred to as home networks.
  • a user could for example take a portable television with him on a trip, and use it in his hotel room to access content stored on his Personal Video Recorder at home. Even though the portable television is outside the home network, it is a part of the user's authorized domain.
  • the trust necessary for secure intercommunication between devices is based on some secret, only known to devices that were tested and certified to have secure implementations.
  • Knowledge of the secret is tested using an authentication protocol.
  • the best currently known solutions for these protocols are those which employ 'public key' cryptography, which use a pair of two different keys.
  • the secret to be tested is then the secret key of the pair, while the public key can be used to verify the results of the test.
  • the public key is accompanied by a certificate, that is digitally signed by a Certification Authority, the organization which manages the distribution of public/private key-pairs for all devices.
  • the public key of the Certification Authority is hard-coded into the implementation of the device.
  • AD-like DRM systems are known. However, they typically suffer from a number of limitations and problems which make their deployment and acceptance in the market difficult. In particular, an important problem which has not been addressed sufficiently is how to manage and maintain an authorized domain structure which allows a consumer to exercise the rights he has obtained anytime and anywhere he chooses. Current AD solutions typically restrict consumers to a particular and limited set of systems, and do not provide the desired flexibility.
  • a common approach is to provide the person who buys a content right (a right needed to access a content item, typically containing a necessary decryption key) with a secure personal device like a smart card. During playback, the smart card shares this decryption key with a compliant playback device. The person can now access content as long as he has his smart card with him.
  • This solution suffer from the drawback that a smart card has a limited amount of memory, which means that not all rights can be stored on the card.
  • An improvement to this system could be to encrypt the content right with the public key of the smart card and to store the rights somewhere, e.g. on multiple locations and e.g. together with the content item.
  • This object is achieved according to the present invention in a method of authorizing an operation requested by a first user on a content item in accordance with a content right containing necessary information for performing the requested operation on the content item and a user right identifying the first user and authorizing the first user to employ the content right.
  • the user right is a single connection between one user and a content right.
  • the content right is required to access a piece of content, for example because it contains a necessary decryption key.
  • Rights management based on persons is achieved by issuing more user rights authorizing persons to employ the content right.
  • This object is achieved according to the present invention in a method of authorizing an operation requested by a first user on a content item in accordance with a user right identifying a second user and authorizing the second user to perform the requested operation on the content item, in which the operation is authorized upon receipt of information linking a user right of the first user and the user right of the second user.
  • the linking information allows users to share rights with each other, regardless of devices the content resides on or of any information such as content rights that may be necessary to perform operations on the content.
  • rights management is based on persons instead of devices.
  • the linking information comprises one or more domain certificates identifying the first and second users as members of the same authorized domain.
  • domain certificates (certificates to indicate a group or domain) are issued by a trusted third party to define which persons are member of a particular domain. If the first user now is not authorized to perform the operation, but there is a second user in the same domain who does have such a right, then the first user is still allowed to perform the operation. Preferably user rights can be anywhere in the system. It is now possible
  • the method comprises receiving a content right containing necessary information for performing the requested operation on the content item, the user right of the second user authorizing the second user to employ the content right. Any person can now obtain a user right and thereby exercise the content right, independently of any other user rights that other persons may possess.
  • the content right makes it possible that a device can perform the operation, for example because it contains a necessary decryption key to access the content.
  • a user right authorizes a particular user to employ the content right on the device. This device must check if the right is available and the user is available. A second user is authorized if also a correct domain certificate is available, which connects the two users.
  • the operation is not authorized if the content right does not identify the authorized domain.
  • content rights can be restricted to the particular authorized domain. Not only does this make rights management more fine-grained, it also limits the damage that can be done by a hacker who manages to obtain decryption keys (provided by content rights) by compromising a device in a particular authorized domain.
  • the content right could be at least partially encrypted using an encryption key for which the corresponding decryption key is available to devices in the domain. This way the content right is not usable outside the domain.
  • This object is achieved according to the present invention in a device arranged to perform an operation requested by a first user on a content item in accordance with a content right containing necessary information for performing the requested operation on the content item and a user right identifying the first user and authorizing the first user to employ the content right.
  • This object is achieved according to the present invention in a device arranged to perform an operation requested by a first user on a content item in accordance with a user right identifying a second user and authorizing the second user to perform the requested operation on the content item, being arranged to authorize the operation upon receipt of of information linking a user right of the first user and the user right of the second user.
  • the linking information comprises one or more domain certificates identifying the first and second users as members of the same authorized domain. It is desirable to be able to share access to the content item with members of a particular family, or more generally a particular domain.
  • the device is arranged to receive a content right containing necessary information for performing the requested operation on the content item, the user right of the second user authorizing the second user to employ the content right.
  • the content right is encrypted using an encryption key for which a corresponding decryption key is available to the device. This way, only devices in a particular authorized domain can employ the content right, thereby effectively restricting the content right to the particular domain.
  • the content right is provided with a digital signature allowing verification of the authenticity of the content right.
  • the device then is arranged to perform the operation if the digital signature can be verified successfully using a digital certificate associated with an authorized content provider. This way only the content provider himself can create 'official' content rights.
  • the device is arranged to perform the operation if the digital signature can be verified successfully using a digital certificate associated with a particular device. This way, personal content (created on that particular device) can also be played back or otherwise used, without the need to involve a third party.
  • the device is arranged to refuse to perform the operation if the digital signature cannot be verified successfully using a digital certificate associated with an authorized content provider and a digital watermark associated with the authorized content provider is present in the content item. This way malicious users cannot create content rights for 'official' content, even when they try to pass the 'official' content of as personal content, e.g. by creating an analog recording from a television screen.
  • the device is arranged to determine a robust fingerprint for the content item and to refuse to perform the operation if the determined robust fingerprint does not match a robust fingerprint comprised in the content right. This way malicious users cannot create content rights for personal content and subsequently try to use those for 'official' content.
  • Fig. 1 illustrates a model of an authorized domain (AD) based on persons, rights and content
  • Fig. 2 illustrates an example of a device that is being operated by a user carrying a smartcard who wants to perform an operation on content item
  • Fig. 3 illustrates how a person can employ another person's user right to exercise a content right if both belongs to the same AD.
  • Fig. 1 illustrates a model of an authorized domain (AD) based on persons, rights and content.
  • the authorized domain AD contains content Cl, C2, C3, ...Ck, rights Rl, R2, R3, ..., Rm and persons PI , P2, P3, ... Pn.
  • the model also shows that content items, e.g. content item Ci, may be imported into the domain or exported from the domain and that persons, e.g. person Pj, may register to the domain or de-register from the domain.
  • content items e.g. content item Ci
  • persons e.g. person Pj
  • PCT/TB03/01940 attorney docket
  • Fig. 1 are: AD persons membership management:
  • AD person-rights link management Persons-rights link identification (Which person may use a right)
  • the user right is a single connection between one user and a content right
  • content content items are encrypted (there are many options, for example with a unique key per content title) and can be anywhere in the system.
  • content right contains rules (e.g. restricted to viewers 18 years or older, or European market only) and key(s) to access a certain content item.
  • the system is flexible in the sense that content rights can be made unique per content title or even unique per specimen (copy) of content.
  • Content rights should be only transferred to compliant devices.
  • a more secure rule is to enforce that content rights may be only transferred to compliant devices that are operated by authorized users (i.e. users that are authorized to have access to the specific content right by means of their user rights).
  • Content rights might also be stored together with the content on for example an optical disk.
  • user right a certificate issued by the content provider that authorizes a person to use a certain content right (belonging to a certain piece of content).
  • User rights can be in principle anywhere in the system.
  • the SPKI authorization certificate (implemented compliant to e.g. X.509) could be used to implement such a user right.
  • device A (compliant) device can identify a user by means of a personalized identification device (such as a smart-card) or e.g. a biometric (or both) and collect certificates (e.g. from the smartcard, or from other devices) that prove that the user is allowed to use a certain content right.
  • This content right could be obtained from the smart-card where it was stored (if it was stored there), or be obtained (securely transferred) from another device on the network (after showing the appropriate certificate chain).
  • user A user is identified by some biometric or preferably by a personalized identification device (e.g. a smartcard) that he/she is carrying. The latter is preferred since it allows users to carry rights with them (for accessing content on off-line devices) and generate signatures to issue their own certificates (user rights).
  • the identification device may itself be protected by a biometric authentication mechanism, so that anyone other than the legitimate owner cannot use the identification device.
  • Fig. 2 illustrates an example of a device Dl that is being operated by a user carrying a smartcard ID who wants to perform an operation on content item Cl, for example a rendering of the content item, a recording of the content item, a transfer of the content item or a creation of a copy of the content item.
  • the device Dl obtains a user right, preferably embodied as a digital certificate, from a remote database URDB on the Internet and stores it in local storage medium UR.
  • the content rights also preferably embodied as digital certificates, that are required to perform the operation on the content item Cl are obtained from a second device D2 and stored in local storage medium CR.
  • device D2 checks the user rights of the user (this depends on the rules for transferring content rights as is said before) and whether the device Dl is compliant.
  • devices Dl and D2 are provided with respective authentication modules AUTH. These modules could for example comprise respective private keys from a public/private key pair and certificates for the associated public keys, allowing public-key based authentication.
  • the operation on the content item Cl is authorized if there is a content right containing necessary information for performing the requested operation on the content item Cl and a user right identifying the first user and authorizing the first user to employ the content right.
  • a separate content right may not be necessary, for example if all operations on content in the system are always authorized.
  • the operation is not performed. However, the operation may still be authorized if information linking a user right of the first user and the user right of the second user is received.
  • information can be of any type, for example a certificate identifying both users or a listing on a Web server indicating the user rights are linked.
  • the information could also be contained in one (or both) of the user rights themselves. Preferably it is provided in the form of one or more domain certificates, as discussed below.
  • a certificate which we call a domain certificate, is issued by a (trusted) third party that defines what persons/entities belong to a certain domain.
  • a certificate contains the identifier (e.g. biometric, public key) of the subject (a person) and the identifier (e.g. name, public key) of the authorized domain the subject is declared to be part of.
  • the certificate is signed with the private key of the issuing trusted party. Furthermore the certificate must contain the usual fields like 'date of issue' and 'validation date' in correspondence with an appropriate revocation system.
  • the SPKI 'name certificate' could be used to implement this domain certificate.
  • the domain certificates can be implemented in a variety of ways.
  • every user is issued a separate domain certificate identifying him as a member of a particular authorized domain.
  • a comparison of the respective AD identifiers in two respective domain certificates establishes whether two users are members of the same domain. This way every domain certificate can be managed separately and a person's domain certificate is not affected when another person joins or leaves the authorized domain.
  • identifiers for members of a single authorized domain are enumerated in a single domain certificate. This way it is much easier to check whether two persons belong to a single authorized domain.
  • every person now automatically has the AD membership information of all other members of his domain available, without requiring a separate certificate to be retrieved. However, when a new person joins the AD, all persons must be issued new domain certificates.
  • the content provider may only allow other persons within the domain to play the content under certain circumstances. In this case this should be stated in the user right by means of some extra bits.
  • other flags or bits could be added to user right certificates. For example bits dealing with permission for a first generation copy or for one-time playback could be added in the certificates. Such bits could also be added to the content right CRl, and then they would apply regardless of which user right was used to exercise the content right.
  • the system also allows for so-called cross authorized-domain rights. These are rights that allow content to cross the borders of the authorized domain. This can be achieved by adding extra fields in the user right that indicate the allowed cross-domain behavior that compliant devices have to obey.
  • the delegation tag in SPKI authorization certificates could be used for this purpose. This way, serial copy management can be implemented that can limit copies up to one generation. It may also be desirable to implement 'copy-once' restrictions.
  • root public keys need to be known by the device. This is necessary in order to check certificates (and certificate chains) that exist in the system.
  • root key of naming authority e.g. government that issues household-domain certificates
  • root key of user management for checking whether key pairs of individual users
  • Smartcards are authentic and have not been compromised (User management).
  • User rights management User rights may change; A user may give away the right to someone else.
  • An ID device may be hacked, or a person may e.g. pass away.
  • Device compliance management Devices may be hacked and then must be revoked/renewed.
  • the composition of a family is represented in a certificate, i.e. the certificate lists the members of the family.
  • the system deals with changes in the family composition by using domain certificates, listing the family members, with limited validity date. After the validation date has expired the family must apply for a new certificate at some trusted third party.
  • the community administration could for example act as such a trusted third party and take into account changes in the family composition.
  • dates/time can be easily, reliably, and securely transferred to devices by including this date/time in content or user rights. This enables the mechanism that a device may only accept a domain certificate if its date is later than the date in the user rights or content right. The device may also store the date/time for future use as a lower boundary to the "current" time. Also some kind of sequence numbering mechamsm could be used in usage and content rights to achieve similar effect for accepting the domain certificate.
  • a user right may also be used to distribute new domain certificates to a family.
  • Revocation messages could be distributed with user rights (or with local content rights). User rights will also be dealt with using validity dates. Such a validity date may also be set to infinite. We now, however, still need to deal with transfer of user rights
  • a person may be identified on the basis of his biometric data or on the basis of an ID device (e.g. a wireless smart card, the mobile telephone, etc.) belonging to that person.
  • Biometric data will go along with the person and managing these data is “automatic”.
  • An ID device could be hacked and duplicated, lost, etc. To handle such "events” requires care management of ID devices.
  • an ID device operates with some public key algorithm using a public/private key pair. The best seems here to also have validity dates for ED devices (or that at a certain moment in time, for new content a new ED device is required). In case a private key becomes known, first of all the device ID should be revoked. Such a revocation message might be included in new content rights or in new user rights. Furthermore the person should be removed from the family certificate. This gives an extra hurdle to hackers being now unable to access content owned by family members. Note that updating of the ID device could be done automatically when a person buys content, i.e. obtains a usage certificate.
  • Device compliancy management can be done on the basis of distribution of content rights. Only compliant devices are allowed to obtain content rights. Different technologies might be used to perform device management and secure content right distribution, e.g. using Secure Authenticated Channels (SACs) and certificates and e.g. using MKB structures as used in CPPM and CPRM (see http://www.4centity.com ).
  • SACs Secure Authenticated Channels
  • MKB structures as used in CPPM and CPRM (see http://www.4centity.com ).
  • the content right should be made a personal/family right.
  • the user right should indicate if a global or the personal/family content right must be used.
  • Different content rights for a specific piece of content are allowed.
  • the user right indicates what specific content right should be used.
  • Content rights could contain revocation data for user rights and person ED devices or an instruction to contact to a certain revocation database before content is played back.
  • Time based rights could be implemented by requiring a heart beat mechanism to get time (see for example international patent application WO 03/058948, attorney docket PHNL020010).
  • a critical assumption is that content rights are only transferred to devices that are compliant and are operated by users that have the appropriate user rights. This assumption may not always be true, since in the real world it can not be held impossible for a secret key (required to decrypt some piece of content) to leak. If this happens, a hacker could create a new content right for the same piece of content but with fewer limitations than the original content right. In general, the content provider might not like the idea that anyone can create content rights, which makes it possible for any content to enter the system.
  • CP Only allowing content rights that are signed with the private key of the official content provider, denoted as CP works fine for securely introducing content into the system that is coming from CP. However, if users want to introduce personal content (like personal photos or home video recordings of their last holiday) into the system, they should first involve CP in order to create the required content rights. This is an undesired situation since CP should not have the power to control personal content. So a first step in order to allow personal content in the system is to allow content rights to be signed by someone else than the CP.
  • the first rule we introduce is that content rights that are not issued by CP must be signed by a compliant device. If this is not the case, the content rights should be rejected by any (compliant) device that wants to use these rights. This means that personal content can only enter the system via a compliant device. Such a compliant device should furthermore check that there is no watermark present in the content. Watermarked content is originally coming from CP and therefore users are not allowed to create their own content rights for such content.
  • a fingerprint of a content item is a representation of the information signal in question which does not change when the content item is modified slightly.
  • fingerprints are sometimes also known as "(robust) hashes".
  • the term robust hashes refers to a hash function which, to a certain extent, is robust with respect to data processing and signal degradation, e.g. due to compression decompression, coding, AD/DA conversion, etc.
  • Robust hashes are sometimes also referred to as robust summaries, robust signatures, or perceptual hashes.
  • An example of a method of generating a fingerprint is disclosed in international patent application WO 02/065782 (attorney docket PHNL010110).
  • this embodiment comprises the following: Content from the 'official' content provider CP must be watermarked and content rights must contain fingerprint information about the content they are linked to. When content rights for personal content are created, compliant devices (or content/service provider) must check that there is no watermark present.
  • Compliant devices must add fingerprint information to a new content right (for personal content) before signing it.
  • Compliant devices that want to use content rights must check if the fingerprint information in the content right matches with the actual content.
  • a compliant device will only play the content if it has the appropriate content rights signed by the official content provider (of which the public key is known). If no watermark is detected, the content is classified as 'personal content' and the accompanying content rights may be signed by any compliant device.
  • this personalization domainization is done by encrypting the content right using an encryption key for which a corresponding decryption key is available to the devices in the authorized domain.
  • the decryption key typically would be available in the identification device.
  • the content provider encrypts a content right with an extra key CREK (Content Right Encryption Key) as follows: E ⁇ CREK ⁇ [Content right].
  • CREK Content Right Encryption Key
  • this key is encrypted with the public domain key (PDK) available to all domain members in their ID card (the content provider has obtained this key during a buy transaction from the ID-card and therefore can use it).
  • the encrypted CREK will be concatenated with the content right: E ⁇ PDK ⁇ [CREK]
  • the protocol for playback may operate as follows:
  • Playback device sends to user id-device: E ⁇ PDK ⁇ [CREK]
  • the user id-device retrieves CREK by decryption with the SDK and then encrypts CREK with the public key of playback device PK_Playback_device.
  • the playback device can now retrieve the CREK and subsequently decrypt the content rights and decrypt the content.
  • Table 1 lists system functions and co ⁇ esponding data elements.
  • Table 2 lists data elements, their function and contents. Many of these functions are of course optional.
  • T tag that specifies the permission being granted
  • the subject may further delegate the permission (which is specified in the tag) to other keys and names.
  • An authorized domain can be formed by letting some central authority issue SPKI name-certificates that bind a person's public key to an official unique identifier (for example, name and address information).
  • An example of such a certificate (in SPKI form) in which 'address authority' AA is providing access to person 'PI': Certl SK_AA ⁇ (K, A, S, V) ⁇ meaning a 4-tuple signed by SK AA (i.e. the private key of the address authority), where:
  • K PK_AA
  • A street address and number
  • K PK_AA
  • the delegation bit D is set to false, which indicates that the user is not allowed to delegate the user right (of content right CRl) to another user. If the delegation bit is set to 'true', then person PI is allowed to delegate the permission.
  • the total system can be designed so that compliant devices still allow other users within the same (authorized) to use CRl and play the content item. The delegation bit in this case prevents spreading of rights outside of the authorized domain.
  • a user obtains access to content via a device.
  • a compliant device will only provide access (decrypt content with the key that is in the Content Right) if the user owns the proper set of certificates. Note that probably the device won't even get a content right if there is no authorized user!
  • the certificates belonging to a user can be retrieved from any location on the network or stored on the user's smartcard. Content rights may also be stored on the smartcard. This is required for playing content on offline devices. It might be useful to allow content rights to be stored on some trusted proxy of the user that is accessible through the network. This way the user can still retrieve content rights that are not stored on his smart card and are not available elsewhere on the network.
  • the following list presents some fields in a certificate that might be required (or useful) when implementing the solution.
  • the list only shows fields, other than the standard SPKI certificate fields that were mentioned before: signing date device identifier on which certificate was signed (facilitates collection of reputation-info of devices which can lead to revocation in the device compliancy subsystem) copy once / copy never / copy no-more and similar flags locations/servers of revocation system
  • the invention provides for methods of and devices (Dl) for authorizing an operation requested by a first user (P2) on a content item (Cl) in accordance with a user right (URl).
  • the user right may identify the first user or a second user (PI) and authorizes the user in question to perform the requested operation on the content item. If the user right identifies the second user, the operation is authorized upon receipt of information linking a user right of the first user and the user right of the second user.
  • the information comprises one or more domain certificates (DCl, DC2) identifying the first and second users as members of the same authorized domain (AD).
  • DCl domain certificates
  • CRl content right

Abstract

Methods of and devices (D1) for authorizing an operation requested by a first user (P2) on a content item (C1) in accordance with a user right (UR1). The user right may identify the first user or a second user (P1) and authorizes the user in question to perform the requested operation on the content item. If the user right identifies the second user, the operation is authorized upon receipt of information linking a user right of the first user and the user right of the second user. Preferably the information comprises one or more domain certificates (DC1, DC2) identifying the first and second users as members of the same authorized domain (AD). Preferably a content right (CR1) enabling the operation is used, whereby the user right authorizes the second user to employ the content right.

Description

Method and device for authorizing content operations
The invention relates to methods of authorizing an operation requested by a first user on a content item. The invention further relates to devices arranged to perform an operation requested by a first user on a content item.
In recent years, the amount of content protection systems is growing in a rapid pace. Some of these systems only protect the content against illegal copying, while others are also prohibiting the user to get access to the content. The first category is called Copy Protection (CP) systems. CP systems have traditionally been the main focus for consumer electronics (CE) devices, as this type of content protection is thought to be cheaply implemented and does not need bi-directional interaction with the content provider. Some examples are the Content Scrambling System (CSS), the protection system of DVD ROM discs and DTCP, the protection system for IEEE 1394 connections.
The second category is known under several names. In the broadcast world, systems of this category are generally known as conditional access (CA) systems, while in the Internet world they are generally known as Digital Rights Management (DRM) systems. Recently new content protection systems have been introduced in which a set of devices can authenticate each other through a bi-directional connection. Based on this authentication, the devices will trust each other and this will enable them to exchange protected content. In the licenses accompanying the content, it is described which rights the user has and what operations he/she is allowed to perform on the content. The license is protected by means of some general network secret, which is only exchanged between the devices within a certain household, or, more generally, within a certain domain. This network of devices is thus called an Authorized Domain (AD). The concept of authorized domains tries to find a solution to both serve the interests of the content owners (that want protection of their copyrights) and the content consumers (that want unrestricted use of the content). The basic principle is to have a controlled network environment in which content can be used relatively freely as long as it does not cross the border of the authorized domain. Typically, authorized domains are centered around the home environment, also referred to as home networks. Of course, other scenarios are also possible. A user could for example take a portable television with him on a trip, and use it in his hotel room to access content stored on his Personal Video Recorder at home. Even though the portable television is outside the home network, it is a part of the user's authorized domain.
The trust necessary for secure intercommunication between devices, is based on some secret, only known to devices that were tested and certified to have secure implementations. Knowledge of the secret is tested using an authentication protocol. The best currently known solutions for these protocols are those which employ 'public key' cryptography, which use a pair of two different keys. The secret to be tested is then the secret key of the pair, while the public key can be used to verify the results of the test. To ensure the correctness of the public key and to check whether the key-pair is a legitimate pair of a certified device, the public key is accompanied by a certificate, that is digitally signed by a Certification Authority, the organization which manages the distribution of public/private key-pairs for all devices. In a simple implementation the public key of the Certification Authority is hard-coded into the implementation of the device.
A number of implementations of AD-like DRM systems are known. However, they typically suffer from a number of limitations and problems which make their deployment and acceptance in the market difficult. In particular, an important problem which has not been addressed sufficiently is how to manage and maintain an authorized domain structure which allows a consumer to exercise the rights he has obtained anytime and anywhere he chooses. Current AD solutions typically restrict consumers to a particular and limited set of systems, and do not provide the desired flexibility.
A common approach is to provide the person who buys a content right (a right needed to access a content item, typically containing a necessary decryption key) with a secure personal device like a smart card. During playback, the smart card shares this decryption key with a compliant playback device. The person can now access content as long as he has his smart card with him. This solution suffer from the drawback that a smart card has a limited amount of memory, which means that not all rights can be stored on the card. An improvement to this system could be to encrypt the content right with the public key of the smart card and to store the rights somewhere, e.g. on multiple locations and e.g. together with the content item. However, it is now not all clear how the content right can be shared with the person's family. At present it is possible for one member of a family to purchase (a right to) a content item, for example a song stored on a compact disc, which he can share with the other members of that family. Consumers are used to such sharing and they expect it from AD-based systems as well. Copyright law typically permits such activities as long as they stay within a particular family. DRM systems try to prevent copying to any third party, and so inadvertently also block this permitted type of activity. The content right could be re-encrypted with the respective public keys of the respective smart cards of the family members. This takes a lot of time and processing power, as all rights have to be processed individually. To check whether it actually is a family member who owns a particular smart card to which the re-encrypted content right is to be supplied a family identifier could be added to the smart card. However, this is not a flexible solution, as it is now very difficult to delete or revoke the content right on one family member's smart card.
It is an object of the present invention to provide authorization methods which allows rights management based on persons instead of devices.
This object is achieved according to the present invention in a method of authorizing an operation requested by a first user on a content item in accordance with a content right containing necessary information for performing the requested operation on the content item and a user right identifying the first user and authorizing the first user to employ the content right. The user right is a single connection between one user and a content right. The content right is required to access a piece of content, for example because it contains a necessary decryption key. Rights management based on persons is achieved by issuing more user rights authorizing persons to employ the content right.
This object is achieved according to the present invention in a method of authorizing an operation requested by a first user on a content item in accordance with a user right identifying a second user and authorizing the second user to perform the requested operation on the content item, in which the operation is authorized upon receipt of information linking a user right of the first user and the user right of the second user. Through user rights, persons can be authorized to perform operations regardless of which devices they wish to use. The linking information allows users to share rights with each other, regardless of devices the content resides on or of any information such as content rights that may be necessary to perform operations on the content. Thus rights management is based on persons instead of devices. Preferably the linking information comprises one or more domain certificates identifying the first and second users as members of the same authorized domain. It is desirable to be able to share access to the content item with members of a particular family, or more generally a particular domain. To this end, domain certificates (certificates to indicate a group or domain) are issued by a trusted third party to define which persons are member of a particular domain. If the first user now is not authorized to perform the operation, but there is a second user in the same domain who does have such a right, then the first user is still allowed to perform the operation. Preferably user rights can be anywhere in the system. It is now possible
To personally buy rights to access (certain pieces of) content,
To share such right within the family/household,
To be able to exercise such rights on any device and anywhere (in the world) as a person within the family, To be able to transfer such rights to others (both inside and outside the family), To be able to revoke and/or renew rights if necessary, To cope with changes of the family structure, To cope with disclosure of rights secrets and illegal acts (e.g. hacking of devices).
In an embodiment the method comprises receiving a content right containing necessary information for performing the requested operation on the content item, the user right of the second user authorizing the second user to employ the content right. Any person can now obtain a user right and thereby exercise the content right, independently of any other user rights that other persons may possess. The content right makes it possible that a device can perform the operation, for example because it contains a necessary decryption key to access the content. A user right authorizes a particular user to employ the content right on the device. This device must check if the right is available and the user is available. A second user is authorized if also a correct domain certificate is available, which connects the two users.
In a further embodiment the operation is not authorized if the content right does not identify the authorized domain. This way content rights can be restricted to the particular authorized domain. Not only does this make rights management more fine-grained, it also limits the damage that can be done by a hacker who manages to obtain decryption keys (provided by content rights) by compromising a device in a particular authorized domain. To further extend this embodiment, optionally the content right could be at least partially encrypted using an encryption key for which the corresponding decryption key is available to devices in the domain. This way the content right is not usable outside the domain.
It is a further object of the present invention to provide devices which allow rights management based on persons. This object is achieved according to the present invention in a device arranged to perform an operation requested by a first user on a content item in accordance with a content right containing necessary information for performing the requested operation on the content item and a user right identifying the first user and authorizing the first user to employ the content right. This object is achieved according to the present invention in a device arranged to perform an operation requested by a first user on a content item in accordance with a user right identifying a second user and authorizing the second user to perform the requested operation on the content item, being arranged to authorize the operation upon receipt of of information linking a user right of the first user and the user right of the second user. Preferably the linking information comprises one or more domain certificates identifying the first and second users as members of the same authorized domain. It is desirable to be able to share access to the content item with members of a particular family, or more generally a particular domain.
In an embodiment the device is arranged to receive a content right containing necessary information for performing the requested operation on the content item, the user right of the second user authorizing the second user to employ the content right. Preferably then at least a portion of the content right is encrypted using an encryption key for which a corresponding decryption key is available to the device. This way, only devices in a particular authorized domain can employ the content right, thereby effectively restricting the content right to the particular domain.
In a further embodiment the content right is provided with a digital signature allowing verification of the authenticity of the content right. Preferably the device then is arranged to perform the operation if the digital signature can be verified successfully using a digital certificate associated with an authorized content provider. This way only the content provider himself can create 'official' content rights.
In a further embodiment the device is arranged to perform the operation if the digital signature can be verified successfully using a digital certificate associated with a particular device. This way, personal content (created on that particular device) can also be played back or otherwise used, without the need to involve a third party. In a refinement of this embodiment the device is arranged to refuse to perform the operation if the digital signature cannot be verified successfully using a digital certificate associated with an authorized content provider and a digital watermark associated with the authorized content provider is present in the content item. This way malicious users cannot create content rights for 'official' content, even when they try to pass the 'official' content of as personal content, e.g. by creating an analog recording from a television screen.
In a further embodiment the device is arranged to determine a robust fingerprint for the content item and to refuse to perform the operation if the determined robust fingerprint does not match a robust fingerprint comprised in the content right. This way malicious users cannot create content rights for personal content and subsequently try to use those for 'official' content.
These and other aspects of the invention will be apparent from and elucidated with reference to the illustrative embodiments shown in the drawings, in which:
Fig. 1 illustrates a model of an authorized domain (AD) based on persons, rights and content;
Fig. 2 illustrates an example of a device that is being operated by a user carrying a smartcard who wants to perform an operation on content item; and Fig. 3 illustrates how a person can employ another person's user right to exercise a content right if both belongs to the same AD.
Throughout the figures, same reference numerals indicate similar or corresponding features. Some of the features indicated in the drawings are typically implemented in software, and as such represent software entities, such as software modules or objects.
Fig. 1 illustrates a model of an authorized domain (AD) based on persons, rights and content. The authorized domain AD contains content Cl, C2, C3, ...Ck, rights Rl, R2, R3, ..., Rm and persons PI , P2, P3, ... Pn. The model also shows that content items, e.g. content item Ci, may be imported into the domain or exported from the domain and that persons, e.g. person Pj, may register to the domain or de-register from the domain. For more information on authorized domain architecture and implementation options, the reader is referred to international patent application WO 03/047204 (attorney docket PHNL010880) or international patent application serial number PCT/TB03/01940 (attorney docket
PHNL020455).
Some example functions that can be used in the domain given the model of
Fig. 1 are: AD persons membership management:
Person identification (To which AD does a person belong)
Registering of persons to an AD
De-registering persons from an AD
AD person-rights link management: Persons-rights link identification (Which person may use a right)
Linking a right to a person
Disconnect a person-right link
We have to note that in practice content can only be accessed/used by means of a user operating a device. In the following text we assume that devices used in the system are compliant and "public" devices. This means that a device will adhere to certain operation rules (e.g. will not illegally output content on a digital interface) and that ownership of a device is not important (public). Device compliancy management, i.e. compliant device identification, renewability of devices, and revocation of devices, will be assumed to be in place (using known techniques), and will not be considered further here. The content right can be used to do device compliancy management.
The user right is a single connection between one user and a content right
(which is required to decrypt a piece of content). By introducing this user right we now have five main entities in our system that could work as follows: content: content items are encrypted (there are many options, for example with a unique key per content title) and can be anywhere in the system. content right: contains rules (e.g. restricted to viewers 18 years or older, or European market only) and key(s) to access a certain content item. The system is flexible in the sense that content rights can be made unique per content title or even unique per specimen (copy) of content. Content rights should be only transferred to compliant devices. A more secure rule is to enforce that content rights may be only transferred to compliant devices that are operated by authorized users (i.e. users that are authorized to have access to the specific content right by means of their user rights). Content rights might also be stored together with the content on for example an optical disk. user right: a certificate issued by the content provider that authorizes a person to use a certain content right (belonging to a certain piece of content). User rights can be in principle anywhere in the system. The SPKI authorization certificate (implemented compliant to e.g. X.509) could be used to implement such a user right. device: A (compliant) device can identify a user by means of a personalized identification device (such as a smart-card) or e.g. a biometric (or both) and collect certificates (e.g. from the smartcard, or from other devices) that prove that the user is allowed to use a certain content right. This content right could be obtained from the smart-card where it was stored (if it was stored there), or be obtained (securely transferred) from another device on the network (after showing the appropriate certificate chain). user: A user is identified by some biometric or preferably by a personalized identification device (e.g. a smartcard) that he/she is carrying. The latter is preferred since it allows users to carry rights with them (for accessing content on off-line devices) and generate signatures to issue their own certificates (user rights). The identification device may itself be protected by a biometric authentication mechanism, so that anyone other than the legitimate owner cannot use the identification device.
Fig. 2 illustrates an example of a device Dl that is being operated by a user carrying a smartcard ID who wants to perform an operation on content item Cl, for example a rendering of the content item, a recording of the content item, a transfer of the content item or a creation of a copy of the content item. The device Dl obtains a user right, preferably embodied as a digital certificate, from a remote database URDB on the Internet and stores it in local storage medium UR.
The content rights, also preferably embodied as digital certificates, that are required to perform the operation on the content item Cl are obtained from a second device D2 and stored in local storage medium CR. Before starting the transfer of content rights, device D2 checks the user rights of the user (this depends on the rules for transferring content rights as is said before) and whether the device Dl is compliant. To this end devices Dl and D2 are provided with respective authentication modules AUTH. These modules could for example comprise respective private keys from a public/private key pair and certificates for the associated public keys, allowing public-key based authentication.
The operation on the content item Cl is authorized if there is a content right containing necessary information for performing the requested operation on the content item Cl and a user right identifying the first user and authorizing the first user to employ the content right. In other systems, the use of a separate content right may not be necessary, for example if all operations on content in the system are always authorized.
If there is no user right authorizing the user to perform the operation, or there is no user right authorizing the first user to employ the content right, then normally the operation is not performed. However, the operation may still be authorized if information linking a user right of the first user and the user right of the second user is received. Such information can be of any type, for example a certificate identifying both users or a listing on a Web server indicating the user rights are linked. The information could also be contained in one (or both) of the user rights themselves. Preferably it is provided in the form of one or more domain certificates, as discussed below.
The presented solution assumes the availability of a public key infrastructure in which users, content owners and other trusted third parties maintain their own unique private/public key pair and can issue certificates by signing with their private key. One of the possibilities is to use certificates as defined in the SPKI/SDSI framework. In order to introduce the notion of Authorized Domain, we propose to introduce another type of certificate into the system. A certificate, which we call a domain certificate, is issued by a (trusted) third party that defines what persons/entities belong to a certain domain. Such a certificate contains the identifier (e.g. biometric, public key) of the subject (a person) and the identifier (e.g. name, public key) of the authorized domain the subject is declared to be part of. The certificate is signed with the private key of the issuing trusted party. Furthermore the certificate must contain the usual fields like 'date of issue' and 'validation date' in correspondence with an appropriate revocation system. The SPKI 'name certificate' could be used to implement this domain certificate.
For example, one can now define one household-domain to every user, which defines the household a person is living in. This could be done by letting the municipality (or a representative thereof) issue a certificate declaring the registered street and address of a user. Such a certificate creates a single connection between a person (user) and his family.
The domain certificates can be implemented in a variety of ways. In one embodiment, every user is issued a separate domain certificate identifying him as a member of a particular authorized domain. A comparison of the respective AD identifiers in two respective domain certificates establishes whether two users are members of the same domain. This way every domain certificate can be managed separately and a person's domain certificate is not affected when another person joins or leaves the authorized domain. In another embodiment, identifiers for members of a single authorized domain are enumerated in a single domain certificate. This way it is much easier to check whether two persons belong to a single authorized domain. Furthermore, every person now automatically has the AD membership information of all other members of his domain available, without requiring a separate certificate to be retrieved. However, when a new person joins the AD, all persons must be issued new domain certificates.
Granting access to content to people living in the same authorized domain can now be done as follows. If a person PI living in authorized domain (household) AD has the user right to exercise the content right CRl to e.g. play back content item Cl, a second person P2 could also exercise the right CRl if he belongs to the same household AD by presenting the following certificates to a compliant device Dl : user right URl signed by content provider showing PI has the right to exercise CRl domain certificate DC1 signed by municipality showing PI is a member of AD domain certificate DC2 signed by municipality showing P2 is a member of AD This situation is depicted in Fig. 3. Note that it is assumed that the device Dl knows a certain root public key in order to check that a certificate was signed by the true authorized issuer.
Optionally the content provider may only allow other persons within the domain to play the content under certain circumstances. In this case this should be stated in the user right by means of some extra bits. Besides stating the permissions concerning usage within the domain, other flags or bits could be added to user right certificates. For example bits dealing with permission for a first generation copy or for one-time playback could be added in the certificates. Such bits could also be added to the content right CRl, and then they would apply regardless of which user right was used to exercise the content right. The system also allows for so-called cross authorized-domain rights. These are rights that allow content to cross the borders of the authorized domain. This can be achieved by adding extra fields in the user right that indicate the allowed cross-domain behavior that compliant devices have to obey. A field in the user right could for example contain a statement like 'XAD=no' meaning that no user rights certificates should be issued to users outside the household authorized domain. The delegation tag in SPKI authorization certificates could be used for this purpose. This way, serial copy management can be implemented that can limit copies up to one generation. It may also be desirable to implement 'copy-once' restrictions. To make the system well manageable and consistent, several root public keys need to be known by the device. This is necessary in order to check certificates (and certificate chains) that exist in the system. Some of the root/master keys of trusted third parties within the system that the device must know are listed below: root key of content owner or representative: for checking user rights (User rights management). root key of device compliancy manager: for checking whether other devices in the system are
(still) compliant (Device compliance management). root key of naming authority (e.g. government that issues household-domain certificates): for checking the relations within an authorized household domain (Domain management). root key of user management: for checking whether key pairs of individual users
(Smartcards) are authentic and have not been compromised (User management).
Ownership of rights and the composition of a family (or other domain) may vary over time. Besides, devices may be hacked or secret keys might become known. We therefore have to consider dynamic behavior for the following cases:
Domain (Family membership) management: The composition of a family may change.
User rights management: User rights may change; A user may give away the right to someone else.
User management: An ID device may be hacked, or a person may e.g. pass away. Device compliance management: Devices may be hacked and then must be revoked/renewed. The composition of a family is represented in a certificate, i.e. the certificate lists the members of the family. The system deals with changes in the family composition by using domain certificates, listing the family members, with limited validity date. After the validation date has expired the family must apply for a new certificate at some trusted third party. The community administration could for example act as such a trusted third party and take into account changes in the family composition.
Note that dates/time can be easily, reliably, and securely transferred to devices by including this date/time in content or user rights. This enables the mechanism that a device may only accept a domain certificate if its date is later than the date in the user rights or content right. The device may also store the date/time for future use as a lower boundary to the "current" time. Also some kind of sequence numbering mechamsm could be used in usage and content rights to achieve similar effect for accepting the domain certificate.
A user right may also be used to distribute new domain certificates to a family.
This even seems preferable. If a family member wants to use and retrieve the user right he then automatically receives the new domain certificate. This method implies that the usage certificate distributor also distributes the domain certificates (, which might be made by another party of course).
A revocation mechanism for household certificates seems not very useful as such revocation certificates could be blocked and their distribution cannot be guaranteed.
Revocation messages could be distributed with user rights (or with local content rights). User rights will also be dealt with using validity dates. Such a validity date may also be set to infinite. We now, however, still need to deal with transfer of user rights
(i.e. a move operation). The most difficult case is for a user right with an infinite validity date. Some possible solutions are:
Do not provide this option.
Do transfer with use of the service provider, give new user right, revoke old right:
Send a revocation message to the user ID device (if available) and store it. When a user wants to access content the device, which is used to access the content, will consult the revocation list in the user ID device, and
Put a revocation message in the domain certificate (Certificate might become very large, not very scalable solution) and require that besides presenting the usage certificate also the domain certificate must be presented when accessing content.
Transfer the user right with help of the user ID device (new signature with own private key), add revocation data in ED device, and transmit revocation data to other family members.
Issue user certificates with validity dates, which at some moment in time need to be renewed.
Require that an external revocation database is consulted before using a user right.
As stated before a person may be identified on the basis of his biometric data or on the basis of an ID device (e.g. a wireless smart card, the mobile telephone, etc.) belonging to that person. Biometric data will go along with the person and managing these data is "automatic". An ID device, however, could be hacked and duplicated, lost, etc. To handle such "events" requires care management of ID devices.
Suppose an ID device operates with some public key algorithm using a public/private key pair. The best seems here to also have validity dates for ED devices (or that at a certain moment in time, for new content a new ED device is required). In case a private key becomes known, first of all the device ID should be revoked. Such a revocation message might be included in new content rights or in new user rights. Furthermore the person should be removed from the family certificate. This gives an extra hurdle to hackers being now unable to access content owned by family members. Note that updating of the ID device could be done automatically when a person buys content, i.e. obtains a usage certificate.
Device compliancy management can be done on the basis of distribution of content rights. Only compliant devices are allowed to obtain content rights. Different technologies might be used to perform device management and secure content right distribution, e.g. using Secure Authenticated Channels (SACs) and certificates and e.g. using MKB structures as used in CPPM and CPRM (see http://www.4centity.com ).
One particular solution uses two types of content rights: global rights (can be used all over the world) and personal/family rights (should remain locally at the user who bought it and may not be distributed). The reason is that this enables the use of counting mechanisms in rights, which is not possible with user rights, which have been signed by a service provider.
In the case of specific/counting rights the content right should be made a personal/family right. The user right should indicate if a global or the personal/family content right must be used. To make it more generic: Different content rights for a specific piece of content are allowed. The user right indicates what specific content right should be used. Content rights could contain revocation data for user rights and person ED devices or an instruction to contact to a certain revocation database before content is played back. Time based rights could be implemented by requiring a hart beat mechanism to get time (see for example international patent application WO 03/058948, attorney docket PHNL020010).
A critical assumption is that content rights are only transferred to devices that are compliant and are operated by users that have the appropriate user rights. This assumption may not always be true, since in the real world it can not be held impossible for a secret key (required to decrypt some piece of content) to leak. If this happens, a hacker could create a new content right for the same piece of content but with fewer limitations than the original content right. In general, the content provider might not like the idea that anyone can create content rights, which makes it possible for any content to enter the system.
The best way to solve the problem sketched above, is for the content provider to digitally sign content rights. Furthermore it must be enforced that (compliant) devices check the signatures on content rights and only accept content rights that are properly signed by the content provider. Therefore devices must know the (root) public key of the content provider. Of course it is not mandatory for content rights to be signed. An additional advantage of this method is the fact that less (root) public keys have to be known to the compliant device. A compliant device has to know (roots of) public keys of amongst others the issuer of user rights, device compliancy manager and naming authority. These values would have to be stored in the device in some way. However if content rights are signed by the content provider, these public keys can be simply added to the content right. Only the (root) public key of the content provider has to be known by the device. This way the content provider can determine who is authorized to issue user rights, compliancy certificates and naming certificates.
Furthermore, information concerning where to check certificate revocation information can be added to content rights. A hacker can not change all this additional information in the content right since a valid content right must be digitally signed by the content provider.
Only allowing content rights that are signed with the private key of the official content provider, denoted as CP works fine for securely introducing content into the system that is coming from CP. However, if users want to introduce personal content (like personal photos or home video recordings of their last holiday) into the system, they should first involve CP in order to create the required content rights. This is an undesired situation since CP should not have the power to control personal content. So a first step in order to allow personal content in the system is to allow content rights to be signed by someone else than the CP.
The first rule we introduce is that content rights that are not issued by CP must be signed by a compliant device. If this is not the case, the content rights should be rejected by any (compliant) device that wants to use these rights. This means that personal content can only enter the system via a compliant device. Such a compliant device should furthermore check that there is no watermark present in the content. Watermarked content is originally coming from CP and therefore users are not allowed to create their own content rights for such content.
The solution presented so far is not completely safe yet, since it allows for a typical attack. Assume that a user has created a content right for a certain piece of self-made content. Now a malicious user could substitute the content by another piece of content after the content right was made (and thus after the compliant device signed it)! Therefore he has to (re)encrypt the (illegal) content with the content key that is in the approved content right and give this content the same identifier as the self-made content for which the content right was made. So lots of illegal content can enter the system if it is encrypted with the same (leaked) content key.
In order to solve this issue, there must be a secure link between a content right and the actual piece of content. The usage of fingerprints of content can provide this link. A fingerprint of a content item is a representation of the information signal in question which does not change when the content item is modified slightly. Such fingerprints are sometimes also known as "(robust) hashes". The term robust hashes refers to a hash function which, to a certain extent, is robust with respect to data processing and signal degradation, e.g. due to compression decompression, coding, AD/DA conversion, etc. Robust hashes are sometimes also referred to as robust summaries, robust signatures, or perceptual hashes. An example of a method of generating a fingerprint is disclosed in international patent application WO 02/065782 (attorney docket PHNL010110).
A content right now should contain some extra information stating what fingerprint can be found in exactly what part of the content. So instead of adding fingerprint information of the total piece of content (which would be a large amount of data) the fingerprint information at certain specific points in time (together with these time values) can be added. The compliant device adds this fingerprint information to the content right before signing it. When a content right is used (e.g. to play content) the compliant device must check whether the fingerprint data that is included in the content right can also be found in the actual content (at the indicated points in time). If this is not the case, the content right must be rejected.
Summarizing, this embodiment comprises the following: Content from the 'official' content provider CP must be watermarked and content rights must contain fingerprint information about the content they are linked to. When content rights for personal content are created, compliant devices (or content/service provider) must check that there is no watermark present.
Compliant devices must add fingerprint information to a new content right (for personal content) before signing it. Compliant devices that want to use content rights must check if the fingerprint information in the content right matches with the actual content.
Like in the original system, the creator of a content right determines what (root) public keys of user right issuer, naming authority and device compliancy manager must be checked in order to access the content. So a user can authorize any party (including himself or his own device) to issue the accompanying user rights for his personal content. The idea of having input devices sign fingerprint information of content closely matches the ideas in international patent application serial number PCT/EB03/00803 (attorney docket PHNL020246). However, our solution is more specific and makes a clear distinction between official content from the content provider (watermarked) and personal content.
In the case that content is watermarked, a compliant device will only play the content if it has the appropriate content rights signed by the official content provider (of which the public key is known). If no watermark is detected, the content is classified as 'personal content' and the accompanying content rights may be signed by any compliant device.
As a further optional extension, it is possible to "personalize or domainize" content rights on the domain level. This can be done generally by having compliant devices arranged to refuse to perform the operation if the authorized domain is not identified in the content right. This way, if the content right identifies the "wrong" domain (or no domain at all) the person from the authorized domain cannot exercise it. This approach, however, has some risks, given the possibly enormous amount (tens of millions is possible) of future compliant devices: As one device gets hacked (and is not sufficiently fast revoked) this may be a leak to all content rights in the complete system.
Preferably this personalization domainization is done by encrypting the content right using an encryption key for which a corresponding decryption key is available to the devices in the authorized domain. The decryption key typically would be available in the identification device. The content provider encrypts a content right with an extra key CREK (Content Right Encryption Key) as follows: E {CREK} [Content right]. Subsequently this key is encrypted with the public domain key (PDK) available to all domain members in their ID card (the content provider has obtained this key during a buy transaction from the ID-card and therefore can use it). The encrypted CREK will be concatenated with the content right: E {PDK} [CREK] || E {CREK} [Content right] and then sent to the user together with the content (if required).
If we assume that all identification devices (e.g. smartcards) have the SDK (Private (secret) Domain Key) on board, then after user identification, the protocol for playback may operate as follows:
Playback device sends to user id-device: E {PDK} [CREK] || PK_Playback_device
The user id-device retrieves CREK by decryption with the SDK and then encrypts CREK with the public key of playback device PK_Playback_device.
Then the user id device sends to the playback device: E {PK_Playback_device} [CREK]
The playback device can now retrieve the CREK and subsequently decrypt the content rights and decrypt the content.
To summarize, in the following two tables the different data elements and their functions are listed. These tables are meant for illustrative purposes only and are not exhaustive. Table 1 lists system functions and coπesponding data elements.
Figure imgf000019_0001
Table 2 lists data elements, their function and contents. Many of these functions are of course optional.
Figure imgf000019_0002
Figure imgf000020_0001
An example of the best way to implement the invention, as presently contemplated by the inventors, will now be discussed. This implementation of the system uses the SPKJ/SDSI framework. See SPKI Certificate Theory (Internet RFC 2693) and Carl Ellison, Improvements on Conventional PKI wisdom, 1st annual PKI Research Workshop, April 2002. Implementation within the X.509 framework is also considered possible. It is assumed that every entity maintains its own public/private key pair. Public and private keys will be indicated with the symbols PK and SK respectively.
An SPKI name certificate is represented as a 4-tuple (K, A, S, V): K = issuer's public key A = local name being defined S = certificate's subject V = validity specification
An SPKI authorization certificate is represented as a 5-tuple (K, S, D, T, V): K = issuer's public key S = certificate's subject D = delegation bit
T = tag that specifies the permission being granted
V = validity specification
If the delegation bit is set to true, the subject may further delegate the permission (which is specified in the tag) to other keys and names.
An authorized domain can be formed by letting some central authority issue SPKI name-certificates that bind a person's public key to an official unique identifier (for example, name and address information). An example of such a certificate (in SPKI form) in which 'address authority' AA is providing access to person 'PI': Certl = SK_AA{(K, A, S, V)} meaning a 4-tuple signed by SK AA (i.e. the private key of the address authority), where:
K = PK_AA
A = street address and number
S = PK_P1 Note that for simplicity validation specifications are left out here. They should be chosen in conformance with the revocation and renewability system.
An alternative solution is to just group the PKs of all persons in the authorized domain in a single domain certificate. This has the additional advantage that only one domain certificate is needed. An example of how such a certificate might look like is Cert lb = SK_AA{(K, A, S, V)} meaning a 4-tuple signed by SK AA (i.e. the private key of the domain authority), where:
K = PK_AA
A = household certificate
S = PK_P1, PK_P2, PK P3, ... Now assume there is a Content Right CRl that holds the rules and keys that are required to play a certain piece of content. A content owner CO1 can authorize person PI by issuing the following certificate: Cert2 = SK_COl {(K, S, D, T, V)} with: K = PK_COl S = PK_P1 D = false T = CR1
In certificate Cert2 the delegation bit D is set to false, which indicates that the user is not allowed to delegate the user right (of content right CRl) to another user. If the delegation bit is set to 'true', then person PI is allowed to delegate the permission. The total system can be designed so that compliant devices still allow other users within the same (authorized) to use CRl and play the content item. The delegation bit in this case prevents spreading of rights outside of the authorized domain.
A user obtains access to content via a device. A compliant device will only provide access (decrypt content with the key that is in the Content Right) if the user owns the proper set of certificates. Note that probably the device won't even get a content right if there is no authorized user!
The certificates belonging to a user can be retrieved from any location on the network or stored on the user's smartcard. Content rights may also be stored on the smartcard. This is required for playing content on offline devices. It might be useful to allow content rights to be stored on some trusted proxy of the user that is accessible through the network. This way the user can still retrieve content rights that are not stored on his smart card and are not available elsewhere on the network.
The following list presents some fields in a certificate that might be required (or useful) when implementing the solution. The list only shows fields, other than the standard SPKI certificate fields that were mentioned before: signing date device identifier on which certificate was signed (facilitates collection of reputation-info of devices which can lead to revocation in the device compliancy subsystem) copy once / copy never / copy no-more and similar flags locations/servers of revocation system
It should be noted that the above-mentioned embodiments illustrate rather than limit the invention, and that those skilled in the art will be able to design many alternative embodiments without departing from the scope of the appended claims. In the claims, any reference signs placed between parentheses shall not be construed as limiting the claim. The word "comprising" does not exclude the presence of elements or steps other than those listed in a claim. The word "a" or "an" preceding an element does not exclude the presence of a plurality of such elements. The invention can be implemented by means of hardware comprising several distinct elements, and by means of a suitably programmed computer.
In the device claim enumerating several means, several of these means can be embodied by one and the same item of hardware. The mere fact that certain measures are recited in mutually different dependent claims does not indicate that a combination of these measures cannot be used to advantage. In summary, the invention provides for methods of and devices (Dl) for authorizing an operation requested by a first user (P2) on a content item (Cl) in accordance with a user right (URl). The user right may identify the first user or a second user (PI) and authorizes the user in question to perform the requested operation on the content item. If the user right identifies the second user, the operation is authorized upon receipt of information linking a user right of the first user and the user right of the second user. Preferably the information comprises one or more domain certificates (DCl, DC2) identifying the first and second users as members of the same authorized domain (AD). Preferably a content right (CRl) enabling the operation is used, whereby the user right authorizes the second user to employ the content right.

Claims

CLAIMS:
1. A method of authorizing an operation requested by a first user on a content item in accordance with a user right identifying a second user and authorizing the second user to perform the requested operation on the content item, in which the operation is authorized upon receipt of information linking a user right of the first user and the user right of the second user.
2. The method of claim 1 , in which the information comprises one or more domain certificates identifying the first and second users as members of the same authorized domain.
3. The method of claim 2, in which the one or more domain certificates comprise a first domain certificate identifying the first user as a member of an authorized domain, and a second domain certificate identifying the second user as a member of the authorized domain.
4. The method of claim 2, in which the one or more domain certificates comprise a single certificate identifying the first and second users as members of the authorized domain.
5. The method of claim 1, in which the operation comprises at least one of: a rendering of the content item, a recording of the content item, a transfer of the content item and a creation of a copy of the content item.
6. The method of claim 1 or 2, comprising receiving a content right containing necessary information for performing the requested operation on the content item, the user right of the second user authorizing the second user to employ the content right.
7. The method of claim 6 as dependent from claim 2, in which the operation is not authorized if the content right does not identify the authorized domain.
8. A device arranged to perform an operation requested by a first user on a content item in accordance with a user right identifying a second user and authorizing the second user to perform the requested operation on the content item, being arranged to authorize the operation upon receipt of of information linking a user right of the first user and the user right of the second user.
9. The device of claim 8, in which the information comprises one or more domain certificates identifying the first and second users as members of the same authorized domain.
10. The device of claim 9, in which the one or more domain certificates comprise a first domain certificate identifying the first user as a member of an authorized domain, and a second domain certificate identifying the second user as a member of the authorized domain.
11. The device of claim 9, in which the one or more domain certificates comprise a single certificate identifying the first and second users as members of the authorized domain.
12. The device of claim 8, being arranged to receive an identifier for the first user from an identification device and to perform the operation if the received identifier matches the identification of the first user in the user right of the first user.
13. The device of claim 8 or 9, being arranged to receive a content right containing necessary information for performing the requested operation on the content item, the user right of the second user authorizing the second user to employ the content right.
14. The device of claim 11, in which at least a portion of the content right is encrypted using an encryption key for which a coπesponding decryption key is available to the device.
15. The device of claim 13, in which the content right is provided with a digital signature allowing verification of the authenticity of the content right.
16. The device of claim 15, being arranged to perform the operation if the digital signature can be verified successfully using a digital certificate associated with an authorized content provider.
17. The device of claim 15, being aπanged to perform the operation if the digital signature can be verified successfully using a digital certificate associated with a particular device.
18. The device of claim 15, being arranged to refuse to perform the operation if the digital signature cannot be verified successfully using a digital certificate associated with an authorized content provider and a digital watermark associated with the authorized content provider is present in the content item.
19. The device of claim 13 or 15, being arranged to extract a public key from the content right and to use the extracted public key in determining whether the operation is authorized.
20. The device of claim 13, being arranged to determine a robust fingerprint for the content item and to refuse to perform the operation if the determined robust fingerprint does not match a robust fingerprint comprised in the content right.
21. The device of claim 13 as dependent from claim 9, being arranged to refuse to perform the operation if the authorized domain is not identified by the content right.
22. A method of authorizing an operation requested by a first user on a content item in accordance with a content right containing necessary information for performing the requested operation on the content item and a user right identifying the first user and authorizing the first user to employ the content right.
23. A device arranged to perform an operation requested by a first user on a content item in accordance with a content right containing necessary information for performing the requested operation on the content item and a user right identifying the first user and authorizing the first user to employ the content right.
24. The device of claim 23, in which at least a portion of the content right is encrypted using an encryption key for which a corresponding decryption key is available to the device.
25. The device of claim 23, in which the content right is provided with a digital signature allowing verification of the authenticity of the content right.
26. The device of claim 25, being arranged to perform the operation if the digital signature can be verified successfully using a digital certificate associated with an authorized content provider.
27. The device of claim 25, being aπanged to perform the operation if the digital signature can be verified successfully using a digital certificate associated with a particular device.
28. The device of claim 25, being arranged to refuse to perform the operation if the digital signature cannot be verified successfully using a digital certificate associated with an authorized content provider and a digital watermark associated with the authorized content provider is present in the content item.
29. The device of claim 23, being arranged to determine a robust fingerprint for the content item and to refuse to perform the operation if the determined robust fingerprint does not match a robust fingerprint comprised in the content right.
30. The device of claim 23, being aπanged to receive an identifier for the first user from an identification device and to perform the operation if the received identifier matches the identification of the first user in the user right.
PCT/IB2003/004538 2002-10-22 2003-10-15 Method and device for authorizing content operations WO2004038568A2 (en)

Priority Applications (5)

Application Number Priority Date Filing Date Title
US10/531,939 US20060021065A1 (en) 2002-10-22 2003-10-15 Method and device for authorizing content operations
BR0315550-1A BR0315550A (en) 2002-10-22 2003-10-15 Method for authorizing an operation requested by a first user on a content item, and device arranged to perform an operation requested by a first user on a content item
AU2003267764A AU2003267764A1 (en) 2002-10-22 2003-10-15 Method and device for authorizing content operations
EP03748459A EP1556748A2 (en) 2002-10-22 2003-10-15 Method and device for authorizing content operations
JP2004546260A JP2006504176A (en) 2002-10-22 2003-10-15 Method and apparatus for permitting content operation

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
EP02079390 2002-10-22
EP02079390.7 2002-10-22

Publications (2)

Publication Number Publication Date
WO2004038568A2 true WO2004038568A2 (en) 2004-05-06
WO2004038568A3 WO2004038568A3 (en) 2004-07-29

Family

ID=32116281

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/IB2003/004538 WO2004038568A2 (en) 2002-10-22 2003-10-15 Method and device for authorizing content operations

Country Status (9)

Country Link
US (1) US20060021065A1 (en)
EP (1) EP1556748A2 (en)
JP (1) JP2006504176A (en)
KR (1) KR20050074494A (en)
CN (1) CN100403209C (en)
AU (1) AU2003267764A1 (en)
BR (1) BR0315550A (en)
RU (1) RU2352985C2 (en)
WO (1) WO2004038568A2 (en)

Cited By (30)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
GB2418271A (en) * 2004-09-15 2006-03-22 Vodafone Plc Digital rights management in a domain
WO2006070330A1 (en) * 2004-12-28 2006-07-06 Koninklijke Philips Electronics N.V. Method and apparatus for digital content management
WO2006075260A1 (en) * 2005-01-11 2006-07-20 Koninklijke Philips Electronics N.V. A method and apparatus for authorized domain management
JP2006260471A (en) * 2005-03-18 2006-09-28 Sony Corp Package media providing system and its method as well as package media production device
WO2006082549A3 (en) * 2005-02-04 2006-11-02 Koninkl Philips Electronics Nv Method, device, system, token creating authorized domains
WO2007036831A2 (en) * 2005-09-30 2007-04-05 Koninklijke Philips Electronics N.V. Improved drm system
WO2007047846A2 (en) 2005-10-18 2007-04-26 Intertrust Technologies Corporation Methods for digital rights management
EP1783654A1 (en) * 2004-07-27 2007-05-09 Sony Corporation Information processing device and method, recording medium, and program
WO2007061453A2 (en) * 2005-11-17 2007-05-31 Sony Ericsson Mobile Communications Ab Digital rights management based on device proximity
US20070186111A1 (en) * 2004-05-03 2007-08-09 Alain Durand Certificate validity checking
JP2008507220A (en) * 2004-07-19 2008-03-06 ソニー ドイチュラント ゲゼルシャフト ミット ベシュレンクテル ハフツング Audio / video content protection method
JP2008518349A (en) * 2004-11-01 2008-05-29 コーニンクレッカ フィリップス エレクトロニクス エヌ ヴィ Improved access to your domain
WO2008090402A1 (en) * 2007-01-25 2008-07-31 Psitek (Proprietary) Limited A system and method of transferring digital rights to a media player in a drm environment
WO2009003708A1 (en) * 2007-07-05 2009-01-08 Fraunhofer-Gesellschaft zur Förderung der angewandten Forschung e.V. Device and method for digital rights management
JP2009503673A (en) * 2005-07-25 2009-01-29 コーニンクレッカ フィリップス エレクトロニクス エヌ ヴィ How to control access to content
WO2009014734A2 (en) * 2007-07-23 2009-01-29 Intertrust Technologies Corporation Tethered device systems and methods
WO2009014733A1 (en) * 2007-07-23 2009-01-29 Intertrust Technologies Corporation Dynamic media zones systems and methods
JP2010506325A (en) * 2006-10-12 2010-02-25 コーニンクレッカ フィリップス エレクトロニクス エヌ ヴィ Authorization area specific to the license
AU2010212301B2 (en) * 2003-06-05 2012-03-15 Intertrust Technologies Corporation Digital Rights Management Engine Systems and Methods
US8239962B2 (en) 2004-05-17 2012-08-07 Koninlijke Philips Electronics N.V. Processing rights in DRM systems
US8687801B2 (en) 2006-01-03 2014-04-01 Samsung Electronics Co., Ltd. Method and apparatus for acquiring domain information and domain-related data
US8752190B2 (en) 2005-05-19 2014-06-10 Adrea Llc Authorized domain policy method
US8761398B2 (en) 2006-05-02 2014-06-24 Koninkljijke Philips N.V. Access to authorized domains
US8813191B2 (en) 2006-02-15 2014-08-19 Thomson Licensing Method and apparatus for controlling the number of devices installed in an authorized domain
US8863239B2 (en) 2004-03-26 2014-10-14 Adrea, LLC Method of and system for generating an authorized domain
US9009308B2 (en) 2003-07-24 2015-04-14 Koninklijke Philips N.V. Hybrid device and person based authorized domain architecture
WO2016087750A1 (en) * 2014-12-04 2016-06-09 Orange Method of managing the right of access to a digital content
US9589110B2 (en) 2011-04-11 2017-03-07 Intertrust Technologies Corporation Information security systems and methods
US9626667B2 (en) 2005-10-18 2017-04-18 Intertrust Technologies Corporation Digital rights management engine systems and methods
US10528704B2 (en) 2002-12-30 2020-01-07 Koninklijke Philips N.V. Divided rights in authorized domain

Families Citing this family (46)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR100568233B1 (en) * 2003-10-17 2006-04-07 삼성전자주식회사 Device Authentication Method using certificate and digital content processing device using the method
US20050122345A1 (en) * 2003-12-05 2005-06-09 Kirn Kevin N. System and method for media-enabled messaging having publish-and-send feature
US9286445B2 (en) * 2003-12-18 2016-03-15 Red Hat, Inc. Rights management system
KR20070009983A (en) * 2004-01-22 2007-01-19 코닌클리케 필립스 일렉트로닉스 엔.브이. Method of authorizing access to content
JP4682520B2 (en) * 2004-02-25 2011-05-11 ソニー株式会社 Information processing apparatus, information processing method, and computer program
KR100601667B1 (en) * 2004-03-02 2006-07-14 삼성전자주식회사 Apparatus and Method for reporting operation state of digital right management
US20050229005A1 (en) * 2004-04-07 2005-10-13 Activcard Inc. Security badge arrangement
CN1961605A (en) * 2004-05-28 2007-05-09 皇家飞利浦电子股份有限公司 Privacy-preserving information distributing system
US7568102B2 (en) * 2004-07-15 2009-07-28 Sony Corporation System and method for authorizing the use of stored information in an operating system
US8219807B1 (en) * 2004-12-17 2012-07-10 Novell, Inc. Fine grained access control for linux services
US8271785B1 (en) 2004-12-20 2012-09-18 Novell, Inc. Synthesized root privileges
US20100071070A1 (en) * 2005-01-07 2010-03-18 Amandeep Jawa Managing Sharing of Media Content From a Server Computer to One or More of a Plurality of Client Computers Across the Computer Network
JP5065911B2 (en) * 2005-01-24 2012-11-07 コーニンクレッカ フィリップス エレクトロニクス エヌ ヴィ Private and controlled ownership sharing
US7490072B1 (en) 2005-02-16 2009-02-10 Novell, Inc. Providing access controls
US7818350B2 (en) 2005-02-28 2010-10-19 Yahoo! Inc. System and method for creating a collaborative playlist
EP1866821A4 (en) * 2005-04-08 2011-03-09 Korea Electronics Telecomm Domain management method and domain context of users and devices based domain system
US8352935B2 (en) 2005-05-19 2013-01-08 Novell, Inc. System for creating a customized software distribution based on user requirements
US8074214B2 (en) 2005-05-19 2011-12-06 Oracle International Corporation System for creating a customized software installation on demand
US20060291700A1 (en) * 2005-06-08 2006-12-28 Ogram Mark E Internet signature verification system
US8646102B2 (en) * 2005-09-16 2014-02-04 Oracle America, Inc. Method and apparatus for issuing rights in a digital rights management system
US7844820B2 (en) * 2005-10-10 2010-11-30 Yahoo! Inc. Set of metadata for association with a composite media item and tool for creating such set of metadata
FR2892222A1 (en) * 2005-10-17 2007-04-20 Thomson Licensing Sa METHOD FOR ETCHING, PROVIDING AND SECURE DISTRIBUTION OF DIGITAL DATA, ACCESS DEVICE AND RECORDER.
US20070204078A1 (en) * 2006-02-09 2007-08-30 Intertrust Technologies Corporation Digital rights management engine systems and methods
KR100791291B1 (en) 2006-02-10 2008-01-04 삼성전자주식회사 Method and apparatus using DRM contents with roaming in device
KR100703805B1 (en) * 2006-02-15 2007-04-09 삼성전자주식회사 Method and apparatus using drm contents with roaming in device of external domain
KR100708203B1 (en) * 2006-02-24 2007-04-16 삼성전자주식회사 Method for granting control device and device for using thereof
US8676973B2 (en) * 2006-03-07 2014-03-18 Novell Intellectual Property Holdings, Inc. Light-weight multi-user browser
KR101346734B1 (en) * 2006-05-12 2014-01-03 삼성전자주식회사 Multi certificate revocation list support method and apparatus for digital rights management
US7730480B2 (en) * 2006-08-22 2010-06-01 Novell, Inc. System and method for creating a pattern installation by cloning software installed another computer
US20090249079A1 (en) * 2006-09-20 2009-10-01 Fujitsu Limited Information processing apparatus and start-up method
US8601467B2 (en) 2006-10-03 2013-12-03 Salesforce.Com, Inc. Methods and systems for upgrading and installing application packages to an application platform
US9230068B2 (en) 2006-10-03 2016-01-05 Salesforce.Com, Inc. Method and system for managing license objects to applications in an application platform
US8601555B2 (en) * 2006-12-04 2013-12-03 Samsung Electronics Co., Ltd. System and method of providing domain management for content protection and security
US8621093B2 (en) * 2007-05-21 2013-12-31 Google Inc. Non-blocking of head end initiated revocation and delivery of entitlements non-addressable digital media network
US8544066B2 (en) * 2007-12-27 2013-09-24 Nec Corporation Access right management system, access right management method, and access right management program
US20090199279A1 (en) * 2008-01-31 2009-08-06 Microsoft Corporation Method for content license migration without content or license reacquisition
US8104091B2 (en) * 2008-03-07 2012-01-24 Samsung Electronics Co., Ltd. System and method for wireless communication network having proximity control based on authorization token
US20090307759A1 (en) * 2008-06-06 2009-12-10 Microsoft Corporation Temporary Domain Membership for Content Sharing
US10382438B2 (en) 2010-05-27 2019-08-13 Nokia Technologies Oy Method and apparatus for expanded content tag sharing
EP2591592A1 (en) * 2010-07-06 2013-05-15 General instrument Corporation Method and apparatus for cross drm domain registration
WO2012105599A1 (en) * 2011-02-03 2012-08-09 日本電気株式会社 Content access management system, server, method, and program
US9509704B2 (en) * 2011-08-02 2016-11-29 Oncircle, Inc. Rights-based system
KR20140017892A (en) * 2012-08-02 2014-02-12 삼성전자주식회사 Method of content transaction and apparatus for content transaction
US10133855B2 (en) 2013-10-08 2018-11-20 Comcast Cable Communications Management, Llc Systems and methods for entitlement management
WO2015069154A1 (en) 2013-11-06 2015-05-14 Telefonaktiebolaget L M Ericsson (Publ) Methods and user equipments for exchanging service capabilities
US11347890B2 (en) * 2017-03-24 2022-05-31 Open Text Sa Ulc Systems and methods for multi-region data center connectivity

Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO1998010381A1 (en) * 1996-09-04 1998-03-12 Intertrust Technologies Corp. Trusted infrastructure support systems, methods and techniques for secure electronic commerce, electronic transactions, commerce process control and automation, distributed computing, and rights management
WO2001013198A1 (en) * 1999-08-13 2001-02-22 Hewlett-Packard Company Enforcing restrictions on the use of stored data
WO2001018628A2 (en) * 1999-08-04 2001-03-15 Blue Spike, Inc. A secure personal content server
WO2001046786A1 (en) * 1999-12-20 2001-06-28 Liquid Audio, Inc. Adaptable security mechanism for preventing unauthorized access of digital data
WO2001076294A1 (en) * 2000-03-30 2001-10-11 Vattenfall Ab A method and a system for providing intelligent services
WO2002001330A2 (en) * 2000-06-27 2002-01-03 Microsoft Corporation Method and system for binding enhanced software features to a persona

Family Cites Families (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5204897A (en) * 1991-06-28 1993-04-20 Digital Equipment Corporation Management interface for license management system
US6135646A (en) * 1993-10-22 2000-10-24 Corporation For National Research Initiatives System for uniquely and persistently identifying, managing, and tracking digital objects
US5463565A (en) * 1993-10-29 1995-10-31 Time Warner Entertainment Co., L.P. Data block format for software carrier and player therefor
JP3090021B2 (en) * 1996-02-14 2000-09-18 富士ゼロックス株式会社 Electronic document management device
US7073063B2 (en) * 1999-03-27 2006-07-04 Microsoft Corporation Binding a digital license to a portable device or the like in a digital rights management (DRM) system and checking out/checking in the digital license to/from the portable device or the like
US7020781B1 (en) * 2000-05-03 2006-03-28 Hewlett-Packard Development Company, L.P. Digital content distribution systems
US20020157002A1 (en) * 2001-04-18 2002-10-24 Messerges Thomas S. System and method for secure and convenient management of digital electronic content
US6895503B2 (en) * 2001-05-31 2005-05-17 Contentguard Holdings, Inc. Method and apparatus for hierarchical assignment of rights to documents and documents having such rights
US7366915B2 (en) * 2002-04-30 2008-04-29 Microsoft Corporation Digital license with referral information

Patent Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO1998010381A1 (en) * 1996-09-04 1998-03-12 Intertrust Technologies Corp. Trusted infrastructure support systems, methods and techniques for secure electronic commerce, electronic transactions, commerce process control and automation, distributed computing, and rights management
WO2001018628A2 (en) * 1999-08-04 2001-03-15 Blue Spike, Inc. A secure personal content server
WO2001013198A1 (en) * 1999-08-13 2001-02-22 Hewlett-Packard Company Enforcing restrictions on the use of stored data
WO2001046786A1 (en) * 1999-12-20 2001-06-28 Liquid Audio, Inc. Adaptable security mechanism for preventing unauthorized access of digital data
WO2001076294A1 (en) * 2000-03-30 2001-10-11 Vattenfall Ab A method and a system for providing intelligent services
WO2002001330A2 (en) * 2000-06-27 2002-01-03 Microsoft Corporation Method and system for binding enhanced software features to a persona

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
"Call for proposals for content protection & copy management technologies" DVB CPT, 5 July 2001 (2001-07-05), XP002230687 *

Cited By (74)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US10528704B2 (en) 2002-12-30 2020-01-07 Koninklijke Philips N.V. Divided rights in authorized domain
US9466054B1 (en) 2003-06-05 2016-10-11 Intertrust Technologies Corporation Interoperable systems and methods for peer-to-peer service orchestration
US9317843B2 (en) 2003-06-05 2016-04-19 Intertrust Technologies Corporation Interoperable systems and methods for peer-to-peer service orchestration
US9235833B2 (en) 2003-06-05 2016-01-12 Intertrust Technologies Corporation Interoperable systems and methods for peer-to-peer service orchestration
US9235834B2 (en) 2003-06-05 2016-01-12 Intertrust Technologies Corporation Interoperable systems and methods for peer-to-peer service orchestration
AU2010212301B2 (en) * 2003-06-05 2012-03-15 Intertrust Technologies Corporation Digital Rights Management Engine Systems and Methods
US8234387B2 (en) 2003-06-05 2012-07-31 Intertrust Technologies Corp. Interoperable systems and methods for peer-to-peer service orchestration
US9009308B2 (en) 2003-07-24 2015-04-14 Koninklijke Philips N.V. Hybrid device and person based authorized domain architecture
US10038686B2 (en) 2003-07-24 2018-07-31 Koninklijke Philips N.V. Hybrid device and person based authorization domain architecture
US8863239B2 (en) 2004-03-26 2014-10-14 Adrea, LLC Method of and system for generating an authorized domain
US9071595B2 (en) * 2004-05-03 2015-06-30 Thomson Licensing Certificate validity checking
US20070186111A1 (en) * 2004-05-03 2007-08-09 Alain Durand Certificate validity checking
US8239962B2 (en) 2004-05-17 2012-08-07 Koninlijke Philips Electronics N.V. Processing rights in DRM systems
EP2933746A1 (en) 2004-05-17 2015-10-21 Koninklijke Philips N.V. Processing rights in drm systems
US8392333B2 (en) 2004-07-19 2013-03-05 Sony Deutschland Gmbh Method for providing protected audio/video content
JP2008507220A (en) * 2004-07-19 2008-03-06 ソニー ドイチュラント ゲゼルシャフト ミット ベシュレンクテル ハフツング Audio / video content protection method
US8095468B2 (en) 2004-07-19 2012-01-10 Sony Deutschland Gmbh Method for providing protected audio/video content
US8365299B2 (en) 2004-07-27 2013-01-29 Sony Corporation Information processing device and method, recording medium, and program
EP1783654A1 (en) * 2004-07-27 2007-05-09 Sony Corporation Information processing device and method, recording medium, and program
US8752195B2 (en) 2004-07-27 2014-06-10 Sony Corporation Information processing apparatus and method, recording medium, and program
EP1783654A4 (en) * 2004-07-27 2010-08-25 Sony Corp Information processing device and method, recording medium, and program
GB2418271A (en) * 2004-09-15 2006-03-22 Vodafone Plc Digital rights management in a domain
JP4927748B2 (en) * 2004-11-01 2012-05-09 コーニンクレッカ フィリップス エレクトロニクス エヌ ヴィ Improved access to your domain
US8561210B2 (en) 2004-11-01 2013-10-15 Koninklijke Philips N.V. Access to domain
JP2008518349A (en) * 2004-11-01 2008-05-29 コーニンクレッカ フィリップス エレクトロニクス エヌ ヴィ Improved access to your domain
WO2006070330A1 (en) * 2004-12-28 2006-07-06 Koninklijke Philips Electronics N.V. Method and apparatus for digital content management
WO2006075260A1 (en) * 2005-01-11 2006-07-20 Koninklijke Philips Electronics N.V. A method and apparatus for authorized domain management
US9356938B2 (en) 2005-02-04 2016-05-31 Koninklijke Philips N.V. Method, device, system, token creating authorized domains
JP2012198912A (en) * 2005-02-04 2012-10-18 Koninkl Philips Electronics Nv Method, device, system, and token for creating authorized domains
CN101116080B (en) * 2005-02-04 2017-07-28 皇家飞利浦电子股份有限公司 The method of establishment Authorized Domain, equipment, system, token
JP2008529184A (en) * 2005-02-04 2008-07-31 コーニンクレッカ フィリップス エレクトロニクス エヌ ヴィ Method, apparatus, system and token for creating an authorization domain
WO2006082549A3 (en) * 2005-02-04 2006-11-02 Koninkl Philips Electronics Nv Method, device, system, token creating authorized domains
CN101116080A (en) * 2005-02-04 2008-01-30 皇家飞利浦电子股份有限公司 Method, device, system, token creating authorized domains
JP2015164039A (en) * 2005-02-04 2015-09-10 コーニンクレッカ フィリップス エヌ ヴェ Method, device, system, and token for creating authorized domains
JP2006260471A (en) * 2005-03-18 2006-09-28 Sony Corp Package media providing system and its method as well as package media production device
US8752190B2 (en) 2005-05-19 2014-06-10 Adrea Llc Authorized domain policy method
JP2009503673A (en) * 2005-07-25 2009-01-29 コーニンクレッカ フィリップス エレクトロニクス エヌ ヴィ How to control access to content
US8881304B2 (en) * 2005-07-25 2014-11-04 Koninklijke Philips N.V. Method of controlled access to content
WO2007036831A2 (en) * 2005-09-30 2007-04-05 Koninklijke Philips Electronics N.V. Improved drm system
WO2007036831A3 (en) * 2005-09-30 2007-11-01 Koninkl Philips Electronics Nv Improved drm system
US8595853B2 (en) 2005-09-30 2013-11-26 Koninklijke Philips N.V. DRM system
US9460271B2 (en) 2005-09-30 2016-10-04 Koninklijke Philips N.V. DRM system
US8776259B2 (en) 2005-09-30 2014-07-08 Koninklike Philips N.V. DRM system
EA012918B1 (en) * 2005-10-18 2010-02-26 Интертраст Текнолоджиз Корпорейшн Digital rights management engine systems and methods
WO2007047846A3 (en) * 2005-10-18 2007-10-18 Intertrust Tech Corp Methods for digital rights management
US9626667B2 (en) 2005-10-18 2017-04-18 Intertrust Technologies Corporation Digital rights management engine systems and methods
US8776216B2 (en) 2005-10-18 2014-07-08 Intertrust Technologies Corporation Digital rights management engine systems and methods
US8688583B2 (en) 2005-10-18 2014-04-01 Intertrust Technologies Corporation Digital rights management engine systems and methods
WO2007047846A2 (en) 2005-10-18 2007-04-26 Intertrust Technologies Corporation Methods for digital rights management
AU2006304655B2 (en) * 2005-10-18 2012-08-16 Intertrust Technologies Corporation Methods for digital rights management
WO2007061453A3 (en) * 2005-11-17 2007-08-23 Sony Ericsson Mobile Comm Ab Digital rights management based on device proximity
WO2007061453A2 (en) * 2005-11-17 2007-05-31 Sony Ericsson Mobile Communications Ab Digital rights management based on device proximity
EP2390816A1 (en) * 2005-11-17 2011-11-30 Sony Ericsson Mobile Communications AB Digital rights management based on device proximity
US8687801B2 (en) 2006-01-03 2014-04-01 Samsung Electronics Co., Ltd. Method and apparatus for acquiring domain information and domain-related data
US8813191B2 (en) 2006-02-15 2014-08-19 Thomson Licensing Method and apparatus for controlling the number of devices installed in an authorized domain
US8761398B2 (en) 2006-05-02 2014-06-24 Koninkljijke Philips N.V. Access to authorized domains
JP2010506325A (en) * 2006-10-12 2010-02-25 コーニンクレッカ フィリップス エレクトロニクス エヌ ヴィ Authorization area specific to the license
WO2008090402A1 (en) * 2007-01-25 2008-07-31 Psitek (Proprietary) Limited A system and method of transferring digital rights to a media player in a drm environment
US8863306B2 (en) 2007-07-05 2014-10-14 Fraunhofer-Gesellschaft Zur Foerderung Der Angewandten Forschung E.V. Device and method for digital rights management
RU2476928C2 (en) * 2007-07-05 2013-02-27 Фраунхофер-Гезелльшафт цур Фёрдерунг дер ангевандтен Method and apparatus for digital rights management
WO2009003708A1 (en) * 2007-07-05 2009-01-08 Fraunhofer-Gesellschaft zur Förderung der angewandten Forschung e.V. Device and method for digital rights management
KR101124866B1 (en) * 2007-07-05 2012-03-27 프라운호퍼-게젤샤프트 추르 푀르데룽 데어 안제반텐 포르슝 에 파우 Device and method for digital rights management
US8793808B2 (en) 2007-07-23 2014-07-29 Intertrust Technologies Corporation Dynamic media zones systems and methods
US9426133B2 (en) 2007-07-23 2016-08-23 Intertrust Technologies Corporation Tethered device systems and methods
US8850195B2 (en) 2007-07-23 2014-09-30 Intertrust Technologies Corporation Tethered device systems and methods
WO2009014733A1 (en) * 2007-07-23 2009-01-29 Intertrust Technologies Corporation Dynamic media zones systems and methods
WO2009014734A3 (en) * 2007-07-23 2009-04-30 Intertrust Tech Corp Tethered device systems and methods
WO2009014734A2 (en) * 2007-07-23 2009-01-29 Intertrust Technologies Corporation Tethered device systems and methods
US10078873B2 (en) 2007-07-23 2018-09-18 Intertrust Technologies Corporation Tethered device systems and methods
US9589110B2 (en) 2011-04-11 2017-03-07 Intertrust Technologies Corporation Information security systems and methods
US10009384B2 (en) 2011-04-11 2018-06-26 Intertrust Technologies Corporation Information security systems and methods
FR3029666A1 (en) * 2014-12-04 2016-06-10 Orange METHOD FOR MANAGING THE RIGHT OF ACCESS TO DIGITAL CONTENT
WO2016087750A1 (en) * 2014-12-04 2016-06-09 Orange Method of managing the right of access to a digital content
US11234032B2 (en) 2014-12-04 2022-01-25 Orange Method of managing the right of access to a digital content

Also Published As

Publication number Publication date
EP1556748A2 (en) 2005-07-27
KR20050074494A (en) 2005-07-18
RU2005115475A (en) 2005-11-10
CN1708740A (en) 2005-12-14
BR0315550A (en) 2005-08-23
US20060021065A1 (en) 2006-01-26
AU2003267764A1 (en) 2004-05-13
JP2006504176A (en) 2006-02-02
CN100403209C (en) 2008-07-16
WO2004038568A3 (en) 2004-07-29
RU2352985C2 (en) 2009-04-20

Similar Documents

Publication Publication Date Title
US20060021065A1 (en) Method and device for authorizing content operations
JP5065911B2 (en) Private and controlled ownership sharing
US6950941B1 (en) Copy protection system for portable storage media
JP5200204B2 (en) A federated digital rights management mechanism including a trusted system
JP5450392B2 (en) Binding content licenses to portable storage devices
US7296147B2 (en) Authentication system and key registration apparatus
EP1652025B1 (en) Hybrid device and person based authorized domain architecture
KR101315076B1 (en) Method for redistributing dram protected content
JP4168679B2 (en) Content usage management system, information processing apparatus or method for using or providing content, and computer program
JP2007528658A (en) Improved domain manager and domain device
KR20070009983A (en) Method of authorizing access to content
JP2005108182A (en) Method of creating domain based on public key cryptography
WO2007086015A2 (en) Secure transfer of content ownership
JP2007124717A (en) System for preventing illegal copying of digital content
JPWO2009044508A1 (en) Copyright protection system, playback device, and playback method
JP2004312717A (en) Data protection management apparatus and data protection management method
KR20000072848A (en) System for protecting copy of digital contents
JP2008529339A (en) Method for preventing unauthorized distribution of content in a DRM system for commercial or personal content
JP2008529340A (en) Registration stage
Sun et al. A Trust Distributed DRM System Using Smart Cards
JP2006014239A (en) Content distribution system, content distribution server, user terminal, content distribution method and content distribution program
JP2005277951A (en) System and method for authentication

Legal Events

Date Code Title Description
AK Designated states

Kind code of ref document: A2

Designated state(s): AE AG AL AM AT AU AZ BA BB BG BR BY BZ CA CH CN CO CR CU CZ DE DK DM DZ EC EE EG ES FI GB GD GE GH GM HR HU ID IL IN IS JP KE KG KP KR KZ LC LK LR LS LT LU LV MA MD MG MK MN MW MX MZ NI NO NZ OM PG PH PL PT RO RU SC SD SE SG SK SL SY TJ TM TN TR TT TZ UA UG US UZ VC VN YU ZA ZM ZW

AL Designated countries for regional patents

Kind code of ref document: A2

Designated state(s): GH GM KE LS MW MZ SD SL SZ TZ UG ZM ZW AM AZ BY KG KZ MD RU TJ TM AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HU IE IT LU MC NL PT RO SE SI SK TR BF BJ CF CG CI CM GA GN GQ GW ML MR NE SN TD TG

121 Ep: the epo has been informed by wipo that ep was designated in this application
WWE Wipo information: entry into national phase

Ref document number: 2003748459

Country of ref document: EP

ENP Entry into the national phase

Ref document number: 2006021065

Country of ref document: US

Kind code of ref document: A1

WWE Wipo information: entry into national phase

Ref document number: 10531939

Country of ref document: US

Ref document number: 659/CHENP/2005

Country of ref document: IN

WWE Wipo information: entry into national phase

Ref document number: 20038A19429

Country of ref document: CN

Ref document number: 2004546260

Country of ref document: JP

Ref document number: 1020057006953

Country of ref document: KR

ENP Entry into the national phase

Ref document number: 2005115475

Country of ref document: RU

Kind code of ref document: A

WWP Wipo information: published in national office

Ref document number: 1020057006953

Country of ref document: KR

WWP Wipo information: published in national office

Ref document number: 2003748459

Country of ref document: EP

WWP Wipo information: published in national office

Ref document number: 10531939

Country of ref document: US