WO2007004107A2

WO2007004107A2 - Method and apparatus for managing digital right licenses

Info

Publication number: WO2007004107A2
Application number: PCT/IB2006/052080
Authority: WO
Inventors: Geert J. Schrijen
Original assignee: Koninklijke Philips Electronics N.V.
Priority date: 2005-06-30
Filing date: 2006-06-26
Publication date: 2007-01-11
Also published as: WO2007004107A3

Abstract

It is showed a method and a device for verifying validity of a data item, said data item being related to a digital right license and located in a hash tree stored in a first memory means, said hash tree comprising a hierarchy of hash value nodes, including a validation node corresponding to a reference hash value. Said method comprises: computing at least one intermediate hash value located in said hierarchy between said data item and said validation node, computing a validation hash value for said validation hash node located in said hierarchy above said data item, retrieving said reference hash value corresponding to said validation hash node from a second memory means, and determining said data item to be valid if said validation hash value equals said reference hash value.

Description

Method and apparatus for managing digital right licenses

The present invention relates to data integrity in general, and more particularly to verifying integrity of distributed data related to digital right licenses.

Digital Rights Management (DRM) is a technology for managing access to digital content. It enables content providers to protect their copyrights and maintain control over distribution of and access to content. In a person-based DRM system, licenses or rights are coupled to users and a user is identified by a personal smart card. A right declares which person is authorized to use a certain piece of content and is often implemented as a digital certificate and may be stored on the user's smart card or in an entity somewhere in a network, reachable for the smart card. The smart card may in turn be inserted into a host device, where the host device is capable of conveying the digital content in a form interpretable by a user, such as text, images, video sequences and/or audio.

Rights are integrity protected with a digital signature from the rights issuer or content provider. Any modifications in the right, either unintentional errors or intentional errors made by an adversary, will lead to a mismatch between the modified right and the signature, allowing the modification to be detected. Devices may use the public key of the rights issuer to detect this and reject such a right. However, to create the signature, a private key of the rights issuer is required, and this private key is only accessible to the rights issuer. Consequently, the adversary cannot forge a signature to match a modification in the right, unless he gets access to the private key.

There are rights that require state information to be retained, e.g. rights with a restriction such as the user is allowed to play the content a certain number of times, or the user is allowed to play the content for a certain amount of time. These rights that contain state information must be treated slightly differently from normal rights, containing no state information. The right itself is still protected by the digital signature of the issuer. However, such a right only contains an initial state value. The owner of the right or a trusted device (e.g. smart card, etc.) must maintain a corresponding current state value of such a right. In the case of a person based DRM systems, a user's smart card is often a trusted device that must maintain state values corresponding to the rights of this user. For example, a right can contain the initial state "play 5 times". The smart card needs to securely maintain some counter value to be decreased each time the content is played. If the counter value reaches 0, the corresponding right may not be used anymore. The smart card of the user often has a trusted internal memory in which data can securely be stored in the sense that no adversary is able to read or modify the stored data. However, the internal memory of a smart card is limited in size. Therefore, the smart card may be provided with access to a large external memory, which may, for example, be located in the host device or somewhere in a network that the smart card has access to. However, the external memory cannot be assumed to be secure; an adversary may have the ability to read the data and could even manipulate the stored data values.

If the number of state values that is to be stored by the smart card is small, the smart card can securely store those state values in its internal memory, whereas the licenses may be stored in the external memory. Besides the state values, the smart card also needs to store the identifier of the license to which a state value is coupled.

If the amount of data for the state information and the identifiers becomes too extensive, the smart card may be unable to keep all this information in its secure internal memory anymore. The smart card therefore needs to use the larger, untrusted, external memory to store the state values of licenses. However, an adversary may try to manipulate the state information in the untrusted external memory. For example, an adversary may try to reset state values such that after playing a piece of content the rightful 5 times, he can play it another 5 times.

The state of the art within this field includes European patent application EP 0 932 109 A2. However, EP 0 932 109 A2 does not resolve a problem of how to manage information within a DRM framework related to a license in several separate memory means.

It is therefore an object of the present invention to overcome a problem of how to manage information within a DRM framework. This object is achieved by way of providing a validity verification method, a recovery method, a computing device, and a computer program product as defined in the appended claims.

A first aspect of the invention is a method for verifying validity of a data item, said data item being related to a digital right license and located in a hash tree stored in a first memory means, said hash tree comprising a hierarchy of hash value nodes, including a validation node corresponding to a reference hash value, said method comprising: computing at least one intermediate hash value located in said hierarchy between said data item and said validation node, computing a validation hash value for said validation hash node located in said hierarchy above said data item, retrieving said reference hash value corresponding to said validation hash node from a second memory means, and determining said data item to be valid if said validation hash value equals said reference hash value. Consequently, only one or more reference hash values have to be stored in the second memory, while the entire hash tree can safely be stored in a first memory. This significantly reduces the amount of data that needs to be stored in the second memory.

In a preferred embodiment, said step of computing a validation hash value involves computing a validation hash value for a validation hash node being a root node of said hash tree. In other words, the validation node is the root node. This minimizes the amount of data to be stored in the second memory, only requiring to store a single reference value corresponding to the root node.

In another preferred embodiment, said step of computing a validation hash value involves computing a validation hash value for a validation hash node being an intermediate node of said hash tree.

In yet another preferred embodiment, said step of retrieving a reference hash value involves retrieval from a secure memory means. As the reference hash values are key to validating data items, it is beneficial to store these in a secure memory. Secure memory entails a memory which is generally inaccessible to intruders.

In yet another preferred embodiment, said step of retrieving a reference hash value involves retrieval from a memory means in a smart card. As a smart card is often available in digital right situations, and the memory in the smart card is secure and readily available, the smart card memory is preferably used to store the reference hash value.

In yet another preferred embodiment, said data item is state information. State information is the type of information relating to digital right licenses that frequently changes and state information may add up to a significant amount of information. Hence it is beneficial to use the present invention to store state information.

In yet another preferred embodiment, said state information is related to how many times a piece of content related to said digital right license may be conveyed to a user. In yet another preferred embodiment, said state information is related to an amount of time during which a piece of content related to said digital right license may be conveyed to a user.

In yet another preferred embodiment, said hash tree is stored in a memory external to said smart card. As the internal secure memory of the smart card is limited in size, and the hash tree itself does not need to be stored in a secure memory, the hash tree may be stored in the external memory in order to conserve the amount of memory that is used in the smart card.

In yet another preferred embodiment, in said step of computing a validation hash value, said data item is determined to be invalid if any computed intermediate hash value is not equal to a corresponding hash value stored in said hash tree. In this way, if inconsistencies are found in the hash tree, the data item can safely be determined to be invalid in an earlier stage.

A second aspect of the invention is a method to recover at least one data item, said at least one data item being related to a digital right license and is to be stored in a hash tree, said at least one data item expected to have a value from a finite set of values, said method comprising: a) determining a trial value from said set of values, b) testing validity of said trial value with the method according to any one of the methods of the first aspect of the invention, c) if said trial value is determined to be valid, setting said data item to be recovered with a value of said trial value, and d) if said trial value is not determined to be valid, repeating said steps of determining a trial value and testing validity until a predetermined set of values have been tested. In this way, invalid data items can be recovered, if it has previously been found that the data items are invalid.

In a preferred embodiment, said step of c) is performed in a first device and said steps of a), b) and d) are performed in a second device in communication with said first device.

In another preferred embodiment, said steps a), c) and d) are performed in a first device and said step of b) is performed in a second device in communication with said first device. As the validity testing may require some processing power to be performed, it may be quicker to perform the validity testing in an external device having more processing capability.

In yet another preferred embodiment, said step of testing validity is performed in a server connected to a smart card comprising said secure memory through a data network. A server often has significant processing power compared to a smart card, significantly reducing the time it takes to recover an invalid data item.

In yet another preferred embodiment, last known state values are used to determine said finite set of values for each of said at least one data items. This is particularly useful for recovery of a plurality of data items, where the last known state may be used to recover all lost data items very quickly.

In yet another preferred embodiment, last known intermediate hash node values stored in said second device are used as reference values in said step b). This can significantly speed up the recovery process as the more intermediate hash values are known, less trial value combinations have to be tested on average. A third aspect of the invention is a computing device configured for managing data items related to digital right licenses, capable of performing a method according to any one of the methods above. A computing device may implement any one of the methods above, providing a device capable of securely managing digital right license data items stored in one memory that may be verified against reference data stored in another memory.

In a preferred embodiment, said computing device is a server. Particularly in the case of data item recovery, a server is exceptionally suitable, providing the processing capability to reduce the time required to recover a lost data item.

In another preferred embodiment, said computing device is a smart card. In the case of validation, a smart card is particularly suitable, as smart cards are often used in digital right license circumstances and the memory in the smart card can often be considered secure.

In yet another preferred embodiment, said computing device is a media player device.

In yet another preferred embodiment, said computing device is a smart card inserted into a media player device.

A fourth aspect of the invention is a computer program product, directly loadable into a memory of a digital computer, comprising software code portions for performing a method according to any one of the methods above. A computer program product may implement any one of the methods above, providing a program capable of securely managing digital right license data items stored in one memory that may be verified against reference data stored in another memory.

Other objectives, features and advantages of the present invention will appear from the following detailed disclosure, from the attached dependent claims as well as from the drawings. This and other aspects of the present invention will now be described in more detail, with reference to the appended drawings showing a currently preferred embodiment of the invention.

Figure 1 is a diagram illustrating an environment where an embodiment of the present invention may operate.

Figure 2 illustrates a hash tree in an embodiment of the present invention.

Figure 3 shows a flow chart of a method for verifying validity of a data item according to an embodiment of the present invention.

Figure 4 shows a flow chart of a method for recovering a value of a data item according to an embodiment of the present invention.

A smart card 102 contains an internal secure memory means 103. The internal secure memory means, also referred to as a second memory means, may, for example, be RAM memory, ROM memory, EEPROM memory, flash memory, magnetic discs, optical disks, any combination thereof, or any other memory capable of storing digital information in a manner that may be considered to be secure. The smart card 102 is inserted in a host device 101. The host device may for example be a portable or handheld computer, a mobile phone, an mp3 player, a media player, a desktop computer, a server, or any other device capable of conveying digital media in a form intelligible to a user. The host device 101 contains a host memory 105, also known as an external memory 105 from the view of the smart card 102, and a processor 108, such as a central processing unit (CPU) or microcontroller, capable of executing software instructions. The external memory, also referred to as a first memory means, may, for example, consist of RAM memory, ROM memory, EEPROM memory, flash memory, magnetic discs, optical disks, any combination thereof, or any other memory capable of storing digital information. The host device is further connected to some form of input device 104, such as a keypad, a keyboard, a mouse or a microphone, to accept input from a user, and one or more output devices such as a speaker 106 and a display 107. For communication purposes, the host device may also be connected to a digital network 109, being a LAN, WAN such as the Internet, or a telecommunications network such as GSM, CDMA-2000, EDGE or UMTS. The network 109 may also be a combination of several types of network technologies. Note that the connection to the network 109 may also be available to the smart card 102. Also connected to the network 109, is a server 110, comprising, a server memory 111. Below follows a description of preferred embodiments of methods according to the invention. These methods are typically implemented by software code being executed in said smart card 102 or said processor 108.

Figure 2 illustrates a hash tree 201 in an embodiment of the present invention. This example shows 16 data items, denoted Dl to D 16, stored in the hash tree 201, being a hierarchical structure of hash values and related data items. As a person skilled in the art will realize, the data item capacity of the hash tree 201, may easily be increased by increasing the number of levels in the hash tree 201. For a binary hash tree 201 having the order of 2, such as the tree exemplified here, capacity is doubled with each additional level, increasing capacity to 32, 64, or to any number 2ⁿ, where n is an integer. Moreover, regardless of the data item capacity of the hash tree 201, any number of data items less or equal to the capacity may be stored in the hash tree 201.

In this example, the data items Dl to D 16, corresponding leaf nodes 21 OA-P, each contain a license identifier and a state value. When the tree is populated, a hash value is computed for each data item using a cryptographic hash function, e.g. the known functions SHA-I, MD5, SHA-224, SHA-256, SHA-384 or SHA-512, based on the contents of the data item in question. These hash values are stored in the parent nodes of the corresponding data item, in this example nodes (1,1) to (1,16). By means of this hash on the data item containing the license identifier and corresponding state value, a state value is uniquely coupled to a specific license. For each higher layer in the tree, the hash value for each node is computed as the hash value of a concatenation of the children of the node in question. This procedure is repeated until the root 202 of the tree, here denoted (5,1), is reached. This example shows a binary tree, having the order of 2. Any order may be used, but it has turned out that binary trees, having the order of 2, or tertiary trees, having the order of 3, are the most advantageous for the purpose of integrity verification.

The complete hash tree 201, including data items and hash values, is in this example stored in an external, untrusted memory such as a memory 105 shown in figure 3. A smart card 102 stores in its secure memory 103 a reference hash value of the root, denoted (5,1) in this example.

Figure 3 shows a flow chart of a method for verifying validity of a data item according to an embodiment of the present invention. This method will now be described, with some references being made to the exemplifying hierarchy depicted in figure 2. The hash tree contains a validation node somewhere above said data node that has a corresponding reference value.

In a computing intermediate hash values step 310, all hash values above the data item in question are computed up to the level directly below the validation node. Only hash values for nodes in a line between the data item and the validation node need to be computed. If, for example, the data item in question is D3 and the validation node is (4,1), hash values for the nodes (1,3), (2,2) and (3,1) need to be computed. Each hash value is computed by performing a hash function of a concatenation of the values of its children. In a preferred embodiment, if a computed hash value does not agree with a stored hash value for the corresponding node, the data item can immediately be considered invalid.

In a compute a validation hash value step 311, the last hash value, for the validation node is computed, resulting in a validation hash value.

In a retrieve reference hash value step 312, a reference hash value corresponding to the validation hash value is retrieved from the secure memory 103.

In the conditional validation hash value equals reference hash value step 313, the computed validation hash value is compared to the reference hash value from the secure memory 103. The reference hash value is a prior validation hash value stored in a secure memory 103 at a time when the validation hash value is known to be valid, for example after updating hash values in the tree after a modification of a data item by the smart card 102. A comparison of the reference hash value and the validation hash value will therefore provide a reliable indication as to whether the data item in question is valid. If the reference hash value and the validation hash value are equal, the method proceeds to a set output to valid step 314. If the reference hash value and the validation hash value are not equal, the method proceeds to a set output to invalid step 315.

In the set output to valid step 314, an output value is set to be valid, indicating that the data item in question has been deemed to be valid.

In the set output to invalid step 315, an output value is set to be invalid, indicating that the data item in question has been deemed to be invalid. Using slightly different words, the integrity validation described above can be described as follows with reference to figure 2. In the nomenclature used here, hash(x) denotes the result of performing a hash function on x, and stored(x) denotes the stored hash value of node x. Assuming that the smart card 102 wants to check the integrity of the data item D3 and the reference value corresponds to the root, it sets a current node to be D3, hashes the data item D3 and compares stored(l,3) to hash(D3). If these are not equal, the data item D3 is immediately found to be invalid and the integrity check ends. If the comparison is ok, the smart card 102 then sets the current node to be the parent, i.e. (1,3), reads the stored hash data for the sibling node stored(l,4) and the new parent node stored(2,2), and compares stored(2,2) with hash(stored(l,3) + stored(l,4)), where '+' denotes concatenation. If these are not equal, the data item D3 is immediately found to be invalid and the integrity check ends. If the comparison is ok, the current node is set to be the parent node (3,1) and the procedure continues up the hierarchy until the parent node becomes the root of the hash tree 201. If the recomputed root hash value corresponds to the root reference hash value stored in the internal memory 103, the integrity of the read data item D3 is accordingly assured.

The hash tree 201 needs to always be current, whereby when the smart card 102 modifies a data item, the smart card 102 needs to update the affected hash values above in the hash tree 201 accordingly, and the smart card 102 will store the new root hash value in its secure memory 103. As seen in the two examples above, the node corresponding to the reference node may be the root or an intermediate node, lower down in the hierarchy. At the expense of using slightly more space in the secure memory, the over-all performance of the integrity checking procedure is improved if intermediate reference hash values are stored in the internal smart card memory 103. This is referred to as caching. Note that in our case we do not have cache memory per se, the reference hash values are simply stored in the internal memory 103 of the smart card 102. The integrity validation may then be stopped as soon as a validation hash value for a parent is verified to be equal to a corresponding hash value stored on the smart card 102. Caching thereby shortens the average time required to validate a data item. Furthermore, when certain data values need to be modified frequently, it can be advantageous to store the frequently changing data values and corresponding hash values in the internal memory 103 and update the tree value in external memory 105 as soon as values are evicted from the internal memory 103.

Figure 4 shows a flow chart of a method for recovering a value of a data item according to an embodiment of the present invention. This method will now be described, also referencing the exemplifying hierarchy depicted in figure 2.

As the data items may be stored in an external memory 105 which is not fully secure, data items may be lost, corrupted or even manipulated by an adversary. When this has happened to a data item that is to be used, the validation method described above will detect that the data item is invalid. The following method solves the problem of how to recover a correct value for the data item.

It is assumed that there is a finite set of expected values that the data item is expected to have. Of these values, a set of trial values is derived, which may be the entire set of expected values or a subset thereof.

In a determine initial trial value step 410, an initial value in the set of trial values is picked as a trial value.

In a test validity of trial value step 411, the validity of the trial value is tested, for example using the validation method described in conjunction with figure 3 above. In a conditional trial value valid step 412, it is checked if the trial value was determined to be valid. If this is the case, the method proceeds to a set recovered value to trial value step 416. In other words, if a trial value is found that passes the validity test, it may relatively safely be considered that the trial value is the correct value for the data item. This is due to the properties of the cryptographic hash function that is used for the hash-tree, where if a certain match is found for a data item, this is indeed the correct data item with very high probability. The chance of finding a different data item that also matches with the hash tree 201, but does not represent the correct data item, also known as a collision, is negligible, again due to the inherent properties of the cryptographic hash functions.

In a conditional more trial values step 413, it is checked if there are values in the trial value set that have not been tried yet. If this is the case, the method proceeds to a determine new trial value step 414, otherwise the method proceeds to a set recovered value to none step 415.

In the determine new trial value step 414, a new trial value, the validity of which has not yet been tested, is picked from the set of expected values. The method then returns to the test validity of trial value step 411 with the new value.

In the set recovered value to none step 415, it has previously been determined that no recovered value has been found, and therefore a value for the recovered value is set to be invalid. Alternatively, a success indicator may be set to false. The method ends after this step. In the set recovered value to valid trial value step 416, it has previously been determined that the latest trial value is valid. Consequently, the recovered value may be set to the valid trial value and may with a large degree of confidence be used as a recovered data item by further processing. Additionally, a success indicator may be set to true. The method ends after this step. If multiple data values in the hash tree 201 are lost, searching through all possible combinations may become a cumbersome task. For example, if we assume that there are C expected values for data items, and data items D5, D6 and hash values (1,5), (1,6) are all lost, there will be a possible C² combinations of values for D5 and D6 that may need to be tried in order to recover the correct data item values. Moreover, if the complete tree would be lost, recovery by the smart card 102 alone is even harder since C^N combinations need to be tried, where N is the number of data items that may be contained in the hash tree 201.

To utilize greater computing power, the recovery method may not only be performed in the smart card 102, but also in an external trusted device. Such a trusted device may be a server of the license issuer, having considerably more computing power compared to the smart card 102. Such a server may hence recover lost values quicker than the smart card 102, and may also have the capacity to recover multiple lost values even when this task may be considered too cumbersome to be performed by the smart card 102.

The method of using a server may work as follows. When an integrity check for a certain data item in the hash tree 201 fails in a smart card 102 validation, the smart card 102 will not allow the corresponding license to be used. The next time the smart card 102 contacts the license issuer, e.g. when buying a new content item or via a network-connected playing device, the smart card 102 may report integrity failures to the server of the license issuer. The license issuer may then try to recover the lost data item. Preferably, the smart card 102 first sets up a secure authenticated channel

(SAC) with the server of the license issuer for this communication. The smart card 102 may then send hash tree values (on the path from the lost data item to the root) to the license issuer and secure reference hash value for the root. The license issuer trusts that the root reference hash value is correct since it was securely stored in the trusted internal memory 103 of the smart card 102 and it trusts that the smart card 102 is compliant. The license issuer may then check whether the intermediate hash values (on the path from the lost data item to the root) are correct and may then attempt to find a matching data item according to the method described above. If a recovered data item is found, the license issuer reports this back to the smart card 102 and the smart card 102 may thereby repair the incorrect data item and hash values. This reporting may be immediate when the data item is found, or it may be kept in a queue, ready to be reported back to the smart card at a later time when a communication channel is available between the server and the smart card for other purposes.

It could furthermore be advantageous to let the license issuer reorder the licenses and build up a new tree, possibly in a more logical order, to assist the recovery possibilities. At recovery, the license issuer must test what data item was kept in what position in the tree, and therefore it could be beneficial if the license issuer has more information about the ordering and also has the power to affect it.

Additionally, the recovery may benefit from using the concept of caching, as described in conjunction with figure 3 above. If the smart card 102 has stored intermediate reference hash values in its trusted memory 103, it may report these reference hash values to the license issuer. Consequently, only the path from the lost data item up to a cached reference hash value needs to be checked in order to recover a data item value.

An alternative to letting the license issuer help the smart card 102 in recovering data item values, is to let another device in the network perform this task. For example a server located in the home of the user, or another server authorized by the license issuer, could perform this task if it has an overview of the licenses that are protected by the smart card 102. The home server may be reached via a network-connected device if validity checks for certain licenses fail and the user wants to wait for recovery. In case a large number of data in the hash tree 201 is damaged, recovery can be very challenging due to the large amount of possible data item combinations that need to be tested. Some additional solutions are presented here.

A first solution is to let the license issuer also store 'last-known' state values containing intermediate hash values and root value so that it is easier to recover data item information if large amounts of data in the memory 105 external to the smart card 102 are lost. The data item may then be reset to the last-known status by the license issuer. Note that the license issuer will most likely only agree to such a recovery if the last-known state was measured in a time in the past within a predetermined time from the present.

A second solution is to let the smart card 102 additionally store sequences of data item values, or any other helpful information about data items, in its secure internal memory 103. For example, the smart card 102 could store the sequence "3,2,5,1,5,5,4" to indicate the current data item values of the first seven licenses. Such a sequence can be very useful in the recovery process. For these licenses the correct data item values are already known and the hash tree 201 may easily be checked without having to test all possible data item value combinations for these licenses. The smart card 102 can send such a sequence to the license issuer or home server (via a SAC) when this may assist the recovery process.

In a third solution, it can be advantageous to cache more lower-level hash-tree values for licenses with a large number of possible data items. For example if k licenses can be played 300 times or for 300 minutes, the maximum counter value C will be C=300. Testing all combinations 300^k combinations for the k licenses for which the data item must be recovered may be a cumbersome task if k grows large. Therefore it helps to store extra, low-level, hash tree values for licenses when large possible counter values are utilized.

The person skilled in the art realizes that the present invention by no means is limited to the preferred embodiments described above. On the contrary, many modifications and variations are possible within the scope of the appended claims.

Claims

CLAIMS:

1. A method for verifying validity of a data item (21 OA-P), said data item being related to a digital right license and located in a hash tree (201) stored in a first memory means, said hash tree (201) comprising a hierarchy of hash value nodes, including a validation node corresponding to a reference hash value, said method comprising: computing at least one intermediate hash value located in said hierarchy between said data item and said validation node, computing a validation hash value for said validation hash node located in said hierarchy above said data item, retrieving said reference hash value corresponding to said validation hash node from a second memory means, and determining said data item to be valid if said validation hash value equals said reference hash value.

2. A method according to claim 1 , wherein said step of computing a validation hash value involves computing a validation hash value for a validation hash node being a root node (202) of said hash tree (201).

3. A method according to claim 1 , wherein said step of computing a validation hash value involves computing a validation hash value for a validation hash node being an intermediate node of said hash tree (201 ).

4. A method according to any of the preceding claims, wherein said step of retrieving a reference hash value, involves retrieval from a secure memory means.

5. A method according to any of the preceding claims, wherein said step of retrieving a reference hash value, involves retrieval from a memory means in a smart card.

6. A method according to any of the preceding claims, wherein said data item is state information.

7. A method according to claim 6, wherein said state information is related to how many times a piece of content related to said digital right license may be conveyed to a user.

8. A method according to claim 6, wherein said state information is related to an amount of time during which a piece of content related to said digital right license may be conveyed to a user.

9. A method according to any of the preceding claims, wherein said hash tree

(201) is stored in a memory (105) external to said smart card (102).

10. A method according to any of the preceding claims, wherein in said step of computing at least one intermediate hash value, said data item is determined to be invalid if any computed intermediate hash value is not equal to a corresponding hash value stored in said hash tree (201).

11. A method to recover at least one data item (21 OA-P), said at least one data item being related to a digital right license and is to be stored in a hash tree (201), said at least one data item (21 OA-P) expected to have a value from a finite set of values, said method comprising: determining a trial value from said set of values, testing validity of said trial value with the method according to any one of claims 1 to 10, if said trial value is determined to be valid, setting said data item to be recovered with a value of said trial value, and if said trial value is not determined to be valid, repeating said steps of determining a trial value and testing validity until a predetermined set of values have been tested.

12. A method according to claim 11 , wherein said step of c) is performed in a first device and said steps of a), b) and d) are performed in a second device in communication with said first device.

13. A method according to claim 11, wherein said steps of a), c) and d) are performed in a first device and said step of b) is performed in a second device in communication with said first device.

14. A method according to claim 12 or 13, wherein said step of testing validity is performed in a server (110) connected to a smart card (102) comprising said secure memory (103) through a data network (109).

15. A method according to any one of claims 11 to 14, wherein last known state values are used to determine said finite set of values for each of said at least one data items.

16. A method according to any one of claims 12 to 15, wherein last known intermediate hash node values stored in said second device are used as reference values in said step b).

17. A computing device configured for managing data items related to digital right licenses, capable of performing a method according to any one of claims 1 to 11.

18. A computing device according to claim 17, wherein said computing device is a server (110).

19. A computing device according to claim 17, wherein said computing device is a smart card (102).

20. A computing device according to claim 17, wherein said computing device is a media player device.

21. A computing device according to claim 17, wherein said computing device is a smart card inserted into a media player device.

22. A computer program product, directly loadable into a memory of a digital computer, comprising software code portions for performing a method according to any one of claims 1 to 16.