无密钥签名基础设施（KSI）详解（翻译论文 《Keyless Signatures' Infrastructure: How to Build Global Distributed Hash-Trees》）
说明：本文并不是逐字翻译，加入了自己的理解和梳理。
原文作者：Ahto Buldas, Andres Kroonmaa, and Risto Laanoja
原文作者公司：Guardtime AS
基本介绍
KSI不是没有密钥体系，数字签名验证的时候仍然需要密钥。但是KSI基础设施中签名验证不再依赖密钥的持续安全性，密钥丢失对签名档验证没有影响。传统的PKI体系与时间戳强相关，所以密钥丢失会对PKI系统造成影响。因为在无密钥系统中，签名者的识别和证据完整性保护是分开的。例如，签名者识别仍然可以通过使用非对称密码来完成，但是签名的完整性可以通过使用无密钥密码（单向无碰撞哈希函数，不涉及任何秘密密钥的公共标准转换）来保护。
无密钥签名的步骤如下：
（1）哈希过程：对需要签名的所有文件进行哈希计算，得到对应哈希列表
（2）聚合：第一轮对哈希列表中的所有hash进行签名，并根据签名创建全局的临时哈希树，该步骤持续时间长短不一，设置的时间是1s。
（3）发布：上一轮中创建的哈希树根被收集到永久哈希树，并生为永久哈希树生成最高哈希值，该哈希值被设定为新的信任锚。
KSI中的哈希树（Hash Trees）和哈希日历（Hash Calenders）
Merkle哈希树是KSI中的基础，但是KSI中的哈希树叫哈希日历。 哈希日历是单向增长的哈希树：每秒钟（UTC时间）新的哈希树都会聚合到左侧已有的哈希树上，生成新的最高哈希值。新的哈希值的生成算法有两种：一种方法是确定性算法可以计算链接哈希树的顶部，从而每秒提供一个不同的顶级哈希值。另一种算法，用于从链接哈希树的形状中提取每秒的时间值，从而为每个已发行令牌提供难以修改的时间值。
在哈希日历中，无法向已经聚合的哈希树中添加请求，从而保证了哈希日历中的哈希树的单向性、抗冲突性，保证了回溯的安全性。
哈希日历的顶层哈希计算算法流程如下图所示：
KSI服务设计原则
（1）提供全局扩展的时间戳。
（2）易于审核和认证，高效和高鲁棒性。
（3）底层数据结构保证无法发布虚假、回溯的或者其他有误导性的签名令牌。
（4）通过构建冗余集群，消除单点故障，提供可靠的KSI核心网络环境。
（5）每一次聚合操作都是不可撤销的
（6）每次计算之后的顶层哈希都需要上传到难以修改的媒体介质，比如报纸、流行的微博平台、电子分发和经过数字签名的出版物清单。具体发布介质根据实际需求修改。
KSI聚合
聚合流程
（1）应用程序通过工具对文档生成签名（或时间戳）。
（2）应用程序发起聚合请求，请求被发送到网关（发送服务到终端用户）。
（3）网关对在其聚合周期中接收到的请求进行初始聚合。
（4）网关将其聚合请求发送到上游聚合集群。
（4）请求通过多层聚合服务器进行聚合，并由核心集群选择全局唯一的顶级哈希值。
（5）通过聚合层发送响应。
说明：每个聚合周期的顶级哈希值存储在“日历数据库”中，并通过“日历缓存”层分发到扩展程序服务，该服务通常与网关主机位于同一位置。 客户端应用程序通过扩展程序服务进行验证。
上述KSI聚合流程如下图所示：
多层聚合服务器
（1）在多层聚合服务器中，来自上游组件对同一回合的后续响应将被忽略，因此可以并行运行多个聚合器以提高可用性。
（2）临时聚合树在水平方向上分为四层（如下图），并依此构建基础结构，以使顶层与核心群集相邻。 两个中间层提供了地理范围。 底层与网关捆绑在一起，并托管在终端用户附近。 每个聚合器通过将其下游客户名称哈希到哈希树中来标记其下游客户。 这些前向安全标签用于标识不同服务终端的分层名称空间。
（3）上述的聚合树在线性水平上非常容易扩展。目前为了提高效率，只有1个签名哈希令牌。初始设定的哈希树的深度是50层，则可以包含的签名容量是：（250 ≈1015）/秒。该初始容量设定基本可以满足大多数服务需求。
（4）每个网关和聚合服务器都生成不变的上游网络流量，该流量与负载无关。这种设置使网管、聚合服务器与客户端分离，不会造成实际服务使用情况信息泄漏，同时提供拒绝服务攻击隔离。
（5）为了避免多层聚合服务器的单点故障，聚合服务器是物理上分散的并行工作的集群。这样低层的服务器可以把聚合请求传给所有上层的聚合服务器，然后将最快反馈的聚合服务器作为下一层的聚合服务提交者。同时，聚合服务器支持不停服配置和扩容。
核心服务器集群
（1）核心服务器是一台分布式同步计算机，负责对每个聚合周期的最高哈希达成共识，并将其持久化存储在日历数据库中，同时将结果返回到聚合网络。
（2）内核保持准确的时钟值，该时钟值作为每个签名的时间戳呈现给客户。
（3）日历数据库使用“dumb”缓存层将日历数据库分发到扩展服务器，以进行签名验证。
（4）核心服务器集群达成共识策略（比如服务为送达，接收到不同序列的请求，部分机器宕机的情况等）：多方协议。具体做法：将其顶级哈希值传播到所有核心节点，其中在每个可能重叠的回合结束时，大多数核心服务器具有相同的顶级哈希值集，则具有不同集合的服务器将知道它们不属于多数服务器。只有属于多数服务器的核心服务器节点可以把最高哈希值写入到日历数据库。基于多方协议策略，核心服务器集群中的节点可以自动从网络连接错误或其他问题中恢复。多方协议平均协议时间是（连接的）核心服务器之间往返的1.5倍（未考虑恶意安全模型——拜占庭模型）。
网关
（1）网关是协议适配层，接收（RFC3161, OpenKSI ）类型的请求
（2）转发请求到指定的聚合服务器，通常第一层聚合服务器在网关服务器上，以此降低聚合带宽。
（3）网关一般运行着一个验证服务——签名验证助手。该服务通过拷贝最新日历缓存来验证签名的合法性。
（4）哈希链式通过客户端API生成。令牌的合法性在应用层确定。应用层会存储所有令牌的详细信息，以便进行重新创建哈希链表，因为应用层不会将网关认为是可信第三方。
KSI验证
KSI可以为电子数据提供独立并且永久的完整性证明，当客户端需要提起数据验证时需要提供如下材料进行验证：
（1）原始文件数据
（2）聚合层返回的无钥签名信息（包含类似merkle树的SPV（简单支付验证）验证路径。）
（3）完整码（当时时间片生成的Top Hash，日历数据，可从公共媒体库上获取）
上述的扩展程序服务（包含“日历缓存”层数据）根据客户的提交的信息进行验证：
（1）根据原始数据根据哈希算法计算文件哈希
（2）根据文件哈希和无钥签名信息使用对应计算规则生成完整码
（3）将步骤（2）中的完整码与KSI公共媒体库上的完整码进行比对，返回验证结果信息。
KSI服务优化
本部分讨论如何优化延迟并消除KSI服务响应时间的“长尾”。
简化方法（同层聚合服务器集群）
由于聚合网络为了消除单点故障的可能，所以聚合网络都是冗余建设，聚合网络集群越大，聚合网络的时间延迟（Merkle哈希树构建，顶层哈希计算，发送请求到上层聚合服务器）越严重。
（1）假设聚合周期为 d（上面已经说过聚合服务器的周期是固定的）
（2）一个请求从创建到到达聚合服务器的时间为 t，则对应请求的延迟是 d-t，所以请求越晚到达，则延迟越小。因此，优化的目的是如何合理设置聚合周期，使得聚合延迟最小。
如果聚合服务器集群中各个聚合服务器顺序（这样才能说通下面的公式）进行聚合，则聚合延迟时间如下：（后面部分的推导是自己的理解，如果不对请更正）
（1）假设有2个聚合服务器，聚合周期是 d ，则请求到达第2个聚合服务器的时间是 d/2（而不是0），所以此种情况下，平均延时时间是 d/4（不是 d/2）。此种情况下聚合延迟与时间的关系式是：
其中：t 属于[0, d]
（2）基于上述公式得到的平均值是 d/4。
（3）如果集群中有m个聚合器，则到达第i个聚合器的时间是 i/m。则对应的时间关系式是：
则平均延迟时间是： d/2m。
通过上述分析，减小聚合延迟的方法是在群集中通过交错聚合回合来减少服务延迟。
实用方法（跨层聚合服务器C to P）
引起跨层传输延迟的原因：
（1）跨层的时间延迟主要是由于传输距离（地理位置、网线长度等）引起，这种延迟是无法进行优化的。
（2）全局的网络路由选择传输路径策略导致的延迟。
（3）网络抖动导致的传输延迟。
上述的几种情况导致的95%延迟的时间在25-40ms（毫秒），所以，可以通过将聚合层 P的时间周期设置为 t+40ms。 其中t为 聚合层 C 请求到达聚合层 P 的时间。在实际应用中，这种延迟的时间远低于d / m。
经验实验总结
论文中的数据测试环境是：在日本东京、长野和欧洲的实验室。核心服务器在欧洲。
实验数据实在环境比较简陋的实验室，数据时长是24小时。
通过实验得出如下结论：
（1）请求几乎没有失败的情况，因为网络各层都有自动重试机制。
（2）聚合延迟主要由底层网络引起：从AN到ATL的往返延迟约为270ms，其他网络延迟则小得多。 所有层的时钟漂移小于4ms，核心协议投票时间为48ms。
所以优化的总结如下：
（1）通过交错聚合来同步聚合周期可以减小聚合延迟。
（2）通过200 ～400ms的聚合时间可实现最低的延迟。 实验从200毫秒开始，后来又恢复到400毫秒，以减少数据流量。
（3）在冗余集群中，虚拟服务器更优。3台虚拟服务器比2台物理机花费更少时间同时提供更好的服务。
（4）虚拟服务器的时间流可能不稳定，但它有助于使本地磁盘IO保持最小。 需要设置网络日志记录。
（5）基于TCP的服务虽然更容易实现，但是它有些无法避免的问题，比如“Idle之后启动比较缓慢”的问题。
生产环境部署建议
（1）合理的NTP时间同步配置
（2）根据每个聚合层的每个聚合服务器站点之间的实测RTT，配置最佳时序偏移
（3）集群配置2～3个聚合服务器可以满足需求
（4）核心服务器不需要任何修改，因为它的时钟已经使用原子钟，该始终已经与高质量的UTC时间源同步了。
（5）一天中不允许SysOps（系统操作）接触多个群集成员
（6）网络协议必须具有版本控制机制，以支持部分推出新版本
（7）测试必须在完全独立的系统上执行
以上是对论文《Keyless Signatures' Infrastructure: How to Build Global Distributed Hash-Trees》的翻译和理解，如果不对和不足的地方欢迎提出修改意见。
