Hardware-generated key encryption

Abstract

To provide a method and an apparatus that allow for per-file encryption and decryption of files stored in a flash storage within a mobile device with a hardware-generated encryption key.SOLUTION: In a system-on-chip of a mobile device, a hardware key manager provides an unlimited number of child keys generated from one or more base keys to which a nonce is applied, and communicates the child keys to a host controller interface via a first bus. Software on the mobile device does not have access to values of the child keys. A flash storage driver communicates commands to the host controller interface via a second bus, and the host controller interface includes a crypto engine that utilizes the child keys to encrypt data written to or decrypt data read from the flash storage.SELECTED DRAWING: Figure 2

Description

[Background technology]

[0001] It is estimated that nearly 80% of the world's population owns a mobile phone, a type of mobile device. Mobile devices typically include a system-on-chip (SoC), which is the brain of the mobile device. The SoC includes various components, such as a central processor, memory, a graphics processor, an audio processor, high-speed input and output line interfaces, and an encryption engine. A mobile device may also include flash storage, also referred to herein as a flash storage device, located outside the SoC. Flash storage is used to store user data, such as photos and emails, on the mobile device. Encrypting data stored on a mobile device for security purposes is standard practice. As the performance of memory devices continues to improve, it is becoming increasingly important to speed up the cryptographic process (e.g., encryption and decryption) of data on a mobile device to ensure efficient performance. Inline encryption on the SoC enables efficient encryption of data as it is written to flash storage, and similarly, enables efficient decryption of data on the SoC as it is read from flash storage to the SoC. However, performing inline cryptographic operations in an efficient manner can be challenging.

[0002] The SoC of a mobile device typically includes a host controller interface located within the flash storage wrapper. The host controller interface communicates between the SoC and the flash storage. The host controller interface includes a crypto engine used by the SoC to encrypt data being written to the flash storage as well as decrypt data being read from the flash storage. Mobile device manufacturers often use an off-the-shelf third-party flash storage controller as the host controller interface within the flash storage wrapper. In many cases, the third-party provider does not offer any customization of this controller. Summary of the Invention

[0003] This document describes the use of hardware-generated keys to provide per-file encryption. This document details how the hardware key manager of the present disclosure can be configured to provide an infinite or unlimited number of keys generated from one or more base keys. The base keys are located on a hardware key manager, which is located on the SoC of a mobile device. To provide per-file encryption, this document describes implementations that enable hardware generation of an unlimited number of encryption keys. This allows inline encryption using different keys to perform per-file encryption. The hardware key manager may generate an unlimited number of child keys. Each child key is generated as a result of applying a nonce, also referred to herein as fine-tuning, to one of the base keys located on the hardware key manager. Even if the hardware key manager contains only a single base key, an unlimited number of child keys can still be generated by the hardware key manager because the nonce can be varied in an infinite number of ways. The hardware-generated child keys can then be used by a host controller interface in the flash storage wrapper to encrypt or decrypt files.

[0004] This document details how an off-the-shelf, third-party flash storage controller can be used as a host controller interface to provide file-based encryption using hardware-generated keys. A bus, also referred to herein as a communication line, is added to the off-the-shelf, third-party flash storage controller to enable communication from a hardware key manager to the off-the-shelf, third-party flash storage controller. The term bus includes communication lines, input lines, output lines, electrical wires, electrical buses, energy buses, etc. The hardware key manager generates hardware keys used by the off-the-shelf, third-party flash storage controller to encrypt and / or decrypt data. A flash memory driver sends a request to use the key with a cryptographic engine on the off-the-shelf, third-party flash storage controller. However, neither the flash memory driver nor the off-the-shelf, third-party flash storage controller has access to the value of the encryption key generated by the hardware key manager.

[0005] This document details how a hardware key manager can be configured to generate an infinite or unlimited number of child keys from a single base key or from a set of base keys. The hardware key manager uses a fine-tuning, or nonce, applied to the base key, also called a parent key, to generate the child keys. This document details that the generated child keys are stored in a key table in the host controller interface. A cryptographic engine in the host controller interface accesses the child keys from the key table to encrypt or decrypt data on the mobile device using the child keys generated by the hardware key manager.

[0006] The flash storage wrapper includes two buses, also referred to herein as communication lines, for communicating with a host controller interface, which may be an off-the-shelf third-party flash storage controller located within the flash storage wrapper. This document details that the first bus of the flash storage wrapper is used to pass hardware-generated keys from a hardware key manager to the host controller interface. In some implementations, the hardware key manager can use the first bus to communicate child keys to the host controller interface of the flash storage wrapper, and other components (e.g., software) can be excluded from using the first bus. If the first bus is accessible only by the hardware key manager, software on the mobile device is prevented from having access to the values ​​of the hardware-generated keys. The second bus of the flash storage wrapper is used to communicate software memory commands from the flash storage driver to the host controller interface. The software memory commands are used to instruct the host controller interface not only on which data needs to be stored in or read from flash storage, but also on which encryption keys the cryptographic engine needs to use during cryptographic operations. The software memory commands are sent from the flash storage driver to the host controller interface based on commands from higher-level software, such as the mobile device's operating system.

[0007] In an exemplary embodiment, a method includes receiving, at a flash storage wrapper, a first child key from hardware via a first bus, the first child key being generated from a base key by a hardware key manager in the hardware; the method further includes receiving, at the flash storage wrapper, a memory command from a flash storage driver via a second bus; the method further includes, at the flash storage wrapper, encrypting a file using the first child key in accordance with the memory command and directing writing of the encrypted file to a location based on the memory command received from the flash storage driver of the flash storage device; or the method further includes, at the flash storage wrapper, reading a file at a location based on the memory command received from the flash storage driver on the flash storage device and decrypting the file using the first child key in accordance with the memory command.

[0008] In an exemplary embodiment, an apparatus includes a first bus configured to receive communications from hardware, a second bus configured to receive communications from software, and an arbiter connected to the first bus and the second bus. The arbiter includes an output line. The apparatus includes a host controller interface having a communication line connected to the output line of the arbiter. The host controller interface includes a first cryptographic engine and a key table. The key table includes a hardware-generated key, and the first cryptographic engine is configured to use the hardware-generated key to encrypt or decrypt files.

[0009] In an exemplary implementation, a method includes generating a child key from a base key at a hardware key manager. The method includes transmitting the child key from the hardware key manager to a flash storage wrapper on a first bus. The method includes receiving a memory command at the flash storage wrapper on a second bus from a flash storage driver. The method includes using the child key at the flash storage wrapper to encrypt or decrypt a file. The method includes writing the encrypted file to a location on the flash storage device or reading the decrypted file from the location based on the memory command.

[0010] In an exemplary embodiment, a system includes a flash storage device and a flash storage wrapper in communication with the flash storage device. The flash storage wrapper includes a first key table having a plurality of keys and a plurality of key slots. Each key of the plurality of keys corresponds to one slot of the plurality of key slots. The system includes a hardware key manager in communication with the flash storage wrapper via a first bus. The system includes a flash storage driver in communication with the flash storage wrapper via a second bus and with the hardware key manager via a third bus.

[0011] Apparatus and techniques for providing hardware-generated key encryption are described with reference to the following drawings, in which like numbers are used to reference like features and components throughout. [Brief explanation of the drawings]

[0012] [Figure 1] 1 illustrates an exemplary device with an SoC including a hardware key manager and a flash storage wrapper that can execute per-file storage encryption instructions. [Figure 2]1 illustrates an exemplary device that includes a host controller interface, which may be an off-the-shelf third-party flash storage controller that can perform per-file storage encryption instructions with a hardware-generated key. [Figure 3] 1 shows a schematic diagram of an exemplary hardware key manager that receives a nonce and generates a child key in response to the received nonce. [Figure 4] 1 illustrates an exemplary system in which per-file storage encryption with hardware-generated keys can be performed by input / output (I / O) commands sent from high-level software to a flash storage driver. [Figure 4-1] 5 illustrates the example system of FIG. 4 in which key information is sent from a flash storage driver to a hardware key manager, child keys are sent from the hardware key manager to a flash storage wrapper on a first bus, and I / O information is sent from the flash storage driver to the flash storage wrapper on a second bus. [Figure 4-2] 4-1 illustrates the example system in which a read or write command is sent from the flash storage wrapper to the flash storage device. [Figure 5] 1 is a flowchart illustrating an exemplary process for using a hardware key for storage encryption. [Figure 6] 1 is a flowchart illustrating an exemplary process for using a hardware key for storage encryption. [Figure 7] 1 is a flowchart illustrating an exemplary process for generating child keys from a base key. DETAILED DESCRIPTION OF THE INVENTION

[0013] overview Mobile devices make important contributions to modern society, including those related to communications, security, manufacturing, and content creation. A mobile device includes an SoC (SoC), which is the device's brain, and flash storage external to the SoC. The flash storage is used to store user data on the mobile device. The SoC provides an inline encryption process as data is written to and read from the mobile device's flash storage. Various aspects of mobile devices comply with standards approved by the Joint Electron Device Engineering Council (JEDEC) Solid State Technology, an independent semiconductor industry association and standards body. JEDEC has an approved standard for inline encryption and decryption that governs the encryption process used in mobile devices. The JEDEC inline encryption standard (JEDEC Universal Flash Storage Host Controller Interface "UFSHIC") allows third-party companies to manufacture compliant host controller interfaces so that the host controller interfaces can be used in mobile devices from various manufacturers.

[0014] Previously, full-disk encryption was used to encrypt data on flash storage. Full-disk encryption uses a single key to encrypt all stored data. To improve security, file-based encryption may be used instead of full-disk encryption. File-based encryption allows various files stored on flash storage to be encrypted with different keys. For example, one encryption key may be used to encrypt personal data, and a different encryption key may be used to encrypt work data. As another example, one encryption key may be used to encrypt data read when unlocking a mobile device, and a different encryption key may be used to encrypt text messages received when locking the mobile device. File-by-file encryption of flash storage provides greater security in the event that a malicious actor (e.g., a “hacker”) determines the value of an encryption key. If file-by-file encryption is used for data on a flash storage device, a hacker only has access to data encrypted with a compromised encryption key and does not have access to any other data encrypted with a different encryption key.

[0015] Manufacturers of SoCs for mobile devices often use off-the-shelf, third-party flash storage controllers as the host controller interface in their flash storage wrappers, rather than creating their own host controller interface. Off-the-shelf means that the flash storage controller is purchased from a third party from existing inventory or supply sources, rather than being custom designed or fabricated. This is economically more efficient because the third party has already fabricated the circuitry that complies with applicable JEDEC standards and can interoperate with industry-standard flash storage devices. Off-the-shelf, third-party flash storage controllers typically perform per-file encryption. One potential problem with per-file encryption is that the host controller interface on the mobile device may require access to many different keys to efficiently perform per-file encryption or decryption. This document describes hardware and techniques that enable the use of many different keys to perform per-file encryption or decryption.

[0016] The host controller interface is located within a flash storage wrapper located on the mobile device's SoC. The host controller interface includes a key table with a finite number of keys in the key table. Keys from the key table are used by a cryptographic engine within the host controller interface to cryptographically process files or data within the mobile device. Typically, the key table includes 16 or 32 key slots, but may include a greater or lesser number of keys depending on the application. The relatively small finite number of available keys in the key table may make it impractical for the cryptographic engine of the host controller interface to efficiently perform per-file encryption. This is because the host controller interface, and specifically the cryptographic engine, may not have access to enough keys at one time to efficiently perform per-file encryption on a large set of files or file categories. If there are not enough keys available for efficient per-file encryption, the cryptographic engine of the host controller interface may need to wait for software on the mobile device to continuously reprogram the key table to make an appropriate number of keys available to the cryptographic engine. Reprogramming the key table may result in an unacceptable lag or delay during the encryption process of a large set of files. This document describes hardware and techniques that allow for the use of multiple different keys to reduce or eliminate unacceptable lag or delay due to key table reprogramming.

[0017] The SoC is essential to the security of a mobile device. In other words, the components and data that reside within the SoC are generally considered secure. As mobile devices become more complex, they contain more and more software. The greater the amount of software on a mobile device, the greater the number of possible vulnerabilities through which the mobile device may be accessed for criminal purposes. Any software that resides outside the SoC boundary is typically considered a potential access point that may be susceptible to malicious activity.

[0018] To provide security, user data on a mobile device that is stored in flash storage can be encrypted. The host controller interface, which is often an off-the-shelf third-party flash storage controller, is located on the SoC, but currently, software on the mobile device programs keys in a key table of the host controller interface. As such, in current mobile devices, the software on the mobile device has access to the encryption key values ​​used to encrypt user data on the flash storage device within the mobile device. As described herein, software with access to the encryption key values ​​may be susceptible to malicious activity. If the encryption key values ​​are obtained, the malicious activity may be able to access and decrypt some (if not all) of the user's data on the mobile device, depending on the number of keys obtained by the malicious activity. This document describes hardware and techniques for creating hardware-generated keys for file or data encryption that are less vulnerable than software-generated encryption keys.

[0019] This document details how a hardware key manager can be configured to provide an unlimited, or virtually unlimited, number of keys. To provide per-file encryption, this document describes an implementation that allows the use of an unlimited number of encryption child keys generated by the hardware key manager. The hardware-generated child keys allow for efficient in-line encryption with a different key for each file.

[0020] This document describes how an unlimited number of child keys may be generated by a hardware key manager from one or more base keys found in a base key table within the hardware key manager. Each child key generated by the hardware key manager is the result of applying a nonce, also referred to herein as a fine-tuning, to a base key located in the base key table found in the hardware key manager. The nonce applied to a base key may vary an infinite number of ways, potentially enabling the hardware key manager to generate an unlimited number of unique child keys. In this manner, the hardware key manager is configured to generate an unlimited number of child keys, even from a single base key, by applying different nonce(s) to the single base key. After the child keys are generated, the hardware key manager communicates the child keys to a host controller interface within the flash storage wrapper and stores them in a key table within the host controller interface. The crypto engine may then access the child keys from the key table for encryption or decryption on a per-file basis, as directed by the flash storage driver.

[0021] This document details that software on a mobile device has access to use hardware-generated encryption keys (also referred to herein as hardware-generated keys and child keys) in a flash storage wrapper during cryptographic processes, but the software does not have access to the values ​​of the hardware-generated keys. A hardware key manager of the present disclosure can generate the hardware-generated keys and prevent software from accessing the values ​​of the hardware-generated keys. In some implementations, the hardware key manager may be the only component on a mobile device that has access to the values ​​of the hardware-generated keys. Because the hardware key manager is located within the boundary of the SoC, it is much more vulnerable to potential malicious activity than the mobile device software or the flash storage device (both of which are located outside the security boundary of the SoC). The use of hardware-generated keys whose values ​​are known only to the hardware key manager located on the SoC, or whose values ​​have other limited accessibility, reduces the likelihood that malicious activity can access and decrypt user data stored on the flash storage device.

[0022] The off-the-shelf third-party flash storage controller is not configured to receive hardware-generated keys from a hardware key manager. This document describes a host controller interface located within a flash storage wrapper. The storage wrapper includes a first bus connected to the hardware key manager and a second bus for receiving software memory commands from a flash storage driver. The first bus from the hardware key manager can be used to extend the off-the-shelf third-party flash storage controller to enable the host controller interface to receive child keys from the hardware key manager. Furthermore, the firmware of the flash storage wrapper can be updated to include functionality for receiving hardware-generated encryption keys from the hardware key manager via the first bus.

[0023] This document details that only traffic on a first bus between the hardware key manager and the flash storage wrapper may pass hardware-generated child keys as described herein. A second bus to the flash storage wrapper enables memory communication between the flash storage driver and a host controller interface. The host controller interface receives I / O information and commands from the flash storage driver to the flash storage wrapper via the second bus.

[0024] Off-the-shelf third-party flash storage host controller interfaces are configured to receive communications over a single bus or communication line. Current interfaces to host controller interfaces are not configured to receive communications from two different buses or communication lines simultaneously. To address this limitation, this document describes an arbiter within a flash storage wrapper. The arbiter is connected to a first bus from a key hardware manager and a second bus connected to a flash storage driver. The arbiter has an output line connected to a configuration interface of a host controller interface within the flash storage wrapper. The arbiter arbitrates communications or signals between the first bus and the second bus and the configuration interface of the host controller interface so as to receive communications one at a time at the host controller interface. In other words, the configuration interface of the host controller interface is not configured to receive instructions from the first bus and the second bus simultaneously.

[0025] To prevent software-generated keys from being communicated to the host controller interface via the second bus, this document describes a controller in a flash storage wrapper, where the controller is disposed between a hardware key manager and an arbiter. The controller is connected from the hardware key manager to the first bus and from the flash storage driver to the second bus. The controller performs access control and key policy checks. The controller is configured to allow hardware-generated keys generated by the hardware key manager to be communicated to the host controller interface and to prevent software-generated keys from being communicated to the host controller interface.

[0026] As described herein, when an SoC performs file-by-file encryption, it may require a large set of encryption keys. This may require continuous reprogramming of the key table by the mobile device software that also generates the encryption keys, which may introduce undesirable lag during the encryption process. Furthermore, software-generated encryption keys may be potentially vulnerable to malicious activity. Hardware-generated encryption keys may be used to overcome these issues. However, off-the-shelf third-party flash storage controllers are not configured to receive hardware-generated keys from a hardware key manager, but rather are configured to receive communications from a single communication line. Potentially, the software-generated keys may still be communicated to a host controller interface in the flash storage wrapper via a second bus connected to the flash storage driver.

[0027] To overcome these problems, this document details a hardware key manager configured to generate a potentially unlimited number of keys that can be used by an SoC for per-file encryption. The hardware key manager creates hardware-generated encryption keys that are less vulnerable to malicious activity than software-generated encryption keys. This document details a flash storage wrapper that includes two buses, also referred to herein as communication lines, to allow the hardware-generated encryption keys to be passed from the hardware key manager to a host controller interface, which may be an off-the-shelf third-party controller, within the flash storage wrapper. This document describes an arbiter that arbitrates communications or signals between the first and second buses and a configuration interface of the host controller interface to receive communications one at a time at the host controller interface. This document details a controller configured to allow hardware-generated keys generated by the hardware key manager to be communicated to the host controller interface and to prevent software-generated keys from being communicated to the host controller interface. These and other embodiments are described herein.

[0028] Exemplary Environments and Electronic Devices 1 illustrates an exemplary environment 100 including a device 102. The device 102 may include a mobile phone, a smartphone, a smartwatch, a tablet, a laptop, a mobile computer, a handheld computer, a digital assistant, etc. The device 102 includes a SoC 104, which includes at least a processor 106, a memory 108, a hardware key manager 110, and a flash storage wrapper 120. The device 102 can use the components of the SoC 104 to execute instructions for hardware-generated key encryption of files or data in the memory 108 located on the SoC 104, which are stored on a flash storage device within the device 102. While the flash storage device is located within the device 102, the flash storage device is located external to the SoC 104. In an embodiment, the instructions are for using the hardware-generated encryption key to perform per-file encryption as described herein.

[0029] The hardware key manager 110 located on the SoC 104 is configured to generate encryption keys used for cryptographic operations (e.g., encryption or decryption) of files or data by the flash storage wrapper 120 within the device 102. The hardware key manager 110 is configured to create hardware-generated encryption keys as discussed herein.

[0030] In this example, device 102 is shown as a smartphone. However, device 102 may be implemented as any suitable computing or other electronic device. Examples of device 102 include a mobile electronic device or mobile device, a mobile communication device, a modem, a cellular or mobile telephone, a mobile station, a gaming device, a navigation device, a media or entertainment device (e.g., a media streamer or game controller), a laptop computer, a desktop computer, a tablet computer, a smart appliance, a vehicle-based electronic system, a wearable computing device (e.g., clothing, a watch, or reality-altering glasses), an Internet of Things (IoT) device, a sensor, an inventory control device, an electronic portion of a machine or electronic component of equipment (e.g., a vehicle or robot), a memory storage device (e.g., a solid-state drive (SSD)), a server computer or portion thereof (e.g., a server blade or rack or other portion of a data center), etc. Illustrated examples of devices 102 include a tablet device 102-1, a smart television 102-2, a desktop computer 102-3, a server computer 102-4, a smartwatch 102-5, a smartphone (or document reader) 102-6, and intelligent glasses 102-7.

[0031] In an exemplary embodiment, the device 102 includes an SoC 104, which is the brain of the device 102. The SoC 104 is typically a complex chip that includes several different components, such as a processor, memory, a cryptographic engine, and high-speed input and output lines. The SoC 104 typically includes a single integrated circuit. The integrated circuit can be part of or implemented as a chip, a package, a module, an assembly, or at least one printed circuit board (PCB) (not shown). Examples of PCBs include flexible PCBs, rigid PCBs, single-layer or multi-layer PCBs, surface-mount or through-hole PCBs, combinations thereof, etc. One or more integrated circuit (IC) chips can be implemented on the PCB. Each IC chip can be implemented as a general-purpose processor, a microcontroller, an application-specific IC (ASIC), etc. Other examples of IC chips include security-oriented IC chips, memory chips, communication IC chips (e.g., modems or radio frequency ICs), graphics processors, artificial intelligence (AI) accelerators, sensor chips, combinations thereof, etc. The sensor chip may include, for example, an accelerometer, a camera or other light sensor, a satellite positioning system (e.g., a Global Positioning System (GPS)) chip, etc. The integrated circuit chip can be packaged alone or together with other IC chips. While portions of this disclosure refer to utilizing techniques in combination with an SoC, the invention is not so limited. For example, the hardware key manager 110 and flash storage wrapper 120 described herein can be included in other circuitry, such as any integrated circuit or chip that accesses a flash storage device containing encrypted data.

[0032] Exemplary Devices, Systems, and Operational Schemes FIG. 2 illustrates, generally at 200, an exemplary flash storage wrapper 120 located on the SoC 104 of the mobile device 102. Components within the flash storage wrapper 120 may be used to encrypt data as it passes from the SoC 104 to the flash storage device 420 of the mobile device 102. Similarly, components within the flash storage wrapper 120 may be used to decrypt data as it is read from the flash storage device to the SoC 104. Because the flash storage wrapper 120 is located on the SoC 104, cryptographic processing (e.g., encryption or decryption) of files or data may be performed inline as the files or data move from the SoC 104 to the flash storage device or as they move from the flash storage device to the SoC 104. The flash storage wrapper 120 includes multiple communication lines, generally referred to as 202, to enable communication between various components within the flash storage wrapper 120. In some implementations, the flash storage wrapper 120 includes a first bus 204 configured to enable communication between the hardware key manager 110 and the host controller interface 210. The flash storage wrapper 120 includes a second bus 206 over which the host controller interface 210 is configured to receive I / O commands and / or I / O information, as further described herein.

[0033] The host controller interface 210 of the flash storage wrapper 120 communicates between the flash storage wrapper 120 and the flash storage device of the mobile device 102. The host controller interface 210 encrypts data being written to the flash storage device and decrypts data being read from the flash storage device, as described in detail herein. The host controller interface 210 may be an off-the-shelf third-party flash storage controller licensed by the SoC manufacturer from a third party. In other words, the host controller interface 210 may be provided by an entity other than the manufacturer of the mobile device 102, as discussed herein. The host controller interface 210 in the mobile device 102 is often an off-the-shelf third-party flash storage controller because the in-line encryption process is a standard set by JEDEC.

[0034] The host controller interface 210 includes a communication line 228, a command controller 212, a key table 214, a control status register (CSR) 216, and a first cryptographic engine 218. The key table 214 includes multiple encryption keys, each of which, generally referred to herein as a key, is located in a key slot. The encryption keys may be used by the first cryptographic engine 218 to encrypt files or data being written to the flash storage device or to decrypt encrypted files or data being read from the flash storage device. In one embodiment, the encryption keys located in the key table 214 of the host controller interface 210 are child keys 340 generated by the hardware key manager 110, as described herein. The key table 214 of the host controller interface 210 includes a finite, or set, number of key slots. Each key slot is configured to hold an encryption key.

[0035] The flash storage wrapper 120 includes a first bus or first communication line 204 and a second bus or second communication line 206. The first bus 204 is connected to the hardware key manager 110 and allows the hardware key manager 110 to communicate with the flash storage wrapper 120. The hardware key manager 110 sends hardware-generated encryption keys (e.g., child keys) to a key table 214 located on the host controller interface 210. The child keys are hardware-generated encryption keys created by the hardware key manager 110 as described in more detail herein.

[0036] A second bus or second communication line 206 of the flash storage wrapper 120 connects the host controller interface 210 to the flash storage driver 250. The processor 106 of the apparatus 102 is configured to execute the flash storage driver 250 to communicate with the second bus 206. The flash storage driver 250 is also in communication with the hardware key manager 110, as discussed herein. The flash storage driver 250 is configured to communicate memory commands to the host controller interface 210 via the second bus 206 and to communicate nonces to the hardware key manager 110 via a third bus 414, as described in more detail below. Memory control commands and / or communications (e.g., I / O commands and / or I / O communications) are transmitted between the flash storage driver 250 of the mobile device 102 and the host controller interface 210 of the flash storage wrapper 120 via the second bus 206. In some embodiments, the second bus 206 is an Advanced Microcontroller Bus Architecture (AMBA) bus, and communication over the second bus 206 between the flash storage driver 250 and the host controller interface 210 uses the Advanced eXtensible Interface (AXI) protocol.

[0037] In some implementations, flash storage wrapper 120 includes an arbiter 220 coupled to first bus 204 and second bus 206 of flash storage wrapper 120. A configuration interface 230 is disposed between arbiter 220 and host controller interface 210. Arbiter 220 includes output lines 226, also referred to herein as communication lines, that are connected to host controller interface 210 via configuration interface 230, and communication lines 228 of host controller interface 210. Arbiter 220 arbitrates communications or signals between target A 222, connected to first bus 204 of flash storage wrapper 120, and target B 224, connected to second bus 206 of flash storage wrapper 120. Arbiter 220 arbitrates communications because configuration interface 230, coupled between arbiter 220 and host controller interface 210, is configured to receive communications from either first bus 204 or second bus 206, one at a time. The arbiter 220 ensures that programming of the components 212, 214, 216, 218 within the host controller interface 210 occurs one at a time via the configuration interface 230 over the communication lines 204, 206. In other words, the configuration interface 230 is not configured to receive instructions from both the first bus 204 and the second bus 206 simultaneously. Thus, the arbiter 220 or the controller 240 (described below) can orchestrate a two-to-one communication path.

[0038] The host controller interface 210 includes a command controller 212 disposed between the key table 214 and the configuration interface 230. The command controller 212 is connected to the key table 214, the CSRs 216, and the configuration interface 230 via the communication line 202. The command controller 212 understands the AXI protocol and updates the key table 214 based on communications and / or commands received from the flash storage driver 250 via the second bus 206. The command controller 212 also updates the CSRs 216 based on communications and / or commands received from the flash storage driver 250 via the second bus 206. The command controller 212 also updates the key table 214 with child keys communicated to the host controller interface 210 from the hardware key manager 110 via the first bus 204. The child keys are stored in key slots in the key table 214.

[0039] In some implementations, flash storage wrapper 120 includes a controller 240 coupled to first bus 204 and second bus 206 of flash storage wrapper 120. Controller 240 is disposed between hardware key manager 110 and arbiter 220. Controller 240 performs access control and key policy checks on communications and / or commands received on first and second buses 204, 206 of flash storage wrapper 120. Controller 240 is configured to allow hardware-generated keys, which are child keys generated by hardware key manager 110, to be communicated to key table 214 of host controller interface 210. Controller 240 is also configured to prevent software-generated keys from being communicated to key table 214 of host controller interface 210. Controller 240 prevents flash storage driver 250 from submitting software-generated encryption keys to be entered into key table 214. Although shown and described separately for clarity, arbiter 220 or controller 240 may be partially or fully combined.

[0040] The first crypto engine 218 of the host controller interface 210 cryptographically processes (e.g., encrypts or decrypts) files or data using hardware-generated keys (e.g., child keys) stored in a key table 214 on the host controller interface 210. The first crypto engine 218 encrypts or decrypts files based on I / O commands / information from the flash storage driver 250 to the flash storage wrapper 120 via the second bus 206.

[0041] If the I / O command / information is a write command, the I / O command / information from flash storage driver 250 indicates where the file or data that needs to be encrypted is located on memory 108 of SoC 104 of mobile device 102. The I / O command / information also specifies which child key stored in key table 214 on host controller interface 210 needs to be used to encrypt the file or data. The I / O command / information also includes the location where the file or data needs to be written to the flash storage device once encrypted.

[0042] If the I / O command / information is a read command, the I / O command / information from flash storage driver 250 indicates the location on the flash storage device of the file or data to be read from the flash storage device. The I / O command / information also specifies which child key stored in key table 214 on host controller interface 210 should be used to decrypt the file or data. The I / O command / information also includes the location where the file or data should be written to memory 108 of SoC 104 of mobile device 102 once it has been decrypted.

[0043] The hardware key manager 110 is located on the SoC 104 of the mobile device 102. The hardware key manager 110 is configured to generate hardware-generated child keys for use by a first cryptographic engine 218, located within the host controller interface 210, to cryptographically process files or data on the mobile device 102. The hardware key manager 110 transmits the hardware-generated child keys to the host controller interface 210 via the first bus or first communication line 204. The transmitted child keys pass through a controller 240 before reaching the host controller interface 210. The controller 240 is configured to allow the child keys to be passed to the host controller interface 210, where they are stored in a designated key slot in a key table 214 located within the host controller interface 210. The designated key slot in the key table 214 is indicated in key information received by the hardware key manager 110 from the flash storage driver 250.

[0044] 3 illustrates an exemplary configuration of the hardware key manager 110. In an embodiment, the hardware key manager 110 is located on the SoC 104 of the mobile device 102. The hardware key manager 110 includes a second crypto engine 320 and a base key table 310. The second crypto engine 320 includes at least one key derivation function (KDF) 322 that can be used to derive a base key 312. Various KDFs 322 can be used by the second crypto engine 320, as will be understood by those skilled in the art with the benefit of this disclosure. For example, the KDF 322 may use, but is not limited to, a keyed-hash message authentication code, a cipher-based message authentication code, or a Keccak-based message authentication code as a pseudorandom function as detailed in National Institute of Standards and Technology SP 800-108r1.

[0045] The base key table 310 includes one or more base keys 312 with corresponding base key slot IDs 314. In one embodiment, the base key table 310 may include only a single base key 312 and a single corresponding base key slot ID 314. In other embodiments, the base key table 310 may include between one and four base keys 312 with corresponding base key slot IDs 314. In yet other embodiments, the base key table 310 may include 16 base keys 312 or 32 base keys 312 with corresponding base key slot IDs 314.

[0046] The hardware key manager 110 receives the nonce 330 from the flash storage driver 250, as discussed herein. The hardware key manager 110 applies the nonce 330 to the second crypto engine 320 to generate or derive a child key 340 from the base key 312. The nonce 330, or tweak, is applied to a specified base key 312, and the result is a child key 340. This is a repeatable process because applying the same nonce 330 to the same base key 312 generates a child key 340 having the same value as before. In one embodiment, the hardware key manager 110 does not need to record the physical number of generated child keys 340 or the values ​​of the generated child keys 340 because the process of generating child keys 340 is repeatable. Similarly, the hardware key manager 110 may not need to record the location in the key table 214 where the child key 340 is stored because the process of generating child keys 340 is repeatable.

[0047] The hardware key manager 110 is configured to generate an unlimited number of child keys 340 even when the base key table 310 contains a single base key 312. This is because the nonce 330 applied to the single base key 312 can be varied in an unlimited number of ways (e.g., 330-1, 330-2, 330-3, ... 330-N) to generate an unlimited number of child keys 340.

[0048] In some implementations, the hardware key manager 110 may include multiple base keys 312-1, 312-2. In this example, the hardware key manager 110 may generate a first child key 340-1 by applying a first nonce 330-1 to a first base key 312-1. The hardware key manager 110 may generate a second child key 340-2, different from the first child key 340-1, by applying the first nonce 330-1 to a second base key 312-2, different from the first base key 312-1. Similarly, the hardware key manager 110 may create a unique child key 340 by applying a second nonce 330-2, different from the first nonce 330-1, to either the first base key 312-1 or the second base key 312-2.

[0049] After generating the child keys 340, the hardware key manager 110 communicates the generated child keys 340 to the host controller interface 210 via the first bus 204, as discussed herein. The child keys 340 are stored in a key table 214 within the host controller interface 210 for use during the cryptographic process by the first cryptographic engine 218. Per-file encryption may specify that different base keys 312 are used to generate child keys 340 for different types or categories of files. For example, a first base key 312-1 may be used to generate child keys 340-1 for work files, and a second base key 312-2 may be used to generate child keys 340-2 for personal files. In one implementation, a first nonce 330-1 may be applied to the first base key 312-1 to create the first child key 340-1. The second nonce 330-2 may be applied to the first base key 312-1 to create a second child key 340-2. In other words, unique child keys 340 may be generated by using different base keys 312 with different nonce 330 applied to the base keys 312, or each of the base keys 312 and nonce 330 may be varied to create unique child keys 340, 340-1, 340-2, ... 340-N.

[0050] In one embodiment, the normal, typical, or standard number of key slots in key table 214 of host controller interface 210 may be doubled to increase the efficiency of data encryption and decryption by first crypto engine 218 of host controller interface 210. For example, in one application, key table 214 of host controller interface 210 may normally have 16 key slots. In this embodiment, the number of key slots in key table 214 is doubled to 32 key slots to increase the efficiency of cryptographic processing by first crypto engine 218 of host controller interface 210. By doubling the number of key slots in key table 214, host controller interface 210 may be able to use one set or group of child keys 340 in the key slots of key table 214 while cryptographically processing one set of files or data. At the same time, the hardware key manager 110 may be able to populate a second set or group of key slots in the key table 214 of the host controller interface 210 with the second set of child keys 340. The second set of child keys 340 in the second set of key slots in the key table 214 may then be used by the first cryptographic engine 218 of the host controller interface 210 during cryptographic processing of the next set of files or data.

[0051] 4 illustrates an exemplary system 400. The system 400 includes high-level software 410, such as an operating system. The high-level software 410 is connected to a flash storage driver 250 via a bus or communication line 412. The system 400 includes a hardware key manager 110 connected to a flash storage wrapper 120 via a first bus 204, also referred to herein as a first communication line. The flash storage driver 250 is connected to the flash storage wrapper 120 via a second bus 206, also referred to herein as a second communication line. The flash storage driver 250 is connected to the hardware key manager 110 via a third bus 414, also referred to herein as a third communication line. The flash storage wrapper 120 is connected to a flash storage device 420 via a bus or communication line 202.

[0052] 4, high-level software 410 sends memory or I / O commands 416 to flash storage driver 250 over communication lines 412. I / O commands 416 may indicate files or data that need to be encrypted using first crypto engine 218 in host controller interface 210 of flash storage wrapper 120. Similarly, I / O commands 416 may indicate files or data that need to be read from flash storage device 420 and then decrypted using first crypto engine 218 in host controller interface 210 of flash storage wrapper 120.

[0053] 4-1 and 4-2 illustrate an exemplary operational scenario using the hardware shown in FIG. 4. Referring now to FIG. 4-1, upon receiving an I / O command 416, the flash storage driver 250 sends key information 418 to the hardware key manager 110 via the third bus 414. The key information 418 includes not only the nonce 330 but also a designated or specified base key 312 to which the nonce 330 should be applied by the second crypto engine 320 of the hardware key manager 110 to generate a child key 340. The key information 418 sent from the flash storage driver 250 may also optionally include a designated key slot in the key table 214 of the host controller interface 210 in the flash storage wrapper 120. The designated destination key slot is the location in the key table 214 where the child key 340 generated by the hardware key manager 110 is stored. Upon receiving the key information 418 via the third bus 414, the hardware key manager 110 generates a child key 340 using the second cryptographic engine 320 by applying the received nonce 330 to the specified base key 312.

[0054] Upon receiving the I / O command 416, the flash storage driver 250 also sends an I / O command / information 422 to the flash storage wrapper 120 via the second bus 206. If the I / O command 416 is a write command, the I / O command / information 422 may instruct the host controller interface 210 of the location in the memory 108 of the mobile device 102 of the file or data that needs to be encrypted. The I / O command / information 422 also indicates the location in the flash storage device 420 where the file or data will be stored once encrypted by the first crypto engine 218. Furthermore, the I / O command / information 422 indicates not only which child key 340 the first crypto engine 218 should use to encrypt the specified file or data, but also the location of the child key 340 in the key table 214.

[0055] If the received I / O command 416 is a read command, then the I / O command / information 422 indicates to the host controller interface 210 the location to access the file or data that needs to be read from the flash storage device 420. The I / O command / information 422 may also indicate the location in the memory 108 of the SoC 104 where the file or data needs to be written after it has been decrypted by the first crypto engine 218. The I / O command / information 422 also indicates which child key 340 the first crypto engine 218 should use to decrypt the specified file or data, as well as the location of the child key 340 in the key table 214.

[0056] After receiving the key information 418 from the flash storage driver 250, the hardware key manager 110 generates a hardware-generated key, the child key 340, based on applying the received nonce 330 to the specified base key 312. The hardware key manager 110 then sends the child key 340 to the flash storage wrapper 120 via the first bus 204. As described herein, the child key 340 is stored in a key table 214 in the host controller interface 210 of the flash storage wrapper 120.

[0057] 4-2, the first crypto engine 218 of the host controller interface 210 is then ready to perform the requested cryptographic operation after receiving the child key 340 specified in the I / O command / information 422 received by the host controller interface 210 of the flash storage wrapper 120. When performing a write operation to the flash storage device 420, the host controller interface 210 retrieves the specified file or data from the memory 108 on the SoC 104, and the first crypto engine 218 encrypts the file or data using the specified child key 340 stored in the key table 214. After the file or data is encrypted, the host controller interface 210 sends a write command 424 to the flash storage device 420 over the communication line 202 to store the encrypted file or data at the location specified in the received I / O command / information 422.

[0058] When performing a read operation from the flash storage device 420, the host controller interface 210 sends a read command 424 over the communication line 202 to retrieve a specified encrypted file or data from the flash storage device 420. The first crypto engine 218 then decrypts the file or data using a specified child key 340 stored in the key table 214. After the file or data is decrypted, the host controller interface 210 sends the decrypted file or data to the flash storage driver 250 for storage in the memory 108 of the SoC 104. In this system 400, the mobile device software does not need access to the values ​​of the base key 312 or the hardware-generated child key 340.

[0059] Exemplary Methods Exemplary methods are described below with reference to the flowcharts of Figures 5, 6, and 7. Aspects of the exemplary methods, although described separately below, may be implemented together in any combination or permutation.

[0060] 5 is a flowchart 500 illustrating an example method for implementing encryption or decryption using a hardware-generated key. Flowchart 500 includes four blocks 502-508. The operations of the example process may be performed by electronic circuit components as described herein. For example, the operations may be performed by flash storage wrapper 120 and at least one instance of hardware key manager 110 located within flash storage wrapper 120.

[0061] At 502, the flash storage wrapper 120 receives a first child key 340 generated from the base key 312 by the hardware key manager 110 in hardware. In one embodiment, the first child key 340 is received at the flash storage wrapper 120 via the first bus 204. The hardware key manager 110 may generate the child key 340 by applying the nonce 330 to the base key 312. At 504, the flash storage wrapper 120 receives a memory command 422 from the flash storage driver 250. In one embodiment, the flash storage wrapper 120 receives the memory command 422 from the flash storage driver 250 via the second bus 206.

[0062] At 506, flash storage wrapper 120 encrypts the file using first child key 340 and directs writing of the encrypted file to a location on flash storage device 420. In one embodiment, flash storage wrapper 120 encrypts the file according to memory command 422 and writes the encrypted file to a location on flash storage device 420 based on memory command 422 received from flash storage driver 250.

[0063] At 508, the flash storage wrapper 120 instead reads the file on the flash storage device 420 and uses the first child key 340 to decrypt the file. In one embodiment, the file is read from a location on the flash storage device 420 based on a memory command 422 received by the flash storage wrapper 120 from the flash storage driver 250 over the second bus 206. The file is decrypted by the flash storage wrapper 120 according to the received memory command 422.

[0064] 6 is a flowchart 600 illustrating an example method for implementing encryption using a hardware-generated key. Flowchart 600 includes five blocks 602-610. The operations of the example process may be performed by electronic circuit components as described herein. For example, the operations may be performed by at least one instance of hardware key manager 110 and flash storage wrapper 120.

[0065] At 602, the hardware key manager 110 may generate a child key 340 from the base key 312. An example process for operation 602 is described below with reference to FIG. 6. At 604, the hardware key manager 110 may send the child key 340 to the flash storage wrapper 120 over the first bus 204. In one embodiment, the hardware key manager 110 may receive a specified key slot in the key table 214 in the host controller interface 210 in the flash storage wrapper 120 from the flash storage driver 250. The child key 340 may be sent to the specified key slot in the key table 214. At 606, the flash storage wrapper 120 may receive a memory command 422 over the second bus 206. The I / O command / information 422 may indicate where the file or data that needs to be encrypted is located on the memory 108 and which child key 340 needs to be used to encrypt the file or data. Alternatively, the I / O command / information 422 may indicate the location on the flash storage device 420 of the file or data that needs to be read and which child key 340 needs to be used to decrypt the file or data.

[0066] At 608, the first crypto engine 218 of the host controller interface 210 in the flash storage wrapper 120 may use the child key 340 to encrypt or decrypt a file or data. The host controller interface 210 may be implemented by an off-the-shelf third-party flash storage controller, as discussed herein. At 610, the host controller interface 210 may write an encrypted file to or read a decrypted file from a location on the flash storage device 420 based on a memory command 422. The I / O command / information 422 may include a location where the file or data needs to be written to the flash storage device 420 once encrypted, or a location where the file or data needs to be written to the memory 108 of the SoC 104 of the mobile device 102 once decrypted.

[0067] 7 is a flowchart 602-1 illustrating an exemplary process for generating a child key 340 from a base key 312. At 602-2, the hardware key manager 110 receives a nonce 330 from the flash storage driver 250. The nonce 330 includes instructions on how to vary the base key 312 to form the child key 340. In other words, the child key 340 is the product that results when the nonce 330 is applied to the base key 312. At 602-3, the hardware key manager 110 receives the identity of a designated base key 312 from the flash storage driver 250. The designated base key 312 can be a designated base key 312 in the base key table 310 within the hardware key manager 110. At 602-4, the hardware key manager 110 applies the nonce 330 to the designated base key 312 to generate the child key 340.

[0068] One embodiment of the method may include preventing transmission of a software-generated key from flash storage driver 250 to host controller interface 210 of flash storage wrapper 120. Another embodiment includes validating that child key 340 was generated by hardware key manager 110 prior to receipt of child key 340 by host controller interface 210 in flash storage wrapper 120. Yet another embodiment includes arbitrating communications between host controller interface 210 and first and second buses or communication lines 204, 206. Arbitrating communications may ensure that first and second buses 204, 206 do not attempt to communicate with host controller interface 210 at the same time.

[0069] For the methods described herein and associated flowchart(s) and flow diagram(s), the order in which operations are shown and / or described is not intended to be construed as limiting. Instead, any number or combination of the described method operations can be combined in any order to perform a given method or alternative methods, including by combining operations from the flowcharts or diagrams, and the aforementioned schemes and techniques, into one or more methods. Operations may also be omitted from or added to the described methods. Furthermore, the described operations may be performed in a wholly or partially overlapping manner.

[0070] Exemplary Hardware-Generated Key Encryption Aspects and Implementations Below, several exemplary aspects and implementations are described.

[0071] Example Aspect 1. An apparatus including: a first bus configured to receive communications from hardware; a second bus configured to receive communications from software; and an arbiter connected to the first bus and the second bus, the arbiter having an output line; the apparatus further including a host controller interface having a communication line connected to the output line of the arbiter; the host controller interface including a first cryptographic engine and a key table, the key table including a hardware-generated key, the hardware-generated key being received from hardware via the first bus; the apparatus further including the first cryptographic engine configured to use the hardware-generated key to encrypt or decrypt files received from software via the second bus.

[0072] Example 2. The apparatus of Example 1, further comprising a hardware key manager connected to the host controller interface via the first bus, the hardware key manager configured to generate the hardware-generated key.

[0073] Example 3. The device described in Example 1 or Example 2, further comprising a controller connected to the first bus and the second bus.

[0074] Example 4. The device described in any one of Examples 1 to 3, wherein the controller is configured to allow the hardware-generated key to be communicated to the host controller interface and to prevent the software-generated key from being communicated to the host controller interface.

[0075] Example 5: An apparatus described in any one of Examples 1 to 4, wherein the controller is connected between the first and second buses and the communication lines of the host controller interface, and the controller is connected between the first and second buses and the arbiter.

[0076] Example 6: The device described in any one of Examples 1 to 5, further including a configuration interface connected between the output line of the arbiter and the communication line of the host controller interface, the arbiter configured to arbitrate communication with the configuration interface between the first bus and the second bus.

[0077] Example 7. The device of any one of Examples 1 to 6, wherein the hardware key manager includes a second cryptographic engine and a base key table.

[0078] Example 8. The device of any one of Examples 1 to 7, wherein the key table of the host controller interface includes 32 key slots.

[0079] Example 9. The device of any one of Examples 1 to 8, wherein the key table of the host controller interface includes 64 key slots.

[0080] Example 10. The device according to any one of Examples 1 to 9, wherein the base key table includes up to four base keys.

[0081] Example 11. The device according to any one of Examples 1 to 10, wherein the base key table includes at least 16 base keys.

[0082] Example 12. The device described in any one of Examples 1 to 11, further including at least one processor configured to execute a software driver that communicates with the second bus, the software driver also communicating with the hardware key manager, the software driver configured to communicate memory commands to the host controller interface via the second bus and configured to communicate a nonce to the hardware key manager.

[0083] Example 13. The device described in any one of Examples 1 to 12, wherein the hardware key manager is configured to apply the nonce to a base key in the base key table to generate a child key, the child key being the hardware-generated key.

[0084] Example 14. The device of any one of Examples 1 to 13, wherein the hardware key manager is configured to communicate the child key to the host controller interface via the first bus.

[0085] Example 15. The apparatus of any one of Examples 1 to 14, wherein the host controller interface is configured to at least one of encrypt a file using the child key and write the encrypted file to a location on a flash storage device, or read a file from the flash storage device and decrypt the file using the child key.

[0086] Example Embodiment 16. A method comprising: generating a child key from a base key in a hardware key manager; sending the child key from the hardware key manager to a flash storage wrapper on a first bus; receiving a memory command at the flash storage wrapper on a second bus from a flash storage driver; using the child key in the flash storage wrapper to encrypt or decrypt a file; and writing the encrypted file to or reading the decrypted file from a location on a flash storage device based on the memory command.

[0087] Example 17. The method of Example 16, wherein generating the child key from the base key includes receiving a nonce from the flash storage driver, receiving an identity of a designated base key from the flash storage driver, and applying the nonce to the designated base key to generate the child key.

[0088] Example 18. The method of any one of Example 16 or Example 17, further comprising receiving a key and a key slot of a key table within the flash storage wrapper from the flash storage driver at the hardware key manager, and wherein transmitting the child key from the hardware key manager to the flash storage wrapper on the first bus comprises transmitting the child key to the specified key slot of the key table within the flash storage wrapper.

[0089] Example 19. The method of any one of Examples 16-18, further comprising preventing transmission of a software-generated key from the flash storage driver to a host controller interface of the flash storage wrapper.

[0090] Example 20. The method of any one of Examples 16-19, further comprising validating that the child key was generated by the hardware key manager before a host controller interface receives the child key within the flash storage wrapper.

[0091] Example 21. The method according to any one of Examples 16 to 20, further comprising arbitrating communication between the host controller interface and the first bus and the second bus with an arbiter.

[0092] Example 22. A system comprising: a flash storage device; and a flash storage wrapper communicating with the flash storage device, the flash storage wrapper comprising a first key table including a plurality of keys and a plurality of key slots, each key of the plurality of keys corresponding to one key slot of the plurality of key slots; the system further comprising a hardware key manager communicating with the flash storage wrapper via a first bus; and a flash storage driver communicating with the flash storage wrapper via a second bus and with the hardware key manager via a third bus.

[0093] Example 23. The system of Example 22, wherein the hardware key manager is external to the flash storage wrapper.

[0094] Example 24. The system of any one of Example 22 or Example 23, including a system-on-chip of a mobile device, wherein the hardware key manager is located on the system-on-chip of the mobile device.

[0095] Example 25. A system described in any one of Examples 22 to 24, wherein the hardware key manager includes a cryptographic engine and a second key table, and the second key table includes a base key and a base key slot corresponding to the base key.

[0096] Example 26: A system described in any one of Examples 22 to 25, wherein in response to receiving a first I / O command from software, the flash storage driver communicates first key information to the hardware key manager via the third bus.

[0097] Example 27: A system described in any one of Examples 22 to 26, wherein the first key information includes the base key, a first nonce, a first key among the plurality of keys, and a key slot corresponding to the first key.

[0098] Example 28. A system described in any one of Examples 22 to 27, wherein upon receiving the first I / O command from software, the flash storage driver communicates first I / O information to the flash storage wrapper via the second bus.

[0099] Example 29. The system of any one of Examples 22 to 28, wherein the hardware key manager applies the first nonce to the base key to generate a first child key.

[0100] Example 30. A system described in any one of Examples 22 to 29, wherein the hardware key manager communicates the first child key to the flash storage wrapper via the first bus, and the first child key is stored in the first key table.

[0101] Example 31. A system described in any one of Examples 22 to 30, wherein the flash storage wrapper uses the first child key to encrypt a first file and write the first file to the flash storage device.

[0102] Example 32. The system described in any one of Examples 22 to 31, wherein the flash storage wrapper uses the first child key to decrypt a first file and read the first file from the flash storage device.

[0103] Example 33. A system described in any one of Examples 22 to 32, wherein upon receiving a second I / O command from the software, the flash storage driver communicates second key information to the hardware key manager via the third bus.

[0104] Example 34: A system described in any one of Examples 22 to 33, wherein the second key information includes the base key, a second nonce, a second key among the plurality of keys, and a key slot corresponding to the second key.

[0105] Example 35. A system described in any one of Examples 22 to 34, wherein upon receiving the second I / O command from the software, the flash storage driver communicates second I / O information to the flash storage wrapper via the second bus.

[0106] Example 36. The system of any one of Examples 22 to 35, wherein the hardware key manager applies the second nonce to the base key to generate a second child key.

[0107] Example 37. The system described in any one of Examples 22 to 36, wherein the hardware key manager communicates the second child key to the flash storage wrapper via the first bus, and the second child key is stored in the first key table.

[0108] Example 38. The system described in any one of Examples 22 to 37, wherein the flash storage wrapper uses the second child key to encrypt a second file and write the second file to the flash storage device.

[0109] Example 39. The system described in any one of Examples 22 to 38, wherein the flash storage wrapper uses the second child key to decrypt a second file and read the second file from the flash storage device.

[0110] Example Aspect 40. A method, comprising: receiving, at a flash storage wrapper, a first child key from hardware via a first bus, the first child key generated from a base key by a hardware key manager within the hardware; the method further comprising: receiving, at the flash storage wrapper, a memory command from a flash storage driver via a second bus; the method further comprising: encrypting, at the flash storage wrapper, a file using the first child key in accordance with the memory command, and directing writing of the encrypted file to a location on a flash storage device, the location being based on the memory command received from the flash storage driver; or the method further comprising: reading, at the flash storage wrapper, a file on the flash storage device, the location of the file being based on the memory command received from the flash storage driver; and decrypting, at the flash storage wrapper, the file using the first child key in accordance with the memory command.

[0111] Example 41. The method of example 40, wherein the first bus and the second bus are different.

[0112] Example 42. The method of any one of Examples 40 or 41, wherein receiving the first child key and receiving the memory command are received from an arbiter, the arbiter being connected to the first bus and the second bus and arbitrating communication between the first bus and the second bus and a host controller interface of the flash storage wrapper.

[0113] Example 43. A method according to any one of Examples 40 to 42, wherein receiving the first child key and receiving the memory command are received from a controller, and the controller is configured to enable reception of the first child key by the host controller interface of the flash storage wrapper and prevent reception of a software-generated key by the host controller interface of the flash storage wrapper.

[0114] Example 44. The method of any one of Examples 40-43, wherein the received memory command identifies a location within a key table within a host controller interface of the flash storage wrapper, and the method further includes storing the received first child key at the location within the key table identified in the received memory command.

[0115] Example 45. A method as described in any one of Examples 40 to 44, wherein encrypting the file using the first child key is performed using a first cryptographic engine in the host controller interface of the flash storage wrapper, and the first cryptographic engine uses the first child key stored in the key table.

[0116] Example 46. The method described in any one of Examples 40 to 45, wherein the instructing of writing the encrypted file to the flash storage device is instructed by the host controller interface of the flash storage wrapper.

[0117] Example 47. The method according to any one of Examples 40 to 46, wherein reading the file on the flash storage device is done by the host controller interface of the flash storage wrapper.

[0118] Example 48. The method described in any one of Examples 40 to 47, wherein decrypting the file using the first child key uses a first cryptographic engine in the host controller interface of the flash storage wrapper, and the first cryptographic engine uses the first child key stored in the key table.

[0119] Example 49. The method of any one of Examples 40 to 48, wherein the received first child key is generated by receiving, at the hardware key manager, a first nonce from the flash storage driver via a third bus; and receiving, at the hardware key manager, via the third bus, an identity of the base key in a base key table in the hardware key manager, the identity being received from the flash storage driver, and wherein the received first child key is further generated by applying the first nonce to the identified base key by the hardware key manager to generate the first child key.

[0120] Example 50. The method of any one of Examples 40 to 49, wherein applying the first nonce to the base key is performed using a second cryptographic engine within the hardware key manager.

[0121] Example 51. The method according to any one of Examples 40 to 50, wherein the first bus, the second bus, and the third bus are different.

[0122] Example 52. The method of any one of Examples 40 to 51, further comprising generating a second child key, the second child key being generated by receiving, at the hardware key manager, a second nonce from the flash storage driver via the third bus, and receiving, at the hardware key manager, via the third bus, the identity of the base key in a base key table in the hardware key manager, the identity received from the flash storage driver, the second child key being further generated by applying the second nonce to the identified base key by the hardware key manager to generate the second child key.

[0123] Example 53. The method of any one of Examples 40 to 52, wherein the flash storage wrapper includes the controller, the arbiter, and the host controller interface.

[0124] Example 54. The method of any one of Examples 40 to 53, wherein the flash storage wrapper further includes a configuration interface coupled between the arbiter and the host controller interface.

[0125] Example 55. A non-transitory computer-readable memory storing instructions that, when executed by one or more processors, cause the one or more processors to perform any one of the methods described in any one of Examples 40-54.

[0126] Example 56. An apparatus configured to perform the method described in any one of Examples 40 to 54. The apparatus may be an apparatus described in Examples 1 to 15.

[0127] Unless the context dictates otherwise, the use of the word "or" herein may be considered an "inclusive or" or the use of a term permitting the inclusion or application of one or more items linked by the word "or" (e.g., the phrase "A or B" may be interpreted as permitting only "A," permitting only "B," or permitting both "A" and "B"). Also, as used herein, a phrase referring to "at least one" of a list of items refers to any combination of those items, including single members. For example, "at least one of a, b, c" can cover not only a, b, c, ab, ac, bc, abc, but also any combination containing multiples of the same element (e.g., aa, aaa, aab, aac, abb, acc, bb, bbb, bbc, cc, ccc, or any other order of a, b, c). Furthermore, items shown in the accompanying drawings and terms described herein may refer to one or more items or terms, and therefore, the singular or plural forms of items and terms herein can be referred to interchangeably.

[0128] Although embodiments of hardware-generated key encryption are described in language specific to particular functions and / or methods, the subject matter of the appended claims is not necessarily limited to the particular functions or methods described. Rather, the specific features and methods are disclosed as example implementations for achieving hardware-generated key encryption.

Claims

1. 1. A method comprising: receiving, in the flash storage wrapper, from hardware via a first bus, a first child key, the first child key being generated from a base key by a hardware key manager within the hardware; receiving, at the flash storage wrapper, a memory command from a flash storage driver via a second bus, the method further comprising: and instructing, in the flash storage wrapper, to write the encrypted file to a location on the flash storage device based on the memory command received from the flash storage driver, or the method further includes: a flash storage wrapper configured to read a file at the location based on the memory command received from the flash storage driver on the flash storage device; and a flash storage wrapper configured to decrypt the file in accordance with the memory command using the first child key.

2. The method of claim 1 , wherein the first bus and the second bus are different.

3. 3. The method of claim 1, wherein receiving the first child key and receiving the memory command are received from an arbiter, the arbiter being connected to the first bus and the second bus and configured to arbitrate communications between the first bus and the second bus and a host controller interface of the flash storage wrapper.

4. 4. The method of claim 3, wherein receiving the first child key and receiving the memory command are received from a controller, the controller connected to the first bus and the second bus, the controller configured to enable reception of the first child key by the host controller interface of the flash storage wrapper and to prevent reception of a software-generated key by the host controller interface of the flash storage wrapper.

5. 5. The method of claim 1, wherein the received memory command identifies a location in a key table in a host controller interface of the flash storage wrapper, the method further comprising storing the received first child key at the location in the key table identified in the received memory command.

6. 6. The method of claim 5, wherein encrypting the file using the first child key encrypts using a first crypto engine in the host controller interface of the flash storage wrapper, the first crypto engine using the first child key stored in the key table.

7. 7. The method of claim 6, wherein directing the writing of the encrypted file to the flash storage device is directed by the host controller interface of the flash storage wrapper.

8. 8. The method of claim 5, wherein reading the file on the flash storage device is read by the host controller interface of the flash storage wrapper.

9. 9. The method of claim 5, wherein decrypting the file using the first child key uses a first cryptographic engine in the host controller interface of the flash storage wrapper, the first cryptographic engine using the first child key stored in the key table.

10. The received first child key is receiving, at the hardware key manager, a first nonce from the flash storage driver via a third bus; receiving, at the hardware key manager, from the flash storage driver via the third bus, an identity of the base key in a base key table in the hardware key manager; and applying, by the hardware key manager, the first nonce to the identified base key to generate the first child key.

11. 11. The method of claim 10, wherein applying the first nonce to the base key is done using a second cryptographic engine within the hardware key manager.

12. 12. The method of claim 10, wherein the first bus, the second bus, and the third bus are different.

13. The method further includes generating a second child key, the second child key comprising: receiving, at the hardware key manager, a second nonce from the flash storage driver via the third bus; receiving, at the hardware key manager, from the flash storage driver via the third bus, the identity of the base key in a base key table in the hardware key manager; and applying, by the hardware key manager, the second nonce to the identified base key to generate the second child key.

14. 14. A non-transitory computer readable memory storing instructions that, when executed by one or more processors, cause the one or more processors to perform any one of the methods of any one of claims 1 to 13.

15. Apparatus configured to carry out the method of any one of claims 1 to 13.

Images