用于验证用户的公钥框架和方法转让专利

申请号 : CN200610091275.6

文献号 : CN1881879B

文献日 :

基本信息:

PDF:

法律信息:

相似专利:

发明人 : 戴维·卡乔夫

申请人 : 国际商业机器公司

摘要 :

一种用于允许信赖方充当信任锚以便验证预订者的公钥(PK)框架。所述框架提供了一种受控于信赖方的目录系统,其中所述目录系统包括:用于在数据库中存储从预订者那里接收的证书的存储系统,其中所述证书是由多个不同的证书授权方发布的;用于管理与预订者相关联的数据库中的记录的管理系统;以及用于允许信赖方从数据库中检取证书以便验证预订者的确认系统。

权利要求 :

1.一种具有用于允许信赖方验证用户的信赖方用户验证系统的公钥框架系统,所述公钥框架系统把用户凭证置于所述信赖方的控制之下,并且其中所述信赖方用户验证系统包括:存储系统,用于在用户凭证数据存储库中存储从用户那里接收的证书,其中所述证书是由多个不同的证书授权方发布的;

管理系统,用于管理与用户相关联的用户凭证数据存储库中的记录;以及确认系统,用于允许信赖方从用户凭证数据存储库中检取证书以便验证用户。

2.如权利要求1所述的公钥框架系统,其中存储在所述用户凭证数据存储库中的证书包括自己签名的证书。

3.如权利要求1所述的公钥框架系统,其中从用户那里接收的证书是经由安全信道接收的。

4.如权利要求1所述的公钥框架系统,其中所述用户预订由信赖方提供的服务。

5.一种用于允许信赖方在公钥(PK)框架内验证用户的方法,其中用户凭证受到信赖方的控制,所述方法包括:提供受控于信赖方的用户凭证数据存储库;

在用户凭证数据存储库中存储从用户那里接收的证书,其中所述证书是由多个不同的证书授权方发布的;

在信赖方处接收验证用户的请求;并且

从用户凭证数据存储库中检取证书以便验证用户。

6.如权利要求5所述的方法,还包括如下步骤:允许信赖方管理与用户相关联的用户凭证数据存储库中的记录。

7.如权利要求5所述的方法,其中存储在所述用户凭证数据存储库中的证书包括自己签名的证书。

8.如权利要求5所述的方法,其中从用户那里接收的证书是经由安全信道接收的。

9.如权利要求5所述的方法,其中所述用户预订由信赖方提供的服务。

10.一种利用信赖方用户验证应用的方法,其中用户凭证受到信赖方的控制,所述方法包括:提供计算机基础设施,其可操作用于:

在受控于信赖方的用户凭证数据存储库中存储从用户那里接收的证书,其中所述证书是由多个不同的证书授权方发布的;

管理与信赖方相关联的用户凭证数据存储库中的记录;并且允许信赖方从所述用户凭证数据存储库中检取证书以便验证用户,所述信赖方用户验证应用可操作用于:接收验证用户的请求。

说明书 :

用于验证用户的公钥框架和方法

技术领域

[0001] 本发明总体上涉及数字安全,更具体地说,涉及一种其中信赖方控制信任锚(trust anchor)的公钥技术框架(framework)。

背景技术

[0002] PKI(公钥基础设施)允许诸如因特网之类的基本上不安全的公共网络的用户通过使用公共和私有密钥对来安全地并且私下地交换数据和执行事务处理,其中所述公钥是经由信任的证书授权方(Certificate Authority)来获得并且共享的。通过使用公钥基础设施,用户可以被唯一地验证。证书授权方使用证书数据存储库(repository),其通常是LDAP(轻型目录访问协议,LightweightDirectory Access Protocol)目录,用于存储用户证书和有关已撤消的证书的信息。
[0003] 在传统的PKI模型中,通常使用两个因素的验证方案,其中,用户使用:(1)由信任的证书授权方(CA)发布的私钥/证书,以及(2)由信赖方发布的用户ID(UID)/密码。这种处理的典型实施例包括如下步骤:
[0004] 1.信赖方向用户询问用户的UID和密码;
[0005] 2.用户利用所述UID和密码来作出响应;
[0006] 3.信赖方相对于安全地存储在凭证(credentials)数据库中的信息来检验给出的UID和密码。
[0007] 4.使用私钥和相应的证书在SSL上向信赖方验证用户;
[0008] 5.信赖方万维网(web)服务器检验如下信息:
[0009] a.证书没有到期,
[0010] b.证书由信任的发布CA签名,
[0011] c.根据证书撤销列表(Certificate Revocation List,CRL)分析(其中所述CRL是由发布CA创建并且控制的),证书没有被撤消。
[0012] 传统的PKI模型把发布方CA视为信任锚(trust anchor)。这意味着信赖方期望CA创建合法的证书,所述合法的证书用于把与预订者(subscriber)(最终用户)有关的信息与一公钥唯一地绑定。所述模型还期望CA检验预订者的身份并且检验在CA发布证书之前、预订者的私钥被安全地生成并存储。在传统的PKI中,信赖方无论在何种情况下都明确地信任CA。
[0013] 在分布式多域PKI模型中,存在多个CA,他们之间建立有信任关系(分级结构、交叉证明、网格等)。在证书确认(validation)期间,允许PKI的(PKI-enabled)应用首先必须尝试发现信任路径,所述信任路径可到达作为信任锚的CA级别,然后必须通过检查由信任的CA发布的CRL/ARL(Authority Revocation List,授权方撤销列表)来检验证书撤销状态。在一般情况下,信赖方必须知道每个CA的CRL/ARL的位置、格式和访问。如果存在许多CA,并且如果证书是自己签名的,那么这样做会带来相当大的难题。
[0014] 这些难题中的一些包括如下事实:(1)预订者需要使用公钥技术由信赖方进行安全验证;(2)预订者可以使用由任何CA发布的证书,所述CA可以是信任的或者是不信任的;并且(3)预订者证书可以是自己签名的(例如使用PGP、OpenSSL或者其它专有应用来进行)。
[0015] 传统的PKI模型无法有效地满足这些要求,是因为:(1)信赖方认为发布CA不值得信任(在信任锚的意义上讲),并且发布CA之间也许没有定义任何信任关系;(2)在相同的环境下,自己签名的和CA签名的证书无法被轻易接纳;并且(3)由于CA不被信赖方所信任,所以信赖方无法使用它们来进行证书撤销状态确认。
[0016] 由此,在不同种类的复杂的大规模PKI的情况下,其中该大规模PKI包括自己签名的证书和其数目可能不可预测并且随着时间变化的独立CA,传统的PKI模型无法提供一致的信任级别,并且无法把那些CA以及自己签名的证书用作信任锚。因此,存在对这样一种PKI模型的需要,所述PKI模型可以有效地处理多个CA以及自己签名的证书。

发明内容

[0017] 本发明通过提供一种公钥技术框架来致力于解决上述问题以及其它问题,其中所述公钥技术框架是基于对由信赖方控制的信任锚的定义的。在此模型中,信赖方安全地把已注册用户与相应的用户证书相绑定。用户证书被存储在用户凭证存储库中,所述用户凭证存储库由信赖方控制。此框架中的预订者负责其私钥的安全性并且获得证书(类似于传统的PKI)。然而,信赖方负责检验预订者的身份,并且依照信赖方的用户帐户规定策略、标准、规则和过程来进行预订者帐户生命周期管理(对用户给出的证书进行注册、悬置(suspend)、删除、更新等)。
[0018] 依照第一方面,本发明提供了一种具有信赖方用户验证系统的公钥(PK)框架,所述信赖方用户验证系统用于允许信赖方验证用户,其中所述PK框架把用户证书置于信赖方的控制之下,并且其中所述信赖方用户验证系统包括:用于在用户凭证数据存储库中存储从用户那里接收的证书的存储系统,其中所述证书是由多个不同的证书授权方发布的;用于管理与用户相关联的用户凭证数据存储库中的记录的管理系统;以及用于允许信赖方从用户凭证数据存储库中检取(retrieve)证书以便验证用户的确认系统。
[0019] 依照第二方面,本发明提供了一种用于使用公钥基础设施(PKI)凭证来验证用户的信赖方验证服务器,其中所述信赖方验证服务器包括多个用于验证用户的信任锚,并且其中所述信任锚包括:包含信任的证书授权方证书的密钥库(key store);已注册证书目录;以及定制的万维网服务用户凭证检验应用(custom web services usercredentials verification application)。
[0020] 依照第三方面,本发明提供了一种允许信赖方在公钥(PK)框架内验证用户的方法,其中用户凭证受到信赖方的控制,所述方法包括:提供受控于信赖方的用户凭证数据存储库;在用户凭证数据存储库中存储从用户那里接收的证书,其中所述证书是由多个不同的证书授权方发布的;在信赖方处接收验证用户的请求;并且从用户凭证数据存储库中检取证书以便验证用户。
[0021] 依照第四方面,本发明提供了一种用于使用公钥基础设施(PKI)凭证来验证用户的方法,包括如下步骤:在信赖方验证服务器处接收验证用户的请求;并且从多个信任锚中选择至少一个信任锚来验证所述用户,其中用于验证预订者的多个信任锚包括:包含信任的证书授权方证书的密钥库(key store);已注册证书目录;以及定制的万维网服务用户凭证检验应用。
[0022] 依照第五方面,本发明提供了一种用于利用信赖方用户验证应用的方法,其中用户凭证受到信赖方的控制,所述方法包括:提供计算机基础设施,其可操作用于:在受控于信赖方的用户凭证数据存储库中存储从用户那里接收的证书,其中所述证书是由多个不同的证书授权方发布的;管理与信赖方相关联的用户凭证数据存储库中的记录;并且允许信赖方从所述用户凭证数据存储库中检取证书以便验证用户。

附图说明

[0023] 根据如下结合附图对本发明各个方面的详细描述,将使本发明的这些以及其它特征更加易于理解,其中:
[0024] 图1描述了一种依照本发明的PK技术框架。
[0025] 图2描述了一种依照本发明的目录系统。
[0026] 图3描述了依照本发明的具有多个信任锚选项的混合系统。

具体实施方式

[0027] 公钥框架概述
[0028] 在本发明的第一实施例中,提供了这样一种框架,其中信赖方使用与用户凭证数据存储库相关联的信任的实体目录(Trusted EntitiesDirectory,TED),其包含作为信任锚的已注册的实体。所述用户凭证数据存储库存储与信赖方相关联的每个用户的证书。在此说明性的实施例中,被称为预订者的用户预订由信赖方提供的服务。除在用户凭证数据存储库中存储证书以外,还可以保存预订者记录,其包括诸如预订者状态之类的管理信息,所述预订者状态例如为已添加、已注册、已删除等。
[0029] 为了确保安全,使用用户注册处理把证书安全地递送到用户凭证数据存储库,其中用户注册处理提供了绑定步骤。可以使用例如采用相互验证的安全套接字层(secure sockets layer,SSL),由信赖的应用来验证预订者,并且可以通过使用相应的TED记录信息,由信赖的应用来确认预订者的状态。
[0030] 此方法与使用密码进行用户验证相似,但是在该情况下,使用了非对称的密钥密码技术,而不需要存储基于密码的安全信息。存储在TED中的证书是可公开得到的。由此,虽然需要在TED中保护它们以免被未被授权的替代或者删除,但是它们不需要被加密。这样做较大地限制了信赖方对受损用户凭证的责任。
[0031] 每一预订者的私钥都是在预订者的完全控制下进行维护的,并且由此应当永远不会放弃预订者的所有权。预订者可以使用任何媒介(例如,令牌、智能卡、浏览器等)来存储其PKI凭证。由于发布CA没有被视为信任锚,所以此框架不要求检查证书撤销或者期满状态,除非信赖方决定使用组合方法。
[0032] 现在参考图1,示出了依照本发明的公钥技术框架10的说明性实施例。在此例子中,预订者15和17接收分别来自证书授权方12CA1和CA2的证书14、16。预订者19具有自己签名的证书18。因此,每一证书14、16、18的来源是唯一的。在此框架中,每一个预订者15、17、19都把其证书14、16、18传送至信任的实体目录(TED)系统24,该系统由信赖方22控制。为了此实施例的目的,术语“控制”指的是信赖方22对TED系统24中的信息具有排他性的存储、管理和访问权利。TED系统24包括用户凭证数据存储库25,用于存储并且管理证书和预订者记录。在此实施例中,证书到用户凭证数据存储库25中的传送最好在是安全信道20上(例如,使用采用单向服务器验证的SSL等)执行的。传送可以在例如当预订者预订由信赖方提供的服务时执行。例如,信赖方22可以提供在线零售,并且预订者可以是客户。当预订者例如在信赖方的网站上向信赖方22注册时,可以从预订者那里传送证书并且将其存储在用户凭证数据存储库25中。
[0033] 当信赖方22需要检验预订者15时,信赖方22:(1)获得预订者15的数字签名28(例如,采用预订者的私钥加密的消息摘要(digest)),(2)访问用户凭证数据存储库25,以便获得预订者15的公钥,并且(3)解密数字签名28,以便检验预订者15。
[0034] 现在参考图2,示出了用于实现信任的实体目录系统24的计算机系统30,其充当所述框架的信任锚。信任的实体目录系统24通常包括用于在数据库41中存储证书的存储系统40,用于管理证书和预订者帐户信息的管理系统42,以及用于从数据库41中搜索并且检取证书的确认系统44。存储系统40允许预订者将其证书安全地递送至数据库41的预订者记录中。如上所述,每一预订者记录可以包括管理信息,其诸如为预订者状态(已添加、已注册、已删除等)。管理系统42允许信赖方22和/或预订者管理其预订者记录。
[0035] 计算机系统30可以作为服务器的一部分来实现。计算机系统30通常包括处理器32、输入/输出(I/O)34、存储器36以及总线37。所述处理器32可以包括单个处理单元,或者可以跨越一个或多个处理单元而分布在一个或多个位置、例如客户端和服务器上。存储器36可以包括任何已知类型的数据存储和/或传输介质,包括磁性介质、光学介质、随机存取存储器(RAM)、只读存储器(ROM)、数据高速缓冲存储器、数据对象等。此外,存储器36可以驻留在单个物理位置上,包括一种或多种类型的数据存储设备,或者依照各种形式跨越多个物理系统分布。
[0036] I/O 34可以包括用于往返于外部资源交换信息的任何系统。外部设备/资源可以包括任何已知类型的外部设备,其中包括监视器/显示器、扬声器、存储设备、其它计算机系统,手持设备、键盘、鼠标、语音识别系统、语音输出系统、打印机、传真机、寻呼机等。总线37在计算机系统30中的每一组件之间提供了通信链路,并且同样可以包括任何已知类型的传输链路,其中包括电的、光学的、无线的等。虽然未示出,但是还可以把诸如高速缓冲存储器、通信系统、系统软件等之类的附加组件包括在计算机系统30中。
[0037] 对计算机系统30的访问可以在诸如因特网、局域网(LAN)、广域网(WAN)、虚拟专用网络(VPN)等的网络上提供。通信可以经由直接硬布线的连接(例如,串行端口)来进行,或者经由可以利用有线线路和/或无线传输方法的任何组合的可寻址连接来进行。此外,还可以使用诸如令牌环网(Token Ring)、以太网、WiFi或者其它常规通信标准的常规网络连接性。另外,可以通过常规的基于TCP/IP套接字的协议来提供连接性。在这种情况下,因特网服务供应商可用于建立互连性。此外,如上所述,可以在客户端-服务器或者服务器-服务器环境下进行通信。
[0038] 混合信任锚
[0039] 在某些应用中,希望实现一种使用多叉(mutli-pronged)方法来验证预订者的信任锚。依照此方式,验证服务器可以被配置为使用多种可能方法中的一种来进行验证。现有的SSL/TLS协议(参见RFC2246)要求服务器检验为了进行验证而给出的客户端证书是由信任的CA签名的。为了实现它,服务器通常在服务器的密钥库中存储信任的CA证书的列表。除了检验CA签名是可靠的以外,服务器还可以被配置为检查与CA有关的证书撤销列表(CRL)以便确认客户端证书撤销状态。
[0040] 在RFC 2246中规定的TLS实现方式假定签名CA证书(或者相应的CA链)是可用于客户端验证的唯一信任锚。本实施例允许服务器使用信赖方专用信任锚,在通常情况下,其不同于签名CA以及相应的CRL。它允许企业用自己签名的证书或者由具有不一致的信任、法律地位、经营范围以及技术实现方式级别的不同CA发布的证书来验证用户。
[0041] 依照本发明的此说明性的实施例,所述TLS协议被修改为包括信赖方专用信任锚信息。它可以是在RFC 2246中略述的签名CA或者CA链,或者是专用于特殊信任锚实现方式的协议数据。例如,信赖方客户端的验证设计可以基于对自己签名的证书或者由不同CA发布的证书的使用。在此特殊实例中,可以把已注册用户的证书存储在数据存储库中,并且可被信赖方视为是值得信任的(例如,如以上在图1和2中所述那样)。通过使用受托方(depository)专用协议(例如,LDAP、SQL、HTTPS、SOAP等),可以相对于此数据存储库来确认客户端证书的信任和撤销状态。
[0042] 所提供的方法包括如下用户验证选项:
[0043] 1.信赖方验证服务器接收来自用户的验证证书(经由数字签名)。
[0044] 2.基于信赖方信任锚实现方式,所述验证服务器执行下述操作之一:
[0045] a.检验所述用户证书是由在服务器的信任的CA证书库(store)中公布的信任的CA签名的(基于RFC 2246的方法);或者
[0046] b.相对于已注册用户证书的LDAP目录56(备选的信任锚)或者某个其它数据存储库58来检查证书;和/或
[0047] c.使用万维网服务机制把接收的证书发送至指定的远程万维网应用(备选的信任锚)以便进行检验。
[0048] 图3描述了用于实现混合信任锚的说明性的实施例。在该情况下,当预订者50向信赖方验证服务器52提交SSL证书62时,信赖方验证服务器52可以使用一个或多个TM TM用于验证预订者50的机制。选项包括:使用信任的CA证书库54(诸如EQUIFAX 、GTE 、TM TM
MICROSOFT 、VERISIGN 等),使用已注册证书的LDAP(轻型目录访问协议)目录56,或者使用其它用于提供已注册证书的凭证数据库58的数据库技术(例如,使用诸如JDBC(Java DataBaseConnectivity,Java数据库连接性)、ODBC(Open DataBaseConnectivity,开放式数据库连接性)、SQL(Structured QueryLanguage,结构化查询语言)、所存储的过程等之类的访问协议),或者例如使用HTTP/SOAP万维网服务实现的定制的万维网服务信任锚应用
60。
[0049] 此方法识别各种可由信赖方使用的信任锚,以便当用户验证证书是自己签名的或者是由任意CA签名的时、更加有效地满足各种验证要求。此方法允许信赖方实现集中化的信任锚模型,其可以跨越分布式大规模企业环境而被有效地管理。
[0050] 应该理解的是,本发明的教义是作为在预订或者付费基础上的商业方法而提供的。例如,信任的实体目录系统或者混合系统可以由服务供应商来创建、维护、和/或利用,所述服务供应商为客户提供此处所述的功能。也就是说,服务供应商可以如上所述提供信任锚服务。
[0051] 应该理解的是,此处所述的系统、功能、机制、方法、引擎和模块可以以硬件、软件或者硬件和软件的组合实现。它们可以通过任何类型的计算机系统或者其它适合于执行此处所述的方法的设备来实现。硬件和软件的典型组合可以是具有计算机程序的通用计算机系统,当载入并且执行所述计算机程序时,该程序控制所述计算机系统,以使其执行此处所述的方法。作为选择,还可以利用包含用于执行本发明的一个或多个功能任务的专用硬件的专用计算机。在进一步的实施例中,本发明的一部分例如可以在诸如因特网之类的网络上依照分布式方式来实现。
[0052] 本发明还可以被嵌入在计算机程序产品中,其包括能够实现此处所述的方法和功能的所有特征,并且当将其载入计算机系统时,其能够执行这些方法和功能。在这个上下文中,诸如计算机程序、软件程序、程序、程序产品、软件等之类的术语,指的是以任何语言、代码或符号的、这样一组指令的任何表示,所述指令意在使具有信息处理能力的系统直接地或者在进行如下步骤中任何一个步骤或两个步骤之后执行特殊的功能,所述步骤包括:(a)转换为另一种语言、代码或符号;和/或(b)以不同材料形式再现。
[0053] 为了举例说明和描述的目的,已经给出了本发明的先前描述。这并不意味着是穷举的或者把本发明限制为所公开的具体形式,并且显然,许多修改和变化都是可能的。意图使对于本领域技术人员来说显而易见的这种修改和变化被包括在本发明的范围之内,其中本发明的范围由所附权利要求书来限定。