Cryptographic modules (CMs) employing cryptographic engines (CEs) are commonly used to provide for the encryption and decryption of audio and visual content. Typically, a CM can, on request from an application, use an internal random number generator in conjunction with a secret, on-chip root key to generate one or more storage keys. These storage keys may then be used by the CE to encrypt secrets provided by the application. The storage keys may then be stored in the CM's internal cache memory while the encrypted secrets and associated encrypted storage keys are typically stored in external memory. The secrets are frequently platform specific and may include, among other things, license keys and a unique platform identifier.
Typically, the root key and the key cache are shielded from direct attack by security threats because they are inaccessible to devices external to the CM. However, as long as the encrypted secrets and associated encrypted storage keys are held in external memory they may be used, in conjunction with a typical CM, to expose the secrets and/or storage keys. For example, using a brute force approach a malevolent entity may repeatedly pass carefully chosen text data to a typical CM, request that the CM encrypt the plain text data with the storage keys or secrets, and then compare the encrypted results with the encrypted secrets and associated encrypted storage keys to expose the secrets and/or storage keys.
The accompanying drawings, which are incorporated in and constitute a part of this specification, illustrate one or more implementations consistent with the principles of the invention and, together with the description, explain such implementations. The drawings are not necessarily to scale, the emphasis instead being placed upon illustrating the principles of the invention. In the drawings,
The following description refers to the accompanying drawings. Among the various drawings the same reference numbers may be used to identify the same or similar elements. While the following description provides a thorough understanding of the various aspects of the claimed invention by setting forth specific details such as particular structures, architectures, interfaces, techniques, etc., such details are provided for purposes of explanation and should not be viewed as limiting. Moreover, those of skill in the art will, in light of the present disclosure, appreciate that various aspects of the invention claimed may be practiced in other examples or implementations that depart from these specific details. At certain junctures in the following disclosure descriptions of well known devices, circuits, and methods have been omitted to avoid clouding the description of the present invention with unnecessary detail.
System 100 may be any system suitable for cryptographically processing data (e.g., content such as text, audio, or image data) and providing that data to devices suited to reproducing the audio and/or visual content in a format suitable for presentation on an external device (not shown) such as a liquid crystal display (LCD), or a plasma display panel (PDP) display to name a few examples. Further, system 100 may assume a variety of physical implementations. For example, system 100 may be implemented in a set-top box (STB), a personal computer (PC), a networked PC, a server computing system, a handheld computing platform (e.g., a personal digital assistant (PDA)), a handheld communication platform (e.g., a cellular telephone handset), etc.
While all components of system 100 may be implemented within a single device, such as a system-on-a-chip (SOC) integrated circuit (IC), components of system 100 may also be distributed across multiple ICs or devices. For example, host processor 102, CM 104, memory 106, and A/V decoder 114 may be implemented in one or more ICs contained within a single platform such as a STB while display processor 115 may be implemented in a separate device such as a display (not shown) coupled to elements 102-106, and 114 through communications pathway 108.
Host processor 102 may comprise a special purpose or a general purpose processor including any control and/or processing logic, hardware, software and/or firmware, capable of supporting enhancing cryptographic engines against security attacks in accordance with implementations of the invention. Including, for example, providing CM 104 with configuration payloads, public keys, encrypted data for decryption, secrets for encryption, etc, as will be explained in greater detail below. Software applications executing on processor 102 may undertake a variety of operations in conjunction with CM 104 related to enhancing cryptographic engines against security attacks, the results of which may be stored in memory 106 as will be explained in greater detail below.
Processor 102 may also be capable of initializing and/or configuring registers within decoder 114 and/or processor 115, interrupt servicing, providing a bus interface for uploading and/or downloading encrypted audio/visual content, etc, although the invention is not limited in this regard. Processor 102 may comprise two or more processor cores although the invention is not limited in this regard. While system 100 shows host processor 102, CM 104, decoder 114 and processor 115 as distinct components, the invention is not limited in this regard and those of skill in the art will recognize that processors 102 and 115, CM 104 and/or decoder 114 possibly in addition to other components of system 100 may be implemented within a single IC such as a Soc.
A/V decoder 114 may comprise any control and/or processing logic, hardware, software and/or firmware, capable of decoding decrypted audio and/or video content and providing that decoded content to other components in system 100 such as processors 102 and/or 115. Display processor 115 may comprise any control and/or processing logic, hardware, software and/or firmware, capable of processing decrypted content for display. Processor 115 may receive decrypted and decoded image data provided by host processor 102, memory 106, or A/V decoder 114 and process that data into a format suitable for display. In addition, display processor 115 may implement a variety of image processing functions such as image scaling, alpha blending, etc.
Bus or communications pathway(s) 108 may comprise any mechanism for conveying information (e.g., encrypted content, keys, etc.) between or amongst any of the elements of system 100. For example, although the invention is not limited in this regard, communications pathway(s) 108 may comprise a multipurpose bus capable of conveying, for example, instructions (e.g., macrocode) between processor 102 and decoder 114, or configuration payloads between processor 102 and CM 104. Alternatively, pathway(s) 108 may comprise a wireless communications pathway.
CM 104 may comprise any processing logic, hardware, software, and/or firmware, capable of enhancing cryptographic engines against security attacks in accordance with some implementations of the invention. As will be explained in greater detail below, CM 104 may receive signed configuration payloads from processor 102, or other devices within system 100 or external to system 100, and may, upon verification of the authenticity of that payload, be configured or reconfigured in response to the content of the configuration payload in accordance with some implementations of the invention. CM 104 may further be capable of decrypting encrypted data and of providing the resulting unencrypted data to A/V decoder 114.
In accordance with some implementations of the invention, LM 214 may, in response to CE 210 exceeding an operational limit, prevent CE 210 from encrypting or decrypting data by supplying a disable signal to CE 210. LM 214 may also, in accordance with some implementations of the invention and in response to CE 210 exceeding an operational limit, prevent applications, such as application 220, from requesting cryptographic services from CM 202 by providing a halt or reset signal to the host processor (e.g., host processor 102 of
Process 300 may begin with the generation of public/private key pairs [act 302]. Act 302 may be undertaken by utilizing well known Public Key Infrastructure (PKI) techniques, such as the Rivest, Shamir, and Adelman (RSA) digital signature algorithm (DSA). For example, a manufacturer of system 100/200 may use PKI techniques to procure public/private key pairs. Process 300 may then continue with the storage of the public keys [act 304]. In some implementations of the invention, the manufacturer of system 100 may have processor 102 undertake act 304 by placing the public key of the public/private key pair generated in act 302 in OTP 206 of CM 202.
Process 300 may continue with the generation of a root key [act 306]. In some implementations of the invention this may be done by the manufacturer of system 100/200 having processor 104 store a previously generated root key in OTP 206. Once stored within CM 202 the root key may not, in accordance with some implementations of the invention, be visible and/or accessible to application 220 and/or other software executing on system 100/200 and/or external devices and/or systems through interfaces to system 100/200 such as Joint Test Action Group (JTAG) interfaces (not shown).
Process 300 may continue with the configuration of the limiter module for a first or initial mode [act 308].
In some implementations of the invention, act 402 may be undertaken by having application 220 assemble data in the form of a configuration payload although the invention is not limited in this regard and act 402 may be undertaken ahead of time by another application. In accordance with act 308, the configuration payload may be designed to place LM 214 in a first mode where that mode may be, for example, a manufacture mode permitting a manufacturer of system 100/200 to have CE 210 undertake cryptographic processing in response to requests from a manufacturing validation application, such as application 220.
Process 400 may continue with signing of the configuration payload [act 404]. One way to do this is to have application 220 use portions of system 100/200, the manufacturer's private key of one of the key pairs generated in act 302, and well known PKI techniques to sign the payload generated in act 402. That signed payload may then be provided to the cryptographic module [act 406]. In some implementations, application 220 may use portions of system 100/200 (e.g., processor 102 and pathway 110) to convey the signed configuration payload to CM 202. Process 400 may then continue with the verification of the signature of the signed payload [act 408]. One way act 408 may be undertaken is to have configuration unit 216 of LM 214 use CE 210 and well known PKI techniques to verify the signed payload using the public key, stored in OTP 206, of the key pair corresponding to the private key used to sign the configuration payload in act 404.
Once verified as a valid configuration payload, process 400 may continue with the configuration of the limiter [act 410]. In some implementations, configuration unit 216 may respond to the contents of the configuration payload verified in act 408 by setting operation counter 218 with a specific initial or first operational count or limit. For example, the configuration payload may specify a limit to the number of cryptographic operations (i.e., encryption or decryption) that CE 210 may undertake. The configuration payload may also specify a time interval over which CE 210 may undertake cryptographic operations.
In response to that initial or first operation count or limit set or configured in act 410, LM 214 may use counter 218 to control the number of cryptographic operations that CE 210 may undertake in the first mode. Thus, for example, process 400 as an implementation of act 308 may result in CE 210 being limited to a specific number of cryptographic operations that CE 210 may undertake in response to requests from application 220. In other words, act 308 may result in CM 202 being capable of generating storage keys so that CE 210 may use the storage keys to encrypt secrets and to encrypt data with the secrets as many times a needed to support the manufacturing of system 100/200.
Returning to
Process 300 may then proceed with a determination of whether to exit the initial or first mode [act 316]. In some implementations, an application, such as application 220, may undertake the determination in act 316 and if the result of that determination is negative (i.e., that system 100/200 should remain in the first or initial mode) then acts 310-314 may repeat using a newly generated storage key and newly provided secrets or data.
If the result of act 316 is positive, in other words if the determination is to leave the initial or first mode, then process 300 may continue with the configuration of the limiter for a run-time or second mode [act 318]. Act 318 is similar to act 308 except that a different configuration payload is generated and used to configure the limiter. Thus, referring again to process 400 of
Process 300 may continue with the generation of a storage key [act 320], the encryption of a secret [act 322] with that storage key and/or encryption of data [act 324] with the secret. Acts 320-324 are similar to acts 310-314 except that acts 320-324 are undertaken using a newly generated storage key and a newly provided secret and/or data generated by and/or provided to CE 210 while CM 202 is operating in the second or run-time mode implemented by act 318. The description of acts 310-314 provided above may be referred to for further details of acts 320-324.
Process 300 may continue with a determination of whether the operational limit has been reached [act 326]. In some implementations, LM 214 may determine that CE 210 has undertaken sufficient cryptographic operations when counter 218 reaches the second or run-time limit that was set or configured in act 318. If the determination of act 326 is positive, that is, if, for example, counter 218 reaches the run-time limit, then a rest, halt and/or disable may be undertaken [act 328] as specified by the configuration payload provided in act 318. One way to do this may be to have LM 214 issue a disable signal preventing CE 210 from undertaking additional cryptographic operations. In other implementations, when CE 210 has reached the second or run-time limit LM 214 may issue a reset or halt or similar signal preventing processor 102 and/or other components of system 100 from continuing to operate thereby preventing CE 210 from undertaking cryptographic operations.
Process 300 may continue with a determination of whether to reconfigure the limiter [act 330]. While
Process 300 may then continue with the configuration of the limiter for a new mode [act 332]. Act 332 is similar to acts 308 and 318 except that a different configuration payload is generated and used to configure the limiter. Thus, referring again to process 400 of
In some implementations, act 332 may be undertaken by an application, such as application 220, to revoke or change the storage keys or secrets by reconfiguring LM 214 with a new configuration payload that is digitally signed by the private key of the manufacturer of system 100/200. Thus, configuration unit 216 may verify the signature of the configuration payload using the manufacturer's public key stored in OTP 206 and then change its operating parameters to permit field re-programmability of previous encrypted storage keys and/or secrets. Thus, for example, a manufacturer of system 100/200 may use act 332 to configure CM 202 so that CE 210 undertakes only a limited number of cryptographic operations as needed by system 100/200 in a new operation mode.
While processes 300 and 400 have been described with respect to system 100/200 and CM 202 and components thereof, those skilled in the art will recognize that processes 300 and 400 can be implemented in the context of any device or system in order to limit misuse of that device or system's cryptographic engines against brute force attacks in accordance with the invention. Clearly, many schemes other than processes 300 and 400 may be implemented consistent with the scope and spirit of the invention. For example, in various implementations of the inventions the configuration payloads provided in acts 308, 318 or 332 may all specify different cryptographic operational limits or controls. Moreover, as discussed above with respect to act 308, configuration payloads in accordance with some implementations of the invention may specify a particular time interval over which a CE may undertake cryptographic operations. As those skilled in the art will recognize, the exact scheme employed may depend upon such things as the architecture used to implement processes such as process 300, memory constraints within such architectures etc. However, the structural details of such schemes are not limiting on the invention.
The acts shown in
While the foregoing description of one or more instantiations consistent with the claimed invention provides illustration and description of the invention it is not intended to be exhaustive or to limit the scope of the invention to the particular implementations disclosed. Clearly, modifications and variations are possible in light of the above teachings or may be acquired from practice of various implementations of the invention. Clearly, many other implementations may be employed to provide for enhancing cryptographic engines against attack consistent with the invention.
No device, element, act, data type, instruction etc. set forth in the description of the present application should be construed as critical or essential to the invention unless explicitly described as such. Also, as used herein, the article “a” is intended to include one or more items. Moreover, when terms or phrases such as “coupled” or “responsive” or “in communication with” are used herein or in the claims that follow, these terms are meant to be interpreted broadly. For example, the phrase “coupled to” may refer to being communicatively, electrically and/or operatively coupled as appropriate for the context in which the phrase is used. Variations and modifications may be made to the above-described implementation(s) of the claimed invention without departing substantially from the spirit and principles of the invention. All such modifications and variations are intended to be included herein within the scope of this disclosure and protected by the following claims.