Abstract:
Cryptographic apparatus having corresponding methods and computer-readable media comprise: a mailbox memory module to store cryptographic commands received from a client over a client bus, wherein the client is external to the cryptographic apparatus; and a secure processor to obtain the cryptographic commands from the mailbox memory module over a first secure internal bus, execute the cryptographic commands, and store a status of execution of the cryptographic commands in the mailbox memory module over the first secure internal bus, wherein the client obtains the status of the cryptographic commands from the mailbox memory module over the client bus.

Description:
CROSS-REFERENCE TO RELATED APPLICATIONS 
     This disclosure claims the benefit of U.S. Provisional Patent Application Ser. No. 61/289,884, entitled “Base Crypto Module FW Architecture,” filed on Dec. 23, 2009, the disclosure thereof incorporated by reference herein in its entirety. 
    
    
     FIELD 
     The present disclosure relates generally to cryptography. More particularly, the present disclosure relates to a cryptographic module with a secure processor. 
     BACKGROUND 
     Cryptography has enjoyed tremendous success in securing electronic data communications. Recently, cryptography has been used to secure stored data as well. For example, secure hard drives, referred to as “self-encrypting drives,” are now commercially available. Such drives include a cryptographic module to encrypt data using a cryptographic key before it is stored on the drive, and to decrypt the data using the key on retrieval. If a computer or drive is stolen, the thief cannot access the data stored on the drive without the cryptographic key. 
     However, current self-encrypting drives have several flaws that compromise their security. For example, the cryptographic key, which is stored in the drive, can be obtained by a skilled hacker, allowing the hacker to access the data on the drive. As another example, a hacker can cause the drive to download and execute malware, which can provide access to the stored data. 
     SUMMARY 
     In general, in one aspect, an embodiment features a cryptographic apparatus comprising: a mailbox memory module to store cryptographic commands received from a client over a client bus, wherein the client is external to the cryptographic apparatus; and a secure processor to obtain the cryptographic commands from the mailbox memory module over a first secure internal bus, execute the cryptographic commands, and store a status of execution of the cryptographic commands in the mailbox memory module over the first secure internal bus, wherein the client obtains the status of the cryptographic commands from the mailbox memory module over the client bus. 
     In general, in one aspect, an embodiment features computer-readable media embodying instructions executable by a processor to perform a method comprising: obtaining cryptographic commands from a mailbox memory module over a first secure internal bus, wherein the cryptographic commands are stored in the mailbox memory module over a client bus by a client; executing the cryptographic commands; and storing a status of execution of the cryptographic commands in the mailbox memory module over the first secure internal bus, wherein the client obtains the status of the cryptographic commands from the mailbox memory module over the client bus. 
     In general, in one aspect, an embodiment features a method comprising: obtaining cryptographic commands from a mailbox memory module over a first secure internal bus, wherein the cryptographic commands are stored in the mailbox memory module over a client bus by a client; executing the cryptographic commands; and storing a status of execution of the cryptographic commands in the mailbox memory module over the first secure internal bus, wherein the client obtains the status of the cryptographic commands from the mailbox memory module over the client bus. 
     The details of one or more implementations are set forth in the accompanying drawings and the description below. Other features will be apparent from the description and drawings, and from the claims. 
    
    
     
       DESCRIPTION OF DRAWINGS 
         FIG. 1  shows elements of a cryptographic system according to one embodiment. 
         FIG. 2  shows a process for the cryptographic system of  FIG. 1  according to one embodiment. 
         FIG. 3  shows an implementation according to one embodiment. 
     
    
    
     The leading digit(s) of each reference numeral used in this specification indicates the number of the drawing in which the reference numeral first appears. 
     DETAILED DESCRIPTION 
     Embodiments of the present disclosure provide elements of a cryptographic module with a secure processor. The cryptographic module includes elements that isolate the secure processor within the cryptographic module. For example, when incorporated in a self-encrypting hard drive, the secure processor is isolated from the drive firmware and host processor, thereby isolating cryptographic functions from the servo functions of the drive. Embodiments also include a secure memory that cannot be accessed by the host processor or host operating system. Therefore cryptographic keys and other data stored in the secure memory cannot be accessed from outside the cryptographic module. 
       FIG. 1  shows elements of a cryptographic system  100  according to one embodiment. Although in the described embodiments the elements of cryptographic system  100  are presented in one arrangement, other embodiments may feature other arrangements. For example, elements of cryptographic system  100  can be implemented in hardware, software, or combinations thereof. In some embodiments, cryptographic module  108  is compliant with the 140 series of Federal Information Processing Standards (FIPS), including at least one of FIPS 140-2 and FIPS 140-3. 
     Referring to  FIG. 1 , cryptographic system  100  includes a cryptographic device  102  in communication with a channel  104 . Channel  104  can be implemented as a storage device, a communications channel, or the like. For example, cryptographic system  100  can be implemented as a self-encrypting drive, and channel  104  can be implemented as a hard drive. As another example, cryptographic system  100  can be implemented as a mobile phone or set-top box, and channel  104  can be implemented as a wireless or wired communications channel. 
     Cryptographic device  102  includes a system-on-chip (SoC)  106  that includes a cryptographic module  108  in communication with a client  110  and an external memory  112  over a client bus  114 . Cryptographic module  108  includes a secure processor  116 , a mailbox memory  118 , a cryptographic engine  120 , a direct memory access (DMA) module  122 , a trust status register (TSR)  124 , and a one-time-programmable (OTP) memory  126  to store one or more cryptographic keys  128 . OTP memory  126  can also store system secrets as well as system lifecycle parameters that need to persist across power cycles. The contents of OTP memory  126  can be made to be accessible to, and modifiable by, only secure processor  116 . Cryptographic module  108  also includes a secure processor bus  130  for secure communication between secure processor  116  and mailbox memory  118 , and a secure memory bus  132  for secure communication between cryptographic engine  120  and DMA module  122 . Secure processor  116  includes a processor memory  134  to store processor instructions and data. Cryptographic engine  120  includes a scratch-pad memory  136  for storage of intermediate variables and the like. 
     Mailbox memory  118  is used to isolate secure processor  116  from external elements such as client  110 . Client  110  and secure processor  116  do not communicate directly. Client  110  stores cryptographic commands  140  in mailbox memory  118  over client bus  114 . Secure processor  116  obtains cryptographic commands  140  from mailbox memory  118  over secure processor bus  130 . Secure processor  116  stores status  144  of cryptographic commands  140  in mailbox memory  118  over secure processor bus  130 . Client  110  obtains status  144  from mailbox memory  118  over client bus  114 . 
     In addition to a secure processor  116 , cryptographic module  108  also includes secure memory that is not accessible from outside cryptographic module  108 . This secure memory includes OTP memory  126 , processor memory  134 , and scratch-pad memory  136 . 
     DMA module  122  exchanges input text  138  and output text  146  with external memory over client bus  114 , and exchanges text  138  and  146  with cryptographic engine  120  over secure memory bus  132 , in accordance with cryptographic commands  140  received from client  110 . As used herein, the term “text” refers to plaintext and/or ciphertext. In some applications the text can include cryptographic keys. The keys can be stored in non-volatile memory inside or outside of cryptographic device  102 , in wrapped form. Wrapped keys are keys that are themselves encrypted by another key at a higher hierarchical level in the security architecture. With the capability to import and export keys into and out of cryptographic module  108 , the system can operate with a much larger set of keys than that allowed by the size of OTP memory  126 . 
     Cryptographic engine  120  encrypts the plaintext, and decrypts the ciphertext, in accordance with cryptographic commands  140  and cryptographic keys  128 , which can include symmetric and asymmetric keys. Cryptographic commands  140  include primitive instructions  142 . Cryptographic engine  120  executes primitive instructions  142  conditionally in accordance with contents of trust status register  124 . For example, the primitive instructions can have an in-built tag within the command itself. An embodiment of this tag can be a 32-bit value (or longer) that is pre-configured to reflect the operational conditions under which the instruction is allowable. Before executing a primitive instruction, secure processor  116  checks this in-built tag against trust status register  124  to ensure that the primitive instruction is allowable under the current security configuration or state. 
     In some embodiments, cryptographic module  108  includes a random bits generation engine. Together with the firmware program run by secure processor  116 , random numbers can be generated that are suitable for use as keys for various cryptographic purposes including data encryption, digital signature, and the like. Also dependent on the secure processor program, these random number numbers can be FIPS compliant. 
       FIG. 2  shows a process  200  for cryptographic system  100  of  FIG. 1  according to one embodiment. Although in the described embodiments the elements of process  200  are presented in one arrangement, other embodiments may feature other arrangements. For example, in various embodiments, some or all of the steps of process  200  can be executed in a different order, concurrently, and the like. In some embodiments, process  200  is compliant with the 140 series of Federal Information Processing Standards (FIPS), including at least one of FIPS 140-2 and FIPS 140-3, FIPS operation can be indicated when a configuration bit is set in secure memory, such as OTP memory  126 . 
     Referring to  FIG. 2 , at  202  client  110  stores one or more cryptographic commands  140  in mailbox memory  118  over client bus  114 . At  204 , secure processor  116  obtains cryptographic commands  140  from mailbox memory  118  over secure processor bus  130 . At  206 , secure processor  116  executes cryptographic commands  140 . Cryptographic commands  140  include primitive instructions  142 . At  208  secure processor  116  sends primitive instructions  142  to cryptographic engine  120 . 
     At  210  and  212 , secure processor  116  causes DMA module  122  to transfer input text  138  from external memory  112  to cryptographic engine  120  over secure memory bus  132  and client bus  114 . At  214 , cryptographic engine  120  obtains one or more cryptographic keys  128  from OTP memory  126 . At  216 , cryptographic engine  120  executes primitive instructions  142  conditionally in accordance with the contents of trust status register  124  using cryptographic key(s)  128  upon input text  138 , thereby producing output text  146 . The contents of trust status register  124  reflect the current security configuration, operational status of cryptographic module  108  and other factors. For example, in FIPS-compliant embodiments, the security configuration bits can indicate the current FIPS mode. The operational status bits can indicate power states, initialization states, operational states, error states, sleep states, and the like. Trust status register  124  also includes programmable reserved bits. 
     After executing cryptographic commands  140 , cryptographic module  108  provides output text  146  and status  144 . In particular, At  218  and  220 , secure processor  116  causes DMA module  122  to transfer output text  146  from cryptographic engine  120  to external memory  112  over secure memory bus  132  and client bus  114 . At  222  cryptographic engine  120  provides status  144  to secure processor  116 . At  224  secure processor  116  stores status  144  in mailbox memory  118  over secure processor bus  130 . At  226 , client  110  obtains status  144  from mailbox memory  118  over client bus  114 . 
       FIG. 3  shows an implementation  300  according to one embodiment. Although in the described embodiments the elements of implementation  300  are presented in one arrangement, other embodiments may feature other arrangements. For example, elements of implementation  300  can be implemented in hardware, software, or combinations thereof. In some embodiments, implementation  300  is compliant with the 140 series of Federal Information Processing Standards (FIPS), including at least one of FIPS 140-2 and FIPS 140-3. 
     Referring to  FIG. 3 , implementation  300  includes a cryptographic module  308  in communication with a SoC CPU  330 , an external memory controller  332 , and a fuse module  334 . Cryptographic module  308  includes a DMA controller  322 , a cryptographic engine  320 , a secure processor  316 , a bus adapter  338 , a bus interface unit (BIU)  340 , and an Advanced Peripheral Bus (APB) bus controller  342  to control an APB bus  344 A. SoC CPU  330  and bus adapter  338  include an Advanced eXtensible Interface (AXI) master  346  and an AXI slave  348 , respectively, for communication over an AXI bus  350 A. DMA controller  322  includes an AXI master  346  for communication over an AXI bus  350 B. In some embodiments, cryptographic module  108  is configured to include an Advanced High-performance Bus (AHB) interface in place of the AXI interface. This configuration allows easy interface to SoCs having an AHB system bus. Fuse module  334  includes an OTP fuse bank  352  and an APB slave  358  for communication over APB bus  344 A. Cryptographic module  308  also includes 
     Bus adapter  338  and BIU  340  include an APB master  356  and an APB slave  358 , respectively, for communication over an APB bus  344 B. Bus adapter  338  also includes an input FIFO  360 . 
     Secure processor  316  includes an ARM processor  362 , a secure JTAG controller  364 , a boot ROM  366 , and a RAM  368  for code and data. Secure processor  316  includes an AHB master  356  for communication with ROM  366  and RAM  368  over an AHB bus  344 C and an AHB slave  358 . Secure processor  316  also includes an AHB master  370  for communication with BIU  340  over an AHB bus  374 . Secure JTAG controller  364  manages the JTAG access mode to cryptographic module  308  for supporting a comprehensive test infrastructure that permits silicon circuit testing, and software debugging, at the device development phase. To support troubleshooting for a failed device during the device deployment phase, secure JTAG controller  364  employs a challenge/response Public Key Infrastructure (PKI) based secure protocol for eliminating the device key residing in OTP fuse bank  352  of cryptographic module  308 , and granting the JTAG access to the test/debugger equipment. 
     BIU  340  includes an AHB slave  372  for communication over AHB bus  374 , and an APB master  356  for communication over APB bus  344 A. BIU  340  also includes a mailbox FIFO  376  to isolate secure processor  316 . The security boundary is shown as a dashed line at  302 . 
     Cryptographic engine  320  includes a plurality of cryptographic accelerators  382 , a scratch-pad memory  384 , and an ABUS controller  378  to control an internal ABUS  380 . Each of cryptographic accelerators  382  and scratch-pad memory  384  has a respective ABUS interface  386  for communication with ABUS  380 . Each of ABUS controller  378 , cryptographic accelerators  382 , and scratch-pad memory  384  has a respective APB slave  358  for communication with APB bus  344 A. ABUS  380  is a flexible bus structure allowing different cryptographic accelerators  382  and DMA controller  322  to be connected in different combinations. This allows for creation of composite cryptographic algorithms. One example is an AES-HASH composite algorithm. Additional engines can be added to ABUS  380  to support data rights management engines. One example is adding controller chips for set-top box applications. Additional engines may include one or a multitude of integrity check engines that support message authentication functionality. Cryptographic module  108  can also be configured to control engines outside of security boundary  302 , such as the loading of keys into those engines, thereby acting as a gate to control authorized access and usage of those engines. 
     DMA controller  322  includes an ABUS interface  386  for communication with ABUS  380 , an AXI master  346  for communication with external memory controller  332  over AXI bus  350 B, and an APB slave  358  for communication with APB bus  344 A. DMA controller  322  also includes an input FIFO  388  and an output FIFO  390 . 
     Various embodiments also provide the ability to load and execute signed memory overlays from an external source. These overlays can be used for testing and customizing operations for a given application. For example, these overlays can be used to patch defects in mask-programmed ROMs, add custom primitives for simulation and test, and providing complete solutions in self-contained, digitally-signed packages. 
     For example, various embodiments can include a mask-programmed ROM, programmed with a certain set of firmware. This firmware builds in SRAM a table, consisting of a set of pointers to functions contained in ROM. These functions form the basis for primitives and various, layered support services for these primitives. Such embodiments are capable of RSA cryptography. An overlay, conforming to a set of guidelines, may be compiled, linked and digitally signed with a private key. Using a primitive, this overlay may be loaded and authenticated with the public key corresponding to the private key. If this overlay authenticates with the given credentials, control within cryptographic module  108  is shifted to the overlay. This overlay, with the knowledge of where the table of pointers is located in SRAM, may augment, replace, enhance, or modify the existing mask-programmed firmware contained in the cryptographic module  108 , by simply replacing these pointers, with ones pointing to replacement functions contained in the overlay itself. This ROM/overlay combination may be unique to a specific application. 
     Various embodiments of the present disclosure can be implemented in digital electronic circuitry, or in computer hardware, firmware, software, or in combinations thereof. Embodiments of the present disclosure can be implemented in a computer program product tangibly embodied in a computer-readable storage device for execution by a programmable processor. The described processes can be performed by a programmable processor executing a program of instructions to perform functions by operating on input data and generating output. Embodiments of the present disclosure can be implemented in one or more computer programs that are executable on a programmable system including at least one programmable processor coupled to receive data and instructions from, and to transmit data and instructions to, a data storage system, at least one input device, and at least one output device. Each computer program can be implemented in a high-level procedural or object-oriented programming language, or in assembly or machine language if desired; and in any case, the language can be a compiled or interpreted language. Suitable processors include, by way of example, both general and special purpose microprocessors. Generally, processors receive instructions and data from a read-only memory and/or a random access memory. Generally, a computer includes one or more mass storage devices for storing data files. Such devices include magnetic disks, such as internal hard disks and removable disks, magneto-optical disks; optical disks, and solid-state disks. Storage devices suitable for tangibly embodying computer program instructions and data include all forms of non-volatile memory, including by way of example semiconductor memory devices, such as EPROM, EEPROM, and flash memory devices; magnetic disks such as internal hard disks and removable disks; magneto-optical disks; and CD-ROM disks. Any of the foregoing can be supplemented by, or incorporated in, ASICs (application-specific integrated circuits). 
     A number of implementations have been described. Nevertheless, various modifications may be made without departing from the scope of the disclosure. Accordingly, other implementations are within the scope of the following claims.