假设爱丽丝从计时员蒂娜那里收到同步时间。假设泰德欺骗了 GPS 信号,欺骗了蒂娜关于当前时间的信息。蒂娜将这个假时间发送给爱丽丝。
爱丽丝可以做些什么来避免被太严重地愚弄?是否有实施此类缓解措施的实施?
一种方法可能是拒绝与 Alice 的内部时钟相比变化太大的建议时间。
编辑:
- 假设外部时间受到损害,我正在寻找缓解措施。没有额外的可信赖的外部时间源。
- 缓解目标是尽量减少或消除 Alice 的受骗情况。
- 攻击者可能会尝试一次更改时间或在更长的时间范围内更改时间。
假设爱丽丝从计时员蒂娜那里收到同步时间。假设泰德欺骗了 GPS 信号,欺骗了蒂娜关于当前时间的信息。蒂娜将这个假时间发送给爱丽丝。
爱丽丝可以做些什么来避免被太严重地愚弄?是否有实施此类缓解措施的实施?
一种方法可能是拒绝与 Alice 的内部时钟相比变化太大的建议时间。
编辑:
没有单一的方法可以减轻时间欺骗攻击。但是,从多个来源获取时间信息并确保没有一个来源之间存在太强烈的分歧是一个开始。
RFC 1305中指定的通用版本 3 的网络时间协议是最广泛使用和最知名的获取时间的方法。它是一种未经身份验证、未加密的协议,使用 UDP,使得欺骗和篡改非常容易。通常,用户将从第 3 层服务器池中轮询时间。Stratum 是指离开源后必须经过的服务器数量,通常是测量原子状态转换的机器。一秒精确定义为超精细 基态的 9,192,631,770 次跃迁接近绝对零的单个铯 133 原子,与这些状态变化相对应的辐射发射是参考时钟的准确性。常用的层有四种:
每个层都连接到较低的层,以避免靠近源的服务过载。Stratum 0 不是常规的联网服务器,而是直接连接到第1 层(例如通过 RS-232)。仅允许选择需要极高准确性的服务(例如,用于科学实验)连接到第 1 层。第 2 层服务器可能对谁可以连接有特定的政策,而有时他们可能只是礼貌地要求您在没有必要的情况下不要使用它们. 任何人都可以使用 Stratum 3 服务器。最多可以有 15 个层,第 16 层表示不同步,但实际上,第 3 层是最后一层。除了第 0 层之外的每个层都能够与同一级别的其他层同步,以提高准确性并减少时钟偏差问题。
有很多服务器值得信赖。虽然与其他服务器存在重大分歧的服务器将被踢出,但只有当它发生得足够频繁时才会发生这种情况。针对单个用户或一组用户的有针对性的攻击很容易被忽视。您的 NTP 客户端可能会平均出您正在使用的池中所有成员给出的时间结果,或者它可能会忽略那些看起来很疯狂的结果。对于这种情况,单个恶意 NTP 服务器并不是什么大问题。但是,由于 NTP 未经身份验证和未加密,因此单个实体从您正在使用的所有服务器中为您提供错误值并不难。
没有办法完全避免这个问题。使用多个 NTP 服务器有助于防止幼稚的攻击和意外的错误配置。通过 VPS 或 VPN 路由 NTP 也可能稍微提高标准,特别是如果您怀疑您的对手不愿意为所有人劫持 NTP并且无法确定哪个服务器代表您连接到 NTP。RFC 5906中为 NTPv4定义了一种经过身份验证的 NTP,但很少有 NTP 服务器支持它,而且配置起来并不简单。
GPS 的工作方式是发送一个周期性的、完全同步的信号(每个 GPS 卫星都有三个第 1 层源)。当一个信号早于或晚于另一个信号被接收时,您将知道您与该卫星的距离比另一颗卫星更近或更远(因为光速是有限的)。通过考虑来自多个来源的这些相对时间差异,可以判断您相对于在轨卫星的位置,从而判断您相对于地球的位置。
GPS时钟通过组合多个轨道卫星给出的时间来工作。此时间信号可用于同步时钟,但除非您知道自己的精确位置,否则可能需要一些时间对信号进行平均才能获得准确的时间。一个高端的、基于 GPS 的专用时钟,如果校准得当,可以精确到一微秒以内。
GPS欺骗并不是特别困难,但很容易检测到。GPS 信号与 NTP 一样,未经身份验证和未加密。三是没有简单的方法来防止这种情况。
无线电控制时钟或 RCC 从直接连接到高精度时钟源(例如第 1 层服务器)的无线电发射器传输时间代码。使用的频率可以是长波或短波,在25 KHz 和 25 MHz之间变化。市场上标有“原子钟”的设备通常使用 RCC,因为它很简单并且需要很少的功率来接收。它们非常准确,可在几微秒内提供精度。
与 GPS 一样,它们极易受到欺骗。
TLS 是传输层安全性,用于加密和验证 TCP 上的通信。
这是一种有趣的保持时间的方式。TLS 1.2 规范在 ClientHello 请求中提供了一个字段,该字段包含当前时间,以纪元以来的秒数为单位。这并不总是可靠的,因为许多服务器的时间戳要么不准确,要么纯粹是随机的。TLS 1.3计划完全取消这个时间戳,所以这不是一个长期的解决方案。从 RFC 的第 7.4.1.2 节:
Structure of this message:
The ClientHello message includes a random structure, which is used
later in the protocol.
struct {
uint32 gmt_unix_time;
opaque random_bytes[28];
} Random;
gmt_unix_time
The current time and date in standard UNIX 32-bit format
(seconds since the midnight starting Jan 1, 1970, UTC, ignoring
leap seconds) according to the sender's internal clock. Clocks
are not required to be set correctly by the basic TLS protocol;
higher-level or application protocols may define additional
requirements. Note that, for historical reasons, the data
element is named using GMT, the predecessor of the current
worldwide time base, UTC.
random_bytes
28 bytes generated by a secure random number generator.
因为服务器发送的“随机”字段的前四个字节包含当前时间,所以可以(ab)使用 TLS 握手从经过身份验证的源获取时间。这就是tlsdate程序所做的。为了获得准确的时间,可以连接多个 TLS 服务器并平均时间。这是由 Tails 使用的。Tails硬编码了三个 TLS 服务器“池”:
Tails 从每个池中查询一台服务器并将结果平均出来,如果其中任何一个过于强烈地反对,就会放弃。这个想法是,池具有足够不同的从属关系,因此它们不太可能合作在其 TLS 时间戳中提供恶意不正确的时间值。这个设置的具体原因是未知的(看起来有点像自制安全),但从 TLS 握手中提取时间的想法本身是相当可靠的。
实时时钟RTC 是任何计算机中的一个组件,是 CMOS 芯片的一部分。它通常使用 32,768 Hz 的石英振荡器进行计时,通常由纽扣电池供电。与频率由自然界中的基本常数决定的铯原子钟不同,石英振荡器被有意调谐到该频率,从而导致轻微的缺陷。我实际上不知道它被调整到这个特定频率的原因(它看起来太完美了,正好是一个有符号的 16 位整数的最大值),但是在写这个答案的时候查了一下,原来是这个值之所以选择它,是因为它总是可以被 2 整除,因此非常适合转换为控制数字手表所需的 1 Hz 信号。频率刚刚卡住。
这实际上是你为你做的最重要的事情。您的 RTC 并不完全准确,但它不能被攻击者直接控制(尽管有间接的方式来影响它,例如强电磁场或环境热量)。只要至少正确设置一次,您始终可以确保检测到严重的时钟偏差攻击,因为您的 RTC 永远不会漂移太远。
这些是相当多的来源,每个都有自己的优点和缺点。事实证明,有一种简单的方法可以将它们全部结合起来。由 OpenBSD 背后的同一个人设计的OpenNTPD项目能够一次组合所有这些时间源。它主要是一个 NTP 服务器,从给它的 NTP 池中获取时间并使用它来设置系统时间。
OpenNTPD 还支持经过身份验证的 TLS 约束,其中使用从 TLS 握手获得的时间戳来确保 NTP 响应不会太不准确。它不是为用作主要时间源而设计的。这类似于 tlsdate,但不受 TLS 握手中时间戳的潜在不准确性的影响。也可以使用硬件时间源,例如 GPS 或 RCC。当然,这需要实际的硬件,但它可以提供更高的准确性。
与许多其他 NTP 实现不同,OpenNTPD 不会在时间更改时立即设置时间。相反,如果时间向前或向后跳跃,它会逐渐改变您的系统时间,使其与当前时间的视图相匹配。例如,它不会立即将时间设置为未来或过去 5 秒,而是会加快或减慢时钟频率,并以非常小的增量将其向前或向后推动。虽然这旨在避免混淆依赖于相对时间戳的应用程序,但它也有助于减缓想要立即将您的时钟设置到过期和受损证书仍然有效的点的攻击者。
OpenNTPD受到了批评(以及对上述批评的回应)。该项目的简单性意味着它缺乏一些提高时间准确性的健全性检查和算法,最多只能达到 200 毫秒的准确性。这不是安全问题,但对于某些应用程序可能并不理想。对于普通电脑用户来说,已经绰绰有余了。