A processing method and apparatus

Abstract

The application discloses a processing method and device, the method comprises the following steps: in response to the connection between the second device and the first device, detecting the matching relationship between the second device and the first device; obtaining the decryption key corresponding to the matching relationship; based on the decryption key, decrypting the to-be-used key package corresponding to the matching relationship in the multiple key packages contained by the second device to obtain the target key; wherein, the multiple key packages use different encryption keys to encrypt the same target key; in response to the access request of the first device to the second device, based on the target key, encrypting or decrypting the data corresponding to the access request.

Description

Technical Field

[0001] This application relates to the field of computer technology, and in particular to a processing method and apparatus. Background Technology

[0002] Data access between devices typically relies on user-set passwords or keys for security. However, existing solutions often face the risk of permanent data loss or cumbersome key migration when users forget their credentials or change access devices, impacting the user experience. Summary of the Invention

[0003] The technical solution provided in this application is as follows:

[0004] The first aspect of this application provides a processing method, including:

[0005] In response to the connection between the second device and the first device, the matching relationship between the second device and the first device is detected;

[0006] Obtain the decryption key corresponding to the matching relationship;

[0007] Based on the decryption key, the key packet to be used corresponding to the matching relationship in the multiple key packets contained in the second device is decrypted to obtain the target key; wherein, the multiple key packets are obtained by encrypting the same target key using different encryption keys;

[0008] In response to the first device's access request to the second device, the data corresponding to the access request is encrypted or decrypted based on the target key.

[0009] In one possible implementation, the matching relationship includes a match between the second device and the first device;

[0010] The key packet to be used corresponding to the matching relationship includes: a first key packet; the first key packet is obtained by encrypting a first encryption key in a first key pair;

[0011] The decryption key corresponding to the matching relationship includes: the first decryption key in the first key pair;

[0012] The first key pair is generated locally by the first device, and the first decryption key is stored locally on the first device and cannot be transferred to other devices.

[0013] In one possible implementation, the matching relationship includes: there is no match between the second device and the first device;

[0014] The key packet to be used corresponding to the matching relationship includes: a second key packet; the second key packet is obtained by encrypting the second encryption key in the second key pair;

[0015] The decryption key corresponding to the matching relationship includes: the second decryption key in the second key pair;

[0016] The second key pair is generated by an application in the first device, and the second decryption key is stored in a third device other than the first device.

[0017] In one possible implementation, the second decryption key is encrypted with user account information and stored in a third device other than the first device;

[0018] Obtaining the decryption key corresponding to the matching relationship includes:

[0019] Obtain the second decryption key from a third device other than the first device;

[0020] Based on the user account information, the encrypted second decryption key is decrypted to obtain the second decryption key.

[0021] In one possible implementation, the processing method further includes:

[0022] In response to the first device failing to obtain the decryption key corresponding to the matching relationship, a third key package is selected from the plurality of key packages as the key package to be used; the third key package is encrypted based on the third encryption key in the third key pair generated by the security agent program in the first device; the third decryption key in the third key pair is not stored in the first device and the third device; the first device and the third device are used to store the decryption key corresponding to the matching relationship;

[0023] Output a prompt message to the user to obtain the third decryption key provided by the user;

[0024] Based on the third decryption key, the third key packet is decrypted to obtain the target key.

[0025] In one possible implementation, after decrypting the key packet to be used based on the decryption key to obtain the target key, the method further includes:

[0026] A fourth key pair is generated locally on the first device; the fourth key pair includes a fourth encryption key and a fourth decryption key;

[0027] The fourth decryption key is stored locally on the first device; the fourth decryption key cannot be transferred to other devices.

[0028] The target key is encrypted based on the fourth encryption key to obtain the fourth key packet;

[0029] Replace the first key packet in the second device with the fourth key packet.

[0030] In one possible implementation, detecting the matching relationship between the second device and the first device includes:

[0031] The system checks whether the external device identifier in the second device is consistent with the device identifier of the first device; the external device identifier is written when a binding relationship is established between the second device and the external device.

[0032] In one possible implementation, prior to detecting the matching relationship between the second device and the first device, the method further includes:

[0033] The first device initiates an authorization request to the second device, so that the second device obtains the host identifier from the authorization request, verifies whether the host identifier matches the authorization identifier stored in the second device, and if the verification is successful, the first device is allowed to access;

[0034] The host identifier is generated by the second device based on the device root key and the identifier information of the first device when the first device and the second device first connect.

[0035] In one possible implementation, the processing method further includes:

[0036] In response to the second device failing verification, a prompt message is output so that the user can enter a recovery key into the second device according to the prompt message. The second device then verifies the validity of the recovery key. If the verification is successful, the first device is allowed to access the device. The prompt message is used to prompt the user to enter a recovery key. The recovery key is generated by the second device and is used to verify the access rights of other devices.

[0037] In another aspect, this application provides a processing apparatus, comprising:

[0038] The detection module is used to detect the matching relationship between the second device and the first device in response to the connection between the second device and the first device;

[0039] The acquisition module is used to acquire the decryption key corresponding to the matching relationship;

[0040] The first decryption module is used to decrypt the key packet to be used, which corresponds to the matching relationship among multiple key packets contained in the second device, based on the decryption key, to obtain the target key; wherein the multiple key packets are obtained by encrypting the same target key using different encryption keys;

[0041] The processing module is configured to, in response to the access request from the first device to the second device, encrypt or decrypt the data corresponding to the access request based on the target key. Attached Figure Description

[0042] The above and other features, advantages, and aspects of the embodiments of this disclosure will become more apparent from the accompanying drawings and the following detailed description. Throughout the drawings, the same or similar reference numerals denote the same or similar elements. It should be understood that the drawings are schematic, and the originals and elements are not necessarily drawn to scale.

[0043] Figure 1 This is a schematic flowchart of a processing method provided in Embodiment 1 of this application;

[0044] Figure 2 A schematic diagram illustrating an implementation scenario of the processing method provided in this application;

[0045] Figure 3 A schematic diagram illustrating another implementation scenario of the processing method provided in this application;

[0046] Figure 4 A schematic diagram illustrating another implementation scenario of the processing method provided in this application;

[0047] Figure 5 This is a flowchart illustrating a processing method provided in Embodiment 5 of this application;

[0048] Figure 6 A schematic diagram illustrating another implementation scenario of the processing method provided in this application;

[0049] Figure 7 is a schematic diagram of a security architecture provided in this application;

[0050] Figure 8 A schematic diagram for initial use provided in this application;

[0051] Figure 9 A schematic diagram illustrating another implementation scenario of the processing method provided in this application;

[0052] Figure 10 A schematic diagram illustrating another implementation scenario of the processing method provided in this application;

[0053] Figure 11 This is a schematic diagram of a state transition provided in this application. Detailed Implementation

[0054] The embodiments of this application are described below with reference to the accompanying drawings. The terminology used in the implementation section of this application is for explaining specific embodiments only and is not intended to limit the scope of this application.

[0055] The embodiments of this application will now be described with reference to the accompanying drawings. Those skilled in the art will recognize that, with technological advancements and the emergence of new scenarios, the technical solutions provided in the embodiments of this application are equally applicable to similar technical problems.

[0056] The terms "first," "second," etc., used in this application are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such terms can be used interchangeably where appropriate; this is merely a way of distinguishing objects with the same attributes in the embodiments of this application. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover non-exclusive inclusion, so that a process, method, system, product, or apparatus that comprises a series of units is not necessarily limited to those units, but may include other units not explicitly listed or inherent to those processes, methods, products, or apparatuses.

[0057] In the embodiments of this application, reference is made to Figure 1 This is a flowchart illustrating a processing method provided in Embodiment 1 of this application, as shown below. Figure 1 As shown, the method may include, but is not limited to, the following steps:

[0058] Step S101: In response to the connection between the second device and the first device, detect the matching relationship between the second device and the first device.

[0059] The first device can be an electronic device with data processing capabilities, such as a personal computer, laptop, tablet, or smartphone.

[0060] The second device can be an external storage device (such as a USB flash drive, portable hard drive, solid-state drive, etc.), a mobile AI peripheral (such as an AI accelerator stick, smart camera, etc.), or other external devices that need to access data through the first device.

[0061] When the second device establishes an authorization relationship with the first device for the first time, the first device can first generate a target key. This target key is used to encrypt and decrypt data exchanged between the first device and the second device.

[0062] As one implementation, the target key can be generated in the secure execution environment of the first device (such as a virtualization-based secure enclave) to ensure the confidentiality of the target key during the generation process.

[0063] Once the target key is generated, it can be securely stored in a second device for later retrieval. However, if the target key is stored directly in plaintext on the second device, it risks being leaked should the second device be compromised. Therefore, the target key must be encrypted before storage.

[0064] Furthermore, considering that the second device may have different matching relationships when connected to different first devices. For example, when the second device connects to the current first device again, there is an established authorization relationship between the two, which is a matched state; when the second device connects to another first device with which no authorization relationship has been established, there is no authorization relationship between the two, which is a mismatched state.

[0065] To securely recover the same target key under various matching relationships, the first device can pre-generate multiple different key pairs based on the possible matching relationships. Each key pair contains an encryption key and a decryption key; the encryption keys and decryption keys in different key pairs are different from each other. Subsequently, the first device uses the encryption keys from these key pairs to encrypt the same target key, thereby generating multiple different key packets. Accordingly, each key packet requires a decryption key belonging to the same key pair as its encryption key to be decrypted.

[0066] The decryption key can be stored in different locations according to its corresponding matching relationship, so that the first device can obtain the corresponding decryption key according to the corresponding storage location under different matching relationships.

[0067] Multiple key packets can be written to and stored in a second device. Simultaneously, key data structure information, used to describe and organize the multiple key packets, can be stored in the second device.

[0068] Key data structure information may include, but is not limited to: identifiers (such as Magic identifiers, e.g., "EXTS") for identifying key data structure information, version numbers for identifying key data structure information, algorithm identifiers for identifying encryption and hash algorithms, and capsule arrays (Capsules[]) for indicating the storage locations of multiple key packets. The capsule arrays record the storage location of each type of key packet and its corresponding encryption method.

[0069] In addition, the key data structure information may also include a hash value used for integrity verification.

[0070] In this embodiment, the first device may pre-install a security agent program, which runs as a system-level service when the operating system starts, or it may be triggered to start after the second device connects to the first device.

[0071] The security agent program can also be pre-stored in the second device. When the second device is connected to the first device, the security agent program can be loaded from the second device and started running on the first device, so that the first device, which does not have the security agent program installed, can also obtain security protection capabilities.

[0072] By running a security agent program, it is possible to detect whether the second device stores key data structure information in a specific format (such as metadata including Magic identifier, version number, algorithm identifier, etc.). If the key data structure information in the specific format is stored, the second device can be determined to be an encrypted device; if the specific data structure is not present in the second device, the second device can be determined to be an unencrypted device.

[0073] If the second device is an encrypted device, the matching relationship between the second device and the first device can be detected through a security proxy program.

[0074] Step S102: Obtain the decryption key corresponding to the matching relationship.

[0075] In this embodiment, there is a correspondence between the storage location of the decryption key and the matching relationship. Specifically, different matching relationships correspond to different decryption key storage locations because when the second device first establishes an authorization relationship with the first device, the first device stores the corresponding decryption key in different locations for different matching relationships.

[0076] For example, when the matching relationship is in a matching state, the corresponding decryption key is stored in the first location, and the first device can directly obtain the decryption key from this first location without relying on external devices or networks. When the matching relationship is in a mismatch state, the corresponding decryption key is stored in the second location, and the first device needs to be verified before it can obtain the decryption key from this second location.

[0077] When the matching relationship is in a matching state, it indicates that a trust relationship has been established between the first device and the second device. The first device is authorized to access the data in the second device. Therefore, the decryption key can be stored in a location that the first device can directly access, so that the decryption key can be quickly and seamlessly obtained during subsequent connections, thus improving the user experience.

[0078] When the matching relationship is in a mismatch state, it indicates that a trust relationship has not been established between the first device and the second device, and the first device is not authorized to directly access the data in the second device. Therefore, the decryption key needs to be stored in a location that requires verification to access, in order to prevent unauthorized devices from arbitrarily obtaining the decryption key and to ensure data security.

[0079] After obtaining the decryption key, the security agent program transmits the decryption key to the secure execution environment (such as a virtualization-based secure enclave) of the first device so that the decryption key can be used in the secure execution environment for subsequent decryption operations.

[0080] In this way, while ensuring security, a secure proxy program is used to achieve differentiated acquisition of decryption keys under different matching relationships.

[0081] Step S103: Based on the decryption key, decrypt the key packet to be used that corresponds to the matching relationship among the multiple key packets contained in the second device to obtain the target key; wherein, the multiple key packets are obtained by encrypting the same target key using different encryption keys.

[0082] After obtaining the decryption key corresponding to the matching relationship, the security agent program can determine the key packet type corresponding to the detected matching relationship.

[0083] After determining the key packet type, the security agent can obtain a capsule array from the key data structure information of the second device. This capsule array records the storage location of each type of key packet and its corresponding encryption method. Based on the determined key packet type, the security agent finds the storage location of that type of key packet in the capsule array and reads the corresponding key packet from that storage location as the key packet to be used.

[0084] After obtaining the key packet to be used, the security agent program can transmit it to the secure execution environment. In the secure execution environment, the key packet is decrypted using a decryption key. The resulting target key also resides within the secure execution environment and is not exposed to any modules outside of it.

[0085] Step S104: In response to the first device's access request to the second device, encrypt or decrypt the data corresponding to the access request based on the target key.

[0086] In an implementation where the access request is a write request, the first device can use the target key to encrypt the plaintext data to be written, generate ciphertext data, and then write it to the second device.

[0087] In an implementation where the access request is a read request, the first device can read the encrypted data from the second device, decrypt it using the target key, restore it to plaintext data, and then provide it to the user.

[0088] In this embodiment, the kernel filter driver in the first device can intercept access requests to the second device. When a write request is intercepted, the kernel filter driver can send the plaintext data to be written to a secure execution environment (such as a virtualization-based secure enclave). The secure execution environment uses the target key to encrypt the plaintext data, generates ciphertext data, and returns it to the kernel filter driver, which then writes the ciphertext data to the second device.

[0089] When a read request is intercepted, the kernel filter driver reads the ciphertext data from the second device and sends the ciphertext data to the secure execution environment. The secure execution environment decrypts the ciphertext data using the target key, generates plaintext data, and returns it to the kernel filter driver, which then provides the plaintext data to the upper-layer application.

[0090] Throughout the encryption and decryption process, the plaintext of the target key resides within the secure execution environment and is never exposed to any modules outside of it (including kernel filter drivers and security agents). The kernel filter driver is only responsible for the movement and physical reading / writing of plaintext and ciphertext data, and does not access the target key itself. This ensures the security of the target key; even if an attacker gains kernel privileges, they cannot steal the plaintext of the target key.

[0091] In this embodiment, based on the fact that the second device pre-stores multiple key packets, each of which is encrypted with the same target key, regardless of which first device the second device connects to, the first device can automatically detect the matching relationship with the second device, determine the storage location of the decryption key based on the matching relationship, obtain the decryption key, select the corresponding key packet, and decrypt it to restore the target key. Then, based on the target key, the accessed data is encrypted and decrypted. Users do not need to remember or manage any passwords or keys, nor do they need to perform any manual operations or complex configuration processes. All key generation, storage, acquisition, decryption, and data encryption / decryption are automatically completed by the security agent program in the first device, achieving a seamless protection experience.

[0092] Meanwhile, the plaintext of the target key always resides in the secure execution environment. Decrypting the key packet and subsequent encryption / decryption operations on accessed data are all performed within this secure execution environment, ensuring that the plaintext of the target key is never exposed to any module outside of it. Through this protection mechanism, even if an attacker gains physical access to the second device and system privileges on the first device, they cannot steal the plaintext of the target key, thus guaranteeing the security of the target key and consequently ensuring the confidentiality of data exchanged between the first and second devices.

[0093] As another optional embodiment of this application, a processing method is provided for Embodiment 2 of this application. This embodiment is mainly an implementation of the matching relationship in Embodiment 1 above, and may specifically include, but is not limited to:

[0094] The second device and the first device are matched. That is, the second device has previously established an authorization relationship with the current first device. When the second device connects to the same first device again, the first device can recognize that the second device is a device it has previously authorized, and an established trust relationship exists between the two.

[0095] In this embodiment, the key packet to be used corresponding to the matching relationship may include: a first key packet; the first key packet may be obtained by encrypting based on the first encryption key in the first key pair.

[0096] The decryption key corresponding to the matching relationship includes: the first decryption key in the first key pair.

[0097] The first key pair is generated locally by the first device, and the first decryption key is stored locally on the first device and cannot be transferred to other devices.

[0098] When the second device establishes an authorization relationship with the first device for the first time, the first device's motherboard security chip can generate a first key pair within the hardware security area. The first key pair may include a first encryption key (which may be represented as a DBK public key) and a first decryption key (which may be represented as a DBK private key).

[0099] The first device can encrypt the target key (which can be represented as EVK) using the first encryption key to generate a first key packet, and then write the first key packet into the second device for storage.

[0100] The initial decryption key can be stored inside the motherboard security chip of the first device. The motherboard security chip has hardware-level security protection mechanisms to ensure that the initial decryption key cannot be exported or copied to other devices.

[0101] like Figure 2 As shown, when the second device connects to the same first device again (i.e., in the local usage scenario), the kernel filter driver detects the insertion of the second device, reads the key data structure information in the second device's header, identifies it as an encrypted second device, and then notifies the security agent program. The security agent program, based on the detected matching relationship (i.e., matching status), determines that the key packet type corresponding to that matching relationship is the first key packet. The security agent program retrieves the storage location of the first key packet (which can be represented as A) from the capsule array of the key data structure information and reads the first key packet from that location.

[0102] Subsequently, the security agent program of the first device can determine whether to communicate with the motherboard security chip based on the matching relationship. The security agent program initiates a decryption request to the motherboard security chip and transmits the first key packet to the motherboard security chip. The motherboard security chip transmits its internally stored first decryption key (i.e., the DBK private key) to the secure enclave. Within the secure enclave, the first key packet A is decrypted based on the first decryption key to obtain the target key, thereby unlocking the volume.

[0103] After the secure enclave obtains the target key, it notifies the security agent program of successful decryption. The security agent program then instructs the kernel filter driver to complete the file system mounting, making the second device appear as a normally accessible drive letter in the operating system. Users can see the drive letter in File Explorer and perform file operations. For users, this mounting process is transparent, allowing the system to use the device without any manual intervention. However, the data stored on the second device remains in encrypted form, and all subsequent read and write operations still require real-time encryption and decryption processing to access the actual data.

[0104] After mounting is complete, when a user or application initiates a read / write request for the second device, the kernel filter driver intercepts the write request and sends the plaintext data to be written to the secure enclave. The secure enclave uses the target key to encrypt the plaintext data, generates ciphertext data, and returns it to the kernel filter driver, which then writes the ciphertext data to the second device.

[0105] When a read request is intercepted, the kernel filter driver reads the encrypted data from the second device and sends it to the secure enclave. The secure enclave decrypts the encrypted data using the target key, generates plaintext data, and returns it to the kernel filter driver, which then provides the plaintext data to the upper-layer application. The entire encryption and decryption process is completely transparent to the upper-layer application and the user; the user can read and write user data on the second device normally without performing any manual operations.

[0106] Throughout the entire process, the plaintext of the target key resides in the memory of the secure enclave and is never persistently stored in plaintext on any non-volatile storage medium (such as hard drives, flash memory, etc.) of the first device. When the second device disconnects from the first device, the target key in the secure enclave is destroyed and no longer retained. When the second device reconnects to the first device, the decryption process needs to be re-executed, reading the first key packet from the second device and decrypting it again using the first decryption key to obtain the target key. In this way, the target key only exists temporarily in the memory of the secure enclave during the connection with the second device and is cleared after the connection is broken, enhancing the security of the target key.

[0107] In this embodiment, since the target key is encrypted and stored on the second device in the form of a first key packet, rather than stored locally on the first device, substantial isolation between the target key and the first device is achieved. In this embodiment, the target key is encrypted and stored on the second device, and the motherboard security chip of the first device only needs to manage one device binding key (i.e., the first decryption key in the first key pair). This device binding key is used to decrypt the first key packet to recover the target key. Because the target key itself is not persistently stored locally on the first device, even if the first device is used by multiple different users, it is not necessary to manage different target keys for each user, thereby simplifying the key management complexity on the first device side.

[0108] Of course, in specific implementation, this embodiment can also be combined with binding to a specific user account. For example, when generating the first key package, in addition to using the first encryption key for encryption, user account information is further associated as an additional encryption factor, so that even if the first decryption key is obtained, user account information is required to decrypt the first key package, thereby achieving dual binding of device and account and further enhancing security.

[0109] In this embodiment, since the first decryption key is non-transferable, only the original first device that generated the first key pair can use it. When the second device reconnects to the original first device, the first device can obtain the first decryption key locally and decrypt the first key packet in the second device to recover the target key.

[0110] In the above manner, in a local usage scenario, the first device can directly obtain the first decryption key from the local device without relying on external devices or networks, and without requiring the user to enter any password or perform any manual operation. This allows for quick and seamless recovery of the target key, thereby enabling encryption and decryption operations on the data in the second device.

[0111] For example, a user copies a batch of work files using a USB flash drive at work (i.e., an implementation of a second device). Upon returning home, the user inserts the USB flash drive into their home computer (i.e., an implementation of a first device). Since the home computer has previously established an authorization relationship with the USB flash drive, when the USB flash drive is inserted, the security agent program on the home computer automatically detects that the matching relationship is successful and identifies the corresponding key package to be used as the first key package. The security agent program reads the first key package from the key data structure information of the USB flash drive and obtains the first decryption key from the security chip on the home computer's motherboard. Within the secure enclave, it uses the first decryption key to decrypt the first key package, restoring the target key. Subsequently, the home computer completes the mounting of the encrypted file system. The user can then see the USB flash drive in File Explorer and read and write files normally without entering any password or performing any manual operations.

[0112] For example, a user possesses an AI accelerator stick (an implementation of a second device) containing encrypted AI model parameters and an inference engine. This AI accelerator stick has established authorization relationships with both the user's desktop computer and laptop computer. Each time an authorization relationship is established, the corresponding first device encrypts the target key using its locally generated first encryption key, generating its own first key packet, which is then stored in the AI ​​accelerator stick. Therefore, the AI ​​accelerator stick stores two different first key packets, corresponding to the desktop computer and the laptop computer respectively.

[0113] One day, a user unplugged the AI ​​accelerator stick from their desktop computer and connected it to their laptop. When the AI ​​accelerator stick was plugged in, the laptop's security agent automatically detected a match, identifying the corresponding key packet as the first key packet previously generated and stored in the AI ​​accelerator stick. The security agent read this first key packet from the AI ​​accelerator stick's key data structure and retrieved the laptop's own first decryption key from the motherboard's security chip. Within a secure enclave, the agent used this first decryption key to decrypt the first key packet, restoring the target key. Subsequently, the laptop mounted the encrypted file system, allowing the user to use the AI ​​accelerator stick for AI inference tasks without any manual intervention.

[0114] In this embodiment, each authorized first device uses its own independently generated first key pair and manages its own decryption key, without affecting each other.

[0115] As another optional embodiment of this application, this is a processing method provided in embodiment 3 of this application. This embodiment is mainly an implementation of the matching relationship in embodiment 1 above, and may specifically include, but is not limited to: the second device and the first device are not matched.

[0116] The key packet to be used corresponding to the matching relationship may include: a second key packet; the second key packet is obtained by encrypting the second encryption key in the second key pair.

[0117] The decryption key corresponding to the matching relationship may include: the second decryption key in the second key pair.

[0118] The second key pair is generated by an application in the first device, and the second decryption key is stored in a third device other than the first device.

[0119] In this embodiment, when the second device establishes an authorization relationship with a first device for the first time, the application in the first device (such as a security agent) can generate a second key pair, which includes a second encryption key (which can be represented as an ARK public key) and a second decryption key (which can be represented as an ARK private key).

[0120] The first device uses the second encryption key to encrypt the target key, generates a second key packet, and writes the second key packet into the second device for storage.

[0121] The second decryption key is stored in a third device other than the first device. This third device can be a cloud server, or other forms of trusted storage devices or services, such as a shared storage device on the same local area network as the first device, a mobile device (such as a mobile phone) paired with the first device, or other trusted computing devices accessible to the first device. The first device needs to be verified before it can obtain the second decryption key from the third device. The verification method can be user authentication, device verification, or other forms of authorization verification; this embodiment does not impose any restrictions on this.

[0122] In some implementations, if a trust relationship has been established between the third device and the first device (e.g., they are in the same trusted network environment or have passed device pairing authentication), the first device can directly obtain the second decryption key from the third device without additional authentication steps.

[0123] like Figure 3 As shown, based on the new first device login security agent program, when the second device connects to the first device with which it has not established an authorization relationship (i.e., a new first device relative to the first device with which it has established an authorization relationship) (i.e., a device replacement recovery scenario), the kernel filter driver detects the insertion of the second device, reads the key data structure information in the second device's header, identifies it as an encrypted second device, and then notifies the security agent program. The security agent program attempts to decrypt the first key packet using the first decryption key in the first device's local motherboard security chip, but decryption fails. Based on the decryption failure result, the security agent program determines that the matching relationship is in a mismatch state.

[0124] The security agent determines the key packet type corresponding to the detected matching relationship (i.e., mismatch status) as the second key packet. The security agent obtains the storage location of the second key packet (which can be represented as B) from the capsule array of key data structure information and reads the second key packet from that location.

[0125] Subsequently, the security agent program determines that the decryption key corresponding to the matching relationship is the second decryption key, and determines that this second decryption key is stored in a third device other than the first device. The security agent program displays an authentication interface to the user. After the user submits their credentials, the security agent program initiates an authentication request to the third device through an encrypted channel. After the third device verifies the user's identity and the device's legitimacy (i.e., authentication is successful), it sends the second decryption key to the security agent program.

[0126] The security agent program transmits the second decryption key to the secure enclave, and at the same time transmits the second key packet to the secure enclave. Within the secure enclave, the second decryption key is used to decrypt the second key packet B, restore the target key, and unlock the volume.

[0127] After the secure enclave obtains the target key, it notifies the security agent program of successful decryption. The security agent program then instructs the kernel filter driver to complete the mounting of the encrypted file system, making the second device appear as a normally accessible drive letter in the operating system. For the user, this mounting process is transparent and readily available to the system; the user can see the drive letter and begin using it without any manual intervention. However, the data stored on the second device remains in encrypted form, and all subsequent read and write operations still require real-time encryption and decryption processing to access the actual data.

[0128] After mounting, since the target key obtained by decryption using the second key packet in this embodiment is the same as the target key obtained by decryption using the first key packet in the previous embodiment, the subsequent read / write request processing is exactly the same as the local usage scenario in Embodiment 2. That is, regardless of whether the first device is an authorized device (i.e., a matching device) or an unauthorized device (i.e., a mismatch), as long as the target key is successfully restored, the same target key will be used for subsequent encryption and decryption operations on the data in the second device, and the user experience will be completely consistent.

[0129] Specifically, when a user or application initiates a read / write request to the second device, the kernel filter driver intercepts the write request and sends the plaintext data to be written to the secure enclave. The secure enclave encrypts the plaintext data using the target key, generates ciphertext data, and returns it to the kernel filter driver, which then writes the ciphertext data to the second device. When a read request is intercepted, the kernel filter driver reads the ciphertext data from the second device and sends it to the secure enclave. The secure enclave decrypts the ciphertext data using the target key, generates plaintext data, and returns it to the kernel filter driver, which then provides the plaintext data to the upper-layer application. The entire encryption and decryption process is completely transparent to the upper-layer application and the user; the user can read and write user data on the second device normally without performing any manual operations.

[0130] Throughout the entire process, the plaintext of the target key resides in the memory of the secure enclave and is not persistently stored in plaintext on any non-volatile storage medium of the first device. When the second device disconnects from the first device, the target key in the secure enclave is destroyed and no longer retained.

[0131] In this embodiment, when the second device connects to the first device with which no authorization relationship has been established, the first device can automatically detect a mismatch and determine the corresponding second key packet and second decryption key based on this mismatch. The first device initiates a verification request to the third device, obtains the second decryption key after authentication, and achieves secure migration of the second decryption key in the device replacement and recovery scenario. Furthermore, within a secure enclave, the second decryption key is used to decrypt the second key packet, thereby restoring the target key and ensuring its security. Throughout the entire process, the user only needs to perform one authentication operation, without manually managing keys or executing complex configuration procedures, to restore access to the second device on the new device.

[0132] Furthermore, since the target key obtained by decrypting through the second key packet is the same as the target key obtained by decrypting through the first key packet, regardless of whether the first device is an authorized device or an unauthorized device, as long as the target key is successfully restored, subsequent encryption and decryption operations on the data in the second device will all use the same target key, ensuring a completely consistent user experience and achieving a seamless cross-device access experience.

[0133] For example, a user initializes and encrypts a USB flash drive (a second implementation of the device) using their office computer (an implementation of the first device), and the USB flash drive contains encrypted work files. One day, the user takes the USB flash drive home and inserts it into their personal computer (another implementation of the first device). Since the personal computer has never previously established an authorization relationship with the USB flash drive, the security agent program on the personal computer automatically detects a mismatch when the USB flash drive is inserted. The security agent program attempts to decrypt the first key package on the USB flash drive using the first decryption key in the security chip on the personal computer's motherboard, but the decryption fails, confirming the mismatch.

[0134] The security agent program then identifies the corresponding key package to be used as the second key package and reads it from the key data structure information on the USB drive. Simultaneously, the security agent program identifies the corresponding decryption key as the second decryption key and confirms that this second decryption key is stored on the cloud server. The security agent program displays an authentication interface to the user. After the user enters their account credentials, the security agent program initiates an authentication request to the cloud server through an encrypted channel. After the cloud server successfully verifies the user's identity, it sends the second decryption key to the security agent program.

[0135] The security agent transmits the second decryption key and the second key packet to a secure enclave. Within the secure enclave, the second decryption key is used to decrypt the second key packet, restoring the target key. Then, in response to a personal computer's access request to the USB drive, the data corresponding to the access request can be encrypted or decrypted based on the target key.

[0136] As another optional embodiment of this application, this embodiment provides a processing method for embodiment 4 of this application. This embodiment is mainly an implementation of the second decryption key in embodiment 3 above. In this embodiment, the second decryption key may be, but is not limited to, being encrypted with user account information and stored in a third device other than the first device.

[0137] In this embodiment, the second decryption key is not stored directly in the third device in plaintext form. Instead, it is first encrypted using the user account information as the encryption factor to generate the encrypted second decryption key, and then the encrypted second decryption key is stored in the third device.

[0138] The third device only holds the encrypted second decryption key ciphertext, but not the plaintext of the second decryption key, nor the user account information used for decryption.

[0139] User account information can be the user's login password, biometric information (such as fingerprints or faces), dynamic codes generated by hardware tokens, or other credentials that can be used for identity verification. This embodiment does not impose any restrictions on this.

[0140] Step S102 above may include, but is not limited to, the following steps:

[0141] Step S1021: Obtain the second decryption key from a third device other than the first device.

[0142] In this embodiment, there can be multiple acquisition methods, and this application does not limit the acquisition method. For example, one method is that the security agent program directly sends an acquisition request to the third device. After receiving the request, the third device directly returns the encrypted second decryption key to the security agent program without additional identity authentication steps, because the decryption process relies on user account information. Even if the encrypted second decryption key is obtained by others, they will not be able to decrypt it.

[0143] Another approach is for the security agent program to first send an authentication request to the third device. The third device then verifies the user's identity and / or the device's legitimacy on the first device. Once the verification is successful, the third device sends the encrypted second decryption key to the security agent program.

[0144] Step S1022: Based on the user account information, decrypt the encrypted second decryption key to obtain the second decryption key.

[0145] The secure agent can transmit the encrypted second decryption key to a secure enclave. Within the secure enclave, the user account information is used as the decryption key to decrypt the encrypted second decryption key.

[0146] During the decryption process, the plaintext of the user account information and the plaintext of the second decryption key obtained from the decryption are both stored inside the secure enclave and are not exposed to any module outside the secure enclave.

[0147] After successful decryption, the second key packet can be decrypted within the secure enclave using the second decryption key.

[0148] In this embodiment, combined with Figure 4 The process of obtaining the second decryption key is explained. For example... Figure 4 As shown, based on the new first device login security agent program, when the second device connects to the first device with which it has not established an authorization relationship (i.e., a new first device relative to the first device with which it has established an authorization relationship) (i.e., a device replacement recovery scenario), the kernel filter driver detects the insertion of the second device, reads the key data structure information in the second device's header, identifies it as an encrypted second device, and then notifies the security agent program. The security agent program attempts to decrypt the first key packet using the first decryption key in the first device's local motherboard security chip, but decryption fails. Based on the decryption failure result, the security agent program determines that the matching relationship is in a mismatch state.

[0149] The security agent determines the key packet type corresponding to the detected matching relationship (i.e., mismatch status) as the second key packet. The security agent obtains the storage location of the second key packet (which can be represented as B) from the capsule array of key data structure information and reads the second key packet from that location.

[0150] Subsequently, the security agent program determines the decryption key corresponding to the matching relationship as the second decryption key, and determines that the second decryption key is stored in encrypted form on a third device other than the first device. The security agent program initiates a request to the third device through an encrypted channel to obtain the encrypted second decryption key from the third device. In some implementations, the third device may first authenticate and verify the legitimacy of the first device before returning the encrypted second decryption key; in other implementations, the third device may directly return the encrypted second decryption key without additional authentication steps, because the decryption process relies on user account information, and even if the encrypted second decryption key is obtained by others, decryption will not be possible.

[0151] The security agent program transmits the encrypted second decryption key to the security enclave, and at the same time transmits the second key packet to the security enclave. Within the security enclave, the encrypted second decryption key is decrypted based on the user account information. Then, the second decryption key is used to decrypt the second key packet B to restore the target key and unlock the volume.

[0152] After the secure enclave obtains the target key, it notifies the security agent program of successful decryption. The security agent program then instructs the kernel filter driver to complete the mounting of the encrypted file system, making the second device appear as a normally accessible drive letter in the operating system. For the user, this mounting process is transparent and readily available to the system; the user can see the drive letter and begin using it without any manual intervention. However, the data stored on the second device remains in encrypted form, and all subsequent read and write operations still require real-time encryption and decryption processing to access the actual data.

[0153] After mounting, when a user or application initiates a read / write request to the second device, the kernel filter driver intercepts the write request. Upon receiving the write request, the kernel filter driver sends the plaintext data to be written to the secure enclave. The secure enclave encrypts the plaintext data using the target key, generating ciphertext data, which is then returned to the kernel filter driver. The kernel filter driver then writes the ciphertext data to the second device. When a read request is intercepted, the kernel filter driver reads the ciphertext data from the second device and sends it to the secure enclave. The secure enclave decrypts the ciphertext data using the target key, generating plaintext data, which is then returned to the kernel filter driver. The kernel filter driver then provides the plaintext data to the upper-layer application. The entire encryption / decryption process is completely transparent to the upper-layer application and the user; the user can read and write user data on the second device normally without any manual operation.

[0154] Throughout the entire process, the plaintext of the target key resides in the memory of the secure enclave and is not persistently stored in plaintext on any non-volatile storage medium of the first device. When the second device disconnects from the first device, the target key in the secure enclave is destroyed and no longer retained.

[0155] In this embodiment, the second decryption key is not stored directly in plaintext on the third device. Instead, it is first encrypted using the user account information as an encryption factor to generate the encrypted second decryption key before being stored on the third device. Even if the third device is compromised and data is leaked, the attacker will only obtain the encrypted second decryption key ciphertext. Without the user account information, the attacker cannot decrypt the plaintext used to obtain the second decryption key, thus ensuring the security of the second decryption key.

[0156] Building upon this, the encrypted second decryption key is transmitted from the third device to the secure enclave. Within the secure enclave, decryption is performed based on the user account information. During decryption, both the plaintext of the user account information and the plaintext of the decrypted second decryption key reside within the secure enclave, without being exposed to any module outside of it. Subsequently, within the same secure enclave, the second decryption key is used to decrypt the second key packet, restoring the target key. The entire decryption process is completed within the memory isolation environment of the secure enclave, avoiding the risk of key interception or leakage during transmission and processing, further ensuring the security of both the second decryption key and the target key.

[0157] Furthermore, since the decryption process relies on user account information, the third device can return the encrypted second decryption key without additional authentication. Even if the encrypted second decryption key is intercepted, it cannot be decrypted without the user account information. This simplifies the interaction process between the third device and the first device, improving the user experience while ensuring security.

[0158] As another optional embodiment of this application, refer to Figure 5 This is a flowchart illustrating a processing method provided in Embodiment 5 of this application. (Refer to...) Figure 5 The method may include, but is not limited to, the following steps:

[0159] Step S201: In response to the connection between the second device and the first device, detect the matching relationship between the second device and the first device.

[0160] Step S202: Obtain the decryption key corresponding to the matching relationship.

[0161] Step S203: Based on the decryption key, decrypt the key packet to be used that corresponds to the matching relationship among the multiple key packets contained in the second device to obtain the target key; wherein, the multiple key packets are obtained by encrypting the same target key using different encryption keys.

[0162] For a detailed description of steps S201-S203, please refer to the relevant description of steps S101-S103 in Example 1, which will not be repeated here.

[0163] Step S204: In response to the first device failing to obtain the decryption key corresponding to the matching relationship, a third key package is selected from the plurality of key packages as the key package to be used; the third key package is obtained by encryption based on the third encryption key in the third key pair generated by the security agent program in the first device; the third decryption key in the third key pair is not stored in the first device and the third device; the first device and the third device are used to store the decryption key corresponding to the matching relationship.

[0164] In this embodiment, the first device may fail to obtain the decryption key corresponding to the matching relationship due to the following reasons:

[0165] Scenario 1: The matching relationship is correct, but the first decryption key in the motherboard security chip of the first device is damaged or unavailable, which makes it impossible to decrypt the first key package and to obtain the decryption key through other paths.

[0166] Scenario 2: The matching relationship is not a match. The first device attempts to obtain the second decryption key from the third device, but the request fails due to network unavailability, and the second decryption key cannot be obtained from the third device.

[0167] Scenario 3: The matching relationship is not a match. The first device attempts to obtain the second decryption key from the third device, but the authentication fails because the user account is unreachable (e.g., the account is locked, the password is forgotten, etc.), and the second decryption key cannot be obtained from the third device.

[0168] Scenario 4: The matching relationship is not a match. The first device successfully obtained the second decryption key from the third device, but failed to decrypt the second key packet using the second decryption key and could not recover the target key.

[0169] Scenario 5: Security agent not logged in. The security agent on the first device is not logged in and cannot access the motherboard security chip or initiate authentication requests to the third device, resulting in the inability to obtain the first or second decryption key.

[0170] When any of the above situations cause the first device to fail to obtain the decryption key corresponding to the matching relationship, the security agent program can obtain the storage location of the third key packet (which can be represented as C) from the key data structure information of the second device, and read the third key packet from that location as the key packet to be used.

[0171] The third key packet is generated when the second device first establishes an authorization relationship with a first device. It is created by encrypting the target key with the third encryption key in the third key pair generated by an application (such as a security agent) on the first device. The third key pair contains a third encryption key (which can be represented as an ORK public key) and a third decryption key (which can be represented as an ORK private key).

[0172] Step S205: Output a prompt message to the user to obtain the third decryption key provided by the user.

[0173] The security agent program can display a prompt message to the user, informing the user that the second device cannot be decrypted through the first key package decryption path in Embodiment 2 or the second key package decryption path in Embodiment 3, and that offline emergency recovery is required.

[0174] The third decryption key can be provided in any of the following ways, but is not limited to:

[0175] The first method involves the user keeping the third decryption key safe.

[0176] When the second device is first activated, the security agent program generates a third key pair and presents the third decryption key to the user in the form of text, QR code, etc., which the user can print, copy, or save as a screenshot. When offline emergency recovery is required, the user manually enters the text content of the third decryption key through the interface provided by the security agent program, or scans the QR code containing the third decryption key. The security agent program then transmits the third decryption key provided by the user to the secure enclave.

[0177] The second method involves providing a third decryption key via a FIDO2 device.

[0178] When the second device is first activated, the security agent can guide the user to generate a third key pair using a FIDO2 device (such as a USB security key, a FIDO2-enabled biometric key, etc.). The third encryption key in the third key pair is used to encrypt the target key to generate a third key package, while the third decryption key is securely stored inside the FIDO2 device and cannot be exported.

[0179] When offline emergency recovery is required, the user inserts the FIDO2 device into the first device. The security agent interacts with the FIDO2 device via the standard FIDO2 protocol, sending a decryption request. The FIDO2 device internally decrypts the third key packet using its stored third decryption key and returns the decryption result to the security enclave, from which the target key is recovered. Throughout this process, the third decryption key remains internal to the FIDO2 device and is not exposed externally.

[0180] Step S206: Based on the third decryption key, decrypt the third key packet to obtain the target key.

[0181] The security agent can transmit a user-provided third decryption key to the security enclave, along with a third key packet. The security enclave, operating in a memory-isolated environment, uses the third decryption key to decrypt the third key packet and recover the target key.

[0182] During the decryption process, the plaintext of the third decryption key and the plaintext of the decrypted target key reside within the secure enclave and are not exposed to any module outside the secure enclave.

[0183] Step S207: In response to the first device's access request to the second device, encrypt or decrypt the data corresponding to the access request based on the target key.

[0184] For a detailed description of step S207, please refer to the relevant description of step S104 in Example 1, which will not be repeated here.

[0185] Next, combined Figure 6 The processing method provided in this embodiment will be described below. Figure 6 As shown, when the second device is inserted into the first device, the security agent program in the first device detects that the second device is an encrypted device, but the security agent program is not logged in. Because the security agent program is not logged in (i.e., an implementation method for an offline emergency recovery scenario), it cannot access the first decryption key in the motherboard security chip of the first device, nor can it initiate an authentication request to the third device to obtain the second decryption key. Therefore, it cannot obtain the decryption key through the first key package decryption path in Embodiment 2 or the second key package decryption path in Embodiment 3.

[0186] Based on the result of failing to obtain the decryption key corresponding to the matching relationship, the security agent program determines that offline emergency recovery is required. The security agent program obtains the storage location of the third key packet (which can be represented as C) from the key data structure information of the second device, and reads the third key packet from that location as the key packet to be used.

[0187] Subsequently, the security agent program displays a prompt message to the user, informing them that the second device cannot be decrypted using the first key package decryption path or the second key package decryption path, and that an offline emergency recovery is required. The program then guides the user to provide a third decryption key. Following the prompts, the user can either enter the text content of the third decryption key through the interface provided by the security agent program, scan a QR code containing the third decryption key, or insert the FIDO2 device into the first device.

[0188] The security agent transmits the user-provided third decryption key to the secure enclave, along with the third key packet. Within the secure enclave, the third decryption key is used to decrypt the third key packet C, restoring the target key and unlocking the volume.

[0189] After the secure enclave obtains the target key, it notifies the security agent program of successful decryption. The security agent program then instructs the kernel filter driver to complete the mounting of the encrypted file system, making the second device appear as a normally accessible drive letter in the operating system. For the user, this mounting process is transparent and readily available to the system; the user can see the drive letter and begin using it without any further manual intervention. However, the data stored on the second device remains in encrypted form, and all subsequent read and write operations still require real-time encryption and decryption processing to access the actual data.

[0190] In this embodiment, when the first device cannot obtain the decryption key based on the decryption path of the first key package and the decryption path based on the second key package and the second decryption key due to reasons such as the security agent program not being logged in, motherboard security chip failure, network unavailability, or user account unreachability, the user can still access the second device through the third decryption key (offline emergency recovery key). Since the third decryption key can be kept by the user and is not stored on any device or in the cloud, the user can restore access to the second device even in a completely offline environment, avoiding the risk of permanent data loss due to device failure, network interruption, or account problems.

[0191] In this embodiment, by using the decryption path of the first key packet, the decryption path of the second key packet and the second decryption key, and the offline emergency recovery path of the third key packet, a complete key recovery system covering various scenarios such as local use, device replacement recovery, and offline emergency recovery is constructed. Users can restore access to the second device in different scenarios using the corresponding key packets and decryption keys, achieving a multi-faceted and seamless security protection experience.

[0192] The processing method will now be explained in conjunction with the security architecture provided in this application.

[0193] Reference Figure 7 Security architecture may include, but is not limited to:

[0194] The security agent program in the first device (local machine) is responsible for coordinating the operation of the entire encryption system, including: detecting the encryption status of the second device, determining matching relationships, obtaining the decryption key, and scheduling the security enclave and the motherboard security chip to perform related operations.

[0195] Security agents can expose their APIs only to digitally signed legitimate components (i.e., signed components), such as motherboard security chip drivers and kernel filter drivers. Unsigned third-party programs cannot interact with them, thus preventing malicious software from impersonating legitimate components to access the security agent.

[0196] Meanwhile, the security agent can protect processes by running Protected Process Light (PPL) mode, effectively resisting process sniffing and Direct Memory Access (DMA) attacks.

[0197] The security agent can communicate with a virtualization-based secure enclave to perform encryption and decryption. That is, it establishes a secure communication channel with the enclave, transmits the data to be encrypted / decrypted to the secure enclave for execution, and returns the encryption / decryption results through this channel. The security agent itself does not handle the plaintext key.

[0198] Kernel filter driver. Responsible for device initialization / mounting and handling I / O requests. The kernel filter driver intercepts all read and write requests to the second device, forwarding plaintext data to a secure enclave for encryption, or forwarding ciphertext data read from the second device to a secure enclave for decryption, but does not participate in the encryption / decryption operations themselves.

[0199] A virtualization-based secure enclave. A secure in-memory environment used for deriving the target key (EVK), decrypting multiple key packets in a second device, and interacting with kernel filter drivers for encryption and decryption of user data. The plaintext target key always resides within the secure enclave and is never exposed externally.

[0200] The motherboard security chip generates a first key pair, which includes a first encryption key (which can be represented as a DBK public key) and a first decryption key (which can be represented as a DBK private key). The DBK private key cannot be exported from the motherboard security chip. The motherboard security chip works with the security enclave to transmit the DBK private key (which can be considered as a device binding key) to the security enclave. Within the security enclave, a target key is generated, and the target key (EVK) is encrypted using the DBK private key to generate the first key packet.

[0201] The security agent program can also be used to generate a second key pair and a third key pair. The second key pair includes a second encryption key (which can be represented as an ARK public key) and a second decryption key (which can be represented as an ARK private key). The third key pair contains a third encryption key (which can be represented as an ORK public key) and a third decryption key (which can be represented as an ORK private key).

[0202] The cloud recovery credential service, included in a third device (e.g., a cloud server), communicates with the first device through a software / device proof + TLS (Transport Layer Security) encrypted channel. It is responsible for verifying the user's identity and the device's legitimacy, and storing and distributing the encrypted ARK private key (which can be regarded as the account recovery private key).

[0203] The second device (e.g., an external storage medium) stores encrypted user data, key data structure information, and multiple key packets.

[0204] Combination Figure 8The diagram illustrating the initial activation scenario explains the interaction process within the aforementioned security architecture. When a user inserts a second device (e.g., an external storage medium) into the first device (the local machine) for the first time, the kernel filter driver detects the second device's connection and reads the key data structure information from the second device. Since the second device is being used for the first time, there is no key data structure information in a specific format (such as the Magic identifier "EXTS") in the header. The kernel filter driver determines that the second device is an unencrypted device and immediately notifies the security agent program.

[0205] The security agent program can prompt the user whether to enable protection. In one implementation, the security agent program can display an interactive interface to the user to enable protection, where the user selects "protect" or "do not protect". If the user selects "do not protect", the second device is mounted in normal unencrypted mode, and no subsequent encryption operations are performed. If the user selects "protect", the seamless security protection process of this application is initiated.

[0206] The security agent can send instructions to the security enclave to generate a target key (EVK). The security enclave generates a random symmetric encryption key, i.e., the target key (EVK), in a memory-isolated environment. The EVK is used for subsequent encryption and decryption of user data in the second device. After the EVK is generated, its plaintext form is always retained in the security enclave's memory space, and the security enclave subsequently discards the EVK's generation context.

[0207] The security agent program can send instructions to the motherboard security chip to generate a DBK. The motherboard security chip generates an asymmetric key pair, namely the device-bound key pair (DBK), within the hardware security area, containing a DBK public key and a DBK private key. The DBK private key is hardware-protected and cannot be exported, while the DBK public key is returned to the security agent program.

[0208] The security agent transmits the DBK public key to the security enclave, which uses the DBK public key to encrypt the EVK and generate the first key packet, namely, Capsule A (represented as EVK@DBK-Pub).

[0209] The security agent generates an account recovery key pair (ARK), containing an ARK public key and an ARK private key. The security agent then transmits the ARK public key to the security enclave, which uses the ARK public key to perform asymmetric encryption on the EVK in memory, generating a second key packet, namely Capsule B (represented as EVK@ARK-Pub).

[0210] The ARK private key is encrypted with the user account access credentials to generate an encrypted ARK private key, which is then backed up to the cloud for credential recovery (the cloud only holds the encrypted text).

[0211] The security agent generates an offline emergency recovery key pair (ORK), containing an ORK public key and an ORK private key. The security agent then transmits the ORK public key to a secure enclave, which performs asymmetric encryption on the EVK using the ORK public key in memory, generating a third key packet, Capsule-C (represented as EVK@ORK-Pub). The ORK private key is either kept by the user or generated and stored using a FIDO2 device.

[0212] The security agent program generates and encrypts capsules A, B, and C in the secure enclave, along with metadata such as version information, algorithm identifiers (e.g., Data=XTS-AES-256, Hash=SHA-512), capsule arrays, and integrity check values, and writes them to the second device through the kernel filter driver.

[0213] The security agent instructs the kernel filter driver to perform device initialization and encrypted mount preparation. The kernel filter driver completes the file system mount, making the second device appear as a normally accessible drive letter in the operating system. For the user, this mounting process is transparent and available for system use; the user can see the drive letter and begin using it without any manual intervention.

[0214] In response to the first device's access request to the second device, the kernel filter driver forwards the data to the secure enclave, which uses EVK for encryption and decryption.

[0215] In subsequent use, when a user or application initiates a read / write request to the second device, the kernel filter driver intercepts the write request and forwards the plaintext data block to be written to the secure enclave. The secure enclave uses EVK to encrypt the plaintext data, generating ciphertext data which is then returned to the kernel filter driver, which writes the ciphertext data to the second device. When a read request is intercepted, the kernel filter driver reads the ciphertext data from the second device and forwards it to the secure enclave. The secure enclave uses EVK to decrypt the ciphertext data, generating plaintext data which is then returned to the kernel filter driver, which provides the plaintext data to the upper-layer application. The entire encryption and decryption process is completely transparent to the upper-layer application and the user.

[0216] Through the above steps, this application achieves the initial activation and transparent encryption initialization of the second device. During the initial activation process, three key packets (Capsule A, Capsule B, and Capsule C) are generated. These three key packets are all obtained by encrypting the same EVK, but use different encryption keys (DBK public key, ARK public key, and ORK public key), each corresponding to a different recovery path. The plaintext of the EVK always resides in the memory of the secure enclave and is not exposed to any module outside the secure enclave, ensuring the security of the EVK.

[0217] As another optional embodiment of this application, a processing method provided in embodiment 6 of this application may include, but is not limited to, the following steps:

[0218] Step S301: In response to the connection between the second device and the first device, detect the matching relationship between the second device and the first device; the matching relationship includes: the second device and the first device are not matched.

[0219] Step S302: Obtain the decryption key corresponding to the matching relationship; the decryption key corresponding to the matching relationship includes: the second decryption key in the second key pair.

[0220] Step S303: Based on the second decryption key, decrypt the second key packet among the multiple key packets contained in the second device to obtain the target key; the second key packet is obtained by encrypting it based on the second encryption key in the second key pair.

[0221] Step S304: In response to the first device's access request to the second device, encrypt or decrypt the data corresponding to the access request based on the target key.

[0222] For detailed procedures of steps S301-S304, please refer to the relevant description in Example 3, which will not be repeated here.

[0223] Step S305: Generate a fourth key pair locally on the first device; the fourth key pair includes a fourth encryption key and a fourth decryption key.

[0224] In this embodiment, in order to enable the new device to quickly and seamlessly unlock the second device through the device binding path when it reconnects in the future, the security agent program, after successfully restoring the target key, instructs the motherboard security chip of the first device to generate a new key pair, namely the fourth key pair, within the hardware security area.

[0225] The fourth key pair may contain a fourth encryption key (which may be represented as a new DBK public key) and a fourth decryption key (which may be represented as a new DBK private key).

[0226] Step S306: Store the fourth decryption key locally on the first device; the fourth decryption key cannot be transferred to other devices.

[0227] The motherboard security chip of the first device can store the fourth decryption key in its hardware security area, which is protected by hardware and ensures that only the original first device that generated the fourth key pair can use the fourth decryption key.

[0228] Step S307: Encrypt the target key based on the fourth encryption key to obtain the fourth key packet.

[0229] The secure agent can transmit a fourth encryption key (the new DBK public key) to the secure enclave. The secure enclave then uses the fourth encryption key to perform asymmetric encryption on the target key (EVK) in memory, generating a fourth key packet.

[0230] Step S308: Replace the first key packet in the second device with the fourth key packet.

[0231] The security agent can instruct the kernel filter driver to read the key data structure information from the second device and replace the original first key packet with the generated fourth key packet. The replacement operation does not re-encrypt existing encrypted data on the storage medium; the target key remains unchanged.

[0232] In this embodiment, when the second device reconnects to the first device, the matching relationship becomes a matching state. The first device can directly decrypt the fourth key packet using the fourth decryption key in the local motherboard security chip to restore the target key without relying on the cloud for recovery, thus achieving seamless unlocking on the local device.

[0233] Furthermore, since only the key packet in the second device is updated, while the target key itself remains unchanged, there is no need to re-encrypt the existing encrypted data in the second device. For encryption scenarios with large amounts of stored data, this feature significantly saves time and improves the user experience.

[0234] Since the target key remains unchanged, the second key packet (generated by encrypting the EVK with the ARK public key) and the third key packet (generated by encrypting the EVK with the ORK public key) remain valid. There is no need to regenerate or update the ARK private key stored in the cloud, nor does the user need to re-store the ORK private key. This simplifies key management, avoids the synchronization overhead between the cloud and the device, and also eliminates the burden of repeatedly saving offline recovery keys.

[0235] For example, such as Figure 9As shown, based on the new first device login security agent program, when the second device connects to the first device with which it has not established an authorization relationship (i.e., a new first device relative to the first device with which it has established an authorization relationship) (i.e., a device replacement recovery scenario), the kernel filter driver detects the insertion of the second device, reads the key data structure information in the second device's header, identifies it as an encrypted second device, and then notifies the security agent program. The security agent program attempts to decrypt the first key packet using the first decryption key in the first device's local motherboard security chip, but decryption fails. Based on the decryption failure result, the security agent program determines that the matching relationship is in a mismatch state.

[0236] The security agent determines the key packet type corresponding to the detected matching relationship (i.e., mismatch status) as the second key packet. The security agent obtains the storage location of the second key packet (which can be represented as B) from the capsule array of key data structure information and reads the second key packet from that location.

[0237] Subsequently, the security agent program determines that the decryption key corresponding to the matching relationship is the second decryption key, and determines that this second decryption key is stored in a third device other than the first device. The security agent program displays an authentication interface to the user. After the user submits their credentials, the security agent program initiates an authentication request to the third device through an encrypted channel. After the third device verifies the user's identity and the device's legitimacy (i.e., authentication is successful), it sends the second decryption key to the security agent program.

[0238] The security agent program transmits the second decryption key to the secure enclave, and at the same time transmits the second key packet to the secure enclave. Within the secure enclave, the second decryption key is used to decrypt the second key packet B, restore the target key, and unlock the volume.

[0239] After the secure enclave obtains the target key, it notifies the security agent program of successful decryption. The security agent program then instructs the kernel filter driver to complete the mounting of the encrypted file system, making the second device appear as a normally accessible drive letter in the operating system. For the user, this mounting process is transparent and readily available to the system; the user can see the drive letter and begin using it without any manual intervention. However, the data stored on the second device remains in encrypted form, and all subsequent read and write operations still require real-time encryption and decryption processing to access the actual data.

[0240] After mounting, since the target key obtained by decryption using the second key packet in this embodiment is the same as the target key obtained by decryption using the first key packet in the previous embodiment, the subsequent read / write request processing is exactly the same as the local usage scenario in Embodiment 2. That is, regardless of whether the first device is an authorized device (i.e., a matching device) or an unauthorized device (i.e., a mismatch), as long as the target key is successfully restored, the same target key will be used for subsequent encryption and decryption operations on the data in the second device, and the user experience will be completely consistent.

[0241] Specifically, when a user or application initiates a read / write request to the second device, the kernel filter driver intercepts the write request and sends the plaintext data to be written to the secure enclave. The secure enclave encrypts the plaintext data using the target key, generates ciphertext data, and returns it to the kernel filter driver, which then writes the ciphertext data to the second device. When a read request is intercepted, the kernel filter driver reads the ciphertext data from the second device and sends it to the secure enclave. The secure enclave decrypts the ciphertext data using the target key, generates plaintext data, and returns it to the kernel filter driver, which then provides the plaintext data to the upper-layer application. The entire encryption and decryption process is completely transparent to the upper-layer application and the user; the user can read and write user data on the second device normally without performing any manual operations.

[0242] Throughout the entire process, the plaintext of the target key resides in the memory of the secure enclave and is not persistently stored in plaintext on any non-volatile storage medium of the first device. When the second device disconnects from the first device, the target key in the secure enclave is destroyed and no longer retained.

[0243] The new first device's motherboard security chip generates a fourth key pair within the hardware security area. This fourth key pair includes a fourth encryption key (which can be represented as a new DBK public key) and a fourth decryption key (which can be represented as a new DBK private key). The fourth decryption key is stored internally within the first device's motherboard security chip and cannot be exported or transferred to other devices.

[0244] The security agent program transmits the fourth encryption key to the security enclave, which then uses the fourth encryption key to perform asymmetric encryption on the target key in memory, generating the fourth key packet.

[0245] The security agent program instructs the kernel filter driver to read the key data structure information in the second device header and replace the original first key packet with the fourth key packet.

[0246] After the replacement is complete, when the second device reconnects to the current first device, it enters the seamless local usage process. Since the second device's first key package has been updated to the fourth key package bound to the new device, when the second device reconnects to the current first device, the matching relationship becomes matched. The first device can directly decrypt the fourth key package using the fourth decryption key in its local motherboard security chip to restore the target key, without relying on cloud recovery again, thus achieving seamless local unlocking.

[0247] Of course, such as Figure 10 As shown, in an offline emergency recovery scenario, after decrypting the third key packet using the third decryption key to obtain the target key, to further enable seamless local use, the motherboard security chip of the first device can also generate a fourth key pair within the hardware security area. The fourth key pair includes a fourth encryption key (which can be represented as a new DBK public key) and a fourth decryption key (which can be represented as a new DBK private key). The fourth decryption key is stored internally within the motherboard security chip of the first device and cannot be exported or transferred to other devices.

[0248] The security agent program transmits the fourth encryption key to the security enclave, which then uses the fourth encryption key to perform asymmetric encryption on the target key in memory, generating the fourth key packet.

[0249] The security agent program instructs the kernel filter driver to read the key data structure information in the second device header and replace the original first key packet with the fourth key packet.

[0250] After the replacement is complete, when the second device reconnects to the current first device, it enters the seamless local usage process. Since the second device's first key package has been updated to the fourth key package bound to the new device, when the second device reconnects to the current first device, the matching relationship becomes matched. The first device can directly decrypt the fourth key package using the fourth decryption key in its local motherboard security chip to restore the target key, without relying on cloud recovery again, thus achieving seamless local unlocking.

[0251] As another optional embodiment of this application, a processing method provided in Embodiment 7 of this application is mainly an implementation of the above-mentioned detection of the matching relationship between the second device and the first device, which may include, but is not limited to, the following steps:

[0252] Step S1011: Detect whether the external device identifier in the second device is consistent with the device identifier of the first device; the external device identifier is written when a binding relationship is established between the second device and the external device.

[0253] In this embodiment, the second device (such as an external storage medium) stores key data structure information, which may include one or more fields for recording device identification information. Specifically, when the second device first establishes an authorization relationship with a first device (i.e., when it is first activated), the security agent program can write the device identifier of the first device (such as a unique identifier like a host serial number, motherboard serial number, or network card MAC address) as an external device identifier into the key data structure information of the second device.

[0254] When the second device reconnects to the first device, the security agent reads the key data structure information from the second device and extracts the external device identifier. Simultaneously, the security agent obtains the device identifier of the first device itself. The security agent then compares the external device identifier with the device identifier of the first device.

[0255] If the external device identifier matches the device identifier of the current first device, the security agent program determines that the matching relationship between the second device and the first device is a match, meaning that the second device has previously established an authorization relationship with the current first device, and there is an established trust relationship between the two. At this time, the security agent program can process according to the process in Embodiment 2, that is, read the first key packet from the second device and obtain the first decryption key from the local motherboard security chip for decryption.

[0256] If the external device identifier does not match the device identifier of the current first device, the security agent program determines that the matching relationship between the second device and the first device is mismatched, that is, the second device previously established an authorization relationship with another first device, and the current first device is a new unauthorized device. At this time, the security agent program can process according to the process in Embodiment 3, that is, attempt to read the first key package from the second device and decrypt it with the local motherboard security chip. Decryption is expected to fail, and then it will switch to the second key package and the cloud recovery path.

[0257] If the second device does not have an external device identifier (e.g., this field is not set in some implementations), the security agent can determine the matching relationship in another way. The security agent reads the first key packet from the second device and attempts to decrypt the first key packet using the first decryption key in the motherboard security chip of the first device. If decryption is successful, the matching relationship is determined to be a match; if decryption fails, the matching relationship is determined to be a mismatch.

[0258] In this embodiment, the matching relationship between the second device and the first device is quickly determined by comparing device identifiers. The subsequent key packet selection path can be determined without executing a complete decryption process, thereby improving processing efficiency.

[0259] As another optional embodiment of this application, a processing method provided in embodiment 8 of this application may include, but is not limited to, the following steps:

[0260] Step S401: In response to the connection between the second device and the first device, the first device initiates an authorization request to the second device, so that the second device obtains the host identifier from the authorization request and verifies whether the host identifier matches the authorization identifier stored in the second device. If the verification is successful, the first device is allowed to access.

[0261] The host identifier is generated by the second device based on the device root key and the identifier information of the first device when the first device and the second device first connect.

[0262] In this embodiment, the second device may have the security capability to determine whether to trust the accessed host. For example, the second device may include, but is not limited to: mobile AI peripherals (integrated local neural network processors, NPUs), encrypted storage devices (such as portable hard drives with hardware encryption chips), smart sensor devices (such as cameras with integrated local image signal processors, ISPs), etc.

[0263] The second device can maintain a status bit to identify its current state, including: UNBOUND (unbound, factory default state), BOUND_IDLE (bound, unauthenticated), AUTHENTICATED (authenticated).

[0264] When the second device is powered on for the first time, it enters the UNBOUND state. The second device generates a device root key in its secure execution environment.

[0265] When a second device connects to the first device (host computer) via a communication interface (such as a Type-C interface), the driver on the first device detects the peripheral insertion. The driver can read the status bits of the second device and find that the second device is currently in an UNBOUND state, indicating that the second device has not yet established an authorization relationship with any first device, and therefore this is the first connection. Since the second device is in an unbound state, the first device initiates a BindRequest to the second device, requesting to establish an authorization relationship with the second device.

[0266] After receiving the binding request, the second device allows the user to make manual confirmation through its interactive components (such as a small display screen and physical buttons) (i.e., entering the WAIT_PHYSICAL_CONFIRM state and waiting for manual confirmation via button press or PIN). After the user confirms on the second device, the second device enters the binding process.

[0267] During the binding process, the second device can generate a host identity for the first device. Specifically, the second device can calculate a derived value using a Key Derivation Function (KDF) based on the device root key and the first device's identification information (such as the host serial number, motherboard identifier, etc.), and use the derived value as the host identity. The host identity can be used to verify the identity of the first device later. Since the device root key is only stored inside the second device, other devices cannot forge a legitimate host identity.

[0268] For example, the second device can use the HMAC-SHA256 algorithm, with the device root key as the HMAC key and the identification information of the first device as the input message, to calculate the HMAC value as the host identifier.

[0269] Meanwhile, the second device can generate a Capability Grant Set for the first device, which can be used to finely control the scope of permissions that the first device can access.

[0270] In this embodiment, the capability authorization set may include, but is not limited to, the following permission items: inference operation permission (allowing the first device to call the NPU of the second device to perform model inference), data reading permission (allowing the first device to read sensor data collected by the second device), and secure storage access permission (allowing the first device to read and write data in the secure storage area of ​​the second device), etc.

[0271] The specific content of the capability authorization set can be selected by the user through the interaction component of the second device, or the second device can grant a minimum capability authorization set according to the default policy. During subsequent access, for each operation request initiated by the first device, the second device can determine whether the operation initiated by the first device is allowed based on the capability authorization set.

[0272] The second device can store authorization information (including host identifier and capability authorization set) in its secure storage area, without exposing internal keys such as the device root key to the first device. After binding is complete, the second device will rewrite its status bit to BOUND_IDLE.

[0273] When the second device connects to the first device again, the driver on the first device can read the status bit of the second device and find that the second device is currently in the BOUND_IDLE (bound, unauthenticated) state, indicating that the second device has previously established an authorization relationship with a first device, but has not yet completed the authentication for this connection. Since the second device is in the bound state, the first device sends an authorization request to the second device, requesting the second device to verify the identity of the current first device.

[0274] The second device obtains the host identifier from the authorization request and verifies whether the host identifier matches the authorization identifier stored in its own secure storage area.

[0275] At the same time, the second device can check whether the authorization status is valid (i.e., whether the current status bit is BOUND_IDLE or AUTHENTICATED).

[0276] If the verification is successful, the second device will switch its status to AUTHENTICATED and enable the corresponding capabilities (such as NPU inference, sensor data reading, secure storage access, etc.) according to the capability authorization set, allowing the first device to access it. During this process, the second device will not expose its internal keys, such as the device root key, to the first device.

[0277] Step S402: Detect the matching relationship between the second device and the first device;

[0278] Step S403: Obtain the decryption key corresponding to the matching relationship;

[0279] Step S404: Based on the decryption key, decrypt the key packet to be used that corresponds to the matching relationship among the multiple key packets contained in the second device to obtain the target key; wherein, the multiple key packets are obtained by encrypting the same target key using different encryption keys;

[0280] Step S405: In response to the first device's access request to the second device, encrypt or decrypt the data corresponding to the access request based on the target key.

[0281] For detailed procedures of steps S402-S405, please refer to the relevant description of steps S101-S104 in Example 1, which will not be repeated here.

[0282] In this embodiment, the second device can proactively determine whether the connected first device is an authorized device through its internally maintained status bits and host identifier verification mechanism, without relying on the first device's operating system security mechanism or the user-entered password. Since the host identifier is generated using a key derivation function based on the device root key and the first device's identifier information, and the device root key is stored only within the second device, other devices cannot forge a legitimate host identifier, thus effectively preventing the leakage of sensitive data or models caused by unauthorized hosts accessing the second device.

[0283] Furthermore, this embodiment implements a two-layer security protection. The first layer involves the second device actively verifying the host's identity and authorizing control capabilities, ensuring that only the authorized first device can access the hardware functions of the second device. The second layer uses multiple key packets to encrypt and store target keys under different recovery paths, achieving transparent encryption and decryption of data and cross-device recovery. The two mechanisms are independent yet complementary. Even if an attacker bypasses the first layer's host authentication, they cannot decrypt the encrypted data stored in the second device; conversely, even if an attacker gains access to the encrypted data in the second device, they cannot call the hardware functions of the second device through an unauthorized host, thereby comprehensively improving the data security and access security of the second device.

[0284] As another optional embodiment of this application, a processing method provided in embodiment 9 of this application may include, but is not limited to, the following steps:

[0285] Step S501: In response to the connection between the second device and the first device, the first device initiates an authorization request to the second device, so that the second device obtains the host identifier from the authorization request and verifies whether the host identifier matches the authorization identifier stored in the second device. If the verification is successful, the first device is allowed to access.

[0286] The host identifier is generated by the second device based on the device root key and the identifier information of the first device when the first device and the second device first connect.

[0287] For a detailed description of step S501, please refer to the relevant description of step S401 in Example 8, which will not be repeated here.

[0288] Step S502: In response to the second device failing verification, a prompt message is output so that after the user enters a recovery key into the second device according to the prompt message, the second device verifies the validity of the recovery key. If the verification is successful, the first device is allowed to access the device. The prompt message is used to prompt the user to enter a recovery key. The recovery key is generated by the second device and is used to verify the access rights of other devices.

[0289] In this embodiment, when the second device detects that the accessing first device is unauthorized, that is, the second device is currently in the BOUND_IDLE state, but the host identifier carried in the authorization request provided by the first device does not match the authorization identifier stored in the second device's secure storage area, the second device determines that the first device is currently an unauthorized host.

[0290] The second device can enter the WAIT_REBIND_PROOF state, waiting for the user to provide a recovery key for rebinding verification. Specifically, the second device outputs a prompt message to the first device via the communication interface, instructing the user to enter a recovery key. After receiving this prompt message, the driver or accompanying software on the first device displays an interactive interface to the user, prompting the user to enter the recovery key generated by the second device during the initial binding.

[0291] The recovery key is generated when the second device is first powered on and is shown to the user through a physical display or a one-time method. The user must keep it safe. The recovery key is used to re-establish the authorization relationship in the event of a lost or replaced host device.

[0292] The user enters the recovery key through the interactive interface on the first device, which then sends the entered recovery key to the second device. The second device verifies the validity of the recovery key, that is, it verifies whether the recovery key entered by the user matches the recovery key stored in its own secure storage area.

[0293] If the recovery key verification is successful, the second device may, but is not limited to, performing the following operations:

[0294] Remove the authorization relationship of the old host, that is, clear the authorization record of the original bound host (including the original host identifier and capability authorization set) in the security storage area of ​​the second device.

[0295] A new host identifier and capability authorization set are generated for the current first device and stored in the secure storage area of ​​the second device.

[0296] The status bit is rewritten to BOUND_IDLE, allowing the current first device to authenticate via authorization requests in subsequent accesses.

[0297] If the recovery key verification fails, the second device can increment the failure count. When the number of consecutive failures exceeds a preset threshold, the second device enters the LOCKED state and rejects any subsequent binding or authorization requests to prevent brute-force attacks.

[0298] If the recovery key cannot be provided (e.g., the user has lost the recovery key), the second device can enter a secure reset mode, clear all authorized host information, local knowledge base and sensor data, and regenerate the device root key to ensure that no historical data can be recovered.

[0299] Step S503: Detect the matching relationship between the second device and the first device.

[0300] Step S504: Obtain the decryption key corresponding to the matching relationship.

[0301] Step S505: Based on the decryption key, decrypt the key packet to be used that corresponds to the matching relationship among the multiple key packets contained in the second device to obtain the target key; wherein, the multiple key packets are obtained by encrypting the same target key using different encryption keys.

[0302] Step S506: In response to the first device's access request to the second device, encrypt or decrypt the data corresponding to the access request based on the target key.

[0303] For detailed procedures of steps S503-S506, please refer to the relevant description of steps S101-S104 in Example 1, which will not be repeated here.

[0304] In this embodiment, when the user changes the host, the second device verifies the host identifier and finds that the first device is not authorized. At this time, the user can re-establish the authorization relationship through the recovery key and restore access to the hardware functions of the second device. The user does not need to worry about the function being restricted due to changing the host.

[0305] Furthermore, the recovery key is generated by the second device upon initial power-on and presented to the user via a physical display or a one-time method, and is kept safe by the user. When the user needs to change hosts, they only need to enter the recovery key to revoke the authorization relationship of the old host and issue new authorization information for the new host. The entire process is completed autonomously by the second device, without relying on cloud services or third-party certification authorities. The user has complete control over the transfer of authorization relationships, and even if the second device is lost, attackers cannot bind the second device to a malicious host without the recovery key.

[0306] Furthermore, by setting a failure count and a lock threshold, when the number of consecutive failed verifications of the recovery key exceeds a preset threshold, the second device enters the LOCKED state and rejects any subsequent binding or authorization requests, thereby effectively preventing attackers from guessing the recovery key through brute force.

[0307] Furthermore, when a user loses their recovery key and cannot restore authorization through other means, the second device can enter a secure reset mode, clearing all authorized host information, local knowledge base, and sensor data, and regenerating the device root key to ensure that no historical data can be recovered. This mechanism allows the second device to be restored to factory settings for reuse while ensuring data security, avoiding the problem of permanent device failure due to lost recovery keys.

[0308] In this embodiment, combined with Figure 11 The diagram showing the state transition illustrates the processing method. For example, the second device maintains a state bit to indicate its current state. The state bits and their corresponding meanings include: S0: UNBOUND (unbound, factory default state), S1: BOUND_IDLE (bound, unauthenticated), S2: AUTHENTICATED (authentication completed), S3: WAIT_PHYSICAL_CONFIRM (waiting for manual confirmation via button / PIN), S4: WAIT_REBIND_PROOF (waiting for rebinding verification), and S_EER: LOCKED (error / forceful failure lock).

[0309] When the second device is powered on for the first time, it enters the S0: UNBOUND state. The second device generates a Device Root Key and a Recovery Key within its secure execution environment. The Recovery Key is displayed to the user physically or through a one-time method and is kept safe by the user. If the user triggers a factory reset, the second device clears all authorized host information, local knowledge base, and sensor data, regenerates the Device Root Key, ensuring that any historical data is unrecoverable, and returns to the S0: UNBOUND state.

[0310] When a second device connects to the first device (host computer) via a communication interface (such as a Type-C interface), the driver on the first device detects the peripheral connection. The driver reads the status bits of the second device and finds that the second device is currently in the S0: UNBOUND state, indicating that the second device has not yet established an authorization relationship with any first device, and therefore this is the first connection. Because the second device is in the S0: UNBOUND state, the first device initiates a BindRequest to the second device, requesting to establish an authorization relationship with the second device.

[0311] After receiving the binding request, the second device uses its interactive components (such as a small display screen and physical buttons) to allow the user to manually confirm, i.e., it enters the S3: WAIT_PHYSICAL_CONFIRM state, waiting for manual confirmation via button press or PIN. After the user confirms on the second device, the second device begins the binding process.

[0312] During the binding process, the second device generates a host identity for the first device. Specifically, the second device calculates a derived value using a Key Derivation Function (KDF) based on the device root key and the first device's identification information (such as the host serial number and motherboard identifier), and uses this derived value as the host identity. The host identity is used to subsequently verify the identity of the first device. Since the device root key is stored only within the second device, other devices cannot forge a legitimate host identity.

[0313] Simultaneously, the second device generates a Capability Grant Set for the first device. This set is used to fine-tune the scope of permissions that the first device can access. The specific content of the Capability Grant Set can be selected by the user through the interactive components of the second device, or the second device can grant a minimum set of capabilities based on a default policy.

[0314] The second device stores the Authorized Host Stored (which stores authorized host information, including host identifier and capability authorization set) in its secure storage area, without exposing internal keys such as the device root key to the first device. After binding is complete (Bind OK), the second device changes its status bit to S1: BOUND_IDLE.

[0315] When the second device reconnects to the first device, the driver on the first device reads the status bit of the second device and finds that the second device is currently in the S1: BOUND_IDLE state, indicating that the second device has previously established an authorization relationship with a first device, but has not yet completed authentication for this connection. Because the second device is in the S1: BOUND_IDLE state, the first device initiates an authorization request to the second device, requesting the second device to verify the identity of the current first device.

[0316] The second device obtains the host identifier from the authorization request and verifies whether the host identifier matches the authorization identifier stored in its own secure storage area. If the host identifier matches, the second device can also perform challenge-response verification: the second device sends a challenge value to the first device, the first device calculates a response value based on its own key or identifier information and returns it, and the second device verifies whether the response value is correct. If the response value verification is successful, i.e., Challenge-Response Passed, the second device confirms that the first device is currently an authorized host, and the authentication is successful (Auth Success). The second device switches the status bit to S2: AUTHENTICATED and enables the corresponding capability according to the capability authorization set (e.g., Enable MSC, i.e., enabling the mass storage class to expose USB storage capability (USB Storage Exposed)), allowing the first device to access the corresponding capabilities on the second device (such as NPU inference capability, sensor data acquisition capability, secure storage access capability, etc.). During this process, the second device does not expose internal keys such as the device root key to the first device.

[0317] When the second device detects that the first device is not authorized, that is, the second device is currently in the S1: BOUND_IDLE state, but the host identifier carried in the authorization request provided by the first device does not match the authorization identifier stored in the second device's secure storage area, the second device determines that the first device is an unauthorized host and authentication fails (Auth / RebindFail).

[0318] The second device enters the S4: WAIT_REBIND_PROOF state, waiting for the user to provide a recovery key for rebinding verification. Specifically, the second device outputs a prompt message to the first device via the communication interface, instructing the user to enter a recovery key. After receiving this prompt message, the driver or accompanying software on the first device displays an interactive interface to the user, prompting the user to enter the recovery key (Require ORS Input), that is, prompting the user to enter the recovery key generated by the second device during the initial binding.

[0319] The recovery key is generated when the second device is first powered on and is shown to the user through a physical display or a one-time method. The user must keep it safe. The recovery key is used to re-establish the authorization relationship in the event of a lost or replaced host device.

[0320] The user enters the recovery key through the interactive interface on the first device. The first device then sends the entered recovery key to the second device, i.e., the second device receives a rebind request. The second device verifies the validity of the recovery key, that is, it verifies whether the recovery key entered by the user matches the recovery key stored in its own secure storage area.

[0321] If the recovery key verification is successful (Rebind OK), the second device will perform the following operations:

[0322] Remove the authorization relationship of the old host, that is, clear the authorization record of the original bound host (including the original host identifier and capability authorization set) in the security storage area of ​​the second device.

[0323] Generate a new host identifier and capability authorization set for the current first device and store it in the secure storage area of ​​the second device;

[0324] Rewrite the status bit to S1: BOUND_IDLE, allowing the current first device to authenticate via authorization request in subsequent accesses.

[0325] If the recovery key verification fails, the second device can increment the failure count. When the number of consecutive failures exceeds a preset threshold, i.e., the Too Many Failures condition is reached, the second device enters the S_EER:LOCKED state and rejects any subsequent binding or authorization requests to prevent brute-force attacks.

[0326] If the recovery key cannot be provided (e.g., the user has lost the recovery key), the second device can enter a secure reset mode, clear all authorized host information, local knowledge base and sensor data, and regenerate the device root key to ensure that no historical data can be recovered.

[0327] The processing apparatus provided in this application will be described below. The processing apparatus described below can be referred to in correspondence with the processing method described above.

[0328] The processing device may include:

[0329] The detection module is used to detect the matching relationship between the second device and the first device in response to the connection between the second device and the first device.

[0330] The acquisition module is used to acquire the decryption key corresponding to the matching relationship.

[0331] The first decryption module is used to decrypt the key packet to be used corresponding to the matching relationship among the multiple key packets contained in the second device based on the decryption key, so as to obtain the target key; wherein the multiple key packets are obtained by encrypting the same target key using different encryption keys.

[0332] The processing module is configured to, in response to the access request from the first device to the second device, encrypt or decrypt the data corresponding to the access request based on the target key.

[0333] In this embodiment, the matching relationship may include matching between the second device and the first device;

[0334] The key packet to be used corresponding to the matching relationship may include: a first key packet; the first key packet is obtained by encrypting the first encryption key in the first key pair;

[0335] The decryption key corresponding to the matching relationship may include: the first decryption key in the first key pair;

[0336] The first key pair is generated locally by the first device, and the first decryption key is stored locally on the first device and cannot be transferred to other devices.

[0337] In this embodiment, the matching relationship may include: the second device and the first device are not matched;

[0338] The key packet to be used corresponding to the matching relationship may include: a second key packet; the second key packet is obtained by encrypting the second encryption key in the second key pair;

[0339] The decryption key corresponding to the matching relationship may include: the second decryption key in the second key pair;

[0340] The second key pair is generated by an application in the first device, and the second decryption key is stored in a third device other than the first device.

[0341] In this embodiment, the second decryption key can be encrypted with user account information and stored in a third device other than the first device.

[0342] The acquisition module can be used specifically for:

[0343] Obtain the second decryption key from a third device other than the first device;

[0344] Based on the user account information, the encrypted second decryption key is decrypted to obtain the second decryption key.

[0345] In this embodiment, the processing device may further include:

[0346] The selection module is configured to select a third key package as the key package to be used from the plurality of key packages in response to the first device failing to obtain the decryption key corresponding to the matching relationship; the third key package is obtained by encryption based on the third encryption key in the third key pair generated by the security agent program in the first device; the third decryption key in the third key pair is not stored in the first device and the third device; the first device and the third device are used to store the decryption key corresponding to the matching relationship.

[0347] The first prompt module is used to output prompt information to the user in order to obtain the third decryption key provided by the user.

[0348] The second decryption module is used to decrypt the third key packet based on the third decryption key to obtain the target key.

[0349] In this embodiment, the processing device may further include:

[0350] A generation module is used to generate a fourth key pair locally on the first device; the fourth key pair includes a fourth encryption key and a fourth decryption key.

[0351] A storage module is used to store the fourth decryption key locally on the first device; the fourth decryption key cannot be transferred to other devices.

[0352] An encryption module is used to encrypt the target key based on the fourth encryption key to obtain a fourth key packet.

[0353] A replacement module is used to replace the first key packet in the second device with the fourth key packet.

[0354] In this embodiment, the detection module can specifically be used for:

[0355] The system checks whether the external device identifier in the second device is consistent with the device identifier of the first device; the external device identifier is written when a binding relationship is established between the second device and the external device.

[0356] In this embodiment, the processing device may further include:

[0357] The authorization initiation module is used to initiate an authorization request from the first device to the second device, so that the second device can obtain the host identifier from the authorization request, verify whether the host identifier matches the authorization identifier stored in the second device, and if the verification is successful, allow the first device to access;

[0358] The host identifier is generated by the second device based on the device root key and the identifier information of the first device when the first device and the second device first connect.

[0359] In this embodiment, the processing device may further include:

[0360] The second prompt module is used to output a prompt message in response to the second device failing verification, so that after the user enters a recovery key into the second device according to the prompt message, the second device verifies the validity of the recovery key. If the verification is successful, the first device is allowed to access the device. The prompt message is used to prompt the user to enter a recovery key. The recovery key is generated by the second device and is used to verify the access rights of other devices.

[0361] It should also be noted that the device embodiments described above are merely illustrative. The units described as separate components may or may not be physically separate, and the components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the modules can be selected to achieve the purpose of this embodiment according to actual needs. In addition, in the device embodiment drawings provided in this application, the connection relationship between modules indicates that they have a communication connection, which can be implemented as one or more communication buses or signal lines.

[0362] Through the above description of the embodiments, those skilled in the art can clearly understand that this application can be implemented by means of software plus necessary general-purpose hardware, or it can be implemented by special-purpose hardware including application-specific integrated circuits, special-purpose CPUs, special-purpose memory, special-purpose components, etc. Generally, any function performed by a computer program can be easily implemented by corresponding hardware, and the specific hardware structure used to implement the same function can also be diverse, such as analog circuits, digital circuits, or special-purpose circuits. However, for this application, software program implementation is more often the preferred implementation method. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, can be embodied in the form of a software product. This computer software product is stored in a readable storage medium, such as a computer floppy disk, USB flash drive, mobile hard disk, ROM, RAM, magnetic disk, or optical disk, etc., and includes several instructions to cause a computer device (which may be a personal computer, training equipment, or network device, etc.) to execute the methods described in the various embodiments of this application.

[0363] In the above embodiments, implementation can be achieved, in whole or in part, through software, hardware, firmware, or any combination thereof. When implemented in software, it can be implemented, in whole or in part, as a computer program product.

[0364] The computer program product includes one or more computer instructions. When the computer program instructions are loaded and executed on a computer, all or part of the processes or functions described in the embodiments of this application are generated. The computer may be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions may be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another. For example, the computer instructions may be transmitted from one website, computer, training device, or data center to another website, computer, training device, or data center via wired (e.g., coaxial cable, fiber optic, digital subscriber line (DSL)) or wireless (e.g., infrared, wireless, microwave, etc.) means. The computer-readable storage medium may be any available medium that a computer can store or a data storage device such as a training device or data center that integrates one or more available media. The available media may be magnetic media (e.g., floppy disks, hard disks, magnetic tapes), optical media (e.g., DVDs), or semiconductor media (e.g., solid-state drives (SSDs)).

Claims

1. A processing method, comprising: In response to the connection between the second device and the first device, the matching relationship between the second device and the first device is detected; Obtain the decryption key corresponding to the matching relationship; Based on the decryption key, the key packet to be used corresponding to the matching relationship in the multiple key packets contained in the second device is decrypted to obtain the target key; wherein, the multiple key packets are obtained by encrypting the same target key using different encryption keys; In response to the first device's access request to the second device, the data corresponding to the access request is encrypted or decrypted based on the target key.

2. The processing method according to claim 1, wherein the matching relationship includes matching between the second device and the first device; The key packet to be used corresponding to the matching relationship includes: a first key packet; the first key packet is obtained by encrypting a first encryption key in a first key pair; The decryption key corresponding to the matching relationship includes: the first decryption key in the first key pair; The first key pair is generated locally by the first device, and the first decryption key is stored locally on the first device and cannot be transferred to other devices.

3. The processing method according to claim 1, wherein the matching relationship includes: The second device and the first device are not compatible; The key packet to be used corresponding to the matching relationship includes: a second key packet; the second key packet is obtained by encrypting the second encryption key in the second key pair; The decryption key corresponding to the matching relationship includes: the second decryption key in the second key pair; The second key pair is generated by an application in the first device, and the second decryption key is stored in a third device other than the first device.

4. According to the processing method of claim 3, the second decryption key is encrypted with user account information and stored in a third device other than the first device; Obtaining the decryption key corresponding to the matching relationship includes: Obtain the second decryption key from a third device other than the first device; Based on the user account information, the encrypted second decryption key is decrypted to obtain the second decryption key.

5. The processing method according to claim 1, further comprising: In response to the first device failing to obtain the decryption key corresponding to the matching relationship, a third key package is selected from the plurality of key packages as the key package to be used; the third key package is obtained by encryption based on the third encryption key in the third key pair generated by the security agent program in the first device. The third decryption key in the third key pair is not stored in the first device and the third device; the first device and the third device are used to store the decryption key corresponding to the matching relationship; Output a prompt message to the user to obtain the third decryption key provided by the user; Based on the third decryption key, the third key packet is decrypted to obtain the target key.

6. The processing method according to claim 3, after decrypting the key packet to be used based on the decryption key to obtain the target key, further comprising: Generate a fourth key pair locally on the first device; The fourth key pair includes a fourth encryption key and a fourth decryption key; The fourth decryption key is stored locally on the first device; The fourth decryption key cannot be transferred to other devices; The target key is encrypted based on the fourth encryption key to obtain the fourth key packet; Replace the first key packet in the second device with the fourth key packet.

7. The processing method according to claim 1, wherein detecting the matching relationship between the second device and the first device includes: Detect whether the external device identifier in the second device is consistent with the device identifier in the first device; The external device identifier is written when a binding relationship is established between the second device and the external device.

8. The processing method according to claim 1, further comprising, before detecting the matching relationship between the second device and the first device: The first device initiates an authorization request to the second device, so that the second device obtains the host identifier from the authorization request, verifies whether the host identifier matches the authorization identifier stored in the second device, and if the verification is successful, the first device is allowed to access; The host identifier is generated by the second device based on the device root key and the identifier information of the first device when the first device and the second device first connect.

9. The processing method according to claim 8, further comprising: In response to the second device failing verification, a prompt message is output so that the user can enter a recovery key into the second device according to the prompt message. The second device then verifies the validity of the recovery key. If the verification is successful, the first device is allowed to access the device. The prompt message is used to prompt the user to enter a recovery key. The recovery key is generated by the second device and is used to verify the access rights of other devices.

10. A processing apparatus, comprising: The detection module is used to detect the matching relationship between the second device and the first device in response to the connection between the second device and the first device; The acquisition module is used to acquire the decryption key corresponding to the matching relationship; The first decryption module is used to decrypt the key packet to be used corresponding to the matching relationship among the multiple key packets contained in the second device based on the decryption key, so as to obtain the target key; wherein the multiple key packets are obtained by encrypting the same target key using different encryption keys; The processing module is configured to, in response to the access request from the first device to the second device, encrypt or decrypt the data corresponding to the access request based on the target key.

Images