CloudFlare开源网络时间安全协议：同时支持NTP和NTS

CloudFlare最近宣布其网络时间安全（Network Time Security，NTS）协议发布第一个主要版本。该版本构建在他们之前发布的time.cloudflare.com之上，这是其免费的时间服务，支持网络时间协议（Network Time Protocol，NTP）和NTS。

CloudFlare的免费时间服务time.cloudflare.com，同时支持NTP和正在兴起的NTS协议。但是，在它发布的时候，并没有太多可用的NTS客户端。随着他们的新CFNTS项目的发布，CloudFlare希望能够鼓励NTS协议的广泛采用。NTPSec最近发布了对NTS的支持。

如果你组合使用time.cloudflare.com和NTPsec或者它们的新CFNTS项目的话，CloudFlare推荐启用NTS。他们还提到daemon需要支持TLS 1.3。

NTS是由两个子协议形成的套件。第一个是网络时间安全秘钥交换（Network Time Security Key Exchange，NTS-KE）。该协议负责秘钥材料的创建，并且负责与第二个协议NTPv4的参数协商。NTPv4是当前版本的NTP协议，允许客户端与远程的服务器同步时间。

CloudFlare的加密工程师Watson Ladd和软件工程师Pop Chunhapanya这样说到：

为了维护NTPv4的可扩展性，很重要的一点就是服务器不维护每个客户端的状态。一个很小的服务器就能为数百万个NTP客户端提供服务。在提供安全性的同时又能保证这种属性是通过cookie来实现的，cookie由服务器提供给客户端并且包含了服务器的状态。

为了在第一阶段完成这一点，客户端需要发送一个请求给NTS-KE 服务器并通过TLS获取一个响应。在这个阶段，涉及到多个功能：

• 协商在第二阶段使用的AEAD算法；
• 协商第二个协议（目前，标准只定义了NTS如何与NTPv4协作）；
• 协商NTP服务器的IP地址和端口；
• 创建第二阶段使用的cookie；
• 从TLS会话创建两个对称秘钥（C2S和S2C）。

NTS过程的第一阶段

在第二阶段，客户端现在可以安全地与协商过的NTP服务器同步它们的时钟。为了确保安全完成，客户端会发送带有四个扩展的NTPv4包。第一个扩展为唯一的标识符扩展，包含了用于防止重播攻击的随机nonce。第二个扩展是NTS cookie扩展，它会为客户端提供两个cookies中的某一个。因为只有客户端记得两个AEAD秘钥（C2S和S2C），所以服务器端需要这个cookie来提取秘钥。每个cookie中包含了秘钥，这些秘钥由服务器端所持有的秘钥进行了加密。

第三个扩展是NTS cookie占位符扩展，这是客户端发送给服务端的一个信号，用来请求额外的cookie。之所以需要它是为了确保响应不会比请求明显长太多，以避免放大攻击（amplification attacks）。最后一个扩展是NTS认证器和加密扩展字段的扩展，它包含AEAD算法的一个密文，以C2S作为密钥，NTP头信息、时间戳和所有上述的扩展作为相关的数据。我们需要此头信息来防止时间戳仿造。

按照Ladd和Chunhapanya所述：

第二次握手可以重复很多次，而不会回到第一个阶段，因为每个请求和响应都会给客户端一个新的cookie。因此，TLS中昂贵的公钥操作被分摊到大量请求中。

团队决定使用Rust来实现他们的服务，这与他们通常所选择的Go语言有所不同。正如作者们所指出的，他们决定使用Rust是因为“在响应NTP包的过程中垃圾收集暂停将会对精确性产生负面影响”。他们还指出，Rust的内存安全性、不可为空性、线程安全性、不可变性和错误处理的特性是他们做出选择时的主要考虑因素。

随着这个版本的发布，CloudFlare已经将他们的时间服务添加到公共NTP池中。NTP池是一个由志愿者维护的服务，它在世界范围内提供NTP服务器。然而，他们注意到NTS在池模型中不能很好地运行。为了获得最佳的安全性，CloudFlare建议启用NTS并使用time.cloudflare.com或其他支持NTS的服务器。

CFNTS服务已经基于2-Clause BSD许可证开源。CloudFlare希望他们的解决方案能够让更多的客户在未来支持NTS。目前，他们正在积极地寻求对代码库的贡献。

原文链接：

CloudFlare Releases Open Source Implementation of Network Time Security Protocol