Memory system and security verification method
Patent Information
- Application Number
- JP2023149091
- Authority / Receiving Office
- JP · JP
- Patent Type
- Applications
- Current Assignee / Owner
- Filing Date
- 2023-09-14
- Publication Date
- 2025-03-27
Smart Images

Figure 2025042215000001_ABST
Abstract
Description
[Technical field]
[0001] 1. Field of the Invention The present invention relates to a memory system and a method for verifying safety. [Background technology]
[0002] In recent years, the spread of smartphones and cloud services, and the widespread use of IoT (Internet of Things) devices have created an environment in which various information devices and electronic devices are connected to the Internet. This environment has led to a society in which remote information and devices can be accessed anytime and anywhere. As a result, while the majority of information devices and electronic devices were previously managed by administrators with specialized knowledge, the majority of information devices and electronic devices are now managed by administrators without specialized knowledge.
[0003] Devices connected to the Internet are exposed to various threats, including the risk of security being affected by malware intrusion and the risk of becoming the source of a Distributed Denial of Service (DDOS) attack.
[0004] As interest in security measures for such information devices grows, there is an ever-increasing demand for security when using information in memory systems such as solid state drives (SSDs) in order to safely protect various types of information.
[0005] In light of this, mechanisms have been proposed for increasing the security of individual active devices, particularly devices connected to the Internet.
[0006] Additionally, mechanisms for enhancing security have come into widespread use, including a Root of Trust (RoT) for strict information management and a Trusted Execution Environment (TEE) that is an isolated environment with the ability to safely execute specific processes independent of the operating system.
[0007] Recently, mechanisms for enhancing the safety of these devices have been introduced, making it easier to build mechanisms for certifying the safety of devices that are specific to those devices.
[0008] On the other hand, the introduction of a mechanism for proving mutual integrity by attestation is currently underway as a mechanism for enhancing the security of devices that are interoperable between devices that can communicate with each other. The mechanism for enhancing the security of devices by attestation makes it possible to verify whether software running on devices that may be compromised by malware, etc., has been compromised.
[0009] However, for passive devices used inside a computer, including memory systems, although there are mechanisms for attesting the security of the device itself, there are limitations to the means of voluntary communication, and therefore no mechanism has been introduced to improve the security of the device by attestation, in which the memory system verifies software that runs on the device that uses the memory system.
[0010] In addition, between the host and the memory system, NVM Express, an interface protocol that allows the host to access data stored in the memory system, is used. TM (NVMe TM ) is sometimes used. NVM Express TM (NVMe TMIn a memory system that employs the IEEE 802.11a standard, it is not possible to initialize or monitor the device status by configuration transactions from devices other than the host. This makes it difficult to perform mutual verification based on the communication used for attestation with the memory system. [Prior art documents] [Patent documents]
[0011] [Patent Document 1] Patent No. 6484255 Summary of the Invention [Problem to be solved by the invention]
[0012] The embodiments of the present invention provide a memory system and a method for verifying safety that can actively verify the safety of applications, services, etc. on a host. [Means for solving the problem]
[0013] According to an embodiment, a memory system includes a non-volatile memory and a controller, the controller verifies the security of a requester requesting to write data to the non-volatile memory or to read data from the non-volatile memory by a challenge-response attestation. [Brief description of the drawings]
[0014] [Figure 1] FIG. 1 is a diagram showing an example of the configuration of a computer system according to a first embodiment. [Diagram 2] FIG. 1 is a diagram showing an example of a configuration of a memory system according to a first embodiment; [Diagram 3] A diagram showing an example of challenge-response attestation [Figure 4] FIG. 1 is a diagram showing an example of a criterion for determining whether to permit or not permit a read request or a write request when the request occurs in the memory system of the first embodiment; [Diagram 5] FIG. 1 is a process flow diagram showing whether a read request or a write request is permitted or not when the request occurs in the memory system according to the first embodiment; [Figure 6] FIG. 11 is a sequence diagram when a service / application reads / writes data from / to the memory system in the first embodiment; [Figure 7] FIG. 1 is a diagram showing an example of the configuration of a computer system according to a second embodiment. [Figure 8] FIG. 13 is a diagram showing another example of a criterion for determining whether a read request or a write request is permitted or not when the request is generated in the memory system of the third embodiment. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS
[0015] Hereinafter, embodiments will be described with reference to the drawings.
[0016] (First embodiment) First, the first embodiment will be described.
[0017] FIG. 1 is a diagram showing an example of the configuration of a computer system 1 according to the first embodiment.
[0018] The computer system 1 includes a host device 100, an application processing device 101, and a memory system 102. The host device 100, the application processing device 101, and the memory system 102 are connected via a bus 103.
[0019] The host device 100 and the application processing device 101 are devices that include a root of trust (RoT) and an isolated environment (TEE: isolated execution environment) 105, 108, respectively. The host device 100 and the application processing device 101 include applications / drivers 106, 109 that perform verification-related processing between the host device 100 and the application processing device 101 and the memory system 102 in the isolated execution environments 105, 108.
[0020] The host device 100 is, for example, a server or a PC (Personal Computer). The application processing device 101 is, for example, a GPU (Graphics Processing Unit). A service / application 104 that executes various information processes involving reading / writing data from / to a memory system 102 runs on the host device 100. Also, a service / application 107 that executes various information processes involving reading / writing data from / to the memory system 102 runs on the application processing device 101.
[0021] Memory system 102 includes media control unit 110, memory transaction manager 111, attestation manager 112, volatile memory 113, and non-volatile memory 114. As indicated by dashed lines, media control unit 110, memory transaction manager 111, and attestation manager 112 are configured as controllers using circuits (devices) such as SoC (System on Chip). Some of the processing of media control unit 110, memory transaction manager 111, and attestation manager 112 can be realized by a CPU included in the controller executing a predetermined program.
[0022] The secure path for the memory system 102 to perform the verification uses a path that can be accessed by a memory transaction. In the first embodiment, the memory system 102 is, for example, an NVM Express TM (NVMe TM ) standard-compliant protocol for NVMe TM SSD. Bus 103 is PCI Express TM (PCIe TM ) standard.
[0023] PCIe TMThe standard provides memory transactions for read / write operations in the memory address space, configuration transactions for device initialization and status monitoring, I / O transactions for read / write operations in the I / O address space, and message transactions for notifying events. TM In the standard, configuration transactions, memory transactions, and I / O transactions are available as standard, and memory transactions using the CMB (Controller Memory Buffer) / PMR (Persistent Memory Region) functions are available as an option. Therefore, in the first embodiment, the secure path is realized by memory transactions on an interface using the CMB / PMR functions.
[0024] The CMB / PMR function is a function that exposes the internal memory area of the memory system 102 to an application through memory mapping (Memory Mapped I / O: MMIO). The host device 100 or the application processing device 101 establishes a secure path with the memory system 102 by MMIO using the CMB / PMR function during a secure startup stage using the isolated execution environments 105 and 108. When making a normal read request / write request to the memory system 102, an I / O transaction is used, which does not need to be a secure path. In FIG. 1, memory transactions using a secure path are represented by solid arrows, and other transactions are represented by dashed arrows.
[0025] Fig. 2 is a diagram showing an example of the configuration of the memory system 102 of the first embodiment. In Fig. 2, a plurality of components within the dashed lines are components that function as a controller.
[0026] The media control unit 110 comprehensively controls the operation of the memory system 102. The media control unit 110 has an NVMe host interface 201, a flash translation layer (FTL) 202, and a flash interface layer 203. The NVMe host interface 201 controls communication with the host device 100 in compliance with the NVMe standard. The flash translation layer 202 manages the correspondence between addresses managed by the host device 100 and storage areas of the memory system 102. The flash interface layer 203 controls communication with the non-volatile memory 114.
[0027] The memory transaction manager 111 includes a secure communication unit 205. The secure communication unit 205 performs interface processing for constructing a secure path by MMIO using the CMB / PMR function.
[0028] The attestation manager 112 performs challenge-response type attestation. The attestation manager 112 includes an authentication processing unit 206 and a policy management unit 207. The authentication processing unit 206 manages and controls the processes required for verification. The policy management unit 207 determines whether or not to perform verification.
[0029] The volatile memory 113 is, for example, a static RAM (random access memory) or a dynamic RAM (DRAM). The non-volatile memory 114 is, for example, a NAND type flash memory.
[0030] FIG. 3 is a diagram showing an example of challenge-response type attestation.
[0031] In the challenge-response attestation, a challenge message including a nonce and a key identifier is provided to a prover 302 by a verifier 301 (S301, S302). In (S301), the verifier 301 generates a challenge message. The challenge message is, for example, a bit string using random numbers.
[0032] The prover 302 responds by attaching a signature to the nonce and the claim (the prover property, etc.) using a private key corresponding to the key identifier (S303, S304).
[0033] The verifier 301 verifies the signature with the public key (S305).
[0034] In the challenge-response attestation in the first embodiment, communication is realized in an interface by a secure path by an MMIO using the CMB / PMR function. Therefore, in the first embodiment, at the stage where a secure path is established, an MMIO in which the verifier 301 writes data to the internal memory of the prover 302 and the prover 302 reads the data written by the verifier 301 from the internal memory, and an MMIO in which the prover 302 writes data to the internal memory and the verifier 301 reads the data written by the prover 302 from the internal memory of the prover 302 are provided on the interface realized by the CMB / PMR function.
[0035] FIG. 4 is a diagram showing an example of a criterion for determining whether to permit or not permit a read request or a write request to the memory system 102 in the policy management unit 207 of the attestation manager 112 when the request is made.
[0036] In the first embodiment, the memory system 102 that provides the safety verification of the request source requires a secure path for the verification. Therefore, the memory system 102 does not perform the verification if the secure path is not established (presence of secure path: no). As a result, if the secure path is not established (unverified state), only the control request to the data that does not need protection (secure data: no) is permitted.
[0037] When a secure path has been established (secure path presence / absence: yes), control requests to data that does not require protection (secure data: no) are permitted regardless of whether verification has been performed or not. On the other hand, control requests to data that requires protection (secure data: yes) are not permitted until verification has been completed.
[0038] FIG. 5 is a diagram showing an example of a processing flow of the policy management unit 207 of the attestation manager 112 to determine whether to permit or not permit a read request or a write request to the memory system 102 when the request is made.
[0039] When the memory system 102 receives an operation request (S501), it determines whether the operation is for information that needs to be protected (S502). If the operation is not for information that needs to be protected (S502: No), the memory system 102 permits the requested operation (S506).
[0040] If the operation is for information that needs to be protected (S502: Yes), the memory system 102 then determines whether a secure path has been established with the requesting device (S503). If a secure path has not been established (S503: No), the memory system 102 rejects the requested operation (S507).
[0041] If a secure path has been established (S503: Yes), the memory system 102 performs verification of the requesting device (S504). The memory system 102 determines whether or not the verification is successful (S505). If the verification is successful (S505: Yes), the memory system 102 permits the requested operation (S506). On the other hand, if the verification is unsuccessful (S505: No), the memory system 102 rejects the requested operation (S507).
[0042] FIG. 6 is a diagram showing an example of a sequence when the services / applications 104, 107 read / write data from / to the memory system 102 in the computer system 1 according to the first embodiment.
[0043] When a service / application 104, 107 generates an operation request by an I / O transaction (S601), the attestation manager 112 of the memory system 102 determines whether the target of the operation request requires verification of the request source (S602). The operation request includes, for example, a request to read or write data to the memory system 102.
[0044] If verification of the request source is required, the attestation manager 112 prepares a challenge message for a challenge-response type attestation by a memory transaction as a pre-verification process (S603). The attestation manager 112 notifies a refusal of the operation request by the previous I / O transaction by using an error code indicating that verification is required (S604).
[0045] The services / applications 104 and 107 and the memory transaction manager 111 of the memory system 102 complete the verification (S605) using the challenge-response type attestation by the memory transaction shown in Fig. 3 on the secure path shown in Fig. 1. After the verification, the services / applications 104 and 107 again make an operation request by an I / O transaction (S606). The memory system 102 completes the operation on the target of the operation request and notifies the services / applications 104 and 107 of the completion of the processing (S607).
[0046] As described above, in the computer system 1 of the first embodiment, the memory system 102 can actively verify the security of the service / application 104 of the host device 100 or the service / application 107 of the application processing device 101 that makes a request to the memory system 102, through challenge-response type attestation.
[0047] More specifically, the computer system 1 of the first embodiment utilizes an interface corresponding to memory transactions as a secure path, thereby enabling challenge-response type attestation, which requires active operation, to be performed in the memory system 102, which is a passive device.
[0048] Furthermore, by enabling the memory system 102 to verify the source of the request and determine whether or not to accept the operation request, the computer system 1 of the first embodiment realizes alleviating the problems of eavesdropping and unauthorized use of information for which information leakage poses a serious threat when the information is moved outside the memory system 102.
[0049] Second embodiment Next, a second embodiment will be described.
[0050] FIG. 7 is a diagram showing an example of the configuration of a computer system 1-2 according to the second embodiment.
[0051] In the second embodiment, the memory system 102 is an NVMe TM The memory system 102 is an SSD, and the bus that connects the memory system 102 and the host devices 701 and 702 in a multi-host configuration is a PCIe TM Here is an example:
[0052] PCIe TM In the standard, each device is connected one-to-one (peer-to-peer). Therefore, a switch device is required to increase the number of connected devices. In a multi-host configuration, the connection between each of the multiple host devices 701, 702 and the memory system 102 is realized by using a switch device 703 with NTB (Non Transparent Bridge) function. TM In the case of the standard, in a multi-host configuration, configuration transactions and message transactions for accessing each device cannot pass through the NTB, so the host device 702 cannot initialize or monitor the status of the memory system 102.
[0053] The computer system 1-2 of the second embodiment employs memory transactions as transactions for verification that are expected to be actively controlled, which enables verification to be performed for multiple host devices without being restricted by the multi-host configuration.
[0054] In the computer system 1-2 of the second embodiment, the secure path realizes communication through an MMIO interface. This makes it possible to use the secure path for status monitoring requests from the host device 702 to the memory system 102 that pass through the NTB.
[0055] Third embodiment Next, a third embodiment will be described.
[0056] FIG. 8 is a diagram showing another example of the criteria for determining whether to permit or not permit a read request or a write request to the memory system 102 in the policy management unit 207 of the attestation manager 112 in the third embodiment.
[0057] As shown in Figure 8, the policy management unit 207 of the attestation manager 112 may use criteria to determine whether to allow or disallow a read or write request to the memory system 102 when such a request is made, such that even for control requests to data that does not require protection, writing may be prohibited when the source of the request has not been verified.
[0058] By implementing an operation that does not permit writing without verifying the request source, it is possible to reduce the threat of unauthorized acquisition of information using a buffer overflow, which is assumed to be a result of information leakage due to unauthorized operations in the memory system 102. More specifically, since unauthorized acquisition of information using a buffer overflow begins with a write request to the memory system 102, the threat can be reduced even when there is an implementation problem regarding writing to the memory system 102.
[0059] (Fourth embodiment) Next, a fourth embodiment will be described.
[0060] 6 described in the first embodiment may be executed periodically, not starting from an I / O transaction. In this case, the host device 100 must constantly monitor the interface for validation established on the secure path, and execute validation by challenge-response type attestation when it detects a validation request from the memory system 102. On the other hand, the attestation manager 112 of the memory system 102 does not need to notify that the request has been rejected due to validation failure, in response to a request from an I / O transaction by the service / application 104, 107.
[0061] In the fourth embodiment, it is not necessary to be aware of verification from the memory system 102 for the services / applications 104, 107 operating in the host device 100. According to the fourth embodiment, it is possible to verify without taking any action whether or not software has been infringed, independently of operation requests from the services / applications 104, 107, etc.
[0062] Although some embodiments of the present invention have been described, these embodiments are presented as examples and are not intended to limit the scope of the invention. These novel embodiments can be implemented in various other forms, and various omissions, substitutions, and modifications can be made without departing from the spirit of the invention. These embodiments and their modifications are included in the scope and spirit of the invention, and are included in the scope of the invention and its equivalents described in the claims. [Explanation of symbols]
[0063] 1...computer system, 100,701,702...host device, 101...application processing device, 102...memory system, 103...bus, 104,107...service / application, 105,108...isolated execution environment, 106,109...application / driver, 110...media control unit, 111...memory transaction manager, 112...attestation manager, 113...volatile memory, 114...non-volatile memory, 201...NVMe host interface, 202...flash translation layer (FTL), 203...flash interface layer, 205...secure communication unit, 206...authentication processing unit, 207...policy management unit, 301...verifier, 302...prover, 703...switch device.
Claims
1. A non-volatile memory; a controller that verifies the security of a request source that requests writing data to the non-volatile memory or reading data from the non-volatile memory by a challenge-response type attestation; Equipped with Memory system.
2. 2. The memory system according to claim 1, wherein the controller verifies the safety of the request source based on a standard I / O transaction from the request source.
3. 2. The memory system of claim 1, wherein the controller determines whether to reject a request from the requester based on at least one of the following: whether the request from the requester is data that needs to be protected, whether a secure path has been established between the requester and the requester, and whether the security of the requester has been verified.
4. 4. The memory system according to claim 3, wherein when the controller determines that the request from the request source should be rejected, the controller notifies the request source of the rejection of the request.
5. The controller: NVM Express TM (NVMe TM ) communicating with said requestor in a protocol conforming to the standard; Between the requester, the NVMe TM A secure path is constructed using MMIO (Memory Mapped I / O) that utilizes the CMB (Controller Memory Buffer) / PMR (Persistent Memory Region) functions supported by the standard.
2. The memory system of claim 1.
6. A method for verifying security of a request source that requests a process to a memory system having a non-volatile memory, comprising the steps of: verifying the security of the request source requesting to write data to the non-volatile memory or to read data from the non-volatile memory by a challenge-response type attestation; Verification method.
Citation Information
Patent Citations
Block copy for color graphic arts
JP1989084255A