Mechanism to support writing files to a file system mounted in a secure memory device

Abstract

A system, method, and apparatus to record a file in a file system installed in a secure section of a memory device. The memory device authenticates a requestor to write data to a secure section based on whether the requestor possesses a cryptographic key. A non-privileged module of an operating system is able to write to a non-secure section of the memory device. A request to write or change a file can be recorded by the non-privileged module into the non-secure section for later submission into the file system. In response to the request to submit the file, a security manager having the cryptographic key is invoked to identify data eligible to be written to the secure section based on the record in the non-secure section. The security manager is able to generate a command signed using the cryptographic key to write contents of the file to the secure memory section.

Description

[0001] Related applications

[0002] This application claims priority to U.S. Patent Application No. 17 / 170,762, filed February 8, 2021, entitled “Mechanism to Support Writing Files into a File System Mounted in a Secure Memory Device,” the entire contents of which are incorporated herein by reference. Technical Field

[0003] At least some of the embodiments disclosed herein generally relate to access control, and more specifically, but not limitedly, to writing files to a file system mounted on a secure storage device. Background Technology

[0004] The memory subsystem may include one or more memory devices for storing data. The memory devices may be, for example, non-volatile memory devices and volatile memory devices. Generally, a host system can utilize the memory subsystem to store data at the memory devices and retrieve data from the memory devices. Attached Figure Description

[0005] The embodiments are illustrated by way of example and without limitation in the accompanying drawings, wherein like references indicate similar elements.

[0006] Figure 1 This describes an example computing system having a memory subsystem according to some embodiments of the present disclosure.

[0007] Figure 2 This describes an integrated circuit memory device with a security manager according to one embodiment.

[0008] Figure 3 This describes a mechanism, according to one embodiment, for supporting writing files to a file system mounted on a secure storage device.

[0009] Figure 4 This describes the use of a security manager, according to one embodiment, for writing files to a file system mounted on a secure storage device.

[0010] Figure 5 A method for writing a file to a secure storage device according to one embodiment is shown.

[0011] Figure 6 This is a block diagram of an example computer system in which embodiments of the present disclosure can be operated. Detailed Implementation

[0012] At least some aspects of this disclosure relate to a security manager configured to transfer data of files in a file system mounted in a secure segment of a storage subsystem from an insecure segment to a secure segment. The following is in conjunction with... Figure 1 Describe examples of storage devices and memory modules. Generally, a host system may utilize a memory subsystem that includes one or more components, such as a memory device for storing data. The host system can provide data to be stored in the memory subsystem and can request data to be retrieved from the memory subsystem.

[0013] Secure memory devices can store device secrets for authentication and access control. For example, a physically unclonable function (PUF) can be used to generate a unique secret for the secure memory device. A cryptographic key can be generated based on this secret and used as an identifier for the memory device.

[0014] For example, authentication of a secure memory device can be performed by verifying that the memory device possesses a cryptographic key and therefore a unique secret. The memory device can digitally sign messages using the cryptographic key. If the digital signature can be verified as having been established using the cryptographic key, then the memory device is considered to possess the cryptographic key and therefore has an identifier associated with a Physically Uncopyable Function (PUF) and / or a unique device secret.

[0015] Furthermore, the secure storage device can store cryptographic keys to authenticate that a received command originates from its authorized user or owner. For example, a command to access a secure section of the storage device can be required to have a digital signature from an authorized user or owner; and the corresponding cryptographic key stored in the secure storage device can be used to verify that the digital signature was established using the cryptographic key of the authorized user or owner of the secure storage device. If the command to access a secure section of the storage device is not signed by one of the device's authorized users or owners, the command can be rejected.

[0016] A digital signature can be generated and appended to a message by applying a cryptographic hash function to obtain a hash value, encrypting the hash value using a cryptographic key, and then attaching it to the message. The encrypted hash value can be decrypted and compared with a hash value calculated independently of the message. If a match exists between the hash value calculated from the message and the hash value reconstructed from the decrypted digital signature, then the integrity of the message can be verified based on the hash value; and the digital signature can be considered to have been established using a cryptographic key.

[0017] When using symmetric-key cryptography, the encryption of the hash value and the decryption of the ciphertext of the hash value are performed using the same cryptographic key.

[0018] When using asymmetric key cryptography, the encryption of the hash value and the decryption of the hash value's ciphertext are performed using different keys in a key pair. The private key in the key pair is used to sign the digital signature; and the public key in the key pair is used to verify the digital signature.

[0019] When a file system is mounted in a secure segment of a secure storage device, allowing applications that can access the file system to write data to that secure segment can be challenging. For example, when an application calls the operating system to write a file, the storage location within the secure segment of the storage device for the file may not yet be determined.

[0020] At least some aspects of this disclosure address the aforementioned and other deficiencies by allowing the file system to initially write data to an insecure segment of the storage device. When the operating system is ready to commit file data to the file system, the security manager can identify the file data from records in the insecure segment and generate a signed command to write the file to a secure segment of the storage device. The security manager is configured with a cryptographic compiling key to generate a valid digital signature for the signed command. After verification of the digital signature, the signed command can be executed via the storage device to write the file to a secure segment of the storage device.

[0021] Because file data in a file system is initially written to insecure segments, various modules of the operating system do not need to be reconfigured to handle signed commands specific to secure segments mounted on the storage device. When a file is committed to the file system mounted in a secure segment on the storage device, the security manager, acting as a centralized representative of the operating system, issues the signed command. Therefore, file system security can be improved by assigning access rights to various modules of the operating system.

[0022] For example, a secure integrated circuit memory device has a secure section. Data writing to the secure section can be controlled via cryptographically signed commands. One or more privileged applications can be configured with cryptographically compiled keys that can be used to sign commands. The signed command is executed by the secure memory device against the secure section, and thus executes to write data to the secure section. However, when a privileged application issues a command to write data to a file, the privileged application typically does not know where the file system will decide where to write the file's data to the secure section.

[0023] At least one embodiment of this disclosure includes a logging mechanism that can be partially initiated and configured by a privileged application as a security manager. While a file logging session is in operation, any module in the operating system may be allowed to write file data to a secure storage device using unsigned commands. However, the secure storage device is configured to temporarily write file data to a non-secure segment. The non-secure segment in the secure storage device can be used as a non-volatile buffer for the file logging session. After the file logging session ends, the privileged application can read the contents of the buffer and determine what changes to commit to the secure segment of the storage device. For data to be committed to the secure segment of the storage device, the privileged application can use its cryptographic key to sign commands to write to the secure segment of the storage device. Optionally, resources of the security manager used to log data to the secure segment may be stored in the secure segment, including analysis tools for determining the validity of the log.

[0024] For example, a secure integrated circuit memory device is configured to allow any module in the operating system to write to an insecure flash memory array during a file recording session of a file system mounted in a secure segment of the memory device. A software module running on the host computer (e.g., as a security application or a module of the operating system) then uses an algorithm to analyze the records in the insecure flash memory array to determine whether any portion of the recorded write sequence should be moved / committed from the insecure flash memory array to a secure segment of the file system mounted therein. Upon successfully identifying data to be committed to the file system, the security application generates a signed command and sends it to the storage device to move / commit the data to the secure segment.

[0025] Figure 1 This description describes an example computing system 100 including a memory subsystem 110 according to some embodiments of the present disclosure. The memory subsystem 110 may include media, such as one or more volatile memory devices (e.g., memory device 140), one or more non-volatile memory devices (e.g., memory device 130), or a combination of the like.

[0026] The memory subsystem 110 may be a storage device, a memory module, or a combination of both. Examples of storage devices include solid-state drives (SSDs), flash drives, universal serial bus (USB) flash drives, embedded multimedia controller (eMMC) drives, universal flash storage (UFS) drives, secure digital storage (SD) cards, and hard disk drives (HDDs). Examples of memory modules include dual in-line memory modules (DIMMs), small form factor DIMMs (SO-DIMMs), and various types of non-volatile dual in-line memory modules (NVDIMMs).

[0027] The computing system 100 may be a computing device, such as a desktop computer, laptop computer, web server, mobile device, vehicle (e.g., airplane, drone, train, car or other vehicle), device with Internet of Things (IoT) functionality, embedded computer (e.g., embedded computer contained in a vehicle, industrial equipment or network business device), or the computing device containing memory and processing device.

[0028] The computing system 100 may include a host system 120 coupled to one or more memory subsystems 110. Figure 1 This describes an example of a host system 120 coupled to a memory subsystem 110. As used herein, “coupled to” or “coupled with” generally refers to a connection between components, which can be an indirect or direct communication connection (e.g., without an intermediary component) (wired or wireless), including connections such as electrical, optical, magnetic, etc.

[0029] Host system 120 may include a processor chipset (e.g., processing device 118) and a software stack executed by the processor chipset. The processor chipset may include one or more cores, one or more caches, a memory controller (e.g., controller 116) (e.g., an NVDIMM controller), and a storage protocol controller (e.g., a PCIe controller, a SATA controller). Host system 120 uses memory subsystem 110, for example, to write data to and read data from memory subsystem 110.

[0030] Host system 120 can be coupled to memory subsystem 110 via a physical host interface. Examples of physical host interfaces include, but are not limited to, Serial Advanced Technology Attachment (SATA) interfaces, Peripheral Component Interconnect Fast (PCIe) interfaces, Universal Serial Bus (USB) interfaces, Fibre Channel, Serial Attached SCSI (SAS) interfaces, Double Data Rate (DDR) memory bus interfaces, Small Computer System Interface (SCSI), Dual In-line Memory Module (DIMM) interfaces (e.g., DIMM socket interfaces supporting Double Data Rate (DDR)), Open NAND Flash Interface (ONFI), Double Data Rate (DDR) interfaces, Low Power Double Data Rate (LPDDR) interfaces, or any other interfaces. The physical host interface can be used to transfer data between host system 120 and memory subsystem 110. When memory subsystem 110 is coupled to host system 120 via a PCIe interface, host system 120 can further utilize an NVM Fast (NVMe) interface to access components (e.g., memory device 130). The physical host interface provides an interface for transmitting control, address, data and other signals between the memory subsystem 110 and the host system 120. Figure 1The memory subsystem 110 is described as an example. Generally, the host system 120 can access multiple memory subsystems via the same communication connection, multiple individual communication connections, and / or combinations of communication connections.

[0031] The processing unit 118 of the host system 120 may be, for example, a microprocessor, a central processing unit (CPU), a processor core, an execution unit, etc. In some examples, the controller 116 may be referred to as a memory controller, a memory management unit, and / or a starter. In one instance, the controller 116 controls communication via a bus coupled between the host system 120 and the memory subsystem 110. Generally, the controller 116 may send commands or requests to the memory subsystem 110 to request access to memory devices 130, 140. The controller 116 may further include interface circuitry for communicating with the memory subsystem 110. The interface circuitry may translate responses received from the memory subsystem 110 into information for the host system 120.

[0032] The controller 116 of the host system 120 can communicate with the controller 115 of the memory subsystem 110 to perform operations such as reading, writing, or erasing data at memory devices 130, 140, and other such operations. In some examples, the controller 116 is integrated within the same package as the processing device 118. In other examples, the controller 116 is packaged separately from the processing device 118. The controller 116 and / or the processing device 118 may include hardware such as one or more integrated circuits (ICs) and / or discrete components, buffer memory, cache memory, or combinations thereof. The controller 116 and / or the processing device 118 may be a microcontroller, a special-purpose logic circuit (e.g., a field-programmable gate array (FPGA), an application-specific integrated circuit (ASIC), etc.), or another suitable processor.

[0033] Memory devices 130 and 140 may include different types of non-volatile memory components and / or any combination of volatile memory components. Volatile memory devices (e.g., memory device 140) may be, but are not limited to, random access memory (RAM), such as dynamic random access memory (DRAM) and synchronous dynamic random access memory (SDRAM).

[0034] Examples of non-volatile memory components include NAND flash memory and in-situ write memory, such as three-dimensional crosspoint (“3D crosspoint”) memory. Crosspoint arrays of non-volatile memory can be combined with stackable cross-grid data access arrays to perform bit storage based on changes in volume resistance. Furthermore, compared to many flash-based memories, crosspoint non-volatile memory can perform in-situ write operations, where the non-volatile memory cells can be programmed without previously erasing them. NAND flash memory includes, for example, two-dimensional NAND (2D NAND) and three-dimensional NAND (3D NAND).

[0035] Each of the memory devices 130 may include one or more arrays of memory cells. One type of memory cell (e.g., a single-level cell (SLC)) may store one bit per cell. Other types of memory cells (e.g., multi-level cell (MLC), three-level cell (TLC), four-level cell (QLC), and five-level cell (PLC)) may store multiple bits per cell. In some embodiments, each of the memory devices 130 may include an array of one or more memory cells (e.g., SLC, MLC, TLC, QLC, PLC, or any combination thereof). In some embodiments, a particular memory device may 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 device 130 may be grouped into pages that may refer to logical units of the memory device used for storing data. For some types of memory (e.g., NAND), pages may be grouped to form blocks.

[0036] Although a non-volatile memory device such as 3D cross-point type and NAND type memory (e.g. 2D NAND, 3D NAND) is described, the memory device 130 may be based on any other type of non-volatile memory, such as read-only memory (ROM), phase change memory (PCM), self-select 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 bridged RAM (CBRAM), resistive random access memory (RRAM), oxide-based RRAM (OxRAM), NOR flash memory, and electrically erasable programmable read-only memory (EEPROM).

[0037] The memory subsystem controller 115 (or simply controller 115) can communicate with the memory device 130 to perform operations such as reading data, writing data, or erasing data at the memory device 130, and other such operations (e.g., responding to commands scheduled on the command bus by controller 116). Controller 115 may include hardware, such as one or more integrated circuits (ICs) and / or discrete components, buffer memories, or combinations thereof. The hardware may include digital circuitry with dedicated (e.g., hard-write code) logic to perform the operations described herein. Controller 115 may be a microcontroller, dedicated logic circuitry (e.g., field-programmable gate array (FPGA), application-specific integrated circuit (ASIC), etc.), or another suitable processor.

[0038] The controller 115 may include a processing means 117 (e.g., a processor) configured to execute instructions stored in local memory 119. In the illustrated example, the local memory 119 of the controller 115 includes embedded memory configured to store instructions for performing various processes, operations, logical flows, and operations of the memory subsystem 110 (including handling communication between the memory subsystem 110 and the host system 120).

[0039] In some embodiments, local memory 119 may include memory registers storing memory pointers, fetched data, etc. Local memory 119 may also include read-only memory (ROM) for storing microprogram code. Although Figure 1 The instance memory subsystem 110 has been described as including controller 115, but in another embodiment of this disclosure, the memory subsystem 110 does not include controller 115 and may instead rely on external control (e.g., provided by an external host or a processor or controller separate from the memory subsystem).

[0040] Generally, controller 115 can receive commands or operations from host system 120 and can translate these commands or operations into instructions or appropriate commands to enable desired access to memory device 130. Controller 115 may handle other operations such as wear leveling, discarded item collection, error detection and error correction code (ECC) operations, encryption, caching, and address translation between logical addresses (e.g., logical block addresses, namespaces) and physical addresses (e.g., physical block addresses) associated with memory device 130. Controller 115 may further include host interface circuitry for communicating with host system 120 via a physical host interface. The host interface circuitry can translate commands received from the host system into command instructions for accessing memory device 130, and translate responses associated with memory device 130 into information for host system 120.

[0041] The memory subsystem 110 may also include additional circuitry or components not described. In some embodiments, the memory subsystem 110 may include cache or buffer (e.g., DRAM) and address circuitry (e.g., row decoder and column decoder) capable of receiving addresses from the controller 115 and decoding the addresses to access the memory device 130.

[0042] In some embodiments, memory device 130 includes a local media controller 150, which operates in conjunction with a memory subsystem controller 115 to perform operations on one or more memory cells of memory device 130. An external controller (e.g., memory subsystem controller 115) may externally manage memory device 130 (e.g., perform media management operations on memory device 130). In some embodiments, memory device 130 is a managed memory device, which is a native memory device combined with a local controller (e.g., local media controller 150) for media management within the same memory device package. An example of a managed memory device is a managed NAND (MNAND) device.

[0043] Controller 115 and / or memory device 130 may include a security manager 113 configured to use signed commands to commit file data buffered in an insecure segment of memory device 130 to a secure segment of memory device 130. In some embodiments, controller 115 and / or local media controller 150 in memory subsystem 110 may include at least a portion of security manager 113. In other embodiments or combinations, controller 116 and / or processing device 118 in host system 120 may include at least a portion of security manager 113. For example, controller 115, controller 116, and / or processing device 118 may include logic circuitry implementing security manager 113. For example, controller 115 or processing device 118 of host system 120 (e.g., a processor) may be configured to execute instructions stored in memory for performing the operations of security manager 113 described herein. In some embodiments, security manager 113 is implemented in an integrated circuit chip disposed in memory subsystem 110. In other embodiments, the security manager 113 may be part of the firmware of the memory subsystem 110, the operating system of the host system 120, a device driver or application, or any combination thereof.

[0044] For example, the operating system of computing system 100 may issue an unsigned command to write file data to memory device 130. The data of the unsigned command may be stored in a buffer within memory device 130. For example, a non-secure section of memory device 130 may be used as a non-volatile buffer to store the data of the unsigned command. Therefore, typical modules of the operating system associated with file system operations do not need to be able to sign write commands and / or know the authentication requirements of secure sections in memory device 130. In response to an instruction to submit a file to a file system mounted in a secure section of the memory device, security manager 113 may identify the data of the file to be stored in the file system mounted in the secure section and generate a signed command to write the data to the secure section.

[0045] Figure 2 This describes an integrated circuit memory device with a security manager according to one embodiment. For example, Figure 1 The memory device 130 in the memory subsystem 110 can be used Figure 2 The integrated circuit memory device 130 is used for implementation.

[0046] The integrated circuit memory device 130 may be enclosed in a single integrated circuit package. The integrated circuit memory device 130 includes multiple memory regions 131, ..., 133 that may be formed in one or more integrated circuit dies. Typical memory cells in memory regions 131, ..., 133 may be programmed to store one or more data bits.

[0047] The local media controller 150 may include at least a portion of a security manager 113 configured to control access to at least one of the memory areas 131, ..., 133.

[0048] For example, security manager 113 may control access to secure memory area 133 based on a cryptographic key generated from the secrets of integrated circuit memory device 130 and / or a cryptographic key representing the owner or authorized user of memory device 130. For example, when a request or command to write data to secure memory area 133 is received in integrated circuit memory device 130, security manager 113 verifies whether the request comes from a requester with a cryptographic key. If not, security manager 113 may refuse the write request. To prove that the request comes from an authorized requester, the requester may digitally sign the request or challenge message using the cryptographic key. When secure memory device 130 determines that the digital signature was formed using the cryptographic key, the requester has permission to write data to memory area 131. For example, memory device 130 may store a cryptographic key 151 used to authenticate the digital signature of the signed request / command.

[0049] Generally, secure memory area 133 may have different security requirements for different types of access (e.g., read, write, erase). For example, secure memory area 133 may be configured to require a digital signature verifiable via cryptographic key 151 to write or modify data in secure memory area 133, but not to require a signed command to read data from secure memory area 133. Alternatively, secure memory area 133 may be configured to require a digital signature verifiable via cryptographic key 151 to read, write, and / or modify data in secure memory area 133. Alternatively, secure memory area 133 may be configured to require digital signatures verifiable via different cryptographic keys for different operations (e.g., read, write, modify, erase, etc.) within secure memory area 133.

[0050] For example, computing system 100 may mount a file system in secure storage area 133, such that file system data 171 will be stored in secure storage area 133. Access to file system data 171 stored in secure storage area 133 may require a command / request signed with a cryptographic compile key associated with access control of secure storage area 133.

[0051] To facilitate the recording of files in the file system, storage device 130 may allocate a non-secure storage area 131 to buffer file data for access requests / files. The non-secure storage area 131 can be accessed via requests / commands without an attached digital signature from the requester. Therefore, the non-secure storage area 131 may be used by controller 150 as a buffer to store file write data 173 associated with files in the file system mounted in secure storage area 133. In response to an instruction to submit a file, security manager 113 (e.g., implemented in storage device 130, or partially running in the processing unit 118 of host system 120 and / or the processing unit 117 of the controller of storage subsystem 110) may copy valid file data from non-secure storage area 131 to secure storage area 133. Optionally, security manager 113 and / or the operating system may further verify that the file was written by an authorized user and / or owner of storage device 130 before submitting the file to secure storage area 133.

[0052] Integrated circuit memory device 130 has a communication interface 147 for receiving commands with address 135 from controller 115 of memory subsystem 110. In response to identifying address 135 of memory region 131 requesting access control, before providing memory data retrieved from memory region 131 using address decoder 141, security manager 113 may perform a cryptographic operation to verify that the request originates from a requester with an authorized cryptographic key for accessing memory region 131. Address decoder 141 of integrated circuit memory device 130 translates address 135 into a control signal to select a group of memory cells in integrated circuit memory device 130; and local media controller 150 of integrated circuit memory device 130 performs an operation to determine the memory data stored in the memory cell at address 135.

[0053] Figure 3 This describes a mechanism, according to one embodiment, that supports writing files to a file system mounted on a secure storage device. For example, it can be... Figure 1 and / or Figure 2 Implemented in the memory device 130 Figure 3 The mechanism.

[0054] exist Figure 3 In this context, the record of the command used to write a file to a file system mounted in the secure storage area 133 can be buffered as file write data 173 in the insecure storage area 131. For example, when an application requests the operating system of the computing system to write data to a file in the file system, the operating system can verify the requester's access rights and then generate an unsigned command. Upon receiving the unsigned command, the memory device 130 generates a write record 121 for the write command in the insecure storage area 131. The write record 121 identifies the file and the location of the data in the file. However, the target location of the data within the secure storage area 133 has not yet been determined. Another request to write data to the same file (or another file) in the file system can generate another write record 123.

[0055] Optionally, write records can be processed and organized according to the file recording session (e.g., 121, ..., 123). When a file in the file system mounted in the secure storage area 133 is opened for recording, the storage device 130 may accept unsigned write commands for storage / buffering in the insecure storage area 131. Therefore, when there is no active recording session for a file in the file system mounted in the secure storage area 133, the storage device 130 may reject unsigned write commands to improve security.

[0056] In response to a request to submit a file or the closing of a file record session, the security manager 113 identifies data / file content eligible to be written to the secure storage area 133 from write records (e.g., 121, 123, ...) and generates a command to write the data / file content to the secure storage area 133.

[0057] The file system data 171 in the secure storage area 133 may include metadata 175 and file data 177. Metadata 175 includes a file identifier 185 and its file storage location 187 in the secure storage area 133. The file storage location 187 identifies one or more portions of the file's content at one or more locations in the secure storage area 133. The file's content is stored as file data 177 at the location identified by the file storage location 187 in the secure storage area 133. The file identifier 185 identifies the file and / or its content in a manner independent of its physical storage in the data storage device. The file system tracks the metadata 175, enabling applications to invoke the operating system of the computing system 100 to store or retrieve data without knowing the physical file storage location 187.

[0058] For example, in response to a request to submit file data / content, security manager 113 determines file storage location 187 and generates a command to write the file content to several locations in secure storage area 133 identified by file storage location 187. For example, file system / operating system may allocate a portion of the storage capacity in secure storage area 133 for file data 177, and thus determine file storage location 187 of file identification 185.

[0059] Generally, some data in the files specified in write records 121, 123, ... may become invalid for various reasons. For example, some data may subsequently be overwritten or changed. For example, some file write operations may be interrupted and / or canceled. For example, some file data may become invalid, corrupted, and / or reversed. The final valid version of the file content to be committed to the file system can be determined from the analysis of write records 121, 123, ... etc. Subsequently, the file system generates and / or updates the relevant portions of metadata 175 to specify the location in the secure storage area 133 for storing the file content. Based on the file storage location 187, a signed write command can be generated by the security manager 113 to write file data 177 to the secure storage area 133.

[0060] For example, a portion of security manager 113 may be implemented as an application or module of the operating system of computing system 100. When the operating system is started (e.g., during operating system startup), a portion of security manager 113 may be initialized to have a valid cryptographically compiled key for signing commands transferred to memory subsystem 110 for writing file data 177 to secure memory area 133 of memory device 130. In response to an instruction or decision to submit a file to the file system, a portion of security manager 113 may be invoked by the operating system to identify the contents to be written to secure memory area 133 and generate the contents for writing the file with signed commands.

[0061] Alternatively, a portion of the security manager 113 may be implemented in the controller 150 of the memory device 130 and / or the controller 115 of the memory subsystem 110 to write valid file data 177 to the secure memory area 133.

[0062] Figure 4 This describes the use of a security manager, according to one embodiment, for writing files to a file system mounted on a secure storage device. For example, it can be used in a device with... Figure 2 The memory device 130 Figure 1 The computing system 100 uses Figure 3 To implement the technology Figure 4 The operation.

[0063] exist Figure 4 In this process, application program 165 running on processing device 118 of host system 120 calls operating system 167 of computing system 100. For example, operating system 167 may initially be stored in secure memory area 133 (or another secure memory area in memory device 130). During startup, security manager 113 may verify that operating system 167 has not been altered, tampered with, and / or damaged before providing operating system 167 to processing device 118 of host system 120 for execution.

[0064] Generally, the operating system 167 and / or application 165 may not have the credentials to issue a signed command to write data to the secure memory area 133 of the memory device 130 in the memory subsystem 110. However, the operating system 167 may mount the file system 161 to the secure memory area 133 of the memory device 130.

[0065] When application 165 requests changes to file system 161, operating system 167 may generate an unsigned write command 181. When storage device 130 receives the unsigned write command 181, storage device 130 may buffer the command 181 as part of file write data 173 in insecure storage area 131. For example, a write record (e.g., 121 or 123) may be generated for the unsigned write command 181. In some embodiments, write records (e.g., 121 or 123) are generated and / or buffered in insecure storage area 131 for a specific file recording session. When no valid file recording session exists, the unsigned write command 181 may be rejected.

[0066] For example, the file write data 173 generated by write command 181 may include file identification 185 and file data 177. File identification 185 identifies the file in file system 161 and the location of file data 177 within the file.

[0067] When a file is ready to be committed to the file system 161, the file system 161 determines the file storage location 187 in the secure storage area 133 based on file identification 185. A routine of the security manager 113 can be invoked by the operating system 167 to identify file data 177 using a signed write command 183 and write the file data 177 to the file storage location 187 in the secure storage area 133.

[0068] For example, the routine of security manager 113 has a cryptographic key 153 that can be used to sign commands for writing file data 177. The signed write command 183 contains a digital signature 163 that can be verified by memory device 130 using cryptographic key 151. When using asymmetric cryptography, cryptographic key 153 can be the private key of a key pair; and cryptographic key 151 can be the public key of a key pair. When using symmetric cryptography, cryptographic key 153 is the same as cryptographic key 151. Cryptographic key 153 and / or 151 can be generated when operating system 167 is started and / or when the routine of security manager 113 is initialized.

[0069] In response to a signed write command 183 generated by a routine of security manager 113 (e.g., executed in host system 120 and / or controller 115), memory device 130 verifies digital signature 163 to write file data 177 to secure storage area 133. The signed write command can be used to update metadata 175 in a similar manner to store data representing the relationship between file identification 185 and file storage location 187. Metadata 175 allows the file system to retrieve file data 177 at the corresponding location in secure storage area 133 based on a reference to file identification 185. For example, application 165 can use file identification 185 to read / retrieve file data 177.

[0070] Generally, the recording of write commands (e.g., 181) of the operating system 167 can be buffered in the insecure storage area 131; and the security manager 113 can be implemented as a centralized agent of the operating system 167 and / or the file system to write valid file data 177 to the secure storage area 133 with authorization that can be confirmed by a digital signature established using the cryptographic compilation key 153.

[0071] Figure 5 A method for writing a file to a secure storage device according to one embodiment is shown. Figure 5 The method can be performed by processing logic that may include hardware (e.g., processing device, circuit system, dedicated logic, programmable logic, microprogram code, device hardware, integrated circuit, etc.), software / firmware (e.g., instructions that run or execute on the processing device), or a combination thereof. In some embodiments, Figure 5 The method is at least in part by Figure 1 Controller 150 and / or controller 115 or Figure 2 The processing logic is executed in the memory device 130. Although shown in a specific sequence or order, the order of the 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.

[0072] exist Figure 5 In block 301, file system 161 is mounted in secure storage area 133 of storage device 130. Storage device 130 is configured to write data to secure storage area 133 based on commands authenticated by cryptographic compilation key 153.

[0073] For example, when a write command is signed using the cryptographic compilation key 153, the write command is executed via the memory device 130 to write the data to the secure memory area 133; otherwise, the command is rejected or buffered to the insecure memory area 131.

[0074] In box 303, the host system 120 and / or controller 115 of the memory subsystem sends a first command to the memory device 130 to write data into the file system 161.

[0075] For example, the first command could be an unsigned write command 181 generated by one or more non-privileged modules of the operating system 167. The non-privileged modules do not have a cryptographically compiled key 153 that has been authenticated by the memory device 130 for writing data to the secure memory area 133.

[0076] In box 305, memory device 130 determines, based on cryptographic compilation key 153, that the first command failed authentication (e.g., due to missing signal signature).

[0077] In block 307, memory device 130 and / or security manager 113 store the write record of the first command (e.g., 121, ..., 123) in insecure memory area 131.

[0078] In box 309, computing system 100 receives a request to submit a file to file system 161.

[0079] In box 311, security manager 113 determines file data 177 of a file to be committed to a file system 161 mounted in secure storage area 133 based on write records (e.g., 121, ..., 123) stored in insecure storage area 131.

[0080] In box 313, security manager 113 generates a second command based on cryptographic compilation key 153 to write file data 177 into secure storage area 133.

[0081] For example, the first command does not have a digital signature and therefore fails authentication based on cryptographic key 153. The second command has a digital signature signed using cryptographic key 153 and therefore passes authentication for execution.

[0082] Optionally, the security manager 113 and / or the operating system 167 may open a recording session for a file in the file system, such that while the recording session is active, an unsigned write command 181 can be recorded in the insecure storage area 131. In response to closing the recording session, the operating system 167 and / or the security manager 113 may commit the file to the file system 161.

[0083] Operating system 167 and / or security manager 113 can determine the storage location 187 of the contents of a file allocated for storage in secure storage area 133. A second command can be generated based on storage location 187. Security manager 113 can further generate one or more third commands based on cryptographic compiling key 153 to write metadata 175 to file system 161. For example, the third command can be signed to include a digital signature 163 to pass authentication performed by memory device 130 for use in writing to secure storage area 133. Metadata 175 can identify the association between logical locations in the file and the physical storage location of file data 177 stored in secure storage area 133.

[0084] For example, the first command may include a logical identifier of the file and its data in the file system 161. The logical identifier is independent of the physical storage location of the file's contents in the memory device 130.

[0085] For example, operating system 167 may receive a request from an application (e.g., 165) to generate a first command. A module of the operating system that does not possess the cryptographic compilation key 153 may use an unsigned write command 181 to write a record of a file write request to insecure storage area 131. When operating system 167 is ready to commit the file, it may invoke security manager 113 to write the file to secure storage area 133 based on the write records (e.g., 121, ..., 123) in insecure storage area 131.

[0086] Optionally, the cryptographic key 153 of the security manager 113 can be configured at the startup time of the operating system 167. For example, during startup, instructions for the security manager 113 can be loaded from the secure storage area 133 for execution; and the cryptographic key 153 can be generated for the security manager 113 when it is manifested. The security manager 113 is authorized to write data to the secure storage area 133 by receiving the cryptographic key 153, which can be used to generate a digital signature 163 that can be confirmed using the corresponding key 151 stored in the memory device 130.

[0087] Figure 6 This describes an instance machine of computer system 400, within which a set of instructions can be executed to cause the machine to perform any or more of the methodologies discussed herein. In some embodiments, computer system 400 may correspond to a host system (e.g., Figure 1 The host system 120 includes, is coupled to, or utilizes a memory subsystem (e.g., Figure 1 The memory subsystem 110) or can be used to perform operations of the security manager 113 (e.g., execute instructions to perform actions corresponding to the security manager 113). Figures 1 to 5 The operation of the security manager 113 is described. In alternative embodiments, the machine may be connected (e.g., network linked) to other machines in a LAN, internal network, external network, and / or the Internet. The machine may operate as a server or client machine in a client-server network environment, as a peer machine in a peer-to-peer (or distributed) network environment, or as a server or client machine in a cloud computing infrastructure or environment.

[0088] A machine may be a personal computer (PC), a tablet PC, a set-top box (STB), a personal digital assistant (PDA), a cellular phone, a network appliance, a server, a network router, a switch, or a bridge, or any machine capable of executing a set of instructions (sequentially or otherwise) specifying actions to be taken by said machine. Furthermore, while describing a machine, the term "machine" should also be considered as any collection of machines that individually or jointly execute one or more sets of instructions to perform any one or more of the methodologies discussed herein.

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

[0090] Processing device 402 represents one or more general-purpose processing devices, such as microprocessors, central processing units, or the like. More specifically, the processing device may be a Complex Instruction Set Computing (CISC) microprocessor, a Reduced Instruction Set Computing (RISC) microprocessor, a Very Long Instruction Word (VLIW) microprocessor, or a processor implementing other instruction sets, or multiple processors implementing combinations of instruction sets. Processing device 402 may also be one or more special-purpose processing devices, such as application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), digital signal processors (DSPs), network processors, or the like. Processing device 402 is configured to execute instructions 426 for performing the operations and steps discussed herein. Computer system 400 may further include a network interface device 408 for communication via network 420.

[0091] Data storage system 418 may include machine-readable medium 424 (also referred to as computer-readable medium), on which one or more sets of instructions 426 or software embodying any one or more of the methodologies or functions described herein are stored. Instructions 426 may also reside wholly or at least partially within main memory 404 and / or processing device 402 during execution by computer system 400, main memory 404, and processing device 402, which also constitute machine-readable storage media. Machine-readable medium 424, data storage system 418, and / or main memory 404 may correspond to... Figure 1 The memory subsystem 110.

[0092] In one embodiment, instruction 426 includes instructions for implementing the security manager 113 (e.g., regarding...). Figures 1 to 5 The description describes the functional instructions of the security manager 113. Although the machine-readable medium 424 is shown as a single medium in the exemplary embodiment, the term "machine-readable storage medium" should be considered as including a single medium or multiple media storing one or more sets of instructions. The term "machine-readable storage medium" should also be considered as including any medium capable of storing or encoding sets of instructions for machine execution and causing the machine to perform any or more of the methodologies of this disclosure. Therefore, the term "machine-readable storage medium" should be considered as including, but not limited to, solid-state memory, optical media, and magnetic media.

[0093] Some portions of the foregoing "Detailed Description" have been presented based on algorithms and symbolic representations of operations performed on data bits within computer memory. These algorithmic descriptions and representations are methods used by those skilled in the art to most effectively communicate the main points of their work to others skilled in the art. Algorithms herein are generally considered to be self-consistent sequences of operations that lead to a desired result. An operation is an operation that requires the physical manipulation of physical quantities. Typically, but not necessarily, these quantities take the form of electrical or magnetic signals that can be stored, combined, compared, and otherwise manipulated. Sometimes, primarily for general reasons, it has proven convenient to refer to these signals as bits, values, elements, symbols, characters, terms, numbers, or the like.

[0094] However, it should be remembered that all these and similar terms should be associated with appropriate physical quantities and are merely convenient labels for application to those quantities. This disclosure may refer to the actions and processes by which a computer system or similar electronic computing device manipulates data representing physical (electronic) quantities in the registers and memories of the computer system and transforms said data into other data similarly represented in the memory or registers of the computer system or other such information storage systems.

[0095] This disclosure also relates to an apparatus for performing the operations described herein. This apparatus may be specially configured for its intended purpose, or may comprise a general-purpose computer selectively started or reconfigured by a computer program stored in a computer. This computer program may 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 magneto-optical disks), read-only memory (ROM), random access memory (RAM), EPROM, EEPROM, magnetic or optical cards, or any type of media suitable for storing electronic instructions, each coupled to a computer system bus.

[0096] The algorithms and displays presented herein are not inherently related to any particular computer or other device. Various general-purpose systems can be used with the programs based on the teachings herein, or it may be proven convenient to construct more specialized devices to implement the methods. The structures of many of these systems will be presented as described below. Furthermore, this disclosure is described without reference to any particular programming language. It will be understood that the teachings of this disclosure as described herein can be implemented using various programming languages.

[0097] This disclosure can be provided as a computer program product or software that may include machine-readable media on which instructions are stored, which can be used to program a computer system (or other electronic device) to perform processes according to this disclosure. Machine-readable media includes any means for storing information in a form readable by a machine (e.g., a computer). In some embodiments, machine-readable (e.g., computer-readable) media includes machine-readable storage media, such as read-only memory (“ROM”), random access memory (“RAM”), disk storage media, optical storage media, flash memory components, etc.

[0098] In this description, various functions and operations are described as being executed or caused by computer instructions for the sake of simplicity. However, those skilled in the art will recognize that such expressions mean that the function is produced by the execution of computer instructions using one or more controllers or processors (e.g., microprocessors). Alternatively or in combination, functions and operations may be implemented using dedicated circuit systems with or without software instructions (e.g., using application-specific integrated circuits (ASICs) or field-programmable gate arrays (FPGAs)). Embodiments may be implemented using hard-wired circuitry without software instructions or in combination with software instructions. Therefore, the technology is neither limited to any particular combination of hardware circuit systems and software, nor to any particular source of instructions executed by a data processing system.

[0099] In the foregoing description, embodiments of the present disclosure have been described with reference to specific exemplary embodiments. It will be apparent that various modifications can be made to the present disclosure without departing from the broader spirit and scope of the embodiments set forth in the appended claims. Therefore, the description and drawings should be regarded as illustrative rather than restrictive.

Claims

1. A method comprising: A file system is mounted into a secure storage area in a storage device, which is configured to write data to the secure storage area based on a cryptographically compiled key authentication command. Send a first command to the memory device to write data into the file system; Based on the cryptographic compilation key, it is determined that the first command failed authentication; The record of the first command is stored in the insecure memory area of ​​the memory device; and In response to a request to submit a file to the file system, The file data of the file to be submitted to the file system installed in the secure storage area is determined based on the records stored in the insecure storage area; and A second command is generated based on the cryptographic compilation key to write the file data into the secure storage area.

2. The method of claim 1, wherein the first command does not have a digital signature; and the second command has a digital signature signed using the cryptographic compilation key.

3. The method according to claim 2, further comprising: Open a recording session for the file in the file system, wherein the first command is recorded in the insecure storage area in response to the recording session being active.

4. The method of claim 3, further comprising: The recording session is closed, wherein the request to submit the file is in response to the closure of the recording session.

5. The method of claim 4, further comprising: Determine the storage location within the secure storage area allocated to store the contents of the file; The second command is based on the storage location.

6. The method of claim 5, further comprising: Based on the cryptographic compilation key, one or more third commands are generated to write metadata to the file system, the metadata identifying the storage location of the content of the file.

7. The method of claim 5, wherein the first command includes identification of the file in the file system; and wherein the identification is independent of the storage location of the content of the file.

8. The method of claim 5, further comprising: The operating system receives a request to generate the first command, wherein the operating system does not possess the cryptographic compilation key; and The operating system invokes a security manager to submit the file to the file system, wherein the security manager possesses the cryptographic compilation key.

9. The method of claim 8, further comprising: The instructions of the security manager are loaded from the secure storage area for execution at the startup time of the operating system.

10. The method of claim 9, further comprising: During the startup time, the security manager is configured with the cryptographic compilation key to authorize the security manager to write data into the secure storage area.

Images