一种可信网络的证书签发、认证方法及相应的设备

一种可信网络的证书签发、认证方法及相应的设备

技术领域

本申请涉及可信计算技术，更具体地，涉及一种可信网络的证书签发、 认证方法及相应的设备。

背景技术

随着计算机技术和网络的迅猛发展，信息安全问题日趋复杂，系统安全 问题，特别是计算机平台的开放框架所带来的威胁层出不穷。传统信息安全 系统是以防外为重点，即以防御网络攻击(如：未知密钥共享，交错攻击， DoS攻击，重放攻击等)为主，这与目前信息安全主要威胁源自内部的实际 状况不相符合。另外，从组成信息系统的服务器、网络、终端三个层面上来 看，现有的保护手段是逐层递减的。人们往往把过多的注意力放在对服务器 和网络设备的保护上，而忽略了对终端的保护。随着安全研究的不断深入， 人们认识到针对计算实体内部的攻击是一种重要的安全威胁，因此越来越重 视这些攻击所造成的危害。

为此，研究人员提出了可信计算的概念。可信计算的本质主要是通过增 强现有的终端体系结构的安全性来保证整个系统的安全。其主要思路是在包 括台式机、笔记本及智能手机等多种设备中，以所嵌入的可信平台模块 (Trusted Platform Module，TPM)为核心为用户和平台提供安全保障。TPM 通过存储、度量、报告等一系列手段来建立一个可信的计算环境，解决了部 分针对内部攻击的问题。TPM具有远程证明的能力，能够响应远程认证方的 请求，证明平台身份和平台完整性等可信属性。可信计算组织(Trusted  Computing Group，TCG)要求在远程证明过程中，有效的保护平台身份信息 的隐私性，即TPM向认证方进行远程证明时不能暴露身份信息。

为了解决远程证明时平台隐私信息的保护问题，TCG先后采用PCA方 法和DAA方法。

TCG在其TPM v1.1b规范中提出了隐私证书权威(Privacy Certificate  Authority，PrivacyCA)匿名认证系统，它采用PrivacyCA作为可信第三方 为客户平台的EK证书签发别名证书来保证匿名性，并通过一次一密的方法 保证平台的多次认证间的不可关联。

针对密钥的不同用途，TCG定义了七种类型的密钥，其中与平台身份认 证有关的主要密钥有：

签署密钥(EK，Endorsement Key)：用于唯一标识平台身份的密钥，一般 由TPM生产商在制造TPM时生成。EK影响到整个系统的安全性，它只 用于两个操作：一是在确定平台属主时，解密属主的授权数据；二是生成AIK 密钥并创建平台身份的别名证书。

身份证明密钥(AIK，Attestation Identity Key)：专用于对TPM产生的数 据(如PCRs值等)进行签名，证明平台身份的合法性及平台环境的可信性。

为了实现密钥的应用、管理及平台的可信证明，TCG定义了五类证书， 每类都被用于为特定操作提供必要的信息，包括：

签署证书(Endorsement Credential)：又称EK证书，一般由生成EK的 厂商发布，包含TPM制造者名、TPM型号、TPM版本号和EK公钥等信 息。

身份证明证书(AIK Credential)：又称AIK证书，用于鉴定对PCR值 进行签名的AIK私钥，它包括AIK公钥和其它签发者认为有用的信息。AIK 证书是由一个可信的、能够校验各种证书和保护用户隐私的服务方签发。通 过签发证书，服务方可以证明提供TPM信息的TPM是真实的。

其他的还有一致性证书(Conformance Credential)、平台证书(Platform  Endorsement Credential)和确认证书(Validation Credential)。

2007年12月，中国国家密码管理局颁布了《可信计算密码支撑平台功 能与接口规范》，该规范描述了可信计算密码支撑平台的功能原理与要求， 并定义了可信计算密码支撑平台为应用层提供服务的接口规范用。为实现远 程证明过程中对平台身份匿名的保护，该规范定义了一个以可信第三方为中 心的平台身份认证系统，以可信密码模块(TCM，Trusted Cryptographic  Module)替代TPM作为可信根，其工作原理及签发证书的协议流程基本与 TCG PrivacyCA系统相同，但为适应我国的国情，采用了双证书体系和不同 的密码算法。其中的双证书包括平台身份证书和平台加密证书，平台身份证 书是为平台身份密钥(PIK，Platform Identity Key)的公钥签发的证书，也称为 PIK证书。PIK是在TCM内部生成的一个SM2密钥对，用于对TCM内 部的信息进行签名，实现平台身份认证和完整性报告；平台加密证书是为平 台加密密钥(PEK，Platform Encryption Key)的公钥签发的证书，也称为PEK 证书，它是TCM中与PIK证书相关联的数据加密证书。

TCG在TPM v1.2标准中提出了直接匿名认证(direct anonymous  attestation，DAA)系统。DAA认证系统以C-L签名方案和基于离散对数的 零知识证明为基础，并使用Fiat-Shamir启发式方法将知识证明转换为非交 互式知识签名。DAA认证系统的主要参与方有签名方(Signer)、可信发布方 (Issuer)和认证方(Verifier)。其工作时，首先，TPM基于EK公钥向可信 发布方申请获得对于秘密数据(f₀，f₁)的C-L签名，也即获得关于(f₀，f₁)的 DAA证书(A，e，v)，之后的每次认证TPM与其相绑定的平台主机一起向认 证方零知识证明其拥有秘密数据(f₀，f₁)及相关DAA证书(A，e，v)，并用 (f₀，f₁)计算了假名N_v，证明通过则该TPM对应平台的身份是可信的。DAA 认证系统在实现身份合法性认证的同时，也对AIK公钥进行签名，使得AIK 成为EK的别名。

可信计算工作组可信网络连接分组(TNC Sub Group，TNC-SG)提出可 信网络连接(TNC)架构，从终端的完整性开始，通过信任链，将信任关系 传递至网络。该架构规定可信接入认证方案的设计，在实现传统用户身份认 证基础上，还需完成对平台身份认证和平台完整性的校验。

TNC架构在纵向分为三个层次，从下到上为：

网络访问层：这一层用于支持传统的网络连接技术，如802.1X和VPN 等，进行用户身份认证和密钥协商并建立安全信道，完成后通知上层进行完 整性评估层协议。

完整性评估层：负责评估所有请求访问网络的平台的完整性，这一层协 议的运行受网络访问层安全信道的保护。

完整性度量层：收集和校验请求访问者的完整性相关信息的组件。

IBM公司在TNC架构基础上提出了一个完整性评估层协议-完整性报 告协议，该协议实现TNC架构中完整性评估层平台的身份认证和完整性校 验。它基于挑战-应答认证协议。如图1所示，平台PA向平台PB证明自己 的身份和完整性。首先PB生成随机数nonce并发送给PM；PA收到挑战消 息nonce，按照协议的规定，使用存储根密钥从TPM中读取证明身份密钥 AIK_priv，并以AIK_priv为私钥将选择的PCR值和收到的随机数nonce进行签名 然后将签名消息Quote连同存储测量日志 SML和Privacy CA向平台签发的AIK证书cert(AIK_pub)一同发给PB；PB收 到后，验证AIK证书和签名消息Quote，并通过PCR验证nonce和SML， 以实现对PA的身份认证和完整性校验。

但是，上述协议容易遭受一种新的攻击-平台替换攻击，这一攻击将导 致平台身份认证的失败以及平台完整性校验错误，造成可信网络连接的安全 目标不能达到。

假定用户A、M和B都是合法用户，且A与M、M与B之间分别建立 了安全信道。用户A、M和B分别控制平台PA、PM和PB，其中PA、PB 是可信平台，PM是不可信平台。合法用户M希望通过不可信的平台PM接 入平台PB，攻击过程如图2所示。

1)PB生成随机数nonce并发送给PM；

2)PM收到nonce后，将其转发给PA；

3)PA接收到PM发来的挑战消息nonce，按照协议的规定，使用存储根 密钥从TPM中读取证明身份密钥AIK_priv，并以AIK_priv为私钥将选择的PCR 值和收到的随机数nonce进行签名，然后将签名消息Quote连同存储测量日 志SML和AIK证书cert(AIK_pub)一同发给PM；

4)PM将PA发来的消息转发给PB；

5)PB的验证过程与图1中PB的验证过程相同。

攻击中，平台PM成功的说服平台PA对平台PB的一次性随机数进行签 名，并进而允许平台PM成功的欺骗平台PB。这是一次完美的攻击，因为平 台PA和平台PB都不能够察觉到任何错误。攻击结束后，平台PB认为PM 是可信平台并允许其接入，平台PA认为它与平台PM进行了一次协议交互。 但实际上平台PM是一个不可信平台，它借助可信平台PA接入PB。

对于证明方向验证方主动发起的远程认证过程也是如此，可参照图2及 相关的假定，在A与M、M与B之间分别建立了安全信道后，可信平台PA 主动发起远程认证(可携带AIK、AIK_priv对选择的PCR值的签名和Privacy CA 向平台签发的AIK证书等证明信息)，不可信平台PM收到后转发给PB， PB验证通过后会认为PM是可信平台并允许其接入。

平台替换攻击是在网络访问层用户之间建立的安全信道基础上进行的。 尽管有安全信道保护，但无法避免平台替换攻击，其原因如下：

按照TPM主规范的规定，对于验证平台而言，AIK签名只能说明消息 来自一个含有真实TPM芯片的平台，不能证明签名消息的平台就是议定的 通信平台，证明身份密钥AIK不能直接用于认证通信平台的身份。因此，验 证平台PB不能确定接收到的消息属于协议议定的响应平台PM，而只能确定 消息来自一个可信的平台。在进行可信网络连接过程中，同一用户可以使用 不同的计算平台，不同的用户也可以使用同一平台进行连接，这就使得用户 与用户所使用的平台之间不存在一一对应的关系。网络访问层建立的安全信 道只能保证网络访问层用户之间通信的认证性和保密性，不能保证用户所使 用的平台之间的认证性。可信网络连接架构规定，网络访问层的安全信道能 够保护完整性评估层协议的消息交互，但实质上用户与平台之间没有绑定关 系，不能将两者看作一个整体来处理，平台之间的身份认证和完整性校验不 能完全依赖于用户之间的安全信道。

对了解决上述问题，现有技术提出一种将存在平台替换攻击的完整性报 告协议转换成安全的完整性评估层协议的方法，而一个可信网络连接协议需 满足以下条件：在网络访问层用户在非认证链路(UM，Unauthenticated Link) 环境下协商出会话密钥安全(SK-Secure)的会话密钥，并建立用户之间的安 全信道；网络访问层用户与完整性评估层平台之间存在动态授权绑定；完整 性评估层平台之间的协议会话在PUM环境下是匹配会话。但该解决方案过 于复杂，对协议的改动过大。

申请内容

有鉴于此，本申请要解决的技术问题是提供一种将用户和平台绑定的可 信网络的证书签发方法和相应的设备。

为了解决上述技术问题，本申请提供了一种可信网络的证书签发方法， 包括：

证书申请方的可信计算平台向证书权威CA发送证书请求，该证书请求 中携带该证书申请方的用户身份信息和平台信息；

该CA收到证书请求后，验证所述用户身份信息和平台信息，如验证通 过，为该证书申请方签发平台及用户身份证书，该平台及用户身份证书的签 名的主体部分包含该证书申请方在该可信网络中的用户标识和平台标识；

该证书申请方的可信计算平台保存该平台及用户身份证书。

较佳地，

所述平台信息包括该证书申请方的可信模块签署(EK)证书或其别名证 书；该CA验证所述平台信息，包括对该EK证书或其别名证书的验证。

较佳地，

该证书申请方的平台标识为该证书申请方的可信模块标识，该平台标识 携带在该证书申请方发送的该证书请求中，或者由该CA为该证书申请方分 配；

该证书申请方的用户标识携带在该证书申请方发送的该证书请求中，或 者由该CA为该证书申请方分配。

较佳地，

该证书申请方的可信计算平台向该CA发送证书请求之前，还包括：

该证书申请方的可信计算平台在所有者的授权下，其内部的该可信模块 生成一对密钥包括第一身份公钥和第一身份私钥，该第一身份私钥保存在该 可信模块内部；

该证书请求中携带的平台信息还包括该第一身份公钥；

该平台及用户身份证书的签名的主体部分还包括该第一身份公钥。

较佳地，

该CA验证所述用户身份信息和平台信息，如验证通过，还包括：

该CA为该证书申请方分配基于所述用户标识和平台标识的一对密钥包 括第二身份公钥和第二身份私钥，并将该第二身份公钥和该第二身份私钥的 信息随该平台及用户身份证书一起发送给该证书申请方，其中，该第二身份 公钥包含在该平台及用户身份证书的签名的主体部分中，该第二身份私钥的 信息经过加密。

较佳地，

该证书签发方法还包括：该CA对其签发的证书申请方的平台及用户身 份证书进行管理，包括对平台及用户身份证书的存储、更新和注销。

相应地，本申请还提供了一种可信网络成员的可信计算平台，包括可信 模块，还包括：

证书申请模块，用于作为证书申请方向证书权威(CA)发送证书请求，该 证书请求中携带本证书申请方的用户身份信息和平台信息；

证书存储模块，用于保存该可信网络的证书权威为本证书申请方签发的 平台及用户身份证书，该平台及用户身份证书的签名的主体部分包含本证书 申请方在该可信网络中的用户标识和平台标识。

较佳地，

所述可信计算平台还包括：

密钥生成模块，用于在所有者的授权下，其内部的该可信模块生成一对 密钥包括第一身份公钥和第一身份私钥，该第一身份私钥保存在该可信模块 内部；

所述证书申请模块向CA发送的证书请求携带的平台信息包括该第一身 份公钥，及该证书申请方的可信模块签署(EK)证书或其别名证书。

相应地，本申请还提供了一种可信网络的证书权威，包括：

接收模块，用于接收证书申请方的可信计算平台发送的证书请求，获取 该证书申请方的用户身份信息和平台信息；

验证模块，用于验证所述用户身份信息和平台信息；

签发模块，用于在所述验证模块的验证通过后，为该证书申请方签发平 台及用户身份证书，该平台及用户身份证书的签名的主体部分包含该证书申 请方在该可信网络中的用户标识和平台标识；

管理模块，用于对所述签发模块签发的证书申请方的平台及用户身份证 书进行管理，包括对平台及用户身份证书的存储、更新和注销。

较佳地，

所述接收模块接收的该证书申请方的平台信息包括该证书申请方的可信 模块签署(EK)证书或其别名证书；

所述验证模块验证所述平台信息，包括对该EK证书或其别名证书的验 证。

较佳地，

所述签发模块签发的该平台及用户身份证书的签名的主体部分还包括该 证书请求中携带的该证书申请方可信模块生成的第一身份公钥；和/或

该签发模块还用于为该证书申请方分配基于所述用户标识和平台标识的 一对密钥包括第二身份公钥和第二身份私钥，并将该第二身份公钥和该第二 身份私钥的信息随该平台及用户身份证书一起发送给该证书申请方，其中， 该第二身份公钥包含在该平台及用户身份证书的签名的主体部分中，该第二 身份私钥的信息经过加密。

上述证书签发方案中，CA签发的平台及用户身份证书中同时包含用户 身份标识和平台标识，相对现有只为平台签发证书的方案，实现了用户和平 台的身份绑定，为用户身份和平台身份的同时认证奠定了基础。

本申请要解决的又一技术问题是提供一种简单、可防止平台替换攻击的 可信网络的认证方法和相应的设备。

为了解决上述技术问题，本申请提供了一种可信网络的认证方法，包括：

证明方的可信计算平台向验证方发送证明信息，该证明信息包括该可信 网络的证书权威为该证明方签发的平台及用户身份证书，该平台及用户身份 证书的签名的主体部分包含该证明方在该可信网络中的用户标识和平台标 识；

该验证方收到所述证明信息后，对该证明方的平台及用户身份证书进行 验证，如验证通过，判定该证明方的用户身份和平台身份合法。

较佳地，

该证明方发送的证明信息中还包括该证明方使用自己的身份私钥对本证 明方可信计算平台的完整性度量值签名得到的签名消息，该身份私钥对应的 身份公钥包含在该平台及用户身份证书的签名的主体部分中；

该验证方收到该证明信息后，还使用该身份私钥对应的身份公钥解密该 签名消息并进行验证，如验证通过，判定该证明方的可信计算平台符合完整 性的要求。

较佳地，

该认证方法还包括：该可信网络的两个成员分别作为验证方对对端认证 通过后，该两个成员的用户之间建立起网络访问层的安全信道，且同时完成 了对对端可信计算平台的身份认证和完整性校验。

本申请提供的实现上述认证的可信计算平台基于上述证书签发方案中的 可信计算平台，包括证书申请模块和证书存储模块，还可以包括密钥生成模 块，为了实现认证，该可信计算平台还包括：

认证请求模块，用于作为证明方向验证方发送证明信息，该证明信息包 括本证明方的平台及用户身份证书及使用本证明书的身份私钥对本证明方可 信计算平台的完整性度量值签名得到的签名消息，该平台及用户身份证书的 签名的主体部分包含该身份私钥对应的身份公钥；

身份验证模块，用于在收到其他的证明方的证明信息后，对所述证明信 息中的平台及用户身份证书和签名消息进行验证，如验证通过，判定该证明 方的用户身份和平台身份合法，且其可信计算平台符合完整性的要求。

上述可信网络的认证方案以平台及用户身份证书为证明，验证方可以同 时实现对证明方平台身份和用户身份的验证，因而可以有效地防止平台替换 攻击。

附图说明

图1是一种现有协议的身份认证和完整性校验的信令示意图；

图2是基于图1协议进行平台替换攻击的信令示意图；

图3为本申请实施例一可信网络的证书签发方法的流程图；

图4为本申请实施例可信网络中可信计算平台及CA的模块图；

图5为本申请实施例二可信网络的认证方法的流程图。

具体实施方式

为使本申请的目的、技术方案和优点更加清楚明白，下文中将结合附图 对本申请的实施例进行详细说明。需要说明的是，在不冲突的情况下，本申 请中的实施例及实施例中的特征可以相互任意组合。

在本申请一个典型的配置中，计算设备包括一个或多个处理器(CPU)、 输入/输出接口、网络接口和内存。

内存可能包括计算机可读介质中的非永久性存储器，随机存取存储器 (RAM)和/或非易失性内存等形式，如只读存储器(ROM)或闪存(flash  RAM)。内存是计算机可读介质的示例。

计算机可读介质包括永久性和非永久性、可移动和非可移动媒体可以由 任何方法或技术来实现信息存储。信息可以是计算机可读指令、数据结构、 程序的模块或其他数据。计算机的存储介质的例子包括，但不限于相变内存 (PRAM)、静态随机存取存储器(SRAM)、动态随机存取存储器(DRAM)、 其他类型的随机存取存储器(RAM)、只读存储器(ROM)、电可擦除可编 程只读存储器(EEPROM)、快闪记忆体或其他内存技术、只读光盘只读存 储器(CD-ROM)、数字多功能光盘(DVD)或其他光学存储、磁盒式磁带， 磁带磁磁盘存储或其他磁性存储设备或任何其他非传输介质，可用于存储可 以被计算设备访问的信息。按照本文中的界定，计算机可读介质不包括非暂 存电脑可读媒体(transitory media)，如调制的数据信号和载波。

实施例一

本实施例涉及一种可信网络的证书签发方法。从证书签发的角度，将该 可信网络的成员分为证书权威(CA)和证书申请方。CA类似于Privacy CA系 统中的Privacy CA、DAA认证系统中的可信发布方、我国的身份认证系统中 的可信第三方等，也可以是根据(n，t)门限体制建立的虚拟CA，也可以是经过 上述Privacy CA等权威机构授权的可以颁发证书的管理方(如可信子域的管 理服务器)，等等。CA负责接收其他网络成员的证书请求，进行验证和签 发证书。可信网络中除CA外的其他成员均可作为证书申请方发送证书请求。 证书申请方的可信计算平台可以是PC、智能手机、PDA等各类用户终端， 或者各种服务器或其他设备的平台，这些平台中均嵌入有可信模块，即嵌入 在设备平台中为用户和平台提供安全保障的可信计算的核心模块如TPM或 TCM等。

如图3所示，本实施例的证书签发方法包括：

步骤110，该证书申请方的可信计算平台在所有者的授权下，其内部的 该可信模块生成一对密钥，包括第一身份公钥和第一身份私钥，第一身份私 钥保存在该可信模块内部；

该对密钥的生成可以采用类似于PCA系统中AIK密钥或我国的身份认 证系统中PIK密钥的方式生成。该步骤及后续对第一身份公钥和第一身份私 钥的相关处理的内容是可选的。

步骤120，证书申请方的可信计算平台向证书权威(CA)发送证书请求， 携带该证书申请方的用户身份信息和平台信息；

本实施例中的平台信息包括上述第一身份公钥，及该证书申请方的可信 模块签署(EK)证书或其别名证书，但本明申请不局限于此。如我国的身份认 证系统中，TCM是将PIK私钥对可信方公钥杂凑值和PIK的公钥进行签名 获得的PIK签名发送给可信方，由可信方进行验证。至于本实施例增加的用 户身份信息，可以是身份证号、邮箱、ID号等唯一标识用户的信息，及表述 一些用户属性的信息，如地址、学历等等，本申请不做限定。

可选的，证书请求中的用户身份信息和平台信息或者其中的部分信息经 过第一身份私钥加密，CA可以用第一身份公钥加以解密。关于证书签发过 程中对传输的信息的加密可以参照PCA等系统，本文不做过多描述。

步骤130，该CA收到证书请求后，验证所述用户身份信息和平台信息， 如验证通过，为该证书申请方签发平台及用户身份证书，该平台及用户身份 证书的签名的主体部分包含该证书申请方在该可信网络中的用户标识和平台 标识；

对于平台信息的验证可以参照现有系统如PCA系统、DAA系统及我国 的身份认证系统中的规定。本实施例中，该CA对平台信息的验证包括对EK 证书或其别名证书的验证。对用户身份信息的验证方式可以参照现有网络访 问层的用户身份认证，如查看身份证位数、校验位是否正确，是否是公安局 颁发的真正合法身份证；邮箱是否是个真实的邮箱地址等。

上述签发(签署和发送)的平台及用户身份证书可以遵循X.509标准(但 不局限于此)，证书中包括主体部分(tbsCertificate)、签名算法标识部分 (signatureAlgorithm)和签名值部分(signatureValue)，signatureValue是使 用signatureAlgorithm部分指定的签名算法对tbsCertificate证书主题部分签名 后的值。文中，将证书中的主体部分和签名值部分统称为签名。该平台及用 户身份证书的签名的主体部分的其他内容可以参照X.509标准。本实施例中， 该平台及用户身份证书的签名的主体部分还包括第一身份公钥。

本实施例中，证书申请方的平台标识为可信模块标识如TPM ID或TCM ID，但也可以是MAC地址、机器识别码等可用于证明平台可信的其他标识， 该平台标识可以携带在该证书申请方发送的该证书请求中，也可以由该CA 为证书申请方分配，这样便于对可信网络成员的统一管理。CA分配的TPM ID/TCM ID可以基于证书申请方原有的TPM ID/TCM ID衍生出来，只要唯 一对应到可信网络中的TPM/TCM即可。同样的，证书申请方的用户标识可 以携带在该证书申请方发送的该证书请求中，也可以由该CA为证书申请方 分配，只要唯一对应于可信网络中的用户即可。

本实施例中，CA还对其签发的证书申请方的平台及用户身份证书进行 管理，包括平台及用户身份证书的存储(可存储在证书库中)、更新和注销。

步骤140，该证书申请方的可信计算平台保存该平台及用户身份证书。

上述证书签发过程的描述略去了一些细节的处理，可以参照如PCA系统 等现有的证书签发方式，相对这些系统，本实施例增加了对用户信息的发送 和验证并将用户标识添加到CA签发的平台及用户身份证书中，在根本上实 现了用户与平台的绑定。

在本实施例的一个变例中，在步骤130中，CA验证所述用户身份信息 和平台信息且验证通过后，还为该证书申请方分配基于所述用户标识和平台 标识的一对密钥包括第二身份公钥和第二身份私钥，并将第二身份公钥和第 二身份私钥的信息随平台及用户身份证书一起发送给证书申请方，其中，该 第二身份公钥包含在该平台及用户身份证书的签名的主体部分中，该第二身 份私钥的信息经过加密，如用第一身份公钥或第二身份公钥或CA私钥加密 都可以。所谓基于所述用户标识和平台标识的一对密钥，指该对密钥或其中 的私钥的生成算法所使用的公开参数中包含了该证书申请方的“用户标识和 平台标识”(可以是独立参数也可以是参数的组成部分)，具体可以是CA 生成，或者CA请求专门的密钥生成设备来生成，或者由CA将生成该对密 钥所需的参数加密发送给证书申请方，由证书申请方自己生成。第二身份私 钥可以代替第一身份私钥用于对可信模块产生的数据如PCRs值进行签名， 证明平台及用户身份的合法性及平台环境的可信性。

如图4所示，本实施例可信网络中的证书权威(CA)10包括：

接收模块101，用于接收证书申请方的可信计算平台发送的证书请求， 获取该证书申请方的用户身份信息和平台信息。本实施例中，该证书申请方 的平台信息包括证书申请方的可信模块生成的第一身份公钥、该证书申请方 的可信模块签署(EK)证书或其别名证书。

验证模块103，用于验证所述用户身份信息和平台信息，本实施例中， 对平台信息的验证包括对该EK证书或其别名证书的验证。

签发模块105，用于在验证模块的验证通过后，为该证书申请方签发平 台及用户身份证书，该平台及用户身份证书的签名的主体部分包含该证书申 请方在该可信网络中的用户标识和平台标识，本实施例中，还包含该证书请 求中携带的该证书申请方可信模块生成的第一身份公钥。所述用户标识和/ 或平台标识可以携带在发送给CA的证书请求中或者由签发模块为该证书申 请方分配，其中的平台标识可以为该证书申请方的可信模块标识。在另一实 施例中，签发模块105在验证模块的验证通过后，还可以为该证书申请方分 配基于所述用户标识和平台标识的一对密钥包括第二身份公钥和第二身份私 钥，该第二身份公钥包含在该平台及用户身份证书的签名的主体部分中。

管理模块107，用于对签发模块签发的证书申请方的平台及用户身份证 书进行管理，包括对平台及用户身份证书的存储、更新和注销。

本实施例可信网络成员(本实施例中是作为证书申请方)的可信计算平 台20除可信模块外，还包括：

密钥生成模块201，用于在所有者的授权下，其内部的该可信模块生成 一对密钥包括第一身份公钥和第一身份私钥，该第一身份私钥保存在该可信 模块内部。该模块可选。

证书申请模块203，用于向证书权威(CA)发送证书请求，该证书请求中 携带该证书申请方的用户身份信息和平台信息，所述平台信息可以包括该证 书申请方的第一身份公钥，及可信模块签署(EK)证书或其别名证书。

证书存储模块205，用于保存可信网络的证书权威为本证书申请方签发 的平台及用户身份证书，该平台及用户身份证书的签名的主体部分包含该证 书申请方在该可信网络中的用户标识和平台标识。

以下是本实施例的一个具体应用的示例。

Alice到CA注册，以获得她的身份编号Alice_001及她的平台标识 TPM_001、基于Alice_001&TPM_001的第二身份密钥、平台及用户身份证 书，其过程包括：

Alice授权Alice的可信计算平台，由其内部的可信模块生成一对密钥包 括第一身份公钥Pub_Alice1和第一身份私钥Pri_Alice1，第一身份私钥 Pri_Alice1保存在可信模块内部；

Alice的可信计算平台以EK证书为身份证明，向CA申请注册，携带用 户身份信息及平台信息，其中的平台信息包括EK证书和第一身份公钥 Pub_Alice1，可选地，用户身份信息和平台信息用Pri_Alice1加密；

CA获得Alice的用户身份信息及平台信息并验证它们的合法性后，为 Alice分配用户标识Alice_001和平台标识TPM_001，并签发平台及用户身 份证书。CA还可同时发送CA为Alice分配的基于Alice_001&TPM_001的 第二身份公钥Pub_Alice2和第二身份私钥Pri_Alice2(Pri_Alice2可以用 Pub_Alice1加密)，该平台及用户身份证书的签名的主体部分包含Alice_001 &TPM_001、Pub_Alice1和/或Pub_Alice2；

Alice的可信计算平台收到CA发送的上述信息后，在可信模块中保存该 平台及用户身份证书、用户标识Alice_001和平台标识TPM_001。还可保存 CA分配的Pub_Alice2和Pri_Alice2。

实施例二

本实施例涉及的是可信网络的认证方法，与现有技术的认证方法不同的 是，本实施例的认证方法基于实施例一中CA签发的平台及用户身份证书， 验证方可以同时实现对证明方的用户身份和平台身份的认证。

如图5所示，本实施例的认证方法包括：

步骤210，证明方的可信计算平台向验证方发送证明信息，该证明信息 包括该可信网络的证书权威为该证明方签发的平台及用户身份证书，该平台 及用户身份证书的签名的主体部分包含该证明方在该可信网络中的用户标识 和平台标识；

较佳地，该证明方发送的证明信息中还包括该证明方使用自己的身份私 钥对本证明方可信计算平台的完整性度量值签名得到的签名消息，该身份私 钥对应的身份公钥包含在该平台及用户身份证书的签名的主体部分中。这里 的身份私钥可以是实施例一中的第一身份私钥也可以是第二身份私钥。

步骤220，该验证方收到所述证明信息后，对该证明方的平台及用户身 份证书进行验证，如验证通过，判定该证明方的用户身份和平台身份合法。

对证书的校验除了使用CA公钥对证书中的签名值进行校验外，还可以 通过查看该证书的有效期，查询CA管理的证书库等方式来判断该证书是否 合法、有效。

较佳地，该验证方收到该证明信息后，还使用上述身份私钥对应的身份 公钥解密上述签名消息并进行验证，如验证通过，判定该证明方的可信计算 平台符合完整性的要求。

该可信网络的两个成员分别作为验证方对对端认证通过后，该两个成员 的用户之间建立起网络访问层的安全信道，且同时完成了对对端可信计算平 台的身份认证和完整性校验。

相应的，本实施例可信网络成员(本实施例中是作为证明方)的可信计 算平台20除包括实施例一中的各个模块外，如图4所示，还包括：

认证请求模块207，用于作为证明方向验证方发送证明信息，该证明信 息包括本证明方的平台及用户身份证书及使用本证明书的身份私钥对本证明 方可信计算平台的完整性度量值签名得到的签名消息，该平台及用户身份证 书的签名的主体部分包含该身份私钥对应的身份公钥；

身份验证模块209，用于在收到其他的证明方的证明信息后，对所述证 明信息中的平台及用户身份证书和签名消息进行验证，如验证通过，判定该 证明方的用户身份和平台身份合法，且其可信计算平台符合完整性的要求。

本实施例在认证时，由于提供的证明信息包括平台及用户身份证书，对 该证书的验证同时包括了对平台身份及用户身份的验证，也就是说，证明方 的可信计算平台和用户的身份是绑定的，因而本实施例可以避免平台替换攻 击，并且无需采用其他复杂的处理。

本领域普通技术人员可以理解上述方法中的全部或部分步骤可通过程序 来指令相关硬件完成，所述程序可以存储于计算机可读存储介质中，如只读 存储器、磁盘或光盘等。可选地，上述实施例的全部或部分步骤也可以使用 一个或多个集成电路来实现，相应地，上述实施例中的各模块/单元可以采用 硬件的形式实现，也可以采用软件功能模块的形式实现。本申请不限制于任 何特定形式的硬件和软件的结合。

以上所述仅为本申请的优选实施例而已，并不用于限制本申请，对于本 领域的技术人员来说，本申请可以有各种更改和变化。凡在本申请的精神和 原则之内，所作的任何修改、等同替换、改进等，均应包含在本申请的保护 范围之内。