Module and method for authenticating data transfer between a storage device and a host device

Abstract

This document describes a module and method for authenticating data transfer between a storage device and a host device. The module is configured to allow encrypted data to be exchanged between the storage device and the host device once the module has verified that the storage device has been correctly paired with an authorized host device whereby the verification step does not require a password to be manually entered or an additional external device to be attached.

Description

[Technical Field]

[0001] This invention relates to a module and method for authenticating data transfer between a storage device and a host device. The module is configured to allow encrypted data to be exchanged between the storage device and the host device once the module has verified that the storage device has been correctly paired with an authorized host device, thereby eliminating the need for manual password input or the attachment of additional external devices. [Previous Technology]

[0002] Storage devices typically include solid-state drives (SSDs), hard disk drives (HDDs), optical drives, or magnetic disk drives. Regardless of whether the storage device includes a simple flash bundle (JBOF), a disk drive, or an SSD, the host device typically needs to specify the logical block address (LBA) and / or physical address block (PAB) to be accessed / modified in the storage device in order to access information related to the LBA.

[0003] To obtain access to the contents stored on a storage device, a malicious third party typically connects the storage device to a host device and attempts to obtain the information stored on the storage device through hacking algorithms or software. Typically, such storage devices are protected at the software level, such as the operating system, using usernames and passwords. This locks a set of data contained on the storage device to a specific user, and only the software administrator has complete access to all the data contained on the storage device.

[0004] However, when the administrator and / or the user enters their password to access the storage device, they are vulnerable to man-in-the-middle attacks, whereby their keystrokes and / or inputs can be recorded and sent to a third party. The malicious third party can then replay the command to gain access to the contents of the storage device.

[0005] Those skilled in the art have proposed an external security device, such as a USB flash drive, to replace the password input method. This external device contains the password (to allow the host device to access the storage device), and is inserted into the host device and / or the storage device each time the storage device is to be accessed. The associated device then automatically retrieves the password from the external device and uses the password contained therein to obtain access to the storage device.

[0006] However, each time the password is exploited, it becomes vulnerable to man-in-the-middle attacks because a malicious actor could monitor data transmissions on a computer bus interface, such as a serial ATA / PCIe bus, and copy the data before it is encrypted within the storage device and / or the host device. The copied password can then be used to gain access to the contents stored in the storage device.

[0007] For the reasons mentioned above, those skilled in this technology have been working to devise a module and method that can authenticate data transfer between a storage device and a host device, without requiring a password to be manually entered and / or without requiring the insertion of an external device each time access to the storage device is needed. [Summary of the Invention]

[0008] The above and other problems are solved by the system and method provided according to embodiments of the present invention, and progress is made in this art.

[0009] A first advantage of an embodiment of the module and method according to the present invention is that the module is not affected by man-in-the-middle attacks because no password needs to be entered each time the storage device is accessed and no external security device needs to be inserted.

[0010] A second advantage of an embodiment of the module and method according to the present invention is that the module can be paired with a storage device and a host device, and once paired, secure communication can only be performed between the storage device and the host device.

[0011] A third advantage of an embodiment of the module and method according to the invention is that, throughout the entire use of the paired device, the module will randomly perform proof of ownership checks to confirm that the storage device is still paired with the appropriate hardware.

[0012] A fourth advantage of embodiments of the module and method according to the invention is that once the storage device has been paired with a host hardware, this unique pairing must be maintained in order to facilitate the exchange of data between the paired devices.

[0013] The above advantages are provided by embodiments of a module and / or method according to the present invention operating in the following manner.

[0014] According to a first feature of the present invention, a module for authenticating data transmission between a storage device and a host device is disclosed, the module comprising a processing unit; and a non-transitory medium readable by the processing unit, the medium being a storage instruction that, when executed by the processing unit, causes the processing unit to: generate a digital signature for the storage device and the host device based on a unique number associated with the storage device and a unique device identity associated with the host device; determine whether the digital signature has been written into a blockchain; when it is determined that the digital signature conforms to a digital signature written into the blockchain, allow encrypted data transmission between the storage device and the host device; or when it is determined that the digital signature does not conform to a digital signature written into the blockchain, prevent data transmission between the storage device and the host device.

[0015] Regarding a first feature of the invention, the instruction for avoiding data transfer between the storage device and the host device further includes an instruction that, when executed by the processing unit, causes the processing unit to: write the digital signature into the blockchain when a paired instruction is received from an authorized application located in the host device; and allow encrypted data transfer between the storage device and the host device when the digital signature has been written into the blockchain.

[0016] Regarding the first feature of the present invention, the module further includes instructions that, when executed by the processing unit, cause the processing unit to: after a random time period has elapsed, generate another digital signature for the storage device and the host device based on the unique number associated with the storage device and the unique device identity associated with the host device; determine whether the other digital signature matches the digital signature already written into the blockchain; when it is determined that the other digital signature matches the digital signature already written into the blockchain, allow encrypted data transmission between the storage device and the host device; or when it is determined that the other digital signature does not match the digital signature already written into the blockchain, prevent data transmission between the storage device and the host device.

[0017] Regarding a first feature of the invention, the instructions for generating the digital signature include instructions for instructing the processing unit to generate the digital signature based on a session key of a good privacy (PGP) hybrid encryption system.

[0018] Regarding a first feature of the invention, the instructions for enabling encrypted data transmission between the storage device and the host device include instructions to instruct the processing unit to: encrypt the PGP session key using public key encryption; store the encrypted PGP session key in a secure location in the storage device and the host device; and encrypt all data exchanged between the storage device and the host device using the PGP session key.

[0019] Regarding a first feature of the invention, the instruction for generating the digital signature includes instructions to instruct the processing unit to: generate a hash message h by hashing a combination of a unique number associated with the storage device and a unique device identity associated with the host device; to convert the hash message h into a BLS signature σ using a Boneh-Lynn-Shacham (BLS) signature scheme; and to use the BLS signature σ as the digital signature.

[0020] Regarding a first feature of the invention, the module further includes instructions that, when executed by the processing unit, cause the processing unit to: receive a restricted logical block address (LBA) from an authorized application disposed in the host device; intercept instructions from the host device to access the restricted LBA; and, when the instructions have been verified by the module, allow the intercepted instructions to access the restricted LBA, wherein the instructions are signed by the authorized application using a public key of the storage device and verified by the module using a private key of the storage device.

[0021] A first feature of the present invention is that the unique number associated with the storage device is set within a secure encryption processor in the storage device.

[0022] Regarding a first feature of the present invention, the blockchain is a private, decentralized database system comprising a host device.

[0023] According to a second feature of the present invention, a method for authenticating data transmission between a storage device and a host device includes the following steps: using a module to generate a digital signature for the storage device and the host device based on a unique number associated with the storage device and a unique device identity associated with the host device; using the module to determine whether the digital signature has been written into a blockchain; when it is determined that the digital signature conforms to a digital signature written into the blockchain, using the module to allow encrypted data transmission between the storage device and the host device; or when it is determined that the digital signature does not conform to a digital signature written into the blockchain, using the module to prevent data transmission between the storage device and the host device.

[0024] Regarding a second feature of the invention, the step of preventing data transmission between the storage device and the host device further includes the following steps: when a pairing instruction is received from an authorized application located in the host device, using the module to write the digital signature into the blockchain; and when the digital signature has been written into the blockchain, using the module to allow encrypted data transmission between the storage device and the host device.

[0025] Regarding a second feature of the present invention, the method further includes the following steps: after a random time period has elapsed, using the module to generate another digital signature for the storage device and the host device based on the unique number associated with the storage device and the unique device identity associated with the host device; using the module to determine whether the other digital signature matches the digital signature already written into the blockchain; when it is determined that the other digital signature matches the digital signature already written into the blockchain, using the module to allow encrypted data transmission between the storage device and the host device; or when it is determined that the other digital signature does not match the digital signature already written into the blockchain, using the module to prevent data transmission between the storage device and the host device.

[0026] Regarding a second feature of the invention, the step of generating the digital signature includes generating the digital signature based on a session key of a good privacy (PGP) hybrid encryption system.

[0027] A second feature of the invention allows encrypted data transmission between the storage device and the host device by comprising the following steps: encrypting the PGP session key using the module and using a public key; storing the encrypted PGP session key in a secure location on the storage device and the host device using the module; and encrypting all data exchanged between the storage device and the host device using the PGP session key using the module.

[0028] Regarding a second feature of the present invention, the step of generating the digital signature includes the following steps: using the module to hash a combination of the unique number associated with the storage device and the unique device identity associated with the host device to generate a hash message h; using the module and a Boneh-Lynn-Shacham (BLS) signature scheme to convert the hash message h into a BLS signature σ; and using the BLS signature σ as the digital signature.

[0029] Regarding a second feature of the invention, the method further includes the steps of: using the module to receive a restricted logical block address (LBA) from an authorized application disposed in the host device; using the module to intercept instructions from the host device to access the restricted LBA; and using the module to allow the intercepted instructions to access the restricted LBA when the instructions have been verified by the module, wherein the instructions are signed by the authorized application using a public key of the storage device and verified by the module using a private key of the storage device.

[0030] A second feature of the invention is that the unique number associated with the storage device is set within a secure encryption processor in the storage device.

[0031] A second feature of the invention is that the blockchain includes a private, decentralized database system located within the host device.

Implementation Method

[0033] This invention relates to a module and method for authenticating data transfer between a storage device and a host device. The module is configured to allow encrypted data to be exchanged between the storage device and the host device once the module has verified that the storage device has been correctly paired with an authorized host device. Therefore, the verification step does not require manual input of a password or attachment of an additional external device. If the module determines that the storage device and the host device are to be paired for the first time, the module generates a digital signature based on the unique identifiers of the storage device and the host device. This digital signature is then stored on a blockchain, making it impossible to modify or alter.

[0034] The present invention will now be described in detail with reference to several embodiments thereof, as illustrated in the accompanying drawings. In the following description, many specific features are set forth to provide a thorough understanding of the embodiments of the invention. However, it will be apparent to those skilled in the art that embodiments may be implemented without some or all of these specific features. Such embodiments should also fall within the scope of the invention. Furthermore, some procedural steps and / or structures may not be described in detail below, and therefore the reader will be reminded of corresponding references to avoid unnecessarily obscuring the invention.

[0035] Furthermore, those skilled in the art will recognize that many functional units described herein have been designated as modules throughout the specification. Those skilled in the art will also recognize that a module can be implemented as a circuit, a logic chip, or any kind of discrete component. Moreover, those skilled in the art will also recognize that a module can be implemented in software, which can then be executed using various processor architectures. In embodiments of the invention, a module may also include computer instructions, firmware, or executable code that instruct a computer processor to perform a sequence of events according to received instructions. The choice of implementation method for the module is left to those skilled in the art for design choices and therefore does not limit the scope of the invention in any way.

[0036] An example of a procedure or method for authenticating data transmission between a storage device and a host device according to an embodiment of the present invention is stated in the following steps. The steps of the procedure or method, implemented as if by a module disposed on the storage device and / or the host device, are as follows: Step 1: Generate a digital signature for the storage device and the host device based on a serial number associated with the storage device and a unique device identity associated with the host device; Step 2: Determine whether the digital signature has been written into a blockchain; Step 3: When it is determined that the digital signature conforms to a digital signature written into the blockchain, allow encrypted data transmission between the storage device and the host device; and Step 4: When it is determined that the digital signature does not conform to a digital signature written into the blockchain, prevent data transmission between the storage device and the host device.

[0037] According to an embodiment of the present invention, the steps described above can be implemented or performed by a module disposed in the host device and / or the storage device.

[0038] A block diagram of a system for authenticating data transfer between a storage device and a host device according to an embodiment of the present invention is depicted in FIG1. ​​FIG1 depicts a storage device 101, host devices 152 and 154, a server rack 156, and a network attached storage (NaS) 158, wherein the host devices 152 and 154, the server rack 156, and the NaS 158 are communicatively connected to a blockchain 170 via wired and / or wireless means. Although FIG1 only depicts a host device, a server rack, and a NAS, those skilled in the art will recognize that any other type of computing device / system can be used without departing from the present invention, provided that the computing device can support an operating system.

[0039] As illustrated in FIG. 1, connector 140 is depicted as being intermediate between storage device 101 and host devices 152 and 154, server rack 156 and NaS 158, so that all communication exchanged with storage device 101 must first pass through connector 140. Although the following description refers only to a single host device, those skilled in the art will recognize that similar functions and / or procedures can be performed by any of host devices 152 and 154, server rack 156 and NaS 158 without departing from the invention, and the host devices are chosen as examples.

[0040] As illustrated in FIG. 1, module 130 may be disposed in storage device 101 and / or in any host device without departing from the present invention. Operationally, when storage device 101 is initially connected to host device 152, storage device 101 will be powered by host device 152. Once powered, module 130 will then retrieve a unique serial number associated with storage device 101 and a public key. In embodiments of the present invention, this unique serial number is stored in secure encryption processor 102, while the public key may be stored in any insecure location within memory 112.

[0041] Module 130 will also enable host device 152 (pre-loaded with an operating system) to provide a unique device identifier and a public key associated with host device 152. In embodiments of the invention, the unique device identifier may be generated by an authorized application installed within an operating system of host device 152. This authorized application (which may include an embedded application) may also be used to generate a pairing instruction that triggers pairing between storage device 101 and host device 152.

[0042] Since this is the first time that the storage device 101 is paired with the host device 152, when the host device 152 provides its unique device identifier and the public key associated with the host device 152, the host device 152 will also provide the pairing instruction to the module 130.

[0043] After receiving the required information from the storage device 101 and the host device 152, the module 130 will generate a digital signature for the two devices based on the serial number associated with the storage device 101 and the unique device identifier associated with the host device 152 to begin pairing the two devices.

[0044] In one embodiment of the invention, the digital signature is a session key generated as an algorithm for a good privacy (PGP) hybrid cryptography. The unique digital signature is then written into blockchain 170. When needed, a search can then be performed on the blockchain to detect whether the unique digital signature has been written to the blockchain.

[0045] In another embodiment of the invention, the PGP session key can be used as a message m, which is then signed using a Boneh-Lynn-Shacham (BLS) signing scheme. In the BLS scheme, message m is hashed to produce a hashed message h. The BLS signature σ is then generated as σ = hx, where x includes the private key of device 101 or 152 (e.g., unique identifiers for devices 101 and 152, respectively). This unique digital signature including the BLS signature σ is then written into blockchain 170. It should be noted that the BLS signature σ can be verified using the public BLS key of the device used to generate the BLS signature, such as the public key of device 101 or 152, respectively.

[0046] In an extension of this embodiment of the invention, all subsequent data transfers occurring between storage device 101 and host device 152 are then encrypted according to the PGP hybrid encryption system, whereby the public key of each device is used as the public PGP key of each device. In embodiments of the invention, the data transfers are typically initiated by module 130, as module 130 must provide the session key to other devices so that the other devices can decrypt the ciphertext and then use the session key to generate the ciphertext.

[0047] For example, when data is transferred from storage device 101 to host device 152, regardless of whether it is via P2P communication and / or conventional data transmission methods, module 130 will first encrypt the data using the session key to form ciphertext. The session key is then encrypted using the public key of host device 152. Module 130 then sends the session key encrypted with the public key, along with the ciphertext, to host device 152. After receiving the session key encrypted with the public key and the ciphertext, host device 152 then replies with the session key using its own private key. The replied session key is then used by host device 152 to decrypt the ciphertext back into plain text. The reply of the session key and the decryption of the ciphertext can both occur within a secure location set up within host device 152.

[0048] Since host device 152 now possesses the session key, and since the public key of storage device 101 is known to host device 152, when data is transmitted from host device 152 to storage device 101, host device 152 will use the session key to encrypt the received data to form ciphertext. The session key is then encrypted using the public key of storage device 101. Host device 152 then sends the session key encrypted with the public key, along with the ciphertext, to storage device 101, where it is intercepted by module 130. After receiving the session key encrypted with the public key and the ciphertext, module 130 then replies with the session key using the private key of storage device 101. In other embodiments of the invention, since the session key is already stored in module 130, module 130 can directly decrypt the ciphertext into plain text using the existing session key, without first decrypting the session key encrypted with the public key. The decrypted text is then delivered to storage device 101 for further processing.

[0049] For completeness, in another example, module 130 is located within host device 152. In this case, when data is transferred from host device 152 to storage device 101, module 130 uses the session key to encrypt the data into ciphertext. The session key is then encrypted using the public key of storage device 101. Module 130 then sends the session key encrypted with the public key, along with the ciphertext, to storage device 101. Upon receiving the session key encrypted with the public key and the ciphertext, storage device 101 then replies with the session key using its own private key. The replied session key is then used by storage device 101 to decrypt the ciphertext back into plain text. The reply of the session key and the decryption of the ciphertext can both occur in a secure location (e.g., encrypted memory 102) within storage device 101.

[0050] Since storage device 101 now possesses the session key, and since the public key of host device 152 is known to storage device 101, when data is transmitted from storage device 101 to host device 152, storage device 101 will use the session key to encrypt the received data to form ciphertext. The session key is then encrypted using the public key of host device 152. Storage device 101 then sends the session key encrypted with the public key, along with the ciphertext, to host device 152, where it is intercepted by module 130. After receiving the session key encrypted with the public key and the ciphertext, module 130 then uses the private key of host device 152 to reply with the session key. In other embodiments of the invention, since the session key is already stored within module 130, module 130 can directly decrypt the ciphertext into plain text using the existing session key, without first decrypting the session key encrypted with the public key. The decrypted text is then delivered to host device 152 for further processing.

[0051] In another embodiment of the present invention, the digital signature is generated as a Boneh-Lynn-Shacham (BLS) signature according to the BLS cryptographic signature scheme. Therefore, the serial number associated with storage device 101 is used as the private key of device 101, and the unique device identifier associated with host device 152 is used as the private key of device 152. In this embodiment, the message m signed using the BLS signature scheme may include, but is not limited to, a combination of the private keys of devices 101 and 152, or a hash of the private keys of device 101 and device 152, to generate a hashed message h. The BLS signature σ is then generated as σ = hx, where x includes the private key of device 101 or 152. This unique digital signature including the BLS signature σ is then written into the blockchain 170. It should be noted that the BLS signature σ can be verified using the public BLS key of the device that was used to generate the BLS signature, such as the public key of device 101 or 152.

[0052] All subsequent data transfers occurring between storage device 101 and host device 152 will then be encrypted using existing cryptographic algorithms, such as the PGP hybrid encryption system, symmetric encryption schemes and / or asymmetric encryption schemes, and / or may be signed using the BLS signature scheme.

[0053] In another embodiment of the invention, module 130 may, after a random and / or preset time period has elapsed, generate another digital signature (according to any of the above embodiments) for storage device 101 and host device 152 based on a serial number associated with storage device 101 and a unique device identifier associated with host device 152. Module 130 will then perform a check on the blockchain to determine whether the newly generated digital signature is visible on the blockchain. If a match is found, this means that the two devices have previously been paired, and in this regard, encrypted data exchange can still occur between the two devices. Conversely, if no match is found, all data transmission between the two devices will be stopped.

[0054] In another embodiment of the present invention, the digital signature can be generated using any cryptographic scheme, such as, but not limited to, asymmetric encryption, symmetric encryption, signature algorithms, key generation algorithms, signature verification algorithms, digital signature schemes, and / or any combination of these schemes.

[0055] Referring to FIG1, it is noted that the storage device 101 includes a power management chipset (PMIC) 110, a security encryption processor / memory 102, a system-in-package (SIP) 106, a flash array 104, a random access memory (RAM) 108, and an interface bus 114. The flash array 104 and RAM 108 are connected to the security encryption processor / memory 102, the controller 106, and the interface bus 114 via a communication bus 116.

[0056] The flash array 104 may include any type of electronic non-volatile computer memory storage media that can be electronically erased and reprogrammed, such as NAND or NOR flash memory. The interface bus 114 acts as a physical interface between a host device and the storage device 101, and thus existing storage standards and interfaces, such as, but not limited to, the Small Computer System Interface (SCSI) protocol, the Serial Advanced Technology Attachment (SATA) protocol, Serial Attached SCSI (SAS), Non-Volatile Memory Express (NVMe), Peripheral Component Interconnect Express (PCIe), NVMe over Fibre (NVME-oF), Network Attached Storage (NAS) protocol, or any similar interface, may be used as a link to communicatively connect the storage device 101 to a host device, such as a computer.

[0057] SIP 106 is a complex embedded system with independent processing, and works with the firmware and modules contained within SIP 106 to manage all features of storage device 101, including protecting and controlling the contents stored in flash array 104, RAM 108, and secure encryption processor / memory 102. This controller is most often implemented as a SoC (System-on-a-Chip) design, which consists of multiple hardware-accelerated functional blocks / modules coupled to one or more embedded processor cores.

[0058] The secure encryption processor / memory 102 includes a dedicated chip / microprocessor for performing cryptographic operations, and is typically embedded within a tamper-proof package. Its primary function is to serve as the foundation of the security subsystem, and it only outputs encrypted data once the external environment has been secured and established. The PMIC 110 includes a power management chipset that draws its power directly from the host device's power supply. In this sense, the storage device 101 is only "powered on" once it is connected to a host device.

[0059] Those skilled in the art will recognize that the various memory components described above include non-transitory computer-readable media, and therefore should be considered to include all computer-readable media except for transient propagation signals. Typically, the instructions are stored as program code in the memory component, but may also be wired.

[0060] The detailed operation of blockchain 170 is omitted for brevity, as it is known to those skilled in the art. In embodiments of the invention, blockchain 170 may include a decentralized distributed database system in which all nodes of the blockchain network are anonymous and all participate in the maintenance of the blockchain. In other embodiments of the invention, blockchain 170 may include a private decentralized database system located within any one of host devices 152, 154, server rack 156, and / or NaS 158.

[0061] According to an embodiment of the present invention, a block diagram representing the components of a processing system 200 according to an embodiment of the present invention is depicted in FIG2, which may be disposed within host devices 152, 154, server rack 156, NaS 158 and / or any computing device / human interface device having an operating system for implementing the embodiment. Those skilled in the art will recognize that the exact configuration of each processing system disposed within these modules / devices may be different, and thus the exact configuration of the processing system 200 may vary, and FIG2 is provided merely as an example.

[0062] In embodiments of the present invention, each of the human interface device, host devices 152, 154, server rack 156, and / or NaS 158 may include a controller 201 and a user interface 202. The user interface 202 is configured to enable human interaction between a user and each of these modules as needed, and for this purpose includes input / output components for the user to input commands to provide updates to each of these modules. Those skilled in the art will recognize that the components of the user interface 202 may vary depending on the embodiment, but will generally include one or more of a display 240, a keyboard 235, and a handwriting pad 236.

[0063] The controller 201 communicates with the user interface 202 via bus 215, and the controller 201 includes a memory 220 mounted on a circuit board, a processor 205, an operating system 206, an input / output (I / O) interface 230 for communicating with the user interface 202, and a communication interface. The processor 205 processes instructions and data for performing the methods of this embodiment, and the communication interface in this embodiment takes the form of a network card 250. The network card 250 may be used, for example, to transmit data from these modules to other processing devices via a wired or wireless network, or to receive data via the wired or wireless network. Wireless networks that can be used by the network card 250 include, but are not limited to, Wi-Fi, Bluetooth, Near Field Communication (NFC), cellular networks, satellite networks, telecommunications networks, wide area networks (WANs), and so on.

[0064] Memory 220 and operating system 206 communicate with CPU 205 via bus 210. The memory components include volatile and non-volatile memory, and more than one of each type, including random access memory (RAM) 220, read-only memory (ROM) 225, and simple flash bundle (JBOF) 245, the last of which includes one or more solid-state drives (SSDs). Memory 220 also includes secure flash 246 for securely storing secret or private keys. Those skilled in the art will recognize that the aforementioned memory components include non-transitory computer-readable media and should be considered to include all computer-readable media except for transient propagation signals. Typically, the instructions are stored as code in the memory components, but can also be wired. Memory 220 may include a core and / or a programmable module, such as a software application, which may be stored in volatile or non-volatile memory.

[0065] The term "processor" as used herein is used to refer overarchingly to any device or component capable of processing such instructions, and may include: microprocessors, microcontrollers, programmable logic devices, system-on-a-chip (SOC), field-programmable gate arrays (FPGAs), SOC+FPGA, application-specific integrated circuits (ASICs), or other computing devices. In other words, processor 205 may be provided by any suitable logic circuit system for receiving input, processing input according to instructions stored in memory, and generating output (e.g., to the memory component or on the display 240). In this embodiment, processor 205 may be a single-core or multi-core processor having memory-addressable space. In one example, processor 205 may be multi-core, such as including an 8-core CPU. In another example, it may be a cluster of CPU cores operating in parallel to accelerate computation.

[0066] Figure 3 is a block diagram depicting a plurality of modules according to an embodiment of the present invention, visible within the firmware of the storage device. The modules within firmware 300 allow firmware 300 to work with any type of host device and / or operating system. Hardware Abstraction Layer (HAL) 302 includes low-level drivers for all system-on-a-chip peripherals and application-specific integrated circuits (ASICs) to allow the computer's operating system to interact with the storage device at a general or abstraction layer, rather than at a detailed hardware layer. Security Authenticator Core 306 is a module configured to process credentials and perform instant encryption and / or decryption procedures. Firmware 300 also includes a first-stage bootloader 308, a second-stage bootloader 308, system firmware 312, and an interface driver 316. The first-stage bootloader 308 may include a read-only memory (ROM), and the second-stage bootloader 308 includes a secure bootloader to allow the firmware to communicate with the communication buses of various devices. A virtual RAM code 350 is also located within firmware 300. The detailed operation of these modules is omitted for simplicity, as it is known to those skilled in the art. Those skilled in the art will recognize that firmware 300 may include any combination of these modules, and thus this is left as a design option for those skilled in the art.

[0067] FIG4 is a flowchart depicting a procedure for accessing restricted logical block addresses (LBAs) in storage device 101 according to an embodiment of the present invention. In this embodiment of the present invention, it is assumed that module 130 is disposed in storage device 101, and it has been determined that encrypted data transmission between host device 152 and storage device 101 is permitted.

[0068] The user of host device 152 can then use an application programming interface (API) 404 of authorized application 402 to select a list of restricted LBAs. Depending on the type of OS 406 running on host device 152, an appropriate driver will be selected from low-level driver 408 and will be used to transmit the list of restricted LBAs to storage device 101 via communication bus 410.

[0069] Upon receiving the restricted LBAs in this list, module 130 then provides the list to front-end dispatcher 412. Front-end dispatcher 412 performs syntax analysis on the list and assigns a tag number to each of the restricted LBAs. RAM code 414 then retrieves information about the tag number to determine whether the LBA has been placed in a protected area. If it is intended to be moved to a protected area, RAM code 414 then moves the LBA to a protected area, whereby it can only be accessed by verified instructions from the host device. RAM code 414 then updates all block stripes and system tables (including flash conversion layers for SSDs) to migrate the restricted LBAs to a protected area, whereby all block stripes related to these data files are tagged using a tuple table. RAM code 414 accomplishes all of this with the help of backend dispatcher 416, firmware 418, HAL 420, controller 422, and flash drive bus 424.

[0070] Once this is completed, the list of restricted LBAs is then provided to module 130. Module 130 is then configured to intercept any instructions from host device 152 attempting to access the restricted LBAs. Module 130 will then only allow the intercepted instructions to access the restricted LBAs if the instructions have already been verified by module 130. In an embodiment of the invention, the instructions will be verified if it is determined that the instructions have been signed by the authorized application using a public key of the storage device and verified by the module using a private key of the storage device.

[0071] FIG5 is a depiction of a program 500 for authenticating data transfer between a storage device and a host device according to an embodiment of the present invention, wherein the program 500 may be implemented in a module 130 provided in the storage device and / or the host device.

[0072] Procedure 500 begins at step 502, whereby procedure 500 generates a digital signature based on a unique serial number associated with the storage device and a unique device identifier associated with the host device. The generation of the digital signature in this step is as described in the preceding paragraphs. At step 504, procedure 500 then uploads the digital signature to the blockchain. Procedure 500 then checks at step 506 whether the digital signature is present in the blockchain. If procedure 500 determines that the digital signature is present in the blockchain, it proceeds to step 508 to allow all encrypted / restricted data transfers between the storage device and the host device. Conversely, if procedure 500 determines that the digital signature is not present in the blockchain, it proceeds to step 510. In this step, all data transfers are not permitted between the storage device and the host device.

[0073] FIG6 illustrates a procedure 600 for transmitting encrypted data from module 130 to another paired device when the PGP hybrid encryption system is used according to an embodiment of the present invention. In this embodiment, the digital signature includes a PGP session key, which is generated based on the unique serial number of the storage device and the unique device identifier of the host device. Procedure 600 begins at step 602, whereby the session key generated thereunder is used to encrypt the data to be transmitted to the paired device. At step 604, procedure 600 then proceeds to encrypt the session key using the public key of the paired device. The session key encrypted with the public key and the ciphertext are then transmitted to the paired device at step 606. For completeness, it should be noted that after receiving the session key encrypted with the public key and the ciphertext, the paired device can then decrypt the session key using its own private key, and the decrypted session key can then be used to decrypt the ciphertext.

[0074] Figure 7 illustrates a procedure 700 for restricting access to restricted LBAs. Procedure 700 begins at step 702, whereby it first receives a list of restricted LBAs. Procedure 700 then adds this list of restricted LBAs to a protected area within the storage device. At step 704, procedure 700 is then configured to intercept any instructions targeting these restricted LBAs. Once the instruction is intercepted, procedure 700 then determines at step 706 whether the instruction is valid and / or authorized. If procedure 700 determines the instruction is valid, it allows the instruction to access the restricted LBA. Conversely, if procedure 700 determines the instruction is invalid, it proceeds to step 710. At this step, the instruction is denied access to the restricted LBA, and no further action is permitted.

[0075] Many other changes, substitutions, variations and modifications can be determined by those skilled in the art, and it is desired that the present invention cover all such changes, substitutions, variations and modifications that fall within the scope of the appended claims. [Simplified Explanation of the Diagram]

[0032] The above and other problems are solved by the features and advantages of the system and method of the present invention, as described in the detailed description and shown in the following figures. [Figure 1] is a block diagram depicting a system for authenticating data transmission between a storage device and a host device according to an embodiment of the present invention; [Figure 2] is a block diagram depicting a processing system representing an embodiment of the present invention; [Figure 3] is a block diagram depicting a module contained within firmware of a storage device according to an embodiment of the present invention; [Figure 4] is a flowchart depicting a procedure for accessing a restricted logical block address (LBA) in a storage device according to an embodiment of the present invention; [Figure 5] is a flowchart depicting a procedure or method for authenticating data transmission between a storage device and a host device according to an embodiment of the present invention; [Figure 6] is a flowchart depicting a procedure or method for transmitting encrypted data between the storage device and the host device according to an embodiment of the present invention; and [Figure 7] is a flowchart depicting a procedure for accessing a restricted logical block address (LBA) in a storage device according to an embodiment of the present invention.

Claims

1. A module for authenticating data transfer between a storage device and a host device, the module comprising: Processing unit; And a non-transitory medium readable by the processing unit, the medium being storage instructions that, when executed by the processing unit, cause the processing unit to: generate a digital signature for the storage device and the host device based on a unique number associated with the storage device and a unique device identity associated with the host device, wherein the unique number is set within a secure encryption processor in the storage device; determine whether the digital signature has been written into a blockchain; when it is determined that the digital signature matches the digital signature written into the blockchain, allow encrypted data transmission between the storage device and the host device; or when it is determined that the digital signature does not match the digital signature written into the blockchain, prevent data transmission between the storage device and the host device.

2. The module of claim 1, wherein the instruction for avoiding data transfer between the storage device and the host device further includes an instruction that, when executed by the processing unit, causes the processing unit to: write the digital signature into the blockchain when a paired instruction is received from an authorized application located on the host device; and allow encrypted data transfer between the storage device and the host device when the digital signature has been written into the blockchain.

3. The module of claim 1 further includes instructions that, when executed by the processing unit, cause the processing unit to: after a random time period has elapsed, generate another digital signature for the storage device and the host device based on the unique number associated with the storage device and the unique device identity associated with the host device; determine whether the other digital signature matches the digital signature already written into the blockchain; when it is determined that the other digital signature matches the digital signature already written into the blockchain, allow encrypted data transmission between the storage device and the host device; or when it is determined that the other digital signature does not match the digital signature already written into the blockchain, prevent data transmission between the storage device and the host device.

4. A module of any of requests 1 to 3, wherein the instructions for generating the digital signature include instructions to instruct the processing unit to generate the digital signature based on the session key of a good privacy (PGP) hybrid encryption system.

5. The module of claim 4, wherein the instructions for enabling encrypted data transmission between the storage device and the host device include instructions to instruct the processing unit to: encrypt the PGP session key using public-key encryption; store the encrypted PGP session key in a secure location on the storage device and the host device; and encrypt all data exchanged between the storage device and the host device using the PGP session key.

6. A module of any of claims 1 to 3, wherein the instruction for generating the digital signature includes instructions to instruct the processing unit to: hash a combination of the unique number associated with the storage device and the unique device identity associated with the host device to generate a hash message h; convert the hash message h into a BLS signature σ using the Boneh-Lynn-Shacham (BLS) signature scheme; and use the BLS signature σ as the digital signature.

7. The module of claim 1, further comprising instructions that, when executed by the processing unit, cause the processing unit to: receive a restricted logical block address (LBA) from an authorized application located on the host device; intercept instructions from the host device to access the restricted LBA; and, when the instructions have been verified by the module, allow the intercepted instructions to access the restricted LBA, wherein the instructions are signed by the authorized application using the public key of the storage device and verified by the module using the private key of the storage device.

8. A module of any of claims 1 to 3, wherein the blockchain includes a private, decentralized database system located within the host device.

9. A method for authenticating data transfer between a storage device and a host device, comprising: A module is used to generate digital signatures for the storage device and the host device based on a unique identifier associated with the storage device and a unique device identity associated with the host device, wherein the unique identifier is set within a secure encryption processor in the storage device; the module is used to determine whether the digital signature has been written into the blockchain; when it is determined that the digital signature matches the digital signature written into the blockchain, the module is used to allow encrypted data transmission between the storage device and the host device; or when it is determined that the digital signature does not match the digital signature written into the blockchain, the module is used to prevent data transmission between the storage device and the host device.

10. The method of claim 9, wherein the step of preventing data transfer between the storage device and the host device further comprises the steps of: when a pairing instruction is received from an authorized application located on the host device, using the module to write the digital signature into the blockchain; and when the digital signature has been written into the blockchain, using the module to allow encrypted data transfer between the storage device and the host device.

11. The method of claim 9, further comprising the steps of: after a random period of time has elapsed, using the module to generate another digital signature for the storage device and the host device based on the unique number associated with the storage device and the unique device identity associated with the host device; using the module to determine whether the other digital signature matches the digital signature already written into the blockchain; when it is determined that the other digital signature matches the digital signature already written into the blockchain, using the module to allow encrypted data transmission between the storage device and the host device; or when it is determined that the other digital signature does not match the digital signature already written into the blockchain, using the module to prevent data transmission between the storage device and the host device.

12. The method of any of claims 9 to 11, wherein the step of generating the digital signature includes generating the digital signature based on a session key of a good privacy (PGP) hybrid encryption system.

13. The method of claim 12, wherein the step of enabling encrypted data transfer between the storage device and the host device comprises the following steps: encrypting the PGP session key using the module and using public key encryption; storing the encrypted PGP session key in a secure location on the storage device and the host device using the module; and encrypting all data exchanged between the storage device and the host device using the PGP session key using the module.

14. The method of any one of claims 9 to 11, wherein the step of generating the digital signature comprises the following steps: using the module to hash a combination of the unique number associated with the storage device and the unique device identity associated with the host device to generate a hashed message h; using the module and a Boneh-Lynn-Shacham (BLS) signature scheme to convert the hashed message h into a BLS signature σ; and using the BLS signature σ as the digital signature.

15. The method of claim 9, further comprising the steps of: using the module to receive a restricted logical block address (LBA) from an authorized application located on the host device; using the module to intercept an instruction from the host device to access the restricted LBA; and using the module to allow the intercepted instruction to access the restricted LBA when the instruction has been verified by the module, wherein the instruction is signed by the authorized application using the public key of the storage device and verified by the module using the private key of the storage device.

16. The method of any one of claims 9 to 11, wherein the blockchain includes a private, decentralized database system located within the host device.

Images