哪些人可以通过认证得到信任?
|
级别: 初级 Larry Loeb, 作家, 安全电子交易 2001 年 12 月 01 日
XML 签名有一个 W3C 候选方案,它看上去非常象最终方案,但这项工作仍处于进展中,并在本文写作时还未正式提升到“草稿标准(Draft Standard)”阶段(请参阅 参考资料 )。 “因特网工程工作组(Internet Engineering Task Force (IETF))”称它为 RFC 3075。据这个候选方案的作者列表上的作者(包括 W3、MIT 和 Microsoft 的人员)判断,因特网行业显然正在严肃地考虑这一问题。
依照 RFC,设计的 XML 签名带有多个目标,可提供“对任何数据类型的完整性、消息认证、和/或签名者认证服务, 无论是在包括该签名的 XML 内部还是在别处。 ”(我加粗了后半句话是因为如果采用并实现候选方案,它对于因特网的工作方式将有重大意义。稍后将详细说明。)这些目标自然雄心勃勃,并且如果放在上下文中考虑,涉及面也很广泛。这些签名及其相关过程有一个终极目标,通过使用 XML,为 Web 提供基于服务器的缺省基本安全性服务。 然而,作者们只理解其工作的一部分。候选方案包含这样一段:“XML 签名……没有规范地指定如何将密钥与个人或社会团体相关联,也没有指定正在引用并签名的数据的含意。 因此,虽然这个规范是安全 XML 应用程序的重要组成部分,但它本身不足以处理所有应用程序安全性/信任事宜,特别在有关将已签名的 XML(或其它数据格式)用作人与人之间通信和协议的基础方面。这种应用程序必须指定附加密钥、算法、处理和再现需要。”简而言之,作者们正在告诫人们,不要将这项工作视作技术上的万能药;必须在其它安全性措施中使用它。这一点很明智,但回避了 XML 幕后是什么这个实质问题。
这里还有一个隐含的假设,作一些检验就会发现这相当明显。XML 既基于 Web 又基于服务器。与 Java 的“无需带宽,装入 servlet”方法相反,它是一种瘦客户机方法。因此,XML 签名将使用 Web(通过 XML 中的 URL)来找出编码或解码事物的方法。 可以从语法上确切地指定它如何使用 Web(随后的技术讨论中将进行演示), 但这种讨论忽略了要使用什么 URL 的实质问题。即,如果签名需要因特网资源来完成其操作,那么谁将提供这些资源呢?如果这种签名成为消息和事务认证所广泛使用的“信号灯”,则 XML 代码中所指向的任何一个 URL 都可以成为认证服务的实际标准。 但不仅如此。真正的认证服务的使用最有可能出现在 Web 购物中;而不是出现在象安全电子邮件这类应用中。贸易商想要知道他从客户那里接收到的订单是否有效,所以将坚持某种形式的可接受认证。这种问题首先由使用安全网络进行操作的“电子数据交换(Electronic Data Interchange (EDI))”系统解决。在不可靠的因特网上,先前解决过的相同的操作问题仍然存在。XML 签名过程打算以清扫方式处理这一问题,但这种清扫是问题的一部分。这种少有人知的候选方案将方法种子引入其中,使一些公司垄断因特网认证服务。 让我假定一种情况。设想某一商业现货供应(Commercial Off The Shelf (COTS))软件公司决定成为认证服务,所有事情必须先通过这个认证服务才能完成。再进一步假定这家 COTS 的专用操作系统可以在大多数研究中的已部署系统上找到。然后,COTS 供应商生产出其 OS 的 Xtra 专用版,它包含了将 XML 签名(和 仅 XML 签名)用于安全性的客户机。 所有 XML 代码都指向该供应商的服务器以提供信息,这有点象非公用的 PKI 基础结构。 这种客户机广泛用于认证,因为这种 OS 被广泛使用,所以很容易将它设置为缺省值。另外,上述的制造商将它作为缺省安全性机制嵌入其流行的“免费”浏览器。 再加些点缀,假设每次这种客户机将供应商的服务器用于认证时,供应商就开始向某人(可能是贸易商,也可能间接地是客户)收取费用。 瞧!垄断和收入同流合污了。 现在,在诚心诚意地使用了这些安全性服务后,贸易商可能会发现这些服务实际上并没有解决根本问题 ― 即信用卡公司的“退费(chargebacks)”。这些退费问题 ― 人们承认他们与贸易商有协议或合同,但他们声称贸易商没有按承诺执行部分或所有方面(象没有交货、订单被取消或其它一些原因) ― 是信用卡发行者商业模型的一部分,并且超出了 XML 签名规范的作用范围。确实,在美国, Fair Credit Billing Act(15 U.S.C. 1666-1666j)保护客户与发行银行就帐单的正确性(包括商品/服务的数量、总金额、时间和交付/接收)进行争论的权利。不能通过合同否认这些权利。 我将总结上一部分。 因此,即使有合适的象 XML 签名这样的方案正在使用,它们可能也不会解决它们应该解决的现实世界的问题。假定可能有贪婪的公司不负责任地胡乱建立因特网垄断业务,那么使用这种技术可以结束这种令人不满的局面。这并不意味着开发者在相当长的时间里一定要使用这种模式以提供兼容性;但也不要认为它只是一个有魔力的咒语。除最大型公司以外的那些公司可能开发独特的认证服务,使用它们可能需要对 XML 代码稍做改写。 真正的问题可能是对制造商提供的 XML 签名代码的绝对接受。所以,让我们看一下技术规范,同时也要注意理解随着服务的发展可能需要哪些更改。
注意,在随后的示例中, 可以用您想到的一些专利软件供应商的 URL 代替 W3C 地址。这样看上去更现实。下面的讨论很大程度上借鉴了候选规范,因为它们与供应商无关。 XML 签名的第一个有用的特性是,它可应用于任何类型的数字内容(有时称为数据对象),包括 XML。 一个 XML 签名可应用于一个或多个资源的内容。对在签名的同一个 XML 文档内的数据执行封装式签名,所以对于签名元素本身以外的数据还有一个分离签名。更具体地讲, 当前的 XML 签名规范定义一种 XML 签名元素类型和一个 XML 签名应用程序;每一个的一致性要求在文档中分别用模式定义和散文方式指定。
看一下签名元素。首先编摘数据对象摘要(“摘要”是变长数据对象的定长表示,并且使用一个类似 SHA-1 的算法创建),产生的值(和其它信息)被放在一个元素中。然后,对该元素进行编摘并使用密码签名。签名元素的结构如下(其中,“?”表示 0 或 1 次出现,“+”表示 1 次或多次出现,“*”表示 0 或多次出现):
考虑一个带一些真实数据的简单示例。 以下是 XML 规范中 HTML4 内容的分离签名。先给出 XML,随后提供每个分别列出的代码行的注释。在讨论中还假设您已经对专用/公用密钥密码术方法有一些经验并且熟悉概念。如果不是这样,可以仔细阅读 developerWorks 上出色的介绍性文章。(请参阅 参考资料。)
XML 是 作者 Donald Knuth 的格言“所有计算机问题都可以通过其它途径解决。”的代码化表示。整个 XML 语法被设计成利用基于 Web 的重定向服务。虽然可以接受向可信伙伴外包关键商业服务,但在缺省情况下,最好不要将外包作为未来几年中电子商务的重要组成部分。 另外,还必须强调对于安全性分析而言,理解 XML 所使用的上下文(实际正在签名的数据)与代码本身的实际签名同样重要。任何转向其他 Web 服务商业模型的无意或无知缺省使用,都可能因其使一个组织开放和不安全而终止 - 更不用说潜在的昂贵开销了。 知道您在 Web 上究竟去向何方(以及是谁让您去那里!)目前来说似乎是一门很理智的操作课程。
|