Patent Application
20100153724
The present invention relates to a system and a method for a key block based authentication comprising a plurality of drive units comprising a plurality of subsets, wherein a drive unit has a set of node keys and an identifier indicating the subsets said drive unit is part of and wherein an application unit has a key block.
Key block based authentication protocols are well known and are used between, e.g., an optical disc drive and a software application running on a host computer system. According to the Video Content Protection System VCPS (cf. http://www.licensing.philips.com/vcps) an authentication protocol has to be executed by an application with a drive in order to get access to a VCPS protected disc. As specified in the VCPS specification (Version 1.1 and lower), the application contains an application key block (AKB) and optionally a pre-computed copy of a root key KRroot that is encoded in the AKB. The application may also dynamically compute KRroot from the AKB using its device ID and its set of node keys KNh. Typically, each application contains an AKB with a personalized KRroot.
Unfortunately, dynamic computation of KRroot in the application renders all applications vulnerable to a key publishing hack even if only a single application is hacked. The reason for this vulnerability is that a hacker can use the node keys KNh extracted from the hacked application to determine the root key KRroot that is contained in the AKBs of all other applications, even if those applications contain personalized AKBs with unique root keys KRroot. Therefore, the hacker can publish a database that contains all root keys KRroot without revealing the identity of the hacked application (i.e. the set of node keys KNh used to construct the database). As a result, the hack remains open for the general public, while the hacked application cannot be identified and thus cannot be revoked.
A number of solutions that mitigate this key publishing hack are known. A first solution is to construct the AKB in such a manner that it does not authorize any other application than the one in which it is contained. Effectively, this means that the AKB “revokes” those other applications (in addition to one or more drives). Therefore, a hacker can not use the node keys KNh of one application to determine the KRroot encoded in the AKB of another application. A second solution is to equip an application with an AKB and the associated root key KRroot, but not with a set of node keys KNh required to decode the AKB.
For VCPS (version 1.2) a mixture of these solutions has been adopted, because VCPS applications require a set of node keys KNh to decode another key block (namely the disc key block DKB), and all KNh are chosen from the same key space. Here, the AKB “revokes” all applications, including the application that owns the AKB, so that its KNh cannot be used to decode KRroot from the AKB.
The above solutions effectively mitigate the key publishing hack that may result from a hacked application. The reason is that these solutions force the hacker to publish data that identify the hacked application (namely KRroot) in order to open up the hack to the general public. Consequently, it becomes possible to identify and to revoke the hacked application.
It has to be noted that such a revocation of the hacked application is effected through other means than the AKB. For example, VCPS revokes applications through the DKBs distributed on new blank media.
In a threat model which assumes that hardware devices will not be hacked, the above solutions may be sufficient. However, a more realistic threat model assumes that hardware devices will be hacked as well, albeit at a substantially lower rate. Whereas the key publishing hack resulting from hacked applications might be resolved by the above solutions, in this model there now also appears a vulnerability to a key publishing hack that results from hacked drives. In this case, the hacker uses the node keys KNd extracted from a drive to construct a database of the root keys KRroot of all applications. And as in the former case, the hacker does not reveal the identity of the revoked drive, so that an identification and a subsequent revocation is not possible.
It is therefore an object of the present invention to provide a system and a method for a key block based authentication comprising a plurality of drive units comprising a plurality of subsets, wherein a drive unit has a set of node keys and an identifier indicating the subsets said drive unit is part of and wherein an application unit has a key block, which allow to identify a hacked drive unit in order to revoke the hacked drive unit from said key block based authentication, wherein said system and said method are to a large extent compatible with existing systems and methods for a key block based authentication.
The object is achieved according to the present invention by a system for a key block based authentication comprising:
a plurality of drive units comprising a plurality of subsets, wherein a drive unit has a set of node keys and an identifier indicating the subsets said drive unit is part of,
an application unit having a key block comprising a plurality of pairs of authorization and authentication keys, wherein each pair of keys is associated with one of said subsets,
a communication means for submitting said identifier from said drive unit to said application unit and for submitting an authorization key from said application unit to said drive unit, and
an authentication means for authenticating said drive unit and said application means by means of a pair of keys,
wherein said application unit comprises a selecting means for selecting a pair of keys from said key block corresponding to said identifier,
wherein said drive unit comprises a first decoding means for deriving said authentication key of said pair of keys from said authorization key of said pair of keys by means of said set of node keys.
The invention also relates to a drive unit as claimed in claim 9 comprising
a set of node keys,
an identifier indicating the subsets said drive unit is part of,
a communication means for submitting said identifier to said application unit and for receiving an authorization key from said application unit,
a decoding means for deriving an authentication key from said authorization key by means of said set of node keys, and
an authentication means for authenticating said application unit by means of said authentication key
and to an application unit as claimed in claim 10 comprising
a key block comprising a plurality of pairs of authorization and authentication keys, wherein each pair of keys is associated with one of said subsets of said drive units,
a communication means for receiving an identifier from a drive unit and for submitting an authorization key to said drive unit,
a selecting means for selecting a pair of keys from said key block corresponding to said identifier,
an authentication means for authenticating said drive unit by means of an authentication key.
A method for a key block based authentication corresponding to the system is defined in claim 11. This method can be implemented on a computer by a computer program comprising computer program code means for causing a computer to perform the steps of said method when said computer program is run on a computer.
The invention is based on the insight that a link between the authentication key and the drive unit for which this authentication key is valid allows to identify the hacked drive unit from which a published authentication key is taken. Since it is not necessary for the authentication as such that different authentication procedures use the same authentication key it is possible to provide different authentication keys for different authentication procedures, i.e. for different drive units authenticating with the same or different application units. It is thus proposed that each authorization key KAx in the AKB encodes a different, preferably unique authentication key KRauth. As a consequence, an application unit must store not one, but multiple authentication keys KRauth when they cannot be decoded from the AKB by the application unit.
If a hacker is able to retrieve the set of node key KNd from a particular drive unit, he or she can only decode one of the authentication keys KRauth of each application unit's AKB. Therefore, the effectiveness of the key publishing hack is reduced, because only a small subset of the public at large will be able to profit, i.e. namely those who have a drive that is located in the same subtree of the AKB as the hacked drive.
The hacker is forced to reveal at least part of the identity of the hacked drive: because each KRauth is unique, its position in the AKB is known, and therefore part of the hacked drive's identity which determines its path through the AKB. Therefore, all future AKBs can revoke the node keys that are on the known path. Consequently, it is possible to revoke the attacked drive in a finite number of steps: The hacker is forced to reveal at least one more bit of the drive's identity in each iteration.
It is possible to detect whether an application unit or a drive unit has been hacked: If an application unit has been hacked, it is likely that all or most of its embedded authentication keys KRauth will be published, supposedly more or less simultaneously. In this case, the application unit must be replaced by a new version, containing a new AKB. If a drive has been hacked, only one KRauth from each application unit will be published. In this case all application units must retrieve a new AKB and a new set of authentication keys KRauth, wherein the hacked drive unit or the subtree it is arranged in is revoked.
Different from the application key block known from the prior art wherein from each authorization key comprised in said application key block the same root key KRroot is to be derived an application key block according to the present invention comprises a plurality of authorization keys KAx wherein also a plurality of authentication keys KRauth is to be derived from this plurality of authorization keys KAx associated to different subsets of drive units in said application key block. Thus, different authentication keys KRauth will be used for authenticating drive units from different subset contrary to the single root key KRroot used for authentication of all drive units according to the prior art.
According to one embodiment of the system for authentication according to the present invention, said drive unit is a user device, in particular a drive, preferably an optical disc drive, and said application unit is a software application on a host computer. Key block based authentication is particularly important for a case in which data to be protected from unauthorized access is provided on a optical data carrier and is to be loaded into a computer or some other host.
In a preferred embodiment of said system for authentication according to the present invention, said identifier is a substantially unique identifier. By providing a substantially unique identifier for each drive unit it can be ensured that exactly the hacked drive unit will be identified and revoked wherein no “innocent” drive unit will be affected by the revocation.
In another embodiment of the present invention, said key block comprises a representation of a tree structure, in particular a binary tree structure, corresponding to said plurality of subsets of said drive units. By arranging the representation of the subsets in a tree structure there is a easy way to find the relevant subset in short time since the search of such a tree structure is easy and fast.
In an advantageous embodiment the system for authentication further comprises a key block generator for generating a new key block for said application unit using a previous key block, said key block generator comprising a revoking means for revoking at least one authentication key from said previous key block to form said new key block, an arranging means for arranging a plurality of subsets of drive units associated with said revoked authentication keys in substantially new subsets of drive units in said new key block and a key generation means for generating new authorization keys encoding new authentication keys for said new subsets. The key block generator is able to rearrange the entries for the plurality of non-revoked drive units in such a way that exactly this plurality is covered by the subsets for which valid authorization keys are included into the key block.
In an preferred embodiment the system for authentication according to the present invention further comprises a plurality of application units, wherein different application units each have a different key block. If there are different key blocks in the system a hacker is forced to reveal more details of the identity of the hacked drive unit in order to open up the hack to the general public.
Accordingly, it is further preferred that said key block generator is adapted for generating a different new key block for each application unit or group of application units from said previous key block.
In an advantageous embodiment of the system for authentication according to the present invention said key block generator is adapted for generating new key blocks from said previous key block, wherein different new key blocks are arranged with substantially different new subsets of drive units. With substantially different new subsets it will be achieved that a drive unit which will be hacked in the future is part of different subsets. Therefore either the number of drive units for which the hacked authorization key may be used is limited to those of one particular subset facing one particular key block or the hacker has to reveal much information as to allow the hack to be exploited by any drive unit facing any key block. Either the hack is virtually useless or the revealed information allows a rather fast tracking of said hacked drive unit.
It has to be noted that the number of iterations necessary for tracking down a hacked drive unit may be reduced by deliberately extending the AKB, i.e. “revoking” additional node keys in the upper part of the tree, so that the authorization keys KAx are located as near to the bottom of the tree as possible. This leads to a (possibly much) larger AKB, but the increased storage requirements do not cause a problem for application units. For example, the AKB size is only about 16 kB if all authorization keys KAx are 10 levels below the root of the tree. By zooming in on the attacked or hacked drive unit, i.e. by adding the additional “revocations” in the subtree that is known to contain the hacked drive unit, complete revocation may be achieved after only a few iterations. If there are multiple drives that must be traced and revoked in this fashion, the number of required iterations may increase, because the zooming-in must be performed for all of these drives at the same time. However, some efficiency may be retained when the AKBs of different popular applications are used to zoom in on different attacked drives. Even greater efficiency may be obtained if individual installations of applications contain a unique AKB, in which the additional “revocations” are e.g. randomly chosen: In this case, the hacker must reveal the lowest KAx present in the collection of AKBs order to open up the hack to the general public, thus giving up a substantial part of the hacked drive's identity.
In the following the present invention will be described in further detail with respect to the accompanying figures, in which:
In this generic EKB, all authorization keys KAx encode the same root key KRroot. In the case of a VCPS DKB that is essential, because this root key is used in the key hierarchy for computing the content key, which obviously is the same for all players and recorders. However, in the case of an AKB this is not necessary. The reason is that there is no relation between different executions of the authentication protocol, and therefore the shared secret (namely KRroot) may be different.
The EKB contains a representation of a binary tree structure. The white circles and the gray circles represent the nodes of the tree. The black circle represents the root node of the tree. The node directly above a node is called its parent. A node directly below a node is called its child. The two nodes that have the same parent are called siblings. A node that does not have any children is called a leaf. All nodes that are on the (single) path from a node up to the root are called its ancestors. All nodes that are on the (multiple) paths from a node down to the leaf nodes are called its descendants. The tree that is formed by a node and all of its descendants is called a sub-tree. In
The nodes of the EKB tree contain the following information: a three-bit tag, and optionally an authorization key KA. The tags describe the tree structure. Each node carries a tag. In
If, for example, drive unit ID4 would be hacked and its authentication key K3′ would be published it would be clear that either drive unit ID4 or ID5 has been hacked. It would then be possible to change the application key block accordingly. The sub-tree of drive units ID4 and ID5 would be divided into two sub-trees wherein each new sub-tree would be provided with a new authorization key encoding a new authentication key.
If, for example, drive unit ID3 would be hacked and its authentication key K2′ would be published it would be clear that drive unit ID3 has been hacked and thus the hacked and identified drive unit ID3 could be revoked.
As shown by the two sub-trees of drive units ID4 and ID5 and ID6 and ID7 it is possible to reduce the necessary steps of iteration to track down a hacked drive unit. By deliberately dividing a sub-tree into smaller sub-trees the number of drive units which are in the same sub-tree and share the same authentication key is thus reduced. Besides the reduction of iteration steps, i.e. the alterations of application key blocks before a hacked drive unit is identified, there is a further advantage as there is only a reduced number of drive units, i.e. those in the same sub-tree as the hacked drive unit, with which the published authentication key could be used.
In step 17 said application unit 1 generates and transmits a message 19 including said authorization key KAx, an indicator j indicating the position of said authorization key KAx in said AKB and a random host number RA. Said drive unit 3 obtains (step 21) said authentication key KRauthx by means of said authorization key KAx and a node key KNE of said set of node keys KNd associated to said indicator j. In step 23 said drive unit 3 generates a random drive number RD and a drive key contribution QD and sends a message 25 including said host number RA, said drive number RD and said key contribution QD being encrypted using said authentication key KRauthx to said application unit 1. Said application unit 1 decrypts said message 25 and checks for the presence of the correct host number RA in said message 25 (step 27). If said host number RA is not identical to the value of step 17 the authentication protocol is aborted.
In step 29 a host key contribution QA is generated and a message 31 is sent to said drive including said drive number RD, said host number RA and said host key contribution QA being encrypted using said authentication key KRauthx. In step 33 said drive 3 decrypts said message 31 and checks for the presence of the correct drive number RD in said message 31. If said drive number RD is not identical to the value of step 23 the authentication protocol is aborted.
In steps 35 and 37 a bus key KB is generated from said drive key contribution QD and said host key contribution QA. Said bus key KB is now a secret shared by both, the application unit 1 and drive unit 3, wherein said authentication between said application unit 1 and said drive unit 3 was successful. In case the authentication protocol is aborted it has to be started again at step 7 or step 11, respectively.
Said identifier IDd is transmitted from said drive unit 3 to said application unit 1 by means of said communication means 72. Said selecting means 62 is used to select a pair of an authorizations key KAx and an authentication key KRauthx from said AKB. Said authorization key KAx is transmitted from said application unit 1 to said drive unit 3 where said decoding means 52 is used to derive said authentication key KRauthx from said authorization key KAx by means of said set of node keys KNd. An authentication is performed using said authentication means 74 as described above with regard to
According to the present invention a new key block based authentication method and a corresponding new key block based authentication system are proposed. By providing different authentication keys for different drive units the effect of a hacked drive unit is reduced, i.e. the usability of an authentication key obtained by hacking is reduced, and an identification of such an hacked drive unit is made possible in order to facilitate a revoking of a hacked drive unit.
The present invention is to a large extent compatible with the known VCPS authentication protocol. Neither hardware nor command set modifications are required for implementing the present invention into said protocol. It is fully backwards compatible with the current version of the specification. What must be changed, however, are the key generation and key issuance tools, and the interface of the key issuance center to the software manufacturers. Of course, software manufacturers must adapt as well.
It has to be noted that the present invention is not limited to the described VCPS since it may be used with other optical formats, such as Blu-ray Disc, and is also applicable to other key block formats and authentication protocols based thereon, such as those used by CPRM and AACS.
| Number | Date | Country | Kind |
|---|---|---|---|
| 05105834.5 | Jun 2005 | EP | regional |
| Filing Document | Filing Date | Country | Kind | 371c Date |
|---|---|---|---|---|
| PCT/IB06/52082 | 6/26/2006 | WO | 00 | 12/20/2007 |
