变聪明之后的后果是无法预料的。
——Christopher Strachey
即便有对正义的管理，事物的秘密性也总在减弱。
——Lord Acton
3.1 引言
如果对于安全工程而言有一个深层次的统一主题的话，那就是对安全协议的研究。前面已经非正式地接触了一些协议——比如“质询-应答”身份验证与Kerberos。本章将深入讨论协议的一些细节。这里并不以安全协议的形式化定义开始，而是给出粗略的描述，之后通过一些示例来逐渐精化和细化。由于本书是一本工程书籍，所以还会给出一些关于协议失败的示例。
典型的安全系统通常是由很多主体构成的，比如人、公司、计算机和磁卡机，这些主体相互之间通过各种信道进行通信，比如电话、电子邮件、无线电、红外线以及银行卡和车票等可以携带并传输数据的物理设备。安全协议是对这些通信进行管理的规则，其典型的设计目标是使得系统可以在恶意攻击中“生存”，这些攻击包括电话诈骗或者造假者修改火车票数据等。如果要防御所有可能攻击，代价通常过于昂贵，因此，协议一般都是基于某些威胁假设进行设计。比如，登录协议的实现中包含了一个输入密码的用户，这里的假设是用户总是会在正确的计算机上进行密码输入。在过去那种由硬件缆线连接的终端构成的工作环境中，这一假设是合乎情理的，而现今，人们通过Internet来登录Web站点，这一假设就不能完全符合实际情况。对协议进行评估时，必须回答两个问题：第一，威胁模型是否能准确反映实际情况？第二，协议是否可以处理这些威胁？
协议可以是极其简单的，比如，要进入某建筑物，就需要先在门禁系统上刷卡以识别身份。协议通常包含交互过程，但并不一定包含密码学等技术措施。比如，在餐馆内订一瓶名酒时，标准的卖酒侍者协议会提供一些隐私保护(同桌的其他就餐者不会知道具体价格)，也提供了一些完整性保护(我们可以确认自己拿到的确实是一瓶名酒，而不是掉包的或是与其他廉价酒勾兑而成的)，还可以提供抗否认机制(就餐者在喝完酒之后试图抱怨或拒付是比较困难的)。Blaze给出了其他一些实例，这些实例涉及到多种不同的应用，比如监票、航空安全与投票等[185]。
就技术层面而言，协议可能要复杂很多。全球的银行卡支付系统中使用了数十种协议，这些协议规定了客户如何与提款机以及零售终端进行交互、提款机或终端如何与其赖以运营的银行进行交互、银行如何与网络运营商通信、银行之间如何转账、如何在多种卡与机器之间建立加密密钥，以及可以传送哪种报警消息(比如吞卡指令)等，这些协议必须在大型复杂系统中协作运行。
通常，貌似无害的功能设计可能会隐含严重缺陷，比如，很多银行使用只有中央计算机和提款机知道的密钥对客户的PIN进行加密，同时把它写到卡的磁条上，此功能的目的是让提款机在本地识别PIN，甚至在提款机脱机时仍然能提供有限的服务。这套系统很多年内平安无事，然而，一名程序员(从事建筑物访问控制系统的读卡器研发)发现，他把妻子的银行账号替换成自己的，就可以改变自己银行卡的磁条。之后，他可以使用修改过的卡和自己的PIN从妻子的账户提款。他意识到这个方法可以从任意银行账户中窃取钱财，并在数年内偷窃了几十万的资金。受这一漏洞影响的银行不得不耗费数百万的资金来修改自己的系统，而有些安全升级可能需要数年的时间才能完成。撰写本书时，多数欧洲银行已经从使用磁卡转为使用智能卡，而美国尚未如此。新旧系统之间必须进行交互，以便欧洲的持卡者可以在美国商店购物，反之亦然。这也给攻击者带来了可乘之机，攻击者在克隆欧洲用户的银行卡后，可以用在其他国家的磁卡机上，因为两个系统的保护机制差别不大。
因此，人们需要系统分析安全协议及其失效的原因。安全协议应用广泛，通常又设计得很差，本书将给出来自不同应用的一些实例。
