连接千万条 安全第一条 加密不认证 亲人两行泪

AES-CBC安全问题详解

​ 保护互联⽹连接安全的TLS⼜双叒叕出事了,本次的漏洞由Tripware的安全研究员Craig Young发现 [1],由于攻击方式类似2014年的POODLE漏洞,此次的两个新漏洞被命名为“Zombie POODLE”和“GOLDENPOODLE”,它们都影响目前广泛流行的TLS协议1.2版本,并允许攻击者破解使用AES-CBC加密的Web和VPN连接。

​ 安全实验室出品的MesaLink TLS项目在设计伊始即摒弃AES-CBC,采用目前最安全的AEAD认证加密技术保护密文的完整性,使得MesaLink不受POODLE及其各种变体影响。2018年8月发布0.7.0以来,MesaLink在智能电视、智能音箱、智能车载等项目中得到了广泛的测试和部署,月活跃用户过千万,稳定性和安全性都经受住了实战的考验。一周前我们发布的MesaLink 0.8.0版本包含了大量新API新特性,为AI时代的安全数据传输提供保障。

​ 在本篇文章中,我们深入探寻POODLE漏洞的来龙去脉。百度安全实验室提醒您:连接千万条,安全第⼀条;加密不认证,亲⼈两⾏泪。

baidu_bannerAES分组加密算法及其CBC模式

​ 故事要从AES说起。AES,全名Advanced Encryption Standard,即高级加密标准,是一个广泛使用的分组加密算法(block cipher)。在AES算法中,明文数据被按顺序分组拆成若干个16字节的明文数据块,然后用一个定长的密钥对每个明文块单独加密,生成的密文块按顺序拼接起来即为输出的密文,如下图所示 [2]。这种分组的加密模式也被称为电子密码本模式(electronic code book),即AES-ECB。但是AES-ECB有一个重大的缺陷:如果明文中存在若干个相同的明文块,那么它们加密得到的密文块也是相同的,这些相同密文块的顺序和位置也和明文块对应,导致泄漏明文数据一些结构上的信息。

aes_ecb

​ 于是,AES的密文块链接(cipher block chaining, CBC)模式应运而生。为了解决ECB模式的问题,CBC模式引入了两处改变:一是加入了随机的初始化向量(Initialization Vector, IV),二是每个明文块需要和前一个密文块(第一个明文块使用IV)进行异或操作后再进行AES加密,如下图所示 [2]。这样,明文或IV中的任何微小变化都会导致之后的所有密文块发生改变。AES-CBC是一个很流行的组合,TLS 1.2标准强制要求所有的TLS 1.2的实现必须支持使用128-bit密钥的AES-128-CBC。

aes_cbc

​ 细心的读者可能会发现一个问题:AES的分组大小是16个字节,那么如果明文长度不是16字节的整数倍,最后一个分组需要补足16字节么?答案是肯定的,甚至明文长度已经是16倍数的情况下也要再填充16字节以保证数据的结尾总是存在填充字节。AES-CBC填充字节(padding)的格式遵循PKCS #7标准:明文在加密前必须填充1~16个相同字节使总长度是16的整数倍,字节的值等于需要填充的长度减1。举个栗子:如果需要填充1个字节,那么则填充0x00;如果需要填充2个字节,则填充0x01, 0x01;3个字节则填充0x02, 0x02, 0x02;以此类推,最多填充16个字节的0x0F。但是SSLv3会话解密AES-CBC密文块后仅检查解密结果的最后一个字节用于计算填充字节长度,而没有检查所有填充字节的完整性。这给攻击者留下了篡改填充字节的机会,并引发了POODLE漏洞等一系列问题。

baidu_banner使用Padding Oracle攻击AES-CBC

​ 接下来我们分析AES-CBC是如何沦陷的。我们使用如下的威胁模型:客户端和服务器存在SSLv3会话,攻击者作为中间人知晓IV和所有的密文块,且攻击者可以从客户端测向服务器发起握手请求并观测服务器的行为,攻击者试图还原客户端发送的明文信息。

我们看下AES-CBC的解密过程,如下图 [2],密文块在用密钥解密后还要和前一个密文块异或后才能得到明文块,即,其中。对于攻击者来说,IV和所有的密文块都是已知的。假设攻击者想获取明文块,则需要知道的值和的值,前者未知,但是后者是已知的。于是问题从获取转化为获取

aes_cbc_dec

下面我们分析如何获取。上一段结尾我们讨论到,SSLv3会话没有检查填充字节的完整性。我们知道0x00是一个合法的填充值,而且只有一个字节长。如果攻击者操纵篡改密文块的最后一个字节(设为),并和密文块一并发给服务器解密,那么解密得到的明文块结尾有两种可能:

  1. 服务器报告填充字节非法:表明结尾不是合法的填充字节,发生概率255/256;
  2. 服务器不报错或报其他错误:表明的最后一个字节是0x00,发生概率1/256。

第二种情况一旦发生,意味着 ,很容易反推出0x00。攻击者最多猜256次既可以获取的最后一个字节。对于倒数第二个字节,攻击者可以继续操纵的最后两个字节使得解密结果的结尾是0x01,0x01这个同样合法的填充值,以此类推可以解出的每一个字节,继而获得明文。类似的攻击思路也可以在CBC字节翻转(CBC bit flipping)攻击中见到。

​ 我们回顾一下AES-CBC是怎样沦陷的。首先服务器端在解密时没有对密文做完整性检查,使得攻击者可以伪造大量的密文发给服务端解密,这构成了选择密文攻击(Chosen ciphertext attack)。其次,服务器相当于一个对填充字节(Padding)合法性作判断的“预言家”(Oracle),服务器返回的不同的错误信息为攻击者提供了额外的信息,构成了padding oracle攻击。综上,AES-CBC模式本没有错,是TLS协议中对AES-CBC的不当应用使得攻击成为了可能。

baidu_bannerPOODLE及其变种

​ POODLE即CVE-2014-3566,全名“Padding Oracle On Downgraded Legacy Encryption”,是2014年发现的一个针对SSLv3的padding oracle攻击。攻击者作为中间人欺骗服务器降级TLS协议版本到受影响的SSLv3,然后使用前一章节的选择密文攻击技术破解AES-CBC加密的数据。防范POODLE攻击的一个主要手段是防止中间人降级TLS版本:客户端给服务器发送的握手信息中需要明确指定一个最低的TLS版本,例如TLS 1.0,服务器一旦发现有试图降级到TLS 1.0以下的请求即放弃握手。防止降级并没有从根本上解决padding oracle的问题。2014年末,POODLE的新变种CVE-2014-8730被发现。该漏洞影响TLS 1.0~1.2的一些实现,这些实现由于对填充字节检查方式的错误实现使得padding oracle依然可行。

​ Padding oracle的玩法并不止步于填充字节的格式上,时间也是可行的Oracle来源,Lucky 13便是这样一种攻击。在Lucky 13攻击中,攻击者依然试图操纵密文块使得解密结果最后一个字节是0x01,与POODLE不同的是,攻击者通过观察HMAC计算的微小时间差异(timing oracle)来判断解密结果是否以0x01结尾 [3]。为了防御此类使用timing oracle的攻击,需要常数时间(constant time)的密码原语,然而这类原语的实现极为困难。

​ 虽然“Zombie POODLE”和“GOLDENPOODLE”的技术细节还没有完全发布,我们有理由相信它们是五年前POODLE漏洞的还魂。正如作者Craig Young所说,“这只是一个微小的变化 (a very slight tweak to the underlying oracle)”。AES-CBC的硬伤从来没有真正彻底地解决。

baidu_banner认证加密技术的崛起

​ AES-CBC的问题之一在于分组密码需要的填充字节。为了更好的安全性,TLS的1.2版本开始支持基于流密码和消息认证码的认证加密(Authenticated Encryption with Associated Data, AEAD)技术,并在TLS 1.3中完全替代了AES-CBC。流密码(stream cipher)不受分组限制,可以加密任意长度的数据而不需要填充字节;新的消息认证码和解密过程深度结合,能够在解密过程中检测密文是否被篡改,从而保证密文的完整性。双管齐下,彻底根除AES-CBC的问题。目前常见的AEAD认证加密算法有AES-GCM和Chacha20Poly1305,在国内外社区的推动下,AES-CBC的连接量逐年下降,AEAD已经成为TLS连接的主流加密方式 [4]。

baidu_banner结语

​ TLS安全技术的升级换代是一项覆盖整个互联网的复杂工程,需要包括智能终端厂商、网络服务运营商在内整个社区的通力合作。百度的OASES智能终端安全生态联盟携手多方力量,用开放的技术让智能终端生态更安全。

参考文献: [1] Introducing Zombie POODLE and GOLDENDOODLE, https://www.tripwire.com/state-of-security/vulnerability-management/zombie-poodle-goldendoodle/

[2] Block cipher mode of operation, https://en.wikipedia.org/wiki/Block_cipher_mode_of_operation

[3] Timing vulnerabilities with CBC-mode symmetric decryption using padding, https://docs.microsoft.com/zh-cn/dotnet/standard/security/vulnerabilities-cbc-mode

[4] Padding oracles and the decline of CBC-mode cipher suites, https://blog.cloudflare.com/padding-oracles-and-the-decline-of-cbc-mode-ciphersuites/

bottom_qr

Published by in general and tagged aes-cbc and mesalink using 152 words.

comments powered by Disqus