Zoom 的加密算法,到底有什么问题?

用户头像
范学雷
关注
发布于: 2020 年 04 月 26 日
Zoom的加密算法,到底有什么问题?

2020年,庚子年,是一个难以让人淡定的年份,COVID-19给人类带来了巨大的灾难和困惑。



灾难和困惑本身就是最真实的市场需求。谁能够减缓或者解决灾难带来的社会问题,谁就承担了最大的社会责任和使命,并且因此获得市场的青睐。我从来不怀疑,这样的企业和产品总是会存在、会出现、会获得很好的市场机会。在线会议系统就是其中之一,它解决了当下人们居家办公、远程协作的紧急需求,使得部分商业运转得以延续。当然,在线会议系统获得了前所未有的机会和订单。在线会议的市场领先产品是Zoom。



难道Zoom还不安全?

2020年,是Zoom获得巨大发展的一年。2020年,截至4月24日,标普500指数下跌13.40%,Zoom上涨133.39%。



2020年Zoom证券市场表现(图片来源:yahoo财经网站截图)



2020年,也是Zoom陷入舆论漩涡的一年。在2020年4月份开始的4个交易周里,Zoom最大跌幅将近27%,而同期的标普500指数上涨超过8%。直到我开始码字的4月25日,Zoom才大致追平标普500指数涨跌。



2020年4月份Zoom的市场表现(图片来源:yahoo财经网站截图)



2020年4月份,是COVID-19在全球展示威力的一个重要时刻。Zoom本该有超出市场预期的表现,为什么股票跌出了一个大坑?



2020年3月31日,研究者公开了Zoom的重大安全漏洞,认为Zoom并不适用于安全会议。其中最重要的安全问题,是和密码算法和密码管理相关的问题。问题之一,就是Zoom会议系统使用了AES的ECB加密模式。ECB加密模式被普遍认为是一种现实中不能有更坏选择的加密模式。



在 Zoom的网站上,有这样的描述,“保护您的数据:我们使用256-bit TLS加密通讯,并可使用AES-256加密所有共享内容。”



Zoom使用AES-256加密共享内容(图片来源:zoom网站首页2020年4月25日截图)



AES-256使用256比特的加密密钥,这种密钥长度,提供了目前可以预见的足够安全强度。即使到了量子计算时代,AES-256依然是安全的。



可以抵御量子计算算力的AES-256,怎么就会有问题呢?

AES-256还能被破解?

在Zoom的关于加密技术的白皮书里,我们可以看到如下的内容:



Zoom使用ECB加密模式(图片来源:zoom白皮书截图)



从白皮书里,我们看到了研究者关注的安全问题,实时的用户间共享的数据是使用AES-256的ECB加密模式加密的。AES-256的选择没有问题,ECB加密模式的选择简直糟糕透了!



使用AES-256不就够了吗,为什么还要掺和进来加密模式?



一般来说,一个按块加密的算法本身,只能转换,也就是加密或者解密,一个固定长度的数据块。比如AES-256的密钥长度是256个比特,块长度是128个比特,它本身只能转换128个比特的数据。可是实际上,需要使用一个密钥加密任意大小的数据,该数据可能比128比特大,也可能比128比特小。



怎么把快加密本身要求的固定的块长度扩展到支持任意长度的数据呢? 这就需要选择加密模式。ECB就是众多加密模式中,最直接、最简陋、最没有抱负的哪一种。



简单地说,ECB加密模式,把任意长度的数据块分割成加密算法要求的多个数据块,然后对每个数据块独立地进行加密。



ECB加密模式(图片来源Wikipedia)



ECB加密模式怎么了?

Zoom安全漏洞的研究者为什么关注ECB加密模式呢? 我们再来看看ECB模式。理解ECB加密模式,需要把握以下三个关键点:

  1. 把任意长度的数据分成多个固定大小的数据块;

  2. 对每个数据块独立进行加解密。

  3. 数据块相同,加密后密文也相同。



假设有如下一段数据:

ABCDEFGHHIJKLMNO0123456789012345



使用AES-256/ECB算法加密时,这段数据需要分成如下两个数据块:

ABCDEFGHHIJKLMNO

0123456789012345



加密这段数据,得到的密文(密钥"1234567890123456789012")是(十六进制表示):

e3aa32e6e1dfdb1753840823c504be39ced6ecb29d5f103d5110f337511f485b



把密文按照块大小分成连段:

e3aa32e6e1dfdb1753840823c504be39
ced6ecb29d5f103d5110f337511f485b



根据ECB加密模式的特点,我们知道第一行密文对应的数据是“ABCDEFGHHIJKLMNO”,第二行密文对应的数据是“0123456789012345”。



所以,如果知道数据块对应的密文,通过寻找重复的密文,即使没有解密操作,我们也能知道对应的数据块。



比如下面的密文:

ced6ecb29d5f103d5110f337511f485be3aa32e6e1dfdb1753840823c504be39



即使不解密,我们也知道对应的数据块是:

0123456789012345ABCDEFGHHIJKLMNO



你可能会有疑问,数据都是加密的,攻击者怎么会事先知道数据块和对应的密文呢?其实,互联网世界里,已知重复的、位置确定的数据非常多,HTTP的头部数据,HTTPS数据包的头部,URL等都是重复频率很高的数据。通过定位数据块,锚定对应的密文,就可以利用已知的数据块和密文寻找、推断未知数据了。



所以,如果使用了ECB,AES-256的理论安全强度就没有现实的意义。因为,攻击者根本不需要通过蛮干的办法去解AES-256设置的问题。



由于ECB加密模式的这个天然的缺陷,应用程序是不应该直接使用这样的加密算法。

ECB加密模式有用吗?

既然应用程序不应该直接使用ECB加密模式,为什么安全应用程序接口还要提供ECB的编程接口呢?这主要是因为,ECB加密模式是块加密算法的基础。块加密算法的基础,就是转换一个固定长度的数据块。可以把它看作是单个数据块的ECB加密。



有密码学专业知识的算法工程师,可以通过合理地使用ECB模式,来构造更复杂、更安全的算法。

AES-256算法安全吗?

如果现在我再问你这样的问题:AES-256算法安全吗?你可能会稍有犹疑,因为你已经知道,至少如果AES-256使用ECB模式,这个算法是不安全的。



我经常可以看到、听到很多论断,诸如使用了128位的AES算法保护数据、或者使用了256位的AES算法保护数据。如果没有进一步的信息,我们很难知道这样的保护机制是不是真的安全、有效。万一使用了ECB模式呢?

GCM就万无一失了吗?

在Zoom的关于加密技术的白皮书里提到,很快会升级到GCM模式。那么,我们是不是可以认为这样的保护机制就是安全、有效的呢?



保护您的数据

我们使用256-bit TLS加密通讯,并可使用AES-256 GCM加密所有共享内容。”



遗憾的是,我们依然没有充分的信息来判断这样的保护机制是不是真的安全、有效。 原则上是的,但是现实中也会出现很多问题。



希望有机会,我们可以聊聊GCM模式,以及GCM模式潜在的安全问题。



密码学是一个水很深的领域,到处充满了暗礁。对于一个涉水年头较少的团队,稍不留神,就有触礁翻船的危险。幸运的是,对于Zoom而言,这些问题发现的并不算晚,而且Zoom正全力以赴地解决掉这些安全问题。



密码学家给的建议是:永远不要自己设计密码算法、永远不要自己实现密码算法。;-) 是不是密码学家给自己深挖的护城河?

发布于: 2020 年 04 月 26 日 阅读数: 2198
用户头像

范学雷

关注

因为慢,所以快。 2018.04.29 加入

制订和维护Java安全规范。

评论 (2 条评论)

发布
用户头像
老范已经被 InfoQ 首页推荐了,要抓紧多写一些内容啊
2020 年 04 月 29 日 18:08
回复
正在琢磨些系列,让自己静下来想想,顺便让更多人认识了解Java和基础安全知识。就是时间不常站在我这一边。 另外,写作平台太棒了。
2020 年 04 月 30 日 00:30
回复
没有更多了
Zoom的加密算法,到底有什么问题?