CN112733096A - 一种用户注册方法、用户登录方法及对应装置 - Google Patents

一种用户注册方法、用户登录方法及对应装置 Download PDF

Info

Publication number
CN112733096A
CN112733096A CN201910977261.1A CN201910977261A CN112733096A CN 112733096 A CN112733096 A CN 112733096A CN 201910977261 A CN201910977261 A CN 201910977261A CN 112733096 A CN112733096 A CN 112733096A
Authority
CN
China
Prior art keywords
user
account
card
passport
tee
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
CN201910977261.1A
Other languages
English (en)
Other versions
CN112733096B (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.)
Shenzhen Hongzhuanfang Technology Co ltd
Original Assignee
Shenzhen Hongzhuanfang Technology 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 Shenzhen Hongzhuanfang Technology Co ltd filed Critical Shenzhen Hongzhuanfang Technology Co ltd
Priority to CN201910977261.1A priority Critical patent/CN112733096B/zh
Priority to PCT/CN2020/117104 priority patent/WO2021073383A1/zh
Publication of CN112733096A publication Critical patent/CN112733096A/zh
Priority to US17/719,552 priority patent/US20220318356A1/en
Application granted granted Critical
Publication of CN112733096B publication Critical patent/CN112733096B/zh
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • 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/31—User authentication
    • G06F21/32—User authentication using biometric data, e.g. fingerprints, iris scans or voiceprints
    • 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
    • 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/62—Protecting access to data via a platform, e.g. using keys or access control rules
    • G06F21/6218—Protecting access to data via a platform, e.g. using keys or access control rules to a system of files or objects, e.g. local or distributed file system or database
    • G06F21/6227—Protecting access to data via a platform, e.g. using keys or access control rules to a system of files or objects, e.g. local or distributed file system or database where protection concerns the structure of data, e.g. records, types, queries
    • 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
    • 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/0825—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 asymmetric-key encryption or public key infrastructure [PKI], e.g. key signature or public key certificates
    • 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)
  • Theoretical Computer Science (AREA)
  • Computer Hardware Design (AREA)
  • Software Systems (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Health & Medical Sciences (AREA)
  • Bioethics (AREA)
  • General Health & Medical Sciences (AREA)
  • Databases & Information Systems (AREA)
  • Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)
  • Storage Device Security (AREA)

Abstract

本申请涉及互联网技术领域，提供一种用户注册方法、用户登录方法及对应装置。在这些方法中，护照或用户卡上记录用户的自主身份的身份信息，用户可使用护照或用户卡访问应用网站，不同于传统的通过账号密码的访问方式。并且，本申请还围绕护照和用户卡，实现了其从申请到使用的一系列机制，使得在护照及用户卡的申请和使用过程，能够对用户身份信息进行有效的安全隔离和隐私隔离，既有效保障了用户身份信息的安全性，又避免了用户隐私被应用网站获取用于商业用途。此外，本申请还借助于授权卡和用户卡，实现了网站访问过程中的授权和转授权机制。

Description

一种用户注册方法、用户登录方法及对应装置
技术领域
本发明涉及互联网技术领域，具体而言，涉及一种用户注册方法、用户登录方法及对应装置。
背景技术
现有互联网上的用户身份大多由中心化机构分配，不具自主性，与这些身份关联的数据归中心化机构所有，普通用户既不拥有注册身份时提交的身份信息(例如，姓名、头像、联系电话、住址等)的主权，也不拥有从身份派生出来的关联数据(例如，用户访问互联网留下的行为数据，用户自创文章、演讲、音乐等数字资产)的自主控制权。中心化机构在获得用户的身份信息以及关联数据的使用权后，可将其用于商业目的，导致用户隐私被严重侵犯。
2012年2月，自主身份的概念首次被引用。程序员莫克西·马林斯佩克(MoxieMarlinspike)展示了一种解决自主主权身份的方法：使用基于密码学的策略来保护用户的自主权和控制权。自此，身份主权的概念逐步走进大众视野，并且随着区块链技术的普及，近些年自主身份的概念以及相关支持系统得到快速发展。
但就整体而言，自主身份技术尚处于发展前期，其技术标准并不成熟，相关领域的研究还有很多处于空白状态，其中，关于利用自主身份实现用户访问应用网站，目前尚未提出有价值的解决方案。
发明内容
本申请实施例的目的在于提供一种用户注册方法、用户登录方法及对应装置，以改善上述技术问题。
为实现上述目的，本申请提供如下技术方案：
第一方面，本申请实施例提供一种用户注册方法，应用于终端设备，所述方法包括：向应用网站发送用户注册请求，所述用户注册请求包括管理网站颁发的护照，所述护照包括用户要注册的化身账号的公钥、所述管理网站的第一公钥以及所述管理网站利用自身的第一私钥对所述护照的签名，所述护照用于证明所述化身账号由一个在所述管理网站实名注册过的可公开真身账号推导产生；其中，所述管理网站的第一私钥与所述管理网站的第一公钥为一个公私钥对。
第二方面，本申请实施例提供一种用户注册方法，应用于应用网站，所述方法包括：接收终端设备发送用户注册请求，所述用户注册请求包括管理网站颁发的护照，所述护照包括用户要注册的化身账号的公钥、所述管理网站的第一公钥以及所述管理网站利用自身的第一私钥对所述护照的签名，所述护照用于证明所述化身账号由一个在所述管理网站实名注册过的可公开真身账号推导产生；其中，所述管理网站的第一私钥与所述管理网站的第一公钥为一个公私钥对；利用所述用户注册请求进行注册验证，验证项目包括以下至少一项：验证所述化身账号的公钥是否尚未绑定资源标识；利用所述管理网站的第一公钥验证对所述护照的签名是否正确；若所有验证项目的结果均为“是”，则为所述用户分配一个资源标识，并绑定所述化身账号的公钥与所述资源标识；保存所述护照或所述护照中的预设信息项，并向所述终端设备发送注册成功的响应。
第三方面，本申请实施例提供一种用户登录方法，应用于终端设备，所述方法包括：向应用网站发送第一用户登录请求，所述第一用户登录请求包括管理网站颁发的护照，所述护照包括用户要登录的化身账号的公钥、所述管理网站的第一公钥以及所述管理网站利用自身的第一私钥对所述护照的签名，所述护照用于证明所述化身账号由一个在所述管理网站实名注册过的可公开真身账号推导产生；其中，所述管理网站的第一私钥与所述管理网站的第一公钥为一个公私钥对。
第四方面，本申请实施例提供一种用户登录方法，应用于应用网站，所述方法包括：接收终端设备发送第一用户登录请求，所述第一用户登录请求包括管理网站颁发的护照，所述护照包括用户要登录的化身账号的公钥、所述管理网站的第一公钥以及所述管理网站利用自身的第一私钥对所述护照的签名，所述护照用于证明所述化身账号由一个在所述管理网站实名注册过的可公开真身账号推导产生；其中，所述管理网站的第一私钥与所述管理网站的第一公钥为一个公私钥对；利用所述第一用户登录请求进行登录验证，验证项目包括以下至少一项：验证所述化身账号的公钥是否已经绑定资源标识；利用所述管理网站的第一公钥验证对所述护照的签名是否正确；若所有验证项目的结果均为“是”，则向所述终端设备发送登录成功的响应。
第五方面，本申请实施例提供一种护照申请方法，应用于终端设备，所述方法包括：利用用户在管理网站实名注册过的可公开真身账号推导化身账号；向所述管理网站发送护照申请请求，所述护照申请请求包括所述可公开真身账号的公钥、所述可公开真身账号的链码、从所述可公开真身账号推导所述化身账号的衍生路径以及利用所述可公开真身账号的私钥对所述护照申请请求的签名；接收所述管理网站发送的护照，所述护照包括所述化身账号的公钥、所述管理网站的第一公钥以及所述管理网站利用自身的第一私钥对所述护照的签名，所述护照用于证明所述化身账号由一个在所述管理网站实名注册过的可公开真身账号推导产生；其中，所述管理网站的第一私钥与所述管理网站的第一公钥为一个公私钥对。
第六方面，本申请实施例提供一种护照申请方法，应用于管理网站，所述方法包括：接收终端设备发送的护照申请请求，所述护照申请请求包括用户的可公开真身账号的公钥、所述可公开真身账号的链码、从所述可公开真身账号推导化身账号的衍生路径以及利用所述可公开真身账号的私钥对所述护照申请请求的签名；利用所述护照申请请求进行申请验证，验证项目包括以下至少一项：验证所述可公开真身账号的公钥是否已经进行过实名注册；利用所述可公开真身账号的公钥验证对所述护照申请请求的签名是否正确；若所有验证项目的结果均为“是”，则利用所述可公开真身账号的公钥、所述可公开真身账号的链码以及从所述可公开真身账号推导所述化身账号的衍生路径推导所述化身账号的公钥；生成护照，所述护照包括所述化身账号的公钥、所述管理网站的第一公钥以及所述管理网站利用自身的第一私钥对所述护照的签名，所述护照用于证明所述化身账号由一个在所述管理网站实名注册过的可公开真身账号推导产生；其中，所述管理网站的第一私钥与所述管理网站的第一公钥为一个公私钥对；向所述终端设备发送所述护照。
以上第一方面至第六方面，建立了一套关于护照申请、使用的完整机制。护照是管理网站颁发的一种可验凭证，护照上记录用户的自主身份的身份信息，用户可使用护照访问(包括注册和登录)应用网站，不同于传统的通过账号密码的访问方式，操作上更为方便，无需对账号密码进行记忆。用户可通过可公开真身账号派生多个化身账号，并为每个化身账号申请一份护照，这样就实现了在数字世界中对用户的真身与化身之间的关系进行表示。并且，在访问不同的应用网站时用户可使用记录有不同化身账号的护照，即使在某个应用网站的访问过程中账号私钥暴露，也不会扩散到其他应用网站，即实现了对用户身份信息的安全隔离。
此外，用户需要先从管理网站申请护照，然后才能将护照用于访问应用网站，在前一阶段，管理网站无法获知用户具体将如何使用护照，因为护照中没有包含和应用网站有关的信息；而在后一阶段，应用网站无法获知护照的真正拥有者，因为护照中并没有包括可公开真身账号的信息。前后两个阶段没有明显的关联，使得他人无法跟踪特定用户的上网行为，即实现了对用户身份信息的隐私隔离。
第七方面，本申请实施例提供一种用户登录方法，应用于终端设备，所述方法包括：向应用网站发送第二用户登录请求，所述第二用户登录请求包括可信执行环境(Trusted Execution Environment，TEE)中生成的用户卡，所述用户卡包括目标用户要登录的目标账号的公钥以及所述TEE利用自身的第二私钥对所述用户卡的签名，所述用户卡用于证明所述应用网站已经授权所述目标用户通过登录所述目标账号使用所述应用网站提供的服务。
第八方面，本申请实施例提供一种用户登录方法，应用于应用网站，所述方法包括：接收终端设备发送第二用户登录请求，所述第二用户登录请求包括TEE中生成的用户卡，所述用户卡包括目标用户要登录的目标账号的公钥以及所述TEE利用自身的第二私钥对所述用户卡的签名，所述用户卡用于证明所述应用网站已经授权所述目标用户通过登录所述目标账号使用所述应用网站提供的服务；利用所述第二用户登录请求进行登录验证，验证项目包括以下至少一项：验证所述目标账号的公钥是否已经绑定资源标识；利用所述TEE的第二公钥验证对所述用户卡的签名是否正确，所述TEE的第二公钥与所述TEE的第二私钥为一个公私钥对；若所有验证项目的结果均为“是”，则向所述终端设备发送登录成功的响应。
第九方面，本申请实施例提供一种授权卡申请方法，应用于终端设备，所述方法包括：向用户已登录的应用网站发送授权卡申请请求，所述授权卡申请请求包括目标账号的标识，所述目标账号的标识为所述目标账号的公钥、从所述用户的未公开真身账号推导所述目标账号的衍生路径或空字串；其中，若所述目标账号的标识为从所述未公开真身账号推导所述目标账号的衍生路径或空字串，表示拥有所述目标账号的目标用户为所述用户自身，若所述目标账号的标识为所述目标账号的公钥，表示所述目标用户为他人；接收所述应用网站发送的授权卡，所述授权卡包括所述授权卡的属主账号的公钥、所述应用网站的公钥以及所述应用网站利用自身的私钥对所述授权卡的签名，所述授权卡用于作为所述用户向TEE设备上配置的TEE申请供所述目标用户使用的用户卡的凭证。
第十方面，本申请实施例提供一种授权卡申请方法，应用于应用网站，所述方法包括：接收已登录所述应用网站的用户通过终端设备发送的授权卡申请请求，所述授权卡申请请求包括目标账号的标识，所述目标账号的标识为所述目标账号的公钥、从所述用户的未公开真身账号推导所述目标账号的衍生路径或空字串；其中，若所述目标账号的标识为从所述未公开真身账号推导所述目标账号的衍生路径或空字串，表示拥有所述目标账号的目标用户为所述用户自身，若所述目标账号的标识为所述目标账号的公钥，表示所述目标用户为他人；根据所述目标账号的标识判断所述目标用户为所述用户自身或他人；生成授权卡，所述授权卡包括所述授权卡的属主账号的公钥、所述应用网站的公钥以及所述应用网站利用自身的私钥对所述授权卡的签名，作为所述用户向TEE设备上配置的TEE申请供所述目标用户使用的用户卡的凭证；其中，若所述目标用户为所述用户自身，则所述属主账号为所述用户当前通过护照或用户卡登录的账号，若所述目标用户为他人，则所述授权卡的属主账号的公钥为所述目标账号的公钥；向所述终端设备发送所述授权卡。
第十一方面，本申请实施例提供一种单向密文密钥生成方法，应用于TEE，所述方法包括：所述TEE通过配置有所述TEE的TEE设备接收应用网站发送的密钥生成请求，所述密钥生成请求包括：第一命令字以及明文密钥；所述TEE根据所述第一命令字确定提供生成单向密文密钥的服务，服务的内容包括：所述TEE利用特定密钥对所述明文密钥进行加密，获得单向密文密钥，所述特定密钥仅在所述TEE中使用；所述TEE通过所述TEE设备向所述应用网站发送所述单向密文密钥。
第十二方面，本申请实施例提供一种用户卡申请方法，应用于终端设备，所述方法包括：若用户卡针对的目标用户为获得授权卡的用户自身，则从所述用户的未公开真身账号推导所述目标用户的目标账号，并将从所述未公开真身账号推导所述目标账号的衍生路径确定为所述目标账号的标识，若所述目标用户为他人，则将所述目标账号的公钥确定为所述目标账号的标识；向配置有TEE的TEE设备发送第一用户卡申请请求，所述第一用户卡申请请求包括第三命令字、所述授权卡以及所述目标账号的标识；其中，所述第三命令字表示请求所述TEE提供凭授权卡生成用户卡的服务，若所述目标用户为所述用户自身，则所述第一用户卡申请请求还包括所述未公开真身账号的公钥、所述未公开真身账号的链码以及所述授权卡的属主账号的衍生路径；接收所述TEE设备发送的用户卡，所述用户卡包括所述目标账号的公钥以及所述TEE利用自身的第二私钥对所述用户卡的签名，所述用户卡用于证明颁发所述授权卡的应用网站已经授权所述目标用户通过登录所述目标账号使用所述应用网站提供的服务。
第十三方面，本申请实施例提供一种用户卡申请方法，应用于TEE，所述方法包括：所述TEE通过配置有所述TEE的TEE设备接收获得授权卡的用户通过终端设备发送的第一用户卡申请请求，所述第一用户卡申请请求包括第三命令字、所述授权卡以及目标账号的标识；其中，若拥有所述目标账号的目标用户为所述用户自身，则所述第一用户卡申请请求还包括所述用户的未公开真身账号的公钥、所述未公开真身账号的链码以及授权卡的属主账号的衍生路径；所述TEE根据所述第三命令字确定提供凭授权卡生成用户卡的服务，服务的内容包括：所述TEE利用所述第一用户卡申请请求进行申请验证，验证项目包括以下至少一项：所述TEE利用所述授权卡中的应用网站的公钥验证对所述授权卡的签名是否正确；所述TEE根据所述目标账号的标识判断所述目标用户为所述用户自身或他人，若所述目标用户为所述用户自身，则所述TEE利用所述未公开真身账号的公钥、所述未公开真身账号的链码、所述目标账号的标识、所述授权卡、所述授权卡的属主账号的衍生路径验证所述属主账号是否属于所述目标用户；若所有验证项目的结果均为“是”，则所述TEE生成用户卡，所述用户卡包括所述目标账号的公钥以及所述TEE利用自身的第二私钥对所述用户卡的签名，所述用户卡用于证明所述应用网站已经授权所述目标用户通过登录所述目标账号使用所述应用网站提供的服务；其中，若所述目标用户为所述用户自身，则所述目标账号的公钥在验证所述属主账号是否属于所述目标用户时获得，若所述目标用户为他人，则所述目标账号的公钥为所述授权卡的属主账号的公钥；所述TEE通过所述TEE设备向所述终端设备发送所述用户卡。
第十四方面，本申请实施例提供一种用户卡申请方法，应用于终端设备，所述方法包括：向配置有TEE的TEE设备发送第二用户卡申请请求，所述第二用户卡申请请求包括第四命令字、用户申请的授权卡、目标账号的标识、所述用户的可公开真身账号的公钥、所述用户申请的护照以及所述授权卡的属主账号的衍生路径；其中，所述第四命令字表示请求所述TEE提供凭护照及授权卡生成用户卡的服务，所述目标账号的标识为从所述可公开真身账号推导所述护照中的化身账号的衍生路径；接收所述TEE设备发送的用户卡，所述用户卡包括所述目标账号的公钥以及所述TEE利用自身的第二私钥对所述用户卡的签名，所述用户卡用于证明颁发所述授权卡的应用网站已经授权拥有所述目标账号的目标用户通过登录所述目标账号使用所述应用网站提供的服务。
第十五方面，本申请实施例提供一种用户卡申请方法，应用于TEE，所述方法包括：所述TEE通过配置有所述TEE的TEE设备接收用户通过终端设备发送的第二用户卡申请请求，所述第二用户卡申请请求包括第四命令字、用户申请的授权卡、目标账号的标识、所述用户的可公开真身账号的公钥、所述用户申请的护照以及所述授权卡的属主账号的衍生路径；所述TEE根据所述第四命令字确定提供凭护照及授权卡生成用户卡的服务，服务的内容包括：所述TEE利用所述第二用户卡申请请求进行申请验证，验证项目包括以下至少一项：所述TEE利用所述授权卡中的应用网站的公钥验证对所述授权卡的签名是否正确；所述TEE利用所述护照中的管理网站的第一公钥验证对所述护照的签名是否正确；所述TEE利用所述可公开真身账号的公钥、所述护照、所述目标账号的标识、所述授权卡、所述授权卡的属主账号的衍生路径验证所述护照中的化身账号以及所述属主账号是否均属于拥有所述目标账号的目标用户；若所有验证项目的结果均为“是”，则所述TEE生成用户卡，所述用户卡包括所述目标账号的公钥以及所述TEE利用自身的第二私钥对所述用户卡的签名，所述用户卡用于证明所述应用网站已经授权所述目标用户通过登录所述目标账号使用所述应用网站提供的服务；其中，所述目标账号的公钥为所述护照中的化身账号的公钥；所述TEE通过所述TEE设备向所述终端设备发送所述用户卡。
以上第七方面至第十五方面，建立了一套关于用户卡申请、使用的完整机制。用户卡是应用网站颁发的一种可验凭证，用户卡上记录用户的自主身份的身份信息，用户可使用用户卡登录应用网站，不同于传统的通过账号密码的访问方式，操作上更为方便，无需对账号密码进行记忆。用户可通过未公开真身账号派生多个化身账号，并为每个化身账号申请一份用户卡，这样就实现了在数字世界中对用户的真身与化身之间的关系进行表示。并且，在访问不同的应用网站时用户可使用记录有不同化身账号的用户卡，即使在某个应用网站的访问过程中账号私钥暴露，也不会扩散到其他应用网站，即实现了对用户身份信息的安全隔离。
在本申请中，借助于授权卡及用户卡机制，用户既可以为自己申请应用网站的访问权限，也可以将自己访问应用网站的权限全部或部分赋予目标用户，使得目标用户可以执行指定范围内的操作，即同时实现了网站访问的授权和转授权。
此外，用户需要先从应用网站申请授权卡，然后请求TEE生成用户卡，最后使用用户卡登录应用网站。在第一个阶段，申请授权卡时登录到应用网站所用的化身账号，通常并不是用户卡中的目标账号，并且应用网站也无法获知用户何时使用授权卡，授权卡与那个目标账号捆绑使用也不一定知道(除非是转授权的情况)；在第二个阶段，TEE提供安全服务生成用户卡有利于防止用户隐私泄露，并且，在一些实现方式中，TEE提供安全服务还可以借助于区块链的分布式计算特性，进一步增加了安全性；而在第三个阶段，应用网站无法获知用户卡的真正拥有者，因为用户卡中并没有包括可公开真身账号或未公开真身账号的信息。前后三个阶段没有明显的关联，使得他人无法跟踪特定用户的上网行为，即实现了对用户身份信息的隐私隔离。
第十六方面，本申请实施例提供一种护照申请装置，配置于终端设备，所述装置包括：第一护照账号推导模块，用于利用用户在管理网站实名注册过的可公开真身账号推导化身账号；护照申请模块，用于向所述管理网站发送护照申请请求，所述护照申请请求包括所述可公开真身账号的公钥、所述可公开真身账号的链码、从所述可公开真身账号推导所述化身账号的衍生路径以及利用所述可公开真身账号的私钥对所述护照申请请求的签名；护照接收模块，用于接收所述管理网站发送的护照，所述护照包括所述化身账号的公钥、所述管理网站的第一公钥以及所述管理网站利用自身的第一私钥对所述护照的签名，所述护照用于证明所述化身账号由一个在所述管理网站实名注册过的可公开真身账号推导产生；其中，所述管理网站的第一私钥与所述管理网站的第一公钥为一个公私钥对。
第十七方面，本申请实施例提供一种护照申请装置，配置于管理网站，所述装置包括：护照申请请求接收模块，用于接收终端设备发送的护照申请请求，所述护照申请请求包括用户的可公开真身账号的公钥、所述可公开真身账号的链码、从所述可公开真身账号推导化身账号的衍生路径以及利用所述可公开真身账号的私钥对所述护照申请请求的签名；护照申请验证模块，用于利用所述护照申请请求进行申请验证，验证项目包括以下至少一项：验证所述可公开真身账号的公钥是否已经进行过实名注册；利用所述可公开真身账号的公钥验证对所述护照申请请求的签名是否正确；第二护照账号推导模块，用于若所有验证项目的结果均为“是”，则利用所述可公开真身账号的公钥、所述可公开真身账号的链码以及从所述可公开真身账号推导所述化身账号的衍生路径推导所述化身账号的公钥；护照生成模块，用于生成护照，所述护照包括所述化身账号的公钥、所述管理网站的第一公钥以及所述管理网站利用自身的第一私钥对所述护照的签名，所述护照用于证明所述化身账号由一个在所述管理网站实名注册过的可公开真身账号推导产生；其中，所述管理网站的第一私钥与所述管理网站的第一公钥为一个公私钥对；护照发送模块，用于向所述终端设备发送所述护照。
第十八方面，本申请实施例提供一种用户注册装置，配置于终端设备，所述装置包括：用户注册模块，用于向应用网站发送用户注册请求，所述用户注册请求包括管理网站颁发的护照，所述护照包括用户要注册的化身账号的公钥、所述管理网站的第一公钥以及所述管理网站利用自身的第一私钥对所述护照的签名，所述护照用于证明所述化身账号由一个在所述管理网站实名注册过的可公开真身账号推导产生；其中，所述管理网站的第一私钥与所述管理网站的第一公钥为一个公私钥对。
第十九方面，本申请实施例提供一种用户注册装置，配置于应用网站，所述装置包括：用户注册请求接收模块，用于接收终端设备发送用户注册请求，所述用户注册请求包括管理网站颁发的护照，所述护照包括用户要注册的化身账号的公钥、所述管理网站的第一公钥以及所述管理网站利用自身的第一私钥对所述护照的签名，所述护照用于证明所述化身账号由一个在所述管理网站实名注册过的可公开真身账号推导产生；其中，所述管理网站的第一私钥与所述管理网站的第一公钥为一个公私钥对；用户注册验证模块，用于利用所述用户注册请求进行注册验证，验证项目包括以下至少一项：验证所述化身账号的公钥是否尚未绑定资源标识；利用所述管理网站的第一公钥验证对所述护照的签名是否正确；资源标识绑定模块，用于若所有验证项目的结果均为“是”，则为所述用户分配一个资源标识，并绑定所述化身账号的公钥与所述资源标识；用户注册响应模块，用于保存所述护照或所述护照中的预设信息项，并向所述终端设备发送注册成功的响应。
第二十方面，本申请实施例提供一种用户登录装置，配置于终端设备，所述装置包括：第一登录模块，用于向应用网站发送第一用户登录请求，所述第一用户登录请求包括管理网站颁发的护照，所述护照包括用户要登录的化身账号的公钥、所述管理网站的第一公钥以及所述管理网站利用自身的第一私钥对所述护照的签名，所述护照用于证明所述化身账号由一个在所述管理网站实名注册过的可公开真身账号推导产生；其中，所述管理网站的第一私钥与所述管理网站的第一公钥为一个公私钥对。
第二十一方面，本申请实施例提供一种用户登录装置，配置于应用网站，所述装置包括：第一用户登录请求接收模块，用于接收终端设备发送第一用户登录请求，所述第一用户登录请求包括管理网站颁发的护照，所述护照包括用户要登录的化身账号的公钥、所述管理网站的第一公钥以及所述管理网站利用自身的第一私钥对所述护照的签名，所述护照用于证明所述化身账号由一个在所述管理网站实名注册过的可公开真身账号推导产生；其中，所述管理网站的第一私钥与所述管理网站的第一公钥为一个公私钥对；第一用户登录请求验证模块，用于利用所述第一用户登录请求进行登录验证，验证项目包括以下至少一项：验证所述化身账号的公钥是否已经绑定资源标识；利用所述管理网站的第一公钥验证对所述护照的签名是否正确；第一登录响应模块，用于若所有验证项目的结果均为“是”，则向所述终端设备发送登录成功的响应。
第二十二方面，本申请实施例提供一种授权卡申请装置，配置于终端设备，所述装置包括：授权卡申请模块，用于向用户已登录的应用网站发送授权卡申请请求，所述授权卡申请请求包括目标账号的标识，所述目标账号的标识为所述目标账号的公钥、从所述用户的未公开真身账号推导所述目标账号的衍生路径或空字串；其中，若所述目标账号的标识为从所述未公开真身账号推导所述目标账号的衍生路径或空字串，表示拥有所述目标账号的目标用户为所述用户自身，若所述目标账号的标识为所述目标账号的公钥，表示所述目标用户为他人；授权卡接收模块，用于接收所述应用网站发送的授权卡，所述授权卡包括所述授权卡的属主账号的公钥、所述应用网站的公钥以及所述应用网站利用自身的私钥对所述授权卡的签名，所述授权卡用于作为所述用户向TEE设备上配置的TEE申请供所述目标用户使用的用户卡的凭证。
第二十三方面，本申请实施例提供一种授权卡申请装置，配置于应用网站，所述装置包括：授权卡申请请求接收模块，用于接收已登录所述应用网站的用户通过终端设备发送的授权卡申请请求，所述授权卡申请请求包括目标账号的标识，所述目标账号的标识为所述目标账号的公钥、从所述用户的未公开真身账号推导所述目标账号的衍生路径或空字串；其中，若所述目标账号的标识为从所述未公开真身账号推导所述目标账号的衍生路径或空字串，表示拥有所述目标账号的目标用户为所述用户自身，若所述目标账号的标识为所述目标账号的公钥，表示所述目标用户为他人；身份判断模块，用于根据所述目标账号的标识判断所述目标用户为所述用户自身或他人；授权卡生成模块，用于生成授权卡，所述授权卡包括所述授权卡的属主账号的公钥、所述应用网站的公钥以及所述应用网站利用自身的私钥对所述授权卡的签名，作为所述用户向TEE设备上配置的TEE申请供所述目标用户使用的用户卡的凭证；其中，若所述目标用户为所述用户自身，则所述属主账号为所述用户当前通过护照或用户卡登录的账号，若所述目标用户为他人，则所述授权卡的属主账号的公钥为所述目标账号的公钥；授权卡发送模块，用于向所述终端设备发送所述授权卡。
第二十四方面，本申请实施例提供一种单向密文密钥生成装置，配置于TEE，所述装置包括：密钥生成请求接收模块，用于所述TEE通过配置有所述TEE的TEE设备接收应用网站发送的密钥生成请求，所述密钥生成请求包括：第一命令字以及明文密钥；单向密文密钥生成模块，用于所述TEE根据所述第一命令字确定提供生成单向密文密钥的服务，服务的内容包括：所述TEE利用特定密钥对所述明文密钥进行加密，获得单向密文密钥，所述特定密钥仅在所述TEE中使用；单向密文密钥发送模块，用于所述TEE通过所述TEE设备向所述应用网站发送所述单向密文密钥。
第二十五方面，本申请实施例提供一种用户卡申请装置，配置于终端设备，所述装置包括：标识获取模块，用于若用户卡针对的目标用户为获得授权卡的用户自身，则从所述用户的未公开真身账号推导所述目标用户的目标账号，并将从所述未公开真身账号推导所述目标账号的衍生路径确定为所述目标账号的标识，若所述目标用户为他人，则将所述目标账号的公钥确定为所述目标账号的标识；第一用户卡申请模块，用于向配置有TEE的TEE设备发送第一用户卡申请请求，所述第一用户卡申请请求包括第三命令字、所述授权卡以及所述目标账号的标识；其中，所述第三命令字表示请求所述TEE提供凭授权卡生成用户卡的服务，若所述目标用户为所述用户自身，则所述第一用户卡申请请求还包括所述未公开真身账号的公钥、所述未公开真身账号的链码以及所述授权卡的属主账号的衍生路径；第一用户卡接收模块，用于接收所述TEE设备发送的用户卡，所述用户卡包括所述目标账号的公钥以及所述TEE利用自身的第二私钥对所述用户卡的签名，所述用户卡用于证明颁发所述授权卡的应用网站已经授权所述目标用户通过登录所述目标账号使用所述应用网站提供的服务。
第二十六方面，本申请实施例提供一种用户卡申请装置，配置于TEE，所述装置包括：第一用户卡申请请求接收模块，用于所述TEE通过配置有所述TEE的TEE设备接收获得授权卡的用户通过终端设备发送的第一用户卡申请请求，所述第一用户卡申请请求包括第三命令字、所述授权卡以及目标账号的标识；其中，若拥有所述目标账号的目标用户为所述用户自身，则所述第一用户卡申请请求还包括所述用户的未公开真身账号的公钥、所述未公开真身账号的链码以及授权卡的属主账号的衍生路径；第一用户卡生成模块，用于所述TEE根据所述第三命令字确定提供凭授权卡生成用户卡的服务，服务的内容包括：所述TEE利用所述第一用户卡申请请求进行申请验证，验证项目包括以下至少一项：所述TEE利用所述授权卡中的应用网站的公钥验证对所述授权卡的签名是否正确；所述TEE根据所述目标账号的标识判断所述目标用户为所述用户自身或他人，若所述目标用户为所述用户自身，则所述TEE利用所述未公开真身账号的公钥、所述未公开真身账号的链码、所述目标账号的标识、所述授权卡、所述授权卡的属主账号的衍生路径验证所述属主账号是否属于所述目标用户；若所有验证项目的结果均为“是”，则所述TEE生成用户卡，所述用户卡包括所述目标账号的公钥以及所述TEE利用自身的第二私钥对所述用户卡的签名，所述用户卡用于证明所述应用网站已经授权所述目标用户通过登录所述目标账号使用所述应用网站提供的服务；其中，若所述目标用户为所述用户自身，则所述目标账号的公钥在验证所述属主账号是否属于所述目标用户时获得，若所述目标用户为他人，则所述目标账号的公钥为所述授权卡的属主账号的公钥；第一用户卡发送模块，用于所述TEE通过所述TEE设备向所述终端设备发送所述用户卡。
第二十七方面，本申请实施例提供一种用户卡申请装置，配置于终端设备，所述装置包括：第二用户卡申请模块，用于向配置有TEE的TEE设备发送第二用户卡申请请求，所述第二用户卡申请请求包括第四命令字、用户申请的授权卡、目标账号的标识、所述用户的可公开真身账号的公钥、所述用户申请的护照以及所述授权卡的属主账号的衍生路径；其中，所述第四命令字表示请求所述TEE提供凭护照及授权卡生成用户卡的服务，所述目标账号的标识为从所述可公开真身账号推导所述护照中的化身账号的衍生路径；第二用户卡接收模块，用于接收所述TEE设备发送的用户卡，所述用户卡包括所述目标账号的公钥以及所述TEE利用自身的第二私钥对所述用户卡的签名，所述用户卡用于证明颁发所述授权卡的应用网站已经授权拥有所述目标账号的目标用户通过登录所述目标账号使用所述应用网站提供的服务。
第二十八方面，本申请实施例提供一种用户卡申请装置，配置于TEE，所述装置包括：第二用户卡申请请求接收模块，用于所述TEE通过配置有所述TEE的TEE设备接收用户通过终端设备发送的第二用户卡申请请求，所述第二用户卡申请请求包括第四命令字、用户申请的授权卡、目标账号的标识、所述用户的可公开真身账号的公钥、所述用户申请的护照以及所述授权卡的属主账号的衍生路径；第二用户卡生成模块，用于所述TEE根据所述第四命令字确定提供凭护照及授权卡生成用户卡的服务，服务的内容包括：所述TEE利用所述第二用户卡申请请求进行申请验证，验证项目包括以下至少一项：所述TEE利用所述授权卡中的应用网站的公钥验证对所述授权卡的签名是否正确；所述TEE利用所述护照中的管理网站的第一公钥验证对所述护照的签名是否正确；所述TEE利用所述可公开真身账号的公钥、所述护照、所述目标账号的标识、所述授权卡、所述授权卡的属主账号的衍生路径验证所述护照中的化身账号以及所述属主账号是否均属于拥有所述目标账号的目标用户；若所有验证项目的结果均为“是”，则所述TEE生成用户卡，所述用户卡包括所述目标账号的公钥以及所述TEE利用自身的第二私钥对所述用户卡的签名，所述用户卡用于证明所述应用网站已经授权所述目标用户通过登录所述目标账号使用所述应用网站提供的服务；其中，所述目标账号的公钥为所述护照中的化身账号的公钥；第二用户卡发送模块，用于所述TEE通过所述TEE设备向所述终端设备发送所述用户卡。
第二十九方面，本申请实施例提供一种用户登录装置，配置于终端设备，所述装置包括：第二登录模块，用于向应用网站发送第二用户登录请求，所述第二用户登录请求包括TEE中生成的用户卡，所述用户卡包括目标用户要登录的目标账号的公钥以及所述TEE利用自身的第二私钥对所述用户卡的签名，所述用户卡用于证明所述应用网站已经授权所述目标用户通过登录所述目标账号使用所述应用网站提供的服务。
第三十方面，本申请实施例提供一种用户登录装置，配置于应用网站，所述装置包括：第二用户登录请求接收模块，用于接收终端设备发送第二用户登录请求，所述第二用户登录请求包括TEE中生成的用户卡，所述用户卡包括目标用户要登录的目标账号的公钥以及所述TEE利用自身的第二私钥对所述用户卡的签名，所述用户卡用于证明所述应用网站已经授权所述目标用户通过登录所述目标账号使用所述应用网站提供的服务；第二用户登录请求验证模块，用于利用所述第二用户登录请求进行登录验证，验证项目包括以下至少一项：验证所述目标账号的公钥是否已经绑定资源标识；利用所述TEE的第二公钥验证对所述用户卡的签名是否正确，所述TEE的第二公钥与所述TEE的第二私钥为一个公私钥对；第二登录响应模块，用于若所有验证项目的结果均为“是”，则向所述终端设备发送登录成功的响应。
第三十一方面，本申请实施例提供一种终端设备，包括：存储器以及处理器，所述存储器中存储有计算机程序指令，所述计算机程序指令被所述处理器读取并运行时，执行第一方面、第三方面、第五方面、第七方面、第九方面、第十二方面、第十四方面中的任意一方面或其可能的实现方式提供的方法。
第三十二方面，本申请实施例提供一种管理网站的服务器，包括：存储器以及处理器，所述存储器中存储有计算机程序指令，所述计算机程序指令被所述处理器读取并运行时，执行第六方面或其可能的实现方式提供的方法。
第三十三方面，本申请实施例提供一种应用网站的服务器，包括：存储器以及处理器，所述存储器中存储有计算机程序指令，所述计算机程序指令被所述处理器读取并运行时，执行第二方面、第四方面、第八方面、第十方面中的任意一方面或其可能的实现方式提供的方法。
第三十四方面，本申请实施例提供一种TEE，包括：存储器以及处理器，所述存储器中存储有计算机程序指令，所述计算机程序指令被所述处理器读取并运行时，执行第十一方面、第十三方面、第十五方面中的任意一方面或其可能的实现方式提供的方法。
第三十五方面，本申请实施例提供一种TEE设备，所述TEE设备上配置有第三十四方面提供的TEE。
第三十六方面，本申请实施例提供一种计算机可读存储介质，所述计算机可读存储介质上存储有计算机程序指令，所述计算机程序指令被计算机运行时，执行第一方面至第十五方面中的任意一方面或其可能的实现方式提供的方法。
附图说明
为了更清楚地说明本申请实施例的技术方案，下面将对本申请实施例中所需要使用的附图作简单地介绍，应当理解，以下附图仅示出了本申请的某些实施例，因此不应被看作是对范围的限定，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他相关的附图。
图1示出了本申请实施例提供的一种护照的申请和使用方法的示意图；
图2示出了本申请实施例提供的方法中步骤S0至步骤S3的流程图；
图3示出了借助区块链实现分布式安全服务的一种场景的示意图；
图4示出了本申请实施例提供的一种用户卡的申请和使用方法的示意图；
图5示出了本申请实施例提供的方法中步骤S4至步骤S7的流程图；
图6示出了本申请实施例提供的一种电子设备的示意图。
具体实施方式
下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行描述。应注意到：相似的标号和字母在下面的附图中表示类似项，因此，一旦某一项在一个附图中被定义，则在随后的附图中不需要对其进行进一步定义和解释。同时，在本申请的描述中，术语“第一”、“第二”等仅用于将一个实体或者操作与另一个实体或操作区分开来，而不能理解为指示或暗示相对重要性，也不能理解为要求或者暗示这些实体或操作之间存在任何这种实际的关系或者顺序。术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括所述要素的过程、方法、物品或者设备中还存在另外的相同要素。
区块链技术发端于比特币，比特币的非确定性钱包(Nondeterministic Wallet)与分层确定性钱包(Hierarchical Deterministic Wallet，HD钱包)，开启了一种自主身份创建模式。用户自行创建身份，而不由某中心机构分配，用户拥有所建身份的控制权，并凭私钥对特定任务(例如转账)以签名方式实现授权，其他个人或机构无法仿冒、或干涉、或冻结、或删除账号。尤其是HD钱包，它可以从一个根账号衍生出多级子账号，衍生的子账号包含私钥与公钥，一个HD钱包的属主不仅拥有根账号的控制权，也拥有所有由根账号衍生的各级子账号的控制权，关于HD钱包的定义及技术细节可参考比特币BIP-32技术规范，此处不作详细阐述。衍生子账号的行为，与现实世界中真身、化身的概念类似：真身只一个，表征用户的唯一的、真实的身份；化身可以有多个，表征用户在完成特定工作时或者处于特定场景下的身份。当然，无论是真身还是化身，最终都指向同一个用户。
BIP-32还规定了从父账号衍生子账号的两种方式：常规衍生(NormalDerivation)与硬化衍生(Hardened Derivation)，其中，常规衍生会利用父账号的公钥，而硬化衍生只利用父账号的私钥。硬化衍生在衍化树上具有隔离效果，比如，子账号的私钥不慎泄露时，他人无法用公开的父账号公钥反推父账号的私钥，因此相较于常规衍生安全性较高。
对于常规衍生还进一步区分是否结合父账号的私钥来推导子账号的私钥，如果结合父账号的私钥去推导，因其计算量少，效率较高，得到子账号的私钥后，再依据子账号的私钥推导其公钥的速度也很快。如果不结合父账号的私钥去推导，即依据父账号的公钥推导子账号的公钥，计算量将大出很多，而且推导出的子账号是不带私钥的，此种方式推导出的公钥可用于收款，而无法支付(因为不具备签名能力)。
本申请中涉及的用户的自主身份，可以按照HD钱包中规定的方式进行创建，并且在阐述时也主要以这种方式为例，但也不排除其他实现方式。
自主身份的概念涉及甚广，本申请主要聚焦于利用自主身份实现用户访问应用网站(包括注册和登录应用网站)，并着重解决以下问题：
其一，如何将用户的一个真身表现为众多化身(这些化身与该真身关联)，从而使得用户可以利用不同的化身访问不同的应用网站；
其二，在将一个真身关联到众多化身时，如何实现各关联线之间的隔离，即不会因为一个化身身份暴露而影响其他化身乃至真身，进而导致用户对身份主权失去控制，本条简称安全隔离；
其三，在将一个真身关联到众多化身时，如何避关联关系暴露，即避免应用网站获知化身归属于某个真身或者多个化身账号归属于同一真身(从而应用网站可以进行数据挖掘等操作，跟踪用户上网行为以牟取商业利益)，本条简称隐私隔离；
其四，如何实现应用网站对用户访问的授权，以及用户如何通过自主身份去承接这些授权；
其五，如何实现用户的转授权，即用户将自己访问应用网站的权限全部或部分赋予目标用户，使得目标用户可以执行指定范围内的操作。
可以理解的，以上问题仅仅是本申请解决的一些关键性问题，因此专门予以说明，但并不代表本申请提供的方案仅仅涵盖上述内容，事实上本申请提供的方案建立起了一套利用自主身份访问应用网站的完整体系。下面将具体进行介绍：
图1示出了本申请实施例提供的一种护照的申请和使用方法的示意图。参照图1，该方法涉及以下几个参与方：终端设备、管理网站以及应用网站。其中，终端设备可以是用户使用的计算机、手机、智能穿戴设备、车载设备等；管理网站用于管理用户的真实身份，可由权威机构运营，具体可以是指权威机构架设的服务器；应用网站用于为用户提供某些特定的服务，例如网页浏览服务、应用程序相关的服务等，具体可以是指服务提供商架设的服务器。终端设备上可以安装浏览器、客户端软件等，以实现对管理网站和应用网站的访问，特别地，对于应用网站，用户可以进行注册以及登录，以便获得与登录账号匹配的操作权限，这也是本申请的方案主要关注的问题。需要指出，上述终端设备、管理网站的服务器、应用网站的服务器既可以是实体设备，也可以是虚拟设备，不作限定。
另外，还需要指出，在本申请中为简化阐述，经常会采取用户执行某项操作的说法，其表达的含义是用户通过终端设备或其他设备上的软硬件的功能执行某项操作，不应理解为用户人工执行该项操作。
图1示出的步骤包括：
步骤S0：用户通过终端设备在管理网站注册可公开真身账号，管理网站对用户做实名认证。
步骤S1：用户通过终端设备向管理网站申请护照，管理网站验证无误后，向用户颁发护照。
步骤S2：用户通过终端设备凭护照在应用网站注册，应用网站验证无误后，为用户注册账号。
步骤S3：用户通过终端设备凭护照登录应用网站，应用网站验证无误后，允许用户登录账号。
下面结合图2对步骤S0至步骤S3作进一步介绍，参照图2，步骤S0可以包括：
步骤S00：终端设备生成可公开真身账号。
步骤S01：终端设备向管理网站发送根账号注册请求。
步骤S02：管理网站根据根账号注册请求进行根账号注册验证。
步骤S03：管理网站绑定可公开真身账号的公钥与用户的实名认证信息。
步骤S04：管理网站向终端设备发送根账号注册响应。
步骤S00至步骤S04结合在一起进行阐述。本申请在实现自主身份时沿用上述现实世界中真身和化身的含义，提出真身账号、化身账号的概念：真身账号表征用户的唯一的、真实的身份；化身账号由真身账号衍生，表征用户完成特定工作(本申请中主要指注册和登录应用网站)时使用的身份。其中，由真身账号推导化身账号的方式可以采用HD钱包中规定的衍生方式，当然也不排除采用其他方式。
在BIP-32中提出了账号衍生的树状结构，BIP-44技术规范则在BIP-32的基础上，赋予树状结构中各层特殊的意义，使HD钱包能够更好地支持多币种和多账户。根据BIP-44的规定，用户可按照如下路径推导应用于不同用途的子账号：
m/purpose'/coin_type'/account'/change/address_index
上述路径中的m表示HD钱包的根账号，可由HD钱包创建。此外包括5个预定义的树状层级结构：purpose’固定取值44’表示符合BIP-44的多账户结构，coin_type’取不同值表示不同数字货币币种，account’是逻辑性亚账户，表示供公司内不同部门(或不同会计目的)使用，change表示用于找零或其它目的，address_index是派生众多实际使用的末端账号，当然，根据实际需求还可以在address_index之后推导更多的子账号。此外，上述路径中的符号’表示本层级账号是通过硬化衍生得到，如果不附带该符号表示本层级账号是通过普通衍生得到。关于以上层级结构的具体含义可以参考BIP-44中的规定，此处不作详细解释。
进一步的，本申请中的真身账号还可以分为可公开真身账号和未公开真身账号，可公开真身账号表征账号的公钥处于对外公开状态，未公开真身账号表征账号的公钥处于不对外公开状态(可以是建议不对外公开或者强制不对外公开)，不对外公开账号的公钥有助于降低他人对账号进行攻击的可能性，因此未公开真身账号可应用于对安全性要求更高的场合(如TEE中)。在步骤S0至步骤S3中，可以只使用可公开真身账号而不使用未公开真身账号(至于此时是否要生成未公开真身账号根据不同的实现可以生成也可以不生成)。上面所谓的对外，可以是指在用户使用的终端设备或安全环境(如TEE)之外。
在一种实现方式中，可以按照BIP-44规范定义可公开真身账号和未公开真身账号，例如，未公开真身账号的衍生路径可以是m/44'/0'/0'/0/0，其中，靠右侧的“0'”，指明采用硬化衍生去推导子账号，这使得即使其下某一级别的私钥不慎泄露后，仍能他人阻断逐级向上反推私钥，从而限制安全事故扩散到其它衍生路径。可公开真身账号的衍生路径可以是m/44'/0'/0'/0/0/0/0，即未公开真身账号可以通过固定的相对路径/0/0推导可公开真身账号，具体表示为：
可公开真身账号＝未公开真身账号.child(0).child(0)
需要指出，可公开真身账号和未公开真身账号并不一定要采用上述衍生路径或上述衍生路径中的衍生方式，但可公开真身账号应当实现为未公开真身账号的子账号(可以是直属子级或者非直属子级)，即未公开真身账号可以推导可公开真身账号，但可公开真身账号不能反推未公开真身账号，即实施单向隔离，该要求一方面是为了保证未公开真身账号的安全性(未公开真身账号本来就适用于对安全性要求较高的场合)，另一方面也是为了通过未公开真身账号和可公开真身账号之间的关联关系进行同属验证，关于同属验证具体见后文阐述。之前已经提到，如果只实现步骤S0至步骤S3的方法(只使用护照，不使用用户卡)，可以不使用未公开真身账号，可以理解，此时自然也不再对可公开真身账号和未公开真身账号之间的关系进行限定。
从真身账号可以推导化身账号，表征现实世界中的从真身派生出化身。例如，可以按照如下方式推导两类化身账号：
第一类化身账号＝未公开真身账号.child(index)
第二类化身账号＝可公开真身账号.child(index)
其中，index为化身账号的序号，index取值范围为1～0x7fffffff，数量可达21亿个，对于常规应用这个化身账号的数量已经绰绰有余。在上面的推导方式中，化身账号都是真身账号的直属子级，当然在其他一些实现方式中，化身账号也可以是真身账号的非直属子集，这一点并不作限定，只是直属子级的账号推导效率更高一些。此外，从真身账号推导化身账号可以采用普通衍生，也可以采用硬化衍生，这一点也不作限定。上面的第一类化身账号、第二类化身账号分别用于护照和用户卡中，关于化身账号的使用，在后文的方法中再具体介绍。
终端设备上可以安装HD钱包应用，HD钱包应用可以在用户的指示下按照设定好的衍生路径创建可公开真身账号(如果需要，未公开真身账号也可以在此时创建)以及推导化身账号，创建了真身账号也就是创建了用户的自主身份。可以理解的，虽然BIP-32、BIP-44都是比特币的相关技术规范，但其中账号创建过程与比特币、区块链等没有必然关系，因此，在本申请中，上述HD钱包应用的功能主要是创建、管理用户的自主身份，其可以实现与数字货币交易相关的功能也可以不实现，只是为了方便起见，仍将其称为“钱包”。
终端设备上生成了可公开真身账号后，用户需要将该账号的公钥提交到管理网站进行注册，使得可公开真身账号关联到现实世界中的个人(当然也可能是群体、单位、组织)，关联后可公开真身账号才能够真正体现用户在现实世界中的真身的含义。由于将数字世界中的账号关联到现实世界中的身份，必然涉及权益分配，因此注册时管理网站会对用户做实名认证，若通过认证则将可公开真身账号的公钥与用户的实名认证信息绑定。实名认证一方面保证用户注册的公钥对应于真人，是可信的，另一方面也确保注册的唯一性，即现实世界的一个真人只能注册一次可公开真身的公钥。
其具体过程如下所述：
终端设备向管理网站发送根账号注册请求，根账号注册请求包括用户的实名认证信息以及可公开真身账号的公钥。管理网站接收到根账号注册请求后，利用根账号注册请求进行根账号注册验证，验证项目包括以下至少一项：
(1)验证实名认证信息是否正确；
(2)验证可公开真身账号的公钥是否尚未绑定实名认证信息。
其中，第(1)项。第(2)项即验证该可公开真身账号的公钥是否已经注册过，确保一个可公开真身账号只可以在管理网站注册一次。
若所有验证项目的结果均为“是”，则管理网站将可公开真身账号的公钥与用户的实名认证信息绑定，此时注册完成，管理网站向终端设备发送根账号注册响应，告知用户注册成功。若某个验证项目的结果为“否”，则管理网站也可以向终端设备发送根账号注册响应，告知用户注册失败，还可以进一步告知用户注册失败的原因。可以理解的，上述验证项目的验证顺序不作限定，并且如果某个验证项目验证失败，剩余尚未执行的验证项目可以不再执行。
用户的实名认证信息是指能够表征用户实际身份的信息，例如，手机号、身份证号、照片等。在一种比较常见的实现方式中，实名认证信息可以包括用户的手机号以及管理网站提供的短信验证码，管理网站接收到用户提交的验证码后判断与自身提供的是否一致从而完成对实名认证信息的验证。其中，手机号虽然并未直接指明用户实际身份，但由于很多国家(如中国)在申请手机号时已经进行过实名登记，所以管理网站根据手机号也能够查询到用户的实际身份，此种方式可称为弱实名认证，弱实名认证虽然是一种间接的认证方式，但由于用户不需要提交太多信息，所以操作上比较简单。
用户提交根账号注册请求的方式不作限定，例如，可以通过HD钱包应用直接向管理网站提交，或者，可以通过浏览器访问管理网站的页面，在页面上填写实名认证信息以及可公开真身账号的公钥，然后点击页面上的按钮进行提交，等等。此外，在某些实现方式中，这些信息的提交过程也可能分成多个步骤，例如，需要用户先输入手机号和验证码，管理网站验证通过后才允许用户提交可公开真身账号的公钥。
进一步的，对于实名认证信息的验证可以由管理网站自己完成，也可以由管理网站借助第三方完成，管理网站从第三方处获得验证结果即可。
在一种实现方式中，根账号注册请求还可以包括特定信息以及利用可公开真身账号的私钥对特定信息的签名，从而管理网站可以用用户提交的可公开真身账号的公钥验证签名，以证实用户确实拥有可公开真身账号。该特定信息可以包括管理网站提供的随机字串，使用随机字串作为待签名内容有利于避免重放攻击，例如，管理网站可以在提供给用户浏览的根账号注册页面中附带该随机字串。当然，特定信息还可以包括其他内容，例如，可公开真身账号的公钥、实名认证信息等，管理网站通过验证签名也可以确认这些内容是否被篡改。
用户在管理网站完成可公开真身账号的注册后，便可以向管理网站申请护照，即执行步骤S1。申请护照前用户自行通过可公开真身账号衍生出一个化身账号，然后请求管理网站出具一份证明，证明该化身账号属于某个已经在管理网站进行实名注册过的可公开真身账号。用户获得护照后，便可以在承认该护照效力的应用网站进行注册(步骤S2)以及登录(步骤S3)，当然这些应用网站也会对护照的真伪进行验证。
继续参照图2，步骤S1可以包括：
步骤S10：终端设备向管理网站发送护照申请请求。
步骤S11：管理网站根据护照申请请求进行护照申请验证。
步骤S12：管理网站生成护照。
步骤S13：管理网站向终端设备发送护照。
步骤S10至步骤S13结合在一起进行阐述。首先，用户在终端设备上通过已经实名注册过的可公开真身账号推导一个化身账号，推导方式上文已经阐述。
然后，终端设备向管理网站发送护照申请请求，护照申请请求至少包括可公开真身账号的公钥、可公开真身账号的链码(Chain Code)、从可公开真身账号推导化身账号的衍生路径以及利用可公开真身账号的私钥对护照申请请求的签名。其中，链码是父账号推导子账号所需的一项信息，其含义可以参考BIP-32技术规范，这里不作具体解释；利用可公开真身账号的私钥对护照申请请求的签名，其签名的对象可以是护照申请请求中除该签名自身以外的其他信息。
根据需求，护照申请请求中还可以包括以下信息中的一项或多项：终端设备的当前时间、护照的目标时间以及护照的时段类别。其中，护照的目标时间为终端设备的当前时间，或者，允许使用申请下来的护照进行注册或登录的应用网站指定的历史时间。
此外，考虑到护照申请请求中存在部分敏感信息，例如链码和衍生路径，这些信息的泄露虽不致命(因为私钥没有泄露)，但不排除他人利用这些信息派生子账号(如果只是推导子账号的公钥，在BIP-32中可以无需父账号的私钥)假冒用户身份，所以在一种可选的方案中，还可以利用管理网站的第二公钥加密对护照申请请求进行加密，步骤S11中管理网站接收到护照申请请求后，可以利用其自身持有的第二私钥对护照申请请求进行解密然后再进行处理。其中，管理网站的第二公钥和第二私钥为一个公私钥对，例如，可以是RSA、ECC公私钥对等。在这种方案中，护照申请请求中携带的签名，其签名对象既可以是加密前的明文(签名后再加密)也可以是加密后的密文。
关于护照申请请求中各信息项的用途，后文中用到时再具体说明。护照申请请求中可以只包含需要的信息项，其余的信息项完全不体现，或者护照申请请求也可以采用固定的格式，例如，每个可能包含的信息项都体现为一个对应的字段，如果需要用到某个信息项，则对应字段的值不为空，否则对应字段的值为空。
管理网站接收到护照申请请求后，利用护照申请请求进行护照申请验证，验证项目包括以下至少一项：
(1)验证可公开真身账号的公钥是否已经进行过实名注册；
(2)利用可公开真身账号的公钥验证对护照申请请求的签名是否正确；
(3)获取管理网站的当前时间，验证终端设备的当前时间与管理网站的当前时间之间的间隔是否小于第一预设时间间隔。
其中，第(1)项即验证用户是否有申请护照的资格，因为一个可公开真身账号只能注册一次。第(2)项即验证用户是否确实拥有可公开真身账号以及护照申请请求内容是否遭到篡改。要执行第(3)项验证的前置条件是护照申请请求包括终端设备的当前时间，第(3)项即验证终端设备的当前时间和管理网站的当前时间是否间隔较远，若间隔较远(不小于第一预设时间间隔)，则该请求可能是重放攻击，应当拒绝。第一预设时间间隔的具体取值不作限定，例如，可以是30分钟、1小时等。
若所有验证项目的结果均为“是”，则管理网站利用可公开真身账号的公钥以及从可公开真身账号推导化身账号的衍生路径推导化身账号的公钥，推导方式上文已经阐述。由于管理网站通过护照申请请求中的签名证实了可公开真身账号确实是该用户拥有的，并且护照申请请求中的链码、衍生路径等信息真实可信，从而管理网站自行推导出的化身账号也必然归属于该用户，因此可以为其颁发一份护照，证明该化身账号属于一个已经在管理网站进行实名注册过的可公开真身账号。若某个验证项目的结果为“否”，则管理网站也可以告知用户申请护照失败，还可以进一步告知用户申请失败的原因。可以理解的，上述验证项目的验证顺序不作限定，并且如果某个验证项目验证失败，剩余尚未执行的验证项目可以不再执行。
管理网站组织若干信息项以生成护照。护照中至少包括管理网站自行推导的化身账号的公钥、管理网站的第一公钥以及管理网站利用自身的第一私钥对护照的签名。根据需求，护照还可以包括以下信息中的一项或多项：护照的验根码、护照的时段唯一码、管理网站的标识、用户的组、护照的时段类别、护照的有效期以及护照的目标时间。
其中，管理网站的第一公钥和第一私钥构成一个公私钥对，表征管理网站作为护照颁发专员的身份，例如，可以是RSA、ECC公私钥对等，管理网站的第一公钥和上文提到的第二公钥可以是同一个也可以不是同一个，相应地，管理网站的第一私钥和上文提到的第二私钥可以是同一个也可以不是同一个。护照中携带管理网站的第一公钥是为了验证护照中的签名，以证实护照确实是由管理网站颁发以及护照内容真实可信。护照中的签名，其签名的对象可以是护照中除该签名自身以外的其他信息。
护照的验根码用于核对护照身份，验根码可以根据可公开真身账号的公钥以及化身账号的总衍生路径进行计算，其中，化身账号的总衍生路径可以定义为一个以未公开真身账号为推导起点的衍生路径，该衍生路径由两部分路径拼接获得：一部分是从可公开真身账号推导化身账号的衍生路径，另一部分是用户的未公开真身账号与可公开真身账号的之间的相对路径(之前已经提到，该相对路径可以为一个预先配置好的固定值)。由于利用未公开真身账号可以推导可公开真身账号，而可公开真身账号可以推导护照的化身账号，因此将两个路径拼接后得到的就是从未公开真身账号推导化身账号的衍生路径。例如，未公开真身账号的衍生路径(以HD钱包的根账号m为推导起点)是m/44'/0'/0'/0/0，可公开真身账号的衍生路径是m/44'/0'/0'/0/0/0/0，从可公开真身账号推导化身账号的衍生路径为/1，未公开真身账号和可公开真身账号之间的相对路径为0/0，拼接后(以相对路径为前缀拼接)即得到从未公开真身账号推导化身账号的衍生路径(即化身账号的总衍生路径)0/0/1。例如，可以将这两项信息拼接后计算校验码，获得的校验码即为护照的验根码。校验码的计算有多种方式，例如可以是循环冗余校验(Cyclic Redundancy Check，CRC)，或者可以对拼接后的信息进行哈希运算，取运算结果的前若干比特位作为校验码，等等。其中，由于很难在源头伪造字串碰撞出确定的结果哈希值，因此采用哈希运算计算验根码的方式具备较强的防伪造能力。
护照的时段类别以及护照的目标时间从护照申请请求中获取。护照的时段唯一码根据可公开真身账号的公钥以及护照的目标时间所在的时段进行计算，而护照的目标时间所在的时段根据护照的目标时间以及护照的时段类别进行计算。
例如，在一种实现方式中，计算护照的时段唯一码可以将可公开真身账号的公钥与护照的目标时间所在的时段这两项信息串接，形成一个字串，对该字串进行哈希摘要运算，所得哈希值就是时段唯一码，用公式可以表达如下：
LoginSession＝hash(OpenPublicKey+TimeSegment)
其中，OpenPublicKey为可公开真身账号的公钥，TimeSegment为护照的目标时间所在的时段(计算方式见下文)，hash表示哈希运算，+表示字串拼接。只要可公开真身账号与目标时间所在时段是确定的，取摘要所得时段唯一码也是确定的，可用作唯一性标识。
护照的时段类别反映时段的长度，例如，可以按周(7天)为一个时段，也可按半月(15天)，或一个月(31天)，或一季度(92天)等为一个时段。而护照的目标时间为一个时刻(终端设备的当前时间或应用网站指定的历史时间)，在一种计算方式中，可以将该时刻换算为以某个基准时刻(如1970年1月1日0时0分0秒)开始的秒数，然后除以护照的时段类别对应的单位时段的秒数，即可得到护照的目标时间所在的时段。例如，若7天为一个时段，则护照的目标时间所在的时段TimeSegment计算方式如下：
TimeSegment＝TIME/604800
这里的TIME即为护照的目标时间换算得到的描述，604800为7天对应的秒数，“/”运算符表示整除，结果值是整数。
护照的时段唯一码表征同一用户在某个时段内使用的某个确定的字串，用于作为一种唯一性标识。同一用户在同一时段(指护照的目标时间所在的时段)的以不同的化身账号申请的护照，其中的时段唯一码完全相同。但如果是不同的用户在同一时段内申请的护照，或者同一用户在不同时段内申请的护照，则护照中的时段唯一码不同。
护照的目标时间在取终端设备的当前时间时，表征管理网站颁发护照的时间，而护照的目标时间取某个应用网站指定的历史时间，其目的是限制同一个用户，无论申请多少份护照，只能获得一个时段唯一码。例如，该历史时间可以取应用网站上线的时间。
管理网站的标识由管理网站自行填充，例如，可以是管理网站给自己起的名字。用户的组可以统一取0或者其他固定值(关于用户的组在后文介绍步骤S4时阐述)。
护照的有效期可以由管理网站根据应用网站的要求自行填充，若护照的目标时间取终端设备的当前时间，则有效期与护照的目标时间形成了一个时段，在该时段中护照是有效的，时段的起点即管理网站颁发护照的时间，通过护照的目标时间表征，时段的长度则由有效期确定，有效期的形式可以是一段时长，也可以是一个时刻(该时段的截止时刻)。
关于护照中各信息项的用途，后文中用到时再具体说明。护照中可以只包含需要的信息项，其余的信息项完全不体现，或者护照也可以采用固定的格式，例如，每个可能包含的信息项都体现为一个对应的字段，如果需要用到某个信息项，则对应字段的值不为空，否则对应字段的值为空。管理网站生成护照后，将护照发送给终端设备。
继续参照图2，步骤S2可以包括：
步骤S20：终端设备向应用网站发送用户注册请求。
步骤S21：应用网站根据用户注册请求进行用户注册验证。
步骤S22：应用网站为用户分配资源标识绑定化身账号的公钥与资源标识。
步骤S23：应用网站向终端设备发送用户注册响应。
步骤S20至步骤S23结合在一起进行阐述。用户申请到护照后，向应用网站发送用户注册请求，并在用户注册请求中携带该护照。在一些实现方式中，用户还可以用步骤S1中推导的化身账号的私钥对用户注册请求进行签名，该化身账号应当与护照中的化身账号一致，签名的对象可以是用户注册请求中除该签名自身以外的内容。
用户申请护照和用户请求在应用网站注册可以是两个相对独立的过程，例如，用户先向管理网站申请了护照，待到要在应用网站注册时，将护照提交给应用网站。但也不排除在一些方案中，这两个过程是连续执行的，例如，应用网站的注册页面内置了一段代码逻辑，终端设备访问该页面后，会执行该代码逻辑：先去管理网站申请护照，然后将护照提交给应用网站进行注册，在这种方案中，用户可以不感知护照申请的过程，直接一键完成护照申请和发送注册请求，在操作上较为友好。
应用网站接收到终端设备发送用户注册请求后，利用用户注册请求进行注册验证，验证项目包括以下至少一项：
(1)验证护照中化身账号的公钥是否尚未绑定资源标识；
(2)利用管理网站的第一公钥验证对护照的签名是否正确；
(3)验证护照的时段唯一码是否不同于任一已注册的用户所使用的护照中的时段唯一码；
(4)利用护照中化身账号的公钥验证对用户注册请求的签名是否正确。
其中，第(1)项即验证该化身账号是否已经注册过了，因为只有注册过的化身账号才会绑定资源标识(具体见后文)，只有未注册过的化身账号才能注册。第(2)项即验证护照是否由管理网站颁发以及护照内容是否遭到篡改，管理网站的第一公钥携带在护照中。
第(3)项验证的前置条件是护照中包含时段唯一码，并且护照的目标时间为应用网站指定的历史时间，之前在解释护照的时段唯一码的定义时已经指出，由于护照的目标时被限制为特定的历史时间，因此同一个用户无论申请多少份护照都只能获得一个时段唯一码，从而，第(3)项即验证是否存在同一用户企图利用不同的化身账号多次进行注册，若存在这样的注册行为，则当前护照内的时段唯一码必然与一已注册的用户所使用的护照中的时段唯一码相同。是否要执行第(3)项验证取决于应用网站，一些应用网站允许同一用户注册多个账号，例如，某个应用网站只是一个以文字交流为主的论坛，允许同一用户注册多个账号也无关紧要。但一些应用网站不允许同一用户注册多个账号，例如，某个网站为注册的用户分配网盘空间，若某个用户注册多个账号，将导致其获得不合理数量的资源，增加网站运营成本。
第(4)项验证的前置条件是用户注册请求中包括利用用户的化身账号的私钥对请求的签名，而化身账号的公钥携带在护照中，第(4)项即验证用户是否确实拥有该化身账号以及请求内容是否遭到篡改。
若所有验证项目的结果均为“是”，则应用网站为用户分配一个资源标识，并绑定化身账号的公钥与该资源标识，该绑定关系可以存储于应用网站的数据库中，供用户登录时使用。下面简单介绍资源标识的概念：
应用网站为用户提供的服务，必然消耗网站资源，应用网站会为耗用的资源设立标识，称为资源标识(ResourceId)，资源标识与应用网站的注册用户一一对应，也即应用网站可以通过资源标识来识别不同的用户。依据资源标识，应用网站有能力对用户行为实施一定程度的数据挖掘，这属于正常现象，有了数据挖掘分析商家才能更好服务于客户。但本申请尝试将应用网站的数据挖掘行为限制在一定范围内，以防止其滥用，减少对用户隐私的侵犯(详见后文分析)。
除了绑定资源标识外，应用网站还可以保存护照或护照中的预设信息项，供后续步骤中使用。此外，应用网站还会向终端设备发送用户注册响应，告知用户注册成功。若某个验证项目的结果为“否”，则应用网站也可以向终端设备发送用户注册响应，告知用户注册网站失败，还可以进一步告知用户注册失败的原因。可以理解的，上述验证项目的验证顺序不作限定，并且如果某个验证项目验证失败，剩余尚未执行的验证项目可以不再执行。
现有技术中，用户在应用网站注册时，往往要输入用户名和密码，而在本申请中，由于护照内已经包含了用户的身份信息(化身账号的公钥)，因此直接向应用网站提交护照即可进行注册，是一种完全不同的注册方式，并且在用户操作上也更为简单。
继续参照图2，步骤S3可以包括：
步骤S30：终端设备向应用网站发送第一用户登录请求。
步骤S31：应用网站根据第一用户登录请求进行用户登录验证。
步骤S32：应用网站向终端设备发送用户登录响应。
步骤S30至步骤S32结合在一起进行阐述。用户使用护照注册应用网站成功后，向应用网站发送第一用户登录请求，并在第一用户登录请求中携带该护照。在一些实现方式中，用户还可以使用步骤S1中推导的化身账号的私钥对第一用户登录请求进行签名，该化身账号应当与护照中的化身账号一致，签名的对象可以是第一用户登录请求中除该签名自身以外的内容。
应用网站接收到终端设备发送第一用户登录请求后，利用第一用户登录请求进行登录验证，验证项目包括以下至少一项：
(1)验证护照中化身账号的公钥是否已经绑定资源标识；
(2)利用管理网站的第一公钥验证对护照的签名是否正确；
(3)获取应用网站的当前时间，验证应用网站的当前时间与护照的目标时间之间的间隔是否小于第二预设时间间隔；
(4)获取应用网站的当前时间，验证应用网站的当前时间是否处于由护照的有效期以及护照的目标时间所指定的时段内；
(5)利用护照中化身账号的公钥验证对第一用户登录请求的签名是否正确；
(6)验证护照的时段唯一码是否不同于任一已登录的用户所使用的护照中的时段唯一码。
其中，第(1)项即验证该化身账号是否已经注册过了，因为只有注册过的化身账号才会绑定资源标识，未注册过的化身账号不应允许其登录。第(2)项即验证护照是否由管理网站颁发以及护照内容是否遭到篡改，管理网站的第一公钥携带在护照中。
要执行第(3)项验证的前置条件是护照中包括目标时间，并且护照的目标时间为终端设备的当前时间，第(3)项即验证护照是否过期，前文已经提到，护照的目标时间在取终端设备的当前时间时，表征管理网站颁发护照的时间，若护照颁发后未及时使用(护照的目标时间与应用网站的当前时间之间的间隔是不小于第二预设时间间隔)，则护照已经过期，不应允许用户继续使用其进行登录，以保证安全性。第二预设时间间隔的具体取值不作限定，例如，可以是1小时、1天等。
要执行第(4)项验证的前置条件是护照中包括目标时间以及有效期，并且护照的目标时间为终端设备的当前时间，第(4)项即验证护照是否过期，若护照颁发后未及时使用(应用网站的当前时间已经不在护照的目标时间和有效期所确定的时段内)，则护照已经过期，不应允许用户继续使用其进行登录，以保证安全性。有效期的具体取值不作限定，例如，可以是1小时、1天等。在实践中，由于护照的效力依赖于应用网站的认可，所以也存在应用网站并不按照护照中的有效期进行验证的可能，例如，虽然护照中的有效期为1天，但应用网站只认可护照在颁发后的1小时内有效。
若希望对护照是否过期进行验证，在实施方案时选择(3)(4)之一实现即可。此外，还需要指出，在使用护照注册时也可以验证护照是否过期，上文中省略未写。
第(5)项验证的前置条件是第一用户登录请求中包括利用用户的化身账号的私钥对请求的签名，化身账号的公钥携带在护照中，第(5)项即验证用户是否确实拥有该化身账号以及请求内容是否遭到篡改。
第(6)项验证的前置条件是护照中包含时段唯一码，根据时段唯一码的计算方式，同一用户在同一时段(指护照的目标时间所在的时段)的以不同的化身账号申请的护照，其中的时段唯一码完全相同。但如果是不同的用户在同一时段内申请的护照，或者同一用户在不同时段内申请的护照，则护照中的时段唯一码不同。从而，第(6)项即验证是否存在同一用户企图利用在同一时段内以不同的化身账号申请的护照进行登录，若存这样的行为，则当前护照内的时段唯一码必然与一已登录的用户所使用的护照中的时段唯一码相同。是否要执行第(6)项验证取决于应用网站，例如，某些应用网站会为登录用户分配具有一定价值的资源(例如，存储资源、计算资源、积分奖励等)，若一个用户通过大量的化身账号登录，将导致严重的资源分配失衡，甚至影响网站的正常运营，因此这些应用网站可以执行第(6)项验证。进一步的，这些应用网站可以要求用户在申请护照时将护照的目标时间指定为一个历史时间，这样就能更严格地限制一个用户只能通过一个化身账号登录应用网站，确保资源分配的公平性。
若所有验证项目的结果均为“是”，则应用网站向终端设备发送用户登录响应，告知用户登录成功，若(1)至(5)中任意一个验证项目的结果为“否”，则应用网站也可以向终端设备发送用户登录响应，告知用户登录网站失败，还可以进一步告知用户登录失败的原因。可以理解的，验证项目(1)至(5)的验证顺序不作限定，并且如果某个验证项目验证失败，剩余尚未执行的验证项目(如果有(6)，也包括(6))可以不再执行。
对于(6)稍微特殊一些，若其验证结果为“否”，并且此时其余验证项目的结果均为“是”，则有两种处理方式：一种是使(6)中提到的已登录的用户登录的账号退出登录，并使当前护照中的化身账号成为该已登录的用户新的登录账号，此时由于当前的护照登录成功了，所以应用网站可以向终端设备发送登录成功的响应；另一种是维持已登录的用户登录的账号继续处于登录状态，而拒绝当前护照中的化身账号进行登录，此时由于当前的护照登录失败了，所以应用网站可以向终端设备发送登录失败的响应。两种方式择一执行即可，总之，都是保证同一用户的两个时段唯一码相同的护照中的化身账号不能同时登录。可以理解的，验证项目(6)可以在验证项目(1)至(5)的任意一项之前或之后执行。
需要指出，执行步骤S3只是用户登录的主流情况，即用户凭护照注册成功后的一段时间，又凭该护照登录注册过的应用网站，这也是用户登录的主流情况。当然，不排除一些应用网站在用户注册成功后直接将其标记为已登录，这种情况只是步骤S3的简化版本，不再单独阐述。
现有技术中，用户在应用网站登录时，往往要输入用户名和密码，而在本申请中，由于护照内已经包含了用户的身份信息(化身账号的公钥)，因此直接向应用网站提交护照即可进行登录，是一种完全不同的登录方式，并且在用户操作上也更为简单。
下面分析一下图1、图2的方案中有关安全隔离和隐私隔离的问题。
首先，允许用户针对不同的应用网站，从可公开真身账号推导不同的化身账号，并用这些化身账号申请不同的护照分别用于在这些应用网站注册以及登录，在某个应用网站注册或登录时，可以动用相应的化身账号的私钥对注册或登录的请求进行签名。也就是说同一用户访问不同的应用网站，采用不同的身份，动用不同的私钥，如果在访问某个应用网站时不慎暴露了账号的私钥，不会扩散到其他登录点，这就是一种安全隔离。但需要指出，以上做法在某些实现方式中并不是强制性的，例如，在这些实现方式中，若用户非要用一个护照在多个应用网站进行注册，也不限制这种行为。
其次，护照在用于访问各应用网站时，可将其有效期限定为较短的一段时间(无论是否在护照中加入有效期信息都可以实现该限定，具体见上文步骤S3)，这样即使在访问某个应用网站时不慎暴露了账号的私钥，也因为护照会很快过期，造成的影响有限，同样是一种安全隔离。
在上面的方法中，先从管理网站申请护照(步骤S1)，然后将护照用于注册以及登录应用网站(步骤S2和步骤S3)，即总体上看分为两个阶段，这样的实现方式有助于实现隐私隔离。在第一个阶段，管理网站虽然能够获知护照申请的用户的真实身份，但无法获知用户具体将如何使用护照，因为护照中没有包含和应用网站有关的信息；而在第二个阶段，应用网站虽然能够获知用户通过某个化身账号进行了注册或登录，但由于护照中并没有包括可公开真身账号的信息，所以应用网站无法获知护照的真正拥有者。这样，前后两个阶段没有明显的关联，他人无法跟踪特定用户的上网行为，从而可以保护用户隐私。
进一步的，在一些实现方式中，如果针对各网站(包括管理网站和应用网站)的操作都在浏览器中进行，还可以要求各网站在相关的html网页文件(例如和注册、登录相关的)的head段添加如下meta配置：
<meta name＝"referrer"content＝"never">
该配置指示浏览器不再向网站传递referrer引用页的URL信息，从而隔断前后次访问的网址之间的关联关系。若不设置，则网站可以通过document.referer获取到用户上一个访问页面的URL(缺省情况下浏览器会向网站传递该信息)，这样，网站一方可能利用该关系分析用户的行为特征，导致用户隐私暴露。例如，某个应用网站发现用户刚刚访问了管理网站，之后立刻访问本网站，如果将用户的两个动作关联，应用网站很可能推测出用户上一步在干什么(例如在申请护照)，进而应用网站可能分析护照中的化身账号和用户的真实身份之间的某种联系。
在介绍图4之前，先介绍TEE、TEE设备以及借助区块链实现的分布式安全服务。
TEE通常不独立工作，而是配置于某个电子设备(本申请中称为TEE设备)上，提供与设备上的富操作系统(RichOperatingSystem，RichOS，例如Android等)并存的运行环境，以实现特定的功能。TEE具有其自身的执行空间，其所能访问的软硬件资源是与RichOS分离的。TEE不仅提供了可信应用的安全执行环境，同时也保护可信应用的资源和数据的保密性，完整性和访问权限。为了保证TEE本身的可信根，TEE在安全启动过程中是要通过验证并且与RichOS隔离的。在TEE中，每个可信应用是相互独立的，而且不能在未授权的情况下不能互相访问。
实现TEE可以采用，但不限于如下两种方式：
其一，借助特定CPU芯片提供的安全防护能力，比如IntelSGX、ARMTrustZone等，构造一个可信执行环境。为了保障安全强度，还可以在可信执行环境底层增加可信硬件支持，比如采用符合可信平台模块(TrustedPlatformModule，TPM)标准的安全芯片，或采用符合可信密码模块(TrustedCryptographyModule，TCM)标准的安全芯片。
其二，采用加密锁(俗称软件狗)实现可信执行环境。常见的软件狗常包装成一个通用串行总线(UniversalSerialBus，USB)设备，软件狗内既提供文件存贮，也支持运行经过定制的程序。采用软件狗，可以不必限定设备的设备类型，只要设备有USB接口即可连接TEE，降低了对设备的软硬件要求。
TEE外部要使用TEE的功能，或者获取TEE中存储的数据，必须通过调用TEE提供的对外接口的方式，例如应用编程接口(Application Programming Interface，API)。
无论是设备本身的芯片就支持TEE(例如上面第一种方式)，还是通过连接软件狗实现了TEE，或者其他方式均可用于本申请。并且，由于在TEE设备上既有Rich OS又有TEE，为了在阐述时对二者进行区分，约定：当提到TEE设备执行某项操作时，是指TEE设备上的Rich OS或其中的某个应用程序完成的操作，若是由TEE设备中的TEE完成的操作，则会直接指出该操作由TEE执行，而不会说该操作由TEE设备执行。
在本申请中，TEE实现的主要功能是对外安全服务，包括但不限于以下四项：生成单向密文密钥的服务、单向密文密钥转密的服务、凭授权卡生成用户卡的服务以及凭护照及授权卡生成用户卡的服务，其服务的对象包括但不限于终端设备以及应用网站，以下可以简称服务需求方。
TEE提供安全服务的方式是通过网络，既可以是普通的互联网也可以是一些特殊的网络，例如区块链网络。考虑到区块链网络具有去中心化、不可篡改、匿名性良好等优点，易于作为TEE提供安全服务的载体，因此在下面主要介绍借助区块链实现的分布式安全服务的实现方式，但需要再次强调的是，只要能够在TEE和服务需求方之间提供信息通道，服务需求方都可以向TEE请求安全服务，因此区块链网络并不是唯一的实现方式。
图3示出了借助区块链实现分布式安全服务的一种场景的示意图。参照图3，区块链网络中包括挖矿节点以及矿池节点，各矿工可以通过矿池节点接入到区块链网络中参与记账权竞争(俗称挖矿)，挖矿产生的区块可以在挖矿节点本地的区块链中进行记录本广播给其他挖矿节点，关于挖矿节点以及矿池节点的具体功能，可以参考现有数字货币系统(例如比特币系统)中的描述，这里不作具体阐述。此外，还需要指出，矿池节点和挖矿节点只是从节点功能上进行的定义，其实现形式有多种，例如，可以分为两个物理节点，也可以在同一个物理节点上实现。
矿池节点可以作为TEE接入到区块链网络并提供安全服务的服务接入点：例如，TEE设备可以和矿池节点之间建立通信连接从而实现远程接入，又例如，矿池节点提供多个USB接口，TEE若采用软件狗形式也可以直接在矿池节点本地接入。可以理解的，某些区块链网络的实现中可能不包含矿池节点，此时也可以将挖矿节点作为TEE服务接入点。
在区块链网络中，矿池节点或挖矿节点可以有很多个，从而TEE服务接入点也可以由很多个，这些接入点在区块链网络中呈分布式状态。服务需求方要请求TEE提供安全服务，也可以从TEE服务接入点接入到区块链网络中。服务需求方向TEE服务接入点请求服务，然后接入点的服务器选择一个在本接入点接入的TEE提供服务，选择的策略不作限定，例如，可以动态且随机地选择一个当前在线且空闲的TEE来提供服务，或者，根据某些预设负载均衡策略进行选择。如果接入点本地没有空闲的TEE，那么接入点的服务器也可以将请求转发给其他接入点。特别地，如果服务需求方同时也是服务提供方，例如，用户使用的终端设备上也配置有TEE(即该终端设备自身也是TEE设备)，则该终端设备也可以直接向自身配置的TEE请求安全服务，而不经过TEE服务接入点，除非其自身配置的TEE处于非空闲状态。
在一种实现方式中，借助于区块链的分布式计算特性，服务需求方有权自主决定要在哪个TEE服务接入点请求安全服务，并且在哪个接入点发起服务请求，也就在该接入点获取服务结果，此举有助于避免中心机构定向作恶。由于在同一个TEE服务接入点可能有多个服务需求方同时请求安全服务，但只有空闲的TEE才能提供安全服务，因此从服务请求发出到获得响应可能经过较长的时间(如几分钟)，因此在可选的方案中，可以将发起服务请求和获取服务结果实现为异步的，服务需求方向接入点的服务器发送完请求后，便可执行其他任务，不必等待服务器返回结果，服务器向TEE设备转发服务请求后，将TEE设备返回的服务结果收集并存储，服务需求方可以定期到服务器上查询是否已经获得服务结果，直至查询到结果或者超时。
在区块链网络中，TEE服务接入点承担调度与消息转发功能，在一种实现方式中，服务需求方向TEE服务接入点发送的服务请求可以利用TEE提供的第一公钥加密，TEE内部用第一私钥解密请求后再提供相应的服务，其中，TEE的第一公钥与第一私钥为一个公私钥对，表征TEE作为安全服务管理员的身份，例如，可以是RSA、ECC公私钥对等。并且，在请求内容中，还可以指定一个用于加密服务结果的密钥，TEE完成服务计算后，对返回的服务结果用此密钥进行对称加密并返回，因为发出的服务请求与返回的服务结果都是密文，因此TEE服务接入点或者其他人在承担调度与消息转发的过程中无法探知往来消息的内容。换一句话说，TEE为服务需求方提供安全服务以黑箱方式进行，非常安全。
上述TEE以黑箱方式提供安全服务还可解决服务提供的动力来源问题，分布式服务对提高公正性、安全性、稳定性有利，否则中心化服务容易助长中心机构作恶，也容易遭受单点攻击，而构造分布式服务的较好方式是提供经济利益让大家把自己的TEE分享出来，类似于区块链提供挖矿奖励给矿工。在黑箱方式下，在TEE之外的消息都是密文，难被伪造，也难被攻击，因此可以在TEE内增加服务调用次数的统计功能，定期或不定期地汇总发送给区块链运营方，或矿池运营方以换取相应报酬(其形式包括但不限于区块链上发行的数字货币、积分、实物奖励)，这样的报酬可以激励更多人贡献出自己的TEE作为安全服务的提供方。进一步的，从TEE中传出的调用次数统计信息可以用TEE持有的第一私钥签名，以确保信息的真实可信。此外，该统计信息也可以在区块链中记录，方便随时进行验证。
在某些区块链实现中，TEE除了可以提供安全服务外，还可以运行共识算法参与区块链网络中的记账权竞争，即作为矿工角色。在这些区块链的实现中TEE可以采用黑箱方式提供安全服务，不仅安全服务的请求使用TEE的第一公钥加密，而且竞争记账权的请求也使用TEE的第一公钥加密，这样在TEE解密请求之前无法区分请求类型，从而也就无法对服务请求进行筛选，即TEE只能对所有请求进行一视同仁的响应。反之，若在TEE之外能够区分请求类型，则可以对服务请求进行筛选，只对其中特定类型的请求进行响应，导致TEE的服务提供缺乏公平性。
例如，TEE设备在调用TEE提供的安全服务接口之前，已经分析出某个请求为安全服务请求，则可以将其过滤掉，不进行接口调用，其动机在于某些区块链实现中可能要求TEE无偿提供安全服务或者只收取少量的报酬，总之服务提供方获得的利益显著低于在区块链上利用TEE挖矿的利益，因此服务提供方可能希望TEE更多地用于响应竞争记账权的请求而非安全服务请求。采用上述黑盒方式则可以避免该问题。
对于TEE参与竞争记账权的情况，若TEE获得记账权，需要将凭证传出并记录到区块链上，此时，若TEE内部统计了服务调用次数，也可以随该凭证一同传出，之后可能作为获取服务奖励的依据。
下面先对TEE提供的生成单向密文密钥的服务以及单向密文密钥转密的服务进行介绍，至于凭授权卡生成用户卡的服务以及凭护照及授权卡生成用户卡的服务在后文介绍用户卡时再进行阐述。
应用网站为生成授权卡，需要获取单向密文密钥(其用途见后文关于步骤S4的阐述)，而TEE提供的安全服务中也包括生成单向密文密钥的服务，因此应用网站可以向TEE申请单向密文密钥。下面先介绍单向密文密钥的获取过程，再介绍单向密文密钥的含义。
应用网站在需要获取单向密文密钥时，向TEE设备发送密钥生成请求。当然，根据上文的阐述，密钥生成请求可以先发给TEE服务接入点，再由TEE服务接入点转发给TEE设备，不过为简单起见，后文在阐述时省略掉对请求转发过程的描述。
密钥生成请求包括第一命令字以及一个明文密钥。其中，第一命令字表示请求TEE提供生成单向密文密钥的服务，TEE以请求中携带的命令字区分不同目的的安全服务请求。根据上文的阐述，若某些实现方式中TEE以黑盒方式提供安全服务，密钥生成请求可以利用TEE的第一公钥加密，并且，在密钥生成请求中还可以包括第一结果加密密钥，第一结果加密密钥用于TEE对生成的单向密文密钥(即返回的服务结果)进行加密。
TEE设备接收到密钥生成请求后，可以调用TEE提供的安全服务接口，将请求传递给TEE，TEE可以针对所有的安全服务提供一个统一的接口，在TEE内部再去识别不同目的的请求，避免TEE设备识别请求目的。
TEE获得密钥生成请求后，根据其中的第一命令字确定要提供的是生成单向密文密钥的服务，然后便执行该项服务的内容：TEE利用特定密钥对密钥生成请求中的明文密钥进行加密，获得单向密文密钥，该特定密钥可以预先配置在TEE中。其中，如果密钥生成请求用TEE的第一公钥进行了加密，则TEE需要先用自身持有的第一私钥解密请求，然后再对请求内容进行解析。
执行完服务内容后，TEE将单向密文密钥作为安全服务接口调用的返回结果传递给TEE设备，TEE设备将单向密文密钥返回给应用网站，应用网站便获得了单向密文密钥。其中，如果密钥生成请求包含了第一结果加密密钥，则TEE在向TEE设备返回单向密文密钥之前，需要先对密钥进行对称加密，而应用网站在收到加密后的单向密文密钥之后，也需要利用第一结果加密密钥进行解密。
一方面，TEE生成单向密文密钥所用的特定密钥仅在TEE中使用，不会泄露到TEE之外，另一方面，TEE只对外提供将明文密钥加密为单向密文密钥的服务，但不对外提供将单向密文密钥解密回明文密钥的服务。由于加解密能力的不对称，因此将这类密钥称为“单向密文密钥”。单向密文密钥在TEE之外无法被解密，但在TEE之内处于某些特定目的可以临时解密回明文密钥，但绝不会向TEE之外提供任何解密单向密文密钥的能力，也不会将临时解密得到的明文密钥向TEE之外传递。
单向密文密钥具有非对称转换信息的效果，获得单向密文密钥的一方可以放心地将其提供给他人使用，他人亦无法通过单向密文密钥反推明文密钥，至多将单向密文密钥传递给TEE进行某些特定目的的操作，但即使TEE会临时解密单向密文密钥，也不会将明文密钥传递到TEE之外，所以外部并无法获取到明文密钥。
TEE在生成单向密文密钥后，可以将其适当转换形式，便于密钥的输入和使用，例如，可以对单向密文密钥进行Base64编码，将其转化为由可打印字符构成的字串。
TEE还提供单向密文密钥转密的服务，用于获得单向密文密钥的一方验证单向密文密钥是否能够正常工作。例如，应用网站在获得单向密文密钥后，可以利用单向密文密钥对应的明文密钥对一个原始明文进行加密，获得其对应的原始密文。然后，应用网站向TEE设备发送转密请求，转密请求包括第二命令字、一个转密密钥、单向密文密钥以及上述原始密文。其中，第二命令字表示请求TEE提供单向密文密钥转密的服务。
TEE获得转密请求后，根据其中的第二命令字确定要提供的是单向密文密钥转密的服务，然后便执行该项服务的内容：TEE利用首先特定密钥对单向密文密钥进行解密，获得明文密钥，然后利用明文密钥对原始密文进行解密，获得其对应的原始明文，最后利用转密请求中的转密密钥对原始明文进行加密，获得校验密文。可见，这一过程是将原始明文从一种密文态转化为另一种密文态，因此也称为转密。其中，如果转密请求用TEE的第一公钥进行了加密，则TEE需要先用自身持有的第一私钥解密请求，然后再对请求内容进行解析。
执行完服务内容后，TEE将校验密文作为安全服务接口调用的返回结果传递给TEE设备，TEE设备将校验密文返回给应用网站，应用网站获取到校验密文后，首先利用转密密钥对校验密文进行解密，获得校验明文，然后判断原始明文与校验明文是否相同，若相同则表明单向密文密钥能够正常工作，否则表明单向密文密钥未能正常工作，其实质也就是判断单向密文密钥对应的明文密钥能否正常加解密。
需要指出，由于单向密文密钥转密的服务的返回结果本来就是密文态的，不必担心内容暴露，所以转密请求中也可以不携带用于加密服务返回结果的密钥，但在实践中，为了方便统一处理，例如，所有的服务请求都包括固定的字段，在转密请求中通过该字段携带用于加密服务返回结果的密钥也是可以的，此时TEE也可以进行统一处理，利用该密钥对校验密文再次加密。
根据前文所述，在一些实现方式中，TEE还可以统计生成单向密文密钥的服务和/或单向密文密钥转密的服务被调用的次数，并在适当的时候将统计结果传出，作为服务提供方获得奖励的依据。
有了以上内容作为基础，下面可以继续介绍图4，图4示出了本申请实施例提供的一种用户卡的申请和使用方法的示意图。参照图4，该方法涉及以下几个参与方：终端设备、TEE设备以及应用网站，这几个参与方在前文已经介绍，不再重复。
本申请提供两种访问应用网站的方式，分别是通过护照注册或登录应用网站，以及，通过用户卡登录应用网站。前一种方式前文已经介绍，在该方式中可以只使用护照完全不涉及用户卡。在后一种方式中，护照和用户卡都会使用，由于用户卡由TEE通过提供安全服务的方式颁发(见后关于文步骤S5的阐述)，因此具有较高的安全性(还可以进一步借助区块链提供分布式安全服务，进一步提高安全性)，因此，在对安全性要求较高的场合，应用网站可以要求用户以通过用户卡方式登录为主，虽然护照仍有其存在价值，但被限制用于两种用途：其一是在应用网站注册(前文关于步骤S2的阐述)；其二是在应用网站登录后申请授权卡(见后关于文步骤S4的阐述)，而凭护照登录后的其他操作受限或者完全禁止(如果要进行其他操作，则可凭用户卡重新登录后再操作)。图4示出的步骤包括：
步骤S0：用户通过终端设备在管理网站注册可公开真身账号，管理网站对用户做实名认证。
步骤S1：用户通过终端设备向管理网站申请护照，管理网站验证无误后，向用户颁发护照。
步骤S2：用户通过终端设备凭护照在应用网站注册，应用网站验证无误后，为用户注册账号。
步骤S3：用户通过终端设备凭护照登录应用网站，应用网站验证无误后，允许用户登录账号。
图4的步骤S0至步骤S3和图1的步骤S0至步骤S3基本相同，因此不再重复阐述，只需要对护照的验根码作一点说明：如果采用图1的方案(只使用护照访问应用网站)，则步骤S1中可以不需要计算护照的验根码，甚至护照中也可以不包含该信息项，因为图1的方案不涉及同属验证(同属验证的具体含义见后文)；如果采用图4的方案(使用护照和用户卡访问应用网站)，则在某些同属验证的实现方式中可能需要计算护照的验根码，计算方式可以采用在介绍步骤S1时给出的方式，在介绍步骤S1时顺带阐述护照验根码的计算主要是为了简便起见。
步骤S4：用户凭护照登录应用网站后，向应用网站申请授权卡，应用网站向用户颁发授权卡。
在本申请的方案中，申请用户卡包括两个阶段，第一个阶段是用户向应用网站申请授权卡，第二个阶段是用户凭授权卡(以及一些其他信息)向TEE申请用户卡。授权卡是一种可验证凭证，即用户向TEE申请用户卡的凭证，授权卡中包含授权相关的信息，应用网站以一个公私钥对表达自己的身份，并用私钥对授权卡中的信息签名，表示对被签信息的认可或者说授权，其公钥则可被各方用于验证签名的真实性。
登录的用户既可以为自己申请授权卡(即为了自己后续使用凭该授权卡申请的用户卡登录应用网站)，也可以为他人申请授权卡(即为了他人后续使用凭该授权卡申请的用户卡登录应用网站)，前一种方式即前文在分析本申请解决的几个关键问题时提到的所谓授权，后一种方式即前文提到的所谓转授权。这里的自己或他人，也即授权的对象，在后文的很多场合称为目标用户。
步骤S5：用户通过终端设备向TEE设备上配置的申请用户卡，TEE验证无误后，向用户颁发用户卡。
拿到用户卡就相当于获得一个由TEE认可的身份，该身份属于目标用户并定向用于授权卡限定的应用网站，若借助于区块链实现用户卡的申请和颁发，这样的身份也可以称为链上身份，即被区块链系统承认的身份。需要指出，申请授权卡和申请用户卡的均可由当前登录的用户完成，无论用户卡最终是给用户自己还是他人使用。
在一些实现方式中，授权卡可以长期甚至永久有效，即在授权对象相同、授权范围不变的情况下，步骤S4可以只执行很少的次数甚至只执行一次，而步骤S5则可以多次重复执行，例如在用户希望以不同的化身账号登录不同的应用网站时。
步骤S6：目标用户通过终端设备登录应用网站，应用网站验证无误后，允许目标用户登录账号。
步骤S7：用户凭用户卡登录应用网站后，向应用网站申请授权卡，应用网站向目标用户颁发授权卡。
步骤S7与步骤S4类似，即无论用户通过护照还是用户卡登录，都可以申请授权卡。同时，对于本来就是转授权的目标用户，多数情况下不允许其再向他人授权(即不允许其申请授权卡)，因此可以认为步骤S7中的用户和步骤S4中的用户是同一用户，所以在步骤S7中未采用目标用户的说法。
下面结合图4对步骤S4至步骤S7作进一步介绍，参照图4，步骤S4可以包括：
步骤S40：终端设备向应用网站发送授权卡申请请求。
步骤S41：应用网站根据授权卡申请请求进行授权卡申请验证。
步骤S42：应用网站生成授权卡。
步骤S43：应用网站向终端设备发送授权卡。
步骤S40至步骤S43结合在一起进行阐述。在用户已凭护照登录应用网站的情况下，可以通过终端设备向应用网站发送授权卡申请请求。授权卡申请请求至少包括目标账号的标识，目标账号即目标用户拥有的账号，目标用户后续使用用户卡登录应用网站时，用户卡中记录该目标账号的公钥，并且登录的也是该目标账号。
在本申请的方案中，该目标账号表征目标用户的自主身份，其具体形式可以是一个公私钥对：对于目标用户是申请授权卡的用户自身的情况，目标账号可以是从目标用户的未公开真身账号衍生出的一个化身账号；对于目标用户不是申请授权卡的用户自身的情况，目标账号可以由目标用户提供给申请授权卡的用户，例如可以是目标用户的一个化身账号，但实际上此时申请授权卡的用户可以不必关心目标账号的产生途径。
目标账号的标识既包含了目标账号的信息同时通过该标识还能够区分用户申请授权卡是为了授权给用户自己还是他人。
例如，在第一种实现方式中，目标账号的标识或者取从用户的未公开真身账号推导目标账号的衍生路径，或者取目标账号的公钥，若为路径表示授权给自己，若为公钥表示授权给他人。需要指出，若目标账号的标识为衍生路径，并不表示此时要先从用户的未公开真身账号推导出目标账号后才能发起授权卡申请，账号的推导可以在申请用户卡时再进行(具体见后文对步骤S5的阐述)。
又例如，在第二种实现方式中，目标账号的标识或者取空字串，或者取目标账号的公钥，若为空字串表示授权给自己，若为公钥表示授权给他。在一些方案中，应用网站颁发授权卡时(非转授权的情况)并不需要知道具体的目标账号，但要知道申请的授权卡是给用户自己还是他人使用，因此传递空字串不影响授权卡的申请，反而有利于减少用户隐私的泄露。
当然，第一种实现方式和第二种实现方式也可以融合在一起，例如，授权卡申请请求中包括目标账号的标识这个固定字段，既可以填入衍生路径，也可以填入空字串，还可以填入公钥，若填入的是前两者中的任意一个，都认为是授权给用户自己，若填入的是第三者则认为是授权给他人。
又例如，在第三种实现方式中，目标账号的标识可以分为两个部分，第一部份为目标账号的公钥，若授权给自己，即为从用户的未公开真身账号推导出的化身账号的公钥，若授权给他人，则为目标用户提供的一个账号公钥，由于两种情况下第一部分都取公钥，因此仅通过第一部分并无法区分是授权给自己还是他人。另一个部分则为区分标志，可以取两个不同的值，比如取0表示授权给自己，取1表示授权给他人。
当然目标账号的标识还有很多种实现方式，这里不再一一例举。
根据需求，授权卡申请请求中还可以包括以下信息中的一项或多项：授权卡的时段类别、授权卡的目标时间、授权卡的有效期、目标用户的组以及目标用户的任务。若执行顺利，以上五项信息(如果有的话)会记录到授权卡，并最终记录到用户卡中，因此这些信息可以视为表征了用户希望获得的权利范围，例如，授权卡的有效期表达希望获得的用户卡的有效期，目标用户的组表达希望目标用户获得的分组，等等，其具体用途在后文阐述。授权卡申请请求中可以只包含需要的信息项，其余的信息项完全不体现，或者授权卡申请请求也可以采用固定的格式，例如，每个可能包含的信息项都体现为一个对应的字段，如果需要用到某个信息项，则对应字段的值不为空，否则对应字段的值为空。
其中，目标用户的组用于标记目标用户在应用网站被授予的等级，以及，标记目标用户为申请授权卡的用户自身或他人。目标用户的任务用于描述目标用户在应用网站上被授权执行的事项。组和任务都是应用网站赋予用户的属性，下面简单介绍一下二者的概念：
应用网站基于资源(比如计算资源、存储资源等)对外提供服务，经常要划分服务等级，提供的服务越好可能需要用户需支付的报酬也越高，划分服务等级也意味着对用户进行了分组(因为每个用户都有自己从属的等级)。但划分服务等级的行为本身又容易让应用网站锁定特定用户，实施数据挖掘，进而容易侵犯用户隐私。比如，考虑一种极端情况，不限制应用网站划分服务等级的数量，假设应用网站用4字节无符号整数对用户分组，则理论上可以有约42亿个组，以至于应用网站可以给每个用户分配唯一的组，这样不管用户用什么账号登录，都能通过分组信息对用户实施精确锁定，从而实现精准的数据挖掘分析。
因此，在本申请的方案中，可以对应用网站提出一定的要求，限制其划分服务等级的最大数量，例如只能用1字节无符号整数对用户分组，即每个用户对应存储1字节的分组信息表明其所属的服务等级，最多256组(取值0～255)，防止用户隐私信息被过度挖掘。
分组信息还可以用于区分某个用户是授权用户还是转授权用户，例如，若1字节的分组信息的最高位置0，表明该用户是授权用户(取值0～127)，最高位置1，表明该用户是转授权用户(取值128～255)。或者，也可以视为前128个分组是属于授权用户的，后128个分组是属于转授权用户的。
授权卡申请请求中，目标用户的组这一信息项即可按照上面对分组信息的描述进行填充。
多数情况下，任务是和组绑定在一起使用的，因为不同分组的用户，其被应用网站允许执行的事项也不同。
例如，某个用户是授权用户，则可以对自己在应用网站上的网盘空间进行读写，某个用户是转授权用户，则只能对网盘空间中的指定目录进行读取(比如用户A将自己网盘的使用权限授予用户B，允许其下载其中的特定文件，但不允许其进行其他操作)。当然，对于不同的授权用户，其分组也可能不同，比如普通的授权用户网盘下载限速为200k/s，VIP用户网盘下载限速为10M/s。
授权卡申请请求中，目标用户的任务这一信息项可填充应用网站允许目标用户执行的事项的描述信息，例如，可以是事项的文字描述，或者，也可以是事项的代码，应用网站可以根据该代码获知目标用户能够执行的操作。若目标用户是申请授权卡的用户自身，一般来说，用户不会主动缩小自己的权限，将自己限制到只能执行某些特定操作，因此此时目标用户的任务可强制填入空字串，表明不作限定，或者说，拥有自己当前所处用户等级下的全部权限。此外，填入空字串还有助于避免泄露用户隐私。
下面再举一个例子，办理交通意外保险理赔时，司机在交管局网站(应用网站)应先注册账号，他授权保险公司代表(即转授权用户)可到交管局网站查阅与自身相关的某起交通事故的详情，或允许保险公司代表索要一份交通事故责任认定书(可以是一份可验凭证，格式可遵守W3C的Verifiable Credential规范)。在司机发起的授权卡申请请求中，目标用户的组指明保险公司代表只能以某个转授权用户的等级在交管局网站登录访问，目标用户的任务则指明授权卡只能在某个特定的任务(如交通事故理赔)中使用，一旦交管局网站根据司机的授权卡申请请求为司机颁发了授权卡，由目标用户的组和目标用户的任务所限定的授权范围将生效，保险公司代表可凭根据该授权卡进一步申请的用户卡登陆交管局网站，并执行其被赋予的有限的操作。
进一步的，在目标用户的任务这一信息项中，还可以附带必要参数，并按照预设的格式填充事项描述和这些参数，例如，事项和参数之间用冒号分隔，各参数之间用分号分隔，等等。比如，在任务“交通理赔:事故责任认定书”中，“交通理赔”为事项，“事故责任认定书”为参数。
用户的组和/或任务有可能发生改变，例如，某个用户本来是普通用户，后来升级为VIP用户，其等级得到提升，则必须为其申请新的授权卡，并在请求中填入新的分组信息。
在前文介绍步骤S1时提到，护照中也可以包含用户的组这项信息，其值可以统一取0或其他固定值，表明不对用户分组。当然若应用网站要对用户分组，在申请护照时也可以在请求中提交分组信息，但有时这样做并不必要，特别是在图4的场景中，首先，护照仅仅是给申请者自己使用，不存在转授权问题，因此不需要通过分组区分授权用户和转授权用户，其次，图4的某些实现方式中，护照的使用很可能受限(只用于注册和申请授权卡)，对这样有限的操作再区分用户等级意义不大。
应用网站接收到授权卡申请请求后，可以利用授权卡申请请求进行授权卡申请验证，验证的内容包括但不限于以下内容中的一项或多项：
(1)授权卡申请请求中包含目标账号的标识，根据该标识可以区分目标用户是申请授权卡的用户自身还是他人，其判断方法参考前文对目标账号的标识的描述。同时若授权卡申请请求中还包含目标用户的组这一信息项，通过目标用户的组也可以区分目标用户是申请授权卡的用户自身还是他人。应用网站可以验证二者的判断结果是否一致，一致则通过验证，否则不通过。
(2)若授权卡申请请求中包含目标用户的组、目标用户的任务两项信息，可以验证其格式是否符合要求，比如事项和参数之间、参数和参数之间是否采用了规定的分隔符。若符合要求则通过验证，否则不通过。
(3)若应用网站判断出申请授权卡是为了授权给自己，并且授权卡申请请求中还包含目标用户的任务这一信息项，则应用网站可以检查目标用户的任务是否为空字串，之前已经提到，在某些实现方式中，此种情况下会强制要求目标用户的任务必须取空字串，避免泄露用户隐私。若为空字串则通过验证，否则不通过。
(4)若授权卡申请请求中包含授权卡的目标时间、授权卡的有效期两项信息，应用网站可以验证两者设置是否合理，例如有效期不能设置过长以至于超出了应用网站的限定。若合理则通过验证，否则不通过。
若所有验证项目均通过，则应用网站可以组织若干信息项以生成授权卡。若某个验证项目未通过，则应用网站也可以告知用户申请授权卡失败，还可以进一步告知用户申请失败的原因。可以理解的，上述验证项目的验证顺序不作限定，并且如果某个验证项目未通过，剩余尚未执行的验证项目可以不再执行。
若验证过程中未进行区分目标用户为申请授权卡的用户自身或他人的操作，则可以先根据目标账号的标识判断要授权的目标用户为申请授权卡的用户自身或他人，然后再生成授权卡，因为授权卡中的一些信息项的生成和该判断结果有关。
授权卡中至少包括授权卡的属主账号的公钥、应用网站的公钥以及应用网站利用自身的私钥对授权卡的签名。根据需求，授权卡还可以包括以下信息中的一项或多项：授权卡的验根码、应用网站的标识、目标用户的组、应用网站的公钥、授权卡的时段类别、授权卡的目标时间、授权卡的有效期、应用网站分配给用户的资源标识、目标用户的任务以及授权卡的种密。
其中，若目标用户为申请授权卡的用户自身，则属主账号为用户当前通过护照登录的账号(若用户当前通过用户卡登录，见步骤S7)，由于申请授权卡时用户处于登录状态，应用网站必然可以获取该账号的公钥；若目标用户为他人，则授权卡的属主账号的公钥为目标账号的公钥，即此时授权卡申请请求中携带的目标账号的标识。
应用网站的公钥和私钥是一个公私钥对，表征应用网站的身份，例如，可以是RSA、ECC公私钥对等。其签名的对象可以是授权卡中除该签名自身以外的其他信息。应用网站的公钥也可以携带在授权卡中，用于签名验证。
若目标用户为申请授权卡的用户自身，则授权卡的验根码为用户当前登录时使用的护照中的验根码(若用户当前通过用户卡登录，见步骤S7)，之前已经提到，用户成功登录后，应用网站会保存护照或护照中预设的信息项，因此护照中的验根码应用网站可以获得；若目标用户为他人，则授权卡的验根码根据用户的可公开真身账号的公钥以及目标账号的公钥进行计算，例如，可以将以上两项信息拼接后计算校验码作为授权卡的验根码。
应用网站的标识由应用网站自行填充，例如，可以是应用网站给自己起的名字，应用网站分配给用户的资源标识是与用户登录的账号的公钥绑定的，应用网站可以获取。
授权卡的时段类别、授权卡的目标时间、授权卡的有效期、目标用户的组以及目标用户的任务从授权卡申请请求中获取。
在介绍授权卡的种密之前，先介绍安全码(Secret)的概念：
本申请中将应用网站对外授权提供服务的控制权概括为安全码，安全码可以是一个不对外公开的字串。简单而言，如果被服务者持有这个安全码，就表明他有权享受服务方提供的服务。比如企业X开发了一个微信小程序，并自己搭建一个供该小程序使用的后台服务器，服务器运行时会调用微信提供的一些资源，此时微信的后台和企业X的服务器之间可以约定用一个安全码，如果服务器持有安全码和微信后台保存的一致，则表明其拥有访问资源的权限。在实践中，直接传输或者让被服务者持有安全码容易泄密，所以可以对安全码做适当的形式转换(例如加密或者其他运算)。
在本申请中，为使授权过程更加便捷、安全，也引入了安全码机制。简单来说，在授权的种密信息项中包含了安全码的信息，而在根据授权卡申请用户卡时，安全码的信息又被融入至用户卡的时段唯一码中(见后文对步骤S5的阐述)，从而应用网站可以在用户通过用户卡登录时进行有关安全码的校验。
具体而言，授权卡的种密可以包括单向密文密钥以及安全码的密文。其中，安全码的密文是利用单向密文密钥对应的明文密钥加密安全码的明文获得的，而单向密文密钥由TEE提供安全服务生成，前文已经介绍。由于种密中的安全码是密文态，所以不必担心安全码泄露。根据单向密文密钥的定义，要向获得安全码的明文，必须将种密传递到TEE中，TEE首先解密单向密文密钥获得明文密钥，然后再利用该明文密钥解密种密中安全码的密文即可。由于TEE本身是一种安全环境，所以即使安全码的明文暴露在TEE中也不存在安全问题。在后文申请用户卡时，会将授权卡传递给TEE，种密也同时传递到TEE中。
关于授权卡中各信息项的用途，后文中用到时再具体说明。授权卡中可以只包含需要的信息项，其余的信息项完全不体现，或者授权卡也可以采用固定的格式，例如，每个可能包含的信息项都体现为一个对应的字段，如果需要用到某个信息项，则对应字段的值不为空，否则对应字段的值为空。应用网站生成授权卡后，将授权卡发送给终端设备，作为申请授权卡的用户向TEE设备上配置的TEE申请供目标用户使用的用户卡的凭证。
用户凭护照登录和用户申请护照可以是两个相对独立的过程，例如，用户先凭护照登录应用网站，待到需要用户卡时，才申请授权卡。但也不排除在一些方案中，这两个过程是连续执行的，例如，应用网站的登录页面内置了一段代码逻辑，终端设备访问该页面后，会执行该代码逻辑：将护照提交给应用网站进行登录，登陆后自动申请授权卡，用户可以不感知授权卡申请的过程，直接一键完成凭护照登录和申请授权卡，在操作上较为友好。
获得授权卡后，用户可以向TEE申请用于登录应用网站的用户卡，根据提交信息的不同，申请用户卡的步骤S5至少包括两种实现方式，在图4中分别示出，其中方式一是凭授权卡以及一些其他信息申请用户卡，方式是凭授权卡、护照以及一些其他信息申请用户卡，TEE也对应地提供两项安全服务，即凭授权卡生成用户卡的服务以及凭护照及授权卡生成用户卡的服务予以响应。具体过程如下：
申请用户卡的步骤S5的实现方式一可以包括：
步骤S50a：终端设备向TEE设备发送第一用户卡申请请求。
步骤S51a：TEE设备上配置的TEE根据第一用户卡申请请求提供凭授权卡生成用户卡的服务。
步骤S52a：TEE设备向终端设备发送用户卡。
步骤S50a至步骤S52a结合在一起进行阐述。在用户申请到授权卡后，用户可以通过终端设备向TEE设备发送第一用户卡申请请求。第一用户卡申请请求至少包括第三命令字、授权卡以及目标账号的标识。
其中，第三命令字表示请求TEE提供凭授权卡生成用户卡的服务。若用户卡针对的目标用户(也就是要使用用户卡登录应用网站的用户)为获得授权卡的用户(也就是申请用户卡的用户)自身，则在终端设备上从该用户的未公开真身账号推导一个化身账号作为目标用户的目标账号，推导方法前文已经阐述，同时，将推导该化身账号的衍生路径目标账号的标识；若用户卡针对的目标用户为他人，则将目标用户提供的目标账号的公钥作为目标账号的标识。
进一步的，若目标用户为获得授权卡的用户自身，则第一用户卡申请请求还包括未公开真身账号的公钥、未公开真身账号的链码以及授权卡的属主账号的衍生路径。授权卡的属主账号的衍生路径可以这样获得：
根据前文阐述可知，可公开真身账号可以由未公开真身账号推导产生，并且二者之间的相对路径是固定的，若用户在申请授权卡时通过护照方式登录，则授权卡的属主账号是从可公开真身账号推导而来的一个化身账号，从可公开真身账号推导该化身账号的衍生路径为一个以可公开真身账号为推导起点的衍生路径，将该衍生路径与两个真身账号之间的相对路径拼接后，可以转换为一个以未公开真身账号为推导起点的衍生路径，并将转换得到的路径确定为授权卡的属主账号的衍生路径。例如，未公开真身账号的衍生路径(以HD钱包的根账号m为推导起点)是m/44'/0'/0'/0/0，可公开真身账号的衍生路径是m/44'/0'/0'/0/0/0/0，从可公开真身账号推导属主账号的衍生路径为/3，未公开真身账号和可公开真身账号之间的相对路径为0/0，拼接后(以相对路径为前缀拼接)即得到从未公开真身账号推导属主账号的衍生路径(即授权卡的属主账号的衍生路径)0/0/3。若用户在申请授权卡时通过用户卡方式登录，计算授权卡的属主账号的衍生路径的方法在步骤S7中再介绍。
需要指出，授权卡的属主账号的衍生路径不一定在申请用户卡时才计算，例如，可以在用户申请护照成功后就进行计算并保存到终端设备本地的数据库中，申请用户卡时直接读取数据库中的历史记录即可。
根据需求，第一用户卡申请请求中还可以包括以下信息中的一项或多项：用户卡的目标时间以及第二结果加密密钥。
其中，用户卡的目标时间表征用户预期该用户卡被使用的时间，该信息项可以和授权卡中的目标时间取相同的值，因为授权卡中的目标时间最终也会被复制到用户卡中作为用户卡的目标时间(见后文)，所以二者本来就表达相同的含义。在第一用户卡申请请求中单独增设该信息项可以起到对授权卡中的目标时间的验证作用。需要指出，用户卡的目标时间或者授权卡的目标时间可以是一个精确的时刻，当然，并不要求用户卡要严格地在该时刻使用，例如，只要应用网站判断出该时刻和用户卡被实际使用的时刻在同一个时段内，都视为用户卡的使用时符合目标时间的要求。
关于第一用户卡申请请求中各信息项的用途，未提及的，后文中用到时再具体说明。第一用户卡申请请求中可以只包含需要的信息项，其余的信息项完全不体现，或者第一用户卡申请请求也可以采用固定的格式，例如，每个可能包含的信息项都体现为一个对应的字段，如果需要用到某个信息项，则对应字段的值不为空，否则对应字段的值为空。
根据上文的阐述，若某些实现方式中TEE以黑盒方式提供安全服务，第一用户卡申请请求可以利用TEE的第一公钥加密，并且，在密钥生成请求中还可以包括第二结果加密密钥，第二结果加密密钥用于TEE对生成的用户卡(即返回的服务结果)进行加密。
TEE设备接收到第一用户卡申请请求后，可以调用TEE提供的安全服务接口，将请求传递给TEE，TEE获得第一用户卡申请请求后，根据其中的第三命令字确定要提供的是凭授权卡生成用户卡的服务，然后便执行该项服务的内容：利用第一用户卡申请请求进行用户卡申请验证，若验证通过则生成用户卡。其中，如果第一用户卡申请请求用TEE的第一公钥进行了加密，则TEE需要先用自身持有的第一私钥解密请求，然后再对请求内容进行解析。
其中，用户卡申请验证的验证项目包括以下至少一项：
(1)TEE利用授权卡中的应用网站的公钥验证对授权卡的签名是否正确；
(2)TEE根据目标账号的标识判断目标用户为用户自身或他人，若目标用户为获得授权卡的用户自身，则TEE利用第一用户卡申请请求中携带的未公开真身账号的公钥、未公开真身账号的链码、目标账号的标识、授权卡、授权卡的属主账号的衍生路径验证授权卡的属主账号是否属于目标用户。
其中，第(1)项即验证授权卡是否是应用网站颁发的以及授权卡的内容是否遭到篡改。第(2)验证也可以称为同属验证，即验证授权卡的属主账号是否属目标用户，或者说，也就是为了验证获得授权卡的用户和目标用户是同一人这一判断结果是否真实可信。授权和转授权所获得的权限是不同的，前者由于还是同一个用户在操作(只是换了一个化身账号)，所以权限维持不变，后者权限则很可能降低，同属验证的目的主要是为了确保权限分配的准确性。需要指出，若目标用户不是获得授权卡的用户自身，则不需要进行同属验证。
同属验证(2)有不同的实现方式，下面介绍其中的两种方式：
方式一
步骤A：TEE利用第一用户卡申请请求中携带的未公开真身账号的公钥、未公开真身账号的链码以及目标账号的标识三项信息推导目标账号的公钥，由于已经判断为同属验证场景，所以此时目标账号的标识为从未公开真身账号推导目标账号的衍生路径。目标账号的公钥将会被记录在后续步骤生成的用户卡中。
步骤B：TEE利用未公开真身账号的公钥、未公开真身账号的链码以及授权卡的属主账号的衍生路径推导校验账号的公钥，根据上文对授权卡的属主账号的衍生路径的定义，该路径是一个以未公开真身账号为推导起点的路径，所以以上推导是可行的。
步骤C：TEE判断校验账号的公钥与授权卡的属主账号的公钥是否相同，若相同则说明授权卡的属主账号可以由未公开真身账号推导。根据步骤A，用户卡上要记录的目标账号的公钥是由未公开真身账号的公钥推导产生的，说明未公开真身账号是属于目标用户的，所以一旦确定未公开真身账号的公钥能够推导授权卡的属主账号的公钥，必然表明授权卡的属主账号也属于即将生成的用户卡针对的目标用户，同时也是获得授权卡的用户。若不相同则说明授权卡的属主账号不属于目标用户。
方式二：
步骤A：TEE利用未公开真身账号的公钥、未公开真身账号的链码以及目标账号的标识推导目标账号的公钥。方式二的步骤A类似方式一的步骤A，不再重复。
步骤B：TEE利用未公开真身账号的公钥、未公开真身账号的链码以及预先配置于TEE中的相对路径推导可公开真身账号的公钥。该相对路径是指从未公开真身账号推导可公开真身账号的衍生路径，上文已经指出，该相对路径可以是一个固定的路径，因此可以预先配置好。
步骤C：TEE根据可公开真身账号的公钥以及授权卡的属主账号的衍生路径计算第一校验验根码。例如，可以将以上两项信息拼接后计算校验码作为第一校验验根码。
步骤D：TEE判断第一校验验根码与授权卡的验根码是否相同。根据前文阐述，在目标用户为获得授权卡的用户自身时，授权卡的验根码为用户登录时使用的护照中的验根码(若用户通过用户卡登录，具体见步骤S7)，而护照中的验根码是根据用户的可公开真身账号的公钥以及化身账号的总衍生路径进行计算，根据前文的定义，化身账号的总衍生路径就是从未公开真身账号推导化身账号的衍生路径，对比步骤C中第一校验验根码的计算方式(要保证两个验根码的计算方式完全一致)，如果两个验根码相同，则表明授权卡的属主账号可从与可公开真身账号对应的未公开真身账号推导产生，两者推导的源头是相同的未公开真身账号，而根据步骤A，用户卡上要记录的目标账号的公钥是由该未公开真身账号的公钥推导产生的，说明用户卡上要记录的目标账号与授权卡的属主账号属于同一真实用户，或者说证明了授权卡的属主账号属于即将生成的用户卡针对的目标用户。反之如果两个验根码不同，则证明目标账号与授权卡的属主账号不属于同一真实用户，或者说证明了授权卡的属主账号不属于即将生成的用户卡针对的目标用户。
若所有验证项目的结果均为“是”，则TEE组织若干信息项以生成用户卡，并将用户卡作为安全服务接口调用的返回结果传递给TEE设备，TEE设备将用户卡返回给终端设备，用户便获得了用户卡，用户卡是一种可验凭证，用于证明应用网站已经授权目标用户通过登录用户卡中记录的目标账号(见后文对用户卡的描述)使用应用网站提供的服务。如果是转授权的情况，用户可以将申请到的用户卡转发给目标用户，当然也可以要求TEE设备直接将用户卡发送给目标用户，或者可以告知目标用户在何处索取用户卡。其中，若第一用户卡申请请求中携带了第二结果加密密钥，则TEE返回的用户卡可以使用第二结果加密密钥进行加密。
若某个验证项目的结果为“否”，则TEE也可以告知用户申请用户卡失败，还可以进一步告知用户申请失败的原因。可以理解的，上述验证项目的验证顺序不作限定，并且如果某个验证项目验证失败，剩余尚未执行的验证项目可以不再执行。
用户卡中至少包括目标账号的公钥以及TEE利用自身的第二私钥对用户卡的签名。根据需求，用户卡还包括以下信息中的一项或多项：用户卡的验根码、应用网站的标识、目标用户的组、应用网站的公钥、用户卡的时段类别、用户卡的目标时间、用户卡的有效期、应用网站分配给用户的资源标识、目标用户的任务、用户卡的时段推导码以及用户卡的时段唯一码。
其中，若目标用户为获得授权卡的用户自身，则目标账号的公钥可以在执行上述第(2)项验证时推导，若目标用户为他人，则目标账号为第一用户卡申请请求中携带的目标账号的标识。
其中，TEE的第二公钥和第二私钥构成一个公私钥对，表征TEE作为用户卡颁发专员的身份，例如，可以是RSA、ECC公私钥对等。TEE的第二公钥和上文提到的TEE的第一公钥可以是同一个也可以不是同一个，相应地，TEE的第二私钥和上文提到的TEE的第二私钥可以是同一个也可以不是同一个。TEE的第二公钥可对外公开，任何人均有权获取，持有TEE的第二公钥便可以验证用户卡中的签名，以证实用户卡确实是由TEE颁发以及用户卡内容真实可信。用户卡中的签名，其签名的对象可以是用户卡中除该签名自身以外的其他信息。
用户卡的验根码根据用户的可公开真身账号的公钥以及第一用户卡申请请求中携带的目标账号的标识进行计算，可公开真身账号的公钥的如何推导在上述第(2)项验证的实现方式二的步骤B中已有介绍。
应用网站的标识、目标用户的组、应用网站的公钥、用户卡的时段类别、用户卡的目标时间、用户卡的有效期、应用网站分配给用户的资源标识以及目标用户的任务从第一用户卡申请请求中携带的授权卡中对应的信息项复制。例如，用户卡的时段类别复制自授权卡中的时段类别，等等。
用户卡的目标时间表征用户预期该用户卡被使用的时间，用户卡的有效期和用户卡的目标时间形成了一个时段，在该时段中用户卡是有效的，时段的起点即用户预期该用户卡被使用的时间，通过用户卡的目标时间表征，时段的长度则由有效期确定，有效期的形式可以是一段时长，也可以是一个时刻(该时段的截止时刻)。若超过了用户卡可以使用的时段(用户卡过期)，必须重新申请用户卡，为方便起见，用户可以一次性申请可供今后多个时段内使用的用户卡，用户卡的目标时间可以取未来的时刻，因此支持用户预备多个用户卡的操作。注意，上述时段的长度和用户卡的时段类别对应的单位时段的长度之间没有必然关系，但在一些实现方式中，若用户卡中未包含有效期信息，也可以默认用户卡的时段类别对应的单位时段就是用户卡的有效期长度。
应用网站分配给用户的资源标识用于定位资源，特别是转授权的情况，例如用户A转授权用户B访问其网盘空间，用户B使用的用户卡中携带应用网站分配给用户A的资源标识，用户B登录后，应用网站可凭该资源标识得到用户A的网盘目录，使得用户B可以在一定操作权限下访问该目录。
用户卡的时段推导码和用户卡的时段唯一码的计算有关(见后文对步骤S6的阐述)，这里先简单介绍其二者的计算方式。
用户卡的时段推导码可以根据用户的可公开真身账号的公钥、指定字串、用户卡的目标时间所在的时段、用户卡中应用网站的标识以及用户卡中目标用户的组进行计算，计算方式不限定，而用户卡的目标时间所在的时段又可以根据用户卡的目标时间以及用户卡的时段类别进行计算(具体计算方式其计算方式可参考前文护照的目标时间所在的时段)。
用户卡的时段唯一码可以根据应用网站提供的安全码、可公开真身账号的公钥以及上述指定字串进行计算。
可公开真身账号的公钥在前文中已经介绍过推导方式。应用网站的安全码从授权卡的种密中解密得到(获取方式见步骤S4中的阐述)，授权卡携带在第一用户卡申请请求中，种密可以从中获取。
例如，在一种实现方式中，指定字串nonce_string根据如下公式计算：
nonce_string＝TimeSegment+Domain+Group
用户卡的时段推导码TimeSession根据如下公式计算：
TimeSession＝hash(OpenPublicKey+nonce_string)^
hash(TimeSegment+Domain+Group)
用户卡的时段唯一码LoginSession根据如下公式计算：
LoginSession＝hash(Secret+hash(OpenPublicKey+nonce_string))
其中，TimeSegment为用户卡的目标时间所在的时段，TimeSegmnet根据用户卡的目标时间以及用户卡的时段类别进行计算，Domain为应用网站的标识、Group为目标用户的组，OpenPublicKey为可公开真身账号的公钥，hash表示哈希运算，+表示字串拼接，^表示异或运算(逐字节进行异或)。
上述实现方式中，TimeSession和LoginSession中都不包含Secret的明文，所以任何人都无法在TEE之外通过TimeSession和LoginSession反推Secret的明文，避免了Secret泄露到TEE之外。另外，在TimeSession和LoginSession的计算过程中，结合了OpenedPublicKey生成字串在计算哈希值，这样既锁定了用户的可公开真身账号(即使一个用户申请的多个用户卡中采用了不同的化身账号(目标账号)，该用户还是只有一个可公开真身账号)，同时又通过哈希变换实现了对用户的可公开真身账号的隔离，让他人无法确定用户卡上的化身账号和用户的可公开真身账号之间的对应关系，从而可以避免用户的身份暴露。
nonce_string用于计算哈希时“撒盐”，让TimeSession的计算结果更加不确定，这有助于防止伪造，尤其针对同一用户从用于其他应用网站的用户卡，取TimeSession字段反推进行破解。另外，nonce_string既然用作撒盐，在其他一些实现方式中改用其他确定值也是可以的。
当目标用户持有包含时段推导码和时段唯一码的用户卡登录应用网站时，应用网站会根据应用网站的安全码、用户卡的时段推导码、应用网站的当前时间所在的时段、应用网站的标识以及目标用户的组计算校验时段码，并验证校验时段码是否与用户卡的时段唯一码相同，计算校验时段码可以采用和计算用户卡的时段唯一码相同或实质相同的方式。而应用网站的当前时间所在的时段可以根据应用网站的当前时间以及用户卡的时段类别进行计算。
例如，如果对应于上面计算TimeSession和LoginSession的公式，则校验时段码LoginSessin’根据如下公式计算：
LoginSession’＝hash(Secret+
(hash(TimeSegment’+Domain+Group)^TimeSession))
其中，TimeSegment’为应用网站的当前时间所在的时段，TimeSegmnet’根据应用网站的当前时间以及用户卡的时段类别进行计算，Domain为用户卡中记录的应用网站的标识、Group为用户卡中记录的目标用户的组，TimeSession为用户卡记录的时段推导码，hash表示哈希运算，+表示字串拼接，^表示异或运算。
LoginSession’的计算方式和LoginSession的计算方式实质上是相同的，考虑应用网站的当前时间和用户卡的目标时间在同一个时段(可以是根据用户卡的时段类别计算得到的时段)内的情况，LoginSession’可以写作：
LoginSession’＝hash(Secret+
(hash(TimeSegment+Domain+Group)^TimeSession))
代入TimeSession的计算公式：
TimeSession＝hash(OpenPublicKey+nonce_string)^
hash(TimeSegment+Domain+Group)
得到：
LoginSession’＝hash(Secret+hash(OpenPublicKey+nonce_string))
这和LoginSession的计算公式相同，既然LoginSession’的计算方式和LoginSession的计算方式实质相同，将二者进行比较，以验证LoginSession是否被伪造是合理的。当然，即使用户卡中的LoginSession未被伪造二者也不一定相等，因为很可能TimeSegment’≠TimeSegment，例如用户卡的目标时间所在的时间段已经结束了，而目标用户还在用该用户卡登录，一样会因无法通过LoginSession的验证而被拒绝，此时用户可以重新申请用户卡。
上述过程中还隐含了对Secret的验证，若目标用户持有的Secret(指融入到LoginSession中的Secret)和应用网站本地的Secret不一致，必然导致LoginSession’和LoginSession计算结果不同，此时应用网站可拒绝用户登录。
用户卡的时段唯一码和护照的时段唯一码由于都包含可公开真身账号的公钥以及时段信息(用户卡的时段信息体现在指定字串中)，因此其基本功能和护照的时段唯一码也是类似的，可以用于应用网站防止同一用户在同一时段内以用户卡上的不同化身账号登陆。当然，用户卡的时段唯一码在计算时还结合了安全码、用户卡中应用网站的标识以及用户卡中目标用户的组，因此其在内涵上更加丰富，比如以上面的计算公式为例，按照上述公式计算LoginSession’至少实现了以下几个目的：
(1)计算结果和Secret有关，只要Secret未泄露，计算结果就无法仿冒；
(2)计算结果和Domain、Group有关，从而在不同的应用网站(Domain不同)，不同等级的用户(Group不同)之间实现了天然的隔离；
(3)计算结果和TimeSegment有关，不同的时段会影响LoginSession的计算(本条和护照类似)；
(4)计算结果和TimeSession有关，而TimeSession的计算又和用户的可公开真身账号有关，重用了针对相同用户的可公开真身账号的唯一性，使得应用网站在不用得知OpenPulicKey的情况下也可以计算LoginSession’。
上述各公式中的哈希运算也可以统一改为HMAC等摘要算法。比如，TEE中的公式可以改用：
LoginSession＝hmac(Secret,hash(OpenedPublicKey+nonce_string))应用网站中的公式可以改用：
LoginSession’＝hamc(Secret+
(hash(TimeSegment+Domain+Group)^TimeSession))
其中，hmac表示HMAC算法，其余内容表示的含义不变。
此外，上述各公式中的+所表示字串拼接是比较灵活的，并不一定要按照上面公式中的顺序进行拼接，例如，TimeSegment+Domain+Group也可以改用Domain+Group+TimeSegment，只要公式中各处的拼接顺序保持一致即可。此外，在拼接时还可以添加若干连字符，例如冒号、斜杠等，以便在调测场合更易阅读。
关于用户卡中各信息项的用途，未提及的，后文中用到时再具体说明。用户卡中可以只包含需要的信息项，其余的信息项完全不体现，或者用户卡也可以采用固定的格式，例如，每个可能包含的信息项都体现为一个对应的字段，如果需要用到某个信息项，则对应字段的值不为空，否则对应字段的值为空。
根据前文所述，在一些实现方式中，TEE还可以统计凭授权卡生成用户卡的服务被调用的次数，并在适当的时候将统计结果传出，作为服务提供方获得奖励的依据。
申请用户卡的步骤S5的实现方式二可以包括：
步骤S50b：终端设备向TEE设备发送第二用户卡申请请求。
步骤S51b：TEE设备上配置的TEE根据第二用户卡申请请求提供凭护照及授权卡生成用户卡的服务。
步骤S52b：TEE设备向终端设备发送用户卡。
首先要强调的是，凭护照及授权卡申请用户卡的方式，只能用于目标用户是获得授权卡的用户自身的情况，转授权时不能采用此种方式申请用户卡。
步骤S50b至步骤S52b结合在一起进行阐述，由于第二种申请用户卡的方式和第一种申请用户卡的方式存在很多相同之处，所以下文将主要阐述二者的区别，其余内容可以参考对步骤S50a至步骤S52a的阐述。在用户申请到授权卡后，用户可以通过终端设备向TEE设备发送第而用户卡申请请求。第二用户卡申请请求至少包括第四命令字、授权卡、一个用户申请的护照、目标账号的标识、用户的可公开真身账号的公钥以及授权卡的属主账号的衍生路径。
其中，第四命令字表示请求TEE提供凭护照及授权卡生成用户卡的服务。用户申请的护照可以是用户申请授权卡时登录所用的护照，或者也可以是用户新申请的一个护照，并不限定，若申请顺利，该护照中记录的化身账号的公钥会被记录到用户卡中作为用户卡的目标账号的公钥，从而目标账号的标识为从用户的可公开真身账号推导护照中的化身账号的衍生路径。
TEE设备接收到第二用户卡申请请求后，可以调用TEE提供的安全服务接口，将请求传递给TEE，TEE获得第二用户卡申请请求后，根据其中的第四命令字确定要提供的是凭护照及授权卡生成用户卡的服务，然后便执行该项服务的内容：利用第二用户卡申请请求进行用户卡申请验证，若验证通过则生成用户卡。
其中，用户卡申请验证的验证项目包括以下至少一项：
(1)TEE利用授权卡中的应用网站的公钥验证对授权卡的签名是否正确；
(2)TEE利用护照中的管理网站的第一公钥验证对护照的签名是否正确；
(3)TEE利用可公开真身账号的公钥、护照、目标账号的标识、授权卡、授权卡的属主账号的衍生路径验证护照中的化身账号以及授权卡的属主账号是否均属于目标用户。
其中，第(1)项即验证授权卡是否是应用网站颁发的以及授权卡的内容是否遭到篡改。第(2)项即验证护照是否是管理网站颁发的以及护照的内容是否遭到篡改。
第(3)验证为同属验证，即验证授权卡的属主账号以及护照的化身账号是否属于目标用户。若两个账号均属于目标用户，即授权卡授权的对象是目标用户，同时护照里的化身账号也属于该目标用户，那么在即将生成的用户卡中填入护照中的化身账号的公钥作为用户卡的目标账号的公钥，表明应用网站已经授权拥有目标账号的目标用户通过登录目标账号使用应用网站提供的服务也就是合情合理的了。在申请用户卡的第一种方式中，对于授权给用户自己的情况，需要从未公开真身账号推导一个化身账号作为用户卡的目标账号，而在申请用户卡的第二种方式中，结合授权卡的证明功能，直接使用护照中的化身账号作为用户卡的目标账号，操作上更为简便，此种方式亦可称为将护照升级为用户卡。
同属验证(3)有不同的实现方式，下面介绍其中一种方式：
步骤A：TEE利用可公开真身账号的公钥以及授权卡的属主账号的衍生路径计算第二校验验根码，例如，可以将以上两项信息拼接后计算校验码作为第二校验验根码，接着TEE验证第二校验验根码与授权卡的验根码是否相同。授权卡的验根码为用户登录时使用的护照(注意和第二用户卡申请请求中的不一定是同一份护照)中的验根码(若用户通过用户卡登录，见步骤S7)，如果两个验根码相同，则表明授权卡的属主账号可从第二用户卡申请请求中携带的可公开真身账号推导产生。
步骤B：TEE利用可公开真身账号的公钥以及目标账号的标识计算第三校验验根码，例如，可以将以上两项信息拼接后计算校验码作为第三校验验根码，接着TEE验证第三校验验根码与第二用户卡申请请求中携带的护照的验根码是否相同。如果两个验根码相同，则表明第二用户卡申请请求中携带的护照中的化身账号可从第二用户卡申请请求中携带的可公开真身账号推导产生。
步骤C：若以上两项的验证结果均为“是”，说明第二用户卡申请请求中携带的护照中的化身账号以及授权卡中的属主账号均归属于同一个可公开真身账号，并且由于第二用户卡申请请求中携带的护照中的化身账号就是用户卡要记录的目标账号，所以此时TEE确定护照中的化身账号以及属主账号均属于目标用户，否则TEE可以确定护照中的化身账号以及属主账号并非均属于目标用户。
若所有验证项目的结果均为“是”，则TEE组织若干信息项以生成用户卡，并将用户卡作为安全服务接口调用的返回结果传递给TEE设备，TEE设备将用户卡返回给终端设备，用户便获得了用户卡。
用户卡中至少包括目标账号的公钥以及TEE利用自身的第二私钥对用户卡的签名。根据需求，用户卡还包括以下信息中的一项或多项：用户卡的验根码、应用网站的标识、目标用户的组、应用网站的公钥、用户卡的时段类别、用户卡的目标时间、用户卡的有效期、应用网站分配给用户的资源标识、目标用户的任务、用户卡的时段推导码以及用户卡的时段唯一码。
其中，目标账号的公钥为第二用户卡申请请求中携带的护照中的化身账号的公钥，而用户卡的验根码也取该护照中的验根码，无需重新计算，此两项内容确认了同属关系后直接从护照中复制即可。其余各信息项的确定方式可参考第一种申请用户卡的方式，不再重复。
根据前文所述，在一些实现方式中，TEE还可以统计凭护照及授权卡生成用户卡的服务被调用的次数，并在适当的时候将统计结果传出，作为服务提供方获得奖励的依据。
继续参照图4，步骤S6可以包括：
步骤S60：终端设备向应用网站发送第二用户登录请求。
步骤S61：应用网站根据第二用户登录请求进行用户登录验证。
步骤S62：应用网站向终端设备发送用户登录响应。
步骤S60至步骤S62结合在一起进行阐述。目标用户获得用户卡后，向应用网站发送第二用户登录请求，并在第二用户登录请求中携带该用户卡。在一些实现方式中，目标用户还可以使用目标账号的私钥对第二用户登录请求进行签名，由于用户卡中携带了目标账号的公钥，因此在应用网站一端可对签名做验证，签名的对象可以是第二用户登录请求中除该签名自身以外的内容。
应用网站接收到终端设备发送第二用户登录请求后，利用第二用户登录请求进行登录验证，验证项目包括以下至少一项：
(1)利用TEE的第二公钥验证对用户卡的签名是否正确；
(2)获取应用网站的当前时间，验证应用网站的当前时间是否处于由用户卡的有效期以及用户卡的目标时间所指定的时段内；
(3)利用目标账号的公钥验证对第二用户登录请求的签名是否正确；
(4)根据用户卡中应用网站的安全码、用户卡的时段推导码、应用网站的当前时间所在的时段、应用网站的标识以及用户卡中目标用户的组计算校验时段码，并验证校验时段码是否与用户卡的时段唯一码相同。
(5)验证用户卡的时段唯一码是否不同于任一已登录的用户所使用的用户卡中的时段唯一码
其中，第(1)项即验证用户卡是否由TEE颁发以及用户卡内容是否遭到篡改。
要执行第(2)项验证的前置条件是用户卡中包括目标时间以及有效期，第(2)项即验证用户卡是否过期，前文已经提到，用户卡的目标时间表征用户预期该用户卡被使用的时间，若用户卡颁发后未及时使用(应用网站的当前时间已经不在用户卡的目标时间和有效期所确定的时段内)，则用户卡已经过期，不应允许用户继续使用其进行登录，以保证安全性。
第(3)项验证的前置条件是第二用户登录请求中包括利用目标账号的私钥对请求的签名，目标账号的公钥携带在用户卡中，第(3)项即验证目标用户是否确实拥有目标账号以及第二用户登录请求内容是否遭到篡改。
第(4)项验证的前置条件是用户卡中包含时段唯一码、时段推导码、时段类别、应用网站的标识以及目标用户的组，其验证过程在前文已经介绍，这里不再重复，其主要目的是验证用户卡的时段唯一码是否被伪造、验证用户卡的目标时间所在的时间段是否已经结束、验证安全码，等等。
第(5)项验证的前置条件是用户卡中包含时段唯一码，根据时段唯一码的计算方式(参考前文用户卡时段唯一码的计算公式)，同一用户(可公开真身账号的公钥相同，用户的组相同)在同一时段(用户卡的目标时间所在的时段相同)、同一网站(用户卡中应用网站的标识相同)且持有相同的服务凭证(应用网站提供的安全码相同，例如，可以为所有的用户都提供相同的安全码)的情况下，使用化身账号申请多个用户卡，其中的时段唯一码完全相同。从而，第(5)项即验证是否存在同一用户企图在同一时段内通过多个用户卡上的不同目标账号登陆同一应用网站，若存这样的行为，则当前用户卡内的时段唯一码必然与一已登录的用户所使用的用户卡中的时段唯一码相同。是否要执行第(5)项验证取决于应用网站。
对比护照中的时段唯一码和用户卡中的时段唯一码，不难发现，二者的计算方式存在一定区别，因此同一用户在同一时段内分别通过其申请的护照和用户卡登录，应用网站也难以通过时段唯一码判断这两次登录的账号是否指向同一人。所以，可以采取的一种措施正如之前提到的，限制护照的使用范围，使其只能用于应用网站注册和登陆后申请授权卡。当然，若应用网站不验证时段唯一码，同一用户在同一时段内分别通过其申请的护照和用户卡登录也可能是允许的行为。
若所有验证项目的结果均为“是”，则应用网站向终端设备发送用户登录响应，告知目标用户登录成功，若(1)至(4)中任意一个验证项目的结果为“否”，则应用网站也可以向终端设备发送用户登录响应，告知目标用户登录网站失败，还可以进一步告知用户登录失败的原因。可以理解的，验证项目(1)至(4)的验证顺序不作限定，并且如果某个验证项目验证失败，剩余尚未执行的验证项目(如果有(5)，也包括(5))可以不再执行。
对于(5)稍微特殊一些，若其验证结果为“否”，并且此时其余验证项目的结果均为“是”，则有两种处理方式：一种是使(5)中提到的已登录的用户登录的账号退出登录，并使当前用户卡中的目标账号成为该已登录的用户新的登录账号，此时由于当前的用户卡登录成功了，所以应用网站可以向终端设备发送登录成功的响应；另一种是维持已登录的用户登录的账号继续处于登录状态，而拒绝当前用户卡中的目标账号进行登录，此时由于当前的用户卡登录失败了，所以应用网站可以向终端设备发送登录失败的响应。两种方式择一执行即可，总之，都是保证同一用户的两个时段唯一码相同的用户卡中的目标账号不能同时登录。可以理解的，验证项目(5)可以在验证项目(1)至(4)的任意一项之前或之后执行。
另外，若用户成功登录，应用网站还可以保存用户卡或用户卡中的预设信息项，供后续步骤中使用。至于目标用户登录成功后能够在应用网站执行何种权限的操作，则可由用户卡中的用户的组、用户的任务限定。
现有技术中，用户在应用网站登录时，往往要输入用户名和密码，而在本申请中，由于用户卡内已经包含了目标用户的身份信息(目标账号的公钥)，因此直接向应用网站提交用户卡即可进行登录，是一种完全不同的登录方式，并且在用户操作上也更为简单。
用户申请到用户卡后，可以通过用户卡登录，并且还可以在登录状态下申请新的授权卡。对于本来就是转授权的目标用户，在常见的情况中，不允许其进行二次授权(即用户A申请授权卡转授权给用户B，用户B又申请授权卡将用户A赋予他的权限二次转授权给用户C)。所以，为简单起见，不妨认为步骤S7中涉及的用户还是步骤S4中的用户，该用户于步骤S4中申请了授权卡，在步骤S5中基于授权卡申请了用户卡，在步骤S6中凭借该用户卡登录应用网站，然后执行步骤S7申请新的授权卡。新的授权卡的用途和步骤S4中申请的授权卡并无什么不同。
继续参照图4，步骤S7可以包括：
步骤S70：终端设备向应用网站发送授权卡申请请求(用户已凭用户卡登录)。
步骤S71：应用网站生成授权卡。
步骤S72：应用网站向终端设备发送授权卡。
步骤S70至步骤S72结合在一起进行阐述，用户在通过用户卡登录的方式下申请授权卡和在通过护照登录的方式下申请授权卡步骤大体相同，所以下文将主要阐述二者的区别，其余内容可以参考对步骤S40至步骤S42的阐述。
应用网站接受到授权卡申请请求后，可以利用授权卡申请请求进行授权卡申请验证，若通过则生成授权卡。授权卡中包括授权卡的属主账号的公钥，若授权卡针对的目标用户为申请授权卡的用户自身，则属主账号为用户当前通过用户卡登录的账号(若用户当前通过护照登录，见步骤S4)，由于申请授权卡时用户处于登录状态，应用网站必然可以获取该账号公钥；若目标用户为他人，则授权卡的属主账号的公钥为目标账号的公钥，即此时授权卡申请请求中携带的目标账号的标识。
在一些实现方式中，授权卡还可以包括验根码，若目标用户为申请授权卡的用户自身，则授权卡的验根码为用户当前登录时使用的用户卡中的验根码(若用户当前通过护照登录，见步骤S4)，之前已经提到，用户成功登录后，应用网站会保存用户卡或用户卡中预设的信息项，因此用户卡中的验根码应用网站可以获得；若目标用户为他人，则授权卡的验根码根据用户的可公开真身账号的公钥以及目标账号的公钥进行计算。
若用户通过步骤S7获得授权卡，则在用该授权卡申请用户卡时，有几个细节需要再补充说明一下：
在申请用户卡时，终端设备要准备授权卡的属主账号的衍生路径，用于做同属验证(因此下面的内容无需考虑转授权场景)。前文提到，若用户在申请授权卡时通过护照方式登录，则授权卡的属主账号是从可公开真身账号推导而来的一个化身账号，从可公开真身账号推导该化身账号的衍生路径为一个以可公开真身账号为推导起点的衍生路径，将该衍生路径与两个真身账号之间的相对路径拼接后，可以转换为一个以未公开真身账号为推导起点的衍生路径，该转换得到的路径定义为授权卡的属主账号的衍生路径。
若用户在申请授权卡时通过用户卡方式登录，则授权卡的属主账号是从未公开真身账号推导而来的一个化身账号，该化身账号的推导起点本来就是未公开真身账号，直接将该化身账号的衍生路径定义为授权卡的属主账号的衍生路径即可。需要指出，授权卡的属主账号的衍生路径不一定在申请用户卡时才获取，例如，可以在用户申请用户卡成功后就保存到终端设备本地的数据库中，申请用户卡时直接读取数据库中的历史记录即可。
在凭授权卡申请用户卡时，做同属验证的第二种方式的步骤D中，TEE会判断第一校验验根码与授权卡的验根码是否相同。授权卡的验根码为用户登录时使用的用户卡中的验根码，而用户卡中的验根码是根据用户的可公开真身账号的公钥以及从未公开真身账号推导目标账号的衍生路径进行计算(或者，也有可能是从某个待升级的护照中复制的，可类似分析)，如果两个验根码相同，则表明授权卡的属主账号可从未公开真身账号推导产生，而根据步骤A，用户卡上要记录的目标账号的公钥是由未公开真身账号的公钥推导产生的，说明未公开真身账号是属于目标用户的，所以一旦确定未公开真身账号的公钥能够推导授权卡的属主账号的公钥，必然表明授权卡的属主账号也属于即将生成的用户卡针对的目标用户。
在凭护照及授权卡申请用户卡时，做同属验证的步骤A中，TEE会利用可公开真身账号的公钥以及授权卡的属主账号的衍生路径计算第二校验验根码，并验证第二校验验根码与授权卡的验根码是否相同。授权卡的验根码为用户登录时使用的用户卡中的验根码，而用户卡中的验根码是根据用户的可公开真身账号的公钥以及从未公开真身账号推导目标账号的衍生路径进行计算(或者，也有可能是从某个待升级的护照中复制的，可类似分析)，如果两个验根码相同，则表明授权卡的属主账号可从第二用户卡申请请求中携带的可公开真身账号对应的未公开真身账号推导产生。
下面分析一下图4、图5的方案中有关安全隔离和隐私隔离的问题。
首先，允许用户针对不同的应用网站，从未公开真身账号推导不同的化身账号，并用这些化身账号申请不同的用户卡分别用于在这些应用网站登录(当然，凭护照升级用户卡也是可以的)，如果在访问某个应用网站时不慎暴露了账号的私钥，不会扩散到其他登录点，这就是一种安全隔离。
其次，用户卡在用于访问各应用网站时，可将其有效期限定为较短的一段时间，这样即使在访问某个应用网站时不慎暴露了账号的私钥，也因为用户卡会很快过期，造成的影响有限，同样是一种安全隔离。
在上面的方法中，先从应用网站申请授权卡(步骤S4和步骤S7)，然后请求TEE生成用户卡(步骤S5)，最后将用户卡用于登录应用网站(步骤S6)，即总体上看分为三个阶段，这样的实现方式有助于实现隐私隔离。在第一个阶段，登录到应用网站所用的化身账号，通常并不是用户卡中的目标账号，并且应用网站也无法获知用户何时使用授权卡，授权卡与那个目标账号捆绑使用也不一定知道(除非是转授权的情况)，使得用户身份难以锁定；在第二个阶段，用户请求接入区块链网络的TEE生成用户卡时，TEE可提供黑盒式的安全服务，使得在消息通路上无人能侦测服务内容或返回结果，保证用户隐私不会泄露，并且，借助于区块链的分布式计算特性，用户可自主选择在哪个接入点提交服务请求，而具体由哪个TEE承接该请求可以由TEE服务接入点动态决定，从而进一步增加了安全性；而在第三个阶段，应用网站虽然能够获知用户通过某个目标账号进行了登录，但由于用户卡中并没有包括可公开真身账号或未公开真身账号的信息，所以应用网站无法获知用户卡的真正拥有者。总之，前后三个阶段没有明显的关联，他人无法跟踪特定用户的上网行为，从而可以保护用户隐私。
本申请实施例还提供一种护照申请装置，配置于终端设备，所述装置包括：第一护照账号推导模块，用于利用用户在管理网站实名注册过的可公开真身账号推导化身账号；护照申请模块，用于向所述管理网站发送护照申请请求，所述护照申请请求包括所述可公开真身账号的公钥、所述可公开真身账号的链码、从所述可公开真身账号推导所述化身账号的衍生路径以及利用所述可公开真身账号的私钥对所述护照申请请求的签名；护照接收模块，用于接收所述管理网站发送的护照，所述护照包括所述化身账号的公钥、所述管理网站的第一公钥以及所述管理网站利用自身的第一私钥对所述护照的签名，所述护照用于证明所述化身账号由一个在所述管理网站实名注册过的可公开真身账号推导产生；其中，所述管理网站的第一私钥与所述管理网站的第一公钥为一个公私钥对。
本申请实施例还提供一种护照申请装置，配置于管理网站，所述装置包括：护照申请请求接收模块，用于接收终端设备发送的护照申请请求，所述护照申请请求包括用户的可公开真身账号的公钥、所述可公开真身账号的链码、从所述可公开真身账号推导化身账号的衍生路径以及利用所述可公开真身账号的私钥对所述护照申请请求的签名；护照申请验证模块，用于利用所述护照申请请求进行申请验证，验证项目包括以下至少一项：验证所述可公开真身账号的公钥是否已经进行过实名注册；利用所述可公开真身账号的公钥验证对所述护照申请请求的签名是否正确；第二护照账号推导模块，用于若所有验证项目的结果均为“是”，则利用所述可公开真身账号的公钥、所述可公开真身账号的链码以及从所述可公开真身账号推导所述化身账号的衍生路径推导所述化身账号的公钥；护照生成模块，用于生成护照，所述护照包括所述化身账号的公钥、所述管理网站的第一公钥以及所述管理网站利用自身的第一私钥对所述护照的签名，所述护照用于证明所述化身账号由一个在所述管理网站实名注册过的可公开真身账号推导产生；其中，所述管理网站的第一私钥与所述管理网站的第一公钥为一个公私钥对；护照发送模块，用于向所述终端设备发送所述护照。
本申请实施例还提供一种用户注册装置，配置于终端设备，所述装置包括：用户注册模块，用于向应用网站发送用户注册请求，所述用户注册请求包括管理网站颁发的护照，所述护照包括用户要注册的化身账号的公钥、所述管理网站的第一公钥以及所述管理网站利用自身的第一私钥对所述护照的签名，所述护照用于证明所述化身账号由一个在所述管理网站实名注册过的可公开真身账号推导产生；其中，所述管理网站的第一私钥与所述管理网站的第一公钥为一个公私钥对。
本申请实施例还提供一种用户注册装置，配置于应用网站，所述装置包括：用户注册请求接收模块，用于接收终端设备发送用户注册请求，所述用户注册请求包括管理网站颁发的护照，所述护照包括用户要注册的化身账号的公钥、所述管理网站的第一公钥以及所述管理网站利用自身的第一私钥对所述护照的签名，所述护照用于证明所述化身账号由一个在所述管理网站实名注册过的可公开真身账号推导产生；其中，所述管理网站的第一私钥与所述管理网站的第一公钥为一个公私钥对；用户注册验证模块，用于利用所述用户注册请求进行注册验证，验证项目包括以下至少一项：验证所述化身账号的公钥是否尚未绑定资源标识；利用所述管理网站的第一公钥验证对所述护照的签名是否正确；资源标识绑定模块，用于若所有验证项目的结果均为“是”，则为所述用户分配一个资源标识，并绑定所述化身账号的公钥与所述资源标识；用户注册响应模块，用于保存所述护照或所述护照中的预设信息项，并向所述终端设备发送注册成功的响应。
本申请实施例还提供一种用户登录装置，配置于终端设备，所述装置包括：第一登录模块，用于向应用网站发送第一用户登录请求，所述第一用户登录请求包括管理网站颁发的护照，所述护照包括用户要登录的化身账号的公钥、所述管理网站的第一公钥以及所述管理网站利用自身的第一私钥对所述护照的签名，所述护照用于证明所述化身账号由一个在所述管理网站实名注册过的可公开真身账号推导产生；其中，所述管理网站的第一私钥与所述管理网站的第一公钥为一个公私钥对。
本申请实施例还提供一种用户登录装置，配置于应用网站，所述装置包括：第一用户登录请求接收模块，用于接收终端设备发送第一用户登录请求，所述第一用户登录请求包括管理网站颁发的护照，所述护照包括用户要登录的化身账号的公钥、所述管理网站的第一公钥以及所述管理网站利用自身的第一私钥对所述护照的签名，所述护照用于证明所述化身账号由一个在所述管理网站实名注册过的可公开真身账号推导产生；其中，所述管理网站的第一私钥与所述管理网站的第一公钥为一个公私钥对；第一用户登录请求验证模块，用于利用所述第一用户登录请求进行登录验证，验证项目包括以下至少一项：验证所述化身账号的公钥是否已经绑定资源标识；利用所述管理网站的第一公钥验证对所述护照的签名是否正确；第一登录响应模块，用于若所有验证项目的结果均为“是”，则向所述终端设备发送登录成功的响应。
本申请实施例还提供一种授权卡申请装置，配置于终端设备，所述装置包括：授权卡申请模块，用于向用户已登录的应用网站发送授权卡申请请求，所述授权卡申请请求包括目标账号的标识，所述目标账号的标识为所述目标账号的公钥、从所述用户的未公开真身账号推导所述目标账号的衍生路径或空字串；其中，若所述目标账号的标识为从所述未公开真身账号推导所述目标账号的衍生路径或空字串，表示拥有所述目标账号的目标用户为所述用户自身，若所述目标账号的标识为所述目标账号的公钥，表示所述目标用户为他人；授权卡接收模块，用于接收所述应用网站发送的授权卡，所述授权卡包括所述授权卡的属主账号的公钥、所述应用网站的公钥以及所述应用网站利用自身的私钥对所述授权卡的签名，所述授权卡用于作为所述用户向TEE设备上配置的TEE申请供所述目标用户使用的用户卡的凭证。
本申请实施例还提供一种授权卡申请装置，配置于应用网站，所述装置包括：授权卡申请请求接收模块，用于接收已登录所述应用网站的用户通过终端设备发送的授权卡申请请求，所述授权卡申请请求包括目标账号的标识，所述目标账号的标识为所述目标账号的公钥、从所述用户的未公开真身账号推导所述目标账号的衍生路径或空字串；其中，若所述目标账号的标识为从所述未公开真身账号推导所述目标账号的衍生路径或空字串，表示所述拥有所述目标账号的目标用户为所述用户自身，若所述目标账号的标识为所述目标账号的公钥，表示所述目标用户为他人；身份判断模块，用于根据所述目标账号的标识判断所述目标用户为所述用户自身或他人；授权卡生成模块，用于生成授权卡，所述授权卡包括所述授权卡的属主账号的公钥、所述应用网站的公钥以及所述应用网站利用自身的私钥对所述授权卡的签名，作为所述用户向TEE设备上配置的TEE申请供所述目标用户使用的用户卡的凭证；其中，若所述目标用户为所述用户自身，则所述授权卡的属主账号为所述用户当前通过护照或用户卡登录的账号，若所述目标用户为他人，则所述授权卡的属主账号为所述目标账号；授权卡发送模块，用于向所述终端设备发送所述授权卡。
本申请实施例还提供一种单向密文密钥生成装置，配置于TEE，所述装置包括：密钥生成请求接收模块，用于所述TEE通过配置有所述TEE的TEE设备接收应用网站发送的密钥生成请求，所述密钥生成请求包括：第一命令字以及明文密钥；单向密文密钥生成模块，用于所述TEE根据所述第一命令字确定提供生成单向密文密钥的服务，服务的内容包括：所述TEE利用特定密钥对所述明文密钥进行加密，获得单向密文密钥，所述特定密钥仅在所述TEE中使用；单向密文密钥发送模块，用于所述TEE通过所述TEE设备向所述应用网站发送所述单向密文密钥。
本申请实施例还提供一种用户卡申请装置，配置于终端设备，所述装置包括：标识获取模块，用于若用户卡针对的目标用户为获得授权卡的用户自身，则从所述用户的未公开真身账号推导所述目标用户的目标账号，并将从所述未公开真身账号推导所述目标账号的衍生路径确定为所述目标账号的标识，若所述目标用户为他人，则将所述目标账号的公钥确定为所述目标账号的标识；第一用户卡申请模块，用于向配置有TEE的TEE设备发送第一用户卡申请请求，所述第一用户卡申请请求包括第三命令字、所述授权卡以及所述目标账号的标识；其中，所述第三命令字表示请求所述TEE提供凭授权卡生成用户卡的服务，若所述目标用户为所述用户自身，则所述第一用户卡申请请求还包括所述未公开真身账号的公钥、所述未公开真身账号的链码以及所述授权卡的属主账号的衍生路径；第一用户卡接收模块，用于接收所述TEE设备发送的用户卡，所述用户卡包括所述目标账号的公钥以及所述TEE利用自身的第二私钥对所述用户卡的签名，所述用户卡用于证明颁发所述授权卡的应用网站已经授权所述目标用户通过登录所述目标账号使用所述应用网站提供的服务。
本申请实施例还提供一种用户卡申请装置，配置于TEE，所述装置包括：第一用户卡申请请求接收模块，用于所述TEE通过配置有所述TEE的TEE设备接收获得授权卡的用户通过终端设备发送的第一用户卡申请请求，所述第一用户卡申请请求包括第三命令字、所述授权卡以及目标账号的标识；其中，若拥有所述目标账号的目标用户为所述用户自身，则所述第一用户卡申请请求还包括所述用户的未公开真身账号的公钥、所述未公开真身账号的链码以及授权卡的属主账号的衍生路径；第一用户卡生成模块，用于所述TEE根据所述第三命令字确定提供凭授权卡生成用户卡的服务，服务的内容包括：所述TEE利用所述第一用户卡申请请求进行申请验证，验证项目包括以下至少一项：所述TEE利用所述授权卡中的应用网站的公钥验证对所述授权卡的签名是否正确；所述TEE根据所述目标账号的标识判断所述目标用户为所述用户自身或他人，若所述目标用户为所述用户自身，则所述TEE利用所述未公开真身账号的公钥、所述未公开真身账号的链码、所述目标账号的标识、所述授权卡、所述授权卡的属主账号的衍生路径验证所述属主账号是否属于所述目标用户；若所有验证项目的结果均为“是”，则所述TEE生成用户卡，所述用户卡包括所述目标账号的公钥以及所述TEE利用自身的第二私钥对所述用户卡的签名，所述用户卡用于证明所述应用网站已经授权所述目标用户通过登录所述目标账号使用所述应用网站提供的服务；其中，若所述目标用户为所述用户自身，则所述目标账号的公钥在验证所述属主账号是否属于所述目标用户时获得，若所述目标用户为他人，则所述目标账号的公钥为所述授权卡的属主账号的公钥；第一用户卡发送模块，用于所述TEE通过所述TEE设备向所述终端设备发送所述用户卡。
本申请实施例还提供一种用户卡申请装置，配置于终端设备，所述装置包括：第二用户卡申请模块，用于向配置有TEE的TEE设备发送第二用户卡申请请求，所述第二用户卡申请请求包括第四命令字、用户申请的授权卡、目标账号的标识、所述用户的可公开真身账号的公钥、所述用户申请的护照以及所述授权卡的属主账号的衍生路径；其中，所述第四命令字表示请求所述TEE提供凭护照及授权卡生成用户卡的服务，所述目标账号的标识为从所述可公开真身账号推导所述护照中的化身账号的衍生路径；第二用户卡接收模块，用于接收所述TEE设备发送的用户卡，所述用户卡包括所述目标账号的公钥以及所述TEE利用自身的第二私钥对所述用户卡的签名，所述用户卡用于证明颁发所述授权卡的应用网站已经授权拥有所述目标账号的目标用户通过登录所述目标账号使用所述应用网站提供的服务。
本申请实施例还提供一种用户卡申请装置，配置于TEE，所述装置包括：第二用户卡申请请求接收模块，用于所述TEE通过配置有所述TEE的TEE设备接收用户通过终端设备发送的第二用户卡申请请求，所述第二用户卡申请请求包括第四命令字、用户申请的授权卡、目标账号的标识、所述用户的可公开真身账号的公钥、所述用户申请的护照以及所述授权卡的属主账号的衍生路径；第二用户卡生成模块，用于所述TEE根据所述第四命令字确定提供凭护照及授权卡生成用户卡的服务，服务的内容包括：所述TEE利用所述第二用户卡申请请求进行申请验证，验证项目包括以下至少一项：所述TEE利用所述授权卡中的应用网站的公钥验证对所述授权卡的签名是否正确；所述TEE利用所述护照中的管理网站的第一公钥验证对所述护照的签名是否正确；所述TEE利用所述可公开真身账号的公钥、所述护照、所述目标账号的标识、所述授权卡、所述授权卡的属主账号的衍生路径验证所述护照中的化身账号以及所述属主账号是否均属于拥有所述目标账号的目标用户；若所有验证项目的结果均为“是”，则所述TEE生成用户卡，所述用户卡包括所述目标账号的公钥以及所述TEE利用自身的第二私钥对所述用户卡的签名，所述用户卡用于证明所述应用网站已经授权所述目标用户通过登录所述目标账号使用所述应用网站提供的服务；其中，所述目标账号的公钥为所述护照中的化身账号的公钥；第二用户卡发送模块，用于所述TEE通过所述TEE设备向所述终端设备发送所述用户卡。
本申请实施例还提供一种用户登录装置，配置于终端设备，所述装置包括：第二登录模块，用于向应用网站发送第二用户登录请求，所述第二用户登录请求包括TEE中生成的用户卡，所述用户卡包括目标用户要登录的目标账号的公钥以及所述TEE利用自身的第二私钥对所述用户卡的签名，所述用户卡用于证明所述应用网站已经授权所述目标用户通过登录所述目标账号使用所述应用网站提供的服务。
本申请实施例还提供一种用户登录装置，配置于应用网站，所述装置包括：第二用户登录请求接收模块，用于接收终端设备发送第二用户登录请求，所述第二用户登录请求包括TEE中生成的用户卡，所述用户卡包括目标用户要登录的目标账号的公钥以及所述TEE利用自身的第二私钥对所述用户卡的签名，所述用户卡用于证明所述应用网站已经授权所述目标用户通过登录所述目标账号使用所述应用网站提供的服务；第二用户登录请求验证模块，用于利用所述第二用户登录请求进行登录验证，验证项目包括以下至少一项：利用所述TEE的第二公钥验证对所述用户卡的签名是否正确，所述TEE的第二公钥与所述TEE的第二私钥为一个公私钥对；第二登录响应模块，用于若所有验证项目的结果均为“是”，则向所述终端设备发送登录成功的响应。
本申请实施例提供的上述各装置，其实现原理及产生的技术效果在前述方法实施例中已经介绍，为简要描述，装置实施例部分未提及之处，可参考方法施例中相应内容。
图6示出了本申请实施例提供的电子设备800的一种可能的结构。参照图6，电子设备800包括：处理器810、存储器820以及通信接口830，这些组件通过通信总线840和/或其他形式的连接机构(未示出)互连并相互通讯。
其中，存储器820包括一个或多个(图中仅示出一个)，其可以是，但不限于，随机存取存储器(Random Access Memory，简称RAM)，只读存储器(Read Only Memory，简称ROM)，可编程只读存储器(Programmable Read-Only Memory，简称PROM)，可擦除只读存储器(Erasable Programmable Read-Only Memory，简称EPROM)，电可擦除只读存储器(Electric Erasable Programmable Read-Only Memory，简称EEPROM)等。处理器810以及其他可能的组件可对存储器820进行访问，读和/或写其中的数据。
处理器810包括一个或多个(图中仅示出一个)，其可以是一种集成电路芯片，具有信号的处理能力。上述的处理器810可以是通用处理器，包括中央处理器(CentralProcessing Unit，简称CPU)、微控制单元(Micro Controller Unit，简称MCU)、网络处理器(Network Processor，简称NP)或者其他常规处理器；还可以是专用处理器，包括数字信号处理器(Digital Signal Processor,简称DSP)、专用集成电路(Application SpecificIntegrated Circuits，简称ASIC)、现场可编程门阵列(Field Programmable Gate Array，简称FPGA)或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件。
通信接口830包括一个或多个(图中仅示出一个)，可以用于和其他设备进行直接或间接地通信，以便进行数据的交互。通信接口830可以是以太网接口；可以是高速网络接口(如Infiniband网络)；可以是移动通信网络接口，例如3G、4G、5G网络的接口；可以是各类总线接口，例如USB、CAN、I2C、SPI总线接口；还是可以是具有数据收发功能的其他类型的接口。
在存储器820中可以存储一个或多个计算机程序指令，处理器810可以读取并运行这些计算机程序指令，以实现本申请实施例提供的上述各方法以及其他期望的功能。
可以理解，图6所示的结构仅为示意，电子设备800还可以包括比图6中所示更多或者更少的组件，或者具有与图6所示不同的配置。图6中所示的各组件可以采用硬件、软件或其组合实现。于本申请实施例中，电子设备800可能是终端设备、网站服务器、TEE等。
本申请实施例还提供一种计算机可读存储介质，该计算机可读存储介质上存储有计算机程序指令，所述计算机程序指令被计算机的处理器读取并运行时，执行本申请实施例提供的上述各方法。例如，计算机可读存储介质可以实现为图6中电子设备800中的存储器820。
在本申请所提供的实施例中，应该理解到，所揭露装置和方法，可以通过其它的方式实现。以上所描述的装置实施例仅仅是示意性的，例如，所述单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，又例如，多个单元或组件可以结合或者可以集成到另一个系统，或一些特征可以忽略，或不执行。另一点，所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些通信接口，装置或单元的间接耦合或通信连接，可以是电性，机械或其它的形式。
另外，作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本实施例方案的目的。
再者，在本申请各个实施例中的各功能模块可以集成在一起形成一个独立的部分，也可以是各个模块单独存在，也可以两个或两个以上模块集成形成一个独立的部分。
以上所述仅为本申请的实施例而已，并不用于限制本申请的保护范围，对于本领域的技术人员来说，本申请可以有各种更改和变化。凡在本申请的精神和原则之内，所作的任何修改、等同替换、改进等，均应包含在本申请的保护范围之内。

Claims (90)

1.一种用户注册方法，其特征在于，应用于终端设备，所述方法包括：
向应用网站发送用户注册请求，所述用户注册请求包括管理网站颁发的护照，所述护照包括用户要注册的化身账号的公钥、所述管理网站的第一公钥以及所述管理网站利用自身的第一私钥对所述护照的签名，所述护照用于证明所述化身账号由一个在所述管理网站实名注册过的可公开真身账号推导产生；其中，所述管理网站的第一私钥与所述管理网站的第一公钥为一个公私钥对。
2.根据权利要求1所述的用户注册方法，其特征在于，所述用户注册请求还包括利用所述化身账号的私钥对所述用户注册请求的签名。
3.一种用户注册方法，其特征在于，应用于应用网站，所述方法包括：
接收终端设备发送用户注册请求，所述用户注册请求包括管理网站颁发的护照，所述护照包括用户要注册的化身账号的公钥、所述管理网站的第一公钥以及所述管理网站利用自身的第一私钥对所述护照的签名，所述护照用于证明所述化身账号由一个在所述管理网站实名注册过的可公开真身账号推导产生；其中，所述管理网站的第一私钥与所述管理网站的第一公钥为一个公私钥对；
利用所述用户注册请求进行注册验证，验证项目包括以下至少一项：验证所述化身账号的公钥是否尚未绑定资源标识；利用所述管理网站的第一公钥验证对所述护照的签名是否正确；
若所有验证项目的结果均为“是”，则为所述用户分配一个资源标识，并绑定所述化身账号的公钥与所述资源标识；
保存所述护照或所述护照中的预设信息项，并向所述终端设备发送注册成功的响应。
4.根据权利要求3所述的用户注册方法，其特征在于，所述护照还包括以下信息中的一项或多项：
所述护照的验根码、所述护照的时段唯一码、所述管理网站的标识、所述用户的组、所述护照的时段类别、所述护照的有效期以及所述护照的目标时间。
5.根据权利要求4所述的用户注册方法，其特征在于，所述护照的时段唯一码根据所述可公开真身账号的公钥以及所述护照的目标时间所在的时段进行计算，所述护照的目标时间为所述应用网站指定的历史时间，所述验证项目还包括：
验证所述护照的时段唯一码是否不同于任一已注册的用户所使用的护照中的时段唯一码。
6.根据权利要求3所述的用户注册方法，其特征在于，所述用户注册请求还包括利用所述化身账号的私钥对所述用户注册请求的签名，所述验证项目还包括：
利用所述化身账号的公钥验证对所述用户注册请求的签名是否正确。
7.一种用户登录方法，其特征在于，应用于终端设备，所述方法包括：
向应用网站发送第一用户登录请求，所述第一用户登录请求包括管理网站颁发的护照，所述护照包括用户要登录的化身账号的公钥、所述管理网站的第一公钥以及所述管理网站利用自身的第一私钥对所述护照的签名，所述护照用于证明所述化身账号由一个在所述管理网站实名注册过的可公开真身账号推导产生；其中，所述管理网站的第一私钥与所述管理网站的第一公钥为一个公私钥对。
8.根据权利要求7所述的用户登录方法，其特征在于，所述第一用户登录请求还包括利用所述化身账号的私钥对所述第一用户登录请求的签名。
9.一种用户登录方法，其特征在于，应用于应用网站，所述方法包括：
接收终端设备发送第一用户登录请求，所述第一用户登录请求包括管理网站颁发的护照，所述护照包括用户要登录的化身账号的公钥、所述管理网站的第一公钥以及所述管理网站利用自身的第一私钥对所述护照的签名，所述护照用于证明所述化身账号由一个在所述管理网站实名注册过的可公开真身账号推导产生；其中，所述管理网站的第一私钥与所述管理网站的第一公钥为一个公私钥对；
利用所述第一用户登录请求进行登录验证，验证项目包括以下至少一项：验证所述化身账号的公钥是否已经绑定资源标识；利用所述管理网站的第一公钥验证对所述护照的签名是否正确；
若所有验证项目的结果均为“是”，则向所述终端设备发送登录成功的响应。
10.根据权利要求9所述的用户登录方法，其特征在于，所述护照还包括以下信息中的一项或多项：
所述护照的验根码、所述护照的时段唯一码、所述管理网站的标识、所述用户的组、所述护照的时段类别、所述护照的有效期以及所述护照的目标时间。
11.根据权利要求10所述的用户登录方法，其特征在于，所述护照包括所述护照的目标时间，所述验证项目还包括：
获取所述应用网站的当前时间，验证所述应用网站的当前时间与所述护照的目标时间之间的间隔是否小于第二预设时间间隔。
12.根据权利要求10所述的用户登录方法，其特征在于，所述护照包括所述护照的有效期以及所述护照的目标时间，所述验证项目还包括：
获取所述应用网站的当前时间，验证所述应用网站的当前时间是否处于由所述护照的有效期以及所述护照的目标时间所指定的时段内。
13.根据权利要求9所述的用户登录方法，其特征在于，所述第一用户登录请求还包括利用所述化身账号的私钥对所述第一用户登录请求的签名，所述验证项目还包括：
利用所述化身账号的公钥验证对所述第一用户登录请求的签名是否正确。
14.根据权利要求10所述的用户登录方法，其特征在于，所述护照包括所述护照的时段唯一码，所述验证项目还包括：
验证所述护照的时段唯一码是否不同于任一已登录的用户所使用的护照中的时段唯一码；
所述方法还包括：若以上针对时段唯一码的验证项目的结果为“否”，并且，其余验证项目的结果均为“是”，则向所述终端设备发送登录成功的响应并使所述已登录的用户登录的账号退出登录，或者，向所述终端设备发送登录失败的响应。
15.一种护照申请方法，其特征在于，应用于终端设备，所述方法包括：
利用用户在管理网站实名注册过的可公开真身账号推导化身账号；
向所述管理网站发送护照申请请求，所述护照申请请求包括所述可公开真身账号的公钥、所述可公开真身账号的链码、从所述可公开真身账号推导所述化身账号的衍生路径以及利用所述可公开真身账号的私钥对所述护照申请请求的签名；
接收所述管理网站发送的护照，所述护照包括所述化身账号的公钥、所述管理网站的第一公钥以及所述管理网站利用自身的第一私钥对所述护照的签名，所述护照用于证明所述化身账号由一个在所述管理网站实名注册过的可公开真身账号推导产生；其中，所述管理网站的第一私钥与所述管理网站的第一公钥为一个公私钥对。
16.根据权利要求15所述的护照申请方法，其特征在于，所述利用用户在管理网站实名注册过的可公开真身账号推导化身账号，包括：
按照分层确定性HD钱包中规定的衍生方式从用户在管理网站实名注册过的可公开真身账号推导化身账号。
17.根据权利要求15所述的护照申请方法，其特征在于，所述护照申请请求还包括以下信息中的一项或多项：
所述终端设备的当前时间、所述护照的目标时间以及所述护照的时段类别；
其中，所述护照的目标时间为所述终端设备的当前时间，或者，允许使用所述护照进行注册或登录的应用网站指定的历史时间。
18.根据权利要求15所述的护照申请方法，其特征在于，所述护照申请请求利用所述管理网站的第二公钥加密。
19.根据权利要求15所述的护照申请方法，其特征在于，在所述利用用户在管理网站实名注册过的可公开真身账号推导化身账号之前，所述方法还包括：
生成用户的可公开真身账号；
向所述管理网站发送根账号注册请求，所述根账号注册请求包括所述用户的实名认证信息以及所述可公开真身账号的公钥。
20.根据权利要求19所述的护照申请方法，其特征在于，所述根账号注册请求还包括：
特定信息以及利用所述可公开真身账号的私钥对所述特定信息的签名，所述特定信息包括所述管理网站提供的随机字串。
21.一种护照申请方法，其特征在于，应用于管理网站，所述方法包括：
接收终端设备发送的护照申请请求，所述护照申请请求包括用户的可公开真身账号的公钥、所述可公开真身账号的链码、从所述可公开真身账号推导化身账号的衍生路径以及利用所述可公开真身账号的私钥对所述护照申请请求的签名；
利用所述护照申请请求进行申请验证，验证项目包括以下至少一项：验证所述可公开真身账号的公钥是否已经进行过实名注册；利用所述可公开真身账号的公钥验证对所述护照申请请求的签名是否正确；
若所有验证项目的结果均为“是”，则利用所述可公开真身账号的公钥、所述可公开真身账号的链码以及从所述可公开真身账号推导所述化身账号的衍生路径推导所述化身账号的公钥；
生成护照，所述护照包括所述化身账号的公钥、所述管理网站的第一公钥以及所述管理网站利用自身的第一私钥对所述护照的签名，所述护照用于证明所述化身账号由一个在所述管理网站实名注册过的可公开真身账号推导产生；其中，所述管理网站的第一私钥与所述管理网站的第一公钥为一个公私钥对；
向所述终端设备发送所述护照。
22.根据权利要求21所述的护照申请方法，其特征在于，所述护照申请请求还包括所述终端设备的当前时间，所述验证项目还包括：
获取所述管理网站的当前时间，验证所述终端设备的当前时间与所述管理网站的当前时间之间的间隔是否小于第一预设时间间隔。
23.根据权利要求21所述的护照申请方法，其特征在于，所述护照还包括以下信息中的一项或多项：
所述护照的验根码、所述护照的时段唯一码、所述管理网站的标识、所述用户的组、所述护照的时段类别、所述护照的有效期以及所述护照的目标时间；
其中，所述护照的验根码根据所述可公开真身账号的公钥以及所述化身账号的总衍生路径进行计算，其中，所述化身账号的总衍生路径为一个由从所述可公开真身账号推导所述化身账号的衍生路径，以及，所述用户的未公开真身账号与可公开真身账号的之间的相对路径拼接后得到的、以所述未公开真身账号为推导起点的衍生路径；
所述护照的时段类别以及所述护照的目标时间从所述护照申请请求中获取；
所述护照的时段唯一码根据所述可公开真身账号的公钥以及所述护照的目标时间所在的时段进行计算，所述护照的目标时间所在的时段根据所述护照的目标时间以及所述护照的时段类别进行计算。
24.根据权利要求21所述的护照申请方法，其特征在于，所述护照申请请求利用所述管理网站的第二公钥进行加密，在所述利用所述护照申请请求进行申请验证之前，所述方法还包括：
利用所述管理网站自身的第二私钥对所述护照申请请求进行解密；其中，所述管理网站的第二私钥与所述管理网站的第二公钥为一个公私钥对。
25.根据权利要求21所述的护照申请方法，其特征在于，在所述接收终端设备发送的护照申请请求之前，所述方法还包括：
接收所述终端设备发送根账号注册请求，所述根账号注册请求包括所述用户的实名认证信息以及所述可公开真身账号的公钥；
利用所述根账号注册请求进行注册验证，验证项目包括以下至少一项：验证所述实名认证信息是否正确；验证所述可公开真身账号的公钥是否尚未绑定实名认证信息；
若所有验证项目的结果均为“是”，则绑定所述可公开真身账号的公钥与所述用户的实名认证信息。
26.根据权利要求25所述的护照申请方法，其特征在于，所述根账号注册请求还包括特定信息以及利用所述可公开真身账号的私钥对所述特定信息的签名，所述特定信息包括所述管理网站提供的随机字串，验证项目还包括：
利用所述可公开真身账号的公钥验证对所述特定信息的签名是否正确。
27.一种用户登录方法，其特征在于，应用于终端设备，所述方法包括：
向应用网站发送第二用户登录请求，所述第二用户登录请求包括TEE中生成的用户卡，所述用户卡包括目标用户要登录的目标账号的公钥以及所述TEE利用自身的第二私钥对所述用户卡的签名，所述用户卡用于证明所述应用网站已经授权所述目标用户通过登录所述目标账号使用所述应用网站提供的服务。
28.根据权利要求27所述的用户登录方法，其特征在于，所述第二用户登录请求还包括利用所述目标账号的私钥对所述第二用户登录请求的签名。
29.一种用户登录方法，其特征在于，应用于应用网站，所述方法包括：
接收终端设备发送第二用户登录请求，所述第二用户登录请求包括TEE中生成的用户卡，所述用户卡包括目标用户要登录的目标账号的公钥以及所述TEE利用自身的第二私钥对所述用户卡的签名，所述用户卡用于证明所述应用网站已经授权所述目标用户通过登录所述目标账号使用所述应用网站提供的服务；
利用所述第二用户登录请求进行登录验证，验证项目包括以下至少一项：利用所述TEE的第二公钥验证对所述用户卡的签名是否正确，所述TEE的第二公钥与所述TEE的第二私钥为一个公私钥对；
若所有验证项目的结果均为“是”，则向所述终端设备发送登录成功的响应。
30.根据权利要求29所述的用户登录方法，其特征在于，所述用户卡还包括以下信息中的一项或多项：
所述用户卡的验根码、所述应用网站的标识、所述目标用户的组、所述应用网站的公钥、所述用户卡的时段类别、所述用户卡的目标时间、所述用户卡的有效期、所述应用网站分配给所述用户的资源标识、所述目标用户的任务、所述用户卡的时段推导码以及所述用户卡的时段唯一码。
31.根据权利要求30所述的用户登录方法，其特征在于，所述用户卡包括所述用户卡的有效期以及所述用户卡的目标时间，所述验证项目还包括：
获取所述应用网站的当前时间，验证应用网站的当前时间是否处于由所述用户卡的有效期以及所述用户卡的目标时间所指定的时段内。
32.根据权利要求29所述的用户登录方法，其特征在于，所述第二用户登录请求还包括利用所述目标账号的私钥对所述第二用户登录请求的签名，所述验证项目还包括：
利用所述目标账号的公钥验证对所述第二用户登录请求的签名是否正确。
33.根据权利要求30所述的用户登录方法，其特征在于，所述用户卡包括所述用户卡的时段唯一码，所述验证项目还包括：
验证所述用户卡的时段唯一码是否不同于任一已登录的用户所使用的用户卡中的时段唯一码；
所述方法还包括：若以上针对时段唯一码的验证项目的结果为“否”，并且，其余验证项目的结果均为“是”，则向所述终端设备发送登录成功的响应并使所述已登录的用户登录的账号退出登录，或者，向所述终端设备发送登录失败的响应。
34.根据权利要求33所述的用户登录方法，其特征在于，所述用户卡还包括所述用户卡的时段推导码、所述用户卡的时段类别、所述应用网站的标识以及所述目标用户的组，所述验证项目还包括：
根据所述应用网站的安全码、所述用户卡的时段推导码、所述应用网站的当前时间所在的时段、所述应用网站的标识以及所述目标用户的组计算校验时段码，并验证所述校验时段码是否与所述用户卡的时段唯一码相同；其中，所述应用网站的当前时间所在的时段根据所述应用网站的当前时间以及所述用户卡的时段类别进行计算。
35.根据权利要求34所述的用户登录方法，其特征在于，所述根据所述应用网站的安全码、所述用户卡的时段推导码、所述用户卡的时段类别、所述应用网站的标识以及所述目标用户的组计算校验时段码，包括：
所述校验时段码LoginSessin’根据如下公式计算：
LoginSession’＝hash(Secret+(hash(TimeSegment’+Domain+Group)^TimeSession))
其中，TimeSegment’为所述应用网站的当前时间所在的时段，TimeSegmnet’根据所述应用网站的当前时间以及所述用户卡的时段类别进行计算，Domain为所述应用网站的标识、Group为所述目标用户的组，TimeSession为所述用户卡的时段推导码，hash表示哈希运算，+表示字串拼接，^表示异或运算。
36.一种授权卡申请方法，其特征在于，应用于终端设备，所述方法包括：
向用户已登录的应用网站发送授权卡申请请求，所述授权卡申请请求包括目标账号的标识，所述目标账号的标识为所述目标账号的公钥、从所述用户的未公开真身账号推导所述目标账号的衍生路径或空字串；其中，若所述目标账号的标识为从所述未公开真身账号推导所述目标账号的衍生路径或空字串，表示拥有所述目标账号的目标用户为所述用户自身，若所述目标账号的标识为所述目标账号的公钥，表示所述目标用户为他人；
接收所述应用网站发送的授权卡，所述授权卡包括所述授权卡的属主账号的公钥、所述应用网站的公钥以及所述应用网站利用自身的私钥对所述授权卡的签名，所述授权卡用于作为所述用户向可信执行环境TEE设备上配置的TEE申请供所述目标用户使用的用户卡的凭证。
37.根据权利要求36所述的授权卡申请方法，其特征在于，所述授权卡申请请求还包括以下信息中的一项或多项：
所述授权卡的时段类别、所述授权卡的目标时间、所述授权卡的有效期、所述目标用户的组、所述目标用户的任务；
其中，所述目标用户的组用于标记所述目标用户在所述应用网站被授予的等级，以及，标记所述目标用户为所述用户自身或他人；
所述目标用户的任务用于描述所述目标用户在所述应用网站上被授权执行的事项。
38.根据权利要求36所述的授权卡申请方法，其特征在于，所述授权卡还包括以下信息中的一项或多项：
所述授权卡的验根码、所述应用网站的标识、所述目标用户的组、所述授权卡的时段类别、所述授权卡的目标时间、所述授权卡的有效期、所述应用网站分配给所述用户的资源标识、所述目标用户的任务以及所述授权卡的种密。
39.一种授权卡申请方法，其特征在于，应用于应用网站，所述方法包括：
接收已登录所述应用网站的用户通过终端设备发送的授权卡申请请求，所述授权卡申请请求包括目标账号的标识，所述目标账号的标识为所述目标账号的公钥、从所述用户的未公开真身账号推导所述目标账号的衍生路径或空字串；其中，若所述目标账号的标识为从所述未公开真身账号推导所述目标账号的衍生路径或空字串，表示拥有所述目标账号的目标用户为所述用户自身，若所述目标账号的标识为所述目标账号的公钥，表示所述目标用户为他人；
根据所述目标账号的标识判断所述目标用户为所述用户自身或他人；
生成授权卡，所述授权卡包括所述授权卡的属主账号的公钥、所述应用网站的公钥以及所述应用网站利用自身的私钥对所述授权卡的签名，作为所述用户向TEE设备上配置的TEE申请供所述目标用户使用的用户卡的凭证；其中，若所述目标用户为所述用户自身，则所述授权卡的属主账号为所述用户当前通过护照或用户卡登录的账号，若所述目标用户为他人，则所述授权卡的属主账号为所述目标账号；
向所述终端设备发送所述授权卡。
40.根据权利要求39所述的授权卡申请方法，其特征在于，所述授权卡还包括以下信息中的一项或多项：
所述授权卡的验根码、所述应用网站的标识、所述目标用户的组、所述应用网站的公钥、所述授权卡的时段类别、所述授权卡的目标时间、所述授权卡的有效期、所述应用网站分配给所述用户的资源标识、所述目标用户的任务以及所述授权卡的种密；
其中，若所述目标用户为所述用户自身，则所述授权卡的验根码为所述用户当前登录时使用的护照或用户卡中的验根码，若所述目标用户为他人，则所述授权卡的验根码根据所述用户的可公开真身账号的公钥以及所述目标账号的公钥进行计算；
所述授权卡的时段类别、所述授权卡的目标时间、所述授权卡的有效期、所述目标用户的组以及所述目标用户的任务从所述授权卡申请请求中获取；
所述授权卡的种密包括：单向密文密钥，以及，利用所述单向密文密钥对应的明文密钥对所述应用网站提供的安全码的明文进行加密得到的所述安全码的密文；其中，持有所述安全码表明有权使用所述应用网站提供的服务，所述单向密文密钥在TEE中生成，所述TEE只对外提供将所述明文密钥加密为所述单向密文密钥的服务，但不对外提供将所述单向密文密钥解密回所述明文密钥的服务。
41.根据权利要求40所述的授权卡申请方法，其特征在于，在所述生成授权卡之前，所述方法还包括：
向所述TEE设备发送密钥生成请求，所述密钥生成请求包括：第一命令字以及所述明文密钥；其中，所述第一命令字表示请求所述TEE提供生成单向密文密钥的服务，所述TEE只对外提供将所述明文密钥加密为所述单向密文密钥的服务，但不对外提供将所述单向密文密钥解密回所述明文密钥的服务；
接收所述TEE设备发送的所述单向密文密钥。
42.根据权利要求41所述的授权卡申请方法，其特征在于，所述密钥生成请求还包括第一结果加密密钥，所述第一结果加密密钥用于所述TEE对生成的所述单向密文密钥进行加密，所述接收所述TEE设备发送的所述单向密文密钥，包括：
接收所述TEE设备发送的加密后的所述单向密文密钥，并利用所述第一结果加密密钥解密加密后的所述单向密文密钥，获得所述单向密文密钥。
43.根据权利要求41所述的授权卡申请方法，其特征在于，所述密钥生成请求利用所述TEE的第一公钥加密。
44.根据权利要求41所述的授权卡申请方法，其特征在于，所述接收所述TEE设备发送的所述单向密文密钥之后，所述方法还包括：
利用所述明文密钥对原始明文进行加密，获得原始密文；
向所述TEE设备发送转密请求，所述转密请求包括：第二命令字、转密密钥、所述单向密文密钥、所述原始密文；其中，所述第二命令字表示请求所述TEE提供单向密文密钥转密的服务，所述转密密钥用于所述TEE对所述原始明文进行加密得到校验密文；
接收所述TEE设备发送的所述校验密文，并利用所述转密密钥对所述校验密文进行解密，获得校验明文；
判断所述原始明文与所述校验明文是否相同，若相同则表明所述单向密文密钥能够正常工作。
45.一种单向密文密钥生成方法，其特征在于，应用于TEE，所述方法包括：
所述TEE通过配置有所述TEE的TEE设备接收应用网站发送的密钥生成请求，所述密钥生成请求包括：第一命令字以及明文密钥；
所述TEE根据所述第一命令字确定提供生成单向密文密钥的服务，服务的内容包括：所述TEE利用特定密钥对所述明文密钥进行加密，获得单向密文密钥，所述特定密钥仅在所述TEE中使用；
所述TEE通过所述TEE设备向所述应用网站发送所述单向密文密钥。
46.根据权利要求45所述的单向密文密钥生成方法，其特征在于，所述密钥生成请求还包括第一结果加密密钥，生成单向密文密钥的服务内容还包括：
所述TEE利用所述第一结果加密密钥对所述单向密文密钥进行加密，获得加密后的所述单向密文密钥；
所述TEE通过所述TEE设备向所述应用网站发送的所述单向密文密钥为加密后的所述单向密文密钥。
47.根据权利要求45所述的单向密文密钥生成方法，其特征在于，所述密钥生成请求利用所述TEE的第一公钥加密，在所述TEE根据所述第一命令字确定提供生成单向密文密钥的服务之前，所述方法还包括：
所述TEE利用自身的第一私钥对所述密钥生成请求进行解密，所述TEE的第一私钥与所述TEE的第一公钥为一个公私钥对。
48.根据权利要求45所述的单向密文密钥生成方法，其特征在于，在所述TEE通过所述TEE设备向所述应用网站发送所述单向密文密钥之后，所述方法还包括：
所述TEE通过所述TEE设备接收应用网站发送的转密请求，所述转密请求包括：第二命令字、转密密钥、所述单向密文密钥以及原始密文；
所述TEE根据所述第二命令字确定提供单向密文密钥转密的服务，服务的内容包括：所述TEE利用所述特定密钥对所述单向密文密钥进行解密，获得所述明文密钥；所述TEE利用所述明文密钥对所述原始密文进行解密，获得原始明文；所述TEE利用所述转密密钥对所述原始明文进行加密，获得校验密文；
所述TEE通过所述TEE设备向所述应用网站发送所述校验密文。
49.一种用户卡申请方法，其特征在于，应用于终端设备，所述方法包括：
若用户卡针对的目标用户为获得授权卡的用户自身，则从所述用户的未公开真身账号推导所述目标用户的目标账号，并将从所述未公开真身账号推导所述目标账号的衍生路径确定为所述目标账号的标识，若所述目标用户为他人，则将所述目标账号的公钥确定为所述目标账号的标识；
向配置有TEE的TEE设备发送第一用户卡申请请求，所述第一用户卡申请请求包括第三命令字、所述授权卡以及所述目标账号的标识；其中，所述第三命令字表示请求所述TEE提供凭授权卡生成用户卡的服务，若所述目标用户为所述用户自身，则所述第一用户卡申请请求还包括所述未公开真身账号的公钥、所述未公开真身账号的链码以及所述授权卡的属主账号的衍生路径；
接收所述TEE设备发送的用户卡，所述用户卡包括所述目标账号的公钥以及所述TEE利用自身的第二私钥对所述用户卡的签名，所述用户卡用于证明颁发所述授权卡的应用网站已经授权所述目标用户通过登录所述目标账号使用所述应用网站提供的服务。
50.根据权利要求49所述的用户卡申请方法，其特征在于，所述从所述用户的未公开真身账号推导所述目标账号，包括：
按照HD钱包中规定的衍生方式从所述用户的未公开真身账号推导所述目标账号。
51.根据权利要求49所述的用户卡申请方法，其特征在于，所述用户的可公开真身账号由所述未公开真身账号经预设的相对路径推导产生；
若所述用户在申请所述授权卡时通过护照方式登录，则所述授权卡的属主账号的衍生路径为一个由从所述可公开真身账号推导所述授权卡的属主账号的衍生路径以及所述相对路径拼接后得到的、以所述未公开真身账号为推导起点的衍生路径，若所述用户在申请所述授权卡时通过用户卡方式登录，则所述授权卡的属主账号的衍生路径为从所述未公开真身账号推导所述授权卡的属主账号的衍生路径。
52.根据权利要求49所述的用户卡申请方法，其特征在于，所述第一用户卡申请请求还包括以下信息中的一项或多项：
所述用户卡的目标时间以及第二结果加密密钥；
其中，所述用户卡的目标时间为所述授权卡的目标时间，所述第二结果加密密钥用于所述TEE对生成的所述用户卡进行加密。
53.根据权利要求52所述的用户卡申请方法，其特征在于，所述第一用户卡申请请求包括所述第二结果加密密钥，所述接收所述TEE设备发送的用户卡，包括：
接收所述TEE设备发送的加密后的所述用户卡，并利用所述第二结果加密密钥解密加密后的所述用户卡，获得所述用户卡。
54.根据权利要求49所述的用户卡申请方法，其特征在于，所述第一用户卡申请请求利用所述TEE的第一公钥加密。
55.一种用户卡申请方法，其特征在于，应用于TEE，所述方法包括：
所述TEE通过配置有所述TEE的TEE设备接收获得授权卡的用户通过终端设备发送的第一用户卡申请请求，所述第一用户卡申请请求包括第三命令字、所述授权卡以及目标账号的标识；其中，若拥有所述目标账号的目标用户为所述用户自身，则所述第一用户卡申请请求还包括所述用户的未公开真身账号的公钥、所述未公开真身账号的链码以及授权卡的属主账号的衍生路径；
所述TEE根据所述第三命令字确定提供凭授权卡生成用户卡的服务，服务的内容包括：所述TEE利用所述第一用户卡申请请求进行申请验证，验证项目包括以下至少一项：所述TEE利用所述授权卡中的应用网站的公钥验证对所述授权卡的签名是否正确；所述TEE根据所述目标账号的标识判断所述目标用户为所述用户自身或他人，若所述目标用户为所述用户自身，则所述TEE利用所述未公开真身账号的公钥、所述未公开真身账号的链码、所述目标账号的标识、所述授权卡、所述授权卡的属主账号的衍生路径验证所述属主账号是否属于所述目标用户；若所有验证项目的结果均为“是”，则所述TEE生成用户卡，所述用户卡包括所述目标账号的公钥以及所述TEE利用自身的第二私钥对所述用户卡的签名，所述用户卡用于证明所述应用网站已经授权所述目标用户通过登录所述目标账号使用所述应用网站提供的服务；其中，若所述目标用户为所述用户自身，则所述目标账号的公钥在验证所述属主账号是否属于所述目标用户时获得，若所述目标用户为他人，则所述目标账号的公钥为所述授权卡的属主账号的公钥；
所述TEE通过所述TEE设备向所述终端设备发送所述用户卡。
56.根据权利要求55所述的用户卡申请方法，其特征在于，所述TEE利用所述未公开真身账号的公钥、所述未公开真身账号的链码、所述目标账号的标识、所述授权卡、所述授权卡的属主账号的衍生路径验证所述属主账号是否属于所述目标用户，包括：
所述TEE利用所述未公开真身账号的公钥、所述未公开真身账号的链码以及所述目标账号的标识推导所述目标账号的公钥；
所述TEE利用所述未公开真身账号的公钥、所述未公开真身账号的链码以及所述授权卡的属主账号的衍生路径推导校验账号的公钥，并判断所述校验账号的公钥与所述授权卡的属主账号的公钥是否相同，若相同则确定所述属主账号属于所述目标用户，否则确定所述属主账号不属于所述目标用户；其中，所述授权卡的属主账号的衍生路径是指从所述未公开真身账号推导所述授权卡的属主账号的衍生路径。
57.根据权利要求55所述的用户卡申请方法，其特征在于，所述授权卡包括所述授权卡的验根码，所述TEE利用所述未公开真身账号的公钥、所述未公开真身账号的链码、所述目标账号的标识、所述授权卡、所述授权卡的属主账号的衍生路径验证所述属主账号是否属于所述目标用户，包括：
所述TEE利用所述未公开真身账号的公钥、所述未公开真身账号的链码以及所述目标账号的标识推导所述目标账号的公钥；
所述TEE利用所述未公开真身账号的公钥、所述未公开真身账号的链码以及预先配置于所述TEE中的相对路径推导所述用户的可公开真身账号的公钥；其中，所述相对路径是指从所述未公开真身账号推导所述可公开真身账号的衍生路径；
所述TEE根据所述可公开真身账号的公钥以及所述授权卡的属主账号的衍生路径计算第一校验验根码；
所述TEE判断所述第一校验验根码与所述授权卡的验根码是否相同，若相同则确定所述属主账号属于所述目标用户，否则确定所述属主账号不属于所述目标用户。
58.根据权利要求55所述的用户卡申请方法，其特征在于，所述用户卡还包括以下信息中的一项或多项：
所述用户卡的验根码、所述应用网站的标识、所述目标用户的组、所述应用网站的公钥、所述用户卡的时段类别、所述用户卡的目标时间、所述用户卡的有效期、所述应用网站分配给所述用户的资源标识、所述目标用户的任务、所述用户卡的时段推导码以及所述用户卡的时段唯一码；
其中，所述用户卡的验根码根据所述用户的可公开真身账号的公钥以及所述目标账号的标识进行计算，所述可公开真身账号的公钥利用所述未公开真身账号的公钥、所述未公开真身账号的链码以及预先配置于所述TEE中的相对路径推导产生，所述相对路径是指从所述未公开真身账号推导所述可公开真身账号的衍生路径；
所述应用网站的标识、所述目标用户的组、所述应用网站的公钥、所述用户卡的时段类别、所述用户卡的目标时间、所述用户卡的有效期、所述应用网站分配给所述用户的资源标识以及所述目标用户的任务从所述授权卡中对应的信息项复制；
所述用户卡的时段推导码根据所述可公开真身账号的公钥、指定字串、所述用户卡的目标时间所在的时段、所述应用网站的标识以及所述目标用户的组进行计算，所述用户卡的目标时间所在的时段根据所述用户卡的目标时间以及所述用户卡的时段类别进行计算；
所述用户卡的时段唯一码根据所述应用网站提供的安全码、所述可公开真身账号的公钥以及所述指定字串进行计算；其中，所述安全码从所述授权卡的种密中解密得到。
59.根据权利要求58所述的用户卡申请方法，其特征在于，所述指定字串nonce_string根据如下公式计算：
nonce_string＝TimeSegment+Domain+Group
所述用户卡的时段推导码TimeSession根据如下公式计算：
TimeSession＝hash(OpenPublicKey+nonce_string)^
hash(TimeSegment+Domain+Group)
所述用户卡的时段唯一码LoginSession根据如下公式计算：
LoginSession＝hash(Secret+hash(OpenPublicKey+nonce_string))
其中，TimeSegment为所述用户卡的目标时间所在的时段，TimeSegmnet根据所述用户卡的目标时间以及所述用户卡的时段类别进行计算，Domain为所述应用网站的标识、Group为所述目标用户的组，OpenPublicKey为所述可公开真身账号的公钥，hash表示哈希运算，+表示字串拼接，^表示异或运算。
60.根据权利要求55所述的用户卡申请方法，其特征在于，所述第一用户卡申请请求还包括第二结果加密密钥，凭授权卡生成用户卡的服务内容还包括：
利用所述第二结果加密密钥对所述用户卡进行加密，获得加密后的所述用户卡；
所述TEE通过所述TEE设备向所述终端设备发送的所述用户卡为加密后的所述用户卡。
61.根据权利要求55所述的用户卡申请方法，其特征在于，所述第一用户卡申请请求利用所述TEE的第一公钥加密，在所述TEE根据所述第三命令字确定提供凭授权卡生成用户卡的服务之前，所述方法还包括：
所述TEE利用自身的第一私钥对所述用户卡生成请求进行解密，所述TEE的第一私钥与所述TEE的第一公钥为一个公私钥对。
62.根据权利要求55所述的用户卡申请方法，其特征在于，所述TEE设备通过TEE服务接入点接入到区块链网络，所述TEE服务接入点为所述区块链网络中的矿池节点或挖矿节点。
63.根据权利要求62所述的用户卡申请方法，其特征在于，所述TEE设备还通过所述TEE参与所述区块链网络中的记账权竞争。
64.根据权利要求63所述的用户卡申请方法，其特征在于，需要所述TEE处理的竞争记账权请求利用所述TEE的第一公钥加密。
65.根据权利要求62所述的用户卡申请方法，其特征在于，所述方法还包括：
所述TEE对凭授权卡生成用户卡的服务被调用的次数进行统计，作为服务提供方获取数字货币奖励的依据。
66.一种用户卡申请方法，其特征在于，应用于终端设备，所述方法包括：
向配置有TEE的TEE设备发送第二用户卡申请请求，所述第二用户卡申请请求包括第四命令字、用户申请的授权卡、目标账号的标识、所述用户的可公开真身账号的公钥、所述用户申请的护照以及所述授权卡的属主账号的衍生路径；其中，所述第四命令字表示请求所述TEE提供凭护照及授权卡生成用户卡的服务，所述目标账号的标识为从所述可公开真身账号推导所述护照中的化身账号的衍生路径；
接收所述TEE设备发送的用户卡，所述用户卡包括所述目标账号的公钥以及所述TEE利用自身的第二私钥对所述用户卡的签名，所述用户卡用于证明颁发所述授权卡的应用网站已经授权拥有所述目标账号的目标用户通过登录所述目标账号使用所述应用网站提供的服务。
67.一种用户卡申请方法，其特征在于，应用于TEE，所述方法包括：
所述TEE通过配置有所述TEE的TEE设备接收用户通过终端设备发送的第二用户卡申请请求，所述第二用户卡申请请求包括第四命令字、用户申请的授权卡、目标账号的标识、所述用户的可公开真身账号的公钥、所述用户申请的护照以及所述授权卡的属主账号的衍生路径；
所述TEE根据所述第四命令字确定提供凭护照及授权卡生成用户卡的服务，服务的内容包括：所述TEE利用所述第二用户卡申请请求进行申请验证，验证项目包括以下至少一项：所述TEE利用所述授权卡中的应用网站的公钥验证对所述授权卡的签名是否正确；所述TEE利用所述护照中的管理网站的第一公钥验证对所述护照的签名是否正确；所述TEE利用所述可公开真身账号的公钥、所述护照、所述目标账号的标识、所述授权卡、所述授权卡的属主账号的衍生路径验证所述护照中的化身账号以及所述属主账号是否均属于拥有所述目标账号的目标用户；若所有验证项目的结果均为“是”，则所述TEE生成用户卡，所述用户卡包括所述目标账号的公钥以及所述TEE利用自身的第二私钥对所述用户卡的签名，所述用户卡用于证明所述应用网站已经授权所述目标用户通过登录所述目标账号使用所述应用网站提供的服务；其中，所述目标账号的公钥为所述护照中的化身账号的公钥；
所述TEE通过所述TEE设备向所述终端设备发送所述用户卡。
68.根据权利要求67所述的用户卡申请方法，其特征在于，所述护照包括所述护照的验根码，所述授权卡包括所述授权卡的验根码，所述TEE利用所述可公开真身账号的公钥、所述护照、所述目标账号的标识、所述授权卡、所述授权卡的属主账号的衍生路径验证所述护照中的化身账号以及所述属主账号是否均属于所述目标用户，包括：
所述TEE利用所述可公开真身账号的公钥以及授权卡的属主账号的衍生路径计算第二校验验根码，验证所述第二校验验根码与所述授权卡的验根码是否相同；
所述TEE利用所述可公开真身账号的公钥以及所述目标账号的标识计算第三校验验根码，验证所述第三校验验证码与所述护照的验根码是否相同；
所述TEE若以上两项的验证结果均为“是”，则确定所述护照中的化身账号以及所述授权卡的属主账号均属于所述目标用户，否则确定所述护照中的化身账号以及所述授权卡的属主账号并非均属于所述目标用户。
69.根据权利要求67所述的用户卡申请方法，其特征在于，所述用户卡还包括以下信息中的一项或多项：
所述用户卡的验根码、所述应用网站的标识、所述目标用户的组、所述应用网站的公钥、所述用户卡的时段类别、所述用户卡的目标时间、所述用户卡的有效期、所述应用网站分配给所述用户的资源标识、所述目标用户的任务、所述用户卡的时段推导码以及所述用户卡的时段唯一码；
其中，所述用户卡的验根码为所述护照的验根码；
所述应用网站的标识、所述目标用户的组、所述应用网站的公钥、所述用户卡的时段类别、所述用户卡的目标时间、所述用户卡的有效期、所述应用网站分配给所述用户的资源标识以及所述目标用户的任务从所述授权卡中对应的信息项复制；
所述用户卡的时段推导码根据所述可公开真身账号的公钥、指定字串、所述授权卡的时段类别、所述授权卡中所述应用网站的标识以及所述授权卡中所述目标用户的组进行计算；
所述用户卡的时段唯一码根据所述应用网站提供的安全码、所述可公开真身账号的公钥以及所述指定字串进行计算；其中，所述安全码从所述授权卡的种密中解密得到。
70.一种护照申请装置，其特征在于，配置于终端设备，所述装置包括：
第一护照账号推导模块，用于利用用户在管理网站实名注册过的可公开真身账号推导化身账号；
护照申请模块，用于向所述管理网站发送护照申请请求，所述护照申请请求包括所述可公开真身账号的公钥、所述可公开真身账号的链码、从所述可公开真身账号推导所述化身账号的衍生路径以及利用所述可公开真身账号的私钥对所述护照申请请求的签名；
护照接收模块，用于接收所述管理网站发送的护照，所述护照包括所述化身账号的公钥、所述管理网站的第一公钥以及所述管理网站利用自身的第一私钥对所述护照的签名，所述护照用于证明所述化身账号由一个在所述管理网站实名注册过的可公开真身账号推导产生；其中，所述管理网站的第一私钥与所述管理网站的第一公钥为一个公私钥对。
71.一种护照申请装置，其特征在于，配置于管理网站，所述装置包括：
护照申请请求接收模块，用于接收终端设备发送的护照申请请求，所述护照申请请求包括用户的可公开真身账号的公钥、所述可公开真身账号的链码、从所述可公开真身账号推导化身账号的衍生路径以及利用所述可公开真身账号的私钥对所述护照申请请求的签名；
护照申请验证模块，用于利用所述护照申请请求进行申请验证，验证项目包括以下至少一项：验证所述可公开真身账号的公钥是否已经进行过实名注册；利用所述可公开真身账号的公钥验证对所述护照申请请求的签名是否正确；
第二护照账号推导模块，用于若所有验证项目的结果均为“是”，则利用所述可公开真身账号的公钥、所述可公开真身账号的链码以及从所述可公开真身账号推导所述化身账号的衍生路径推导所述化身账号的公钥；
护照生成模块，用于生成护照，所述护照包括所述化身账号的公钥、所述管理网站的第一公钥以及所述管理网站利用自身的第一私钥对所述护照的签名，所述护照用于证明所述化身账号由一个在所述管理网站实名注册过的可公开真身账号推导产生；其中，所述管理网站的第一私钥与所述管理网站的第一公钥为一个公私钥对；
护照发送模块，用于向所述终端设备发送所述护照。
72.一种用户注册装置，其特征在于，配置于终端设备，所述装置包括：
用户注册模块，用于向应用网站发送用户注册请求，所述用户注册请求包括管理网站颁发的护照，所述护照包括用户要注册的化身账号的公钥、所述管理网站的第一公钥以及所述管理网站利用自身的第一私钥对所述护照的签名，所述护照用于证明所述化身账号由一个在所述管理网站实名注册过的可公开真身账号推导产生；其中，所述管理网站的第一私钥与所述管理网站的第一公钥为一个公私钥对。
73.一种用户注册装置，其特征在于，配置于应用网站，所述装置包括：
用户注册请求接收模块，用于接收终端设备发送用户注册请求，所述用户注册请求包括管理网站颁发的护照，所述护照包括用户要注册的化身账号的公钥、所述管理网站的第一公钥以及所述管理网站利用自身的第一私钥对所述护照的签名，所述护照用于证明所述化身账号由一个在所述管理网站实名注册过的可公开真身账号推导产生；其中，所述管理网站的第一私钥与所述管理网站的第一公钥为一个公私钥对；
用户注册验证模块，用于利用所述用户注册请求进行注册验证，验证项目包括以下至少一项：验证所述化身账号的公钥是否尚未绑定资源标识；利用所述管理网站的第一公钥验证对所述护照的签名是否正确；
资源标识绑定模块，用于若所有验证项目的结果均为“是”，则为所述用户分配一个资源标识，并绑定所述化身账号的公钥与所述资源标识；
用户注册响应模块，用于保存所述护照或所述护照中的预设信息项，并向所述终端设备发送注册成功的响应。
74.一种用户登录装置，其特征在于，配置于终端设备，所述装置包括：
第一登录模块，用于向应用网站发送第一用户登录请求，所述第一用户登录请求包括管理网站颁发的护照，所述护照包括用户要登录的化身账号的公钥、所述管理网站的第一公钥以及所述管理网站利用自身的第一私钥对所述护照的签名，所述护照用于证明所述化身账号由一个在所述管理网站实名注册过的可公开真身账号推导产生；其中，所述管理网站的第一私钥与所述管理网站的第一公钥为一个公私钥对。
75.一种用户登录装置，其特征在于，配置于应用网站，所述装置包括：
第一用户登录请求接收模块，用于接收终端设备发送第一用户登录请求，所述第一用户登录请求包括管理网站颁发的护照，所述护照包括用户要登录的化身账号的公钥、所述管理网站的第一公钥以及所述管理网站利用自身的第一私钥对所述护照的签名，所述护照用于证明所述化身账号由一个在所述管理网站实名注册过的可公开真身账号推导产生；其中，所述管理网站的第一私钥与所述管理网站的第一公钥为一个公私钥对；
第一用户登录请求验证模块，用于利用所述第一用户登录请求进行登录验证，验证项目包括以下至少一项：验证所述化身账号的公钥是否已经绑定资源标识；利用所述管理网站的第一公钥验证对所述护照的签名是否正确；
第一登录响应模块，用于若所有验证项目的结果均为“是”，则向所述终端设备发送登录成功的响应。
76.一种授权卡申请装置，其特征在于，配置于终端设备，所述装置包括：
授权卡申请模块，用于向用户已登录的应用网站发送授权卡申请请求，所述授权卡申请请求包括目标账号的标识，所述目标账号的标识为所述目标账号的公钥、从所述用户的未公开真身账号推导所述目标账号的衍生路径或空字串；其中，若所述目标账号的标识为从所述未公开真身账号推导所述目标账号的衍生路径或空字串，表示拥有所述目标账号的目标用户为所述用户自身，若所述目标账号的标识为所述目标账号的公钥，表示所述目标用户为他人；
授权卡接收模块，用于接收所述应用网站发送的授权卡，所述授权卡包括所述授权卡的属主账号的公钥、所述应用网站的公钥以及所述应用网站利用自身的私钥对所述授权卡的签名，所述授权卡用于作为所述用户向TEE设备上配置的TEE申请供所述目标用户使用的用户卡的凭证。
77.一种授权卡申请装置，其特征在于，配置于应用网站，所述装置包括：
授权卡申请请求接收模块，用于接收已登录所述应用网站的用户通过终端设备发送的授权卡申请请求，所述授权卡申请请求包括目标账号的标识，所述目标账号的标识为所述目标账号的公钥、从所述用户的未公开真身账号推导所述目标账号的衍生路径或空字串；其中，若所述目标账号的标识为从所述未公开真身账号推导所述目标账号的衍生路径或空字串，表示拥有所述目标账号的目标用户为所述用户自身，若所述目标账号的标识为所述目标账号的公钥，表示所述目标用户为他人；
身份判断模块，用于根据所述目标账号的标识判断所述目标用户为所述用户自身或他人；
授权卡生成模块，用于生成授权卡，所述授权卡包括所述授权卡的属主账号的公钥、所述应用网站的公钥以及所述应用网站利用自身的私钥对所述授权卡的签名，作为所述用户向TEE设备上配置的TEE申请供所述目标用户使用的用户卡的凭证；其中，若所述目标用户为所述用户自身，则所述属主账号为所述用户当前通过护照或用户卡登录的账号，若所述目标用户为他人，则所述授权卡的属主账号为所述目标账号；
授权卡发送模块，用于向所述终端设备发送所述授权卡。
78.一种单向密文密钥生成装置，其特征在于，配置于TEE，所述装置包括：
密钥生成请求接收模块，用于所述TEE通过配置有所述TEE的TEE设备接收应用网站发送的密钥生成请求，所述密钥生成请求包括：第一命令字以及明文密钥；
单向密文密钥生成模块，用于所述TEE根据所述第一命令字确定提供生成单向密文密钥的服务，服务的内容包括：所述TEE利用特定密钥对所述明文密钥进行加密，获得单向密文密钥，所述特定密钥仅在所述TEE中使用；
单向密文密钥发送模块，用于所述TEE通过所述TEE设备向所述应用网站发送所述单向密文密钥。
79.一种用户卡申请装置，其特征在于，配置于终端设备，所述装置包括：
标识获取模块，用于若用户卡针对的目标用户为获得授权卡的用户自身，则从所述用户的未公开真身账号推导所述目标用户的目标账号，并将从所述未公开真身账号推导所述目标账号的衍生路径确定为所述目标账号的标识，若所述目标用户为他人，则将所述目标账号的公钥确定为所述目标账号的标识；
第一用户卡申请模块，用于向配置有TEE的TEE设备发送第一用户卡申请请求，所述第一用户卡申请请求包括第三命令字、所述授权卡以及所述目标账号的标识；其中，所述第三命令字表示请求所述TEE提供凭授权卡生成用户卡的服务，若所述目标用户为所述用户自身，则所述第一用户卡申请请求还包括所述未公开真身账号的公钥、所述未公开真身账号的链码以及所述授权卡的属主账号的衍生路径；
第一用户卡接收模块，用于接收所述TEE设备发送的用户卡，所述用户卡包括所述目标账号的公钥以及所述TEE利用自身的第二私钥对所述用户卡的签名，所述用户卡用于证明颁发所述授权卡的应用网站已经授权所述目标用户通过登录所述目标账号使用所述应用网站提供的服务。
80.一种用户卡申请装置，其特征在于，配置于TEE，所述装置包括：
第一用户卡申请请求接收模块，用于所述TEE通过配置有所述TEE的TEE设备接收获得授权卡的用户通过终端设备发送的第一用户卡申请请求，所述第一用户卡申请请求包括第三命令字、所述授权卡以及目标账号的标识；其中，若拥有所述目标账号的目标用户为所述用户自身，则所述第一用户卡申请请求还包括所述用户的未公开真身账号的公钥、所述未公开真身账号的链码以及授权卡的属主账号的衍生路径；
第一用户卡生成模块，用于所述TEE根据所述第三命令字确定提供凭授权卡生成用户卡的服务，服务的内容包括：所述TEE利用所述第一用户卡申请请求进行申请验证，验证项目包括以下至少一项：所述TEE利用所述授权卡中的应用网站的公钥验证对所述授权卡的签名是否正确；所述TEE根据所述目标账号的标识判断所述目标用户为所述用户自身或他人，若所述目标用户为所述用户自身，则所述TEE利用所述未公开真身账号的公钥、所述未公开真身账号的链码、所述目标账号的标识、所述授权卡、所述授权卡的属主账号的衍生路径验证所述属主账号是否属于所述目标用户；若所有验证项目的结果均为“是”，则所述TEE生成用户卡，所述用户卡包括所述目标账号的公钥以及所述TEE利用自身的第二私钥对所述用户卡的签名，所述用户卡用于证明所述应用网站已经授权所述目标用户通过登录所述目标账号使用所述应用网站提供的服务；其中，若所述目标用户为所述用户自身，则所述目标账号的公钥在验证所述属主账号是否属于所述目标用户时获得，若所述目标用户为他人，则所述目标账号的公钥为所述授权卡的属主账号的公钥；
第一用户卡发送模块，用于所述TEE通过所述TEE设备向所述终端设备发送所述用户卡。
81.一种用户卡申请装置，其特征在于，配置于终端设备，所述装置包括：
第二用户卡申请模块，用于向配置有TEE的TEE设备发送第二用户卡申请请求，所述第二用户卡申请请求包括第四命令字、用户申请的授权卡、目标账号的标识、所述用户的可公开真身账号的公钥、所述用户申请的护照以及所述授权卡的属主账号的衍生路径；其中，所述第四命令字表示请求所述TEE提供凭护照及授权卡生成用户卡的服务，所述目标账号的标识为从所述可公开真身账号推导所述护照中的化身账号的衍生路径；
第二用户卡接收模块，用于接收所述TEE设备发送的用户卡，所述用户卡包括所述目标账号的公钥以及所述TEE利用自身的第二私钥对所述用户卡的签名，所述用户卡用于证明颁发所述授权卡的应用网站已经授权拥有所述目标账号的目标用户通过登录所述目标账号使用所述应用网站提供的服务。
82.一种用户卡申请装置，其特征在于，配置于TEE，所述装置包括：
第二用户卡申请请求接收模块，用于所述TEE通过配置有所述TEE的TEE设备接收用户通过终端设备发送的第二用户卡申请请求，所述第二用户卡申请请求包括第四命令字、用户申请的授权卡、目标账号的标识、所述用户的可公开真身账号的公钥、所述用户申请的护照以及所述授权卡的属主账号的衍生路径；
第二用户卡生成模块，用于所述TEE根据所述第四命令字确定提供凭护照及授权卡生成用户卡的服务，服务的内容包括：所述TEE利用所述第二用户卡申请请求进行申请验证，验证项目包括以下至少一项：所述TEE利用所述授权卡中的应用网站的公钥验证对所述授权卡的签名是否正确；所述TEE利用所述护照中的管理网站的第一公钥验证对所述护照的签名是否正确；所述TEE利用所述可公开真身账号的公钥、所述护照、所述目标账号的标识、所述授权卡、所述授权卡的属主账号的衍生路径验证所述护照中的化身账号以及所述属主账号是否均属于拥有所述目标账号的目标用户；若所有验证项目的结果均为“是”，则所述TEE生成用户卡，所述用户卡包括所述目标账号的公钥以及所述TEE利用自身的第二私钥对所述用户卡的签名，所述用户卡用于证明所述应用网站已经授权所述目标用户通过登录所述目标账号使用所述应用网站提供的服务；其中，所述目标账号的公钥为所述护照中的化身账号的公钥；
第二用户卡发送模块，用于所述TEE通过所述TEE设备向所述终端设备发送所述用户卡。
83.一种用户登录装置，其特征在于，配置于终端设备，所述装置包括：
第二登录模块，用于向应用网站发送第二用户登录请求，所述第二用户登录请求包括TEE中生成的用户卡，所述用户卡包括目标用户要登录的目标账号的公钥以及所述TEE利用自身的第二私钥对所述用户卡的签名，所述用户卡用于证明所述应用网站已经授权所述目标用户通过登录所述目标账号使用所述应用网站提供的服务。
84.一种用户登录装置，其特征在于，配置于应用网站，所述装置包括：
第二用户登录请求接收模块，用于接收终端设备发送第二用户登录请求，所述第二用户登录请求包括TEE中生成的用户卡，所述用户卡包括目标用户要登录的目标账号的公钥以及所述TEE利用自身的第二私钥对所述用户卡的签名，所述用户卡用于证明所述应用网站已经授权所述目标用户通过登录所述目标账号使用所述应用网站提供的服务；
第二用户登录请求验证模块，用于利用所述第二用户登录请求进行登录验证，验证项目包括以下至少一项：利用所述TEE的第二公钥验证对所述用户卡的签名是否正确，所述TEE的第二公钥与所述TEE的第二私钥为一个公私钥对；
第二登录响应模块，用于若所有验证项目的结果均为“是”，则向所述终端设备发送登录成功的响应。
85.一种终端设备，其特征在于，包括：存储器以及处理器，所述存储器中存储有计算机程序指令，所述计算机程序指令被所述处理器读取并运行时，执行如权利要求1-2、7-8、15-20、27-28、36-38、49-54、66中任一项所述的方法。
86.一种管理网站的服务器，其特征在于，包括：存储器以及处理器，所述存储器中存储有计算机程序指令，所述计算机程序指令被所述处理器读取并运行时，执行如权利要求21-26中任一项所述的方法。
87.一种应用网站的服务器，其特征在于，包括：存储器以及处理器，所述存储器中存储有计算机程序指令，所述计算机程序指令被所述处理器读取并运行时，执行如权利要求3-6、9-14、29-35、39-44中任一项所述的方法。
88.一种TEE，其特征在于，包括：存储器以及处理器，所述存储器中存储有计算机程序指令，所述计算机程序指令被所述处理器读取并运行时，执行如权利要求45-48、55-65、67-69中任一项所述的方法。
89.一种TEE设备，其特征在于，所述TEE设备上配置有如权利要求88所述的TEE。
90.一种计算机可读存储介质，其特征在于，所述计算机可读存储介质上存储有计算机程序指令，所述计算机程序指令被计算机运行时，执行如权利要求1-69中任一项所述的方法。
CN201910977261.1A 2019-10-14 2019-10-14 一种用户注册方法、用户登录方法及对应装置 Active CN112733096B (zh)

Priority Applications (3)

Application Number Priority Date Filing Date Title
CN201910977261.1A CN112733096B (zh) 2019-10-14 2019-10-14 一种用户注册方法、用户登录方法及对应装置
PCT/CN2020/117104 WO2021073383A1 (zh) 2019-10-14 2020-09-23 一种用户注册方法、用户登录方法及对应装置
US17/719,552 US20220318356A1 (en) 2019-10-14 2022-04-13 User registration method, user login method and corresponding device

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN201910977261.1A CN112733096B (zh) 2019-10-14 2019-10-14 一种用户注册方法、用户登录方法及对应装置

Publications (2)

Publication Number Publication Date
CN112733096A true CN112733096A (zh) 2021-04-30
CN112733096B CN112733096B (zh) 2024-02-27

Family

ID=75538327

Family Applications (1)

Application Number Title Priority Date Filing Date
CN201910977261.1A Active CN112733096B (zh) 2019-10-14 2019-10-14 一种用户注册方法、用户登录方法及对应装置

Country Status (3)

Country Link
US (1) US20220318356A1 (zh)
CN (1) CN112733096B (zh)
WO (1) WO2021073383A1 (zh)

Families Citing this family (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20240146531A1 (en) * 2022-10-28 2024-05-02 Apple Inc. Mobile identification techniques

Citations (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN102355351A (zh) * 2011-07-21 2012-02-15 华为技术有限公司 一种基于可信计算的密钥生成、备份和迁移方法及系统
US8719952B1 (en) * 2011-03-25 2014-05-06 Secsign Technologies Inc. Systems and methods using passwords for secure storage of private keys on mobile devices
CN107196965A (zh) * 2017-07-04 2017-09-22 烟台大学 一种安全网络实名登记注册技术
CN107357903A (zh) * 2017-07-14 2017-11-17 泰康保险集团股份有限公司 用户行为数据整合方法、装置及电子设备
DE202015009562U1 (de) * 2015-03-27 2018-04-30 Black Gold Coin, Inc. System zur persönlichen Identifizierung und Verifizierung
CN109005186A (zh) * 2018-08-20 2018-12-14 杭州复杂美科技有限公司 一种隔离用户身份信息的方法、系统、设备和存储介质
CN109120597A (zh) * 2018-07-18 2019-01-01 阿里巴巴集团控股有限公司 身份校验、登录方法、装置及计算机设备
CN109409893A (zh) * 2018-08-20 2019-03-01 杭州复杂美科技有限公司 一种信任系统及其构建方法、设备及存储介质
US20190312877A1 (en) * 2016-12-23 2019-10-10 Cloudminds (Shenzhen) Robotics Systems Co., Ltd. Block chain mining method, device, and node apparatus

Family Cites Families (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US10498541B2 (en) * 2017-02-06 2019-12-03 ShocCard, Inc. Electronic identification verification methods and systems

Patent Citations (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8719952B1 (en) * 2011-03-25 2014-05-06 Secsign Technologies Inc. Systems and methods using passwords for secure storage of private keys on mobile devices
CN102355351A (zh) * 2011-07-21 2012-02-15 华为技术有限公司 一种基于可信计算的密钥生成、备份和迁移方法及系统
DE202015009562U1 (de) * 2015-03-27 2018-04-30 Black Gold Coin, Inc. System zur persönlichen Identifizierung und Verifizierung
US20190312877A1 (en) * 2016-12-23 2019-10-10 Cloudminds (Shenzhen) Robotics Systems Co., Ltd. Block chain mining method, device, and node apparatus
CN107196965A (zh) * 2017-07-04 2017-09-22 烟台大学 一种安全网络实名登记注册技术
CN107357903A (zh) * 2017-07-14 2017-11-17 泰康保险集团股份有限公司 用户行为数据整合方法、装置及电子设备
CN109120597A (zh) * 2018-07-18 2019-01-01 阿里巴巴集团控股有限公司 身份校验、登录方法、装置及计算机设备
CN109005186A (zh) * 2018-08-20 2018-12-14 杭州复杂美科技有限公司 一种隔离用户身份信息的方法、系统、设备和存储介质
CN109409893A (zh) * 2018-08-20 2019-03-01 杭州复杂美科技有限公司 一种信任系统及其构建方法、设备及存储介质

Also Published As

Publication number Publication date
US20220318356A1 (en) 2022-10-06
CN112733096B (zh) 2024-02-27
WO2021073383A1 (zh) 2021-04-22

Similar Documents

Publication Publication Date Title
US11314891B2 (en) Method and system for managing access to personal data by means of a smart contract
JP7241216B2 (ja) ブロックチェーンベースの暗号通貨のためのトークンを検証する、コンピュータにより実行される方法及びシステム
CN109598616B (zh) 一种引入仲裁机制的区块链数据隐私保护的方法
KR101816653B1 (ko) 스마트 컨트랙트 및 블록체인 데이터베이스를 사용하여 서비스 제공 서버에 의하여 제공되는 서비스를 이용하기 위한 사용자의 로그인 요청에 대하여 pki 기반의 인증을 통해 로그인을 대행하는 방법 및 이를 이용한 서버
KR101816651B1 (ko) Utxo 기반 프로토콜의 블록체인 데이터베이스를 사용하여 서비스 제공 서버에 의하여 제공되는 서비스를 이용하기 위한 사용자의 로그인 요청에 대하여 pki 기반의 인증을 통해 로그인을 대행하는 방법 및 이를 이용한 서버
US8843415B2 (en) Secure software service systems and methods
US20200127813A1 (en) Method and system for creating a user identity
US8402527B2 (en) Identity broker configured to authenticate users to host services
US8667287B2 (en) Transaction auditing for data security devices
US20190295069A1 (en) Systems and methods for integrating cryptocurrency wallet identifiers with digital certificates
US20110314532A1 (en) Identity provider server configured to validate authentication requests from identity broker
CN112000951B (zh) 一种访问方法、装置、系统、电子设备及存储介质
CN109450843B (zh) 一种基于区块链的ssl证书管理方法及系统
JP2002537685A (ja) オンボードシステムによって生成される公開鍵の使用を検証する方法
WO2015116998A2 (en) Electronic transfer and obligation enforcement system
CN113129518B (zh) 电动车辆充电系统及其资源管理方法
JP2000511660A (ja) 暗号的保護通信を伴うシステムおよびその方法
KR101816652B1 (ko) Utxo 기반 프로토콜에서 머클 트리 구조를 사용하여 서비스 제공 서버에 의하여 제공되는 서비스를 이용하기 위한 사용자의 로그인 요청에 대하여 pki 기반의 인증을 통해 로그인을 대행하는 방법 및 이를 이용한 서버
CN114008968A (zh) 用于计算环境中的许可授权的系统、方法和存储介质
CN101546407A (zh) 基于数字证书的电子商务系统及其管理方法
CN104125230A (zh) 一种短信认证服务系统以及认证方法
CN113676447A (zh) 基于区块链的科技服务平台跨域身份认证方案
KR101120059B1 (ko) 클라우드 컴퓨팅 과금 공증장치, 과금 시스템 및 과금방법
US20220318356A1 (en) User registration method, user login method and corresponding device
Ahmed et al. Transparency of SIM profiles for the consumer remote SIM provisioning protocol

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