CN115021895A - Data protection method and system and electronic equipment - Google Patents

Data protection method and system and electronic equipment Download PDF

Info

Publication number
CN115021895A
CN115021895A CN202111408407.4A CN202111408407A CN115021895A CN 115021895 A CN115021895 A CN 115021895A CN 202111408407 A CN202111408407 A CN 202111408407A CN 115021895 A CN115021895 A CN 115021895A
Authority
CN
China
Prior art keywords
master key
server
ciphertext
updated
electronic device
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Granted
Application number
CN202111408407.4A
Other languages
Chinese (zh)
Other versions
CN115021895B (en
Inventor
窦伟明
丁金岩
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Honor Device Co Ltd
Original Assignee
Honor Device Co Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Honor Device Co Ltd filed Critical Honor Device Co Ltd
Priority to CN202111408407.4A priority Critical patent/CN115021895B/en
Publication of CN115021895A publication Critical patent/CN115021895A/en
Application granted granted Critical
Publication of CN115021895B publication Critical patent/CN115021895B/en
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
    • H04L9/0816—Key establishment, i.e. cryptographic processes or cryptographic protocols whereby a shared secret becomes available to two or more parties, for subsequent use
    • H04L9/0819—Key transport or distribution, i.e. key establishment techniques where one party creates or otherwise obtains a secret value, and securely transfers it to the other(s)
    • H04L9/0822—Key transport or distribution, i.e. key establishment techniques where one party creates or otherwise obtains a secret value, and securely transfers it to the other(s) using key encryption key
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/30—Authentication, i.e. establishing the identity or authorisation of security principals
    • G06F21/45—Structures or tools for the administration of authentication
    • G06F21/46—Structures or tools for the administration of authentication by designing passwords or checking the strength of passwords
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/60—Protecting data
    • G06F21/602—Providing cryptographic facilities or services
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/10—Network architectures or network communication protocols for network security for controlling access to devices or network resources
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/10—Protocols in which an application is distributed across nodes in the network
    • H04L67/1095—Replication or mirroring of data, e.g. scheduling or transport for data synchronisation between network nodes
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3226—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using a predetermined code, e.g. password, passphrase or PIN
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/30—Security of mobile devices; Security of mobile applications
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F2221/00—Indexing scheme relating to security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F2221/21—Indexing scheme relating to G06F21/00 and subgroups addressing additional information or applications relating to security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F2221/2117—User registration

Abstract

The embodiment of the application provides a data protection method, a data protection system and electronic equipment. According to the method, when a master key updating period expires, after receiving a notification from a server, an electronic device changes a local master key, generates a new master key ciphertext and a new authentication parameter, uploads the new master key ciphertext and the new authentication parameter to the server, replaces an old master key ciphertext and an old authentication parameter in the server, periodically changes a master key of a device side and trusts the master key to a trust ring, reduces the risk of cracking the master key, and improves the security of user data of a cloud side based on master key protection. Meanwhile, the managed master key ciphertext is encrypted based on the screen locking code and other user secrets, the cloud side cannot acquire the master key, and the master key can be cleared by self.

Description

Data protection method and system and electronic equipment
Technical Field
The embodiment of the application relates to the field of terminal equipment, in particular to a data protection method, a data protection system and electronic equipment.
Background
Currently, a terminal device can store data of a user in a cloud so that the user can upload and download the data in real time. The user's data typically corresponds to a particular user account. However, the security of user data relies entirely on account security, and the data may be obtained from the cloud side as long as the device is able to authenticate through the account. If any one of the account number and the cloud side server is attacked, user data can be leaked. Moreover, the cloud side server has the possibility of decrypting the user data, and the cloud side cannot self-prove and clear. Thus, the known solutions are less secure and do not provide support for user data protection with higher security requirements.
Disclosure of Invention
The application provides a data protection method, a data protection system and electronic equipment, which are used for periodically changing a master key of an equipment side and trusting to a trust ring, reducing the risk of cracking the master key and improving the security of user data of a cloud side based on master key protection. Meanwhile, the managed master key ciphertext is encrypted based on user secrets such as a screen locking code, and the cloud side cannot acquire the master key and can self-verify the clearness.
In a first aspect, the present application provides a method of data protection. The method is applied to first electronic equipment and comprises the following steps: receiving a master key updating notification sent by a second server, logging in a first account, wherein the first electronic device and the second electronic device are in-loop devices of a first trust loop corresponding to the first account in the first server, trust loop data of the first trust loop comprise a first master key ciphertext and a first authentication parameter of the first electronic device and a second master key ciphertext and a second authentication parameter of the second electronic device, the master key updating notification is sent by the second server under the condition that a preset master key updating period expires, and a master key of the first master key ciphertext and the second master key ciphertext is a first master key. Then, a first screen locking code of the first electronic device input by a user is received, and a first updated derivative key and a first updated authentication parameter are generated based on the first screen locking code. Then, a second master key is generated and stored in a trusted execution environment of the first electronic device, and the second master key is encrypted based on the first updated derivative key to generate a first updated master key ciphertext of the first electronic device. And then, sending a master key updating request to the first server, wherein the master key updating request carries a first updated master key ciphertext and a first updated authentication parameter, so that the first server replaces the first master key ciphertext in the first trust ring with the first updated master key ciphertext, replaces the first authentication parameter with the first updated authentication parameter, and updates the master key version. Then, a master key update success notification sent by the first server is received. Therefore, the master key of the equipment side can be periodically changed and managed to the trust ring, the risk of cracking the master key is reduced, and the user data of the cloud side protected based on the master key is improved. Meanwhile, the managed master key ciphertext is encrypted based on user secrets such as a screen locking code, and the cloud side cannot acquire the master key and can self-verify the clearness.
The screen locking code in the present application may also be replaced with other user information, for example, the user information may be a user birthday, a user name, a birthday of a parent or a friend, a name, and the like. These pieces of information are information unique to the user, and are known only by the user himself, and the information differs from user to user. This user information is easy for the user to remember and is not known by the cloud side. When the master key is encrypted based on the user information, the cloud side cannot decrypt, and thus the cloud side can self-verify the clearness. Except for the user, other people hardly know which user information is used by the user to encrypt the main key, so that the difficulty in cracking the ciphertext of the main key is greatly increased, the safety of the main key is improved, and the safety of user data protected by using the derivative key of the main key can be improved. Meanwhile, when the 2 nd device and the devices after the 2 nd device in the trust ring are registered, the identity of the registered device can be verified based on the user information, interaction with the registered device is not needed, and convenience is provided for the user.
According to the first aspect, after receiving the notification of successful update of the master key sent by the first server, the method further includes: and deriving a first updated service key based on the second master key, deriving a first service key based on the first master key stored in the trusted execution environment of the first electronic device, acquiring all current service data ciphertexts under the first account from the second server, and storing the service data ciphertexts in the second server. And then, decrypting the business data ciphertext by using the first business key to obtain business data, and encrypting the business data by using the first updated business key to obtain an updated business data ciphertext. And then, sending the updated business data ciphertext to the second server so that the second server replaces the business data ciphertext with the updated business data ciphertext. And then, receiving a service data updating success notification sent by the second server. Therefore, after the MK is updated, the user data stored on the cloud side is encrypted again and stored by the updated MK, so that the user data can be synchronized among all devices on the trust ring based on the updated MK, and the safety is improved.
According to the first aspect, after the master key update period expires and before the second server replaces the service data ciphertext with the updated service data ciphertext, the service data ciphertext of the first account stored in the second server is in a frozen state. In the frozen state, the electronic equipment on the trust ring can read the business data ciphertext from the cloud side, but cannot upload the new business data ciphertext to the cloud side for storage. Therefore, after the MK is updated, the business data ciphertext on the cloud side can be adaptively updated, and the electronic equipment which is newly added into the trust ring after being updated can obtain user data by using the updated MK.
According to the first aspect, after receiving the notification of successful update of the service data sent by the second server, the method further includes: deleting a first master key stored in a trusted execution environment of the first electronic device and a traffic key generated based on the first master key. In this way, the updated MK may be used to protect the user data.
According to the first aspect, after receiving the notification of successful update of the service data sent by the second server, the method further includes: and deriving a service key of the first service based on the second master key, encrypting the service data of the first service by using the service key of the first service to obtain a first service data ciphertext, and sending the first service data ciphertext to the second server so that the second server stores the first service data ciphertext. In this way, the electronic device may employ the updated MK to protect the user data uploaded to the cloud side.
According to the first aspect, after receiving the service data update success notification sent by the second server, the method further includes: and acquiring a second service data ciphertext corresponding to the second service from the second server, deriving a service key of the second service based on the second master key, and decrypting the second service data ciphertext by using the service key of the second service to obtain service data of the second service. In this way, the electronic device may decrypt the user data ciphertext downloaded from the cloud side using the updated MK protection.
In a second aspect, the present application provides a data protection method applied to a second electronic device, including; the method comprises the steps of sending a service data synchronization request to a second server, wherein the service data synchronization request carries a master key version, the second electronic equipment and the first electronic equipment are in-loop equipment of a first trust loop corresponding to a first account number in the first server, trust loop data of the first trust loop comprise a first updated master key ciphertext and a first updated authentication parameter of the first electronic equipment, and a second master key ciphertext and a second authentication parameter of the second electronic equipment, a master key in the first updated master key ciphertext is a second master key, a master key in the second master key ciphertext is a first master key, a master key corresponding to the master key version carried in the service data synchronization request is a first master key, and a trusted execution environment of the second electronic equipment stores the first master key. And then, receiving a synchronization failure notification returned by the second server, logging in the first account, wherein the synchronization failure notification is sent by the second server under the condition that the master key version carried in the service data synchronization request is determined to be inconsistent with the master key version in the second server, and the master key corresponding to the master key version in the second server is the second master key. The method comprises the steps of receiving a second screen locking code of second electronic equipment input by a user, receiving a first screen locking code of first electronic equipment input by the user when the second screen locking code passes verification, and receiving a first updated master key ciphertext of the first electronic equipment sent by a first server when the first electronic equipment passes identity verification based on the first screen locking code. And decrypting the first updated master key ciphertext based on the first screen locking code to obtain a second master key, and storing the second master key into a trusted execution environment of the second electronic device. And encrypting the second master key based on the second screen locking code to generate a second updated master key ciphertext of the second electronic device, and generating a second updated authentication parameter based on the second screen locking code. And then, sending a master key updating request to the first server, wherein the master key updating request carries a second updated master key ciphertext and a second updated authentication parameter, so that the first server replaces the second master key ciphertext in the first trust ring with the second updated master key ciphertext and replaces the second authentication parameter with the second updated authentication parameter. And receiving a master key updating success notice sent by the first server. Therefore, when the existing ring device for updating the MK exists in the trust ring, other devices can acquire the updated MK by re-registering in the trust ring, and protect the user data based on the updated MK.
According to the second aspect, after receiving the service data update success notification sent by the second server, the method further includes: deleting a first master key stored in a trusted execution environment of the second electronic device and a traffic key generated based on the first master key. In this way, the updated MK may be used to protect the user data.
According to the second aspect, after receiving the master key update success notification sent by the first server, the method further includes: and deriving a second updated service key based on the second master key, acquiring all current service data ciphertexts under the first account from the second server, storing the service data ciphertexts in the second server, and decrypting the service data ciphertexts by using the second updated service key to obtain service data. In this way, the electronic device may decrypt the user data ciphertext downloaded from the cloud side using the updated MK protection.
According to the second aspect, after receiving the master key update success notification sent by the first server, the method further includes: deriving a service key of the first service based on the second master key, and encrypting the service data of the first service by using the service key of the first service to obtain a first service data ciphertext; and sending the first service data ciphertext to a second server so that the second server stores the first service data ciphertext. In this way, the electronic device may employ the updated MK to protect the user data uploaded to the cloud side.
According to the second aspect, after receiving the master key update success notification sent by the first server, the method further includes: and acquiring a second service data ciphertext corresponding to the second service from the second server, deriving a service key of the second service based on the second master key, and decrypting the second service data ciphertext by using the service key of the second service to obtain service data of the second service. In this way, the electronic device may decrypt the user data ciphertext downloaded from the cloud side using the updated MK protection.
In a third aspect, the present application provides a data protection system, including a first electronic device, a second electronic device, a first server, and a second server, where the first server is configured to send a master key update notification to the second server when a preset master key update period expires. And the second server is used for receiving the master key updating notification sent by the first server and sending the master key updating notification to the first electronic equipment. The first electronic device is used for receiving a master key updating notification sent by the second server, logging in a first account, wherein the first electronic device and the second electronic device are in-loop devices of a first trust loop corresponding to the first account in the first server, trust loop data of the first trust loop comprise a first master key ciphertext and a first authentication parameter of the first electronic device and a second master key ciphertext and a second authentication parameter of the second electronic device, a master key of the first master key ciphertext and the second master key ciphertext is a first master key, receiving a first screen locking code of the first electronic device input by a user, generating a first updating derivative key and a first updating authentication parameter based on the first screen locking code, generating and storing a second master key in a trusted execution environment of the first electronic device, encrypting the second master key based on the first updating derivative key, and generating a first updating master key of the first electronic device, and sending a master key updating request to the first server, wherein the master key updating request carries a first updated master key ciphertext and a first updated authentication parameter. The first server is further configured to receive a master key update request, replace a first master key ciphertext in the first trust ring with a first updated master key ciphertext, replace the first authentication parameter with a first updated authentication parameter, update a master key version, and send a master key update success notification to the first electronic device. The first electronic device is further configured to receive a notification that the master key update is successful, where the notification is sent by the first server. Therefore, the master key of the equipment side can be periodically changed and managed to the trust ring, the risk of cracking the master key is reduced, and the user data of the cloud side protected based on the master key is improved. Meanwhile, the managed master key ciphertext is encrypted based on user secrets such as a screen locking code, and the cloud side cannot acquire the master key and can self-verify the clearness.
In a fourth aspect, the present application provides a data protection system, including a first electronic device, a second electronic device, a first server, and a second server, wherein: the second electronic device is used for sending a service data synchronization request to the second server, the service data synchronization request carries a master key version, the second electronic device and the first electronic device are ring-in-ring devices of a first trust ring corresponding to a first account number in the first server, trust ring data of the first trust ring comprise a first updated master key ciphertext and a first updated authentication parameter of the first electronic device, and a second master key ciphertext and a second authentication parameter of the second electronic device, a master key in the first updated master key ciphertext is a second master key, a master key in the second master key ciphertext is a first master key, a master key corresponding to the master key version carried in the service data synchronization request is a first master key, and the first master key is stored in a trusted execution environment of the second electronic device. And the second server is used for sending a synchronization failure notification to the second electronic device under the condition that the master key version carried in the service data synchronization request is determined to be inconsistent with the master key version in the second server, wherein the master key corresponding to the master key version in the second server is the second master key. The second electronic device is further configured to receive a synchronization failure notification returned by the second server, log in the first account, receive a second screen locking code of the second electronic device input by the user, receive a first screen locking code of the first electronic device input by the user when the second screen locking code passes verification, receive a first updated master key ciphertext of the first electronic device sent by the first server when the identity verification of the first electronic device based on the first screen locking code passes verification, decrypt the first updated master key ciphertext based on the first screen locking code to obtain a second master key, store the second master key in a trusted execution environment of the second electronic device, encrypt the second master key based on the second screen locking code to generate a second updated master key ciphertext of the second electronic device, generate a second update authentication parameter based on the second screen locking code, and send a master key update request to the first server, the master key updating request carries a second updated master key ciphertext and a second updated authentication parameter. And the first server is used for replacing the second master key ciphertext in the first trust ring with a second updated master key ciphertext, replacing the second authentication parameter with a second updated authentication parameter, and sending a master key update success notification to the second electronic device. And the second electronic equipment is also used for receiving a master key updating success notice sent by the first server. Therefore, when the in-loop device with the updated MK is in the trust loop, other devices can acquire the updated MK by re-registering to the trust loop, and protect the user data based on the updated MK.
In a fifth aspect, the present application provides an electronic device, comprising: a memory coupled to the processor, the memory storing program instructions that, when executed by the processor, cause the electronic device to perform the method of any of the first or second aspects.
In a sixth aspect, the present application provides a computer-readable storage medium comprising a computer program which, when run on an electronic device, causes the electronic device to perform the data protection method of any one of the first or second aspects.
Drawings
Fig. 1 is a schematic structural diagram of an exemplary electronic device 100;
fig. 2 is a block diagram illustrating a software structure of the electronic device 100 according to the embodiment of the present application;
FIG. 3 is a diagram illustrating information interaction in creating a trust ring;
FIG. 4 is a diagram illustrating interaction of a device with a cloud side in creating a trust ring;
FIG. 5A is an exemplary interface diagram illustrating entry into the My devices application with a logged in account;
FIG. 5B is an exemplary illustration of an interface to a "my devices" application without a login account;
FIG. 6 is an exemplary interface diagram illustrating the migration of a My devices application from a device A to a password safe synchronization application;
FIG. 7A is a schematic diagram illustrating an exemplary entry process into the "combination safe" interface with device A having a lock screen code set;
FIG. 7B is a schematic diagram illustrating an exemplary entry process into the "combination safe" interface without the lock screen code set by device A;
FIG. 8 is a schematic diagram illustrating the process of opening a "password safe synchronization" switch in the context of creating a trust ring;
FIG. 9 is a diagram illustrating an exemplary process of turning on a "synchronize to Rough Account" switch in the context of creating a trust ring;
FIG. 10 is a schematic diagram illustrating a process for creating a trust ring;
fig. 11 is a schematic diagram illustrating an example of synchronizing a service data ciphertext with an account management server by a device a after a trust ring is created;
FIG. 12 is a schematic diagram illustrating exemplary module interactions for synchronizing business data ciphertexts;
FIG. 13 is a schematic diagram illustrating an interface of a synchronized business data cryptograph to an account management server;
FIG. 14 is a diagram illustrating information interaction during the process of joining a trust ring by device B;
FIG. 15 is an exemplary interface diagram illustrating the migration of a My devices application from device B to a password safe synchronization application;
FIG. 16A is a schematic diagram illustrating the process of entering the "combination safe" interface and opening the "combination safe synchronization" switch when device B has set the lock code;
FIG. 16B is a schematic diagram illustrating a process of entering a "combination safe" interface and actuating a "combination safe synchronization" switch without a lock screen code being set by device B;
fig. 17 is a schematic diagram illustrating a process of turning on a "synchronize to glory account" switch in a scenario where device B joins a trust ring;
FIG. 18 is a flowchart illustrating device B joining a trust ring;
fig. 19 is a diagram illustrating synchronization of a service data cryptogram from an account management server after device B joins a trust ring;
fig. 20 is a schematic diagram illustrating an interface for synchronizing business data ciphertexts from an account management server;
FIG. 21 is an exemplary interaction diagram of a first registered device and a cloud side in an MK update process;
fig. 22 is an exemplary interface diagram illustrating an MK update by the first registered device;
fig. 23 is an exemplary MK update flow diagram of the first registered device;
FIG. 24 is an exemplary illustration of interaction of a non-first registered device with the cloud side during an MK update process;
FIG. 25 is an exemplary interface diagram illustrating an MK update by a device other than the first registered device;
fig. 26 is an exemplary MK update flow diagram of a non-first registered device.
Detailed Description
The technical solutions in the embodiments of the present application will be clearly and completely described below with reference to the drawings in the embodiments of the present application, and it is obvious that the described embodiments are some, but not all, of the embodiments of the present application. All other embodiments obtained by a person of ordinary skill in the art based on the embodiments in the present application without making any creative effort belong to the protection scope of the present application.
The term "and/or" herein is merely an association relationship describing an associated object, and means that there may be three relationships, for example, a and/or B, which may mean: a exists alone, A and B exist simultaneously, and B exists alone.
The terms "first" and "second," and the like in the description and in the claims of the embodiments of the present application, are used for distinguishing between different objects and not for describing a particular order of the objects. For example, the first target object and the second target object, etc. are specific sequences for distinguishing different target objects, rather than describing target objects.
In the embodiments of the present application, the words "exemplary" or "such as" are used herein to mean serving as an example, instance, or illustration. Any embodiment or design described herein as "exemplary" or "e.g.," is not necessarily to be construed as preferred or advantageous over other embodiments or designs. Rather, use of the word "exemplary" or "such as" is intended to present concepts related in a concrete fashion.
In the description of the embodiments of the present application, the meaning of "a plurality" means two or more unless otherwise specified. For example, a plurality of processing units refers to two or more processing units; the plurality of systems refers to two or more systems.
Fig. 1 is a schematic structural diagram of an exemplary electronic device 100. It should be understood that the electronic device 100 shown in fig. 1 is only one example of an electronic device, and that the electronic device 100 may have more or fewer components than shown in the figures, may combine two or more components, or may have a different configuration of components. The various components shown in fig. 1 may be implemented in hardware, software, or a combination of hardware and software, including one or more signal processing and/or application specific integrated circuits.
The electronic device 100 may be a mobile phone, a tablet, or the like.
The electronic device 100 may include: the mobile terminal includes a processor 110, an external memory interface 120, an internal memory 121, a Universal Serial Bus (USB) interface 130, a charging management module 140, a power management module 141, a battery 142, an antenna 1, an antenna 2, a mobile communication module 150, a wireless communication module 160, an audio module 170, a speaker 170A, a receiver 170B, a microphone 170C, an earphone interface 170D, a sensor module 180, a button 190, a motor 191, an indicator 192, a camera 193, a display screen 194, a Subscriber Identity Module (SIM) card interface 195, and the like. The sensor module 180 may include a pressure sensor 180A, a gyroscope sensor 180B, an air pressure sensor 180C, a magnetic sensor 180D, an acceleration sensor 180E, a distance sensor 180F, a proximity light sensor 180G, a fingerprint sensor 180H, a temperature sensor 180J, a touch sensor 180K, an ambient light sensor 180L, a bone conduction sensor 180M, and the like.
The software system of the electronic device 100 may employ a layered architecture, an event-driven architecture, a micro-core architecture, a micro-service architecture, or a cloud architecture. The embodiment of the present application takes an Android system with a layered architecture as an example, and exemplarily illustrates a software structure of the electronic device 100.
The layered architecture of the electronic device 100 divides the software into several layers, each layer having a clear role and division of labor. The layers communicate with each other through a software interface. In some embodiments, the Android system is divided into three layers, an application layer, an application framework layer, and a kernel layer from top to bottom.
The application layer may include a series of application packages.
As shown in fig. 2, the application package may include applications such as sensors (which may also be referred to as desktop and wallpaper), HMS core, trust rings, password safes, and the like. For example, the sensor may monitor the user's sliding, pressing, etc. operation on the screen, and the HMS core provides a collection of cloud opening capabilities on the electronic device side. The trust ring application is used for creating and managing a trust ring for an account, wherein the management of the trust ring includes but is not limited to: adding equipment to the trust ring, deleting equipment from the trust ring, deleting the trust ring, freezing the trust ring, updating the master key ciphertext under the trust ring, and the like. The password safe box is used for managing service data synchronized by a user to an account management server, such as: a login account and a password for a certain service.
The application framework layer provides an Application Programming Interface (API) and a programming framework for the application program of the application layer. The application framework layer includes a number of predefined functions.
As shown in fig. 2, the application framework layer may include a window manager, a view system, an F interface, and a resource manager, etc.
The window manager is used for managing window programs. The window manager can obtain the size of the display screen, judge whether a status bar exists, lock the screen, intercept the screen, send an interface information display instruction to the view system and the like.
The view system includes visual controls such as controls to display text, controls to display pictures, and the like. The view system may be used to build applications. The display interface may be composed of one or more views. For example, the display interface including the short message notification icon may include a view for displaying text and a view for displaying pictures.
The resource manager provides various resources for the application, such as localized strings, icons, pictures, layout files, video files, and the like.
The F interface is an external service interface of the trust ring.
The application layer and the application framework layer run in a virtual machine. And executing java files of the application program layer and the application program framework layer into a binary file by the virtual machine. The virtual machine is used for performing the functions of object life cycle management, stack management, thread management, safety and exception management, garbage collection and the like.
The system library may include a plurality of functional modules. For example: a two-dimensional graphics engine (e.g., SGL), a key asset trust ring CA, a surface manager, etc.
The surface manager is used to manage the display subsystem and provide fusion of 2D and 3D layers for multiple applications. A two-dimensional graphics engine is a drawing engine for two-dimensional images.
The key asset trust ring CA may also be referred to as a trust ring service module, and is mainly used for message pass-through between an upper layer trust ring application and a lower layer key asset trust ring TA.
The kernel layer is a layer between hardware and software. The kernel layer contains at least a display driver, a sensor driver, a W-iFi driver, and a key asset trust ring TA. The display driver is used to drive the display screen 194, the Wi-Fi driver is used to drive the wireless communication module 160, and the sensor driver is used to drive the sensor module 180.
The key asset trust ring TA may also be referred to as a trust ring module, and is configured to implement a core security logic, provide a trusted execution environment, generate a master key in the trusted execution environment, encrypt the master key to generate a master key ciphertext, and the like. For the specific functions of the key asset trust ring CA and the key asset trust ring TA, reference may be made to the related introduction in the following flow description of creating a ring, adding a ring, deleting a ring, preventing a riot, taking a device in the trust ring off line, updating a master key ciphertext, and the like.
It is to be understood that the system framework layer and the components included in the runtime layer shown in fig. 2 do not constitute a specific limitation of the electronic device 100. In other embodiments of the present application, electronic device 100 may include more or fewer components than shown, or some components may be combined, some components may be split, or a different arrangement of components.
When using an electronic device, a user usually needs to memorize a lot of password data, such as a password of a mailbox account, a password of a network disk account, a password of a smart home control right, and the like. When the password data is large, if the user is allowed to independently record the password data of each service, great difficulty is caused to the user to memorize. Therefore, the user wants to upload the password data to the cloud side for storage through the data synchronization function, and the password data is directly acquired from the cloud side during use without being memorized by the user.
However, for such password data, users have different security requirements from general data to be synchronized, for example, data such as pictures, address lists, short messages, and the like. Such password data, once leaked, would cause a great loss to the user. Therefore, users have high security requirements for such cryptographic data. At this time, the disadvantage that the cloud side cannot self-verify the data synchronized to the cloud side is greatly reduced in security, and the high security requirement of the password data cannot be met.
The data protection method enabling the cloud side to be self-certified and self-cleared can provide support for data synchronization of service data with high security requirements, such as password data.
The data protection method of the present application will be described in detail below with reference to the accompanying drawings.
Creating a trust ring
Fig. 3 is a schematic diagram illustrating information interaction in a process of creating a trust ring. Fig. 4 is an exemplary interaction diagram of a device and a cloud side in a process of creating a trust ring. FIG. 10 is a schematic diagram illustrating a process for creating a trust ring.
The process of creating a trust ring according to the embodiment of the present application will be described in detail below with reference to fig. 3, 4 and 10.
In the embodiment of the present application, a glory account of a device a is assumed as an account 1, and a process of creating a trust ring is described by taking the device a to initiate registration to a trust ring cloud for the first time and creating the trust ring 1 of the account 1 as an example. The application that can trigger the creation of the trust ring process may be any application under the glory account, and the example of triggering the creation of the trust ring process through the application of "password safe synchronization" under the glory account is described herein.
Herein, "registration" refers to the process of adding a device to a trust ring. When the first device registers, because the account number does not have a trust ring, the trust ring needs to be created first and then the device is added to the trust ring, and the process of first device registration is referred to as creating the trust ring. The registration of a non-first device requires only adding the device to an existing trust ring, and the process of registering a non-first device is referred to herein as joining a trust ring.
Assume herein that account 1 includes 3 devices under it, Rough V40 (i.e., device A), Rough V30 (denoted as device B), Rough V50 (denoted as device C).
It should be noted that the actions performed by the various clouds herein should be understood as the actions performed by the servers in the respective clouds. For example, the actions performed by the account management server are performed by the account management server, and the actions performed by the trust ring cloud are performed by the trust ring cloud server.
Referring to fig. 3, in the process of creating a trust ring, a device a sends a request for logging in an account 1 to an account management server, and after the account management server passes verification of the request for logging in the account 1, the account management server returns a verification passing message to the device a; after receiving the verification passing message, the device a generates a master key ciphertext EMK11 of the device a and an authentication parameter pawe 11 of the device a, and sends EMK11 and pawe 11 to the trust ring cloud, and after receiving the EMK11 and pawe 11 sent by the device a, the trust ring cloud creates a trust ring 1 for the account 1, and adds the device a to the trust ring 1.
Referring to fig. 10, in an embodiment of the present application, a process of creating a trust ring by a device a may include the following steps:
step S1: device a logs in to account 1.
The example of device a as a glory V40 handset is described herein. It should be understood that device a may be any electronic device that has installed the functionality of creating a trust ring in the present application, and the present application is not limited thereto.
Device a needs to initiate registration with the trust ring cloud to create a trust ring if it has logged in to the account. If the device a does not log in the account, the account needs to be logged in first.
FIG. 5A is an exemplary illustration of an interface to a "my devices" application with a logged on account. Fig. 5B is an exemplary interface diagram illustrating entry into the my devices application without logging in to the account. FIG. 6 is an exemplary interface diagram illustrating the migration of a My devices application from a device A to a password safe synchronization application.
Referring to fig. 5A and 6, in a case where the device a has logged in to account 1 (account 1 is assumed to be 1581991 xxx), the user may click on a "settings" application icon in the main interface of the device a (as shown in fig. 5A (a), and enter a "settings" interface shown in fig. 5A (b)). In the "setup" interface, the user clicks account 1 (i.e., 1581991 xxx), and proceeds to the "account center" interface shown in FIG. 5A (b). In the "account center" interface, the user clicks on "my device" and proceeds to the "my device" interface shown in fig. 6 (b). Find the current device in the My devices interface, i.e., Rough V40, click Rough V40 into the "device info" interface shown in FIG. 6 (c). In the "device information" interface, the user continues to click on the "password safe synchronization" application in the interface, and may enter the "password safe" interface. After a 'password safe box synchronization' switch is opened on a 'password safe box' interface, a 'synchronization to glory account' switch is clicked, and then a process of creating a trust ring is triggered. The process of entering the "safe" interface, opening the "safe synchronization" switch, and opening the "synchronization to glory account" switch will be described later.
It should be noted that if there is a trust ring under account 1, a "trusted device" is displayed under the devices that have been added to the trust ring on the "my devices" interface. The device identified as "trusted device" is a device that has joined the trust ring, i.e., a registered device, see the interface shown in subsequent fig. 15 (b). If there is no trust ring under account 1, for example, on the "my equipment" interface of equipment a shown in fig. 6 (b), none of the 3 glory equipment is a trusted equipment, which means that there is no trust ring under account 1 currently.
Referring to fig. 5A, 5B, and 6, in a case where the device a does not log in to the account 1, after clicking a "setting" application icon in the main interface of the device a (as shown in fig. 5A), the user enters a "setting" interface shown in fig. 5B (a). In the "setup" interface, the user clicks "login for a glory account" and proceeds to the glory account login interface shown in fig. 5B (B). In the glory account login interface, the user enters account 1(1581991 xxx) and a login password (assumed to be key1), and device a sends a request to the account management server to login account 1, with account 1(1581991 xxx) and login password key 1.
Referring to fig. 4, a user may send a request for logging in an account 1 to an account management server through an account management module of an application layer of the device a, so as to log in the account 1.
After the device a successfully logs in the account 1, the process of creating the trust ring is triggered according to the process in the case of the logged-in account, please refer to fig. 5A (c), fig. d, and fig. 6, which are not described herein again.
Step S2: and the account management server returns a verification passing message.
The account management server pre-stores information of the account 1, which includes a login password corresponding to the account 1, and it is assumed that the login password of the account 1 stored by the account management server is key 0. After receiving the request for logging in the account 1 sent by the device a, the account management server verifies the request for logging in the account 1 according to the information of the account 1 locally stored by the account management server. If the password key1 of the login account 1 carried in the request for logging in the account 1 is consistent with the login password key0 of the account 1 locally stored by the account management server, the account management server determines that the login verification of the account 1 is passed. At this time, the account management server returns an authentication pass message to the device a.
If the password key1 of the login account 1 carried in the request for logging in the account 1 is inconsistent with the login password key0 of the account 1 locally stored by the account management server, the account management server determines that the login authentication of the account 1 fails. At this time, the account management server returns a verification failure message to the device a. At this time, the user needs to re-input the account number and the login password through the diagram (B) of fig. 5B.
Referring to fig. 4 and 10, the device a receives a verification pass message or a verification fail message through the account management module.
S3: and sending a registration opening notice.
Referring to fig. 4 and 10, in a case that the account management module of the device a receives a verification-passed message returned by the account management server, the account management module in the device a sends a registration-opening notification to the trust ring service module of the application framework layer. The registration opening notification is used for indicating the trust ring service module to open the registration process.
Here, a process of entering a "password safe" interface and opening a "password safe synchronization" switch by the device a in the process of creating the trust ring will be described.
FIG. 7A is a schematic diagram illustrating the process of entering a "combination safe" interface when device A has set a lock screen code. Referring to fig. 7A, in a case that a user of device a has set a screen locking code (also referred to as a screen locking password) of device a, when the user clicks a "password safe synchronization" application in the interface on a "device information" interface (see fig. 7A), device a pops up a "screen locking password input" interface (see fig. 7 b). If the user enters the screen lock code on the "enter screen lock code" interface and the screen lock code is correct, the screen of device a enters the "password safe" interface (see fig. 7A (c)). At the moment, a 'password safe box synchronization' switch and a 'synchronization to glory account number' switch on the 'password safe box' interface are both in a closed state.
Fig. 7B is a schematic diagram illustrating an exemplary process for entering a "combination safe" interface without device a setting a lock screen code. Referring to fig. 7B, in a case where the user of the device a does not set the screen locking code of the device a, when the user clicks the "password safe synchronization" application in the interface on the "device information" interface (see fig. 7B (a)), the device a pops up the "set digital screen locking code" interface (see fig. 7B (B)). After the user inputs the lock screen code at the interface "set digital lock screen code" shown in fig. 7B (B), the device a pops up an interface for confirming the code "set digital lock screen code" (please refer to fig. 7B (c)). The user re-inputs the lock screen code on the interface shown in fig. 7B (c), and if the re-input lock screen code is identical to the lock screen code input by the user on the interface shown in fig. 7B (B), the screen of the device a enters the "password safe" interface shown in fig. 7B (d), which is the same as the interface shown in fig. 7A (c).
FIG. 8 is a schematic diagram illustrating the process of opening a "password safe synchronization" switch in the context of creating a trust ring. Referring to fig. 8, when the user clicks the "password safe synchronization" switch on the "password safe" interface (see fig. 8 (a)), the device a pops up a reminder interface shown in fig. 8 (b) on the screen, and the reminder interface is used to remind the user whether to approve the password safe synchronization service. When the user clicks the "agree" button on the reminder interface (see fig. 8 (b)), the "password safe synchronization" switch on the "password safe" interface is turned on (see fig. 8 (c)).
When receiving the registration opening notification, the trust ring service module cannot determine whether to open a process of creating a trust ring or a process of joining the trust ring, and needs to determine by detecting a registration state.
S4: the trust ring service module in device a detects the registration status of device a.
The registered state includes both unregistered and registered states. The unregistered state is used for indicating that the device is not currently registered to the trust ring, and the registered state is used for indicating that the device is currently registered to the trust ring.
S5: and when the registration state of the device A is detected to be unregistered, the device A sends a registration state comparison request to the trust ring cloud.
The registration state comparison request is used for indicating to obtain a comparison result between the registration state of the device A detected by the trust ring service module and the registration state of the device A stored in the trust ring cloud.
The registration state comparison request includes a UID (device identifier) of the device a and a UDID (account identifier) of an account to which the device a belongs.
S6: the trust ring cloud returns a first registration status confirmation message to the trust ring service module in device a.
Wherein the first registration status confirmation message is used to indicate that no trust ring exists under account 1.
After receiving a registration state comparison request of the device a, the trust ring cloud compares whether a trust ring exists under the account 1, and compares whether the device a is in the trust ring under the condition that the trust ring exists under the account 1. And when the trust ring does not exist under the account number 1, the trust ring cloud generates a first registration state confirmation message and sends the first registration state confirmation message to the device A.
Based on a first registration state confirmation message returned by the trust ring cloud, the device a determines that the registration is executed to create the trust ring process.
S7: the trust ring service module in device a receives the user-entered screen locking code pw11 for device a.
Here, a process of turning on the "synchronize to glory account" switch in the process of creating the trust ring will be described.
Fig. 9 is a schematic diagram illustrating an exemplary process of turning on a "synchronize to glory account" switch in a scenario of creating a trust ring. Referring to fig. 9, when the user clicks the "synchronize to glory account" switch on the "password safe" interface in which the "password safe synchronization" switch is turned on (see fig. 9 (a)), the device a pops up a "enter lock screen password" interface on the screen (see fig. 9 (b)). If the user inputs the screen locking code of the device A on the screen locking password input interface, the trust ring service module in the device A receives the screen locking code of the device A input by the user. If the screen locking password of the device a input by the user is correct, after the device a executes the process of creating the trust ring, the device a enters a "password safe box" interface in which both a "password safe box synchronization" switch and a "synchronization to glory account" switch are in an open state (see fig. 9 (c)).
It should be noted that the operation of the user clicking the "synchronize to glory account" switch on the interface shown in fig. 9 (a) (see fig. 9 (a)) triggers the device a to execute the steps of the create trust ring program after step S3 and step S3 in fig. 10.
The screen locking code of the device A belongs to the user secret of the device A, and is unknown to the cloud side.
S8: the trust ring service module of device a verifies device a's lock screen code pw 11.
The process of verifying the screen locking code of device a may be: and the equipment A compares the screen locking code input by the user with the screen locking code pre-stored in the equipment A, if the screen locking code is consistent with the screen locking code, the verification is passed, and if the screen locking code is not consistent with the screen locking code, the verification fails.
Here, the trust ring service module verifies the lock screen code of the device a input by the user on the interface shown in fig. 9 (b), and the subsequent step S9 is not executed until the verification is passed. If the verification fails, the device a will exit to the interface shown in fig. 9 (b) and prompt the input screen locking code error at the interface.
S9: the trust ring service module derives pwuat 11 based on the lock screen code of device a.
Assuming that the screen locking code input by the user this time is pw11, the trust ring service module derives PWUATH11 based on pw 11.
Since pw11 belongs to the user secret of device a, the cloud side cannot obtain pw11, and thus the cloud side cannot obtain pwuth 11 derived based on pw 11.
Since PWUATH11 is generated based on the unknown user secret pw11 at the cloud side, PWUATH11 is unknown at the cloud side.
S10: the trust ring service module of device a sends PWAUTH11 to the trust ring module in the trusted execution environment of device a.
Subsequently, the trust ring module generates a master key ciphertext EMK11 and a parameter token 11 based on PWAUTH11, and the generation manners of EMK11 and token 11 are detailed in steps S11 to S14 of fig. 10.
S11: the trust ring module generates MK.
The device A generates MK (main key) through the trust ring module, and the MK is stored in the trusted execution environment of the device A, and even if the device A is attacked, the MK cannot be stolen, so that the safety is high.
S12: the trust ring module encrypts MK based on PWAUTH11, generating EMK 11.
EMK11 is the first master key ciphertext. The trust ring module derives a key KEK11 based on PWAUTH11, and encrypts MK based on the KEK11 to generate EMK 11.
S13: the trust ring module of device a sends the EMK11 to the trust ring service module of device a.
After the trust ring module generates the EMK11, it sends EMK11 to the trust ring service module.
S14: the trust ring service module in device a generates the parameter park 11 based on PWAUTH 11.
S15: the device A sends a ring creation request carrying the EMK11 and the PAKE11 to the trust ring cloud through the trust ring service module.
The device A sends a ring creation request to the trust ring cloud through the trust ring service module, and the PAKE11 parameter registration and EMK11 hosting can be completed through the request.
In order to improve the security of the EMK11, before the trust ring service module sends the EMK11, the trust ring service module performs secondary encryption on the EMK11 based on the public key of the trust ring cloud HSM obtained during login, so as to obtain a two-layer ciphertext of the master key.
S16: the trust ring cloud creates a trust ring 1 for account 1 in response to the ring creation request, and adds device a to trust ring 1.
The trust ring cloud responds to a ring creation request sent by the device A, creates a trust ring 1 for the account 1, when other devices such as a device B and a device C under the account 1 send registration state comparison requests to the trust ring cloud, the trust ring cloud returns a confirmation message that the trust ring 1 exists but the device B and the device C are not in the trust ring, the device B and the device C execute a process of joining the trust ring, and the specific process of joining the trust ring can refer to subsequent related descriptions.
After the creation of the trust ring 1 is completed, the trust ring 1 data managed in the trust ring cloud is as shown in table 1:
TABLE 1
UID UDID Parameter PAKE Master key ciphertext
Account number
1 Device A PAKE11 EMK11
S17: the trust ring cloud returns a ring creation success message to the trust ring service module of the device A.
The trust ring cloud creates a trust ring 1 for the account number 1, and after the device a is added to the trust ring 1, returns a ring creation success message to the device a, and after the device a receives the ring creation success message, opens a switch of "synchronize to glory account number" in the password safe interface, as shown in (c) of fig. 9. After the 'synchronization to a glory account' switch is turned on, a user can sense that the device A has successfully joined the trust ring, and service data in the password safe can be synchronized to the account management server, so that other devices in the trust ring 1 under the account 1 can share the service data.
At this point, the process of creating a trust ring is finished, and device a completes registration.
As can be seen from the process of creating the trust ring, the account-level master key MK is protected based on the user secret, and the cloud side cannot decrypt the managed master key ciphertext because the user secret is unknown to the cloud side, so that the risk of master key leakage is reduced, the safety of the master key MK is improved, and the cloud side can self-prove and clear.
It should be noted that the above-mentioned process should be understood as an illustrative example of the process of creating a trust ring in the present application, and is not intended to limit the present application.
Fig. 11 is a schematic diagram illustrating that device a synchronizes the business data ciphertext to the account management server after creating the trust ring. Fig. 12 is a schematic diagram illustrating exemplary interaction of modules for synchronizing business data ciphertext. Fig. 13 is a schematic diagram illustrating an interface of a synchronized service data ciphertext to an account management server. Referring to fig. 11, 12, and 13, in a case that a trust ring 1 of an account 1 has been created and a device a has been added to the trust ring 1, the device a may encrypt sensitive service data with MK to obtain a service data ciphertext, and upload the service data ciphertext to an account management server.
After the trust ring is created, the process of synchronizing the service data ciphertext to the account management server by the device A is as follows:
referring to fig. 12, a cryptographic safe of an application layer in a device a reads a service data plaintext, then stores the service data plaintext into a service data storage service module of an application framework layer, the service data storage service module sends the service data plaintext to a key management module in a trusted execution environment, the key management module reads a master key MK from a trust ring module, generates a service key dkey according to MK, and encrypts service data by using dkey to obtain a service data ciphertext Edata. And the service data storage service module uploads the service data ciphertext Edata to the account management server through the service data synchronization service module and an account management server synchronization frame of the application program layer.
It should be noted that the service keys dkey corresponding to different services are different, and the device a may generate the service keys of different services according to MK.
For example, referring to fig. 13, when the user uses service 1 on device a, the user needs to input the account and password of service 1, as shown in fig. 13 (a). After the account number and the password of the service 1 are input, the device a pops up information prompting whether to synchronize the account number and the password of the service 1 to the password safe, as shown in fig. 13 (b). If the user agrees, the device A takes the account number and the password of the service 1 as the service data1 of the service 1, and uploads the ciphertext Edata1 of the data1 to the account management server according to the same synchronization process with the service data.
Therefore, in the embodiment of the application, the business data ciphertext in the account management server does not depend on account security completely, but also depends on MK security, and even if the account is stolen, the security of data on the cloud is not affected.
The business data of the user are encrypted based on the high-security master key, and then the business data ciphertext is synchronized to the account management server, so that the risk of leakage of the business data ciphertext is reduced, and the security of data synchronous backup is improved.
Joining a trust ring
On the basis that device a has created trust ring 1 for account 1, device B under account 1 may join trust ring 1 according to the join trust ring procedure in the following embodiment. Before device B joins trust ring 1, only device a, the ring device, is in trust ring 1.
Fig. 14 is a schematic diagram illustrating information interaction during the process of joining the trust ring by the device B. Fig. 18 is a flowchart illustrating the process of device B joining a trust ring.
The process of joining a trust ring according to the embodiment of the present application will be described in detail below with reference to fig. 14 and 18.
Referring to fig. 14, after device a registers as the first device, the process of creating the trust ring is completed, device a has uploaded the master key cryptogram EMK11 of device a, i.e., the first master key cryptogram, and the authentication parameter pave 11 of device a to the trust ring cloud, and thereafter, other devices, e.g., device B, register by joining the trust ring process. In the process that the device B joins the trust ring 1, the device B sends the authentication parameter PAKE12 of the device A in the trust ring 1 to the trust ring cloud, and after confirming that the PAKE12 is consistent with the authentication parameter PAKE11 of the device A stored in the trust ring 1, the trust ring cloud returns the master key ciphertext EMK11 of the device A to the device B. Device B then decrypts MK from EMK11, encrypts MK based on device B's lock screen code, generates device B's master key ciphertext EMK21, i.e., the second master key ciphertext, and device B's authentication parameter pay 21, and sends EMK21 and pay 21 to the trust ring cloud.
Referring to fig. 18, in the embodiment of the present application, the process of joining the trust ring by the device B may include the following steps:
s1: device B logs in to account 1.
Like device a, device B logs in to account 1 by sending a request to the account management server to log in to account 1. For a detailed process of logging in the account 1 by the device B, please refer to the foregoing description of the process of logging in the account 1 by the device a, which is not described herein again.
And S2, the account management server returns a verification passing message to the device B.
For the processing procedure of the request of the account management server for the device B to log in the account 1, reference is made to the processing procedure of the request of the account management server for the device a to log in the account 1, which is not described herein again.
After the device B successfully logs in the account 1, the user may enter the "account center" interface through the flow indicated by the diagrams (B) and (c) in fig. 5A to find the "my device" application.
S3: and sending a registration opening notice.
Referring to fig. 4 and fig. 18, in a case that the account management module of the device B receives a verification-passed message returned by the account management server, the account management module in the device B sends a registration-opening notification to the trust ring service module of the application framework layer. The registration opening notification is used to instruct the trust ring service module of the device B to open the registration process.
Here, a process of entering a "password safe" interface and opening a "password safe synchronization" switch during the process of joining the trust ring by the device B will be described.
FIG. 15 is an exemplary interface diagram illustrating the migration of a My devices application from device B to a password safe synchronization application. Comparing fig. 6, it can be seen that there is a trusted device glory V40 on the my devices interface of device B, device a, during the joining of the trust ring. This indicates that a ring of trust already exists under account 1.
Fig. 16A is a schematic diagram illustrating the process of entering the "safe" interface and opening the "safe sync" switch if device B has set the lock code. Referring to fig. 16A, in the case that the user of the device B has set the lock screen code of the device B, when the user clicks the "password safe synchronization" application in the "device information" interface (see fig. 16A), the device B pops up the "enter lock screen password" interface (see fig. 16A B). If the user enters the lock screen code at the "enter lock screen code" interface and the lock screen code is correct, the screen of device B enters the "password safe" interface (see fig. 16A (c)). At the moment, a 'password safe box synchronization' switch and a 'synchronization to glory account number' switch on the 'password safe box' interface are both in a closed state. Different from the process of creating the trust ring by the device a, when the user clicks the "password safe synchronization" switch on the "password safe" interface shown in the diagram (c) of fig. 16A during the process of joining the trust ring by the device B, the screen of the device B is directly switched to the interface shown in the diagram (d) of fig. 16A, that is, the interface where the "password safe synchronization" switch is turned on and the "synchronization to the glorious account" is not turned on.
FIG. 16B is a schematic diagram illustrating the process of entering the "combination safe" interface and opening the "combination safe synchronization" switch without the lock screen code being set by device B. Referring to fig. 16B, a process of entering the interface of the "password safe" and opening the switch of the "password safe synchronization" when the device B does not set the lock screen code is different from a process of entering the interface of the "password safe" and opening the switch of the "password safe synchronization" when the device B has set the lock screen code shown in fig. 16A in that the lock screen code needs to be set (see fig. 16B (B)) and the lock screen code needs to be confirmed (see fig. 16B (c)) when the device B does not set the lock screen code, and other processes are the same as those in the case of having set the lock screen code, and are not described again here.
S4: the trust ring service module in device B detects the registration status of device B.
For the description of this step, refer to the foregoing description of step S4 in fig. 10, and will not be described herein again.
S5: and when the registration state of the device B is detected to be unregistered, sending a registration state comparison request.
For the description of this step, refer to the foregoing description of step S5 in fig. 10, and will not be described herein again.
S6: and returning a second registration state confirmation message, namely the second registration state confirmation message.
Wherein 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.
After receiving the registration state comparison request of the device B, the trust ring cloud first compares whether a trust ring exists under the account 1. At this point, since the trust ring has created trust ring 1 for account 1 at the time of device a registration, it is confirmed that there is a trust ring under account 1. Then, the trust ring cloud confirms that the device B is not in the trust ring according to the trust ring data of the account 1 shown in table 1, and at this time, the trust ring cloud generates a second registration state confirmation message and sends the second registration state confirmation message to the device B.
And based on a second registration state confirmation message returned by the trust ring cloud, the device B determines that the registration is executed and the trust ring joining process is executed.
S7: the trust ring service module in device B receives the user input of the lock screen code pw21 of device B.
Fig. 17 is a schematic diagram illustrating a process of turning on a "synchronize to glory account" switch in a scenario where device B joins a trust ring. Referring to fig. 17, when the user clicks the "synchronize to glory account" switch on the "password safe" interface in which the "password safe synchronization" switch is turned on (see fig. 17 (a)), the device B pops up a "enter lock screen password" interface on the screen (see fig. 17 (B)). If the user inputs the screen locking code of the device B on the screen locking password input interface, the trust ring service module in the device B receives the screen locking code of the device B input by the user.
S8: the trust ring service module of device B verifies device B's lock screen code pw21, deriving PWAUTH21 based on device B's lock screen code pw 21.
Please refer to the aforementioned process of verifying the screen locking code pw11 of the device a for the process of verifying the screen locking code pw21 of the device B, which is not described herein again.
S9: the trust ring service module of device B obtains the list of devices in trust ring 1.
The trust ring service module of the device B may send an acquisition request of the device list in the trust ring 1 to the trust ring cloud, and the trust ring cloud returns the device list in the trust ring 1 to the trust ring service module of the device B after receiving the acquisition request.
S10: the trust ring cloud returns the list of devices in trust ring 1 to the trust ring service module of device B.
All devices that have currently joined the trust ring 1 are included in the device list in trust ring 1. In the embodiment of the present application, since the device a is a device that creates the trust ring 1, and the device B is a device that first joins the trust ring 1, in a process that the device B joins the trust ring 1, a device list in the trust ring 1 returned by the trust ring cloud includes only one device of the device a.
S11: the trust ring service module of the device B displays a screen locking code input interface of the device A, receives a screen locking code pw12 of the device A input by a user, and generates a parameter PAKE12 based on the screen locking code pw 12.
Referring to fig. 17, if the screen-locking code of device B entered by the user at the interface shown in fig. 17 (B) is correct, the screen of device B pops up the interface "enter other glory device screen-locking code" (see fig. 17 (c)), and the "other glory device" in fig. 17 (c) is glory V40, i.e., device a. If the user inputs the screen locking code pw12 of the device a on the "input other glory device screen locking password" interface, and if the screen locking code pw12 of the device a input by the user is correct, the device B enters a "password safe box synchronization" switch and a "synchronization to glory account" switch which are both in an open state after executing the trust loop adding process (see fig. 17 (d)). After the 'password safe synchronization' switch is turned on, the service data in the password safe can be synchronized to the cloud, and after the 'synchronization to the glowing account' switch is turned on, the service data in the password safe can be synchronized to each device, such as device A, under the trust ring 1. In the actual implementation process, the 'password safe box synchronization' switch and the 'synchronization to glory account number' switch can be combined into one switch.
It should be noted that the operation of the user clicking the "synchronize to glory account" switch on the interface shown in fig. 17 (a) (see fig. 17 (a)) triggers the device a to execute the join trust ring program steps after step S3 and step S3 in fig. 18.
The screen locking code of the device B belongs to the user secret of the device B, and is unknown to the cloud side.
The principle of generating the parameter park 12 is the same as that of generating the parameter park 11, and is not described herein again.
S12: the trust ring service module of device B sends the parameter pawe 12 to the trust ring cloud.
In the process that the device B joins the trust ring 1, the trust ring cloud needs to verify the identity of the device in the trust ring 1, when the verification is passed, the device is allowed to join the trust ring 1, otherwise, the trust ring cloud forbids the device B to join the trust ring 1.
S13: after the authentication of the device a by the trust ring cloud based on the parameter PAKE12 is passed, the EMK11 of the device a is returned to the trust ring service module of the device B.
S14 the trust ring service module of device B sends EMK11 and PWAUTH21 to the trust ring module of device B.
The trust ring module is located in the trusted execution environment of device B, which needs to decrypt EMK11 in the trusted execution environment to fetch MK, and encrypt MK based on PWAUTH21 in the trusted execution environment, resulting in EMK 21.
And S15, decrypting the EMK11 by the trust ring module of the device B to obtain MK, and encrypting the MK based on PWAUTH21 to obtain EMK 21.
The process of decrypting the EMK11 by the device B to obtain the MK comprises the following steps:
s16: the trust ring module of device B sends the EMK21 to the trust ring service module of device B.
S17: device B generates parameter pay 21 based on PWAUTH 21.
Please refer to the related description that the trust ring service module in the device a generates the parameter pay 11 based on PWAUTH11 in the first process of creating the trust ring, which is not described herein again.
S18: the trust ring service module of device B sends a ring add request carrying EMK21 and parameter park 21 to the trust ring cloud.
S19: the trust ring cloud joins device B in trust ring 1 in response to the join ring request.
After device B joins trust ring 1, the trust ring 1 data managed in the trust ring cloud is shown in table 2:
TABLE 2
UID UDID Parameter PAKE Master key ciphertext
Account number
1 Device A PAKE11 EMK11
Account number
1 Device B PAKE21 EMK21
S20: and the trust ring cloud returns a ring adding success message to the trust ring service module of the device B.
After the trust ring cloud adds the device B to the trust ring 1, a ring adding success message is returned to the device B, and after receiving the ring adding success message, the device B opens a switch of synchronizing to a glory account number in a password safe interface, as shown in (d) of fig. 17. After the 'synchronization to a glory account' switch is turned on, a user can sense that the device B has successfully joined the trust ring, and service data in the password safe can be synchronized to the account management server, so that other devices in the trust ring 1 under the account 1 can share the service data.
At this point, the process of joining the trust ring 1 by the device B is completed, and the device B completes registration.
According to the trust ring adding process, in the embodiment of the application, the cloud side sends the escrow master key ciphertext of the registered equipment to the ring adding equipment, the ring adding equipment decrypts the master key ciphertext of the registered equipment based on the user secret of the registered equipment to obtain the master key MK, and the user secret of the registered equipment is unknown to the cloud side and does not need to be forwarded by the cloud side, so that the cloud side can not decrypt the master key ciphertext and can self-prove.
It should be noted that the above-mentioned process should be understood as an illustrative example of the trust ring process added in the present application, and is not intended to limit the present application.
Fig. 19 is a schematic diagram illustrating synchronization of a service data ciphertext from an account management server after device B joins a trust ring. Fig. 20 is a schematic diagram illustrating an interface for synchronizing business data ciphertext from the account management server. Referring to fig. 19, 12 and 20, in the case that the trust ring 1 of the account 1 is created, the device a has been added to the trust ring 1, and the device a has uploaded the service data ciphertext Edata to the account management server, the device B may synchronize the service data ciphertext Edata from the account management server to the device B, and decrypt the service data ciphertext Edata locally with MK to obtain the service data plaintext data.
After the trust ring is added, the process of synchronizing the service data ciphertext in the account management server by the device B is as follows:
referring to fig. 12, a service data synchronization service module in the device B obtains a service data ciphertext Edata from an account management server through an account management server synchronization framework of an application layer. Then, the service data synchronization service module in the device B sends the service data ciphertext Edata to the service data storage service module in the device B, and the service data storage service module sends the service data ciphertext Edata to the key management module in the information execution environment in the device B. And the key management module reads the main key MK from the trust ring module, generates a service key dkey according to the MK, and decrypts the service data ciphertext Edata by using the dkey to obtain the service data plaintext data. And then, the key management module returns the service data plaintext data to the service data storage service module, and the service data storage service module stores the service data plaintext data.
For example, referring to fig. 20, when the user uses service 1 on device B, the user needs to input the account and password of service 1. In the account number and password input interface of the service 1, as shown in fig. 20 (a), the device B pops up information indicating whether to use the account number and password of the service 1 with the synchronized password safe. If the user agrees, device B automatically populates the interface shown in fig. 20 (a) with the account number and password of service 1 with synchronized password safe, as shown in fig. 20 (B). Therefore, the user does not need to independently record the password for each service, and the user experience is improved.
It should be noted that, after the device B is added to the trust ring 1, the service data in the device B may also be encrypted by the master key MK and then synchronized to the account management server, and for this synchronization process, reference is made to the foregoing description of synchronizing the service data to the account management server by the device a, which is not described herein again.
Master key or MK update
After the device a and the device B join the trust ring 1 of the account 1, the service data synchronized by the user is encrypted by a service key derived from MK and uploaded to the cloud side for storage, and the MK is also encrypted to generate a corresponding EMK (master key cryptograph) and store the EMK in the cloud side. In order to prevent leakage caused by continuous attack, the MK may be updated according to a preset period. The MK updating is periodically triggered by the trust ring cloud, each registered device in the trust ring 1 executes an MK updating flow, and the MK updating flow of the first registered device is different from that of the non-first registered device. The following describes the MK update process of the first registered device a and the non-first registered device B in the trust ring 1.
Fig. 21 is an interaction diagram of a first registered device and a cloud side in an MK update process, which is exemplarily shown. Fig. 23 is an exemplary MK update flow diagram of the first registered device.
Next, with reference to fig. 21 and 23, an MK update process of the first registered device according to an embodiment of the present application is described in detail.
Referring to fig. 21, the cloud of the trust ring sends an MK update notification to the account management server, the account management server sends the MK update notification to the first registered device a under the trust ring 1, the device a logs in the account and sends login information, the account management server verifies the login information of the device a, and sends a login information verification passing message to the device a after the verification passes. The device A generates an updated master key MK ', generates EMK13 and PAKE13 based on the lock screen codes pw11 and MK' of the device A, and sends EMK13 and PAKE13 to the trust ring cloud; the trust ring cloud sends an MK update success message to device a. The device A sends a business data old ciphertext acquisition request to the account management server, and the account management server returns the business data old ciphertext; the equipment A obtains the business data by adopting the MK interface business data old ciphertext before updating, the business data is encrypted through the business key derived from MK', a new business data ciphertext is generated and sent to the account management server, and the account management server sends a business number updating success message to the equipment A after updating the business data ciphertext.
Referring to fig. 23, in an embodiment of the present application, an MK update process of the first registered device a may include the following steps:
s1: when the remaining time of the countdown timer is 0, the trust ring cloud triggers MK updating, marks all EMK updating under the trust ring 1, and forbids new equipment from entering the ring.
An MK updating countdown timer is arranged in the trust ring cloud, the starting timing time of the countdown timer is the MK updating period duration, and when the remaining time is 0, an MK updating flow is determined to be triggered. The MK update period may be flexibly set by those skilled in the art, for example, to be one week, 10 days, or 15 days, etc., which is not particularly limited in this application.
Taking two devices, namely a device a and a device B, registered under the trust ring 1 as an example, the data of the trust ring 1 managed in the trust ring cloud is shown in table 2, and all EMKs, namely master key ciphertexts, under the trust ring 1 include: EMK11 and EMK21, which are marked as updated in the trust ring cloud.
The new device is a device which does not register the trust ring 1 under the account 1. Since MK corresponding to the trust ring 1 needs to be updated, when a new device D under the account 1 applies for registering the trust ring 1, the trust ring cloud cannot provide an effective EMK to the new device, and therefore, even if the new device D sends a registration request, the new device D cannot successfully join the trust ring 1.
And the cloud account prompts that the updating is carried out, and when the user clicks, the login process is triggered again.
S2: and the trust ring cloud sends an MK updating notice to the account management server and informs the account management server of updating of the frozen service data.
The MK update notification can carry identification information of the trust ring 1 or information of the account 1, the account management server manages service data synchronized with each device under the trust ring 1, and the service data is stored in the account management server in the form of a service data ciphertext, so that the account management server is notified to freeze updating of the service data of each device under the trust ring 1 in order to avoid that the service data uploaded or acquired by the device in the trust ring after the MK is updated cannot be decrypted successfully.
S3: and the account management server pushes an MK updating notice to all the ring devices.
After each device in the trust ring 1 receives the MK update notification, the update notification is displayed at the account login entry in the setting interface of the device, and the update notification may be a text or an icon.
Fig. 22 is an exemplary interface diagram of the first registered device when performing MK update. After receiving the MK update notification, device a displays a dot icon in the account login field to prompt the user to update, as shown in fig. 22 (a). As shown in fig. 22 (b), when the user clicks the account login entry, the device a is triggered to execute a login process, and the device a opens an account login interface shown in fig. 22 (c).
S4: and the account management server marks the business data ciphertext as a frozen state, and is only readable and not writable.
And after receiving the notification of updating the frozen service data sent by the trust ring cloud, the account management server marks the service data ciphertext in the trust ring 1 as a frozen state. The business data ciphertext in the frozen state can only be read and can not be written, so that the equipment under the trust ring 1 can only request the business data ciphertext under the account 1 from the account management server, and cannot successfully upload the business data ciphertext.
S5: the device a requests the account management server to log in the account 1.
With continued reference to fig. 22, as shown in fig. 22 (c), after the user enters account 1 and a password in the account login interface, the user may click a "login" button, and after receiving an operation of clicking the "login" button, the device a requests the account management server to log in to account 1.
The account 1 and the password in the login interface can also be filled with the account and the password of the last login by default, and the user does not need to manually input the password, and can directly click the login button.
S6: the account management server returns a verification passing message to the device a.
The account management module of the device a interacts with the account management server to execute the login process of the account 1. The login process of the account 1 only needs to refer to the relevant description of the login process of the account 1 when the device a registers the trust ring for the first time, and details are not described here.
S7: the trust ring service module triggers a re-ring creation process, and receives the screen locking code pw11 of the device a input by the user.
Continuing to refer to fig. 22, after the device a successfully logs in the account 1, displaying a screen locking code input interface as shown in fig. 22 (d), inputting a screen locking code of the device a in the screen locking code input interface by a user, and interacting with the trust ring cloud by the device a based on the screen locking code input by the user to recreate the trust ring 1. After device a recreates trust ring 1, it returns to the cloud space first page as shown in diagram (e) of fig. 22.
The specific process of device a recreating the trust ring 1 includes S7 to S13.
S8: the trust ring service module verifies pw11, derives PWAUTH13 and parameter pay 13 based on pw 11.
S9: the trust ring service module sends PWAUTH13 to the trust ring module.
S10: the trust ring module generates a new master key MK'.
The trust ring module can provide a trusted execution environment, a new master key MK 'is generated and stored in the environment, and the stored MK' is high in safety and cannot be stolen illegally.
S11: the trust ring module encrypts MK' based on PWAUTH13, generating EMK 13.
S12: the trust ring module sends the EMK13 to the trust ring service module.
S13: the trust ring service module sends the parameters PAKE13 and EMK13 to the trust ring cloud.
S7-S13 are processes of creating a trust ring for the device a, and the processes may refer to the relevant description of the process of creating a trust ring for the device a in fig. 10, and are not described herein again.
S14: the trust ring cloud replaces the EMK11 for device a with EMK13, replaces the parameter pay 11 for device a with parameter pay 13, and allows new devices to come into the ring.
After device a recreates trust ring 1, the trust ring 1 data managed in the trust ring cloud is as shown in table 3:
TABLE 3
UID UDID Parameter PAKE Master key ciphertext
Account number
1 Device A PAKE13 EMK13
Account number
1 Device B PAKE21 EMK21
At this time, other devices not in the trust ring 1 may join the trust ring 1 according to the join process shown in fig. 18.
S15: and the trust ring cloud returns a master key updating success notice to the trust ring service module.
S16: and the trust ring service module returns a re-registration success notice to the account number management module.
S17: and the trust ring service module informs the service data synchronization service module of re-encrypting the service data by using the service key derived from MK'.
S18: and the business data synchronization service module acquires a full business data ciphertext in the account management server.
And the service data synchronization service module responds to the re-decryption service data notification of the trust ring service module, and the request carries the identification information of the account number 1.
S19: and the account management server returns the full business data ciphertext to the business data synchronization service module.
And after receiving the full service data ciphertext acquisition request, the account management server returns the full service data ciphertext to the service data synchronization service module of the device A.
And the full service data ciphertext is all service data ciphertext synchronized to the account management server by each device under the trust ring 1.
S20: and the business data synchronization service module decrypts the business data ciphertext by using the business key derived from the old master key MK to obtain the business data.
The specific way of deriving the service key from the old master key MK may be as described above, and is not described herein again.
The service data ciphertext is obtained by encrypting the service data based on the old MK derived service key, and in the step, after the old main key MK derived service key is determined, the service key ciphertext can be successfully decrypted to obtain the service data.
The obtained full-service data ciphertext is decrypted by adopting the method to obtain the full-service data.
S21: and the business data synchronization service module updates local business data and encrypts the updated business data based on the MK' derived business key to obtain an updated business data ciphertext.
The specific way of deriving the service key MK 'and encrypting the service data based on the derived service key MK' may be referred to the foregoing description, and will not be described herein again.
S22: and the business data synchronization service module sends the updated business data ciphertext to the account management server.
S23: and the account management server updates the business data ciphertext and marks the business data ciphertext into a unfreezing state.
At this time, all the service data ciphertexts of the trust ring 1 managed in the account management server are service data encrypted based on the MK' derived service key. The business data ciphertext carries MK' version information.
S24: and the account management server sends a service data updating success notification to the service data synchronization service module.
S25: and the service data synchronization service module sends an update completion notification to the trust ring module.
S26: and deleting the MK and the service key derived from the MK by the trust ring module.
Fig. 24 is an exemplary interaction diagram of a non-first registered device and a cloud side in an MK update process. Fig. 26 is an exemplary MK update flow diagram of a non-first registered device.
The following describes in detail an MK update procedure of a non-first registered device according to an embodiment of the present application, with reference to fig. 24 and 26.
Referring to fig. 24, the non-first registration device B sends a service data synchronization request carrying an MK version to the account management server, and the account management server returns request failure information, and at this time, the device B executes an MK update process. The device B logs in the account and sends login information to the account management server, the account management server verifies the login information of the device B, and the login information verification passing message is sent to the device B after the verification is passed. The method comprises the steps that a device B sends a notification for obtaining an updated MK device list to a trust ring cloud, the trust ring cloud returns the updated MK device list including the device A, the device B sends a request for obtaining a new EMK1 and a new PAKE1 of the device A, the trust ring cloud returns the new EMK13 and the new PAKE13 of the device A to the device B, the device B determines an updated master key MK 'based on the new EMK13 and the new PAKE13, generates a new EMK22 and a new PAKE22 based on lock screen codes pw21 and MK' of the device B, and sends an EMK22 and a PAKE22 to the trust ring cloud; the trust ring cloud sends an MK update success message to device B. And the equipment B sends a business data ciphertext acquisition request to the account management server, and the account management server returns the business data ciphertext until the MK updating process of the non-first registered equipment B is finished.
Referring to fig. 26, in the embodiment of the present application, an MK update process of the first registered device a may include the following steps:
s1: and the service data synchronization service module of the device B sends a service data synchronization request carrying the master key version to the account management server.
After the device A finishes MK updating, the device B has no perception, and the device B sends a service data synchronization request to the account management server as usual.
S2: and the account management server judges whether the version of the master key carried in the request is the latest version, and if not, the service data is forbidden to be synchronized.
The version of the master key carried in the service data synchronization request may be: a master key identification, a master key version number, etc.
After the device a completes MK update, the uploaded service data ciphertext carries the latest version of the master key, and when the account management server determines whether the master key version carried in the device B request is the latest version, the two master key versions are compared, so that whether the master key version carried in the request sent by the device B is the latest version can be determined.
S3: and the account management server returns a synchronization failure notice.
Device B directs the user to the account login interface S4.
Fig. 25 is an exemplary interface diagram illustrating MK update performed by a device other than the first registered device. After receiving the synchronization failure notification, the device B service data synchronization service module guides the user to log in the account again, as shown in fig. 25 (a), the device B displays a setting interface including an account login entry, as shown in fig. 25 (B), when the user clicks the account login entry, the device B is triggered to execute a login process, and the device B opens the account login interface shown in fig. 25 (c).
S5: the device B requests the account management server to log in the account 1.
With continued reference to fig. 25, as shown in fig. 25 (c), after the user enters account 1 and the password in the account login interface, the user may click the "login" button, and after receiving the operation of clicking the "login" button, the device B requests the account management server to log in to account 1.
S6: and the account management server returns a verification passing message to the device B.
And S7, the account management module of the device B pulls up the service.
The pulled service enlightenment is used for indicating the trust ring service module to start the registration process and rejoin the trust ring. The flow of device B rejoining the trust ring is shown at S8-S18. The description of the procedure for device B to rejoin the trust ring and the same steps in the process for device B to join the trust ring shown in fig. 18 can be referred to each other, and are not described herein again.
S8, the trust ring service module of device B triggers a re-join procedure to request the device list with updated master keys.
Each device under the trust ring 1 is managed in the trust ring cloud, the master key is updated by part of devices under the trust ring 1, the master key is not updated by part of devices, and the trust ring cloud sends the device list of the updated master key to the device B in the step.
S9, the trust ring cloud returns the information of device a that has updated the master key to the trust ring service module.
In this example, it is described that the trust ring 1 includes a device a and a device B, the first registered device a updates the master key, and the device B does not yet update the master key, so that the trust ring cloud only returns the information of the device a that has updated the master key.
And S10, the trust ring service module pops up the screen locking code verification interface of the equipment B.
With reference to fig. 25, after the device B successfully logs in the account 1, a screen locking code input interface shown in fig. 25 (d) is displayed, the user inputs the screen locking code of the device B in the screen locking code input interface, and the device B verifies the screen locking code of the device B input by the user.
When verification is carried out, comparing the screen locking code of the equipment B input by the user with a screen locking code preset by the user, and determining that the screen locking code of the equipment B passes verification if the screen locking code of the equipment B is the same as the screen locking code of the equipment B; otherwise, it is determined that the screen locking code verification of the device B fails.
And S11, popping up a screen locking code verification interface of the equipment A after the screen locking code PW21 of the equipment B passes verification.
After the screen locking code verification of the device B passes, a screen locking code verification interface of the device a shown in fig. 25 (e) is displayed, and the user inputs the screen locking code of the device a in the screen locking code verification interface of the device a.
In fig. 25, the device a is explained as "glory 40".
It should be noted that, if the updated master key device is not unique, when receiving the device list returned by the trust ring cloud and receiving the "select authentication device" button of the user on diagram (e) of fig. 25, the device B may display the device list for the user to select the subsequent device for ring authentication.
And S12, after the screen locking code PW11 of the device A passes the verification, requesting the trust ring cloud to acquire the parameter PAKE and the master key ciphertext record of the device A.
And the trust ring service module of the equipment B interacts with the trust ring cloud to verify the screen locking code of the equipment A. The specific verification process may refer to the specific description of the process of verifying the screen locking code of the device a when the device B performs looping, which is not described herein again.
S13, the trust ring cloud returns the recorded parameters of device a, PAKE13 and EMK 13.
S14, the trust ring service module of the device B decrypts EMK13 to obtain MK' based on the key derived from the screen locking code PW11 of the device A.
S15, the trust ring service module of the device B generates a parameter PAKE22 based on the screen locking code PW21 of the device B, and generates an EMK22 based on PW21 and MK'.
S16, the trust ring service module of device B sends PAKE22 and EMK22 to the trust ring cloud.
S17, the trust ring cloud replaces EMK21 of device B with EMK22 and parameter PAKE21 of device B with PAKE 22.
At this point, the trust ring cloud rejoins device B in trust ring 1.
After the device B rejoins the trust ring 1, the data of the trust ring 1 managed in the trust ring cloud is shown in table 4:
TABLE 4
UID UDID Parameter PAKE Master key ciphertext
Account number
1 Device A PAKE13 EMK13
Account number
1 Device B PAKE22 EMK22
And S18, the trust ring cloud returns a master key update success notice to the trust ring service module of the device B.
And S19, the trust ring service module of the device B informs the trust ring module to delete the old master key MK and the derived service key.
And S20, deleting the old master key MK and the service key derived from MK by the trust ring module of the device B.
And S21, the trust ring module of the device B informs the account management module that the master key is successfully updated and returns to the cloud space homepage.
With continued reference to fig. 25, after rejoining trust ring 1, device B returns to the cloud space first page as shown in diagram (e) of fig. 25.
S22: and the trust ring module of the device B sends a synchronous service data notification to the service data synchronous service module.
S23: and the service data synchronization service module of the device B requests the account management server to acquire the full service data ciphertext.
And the full service data ciphertext is all service data ciphertext synchronized to the account management server by each device under the trust ring 1.
S24: and the account management server returns the full service data ciphertext.
And the account management server returns a full service data ciphertext to the service data synchronization service module of the equipment B.
S25: and the service data synchronization service module of the equipment B decrypts the service data ciphertext by using the service key derived from MK' to obtain the service data.
And after the device B acquires MK ', the device A derives the service key according to the same derivation mode of MK' derived service key. The device B can successfully decrypt the business key ciphertext to obtain the business data based on the business key derived by MK'.
The above description is only given by taking the device B as an example to describe the master key updating process of the non-first registered device, and the master key updating processes of other non-first registered devices in the trust ring 1 are the same as the master key updating process of the device B, and are not described herein again.
According to the master key updating method, the trust ring cloud periodically triggers the equipment in the trust ring to update the master key, so that the problem that the master key is leaked due to continuous attack is solved, and the safety of data management can be improved. In addition, as can be seen from the above master key updating process, in the embodiment of the present application, the updated MK ' of the device is protected based on the user secret, and since the user secret is unknown to the cloud side, the cloud side cannot decrypt the hosted master key ciphertext, so that the risk of MK ' leakage is reduced, the security of MK ' is improved, and the cloud side can self-prove and clear.
The electronic device, the computer storage medium, the computer program product, or the chip provided in this embodiment are all configured to execute the corresponding method provided above, so that the beneficial effects achieved by the electronic device, the computer storage medium, the computer program product, or the chip may refer to the beneficial effects in the corresponding method provided above, and are not described herein again.
Through the description of the foregoing embodiments, those skilled in the art will understand that, for convenience and simplicity of description, only the division of the functional modules is used for illustration, and in practical applications, the above function distribution may be completed by different functional modules as needed, that is, the internal structure of the device may be divided into different functional modules, so as to complete all or part of the functions described above.
In the several embodiments provided in the present application, it should be understood that the disclosed apparatus and method may be implemented in other manners. For example, the above-described embodiments of the apparatus are merely illustrative, and for example, a module or a unit may be divided into only one logic function, and may be implemented in other ways, for example, a plurality of units or components may be combined or integrated into another apparatus, or some features may be omitted, or not executed. In addition, the shown or discussed mutual coupling or direct coupling or communication connection may be an indirect coupling or communication connection through some interfaces, devices or units, and may be in an electrical, mechanical or other form.
Units described as separate parts may or may not be physically separate, and parts displayed as units may be one physical unit or a plurality of physical units, may be located in one place, or may be distributed to a plurality of different places. Some or all of the units can be selected according to actual needs to achieve the purpose of the solution of the embodiment.
In addition, functional units in the embodiments of the present application may be integrated into one processing unit, or each unit may exist alone physically, or two or more units are integrated into one unit. The integrated unit can be realized in a form of hardware, and can also be realized in a form of a software functional unit.
Any of the various embodiments of the present application, as well as any of the same embodiments, can be freely combined. Any combination of the above is within the scope of the present application.
The integrated unit, if implemented in the form of a software functional unit and sold or used as a stand-alone product, may be stored in a readable storage medium. Based on such understanding, the technical solutions of the embodiments of the present application may be essentially or partially contributed to by the prior art, or all or part of the technical solutions may be embodied in the form of a software product, where the software product is stored in a storage medium and includes several instructions to enable a device (which may be a single chip, a chip, or the like) or a processor (processor) to execute all or part of the steps of the methods of the embodiments of the present application. And the aforementioned storage medium includes: various media capable of storing program codes, such as a usb disk, a removable hard disk, a Read Only Memory (ROM), a Random Access Memory (RAM), a magnetic disk, or an optical disk.
While the present embodiments have been described with reference to the accompanying drawings, it is to be understood that the invention is not limited to the precise embodiments described above, which are meant to be illustrative and not restrictive, and that various changes may be made therein by those skilled in the art without departing from the spirit and scope of the invention as defined by the appended claims.

Claims (15)

1. A data protection method is applied to first electronic equipment and comprises the following steps:
receiving a master key update notification sent by a second server, logging in a first account, wherein the first electronic device and the second electronic device are in-loop devices of a first trust loop corresponding to the first account in the first server, trust loop data of the first trust loop comprise a first master key ciphertext and a first authentication parameter of the first electronic device and a second master key ciphertext and a second authentication parameter of the second electronic device, the master key update notification is sent by the second server under the condition that a preset master key update period expires, and a master key of the first master key ciphertext and a master key of the second master key ciphertext is a first master key;
receiving a first screen locking code of first electronic equipment input by a user, and generating a first updated derivative key and a first updated authentication parameter based on the first screen locking code;
generating and storing a second master key in a trusted execution environment of the first electronic device;
encrypting the second master key based on the first updated derivative key to generate a first updated master key ciphertext of the first electronic device;
sending a master key updating request to the first server, wherein the master key updating request carries the first updated master key ciphertext and the first updated authentication parameter, so that the first server replaces the first master key ciphertext in the first trust ring with the first updated master key ciphertext, replaces the first authentication parameter with the first updated authentication parameter, and updates a master key version;
and receiving a master key updating success notice sent by the first server.
2. The method of claim 1, wherein after receiving the master key update success notification sent by the first server, the method further comprises:
deriving a first updated traffic key based on the second master key, deriving a first traffic key based on the first master key stored in a trusted execution environment of the first electronic device;
acquiring all current business data ciphertexts under the first account from the second server, wherein the business data ciphertexts are stored in the second server;
decrypting the business data ciphertext by using the first business key to obtain business data;
encrypting the service data by using the first updated service key to obtain an updated service data ciphertext;
sending the updated business data ciphertext to the second server, so that the second server replaces the business data ciphertext with the updated business data ciphertext;
and receiving a service data updating success notification sent by the second server.
3. The method according to claim 1, wherein the business data ciphertext of the first account stored in the second server is in a frozen state after the master key update period expires and before the second server replaces the business data ciphertext with the updated business data ciphertext.
4. The method of claim 2, wherein after receiving the notification of successful update of the service data sent by the second server, the method further comprises:
deleting the first master key stored in a trusted execution environment of the first electronic device and a traffic key generated based on the first master key.
5. The method of claim 2, wherein after receiving the notification of successful update of the service data sent by the second server, the method further comprises:
deriving a service key of a first service based on the second master key, and encrypting service data of the first service by using the service key of the first service to obtain a first service data ciphertext;
and sending the first service data ciphertext to a second server so that the second server stores the first service data ciphertext.
6. The method of claim 2, wherein after receiving the notification of successful update of the service data sent by the second server, the method further comprises:
acquiring a second service data ciphertext corresponding to a second service from a second server;
deriving a traffic key for the second traffic based on the second master key;
and decrypting the second service data ciphertext by using the service key of the second service to obtain the service data of the second service.
7. A data protection method is applied to a second electronic device and comprises the following steps:
sending a service data synchronization request to a second server, wherein the service data synchronization request carries a master key version, the second electronic device and the first electronic device are in-loop devices of a first trust loop corresponding to a first account in the first server, trust loop data of the first trust loop comprise a first updated master key ciphertext and a first updated authentication parameter of the first electronic device, and a second master key ciphertext and a second authentication parameter of the second electronic device, a master key in the first updated master key ciphertext is a second master key, a master key in the second master key ciphertext is a first master key, a master key corresponding to the master key version carried in the service data synchronization request is the first master key, and a trusted execution environment of the second electronic device stores the first master key;
receiving a synchronization failure notification returned by the second server, and logging in a first account, wherein the synchronization failure notification is sent by the second server under the condition that the master key version carried in the service data synchronization request is determined to be inconsistent with the master key version in the second server, and the master key corresponding to the master key version in the second server is the second master key;
receiving a second screen locking code of the second electronic equipment input by a user;
when the second screen locking code passes verification, receiving a first screen locking code of the first electronic equipment input by a user;
when the identity verification of the first electronic equipment based on the first screen locking code passes, receiving a first updated master key ciphertext of the first electronic equipment, which is sent by the first server;
decrypting the first updated master key ciphertext based on the first screen locking code to obtain a second master key, and storing the second master key into a trusted execution environment of the second electronic device;
encrypting the second master key based on the second screen locking code to generate a second updated master key ciphertext of the second electronic device, and generating a second updated authentication parameter based on the second screen locking code;
sending a master key updating request to the first server, wherein the master key updating request carries the second updated master key ciphertext and a second updated authentication parameter, so that the first server replaces the second master key ciphertext in the first trust ring with the second updated master key ciphertext and replaces the second authentication parameter with the second updated authentication parameter;
and receiving a master key updating success notice sent by the first server.
8. The method of claim 7, wherein after receiving the notification of successful update of the service data sent by the second server, further comprising:
deleting the first master key stored in a trusted execution environment of the second electronic device and a traffic key generated based on the first master key.
9. The method according to claim 7, further comprising, after receiving the notification of successful update of the master key sent by the first server:
deriving a second updated traffic key based on the second master key;
acquiring all current business data ciphertexts under the first account from the second server, wherein the business data ciphertexts are stored in the second server;
and decrypting the business data ciphertext by using the second updated business key to obtain the business data.
10. The method of claim 7, wherein after receiving the master key update success notification sent by the first server, the method further comprises:
deriving a service key of a first service based on the second master key, and encrypting service data of the first service by using the service key of the first service to obtain a first service data ciphertext;
and sending the first service data ciphertext to a second server so that the second server stores the first service data ciphertext.
11. The method of claim 7, wherein after receiving the notification of successful update of the master key sent by the first server, further comprising:
acquiring a second service data ciphertext corresponding to a second service from a second server;
deriving a traffic key for the second traffic based on the second master key;
and decrypting the second service data ciphertext by using the service key of the second service to obtain the service data of the second service.
12. A data protection system is characterized by comprising a first electronic device, a second electronic device, a first server and a second server, wherein:
a first server to:
sending a master key updating notification to the second server under the condition that a preset master key updating period expires;
a second server to:
receiving a master key updating notification sent by the first server, and sending the master key updating notification to the first electronic equipment;
a first electronic device to:
receiving a master key update notification sent by a second server, logging in a first account, wherein the first electronic device and the second electronic device are in-loop devices of a first trust loop corresponding to the first account in the first server, trust loop data of the first trust loop comprise a first master key ciphertext and a first authentication parameter of the first electronic device, and a second master key ciphertext and a second authentication parameter of the second electronic device, and a master key of the first master key ciphertext and a master key of the second master key ciphertext is a first master key;
receiving a first screen locking code of first electronic equipment input by a user, and generating a first updated derivative key and a first updated authentication parameter based on the first screen locking code;
generating and storing a second master key in a trusted execution environment of the first electronic device;
encrypting the second master key based on the first updated derivative key to generate a first updated master key ciphertext of the first electronic device;
sending a master key updating request to the first server, wherein the master key updating request carries the first updated master key ciphertext and the first updated authentication parameter;
the first server is further configured to:
receiving the master key updating request, replacing the first master key ciphertext in the first trust ring with the first updated master key ciphertext, replacing the first authentication parameter with the first updated authentication parameter, and updating a master key version;
sending a master key update success notification to the first electronic device;
the first electronic device is further configured to:
and receiving a master key updating success notice sent by the first server.
13. A data protection system is characterized by comprising a first electronic device, a second electronic device, a first server and a second server, wherein:
a second electronic device to:
sending a service data synchronization request to a second server, where the service data synchronization request carries a master key version, the second electronic device and the first electronic device are in-loop devices of a first trust loop corresponding to a first account in the first server, trust loop data of the first trust loop includes a first updated master key ciphertext and a first updated authentication parameter of the first electronic device, and a second master key ciphertext and a second authentication parameter of the second electronic device, a master key in the first updated master key ciphertext is a second master key, a master key in the second master key ciphertext is a first master key, a master key corresponding to the master key version carried in the service data synchronization request is the first master key, and a trusted execution environment of the second electronic device stores the first master key;
a second server to:
under the condition that the version of the master key carried in the service data synchronization request is determined to be inconsistent with the version of the master key in the second server, a synchronization failure notification is sent to the second electronic device, and the master key corresponding to the version of the master key in the second server is the second master key;
a second electronic device further to:
receiving a synchronization failure notification returned by the second server, and logging in a first account;
receiving a second screen locking code of the second electronic equipment input by the user;
when the second screen locking code passes verification, receiving a first screen locking code of the first electronic equipment input by a user;
when the identity verification of the first electronic equipment based on the first screen locking code passes, receiving a first updated master key ciphertext of the first electronic equipment, which is sent by the first server;
decrypting the first updated master key ciphertext based on the first screen locking code to obtain a second master key, and storing the second master key into a trusted execution environment of the second electronic device;
encrypting the second master key based on the second screen locking code to generate a second updated master key ciphertext of the second electronic device, and generating a second updated authentication parameter based on the second screen locking code;
sending a master key updating request to the first server, wherein the master key updating request carries the second updated master key ciphertext and the second updated authentication parameter;
a first server to:
replacing the second master key ciphertext in the first trust ring with the second updated master key ciphertext and replacing the second authentication parameter with the second updated authentication parameter;
sending a master key update success notification to the second electronic device;
a second electronic device further to:
and receiving a master key updating success notice sent by the first server.
14. An electronic device, comprising:
a memory and a processor, the memory coupled with the processor;
the memory stores program instructions that, when executed by the processor, cause the electronic device to perform the data protection method of any of claims 1-11.
15. A computer-readable storage medium, comprising a computer program which, when run on an electronic device, causes the electronic device to perform the data protection method of any one of claims 1-11.
CN202111408407.4A 2021-11-19 2021-11-19 Data protection method and system and electronic equipment Active CN115021895B (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN202111408407.4A CN115021895B (en) 2021-11-19 2021-11-19 Data protection method and system and electronic equipment

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN202111408407.4A CN115021895B (en) 2021-11-19 2021-11-19 Data protection method and system and electronic equipment

Publications (2)

Publication Number Publication Date
CN115021895A true CN115021895A (en) 2022-09-06
CN115021895B CN115021895B (en) 2023-04-14

Family

ID=83064803

Family Applications (1)

Application Number Title Priority Date Filing Date
CN202111408407.4A Active CN115021895B (en) 2021-11-19 2021-11-19 Data protection method and system and electronic equipment

Country Status (1)

Country Link
CN (1) CN115021895B (en)

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN109525989A (en) * 2017-09-19 2019-03-26 阿里巴巴集团控股有限公司 Data processing, identity identifying method and system, terminal
WO2021121125A1 (en) * 2019-12-16 2021-06-24 华为技术有限公司 Control method for smart home devices and medium and terminal thereof
CN113609498A (en) * 2021-07-15 2021-11-05 荣耀终端有限公司 Data protection method and electronic equipment

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN109525989A (en) * 2017-09-19 2019-03-26 阿里巴巴集团控股有限公司 Data processing, identity identifying method and system, terminal
WO2019056957A1 (en) * 2017-09-19 2019-03-28 阿里巴巴集团控股有限公司 Data processing and identity authentication methods and systems, and terminal
WO2021121125A1 (en) * 2019-12-16 2021-06-24 华为技术有限公司 Control method for smart home devices and medium and terminal thereof
CN113609498A (en) * 2021-07-15 2021-11-05 荣耀终端有限公司 Data protection method and electronic equipment

Also Published As

Publication number Publication date
CN115021895B (en) 2023-04-14

Similar Documents

Publication Publication Date Title
CN107251035B (en) Account recovery protocol
CN102595404B (en) For storing and executing the method and device of access control clients
US10044706B2 (en) Encryption methods and apparatus
US11831753B2 (en) Secure distributed key management system
KR20140107168A (en) Apparatus and methods for storing electronic access clients
CN108605034A (en) Radio firmware updates
US10686787B2 (en) Use of personal device for convenient and secure authentication
JP2017152880A (en) Authentication system, key processing coordination method, and key processing coordination program
US9443069B1 (en) Verification platform having interface adapted for communication with verification agent
CN106936797A (en) The management method and system of magnetic disk of virtual machine and file encryption key in a kind of cloud
CN111405016B (en) User information acquisition method and related equipment
CN105099686B (en) Data synchronous method, server, terminal and system
CN115037453B (en) Data protection method and system and electronic equipment
CN115037451B (en) Data protection method and electronic equipment
CN115021894B (en) Data protection method, system and electronic equipment
CN115021895B (en) Data protection method and system and electronic equipment
CN114760112B (en) Wireless local area network-oriented intelligent home equipment networking method, system, equipment and storage medium
CN115037450B (en) Data protection method and electronic equipment
CN115037455B (en) Data protection method and system and electronic equipment
CN115037454B (en) Data protection method and electronic equipment
CN115037456B (en) Data protection method, system and electronic equipment
CN115037452B (en) Data protection method, system and electronic equipment
CN115499228A (en) Key protection method, device, equipment and storage medium
CN114490552A (en) Data transmission method and device and electronic equipment

Legal Events

Date Code Title Description
PB01 Publication
PB01 Publication
SE01 Entry into force of request for substantive examination
SE01 Entry into force of request for substantive examination
GR01 Patent grant
GR01 Patent grant