网络安全与信息加密技术-第十九章剖析

《网络安全与信息加密技术-第十九章剖析》由会员分享，可在线阅读，更多相关《网络安全与信息加密技术-第十九章剖析（60页珍藏版）》请在金锄头文库上搜索。

1、q事实上，在所有的分布式环境中，电子邮件是最繁重的网络 应用。无论双方使用何种操作系统和通信软件，用户都希望 能够直接或间接与Internet连接着的对方发送电子邮件。 随着对电子邮件依赖性的爆炸式增长，认证性和保密服务 需求也在日益增长。两种被广泛应用的方法：PGP和 S/MIME脱颖而出。本章将阐述这两种方法。 第19章 电子邮件 主要由Phil Zimmermann提出的PGP提供了可用于电子邮件和文 件存储应用的保密性和认证性。基本上，Zimmermann做了如下 工作： q1.在构建数据块时，选用了最合适、可用的密码算法。 q2.将这些算法整合到通用应用程序中，这些应用程序独立于不

2、同操作系统和处理器，并且是基于一个小规模的易用指令集。 q3.将其制作成软件包并形成文档，包括源代码。这些资源都可 以通过Internet，广告牌和诸如AOL(America On Line)的商 用网络免费获取。 q4.与Viacrypt(现在的Network Associates)公司达成协议， 提供完全兼容、低成本的商用版PGP。 19.1 PGP 第19章 电子邮件 PGP的应用迅速普及，呈爆炸式增长。其原因大致可归纳如下： q1.提供了在世界范围内的各种免费可用的版本，可运行于各种 平台，包括Windows，UNIX，Macintosh等。另外，其商 用版满足了用户的需求并获得了商家

3、的支持。 q2.使用的算法是经过广泛的使用检验并被认为是非常安全的算 法。值得指出的是，这个软件包中包含了用于公钥加密的RSA ，DSS和Diffie-Hellman算法，用于对称加密的CAST-128， IDEA和3DES算法以及用SHA-1做Hash编码。 q3.应用范围广泛，即可用于公司选择和增强加密文件与消息的 标准化模式，也可用于个人通过Internet或其他网络进行安全 通信。 q4.不是由政府或者是标准化组织开发或控制。对那些本能地对 上述“组织”有不信任的人们来说，PGP非常有吸引力。 19.1 PGP 19.1 PGP 19.1 PGP 2. 操作描述 q与密钥管理相对应，P

4、GP的实际操作由4类服务组成：认证、 保密、压缩和电子邮件兼容性如下表所示： q下面我们一一介绍。 19.1 PGP 认证： q下图描述了PGP提供 的数字签名服务。该数字签名方案在第 13章讨论过。 认证过程如下： q1.发送方生成消息。 q2.用SHA-1算法生成消息的160位Hash码。 q3.用发送方的私钥按RSA算法加密该Hash码并将结果预先加 入到消息中。 19.1 PGP q4.接收方用发送方的公钥按RSA算法解密消息并回复Hash 码。 q5.接收方对该消息用相同的Hash函数生成新的Hash码，并比 较该Hash码与解密得到的Hash码，如果两者吻合则该消息为 可信的。 S

5、HA-1和RSA的结合提供了一个高效的数字签名方案。鉴于RSA 的安全强度，接收者可以确信如果是不同的消息必定无法生成与该 Hash码匹配Hash值。于是保证了原消息签名有效。 19.1 PGP qDSS/SHA-1也是生成数字签名的可选方案。 q尽管通常情况下签名都会附在消息或者是文件中，但也不尽然 ：签名也可以被分离出来。一个分离式签名可能会被同对应的 消息分开存储或传输。这在一些情形下是有用的，例如某用户 可能希望能为所有发送或接收到的消息的各分离式签名建立并 保持一个日志。一个可执行程序的分离式签名可用来甄别该程 序是否被病毒感染。另外，分离式签名还可以用于多个成员对 一份注入合法契约

6、等文件进行签名，每一个成员的签名都是独 立的并且只用于该文件，否则签名可能会被嵌套，例如第二个 成员会对文档和第一个成员生成的签名进行签名等。 19.1 PGP 保密： qPGP提供的另一个服务是保密，这是通过对传输的消息或者是 本地存储的文件进行加密来实现的。在如上两种情形下对称加 密算法(CAST-128)是可用的。同时，IDEA和3DES也是也用 的。使用64位密文反馈模式(DFB)。 19.1 PGP 通常，设计加密时必须讨论密钥分配的问题。在PGP中，每一个对 称密钥都只使用一次，这意味着对每一个消息都会随机生成一个 128位的自然数用作新密钥。因此， 尽管这在标准文档中是指会话 密

7、钥，其实是一次性密钥。因为它只是用一次，所以会话密钥会和 消息绑定并随之一起传输。用接收者的公开密钥加密以保护该会话 密钥如上图所示。用文字描述如下： q1.发送者生成消息和仅用于加密该消息的会话密钥，该会话密 钥为128位随机自然数。 q2.采用CAST-128(或IDEA或3DES)算法，使用该会话密钥加 密消息。 q3.采用RSA算法，用接收者的公开密钥加密该会话密钥并预先 发送给对方。 19.1 PGP q4.接收者采用RSA算法，用自己的私钥解密并恢复会话密钥。 q5.用会话密钥解密消息。 作为用于对密钥进行加密的RSA算法的替换，PGP还提供了Diffie -Hellman算法作为

8、选择。正如第10章中所介绍的那样，Diffie- Hellman是一个密钥交换算法。事实上，PGP使用了大量的Diffie -Hellman来提供加/解密。 19.1 PGP q上述过程中我们会发现一些问题。首先，为了减少加密时间， 对称加密和公钥加密的结合在效率上优于仅仅使用RSA或者 ElGamal直接对消息进行加密：CAST-128和其他对称加密算 法远快于RSA或ElGamal。其次，公钥算法的使用解决了会话 密钥分配的问题，因为只有接收者才能还原与消息绑定的会话 密钥。值得注意的是，在这里我们不需要使用像在第14章中讨 论的会话密钥交换协议，因为我们不会从正在进行的会话中开 始，而是

9、对每一个消息都是用独立的一次性密钥。此外，鉴于 电子邮件存储转发的特性，使用握手协议来确保通信双方拥有 相同的会话密钥也是不切实际的。最后，使用一次性对称密钥 也使原本安全强度较高的对称加密方法更安全。每一个密钥都 只加密少量的明文，并且密钥与密钥之间没有任何关联。因此 ，在某种意义上说只要公钥算法是安全的，那么整个方案就是 安全的。 19.1 PGP q同时，PGP为用户提供了密钥长度从768位到3072位范围之 间的选择(用于数字签名的DSS密钥限制在1024位)。 保密性和认证性： q如上图所描述，保密性和认证性这两种服务可能会对同一个消 息使用。首先，生成一个明文的签名，然后用CAST

10、-128(或 IDEA或3DES)对明文消息和签名进行加密，然后用RSA(或 ElGamal)对会话密钥加密。这个流程比先加密消息然后生成 密文的签名的过程要好。这样更便于保存明文消息的签名。 19.1 PGP 19.1 PGP 1.生成签名在压缩之前进行是由于如下两个原因： qa.对未压缩的消息进行签名更有利于仅存储未压缩消息和签名 以便未来的签名验证。假如压缩后对文档签名，那么必须要么 存储消息的一个压缩版或者是当需要时对消息重新压缩以便验 证签名。 qb.即使有用户愿意为验证签名动态的生成消息的压缩版，PGP 的压缩算法也表现出不合适。因为该算法是不确定的，在运行 速度和压缩比之间权衡时

11、会产生该算法各种不同形式的实现。 但是，这些不同的算法实现是可以同时使用的，因为该算法的 任何版本都可以正确的解压缩任何其他版本的压缩文件。在 Hash函数和签名之后使用可以使所有的PGP实现都统一使用 一种版本的压缩算法。 2.在压缩之后对消息进行加密是为了增强密码运算的安全性。因为 压缩后的消息比原明文的信息冗余少，这让密码分析更加困难。 19.1 PGP q所使用的压缩算法ZIP将在附录0中有介绍。 电子邮件兼容性： q当使用PGP时，数据块中至少被传输的那部分会被加密。假如 使用了数字签名服务，那么消息的摘要会用发送者的私钥加 密。假如使用了保密服务，那么消息和签名(如果有签名的话)

12、会用一次性对称密钥加密。因此，数据块的整体或部分会由任 意的8字节流组成。但是大多数的电子邮件系统都只允许使用 由ACSII文本组成的数据块。为了适应限制，PGP提供了将原 字节流转换成可打印的ASCII字符流的服务。 qRadix-64就是用于该目的的解决方案。每三个字节组成的二 进制数据可以映射成四个ASCII字符。这种格式也附加了CRC 校验码用来检查传输错误。 19.1 PGP 19.1 PGP q下图显示了到目前为止讨论的4种服务之间的关系。 19.1 PGP q在传输方，假如需要可以生产一个明文的Hash码用作签名。 然后压缩明文(如果有签名就加上签名)。接着，如果有保密性 要求，

13、这个数据块(压缩了的明文或者是压缩了签名和明文的 集合)就用对称密钥加密，而该对称密钥则是预先用公钥加密 的。最后，将整个数据块转换成Radix-64格式。 q在接收方，首先把接收到的数据块由Radix-64格式转换成二 进制。然后，假如消息是加密的，那么接收者就用自己的私钥 恢复出会话密钥并用会话密钥解密消息。然后把得到的结果解 压。假如消息是签名的，那么接收者就恢复出传输过来的 Hash码并且与自己计算的Hash码进行比较。 19.1 PGP qS/MIME(Secure/Multipurpose Internet Mail Extension)是对基于RSA数据安全的MIME Inter

14、net电子邮 件格式标准的安全性增强。尽管PGP和S/MIME都是IETF工 作组推出的标准，但是S/MIME倾向于推广为商业或组织用于 的工业标准，而PGP则用来为个人电子邮件安全提供服务选 择。S/MIME在很多的文档中被定义了，其中最重要的是RFC 3370,3850, 3851和3852。 q为了理解S/MIME，我们首先得对其使用的电子邮件格式(即 MIME)有一个大概的理解。但是为了理解MIME的重要性，又 将回到传统的电子邮件格式标准(RFC 822)，而该标准仍然广 泛使用。最新版本的格式规范是RFC 5322(Internet消息格 式)。因此，本节将首先介绍那两个较早的标准

15、然后再开始讨 论S/MIME。 19.2 S/MIME 第19章 电子邮件 1. RFC 5322 qRFC 5322定义了用电子邮件发送的文本消息的格式。这已经 是基于Internet的文本邮件消息的标准并且仍然在广泛使用。 在RFC 5322中，消息被视为一个信封和内容的组合。信封包 含了任何用来完成传输和发送功能的信息。内容则构成了发送 给接收者的对象。RFC 5322标准关注的是内容部分。但是， 内容标准包含了一系列头域，这些头域是由邮件系统用来生成 信封的，而该标准也致力于使程序获取头域信息更方便。 q符合RFC 5322的消息的大体结构非常简单。一个消息包含了 若干行的头部(the

16、 head)和随后的无限制的正文(the body) 。头部和正文中间用一空行隔开。另外，消息是ASCII文本， 第一个空行之上的所有行都是邮件系统中用户代理部分使用的 头部行。 19.2 S/MIME q头部行通常包含关键字、冒号和关键字的参数，该格式允许将 一个长行分割成若干短行。使用最频繁的关键字是From，To ，Subject和Date。例如： q在RFC 5322中常见的另一个域是消息标志(Message-ID)， 该域包含一个与该消息关联的唯一标志符。 19.2 S/MIME 2. MIME MIME是RFC 5322的扩展，目的是解决一些因使用简单邮件传输 协议(SMTP，在RFC 821中定义)或其他一些邮件传输协议而产生 的限制。参考文献列出了SMTP/5322方案的限制。 q1.SMTP不能传输可执行文件和其他二进制对象。SMTP邮件 系统使用了很多用来将二进制文件转换为文本格式的方案，包 括闻名的UNIX UUencode/UUdecode方案。但是，没有一 个成为标准或者事实上的标准。 q2.SMTP不能传输含有国际语言字符的文本数据，因为这