A data processing method and device, electronic equipment, chip and medium

Abstract

This disclosure provides a data processing method, apparatus, electronic device, chip, and medium, relating to the field of data encryption and decryption technology. It includes: acquiring target data corresponding to a first request; in response to the target data including file data and attribute data, generating a target key, the target key including a first key corresponding to the attribute data, a second key corresponding to the file data, and a starting offset of the file data within the target data; and processing the target data corresponding to the first request based on the target key. This disclosure determines the type of target data targeted by the first request, thereby assigning different keys to the file data and attribute data respectively, to achieve partitioned encryption and decryption of the file data and attribute data, saving storage space, improving storage efficiency, and further reducing the number of I / O requests.

Description

Technical Field

[0001] This disclosure relates to the field of data encryption and decryption technology, and in particular to a data processing method and apparatus, electronic device, chip and medium. Background Technology

[0002] In the field of storage devices, hardware encryption is widely used in self-encrypting drives. Hardware encryption refers to using a specially designed hardware encryption engine to perform encryption and decryption operations, rather than relying entirely on software implementation. Summary of the Invention

[0003] This disclosure provides a data processing method and apparatus, electronic device, chip and medium, and provides a scheme for encrypting and decrypting file data and attribute data by configuring keys separately.

[0004] A first aspect of this disclosure provides a data processing method, comprising: acquiring target data corresponding to a first request; generating a target key in response to the target data including file data and attribute data, the target key including a first key corresponding to the attribute data, a second key corresponding to the file data, and a starting offset of the file data in the target data; and processing the target data corresponding to the first request based on the target key.

[0005] In some embodiments of this disclosure, the method further includes: determining the type of target data corresponding to the first request; and determining key configuration information corresponding to the first request based on the type of target data, wherein the key configuration information is used to generate a target key.

[0006] In some embodiments of this disclosure, the key configuration information corresponding to the first request is determined based on the type of the target data, including any of the following: in response to the target data being of a first type, the key configuration information is determined to include configuration parameters of a second key; in response to the target data being of a second type, the key configuration information is determined to include configuration parameters of a first key; in response to the target data being of a third type, the key configuration information is determined to include configuration parameters of a first key; in response to the target data being of a fourth type, the key configuration information is determined to include configuration parameters of a first key, configuration parameters of a second key, and a starting offset.

[0007] In some embodiments of this disclosure, the target data corresponding to the first request is processed based on the target key, including: in response to the first request being a write request, the target data corresponding to the write request is encrypted using the target key.

[0008] In some embodiments of this disclosure, the target data corresponding to the write request is encrypted using a target key, including at least one of the following: encrypting the file data using a second key based on a starting offset, and writing the second key and the key index corresponding to the starting offset into the attribute data; encrypting the attribute data using a first key.

[0009] In some embodiments of this disclosure, target processing is performed on target data corresponding to the first request based on the target key, including: in response to the first request being an access request, decrypting the target data corresponding to the access request using the target key.

[0010] In some embodiments of this disclosure, decrypting the target data corresponding to the access request using the target key includes at least one of the following: decrypting the attribute data in the target data corresponding to the access request using a first key; and decrypting the file data in the target data corresponding to the access request using a second key based on the starting offset.

[0011] In some embodiments of this disclosure, the method further includes: in response to the target data corresponding to the access request meeting preset conditions, decrypting the attribute data using a first key to determine the key index and starting offset of the file data; and determining a second key based on the key index.

[0012] In some embodiments of this disclosure, determining the second key based on the key index includes any of the following: in response to the key index indicating that the type of file data is the same as the type of the parent directory of the file data, determining the key corresponding to the parent directory as the second key; in response to the key index indicating that the file data is a preset type, generating the second key based on the configuration parameters corresponding to the file data.

[0013] In the above embodiments, by determining the type of target data targeted by the first request, different keys are assigned to file data and attribute data respectively, so as to realize partitioned encryption and decryption of file data and attribute data, saving storage space, improving storage efficiency, and further reducing the number of IO requests.

[0014] A second aspect of this disclosure provides a data processing apparatus, including an acquisition module, a determination module, and a processing module. The acquisition module is used to acquire target data corresponding to a first request. The determination module is used to generate a target key in response to the target data including file data and attribute data. The target key includes a first key corresponding to the attribute data, a second key corresponding to the file data, and a starting offset of the file data in the target data. The processing module is used to process the target data corresponding to the first request based on the target key.

[0015] In some embodiments of this disclosure, the determining module is further configured to: determine the type of target data corresponding to the first request; and, based on the type of target data, determine key configuration information corresponding to the first request, wherein the key configuration information is used to generate a target key.

[0016] In some embodiments of this disclosure, the determining module is further configured to, in response to the target data being of a first type, determine that the key configuration information includes configuration parameters of a second key; in response to the target data being of a second type, determine that the key configuration information includes configuration parameters of a first key; in response to the target data being of a third type, determine that the key configuration information includes configuration parameters of a first key; and in response to the target data being of a fourth type, determine that the key configuration information includes configuration parameters of a first key, configuration parameters of a second key, and a starting offset.

[0017] In some embodiments of this disclosure, the processing module is further configured to: encrypt the target data corresponding to the write request using the target key in response to the first request being a write request; and decrypt the target data corresponding to the access request using the target key in response to the first request being an access request.

[0018] In the above embodiments, by determining the type of target data targeted by the first request, different keys are assigned to file data and attribute data respectively, so as to realize partitioned encryption and decryption of file data and attribute data, saving storage space, improving storage efficiency, and further reducing the number of IO requests.

[0019] A third aspect of this disclosure provides an electronic device including: a processor and a memory for storing a computer program capable of running on the processor, wherein the processor, when running the computer program, performs the method described in any embodiment of the first aspect of this disclosure, or includes the apparatus described in any embodiment of the second aspect of this disclosure.

[0020] A fourth aspect of this disclosure provides a non-transitory computer-readable storage medium storing computer instructions for causing a computer to perform the methods described in any of the embodiments of the first aspect of this disclosure.

[0021] A fifth aspect of this disclosure provides a program product including computer instructions for causing a computer to perform the methods described in any of the embodiments of the first aspect of this disclosure.

[0022] A sixth aspect of this disclosure provides a chip including at least one processor and a communication interface; the communication interface is used to receive signals input to the chip or signals output from the chip, and the processor communicates with the communication interface and implements the method described in any one of the first aspects of this disclosure through logic circuits or executing code instructions.

[0023] In summary, the data processing method, apparatus, electronic device, chip, and medium proposed in this disclosure include: acquiring target data corresponding to a first request; generating a target key in response to the target data including file data and attribute data, the target key including a first key corresponding to the attribute data, a second key corresponding to the file data, and a starting offset of the file data in the target data; and processing the target data corresponding to the first request based on the target key. This disclosure determines the type of target data targeted by the first request, thereby assigning different keys to the file data and attribute data respectively, to achieve partitioned encryption and decryption of the file data and attribute data, saving storage space, improving storage efficiency, and further reducing the number of I / O requests.

[0024] It should be understood that the above general description and the following detailed description are exemplary and explanatory only, and are not intended to limit this disclosure. Attached Figure Description

[0025] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this disclosure and, together with the description, serve to explain the principles of this disclosure, and are not intended to unduly limit this disclosure.

[0026] Figure 1 This is a flowchart of a data processing method proposed in an embodiment of the present disclosure;

[0027] Figure 2 This is a schematic flowchart of a data processing method proposed in an embodiment of this disclosure;

[0028] Figure 3 This is a schematic flowchart of a data processing method proposed in an embodiment of this disclosure;

[0029] Figure 4 This is a schematic flowchart of a data processing method proposed in an embodiment of this disclosure;

[0030] Figure 5A This is an encryption / decryption framework that enables both file-level encryption and metadata encryption.

[0031] Figure 5B A flowchart illustrating the process of local hardware encryption for stored data;

[0032] Figure 5C Flowchart for configuring the key;

[0033] Figure 6 This is a schematic diagram of the structure of a data processing apparatus according to an embodiment of the present disclosure;

[0034] Figure 7 This is a schematic diagram of the structure of the electronic device proposed in the embodiments of this disclosure. Detailed Implementation

[0035] Embodiments of this disclosure are described in detail below. Examples of these embodiments are illustrated in the accompanying drawings, wherein the same or similar reference numerals denote the same or similar elements or elements having the same or similar functions throughout. The embodiments described below with reference to the accompanying drawings are exemplary and intended to explain this disclosure, and should not be construed as limiting this disclosure.

[0036] The device that performs hardware encryption has a hardware encryption engine embedded inside the controller, which encrypts all data stored on the drive in real time.

[0037] Hardware encryption ensures that when data is written to the system, it is first encrypted by a hardware encryption engine before being stored in flash memory. When data is read, the hardware decrypts it before it is transmitted to the system. The entire process is transparent to the operating system and applications, and no additional software processing is required from the user.

[0038] Hardware encryption schemes typically come with a dedicated key management mechanism, supporting secure key storage, dynamic allocation, and rotation. In the Android system, keys are primarily stored in a separate secure environment, and different key management schemes exist depending on the encryption scheme. Using an inline hardware encryption engine to process large amounts of secure data can reduce latency and lighten the load on the main processor, thereby providing better real-time system performance. Inline hardware encryption handles symmetric encryption and batch encryption, while software encryption handles authentication, key, and filename encryption.

[0039] Hardware encryption schemes in related technologies encrypt and decrypt single I / O requests only on a block-by-block basis, which has the following drawbacks: The inode of the file system stores the index of the encryption key, therefore it is impossible to use the same key as the file content for encryption. Since the size of a file inode is generally much smaller than the block size, the data block to which the inode belongs could originally be used to store the end-of-file data; this feature cannot be used after encryption is enabled.

[0040] To address the technical problems of the aforementioned solutions, this disclosure proposes a data processing method that, for an IO request, determines the type of the requested data block and then assigns keys for encryption and decryption of the file data and metadata, respectively.

[0041] The data processing method provided in this application will be described in detail below with reference to the accompanying drawings.

[0042] Figure 1 This is a flowchart of a data processing method proposed in an embodiment of the present disclosure, as follows: Figure 1 As shown, the method includes the following steps:

[0043] Step 101: Obtain the target data corresponding to the first request.

[0044] In some embodiments, the first request may be an I / O request submitted by the application (APPS) to the host system.

[0045] In some embodiments, such as Figure 5A The encryption / decryption framework diagram shown illustrates that the application submits I / O requests using the interface provided by the file system. The file system manages the I / O requests, parses out the location of the data to be operated on, and submits it to the underlying encryption device.

[0046] In some embodiments, the first request can be either a write request or an access request. A write request can be for writing data to flash memory, while an access request can be for reading data from flash memory. During the write process, the written data needs to be encrypted and stored; during the read process, the original data needs to be decrypted to retrieve it.

[0047] In some embodiments, the first request can be divided into two categories: one is metadata, which stores the attribute information of the file data, and the other is the file data. Different files are classified differently. Files of the same type are encrypted with the same key, while files of different types are encrypted with different keys. These keys are configured by the file system.

[0048] In some embodiments, for a first request, the logical block address and block type can be calculated based on the requested data address, thereby determining the target data.

[0049] In some embodiments, such as Figure 5BThe overall process diagram shown illustrates the following steps: Upon initial startup of the host system, credentials are generated by calling the Keymaster HAL to generate a key. The Keymaster HAL communicates with the TEE via the TEE driver, submitting the request to the Keymaster TA. The Keymaster TA sends a request to the Key manager service to generate a unique key for the host based on the credentials. After successful key generation, or upon system restart, the vold module, based on the credentials corresponding to the key, calls the Keymaster HAL to request the key. The Keymaster HAL communicates with the TEE via the TEE driver, submitting the request to the Keymaster TA. The Keymaster TA sends a request to the Key manager service to obtain the key corresponding to the host and verifies it using credentials. If verification is successful, the key index is returned. After obtaining the key index, vold configures it in kerneling. When an application initiates an I / O request, it retrieves the key index from kerneling, configures the key index in the I / O request, encapsulates the I / O request (including LBA, data type, key index, etc.), and submits it to the ufs driver.

[0050] In some embodiments, the method further includes: determining the type of target data corresponding to the first request; and determining key configuration information corresponding to the first request based on the type of target data, wherein the key configuration information is used to generate a target key.

[0051] In some embodiments, the target data corresponding to the first request may be a metadata block, such as an inode data block, superblock, block group descriptor, or directory block in the metadata block, or it may be a file data block.

[0052] In some embodiments, by determining the type of target data, the corresponding key configuration information can be determined for subsequent generation of the target key.

[0053] In some embodiments, based on the type of the target data, the key configuration information corresponding to the first request is determined to include any of the following: in response to the target data being of a first type, the key configuration information is determined to include configuration parameters of a second key; in response to the target data being of a second type, the key configuration information is determined to include configuration parameters of a first key; in response to the target data being of a third type, the key configuration information is determined to include configuration parameters of a first key; in response to the target data being of a fourth type, the key configuration information is determined to include configuration parameters of a first key, configuration parameters of a second key, and a starting offset.

[0054] In some embodiments, the first type may be a file data block, i.e., a data block that only includes file data.

[0055] In some embodiments, when the target data is of the first type, the key configuration parameters of the configuration file data are required, that is, the key configuration information only includes the configuration parameters of the second key.

[0056] In some embodiments, the second type can be a non-inode data block in the metadata block, that is, a metadata block but not an inode data block.

[0057] In some embodiments, when the target data is of the second type, it is necessary to configure the key configuration parameters of the metadata block, that is, the key configuration information only includes the configuration parameters of the first key.

[0058] In some embodiments, the third type may be an inode data block, and the inode data block may only include attribute data, which is metadata, and the metadata is data that reflects information such as data block attributes and parameters.

[0059] In some embodiments, when the target data is of type three, it is necessary to configure the key configuration parameters of the metadata block, that is, the key configuration information only includes the configuration parameters of the first key.

[0060] In some embodiments, the fourth type may be an inode data block, and the inode data block includes file data and attribute data.

[0061] In some embodiments, when the target data is of type four, key configuration parameters for configuration file data and attribute data are required, that is, the key configuration information includes configuration parameters for the first key, configuration parameters for the second key, and starting offset.

[0062] For example, Figure 5C The diagram shows the key configuration flowchart. Different key configuration processes exist depending on the I / O data type. First, determine the file type targeted by the I / O request: file data, non-inode metadata, or inode data. If the I / O does not belong to the metadata block, configure the data key; if the I / O belongs to the metadata block but not the inode data block, configure the metadata key; if the I / O belongs to the inode data block but does not contain file data, configure the metadata key; if the I / O belongs to the inode data block and contains file data, and the data key index is known, configure the data key and starting offset; if the data key index is unknown, configure the metadata key, then configure the data key and starting offset.

[0063] In some embodiments, by determining the key configuration information corresponding to the target data, the relevant parameters for generating the target key can be determined for use in subsequent processes to generate the target key.

[0064] In some embodiments, a first key is generated in response to the target data being attribute data.

[0065] In some embodiments, a second key is generated in response to the target data being file data.

[0066] For example, the ufs driver sends the root key index and derived parameters (containing LBA / data type) to the TEE, causing the TEE to return the key.

[0067] Step 102: In response to the target data, including file data and attribute data, generate a target key.

[0068] In some embodiments, the target key includes a first key corresponding to the attribute data, a second key corresponding to the file data, and the starting offset of the file data in the target data.

[0069] In some embodiments, attribute data may be data representing attribute information of the target data, and file data may be data of the actual valid files stored in the target data.

[0070] In some embodiments, the target data includes file data and attribute data; that is, the position from the beginning to the starting offset in the data block is attribute data, and the position from the starting offset to the end is file data. When both file data and attribute data are stored in a data block, two different keys can be generated to encrypt and decrypt the two data separately.

[0071] In some embodiments, in response to the target data including file data and attribute data, a target key including a first key, a second key, and a starting offset can be generated based on the key configuration information.

[0072] For example, such as Figure 5B The overall flowchart shows that the UFS driver sends the root key index and derivation parameters to the TEE. The TEE requests a derivation key from the keymaster TA. The keymaster TA returns the derivation key to the TEE, including the key for file data and the key for metadata. The TEE returns the key to the UFS driver, which then transmits the derivation key and encryption area information to the UFS controller via the UTRD field. The UTRD field supports configuring the local encryption key and the local encryption start address.

[0073] For example, the unique key generated for the host system is the device-level root key. Different keys for file data and metadata are dynamically derived during IO requests. The key generated on the TEE side is the encryption seed. In subsequent use, vold will derive two sub-keys from the root key through the key derivation parameter: one for encrypting and decrypting file data, and the other for encrypting and decrypting metadata.

[0074] Step 103: Process the target data corresponding to the first request based on the target key.

[0075] In some embodiments, depending on the type of the first request, processing the target data based on the target key can be either encrypting or decrypting the target data.

[0076] In some embodiments, when the target data is attribute data, the target data is encrypted or decrypted using a first key.

[0077] In some embodiments, when the target data is file data, the target data is encrypted or decrypted using a second key.

[0078] For example, the hardware encryption engine inside the UFS controller encrypts and decrypts a single data block based on the key information in the UTRD. When two keys are configured, the local encryption key is used to encrypt and decrypt the region from the start address of the local encryption to the end, while the single key is used to encrypt and decrypt other regions.

[0079] In the above embodiments, by determining the type of target data targeted by the first request, different keys are assigned to file data and attribute data respectively, so as to realize partitioned encryption and decryption of file data and attribute data, saving storage space, improving storage efficiency, and further reducing the number of IO requests.

[0080] Figure 2 This is a flowchart illustrating a data processing method proposed in an embodiment of this disclosure, based on... Figure 1 The illustrated embodiments, such as 2 pairs Figure 1 Step 103 in the text will be further explained, such as... Figure 2 As shown, the method includes the following steps:

[0081] Step 201: In response to the first request being a write request, the target data corresponding to the write request is encrypted using the target key.

[0082] In some embodiments, encrypting the target data corresponding to the write request using a target key includes at least one of the following: encrypting the file data using a second key based on a starting offset, and writing the second key and the key index corresponding to the starting offset into the attribute data; encrypting the attribute data using a first key.

[0083] In some embodiments, if the first request is a write request, then the corresponding data processing process is the encryption process. After generating the target key, the target key can be used to encrypt file data and / or attribute data.

[0084] In some embodiments, the specific process of encryption is not limited in this disclosure.

[0085] In some embodiments, the starting offset is the starting position of the file data in the target data. Based on the starting offset, the file data can be encrypted using a second key to obtain the key index corresponding to the second key and the starting offset.

[0086] In some embodiments, the key index needs to be written into attribute data for storage so that the key index can be parsed during the decryption process to determine the corresponding key.

[0087] In some embodiments, when the target data includes only file data, the starting offset can be the starting position of the target data, or it can be zero, which means that encryption processing needs to be performed from the beginning of the target data to obtain encrypted file data.

[0088] In some embodiments, where the target data includes only attribute data, the attribute data is encrypted using a first key to obtain encrypted attribute data.

[0089] In some embodiments, where the target data includes file data and attribute data, after encrypting the file data using a second key, the key index is written into the attribute data, and the attribute data is encrypted using a first key, thereby obtaining the encrypted target data.

[0090] In some embodiments, after encrypting the target data, the encrypted target data can be written into flash memory.

[0091] In the above embodiments, by using keys generated for different types of target data to encrypt the target data, different keys are used to encrypt file data and attribute data. This saves storage space, improves storage efficiency, and further reduces the number of IO requests during storage.

[0092] Figure 3 This is a flowchart illustrating a data processing method proposed in an embodiment of this disclosure, based on... Figure 1 , Figure 2 The illustrated embodiments, such as 3 pairs Figure 1 Step 103 in the text will be further explained, such as... Figure 3 As shown, the method includes the following steps:

[0093] Step 301: In response to the first request being an access request, the target data corresponding to the access request is decrypted using the target key.

[0094] In some embodiments, decrypting the target data corresponding to the access request using the target key includes at least one of the following: decrypting the attribute data in the target data corresponding to the access request using a first key; and decrypting the file data in the target data corresponding to the access request using a second key based on the starting offset.

[0095] In some embodiments, an access request may be an application-initiated request to read data stored in flash memory.

[0096] In some embodiments, after a target key is generated based on an access request, the target key can be used to decrypt the target data.

[0097] In some embodiments, where the target data only includes file data, the target data is decrypted using a second key based on the starting offset to obtain the original file data. Here, the starting offset is either the starting position of the target data or zero.

[0098] In some embodiments, if the target data includes only attribute data, the target data is decrypted using a first key to obtain the original attribute data.

[0099] In some embodiments, where the target data includes file data and attribute data, the file data is decrypted using a second key based on the starting offset, and the attribute data is decrypted using a first key, thereby obtaining the original target data.

[0100] In some embodiments, after encrypting the target data, the encrypted target data can be written into flash memory.

[0101] In the above embodiments, by using keys generated for different types of target data to decrypt the target data, the reading efficiency is improved and the number of IO requests is further reduced.

[0102] Figure 4 This is a flowchart illustrating a data processing method proposed in an embodiment of this disclosure, based on... Figure 1 , Figure 2 , Figure 3 The illustrated embodiment, as shown in example 4, will be further described, as follows: Figure 4 As shown, the method includes the following steps:

[0103] Step 401: In response to the target data corresponding to the access request meeting the preset conditions, the attribute data is decrypted using the first key to determine the key index and starting offset of the file data.

[0104] In some embodiments, the preset condition may be "first read" or "first time reading".

[0105] In some embodiments, during the initial read, the key index of the file data is stored in the attribute data, so the attribute data needs to be decrypted first to obtain the key index and starting offset of the file data.

[0106] In some embodiments, the key index and starting offset of the file data are attribute data written during the encryption process, and the key index and the encryption key of the file data have a corresponding relationship.

[0107] In some embodiments, during the first read, the attribute data is decrypted using the first key. This can be done by decrypting the entire target data using the first key. However, since the encryption key used for the part of the file data is different from that used for the attribute data, only the attribute data can be decrypted by the first key. The part of the file data will result in garbled data after decryption, and this part of the data is unusable. However, since the attribute data has been decrypted, the key index and starting offset of the file data can be obtained.

[0108] For example, if the IO data is inode data, but it is the first time reading it, since the data key needs to be obtained from the inode data, the data key index is unknown at this time. Only the metadata key can be configured. After the inode data is read, the data key and the data starting offset can be configured.

[0109] Step 402: Determine the second key based on the key index.

[0110] In some embodiments, by decrypting the attribute data, the key index corresponding to the second key is obtained. Based on the correspondence between the key index and the key, the second key corresponding to the file data can be determined.

[0111] In some embodiments, determining the second key based on the key index includes any of the following: in response to the key index indicating that the type of file data is the same as the type of the parent directory of the file data, determining the key corresponding to the parent directory as the second key; in response to the key index indicating that the file data is a preset type, generating the second key based on the configuration parameters corresponding to the file data.

[0112] In some embodiments, the key index may include a key identifier that can be used to indicate the type of file data, so as to employ a different determination method for the second key according to the indication of the key index.

[0113] In some embodiments, if the file data exists in a parent directory and the parent directory is of the same type as the file data, since file data of the same type uses the same key for encryption and decryption, the key corresponding to the parent directory can be directly obtained and determined as the second key. Therefore, it is not necessary to repeatedly decrypt the attribute data. After determining the second key, the first key and the second key can be used to decrypt the attribute data and the file data respectively to obtain the original file data and attribute data.

[0114] In some embodiments, in response to a key index indicating that the file data is of a preset type, a second key is generated based on the configuration parameters corresponding to the file data. The preset type can be an independent file type, meaning the file data does not exist in a parent directory or its type is different from the parent directory; in such cases, a second key needs to be generated based on the configuration parameters corresponding to the file data.

[0115] In some embodiments, the configuration parameters corresponding to the file data can be obtained from the attribute data by decrypting the attribute data.

[0116] In summary, the data processing method proposed in this disclosure determines the type of target data for the first request and assigns different keys to file data and attribute data respectively, thereby enabling partitioned encryption and decryption of file data and attribute data, saving storage space, improving storage efficiency, and further reducing the number of IO requests.

[0117] The following is a specific implementation of a local hardware encryption method for storing data provided in this disclosure:

[0118] This solution is applicable to scenarios where the keys required for encrypting or decrypting specific data blocks differ from those required for other data.

[0119] Figure 5A This is an encryption / decryption framework with file-level encryption and metadata encryption enabled. Applications (APPS) submit I / O requests using interfaces provided by the filesystem. The filesystem manages the I / O requests, parses the location of the data to be manipulated, and submits it to the underlying cryptographic block device (DM).

[0120] IO requests are divided into two categories. One category is metadata, which stores file system and file attribute information. When metadata encryption is enabled, the same key is used for encryption, and the key is configured by the encryption block device. The other category is file data. Different files are classified differently. Files of the same type are encrypted with the same key, while files of different types are encrypted with different keys, and these keys are configured by the file system.

[0121] In this scheme, the inode data block simultaneously stores file system metadata and file data, requiring two different keys to encrypt and decrypt different locations within a single data block. When the inode data block does not contain file data, the metadata key is configured by the encryption block device, and then configured into the UFS hardware's key register via the UFS driver. When the inode data block contains file data, the metadata key is configured by the encryption block device using the file system configuration key and the file data start offset, and then configured into the UFS hardware's key register via the UFS driver. During actual I / O processing, the UFS hardware uses different keys for encryption and decryption at different locations within the data block, based on the number of keys and the encryption / decryption start offset.

[0122] Figure 5B This is a flowchart illustrating the process of local hardware encryption for stored data. As shown, the key is centrally managed by the TEE side. During system startup, the vold module retrieves the key from the TEE side based on the credentials corresponding to the key and stores it in the kernel. The file system and encryption block device retrieve the key from the kernel and configure it for IO requests, sending them to the ufs driver. The ufs driver is responsible for passing the key information to the ufs controller, which performs encryption and decryption based on the key information. Therefore, the following part is added:

[0123] 1. The UFS driver transmits encrypted information via UTRD (UTP Transfer Request Descriptor), currently only supporting configuration of a single key. Therefore, the UTRD field needs to be expanded to support configuration of local encryption keys and local encryption start addresses.

[0124] 2. The hardware encryption engine inside the UFS controller encrypts and decrypts individual data blocks based on the key information in the UTRD. When only a single key is configured, the entire data block is encrypted and decrypted; when two keys are configured, the local encryption key is used to encrypt and decrypt the region from the start address of the local encryption to the end, while the original single key is used to encrypt and decrypt other regions.

[0125] The overall process is as follows:

[0126] 1. Upon initial system startup, vold generates credentials and calls the Keymaster HAL to generate a key. The Keymaster HAL communicates with the TEE via the TEE driver, submitting the request to the Keymaster TA. The Keymaster TA then sends a request to the Keymanager service to generate a unique key for the host based on the credentials.

[0127] 2. After successful key generation, or upon system restart, the vold module, based on the credentials corresponding to the key, calls the Keymaster HAL to request the key. The Keymaster HAL communicates with the TEE via the TEE driver, submitting the request to the Keymaster TA. The Keymaster TA sends a request to the Key manager service to obtain the key corresponding to the host and verifies it using credentials. If verification is successful, it returns the key's index. After obtaining the key's index, vold configures it in the kernel.

[0128] 3. When the application initiates an IO request, it obtains the key index from the kernel, configures the key index into the IO request, and submits it to the ufs driver.

[0129] 4. When configuring the key index, there are different key configuration procedures depending on the IO data type. Figure 5C Flowchart for key configuration. Determine the file type of the IO request: file data, non-inode metadata, or inode data. If the IO does not belong to a metadata block, configure the data key; if the IO belongs to a metadata block but not an inode data block, configure the metadata key; if the IO belongs to an inode data block but does not contain file data, configure the metadata key; if the IO belongs to an inode data block and contains file data, and the data key index is known, configure the data key and starting offset; if the data key index is unknown, configure the metadata key, then configure the data key and starting offset.

[0130] a. If the IO is file data, then directly configure the corresponding data key.

[0131] b. If the IO belongs to non-inode metadata, or inode data that does not contain file data, then configure the metadata key directly.

[0132] c. If the IO data is inode data, but this is the first read, the data key needs to be obtained from the inode data. Since the data key index is unknown at this time, only the metadata key can be configured. The data key and data start offset can be configured after the inode data is read. Furthermore, if the file and its parent directory use the same type of data key, this data key can be configured during the first read, and the inode data can be read repeatedly.

[0133] 5. The ufs driver queries the keyslot register index corresponding to the key. If it is not configured in the register, the key index is passed to the TEE.

[0134] 6. The TEE retrieves the corresponding key based on the index, configures the key in the keyslot register of the UFS controller, and returns the corresponding keyslot register index. The UFS driver adds the keyslot register index to the I / O request and submits it to the UFS controller.

[0135] 7. The UFS controller finds the corresponding key based on the index and uses the key to encrypt and decrypt the data. When only a single key is configured, the entire data block is encrypted and decrypted. When two keys are configured, the local encryption key is used to encrypt and decrypt the area from the start address of the local encryption to the end, while the original single key is used to encrypt and decrypt other areas.

[0136] In summary, the beneficial effects of this embodiment are as follows:

[0137] When encrypting and decrypting inode data blocks in a file system, the local data storing the end of the file can use a different key than other data. This allows the file system inode data blocks to store the end of the file even with hardware encryption enabled, thus saving storage space. In certain situations, reading and writing this portion of data can also be completed in the same I / O operation as reading and writing the inode data, reducing the amount of I / O.

[0138] When hardware encryption is enabled, if storing a large number of small files (less than 3KB) on the device results in significantly less storage space usage compared to other devices, similar to storage space usage without encryption, this indicates that the data for these small files is stored in inode data blocks without occupying additional data blocks. Therefore, the hardware encryption scheme is compatible with this characteristic. All cases meeting this scenario should be protected under this scheme.

[0139] Figure 6 This is a schematic diagram of the structure of a data processing apparatus 600 according to an embodiment of this disclosure. Figure 6 As shown, the device includes: an acquisition module 610, a determination module 620, and a processing module 630.

[0140] The acquisition module is used to acquire the target data corresponding to the first request;

[0141] The determination module is used to generate a target key in response to the target data, which includes file data and attribute data. The target key includes a first key corresponding to the attribute data, a second key corresponding to the file data, and the offset of the file data in the target data.

[0142] The processing module is used to process the target data corresponding to the first request based on the target key.

[0143] In some embodiments, the determining module is further configured to: determine the type of target data corresponding to the first request; and determine key configuration information corresponding to the first request based on the type of target data, wherein the key configuration information is used to generate a target key.

[0144] In some embodiments, the determining module is further configured to determine, in response to the target data being of a first type, that the key configuration information includes configuration parameters of a second key; in response to the target data being of a second type, that the key configuration information includes configuration parameters of a first key; in response to the target data being of a third type, that the key configuration information includes configuration parameters of a first key; and in response to the target data being of a fourth type, that the key configuration information includes configuration parameters of a first key, configuration parameters of a second key, and a starting offset.

[0145] In some embodiments, the processing module is further configured to: encrypt the target data corresponding to the write request using the target key in response to the first request being a write request; and decrypt the target data corresponding to the access request using the target key in response to the first request being an access request.

[0146] In some embodiments, the processing module is further configured to encrypt the file data using a second key based on the starting offset, and write the second key and the key index corresponding to the starting offset into the attribute data; and encrypt the attribute data using a first key.

[0147] In some embodiments, the processing module is further configured to use a first key to decrypt attribute data in the target data corresponding to the access request; and use a second key to decrypt file data in the target data corresponding to the access request based on the starting offset.

[0148] In some embodiments, the determining module is further configured to, in response to the target data corresponding to the access request meeting preset conditions, use a first key to decrypt the attribute data, determine the key index and starting offset of the file data, and determine a second key based on the key index.

[0149] In some embodiments, the determining module is further configured to determine the key corresponding to the parent directory as the second key in response to the key index indicating that the type of the file data is the same as the type of the parent directory of the file data; and to generate the second key based on the configuration parameters corresponding to the file data in response to the key index indicating that the file data is a preset type.

[0150] The data processing apparatus disclosed herein saves storage space, improves storage efficiency, and further reduces the number of I / O requests.

[0151] Figure 7This is a schematic diagram of the structure of an electronic device 700 for implementing the above-described data processing method, according to an exemplary embodiment.

[0152] Reference Figure 7 The electronic device 700 may include one or more of the following components: a processing component 702, a memory 704, a power supply component 706, a multimedia component 708, an audio component 710, an input / output (I / O) interface 712, a sensor component 714, and a communication component 716.

[0153] Processing component 702 typically controls the overall operation of electronic device 700, such as operations associated with display, telephone calls, data communication, camera operation, and recording operations. Processing component 702 may include one or more processors 720 to execute instructions to complete all or part of the steps of the methods described above. Furthermore, processing component 702 may include one or more modules to facilitate interaction between processing component 702 and other components. For example, processing component 702 may include a multimedia module to facilitate interaction between multimedia component 708 and processing component 702.

[0154] Memory 704 is configured to store various types of data to support the operation of electronic device 700. Examples of this data include instructions for any application or method operating on electronic device 700, contact data, phonebook data, messages, pictures, videos, etc. Memory 704 can be implemented by any type of volatile or non-volatile storage device or a combination thereof, such as static random access memory (SRAM), electrically erasable programmable read-only memory (EEPROM), erasable programmable read-only memory (EPROM), programmable read-only memory (PROM), read-only memory (ROM), magnetic storage, flash memory, magnetic disk, or optical disk.

[0155] Power supply component 706 provides power to various components of electronic device 700. Power supply component 706 may include a power management system, one or more power supplies, and other components associated with generating, managing, and distributing power to electronic device 700.

[0156] Multimedia component 708 includes a screen that provides an output interface between electronic device 700 and user. In some embodiments, the screen may include a liquid crystal display (LCD) and a touch panel (TP). If the screen includes a touch panel, the screen may be implemented as a touchscreen to receive input signals from the user. The touch panel includes one or more touch sensors to sense touches, swipes, and gestures on the touch panel. The touch sensors may sense not only the boundaries of touch or swipe actions but also the duration and pressure associated with the touch or swipe operation. In some embodiments, multimedia component 708 includes a front-facing camera and / or a rear-facing camera. When electronic device 700 is in an operating mode, such as a shooting mode or video mode, the front-facing camera and / or rear-facing camera may receive external multimedia data. Each front-facing camera and rear-facing camera may be a fixed optical lens system or have focal length and optical zoom capabilities.

[0157] Audio component 710 is configured to output and / or input audio signals. For example, audio component 710 includes a microphone (MIC) configured to receive external audio signals when electronic device 700 is in an operating mode, such as call mode, recording mode, and voice recognition mode. The received audio signals may be further stored in memory 704 or transmitted via communication component 716. In some embodiments, audio component 710 also includes a speaker for outputting audio signals.

[0158] I / O interface 712 provides an interface between processing component 702 and peripheral interface modules, such as keyboards, click wheels, buttons, etc. These buttons may include, but are not limited to, home buttons, volume buttons, power buttons, and lock buttons.

[0159] Sensor assembly 714 includes one or more sensors for providing state assessments of various aspects of electronic device 700. For example, sensor assembly 714 may detect the on / off state of electronic device 700, the relative positioning of components such as the display and keypad of electronic device 700, changes in position of electronic device 700 or a component of electronic device 700, the presence or absence of user contact with electronic device 700, orientation or acceleration / deceleration of electronic device 700, and temperature changes of electronic device 700. Sensor assembly 714 may include a proximity sensor configured to detect the presence of nearby objects without any physical contact. Sensor assembly 714 may also include a light sensor, such as a CMOS or CCD image sensor, for use in imaging applications. In some embodiments, sensor assembly 714 may also include an accelerometer, gyroscope, magnetometer, pressure sensor, or temperature sensor.

[0160] Communication component 716 is configured to facilitate wired or wireless communication between electronic device 700 and other devices. Electronic device 700 can access wireless networks based on communication standards, such as WiFi, 2G or 3G, 4G LTE, 5G NR (NewRadio), or combinations thereof. In one exemplary embodiment, communication component 716 receives broadcast signals or broadcast-related information from an external broadcast management system via a broadcast channel. In one exemplary embodiment, communication component 716 also includes a near-field communication (NFC) module to facilitate short-range communication. For example, the NFC module may be implemented based on radio frequency identification (RFID) technology, Infrared Data Association (IrDA) technology, ultra-wideband (UWB) technology, Bluetooth (BT) technology, and other technologies.

[0161] In an exemplary embodiment, the electronic device 700 may be implemented by one or more application-specific integrated circuits (ASICs), digital signal processors (DSPs), digital signal processing devices (DSPDs), programmable logic devices (PLDs), field-programmable gate arrays (FPGAs), controllers, microcontrollers, microprocessors, or other electronic components to perform the methods described above.

[0162] In an exemplary embodiment, a non-transitory computer-readable storage medium including instructions is also provided, such as a memory 704 including instructions, which can be executed by a processor 720 of an electronic device 700 to perform the above-described method. For example, the non-transitory computer-readable storage medium may be a ROM, random access memory (RAM), CD-ROM, magnetic tape, floppy disk, and optical data storage device, etc.

[0163] Embodiments of this disclosure also provide a non-transitory computer-readable storage medium storing computer instructions, wherein the computer instructions are used to cause a computer to perform the data processing methods described in the above embodiments of this disclosure.

[0164] Embodiments of this disclosure also provide a computer program product, including a computer program that is executed by a processor using the data processing method described in the above embodiments of this disclosure.

[0165] Embodiments of this disclosure also propose a chip including at least one processor and a communication interface; the communication interface is used to receive signals input to the chip or signals output from the chip, and the processor communicates with the communication interface and implements the data processing method described in the above embodiments of this disclosure through logic circuits or executing code instructions.

[0166] It should be noted that the terms "first," "second," etc., used in the specification, claims, and accompanying drawings of this disclosure are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments of this disclosure described herein can be implemented in orders other than those illustrated or described herein. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with this disclosure. Rather, they are merely examples of apparatuses, systems, and methods consistent with some aspects of this disclosure as detailed in the appended claims.

[0167] In the description of this specification, the references to terms such as "one embodiment," "some embodiments," "illustrative embodiment," "example," "specific example," or "some examples," etc., indicate that a specific feature, structure, material, or characteristic described in connection with an embodiment or example is included in at least one embodiment or example of this disclosure. In this specification, the illustrative expressions of the above terms do not necessarily refer to the same embodiment or example. Furthermore, the specific features, structures, materials, or characteristics described may be combined in any suitable manner in one or more embodiments or examples.

[0168] Any process or method description in the flowchart or otherwise herein can be understood as representing a module, segment, or portion of code comprising one or more executable instructions for implementing a particular logical function or process, and the scope of preferred embodiments of this disclosure includes additional implementations in which functions may be performed not in the order shown or discussed, including substantially simultaneously or in reverse order depending on the function involved, as will be understood by those skilled in the art to which embodiments of this disclosure pertain.

[0169] The logic and / or steps represented in the flowchart or otherwise described herein, for example, can be considered as a sequenced list of executable instructions for implementing logical functions, and can be embodied in any computer-readable medium for use by, or in conjunction with, an instruction execution system, apparatus, or device (such as a computer-based system, a system including a processing module, or other system that can fetch and execute instructions from, an instruction execution system, apparatus, or device). For the purposes of this specification, "computer-readable medium" can be any means that can contain, store, communicate, propagate, or transmit programs for use by, or in conjunction with, an instruction execution system, apparatus, or device. More specific examples (a non-exhaustive list) of computer-readable media include: an electrical connection having one or more wires (control method), a portable computer disk drive (magnetic device), random access memory (RAM), read-only memory (ROM), erasable and editable read-only memory (EPROM or flash memory), fiber optic device, and portable optical disc read-only memory (CDROM). Furthermore, computer-readable media can even be paper or other suitable media on which programs can be printed, because programs can be obtained electronically, for example, by optically scanning the paper or other media, followed by editing, interpreting, or otherwise processing as necessary, and then stored in computer memory.

[0170] It should be understood that various parts of the embodiments of this disclosure can be implemented in hardware, software, firmware, or a combination thereof. In the above embodiments, multiple steps or methods can be implemented in software or firmware stored in memory and executed by a suitable instruction execution system. For example, if implemented in hardware, as in another embodiment, it can be implemented using any one or a combination of the following techniques known in the art: discrete logic circuits having logic gates for implementing logical functions on data signals, application-specific integrated circuits (ASICs) having suitable combinational logic gates, programmable gate arrays (PGAs), field-programmable gate arrays (FPGAs), etc.

[0171] Those skilled in the art will understand that all or part of the steps of the methods described in the above embodiments can be implemented by a program instructing related hardware. The program can be stored in a computer-readable storage medium, and when executed, the program includes one or a combination of the steps of the method embodiments.

[0172] Furthermore, the functional units in the various embodiments of this disclosure can be integrated into a single processing module, or each unit can exist physically separately, or two or more units can be integrated into a single module. The integrated module can be implemented in hardware or as a software functional module. If the integrated module is implemented as a software functional module and sold or used as an independent product, it can also be stored in a computer-readable storage medium. The aforementioned storage medium can be a read-only memory, a hard disk, or an optical disk, etc.

[0173] Although embodiments of the present disclosure have been shown and described above, it is understood that the above embodiments are exemplary and should not be construed as limiting the present disclosure. Those skilled in the art can make changes, modifications, substitutions and variations to the above embodiments within the scope of the present disclosure.

Claims

1. A data processing method, characterized in that, The method includes: Obtain the target data corresponding to the first request; In response to the target data including file data and attribute data, a target key is generated. The target key includes a first key corresponding to the attribute data, a second key corresponding to the file data, and a starting offset of the file data in the target data. The file data and the attribute data are in the same data block. The attribute data includes the second key and the key index corresponding to the starting offset. Based on the target key, the target data corresponding to the first request is processed.

2. The method according to claim 1, characterized in that, The method further includes: Determine the type of the target data corresponding to the first request; Based on the type of the target data, the key configuration information corresponding to the first request is determined, and the key configuration information is used to generate the target key.

3. The method according to claim 2, characterized in that, Determining the key configuration information corresponding to the first request based on the type of the target data includes any one of the following: In response to the target data being of type 1, it is determined that the key configuration information includes configuration parameters of the second key; In response to the target data being of the second type, it is determined that the key configuration information includes the configuration parameters of the first key; In response to the target data being of type three, it is determined that the key configuration information includes the configuration parameters of the first key; In response to the target data being of type four, the key configuration information is determined to include the configuration parameters of the first key, the configuration parameters of the second key, and the starting offset.

4. The method according to any one of claims 1 to 3, characterized in that, The step of processing the target data corresponding to the first request based on the target key includes: In response to the first request being a write request, the target data corresponding to the write request is encrypted using the target key.

5. The method according to claim 4, characterized in that, The step of encrypting the target data corresponding to the write request using the target key includes at least one of the following: Based on the starting offset, the file data is encrypted using the second key, and the second key and the key index corresponding to the starting offset are written into the attribute data; The attribute data is encrypted using the first key.

6. The method according to any one of claims 1 to 3, characterized in that, The step of performing target processing on the target data corresponding to the first request based on the target key includes: In response to the first request being an access request, the target data corresponding to the access request is decrypted using the target key.

7. The method according to claim 6, characterized in that, The process of decrypting the target data corresponding to the access request using the target key includes at least one of the following: The first key is used to perform the decryption process on the attribute data in the target data corresponding to the access request. Based on the starting offset, the second key is used to perform the decryption process on the file data in the target data corresponding to the access request.

8. The method according to claim 6, characterized in that, The method further includes: In response to the target data corresponding to the access request meeting the preset conditions, the first key is used to perform the decryption process on the attribute data to determine the key index and the starting offset of the file data; The second key is determined based on the key index.

9. The method according to claim 8, characterized in that, The determination of the second key based on the key index includes any of the following: In response to the key index indicating that the type of the file data is the same as the type of the parent directory of the file data, the key corresponding to the parent directory is determined as the second key; In response to the key index indicating that the file data is of a preset type, a second key is generated based on the configuration parameters corresponding to the file data.

10. A data processing apparatus, characterized in that, The device includes an acquisition module, a determination module, and a processing module. The acquisition module is used to acquire the target data corresponding to the first request; The determining module is used to generate a target key in response to the target data including file data and attribute data. The target key includes a first key corresponding to the attribute data, a second key corresponding to the file data, and a starting offset of the file data in the target data. The file data and the attribute data are in the same data block. The attribute data includes the second key and the key index corresponding to the starting offset. The processing module is used to process the target data corresponding to the first request based on the target key.

11. The data processing apparatus according to claim 10, characterized in that, The determining module is also used for: Determine the type of the target data corresponding to the first request; Based on the type of the target data, the key configuration information corresponding to the first request is determined, and the key configuration information is used to generate the target key.

12. The data processing apparatus according to claim 11, characterized in that, The determining module is also used for In response to the target data being of type 1, it is determined that the key configuration information includes configuration parameters of the second key; In response to the target data being of the second type, it is determined that the key configuration information includes the configuration parameters of the first key; In response to the target data being of type three, it is determined that the key configuration information includes the configuration parameters of the first key; In response to the target data being of type four, the key configuration information is determined to include the configuration parameters of the first key, the configuration parameters of the second key, and the starting offset.

13. The data processing apparatus according to claim 12, characterized in that, The processing module is also used for: In response to the first request being a write request, the target data corresponding to the write request is encrypted using the target key; In response to the first request being an access request, the target data corresponding to the access request is decrypted using the target key.

14. An electronic device, characterized in that, include: A processor and a memory for storing a computer program capable of running on the processor, wherein the processor, when running the computer program, performs the method of any one of claims 1 to 9, or includes the means of any one of claims 10 to 13.

15. A non-transitory computer-readable storage medium storing computer instructions, characterized in that, The computer instructions are used to cause the computer to perform the method according to any one of claims 1 to 9.

16. A program product, characterized in that, Includes computer instructions for causing a computer to perform the method of any one of claims 1 to 9.

17. A chip, characterized in that, It includes at least one processor and a communication interface; the communication interface is used to receive signals input to the chip or signals output from the chip, and the processor communicates with the communication interface and implements the method as described in any one of claims 1 to 9 through logic circuits or executing code instructions.

Images