Abstract:
Two processing elements in a single platform may communicate securely to allow the platform to take advantage of the certain cryptographic functionality in one processing element. A first processing element, such as a bridge, may use its cryptographic functionality to request a key exchange with a second processing element, such as a graphics engine. Each processing element may include a global key which is common to the two processing elements and a unique key which is unique to each processing element. A key exchange may be established during the boot process the first time the system boots and, failing any hardware change, the same key may be used throughout the lifetime of the two processing elements. Once a secure channel is set up, any application wishing to authenticate a processing element without public-private cryptographic function may perform the authentication with the other processing element which shares a secure channel with the first processing element.

Description:
BACKGROUND  
       [0001]    This relates generally to communications between processing elements. 
         [0002]    In a number of instances, one processing element in a platform may wish to communicate with another processing element in the same platform. Examples of such communications include communications between input/output (I/O) bridges and graphics chips or communications between a chipset and a graphics chip. Each of the chipset, the graphics chip, and the bridge may have an integrated internal controller or processor. 
         [0003]    There are instances when two of these processor-based components wish to communicate in a secure fashion. Typically, such secure communications involve repeated establishment of secure communication channels between the two different devices. 
         [0004]    Various types of secure content may be received to be played back on a computer. For example, pay per view video or proprietary content may be received on a computer system for playback. Digital versatile disk (DVD) content may also be played on computers. This content may arrive in an encrypted fashion and, therefore, cannot easily be intercepted in route to the receiving computer. 
         [0005]    However, once the content arrives at the computer, it may be decrypted for playback. Once decrypted, it may be accessed by malevolent software in the computer system and stolen by unauthorized entities. Unauthorized copies of software, DVD disks, games, videos, and other content may be made in this way. 
     
    
     
       BRIEF DESCRIPTION OF THE DRAWINGS  
         [0006]      FIG. 1  is a depiction of a system in accordance with one embodiment of the present invention; 
           [0007]      FIG. 2  is a flow chart for the embodiment shown in  FIG. 1  in accordance with one embodiment; 
           [0008]      FIG. 3  is a depiction of a system in accordance with one embodiment of the present invention; 
           [0009]      FIG. 4  is a flow chart for the embodiment shown in  FIG. 3  in accordance with one embodiment; 
           [0010]      FIG. 5  is a depiction of a system in accordance with one embodiment of the present invention; and 
           [0011]      FIG. 6  is a flow chart for the embodiment shown in  FIG. 5  in accordance with one embodiment. 
       
    
    
     DETAILED DESCRIPTION  
       [0012]    Referring to  FIG. 1 , a processor-based system  12 , such as a graphics engine, includes a processor or controller. The system  12  may wish to communicate with another processor-based system  18 , such as a bridge, in this example. However, the two processor-based systems  12  and  18  may be a variety of different devices, including a central processing unit, a south bridge, a north bridge, a peripheral component hub, or a graphics engine, to mention a few examples. 
         [0013]    The systems  12  and  18  may be part of a larger processor-based system  10 , such as a personal computer, have a central processing unit coupled to the processors  12  and  18 . Other examples of such larger systems  10  include media players, set top boxes, and handheld or mobile devices. 
         [0014]    In one scenario, one of the two processor-based systems  12  or  18  may have a cryptographic capability. It may be advantageous, in some embodiments, to enable communications between the two devices without providing the same graphics capability in both devices. In one embodiment, the system  18  may have such a cryptographic capability. For example, it may have a so-called manageability engine (ME) or controller which implements cryptographic functions. As one example, it may include a direct, anonymous, attestation (DAA), public-private key system that provides RSA like functionality with an entity. No such capability may be provided on the other device  12 . 
         [0015]    In order to play a secure DVD disk, as one example, it is necessary for system  18  to perform a cryptographic operation with a third party application  78 , such as a software player, and then communicate the result to system  12  in a secure fashion. This may be possible in some embodiments even though both systems  12  and  18  do not have the full cryptographic functionality that one of the devices, in this case the system  18 , may possess. 
         [0016]    Thus, upon booting of both the systems  12  and  18 , the system  18  may initially inquire as to whether or not it has a secure communication key. In some embodiments, this may be done during the boot sequence of the system  10 , after booting of the systems  12  and  18 , but before completing system  10  boot and before there is any handoff of control to the operating system. 
         [0017]    Thus, the boot environment is generally a secure environment. However, communications between the components  12  and  18 , in some embodiments, may be done using a secure message protocol, such as vendor defined messages available with the PCI Express standard. See PCI Express Base 2.0 Specification (2007), available from the PCI Special Interest Group, Beaverton, Oreg. 97006. Messages using the vendor defined message (VDM) protocol may be exchanged in a proprietary fashion. 
         [0018]    Thus, the system  18  may initially ask whether it has a communication key  34 . It then sends a request for a communication key, as indicated at  28 , over a direct memory interface (DMI) interconnecting bus communication links  22 , for example. The message may be received within the system  12  by a traffic control entity. The system  12  may have a global key  38  in one embodiment. The global key  38  may be provided to all devices that are meant to operate with one another. All of these devices may have the same global key G. Thus, in this embodiment, the system  12  includes the global key G, as indicated at  38  and the system  18  includes the global key G, indicated at  38 . 
         [0019]    Initially, the system  12  derives the encrypted key kf 1  from a fuse value F 1 , as indicated in block  20 . In one embodiment, the system  12  has a unique, stored, randomly generated 128 bit value which is unique to the system  12 . It may be stored in a permanent memory, which may be referred to as a fuse or fuse block. The fuse or fuse block  14  may permanently store the fuse value. However, any type of permanent memory storage may be used for this purpose. The fuse block  14  provides the fuse F 1  to the block  20 . The block  20  then derives, from fuse F 1 , the encrypted value kf 1 . 
         [0020]    In one embodiment, kf 1  may be derived from F 1  using the Advanced Encryption Standard (AES), available from NIST Publications, Springfield, Va., 22161. Then kf 1  is encrypted with the global key G, still as indicated in block  20 . Then the system  12  sends the value of kf 1 , encrypted with the global key G, as indicated at  30 , over the communication link  22 , back to the system  18 . 
         [0021]    In the system  18 , the encrypted key kf 1  is decrypted using the global key G from the storage  38  in block  32 . Then kf 1  is encrypted with a key kf 2 , which comes from a fuse block  40  on the system  18 . The fuse value F 2  is totally unique to the system  18  and may be a random number permanently stored on the system  18 , for example, in the form of a 128 bit randomly generated value. The value of kf 1 , encrypted with kf 2 , is stored in a system flash memory, as indicated at  42 , in accordance with one embodiment. 
         [0022]    Thus, referring to  FIG. 2 , the system  10  begins to boot and the system  12  boots up and determines it has no key for communications with the system  18 , as determined in block  50 . Then the system  18  requests the communications key from the system  12 , as indicated in block  52 . The system  12  then generates the desired key using a global key  38  and a fuse block fuse  14  in one embodiment. The encrypted key is then sent to the system  12 , as indicated in block  54 . The system  18  then securely stores the communication key, as indicated in block  56 . 
         [0023]    In some embodiments, this key exchange may be done the first time that the system  18  boots up. From then on, all communications are possible in a cryptographic mode using the now exchanged key that is stored in the flash. This key will be useful as long as there is no hardware change. Messages can then be sent across the DMI interface using vendor defined messages. Thus, secure communications are now possible between the two devices, despite the fact that only one of the devices has full cryptographic capabilities. DMI messages may be used as long as both sides of the communication have a suitable mailbox that has been established. 
         [0024]    In some embodiments, the key exchange code just described may be part of the boot up code. Thus, there may be a storage or memory that stores the boot up code, code for the system  18 , and the code to implement the secure communication protocol described herein. For example, this may all be stored in the flash memory  42 . In some embodiments, the boot code may contain manageability capabilities to protect this stored code. 
         [0025]    System  18  may perform cryptographic operations on behalf of system  12  with a media source (like a software media player) or other applications  78  and then pass the result to system  12 . However, the general concept is that any one processor may use the security functions of another processor to enable secure communications between the two processors. As one example, every time that you need to play a movie, a session key may be sent across a communication interface. The application running on a central processing unit, such as a Windows® media player, may authenticate the system  12  hardware before setting up a session key for transmission of video data. 
         [0026]    The above-described protocol is one way to make such an exchange. The scheme allows for the application to authenticate the hardware using system  18  cryptographic hardware and then securely transmits the session key to system  12 . From this point, the application and system  12  can communicate securely using the session key. 
         [0027]    Referring to  FIG. 3 , each time there is another boot, a check may be implemented to make sure that the right key is possessed by the system  18 . Thus, upon booting, the system  18  obtains the encrypted key from flash  42 . It unwraps the key using the kf 2  value from the fuse  40 . It takes the kf 1  value and encrypts a standard variable, such as zero in this case, as indicated in block  36 . Then it sends the encrypted value to the system  12  with a message  60  asking if the communication key is valid and telling the system  12  that it has encrypted zero with the key that is believed to be common between the two devices. The system  12  then derives kf 1  using the fuse F 1  from the fuse block  14 . It decrypts the message payload, as indicated in block  64  and returns a yes if it finds a zero and, otherwise, it returns a no, as indicated at  62 . Again, the communications  60  and  62  may be over a secure protocol, such as the DMI. 
         [0028]    The system  18  determines if the response was yes and the key matched. If so, it knows it does not need to do a new key exchange. Otherwise, it triggers a new key exchange, as indicated in block  26 . 
         [0029]    Thus, referring to  FIG. 4 , the system  18  checks, upon each new boot, to determine whether the key is valid (block  66 ). It does so by encrypting a zero with kf 1  and sending a message to the system  12 , as indicated in block  68 . The system  12  checks the validity of the key and sends a response, as indicated in block  70 . Then, in block  72 , the system  18  processes the response from the system  12  and takes appropriate steps. Namely, if the key is valid, communications may continue using the key and, otherwise, a new key exchange must be established using the protocol of  FIG. 1  and  FIG. 2 . 
         [0030]    Playback of premium content, such as DVD movies on a personal computer, is carried out by a software application provided by independent software vendors. These application vendors sign the content license and, hence, are responsible for the secure playback of the content. To fulfill the terms of their contract license, the player applications need to ensure that the data flow of content from the DVD disk to the display device is protected. For video playback, typical applications perform a portion of the video decode and rely on a graphics hardware for the remaining decode and display. Since the application needs to send the premium content over to the graphics device for further processing, the application needs to authenticate that device and set up a secure channel for sending this data over. 
         [0031]    The standard available mechanisms for authentication of the devices setting up a secure channel are fairly complex and generally involve the application and graphics hardware sharing a secret key. The graphics hardware uses a public-private key infrastructure and sends the public key to the application. The use of a shared secret key may be weak from a robustness point of view since a compromise of the secret key in the application affects all other vendors. Relying on graphics hardware to have a public/private key infrastructure involves a significant hardware cost since it involves RSA style exponentiation. 
         [0032]    A session key setup may be negotiated between the application and the bridge to the graphics engine. This can happen at the beginning of each playback session, such as the beginning of a movie. 
         [0033]    Thus, referring to  FIG. 5 , the application  78 , which may be a software application of an independent software vendor, initiates authentication of a graphics device, as indicated at  88 . This request actually goes to the system  18 , which generates a public/private key DAA signed public key, as indicated in block  74 . Thus, the application interacts with the bridge to perform the DAA authentication. The system  18  generates and sends a signed Diffie-Hellman value to the application, as indicated at  76 , and the application  78  verifies the signature. Then the application and the bridge derive a unique session key. 
         [0034]    The system  18  retrieves the graphics bridge communication key from the flash  42  and derives a session key re-encrypted with kf 1  (block  86 ). Then the system  12 , compatible session key  84  is sent over DMI to the system  12 . At block  82 , the graphics engine derives kf 1 , using the fuse F 1  from the fuse block  14 . With kf 1 , it is able to decrypt the session key. As a result, content encrypted with the session key  80  may be sent from the application  78  and decoded in whole or in part by the system  12 . 
         [0035]    Thus, referring to  FIG. 6 , the application initiates authentication of the graphics device, as indicated in block  90 , through the bridge. The application and the bridge derive a unique session key, as indicated in block  92 . Then the bridge sends the encrypted session (block  94 ). Multiple writes may be required to get the session key to the graphics engine. 
         [0036]    Thus, in some embodiments, both a platform specific key in the form of the fuse block  14  and the fuse  40  may be used, together with a global key  38 , which is not platform specific. Even if the global key were broken, the platform specific key is still useful. 
         [0037]    The graphics processing techniques described herein may be implemented in various hardware architectures. For example, graphics functionality may be integrated within a chipset. Alternatively, a discrete graphics processor may be used. As still another embodiment, the graphics functions may be implemented by a general purpose processor, including a multicore processor. 
         [0038]    In accordance with some embodiments of the present invention, capabilities described herein may be implemented in hardware, software, or firmware. In software or firmware embodiments, a computer readable medium, such as a semiconductor memory, may store instructions for implementation by a processing entity, such as a central processing unit, a bridge, or any controller. For example, in some embodiments, each of the steps illustrated in  FIGS. 1-6  may be implemented in software and may be executed on any processor or processing element. For example, in one embodiment, such instructions may be implemented by execution on the system  18 . In other embodiments, portions of the sequences may be executed on the systems  12  and/or  18 . 
         [0039]    References throughout this specification to “one embodiment” or “an embodiment” mean that a particular feature, structure, or characteristic described in connection with the embodiment is included in at least one implementation encompassed within the present invention. Thus, appearances of the phrase “one embodiment” or “in an embodiment” are not necessarily referring to the same embodiment. Furthermore, the particular features, structures, or characteristics may be instituted in other suitable forms other than the particular embodiment illustrated and all such forms may be encompassed within the claims of the present application. 
         [0040]    While the present invention has been described with respect to a limited number of embodiments, those skilled in the art will appreciate numerous modifications and variations therefrom. It is intended that the appended claims cover all such modifications and variations as fall within the true spirit and scope of this present invention.