Dns transparency 调研

 证书放在分布式独立账本中。用户代理：验证证书是否已合法添加到日志中，来帮助执行证书审核。监视器：确保所有记录的证书在日志中可见，并监视日志中的可疑证书。

Certicate Transparency Using Blockchain

 使CA在未获得域名所有者同意的情况下无法为域名颁发证书（CT的作用）。使用Go写（hyperledger）。

 证书透明度的最终目标是Web客户端应该只接受公开记录的证书，并且CA不可能在没有公开可见的情况下为域颁发证书。在最终确定其有效性之前，未经授权的证书可能会被浏览器接受。在本文中，我们建议域所有者在授权其域的证书时拥有绝对控制权。域名所有者直接参与其域名的证书颁发过程。

 CT细节：Auditors使用一致性保护（由Log Servers提供）来验证日志的新条目是否总是添加到日志的旧条目中，并且没有人通过追溯插入、删除或修改证书来损坏日志。一致性证明允许Auditors验证其对特定日志的当前视图与其过去的视图是否一致。Monitors监视Log Servers日志中的可疑证书。Monitors 还验证所有记录的证书在日志中是否可见。他们通过定期获取添加到日志中的所有新条目来实现这一点。因此，大多数Monitors都有其监视的日志的完整副本。

Log Servers 如何维护证书、生成审计路径和提供一致性证明

 如何维护证书？CT中的日志服务器使用Merkle哈希树来促进证书的公开审计。二叉树，叶节点是证书哈希，非叶节点是子节点合并起来，然后哈希。

 生成审计路径？叶节点到根节点的路径。

 提供一致性证明？验证日志的两个版本是否一致。举例说明，如下所示，首先一致性证明是给出新树的信息(c,h(x_4),h(x_5),h(x_6))。之后，验证d==h(c,h(x_4))，来验证旧树是否正确。之后验证h==(c,h(h(h(x_4), h(x_5)), h(x_6)))是否正确，如果正确则满足一致性。

Hyperledger Fabric（HF）

 一个开源区块链平台。

 包括：（1）Chaincode：是一种实现应用程序逻辑的程序代码。（2）Endorsement Policy：定义哪些节点需要对交易进行确认。

 流程：（1）Execution Phase：在此阶段，客户将交易发送给背书政策指定的特定对等方。这样的消息是一个已签名的请求，用于调用链代码函数。它必须包括链代码id、时间戳和事务的有效负载。然后，每个事务都由特定的对等方执行，并记录其输出。背书对等方根据当前状态模拟/执行事务。对等方将此执行的结果与认可对等方的签名一起发送给客户端。此时没有对分类帐进行更新。客户收集背书并将其组合成交易。客户端验证验证对等方的签名，并检查认可策略是否已执行。如果满足这些条件，客户端将使用对等方的读写集、签名和Channel id创建一个签名信封。上述信封代表交易提案。（2）Ordering Phase：客户将向排序服务广播交易建议。排序服务不阅读信封中的内容；它只收集网络中所有频道的信封，对其进行排序，并创建包含这些信封的签名链块，最后广播给所有的对等方。（3）Validation Phase：在此阶段中，每个对等点随后验证与认可策略和执行一致性相关的认可交易的状态更改。所有对等点都以相同的顺序验证事务，并且验证是确定性的。最后，每个对等点将块附加到链上，并且对于每个有效事务，写集合被提交到当前状态数据库。发出一个事件，通知客户端应用程序事务已被不变地附加到链上，并通知事务是有效的还是无效的。

具体实现

 将证书透明度所需要的log变成了hyperledger。

 hyperledger是一个账本，元素是(domain, cert)。账本更新需要(old cert, new cert, old key signature)。

 证书撤销。将元素改为(domain,(cert, revoked/not revoked))。

Certificate Transparency with Enhanced Privacy

 方案贡献：（1）在恶意日志服务器试图迫使用户接受实际上没有在日志中注册的假证书的情况下，用户应该能够验证从日志服务器接收到的证书验证消息是否是恶意生成的（即，基于假证书进行操纵）（用区块链与不用区块链）。（2）用户的浏览隐私：在证书验证过程中，用户的任何浏览信息（如用户希望访问何种网络服务器）都不应泄露给外部实体，如日志服务器和监视器。

 要解决的问题：（1）一致性。不同位置，日志记录的相同。（2）时间前后，后面日志包含前面日志。

share value tree（SVT）

 非叶节点与叶节点。非叶节点x表示阈值门，x.n表示x的子节点数量，x.s表示x的共享值，x.k表示其阈值。

不用区块链来抵御split-world attack

 使用秘密共享树，与monitor进行交互，来解决上述两个问题，同时保护用户隐私。但是monitor密钥轮换是一个问题，而且可能需要多个Monitor。

LogPicker: Strengthening Certificate Transparency Against Covert Adversaries

SoK: SCT Auditing in Certificate Transparency

 目前，现在的问题是缺乏审计，即Auditors，因为我不用区块链，还要保持日志一致性，所以就需要一个构造合理的Auditors。

 客户端直接查询日志：客户端直接向日志进行查询是否有某个证书。但有两个问题：1. 没有隐私，日志能够知道客户端访问的哪个网页；2. 日志无法确认客户端是合法的，要不就会向外部共享证书。

 客户端通过代理来查询日志：保证代理与日志没有串通，且会增加延迟。其中，可以将DNS服务器当作代理，因为日志知道DNS服务器对证书感兴趣，因此日志不会知晓客户端的信息。（google提出来的，可以在DNS的回复中获取证据信息。）但此方案有隐私风险：（1）SCT审查可能是异步的，SCT审查通过不同的DNS进行路由，从而定位客户端位置；（2）DNS会进行预取，预先取SCT，而客户端此时不需要，可能会暴露客户端其他信息。（google已经放弃DNS方案）

 在客户端直接查询日志的方向上，还有一个思路，我们可以让日志知道客户端现在正在查询证书，但是日志不知道客户端查询的什么证书。（1）Fuzzy ranges。日志可以向客户端证明其要的证书在某个范围内，而不是证明某个证书是否存在。其可以让客户端查询两个索引之间的所有条目，但是证书需要包含序列号，会增加通信与计算成本。且客户端在查询时，需要查询一个范围，如果客户端向多个日志进行查询，且日志之间是串通的，那么就可以取交集，来缩小范围。（2）PIR（私有信息检索）。PIR就是客户查询隐私，服务端内容全局可见。现有解决方案大多在双服务器的PIR上运行。但是，还要验证STH（signed tree head）与之前信任的STH的一致性。这也要求证书需要包含序列号。这些方案存在开销过大的问题。（3）私有集求交（PSM）。要求服务器与客户端都不知道对方的信息，即客户端不知道服务器的其他信息，服务器不知道客户端要查询的内容。

 还有一种，客户端与日志不通信，那么日志就不会知道客户端访问的什么网页。其方法有：（1）客户端本地保存日志，对客户端存储有重大挑战。（2）CA将包含证明SCT嵌入到证书中，这样客户端就不用去问日志。如果日志立即将SCT发给CA，那么

注：SCT是由证书颁发机构（Certificate Authority，CA）签署的证书签名时间戳，用于证明该证书已被提交到证书透明度日志（CT log）中。SCT确保了证书的公开性，因为它们可以让任何人验证证书是否已经被提交到日志中。STH是一个包含了所有已提交到CT日志中的证书哈希值的数据结构。STH由CT日志的管理员签名，确保了日志的完整性和公开性。STH还允许任何人验证日志中的证书数量和内容是否已被篡改。SCT和STH之间的关系是，SCT证明了证书已经被提交到CT日志中，而STH则提供了CT日志的完整性和公开性证明。SCT和STH的结合确保了证书透明度系统的安全和有效性。