(19)
(11)EP 2 641 208 B1

(12)EUROPEAN PATENT SPECIFICATION

(45)Mention of the grant of the patent:
29.04.2020 Bulletin 2020/18

(21)Application number: 11808938.2

(22)Date of filing:  15.11.2011
(51)International Patent Classification (IPC): 
G06F 21/00(2013.01)
H04N 21/442(2011.01)
H04N 21/6334(2011.01)
G06F 21/12(2013.01)
G06F 16/23(2019.01)
H04N 21/258(2011.01)
H04N 21/426(2011.01)
H04N 21/6377(2011.01)
G06F 21/16(2013.01)
(86)International application number:
PCT/IB2011/055083
(87)International publication number:
WO 2012/066471 (24.05.2012 Gazette  2012/21)

(54)

METHOD TO DETECT CLONED SOFTWARE

VERFAHREN FÜR DEN NACHWEIS VON GEKLONTER SOFTWARE

PROCÉDÉ PERMETTANT DE DÉTECTER UN CLONE LOGICIEL


(84)Designated Contracting States:
AL AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HR HU IE IS IT LI LT LU LV MC MK MT NL NO PL PT RO RS SE SI SK SM TR

(30)Priority: 19.11.2010 US 415363 P

(43)Date of publication of application:
25.09.2013 Bulletin 2013/39

(73)Proprietor: Nagravision S.A.
1033 Cheseaux-sur-Lausanne (CH)

(72)Inventors:
  • FISCHER, Jean-Bernard
    25370 Rochejean (FR)
  • MARCACCI, Patrik
    1020 Renens (CH)
  • SCHWARZ, Christian
    1418 Vuarrens (CH)
  • WYSEUR, Brecht
    1305 Penthalaz (CH)

(74)Representative: Hoyng Rokh Monegier LLP 
Rembrandt Tower, 31st Floor Amstelplein 1
1096 HA Amsterdam
1096 HA Amsterdam (NL)


(56)References cited: : 
WO-A2-02/17555
US-A1- 2006 107 323
US-B1- 6 650 753
US-B2- 7 676 436
WO-A2-02/052389
US-A1- 2007 174 472
US-B2- 7 228 427
  
      
    Note: Within nine months from the publication of the mention of the grant of the European patent, any person may give notice to the European Patent Office of opposition to the European patent granted. Notice of opposition shall be filed in a written reasoned statement. It shall not be deemed to have been filed until the opposition fee has been paid. (Art. 99(1) European Patent Convention).


    Description

    TECHNICAL FIELD



    [0001] This invention concerns the field of integrated receiver/decoder receiving data from a central broadcasting equipment; the access to these data being subject to conditional access.

    BACKGROUND



    [0002] A major problem in software security is to prevent illegitimate copying and usage of software.

    [0003] In a pure software solution, this problem is impossible to solve in a disconnected use case. However, when a connection is available to a trusted entity (e.g., a verification server), this connection can be used to deploy some security mechanisms (both in the case of a continuous connected as an occasionally connected use case). Despite this, in a distributed use case (where a large population of users is allowed to use the software), it is still difficult to detect and block copies.

    [0004] Locking software to the hardware of their platform is not always an option. First of all, this may not be feasible due to the lack of trusted hardware or a bootstrap mechanism. Secondly, a user should always be allowed to migrate his software to another platform, or to change his hardware or software configuration.

    [0005] In the present setting, a player can be easily cloned with all his secrets and run on thousands of computers at the same time. Therefore, a user paying a flat fee to access content would have a good incentive to resell copies (clones) of his player to other users.

    [0006] WO 02/17555 A2 recites systems, methods and computer readable media for enabling a server device to validate one or more client devices. A shared unpredictable secret is generated. The shared unpredictable secret is stored in the client device and in the server device. The client device proves possession of a correct shared unpredictable secret to the server device. The shared unpredictable secret is replaced by a new shared unpredictable secret each time the client device is validated by the server device.

    [0007] US 2006/107323 A1 recites a system and method for providing secure communications between client communication devices and servers. A server generates a random offset. The server alters a server communication device dynamic credential by applying the random offset to the server communication device dynamic credential. The server stores the server communication device dynamic credential.

    [0008] WO 02/052389 A2 recites a method for preventing the use of more than one identical security module for identifying and using resources managed by a management centre. Therefor, the invention provides an anti-cloning method based on storage of identification numbers of user units connected to said security module. When a connection is set up with a management centre, said numbers are transmitted and compared with the numbers of a previous transmission.

    [0009] US 7 676 436 recites enabling a user to acquire an item (e.g., a digital song, digital video, etc.) using one device (e.g., a portable device) and to easily move a copy of the acquired item from the one device to another device so that a user of the other device can play the item.

    [0010] US 2007/174472 A1 recites a security system for network communications with client devices A server compares covert identifiers received from client devices in order to detect possible clones.

    SUMMARY OF THE INVENTION



    [0011] While the invention is defined in the independent claim, further aspects of the invention are set forth in the dependent claims, the drawings and the following description.

    BRIEF DESCRIPTION OF THE DRAWINGS



    [0012] The present invention will be better understood thanks to the attached figures in which:

    Figure 1 shows a cloning detection diagram, which is based on a dynamic tag verification, according to a first embodiment of the present invention,

    Figure 2a illustrates a second embodiment of the invention, in particular a message authentication based on a dynamic credential to detect cloning.

    Figure 2b illustrates another variant of the embodiment shown in Fig. 2a.

    Figure 3 illustrates a third embodiment of the invention, where a tag update condition is enforced prior to content delivery.


    DETAILED DESCRIPTION



    [0013] The main idea of the solution suggested in the present invention is based on the observation that each client software component (e.g. a media player) will have a different content usage. Each content usage generates a unique usage history which allows to trace the legitimacy of the software and facilitate the detection of illegitimate copies.

    [0014] More concretely, a server will keep track of the usage history of each client via the use of the tag value. The tag value represents the usage (partially or fully) while preserving the privacy of the history. At every valid request, this tag value will preferably be updated, thus causing a desynchronization between copies made from this implementation, given that when a copy is made, it will fork from the history of the original client, and its usage will deviate from the usage of the original client. It is precisely this deviation which can be detected.

    [0015] Referring to Figure 1 showing a first embodiment of the invention, each client (C) receives an initial random tag value tc which can be embedded into the software player at initialization time or which can be transmitted by the server during the first authentication with the latter. The server will have the tag values of all clients in a database. This initial tag value tc may be also sent to the client of the user unit by any conventional communication means such as, but not limited to, a letter, a SMS, a phone call, an email, a web page, or any combination thereof. At its side, the server has opened a new record in its database for storing this tag value tc. Thus, both the user unit and the server possess the same tag value tc at the end of this first phase, named initialization phase.

    [0016] In order to implement this initialization phase, the following steps are undertaken:
    • defining the tag value (tc) as being equal to an initial random value,
    • opening a new record storing said tag value (tc) in the server database,
    • introducing this tag value (tc) into the client user unit.


    [0017] The step aiming to define the tag value as being an initial random value aims to take an unpredictable value as first tag value.

    [0018] During an operating phase and while referring still to Figure 1, when a client requests a service from the server, via a common communication network connecting the client user unit to this server, his tag value tc will be sent along, within a message named client message. The server will verify if the tag value, included in the client message, is also present in its database If such a comparison give a correct result, the server will grant the requested service (or proceed with verifying other requirements). If the tag value sent within the client message is not listed in the database or cannot be verified correctly, then the requested service will be refused.

    [0019] The tag value tc can be the digest of a compression function, such as a cryptographic hash function, applied to the client request. Although good derivation functions provide digests that are difficult to guess, an attacker such as a man-in-the-middle, known by the person skilled in the art, could still attempt to gain access to a service either by grabbing or guessing tag values.

    [0020] To prevent any attack, a first solution is to undertake communications between the client and the server through a protected channel (i.e. by means of an encrypted and authenticated communication between client and server). In this case, the tag value can be directly appended to the request, and hence the server can perform a direct verification by checking if the tag is comprised in the database of the server (as shown in Fig. 1).

    [0021] Besides, if a cryptographic hash function is used to derive a new tag from the old tag and usage history, then this tag value is unique per user and can therefore be used as an identifier for identifying each client. This facilitates an anti-cloning verification without the need to associate requests to individuals and therefore leading to transparent, faster and anonymous verifications (however, this does not exclude to append a unique client identifier to the request in the client message). Depicted in Figure 1, this use-case is a remote attestation protocol that should only be used in cases where a malicious person is not able to actively spoof and tamper with the connection between the client and the server (e.g., in a secure home-domain or when communication between client and server are over an authenticated secure channel).

    [0022] Corresponding to each valid request, both the client and the server will update the tag value. The new tag value t'c will be derived from data that is known by both the client and the server: for instance, the old tag value and information obtained from at least a part of the content of the server message that is provided as response to the client request. Alternately, the new tag value t'c can derive from the last tag value tc and from at least a part of the content of the client message. The server message or the client message (or a part of their content) can be a timestamp that is embedded in the media stream or any other header information, over-encrypted cryptographic keys that are sent along, specific frames, etc. The new tag value t'c being destined to replace the old tag value tc.

    [0023] To this end, this operating phase requires the steps of:
    • preparing, on the user unit side, a client message comprising a request together with the tag value tc, then
    • sending this client message, from the user unit to the server,
    • performing an access condition test, on the server side, aiming to test if this tag value tc is comprised in the database of the server. In negative outcome (i.e. negative event): deny the requested service, whereas in positive outcome (i.e. positive event):
    • sending a server message to the user unit, as a response to the client request,
    • updating the tag value tc, both on the server side and on the user unit side, by replacing this value tc by a new tag value t'c. This new tag value t'c being derived from the last tag value tc and from other data known by both the client and the server,
    • storing the new tag value t'c in the user unit (i.e. in a memory) and in the record of the database connected to the server (e.g. by replacing the old tag value tc).


    [0024] If a copy of the client software implementation is made, a desynchronization will occur when one of them (either the original or the copy) requests a service. Hence, an authentic user has no incentive to share his client software implementation, since the use of the copy would eventually deny his original to be able to be granted access.

    [0025] Advantageously, a user can still migrate his software implementation to another platform without any problem.

    [0026] Referring to Fig. 2a, the latter discloses another embodiment of the invention which is usable for preventing any attack while using an unsecured channel. The solution suggested in this embodiment aims to sign the client request by using a key, deriving directly or indirectly from the tag value tc, obtained by a signature key derivation function. Thus, during the operating phase, when a client requests a service from the server (e.g. via an unsecured communication channel), a signature of the request will be sent along with the request within the client message. As shown in Fig. 2a, this signature can be appended to the request as an authentication code of the client message. This signature is obtained firstly by applying a compression function to the client request in order to obtain a digest of the request, then encrypting this digest with a signature key which is derived from the tag value and obtained by using the signature key derivation function. For instance, the compression function can be a hash function or a HMAC function which takes as key the tag value tc, or a value derived thereof. By this way, the value of the signature depends on the tag value. The server is able to verify the authentication of the client request by comparing the signature comprised in the client message with a signature computed by the server in a similar manner to that determined by the client user unit. To this end, the server uses the same signature key (obtained from the same signature derivation function and the tag value stored in its database) to decrypt the signature appended to the request and then obtaining the digest of this request. Then, the server computes a digest from the request by using the same compression function as that used by the user unit. If this digest is identical to the decrypted digest, therefore the comparison gives a correct result and the signature is defined as being valid. If the signature is valid, the server will grant the requested service (or proceed with verifying other requirements) and the tag value can be updated as mentioned above in reference to Fig. 1. If the signature sent within the client message cannot be verified correctly, therefore the requested service will be refused (further steps can also performed by the server as consequence of a denied service).

    [0027] In order to implement the embodiment shown in Fig. 2a, the initialization phase disclosed with the embodiment shown in figure 1 has to be amended by undertaking the following additional steps:
    • defining a signature function (e.g., an HMAC function) and a signature key derivation function to obtain a signature key (derived preferably from said tag value tc) for encrypting a digest resulting from this signature function,
    • sharing the definition of this signature function and the definition of the signature key derivation function between the user unit and the server.


    [0028] As previously disclosed with reference to Fig. 1, sharing these data during this initialization phase can be achieved through many different manners, as long as the value and/or function can be introduced, at the end of this step, into the client user unit. At the end of this initialization phase, the user unit and the server possess the same initial data.

    [0029] The operating phase of the embodiment illustrated by Figure 2a further requires the following steps, in addition to or instead of those relating to the first embodiment (same phase):
    • calculating an authentication code by applying the signature function to the client request and by using the signature key for encrypting the digest resulting from said signature function, then amending the preparation step of the client message by preparing a client message comprising the authentication code and the client request,
    • amending the access condition by checking if the authentication code received within the client message is equal to an authentication code calculated by the server by applying the same signature function to the client request and by using the same signature key for decrypting said digest; where the signature key is preferably derived from the expected tag value that is stored in the server database.


    [0030] Referring now to Figure 2b, the latter shows a variant of the embodiment shown in Fig. 2a. During the initialization phase, each client software implementation has installed a unique identifier IDc, and an initial random tag value tc. The server stores the tuples (IDc, tc) of all his legitimate clients. Thus, with respect to the initialization phase of the embodiment shown in figure 2a, the following additional steps are undertaken:
    • allocating a unique identifier IDc to the client and storing this client identifier IDc in the new record assigned to this client,
    • sharing this identifier IDc between the user unit and the server (preferably jointly with the definition of the signature function).


    [0031] As previously mentioned, sharing or obtaining these data during this initialization phase can be achieved through several manners, as long as data can be introduced, at the end of this step, into the client user unit. The goal of this step is the same as for the previous embodiments, namely that the user unit and the server possess the same initial data.

    [0032] When a client requests a service, he sends along his identifier and a signature of the request, which authenticates his request. Preferably, the signature uses the stored tag value as a key (or the key is derived from this tag value).

    [0033] The server is able to verify the signature, since it knows the signature function and is able to derive the signature key that is used from the tuple corresponding to the client's identifier. Only when the signature is correct, a service will be granted.

    [0034] Corresponding to each valid request, the client and server will update the tag value tc in the same way as disclosed for the previous embodiments. Thus, a new tag value t'c will be computed from the old tag value tc on the one hand, and from information obtained from the content that is provided on the other hand. In the server database, the new tag will replace the old tag.

    [0035] From the foregoing, it should be noted that the operating phase of the embodiment illustrated by Figure 2b further requires the following steps, in addition to or instead of those relating to the first embodiment shown in Fig. 2a (same phase):
    • amending the preparation step of the client message by including the client identifier IDc into the client message.


    [0036] Optionally, the server can send a software update to a client, changing the used signature function and/or parameters, or may decide to replace the tag value tc by a new tag value t'c. This technique can be applied to any embodiment and could be used to disable hackers that have been able to fetch a tag value and/or reverse engineer the used signature function or the function to compute a new tag value (e.g., the cryptographic hash function). Since in this case, they could attempt to fight the de-synchronization, which occurs when clones are used, by deploying a central 'resynchronization' service or a proxy between the clones and the server.

    [0037] The use of a hash function is recommended for achieving the invention in accordance with the first embodiment shown in Figure 1. This follows from the fact that the tag values (namely the hash values) stored in the server database must be difficult to guess and need to remain different when they are updated. No collision should occur between two authentic client implementations. That is, if all authentic clients start with a different initial tag value, a collision in the hash values would imply that the cryptographic hash function is shown to be insecure (with respect to the collision-resistance property that is required for cryptographic hash functions).

    [0038] However, according to the embodiment shown in Figure 2b, this recommendation can be relaxed since each tag value is linked to a unique identifier, i.e. to the client identifier IDc. The only recommendation is that the signature key, which is either identical to the tag value tc or preferably derived from this tag value, remains unpredictable for malicious users having no knowledge of the tag value tc. Hence, sufficient entropy should remain from the input. The tag derivation function calculates the new tag value t'c on the basis of the (old) tag value tc and at least a part of the content of the message. By this way, a chain holding information obtained throughout the entire past history is carried out.

    [0039] A fallback mechanism is also suggested by the present invention in case of accidental desynchronization, for instance when a client needs to fall back to a previous backup after his system has crashed, or when his software has been cloned unintentionally. A fallback procedure can be implemented via a conventional authentication process, for instance by presenting correct credentials. At the end of this procedure, the tag value corresponding to the unique client identifier can be replaced on the client side (in the user unit) and server side (in the memory of the server). This will render each clone that uses the same identifier useless.

    [0040] To perform such a fallback mechanism, the operating phase of any embodiment will comprise a resynchronization step amending the updating step by the following steps:
    • replacing the tag value tc by a new tag value t'c equal to a new random value,
    • then sending said new tag value t'c to the user unit.


    [0041] Referring to Fig. 3, the latter suggests a third main embodiment for the present invention. According to this variant, the client user unit will append to each request a signature as is also done in the second embodiment of this invention (see Fig 2a and Fig. 2b). Once the server has verified the signature as being valid, the server can decide either to enforce an update of the tag (forcing the client to request the service again, thus allowing the server to prove that the tag value of the client user unit has been updated), or not to do so and directly send the content in response to the request. In contrast to the previous embodiments of this invention, the new tag value t'c is no longer updated on the basis of the content that is sent. The decision whether or not to enforce a tag update depends on business logic. Checking if the tag value tc has to be updated can be carried out by a test based on a temporal parameter or on a characteristic which may depend on the significance of the client request for instance. A tag update can be enforced for each content request, or only for valuable content only, or once a day, or depending on any other parameters imaginable. The decision whether or not to enforce an update of the tag value could be also applied to the other embodiments shown in Fig. 1, 2a and 2b by adding, to the operating phase, a step aiming to take such a decision. In this case, the client user unit must be informed, at each time a server message is sent as a response to a client request, whether or not the tag value has been updated by the server. For instance, a specific value could be added or appended to the server message in order to provide such information to the client user unit.

    [0042] Returning to the embodiment shown in Fig. 3, to enforce a tag update, the server will send to the client user unit a specific message (i.e. an update message) that includes an update value (denoted by the letter X in this figure) that will be used when deriving the new tag value t'c. For instance, this update value (X) can be a random value, a header information or metadata information. After this step, the server will expect the client user unit to start the request procedure again from the beginning, namely just after the initialization phase and after having introducing the new tag value t'c that derives on the one hand from the previous tag value tc and on the other hand from the update value (X) comprised in the update message. In this way, the server can easily verify if the tag has been updated or not. As long as no signature has been received that corresponds to the new tag value, the server will use the old tag and keep repeating the tag update enforcement step. Alternately, the requested service can be denied, for instance after a certain number of failed attempts. Thus, a test aiming to count (by means of a specific counter) the number of unsuccessful attempts, until a predefined threshold, can be performed to decide either to send a server message to the user unit without updating the tag value tc, or to deny the requested service. Once a signature that corresponds to the new tag has been received, the requested service can be delivered to the client.

    [0043] This third main embodiment, as shown in Fig. 3, further requires:
    1. a) replacing the steps in the positive outcome of the access condition test performed within the operating phase by a conditional step aiming to check if the tag value (tc) has to be updated:
      • in positive event: firstly to update the tag value tc, both on the server side and on the user unit side, by sending from the server to the user unit an update message including an update value X and by replacing the tag value tc by a new tag value t'c derived from the last tag value tc and from the update value X, then storing the new tag value t'c in the record of the database of the server and in the memory of the user unit,
      • in negative event: directly sending the server message to the user unit, as a response to the client request (in this latter case, the tag value tc is not updated),
    2. b) replacing the steps in the negative outcome of said access condition test by a test aiming, by means of an unsuccessful attempts counter used to count a number of successive negative outcomes relating to said access condition, to check if this number has reached a predetermined threshold:
      • in negative event: sending a server message to the user unit without updating the tag value (tc),
      • in positive event: denying the requested service.


    [0044] Regarding the positive event of the conditional step aiming to check if the tag value has to be updated (as mentioned above under the part denoted a) within the operating phase), it should be noted that the client user unit is forced to resend the client request while using the updated tag value. According to another appropriate variant, a message can be sent to the client user unit in order to require the latter for requesting the service again by using the updated tag value. This allows the server to ensure that the tag value has been updated on the client side.

    [0045] Although the embodiment illustrated by the Fig. 3 is shown as a variant of the embodiments shown in Fig. 2a and 2b, it should be noted that the above-mentioned steps performed in these positive and negative events can be also applied to the method according to the first embodiment, by replacing the steps performed under the positive and negative outcomes of the access condition test of the first embodiment.

    [0046] Whatever the embodiment, it should be noted that the tag value that is associated with each client captures the usage history of the client (and is initialized with a random value). Preferably, it is ought to be unique for each client, in particular if no identifier IDc is assigned to the client, and will change after each valid request. Hence, it can be used as a source of randomness to derive other keys (e.g. a session key for secure communications between client and server), or to enable run-time software diversity.

    [0047] The random values can be provided either by the server, e.g. during the first communication with the client, or by the software, e.g. during its first use and/or the first communication with the server.

    [0048] Preferably, the messages and/or values sent between the server and the client user unit in the method of the present invention are exchanged within a secure communication channel, independently from the embodiment used. Such a secure communication channel can be obtained by encryption of at least a part of exchanged contents/communications. For instance, at least a part of the content of a message can be encrypted. Furthermore, the exchanged communications can be signed. Besides, the tag value tc, t'c can be used to derive at least an encryption key for encrypting said exchanged contents.

    [0049] Advantageously, the present invention allows, firstly to produce identical software copies intended to be distributed to individual customers, and secondly, after the initialization phase, to provide an individualization of each software implementation which will lead its own life by having unique data at its disposal that can be used to enable spatial diversity.

    [0050] Depending on business logic, it may sometimes be desired to allow a limited amount of software clones. Users may be allowed to copy a client software implementation onto another device, and have a limited amount of clones running independently. To achieve this, the server will fork a new tuple (IDc1, tc1) from the original tuple (IDc, tc) as soon as an incorrect tag has been detected and policies allow a new clone. The presented identifier needs to be a correct identifier IDc. The new tuple can be associated with the original identity, e.g. by storing the cloned new client identifier IDc1 in a specific record of the original client identifier IDc (within the server database), to keep association between the cloned new tuple and the original client identifier IDc (or the original client user record). By providing counting means (e.g. means for incrementing by one unit) for counting the number of associations, i.e. the number of those specific records which are associated to an original client identifier, this allows to monitor how many clones this original identifier has and to know the identifier (IDc1, IDc2, ...) of these authorized clones. Comparison means may be provided for comparing the number of these specific records with a predefined threshold determining the maximum number of authorized clones for a certain original client identifier. If the result of this comparison is equal or upper than this threshold, the requested will be denied and no new authorized clone will be allowed to this original client identifier. On the contrary, if the threshold is not reached (or not exceeded), a new identifier IDc1 and a new tag tc1 will then be enforced on the cloned client user unit, using a dedicated command or any suitable operation to provide this new data to this new client user unit. From then on, the clone can be seen as a new authentic user unit.

    [0051] According to a slightly different way, in order to monitor how many clones a certain identity has, each client record (identified by it client identifier IDc), may include a count value. This value is incremented (or decremented) by one at each time a software clone is derived from this client. Thus, the served knows, at any time, how many software clones have been generated by a certain client.

    [0052] To avoid that a cloned client identifier generates further software clones at its turn, each record resulting from a software clone generation will be provide with a cloning tag used to identify which client identifier is a so-called "cloned identifier" and which client identifier is an initial identifier. The same function as that provided by such a cloning tag can be obtained by storing, in the new record corresponding to the so-called "cloned client identifier", a count value reaching immediately the above-mentioned threshold.

    [0053] Limiting amount of software clones is a variant that is applicable to the embodiments shown in Fig. 2b and Fig. 3. To carry out such software clones limitation, the steps below referring to the embodiment shown in Fig. 2b has to be taken into account with respect to the negative outcome of the access condition test of the method. This negative outcome will be replaced by (or will also include) the following conditional step together with the other following steps:
    • (or) checking if the client identifier IDc included to the client message is already stored in one of the records of the database: in negative event, deny the requested service, whereas in positive event:
    • incrementing by one unit a count value of a client counter associated to said client identifier IDc in its record, then check if this client counter reaches a predetermined threshold, in positive event: deny the requested service, whereas in negative event (the generation of a new clone is authorized):
    • storing the count value of the incremented client counter in said record,
    • assigning a new unique client identifier IDc to the client by storing, in a new record of the database, this new unique client identifier IDc together with a new tag value t'c (random value) and with a count value, stored as client counter, which reaches said predetermined threshold,
    • sending a server message to the user unit, as a response to the client request,
    • providing the new unique client identifier IDc and the new tag value t'c to the client (client user unit),
    • storing the new tag value t'c in the record of the database of the server and in the client user unit (i.e. in the memory of the client user unit).


    [0054] In order to provide the new client IDc and the new tag value to the new client user unit, this operation (step) can be achieved by any conventional communication means such as, but not limited to, a letter, a SMS, a phone call, an email, a web page, or any combination thereof. Alternately, this information can be transmitted to the client by including the new unique client identifier and the new tag value into the server message sent to the client user unit. This information can also be attached to the server message or sent separately.

    [0055] It should be noted that the method of the present invention does not prevent the clones from playing already purchased content: it only prevents that clones can request new services. This is an inherent issue with client media players that can be used offline, since only a server-side verification can be performed when the client software component connects to the online service.

    [0056] The client software implementation needs to be stateful.

    [0057] In terms of privacy issue, the method suggested in this invention discloses that the tag values are derived from the usage history and from the initial tag value. However, when cryptographic hash functions are used to derive new tag values, these values do not expose any usage history information (due to the pre-image resistance property of cryptographic hash functions).

    [0058] Besides, it is further possible to include additional information that is sent from the server to the client; e.g., a random offset that can be included in the update process, or an encrypted new hash value.


    Claims

    1. Method to detect a cloned software to be used on a client user unit communicating with a server for requesting a service by sending a request from the user unit to the server, the latter being connected to a database comprising client records, each of these records comprising at least a tag value (tc), said method comprising an initialization phase and an operating phase,

    a) the initialization phase comprising the steps of:

    - defining said tag value (tc) as being equal to an initial value,

    - opening a new record storing said tag value (tc) at the server,

    - introducing said tag value (tc) into the client user unit,

    b) the operating phase comprising the steps of:

    - preparing, on the user unit side, a client message for the server comprising said request and said tag value (tc), then

    - sending this client message, from the user unit to the server,

    - performing an access condition test, on the server side, by checking if the tag value (tc) of said client message is comprised in the database, in negative outcome: deny the requested service,

    in positive outcome:

    - sending a server message to the user unit, as a response to said request,

    - calculating on the server side and on the user unit side a new tag value (t'c) using a hash function configured to use the last tag value (tc) and at least a part of the client message or a part of the server message as input data of said hash function and to provide said new tag value (t'c) as output data of said hash function,

    - updating said tag value (tc), both on the server side and on the user unit side, by replacing it by the new tag value (t'c),

    - storing the new tag value (t'c) in the record of the database of the server and in the user unit.


     
    2. Method of claim 1, wherein said part of message is a timestamp.
     
    3. Method of any of preceding claims, wherein the client message further comprises a unique identifier (IDc) assigned to the client.
     
    4. Method of any of preceding claims, wherein

    a) the initialization phase further comprises the steps of:

    - defining a signature function and a signature key derivation function for encrypting a digest resulting from said signature function,

    - sharing the definition of said signature function and said signature key derivation function between the user unit and the server,

    b) the operating phase further comprises the steps of:

    - calculating an authentication code by applying said signature function to the request and using the signature key for encrypting the digest resulting from said signature function, then amending the preparation step of the client message by preparing a client message comprising said authentication code and said request,

    - amending the access condition by testing if the authentication code received within the client message is equal to an authentication code calculated by the server by applying the same signature function to the request comprised in the client message and using the same signature key for processing said digest; this signature key being preferably derived from the expected tag value that is stored in the server database.


     
    5. Method of claim 4, wherein

    a) the initialization phase further comprises the steps of:

    - assigning a unique identifier (IDc) to the client and storing this identifier (IDc) in said new record,

    - sharing said identifier (IDc) between the user unit and the server,

    b) the operating phase further comprises the step of:

    - amending the preparation step of the client message by including the client identifier (IDc) into the client message,


     
    6. Method of any of preceding claims, wherein the operating phase comprises a resynchronization step replacing the tag value (tc) by a new tag value (t'c) equal to a new random value, then sending said new tag value (t'c) to the user unit.
     
    7. Method of claim 4 or 5, wherein said signature key is identical to the tag value (tc) of the client.
     
    8. Method of claim 4 or 5, wherein said signature key is derived from the tag value (tc) of the client.
     
    9. Method of any of preceding claims, wherein said messages and/or values sent between the server and the user unit are exchanged within a secure communication channel.
     
    10. Method of claim 9, wherein said secure communication is obtained by encryption of at least a part of exchanged contents.
     
    11. Method of claims 10, wherein the tag value (tc, t'c) is used to derive at least an encryption key for encrypting said exchanged contents.
     
    12. Method of any of preceding claims, wherein the positive outcome in the access condition test performed within the operating phase is replaced by performing a conditional step aiming to check if the tag value (tc) has to be updated:

    - in positive event: firstly update the tag value (tc), both on the server side and on the user unit side, by sending from the server to the user unit an update message including an update value (X) and by replacing said tag value (tc) by a new tag value (t'c) derived from the last tag value (tc) and from said update value (X), and storing the new tag value (t'c) in the record of the database of the server and in the user unit;

    - in negative event: directly sending said server message to the user unit, as a response to said request;

    and wherein the negative outcome in said access condition test is replaced as follows:

    - performing a conditional step aiming, by means of an unsuccessful attempts counter used to count a number of successive negative outcomes relating to said access condition, to check if this number has reached a predetermined threshold:

    - in negative event: sending a server message to the user unit without updating the tag value (tc),

    - in positive event: denying the requested service.


     
    13. Method of any of claims 5 to 12, wherein the negative outcome in said access condition test further comprises the following steps:

    - checking if the client identifier (IDc) included to the client message is already stored in one of the records of the database: in negative event, deny the requested service, whereas in positive event:

    - incrementing by one unit the value of a client counter associated to said client identifier (IDc) in its record, then check if this client counter reaches a predetermined threshold, in positive event: deny the requested service, whereas in negative event:

    - storing the value of the incremented client counter in said record,

    - assigning a new unique client identifier (IDc) to the client by storing, in a new record of the database, this new unique client identifier (IDc) together with a new tag value (t'c) and with a value, stored as client counter, which reaches said predetermined threshold,

    - sending a server message to the user unit, as a response to said request,

    - providing said new unique client identifier (IDc) and said new tag value (t'c) to its client user unit,

    - storing the new tag value (t'c) in the record of the database of the server and in the client user unit.


     


    Ansprüche

    1. Verfahren zum Erkennen einer geklonten Software zur Verwendung auf einer Client-Benutzereinheit, die mit einem Server zum Anfordern eines Dienstes kommuniziert, indem eine Anforderung von der Benutzereinheit an den Server gesendet wird, wobei letzterer mit einer Datenbank verbunden ist, die Client-Datensätze enthält, wobei jeder dieser Datensätze mindestens einen Tag-Werts (tc) umfasst, wobei das Verfahren eine Initialisierungsphase und eine Betriebsphase umfasst,

    a) wobei die Initialisierungsphase die folgenden Schritte umfasst:

    - Definieren des Tag-Wertes (tc) als gleich einem Anfangswert,

    - Öffnen eines neuen Datensatzes, der den Tag-Wert (tc) auf dem Server speichert,

    - Einbringen des genannten Tag-Wertes (tc) in die Client-Benutzereinheit,

    b) wobei die Betriebsphase die folgenden Schritte umfasst:

    - Vorbereiten, auf der Seite der Benutzereinheit, einer Client-Nachricht für den Server, die die Anforderung und den Tag-Wert (tc) enthält, und daraufhin

    - Senden dieser Client-Nachricht von der Benutzereinheit an den Server,

    - Durchführen eines Zugangsbedingungstests auf der Server-Seite, indem geprüft wird, ob der Tag-Wert (tc) der besagten Client-Nachricht in der Datenbank enthalten ist, wobei Folgendes gilt: bei negativem Ergebnis: Verweigern des angeforderten Dienstes; bei positivem Ergebnis:

    - Senden einer Server-Nachricht an die Benutzereinheit als Reaktion auf diese Anforderung,

    - Berechnen auf der Serverseite und auf der Seite der Benutzereinheit eines neuen Tag-Wertes (t'c) unter Verwendung einer Hash-Funktion, die so konfiguriert ist, dass sie den letzten Tag-Wert (tc) und zumindest einen Teil der Client-Nachricht oder einen Teil der Server-Nachricht als Eingabedaten der Hash-Funktion verwendet und den neuen Tag-Wert (t'c) als Ausgabedaten der Hash-Funktion bereitstellt,

    - Aktualisieren des Tag-Wertes (tc), sowohl auf der Serverseite als auch auf der Seite der Benutzereinheit, indem er durch den neuen Tag-Wert (t'c) ersetzt wird,

    - Speichern des neuen Tag-Wertes (t'c) im Datensatz der Datenbank des Servers sowie in der Benutzereinheit.


     
    2. Verfahren nach Anspruch 1, wobei der Teil der Nachricht ein Zeitstempel ist.
     
    3. Verfahren nach einem der vorhergehenden Ansprüche, wobei die Client-Nachricht ferner eine eindeutige Kennzeichnung (IDc) umfasst, die dem Client zugeordnet ist.
     
    4. Verfahren nach einem der vorhergehenden Ansprüche, wobei

    a) die Initialisierungsphase weiterhin die folgenden Schritte umfasst:

    - Definieren einer Signaturfunktion und einer Signaturschlüssel-Ableitungsfunktion zum Verschlüsseln eines aus der Signaturfunktion resultierenden Hashwerts,

    - Teilen der Definition der Signaturfunktion und der Signaturschlüssel-Ableitungsfunktion zwischen der Benutzereinheit und dem Server,

    b) die Betriebsphase weiterhin die folgenden Schritte umfasst:

    - Berechnen eines Authentifizierungscodes durch Anwenden der Signaturfunktion auf die Anforderung und Verwenden des Signaturschlüssels zum Verschlüsseln des aus der Signaturfunktion resultierenden Hashwerts, sowie anschließendes Ändern des Vorbereitungsschritts der Client-Nachricht durch Vorbereiten einer Client-Nachricht, die den Authentifizierungscode und die Anforderung umfasst,

    - Ändern der Zugangsbedingung durch Prüfen, ob der in der Client-Nachricht empfangene Authentifizierungscode gleich einem vom Server berechneten Authentifizierungscode ist, indem die gleiche Signaturfunktion auf die in der Client-Nachricht enthaltene Anforderung angewendet wird und der gleiche Signaturschlüssel für die Verarbeitung des Hashwerts verwendet wird, wobei dieser Signaturschlüssel vorzugsweise von dem erwarteten Tag-Wert abgeleitet wird, der in der Server-Datenbank gespeichert ist.


     
    5. Verfahren nach Anspruch 4, wobei

    a) die Initialisierungsphase weiterhin die folgenden Schritte umfasst:

    - Zuweisen einer eindeutigen Kennzeichnung (IDc) an den Client und Speichern dieser Kennzeichnung (IDc) in dem neuen Datensatz,

    - Teilen der Kennzeichnung (IDc) zwischen der Benutzereinheit und dem Server,

    b) die Betriebsphase weiterhin den folgenden Schritt umfasst:

    - Ändern des Vorbereitungsschritts der Client-Nachricht durch Einbinden der Client-Kennzeichnung (IDc) in die Client-Nachricht,


     
    6. Verfahren nach einem der vorhergehenden Ansprüche, wobei die Betriebsphase den folgenden Resynchronisierungsschritt umfasst:
    Ersetzen des Tag-Wertes (tc) durch einen neuen Tag-Wert (t'c), der einem neuen Zufallswert entspricht, dann Senden des neuen Tag-Wertes (t'c) an die Benutzereinheit.
     
    7. Verfahren nach Anspruch 4 oder 5, wobei der Signaturschlüssel mit dem Tag-Wert (tc) des Clients identisch ist.
     
    8. Verfahren nach Anspruch 4 oder 5, wobei der Signaturschlüssel aus dem Tag-Wert (tc) des Clients abgeleitet ist.
     
    9. Verfahren nach einem der vorhergehenden Ansprüche, wobei die zwischen dem Server und der Benutzereinheit gesendeten Nachrichten und/oder Werte innerhalb eines sicheren Kommunikationskanals ausgetauscht werden.
     
    10. Verfahren nach Anspruch 9, wobei die sicheres Kommunikation durch Verschlüsselung mindestens eines Teils der ausgetauschten Inhalte erhalten wird.
     
    11. Verfahren nach Anspruch 10, wobei der Tag-Wert (tc, t'c) verwendet wird, um mindestens einen Verschlüsselungsschlüssel zur Verschlüsselung der ausgetauschten Inhalte abzuleiten.
     
    12. Verfahren nach einem der vorhergehenden Ansprüche, wobei das positive Ergebnis des in der Betriebsphase durchgeführten Zugangsbedingungstests durch einen bedingten Schritt ersetzt wird, bei dem geprüft wird, ob der Tag-Wert (tc) aktualisiert werden muss:

    - im positiven Fall: zunächst Aktualisieren des Tag-Wertes (tc), sowohl auf der Serverseite als auch auf der Seite der Benutzereinheit, durch Senden einer Aktualisierungsnachricht, die einen Aktualisierungswert (X) enthält, vom Server an die Benutzereinheit sowie durch Ersetzen des Tag-Wertes (tc) durch einen neuen Tag-Wert (t'c), der vom letzten Tag-Wert (tc) und vom Aktualisierungswert (X) abgeleitet ist, und Speichern des neuen Tag-Wertes (t'c) im Datensatz der Datenbank des Servers und in der Benutzereinheit;

    - im negativen Fall: direktes Senden der Server-Nachricht an die Benutzereinheit als Reaktion auf die Anforderung;

    und wobei das negative Ergebnis im Zugangsbedingungstest wie folgt ersetzt wird:

    - Durchführen eines bedingten Schrittes, wobei darauf abgezielt wird, mit Hilfe eines Zählers für erfolglose Versuche, der dazu verwendet wird, eine Anzahl aufeinanderfolgender negativer Ergebnisse in Bezug auf die Zugangsbedingung zu zählen, überprüft werden soll, ob diese Anzahl einen vorbestimmten Schwellenwert erreicht hat:

    - im negativen Fall: Senden einer Server-Nachricht an die Benutzereinheit, ohne den Tag-Wert (tc) zu aktualisieren,

    - im positiven Fall: Verweigern des angeforderten Dienstes.


     
    13. Verfahren nach einem der Ansprüche 5 bis 12, wobei das negative Ergebnis des Zugangsbedingungstests weiterhin die folgenden Schritte umfasst:

    - Überprüfen, ob die in der Client-Nachricht enthaltene Client-Kennzeichnung (IDc) bereits in einem der Datensätze der Datenbank gespeichert ist: im negativen Fall, Verweigern des angeforderten Dienstes; im positiven Fall:

    - Inkrementieren des Wertes eines Client-Zählers, welcher der Client-Kennzeichnung (IDc) in seinem Datensatz zugeordnet ist, sowie anschließendes Überprüfen, ob dieser Client-Zähler einen vorbestimmten Schwellenwert erreicht, im positiven Fall: Verweigern des angeforderten Dienstes, im negativen Fall:

    - Speichern des Wertes des inkrementierten Client-Zählers in diesem Datensatz,

    - Zuweisen einer neuen eindeutigen Client-Kennzeichnung (IDc) an den Client durch Speichern dieser neuen eindeutigen Client-Kennzeichnung (IDc) zusammen mit einem neuen Tag-Wert (t'c) und mit einem als Client-Zähler gespeicherten Wert, der den vorbestimmten Schwellenwert erreicht, in einem neuen Datensatz der Datenbank,

    - Senden einer Server-Nachricht an die Benutzereinheit als Reaktion auf diese Anforderung,

    - Bereitstellen der neuen eindeutigen Client-Kennzeichnung (IDc) und des neuen Tag-Wertes (t'c) für seine Client-Benutzereinheit,

    - Speichern des neuen Tag-Wertes (t'c) im Datensatz der Datenbank des Servers und in der Client-Benutzereinheit.


     


    Revendications

    1. Procédé de détection d'un logiciel cloné à utiliser sur une unité utilisateur client communiquant avec un serveur pour demander un service en envoyant une requête de l'unité utilisateur au serveur, ce dernier étant connecté à une base de données comprenant des enregistrements client, chacun de ces enregistrements comprenant au moins une valeur d'étiquette (tc), ledit procédé comprenant une phase d'initialisation et une phase de fonctionnement,

    a) la phase d'initialisation comprenant les étapes :

    - de définition de ladite valeur d'étiquette (tc) comme étant égale à une valeur initiale,

    - d'ouverture d'un nouvel enregistrement stockant ladite valeur d'étiquette (tc) sur le serveur,

    - d'introduction de ladite valeur d'étiquette (tc) dans l'unité utilisateur client,

    b) la phase de fonctionnement comprenant les étapes :

    - de préparation, côté unité utilisateur, d'un message client pour le serveur comprenant ladite requête et ladite valeur d'étiquette (tc), puis

    - d'envoi de ce message client, de l'unité utilisateur au serveur,

    - de réalisation d'un test de condition d'accès, côté serveur, en vérifiant si la valeur d'étiquette (tc) dudit message client est comprise dans la base de données, en résultat négatif : de refus du service demandé,

    en résultat positif :

    - d'envoi d'un message serveur à l'unité utilisateur, en réponse à ladite requête,

    - de calcul côté serveur et côté unité utilisateur
    d'une nouvelle valeur d'étiquette (t'c) utilisant une fonction de hachage configurée pour utiliser
    la dernière valeur d'étiquette (tc) et au moins une partie du message client ou une partie du message serveur en tant que données d'entrée de ladite fonction de hachage et pour fournir ladite nouvelle valeur d'étiquette (t'c) en tant que données de sortie de ladite fonction de hachage,

    - de mise à jour de ladite valeur d'étiquette (tc), à la fois côté serveur et côté unité utilisateur, en la remplaçant par la nouvelle valeur d'étiquette (t'c),

    - de stockage de la nouvelle valeur d'étiquette (t'c) dans l'enregistrement de la base de données du serveur et dans l'unité utilisateur.


     
    2. Procédé selon la revendication 1, dans lequel ladite partie du message est un horodatage.
     
    3. Procédé selon l'une quelconque des revendications précédentes, dans lequel le message client comprend en outre un identifiant unique (IDc) attribué au client.
     
    4. Procédé selon l'une quelconque des revendications précédentes, dans lequel

    a) la phase d'initialisation comprend en outre les étapes :

    - de définition d'une fonction de signature et d'une fonction de dérivation de clé de signature pour chiffrer un condensé résultant de ladite fonction de signature,

    - de partage de la définition de ladite fonction de signature et de ladite fonction de dérivation de clé de signature entre l'unité d'utilisateur et le serveur,

    b) la phase de fonctionnement comprend en outre les étapes :

    - de calcul d'un code d'authentification en appliquant ladite fonction de signature à la requête et en utilisant la clé de signature pour chiffrer le condensé résultant de ladite fonction de signature, puis de modification de l'étape de préparation du message client en préparant un message client comprenant ledit code d'authentification et ladite requête,

    - de modification de la condition d'accès en testant si le code d'authentification reçu dans le message client est égal à un code d'authentification calculé par le serveur en appliquant la même fonction de signature à la requête comprise dans le message client et en utilisant la même clé de signature pour traiter ledit condensé ; cette clé de signature étant de préférence dérivée de la valeur d'étiquette attendue qui est stockée dans la base de données du serveur.


     
    5. Procédé selon la revendication 4, dans lequel

    a) la phase d'initialisation comprend en outre les étapes :

    - d'attribution d'un identifiant unique (IDc) au client et de stockage de cet identifiant (IDc) dans ledit nouvel enregistrement,

    - de partage dudit identifiant (IDc) entre l'unité d'utilisateur et le serveur,

    b) la phase de fonctionnement comprend en outre l'étape :

    - de modification de l'étape de préparation du message client en incluant l'identifiant client (IDc) dans le message client,


     
    6. Procédé selon l'une quelconque des revendications précédentes, dans lequel la phase de fonctionnement comprend une étape de resynchronisation remplaçant la valeur d'étiquette (tc) par une nouvelle valeur d'étiquette (t'c) égale à une nouvelle valeur aléatoire, puis l'envoi de ladite nouvelle valeur d'étiquette (t'c) à l'unité utilisateur.
     
    7. Procédé selon la revendication 4 ou 5, dans lequel ladite clé de signature est identique à la valeur d'étiquette (tc) du client.
     
    8. Procédé selon la revendication 4 ou 5, dans lequel ladite clé de signature est dérivée de la valeur d'étiquette (tc) du client.
     
    9. Procédé selon l'une quelconque des revendications précédentes, dans lequel lesdits messages et/ou valeurs envoyé(e)s entre le serveur et l'unité utilisateur sont échangé(e)s dans un canal de communication sécurisé.
     
    10. Procédé selon la revendication 9, dans lequel ladite communication sécurisée est obtenue par chiffrage d'au moins une partie des contenus échangés.
     
    11. Procédé selon la revendication 10, dans lequel la valeur d'étiquette (tc, t'c) est utilisée pour dériver au moins une clé de chiffrage afin de chiffrer lesdits contenus échangés.
     
    12. Procédé selon l'une quelconque des revendications précédentes, dans lequel le résultat positif dans le test de condition d'accès réalisé dans la phase de fonctionnement est remplacé par l'exécution d'une étape conditionnelle visant à vérifier si la valeur d'étiquette (tc) doit être mise à jour :

    - en cas positif : la mise à jour d'abord de la valeur d'étiquette (tc), à la fois côté serveur et côté unité utilisateur, en envoyant du serveur à l'unité utilisateur un message de mise à jour comportant une valeur de mise à jour (X) et en remplaçant ladite valeur d'étiquette (tc) par une nouvelle valeur d'étiquette (t'c) dérivée de la dernière valeur d'étiquette (tc) et de ladite valeur de mise à jour (X), et le stockage de la nouvelle valeur d'étiquette (t'c) dans l'enregistrement de la base de données du serveur et dans l'unité utilisateur ;

    - en cas négatif : l'envoi direct dudit message serveur à l'unité utilisateur, en réponse à ladite requête ;

    et dans lequel le résultat négatif dans ledit test de condition d'accès est remplacé selon les étapes suivantes :

    - de réalisation d'une étape conditionnelle visant, au moyen d'un compteur de tentatives infructueuses utilisé pour compter un certain nombre de résultats négatifs successifs relatifs à ladite condition d'accès, à vérifier si ce nombre a atteint un seuil prédéterminé :

    - en cas négatif : d'envoi d'un message serveur à l'unité utilisateur sans mise à jour de la valeur d'étiquette (tc),

    - en cas positif : de refus du service demandé.


     
    13. Procédé selon l'une quelconque des revendications 5 à 12, dans lequel le résultat négatif dans ledit test de condition d'accès comprend en outre les étapes suivantes :

    - la vérification pour savoir si l'identifiant client (IDc) inclus dans le message client est déjà stocké dans l'un des enregistrements de la base de données : en cas négatif, le refus du service demandé, alors qu'en cas positif :

    - l"incrémentation d'une unité la valeur d'un compteur client associé audit identifiant client (IDc) dans son enregistrement, puis de vérifier si ce compteur client atteint un seuil prédéterminé, en cas positif : le refus du service demandé, alors qu'en cas négatif :

    - le stockage de la valeur du compteur client incrémenté dans ledit enregistrement,

    - l"attribution d'un nouvel identifiant client unique (IDc) au client en stockant, dans un nouvel enregistrement de la base de données, ce nouvel identifiant client unique (IDc) avec une nouvelle valeur d'étiquette (t'c) et une valeur, stockée comme compteur client, qui atteint ledit seuil prédéterminé,

    - l'envoi d'un message serveur à l'unité utilisateur, en réponse à ladite requête,

    - la fourniture dudit nouvel identifiant client unique (IDc) et de ladite nouvelle valeur d'étiquette (t'c) à son unité d'utilisateur client,

    - le stockage de la nouvelle valeur d'étiquette (t'c) dans l'enregistrement de la base de données du serveur et dans l'unité utilisateur client.


     




    Drawing











    Cited references

    REFERENCES CITED IN THE DESCRIPTION



    This list of references cited by the applicant is for the reader's convenience only. It does not form part of the European patent document. Even though great care has been taken in compiling the references, errors or omissions cannot be excluded and the EPO disclaims all liability in this regard.

    Patent documents cited in the description