【择善】一种针对TLS实现的时间侧信道攻击

 

关键词：TLS、s2n、Lucky 13 攻击

本周研读的论文发表于2016 年EUROCRYPT 会议上

标题为：“Lucky Microseconds:
A Timing Attack on Amazon’s s2n Implementation of TLS”

论文作者是Martin Albrecht 和Kenneth Paterson。TLS 是一套网络安全协议，用于在通信双方之间建立安全信道，即提供通信内容的机密性与完整性。它由TLS 握手协议和TLS 记录协议两个部分组成，其中前者用于确定密码套件、认证身份、协商会话密钥等，后者用于安全地传输应用层数据。s2n是由Amazon 于2015 年6 月发布的TLS 协议实现，仅包含约6000 行C99 代码(OpenSSL 的TLS 协议实现包含大约70000 行代码)。该实现针对2013年提出的Lucky 13 攻击[1] 进行了防御。Lucky 13 攻击是一种针对TLS 记录协议的时间侧信道攻击方法，要求TLS 记录协议采用MEE(MAC-Encode-Encrypt) 范式及分组密码的CBC(Cipher Block Chaining) 操作模式。这是目前TLS 协议的主流使用方式，即先对消息应用HMAC 算法，然后将消息、MAC 值串联并填充到(分组密码中) 分组大小的整数倍，最后使用CBC 操作模式对填充后的明文加密。通过更改密文最后一个字节的内容，可以影响解密者对填充长度的判断，从而改变验证时输入到HMAC 算法的消息长度。由于不同长度的消息在HMAC 中的迭代次数不同，因此会导致不同的验证时间，攻击者通过这一时间差别可以确定明文最后一个字节的内容，进而完全恢复明文。

针对Lucky 13 攻击，s2n 采用了两种防御措施。首先，在验证MAC 值时额外调用一次s2n_hmac_update 函数，使得在HMAC 中的迭代次数独立于消息长度和填充长度。其次，在验证失败后，分别调用sleep 和usleep 函数，使得攻击者获得反馈的时间具有随机性。

这篇论文指出上述防御措施并未取得预期的效果。对于第一种防御措施，作者提出了Lucky 13 攻击的一种简单变体。由于额外调用的s2n_hmac_update函数受HMAC 算法内部缓冲区及填充长度影响，因此攻击者可以通过构造短消息使得这次额外的调用没有实际执行，即HMAC 中的迭代次数仍然与消息长度成正比。该攻击方法将密文分为两类，首先确定密文属于哪一类，然后进一步分析具体的明文。对于第二种防御措施，作者分别对sleep 和usleep 函数造成的时延进行了统计分析。由于sleep 函数产生的时延较长，因此实践中常以0 作为参数调用该函数，作者指出可以忽略响应时间大于1 秒的情况来消除sleep 函数参数带来的随机性。实验表明，调用sleep(0) 产生的时延是稳定的，可以较为容易地被消除。相对而言，调用usleep 函数产生的时延较难刻画，然而实验表明，(Lucky 13 攻击定义的) 密文的每一类中分布几乎相同，且两类之间的KL(Kullback-Leibler) 距离差异较大，因此攻击者较容易区分密文究竟属于哪一类。

这篇论文，作者通过大约28000 个TLS 会话完成了区分。
作者指出使用nanonsleep 函数来产生随机时延可以抵抗这篇论文提出的统计分析方法，从而增强第二种防御措施。在第二种防御措施有效的前提下，针对第一种防御措施的攻击本身并不会危害s2n 的安全性。使用更为先进的AEAD(Authenticated Encryption with Associated Data) 加密算法，而非MEE 范式，也能抵抗这篇论文的攻击。我们应该谨记，安全地实现一个密码学协议是极为困难的，需要加倍的小心与努力。

参考文献：[1] N. Fardan and K. Paterson, “Lucky Thirteen: Breaking the TLS and DTLS Record Protocols,” in Proc. of S&P, 2013.

作者：石头

排版：玖玖

审稿：王博