信息安全综合设计与实践报告

华中科技大学计算机科学与技术学院

《信息安全综合设计与实践》实验报告

题目：动态创建可信执行环境保护用户登录口令

专业：信息安全

班级：0802

学好：U200814083

姓名：李瑞瑞

指导教师：崔永泉

完成时间：2011-12-25

动态创建可信执行环境保护用户登录口令

一、实验概要

云计算作为一种新型计算模式，已逐步被IT界和学术界所接受，采用虚拟化技术构建云平台也越来越流行，用户通过虚拟机使用云平台提供的资源。随着云计算的普及，其安全性也成为了人们最为担心的问题。目前流行的云平台已经提供了一些安全解决方案，比如用户通过ssh远程连接到虚拟机来实现安全访问。然而，由于虚拟机通常采用成熟的商用操作系统，很难确保系统不被木马入侵，对于ssh连接而言，openssh-server在验证用户的时候会将用户口令解密出来，那么恶意软件可以在内存中窃取用户的口令。因此需要在openssh-server验证用户口令时动态创建可信的执行环境来验证用户防止系统中其他恶意软件窃取用户口令。

本系统的全称为“动态创建可信执行环境保护用户登录口令系统”，英文缩写为TeeS。本系统保证了用户登录opensssh-server时的用户口令在服务器上一直是密文状态，为了安全获得用户口令，本系统建立了一个可信执行环境（Trust Execution Environment，TEE）用来保证口令不被恶意软件从内存中盗取，并且利用可信计算技术，可以向用户进行远程证明。

本系统工作在虚拟化平台——Xen之上，充分利用了Xen提供的基本机制，如Hypercall，事件通道，共享内存等机制，从底层保证了系统的安全性。同时为了说明系统的安全性，本系统运用了可信计算技术，通过vTPM可以完成对系统的度量以及向挑战者进行远程证明，从而从密码学的角度向对方证明系统的安全性。

二、实验环境

主机操作系统环境：Windows XP SP3

虚拟机型号：VMware WorkStation

虚拟机系统环境：Ubuntu（客户端虚拟机）、Xen（云端服务器）

云端服务器Xen环境：

Dom0域（Ubuntu）

DomU域（修改后的Ubuntu，为用户远端的虚拟机系统）

miniOS域（小型操作系统，用于解密验证口令

OpenSSH环境：修改后的OpenSSH,可执行常规远程连接服务，也可通过我们设计的客户端软件执行修改后的OpenSSH服务。

三、实验整体框架

在一次普通的OpenSSH会话中，存在着这样的隐患:服务器端程序在验证用户登录

口令时，将口令解密，这时，内存中存在口令的明文，恶意程序或木马此时可以从进程空间中读取出口令。那么，我们的任务就是通过创建一个可信的执行环境MiniOS来进行口令的解密与验证，避免了在原先的服务器端程序的进程空间出现口令明文，达到了消除这种安全隐患的目的。整个系统由虚拟机Dom0，虚拟机DomU，虚拟机MiniOS 以及远程的ssh客户端组成,工作流程如下图所示：

①客户端对口令利用AES加密，并在密文前加上一个特定的字符串如“12345678”，

称这个字符串为Magic number，最后生成一个nonce值，再将整个字符串通过ssh

发送给服务器端。

②服务器端sshd首先解密得到Magicnumber + Eaes( Password )+nonce这个字符串，

通过Magicnumber判断需要创建可信环境验证口令。于是DomU将

Eaes( Password )+nonce，口令解密与验证代码以及shadow文件中该用户对应的

SHA1值拷贝到共享内存中，xen对共享内存的代码段的哈希值扩展到PCR17中；

③启动可信执行环境MiniOS，MiniOS调用共享内存中的口令解密验证代码，对口令

进行验证，并将验证结果（1/0）写入共享内存，xen对结果页+用户名+口令+nonce

的哈希值扩展到PCR18中；

④DomU读取共享内存中的验证结果；

⑤sshd根据验证结果判断用户的登录是否合法。

另外，上面的执行流程由远程证明模块RemoteAttestation监督，确保任何对系统的非法篡改都能及时发现。

四、系统流程及各模块功能

（一）

系统的执行流程如下：

a)远程ssh客户端登录DomU，发送用户名和口令（口令的格式为MagicNumber+口

令密文）+nonce；

b)DomU中的sshd根据口令前的MagicNumber确定用户要求使用TEE环境登录；

c)Sshd利用tee.ko模块分配共享内存，并把AES解密和验证部分的代码拷贝到

共享内存中，同时把shadow文件中该用户对应的SHA1值以及口令密文也拷贝

到共享内存中；并通过xen对共享内存进行度量，把度量值扩展到pcr17中。

d)Sshd利用Dom0中的脚本首先对MiniOS的配置文件和内核进行度量，然后启动

MiniOS；

e)MiniOS通过Load Engine执行共享内存中的AES解密以及验证部分的代码，然

后把验证结果写回共享内存，并对结果页进行度量，并扩展到pcr18中；Sshd从共享内存中读取执行结果，判断客户端提供的口令是否正确，并向客户端进行远程证明。

1、系统启动流程

其中，Dom0是具有管理员权限的域，负责管理Xen平台上其他的虚拟机，管理vtpm，控制系统执行流程。

DomU是系统实际和用户交互的虚拟机，一个Xen平台可以有很多个DomU，每个DomU对应一个用户，而Dom0只有一个。

MiniOS就是对口令进行解密认证的可信执行环境，也是个轻量级的虚拟机，由于MiniOS结构简单，功能单一且固定，比较容易保证其安全性。

sealingkey用于解密得到AES密钥，AES密钥以密文的形式存放在MiniOS中，利用sealingkey解密得到，再利用这个AES密钥解密得到用户登录口令。

2、系统登录流程

设AES加密密钥为Eaes,则系统利用ssh传输的数据为： Magicnumber + Eaes( Password )+nonce；

Eaes经过一次加密存放在MiniOS中，验证时，MiniOS需要先利用sealingkey 将Eaes解密出来，再利用Eaes解密出用户登录口令。而sealingkey由DomU写入到vtpm中。如下：

（二）

1.Dom0的各个模块

Dom0是特权域，该域负责启动Xen平台上的其他虚拟机、管理vTPM、控制系统的整个执行流程。

（1）vTPM Manager

vTPM Manager负责创建并管理vTPM实例。当一个VM被创建时，它将产生一个vTPM实例，并将其关联到该VM。

当运行半虚拟化的DomU时，vTPM Manager还有一个用途。它重定向来自DomU （通过监听后端设备/dev/vtpm）的命令到相应的vTPM实例。

在其运行的主机上，vTPM Manager需要一个硬件TPM（或者是模拟器）。该TPM 用来绑定（用TPM密钥和PCRs进行加密，确保数据仅仅能够在预期的状态系被TPM 解密）vTPM实例的非易失性存储器数据，并保存到硬盘驱动器上。也可以将TPM 命令直通到该硬件TPM（但是该功能从未被使用过）。

引入了5个TPM命令使vTPM实例可以和vTPMMananger交互（vTPM Manager 将以vTPM实例的身份执行命令）：

●VTPM_ORD_SAVENVM：通知vTPMManager保存（绑定）vTPM实例的非易失性存

储器到磁盘上。

●VTPM_ORD_LOADNVM：通知vTPMManagerd读取（解绑）已经保存到磁盘上的vTPM

实例的非易失性存储器的数据，并将解绑后的数据发送给vTPM实例。

●VTPM_ORD_TPMCOMMAND：通知vTPMManager由硬件TPM执行通过参数传递的命

令（但是并不是每个命令都可以发送到硬件TPM，vTPMMannager会对它们进行

过滤）。

●VTPM_ORD_GET_MIG_KEY：该命令用于在迁移过程中获得迁移密钥。

●VTPM_ORD_LOAD_MIG_KEY：该命令用于在迁移过程中加载迁移密钥到vTPM

Manager中。

还引入了5个TPM命令使其它的组件可以与vTPM Manager交互。它们是特权命令，它们不是由VM发出的，而是由Xen热插拔脚本（hot-plug scripts）或者vTPM迁移守护进程发出的。它们是：

●VTPM_ORD_OPEN：通知vTPM Manager创建或者重新打开一个vTPM实例。

●VTPM_ORD_CLOSE：通知vTPM Manager关闭该vTPM实例（通常当VM关闭

时）。

●VTPM_ORD_DELETE：通知vTPM Manager关闭该vTPM实例，并永久地删除

它。

●VTPM_ORD_MIGRATE_OUT：该命令用与在迁移过程中发送vTPM实例的状态

和数据。

●VTPM_ORD_MIGRATE_IN：该命令用于在迁移过程中接收vTPM实例的状态和

数据。

可以在tools/vtpm_manager/manager/vtpm_manager.h中找到关于TPM/vTPM 命令的更多的信息。

vTPM Manager守护进程的名字为vtpm_managerd，它的源代码可以在Xen源码树的tools/vtpm_manager/manager/目录下找到。

vTPM Manager创建了3个线程：一个用来监听来自热插拔脚本（还有vTPM迁移守护进程）的命令；另一个监听来自半虚拟化虚拟机（后端驱动）的命令；最后一个监听来自vTPM实例的应答。

vTPM Manager使用了如下文件：

●/var/vtpm/vtpm.db：这是一张VM到vTPM实例的映射表。你可以在第一

列插入domain的名字，在第二列插入vTPM实例的id号，从而关联该

domain到固定的vTPM实例。那么每次你启动该虚拟机的时候它将会与表

中所指定的vTPM实例关联。

●/var/vtpm/VTPM：该文件包含由vTPM Manager维护的vTPM实例的状态。

当vTPM Manager启动的时候，读取该文件并加载状态；当vTPM Manager

退出的时候，把更新后的状态写回该文件。

●/var/vtpm/vtpm_dm_%d.data：这些文件包含了绑定的vTPM实例的非易失

性存储器的数据。

（2）vTPM实例

vTPM实例就是VM的TPM，每个VM在整个生命周期中都有一个vTPM实例随之一起运行，所以vTPM实例的数目和运行中的VM（这里的VM指的是配有vTPM设备

的虚拟机）的数目是相同的。每个vTPM与VM之间的关联是独一无二的。Xen中实

现的vTPM是基于软件的，所以，vTPM实例就是一段运行在Dom0中的代码。

vTPM实例的守护进程叫做vtpmd，它的源代码位于Xen源码树的tools/vtpm/目录下。该守护进程不是直接由用户手动启动的，而是由vTPM Manager自动启动

的。它接收三个参数：

● startup_mode：可以是clear、save或者deactivated。

● type：对于半虚拟化应该是pvm，而对于全虚拟化是hvm。该参数

用于设置vTPM实例与其它组件的通信方式。

● dmi_id：vTPM实例的标识符。

当vTPM实例启动的时候，在初始化阶段它会试着恢复以前的数据（启动模式startup_mode为save）。vTPM实例的数据就代表它的非易失性存储器（如，SRK，

EK等）。每次调用TPM_SaveState都会进行保存，当编译时定义了宏

TPM_STRONG_PERSISTENCE（在tools/vtpm/tpm/tpm_emulator.h中可以找到）时，每执行一个命令都会进行保存。vTPM实例并不自己存储或者回复它的数据，而是

通过vTPM Manager进行磁盘访问。

对于运行中的vTPM实例，它仅仅等待将要执行的命令，并通过相同的通信通道发送响应数据。

（3）Run Scripts

Run scripts主要用来负责启动TEE可信执行环境，并对其进行度量然后把度量值扩展到相应的pcr中。

（4）Xensp.ko模块与虚拟LPC

虚拟LPC作为一个沟通Xen虚拟机管理器与Domain 0再到Domain 0中的vTPM管理器vTPM 管理器应用程序信息流通管道，负责从Xen向vTPM管理器传递信息、从vTPM管理

器向Xen反馈信息以及从vTPM管理器向Xen传递信息、从Xen向vTPM管理器反馈

信息，起着非常重要的作用。真实的物理TPM芯片到CPU的数据传输时通过物理

LPC总线来传输的，其速度上限为16MB/s，而虚拟LPC的传输速度是内存的写入和

读取速度，大约为8GB/s，其性能相差500倍。

（1）虚拟LPC的构成

由于虚拟LPC是从Xen虚拟机管理器层向Domain 0的客户操作系统内核层传递信息，然后再从Domain 0的客户操作系统内核层向vTPM管理器的应用程序层传

递信息，因此组成此信息流管道的两处信息流节点分为Xen虚拟机管理器层到客户

操作系统层和客户操作系统层到应用程序层vTPM管理器两个部分，这两个部分分

别以不同的形式实现。虚拟LPC的信息流构成如下图所示。

控制流

图虚拟LPC的信息流向构成图

①从Xen虚拟机管理器到客户操作系统内核的信息流管道以虚拟中断的形式存在，

Xen与客户操作系统的交互主要通过模拟设备中断的方式产生虚拟中断来通知客户操作系统某一事件的发生，而且此处传递的是控制信息，不包含实际的数据，Xen 虚拟机管理器向上传递的控制信息具体的是一个事件信息，通知设备驱动共享内存中有数据这一事件的发生。

②从Xen虚拟机管理器向应用层的vTPM管理器传递信息的信息流管道则是以共享内

存的形式存在，此处传递的是数据信息，vTPM管理器向下层的Xen虚拟机管理器传递的信息则包含数据和控制信息两种，因为vTPM管理器可以直接通过读写共享内存来向Xen传递信息，当然，传递的信息是数据信息，这就要做好Xen中这块共享内存的利用，其中涉及到数据格式的协议的设计。

由于Xen与vTPM管理器的交流是双向的，当Xen向共享内存中写数据时，则通过虚拟中断的形式通知驱动再通知vTPM管理器从共享内存中读数据，当vTPM 管理器向共享内存中写数据时则通过Hypercall（类似与传统操作系统中的系统调用）的形式通知Xen从共享内存中读取数据。

（2）虚拟LPC的控制信息流

由于虚拟LPC是沟通Xen到Domain 0再到vTPM管理器的桥梁，其间的控制信息流向表现的非常明显，因为在传递数据之前必须通过某种方式使得发送方和接收方达到协调一致的状态才能开始传输数据，主要表现在，可以通过控制信息的传输平台来控制数据传输的开始、结束，甚至是暂停和恢复，这样就可以减少不必要的数据传输，节约了数据通信的带宽，因此，在数据传输之前必须传递控制信息来控制发送方和接受方的状态。虚拟LPC中控制信息流向如图所示。

图虚拟LPC控制信息流向图

①虚拟LPC的控制信息流的构成

对于应用程序层的vTPM管理器可以通过虚拟设备驱动的读设备操作处于阻塞状态，此处的阻塞状态不同于轮询等待这种低效率的方式，而是放弃cpu时间片进入休眠状态等待设备的中断来唤醒vTPM管理器。Xen通过虚拟中断的方式通知虚拟设备唤醒虚拟设备的读操作，此时应用程序可以从读设备操作中返回，至此，Xen 可以通过上图中右边的线路将控制信息传递给vTPM管理器。

当vTPM管理器尝试向Xen发送控制信息时，vTPM管理器通过操作设备文件调用Hypercall通知Xen数据已经写到共享内存，则Xen可以及时从共享内存中取出vTPM管理器的数据。vTPM管理器向Xen发送控制信息的线路如上图左边的线路所示。

②虚拟LPC的控制信息流管道的建立

对于应用程序层vTPM管理器和设备的控制信息主要通过设备的驱动来实现，而设备和Xen的控制信息则由Xen本身提供的Hypercall机制和虚拟中断机制来实现。如图3-2-2所示，右边的控制信息线路，Xen通过虚拟中断通知设备数据已到达共享内存，则设备的读操作立即返回，vTPM管理器可以通过返回值来判断数据来自共享内存还是通过Xenbus来自其他虚拟机，然后vTPM管理器可以读取相应的数据；左边的控制信息线路，vTPM管理器通过设备驱动的一个操作调用Hypercall 通知Xen，则此时Xen可以立即读取共享内存中由vTPM管理器写入的数据。（3）虚拟LPC的数据信息流

对于虚拟LPC的数据流式紧跟着控制信息流的发生而发生的，即从时间观点上看，控制流信息和数据流信息的传递时一先一后紧接着发生的。而数据信息流管道的实现却和控制信息流管道的实现有着本质的区别。数据信息流向如图所示。

图虚拟LPC数据信息流向图

①虚拟LPC的数据信息流的构成

由于共享内存由Xen直接向应用程序层的vTPM管理器提供映射机制，所以，vTPM管理器可以和Xen通过共享内存来交流信息。

关于数据的格式协议如图3-2-4所示，其中包括：

a. 前端Dom ID：前端客户操作系统的ID号，控制请求模块用该字段来确定应该将控制请

求发送到哪个客户操作系统中。

b. 信息流向：用来标识数据是由vTPM管理器写入供Xen读取还是由Xen写入供vTPM管理

器读取。

c. 数据长度：该字段用来指明其后有用数据的长度。

d. 数据：实际发送的数据内容。

e. 结束符：同步信息，表示一个包的结束。

图3-2-4数据包的格式

②虚拟LPC数据信息流管道的建立和拆除

虚拟LPC的数据信息流管道的建立过程是在vTPM管理器初始化的过程中完成的，如图所示。

图虚拟LPC的数据信息流管道的建立过程

2.DomU的各个模块

（1）Sshd模块

Sshd是在openssh的基础上增加了TEE的相关功能，首先在用户登录时会判断用户是否要使用TEES的功能进行安全登录，如果用户选择了TEES安全登录（根据口令前面的MagicNumber是否为“012345678”判断），那么将会启动MiniOS利用可信执行环境进行登录。

具体流程如图3-4-1所示：

图sshd验证过程

（2）tee.ko模块

tee.ko运行在DomU的内核态，由sshd调用。它导出了设备文件/dev/tee。它通过ioctl向用户态的应用程序提供了两个接口命令：VMS_EXEC和VMS_GET_RESULT。

VMS_EXEC命令完成了以下功能：向共享内存中拷贝代码段、与Xen进行交互、与MiniOS进行同步；VMS_GET_RESULT命令用于用户态的应用程序从共享内存中读取结果信息。

（1）共享内存

这里的共享内存指的是DomU和MiniOS之间的共享内存，其实Xen本身就提供了共享内存机制，但是由于Xen本身的共享内存机制每次只能共享一页的内存，而本系统要共享256页虚拟地址连续的内存，所以Xen本身的共享内存机制并不能满足我们的要求。

为了实现在虚拟机之间共享大片的内存，本系统修改了Xen的源码，使其符合我们

的要求。原理是这样的：首先DomU和MiniOS分别在内核态申请256页的内存，然

后DomU通过Hypercall通知Xen修改MiniOS中所申请的256也内存的页表项，使

MiniOS中的虚拟内存与DomU中的虚拟内存引用相同的物理页，从而达到内存共享

的目的。

（2）AES解密和验证代码段

由于要防止DomU中的恶意软件从内存中读取用户的ssh登录口令，所以口令明文

是不能出现在DomU中的，只能出现在可信执行环境MiniOS中，

（3）与MiniOS进行同步

3.MiniOS中的各个模块

Load Engine模块

MiniOS与DomU之间是通过共享内存通信的，包括解密口令和验证的代码，并且要

在MiniOS中执行这段代码，所以在执行之前必须要把相应的资源都载入到MiniOS

中，为其建立执行环境。要载入的资源包括：共享内存、共享的AES密钥等。

该模块主要完成了以下功能：

（1）分配共享内存；

（2）映射DomU的共享内存；

（3）解密出共享的AES密钥；

（4）执行验证代码；

（5）对结果页求SHA1，扩展到pcr7中；

（6）通知XenMiniOS执行完毕。

五、相关加密算法与技术

1、AES加密算法

高级加密标准（Advanced Encryption Standard，AES），在密码学中又称Rijndael加密法，是美国联邦政府采用的一种区块加密标准。这个标准用来替代原先的DES，已经被多方分析且广为全世界所使用。经过五年的甄选流程，高级加密标准由美国国家标准与技术研究院（NIST）于2001年11月26日发布于FIPS PUB 197，并在2002年5月26日成为有效的标准。2006年，高级加密标准已然成为对称密钥加密中最流行的算法之一。

当前DES和三圈DES应用也比较广泛，DES和AES的对比，如表3-4-1所示：

表 3-4-1DES和AES的对比

基于AES的高效率、高安全性以及提供三种不同的安全级别等特性，我们选择了AES 作为加密算法。

2、SHA1校验算法

SHA是安全散列算法（Secure Hash Algorithm)的简称。SHA-1由美国国家安全局（National Security Agency)设计，1995年由美国标准与技术研究所（NIST）发布，作为联邦信息处理标准。它的使命是接替它的前辈SHA-0.后者在1993年发布，并且很快被证明存在显著缺陷。SHA-1使用在一些被广泛使用的安全协议和应用中，如IPsec等。

3、虚拟化环境下的远程证明技术

远程证明指可信平台使用AIK对当前平台配置信息的PCR值进行签名，报告给远程挑战者以证明其平台状态的可信性。每个TPM存在唯一的背书密钥（Endorsement Key, EK），TPM出厂时都会由TPM厂商签发EK证书来唯一标识可信平台的身份。在对外认证时，一个TCG（Trusted Compting Group）实体要向远程挑战者证明其当前真实的软硬件配置，最简单的方法是使用一个仅属于它自己的私钥，并且使挑战者相信对应的公钥属于它的，这可以通过CA（认证中心）签发的身份证书来完成。然而对于可信平台的身份认证，不仅需要个人隐私来证明其身份，还要尽可能少暴露个人隐私。所以，TCG规定不能使用EK用作身份认证，而使用身份认证密钥AIK以作为EK的别名。TPM使用EK生成AIK，并通过私有CA签发的 AIK 证书来完成身份认证。

远程证明过程有三个阶段，分别为完整性度量、存储和报告。

完整性度量和存储指可信平台在启动时度量整个启动过程中按序装载的所有软件和关键的平台配置，并存储在PCR中，可信度量有一个绝对可信的源头，称为核心度量可信根CRTM，被固化到BIOS中。它是可信平台第一个获得控制权的模块，这个模块在将控制权交给BIOS前对BIOS进行度量，按照同样的方法，以后CPU的控制权交给下一个模块前都会先度量它，依次构建相互信任的可信链。系统启动时度量顺序依次是BIOS、引导加载程序、操作系统内核、设备驱动和服务和应用程序等，这些度量值作为完整性标识存储在PCR中，假如有任何软件和平台配置被篡改了，PCR值必然发生改变。由于TPM的PCR个数有限，没有足够存储空间来存放这些度量值，TCG通过扩展操作来修改PCR值，当需要将某一新的度量值记录在TPM 内部，则将其连接在某一当前PCR值的后面，并对串连值采用安全散列算法进行哈希运算，然后替换旧的PCR值。所有对PCR值扩展的操作的历史记录都会被记录在存储度量日志（SML）中。

完整性报告指被证明平台将TPM中的完整性度量值报告给远程挑战者，这一过程通过使用挑战/回应协议来完成：远程挑战者产生一个随机数nonce对某一可信平台发起挑战请求，最终获取到可信平台用自身AIK密钥签名的PCR值，由于签名算法中加入了nonce，挑战者可以知道签名的新鲜性，以防止重放攻击。可信平台

除了发送已签名的PCR外，还应该包括有存储度量日志SML和AIK证书，通过验证AIK证书、AIK签名和nonce的合法性证实平台的身份，判断SML中的PCR值是否来自该平台，平台上运行了何种软件以及平台处于何种状态，挑战者将PCR值与期望值比较可以验证被证明平台的可信性。

远程证明协议如图3-3-1所示，并给出相应的步骤。

图：远程证明协议

步骤1：TEE后端度量受保护进程的代码段和数据段（以下简称SEG），即执行操作：

Domain 0里面一直运行TEE后端守护进程，首先Domain U通过共享内存发送目标程序的进程名给Domain 0，接着Domain 0响应请求，回复确认信息，Domain U 就启动目标进程，同时TEE后端驱动监控在Domain U中的目标进程，将目标进程的代码段和数据段一起作哈希运算：SHA1（SEG），再把最初PCR16中记录的值和SEG 度量值串联起来，作哈希运算得到160比特的值，之后调用创建的vLPC通道，将新值通过PCRExtend操作写入到PCR16中。

步骤2：客户端发出挑战请求，即

用户处于挑战者的角色，创建一个160比特的随机数，初始化认证请求，请求中标明所要查看的PCR索引号即16，然后将认证请求发送到资源节点上的远程证明守护进程，亦即远程证明服务端。

步骤3：使用AIK签名PCR，即

远程证明守护进程与TSS交互，载入AIK，调用TPM_Quote接口对PCR16进行签名。首先，将PCR16和nonce串联并用SHA1算法求出度量值为160比特，然后使用RSA算法用AIK的私钥对此度量值进行数字签名。Tspi_TPM_Quote的调用接口如下：

TSS_RESULT Tspi_TPM_Quote(TSS_HTPM hTPM, /* in */

TSS_HKEY hIdentKey, /* in */

TSS_HPCRS hPcrComposite, /* in */

TSS_VALIDATION * pValidationData) /* in, out */

其中，hTPM为TPM对象句柄，hIdentKey为签名密钥对象的句柄，hPcrComposite

为PCR组件对象，结构类型为TSS_PCRS_STRUCT_INFO，含需要签名的PCR索引号，pValidationData存放对PCR签名的相关信息，包含输入数据和输出数据，输入数

据指定完成签名需要的额外数据如nonce，用于防止重放攻击；输出数据记录签名

成功后获取到的TSS_PCRS_STRUCT_INFO结构和签名的PCR值。

步骤4：反馈报告，即

远程证明守护进程将以下信息发送到用户：已签名的PCR值，AIK证书，还含

有PCR值经过SHA1操作之后经过填充之后的TSS_PCRS_STRUCT_INFO结构，这个结

构具体来说由四部分构成：

（1）TPM本身的版本信息，4字节，在这里是基于TSS1.2的；

（2）MAGIC信息，即字符串“QUTE”，4字节；

（3）PCR经过填充之后的哈希值，对于PCR16来说，哈希值的计算方式是SHA1（“\x00\x03\x00\x00\x01\x0\x0\x0\x14”||PCRvlaue），20字节，这部分最终用

于用户验证PCR值；

（4）防重放攻击的nonce值，也就是远程证明客户端发送过去的nonce，20

字节，最终用于用户判断nonce值是否新鲜。总共48个字节。

步骤5：用户验证资源节点AIK证书，即

这一步骤验证AIK证书的合法性。用户通过CA证书验证AIK证书的合法性，

即验证AIK证书是否为CA所签发。通过调用Tspi_Hash_VerifySignature接口实

现AIK证书的验证，接口描述如下：

TSS_RESULT Tspi_Hash_VerifySignature(TSS_HHASH hHash, /* in */ TSS_HKEY hKey, /* in */

UINT32 ulSignatureLength, /* in */

BYTE* rgbSignature); /* in */

其中，hHash表示哈希对象实例的句柄，这里的哈希对象指AIK证书数据的哈

希值，hKey表示用于验证签名的CA公钥对象的句柄， rgbSignature指向AIK证

书的签名数据，数据大小用ulSignatureLength表示。

步骤6：验证AIK签名，即

这一步骤验证AIK签名的合法性。安全管理服务从TSS_PCRS_STRUCT_INFO中

获取到segPCR，与nonce串联后计算其哈希值，得到SHA1（segPCR||nonce）;另

外使用AIK的公钥解密已签名的PCR值，得到，如果两者相等则AIK签名是合法

的，否则segPCR被篡改了或者nonce不是新鲜的。

如同步骤5，验证AIK的签名需要调用Tspi_Hash_VerifySignature接口，这里的hHash为，hKey指用于验证签名的AIK公钥对象的句柄， rgbSignature指向所在的内存块，内存大小用ulSignatureLength表示。

步骤7：用户判断节点是否可信，即

用户读取SML，其中包含每次扩展代码段和数据段SHA1之后得到的SEG，按照扩展的顺序执行循环操作：

while（SEG!=NULL） {

newPCRvalue=SHA1（oldPCRvalue||SEG）;

SEG=SEG->next;

}

通过这样的计算可以得到预期的PCR值newPCRvalue，但是这样还不能达到认证的目的。回想步骤四，我们得到的并非是PCR的PCRvalue的明文，而是一个结构体TSS_PCRS_STRUCT_INFO，不过我们可以通过其中第三部分值PCR_DIGEST完成证明操作。具体来说，我们可以仿照Tspi_TPM_Quote函数中计算PCR_DIGEST的步骤得到通过日志计算得来的期望的PCR_DIGEST值，即PCR_DIGEST=SHA1（“\x00\x03\x00\x00\x01\x0\x0\x0\x14”||newPCRvlaue），再与步骤四中得到的结构TSS_PCRS_STRUCT_INFO中PCR_DIGEST值比较，就可以验证间接地验证两个PCR 值是否相等。如果相等则可以证实远程SEG是安全可信的，否则不然。SEG的度量期望值可以来自用户提交的部署请求文件。

六、实验结果

1、功能测试

（1）登使用一般OpenSSH登陆方式时的系统测试

用户通过一般的ssh远程连接自己的虚拟机，openssh-server在验证用户的时候会将用户的口令在内存中解密出来，那么攻击软件可以在内存中窃

取用户的口令明文。

直接在客户端虚拟机终端中执行ssh远程登录命令。见下图。其中所连接的云端用户虚拟机系统DomU域的IP地址为：192.168.182.151。bob用户的密

码为：is2011。

图一般登录过程

木马程序可以将口令窃取，写入到/tmp/password文件中，如图所示：

图木马程序打印出登录口令明文

（2）在TeeS保护下利用OpenSSH登录时的测试

在客户端系统中运行我们设计的安全登录客户端远程登录程序，远程登录用户操作系统DomU，如图所示，登录的用户为alice，登录

口令为is2011：

图TeeS保护下登录

此时，若木马程序再次发生攻击，则得不到口令明文，如下图：

图有TeeS保护时木马程序打印出的登录口令

可见，在TeeS保护下，木马程序最多只能得到口令密文。

2、性能测试

系统性能直接影响到用户的登陆时延，如果由于我们的口令解析过程而使得登陆时延过长，那么将使得用户无法接受。因此我们需要将用户从发出登陆请求到登陆成功的时延控制在3s以内。

为了测试登陆时延，我们编写了相关的小程序。其中登陆时延的实现是计算系统接受到口令到允许登陆的时间差。同时我们还计算了系统的用户态和内核态所用的时间片时间。相关测试数据见下表。

表系统性能测试

根据登陆时延测试数据，登陆时延<3s，由此说明我们的口令解析系统对整体系统的性能影响是很小的，不影响用户的使用。

七、实验创新

本系统具有以下创新点：

?从底层出发，具有较高的安全性

本系统从比操作系统更底层的Xen系统出发，在Xen系统上构建多个虚拟机进行通信，验证。负责验证的可信执行环境MiniOS就是一个轻量级的虚拟机，它与作为服务器的虚拟机DomU在不同的操作系统中。操作系统层面上的独立有效地将可信执行环境与不可信的执行环境隔离了起来。

又由于可信执行环境MiniOS功能单一，结构简单，因而其流程的控制与校验都很容易，通过远程证明系统可以有效地控制可信执行环境的安全性，从而保证了整个系统的安全。

?可信执行环境可以共用，提高了资源利用率

在云服务中，系统中的每一个DomU对应一个用户，每个用户有自己的虚拟机，但是通过配置，对他们进行登录验证的可信执行环境可以是同一个MiniOS。由于登录验证的时间毕竟只占总的在线时间的很少的一部分，因此一个MiniOS就可以验证大量的登录过程。不需要对每个用户都临时创建一个可信执行环境，既有较快的响应时间，又有较高的资源利用率。

?对口令与服务器进行了强隔离

系统中，口令明文只出现在可信执行环境MiniOS中，服务器的内存空间里口令只能以密文形式存在，不可能出现口令以明文方式出现在服务器的进程空间中的情况。从根本上

杜绝了木马从服务器里窃取口令的可能性，具有很高的安全性。

通过远程证明技术，使用户能够了解服务器状态

云服务中，一个很大的问题在于，用户不知道云端的服务是否被非法篡改过，将自己的资料与数据放上去是否安全。这里通过远程证明技术，审计，验证了每一个执行流程，对于与预计步骤不相同的步骤，给出了异常的警告。从而让客户端明白云端是否在按合法流程执行，一定程度上打消了用户的不安全感，有利于云服务的推广。