《电子邮件的安全性》PPT课件.ppt

第12章 电子邮件的安全性 PGP（Pretty Good Privacs） S/MIME 1. PGP PGP的来源 PGP主要由于 Phil Zimmermann一个人的贡献，PGP提供了一种机 密性和鉴别的服务，可以用于电子邮件和文件存储的应用。 Zimmermann主要做了下面一些工作： 选择最好的、可用的加密算法作为基础构件。 将这些算法集成起来，形成一个通用的独立于操作系统和处理 器的应用程序，该应用程序基于易于使用的命令构成的小集合 。 制作了软件包和相应的文档，包括源代码，通过Internet、电子 公告牌和如 Compuserve的商业网，免费提供给用户。 和一个公司（Viacrypt，现在是Network Associates）签订了合 同，提供PGP的完全兼容的、低价格的商用版本。 1. PGP PGP的发展特点 PGP发展非常迅速，现在已经被广泛应用。PGP得到快速发展的 原因包括以下一些： 它是全世界免费可得到的，包括了运行在不同平台的多个版本 ，诸如：DOSWndow，Unix，Macintosh等。另外，商用版 本满足了那些想要获得厂家技术支持的用户的需要。 它建立在一些经过公开评议，被认为是非常安全的算法的基础 上。具体来说，PGP软件包包括了公开密钥的RSA，DSS和 Diffie-Hellman加密算法；常规的CAST-128，IDEA和3DES加 密算法；以及散列编码的SHA-1算法。 它的应用范围非常广，从想要选择和实施一个标准模式来加密 文件和消息的公司到想要通过Internet或其他网络和他人进行安 全通信的个人都可以使用。 它不是任何政府或标准化组织开发的，因而也不会被它们控制 。对于那些本质上不信任任何“组织机构”的人来说，PGP具有 吸引力。 1. PGP PGP的操作 功能使用的算法描述 鉴别 (数字签名)DSS/SHA或 RSA/SHA 使用SHA-1创建的报文的散列编码 。采用DSS或 RSA算法使用发送者的私有密钥对这 个报文摘要 进行加密，并且包含在报文中 机密性(报文加密 ) CAST或IDEA或三密 钥三DES，带有Diffie -Hellman算法或RSA 采用CAST-128或IDEA或3DES，使用发送者生成 的一次性会话密钥对报 文进行加密，采用Diffie- Hellman或RSA，使用接收方的公开密钥对 会话 密钥进 行加密并包含在报文中 压缩ZIP报文可以使用ZIP进行压缩 ，用于存储或传输 电子邮件兼容性64基转换为了提供电子邮件应用的透明性，加密的报文可 以使用64基转换 算法转换 成ASCII字符串 分段-为了满足最大报文长度的限制，PGP完成报文的 分段和重新装配 1. PGP PGP加密功能 1. PGP PGP的操作鉴别 发送者创建报文。 使用 SHA-l来生成报文的160 bit散列代码。 使用发送者的私有密钥，采用RSA算法对散列代码进行加密， 结果串接在报文的前面。 接收者使用发送者的公开密钥，采用RSA解密和恢复散列代码 。 接收者为报文生成新的散列代码，并与被解密的散列代码相比 较。如果两者匹配，则报文作为已鉴别的报文而接受。 尽管签名一般和所签的报文或文件附加在一起，但这并不是必需 的：分离的签名也是支持的。分离的签名可以和所签的报文分 开存储和传输，这种方法在好几种场合中都是有用的。用户可 能想要保持单独的所发送或接收的所有报文的签名日志。可执 行程序的分离签名可以检测出接下来的病毒侵入。最后，分离 签名可以用在需要多方签名的文档上，如法律合同。每个人的 签名是独立的，因而可以只是应用到文档上。否则，签名将只 能递归使用，第二个签名对文档和第一个签名进行签名，依此 类推。 1. PGP PGP的操作机密性 发送者生成报文和128 bit的用作该报文会话密钥的随机数。 采用CAST-128（或IDEA或3DES）算法，使用会话密钥对报文 进行加密。使用 64 bit来加密反馈（CFB）模式。 采用RSA算法，使用接收者的公开密钥对会话密钥进行加密，并 附加到报文前面。 接收者采用RSA算法，使用自己的私有密钥解密和恢复会话密钥 。 使用会话密钥来解密报文。 除了使用RSA对密钥加密之外，PGP提供了另一种称为Diffie- Hellman的选择。实际上，PGP使用的是Diffie-Hellman的提供加 密解密的变体一一ElGamal。 PGP提供给用户的密钥长度的范围达到768到3072比特。 1. PGP PGP的操作机密性与鉴别 PGP可以对报文可以同时使用两个服务。首先，为明文报文生成 签名并附加到报文首部。然后使用CAST-128（或IDEA或 3DES）对明文报文和签名进行加密，再使用RSA（或ElGamal ）对会话密码进行加密。这个步骤比相反的步骤要好：加密报 文然后再生成加密后的报文的签名。将签名与明文报文存储在 一起更加方便。另外，为了方便第三方验证，如果首先产生签 名，第三方在验证签名时就不需要与常规密钥打交道。 总之，当同时使用两个服务时，发送者首先用自己的私有密钥为 报文签名，然后使用会话密钥对报文加密，接着再用接收者的 公开密钥对会话密钥进行加密。 1. PGP PGP的操作压缩 在默认情况下，在签名之后加密之前，PGP可以对报文进行压缩 。这有利于在电子邮件传输和文件存储时节省空间。压缩算法 使用的是ZIP。 在压缩之前生成签名有两个理由： 对没有经过压缩的报文进行签名更好，这样为了将来的验证只需 要存储没压缩的报文和签名。如果对压缩文档签名，那么为了将 来的验证就必须或者存储压缩过的报文，或者在需要验证时重新 压缩报文。 即使一个人愿意在验证时动态生成重新压缩的报文，PGP的压缩 算法也存在问题。算法不是固定的，算法的不同实现在运行速度 和压缩比上进行不同的折衷，因此产生了不同的压缩形式。但是 ，这些不同的压缩算法是可以互操作的，因为任何版本的算法都 可以正确地解压其他版本的输出。在压缩之后应用散列函数和签 名，将约束所有的PGP实现都使用同样的压缩算法。 在压缩之后对报文加密可以加强加密的强度。因为压缩过的报 文比原始明文冗余更少，密码分析更加困难。 1. PGP PGP的操作电子邮件的兼容性 很多电子邮件系统只允许使用由ASCII正文组成的块。为了满足 这一约束，PGP提供了将原始8 bit二进制流转换成可打印 ASCII字符的服务。为这一目的采用的方案是radix-64转换。 1. PGP PGP的操作分段和重装 电子邮件设施经常受限于最大的报文长度。例如，很多Internet可 以访问的设施都有最大50 000个八位组的限制。任何长度超过 这个数值的报文都必须划分成更小的报文段，每个段单独发送 。 为了满足这个约束，PGP自动将太长的报文划分成可以使用电子 邮件发送的足够小的报文段。分段是在所有其他的处理（包括 radix-64转换）完成之后才进行的，因此会话密钥部分和签名 部分只在第一个报文段的开始位置出现一次。 1. PGP PGP报文格式 1. PGP PGP加密密钥和密钥环 PGP利用了四种类型的密钥：一次性会话的常规密钥、公开密钥 。私有密钥和基于口令短语（passphrase）的常规密钥（在下 面解释）。对于这些密钥存在三种独立的需求： 需要生成一种不可预测的会话密钥的方法。 允许用户拥有多个公开私有密钥对。一个理由是用户可能想 要不时地改变他或她的密钥对。当发生了这种情况时，管道中 所有报文都将是用过时的密钥构造的。此外，接收者在接到改 变的通知之前只知道旧的公开密钥。除了不时地改变密钥的需 要之外，在给定的时刻，用户可能想要拥有多个密钥对来和不 同的通信组交互，或者只是为了增强安全性而限制密钥能够加 密的报文的数量。这些原因的结果就是在用户和他们的公开密 钥之间不存在一一对应的关系。因此，需要某种方法来标识特 定的密钥。 每个PGP实体必须维护它自己的公开私有密钥对的文件，以 及与它通信的人的公开密钥文件。 1. PGP PGP会话密钥和IV的生成 参见密码编码学与网络安全：原理与实践(第二版)附录12C 。 1. PGP PGP的密钥标识符 PGP采用的解决方法是给每个公开密钥指派一个密钥ID，这在用 户ID中很可能是惟一的。密钥ID与每个公开密钥相关联，并由 公开密钥的最低64比特组成，即，公开密钥KUa的密钥ID是（ KUa mod 264）。这个长度足以使密钥 ID重复概率非常小。 PCP的数字签名也需要密钥ID。因为发送者可能使用一组私有密 钥中的一个来加密报文摘要，接收者必须知道应该使用哪个公 开密钥来解密。相应地，报文的数字签名部分包括了需要的公 开密钥的64 bit密钥ID。当报文被收到时，接收者验证该密钥 ID是它所知道的发送者的公开密钥，然后接着来验证签名。 1. PGP PGP的密钥环 任何一个PGP报文中包括的两个密钥ID提供了机密性和鉴别。这 些密钥需要以一种系统化的方法来存储和组织，使得各方能够 有效和高效地使用它们。PGP使用的方法是在每个结点提供一 对数据结构，一个用来存储该结点拥有的公开私有密钥对， 另一个用来存储该结点所知道的其他用户的公开密钥。相应地 ，这些数据结构被称为私有密钥环和公开密钥环。 1. PGP PGP私有密钥环的一般结构 时间戳：该密钥对生成的日期时间。 密钥ID：这个实体的公开密钥的低位64比特。 公开密钥：密钥对的公开密钥部分。 私有密钥：密钥对的私有密钥部分；这个字段是加密的。 用户ID：这个字段的典型值是用户的电子邮件地址（例如，stallings ）。然而，用户可以为每个密钥对选择不同的名字（例如 ，Stallings，Wstallings，Williamstallings等等），或者多次重用相同 的用户ID。 时间 戳密钥ID公开密钥加密的私有密钥用户ID TiKUi mod 264KUiEH(Pi)KRi用户i 1. PGP PGP对私有密钥的保护 尽管想要私有密钥环只存储在创建和拥有密钥对的用户的机器上 ，并且只有该用户可以访问私有密钥环，但确保私有密钥的值 尽可能地安全仍然很有意义。相应地，私有密钥本身并不存储 在密钥环中，相反，要使用CAST-128（或IDEA或3DES）来 对这个密钥加密。其步骤如下： 用户选择口令短语用来对私有密钥进行加密。 当系统使用RSA生成新的公开私有密钥对时，它向用户要求 那个口令短语。使用SHA-1生成该口令短语的160 bit的散列编 码，然后该口令短语被丢弃。 系统使用CAST-128，将128 bit的散列编码作为密钥来加密私 有密钥。然后，散列编码被丢弃，加密过的私有密钥被存储在 私有密钥环中。 当用户访问私有密钥环来查询私有密钥时，他或她必须提供相应 的口令短语。PGP将查询加密的私有密钥，生成口令短语的散 列编码，然后使用该散列编码来应用CAST-128对加密的私有 密钥进行解密。 1. PGP PGP公开密钥环的一般结构 时间戳：这个实体生成的日期时间。 密钥ID：这个实体公开密钥的低位64比特。 公开密钥：这个实体的公开密钥。 用户ID：这个密钥的拥有者。公开密钥可以与多个用户ID相关 联。 时间 戳密钥ID公开密 钥 拥有者信任用户ID密钥合法性签名 (S) 签名信任 (S) TiKUi mod 264 KUitrust_flagiUseritrust_flagi 1. PGP PGP报文生成 1. PGP PGP报文生成 签名报文 PGP使用用户ID作为索引从私有密钥环中查找发送者的私有密钥 。如果在命令中没有提供用户ID，那么查询环中的第一个私有密 钥。 PGP提示用户输入口令短语来恢复未加密的私有密钥。 构造报文的签名部分。 加密报文 PGP生成会话密钥并且加密报文。 PGP使用接收者的用户ID作为索引，从公开密钥环中查找接收者 的公开密钥。 构造报文的会话密钥部分。 1. PGP PGP报文接收 1. PGP PGP报文接收 解密报文 PGP使用报文会话密钥部分的密钥ID字段作为索引，从私有密钥 环中查找接收者的私有密钥。 PGP提示用户输入口令短语来恢复未加密的私有密钥。 PGP然后恢复会话密钥并且解密报文。 鉴别报文 PGP使用报文签名密钥部分的密钥ID字段作为索引，从公开密钥 环中查找发送者的公开密钥。 PGP恢复传输的报文摘要。 PGP对接收的报文计算报文摘要，将计算的结果与传输过来的报 文摘要相比较以鉴别报文。 1. PGP PGP公开密钥管理的方法 确实地从B得到密钥。B可以将其公开密钥（KUb）存储在软盘上，将 软盘交给A。A可以从这个软盘上将密钥加载到他的系统中。这是非 常安全的方法，但实际运用具有明显的局限性。 通过电话验证密钥。如果A可以在电话上听出B的声音人可以给B打电 话，要求她在电话上以radix-64的形式口述密钥。更加实用的方法是B 可以将她的密钥通过电子邮件传递给A。然后，A可以让PHP生成密 钥的160 bit的SHA-l摘要，并且以十六进制的形式显示，这个摘要被 称为密钥的“指纹”。接下来人可以给B打电话，让她在电话里口述指 纹。如果两个指纹一致，那么密钥就验证过了。 从双方信任的人D那里获得B的公开密钥。介绍人D创建签名的证书， 证书包括B的公开密钥、创建密钥的时间和密钥的合法期限。D生成 这个证书的SHA-1摘要，使用她的私有密钥对其加密，并且将签名附 加在证书上。因为只有D能够创建这个签名，所以没有其他人可以创 建假的公开密钥，并且伪装成经过D的签名。签名的证书可以直接由 B或D发送给A，或者粘贴在公告牌上。 从可信任的认证中心获得B的公开密钥。再一次创建公开密钥证书， 并经过认证中心的签名。A可以访问这个认证中心，提供用户名获得 签名的证书。 1. PGP PGP信任的标注 PGP使用与实体相联系的密钥合法性字段，用来指示PGP信任“ 这是这个用户合法的公开密钥”的程度；信任程度越高，这个 用户ID与这个密钥的绑定越紧密。这个字段是由PGP从这个实 体的一组签名信任字段中推导出来的。 与每个实体相联系的还有密钥环的拥有者收集的，对这个证书 签名的零个或多个签名。 每个签名都带有签名信任字段，用来指示该PGP用户信任签名 者对这个公开密钥证明的程度。 每个实体定义了与特定的拥有者相联系的公开密钥，包括拥有 者信任字段，用来指示这个公开密钥对其他公开密钥证书进行 签名的可信任程度，这个信任程度是由该用户指派的。我们可 以把签名信任字段看成是来自于其他实体的拥有者信任字段的 副本。 1. PGP PGP信任标志字节的内容 (a) 指派公开密钥拥 有者的信 任 （出现在密钥分组之后，用 户定义的） (b) 指派公开密钥/用户ID对的 信任 （出现在用户ID分组之后， 由PGP计算） (c) 指派签名的信任 （出现在签名分组之后，该 签名者的OWNERTRUST的 副本） OWNERTRUST字段 一未定义的信任 一不认识 的用户 一对其他密钥的签名通常不 能信任 一对其他密钥的签名通常可 以信任 一对其他密钥的签名总是可 以信任 一这个密钥出现在秘密密钥 环中（终极信任） BUCKSTOP比特 一如果这个密钥出现在秘密 密钥环 中，置位 KEYLEGIT字段 一不认识 或未定义的信任 一密钥的拥有权不可信任 一密钥的拥有权的少量信任 一密钥的拥有权的完全信任 WARNONLY比特 一如果用户想要系统只是在使 用没有经过 完全验证 的密钥 来加密时才告警，置位 SIGTRUST字段 一未定义的信任 一不认识 的用户 一对其他密钥的签名通常不 能信任 一对其他密钥的签名通常可 以信任 一对其他密钥的签名总是可 以信任 一这个密钥出现在秘密密钥 环中（终极信任） CONTIG比特 一如果签名导致了一条连续 的可信任的通向终极信任密钥 环的拥有者的路径时，置位 1. PGP PGP信任的确定 当A在公开密钥环中插入了新的公开密钥时，PGP必须为与这个公开 密钥拥有者相关联的信任标志赋值。如果拥有者是A，因此这个公开 密钥也出现在私有密钥环中，那么这个信任字段被自动指派终极信任 的值。否则，PGP询问A指派这个密钥拥有者的信任程度的评定，A 必须输入想要的级别。用户可以说明这个拥有者是未知的、不可信任 的、少量信任和完全可信的。 当新的公开密钥输入之后，可以在它上面附加一个或多个签名，以后 还可以增加更多的签名。在实体中插入签名时，H对在公开密钥环中 搜索，查看这个签名的作者是否属于已知的公开密钥拥有者。如果是 ，为这个签名的SIGTRUST字段指派该拥有者的OWNERTRUST值。 否则，指派不认识的用户值。 密钥合法性字段的值是在这个实体的签名信任字段的基础上计算的。 如果至少有一个签名具有终极信任的值，那么密钥合法性字段的值设 置为完全；否则，PGP计算信任值的权重和。对于总是可信任的签名 指派1/X的权重，对于通常可信任的签名指派1/Y的权重，其中X和Y 都是用户可配置的参数。当介绍者的密钥用户ID绑定的权重总和达 到1时，绑定被认为是值得信赖的，密钥合法性值被设置为完全。因 此，在没有终极信任的情况下，需要至少X个签名是总是可信的，或 者至少Y个签名是通常可信的，或者上述两种情况的某种组合。 1. PGP PGP信任模型 1. PGP PGP信任模型讨论 注意到除了结点L以外，所有其拥有者被该用户完全信任或部分信任 的密钥都被该用户签了名。这样一个用户签名并不总是必要的，如同 结点L的存在所指示的，但是实际上大多数用户都想要给自己信任的 用户的密钥进行签名。因此，即使E的密钥已经被一个可信任的介绍 者F签了名，该用户还是选择直接对E的密钥进行签名。 假设两个部分可信的签名足以证明一个密钥，因此用户H的密钥被 PGP认定为合法的，因为它被A和B签了名，后者都是部分可信的。 一个密钥可能由于它被一个完全可信的或两个部分可信的签名人签了 名而被认定为是合法的，但它的用户对其他密钥的签名不可信。例如 ，N的密钥是合法的，因为它被E签了名，而E是用户可信任的；但是 N对其他密钥的签名不可信任，因为用户没有指派N信任值。因此， 尽管R的密钥被N签了名，PGP不认为R的密钥是合法的。这种情况是 非常有意义的。如果你想要给某个人发送私人报文，并不需要你对这 个人的各个方面都信任，惟一需要的是你要确认你有了这个人的正确 的公开密钥。 1. PGP PGP信任模型讨论(续) PGP信任模型也显示了分离的“孤儿”结点S的例子，该结点带 有两个未知的签名。这样的密钥可能是从密钥服务器上获得的 。PGP不能简单地认定这个密钥的合法性，因为它来自于知名 的服务器。用户必须通过签名来声明密钥的合法性，或者告诉 IMP密钥的签名者是完全可信赖的。 1. PGP PGP废除公开密钥 废除公开密钥的常规方法是拥有者发出密钥废除证书，该证书必 须经过拥有者的签名。这个证书和一般的签名证书的格式一样 ，但是包括了表示该证书的目的是为了废除这个公开密钥使用 的指示。请注意必须使用对应的私有密钥对这个废除公开密钥 的证书签名。拥有者接着应该尽可能快和尽可能广地散布这个 证书，使得潜在的对应方都能够修改他们的公开密钥环。 请注意已经获得拥有者私有密钥的对手也可能发出这样的证书。 但是，这会使得这个对手和合法的拥有者一样不能使用该公开 密钥，因此，这看起来比恶意使用被偷私有密钥的威胁要小得 多。 2. S/MIME 简介 SMIME（安全通用Internet邮件扩充SecureMultipurpose Internet Mail Extension）是基于RSA数据安全技术的、MIME Internet电子邮件格式标准的安全扩充。 尽管PGP和SMIME都在IETF标准化的过程当中，但是S MIME可能作为商业和组织使用的工业标准而出现，而PGP对 大多数用户来说，仍然作为个人安全电子邮件的选择。 目前，S/MIME已在IEFT中得到了标准化，具体可见RFC和RFC 文档。 2. S/MIME 功能 加密的数据：对于一个或多个接收者来说，这是由任意类型的 加密内容和加密内容的加密密钥组成的。 签名的数据：通过取得要签名的内容的报文摘要，然后使用签 名者的私有密钥对该摘要进行加密形成数字签名。接着，内容 和签名使用radix-64编码方法进行编码。签了名的数据报文只 能被具有SMIME功能的接收者看到报文的内容。 清澈签名（Clear-signed）的数据：和签名数据一样，形成内容 的数字签名。但是，这种情况只有数字签名部分使用radix-64 进行了编码。因此，没有SMIME功能的接收者可以看到报 文的内容，尽管它们不能验证签名。 签名并且加密的数据：只签名和只加密的实体可以递归使用， 因此加密的数据可以被签名，签名或清澈签名的数据可以被加 密。 2. S/MIME 加密算法 功能需求 创建用于形成数字签名的报文摘要必须支持SHA-1和MD5 应该 使用SHA-1 加密报文摘要以形成数字签名发送和接收代理必须支持DSS 发送代理应该 支持RSA加密 接收代理应该 支持使用长度为512到1024比特的 密钥来验证 RSA的签名 加密会话密钥和报文一起传输发送和接收代理必须支持Diffie-Hellman 发送代理应该 支持使用长度为52比特到1024比 特的密钥的RSA加密 接收代理应该 支持RSA解密 使用一次性会话密钥来加密传输 的报 文 发送代理应该 支持三元组DES和RC2/40的加密 接收代理应该 支持三元组DES的解密，必须支持 RC2/40的解密 2. S/MIME 发送代理规则 如果发送代理从它想要的接收者那里获得了解密能力的列表， 它应该选择能使用的列表的第一个（最高优先级）能力。 如果发送代理没有它想要的接收者的这样的能力清单，但曾经 从接收者那里收到过一个或多个报文，那么输出的报文应该使 用和从那个接收者那里接收的最后一个签名和加密报文所使用 的同样的加密算法。 如果发送者没有它想要的接收者解密能力的任何知识，并且愿 意冒着接收者可能不能解密报文的危险，那么发送代理应该使 用三元组DES。 如果发送者没有它想要的接收者解密能力的任何知识，并且不 愿意冒着接收者可能不能解密报文的危险，那么发送代理必须 使用RC240。 如果报文需要发送给多个接收者，但却不能选择共同的加密算 法，那么发送代理将需要发送两个报文。然而，需要注意的是 在这种情况下，报文的安全性依赖于低安全性的报文的一个副 本的传输。 2. S/MIME S/MIME报文类型 类型子类型S/MIME参数描述 MultipartSigned清澈签名的报文分成两个部分： 一个是报文部分，另一个是签名 部分 Applicatio n pkcs7-minesignedData签名的SMIME实体 pkcs7-mineenvelopedDat a 加密的SMIME实体 pkcs7-minedegenerste signedData 只包含了公开密钥证书 的实体 pkcs7-signature多部分签名报文的签名子部分 的内容类型 pkcs10-mine证书注册请求报文 2. S/MIME MIME实体安全化 SMIME使用签名、加密或同时使用两者来保证MIME实体的安 全。 一个MIME实体可能是一个完整的报文（除了RFC 822首部）， 或者是多部分MIME内容类型的一个或多个子部分。MIME实 体按照MIME报文准备的一般规则来准备。然后，该MIME实 体加上一些与安全有关的数据，如算法标识符和证书，被S MIME处理以生成称为PKCS的对象。然后PKCS对象被看作报 文内容并包装成MIME（提供合适的MIME首部）。 在所有情况下，称为对象的报文实体都用ITU-T Recommndation X.209建议书定义的基本编码规则（BER）来表示。BER格式 是由任意的八位组字符串组成的，因此是二进制数据。这样一 个对象在外部的MIME报文中应该使用radix-64编码转换。 2. S/MIME envelopedData（包装数据）操作 为特定的对称加密算法（RC240或三元组DES）生成伪随机 的会话密钥。 对每个接收者，使用接收者的公开RSA密钥对会话密钥进行加 密。 为每个接收者准备称为RecipientInfo（接收者信息）的数据块 ，该块中包含了发送者的公开密钥证书。用来加密会话密钥算 法的标识以及加密的会话密钥。 使用会话密钥加密报文的内容。 RecipientInfo块后面跟着加密的内容组成了包装数据。然后使 用radix-64对这个信息编码。 2. S/MIME envelopedData（包装数据）示例 Content-Type: application/pkcs7-mime; smime-type=enveloped-data; name=smime.p7m Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename=smime.p7m rfvbnj756tbBghyHhHUujhJhjH77n8HHGT9HG4VQpfyF467GhIGfHfYT 6 7n8HHGghyHhHUujhJh4VQpfyF467GhIGfHfYGTrfvbnjT6jH7756tbB9 H f8HHGTrfvhJhjH776tbB9HG4VQbnj7567GhIGfHfYT6ghyHhHUujpfyF 4 0GhIGfHfQbnj756YT64V 2. S/MIME signedData（签名数据）操作 选择报文签名算法（SHA或MD5）。 计算需要签名内容的报文摘要或散列函数。 使用发送者的私有密钥加密报文摘要。 准备称为SignerInfo（签名者信息）的数据块，该块中包含了 签名者的公开密钥证书、报文摘要算法的一个标识符、用来加 密报文摘要算法的标识符以及加密的报文摘要。 签名数据实体由一系列块组成，包括报文摘要算法标识符、被 签名的报文和SignerInfo。签名数据实体还可以包括公开密钥 证书的集合，该集合足以组成一条从一个可识别的根或最上级 的认证中心到签名者的链。然后使用radix-64进行编码。 2. S/MIME signedData（签名数据）示例 Content-Type: application/pkcs7-mime; smime-type=signed-data; name=smime.p7m Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename=smime.p7m 567GhIGfHfYT6ghyHhHUujpfyF4f8HHGTrfvhJhjH776tbB9HG4VQbn j7 77n8HHGT9HG4VQpfyF467GhIGfHfYT6rfvbnj756tbBghyHhHUujhJh jH HUujhJh4VQpfyF467GhIGfHfYGTrfvbnjT6jH7756tbB9H7n8HHGghy Hh 6YT64V0GhIGfHfQbnj75 2. S/MIME 清澈签名（Clear Signing）操作 清澈签名是通过带有签名子类型的多部分内容类型来实现的。如 同曾经提到的那样，这个签名过程没有涉及到转换签名报文的 形式，因此报文以一种“清澈的”形式发送。从而使得具有 MIME能力但没有SMIME能力的接收者能够阅读输入的报文 。 多部分签名的报文有两个部分。第一部分可以是任何MIME类 型，但必须准备报文使得它在从源到目的地的传输中不被修改 。这就意味着如果第一部分不是7 bit的，那么需要使用base-64 或者加引号的可打印（quoted-printable）进行编码。然后这一 部分按照和签名数据一样的方式来处理，但是在这种情况下创 建了空报文内容字段的签名数据格式的对象，这个对象是分离 的签名。然后使用base-64对它进行传送编码，成为多部分签 名报文的第二部分。这个第二部分有一个应用的MIME内容类 型和一个phes7-signature和子类型。 2. S/MIME 清澈签名（Clear Signing）示例 Content-Type: multipart/signed; protocol=“application/pkcs7-signature“; micalg=sha1; boundary=boundary42 -boundary42 Content-Type: text/plain This is a clear-signed message. -boundary42 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename=smime.p7s ghyHhHUujhJhjH77n8HHGTrfvbnj756tbB9HG4VQpfyF467GhIGfHfYT6 4VQpfyF467GhIGfHfYT6jH77n8HHGghyHhHUujhJh756tbB9HGTrfvbnj n8HHGTrfvhJhjH776tbB9HG4VQbnj7567GhIGfHfYT6ghyHhHUujpfyF4 7GhIGfHfYT64VQbnj756 -boundary42- 2. S/MIME 注册请求（Registration Request） 典型的情况是应用或用户要向证书管理机构申请公开密钥的证书 。Applicationpkcs10 SMIME实体是用来传送证书请求的。