Wireless Security Protocols

Abstract

The present disclosure relates to a data storage device. A data port transmits data between a host computer system and a data storage device via a data channel. The device repeatedly broadcasts announcement packets via a wireless communication channel different from the data channel. Each announcement packet includes a random value and a message authentication code calculated based on the random value and an identity key. The identity key can be read by a to-be-connected device near the data storage device out-of-band of a data channel and a communication channel. The identity key enables the to-be-connected device to verify the message authentication code based on the random value and the identity key, thereby authenticating the data storage device.

Description

Technical Field

[0001] The present disclosure relates to a wireless security protocol. Background Art

[0002] The Bluetooth standard has gained widespread popularity due to its ease of pairing devices with each other. In particular, for applications with low security requirements, such as connecting a media player or a phone to a wireless headset, Bluetooth is the solution of choice.

[0003] However, there are some concerns about applications with high security requirements. For example, in some application scenarios, a manager device will be wirelessly connected to a data storage device, such as an external hard disk drive (HDD) or solid-state drive (SSD) that can be connected to a host computer system via a universal serial bus (USB). If a manager device such as a mobile phone will be wirelessly connected to such a device to perform administrator tasks, it is important that the connection is secure to prevent unauthorized access, damage, or loss of data stored on the data storage device. Current Bluetooth standards are worrying, especially related to privacy. It is hoped that the manager device does not need to share private information, such as keys, device information, etc., with an unknown data storage device before the data storage device is authenticated. For example, it would be undesirable if a malicious device could integrate a near field communication (NFC) chip that simulates a valid data storage device and successfully pairs with a manager device to obtain information about the manager device. Summary of the invention

[0004] The present disclosure relates to a security protocol that is based on out-of-band communication of an identity key from a server to a client. The identity key can then be used to protect the communication channel and can then be authenticated by the server using a certificate linked to a root certificate that can be accessed by the client. Therefore, the client and server do not need to share any private information before authenticating the server.

[0005] More specifically, before establishing a connection, the server calculates a message authentication code (MAC) using an identity key and a random value. The random value is sent to the client along with the MAC. The client can recalculate the MAC based on the random value and the identity key obtained out-of-band. In response to determining that the received MAC matches the recalculated MAC, the client has authenticated the server. Note that this initial authentication is possible without the server or client having to provide any private information. Since the MAC is calculated using the identity key, only nearby user devices can recalculate the MAC. To all other devices, the announcement packet appears random. In the case where multiple servers send announcement packets and multiple identity keys are available, the client can try each identity key and attempt to recalculate the MAC. If there is a match, the client has determined that the matching identity key is for the device with the matching MAC.

[0006] A data storage device is disclosed herein, which includes a data path, a data storage repository, and an access controller. The data path includes: a data port configured to transmit data between a host computer system and a data storage device through a data channel, wherein the data storage device is configured to register as a block data storage device to the host computer system; a non-volatile storage medium configured to store encrypted user content data; and an encryption engine connected between the data port and the storage medium, and configured to decrypt the encrypted user content data stored on the storage medium using an encryption key in response to a request from the host computer system. The data storage repository is configured to store an identity key. The access controller is configured to repeatedly broadcast announcement packets through a wireless communication channel different from the data channel, each announcement packet including a random value and a message authentication code calculated based on the random value and the identity key. The identity key can be read by a device to be connected close to the data storage device out of band of the data channel and the communication channel. The identity key is configured to enable the device to be connected to verify the message authentication code based on the random value and the identity key, thereby authenticating the data storage device.

[0007] In some embodiments, the data repository is further configured to store a data storage device certificate, which is configured to be cryptographically linked to a root certificate that can be accessed by the device to be connected; and the access controller is further configured to calculate a signature verified by the data storage device certificate, and send the data storage device certificate and signature to the device to be connected so that the device to be connected can authenticate the data storage device.

[0008] In some embodiments, the certificate includes a hash value of the identity key to bind the certificate to the data storage device, and the identity key can be read from the data storage device out-of-band.

[0009] In some embodiments, the root certificate is accessible by the connecting device via an application installed on the connecting device, the application being from an authenticated provider that is cryptographically associated with the root certificate.

[0010] In some embodiments, the announcement addresses for broadcast announcement packets are selected uniformly at random.

[0011] In some embodiments, each announcement packet also includes a service identifier of the data storage device, and wherein the message authentication code is calculated based on the random value, the identity key, and the service identifier.

[0012] In some embodiments, the access controller is further configured to receive a first random value from the device to be connected via a wireless communication channel; generate a second random value and broadcast the second random value via the wireless communication channel; derive an encryption key from the identity key, the first random value and the second random value using a key derivation function; and protect the wireless communication channel with the device to be connected using the encryption key.

[0013] In some embodiments, the communication channel is Bluetooth Low Energy.

[0014] In some embodiments, the identity key can be read by the device to be connected via a quick response (QR) code attached to the data storage device or via a near field communication (NFC) tag integrated in the data storage device.

[0015] Disclosed herein is a client device comprising a processor and a memory, the memory comprising instructions that can be executed by the processor to perform the following operations: receiving an identity key from a server out-of-band of a wireless communication channel; receiving an announcement packet broadcast by the server through the wireless communication channel, the announcement packet comprising a random value and a message authentication code calculated by the server device based on the random value and the identity key; verifying the message authentication code based on the random value and the identity key to authenticate the server; and when authenticating the server, generating an encryption key based on the identity key to protect the wireless communication channel with the server device.

[0016] In some embodiments, the memory also includes instructions executable by the processor to access a root certificate cryptographically linked to the server's certificate.

[0017] The present invention discloses a method for protecting a wireless communication channel between a client device to be connected and a server device. The method comprises repeatedly performing the following steps: generating a random value; calculating a message authentication code based on the random value and an identity key, the identity key being readable by the client device to be connected close to the server device out of band of the wireless communication channel, the identity key enabling the client device to verify the message authentication code based on the random value and the identity key, thereby authenticating the server device; and broadcasting a notification packet through the wireless communication channel, the notification packet comprising the random value and the message authentication code calculated based on the random value and the identity key.

[0018] In some embodiments, the method also includes sending a server certificate issued by the server device to the client device in response to receiving a connection request from the client device, the server certificate including a hash value of an identity key to bind the certificate to the server device, and the identity key can be read from the server device out-of-band.

[0019] In some embodiments, the server certificate is cryptographically linked to a root certificate that is accessible by the client device.

[0020] In some embodiments, the method further includes: calculating a signature; and sending the signature to the client device in response to receiving a connection request from the client device.

[0021] In some embodiments, the signature is verified by the server certificate by computing the signature using a private key that is verified by the server certificate.

[0022] In some embodiments, the server certificate includes a public key corresponding to a private key for use in verifying the signature.

[0023] In some embodiments, the method further includes calculating a hash of the identity key, the random number received from the client device, and the random value; and calculating a signature of the hash based on the identity key and verifying it by the server certificate.

[0024] In some embodiments, authenticating a server device includes receiving from the server device a server certificate issued by the server device and a signature calculated by the server device based on an identity key and verified by the server certificate; verifying the server certificate against a root certificate; verifying the signature against the server certificate; and protecting a wireless communication channel with the server device when verifying the signature.

[0025] Disclosed herein is a server device for protecting a wireless communication channel between a client device to be connected and a server device, the server device comprising a processor configured to repeatedly perform the following steps: generating a random value; calculating a message authentication code based on the random value and an identity key, the identity key being readable by the client device close to the server device out-of-band of the wireless communication channel, the identity key enabling the client device to verify the message authentication code based on the random value and the identity key, thereby authenticating the server device; and broadcasting a notification packet through the wireless communication channel, the notification packet comprising a random value and a message authentication code calculated based on the random value and the identity key. BRIEF DESCRIPTION OF THE DRAWINGS

[0026] Non-limiting examples will now be described with reference to the following drawings:

[0027] Figure 1 A data storage device according to one embodiment is shown.

[0028] Figure 2 According to one embodiment, Figure 1 A section of the configuration memory of a data storage device.

[0029] Figure 3 According to one embodiment, Figure 1 The control flow between the authorization device and the access controller.

[0030] Figure 4 A certificate issued by a data storage device and sent by an authorization device to the data storage device to unlock the data storage device is shown according to one embodiment.

[0031] Figure 5 A method for protecting a wireless communication channel between a client device and a server device according to one embodiment is shown.

[0032] Figure 6 A protocol for protecting a communication channel between a data storage device and a connecting client device according to one embodiment is shown. DETAILED DESCRIPTION

[0033] Figure 1 1 shows a data storage device (DSD) 100 including a data path 101 and an access controller 102 according to one embodiment. The data path 101 includes a wired data port 103, which is connected to the Figure 1 104 and DSD 100. In other embodiments, the data path 101 includes a wireless data port (not shown) for wirelessly transmitting data between the host computer system 104 and the DSD 100. The DSD 100 is registered with the host computer system 104 as a large-capacity data storage device that provides functionality to the operating system of the host computer system 104 of the block data storage device. The DSD 100 also includes a non-transitory storage medium 105 for storing encrypted user content data, noting that user content data is data that users typically want to store on the DSD, such as files including image files, documents, video files, etc. The storage medium can be a solid-state drive (SSD), a hard disk drive (HDD) with a rotating disk, or other non-volatile storage medium. In addition, the storage medium can be a block data storage device, which means that user content data is written to the storage medium 105 in the form of blocks and read from the storage medium 105 in the form of blocks.

[0034] Command Set

[0035] In one example, the storage medium 105 includes an encryption engine 106 in the form of an application specific integrated circuit and / or a programmable integrated circuit that encrypts data to be stored on the storage medium 105 and decrypts data to be read from the storage medium 105. In such examples, the storage medium may provide a Small Computer System Interface (SCSI) or Advanced Technology Attachment (ATA) command set in accordance with the optical specification of the Trusted Computing Group (TCG).

[0036] Program code stored on the encryption engine 106 enables the encryption engine 106 to receive, interpret and execute commands received from the host computer system 104. For example, the encryption engine 106 can be configured to implement the standard ATA or Serial ATA (SATA) and / or ATA Packet Interface (ATAPI) command set, which can be obtained from Technical Committee T13, noting that the same functionality can be implemented in TCG Opal, SCSI and other proprietary architectures. The command set includes a READ SECTORS command, and the command input is a count of sectors and a starting sector (note that "sector" is used synonymously with "block" in this article). Therefore, there is a corresponding write command. It should be noted that a data storage device driver is installed on the host computer system 104. The data storage device driver (not shown) uses the command set to provide advanced services to the operating system, such as file read functions. In some examples, the data storage device driver is a generic driver provided as part of the operating system, and does not support device-specific encryption commands because the encryption functions are hidden from the host computer system 104 and are processed internally within the DSD 100, as described below. This means that there is no need to install additional drivers to use the full functionality disclosed herein.

[0037] The command set provided by the encryption engine 106 to the data port 103 (but not forwarded to the host computer system 104) may include a command set from the ATA SECURITY feature set. Specifically, the command set may include the command SECURITY SETPASSWORD or a corresponding command from TCG Opal to set a password for reading user content data and writing user content data to the storage medium 105.

[0038] In this sense, the encryption engine 106 is connected between the data port 103 and the storage medium 105, and is configured to use the encryption key to encrypt the user content data to be stored on the storage medium 105 and decrypt the encrypted user content data stored on the storage medium 105 in response to a request from the host computer system 104. In some examples, the ATASECURITY feature set is only used by the data port 103, and not by the host 104. That is, the access controller 102 provides the necessary input for the data port 103 to issue the ATASECURITY command to the encryption engine 106. For example, the access controller 102 can provide the key to the data port 103, and then the data port 103 forwards the key to the encryption engine 106 via the SECURITY SET PASSWORD command. The interface between the access controller 102 and the data port 103 can be an inter-integrated circuit (I2C) bus, which is particularly useful in the case where the bus has been implemented in an existing chip. However, many other communication architectures can be used, including bus architectures, point-to-point architectures, serial architectures, parallel architectures, memory-based architectures, and other architectures.

[0039] Please note that Figure 1 The separation of functions in the dedicated chip shown is only one possible exemplary implementation. Therefore, functions can be further combined or split. For example, the data port 103 can be integrated with the access controller 102 into a single chip with a single core. In other cases, the data port 103 and the access controller 102 can be integrated with the encryption engine 106 into a single dedicated chip with a single core. Of course, all chips can have multiple cores.

[0040] In one example, the following components are used:

[0041] Data port 103: USB 3.1 Gen 2 10 Gigabit per second (Gb / s) interface

[0042] Access Controller 102: nRF52840 System-on-Chip (SoC) from Nordic Semiconductor

[0043] Note that for the functionality disclosed herein, the access controller 102 plays a primary role and will be described in more detail below, again noting that in other examples, tasks may be split into separate chips. When reference is made to the "configuration" of the access controller 102 or the access controller 102 is "configured" to perform a certain step, this should be understood to refer to program code stored on a program memory (not shown for clarity) on a non-volatile memory in the DSD 100 and executed by the access controller 102.

[0044] In other examples, some or all of the steps disclosed herein may be performed by hardware circuits without program code. Specifically, for performance and security reasons, cryptographic primitives may be implemented by dedicated hardware circuits. For example, particularly computationally demanding commands (such as elliptic curve multiplication or exponentiation) may be implemented by an arithmetic logic unit (ALU) specifically designed for that calculation, so that the calculation can be performed in a single or fewer number of processor cycles than using a sequential program in a general-purpose microcontroller. It should also be noted that the chips included in the DSD 100 are microcontrollers, which means that in this context, they do not run under an operating system that provides a hardware abstraction layer, but rather program code acts directly on hardware circuits. Although elliptic curve encryption is used as an example in this article for computational efficiency and security reasons, it should be noted that other public key cryptographic systems, such as the Rivest-Shamir-Adelman (RSA) cryptographic system, may also be used.

[0045] return Figure 1 In addition to the host computer system 104, there are multiple devices located external to the DSD 100 and that play a role in unlocking the DSD 100 and providing keys to the encryption engine 106, so that the plaintext decrypted data can ultimately be provided to the host computer system 104.

[0046] Specifically, there is a first manager device 110, which in most examples is a mobile phone. An application (app) installed on the manager device 110 performs the following steps. As such, the following steps may be implemented in software by the manufacturer of the DSD 100 and distributed to the manager devices 110 via a commonly accessible application store (such as Apple's App Store or Google Play). The application installed on the manager device 110 performs the steps of acquiring ownership of the DSD 100, at which point all data on the DSD 100 is erased or otherwise rendered inaccessible. For example, the data may be cryptographically erased by securely deleting all encryption keys stored on the DSD 100.

[0047] For simplicity, the present disclosure describes the steps as being simply performed by the manager device 110 if they are implemented by an application. The manager device 110 sets up the DSD 100, which means generating various different keys to support the processes disclosed herein. The manager device 110 registers the user device 111 with the DSD, so that the user device 111 is subsequently referred to as an "authorized device" 111. In most examples, the authorized device 111 is also a mobile phone, which has an application installed that implements the steps described as being performed by the authorized device 111. However, other types of devices can be used as authorized devices, which will be explained below with respect to beacons and key cards.

[0048] Taking Ownership

[0049] After purchase, unpacking, and powering up, the first step in using the DSD 100 is to install the application on the manager device 110 and register the device as a manager device 110. For this process, the manager device 110 obtains a unique identifier for the DSD from the DSD. This unique identifier is called an identity key (IDK). Figure 1 In the example shown, the identity key is encoded as a quick response (QR) code 112 that is attached to the outer surface of the DSD 100. An application installed on the manager device 110 has access to the camera and has a software module that extracts the encoded information from the image of the QR code 112. The manager device 110 captures the image of the QR code 112 using the camera and decodes the identity key of the DSD 100 from the QR code. In one example, the QR code encodes a uniform resource locator (URL). In this case, a universal application can capture the QR code, which then automatically directs the phone to an application store where the application can be downloaded. The URL also includes the identity key so that once the application is installed, the application can decode the identifier.

[0050] In another example, the manager device 110 may read another tag or NFC chip attached to or integrated with the DSD 100 to obtain the identity key. Then, using the identity key, the manager device 110 may initiate communication with the DSD 100 and, in particular, the access controller 102, such as wirelessly (e.g., via Bluetooth).

[0051] Recovery Key

[0052] Upon taking ownership of DSD 100, access controller 102 generates a recovery key and provides the recovery key to manager device 110. The recovery key may then be stored on secure storage 113 or printed and locked away. Finally, backup manager device 114 may use the recovery key to assume the administrator role previously held by manager device 110.

[0053] Registration of authorized devices

[0054] Once the DSD 100 is initially configured during the acquisition process, the manager device 110 registers the authorized device 111. Typically, there may be multiple authorized devices registered with a single DSD 100, so the manager device 110 registers the authorized device as one of the multiple authorized devices. More specifically, the access controller 102 receives a public key associated with a private key stored on the user device 111 from the manager device 110. The manager device 110 itself may have received the public key from the user device 111 via email, by scanning a QR code displayed on the user device 111, or in any other manner. At this point, the device 111 is not yet authorized, and is therefore referred to simply as "user device 111". Once the user device 111 is authorized, it is referred to as "authorized device 111". The access controller 102 creates authorization data indicating that the user device 111 is an authorized device (described below) and stores the authorization data associated with the public key on the configuration memory 115 to register the user device 111 as one of the multiple authorized devices. This means that keys and other data associated with the authorizing device 111 are created and stored as described below. The user can then use the authorizing device 111 to unlock the DSD 100 simply by placing the authorizing device 111 within wireless communication range (e.g., Bluetooth range). Again, the steps performed by the authorizing device 111 are encoded in an application installed on the authorizing device 111. Depending on configuration parameters, the user may be required to unlock the authorizing device 111 before the DSD 100 can be unlocked.

[0055] More specifically, the access controller 102 has access to a non-volatile configuration data repository, such as configuration memory 115, which may be flash memory external to the access controller 102 (but may equally be integrated into the access controller 102). The configuration memory 115 may also store program code that implements the steps described herein as being executed by the access controller 102. It is noted that some of the examples herein are configured to assume that an attacker may easily isolate and read out the contents of the configuration memory 115, but should not be able to use that information to decrypt user content data. That is, in those examples, no keys are permanently stored in plain text on the configuration memory 115 or elsewhere on non-volatile memory in the DSD 100.

[0056] Once the encryption keys are provided in plain text, they are stored only in volatile memory (not shown). This means that powering down the DSD 100 erases all encryption keys stored in plain text. Additional circuitry may be provided to reset all residual charge upon power down, power up, or external reset, making it physically impossible to recover any information from the volatile memory in practice. In many cases, a user disconnecting the USB cable from the host computer system 104 results in a power down and erase of all volatile memory. In other examples, a secondary power supply is used that requires disconnection to power down the DSD 100 to delete the volatile memory.

[0057] Challenge-Response

[0058] The configuration memory 115 has data stored thereon that is specific to the registered authorization device 111. This data may be referred to as an identifier of the authorization device 111 or as a public key associated with a corresponding private key stored on the authorization device 111. The public key may be a "transmission public key" (TPK) and is generated by the authorization device 111 when the application is first started by executing the elliptic curve cryptography (ECC) primitive ECC-Pub ({transmission private key}). (Recall that, although elliptic curve cryptography is used as an example in this article for reasons of computational efficiency and security, it should be noted that other encryption techniques may also be used.) The corresponding private key is stored on the authorization device 111. The access controller 102 is configured to use an identifier (e.g., a transmission public key) or to generate and store an additional public key to generate a challenge to the authorization device 111. It should be noted here that the challenge is unique because each challenge is different, so that subsequent challenges are different from any previous challenges. As described below, this is achieved by multiplying the stored data by a random blinding factor. The access controller 102 then sends the challenge to the authorization device 111 over a communication channel that is different from the data path. For example, the data path may include a wired USB connection, while the communication channel between the access controller 102 and the authorization device 111 is a wireless (eg, Bluetooth) connection.

[0059] In one example, a re-registration process is performed in response to the authorization device first connecting to the DSD 100 after the authorization data is created and stored on the configuration memory 115 in association with the public key of the authorization device 111 received from the manager device 110. During the re-registration process, the DSD 100 updates the authorization data and, as described below, may request that the authorization device 111 generate an unlock public key (and a corresponding unlock private key) in addition to transmitting the public key. The authorization device 111 then provides the unlock public key to the access controller 102.

[0060] This has the following advantages: two corresponding private keys (transmission private key and unlocking private key) can be stored separately on the authorization device, and the two keys can have different access policies. For example, even if the authorization device 111 is locked (e.g., by screen lock or timeout), the transmission public key can be accessed at any time to allow continuous communication between the authorization device 111 and the DSD 100. However, in order to unlock the DSD 100, the access policy of the unlocking private key may require the user to unlock the authorization device 111, enter a personal identification number (PIN), provide biometrics or other authentication. In this way, a stolen authorization device cannot unlock the DSD 100. Since unlocking the DSD 100 is only performed once when the DSD 100 is powered on, the increased security does not significantly reduce user convenience.

[0061] Authorized device 111 may calculate a response to the challenge that cannot be calculated by any other device not registered with the DSD. More specifically, a device that does not have access rights to the data corresponding to the identifier stored on configuration memory 115 cannot calculate the correct response. For example, authorized device 111 calculates the response to the challenge using a stored unlock private key associated with a corresponding unlock public key stored on configuration memory 115.

[0062] The access controller 102 receives a response to the challenge from the authorization device 111 via the communication channel. It should be noted here that if the access controller 102 simply verifies the response to the challenge and, upon success, reads the encryption key from the configuration memory 115, the encryption key will be stored in plain text, which is undesirable because it will enable an attacker to deassemble the DSD 100 and read the key from the configuration memory 115 to access the user content data stored on the storage medium 105.

[0063] Calculate the key

[0064] Therefore, instead, the access controller 102 computes the encryption key based at least in part on the response from the authorization device 111. This means that the encryption key is not a pure function of the response, but involves other values ​​as described in more detail below. In summary, the encryption key is stored in encrypted form on the configuration memory 115, and the calculation of the secret to decrypt the encryption key is enabled based on the response of the private key stored on the authorization device.

[0065] Throughout this disclosure, reference may be made to the "encapsulation" of a key, which simply means that a key is encrypted by another key (i.e., by a "secret"). In many cases of "encapsulation", the encryption is symmetric, such that there is a single secret (key) that can decrypt the encrypted key (there is no public key associated with the secret). In one example, the symmetric encryption uses Advanced Encryption Standard (AES) primitives.

[0066] Finally, the access controller 102 provides the encryption key to the encryption engine 106 (via the data port 103 in this example) to decrypt the encrypted user content data stored on the storage medium 105 of the DSD 100. As described above, once the access controller 102 has calculated the encryption key, the access controller 102 provides the encryption key in plain text to the data port 103, and the data port 103 issues a SECURITY SET PASSWORD command including the encryption key to the encryption engine 106.

[0067] Note that where reference is made to "unlocking" the device, this may refer to the entire process described above, including the challenge, the response to the challenge, and the sending of an encryption key to the encryption engine 106 to allow a plain text read command issued by the host computer system. In other examples, the challenge and the response to the challenge are considered part of a separate "connection" step. During the following "unlock" step, the access controller 102 then sends the encryption key to the data port 103 to allow access to the user content data.

[0068] It is worth noting that, in addition to this, it is possible for an attacker to eavesdrop on the transmission of the key from the access controller 102 to the data port 103 and then to the encryption engine 106. However, the transmission of the key is not over a public network, so such eavesdropping would require gaining access to and disassembling the unlocked DSD without removing power from the DSD 100. This scenario can be discarded as a threat because in this scenario, the user content data is available on the host computer system 104 anyway. In other words, while the DSD 100 is connected and unlocked, the data is available to both the legitimate user and the attacker. But once the user disconnects the DSD from the host computer system 104, such an eavesdropping attack is no longer possible. Therefore, this attack will not be considered further.

[0069] For the sake of completeness, it is noted that once the encryption engine 106 has received the encryption key, the host computer system 104 can issue a normal READ SEGMENT command and transparently access the encrypted data without any perceptible difference to accessing an unencrypted device. This is particularly true if the encryption engine has a hardware encryption module to achieve encryption and decryption at or above the read and write speeds of the storage medium 105 and / or data port 103. However, the user can disconnect the DSD 100 to lock it. In this way, the DSD 100 can be carried by the user through an unsecured location where the DSD 100 may be lost or stolen, but it is difficult for others to decrypt the encrypted user content data stored on the storage medium 105. If the user has the DSD, the user can connect it to the second host computer system 116, conveniently unlock the DSD 100 using the user's authorized device 111 (e.g., a phone), and easily access the encrypted user content data stored on the storage medium 105.

[0070] For user convenience, data port 103 may be configured so that if the DSD is locked, it registers with host computer system 104 as a large-capacity data storage device with no storage media present, similar to an SSD card reader with no card inserted. Once an authorized device 111 is connected to DSD 100 and DSD 100 is unlocked, data port 103 switches to the storage media present, similar to a card reader with an SSD card inserted. Such a configuration will prevent the host computer system 104 operating system from generating any warnings about data being inaccessible or access being denied. Instead, all user interactions will be performed by an application installed on the authorized device, which is fully controlled by the manufacturer of the DSD, so the user experience can be optimized. Figure 1 As shown, there may also be mobile phones acting as authorization devices 117 and 118.

[0071] Beacons and key fobs

[0072] Consider Again Figure 1, it can be seen that there are additional devices, such as beacons 120 and key fobs 121. These devices may also be considered "authorized devices" because they may operate substantially the same as the authorized device 111. Prior to initial registration by the manager device 110, these devices are referred to as "devices to be authorized." When reference is made to "user devices" herein (primarily describing the mobile phone 111 prior to initial registration), this also applies to the beacons 120 and key fobs 121, unless otherwise noted, such as where user input is required. The beacons 120 and key fobs 121 also have their own securely stored private keys so that they can respond to challenges specific to one beacon or key fob. However, since there is no user input for the beacons 120 and key fobs 121, the initiation of communication may be slightly different. More specifically, the beacons 120 and key fobs 121 may periodically send announcements to broadcast their presence, and the DSD 100 then initiates communication with the beacons 120 and / or key fobs 121, which prompts them to send their transmission public keys. This is in contrast to the authorization device 111 which sends a transmission public key to the DSD 100 to initiate communication.

[0073] In another example, the beacon 120 is in a deactivated state when it is powered on and needs to be activated by the manager device 110 or the authorization device 111. This activation may follow a similar process to unlocking the DSD 100. That is, the manager device 110 or the authorization device 111 or both register with each beacon 120 using its transmission public key and respond to a challenge as described herein. Thus, a device may register with one of the beacons 102 and / or the key fob 121 as a manager device or an authorization device without registering with the DSD 100 itself. If the response to the challenge is valid, the beacon 120 unlocks the DSD 100. In yet another example, the beacons 120 register with each other such that the manager device 110 and / or the authorization device 111 need only activate one of the beacons 120 and the remaining beacons automatically activate. In other words, the activation is "propagated" through the beacon network as long as the beacons are within range of each other.

[0074] Note that the only information that authorized devices 111, 117, 118, 120, and 121 provide to manager device 110 for registration is a public key for each device. In other words, each device provides its own public key that corresponds to a private key securely stored on that device. Therefore, if an attacker intercepts the initial communication between one of devices 111, 117, 118, 120, and 121 and manager device 110, the only information the attacker can obtain is the public key. As the name implies, the public key is not a secret and can be well known. Therefore, the attacker does not gain any advantage. In addition, manager device 110 cannot use the public key to access anything else related to the authorized device. For example, a manager device cannot decrypt or unlock any other data storage device with which other manager devices have registered the authorized device.

[0075] The access controller 102 receives the public key of the authorized device from the manager device 110 and generates authorization data. The access controller 102 stores the authorization data on the configuration memory 115 and waits for the authorized device to connect for the first time. At the first connection, the access controller 102 performs a challenge-response to the authorized device and, upon success, updates the authorization data to indicate that the authorized device is now fully registered. This first connection process is referred to herein as "re-registration," and details of generating authorization data and re-registration are provided below.

[0076] Elliptic Curve Cryptography

[0077] In one example, the challenge generated by the DSD 100 and sent to the authorization device 111 is based on elliptic curve cryptography. This has the advantage of shorter keys, resulting in more efficient communication and storage. In addition, a large number of phones currently on the market provide dedicated elliptic curve cryptographic functions within a secure hardware module. The secure hardware module securely stores the user's private keys and executes cryptographic primitives within the secure hardware module without the keys leaving the secure hardware module and being sent to a general-purpose processor core, where the keys may be subject to unauthorized retrieval attacks. In one embodiment, the secure hardware module includes an independent processor that executes its own microkernel that cannot be directly accessed by the operating system or any program running on the phone. The secure hardware module may also include a non-volatile storage device for storing a 256-bit elliptic curve private key. In one embodiment, the secure hardware module is a Secure Enclave coprocessor available on some Apple devices.

[0078] Authorized device data record

[0079] Figure 2 1 shows a cross section of configuration memory 115 according to one embodiment. More specifically, Figure 2 A record 201 in the configuration memory 115 is shown, which is associated with one of the multiple authorized devices and is referred to herein as "authorization data". Additional data records for additional authorized devices are schematically indicated as empty dashed boxes, but details are not considered when they operate in a similar manner to record 201. Specifically, each additional data record includes authorization data, which is generated by the access controller 102 in response to receiving a public key of a user device from the manager device 110, and then updated during the first connection of the user device (hereinafter referred to as "authorized device"). For convenience, the data structure of the configuration memory 115 is referred to as a "table" including one or more "records", each of which relates to a registered authorized device and each record has multiple fields. However, it should be noted that other data structures can be used, such as JavaScript Object Notation (JSON), Extensible Markup Language (XML), binary format, etc. In one example, each entry has a fixed length, and the table has a fixed number of rows (i.e., entries). In the present disclosure, a "record" may also be referred to as a "row" or "entry".

[0080] Record 201 includes a field for a pre-authorization key 202, which is used in response to the first connection of the authorized device 111 to the DSD 100. During this first connection, the access controller 102 performs a number of steps referred to as "re-registration," as described in more detail below. The pre-authorization key 202 is generated by an identifier of the authorized device 111 (e.g., a transmission public key). For example, the access controller 102 can generate the pre-authorization key 202 by applying a key derivation function together with an authorized device slot key to the derivation function, the key derivation function using the x-coordinate of the transmission public key as an input parameter, the authorized device slot key as a salt value. The authorized device slot key can be a pseudo-random number (e.g., 16 bytes) stored on the configuration memory 115, and can be used to encrypt data in an authorized device certificate so that only the issuing DSD 100 can recover the information.

[0081] At this point, it can be said that the records stored on the configuration memory 115 are indexed by the pre-authorization key 202 based on the identifier of the authorized device (e.g., the transmission public key). Figure 4 As described, during re-registration, the index of record 201 may be stored as a slot number in the certificate and the pre-authorization key 202 may be replaced with a random value at this time to make the configured DSD indistinguishable from a new device leaving the factory even in possession of the transport public key.

[0082] Record 201 also includes fields for a first copy of a metadata encapsulation key (MWK) 203 and a pre-authorization metadata encapsulation key (PMWK) 214. Some of the fields in record 201 are encrypted, which are indicated by double-line boxes, where a single solid box within the double-line box indicates a "payload", such as metadata encapsulation key 203 and pre-authorization metadata encapsulation key 214. The corresponding encryption key used to encrypt the payload is noted at the bottom of the double-line box. Thus, for example, metadata encapsulation key 203 is encrypted by authorized device metadata key (ADMK) 204. It should be noted that each encrypted box may include an additional random number concatenated with the payload data. This ensures that even possession of encrypted data (such as the transmission public key of an authorized device) cannot distinguish the encrypted entry from the random data.

[0083] The record 201 also includes a field for authorized device metadata (ADM) 205, which is a concatenation of a device type 206 (e.g., recovery key, key fob, beacon, phone, computer, watch, etc.), a role of the device 207 (e.g., administrator or user), a name of the device 208 (e.g., "John's phone"), a transport public key 209, unlock key metadata 210 (e.g., whether a fingerprint, PIN, or key restriction is required for unlocking), a temporary public key 211, and an unlock public key 212. In one embodiment, the temporary public key 211 is an elliptic curve public key generated from a random temporary private key (EPK) using an elliptic curve cryptography (ECC) primitive ECC-Pub (EUK). The temporary private key is not stored on the configuration memory 115 or on the authorized device 111, but is discarded after the temporary public key is created. This means that the temporary private key is not stored on non-volatile memory, but only on volatile memory. Therefore, a power failure to the memory results in a complete and irrecoverable loss (e.g., destruction) of the temporary private key. The unlock public key 212 corresponds to the unlock private key stored on the authorizing device 111 , and is generated by the authorizing device 111 and provided to the access controller 102 .

[0084] The authorized device metadata (concatenated with an additional random number) is encrypted by a metadata wrapping key (MWK) 213, which is also stored in encrypted form at 203. The primary purpose of storing the encrypted metadata wrapping key 203 in entry 201 is to allow a manager user with access rights to the authorized device metadata key 204 to access the encrypted authorized device metadata 205. If the manager does not have access to the metadata wrapping key, the manager will not be able to retrieve any information from the DSD 100 about which authorized devices are currently registered. In one example, the authorized device metadata key 204 is a single key for all authorized devices and is stored encrypted by the manager key. The manager key can be a pseudo-random value (e.g., 32 bytes) and is generated by the access controller 102 in response to the storage medium 105 being erased. The manager key is encrypted and stored for each paired manager device 110 / 114.

[0085] Record 201 also includes a field for a second copy of the device role 220 concatenated with a second copy of the user key 221 and the metadata encapsulation key 222. Note that the roles 207 / 220 and metadata encapsulation keys 203 / 222 are stored in two copies that are identical but encrypted using different keys. The purpose of storing two copies of the roles 207 / 220 is to enable the access controller 102 to verify the roles during connection (in response to the authorization device metadata being decrypted) and during unlocking (in response to the user key 221 being decrypted). The purpose of storing the first copy of the metadata encapsulation key 203 is to provide it to manager devices that have access rights to the authorization device metadata keys. The purpose of the second copy of the metadata encapsulation key 222 is to provide it to pre-authorized devices during the first connection. The concatenated values ​​220, 221, 222 are encrypted together by a temporary unlocking secret (EUS) 223, which is initially generated by the Diffie-Hellman method using a temporary private key corresponding to the temporary public key 211 and the unlocking public key 212. The temporary unlocking secret 223 can be recovered using the temporary public key 211 and the associated unlocking private key stored on the authorized device 111 and corresponding to the unlocking public key 212. In other words, the temporary unlocking secret 223 can be generated when the authorized device 111 is first connected to the DSD 100 using the temporary private key and the unlocking public key 212. Note that the temporary private key itself is not stored, but the temporary unlocking secret 223 can still be recovered as described above. This means that the user key 221 can be decrypted based on the response from the authorized device. Note that the user key 221 is the same for all authorized devices and can be used to decrypt user content data. This does not necessarily mean that the user key itself decrypts the user content data. There may also be a key that the user key decrypts and the final key decrypts the user content data. The terms "decrypting user content data using a key" and "enabling decryption of user content data" refer to indirect encryption via multiple keys in a chain. In contrast, "key decryption data" refers to directly decrypting data using a key, such as modular multiplication of encrypted data with a key. Here, user key 221 is used to indirectly decrypt data and can be the starting point of a chain of keys that are decrypted in sequence until, at the end, the chain ends at the key that decrypts the user content data. Although in most examples disclosed herein, temporary unlocking secret 223 decrypts user key 221, encryption keys can also be derived from responses to challenges in other ways. For example, responses to challenges can be used directly as encryption keys to decrypt user content data.

[0086] This distribution of keys and metadata enables configuration in which the entire configuration information about authorized devices, manager devices, and other aspects is stored on the DSD 100 itself. However, the authorized devices require the keys stored on the corresponding authorized devices to unlock the DSD 100. If an unregistered user who does not have access to any keys wants to access the entire configuration of the device, such as retrieving a list of registered devices, the unregistered user will only need the recovery key to register as a manager device and gain access to the manager key. The DSD 100 can then use the manager key to provide the entire contents of the configuration memory 115 to the new manager device. In addition, there may be two manager devices, and both can register or remove authorized devices. Other manager devices will be able to obtain configuration updates by synchronizing their own records with the data stored on the configuration memory 115. In some examples, the DSD 100 is configured to erase the records 201 of all authorized devices (but not delete the user content data or user keys 221, which may be stored in encrypted form on the configuration memory 115, separate from the entries 201 and other entries) if the recovery key is used to gain access but this is a policy decision.

[0087] Figure 3 The control flow 300 between the authorization device 111 and the access controller 102 according to one embodiment is shown. First, the authorization device 111 initiates the connection method by sending 301 its transmission public key. This step can be easily replayed by an attacker. The access controller 102 then replies 302 with a request for a certificate, and in response to the request, the authorization device 111 sends 303 the certificate previously obtained from the access controller 102 through the re-registration process.

[0088] Certificate

[0089] Figure 4 A certificate 400 is shown that is issued by a data storage device 100 and sent to the data storage device by an authorization device 111 to unlock the data storage device, according to one embodiment. In this example, the certificate 400 includes a plurality of type-length-value (TLV) fields, where the type value indicates the kind of field that is part of the certificate, the length is the size of the value field (usually in bytes), and the value is a variable-sized series of bytes that contains the data for that portion of the certificate.

[0090] The certificate 400 begins with a TLV atom which indicates the type of certificate that follows. This is called the certificate role 401 and has a 2-byte value to indicate that this is an authorized device certificate.

[0091] The certificate 400 belongs to a certificate chain. The access controller 102 uses the chain to verify and authenticate the certificate 400. In order to indicate which chain the certificate 400 belongs to, the certificate 400 has a 4-byte root certificate identifier (ID) 402. The certificate identifiers of each certificate in the certificate chain are the same. Unmatched certificate identifiers indicate invalid certificates. In one example, the root certificate identifier indicates whether the certificate chain is a production or development certification chain. In other examples, other groups may be indicated by corresponding certificate identifiers.

[0092] Certificate 400 also includes a 1-byte indicator of certificate depth 403. The depth of a certificate is defined as its distance from the root certificate within the certificate chain. The root certificate is defined to have a depth of zero. When processing a given certificate chain, the depth field is verified to ensure the integrity of the chain.

[0093] The certificate 400 also includes a 64-byte certificate transport public key 404 (e.g., according to the National Institute of Standards and Technology (NIST) P-256 elliptic curve). Each certificate is represented / indexed via the transport public key. Each type of public key will have its own dedicated tag type. That is, the tag type will represent the cipher suite used to generate the transport public key, such as the P-256 cipher suite.

[0094] The certificate 400 also includes a data field 405 (explained below) and is authenticated via a signature 406. The access controller 102 receives the certificate 400 and verifies the signature before trusting or using any of the contents of the certificate. To enable signature verification, a 64-byte signer public key 407 is provided as part of the certificate. The signature 406 itself is 64 bytes in length and is calculated over all previous TLVs 401-405, 407 encountered within the certificate, regardless of whether they are recognized by the specific implementation. More specifically, the signature 406 is derived from a hash of the certificate data. The specific data of the signature is certificate-related, but contains all TLVs used to represent the certificate, including unrecognized TLVs. The key used to generate the signature is a logical identity key and is associated with the signer public key 407.

[0095] Data field 405 includes slot number 410, which indicates the index of record 201 within configuration memory 115. Data field 405 also includes another copy of metadata encapsulation key 411 (in addition to Figure 2 The data field 405 is encrypted using the Authorized Device Slot Key (ADSK) 412, which is a 16-byte pseudo-random value stored in the configuration memory 115 and is used to encrypt the data in the Authorized Device Certificate so that only the issuing DSD 100 can recover the information.

[0096] Unlocking data storage devices

[0097] return Figure 3 If the authorizing device 111 wishes to unlock the DSD 100, the authorizing device 111 sends 303 to the access controller 102 a certificate 400 including the encrypted metadata wrapping key (MWK) 213 / 411. The certificate 400 also includes a slot number 410, which is an index of the record 201 in the configuration memory 115.

[0098] The access controller 102 decrypts 304 the data field 405 using the authorized device slot key stored in the configuration memory 115 and extracts the slot number and the metadata encapsulation key. The access controller 102 then queries the configuration memory 115 to read 305 the appropriate record 201 from the configuration memory 115 and decrypts 306 the authorized device metadata 205 using the metadata encapsulation key. This generates a temporary public key 211, which may also be referred to as an identifier of the authorized device, which uniquely identifies the authorized device because the temporary public key 211 is cryptographically associated with an unlocking private key stored only on the authorized device 111. The access controller 102 may perform additional checks 307, such as verifying that the transport public key 209 included in the authorized device metadata 205 matches the transport public key 404 provided in the certificate 400. In addition, the access controller 102 verifies the role 401 against a set of valid values ​​and associates the role with the connection. This means that the access controller 102 knows the current role (authorized device or manager device) for the duration of the connection. For example, the access controller 102 stores a parameter value indicating the role 401 provided in the certificate on a volatile memory. If any of the foregoing checks fail, the authorized device is considered revoked and an error is issued to that effect. Otherwise, the connection attempt is successful and the access controller 102 sends 308 a connection confirmation message to the authorized device 111.

[0099] At this stage, the authorization device 111 is connected and the unlocking process begins 319 by the authorization device 111 sending 320 an unlock request to the access controller 102. The unlock request includes an unlock public key associated with a private key stored on the secure hardware module of the authorization device. The access controller 102 matches 321 the received unlock public key with the unlock public key 212 stored in the authorization device metadata record 205. Next, the access controller 102 generates 322 a new blind value (also called an unlock blind key (UBK)), which is essentially a temporary private scalar and is randomly generated.

[0100] The access controller 102 then generates a challenge based on the identifier of the authorized device (e.g., the temporary public key 211) multiplied by the unlocking blind key (UBK). More specifically, the access controller 102 multiplies 323 the temporary public key 211 by the unlocking blind key, returning the complete X and Y coordinates of the result, noting that this operation is performed on an elliptic curve. The access controller 102 then sends 324 the X and Y coordinates to the authorized device 111 as a challenge. Note here that the challenge is based on the identifier of the authorized device 111 because the temporary public key is a factor of the multiplication that derives the challenge. Note also that for each unlock request (i.e., 320), a different unlocking blind key is generated to avoid man-in-the-middle attacks.

[0101] In addition, the access controller 102 calculates 325 the inverse of the unlocking blinding key (UBK -1 ). The access controller 102 may calculate the inverse of the unlocking blind key while waiting for a response from the authorization device 111.

[0102] The authorization device 111 calculates a response to the challenge by multiplying 326 the challenge by an unlock private key that is stored in a secure hardware module of the authorization device and corresponds to the unlock public key 212 stored on the configuration memory 115. This may involve the execution of a cryptographic primitive that may be executed entirely within a secure hardware module within the authorization device 111. The authorization device 111 then sends the result back in a response message 327. The access controller 102 multiplies 328 the returned result by the inverse of the unlock blinding key to calculate a temporary unlock secret (EUS) 223.

[0103] In mathematical notation, P represents the temporary public key, and k represents the Figure 3 The access controller 102 calculates 323 the product k*P and sends it 324 to the authorization device 111. The authorization device 111 multiplies 326 the challenge with the unlocking private key j to calculate j*k*P and returns 327 the result to the access controller 102. The access controller 102 compares the response to the inverse k of the unlocking blind key. -1 Multiply by 238 to calculate k -1 *j*k*P, which is equal to j*P (i.e., k -1 *j*k*P=k*k -1*j*P=j*P). The access controller 102 then decrypts 329 the user key 221 using j*P as a temporary unlocking secret (i.e., key). That is, the access controller 102 uses the temporary unlocking secret to decrypt the user key 221 stored on the DSD 100, which was encrypted using the temporary unlocking secret. More specifically, the access controller 102 decrypts 329 the user key, which then decrypts 330 the "user drive key", which is then ultimately sent 331 to the encryption engine 106 via a TCG command. That is, the user drive key may be generated by the access controller 102 using a key derivation function based on the user key. The user drive key is a TCG credential used to unlock the DSD 100, and may be equivalent to the "encryption key" described herein. In the case of Opal, this is the User2 credential.

[0104] Note that a temporary unlock secret is generated during the re-registration process by deriving a symmetric key from the results of an Elliptic Curve Diffie-Hellman process using an unlock private key and an unlock public key 212 stored on the authorized device 111. The resulting key is used to encrypt the user key 221, but is not stored in the DSD 100. Instead, the key is regenerated each time an authorized device requests unlocking of the DSD 100, as described above.

[0105] In another example, in the above formula, the unlock private key j can be replaced by the product of the unlock private key and a value derived from the pass code. The unlock private key will still be stored in the secure hardware module of the authorized device, but the unlock private key alone will not be able to decrypt the user content data stored on the DSD 100. Instead, the user needs to enter the pass code to calculate the response to the challenge and send 327 the response. This will simply replace j with the product of the pass code value and j above. The DSD will ignore this change because the temporary unlock secret 223 will be generated in the same manner as above from the perspective of the access controller 102.

[0106] Registration and Re-registration

[0107] Please note that Figure 2 The data record 201 shown is shown after the authorization device 111 has completed the re-registration process and is allowed to decrypt the encrypted user content data. Again, there are three steps in general: First, the manager device 110 registers the user device 111 once, making it one of the multiple authorization devices. Second, when connecting to the access controller 102 for the first time, the authorization device 111 re-registers once to complete the generation of the keys involved. Third, the authorization device 111 subsequently connects to the access controller 102 to unlock the DSD 100. This third step can occur multiple times.

[0108] During an (initial) registration step initiated by the manager device 110, the access controller 102 receives from the manager device 110 a public key corresponding to a private key stored on the user device 111. In response, the access controller 102 creates authorization data similar to Figure 2 1, except that the unlock public key 212 field holds the transmission public key 209 (as received from the manager device 110) since the unlock public key has not yet been generated. The access controller 102 generates a pre-authorization key 202, which is essentially an index used to locate the record 201. The pre-authorization key is generated by a key generation function using the x-coordinate of the received transmission public key 209 and a salt value. The salt value may be an authorized device slot key, which may be a 16-byte pseudo-random value generated during the "take ownership" process, stored on the configuration memory 115, and not shared with the authorized device. In this way, the salt may be different after each "factory reset", such as each time a manager device takes ownership of the DSD 100.

[0109] Creating the authorization data stored in record 201 also includes generating a metadata encapsulation key 222, such as by generating a 16-byte pseudo-random value. Access controller 102 stores the metadata encapsulation key in field 222. In addition, access controller 102 generates a temporary unlocking secret 223 and encrypts role 220 (e.g., authorized device), user key 221, and new metadata encapsulation key 222 using temporary unlocking secret 223. Access controller 102 then generates temporary public key 211 from temporary unlocking secret 223 and discards temporary unlocking secret 223.

[0110] Recall that during the (initial) registration step initiated by the manager device 110, the access controller 102 creates a Figure 2 Authorization data in data record 201. Figure 2 In contrast, the authorized device metadata 205 is not encrypted by a new metadata encapsulation key, but by a pre-authorized metadata encapsulation key, because the actual metadata encapsulation key 222 is not yet available to the authorized device 111. The pre-authorized metadata encapsulation key may be the same as the pre-authorized key 202 at this stage or generated separately. It should be noted that the pre-authorized metadata encapsulation key that now encrypts the authorized device metadata 205 may only be generated by the access controller 102, and not provided by the authorized device 111, because the authorized device 111 does not have access to the authorized device slot key used to generate the pre-authorized metadata encapsulation key.

[0111] Thus, in response to the authorization device 111 first connecting with the access controller 102, the authorization device 111 sends its transport public key to the access controller 102. The access controller 102 uses the transport public key and the stored authorization device slot key to generate the pre-authorization key 202. The access controller 102 may then search the configuration memory 115 for the pre-authorization key 202 to retrieve the record 201. The access controller 102 may also use the pre-authorization key as a pre-authorization metadata encapsulation key to decrypt the authorization device metadata 205.

[0112] As described above, the access controller 102 generates a challenge using the temporary public key 211 and the unlock blind key. The access controller 102 then creates the temporary unlock secret 223 from the response. Note that only the authorized device 111 with the private key corresponding to the transmission public key 209 can create a valid response. This means that even if an attacker disassembles the configuration memory 115 and reads the authorized device slot key to generate the pre-authorization metadata encapsulation key to decrypt the temporary public key 211, the attacker will still not be able to generate the temporary unlock secret 223.

[0113] The access controller 102 verifies the response by checking that the response acts as a temporary unlocking secret 223, and in response, updates the authorization data in the record 201. More specifically, the access controller 102 checks whether the field 212 for the unlocking public key is the same as the transmission public key 209. In response to the two being the same (as described above), the access controller 102 requests a new unlocking public key from the authorization device 111 and stores the returned key as the unlocking public key 212.

[0114] The access controller further decrypts the metadata encapsulation key 222 generated during registration by the manager device 110. At this stage, the access controller 102 may regenerate the temporary unlocking secret 223, the encryption role 220, the user key 221, and the metadata encapsulation key 222, regenerate and store the temporary public key 211, and discard the temporary unlocking secret 223. Finally, the access controller encrypts the authorized device metadata 205 using the metadata encapsulation key 222, and overwrites the pre-authorization key 202 with a random value so that the configuration memory 115 cannot be distinguished from random data even when holding the transmission public key and / or the unlocking public key. This ends the update and registration process of the authorization data stored in the record 201. Therefore, the authorized device 111, as one of the multiple authorized devices, is now allowed to decrypt the encrypted user content data through the above-mentioned unlocking step.

[0115] The above process involving creation and updating of authorization data enables multiple authorized devices to register using only their public keys during a first step of registration by manager device 110. In this way, there is no need to share secret information that could be intercepted and used to maliciously unlock the user's other devices.

[0116] Figure 5 A method 500 for protecting a wireless communication channel between a client device and a server device according to one embodiment is shown. The method 500 is performed by an access controller 102 and includes the access controller 102 repeatedly performing the following steps. The access controller 102 generates 501 a random value, such as by performing a pseudo-random function. The access controller 102 may also access an entropy source, such as physical random noise, such as thermal noise. Then, the access controller 102 calculates 502 a message authentication code based on the random value and the identity key. As described above, in response to being close to the data storage device 100, the manager device 110 is able to read the identity key. The identity key can be read out-of-band in the wireless communication channel. This means that the identity key is obtained through a channel different from the wireless communication channel. For example, the manager device 110 can obtain the identity key by reading a QR code or interrogating an NFC chip. Since both steps are only possible when the two devices are close, the availability of the identity key can be used as evidence of possession of the data storage device 100. In addition, the identity key enables the manager device 110 to verify the message authentication code based on the random value and the identity key, thereby authenticating the data storage device 100. Once the message authentication code is calculated, the access controller 102 broadcasts 503 an announcement packet over the wireless communication channel. The announcement packet includes a random value and a message authentication code calculated based on the random value and the identity key. The manager device 110 receives the announcement packet and can determine that it originated from the data storage device 110 due to the matching message authentication code, as described below.

[0117] Communication Protocol

[0118] Figure 6 A protocol 600 for protecting a communication channel between DSDs 100 according to one embodiment is shown. The DSDs 100 are also referred to as "server devices" 100, and the manager devices 110 are also referred to as "client devices". In some examples described herein, the communication channel of the protocol 600 is described with respect to Bluetooth Low Energy (BLE). However, the protocol 600 may be used over other transport mechanisms such as USB Human Interface Devices (HID), User Datagram Protocol (UDP) networks, and the like.

[0119] The protocol 600 is based on out-of-band communication of an identity key (IDK) from the server device 100 to the client device 110 at step 601. The identity key is stored in the configuration memory 115 of the server device 100 and is accessible by the client device 110 using an out-of-band channel, such as by scanning a QR code or reading an NFC chip, as described above.

[0120] At step 602, the access controller of the server device 100 repeatedly broadcasts announcement packets over the wireless communication channel. Each announcement packet includes a random value and a message authentication code (MAC) calculated based on the random value and the identity key. For example, the server device 100 calculates the MAC as a keyed hash of the random value or by encrypting the random value using the identity key. The random value may be selected uniformly at random or by simulating the output of a pseudo-random function of a given property. The announcement packet may also include a service identifier that identifies the server device 100 as supporting protocol 600. The address of the broadcast announcement packet may be selected uniformly at random because the address does not need to be used to parse the announcement packet of the server device 100.

[0121] Advantageously, the broadcast packets sent by the server device do not contain any identifying information that could be foreseen as malicious or eavesdropping third parties. In fact, third parties without the identity key will not be able to parse the broadcast packets, thereby negating any attempt to track the server device 100.

[0122] Once the client device 110 receives the announcement packet, at step 603, the client device verifies the received MAC based on the received random value and the identity key obtained at step 601, thereby parsing and authenticating the server device 100. More specifically, the client recalculates the MAC based on the random value and the identity key obtained out of band, and compares it with the received message authentication code. In other words, the client device 110 performs the same steps on the random value that the server device 100 has performed. In response to determining that the received MAC matches the recalculated MAC, the client device 110 has authenticated the server device 100. It should be noted that this initial authentication is possible without the server device 100 or the client device 110 having to provide any private information. Since the MAC is calculated using the identity key, only nearby client devices can recalculate the MAC. For all other devices, the announcement packet looks random. In the case where multiple servers send announcement packets and multiple identity keys are available, the client device 110 can try each identity key and attempt to recalculate the MAC. If it matches, the client device 110 has determined that the matching identity key is for the device with the matching MAC.

[0123] At step 603, the client device 110 uses the content of the announcement packet to parse the broadcasted announcement packet. The packets are called announcement packets because they generally announce the presence of the server device 100. This should not be confused with a specific BLE announcement packet according to the BLE standard. Although the BLE standard includes a resolvable private address that can be used here, the address of the BLE announcement packet is only 48 bits long (the random value is 24 bits and the resolution tag of the resolvable private address is 24 bits). In contrast, according to protocol 600, the BLE data packet provides enough space for 64 bits of random values ​​and 64 bits of message authentication codes. If the random value is randomly uniformly selected, the expected number of n-bit values ​​that must be collected in order to observe the collision of the random value is approximately 2^(n / 2). Therefore, the 24 bits of the resolvable private address in the BLE announcement packet encounter a collision approximately every 4000 random values, while the random value when using the BLE data packet encounters a collision approximately every 4 billion random values. This advantageously allows a client device 100 of the protocol 600 to more confidently confirm that a collision of random values ​​indicates that a given server is the same server as previously seen.

[0124] Upon successful verification and authentication of server device 100 at 603, client device 110 randomly generates a client nonce value at step 604 and sends it to server device 100 to connect to server device 100. In some embodiments, client device 110 additionally sends supplemental data to the server, such as supported cipher suites and / or protocol versions.

[0125] Upon receiving the client random value (and optionally supplemental data), server device 100 randomly generates and sends a server random value to client device 110 at step 605. In some embodiments, server device 100 additionally sends supplemental data to the client, such as a selected cipher suite and / or protocol version.

[0126] Advantageously, client device 110 is able to parse / identify the server device's broadcast packets and connect using the identity key obtained out-of-band. The connection process itself does not broadcast information that could be used by an adversary to identify server device 100 or client device 110.

[0127] Then, both the client device and the server device derive keys from the identity key, the client random value, the server random value, and optionally the supplemental data using standard key derivation functions. The supplemental data may be included to bind the resulting key material to a specific exchange process between the server device 100 and the client device 110. The resulting keys derived by both the client device 110 and the server device 100 may be used to encrypt data exchanges and establish an encrypted and secure communication channel.

[0128] Steps 601 to 607 do not facilitate any exchange of private information such as keys, device information, etc. between the server and the client device before authenticating the server device 100. However, it may be desirable to additionally conduct a second key exchange process encrypted by a derived key based on the server certificate in order to ensure that a trusted authority has assigned a given identity to the server device 100. This will prevent a malicious device (via an integrated NFC chip or QR code) from using a stolen identity key to impersonate a valid server device 100, thereby preventing the malicious device from successfully pairing with the client device 100.

[0129] To further authenticate the server device 100, the resulting keys derived at steps 606 and 607 are used to encrypt a second key exchange based on the server certificate. At step 608, the client requests a server certificate from the server device 100. The server certificate is stored in the data repository 105 of the server device 100 and is cryptographically linked to a root certificate of a trusted authority of the client device 110. The root certificate can be accessed by the client device, for example, through an application installed on the client device, the application being from an authenticated provider cryptographically associated with the root certificate.

[0130] At step 609, the server device 100 obtains the server certificate from the configuration memory 115, and cryptographically signs the identity key with the key verified by the server certificate to generate a signature. In other words, the certificate includes a public key for verifying the signature, and the signature can be cryptographically verified using the public key from the server certificate. In other embodiments, the server device 100 also generates a hash of the identity key and includes the hash in the certificate. This provides cryptographic binding between the connection verified by the certificate and the identity key obtained out of band, for example, by scanning a QR code. The hash may also include the values ​​of the client random number and the server random number in the record hash to be signed by the key verified by the server certificate to generate the signature.

[0131] Then, at step 610, the server device 100 sends the signature and the server certificate to the client device. The signature and the server certificate are encrypted using the keys derived in steps 606 and 607 to prevent other parties from intercepting the private data. At step 611, the client device 110 cryptographically verifies the server certificate against a root certificate accessible by the client device 110, and cryptographically verifies the signature of the identity key (or its hash) against the server certificate. In other words, the client device 110 computes a hash of the identity key obtained out-of-band and compares the computed hash with the hash provided in the certificate.

[0132] In verifying the signature and server certificate, the client device can ensure that the server device 100 is the only physical device that has been assigned a given identity key by a trusted authority. At step 612, the client device and the server device encrypt the communication channel using the verified signature to securely exchange data.

[0133] At this stage, the server device 100 may also issue a certificate to the client device 110 as described above, so that the client device can authenticate itself to the server device 100 .

[0134] Registering a Data Storage Device

[0135] Data port 103 registers as a block data storage device with host computer system 104. For example, a Universal Serial Bus (USB) device provides information in the form of a USB device descriptor. The USB device descriptor contains relevant information about the device. Therefore, in an embodiment where the data storage device is connected to the host computer system via a USB connection, the data storage device registers as a block data storage device with the host computer system by configuring its USB device descriptor to indicate that the data storage device is a block data storage device.

[0136] The USB device descriptor provides structured information about the USB device, such as the device class, supported protocols, device type, manufacturer, and other configuration parameters. The operating system of the host computer can obtain the USB device descriptor of the data storage device by sending various standard control requests (e.g., GET_DESCRIPTOR requests) to the data storage device. In response to receiving these requests, the data storage device provides the USB_DEVICE_DESCRIPTOR to the host computer system, thereby registering the data storage device as a block data storage device to the host computer system. The host computer interprets the USB_DEVICE_DESCRIPTOR to determine the configuration and capabilities of the data storage device. The host computer system can then store information about the data storage device in a register of the operating system of the host computer system.

[0137] It will be appreciated by those skilled in the art that many variations and / or modifications may be made to the above-described embodiments without departing from the broad general scope of the present disclosure. The embodiments of the present invention are therefore to be considered in all aspects as illustrative and not restrictive.

Claims

1. A data storage device, the data storage device comprising a data path, a data storage library and an access controller, wherein: The data path includes: a data port configured to transfer data between a host computer system and the data storage device via a data channel; a non-volatile storage medium configured to store encrypted user content data; and an encryption engine connected between the data port and the storage medium, wherein the encryption engine is configured to decrypt the encrypted user content data stored on the non-volatile storage medium using an encryption key in response to a request from the host computer system; the data repository is configured to store an identity key; and The access controller is configured to: Repeatedly broadcasting an announcement packet over a wireless communication channel different from the data channel, wherein: Each announcement packet includes a random value and a message authentication code calculated based on the random value and the identity key; The identity key is readable by the device to be connected close to the data storage device out-of-band of the data channel and the communication channel; and The identity key is configured to enable the device to be connected to verify the message authentication code based on the random value and the identity key, thereby verifying the data storage device; receiving a response based on the identity key and the message authentication code from the device to be connected; Based on the response, establishing a secure wireless communication channel with the device to be connected as a manager device; and The encryption key is generated in response to the manager device taking ownership of the data storage device.

2. The data storage device according to claim 1, wherein: The data repository is further configured to store a data storage device certificate, the data storage device certificate being configured to be cryptographically linked to a root certificate accessible by the to-be-connected device; and The access controller is further configured to: calculating a signature verified by the data storage device certificate; as well as The data storage device certificate and the signature are sent to the device to be connected, so that the device to be connected can authenticate the data storage device.

3. The data storage device of claim 2, wherein the data storage device certificate comprises a hash value of the identity key to bind the data storage device certificate to the data storage device, the identity key being readable out-of-band from the data storage device.

4. The data storage device according to claim 2, wherein: The root certificate is accessible by the device to be connected via an application installed on the device to be connected, the application being from an authenticated provider cryptographically associated with the root certificate.

5. The data storage device of claim 1, wherein an announcement address of the broadcast announcement packet is selected uniformly at random.

6. The data storage device according to claim 1, wherein: Each advertising packet also includes a service identifier of the data storage device; and The message authentication code is calculated based on the random value, the identity key, and the service identifier.

7. The data storage device of claim 1 , wherein the access controller is further configured to: receiving a first random value from the response of the device to be connected; generating a second random value; broadcasting the second random value via the wireless communication channel; deriving a derived encryption key from the identity key, the first random value, and the second random value using a key derivation function; as well as The wireless communication channel with the to-be-connected device is protected using the derived encryption key.

8. The data storage device of claim 1, wherein the communication channel uses a low power wireless communication protocol.

9. A data storage device according to claim 1, wherein the identity key can be read by the device to be connected through a quick response (QR) code attached to the data storage device or through a near field communication (NFC) tag integrated in the data storage device.

10. A client device comprising a processor and a memory, the memory comprising instructions executable by the processor, the instructions being for: receiving an identity key from a data storage device out-of-band over a wireless communication channel with the data storage device, wherein the data storage device comprises a data path comprising: a data port configured to transfer data between a host computer system and the data storage device via a data channel; a non-volatile storage medium configured to store encrypted user content data; and an encryption engine connected between the data port and the storage medium, wherein the encryption engine is configured to decrypt the encrypted user content data stored on the non-volatile storage medium using a user content encryption key in response to a request from the host computer system; receiving an announcement packet broadcast by the data storage device over the wireless communication channel, the announcement packet comprising a random value and a message authentication code calculated by the data storage device based on the random value and the identity key; verifying the message authentication code based on the random value and the identity key, thereby authenticating the data storage device; upon authenticating the data storage device, generating a derived encryption key based on the identity key to protect the wireless communication channel with the data storage device; as well as In response to establishing a secure wireless communication channel, taking ownership of the data storage device as a manager device, wherein the data storage device is configured to generate the user content encryption key in response to the manager device taking ownership of the data storage device.

11. The client device of claim 10, wherein the memory further comprises instructions executable by the processor to access a root certificate cryptographically linked to a certificate of the data storage device.

12. A method comprising: A random value is generated by a data storage device, wherein the data storage device comprises a data path, the data path comprising: a data port configured to transfer data between a host computer system and the data storage device via a data channel; a non-volatile storage medium configured to store encrypted user content data; and an encryption engine connected between the data port and the storage medium, wherein the encryption engine is configured to decrypt the encrypted user content data stored on the non-volatile storage medium using a user content encryption key in response to a request from the host computer system; The data storage device calculates a message authentication code based on the random value and the identity key, wherein: The identity key is readable by the device to be connected in close proximity to the data storage device out-of-band of a wireless communication channel between the device to be connected and the data storage device, and The identity key enables the device to be connected to verify the message authentication code based on the random value and the identity key, thereby authenticating the data storage device; The data storage device broadcasts an announcement packet through the wireless communication channel, wherein the announcement packet includes the random value and the message authentication code calculated based on the random value and the identity key; The data storage device receives a response based on the identity key and the message authentication code from the device to be connected; The data storage device, based on the response, establishes a secure wireless communication channel with the device to be connected as a manager device; and The user content encryption key is generated by the data storage device in response to the manager device taking ownership of the data storage device.

13. The method according to claim 12 further includes sending a data storage device certificate issued by the data storage device to the device to be connected in response to receiving a connection request from the device to be connected, the data storage device certificate including a hash value of the identity key to bind the data storage device certificate to the data storage device, and the identity key can be read from the data storage device out-of-band.

14. The method of claim 13, wherein the data storage device certificate is cryptographically linked to a root certificate accessible by the to-be-connected device.

15. The method according to claim 13, further comprising: The data storage device calculates a hash of the identity key, a random number received from the device to be connected, and the random value; as well as A signature of the hash is calculated by the data storage device based on the identity key and verified by the data storage device certificate.

16. The method according to claim 13, further comprising: Calculating, by the data storage device, a signature of the data storage device certificate; as well as The data storage device, in response to receiving the connection request from the device to be connected, sends the signature to the device to be connected.

17. The method of claim 16, wherein the signature is verified by the data storage device certificate by computing the signature using a private key, wherein the private key is verified by the data storage device certificate.

18. The method of claim 17, wherein the data storage device certificate includes a public key corresponding to the private key for use in verifying the signature.

19. The method according to claim 12, further comprising: The device to be connected receives from the data storage device: a data storage device certificate issued by the data storage device and a signature calculated by the data storage device based on the identity key and verified by the data storage device certificate; The device to be connected verifies the data storage device certificate against the root certificate; The device to be connected verifies the signature by comparing it with the data storage device certificate; as well as When the signature is verified by the device to be connected, the wireless communication channel with the data storage device is protected.

20. A data storage device comprising: processor; Memory; A data path, the data path comprising: a data port configured to transfer data between a host computer system and the data storage device via a data channel; a non-volatile storage medium configured to store encrypted user content data; and an encryption engine connected between the data port and the storage medium, wherein the encryption engine is configured to decrypt the encrypted user content data stored on the non-volatile storage medium using a user content encryption key in response to a request from the host computer system; means for generating random values; means for computing a message authentication code based on the random value and an identity key, wherein: The identity key is readable by the device to be connected in close proximity to the data storage device out-of-band of a wireless communication channel between the device to be connected and the data storage device, and The identity key enables the device to be connected to verify the message authentication code based on the random value and the identity key, thereby authenticating the data storage device; means for broadcasting an announcement packet over the wireless communication channel, wherein the announcement packet comprises the random value and the message authentication code calculated based on the random value and the identity key; Used to receive a response based on the identity key and the message authentication code from the device to be connected; means for establishing a secure wireless communication channel with the device to be connected as a manager device based on the response; and means for generating the user content encryption key in response to the manager device taking ownership of the data storage device.

Images