Content protection for transmission systems5949877Abstract A method for protecting digital content from copying and/or other misuse as it is transferred between devices over insecure links, includes authenticating that both a content source and a content sink are compliant devices, establishing a secure control channel between the content source and the content sink, establishing a secure content channel, providing content keys, and transferring content. In a further aspect of the present invention, at least one certificate revocation list version identifier is exchanged between the content source and the content sink, and if the received certificate revocation list version identifier is more recent than the certificate revocation list version identifier stored in the receiving device, then the certificate revocation list of the receiving device is updated. Claims What is claimed is: Description FIELD OF THE INVENTION
__________________________________________________________________________
General: n, g = public constants for Diffie-Hellman
S.sup.X.sbsb.1 ›M! = Sign M using DSS with private
key exchange
key X.sup.-1 Values Shared by Devices:
V.sup.X.sbsb.1 ›M! = Verify signature of M using DSS
K.sub.Control = Y.sub.V .sup.Xk mod n where Y.sub.V is
the first
with public key X.sup.1
phase Diffie-Hellman value from other
.vertline. = Concatenation of fields
30 device = Robust Control Channel key
License Authority: K.sub.content = Random Content Channel key
L.sup.1, L.sup.-1 = License authority DSS
Algo.sub.-- Select = Selected symmetric cipher
public/private key pair
algorithm
For Device X: X.sub.Hash = SHA-1 hash of software
X.sup.1, X.sup.-1 = DSS Public/private key pair
implementation
X.sub.CRLV = Current CRL version number
X.sub.Auth.sub.-- Mask = Authorization Mask
X.sub.CRLD = Current CRL device ID list
X.sub.Cert = S.sup.L.spsp.-1 ›X.sub.ID .vertline.X.sub.
Hash .vertline.X.sub.Auth.sub.-- Mask.vertline.X.sup.1!
=
X.sub.CRL = S.sup.L.sbsb.-1 ›X.sub.CRLV .vertline.X.sub.CRLD ! = CRL
Device Certificate
X.sub.ID = Identification Number
X.sub.V = g.sup.Xk mod n = First phase value for the
Xk = Random value for the first phase of
Diffie-Hellman key exchange
the Diffie-Hellman key exchange
__________________________________________________________________________
Cryptographic Support from the License Authority When the License Authority is established, it must generate a public key/private key pair, L.sup.1 and L.sup.-1. These keys will be used extensively, for the lifetime of the License Authority, to sign and verify the digital certificates upon which compliant systems are based. L.sup.-1 is the most important key in this entire cryptographic system. It must be closely held by the License Authority. In the event of disclosure, the security of the entire system would be at risk of being compromised. L.sup.1 must be distributed widely to allow verification of certificates signed by the License Authority. The License Authority is responsible for the creation of Certificate Revocation Lists (CRL). A CRL is composed of two parts, a list (CRLD) of device IDs whose compliance with the conditions of the license have been violated and detected by the License Authority, and a monotonicly increasing version identifier (CRLV). These contents are signed by the License Authority, S.sup.L.spsp.-1 ›CRLV .vertline.CRLD!, to ensure authenticity. If the list, CRLD, becomes unwieldly because of its size, then the list may be compressed. The trade-off to be considered by a designer is the additional computation needed to decompress the data. Finally, the License Authority must also create the constants n and g required for the Diffie-Hellman key exchange protocol. It is not necessary to maintain the secrecy of these values. All compliant systems will need them to perform the key exchange protocol. Compliant Systems All compliant systems should generate during manufacture a public/private key pair (X.sup.1, X.sup.-1) using the defined key generation mechanism described above. X.sup.-1 must be stored within the system in such a way as to reduce, to the extent possible, the likelihood of its disclosure. Typically, CE devices use hardware based anti-tampering techniques, and PCs use software mechanisms, often available in the operating system, to achieve tamper-resistance. If X.sup.-1 is disclosed, or the integrity of the implementation is compromised, and the License Authority is able to detect this, then X.sub.ID may be added to the CRL distributed on future media. The manufacturer should demonstrate that the system is compliant with the terms of the license. If successful, the License Authority will create a digital certificate for the system. This certificate (X.sub.Cert) consists of the unique device ID(X.sub.ID), an SHA-1 (Secure Hash Algorithm-1) hash of the implementation software (X.sub.Hash), an authorization mask (X.sub.Auth.sbsb.--.sub.Mask) that specifies the channel encryption algorithms supported by the system, and the device's public key (X.sup.1). These values are signed by the License Authority resulting in X.sub.Cert =S.sup.L.spsp.-1 ›X.sub.ID .vertline.X.sub.hash .vertline.X.sub.Auth.sbsb.--.sub.Mask .vertline.X.sup.1 !. This certificate is stored by the compliant system and used in the authentication process. In addition, all compliant system must know L.sup.1. One way to ensure uniqueness if device IDs is to have them assigned by the License Authority. SHA-1 (Secure Hash Algorithm-1) is the part of the DSA which is used to generate a message digest. A message digest is an unique value associated with a message. It is similar in concept to a checksum, but significantly harder to forge. SHA can also be used to generate a message digest for the code used to implement the authentication and key exchange mechanisms. If the code is tampered with, X.sub.Hash in the device's certificate will not match the value calculated over the corrupted code. Compliant Media Prerecorded media containing protected content can be used to distribute updated CRLs. During the media manufacturing process, an up to date copy of the CRL is stored on the media. Compliant systems reading this media can update their CRL from the media if the version number (CRLV) is more recent. The CRLV may also be referred to as a CRL version identifier. The CRLV may be numbers, letters, or other suitable marks or codes that can be perceived and compared. System Authentication and Control Channel Key Exchange In accordance with embodiments of the present invention and as shown in FIGS. 1(a)-(c), when a compliant device is added to a communications link such as an IEEE 1394 serial bus, a cryptographic protocol is used to authenticate the devices on the bus and establish control channels between them. In this illustrative example, a compliant device ("Device A") which is a source of protected content (e.g., a DVD player) is attached to a serial bus which already has another compliant device ("Device B") which is a sink for protected content (e.g., a PC running an MPEG-2 decoder) attached to it. In this illustrative example, all messages are sent using IEEE 1394 asynchronous transactions. As soon as Device A has been initialized, it attempts to authenticate the other devices attached to the serial bus to determine which are compliant. In this example Device A performs the protocol with Device B. In a step 102 Device A transmits a signed message, S.sup.A.spsp.-1 ›A.sub.CRLV .vertline.A.sub.Cert .vertline.A.sub.C ! to Device B which contains Device A's certificate (A.sub.Cert), Device A's CRL version number (A.sub.CRLV) and a random challenge (A.sub.C). Those skilled in the art will recognize that variations to this protocol might include more or fewer items. When Device B receives the message it first checks, in a step 104, the signature by computing V.sup.A.spsp.1 ›S.sup.A.spsp.-1 ›A.sub.CRLV .vertline.A.sub.Cert .vertline.A.sub.C ! with A's public key (A.sup.-1 from A.sub.Cert) to verify that the message has not been tampered with. If the signature cannot be verified, Device B in a step 108 refuses to continue. Typically, a time-out condition will be detected and the devices will recognize that the current communication session has been terminated. However, as those skilled in the art will recognize, any appropriate handshaking protocol can be used to terminate the communication session. If the signature is valid, the next step 110 is to verify A's certificate by computing V.sup.L.spsp.1 ›A.sub.Cert !. If the License Authority signature is not valid, Device A does not have a valid certificate, and thus is not a compliant system. If the signature is valid, then in a step 114 Device B checks to see if A.sub.ID (in A.sub.Cert) has been revoked by searching its CRL (B.sub.CRLD). If A.sub.ID is on the list, then Device B considers Device A a non-compliant system and in a step 108 refuses to continue. Also, in a step 118 Device B checks to see if the Device A has a more recent CRL by comparing A.sub.CRLV to B.sub.CRLV. and if A.sub.CRLV >B.sub.CRLV then the CRL update procedure is performed following the completion of the authentication and key exchange process. If no errors are encountered, then in a step 120 Device B sends a signed message, S.sup.B.spsp.-1 ›B.sub.CRLV .vertline.B.sub.Cert .vertline.B.sub.C .vertline.A.sub.C .vertline.B.sub.V ! to Device A which contains the following elements: Device B's certificate (B.sub.cert), Device B's certificate revocation list version number(B.sub.CRLV), a random challenge (B.sub.C), the random challenge from Device A (A.sub.C), and the Diffie-Hellman key exchange first phase value from Device B (B.sub.V). On receipt of this message, in a step 122 Device A checks the signature by computing V.sup.B.spsp.1 ›S.sup.B.spsp.-1 ›B.sub.CRLV .vertline.B.sub.Cert .vertline.B.sub.C .vertline.A.sub.C .vertline.B.sub.V !! to verify that the message has not been tampered with (B.sup.1 is in B.sub.Cert). If, in a step 124, the signature cannot be verified, Device A refuses to continue. If the signature is valid, the next step 126 is to compare the value of A.sub.C returned by Device B to the value which was originally sent out. If these value do not match, then Device B did not answer the random challenge correctly. If the values match, then Device A verifies Device B's certificate by computing V.sup.L.spsp.1 ›B.sub.Cert ! in a step 128. If the License Authority signature is not valid, Device B does not have a valid certificate and thus is not a compliant system. If the signature is valid, Device A, in a step 132 checks to see if B.sub.ID (in B.sub.Cert) has been revoked by searching its CRL (A.sub.CRLD). If B.sub.ID is on the list, Device A considers Device B to be a non-compliant system and in a step 108 refuses to continue. Also, in a step 136 Device A checks to see if Device B has a more recent CRL by comparing B.sub.CRLV to A.sub.CRLV. If B.sub.CRLV >A.sub.CRLV then a CRL update procedure is performed following the completion of the authentication and key exchange process. In embodiments of the present invention which implement more than one cipher algorithm, Device A specifies which channel encryption algorithm will be used to protect the Control Channel. B.sub.Auth.sbsb.--.sub.Mask (found in B.sub.Cert) is compared with A.sub.Auth.sbsb.--.sub.Mask to select the strongest encryption algorithm which is mutually supported. Algo.sub.-- Select is set to the appropriate value. A signed message S.sup.A.spsp.-1 ›B.sub.C .vertline.Algo.sub.-- Select.vertline.A.sub.V ! is then transmitted to Device B, where B.sub.C is the value of the random challenge from Device B, Algo.sub.-- Select is the control channel encryption algorithm to be used, and A.sub.V is the Diffie-Hellman key exchange first phase value from Device A. When this message arrives, Device B first verifies the signature by computing V.sup.A.spsp.1 ›S.sup.A.spsp.-1 ›B.sub.C .vertline.Algo.sub.-- Select.vertline.A.sub.V !!. If the signature is valid, Device B compares the value of B.sub.C in the message to the value which it originally sent out. If these two values are the same, then Device B has authenticated Device A. Otherwise, Device B aborts the protocol and assumes that Device A is a non-compliant device. If no errors have occurred up to this point, the two devices have authenticated each other. They have also agreed upon a control channel cipher key and algorithm. In addition, by calculating B.sub.V.sup.Ak mod n and A.sub.V.sup.Bk mod n for Devices A and B respectively, a common key K.sub.Control (g.sup.AkBk mod n) for the control channel is established. This control channel remains available as long as both devices remain attached to the serial bus. This control channel is then used to set up and manage the security of protected content streams without further computationally intensive device authentication and Diffie-Hellman key exchanges. Content Channel Encryption To establish a channel for protected content, the following procedure, as shown in FIG. 2, is used. The source of the content, in a step 202, sends a message, via the previously established control channel, to a compliant destination device (or devices in the case of a content multicast). This message contains the following elements: a randomly generated key which is unique for each stream of content (K.sub.content), identification of the symmetric cipher to be used (Algo.sub.-- Select), and the isochronous channel associated with the content stream. If additional compliant devices desire to receive content which is already being transmitted, those devices can request receipt of the values described above via the control channel. A separate control channel is created between each source and destination. The protected content is transmitted in a step 204. When the source has completed the transmission of the protected content it sends a message, in a step 206 to the destination(s) asynchronously via the control channel(s) which terminates the content channel. Since most content is real time in nature, it is preferable to use isochronous transfers when using the IEEE 1394 serial bus. This content protection system, however, can also be used to protect non-real time content transferred asynchronously. Compliant System Components A compliant system must implement the components described in the following sections. FIG. 3 shows the components required for a device which is a source of protected content. FIG. 4 shows the components for a receiver of protected content. In both FIGS. 3 and 4, the subsystems in boxes with solid outlines are required for compliance. Boxes with dashed outlines are subsystems which are common to compliant and non-compliant devices. Marking Subsystem A Marking Subsystem 302 shown in FIG. 3 is present in systems which are sources of protected content. The primary function is to determine the protection status of the content which is to be transferred across the serial bus. This status is then translated into protection requirements which are passed to an Authentication and Key Exchange Subsystem 304. A secondary function is to update the CRL stored in the device if the content has a newer CRL. Updating Device CRL from Prerecorded Content Media This procedure applies to devices which can read prerecorded, protected content from removable media. Prerecorded, protected media, in accordance with the present invention, contains a Certificate Revocation List which is current as of the time the media is manufactured. When a device loads new, prerecorded media, it examines the version number of the CRL stored on the media. If this value is greater than that of the device's current CRL, the device uses the following steps to update its CRL: 1. Read the CRL from the Media 2. Verify the signature of CRL with the License Authority's public key. 3. If the signature is valid, store the newer CRL in the device's non-volatile storage. Authentication and Key Exchange Subsystem As shown in FIGS. 3 and 4 an Authentication and Key Exchange Subsystem 304, 404 is found in both Senders and Receivers of protected content. Authentication and Key Exchange Subsystem 304, 404 is responsible for implementing the protocols which are used to ensure that devices exchanging protected content are compliant. The protocol is also used to select a channel encryption algorithm and exchange the control channel encryption key. Updating the CRL from a Remote Device If during device authentication a more recent CRL is discovered on another device the following procedure is used to update the local CRL: 1. Read the CRL from the remote device 2. Verify the signature of CRL with the License Authority's public key. 3. If the signature is valid, store the newer CRL in the device's non-volatile storage. This procedure should take place following the completion of authentication and key exchange. Since updating the CRL is not a time critical activity, it can be done in the background. In this way impact on normal device operation is typically small. Channel Encryption Subsystem A compliant device that transmits protected content must have a Channel Encryption Subsystem 306. Control messages, as well as protected content, are encrypted prior to transmission. Channel Encryption Subsystem 306 performs these encryptions. The keys used to encrypt the content and commands are passed to Channel Encryption Subsystem 306 from Authentication and Key Exchange Subsystem 304. Channel Encryption Subsystem 306 may support more than one cipher, although for interoperability it is preferable that a Baseline Cipher be supported. In a typical embodiment of the present invention, Authentication and Key Exchange Subsystem 304 specifies the particular cipher and key to be used for each packet transmitted. Channel Decryption Subsystem A compliant device which receives protected content must have a Channel Decryption Subsystem 408. Channel Decryption Subsystem 408 decrypts control messages and protected content which are received from the serial bus. The keys used to decrypt the content and commands are passed to Channel Decryption Subsystem 408 from Authentication and Key Exchange Subsystem 404. Channel Decryption Subsystem 408 may support more than one cipher, although for interoperability it is preferable that a Baseline Cipher be supported. Authentication and Key Exchange Subsystem 404 specifies the particular cipher and key to be used for each packet received. Baseline Cipher A Baseline Cipher must be supported by Channel Encryption Subsystem 306 and Channel Decryption Subsystem 408 of all compliant devices. This baseline cipher is required to ensure the interoperability of all compliant devices. Additional ciphers with other properties such as increased security can also be deployed and used, provided that both the source and destination devices support it. Those skilled in the art will recognize that many symmetric key ciphers, for example DES, are available to for use as a baseline cipher. Channel Encryption Performance In order to support content transfer of an MPEG-2 compressed video stream, the encryption cipher implementation should be able to deliver at least approximately 12 Mbps. For PCs, this cipher is typically implemented in software. For CE devices, it is typically implemented in hardware. Key Generation at Device Manufacture Ideally, each device manufactured will have a unique device ID and public/private DSS key pair. With unique device IDs and DSS keys, the License Authority will only need to revoke the certificates of the specific devices which have been compromised. Other users who bought the same device model and have not violated the license agreement would not be effected by this revocation. The principle drawback of this scheme may be that the manufacture of CE devices is made more complicated. This would be the case if no information unique to each copy of the device (such as a serial number) is currently programmed into it. Certificate Revocation List Storage and Size Certificate Revocation Lists are straightforward to implement and use as long as CE devices have sufficient non-volatile, reprogrammable storage in which to keep the list. PC implementations do not have this problem as the CRL can be stored on disk. Unless the lists remain relatively short, a direct representation may become unwieldy. Techniques are available to generate more compact representations of the list, but they require more computation to search. Key Generation It will be apparent to those skilled in the art that with respect to DSS key generation, various key generation procedures and key lengths are possible. Selection of specific key generation procedures and key lengths should be chosen in view of the performance of the underlying platform. Typically, key lengths of from 512 to 1024 bits may be used, however, as readily understood by those skilled in the art, there is a trade-off between the increased security provided by longer keys, and the increased time that it takes to sign and verify with a longer key. With respect to the generation of keys for the Diffie-Hellman protocol, the properties of the constants g and n should be as follows: g is primitive mod n (Choose the smallest g possible) n is large prime (n-1)/2 must also be prime where g is primitive with respect to p is for each b from 1 to n, there exists some a where g.sup.a is congruent to b (mod p). The security of the key exchange is based on the size of n. At a minimum, n must be larger than the channel key size. The actual size is chosen by a system designer in view of the capabilities of the underlying platform, particularly in terms of the time required and the latency that might be seen by an end user of the system. Depending on the strength of the channel ciphers, it may be necessary to change both control and content cipher keys on a regular basis. Control channel keys are preferably renegotiated using the Diffie-Hellman protocol. New content channel keys can be distributed via the control channel. These key changes would typically be a relatively low priority (as compared to delivery of real-time audio and video for example) activity, typically performed in the background and therefore unlikely to adversely affect overall system performance. Conclusion Embodiments of the present invention provide a flexible system which can support a range of protection levels. Digital certificates enable device authentication which excludes the use of devices which can circumvent the protection of the content. Furthermore, the content itself will be encrypted to ensure that even if it is copied, it will be in an unusable format. In typical embodiments of the present invention, the keys used to protect the content are exchanged using the Diffie-Hellman key exchange protocol. The present invention allows for a high level of content protection which can be implemented with a reasonable level of resources for consumer electronics equipment and computer systems. Embodiments of the present invention advantageously provide strong protection of audio/video content transmitted over communications links such as an IEEE 1394 buss. A further advantage of the present invention is that non-compliant devices are unable to transmit or receive protected content. Define a system which works well for PCs and consumer electronics (CE) devices. A still further advantage of the present invention is that it is inexpensive to implement in PCs and other consumer electronic devices. It will be understood by those skilled in the art that many design choices are possible within the scope of the present invention. The present invention is not limited to communication via a bit serial link, nor is it limited to a particular cryptographic algorithm or key length. For example, although an illustrative embodiment of the present invention is described as using an IEEE 1394 serial bus, the present invention is equally applicable to other interconnect technologies such as Ethernet, Asynchronous Transfer Mode (ATM), cable television systems, and telephony networks. Further cryptographic algorithms chosen for the content and control channels may be different. The present invention can be embodied as methods and apparatuses for practicing those methods. The present invention can also be embodied in the form of computer program code embodied in tangible media, such as floppy diskettes, CD-ROMs, hard drives, or any other computer-readable storage medium, wherein, when the computer program code is loaded into and executed by a computer, the computer becomes an apparatus for practicing the invention. The program code encoded in tangible media creates the means for causing the computer to perform the various steps of the present invention. The present invention can also be embodied in the form of computer program code, whether stored in a storage medium loaded into and/or executed by a computer, or transmitted over some transmission medium, such as over electrical wiring or cabling, through fiber optics, or via electromagnetic radiation, wherein, when the computer program code is loaded into and executed by a computer, the computer becomes an apparatus for practicing the invention. When implemented on a general purpose microprocessor, the computer program code combines with the microprocessor to provide a unique device that operates analogously to specific circuits. It will be understood that various changes in the details, materials, and arrangements of the parts and steps which have been described and illustrated in order to explain the nature of this invention may be made by those skilled in the art without departing from the principles and scope of the invention as expressed in the subjoined claims.
|
Same subclass Same class Consider this |
||||||||||