证书透明化日志工做原理

目录

• 概念
• 一致性证实和审计证实
  • 默克一致性证实
  • 默克审计证实
• 使用证实

译：How Log Proofs Work

概念

证书透明日志使用特殊的加密算法有助于证书和日志的公共审查。这个特殊的加密算法称做默克哈希树（Merkle hash tree） ，一种包含哈希叶和结点的简单二叉树（图1）。叶子是已附加到日志中的单个证书的哈希。节点是成对的子叶或成对的子节点的哈希。全部叶子和结点的根，即根哈希称做默克树哈希（Merkle tree hash）。当日志服务器对默克树哈希（及其余信息）签名，称为签名树头（STH:signed tree head ）。

按期地，可能一小时一次，日志服务器将新获取到的证书追加到日志中。经过新获取到的证书建立单独的默克树哈希，该哈希和以前已在哈希树中的旧默克树哈希结合成新的默克树哈希（图2）。对新的默克树哈希签名建立新签名树头。反反复复的持续，以前提交到日志中的全部证书造成了一个不断增加的默克树。

一致性证实和审计证实

由于这种构造方式，默克哈希树让日志高效迅速的证实两件事：

• 全部证书被一致性地附加到日志中
• 特定的证书附加到日志中
  日志经过提供两个加密证实来支持：默克一致性证实和默克审计证实。

默克一致性证实

默克一致性证实验证一条日志的任意两个版本是一致的：即，新版本包含旧版本的一切，换句话说，全部新条目紧跟在上个版本的条目后。若是证实日志是一致的，意味着没有过时的证书且插入到日志中，日志中没有证书被修改，且日志也没有分支过。

为了演示默克一致性证实原理，假设要证实图2和图3中的日志是一致的。第一步，须要证实旧默克树哈希是新默克树哈希的子集。而后再证实新默克树哈希是旧默克树哈希加上全部中间新附加证书的结点哈希。一致性证实是计算这二者所须要的最少中间节点哈希集。

这种情形下，一致性证实由如下中间节点哈希组成：k，l和m（见图4）。用k和m建立旧默克树哈希，所以证实旧树存在且没有被改变。而后用l和k建立n，用n和m建立日志新默克树哈希。若是计算的默克树哈希和日志中的相匹配，则日志是一致性的。

监视器和审计按期使用一致性证实来验证日志是否正常。由于监视器一般有和日志中同样的证书列表，能够自行计算一致性证实，且验证日志中的一致性。设计能够简单的查询日志服务器，获得任意两个已签名树头的一致性证实。

默克审计证实

默克审计证实能够验证日志中是否有特定的证书。这是一项重要的证实任务，由于证书透明模型须要的是全部TLS客户端拒绝没有在日志中出现的证书。

为显示默克审计证实的原理，假设要验证d3证书（d叶子）已经附加到图3中里的日志中。默克审计证实是计算叶与树根之间的全部节点所需的缺乏节点哈希。若是根据审计路径计算的根哈希和当前日志中的默克树哈希相匹配，则该叶子存在于树中（或换句话说，日志中存在该证书）。

这个例子中，默克审计证实包含如下节点哈希：c,i,n(见图5)。觉得d已知，则能够用c计算出j。而后用i和j计算出m，再用n和m计算出该日志的默克树哈希。同理，若是要验证证书d4已经被附加到日志中，日志给你发送f, l, m 结点哈希的一致性证实。已知叶子哈希（ e）,也就能用叶子哈希f计算出结点哈希k，而后用结点哈希l计算出结点哈希n，再用结点哈希m和n计算出日志的默克树哈希。

任何人均可以请求日志的默克树哈希，也能验证某个证书是否存在日志中。审计一般发送这些类型的请求到日志中，以便为TLS客户端验证证书。若是默克审计证实没有计算出和默克树哈希相匹配的根哈希，则意味着日志中不存在该证书。

使用证实

证实提供审计须要的加密数据。通知，审计了解日志的不多信息，可是尽管了解有限，证实能为审计验证日志的一致性和特定证书是否已附加到日志中。

若没有证实，审计可能访问或回去全部的日志记录，以行使其职责。证实让数据交换更高效，日志和审计交换的数据量也少的多。举个例子，包好1000万个证书的日志仅须要24个结点哈希一致性证实。若是日志中增长到2000万个证书，一致性证实的结点哈希数量才到25个。

证实对于监视器也颇有用，尽管方式略有不一样。监视器一般保存监控到的日志副本，以便检查日志的每一个证书，且注意特定的证书。若是监视器检查监控到的特定日志的一致性，能够本身计算出一致性证实，而后验证日志的一致性。一样地，若是监视器老是须要特定的证书是否存在于日志中，也能够本身计算出审计证实，而后用该证实验证证书。