文档结构  
翻译进度:已翻译     翻译赏金:0 元 (?)    ¥ 我要打赏

人们说历史总是在不断地重复自身,首先是悲剧,然后是闹剧。这个道理除了在华盛顿邮报记者Ellen Nakashima和Barton Gellman的这篇文章之外从来没有这么明显过:“随着加密的传播,美国在和隐私与安全之间的冲突努力斗争”。

这篇文章的主题是美国情报和执法机构再次努力在现代加密系统强制委托“后门”,这从表面上看是对智能手机大规模的采用强加密,警察将失去他们一直依赖的监听的能力的必要担忧所作出的反应。

第 1 段(可获 1.25 积分)

这已经不是我们第一次面对这种情况了。早在上世纪90年代,联邦政府就给 “托管”电话加密提出了一个称为“Clipper”芯片的国家标准。这一努力的失败很大程度上是因为这项技术太糟糕了,但也是由于——至少在当时来说 ——普通市民采用端-到-端加密的想法基本上只在科幻小说里会出现。

归功于智能手机的出现和在像苹果的iMessageWhatsApp这样热门的系统上的“默认(on-by-default)”加密,美国人终于在大范围上使用端-到-端加密,而且似乎都很喜欢它。这使当权者都大吃一惊。

第 2 段(可获 1.38 积分)

因此有了加密的后门。

你可能已经猜到了,我对在任何加密系统添加后门持有严重的哲学上的反对意见——因为有很好的理由,我可以写几千字来阐述它。但是我不准备做这件事。我在这篇文章里面想要做的,是放下我自己的价值判断,尝试在表面上采取政府的这些建议。

因此我想要在这篇文章中考虑的问题是

让我们假装加密后门是一个很好的想法。从纯技术的角度来看,我们需要做什么来实现它们,以及可实现的程度有多大?

第 3 段(可获 1.36 积分)

先介绍一下背景。

端-到-端加密系统101

现代加密模式可以分成几个类别。为了展开我们的讨论,我们会考虑把加密模式分为两种模式:一种是提供者持有密钥的系统,一种是提供者不持有密钥的系统。

我们对于包括了像SSL/TLS和谷歌Hangouts这样的协议的第一类加密系统并不是很感兴趣,因为这些系统只是在数据到达提供者的服务器前的数据链路层保护了数据。我想,相当容易确定的是,如果Facebook、Apple、Google或者Yahoo可以访问你的数据,那么政府也同样可以访问它们——只需要传唤或强制这些公司参与合作就可以了。我们甚至已经见识过如何操作了。

第 4 段(可获 1.55 积分)

我们感兴趣的所有加密系统都属于第二类——使用甚至提供者都不能解密你的信息的协议。这种系统包括有:

这看起来是一个很短的应用列表,但实际上我们谈论到了非常多的数据。单是iMessage和WhatsApp系统每天就会处理数十亿条的即时信息,苹果的设备加密对于每个使用最近(ly更新)的手机的人来说默认是开启的

第 5 段(可获 1.49 积分)

如何破解端-到-端加密系统

如果你决定通过合法的方法打击端-到-端加密系统,有相对较少的一些方法来处理。

到目前为止,最简单的方式就是完全禁止端-到-端解密,或者强制采用加密。这在之前有个先例:在整个上世纪90年代,NSA强制美国公司把“贸易”等级的加密,在用于商业用途时足够好,但是对于政府的攻击足够弱。这个策略的问题是,攻击会变得更强,但传统的加密却不会消失

幸运的是,针对这个讨论,我们要用到一些参数。其中一个参数是,华盛顿似乎真的想避免对硅谷口述技术设计。更重要的是,奥巴马总统自己说过:“在任何情况下,我们都希望加密是足够强大的”。这个声明在表面上应该意味着我们可以排除彻底的加密禁止、强制设计和任何从根本上会弱化对外部攻击者的防御的加密修改。

如果我们把这一切混合在一起,我们真正的选择只有两个:

第 6 段(可获 2.39 积分)
  1. 攻击密钥分发。在依赖集中式系统,提供者产生密钥的服务器中,例如WhatsApp、Facetime、Signal 和iMessage,政府可以强制提供者分发不合法的密钥,或者登记影子设备到用户的账户中。这本质上是一种对于加密通信系统的中间人攻击。
  2. 密钥托管。这个方法是说,任何加密方案都可以被修改来加密一个解密(或者会话session)密钥的复制,这样,一个“主密钥持有人”(例如苹果或者美国政府)仍然可以解密。这样的一个主要优点是,即使对于没有可收买的密钥服务器的设备加密系统,这种方法依然有效。

 

第 7 段(可获 1.28 积分)

每个方法都需要对客户端、服务器或者系统里的其他组件做一些修改。

攻击密钥分发

对Apple iMessage发出的查找密钥Key请求。电话号码出现在右上方,响应在左下方。

许多端-到-端信息加密系统,包括WhatsApp和iMessage,都为你所拥有的每一个设备生成一个长期的公钥和私钥密钥对。密钥对的公共部分被分发到每个想要发送信息给你的人的设备上,而私钥永远不会离开设备。

在你可以启动和你的预期收件人之间的连接之前,你首先要获取收件人的公钥的一个复制。这通常是使用由提供者操作的一个密钥服务器来处理的。 密钥服务器可能会返回一个或多个公钥(取决于收件人注册了的设备有多少个)。只要这些密钥全部都合法地属于你的预期收件人,一切就能正常工作。

第 8 段(可获 1.91 积分)

然而,拦截信息是可能的,如果提供者愿意把他们的公钥替代成——提供者(或者政府)实际上知道私钥的公钥。 在理论上,这是比较简单的——在实践上,这是有点麻烦的,由于像iMessage这样的协议具有高度的复杂性。

密钥指纹

攻击密钥分发的主要问题是——和传统的窃听不同——替换密钥至少在理论上是可以被攻击目标检测出来的。 一些通信系统,例如Signal,允许用户比对密钥指纹,以验证每个接收到的公钥的正确性。其他的应用,例如iMessage和WhatsApp,没有提供这项技术——但是做一些简单的修改就能够实现同样的功能(甚至是使用第三方客户端就可以) 。像CONIKS这样的系统甚至在将来甚至可以自动化这项流程——允许应用实时监控服务器分发的自己独有的密钥的变化。

第 9 段(可获 1.99 积分)

攻击密钥分发方法最后一个显著的特征是,它只允许前瞻性 窃听——这也就是说,执法必须先指定一个特定用户为目标, 只有这样他们才能窃听她的连接,没有办法在时间上向后看。 我认为这通常来说是一件好事。其他人可能不同意。

密钥托管 

剪刀(Clipper)“LEAF”的结构

上述技术对于没有密钥服务器的系统来说,起不到多大的作用,此外,对于完全不使用公钥的系统,以设备加密为典型例子,它们什么也不做。在这种情况下,唯一的选择就是委托某种形式的密钥托管

第 10 段(可获 1.4 积分)

抽象地说,托管系统的目的是把解密密钥放到受信任机构的文件上(“托管”它们),这些机构能够在有需要的时候把密钥分解出来。在实践上,这通常会有一点复杂。

第一个窍门是现代加密系统通常以拥有许多 解密密钥为特征,这些密钥中的其中一些可以在系统运行时动态获得。(例如TextSecure/WhatsApp这样的系统实际上为几乎你发出的每条信息都生成一个新的加密密钥。)使用被加密设备的用户可以不时地修改他们的密码。

为了处理这个问题,一个更可取的方法是把这些会话密钥根据托管权威机构生成的主公钥 包裹起来(加密它们)——连同其余的加密数据一起存储/发送结果密文。在上世纪90年代的Clipper规范中,这些密文被称为执法访问字段(Law Enforcement Access Field),或LEAF。***

第 11 段(可获 1.88 积分)

在你的协议中增加了LEAF,窃听变得相对直接很多。执法只需要截取加密数据——或者从你没收的设备里面获取加密数据——提取出LEAF,并请求这个托管的机构解密LEAF。追溯到PGP时代,你可以发现很多这个设计的变体。实际上,整个概念看起来是很简单的——这让即使是没有任何使用背景的人也可以理解它。

包括一些加密信息(左边)和一个LEAF(右边)的概念视图。

只有当你需要注意实际实现密钥托管的细节时,情况才变得复杂。这些计划要求你在相当基础的层面上更改加密系统中的每个协议——这个过程会孕育出所有的安全漏洞的基础——但,更重要的是,这些计划强迫你去认真考虑谁是值得托付这些托管密钥的。

第 12 段(可获 1.81 积分)

谁实际上持有密钥?

这对于任何托管平台都是一个价值很高的问题。各邮报都投入了很多精力去探索回答这个问题的各种建议。

托管密钥管理是不成则败(make-or-break)的,由于密钥服务器代表了任何托管通信系统的通用漏洞。在目前的辩论中,似乎在台面上有两个解决方案。第一个方案是将问题转给每个提供者,提供者自己将负责管理他们的托管密钥——使用任何他们认为合适的技术手段。一些公司会得到这个权利。不幸的是,大多数公司在密码学上的技术都很烂,所以可以很有理由相信,由此产生的系统将是相当脆弱的。

第 13 段(可获 1.43 积分)

第二个方案是由政府保管这些密钥。由于托管密钥对于任一机构来说都太过重大,一个或者多个可信的美国政府部门应该持有主密钥的“一份(share)” ,基于不同个案,这些政府部门应该合作提供解密。这实际上就是曾为Clipper芯片提出的方案。

这个提议的主要问题是,它的实现非常困难。如果你要将密钥拆分出来,给多个机构,你必须考虑要怎样存储这些密钥,还有当你需要访问某人的密钥的时候如何去恢复出这些密钥。最明显的方法是——在某个集中的地方合并这些密钥的部份(share)——这看起来很危险,因为合并出的主密钥在这时是最容易受攻击的。 

第 14 段(可获 1.74 积分)

一种替代方案是使用阈值加密系统。阈值加密是指一套在多个地点存储密钥的技术, 这使即使不合并密钥的各部分(share)仍然可以解密。 这似乎是一个理想的解决方案,只有一个问题:没有人在这种规模部署过带阈值加密系统。实际上,许多在这个领域里我们所知道的协议都从来没有在研究文献外被实现过。此外, 这将要求各国政府为高科技公司的实施精确地指定一套协议——这似乎违背了起初让技术人员自己设计自己的系统的目标。

第 15 段(可获 1.4 积分)

软件实现

要记住的最后一个问题是,我们需要使这一切发生的软件的复杂度。 我们的加密软件已经是如此复杂,以致于它已经发展到了极限。(如果你不相信我,可以看看OpenSSL去年的安全警告)虽然添加托管机制似乎相对简单直接,但它将需要相当仔细的编码,这是我们不擅长的。

即使我们真的继续推进这个计划,还是有有许多悬而未决的问题。这些软件实现能部署在多宽的范围?是否每个应用程序制造商都将被迫使用托管?我们是否会被要求提供一套新的在iOS、Windows和Android系统的API,以便我们可以得到这个权利? 回答这些问题将导致整个操作系统软件技术栈的戏剧性变化。可怜的开发人员必须要回答这些问题。

第 16 段(可获 2.06 积分)

我们怎么强迫人们使用密钥托管?

撇开技术问题,真正棘手的问题是:你怎么强迫任何人来这个东西?托管需要在加密协议上做突破性的改变;它的花费巨大;它引入了许多新的安全问题。此外,法律取缔端-到-端的加密软件似乎注定要违反宪法第一修正案

我不是一个律师,所以不要把我的推断看得太严重——任何潜在的立法将针对服务提供商 而不是软件供应商或开源软件开发人员,但对我来说似乎是很直观的。因此授权密钥托管的真正作用将只能应用于全球性的facebook和苹果。你的第三方PGP和OTR客户会被隔离出来,因为使用这些工具的人只占很小的比例。

第 17 段(可获 1.71 积分)

不幸的是,在现在,即使是小应用程序的开发人员也越来越多地在运行自己的后端服务器(例如,耳语系统(Whisper Systems)和沉默圈(Silent Circle)),所以这个提案并没有听起来的那么让人安心。也许加密应用程序开发人员的最大收获是,很有必要考虑一下,怎样在一个不再能运行自己的后端数据传输设备的世界发挥自己的作用——在这个世界里,其他商业服务可能不会友好到为你移动你的数据。

总结

如果这篇文章比起回答提出了更多的问题,那是因为目前真的不能回答这些问题。一个严肃的讨论正发生在几乎没有技术输入,至少没有不属于情报机构的技术人员,的环境下。

第 18 段(可获 1.66 积分)

也许这本身就是持怀疑态度的足够的理由。

注意:

* 我并不是认可这种加密。我在电报的加密协议上有很多想法,但是它们超出了本文的范围。

** 电报不在这个列表里面,因为他们的协议根本不能处理长期密钥。每一个连接都必须使用一个图形化的密钥指纹亲自被验证,这说实在的,非常的糟糕

***  Clipper芯片使用对称加密算法加密LEAF,这意味着 LEAF解密密钥必须配备在每一个消费设备上。这是很难对付的部分,肯定是一颗被逃避了的子弹。(之前的讨论都跳过/省略了这个很难的部分)这也意味着每一个Clipper必须使用防篡改芯片制造技术在硬件中实现。这是一个真正可怕的设计。

第 19 段(可获 1.63 积分)

文章评论