Vendor-independent facility for application access to secure memory devices

Abstract

The present disclosure relates to vendor-independent facilities for applications to access secure memory devices. A system, apparatus, and method to provide vendor-independent access to secure memory devices via an abstraction layer, which can be implemented via an operating system kernel and one or more utilities. Upon receiving a request to perform a function, the abstraction layer uses parameters provided in the request to generate at least one first command in a format independent of a specification of the memory device. The at least one first command is provided to a device driver of the memory device identified in the request, causing the memory device to generate at least one second command to the memory device according to the specification of the memory device. The second command includes a signature generated using a portion of the second command; and the function is implemented by executing the at least one second command in the memory device.

Description

[0001] Related Applications

[0002] This application claims priority to provisional U.S. Patent Application Serial No. 63 / 194,417, filed May 28, 2021, the entire disclosure of which is hereby incorporated by reference herein. TECHNICAL FIELD

[0003] At least some embodiments disclosed herein generally relate to accessing secure memory devices, and more particularly, but not by way of limitation, to techniques that allow applications to access secure memory devices in a manner that is independent of implementation or specification from different manufacturers of secure memory devices. BACKGROUND

[0004] A memory sub-system can include one or more memory devices that store data. For example, the memory devices can be non-volatile memory devices and volatile memory devices. Generally, a host system can utilize a memory sub-system to store data at and retrieve data from the memory devices. SUMMARY

[0005] In one aspect, the disclosure relates to a method comprising: receiving, in an abstraction layer implemented for a memory device configured with encryption-based access control, a request to perform a function, the request including one or more parameters and identifying the memory device; generating, by the abstraction layer, at least one first command using the one or more parameters in a format independent of a command timing, format, or syntax configuration of the memory device; identifying, by the abstraction layer, a device driver for the memory device; and transmitting the at least one first command to the device driver to cause the device driver to generate at least one second command to the memory device according to the command timing, format, or syntax configuration of the memory device, the second command including a signature generated using a portion of the second command, wherein the function is implemented by executing the at least one second command in the memory device.

[0006] In another aspect, the disclosure relates to a non-transitory storage medium storing instructions that, when executed on a computing device, cause the computing device to perform a method comprising: receiving, in an abstraction layer implemented for a memory device configured with encryption-based access control, a request to perform a function, the request including one or more parameters and identifying the memory device; generating, by the abstraction layer, at least one first command using the one or more parameters in a format independent of a command and response timing, format, or syntax configuration of the memory device; identifying, by the abstraction layer, a device driver for the memory device; and sending the at least one first command to the device driver to cause the device driver to generate at least one second command to the memory device according to the command and response timing, format, or syntax configuration of the memory device, the second command including a signature generated using a portion of the second command, wherein the function is implemented by executing the at least one second command in the memory device.

[0007] In another aspect, the disclosure relates to a device comprising: a memory device; and at least one microphone configured via instructions to: receive, in an abstraction layer implemented for a memory device configured with encryption-based access control, a request to perform a function, the request including one or more parameters and identifying the memory device; generate, by the abstraction layer, at least one first command using the one or more parameters in a format independent of manufacturer specifications regarding a command and response timing, format, or syntax configuration for the memory device; identify, by the abstraction layer, a device driver for the memory device; and send the at least one first command to the device driver to cause the device driver to generate at least one second command to the memory device according to the manufacturer specifications for the memory device, the second command including a signature generated using a portion of the second command, wherein the function is implemented by executing the at least one second command in the memory device. BRIEF DESCRIPTION OF DRAWINGS

[0008] Embodiments are illustrated by way of example, and not by way of limitation, in the figures of the accompanying drawings in which like references indicate similar elements. FIG. 1 illustrates an example system for a secure memory device.

[0009] Figure 1 A system is shown with an abstraction layer for a secure memory device to allow applications to access the secure memory device in a manner independent of the hardware implementation of the secure memory device.

[0010] Figure 2 A command and response structure for accessing a secure memory device is illustrated for one embodiment.

[0011] Figure 3An integrated circuit memory device with a security manager is described according to one embodiment.

[0012] Figure 4 Techniques to control execution of commands in a memory device are described according to one embodiment.

[0013] Figure 5 A method of accessing a secure memory device is shown according to one embodiment.

[0014] Figure 6 An example computing system with a memory subsystem is described according to some embodiments of the disclosure.

[0015] Figure 7 is a block diagram of an example computer system in which embodiments of the disclosure can operate. DETAILED DESCRIPTION

[0016] At least some aspects of the disclosure relate to an abstraction layer for secure memory devices.

[0017] Secure memory devices use encryption to control access to functions of the secure memory device. For example, privileged commands received in a secure memory device will be signed using a correct encryption key, after which the command can be executed within the secure memory device; and the encryption key represents a privilege to execute commands in the secure memory device. Different vendors / manufacturers can provide similar secure features with different access control implementations in the secure memory devices of the vendors / manufacturers. For example, commands to support encryption-based access control can have different syntax, format, and / or specification for secure memory devices from different manufacturers.

[0018] The abstraction layer provides a standardized model of the secure memory device with a predefined application programming interface (API) for applications to access the secure features in a standardized manner. For example, a set of utilities can provide a set of common commands for typical use of the secure features supplied by different vendors / manufacturers. The utilities can receive parameters from an application and implement their functions by invoking an operating system kernel and calling commands defined for the standardized model of the secure memory device. The operating system kernel can route the commands to corresponding device drivers of the secure memory devices from the respective vendors / manufacturers. The device drivers can implement the received commands based on the secure memory devices supplied by the respective vendors / manufacturers and operated by the respective device drivers using commands specific to the secure memory devices. Thus, an application programmed to access the secure memory devices using the utilities can work with different secure memory devices provided by different vendors or manufacturers of the secure memory devices.

[0019] Secure memory devices can be configured in a memory subsystem. The following description is presented to enable one of ordinary skill in the art to make and use the application, and is provided in the context of Figure 6 Examples of storage devices and memory modules as memory subsystems are described. Generally, a host system can utilize a memory subsystem that includes one or more components, such as a memory device that stores data. The host system can provide data to be stored at the memory subsystem, and can request data to be retrieved from the memory subsystem.

[0020] Figure 1 A system is shown with an abstraction layer 108 for secure memory devices (e.g., 121, 122) to allow applications to access the secure memory devices (e.g., 121, 122) in a manner independent of hardware implementations of the secure memory devices (e.g., 121, 122).

[0021] In Figure 1 The abstraction layer 108 is implemented using a utility 103 and an operating system kernel 101.

[0022] The operating system kernel 101 implements according to a standardized device model 102 of the secure memory devices (e.g., 121 and 122). Commands 105 processed by the standardized device model 102 provide responses 107. For example, the commands 105 include a signature that is checked for cryptographic-based access control before the standardized device model 102 provides a response 107 providing a result requested by the command 105; if the signature is invalid, the response 107 indicates an error.

[0023] The commands 105 and responses 107 of the standardized device model 102 can be implemented using a combination of a device driver (e.g., 111 or 112) and a corresponding secure memory device (e.g., 121 or 122) supported and / or operated by the device driver (e.g., 111 or 112).

[0024] For example, the memory device 121 can be manufactured according to a specification 123 so that commands 125 received in the memory device 121 provide responses 127. The manufacturer specification 123 identifies configurations of timing, format, syntax, and / or other aspects of commands to the memory device 121 and responses from the memory device 121. The device driver 111 implements the commands 105 issued to the standardized device model 102 using the commands 125 to the memory device 121, and generates the responses 107 to the commands 105 using the responses 127 from the memory device 121.

[0025] Similarly, another memory device 122 can be manufactured according to a different specification 124, such that a command 126 received in the memory device 122 provides a response 128. The device driver 112 implements the command 105 issued to the standardized device model 102 using the command 126 to the memory device 121 and generates the response 107 to the command 105 using the response 128 from the memory device 122.

[0026] To implement the same command 105, the device drivers 111 and 112 can generate different commands 125 and 126 according to different device specifications 123 and 124 for the respective secure memory devices 121 and 122. The corresponding responses 127 and 128 to the respective commands 125 and 126 are typically different (e.g., in syntax, format, and / or sequence). The device drivers 111 and 112 can generate the same response 107 for the command 105 based on the different responses 127 and 128. Thus, the memory device 121 operated by the device driver 111 and the memory device 122 operated by the device driver 112 can implement the same standardized device model 102 in generating the response 107 to the command 105.

[0027] In Figure 1 , the utility 103 provides a set of predefined application programming interfaces (APIs) for accessing the secure features according to the device usage model 104. The utility 103, which can be used by an application (e.g., 117 or 119), performs the secure functions on the standardized device model 102. The utility 103 can check parameters received from the application (e.g., 117 or 119), allocate resources for implementing the functions, format the parameters to generate data for the operating system kernel 101 to issue the command 105 to the relevant device driver (e.g., 111 or 112), and invoke the operating system kernel 101 with the generated data to cause the operating system kernel to issue the command 105. The sequence of commands 105 can be used to implement the functions of the utility 103 to provide a friendly response while masking the details of the standardized device model 102 from the applications 117,..., 119. Thus, the use of the secure features of the standardized device model 102 can be greatly simplified for the applications 117,..., 119.

[0028] In some implementations, the utility 103 and / or device drivers (e.g., 111, 112) are configured to access encryption keys to sign commands (e.g., 125, 126) to be transmitted to respective memory devices (e.g., 121, 122). Alternatively, the applications (e.g., 117, 119) are configured to communicate signatures to the utility 103 to allow generation of commands (105, 125, 126) that include signatures. For example, the utility 103 and / or device drivers (e.g., 111, 112) can generate a message to be signed and request the applications (e.g., 117, 119) to provide a signature for the message formatted by the utility 103 and / or device drivers (e.g., 111, 112).

[0029] For example, the utility 103 can be implemented as a command-line utility. An application (e.g., 117 or 119) can request the operating system to run the utility 103, passing data required by the utility 103 as command-line arguments. Some arguments can specify files containing data to be used by the utility 103. The utility 103 can invoke the operating system kernel 101 to issue commands 105 and provide responses in a standard output channel (or file) based on responses 107.

[0030] Figure 2 A command and response structure for accessing secure memory devices is described according to one embodiment.

[0031] For example, Figure 2 The command and response structure of the standardized device model 102 can be used for commands 105 and responses 107 of the device model 102, for commands 125 and responses 127 of a memory device 121 from one vendor according to a device specification 123, and / or for commands 126 and responses 128 of another memory device 122 from another vendor according to another device specification 124. The standardized device model 102 as well as the specifications 123 and 124 can use a similar overall structure of commands and responses as in Figure 2 but different definitions of syntax, fields, sequences of operations, sizes, and / or value interpretations, etc.

[0032] In the command and response structure of the standardized device model 102, Figure 2 a typical command 131 has a number of bytes to be transmitted or written into a memory device, such as a virtual memory device according to the standardized device model 102, or a memory device 121 with a specification 123 from one vendor, or another memory device 122 with a different specification 124 from a different vendor / manufacturer.

[0033] Command 131 can include an operation code 132 and a command type 133 to specify the operation to be performed on the command, as well as one or more fields 134, 135,... to specify parameters to be used with command 131. The total size of command 131 can depend on the combination of operation code 132 and command type 133.

[0034] For at least some types of commands, a field of command 131 will provide a signature created for command 131 for encryption-based access control. The signature can be a hash-based message authentication code (HMAC), which can be verified using an encryption key stored in the secure memory device.

[0035] Optionally, command 131 can include a field identifying a particular encryption key from a list of keys in the secure memory device to be used to verify the signature. Optionally, each of the keys can have a corresponding monotonic counter; and can be referenced in command 131 via a reference to the corresponding monotonic counter pre-associated with the key.

[0036] The signature provided in a field of command 131 will be verified from a message including the contents of the fields (e.g., 134, 135) and one or more of operation code 132 and / or command type 133 of command 131.

[0037] In Figure 2 command 131 has a number of bytes to be returned by the corresponding memory device in response to command 131. The total size of response 141 can depend on the combination of operation code 132 and command type 133 specified in the corresponding command 131. For some types of commands, a field (e.g., 142 or 143) in response 141 can include a signature created by the secure memory device (e.g., 121 or 122) in response to command 131 to attest to the identity of the memory device and / or the integrity of the contents provided in response 141.

[0038] For example, command 131 can include an operation code 132 and a command type 133 configured to request a secure memory device to write a root key into the secure memory device. The secure memory device can be a device according to standardized device model 102, or device 121 according to specification 123, or device 122 according to specification 124. This command 131 can include a field 134 to specify the root key to be stored into the secure memory device, and another field 135 to specify a signature (or a truncated portion of the signature) for command 131. The signature (or a portion thereof) will be verified by the secure memory device before command 131 is executed in the secure memory device to store the root key.

[0039] For example, command 131 can include an opcode 132 and a command type 133 configured to request that the secure memory device update an encryption key used by the secure memory device to verify a signature based on its root key and data provided in a field 134 of command 131. This command 131 can include a field 135 to specify a signature for command 131; and a signature is generated for a message including the data provided in field 134.

[0040] For example, command 131 can include an opcode 132 and a command type 133 configured to request that the secure memory device increment a monotonic counter maintained within the secure memory device. This command 131 can include a field 134 to specify a current value of the monotonic counter, and a field 135 to specify a signature for command 131; and a signature is generated for a message including the current value of the monotonic counter provided in field 134.

[0041] For example, command 131 can include an opcode 132 and a command type 133 configured to request that the secure memory device provide a value maintained in a monotonic counter within the secure memory device. This command 131 can include a field 134 to specify a tag, and a field 135 to specify a signature for command 131; and a signature is generated for a message including the tag.

[0042] For example, command 131 can include an opcode 132 and a command type 133 configured to request that the secure memory device provide extended state data resulting from execution of a previous command. This command 131 can include a field 135 to specify a signature for command 131.

[0043] For example, command 131 can include an opcode 132 and a command type 133 configured to request that the secure memory device provide a unique ID (UID) of the secure memory device. This command 131 can include a field 134 to specify a random number value (e.g., nonce), but no signature for command 131 is required. In response, the secure memory device will provide an HMAC signature for a message including the random number value and the UID for its UID.

[0044] For example, command 131 can include an opcode 132 and a command type 133 configured to provide / activate a security feature that provides a trusted measurement core root (CRTM). This command 131 can include a field 134 to specify a random number value, and a field 135 to specify a signature for command 131. Command 131 can further include a field to specify a current value of a predetermined monotonic counter in the secure memory device. A signature is generated using the server root key for a message that includes the random number value. In response, if the secure memory device has not been provisioned, the secure memory device can generate a root key using the random number value, and activate encryption-based access control and deactivate other lock / access controls.

[0045] For example, command 131 can include an opcode 132 and a command type 133 configured to de-provision / de-activate a security feature that provides a trusted measurement core root (CRTM). This command 131 can include a field 134 to specify a current value of a predetermined monotonic counter in the secure memory device, and a field 135 to specify a signature for command 131. A signature is generated using the server root key for the command content (not the signature itself). In response, if the secure memory device has not been de-provisioned, the secure memory device can deactivate encryption-based access control and allow activation of other lock / access controls.

[0046] For example, command 131 can include an opcode 132 and a command type 133 configured to allow modification to prevent locking a register in the secure memory device. This command 131 can include a field 134 to specify a current value of a predetermined monotonic counter in the secure memory device, and a field 135 to specify a signature for command 131. A signature is generated using the server session key for the command content (not including the signature itself).

[0047] For example, command 131 can include an opcode 132 and a command type 133 configured to request the secure memory device to compute a digest of a portion of content stored in the secure memory device and extend it to a register, or write it to another register. The portion can be identified using a value stored in a predefined register that specifies the location and size of the portion in the secure memory device. This command 131 can include a field 134 to specify a current value of a predetermined monotonic counter in the secure memory device, and a field 135 to specify a signature for command 131. A signature is generated using the server session key for the command content (excluding the signature itself).

[0048] For example, command 131 can include an operation code 132 and a command type 133 configured to indicate the start of a register update or to indicate the start of an update of a recovery block or recovery mode. This command 131 can include a field 134 to specify the current value of a predetermined monotonic counter in the secure memory device, and a field 135 to specify a signature for the command 131. The signature is generated for the command content (excluding the signature) using the server session key.

[0049] For example, command 131 can include an operation code 132 and a command type 133 configured to write data to a register. This command 131 can include a field 134 to specify the current value of a predetermined monotonic counter in the secure memory device, and a field 135 to specify a signature for the command 131. The command 131 can include other fields to specify the identity of the register to be written and the data to be written to the register; and the signature is generated for the command content (excluding the signature) using the server session key.

[0050] For example, command 131 can include an operation code 132 and a command type 133 configured to read data from a register. This command 131 can include a field 134 to specify the current value of a predetermined monotonic counter in the secure memory device, and a field 135 to specify the identity of the register to be read, but not a signature for the command 131.

[0051] For example, command 131 can include an operation code 132 and a command type 133 configured to indicate the end of a register update or to indicate the completion of a recovery block update or recovery mode. This command 131 can include a field 134 to specify the current value of a predetermined monotonic counter in the secure memory device, and a field 135 to specify a signature for the command 131. The signature is generated for the command content (excluding the signature) using the server session key.

[0052] For example, command 131 can include an operation code 132 and a command type 133 configured to request the secure memory device to change a root key, a session key, or a unique device secret (UDS). This command 131 can include a field 134 to specify the current value of a predetermined monotonic counter in the secure memory device, a random number value, and a field 135 to specify a signature for the command 131. The signature is generated for the command content (excluding the signature) using the server session key.

[0053] For example, command 131 can include an operation code 132 and a command type 133 configured to request the secure memory device to compute a digest or HMAC according to inputs provided in command 131. This command 131 can include a field 134 to specify a current value of a predetermined monotonic counter in the secure memory device, an identification of a portion of memory in the memory device based on which digest or HMAC is requested to be computed, and a field 135 to specify an optional signature for command 131. A signature is generated for the command content (excluding the signature) using the session key.

[0054] For example, command 131 can include an operation code 132 and a command type 133 configured to request the secure memory device to perform an operation related to programming / write, erase, and / or append based on automatic signature verification. This command 131 can include a field 134 to specify a current value of a predetermined monotonic counter in the secure memory device, and a field 135 to specify an optional signature for command 131. Command 131 can further include fields to specify the operation to be performed, options for the operation, an identification of a source region of memory in the memory device storing data for the operation, and an identification of a destination region of memory in the memory device for the operation; and a signature is generated for the command content (excluding the signature) using the session key.

[0055] Figure 3 An integrated circuit memory device with a security manager is described in accordance with one embodiment. For example, Figure 1 Memory device 121 or 122 in Figure 3 Memory device 230 can be implemented.

[0056] Integrated circuit memory device 230 can be enclosed in a single integrated circuit package. Integrated circuit memory device 230 includes a plurality of memory regions 231,..., 233, which can be formed in one or more integrated circuit dies.

[0057] A memory region (e.g., 231 or 233) can be allocated for use by a host system as a partition, logical unit, or namespace. Memory locations in a memory region (e.g., 231 or 233) can be specified by a host system via addresses of logical block addressing (LBA); and memory device 230 can include an address mapping that specifies a relationship between LBA addresses in a partition, logical unit, or namespace and physical addresses of corresponding memory cells used to provide a memory space allocated to the partition, logical unit, or namespace. In some implementations, memory device 230 is configured in a memory subsystem (e.g., 210) described in Figure 6 Memory device 230; and memory subsystem controller 215 can be configured to perform the address mapping for memory device 230.

[0058] A typical memory cell in a memory region (e.g., 231,..., 233) can be programmed to store one or more bits of data.

[0059] The memory device 230 has a local media controller 250 that can implement at least a portion of the security manager 213.

[0060] The security manager 213 of the memory device 230 can include the access controller 209, the encryption engine 207, the abstraction layer 108, and / or one or more device drivers (e.g., 111, 112).

[0061] The encryption engine 207 can be implemented via logic circuitry and / or instructions or microcode to perform cryptographic computations, such as applying a cryptographic hash function to a data item to produce a hash value, encrypting a data item using an encryption key to produce ciphertext, decrypting ciphertext using a corresponding encryption key to recover the data item, generating an encryption key for symmetric encryption and / or a pair of encryption keys for asymmetric encryption, etc.

[0062] The access controller 209 controls access to at least one of the memory regions 231,..., 233 and / or other functions of the memory device 230 based on encryption keys that represent access privileges.

[0063] For example, the security manager 213 can control access to the secure memory region 233 based on an encryption key generated based on the secret 201 of the integrated circuit memory device 230 and / or an encryption key that represents an owner or authorized user of the memory device 230. For example, when a request or command to write data into the secure memory region 233 is received in the integrated circuit memory device 230, the security manager 213 verifies whether the request is from a requestor with the encryption key. If not, the security manager 213 can deny the write request. To prove that the request is from an authorized requestor, the requestor can digitally sign the request or challenge message using the encryption key. When the security memory device 230 determines that the digital signature is made using the correct encryption key, the requestor is deemed to have the authority to write data into the secure memory region 233. For example, the memory device 230 can store one or more encryption keys 251 used to authenticate the digital signature of signed requests / commands.

[0064] Memory device 230 can be configured to use different encryption keys 251 for access control of different commands. For example, one encryption key 251 can represent a privilege to execute a secure command in memory device 230; and the secure command is to specify another encryption key 251 represents a privilege to read and / or write in a secure memory region 233. For example, memory device 230 can have multiple secure memory regions (e.g., 233); and access to each of the secure memory regions (e.g., 233) can be controlled via a separate encryption key 251.

[0065] For example, memory device 230 can have a unique device secret 201 representing an identity of memory device 230; and an encryption key 251 derived from unique device secret 201 can represent an owner privilege to operate memory device 230 and thus execute a secure command in the memory device.

[0066] In general, secure memory region 233 can have different security requirements for different types of access (e.g., read, write, erase). For example, secure memory region 233 can be configured to require a digital signature verifiable via encryption key 251 to write or change data in secure memory region 233, but not require a signed command to read data from secure memory region 233. Alternatively, secure memory region 233 can be configured to require a digital signature verifiable via encryption key 251 to read, write, and / or change data in secure memory region 233. Alternatively, secure memory region 233 can be configured to require a digital signature verifiable via a different encryption key to different operations in secure memory region 233, such as read, write, change, erase, etc.

[0067] Integrated circuit memory device 230 has a communication interface 247 to receive a command with an address 235. In response to address 235 identifying a secure memory region (e.g., 233) configured with access control, security manager 213 uses encryption engine 207 to perform an encryption operation to verify that the request is from a requester with an encryption key authorized to access memory region 233, while providing memory data retrieved from memory region 233 using address decoder 241. Address decoder 241 of integrated circuit memory device 230 converts address 235 to control signals to select a group of memory cells in integrated circuit memory device 230; and local media controller 250 of integrated circuit memory device 230 performs operations to determine memory data stored in the memory cells at address 235.

[0068] Figure 4 A technique to control execution of commands in a memory device is described in accordance with one embodiment. For example, Figure 4The techniques of this disclosure can be implemented in Figure 3 The memory device 230.

[0069] In Figure 4 The access controller 209 is configured with an access control key 249 to determine whether a signed command 263 received in the communication interface 247 is from an entity with privileges to execute commands 255 in the secure memory device 230.

[0070] When the controller 216 of the host system 220 sends a command 255 to the communication interface 247 of the memory device 230, the access controller 209 determines whether the sender of the command 255 has privileges to request the memory device 230 to execute the command 255. The host system 220 can include one or more processing devices 218 that execute instructions that implement an operating system and / or an application program.

[0071] The encryption key 245 is configured to represent privileges that are to be checked using the access control key 249. The sender of the command 255 can generate a verification code 253 from the encryption key 245 and the message 243 containing the command 255.

[0072] The encryption key 245 and the verification code 253 of the message 243 can be constructed and / or verified using various techniques, such as a hash digest, a digital signature, or a hash-based message authentication code, symmetric encryption, and / or asymmetric encryption. Thus, the verification code 253 is not limited to a particular implementation.

[0073] In general, verifying that the sender of a message (e.g., 243) has an encryption key (e.g., 245) involves verifying a verification code (e.g., 253) of the message (e.g., 243). The verification code can be in the form of a hash digest, a digital signature, a hash-based message authentication code (HMAC), a cipher-based message authentication code (CMAC), etc. The verification code is generated using the encryption key and the message as inputs to an encryption operation (e.g., a hash, an encryption, and / or other computation) such that it is generally impractical to generate the verification code without the encryption key and to generate the verification code from a modified version of the message. Thus, when a recipient confirms that a received verification code is valid for a received message and an encryption key, the recipient can conclude that the sender has the corresponding encryption key and that the received message is the same as the message used to generate the received key.

[0074] In some implementations, the receiver performs verification of the message's authentication code using the same encryption key as was used by the sender to generate the authentication code. For example, the receiver uses the same encryption key to generate an authentication code for the received message and compares the generated authentication code to the received authentication code. If there is a match, the received authentication code is valid for the received message; and the sender can be considered to have the encryption key. Otherwise, the received authentication code is not valid for the received message; the received message has been altered since the authentication code was generated, or the received authentication code was generated using a different encryption key, or both.

[0075] In some implementations, the receiver performs verification of the message's authentication code using a public encryption key of a key pair; and the sender generates the authentication code using a private encryption key of the key pair. For example, the authentication code can be generated by applying a hash function to the message to generate a hash value for the message. A ciphertext of the hash value obtained by encrypting the hash value using the encryption key can be used as the authentication code. The receiver of the message and authentication code performs verification using a corresponding decryption key, which is the same as the encryption key when symmetric encryption is used, and is a different key of the key pair when asymmetric encryption is used. After recovering the hash value from the ciphertext using the decryption key, the recovered hash value can be compared to a hash value of the received message; if there is a match, the received authentication code is valid for the received message; otherwise, the received authentication code is not valid for the received message. Alternatively, the receiver can perform verification using the encryption key without performing decryption. The receiver can use the encryption key to generate an authentication code for the message for comparison with the received authentication code.

[0076] In some implementations, the message and the encryption key are combined to generate a hash value as an authentication code, as in a hash-based message authentication code (HMAC) technique. For example, the encryption key can be used to generate two keys. After one of the two keys is combined with the message to generate a message modified by the key, a cryptographic hash function can be applied to the key-modified message to generate a hash value, which is further combined with the other key to generate a further message. After applying a cryptographic hash function (or another cryptographic hash function) to the further message, a hash-based message authentication code is generated. The receiver of the message can use the same encryption key to generate a hash-based message authentication code for the received message for comparison with the received hash-based message authentication code. If there is a match, the verification succeeds; otherwise, the verification will fail.

[0077] In general, any technique for generating and verifying a message from a sender and a cryptographic key used by the sender to generate a verification code for the message can be used to determine whether the sender has the cryptographic key. The receiver will perform the verification using the appropriate cryptographic key, which can be the same as the cryptographic key used to generate the verification code, or in the same pair of asymmetric cryptographic keys. Thus, the present disclosure is not limited to a particular technique of hash digest, digital signature, and / or hash-based message authentication code.

[0078] For convenience, generating a verification code (e.g., 253) for a message (e.g., 243) using a cryptographic key (e.g., 245) to represent both the message (e.g., 243) and the cryptographic key (e.g., 245) can be generally referred to as a digital signature of the message (e.g., 243) signed using the cryptographic key (e.g., 245), and it should be understood that various techniques can be used to generate the verification code, such as a hash-based message authentication code.

[0079] In Figure 4 The access controller 209 uses the corresponding access control key 249 to verify the verification code 253 submitted to the communication interface 247 for the command 255. The access controller 209 uses the cryptographic engine 207 to generate a verification result 259 of the received message 243 and the received verification code 253. Based on the verification result 259, the access controller 209 can selectively allow the command 255 to execute within the memory device 230 or prevent execution of the command 255.

[0080] For example, the access control key 249 can be one of the cryptographic keys 251 stored in the memory device 230. Different access control keys can be used to control different privileges for executing different commands and / or executing commands that operate on different sections or regions of memory cells.

[0081] For example, one cryptographic key 245 can represent a privilege to execute a secure command in the memory device 230. When the secure command is executed, the access control key 249 for verifying a verification code representing a privilege to execute a read command (or a write command) to access a secure memory region 233 is installed (or uninstalled) in the memory device 230.

[0082] Optionally, the cryptographic key 245 is generated in a process of verifying the identity of the memory device 230 based on a unique device secret 201 of the memory device 230; and a secret known between the memory device 230 and an owner of the memory device 230 allows generating a session key as the cryptographic key 245 to represent a privilege to execute a selected command in the memory device 230 during a communication session. The communication session can have a time limit and / or be terminated via a command to the memory device 230.

[0083] In some implementations, the same session key is used as the encryption key 245 that represents a privilege and as an access control key 249 for verifying a verification code (e.g., 253) generated using the encryption key 245.

[0084] In another implementation, a pair of encryption keys of an asymmetric encryption can be used for a session. The public key of the pair is used as the access control key 249; and the private key of the pair can be used as the encryption key 245 that represents a corresponding privilege.

[0085] After installing in the memory device 230 an access control key 249 for verifying a verification code (e.g., 253) generated using an encryption key 245 that represents a privilege read or written in the secure memory area 233, a signed command 263 can be generated by an authorized entity using the encryption key 245. The signed command 263 can be transmitted by the host system 220 to the communication interface 247 of the memory device 230. After the access controller 209 verifies the verification code 253 in the signed command 263, the access controller 209 allows the memory device 230 to execute the command 255.

[0086] The message 243 can include data 257 that represents a constraint on the request to execute the command 255.

[0087] For example, the data 257 can include an execution count value maintained within the memory device 230 so that a previously used verification code generated with a lower count cannot be replayed and made valid.

[0088] For example, the data 257 can include an encrypted random number value established for a particular instance of the request to execute the command 255 so that the verification code 253 cannot be reused for another instance.

[0089] For example, the data 257 can include a time window in which the verification code 253 is valid.

[0090] For example, the data 257 can include an identification of a memory area in which the command 255 is allowed to be executed.

[0091] For example, the data 257 can include an operation type that allows the command 255 to be executed in the memory device 230.

[0092] Figure 5 A method of accessing a secure memory device is shown in accordance with one embodiment. Figure 5 The method of can be performed by processing logic that can include hardware (e.g., processing device, circuitry, dedicated logic, programmable logic, microcode, hardware of a device, integrated circuit, etc.), software (e.g., instructions run or executed on a processing device), or a combination thereof. In some embodiments, the method of Figure 5 The method of is performed, at least in part, byFigure 4 The processing unit 218 or controller 216 of the host system 220 Figure 6 The controller 215 and / or controller 250 of the memory subsystem 210, or Figure 3 The processing logic within the memory device 230 is used for execution. Although shown in a specific sequence or order, the order of processes may be modified unless otherwise specified. Therefore, the illustrated embodiments should be understood as examples only, and the illustrated processes may be executed in different orders, and some processes may be executed in parallel. In addition, one or more processes may be omitted in various embodiments. Therefore, not all processes are required in every embodiment. Other process flows are possible.

[0093] At block 301, an abstraction layer 108 implemented for a memory device configured with encryption-based access control receives a request to perform a function, the request containing one or more parameters and identifying the memory device (e.g., 121 or 122).

[0094] For example, the abstraction layer 108 may be partially implemented in the operating system kernel 101 and / or at least one utility 103.

[0095] For example, utility 103 can be configured to be executed as a command-line command.

[0096] At box 303, abstraction layer 108 uses one or more parameters to generate at least one first command (e.g., 105) in a format independent of the memory device (e.g., 121) specification (e.g., 123).

[0097] At box 305, abstraction layer 108 identifies the device driver (e.g., 111) of the memory device (e.g., 121).

[0098] At box 307, abstraction layer 108 (e.g., by retrieving, calling, or executing device driver 121) provides (e.g., transmits or sends) at least one first command (e.g., 105) to device driver (e.g., 121).

[0099] At block 309, the device driver (e.g., 121) generates at least one second command (e.g., 125) to the memory device (e.g., 121) according to the specification (e.g., 123) of the memory device (e.g., 121) to perform a function. The second command (e.g., 125) contains a signature generated using a portion of the second command (e.g., 125).

[0100] For example, the signature could be a verification code 253, such as a hash-based message authentication code (HMAC) generated using encryption key 245 for a part of message 243 with a second command (e.g., 125).

[0101] For example, the one or more parameters provided to the utility can include a signature generated using the encryption key 245.

[0102] In some implementations, the abstraction layer 108 does not have access to the encryption key 245; and a separate application or program with the encryption key 245 will provide the verification code 253 for the message 243 to be signed.

[0103] For example, based on the requested function, the abstraction layer 108 is configured to provide an operation code and a command type for generating a second command (e.g., 125) from at least one first command (e.g., 105) according to a specification.

[0104] For example, the operation code and the command type in the second command are configured to: write an encryption key to a memory device; update an encryption key in a memory device; increment a monotonic counter in a memory device; or retrieve data from a memory device; or any combination thereof.

[0105] For example, the operation code and the command type in the second command are configured to: activate a security feature of a memory device; deactivate a security feature of a memory device; start a session to update a register in a memory device; end a session to update a register in a memory device; compute a digest of a portion of content stored in a memory device; change a portion of data stored in a memory device; or replace an encryption key in a memory device; or any combination thereof.

[0106] Figure 6 An example computing system 200 including a memory sub-system 210 is described in accordance with some embodiments of the present disclosure. The memory sub-system 210 can include media, such as one or more volatile memory devices (e.g., memory devices 240), one or more non-volatile memory devices (e.g., memory devices 230), or a combination thereof.

[0107] The memory sub-system 210 can be a memory device, a memory module, or a hybrid of a storage device and a memory module. Examples of storage devices include a solid-state drive (SSD), a flash drive, a Universal Serial Bus (USB) flash drive, an embedded Multi-Media Controller (eMMC) drive, a Universal Flash Storage (UFS) drive, a Secure Digital (SD) card, and a hard disk drive (HDD). Examples of memory modules include a dual in-line memory module (DIMM), a small outline DIMM (SO-DIMM), and various types of non-volatile dual in-line memory modules (NVDIMM).

[0108] The computing system 200 can be a computing device, such as a desktop computer, a laptop computer, a network server, a mobile device, a vehicle (e.g., an airplane, a drone, a train, a car, or other vehicle), an Internet of Things (IoT) enabled device, an embedded computer (e.g., a device included in a vehicle, industrial equipment, or a networked commercial device), or such computing device that includes a memory and a processing device.

[0109] The computing system 200 can include a host system 220 coupled to one or more memory sub-systems 210. Figure 6 One example of a host system 220 coupled to one memory sub-system 210 is described. As used herein, “coupled to” or “coupled with” generally refers to a connection between components that can be an indirect communicative connection or direct communicative connection (e.g., without intermediary components), whether wired or wireless, including connections such as electrical, optical, magnetic, etc.

[0110] The host system 220 can include a processor chipset (e.g., processing device 218) and a software stack executed by the processor chipset. The processor chipset can include one or more cores, one or more caches, a memory controller (e.g., controller 216) (e.g., NVDIMM controller), and a storage protocol controller (e.g., PCIe controller, SATA controller). The host system 220 writes data to and reads data from the memory sub-system 210, for example, using the memory sub-system 210.

[0111] The host system 220 can be coupled to the memory sub-system 210 via a physical host interface. Examples of a physical host interface include, but are not limited to, a Serial Advanced Technology Attachment (SATA) interface, a Peripheral Component Interconnect Express (PCIe) interface, a Universal Serial Bus (USB) interface, Fibre Channel, a Serial Attached SCSI (SAS) interface, a Double Data Rate (DDR) memory bus interface, a Small Computer System Interface (SCSI), a Dual In-line Memory Module (DIMM) interface (e.g., a DIMM slot interface supporting Double Data Rate (DDR)), an Open NAND Flash Interface (ONFI), a Double Data Rate (DDR) interface, a Low Power Double Data Rate (LPDDR) interface, or any other interface. The physical host interface can be used to transfer data between the host system 220 and the memory sub-system 210. The host system 220 can further utilize a NVM Express (NVMe) interface to access components (e.g., memory devices 230) when the memory sub-system 210 is coupled with the host system 220 over a PCIe interface. The physical host interface can provide an interface for passing control, address, data, and other signals between the memory sub-system 210 and the host system 220. Figure 6The memory sub-system 210 is illustrated as an example. In general, the host system 220 can access multiple memory sub-systems via the same communication connection, multiple separate communication connections, and / or a combination of communication connections.

[0112] The processing device 218 of the host system 220 can be, for example, a microprocessor, a central processing unit (CPU), a processing core of a processor, an execution unit, or the like. In some examples, the controller 216 can be referred to as a memory controller, a memory management unit, and / or an initiator. In one example, the controller 216 controls communications over a bus coupled between the host system 220 and the memory sub-system 210. In general, the controller 216 can send commands or requests to the memory sub-system 210 for desired accesses to the memory devices 230, 240. The controller 216 can further include interface circuitry to communicate with the memory sub-system 210. The interface circuitry can convert responses received from the memory sub-system 210 into information for the host system 220.

[0113] The controller 216 of the host system 220 can communicate with the controller 215 of the memory sub-system 210 to perform operations such as reading data, writing data, or erasing data at the memory devices 230, 240, among other such operations. In some examples, the controller 216 is integrated in the same package as the processing device 218. In other examples, the controller 216 is separate from the package of the processing device 218. The controller 216 and / or the processing device 218 can include hardware such as one or more integrated circuits (ICs) and / or discrete components, a buffer memory, a cache memory, or a combination thereof. The controller 216 and / or the processing device 218 can be a microcontroller, special purpose logic circuitry (e.g., a field programmable gate array (FPGA), an application specific integrated circuit (ASIC), etc.), or another suitable processor.

[0114] The memory devices 230, 240 can include any combination of different types of non-volatile memory components and / or volatile memory components. Volatile memory devices (e.g., the memory device 240) can be, but are not limited to, random access memories (RAMs) such as dynamic random access memories (DRAMs) and synchronous dynamic random access memories (SDRAMs).

[0115] Some examples of non-volatile memory components include negative- AND (NAND) type flash memory and in-place write memory, such as three-dimensional cross-point (“3D cross-point”) memory. Cross-point arrays of non-volatile memory can perform bit storage based on changes in bulk resistance in conjunction with a stackable cross-grid data access array. Additionally, in contrast to many flash-based memories, cross-point non-volatile memory can perform in-place write operations, where a non-volatile memory cell can be programmed without first erasing the non-volatile memory cell. NAND type flash memory includes, for example, two-dimensional NAND (2D NAND) and three-dimensional NAND (3D NAND).

[0116] Each of the memory devices 230 can include one or more arrays of memory cells. One type of memory cell, such as a single-level cell (SLC), can store one bit per cell. Other types of memory cells, such as a multi-level cell (MLC), a triple-level cell (TLC), a quad-level cell (QLC), and a penta-level cell (PLC), can store multiple bits per cell. In some embodiments, each of the memory devices 230 can include one or more arrays of memory cells, such as SLC, MLC, TLC, QLC, or PLC, or any combination of this. In some embodiments, a particular memory device can include an SLC portion, an MLC portion, a TLC portion, a QLC portion, and / or a PLC portion of memory cells. The memory cells of the memory devices 230 can be grouped into pages, which can refer to a logical unit of the memory device used to store data. For some types of memory, such as NAND, pages can be grouped to form blocks.

[0117] Although non-volatile memory devices such as 3D cross-point type and NAND type memory (e.g., 2D NAND, 3D NAND) are described, the memory devices 230 can be based on any other type of non-volatile memory, such as read-only memory (ROM), phase change memory (PCM), self-selecting memory, other chalcogenide-based memory, ferroelectric transistor random access memory (FeTRAM), ferroelectric random access memory (FeRAM), magnetic random access memory (MRAM), spin-transfer torque (STT)-MRAM, conductive-bridge RAM (CBRAM), resistive random access memory (RRAM), oxide-based RRAM (OxRAM), or negative (NOR) flash memory, as well as electrically erasable programmable read-only memory (EEPROM).

[0118] The memory sub-system controller 215 (or controller 215 for simplicity) can communicate with the memory devices 230 to perform operations such as reading data, writing data, or erasing data at the memory devices 230, among other such operations (e.g., in response to commands scheduled by the controller 216 on a command bus). The controller 215 can include hardware such as one or more integrated circuits (ICs) and / or discrete components, a buffer memory, or a combination thereof. The hardware can include digital circuitry with dedicated (e.g., hard-coded) logic to perform the operations described herein. The controller 215 can be a microcontroller, special purpose logic circuitry (e.g., a field programmable gate array (FPGA), an application specific integrated circuit (ASIC), etc.), or another suitable processor.

[0119] The controller 215 can include a processing device 217 (e.g., a processor) configured to execute instructions stored in local memory 219. In the illustrated example, the local memory 219 of the controller 215 includes embedded memory configured to store various processes, operations, logic flows, and routines that are used to perform operations including handling communications between the memory sub-system 210 and the host system 220.

[0120] In some embodiments, the local memory 219 can include memory registers that store memory pointers, fetch data, etc. The local memory 219 can also include read-only memory (ROM) for storing microcode. Although the local memory 219 is illustrated as being included in the controller 215, in other embodiments, the local memory 219 can be external to the controller 215. Figure 6 In another implementation of the disclosure, the memory sub-system 210 can not include a controller 215, but can rely upon external control (e.g., provided by an external host or by a processor or controller separate from the memory sub-system).

[0121] In general, the controller 215 can receive commands or operations from the host system 220 and can convert the commands or operations into instructions or appropriate commands to achieve the desired access to the memory devices 230. The controller 215 can be responsible for other operations such as wear leveling operations, garbage collection operations, error detection and error-correcting code (ECC) operations, encryption operations, caching operations, and address translations between a logical address (e.g., a logical block address (LBA), a namespace) and a physical address (e.g., a physical block address) associated with the memory devices 230. The controller 215 can further include host interface circuitry to communicate with the host system 220 via the physical host interface. The host interface circuitry can convert commands received from the host system into command instructions to access the memory devices 230 as well as convert responses associated with the memory devices 230 into information for the host system 220.

[0122] The memory sub-system 210 can also include additional circuitry or components not shown. In some embodiments, the memory sub-system 210 can include a cache or buffer (e.g., DRAM) and address circuitry (e.g., row and column decoders) that can receive addresses from the controller 215 and decode the addresses to access the memory device 230.

[0123] In some embodiments, the memory device 230 includes a local media controller 250 that operates in conjunction with the memory sub-system controller 215 to perform operations on one or more memory cells of the memory device 230. An external controller (e.g., the memory sub-system controller 215) can externally manage the memory device 230 (e.g., perform media management operations on the memory device 230). In some embodiments, the memory device 230 is a managed memory device that is a raw memory device combined with a local controller (e.g., the local media controller 250) for media management within the same memory device package. An example of a managed memory device is a managed NAND (MNAND) device.

[0124] The controller 215 and / or the memory device 230 can include the security manager 213 discussed above. In some embodiments, the controller 215 in the memory sub-system 210 and / or the local media controller 250 can include at least a portion of the security manager 213. In other embodiments, or in combination, the controller 216 in the host system 220 and / or the processing device 218 can include at least a portion of the security manager 213. For example, the controller 215, the controller 216, and / or the processing device 218 can include logic circuitry that implements the security manager 213. For example, the controller 215 or the processing device 218 (e.g., a processor) of the host system 220 can be configured to execute instructions stored in a memory for performing the operations of the security manager 213 described herein. In some embodiments, the security manager 213 is implemented in an integrated circuit chip that is disposed in the memory sub-system 210. In other embodiments, the security manager 213 can be part of firmware of the memory sub-system 210, an operating system, a device driver, or an application program of the host system 220, or any combination thereof.

[0125] Figure 7 An example machine of a computer system 400 is illustrated, within which a set of instructions, for causing the machine to perform any one or more of the methodologies discussed herein, can be executed. In some embodiments, the computer system 400 can correspond to a host system (e.g., the host system 220 of FIG. 2) that includes, is coupled to, or utilizes a memory sub-system (e.g., the memory sub-system 210 of FIG. 2). Figure 6 Figure 6 ​memory subsystem 210) or that can be used to perform the operations of the security manager 213 (e.g., executing instructions to perform operations corresponding to references Figures 1 to 5 The described machine can be connected (e.g., networked) to other machines in a LAN, an intranet, an extranet, and / or the Internet. The machine can operate in the capacity of a server or a client machine in client-server network environment, as a peer machine in a peer-to-peer (or distributed) network environment, or as a server or a client machine in a cloud computing infrastructure or environment.

[0126] The machine can be a personal computer (PC), a tablet PC, a set-top box (STB), a Personal Digital Assistant (PDA), a cellular telephone, a web appliance, a server, a network router, a switch or bridge, or any machine capable of executing a set of instructions (sequential or otherwise) that specify actions to be taken by that machine. Further, while a single machine is illustrated, the term "machine" shall also be taken to include any collection of machines that individually or jointly execute a set (or multiple sets) of instructions to perform any one or more of the methodologies discussed herein.

[0127] The example computer system 400 includes a processing device 402, a main memory 404 (e.g., read-only memory (ROM), flash memory, dynamic random access memory (DRAM) (such as synchronous DRAM (SDRAM) or Rambus DRAM (RDRAM), static random access memory (SRAM), etc.), and a data storage system 418, which communicate with each other via a bus 430 (which can include multiple buses).

[0128] The processing device 402 represents one or more general-purpose processing devices such as a microprocessor, a central processing unit, or the like. More particularly, the processing device can be a complex instruction set computing (CISC) microprocessor, reduced instruction set computing (RISC) microprocessor, very long instruction word (VLIW) microprocessor, or a processor implementing other instruction sets, or processors implementing a combination of instruction sets. The processing device 402 can also be one or more special-purpose processing devices such as an application specific integrated circuit (ASIC), a field programmable gate array (FPGA), a digital signal processor (DSP), network processor, or the like. The processing device 402 is configured to execute instructions 426 for performing the operations and steps discussed herein. The computer system 400 can further include a network interface device 408 to communicate over the network 420.

[0129] Data storage system 418 can include a machine-readable medium 424 (also referred to as a computer-readable medium) on which is stored one or more sets of instructions 426 or software embodying any one or more of the methodologies or functions described herein. The instructions 426 can also reside, completely or at least partially, within the main memory 404 and / or within the processing device 402 during execution thereof by the computer system 400, the main memory 404 and the processing device 402 also constituting machine-readable storage media. The machine-readable medium 424, data storage system 418, and / or main memory 404 can correspond to memory subsystem 210 of FIG. 2. Figure 6

[0130] In one embodiment, the instructions 426 include instructions to implement functionality corresponding to the security manager 213 (e.g., the security manager 213 described with reference to FIG. 2). While the machine-readable medium 424 is shown in an example embodiment to be a single medium, the term "machine-readable storage medium" should be taken to include a single medium or multiple media that store one or more sets of instructions. The term "machine-readable storage medium" shall also be taken to include any medium that is capable of storing or encoding a set of instructions for execution by the machine and that cause the machine to perform any one or more of the methodologies of the present disclosure. The term "machine-readable storage medium" shall accordingly be taken to include, but not be limited to, solid-state memories, optical media, and magnetic media. Figures 1 to 5

[0131] Some portions of the preceding detailed descriptions have been presented in terms of algorithms and symbolic representations of operations on data bits within a computer memory. These

[0132] It should be borne in mind, however, that all of these and similar terms are to be associated with the appropriate physical quantities and are merely convenient labels applied to these quantities. The present disclosure can refer to the action and processes of a computer system, or similar electronic computing device, that manipulates and transforms data represented as physical (electronic) quantities within the computer system's registers and memories into other data similarly represented as physical quantities within the computer system memories or registers or other such information storage systems.

[0133] ​​The present disclosure also relates to an apparatus for performing the operations herein. This apparatus can be specially constructed for the intended purposes, or it can include a general purpose computer selectively activated or reconfigured by a computer program stored in the computer. Such a computer program can be stored in a computer readable storage medium, such as, but not limited to, any type of disk including floppy disks, optical disks, CD-ROMs, and magnetic-optical disks, read-only memories (ROMs), random access memories (RAMs), EPROMs, EEPROMs, magnetic or optical cards, or any type of media suitable for storing electronic instructions, each coupled to a computer system bus.

[0134] The algorithms and displays presented herein are not inherently related to any particular computer or other apparatus. Various general purpose systems can be used with programs in accordance with the teachings herein, or it can prove convenient to construct a more specialized apparatus to perform the method. The structure for a variety of these systems will appear as follows from the description. In addition, the present disclosure is not described with reference to any particular programming language. It will be appreciated that a variety of programming languages can be used to implement the teachings of the disclosure as described herein.

[0135] The present disclosure can be provided as a computer program product, or software, that can include a machine-readable medium having stored thereon instructions, which can be used to program a computer (or other electronic devices) to perform a process according to the present disclosure. A machine-readable medium includes any mechanism for storing information in a form accessible by a machine (e.g., a computer). In some embodiments, a machine-readable (e.g., computer-readable) medium includes a machine (e.g., a computer) readable storage medium, such as read-only memory ("ROM"), random access memory ("RAM"), magnetic disk storage media, optical storage media, flash memory components, etc.

[0136] In this description, various functions and operations are described as being performed by or caused by computer instructions, e.g., software. However, it will be readily apparent to those skilled in the art that any feature, function, or operation described herein can be implemented by hardware that carries out the approach described herein, by software stored on a machine-readable medium (e.g., RAM or ROM) which is executed by a computer, or by a combination of hardware and software. Moreover, a software implementation could be implemented as a computer program product such as a plug-in which can be uploaded to a machine using a

[0137] In the foregoing specification, embodiments of the disclosure have been described with reference to specific examples thereof. It is evident, however, that various modifications can be made thereto without departing from the broader spirit and scope of the disclosure as set forth in the appended claims. The specification and drawings are, accordingly, to be regarded in an illustrative sense rather than a restrictive sense.

Claims

1. A method comprising: In an abstraction layer implemented for a memory device configured with encryption-based access control, a request to perform a function is received, the request containing one or more parameters and identifying the memory device. The abstraction layer uses one or more parameters to generate at least one first command in a format independent of the command timing, format, or syntax configuration of the memory device; The device driver for the memory device is identified by the abstraction layer; and The at least one first command is transmitted to the device driver such that the device driver generates at least one second command to the memory device according to the command timing, format, or syntax configuration of the memory device, the second command containing a signature generated using a portion of the second command, wherein the functionality is implemented by executing the at least one second command in the memory device.

2. The method according to claim 1, wherein the abstraction layer comprises an operating system kernel and at least one utility.

3. The method of claim 2, wherein the utility can be executed as a command-line command.

4. The method of claim 2, wherein the signature is a hash-based message authentication code generated using an encryption key for the portion of the message having the second command.

5. The method of claim 4, wherein one or more parameters include the signature.

6. The method of claim 5, wherein the abstraction layer cannot access the encryption key.

7. The method of claim 5, wherein the abstraction layer is configured to provide opcodes and command types for generating the second command based on the command timing, format, or syntax configuration from the at least one first command.

8. The method of claim 7, wherein the opcode and the command type are configured for the second command as follows: Write the encryption key into the memory device; Update the encryption key in the memory device; Increment the monotonic counter in the memory device; or Retrieve data from the memory device; or Any combination thereof.

9. The method of claim 7, wherein the opcode and the command type are configured for the second command as follows: Activate the security features of the memory device; Deactivate the security features of the memory device; Initiate a session to update the registers in the memory device; End the session that updates the registers in the memory device; Calculate a summary of a portion of the contents stored in the memory device; Change a portion of the data stored in the memory device; or Replace the encryption key in the memory device; or Any combination thereof.

10. A non-volatile storage medium storing instructions, said instructions causing the computing device to perform a method when executed on a computing device, the method comprising: In an abstraction layer implemented for a memory device configured with encryption-based access control, a request to perform a function is received, the request containing one or more parameters and identifying the memory device. The abstraction layer uses one or more parameters to generate at least one first command in a format independent of the command and response timing, format, or syntax configuration of the memory device. The device driver for the memory device is identified by the abstraction layer; and The at least one first command is sent to the device driver such that the device driver generates at least one second command to the memory device according to the command and response timing, format, or syntax configuration of the memory device, the second command containing a signature generated using a portion of the second command, wherein the functionality is implemented by executing the at least one second command in the memory device.

11. The non-volatile storage medium of claim 10, wherein the abstraction layer comprises an operating system kernel and at least one utility program.

12. The non-volatile storage medium of claim 11, wherein the utility can be executed as a command-line command.

13. The non-volatile storage medium of claim 11, wherein the signature is a hash-based message authentication code generated using an encryption key for the portion of the message having the second command.

14. The non-volatile storage medium of claim 13, wherein one or more parameters include the signature.

15. The non-volatile storage medium of claim 14, wherein the abstraction layer cannot access the encryption key.

16. The non-volatile storage medium of claim 14, wherein the abstraction layer is configured to provide opcodes and command types for generating the second command based on the command and response timing, format, or syntax configuration from the at least one first command.

17. The non-volatile storage medium of claim 16, wherein the opcode and the command type are configured for the second command as follows: Write the encryption key into the memory device; Update the encryption key in the memory device; Increment the monotonic counter in the memory device; or Retrieve data from the memory device; or Any combination thereof.

18. The non-volatile storage medium of claim 16, wherein the opcode and the command type are configured for the second command as follows: Activate the security features of the memory device; Deactivate the security features of the memory device; Initiate a session to update the registers in the memory device; End the session that updates the registers in the memory device; Calculate a summary of a portion of the contents stored in the memory device; Change a portion of the data stored in the memory device; or Replace the encryption key in the memory device; or Any combination thereof.

19. An apparatus comprising: Memory devices; and At least one microphone, configured via instructions to: In an abstraction layer implemented for a memory device configured with encryption-based access control, a request to perform a function is received, the request containing one or more parameters and identifying the memory device. The abstraction layer uses one or more parameters to generate at least one first command in a format independent of the manufacturer's specifications regarding command and response timing, format, or syntax configuration for the memory device; The device driver for the memory device is identified by the abstraction layer; and The at least one first command is sent to the device driver such that the device driver generates at least one second command to the memory device according to the manufacturer's specification for the memory device, the second command containing a signature generated using a portion of the second command, wherein the functionality is implemented by executing the at least one second command in the memory device.

20. The device of claim 19, wherein the abstraction layer comprises an operating system kernel and at least one utility.

Images