Hardware generated key encryption

Abstract

The invention relates to hardware generated key encryption. A hardware generated encryption key is provided to enable per-file encryption of a file to be stored in a flash memory storage in a mobile device. The hardware generated encryption key is also used to decrypt the encrypted file stored in the flash memory storage. The hardware key manager is configured to provide an unlimited number of sub-keys generated from one or more base keys. The random number is applied to the base key to generate a sub-key. The hardware key manager transmits the subkey to the host controller interface via the first bus. Software on the mobile device does not have access to the value of the subkey. The flash memory storage drive transmits a command to the host controller interface via the second bus. The host controller interface includes a cryptographic engine that utilizes a subkey to encrypt data to be written to the flash memory storage or decrypt data read from the flash memory.

Description

Technical Field

[0001] The present disclosure relates to hardware generated key encryption. Background Art

[0002] It is estimated that almost 80% of the world's population owns a mobile phone, which is a type of mobile device. Mobile devices typically include a system-on-chip (SoC), which is the core of the mobile device. The SoC includes various components such as a central processing unit (CPU), memory, a graphics processor (GPU), an audio processor, high-speed input and output line interfaces, and an encryption engine. Mobile devices may include flash memory storage located outside the SoC, also referred to herein as flash memory storage. Flash memory storage is used to store user data, such as pictures and emails, on mobile devices. For security purposes, encrypting data stored on mobile devices is standard practice. As the performance of memory devices continues to increase, increasing the speed of cryptographic processes (e.g., encryption and decryption) for data on mobile devices has become important to ensure efficient performance. Inline encryption on the SoC enables efficient encryption of data as it is written to the flash memory, and similarly, enables efficient decryption of data on the SoC as it is read from the flash memory to the SoC. However, implementing inline cryptographic operations efficiently can be challenging.

[0003] The SoC of a mobile device typically includes a host controller interface (HCI) within a flash storage wrapper. The HCI communicates between the SoC and the flash storage. The HCI includes a cryptography engine that encrypts data written to the flash storage and decrypts data read from the flash storage by the SoC. Mobile device manufacturers typically use an off-the-shelf third-party flash storage controller as the HCI within the flash storage wrapper. Third-party providers typically do not offer any customization of this controller. Summary of the Invention

[0004] This document describes the use of hardware-generated keys to provide per-file encryption. This document details how the disclosed hardware key manager can be configured to provide an unlimited or unrestricted number of keys generated from one or more base keys. The base keys reside on a hardware key manager that resides on the SoC of a mobile device. To provide per-file encryption, this document describes an implementation that implements hardware generation of an unlimited number of encryption keys. This enables inline encryption to perform per-file encryption using different keys. The hardware key manager can generate an unlimited number of subkeys. Each subkey is generated as a result of applying a random number, also referred to herein as a fine-tune, to one of the base keys located on the hardware key manager. Even if the hardware key manager only includes a single base key, an unlimited number of subkeys can still be generated by the hardware key manager because the random number can be varied in an unlimited number of ways. The hardware-generated subkeys can then be used by a host controller interface within the flash storage wrapper to encrypt or decrypt on a per-file basis.

[0005] 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, conductors, electrical buses, energy buses, etc. The hardware key manager generates hardware keys that are used by the off-the-shelf third-party flash storage controller to encrypt and / or decrypt data. The flash memory driver sends a request to use the key with the cryptography 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.

[0006] This document details how a hardware key manager can be configured to generate an unlimited or unrestricted number of child keys from a single base key or from a set of base keys. The hardware key manager generates child keys using a trim or random number applied to a base key, also known as a parent key. This document details how the generated child keys are stored in a key table in the host controller interface. A cryptography 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.

[0007] The flash storage wrapper includes two buses, also referred to herein as communication lines, for communicating with a host controller interface, which can be an off-the-shelf third-party flash storage controller located within the flash storage wrapper. This document details how the flash storage wrapper's first bus is used to communicate hardware-generated keys from a hardware key manager to the host controller interface. In some implementations, the hardware key manager is enabled to use the first bus to transmit subkeys to the host controller interface of the flash storage wrapper, while other components (e.g., software) are excluded from using the first bus. If the first bus is accessible only to the hardware key manager, software on the mobile device is prevented from having access to the value of the hardware-generated key. The flash storage wrapper's second bus is used to transmit 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 what data to store to or read from the flash storage, as well as what encryption key to use during cryptographic processing by the cryptography engine. 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 an operating system of the mobile device.

[0008] In an example implementation, a method includes receiving, at a flash storage wrapper via a first bus and from hardware, a first subkey generated from a base key by a hardware key manager within the hardware; receiving, at the flash storage wrapper via a second bus and from a flash storage drive, a memory command; and encrypting a file at the flash storage wrapper using the first subkey and in accordance with the memory command, and directing writing of the encrypted file to a location on the flash storage device based on the memory command received from the flash storage drive; or 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 drive, and decrypting the file at the flash storage wrapper using the first subkey and in accordance with the memory command.

[0009] In an example implementation, a device 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 device includes a host controller interface, the host controller interface including 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 encrypt or decrypt a file using the hardware-generated key.

[0010] In an example implementation, a method includes generating a subkey from a base key in a hardware key manager. The method includes transmitting the subkey from the hardware key manager to a flash storage wrapper over a first bus. The method includes receiving a memory command from a flash storage driver at the flash storage wrapper over a second bus. The method includes encrypting a file or decrypting the file at the flash storage wrapper using the subkey. The method includes writing the encrypted file to a location on the flash storage device or reading the decrypted file from the location on the flash storage device based on the memory command.

[0011] In an example implementation, 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 comprising a plurality of keys and a plurality of key slots. Each key in the plurality of keys corresponds to a slot in 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. BRIEF DESCRIPTION OF THE DRAWINGS

[0012] Devices and techniques for providing hardware-generated key encryption are described with reference to the following drawings. Throughout the drawings, like reference numerals are used to reference like features and components.

[0013] Figure 1 An example device is shown having a SoC that includes a hardware key manager and a flash storage wrapper that can implement per-file storage encryption instructions.

[0014] Figure 2 An example device is shown that includes a host controller interface that may be an off-the-shelf third-party flash storage controller capable of implementing per-file storage encryption instructions utilizing hardware-generated keys.

[0015] Figure 3 A schematic diagram illustrating an example hardware key manager receiving a random number and generating a subkey in response to the received random number is shown.

[0016] Figure 4 An example system is shown in which per-file storage encryption utilizing hardware-generated keys can be implemented utilizing input / output (I / O) commands sent from high-level software to a flash storage drive.

[0017] Figure 4-1 Shown Figure 4An example system in which key information is sent from a flash storage driver to a hardware key manager, wherein subkeys are sent from the hardware key manager to a flash storage wrapper on a first bus, and wherein I / O information is sent from the flash storage driver to the flash storage wrapper on a second bus.

[0018] Figure 4-2 Shown Figure 4-1 An example system in which a read or write command is sent from a flash storage wrapper to a flash storage device.

[0019] Figure 5 is a flow chart illustrating an example process for storage encryption using hardware keys.

[0020] Figure 6 is a flow chart illustrating an example process for storage encryption using hardware keys.

[0021] Figure 7 is a flow chart illustrating an example process for generating subkeys from a base key. DETAILED DESCRIPTION

[0022] Overview

[0023] Mobile devices have made important contributions to modern society, such as those related to communications, security, manufacturing, and content creation. Mobile devices include a SoC as the core of the device, and flash storage external to the SoC. The flash storage is used to store user data on the mobile device. The SoC provides inline cryptographic processes when data is written to and read from the flash storage of the mobile device. Various aspects of the mobile device follow standards approved by the Joint Electron Device Engineering Council (JEDEC) Solid State Technology Association, which is an independent semiconductor trade organization and standardization body. JEDEC has approved standards for inline encryption and decryption that govern the cryptographic processes used on mobile devices. The JEDEC inline encryption standard (JEDEC Universal Flash Storage Host Controller Interface "UFSHIC") has enabled third-party companies to manufacture standard-compliant host controller interfaces so that the host controller interface can be used in mobile devices of various manufacturers.

[0024] In the past, 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 can be used instead of full-disk encryption. File-based encryption enables different files stored in flash storage to be encrypted using different keys. For example, one encryption key can be used to encrypt personal data, while a different encryption key can be used to encrypt work data. As another example, one encryption key can be used to encrypt data read when the mobile device is unlocked, while a different encryption key can be used to encrypt text messages received when the mobile device is locked. File-based encryption of flash storage provides better security in the event that a malicious actor (e.g., a "hacker") determines the value of the encryption key. If file-based encryption is used for data on the flash storage device, the hacker will only gain access to data encrypted using the cracked encryption key and will not have access to any other data encrypted using a different encryption key.

[0025] Manufacturers of SoCs for mobile devices often use an off-the-shelf third-party flash storage controller as the host controller interface in the flash storage wrapper, rather than creating their own host controller interface for the flash storage wrapper. Off-the-shelf means that the flash storage controller is not designed or manufactured to order, but is purchased from a third party from existing inventory or supply. This is more economically efficient because the third party has already created circuitry that complies with the applicable JEDEC standards and is interoperable with industry standard flash storage devices. Off-the-shelf third-party flash storage controllers often perform per-file encryption. One potential issue with per-file encryption is that the host controller interface on a mobile device may need to access a large number of different keys to efficiently perform per-file encryption or decryption. This document describes hardware and techniques that enable a large number of different keys to be used to perform per-file encryption or decryption.

[0026] The host controller interface is located within a flash storage wrapper, which is located on the mobile device's SoC. The host controller interface includes a key table with a limited number of keys. 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 some applications may include more or fewer key slots. This relatively limited number of available keys in the key table may make it impractical for the host controller interface's cryptographic engine 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 once to efficiently perform per-file encryption for a large number of files or file categories. If there are not enough keys available for efficient per-file encryption, the host controller interface's cryptographic engine may need to wait for software on the mobile device to repeatedly reprogram the key table to make a sufficient number of keys available to the cryptographic engine. This reprogramming of the key table can result in unacceptable lag or delay during the cryptographic process for a large number of files. This document describes hardware and techniques that enable a large number of different keys to be used to reduce or eliminate unacceptable lag or delay in reprogramming the key table.

[0027] The security of the SoC and mobile devices is integral. In other words, the components and data residing within the SoC are generally considered secure. As mobile devices grow in complexity, they include more and more software. The greater the amount of software on a mobile device, the greater the number of possible vulnerabilities through which malicious actors could gain access to the mobile device. Any software residing outside the SoC boundaries is generally considered a potential access point that could be vulnerable to malicious actions.

[0028] To provide security, user data stored in flash storage on a mobile device can be encrypted. Although the host controller interface of a third-party off-the-shelf flash storage controller is typically located on the SoC, software on the mobile device currently programs keys in a key table of the host controller interface. Therefore, in current mobile devices, software on the mobile device has access to the value of an encryption key that is used to encrypt user data on the flash storage device in the mobile device. As discussed herein, software having access to the encryption key value may be vulnerable to attack by malicious actors. If the encryption key value is obtained, the malicious actor may be able to access some, if not all, of the user's data on the mobile device and decrypt some of the data, depending on the number of keys obtained by the malicious actor. This document describes hardware and techniques for creating hardware-generated keys for encryption of files or data that are not as vulnerable as software-generated encryption keys.

[0029] This document details how the hardware key manager can be configured to provide an unlimited or effectively unlimited number of keys. To provide per-file encryption, this document describes an implementation that enables the use of an unlimited number of sub-encryption keys generated by the hardware key manager. The hardware-generated sub-keys enable efficient inline encryption on a per-file basis using different keys.

[0030] This document describes how a hardware key manager can generate an unlimited number of subkeys from one or more base keys found in a base key table within the hardware key manager. Each subkey generated by the hardware key manager is the result of applying a random number, also referred to herein as a trim, to a base key located in the base key table found in the hardware key manager. The random number applied to the base key can be varied in an unlimited or infinite number of ways, resulting in the hardware key manager being able to potentially generate an unlimited number of unique subkeys. In this manner, the hardware key manager is configured to generate an unlimited number of subkeys even from a single base key by applying different random numbers to the base key. After generating the subkeys, the hardware key manager transmits the subkeys to a host controller interface within the flash storage wrapper, where they are stored in a key table within the host controller interface. A cryptographic engine can then access the subkeys from the key table to perform encryption or decryption on a per-file basis as directed by the flash storage driver.

[0031] This document details that software on a mobile device has access to hardware-generated encryption keys (also referred to herein as hardware-generated keys and subkeys) used in a flash storage wrapper during cryptographic processes, but the software does not have access to the values of the hardware-generated keys. A disclosed hardware key manager generates the hardware-generated keys and can prevent access to the values of the hardware-generated keys by software. In some implementations, the hardware key manager can be the only component on the mobile device with access to the values of the hardware-generated keys. The hardware key manager is located within the boundaries of the SoC and is therefore less vulnerable to potential malicious actions than software or the flash storage device of the mobile device, both of which are located outside the security boundaries of the SoC. Using hardware-generated keys with values known only to the hardware key manager located on the SoC or with values that otherwise have restricted accessibility reduces the likelihood that malicious actions can access user data stored on the flash storage device and decrypt the user data.

[0032] Off-the-shelf third-party flash storage controllers are 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 the flash storage driver. The first bus from the hardware key manager can be used to enhance a third-party off-the-shelf flash storage controller to enable the host controller interface to receive subkeys from the hardware key manager. Additionally, the flash storage wrapper's firmware can be updated to include functionality for receiving hardware-generated encryption keys from the hardware key manager via the first bus.

[0033] This document details that the only traffic on the first bus between the hardware key manager and the flash storage wrapper can be the transfer of hardware-generated subkeys as described in this document. The second bus to the flash storage wrapper enables memory communication between the flash storage driver and the host controller interface. The host controller interface will receive I / O information and commands from the flash storage driver via the second bus to the flash storage wrapper.

[0034] A third-party, off-the-shelf flash storage host controller interface is configured to receive communications via a single bus or communication line. The current interface to the host controller interface is not configured to receive communications from two different buses or communication lines simultaneously. To address this limitation, this document describes an arbiter in a flash storage wrapper. The arbiter is connected to a first bus from a key hardware manager and a second bus connected to the flash storage drive. The arbiter has an output line that is connected to a configuration interface of the host controller interface in the flash storage wrapper. The arbiter arbitrates communications or signals between the first and second buses and the configuration interface of the host controller interface, such that communications are received 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 and second buses simultaneously.

[0035] To prevent software-generated keys from being transmitted to the host controller interface via a second bus, this document describes a controller within a flash storage wrapper, wherein the controller is positioned between a hardware key manager and an arbitrator. The controller is connected to a first bus from the hardware key manager and a second bus from the flash storage driver. 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 transmitted to the host controller interface and to prevent software-generated keys from being transmitted to the host controller interface.

[0036] As discussed herein, a SoC may require a large number of encryption keys when performing per-file encryption. This may require constant reprogramming of the key table by the mobile device's software, which is also generating the encryption keys, which may cause undesirable lags during the encryption process. Furthermore, software-generated encryption keys may be potentially vulnerable to malicious actions. 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 and are configured to receive communications from a single communication line. Potentially, the software-generated keys could still be transmitted to the host controller interface within the flash storage wrapper via a second bus connected to the flash storage drive.

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

[0038] Example Environment and Electronic Devices

[0039] Figure 1An example environment 100 is shown that includes a device 102. Device 102 may include a mobile phone, a smartphone, a smartwatch, a tablet, a laptop, a mobile computer, a handheld computer, a digital assistant, and the like. Device 102 includes a SoC 104 that includes at least a processor 106, a memory 108, a hardware key manager 110, and a flash storage wrapper 120. Device 102, using components of SoC 104, may implement instructions for hardware-generated key encryption of files or data located in memory 108 on SoC 104 to be stored in flash storage within device 102. The flash storage is located within device 102, but the flash storage is external to SoC 104. In an implementation, the instructions are used to perform per-file encryption using the hardware-generated encryption key, as described herein.

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

[0041] In this example, device 102 is depicted as a smartphone. However, device 102 can 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 phone, 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 home 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 management device, an electronic portion of a machine or piece 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 another portion of a data center), etc. Illustrated examples of devices 102 include a tablet 102-1, a smart TV 102-2, a desktop computer 102-3, a server computer 102-4, a smart watch 102-5, a smart phone (or document reader) 102-6, and smart glasses 102-7.

[0042] In an example implementation, device 102 includes a SoC 104, which is the core of device 102. SoC 104 is typically a complex chip that includes multiple different components, such as a processor, memory, a cryptographic engine, and high-speed input and output lines. 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, and the like. One or more integrated circuit (IC) chips can be mounted on the PCB. Each IC chip can be implemented as a general-purpose processor, a microcontroller, an application-specific integrated circuit (ASIC), and the like. 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, and combinations thereof. Sensor chips can include, for example, accelerometers, cameras or other light sensors, satellite positioning system (e.g., Global Positioning System (GPS)) chips, and the like. The integrated circuit chip can be packaged alone or in combination with other IC chips. Although some of the present disclosure relates to utilizing the technology in conjunction with an SoC, the present invention is not limited thereto. For example, the hardware key manager 110 and flash storage wrapper 120 as described herein can be included in other circuits, such as any integrated circuit or chip that accesses a flash storage device containing encrypted data.

[0043] Example devices, systems, and operating scenarios

[0044] Figure 2An example flash storage wrapper 120 located on the SoC 104 of the mobile device 102 is generally shown at 200. Components within the flash storage wrapper 120 can be used to encrypt data as it is transferred from the SoC 104 to the flash storage 420 of the mobile device 102. Similarly, components within the flash storage wrapper 120 can be used to decrypt data as it is read from the flash storage 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 can be performed inline as they are moved from the SoC 104 to the flash storage or vice versa. The flash storage wrapper 120 includes a plurality of communication lines, generally referred to as 202, that 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 configured for the host controller interface 210 to receive I / O commands and / or I / O information, as described in detail herein.

[0045] 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 written to the flash storage device and decrypts data read from the flash storage device, as described in detail herein. The host controller interface 210 can be an off-the-shelf third-party flash storage controller that the SoC manufacturer has licensed from a third party. In other words, the host controller interface 210 can 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 typically an off-the-shelf third-party flash storage controller because the inline cryptography process is a standard set by JEDEC.

[0046] 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 cryptography engine 218. The key table 214 includes a plurality of encryption keys located in key slots, each of the plurality of encryption keys also generally referred to herein as a key. The encryption keys can be used by the first cryptography engine 218 to encrypt files or data written to the flash storage device or to decrypt encrypted files or data read from the flash storage device. In one implementation, the encryption keys located in the key table 214 of the host controller interface 210 are subkeys 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.

[0047] 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 enables the hardware key manager 110 to communicate with the flash storage wrapper 120. The hardware key manager 110 transmits hardware-generated encryption keys (e.g., subkeys) to a key table 214 located on the host controller interface 210. The subkeys are hardware-generated encryption keys created by the hardware key manager 110, as described in detail herein.

[0048] The 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 device 102 is configured to execute the flash storage driver 250 in communication with the second bus 206. The flash storage driver 250 also communicates with the hardware key manager 110, as discussed herein. The flash storage driver 250 is configured to transmit memory commands to the host controller interface 210 via the second bus 206 and to transmit random numbers to the hardware key manager 110 via the third bus 414, as described in 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 implementations, the second bus 206 is an Advanced Microcontroller Bus Architecture (AMBA) bus, and communications between the flash storage drive 250 and the host controller interface 210 on the second bus 206 use the Advanced eXtensible Interface (AXI) protocol.

[0049] In some implementations, the flash storage wrapper 120 includes an arbitrator 220 connected to the first bus 204 and the second bus 206 of the flash storage wrapper 120. A configuration interface 230 is positioned between the arbitrator 220 and the host controller interface 210. The arbitrator 220 includes output lines 226, also referred to herein as communication lines, connected to the host controller interface 210 via the configuration interface 230 and communication lines 228 of the host controller interface 210. The arbitrator 220 arbitrates communications or signals between a target A 222 connected to the first bus 204 of the flash storage wrapper 120 and a target B 224 connected to the second bus 206 of the flash storage wrapper 120. The arbitrator 220 arbitrates communications because the configuration interface 230, connected between the arbitrator 220 and the host controller interface 210, is configured to receive communications from either the first bus 204 or the 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 via the communication lines 204, 206 occurs one at a time through the configuration interface 230. In other words, the configuration interface 230 is not configured to simultaneously receive instructions from both the first bus 204 and the second bus 206. Thus, the arbiter 220 or the controller 240 (described below) can coordinate the two-to-one communication paths.

[0050] The host controller interface 210 includes a command controller 212 positioned between the key table 214 and the configuration interface 230. The command controller 212 is connected to the key table 214, the CSR 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 CSR 216 based on communications and / or commands also received from the flash storage driver 250 via the second bus 206. The command controller 212 also updates the key table 214 with a subkey transmitted from the hardware key manager 110 to the host controller interface 210 via the first bus 204. The subkey is stored in a key slot in the key table 214.

[0051] In some implementations, the flash storage wrapper 120 includes a controller 240 connected to the first bus 204 and the second bus 206 of the flash storage wrapper 120. The controller 240 is positioned between the hardware key manager 110 and the arbitrator 220. The controller 240 performs access control and key policy checks on communications and / or commands received on the first bus 204 and the second bus 206 of the flash storage wrapper 120. The controller 240 is configured to allow hardware-generated keys—subkeys generated by the hardware key manager 110—to be passed to the key table 214 of the host controller interface 210. The controller 240 is also configured to prevent software-generated keys from being passed to the key table 214 of the host controller interface 210. The controller 240 prevents the flash storage driver 250 from submitting software-generated encryption keys to be entered into the key table 214. Although shown and described separately for clarity, the arbitrator 220 or the controller 240 may be partially or completely combined.

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

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

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

[0055] 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 a subkey, which is a hardware-generated key to be used by the first cryptography engine 218 located in the host controller interface 210 to cryptographically process files or data on the mobile device 102. The hardware key manager 110 sends the hardware-generated subkey to the host controller interface 210 via the first bus or first communication line 204. The sent subkey passes through the controller 240 before reaching the host controller interface 210. The controller 240 is configured to permit the subkey to be passed to the host controller interface 210, where it will be stored in a designated key slot of the key table 214 located in the host controller interface 210. The designated key slot of the key table 214 is indicated in the key information received by the hardware key manager 110 from the flash storage driver 250.

[0056] Figure 3 An example configuration of the hardware key manager 110 is shown. In an implementation, the hardware key manager 110 is located on the SoC 104 of the mobile device 102. The hardware key manager 110 includes a second cryptography engine 320 and a base key table 310. The second cryptography engine 320 includes at least one key derivation function (KDF) 322 that can be used to derive a base key 312. As will be appreciated by one of ordinary skill in the art having the benefit of this disclosure, the second cryptography engine 320 can use a variety of KDFs 322. For example, the KDF 322 can 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 NIST SP 800-108r1.

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

[0058] The hardware key manager 110 receives a random number 330 from the flash storage drive 250, as discussed herein. The hardware key manager 110 utilizes the second cryptographic engine 320 to apply the random number 330 to generate or derive a subkey 340 from the base key 312. The random number 330, or a modification thereof, is applied to the specified base key 312, and the result is a subkey 340. This is a repeatable process, as the same random number 330 applied to the same base key 312 will result in the generation of a subkey 340 with the same value as before. In one implementation, the hardware key manager 110 does not need to record the physical number of generated subkeys 340 or the values of generated subkeys 340, as the process of generating subkeys 340 is repeatable. Similarly, the hardware key manager 110 may not need to record the location in the key table 214 where the subkeys 340 are stored, as the process of generating subkeys 340 is repeatable.

[0059] The hardware key manager 110 is configured to generate an unlimited number of subkeys 340 even if the base key table 310 includes a single base key 312. This is because the random number 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 subkeys 340.

[0060] 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 subkey 340-1 by applying a first random number 330-1 to the first base key 312-1. The hardware key manager 110 may generate a second subkey 340-2 that is different from the first subkey 340-1 by applying the first random number 330-1 to a second base key 312-2 that is different from the first base key 312-1. Similarly, the hardware key manager 110 may create a unique subkey 340 by applying a second random number 330-2 that is different from the first random number 330-1 to the first base key 312-1 or the second base key 312-2.

[0061] After generating the subkey 340, the hardware key manager 110 transmits the generated subkey 340 to the host controller interface 210 via the first bus 204, as discussed herein. The subkey 340 is stored in the key table 214 in the host controller interface 210 for use by the first cryptography engine 218 during cryptographic processes. Per-file encryption can specify that a different base key 312 will be used to generate the subkey 340 for each different type or category of file. For example, a first base key 312-1 can be used to generate a subkey 340-1 for work files, and a second base key 312-2 can be used to generate a subkey 340-2 for personal files. In one implementation, a first random number 330-1 can be applied to the first base key 312-1 to create the first subkey 340-1. A second random number 330-2 can be applied to the first base key 312-1 to create the second subkey 340-2. In other words, the unique subkeys 340 may be generated by using different base keys 312, using different random numbers 330 applied to the base keys 312, or each of the base keys 312 and random numbers 330 may be varied to create the unique subkeys 340, 340-1, 340-2, ..., 340-N.

[0062] In one implementation, the normal, typical, or standard number of key slots in the key table 214 of the host controller interface 210 can be doubled to increase the efficiency of encryption and decryption of data by the first cryptography engine 218 of the host controller interface 210. For example, in one application, the key table 214 of the host controller interface 210 may typically have 16 key slots. In this implementation, the number of key slots in the key table 214 is doubled to 32 key slots to increase the efficiency of cryptographic processing performed by the first cryptography engine 218 of the host controller interface 210. By doubling the number of key slots in the key table 214, the host controller interface 210 may be able to use one or a group of subkeys 340 in the key slots of the key table 214 when cryptographically processing a set of files or data. Simultaneously, 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 subkeys 340. The second set of subkeys 340 in the second set of key slots in the key table 214 on the host controller interface 210 may then be used by the first cryptography engine 218 of the host controller interface 210 for the next set of files or data during cryptographic processing.

[0063] Figure 4An example system 400 is shown. System 400 includes high-level software 410, such as an operating system. High-level software 410 is connected to a flash storage driver 250 via a bus or communication line 412. 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. Flash storage driver 250 is connected to flash storage wrapper 120 via a second bus 206, also referred to herein as a second communication line. Flash storage driver 250 is connected to hardware key manager 110 via a third bus 414, also referred to herein as a third communication line. Flash storage wrapper 120 is connected to flash storage 420 via bus or communication line 202.

[0064] like Figure 4 As shown, high-level software 410 sends a memory command or I / O command 416 to the flash storage driver 250 via communication line 412. The I / O command 416 may indicate a file or data to be encrypted using the first cryptography engine 218 in the host controller interface 210 of the flash storage wrapper 120. Likewise, the I / O command 416 may indicate a file or data to be read from the flash storage device 420 and then decrypted using the first cryptography engine 218 in the host controller interface 210 of the flash storage wrapper 120.

[0065] Figure 4-1 and Figure 4-2 Describes the use Figure 4 Example operating scenarios for the hardware shown. Figure 4-1 Upon receiving the 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 the random number 330 and the designated or specified base key 312. The random number 330 is to be applied by the second cryptography engine 320 of the hardware key manager 110 to the base key to generate the subkey 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 within the key table 214 where the subkey 340 to be generated by the hardware key manager 110 is to be stored. Upon receiving the key information 418 via the third bus 414, the hardware key manager 110 generates the subkey 340 using the second cryptography engine 320 by applying the received random number 330 to the designated base key 312.

[0066] After 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 indicate to the host controller interface 210 the location of the file or data to be encrypted in the memory 108 of the mobile device 102. The I / O command / information 422 also indicates the location within the flash storage device 420 where the file or data is to be stored once it has been encrypted by the first cryptography engine 218. Additionally, the I / O command / information 422 indicates which subkey 340 the first cryptography engine 218 should use to encrypt the specified file or data, as well as the location of the subkey 340 in the key table 214.

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

[0068] After receiving the key information 418 from the flash storage driver 250, the hardware key manager 110 generates a hardware-generated key, i.e., a subkey 340, based on the received random number 330 being applied to the specified base key 312. The hardware key manager 110 then sends the subkey 340 to the flash storage wrapper 120 via the first bus 204. As discussed herein, the subkey 340 is stored in the key table 214 within the host controller interface 210 of the flash storage wrapper 120.

[0069] Now refer to Figure 4-2After the host controller interface 210 of the flash storage wrapper 120 has received the subkey 340 specified in the received I / O command / information 422, the first cryptography engine 218 of the host controller interface 210 is then ready to perform the requested cryptographic processing. If a write operation is performed 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 cryptography engine 218 encrypts the file or data using the specified subkey 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 via the communication line 202 to store the encrypted file or data at the location specified in the received I / O command / information 422.

[0070] If a read operation is performed from the flash storage device 420, the host controller interface 210 sends a read command 424 via the communication line 202 to retrieve the specified encrypted file or data from the flash storage device 420. The first cryptography engine 218 then decrypts the file or data using the specified subkey 340 stored in the key table 214. After the file or data has been decrypted, the host controller interface 210 sends the decrypted file or data to the flash storage drive 250 for storage within the memory 108 of the SoC 104. In this system 400, the mobile device's software does not need to access the base key 312 or the hardware-generated subkey 340 value.

[0071] Example Method

[0072] References below Figure 5 、 Figure 6 and Figure 7 Although example method aspects are described separately below, they may be implemented together in any combination or arrangement.

[0073] Figure 5 Flowchart 500 illustrates an example method for implementing encryption or decryption using hardware-generated keys. 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.

[0074] At 502, the flash storage wrapper 120 receives a first subkey 340 generated by the hardware key manager 110 within the hardware from the base key 312. In one implementation, the first subkey 340 is received at the flash storage wrapper 120 via the first bus 204. The hardware key manager 110 may generate the subkey 340 by applying the random number 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 implementation, the flash storage wrapper 120 receives the memory command 422 from the flash storage driver 250 via the second bus 206.

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

[0076] At 508, flash storage wrapper 120 instead reads the file on flash storage 420 and decrypts the file using first subkey 340. In one implementation, the file is read at a location on flash storage 420 based on a memory command 422 received by flash storage wrapper 120 from flash storage driver 250 via second bus 206. The file is decrypted by flash storage wrapper 120 according to the received memory command 422.

[0077] Figure 6 6 is a flowchart 600 illustrating an example method for implementing encryption using hardware-generated keys. 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.

[0078] At 602, the hardware key manager 110 may generate a subkey 340 from the base key 312. Figure 6An example process for operation 602 is described. At 604, the hardware key manager 110 may transmit the subkey 340 to the flash storage wrapper 120 over the first bus 204. In one implementation, the hardware key manager 110 may receive a designated key slot of the key table 214 in the host controller interface 210 in the flash storage wrapper 120 from the flash storage driver 250. The subkey 340 may be transmitted to the designated key slot of 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 to be encrypted is located on the memory 108 and which subkey 340 should be used to encrypt the file or data. Alternatively, the I / O command / information 422 may indicate where the file or data to be read is located on the flash storage device 420 and which subkey 340 should be used to decrypt the file or data.

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

[0080] Figure 7 Flowchart 602-1 illustrates an example process for generating a subkey 340 from a base key 312. At 602-2, the hardware key manager 110 receives a random number 330 from the flash storage driver 250. The random number 330 includes instructions on how to vary the base key 312 to form the subkey 340. In other words, the subkey 340 is the product that results when the random number 330 is applied to the base key 312. At 602-3, the hardware key manager 110 receives an 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 in the hardware key manager 110. At 602-4, the hardware key manager 110 applies the random number 330 to the designated base key 312 to generate the subkey 340.

[0081] One implementation of the method may include preventing the transmission of software-generated keys from the flash storage driver 250 to the host controller interface 210 of the flash storage wrapper 120. Another implementation includes verifying that the subkey 340 was generated by the hardware key manager 110 before the subkey 340 is received by the host controller interface 210 within the flash storage wrapper 120. Yet another implementation includes arbitrating communications between the host controller interface 210 and the first bus or communication line 204 and the second bus or communication line 206. Arbitration of communications may ensure that the first bus 204 and the second bus 206 do not attempt to communicate with the host controller interface 210 at the same time.

[0082] For the methods described herein and associated flow charts and flowcharts, the order in which the operations are shown and / or described is not intended to be considered limiting. Rather, any number of the described method operations or any combination of the described method operations may be combined in any order to implement a given method or an alternative method, including by combining the operations from the flow charts or flowcharts and previously described 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 implemented in a wholly or partially overlapping manner.

[0083] Example aspects and implementations of hardware-generated key encryption

[0084] In the following, some example aspects and implementations are described:

[0085] Example aspect 1. A device comprising: a first bus configured to receive communications from hardware; a second bus configured to receive communications from software; an arbitrator connected to the first bus and the second bus, the arbitrator having an output line; a host controller interface having a communication line connected to the output line of the arbitrator, the host controller interface comprising a first cryptographic engine and a key table, the key table comprising a hardware-generated key, the hardware-generated key being received from the hardware via the first bus; and the first cryptographic engine configured to use the hardware-generated key to encrypt or decrypt a file received from the software via the second bus.

[0086] Example Aspect 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 a hardware-generated key.

[0087] Example Aspect 3. The apparatus of Example Aspect 1 or Example Aspect 2, further comprising a controller connected to the first bus and the second bus.

[0088] Example aspect 4. The apparatus of any one of example aspects 1 to 3, wherein the controller is configured to: allow hardware-generated keys to be transmitted to the host controller interface; and prevent software-generated keys from being transmitted to the host controller interface.

[0089] Example aspect 5. The apparatus of any one of example aspects 1 to 4, wherein: the controller is connected between the first bus and the second bus and the communication line of the host controller interface; and the controller is connected between the first bus and the second bus and the arbitrator.

[0090] Example Aspect 6. The device according to any one of Example Aspects 1 to 5 further includes a configuration interface connected between the output line of the arbitrator and the communication line of the host controller interface, and the arbitrator is configured to arbitrate communication with the configuration interface between the first bus and the second bus.

[0091] Example aspect 7. The apparatus of any one of example aspects 1 to 6, wherein the hardware key manager comprises a second cryptography engine and a base key table.

[0092] Example Aspect 8. The apparatus of any one of Example Aspects 1 to 7, wherein the key table of the host controller interface includes thirty-two key slots.

[0093] Example Aspect 9. The apparatus of any one of Example Aspects 1 to 8, wherein the key table of the host controller interface includes sixty-four key slots.

[0094] Example aspect 10. The apparatus of any one of example aspects 1 to 9, wherein the base key table includes up to four base keys.

[0095] Example aspect 11. The apparatus of any one of example aspects 1 to 10, wherein the base key table includes at least sixteen base keys.

[0096] Example Aspect 12. The device according to any one of Example Aspects 1 to 11 further includes: at least one processor configured to execute a software driver that communicates with the second bus; the software driver also communicates with the hardware key manager; and wherein the software driver is configured to transmit memory commands to the host controller interface via the second bus and transmit random numbers to the hardware key manager.

[0097] Example aspect 13. The apparatus of any one of example aspects 1 to 12, wherein: the hardware key manager is configured to apply a random number to a base key in the base key table to generate a subkey; and the subkey is a hardware-generated key.

[0098] Example aspect 14. The apparatus of any one of example aspects 1 to 13, wherein the hardware key manager is configured to transmit the subkey to the host controller interface via the first bus.

[0099] Example Aspect 15. An apparatus according to any one of Example Aspects 1 to 14, wherein the host controller interface is configured to at least one of: encrypt a file using a subkey 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 subkey.

[0100] Example Aspect 16. A method comprising: generating a subkey from a base key in a hardware key manager; transmitting the subkey from the hardware key manager to a flash storage wrapper on a first bus; receiving a memory command from a flash storage drive at the flash storage wrapper on a second bus; using the subkey to encrypt a file or decrypt a file at the flash storage wrapper; and based on the memory command, writing an encrypted file to a location on a flash storage device or reading a decrypted file from a location on the flash storage device.

[0101] Example aspect 17. A method according to example aspect 16, wherein generating a subkey from a base key comprises: receiving a random number from a flash storage drive; receiving an identification of a specified base key from the flash storage drive; and applying the random number to the specified base key to generate the subkey.

[0102] Example Aspect 18. The method according to Example Aspect 16 or Example Aspect 17 further includes: receiving a key and a key slot of a key table in a flash storage wrapper from a flash storage driver at a hardware key manager; and wherein transmitting a subkey from the hardware key manager to the flash storage wrapper on the first bus includes transmitting the subkey to a designated key slot of the key table in the flash storage wrapper.

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

[0104] Example aspect 20. The method of any one of example aspects 16 to 19, further comprising: verifying that the subkey is generated by the hardware key manager before the host controller within the flash storage wrapper receives the subkey.

[0105] Example Aspect 21. The method of any one of Example Aspects 16 to 20, further comprising: utilizing an arbitrator to arbitrate communications between the host controller interface and the first bus and the second bus.

[0106] Example Aspect 22. A system comprising: a flash memory storage device; a flash memory storage wrapper that communicates with the flash memory storage device, the flash memory storage wrapper comprising a first key table, the first key table comprising a plurality of keys and a plurality of key slots, each key in the plurality of keys corresponding to a key slot in the plurality of key slots; a hardware key manager that communicates with the flash memory storage wrapper via a first bus; and a flash memory storage drive that communicates with the flash memory storage wrapper via a second bus and with the hardware key manager via a third bus.

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

[0108] Example Aspect 24. The system of Example Aspect 22 or Example Aspect 23, comprising a system-on-chip of a mobile device, wherein the hardware key manager is located on the system-on-chip of the mobile device.

[0109] Example aspect 25. The system of any one of example aspects 22 to 24, wherein the hardware key manager includes a cryptography 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.

[0110] Example aspect 26. The system of any of example aspects 22 to 25, wherein in response to receiving the first I / O command from the software, the flash storage driver transmits the first key information to the hardware key manager via the third bus.

[0111] Example aspect 27. The system of any one of example aspects 22 to 26, wherein the first key information includes a base key, a first random number, a first key of the plurality of keys, and a key slot corresponding to the first key.

[0112] Example aspect 28. The system of any of example aspects 22 to 27, wherein upon receiving the first I / O command from the software, the flash storage driver transmits the first I / O information to the flash storage wrapper via the second bus.

[0113] Example aspect 29. The system of any of example aspects 22 to 28, wherein the hardware key manager applies the first random number to the base key to generate the first subkey.

[0114] Example aspect 30. The system of any of example aspects 22 to 29, wherein the hardware key manager transmits the first subkey to the flash storage wrapper via the first bus, and wherein the first subkey is stored in the first key table.

[0115] Example aspect 31. The system of any of example aspects 22 to 30, wherein the flash storage wrapper encrypts the first file using the first subkey and writes the first file to the flash storage device.

[0116] Example aspect 32. The system of any of example aspects 22 to 31, wherein the flash storage wrapper decrypts the first file using the first subkey and reads the first file from the flash storage device.

[0117] Example aspect 33. The system of any of example aspects 22 to 32, wherein upon receiving the second I / O command from the software, the flash storage driver transmits the second key information to the hardware key manager via the third bus.

[0118] Example aspect 34. The system of any one of example aspects 22 to 33, wherein the second key information includes a base key, a second random number, a second key of the plurality of keys, and a key slot corresponding to the second key.

[0119] Example aspect 35. The system of any of example aspects 22 to 34, wherein upon receiving the second I / O command from the software, the flash storage driver transmits the second I / O information to the flash storage wrapper via the second bus.

[0120] Example aspect 36. The system of any of example aspects 22 to 35, wherein the hardware key manager applies the second random number to the base key to generate the second subkey.

[0121] Example aspect 37. The system of any of example aspects 22 to 36, wherein the hardware key manager transmits the second subkey to the flash storage wrapper via the first bus, and wherein the second subkey is stored in the first key table.

[0122] Example aspect 38. The system of any of example aspects 22 to 37, wherein the flash storage wrapper encrypts the second file using the second subkey and writes the second file to the flash storage device.

[0123] Example aspect 39. The system of any of example aspects 22 to 38, wherein the flash storage wrapper decrypts the second file using the second subkey and reads the second file from the flash storage device.

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

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

[0126] Example aspect 42. A method according to example aspect 40 or example aspect 41, wherein receiving the first subkey and receiving the memory command are received from an arbitrator that is connected to the first bus and the second bus and is configured to arbitrate communications between the first bus and the second bus and a host controller interface of the flash storage wrapper.

[0127] Example Aspect 43. A method according to any one of Example Aspects 40 to 42, wherein receiving the first subkey and receiving the memory command are received from a controller connected to the first bus and the second bus, the controller being configured to enable the first subkey to be received by the host controller interface of the flash storage wrapper and to prevent the host controller interface of the flash storage wrapper from receiving a software-generated key.

[0128] Example Aspect 44. A method according to any one of Example Aspects 40 to 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 subkey at the location within the key table identified in the received memory command.

[0129] Example Aspect 45. A method according to any one of Example Aspects 40 to 44, wherein encrypting the file using the first subkey is performed using a first cryptography engine within a host controller interface of the flash storage wrapper, the first cryptography engine using the first subkey stored in the key table.

[0130] Example aspect 46. The method of any one of example aspects 40 to 45, wherein directing the writing of the encrypted file to the flash storage device is directed by a host controller interface of the flash storage wrapper.

[0131] Example aspect 47. The method of any one of example aspects 40 to 46, wherein reading the file on the flash storage device is read by a host controller interface of the flash storage wrapper.

[0132] Example Aspect 48. A method according to any one of Example Aspects 40 to 47, wherein decrypting the file using the first subkey is decrypting using a first cryptographic engine within a host controller interface of the flash storage wrapper, the first cryptographic engine using the first subkey stored in the key table.

[0133] Example Aspect 49. A method according to any one of Example Aspects 40 to 48, wherein the received first subkey is generated by: receiving a first random number from a flash storage drive via a third bus at the hardware key manager; receiving an identification of a base key in a base key table within the hardware key manager via the third bus, the identification being received from the flash storage drive; and applying the first random number to the identified base key by the hardware key manager to generate the first subkey.

[0134] Example aspect 50. The method of any one of example aspects 40 to 49, wherein applying the first random number to the base key is applied using a second cryptography engine within the hardware key manager.

[0135] Example Aspect 51. The method of any one of Example Aspects 40 to 50, wherein the first bus, the second bus, and the third bus are different.

[0136] Example Aspect 52. The method according to any one of Example Aspects 40 to 51 further includes generating a second subkey, which is generated by: receiving a second random number from a flash storage drive via a third bus at the hardware key manager; receiving an identifier of a base key in a base key table within the hardware key manager via a third bus, which identifier is received from the flash storage drive; and applying the second random number to the identified base key by the hardware key manager to generate a second subkey.

[0137] Example aspect 53. The method of any one of example aspects 40 to 52, wherein the flash storage wrapper comprises a controller, an arbitrator, and a host controller interface.

[0138] Example aspect 54. The method of any one of example aspects 40 to 53, wherein the flash storage wrapper further comprises a configuration interface connected between the arbitrator and the host controller interface.

[0139] Example aspect 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 according to example aspects 40 to 54.

[0140] Example aspect 56. A device configured to perform the method according to any one of example aspects 40 to 54. The device may be the device according to example aspects 1 to 15.

[0141] Unless the context dictates otherwise, the use of the word "or" herein may be considered as use of an "inclusive or," or 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," only "B," or both "A" and "B"). Furthermore, 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, or c" may encompass a, b, c, ab, ac, bc, and abc, as well as any combination having multiples of the same element (e.g., aa, aaa, aab, aac, abb, acc, bb, bbb, bbc, cc, and ccc, or any other ordering of a, b, and c). Furthermore, the items shown in the drawings and the terms discussed herein may indicate one or more items or terms, and thus reference may be made interchangeably to the items and terms in this written description in either singular or plural form.

[0142] Although implementations of hardware-generated key encryption have been described in language specific to certain features and / or methods, the subject matter of the appended claims is not necessarily limited to the specific features or methods described. Rather, the specific features and methods are disclosed as example implementations for implementing hardware-generated key encryption.

Claims

1. A method comprising: receiving, at a flash storage wrapper, via a first bus and from hardware, a first subkey generated from a base key by a hardware key manager within the hardware; receiving a memory command at the flash storage wrapper via a second bus and from a flash storage driver; as well as encrypting a file at the flash storage wrapper using the first subkey and 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 drive; or A file on the flash storage device is read at the flash storage wrapper, the location of the file being based on the memory command received from the flash storage drive, and the file is decrypted at the flash storage wrapper using the first subkey and in accordance with the memory command.

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

3. The method of claim 1 , wherein the first subkey and the memory command are received from an arbitrator 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. The method of claim 3 , wherein the first subkey and the memory command are received from a controller connected to the first bus and the second bus, the controller being configured to enable receipt of the first subkey by the host controller interface of the flash storage wrapper and to prevent receipt of a software-generated key by the host controller interface of the flash storage wrapper.

5. The method of claim 1 , 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 comprises storing the received first subkey at the location within the key table identified in the received memory command.

6. The method of claim 5 , wherein encrypting the file using the first subkey comprises encrypting the file using a first cryptography engine within the host controller interface of the flash storage wrapper, the first cryptography engine using the first subkey stored in the key table.

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

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

9. The method of claim 5, wherein decrypting the file using the first subkey comprises decrypting the file using a first cryptography engine within the host controller interface of the flash storage wrapper, the first cryptography engine using the first subkey stored in the key table.

10. The method according to any one of claims 1 to 9, wherein the received first subkey is generated by: receiving, at the hardware key manager, a first random number from the flash storage drive via a third bus; receiving, at the hardware key manager via the third bus, an identification of the base key in a base key table within the hardware key manager, the identification being received from the flash storage drive; and The first random number is applied to the base key by the hardware key manager to generate the first subkey.

11. The method of claim 10, wherein the first random number is applied to the base key using a second cryptography engine within the hardware key manager.

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

13. The method of claim 10, further comprising generating a second subkey, wherein the second subkey is generated by: receiving, at the hardware key manager via the third bus, a second random number from the flash storage drive; receiving, at the hardware key manager via the third bus, the identification of the base key in a base key table within the hardware key manager, the identification being received from the flash storage drive; and The second random number is applied to the base key by the hardware key manager to generate the second subkey.

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 the method according to any one of claims 1 to 13.

15. A device configured to perform the method according to any one of claims 1 to 13.

Images