Method and system for enabling custom features using public key infrastructure in storage device

Abstract

The invention relates to managing custom memory functionality in a storage device coupled to a host device in an electronic system. The storage device obtains information items (e.g., programs, data, metadata) for implementing custom memory functions. The storage device receives a host signature and a public key from the host device and authenticates the host signature using the public key. In accordance with authentication of at least the host signature, the storage device performs the custom memory function based on the information item. In some embodiments, the host device selects a set of storage devices based on a first arrival first service order, and the custom memory functionality is implemented at each of the set of storage devices in accordance with authentication of at least a respective host signature issued by the host device.

Description

[0001] Related applications

[0002] This application is a continuation-to-priority application of U.S. Patent Application No. 18 / 237,345, filed August 23, 2023, entitled “Methods and Systems For Enabling Custom Features Using Public Key Infrastructure in Memory Devices,” which claims priority to U.S. Provisional Patent Application No. 63 / 522,097, filed June 20, 2023, entitled “This Method Leverages Asymmetric Cryptography To Enable Custom And Debug Features In SSDs, And Embedded Devices In General,” each of which is incorporated herein by reference in its entirety. Technical Field

[0003] This application generally relates to memory management, including but not limited to methods, systems, and non-transitory computer-readable media for the secure management of memory functions in a memory system. Background Technology

[0004] Memory is used in computer systems to store instructions and data. Specifically, if a computer system is decoupled from its power supply, it relies on non-volatile memory to retain the instructions and data stored thereon. Examples of secondary storage include, but are not limited to, hard disk drives (HDDs) and solid-state drives (SSDs). Different SSDs can be configured to implement different memory functions under the control of their host devices. SSD manufacturers sometimes specifically release custom memory function code to a target group of customers (customers who purchase SSDs and install them on their computer systems). Custom memory functions can only be implemented on computer systems that receive the code directly from the SSD manufacturer. Managing such targeted custom versions is costly. It is highly likely that the code will be sent to unintended customers, and few solutions exist to restrict such custom versions to the target customers or a subset of devices within their deployment pool. For security reasons, many customers (e.g., those requiring a general release (GA) version) are unwilling to accept custom versions and are most likely to reject them outright. Alternatively, SSD manufacturers can widely distribute custom memory function code among their customers. A target group of customers is identified on a list of serial numbers or identifiers. Only customers identified on the list are allowed to implement custom memory functions. The requirement to widely distribute the list of serial numbers or identifiers in a secure manner makes this solution unsuitable for the widespread deployment of custom storage functions. Such widespread distribution of non-targeted versions can involve cumbersome processes and extended turnaround times, especially since the list of serial numbers or identifiers is included in every version. Developing mechanisms for the efficient and secure deployment of storage functions in storage systems, such as SSDs, would be beneficial. Summary of the Invention

[0005] Various embodiments of this application relate to methods, systems, apparatuses, and non-transitory computer-readable media for securely managing custom memory functions on storage devices coupled to host devices in an electronic system (e.g., a computer system). A public key infrastructure (PKI) is created in the electronic system, allowing the application of asymmetric cryptography to enable custom memory functions (e.g., certain debugging features, retrieval of custom statistics) in the electronic system's storage devices. Specifically, in some cases, the electronic system deploys custom memory functions to a set of target host devices and their associated storage devices. Examples of custom memory functions include, but are not limited to, debugging or experimental functions that help debug specific memory problems and specific memory features to be enabled on mass-market memory products owned by target customers (e.g., SSDs manufactured in selected batches). The use of asymmetric cryptography implements secure methods for enabling custom memory features and capabilities. Low-level cryptographic capabilities are implemented on the electronic system with storage devices to manage the secure deployment of custom memory functions on the storage devices.

[0006] More specifically, in one aspect, a method is provided for securely managing custom memory functionality on a storage device (e.g., comprising one or more SSDs) of a host device coupled to an electronic system. The method includes: obtaining an information item for implementing the custom memory functionality; receiving a host signature and a public key from the host device; authenticating the host signature using the public key; and implementing the custom memory functionality based on the information item, according to the authentication of at least the host signature. Furthermore, in some embodiments, the information item is associated with a public key and is applied to implement the custom memory functionality based on verification of the public key.

[0007] In some embodiments, the storage device includes a first storage device. A host device is coupled to multiple storage devices, and a subset of the multiple storage devices includes the first storage device. Custom memory functionality is implemented at each of the subset of storage devices based on an authentication issued by the host device with at least a corresponding host signature. The method further includes the host device selecting a subset of storage devices based on a first-come, first-served order by obtaining a host identity certificate from each of the subset of storage devices.

[0008] In some embodiments, the storage device includes a first storage device. The method further includes receiving from a host device a certificate signing request for a host identity certificate for each of a set of storage devices coupled to the host device and including the first storage device. The method further includes: for each of the storage devices, receiving a second host signature and a certificate signing request; and generating a host identity certificate based on verification of the second host signature and providing the host identity certificate to the host device. Information items are further applied to each of the storage devices based on verification of the host identity certificate provided to the host device by the respective storage device.

[0009] Some embodiments of this application include an electronic system comprising one or more processors and a memory storing instructions thereon, the instructions, when executed by the one or more processors, causing the processors to perform any of the methods described above on a storage system (e.g., an SSD).

[0010] Some implementations include a non-transitory computer-readable storage medium storing one or more programs. The one or more programs contain instructions that, when executed by one or more processors, cause the processors to perform any of the methods described above on a storage system (e.g., an SSD).

[0011] In some embodiments, a customer-owned host device generates a pair of private and public keys and submits the public key to a server associated with the device vendor via a secure communication link. The server incorporates the public key into a firmware version containing the customer's storage functionality. The firmware version is based on previously released production code and contains the customer's public key and data associated with the customer's requested custom storage functionality (e.g., program code, user data). In some embodiments, the public key is optionally built into the firmware, which exposes a provisioning interface that allows the customer to provision the public key after downloading the firmware version. Alternatively, in some embodiments, the firmware version is production code and is implemented on a storage device associated with the host device based on a challenge-response protocol (implemented using vendor-unique (UV) commands defined by the storage device vendor). The storage device receives the firmware version and needs to complete the challenge-response protocol before custom storage functionality can be implemented on the storage device. The challenge-response protocol contains a challenge signed by the host device. The challenge was previously submitted by the host device to the server and downloaded to the storage device associated with the host device. If the storage device (specifically, the memory driver or controller) determines that the challenge was successful, then the custom memory function is implemented on the storage device. Conversely, if the storage device determines that the challenge was erroneous, then the storage device continues to skip the custom memory function and implements the existing memory function. Given that the public key is embedded in the firmware, no one is allowed to implement the custom memory function except for the storage device associated with the host device of the target client.

[0012] In some embodiments, access to custom memory functionality is cryptographically restricted to one or more target customers. The vendor guarantees that other customers will not be permitted to implement custom memory functionality. In some embodiments, the number of storage devices that can implement custom memory functionality is unlimited, especially when the host device has full authority to enable or disable custom memory functionality. Even if a server associated with the vendor accidentally exposes custom memory functionality to an unintended user who is unaware of the public key provided by the target customer, the unintended user's storage device is prohibited from implementing custom memory functionality. The host device has the flexibility to simplify the deployment of custom functionality by using the same public / private key pair across the entire fleet, or to segment the fleet by creating multiple key pairs for different fleet segments. Through these means, the server associated with the vendor can securely deploy custom memory functionality to target host devices and associated storage devices (e.g., SSDs associated with individual or data center host devices) without requiring confidentiality agreements.

[0013] These illustrative embodiments and implementations are mentioned not to limit or restrict this disclosure, but to provide examples to aid in understanding it. Additional embodiments are discussed in the detailed description and are further described herein. Attached Figure Description

[0014] To better understand the various described implementation schemes, refer to the detailed implementation methods below in conjunction with the following figures, where the same reference numerals refer to corresponding parts throughout the figures.

[0015] Figure 1 This is a block diagram of an example system module in a typical electronic system according to some embodiments.

[0016] Figure 2 This is a block diagram of a storage system of an example electronic system having one or more memory access queues according to some embodiments.

[0017] Figure 3 This is a flowchart of the deployment process of instance secure storage functionality implemented between servers, host devices, and storage devices according to some embodiments.

[0018] Figures 4A to 4B This is a flowchart of another secure storage function deployment process 400 implemented between a server, a host device, and one or more storage devices according to some embodiments.

[0019] Figure 5 This is a block diagram of an electronic system, according to some embodiments, for deploying custom memory functions to a collection of storage devices associated with a host device based on a first-come, first-served order.

[0020] Figure 6 This is a flowchart of an example method for securely implementing custom memory functions in an electronic system, according to some embodiments.

[0021] Throughout the diagram, several views are referenced by similar figure labels that indicate the corresponding parts. Detailed Implementation

[0022] Detailed reference will now be made to specific embodiments, examples of which are illustrated in the accompanying drawings. In the following detailed description, numerous non-limiting details are set forth to aid in understanding the subject matter presented herein. However, it will be apparent to those skilled in the art that various alternatives may be used without departing from the scope of the claims, and that the subject matter may be practiced without these specific details. For example, it will be apparent to those skilled in the art that the subject matter presented herein can be implemented on many types of electronic devices with data storage capabilities.

[0023] This application relates to the secure management of custom memory functions on storage devices of host devices coupled to an electronic system (e.g., a computer system). A PKI is created within the electronic system, allowing the application of asymmetric cryptography to enable custom memory functions (e.g., certain debugging features) in the electronic system's storage devices. Specifically, in some cases, the electronic system deploys custom memory functions to a target set of host devices and their associated storage devices. Examples of custom memory functions include, but are not limited to, debugging or experimental functions that help debug specific memory problems and specific memory features to be enabled on mass-market memory products owned by a target customer (e.g., SSDs manufactured in a selected batch). The use of asymmetric cryptography implements a secure method for enabling custom memory features and capabilities. Specifically, the storage device obtains an information item for implementing the custom memory function and receives a host signature and public key from the host device. The public key is used to authenticate the host signature, and based on the authentication of at least the host signature, the storage device implements the custom memory function based on the information item.

[0024] Figure 1 This is a block diagram of an example system module 100 in a typical electronic system according to some embodiments. System module 100 in this electronic device includes at least a processor module 102, a memory module 104 for storing programs, instructions, and data, an input / output (I / O) controller 106, one or more communication interfaces such as a network interface 108, and one or more communication buses 140 for interconnecting these components. In some embodiments, the I / O controller 106 allows the processor module 102 to communicate with I / O devices (e.g., a keyboard, mouse, or touchpad) via a universal serial bus interface. In some embodiments, the network interface 108 includes one or more interfaces for Wi-Fi, Ethernet, and Bluetooth networks, each allowing the electronic device to exchange data with an external source (e.g., a server or another electronic device). In some embodiments, the communication bus 140 includes a circuitry (sometimes referred to as a chipset) that interconnects and controls communication between the various system components included in system module 100.

[0025] In some embodiments, memory module 104 includes high-speed random access memory, such as DRAM, static random access memory (SRAM), double data rate (DDR) dynamic random access memory (RAM), or other random access solid-state storage devices. In some embodiments, memory module 104 includes non-volatile memory, such as one or more disk storage devices, optical disk storage devices, flash memory storage devices, or other non-volatile solid-state storage devices. In some embodiments, memory module 104, or alternatively, one or more non-volatile storage devices within memory module 104, include non-transitory computer-readable storage media. In some embodiments, system module 100 has a memory slot reserved for receiving memory module 104. Once inserted into the memory slot, memory module 104 is integrated into system module 100.

[0026] In some embodiments, system module 100 further includes one or more components selected from memory controller 110, SSD 112, hard disk drive (HDD) 114, power management integrated circuit (PMIC) 118, graphics module 120, and audio module 122. Memory controller 110 is configured to control communication between processor module 102 and memory components of the electronic device, including memory module 104. SSD 112 is configured to use integrated circuit assemblies to store data in the electronic device, and in several embodiments, they are based on NAND or NOR memory configurations. HDD 114 is a conventional data storage device for storing and retrieving digital information based on electromechanical disk. Power connector 116 is electrically coupled to receive external power. PMIC 118 is configured to modulate the received external power to other desired DC voltage levels, such as 5V, 3.3V, or 1.8V, as needed by various components or circuits within the electronic device (e.g., processor module 102). Graphics module 120 is configured to generate an output image stream to one or more display devices according to desired image / video formats. The sound module 122 is configured to facilitate the input of audio signals to and output of audio signals to an electronic device under the control of a computer program.

[0027] It should be noted that the communication bus 140 will also include various system components 110 to 122 interconnected and control communication between them.

[0028] Furthermore, those skilled in the art will recognize that other non-transitory computer-readable storage media can be used, as new data storage technologies have been developed for storing information in non-transitory computer-readable storage media within memory module 104 and SSD 112. These new non-transitory computer-readable storage media include, but are not limited to, media made of biological materials, nanowires, carbon nanotubes, and individual molecules, although the corresponding data storage technologies are currently under development and have not yet been commercialized.

[0029] Figure 2 This is a block diagram of a storage system 200 of an example electronic system having one or more memory access queues according to some embodiments. The storage system 200 is coupled to a host device 220 (e.g., Figure 1 The storage system 200 includes a processor module 102 and is configured to store instructions and data for extended periods, such as when the electronic device is in sleep, hibernation, or off. The host device 220 is configured to access and process instructions and data stored in the storage system 200 to run an operating system and execute user applications. The storage system 200 further includes a controller 202 and a plurality of memory channels 204. Each memory channel 204 includes a plurality of memory cells. The controller 202 is configured to implement firmware-level software to bridge the plurality of memory channels 204 to the host device 220. In some embodiments, the collection of memory channels 204 forms a storage device (e.g., an SSD), and the storage system 200 includes one or more storage devices.

[0030] Each memory channel 204 comprises one or more memory packages 206 (e.g., two memory dies). In this example, each memory package 206 corresponds to a memory die. Each memory package 206 comprises a plurality of memory planes 208, and each memory plane 208 further comprises a plurality of memory pages 210. Each memory page 210 comprises an ordered set of memory cells, and each memory cell is identified by a corresponding physical address. In some embodiments, the storage system 200 comprises a plurality of superblocks. Each superblock comprises a plurality of memory blocks, each of which further comprises a plurality of memory pages 210. For each superblock, the plurality of memory blocks are configured to be simultaneously written to and read from the storage system via a memory input / output (I / O) interface. Optionally, each superblock groups the memory cells distributed across the plurality of memory planes 208, the plurality of memory channels 204, and the plurality of memory dies 206. In one example, each superblock contains at least one set of memory pages, wherein each page is distributed across disparate memory dies 206, has the same die, plane, block, and page designation, and is accessed via disparate channels of the disparate memory dies 206. In another example, each superblock contains at least one set of memory blocks, wherein each memory block is distributed across disparate memory dies 206, contains multiple pages, has the same die, plane, and block designation, and is accessed via disparate channels of the disparate memory dies 206. The storage system 200 stores information about the ordered list of superblocks in a cache of the storage system 200. In some embodiments, the cache is managed by a host driver of the host device 220 and is referred to as a host-managed cache (HMC).

[0031] In some embodiments, the storage system 200 includes single-level cell (SLC) NAND flash memory, with each memory cell storing a single data bit. In some embodiments, the storage system 200 includes multi-level cell (MLC) NAND flash memory chips, with each memory cell of the MLC NAND flash memory chip storing two data bits. In one example, each memory cell of a three-level cell (TLC) NAND flash memory chip stores three data bits. In another example, each memory cell of a four-level cell (QLC) NAND flash memory chip stores four data bits. In yet another example, each memory cell of a five-level cell (PLC) NAND flash memory chip stores five data bits. In some embodiments, each memory cell may store any suitable number of data bits. Compared to non-SLC NAND flash memory chips (e.g., MLCSSD, TLC SSD, QLC SSD, PLC SSD), SSDs with SLC NAND flash memory chips operate at higher speeds, higher reliability, and longer lifespans; however, they have lower device density and higher prices.

[0032] Each memory channel 204 is coupled to a corresponding channel controller 214, which is configured to control internal and external requests for access to memory cells in the corresponding memory channel 204. In some embodiments, each memory package 206 (e.g., each memory die) corresponds to a corresponding queue 216 of memory access requests. In some embodiments, each memory channel 204 corresponds to a corresponding queue 216 of memory access requests. Furthermore, in some embodiments, each memory channel 204 corresponds to a distinct and different queue 216 of memory access requests. In some embodiments, a subset (less than all) of the plurality of memory channels 204 corresponds to a distinct queue 216 of memory access requests. In some embodiments, all of the plurality of memory channels 204 of the storage system 200 correspond to a single queue 216 of memory access requests. Each memory access request may optionally be received internally from the storage system 200 to manage the corresponding memory channel 204, or externally from the host device 220 to write or read data stored in the corresponding channel 204. Specifically, each memory access request includes one of the following: a system write request received from storage system 200 to write to the corresponding memory channel 204; a system read request received from storage system 200 to read from the corresponding memory channel 204; a host write request originating from host device 220 to write to the corresponding memory channel 204; and a host read request received from host device 220 to read from the corresponding memory channel 204. It should be noted that system read requests (also known as background read requests or non-host read requests) and system write requests are scheduled by the memory controller to implement internal memory management functions, including but not limited to garbage collection, wear leveling, read interference mitigation, memory snapshot capture, memory mirroring, caching, and memory spare.

[0033] In some embodiments, in addition to channel controller 214, controller 202 further includes a local memory processor 218, a host interface controller 222, an SRAM buffer 224, and a DRAM controller 226. The local memory processor 218 accesses multiple memory channels 204 based on one or more queues 216 of memory access requests. In some embodiments, the local memory processor 218 writes to and reads from the multiple memory channels 204 on a block-by-block basis. Data from one or more memory blocks is jointly written to or jointly read from the multiple channels. No data in the same memory block is simultaneously written via more than one operation. Each memory block optionally corresponds to one or more memory pages. In one example, each memory block to be jointly written to or read in multiple memory channels 204 has a size of 16 KB (e.g., one memory page). In another example, each memory block to be jointly written to or read in multiple memory channels 204 has a size of 64 KB (e.g., four memory pages). In some embodiments, each page has 16 KB of user data and 2 KB of metadata. In addition, the number of memory blocks to be accessed jointly and the size of each memory block can be configured for each of the system read, host read, system write, and host write operations.

[0034] In some embodiments, the local memory processor 218 stores data to be written to or read from each of the plurality of memory channels 204 in an SRAM buffer 224 of the controller 202. Alternatively, in some embodiments, the local memory processor 218 stores data to be written to or read from each of the plurality of memory channels 204 in a DRAM buffer 228 in the storage system 200. Alternatively, in some embodiments, the local memory processor 218 stores data to be written to as a result of processing by the processor module 102 ( Figure 1 The DRAM buffer 228 of the main memory is used to access data in or read from each of the multiple memory channels 204 in the DRAM buffer 228. The local memory processor 218 of the controller 202 accesses the DRAM buffer 228 via the host interface controller 222.

[0035] In some embodiments, data in the plurality of memory channels 204 are divided into coded blocks, and each coded block is called a codeword. For example, each codeword contains n Position, among which k The bit corresponds to user data, and ( n - k ) corresponds to the integrity data of user data, where k and nIt is a positive integer. In some embodiments, the storage system 200 includes an integrity engine 230 (e.g., an LDPC engine) and a register 232, which contains multiple registers or SRAM cells or flip-flops and is coupled to the integrity engine 230. The integrity engine 230 is coupled to the memory channel 204 via a channel controller 214 and an SRAM buffer 224. Specifically, in some embodiments, the integrity engine 230 has a data path connection to the SRAM buffer 224, which is also connected to the channel controller 214 via a data path controlled by a local memory processor 218. The integrity engine 230 is configured to verify the data integrity of each coded block of the memory channel 204.

[0036] Figure 3 This is a flowchart of an instance secure storage function deployment process 300 implemented between server 302, host device 220, and storage device 304 according to some embodiments. Host device 220 is coupled to a storage system 200 comprising one or more storage devices 304 (e.g., one or more SSDs) and a controller 202. Controller 202 is configured to receive storage access requests from host device 220 and access one or more storage devices 304 in response to the requests. In some embodiments, server 302 is associated with a vendor of storage device 304, and host device 220 is associated with a customer (i.e., a user) who purchases storage device 304 from the vendor. Storage device 304 is located near and physically coupled to host device 220, while server 302 is located remotely from host device 220 and storage system 200. Server 302 communicates with host device 220 and storage system 200 via one or more wireless communication networks. In some embodiments, storage device 304 obtains (operation 320) information items 316 (e.g., program code, user data, signature, public key, and metadata) for implementing custom memory functions (e.g., debugging memory errors). Storage device 304 receives (operation 324) a host signature 326 and a public key 308 from host device 220, and authenticates (operation 328) the host signature 326 using the public key 308. Based on the authentication of at least the host signature 326, storage device 304 implements (operation 330) the custom memory functions based on information items 316.

[0037] In some embodiments, host device 220 generates a key pair containing a public key 308 and a private key 310 associated with the public key 308, and distributes the public key 308 to server 302, for example, via one or more communication networks (operation 312), without involving storage device 304 coupled to host device 220. Server 302 associates information item 316 for implementing custom memory functionality with public key 308 (operation 314). In an example, information item 316 for implementing custom memory functionality includes debug firmware, for example, in the form of microcode or a program to be embedded in storage device 304 to debug errors in the storage device. In some embodiments, public key 308 is applied to generate (operation 318) a signature associated with the debug firmware. Information item 316 and / or the signature is provided (operation 320) to storage device 304 (e.g., via host device 220). Specifically, in some cases, host device 220 provides public key 308 to server 302, receives information item 316 and public key 308 from server 302, and forwards information item 316 and public key 308 as binary files to the firmware of storage device 304. Alternatively, in some embodiments, storage device 304 directly downloads information item 316, public key 308, and / or associated signature from server 302. In some embodiments, storage device 304 sends an acknowledgment message (operation 322) to host device 220 after successfully obtaining information item 316, public key 308, and / or associated signature.

[0038] More specifically, in some embodiments, server 302 generates a signature associated with public key 308. Information item 316 is concatenated with the signature associated with public key 308 and sent to storage device 304 (e.g., via host device 220). Furthermore, in some embodiments, server 302 encrypts information item 316 using public key 308. The encrypted information item 316 is combined with the signature associated with public key 308 and sent to storage device 304 (e.g., via host device 220).

[0039] After receiving information item 316, storage device 304 also receives (operation 324) host signature 326 and public key 308 from host device 220. Storage device 304 uses public key 308 to authenticate (operation 328) host signature 326. Based on the authentication of at least host signature 326, storage device 304 implements (operation 330) a custom memory function based on information item 316. In some embodiments, information item 316 contains program code implemented to implement the custom memory function. Alternatively, in some embodiments, information item 316 for implementing the custom memory function does not contain program code or software. The custom memory function includes multiple features that have been distributed to storage device 304. Information item 316, sent along with the signature, includes metadata that provides an additional granular layer for enabling the custom memory function. For example, the metadata is provided by host device 220 and includes an enable signal for one of the multiple features for the custom memory function. Additionally, alternatively, in some embodiments, multiple custom memory functions are deployed to storage device 304. Storage device 304 receives information item 316 containing function identifier and selects a custom memory function based on the function identifier.

[0040] In some embodiments, information item 316 is associated with public key 308. Public key 308 is verified (operation 332). Information item 316 is applied to implement custom storage functionality based on verification using public key 308. In some embodiments, information item 316 is signed based on public key 310. From a cryptographic perspective, the integrity of information item 316 is associated with public key 308 during its transmission between server 302, host device 220, and storage device 304 (e.g., through signing and signature verification). If information item 316 needs to remain confidential (e.g., if only server 302 and storage device 304 can see information item 316), then information item 316 needs to be encrypted and decrypted.

[0041] In some embodiments, storage device 304 sends a random number 336 (operation 334) to host device 220, for example, in response to a request 338 from host device 220. Host signature 326 is generated by host device 220 based on random number 336, private key 310 associated with public key 308, or both. In addition to host signature 326 and public key 308, storage device 304 also receives (operation 324) random number 336. Random number 336 is verified separately and together with host signature 326 (operation 340). Both random number 336 and host signature 326 are verified to increase the security level of the deployment of information item 316. In some embodiments, random number 336 is any number that can be used once in encrypted communication. Random number 336 may optionally be a random number or pseudo-random number issued in an authentication protocol to ensure that old communications cannot be reused in replay attacks.

[0042] In some embodiments, the secure storage function deployment process 300 includes two phases: a preparation phase 342 and a feature activation phase 344. In the preparation phase 342, information item 316 and public key 308 provided by host device 220 are successfully provided to server 302, which distributes them to storage device 304 associated with host device 220. In the feature activation phase 342, host device 220 provides public key 308 and host signature 326 separately to storage device 304. If the host signature 326 and / or public key 308 obtained from host device 220 in phase 344 are verified in reference to the public key 308 obtained from server 302 in phase 342, then information item 316 is verified.

[0043] This application relates to the secure management of custom memory functions on storage device 304 of host device 220 coupled to an electronic system (e.g., a computer system). A PKI is created within the electronic system, allowing the application of asymmetric cryptography to enable custom memory functions (e.g., certain debugging features) within the storage device 304 of the electronic system. Examples of custom memory functions include, but are not limited to, debugging or experimental functions that aid in debugging specific memory problems and specific memory features to be enabled on mass-market memory products owned by a target customer (e.g., SSDs manufactured in selected batches). The use of asymmetric cryptography enables secure methods for enabling custom memory features and capabilities.

[0044] In some embodiments, a customer-owned host device 220 generates a pair of private keys 310 and public keys 308, and submits the public key 308 to a server 302 associated with a storage device vendor via a secure communication link. The server 302 incorporates the public key 308 into a firmware version containing custom memory functionality. The firmware version is based on previously released production code and includes the customer's public key 308 and information items 316 (e.g., program code, user data, metadata) associated with the custom memory functionality requested by the customer. In some embodiments, the public key 308 may optionally be built into the firmware, which exposes a provisioning interface that allows the customer to provision the public key 308 after downloading the firmware version. Alternatively, in some embodiments, the firmware version is production code and is implemented on a storage device 304 associated with the host device 220 based on a challenge-response protocol (implemented using VU commands). The storage device 304 receives the firmware version and needs to complete the challenge-response protocol before the custom memory functionality can be implemented on the storage device 304. The challenge-response protocol contains a challenge signed by the host device 220. The challenge was previously submitted by host device 220 to server 302 and downloaded to storage device 304 associated with host device 220. If storage device 304 (specifically, a memory driver or controller) determines the challenge was successful, then a custom memory function is implemented on storage device 304. Conversely, if storage device 304 determines the challenge is incorrect, then storage device 304 continues to skip the custom memory function and implements the existing memory function. Given that the public key is embedded in the firmware, no one other than storage device 304 associated with the target client's host device 220 is allowed to implement the custom memory function.

[0045] Figures 4A to 4B This is a flowchart of another secure storage function deployment process 400 implemented between server 302, host device 220, and one or more storage devices 304 according to some embodiments. Host device 220 is coupled to a controller 202 that includes one or more storage devices 304 (e.g., one or more SSDs). Figure 2 The storage system 200 is configured to receive memory access requests from host device 220 and access one or more storage devices 304 in response to the requests. In some embodiments, server 302 is associated with a vendor of storage device 304, and host device 220 is associated with a customer (i.e., a user) who purchases one or more storage devices 304 from the vendor. One or more storage devices 304 are located near and physically coupled to host device 220 to form storage system 200, while server 302 is located away from host device 220 and storage system 200 and communicates with host device 220 and storage system 200 via one or more wireless communication networks. In some embodiments, storage device 304 obtains (operation 402, Figure 4A Information item 316 is used to implement custom memory functions. Storage device 304 receives (operation 404) from host device 220. Figure 4B The host signature is 326 and the public key is 308, and authentication is performed using the public key 308 (Operation 406). Figure 4B Host signature 326. Based on authentication of at least host signature 326, storage device 304 performs (operation 408) based on information item 316. Figure 4B Custom memory functionality.

[0046] In some embodiments, information item 316 includes one or more of the following: program code, user data, signature, public key, and metadata. In some embodiments, information item 316 includes multiple debugging instructions and associated debugging data, and a custom memory function is implemented to debug errors in storage device 304 using the multiple debugging instructions and associated debugging data. Alternatively, in some embodiments, information item 316 includes multiple storage instructions, and the custom memory function includes custom storage characteristics associated with storage device 304. An example of storage device 304 is an SSD.

[0047] Figure 4A and Figure 4B The storage device 304 shown includes a first storage device 304A. A host device 220 is coupled to a plurality of storage devices 304, and a subset of the plurality of storage devices 304 includes the first storage device 304A. Custom memory functionality is implemented at each of the subsets of storage devices 304 based on authentication of at least a corresponding host signature 326 issued by the host device 220. Additionally, the host device 220 selects a subset of storage devices 304 based on a first-come, first-served order by obtaining a host identity certificate 410 from each of the subsets of storage devices 304. The host identity certificate 410 is authenticated (operation 412) before the storage devices 304 implement (operation 408) the custom memory functionality based on information item 316.

[0048] In some embodiments, the secure storage function deployment process 400 includes three phases: a preparation phase 414, an authorization phase 416, and a feature activation phase 418. In the preparation phase 414, an information item 316 is provided (operation 402) to a storage device 304 associated with a host device 220. In this example, the information item 316 contains firmware with customer-specific features, and the storage device 304 installs the firmware upon receiving the information item 316. In the authorization phase 416, the host device 220 selects a subset of storage devices 304 for implementing the custom storage function associated with the information item 316. The host device 220 selects the subset of storage devices 304 based on a first-come, first-served order by obtaining (operation 420) a host identity certificate 410 from each of the subsets of storage devices 304. In the feature activation phase 418, a host signature 326 is provided separately by the host device 220 to the storage device 304. If signature 326 and host identity certificate 410 are verified, then information item 316 is verified (operations 406 and 412).

[0049] In some embodiments, storage device 304 includes a first storage device 304A. A set of storage devices 304 is coupled to host device 220 and includes the first storage device 304A. Each of the storage devices 304 (e.g., the first storage device 304A) receives from host device 220 a Certificate Signing Request (CSR) 422 for a host identity certificate 410 (customer_cert) issued by the respective storage device 304. The Certificate Signing Request 422 and a second host signature 426 are received (operation 424). In some embodiments, the Certificate Signing Request 422 is generated based on host identification information 428 (e.g., customer_info) and a public key 308, and the second host signature 426 is generated based on the Certificate Signing Request 422 and the private key 310 of host device 220. In some embodiments, a certificate signing request 422 and a second host signature 426 are concatenated to generate a signed certificate signing request 422' (e.g., Signed_CSR), and the signed certificate signing request is sent (operation 424) to each of the set of storage devices 304. Based on the verification 432 of the second host signature 426, storage device 304A generates a host identity certificate 410 and provides the host identity certificate 410 to host device 220 (operation 420). During the subsequent feature activation phase 418, information item 316 is applied to each of the set of storage devices 304 based on the verification 412 of the host identity certificate 410 provided to host device 220 by the respective storage device 304.

[0050] In some embodiments, the host signature 326 generated during the feature enablement phase 418 is a first host signature 326 used to verify the host identity certificate 410. A second host signature 426 and a certificate signing request 422 for generating the host identity certificate 410 are received. During the authorization phase 416, the storage device 304 verifies (operation 432) the second host signature 426 using the public key 308. Based on the verification 432 of the second host signature 426, the host identity certificate 410 is generated and provided to the host device 220. Furthermore, in some embodiments, the certificate signing request 422 includes at least information about the host device (e.g., host identification information 428 (customer_info)), and the host identity certificate 410 is generated based on this information. In some embodiments, the storage device 304 further generates a memory signature 434 based on the host identity certificate 410 and the storage device 304's private key 436. The storage device 304 provides the memory signature 434 together with the host identity certificate 410 to the host device 220. In some embodiments, storage device 304 concatenates host identity certificate 410 and storage signature 434 to generate a signed host identity certificate 410'.

[0051] In some embodiments, during the authorization phase 416, after the host identity certificate 410 is provided to the host device 220, each of the collection of storage devices 304 (e.g., the first storage device 304A) receives (operation 438) a certificate denial-of-reversal request 440 and confirms (operation 442) that the storage device 304 will not provide any identity certificate or will not link to a different electronic system.

[0052] It should be noted that the host identity certificate 410 is signed with the private key 436 of the storage device 304. When the host identity certificate 410 enters the feature enablement phase 418, the host identity certificate 410 is signed with the private key 436, thereby enabling the same storage device 304 to verify that the host identity certificate 410 was previously signed (authorized) by the same storage device 304. To clarify, during the feature enablement phase 418, the storage device 304 receives the host identity certificate 410 and the memory signature 434, as well as the first host signature 326, and verifies the host identity certificate 410 and the memory signature 434 based on the private key 436 of the storage device 304. Based on the authentication 406 of the host signature 326 and the verification 412 of the signed host identity certificate 410' (e.g., the host identity certificate 410 and the memory signature 434), the application information item 316 is used to implement custom memory functionality.

[0053] Figure 5This is a block diagram of an electronic system 500, according to some embodiments, for deploying custom memory functions to a set of storage devices 304 associated with a host device 220 based on a first-come, first-served order. The host device 220 is coupled to a plurality of storage devices 304 comprising a subset of storage devices 304S. Custom memory functions are implemented at each of the subsets of storage devices 304 based on authentication of at least a corresponding host signature 326 issued by the host device 220. Furthermore, the host device 220 selects the subset of storage devices 304S based on a first-come, first-served order by obtaining a host identity certificate 410 from each of the subsets of storage devices 304S.

[0054] In some embodiments, host device 220 is coupled to 32 SSDs, and server 302 confirms that host device 220 can enable custom memory functionality on 10 selected SSDs of its 32 SSDs, without specifically identifying the 10 selected SSDs. First, 10 SSDs of host device 220 are selected to provide signed host identity certificates 410' for implementing the custom memory functionality. After host device 220 has collected 10 signed host identity certificates 410' from different storage devices 304, host device 220 does not collect additional host identity certificates 410' from the remaining 22 SSDs. Each remaining SSD cannot receive a signed host identity certificate 410 from host device 220 during the feature enablement phase 418, nor can each remaining SSD verify the host identity certificate 410, host signature 326, or both, to enable the custom memory functionality associated with information item 316.

[0055] More specifically, each of the storage devices 304S (e.g., the first storage device 304A) receives from the host device 220 a certificate signing request 422 (signed or unsigned) for a host identity certificate 410 (customer_cert) issued by the corresponding storage device 304S. The certificate signing request 422 and the second host signature 426 are received (operation 424). In some embodiments, the certificate signing request 422 is generated based on host identification information 428 (e.g., customer_info) and the public key 308, and the second host signature 426 is generated based on the certificate signing request 422 and the private key 310 of the host device 220. In some embodiments, the certificate signing request 422 and the second host signature 426 are concatenated to generate a signed certificate signing request 422' (e.g., Signed_CSR), and the signed certificate signing request is sent (operation 424) to each of the storage devices 304S. Based on the verification 432 of the second host signature 426, the storage device 304S generates a host identity certificate 410 and provides the host identity certificate 410 (signed or unsigned) (operation 420). Figure 4A) to host device 220.

[0056] During authorization phase 416, storage device 304S uses public key 308 for authentication (operation 432, Figure 4A Second host signature 426. Based on the verification 432 of the second host signature 426, a host identity certificate 410 is generated and provided to the host device 220. Furthermore, in some embodiments, the certificate signing request 422 includes at least information about the host device (e.g., host identification information 428 (customer_info)), and the host identity certificate 410 is generated based on this information. In some embodiments, the storage device 304S further generates a memory signature 434 based on the host identity certificate 410 and the storage device 304S's private key 436. The storage device 304S provides the memory signature 434 together with the host identity certificate 410 to the host device 220. In some embodiments, the storage device 304S concatenates the host identity certificate 410 and the memory signature 434 to generate a signed host identity certificate 410'. After providing the host identity certificate 410 to the host device 220, each of the storage devices 304S (e.g., the first storage device 304A) receives (operation 438, Figure 4A Certificate refusals to reverse request 440, and confirmation (operation 442, Figure 4A Storage device 304 will not provide any identity certificate or will not be linked to different electronic systems.

[0057] Figure 6 This is a flowchart of an example method 600 for securely implementing custom memory functionality in an electronic system according to some embodiments. Storage device 304 is coupled to host device 220 in the electronic system. Storage device 304 obtains (operation 602) information item 316 for implementing custom memory functionality, receives (operation 604) a host signature 326 and a public key 308 from host device 220, and authenticates (operation 606) the host signature 326 using the public key 308. Based on the authentication of at least the host signature 326, storage device 304 implements (operation 608) the custom memory functionality based on information item 316. Alternatively, from the perspective of host device 220, host device 220 generates a key pair containing a public key 308 and a private key 310, generates a host signature 326 using the private key 310, sends the host signature 326 and the public key 308 to storage device 304, and enables storage device 304 to implement custom memory functionality using information item 316 based on the authentication of at least the host signature 326.

[0058] In some embodiments, information item 316 is associated with public key 308, and information item 316 is applied to implement (operation 610) a custom memory function based on verification of public key 308. Additionally, in some embodiments, storage device 304 obtains information item 316. Host device 220 is configured to provide public key 308 to server 302, receive information item 316 and public key 308 from server 302, and forward information item 316 and public key 308 to be stored as a binary file in the firmware of storage device 304. Alternatively, in some embodiments, storage device 304 downloads information item 316 and public key 308 directly from server 302. Host device 220 is configured to provide public key 308 to server 302, and server 302 is configured to generate information item 316 using public key 308.

[0059] In some embodiments, host device 220 generates a key pair containing public key 308 and private key 310, and generates host signature 326 based on private key 310.

[0060] In some embodiments, storage device 304 sends a random number to host device 220. Host signature 326 is generated by host device 220 based on the random number and private key 310 associated with public key 308. In addition to host signature 326 and public key 308, storage device 304 also receives a random number, which is verified separately and together with host signature 326.

[0061] In some embodiments, storage device 304 receives a function identifier and selects a custom memory function based on the function identifier, for example, from a plurality of custom memory functions locally stored on storage device 304.

[0062] In some embodiments, storage device 304 includes a first storage device 304A. Host device 220 is coupled to a plurality of storage devices 304, and a subset of the plurality of storage devices includes the first storage device 304A. Custom memory functionality is implemented (operation 612) at each of the subsets of storage devices 304 based on authentication of at least a corresponding host signature 326 issued by host device 220. Host device 220 selects (operation 614) the subset of storage devices based on a first-come, first-served order by obtaining host identity certificate 410 from each of the subsets of storage devices.

[0063] In some embodiments, storage device 304 includes a first storage device 304A. Each of the set of storage devices 304S is coupled to host device 220 and includes the first storage device 304A. Each of the set of storage devices 304S receives from host device 220 a certificate signing request 422 for a host identity certificate 410 issued by the corresponding storage device 304A, and receives a second host signature 426 and the certificate signing request 422. Based on the verification of the second host signature 426, storage device 304A generates a host identity certificate 410 and provides the host identity certificate 410 to host device 220. Further based on the verification of the host identity certificate 410 provided to host device 220 by the corresponding storage device 304S, information item 316 is applied to each of the set of storage devices 304A.

[0064] In some embodiments, host signature 326 includes a first host signature. Storage device 304 receives a certificate signing request 422 from host device 220 for host identity certificate 410 from storage device 304. Storage device 304 receives a second host signature 426 and certificate signing request 422, and uses public key 308 to verify the second host signature 426. Based on the verification of the second host signature 426, storage device 304 verifies host identity certificate 410 and provides host identity certificate 410 to host device 220. Furthermore, in some embodiments, certificate signing request 422 includes at least information about host device 220, and host identity certificate 410 is generated based on the information about host device 220. In some embodiments, storage device 304 generates storage signature 434 based on host identity certificate 410 and private key 310 of storage device 304. Figure 4A The storage device 304 receives the host identity certificate 410, the storage signature 434, and the first host signature 326, and verifies the host identity certificate 410 and the storage signature 434 based on the private key 436 of the storage device 304. Based on the authentication of the host signature 326 and the verification of the host identity certificate 410 and the storage signature 434, application information item 316 is applied to implement (operation 616) a customized storage function. Furthermore, a second host signature 426 is generated based on the certificate signing request 422 and the private key 310 of the host device 220. In some embodiments, after providing the host identity certificate 410 to the host device 220, the storage device 304 receives a certificate reversal request and confirms that the storage device 304 will not provide any identity certificate or will not link to a different electronic system.

[0065] In some embodiments, information item 316 includes multiple debugging instructions and associated debugging data, and the custom memory function is implemented to debug errors in storage device 304 using multiple debugging instructions and associated debugging data.

[0066] In some embodiments, information item 316 includes multiple storage instructions, and custom memory features include custom storage characteristics associated with storage device 304.

[0067] This application relates to the secure management of custom memory functions on storage devices 304 of host device 220 coupled to an electronic system (e.g., a computer system). A PKI is created within the electronic system, allowing the application of asymmetric cryptography to enable custom memory functions (e.g., certain debugging features) within the electronic system's storage device 304. Specifically, in some cases, the electronic system deploys custom memory functions to a set of target host devices and their associated storage devices. Examples of custom memory functions include, but are not limited to, debugging or experimental functions that help debug specific memory problems and specific memory features to be enabled on mass-market memory products owned by target customers (e.g., SSDs manufactured in selected batches).

[0068] Access to custom storage functionality is password-protected and limited to one or more target customers. The vendor guarantees that other customers will not be permitted to implement custom storage functionality. In some embodiments, the number of storage devices that can implement custom storage functionality is unlimited, especially when the host device has full authority to enable or disable custom storage functionality. Even if the vendor-associated server 302 accidentally exposes custom storage functionality to an unintended user who is unaware of the public key provided by the target customer, the unintended user's storage device is prohibited from implementing custom storage functionality. The host device has the flexibility to simplify the deployment of custom functionality by using the same public / private key pair across the entire fleet, or to segment the fleet by creating multiple key pairs for different fleet segments. Through these means, the vendor-associated server 302 can securely deploy custom storage functionality to target host devices and associated storage devices (e.g., SSDs associated with individual or data center host devices) without requiring confidentiality agreements.

[0069] In some embodiments, each of the server 302, the host device, and the storage device possesses cryptographic capabilities, including one or more of the following: digital certificate generation (e.g., according to X.509), asymmetric key pair generation (e.g., using RSA or ECDSA), key wrapping and unwrapping (e.g., using NIST SP600-38F), deterministic random bit generation (e.g., according to NIST SP600-90A, 90B, 90C), and digital signature verification (e.g., according to FIPS 186-4). The public key is supplied in a secure environment. For example, the public key is generated in a host device at a secure location within the customer's premises and is securely transmitted to the server 302 associated with the vendor before being incorporated into the firmware version.

[0070] The memory also stores instructions and data associated with method 600 and includes high-speed random access memory, such as DRAM, SRAM, DDR RAM, or other random access solid-state storage devices; and optionally, includes non-volatile memory, such as one or more disk storage devices, one or more optical disk storage devices, one or more flash memory devices, or one or more other non-volatile solid-state storage devices. Optionally, the memory includes one or more storage devices located remotely from one or more processing units. The non-volatile memory within the memory, or alternatively the memory itself, includes a non-transitory computer-readable storage medium. In some embodiments, the memory or the non-transitory computer-readable storage medium of the memory stores programs, modules, and data structures, or subsets or supersets, for implementing method 600.

[0071] Each of the elements identified above may be stored in one or more of the previously mentioned storage devices and corresponds to a set of instructions for performing the functions described above. The modules or programs identified above (i.e., the instruction sets) need not be implemented as separate software programs, procedures, modules, or data structures, and therefore various subsets of these modules may be combined or otherwise rearranged in various embodiments. In some embodiments, the memory may optionally store a subset of the modules and data structures identified above. Furthermore, the memory may optionally store additional modules and data structures not described above.

[0072] The terminology used in the description of the various embodiments described herein is for the purpose of describing particular embodiments only and is not intended to be restrictive. As used in the description of the various described embodiments and the appended claims, the singular forms “a,” “an,” and “the” are also intended to include the plural forms, unless the context clearly indicates otherwise. It should also be understood that, as used herein, the term “and / or” refers to and covers any and all possible combinations of one or more of the associated listed items. It should be further understood that the terms “includes,” “including,” “comprises,” and / or “comprising,” when used in this specification, specify the presence of stated features, integers, steps, operations, elements, and / or components, but do not exclude the presence or addition of one or more other features, integers, steps, operations, elements, components, and / or groups thereof. Additionally, it should be understood that although the terms “first,” “second,” etc., may be used herein to describe various elements, these elements should not be limited by these terms. These terms are used only to distinguish one element from another.

[0073] As used herein, depending on the context, the term "if" may optionally be understood as meaning "when," "after," "in response to determining," "in response to detecting," or "according to determining." Similarly, depending on the context, the phrase "if determining" or "if [the stated condition or event] is detected" may optionally be understood as meaning "after determining," "in response to determining," "after detecting [the stated condition or event]," "in response to detecting [the stated condition or event]," or "according to determining that [the stated condition or event] is detected."

[0074] For illustrative purposes, the foregoing description has been described with reference to specific embodiments. However, the foregoing illustrative discussion is not intended to be exhaustive or to limit the claims to the precise form disclosed. In view of the foregoing teachings, many modifications and variations are possible. The embodiments were chosen and described in order to best explain the operating principles and practical applications, thereby enabling others skilled in the art to make their own.

[0075] Although the diagrams show several logical stages in a specific order, stages that are not sequentially related can be reordered, and other stages can be combined or decomposed. While some reorderings or other groupings are specifically mentioned, other reorderings or groupings will be obvious to those skilled in the art, and therefore the orderings and groupings presented herein are not an exhaustive list of alternatives. Furthermore, it should be recognized that stages can be implemented in hardware, firmware, software, or any combination thereof.

Claims

1. A method comprising: at a storage device coupled to a host device in an electronic system: obtaining an item of information for implementing a custom memory function; receiving a host signature and a public key from the host device; authenticating the host signature using the public key; and based on the item of information, performing the custom memory function in accordance with authentication of at least the host signature.

2. The method of claim 1, wherein the item of information is associated with the public key, and the item of information is applied to implement the custom memory function in accordance with verification of the public key.

3. The method of claim 2, further comprising: obtaining, by the storage device, the item of information, wherein the host device is configured to provide the public key to a server, receive the item of information and the public key from the server, and forward the item of information and the public key for storage as a binary file in firmware of the storage device.

4. The method of claim 2 or 3, further comprising: downloading, by the storage device, the item of information and the public key directly from a server, wherein the host device is configured to provide the public key to the server, and the server is configured to generate the item of information using the public key.

5. The method of any of claims 1-4, further comprising at the host device: generating a key pair including the public key and a private key; and generating the host signature based on the private key.

6. The method of any of claims 1-5, further comprising at the storage device: sending a random number to the host device, wherein the host signature is generated by the host device based on the random number and a private key associated with the public key; and receiving the random number in addition to the host signature and the public key, wherein the random number is verified separately and with the host signature.

7. The method of any of claims 1-6, wherein: the storage device includes a first storage device; the host device is coupled to a plurality of storage devices, and a subset of the plurality of storage devices includes the first storage device; the custom memory function is performed at each of the subset of storage devices in accordance with authentication of at least a respective host signature issued by the host device; and the method further comprises selecting, by the host device, the subset of storage devices based on a first-come-first-served order by obtaining a host identity certificate from each of the subset of storage devices.

8. The method of any of claims 1-7, the host signature including a first host signature, the method further comprising at the storage device: receiving a certificate signing request from the host device for a host identity certificate issued by the storage device; receiving a second host signature and the certificate signing request; verifying the second host signature using the public key; and in accordance with verification of the second host signature, generating the host identity certificate and providing the host identity certificate to the host device. ​ 9. The method of claim 8, wherein the certificate signing request includes at least information of the host device, and the host identity certificate is generated based on the information of the host device.

10. The method of claim 8 or 9, further comprising: generating a memory signature based on the host identity certificate and a private key of the storage device; and jointly providing the memory signature and the host identity certificate to the host device.

11. The method of claim 10, further comprising: receiving the host identity certificate and the memory signature and the first host signature; and verifying the host identity certificate and the memory signature based on the private key of the storage device; wherein the item of information is applied to implement the custom memory function based on authentication of the host signature and verification of the host identity certificate and the memory signature.

12. The method of any of claims 1-11, the host signature including a first host signature, the method further comprising at the storage device: receiving a certificate signing request from the host device for a host identity certificate from the storage device; receiving a second host signature and the certificate signing request; verifying the second host signature using the public key; and generating the host identity certificate based on verification of the second host signature and providing the host identity certificate to the host device.

13. The method of claim 12, wherein the second host signature is generated based on the certificate signing request and a private key of the host device.

14. The method of claim 12 or 13, further comprising after providing the host identity certificate to the host device: receiving a certificate revocation request; and confirming that the storage device will not provide any identity certificate or will not link to a different electronic system.

15. The method of any of claims 1-14, wherein the item of information includes a plurality of debug instructions and associated debug data, and the custom memory function is implemented to debug an error of the storage device using the plurality of debug instructions and the associated debug data.

16. The method of any of claims 1-15, wherein the item of information includes a plurality of storage instructions, and the custom memory function includes a custom storage feature associated with the storage device.

17. The method of any of claims 1-16, wherein the storage device includes a first storage device, the method further comprising at each of a set of storage devices coupled to the host device and including the first storage device: receiving a certificate signing request from the host device for a host identity certificate issued by the respective storage device; receiving a second host signature and the certificate signing request; generating the host identity certificate based on verification of the second host signature and providing the host identity certificate to the host device; ​ ​ wherein the information item is further applied at each of the set of storage devices in dependence on verification of the host identity certificate provided by the respective storage device to the host device.

18. The method of any of claims 1-17, further comprising, at the storage device: receiving a function identifier; and selecting the custom memory function based on the function identifier.

19. An electronic system, comprising: one or more processors; and memory storing one or more programs for execution by the one or more processors, the one or more programs including instructions for performing the method of any of claims 1-18 at a storage device coupled to a host device in the electronic system.

20. A non-transitory computer-readable storage medium storing one or more programs for execution by one or more processors, the one or more programs further including instructions for performing the method of any of claims 1-18 at a storage device coupled to a host device in an electronic system.

Images