KR20190106544A - Data availability ssd architecture for providing user data protection - Google Patents

Abstract

For providing data availability, which preserves user data from malicious attack, a solid state drive (SSD) device may be operated as an independent block storage device in which a security function is separated from a host system, and the SSD device may include a data versioning process storing data with a plurality of versions for the user data and not interrupted by operating system (OS).

Description

DATA AVAILABILITY SSD ARCHITECTURE FOR PROVIDING USER DATA PROTECTION}

The description below relates to a solid state drive (SSD) architecture for user availability.

Providing confidentiality and integrity of data to storage has been studied, and related technologies are disclosed in the following paper.

[1] Trusted Computing Group. TCG Storage Security Subsystem Class: Opal, 2015. Ver. 2.01, Rev. 1.0.

[2] Intel. Intel Solid-State Drive Pro 2500 Series: Opal Compatibility Guide, August 2014.Ver 1.0.

Recently, a new type of security problem for ransomware has emerged. Ransomware infiltrates the target system and encrypts the user data on the storage, making the stored data unusable without the secret key. Previous support for data confidentiality and integrity of storage does not protect user data from new types of attacks on data availability.

We propose an SSD to protect the availability of user data against ransomware attacks.

Unlike previous studies that proposed a software-based approach to protecting user data availability, we propose a new hardware-based solution for implementing protection mechanisms on storage devices.

We propose SSDs that can maintain user data availability even when the operating system is corrupted.

In solid state drive (SSD) devices, the security function operates as an independent block storage device separate from the host system to provide data availability that preserves user data from malicious attacks, and the user data. The present invention provides an SSD device including a data versioning process for storing a plurality of versions of data and not interrupted by an operating system (OS).

According to one aspect, the SSD device is assigned a unique private and public key pair to the SSD in communication with the outside using the network interface of the host system to support secure communication with the outside and the notification including the result of the integrity check of the SSD It can contain a root-of-trust that provides externally.

According to another aspect, the SSD device may be embedded with a platform module in which a unique private and public key pair is present in the SSD for SSD authentication.

According to a further aspect, the SSD unit may provide the communication between the SSD and the user through a message relay service provided by the vendor or a remote server SSD of the third-party (3 ^rd party).

According to another aspect, the SSD device may transmit a heartbeat message periodically generated in the SSD to the remote server and detect the presence or absence of a response message to the heartbeat message from the remote server.

According to another aspect, the SSD device may determine that network access is restricted by the operating system in the SSD when the heartbeat message is not transmitted to the remote server and the absence of the response message is detected from the remote server. .

According to another aspect, if it is determined that network access is restricted by the operating system in the SSD, the SSD device may generate a snapshot of the current state.

According to another aspect, the SSD device reads a block of each partition using partition table information included in a block of a disk, and selects a block constituting a given file based on the file system type encoded in the block. You can find it.

According to another aspect, the SSD device may perform reverse lookup with a file name given a block.

According to another aspect, the SSD device may perform data version management using a snap mechanism for a write request.

According to another aspect, the SSD device may take a snapshot of the original data by using a flash translation layer structure and then write a new write to the SSD.

According to another aspect, the SSD device may perform data version management by identifying a request having a false positive possibility for the write request.

According to another aspect, the SSD device may perform data version management by identifying malicious writes among the write requests using an entropy-based detection scheme.

An SSD device comprising: an SSD storing data using a NAND flash chip as storage; And a controller coupled to the SSD, the controller configured to operate the SSD as an independent block storage device having security functions separate from the host system to provide data availability that preserves the data from malicious attacks. An SSD device is provided that includes a data version management process that controls and stores the data in multiple versions and is not interrupted by an operating system.

A method for the control operation of an SSD, wherein the method controls the SSD to operate as an independent block storage device whose security function is separate from the host system to provide data availability that preserves user data from malicious attack. And storing a plurality of versions of data for the user data and performing data version management that is not interrupted by an operating system.

1 is an exemplary diagram for describing an address mapping according to an embodiment of the present invention.
FIG. 2 illustrates an overall schematic diagram including an SSD (DA-SSD) and a host system for data availability according to an embodiment of the present invention.
3 illustrates the overall structure of an SSD (DA-SSD) for data availability according to an embodiment of the present invention.
4 is an exemplary diagram for explaining data version management for protecting user data according to an embodiment of the present invention.
FIG. 5 is a diagram for describing entropy for each file type according to an embodiment of the present invention. FIG.

Hereinafter, exemplary embodiments of the present invention will be described in detail with reference to the accompanying drawings.

The present invention proposes an SSD for data availability (hereinafter referred to as 'DA-SSD') having a new SSD structure independently existing as a trusted domain to provide data availability in a corrupted operating system. DA-SSD has its own root of trust and automatically saves multiple versions of user data to guard against possible ransomware attacks.

The file semantic inference function may be applied to obtain file semantics in the storage device. The present invention proposes an efficient versioning mechanism for protecting user data from ransomware attacks and provides a method for detecting an ongoing ransomware attack.

DA-SSD works with normal block storage to accept operating system requests. However, as independent storage, the data versioning process within the DA-SSD cannot be interrupted by the operating system.

To enable this uninterrupted versioning, DA-SSD has to solve some technical challenges. First, DA-SSD must be able to communicate safely with users even if the operating system is damaged. Second, the DA-SSD must be able to infer the high-level semantics of the file system, even though the SSD as a block device can only observe block-level data traffic transmitted from the operating system. Third, the DA-SSD must be able to efficiently generate data versions. This versioning process should not delay the normal use of the disk. Finally, the capacity overhead should be reduced as much as possible.

To provide a secure communication path for the user, the DA-SSD has a Trusted Platform Module (TPM) with a unique private / public key pair. In addition to the validity of disk devices, the DA-SSD supports TPM support so that the DA-SSD's controller and firmware can be demonstrated in user applications. In addition, DA-SSD can safely notify users of suspicious activity on the data even when an intermediate operating system handles the actual communication with the user.

However, since all data from previous versions must exist in storage, writing multiple versions of data for every write can significantly reduce the effective storage capacity. To reduce this capacity overhead, DA-SSD uses a ransomware detection algorithm to identify suspicious activity on disk. The DA-SSD can be configured to generate all previous versions of data until the disk is full for certain critical use cases, but in the present invention there is a possibility of false positives to reduce capacity overhead in normal use. Use detection mechanisms.

The main contents of the present invention are as follows.

The present invention proposes a new SSD design that provides remote attestation and authenticated notification using a trusted platform module (TPM) when the operating system is not secure.

To overcome the limitations of block devices without file system semantics, DA-SSD uses reverse engineering to reconstruct file system structures into SSDs.

The present invention provides an efficient version control mechanism utilizing the flash translation layer (FTL) structure of the SSD.

To reduce capacity overhead, DA-SSD uses entropy-based malware detection for operating systems. The present invention shows that entropy-based malware detection can be applied within block storage.

First, the security of storage and SSD architectures will be discussed first.

Data is an important part of computing, and data security requires three essential security attributes: confidentiality, integrity, and availability.

Data Security for Storage

Confidentiality aims to prevent attackers from reading user data, which is supported by encryption. Software and hardware technologies exist that encrypt user data. Software solutions include full disk encryption and individual file encryption. Hardware solutions are provided with full disk encryption, such as the Opal storage specification, and commercial SSDs implement the requirements of the Opal storage specification.

Integrity aims to notify you whenever user data is modified without your intention. Providing integrity is a difficult task because it is difficult to detect unintended user data modifications. The program you run can modify any file you own. If a malicious program runs under a user ID, the file can be modified. To prevent this attack, whitelisting applications that are allowed to modify the data provide software protection, and non-whitelisting applications are detected and unable to modify the file.

Finally, availability aims to provide users with access to data without disrupting service. Unfortunately, if the threat model includes a corrupted operating system, it is difficult to provide data availability, if not impossible. A broken operating system is a very common assumption, so providing availability is difficult.

Recently ransomware attacks have increased significantly, and ransomware generally requires money before encrypting and decrypting user data, or other types of attacks that leak user data. Ransomware attacks emphasize the need for data protection through confidentiality, integrity and data availability protection.

Many studies exist to protect user data. Traditional antivirus adds known ransomware patterns to protect against known threats, and some adds behavior-based detection mechanisms. Furthermore, antivirus companies are introducing ransomware protection solutions by tightly controlling access to files in custom directories.

Relatedly, there are also attempts to access malware detection at the lower part of the system. By examining patterns in file operations such as open, create, and delete, you can successfully detect known or unknown ransomware.

However, all of these approaches rely on operating systems to work properly. A compromised operating system can simply stop the malware detecting the process or bypass the access control set by the ransomware proof solution. There are vulnerabilities that authorize attackers, who can take steps to invalidate detection and protection software.

Therefore, there is a need for a means of protecting user data from all attacks on user space and authorized software.

SSD

SSDs are great devices for detecting and taking safety measures against ransomware. SSDs use NAND flash chips as storage to store data. SSDs are used to replace or be used with existing hard disk drives, and the Flash Translation Layer (FTL) is used to provide the necessary compatibility between SSDs and traditional HDDs. NAND flash has the ability to 'write' a page, but once written, it must be erased before it can be rewritten. The delete process is in blocks and is much larger than the write units of a page. These features of NAND flash require the writing of existing data on the SSD, the writing of new areas, and the collection of data to be deleted later. In addition, NAND storage has a limited number of writes and write-leveling is integrated to equalize the writes evenly. All of these features require address remapping.

SSDs require indirection through the address mapping table to map logical addresses to physical NAND addresses. 1 is an exemplary diagram for describing an address remapping. Since the host does not know the physical layout of the SSD, every address sent from the host to the SSD is a logical address. The SSD internal mapping table is looked up to convert logical addresses into physical addresses (1). If a physical address is found, the actual physical NAND page is accessed (2).

When a write is performed, the data is not actually written physically, but is written to another physical page, and the mapping table is updated to show the new data. As the mapped table is updated, all subsequent accesses to the written data follow steps ① and ② and terminate with the new data. Pages with previous data are marked invalid and are later collected in garbage.

To enable mapping, garbage collection, and wear leveling, SSDs have controllers to handle these tasks. The controller has computational capabilities, and SSD manufacturers have recently suggested using SSDs to process data with some additional hardware logic.

Address remapping and calculations required for SSDs can be used to enhance data availability. Accordingly, the present invention proposes a SSD for data availability, a DA-SSD, which is a new type of storage that plays a role of being a reliable root even when the entire software is damaged and plays an active role in protecting user data.

The following describes the design goals and challenges of SSD to define data availability and support data availability.

Data availability

Data availability is a new security requirement that is a subfield of availability for storage systems and aims to preserve data even in the event of ransomware attacks.

The definitions in the present invention for data availability are as follows: Data is preserved and can be accessed when the system is in a safe state, ie in a clean room environment or when recovered from malicious attacks such as malicious code. The general availability of storage systems requires storage to be always accessible while providing the exact data requested. Unlike general availability, data availability limits the data retention range of storage that can be recovered when connected to a clean system.

Many solutions have recently been proposed to support data availability. The Continuous Data Protection (CDP) solution automatically creates a backup copy of changes made to the system, which allows the system administrator to restore data to previous versions of the data. However, CDP solutions can be hindered by malicious administrators or compromised operating systems. Administrators can disable such software-based protection mechanisms, and the operating system kernel may not make backup copies, making user data insecure.

Design goals

The present invention proposes an SSD (DA-SSD) for data availability in order to provide data availability even in a weak operating system. DA-SSD uses SSD's processing function to keep stored data safe. There is a study using processing devices in SSDs to calculate data present in SSDs in the form of Near Data Processing (NDP). The present invention proposes a method of providing an additional layer of security for data stored in an SSD by using a calculation function instead of using calculations possible for data processing.

DA-SSD protects the data availability of user data in the presence of ransomware. DA-SSD detects potential ransomware such as disk writes and takes protective measures to protect data availability. User data is safely backed up / versioned and the user is safely notified of the suspicious activity and asked to determine whether the suspicious activity is malicious or benign. In the malicious case, the backup / versioned data is used to roll back to the correct state. The DA-SSD may require user action to determine whether the alert is caused by actual malicious activity after the alert is issued.

An important goal of DA-SSD is to provide data availability protection even if the operating system crashes. To enable this autonomous data protection, DA-SSD's data protection functions run only within SSD boundaries and cannot be interrupted by malicious operating systems.

2 shows an overall schematic diagram of a DA-SSD and a host system.

As shown in FIG. 2, the DA-SSD is a peripheral device of the system and is connected to the host system through a PCIe or SATA bus. The DA-SSD consists of a NAND flash chip, an SSD controller, and a DRAM that the controller uses to run tasks and improve SSD performance.

Since confidentiality and integrity support can be achieved by adopting existing methods, the present invention focuses on support for data availability. For example, the storage can manually store encrypted files with a message authentication code (MAC) generated by a user application. Modern hardware-based Trusted Execution Environments (TEEs) can provide isolated execution for user applications that cannot be compromised by authorized software. User-level application or library file systems can encrypt files in the TEE and store them in storage. However, the conventional approach does not provide any mechanism by which the data is actually written to storage or stored data is not modified by the operating system.

Threat Model

The present invention assumes a threat model in which the entire software stack can be compromised. Operating systems and applications are vulnerable to all types of software attacks, such as remote code execution and privilege escalation attacks. Both operating systems and applications can be the source of attacks on user data. In FIG. 2, an area belonging to the host system is not reliable.

In the present invention, it is assumed that the DA-SSD and the host are initially set before the ransomware attack is started, and the state of the user data is correct. Once the DA-SSD and host are configured and the correct user data is stored on the DA-SSD, the DA-SSD can protect against any data modification attacks from the compromised host.

The present invention does not provide protection against general availability attacks other than data availability. The operating system can block the DA-SSD and prevent DA-SSD reads and writes from causing denial of service and availability attacks. Ensure data availability when the system returns to a safe state. Although we do not assume direct physical attacks on SSDs, we can protect them from physical attacks through proper packaging support for SSD devices used in secure computing devices.

SSD makers assume that they provide authentication services for each SSD, similar to the Direct Anonymous Attestation (DAA) approach supported by Intel SGX. For security notifications to users' mobile devices, vendors also provide users with remote message relay services.

DA- SSD

Figure 3 shows the overall structure of the DA-SSD.

As shown in Fig. 3, the DA-SSD still operates as a block storage device to receive a block read / write request from the file system. However, it separates its autonomous security from the rest of the system. There are several challenges in designing and implementing DA-SSDs.

There are five design challenges to be addressed for DA-SSD design.

① DA-SSD must be reliable with root trust in each SSD. Each SSD with a unique private and public key pair must be proved by the user and the SSD manufacturer must verify the authenticity of the SSD.

② DA-SSD must provide a mechanism for transferring commands or messages between the user and SSD. Suspicious activity should be known to the user safely even if the operating system is corrupted. If the user application is running on a hardware TEE, direct communication between the user and the DA-SSD is possible once the communication channel is established.

In the current storage architecture, the DA-SSD is a block device. If there is no high level file system semantics available directly on the SSD, there is a limit to identifying what is sent from the host to the block device. To overcome this limitation, DA-SSDs have to deduce a higher level of meaning using limited information.

④ DA-SSD must manage data version efficiently. If suspicious activity on the data is detected, the DA-SSD must save an undamaged version of the data to be recovered later without incurring significant performance overhead.

⑤ DA-SSD must provide mechanism to detect ransomware attack on user data. The detection mechanism should trigger data versioning to alert the user to suspicious activity and reduce false alarms as much as possible.

Hereinafter, solutions for the five design challenges of DA-SSD will be described.

DA- with root of trust SSD

To support data availability, DA-SSDs must be able to communicate securely with users under compromised operating systems. In addition, the user should be able to determine whether the current SSD is a genuine DA-SSD from a trusted manufacturer that supports the data availability feature (indicated by ① in FIG. 3). To provide this proof and secure communication between the SSD and the user, each DA-SSD can be assigned a private and public key pair to establish a root-of-trust for data availability on each SSD.

To embed the root of trust, DA-SSD adopts the mechanisms used in recent trusted computing technologies. Existing Trusted Platform Modules (TPMs) can be built into DA-SSDs, and SSD manufacturers provide certification services for DA-SSDs to verify that TPMs are used in genuine SSDs. In addition, remote authentication is required to inform the requester that the DA-SSD has not been altered to allow the user to verify that the DA-SSD is operating correctly, and the running software is the intended binary. DA-SSD controllers with a TPM verify the integrity of the BIOS and controller binaries and communicate with remote requesters.

Create a hardware root of trust in the DA-SSD by implementing a root of trust in the DA-SSD. The DA-SSD can use the private / public key assigned to each SSD to support secure communication with the user, and can check the integrity of the SSD itself and provide a notification including the check result. This secure communication channel to the user is essential for notifying the user of suspicious activity or confirming data writes from the user.

DA- With SSD  Secure communication

The DA-SSD requires communication capabilities for two reasons: first, remote authentication is required to trust the DA-SSD, and second, the DA-SSD sends appropriate notifications and alerts to the user and potential Block dangerous activities and communicate with users to resolve situations that require orders from users and require their decisions. The secure communication function is indicated by ② in FIG. 3. Because individual users to communicate directly with the DA-SSD supplier, or a third party (3 ^rd party) gives a message relay service to each user. The user remotely authenticates the DA-SSD and receives notifications through a trusted remote server. The remote maintains the point of contact of the DA-SSD and sends a relay message to the user using the contact information. The user can use various media to receive alerts and send commands. You can use a cell phone or web service with the app installed.

The communication function of DA-SSD requires the support of an operating system driver. The DA-SSD driver will run in the operating system to send and receive data to and from the DA-SSD and relay it to a reliable remote location through the NIC. The DA-SSD will generate a periodic heartbeat message to the remote, and the driver will send a heartbeat message periodically. If there are other alerts generated by the DA-SSD or there is an incoming request for operation, the driver relays the message as appropriate, whether it is a proof request or a user command sent from a remote location.

The communication function needs to withstand attacks by a corrupted operating system. This is because the threat model of the present invention includes a compromised system. To address the confidentiality and integrity issues of incoming and outgoing messages, the DA-SSD's TPM encrypts and adds integrity checks to the messages. Any message leaving a trusted remote or DA-SSD cannot be forged by an attacker, so changes in the message can be detected at the receiving end.

Availability is a more difficult task. If the operating system is corrupted, the operating system may choose to refuse to send or receive messages generated or bound to the DA-SSD. In this case, the DA-SSD and the remote server cannot communicate. The remote informs the user that periodic heartbeats will be rejected and will alert the user through the user specified medium. The user must verify that the system is functioning correctly, or take the necessary steps to restore the system to its correct state. To distinguish between a successful shutdown of the host system and a loss of communication, the driver sends power-on and power-off messages to the remote server. If the heartbeat is missing after the power off message, the heartbeat is not natural and the user is not alerted.

Finally, if the DA-SSD detects that a message is not sent remotely and there is no ack message remotely, the DA-SSD may determine that the network is currently restricted by the operating system (Denial of Service (DoS)). If it is determined that network access is restricted, a snapshot of the current state is created and the function is maintained normally.

The DA-SSD communicates with the outside (users and trusted remote servers) using the network interface card of the host system. The DA-SSD operating system driver is responsible for message relay with the DA-SSD. A compromised operating system can attack operating system drivers, but the present invention introduces a mechanism to protect the system from such attacks.

Trust establishment between secure user TEE and DA-SSD: If a trusted user execution environment (TEE) such as Intel SGX is supported, trusted user execution can communicate directly with the DA-SSD. The term Intel SGX is used to refer to the secure execution environment simply as an enclave. When setting up an enclave using a DA-SSD, the user space enclave and the DA-SSD must establish trust to ensure that they are actually communicating with each other. This step attempts to prevent the possibility of an OS-in-the-middle attack. The establishment of trust between the enclave and the DA-SSD is done through the same trusted remote server that the user uses for DA-SSD secure communication.

This communication channel is used to exchange keys as a means of security verification and communication with the DA-SSD. enclave establishes a secure channel using the remote server's pre-installed public key. First, a remote attestation request is executed, and the enclave confirms the attestation request using the remote public key. After the Enclave verifies whether the DA-SSD is operating correctly based on the remotely relayed message, it exchanges the key with the DA-SSD. The enclave's public key and the DA-SSD are exchanged through a trusted remote. When the key is exchanged, the enclave and DA-SSD are established and ready to communicate over a secure channel.

Derivation of file information with block level information

DA-SSD relies on semantic inference of files based on data stored in DA-SSD. Hereinafter, a reverse lookup for obtaining a file name when a specified logical block number exists as used in 3 of FIG.

SSDs are block devices, and block devices have a limited view of the semantics of file systems and file I / O requests. An SSD can only see blocks that are sent from or coming into an SSD. DA-SSD does not have access to file system level semantics such as read / write to file at offset.

However, since it is possible for DA-SSD to analyze the file system and obtain the necessary information, the actual data resides on the SSD. The superblock on the disk contains partition table information and uses the master boot record (MBR) or GUID partition table (GPT) format. The DA-SSD can read the superblock of each partition using the information of the disk superblock. The DA-SSD may find a file system inode for acquiring a file in a block relation based on the file system type encoded in the partition superblock. Thus, given a file, the user knows the blocks that make up the file.

Additional engineering also allows DA-SSD to perform reverse lookups, which can look up the owner file in reverse order or enumerate the block list by specifying the file name. If the host system sends a DA-SSD I / O request on a block basis, the reverse lookup indicates the file being written. This information can be used by the DA-SSD to inform the user that a particular file has been updated and can ask the user to verify that the file is not corrupted. This is indicated by a dashed arrow in FIG. 3. This information can also allow the user to be aware of updates that the user is not aware of, which can be an attack on user data.

For this function, the DA-SSD needs to know the file system configuration. For example, we used NTFS and ext4 file systems, but we can extend DA-SSD to recognize more file systems. Since the structure of the file system is rarely changed to prevent compatibility issues, DA-SSDs can be loaded into a variety of widely used file systems. If you need to change a specific file system or add a new file system, you can update the DA-SSD software to recognize the change.

In addition, for efficient reverse lookup, the DA-SSD may need to maintain a separate reverse mapping tree. Maintaining a reverse tree on a block basis creates a very large tree. Recently, file systems have begun to use large continuous disks to store data in files to improve sequential disk access performance. In the Ext4 file system, blocks are composed of 'extents'. A data structure such as an interval tree can be used for the reverse mapping tree. In addition, DA-SSD can monitor modifications to super blocks and inode blocks. Each time a modification is made, the DA-SSD updates the change with an internally maintained data structure.

DA-SSD is a block device, DA-SSD as a block device can see the semantics of the file system limited. However, since the DA-SSD is the actual data store that holds the data, the DA-SSD can be extended to analyze the data stored in the DA-SSD. Since the data is structured based on the existing system, DA-SSD can understand the file system with the data stored internally.

Data protection following an attack

The DA-SSD must provide a mechanism for protecting user data during the attack as in ④ of FIG. 3. Attacks on data can be defended by creating a data version or by taking a snapshot of the data in time at a given point. In this specification, the terms versioning and snapshot are used interchangeably. The action taken depends on the reliability of the attack detection mechanism. Let's look at some other situations, and finally discuss a versioning-based approach to protecting user data.

The first is to periodically version the data stored in the storage. Regular versioning creates snapshots at given intervals, and more frequent snapshots provide higher safety at snapshot storage capacity overhead. If storage starts when there is insufficient capacity, the old snapshot is discarded to make room for new snapshots and incoming disk writes. This method relies on the user identifying any ransomized data and restoring previous versions of the data. However, if a user tries to access a file after a long time since it was encrypted, the version holding the file may be discarded before it is encrypted. Another way is to stop the disk and ask the user to confirm that they want to discard the previous version. This requires the user to look at all the updated files and screen for exceptions, which can be too much of a burden on the user due to the huge amount of files to check.

If you have a detection mechanism that can identify potential threats to your data, you can improve data protection. Next, we introduce a detection mechanism.

Second, if the attack detection mechanism generates a false positive, the DA-SSD does not have sufficient knowledge and does not judge a suspicious event as malicious or benign, as will be described below. Therefore, DA-SSD must protect user data from all possible attacks and at the same time request the user to make a decision. The user is notified of a file modified with suspicious write entropy, asked to check the file, and determine the write. Therefore, data protection for the DA-SSD is required for a time when the user is requested to make a decision.

If the user decides that the write is malicious, the DA-SSD will refuse to write and the user should take action to restore the compromised system to a safe state. The user also has the option to read data from the DA-SSD in read-only mode while the system is compromised. After fixing the problem, if the user informs the DA-SSD of the system's safety status, the DA-SSD will operate normally.

Third, if the detection mechanism requires many samples, the DA-SSD needs to keep the data safe while the detector collects the sample. In this case, data protection provided by the DA-SSD is essential.

Finally, if the detection mechanism is certain that data is under attack, DA-SSD can stop all write requests from being written to NAND storage. The DA-SSD can also choose to send an I / O error to the host system and send a warning message to the user via the out-of-band communication described above. In this case, DA-SSD protects user data by rejecting write requests classified as malicious.

The four situations in which the DA-SSD's data protection feature is used are described above. Overall, data protection is essential to protect data from ransomware. DA-SSD requires two protection functions. The first is to refuse write requests to be written to NAND storage. This is easy because the I / O storage device interface has the ability to notify the host system of I / O errors. The second is to protect the data while allowing potentially dangerous data updates. The present invention proposes a method of taking a snapshot of original data using a snapshot and recovery-based protection method and then recording a new write later on the DA-SSD.

Data protection using snapshots: SSDs already come with page remapping to provide compatibility with existing page devices. SSDs cannot write to existing pages due to the erase-before-write constraints of NAND flash. So whenever data is updated in place, the data is actually written to another blank page, and the mapping table updates the page's position with the newly created position. The previous data is then marked invalid and later corrected and erased by the garbage collection operation.

Write operations, also called relocate-on-write, can be used to create very simple snapshot mechanisms. The present invention provides version control of data in the DA-SSD using a snapshot mechanism. DA-SSD maintains a global version, a monotonically increasing counter. Each page or block in a DA-SSD that implements the mapping method requires two version numbers: a created version and an expired version. All records for the DA-SSD are annotated with the recorded version of the specific page / block currently being written to the global version. The expired version is empty because the page / block has not yet expired.

The created version indicates the version number on which this page / block is valid. Expired version indicates the version number on which this page / block is invalidated. The lifetime of each block is indicated using the created and expired versions. The present invention uses a 16-bit value to store two version data per process, which requires an additional 4B of storage space per page / per block.

Snapshot creation: Increasing the global version automatically snapshots the current data state, and all future records for the DA-SSD are written with the new version. Due to the SSD's relocate-on-write operation, all update records for an existing page will be written to a new page. However, unlike when creating a regular SSD or within the same version, the old page is not marked as invalid if the version of the newly created page and the previous page are different. This operation is shown in Fig. 4B. Instead, the previous page keeps a version of the page. The previous page is only invalidated if the page is discarded.

An example of the version control mechanism is as follows: 4 shows the state of each page (write unit of SSD) according to another I / O command, and shows changes of pages after various operations. In this case, each of the four pages represents a service set of physical pages of the SSD.

4 (a) shows an initial state, where logical page LBA 2 is located on a physical page in the upper left corner. The other three pages are free pages. The DA-SSD maintains a global version, and all versions are based on this global version. In this example, the global version is four.

Update of other versions: When an update to LBA 2 is requested, the first free page is recorded as shown in FIG. The write was made when the global version was 4, so the version created is 4. However, because the page has not yet expired, the expired version is left blank (zero). The old LBA 2 (top left) expired because it was overwritten and expired in global version 4, so the expired version is marked as 4. There are two pages with physical LBA 2. The DA-SSD actually points to the most recent page of the mapping table, so in this case, it points to the top right page for LBA 2.

Updates of the same version: If another update to LBA 2 is requested from the same global version 4 (FIG. 4C), the update is written to a new free page (bottom left). The top right page is now shaded to indicate that it is invalid. If you create a page with the same version and it expires, the page is invalidated and the garbage collector collects it and deletes it. This is actually the same behavior as writing to a regular SSD.

In Figure 4 (d) another update to LBA 2 is requested, but the global version has been increased to 5. The free page is found (bottom right) and written. Now the page created is 5 and the previously pointing page (bottom left) is marked as expired in version 5.

Revocation Version: Finally, the DA-SSD is ordered to retire all five or more versions (Fig. 4 (e)). In this case, pages created before version 5 and all pages that expired before or before version 5 are invalidated. All versions older than 5 expire because no more than four versions are needed anymore.

TRIM task: Must process TRIM command of SSD. The TRIM command is used to inform the SSD that the corresponding (logical) page address sent with the command in the host file system is no longer used and the garbage collector can correct it.

When a TRIM command is executed (output) on a regular SSD, the corresponding logical page address provided with the command is queried and marked as invalid for garbage to be collected. When versioning is introduced, the page is expired with the current global version without marking the page as invalid. If the created version and the expired version are the same, this operation matches the TRIM behavior of a regular SSD and invalidates the page.

Mapping Table Management: The DA-SSD's mapping table always points to the most recent page of a particular LBA. However, if a data attack is detected, the system must be returned in time or to a specific state of the DA-SSD to restore or access the protected file. In this case, the DA-SSD must reconstruct the mapping table for the particular version. The DA-SSD goes through two tables that hold the created and expired versions of each physical page. In addition, the existing table holding the logical page address of each physical page is also scanned. When reorganizing the mapping table for a specific version or target version, the created and expired versions of the page are retrieved. If the target version is larger than the created version and the expired version is larger than the target version or the page has not yet expired, the logical page address is queried. Finally, the reorganized mapping table is populated with the logical page address as an index and the physical page number as a value. You need to check three tables, but the reorganization is only performed if you need to restore a particular version. This action is rare and can be expensive.

The proposed versioning mechanism is very lightweight because writing is not affected in terms of performance. Two additional writes to the created and expired version tables are required, but these writes do not cause significant delays. This is because the table is cached because writes to the page are spatially localized in terms of physical pages and the table is indexed in terms of physical pages, providing the possibility of frequent hits to the table entries in the controller cache or at least the DRAM of the SSD. Because it is likely to be. Rolling back to a specific version requires some time-consuming reorganization mapping tables. However, version restoration doesn't happen very often, only when an attack occurs. There is no general penalty update, and a slow but infrequent reconstruction is a practical design design choice.

Ransomware  Activity detection

The DA-SSD should be able to identify possible attacks (5 in FIG. 3) on user data. The DA-SSD is a block device and the visibility of the received data block to be written to the DA-SSD is limited. Therefore, the threat detection function for DA-SSD based on the existing technology is used. The purpose of threat detection is to distinguish between normal and malicious activity on block devices.

Recent research uses entropy values to detect malicious writes. Shannon entropy represents the diversity or uncertainty of the bytes that represent a file. Shannon entropy is calculated using equation (1). Use entropy calculations in bytes, where each byte can have a value between 0 and 255. To calculate the page entropy of 4096B, each time a value between 0 and 255 is encountered, p _i is the probability of the value appearing.

[Equation 1]

In general, files use only a subset of byte representations, so the entropy of a typical file should be relatively low. For example, a text file or source code is represented by a subset of characters (ASCII), and alpha numbers are limited to 62 characters out of the 256 available byte values. This property makes file entropy relatively low. On the other hand, encrypted data generates high diversity data resulting in high entropy values.

Blocks of entropy values can be used to detect potentially dangerous disk activity. The entropy value can be used to alert the security system if the block being written has a large entropy value. As shown in Fig. 3, in the present invention, potentially dangerous block writes are triggered (4) and queued to be identified (3).

The present invention proposes a method of using the entropy value of the block being prepared. Unlike the previous method, the entropy calculator and detection mechanism are implemented inside the SSD. The DA-SSD accesses data blocks from the host computer that will be written to the SSD. A simple hardware entropy calculator can be used to quickly detect abnormal records and consume power efficiently.

To study the entropy values of real user files, we calculated the file entropy of documents, source code, media files, and so on. 5 analyzes over 40,000 files and shows the entropy distribution of over 23,000 files. Unlike home, Microsoft Office files ppt (x), doc (x), xls (x), pdf documents, image files (png, jpg, gif), media files (mp3, wma, mp4), compressed files (zip, gz Common types of files, such as), have very high entropy values.

The entropy of an encrypted file has a high entropy value as expected. Encrypt the same file as shown in Figure 5 using AES CBC mode and use the entropy of the encrypted file. You can see that the encrypted file has entropy between 7.48 and 8.0. Where 8 is the maximum value. An interesting feature of encrypted file entropy is that file entropy tends to increase with file size. Low entropy values occur for small files of 512B. Files larger than 1 kB had entropy greater than 7.75 and files greater than 2 kB showed greater than 7.88. Finally, files larger than 4kB appear to have entropy greater than 7.94. This is a natural result because larger files can produce more randomness by encryption. The encrypted file is shown in FIG.

The entropy result of the actual user data shows that there is a problem with the assumption of entropy values. Assume that the entropy value of a normal file is relatively low. Using the entropy value of the actual user file, we can see that this assumption is wrong. Nevertheless, even in the case of the present invention which generates a positive error, a successful data attack does not occur, and more blocks to be queried in reverse order and snapshots are generated more frequently.

Based on the high entropy value of the encrypted file, DA-SSD uses an entropy-based ransomware detector. The DA-SSD uses simple special logic to calculate all the blocks to be written to the DA-SSD, checking the entropy of all the blocks to be written, and triggering an alarm when a suspicious block comes in. As shown in FIG. 5, an entropy value 7.4 may be used as the threshold value. The threshold entropy value that triggers an alert conflicts with a recall that detects a trick block for precision or false positives.

As long as the DA-SSD can handle false positives in a timely manner, lowering the threshold will cause more warnings but higher recall, providing strong defense against ransomware writes. An entropy value of 7.4 can be used as the threshold, but the threshold can be dynamically adjusted according to the device's capabilities and the amount of false positives generated.

The false positives of the detector do not result in data loss. However, it can induce more frequent DA-SSD defense mechanisms, leading to spatial overhead. Some common files with high entropy values are recognized as malicious writes during writes and updates, causing false alarms. However, image, audio, and video files are usually static, not modified by the end user, and should generally not cause many positive errors. In addition, it is determined that the normal user activity does not cause excessively high load on the reverse lookup mechanism and the snapshot mechanism. When a block write is reached at a certain period or when a specific criterion is reached, a user or a supplier may request a version management setting such as deleting or rolling back a version.

In the above description, a threat detection technique based on entropy has been described. However, the present invention is not limited thereto. Threat detection includes a method of comparing before and after writing of the same block of the same file, and a method of detecting a threat by analyzing data values of the block. It is also possible to apply various algorithms used for.

As described above, according to embodiments of the present invention, an SSD (DA-SSD) for data availability may be provided to prevent an increase in attacks on user data, and an address mapping function and a controller logic included in the SSD may be provided. You can use it to detect and protect incoming attacks against user data.

The apparatus described above may be implemented as a hardware component, a software component, and / or a combination of hardware components and software components. For example, the devices and components described in the embodiments may include a processor, a controller, an arithmetic logic unit (ALU), a digital signal processor, a microcomputer, a field programmable gate array (FPGA), a programmable PLU (programmable). It can be implemented using one or more general purpose or special purpose computers, such as logic units, microprocessors, or any other device capable of executing and responding to instructions. The processing device may execute an operating system (OS) and one or more software applications executed on the operating system. The processing device may also access, store, manipulate, process, and generate data in response to the execution of the software. For convenience of explanation, one processing device may be described as being used, but one of ordinary skill in the art will appreciate that the processing device includes a plurality of processing elements and / or a plurality of types of processing elements. It can be seen that it may include. For example, the processing device may include a plurality of processors or one processor and one controller. In addition, other processing configurations are possible, such as parallel processors.

The software may include a computer program, code, instructions, or a combination of one or more of the above, and configure the processing device to operate as desired, or process it independently or collectively. You can command the device. The software and / or data may be embodied in any type of machine, component, physical device, computer storage medium or device in order to be interpreted by or provided to the processing device or to provide instructions or data. have. The software may be distributed over networked computer systems so that they may be stored or executed in a distributed manner. Software and data may be stored on one or more computer readable recording media.

The method according to the embodiment may be embodied in the form of program instructions that can be executed by various computer means and recorded in a computer readable medium. In this case, the medium may be to continuously store a program executable by the computer, or to temporarily store for execution or download. In addition, the medium may be a variety of recording means or storage means in the form of a single or several hardware combined, not limited to a medium directly connected to any computer system, it may be distributed on the network. Examples of the medium include magnetic media such as hard disks, floppy disks and magnetic tape, optical recording media such as CD-ROMs and DVDs, magneto-optical media such as floptical disks, And ROM, RAM, flash memory, and the like, configured to store program instructions. In addition, examples of another medium may include a recording medium or a storage medium managed by an app store that distributes an application, a site that supplies or distributes various software, a server, or the like.

Although the embodiments have been described by the limited embodiments and the drawings as described above, various modifications and variations are possible to those skilled in the art from the above description. For example, the described techniques may be performed in a different order than the described method, and / or components of the described systems, structures, devices, circuits, etc. may be combined or combined in a different form than the described method, or other components. Or even if replaced or substituted by equivalents, an appropriate result can be achieved.

Therefore, other implementations, other embodiments, and equivalents to the claims are within the scope of the claims that follow.

Claims (23)

In a solid state drive device,
To provide data availability that preserves user data from malicious attacks,
The security function operates as an independent block storage device separate from the host system.
Data versioning process that stores a plurality of versions of data for the user data and is not interrupted by an operating system (OS)
SSD device comprising a. The method of claim 1,
When the SSD device communicates with the outside using the network interface of the host system, a unique private and public key pair is allocated to the SSD to support secure communication with the outside and provide a notification including an SSD integrity check result to the outside. Containing root-of-trust
SSD device characterized in that. The method of claim 1,
The SSD device includes a platform module in which unique private and public key pairs exist in the SSD for SSD authentication.
SSD device characterized in that. The method of claim 1,
The SSD device to provide communication between the SSD and the user through a message relay service provided by SSD vendors or third-party remote server (3 ^rd party)
SSD device characterized in that. The method of claim 4, wherein
The SSD device transmits a heartbeat message periodically generated in the SSD to the remote server and detects the presence or absence of a response message to the heartbeat message from the remote server.
SSD device characterized in that. The method of claim 5,
The SSD device determines that network access is restricted by an operating system in the SSD when the heartbeat message is not transmitted to the remote server and the absence of the response message is detected from the remote server.
SSD device characterized in that. The method of claim 6,
The SSD device generates a snapshot of the current state when it is determined that network access is restricted by the operating system in the SSD.
SSD device characterized in that. The method of claim 1,
The SSD device reads a block of each partition using partition table information included in a block of a disk, and finds a block constituting a given file based on the file system type encoded in the block.
SSD device characterized in that. The method of claim 8,
The SSD device performs reverse lookup with a file name given a block.
SSD device characterized in that. The method of claim 1,
The SSD device performs data version control using a snap mechanism for a write request.
SSD device characterized in that. The method of claim 10,
The SSD device uses a flash translation layer structure to take a snapshot of the original data and then write a new write to the SSD.
SSD device characterized in that. The method of claim 10,
The SSD device performs data version management by identifying a request that has a false positive possibility for the write request.
SSD device characterized in that. The method of claim 10,
The SSD device performs data version management by identifying malicious writes among the write requests using an entropy-based detection method.
SSD device characterized in that. In an SSD device,
An SSD storing data using a NAND flash chip as storage; And
A controller coupled to the SSD
Including,
The controller,
To provide data availability that preserves the data from malicious attacks,
A data version management process that controls the SSD to operate as an independent block storage device having security functions separate from the host system, stores the data in multiple versions, and is not interrupted by an operating system.
Including, SSD device. In the method for the control operation of the SSD,
The method,
To provide data availability that preserves user data from malicious attacks,
Controlling the SSD to operate as an independent block storage device having a security function separate from the host system, storing a plurality of versions of data for the user data, and performing data version management not interrupted by an operating system
Including, the method. The method of claim 15,
The step of performing,
In communication with the outside using the network interface of the host system, providing secure communication with the outside using a unique private and public key pair assigned to the SSD and providing a notification including the result of the integrity check of the SSD to the outside.
Including, the method. The method of claim 15,
The step of performing,
Providing communication between SSD and user through message relay service provided by SSD vendor or third party remote server
Including, the method. The method of claim 17,
The step of performing,
Transmitting a heartbeat message periodically generated in the SSD to the remote server and detecting the presence of a response message to the heartbeat message from the remote server;
Determining that network access is restricted by an operating system in the SSD when it is detected that the response message is absent from the remote server; And
If the SSD determines that network access is restricted by the operating system, creating a snapshot of the current state
Including, the method. The method of claim 15,
The step of performing,
Reading the blocks of each partition using partition table information contained in the blocks of the disk and finding the blocks that make up a given file based on the file system type encoded in that block
Including, the method. The method of claim 19,
The step of performing,
Given a block, perform reverse lookup by filename
Including, the method. The method of claim 15,
The step of performing,
Performing Data Version Control Using the Snapshot Mechanism for Write Requests
Including, the method. The method of claim 21,
The step of performing,
Taking a snapshot of the original data using the flash translation layer structure and writing a new write to the SSD
Including, the method. The method of claim 21,
The step of performing,
Performing data version management by identifying malicious writes among the write requests using an entropy-based detection scheme
Including, the method.

Images