基于区块链的PKI管理框架

Posted by LB on Sat, Dec 16, 2023

BlockChain-PKI

摘要

公钥基础设施(PKI)是促进互联网上安全信息交换的基石技术。但是,由于证书颁发机构(CA)可能会被用来为最终用户颁发未经授权的证书,因此PKI面临风险。最近的许多违规事件表明,如果CA受到损害,相应最终用户的安全将面临风险。作为一种新型的解决方案,区块链技术有可能解决传统PKI系统的问题,特别是消除单点故障和对CA缺点的快速反应。区块链能够在公共且不可变的分布式账本中存储和管理数字证书,从容产生完全可追溯的历史日志。在这篇论文中我们设计和开发了一个基于区块链的PKI管理框架,用于颁发、验证和撤销X.509证书。评估和实验结果证实,所提出的框架提供了更可靠、更强大的PKI系统,且维护成本适中。

I.介绍

公钥基础设施(PKI)提供了一种通过互联网验证身份的安全方法。它定义了颁发、管理、验证和分发数字证书所需的策略和程序,以便安全地使用公钥加密。公钥的PKI管理通常基于证书标准X.509,该标准提供某些外部实体(证书颁发机构)对私钥所有权的验证。X.509证书被定义为公钥值与主题(例如域名)绑定的数据结构。绑定由受信任的证书颁发机构(CA)对每个证书进行数字签名来断言。CA可以通过深入验证私有证书持有者的身份来做出这一断言。

最近,知名CA的安全程序存在缺陷,表明CA的安全容易受到操作失误的影响。由于CA似乎是PKI中的单点故障,CA的错误或违规导致颁发未经授权的证书。例如,其中一件备受瞩目的是CA DigiNotar安全漏洞,导致利用该公司基础设施为知名域名颁发数百个流氓数字证书,其中包括google.com的一个。结果,在发现500多个假证书后,网络浏览器供应商被迫将荷兰CA DigiNotar颁发的所有证书列入黑名单。

在另外一个案例中,DigiCert Sdn是马来西亚的颁发机构。错误地颁发了22个弱SSL证书,这些证书可用于冒充网站和签署恶意软件。最终,主要浏览器不得不撤销对于DigiCert Sdn. Bhd颁发的所有证书的信任。(注:DigiCert Sdn. Bhd. 不隶属于美国公司 DigiCert, Inc.)美国大型证书颁发机构TrustWave也存在证书泄露问题。TrustWave承认,它向其中一位客户颁发了从属Root证书,以便该客户可以监控其内部网络上的流量。从属Root证书允许其持有者从Internet上的几乎任何域创建SSL证书。尽管TrustWave已经吊销该证书,并表示将不会向客户颁发从属跟证书,但这说明CA是多么容易犯错,以及这些失误的后果可能有多么严重。

PKI问题及现有解决方案

提出了两种方法来解决SSL/TLS PKI问题:基于日志的PKI模式和点对点认证的去中心化网络(称为信任Web(WoT))。

基于日志的PKIs(Log-based PKIs)

该方法已被提议作为解决CA行为不当问题的新兴解决方案。其背后的想法是使用高度可用的公共日志服务器来监视和发布CA颁发的证书。这些公共日志通过确保最终客户只接受和信任公共记录的证书提供透明度。因此,CA的任何不当行为都会被用户和服务器检测到。Google的证书透明度(CT)是部署最广泛的基于日志的PKI,目前在Chrome和Firefox中都可用。与此同时,许多提案打算通过支持撤销和错误处理来扩展基于日志的PKI模式的功能。不幸的是,尽管有这些好处,基于日志的PKI仍然面对一些挑战,例如与证书吊销相关的挑战。

信任网(WoT)(Web of Trust)

WoT的方法是完全分散的:用户可以通过签署其公钥证书来指定其他人值得信赖。通过这样做,用户积累了包含他的公钥和来自认为他值得信赖的实体的数字签名证书。如果可以验证该证书包含她/他信任的某人的签名,则该证书将手打第三方的信任。该系统受益于其分布式特性,因为它消除了任何中心故障点。然而,这使得新用户或远程用户加入网络变得困难,因为WoT的某些现有成员通常必须亲自与新用户会面,以首次验证她/他的身份并签署公钥。此外,与基于CA的方法不同,WoT无法处理密钥撤销。一个用户被限制选择另外一个用户作为她/他的“指定撤销者“,有权在私钥丢失或泄露时撤销她/他的证书。当前的使用方法依赖于定期向浏览器推动撤销列表。但是,这种方法会使无效证书受到信任,直到浏览器的吊销列表得到下一次推送为止。

基于区块链的PKI(Blockchain-based PKI)

基于区块链的PKI启发了很多研究,它们基于区块链技术构建安全的PKI系统。他们的主要论点是,基于区块链的解决方案可以融合基于日志的PKI和WoT方法的优点,并解决传统PKI系统的一些问题。一方面,区块链解决了基于日志PKI方法的潜在故障点和部署问题,我们将在稍后讨论。另一方面,基于区块链的方法减轻了新证书持有者对WoT的需求,以证明现有网络成员的可信度。

我们的主要贡献是一个完整的基于区块链的PKI框架来管理X.509证书。我们的框架包含多项创新。第一,我们扩展标准X.509证书以与基于区块链的PKI方法兼容,我们使用X.509的扩展字段用于嵌入区块链元数据。第二,我们设计并实现了基于区块链的PKI,为数字证书提供可靠的管理。

本文的其余部分安排如下:第二节介绍了证书验证机制(称为信任链)的背景,并介绍了区块链技术如何帮助构建安全的PKI系统。第三节探讨了使用区块链实施PKI的相关工作。第四节我们展示了基于区块链的PKI解决方案。第五节提供了评估结果和讨论。最后,第六节对本文进行了总结。

II.背景

在这一节,首先我们介绍信任链背后的想法,用于验证X.509证书。然后我们简要介绍了区块链技术以及如何使用它来构建PKI管理框架。

A.可信链(Chain of trust)

传统的PKI系统是基于CA的,CA颁发签名证书,完全符合X.509标准,用于证明实体对公钥的所有权。例如,当用户通过网络浏览器登录Twitter时,网络浏览器首先通过检查给定证书的CA来验证持有Twitter公钥的所声明的证书。通常Web浏览器已预先配置为接受来自某些已知CA的证书。因此,为了使证书受到信任,它必须由用户浏览器或设备中受信任存储中存在的根CA颁发,或者由受根CA签名信任的子CA颁发。通常,Mozilla产品附带154个根证书。此外,苹果、微软和谷歌在其产品中嵌入了自己的受信任根证书存储。

给定证书和根证书之间的链接称为信任链。重要的是,信任链可以包含给定证书和根CA证书之间任意数量的子CA证书。然后,X509v3有一个名为Basic Constraints的扩展,该扩展可以限制有效证书链(信任链)的最大深度。

Untitled

图1说明了从最终实体证书到信任链开始的根CA的认证路径。因此,如果最终实体证书不是由受信任的CA颁发的,则Web浏览器将检查颁发CA的证书是否由受信任的CA颁发,依此类推,直到找到受信任的CA,或者如果在链中找不到受信任的CA,则浏览器通常会显示错误。

B. 区块链技术

区块链或分布式账本被证明是互联网行业中最有趣的技术,主要是在见证了比特币的成功之后。目前,大多数区块链平台都用于金融应用,但越来越多的不同领域的新应用开始出现。需要高可靠性和完全消除数据操作风险的应用程序可以使用区块链。此外,区块链是分布式的,因此避免了单点故障的情况。

最近几年区块链进化到可以执行任意逻辑,称为智能合约。从概念上讲,智能合约是一个运行在区块链之上的应用程序,并使用底层交易顺序来保持对等点之间智能合约执行结果的一致性。例如,以太坊区块链支持复杂且有状态的图灵完备语言,如Solidity,可用于编程和定义广泛的应用场景。

在PKI背景下,区块链技术提供了有价值的安全功能,例如证书撤销、消除中心故障点和可靠的交易记录。例如,通过快速证书吊销,基于区块链的PKI可以立即隔离受感染的CA和相应的证书,而无需等到证书吊销列表(CRL)的下一次更新。此外,基于区块链的PKI作为公共的 ”仅追加“日志,自然提供了Google提出的证书透明度(CT)属性。

在这项工作中,我们选择了以太坊平台和Solidity智能合约编程语言,因为它们拥有庞大的开源社区,使得开发过程更加高效。

III. 相关工作

用于构建PKI系统的区块链实施经过了许多不同的先前工作的审查。在[14]中,作者提出了Blockstack,它使用比特币区块链来提供名称注册系统,其中名称与公钥绑定。

与Blockstark类似,基于区块链的PKI在Emercoin2(EmerSSH项目)中实现。Emercoin是一个在架构方面与比特币非常接近的公共区块链,具有混合工作量证明和权益证明共识,具体取决于采矿能力的可用性。Emercoin没有智能合约,并将证书哈希存储到区块链中。这意味着证书的验证并不完全依赖于区块链外部的代码。EmerSSH并不关注信任链,因为默认情况下,证书在扩展字段中不包含指向其父CA的链接。相反,据作者称,EmerSSH将证书哈希存储到区块链,从而减轻了中间人风险。一旦证书的哈希值加载到区块链中,就会建立使用证书公钥的安全连接,并为每个连接进行全新密钥的交换。

弗罗姆克内希特等人。 [10] 利用 Certcoin 实现基于区块链的 PKI,存储域及其关联的公钥。与此同时,在[9]中,作者仔细研究了 Certcoin 的隐私问题。

所有上述研究都提出了纯粹基于区块链的方法。然后,在这项工作中,我们建议使用通用标准X.509v3证书,并对具有区块链相关信息的扩展字段进行少量添加。因此,扩展的X.509证书通过经典的基于CA的信任链或使用基于区块链的PKI框架进行验证。据我们所知,我们是第一个提出这种混合证书的。作为未来的工作,我们计划开发一个用于网络浏览器的插件,使用公共区块链验证所声明的证书。

IV. 基于区块链的PKI框架

这一节介绍了我们在区块链平台中管理PKI的框架。首先,我们将概述所提议方法的主要优点。那么,我们将解释在PKI系统中安排主要参与者(即根CA、子CA、证书持有者)的方法。

A.概述

我们基于区块链的PKI框架支持证书撤销,这是传统PKI系统重的一个现实问题。此外,由于无法从区块链中删除信息,因此只有父CA才能将其颁发的证书标记为已撤销。因此,CA在证书吊销方面的任何不当行为也将被所有其他实体跟踪和注意到。

B.设计方法论

Untitled

基于区块链的PKI是混合X.509证书,正如图2所示。证书的扩展字段中包含有关PKI环境的某些信息。扩展字段的值如下:

  • 主题密钥标识符(Subject Key identifier):持有证书所有者的身份。
  • **区块链名称(Blockchain name):**持有区块链平台的名称。目前,我们使用以太坊公共区块链,但我们希望覆盖更多平台。
  • CA 密钥标识符(CA key identifier):保存当前 CA 的智能合约地址(如果这是 CA 证书)。对于非 CA 证书,此字段为空。
  • 发行者 CA 标识符(Issuer CA identifier):持有颁发该证书的 CA 的智能合约地址。它允许验证者在区块链中找到父CA智能合约,并检查具有相应哈希值的证书是否已颁发且未被撤销。对于根证书,此字段为空。
  • 哈希算法(Hashing algorithm):保存有关哈希算法的信息,该算法用于计算加载到区块链中的证书哈希。

Untitled

基于上面的扩展结构,我们的框架设想了三种类型的证书:根CA、子CA和最终用户证书。表1说明了区块链混合证书的层次结构。第一行表示证书由其本人颁发和签名的根CA,因此没有颁发者CA,如第五列中的颁发者CA ID所示(即0x00000000)。子CA的证书在第二行中给出-它由根CA颁发,并且颁发者CA ID指向根CA。最后一行保存由子CA颁发的最终用户证书。在下一节中,我们将解释如何在区块链平台上实现这种结构。

C.架构

我们框架的主要思想是每个CA都有一个专用的智能合约,其中包含以下信息:

  • 包含已颁发证书的哈希值的数组。它还可能包括每个证书的到期日期和一些其他技术信息。
  • 证书哈希引用的吊销数据的映射。如果证书被撤销,颁发该证书的 CA 会将已撤销证书的数据添加到此映射中。

此外,如果证书是 CA 的证书,则证书本身也会加载到相应 CA 的智能合约中。由于证书包含父 CA 智能合约的地址,因此它允许验证从叶到根证书的整个证书颁发机构树(信任链)。

D.实现

所提出的基于区块链的 PKI 框架包括三个主要部分:Restful 服务证书验证和主要用于测试的 Web 用户界面

  1. Restful服务:它是使用 Golang 开发的,作为独立的 Web 服务器,提供对以太坊公共区块链的访问。它提供证书颁发、撤销和验证的所有功能。重要的是,从公共区块链的加密货币成本的角度来看,验证是“免费”进行的,因此验证不会添加或更改区块链中的数据。

    Restful服务提供了以下核心功能:

  • 注册用户(Enroll-user):将证书的哈希值添加到给定 CA 的智能合约中。作为提供哈希作为参数的替代方法,可以将证书上传到 Restful 服务。在这种情况下,哈希值是根据上传的证书计算的。

  • 黑名单用户(Blacklist-user):撤销证书,即将证书(普通证书或 CA 证书)从白名单移至黑名单。从技术上讲,这是通过添加证书哈希引用智能合约中的撤销映射。

  • 创建合约(Create-contract):为新 CA 创建空合约。这是由父 CA 在为其子 CA 颁发证书时调用的。

  • 填充合约(Populate-contract):为子 CA 创建空智能合约后,父 CA 必须将包含父智能合约地址和扩展字段中的子 CA 智能合约地址的子 CA 证书上传到其中。在子 CA 智能合约使用其父 CA 的证书进行填充后,子 CA 的以太坊账户地址将被记录到智能合约的所有者变量中,从而仅向子 CA 提供写访问权限。

  • 验证证书Validate-cert(查看/常量函数): 从 CA 树的叶子到根的证书验证。重要的是,证书的验证可以通过基于 Golang 代码或基于调用单独的验证智能合约的 Restful 服务来进行。正如我们上面所讨论的,所有验证都是以零成本进行的。

    Restful服务功能的前四个功能意味着对父证书颁发机构(CA)对应的以太坊用户的授权。 Restful 服务功能的重要特征是有意多阶段启动子 CA 注册(将子 CA 证书添加到父 CA 智能合约中已批准的证书列表中)。与仅通过 Restful 服务的 Enroll-user 功能发起的传统最终用户证书不同,子 CA 证书通过以下步骤发起:

  • 父CA应使用Create-contract函数为子CA创建空智能合约。现在父CA可以生成混合证书,将新的智能合约地址放入证书扩展的相应字段中。

  • 然后,父 CA 使用 Restful 服务的 Populate-contract 功能将生成的证书填充到子 CA 的新智能合约中。执行填充合约功能后,新智能合约的写入权将专门转移给子 CA,并将子 CA 以太坊地址填充到新智能合约的所有者字段中

  • 最后,通过 Enroll-user 函数将智能合约的哈希值记录到父 CA 的白名单中

  1. 验证:验证模块包含一个智能合约,允许验证给定证书的信任链(从叶或最终实体证书到 CA 树中的根的路径)。重要的是,智能合约验证独立于 Restful 服务的 Golang 代码验证,这是我们框架中也实现的另一种证书验证方法。显然,这两种验证方法都意味着不支付加密货币,因为区块链没有改变。

  2. 用户web界面:用户界面允许客户端测试整个应用程序 - 在不同 CA 账户下的 CA 树的不同级别添加、吊销最终用户证书。显然,Web 界面可以被视为上述 Restful 服务的外壳。值得一提的是,测试 Web 界面有自己的智能合约,用于存储一些数据,包括从父 CA 到其子 CA 智能合约的链接。这允许从证书树的根导航到叶子(最终实体证书),显然是在使用 Web 界面加载给定信任链的情况下。

E.区块链PKI的优势

与传统PKI相比,基于区块链的PKI具有以下优势。首先,证书及其CA证书链的验证简单且快速。其次,基于区块链的 PKI 解决了传统 PKI 的长期存在的问题,因为网络节点之间的区块链同步不需要使用发布证书撤销列表 (CRL) 的服务,其中对证书状态的任何修改都会立即通知到所有节点[8]。

互联网安全背景下的另一个重要方面是基于区块链的 PKI 提供了针对中间人 (MITM) 攻击的灵活保护。传统上,MITM 被认为是一种主要的安全风险,意味着攻击者通过提供该域的有效证书(即伪造的公钥)来劫持给定网站的浏览器连接。对于用户和 Web 浏览器来说,如果相关 CA 被攻击者黑客攻击,则很难识别证书的替换情况 [15]。基于区块链的 PKI 方法使得 MITM 攻击几乎不可能,因为当 CA 在区块链上发布或撤销网站/域的公钥时,信息将分布在数千个节点上,因此(理论上)将无法篡改公钥的问题[16]。传统的PKI解决MITM风险是通过在浏览器安装程序中加入Root CA证书,这就人为地扩大了CA的进入门槛,增加了根CA证书吊销所需的时间。

V.评估和实验结果

本节介绍不同的评估测试。我们从一般性能评估开始,然后测量基于区块链的功能的成本,最后讨论基于区块链的 PKI 平台的限制。

A.性能

为了证明基于以太坊智能合约的 PKI 的效率,我们在公共以太坊测试网(Rinkeby)上针对从叶(给定的 CA 证书)到根的全路径 CA 证书验证的性能进行了多项实验(信任链)。实验的思路是基于智能合约的验证和Restful服务的Golang代码验证的性能比较。

Restful服务验证: 最初我们的证书验证虽然完整的信任链是基于 Restful 服务,该服务从区块链获取每个 CA 的证书,使用Golang库解析证书以提取父CA的智能合约地址,然后根据父CA智能合约中存储的相应哈希检查证书有效性。

基于智能合约的验证:事实证明,这是一种更有效的替代方法。这个想法是,专用的智能合约专门使用以太坊智能合约编译器 Solidity 的代码来读取和解析存储在区块链中的 CA 证书。值得注意的是,由于智能合约不会改变区块链,因此验证是免费完成的。由于缺乏用于字符串操作的 Solidity 核心库,困难与解析有关。

Untitled

如图 3 所示,尽管与基于相对较短的信任链(少于 400 个子 CA)的 Golang 加密库相比,智能合约的性能可能不太令人印象深刻,但从信任链长度超过 500 个子 CA 开始,基于智能合约的验证性能高于Golang代码。

例如,对于长度约为 1100 个子 CA 的信任链,基于智能合约的验证大约需要 7 秒,而使用 Golang 加密库的 Golang 代码则需要近 15 秒。实验中我们使用了相对标准的DELL工作站,配备Intel core i7处理器,但运行内存为32GB。

B.在以太坊中启动新CA的成本

我们认为,基础设施支持成本是基于区块链的 PKI 解决方案的重要优势。假设最终用户无论如何都使用公共区块链的本地副本,所有成本基本上都包括确认将数据记录到区块链中的矿工的费用。

根据我们与 Rinkeby 测试公共区块链的实验,CA 的启动(包括创建空智能合约,上传证书到智能合约,将该证书的哈希值记录到父 CA 的智能合约等中)需要花费 0.07 以太币,根据当前每以太币约 700 美元的以太币汇率,这相当于每份 CA 证书 50 美元。

显然,普通终端实体证书的启动意味着仅将其散列记录到其父 CA 智能合约中,从而导致每个证书的成本降低至 7-10 美元。鉴于当前原始年度最终实体证书的价格高达数百美元,区块链证书成本似乎不会超过 CA 现有基础设施的成本。

C.局限性和挑战

显然,基于区块链的PKI基础设施也存在一些来自区块链技术本质的挑战。首先,公共区块链的特点是区块链大小的大幅增长,并复制到参与系统的所有节点。尤其是以太坊和其他类似平台在智能合约支持下的情况尤其如此,这对于安排高效的 PKI 非常重要。例如,2017 年 12 月,采用 FAST Sync 的以太坊 ChainData 大小达到 38.89 GB,而 2017 年 9 月为 20.46 GB

其次,加密货币的巨大波动性导致长期和短期的证书加载/更新成本存在一定的不确定性。换句话说,区块链的运营成本与以太币等相应加密货币的价格直接相关。例如,2017 年 5 月以太币价格为 85.43 美元,而 2017 年 12 月价格达到 729.01 美元,这意味着区块链运营成本在 7 个月内增长了 8 倍。

第三,如果为了证书验证,我们使用智能合约的 Solidity 代码解析,而不是外部 golang 模块(即 Restful 服务),我们可以限制使用可用于智能合约的哈希函数和非对称加密函数。例如,对于没有进行初步数据处理的以太坊,只能使用 SHA256 作为哈希函数和基于椭圆曲线密码学的 ECDSA 签名。

最后,由于修改证书颁发机构数据的访问权限是基于区块链平台的用户帐户系统,因此丢失密码将导致不可挽回地失去对帐户的访问权限。解决 CA 丢失区块链访问密码问题的一种方法是安排空智能合约,并将旧智能合约中的所有数据复制到新智能合约中,因为从理论上讲,任何智能合约始终可供任何人读取。显然,新的 CA 智能合约的建立可能会导致 CA 证书的重新颁发(至少在我们当前的实现中),因为 CA 证书可能包含对相应智能合约的引用。

VI. 结论

传统的PKI是基于CA的,因此如果一个CA被破坏,PKI系统的安全就会面临风险。文献中的各种研究调查了使用区块链技术构建安全的 PKI 系统,因此它们可以融合基于日志的 PKI 和 WoT 方法的优点,并解决传统 PKI 系统的一些问题。因此,我们的主要贡献是一个完整的、基于区块链的 PKI 框架。该框架根据 LGPL 许可证分发,并在 Github上提供。我们的框架提出的优点缓解了传统 PKI 的问题,例如快速证书撤销、消除单点故障和 CA 不当行为的困难。评估结果表明,由于合理的性能和有吸引力的维护成本,使用区块链技术构建强大的 PKI 系统的好处。作为未来的工作,我们计划开发一个浏览器插件来验证基于我们基于区块链的 PKI 框架的证书。

引用

[1] J. Yu and M. Ryan, “Evaluating web pkis,” in Software Architecture for Big Data and the Cloud.Elsevier, 2017, pp. 105–126.

[2] D. Cooper, “Internet x. 509 public key infrastructure certificate and certificate revocation list (crl) profile,” 2008.

[3] H. Anada, J. Kawamoto, J. Weng, and K. Sakurai, “Identity-embedding method for decentralized public-key infrastructure,” in International Conference on Trusted Systems. Springer, 2014, pp. 1–14.

[4] J. Prins and B. U. Cybercrime, “Diginotar certificate authority breach’operation black tulip’,” 2011.

[5] B. Laurie, A. Langley, and E. Kasper, “Certificate transparency,” Tech.Rep., 2013.

[6] S. Matsumoto and R. M. Reischuk, “Ikp: Turning a pki around with blockchains.” IACR Cryptology ePrint Archive, vol. 2016, p. 1018, 2016.

[7] S. Matsumoto, P. Szalachowski, and A. Perrig, “Deployment challenges in log-based pki enhancements,” in Proceedings of the Eighth European Workshop on System Security. ACM, 2015, p. 1.

[8] K. Lewison and F. Corella, “Backing rich credentials with a blockchain pki,” 2016.

[9] L. Axon and M. Goldsmith, “PB-PKI: A privacy-aware blockchain-based PKI,” in Proceedings of the 14th International Joint Conference on e-Business and Telecommunications (ICETE 2017) - Volume 4:SECRYPT, Madrid, Spain, July 24-26, 2017., 2017, pp. 311–318.[Online]. Available: https://doi.org/10.5220/0006419203110318

[10] C. Fromknecht, D. Velicanu, and S. Yakoubov, “Certcoin: A namecoin based decentralized authentication system,” Massachusetts Inst. Tech-nol., Cambridge, MA, USA, Tech. Rep, vol. 6, 2014.

[11] “Mozilla included ca certificate list,” 2017.

[12] E. Androulaki, C. Cachin, A. D. Caro, A. Sorniotti, and M. Vukolic,“Permissioned blockchains and hyperledger fabric,” ERCIM News, vol.2017, no. 110, 2017. [Online]. Available: https://ercim-news.ercim.eu/en110/special/permissioned-blockchains-and-hyperledger-fabric

[13] A. J. Nicholas Stifter and E. Weippl, “A holistic approach to smart contract security,” ERCIM News, vol. 2017, no. 110,2017. [Online]. Available: https://ercim-news.ercim.eu/en110/special/a-holistic-approach-to-smart-contract-security

[14] M. Ali, J. C. Nelson, R. Shea, and M. J. Freedman, “Blockstack: A global naming and storage system secured by blockchains.” in USENIX Annual Technical Conference, 2016, pp. 181–194.

[15] M. Alicherry and A. D. Keromytis, “Doublecheck: Multi-path verification against man-in-the-middle attacks,” in Computers and communications, 2009. iscc 2009. ieee symposium on. IEEE, 2009, pp. 557–563.

[16] “Blockchain & cyber security. let’s discuss,” 2017. [Online]. Available: https://www2.deloitte.com/content/dam/Deloitte/ie/Documents/Technology/IE C BlockchainandCyberPOV 0417.pdf

https://github.com/snt-sedan/pki-blockchain

A Blockchain-Based PKI Management Framework.pdf