UMID去中心化身份认证解决方案(草稿)
相关索引
UMID 去中心化身份认证平台设计文档
https://www.yuque.com/docs/share/a9dd79b8-dc61-4a29-98c6-c6583e6cf888?#
UMID 实现层字段说明(DID)
https://www.yuque.com/docs/share/6412f7d2-6f28-4e27-8f66-9077f5c66eca?#
UMVC 实现层字段说明(VC)
https://www.yuque.com/docs/share/2dfdcc51-14f7-423f-a151-701bcd7e6b78?#
DID 测试要求:
https://www.yuque.com/docs/share/d0bfb89f-434e-481d-af02-5947e0d03901?#
VC 测试要求:
https://www.yuque.com/docs/share/51c26ac4-ef9d-4f92-8adc-79160bbf4b12?#
背景与现状
在社会科学中,身份是指一个人或者一个群体的品质、信仰、人格和外貌等因素的组合。其中人指心理学上的自我认同,群体指社会学上的集体认同。
数字身份是计算机系统用来表述外部实体的信息,一个数字身份就是一个与实体相关的属性集,外部实体可以是一个人、一个组织、一个应用或者一个设备等等。
一个人只拥有一个身份,如身份证号码,一个身份则可以拥有多个数字身份,比如在多个平台分别拥有多个用户账号,或者在一个平台拥有多个用户账号。
使用数字身份在网络上进行活动时,会涉及到两种类型的操作:一是使用账户名、密码作为数字身份的标识,二是网络服务提供商经常需要用户上传证件信息,以确认数字身份和身份之间的对应关系。在目前的网络制度体系下,数字身份标识和数字身份认证这两方面都存在一定问题。
数字身份认证的发展经历了三个阶段:中心化的数字身份、第三方数字身份服务商提供服务(IDP)以及自主主权的身份(SSI)。
在中心化数字身份的阶段,用户自己维护在多个平台的账号信息,可能各个平台都会需要用户认证某些身份信息,比如手机号码、身份证号码。在这种模型中,用户需要记住多种数字身份标识,到了各个平台上,用户还需要重复操作去认证相同的证件信息。更加严重的问题是,储存在第三方平台上的证件信息很容易被复制、滥用,一旦把信息上传到平台上,用户就失去了对这些信息的控制,即使在线删除,用户也不能确定平台是否真的删除了信息。
所以现在很多用户会选择可信的第三方数字身份服务商来管理数字身份,如 Google 和 Apple,使用 Google 账号就可以在各个平台登录,Apple 平台的应用也可以使用 Apple 账号一键登录。用户一般会认为 Google 和 Apple 是可信的,但也不免产生证件信息过于集中化的担忧。这是第二个阶段的数字身份认证模型。
第三个阶段的自主主权的认证模型,得益于密码学技术和去中心化网络技术的发展,可以实现只有用户自己拥有完整的身份数据,以及用户可以完全控制自己的信息,在用户不授权的情况下,第三方应用无法获得也无法使用这些信息。已经获得信息的第三方应用,也难以复制和滥用这些信息。
UMID 结合基于标准规范,结合使用多种前沿技术,提供了实现自主主权认证模型(SSI)的完整解决方案。
技术与规范概览
SSI相关规范
目前有四个规范共同定义了 SSI 的模型,其中 W3C 发布了 Verifiable Credentials 和 DIDs,RWOT定义了证明 DID 所有权的 DID Auth,Hyperledge Indy 定义了 DKMS 相关内容。
可验证的证明
生活中的证件信息包括身份证信息、驾驶证信息、学位证信息等,当证件信息在互联网上体现为数字证件信息时,我们期望这些信息在互联网上是加密的,用户的隐私可以受到保护,同时这些信息是机器可验证的,能够有方法证明证件的有效性。
在可验证的证明(Verifiable Credentials)规范中,有四种类型的参与方,分别是发证方、持证方、验证方和可验证数据的数据中心。
数据模型的具体定义为:
- 发证方,权威可信的机构,有权颁发证件或者发布其他形式的声明,发布的证件信息会交给持证方。
- 持证方,互联网上的终端用户,从发证方申请证书。持证方会从多个发证方得到多个证件。
- 验证方,互联网上的第三方应用,从持证方获取证件信息,然后到发证方验证证件有效性。
- 可验证数据的数据中心,互联网上的公共平台,储存一些关键的信息,如数字身份标识、可验证证件的数据模型等。数据中心可以是去中心化的数据库、政府背书的数据库、可信任的中心化数据库等。
对于可验证的证明,完整的生命周期如下图所示:
关于生命周期的具体说明如下:
- 可验证的证明由发证方签发
- 发证方可以撤销证明
- 持证者可以丢弃证明
- 持证者可以随意复制证明
- 持证者可以随意展示证明给验证方
- 验证方需要到数据中心检查证明有效性
- 验证方可能会直接到发证方检查证明有效性
为了实现可验证的证明,系统需要满足以下信任模型:
- 所有参与者信任可验证数据的数据中心能够正确记录所有数据
- 持证方信任可验证数据的数据中心不会擅自更改和使用数据
- 验证方信任接收到的证明是发证方签发的
- 持证方和验证方信任发证方签发的证明
另外,在这个信任模型中:
- 发证方和验证方不需要信任可验证数据的数据中心
- 发证方不需要知道和信任验证方
在可验证的证明系统中,会将储存原证件信息保存到数据仓库中,当用户需要向验证者展示证书时,由系统生成一个带有唯一流水号(Challenge)的可验证展示(Verifiable Presentation),用于防止双重支付攻击。
零知识证明
零知识证明是一种加密方法,可以在不透露真实信息的情况下证明消息的真实性。零知识证明机制可以为可验证证明提供如下能力:
- 将多个发证方发布的证书信息整合到一个可验证展示上,验证着将无法直接和发证方建立联系,保护用户的隐私不受验证方侵犯。
- 对于一份可验证证明,选择性的披露其中的部分内容,而不将完整的证明内容生成到可验证展示上,用户可以更加自由的控制自己要展示的信息。
- 用户可以按照验证方的数据格式组织可验证展示的信息,而不需要按照发证方的数据格式。
结合盲签名技术生成可验证证明,可以更好契合零知识证明的实现。
去中心化的身份标识
DIDs(Decentralized Identifiers)是一种新型可验证的去中心化数字身份标识规范。一个 DID 标识可以指一个人、一个组织、数据模型甚至是抽象的东西。DIDs 使用有关联的数据(Linked Data)作为基础的数据结构,对数字身份信息的控制拥有完整的表述能力。
一个 DID 的基本形式为:
DID URL 的形式为:
对比其他标识的定义,URLs 指向网络上的资源,URNs 是网络上不会改变的持久化的名称,DIDs 则包含了 URN 的能力,即 DID 本身是一个持久化的名称,并且 DID 可以解析为多个 URL。
DIDs 的组成模块结构如下:
各模块的详细说明:
- 可验证数据的数据中心,储存 DIDs、DID document 和它们的对应关系。
- DID 实体,可以指人、组织、群体、物理上的事物或者逻辑上的事物,等等。一个 DID 对应一个 DID 实体。
- **DIDs 和 DID URL,**一个 DID 就是一个去中心化的标识,是由三个部分组成的 URI。DID URL 允许一些 URL 形式的扩展,如
?和#等标识符及相应含义的操作。 - DID 控制者,拥有修改 DID 文档权限的实体。一个 DID 可能拥有多个 DID 控制者。
- DID 文档,DID 文档包含 DID 相关的具体内容,支持自定义字段。
- DID 解析器,可以根据 DID 解析出对应的 DID 文档。
- DID 方法,DID 方法和可验证数据的数据中心相关联,用于约定了 DID 生成、解析、更新等操作的具体方式。
有连接的数据
ref: https://www.w3.org/wiki/LinkedData
有连接的数据(Linked Data)是指在互联网上发布结构化数据的一组最佳实践,包括以下四个原则:
- URIs 作为数据的名称
- 使用 HTTP URLs 作为名称
- URLs 链接到的页面中应该包含有用的信息
- 包含一些指向其他资源的 URIs
这些原则背后,一方面是提供一种标准的方法在展现互联网上的数据,另一方面是,这些原则建立起了不同数据源之间的联系。这些超链接将有联系的数据都整合到单个的数据图谱中,类似在 HTML 文档上组织网页内容。Linked Data 对于数据的重要性,就像超链接对于网页文件的重要性一样。
ref: https://www.w3.org/TR/did-core/
JSON-LD 是 Linked Data 基于 JSON 的实现,DIDs 使用 JSON-LD 作为数据的载体。一个 DID 文档必须是一个 JSON 对象,DID 文档对象中属性和值类型的对应关系如下:
- 数值必须表现为数值类型
- 布尔值必须表现为布尔值类型
- 序列值必须表现为数组类型
- 未排序的集合必须表现为数组类型
- 属性的集合必须表现为对象类型
- 空值表现为 null 类型
- 其他值全部表现为字符串类型
DID 文档的属性必须全部包含在第一个层级,其他数据可以以任意形式储存在文档中。当然,@context
是 JSON-LD 的保留属性,不能自定义使用。
DID认证机制
ref: https://github.com/WebOfTrustInfo/rwot6-santabarbara/blob/master/final-documents/did-auth.md
DID Auth 定义了证明 DID 所有权和数据结构、挑战方式和数据传输方式。证明 DID 的所有权需要用户和验证方进行一定的交互,可以使用长连接或者其他形式实现这一操作。一次成功的 DID 授权应该保证各交互方以可信的形式传输数据,尤其是用户和验证方的数据交换。
DID Auth 使用场景的示例流程如下:
对于网页服务和手机应用验证的使用场景,验证流程相对简单,由验证方发起挑战,应用端完成挑战后将结果响应回验证方。
去中心化的密钥管理系统
ref: https://hyperledger-indy.readthedocs.io/projects/sdk/en/latest/docs/design/005-dkms/README.html
去中心化密钥管理系统(Decentralized Key Management System, DKMS)是一种在没有中央机构的情况下管理加密密钥的方法,DKMS利用去中心化网络不可篡改、高可用、数据可恢复等特性,提供了高度可扩展的密钥分发、验证、恢复机制。
DKMS的密钥类型分为三种:
- 主密钥:主密钥是没有加密的密钥,手动分配或者在初始化的时候生成。
- 加密密钥:用于传输或储存其他密钥的公钥或者对称密钥。
- 数据密钥:对用户数据进行加密的密钥。
高级别的密钥保护低级别的密钥,主密钥需要特别保护,应该严格限制访问权限,进行电子和物理的隔离,以及保证在共享控制的情况下才拥有访问权限等等。
密钥丢失意味着不再拥有密钥的控制权,并且不再有进一步泄露的风险,如洪水、雷电、地震、火灾、硬件损坏等。密钥泄露则意味着公钥或者私钥已经可以在不授权的情况下被得知。
在去中心化密钥管理系统中,密钥的恢复是很重要的,因为没有更高的权限和方式来恢复密钥了:
- 使用物理媒介或者可插拔的数字化媒介持久化储存密钥,可以实现离线恢复
- 让可信任的委托人保管密钥的一部分,借此来恢复密钥信息,可以实现密钥的社会性恢复
UMID 系统架构概述
UMID 系统架构概览图如下:
(说明)
具体模块划分:
关于系统架构层级结构的说明:
- 客户端层是用户和企业实际接触到的终端,包括 SDK、APP、小程序、网页等形式。
- UMID 为去中心化的密钥管理系统,提供了密钥的备份、找回等功能。
- UMID Auth负责接入底层并提供统一的 API 接口,对接各种形式的客户端。
- UMVC 实现层负责
- UMID 实现层负责
- UMID 底层基于去中心化的联盟链,提供可靠的可验证数据的数据中心服务,UMID 的生成、更新、删除、备份和找回等操作都由底层提供能力。
UMID Auth 的功能模块图如下:
UMID Auth 即服务接入层,主要负责所有权的确认。当用户使用一个 DID 到系统中进行某些操作,系统需要首先确认用户是否拥有 DID 的使用权。UMID Auth 在收到请求后,挑战模块会发起一个解码挑战,生成一串随机的字符,然后让用户使用请求 DID 对应的私钥对挑战字符串进行签名,并返回加签后的内容。挑战模块会从数据中心查询 DID 的公钥,用公钥验签。验签通过则说明 DID 归属于该用户,请求会转发到 UMVC 实现层继续后续操作。UMID Auth 同时会把挑战的内容也发送到 UMVC 实现层,防止二重支付攻击。
UMVC 的功能模块图如下:
(补充说明)
UMID 的功能模块图如下:
- DID API 和 DID RESTful API 分别提供命令形式和网络形式的接口服务
- DID Resolver 负责 DID 和 DID URL 的解析以及 Json-ld 的处理
- DID Authentication 负责 DID Controller 的确认以及 DID 所有权的验证
- DID Core 负责 DID Document 的 CRUD 操作
- DID Model 是数据操作的抽象层,提供对数据中心的抽象操作。只有 DID Model 直接和数据中心产生数据交互
- crypto 为通用加解密模块,负责为 DID 操作中的加解密功能提供支持
UMKMS 的功能模块图如下:
(图)
(补充说明)
UMID 系统架构详述
基本使用流程
UMID 的具体使用流程为:
- 持证方(用户)使用公钥申请可验证的证明
- 发证方使用公钥颁发证明给持证方,同时将证书储存到数据中心
- 发证方将证明的 UMID 展示给验证方(第三方平台)
- 验证方确认持证方对 UMID 的所有权
- 验证方检查可验证证明的状态
- 验证方接受证明
第 1、2 步持证方申请证明的详细流程如下图所示:
第 3、4、5、6 步验证方确认可验证证明的详细流程如下图所示:
其中第 4 步是基于 UMID Auth 实现,由验证方发起挑战,然后根据从数据中心查到的公钥判断持证方是否拥有 UMID 的所有权。
风控系统设计
第 5 步检查证明状态的步骤是可变的,系统将根据风控策略进行不同的操作。当风险等级低时,验证方不需要与发证方进行交互,只需根据可验证证明本身包含的信息就可以判断结果,比如当确信只有信任的发证方可以向数据中心写入证书时。当风险等级高,如数据中心是公开、任何人可以写入数据的,验证方就不得不直接和发证方通信,以校验可验证证明的状态,因为在公开的网络上,发证方有被冒充的可能。
UMID身份认证平台支持三种类型的数据库作为可验证数据的数据中心,一是公有链,如结合以太坊的智能合约储存数据,由于区块链数据和合约程序都是公开的,风险等级最高。二是包含准入机制的联盟链,在控制了数据源的情况下,结合区块链天然的溯源能力,可以提供非常可靠的数据服务,风险等级比较低。三是权威机构背书的传统数据库,由于政治正确 :-P,风险等级比较低。
去中心化密钥管理系统设计
(补充)
UMID的优势
可靠的去中心化网络
使用自研 UChains,技术自主可控,高效的共识算法,高吞吐量,支持大规模数据的储存与复杂条件的组合查询。
支持国密
UMID 系统提供对国密算法完整的支持,UMID 在 DIDs 规定的加密算法之外,增加了对 SM2 国密算法的支持,可以更好契合国家对系统数据安全的要求。