NTP协议安全性分析

《NTP协议安全性分析》由会员分享，可在线阅读，更多相关《NTP协议安全性分析（7页珍藏版）》请在装配图网上搜索。

1、三、NTP的安全机制考虑到 NTP 协议的应用特点，关于时间服务的数据可以公开，因此对数据包的保密性 不做特别要求，NTP协议面临的安全威胁主要在于攻击者恶意重放，篡改数据包或假扮合 法服务器为客户端提供错误的时间。所以NTP安全机制更多地考虑数据包的认证性，即进 行源认证和保护数据的完整性。这里我们主要针对NTP协议的客户端服务器模式的安全机制进行研究。3.1传送时间戳检测伪装和重放NTP数据包中有两个时间戳：Originate timestamp表示客户端对服务器的请求离开的本 地时间，Transmit timestamp表示服务器对客户端的响应离开的本地时间 传送时间戳是NTP数据包头部

2、的一个字段，用于检测数据包的伪装和复制。它是一个临时 值，通过在 64 位传送时间戳的非重要的位中插入随机数。对于这个时间戳不要求它是正确 的，也不一定是单调递增的，但必须保证每个传送时间戳是不同的，无法在0.232ns内被预 测出来，也就是保证入侵者无法提前预测传送时间戳的值。 如果一个包的传送时间戳和以前的包的传送时间戳一样，则检测出这个包是复制的，这时丢 弃这个复制品。在客户端/服务器和对称模式中，我们比较客户端请求数据包中的传送时间 戳和服务器响应数据包的原始的时间戳。如果二者不同，表示这个服务器数据包是伪装的， 是旧的复本或传送时丢失的。3.2消息摘要保护数据包的完整性对称密钥算法中

3、，客户端和服务器需要预共享消息密钥（以下称为对称摘要密钥）来计 算消息摘要。对称摘要密钥由密钥文件定义。当程序启动时，就装载一个这样的文件。每一 行包括密钥ID, 个摘要算法标识和对称摘要密钥。（1）客户端发送时间请求报文。客户端自行选择使用的对称摘要密钥，将密钥 ID 写 入报文中，用对称摘要密钥与NTP请求报文一起算出MAC。MAC = H （symmetric key | NTP packet）（2）服务器发送时间响应报文。服务器对客户端数据包的完整性认证，服务器根据客户端的密钥ID找到对称摘要密钥, 验证客户端数据包中的MAC。将对称摘要密钥与NTP响应报文进行哈希，计算出MAC。MA

4、C = H （symmetric key | NTP packet）（3）客户端利用对称摘要密钥，验证服务器响应报文中的MAC。3.3 Autokey 模型自动分发对称摘要密钥用于生成MAC的对称摘要密钥可以不通过密钥文件定义，而是通过AutoKey协议模型 来实现对称摘要密钥的协商，对称摘要密钥的协商在 NTP 数据包的扩展域中完成。以下 Autokey 就表示对称摘要密钥。331基于Autokey的MAC计算(1) MAC的计算使用扩展域协商对称摘要密钥时的MAC是公共值和NTP头部和扩展域的MD5消息摘 要：MAC = H (public value II NTP packetll ex

5、tension field)使用对称摘要密钥进行时间同步服务时MAC是对称摘要密钥与NTP头部的MD5消息 摘要：MAC = H (Autokey | NTP packet)(2) 对称摘要密钥(Autokey)的计算Autokey = H (Sender-IP II Empfanger-IP II KeylDII Cookie)H ()是MD5消息摘要，结果为16个字节密钥ID是仅使用一次的伪随机序列。特殊的0值用于crypto-NAK应答报文中。(3) Cookie的计算Cookie = MSBs32 (H (Client IPII Server IPII 0II Server Seed)

6、服务器使用客户端和服务器地址和私有值(服务器种子)为这个客户端生成唯一的 cookie。(4) 生成密钥摘要列表服务器选择一个随机的32位种子作为初始的密钥ID。初始的摘要密钥使用给定的地址, cookie和初始的密钥ID构建，摘要密钥值存储在密钥cache中。下一个摘要密钥使用摘要 密钥值的前4个字节作为新密钥ID.服务器生成完整的列表。当密钥列表中所有密钥用完后, 就生成新的密钥列表。Index n+ 13.3.2 Autokey协议格式（NTP扩展域）Field TypeLengthAssociation IDTim/怡 nipFilestampValue LengthValueSigm

7、ture LengthSignaturePadding (as needed)Value Fields (optional)NTP Extension Field扩展域包括域类型，长度，关联ID,签名时间戳，用于验证密码媒介的文件戳。关联 ID是当发起客户端联盟时分配的临时值。3.3.3验证服务器的身份1、可信证书：服务器发送证书建立从服务器自身到可信机构的证书链。如果证书没有被服务器自身发行，则客户端继续请求发行者的证书。如果客户端最终收 到一个自己生成的证书，则检查这个证书是否来自可信机构。通过这种方式建立了从服务器 到可信机构的证书链认证。2、私有证书：客户端和服务器有带有相应私有密钥的

8、相同证书，与预共享密钥相似。 但是如果一个组内多个客户端使用相同私有密钥，则它们每一个都能向其他客户端伪装成服 务器。必须注意的是，私有证书能够在完成公钥交换的同时保证身份认证，而在可信证书机制 中，客户端没有存储可信证书列表，如果请求的证书的扩展域中包含“可信根”字段，则客 户端就认为这个证书来自可信机构。攻击者很容易伪造这样的一个证书：。攻击者的公钥值。服务器标识符信息（服务器名称） o有效期（证书的有效时间）。颁发者标识符信息（服务器名称）。颁发者的数字签名（攻击者的公钥与服务器名称的绑定） 。在扩展域“X.509v3 Extended Key Usage包含了“trustRoot可见，

9、信任不是由客户端已经拥有了来自可信机构的证书建立的，所以说通常情况下， 在可信证书交换的以后，还需要使用基于挑战应答进行身份认证。以下是三种基于挑战应答 的身份认证机制：1、基于公共参数的挑战应答：客户端有服务器的公共参数，客户端确切地知道这些参 数属于这个服务器。但是这些参数不需要保密。客户端发送一个随机值（挑战）给服务器。 后者计算一个值证明它拥有作为公共参数一部分的秘密之一。不保密的话，其他人知道不也 能计算吗？可信代理生成IFF参数，将它们以安全的方式传送给所有的组成员。IFF身份交换用于 验证组证书。2、基于签名程序的挑战应答：客户端和服务器需要共享一个秘密，称为组密钥，生成 挑战应

10、答程序验证应答，与私有证书机制相似，如果几个客户端使用相同的组密钥，则其中 一个客户端可向其他客户端伪装成服务器。可信代理生成GQ参数，以安全的方式将它们传送给所有的组成员。每个成员生成GQ 公/私钥对和扩展域中带有公钥的证书。GQ身份交换用于验证组证书。3、基于加密程序的挑战应答：这个加密程序用于加密广播，这样数据可以使用几个密 钥进行解密（不同的客户端的密钥吗？好神奇。）方便单独的密钥可以被增加或撤销。步 骤：客户端发送随机值给服务器。这个值被服务器加密发送给客户端。客户端解密这个值与 原先值进行比较。用于带有不可信从属客户端的服务器。最后的信任取决于可信代理。可信的代理生成参 数和加密私

11、密钥给服务器组，解密私钥给客户端组。 MV 身份交换用于验证服务器证书 注意客户端用来验证服务器的参数需要预先以安全的方式分发好。3.3.4 签名保证源认证和消息完整性客户端得到了服务器签名公钥，在随后的消息交换中，就要使用签名来保证扩展域的完 整性和源认证。在需要身份认证时，保护了扩展域的完整性。在随后的 cookie 分发中，数 据包中的每个扩展域由服务器签名私钥签名，同时保证了源认证和扩展域的完整性。证书有 生存期，默认为1 年，到期必须重要生成。3.3.5 时间戳抵抗消耗资源的重放攻击1）签名时间尽管公钥签名保证了服务器的源认证，但是计算签名需要昂贵的代价。这提供给攻击者 通过重放旧的

12、消息或发送伪造消息来阻塞客户端或服务器的机会。接收到这样消息的客户端 可能被强迫验证其中无效的签名，进而消耗了重要的处理器资源。为了抵抗这样的攻击，每个带签名的扩展域要带一个时间戳。在使用任何值或验证签名 以前，协议先检查时间戳，如果是带有旧的或重复的时间戳或者伪造的时间戳，协议就丢弃 这个扩展域。如果系统时钟要与一个可信的源进行同步，就会产生一个签名并携带一个有效的非 0时间戳。否则，不会进行签名，时间戳为0视为无效。（RFC 5906）只有当密码算法的值被创建或被修改时，才进行签名计算。携带这些签名的扩展域按需 要复制到消息中，但是不重新计算签名，有三种签名形式：（1）Cookie签名时间

13、戳。服务器创建cookie并发送给客户端时，对cookie进行签名并 加上时间戳（2）autokey签名时间戳。当创建密钥列表时对autokey值进行签名，并加上时间戳。（3）公共值签名时间戳。在系统时钟第一次与可信源进行同步需要协商公共值（公钥， 证书和闰秒值），在生成这些公共值或者这些公共值发生变化时，要对它们进行签名。另外 此后大约每天一次，即使这此值没有发生变化，也要对它们进行签名加上时间戳。每个类型接收到的最近的时间戳要被保存下来用于比较。一旦收到了一个带有有效时间 戳的签名，那些同类型的且携带无效的时间戳或更早有效的时间戳的消息就要在验证签名之 前被丢弃。这在广播模式中最重要，广播

14、模式容易遭受阻塞攻击。2）更新密码媒介时的文件戳协议使用的所有密码值是时间敏感性的，需要定期更新。特别的，签名和加密算法使用 的包含密码值的文件需要重新生成。每个文件都与一个文件戳相关联，目的是为了让文件重 新生成时不需要特别地提前警告也不需要提前分配文件内容。尽管加密数据文件没有特殊的 签名。保证文件戳是可信数据是很重要的，所以除非生成者与一个可信源同步，否则文件戳不 能被生成。同样地，NTP子网中的文件戳代表一个局部的所有文件创建的顺序，用于删除 旧的数据，保证新的数据是一致的。数据由服务器向客户端传送时，要保存文件戳，包括那 些证书和闰秒值的。带有旧的文件戳的数据包在验证签名前被丢弃文件

15、戳与时间戳可以以任何组合进行比较，使用相同的约定。有时比较它们来确定哪个 更早或更晚很必要。由于这些值以秒为粒度，所以如果这些值是在相同的秒位时，这样的比 较是模糊的。3）更新时间戳的条件更新时间戳需要满足以下条件：1、消息类型和关联 ID 与客户端关联值相匹配。这是为了防止中间人复制这个扩展域 给另一个客户端。2、时间戳比媒质时间戳要晚。防止中间人重放一个早期的扩展域。3、文件戳同媒介文件戳相同或者更晚，为了在更新媒介时强制一个重新活动4、扩展域签名有效时。如果这些标准没有达到，则丢弃这个包。如果一段时间内没有收到有效的数据包，则重 新组建这个联盟，更新媒介变量。如果服务器的时钟向后倒退，则

16、它的扩展域会一直被忽略 直到超时。3.4限制数据包到达率抵抗消耗资源的Dos攻击一个入侵者会发起一个DOS攻击，用于消耗服务器计算资源。比如，他会以高频率地 重放伪造但是有效的 cookie 请求数据包。通过昂贵的主机加密和签名计算来阻塞服务器。 对 DOS 攻击一个有效的防御是参考实现中的到达率管理规定。限制来自任何客户端的数据 包的到达率不超过每2 秒一个数据包，多余的数据包不进行密码计算直接丢弃。3.5基于Autokey模型的NTP协议序列3.5.1 初始关联（1）客户端发送关联请求报文：扩展域类型为关联。报文包含一个32位的状态域和客 户端的对称摘要密钥主机名字。（2）服务器发送关联应

17、答报文：包含一个 32 位的状态域和服务器的对称摘要密钥主机 名字。状态域：32 位状态字，十六进制。包含 X.509 名称（使用哪种证书）和服务器和客户 端使用的加密算法信息。状态字的前4 位用于识别使用的认证机制，由服务器决定使用哪个 认证机制。3.5.2 证书交换得到签名公钥(1) 客户端发送证书请求 客户端选择可用的加密选项，发送证书请求，包含服务器名称 (证书主体名称，也 是初始关联中客户端从服务器收到的主机名称)。服务器发送证书3.5.3 基于挑战应答验证服务器身份(可选)(1) 客户端发送挑战 客户端选择可用的加密选项，发送带有扩展域的请求，扩展域类型分别为 IFF, GQ or

18、 MV。(2) 服务器发送应答 服务器发送相应应答，并进行签名(防止篡改)(3) 客户端进行验证 根据认证机制的不同，客户端利用已经有的公共参数或可信机构的证书，验证服务器的 身份。3.5.4 客户端请求 cookie(1) 客户端发送cookie请求报文。报文包含用于加密的客户端的公共密钥(RSA)。(2) 服务器发送cookie加密报文。服务器利用客户端IP服务器IP, 0值，服务器种子 计算出cookie，用客户端的公钥进行加密，将它放在扩展域中，使用服务器私钥进行签名。Cookie = MSBs32 (H (Client IP| Server IP| 0| Server Seed)(3

19、) 客户端接收 cookie客户端利用服务器公钥验证服务器的签名，使用自己的私钥进行解密得到cookie。客户 端验证了服务器的可靠性并接收到秘密的cookie。注：( 1)服务器种子每天定时更新一次，此时需要重新协商 cookie。(2) 这个交换容易受到攻击。(中间人可以使用它自己的公钥加密密钥发送一个客户端 cookie 请求，见 5(3)(3) 以上几步，虽未得到对称摘要密钥，仍然需要计算MACMAC = H (public value| NTP packet| Extension Field)3.5.5 客户端请求摘要密钥(1)客户端发送摘要密钥请求报文 不需要同步时客户端发送不带签

20、名的 autokey 请求。( 2)服务器发送摘要密钥应答报文服务器生成密钥列表：服务器选择一个随机的32位种子作为初始的密钥ID。初始的摘 要密钥使用给定的地址，cookie和初始的密钥ID进行哈希，存储在密钥cache中。Autokey = H (Sender-IP II Empfanger-IP II KeyIDII Cookie)下一个摘要密钥的生成：使用摘要密钥的前4个字节作为新密钥ID.服务器在扩展域中提供最后的索引号和最后的密钥ID,并进行签名，加上时间戳。3.5.5 客户端请求时间同步客户端获得 cookie 后，就可以在以后的通信中与服务器共享一个对称摘要密钥。客户 端与服务

21、器进行时间同步的NTP数据包就不需要包含扩展域，只需要包含密钥ID和MAC。(1) 客户端发送时间请求报文。客户端每次自行选择密钥ID，与得到的cookie 一起计 算出对称摘要密钥，进而与NTP请求报文一起算出MAC。Autokey = H (Sender-IP II Empfanger-IP II KeylDII Cookie)MAC = H (Autokey | NTP packet)(2) 服务器发送时间响应报文。服务器对客户端数据包的完整性认证，服务器根据客户端的密钥ID和cookie (不记录 客户端的cookie，每次客户端数据包到达时需要重新生成)，计算出对称摘要密钥，验证客 户端数据包中的MAC。将对称摘要密钥与NTP响应报文进行哈希，计算出MAC。Autokey = H (Sender-IP II Empfanger-IP II KeyIDII Cookie)MAC = H (Autokey II NTP packet)(3) 客户端利用密钥 ID 与 cookie 计算出对称摘要密钥，进而验证服务器响应报文中 的MAC。如果计算出的MAC与报文中MAC 一致，就说明这个应答者拥有了共享的cookie， 并且用于计算应答MAC的密钥ID与本次请求报文中的密钥ID 一致。注：使用密钥ID和MAC时，不使用扩展域。当计算相应的对称摘要密钥时，两个IP地址要颠倒。