(Field of the invention)

The present invention relates to methods of protecting access to data on a network. It relates particularly to methods of protecting access to data sent between two entities through the Internet network.

(Prior art)

On a network, data is generally provided by a server through a dedicated Uniform Resource Identifier, also named URI . In particular Uniform Resource Locator (URL) is a kind of URI. It is known to use one time URL for temporary content. The exchanges of data between a client and a server over a network may require the protection of the data conveyed through the network. The security of the exchanged data may rely on the public key scheme. The data protection may also be carried out with a session key which is known by both sides. In such a case the session key is called symmetric key. For high secure sessions, several session keys may be successively used during a unique session. For security reasons, the system must avoid to convey the session keys to be used from a side to the other side. Moreover the deployment of a large number of session keys between a client and a server is complex and required costly security mechanisms.

There is a need for providing a dynamic mechanism allowing to securely exchange one or several data between a client entity and a server entity without session key transport.

(Summary of the Invention)

An object of the invention is to solve the above mentioned technical problem.

The object of the present invention is a method of protecting access to a data which is intended to be retrieved from a first entity by a second entity through the Internet network. Said first and second entities comprise a shared secret value. Said data is reachable through a one time URI. Said method comprises a step of retrieving an addressing value from the first entity. Said method comprises a step of generating said one time URI from the retrieved addressing value and from said shared secret value. The generation of the one time URI is carried out in the second entity. Said method comprises a step of retrieving said data by using the generated one time URI.

Advantageously, the first entity may check the validity of said one time URI and may refuse the retrieving of said data if the checking has failed.

In a preferred embodiment, the one time URI may be generated by using One-Time-Password mechanism.

Advantageously, said first and second entities may comprise a second shared secret value and said data may be ciphered/deciphered with the second shared secret value .

A plurality of data may be intended to be retrieved by the second entity. A specific one time URI may be respectively generated by the second entity for each data to be retrieved.

Advantageously, several addressing values may be retrieved from the first entity and each of said addressing values may have a limited validity duration.

Advantageously, said data may be audio/video content .

The second entity may be either a hardware secure token or a couple made of a host machine and a hardware secure token connected to the host machine.

Advantageously, said first entity may be made of first, second and third machines. The first machine may be a portal server providing the addressing value. The second machine may be a content server providing the data to be retrieved. The third machine may be an authentication server able to check the validity of a one time URI .

Another object of the invention is a system comprising a host machine and a connected secure electronic token. The token comprises a shared secret value. The host machine is intended to retrieve a data from a first entity through the Internet network. The host machine comprises a first means capable of retrieving an addressing value from the first entity. The secure electronic token comprises a second means capable of generating a part of one time URI from said shared secret value. The system comprises a third means capable of generating a one time URI from both said addressing value and said generated URI part. Advantageously, the secure electronic token may comprise an identifier and the URI part may be generated from said identifier.

In a preferred embodiment, the second means may be capable of generating the URI part by using One-Time- Password mechanism.

Another object of the invention is a secure electronic token comprising a shared secret value and a token identifier. The secure electronic token is intended to be connected to a host machine. The secure electronic token comprises a means capable of generating a part of a one time URI from said token identifier and from said shared secret value by using One-Time-Password mechanism.

Advantageously, the secure electronic token may be a smart card or a hardware OTP token.

(Brief description of the drawings)

Other characteristics and advantages of the present invention will emerge more clearly from a reading of the following description of a number of preferred embodiments of the invention with reference to the corresponding accompanying drawings in which:

- Figure 1 is a first example of a system comprising a server entity and a client entity according to the invention; Figure 2 is a second example of a system comprising a server entity and a client entity according to the invention;

- Figure 3 depicts schematically the architecture of a secure electronic token according to one embodiment of the invention; and

- Figure 4 depicts two examples of URL generated according to the invention.

(Detailed description of the preferred embodiments) The invention may apply to any types of server entity and to any types of client entity which are able to manage URI . In particular, the client entity may be a unique device that embeds software application able to generate the required secret data. The client entity may also be couple made of a host machine and a hardware secure token.

The invention may apply to any types of data exchanged between two entities through a network like Internet. For example, the exchanged data may be files, HTML pages, scripts, applications or audio/video content. In particular, the invention is well-suited for protecting TV streaming over the Internet network.

The invention relies on the fact that a data is made available at a temporary URI by the server entity and on the fact that the client entity is able to automatically compute the relevant temporary URI. According to an embodiment of the invention, a unique video file may be split in a plurality of ordered segments. These segments may be successively made available at a series of temporary URI and the client entity is able to automatically compute the series of relevant temporary URI in order to get the plurality of ordered segments.

An advantage of the invention is to securely allow accessing data without ciphering/deciphering the data.

Thus time may be saved in data treatment on both server and client sides. In particular, when numerous client entities want to access the same content data on a server entity, the ciphering of the data with as many keys as client entities is very heavy, long and resources consuming.

Another advantage of the invention is to allow the use of dynamic secret values which are renewed at each session.

Thanks to the invention, the server entity is able to authenticate the client entity.

Another advantage of the invention is to avoid the distribution of scrambling keys over the network for TV streaming domain.

Figure 1 shows an example of system comprising a server entity SV that provides a client entity CL with access to a data through the Internet network according to the invention.

In this example, the server entity SV is made of three machines MAI, MA2 and MA3. The machine MAI is a portal server able to provide addressing values which are required for generating the URLs to be used for getting the data. The machine MA2 is a content server able to provide data intended to be distributed. The machine MA3 is an authentication server able to check the validity of an URI .

In a preferred embodiment, the authentication server is an OTP server. For other embodiments, the authentication server may be based on any kind of authentication mechanisms which are well-known in the network domain.

In this example, the client entity CL comprises a host machine HM and a hardware secure token ET connected to the host machine HM. The hardware secure token ET may be a smart card or an OTP token for example .

Figure 2 shows another example of system comprising a server entity SV that provides a client entity CL with access to a data Dl through the Internet network.

In this example, the server entity SV is made of a unique machine which acts as a portal server, a content server and an OTP authentication server.

In this example, the client entity CL comprises a host machine HM and a hardware OTP token ET connected to the host machine HM.

The server entity SV comprises two secret data SSI and SS2 shared with the client entity CL . These secret data SSI and SS2 are assumed to have been deployed in a secure way. The server entity SV comprises a means MSG and two addressing values AVI and AV2. The means MSG is able to generate a subset of an URL from the secret data SSI. In a preferred embodiment the means MSG is an OTP generator. The server entity SV comprises two data Dl and D2 intended to be distributed to the client entity CL .

In a preferred embodiment, the server entity SV comprises a means able to generate a series of addressing values.

The client entity CL comprises the two secret data SSI and SS2 which are stored in the token ET. The token ET comprises a means MS2 and a token identifier ID. The means MS2 is able to generate a subset of an URL. In a preferred embodiment, MS2 is an OTP generator. The host machine HM comprises two means MSI and MS3. MSI is able to retrieve addressing values from the server entity SV. MS3 is able to generate an URL from an addressing value and a subset of URL generated by MS2.

In this example, both OTP generators MSG and MS2 use the shared secret data SSI for computing OTP values. Advantageously, MSG and MS2 may be able to generate time-based OTP. Figure 3 shows an example of architecture of hardware OTP token ET according to an embodiment of the invention. The token ET contains a microprocessor MP, a communication interface INT, a non volatile memory MRY, and a working memory WM. The working memory may be a RAM memory. The communication interface INT is intended to be connected to a host machine and allows exchanging data with the connected host machine. The communication interface INT may be a contactless or a contact interface. The host machine may be a computer. The memory MRY may be an EEPROM or a Flash memory. The memory MRY contains an operating system OS, a token identifier ID, two secret data SSI and SS2 and two means MS2 and MS4. In the example of Figure 3, the memory MRY is implemented as a unique non volatile memory. The memory MRY may also be implemented as any combination of several non volatile memories of different types.

The means MS2 is able to generate a subset of an URL from the secret data SSI. In a preferred embodiment, the means MS2 is an OTP generator.

In this example, the token ET comprises a means

MS4 which is able to decipher a data by using the secret value SS2.

Advantageously, the operating system OS may comprise a virtual machine, in particular a Java ® virtual machine or a .Net ® virtual machine.

The microprocessor MP cooperates with the working memory WM and is intended to run the operating system OS. The two means MS2 and MS4 may be either software applications run by the microprocessor MP or hardware designed. These two means may be implemented as two distinct elements or merged in one or several elements.

In a preferred embodiment, the two means are implemented as two different components.

Advantageously, the token ET may be a smart card.

Figure 4 shows two examples of URL generated according to the invention.

The first URL URL1 is composed of two elements: an addressing value AVI and a part PA1. The part PA1 is made of two elements: a value GV1 and the token identifier ID. The value GV1 is a subset of URL. The value GV1 has been generated by the means MS2 or by the means MSG.

The second URL URL2 is composed of two elements: an addressing value AVI and a part PA2. The part PA2 is made of two elements: a value GV2 and the token identifier ID. The value GV2 is a subset of URL. The value GV2 has been generated by the means MS2 or by the means MSG. In the following detailed embodiments, the client entity CL is assumed to have registered to the server entity SV and to have exchange its identifier ID. In a preferred embodiment, both server entity SV and client entity CL are assumed to have access to OTP generators using synchronized OTP algorithms. In particular the synchronization may rely on the time-based OTP mechanism. Alternately, both server entity SV and client entity CL may have access to crypto engines which use synchronized algorithms.

Both server entity SV and client entity CL are assumed to be able to generate URLs in a synchronized manner. For example, the synchronization may rely on the current date/time value or on counters managed on both sides.

An example of embodiment of the method of protecting access to a data according to the invention is described below. The method comprises several steps.

In this embodiment, the server entity SV is made of a HTTP streaming portal server MAI, an HTTP audio/video content provider MA2 and an authentication server MA3. In this example, MA3 comprises an OTP generator. The server entity SV is reachable through the Internet. The server entity SV is intended to distribute audio/video content through a plurality of ordered data Dl, D2.

In this embodiment, the client entity CL is composed of a smart card ET and a host machine HM of Personal Computer type. The Personal Computer is connected to the Internet and to the smart card ET. Alternately, the host machine HM may be a TV, a set-top box, a mobile phone or any device intended to receive a data distributed by the server entity SV through Internet .

At a first step, the client entity CL generates a first request for starting a session which allows getting the data Dl . Then the client entity CL sends the request to the portal server MAI . In response to the request, the portal server sends a first addressing value AVI to the client entity CL . AVI is a value related to the data Dl . AVI allows generating a part of the URL where Dl may be reached on the Internet.

At a second step, the smart card ET generates a subset GV1 of URL from the secret data SSI. Then the smart card provides the host machine HM with the generated subset GV1 and with its identifier ID. GV1 corresponds to a part of the URL where the data Dl may be reached. The host machine HM builds the URL URL1 corresponding to the data Dl . URL1 is built from AVI, GV1 and ID. In a preferred embodiment, URL1 is generated as the concatenation of AVI, GV1 and ID as drawn at Figure 4. At a third step, the host machine HM connects the URL1. In this example, URL1 corresponds to an address in the content server MA2.

At a fourth step, the content server MA2 extracts the subset GV1 and the identifier ID from the received URL1 and asks the authentication server MA3 for an authentication of the couple (GV1, ID) .

At a fifth step, the content server MA2 authorizes the download of Dl by the host machine HM if the authentication phase has been successful.

Thus the client entity CL gets the data Dl from the server entity SV.

If a further data D2 is to be retrieved by the client entity CL, the above-described steps are repeated for the new data D2. In a first embodiment, the same addressing value AVI is used with a new generated subset GV2 of URL for building URL2. URL2 is the URL where the data D2 may be retrieved at content server MA2 side. Thus the client entity may avoid the step of requesting the addressing value from the server entity SV. In a second embodiment, a new addressing value AV2 is provided by the server entity SV.

URL1 is deactivated by the server entity SV once the data Dl has been downloaded by the client entity CL . Advantageously, URL1 is deactivated by the content server MA2.

Alternately, the authentication of the part GV1 of the URL1 may be authorized only once by the authentication server MA3.

Alternately, the URL1 may remain valid during a limited period. The validity duration of URL1 may be achieved through a time-based One-Time-Password mechanism.

Thanks to the invention the data Dl and D2 may be transmitted through Internet in clear mode. In other words, neither Dl nor D2 are encrypted.

In order to increase the security of data transport, an additional key may be used for ciphering/deciphering Dl and D2. For example, the secret data SS2 may be used as symmetric key since both the server entity SV and the client entity CL comprise the secret data SS2.

Advantageously, the addressing value AVI may be used as a public part of URLs. In this case AVI may be used by a set of client entities. Thus each client entity computes its own URL based on both the public part AVI and a private part. The private part is specific to the client entity.

Advantageously, the use of the token ET may be controlled through a value specific to the user of the token. For example, the access to the token ET may be controlled by a PIN code or a biometric value.