WO2006051494A1 - Amelioration de revocation dans domaine autorise - Google Patents

Amelioration de revocation dans domaine autorise Download PDF

Info

Publication number
WO2006051494A1
WO2006051494A1 PCT/IB2005/053687 IB2005053687W WO2006051494A1 WO 2006051494 A1 WO2006051494 A1 WO 2006051494A1 IB 2005053687 W IB2005053687 W IB 2005053687W WO 2006051494 A1 WO2006051494 A1 WO 2006051494A1
Authority
WO
WIPO (PCT)
Prior art keywords
devices
domain
status information
content
revocation status
Prior art date
Application number
PCT/IB2005/053687
Other languages
English (en)
Inventor
Robert P. Koster
Franciscus L. A. J. Kamperman
Peter Lenoir
Koen H. J. Vrielink
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.
Publication of WO2006051494A1 publication Critical patent/WO2006051494A1/fr

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/10—Network architectures or network communication protocols for network security for controlling access to devices or network resources
    • H04L63/101—Access control lists [ACL]
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/10—Protecting distributed programs or content, e.g. vending or licensing of copyrighted material ; Digital rights management [DRM]
    • G06F21/101—Protecting distributed programs or content, e.g. vending or licensing of copyrighted material ; Digital rights management [DRM] by binding digital rights to specific entities
    • G06F21/1012—Protecting 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
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L2463/00—Additional details relating to network architectures or network communication protocols for network security covered by H04L63/00
    • H04L2463/101—Additional details relating to network architectures or network communication protocols for network security covered by H04L63/00 applying security measures for digital rights management

Definitions

  • PC personal computer
  • CE personal computer
  • mobile contains some form of digital interconnectivity technology.
  • digital interconnectivity technology will get more and more a ubiquitous character.
  • P2P peer-to-peer
  • Digital interconnectivity and storage technologies enable the transfer and copying of data.
  • commercial content typically comprises things like music, songs, movies, TV programs, pictures, games, books and the likes, but which also may include data related to interactive services
  • Digital Rights Management (DRM) systems are being increasingly employed to protect and enforce the rights of content owners.
  • FIG. 1 An illustrative embodiment of a DRM system is illustrated in Fig. 1.
  • the content is encrypted and embedded in a so-called Content Container for which many standards exist, e.g. ISMACrypt or MPEG-2 Transport Stream as defined by DVB for conditional access. See
  • CA digital broadcast systems
  • MPEG Information Technology - Generic coding of moving pictures and associated audio information: Systems, ISO/IEC 13919-1: 1996(E), MPEG, 15-4-1996.
  • a device To decrypt the content a device will require the Content Key. Additionally there is Rights Expression, which specifies which identity may use the content and also how the content may be used.
  • the identity specified in the Content Item could cither represent a device, a person or a group of devices and/or persons. Devices should comply with certain (security and other) requirements before they are entitled to access protected content. Such devices are commonly referred to as "compliant devices”.
  • the combination of the Content Container, the Content Key and the Rights Expression is in this document referred to as the Content Item (denoted 'C in subsequent figures).
  • Authorized Domains tries to find a solution to both serve the interests of the content owners (that want protection of their intellectual property) 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.
  • a user could for example take a portable device for audio and/or video with a limited amount of content with him on a trip, and use it in his hotel room to access or download additional content stored on his personal audio and/or video system at home. Even though the portable device is outside the home network, it is a part of the user's authorized domain.
  • an Authorized Domain is a system that allows access to content by devices in the domain, but not by any others.
  • AD One type of AD, sometimes referred to as a device based AD is illustrated in Fig. 2. It allows a set of devices bound to a domain to access content bound to that domain. This double binding assures that all the devices in the AD can access the content. This structure is often established by implementing the bindings through a shared secret key. This key is chosen by a domain manager and distributed to all the devices in the domain. When content is bound to the domain, the license is cryptographically linked to the domain by means of encryption with the shared key.
  • the content may be directly bound to one device, as illustrated in Fig. 3. As can be seen the devices remain bound to the AD.
  • AD is the so-called person based Authorized Domains, where the domain is based on persons instead of devices.
  • An example of such a system is described in international patent application WO 04/038568 (attorney docket PHNL021063) by the same applicant, in which content is coupled to persons, which then are grouped into a domain.
  • Fig. 4 is shown a configuration with the content bound to a person and a number of persons, e.g. all the members of one family, grouped into an authorized domain.
  • the content will be accessible on every suitable compliant device and therefore they are missing in the figure because for the purpose of this model all compliant devices are equal.
  • devices are still required to process (e.g. render) and store content and licenses, they need to be compliant to guarantee that the content cannot be illegally exported from this DRM system.
  • a so-called Hybrid Authorized Domain-based DRM system ties content to a group that may contain devices and persons. This group is typically limited to a household, such that:
  • Content protection systems usually involve protected communication between devices 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 solutions for these protocols are those that 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, which is digitally signed by a Certification Authority (CA), the organization that manages the distribution of public/private key-pairs for all devices.
  • CA Certification Authority
  • Everybody knows the CA's public key and can use it to verify the CA's signature on the certificate.
  • the public key of the CA is hard-coded into the implementation of the device.
  • each hardware device or software application (referred to collectively as devices hereafter) holds a number of secret keys, sometimes also known as private keys.
  • These keys and the control flow using these keys should be well protected, for knowledge of these keys or manipulation of the control flow would allow hackers to circumvent the content protection systems.
  • there are several different devices involved which might not all be implemented with equal levels of tamper proofing. Such a system should therefore be resistant to the hacking of individual devices, which might enable illegal storing, copying and/or redistribution of digital content.
  • Certificate Revocation List a list allowing identification of revoked devices.
  • Compliant devices are forced in some manner to possess an up-to-date CRL, and they should never pass content to devices that are listed as revoked in the CRL.
  • the CA generates and distributes new CRLs whenever necessary.
  • Revocation can be indicated in several different manners. Two different techniques are so-called black lists (a list of revoked devices) and white lists (a list of un- revoked devices). Devices are identified on the blacklist or the white list by a unique identifier, such as a serial number. A device may have a unique identifier installed in the factory. This globally unique identifier can then be listed in the CRL. Alternatively an authorized domain manager device may assign unique identifiers to devices as they join the authorized domain. These identifiers can be used in a CRL to be used in the authorized domain (sometimes called a "local CRL") instead of globally unique identifiers.
  • a typical problem with blacklist-based approaches is that each device has to store the blacklist or has to have communication means to check or retrieve the blacklist. In CE devices this is often not a viable solution and therefore the whitelist approach is preferred. Now each device gets an authorization certificate in which is declared that the device is still compliant. The latter is small enough such that a device can store it. However, a device now has to renew its authorization certificate every now and then from the authority that issues those. The latter is difficult for devices that do not directly contact such authorities, for example because they have limited connectivity or because they operate most of the time without a connection to an authority.
  • the invention provides an authorized domain system comprising a plurality of devices including at least one retrieval device, in which the retrieval device is configured to retrieve revocation status information for two or more devices comprised in the domain and to distribute the retrieved revocation status information to one or more devices with which the retrieval device is in contact.
  • Such status information may be provided using the blacklist or whitelist approach discussed above.
  • Preferably it comprises a range of non-revoked devices.
  • the retrieval device may retrieve revocation status information for some or all of the devices comprised in the domain.
  • the retrieval device is configured to retrieve revocation status information for one or more devices in the domain that it has learned are a member of the domain. For instance, these one or more devices may have previously requested the retrieval device to retrieve content, or the retrieval device has recently communicated with these one or more devices.
  • the domain may comprise devices that expect different types of revocation status information, for example because they are configured to use different content protection mechanisms. It is likely that a device that requests content from the retrieval device (which is in a particular format) is also able to handle revocation status information provided by this same retrieval device.
  • a first device comprised in the domain that has received the retrieved revocation status information is configured to distribute the retrieved revocation status information to a second device comprised in the domain, for example as part of setting up a secure authenticated channel with said one or more devices.
  • This provides a mechanism for distributing the revocation status information amongst the devices in the domain. It is now not necessary for the retrieval device (or another central device or management device) to distribute the status information directly to that second device.
  • the revocation status information may be bundled with an updated version of a list of device identifiers that is to be distributed to the devices in the domain.
  • bundling can be effected in many ways e.g. by including the revocation status information in a data structure containing this updated version of the list, or by transmitting it in the same session as the one used to transmit this updated version of the list.
  • the revocation status information may comprise a plurality of certificates, each identifying one or more devices that have not been revoked.
  • a device then normally sends, as part of the authentication procedure, only the certificate that identifies this device itself.
  • the device receiving this certificate may compare a version number associated with this certificate against a version number of a certificate it received and stored earlier. If this certificate is newer than the stored certificate, the receiving device may request the sending device to send some or all of the certificates in possession of the sending device.
  • a receiving device may request to send all certificates that are newer than the stored certificate.
  • a receiving device may also request only that certificate which is newer than the stored certificate and which identifies the receiving device.
  • a creation date can be used.
  • the retrieval device is configured to retrieve the revocation status information in conjunction with a purchase transaction.
  • the revocation status information can be retrieved from a server facilitating the purchase transaction, or from a different server of course.
  • Fig. 2 schematically shows an authorized domain structure with devices bound to a domain and content bound to that domain
  • Fig. 3 schematically shows an authorized domain structure with content bound to devices and devices bound to that domain
  • Fig. 4 schematically shows an authorized domain structure with content bound to a person and persons bound to a domain
  • Fig. 5 schematically shows a system comprising devices interconnected via a network
  • Fig. 6 schematically shows an embodiment of an AD system
  • Fig. 7 schematically shows this embodiment in more detail
  • Fig. 8 schematically shows major building blocks for this embodiment.
  • 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. 5 schematically shows a system 100 comprising devices 101-105 interconnected via a network 110.
  • a typical digital home network includes a number of devices, e.g. a radio receiver, a tuner/decoder, a CD player, a pair of speakers, a television, a VCR, a digital recorder, a mobile phone, a tape deck, a personal computer, a personal digital assistant, a portable display unit, and so on. These devices are usually interconnected to allow one device, e.g. the television, to control another, e.g. the VCR.
  • One device such as e.g. the tuner/decoder or a set top box (STB), is usually the central device, providing central control over the others.
  • STB set top box
  • the system 100 may be an in-home network that operates as an Authorized Domain.
  • content protection systems like SmartRight from Thomson, or DTCP from DTLA
  • DTCP DTCP from DTLA
  • 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.
  • Content which typically comprises things like music, songs, movies, TV programs, pictures, games, books and the likes, but which also may include interactive services, is received through a residential gateway or set top box 101.
  • Content could also enter the home via other sources, such as storage media like discs or using portable devices.
  • the source could be a connection to a broadband cable network, an Internet connection, a satellite downlink and so on.
  • the content can then be transferred over the network 110 to a sink for rendering.
  • a sink can be, for instance, the television display 102, the portable display device 103, the mobile phone 104 and/or the audio playback device 105.
  • rendering comprises generating audio signals and feeding them to loudspeakers.
  • rendering generally comprises generating audio and video signals and feeding those to a display screen and loudspeakers.
  • Rendering may also include operations such as decrypting or descrambling a received signal, synchronizing audio and video signals and so on.
  • the set top box 101 may comprise a storage medium Sl such as a suitably large hard disk, allowing the recording and later playback of received content.
  • the storage medium Sl could be a Personal Digital Recorder (PDR) of some kind, for example a DVD+RW recorder, to which the set top box 101 is connected.
  • Content can also enter the system 100 stored on a carrier 120 such as a Compact Disc (CD) or Digital Versatile Disc (DVD).
  • the portable display device 103 and the mobile phone 104 are connected wirelessly to the network 110 using a base station 111, for example using Bluetooth or IEEE 802.1 Ib.
  • the other devices are connected using a conventional wired connection.
  • HAVi Home Audio/Video Interoperability
  • D2B domestic digital bus
  • DRM Digital Rights Management
  • SAC secure authenticated channel
  • AKA Authentication and Key Agreement
  • Standards such as International Standard ISO/IEC 11770-3 and ISO/IEC 9796- 2, and public key algorithms such as RSA and hash algorithms like SHA-I are often used.
  • compliant devices receive an identity certificate that is used in the AKA to exchange the public keys of the devices.
  • the compliant devices receive a second certificate called AuthorizationCertificate (AC), which declares that that device still belongs to the compliant set of devices.
  • AC AuthorizationCertificate
  • the contents of the AC preferably consists of intervals of (still compliant) device identities and the total authorization list consists of one or more of such ACs.
  • a device only needs to store and exchange that AC, which contains the interval in which its device identity falls. This is well suited for embedded CE devices, as these devices have often strict and fixed storage requirements. See international patent application WO 03/107588 (attorney docket PHNL020543).
  • European patent application serial number 04101104.0 (attorney docket PHNL040332) provides an improvement comprising generating a run-length encoded representation of an authorization status of a number of devices and storing the representation in the GC.
  • the authorization certificates are updated on a regular basis and new certificates are identified by means of a serial number, creation date or similar mechanism.
  • This mechanism has as a drawback the chance that devices can be locked out of compliant communications, while in fact they are still compliant devices but with outdated authorization information. This drawback can be largely mitigated by employing efficient distribution strategies for the authorization lists.
  • PED Personal Entertainment Domain
  • Fig. 6 One single person is member/owner of the domain. This embodiment is illustrated in Fig. 6.
  • the content is bound to that person and a number of devices are bound to his domain.
  • the content can be accessed on devices that belong to the PED. However, to facilitate location independence, content can still be accessed on all other compliant devices if a suitable user authentication has taken place.
  • An improvement is to allow devices to be part of multiple PEDs. As the number of devices in a PED is limited and content is kept bound to the person in the domain, we can still make sure that persons, who make use of the same devices, can share content
  • Fig. 7 shows how the domain/grouping functionality of PED AD-DRM can be organized.
  • PED AD-DRM content is bound to users by binding the license to a particular user, normally the one that buys rights to the content.
  • the main aspect of user management in PED AD-DRM is that a user gets a UserID certificate and corresponding public/private key pair. The user does not get personal access to the corresponding private key. This prevents that a user can give away his private key and enable someone else to impersonate him. Therefore the user's private key must be securely stored on a tamper resistant UserID device, which also serves as a token proving the user's presence.
  • the UserID device must be easy to handle, robust, provide secure computing means and must be hard to clone. Examples of such devices are smart cards and mobile phones with a SIM. Devices in PED AD-DRM get a DevicelD certificate.
  • DD DomainDevices
  • Solutions without a DD certificate can be considered, e.g. each device "remembers" that it is associated with a particular user, or each device gets its own certificate instead of one DD that lists all members, or each device is simply given a domain key that grants access the content of the user.
  • the advantage of storing the DomainDevices information in a certificate is that it leaves a trace of who issued it, while both "remembering" and having access to a key do not leave a trail.
  • the advantage of putting all domain members in one certificate is that it allows for a simple (viral) signalling mechanism what devices are in the domain, which can be effectively used to inform deregistered devices and be used in the process of revocation information distribution.
  • DD certificate Another use of the DD certificate is that devices can use it to report domain information to the user, e.g. show the devices in his domain.
  • a disadvantage of using DD certificates is that they are generally bigger in size, but this size limitation is so marginal compared with the other information in this system (e.g. content) that it is considered to be of little importance.
  • AD-DRM functionality of an AD-DRM system as indicated above is distributed over a set of functional components that form the major building blocks for the AD-DRM system.
  • An embodiment is illustrated in Fig. 8.
  • the ADMCore, ADMTerminal, ADClient and UserID components together are responsible for the following AD and DRM functions of AD-DRM: domain management, content management, compliance management, rights management (license evaluation), user management (user authentication), device management and user interfacing.
  • components may be combined on a device. In other embodiments, different components may be used or their functionality can be distributed in another way over different components.
  • Fig. 8 also shows the interaction between the different components including the typical communication means between the components.
  • the communication means arc not exhaustive, but rather indicate some classes, such as: • being combined on the same device, e.g. local inter-process communication,
  • IP network e.g. an IP network
  • the third class is considered as a special category, because (secure) distance limited communication means can be used both for user convenience and for security.
  • the ADMCore component has the responsibility for domain management, e.g. registering and deregistering of devices to the domain. It controls the domain composition by acting according to the domain policy. ADMCore furthermore acts as a security module for domain secrets and controls distribution of those secrets, which means that domain secret are concentrated in ADMCore and that other components only get access to those credentials on a need to have basis. Preferably this also implies that ADMCore must operate in a secure and robust environment.
  • the ADMTerminal component provides the interface for the ADMCore to end-users, for example a user interface to perform domain management actions, and to the rest of the AD-DRM system components (arrows 1 and 2).
  • ADMTerminal may provide proxy functions to ADMCore that enable remote components to communicate with ADMCore.
  • ADMTerminal does not need a robust implementation and does not need to be located on a compliant device, because ADMTerminal does not perform any security sensitive AD-DRM operations itself, but only interfaces with the components.
  • the ADClient component is responsible for both AD and DRM functions, such as rights management (e.g. verifying that rights can be accessed by the right components, rights evaluation) and content management (processing content , e.g. decryption).
  • ADClient also realizes some of the user management, device management and domain management functions, but the main responsibility of those functions lies at other components and ADClient only acts as a client to such functions.
  • ADClient typically runs on devices that access the content, e.g. for rendering, and supports typical DRM functionality such as license exchange (arrow 3) and license evaluation and participates in typical AD functionality such as (de)registering to domains (arrow 2 and 4) .
  • ADClient requires a robust implementation, because it has access to secrets associated with content and domains.
  • the UserID component is important for the person-based access of content on compliant devices that do not belong to the PED. Therefore UserID manages some user credentials and uses those for authentication with ADClients (arrow 5). UserID ensures that the user credentials are protected and thereby UserID also requires a robust implementation.
  • the distribution of components over devices depends on the characteristics of the AD-DRM system and a lot on the expected user interaction. PED AD-DRM has some characteristics that make it efficient to combine certain components on the same device. One of these choices would be to combine the UserID and ADMCore components on a smart card, because each user has exactly one domain. This smart card is then the physical representation for both the user and the domain, which makes it conceptually quite straightforward for the end-user. Implementing both on a smart card furthermore has the advantage that it provides a natural environment for secure and robust implementations, which is what both UserID and ADMCore require.
  • ADClient resides on a device together with ADMTerminal, which makes it straightforward to perform AD management operation since the ADMCore smartcard can be held at the device after which ADMTerminal uses the user interface of the device to facilitate (de)registration of the device in cooperation with ADClient.
  • Alternatives are also possible, e.g. advanced portable devices that combine the ADMCore and ADMTerminal components and possibly even UserID.
  • the ADMCore component needs authorization information for some of its • operations. However, it may have no direct contact with the services that provide the authorization information. The same roughly applies to some devices running ADClients, e.g. typical consumption-only portable devices, that normally only contact another ADClient to obtain their content. Fortunately also devices exist with ADClients that regularly communicate with services in the network, e.g. to buy new content and receive new licenses, and these devices can obtain updated authorization information as part of that transaction.
  • a service provider can provide new authorization information for the device it is delivering to and we extend this mechanism by also obtaining authorization information for the identities of all other domain members listed in the DD certificate, preferably also for the identity of ADMCore and also for the uscr(s) of the domain. Due to the viral nature of the DD certificate distribution, we achieve that eventually deregistered and revoked devices cannot render any domain content anymore, with the exception when a deregistered device does not have any contact its former domain members anymore. In this case the isolated device can keep on rendering content based on the information it already possesses. In some embodiments of DRM systems, the DRM system does not explicitly provide a list of device identifiers of the devices in the system or domain.
  • the domain manager may supply the retrieval device with the necessary device identifiers.
  • the devices in question may supply a request for retrieval of relevant revocation status information to the retrieval device, or to the domain manager.
  • the domain manager then informs the retrieval device that revocation status information should be retrieved for these devices.
  • This can be done in many ways. For example the domain manager may send a message or request to the retrieval device. This can be done periodically or whenever a predetermined number of requests have been received or according to another criterion.
  • the retrieval device may contact the domain manager to find out if other devices have made any requests for revocation status information. This can be done periodically or whenever the retrieval device is about to engage in a purchase or download transaction or according to another criterion.
  • the devices may also send such a request for revocation status information to other devices in the system, which then pass the request on to yet other devices.
  • a "viral" distribution of requests ensures that the requests will eventually reach the retrieval device.
  • Such an embodiment is advantageous e.g. when there is no domain manager, or when the domain manager is not available to the other devices at all times.
  • the above mechanisms for making requests and supplying these requests to the retrieval device can also be used to supply responses, i.e. revocation status information, from the retrieval device back to devices in the system.
  • the retrieval device may supply the retrieved revocation status information to the domain manager, or signal the domain manager that it has retrieved this information. It may also signal this to other devices, for example by using a designated bit in another message to "flag" that updated revocation status information is available. The other devices can then retrieve the revocation status information when needed.
  • a device may "subscribe" to revocation status information, i.e. indicate to the retrieval device or domain manager that updated revocation status information should be retrieved and transmitted to this device on a regular basis.
  • the retrieval device should be prepared to handle this. If the retrieval device can only handle one particular type of revocation status information, it should reject or ignore any requests for revocation status information of a different type. If multiple types or formats of revocation status information are retrieved, they may need to be distributed among the devices in the domain separately, or at least labeled as being of different type. This depends on the AD system in question.
  • Another embodiment is an extension to the system described in European patent application serial number 04100997.8 (attorney docket PHNL040288).
  • This system revocation is done in a two-step approach.
  • First global revocation information is retrieved by a content management device. This is forwarded to the AD manager device which creates local revocation information from it.
  • the system does not specify the exact format of the revocation information.
  • a blacklist approach is possible, but this may be inefficient since these can be large and processing on AD manager can be hard because it may have limited storage and processing capabilities.
  • each content management device could obtain a much smaller set of revocation information based on the domain members.
  • whitelist approach is now preferred. New authorization information can be sent to the AD manager that turns it into local revocation information, which it can do much simpler now because less storage and processing is required.
  • the revocation status information for example may also apply to (certificates or tokens for) persons or other entities in the system, not just to devices. It may also apply to a certain function in the system, i.e. the ability to write content to storage media can be revoked. It may also apply to an entity outside the system whose revocation status needs to be known to the entities in the system.
  • International patent application WO 01/42886 discloses an efficient way of combining a contact list and a revocation list. Contact lists can be combined with the revocation or authentication lists as discussed above.
  • European patent application serial number 04100215.5 (attorney docket PHNL040086) describes a method of and source device for authorizing access to content by a sink device in accordance with usage rights, the content being stored on a storage medium controlled by the source device.
  • the revocation or authorization status of the sink device is verified using the most recently issued revocation or authorization information that is available if the usage rights need to be modified as part of the authorization of access to the content, and using revocation or authorization information associated with the content stored on the storage medium, preferably the information stored on the storage medium, otherwise.
  • the latest version of the revocation or authorization information as used in that patent ' application can be obtained in accordance with the present invention.
  • 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.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Hardware Design (AREA)
  • Computer Security & Cryptography (AREA)
  • Theoretical Computer Science (AREA)
  • General Engineering & Computer Science (AREA)
  • Software Systems (AREA)
  • Signal Processing (AREA)
  • Multimedia (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Technology Law (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Computing Systems (AREA)
  • Storage Device Security (AREA)

Abstract

L'invention concerne un système de domaine autorisé comprenant une pluralité de dispositifs, y compris au moins un dispositif d'extraction, qui est conçu pour extraire une information de statut de révocation pour deux dispositifs ou plus compris dans le domaine et pour diffuser l'information d'état de révocation ainsi extraite à un ou plusieurs dispositifs en contact avec le dispositif d'extraction.
PCT/IB2005/053687 2004-11-15 2005-11-09 Amelioration de revocation dans domaine autorise WO2006051494A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
EP04105769.6 2004-11-15
EP04105769 2004-11-15

Publications (1)

Publication Number Publication Date
WO2006051494A1 true WO2006051494A1 (fr) 2006-05-18

Family

ID=35840445

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/IB2005/053687 WO2006051494A1 (fr) 2004-11-15 2005-11-09 Amelioration de revocation dans domaine autorise

Country Status (1)

Country Link
WO (1) WO2006051494A1 (fr)

Cited By (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP1860586A1 (fr) * 2006-05-18 2007-11-28 Vodafone Holding GmbH Méthode et unité de gestion pour gérer l'utilisation de contenu numérique, dipositif de rendu correspondant
EP1881433A1 (fr) * 2006-07-17 2008-01-23 Research In Motion Limited Procédé et dispositif de gestion de plusieurs connections à un appareil d'accès par jeton de sécurité
DE102006044299A1 (de) * 2006-09-20 2008-04-10 Nokia Siemens Networks Gmbh & Co.Kg Vorrichtung und Verfahren zur gesicherten Verteilung von Inhalten in einem Telekommunikationsnetzwerk
WO2008090402A1 (fr) * 2007-01-25 2008-07-31 Psitek (Proprietary) Limited Système et procédé de transfert de droits numériques à un lecteur multimédia dans un environnement de gestion de droits numériques
US8079068B2 (en) 2006-07-17 2011-12-13 Research In Motion Limited Management of multiple connections to a security token access device
US8761398B2 (en) 2006-05-02 2014-06-24 Koninkljijke Philips N.V. Access to authorized domains
EP3101904A1 (fr) * 2015-06-05 2016-12-07 Sony Corporation Liste blanche distribuée pour renouvellement de sécurité

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2001098903A1 (fr) * 2000-06-16 2001-12-27 Entriq Limited BVI Abbot Building Procedes et systemes servant a distribuer un contenu par l'intermediaire d'un reseau mettant en application des agents d'acces conditionnel distribues et des agents securises pour effectuer la gestion de droits numeriques (drm)
EP1376307A2 (fr) * 2002-06-28 2004-01-02 Microsoft Corporation Modèle de confiance pour un système DRM

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2001098903A1 (fr) * 2000-06-16 2001-12-27 Entriq Limited BVI Abbot Building Procedes et systemes servant a distribuer un contenu par l'intermediaire d'un reseau mettant en application des agents d'acces conditionnel distribues et des agents securises pour effectuer la gestion de droits numeriques (drm)
EP1376307A2 (fr) * 2002-06-28 2004-01-02 Microsoft Corporation Modèle de confiance pour un système DRM

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
BOGDAN C. POPESCU , FRANK L.A.J. KAMPERMAN , BRUNO CRISPO , ANDREW S. TANENBAUM: ""A DRM Security Architecture for Home Networks", DRM'04, 25 October 2004 (2004-10-25), Washington, DC, USA, XP002369881 *

Cited By (10)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8761398B2 (en) 2006-05-02 2014-06-24 Koninkljijke Philips N.V. Access to authorized domains
EP1860586A1 (fr) * 2006-05-18 2007-11-28 Vodafone Holding GmbH Méthode et unité de gestion pour gérer l'utilisation de contenu numérique, dipositif de rendu correspondant
EP1881433A1 (fr) * 2006-07-17 2008-01-23 Research In Motion Limited Procédé et dispositif de gestion de plusieurs connections à un appareil d'accès par jeton de sécurité
US8079068B2 (en) 2006-07-17 2011-12-13 Research In Motion Limited Management of multiple connections to a security token access device
US8745717B2 (en) 2006-07-17 2014-06-03 Blackberry Limited Management of multiple connections to a security token access device
DE102006044299A1 (de) * 2006-09-20 2008-04-10 Nokia Siemens Networks Gmbh & Co.Kg Vorrichtung und Verfahren zur gesicherten Verteilung von Inhalten in einem Telekommunikationsnetzwerk
DE102006044299B4 (de) * 2006-09-20 2014-11-13 Nokia Solutions And Networks Gmbh & Co. Kg Vorrichtung und Verfahren zur gesicherten Verteilung von Inhalten in einem Telekommunikationsnetzwerk
WO2008090402A1 (fr) * 2007-01-25 2008-07-31 Psitek (Proprietary) Limited Système et procédé de transfert de droits numériques à un lecteur multimédia dans un environnement de gestion de droits numériques
EP3101904A1 (fr) * 2015-06-05 2016-12-07 Sony Corporation Liste blanche distribuée pour renouvellement de sécurité
US9807083B2 (en) 2015-06-05 2017-10-31 Sony Corporation Distributed white list for security renewability

Similar Documents

Publication Publication Date Title
US8983071B2 (en) Key management method using hierarchical node topology, and method of registering and deregistering user using the same
US8561210B2 (en) Access to domain
JP5323685B2 (ja) 改善されたドメインへのアクセス
US9843834B2 (en) Digital rights management method and system
JP4734257B2 (ja) 接続リンクされた権利保護
US8776259B2 (en) DRM system
US20070180497A1 (en) Domain manager and domain device
JP2006500652A (ja) 証明書に基づく認証ドメイン
WO2005071515A1 (fr) Procede d'autorisation d'acces au contenu
WO2006051494A1 (fr) Amelioration de revocation dans domaine autorise
WO2006083141A1 (fr) Procede de gestion de cles dans lequel est utilisee une topologie nodale hierarchisee, et procede d'enregistrement et de retrait d'enregistrement d'un utilisateur dans lequel est utilise ledit procede de gestion de cles
KR100999829B1 (ko) 디바이스들 사이의 클래스－기반 콘텐트 전달
Koster et al. Identity based DRM: Personal entertainment domain
WO2007085989A2 (fr) Validation amelioree d’une chaine de certificats
KR20070022019A (ko) 개선된 도메인 매니저 및 도메인 디바이스
MXPA06008255A (en) Method of authorizing access to content

Legal Events

Date Code Title Description
AK Designated states

Kind code of ref document: A1

Designated state(s): AE AG AL AM AT AU AZ BA BB BG BR BW 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 KM KN KP KR KZ LC LK LR LS LT LU LV LY MA MD MG MK MN MW MX MZ NA NG NI NO NZ OM PG PH PL PT RO RU SC SD SE SG SK SL SM 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: A1

Designated state(s): BW GH GM KE LS MW MZ NA 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 IS IT LT LU LV MC NL PL 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
NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 05810537

Country of ref document: EP

Kind code of ref document: A1