Data protection method and electronic device

Abstract

Embodiments of the present application provide a data protection method and an electronic device, the method comprising: after inputting a first lock screen code of a first electronic device and enabling a synchronization function of a password safe service, a user triggers a second control in a current display interface, triggers the first electronic device to create a first trust circle corresponding to a first account, and after the first trust circle is created and joined, displays prompt information in the interface to prompt that the first trust circle has been created. The data protection method protects the account-level master key MK based on a user secret, such as a device lock screen code. Since the user secret is unknown to the cloud side, the cloud side cannot decrypt the hosted master key ciphertext, thereby reducing the risk of master key leakage, improving the security of the master key MK, and enabling the cloud side to prove its innocence.

Description

[0001] This application is a divisional application. The original application was entitled "Data Protection Method and Electronic Device" with application number 202111400200.2 and application date November 19, 2021. The entire contents of the original application are incorporated herein by reference. Technical Field

[0002] This application relates to the field of terminal devices, and more particularly to a data protection method and electronic device. Background Technology

[0003] Currently, terminal devices can store user data in the cloud for users to upload and download in real time. User data typically corresponds to a specific user account. However, the security of user data relies entirely on account security; as long as the device can pass account verification, it can obtain the data from the cloud. If either the account or the cloud server is attacked, user data will be leaked. Furthermore, the cloud server also has the potential to decrypt user data, making it impossible for the cloud to prove its innocence. Therefore, known solutions have low security and cannot support user data protection with higher security requirements. Summary of the Invention

[0004] This application provides a data protection method and electronic device. When the current service is a preset service on a whitelist, a first derived key stored in the trusted execution environment of the first electronic device is extracted and a master key is generated. The master key is then encrypted based on the first derived key to obtain a first master key ciphertext. First authentication parameters are generated based on the first derived key. The first authentication parameters and the first master key ciphertext are uploaded to the cloud, enabling a first server to create a trust ring for the first account logged into by the first electronic device and add the first device to the ring. This data protection method protects the account-level master key MK based on user secrets, such as the device lock screen code. Since the user secret is unknown to the cloud side, the cloud side cannot decrypt the hosted master key ciphertext. This reduces the risk of master key leakage, improves the security of the master key MK, and allows the cloud side to prove its innocence.

[0005] Firstly, this application provides a data protection method applied to a first electronic device, comprising: extracting a first derived key stored in the trusted execution environment of the first electronic device when the current service is a preset service in a whitelist, wherein the first derived key is generated based on the first lock screen code of the first electronic device, and the first electronic device has logged into a first account; generating a master key in the trusted execution environment of the first electronic device; encrypting the master key based on the first derived key to generate a first master key ciphertext of the first electronic device; generating a first authentication parameter based on the first derived key; and sending a ring creation request to a first server to enable the first server to create a first trust ring corresponding to the first account, and adding the first master key ciphertext and the first authentication parameter to the trust ring data of the first trust ring, wherein the ring creation request carries the first master key ciphertext and the first authentication parameter. This method of creating a trust ring protects the account-level master key MK based on user secrets such as the device lock screen code. Since the user secrets are unknown to the cloud side, the cloud side cannot decrypt the hosted master key ciphertext, thus reducing the risk of master key leakage, improving the security of the master key MK, and enabling the cloud side to prove its innocence. Furthermore, this method for creating a trust ring eliminates the need for users to manually enter the lock screen code of the second electronic device after requesting to add the ring, making the operation convenient.

[0006] In this application, the lock screen code can be replaced with other user information, such as the user's birthday, name, or the birthdays and names of their parents or friends. This information is unique to the user, known only to that user, and varies from user to user. This user information is easy for the user to remember and is unknown to the cloud side. When the master key is encrypted based on user information, the cloud side cannot decrypt it, thus proving its innocence. Apart from the user, it is difficult for others to know which user information the user used to encrypt the master key, greatly increasing the difficulty of cracking the master key ciphertext and improving the security of the master key. This, in turn, enhances the security of user data protected by derived keys of the master key. Furthermore, when the second and subsequent devices in the trust ring register, the identity of the registered device can be verified based on the user information without interaction with the registered device, providing convenience for the user.

[0007] According to the first aspect, the first electronic device encrypts the master key based on a first derived key to generate a first master key ciphertext for the first electronic device, including: the first electronic device generating a second derived key based on the first derived key; and encrypting the master key based on the second derived key to obtain the first master key ciphertext for the first electronic device. In this way, encrypting the master key based on user-personalized information such as a lock screen code prevents the cloud side, which does not know the user's personalized information, from decrypting the master key, thus protecting user data encrypted using the derived key of the master key and improving the security of user data.

[0008] According to the first aspect, or any implementation thereof, the first electronic device generates the first authentication parameter based on the first derived key by: generating a first shared value based on the first derived key; and encrypting the first shared value using the HSM public key generated by the first server to obtain the first authentication parameter. In this way, generating authentication parameters based on user-personalized information such as the lock screen code ensures that the authentication parameters cannot be forged, guaranteeing authentication security.

[0009] According to the first aspect, or any implementation of the first aspect above, the method further includes: in response to an operation that modifies the lock screen code of the first electronic device, generating a hash value based on the modified new lock screen code; generating a first derived key based on the hash value; and saving the first derived key to the trusted execution environment of the first electronic device. This pre-generating the first derived key based on the lock screen code allows it to be directly retrieved from the trusted execution environment when needed during the ring-locking process, eliminating the need to prompt the user to input the lock screen code again, thus reducing the number of times the user needs to input the lock screen code and improving the user experience.

[0010] According to the first aspect, or any implementation of the first aspect above, the method further includes: upon receiving a registration request, detecting the registration status of the first electronic device; if the first electronic device is not registered, sending a registration status comparison request to the first server, the registration status comparison request carrying the device identifier of the first electronic device and the account identifier of the first account; receiving a first registration status confirmation message returned by the first server, wherein the first registration status confirmation message is used to indicate that there is no trust loop under the first account. This method of first detecting the registration status on the device side, and then comparing the registration status on the cloud when it is determined that there is no local registration, can reduce the number of accesses to the cloud compared to directly requesting the cloud for registration status comparison.

[0011] According to the first aspect, or any implementation of the first aspect above, the ring creation request carries the device identifier of the first device and the account identifier of the first account; after the first electronic device is added to the first trust ring, the trust ring data of the first trust ring includes: the correspondence between the account identifier of the first account, the device identifier of the first device, the first authentication parameters, and the first master key ciphertext. The relevant trust ring data of the device is stored accordingly to facilitate subsequent management of the trust ring data.

[0012] According to the first aspect, or any implementation of the first aspect above, the method further includes: deriving a first business key based on the master key; encrypting the first business data using the first business key to obtain ciphertext of the first business data; and sending the ciphertext of the first business data to a second server so that the second server can store the ciphertext of the first business data. This method of encrypting ciphertext of business data based on a business key derived from the master key and then synchronously uploading it to the cloud ensures the security of the business data because the master key is unknown to the cloud, and therefore the ciphertext of the business data uploaded to the cloud is also unknown to the cloud. Furthermore, the cloud can prove its innocence.

[0013] According to the first aspect, or any implementation thereof, the method further includes: a first electronic device obtaining second business data ciphertext from a second server; deriving a first business key based on a master key; and decrypting the second business data ciphertext using the first business key to obtain the second business data. This method of obtaining business data ciphertext from the cloud and then decrypting it locally on the electronic device improves the security of business data, as even if the ciphertext transmitted between the cloud and the electronic device is intercepted, the interceptor cannot decrypt the obtained business data because they cannot know the master key or the rules for deriving the first business key from the master key.

[0014] Secondly, embodiments of this application provide a data protection method applied to a second electronic device. The method includes: when the current service of the second electronic device is a preset service in a whitelist, extracting a third derived key stored in the trusted execution environment of the second electronic device, the third derived key being generated based on a second screen lock code of the second electronic device, wherein the second electronic device is logged into a first account; receiving a first screen lock code input by a user, wherein the first electronic device is a device in the on-ring device information of a first trust ring corresponding to a first account obtained from a first server; when authentication of the first electronic device based on the first screen lock code is successful, receiving a first master key ciphertext of the first electronic device sent by the first server; decrypting the first master key ciphertext based on the first screen lock code to obtain a master key; encrypting the master key based on the third derived key to generate a second master key ciphertext of the second electronic device, and generating a second authentication parameter based on the third derived key; and sending a ring-adding request to the first server to add the second master key ciphertext and the second authentication parameter to the trust ring data of the first trust ring.

[0015] This method of joining a trust ring involves the cloud side sending the encrypted master key of the registered device to the ring-joining device. The ring-joining device decrypts the encrypted master key based on the registered device's user secret, obtaining the master key MK. Since the registered device's user secret is unknown to the cloud side and does not require forwarding through the cloud side, the cloud side cannot decrypt the encrypted master key, thus proving its innocence. Furthermore, this method eliminates the need for the user to manually enter the lock screen code of the second electronic device after requesting ring joining, making it convenient to operate.

[0016] According to the second aspect, after extracting the third derived key stored in the trusted execution environment of the second electronic device, the method further includes: sending a request to the first server to obtain in-loop device information, wherein the request carries the account identifier of the first account; receiving in-loop device information of the first trust ring corresponding to the first account returned by the first server, wherein the in-loop devices include the first electronic device; and displaying the lock screen code input interface of the first electronic device. In this way, the default device's lock screen code input interface is displayed, allowing the user to directly enter the lock screen code to verify the device, making the operation convenient.

[0017] According to the second aspect, or any implementation of the second aspect above, after the second electronic device extracts the third derived key stored in the trusted execution environment of the second electronic device, the method further includes: sending a request to obtain in-loop device information to the first server, wherein the request carries the account identifier of the first account; receiving in-loop device information of the first trust ring corresponding to the first account returned by the first server, wherein the in-loop devices include the first electronic device and the third electronic device; and displaying the lock screen code input interface of the third electronic device in response to the selection operation of the third electronic device in the in-loop device information. The first server returns all in-loop device information, and the user can flexibly select any in-loop device as the verification device, making the verification more flexible.

[0018] According to the second aspect, or any implementation thereof, before the authentication of the first electronic device based on the first lock screen code is successful and the first master key ciphertext of the first electronic device is received from the first server, the method further includes: generating a first authentication parameter based on the first lock screen code; and sending the first authentication parameter to the first server so that the first server can authenticate the first electronic device based on the first authentication parameter. In this way, generating authentication parameters based on user-personalized information such as the lock screen code ensures that the authentication parameters cannot be forged, guaranteeing authentication security.

[0019] According to the second aspect, or any implementation thereof, the second electronic device encrypts the master key based on the third derived key to generate a second master key ciphertext for the second electronic device, including: generating a fourth derived key based on the third derived key; and encrypting the master key based on the fourth derived key to obtain the second master key ciphertext for the second electronic device. In this way, encrypting the master key based on user-personalized information such as the lock screen code prevents the cloud side, which does not know the user's personalized information, from decrypting the master key, thus protecting user data encrypted using the derived key of the master key and improving the security of user data.

[0020] According to the second aspect, or any implementation thereof, generating the second authentication parameter based on the third derived key includes: generating a second shared value based on the third derived key; encrypting the second shared value using the HSM public key generated on the first server side to obtain the second authentication parameter. In this way, generating authentication parameters based on user-personalized information such as the lock screen code ensures that the authentication parameters cannot be forged, guaranteeing authentication security.

[0021] According to the second aspect, or any implementation thereof, the method further includes: upon receiving a registration request, detecting the registration status of the second electronic device; if the second electronic device is not registered, sending a registration status comparison request to the first server, the registration status comparison request carrying the device identifier of the second electronic device and the account identifier of the first account; receiving a second registration status confirmation message returned by the first server, wherein the second registration status confirmation message is used to indicate that a first trust ring exists under the first account, but the second electronic device is not on the first trust ring. This method of first detecting the registration status on the device side, and then comparing the registration status on the cloud when it is determined that the device is not registered locally, can reduce the number of accesses to the cloud compared to directly requesting the cloud for registration status comparison.

[0022] According to the second aspect, or any implementation thereof, the method further includes: a second electronic device derives a first service key based on a master key, encrypts first service data using the first service key to obtain ciphertext of the first service data; and sends the ciphertext of the first service data to a second server so that the second server can store the ciphertext of the first service data. This method of encrypting ciphertext of service data based on a service key derived from a master key and then synchronously uploading it to the cloud ensures the security of the service data because the master key is unknown to the cloud, and therefore the ciphertext of the service data uploaded to the cloud is also unknown to the cloud. Furthermore, the cloud can prove its innocence.

[0023] According to the second aspect, or any implementation thereof, the method further includes: obtaining second business data ciphertext from a second server; generating a first business key based on the master key; and decrypting the second business data ciphertext using the first business key to obtain the second business data. This method of obtaining business data ciphertext from the cloud and then decrypting it locally on the electronic device improves the security of business data. Even if the ciphertext transmitted between the cloud and the electronic device is intercepted, the interceptor cannot know the master key or the rules for deriving the first business key from the master key, thus preventing the decryption of the obtained business data.

[0024] Thirdly, embodiments of this application provide an electronic device, serving as a first electronic device, comprising: a trust ring module and a trust ring service module; the trust ring module is configured to: extract a first derived key stored in the trusted execution environment of the first electronic device when the current service is a preset service in the whitelist, the first derived key being generated based on a first lock screen code of the first electronic device, wherein the first electronic device has logged into a first account; generate a master key in the trusted execution environment of the first electronic device; then encrypt the master key based on the first derived key to generate a first master key ciphertext of the first electronic device; and send the first derived key to the trust ring service module; the trust ring service module is configured to: generate a first authentication parameter based on the first derived key; send a ring creation request to a first server to enable the first server to create a first trust ring corresponding to the first account, and add the first master key ciphertext and the first authentication parameter to the trust ring data of the first trust ring, wherein the ring creation request carries the first master key ciphertext and the first authentication parameter.

[0025] This method of creating a trust ring protects the account-level master key MK based on user secrets, such as the device lock screen code. Since the user secrets are unknown to the cloud side, the cloud side cannot decrypt the ciphertext of the hosted master key. This reduces the risk of master key leakage, improves the security of the master key MK, and enables the cloud side to prove its innocence.

[0026] Fourthly, this application provides an electronic device as a second electronic device, comprising: a trust ring module and a trust ring service module; the trust ring module is used to: extract a third derived key stored in the trusted execution environment of the second electronic device when the current service is a preset service in the whitelist, the third derived key being generated based on the second lock screen code of the second electronic device, wherein the second electronic device has been logged into a first account; the trust ring service module is used to: receive a first lock screen code of the first electronic device input by a user, wherein the first electronic device is a device in the loop device information of the first trust ring corresponding to the first account obtained from a first server; when the first lock screen code is used to access the second electronic device... Upon successful authentication of an electronic device, the device receives the first master key ciphertext sent by the first server; it then sends the first master key ciphertext and the first lock screen code to the trust ring module. The trust ring module is configured to: decrypt the first master key ciphertext based on the first lock screen code to obtain the master key; encrypt the master key based on the third derived key to generate the second master key ciphertext of the second electronic device; and send the third derived key to the trust ring service module. The trust ring service module is further configured to: generate second authentication parameters based on the third derived key; and send a ring-adding request to the first server to add the second master key ciphertext and the second authentication parameters from the first server to the trust ring data of the first trust ring.

[0027] This method of joining a trust ring involves the cloud side sending the encrypted master key of the registered device to the ring-joining device. The ring-joining device decrypts the encrypted master key based on the registered device's user secret, obtaining the master key MK. Since the registered device's user secret is unknown to the cloud side and does not require forwarding through the cloud side, the cloud side cannot decrypt the encrypted master key, thus proving its innocence. Furthermore, this method eliminates the need for the user to manually enter the lock screen code of the second electronic device after requesting ring joining, making it convenient to operate.

[0028] Fifthly, this application provides a computer-readable medium for storing a computer program, the computer program including instructions for performing the method in the first aspect or any possible implementation of the first aspect, or instructions for performing the method in the second aspect or any possible implementation of the second aspect.

[0029] Sixthly, this application provides a computer program including instructions for performing the method in the first aspect or any possible implementation thereof, and instructions for performing the method in the second aspect or any possible implementation thereof. Attached Figure Description

[0030] Figure 1 This is a schematic diagram of the structure of an electronic device 100 as an example.

[0031] Figure 2 This is a software structure block diagram of an electronic device 100 according to an embodiment of this application, which is an example shown.

[0032] Figure 3 This is a schematic diagram illustrating the information interaction during the creation of a trust loop;

[0033] Figure 4 This is an illustrative diagram illustrating the interaction between the device and the cloud during the creation of a trust ring.

[0034] Figure 5A This is an example illustration of the interface for accessing the "My Device" application when an account is logged in;

[0035] Figure 5B This is an example illustration of the interface for accessing the "My Device" application without logging into an account;

[0036] Figure 6 This is an example illustration of the interface for accessing the "Password Vault Sync" application from the "My Device" application on device A;

[0037] Figure 7A This is an exemplary diagram illustrating the process of accessing the "Password Vault" interface when device A has been set with a lock screen code;

[0038] Figure 7B This is an exemplary diagram illustrating the process of accessing the "Password Vault" interface on device A when no lock screen code is set.

[0039] Figure 8 This is a schematic diagram illustrating the process of enabling the "Password Vault Synchronization" switch in a scenario of creating a trust ring;

[0040] Figure 9 This is a schematic diagram illustrating the process of enabling the "Sync to Honor Account" switch in a scenario of creating a trust ring;

[0041] Figure 10 This is a schematic diagram illustrating the process of creating a trust ring;

[0042] Figure 11 This is an illustrative diagram showing how device A synchronizes encrypted business data to the account management server after a trust ring is created.

[0043] Figure 12 This is an example of a module interaction diagram illustrating the synchronization of encrypted business data.

[0044] Figure 13 This is an example illustration of an interface for synchronizing encrypted business data to an account management server.

[0045] Figure 14 This is a schematic diagram illustrating the information interaction during the process of adding device B to the trust ring, as exemplarily shown.

[0046] Figure 15 This is an example illustration of the interface for accessing the "Password Vault Sync" application from the "My Device" application on device B.

[0047] Figure 16A This is an exemplary diagram illustrating the process of entering the "Password Vault" interface and turning on the "Password Vault Synchronization" switch when device B has been set with a lock screen code;

[0048] Figure 16B This is an exemplary diagram illustrating the process of entering the "Password Vault" interface and turning on the "Password Vault Synchronization" switch on device B without setting a lock screen code;

[0049] Figure 17 This is a schematic diagram illustrating the process of enabling the "Sync to Honor Account" switch in the scenario where device B is added to the trust ring, as shown in the example.

[0050] Figure 18 A schematic diagram illustrating the process of adding device B to the trust ring;

[0051] Figure 19 This is an example illustration of how device B synchronizes encrypted business data from the account management server after being added to a trust ring.

[0052] Figure 20 This is an example illustration of an interface for synchronizing encrypted business data from an account management server.

[0053] Figure 21 This is an example of an interface diagram illustrating the process of creating a trust ring for device A under a password vault service.

[0054] Figure 22 This is a schematic diagram illustrating the process of creating a trust ring;

[0055] Figure 23 This is an example of an interface diagram illustrating the process of adding device B to the trust ring under the password safe service.

[0056] Figure 24 This is a schematic diagram illustrating the process of joining a trust ring. Detailed Implementation

[0057] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0058] In this article, the term "and / or" is merely a description of the relationship between related objects, indicating that there can be three relationships. For example, A and / or B can represent three situations: A exists alone, A and B exist simultaneously, and B exists alone.

[0059] The terms "first" and "second," etc., used in the specification and claims of this application are used to distinguish different objects, not to describe a specific order of objects. For example, "first target object" and "second target object," etc., are used to distinguish different target objects, not to describe a specific order of target objects.

[0060] In the embodiments of this application, the terms "exemplary" or "for example" are used to indicate that something is an example, illustration, or description. Any embodiment or design that is described as "exemplary" or "for example" in the embodiments of this application should not be construed as being more preferred or advantageous than other embodiments or design. Specifically, the use of the terms "exemplary" or "for example" is intended to present the relevant concepts in a specific manner.

[0061] In the description of the embodiments in this application, unless otherwise stated, "multiple" means two or more. For example, multiple processing units means two or more processing units; multiple systems means two or more systems.

[0062] Figure 1 This is a schematic diagram illustrating the structure of an electronic device 100 as an example. It should be understood that... Figure 1 The electronic device 100 shown is merely an example of an electronic device, and the electronic device 100 may have more or fewer components than those shown in the figure, may combine two or more components, or may have different component configurations. Figure 1 The various components shown can be implemented in hardware, software, or a combination of hardware and software, including one or more signal processing and / or application-specific integrated circuits.

[0063] Among them, electronic devices 100 can be mobile phones, tablets, etc.

[0064] Electronic device 100 may include: processor 110, external memory interface 120, internal memory 121, universal serial bus (USB) interface 130, charging management module 140, power management module 141, battery 142, antenna 1, antenna 2, mobile communication module 150, wireless communication module 160, audio module 170, speaker 170A, receiver 170B, microphone 170C, headphone jack 170D, sensor module 180, button 190, motor 191, indicator 192, camera 193, display screen 194, and subscriber identification module (SIM) card interface 195, etc. The sensor module 180 may include a pressure sensor 180A, a gyroscope sensor 180B, a barometric pressure sensor 180C, a magnetic sensor 180D, an accelerometer sensor 180E, a distance sensor 180F, a proximity sensor 180G, a fingerprint sensor 180H, a temperature sensor 180J, a touch sensor 180K, an ambient light sensor 180L, a bone conduction sensor 180M, etc.

[0065] The software system of electronic device 100 can adopt a layered architecture, event-driven architecture, microkernel architecture, microservice architecture, or cloud architecture. This application embodiment uses the layered architecture Android system as an example to exemplify the software structure of electronic device 100.

[0066] The layered architecture of the electronic device 100 divides the software into several layers, each with a clear role and division of labor. Layers communicate with each other through software interfaces. In some embodiments, the Android system is divided into three layers, from top to bottom: the application layer, the application framework layer, and the kernel layer.

[0067] The application layer can include a series of application packages.

[0068] like Figure 2 As shown, the application package may include applications such as sensors (also known as desktop and wallpaper), HMS core, trust ring, and password vault. For example, sensors can monitor user actions such as swiping and pressing on the screen, while HMS core provides a collection of on-device and cloud-based capabilities. The trust ring application is used to create and manage trust rings for accounts. Trust ring management includes, but is not limited to: adding devices to the trust ring, removing devices from the trust ring, deleting the trust ring, freezing the trust ring, and updating the master key ciphertext under the trust ring. The password vault is used to manage business data synchronized by users to the account management server, such as login accounts and passwords for a specific business.

[0069] The application framework layer provides application programming interfaces (APIs) and a programming framework for applications in the application layer. The application framework layer includes some predefined functions.

[0070] like Figure 2 As shown, the application framework layer may include a window manager, a view system, an F interface, and a resource manager, etc.

[0071] The window manager is used to manage window programs. The window manager can obtain the screen size, determine if a status bar is present, lock the screen, capture the screen, and send interface information display commands to the view system, etc.

[0072] A view system includes visual controls, such as controls for displaying text and controls for displaying images. View systems can be used to build applications. A display interface can consist of one or more views. For example, a display interface including a text notification icon could include views for displaying text and views for displaying images.

[0073] The file explorer provides applications with various resources, such as localized strings, icons, images, layout files, video files, and more.

[0074] Interface F is the external service interface of the trust loop.

[0075] The application layer and application framework layer run in a virtual machine. The virtual machine executes the Java files of the application layer and application framework layer as binary files. The virtual machine is used to perform functions such as object lifecycle management, stack management, thread management, security and exception management, and garbage collection.

[0076] The system library can include multiple functional modules. For example: a 2D graphics engine (e.g., SGL), a critical asset trust ring (CA), a surface manager, etc.

[0077] The Surface Manager manages the display subsystem and provides the blending of 2D and 3D layers for multiple applications. The 2D Graphics Engine is the drawing engine for 2D images.

[0078] The Critical Asset Trust Ring (CA), also known as the Trust Ring Service Module, is mainly used for message pass-through between the upper-layer Trust Ring application and the lower-layer Critical Asset Trust Ring (TA).

[0079] The kernel layer is the layer between hardware and software. The kernel layer includes at least the display driver, sensor driver, Wi-Fi driver, and the critical asset trust ring (TA). The display driver drives the display screen 194, the Wi-Fi driver drives the wireless communication module 160, and the sensor driver drives the sensor module 180.

[0080] The Critical Asset Trust Ring (TA), also known as the Trust Ring Module, is used to implement core security logic, provide a trusted execution environment, and generate master keys and encrypt them to generate master key ciphertext within this environment. For the specific functions of the Critical Asset Trust Ring (CA) and the Critical Asset Trust Ring (TA), please refer to the relevant descriptions in the following sections on ring creation, ring addition, ring deletion, anti-riot measures, device decommissioning within the trust ring, updating master keys, and updating master key ciphertext.

[0081] Understandable, Figure 2 The components included in the system framework layer and runtime layer shown do not constitute a specific limitation on the electronic device 100. In other embodiments of this application, the electronic device 100 may include more or fewer components than shown, or combine some components, or split some components, or have different component arrangements.

[0082] When using electronic devices, users typically need to remember a lot of passwords, such as email account passwords, cloud storage account passwords, smart home control passwords, and so on. When there is a large amount of this password data, requiring users to independently record the passwords for each service would be quite difficult. Therefore, users hope to use data synchronization functions to upload this password data to the cloud for storage, retrieving it directly from the cloud when needed, without having to memorize it themselves.

[0083] However, users have different security requirements for this type of password data compared to general data to be synchronized, such as pictures, contacts, and text messages. The leakage of this type of password data can cause significant losses to users. Therefore, users have high security requirements for this type of password data. In this case, the cloud's inability to prove its innocence greatly reduces the security of data synchronized to the cloud, failing to meet the high security requirements of this type of password data.

[0084] This application provides a data protection method that enables the cloud side to prove its innocence, and can support the data synchronization of business data with high security requirements such as cryptographic data.

[0085] The data protection method of this application will be described in detail below with reference to the accompanying drawings.

[0086] The first method for creating a trust loop

[0087] Figure 3 This is a schematic diagram illustrating the information interaction during the creation of a trust loop. Figure 4 This is an example illustration of the interaction between the device and the cloud during the creation of a trust ring. Figure 10 This is a schematic diagram illustrating the process of creating a trust ring.

[0088] The following is combined Figure 3 , Figure 4 and Figure 10 The process of creating a trust ring according to the embodiments of this application will be described in detail.

[0089] In this embodiment, it is assumed that the Honor account of device A is account 1, and the process of creating a trust ring is described by taking the initial registration of device A with the Trust Ring Cloud and the creation of Trust Ring 1 for account 1 as an example. The application that can trigger the trust ring creation process can be any application under the Honor account. In this paper, the process of triggering the trust ring creation process through the "Password Vault Synchronization" application under the Honor account is used as an example.

[0090] In this article, "registration" refers to the process of adding a device to a trust ring. For the first device registration, since the account does not yet have a trust ring, a trust ring needs to be created before adding the device. This process of registering the first device is referred to as "creating a trust ring." For subsequent device registrations, the device only needs to be added to an existing trust ring; this process is referred to as "joining a trust ring."

[0091] This article assumes that account 1 includes 3 devices: Honor V40 (device A), Honor V30 (device B), and Honor V50 (device C).

[0092] It should be noted that the actions performed by various clouds in this article should be understood as actions performed by the servers within the respective clouds. For example, the actions performed by the account management server are executed by the account management server itself, and the actions performed by the trust ring cloud are executed by the trust ring cloud server.

[0093] Please see Figure 3 During the creation of the trust ring, device A sends a request to the account management server to log in to account 1. After the account management server verifies the request to log in to account 1, it returns a verification success message to device A. After receiving the verification success message, device A generates the master key ciphertext EMK11 and the authentication parameter PAKE11, and sends EMK11 and PAKE11 to the trust ring cloud. After receiving EMK11 and PAKE11 sent by device A, the trust ring cloud creates trust ring 1 for account 1 and adds device A to trust ring 1.

[0094] Please see Figure 10 In this embodiment of the application, the process of device A creating a trust ring may include the following steps:

[0095] Step S1: Log in to account 1 on device A.

[0096] This article uses the Honor V40 mobile phone as an example for illustration. It should be understood that device A can be any electronic device that has the trust ring creation function of this application installed, and this application does not impose any restrictions.

[0097] Device A needs to be logged into an account before it can initiate registration with the Trust Ring Cloud to create a Trust Ring. If Device A is not logged into an account, it needs to log in first.

[0098] Figure 5A This is an example illustration of the interface for accessing the "My Device" application when an account is logged in. Figure 5B This is an example illustration of the interface for accessing the "My Device" application without logging into an account. Figure 6 This is an example illustration of the interface for accessing the "Password Vault Sync" application from the "My Device" application on device A.

[0099] Please see Figure 5A and Figure 6 If device A is already logged into account 1 (assuming account 1 is 1581991××××), the user can click the "Settings" application icon on the main interface of device A (e.g., ...). Figure 5A As shown in Figure (a), enter Figure 5A The “Settings” interface is shown in Figure (b). In the “Settings” interface, the user clicks on account 1 (i.e., 1581991××××) to enter… Figure 5A The “Account Center” interface is shown in Figure (b). In the “Account Center” interface, the user clicks “My Device” to enter… Figure 6 The "My Devices" interface is shown in Figure (b). In the "My Devices" interface, locate the current device, i.e., Honor V40, and tap on Honor V40 to enter... Figure 6 The "Device Information" interface is shown in Figure (c). On the "Device Information" interface, the user can access the "Password Vault Sync" application by clicking on it. In the "Password Vault" interface, after enabling the "Password Vault Sync" switch, clicking the "Sync to Honor Account" switch triggers the process of creating a trust ring. The processes of accessing the "Password Vault" interface, enabling the "Password Vault Sync" switch, and enabling the "Sync to Honor Account" switch will be explained later.

[0100] It should be noted that if account 1 already has a trust ring, devices added to the trust ring will be displayed as "Trusted Devices" on the "My Devices" interface. Devices marked as "Trusted Devices" are those already added to the trust ring, i.e., registered devices. Please refer to subsequent sections for more details. Figure 15 The interface shown in Figure (b). If there is no trust loop under account 1, for example in Figure 6In Figure (b), on the "My Devices" interface of device A, none of the three Honor devices are trusted devices, indicating that there is no trust ring under the current account 1.

[0101] Please see Figure 5A , Figure 5B and Figure 6 If user A is not logged into account 1 on device A, and the user clicks the "Settings" application icon on the main interface of device A (e.g., ... Figure 5A After (as shown in Figure (a)), proceed to... Figure 5B The "Settings" interface is shown in Figure (a). In the "Settings" interface, the user clicks "Log in to Honor account" to enter... Figure 5B Figure (b) shows the Honor account login interface. On the Honor account login interface, the user enters account 1 (1581991××××) and login password (assumed to be key1). Device A sends a login request for account 1 to the account management server, carrying account 1 (1581991××××) and login password key1 in the request.

[0102] Please see Figure 4 Users can send a login request for account 1 to the account management server through the account management module of the application layer of device A to log in to account 1.

[0103] After device A successfully logs in to account 1, it triggers the trust ring creation process according to the aforementioned process for an already logged-in account. Please refer to [link to relevant documentation]. Figure 5A Figures (c), (d), and Figure 6 As shown, it will not be elaborated further here.

[0104] Step S2: The account management server returns a verification successful message.

[0105] The account management server pre-stores information about account 1, including its login password. Let's assume the password stored for account 1 is key0. When the account management server receives a login request for account 1 from device A, it verifies the request based on the information stored locally. If the password key1 in the login request matches the password key0 stored locally on the account management server, the login verification for account 1 is successful. At this point, the account management server returns a verification success message to device A.

[0106] If the password key1 for account 1 carried in the login request does not match the password key0 for account 1 stored locally on the account management server, the account management server determines that login verification for account 1 has failed. In this case, the account management server returns a verification failure message to device A. At this point, the user needs to... Figure 5B (b) Re-enter your account and login password.

[0107] Please see Figure 4 and Figure 10 Device A receives verification success or verification failure messages through the account management module.

[0108] S3: Send a registration activation notification.

[0109] Please see Figure 4 and Figure 10 When the account management module of device A receives a verification success message from the account management server, the account management module in device A sends a registration start notification to the trust ring service module in the application framework layer. The registration start notification instructs the trust ring service module to initiate the registration process.

[0110] This section explains the process by which device A enters the "Password Vault" interface and turns on the "Password Vault Synchronization" switch during the creation of a trust ring.

[0111] Figure 7A This is an exemplary diagram illustrating the process of accessing the "Password Vault" interface when device A has been set with a lock screen code. Please refer to [link / reference]. Figure 7A If the user of device A has set a lock screen code (also known as a lock screen password) for device A, when the user clicks the "Password Vault Sync" application on the "Device Information" screen (see [link]), Figure 7A (See Figure (a)). Device A displays the "Enter Lock Screen Password" screen (see Figure (a)). Figure 7A (Figure (b)). If the user enters the lock screen code on the "Enter Lock Screen Password" screen and the lock screen code is correct, the screen of device A will enter the "Password Vault" screen (see Figure (b)). Figure 7A (See Figure (c)). At this time, both the "Password Vault Sync" switch and the "Sync to Honor Account" switch on the "Password Vault" interface are turned off.

[0112] Figure 7B This is an exemplary diagram illustrating the process of accessing the "Password Vault" interface on device A when no lock screen code is set. Please refer to [link / reference]. Figure 7B If the user of device A has not set a lock screen code for device A, when the user clicks the "Password Vault Sync" application on the "Device Information" screen (see [link]), Figure 7B (See Figure (a)). Device A displays the "Set Numeric Lock Screen Password" interface (see Figure (a)). Figure 7B (Figure (b)). Users in Figure 7B After entering the lock screen code on the "Set Numeric Lock Screen Password" interface shown in Figure (b), Device A will display a confirmation screen for the "Set Numeric Lock Screen Password" (see Figure 1). Figure 7B(c) diagram). User in Figure 7B On the interface shown in Figure (c), the user enters the lock screen code again. If the re-entered lock screen code matches the one the user entered in the previous step... Figure 7B When the lock screen code entered on the interface shown in Figure (b) matches, the screen of device A enters... Figure 7B The “Password Vault” interface shown in Figure (d) is similar to... Figure 7A The interface shown in Figure (c) is the same.

[0113] Figure 8 This is a schematic diagram illustrating the process of enabling the "Password Vault Synchronization" switch in a scenario where a trust ring is created. Please refer to [link / reference]. Figure 8 When the user clicks the "Password Vault Synchronize" switch on the "Password Vault" interface (see [link]), Figure 8 (Figure (a)) A pop-up appears on the screen of device A. Figure 8 The reminder interface shown in Figure (b) is used to prompt the user whether they agree to enable the password vault synchronization service. When the user clicks the "Agree" button on the reminder interface (see Figure [link to relevant documentation]), the reminder will be displayed. Figure 8 (See Figure (b)). The "Password Vault Synchronization" switch on the "Password Vault" interface is turned on (see Figure (b)). Figure 8 (Figure (c)).

[0114] When the Trust Ring service module receives a registration activation notification, it cannot determine whether it is initiating the process of creating a Trust Ring or joining a Trust Ring. It needs to determine this by checking the registration status.

[0115] S4: The trust ring service module in device A detects the registration status of device A.

[0116] The registration status includes two states: unregistered and registered. The unregistered state indicates that the device is not currently registered to the trusted ring, while the registered state indicates that the device is currently registered to the trusted ring.

[0117] S5: When it is detected that the registration status of device A is not registered, device A sends a registration status comparison request to the Trust Ring Cloud.

[0118] The registration status comparison request is used to instruct the user to obtain the comparison result between the registration status of device A detected by the trust ring service module and the registration status of device A stored in the trust ring cloud.

[0119] The registration status comparison request includes the UID (device identifier) ​​of device A and the UDID (account identifier) ​​of the account to which device A belongs.

[0120] S6: Trust Ring Cloud returns a first registration status confirmation message to the Trust Ring Service Module in Device A.

[0121] The first registration status confirmation message is used to indicate that there is no trust ring under account 1.

[0122] After receiving a registration status comparison request from device A, TrustRingCloud first checks if a trust ring exists under account 1. If a trust ring exists under account 1, it then checks if device A is within that trust ring. If no trust ring exists under account 1, TrustRingCloud generates a first registration status confirmation message and sends it to device A.

[0123] Based on the first registration status confirmation message returned by the Trust Ring Cloud, Device A determines that it will execute the Trust Ring Creation process during this registration.

[0124] S7: The trust ring service module in device A receives the user's input of device A's lock screen code pw11.

[0125] This section explains the process of enabling the "Sync to Honor Account" switch during the creation of a trust ring.

[0126] Figure 9 This is a schematic diagram illustrating the process of enabling the "Sync to Honor Account" switch in a scenario where a trust ring is created. Please refer to [link / reference]. Figure 9 When a user clicks the "Sync to Honor Account" switch on the "Password Vault Sync" interface where the "Password Vault Sync" switch is enabled (see [link]), Figure 9 (Figure (a)) A "Enter Lock Screen Password" screen pops up on device A's screen (see Figure (a)). Figure 9 (See Figure (b)). If the user enters the lock screen code of device A on the "Enter Lock Screen Password" screen, the trust ring service module in device A will receive the user's lock screen code. If the user's lock screen code for device A is correct, after device A completes the trust ring creation process, it will enter the "Password Vault" screen where both the "Password Vault Synchronization" and "Synchronize to Honor Account" switches are turned on (see Figure (b)). Figure 9 (Figure (c)).

[0127] It should be noted that users in Figure 9 The operation of clicking the "Sync to Honor Account" switch on the interface shown in Figure (a) (see also) Figure 9 (a) Figure triggers device A to execute Figure 10 Step S3 and the subsequent steps in the trust ring creation process.

[0128] The lock screen code of device A is a user secret of device A, and it is unknown to the cloud side.

[0129] S8: The trust ring service module of device A verifies the lock screen code pw11 of device A.

[0130] The process of verifying the lock screen code of device A can be as follows: device A compares the lock screen code entered by the user with the lock screen code pre-stored in device A. If the two match, the verification is successful; otherwise, the verification fails.

[0131] Here, the trust ring service module provides users with... Figure 9 The device lock screen code entered on the interface shown in Figure (b) is re-verified. Only after successful verification can the subsequent step S9 be executed. If verification fails, device A will return to... Figure 9 The interface shown in Figure (b) displays an error message indicating that the entered lock code is incorrect.

[0132] S9: The Trust Ring Service module derives PWUATH11 from the lock screen code of device A.

[0133] Assuming the user enters the lock screen code pw11, the trust ring service module derives PWUATH11 from pw11.

[0134] Since pw11 is a user secret of device A, the cloud side cannot obtain pw11, and therefore cannot obtain PWUATH11 derived from pw11.

[0135] Since PWUATH11 is generated based on the user secret pw11 which is unknown to the cloud side, PWUATH11 is unknown to the cloud side.

[0136] S10: The Trust Ring Service Module of Device A sends PWAUTH11 to the Trust Ring Module in the Trusted Execution Environment of Device A.

[0137] Subsequently, the trust ring module generates the master key ciphertext EMK11 and parameter PAKE11 based on PWAUTH11. For details on how EMK11 and PAKE11 are generated, please refer to [link to documentation]. Figure 10 Steps S11 to S14.

[0138] S11: Trust ring module generates MK.

[0139] Device A generates MK, or master key, through the trust ring module. MK is stored in the trusted execution environment of device A. Even if device A is attacked, MK will not be stolen, so the security is very high.

[0140] S12: The trust ring module encrypts MK based on PWAUTH11 to generate EMK11.

[0141] EMK11 is the first master key ciphertext. The trust ring module derives a key KEK11 based on PWAUTH11, and then encrypts MK based on KEK11 to generate EMK11.

[0142] S13: The trust ring module of device A sends EMK11 to the trust ring service module of device A.

[0143] After the trust ring module generates EMK11, it sends EMK11 to the trust ring service module. At the same time, it also sends salt_enc11 to the trust ring service module.

[0144] S14: The trust ring service module in device A generates parameter PAKE11 based on PWAUTH11.

[0145] S15: Device A sends a creation request carrying EMK11 and parameter PAKE11 to the Trust Ring Cloud through the Trust Ring Service Module.

[0146] Device A sends a creation request to the Trust Ring Cloud through the Trust Ring Service module. This request enables the registration of PAKE11 parameters and the management of EMK11.

[0147] To enhance the security of EMK11, the Trust Ring Service module can perform secondary encryption on EMK11 based on the public key of the Trust Ring Cloud HSM obtained during login before sending EMK11, thus obtaining the second-layer ciphertext of the master key.

[0148] S16: Trust Ring Cloud responds to the creation request, creates Trust Ring 1 for account 1, and adds device A to Trust Ring 1.

[0149] In response to the creation request sent by device A, Trust Ring Cloud creates Trust Ring 1 for account 1. When other devices under account 1, such as device B and device C, send a registration status comparison request to Trust Ring Cloud, Trust Ring Cloud will return a confirmation message that Trust Ring 1 exists but device B and device C are not in the Trust Ring. Device B and device C then execute the process of joining the Trust Ring. For details on the process of joining the Trust Ring, please refer to the following related instructions.

[0150] After Trust Ring 1 is created, the data of Trust Ring 1 managed in the Trust Ring Cloud is shown in Table 1:

[0151] Table 1

[0152] UID UDID Parameter PAKE Master key ciphertext Account 1 Equipment A PAKE11 EMK11

[0153] S17: Trust Ring Cloud returns a successful ring creation message to the Trust Ring Service Module of Device A.

[0154] TrustRing Cloud creates TrustRing 1 for Account 1 and adds Device A to TrustRing 1. After adding Device A, it sends a successful trust ring creation message to Device A. Upon receiving the message, Device A enables the "Sync to Honor Account" switch in the Password Vault interface. Figure 9As shown in Figure (c), after the "Sync to Honor Account" switch is turned on, the user can perceive that device A has successfully joined the trust ring, and the business data in the password vault can be synchronized to the account management server so that other devices under account 1 in trust ring 1 can share the business data.

[0155] At this point, the trust ring creation process is complete, and device A has finished registering.

[0156] After device A completes registration, the trust ring service module of device A will change the registration status of device A to "registered".

[0157] As can be seen from the trust ring creation process, the embodiments of this application protect the account-level master key MK based on the user secret. Since the user secret is unknown to the cloud side, the cloud side cannot decrypt the ciphertext of the master key it manages. This reduces the risk of master key leakage, improves the security of the master key MK, and enables the cloud side to prove its innocence.

[0158] It should be noted that the above process should be understood as an illustrative example of the process of creating a trust ring in this application, and is not intended to limit this application.

[0159] Figure 11 This is an example illustration of device A synchronizing encrypted business data to the account management server after a trust ring is created. Figure 12 This is an example of a module interaction diagram illustrating the synchronization of encrypted business data. Figure 13 This is an example illustration of an interface for synchronizing encrypted business data to an account management server. Please refer to... Figure 11 , Figure 12 and Figure 13 With trust ring 1 already created for account 1 and device A added to trust ring 1, device A can use MK to encrypt sensitive business data, obtain ciphertext of the business data, and upload the ciphertext of the business data to the account management server.

[0160] The process by which device A synchronizes encrypted business data to the account management server after creating a trust ring is as follows:

[0161] Please see Figure 12In device A, the application layer's password vault reads plaintext business data and stores it in the application framework layer's business data storage service module. This module then sends the plaintext business data to the key management module in the trusted execution environment. The trust ring module generates a business key (dkey) based on the MK (Key Management Module). The key management module reads the dkey from the trust ring module and uses it to encrypt the business data (data), obtaining the encrypted business data (Edata). The key management module returns the encrypted Edata to the business data storage service module, which then uploads it to the account management server via the business data synchronization service module and the application layer's account management server synchronization framework.

[0162] It should be noted that different services have different service keys (dkey), and device A can generate service keys for different services based on the MK.

[0163] For example, see Figure 13 When a user uses service 1 on device A, they need to enter the account and password for service 1, such as... Figure 13 As shown in Figure (a), after entering the account and password for Service 1, Device A prompts whether to synchronize the account and password for Service 1 to the password safe, as shown in Figure (a). Figure 13 As shown in Figure (b). If the user agrees, device A will use the account and password of service 1 as service data data1, and upload the encrypted Edata1 of data1 to the account management server according to the same synchronization process as the service data data.

[0164] As can be seen from the above, in this embodiment of the application, the encrypted business data in the account management server does not rely entirely on account security, but also on the security of MK. Even if the account is stolen, it will not affect the security of the data in the cloud.

[0165] User business data is encrypted using a highly secure master key, and then the encrypted business data is synchronized to the account management server, reducing the risk of encrypted business data leakage and improving the security of data synchronization and backup.

[0166] The first method involves adding a trust ring.

[0167] With device A already having created trust ring 1 for account 1, device B under account 1 can join trust ring 1 according to the joining process in the following embodiment. Before device B joins trust ring 1, trust ring 1 only contains device A.

[0168] Figure 14 This is a schematic diagram illustrating the information interaction during the process of adding device B to the trust ring, as exemplarily shown. Figure 18This is a schematic diagram illustrating the process of adding device B to the trust ring, as shown in the example.

[0169] The following is combined Figure 14 and Figure 18 The process of adding a trust ring according to the embodiments of this application will be described in detail.

[0170] Please see Figure 14 After device A registers as the first device, the trust ring creation process is completed. Device A has uploaded its master key ciphertext EMK11 (the first master key ciphertext) and authentication parameter PAKE11 to the trust ring cloud. Subsequently, other devices, such as device B, register by joining the trust ring. During device B's joining trust ring 1, device B sends device A's authentication parameter PAKE12, already stored in trust ring 1, to the trust ring cloud. After confirming that PAKE12 matches the stored authentication parameter PAKE11, the trust ring cloud returns device A's master key ciphertext EMK11 to device B. Then, device B decrypts MK from EMK11 and encrypts MK based on its lock screen code, generating device B's master key ciphertext EMK21 (the second master key ciphertext) and authentication parameter PAKE21, and sends EMK21 and PAKE21 to the trust ring cloud.

[0171] Please see Figure 18 In this embodiment of the application, the process of adding device B to the trust ring may include the following steps:

[0172] S1: Device B login account 1.

[0173] Similar to device A, device B logs in to account 1 by sending a request to the account management server. For a detailed explanation of device B's login process for account 1, please refer to the previous description of device A's login process for account 1; it will not be repeated here.

[0174] S2: The account management server returns a verification success message to device B.

[0175] For details on how the account management server handles the request for device B to log in to account 1, please refer to the aforementioned process for how the account management server handles the request for device A to log in to account 1. These details will not be repeated here.

[0176] After device B successfully logs in to account 1, the user can... Figure 5A The process indicated by diagrams (b) and (c) leads to the "Account Center" interface, where you find the "My Devices" application.

[0177] S3: Send a registration activation notification.

[0178] Please see Figure 4 and Figure 18Upon receiving a verification success message from the account management server, the account management module of device B sends a registration initiation notification to the trust ring service module in the application framework layer. This notification instructs the trust ring service module of device B to begin the registration process.

[0179] This section explains the process by which device B enters the "Password Vault" interface and turns on the "Password Vault Synchronization" switch during the process of joining the trust ring.

[0180] Figure 15 This is an example illustration of the interface for accessing the "Password Vault Sync" application from the "My Device" application on device B. (Comparison) Figure 6 As can be seen, during the process of joining the trust ring, there is a trusted device Honor V40 on the "My Devices" interface of device B, which is device A. This indicates that a trust ring already exists under account 1.

[0181] Figure 16A This is an exemplary diagram illustrating the process of accessing the "Password Vault" interface and activating the "Password Vault Synchronization" switch on device B, which has been set with a lock screen code. Please refer to [link / reference]. Figure 16A If the user of device B has set a lock screen code for device B, when the user clicks the "Password Vault Sync" application on the "Device Information" screen (see [link]), Figure 16A (See Figure (a)). Device B displays the "Enter Lock Screen Password" screen (see Figure (a)). Figure 16A (See Figure (b)). If the user enters the lock screen code on the "Enter Lock Screen Password" screen and the lock screen code is correct, the screen of device B will enter the "Password Vault" screen (see Figure (b)). Figure 16A (Figure (c)). At this time, both the "Password Vault Sync" switch and the "Sync to Honor Account" switch on the "Password Vault" interface are in the off state. Unlike device A during the creation of the trust ring, device B, during the joining of the trust ring, when the user clicks... Figure 16A As shown in Figure (c), the "Password Vault Synchronization" switch on the "Password Vault" interface will directly switch the screen of Device B to... Figure 16A The interface shown in Figure (d) is the one where the "Password Vault Sync" switch is turned on, but the "Sync to Honor Account" switch is not turned on.

[0182] Figure 16B This is an exemplary diagram illustrating the process of accessing the "Password Vault" interface and activating the "Password Vault Synchronization" switch on device B without a lock screen code. Please refer to [link / reference]. Figure 16B The process of device B entering the "Password Vault" interface and turning on the "Password Vault Sync" switch without setting a lock screen code, and... Figure 16AThe process of entering the "Password Vault" interface and turning on the "Password Vault Sync" switch on device B, which has a lock screen code set, differs from the process on device B, which requires setting a lock screen password if no lock screen code is set (see [link]). Figure 16B (b) and confirm the lock screen password (see Figure 1) Figure 16B (See Figure (c)). The rest of the process is the same as the process when a lock screen code has been set, and will not be described again here.

[0183] S4: The trust ring service module in device B detects the registration status of device B.

[0184] For instructions on this step, please refer to the aforementioned section. Figure 10 The description of step S4 will not be repeated here.

[0185] S5: When device B is detected to be unregistered, a registration status comparison request is sent.

[0186] For instructions on this step, please refer to the aforementioned section. Figure 10 The description of step S5 will not be repeated here.

[0187] S6: Return the second registration status confirmation message.

[0188] The second registration status confirmation message is used to indicate that trust ring 1 exists under account 1, but device B is not on trust ring 1.

[0189] After receiving the registration status comparison request from device B, TrustRing Cloud first checks whether a trust ring exists under account 1. Since TrustRing 1 for account 1 was already created during device A's registration, it confirms the existence of a trust ring under account 1. Then, based on the trust ring data for account 1 shown in Table 1, TrustRing Cloud confirms that device B is not in the trust ring. At this point, TrustRing Cloud generates a second registration status confirmation message and sends it to device B.

[0190] Based on the second registration status confirmation message returned by the Trust Ring Cloud, Device B determines that it will execute the process of joining the Trust Ring during this registration.

[0191] S7: The trust ring service module in device B receives the user-input device B lock screen code pw21.

[0192] Figure 17 This diagram illustrates the process of enabling the "Sync to Honor Account" switch in a scenario where device B is added to the trust ring, as shown in the example. Please refer to... Figure 17 When a user clicks the "Sync to Honor Account" switch on the "Password Vault Sync" interface where the "Password Vault Sync" switch is enabled (see [link]), Figure 17 (See Figure (a)). On device B's screen, a "Enter lock screen password" interface pops up (see Figure (a)). Figure 17 (See Figure (b)). If the user enters the lock screen code of device B on the "Enter Lock Screen Password" screen, the trust loop service module in device B will receive the lock screen code of device B entered by the user.

[0193] S8: The trust ring service module of device B verifies the lock screen code pw21 of device B, and derives PWAUTH21 based on the lock screen code pw21 of device B.

[0194] For the process of verifying the lock screen code pw21 of device B, please refer to the process of verifying the lock screen code pw11 of device A mentioned above, which will not be repeated here.

[0195] S9: The trust ring service module of device B obtains the list of devices in trust ring 1.

[0196] The Trust Ring Service Module of Device B can send a request to the Trust Ring Cloud to obtain the list of devices in Trust Ring 1. After receiving the request, the Trust Ring Cloud returns the list of devices in Trust Ring 1 to the Trust Ring Service Module of Device B.

[0197] S10: Trust Ring Cloud returns the list of devices in Trust Ring 1 to the Trust Ring Service Module of Device B.

[0198] The device list in Trust Ring 1 includes all devices currently joined to Trust Ring 1. In this embodiment, since device A is the device that created Trust Ring 1, and device B is the first device to join Trust Ring 1, the device list in Trust Ring 1 returned by Trust Ring Cloud during the process of device B joining Trust Ring 1 only includes device A.

[0199] S11: The trust ring service module of device B displays the screen lock code input interface of device A, receives the screen lock code pw12 of device A input by the user, and generates parameter PAKE12 based on the screen lock code pw12.

[0200] Please continue reading Figure 17 If the user is Figure 17 The lock screen password for device B entered in the interface shown in Figure (b) is correct. A "Enter lock screen password for other Honor devices" interface pops up on device B's screen (see Figure (b)). Figure 17 (c) Figure Figure 17 In diagram (c), "Other Honor Devices" refers to the Honor V40, i.e., device A. When the user enters device A's lock screen code pw12 on the "Enter Other Honor Device Lock Screen Password" screen, if the entered code is correct, device B will enter the "Password Vault" screen after completing the trust ring joining process. This screen will have both the "Password Vault Sync" and "Sync to Honor Account" switches enabled (see [link]). Figure 17(See Figure (d)). When the "Password Vault Synchronize" switch is turned on, business data in the password vault can be synchronized to the cloud. When the "Synchronize to Honor Account" switch is turned on, business data in the password vault can be synchronized to various devices under Trust Ring 1, such as device A. In actual implementation, the "Password Vault Synchronize" switch and the "Synchronize to Honor Account" switch can be combined into one switch.

[0201] It should be noted that users in Figure 17 The operation of clicking the "Sync to Honor Account" switch on the interface shown in Figure (a) (see also) Figure 17 (a) Figure triggers device A to execute Figure 18 Step S3 and the subsequent steps in the trust ring process.

[0202] The lock screen code of device B is a user secret of device B, and it is unknown to the cloud side.

[0203] The generation principle of parameter PAKE12 is the same as that of parameter PAKE11 mentioned above, so it will not be repeated here.

[0204] S12: The Trust Ring Service Module of Device B sends parameter PAKE12 to the Trust Ring Cloud.

[0205] During the process of adding device B to Trust Ring 1, Trust Ring Cloud needs to verify the identity of the device already in Trust Ring 1. Only when the verification is successful will device B be allowed to join Trust Ring 1; otherwise, Trust Ring Cloud will prohibit device B from joining Trust Ring 1.

[0206] S13: After the Trust Ring Cloud authenticates device A based on parameter PAKE12, it returns device A's EMK11 to the Trust Ring Service Module of device B.

[0207] S14: The trust ring service module of device B sends EMK11 and PWAUTH21 to the trust ring module of device B.

[0208] The trust ring module is located in the trusted execution environment of device B. Device B needs to decrypt EMK11 in the trusted execution environment to retrieve MK, and encrypt MK based on PWAUTH21 in the trusted execution environment to obtain EMK21.

[0209] S15: The trust ring module of device B decrypts EMK11 to obtain MK, and encrypts MK based on PWAUTH21 to obtain EMK21.

[0210] S16: The trust ring module of device B sends EMK21 to the trust ring service module of device B.

[0211] S17: Device B generates parameter PAKE21 based on PWAUTH21.

[0212] For details on this process, please refer to the relevant instructions on the generation of parameter PAKE11 based on PWAUTH11 by the Trust Ring Service Module in Device A during the first Trust Ring Creation process. It will not be repeated here.

[0213] S18: The Trust Ring Service Module of Device B sends a ring-adding request carrying EMK21 and parameter PAKE21 to the Trust Ring Cloud.

[0214] S19: The Trust Ring Cloud responds to the ring addition request and adds device B to Trust Ring 1.

[0215] After device B is added to Trust Ring 1, the Trust Ring 1 data managed in the Trust Ring Cloud is shown in Table 2:

[0216] Table 2

[0217] UID UDID Parameter PAKE Master key ciphertext Account 1 Equipment A PAKE11 EMK11 Account 1 Equipment B PAKE21 EMK21

[0218] S20: Trust Ring Cloud returns a successful ring addition message to the Trust Ring Service Module of Device B.

[0219] After Trust Ring Cloud adds device B to Trust Ring 1, it returns a ring-addition success message to device B. Upon receiving this message, device B enables the "Sync to Honor Account" switch in the Password Vault interface. Figure 17 As shown in Figure (d), after the "Sync to Honor Account" switch is turned on, the user can perceive that device B has successfully joined the trust ring, and the business data in the password vault can be synchronized to the account management server so that other devices under account 1 in trust ring 1 can share the business data.

[0220] At this point, the process of device B joining trust ring 1 is complete, and device B has completed its registration.

[0221] After device B completes registration, the trust ring service module of device B will change the registration status of device B to registered.

[0222] As can be seen from the trust ring joining process, in this embodiment of the application, the cloud side sends the ciphertext of the registered device's managed master key to the ring-joining device. The ring-joining device decrypts the ciphertext of the registered device's master key based on the user secret of the registered device to obtain the master key MK. Since the user secret of the registered device is unknown to the cloud side and does not need to be forwarded by the cloud side, the cloud side cannot decrypt the ciphertext of the master key and can prove its innocence.

[0223] It should be noted that the above process should be understood as an illustrative example of the process of adding a trust ring in this application, and is not intended to limit this application.

[0224] Figure 19 This is a schematic diagram illustrating how device B, as an example, synchronizes encrypted business data from the account management server after being added to a trust ring. Figure 20 This is an example illustration of an interface for synchronizing encrypted business data from an account management server. Please refer to... Figure 19 , Figure 12 and Figure 20 Given that account 1 has been created in trust ring 1, device A has been added to trust ring 1, and device A has uploaded the encrypted business data Edata to the account management server, device B can synchronize the encrypted business data Edata from the account management server to device B, and then decrypt it locally on device B using MK to obtain the plaintext business data data.

[0225] The process by which device B synchronizes encrypted business data from the account management server after joining the trust ring is as follows:

[0226] Please see Figure 12 In Device B, the business data synchronization service module obtains the encrypted business data Edata from the account management server through the application-layer account management server synchronization framework. Then, the business data synchronization service module in Device B sends the encrypted business data Edata to the business data storage service module in Device B. The business data storage service module then sends the encrypted business data Edata to the key management module in the trust ring environment of Device B. The trust ring module derives a business key dkey based on the master key. The key management module reads the business key dkey from the trust ring module and uses dkey to decrypt the encrypted business data Edata, obtaining the plaintext business data data data. Next, the key management module returns the plaintext business data data data to the business data storage service module, which stores the plaintext business data data data. For example, please refer to [link to relevant documentation]. Figure 20 When a user uses Service 1 on device B, they need to enter the account and password for Service 1. On the account and password input screen for Service 1, as shown... Figure 20 As shown in Figure (a), Device B prompts the user to confirm whether to use the account and password information of Service 1, which has been synchronized with the Password Vault. If the user agrees, Device B automatically fills in the account and password information of Service 1, which has been synchronized with the Password Vault. Figure 20 The interface shown in Figure (a), after being filled, is as follows: Figure 20 As shown in Figure (b). This eliminates the need for users to record passwords separately for each service, improving the user experience.

[0227] It should be noted that after device B is added to trust ring 1, the business data in device B can also be encrypted with the master key MK and synchronized to the account management server. For the synchronization process, please refer to the previous explanation of synchronizing business data of device A to the account management server, which will not be repeated here.

[0228] The second method for creating a trust loop

[0229] Figures 3 to 10 This paper provides a universal method for creating a trust ring on a device. In practical implementation, for scenarios requiring the creation of a trust ring under certain high-security services, users do not need to enter the device's lock screen code after requesting trust ring registration, which reduces the number of user operations and improves the user experience. High-security services can be pre-stored in the device in the form of a whitelist. The high-security services included in the whitelist can be flexibly set by those skilled in the art, and no specific restrictions are imposed here.

[0230] The following uses high-security services as an example of password safe services, combined with... Figure 21 as well as Figure 22 The second method for creating a trust ring will be explained.

[0231] Figure 21 This is an example of an interface diagram illustrating the process of creating a trust ring for device A under a password vault service. Figure 21 As shown in Figure (a), after the user turns on the "Password Security Synchronization" switch, they manually turn on the "Sync to Honor Account" switch. Device A receives the user's operation to turn on the "Sync to Honor Account" switch and executes the trust ring creation process in the background. After the trust ring is created, it is displayed as shown below. Figure 21 The "Sync to Honor Account" switch is turned on in the interface shown in Figure (b).

[0232] Refer to the aforementioned user interface diagram for enabling the password vault synchronization function. Figures 5A to 8 The relevant interface is available. During the request to enter the password safe, the user needs to enter the lock screen code of device A. Device A verifies the lock screen code and then enters the password safe. Since the user has already entered the lock screen code of device A for security verification during the password safe entry process, when the user enables the "Sync to Honor Account" switch under the password safe service to trigger device A to register trust ring 1, the user does not need to enter the lock screen code of device A again. Device A can directly call the stored lock screen code of device A during the trust ring registration process.

[0233] Figure 22 The following is a schematic diagram illustrating the process of creating a trust ring, compared with the example below. Figure 10 right Figure 22 The second method for creating a trust ring will be described below. The second method for creating a trust ring includes the following steps:

[0234] S1: When the account management module of device A modifies the lock screen code, it generates a hash value based on the new lock screen code pw11.

[0235] S2: The account management module of device A sends a hash value to the trust ring service module.

[0236] S3: Device A's trust ring service module generates PWAUTH11 based on the hash value.

[0237] S4: The trust ring service module of device A sends a PWAUTH11 storage command to the trust ring module.

[0238] S5: Device A's trust ring module stores PWAUTH11.

[0239] Compared to Figure 10 The process for creating a trust ring is shown below. Figure 22 The process of creating a trust ring shown includes new steps S1 to S5. This part describes the process of device A storing its local lock screen code.

[0240] When device A adds, deletes, or modifies the lock screen code, it will trigger device A to execute S1 to S5. The specific algorithm for generating PWAUTH11 based on the lock screen code pw11 can be found in the relevant descriptions in the first trust ring creation process mentioned above, and will not be repeated here.

[0241] The trust ring module of device A stores PWAUTH11. When the trust ring module needs to encrypt MK based on PWAUTH11, it can directly extract it without the user having to input the lock screen code of device A. PWAUTH11 is generated based on the lock screen code of device A.

[0242] S6: Login account 1 for the account management module of device A.

[0243] S7: The account management server returns a verification success message to the account management module of device A.

[0244] S8: The account management module of device A sends a registration activation notification to the trust ring service module.

[0245] S9: The trust ring service module of device A detects the registration status of device A.

[0246] S10: When it is detected that the registration status of device A is not registered, the trust ring service module of device A sends a registration status comparison request to the trust ring cloud.

[0247] S11: Trust Ring Cloud returns a first registration status confirmation message to the Trust Ring Service Module of Device A.

[0248] The first registration status confirmation message is used to indicate that there is no trust ring under account 1.

[0249] S6 to S10 reference pairs Figure 10 The detailed explanation of the relevant steps in the trust ring creation process shown in the diagram is sufficient and will not be repeated here.

[0250] S12: The trust ring service module of device A determines whether the current service is a preset service in the whitelist.

[0251] The preset services in the whitelist can be flexibly set by those skilled in the art, and this application does not impose specific restrictions on them. For example, they can be high-security services such as password safes.

[0252] The common feature of the preset services in the whitelist is that device A has already performed security verification on the user during the process of entering the preset service. Therefore, when performing other requests in the preset service scenario, it is not necessary to enter the lock screen code of device A for security verification again.

[0253] S13: If so, the trust ring service module of device A sends a PWAUTH11 extraction command to the trust ring module.

[0254] S12-S13 replacement Figure 10 In the S7-S9 models, users no longer need to manually enter the lock screen code for device A, reducing the number of operations required and improving the user experience.

[0255] S14: The trust ring module of device A extracts PWAUTH11 and generates MK.

[0256] After receiving the PWAUTH11 retrieval instruction from the Trust Ring Service Module, the Trust Ring Module of Device A retrieves the stored PWAUTH11.

[0257] S15: The trust ring module of device A encrypts MK based on PWAUTH11 to generate EMK11.

[0258] S16: The trust ring module of device A sends EMK11 to the trust ring service module.

[0259] S17: The trust ring service module of device A generates parameter PAKE11 based on PWAUTH11.

[0260] S18: The Trust Ring Service Module of Device A sends a ring creation request carrying EMK11 and parameter PAKE11 to the Trust Ring Cloud.

[0261] S19: Trust Ring Cloud responds to the creation request, creates Trust Ring 1 for account 1, and adds device A to Trust Ring 1.

[0262] S20: Trust Ring Cloud returns a successful ring creation message to the Trust Ring Service Module of Device A.

[0263] S15 to S20 reference pairs Figure 10 The detailed explanation of steps S11 to S17 in the trust ring creation process shown is sufficient and will not be repeated here.

[0264] This method of creating a trust ring has the same purpose and effect as the aforementioned method, and relevant details can be found in the previous descriptions, which will not be repeated here. Furthermore, this method eliminates the need for the user to manually enter the device's lock screen code, making it easier for the user to operate.

[0265] The second method of adding a trust ring

[0266] Figures 15 to 18 The method provides a universal approach to adding devices to a trust ring. In practice, for scenarios where users request to join a trust ring under certain high-security services, they do not need to enter the device's lock screen code after requesting to register the trust ring, which reduces the number of user operations and improves the user experience.

[0267] The following example will still be the high-security business, specifically the password safe deposit box business. Figure 23 as well as Figure 24 This method of adding a trust ring is explained.

[0268] Figure 23 This is an example of an interface diagram illustrating the process of adding device B to the trust ring under the password safe service. Figure 23 As shown in Figure (a), after the user turns on the "Password Security Sync" switch, they manually turn on the "Sync to Honor Account" switch. Device B receives the user's operation to turn on the "Sync to Honor Account" switch, and a "Enter other Honor device lock screen password" interface pops up on the screen of Device B (see Figure (a)). Figure 23 (Figure b) shows that the user enters the lock screen code of device A, and the process of joining the trust ring is executed in the background. After joining the trust ring, the following is displayed: Figure 23 The "Sync to Honor Account" switch is turned on in the interface shown in Figure (c).

[0269] For a user interface interaction diagram of enabling the password vault synchronization function, please refer to the relevant interface in Figure 16. Figure 23 and Figure 17 The difference lies in the absence of an interface for entering the device's lock screen code. Since the user has already entered the device B's lock screen code for security verification during the password safe entry process, when the user activates the "Sync to Honor Account" switch under the password safe service to trigger device B's registration trust ring 1, the user does not need to enter device B's lock screen code again. Therefore, in the diagram, device B can directly call the stored device B's lock screen code during the registration trust ring process.

[0270] Figure 24 The following is a schematic diagram illustrating the process of adding a trust ring, as an example. Figure 18 right Figure 24 The process of joining a trust ring, as shown below, will be explained. This process includes the following steps:

[0271] S1: When the account management module of device B modifies the lock screen code, it generates a hash value based on the new lock screen code pw21.

[0272] S2: The account management module of device B sends a hash value to the trust ring service module.

[0273] S3: Device B's trust ring service module generates PWAUTH21 based on the hash value.

[0274] S4: The trust ring service module of device B sends the PWAUTH21 storage command to the trust ring module.

[0275] S5: Device B's trust ring module stores PWAUTH21.

[0276] Compared to Figure 18 The process of adding to the trust ring shown is as follows. Figure 24 Steps S1 to S5 in the process of joining the trust ring shown are new steps. This part describes the process of device B storing its local lock screen code.

[0277] When adding, deleting, or modifying the lock screen code on device B, device B will be triggered to execute S1 to S5. The specific algorithm for generating PWAUTH21 based on the lock screen code can be found in the aforementioned related descriptions, and will not be repeated here.

[0278] The trust ring module of device B stores PWAUTH21. When the trust ring module needs to encrypt MK based on PWAUTH21, it can directly extract it without the user having to enter the lock screen code of device A. PWAUTH21 is then generated based on the lock screen code of device A.

[0279] S6: Login account 1 for the account management module of device B.

[0280] S7: The account management server returns a verification success message to the account management module of device B.

[0281] S8: The account management module of device B sends a registration activation notification to the trust ring service module.

[0282] S9: The trust ring service module of device B detects the registration status of device A.

[0283] S10: When it is detected that the registration status of device B is not registered, the trust ring service module of device B sends a registration status comparison request to the trust ring cloud.

[0284] S11: Trust Ring Cloud returns a second registration status confirmation message to the Trust Ring Service Module of Device B.

[0285] The second registration status confirmation message is used to indicate that trust ring 1 exists under account 1, but device B is not in trust ring 1.

[0286] S6 to S11 reference pairs Figure 18 The detailed explanation of steps S1 to S6 in the first trust ring joining process shown in the figure is sufficient, and will not be repeated here.

[0287] S12: The trust ring service module of device B determines whether the current service is a preset service in the whitelist.

[0288] The preset services in the whitelist can be flexibly set by those skilled in the art, and this application does not impose specific restrictions on them. For example, they can be high-security services such as password safes.

[0289] The common feature of the preset services in the whitelist is that device A has already performed security verification on the user during the process of entering the preset service. Therefore, when performing other requests in the preset service scenario, it is not necessary to enter the lock screen code of device A for security verification again.

[0290] S13: If so, the trust ring service module of device B sends the PWAUTH21 extraction command to the trust ring module.

[0291] S12-S13 replacement Figure 18 In the S7-S9 models, users no longer need to manually enter the lock screen code for device A, reducing the number of operations required and improving the user experience.

[0292] S14: The trust ring service module of device B obtains the list of ring devices in trust ring 1.

[0293] S15: Trust Ring Cloud returns a list of devices to the Trust Ring Service module of device B.

[0294] S16: The trust ring service module of device B displays the lock screen code input interface of device A, receives the lock screen code pw12 of device A input by the user, and generates parameter PAKE12 based on the lock screen code pw12.

[0295] S17: The Trust Ring Service Module of Device B sends parameter PAKE12 to the Trust Ring Cloud.

[0296] S18: After the Trust Ring Cloud successfully authenticates device A based on parameter PAKE12, it returns EMK11 from device A to the Trust Ring Service module of device B.

[0297] S19: The trust ring service module of device B sends EMK11 to the trust ring module.

[0298] S20: The trust ring module of device B decrypts EMK11 to obtain MK, and encrypts MK based on PWAUTH21 to obtain EMK21.

[0299] S21: The trust ring module of device B sends EMK21 to the trust ring service module.

[0300] S22: The trust ring service module of device B generates parameter PAKE21 based on PWAUTH21.

[0301] S23: The Trust Ring Service Module of Device B sends a ring-adding request carrying EMK21 and parameter PAKE21 to the Trust Ring Cloud.

[0302] S24: The Trust Ring Cloud responds to the ring addition request and adds device B to Trust Ring 1.

[0303] S25: Trust Ring Cloud returns a ring addition success message to the Trust Ring Service Module of Device B.

[0304] References to S14 to S25 Figure 18 The detailed explanation of steps S9 to S20 in the process of joining the trust ring shown is sufficient and will not be repeated here.

[0305] The second method of joining a trust ring has the same purpose and effect as the first method described above. Please refer to the relevant explanations above for details, which will not be repeated here. Furthermore, the second method eliminates the need for the user to manually enter their device lock screen code when requesting to join a trust ring in a preset service, making it easier for the user.

[0306] In this embodiment, the electronic device, computer storage medium, computer program product or chip are all used to execute the corresponding method provided above. Therefore, the beneficial effects that can be achieved can be referred to the beneficial effects of the corresponding method provided above, and will not be repeated here.

[0307] Through the above description of the embodiments, those skilled in the art will understand that, for the sake of convenience and brevity, only the division of the above functional modules is used as an example. In actual applications, the above functions can be assigned to different functional modules as needed, that is, the internal structure of the device can be divided into different functional modules to complete all or part of the functions described above.

[0308] In the several embodiments provided in this application, it should be understood that the disclosed apparatus and methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative; for instance, the division of modules or units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another apparatus, or some features may be ignored or not executed. Furthermore, the mutual coupling or direct coupling or communication connection shown or discussed may be through some interfaces; the indirect coupling or communication connection between apparatuses or units may be electrical, mechanical, or other forms.

[0309] The units described as separate components may or may not be physically separate. A component shown as a unit can be one or more physical units; that is, it can be located in one place or distributed in multiple different locations. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0310] Furthermore, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit.

[0311] Any content in the various embodiments of this application, as well as any content in the same embodiment, can be freely combined. Any combination of the above content is within the scope of this application.

[0312] If the integrated unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a readable storage medium. Based on this understanding, the technical solutions of the embodiments of this application, in essence, or the parts that contribute to the prior art, or all or part of the technical solutions, can be embodied in the form of a software product. This software product is stored in a storage medium and includes several instructions to cause a device (which may be a microcontroller, chip, etc.) or processor to execute all or part of the steps of the methods of the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0313] The embodiments of this application have been described above with reference to the accompanying drawings. However, this application is not limited to the specific embodiments described above. The specific embodiments described above are merely illustrative and not restrictive. Those skilled in the art can make many other forms under the guidance of this application without departing from the spirit and scope of the claims, and all of these forms are within the protection scope of this application.

Claims

1. A data protection method, characterized in that, Applied to a first electronic device, including: In response to a first operation input by the user, a first interface is displayed. The first interface includes: a first prompt message, which prompts the user to input a first lock screen code of the first electronic device on the first interface. The first electronic device is logged into a first account. The first operation is used to trigger the activation of the password safe service, which is a preset service in the whitelist. In response to the user's input of the first lock screen code on the first interface, a second interface is displayed; the second interface includes: synchronization controls for the password safe service; In response to the user's first trigger operation on the synchronization control of the password safe service, a second prompt message is displayed on the second interface. The second prompt message indicates that when the first electronic device has enabled the synchronization function of the password safe service corresponding to the first account, the first electronic device has created a first trust ring corresponding to the first account and joined the first trust ring. The first electronic device displays the interface of the first service, which includes a first input box and a second input box. The first input box is used to input the account of the first service, and the second input box is used to input the password of the second service. In response to the user entering the account of the first service in the first input box and the password of the first service in the second input box, a synchronization prompt message is displayed on the interface of the first service. The synchronization prompt message is used to prompt the user whether to allow the account and password of the first service to be synchronized to the second server. In response to the user's input permission, the account and password of the first service are synchronized to the second server, and the second server stores the account and password of the first service. The electronic device that has joined the first trust ring obtains the account and password of the first service from the second server in response to the user's input permission.

2. The method according to claim 1, characterized in that, In response to a user's first trigger operation on the synchronization control of the password safe service, a second prompt message is displayed on the second interface, including: Extract the first derived key stored in the trusted execution environment of the first electronic device, wherein the first derived key is generated based on the first screen lock code; Generate a master key in the trusted execution environment of the first electronic device; The master key is encrypted based on the first derived key to generate the first master key ciphertext of the first electronic device; Generate the first authentication parameters based on the first derived key; A ring creation request is sent to the first server to enable the first server to create a first trust ring corresponding to the first account, and to add the first master key ciphertext and the first authentication parameter to the trust ring data of the first trust ring, wherein the ring creation request carries the first master key ciphertext and the first authentication parameter.

3. The method according to claim 2, characterized in that, The master key is encrypted based on the first derived key to generate the first master key ciphertext of the first electronic device, including: Generate a second derived key based on the first derived key; The master key is encrypted using the second derived key to obtain the first master key ciphertext of the first electronic device.

4. The method according to claim 2, characterized in that, The first authentication parameters generated based on the first derived key include: Generate a first shared value based on the first derived key; The first shared value is encrypted using the HSM public key generated by the first server to obtain the first authentication parameter.

5. The method according to claim 2, characterized in that, The method further includes: In response to the operation of modifying the lock screen code of the first electronic device, a hash value is generated based on the modified new lock screen code; A first derived key is generated based on the hash value; The first derived key is saved to the trusted execution environment of the first electronic device.

6. The method according to claim 2, characterized in that, The method further includes: Upon receiving a registration request, the registration status of the first electronic device is checked; If the first electronic device is not registered, a registration status comparison request is sent to the first server. The registration status comparison request carries the device identifier of the first electronic device and the account identifier of the first account. Receive a first registration status confirmation message returned by the first server, wherein the first registration status confirmation message is used to indicate that there is no trust loop under the first account.

7. The method according to claim 2, characterized in that: The creation request carries the device identifier of the first electronic device and the account identifier of the first account; After the first electronic device is added to the first trust ring, the trust ring data of the first trust ring includes: the account identifier of the first account, the device identifier of the first electronic device, the first authentication parameters, and the correspondence between the first master key ciphertext.

8. The method according to claim 2, characterized in that, The method further includes: A first service key is derived based on the master key, and the first service key is used to encrypt the first service data to obtain the ciphertext of the first service data. The first business data ciphertext is sent to the second server so that the second server can save the first business data ciphertext.

9. The method according to claim 2, characterized in that, The method further includes: Obtain the encrypted second business data from the second server; A first service key is derived based on the master key; The second service data is obtained by decrypting the ciphertext of the second service data using the first service key.

10. A data protection method, characterized in that, Applied to a second electronic device, the method includes: In response to a second user input, a third interface is displayed. The third interface includes a third prompt message, which prompts the user to enter a second lock screen code for the second electronic device on the third interface. The second electronic device is logged into a first account. The second operation is used to enable the password safe service, which is a preset service in the whitelist. In response to the user's input of the second lock screen code on the third interface, a fourth interface is displayed; the fourth interface includes: a synchronization control for the password safe service; In response to the user's second trigger operation on the synchronization control of the password safe service, a fourth prompt message is displayed on the fourth interface. The fourth prompt message is used to prompt the user to enter the first lock screen code of the first electronic device when the synchronization function of the password safe service corresponding to the first account is enabled. The first electronic device is a device in the loop device information of the first trust ring corresponding to the first account obtained from the first server. In response to the user's input of the first lock screen code, a fifth prompt message is displayed on the fourth interface, which indicates that the second electronic device has successfully joined the first trust ring. The second electronic device displays the interface of the first service, which includes: a sixth prompt message, a third input box, and a fourth input box. The sixth prompt message is used to prompt the user whether to allow the use of the account and password information of the first service that have been synchronized by the password vault service. The synchronized account and password of the first service are stored by the second server. In response to the user's input of permission, the synchronized account of the first service is filled in the third input box, and the synchronized password of the first service is filled in the fourth input box.

11. The method according to claim 10, characterized in that, In response to the user's input of the first lock screen code, a fifth prompt message is displayed on the fourth interface, including: Extract the third derived key stored in the trusted execution environment of the second electronic device, the third derived key being generated based on the second lock screen code of the second electronic device; Receive the first lock screen code of the first electronic device input by the user; When the authentication of the first electronic device based on the first lock screen code is successful, the first master key ciphertext of the first electronic device sent by the first server is received. The first master key ciphertext is decrypted based on the first lock screen code to obtain the master key; The master key is encrypted based on the third derived key to generate the second master key ciphertext of the second electronic device, and the second authentication parameters are generated based on the third derived key. A ring-adding request is sent to the first server so that the second master key ciphertext and the second authentication parameters are added to the trust ring data of the first trust ring.

12. The method according to claim 11, characterized in that, After extracting the third derived key stored in the trusted execution environment of the second electronic device, the process also includes: Send an in-loop device information acquisition request to the first server, wherein the in-loop device information acquisition request carries the account identifier of the first account; Receive the in-ring device information of the first trust ring corresponding to the first account returned by the first server, wherein the in-ring device includes the first electronic device; The lock screen code input interface of the first electronic device is displayed.

13. The method according to claim 11, characterized in that, After extracting the third derived key stored in the trusted execution environment of the second electronic device, the process also includes: Send an in-loop device information acquisition request to the first server, wherein the in-loop device information acquisition request carries the account identifier of the first account; Receive the in-ring device information of the first trust ring corresponding to the first account returned by the first server, wherein the in-ring device includes a first electronic device and a third electronic device; In response to the selection of a third electronic device in the in-loop device information, the lock screen code input interface of the third electronic device is displayed.

14. The method according to claim 11, characterized in that, Before the authentication of the first electronic device based on the first lock screen code is successful, and before receiving the first master key ciphertext of the first electronic device sent by the first server, the process further includes: Generate first authentication parameters based on the first lock screen code; The first authentication parameter is sent to the first server so that the first server can authenticate the first electronic device based on the first authentication parameter.

15. The method according to claim 11, characterized in that, The master key is encrypted based on the third derived key to generate the second master key ciphertext for the second electronic device, including: Generate a fourth derived key based on the third derived key; The master key is encrypted using the fourth derived key to obtain the second master key ciphertext of the second electronic device.

16. The method according to claim 11, characterized in that, The generation of the second authentication parameters based on the third derived key includes: A second shared value is generated based on the third derived key; The second shared value is encrypted using the HSM public key generated by the first server to obtain the second authentication parameter.

17. The method according to claim 11, characterized in that, Also includes: Upon receiving a registration request, the registration status of the second electronic device is checked; If the second electronic device is not registered, a registration status comparison request is sent to the first server. The registration status comparison request carries the device identifier of the second electronic device and the account identifier of the first account. The system receives a second registration status confirmation message returned by the first server, wherein the second registration status confirmation message is used to indicate that a first trust ring exists under the first account, but the second electronic device is not on the first trust ring.

18. The method according to claim 11, characterized in that, Also includes: A first service key is derived based on the master key, and the first service key is used to encrypt the first service data to obtain the ciphertext of the first service data. The first business data ciphertext is sent to the second server so that the second server can save the first business data ciphertext.

19. The method according to claim 11, characterized in that, The method further includes: Obtain the encrypted second business data from the second server; A first business key is generated based on the master key; The second service data is obtained by decrypting the ciphertext of the second service data using the first service key.

20. An electronic device, characterized in that, As the first electronic device, it includes: Memory and processor; The processor is coupled to the memory; The memory stores program instructions that, when executed by the processor, cause the first electronic device to perform the following steps: In response to a first operation input by the user, a first interface is displayed. The first interface includes: a first prompt message, which prompts the user to input a first lock screen code of the first electronic device on the first interface. The first electronic device is logged into a first account. The first operation is used to trigger the activation of the password safe service, which is a preset service in the whitelist. In response to the user's input of the first lock screen code on the first interface, a second interface is displayed; the second interface includes: synchronization controls for the password safe service; In response to the user's first trigger operation on the synchronization control of the password safe service, a second prompt message is displayed on the second interface. The second prompt message indicates that when the first electronic device has enabled the synchronization function of the password safe service corresponding to the first account, the first electronic device has created a first trust ring corresponding to the first account and joined the first trust ring. The first electronic device displays the interface of the first service, which includes a first input box and a second input box. The first input box is used to input the account of the first service, and the second input box is used to input the password of the second service. In response to the user entering the account of the first service in the first input box and the password of the first service in the second input box, a synchronization prompt message is displayed on the interface of the first service. The synchronization prompt message is used to prompt the user whether to allow the account and password of the first service to be synchronized to the second server. In response to the user's input permission, the account and password of the first service are synchronized to the second server, and the second server stores the account and password of the first service. The electronic device that has joined the first trust ring obtains the account and password of the first service from the second server in response to the user's input permission.

21. An electronic device, characterized in that, As a second electronic device, it includes: Memory and processor; The processor is coupled to the memory; The memory stores program instructions that, when executed by the processor, cause the second electronic device to perform the following steps: In response to a second user input, a third interface is displayed. The third interface includes a third prompt message, which prompts the user to enter a second lock screen code for the second electronic device on the third interface. The second electronic device is logged into a first account. The second operation is used to enable the password safe service, which is a preset service in the whitelist. In response to the user's input of the second lock screen code on the third interface, a fourth interface is displayed; the fourth interface includes: a synchronization control for the password safe service; In response to the user's second trigger operation on the synchronization control of the password safe service, a fourth prompt message is displayed on the fourth interface. The fourth prompt message is used to prompt the user to enter the first lock screen code of the first electronic device when the synchronization function of the password safe service corresponding to the first account is enabled. The first electronic device is a device in the loop device information of the first trust ring corresponding to the first account obtained from the first server. In response to the user's input of the first lock screen code, a fifth prompt message is displayed on the fourth interface, which indicates that the second electronic device has successfully joined the first trust ring. The second electronic device displays the interface of the first service, which includes: a sixth prompt message, a third input box, and a fourth input box. The sixth prompt message is used to prompt the user whether to allow the use of the account and password information of the first service that have been synchronized by the password vault service. The synchronized account and password of the first service are stored by the second server. In response to the user's input of permission, the synchronized account of the first service is filled in the third input box, and the synchronized password of the first service is filled in the fourth input box.

22. A computer-readable storage medium comprising a computer program, characterized in that, When the computer program is run on an electronic device, it causes the electronic device to perform the data protection method as described in any one of claims 1-19.

Images