使用社交账号登陆

当前位置: 主页 > IEEE专区

加密到底应该是什么?

时间: 2015年11月22日 | 作者: admin | 来源: 未知
【作者】 史蒂文· M ·贝洛维( Steven M. Bellovin ) 哥伦比亚大学( Columbia University ) 【正文】 关于密码学,我们只知道一件事:它很难。事实上,它在所有层面上都很困难:无论是原始

【作者】

史蒂文·M·贝洛维(Steven M. Bellovin

哥伦比亚大学(Columbia University

SteveBellovin2013.jpg

【正文】

关于密码学,我们只知道一件事:它很难。事实上,它在所有层面上都很困难:无论是原始的加密原理,加密协议,加密的实现,还是使用规则,都非常非常困难。而如果犯错,就会被攻击者加以利用。很多问题已经在技术社区中引起了广泛的关注。参加国家标准技术研究所加密或哈希算法竞赛的提交必须包含安全分析,要能抵挡已知的攻击类型,例如差分密码分析(differential cryptanalysis)。

设计糟糕的协议必然存在风险。不过,大部分攻击规模不大,这些攻击一般要求大量的截取数据——这本身对很多攻击者来说就是很大的挑战,还需要技术高超的攻击者。然而,有一类问题并没有在可用性(usability)社区外引起多少注意,这类问题就是用户犯下的错误。忽略这个问题后果严重,用户的错误过去和现在都能造成严重的威胁,因为他们可以也会在不知道的情况下发送明文信息。

这并不意味着没有警告。长期以来,密码会因为工作人员产生的信息没有加入足够的空值,或充分使用密码文本的同义替代而被破解。德国在使用二战时期的恩尼格玛密码机时犯了错,帮助了英国的密码破译人员。更近一些,惠滕(Whitten)和泰加尔(Tygar)在经典的《为什么约翰尼加不了密?》(Why Johnny Can’t Encrypt)是一个明确的警告,但是后续的研究要么面向可用性社区(也是这一观点的鼓吹者),要么至少像专注于可用性问题那样专注于协议性问题。这么做是错误的。可用性失败是钓鱼攻击和意外明文邮件的主要技术原因,而且在还时常导致网页公钥基础设施出现问题。

让我们更仔细地研究一下被加密保护的电子邮件:它应该是什么样的?发送者是不是必须要求加密?用户能否在没有密钥的设备上接受信息?如果默认开启加密,用户是否应该有权关闭加密?如果已知某些收信人有能力或无法进行加密,或者不知道收信人是否有这种能力,应该怎么办?怎么区分这几种收信人?我们知道用户并不会留意非常细小的提示,比如一个带锁的图标;我们也知道服务商因为自身的原因很喜欢大幅度改变UI——例如可以比较一下iOS6iOS7——所以提示图标也不管用。

收信人也有相似的问题。他们如何被清楚无疑义地告知某条信息在加密的条件下被接收?如何显示某个数字签名是否存在或缺失?如何显示加密验证的发件人,而不是显示一行“寄件人:”?如果他们有分歧,比如在某些细枝末节上存在分歧应该怎么办?如果加密验证的发件人和“寄件人:”那一栏显示的发件人不符,应该怎么办?如果我们可以在一个晚上升级所有的电子邮件的邮件程序系统,这些问题就会相对简单,但很明显我们没法这么做。

密钥处理本身也存在挑战。我怎么才能安全地决定他人的公共密钥?要怎么做我才不需要担心甚至知道公共密钥?他们如何才能在不理解诸如证书和PKI等重要概念的情况下,获得我的密钥?在现今操作系统糟糕的安全性的状况下,我如何保护自己的私钥?如何处理例外情况,例如密钥吊销?

这些问题全都没有简单的答案。我们甚至还不清楚有些问题是不是会有答案。我们不知道,除非整个安全社区共同关注一个看起来相对简单的问题:加密到底应该是什么?

【作者简介】史蒂文·M·贝洛维(Steven M. Bellovin)是哥伦比亚大学的计算机注册新宝GG教授。他的网页是:https://www.cs.columbia.edu/~smb/