采用多种安全机制实现多因素身份验证

使用多种安全机制为 AIX 和 UNIX 系统设计和实现多因素身份验证

身份验证是依赖于安全性的解决方案的重要组成部分。在为 UNIX® 系统设计的客户机-服务器模型中,分布式网络安全是极其重要的。为了满足客户机-服务器模型所需的严格的安全需求,现有的系统必须使用多层身份验证或多因素身份验证,或这两者的组合。本文讨论在多因素身份验证系统中使用同一种安全机制的风险,建议使用 GSS-API(大多数 UNIX 系统上都有的通用安全服务)通过多种安全机制实现多因素身份验证,从而增强为 UNIX 设计的解决方案的安全性。

Sandeep Patil, 软件工程师, IBM

Sandeep Patil 的照片Sandeep Ramesh Patil 是 IBM India Software Lab 的软件咨询工程师。他已在 IBM 工作了七年,着重研究分布式技术,包括 DCE、SARPC 以及安全产品,比如 IBM Network Authentication Services (IBM Kerberos)。目前,他正在开发新的特性,并在为 IBM Network Authentication Services 实现与安全有关的 RFC 及其产品支持。Sandeep 拥有 University of Pune,India 的计算机科学与工程学士学位。


developerWorks 大师作者

2009 年 5 月 13 日

简介

安全性是软件工程的一个重要问题。在通过网络运行的软件或软件解决方案中,身份验证、授权、私密性、完整性和不可否认性是主要的安全组件。在这些组件中,身份验证是最重要的。身份验证的作用是证明用户的身份。在 UNIX 系统中,有多种身份验证方法,比如基于密码的身份验证、使用智能卡的身份验证、基于生物检测技术的身份验证等等。这些通过网络的身份验证方法使用不同的安全机制。SSL/TLS(Secure Socket Layer / Transport Layer Security Version 1.0,RFC 2246)和 Kerberos(Kerberos Network Authentication Service (V5),RFC 1510)是网络身份验证最常用的两种安全机制。AIX® 集成了对 Kerberos 的登录支持。针对金融、银行和保险业的解决方案和软件具有非常严格的安全需求。为了满足这些安全需求,必须使用多层身份验证或多因素身份验证,或这两者的组合。大多数实现多因素身份验证和多层身份验证的解决方案使用相同的底层网络安全机制。这会带来风险,在安全需求严格的环境中尤其如此。

本文讨论使用相同的网络安全机制实现多因素或多层身份验证的风险。本文指出解决方案需要构建使用多种安全机制的多因素身份验证。还介绍 AIX 和其他 UNIX 操作上都有的 Generic Security Service Application Programming Interface (GSS-API),建议使用它实现使用多种安全机制的多因素身份验证。

特殊行业需要更强的网络身份验证

电子通信已经成为所有行业的基本部分,包括医疗保健、电信、制药、零售、金融等等。几乎所有这些行业都在全世界部署了它们自己的特制软件系统和解决方案,从而把它们的客户和业务伙伴连接在一起。安全对于所有这些系统都很重要,尤其是对于金融部门。

与其他行业的公司相比,金融机构面对的安全风险要高得多。金融机构的业务几乎全都涉及到资金,攻击它们可能获得更大的收获,所以它们总是受到持久的坚决的攻击。因此,银行、保险、资产管理和股票市场等领域的金融机构必须满足非常严格的安全需求,必须保护它们的应用程序处理的所有电子数据。它们必须设计和实现能够满足这些严格的安全需求的软件解决方案和应用程序。换句话说,系统需要确保很高的安全合法性。正如在 FFIEC (Federal Financial Institutions Examination Council) 致金融机构的信函(FIL-103-2005,2005 年 10 月 12 日)“Authentication in an Internet Banking Environment” 中指出的:“在网上银行环境中,未经授权的或未正确识别的用户可能会进行欺诈、泄露客户信息、损坏数据或造成不可能实施的合约,从而给金融机构造成经济损失和名誉损失。” 这封信函强调了网络身份验证的重要性:“风险评估应该根据与网上客户可用的各种产品和服务相关的风险决定有效的身份验证战略”(详细信息见 参考资料)。因此,必须建立健壮的身份管理过程来实现身份验证和授权,这是成功实现安全的软件解决方案的关键因素之一。

分布式解决方案的安全需求不仅对于金融机构很重要,对于电信、医疗保健、制药等行业也同样重要,它们也需要非常安全的解决方案。因此,为了满足对安全的 UNIX 系统日益增长的需求,大多数解决方案放弃了保护能力不足的单因素身份验证,转而采用多因素和多层(递增式)身份验证。

按照推荐的两因素身份验证系统设计,可以使用 Kerberos 实现第一因素身份验证,然后使用 Kerberos 基础结构(通过 GSS-API 接口)实现使用 One-Time Password (OTP) 令牌的第二因素身份验证。在按照这种方式实现的双因素身份验证系统中,Kerberos 协议扮演双重角色。

多因素和多层身份验证

在多因素身份验证中,使用多种检验机制检查身份的真实性。两因素身份验证 (T-FA) 是常用的多因素身份验证形式之一。通常,两因素身份验证实现使用的一个因素是 “用户知道的某种信息” (比如密码),另一个因素是 “用户拥有的某种东西”(物理设备)或 “用户本身的某种特征”(比如指纹等生物学特征)。常见的一个 T-FA 示例是银行卡(信用卡,借记卡);卡片本身是 “用户拥有的物理物品”,个人识别号(PIN)是与它相关联的 “用户知道的信息”(密码)。

系统常常使用多因素身份验证提高安全性,减轻犯罪造成的风险。因此,金融和相关行业的解决方案一般采用这种技术。人们常常认为多层身份验证是多因素身份验证的同义词。但是,在多因素身份验证和多层身份验证之间有明确的差异。

多因素身份验证本身可以分层。在多层身份验证中,身份验证层表示是否需要额外的身份验证才能访问受保护的对象。这意味着,如果需要访问限制更严格的资源,就需要额外的身份验证步骤。

多层身份验证与 IBM® Tivoli® Access Manager 为电子商务定义的递增式身份验证相似。在传统的多层身份验证中,系统分层为多个子组件;要想访问特定的子组件,就需要基本组件的有效身份验证信息,以及特定子组件专用的额外身份验证信息,通常使用相同的检验机制。例如,在实现多层身份验证的银行系统中,用户需要输入用户名和密码(用户知道的某种信息)以登录系统,这是系统的基本身份验证。基本身份验证允许用户执行基本任务,比如查看以前的事务。但是,如果用户希望执行某些事务(比如转账),那么除了基本身份验证之外,用户还需要输入 “事务密码”(与多因素身份验证不同,这也是 “用户知道的某种信息”),然后才能执行事务。

多因素身份验证和多层身份验证相结合能够提供比传统的单密码身份验证更安全的解决方案。

采用多种安全机制的多因素身份验证的现实需求

尽管多因素身份验证和多层身份验证是有优势的,但是大多数解决方案使用相同的底层网络安全机制实现它们。这会造成问题,在安全需求严格的环境中尤其如此。例如,大多数基于 Web 的银行系统使用 SSL/TLS 或 HTTPS 协议(Secure HyperText Transfer Protocol,RFC 2660)作为底层网络安全机制实现基本的两因素身份验证。

为了成功地登录这种系统,最终用户通常需要:

  1. 提交正确的密码(所需的身份验证信息是用户应该知道的某种信息)。这是第一个身份验证因素。
  2. 提交用户的 ATM 卡号的最后四位(所需的身份验证信息是用户拥有的某种东西)。这是两因素身份验证的第二个因素,系统假设只有用户能够看到自己的 ATM 卡。

在这些情况下,两因素身份验证能够提高系统的安全性;要想入侵系统,恶意用户不但必须猜出用户的密码,还必须获得 ATM 卡的号码。这听起来安全多了。但是要注意一点:对于两因素身份验证的两个因素,系统使用相同的底层安全机制 (SSL/TLS/HTTPS) 实现网络身份验证。这会带来几个问题:如果恶意用户攻破了底层安全机制本身,那么会怎么样?如果黑客在安全机制中发现了一个漏洞,让他可以破解身份验证,而不需要了解用户的身份验证信息,那么会怎么样?如果有人利用安全机制的某些未知的限制破解了它,那么会怎么样?因为两因素身份验证的两个因素使用相同的底层安全机制实现网络身份验证,双重身份验证的优势完全被抵消了。这会带来风险,对于需要非常安全的解决方案的系统,这可能是很严重的问题。

为了解决这个问题,这里推荐一种方法。实现多因素身份验证的系统应该对不同的因素使用不同的底层安全机制。这会显著降低风险。例如,如果两因素身份验证的第一个因素使用 Kerberos 作为底层网络安全机制,第二个因素使用 LIPKEY(一种使用 SPKM 的 Low Infrastructure Public Key Mechanism,RFC 2847)或 NTLM(NT LAN Manager,一种 Microsoft® 身份验证协议)作为底层网络安全机制,那么恶意用户必须破解两种完全不同的安全机制,这加大了入侵的难度,降低了风险。这种方法通过降低风险增强了系统的总体安全性。对于实现多层身份验证的系统,也是如此。

Generic Security Service Application Program Interface

Generic Security Service Application Program Interface(GSS-API,在 [RFC-2743] 中定义,见 参考资料)以一致的方式向调用者提供安全服务,可以支持多种底层机制和技术,因此为应用程序提供源代码级可移植性。它是一组编程接口,对身份验证、消息来源身份验证和完整性以及消息的机密性进行抽象。因此,使用 GSS-API 开发的安全应用程序可以使用不同的安全机制,不需要修改应用程序。在 GSS-API 中,相互通信的两个应用程序之间的安全连接通常由称为安全上下文的数据结构表示。建立安全连接的应用程序称为上下文发起者。接受安全连接的应用程序称为上下文接受者。在发起者和接受者之间建立上下文实际上是一个握手过程,此过程需要对双方进行身份验证。成功地建立 GSS-API 上下文之后,就可以认为已经成功地检验了通信双方的用户身份。

UNIX 分布式文件系统 Network File System Version 4 (NFS v4) 使用 GSS-API 作为网络安全机制(见 参考资料)。大多数 UNIX 操作系统(包括 AIX)都支持和提供 GSS-API。IBM Network Authentication Service for AIX Version 1.4 提供 GSS-API,可以用它为 AIX 实现安全解决方案。GSS-API 在市场上出现已经有相当长的时间了,它的大多数实现只支持密钥安全机制,即 Kerberos。由于有这个限制,往往不使用 GSS-API。但是,NFS v4 要求使用 SPKM (Simple Public Key Mechanism) 和 LIPKEY (Low Infrastructure Public Key Mechanism) 等比较新的机制,有望通过 GSS-API 在 UNIX 系统上使用这些机制。因此,应用程序程序员应该了解 GSS-API 的好处,考虑使用 GSS-API 实现应用程序的安全机制。一些 GSS-API 实现,比如 Microsoft 的 SSPI (Security Support Provider Interface),已经支持 NTLM、Kerberos 和 SSL 等多种安全机制。如果架构师需要让应用程序能够在多种安全基础结构环境中运行,就应该考虑使用 GSS-API 框架,而不是在应用程序中直接使用安全机制特有的 API。

可以使用 GSS-API 实现多因素身份验证,从而实现使用多种安全机制的多因素身份验证。这种技术组合可以降低使用相同底层安全机制实现多因素身份验证解决方案的风险。通过使用 GSS-API,系统可以对多因素身份验证的不同因素使用不同的底层安全机制。只需在 GSS-API 握手过程中指定适当的与机制相关的对象标识符 (OID),就可以显式地声明应用程序对于身份验证使用的底层安全机制。例如,在实现两因素身份验证的系统中,对于第一个身份验证因素,开发人员可以向 GSS-API 传递一个特定的安全机制 OID(例如 Kerberos);身份验证成功之后,再用另一个安全机制 OID(例如 LIPKEY)发起用于第二个身份验证因素的 GSS-API 身份验证握手。因为 Kerberos 机制(基于纯粹的对称密钥技术)和 LIPKEY 机制(基于对称和非对称密钥技术)很不一样,恶意用户很难同时破解这两种机制。因此,这种系统降低了使用单一安全机制实现两因素身份验证的风险。

图 1 说明如何使用 GSS-API 框架为两因素身份验证显式地指定两种不同的安全机制,从而为 UNIX 系统提供更安全的身份验证。要想入侵这样的系统,恶意用户必须破解两种完全不同的安全机制,而不是一种,因此提高了安全性。

图 1. 通过 GSS-API 采用多种安全机制实现多因素身份验证的处理流
通过 GSS-API 采用多种安全机制实现多因素身份验证的处理流

关于 GSS-API 编程的更多信息,请参见产品附带的 IBM Network Authentication Service Version 1.4 for AIX Application Development Reference。可以在 AIX Expansion Pack CD 上找到 IBM Network Authentication Service Version 1.4 for AIX,也可以通过 IBM AIX Web Download Pack Programs 下载(见 参考资料)。

结束语

本文讨论了安全性尤其是身份验证的重要性。还指出,尽管多因素身份验证更安全,但是如果用单一底层安全机制实现它,也会造成安全风险。本文强调应该使用多种安全机制实现多因素身份验证,从而提高安全性。最后,建议使用 GSS-API(在包括 AIX 在内的大多数 UNIX 操作系统上都有的 API)帮助纳入新的安全机制。

参考资料

学习

获得产品和技术

条评论

developerWorks: 登录

标有星(*)号的字段是必填字段。


需要一个 IBM ID?
忘记 IBM ID?


忘记密码?
更改您的密码

单击提交则表示您同意developerWorks 的条款和条件。 查看条款和条件

 


在您首次登录 developerWorks 时,会为您创建一份个人概要。您的个人概要中的信息(您的姓名、国家/地区,以及公司名称)是公开显示的,而且会随着您发布的任何内容一起显示,除非您选择隐藏您的公司名称。您可以随时更新您的 IBM 帐户。

所有提交的信息确保安全。

选择您的昵称



当您初次登录到 developerWorks 时,将会为您创建一份概要信息,您需要指定一个昵称。您的昵称将和您在 developerWorks 发布的内容显示在一起。

昵称长度在 3 至 31 个字符之间。 您的昵称在 developerWorks 社区中必须是唯一的,并且出于隐私保护的原因,不能是您的电子邮件地址。

标有星(*)号的字段是必填字段。

(昵称长度在 3 至 31 个字符之间)

单击提交则表示您同意developerWorks 的条款和条件。 查看条款和条件.

 


所有提交的信息确保安全。


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=10
Zone=AIX and UNIX, Security
ArticleID=388895
ArticleTitle=采用多种安全机制实现多因素身份验证
publish-date=05132009