Vouching for source authorization

FIELD OF THE INVENTION

This invention relates to a method of providing an authentication tag over a digital object in a first device belonging to a user domain comprising a plurality of devices. The invention moreover relates to a method of processing a digital object (DO) in a second device belonging to a user domain (UD) comprising a plurality of devices. Moreover, the invention relates to a system comprising a user domain (UD) comprising a plurality of devices, a device comprised in a user domain (UD) with a plurality of devices and an authentication tag.

BACKGROUND OF THE INVENTION

In recent years, the number of content protection systems available has been growing rapidly. Some of these systems only protect the content against unauthorized copying, while others restrict the user's ability to access or use the content. These systems are often referred to as Digital Rights Management (DRM) systems. Consumers want to enjoy content without hassle and with as few limitations as possible. They want to network their devices to enable all types of different applications and easily access any type of content. They also want to be able to share/transfer content in their home environment without limitations.

The concept of Authorized Domains (ADs) or User Domains (UD) tries to find a solution to both serve the interests of the content owners (who 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 contexts are also possible. 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. In this way, an Authorized Domain

(AD) or a User Domain (UD) is a system that allows access to content by devices in the domain, but not by any others.

Authorized Domains or User Domains need to address issues such as authorized domain identification or user domain identification, device check-in, device check-out, rights check-in, rights check-out, content check-in, content check-out, as well as domain management. For a more extensive introduction to the use of an Authorized Domain, etc., see S.A.F.A. van den Heuvel, W. Jonker, F. L. AJ. Kamperman, P.J. Lenoir, Secure Content Management in Authorized Domains, Philips Research, The Netherlands, IBC 2002 conference publication, pages 467-474, held at 12-16 September 2002. In certain architectures for Authorized Domains or User Domains the entities, e.g. devices, in the domain share a symmetric Domain Key that is used, among other things, to create, access and/or authenticate objects such as content or licenses (digital objects and rights objects) that are available in the domain. One example is version 2 of the Open Mobile Alliance's DRM Architecture: Approved Version 2.0, OMA-AD-DRM-V2 0-20060303-A, 03 Mar 2006, hereafter called OMA DRM v2 for short. This document is available on the Internet at member.openmobilealliance.org/ftp/public documents/bac/DLDRM/Permanent documents/ and is incorporated by reference into the present document. In such architectures, knowledge of the Domain Key is a way of proving membership of the Authorized Domain or User Domain.

Digital Objects may be issued by a Digital Objects Issuer (DOI) which is a network entity that issues Digital Objects to the User Domain. The Digital Objects Issuer (DOI) may append a Validation Token (VT) to the Digital Object before transmitting the Digital Object to a device in the User Domain. The Validation Token is a digital object arranged to prove authorisation of the Digital Objects Issuer (DOI) by a Domain Authority for use in a user domain. An example of such a Validation Token is given in international patent application serial number PCT/IB2007/051533 "Methods to support the introduction of the Domain Issuer in OMA DRM" by Koster, P, et al. (attorney docket PHNL 005802). One element of the Validation Token is typically an expiiy date thereof. Digital Objects may be copied and/or transferred between devices in the

Authorized Domain or User Domain.

A DeviceMAC is a Message Authentication Code (MAC) over a Digital Object computed by a device in the user domain by use of the symmetric domain key. Prior to providing the DeviceMAC, the device acquiring the Digital Object for a Digital Objects

Issuer (DOI), validates the Validation Token, and only provides the DeviceMAC if the validation is successful. The DeviceMAC selves as proof to other devices in the user domain (ie. also knowing the domain key) that the Validation Token appended to the Digital Object was valid at the moment the Digital Object was acquired by a device in the User Domain. Hereby, the Digital Object with the validation Token and DeviceMAC appended may be distributed among devices in the User Domain even after the Validation Token has expired. Devices in the User Domain may accept DeviceMACs computed with current or previous Domain Keys, so that DeviceMACs remain valid after update of the Domain Key.

If a device from the User Domain is removed from the User Domain, it will not get to know updated Domain Keys. However, it can still constiiict DeviceMACs for digital objects and distribute such digital objects with an appended DeviceMAC out-of-band using an old Domain Key. Hereby, a device removed from a User Domain could distribute unauthorized digital objects in the User Domain without the permission of a Domain Authority. Such illegitimate digital objects cannot be distinguised from legitimately acquired digital objects, because DeviceMACs provided by use of old domain keys are also valid. OMA DRM v2 proposes propose to counter this threat by requiring that an acquiring device in the user domain computes, in addition to the DeviceMAC, a DeviceSign: a signature over the DeviceMAC with its secret key. This signature links the DeviceMAC (and hence the Digital Object) to the device that performed the acquisition. This way the Domain Authority managing the user domain could revoke a removed device that is suspected to illegitimately distribute Digital Objects. This method has the following disadvantages:

• An infrastructure is needed to check the revocation status of devices, e.g. device revocation lists. • Eveiy time a device receives an digital object out-of-band, it needs to check the revocation status of the source device.

• Revocation is the only way to disable a device removed from the user domain.

• When a device has been revoked, then even the digital objects it legitimately distributed before revocation become invalid for the other domain members that received them.

SUMMARY OF THE INVENTION

An object of the invention is to provide an alternative way of assuring that Digital Objects may be transferred from one device to another in a user domain, and at the

same time prohibiting devices removed from the user domain from illegitimately distributing its Digital Objects. It is moreover an object to provide a method of authenticating digital objects with an efficient handling of updates of the domain key shared by devices in a user domain. These objects and others are achieved by a method of providing an authentication tag over a digital object (DO). The method is to be carried out in a first device belonging to a user domain (UD) comprising a plurality of devices, the devices in the user domain (UD) sharing a common symmetric domain key (K _D ). The method comprises, in the first device, creating a first and a second part of said authentication tag, wherein the first part is a digital signature over said digital object (DO) by a secret key (sk) of an asymmetric key pah' and wherein the second part comprises information facilitating authentication of a public key (pk) of said asymmetric key pair by use of information on the domain key (K _D ).

By providing an authentication tag in the above two parts, the first part of the authentication tag is unchanged by updates of the domain key, whilst the second part has to be updated by updates of the domain key. Thus, the method provides an efficient replacement of the authentication tag in case of update of the domain key,, because the part to be replaced, viz. the second part of the authentication tag, is the same for all the digital objects of a device in the user domain. Knowledge of the domain key, in a first device, proves membership of the user domain and makes it possible for the second device to verify the authenticity of the public key which may be used for verifying the digital signature in the first part of the authentication tag.

An advantage of the method of providing an authentication tag of the invention is that it provides easy handling of digital objects stored offline, e.g. on a removable medium, such as a Compact disc (CD) or Digital varsatile Disc (DVD), compared to the DeviceMAC described above. For digital objects stored off-line the DeviceMAC cannot be refreshed (i.e. updated) directly in case of an update of the domain key shared by the devices in the user domain. Thus, other devices in the user domain cannot install such a digital object if its DeviceMAC is out-of-date. Instead, the DeviceMAC of the digital object would have to be refreshed by a device in the user domain that has already the digital object installed. Moreover, the devices in the user domain may transmit the second part of the authentication tag to other domain members after an update of the domain key, so that digital objects stored off-lline can still be distributed without having to be refrehsed first.

The first and second part of the authentication tag are inherently linked together in that the public key in the second part verifies the signature in the first part.

Moreover, the first and second part of the authentication tag may be linked together by concatenation.

According to the invention, the authentication facilitating information in said second part comprises the public key of the asymmetric key pair encrypted by means of said domain key. Hereby, the authentication of the public key of the first device may be checked by a device knowing of the domain key, thereby facilitating verification of the signature in the first part of the authentication tag. Only authentication tags created by means of the domain key of the user domain may be verified by a device that is a member of the user domain and therefore knows the domain key. Whenever the domain key is updated, the second part of the authentication tag may be updated for all digital objects, and thereby only the devices knowing of the latest or the updated domain key, thereby showing membership of the user domain, are able to create the authentication tag.

Alternatively, the authentication facilitating information in said second part second part comprises the public key of said asymmetric key pair and a Message Authentication Code over the public key with the domain key. Again, the authenticity of the public key of the first device may be checked by a device knowing of the domain key, thereby facilitating verification of the signature in the first part of the authentication tag. Only Message Authentication Codes of the second part of the authentication tags created by means of the domain key of the user domain may be verified by a device that is a member of the user domain and therefore knows the domain key. Again, whenever the domain key is updated, the second part of the authentication tag may be updated for all digital objects, and thereby only the devices knowing of the latest or the updated domain key, thereby showing membership of the user domain, are able to create the authentication tag.

Alternatively, said authentication facilitating information in said second part is a validation token (VT _DE V) comprising the public key of the asymmetric key pair and an identification of the user domain (DomainID) to which the first device belongs, said identificaiton of the user domain comprising information on the domain key. Hereby, the first device providing the authentication tag provided may prove its membership of the user domain by presenting a validation token (VT _DE V), which is a certification of membership issued by a Domain Authority managing the user domain. Moreover, the validation token provides authentication of the public key of the first device. Together with the signature over the digital object, in the first part of the authentication tag, this proof of membership of the user domain is linked to the digital object. It should be noted that the identification (DomainID) of the user domain may provide information on the current domain key or the

current domain key generation. In OMA the last three digits of the identification (DomainID) of the user domain indicates the domain key generation.

Advantageously, the validation token (VT _DE V) moreover comprises one or more of the following: an identification of the entity type of the first device to which the validation token (VT) belongs, the expiiy date of the validation token (VT _DE V), and the digital signature of a Domain Authority (DA) arranged to manage the User Domain. When the validation token comprises the digital signature of a Domain Authority arranged to manage the user domain, the public key of the first device may be certified by the validation token which initially has been issued by the Domain Authority which acts as a trusted party for the system defined by the User Domain. Inclusion of the expiiy date of the validation token and/or of the entity type of the first device renders validation of the validation token more secure.

Advantageously, updating of the authentication tag is performed by updating the second part of said authentication tag only. Such updating may for example be carried out in case of update of the domain key or at expiration of the validation token of a device.

It should be noted that the asymmetric key pair of the first device used in the method of the invention may be a certified key pair from a Tiiist Authority. However, the asymmetric key pair may alternatively be an arbitrary asymmetric key pair generated by the first device or supplied by a Domain Authority managing the user domain. Moreover, the asymmetric key pair of the first device may be updated when desired, since the authentication tag itself contains information on the public key of the asymmetric key pair, this information being available to any device knowing of the domain key, i.e. being member of the user domain.

Moreover, it should be noted that the term "user domain" is meant to cover any group of entities sharing a common symmetric domain key. Such a user domain could be an Authorized Domain. Moreover, the term "digital object" may denote any type of digital objects, such as rights objects, digital content, such as music, movies, TV programs, pictures, games.

The invention further provides a method of processing a digital object in a second device belonging to a user domain comprising a plurality of devices, the devices in the user domain sharing a common domain key. In the method, the digital object is received in said second device together with a validation token (VT _D O _I ) of a digital objects issuer issuing the digital object and an authentication tag over the digital object, said authenthication tag having a first and a second part, the first part comprising a digital

signature over the digital object (DO) and the second part comprising information facilitating authentication of the public key of an asymmetric key pair, the method comprising the steps of: performing a first check of whether the validation token (VT _D O _I ) is valid; - if the first check disclosed that the validation token (VT _D O _I ) is not valid, performing a second check of whether the authentication tag provided by a first device in said user domain from which said second device receives said digital object is valid, wherein said second check comprises checking the second part of the authentication tag by use of information on the domain key; and - installing the digital object, if the first or the second check disclosed a valid validation token (VT _D O _I ) or a valid authentication tag.

The method provides an installation procedure for installing the digital object in case the validation token or the authentication tag may be validated. By performing a first check on the validation token and only performing the second check in case of an invalid validation token, the digital content may be installed if the validation token is still valid. Only when the validation token is not valid, such as if the expiiy date thereof has been exceeded, the second check is performed. This provides an efficient and secure method of processing the digital object received with a validation token and an authentication tag. Only devices which are members of the user domain (UD) has knowledge of the domain key (K _D ) and thus only such domain members are able to create the authentication tag. Thus, the second part of the authentication tag guarantees the authenticity of the public key of the first device.

It should be noted that the first check on the validity of the validation token (VT _D O _I ) may include checking the expiiy date of the validation token (VT _D O _I ) and the version of the K _D ). Moreover, it should be noted that the term "first device" is meant to denote a device which has provided the authentication tag transmitted with the digital object and validation token. The first device might have acquired the digital object from a digital object issuer outside the user domain or it might have received the digital object from another device in the user domain. The term "second device" is meant to denote a device which has received the digital object together with a validation token and an authentication tag from another device in the user domain. The term "installing a digital object" is meant to denote saving save or store the digital object for immediate or subsequent use or execution. The digital object may be a rights object (RO) provided by a rights issuer (RI), the rights object specifying permissions and constraints associated with a piece of DRM content, such as a

piece of music, a movie, etc. In this case the DRM content might not be used without an associated rights object (RO).

In an embodiment of the method according to the invention the step of performing a second check comprises: - checking if the public key (pk) of the asymmetric key pair may be authenticated by means of the domain key (K _D ); if said authentication was successful, verifying the signature in the first part of the authentication tag by means of said public key (pk) of the first device. Hereby, membership of the first and second devices of the user domain is proved by their knowledge of the domain key in that only devices knowing of the domain key are able to create the authentication tag.

In an embodiment of the method according to the invention, the checking of the public key of the asymmetric key pair comprises decrypting the public key encrypted by use of the domain key. Thus, the authentication of the public key of the first device may be checked by the second device if it knows of the domain key, thereby facilitating verification of the signature in the first part of the authentication tag. Only authentication tags created by means of the domain key of the user domain may be deciypted by a device that is a member of the user domain and therefore knows the domain key.

In an alternative embodiment of the method according to the invention, the checking of the public key of the asymmetric key pair comprises verifying a message authentication code over the public key by use of the domain key. Again, the authentication of the public key of the first device may be checked by the second device if the second device knows of the domain key, thereby facilitating verification of the signature in the first part of the authentication tag. Only Message Authentication Codes of the second part of the authentication tags created by means of the domain key of the user domain may be verified by a device that is a member of the user domain and therefore knows the domain key.

In yet an alternative embodiment of the method according to the invention, the checking of the public key of the asymmetric key pair comprises verifying a validation token (VTDEV) in the second part of the authentication tag, the validation token (VTDEV) comprising the public key of the assymmetric key pair. Hereby, the second device may check the membership of the first device of the user domain by checking the validation token (VT _DE V), which is a certification of membership issued by a Domain Authority managing the user domain. Moreover, the validation token provides authentication of the public key of the first device.

In a further embodiment, the method may comprise the step of: if neither the first nor the second check discloses a valid validation token (VT _D O _I ) or a valid authentication tag, consulting a Domain Authority (DA) arranged to manage the user domain (UD) for authorisation of the digital objects issuer (DOI) or of said first device in the user domain (UD) from which said second device receives said digital object (DO). Hereby, proof of membership of the user domain may be provided by a Domain Authority, e.g. in the form of a validation token. The Domain Authority may thus check the certificate status, and the devices in the domain may trust the Domain Authority in this matter. The method according to the invention, may further comprise replacing said authentication tag with another authentication tag provided by means of the method according to claim 1 performed by the second device. Thus, when a second device receives a digital object with an authentication tag, the device checks the tag, installs the digital object if the check was successful and creates another tag. This another tag is prepared by an asymmetric key pair of the second device. Each device in the user domain has a secret key of an asymmetric key pair, so the another authentication tag is specific for the second device and is prepared by means of the secret key of the second device.

The invention moreover relates to system comprising a user domain comprising a plurality of devices, the devices in the user domain sharing a common domain key, the system moreover comprising a domain authority arranged to manage the user domain and a digital objects issuer arranged to issue digital objects to devices in the user domain, each of said devices in said system being configured for: providing an authentication tag over a digital object by creating a first and a second part of the authentication tag, wherein the first part is a digital signature over said digital object by the secret key of an asymmetric key pair and wherein the second part comprises information facilitating authentication of the public key of said asymmetric key pah'.

In one embodiment of the system, each of the devices in the user domain is arranged to check an authentication tag over a digital object and, if the check is successful, to install the digital object.

The invention moreover relates to a device comprised in a user domain with a plurality of devices, the devices in the user domain sharing a common domain key, said device being configured for:

providing an authentication tag over a digital object by creating a first and a second part of the authentication tag, wherein the first part is a digital signature over said digital object by the secret key of an asymmetric key pair and wherein the second part comprises information facilitating authentication of the public key of said asymmetric key pah'.

In an embodiment, the device according to the invention is further arranged to check an authentication tag over a digital object and, if the check is successful, to install the digital object.

The invention furthermore relates to an authentication tag comprising a first and a second part, wherein the first part is a digital signature over a digital object by a secret key of an asymmetric key pair and wherein the second part comprises information facilitating authentication of the public key of said asymmetric key pair.

BRIEF DESCRIPTION OF THE DRAWINGS Figs. 1 and 2 are diagrams of a system according to the invention;

Fig. 3 is a flow diagram of a method 10 according to the invention of providing an authentication tag over a digital object (DO); and

Figs. 4 and 5 are flowcharts of methods 20, 30 according to the invention of processing a digital object (DO) in a second device (DEV2) belonging to a user domain (UD).

DETAILED DESCRIPTION OF EMBODIMENTS

Fig. 1 shows a system 100 comprising a Domain Authority (DA), a Digital Objects Issuer (DOI) and a user domain (UD) comprising a plurality of devices (DEVI, DEV2, DEV3). In Fig. 1 only three devices are shown; however, the user domain (UD) may comprise another number of devices. Each of the devices (DEVI ; DEV2; DEV3) comprises a DRM Agent (DRMl ; DRM2; DRM3), usually embodied as a software component being executed on the device in question. In the system showed in Fig. 1 the Domain Authority is a separate device compared to the Digital Objects Issuer (DOI); however, the two devices could be integrated into one device. The devices (DEVI, DEV2, DEV3) of the user domain (UD) may be interconnected via a network (not shown) and could e.g. be 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, a car entertainment system, and so on. These devices are usually interconnected

to allow one device, e.g. the television, to control another, e.g. the VCR. In some embodiments, one device, such as e.g. the tuner/decoder or a set top box (STB), operates as central device, providing central control over the others.

Digital objects may comprise content, typically music, songs, movies, rights objects, animations, speeches, videoclips for music, TV programs, pictures, games, ringtones, spoken books and the like.

The devices may be wirelessly to the network using a base station (not shown), for example using Bluetooth or IEEE 802.1 Ib, or using a conventional wired connection. To allow the devices (DEVI, DEV2, DEV3) to interact, several interoperability standards are available, which allow different devices to exchange messages and information and to control each other. One well-known standard is the Universal Plug and Play standard (http://www.upnp.org).

The system 100 may be set up to manage access to content by operating as an Authorized Domain (AD), preferably in accordance with the OMA DRM v2 standard or a successor thereof.

The domain authority (DA) is a network entity that manages the User Domain (UD), i.a. by adding and removing DRM Agents. It provides the DRM Agents (DRMl ; DRM2; DRM3) in the devices of the user domain (UD) with a symmetric domain key (K _D ). The domain key (K _D ) may be upgraded when necessary. Further, the domain authority (DA) may authorize digital object issuers (DOIs) to issue digital objects (DOs) to the devices in the User Domain, by providing them with a Use Domain Context (UDC). A Use Domain Context (UDC) consists of a diversified domain key K _D , and a validation token (VT). The diversified domain key (K _D ,) is to be used by the Digital Objects issuer for protection the digital objects (DO). The diversified domain key (K _D ,) is computed as a one-way function of the domain key K _D and the public key of the digital objects issuer (DIO), so that DRM

Agents (DRMl ; DRM2; DRM3) of the devices (DEVI ; DEV2; DEV3) in the user domain (UD) can compute it. The digital rights issuer (DOI), however, cannot compute the domain key (K _D ) from the diversified domain key (K _D ,), SO the domain key (K _D ) remains secret.

The Validation token (VT) proves authorization of the digital objects issuer (DOI) by the domain authority (DA) for domain use. The validation token (VT) may contain the public key of the digital objects issuer, an expiiy date, and the signature of the Domain Authority (DA). However, advantageously, the validation token moreover comprises the entity type to which the validation token (VT) belongs (here the digital objects issuer (DOI)) as well as the identity of the user domain (DomainID). By including the entity tipe, validation

tokens (VTs) for other entities than digital objects issuers may be handled, such as local rights managers and DRM Agents. By including the identity of the user domain, the validation token becomes domain-specific. In OMA, the last three digits of the DomainID indicate the current domain key generation. This means in case of an update of the domain key (K _D ), the validation tokens (VTs) become invalid and the domain authority (DA) has to distribute new ones. This is a beneficial property for reasons explained below. Moreover, it hardly reduces efficiency, because update of the domain key (K _D ) update is typically a rare event, and, whenever it does occur, the domain authority (DA) needs to interact with the digital objects issuer (DOI) to send the new diversified domain key (K _D ,) anyway. Thus, here the VT is constiiicted as: VT = _/ 'entity type, expiry date, public key, Domain ID, DA signature/, where the DA signature is a signature of the domain authority (DA) computed over all the preceding items. Obviously, the domain authority (DA) generates a different diversified domain key (K _D ,) and validation token (VT) for eveiy digital objects issuer (DOI) it wishes to authorize for a certain user domain.

The digital objects issuer (DOI) is a network entity that issues digital objects (DOs) to the User Domain (UD) For this it requires an up-to-date user domain context (UDC) containing a non-expired validation token (VT) and the latest generation of the diversified domain key (K _D ,). The Digital objects issuer (DOI) encrypts the confidential parts of the digital object (DO) with the diversified domain key (K _D ,), signs the digital object (DO) with its secret key, and appends the validation token (VT) received from the domain authority (DA).

The DRM Agent (DRMl ; DRM2; DRM3) of each of the devices (DEVI, DEV2, DEV3) is a user-controlled device able to evaluate digital objects (DO). The digital objects issuer (DOI) may be rights issuer (RI), the digital objects (DO) issued being rights objects (ROs). A rights object specifies permissions and constraints associated with a piece of content, e.g. whether a content may be rendered, copied, time limits for use, etc. A content issuer (not shown) may make content (songs, films, etc.) available in protected form ("DRM Content" in the case of OMA) to the devices in the user domain (UD). To access the content, the device that received the content needs a Rights Object (RO) provided by a Rights Issuer (RI). The provision of the RO 212 may occur simultaneously with the provision of the content, but this is not necessary. For instance, a device may obtain content at a certain time and later purchase a rights object to access that content. Alternatively one may obtain a rights object and only later obtain the content to which the rights object applies.

In OMA DRM, a rigths object (RO) is an XML document specifying permissions and constraints associated with a piece of DRM Content. DRM Content cannot be used without an associated rights object (RO), and may only be used according to the permissions and constraints specified in a rights object (RO). The rights objects (ROs) contain the rights expressions and keys needed for rendering the actual content. The RO acquisition, device registration, and domain management is specified by means of a set of protocols called ROAP.

The DRM Agent (DRMl ; DRM2; DRM3) of the devices (DEVI, DEV2, DEV3) ensures that the permissions and constraints specified in a rights object (RO) are adhered to. A Rights Object (RO) is cryptographically bound to devices in the user domain by means of the domain key, so that any DRM Agent (DRMl ; DRM2; DRM3) knowing the domain key may use the rights object (RO).

Note that the Content Issuer and the Rights Issuer may be one and the same entity. In OMA terminology this entity is then referred to as a content distributor. When a device in the user domain (UD) has acquired a rights object (digital object (DO)) from a rigths issuer (digital objects issuer (DOI)), the DRM agent (DRMl; DRM2; DRM3) of the device (DEVI ; DEV2; DEV3) validates the validation token (VT) by checking the expiiy date and the signature of the domain authority (DA). Furthermore, it checks whether the rights object (RO) has a valid RI signature and is created with an up-to- date diversified domain key (K _Dl ). If all checks are passed, the DRM Agent (DRMl ; DRM2; DRM3) accepts the rights object (RO) and computes a tag.

Hitherto, it has been known to compute a tag called the DeviceMAC. The DeviceMAC is arranged to serve as a proof to other DRM Agents that the validation token (VT) was valid at the moment of RO acquisition. This way, the RO can be distributed out-of- band among DRM Agents even after the validation token (VT) has expired. DRM Agents accept DeviceMAC s computed with the current or previous domain keys, so that they remain valid even after domain key update. The domain authority (DA) has two ways to stop RI functionality. The first way is to stop providing new validation tokens, so the RI can no longer issue new rights objects (ROs) after its current validation token (VT) expires. The second way is to perform a domain key update without providing the rights issuer (RI) with a corresponding, up-to-date diversified domain key. Such domain key update directly excludes that particular rights issuer (RI), but also entails interaction with all DRM Agents and remaining rights issuers (RIs).

Fig. 2 shows a system 200 comprising a Domain Authority (DA) and an import device 210. The Import Device (210) is a user-controlled device consisting of two components: the local rights manager (LRM) and a DRM Agent (DRMl ). These components mimic the RO acquisition from an rights issuer. The local rights manager (LRM) requires a user domain context (UDC) from the domain authority (DA), the user domain context (UDC) consisting of a diversified domain key (K _D ,) and a validation token (VT) (with entity type set to a local rights manager (LRM)). Similar to a rights issuer, the local rights manager (LRM) computes right objects (ROs) using the diversified domain key (K _D ,) and the validation token (VT) of the user domain context (UDC). The DRM Agent component (DRMl ) of the import device (210) has joined the User Domain (UD) and has acquired the domain key (K _D ). The DRM agent (DRMl ) of the import device (210) may check the rights object (RO) and validation token (VT) and append a tag. The rights object may now directly be distributed out-of-band. The difference with a DRM Agent acquiring an rights object (RO) from a rights issuer (RI) is that both entities are contained in the same device: the Import Device (210). Moreover, the system 200 comprises a user domain (UD) comprising a plurality of devices (DEV2, DEV3). The DRM agent (DRMl ) of the import device 210 has joined the user domain (UD). Apart from the DRM agent (DRMl ) of the import device 210, only two devices (DEV2, DEV3) are shown in the user domain (UD); however, the user domain (UD) may comprise another number of devices. Each of the devices (DEV2, DEV3) comprises a DRM Agent (DRM2; DRM3), usually embodied as a software component being executed on the device in question. In the system showed in Fig. 2 the Domain Authority (DA) is a device separate from the Local rights manager (LRM). The domain authority (DA) is a network entity that manages the User Domain (UD), i.a. by adding and removing DRM Agents. It provides the DRM Agents in the user domain (UD), viz. the DRM agent (DRMl )in the import device 210 and the DRM agents (DRM2; DRM3) in the devices

(DEV2; DEV3) of the user domain (UD) with a symmetric domain key (K _D ). The domain key (K _D ) may be upgraded when necessary. Further, the domain authority (DA) may authorize the local rights manager (LRM) to issue digital objects (ROs) to the devices in the User Domain (UD) and to the DRM agent of the import device 210, by providing it with a Use Domain Context (UDC). A Use Domain Context (UDC) consists of a diversified domain key K _D , and a validation token (VT). The diversified domain key (K _D ,) is to be used by the Local rights manager (LRM) for protection the rights objects (DO). The diversified domain key (K _DI ) is computed as a one-way function of the domain key K _D and the public key of the local rights manager (LRM), so that the DRM Agents (DRMl, DRM2, DRM3) in in the user

domain (UD) can compute it. The local rights manager (LRM), however, cannot compute the domain key (K _D ) from the diversified domain key (K _D ,), SO the domain key (K _D ) remains secret..

The exemplary embodiment described in relation to Figs. 1 and 2 is given in relation to an OMA architecture comprising a Domain Authority (DA), a Digital Objects Issuer (DOI) or Local rights manager (LRM) as well as DRM agents. In the following, the digital object (DO) is a rights object (RO) and a digital objects issuer (DOI) is a rights issuer (RI). It should be noted that the invention is not limited to OMA architectures, but may be employed in any user domain formed by a group of entities sharing a common symmetric key. Moreover, the invention is not limited to rights objects (RO), but may be employed to any digital objects.

The split shown in figs. 1 and 2 between the domain authority (DA) and rights issuer (RI) (fig. 1 ) or local rights manager (LRM) (fig. 2) causes the following problem. A DRM Agent receiving an rights object (RO) out-of-band cannot check whether the issuer (i.e., RI or LRM) was authorized at the moment of acquisition. A general solution to this problem is for the acquiring DRM Agent to add to the rights object (RO) a new element, viz. a tag. This Tag selves to prove to other DRM Agents (receiving the RO out-of-band) that the RO was acquired by a compliant member of the User Domain (UD). This in turn convinces the receiving DRM Agent that the RO was legitimately acquired from an authorized RI or LRM.

The DeviceMAC described above is such a tag. However, the DeviceMAC suffers from the following security threat. Consider a DRM Agent that has been removed from a User Domain and therefore does not know the up-to-date domain key (K _D ). It can still construct a valid DeviceMAC for an RO and distribute it out-of-band using an old domain key. This way a removed DRM Agent could collude with an unauthorized issuer (either RI or LRM) to distribute ROs in the User Domain without the DA's permission. These illegitimate RO s cannot be distinguished from legitimately acquired ones, because DeviceMAC's from old domain keys are also valid. Note that the introduction of the Import Device, which incorporates both the LRM and DRM Agent components in a single user-controlled device (see (210) of fig. 2), makes such a collusion attack even much more feasible.

A different solution for DeviceMACs could be the following. In case of a domain key update, the DRM Agents in the domain refresh the DeviceMACs of all their ROs, i.e., compute a fresh DeviceMAC with the new domain key for eveiy RO. Then only DeviceMACs with the current domain key are accepted, eliminating the threat of

DeviceMAC forgery by ex-members with an old domain key. The disadvantage, however, is the inconvenience of having to re-compute the DeviceMACs of all ROs every time a key update takes place. Moreover, ROs might be stored on a removable medium, which makes direct update of their DeviceMACs impossible. The invention proposes an alternative tag compared to the DeviceMAC as described in the following in connection with the description of Figs. 3 to 5.

Fig. 3 is a flow diagram of a first method 10 according to the invetion. The method starts at step 1 1 and continues to step 12, wherein a tag according to the invention is created. The tag may be created and checked as described in any of the examples 1 to 3 below. The method ends at step 13.

Example 1 :

The tag of Example 1, Tagl, consists of a signature over the digital object (DO) with the secret key (sk) of the DRM Agent of a device (DEVI ) (see fig. 1 or 2), concatenated with the symmetric encryption of the public key (pk) of the DRM Agent with the domain key (K _D ):

Tagl = SIGN _ik (DO) \\ ENC^ ipk) .

To check Tagl, a receiving DRM Agent in another (DEV2) (see fig. 1 or 2) of the devices in the user domain (UD) deciypts KIλ P* ⁾ _us i _n g the up-to-date domain key (K _D ), and uses the resulting public key (pk) to verify the signature over the digital object (DO). This check only succeeds if the Tagl was created with the current domain key (K _D ). The receiving DRM Agent (in DEV2) may replace Tagl with its own tag, i.e., the DRM Agent of DEV2 signs the digital object (DO) with its own secret key (sk) and appends the encryption of its public key. In case of a domain key upgrade, the DRM Agents only need to refresh the encryption part KIλ P* ⁾ _{^ wn} i _cn i _s equal for all its tags. The signatures, which are DO-specific, remain unchanged. The encryption part of the Tag proves knowledge of the domain key (K _D ) and hence proves domain membership. This membership proof is linked to a specific digital object (DO) by the signature.

Example 2:

The tag of example 2, Tag2, consists of a signature over the digital object (DO) with the DRM Agent's secret key (sk), concatenated with the corresponding public key (pk) and a MAC over the public key (pk) with the domain key (K _D ):

Tag 2 = SIGN^ (DO) \\ pk \\ MAC^ ipk) .

To check Tag2, a receiving DRM Agent in a device (DEV2) (See Fig. 1 or 2) verifies the MAC over the public key (pk) with the current domain key (K _D ). If the MAC is correct, it uses the public key (pk) to validate the signature. The receiving DRM Agent (DEV 2 in Figs. 1 and 2) replaces Tag2 with its own tag, i.e., the DRM agent signs the digital object (DO) with its own secret key and appends its public key (pk) and the MAC over the public key (pk) with the domain key (K _D ). When the domain key (K _D ) is upgraded, the DRM Agent only needs to refresh the message authentication code " ' ^ ¹ ^ ' which is equal for all its tags. The signatures, which are DO-specific, remain unchanged. The MAC shows knowledge of the domain key (K _D ) and hence proves domain membership. This membership proof is linked to a specific digital object (DO) by the signature.

Example 3:

The tag of example 3, Tag3, consists of a digital signature over the digital object (DO) with the DRM Agent's secret key (sk). In this example, the corresponding public key (pk) is certified by means of a Validation Token (VT _DE V) issued by the domain authority (DA) (See Fig. 1 or 2). This validation token (VToEv)has five items as described above, with the entity type now indicating that the validation token (VT _DE V) belongs to a DRM Agent of a device (DEV 1 ) (See fig. 1 or 2). Tag3 is then defined as follows:

TaOi = SIGNJDO) W VT ₁ DEI

To check Tag3, a receiving DRM Agent of a device (DEV 2) (See Fig. 1 or 2) validates the validation token (VT _DE V) by verifying the expiiy date, the domain key generation, and the DA ^' s signature. If the validation token (VTDEV) is valid, the contained public key (pk) is used to verify the signature over the digital object (DO). Upon installing the digital object (DO), the receiving DRM Agent of the device (DEV2) replaces Tag5 with its own tag. Whenever the validation token expires (either because of domain key update, or

because the expiry date is reached) it needs to be replaced. Conveniently, the signature parts of the tag, Tag5, remain unchanged.

Tag3 is conceptually different from Tagl and Tag2 in the way domain membership is proved. Namely, instead of proving knowledge of the domain key (K _D ), DRM Agents now present their validation token (VT _DE V), which is a certification of membership issued by the DA. Besides proof of membership, this validation token (VT _DE V) provides authentication of DRM Agent's public key (pk). Together with the signature over the digital object (DO), this links the membership proof to the digital object (DO).

Fig. 4 is a flowchart of a method 20 according to the invention of processing a digital object (DO) in a second device (DEV2) belonging to a user domain. The method 20 is to be performed in a second device (DEV2) belonging to a user domain (UD) comprising a plurality of devices (DEVI, DEV2, DEV3), the devices in the user domain (UD) sharing a common domain key (K _D ). The digital object (DO) is received in said second device (DEV2) together with a validation token (VT _D O _I ) of a digital objects issuer (DOI) issuing the digital object (DO) and an authentication tag (Tag) over the digital object (DO), said authentication tag (Tag) having a first and a second part, the second part comprising information facilitating authentication of the public key (pk) of an asymmetric key pair.

The method 20 starts at step 21 and continues to step 22, wherein a first check is performed, viz. a check of whether the validation token (VT _D O _I ) is valid. If the validation token (VT _D O _I ) of the digital object issuer (DOI) is valid, the method continues to step 24, wherein the digital object (DO) is installed. The method ends in step 29.

If the check of step 22 disclosed that the validation token (VT _D O _I ) is not valid, the method continues to step 23, wherein a second check is performed of whether the authentication tag (Tag) provided by a first device (DEVI ) in said user domain (UD) from which said second device (DEV2) receives said digital object (DO) is valid. The second check performed in step 23 comprises checking the second part of the authentication tag by use of information on the domain key (K _D ) and verifying the signature in the first part of the authentication tag. If the check of step 23 disclosed a valid authentication tag (Tag), the method continues to step 24, wherein the digital object (DO) is installed, and ends in step 29. Otherwise, the method continues to step 29 from step 23, wherein the method is ended.

Fig. 5 is a flowchart of a methods 30 according to the invention of processing a digital object (DO) in a second device (DEV2) belonging to a user domain. The steps 31 to 33 of the method 30 correspond to the steps 21 to 23 of the method 20; the steps 35 and 39 of the method 30 correspond to the steps 24 and 29 of the method 20. These corresponding

steps will not be described in further detail here. If the check in step 33 of the method 30 disclosed a valid authentication tag (Tag), the method 30 continues to step 35, wherein the digital object (DO) is installed, and ends in step 39. Otherwise, the method continues to step 34 from step 33, wherein a Domain Authority (DA) is consulted. The Domain Authority (DA) is arranged to manage the user domain (UD) for authorisation of the digital objects issuer (DOI) or of said first device (DEVI ) in the user domain (UD) from which said second device (DEV2) receives said digital object (DO). If the Domain Authority in step 34 provides authorisation of the Digital Objects issuer (DOI) or of the first device (DEVI ), whichis the source device for providing the digital object (DO) to the second device (DEV2), the method continues to step 35 and subsequently to step 39. Otherwise, the method goes directly from step 34 to step 39, wherein the method is ended.

It should be noted that the checks in step 22, 23 of the method 20 of Fig. 4 and the checks in step 32 and 33 of the method 30 of Fig. 5 may be as described in connection with examples 1 to 3 above. All proposed Tags (i.e. Tagl, Tag 2 and Tag3) use digital signatures.

Generally, signatures do not only authenticate the message but also the originator. However, what is important is whether the originator device providing the digital object to another device is a member of the user domain. Even if it could be stated that the use digital signatures might be an overly heavy tool for the purpose, it has the advantage of making it possible to avoid the hassle with certificates proving the authenticity of the public key and identifying this key as belonging to a particular DRM Agent. Instead, a simple proof that the used public key belongs to some (unspecified) domain member (i.e. a device in the user domain) provides the required level of authentication: domain membership of the acquiring DRM Agent. The Tags differ in the way they prove this membership: • Tag 1 includes an encryption of the public key, thereby showing knowledge of the domain key (K _D ).

• Tag 2 includes a message authentication code (MAC) over the public key, thereby showing knowledge of the domain key (K _D ).

• Tag 3 presents a validation token (VT _DE VK thereby showing authorization by the domain authority (DA).

The above implies that DRM Agents need not even use their official, certified key pah's but can use an arbitrary key pair. This key pair can be either generated by the DRM Agents themselves or supplied by the domain authority (DA), and can be updated when desired.

An advantage of the tags Tagl is that the use of the domain key is restricted to to its intended purpose, viz. encryption. Another advantage of Tagl is that the public key is shielded from outsiders, which could be preferable from privacy point of view.

As for Tag 3, the used public key is 'certified' by the validation token (VT _DE V) issued by the DA. This validation token (VT _DE V) merely assures that the owner of the key is a member of the domain, and hence it can be seen as a 'lightweight certificate' issued by the domain authority (DA), which acts as a taisted party for the system defined by the User Domain (UD).

It should be noted that the three examples of the tags are well compatible. In case each type of Tag is allowed, a DRM Agent can authenticate the signature part

SIGNJRO ⁾ _{by either} ENC^ (Pk) _^ MλC^pk) _{Qγ γτ , whichever one suits him best} .

As explained above, the known non-updatable DeviceMAC, which is accepted also for old domain keys, is insecure, because it allows removed DRM Agents to keep distributing digital objects (DOs) to the devices in the domain. The known updatable DeviceMAC, which is accepted only for new domain keys, is DRM Agent-independent, so a receiving DRM Agent can conveniently retain the DeviceMAC it receives with the digital object (DO). However, in case of a domain key update, a DRM Agent has to recompute the DeviceMACs for all its digital objects (DOs). Even though message authentication codes are an efficient symmetric technique, this can be a lot of work when a DRM Agent has a large number of digital objects (DOs). Moreover, there is a problem for digital obejcts (DOs) stored off-line (e.g., on a removable medium), for which the DeviceMAC cannot be refreshed directly. Hence, other DRM Agents cannot install such an RO, because of its out-of-date DeviceMAC. Instead, its DeviceMAC first has to be refreshed by a DRM Agent that has already installed the RO. Contrary to the known DeviceMACs, for the proposed authentication tags of the invention, the receiving DRM Agent always needs to create a new device specific authentication tag by signing the digital object (DO) with its secret key (sk). Even though the creation of a digital signature is a relatively expensive operation, the method of the invention is advantageous, in that refreshment of these authentication tags in case of key update is very efficient, because the part to be replaced (i.e., encryption, MAC, or VT) is the same for all the tags of a DRM Agent. This also means that DRM Agents can send around this variable part (i.e the second part of the authentication tag) to other domain members after an update of the domain key (K _D ). Hereby, digital objects (DOs) stored off-line may still be distributed, without having to be refreshed first. Alternatively, receiving DRM Agents can request this

information from the domain authority (DA) rather than from the source DRM Agent (DRM of DEVI ).

As explained above, the key pair used for the signature in Tagl and Tag2 does not have to be the DRM Agent's certified key pair, but can be a random key pair. The domain authority (DA) may act as a tiiist centre by certifying this key pair by means of a validation token, since the DRM Agents inherently trust the domain authority (DA) and the DRM Agents are interested in each other's membership of the domain rather than each other's exact identity. Therefore, the use of certified key pairs and the corresponding inconvenience with certificates and revocation lists may be avoided. The above also applies to issuers of rights objects and digital objects (e.g. rights issuers (RIs) and local rights managers (LRMs)). Namely, DRM Agents do not need to know the exact identity of the issuer; they merely want to be assured of their being authorized for domain use by the domain authority (DA). The validation token (VT) proves this authorization. When the domain authority (DA) checks the certificate status of an issuer before it provides it with a validation token (VT), the DRM Agent does not have to do this again. Hence, the inconvenience of certificate checking can be off-loaded from the DRM Agent to the domain authority (DA), thereby reducing the responsibility and workload for the DRM Agents. Ultimately, the DRM Agent does not need an RI or LRM context in order to acquire rights objects (ROs) or digital objects (DOs) anymore. This means that an authorized issuer can issue rights objects (ROs) or digital objects (DOs) to member DRM Agents using any mechanism (e.g., out-of-band distribution) instead of requiring a formal protocol (such as ROAP).

It should be noted that throughout this specification, the expression asymmetric key pair is meant to denote a pair of cryptographic keys, viz. a public key (pk) and a secret key (sk). The secret key may also be denoted "private key". The secret key is kept secret, while the public key may be widely distributed. The keys are related mathematically, but the private key cannot be derived from the public key. A digital object signed by means of the secret key may be verified only with the corresponding public key. Conversely, symmetric cryptography uses a single symmetric key (in this specification the domain key is such a key) for both encryption and decryption or for creating and/or verifying a Message Authentication Code (MAC).

Moreover, 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 constiiied 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 a 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.