"DEVICE, SYSTEM AND METHOD FOR ALLOWING AUTHORISED ACCESS TO A DIGITAL CONTENT"

Technical field

The present invention relates to a user device, to a communication system, and to a method for allowing authorised access to a digital content.

In particular, the present invention relates to a user device, to a communication system, and to a method for allowing authorised access to a digital content stored on a data carrier and accessible by at least one software application installed and running on the user device.

Background art

In the last few years portable devices with phone capabilities and considerable computing features, usually named "smartphones", have become more and more common for the average customer. Smartphones may be considered as a crossing point between two different technologies: telephony and personal computing, both of them having reached a very mature stage.

As for telephony, smartphones provide an user with the whole set of capabilities usually included in a standard mobile phone. The user inserts his/her SlM card in the smartphone which gets connected to the phone network in the usual way. From that point on, the user may initiate phone calls, receive them, send and receive messages, work with the contacts in the SEVPs address book and so on, as he/she would do with any standard mobile phone.

About the PC-like features, improvements are still expected, but as for now, smartphones are provided with an operating system which is most of the times based on a simple graphical menu and an up/down arrow-based user interface, and has one or more open software platforms (e.g. Java), which allow new applications to be installed and executed.

Many smartphones are provided with software applications allowing the user to work with text documents, images, audio and video clips, in a variety of standardized formats: these are currently a small subset of the formats supported by home personal computers, but support for all the most important (i.e. often used) file formats is expected to come soon.

As one might expect, the issue of protecting data rights arises for the smartphones as well. Just like in PC's world, where PC's users have easily been able to find ways for copying and editing copyrighted materials, it will not take long for smartphone users to copy and edit copyrighted materials as unauthorised PC's users do.

Copyrighted materials released for the smartphones are going to be vulnerable to illegal actions as well. Therefore, it is no wonder that the topic of enforcing digital rights is regarded as one of the most important by the media industry and by all the companies selling digital contents.

Many methods and architectures have been published in the past concerning the enforcement of digital rights, but none of them has proven to be successful for all data formats and for all environments. What has emerged, is that different architectures should be used to address different needs, like the kind of digital data to be protected, the data carrier supporting the data, the device used to read the data, the owner and the enforcer of the data rights, and so on.

The International Patent Application no. WO 03/088054 provides a method for protecting data delivered to a device with phone capabilities, wherein the decryption of a digital content is performed on the device. A SIM card is used to receive a decryption key from the network operator and to store it until it is needed by the application on the device handling the decryption of the digital content.

The International Patent Application no. WO 01/574692 provides a system for protecting data on a data carrier connected to a device with phone capabilities where the data is stored in encrypted format on the data carrier and a SIM card is used for enabling connection to the network. In the provided architecture, an application running on the device sends the media code, i.e. a code identifying the media to be decrypted, and the

SM code, i.e. a code identifying the SM, to the network, and the network replies with a token enabling or disabling the decryption of the media.

Object and summary of the invention

The Applicant has observed that, up to now, the solutions proposed in the art are not completely satisfactory.

For example, in respect of WO 03/088054, the Applicant has observed that the fact of transferring the decryption key to an application running on the device might considerably reduce the security level of the whole architecture, because some other application, concurrently running on the device itself, might get access to the memory assigned to the first application and read the decryption key.

Further, the Applicant remarks that the architecture described in the document no. WO 01/574692 provides a very low security level, since the SM and the network are only used to authorize the decryption process, while the decryption key is stored on the data carrier and the decryption is performed on the device.

The Applicant has tackled the problem of how to allow authorised access to a digital content stored on a data carrier, maintaining a high level of security in the decryption process, thus guaranteeing protection against unauthorized access of content stored in the data carrier.

It is therefore a first object of the present invention to provide a user device, a communication system and a method for allowing authorised access to a digital content stored on a data carrier.

It is a second object of the present invention to provide a method for increasing the level of security in accessing a protected digital content by means of a user device associated to a secure storage module, such as a SM card.

It is a third object of the present invention to provide a method for allowing authorised access to a digital content stored on a data carrier, said method being independent from the architecture of the user device employed to access such a digital content and from the

data carrier supporting the digital content.

According to the invention, the decryption key used for decrypting a digital content is stored on a secure storage module and is never transferred to a different device, hence increasing the reliability of the overall system.

According to the invention, the fact of allowing the decryption to be performed in the secure storage module leads to a high degree of security in the overall architecture. This is due to the fact that the decryption key never leaves the secure storage module, from the time it is received by the network operator to the time when it must be deleted (e.g. for making room to another decryption key). Further, the decryption algorithm is performed inside the secure storage module. These elements, all together, considerably reduce the possibility that a malicious application running on the device may get information allowing the decryption of the digital content without control by the network operator.

The decryption process is started when a software application running on the user device wishes to make use of the digital content. At this point, a decrypting module of the user's device, hereinafter referred to as Decryption Manager DM, is started to manage the decryption process. The Decryption Manager DM performs operations so as to allow the secure storage module to identify the digital content to be decrypted and the environment where the decrypted content will be used.

When all needed information is available, the secure storage module sends a short message (SMS) to a digital rights management server in the operator's network requesting the decryption key for the identified digital content. When the decryption key is received, the digital content can be decrypted and transferred to the software application which had requested it.

It is a further object of the present invention to provide a method allowing an easy management by a network operator of digital rights relative to a digital content.

According to the invention, the network operator, whose domain the secure storage module belongs to, is the enforcer of the rights, i.e. the network operator keeps the relationships between users and digital contents, knows whether each user is allowed to

use any digital content and how the content is to be used (for instance, how many times). In the architecture provided by the invention, a crucial role is played by the secure storage module, in that the secure storage module is involved in the user authentication by the network operator and in the decryption of the digital content. When the user needs to access the digital content, the encrypted parts of the digital content are transferred to the secure storage module, which performs the decryption of the encrypted parts by means of a decryption key provided by the network operator. The decryption key is sent by the network operator in conjunction with a license (content's rights) describing how the content may be used. The network operator only communicates the decryption key and the content's rights to the secure storage module after having received by the secure storage module the user ID code (e.g. IMSI or International Mobile Subscriber Identity) and the digital content code (i.e. a code identifying the digital content to be decrypted) and upon verification of user's permissions on that digital content.

Further features and advantages of the present invention will be made clearer by the following detailed description of some examples thereof, provided purely by way of example and without restrictive intent. The detailed description will refer to the following Figures, wherein:

- Figure 1 shows a system for allowing authorised access to a digital content stored on a data carrier and accessible by a user device according to the invention; - Figure 2 shows a diagram sketching the steps of a method for allowing authorised access to a digital content stored on a data carrier and accessible by a user device according to the invention.

Detailed description of preferred embodiments of the invention

With reference to Figure 1, it is shown a user device 1, having at least computing and phone capabilities such as a smartphone, which is able to communicate with a secure storage module 5, with a data carrier 4 and with one or more input/output devices 6,7,8 respectively representing for instance a display, a keyboard and a loudspeaker.

The data carrier 4 may be any data carrier currently supported by the user device 1, e.g. a multimedia card (MMC) or a flash-ROM memory embedded in the user device 1, or any

other data carrier that is supported by such user device 1.

By secure storage module 5 reference is made to a card provided by network operators to network users to allow user authentication in the operator's network. Besides, these cards are provided with internal computing capabilities and memory means for running programs, e.g. scripts or Java applets, which are also used by network operators as enablers for various types of service. Preferably, the secure storage module 5 is a subscriber identification card provided by a mobile network operator, examples for these cards are a SIM card, i.e. a Smart Card compliant with the GSM 11.11 and GSM 11.14 specifications, a USIM card, i.e. a Smart Card compliant with the ETSI 51.011 specification, and any other Smart Card having similar features.

The secure storage module 5 comprises a software or hardware decryption module 2 which is able to decrypt at least one encrypted portion of a digital content 3 stored on the data carrier 4 at least partially in an encrypted format.

A software module or Decryption Manager DM, running on the user device 1, and being preferably part of the operating system OS of the user device 1, is able to manage a decryption process of the digital content 3.

The secure storage module 5, which is preferably embedded in the user device 1, allows the user device 1 to be authenticated by an operator of a communication network 10 and to communicate securely with one or more servers S of the communication network 10. The communication network 10 may be of the GSM, UMTS, GPRS type or of any other cellular communication type.

According to the invention, at least one portion ©f the digital content 3 residing on the data carrier 4 is encrypted, so that it can not be properly played or read by a software application SA running in the user device 1 and usually employed to play or read such a digital content 3. As an example, the software application SA might be an audio player or a video player and the digital content 3 might respectively be a song or a video clip.

The total size of the at least one portion of the digital content 3 to be encrypted must be selected by taking into account the delay introduced by the secure storage module 5 for

its decryption.

The decryption process depends on the hardware capabilities of the secure storage module (e.g. on the CPU speed of the secure storage module 5) and on the data transfer rate between the secure storage module 5 and the user device 1 (e.g. the bus speed of the user device 1). In any case, the at least one portion of the digital content 3 to be encrypted must be chosen so as to allow the maximum annoyance for the software application SA trying to play or read the digital content 3 without having decrypted it first.

For instance, given the current capabilities of a secure storage module 5, the size of the at least one encrypted portion of the digital content 3 should be kept rather small, so that the decryption process is not too resource-consuming. However, as the hardware capabilities of the secure storage module-5 improve and the bus speed of the device 1 increases, the at least one portion of the digital content 3 to be encrypted will be larger and larger and eventually be the whole digital content 3.

Algorithms for encryption/decryption of the at least one portion of the digital content 3 should vary according to the format of the digital content 3 (e.g. according to its MIME type, i.e. according to the text string identifying the type of file) and must be known to the Decryption Manager DM. In fact, the Decryption Manager DM is in charge of transferring to the secure storage module 5 only the at least one encrypted portion of the digital content 3, and of reassembling the whole digital content 3 after decryption.

An example of an algorithm which can be used for encrypting at least one portion of the digital content 3 is the "3DES algorithm" which can encrypt and decrypt data using a single secret key having a length of 168 bits.

Implementations of the "3DES algorithm" inside the secure storage module 5 preferably exploit the Java API (Application Program Interface) provided by all JavaCard secure storage modules. For instance, secure storage modules complying with the 3GPP Standard are natively equipped with Java APIs to perform the 3DES algorithm (implemented in hardware). Should the APIs not be natively provided by the secure storage module 5, the algorithm might be implemented as a software module running atop of the Java Machine provided by the secure storage module 5.

For decrypting the at least one encrypted portion of the digital content 3 and consequently for allowing a proper read or play of the digital content 3 itself, it is required that the Decryption Manager DM be in execution on the user device 1, since the Decryption Manager DM is in charge of managing the decryption process of the digital content 3.

The Decryption Manager DM identifies the software application SA which will exploit the digital content 3 and the environment where the decrypted content will be run. By environment it is meant for instance data about the operating system OS or information about the input/output devices 6, 7, 8 of the device 1.

Then the Decryption Manager DM invokes appropriate procedures on the secure storage module 5 that deal with requesting to the network's operator a decryption key and with decrypting the at least one encrypted portion of the digital content 3. Said procedures dre explained in detail later when referring to Figure 2.

As an example of implementation of the invention, the digital content 3 might be an encrypted 3GP/H.263 video stream. The 3GP file format is described in the 3GPP specification TS 26.244. Said specification provides that a video stream is split in many frames (samples), each of which is described by a field "H263SampleEntry" which is a basic element in the 3GP file format.

Frames might be of type I (intraframe), thus containing information about a whole still image, and of type P (predictive), thus only containing differential information with respect to the last frame of type I. Since frames of type I are a critical part in the video stream and are only a subset of all the frames in the video stream, they are also well suited for encryption in the architecture provided by this invention. Indeed, if a media player is used to play such a video stream when still in encrypted format, such media player will be unable to correctly read said encrypted video stream, as all the reference images of the type I in the video stream are illegible because encrypted. In a 3GP video stream, encrypted frames can be described by a field "EncryptedVideoSampleEntry" in place of a field η263SampleEntry". The field "EncryptedVideoSampleEntry" therefore contains all the information provided by the field "H263SampleEntry", plus a "Protection scheme information box" with details on the original format of the video stream, as well as all requirements for decrypting the encoded video stream. Among said requirements, it is also provided an indication that the

decryption should be handled by the Decryption Manager DM and performed inside the secure storage module 5. When the Decryption Manager DM is first invoked for managing a 3GP file containing said indication, it can easily spot the parts to decrypt just by reading in the field "MedialnformationBox" all the "H263SampleEntry" boxes and by finding out which of them refer to encrypted frames. At that point, it can transfer to the secure storage module 5 those portions of video stream to be decrypted, according to the specified architecture of the user device 1.

With reference to Figure 2, it will now be described a diagram showing in detail the various steps of the method according to the invention.

When the software application SA wants to have access to the digital content 3 stored on the data carrier 4, it asks the operating system OS of the user device 1 for a content file CF containing the digital content 3 (step A).

The operating system OS of the user device 1 understands that the content file CF must be decrypted by recognizing a special extension of the name of the content file CF, through some flags in the operating system file descriptor associated to the content file CF or through some parameters set in the content file CF. Then the software application SA triggers the Decryption Manager DM by invoking the appropriate Application Program Interfaces (APIs) of the Decryption Manager DM (step B).

The operating system OS delivers to the Decryption Manager DM the name and the path of the requested content file CF and also provides the Decryption Manager DM with an indication about the software application SA which requested the content file CF.

Before anything else, the Decryption Manager DM obtains the identity of the software application SA (step C) to allow subsequent check by the secure storage module 5 for validity and/or ability to receive the digital content 3 after having decrypted it. This is a crucial point, since transferring the at least one decrypted portion of the digital content 3 to a malicious software application might allow reuse of the digital content 3 without awareness of the network 10, thereby allowing a successive unauthorized circulation and diffusion of the digital content 3.

To obtain the identity of the software application SA, the Decryption Manager DM computes a hash function on the application's image, thereby obtaining a first code IDl. The hash algorithm must be designed so that it is extremely difficult to find two application images having the same hash. An example of hash function to be used for this purpose is an implementation of the SHA-I algorithm, which is described in the document FIPS PUB 180-1 of the National Institutes of Standards and Technology. Many other algorithms of this kind, appropriately configured about padding and other parameters, may be found in literature.

Then the Decryption Manager DM obtains a second code ID2 identifying the digital content 3 (step D). The second code ID2 must be chosen so that it univocally identifies the specific content file CF, its format and its length.

Further, from this second code ID2 it must be possible to identify also which portions of the file CF are encrypted and which are in clear text.

The second code ID2 must also be easily obtained, for example it can be put in a field in the content file CF, or it can be computed from the content file CF itself (e.g. a hash function computed on the whole content file CF). This last option is also useful for stating the integrity of the content file CF.

Having gathered all the needed information, the Decryption Manager DM begins the procedure for getting the rights of the digital content 3 from the network 10. The Decryption Manager DM invokes a procedure in the secure storage module 5 (step E) by supplying the first code IDl identifying the software application SA which will exploit the digital content 3, and the second code ID2 identifying the requested digital content 3.

The secure storage module 5 receives the first code IDl and the second code ID2 from the Decryption Manager DM and checks whether the first code IDl and the second code ID2 are already contained in an internal register 9 of the secure storage module 5. The internal register 9 works as a cache for previously delivered decrypting keys. When the secure storage module 5 receives a decryption key for a digital content 3 relative to a software application SA, it stores the decryption key in the internal register 9 for subsequent use by the secure storage module 5.

If it is the first time that the digital content 3 is used, i.e. the decryption key has not been found in the internal register 9, the procedure on the secure storage module 5 packs the first code IDl and the second code ID2 into a message (e.g. an SMS), and adds a third code ID3 identifying the user (e.g. the International Mobile Subscriber Identity or IMSI). The message containing the first IDl, the second ID2 and the third code ID3 is sent to a DRM (Digital Rights Management) server S associated to the operator's network 10 while requesting the decryption key associated with the digital content 3 (step F).

The message sent by the procedure in the secure storage module 5 can contain further information to help the network operator 10 understanding the status of the user device 1 and the environment which will receive the decrypted digital content 3 (e.g. a code identifying the operating system OS of the user device 1, the version of the operating system OS, the version of the device firmware, and so on).

The message just formed can be sent through an SMS but also through other means allowing end-to-end communication between the secure storage module 5 and the network 10 (e.g. a secure GPRS/UMTS connection). After sending this message, an answer is waited by the network 10.

After having received the message from the secure storage module 5, the DRM server S associated to the network 10 checks whether the user is allowed to use the software application SA by looking up the user's rights in a first DRM database DBl, shown in Figure 1, of the network's operator 10 (step G). Then the DRM server S verifies the identity of the digital content 3 against a second DRM database DB2, shown in Figure 1, containing identity codes of valid digital contents (step H).

More particularly, it is checked whether the first code IDl is found in the database DBl and recognized as a valid code, and whether the second code ID2 is found in database DB2 and recognized as a valid code. The databases DBl and DB2 also contain information about the user's rights, that is how the digital content 3 may be used (e.g. how many times, how long and so on).

Then the DRM server S packs the response information in an SMS and sends it back to

the secure storage module 5 (step I).

If the user is authorized to use the digital content 3, then this response information will contain the decryption key for the digital content 3. It should be noted that the SMS content is itself ciphered (e.g. with a public/private key algorithm), so that only the secure storage module 5 may decrypt and understand it.

The user's rights information together with the content's decryption key is stored in the internal register 9 of the secure storage module 5 for subsequent requests. If the same software application SA intends to use the same digital content 3, it will ask for the content file CF containing the digital content 3 to the operating system OS, which will forward the request to the Decryption Manager DM (step B). The Decryption Manager DM will obtain the identity code IDl of the software application SA (step C) and the identity code ID2 of the digital content 3 (step D) and will ask for user's rights to the secure storage module 5 (step E). However, the secure storage module 5 will not need to ask for user's rights to the network 10, since it may find the information needed in its internal register 9.

If a different software application SAl intends to use the same digital content 3, the actions done by the operating system OS of the device 1 and by the Decryption Manager DM will be the same, but the secure storage module 5 this time will not contain the first code IDl identifying the application, but another first code IDl'.

In this case, the secure storage module 5 will send a new message to the DRM server S requesting again a decryption key for the digital content 3 (step F).

The information related to any digital content 3 remains stored in the internal register 9 of the secure storage module 5 until memory space is needed, e.g. for storing information related to further digital content 3'.

Once the secure storage module 5 has received the user's rights from the network 10 (or has found it in its internal register 9), the procedure invoked by the Decryption Manager DM may return a suitable code ID4 indicating whether the user has sufficient rights to use the digital content 3 (step J).

If the user has not been authorized to decrypt the digital content 3, the Decryption Manager DM returns an error to the software application SA which originally asked for the digital content 3 and might prompt the user with a dialog showing how to buy the right to exploit that digital content 3.

If the user has got sufficient rights to use the digital content 3, the Decryption Manager DM becomes responsible for the decryption of the digital content 3 and its delivery to the software application SA. Since not all the file is encrypted, the Decryption Manager DM determines the portions of the content file CF which are encrypted, on the basis of the information available to it about the format of the content file CF of the digital content 3. Then the Decryption Manager DM transfers such encrypted portions to the secure storage module 5 while asking for their decryption (step K).

Then, the procedure in the secure storage module 5 handling the decryption process returns the decrypted portions of the digital content 3 back to the Decryption Manager DM (step L). For instance, this procedure may be performed by an applet Java loaded on the secure storage module 5, as above described in detail.

As the decryption algorithm is performed by a procedure in the secure storage module 5, this procedure allows maximum security against attempts of stealing the decryption key, since the decryption key never leaves the secure storage module 5, from the time it is received by the network operator 10 to the time it gets deleted.

The Decryption Manager DM is also responsible for reassembling together the various portions of the digital content 3 (step M) and for delivering the whole decrypted file to the software application SA which requested it (step N).

Obviously, while the principle of the invention remains unchanged, the details of the implementation of the invention and its embodiments might be varied considerably with respect to what has been herein described and illustrated, without departing from the spirit and scope of the invention as defined by the appended claims.

For instance, the invention has been described with particular reference to a smartphone.

However, the invention might be applied to any device able to process audio and/or video data, like for instance a set-top box able to manage audio and/or video television signals or a digital audio player, both having a network connection, wireless or wireline, to a DRM server capable of managing user's rights.