《信息安全引论》课件Chapter7

1、第7章 电子邮件安全 电子邮件是网络的杀手级应用之一，电子邮件的安全是网络安全的重要研究内容之一，归结起来电子邮件的主要安全需求包括：认证性与机密性。本章主要研究保证电子邮件机密性和认证性的主要技术手段。具体说本章主要研究PGP(用于私人)和S/MIME(用于工业和组织)本章内容第1节 电子邮件安全服务第2节 Pretty Good Privacy 第3节 S/MIME 小结 本章首先讲述了电子邮件的安全需要，接着讲述了主要用于保证个人电子邮件安全的技术PGP。在PGP之后又讲述了主要用于保证商业与组织电子邮件安全的技术标准S/MIME。集中讲述这些技术的安全保证机制、有关的消息格式、消息的内

2、容、消息的变换等。内容比较琐碎，但是也比较容易理解。思考题 选择一个本章没有研究的电子邮件安全需要，分析什么情况下有这样的安全需要，并为该安全需要设计一种安全保证机制。 分析本章的电子邮件安全方案PGP和S/MIME还有什么缺点与漏洞。第1节 电子邮件安全服务 理想的电子邮件安全服务应该包括下列内容： (1) 私有性：只有预期的接收者才能阅读邮件消息； (2) 认证性：向接收者保证发送者身份的真实性； (3) 完整性：向接收者保证发送者发送的邮件在传输过程中没有被修改过。电子邮件安全服务 (4) 非否认：发送者不能否认曾经发送过某个消息。 (5) 邮件提交证据：邮件系统给发送者提供的、证明其所

3、发送的信息已经提交给了邮件投递系统的证据。 (6) 邮件投递证据：证明接收者已经收到该邮件消息的证据。 (7) 消息流的机密性：确保Carol不仅不知道Alice发给Bob的邮件内容，而且也不知道Alice电子邮件安全服务是否给Bob发送过邮件。 (8) 匿名性：邮件的接收者无法知道发送者的身份。 (9) 防泄漏：保证具有某种安全级别的信息不会泄漏到特定区域的能力。 (10) 审计：应该具有记录安全相关事件的能力。 (11) 计费：邮件系统应该具有记录使用情况的能力电子邮件安全服务 (12) 自毁服务：发送者可以规定邮件被投递到接收方之后应该自己销毁。 (13) 消息序列完整性：保证一系列消息

4、按照发送顺序达到，不会丢失。 目前大多数邮件系统都不提供这些安全服务，即使专门设计的安全邮件系统也只提供其中的若干种。目前安全电子邮件所提供的服务主要是私有性、认证、完整性和消息序列完整性。一些安全服务的解决思路 (1) 建立密钥：多数安全服务是通过使用密码机制实现的，但是密码机制需要密钥。如果Alice要给Bob发送消息，那么需要知道哪些密钥呢？Alice怎样才能可靠而有效地得到这些密钥呢？发送消息的过程还有谁参与？这是电子邮件安全首先要研究的问题。 (2) 私有性：很多人认为电子邮件是保密的，其实那些想知道别人秘密的人有许多方法可以得到别人的邮件消息，比如通过搭线窃听获取一些安全服务的解决

5、思路在网络上传输的邮件消息，中继节点也可能安装了保存邮件消息的软件，并将邮件消息泄露给想知道的人。所以要想保密，不能依赖于网络来保证消息的机密性。通过使用密码机制对消息进行加密，就可以保证消息的机密性。很自然的想法是用Bob的公开密钥或者双方共享的对称密钥加密，但邮件通常不采用这种方式，原因是：如果Alice有一个很长的邮件要发送给多个接收者，那么就需要针对每个接收者分别加密消息，结果发送给每个接收者的消息都不同。而且公钥加密比对称加密慢得多。一些安全服务的解决思路如非必要，最好不要使用长期密钥，为了延长共享的长期密钥的生命周期，最好是尽可能少地使用这种代价昂贵的密钥加密消息。那么邮件系统所使

6、用的方法是：Alice选择一个随机的对称密钥S，Alice首先使用S加密邮件消息，然后使用Bob的公钥加密S，再把加密的消息和加密的密钥发给Bob。这种机制对于要发送给多个接收者的情况也带来方便。 (3) 在普通的邮件中，Carol可以将发送给Bob的邮件的消息中From域填上Alice。如果邮件的一些安全服务的解决思路来源比较重要的话，这就会成为一个严重的问题。因此安全邮件系统需要Bob确信邮件的消息确实来源于Alice。一般通过公开密钥技术实现源认证。 (4) 消息完整性：当Bob接收到Alice发送来的消息时，他怎么知道Carol是否拦截并篡改了该消息呢？如果不能保证消息的完整性，那么源

7、认证也就没有多大意义。所以，所有的邮件系统要么同时提供消息的完整性和源认证，要么一些安全服务的解决思路都不提供。 (5) 非否认：如果Alice给银行发送一条消息，要求给Bob的账户转100万美元，而银行转了账以后，Alice可以否认发送过这个消息，那银行还会相信这种方式发来的信息吗？银行不仅需要证实该消息确实来自Alice，而且在必要的时候，还应当能够向法院证明Alice的确发送过这个消息。使用公钥技术能够很自然地实现非否认的源认证。一些安全服务的解决思路 (6) 邮件提交证据：电子邮件能够提供类似于挂号信服务的功能。只不过电子邮件系统采用的是对邮件内容进行密码学运算的方式。为实现邮件提交证

8、据服务，邮件系统可以将邮件与其他有用的信息串接起来，然后计算消息摘要并对其进行签名。用户可以使用该收据来证明该消息已经被发送。 (7) 邮件投递证据：电子邮件系统中的实现方式是要求邮件消息的接收者或者邮件投递服务一些安全服务的解决思路方对邮件消息和其他有用信息的消息摘要进行签名。 (8) 消息流的机密性：这样的服务可以通过中介转发，甚至通过多个中介转发。 (9) 匿名性：因为大多数邮件系统会在邮件消息中自动包含发送者的名称。修改发送者名称并不能保证匿名性。如果确实想保证消息的匿名性，可以使用消息流机密性的类似技术。一些安全服务的解决思路 (10) 防泄漏：该特性模仿了强制访问控制，网络可被分为

9、能够处理特定安全级别的多个部分，每个邮件消息可被标记为不同安全级别，消息的路由设备可以拒绝将某个消息转发到不能处理该安全级别的网络中去。 (11) 校验消息的真正发送时间：为什么会有人将消息的发送时间提前呢？不诚实的采购者为了不对自己所发出的采购信息负责，他可以说该采购信息是在私钥丢失之后，别人一些安全服务的解决思路签署的，但故意将消息时间提前了。这种证明消息是在某个特定的时刻之前生成的，解决方法是采用公证的方法。要证明消息是在某个特定时刻之后生成的，那么可以在消息中嵌入一个在这个时刻以前还不知道的东西，例如某个时间的出版的报纸、刊物等。 BACK第2节 Pretty Good Privacy

10、 电子邮件与WWW被并列称为网络杀手级应用(Killer Use) 。这两方面的应用正是互联网发展的双引擎。电子邮件是唯一的能够跨越各种体系结构、各种供应商平台的分布式应用。用户期望能够、并且也确实能够向直接或间接与互联网相连的其他用户发送信息，而不需考虑用户的操作系统或通信机制。PGP 由于对电子邮件的依赖越来越严重，电子邮件的安全问题也被提上研究日程。人们希望电子邮件系统也能够提供安全的电子邮件服务。电子邮件的安全主要包括机密性和认证性，主要解决方案有PGP和S/MIME，本章主要讲述这两种安全机制。PGP概述 PGP在计算机界是一个惊人的现象，因为PGP基本上是一个人努力的结果。PGP并

11、不是一个新的算法或者新的技术，它是通过将最优秀的加密算法、认证算法、签名算法等进行恰当的组合，形成一个基于少量的易于使用的命令的、通用的安全的电子邮件应用。该应用独立于操作系统和处理器。PGP不仅能够用于保护电子邮件，也能用于对文件进行加密和完整性保护。PGP概述PGP处理电子邮件的方式与普通电子邮件没有什么不同。要发送电子邮件，首先使用PGP来转换要发送的文件，然后再使用传统的邮件程序来发送转换之后的文件。同样接收用PGP加密的邮件时，也是把接收道的邮件当作一个PGP文件进行处理。因为这样有点不太方便，可以把PGP集成到其他邮件系统中，PGP的源代码中包含几个经过修改的通用的邮件系统。PGP

12、概述 PGP能够得到广泛的应用，与下面的原因是分不开的： (1) 它的各种版本在全球范围内都可以自由获取，并且能够运行各种操作平台(Windows, Unix, Macintosh)。 (2) 它选择的算法经过广泛的公开分析，被认为是极其安全的。而且算法包中包括RSA, DSS, Diffie-Hellman公钥算法，CAST, IDEA, 3DES对称加密算法和SHA-1散列算法，给用户选择PGP概述的自由。 (3) 具有广泛的适用性，从希望加密文件与消息的公司到希望在全球范围内进行安全通信的个人，都可以使用。 (4) 它不是任何政府或标准组织所开发的，也不受任何政府或标准组织的控制。这使得

13、PGP很有吸引力。 (5) PGP已经成为互联网事实上的标准之一。PGP提供的安全服务 PGP能够提供三类服务包括：认证性服务、机密性服务、认证性与机密性服务。现在我们先看一下PGP如何提供这三种服务的，然后再来看这三种服务的细节。 PGP的操作有5种：数字签名、消息加密、消息压缩、电子邮件兼容变换、对消息分段。 首先看三类服务分别是如何实现的。PGP认证过程 (1) Alice产生一个消息。 (2) 用SHA-1生成该消息的160比特的散列值。 (3) Alice 用她的私钥对散列值签名，放到原消息的前面。 (4) Bob 收到后用Alice的公钥解密恢复散列值。 (5) Bob 用该消息计

14、算其散列值，并与解密的散列值比较，如果匹配，就认为消息是可信的。PGP机密性保证机制 (1) Alice 产生一个消息与一个128比特的随机数(作为加密该消息的密钥)。 (2) Alice 用该密钥和CAST-128 (or IDEA or 3DES) 加密消息。 (3) Alice 用Bob的RSA公开密钥加密密钥，并放到消息的前面。 (4) Bob 用自己的私钥解密，得到会话密钥。 (5) 用这个会话密钥解密实际消息。机密性与认证性 PGP保证机密性与认证性的方法非常简单、直观，实际上就是将机密性保护的过程从中间截断，然后在中间加上保证认证的过程。这样简单的方法就实现了认证性与机密性保护。

15、PGP的压缩 PGP默认在签名之后，加密之前要进行一次压缩。压缩能够节约电子邮件存储与传递过程中所需要的空间。压缩算法放在什么位置非常关键。压缩放在签名之后的原因有两个： (1) 签署未经压缩的消息，使得人们能够仅仅保存未经压缩的消息以及对消息的签名，可以在以后随时进行验证。如果签署的是经过压缩的消息，当以后需要验证时，就需要保存一个消息的压缩文件或者重新进行压缩，这两种方法都给使用带来不便。PGP的压缩 (2) 即使验证时，验证者乐意进行压缩，PGP压缩也会带来困难。因为PGP算法是不确定的，不同的算法有不同的压缩率和压缩速度，并产生不同的压缩格式。然而，这些不同的压缩算法具有互操作性。在压

16、缩之后进行散列运算与签名将限制接收方与发送方必须采用同样的压缩算法。消息先压缩后加密能够增强安全性，因为压缩能够减少原始明文中的信息冗余，这就使得密码分析更加困难。PGP采用的压缩算法是ZIP。PGP与E-mail的兼容性 只要采用PGP，至少有部分的数据包是经过加密后传输的。如果仅使用签名服务，那么消息摘要需要加密。如果使用机密性服务，消息和签名都要加密。因而部分或全部的数据包是由任意的8个一组的数据流组成的。然而许多E-mail系统只允许使用由ASCII文本所组成的数据包。为与这种限制相兼容，PGP提供了将原始的8比特二进制数据流转换成可打印的ASCII文本的服务。PGP与E-mail的兼

17、容性所用的方案是Radix-64转换。这种方案将3字节的数字，转换成4个ASCII码字符。6个连续的比特用一个ASCII码字符来代替。因为这种转换是一种不考虑原始内容的盲转换，即使输入数据中偶尔有ASCII码。所以如果消息经过签名，但不加密，通过这种转换后，消息对于一般的接触到消息的人来说是不可读的，这也提供了一定程度的机密性。下面的图说明了PGP所提供的四种服务之间的关系。发送方进行的处理过程PGP与E-mail的兼容性在传输消息时，如果需要签名，就对未压缩的明文消息的散列函数值进行签名。然后对明文和签名进行压缩。下一步，如果有机密性要求，就将压缩后的数据进行加密，同时将对称加密密钥用接收方

18、的公开密钥加密并置于前面加密的数据之前，最后将所有的数据用Radix-64转换，转换成Radix-64 格式。在接收方进行顺序完全相反的操作，具体过程如下图所示。分拆与重新装配E-mail设施通常都限制所传输文件的大小，这主要是为了限制利用E-mail发送可执行文件。所以任何大于限制大小的消息都必须拆开成为小于限制大小的消息，分别进行传输。为适应这种情况，PGP自动将太大的消息拆分成能够通过E-mail进行传输的消息，这是在前面的所有处理(包括Radix-64转换)都完成后进行的。这样做的好处是会话密钥与签名仅在拆分后的一个字组中出现一次。在接收端，PGP首先要剥离E-mail的所有报头，并重

19、新装配信息，然后进行下面所示的处理。接收方进行的处理过程密钥与密钥环 PGP中有四种密钥，分别是一次性的对称会话密钥、公开密钥、私有密钥和基于通行短语的对称密钥。对这些密钥有三种基本要求： (1) 要能够产生不可预测的会话密钥； (2) 应当允许用户使用多个公开密钥私有密钥对。原因是用户可能会时不时地更换其密钥对。更换密钥对就带来一个问题，所有尚在路途中的信息都将用过时的密钥进行处理，而且在更新到达接收者之前，接收者只能使用旧的密钥与密钥环公开密钥。此外一个用户在同一个时间也可能使用多个密钥对与不同的对象通信，或者仅仅为了限定一个密钥所加密的信息量，从而增强安全性。所有这些都说明用户和他们的公

20、钥之间并不存在一一对应的关系，这就需要一定的机制来识别具体的密钥。每一个PGP实体都必须维护一个自己的公钥/私钥对文件以及需要进行通信的其它实体的公钥文件。生成会话密钥 一个会话密钥与单个消息相关联，而且只用于加密或解密相应的消息。在PGP中加密与解密的算法是CAST-128，IDEA或者3DES。假设使用CAST-128算法，我们来讨论会话密钥的生成方法。首先用CAST-128生成一个128比特的随机数，生成方法是给该算法输入一个128比特的密钥和作为明文的两个64比特的分组。运用CFB模式加密，生成两个64比特的密文分组，将这两个密文分组连接起来，生成一个128比特生成会话密钥的会话密钥。

21、 输入随机数生成器的明文有两个64比特的分组，是从128比特的随机数获得的，而这128个比特的随机数是通过用户击键所用的时间与实际敲击的键决定的。因而如果用户正常敲击键盘上任意的键，将会产生合理的随机数。随机输出还与前面的会话密钥输入有关。这样采用CAST-128，就能产生一个确实不可预测的会话密钥。具体过程如下图所示。密钥标示 如前所述，加密的消息必须伴随一个用接收者公钥加密的会话密钥。所以只有合法的接受者才能恢复会话密钥、进一步恢复出消息。如果每个用户都只使用一个公钥私钥对，那么接收者只要用相应的私钥解密会话密钥即可。现在一个用户可能有许多公钥私钥对，那么接收者怎么知道用哪个私有密钥去解密

22、呢？当然朴素的解决方案有两种，一是用所有的私要试一遍，或者让发送者附上所用的公钥。这两密钥标示种方法有什么问题呢？在第2种方案中接收者只要验证所附的公钥确实是自己的公钥，就知道对应的私钥，工作就可以进行下去。但是附带公钥也不是一个小的数据，每个信息需要附带几百个十进制数。另一种方案是给每个公钥一个编号。然后只需要告诉接收者所用的公钥的编号即可。这又产生了一个管理问题：公开密钥的编号必须在发送者和接收者之间进行交换，并确保始终一致。这是一个不必要的负担。密钥标示 PGP采用的方法是在发送消息的同时，发送所采用的公开密钥的最后面的64比特。这样虽然不能保证两个密钥最后面64比特一定不同，但可以保证

23、两个不同的密钥最后64比特相同的概率非常低。 介绍了密钥表示的概念之后，我们可以更详细地看一下PGP所传送的消息的格式。具体的格式如下面的图所示。PGP消息 消息：指实际要传输的数据、文件名与表明文件生成时间的时间标记。 签名：包括签名生成时间、消息摘要(160比特的SHA-1摘要，并用发送者的私有密钥签名)、消息摘要的起始16比特，用于验证对摘要的解密是否正确、发送者的公钥ID。 会话密钥部分：包括用接收者公钥加密的会话密钥、接收者公钥变ID。 所有PGP消息最后转换成Radix64格式消息。密钥环 密钥ID在PGP操作中是非常关键的，为了保证机密性与真实性，PGP信息需要两个密钥ID，这些

24、密钥需要系统地存储与组织以保证所有当事人都能够使用。PGP采用的机制是在每个节点有两个数据文件，一个保存该节点的公钥私钥数据，另一个保存该节点知道的其他节点的公开密钥数据。这些数据分别称为私有密钥环和公开密钥环。下面的图表示一般的密钥环的结构。私钥环时标密钥ID公钥加密私钥用户ID.TiPimod 264PiE(Si)用户i.公钥环时标密钥ID公钥信任级别用户ID密钥合法性签名签名信任程度.TiPimod 264PiTrust_flag用户iTrust_flag.私钥密钥环 为使用方便，用户ID一般用用户的E-mail地址来表示。当然也可以选用用户的姓名作为用户ID。用户ID或密钥ID都可以作

25、为索引项。有时可能需要用这两项合起来作为索引项。为保证机密性，用户的私钥需要加密保存。运用基于通行短语(Passphase)的加密过程： (1) 用户选择一个通行短语； (2) 利用SHA-1对通行短语进行散列运算，产生一个散列函数值，抛弃通行短语；私钥密钥环 (3) 系统运用CAST-128加密散列值，散列值也被丢弃，用加密过的散列值作为私有密钥。 相应地，用户如果要想使用私有密钥，就必须提供通行短语。PGP就可以恢复出私有密钥。 这是非常紧凑，非常有效的方案，同任何基于口令的系统一样，系统的安全性取决于通行短语的安全性。应该使用不易猜测，但易于记忆的通行短语。公钥密钥环 需要注意的是在公钥

26、密钥环中，同一个公钥可能有多个用户ID。 现在，我们来看一下在消息发送与接收过程中如何使用密钥环。为简单起见，我们忽略压缩和转换过程。如下面的图所示。 发送方按照以下步骤进行： 1 对消息进行签名: (1) PGP应用密钥ID作为索引项从私钥密钥环中找到发送者的经过加密的私钥。如果没有提供密钥ID，就用第一个私发送者最后发送的消息形式密钥环的使用钥。(2) PGP提示用户输入通行短语，以便对私钥解密。(3) 利用私钥构造消息的签名部分。 2 加密消息：PGP产生一个会话密钥，并用该会话密钥加密消息。(2) PGP从公钥密钥环中找到接收者的公钥。(3) 利用公钥构造PGP消息的会话密钥部分。 而

27、在接收方，接收者进行如下操作，如下面的图所示。 接收者的工作 (1) 解密消息：(a) 从收到的消息的会话密钥部分找到密钥ID，据此找到接收者的私钥。(b) PGP提示接收者输入通行短语，用私有密钥解密得到会话密钥。(c) 用会话密钥解密消息。 (2) 认证消息: (a) PGP找到发送者的公钥。(b) PGP解密消息摘要。(c) PGP计算消息的摘要，然后把计算的消息摘要和解密的消息摘要进行比较，如果匹配，则通过认证。公钥管理 PGP用一套聪明的、高效的、互相制约的函数与格式约定提供有效的机密性与真实性服务。为了使整个系统能够顺利工作，还需要解决一个问题：公开密钥的管理问题。保护公开密钥不被

28、篡改在公开密钥的应用中是一个最困难的问题。它是公开密钥密码学唯一致命的弱点，为解决这个问题需要付出许多计算复杂性的代价。PGP提供了这个问题的一个结决框架，因为PGP用途广泛，所以并没有提出一个刚性的公钥管理方案。公钥管理 问题的实质是用户Alice必须建立包含所有用PGP进行通信的对象的公钥的一个公钥密钥环。假设Alice的密钥环包含Bob的公钥，但实际上该公钥是Carol的。这种情况可能在下面的环境下发生：Alice从公钥数据库中获得了Bob的公钥，而事实上Carol用自己的公钥替换了Bob的公钥。这样的结果就会产生两个威胁: (1) Carol能够给Alice发送消息，并且能够假冒Bob

29、的签名，Alice就会将Carol发送的消息当成是公钥管理Bob发送的消息。(2) Carol能够阅读Alice给Bob发送的任何消息。 有一些可行的方案能够使一个用户的密钥环中包含假的公钥的风险降到最低。下面都是一些可以采取的措施： (1) 用物理措施获得Bob的密钥。Bob可以当面告诉Alice，或者当面写给Alice，或者把密钥存到一个磁盘中交给Alice，Alice拿回去直接装到自己的密钥环中。公钥管理 (2) 通过电话验证密钥：Bob可以通过E-mail告诉Alice他的公钥，然后通过电话告诉Alice公钥的散列函数值，如果Alice能够辨别Bob的声音，该方法就是可行的。 (3)

30、Alice 通过一个互相信任的个体获得Bob的公钥。 (4) Alice从CA处得到Bob的公开密钥。 在后两种情况下，Alice都需要决定可信者的可信水平。公钥管理 尽管PGP并没有规定建立认证的任何机制，但却提供了一个方便的利用信任链的方法，将信任与公钥关联起来，并开发信任信息。基本的结构如下：公钥环的每一个记录包含一个公钥证书和一个信任水平，表明PGP对该公钥的信任程度。信任度越高，用户ID与该密钥的绑定关系越紧密。与密钥环的条目有关连的还有密钥环拥有者所收集到的关于证书的零个或者多个签名。每个签名以此与一个信任域相关联，表明PGP用户信任签名者对证书的签名的公钥管理信任程度。密钥信任域

31、的内容是从收集的关于该条目的所有签名计算出来的。最后密钥环中的每一个条目都定义了与某个拥有者相关联的一个公钥、一个拥有者的信任域用于表明公钥环的拥有者对于该公钥拥有者所签发的证书的信任程度。这个信任水平是有由密钥环的拥有者自己确定的。 包含在框架中密钥信任域、签名信任域和拥有者信任域被称为Trust flag byte. 假设我们在讨论用户Alice的密钥环，信任处理操作如下：Trust flag byte 内容信任操作处理 (1) 当Alice钥在自己的密钥环中添加一个公开密钥时，必须为该公开密钥的拥有者分配一个Trust flag。如果该公钥的拥有者就是Alice本人，该公钥将会在Alic

32、e私钥密钥环中出现，那么就分配一个最高程度的信任度。否则PGP将请求Alice对该密钥进行评价，Alice必须给出一个希望的信任程度，Alice的选择包括Unknown, untrust, marginally trust or completely trust. (2) 添加一个公钥时，必须附带一个或多个签名。以后还可以添加更多的签名。当添加一个信任操作处理签名时，PGP就会搜索公钥环，查看该签名的签名人是否是一个已知的公钥的拥有者。如果是，就为该签名的签名信任域分配一个OWNERTRST值，否则就分配一个未知用户值。 (3) 以本条目的签名信任域为基础计算密钥信任值。如果至少有一个签名是由

33、最高信任程度的拥有者签署的，那么密钥信任值就设置为完全信任。否则PGP要计算信任值的加权和。对信任操作处理对于总是信任的签名分配1/X的权重，对于通常信任的签名分配1/Y的权重，其中X和Y是用户设置的参数。如果所有签名者关于密钥/用户ID的权重和达到1，就认为绑定是可信的，密钥的可信值就设置为完全可信。因而如果缺少最高可信者签名，至少需要X个总是信任签名或者Y个通常信任的签名，或者他们的组合。 PGP会周期性地更新密钥环，以保证一致性。本质上这是一个自顶向下的过程。信任操作处理对于每一个OWNERTRUST域，PGP扫描密钥环，找到拥有者的所有签名，并将SIGTRUAT域修改为与OWNERTR

34、UST域值相等。从具有最高信任程度的密钥开始处理。所有KEYLEGIT域值以附带的签名为基础进行计算。下面的图表明了签名信任域值和密钥信任域值关联的方法。该图表示的是一个密钥环的结构，用户Alice已经得到了一些公开密钥，有些直接来自于密钥的拥有者，有些来自于第三者。标“You”的节点代表Alice，该密钥具有信任操作处理最高的信任程度。在Alice为他们分配其他值以前，该密钥环中的其它节点的OWNERTRUST值一律为undefined. 在这个密钥环的结构途中要注意的几种情况： (1) Alice与节点E、F之间的信任关系； (2) H和A、B节点之间的信任关系； (3) N和R节点之间的

35、信任关系； (4) 孤儿节点S的情况。公钥的撤销 一个用户可能希望撤销其使用的密钥，原因可能是密钥遭到破坏，或者仅仅不想使用更长的时间。密钥遭到破坏可能是攻击者得到了你的未加密的私钥的副本，或者攻击者从你的私钥密钥环得到了你的私钥以及通行短语。 撤销公钥的机制约定由公钥的拥有者签发一个自己签名的撤销证书。内容与正常的签名证书形式想同，但包括撤销该公钥的证书的目的。证书的拥有者应当尽可能快、尽可能广泛地告诉潜在的通信者，及时更新它们的密钥环。 BACK第3节 S/MIME S/MIME是基于RSA数据安全公司技术的电子邮件安全强化机制。PGP与S/MIME两者各有优势，不过从目前的趋势看来，似乎

36、S/MIME将会成为商业与其他社会机构所使用的工业标准，而PGP将会成为个人用户安全的首选。要想理解S/MIME，必须首先熟悉MIME，并与传统的RFC822规定的电子邮件格式进行比较。 RFC822格式：RFC822定义了电子邮件发送的文本消息的格式。现在已经作为文本电子邮件RFC822邮件格式的格式标准。RFC822定义E-mail信息包括信封和内容。信封包括完成内容传输与提交所需要的需要的额外信息。内容则组成了向接收者所提交的主题。内容包含邮件系统创造信封所需要的一套报头域。符合RFC822的消息结构非常简单。一条消息包括报头和不受限制的主体(body) 。报头和body之间用一个空白行

37、隔开。在第一个空白行之前的所有行都被认为是邮件系统所使用的报头行。一个报头行通常由一个RFC822邮件格式关键词，紧跟一个冒号，然后是关键词的参数。并允许将一个较长的报头行分成若干行。经常使用的关键词有From, To, Subject, and Date. 下面就是一个简单的例子。Date: Tue, 16 Oct 2006 10:38:18From: “Tom” To: smithCc: Jones.Hello. Please meet me at SNNU on Oct.28.RFC822邮件格式 RFC822格式有以下局限性： (1) 使用的邮件协议仅限于SMTP，而SMTP协议不能传

38、输可执行文件与其他二进制对象； (2) SMTP不能传输包含National language characters. 因为这些character是用8比特编码表示的，而SMTP仅限于7比特的ASCII码； (3) SMTP将拒绝超过规定大小的邮件消息； (4) 在ASCII和EBCDIC编码之间进行转换的SMTP网管并不使用一套一致的映射，导致RFC822邮件格式翻译问题。 (5) 某些SMTP的布署并不完全符合SMTP标准。主要问题包括：删除、添加或者重新记录回车、换行；截断或者限制超过76字符的行；将消息中的一行填充到相同的长度；将Tab字符转换成多个空格字符。 MIME就是为解决这些问

39、题，并要与RFC822格式兼容而提出的新的邮件格式。MIME邮件格式 MIME是RFC822格式的扩展，主要是为了使E-mail能够收发各种格式的文件。主要包含下面的几个元素：定义了5个消息报头说明消息主体的有关信息定义了7种内容类型实现多媒体电子邮件表示的标准化定义了6种内容转换编码将内容转换成受邮件系统保护的免于修改的格式。MIME的5种报头 (1) MIME版本号：只有一个参数1.0。 (2) Content-Type: 描述信息主体的数据，为使接收者选择适当的代理或机制表示或处理有关的数据提供足够详细的信息。 (3) 内容转换编码：说明信息主体所用的变换方法。 (4) Content-

40、ID: 用于在多个消息中唯一地标示一个MIME实体。 (5) 内容描述：一个对于主题和信体的文字描述，如果主题不可读，这部分信息就很有用。MIME 内容类型 MIME定义了7中内容类型：Type SubtypeTypeSubtypeTextPlain, EnrichedVideompegMultipartMixed, Digest Parallel, AlternativeAudioBasicMessageRFC822, Partial, External-bodyApplicationPS, Octet流ImageJpeg, gifMIME 内容类型 MIME的内容类型声明了数据的大类和子类

41、，并规定了那种内容类型的具体格式。 (1) Text type 的首选子类是Plain text, 是指ASCII码串或者ISO8859码串，enriched 子类提供了更高的格式灵活性。 (2) 多部类型：说明信体包含多个相互独立的部分，内容类型报头包括一个边界参数，定义信体之间的边界，边界不应出现信息的任何部分，最后边界表明最后一个部分的结束。下面是一个multi-part消息的例子。From: Alice To: BobSubject: sample messageMIME-Version: 1.0Content-type: multi-part/mixed; boundary=“sim

42、ple message”This is the preamble - -simple boundaryThis is implicitly. - -simple boundary Content-type: Text/plain; charset=us-asciiThis is explicitly. - -simple boundary-MIME 内容类型多部类型有4个子类：mixed表示不同的部分相互独立，但一起发送，应当按邮件消息的顺序提交给接收者；Parallel子类没有限定不同部分的顺序；Alternative子类是同一个信息的不同版本，接收者的邮件系统应该显示对于接收者来说是最好的

43、版本。 (3) Message type 为MIME提供了一些重要的性能。Rfc822子类表明信体是一个完整的包含信头和信体的消息。Partial 子类使得消息能够MIME 内容类型拆开成许多部分，到目的地后必须重新组装。这个子类需要三个参数：消息的各个片段需要分配同样的ID号，每个片断需要有一个序列号，全部片段数。External-body子类表明信的真正数据并不在信体中，信体只是关于如何访问有关数据的说明。 (4) 应用类型:只其他类型的数据，可能是无解释的二进制数据或者需要基于邮件的应用处理的信息。MIME 转换编码 除了内容类型的定义外，MIME另一个重要的定义是消息体(body)的编

44、码方法。这主要是为了能够通过大范围网络将邮件提交给用户。MIME定义了2种编码方法。内容编码域实际上可以有6个选项(7bit, 8bit, binary, quoted-printable, base64, x-token)，但7bit, 8bit, binary 实际上表明没有用任何编码方法。X-token 表明采用了MIME规定的范围以外的编码方法，这就需要提供具体的编码方法。MIME 转换编码MIME规定的两种有效编码方法是quoted- printable 与base64。 当数据主要是与可打印的ASCII码相应的8个一组的数据时，使用quoted-printable编码。本质上是直接

45、引用八进制码直接表示字符的编码。Base64编码方法就是前面所讲的Radix64编码。 S/MIME的作用 从作用来看，S/MIME与PGP非常相似，都提供签名与加密的能力。S/MIME提供下面的四种功能： (1) Enveloped data: 包括加密任何类型的数据、为多个接收者加密会话密钥。 (2) Signed data: 加密内容的摘要形成数字签名，并用接收者的公钥加密签名。签名与内容一起用Base64编码。S/MIME的作用 (3) Clear-signed data: 是对内容的数字签名。只有数字签名部分才用Base64编码。这样即使不支持S/MIME的接收者也可以阅读内容，但不

46、能验证签名。 (4) Signed and enveloped data: 仅仅经过签名的实体与仅仅经过加密的实体才能够嵌套，这样加密的数据可以再签名，签名的数据也可以再加密。 密码学算法：下面的标概括了S/MIME所使用的算法与术语。加密算法功能要求产生消息摘要用于数字签名必须支持SHA-1，接收者应当支持MD5。加密消息摘要形成数字签名双方必须支持DSS，发送代理应支持RSA，接收代理应支持RSA签名验证传输消息用的加密会话密钥双方代理必须支持Diffie-Hellman。发送代理应支持RSA加密，接收代理应支持RSA解密用一次性会话密钥加密消息发送代理应支持3DES与RC2/40，接收大

47、力必须支持3DES解密，应当支持RC2/40解密加密算法 S/MIME集成了三种公钥算法：DSS、RSA和Diffie-Hellman。对于散列算法，S/MIME规定了两种算法：SHA-1和MD5算法。对于加密算法，S/MIME规定了两种算法：3DES和比特密钥RC2 40算法。 在决定选用什么加密算法进行加密时，发送代理必须考虑接收方的解密能力。基本选择原则如下： (1) 如果发送代理有一个按接收方的喜好排序加密算法的解密列表，应当选择列表中的第一个算法。 (2) 如果发送代理没有这样的列表，那么最近一次接收方发来的信息用什么算法加密，就选择什么算法加密。 (3) 如果上述的消息都没有，并乐

48、意冒接收方无法解密的风险，那么就选用3DES算法。 (4) 如果上述的消息都没有，而且不愿意冒接收方无法解密的风险，那么就选用RC2算法。S/MIME 消息 S/MIME的消息类有两个大类，6个子类。所有的新的应用类型用设计的PKCS( public key cryptography specification). 保证一个MIME实体的安全措施：签名、加密或者二者并用。一个MIME实体可以是全部的MIME消息，如果消息是由多个部分组成的，那么每个部分都可以是一个MIME实体。一个MIME实体与有关的数据、比如算法ID与证书等，通过S/MIME的处理生成一个PKCS对保证MIME实体的安全象。

49、一个PKCS对象作为消息内容被处理并包装成MIME。需要特别注意转换编码的应用。多数情况下应用安全算法生成一个可部分或全部用任意二进制数表示的数据。这个数据再转换成Base64编码发送出去。一个应用/pkcs7-mime子类用于四类S/MIME的处理过程，每个过程有一个唯一的smime类型参数。处理的结果称为一个对象，并以Basic Encoding Rules 的方式表示，BER是国际电信联盟在X.209中规定的编码规则。BER格式是由8个一组的任意串组成的，这样的对象应当在发送出去之前转换成base64编码格式的消息。Enveloped Data 准备一个envelopedData MIM

50、E实体的过程如下：Enveloped Data其中RecipientInfo的信息包包括接收者的公钥证书号、用于加密会话密钥的算法ID以及加密的会话密钥。RecipientInfo与紧跟着的加密的消息构成了EnvelopedData。然后，这个信息也用base64编码。要恢复加密的消息，接收者首先剥掉base64编码，然后用自己的私钥解密会话密钥，最后用会话密钥解密消息内容。Signed Data 准备一个Signed Data MIME实体的过程如下： (1) 选择消息摘要算法； (2) 计算消息摘要； (3) 用签名者的私人密钥加密消息摘要； (4) 生成一个称为SignerInfo的信息

51、包，包括签名者的公钥证书号、消息摘要算法ID、加密算法ID与经过加密的消息摘要。Signed Data 消息摘要算法ID、被签署的消息与SignerInfo 等构成了一个signedData 实体。也可能还包含足以构造从根CA或最高级别的CA到签名者的证书链的一套证书。这条信息被编码成base64码。 要恢复签名的消息并验证签名，接收者首先剥掉base64编码，然后用签名者的公钥解密消息摘要。接收者独立计算消息摘要，并与解密的消息摘要进行比较来验证签名。Clear Signing Clear signing (透明签名)是通过具有签名子类的多部分内容类型获得的。因为该签名并不对要传输的信息进行

52、签名，发送的消息是透明的，故称为透明签名。 一个multipart/signed 签署消息有两部分组成。第1部分可以是任何MIME类型，但必须进行适当的处理以保证在源端发往目的端的过程中不被篡改。这就意味着如果第1部分不是7比特形式，就需要用base64或者quoted-printableClear Signing进行编码。然后用SignedData方式相同的方法处理这一部分。但是这种情况下创建的具有SignedData格式的对象的消息内容域是空的。这个对象可以与签名相分离。然后用base64编码这个对象，变成multipart/signed的第2部分。这第2部分具有MIME应用内容类型以及pkcs7-Signature子类。接收者可以提取第1部分的消息摘要，与从第2部分的签名中恢复的消息摘要进行比较来验证签名。Registration Request 通常，一个用户或者一个应用会向一个CA申请一份公钥证书。要传递一个证书请求需要用application/pkcs10 S/MIME实体。证书请求包含证书请求信息包RequestInfo，紧跟一个公钥加密算法ID与用发送者私钥签名的RequestInfo.RequestInf