Cryptographic access control method, apparatus, system, device, and readable storage medium

Abstract

This application provides an encrypted access control method, apparatus, system, electronic device, and computer-readable storage medium. It can receive a data access request initiated by a first terminal device; the data access request includes a first encryption public key and data request information; if the data access request from the first terminal device is authorized, encrypted feature data corresponding to the data request information is extracted from an encrypted data container; the encrypted feature data is re-encrypted based on a re-encryption key, generated based on the first encryption public key and a second encryption private key; and the re-encrypted feature data is transmitted to the first terminal device via a secure transmission path. This ensures the feature data owner's complete control over their feature data and guarantees the security of the feature data during storage, transmission, and use.

Description

Technical Field

[0001] This application relates to the technical field of data sharing, specifically to an encrypted access control method, apparatus, system, electronic device, and computer-readable storage medium. Background Technology

[0002] With the widespread adoption of smart devices, users generate a large amount of personal preference data during their use. Each service provider employs a closed data storage system, locking user data within its own ecosystem and preventing data migration between devices across brands and platforms.

[0003] In related technologies, data synchronization is achieved through the service provider's own cloud service platform, while limited data transfer is achieved through third-party migration tools.

[0004] Typically, user data control belongs to the service provider, posing a risk of privacy breaches; terminal devices of cross-brand products cannot communicate with each other, only enabling limited data migration, which cannot guarantee the integrity and authenticity of the data, increasing the risk of new data breaches. Summary of the Invention

[0005] This application provides an encrypted access control method, apparatus, system, electronic device, and computer-readable storage medium to solve the problem of user data sovereignty loss caused by the inability to achieve secure data migration across devices due to data silos in related technologies.

[0006] This application discloses an encrypted access control method, including the following steps: Receive a data access request initiated by a first terminal device; the data access request includes a first encryption public key and data request information; Upon determining that the first terminal device is authorized to access data, encrypted feature data corresponding to the data request information is extracted from the encrypted data container; the encrypted feature data is obtained by encrypting the feature data using the master key of the feature data owner. The encrypted feature data is re-encrypted based on the re-encryption key to obtain re-encrypted feature data; the re-encryption key is generated based on the first encryption public key and the second encryption private key. The re-encrypted feature data is transmitted to the first terminal device via a secure transmission path.

[0007] This application also discloses an encrypted access control device, including: The receiving module is used to receive a data access request initiated by a first terminal device; the data access request includes a first encryption public key and data request information.

[0008] The extraction module is used to extract encrypted feature data corresponding to the data request information from the encrypted data container when it is determined that the data access request of the first terminal device is authorized; the encrypted feature data is obtained by encrypting the feature data using the master key generated by the second terminal device.

[0009] The re-encryption module is used to re-encrypt the encrypted feature data based on the re-encryption key to obtain re-encrypted feature data; the re-encryption key is generated based on the first encryption public key and the second encryption public key.

[0010] The communication module is used to transmit the re-encrypted feature data to the first terminal device via a secure transmission path.

[0011] This application also discloses an encrypted access control system, including: First terminal equipment, second terminal equipment, and control terminal; The first terminal device is used to initiate a data access request; the data access request includes a first encryption public key and data request information; The second terminal device is used to provide feature data and generate a master key; The control terminal is configured to, upon determining that the first terminal device has been authorized to access data, encrypt the feature data using the master key to obtain the encrypted feature data, re-encrypt the encrypted feature data based on the re-encryption key to obtain the re-encrypted feature data, and transmit the re-encrypted feature data to the first terminal device via a secure transmission path, wherein the re-encryption key is generated based on the first encryption public key and the second encryption private key.

[0012] This application also discloses an electronic device, including: Memory, used to store programs; A processor, when executing the program, implements the encrypted access control method as described in any of the foregoing embodiments.

[0013] This application also discloses a computer-readable storage medium, which, when the instructions in the computer storage medium are executed by the processor of an electronic device, enables the electronic device to execute one or more of the encrypted access control methods described in this application.

[0014] In the embodiments of this application, the feature data of the second terminal device of the feature data owner can be stored in an encrypted data container. The feature data is obtained by removing the identity information of the feature data owner from the configuration parameter data exported by the second terminal device used by the feature data owner. The feature data can be encrypted using a master key generated by the second terminal device to obtain encrypted feature data, and uploaded to the encrypted data container through a secure transmission path. In response to the data access request of the first terminal device, based on the feature data owner's confirmed access permission operation, the extracted encrypted feature data is re-encrypted to obtain re-encrypted feature data, and the re-encrypted feature data is fed back to the first terminal device, ensuring that the encrypted feature data is unusable ciphertext during storage and use. This can break down the data silos between different service providers. Through secure network communication and authorized access mechanisms, the ownership sovereignty of the feature data producer over the feature data stored in the encrypted data container can be guaranteed, enabling secure and convenient migration of feature data between devices across platforms. Therefore, seamless migration of feature data can be achieved between devices on cross-server platforms, thereby ensuring the feature data owner's complete control over their feature data and improving the confidentiality, integrity, and availability of encrypted feature data during storage, transmission, and use. Attached Figure Description

[0015] Figure 1 This is a flowchart of an encrypted access control method provided in an embodiment of this application; Figure 2 This is a flowchart of another encrypted access control method provided in the embodiments of this application; Figure 3 This is a flowchart of another encrypted access control method provided in the embodiments of this application; Figure 4 This is a block diagram of an encrypted access control device provided in an embodiment of this application; Figure 5 This is a block diagram of an encrypted access control system provided in an embodiment of this application; Figure 6 This is a structural block diagram of an electronic device provided in an embodiment of this application. Detailed Implementation

[0016] The present invention will now be described in further detail with reference to specific embodiments and accompanying drawings. Similar elements in different embodiments are referred to by associated similar element reference numerals. In the following embodiments, numerous details are described to facilitate a better understanding of this application.

[0017] Furthermore, the features, operations, or characteristics described in the specification can be combined in any suitable manner to form various embodiments. At the same time, the steps or actions in the method description can be rearranged or adjusted in a manner obvious to those skilled in the art. Therefore, the various orders in the specification and drawings are only for the clear description of a particular embodiment and do not imply a necessary order, unless otherwise stated that a particular order must be followed.

[0018] The serial numbers assigned to components in this article, such as "first" and "second", are used only to distinguish the objects being described and have no sequential or technical meaning.

[0019] Before introducing the encrypted access control method, apparatus, device, system, and computer-readable storage medium provided in this application, the application scenarios involved in the various embodiments of this application are first described. This application can be applied to scenarios involving data migration of atomizing devices, and the terminal device provided in the embodiments of this application can be an atomizing device. This atomizing device can be used to heat or vibrate and break down an atomizing matrix (liquid substance) into aerosols (mist particles).

[0020] Currently, with the widespread use of terminal devices (such as atomizing devices, smartphones, and smart home devices), users generate a large amount of characteristic data related to their own identity during use. This characteristic data includes data related to the user's configuration preferences. In existing technical solutions, characteristic data is controlled and managed by the platform, meaning the characteristic data owner cannot truly control and manage their own data. Furthermore, traditional transmission and storage processes have security vulnerabilities, failing to guarantee the confidentiality, integrity, and availability of the data.

[0021] To address the aforementioned problems, this application provides an encrypted access control method, apparatus, device, system, and computer-readable storage medium.

[0022] The methods provided in this application will be described in detail below with reference to the accompanying drawings, through specific embodiments and application scenarios.

[0023] Figure 1 A flowchart of an encrypted access control method according to an embodiment of this application is shown.

[0024] Reference Figure 1 The encrypted access control method can be applied to the controller of a terminal device. This method may include the following steps: Step 101: Receive a data access request initiated by the first terminal device; the data access request includes a first encryption public key and data request information.

[0025] It should be noted that the terminal device can be a fogging device, smart home device, or wearable device, etc. The first terminal device is the terminal device of the requester initiating the data access request. Users, through operation or use of the terminal device, configure it according to their own preferences or usage habits, generating a large amount of feature data related to their own configuration preferences and usage scenarios. When the feature data owner changes to a new terminal device, the feature data of the terminal device previously used by the feature data owner needs to be synchronized. In this case, the new terminal device used by the feature data owner is the first terminal device, and the terminal device previously used by the feature data owner is the second terminal device. Alternatively, when someone else requests to use the feature data owner's feature data, the feature data owner needs to share the feature data of the terminal device currently used by the feature data requester. In this case, the terminal device used by the feature data requester is the first terminal device, and the terminal device currently used by the feature data owner is the second terminal device. When the feature data owner changes to a new terminal device, or when someone else requests to use the feature data owner's feature data, a feature data access request can be sent to the shared data platform.

[0026] In embodiments of this application, a data access request initiated by a first terminal device is received. The data access request includes a first encrypted public key and data request information. When a feature data owner prepares to use a new terminal device (i.e., the first terminal device), they typically maintain feature data related to their configuration preferences or usage habits. Therefore, it is necessary to synchronize feature data related to the feature data owner on the first terminal device. Alternatively, when someone else requests to use the feature data owner's feature data, they can send a data access request to a shared data platform, such as the cloud or a server. The data access request includes the first encrypted public key and data request information. When a feature data owner prepares to use a new terminal device, or when someone else requests to use the feature data owner's feature data, the feature data owner or the requester first needs to generate a first encrypted key pair based on the core parameters of the first terminal device, using an algorithm such as AES (Advanced Encryption Standard). The first encrypted key pair includes a first encrypted public key and a first encrypted private key. Secondly, the feature data owner or the requester needs to perform an operation on the first terminal device, such as selecting the "synchronize configuration parameters" option, and then generate data request information corresponding to the configuration parameter data. Then, a data access request corresponding to the configuration parameter data related to the feature data owner can be generated based on the first encrypted public key and the data request information, and the data access request corresponding to the feature data owner can be sent to the shared data platform through secure network communication.

[0027] Step 102: If the data access request of the first terminal device is authorized, extract the encrypted feature data corresponding to the data request information from the encrypted data container.

[0028] The encrypted feature data is obtained by encrypting the feature data based on the master key generated by the second terminal device.

[0029] It should be noted that an encrypted data container is a database or shared data platform used to store feature data belonging to the feature data owner. Feature data refers to settings parameters related to the feature data owner's configuration preferences and habits. Encrypted feature data is ciphertext data (C_A) obtained by encrypting the feature data using a master key generated by a second terminal device. An encrypted data container can store multiple encrypted feature data in a unified format within an encrypted data block. For example, file system-level encryption encrypts stored files; a key-based shared data management platform enables automated management of the entire lifecycle of encrypted data. The master key pair is generated based on the parameters of the feature data owner's second terminal device.

[0030] In the embodiments of this application, after receiving a data access request initiated by a first terminal device, the shared data platform needs to parse the data request information from the data access request, filter out the feature data owner corresponding to the data request information, and send a data access confirmation request to the feature data owner indicating whether to allow the feature data requester to use the feature data. The data access confirmation request can be prompted in a pop-up window on the feature data owner's second terminal device, and the feature data owner can confirm by operation. In response to receiving the confirmation operation of the feature data owner on the second terminal device, the encrypted feature data corresponding to the data request information is extracted from the encrypted data container. The encrypted data container structure includes: metadata information and encrypted data blocks. The metadata includes a version number, a user unique identifier, or a data block index table signature, such as plaintext or a signature. The encrypted data block includes multiple data blocks, each data block including a descriptor and a data body stored in encrypted form. The descriptor is, for example, {"data type": "device preference", "device type": "vaporizer", "manufacturer brand": "A", "timestamp": "etc"}; the data body is, for example, {"usual power": 12, "preferred flavor": "cool tobacco", "daily puffs": 150}. Therefore, the encrypted feature data is the ciphertext data obtained by encrypting the feature data corresponding to the data request information in the encrypted data block using the master key generated by the second terminal device, such as C_A.

[0031] Step 103: Re-encrypt the encrypted feature data based on the re-encryption key to obtain re-encrypted feature data; the re-encryption key is generated based on the first encryption public key and the second encryption private key.

[0032] It's important to note that re-encryption can be proxy re-encryption. Proxy re-encryption (PRE) is a public-key cryptosystem whose core function is to convert plaintext into ciphertext without revealing the plaintext, enabling different keys to decrypt the same ciphertext without exposing the original key. It can be applied to secure cloud storage and sharing, distributed systems and blockchain, IoT data gateways, etc. The proxy can be a service provider on a shared data platform. The re-encryption key is calculated using a specific algorithm based on the first public encryption key in the data access request and the second private encryption key generated by the second terminal device.

[0033] In the embodiments of this application, after obtaining the encrypted feature data that needs to be accessed, a re-encryption key can be calculated using a specific algorithm based on the first encrypted public key extracted from the data access request and the second encrypted private key of the feature data owner. When the feature data owner needs to authorize the first terminal device (with the first encrypted public key PK_B and the first encrypted private key SK_B) to access the feature data, the feature data owner can use their second encrypted private key SK_A and the first encrypted public key PK_B to calculate a re-encryption key RK_(A→B) using a specific algorithm. RK_(A→B) does not contain any direct information about SK_A and PK_B; it is merely a tool for converting ciphertext. The shared data platform uses RK_(A→B) to execute the re-encryption function ReEncrypt(C_A, RK_(A→B)) on the obtained encrypted feature data C_A, outputting the converted encrypted ciphertext C_B.

[0034] Therefore, it is evident that during the entire re-encryption process, the shared data platform does not perform any decryption operations or obtain the original plaintext of the feature data, ensuring data security throughout the process. Furthermore, it does not obtain the encryption private key of the feature data requester or owner; it only performs blind conversion on the encrypted ciphertext, thus ensuring the reliability of key management. Specifically, if the feature data owner changes to a new terminal device, the new terminal device is designated as the first terminal device, and the previously used terminal device is designated as the second terminal device; the feature data requester and the feature data owner are the same person. Alternatively, if someone else requests to use the feature data of the feature data owner, the terminal device used by the requester is designated as the first terminal device, and the terminal device currently used by the feature data owner is designated as the second terminal device; the feature data requester and the feature data owner are different people.

[0035] Step 104: Transmit the re-encrypted feature data to the first terminal device via a secure transmission path.

[0036] It's important to note that a secure transmission path refers to the secure network path that carries data from the sender to the receiver. This can be a secure communication module or network communication based on transport layer security protocols. In the OSI (Open System Interconnection) seven-layer model, transport layer security protocols include SSL (Secure Sockets Layer) and TLS (Transport Layer Security). TLS is a standardized upgrade of SSL, operating between the transport layer and the application layer. It can be invoked by application layer protocols (such as HTTPS), but its encrypted channel is actually established at the transport layer.

[0037] In the embodiments of this application, the re-encrypted feature data is transmitted to the first terminal device via a secure transmission path. The re-encrypted feature data (e.g., encrypted ciphertext C_B) can be sent to the first terminal device to complete the response to the current data access request. The shared data platform can record the access data or authorization. The re-encrypted feature data can be decrypted using the first encryption private key SK_B generated by the first terminal device to obtain the plaintext feature data corresponding to the current data access request. The terminal device equipped with SK_B (e.g., the first terminal device) can perform final decryption to obtain the plaintext feature data, and then configure the parameters of the first terminal device based on the plaintext feature data. Typically, the first terminal device and the second terminal device are of the same type. The plaintext feature data is based on a configuration parameter file exported by the feature data owner when using the second terminal device. In this case, the first terminal device can parse the configuration parameter file to obtain specific configuration parameter data, such as nicotine intake estimates, flavor categories, and vaporization concentrations, and map them to specific hardware modules (e.g., sensors) or software settings. Then the first terminal device system applies the parameters to the first terminal device. Finally, the first terminal device can confirm the configuration is effective through a feedback mechanism (e.g., local pop-up prompts or cloud log records) to migrate the feature data related to the feature data owner in the second terminal device to the first terminal device, and apply the configuration parameter data in the feature data to the first terminal device.

[0038] Figure 2 A flowchart of another encrypted access control method according to this application is shown. The method includes: Step 201: Obtain configuration parameter data related to the configuration preferences of the feature data owner in the second terminal device, and remove the identity information of the feature data owner from the configuration parameter data to obtain the feature data.

[0039] It should be noted that the second terminal device used by the feature data owner can be a smartphone, a vaporizer, a wearable device, or a smart home device, etc. During the use of this second terminal device, the feature data owner will adjust the parameters according to their own configuration preferences or usage habits to achieve diverse customized services or functions, thus meeting the usage needs of different consumers for the same type of terminal device.

[0040] In the embodiments of this application, configuration parameter data related to the configuration preferences of the feature data owner can be managed through a dedicated APP (e.g., Bluetooth or Wi-Fi connection) supported by the second terminal device. For example, the "Import / Export" function can be found in the "Device Management" or similar menu of the APP, allowing the export of configuration parameter data set by the feature data owner during the use of the second terminal device. The second terminal device stores the feature data owner's configuration parameter data through a cloud platform, and the feature data owner can download the configuration parameter file to the second terminal device by logging into the corresponding cloud platform account and finding "Parameter Backup" in the settings.

[0041] Step 202: Encrypt the feature data using the master key generated by the second terminal device to obtain encrypted feature data; Step 203: Encrypt the master key generated by the second terminal device using the second encryption public key to obtain the key ciphertext; the second encryption public key is the encryption public key in the second encryption key pair generated on the second terminal device.

[0042] Regarding steps 202 and 203, it should be noted that the most commonly used encryption algorithms for SSL certificates fall into two main categories: asymmetric encryption and symmetric encryption. Asymmetric encryption algorithms include key pairs formed using the RSA algorithm. The master key is a symmetric key, an underlying key generated based on the secure environment of the terminal device and completely transparent to the owner of the characteristic data. Subkeys such as file encryption keys can be derived from this underlying key. The second encryption key pair is an asymmetric key, including a public encryption key and a private encryption key.

[0043] In the embodiments of this application, a master key for the feature data owner can be generated based on the security environment of the second terminal device when the feature data owner first uses the second terminal device. The master key can be generated using a CSPRNG within the TEE / SE security chip of the second terminal device used by the feature data owner, for example, AES-256, and stored directly in the HSM of the security chip, preventing leakage risks by keeping the master key within the chip. Simultaneously, a second encryption key pair (PK_A, SK_A) can be generated using an asymmetric encryption algorithm such as RSA, including a second public encryption key and a second private encryption key. Then, the feature data owner can export or synchronize configuration parameter data, encrypting the exported feature data using the master key generated by the second terminal device to obtain encrypted feature data; and the master key MK needs to be encapsulated, which can be done using the second public encryption key PK_A to obtain the encapsulated key ciphertext Enc(MK, PK_A). The feature data owner's second terminal device can also encrypt the public encryption key (RSA public key) using a symmetric key (e.g., AES-256) to obtain the key ciphertext. Encrypted feature data and key ciphertext can be packaged or combined into a data packet for uploading and retrieval.

[0044] The encrypted feature data and key ciphertext can be transmitted to the encrypted data container for storage via a secure transmission protocol.

[0045] It should be noted that secure transmission protocols are used to ensure data security during transmission through encryption and authentication. Commonly used secure transmission protocols include SFTP (Secure File Transfer Protocol), SCP (Secure Copy Protocol), and HTTPS (Hypertext Transfer Protocol Secure). An encrypted data container is a database or cloud service platform used to manage and store encrypted characteristic data; this encrypted characteristic data includes encrypted data blocks and container metadata.

[0046] In the embodiments of this application, encrypted feature data and key ciphertext can be transmitted to an encrypted data container via the HTTPS protocol. Alternatively, data packets including encrypted feature data and key ciphertext can be uploaded to the encrypted data container, such as in the cloud or on a data server, via SFTP. The encrypted data container structure includes metadata information, encrypted data blocks, and encrypted key blocks. Encrypted feature data and key ciphertext, as well as related relationship information such as timestamps or version numbers, can be parsed from the data packets. Based on the encrypted data container's data storage structure, encrypted feature data can be stored in encrypted data blocks, and key ciphertext can be stored in encrypted key blocks. Relevant relationship information is saved in the original data's data block index table. Therefore, the transmitted data can be encrypted, security verified, and authenticated, thereby ensuring the secure transmission of encrypted feature data.

[0047] Step 204: Receive a data access request initiated by the first terminal device; the data access request includes a first encryption public key and data request information.

[0048] This step can be referred to as step 101 above, and will not be repeated here.

[0049] Step 205: If the permission status information indicates that authorization has been confirmed, in response to the data access request initiated by the first terminal device, the encrypted feature data corresponding to the data request information is extracted from the encrypted data block in the encrypted data container.

[0050] The encrypted feature data is obtained by encrypting the feature data based on the master key generated by the second terminal device, and the permission status information represents the authorization status of the data access request.

[0051] Step 206: Obtain the re-encryption key from the permission status information; the re-encryption key is generated based on the first encryption public key and the second encryption private key.

[0052] Step 207: Re-encrypt the encrypted feature data based on the re-encryption key to obtain re-encrypted feature data.

[0053] Regarding steps 206 to 207, it should be noted that the permission status information represents the authorization status of the data access request. This permission status information represents the authorization status of the second terminal device for the data access request initiated by the first terminal device. In other words, the feature data owner makes a decision on whether to authorize the data access request on the second terminal device. The permission status information includes allowing access to the feature data and prohibiting access to the feature data; allowing access to the feature data includes a re-encryption key. The re-encryption key can be a proxy re-encryption key generated based on proxy re-encryption technology. The proxy re-encryption key securely converts ciphertext from the encryption domain of feature data owner A to the encryption domain of feature data owner B without touching the plaintext, using a semi-trusted proxy server. A first encryption private key and a first encryption public key can be generated on the first terminal device using an asymmetric encryption algorithm; a second encryption private key and a second encryption public key can be generated on the second terminal device used by the feature data owner using an asymmetric encryption algorithm; and a one-way conversion key is generated on the second terminal device of the feature data owner using the first encryption public key and the second encryption private key through a combination operation to obtain the re-encryption key. The master key generated by the second terminal device is a symmetric encryption key, which can be used to encrypt and decrypt feature data.

[0054] In embodiments of this application, the system can receive permission status information for the data access request sent by the feature data owner from a second terminal device. When the permission status information indicates authorization, the first terminal device is allowed to access the requested data. At this time, the permission status information indicates that access to the feature data is permitted. A re-encryption key can be extracted from the information indicating that access to the data is permitted. The re-encryption key is generated on the second terminal device of the feature data owner performing the authorization operation, based on a second encryption private key generated by the second terminal device and a first encryption public key of the first terminal device, through an algorithm transformation. It is permissible to extract encrypted feature data corresponding to the data request information from the encrypted data container, and to re-encrypt the extracted encrypted feature data using the re-encryption key to obtain re-encrypted feature data. The second encryption key pair is generated on the second terminal device of the feature data owner performing the authorization operation in a secure environment using an asymmetric encryption algorithm. The second encryption key pair includes a second encryption private key and a second encryption public key.

[0055] For example, an encrypted data container, such as a shared data platform, can receive, via a secure transmission protocol, such as SFTP, a response information, such as permission status information, from a second terminal device (e.g., terminal device B previously used by the feature data owner) to a data access request initiated by a first terminal device (e.g., a new terminal device A that the feature data owner will replace). This response information can be parsed to distinguish whether access to the feature data is permitted or prohibited based on the identifier bits. If permitted access is obtained, a re-encryption key can be extracted from the permitted access feature data, and encrypted feature data can be extracted from the encrypted data block in the encrypted data container. The re-encryption key is then used to re-encrypt the encrypted feature data to obtain re-encrypted feature data. The re-encryption key is obtained by running a proxy re-encryption algorithm (e.g., the ReKeyGen algorithm) on a second private key generated by the second terminal device and a first public key generated by the first terminal device. The re-encrypted feature data is obtained by converting the encrypted feature data ciphertext into another encrypted ciphertext form.

[0056] Therefore, during the authorization and encryption process for data access requests, both encrypted and re-encrypted feature data can be stored and transmitted in ciphertext form. Thus, for encrypted data containers such as shared data platforms, the feature data is an invisible encrypted bitstream, ensuring the security of the feature data owner's data. Furthermore, encrypted feature data can only be extracted from the encrypted data container with the feature data owner's authorization, guaranteeing the owner's sovereignty over their data.

[0057] Optionally, step 207 may also include: Sub-step 2071: Based on the re-encryption key, the encrypted feature data is encrypted and transformed to obtain re-encrypted feature data, and the encrypted feature data after encryption transformation is used as the re-encrypted feature data.

[0058] The encryption transformation involves performing a mathematical transformation on the encrypted feature data based on a re-encryption key.

[0059] It should be noted that the re-encryption key is calculated from the second encryption private key generated by the second terminal device and the first encryption public key generated by the first terminal device; and is transmitted to the agent (e.g., a shared data platform) through a secure channel. The encrypted feature data is the ciphertext obtained by encrypting the feature data based on the master key generated by the second terminal device.

[0060] In the embodiments of this application, the encrypted feature data is obtained by encrypting the feature data based on the master key MK generated by the second terminal device, for example, CipherText_A. The re-encryption key is RK_A→B, generated using the second encryption private key (SK_A) generated by the second terminal device and the first encryption public key (PK_B) generated by the first terminal device. The encrypted feature data (e.g., CipherText_A) is encrypted and transformed based on the re-encryption key (e.g., RK_A→B) to obtain the re-encrypted feature data (e.g., ReEncrypted_CipherText_B). The encryption transformation is a mathematical transformation of the encrypted feature data based on the re-encryption key; it does not perform a second encryption on the encrypted feature data.

[0061] Therefore, during the proxy re-encryption process, the feature data generated by the feature data owner while using the second terminal device is only encrypted once. When the feature data requester receives the re-encrypted feature data, such as ReEncrypted_CipherText_B, on the first terminal device, they can directly generate their own encryption private key (e.g., SK_B) on the first terminal device to decrypt and obtain the feature data. Since the proxy re-encryption operation is performed on a shared data platform, the terminal device does not need to frequently decrypt and re-encrypt data, and the feature data owner or feature data requester does not need to directly share their encryption private key, thus avoiding the risk of data leakage.

[0062] Step 208: Transmit the re-encrypted feature data to the first terminal device via a secure transmission path.

[0063] This step can be referred to as step 104 above, and will not be repeated here.

[0064] After receiving the data access request initiated by the first terminal device, the method further includes: Step 209: Identify the characteristic data owner corresponding to the data request information in the data access request.

[0065] Step 210: Send the data access request to the second terminal device of the owner of the feature data.

[0066] Regarding steps 209 and 210, it should be noted that the data access request includes a first encrypted public key and data request information. The data request information is the feature data that the feature data requester needs to load when configuring the first terminal device. The feature data includes configuration preferences or data related to parameter configuration.

[0067] In the embodiments of this application, after receiving a data access request initiated by a first terminal device, the shared data platform needs to parse the data request information from the data access request, filter out the feature data owner corresponding to the data request information, and send a data access confirmation request to the second terminal device of the feature data owner. The data access confirmation request includes a first encrypted public key sent by the first terminal device and a permission operation request. The permission operation request is a confirmation operation requesting whether the feature data owner allows the feature data requester to access the feature data. In response to the permission operation request, the second terminal device of the feature data owner reminds the user to perform a permission operation through pop-ups, vibration, or voice prompts. The permission operation includes authorization and denial operations.

[0068] The method further includes: Step 211: Generate an authorization event based on the data access request of the first terminal device that has been authorized; Step 212: Generate an access event based on the encrypted feature data extracted from the encrypted data container; Step 213: Generate event hash values ​​corresponding to the authorization event and the access event respectively, and store the event hash values ​​in the blockchain evidence storage system.

[0069] Regarding steps 211-213, it should be noted that blockchain-based evidence storage is a method of fixing and preserving electronic data using blockchain technology. In this embodiment, corresponding event hash values ​​can be generated for access and authorization events and stored in the blockchain-based evidence storage system.

[0070] In the embodiments of this application, the data sharing platform can generate access events and authorization events based on the received data access request and information allowing access to characteristic data. Then, the parameters of the access event or authorization event (e.g., time, operator, permissions, etc.) are hashed using a hash algorithm (e.g., SHA-256) to generate a unique hash value, which can serve as a unique digital identifier. This unique hash value can be packaged with event stamps, identity identifiers, and other information. By broadcasting this packaged information to all nodes in the secure network, the data's legality is verified using a consensus algorithm (e.g., PBFT, PoA), ensuring data consistency across the entire blockchain network and implementing a notarization mechanism. Event hash values ​​corresponding to authorization events and access events can be generated respectively, and these event hash values ​​can be stored in the blockchain notarization system. Therefore, the process of accessing or authorizing encrypted characteristic data of encrypted data containers can be recorded, leveraging the tamper-proof, traceable, decentralized, and efficient notarization features of blockchain.

[0071] The method further includes: Step 214: Decrypt the re-encrypted feature data using the first encryption private key to obtain the plaintext feature data; Step 215: Configure parameters for the first terminal device based on the plaintext of the feature data to complete the data migration.

[0072] It should be noted that decryption is the process of restoring encrypted data to readable information. Symmetric decryption uses the same key as encryption. Asymmetric decryption uses the private key in the key pair to decrypt data encrypted with the public key to obtain the plaintext data. After receiving re-encrypted feature data from the encrypted data container, the first terminal device's first encryption private key can be used to decrypt the re-encrypted feature data to obtain the plaintext feature data. Parameter configuration is performed on the first terminal device based on the relevant parameter content of the plaintext feature data to complete the data migration.

[0073] In the embodiments of this application, re-encrypted feature data is received from a shared data platform. This re-encrypted feature data is in ciphertext form and cannot be directly used by the first terminal device. The re-encrypted feature data can be decrypted using a first encryption private key to obtain the plaintext feature data. The first terminal device, such as an atomizing device, can configure corresponding parameters by importing the plaintext feature data. Users can click "Import Preference Data" on the atomizing device's application, select the plaintext feature data file, and automatically configure the atomizing device's parameters (e.g., power 12W, recommended cooling flavor). After parameter configuration, the plaintext data can be automatically deleted from the first terminal device according to a set policy, avoiding the tedious process of manual parameter configuration, ensuring data security, and improving the experience for the feature data owner.

[0074] Figure 3 This is a flowchart of another encrypted access control method provided in this application embodiment. This embodiment illustrates a scenario where the feature data owner changes to a new terminal device and needs to synchronize feature data from the terminal device previously used by the feature data owner (i.e., the feature data requester and the feature data owner are the same person). In this embodiment, the new terminal device used by the feature data owner is the first terminal device (i.e., feature data owner device B), and the terminal device previously used by the feature data owner is the second terminal device (i.e., feature data owner device A).

[0075] like Figure 3As shown, the encrypted access control method is applied to a shared data platform, such as a proxy re-encryption engine. Configuration parameter data related to the feature data owner device A is migrated from the shared data platform to the feature data owner device B. The shared data platform includes encrypted data blocks for storing encrypted feature data. The feature data is configuration parameter data related to the feature data owner's configuration preferences, exported from feature data owner device A. After the feature data owner's identity information is removed from the configuration parameter data by a de-identification module, feature data about the feature data owner's configuration preferences is obtained, such as "number of puffs: 150, preferred flavor: mint, power: 12". The feature data can be encrypted using a symmetric key MK to obtain encrypted feature data.

[0076] In this embodiment, when it is necessary to migrate device configuration parameter data related to the configuration preferences of the feature data owner, an asymmetric key pair (PK_B, SK_B) can be generated on the feature data owner device B. The feature data owner device B sends a data access request to the shared data platform. The data access request includes data request information and the encryption public key PK_B. The shared data platform can send a pop-up message to the terminal device previously used by the feature data owner (feature data owner device A): "Do you allow device B to read your taste preferences?". The feature data owner performs permission operations on the feature data owner device A. When the permission status information is that data access is allowed, the feature data owner sends a re-encryption key to the shared data platform. The re-encryption key is a proxy re-encryption key, which is calculated using a specific algorithm based on the asymmetric public key PK_B of the feature data owner device B and the asymmetric private key SK_A of the feature data owner device A. Simultaneously, encrypted feature data corresponding to the data request information is extracted from the encrypted data blocks in the encrypted data container. The feature data owner generates an asymmetric key pair (PK_A, SK_A) and a symmetric key MK through device A. The encrypted feature data is obtained by encrypting configuration parameter data related to the feature data owner's configuration preferences using the symmetric key MK. The symmetric key MK is then encrypted using the asymmetric key PK_A to obtain the key ciphertext. The encrypted feature data can be re-encrypted using the re-encryption key RK to obtain re-encrypted feature data. The re-encrypted feature data is sent to the feature data owner device B through a secure communication network. The feature data owner device B can first parse the master key MK using its own asymmetric key SK_B, and then decrypt the encrypted feature data using the master key MK. The plaintext feature data is obtained by reversing the encryption process of MK. In the above encryption and decryption process, the master key MK generated by the feature data owner device A is a symmetric key, which is the working key for encrypting the feature data, while PK_A, SK_A, PK_B, and SK_B are asymmetric key pairs used to manage and control the encryption and decryption process of MK, thereby realizing the control keys for advanced functions such as data security authorization and re-encryption.

[0077] It should be noted that, for the sake of simplicity, the method embodiments are all described as a series of actions. However, those skilled in the art should understand that the embodiments of this application are not limited to the described order of actions, because according to the embodiments of this application, some steps can be performed in other orders or simultaneously. Secondly, those skilled in the art should also understand that the embodiments described in the specification are all preferred embodiments, and the actions involved are not necessarily required by the embodiments of this application.

[0078] Figure 4 A structural block diagram of an encrypted access control device according to an embodiment of this application is shown.

[0079] The encrypted access control device 400 may specifically include: The acquisition module 401 is used to receive a data access request initiated by the first terminal device; the data access request includes a first encryption public key and data request information.

[0080] Extraction module 402 is used to extract encrypted feature data corresponding to the data request information from the encrypted data container when it is determined that the terminal device has been authorized to access the data; the encrypted feature data is obtained by encrypting the feature data using a master key generated by the second terminal device.

[0081] The re-encryption module 403 is used to re-encrypt the encrypted feature data based on the re-encryption key to obtain re-encrypted feature data; the re-encryption key is generated based on the first encryption public key and the second encryption public key.

[0082] The communication module 404 is used to transmit the re-encrypted feature data to the first terminal device through a secure transmission path.

[0083] Optionally, the extraction module 402 further includes: The confirmation submodule is used to extract encrypted feature data corresponding to the data request information from the encrypted data block in the encrypted data container in response to the data access request initiated by the first terminal device when the permission status information indicates that authorization is confirmed. The permission status information represents the authorization status of the second terminal device for the data access request, and the encrypted feature data is obtained by encrypting the feature data based on the master key generated by the second terminal device.

[0084] Optionally, the device further includes: The second extraction submodule is used to extract the re-encryption key from the permission status information; The re-encryption key is generated based on the first encryption public key and the second encryption private key, wherein the second encryption private key is the encryption private key in the second encryption key pair generated by the second terminal device.

[0085] Optionally, the communication module 404 further includes: A submodule is established to establish a communication connection between the encrypted data container and the first terminal device based on a secure transmission protocol.

[0086] The first sending submodule is used to send the re-encrypted feature data to the first terminal device through the communication connection.

[0087] Optionally, the re-encryption module 403 further includes: An encryption submodule is used to perform encryption transformation on the encrypted feature data based on the re-encryption key to obtain encrypted feature data after encryption transformation; and to use the encrypted feature data after encryption transformation as the re-encrypted feature data; wherein, the encryption transformation is to perform mathematical transformation on the encrypted feature data based on the re-encryption key.

[0088] The device further includes: The identification submodule is used to identify the characteristic data owner corresponding to the data request information in the data access request.

[0089] The second sending submodule is used to send a data access confirmation request to the second terminal device of the owner of the feature data.

[0090] Optionally, the device further includes: The removal submodule is used to obtain configuration parameter data related to the configuration preferences of the feature data owner in the second terminal device, and remove the identity information of the feature data owner from the configuration parameter data to obtain the feature data.

[0091] The first encryption submodule is used to encrypt the feature data using a master key generated by the second terminal device to obtain the encrypted feature data.

[0092] The second encryption submodule is used to encrypt the master key generated by the second terminal device using the second encryption public key to obtain the key ciphertext; the second encryption public key is the encryption public key in the second encryption key pair generated on the second terminal device.

[0093] Optionally, the device further includes: The first generation submodule is used to generate an authorization event based on the data access request of the first terminal device that is determined to be authorized.

[0094] The second generation submodule is used to generate an access event based on the encrypted feature data extracted from the encrypted data container.

[0095] The generation and storage submodule is used to generate event hash values ​​corresponding to the authorization event and the access event respectively, and store the event hash values ​​in the blockchain evidence storage system.

[0096] Optionally, the device further includes: The decryption submodule is used to decrypt the re-encrypted feature data using the first encryption private key to obtain the plaintext feature data. The migration submodule is used to configure parameters of the first terminal device based on the plaintext of the feature data in order to complete the data migration.

[0097] In the embodiments of this application, the feature data of the second terminal device of the feature data owner can be stored in an encrypted data container. The feature data is obtained by removing the identity information of the feature data owner from the configuration parameter data exported by the second terminal device used by the feature data owner. The feature data can be encrypted using a master key generated by the second terminal device to obtain encrypted feature data, and uploaded to the encrypted data container through a secure transmission path. In response to the data access request of the first terminal device, based on the feature data owner's confirmed access permission operation, the extracted encrypted feature data is re-encrypted to obtain re-encrypted feature data, and the re-encrypted feature data is fed back to the first terminal device, ensuring that the encrypted feature data is unusable ciphertext during storage and use. This can break down the data silos between different service providers. Through secure network communication and authorized access mechanisms, the ownership sovereignty of the feature data producer over the feature data stored in the encrypted data container can be guaranteed, enabling secure and convenient migration of feature data between devices across platforms. Therefore, seamless migration of feature data can be achieved between devices on cross-server platforms, thereby ensuring the feature data owner's complete control over their feature data and improving the confidentiality, integrity, and availability of encrypted feature data during storage, transmission, and use.

[0098] As the device embodiment is basically similar to the method embodiment, the description is relatively simple, and relevant parts can be found in the description of the method embodiment.

[0099] Figure 5 An embodiment of the encrypted access control system of this application is shown, comprising: First terminal equipment, second terminal equipment, and control terminal; The first terminal device is used to initiate a data access request; the data access request includes a first encryption public key and data request information; The second terminal device is used to provide feature data and generate the master key; The control terminal is used to, upon determining an authorized data access request from a first terminal device, encrypt feature data using a master key to obtain encrypted feature data, re-encrypt the encrypted feature data based on a re-encryption key to obtain re-encrypted feature data, and transmit the re-encrypted feature data to the first terminal device via a secure transmission path, wherein the re-encryption key is generated based on a first encryption public key and a second encryption private key.

[0100] In the embodiments of this application, the description of the encrypted access control system can be referred to the relevant embodiments of the encrypted access control method described above, and will not be repeated here.

[0101] Figure 6 An electronic device for encrypted access control according to an embodiment of this application is shown. This application provides an electronic device, referring to... Figure 6 The electronic device includes a processor 501, a memory 502, and a computer program 5021 stored in the memory and executable on the processor. When executed, the processor implements the encrypted access control method of the foregoing embodiments.

[0102] In this embodiment, the processor and memory can be connected via a bus or other means. The memory may include volatile memory, such as random access memory; the memory may also include non-volatile memory, such as read-only memory, flash memory, hard disk, or solid-state drive. The processor may be a general-purpose processor, such as a central processing unit, digital signal processor, application-specific integrated circuit, or one or more integrated circuits configured to implement embodiments of the present invention.

[0103] This application also provides a computer-readable storage medium that, when computer instructions in the storage medium are executed by a processor on a server side, enables the server side to execute an encrypted access control method, the method comprising the encrypted access control method of the foregoing embodiments.

[0104] The various embodiments in this specification are described in a progressive manner, with each embodiment focusing on the differences from other embodiments. The same or similar parts between the various embodiments can be referred to each other.

[0105] Those skilled in the art will understand that embodiments of this application can be provided as methods, apparatus, or computer programs. Therefore, embodiments of this application can take the form of entirely hardware embodiments, entirely software embodiments, or embodiments combining software and hardware aspects. Furthermore, embodiments of this application can take the form of a computer program implemented on one or more computer-usable storage media (including but not limited to disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0106] This application describes embodiments with reference to flowchart illustrations and / or block diagrams of methods, terminal devices (systems), and computer programs according to embodiments of this application. It should be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing terminal device to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing terminal device, generate instructions for implementing the flowchart illustrations. Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.

[0107] These computer program instructions may also be stored in a computer-readable storage medium capable of directing a computer or other programmable data processing terminal device to operate in a predictive manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 One or more processes and / or boxes Figure 1 The function specified in one or more boxes.

[0108] These computer program instructions can also be loaded onto a computer or other programmable data processing terminal equipment, causing a series of operational steps to be performed on the computer or other programmable terminal equipment to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable terminal equipment for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps of the function specified in one or more boxes.

[0109] Although preferred embodiments of the present application have been described, those skilled in the art, upon learning the basic inventive concept, can make other changes and modifications to these embodiments. Therefore, the appended claims are intended to be interpreted as including the preferred embodiments as well as all changes and modifications falling within the scope of the embodiments of the present application.

[0110] Finally, it should be noted that in this document, relational terms such as "first" and "second" are used only to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or terminal device that includes a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or terminal device. Without further limitations, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or terminal device that includes said element.

[0111] The above provides a detailed description of an encrypted access control method and apparatus, an encrypted access control system, an electronic device, and a computer-readable storage medium provided in this application. Specific examples have been used to illustrate the principles and implementation methods of this application. The descriptions of the above embodiments are only for the purpose of helping to understand the method and core ideas of this application. At the same time, for those skilled in the art, there will be changes in the specific implementation methods and application scope based on the ideas of this application. Therefore, the content of this specification should not be construed as a limitation of this application.

Claims

1. An encrypted access control method, characterized in that, include: Receive a data access request initiated by a first terminal device; the data access request includes a first encryption public key and data request information; If a data access request for the first terminal device is authorized, encrypted feature data corresponding to the data request information is extracted from the encrypted data container. The encrypted feature data is re-encrypted based on the re-encryption key to obtain re-encrypted feature data; the re-encryption key is generated based on the first encryption public key and the second encryption private key. The re-encrypted feature data is transmitted to the first terminal device via a secure transmission path.

2. The method according to claim 1, characterized in that, When a data access request for the first terminal device is authorized, extracting encrypted feature data corresponding to the data request information from the encrypted data container includes: When the permission status information indicates that authorization has been granted, in response to the data access request initiated by the first terminal device, the encrypted feature data corresponding to the data request information is extracted from the encrypted data block in the encrypted data container. The permission status information represents the authorization status of the second terminal device for the data access request, and the encrypted feature data is obtained by encrypting the feature data based on the master key generated by the second terminal device.

3. The method according to claim 1, characterized in that, Before re-encrypting the encrypted feature data based on the re-encryption key to obtain the re-encrypted feature data, the method further includes: Extract the re-encryption key from the permission status information; The re-encryption key is generated based on the first encryption public key and the second encryption private key, wherein the second encryption private key is the encryption private key in the second encryption key pair generated by the second terminal device.

4. The method according to claim 1, characterized in that, The step of re-encrypting the encrypted feature data based on the re-encryption key to obtain re-encrypted feature data includes: The encrypted feature data is encrypted and transformed based on the re-encryption key to obtain the encrypted feature data after encryption transformation; the encrypted feature data after encryption transformation is used as the re-encrypted feature data; The encryption transformation involves performing a mathematical transformation on the encrypted feature data based on the re-encryption key.

5. The method according to claim 1, characterized in that, The step of transmitting the re-encrypted feature data to the first terminal device via a secure transmission path includes: A communication connection is established between the encrypted data container and the first terminal device based on a secure transmission protocol; The re-encrypted feature data is sent to the first terminal device via the communication connection.

6. The method according to claim 1, characterized in that, The method further includes: An authorization event is generated based on the data access request that is authorized to the first terminal device; An access event is generated based on the encrypted feature data extracted from the encrypted data container; Generate event hash values ​​corresponding to the authorization event and the access event respectively, and store the event hash values ​​in the blockchain evidence storage system.

7. The method according to claim 1, characterized in that, The method further includes: Obtain configuration parameter data related to the configuration preferences of the feature data owner from the second terminal device, and remove the identity information of the feature data owner from the configuration parameter data to obtain the feature data; The feature data is encrypted using a master key generated by the second terminal device to obtain the encrypted feature data; The master key generated by the second terminal device is encrypted using the second encryption public key to obtain the key ciphertext; the second encryption public key is the encryption public key in the second encryption key pair generated on the second terminal device.

8. The method according to claim 1, characterized in that, After receiving the data access request initiated by the first terminal device, the method further includes: Identify the characteristic data owner corresponding to the data request information in the data access request; Send a data access confirmation request to the second terminal device of the owner of the feature data.

9. The method according to claim 1, characterized in that, The method further includes: The re-encrypted feature data is decrypted using the first encryption private key to obtain the plaintext feature data; The first terminal device is configured with parameters based on the plaintext of the feature data to complete the data migration.

10. An encrypted access control device, characterized in that, include: The acquisition module is used to receive a data access request initiated by a first terminal device; the data access request includes a first encryption public key and data request information; The extraction module is used to extract encrypted feature data corresponding to the data request information from the encrypted data container when it is determined that the data access request of the first terminal device is authorized; the encrypted feature data is obtained by encrypting the feature data using a master key generated by the second terminal device. A re-encryption module is used to re-encrypt the encrypted feature data based on a re-encryption key to obtain re-encrypted feature data; the re-encryption key is generated based on the first encryption public key and the second encryption public key. The communication module is used to transmit the re-encrypted feature data to the first terminal device via a secure transmission path.

11. An encrypted access control system, characterized in that, include: First terminal equipment, second terminal equipment, and control terminal; The first terminal device is used to initiate a data access request; the data access request includes a first encryption public key and data request information; The second terminal device is used to provide feature data and generate a master key; The control terminal is used to, upon determining that the first terminal device has been authorized to access data, encrypt the feature data using the master key to obtain the encrypted feature data, and then re-encrypt the encrypted feature data based on the re-encryption key to obtain the re-encrypted feature data. The re-encrypted feature data is transmitted to the first terminal device via a secure transmission path, wherein the re-encryption key is generated based on the first encryption public key and the second encryption private key.

12. An electronic device, characterized in that, include: Memory, used to store programs; A processor, when executing the program, implements the data encryption access control method as described in any one of claims 1 to 9.

13. A computer-readable storage medium, characterized in that, When the instructions in the computer-readable storage medium are executed by a processor, the method described in any one of claims 1 to 9 can be implemented.

Images