CN115037454B - 数据保护方法及电子设备 - Google Patents

数据保护方法及电子设备 Download PDF

Info

Publication number
CN115037454B
CN115037454B CN202111408374.3A CN202111408374A CN115037454B CN 115037454 B CN115037454 B CN 115037454B CN 202111408374 A CN202111408374 A CN 202111408374A CN 115037454 B CN115037454 B CN 115037454B
Authority
CN
China
Prior art keywords
key
electronic equipment
screen locking
electronic device
master key
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.)
Active
Application number
CN202111408374.3A
Other languages
English (en)
Other versions
CN115037454A (zh
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 CN202310304709.XA priority Critical patent/CN116405202A/zh
Priority to CN202111408374.3A priority patent/CN115037454B/zh
Publication of CN115037454A publication Critical patent/CN115037454A/zh
Application granted granted Critical
Publication of CN115037454B publication Critical patent/CN115037454B/zh
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

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Theoretical Computer Science (AREA)
  • General Engineering & Computer Science (AREA)
  • Computer Hardware Design (AREA)
  • Software Systems (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Computing Systems (AREA)
  • Health & Medical Sciences (AREA)
  • Bioethics (AREA)
  • General Health & Medical Sciences (AREA)
  • Storage Device Security (AREA)

Abstract

本申请实施例提供了一种数据保护方法及电子设备。该方法包括：第二电子设备基于第一电子设备的锁屏码生成认证参数，将认证参数通过云端透传至第一电子设备，第一电子设备基于认证参数对第二电子设备进行身份认证后，向第二电子设备返回封装后的主密钥，第二电子设备解密封装后的主密钥得到主密钥，然后基于主密钥和第二电子设备的锁屏码加环，一方面，用于确认第二电子设备身份的秘密如验证码不事先存储在任何设备上，具有即时性；第二方面，该秘密不由云侧下发到设备上，因此，基于该秘密生成的协商参数加密后的主密钥经云侧透传时，云侧不可解密得到主密钥，云侧可自证清白；3.该秘密对用户记忆友好，不需要额外记忆。

Description

数据保护方法及电子设备
技术领域
本申请实施例涉及终端设备领域，尤其涉及一种数据保护方法及电子设备。
背景技术
目前，终端设备可以将用户的数据保存在云端以便用户实时上传和下载该数据。用户的数据通常对应着某个特定的用户账号。然而，用户数据的安全完全依赖于账号安全，只要设备能够通过账号验证，就可以从云侧获得该数据。如果账号和云侧服务器中的任一个被攻击，用户数据就会发生泄露。并且，云侧服务器也存在解密用户数据的可能，云侧无法自证清白。因而，已知的方案安全性较低，无法为具有更高安全性要求的用户数据保护提供支撑。
发明内容
本申请提供一种数据保护方法及电子设备，电子设备基于对端电子设备的锁屏码生成认证参数，将认证参数通过云端透传至对端电子设备，对端电子设备基于认证参数对第二电子设备进行身份认证后，向电子设备返回封装后的主密钥，电子设备解密封装后的主密钥得到主密钥，然后基于主密钥和本机锁屏码加环，一方面，用于确认电子设备身份的秘密如验证码不事先存储在任何设备上，具有即时性；第二方面，该秘密不由云侧下发到设备上，因此，基于该秘密生成的协商参数加密后的主密钥经云侧透传时，云侧不可解密得到主密钥，云侧可自证清白；3.该秘密对用户记忆友好，不需要额外记忆
第一方面，本申请实施例提供一种数据保护方法，应用于第二电子设备，该方法包括：第二电子设备接收用户输入的第一电子设备显示的验证码，其中，第一电子设备已登录第一账号，第一电子设备为第一账号对应的第一信任环的在环设备；验证码由第一电子设备在接收到允许第二电子设备登录所述第一账号的指令后生成；基于验证码生成认证参数；然后，通过第一服务器将认证参数透传给第一电子设备，以供第一电子设备基于所述认证参数对所述第二电子设备进行身份认证；在第二电子设备的身份认证通过的情况下，获得来自第一电子设备的主密钥；接收用户输入的第二电子设备的第二锁屏码；在第二锁屏码验证通过后，基于第二锁屏码对主密钥进行加密，生成第二电子设备的第二主密钥密文，以及基于第二锁屏码生成第二认证参数；向第一服务器发送加环请求，以使第一服务器将第二主密钥密文和第二认证参数添加至第一信任环的信任环数据中。
该数据保护方法，加环设备依据以已注册设备随机生成的验证码生成认证参数，通过云侧将认证参数透传给设备A即第一电子设备，设备A基于认证参数对设备B进行身份验证，在设备B及第二电子设备的身份验证通过后，设备A生成协商参数基于协商参数对主密钥MK进行双重加密后通过云侧将双重加密后的MK和协商参数透传给设备B，由设备B基于协商参数对双重加密后的MK进行解密得到MK。该加环过程，通过设备A与设备B间验证某种用户秘密(非锁屏码)，达到确认账号以及设备B的身份的目的，一方面，用于确认设备B身份的秘密不事先存储在任何设备上，具有即时性；第二方面，该秘密不由云侧下发到设备上，因此，基于该秘密生成的协商参数加密后的主密钥经云侧透传时，云侧不可解密得到主密钥，云侧可自证清白；3.该秘密对用户记忆友好，不需要额外记忆。
其中，本申请中的锁屏码也可以替换为其他用户信息，例如，用户信息可以是用户生日、用户姓名、父母或朋友的生日、姓名等等。这些信息是用户独有的信息，仅该用户自己知道，且该信息因用户的不同而不同。这些用户信息是用户容易记忆的，并且是云侧所不知道的。当基于用户信息对主密钥加密时，云侧无法解密，因此云侧可自证清白。除了用户自己，别人很难知道用户使用哪一个用户信息来加密主密钥，这样大大增加了主密钥密文的破解难度，提高了主密钥的安全性，进而能够提高使用主密钥的派生密钥保护的用户数据的安全性。同时，在信任环中的第2个设备及第2个以后的设备注册时，可以基于用户信息对已注册设备的身份进行验证，不需要与已注册设备进行交互，为用户提供了便利。
根据第一方面，在基于第二锁屏码对所述主密钥进行加密，生成第二电子设备的第二主密钥密文之前，该方法还包括：第二电子设备将第二锁屏码与本地保存的第二电子设备的锁屏码进行比较；当第二锁屏码与本地保存的第二电子设备的锁屏码一致，确定第二锁屏码验证通过。通过对本设备的锁屏码进行验证，可避免他人恶意触发加环流程。
根据第一方面，或者以上第一方面的任意一种实现方式，第二电子设备基于第二锁屏码对主密钥进行加密，生成第二电子设备的第二主密钥密文，包括：第二电子设备根据第二锁屏码生成第三派生密钥；根据第三派生密钥生成第四派生密钥；根据第四派生密钥对主密钥进行加密，得到第二电子设备的第二主密钥密文。这样，根据锁屏码这样的用户个性化信息对主密钥加密，使得不知道用户个性化信息的云侧无法解密主密钥，保护使用主密钥的派生密钥加密的用户数据，提高用户数据的安全性。
根据第一方面，或者以上第一方面的任意一种实现方式，第二电子设备基于第二锁屏码生成第二认证参数包括：第二电子设备根据第二锁屏码生成第三派生密钥；根据第三派生密钥生成第二共享值；根据第一服务器侧生成的HSM公钥加密第二共享值，得到第二认证参数。这样，根据锁屏码这样的用户个性化信息生成认证参数，使得认证参数无法被伪造，保证认证的安全性。
根据第一方面，或者以上第一方面的任意一种实现方式，该方法还包括：第二电子设备基于主密钥派生第一业务密钥，使用第一业务密钥对第一业务数据进行加密，得到第一业务数据密文；将第一业务数据密文发送给第二服务器，以使第二服务器保存第一业务数据密文。该种基于主密钥派生的业务密钥加密业务数据密文后同步上云的方式，由于主密钥云端不可知，因此上云的业务数据密文云端也不可知，能够确保业务数据的安全性，并且云端可自证清白。
根据第一方面，或者以上第一方面的任意一种实现方式，该方法还包括第二电子设备从第二服务器获取第二业务数据密文；基于主密钥派生第一业务密钥；使用第一业务密钥对第二业务数据密文进行解密，得到第二业务数据。该种从云端获取业务数据密文后在电子设备本地解密的方式，云端与电子设备间传输的业务数据密文即便被截获，由于截获仿无法获知主密钥以及主密钥派生第一业务密钥的规则，因此也无法解密得到的业务数据，能够提升业务数据的安全性。
第二方面，本申请实施例提供一种电子设备，该电子设备可以作为第二电子设备，包括：存储器和处理器；处理器与存储器耦合；存储器存储有程序指令，当程序指令由处理器执行时，使得电子设备执行如下步骤：
第二电子设备接收用户输入的第一电子设备显示的验证码，其中，第一电子设备已登录第一账号，第一电子设备为第一账号对应的第一信任环的在环设备；所述验证码由第一电子设备在接收到允许第二电子设备登录第一账号的指令后生成；基于验证码生成认证参数；通过第一服务器将认证参数透传给第一电子设备，以供第一电子设备基于认证参数对第二电子设备进行身份认证；在第二电子设备的身份认证通过的情况下，获得来自第一电子设备的主密钥；接收用户输入的第二电子设备的第二锁屏码；在第二锁屏码验证通过后，基于第二锁屏码对主密钥进行加密，生成第二电子设备的第二主密钥密文，以及基于第二锁屏码生成第二认证参数；向第一服务器发送加环请求，以使第一服务器将第二主密钥密文和第二认证参数添加至第一信任环的信任环数据中。
根据第二方面，当程序指令由处理器执行时，还使得电子设备执行如下步骤：将第二锁屏码与本地保存的第二电子设备的锁屏码进行比较；当第二锁屏码与本地保存的第二电子设备的锁屏码一致，确定第二锁屏码验证通过。
根据第二方面，或者以上第二方面的任意一种实现方式，当程序指令由处理器执行时，还使得电子设备执行如下步骤：根据第二锁屏码生成第三派生密钥；根据第三派生密钥生成第四派生密钥；根据第四派生密钥对主密钥进行加密，得到所述第二电子设备的第二主密钥密文。
根据第二方面，或者以上第二方面的任意一种实现方式，当程序指令由处理器执行时，还使得电子设备执行如下步骤：根据第二锁屏码生成第三派生密钥；根据第三派生密钥生成第二共享值；根据第一服务器侧生成的HSM公钥加密第二共享值，得到第二认证参数。
根据第二方面，或者以上第二方面的任意一种实现方式，当程序指令由处理器执行时，还使得电子设备执行如下步骤：，基于主密钥派生第一业务密钥，使用第一业务密钥对第一业务数据进行加密，得到第一业务数据密文；将第一业务数据密文发送给第二服务器，以使第二服务器保存第一业务数据密文。
根据第二方面，或者以上第二方面的任意一种实现方式，当程序指令由处理器执行时，还使得电子设备执行如下步骤：从第二服务器获取第二业务数据密文；基于主密钥派生第一业务密钥；使用第一业务密钥对第二业务数据密文进行解密，得到第二业务数据。
第二方面以及第二方面的任意一种实现方式分别与第一方面以及第一方面的任意一种实现方式相对应。第二方面以及第二方面的任意一种实现方式所对应的技术效果可参见上述第一方面以及第一方面的任意一种实现方式所对应的技术效果，此处不再赘述。
第三方面，本申请提供了一种计算机可读介质，用于存储计算机程序，该计算机程序包括用于执行第一方面或第一方面的任意可能的实现方式中的方法的指令。
第四方面，本申请提供了一种计算机程序，该计算机程序包括用于执行第一方面或第一方面的任意可能的实现方式中的方法的指令。
附图说明
图1为示例性示出的电子设备100的结构示意图；
图2为示例性示出的本申请实施例的电子设备100的软件结构框图；
图3为示例性示出的创建信任环过程中的信息交互示意图；
图4为示例性示出的创建信任环过程中设备与云侧的交互示意图；
图5A为示例性示出的已登录账号情况下进入“我的设备”应用的界面示意图；
图5B为示例性示出的未登录账号情况下进入“我的设备”应用的界面示意图；
图6为示例性示出的从设备A中“我的设备”应用进入到“密码保险箱同步”应用的界面示意图；
图7A是示例性示出的设备A已设置锁屏码情况下进入“密码保险箱”界面的过程示意图；
图7B是示例性示出的设备A未设置锁屏码情况下进入“密码保险箱”界面的过程示意图；
图8为示例性示出的创建信任环的场景下开启“密码保险箱同步”开关的过程示意图；
图9为示例性示出的创建信任环的场景下开启“同步到荣耀账号”开关的过程示意图；
图10为示例性示出的创建信任环的流程示意图；
图11为示例性示出的创建信任环后设备A同步业务数据密文到账号管理服务器的示意图；
图12为示例性示出的同步业务数据密文的模块交互示意图；
图13为示例性示出的同步业务数据密文到账号管理服务器的界面示意图；
图14为示例性示出的设备B加入信任环过程中的信息交互示意图；
图15为示例性示出的设备B加入信号过程中，设备B与设备A的交互界面示意图；
图16为示例性示出的设备B加入信任环的流程示意图；
图17为示例性示出的设备B加入信任环后从账号管理服务器同步业务数据密文的示意图；
图18为示例性示出的从账号管理服务器同步业务数据密文的界面示意图。
具体实施方式
下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例是本申请一部分实施例，而不是全部的实施例。基于本申请中的实施例，本领域普通技术人员在没有作出创造性劳动前提下所获得的所有其他实施例，都属于本申请保护的范围。
本文中术语“和/或”，仅仅是一种描述关联对象的关联关系，表示可以存在三种关系，例如，A和/或B，可以表示：单独存在A，同时存在A和B，单独存在B这三种情况。
本申请实施例的说明书和权利要求书中的术语“第一”和“第二”等是用于区别不同的对象，而不是用于描述对象的特定顺序。例如，第一目标对象和第二目标对象等是用于区别不同的目标对象，而不是用于描述目标对象的特定顺序。
在本申请实施例中，“示例性的”或者“例如”等词用于表示作例子、例证或说明。本申请实施例中被描述为“示例性的”或者“例如”的任何实施例或设计方案不应被解释为比其它实施例或设计方案更优选或更具优势。确切而言，使用“示例性的”或者“例如”等词旨在以具体方式呈现相关概念。
在本申请实施例的描述中，除非另有说明，“多个”的含义是指两个或两个以上。例如，多个处理单元是指两个或两个以上的处理单元；多个系统是指两个或两个以上的系统。
图1为示例性示出的电子设备100的结构示意图。应该理解的是，图1所示电子设备100仅是电子设备的一个范例，并且电子设备100可以具有比图中所示的更多的或者更少的部件，可以组合两个或多个的部件，或者可以具有不同的部件配置。图1中所示出的各种部件可以在包括一个或多个信号处理和/或专用集成电路在内的硬件、软件、或硬件和软件的组合中实现。
其中，电子设备100可以为手机、平板等。
电子设备100可以包括：处理器110，外部存储器接口120，内部存储器121，通用串行总线(universal serial bus，USB)接口130，充电管理模块140，电源管理模块141，电池142，天线1，天线2，移动通信模块150，无线通信模块160，音频模块170，扬声器170A，受话器170B，麦克风170C，耳机接口170D，传感器模块180，按键190，马达191，指示器192，摄像头193，显示屏194，以及用户标识模块(subscriber identification module，SIM)卡接口195等。其中传感器模块180可以包括压力传感器180A，陀螺仪传感器180B，气压传感器180C，磁传感器180D，加速度传感器180E，距离传感器180F，接近光传感器180G，指纹传感器180H，温度传感器180J，触摸传感器180K，环境光传感器180L，骨传导传感器180M等。
电子设备100的软件系统可以采用分层架构、事件驱动架构、微核架构、微服务架构，或云架构。本申请实施例以分层架构的Android系统为例，示例性说明电子设备100的软件结构。
电子设备100的分层架构将软件分成若干个层，每一层都有清晰的角色和分工。层与层之间通过软件接口通信。在一些实施例中，将Android系统分为三层，从上至下分别为应用程序层，应用程序框架层，以及内核层。
应用程序层可以包括一系列应用程序包。
如图2所示，应用程序包可以包括传感器(也可以称为桌面和壁纸)、HMS core、信任环、密码保险箱等应用程序。示例性的，传感器可以监测用户对屏幕的滑动、按压等操作，HMS core提供电子设备端、云开放能力的合集。信任环应用用于为账号创建、管理信任环，其中，对信任环的管理包括但不限于：向信任环中添加设备、从信任环中删除设备、删除信任环、冻结信任环、更新信任环下的主密钥密文等。密码保险箱用于管理用户同步至账号管理服务器的业务数据，例如：某业务的登录账号和密码。
应用程序框架层为应用程序层的应用程序提供应用编程接口(applicationprogramming interface，API)和编程框架。应用程序框架层包括一些预先定义的函数。
如图2所示，应用程序框架层可以包括窗口管理器、视图系统、F接口以及资源管理器等。
窗口管理器用于管理窗口程序。窗口管理器可以获取显示屏大小，判断是否有状态栏，锁定屏幕，截取屏幕，向视图系统发送界面信息显示指令等。
视图系统包括可视控件，例如显示文字的控件，显示图片的控件等。视图系统可用于构建应用程序。显示界面可以由一个或多个视图组成的。例如，包括短信通知图标的显示界面，可以包括显示文字的视图以及显示图片的视图。
资源管理器为应用程序提供各种资源，比如本地化字符串，图标，图片，布局文件，视频文件等等。
F接口为信任环的对外服务接口。
应用程序层和应用程序框架层运行在虚拟机中。虚拟机将应用程序层和应用程序框架层的java文件执行为二进制文件。虚拟机用于执行对象生命周期的管理，堆栈管理，线程管理，安全和异常的管理，以及垃圾回收等功能。
系统库可以包括多个功能模块。例如：二维图形引擎(例如：SGL)、关键资产信任环CA、表面管理器等。
表面管理器用于对显示子系统进行管理，并且为多个应用程序提供了2D和3D图层的融合。二维图形引擎是二维图像的绘图引擎。
关键资产信任环CA又可称为信任环服务模块，主要用于上层信任环应用与下层关键资产信任环TA之间的消息透传。
内核层是硬件和软件之间的层。内核层至少包含显示驱动，传感器驱动，W-iFi驱动以及关键资产信任环TA。显示驱动用于驱动显示屏194，Wi-Fi驱动用于驱动无线通信模块160，传感器驱动用于驱动传感器模块180。
关键资产信任环TA又可称为信任环模块，用于实现核心安全逻辑，提供可信任执行环境，在可信任执行环境中生成主密钥、对主密钥进行加密生成主密钥密文等。对于关键资产信任环CA、关键资产信任环TA的具体功能，参照下文中创环、加环、删环、防暴、信任环中设备下线、更新主密钥、更新主密钥密文等流程说明中的相关介绍即可。
可以理解的是，图2示出的系统框架层与运行时层包含的部件，并不构成对电子设备100的具体限定。在本申请另一些实施例中，电子设备100可以包括比图示更多或更少的部件，或者组合某些部件，或者拆分某些部件，或者不同的部件布置。
在使用电子设备时，用户通常需要记忆很多密码数据，例如邮箱账号的密码、网盘账号的密码、智能家居控制权的密码等等。当这类密码数据较多时，如果让用户独立记录每种业务的密码数据，会给用户记忆造成较大的困难。因此，用户希望通过数据同步功能，将这类密码数据上传到云侧进行存储，使用时直接从云侧获取，而不必用户自己记忆。
然而，对于这类密码数据，用户具有与一般的待同步数据，例如，对于图片、通讯录、短信息等数据，不同的安全性要求。这类密码数据一旦泄露，将会给用户造成巨大损失。因此，用户对这类密码数据具有较高的安全性要求。此时，云侧不可自证清白的缺点将使得同步到云侧的数据的安全性大大降低，无法满足这类密码数据的高安全性要求。
本申请提供一种使云侧能够自证清白的数据保护方法，能够为密码数据这类高安全性要求的业务数据的数据同步提供支撑。
下面结合附图，对本申请的数据保护方法进行详细说明。
第一种创建信任环
图3为示例性示出的创建信任环过程中的信息交互示意图。图4为示例性示出的创建信任环过程中设备与云侧的交互示意图。图10为示例性示出的创建信任环的流程示意图。
下面结合图3、图4和图10，对本申请实施例的创建信任环过程进行详细说明。
本申请实施例中，假设设备A的荣耀账号为账号1，并以设备A向信任环云首次发起注册，创建账号1的信任环1为例对创建信任环的过程进行说明。其中，可以触发创建信任环流程的应用可以是荣耀账号下的任一个应用，本文中，以通过荣耀账号下的“密码保险箱同步”应用触发创建信任环流程为例进行说明。
其中，本文中的“注册”是指将设备添加到信任环中的过程。其中，首个设备注册时由于账号下还没有信任环，因此需要先创建信任环再将设备添加到信任环中，本文中将首个设备注册的过程称为创建信任环。非首设备注册时只需要将设备添加到已有的信任环，本文中将非首设备注册的过程称为加入信任环。
本文中假设账号1下包括3个设备，分别为荣耀V40(即设备A)、荣耀V30(记为设备B)、荣耀V50(记为设备C)。
需要说明的是，本文中各种云所执行的动作应当理解为相应云中的服务器所执行的动作。例如，账号管理服务器所执行的动作是由账号管理服务器服务器执行的，信任环云所执行的动作是由信任环云服务器执行的。
请参见图3，在创建信任环过程中，设备A向账号管理服务器发送登录账号1的请求，账号管理服务器对登录账号1的请求验证通过后，向设备A返回验证通过消息；设备A在接收到验证通过消息后，生成设备A的主密钥密文EMK11和设备A的认证参数PAKE11，并将EMK11和PAKE11发送至信任环云，信任环云接收到设备A发送的EMK11和PAKE11后，为账号1创建信任环1，并将设备A添加到信任环1中。
请参见图10，本申请实施例中，设备A创建信任环的过程可以包括如下步骤：
步骤S1：设备A登录账号1。
本文中以设备A为荣耀V40手机为例进行说明。应当理解的是，设备A可以是已安装本申请中创建信任环功能的任意电子设备，本申请不做限制。
设备A需要在已登录账号的情况下，才能向信任环云发起注册，以创建信任环。如果设备A还没有登录账号，需要先登录账号。
图5A为示例性示出的已登录账号情况下进入“我的设备”应用的界面示意图。图5B为示例性示出的未登录账号情况下进入“我的设备”应用的界面示意图。图6为示例性示出的从设备A中“我的设备”应用进入到“密码保险箱同步”应用的界面示意图。
请参见图5A和图6，在设备A已登录账号1(假设账号1为1581991××××)的情况下，用户可以点击设备A主界面中的“设置”应用图标(如图5A的(a)图所示)，进入到图5A的(b)图所示的“设置”界面。在“设置”界面，用户点击账号1(即1581991××××)，进入到图5A的(b)图所示的“账号中心”界面。在“账号中心”界面，用户点击“我的设备”，进入到图6的(b)图所示的“我的设备”界面。在“我的设备”界面中找到当前设备，即荣耀V40，点击荣耀V40进入图6的(c)图所示的“设备信息”界面。在“设备信息”界面，用户继续点击该界面中的“密码保险箱同步”应用，可以进入“密码保险箱”界面。在“密码保险箱”界面，开启“密码保险箱同步”开关后，点击“同步到荣耀账号”开关，即触发创建信任环的流程。其中，进入“密码保险箱”界面、开启“密码保险箱同步”开关和开启“同步到荣耀账号”开关的过程在后文进行说明。
需要说明的是，如果账号1下已有信任环，在“我的设备”界面上已加入到信任环中的设备下面会显示“受信任设备”。被标识为“受信任设备”的设备是已经加入到信任环中的设备，即已注册设备，请参见后续图15的(b)图所示界面。如果账号1下无信任环，例如在图6的(b)图所示的设备A的“我的设备”界面上，3个荣耀设备均不是受信任设备，表示当前的账号1下没有信任环。
请参见图5A、图5B和图6，在设备A未登录账号1的情况下，用户点击设备A主界面中的“设置”应用图标(如图5A的(a)图所示)后，进入到图5B的(a)图所示的“设置”界面。在“设置”界面，用户点击“登录荣耀账号”，进入到图5B的(b)图所示的荣耀账号登录界面。在荣耀账号登录界面，用户输入账号1(1581991××××)和登录密码(假设为key1)，设备A向账号管理服务器发送登录账号1的请求，请求中携带账号1(1581991××××)和登录密码key1。
请参见图4，用户可以通过设备A的应用程序层的账号管理模块，向账号管理服务器发送登录账号1的请求，以登录账号1。
设备A成功登录账号1后，按照前述已登录账号情况下的流程触发创建信任环的流程，请参见图5A的(c)图、(d)图和图6所示，此处不再赘述。
步骤S2：账号管理服务器返回验证通过消息。
账号管理服务器中预先保存账号1的信息，该信息包括账号1对应的登录密码，此处假设账号管理服务器保存的账号1的登录密码为key0。账号管理服务器接收到设备A发送的登录账号1的请求后，根据账号管理服务器本地保存的账号1的信息对登录账号1的请求进行验证。如果登录账号1的请求中携带的登录账号1的密码key1，与账号管理服务器本地保存的账号1的登录密码key0一致，账号管理服务器确定账号1的登录验证通过。此时，账号管理服务器向设备A返回验证通过消息。
如果登录账号1的请求中携带的登录账号1的密码key1，与账号管理服务器本地保存的账号1的登录密码key0不一致，账号管理服务器确定账号1的登录验证失败。此时，账号管理服务器向设备A返回验证失败消息。此时，用户需要通过图5B的(b)图重新输入账号和登录密码。
请参见图4和图10，设备A通过账号管理模块接收验证通过消息或验证失败消息。
S3：发送注册开启通知。
请参见图4和图10，在设备A的账号管理模块接收到账号管理服务器返回的验证通过消息的情况下，设备A中的账号管理模块向应用程序框架层的信任环服务模块发送注册开启通知。注册开启通知用于指示信任环服务模块开启注册流程。
此处，对设备A在创建信任环过程中进入“密码保险箱”界面、开启“密码保险箱同步”开关的过程进行说明。
图7A是示例性示出的设备A已设置锁屏码情况下进入“密码保险箱”界面的过程示意图。请参见图7A，在设备A的用户已设置设备A的锁屏码(也可称为锁屏密码)情况下，当用户在“设备信息”界面点击该界面中的“密码保险箱同步”应用(请参见图7A的(a)图)，设备A弹出“输入锁屏密码”界面(请参见图7A的(b)图)。如果用户在“输入锁屏密码”界面输入锁屏码且锁屏密码正确，设备A的屏幕就进入到“密码保险箱”界面(请参见图7A的(c)图)。此时，“密码保险箱”界面上的“密码保险箱同步”开关和“同步到荣耀账号”开关均处于关闭状态。
图7B是示例性示出的设备A未设置锁屏码情况下进入“密码保险箱”界面的过程示意图。请参见图7B，在设备A的用户未设置设备A的锁屏码情况下，当用户在“设备信息”界面点击该界面中的“密码保险箱同步”应用(请参见图7B的(a)图)，设备A弹出“设置数字锁屏密码”界面(请参见图7B的(b)图)。用户在图7B的(b)图所示的“设置数字锁屏密码”界面输入锁屏码后，设备A弹出“设置数字锁屏密码”的确认密码的界面(请参见图7B的(c)图)。用户在图7B的(c)图所示的界面上再次输入锁屏码，如果该再次输入的锁屏码与用户在图7B的(b)图所示的界面输入的锁屏码一致，设备A的屏幕就进入到图7B的(d)图所示的“密码保险箱”界面，该界面与图7A的(c)图所示界面相同。
图8为示例性示出的创建信任环的场景下开启“密码保险箱同步”开关的过程示意图。请参见图8，当用户点击“密码保险箱”界面上的“密码保险箱同步”开关(请参见图8的(a)图)，设备A屏幕上弹出图8的(b)图所示的提醒界面，该提醒界面用于提醒用户是否同意开启密码保险箱同步服务。当用户点击提醒界面上的“同意”按钮(请参见图8的(b)图)，“密码保险箱”界面上的“密码保险箱同步”开关开启(请参见图8的(c)图)。
信任环服务模块在接收到注册开启通知时，并不能确定是开启创建信任环的流程，还是加入信任环的流程，需要通过检测注册状态来确定。
S4：设备A中的信任环服务模块检测设备A的注册状态。
注册状态包括未注册和已注册两种状态。其中，未注册状态用于指示设备当前未注册到信任环，已注册状态用于指示设备当前已注册到信任环。
S5：当检测到设备A的注册状态为未注册，设备A向信任环云发送注册状态对比请求。
其中，注册状态对比请求用于指示获取信任环服务模块检测到的设备A的注册状态与信任环云中存储的设备A的注册状态的比对结果。
注册状态对比请求中包括设备A的UID(设备标识)和设备A所属的账号的UDID(账号标识)。
S6：信任环云向设备A中的信任环服务模块返回第一注册状态确认消息。
其中，第一注册状态确认消息用于指示账号1下不存在信任环。
信任环云在接收到设备A的注册状态对比请求后，首先比对账号1下是否存在信任环，在账号1下存在信任环的情况下，再比对设备A是否在信任环中。当账号1下不存在信任环，信任环云生成第一注册状态确认消息，并发送给设备A。
基于信任环云返回的第一注册状态确认消息，设备A确定本次注册执行创建信任环流程。
S7：设备A中的信任环服务模块接收用户输入的设备A的锁屏码pw11。
此处，对创建信任环过程中开启“同步到荣耀账号”开关的过程进行说明。
图9为示例性示出的创建信任环的场景下开启“同步到荣耀账号”开关的过程示意图。请参见图9，当用户在“密码保险箱同步”开关已开启的“密码保险箱”界面上点击“同步到荣耀账号”开关(请参见图9的(a)图)，设备A屏幕上弹出“输入锁屏密码”界面(请参见图9的(b)图)。如果用户在“输入锁屏密码”界面输入设备A的锁屏码，设备A中的信任环服务模块就会接收到用户输入的设备A的锁屏码。如果用户输入的设备A的锁屏密码正确，设备A执行完创建信任环流程后就进入到“密码保险箱同步”开关和“同步到荣耀账号”开关均处于开启状态的“密码保险箱”界面(请参见图9的(c)图)。
需要说明的是，用户在图9的(a)图所示的界面上点击“同步到荣耀账号”开关的操作(请参见图9的(a)图)触发设备A执行图10中的步骤S3以及步骤S3之后的创建信任环流程步骤。
设备A的锁屏码属于设备A的用户秘密，对于云侧来说，设备A的锁屏码是未知的。
S8：设备A的信任环服务模块验证设备A的锁屏码pw11。
验证设备A的锁屏码的过程可以为：设备A将用户输入的锁屏码与设备A中预先存储的锁屏码进行比对，如果二者一致，验证通过，否则验证失败。
此处，信任环服务模块对用户在图9的(b)图所示的界面上输入的设备A的锁屏码进行再次验证，验证通过后才能继续执行后续的步骤S9。如果验证失败，设备A将退回到图9的(b)图所示的界面，并在该界面提示输入的锁屏码错误。
S9：信任环服务模块基于设备A的锁屏码派生PWUATH11。
假设用户本次输入的锁屏码为pw11，信任环服务模块基于pw11派生PWUATH11。
由于pw11属于设备A的用户秘密，云侧无法获得pw11，从而云侧无法获得基于pw11派生的PWUATH11。
由于PWUATH11是基于云侧未知的用户秘密pw11生成的，因此对云侧来说PWUATH11是未知的。
S10：设备A的信任环服务模块向设备A的可信执行环境中的信任环模块发送PWAUTH11。
后续，信任环模块基于PWAUTH11生成主密钥密文EMK11和参数PAKE11，EMK11和PAKE11的生成方式详见图10的步骤S11至S14。
S11：信任环模块生成MK。
设备A通过信任环模块生成MK即主密钥，MK保存在设备A的可信执行环境中，即便设备A受攻击MK也不会被窃取，因此安全性很高。
S12：信任环模块基于PWAUTH11对MK进行加密，生成EMK11。
EMK11即第一主密钥密文。信任环模块基于PWAUTH11派生一个秘钥KEK11，再基于该KEK11加密MK，生成EMK11。
S13：设备A的信任环模块向设备A的信任环服务模块发送EMK11。
信任环模块生成EMK11后，将EMK11发送至信任环服务模块，在发送EMK11的同时也将salt_enc11发送至信任环服务模块。
S14：设备A中的信任环服务模块基于PWAUTH11生成参数PAKE11。
S15：设备A通过信任环服务模块向信任环云发送携带EMK11、参数PAKE11的创环请求。
设备A通过信任环服务模块向信任环云发送创环请求，通过该请求即可完成PAKE11参数注册以及EMK11托管。
为提升EMK11的安全性，信任环服务模块在发送EMK11前，可以基于登录时获得的信任环云HSM的公钥对EMK11进行二次加密，得到主密钥的二层密文。
S16：信任环云响应于创环请求，创建账号1的信任环1，并将设备A添加到信任环1中。
信任环云响应于设备A发送的创环请求，为账号1创建信任环1，当账号1下的其他设备如设备B、设备C向信任环云发送注册状态比对请求时，信任环云将返回存在信任环1但设备B、设备C不在信任环中的确认消息，设备B、设备C执行加入信任环的流程，加入信任环的具体流程参照后续相关说明即可。
信任环1创建完成后，信任环云中管理的信任环1数据如表1中所示：
表1
UID UDID 参数PAKE 主密钥密文
账号1 设备A PAKE11 EMK11
S17：信任环云向设备A的信任环服务模块返回创环成功消息。
信任环云为账号1创建信任环1，并将设备A添加到信任环1中后，向设备A返回创环成功消息，设备A接收到创环成功消息后，开启密码保险箱界面中的“同步到荣耀账号”开关，如图9的(c)图所示。“同步到荣耀账号”开关开启后用户可感知设备A已成功加入信任环，密码保险箱中的业务数据可同步至账号管理服务器，以使账号1下的其他在信任环1中的设备能够共享该业务数据。
至此，创建信任环过程结束，设备A完成注册。
设备A完成注册后，设备A的信任环服务模块将设备A的注册状态修改为已注册。
通过创建信任环过程可见，本申请实施例基于用户秘密对账号级主密钥MK进行保护，由于用户秘密对于云侧来说是未知的，因此云侧不能对托管的主密钥密文进行解密，这样，降低了主密钥泄露的风险，提高了主密钥MK的安全性，同时使得云侧能够自证清白。
需要说明的是，上述过程应当理解为本申请中创建信任环过程的示意性举例，并不用于对本申请进行限制。
图11为示例性示出的创建信任环后设备A同步业务数据密文到账号管理服务器的示意图。图12为示例性示出的同步业务数据密文的模块交互示意图。图13为示例性示出的同步业务数据密文到账号管理服务器的界面示意图。请参考图11、图12和图13，在已创建账号1的信任环1，并且设备A已添加到信任环1的情况下，设备A可以用MK对敏感业务数据进行加密，得到业务数据密文，并将业务数据密文上传到账号管理服务器。
其中，创建信任环后设备A同步业务数据密文到账号管理服务器的过程如下：
请参见图12，设备A中应用程序层的密码保险箱读取业务数据明文，然后将业务数据明文存储到应用程序框架层的业务数据存储服务模块中，业务数据存储服务模块将业务数据明文发送给可信执行环境中的密钥管理模块，信任环模块根据MK生成业务密钥dkey，密钥管理模块从信任环模块读取业务密钥dkey，使用dkey对业务数据data进行加密，得到业务数据密文Edata。密钥管理模块将业务数据密文Edata返回给业务数据存储服务模块，业务数据存储服务模块通过业务数据同步服务模块和应用程序层的账号管理服务器同步框架，将业务数据密文Edata上传至账号管理服务器。
需要说明的是，不同的业务对应的业务密钥dkey不同，设备A可以根据MK生成不同业务的业务密钥。
例如，请参见图13，用户在设备A上使用业务1时，需要输入业务1的账号和密码，如图13的(a)图所示。在输入完业务1的账号和密码后，设备A弹出提示是否将业务1的账号和密码同步到密码保险箱的信息，如图13的(b)图所示。如果用户同意，设备A将业务1的账号和密码作为业务1的业务数据data1，按照上述与业务数据data相同的同步过程，将data1的密文Edata1上传至账号管理服务器。
由上可见，本申请实施例中，账号管理服务器中的业务数据密文不完全依赖账号安全，还依赖MK的安全，即使账号失窃，不影响云上数据的安全。
基于高安全性的主密钥对用户的业务数据进行加密，然后同步业务数据密文到账号管理服务器，降低了业务数据密文泄露的风险，提高了数据同步备份的安全性。
加入信任环
在设备A已经创建了账号1的信任环1的基础上，账号1下的设备B可以根据如下实施例中的加入信任环流程加入到信任环1中。以设备B加入信任环1之前，信任环1中只有设备A这一个在环设备为例进行说明。
本申请实施例提供的加入信任环的方式中，设备B加入信任环时，需要一台在信任环1中，且在线、在用户身边的设备A，由设备A生成一个随机的验证码，用户在设备B上输入该验证码，通过密码学算法产生一系列认证参数，再通过信任环云把认证参数发送到设备A，由设备A对设备B发送的认证参数做校验，校验通过后设备A加密主秘钥MK得到EMK12，将EMK12和协商参数通过信任环云发送到设备B上，设备B用设备A发送过来的协商协商出秘钥解密EMK12得到MK，基于得到的MK加入信任环1中。
图14为示例性示出的设备B加入信任环过程中的信息交互示意图。图16为示例性示出的设备B加入信任环的流程示意图。
下面结合图14和图16，对本申请实施例的加入信任环过程进行详细说明。
请参见图14，在设备A作为首设备注册后，创建信任环过程完成，设备A已将设备A的主密钥密文EMK11和设备A的认证参数PAKE11上传至信任环云，此后，其他设备，例如设备B通过加入信任环流程进行注册。在设备B加入信任环1的过程中，设备B登录账号，向账号管理服务器发送登录信息，账号管理服务器对设备B的登录账号进行验证，验证通过后向信任环云发送登录信息验证通过通知。信任环云向在已在环设备A发送准备校验的通知。设备A随机生成验证码，用户在设备B上输入设备A生成的验证码，设备B向信任环云发送基于验证码生成的认证参数，信任环云透传认证参数，设备A对认证参数做校验，校验通过后生成协商参数，并基于协商参数对MK进行封装生成EMK12，通过信任环云透传协商参数和EMK12至设备B，设备B基于协商参数协商出会话秘钥，基于会话秘钥解密EMK12得到MK，并基于设备B的锁屏码加密MK，生成设备B的主密钥密文EMK21，和设备B的认证参数PAKE21，并将EMK21和PAKE21发送至信任环云。
请参见图16，本申请实施例中，设备B加入信任环过程可以包括如下步骤：
S1：设备B登录账号1。
同设备A一样，设备B通过向账号管理服务器发送登录账号1的请求来登录账号1。设备B登录账号1的详细过程请参见前述设备A登录账号1的过程说明，此处不再赘述。
S2:账号管理服务器向设备B返回验证通过消息。
账号管理服务器对设备B登录账号1的请求的处理过程请参见前述账号管理服务器对设备A登录账号1的请求的处理过程，此处不再赘述。
S3：账号管理服务器向信任环云发送登录信息验证通过消息。
账号管理服务器对设备B的登录信息验证通过后，向信任环云发送登录信息验证通过消息，信任环云接收到设备B的登录信息验证通过消息后，确定账号1下已加入信任环1中的各设备，向各在信任环1中的设备发送准备校验通知，同时向设备B返回验证通过消息。
S4：拉起服务，发送等待验证码消息。
图15的(a)图所示，用户在设备B上输入账号1“1581991xxxx”以及登录密码请求登录荣耀账号即账号1，设备B的账号管理模块接收到账号管理服务器返回验证通过消息后，发送等待验证码消息。
S5：信任环云通知在环设备A准备校验。
信任环云确定所管理的信任环1下的全部设备，通知信任环1下的全部设备准备校验。由于设备A为信任环1中唯一在环设备，因此仅向设备A发送准备校验通知。
需要说明的是，若信任环1中还包括除设备A外的其它设备如设备C、设备D，则向设备A、设备C以及设备D分别发送准备校验通知。
S6：设备B弹出验证码输入界面。
设备B的账号管理模块发送等待验证码消息后，在设备B弹出验证码输入界面，设备B的验证码输入界面如图15的(d)图所示，验证码输入界面中包括安全验证提示框，安全验证提示框中包括：验证码输入区域、取消按钮以及确定按钮。
S7：设备A弹出允许登录的请求弹窗。
在信任环1中的设备A接收到准备校验通知后，弹出允许登录的请求弹窗，显示有允许登录的请求弹窗界面示意图如图15的(b)图所示，允许登录的请求弹窗中包括“是否允许……在……上登录的”询问信息、不允许按钮以及允许按钮。
S8：设备A接收到用户允许登录指令后，生成验证码并显示。
用户点击“允许”按钮，设备A响应于用户点击“允许”按钮的操作，确定接收到用户允许登录指令，随机生成一个验证码，设备A取消显示允许登录的请求弹窗，在界面中显示荣耀账号安全验证码提示框，如图15的(c)图所示，荣耀账号安全验证码提示框中包括设备A随机生成的验证码以及“知道了”按钮。用户查看完设备A显示的安全验证码后，可以点击“知道了”按钮触发设备A取消显示荣耀账号安全验证码提示框。
荣耀账号安全验证码提示框并不局限于在用户点击“知道了”按钮之后取消显示，还可以在显示预设时长后自动消失；或者在用户点击荣耀账号安全验证码提示框外的区域后自动消失，本申请中对此不做具体限制。
预设时长可以设置为3秒、2秒或者5秒等，预设时长的数值可由本领域技术人员灵活设置，在此不做具体限制。
需要说明的是，若信任环1中还包括设备C和D，则设备C和D也会弹出允许登录的请求弹窗，显示界面与设备A弹出允许登录的请求弹窗后的界面相同，在用户点击设备A的“允许”按钮后，设备C与设备D中的允许登录的请求弹窗消失。
S9：设备B接收用户输入的设备A显示的验证码。
继续参照图15的(c)图，在设备A上显示验证码后，用户可将设备A上显示的验证码输入如图15的(d)图中所示的设备B的验证码输入界面中，设备B的信任环服务模块接收用户输入的设备A显示的验证码。
S10：设备B基于验证码生成认证参数。
本步骤中由信任环服务模块与信任环模块交互，生成认证参数，认证参数生成过程如下：
信任环服务模块接收用户输入的设备A生成的PinCodeA即验证码；
信任环模块生成椭圆曲线公私钥对ecc_keypair_B，并将设备B的椭圆曲线公钥NewDevPk发送至信任环服务模块；
信任环服务模块生成PinCode的散列值CodeIndex，PAKE参数(口令认证密钥交换参数)PakeX以及认证参数UpdatePkAuth。
生成的认证参数可以包括：CodeIndex、PakeX、NewDevPk、UpdatePkAuth、其他设备信息以及防重放攻击的挑战值challenge。
S11：设备B向信任环云发送认证参数。
设备B的信任环服务模块向信任环云发送认证参数，以通过信任环云将认证参数透传给设备A。
S12：信任环云向设备A透传认证参数。
S13：设备A生成协商参数，并封装主密钥MK。
设备A的信任环服务模块与信任环模块交互，生成协商参数并封装主密钥MK，具体生成协商参数、封装MK的过程如下：
信任环服务模块生成PinCodeA的散列值，比较与认证参数中的CodeIndex是否一致；生成HMAC与认证参数中的UpdatePkAuth比较是否一致；若两个比较结果均为一致，则向信任环模块发送校验通过通知，信任环模块生成协商参数，信任环模块生成协商参数的过程可以如下：
生成设备A的椭圆曲线公私钥对ecc_keypair_A、UpdatePk；
生成设备A公钥的消息验证码UpdatePkMac
协商出设备A的椭圆曲线的会话密钥：ecc_seesionkey
采用协商出的设备A的椭圆曲线的会话密钥加密主密钥，得到EMK12
信任环模块将协商出的会话密钥ecc_seesionkey以及EMK12发送至信任环服务模块，信任环服务模块执行如下算法逻辑：
生成PAKE参数PakeY
生成PAKE会话密钥pake_sessionKey
PAKE会话密钥加密EMK12得到封装后的MKE。
封装后的MK为对MK进行两层加密后生成，首先使用协商出的设备A的椭圆曲线的会话密钥ecc_seesionkey对MK进行加密，生成EMK12；然后再通过PAKE会话密钥对EMK12进行加密，得到封装后的MK。
信任环服务模块向信任环云发送协商参数和封装后的MK。其中，协商参数可以包括：
UpdatePk(设备A的椭圆曲线公钥)、UpdatePkMac、PakeY、CipherDevDataSignature、其他附加信息，封装后的MK可以表示为EEMK12。
S14：设备A向信任环云发送协商参数和封装后的MK。
S15：信任环云向设备B的信任环服务模块透传协商参数和封装后的MK。
S16：设备B的信任环服务模块解封封装后的MK，得到EMK12。
设备B的信任环服务模块接收到信任环云透传的协商参数和封装后的MK后，由设备B的信任环服务模块解封封装后的MK得到EMK12，具体解封封装后的MK的过程，可以如下：
计算pake_sessionKey，基于pake_sessionKey解密EEMK12得到EMK12
比较挑战值是否一致，若一致将EMK12发送至设备B的信任环模块中。
S17：设备B的信任环服务模块向设备B的信任环模块中发送EMK12。
S18：设备B的信任环模块协商会话密钥，基于会话密钥对EMK12进行解密，得到MK。
信任环模块执行如下过程：
协商出ECC会话密钥ecc_seesionkey，基于ECC会话密钥解密EMK12，得到MK。
生成消息验证码HMac(MK,UpdatePk)与设备A传入的协商参数中的UpdatePKMac比较是否一致，若一致，确定安全验证通过。
S19：设备B的信任环模块拉起锁屏。
设备B的信任环模块解密成功得到MK后，拉起锁屏。
S9至S19为基于设备A的验证码对设备B进行安全验证，以及在设备B安全验证通过后从设备A侧获取到MK的过程。
S20：设备B弹出锁屏码输入界面。
继续参照图15的(d)图，用户在设备B的验证码输入界面中输入设备A的验证码完成安全验证后，如图15的(e)图所示，设备B中显示本机锁屏码输入界面。
S21：设备B接收用户输入的设备B的锁屏码pw21。
本示例中以设备B的信任环服务模块接收用户输入的锁屏码为例进行说明，在实际实现过程中还可以设置锁屏服务模块，由锁屏服务模块接收用户输入的锁屏码。
S22：设备B的信任环服务模块验证设备B的锁屏码pw21，验证通过后基于pw21派生参数PAKE21。
基于设备B的锁屏密码pw21派生参数PAKE21的过程，参照图10中所示的创建信任环过程中的基于设备A的锁屏密码pw11派生参数PAKE11的过程说明即可，在此不再赘述。
S23：设备B的信任环模块基于pw21派生的密钥对MK进行加密，得到EMK21。
基于设备B的锁屏密码pw21派生的密钥对MK进行加密的过程，参照图10中所示的创建信任环过程中的基于设备A的锁屏密码pw11派生的密钥对MK进行加密，得到EMK11的过程说明即可，在此不再赘述。
S24：设备B的信任环模块向设备B的信任环服务模块发送EMK21。
S25：设备B的信任环服务模块向信任环云发送携带PAKE21和EMK21的加环请求。
S26：信任环云响应于加环请求，将设备B加入账号1的信任环1中。
设备B加入信任环1后，信任环云中管理的信任环1数据如表2中所示：
表2
UID UDID 参数PAKE 主密钥密文
账号1 设备A PAKE11 EMK11
账号1 设备B PAKE21 EMK21
其中，PAKE11又可以称为pakeParameter密文A，PAKE21又可称为pakeParameter密文B，EMK11又可称为escrowMsg密文A，EMK21又可称为escrowMsg密文B。
S27：信任环云向设备B的信任环服务模块返回加环成功通知。
S28：信任环服务模块向账号管理模块发送加环成功通知。
S29：返回云空间界面。
信任环云将设备B添加到信任环1中后，向设备B返回加环成功消息，设备B接收到加环成功消息后，如图15的(f)图所示回到云空间界面，云空间界面中的“云备份”按钮开启，用户可感知设备B已成功加入信任环，云空间中管理的业务数据可同步至账号管理服务器，以使账号1下的其他在信任环1中的设备能够共享该业务数据。
至此，设备B加入信任环1的过程完成，设备B完成注册。
设备B完成加环后，设备B的信任环服务模块将设备B的注册状态修改为已注册。
通过加入信任环过程可见，本申请实施例中，加环设备依据以已注册设备随机生成的验证码生成认证参数，通过云侧将认证参数透传给设备A，设备A基于认证参数对设备B进行身份验证，在设备B的身份验证通过后，设备A生成协商参数基于协商参数对主密钥MK进行双重加密后通过云侧将双重加密后的MK和协商参数透传给设备B，由设备B基于协商参数对双重加密后的MK进行解密得到MK。该加环过程，通过设备A与设备B间验证某种用户秘密(非锁屏码)，达到确认账号以及设备B的身份的目的，一方面，用于确认设备B身份的秘密不事先存储在任何设备上，具有即时性；第二方面，该秘密不由云侧下发到设备上，因此，基于该秘密生成的协商参数加密后的主密钥经云侧透传时，云侧不可解密得到主密钥，云侧可自证清白；3.该秘密对用户记忆友好，不需要额外记忆。
图17为示例性示出的设备B加入信任环后从账号管理服务器同步业务数据密文的示意图。图18为示例性示出的从账号管理服务器同步业务数据密文的界面示意图。请参考图17、图12和图18，在已创建账号1的信任环1、设备A已添加到信任环1、设备A已将业务数据密文Edata上传到账号管理服务器的情况下，设备B可以从账号管理服务器同步业务数据密文Edata到设备B，并在设备B本地用MK解密，得到业务数据明文data。
其中，加入信任环后设备B从账号管理服务器中同步业务数据密文的过程如下：
请参见图12，设备B中的业务数据同步服务模块通过应用程序层的账号管理服务器同步框架，从账号管理服务器获取到业务数据密文Edata。然后，设备B中的业务数据同步服务模块将业务数据密文Edata发送给设备B中的业务数据存储服务模块，业务数据存储服务模块将业务数据密文Edata发送给可设备B中的信执行环境中的密钥管理模块。信任环模块根据主密钥生成业务密钥dkey，密钥管理模块从信任环模块读取主密钥dkey，使用dkey对业务数据密文Edata进行解密，得到业务数据明文data。接着，密钥管理模块将业务数据明文data返回给业务数据存储服务模块，业务数据存储服务模块存储业务数据明文data。
例如，请参见图18，用户在设备B上使用业务1时，需要输入业务1的账号和密码。在业务1的账号和密码的输入界面，如图18的(a)图所示，设备B弹出提示是否使用密码保险箱已同步的业务1的账号和密码的信息。如果用户同意，设备B将密码保险箱已同步的业务1的账号和密码自动填充到图18的(a)图所示的界面，填充后如图18的(b)图所示。这样就不需要用户为每种业务独立记录密码，提升了用户体验。
需要说明的是，设备B加入到信任环1后，也可以将设备B中的业务数据用主密钥MK加密后同步到账号管理服务器中，此同步过程请参见前述对设备A同步业务数据到账号管理服务器的说明，此处不再赘述。
其中，本实施例提供的电子设备、计算机存储介质、计算机程序产品或芯片均用于执行上文所提供的对应的方法，因此，其所能达到的有益效果可参考上文所提供的对应的方法中的有益效果，此处不再赘述。
通过以上实施方式的描述，所属领域的技术人员可以了解到，为描述的方便和简洁，仅以上述各功能模块的划分进行举例说明，实际应用中，可以根据需要而将上述功能分配由不同的功能模块完成，即将装置的内部结构划分成不同的功能模块，以完成以上描述的全部或者部分功能。
在本申请所提供的几个实施例中，应该理解到，所揭露的装置和方法，可以通过其它的方式实现。例如，以上所描述的装置实施例仅仅是示意性的，例如，模块或单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，例如多个单元或组件可以结合或者可以集成到另一个装置，或一些特征可以忽略，或不执行。另一点，所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口，装置或单元的间接耦合或通信连接，可以是电性，机械或其它的形式。
作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是一个物理单元或多个物理单元，即可以位于一个地方，或者也可以分布到多个不同地方。可以根据实际的需要选择其中的部分或者全部单元来实现本实施例方案的目的。
另外，在本申请各个实施例中的各功能单元可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中。上述集成的单元既可以采用硬件的形式实现，也可以采用软件功能单元的形式实现。
本申请各个实施例的任意内容，以及同一实施例的任意内容，均可以自由组合。对上述内容的任意组合均在本申请的范围之内。
集成的单元如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个可读取存储介质中。基于这样的理解，本申请实施例的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的全部或部分可以以软件产品的形式体现出来，该软件产品存储在一个存储介质中，包括若干指令用以使得一个设备(可以是单片机，芯片等)或处理器(processor)执行本申请各个实施例方法的全部或部分步骤。而前述的存储介质包括：U盘、移动硬盘、只读存储器(read only memory，ROM)、随机存取存储器(random access memory，RAM)、磁碟或者光盘等各种可以存储程序代码的介质。
上面结合附图对本申请的实施例进行了描述，但是本申请并不局限于上述的具体实施方式，上述的具体实施方式仅仅是示意性的，而不是限制性的，本领域的普通技术人员在本申请的启示下，在不脱离本申请宗旨和权利要求所保护的范围情况下，还可做出很多形式，均属于本申请的保护之内。

Claims (13)

1.一种数据保护方法，应用于第二电子设备，其特征在于，所述方法包括：
接收用户输入的第一电子设备显示的验证码，其中，所述第一电子设备已登录第一账号，所述第一电子设备为所述第一账号对应的第一信任环的在环设备；所述验证码由所述第一电子设备在接收到允许所述第二电子设备登录所述第一账号的指令后生成；
基于所述验证码生成认证参数；
通过第一服务器将所述认证参数透传给所述第一电子设备，以供所述第一电子设备基于所述认证参数对所述第二电子设备进行身份认证；
在所述第二电子设备的身份认证通过的情况下，获得来自所述第一电子设备的主密钥；
接收用户输入的所述第二电子设备的第二锁屏码；
在所述第二锁屏码验证通过后，基于所述第二锁屏码对所述主密钥进行加密，生成所述第二电子设备的第二主密钥密文，以及基于所述第二锁屏码生成第二认证参数；
向所述第一服务器发送加环请求，以使所述第一服务器将所述第二主密钥密文和第二认证参数添加至所述第一信任环的信任环数据中。
2.根据权利要求1所述的方法，其特征在于，在基于所述第二锁屏码对所述主密钥进行加密，生成所述第二电子设备的第二主密钥密文之前，还包括：
将所述第二锁屏码与本地保存的所述第二电子设备的锁屏码进行比较；
当所述第二锁屏码与本地保存的所述第二电子设备的锁屏码一致，确定所述第二锁屏码验证通过。
3.根据权利要求1所述的方法，其特征在于，基于所述第二锁屏码对所述主密钥进行加密，生成所述第二电子设备的第二主密钥密文，包括：
根据第二锁屏码生成第三派生密钥；
根据第三派生密钥生成第四派生密钥；
根据第四派生密钥对所述主密钥进行加密，得到所述第二电子设备的第二主密钥密文。
4.根据权利要求1所述的方法，其特征在于，基于所述第二锁屏码生成第二认证参数包括：
根据第二锁屏码生成第三派生密钥；
根据所述第三派生密钥生成第二共享值；
根据所述第一服务器侧生成的HSM公钥加密所述第二共享值，得到所述第二认证参数。
5.根据权利要求1所述的方法，其特征在于，还包括：
基于所述主密钥派生第一业务密钥，使用所述第一业务密钥对第一业务数据进行加密，得到第一业务数据密文；
将所述第一业务数据密文发送给第二服务器，以使第二服务器保存所述第一业务数据密文。
6.根据权利要求5所述的方法，其特征在于，还包括：
从第二服务器获取第二业务数据密文；
基于所述主密钥派生第一业务密钥；
使用所述第一业务密钥对第二业务数据密文进行解密，得到第二业务数据。
7.一种第二电子设备，其特征在于，包括：
存储器和处理器；
所述处理器与所述存储器耦合；
所述存储器存储有程序指令，当所述程序指令由所述处理器执行时，使得所述第二电子设备执行如下步骤：
接收用户输入的第一电子设备显示的验证码，其中，所述第一电子设备已登录第一账号，所述第一电子设备为所述第一账号对应的第一信任环的在环设备；所述验证码由所述第一电子设备在接收到允许所述第二电子设备登录所述第一账号的指令后生成；
基于所述验证码生成认证参数；
通过第一服务器将所述认证参数透传给所述第一电子设备，以供所述第一电子设备基于所述认证参数对所述第二电子设备进行身份认证；
在所述第二电子设备的身份认证通过的情况下，获得来自所述第一电子设备的主密钥；
接收用户输入的所述第二电子设备的第二锁屏码；
在所述第二锁屏码验证通过后，基于所述第二锁屏码对所述主密钥进行加密，生成所述第二电子设备的第二主密钥密文，以及基于所述第二锁屏码生成第二认证参数；
向所述第一服务器发送加环请求，以使所述第一服务器将所述第二主密钥密文和第二认证参数添加至所述第一信任环的信任环数据中。
8.根据权利要求7所述的第二电子设备，其特征在于，当所述程序指令由所述处理器执行时，还使得所述第二电子设备执行如下步骤：
将所述第二锁屏码与本地保存的所述第二电子设备的锁屏码进行比较；
当所述第二锁屏码与本地保存的所述第二电子设备的锁屏码一致，确定所述第二锁屏码验证通过。
9.根据权利要求7所述的第二电子设备，其特征在于，当所述程序指令由所述处理器执行时，还使得所述第二电子设备执行如下步骤：
根据第二锁屏码生成第三派生密钥；
根据第三派生密钥生成第四派生密钥；
根据第四派生密钥对所述主密钥进行加密，得到所述第二电子设备的第二主密钥密文。
10.根据权利要求7所述的第二电子设备，其特征在于，当所述程序指令由所述处理器执行时，还使得所述第二电子设备执行如下步骤：
根据第二锁屏码生成第三派生密钥；
根据所述第三派生密钥生成第二共享值；
根据所述第一服务器侧生成的HSM公钥加密所述第二共享值，得到所述第二认证参数。
11.根据权利要求7所述的第二电子设备，其特征在于，当所述程序指令由所述处理器执行时，还使得所述第二电子设备执行如下步骤：
基于所述主密钥派生第一业务密钥，使用所述第一业务密钥对第一业务数据进行加密，得到第一业务数据密文；
将所述第一业务数据密文发送给第二服务器，以使第二服务器保存所述第一业务数据密文。
12.根据权利要求7所述的第二电子设备，其特征在于，当所述程序指令由所述处理器执行时，还使得所述第二电子设备执行如下步骤：
从第二服务器获取第二业务数据密文；
基于所述主密钥派生第一业务密钥；
使用所述第一业务密钥对第二业务数据密文进行解密，得到第二业务数据。
13.一种计算机可读存储介质，包括计算机程序，其特征在于，当所述计算机程序在电子设备上运行时，使得所述电子设备执行如权利要求1-6中任意一项所述的数据保护方法。
CN202111408374.3A 2021-11-19 2021-11-19 数据保护方法及电子设备 Active CN115037454B (zh)

Priority Applications (2)

Application Number Priority Date Filing Date Title
CN202310304709.XA CN116405202A (zh) 2021-11-19 2021-11-19 数据保护方法及电子设备
CN202111408374.3A CN115037454B (zh) 2021-11-19 2021-11-19 数据保护方法及电子设备

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN202111408374.3A CN115037454B (zh) 2021-11-19 2021-11-19 数据保护方法及电子设备

Related Child Applications (1)

Application Number Title Priority Date Filing Date
CN202310304709.XA Division CN116405202A (zh) 2021-11-19 2021-11-19 数据保护方法及电子设备

Publications (2)

Publication Number Publication Date
CN115037454A CN115037454A (zh) 2022-09-09
CN115037454B true CN115037454B (zh) 2023-04-07

Family

ID=83117776

Family Applications (2)

Application Number Title Priority Date Filing Date
CN202111408374.3A Active CN115037454B (zh) 2021-11-19 2021-11-19 数据保护方法及电子设备
CN202310304709.XA Pending CN116405202A (zh) 2021-11-19 2021-11-19 数据保护方法及电子设备

Family Applications After (1)

Application Number Title Priority Date Filing Date
CN202310304709.XA Pending CN116405202A (zh) 2021-11-19 2021-11-19 数据保护方法及电子设备

Country Status (1)

Country Link
CN (2) CN115037454B (zh)

Family Cites Families (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US10783565B2 (en) * 2014-10-30 2020-09-22 Ebay Inc. Method, manufacture, and system of transferring authenticated sessions and states between electronic devices
CN104506534B (zh) * 2014-12-25 2017-11-21 青岛微智慧信息有限公司 安全通信密钥协商交互方案
US20170372310A1 (en) * 2016-06-27 2017-12-28 Paypal, Inc. Secure key based trust chain among user devices
CN113609498B (zh) * 2021-07-15 2022-09-30 荣耀终端有限公司 数据保护方法及电子设备

Also Published As

Publication number Publication date
CN116405202A (zh) 2023-07-07
CN115037454A (zh) 2022-09-09

Similar Documents

Publication Publication Date Title
US11297055B2 (en) Multifactor contextual authentication and entropy from device or device input or gesture authentication
KR102399582B1 (ko) 모바일 디바이스를 사용한 시스템 액세스
CN107251035B (zh) 账户恢复协议
JP6121049B2 (ja) プロキシを使用したリソースへの安全なアクセス
CN102595404B (zh) 用于存储和执行访问控制客户端的方法及装置
US8769289B1 (en) Authentication of a user accessing a protected resource using multi-channel protocol
JP2016502377A (ja) 安全計算を用いて安全性を提供する方法
CN105379223A (zh) 用于移动应用管理的对移动应用的身份的验证
KR20140107168A (ko) 전자 액세스 클라이언트들을 저장하기 위한 장치 및 방법들
JP2019530265A (ja) グラフィックコード情報を提供及び取得する方法及び装置並びに端末
US9443069B1 (en) Verification platform having interface adapted for communication with verification agent
JP2017152880A (ja) 認証システム、鍵処理連携方法、および、鍵処理連携プログラム
CN115037451B (zh) 数据保护方法及电子设备
CN115037453B (zh) 数据保护方法、系统及电子设备
CN115021894B (zh) 数据保护方法、系统及电子设备
CN115037454B (zh) 数据保护方法及电子设备
CN115037455B (zh) 数据保护方法、系统及电子设备
CN115037450B (zh) 数据保护方法及电子设备
CN115021895B (zh) 数据保护方法、系统及电子设备
CN115037456B (zh) 数据保护方法、系统及电子设备
Cha et al. Is there a tradeoff between privacy and security in BLE-based IoT applications: Using a smart vehicle of a major Taiwanese brand as example
CN115037452B (zh) 数据保护方法、系统及电子设备
CN117879819B (zh) 密钥管理方法、装置、存储介质、设备及算力服务系统
Culnane et al. Formalising Application-Driven Authentication & Access-Control based on Users’ Companion Devices

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