具有去中心化身份和可验证凭证的分布式账本认证

摘要

使用用户名和密码进行身份验证对用户来说是一个不方便的过程。终端用户通常无法控制他们的个人隐私,影响数百万用户的数据泄露已经发生了多次。我们通过将其与自主身份相结合,实现了一个概念验证的去中心化OpenID连接提供者,这让用户可以从大量身份提供者中自由选择,而不是只选择少数公司,从而实现了高度集中的数字身份景观的民主化。此外,提出了一种使用分布式账本技术的可验证凭据驱动的去中心化公钥基础设施,为获取数字证书提供了一种直接且可验证的方式。

引言

许多网站为最终用户支持Facebook和谷歌单点登录(SSO)解决方案。不幸的是,这带来了隐私方面的成本。通常,像Facebook和谷歌这样的集中式服务提供商的商业利益与用户的利益不一致。这可能导致用户在最初共享数据时超出其意图使用数据[1]。用户仍然可以从SSO客户体验中获得好处,不必在每个网站上注册,同时不牺牲自己的隐私。
自主身份(Self-Sovereign Identity, SSI)的思想旨在通过分散数字身份来解决这个问题。W3C在可验证凭证和去中心化标识符方面的标准化工作服务于SSI的这一愿景。目前,分布式账本技术(DLT),如Sovrin和Hyperledger Indy,被用于实现SSI框架。通过这些方法,最终用户可以获得更多的隐私和对他们数据的更多控制,同时能够比我们今天在网上拥有更多的信任。NIST将认证定义为验证用户、进程或设备的身份,授权是授予系统实体访问系统资源的权限或权限。
单点登录解决方案背后的行业标准是OAuth 2.0和OpenID Connect(OIDC)[4]。OIDC是OAuth 2.0[5]之上的认证层,是一种授权框架,其定义见OIDC官网1。默认情况下,有一个OIDC提供商,如Facebook或谷歌,向OIDC客户提供关于身份持有人的信息。自主版本的OIDC是要求用户提供个人信息,而实际上没有SSI OIDC提供商的用户帐户。因此,没有用户必须依赖的、容易被黑客攻击的个人数据中央数据库。
此外,对现有身份验证系统的安全性也存在担忧。即使某些双因素身份验证方法对于20192年的在线银行等用例也不够安全,因为像Muraena和NecroBrowser这样的强大框架能够攻击通过软件(例如谷歌Authenticator)或硬件(例如RSA SecurID)生成的基于时间的一次性密码(TOTP)。此外,广泛使用的SMS令牌可以被SIM交换攻击截获,并用于[6]重放攻击。影响数百万用户的数据泄露已经发生,甚至在Facebook和谷歌这样的公司,终端用户通常对自己的数据几乎没有控制权。
SSI可以将控制权交还给最终用户,并可能有助于缓解隐私担忧、安全和数据泄露等问题。当结合SSI和OIDC进行用户身份验证时,可以采用多种可能的方法。在本文中,我们进行了彻底的分析,以找到适合我们的场景的方法。
SSI可以实现多种场景下的用户认证和授权。除了OIDC之外,SSI技术还可以用来集成、扩展和修改现有的数字身份标准(如X.509[7]),从而增强互操作性。已经有几项旨在建立和改进在线身份识别流程的举措。域名系统(DNS)和公钥基础设施(PKI)依赖于X.509和集中的证书颁发机构(CA)系统,使网站能够向浏览互联网的人进行身份验证。不幸的是,当前的PKI会导致较高的证书成本,而CA故障,比如DigiNotar,会导致巨大的问题。
本文的主要贡献包括:(1)回顾了SSI认证方法,(2)实现和评估了OIDC的自主认证,(3)分析了SSI支持的PKI的好处。
在下文中,我们首先在第二节中介绍SSI、去中心化标识符和可验证合同的背景信息。第三部分介绍了基于分布式账本的身份认证和pki的相关工作。在第四节中,我们概述了该方法的设计。第五节概述了实施,在第六节中,我们评估了我们的方法,然后在第七节结束。

背景

去中心化目前高度集中化的数字身份生态系统,为使用区块链的终端用户提供更多的控制、隐私和安全,已经提上了一些初创公司、大型组织和研究机构等的议程。
SSI始于2016年克里斯托弗·艾伦的博客文章。Allen提出了10条指导身份系统设计的原则,这些原则侧重于终端用户的利益,作为SSI的思想基础。Allen制定的存在、控制、访问、透明性、持久性、可移植性、互操作性、同意、最小化和保护这10个原则强调了身份所有者(也称为身份持有者)的隐私、独立性和权利,以及身份管理系统的互操作性和透明性。此外,艾伦也是去中心化的支持者。审视当前的身份生态系统,我们甚至可以认为艾伦的自我主权乌托邦愿景。有一些初创公司、机构和基金会打算分散数字身份,例如欧洲主权身份框架(eSSIF)。去中心化身份基金会(DIF)的成员包括IBM、微软、万事达卡、Sovrin、evernym、Jolocom、uPort、Auth0、不列颠哥伦比亚省公民服务部等。

去中心化身份

去中心化身份(DID)[8]为与控制DID的DID主体交互提供了一种可验证的、去中心化的手段。可以将DID解析为DID文档,其中可以包含加密材料、验证方法和服务端点。一个例子是:
did:sov:WRfXPg8dantKVubE3HX8pw
其中的did告诉我们这是一个DID,sov是Sovrin DIDs的DID方法名称,WRfXPg8dantKVubE3HX8pw标识了DID的主体。一个DID本身不是为提供有关DID主体的可信个人信息而设计的,而是为持有人的自我主权和促进隐私而设计的。
例如,对于Sovrin,像Jane Doe这样的身份持有人在每个连接中都应该有不同的DID。由于Jane在与银行交互时使用的操作与她在网上商店使用的操作不同,银行和网上商店不能使用Jane的操作来关联收集到的关于她的个人信息。

可验证的凭据

DIDs允许用户以保护隐私和去中心化的方式在线认证自己,但在许多情况下,我们需要获得有关个人身份的可信信息以进行某些交易,例如在线购买酒精饮料。当简在网上商店订购她最喜欢的葡萄酒时,她还需要证明她是合法的成年人。这可以通过使用可验证凭据(VC)来实现,它通过提供从终端用户接收可加密验证的可信身份信息的方法来补充DIDs。
一般来说,VC[9]以安全、隐私保护和机器可验证的方式为我们提供了日常生活中使用的数字证书,如驾照、护照或大学学位。
VCs支持选择性披露,因此最终用户可以证明关于其身份的声明,而无需披露超出执行特定操作所需的更多信息。例如,当Jane在网上葡萄酒商店订购她喜欢的葡萄酒时,她只向卖家证明她已超过18岁(假设18岁是合法饮酒年龄),这可以通过使用她的护照VC生成有关出生日期的证明来实现。此外,Jane甚至不需要分享确切的日期,因为这足以让她生成零知识证明,表明她已经超过18岁。
VCs可以表达物理证书中包含的任何信息,但使用来自颁发者和持有者的数字签名使其易于篡改,并且对验证者更加可信。我们在图1中展示了VC数据模型的说明。

相关工作

在本节中,我们将讨论使用OIDC和PKI域对终端用户的在线认证。

用户身份验证

身份验证经常与授权一起讨论。OAuth 2.0是目前的行业标准授权协议,也是OIDC的基础。OAuth 2.0允许应用访问其他HTTP web服务(如Facebook)上已有的账户。因此,身份验证被委托给已经与用户接触的第三方。在OAuth 2.0模型中有4种角色,分别是(1)资源所有者,(2)客户端,(3)资源服务器,(4)授权服务器。
然后将OIDC置于OAuth 2.0授权层之上,以便建立一种从身份提供者(IdPs)接收用户账户信息的标准化方法。
图1所示:可验证凭据(VC)角色模型包括颁发者、身份持有者和验证者。此外,还有一个公开可读的可验证数据注册中心,它可以是区块链、分布式账本或任何安全的去中心化存储。例如,市政办公室(颁发者)向Jane Doe(身份持有人)颁发护照凭证,然后她在开立新账户时将其提交给银行(验证者)。
VCAuthN for OIDC5是不列颠哥伦比亚省政府公司的一个项目,在身份持有者和OIDC提供商之间使用DIDComm协议。OIDC提供商在SSI术语中扮演验证者的角色。DIDComm目前正在Hyperledger Aries项目下孵化6。VCAuthN项目集成了隐式代码流和授权代码流。VCAuthN依赖VC表示来提取包含用户信息的ID令牌的属性。VC演示通过二维码或身份钱包移动应用程序的深度链接进行展示。
不过,用户身份验证也可以关注DIDs。Sabadello等人撰写的DID认证文档[10]描述了10种不同的基于DID的认证架构,以及DID认证与其他身份认证技术的关系,如biometrics、OpenPGP[11]、WebAuthn[12]和OIDC。作者提出将DID身份验证作为OIDC提供商的一种可能的本地认证方法,并通过DID解析获得的DID文档的服务端点属性作为OIDC提供商发现的一种替代方法。
DIF的GitHub存储库中托管的did-auth-jose库7提供了使用Javascript对象签名和加密的去中心化身份验证8(JOSE),遵循自发行ID令牌的OIDC身份验证流程。did-auth-jose库需要访问一个通用的Resolver9实例来获取用于身份验证的DIDs的加密密钥。
DIF还为OIDC10创建了DID身份验证规范。在这种变体中,OIDC客户端不依赖于预先配置的OIDC提供商,而是使用自签发的OIDC提供商(SIOP)。所提出的SIOP DID AuthN方法没有利用授权代码流,因为将DID Auth与OIDC提供商集成对于实现最大程度的去中心化和隐私来说是不必要的。另一方面,要求OIDC客户实现SIOP流程使得适应SIOP DID AuthN变得更加困难。然而,SIOP是OIDC规范的一部分。
Gruner、Muhle和Meinel还提出了一种将OIDC与两个SSI平台[13](Jolocom和uPort)集成的可能方法。他们的解决方案的体系结构包括一个信任引擎组件,用于确定凭据的颁发者是否可信。与Sovrin一样,我们不需要依赖难以验证的中央信任引擎来评估索赔的信誉,因为Sovrin基金会采取了必要的步骤来确保所有Sovrin发行人都有合法的权利签发他们所提供的凭证。然而,Gruner等人通过引入SSI代理组件解决了互操作性,该组件处理了与各种平台(如Jolocom和uPort)交互的复杂性。

区块链安全的公钥基础设施

还存在描述区块链和用于管理X.509证书的分布式账本应用程序的出版物、专利和白皮书。
Won[14]设想实现基于区块链的PKI,与目前最先进的使用证书颁发机构颁发的用于管理物联网设备公钥的X.509证书相比,它能够更快地进行证书验证。Won认为,目前的PKI基础设施不适合物联网设备,因为(1)安全性方面失败的后果,以及(2)由于缺乏管理公钥生命周期的标准协议,管理证书存在困难。Won认为,如果一个根CA的密钥被攻击者泄露了,那么所有实体必须相应地更新它们的可信根证书列表。例如,2011年DigiNotar在[15]被黑客攻击时就是这样。
证书透明(Certificate Transparency12, CT)通过扩展现有的CA和PKI体系结构,提供了一种降低这些风险的机制。CT的概念包括三个公共服务:证书日志、日志监控和证书审计。这些公共服务可以由多个提供商以去中心化的方式运行,例如cdn、isp、浏览器厂商或DNS提供商。自2018年以来,浏览器和搜索引擎开始包括额外的证书验证机制,如CT。Stark等人在[16]中表明,CT已经进行了重大调整,但他们也指出了终端用户对系统警告等错误反应的危险,因此CT的附加值处于危险之中。另一种加强当前CA基础设施的机制是引入扩展验证(Extended Validation13, EV)证书,它要求在授予证书之前验证实体的合法身份。目前只有一部分ca被允许实现这种方法。
Won[14]进一步解释说,由于生成响应的计算密集型性质,在线证书状态协议响应程序很容易过载,因此对它们进行成功的分布式拒绝服务攻击相对容易。Won的目标是使用基于Emercoin15的权益证明共识算法的区块链网络取代CAs。
最初,Blockstack[17]设想了一个使用比特币区块链的全球命名和存储系统。2016年,Blockstack为其40,000名用户提供了使用Namecoin的PKI系统,超过33,000条条目和200,000笔交易。
Blockstack PBC随后为去中心化的全球命名系统提交了一份专利申请[18],使用分布式哈希表实现虚拟区块链作为全球命名系统的防篡改注册表。
DIDs还可以与DNS(如命名系统)结合。Web16的DID方法规范草案已经可用,它通过将DID链接到已经存在的域背后的有意义的信息来增强DID,从而帮助大规模采用该技术。一个例子是:
did:web:w3c-ccg.github.io.

概念和设计

将OpenID Connect标准声明与自主身份集成

由于OIDC有一组预定义的声明17(见表I,它们都是字符串,除了*_verified是布尔值,地址是JSON对象,更新的at是数字),我们应该将这些属性包括到OIDC模式和凭据定义中。声明包括一个名为sub的标识符,以及一些个人声明,如姓名、性别、电话号码、电子邮件、图片、网站和地址、生日。
可以验证电话号码和电子邮件。由于电话号码通常与实体身份联系在一起,我们可以使用它们进行可信的身份验证。
为了以可信的方式支持OIDC标准索赔集,我们对Hyperledger Indy所需要的只是一个包含所有属性的SCHEMA和CLAIM_DEF。在这种情况下,最终用户甚至不需要SSI OIDC提供商的账户,并且能够使用任何颁发者的凭据登录,例如通过使用Sovrin网络或其他网络。

含有OpenID Connect的DID Auth

对于我们由si支持的OIDC提供商的授权,我们可以依赖一个经过认证的消息,即一个经过认证加密和did签名的公钥消息。因此,我们提出了一个额外的基于VCs的身份验证因子,在请求的VCs中包含必要的用户信息。上述过程有三个主要好处。首先,发送给依赖方的用户数据直接从用户那里获取。其次,我们有机会收集用户的额外信息。第三,VCs可以对用户账户信息建立更多的信任。

从信任、隐私和灵活性的角度来看,以证明请求的形式从持有者那里接收和验证数据是有益的。如果验证者收到了由特定政府签署的属性证明,她几乎可以确定持有者的真实身份被暴露了。然而,出于隐私考虑,证书持有者也有机会发送自签名证书。此外,这也将使任何Sovrin发行方成为SSI OIDC提供商的一部分,从而帮助我们实现身份分散的目标,并给最终用户一个真正的机会,从比今天更多的候选运营商中选择他们喜欢的运营商。尽管如此,应用程序开发人员只需要将SSI OIDC提供商与他们的web服务集成起来,而且他们将能够支持使用来自多个IdP的帐户登录。
关于OIDC的DID认证的一个设计决策是我们是否在一个或两个步骤中进行VC证明和DID交换。请注意,单步VC交换只能在SSI OIDC提供商已经建立了两两DID连接的情况下进行,即唯一的DID和相关密钥已经与终端用户交换,或者如果双方都在分布式账本上编写了公开的DID。此外,SSI OIDC提供商还需要事先知道用户的DID,以便将证明请求发送给持有者。在一步证明交换中,持证人和验证者之间的通信可以用各自的DIDs的公钥和私钥进行加密和解密。
1)通过SSI移动钱包应用程序进行身份验证:当使用Hyperledger Indy时,我们需要三件事:(1)IdP(颁发者)和用户(持有者)之间建立成对连接,(2)了解匹配的VC类型,以及(3)知道我们要验证的是哪个用户。SSI IdP和持有者之间的成对连接可以通过SSI智能手机钱包应用程序扫描SSI IdP网站上显示的二维码来建立。为了开始身份验证,我们可以通过扫描二维码使用HTTP cookie或基于挑战响应的身份验证方案,前提是不存在关于用户DID的先前会话信息。然后,身份持有人会收到证明请求和推送通知,并利用智能手机的生物识别功能,在同意的情况下将证明发送给SSI OIDC提供商。然后IdP可以将接收到的属性以JSON Web令牌的形式转发给依赖方。

一个基于分布式账本的公钥基础设施和域名系统

像Sovrin这样的公共授权账本很有希望成为PKI的候选对象,因为需要写访问的实体数量比需要读访问的实体少几个数量级。运行共识协议的节点需要被广泛信任的组织,例如最受信任的SSL证书颁发机构(SSL certificate authority, CA)。普通CA也可以对账本拥有写访问权限。Mir-BFT[19]能够在广泛分布的100个节点上每秒订购超过60000笔签名比特币大小的交易。如今,web浏览器依赖于一组预定义的可信根证书。在去中心化的PKI中,我们可以使用公共许可账本的初始交易来初步验证检索到的证书的真实性。
1)基于NYM交易的PKI:创建一个对账本已知的DID本身就是一个身份记录,也称为NYM交易。NYM事务可用于创建分类账已知的新DIDs。由于Hyperledger Indy的NYM账本交易包括verkey和可选的alias字段,我们可以使用它们将人类可读的名称和特定DID的公钥绑定在一起。DID verkey是EdDSA(Edwards-curve Digital Signature Algorithm, EdDSA)签名方案的公钥,该方案使用SHA-512哈希算法和Ed25119曲线,即提供128位安全性的椭圆曲线,也适用于生成X.509证书。可以通过更新NYM事务和相应的DIDs来支持X.509证书的吊销。
2)可验证凭据启发的PKI:VCs不存储在公共账本上,而是用Hyperledger Indy私下保存在身份持有人的钱包中。如果网站能够秘密地持有支持撤销的X.509-structured VCs,我们不一定会提高当前PKI系统的透明度,但仍然会有一种获取证书颁发机构公钥的标准化方法。然而,公开访问包含与X.509证书相同信息的VCs证明并不是绝对必须的。在NYM交易中,在Indy分类帐上拥有证书颁发机构的公钥就足够了,基于X.509证书模式创建在CLAIM_DEF交易中记录的凭证定义,而无需公开证明。

实现

我们有一个SSI OIDC提供商的概念验证实现,我们已经确定了实现基于vc的PKI的基本库。

OpenID可验证的基于凭据的连接提供者进行身份验证

为了实现首选的SSI和OIDC集成,我们使用了Indy Edge Agent API18,这是一个扩展的Node.js OIDC提供商,一个模拟在线商店功能的测试OIDC客户端。此外,移动SSI钱包应用程序也是工作流程的重要组成部分。图2显示了实现和登录过程。接下来,我们将描述每个组件。
1)Indy edge agent API:我们有一个自己的Indy edge agent REST API,它包装了Indy SDK的功能,并可部署在服务器上,客户端可以通过使用简单的REST调用来使用Indy SDK的功能。我们的Indy API可以连接到任何Indy账本,包括Sovrin主网。API是用Node.JS编写的,它还需要一个MongoDB实例作为身份钱包的持久存储。
2)SSI OpenID连接提供商:对于我们的SSI OIDC提供商的概念验证实现,我们可以将我们的解决方案基于已经存在的、经过认证的软件。当与OIDC合作时,我们有几种开源实现可供选择。我们选择了一个经过认证的Node.js OIDC提供商19,它具有100%成功的测试矩阵,用于在jwt上进行令牌签名和验证。io,它由底层的JOSE库提供。
我们当前的实现使用隐式流,但通过为授权代码流配置我们选择的OIDC提供商,可以相对容易地改变这一点。
图2所示。基于oidc授权代码流的SSO与SSI集成顺序图。在该方案中,DID认证通过证明交换一步完成,其中发送的证明以VC的形式包含id令牌的属性。首先,用户在网站上发起登录。然后,网站(OIDC客户端)将他/她重定向到SSI OIDC提供商。如果用户还没有连接,那么可以通过使用身份钱包移动应用程序扫描二维码来建立连接。然后OIDC提供商向最终用户(身份持有人)发送证明请求。接下来,身份持有人可以决定是否响应证明,从而执行登录。
3)SSI移动钱包应用程序:我们已经开发了一个React Native Android应用程序,使用Hyperledger Indy作为身份持有人的SSI身份钱包。React Native应用依赖于Indy SDK的Java包装器。该应用程序可以通过扫描连接提供的二维码与DIDs建立成对连接,并可以获取和存储VCs。此外,该应用程序还可以在收到证明请求并获得身份持有人的同意后向验证者发送证明。
4)OpenID连接客户端:为了测试我们的原型,我们创建了一个网站,用户可以使用他/她的SSI凭据登录。然后网站将用户重定向到SSI OIDC提供商,在那里执行身份验证。如果处理成功,客户端网站就会收到ID令牌。目前使用的是隐式流,客户端应用程序将ID令牌作为重定向URL的一部分接收。
目前,我们使用带有隐式流的Node.js OIDC客户端,这可以轻松地与OIDC提供商集成。

分布式账本驱动的PKI

X.509证书的属性可以很容易地合并到VC中,而不是抽象语法表示法1(ASN.1)结构中。在Hyperledger Indy的情况下,CLAIM_DEF需要在证书中明确包含大多数属性。在Certificate_Signature_Algorithm和Certificate_Signature属性中找到的信息将在这里通过在reqSignature字段中找到的值提供。为了广泛使用基于vc的证书,我们必须将它们与TLS和SSL库(如OpenSSL20和Rustls21)集成。

评价

对于PKI和终端用户认证场景,可以从多个方面比较区块链和分布式账本认证方法以及集中式方法。接下来,我们进行定性评估。未来的工作是对所提出方法的实际性能进行模拟和实验。

基于分布式分类帐的PKI

正如Won[14]所写的,目前还没有管理X.509证书生命周期的标准协议。分布式账本技术支持的PKI系统的一个主要优势是更高的透明度和互操作性,我们可以很容易地在一个公开的、经过许可的、防篡改的注册表上找到所有现有的X.509证书和域名。
需要研究的一个问题是,我们是否能够支持所有X.509证书的存储,或者仅支持ca的证书。截至2020年3月,BuiltWith检测到超过1.45亿张SSL证书22。如果我们假设所有的证书每3个月更新一次,这仍然会导致平均每秒不到17个交易的吞吐量。如果我们的分布式账本支持每秒10,000笔交易,那么我们可以预期我们的系统能够在3.5小时内记录超过1.245亿张SSL证书。
然而,我们仍然需要更多的证据、研究和创新,来看看基于分布式账本的PKI是否比最先进的PKI更好。尽管如此,siddetree协议,像Hyperledger Fabric这样的平台,像Mir-BFT[19]这样的高吞吐量共识算法,以及能够通过引入观察者节点[20]来服务大量读请求的Sovrin架构,都指向一个方向,即基于分布式账本的PKI系统将很快成为全球规模的可行解决方案。

自主的OpenID连接提供者

本文确定了SSI OIDC提供商的四个主要优势,即(1)互操作性,(2)隐私性,(3)信任和(4)更丰富的客户数据。
首先,它支持与任何遵循标准OIDC声明模式的Sovrin VC进行SSO,但OIDC客户端只需要与一个OIDC提供商集成。这对OIDC客户来说是一个好处,因为让用户从可能很高的IdP数量中手动选择是不切实际的,而且它还减少了开发工作。例如,客户端必须单独集成谷歌、GitHub、Microsoft、Yahoo和Amazon登录,然后用户还必须选择他/她的首选。集成开销和显示的不同登录选项列表在OIDC客户端上的OIDC提供商数量呈线性增长。但是对于我们的SSI OIDC供应商,它永远只是一个,然而不同帐户的数量可以任意高。
其次,随着最终用户得到关于他们披露的数据的证明要求,他们对他们共享的个人信息有更多的控制,整个过程变得更加透明。此外,终端用户的身份钱包由用户自己存储在其首选设备上,而不是由第三方存储。DIF的SSI和OIDC集成协议利用自主发行的ID令牌提供了最大可能的隐私保护,但它要求OIDC客户端支持一个特殊的功能。我们提议的SSI OIDC提供商不要求OIDC客户提供任何非默认功能。
第三,与Sovrin合作的风***司来自受信任的发行人,这些发行人由Sovrin基金会负责。由于Sovrin分类帐是被许可的,模式和凭据定义只能由可信的实体写入Sovrin主网。这保证了验证者可以信任Sovrin凭据。
最后,根据OIDC规范,常规OIDC提供商可能不支持标准索赔集的所有属性。然而,如果这些属性得到了VCs的支持,那么SSI OIDC提供商可以为其客户提供丰富的索赔集,如果用户拥有匹配的凭证。

结论

带SSI的去中心化认证使终端用户在物联网、PKI和OIDC场景中受益。
将OIDC与SSI结合,并作为VC检索账户索赔,不仅给了最终用户更多的自由,而且还可以通过提供任何匹配的VC,在没有账户的情况下与单个SSI OIDC提供商进行登录。我们的SSI OIDC供应商原型的下一步可能是为使用VCs和DIDs登录提供支持,这些登录来自更多的SSI平台,如Jolocom和uPort,而不仅仅来自Sovrin和Hyperledger Indy。
我们的分析结果是,在IoT PKI场景中,部署一个受许可的账本可以作为必要的加密公共数据的公开验证注册中心。这些数据包括用于验证可验证凭据的X.509证书元数据。
总之,SSI运动已经贡献了几种可行的OIDC认证变体,包括我们的概念验证SSI OIDC提供商。此外,基于分布式账本的物联网设备PKI在技术上可能成为大规模可行的。

致谢

这项活动在分散身份管理系统(DIMS)项目下得到欧洲创新和技术研究所的资助。这个欧洲机构得到了地平线2020研究和创新计划的支持。我们还要感谢Omer Ilhan、Santhos Baala Ramalingam Santhanakrishnan和Marcel Ebermann对原型组件实现的支持。

引用

[1] M. Falch, A. Henten, R. Tadayoni, and I. Windekilde, “Business models in social networking,” in CMI Int. Conf. on Social Networking and Communities, 2009.
[2] E. Aroms,
NIST Special Publication 800-137 Information Security Continuous Monitoring for Federal Information Systems and Organizations. CreateSpace, 2012.
[3] K. Stouffer, S. Lightman, V. Pillitteri, M. Abrams, and A. Hahn, “Guide to Industrial Control Systems (ICS) Security,” NIST Special Publication, May 2015.
[4] N. Sakimura, J. Bradley, M. Jones, B. de Medeiros, and C. Mortimore, “OpenID Connect Core 1.0 incorporating errata set 1,”
The OpenID Foundation, specification, 2014.
[5] M. Jones and D. Hardt, “The OAuth 2.0 Authorization Framework: Bearer Token Usage,” RFC 6750, October 2012. [Online]. Available: https://www.hjp.at/doc/rfc/rfc6750.html
[6] C. Mulliner, R. Borgaonkar, P. Stewin, and J.-P. Seifert, “SMS-Based One-Time Passwords: Attacks and Defense,” in
Detection of Intrusions and Malware, and Vulnerability Assessment, ser. Lecture Notes in Computer Science, K. Rieck, P. Stewin, and J.-P. Seifert, Eds. Springer, 2013, pp. 150–159.
[7] M. Myers, R. Ankney, A. Malpani, S. Galperin, and C. Adams, “X.509 Internet public key infrastructure online certificate status protocolOCSP,” IETF RFC 2560, 1999.
[8] D. Reed, D. S***y, Manu abd Longley, C. Allen, R. Grant, and M. Sabadello, “Decentralized Identifiers (DIDs) v1.0 Technical report,” W3C, 2019. Retrieved from: https://www.w3.org/TR/did-core/, Tech. Rep., 2019.
[9] M. S***y, D. Longley, and D. Chadwick, “Verifiable Credentials Data Model 1.0 Technical report,” W3C, 2019. Retrieved from: https://www.w3.org/TR/vc-data-model/, Tech. Rep., 2019.
[10] M. Sabadello, K. Den Hartog, C. Lundkvist, C. Franz, A. Elias, A. Hughes, J. Jordan, and D. Zagidulin. (2018) Introduction to DID Auth. Rebooting the Web of Trust. [Online]. Available: https://github.com/WebOfTrustInfo/rwot6-santabarbara/blob/master/final-documents/did-auth.md
[11] M. Elkins, D. Del Torto, R. Levien, and T. Roessler, “MIME Security with OpenPGP,” RFC 3156, August 2001. [Online]. Available: https://www.hjp.at/doc/rfc/rfc3156.html
[12] C. Brand, A. Langley, G. Mandyam, M. West, and J. Yasskin, “Web Authentication: An API for accessing Public Key Credentials Level 1,” https://www.w3.org/TR/webauthn/, March 2019.
[13] A. Gruner, A. M ¨ uhle, and C. Meinel, “An Integration Architecture to  Enable Service Providers for Self-sovereign Identity,” in
Companion Proceedings of the 10th International Conference on Utility and Cloud Computing. IEEE, 2019, pp. 1–5.
[14] J. Won, A. Singla, E. Bertino, and G. Bollella, “Decentralized public key infrastructure for internet-of-things,” in
MILCOM 2018-2018 IEEE Military Communications Conference (MILCOM). IEEE, 2018, pp. 907–913.
[15] H. Hoogstraaten, “Black Tulip Report of the investigation into the DigiNotar Certificate Authority breach,” Fox-IT BV, Tech. Rep., 08 2012.
[16] E. Stark, R. Sleevi, R. Muminovic, D. O'Brien, E. Messeri, A. P. Felt, B. McMillion, and P. Tabriz, “Does Certificate Transparency Break the Web? Measuring Adoption and Error Rate,” in
2019 IEEE Symposium on Security and Privacy (SP). IEEE, may 2019.
[17] M. Ali, J. Nelson, R. Shea, and M. J. Freedman, “Blockstack: A Global naming and storage system secured by blockchains,” in
Proceedings of the 2016 USENIX Conference on Usenix Annual Technical Conference, ser. USENIX ATC ’16. USENIX Association, Jun. 2016, pp. 181–194.
[18] M. Ali, R. Shea, and J. Nelson, “Decentralized Processing of Global Naming Systems,” US Patent US20 170 236 123A1, Aug., 2017, library Catalog: Google Patents.
[19] C. Stathakopoulou, T. David, and M. Vukolic, “Mir-BFT: High-Throughput BFT for Blockchains,”
arXiv preprint arXiv:1906.05552, 2019.
[20] D. Reed, J. Law, and D. Hardman, “The technical foundations of sovrin,” Technical report, Sovrin, 2016. Retrieved from: https://www.evernym.com/wp-content/uploads/2017/07/The-TechnicalFoundations-of-Sovrin.pdf, Tech. Rep., 2016.


全部评论

相关推荐

1 3 评论
分享
牛客网
牛客企业服务