Patent Application
20100161972
The invention relates to a device and a method for key block based authentication.
In recent years, Broadcast Encryption (cf. A. Fiat and M. Naor, Broadcast Encryption, Advances in Cryptology—CRYPTO '93, Lecture Notes in Computer Science 773, Springer, 1994, pp. 480-491, D. M. Wanner, E. J. Harder and R. C. Agee, Key Management for Multicast: Issues and Architectures, Internet RFC 2627, June, 1999 and C. K. Wong, M. Gouda and S. Lam, Secure Group Communications Using Key Graphs, SIGCOMM 1998. Wong, et al) has proven to be a very popular way to solve the key distribution and revocation problems in the field of copy protection. E.g. systems such as Copy Protection for Recordable Media and Copy Protection for Pre-recorded Media (CPRM, CPPM, cf. http://www.4centity.org), Content Protection System for Blu-ray Disc Rewritable (BD-RE CPS, Matsushita/Philips/Sony), and Video Content Protection System (cf. http://www.licensing.philips.com/vcps, HP/Philips) use key blocks to ensure that only compliant playback and recording devices are able to access content.
The general idea behind broadcast encryption is that the total set of all devices is covered by a plethora of cleverly chosen subsets. To every one of those subsets a group-key is assigned. The group-key is embedded in all devices which belong to the corresponding subset. A particular device is a member of multiple subsets and therefore has multiple group-keys on board. This set of group-keys on board of a device is also referred to as its Device Keys. To restrict the access to a piece of content to the set of compliant devices, the content is encrypted with a root key Kroot, and Kroot in turn is encrypted with several different group-keys. The group-keys are chosen in such a way that the corresponding subsets cover exactly the set of compliant devices, but no more than that. The structure containing Kroot encrypted with the group-keys is called the Key Block.
When one or more formerly compliant devices are found to be hacked, new content is encrypted with a new root key K′root and this key is transferred to the remaining compliant devices using a new key block. The group-keys used for this key block now correspond to a new collection of subsets which covers only the new set of compliant devices. By choosing a new collection of subsets, by creating a new key block, in effect a set of devices may be revoked.
The advantage of broadcast encryption over alternatives is that it combines low transmission requirements (the size of the key block is roughly proportional to the number of non-compliant/revoked devices, usually less than a few thousand) with its low complexity: only symmetric key cryptography is required to decode a key block. Moreover, revocation and key-distribution are conveniently rolled into one.
A relatively new application of broadcast encryption is its use in authentication. As in the example above, devices still have an embedded set of device keys, wherein every device has a different set of device keys, which compliant devices can be used to decode a key block, but non-compliant devices cannot. By using the root key of the key block as a shared secret in a challenge response protocol, one device can verify that another device, e.g. a recorder requesting content from a set top box, is (still) compliant. Examples of this use of broadcast encryption can be found in systems such as xCP (for devices to join a home network, cf. IBM response to DVB-CPT Call for Proposals for Content Protection & Copy Management, DVB-CPT-716, October 2001 http://www.almaden.ibm.com/software/ds/ContentAssurance/papers/xCP_DVB.pdf), and VCPS.
Although the advantages of broadcast encryption in content distribution carry over to authentication, unfortunately there is also a major disadvantage: the key publishing attack. The problem is that this hack allows a single sophisticated hacker to supply many casual hackers with a software tool such that these unauthorized casual hackers can authenticate with a compliant device, in such a way that the keys used in this tool cannot be revoked. The method of this hack is as follows.
Since no implementation of a key block decoding is perfect, there always may be a device in the entire population where the device keys can be retrieved by a relatively sophisticated hacker. In particular software applications are vulnerable in this respect.
The sophisticated hacker uses the device keys to retrieve the root key from any key block on which he can get his/her hands. It has to be noted that key blocks themselves are not confidential and are freely distributed. The root keys retrieved from the key blocks are collected in a database on a server on the internet together with a reference, e.g. a hash, to the key block from which they originated.
A casual hacker wishing to authenticate to a compliant device, e.g. to obtain content, or to join a home network, downloads a tool from the interne which will impersonate a compliant device. When the challenge-response protocol with the compliant device is started, the tool sends a reference, e.g. a hash, of the key block used in the protocol to the server mentioned above; the server returns the corresponding root key which is subsequently used by the tool in the protocol.
Because the device keys used by the sophisticated hacker are never published and only root keys are published, it is very difficult to revoke these device keys in new key blocks.
One way to deal with this attack is to use public key encryption instead of broadcast encryption. In authentication based on public key encryption, every device has its own unique identity fixed in a certificate signed by a certificate authority. Because of the asymmetric nature of public key encryption, there is no need for a shared secret like a root key, and although a sophisticated hacker can still construct a tool for casual hackers, this tool has to be based on the private key of a particular implementation and hence the corresponding public key can be revoked. Unfortunately, public key cryptographic protocols are very expensive in terms of MIPS (for software implementations) and kgates (for hardware implementations), which makes them unpopular for CE products.
Although the key publishing attack suggests that broadcast encryption cannot be used securely for authentication, closer inspection shows that it is still a useful technique as long as the device keys are never present in “weak” implementations. For example, in a situation where hardware is rarely attacked, but software is vulnerable, software should not contain device keys, but hardware could. A system that follows this design criterion is the authentication protocol between a DVD+RW drive and PC host application according to the VCPS, wherein device keys are embedded in all DVD+RW drives and every software application contains it own unique key block and root key, but no device keys.
Software applications can still be hacked but a (sophisticated) hacker will learn at most a root key. Although this root key might still be used in a key publishing attack, this root key is no longer “anonymous”: since every application has its own unique key block and root key, it is, in principle, possible to revoke the corresponding application.
For a successful application revocation hardware devices should have a mechanism to learn which root keys (i.e. which applications) they can no longer accept because the corresponding application has been found to be compromised. In general, there are two ways to establish this: either by black-listing, i.e. revocation lists are distributed regularly which tell hardware devices which applications are no longer compliant (and implicitly, which are still compliant), or by white-listing, i.e. all applications and their key blocks/root keys are revoked regularly and have to prove themselves anew by using new key blocks.
In either case there is an issue how to enforce the “regular”-phrase above: in the black-listing case the hardware device needs timely revocation information, and for white-listing the device needs a trigger to revoke all current key blocks. Known, e.g. from VCPS, are methods where revocation information (not necessarily key block revocation information) or triggers are delivered through third communications partners, e.g. if the hardware device is an optical drive, application revocation information or a trigger might be included on new optical discs; or if the hardware device is a broadcast tuner (e.g. for ATSC), application revocation information or a trigger might be included in the broadcast stream; if the hardware device is nomadic, i.e. it is connected to many other devices, of which a non-zero fraction is likely not to be revoked, it may receive revocation information or a trigger from such other devices.
However, there are also situations where hardware devices are relatively isolated or can only access the outside world through (software) applications which they cannot trust (establishing this trust is exactly the purpose of the (key block based) authentication). The intervening software application may intentionally block revocation information or triggers from reaching the hardware device, or may e.g. replace new revocation information with old revocation information.
It is therefore an object of the present invention to provide a device and a method for a key block based authentication wherein devices are revoked through the key block and application units are revoked through a separate revocation (black/white-)list, which overcome the above mentioned problems and allow for an effective key block and/or application revocation wherein it is ensured that valid and new revocation information reaches said device and is used for authentication.
The object is achieved according to the present invention by a device for a key block based authentication comprising:
The object is also achieved by a corresponding method as claimed in claim 12. The present invention is further related to 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 device may by itself enforce a regular update of its revocation information. Instead of waiting for an external event or trigger a device may generate its own trigger in order to obtain new revocation information. In particular, in the absence of reliable delivery channels for revocation information or triggers, the device refuses to engage in the authentication protocol after a “time-out” until the other device (the one wishing to authenticate) supplies “fresh” revocation information or renews its key block.
It has to be noted that the term “device” is not limited to a hardware device. The present invention may also be implemented into a software application, in particular a software application with sufficient hardware support (e.g. a TPM module or running on a special secure chipset like Intel LaGrande or ARM Trustzone) to be securely able to carry device keys as a hardware device. Conversely, the term “application unit” is not limited to a software implementation.
In an embodiment of the present invention said revocation information includes a revocation version number and said internal trigger means is adapted for renewing said revocation information by increasing said revocation version number. Having said revocation version number the device is able to perform an authentication with sufficiently new authentication data. By increasing said revocation version number during said renewing it is ensured that no old authentication data is used for authentication.
In an advantageous embodiment of the present invention the device further comprises communication means for requesting and receiving a black-list of key blocks and/or application units which are revoked and/or a white-list of key blocks and/or application units which are not revoked from said application unit, said black-list and white-list having a version number equal to or exceeding said revocation version number. Further, said authentication means is adapted for using said black-list and/or said white-list for said authentication. Said device requests as new data for authentication a black-list and/or a white-list and is provided with said black-list and/or white-list by said application unit. By checking the entries in said black-list and/or said white-list said device is able to distinguish between application units which are revoked and those which are not revoked. In order to avoid the use of an out-dated black-list or white-list the version number of said list has to be equal to or higher than the revocation version number. Since it is not necessary according to this embodiment to store said black-list or said white-list in said device it is possible to avoid further efforts for securely storing said list(s).
In a further embodiment of the present invention said authentication means is adapted for authenticating only an application unit having a key block with key block version number equal to or exceeding said revocation version number. The revocation version number gives a cut-off between key blocks which are new enough, i.e. which have a sufficiently high version number, and key blocks which are too old, i.e. which have a version number out-dated by said revocation version number.
In yet another embodiment of the present invention said revocation information includes a black-list of key blocks and/or of application units which are revoked and said device comprises communication means for requesting and receiving data for said renewing of said revocation information from said application unit, and replacing means for replacing said black-list by a new black-list received by said communication means. The device stores the black-list on its own and may check upon any occurrence of an authentication event whether the application unit to be authenticated is revoked according to the stored black-list even if said application unit is not able to provide fresh revocation information.
In a further embodiment of the present invention said revocation information includes a white-list of key blocks and/or of application units which are not revoked and said device comprises communication means for requesting and receiving data for said renewing of said revocation information from said application unit, wherein said device further comprises compilation means for deleting said white-list and compiling a new white-list upon provision of authentication certificates for key blocks and/or application units; and/or replacing means for replacing said white-list by a new white-list received by said communication means. By storing the white-list on its own the device is provided with a list of non-revoked application units and/or key blocks. Thus, said device may also authenticate application units which are not in possession of a new white-list.
In an advantageous embodiment of the present invention said revocation information includes further a revocation sequence number in addition to said black-list and/or said white-list, wherein said internal trigger is adapted for increasing said revocation sequence number upon said renewing, and wherein said device is adapted for accepting only data for said renewing having a version number equal to or exceeding said revocation sequence number. In order to ensure that even if the device receives new revocation information (in case of key block black-listing) or is confronted with a new key block (in case of key block white-listing) after a triggering event, it can be certain that this is fresh revocation information or a fresh key block, the device also keeps a revocation sequence number. When the process of renewing is triggered, said revocation sequence number is increased. In the case of a black-list the device will only accept a key block revocation list with an embedded version number equal to or exceeding the revocation sequence number wherein in the case of a white-list the device will only accept a new key block or a new white-list with an embedded version number equal to or exceeding to the revocation sequence number.
In another preferred embodiment said device further comprises an internal timer, wherein said internal trigger means is adapted for triggering said process of renewing of said revocation information after a predetermined or randomly chosen period of time. With the provision of a predetermined, fixed time after which new revocation information is to be requested or the revocation version number is increased, said device forces an application unit to receive and transmit new revocation data in regular intervals. Thus, it is ensured that the longest time which an application unit to be revoked may unrightfully but however successfully authenticated by a device is limited to be shorter than said predetermined period of time. Said period of time may also be randomly chosen after each triggering.
In an advantageous embodiment said device further comprises an internal counter for counting the number of authentications, wherein said internal trigger means is adapted for triggering said process of renewing of said revocation information after a predetermined or randomly chosen number of authentications. In another advantageous embodiment said device further comprises an internal meter for measuring the amount of data, in particular content protected data, handled by said device, wherein said internal trigger means is adapted for triggering said process of renewing of said revocation information after a predetermined or randomly chosen amount of data is handled. By using the number of authentications or the amount of handled data as a trigger event it is possible to limit the utility of an application unit which is newly revoked, e.g. in the newest black-list but not in older versions of the black-list. Similar to the provision of a limited time period between two triggering events the damage possibly caused by a newly revoked application unit, e.g. the unrightfully accessed content, is limited.
In yet another embodiment of the present invention said authentication means is adapted for retrieving an identifier substantially uniquely identifying said application unit and an authentication key associated with said application unit, and said device further comprises a non-volatile memory for storing said authentication key. The authentication key obtained during a first authentication may also be used as a secret shared between said device and said application unit and/or to generate or communicate such a shared secret in further instances of communication without the need of an additional authentication.
In another advantageous embodiment of the method according to the present invention said step of authenticating comprises
In case of a black-list, the device may check during the authentication that the used key block (version number) does not appear on the revocation list. To this end the device may check a signature on the key block which ties its version number to the key block or root key.
Then, during an update of the revocation list, the device may check that this list has not been tampered with, i.e. the device may verify a signature on the revocation list (if the revocation list is stored internal to the device, this signature check may be necessary only once).
In the case of a white-list, the device may check that the key block is fresh enough, i.e. that the version number of the key block is higher than an internally stored version number. This step also requires that a signature is checked, viz. a signature on the key block which ties its version number to the key block or root key.
Checking signatures is approximately one order-of-magnitude more expensive than symmetric key decryption/encryption and according to the present embodiment of a method for authentication these expensive signature-checking operations may be minimized
The protocols for black-listing white-listing are cut in two parts:
It has to be noted that the price to be paid for the cheaper authentication phase is that the hardware device may need to store a root key per application in (secure) NVRAM.
In general this should not be a problem because the device may need (secure) NVRAM anyway to store the revocation sequence number and or revocation version number. Although this requires roughly 16(root key)+4(appl. ID)=20 bytes per application, should NVRAM come at a premium, the hardware device could overwrite less used root keys by root keys which are required more regularly; the consequence is that the less used application has to undergo a signature check of its key block every time it is used.
Typically the enrollment phase is executed when an application wants to authenticate with the hardware device for the first time. A convenient implementation of key block revocation via black-listing is to strike the root key of an application from NVRAM, when this application or its key block has appeared on a key block revocation list. A convenient implementation of key block revocation via white-listing is to strike all the root keys from NVRAM, when a trigger or time-out signal is received.
In the following the present invention will be described further with respect to the accompanying figures, in which:
If in step 22 it is found that the version number of the black-list is lower than the revocation version number, or if in step 24 it is found that the present key block is revoked according to the black-list, the authentication is aborted in step 26 or 27, respectively, and the protocol continues with step 20. If in step 20 it is found that there is a time-out event, i.e. the internal trigger means of said device triggered a process of renewing, the revocation version number is increased in step 28 and the process is again continued with step 20.
Further, an application random number RA is generated 58 and a message 60 is transmitted to said device 42. Said message 60 contains an indicator for the relevant node of said application key block AKB, said authorization key, said random number RA and a certificate or signature of said key block AKB. In step 62 said authentication key Kroot is decrypted by means of the appropriate device key KDj. Further, the signature on the header of said application key block AKB in said certificate or signature is checked. Additionally, there is a check whether the obtained root key Kroot complies with its shadow in said header.
In case of black-listing the signature on the revocation list is checked. If said device 42 stores its own revocation list this check has to be done only once after storing but if said device 42 is provided with a (new) revocation list upon each instance of an authentication, e.g. by said application unit 40, said check has to be repeated during each authentication. Further, it is checked whether said key block identifier or application identifier IDA is in said revocation list 44.
It is to be noted that in the VCPS authentication protocol the application key block is not revoked directly as described in the previous three paragraphs. Therefore the VCPS authentication protocol lacks the exchanging and checking of a certificate/signature, as well as the interpretation of key block black/white-lists.
In case of white-listing the version number in the header of said application key block is compared to said revocation version number, i.e. it is checked whether the version number of the key block is equal to or exceeds said revocation version number which is preferably stored in a NVRAM.
In step 64 a device random number RD is generated by said device 42 and transmitted 68 together with said application random number RA and a device key contribution KDbus and encrypted by means of said root key Kroot to said application unit 40. By means of said root key Kroot embedded in said application unit 40 the message 68 is decrypted and its validity is checked by checking for the presence of the correct application random number RA (step 70). In step 72 an application key contribution KAbus is generated which is transmitted 74 to said device 42 together with said application random number RA, said device random number RD and said application key contribution KAbus being encrypted by means of said root key Kroot. The validity of this response 74 is checked by checking for the presence of said device random number RD. In steps 78 and 80 a bus key is generated as a one-time shared secret by said application unit 40 and said device 42, e.g. by application a hash-function to the combination of said application key contribution KAbus and said device key contribution KDbus. Thus, the authentication is completed.
It has to be noted that the authentication is aborted by said application unit 40 or said device 42 if any check implies that some part of this authentication is not valid. The certificate checkings in step 62 are expensive and it would be advantageous to avoid or reduce repetitions of this step in order to accelerate the authentication protocol.
Because of the Key Publishing Attack, key block-based broadcast encryption is commonly considered to be not suitable for authentication. However, the Video Content
Protection System VCPS by Philips and HP (cf. http://www.licensing.philips.com/vcps) introduced a way to use broadcast encryption avoiding this attack by restricting the use of device keys to hardware devices, and giving every (vulnerable) software application its own key block and root key. In this system there is two-way authentication but not two-way revocation, i.e. the software application may revoke the hardware device but the hardware device cannot revoke the software application. According to the present invention this system may be extended to the case of true two-way revocation by introducing key block black-listing (the hardware device regularly obtains a list of key blocks/applications which can no longer be used) or key block white-listing (the hardware device regularly revokes all existing key blocks/applications, and demands new key blocks to continue authentication). A number of solutions for hardware devices to obtain fresh revocation information/full revocation triggers is provided. The present invention is in particular suitable to provide an authentication protocol between a software application and a graphics card or tuner-card in the PC back-end.
After a self-generated time-out, the hardware device may refuse any authentications until a new key block revocation list is delivered (black-list) and/or the hardware device may refuse all authentication with existing key blocks, and will only authenticate with new key blocks until the next time-out (white-list). It is proposed that the hardware device has an internal notion of time, performed authentications and/or handled content. Some other (similar) value may also be used as a “count-down” to a triggering event. This “time” keeping function regularly releases a trigger which signals to the device to refuse any further authentication until new revocation information has been delivered or new key blocks are installed.
Examples of conditions setting off this trigger are:
It has to be noted that suitable measurements should preferably be taken to prevent a tampering with the processing authentication data. For example, in order to prevent an attacker from passing an old revocation list or key block off as a new one, the version number in either the revocation list or the key block is tied to the revocation list or key block in a cryptographically secure manner, e.g. the version number and revocation list/key block are signed together by a licensing or certificate authority. Further, the storage or memory means should preferably be secure and non-volatile.
The present invention may be combined with a grace-period mechanism, e.g. those described in “Grace period for unauthorized device-host interactions” (international patent application PCT/IB2005/051758, attorney docket PHNL040647) which attempts to solve the problem of a system stuck in a dead-lock when one component of this system demands fresh revocation information but the system has no means to access a network to retrieve such information.
| Number | Date | Country | Kind |
|---|---|---|---|
| 05105837.8 | Jun 2005 | EP | regional |
| Filing Document | Filing Date | Country | Kind | 371c Date |
|---|---|---|---|---|
| PCT/IB06/52087 | 6/26/2006 | WO | 00 | 12/20/2007 |
