枫林在线论坛精华区>>信息安全

[30634] 主题： 互联网上的密码术（转贴）

	作者： leaflet (Leaf闭关中…)
	标题： 互联网上的密码术（转贴）
	来自： 61.151.*.*
	发贴时间： 2002年12月04日 12:03:23
	长度： 10936字
	出处 http://chinasmile.infopop.net/0/OpenTopic?a=tpc&s=10009 2507&f=8580923432&m=6200966435     因特网引入了大量与以往不同的安全性弱点。您正在与之通信的组织或个 人可能是您不认识的或者可能是伪装成其他组织（个人）的组织或个人。 不必过分猜疑这类问题，但有必要采取适当的预防措施来防止通过各种方 式造成的损失，这些方式包括资金转移、错误认证的结果、机密信息丢失 、毁约等。密码术就是主要处理这类风险的，本文介绍了某些协议和相关 机制，这些协议和相关机制与因特网活动（包括，电子邮件）有特定的相 关性。 与因特网相关的协议和机制 请求注释（Request for comment (RFC)） 请求注释是由因特网网络工程任务组（IETF）管理的正式因特网文档，它 用作传播有关因特网工程咨询和意见信息的一种方式。RFC 描述了开放标 准，使那些可能希望或需要使用那些标准进行通信的人受益。它们是由参 与不同工作组的志愿者编写的，发布在不同位置上，特别在 IETF 站点上 。有关 TLS 的详细信息（请参阅下面的描述）就是以这种格式表示的。 IPSec IETF 的 IP 安全性协议工作组目前正在定义 IP 的安全性附加协议，它是 为 IP 数据报这一层提供认证、完整性和保密性服务的规范。在几个 RFC  中对它都有描述，虽然是想专门用于 IP v.6.0 的，但它也可以用于 IP  v. 4.0（IP v. 4.0 是当前标准，使用点分四组形式的地址，如 192.16 8.1.3）。它旨在用作对因特网通信（例如，为 VPN 和封装隧道等）提供 安全性的基础。一些供应商和软件组织正在开发或提供集成了 IPSec 的产 品。例如，芬兰的 SSH Communications Security 有一种称为 IPSec Ex press 的产品，它是为方便符合 IPSec 的电子商业应用程序开发而设计的 ，而从 1999 年 6 月开始，NetBSD Foundation 已经将 IPSec 代码合并 到了 NetBSD 分发版中。  虽然 IPSec 已经成为因特网安全性实现的一个事实上的标准，但却受到来 自 Niels Ferguson 和 Bruce Schneier（后者是被广泛关注的 Blowfish  密码的设计者）等人的批评。Ferguson 和 Schneier 认为 IPSec 已经变 得过度复杂并趋于难以管理。他们说，这里的问题是：对 IPSec 进行的内 容增加并没有以期望的方式增强该产品，而是为了满足表达出来的广泛兴 趣的愿望和期望。他们不合时宜地将这种方法与 NIST 采用的方法进行对 照以便选择一种新的安全性算法来代替 DES，在有关对称密码术的文章（ 第 2 部分）中对此作了描述。  他们的结论是：IPSec 比以前任何安全性协议都好得多，但声称其设计中 固有的复杂性已经导致了大量模糊、矛盾、低效和其它一些弱点，并产生 了极其难懂的一套规范，结果他们怀疑它是否能生成一个真正安全的操作 系统。他们提出了许多具体的建议，但承认文档的拙劣质量和协议的过度 复杂性意味着他们没有完全理解系统，这是对其经验和权威的极大挑战。 正如他们指出的，让 90% 的安全性起作用是不行的。坦率地说，他们十分 不满意使用当前形式的 IPSec，但更强烈地反对当前任何其它协议。因此 ，当这些其它协议不能保护网络的安全时，他们还是建议使用 IPSec。  安全 HTTP（Secure HTTP (S-HTTP)） 安全 HTTP（S-HTTP）是在应用层运行的 HTTP 安全性扩展。它旨在当支持 不可抵赖性以及允许使用多种密码算法和密钥管理机制的同时，提供保密 性和认证。虽然可以在会话之前获得经 Kerberos 服务器同意的初始密钥 ，或者可以在一个会话中生成下一个会话要使用的密钥，但通常将 RSA 用 于初始密钥协商。  安全套接字层（Secure Sockets Layer (SSL)） 安全套接字层（SSL）是由 Netscape Communications 开发的用来向因特 网会话提供安全性和保密性的握手协议。它支持服务器和客户机认证，并 且被设计成协商加密密钥以及在交换任何数据之前认证服务器。它使用加 密、认证和 MAC 来维护传输信道的完整性。  虽然 SSL 最适合用于 HTTP，但它也可以用于 FTP 或其它相关协议。它在 传输层运行并且是独立于应用程序的，因此象 FTP 或 HTTP 之类的相关协 议可以放在该层之上。使用初始握手来对服务器进行认证。在这一过程中 ，服务器把证书提交到客户机并指定要使用的首选密码。然后，客户机生 成在即将进行的会话期间使用的秘钥，然后将它提交给服务器，并相应地 用服务器的公钥对它加密。服务器使用其私钥解密消息，恢复秘钥，然后 通过向客户机发送一条使用该秘钥加密的消息来向客户机认证自己。使用 这一达成协议的秘钥对加密的数据进行进一步的交换。 可以用第二阶段（可选）来进一步增加安全性。这里，服务器发送一个质 询，客户机对此作出响应，向服务器返回该质询的数字签名和客户机的公 钥证书。 质询阶段通常是使用带有用于消息摘要的 MD5 的 RSA 执行的。也可以使 用各种对称密码，包括 DES、三重 DES、IDEA、RC2 和 RC4。公钥证书符 合 X.509 标准。SSL 目前的版本为 3.0。  SSL 先前的历史给出了一个有关密码产品的对等复查重要性的警告，特别 是 Ian Goldberg 和 David Wagner（两名加州大学的博士研究生）在 Dr  Dobb's Journal 1996 年 2 月刊中写了一篇文章，说明了他们是如何破 解加密系统然后使用它的。  因为在那时，Netscape 不想发布关于 SSL 的结构或 SSL 所使用的密码术 和其它方法的任何信息，Goldberg 和 Wagner 对相关算法运用了逆向工程 。他们发现用来生成伪随机数（并由此随机数生成秘钥）的种子取决于日 期、进程标识和父进程标识。获取这两个标识相对容易，至少对于在运行 浏览器的 UNIX 机器上有帐户的任何用户来说是这样。嗅探器用一秒钟就 可以完成信息包的收集。该信息将可能的种子的数目降低为一百万，然后 使用 HP 712/80 可以在不到半分钟的时间内完成这些值的破解。 使用计算机生成一个真正的随机值是很困难的，因此需要随机数的程序将 以尽可能随机的方式生成一个种子，然后使用伪随机数发生器（PRNG）从 这个种子生成一个伪随机数。然而，使用特定 PRNG 的同一种子将产生相 同的数，该数被相应地用于加密体制算法中，它将产生相同的密钥。这对 于它本身并不是弱点，但使原始的种子尽可能随机地生成却非常重要。应 用程序通常会遇到非常难以预料或重复的事件，例如，芯片中的随机电子 噪声、有噪声的二极管、某个磁盘驱动器的运转、用户击键或者鼠标移动 等。在这种特殊情况下，乍看，使用三个元素来创建种子是合理的，并且 刚开始的设计人员明显也是这样做的，但是进一步的分析却揭示了一些局 限性。请别人来为这类机制挑刺恰恰是对等复查的价值所在，如果一个系 统最终被认为是良好的，这一点很关键。  传输层安全性（Transport Layer Security (TLS)） 传输层安全性（TLS）协议是 IETF 标准草案，它基于 SSL 并与之相似。 它的主要目标是在两个正在通信的应用程序之间提供保密性和数据完整性 。它由两层构成。较低的层称为 TLS Record 协议，且位于某个可靠的传 输协议（例如，TCP）上面。这一层有两个基本特性，具体说该连接是专用 的并且是可靠的。它用于封装各种更高级协议，但也可以不加密地使用。 通常使用加密时，生成的用于这个加密的秘钥专用于每个连接，这些秘钥 基于由另一个协议（例如，更高级别的 TLS Handshake 协议）协商的秘钥 。  TLS Handshake 协议提供了具有三个基本特性的连接安全性，即可以使用 非对称密码术来认证对等方的身份，共享密钥的协商是安全的，以及协商 是可靠的。  与 SSL 一样，TLS 是独立于应用程序协议的，其使用的加密算法的种类与  SSL 使用的相似。然而，TLS 标准把如何启动 TLS 握手和如何解释认证 证书的决定权留给运行于其上层的协议的设计者和实现者来判断。  TLS 协议的目标，按其优先级顺序来说，是密码安全性、互操作性和可扩 展性。最后一个目标意味着 TLS 提供了一种框架，当新的和改进的非对称 以及其它加密方法可用时，便可以将它们引入该框架。  无线传输层安全性（Wireless Transport Layer Security (WTLS)） 无线应用程序协议（Wireless Application Protocol (WAP)）体系结构中 的安全性层协议称为无线传输层层安全性（Wireless Transport Layer S ecurity (WTLS)）。它在传输协议层之上操作，它是模块化的，是否使用 它取决于给定应用程序所需求的安全性级别。WTLS 为 WAP 的上一层提供 了保护其下的传输服务接口的安全传输服务接口。另外，它为管理安全连 接提供了一个接口。  WTLS 与 TLS 非常相似，但它最适合用于等待时间相对长的窄带传输网络 。但是，它添加了一些新特性，例如，数据报支持、经过最优化的握手和 密钥刷新。与使用 TLS 一样，它的主要目标是在两个正在通信的应用程序 之间提供保密性、数据完整性和认证。 安全电子交易（Secure Electronic Transaction (SET)） 安全电子交易（SET）协议是由 VISA 和 MasterCard 国际财团开发的作为 在开放网络上的进行安全银行卡交易的方法。它支持 DES 和三重 DES 以 实现成批数据加密，并支持用 RSA 对秘钥和银行卡号的公钥进行加密。 虽然 SET 被认为是非常安全的，但太安全使它的速度相对很慢。另外，用 户需要正确发出的数字证书，因此不能象 SSL 或 TLS 那样以一种简单的 特别方式来使用它。由于这些原因，以及许多银行将风险和银行卡安全性 漏洞的后果转嫁给其商业客户，所以 SET 的采用远没有开始设想的那么多 ，这是个问题。然而，有迹象表明这正在改变。  安全广域网（Secure Wide Area Network (S/WAN)） 安全广域网倡议是由 RSA Data Security 推动的，它旨在促进基于因特网 的虚拟专用网（Internet-based Virtual Private Networks (VPN)）的广 泛部署。S/WAN 支持 IP 级的加密，因此它比相似的 SSL 或 TLS 提供了 更基本的、更低级别的安全性。VPN 是一种机制，设计成当用户使用因特 网时，允许他们维护他们之间的安全隧道。例如，可以廉价地连接远程办 公室，而不会增加成本，或者避免使用专门租用线路造成点对点的不便。 对通过通道传递的消息进行了加密，因此它们应该是安全的，可以避免第 三方的有效截获。实际上，并且部分由于不同标准的开发被设计成为一个 或另一个公司带来有竞争力的利益，造成理论和实践严重脱节，尤其在互 操作性方面。S/WAN 倡议是给产生的混乱带来一些秩序的一种尝试。  虽然原始的 S/WAN 倡议不再进行了，但是在 Linux FreeS/WAN 和虚拟专 用网协会（Virtual Private Network Consortium）倡议中有非常相似的 倡议。FreeS/WAN 是 IPSec （请参阅前面的描述）在 Red Hat Linux 中 的实现，并有效地按照 GNU GPL 下提供了可以自制的 Linux 的 VPN 实现 。  安全 Shell（SSH） 安全 Shell（SSH）是目前正在由 IETF 的 SECSH 工作组标准化的协议。 它允许网络上的安全远程访问。可以使用多种方法来认证客户机和服务器 并在支持 SSH 的系统之间建立加密的通信通道。然后，这个连接可以用于 许多方面，例如，建立 VPN 或者在服务器上创建安全远程登录以替换类似 的 telnet、rlogin 或 rsh。 加密的电子邮件 为何提到加密的电子邮件呢？在许多情况下，它并没有什么不同，但是用 户应该理解，发送明文电子邮件等于发送一张任何人都可读的明信片。电 子邮件在一条不确定的、分段路由上传输，并且在沿途的许多点可以毫不 费力地查看它。部分时间内，它保存在网络邮件服务器的半公开区域或 I SP 的存储器中。电子邮件还可能被错误路由或错误地成批发送：Network  News 期刊中收录了一名网络经理的文章，他误将一张在他的头像旁写有 “I am very munchable”（我很能吃）的图象发送到了办公楼里的每台打 印机，这个图象原本是作为他妻子的私人 T-恤衫上的消息。那当然不是电 子邮件，但是电子邮件也很容易发生这样的问题，而且同样会造成尴尬。 许多产品提供安全电子邮件，该电子邮件要么作为使用 PGP（Pretty Goo d Privacy (PGP)，后面的文章中会详细讨论）的补充产品提供，要么使用 如安全 MIME (S/MIME) 之类的协议将数字签名和加密工具添加到使用适当 的客户机（例如，Netscape）创建的邮件消息中。MIME（多用途因特网邮 件扩展 (Multipurpose Internet Mail Extensions））是一种因特网邮件 标准化的格式，它允许以标准化的格式在电子邮件消息中包含增强文本、 音频、图形、视频和类似的信息。然而，MIME 不提供任何安全性元素 —  S/MIME 添加了这些元素。S/MIME 已经得到了许多联网和消息传递 ISV  的认可，包括 Netscape、Qualcomm、Microsoft、Lotus、Novell 以及其 它 ISV。可以从 IETF 获取信息。  然而，将加密的电子邮件引入大型组织会引起一些新问题。反病毒产品可 能未必一定识别加密的危险附件。另外，扫描程序和防火墙（其工作可能 是确保阻止机密或非法信息出入组织或部门）也可能有相似问题。 一种解决方案可能是在外部网关上加密和解密，但这会使电子邮件在通过 公司网络传输时保持未加密状态，这可能不太合适。在任何情况下，无论 正在使用何种电子邮件客户机，许多电子邮件加密包作为这些客户机的附 属工具在桌面级别工作。但是，通过分散特定内容安全性策略，在桌面扫 描会使问题更复杂和难以强制执行。另一个选项 — 通常是笨拙和耗费资 源的，但在某些环境中却是适当的 — 可能是仅在将电子邮件的副本发送 到集中式邮箱以进行解密和检查的同时，才允许使用加密的电子邮件；这 里的困难包括流量加倍、消息传递延迟、需要实时告知用户实际情况以及 可能给用户带来的不便。Giga Group 在最近的一次讨论中提出了该问题， 建议最满意的解决方案是加密的电子邮件，然后发送到中继器；在那里， 对其解密，并进行检查以确定是否符合安全性策略以及有无病毒，为既定 收件人进行加密，然后适时地重新发送。和以往一样，最好的方法取决于 权衡风险与所提解决方案的成本和不便。
	========== * * * * * ==========

返回