虚拟可信平台（共7篇）
虚拟可信平台 篇1
0 引言
云计算技术从一定程度上来说是种计算模型, 还可以说是一种运营模式, 它能给IT企业或者其他行业带来福音, 能进行有效管理, 积极合理分配零散资源, 能帮助企业在很大程度上减少开销。同时, 随着先进网络等计算机技术的迅猛发展, 如何将数据安全地存储、操作等问题就显得尤为重要了。因此, 对数据的安全问题研究也迫在眉睫。
在许多有关云计算的安全问题中, 用户和企业最为关注的则是数据处理和存储中信息的完整性、有效性和保密性等问题。若数据基于个人设备中存储时, 用户负责数据的安全和处理操作, 但如果数据是基于云计算服务的, 则用户本身不具备对数据的控制了, 由各大云计算服务提供商对数据处理和保护等措施, 整个过程由服务提供商负责, 数据用户不做参与。因此, 怎样确保数据数据的安全性, 增强用户对云计算服务提供商提供的服务是安全可信的, 这就需要在云计算服务提供商和数据用户之间建立相互信任的机制。
1 虚拟机迁移技术
1.1 TCCP模型
2009年Santos[1]已把信任的相关问题与云计算的环境相结合了, 其中的TCCP模型主要目的是利用可信计算技术来使得数据不被非法篡改或非法访问, 其模型如图1所示。其中, ETE是外部可信实体, TC (Trusted Coordinator) 是可信协调者, TN (Trusted Node) 是可信节点, CM (Cloud Manager) 是云管理者。
用户的数据信息存储的主要载体是云存储环境中的物理硬件设施, 而TCCP模型是以最底层的物理设施为基础来实施架构的, 这样的结构有利于数据的集中管理控制及安全保护。VMM (Virtual Machine Monitor) 虚拟机监控器在TN可信节点中为每个VM (Virtual Machine) 构造了一个Black Box黑盒环境, 虚拟机内部信息就不会被用户所知, 这样用户只能通过提供的相应功能来使用虚拟机。因此, 有了以上的相关安全措施, 虚拟机的信任区间的创建和转换迁移则是云计算环境里信任问题研究的关键了。
1.2 VM虚拟机和虚拟可信平台模块v TPM的迁移
虚拟机的迁移在虚拟化进程中是个非常重要的工作[2], 若数据用户在使用虚拟移动设备, 或者云存储系统资源需统一管理, 又或云系统资源负载需均衡时, 虚拟机的迁移操作能产生积极的影响和益处。允许虚拟机从一台物理服务器迁移到另一台服务器上的动态特征 (Live characteristic) , 将不会阻止正常服务的供给。虚拟化平台一旦与可信计算技术相结合后, v TPM这个虚拟可信平台的实验环境就能被应用程序利用来完成对数据信息安全有效的存储。怎样做到虚拟机迁移的前后系统状态达到同步一致, 虚拟机和可信平台都要迁移, 文献[3-7]以具体方式或者协议来对虚拟机及可信平台的迁移都有研究。
Berger[4]提出的研究基础是迁移操作的平台是可信的这个假设基础之上的, 因此该迁移协议也能在相同配置的平台间进行, 同时具备的数据完整性机制能使得在迁移中保证数据的安全, 文献还指明同样适用于虚拟机的迁移机制。
虚拟机和其虚拟可信平台模块的完整性对于迁移非常重要, Stumpf和Sadeghi[5,6]分别指出, 传统的加密技术对迁移操作进行加密, 若虚拟机和对应的v TPM的数据被篡改时容易被察觉。Sutmpf的文献[5]中, 则是利用完整性验证过程来对数据进行完整性保护。
文献[3]和文献[5]中的协议比较相似, 在Xen的迁移协议负责初始化迁移过程, 再利用迁移密钥加密整个虚拟可信平台v TPM, 然后将加密了的模块传到目的平台。最终的加密虚拟平台因为自身的密钥结构不清晰, 对解密和恢复造成了困难, 这也是Xen协议的难点。
2 安全迁移过程的基本需求
文献[8]中, 支持了迁移协议有着一定的缺陷, 例如, 没有上下文支持, 向目的服务器传递授权信息等, 虚拟机和虚拟平台的关联, 数据的完整性和私有性保护等问题。这些不足是在协议设计最先对协议的需求分析不明确造成的。因此, 鉴于对健壮性和安全性的考虑, 迁移协议都必须以基本的安全需求为基础。
2.1 初始化的正确性
“初始化正确性”这是第一项基本安全需求, 它能对整个迁移过程的初始阶段的正确性来作说明。同时必须是可信实体 (云服务提供商, 源、目的服务器) 才能请求虚拟机及其虚拟平台v TPM的迁移操作, 该操作对于不可信实体是屏蔽了的。这样能通过对参与者约束的方式来降低对系统的威胁, 若不可信实体持续对系统发迁移请求, 可以使系统非正常运行, 即造成拒绝服务攻击Do S。
2.2 虚拟机和虚拟可信平台v TPM的完整性和机密性
“VM和v TPM的完整性和机密性”是第二项基本需求, 目的是保证迁移过程中对象的隐私。从机密性来看, 迁移过程不允许不可信实体获取信息, 因此大大降低了系统泄密的危险。从完整性来看, 在整个虚拟机和虚拟可信平台的迁移前后, 那些肆意的违法操作都能被检测并进行及时处理。
2.3 信任链的保护
“信任链的保护”是第三项基本需求, 目的是保证对象与对象之间的相互信任。因为该需求和其他需求相比较抽象, 必须从互补的角度理解且保障该需求。其目的是要保证对不正确的迁移操作可信服务器不能提供服务, 同时, 不可信服务器不能发请求来进行迁移操作。该需求能对迁移过程的对象建立信任关系, 若源服务器出现问题, 该源服务器的信息将不会被目的服务器接受, 因此与该服务器的连接得减少或者结束。
2.4 时空间的开销降低
“迁移的时间空间消耗尽可能降低”这是第四项基本安全需求了。在整个迁移过程中, 对象的信任关系确认, VM和v T-PM之间数据传输, 加密解密的存储空间的消耗等等, 都应该最小化用以减少时间和空间的消耗, 降低系统的额外开销。
3 迁移方法的描述
综合基于前面文献[3-8]所提出的协议, 本文进一步给出了一个安全的VM和v TPM之间迁移方法细则。如图2所示, 主要由身份验证、完整性验证和数据传输三部分组成。
3.1 身份验证部分
依据安全迁移的第三条需求, 在源服务器和目的服务器间的相互认证是否是可信实体, 一般是通过在源服务器和目的服务器间使用公钥证书, 但是会带来系统额外开销, 为了保证第四条的安全迁移需求, 将使用文献[9, 10]的身份加密机制。
1) 身份加密机制的应用
源服务器和目的服务器的公开密钥可以利用IBE身份加密机制的各自的身份描述获得, 其私有密钥则通过私钥生成器PKG[10]来生成。目的服务器的身份描述信息被获取后, 目的服务器的公开密钥被源服务器构造好之后, 通信信息被该密钥加密。这样以密文形式的通信信息就传输到了目的服务器。相对于DS目的服务器, 利用PKG来取得自身的私钥信息来对密文解密。其交互过程不需要保存系统公钥或证书, 能减少系统的开销, 便于简化公钥管理。
基于身份加密的身份认证部分, 可以分为四个阶段, 系统设置阶段、参数提取阶段和加密、解密阶段。
(1) 系统设置阶段
k为全局安全参数, 以它来构造params系统参数和管理密钥master key。其中系统参数包含有限消息空间M和有限密文空间C。而PKG管理该系统在设置阶段的若干事宜, 在params参数生成后使之公开化, 有且仅有PKG知晓所有相关信息。
(2) Params提取阶段
主要是构造DS与SS相应的身份信息私有密钥。系统的公开密钥保存的是目的服务器的身份描述信息IDDS∈{0, 1}*, 且指定系统参数params和master key管理密钥, 有PKG来提取与目的服务器相应的私有密钥信息d, 以此解密通道的安全信息。
(3) 加密阶段
SS利用DS的身份验证信息、参数信息和认证信息m∈M, 一同构造好认证信息的密文c∈C, 由SS传送给DS来加密认证信息c。
(4) 解密阶段
若接收到SS的加密信息c, 同时DS在向私钥生成器PKG表明了身份并请求私钥信息d之后, 对c解密从而获得认证信息m。
以上四个阶段务必遵循以下的一致性约束, 即给定公开密钥的身份描述信息和私有密钥d, 通过身份描述信息加密的认证信息m一定能被私有密钥d解密, 形式化后:
由于IBE的身份加密机制的公开化特征, 只有私有密钥d是由PKG向目的服务器传递过程中面临攻击的危险, 所以务必要确保d的安全性。因此在参数提取阶段增加了安全信息通道技术来保护私有密钥d, 如图3所示。
2) 安全信道的应用
虚拟的安全通道用以传输加密的数据信息, 同时也可以利用安全信息通道来进行信息交换或者传递敏感信息, 这样不会被外部实体干扰。而建立安全通道的原因有:一方面利用身份认证来建立信任关系;另一方面有利于参与者协商消息加密的密钥。
目的服务器收到SS发来的加密信息后, 向PKG进行身份验证以后通过安全通道或缺私有密钥d来解密消息。其中, 目的服务器构造主密钥MK (Master Key) , 其作用是保护后续的消息认证码 (MACs) 的安全和传输密钥TK (Transmission Key) 。所以需要生产两个64位的x和y, 用y对x加密。即Enc1=DESy (x) , 再用x对y加密, 即:Enc2=DESx (y) 。最后, 这两个加密结果异或操作后得到主密钥, 即MK=Enc1⊕Enc2。这样可以通过检验目的服务器和私有密钥生成器PKG对主密钥的认知度来认证其身份。同时, 被主密钥MK加密后的加密密钥在安全通信信道传输给信息参与者, 也不需要担心传输过程中的信息泄露。
以下是信息参与者确立安全通道的四个步骤:
(1) DS目的服务器在和PKG建立的网络连接后, 在安全通信信道里向PKG表明身份并发请求信号{ID, Enc1‖T, Enc2‖T}, 其中ID是身份描述, ‖是连接符合, 确保Enc的机密性。
(2) 在身份加密机制里, 目的服务器的身份描述对于PKG是透明的, 它能够快速检验目的服务器的身份信息。同时, PKG还能确认接收的信息正确性。通过拆分请求信号的Enc1‖T来获得Enc1, 再通过异或操作构造主密钥MK。新的MK是加密反馈信息, 如{DESMK (T, R) }, 其中时间戳由T表示, R表示密钥生成器生成的64位大整数, DESMK是主密钥进行DES加密后的表示。如果请求信息合法、正确, 则两者构造的密钥是一致相同的;若请求信息不正确, 则新构造的主密钥与目的服务器构造的不一样, 后续过程也会产生错误。同时还会附上由MK生成的消息认证码MAC进行保护。
(3) 目的服务器利用主密钥MK解密反馈信息{DESMK (T, R) }, 若时间戳T解密正确, 则加密操作合法。R则被目的服务器保留来构造传输密钥TK, 目的服务器再向PKG反馈信息{DESTK (T, P) }, 其中P是目的服务器的密码, DESTK是TK传输密钥的DES加密操作。
(4) PKG获得反馈信息后使用R生成传输密码TK, 进行解密后的时间戳T和服务器密码P。若T正确解密, 则反馈信息是正确的。这样四个步骤操作完后, 在目的服务器和私钥生成器PKG之间就建立了一条安全的通信通道。
3.2 相互完整性验证部分
SS和DS进行身份验证后就进行相互完整性的检验。这是完全符合安全迁移的第二项基本安全需求, 同样得保证安全协议的基本要求即迁移场景中的支持组件的完整性。
可信平台模块TPM是以独立实体的形式的应用物流平台为基础, 计算等操作的安全性就是通过把计算融入到过程中来提高的。TPM主要是对物理平台来测量, 负责信息的记录等, 这样就可以掌握物理环境的全貌且能负责外部安全请求[11]。
由于狭小的空间, 可信平台不能将所有信息存储, 需要一个24位的PCR (Platform Configuration Register) 平台配置寄存器来管理且存储摘要值[12,13,14]。其中前五位PCRs (0-4) 与物理平台的个组件对于PCRs (5-7) 这三位是对OS引导程序来度量的;PCRs (8-15) 七位是保留给主机和操作系统OS使用的;PCRs (16) 保存系统调试信息;PCRs (17-20) 度量可信进程的信息;PCRs (21-22) 度量可信操作系统的信息, 最后的PCRs (23) 是预留给指定的应用程序的。PCR的值的属性是只读, 可信平台TPM把值变成可扩展extend的, 即:Extend (PCRN, data) =SHA1 (PCRN‖data) , 其中SHA-1的散列值由PCRN的当前值和数据data来决定。
一旦启动物理平台, CRTM主要记录基本输入输出系统的信息, 其中主要有系统引导加载程序的状态和平台启动运行的硬件情况。物理平台的初始化将信任状态传递给下一组件, 同时下一组件的完整性也由初始化的组件负责, 且决定是否继续传递信任状态, 即是否继续下一个组件的散列值SHA1 (info) , 再调用新的平台配置寄存器值PCRN←SHA1 (PCRN‖SHA1 (info) ) 。
将目的服务器的身份描述“扩展”到PCR平台配置寄存器中, 即可信计算组织TCG的核心“TCG Software Stack”提供的API (如表1所示) 进行扩展操作:PCRN←SHA1 (PCRN‖SHA1 (IDDS) 。DS和SS之间以该扩展方式进行相互完整性检验过程:
(1) 目的服务器将自己的平台配置寄存器值即SigAIK (PCR‖NSS) 反馈给源服务器, 其中AIK是TPM的身份密钥, Nss是源服务器的随机数。
(2) 源服务器接收到了反馈信息后, 先检查PCR中的目的身份描述信息是否正确, 再检验反馈信息中的目的服务器的PCR值以确定其完整性。
(3) 依据 (2) 的目的服务器相同地检验源服务器的完整性。
3.3 数据传输部分
在进行了身份验证和完整性测验后, 即保证了双方的真实可靠性和完整性, 这样在SS和DS之间就可以进行安全的数据迁移操作, 也就是数据传输部分。首先, 目的服务器发送一个随机数NDS给源服务器, 表示它已经做好准备接收VM及其虚拟可信平台模块v TPM了, 若SS源服务器只要接收了NDS则可执行数据迁移。在迁移中必须同步VM及其v TPM的数据信息, 若不能使得两者的状态信息一致, 则应用程序不能保证其完整性也不能完成信息的安全存储。
文献[7]是利用仿真器模拟虚拟可信平台v TPM, 用以替代物理可信平台而将所有功能来实现。该状态的v TPM运行在虚拟机内部, 也就是Xen中的Dom U域。在迁移中要同步二者的状态, 文献[7]是采用“挂起-传输-恢复”的模式, 即:当发出迁移指令后, 源服务器中运行的虚拟机状态通过“xm save”挂起, 且该状态以文件形式保存, 同时该文件还会送给DS且由“xm restore”恢复得到虚拟机。因SS中每一个v TPM都运行在对应的VM中, 则SS的挂起操作就是对其的封装, 相应的DS的恢复操作就是对其的解封。但是这种机制需要同步状态信息, 不适合动态迁移的要求, 因此得引入动态迁移的机制。
Clark等人的虚拟动态迁移可由以下阶段构成, 机制可被抽象为两台服务器之间来做事务处理。
步骤0是SS源服务器向选定的DS发迁移请求, 且该目的服务器具备基本的物理设备资源, 该阶段称为预迁移阶段。
步骤1主要完成目的服务器DS在接收了迁移请求信息后, 考察迁移所需的内存空间等资源, 该阶段是资源预留阶段。
步骤2 Pre-copy算法将虚拟机的内存页拷贝到目的服务器中, 同时, 源服务器的虚拟机运行不受影响。第一次拷贝是将所有页面都拷贝到目的服务器, 接着的每一次拷贝仅拷贝修改过的页面, 这一过程是迭代预拷贝阶段。
步骤3停机拷贝阶段, 若SS中的VM被挂起, VM的CPU状态和不一致的页面发送给DS。拷贝结束后SS和DS都包含了挂起状态的虚拟机的页面。
步骤4迁移虚拟机接收成功的信息被目的服务器发送给源服务器, 同时源服务器SS确认迁移完成, 这是提交阶段。
步骤5在目的服务器DS中的虚拟机VM被恢复同时, IP地址、设备驱动等信息与恢复的VM绑定, 这一过程是虚拟机恢复。
在虚拟机VM和虚拟可信平台间v TPM间完成数据迁移, 需要在步骤3时引入关键的特殊步骤, 利用仿真器模拟出v TPM的状态是运行在Xen的Dom U域, 再由Xen中的进程完成迁移[15,16]。当完成迁移后, 再发送不一致的内存页。当虚拟机实现挂起操作时即表示虚拟机VM所有的操作全部完成, 此时VM和v TPM的交互不再发生, 即是对系统可信的判断依据, 也是将v TPM迁移至DS的最好时机。同时在迁移之后也不需要额外的更新操作。当迁移完成后, 源服务器不保留VM和v TPM, 同时DS目的服务器也转变成VM和v TPM的宿主机。
4 数据迁移方法分析
在迁移方法中的身份确认让双方互相证明可信性。广义来看, 对认证阶段的参与者可确定正在和可信实体交互。若迁移由SS发起, DS如果确认了SS的身份, DS就能确信SS能根据迁移协议完成后续操作, 因此迁移就得到了初始化的合法保障, 满足了初始化正确性的基本要求。
利用Danev等人[7]的传输层协议和公钥证书来实现DS和SS之间的身份验证。而证书机制在证书创建、存储和管理分发阶段都有时空开销。与此相比, 基于身份的加密机在的公开密钥能直接由任意字符串生成, 与专门的PKG私钥生成器构造, 无需预先发密钥, 而是在初始化时验证, 因此能逐步减少系统开销, 为用户增添便捷性和灵活性, 即满足了安全迁移的减低时空开销的需求。
如何将安全有效的密钥信息从PKG发送给DS是身份加密机制的关机之一, 为保障信息交互的安全, 得建立一条安全通道, 可以传递敏感信息。基于安全通信通道的IBE保障了安全迁移中VM和v TPM完整性和机密性的基本要求。
将DS的身份描述扩展到PCR平台配置寄存器中, 能与设备寄存器的度量信息做一致性的检验。SS对DS的完整性做判定, 其中的不一致的信息都能被SS检查到。因此VM和v TPM间的正确迁移, SS和DS的软件及运行状态完整, 即实现了信任迁移的基本需求。
5 实验及结果分析
云服务中的虚拟机与虚拟可信平台模块的数据迁移, 在具备了第2节阐述的安全迁移的基本需求后, 以Xen的开源基础对v TPM提供了虚拟支持, 这样任意的VM都有对应的v TPM来对应, 因此, 要构建配置好虚拟环境, 在Cent OS下安装Xen后, 为宿主OS内核增补以支持开源基础设施Xen。表2是内核配置的设置, 用于宿主系统和虚拟系统的引导。安装了Dom U虚拟机, 进行配置信息“vtpm=[“instance=1, backend=0”]”。其中“backend”是指明和对应的v TPM实例以及TPM在何处进行驱动编译, “0”表示Dom0中, “instance”表示Dom0和Dom1间的通信v TPM实例。“1”表示实例编号。若在Dom U虚拟机中能看到PCR的值, 如图4所示, 则表示在Dom U虚拟机和其对应的Dom0中的虚拟可信平台实例建立连接成功。
用预拷贝Pre-copy做虚拟机内存迁移模拟, 在不同阶段做v TPM的迁移设置。如图5 (a) 表示预拷贝开始之前。记录了被迁移VM的Dom U的状态S, 进行了迁移后状态变为S1, 且记录信息不一致。图5 (b) 是预拷贝的第一轮后。第一轮是把所有内存页拷贝到目的主机, 同时Dom U和v TPM的记录信息都从S变为S1, 且记录信息不统一。图5 (c) 是迁移中的停机拷贝阶段。此时将挂起Dom U, 状态由S也变成S1。且与v TPM不交互, 虚拟可信平台的信息是S1, 迁移后状态信息一致。
6 结语
在本文研究云计算的信任问题中, 虚拟机VM及其虚拟可信平台v TPM的迁移问题是我们重点关注的。考虑了信息终端的数据安全问题, 在数据存储的基本载体层面上对数据信息进行安全保护。若VM和其对应的v TPM在同一环境下, 两者进行数据迁移及信息的保护问题, 将是后续研究的重点。
虚拟可信平台 篇2
火炮的反后坐装置被称为火炮的“心脏”，目前火炮在实际使用过程中，由于测试手段的局限性，而且进行实弹射击危险性较大，不能很好的判断反后坐装置工作是否正常。我们利用虚拟样机技术对火炮反后坐装置的工作性能进行评估，通过仿真试验结果，来检验虚拟样机的可信性。
1虚拟样机的建立过程
我们在Pro/E的环境中按照火炮各体的实际尺寸和动力学特性进行实体建模。对组成火炮系统的各体施加约束力。在此基础上，将实体模型转换成ADAMS环境下的具有动力学参数的实体模型[1,2]。Pro/ENGINEER是由美国PTC（参数技术）公司研发的的三维建模软件广泛应用于电子、机械、模具、工业设计、汽车、航空航天、家电、玩具等行业，是一个全方位的3D产品开发软件[3]。ADAMS是一个动力学分析软件，它能更好地解决复杂系统的动态指标参数[4,5]，按照美国MDI公司开发的通用动力学仿真软件ADAMS和美国PTC公司的CAD软件Pro/E作为基本建模工具，两者之间的接口采用MDI公司开发的ADAMS与专用接口模块Mechanism/Pro（简记为M/Pro）建模的过程如图1。
本系统需要运用ADAMS作为辅助，结合Fortran语言编制仿真模型的用户自定义程序。在ADAMS环境下获得可以仿真火炮动态特性的虚拟样机模型。具体模型如（图2、3、4):
2虚拟样机可信性验证
由于火炮实弹射击试验具有一定的危险性，因此需要专门的试验场地和多方面的人力保障，而且在试验过程中需要通过特殊的测试手段、运用专门的仪器设备才能对火炮的各种参数进行测试，以致于试验成本较高。建立火炮虚拟样机的过程，是一个不断建模———验模———再建模的过程，对于任何仿真试验结果都应进行试验验证，以检验其仿真结果的可信度。由于受经费、场地和测试手段等诸多因素的制约，我们选用某型火炮的定型试验报告提供的火炮测试参数的相关数据和图表曲线，来考核和检验虚拟样机仿真输出结果的准确性。火炮进行定型试验是为了全面检验和考核火炮的战术、技术指标和安全性，通常要对火炮射击时的各主要状态参数进行综合性测试，而且为保证测试数据的准确性，通常对火炮某一测试项目要进行多次试验反复测试，所以试验测试数据既有单发射击的图表曲线，又有多发射击试验数据的统计平均结果，因此运用火炮设计定型试验的数据结果可以对所建立的火炮虚拟样机进行更充分、更全面的考核和验证。
现代火炮采用了反后坐装置后，其炮身通过反后坐装置（驻退机和复进机）与炮架弹性相连，火药气体作用于炮身产生的腔内压力Ppt通过驻退机和复进机进行缓冲，因此炮架的受力由原来的炮膛合力Ppt变为反后坐装置提供的后坐阻力R。实践证明反后坐装置的应用使得炮架实际受力仅为炮膛合力最大值Pptm的几十分之一。反后坐装置的作用如此重要而常常被称为火炮的“心脏”，为此反后坐装置内的各相关动态参数已成为衡量火炮动态性能的重要指标。通常火炮的分析计算和试验测试也都重点考核这些指标参数，所以本文也以这些指标来考核虚拟样机的准确性。
2.1反后坐装置的作用(1)可以极大地减小火炮射击时的受力；(2)将全炮的后坐运动变为可控制的炮身沿炮身轴线的后坐运动，并使其射击后自动恢复到射前位置。
2.2反后坐装置的动作原理火炮射击时，后坐部分的后坐阻力主要由反后坐装置所提供。反后坐装置不同于一般的缓冲阻尼器系统，它实际上是一个结构复杂的缓冲阻尼装置，通过改变流液漏口的面积改变后坐阻力，使其满足一定规律而达到有效控制后坐运动和受力的目的。后坐开始时，驻退机内液体在工作腔分流为两股液流，一股经节制杆与节制环之间的环形漏口流向非工作腔，另一股由驻退杆内壁与节制杆之间的环形通道，经调速筒流入内腔。由于驻退杆不断抽出，驻退机外腔的液流在活塞压强作用下分别流向驻退机非工作腔和内腔。为保证火炮在整个后坐行程上全程制动，驻退机内腔始终充满液体，其压强p2>0。在对驻退机进行试验测试时，主要测试驻退杆外腔和内腔的压强，针对复进机的测试也主要测试其腔内气体压强。
后坐部分复进时，驻退机内腔压强p2>0，内腔液体在其作用下流回外腔。由于真空的存在，驻退机非工作腔在复进开始一段距离内压强为零，只有内腔液体存在压强，复进时驻退机内腔的压强对反后坐装置的影响也很大，在试验鉴定时也作为一个测试项目。复进机的作用是在后坐过程中提供后坐阻力和在复进过程中提供复进动力。在后坐开始时，复进机腔内气体压强不为零，之后随后坐行程增加而逐渐增大，至后坐终止时腔内气体压强达到最大，在复进时其腔内气体压强与后坐时一致。因此，测试复进机内气体压强时只对后坐时的情况进行测试。
2.3虚拟样机仿真数据的可信性分析反后坐装置使火炮由刚性后坐变为弹性后坐，并贮存后坐能量，使后坐部分在后坐终止后可以转为复进。反后坐装置之所以称为“火炮的心脏”，是由于该装置的可靠性将直接影响整个火炮工作性能，甚至使整个火炮丧失工作能力。因此，在火炮设计定型试验时，将反后坐装置作为试验测试的重点，针对反后坐装置的测试项目，主要包括驻退机内外腔压强、复进机腔内压强、后坐速度和复进速度等，进而通过求得最大后坐阻力，来检验反后坐装置的功能是否满足给定的指标要求。综上所述，利用定型试验数据验证所建火炮虚拟样机的真实性是可行的。
2.4虚拟样机仿真数据与定型试验数据对比本文选择对某型火炮的仿真结果与试验数据结果进行对比验证，各项目的试验测试曲线如图5所示，其中：p1为后坐时驻退机外腔压强；p2为后坐时驻退机内腔压强；p′2为复进时驻退机内腔压强；v为后坐速度；v′为复进速度；pΠ为后坐时复进机腔内气体压强；R为后坐阻力；t为后坐时间；t′复进时间。本文选择与定型试验一致的试验条件，充分利用并对照定型试验的测试项目，对各测试项目进行虚拟样机仿真。火炮射击初始条件为0°射角、全装药、底盘着地射击，驻退机和复进机中的有关数据来源于火炮设计说明书，各结构尺寸存在一定公差范围，本文均采用其标称尺寸。
2.5由数据对比表得出结论
2.5.1复进机压强是后坐位移的函数，其值基本与试验数据相符；
2.5.2后坐和复进速度、后坐阻力值及变化趋势与仿真曲线基本相符；
2.5.3对于后坐时内腔的压强，利用伯努利方程可以求得内、外腔压强和液体流速的关系：p1-p2=
其中，p1为外腔压强，p2为内腔压强，其它符号含义见文献[6]。
由式（1）可知，驻退机内腔压强与外腔压强的基本趋势一致，随着后坐速度降低，二者压强差别逐渐变小。
2.5.4驻退机的内、外腔压强在出现峰值的时机与仿真数据曲线有所不同，导致结果不同的原因可能是在虚拟样机仿真时，虽然我们在制作各部件的时候采用的尺寸数据为标称值，但是实际加工的部件存在一定的误差，从数据结果看，制作的节制杆直径有一定误差，导致流液口面积的变化。对于复进时内腔的压强，真空消失过程不是一个突变的过程，而是一个渐近的过程，因此在非工作腔产生一定的压强，然而理论上认为复进真空消失之前，非工作腔不提供压强，从而导致在复进开始段仿真得到的压强值稍大。
虚拟样机仿真曲线与试验测试数据相比虽有一定误差，但基本与试验数据相吻合。宏观而言，后坐和复进速度的基本趋势与试验数据一致，最大后坐阻力基本规律一致，说明了所建虚拟样机的正确性，利用该虚拟样机对火炮宏观动力学特性进行研究是可信的，所建虚拟样机模型是满足工程上应用的。
摘要：针对目前火炮在实际使用过程中,由于测试手段的局限性,进行实弹射击危险性较大,不能很好的判断反后坐装置工作是否正常。本文以虚拟样机技术为研究手段对火炮反后坐装置的工作性能进行评估,通过仿真试验结果,检验虚拟样机的可信性。
关键词：某型火炮,虚拟样机,建立,可信性验证
参考文献
[1]杜中华.基于ADAMS的某型炮闩系统动力学仿真研究[D].石家庄:军械工程学院硕士学位论文,2001.
[2]杜中华,薛德庆,赵迎红.Pro/E和ADAMS传递过程中若干问题的讨论[J].机械与电子,2003,(2):68-70.
[3]刘竹清.Pro/E Wildfire入门与提高实用教程[M].北京:中国铁道出版社,2003.
[4]李军,邢俊文,覃文洁等.ADAMS实例教程[M].北京:北京理工大学出版社,2002.
[5]石博强,申焱华,宁晓斌等.ADAMS基础与工程范例教程[M].北京:中国铁道出版社,2007.
虚拟可信平台 篇3
随着信息技术的快速发展, 系统及网络安全问题日益突出, 可信计算的提出从一个新的角度来解决信息安全问题, 同时可信计算在安全方面的优越性受到越来越多国内外计算机领域工作者的关注。与传统的安全技术不同, 可信计算的思想是要从终端、从平台根源解决现有的安全问题, 在计算机的硬件平台上嵌入一个安全芯片即可信平台模块, 计算机系统中首先建立一个信任根, 再建立一条信任链, 一级测量认证一级, 一级信任一级, 把信任关系扩大到整个计算机系统, 从而确保计算机系统的可信。
Intel, Microsoft, IBM, HP等国际IT产业界巨头在1999年共同发起了TCPA可信计算平台联盟。2003年, TCPA重新改组, 更名为TCG (Trusted Computing Group) 可信计算组织, 其成员也迅速扩大到近200家。
我国的可信计算研究目前进入了一个蓬勃发展的阶段, 国内一些公司和研究机构已经自主研发出了可信平台安全芯片, 这些安全芯片有些符合TCG中TPM的规范, 有些使用了与TCG规范不同的密码算法, 由此导致了可信计算平台的异构。因此, 就需要考虑可信平台的兼容性问题。可信计算软件栈为兼容异构可信平台提供了框架基础和开发坏境。
1 可信计算平台
根据TCG组织可信的定义, 可信平台是一种总是能够以一定的方式按照预定的目的行为的平台。可信计算平台是能够提供可信计算服务的计算机软硬件实体, 它能够提供系统的可靠性、可用性、信息和行为的安全性。
可信计算平台以TPM为核心, 由TSS配合TPM对可信计算平台提供支持, 从而保证可信计算平台能够提供基于硬件保护的安全存储和各种密码运算等功能 (如图1) 。
可信计算平台由主板、搭建在其上的CPU、存储器和一些主要的外围设备, 以及嵌入式固件、BIOS、可信构建模块TBB (Trusted Building Block) 等共同构成。可信计算平台的一个主要特征就是在主板上嵌有TBB作为可信计算平台的信任根, 平台的可信就是建立在该信任根部件之上的。TBB由CRTM (可度量的核心信任源) 和TPM (可信平台模块) 组成, CRTM到TPM之间的联结是通过可信的传递建立的。TPM是可信计算技术的核心, 是一个含有密码运算部件和存储部件的小型片上系统。TPM是整个可信计算平台的基础, 它向操作系统、TSS等提供诸多安全方面的支持。完成计算平台的可靠性认证、用户身份认证和数字签名等功能。
2 可信计算软件栈模块化体系结构
TSS (TCG Software Stack) 是可信计算平台上TPM的支撑软件。TSS的主要目的是提供应用程序对TPM功能的单一的访问入口;提供对TPM的同步访问;对上层应用隐藏构建命令流的底层;管理TPM的资源, 包括对这些资源的创建、释放、调度。
TSS有两种模式:内核模式和用户模式。用户模式下有两种应用即用户应用程序和系统服务。TSS的模块化体系结构图如图2。
TSS服务提供层 (TSP) 是TCG提供给应用的API函数, 负责在应用程序中运行TPM提供的可信运算的功能。TSS核心服务 (TCS) 为一个平台上的所有TSP提供一系列通用的服务, TCS作为系统服务执行。多个TSP可以共享一个TCS。TCG设备驱动库 (TDDL) 是用户态和内核态的过渡, 提供一个用户态接口。由于TPM不是多线程的, 一个平台只有一个TDDL实例, 从而只允许单线程访问TPM。TPM设备驱动 (TDD) 接收来自于TDDL的字节流, 并把它们发向TPM, 最后将结果返回给TDDL。TSS排他性地打开TPM设备驱动, 驱动不允许任何应用在TSS之外与TPM设备建立连接。
以上各个模块的交互过程是TSP模块从应用程序获得的参数打包传给TCS模块, 由TCS模块来提供具体的服务功能, TCS模块把这些参数进行处理后生成TPM可以识别的字节流序列, 经过TDDL和TDD传到TPM, TPM接收到字节流以后进行相应的操作, 把结果以字节流的形式通过T D D和TDDL返回到TCS, TCS对字节流分析处理以后, 把结果传给TSP, TSP再把结果返回给应用程序。
3 支持异构可信平台的可信计算软件栈研究
3.1 TSS为实现异构可信平台应用兼容提供了框架基础
可信计算平台的异构主要是由密码算法和密码协议的不同造成的。密码协议和密码算法的不同, 带来了异构可信平台在应用上兼容性问题。可以利用可信计算软件栈TSS来实现异构可信平台应用上的兼容, 为异构可信计算平台的上层应用提供统一、兼容的接口, 使在异构可信计算平台上开发的应用可以在对方的可信平台上运行。
TSS的作用是将可信计算的服务提供给应用程序。应用程序通过它来使用可信平台模块提供的可信运算功能。TSS提供基本资源以支持可信芯片, 为应用提供进入可信芯片功能的入口点, 提供对可信芯片的同步访问, 将命令构建为字节流访问可信芯片, 并管理可信芯片资源。因此, 可以通过对TSS中的部分模块进行重构, 并在其中添加支持不同密码算法的TSS模块, 来实行对异构可信平台在应用上的兼容性具有可行性。同时, TSS为应用软件提供了兼容异构可信平台模块的开发坏境。
实现异构可信计算平台在应用上的兼容, 一个主要问题是通过TSS软件栈来解决异构带来的命令和密码协议转换问题, 使上层应用可以使用相同的命令来调用异构可信平台的可信计算功能。在TSS的模块化层次体系结构中, 解决异构可信平台在应用上的兼容主要体现在TSP层和TCS层。
3.2 TSP层实现异构兼容
TSP为上层应用提供访问可信平台模块功能的接口, 上层应用调用TSPI的函数后, TSP会将参数和命令号打包传输给TCS。TSP层是以对象来定义其中的模块, 包括:上下文对象, 策略对象, TPM对象, 密钥对象, 数据加密对象, PCR对象, 以及Hash对象等。通过TSP上下文 (TSP Context) 来管理这些对象, 它包含这些TSP对象执行环境的信息, 比如对象的标识, 与TSS其他模块的交互和通信信息。对于异构可信台的上层应用来说, TSP为其提供的接口应该是统一的, 但是由于密码算法的不同, 需要在这一层添加相应的密钥对象和策略对象。
3.3 TCS层各模块实现异构兼容
TCS接收到TSP传输的参数和命令, 将其转化成可信平台模块可以识别的字节流。因此, 可以在这一层实现对命令的识别和转换。根据底层所运行的可信平台模块的不同, 在TCS实现不同密钥算法的映射。TCS由上下文管理 (Context manager) 、密钥与证书管理 (Key&credential manager) 、事件管理 (Event manager) 、审计管理 (Audit manager) 和TPM参数块产生器 (TCS TPM Parameter Block Generator) 五个模块组成。
TCS上下文管理TSP请求所使用的所有TCS中的资源, 包括为其分配的内存, 以及所使用的密钥 (如图3所示) 。
TCS上下文由TCS内部创建和维护。TCS上下文是以链表形式在TCS内部进行管理和维护, 同时有创建、查找、撤销等方法。当TSP与TCS的连接断开时, 相应的TCS句柄也就同时销毁。
对于TCS的密钥管理, 密钥在TPM外部是以一种树型结构来进行存储和管理的, 形成一种保护存储的密钥层次。密钥的存储结构如图4所示。
这个树型存储结构的根是存储根密钥, 每层中的密钥都被其上一层的密钥加密。密钥的永久存储区分为系统永久存储区和用户永久存储区, 所有由T S S管理的密钥都应该在TCS的永久存储区中进行注册。注册之后的密钥可以通过它的UUID值进行索引。密钥一旦在永久存储区中注册后就一直存储在其中, 直到被注销。
为了更有效的管理TSS的密钥, 在TCS中有一个TCS密钥缓存管理器 (KCM) 。KCM的职责是确保应用已经调入的密钥需要时可以使用。如果所有的TPM资源都被占用了, KCM必须释放资源, 以便将需要使用的密钥调回到TPM中。一个应用只需要使用KCM将密钥加载到TPM, 就可以使用这个密钥了。
TCS密钥管理中, 密钥的创建以及密钥的加载时, 由于异构可信平台存储根密钥的不同, TCS中调用部分关于密钥的函数时, 需要在参数上进行修改。同时添加相应的密钥加载及注销模块。
应用程序是不允许直接访问T P M芯片的, 而是通过TPM参数块产生器来将T C S要执行的命令转化为T P M可以接受的格式。它为TCG的应用提供通过TCS的平台服务访问T P M命令的途径。TPM参数块产生器主要负责对TPM命令进行序列化, 同步化以及执行T P M命令。
T P M参数块产生器构造字节流输入到T P M中, 并将T P M返回的字节流进行转化。它通过底层的T P M驱动与T P M进行交互。T P M参数块产生器还包含内部的接口提供给密钥和证书管理, 审计管理和事件管理。因为这些模块都需要和TPM进行数据交互。对于TPM参数块产生器, 该模块起的作用是可信平台模块中所有命令的参数转化功能, 异构可信平台之间的差异会在这个模块中表现出来, 在这个模块中, 可以根据存在的差异来改变相应的数据结构和参数, 转化成对应的可信计算模块所接受的命令格式。
4 结束语
可信计算近年来发展迅速, 研究具有我国自主知识产权的可信平台对于我国的信息安全有十分主要的意义。发展中国的可信计算技术, 我国的可信计算技术走国产化, 拥有自主知识产权是信息安全领域专家的共识, 同时也得到了国家和政府大力支持。我国的可信计算也取得了一些成果, 研制出了自主密码的可信计算平台。为了使我国的可信计算平台获得更好的通用性, 使其与TCG规范下的可信计算平台之间兼容很有必要。
参考文献
[1]TCG Specification Architecture Overview Specifica-tion Revision 1.4 2nd August.2007.
[2]TCG Software Stack (TSS) Specification Version 1.2.2007.
移动可信平台的发展与研究 篇4
管理学里“木桶理论”同样可以用于信息安全领域，如果安全问题成为了移动终端应用的短板，那么将严重制约移动终端的发展。移动终端在最初设计时并没有太多从安全角度去考虑，目前，包括生产厂商、运营商等在内的产业界与学术界都从信息安全技术入手着眼于提高移动终端的安全性，如推出的手机防火墙、查杀病毒等技术。查杀病毒和防火墙等被动防御措施已被证明不足以保证计算机系统的安全，这个结论将同样也适用于移动终端[2]。在移动终端中许多其它的安全技术也逐渐产生，如增加生物识别模块以加强身份认证，增加STK/WIM卡以增强商务安全技术等。由于移动设备本身的限制，如较小的内存、较低的处理能力以及对成本控制要求等，较难在移动终端实现在计算机上的众多安全服务[3]，从而导致用户无法放心地在移动终端进行许多方便快捷应用(如移动商务等)，人们将希望的目光聚焦到可信计算技术。
1999年10月，由Intel、HP、Compaq、IBM和Microsoft发起成立了可信计算联盟TCPA，率先提出了可信计算平台的概念，其主要思想是利可信计算技术构建一个通用的终端硬件平台，以增强PC终端体系结构的安全性[4]。2003年，TCPA重组为“可信计算组”TCG(Trusted Computing Group)，并制定了新的TPM规范，并将可信技术扩展到移动平台[5]。
1 可信计算
TCG对“可信”定义为：如果实体的行为总是以所期望的方式，朝着预期的目标，那么这个实体就是可信。(Trust is the expectation that a device will behave in particular manner for a specific purpose。[4])它将“可信”定义归结为一种预期，它强调行为结果的可预期，但并不等于行为是安全。可信技术其主体思路是在计算平台是增补了一个防篡改的硬件，以保存重要数据和各种敏感信息，利用完整性度量、存储报告等机制，增强了认证、证明等手段来构建一个安全可信的软硬件运行环境，从源头上杜绝各种安全隐患。
TCG可信计算中提出了一些重要的概念：如完整性度量、认证启动、密封、平台认证。通常如果一个平台包含这几个概念，通常被认为是一个可信平台，在后来的规范中，还增加了软件隔离这个概念。为实现平台的这些功能，平台通常是以硬件的形式集成了可信组件(TBB)，如TCG定义的可信PC平台中，通常是可信平台模块(TPM)来建立一个软件运行可信的基础环境。
可信平台模块(TPM)是可信计算平台的关键基础部件，包含有密码运算部件和存储部件，能完成完整性度量、数据加/解密、数字签名以及安全存储等功能。可信软件栈(TSS)是可信计算平台内部的支撑软件，为平台外部提供访问TPM提供唯一的接口。
2 可信移动平台
可信移动平台，我们通常理解为植入了可信计算概念硬件或软件的移动平台。当前市场上不同的组织定义了不同的移动安全标准：如开放移动终端平台OMTP，可信计算组织TCG，开放移动联盟OMA，第三代合作项目3GPP等，这些组织制定的安全标准中都要求有硬件安全的支持[5]。目前适合移动和嵌入式平台中主要有以下几种增加了硬件的安全技术：为移动设备TCG定义的MTM和为嵌入式设备ARM定义了TrustZone技术以及OMTP的M-Shield。
2.1 移动可信模块MTM
2006年9月TCG发布了移动可信平台模块(mobile trusted module,MTM)规范的草稿文本，该规范为可信计算技术应用于移动设备提供了有力的理论依据。MTM规范是基于TPM1.2规范上构建的，可以把MTM看成是更适合移动平台的特殊TPM。MTM的命令由TPMV1.2中的一部分及额外增加的命令组成[6]。
移动可信平台模块(MTM)规范根据利益相关性，定义两种模块：移动本地所有者可信平台模块(MLTM)和移动远程所有者可信平台模块(MRTM)。MLTM即利益相关者(stakeholder)是本地所有者如用户，能物理访问移动设备，MLTM所支持的功能与现有的TPM类似，支持平台进行物理访问的实体(如用户)控制。MRTM则是利益相关者在远程，例如设备制造商，和网络服务提供商等，不能对设备进行直接物理访问，需要利用MRTM功能来通过远程安全访问到移动终端，为移动终端提供服务(如网络信号及服务支持)。MRTM不同于MLTM之处最重要的一点是MRTM提供额外的保护功能支持安全启动。
MTM依赖分离出可信的操作域，叫可信引擎。可信引擎支持远程的利益攸关者执行在本地移动平台可信计算。每个可信引擎可分别代表具体的设备，蜂窝网络，应用程序和用户等。一个移动设备可能包括多个MTM，与TPM不同的是MTM引入了安全启动的概念，需要对软件完整性保护和安全启动。与计算机平台的认证启动相比，安全启动不仅要对启动序列进行度量，也要中止任何非预期的状态转换。第二点不同是MTM不仅支持用硬件方式实现，也支持用软件方式实现。这使得MTM可能用为现有的手机附加地部署这种安全元素。这种参考结构考虑到在同一个设备中平行地支持几个MTM实例，有些可以由用户任意部署，有的由厂商强制定义安全策略(强制的安全访问控制)。
2.2 ARM TrustZone技术
ARM公司根据可信技术概念在嵌入式领域里提出了TrustZone技术，其目标是在嵌入式平台(如移动手机、PDAs、机顶盒等设备)提供一个安全可信的环境，以应对日益增长的安全威胁。其实质是在CPU中加入域隔离功能，提供代码隔离环境和安全服务以构建安全可信环境。
TrustZone技术其核心是在微处理器中增加安全功能，以保证微处理器内外的存储空间及外设不受软件攻击，同时也可以增加硬件加密、存储保护等安全设计。TrustZone技术定义了一种新的模式：即增加了安全状态[7]。系统及应用程序可以在安全和非安全两种状态中运行，在任何时刻只允许运行一种模式，监控器“SecureMonitor”负责两种模式之间的切换。处理器在安全状态模式中运行时可以进行安全性要求高的操作，如调用密钥、加解密、完成签名等。TrustZone技术为这些安全代码和数据进行独立分区并作了标记，只有当代码或数据在安全状态下才能进行操作，这些都是通过增强安全与非安全状态标识位、扩展的寄存器以及存储管理器MMU和Caches来实现的。TrustZone为处理这些硬件扩展功能定义了TrustZone软件，用户可以根据TrustZone软件对TrustZone微处理器内核进行安全操作。
TI公司的M-Shield技术提供了一个基于硬件的安全环境，它定义了安全的ROM和RAM并嵌入了一个安全状态机(SSM)。安全状态机(SSM)确保应用程序在进入、执行和退出安全环境时遵守系统安全策略。SSM消除了芯片互连及直接存储访问(DMA)时数据传输的脆弱性，为整个平台处理和传输机密及敏感数据(密钥、证书等)提供的安全保护。M-Shield移动安全技术包括公钥基础设施，提供运行前对平台各种软件真实性和完整性的验证。安全芯片互连只允许访问安全环境下的外设和存储器和安全的DMA通道，以保证保密、敏感信息在整个处理过程的安全。
在上述几种移动设备的安全技术中，M-Shield及TrustZone技术已经步入了实际运用的阶段，已有一系列较为成熟的产品。而可信计算组织提出的可信移动平台方案虽然尚未出现成熟的产品，但为解决移动设备的安全问题建立了一个标准规范，代表着未来的研究与发展方向。目前几种技术有相互融合的趋势，例如德州仪器M-Shield为基础的系统级的移动安全解决方案中为减少各厂商的设计流程与周期，就开发出一个安全中间件组件，包括一个基于TrustZone软件的标准API[8]，一些设计者也试图用TrustZone技术来实现移动可信平台模块(MTM)。
3 移动可信模块MTM的实现
基于PC上的TPM，是以硬件的方式实现的，目前在一些高端PC中已经得到部署。与桌面计算机平台已出现的相对成熟的TPM相比，移动平台中尚无成熟的MTM产品，如何在处理能力及存储能力受限的移动终端实现TPM，这是值得我们探讨的。TCG已经就如何设计移动TPM及提供的功能进行规范，而这种规范定义得相当宽松，允许制造厂商用不同的方法实现他们的TPM。例如以纯软件、硬件方式和软硬件结合的方式[9]。下面对两种具有代表性的实现方案进行介绍。
3.1 基于TrustZone的方案
国外学者对TrustZone技术实现MTM进行了许多研究，Winter,J.提出了一种基于ARM处理器，利用TrustZone技术模拟实现MTM软件的设计，依赖于开源操作系统Linux内核作为基础安全部件，能有效地达到为移动可信平台模块实现防护和数据保护需求提供隔离区目的[10]，Kurt Dietrich and Johannes Winter利用Winter,J.提出了利用TrustZone和修改Linux内核用纯软件方式实现MTM。杜文银，张涛等中提出了基于ARM TrustZone技术的移动可信平台，其主体思路是利用TrustZone建立的安全模式与非安全模式来实现硬件的隔离，MTM运行在安全区域中以保证其中敏感数据的安全性。所有应用程序均运行在一般区域，当需要上层可信服务时，通过向监控器提出申请以切换到安全区域进行相应处理[11]。其平台体系结构如图1。
3.2 基于智能JAVA卡的MTM
在国外的计算机平台中通常用智能卡来实现对重要数据如(密钥、证书、账号口令等敏感数据)的存储及提供硬件加/解密。Kurt Di-etrich and Johannes Winter设计出一种基于Java卡硬件的移动可信平台模块，利用智能卡提供硬件密码算法及防护的优点及JAVA的各applet相互隔离及编程的灵活性，其主要思想在智能卡内部非易失性存储器内用来存储MTM的背书密钥、授权数据等和用硬件密码模块实现MTM所需的密码算法运算，在JAVA卡的虚拟机上运行相互隔离的applet实例程序来实现MTM中的MRTM和MRLM功能模块，用APUD与卡外的应用程序进行通信。文献[12]中指出基于JAVA卡实现MTM的安全特性是可以证明的。其软件结构图如图2所示。
3.3 两种方案比较
基于TrustZone和JAVA智能卡技术实现MTM两种方案均采用了以硬件为支撑来实现可信模块的安全功能，软硬件结合实现MTM的方案代表着目前可信技术在移动平台研究的主要方向。基于TrustZone实现MTM是利用在ARM芯片中增强特殊的软硬件安全结构增加安全算法和安全存储的硬件支持和利用TrustZone软件实现安全区与非安全区的隔离，以增强安全防护能力，其显著特点是不需要增加任何附加的硬件，但只有在ARM TrustZone芯片中才能实现这种技术，有一定的片面性与局限性。而JAVA智能卡实现的MTM则利用智能卡提供硬件密码算法及防护等优点及JAVA“一次编程、到处运行”的灵活性，其显著特点是发展潜力好，灵活性强。但其缺点是JAVA卡是以虚拟机实现applet，其处理速度受移动终端的处理器及内存等约束，这对移动终端本身资源受限的现况提出了较高的要求，如何优化字节码以提高在JAVA卡的运行效率是一个值得探讨的课题。
4 总结和展望
面对移动终端日益严峻的安全威胁，必须采取相应的软硬件安全措施来防止任何破坏性攻击。本文依照TCG的MWPG定义的规范对移动平台中可信模块进行了介绍，并对两种有代表MTM实现方案进行了阐述，希望能给读者对移动平台中的可信技术有更多的了解。
目前在移动终端的可信计算研究也刚刚起步，将来的移动可信平台，将可能以各种各样的技术实现MTM。TCG只是为解决移动平台安全问题提供一个参考模型，各个厂商还未推出这方面很成熟的产品，这既与技术方面原因有关，也与成本要求、复杂性等因素有关。同计算机平台中一样，如何利用可信计算来构建一个包括硬件、操作系统、应用程序及网络系统等在内的移动可信环境，这不仅要学术界技术的支持，需要生产厂商、移动运营商、服务提供商等产业界共同努力，实现真正“可信”，还有一段很长的路要走。但我们相信随着移动设备的安全需求的加大和移动可信技术研究的不断深入，具有可信概念的移动设备的出现将为期不远。
摘要：随着通信技术和互联网技术的不断融合,移动终端应用越来越广泛,与此同时安全问题正逐渐成为其众多应用推广的主要障碍。可信计算技术是有效解决移动终端安全问题的一种新思路。该文在阐述可信计算一些重要概念的基础上,对可信计算组织定义的移动可信模块(Mobile Trusted Module,MTM)的结构和特点进行了详细描述,介绍了当前增强移动平台安全的TrustZone及M-Shield技术,并且着重分析了两种可行的MTM的实现技术。最后对移动可信计算技术未来的研究方向进行了展望。
关键词：可信计算,移动可信模块,TrustZone技术,M-Shield,JAVA卡
参考文献
[1]Mark Stamp.信息安全原理与实践著[M]杜瑞颖,赵波,王张宜,彭国军,译.北京:电子工业出版社,2007.
[2]张翔.移动终端智能化的信息安全[J].通信世界,2009,15.
[3]SuGil Choi,JinHee Han,JeongWoo Lee,et al.Implementation of a TCG-Based Trusted Computing in Mobile Device Wireless Security Application Research TeamElectronics and Telecommunications Research Institute(ETRI)161Gajeong-dong,Yuseong-gu,Daejeon,305-700,South Korea.
[4]Trusted Computing Group.TCG specification architecture overview.[EB/OL].(2005-03-01).http://www.Trustedcomputinggroup.org/groups/TCG_1_0_Architecture_Overview.pdf.
[5]NTT DoCoMo,IBM,Intel Corporation.Trusted mobile platform protocol specification document-Revision1.OO[EB/OL].(2004-04-05).http://www.trusted-mobile.org.
[6]TCG MPWG:Mobile trusted module specification overview document.Mobile trusted module specification support documents,Trusted Computing Group(TCG),Beaverton,Oregon,USA2006.
[7]TrustZone Software API Specification[Z].https://www.arm.com/pdfs.
[8]https://.www.ti.com/m-shield.M-Shield?Mobile SecurityTechnology:making wireless secure2008Texas Instruments Incorporated.
[9]Joe Grand.Practical secure hardware design for embedded systems[c].Proceedings of the Embedded System Conference,San Francisco:CMP Media,2004.
[10]Winter J.Trusted computing building blocks for embedded linux-based arm trustzone platforms[C].In:STC2008:Proceedings of the3rd ACM workshop on Scalable trusted computing,.ACM,New York,2008:21–30.
[11]杜文银,张涛,凌君.基于ARM TrustZone技术的移动可信平台[J].测控技术,2009,28.
可信云平台服务运行管理模式初探 篇5
云平台允许第三方服务提供商提供的服务放在“云”里运行。云计算的灵魂在于服务, 服务的灵魂在于安全可靠, 如何打造可信、安全的云平台是云服务商和用户关心的问题。由于云平台对于第三方服务的开放性, 打造可信的云平台需要满足: (1) 云平台自身具有可信保证机制; (2) 云平台上的第三方服务在运行中是可靠的。
本文假定云平台是已被证明是可信的, 作为本文研究的可信根。云平台提供一套可信服务管理框架, 以保证运行在云平台上的服务是可信的。信任云平台的用户可以安全地使用云平台上的。该框架能够实现: (1) 防止服务提供商在服务运行过程中篡改程序代码, 获取用户数据进行恶意操作; (2) 防止服务因其程序依赖的其他程序包和部署环境发现的漏洞而受到攻击。
2 威胁模型
本节介绍在用户在使用第三方服务的过程中可能遇到的威胁模型, 及在可信云平台中通过计算手段克服这些威胁的解决方案, 使得信任云平台的用户能够使用可信的服务。在本文中, 云服务提供商担任可信根。
2.1 来自服务提供商的威胁
部署在云平台上的第三方服务在运行过程中主要受到两种来源的威胁, 分别来自服务提供商和黑客等外部群体。本节对服务提供商在服务运行过程中篡改服务源码的威胁及防御措施进行介绍。
2.1.1 威胁模型
图2-1展示了一个用户在使用第三方提供的服务时存在的威胁模型。服务提供商提供了一个恶意服务程序, 部署在服务提供商的服务器上, 服务提供商对服务进行运行和控制。一个信任这个服务提供商的用户发现了这个服务并访问该服务。该服务能够获取到用户的数据, 并有可能不正确地使用用户数据, 或在用户未知的情况下, 将用户数据泄露给其他的恶意服务。但在此模型中, 用户想要使用该服务, 只能相信服务提供商, 此外并无其他选择。
2.1.2 防御模型
图2-2展示了针对威胁模型1的防御模型。云平台提供商作为中立的第三方可信平台, 对发布在云平台上的服务进行严格的验证, 并对服务实例进行封装, 防止实例被篡改。验证主要包括服务是否存在漏洞, 是否存在恶意代码等进行全方面的检查。封装即保证一旦实例运行起来后就不能被修改。在云平台, 云服务提供商将服务封装在虚拟机镜像中, 以实例的方式运行服务, 使得实例被隔离并防止服务提供商对实例的修改。这样, 在云服务提供商将服务部署到云平台之后, 服务提供商无法在其中增加恶意代码, 也无法获取用户数据。
通过上述措施, 信任云平台的用户可以放心的使用云平台中部署的第三方服务。
2.2 来自外部的攻击
除了前文介绍的来自服务提供商的威胁, 服务还可能因其程序依赖的程序包或者部署环境存在漏洞而受到黑客等外部群体的攻击。本节对该类威胁模型和针对该类威胁的防御模型进行介绍。
2.2.1 威胁模型
图2-3展示了服务在运行过程中存在的漏洞威胁模型。2013年7月17日的Struts2高危漏洞事件造成了大规模的信息泄露。利用漏洞, 黑客能够发起远程攻击, 轻则窃取网站数据信息, 严重的可取得网站服务器控制权, 构成信息泄露和运行安全威胁, 无数的网民受其影响。7.17事件只是我们的漏洞威胁模型中的一个案例。服务实例在运行过程中, 可能会因为程序依赖的包 (如Struts2的Jar包) 或部署环境 (如操作系统、数据库等) 存在的漏洞而受到攻击, 在这种情况下, 用户的信息可能会泄露而造成损失。
2.2.2 防御模型
图2-4描述了针对漏洞威胁模型的防御模型, 云平台构建漏洞预防机制。云平台通过爬虫实时获得互联网上公布的漏洞信息, 对安全信息库进行不断更新。可心服务检测引擎监测安全信息库中的漏洞, 并发现漏洞可能影响的运行在云平台中的服务实例, 并将发现的潜在风险通知云平台提供商, 以采取预防措施, 防止服务受到攻击, 也防止第三方服务将风险引入云平台。
3 解决方案
为了提高云平台服务管理的标准化程度及规范性, 在云平台对第三方服务的管理中引入了ITIL规范。ITIL (信息技术基础架构库) 于上世纪八十年代被提出, 用于指导IT组织提供更加经济高效的IT服务, 是一套与产品和行业无关的国际最佳实践。ITIL运维服务支持五大流程, 即事件、问题、配置、变更、发布管理流程。本文基于ITIL规范及本单位参与制订的《可信计算平台可信性度量》系列标准, 提出一种对云平台服务可信性管理的机制。本节对与第二章威胁模型相关的流程进行介绍。
3.1 服务发布管理
对于第三方服务提供商提交给云平台的服务, 云平台依据图3-1的发布管理流程对服务的发布进行严格管理, 以预防服务提供商在服务发布到云平台之后, 对于服务源代码的恶意篡改行为。
在上述流程中, 服务提供商只负责向云平台提交服务, 在服务部署到云平台之后, 不再具有对服务的控制权, 无法对运行中的服务进行代码修改等操作, 有效预防威胁模型1中描述的威胁。
服务验证包括云平台服务管理员对服务提供商的资质、信用, 对服务的漏洞扫描等操作, 保证初始的服务是安全的。
服务封装指云平台将服务封装在KVM虚拟机镜像中, 通过运行虚拟机实例的方式运行服务, 而虚拟机对服务提供商而言是不可见也不可控制的, 从而保证服务实例的安全性。云平台采用Eucalyptus云计算软件作为底层的管理软件, 利用Eucalyptus的管理能力能够实现对服务实例的隔离并防止服务提供商对服务实例的修改, 使服务提供商无法以root身份登陆去修改软件代码和设置信息。具体过程为:
(1) 云平台管理员制作KVM镜像, 镜像中包含服务提供商上传的服务包及运行依赖的环境;
(2) 将制作的镜像相关文件上传到云平台CLC机器, Eucalyptus对镜像进行管理;非云平台管理员无法获取镜像和修改镜像;
(3) 用镜像启动虚拟机, 服务可对外访问。可通过SSH协议远程登陆虚拟机, SSL私钥保持机密, 服务提供商不能通过自己的私钥来访问虚拟机。
3.2 服务配置管理
按照图3-2展示的服务配置管理, 云平台对第三方服务商提供的服务进行规范的配置管理, 规范化的服务配置信息存储在配置信息库中。
配置信息由服务提供商在提交服务的同时, 提交给云平台。配置信息主要包括两类信息:
(1) 服务依赖的运行环境配置, 包括Web服务器、数据库等。
(2) 服务程序中依赖的第三方程序包, 如Struts Jar包等, 本文采用类似Maven的配置文件pom.xml格式的XML文件提交服务依赖程序包信息, 服务提供商如果使用Maven管理项目则可以直接提交项目的pom.xml文件, 否则需按照云平台提供的类似pom.xml的文件填写。
提交之后, 云平台会对配置项信息的完整性进行检查, 并将完整的配置项信息提交到配置信息库, 此后如果发现配置项信息变化则进行变更配置项的操作。
3.3 服务漏洞监测
在服务提供商将服务及服务配置信息提交给云平台, 并且云平台对服务进行检验、封装并运行之后, 运平台的可信服务监测引擎则不断监测服务可能存在的漏洞, 并触发风险预警, 如图3-3所示。
云平台执行网络爬虫程序, 实时从互联网上的多个权威的漏洞和安全信息页面爬取漏洞和安全信息, 并存储在采集库中, 采集库中的信息经过清洗、提取等处理形成不断更新的安全信息库, 包括漏洞、补丁、安全事件等信息。可信服务监测引擎实时监测安全信息库中的信息, 并根据这些漏洞、补丁影响的软件、程序包等信息以及云平台服务的配置项信息, 判断可能会受到影响的服务, 从而生成风险预警信息, 并进入事件管理流程。
通过该系统, 云平台能够实现对漏洞、补丁相关威胁的预先防范和及时发现, 降低服务和云平台的风险。
3.4 事件管理
对于可信服务监测系统发现的漏洞风险进行规范的事件管理。首先云平台管理员接收全部风险预警信息, 并进行判别, 对误报的风险直接关闭。对于服务真正存在的潜在风险进行分类和在线支持, 对于能够直接处理的问题直接进行解决, 否则派发给云平台运维工程师进行调查、诊断和解决。
4 总结
本文基于ITIL服务管理及《可信计算平台可信性度量》系列标准, 制定了可信云平台服务管理方案。云平台作为可信根, 对部属在云平台上的服务进行规范管理, 避免了两种安全威胁: (1) 防止服务提供商在服务运行过程中篡改程序代码, 获取用户数据进行恶意操作; (2) 防止服务因其程序依赖的其他程序包和部署环境发现的漏洞而受到攻击。从而使得信任云平台的用户能够安全使用云平台上部署的第三方服务提供上提供的服务。
摘要：随着云计算的推进和发展, 云平台的建设由基础设施向高端的软件服务延伸, 作为一种平台, 云平台允许开发者们或是将写好的服务放在“云”里运行, 或是使用“云”里提供的服务, 或二者皆是。与此同时, 云平台的可信性问题越来越引起业界及用户的关注, 构建可信性平台变得越来越重要。云平台除了证明平台自身的可信性之外, 还必须保证由第三方提供的、运行在云平台上的服务在云平台运行过程中, 不会给云平台引入新的风险和隐患, 保证云平台上的服务不会影响云平台的可信性。本文结合与上海证券交易所合作的“证券业云平台研发与运营”课题, 对可信云平台的服务运行管理模式进行了探讨, 结合ITIL规范和本单位参与制订的《可信计算平台可信性度量》系列标准, 提出一种对云平台服务在运行阶段的可信性管理的机制。
关键词：可信,云平台,ITIL,威胁模型,防御模型,配置管理,服务部署
参考文献
[1]翰纬ITIL Version 3白皮书[Z].翰纬IT管理研究咨询中心, 2007 (O7) .
[2]Web安全:技术与危机并进[Z].信息安全与通信保密, 2010.
云计算平台可信性增强技术的分析 篇6
云计算主要包含五个特征:基于多租户架构、可扩展性超强、有弹性、按需付费与资源可根据需要自动供应。通过云计算服务能够帮助企业大幅度节约存储和计算成本, 但是云平台中的安全问题成为了制约云计算发展的首要因素。企业在关心如何降低数据存储和处理的成本的同时, 最关心数据是否安全以及失去数据控制权会对隐私带来什么样的危害。当企业在使用云服务的同时, 恶意云服务商或者和行为不端的员工很有可能篡改或泄露用户数据, 如果这些数据对企业运营来说是机密级别的, 这将会对用户会造成巨大危害。
本文提出一种可信的云计算平台 (TCCP) , 可以确保外包给IaaS的计算的保密性和完整性。TCCP为用户VM提供一个封闭的执行环境, 避免云服务商的特权用户窥视或者篡改内容, 在执行VM申请前, 用户可以远程判断服务后台运行的TCCP是否可信。该方法拓展了整体服务验证的概念, 使用户能够预估计算执行安全性。
二、可信赖云计算平台关键技术
传统可信平台只能够保证单台主机上的计算安全性, 平台验证机制不能保证远程方得到的测度列表ML就是VM运行主机的真实信息。因此, TCCP需要设计远程验证方法, 保证后台平台资源持久安全。
2.1概述
TCCP可以加强IaaS后台, 进而做到不改变整体结构的前提下为云计算提供封闭的执行环境。TCCP可信计算包括两个方面:可信赖虚拟机映像 (TVMM) 与可信赖协调者 (TC) 。
后台节点作用为运行掌控客户虚拟机的TVMM, 并阻止特权用户窥视和篡改。TVMM可以在遵守TCCP协议的前提下自身安全进行保护, 节点被嵌入在经过验证的TPM, 可通过安全启动进程加载TVMM。TVMM的本质就是一个可隔离不轨意图系统管理员的本地的封闭环境。TC管理一系列可以安全运行客户虚拟机的节点, 这些节点称为可信节点。该类节点必须位于安全域内并运行TVMM, 这要求TC保存节点位于安全域的记录, 并验证节点平台以判断该节点是否运行着可信赖TVMM。TC还可以进行在簇中添加或移除节点、临时关闭节点等操作。通过TC主要用于验证IaaS是否安全。
为保证将VM限制在可信的节点和VM迁移时其状态不受窥视和篡改的安全, 每个节点上运行的每个TVMM必须与TC相配合。假设由外部可信赖实体 (ETE) 对TC进行管理, 并在IaaS域中为TC部署一系列节点和可信赖配置的信息, 保证管理IaaS的系统管理员在ETE内部没有特权, 不能对TC进行篡改。本文立足点为ETE由没有与IaaS服务商有共同动机的的第三方维护。
2.2关键技术设计
本节详细介绍TCCP相关机制。在2.2.1节介绍可信赖平台上一系列节点管理协议;2.2.2节介绍VM安全管理协议, 包括装载VM和迁移VM。这些协议中用以下标记表示加密操作, Kx表示会话密钥,
2.2.1 VM安全管理协议
通过保存包括安全域内节点、识别节点可信平台模块 (TPM) 的公开识别密钥EKNP和预期测度列表MLN的目录, TC可以动态管理一系列掌控VM的可信赖节点。ETE保证TC部分参数安全公开可用, 包括MLN和MLTC是远程方在识别节点N或TC上运行的平台时的期望值。
节点必须在TC注册, 并遵守相关协议。前两步节点N验证TC, 节点N向TC发起挑战, TC返回经加密的MLTC, 如果MLTC与预期相符, 即表示TC是可信赖的。TC在返回信息中包含了对节点N的挑战nTC, 第三步节点N产生密钥对
必须做到可信节点重启后, TCCP还可以将节点认为是可信的, 否则TCCP的安全性会收到威胁。可采用如下手段:节点内存只保存机器重启密钥就会丢失, 节点会被TCCP阻止, 必须重新进行注册。
2.2.2虚拟机管理
TCCP在加载VM时需要保证一下几点: (1) VM加载的节点可信; (2) 系统管理员不能窥视和篡改初始VM状态。
可设置如下协议。加载VM前, 用户不知道VM将加载到哪个物理节点上, 且在服务的所有参与者中只有TC可信赖。用户首先生成会话密钥KVM, 并将消息发送到CM, 消息包含φ和φ用会话密钥加密的哈希值, 以及采用进行加密的KVM。用TC的公钥加密会话密钥, 保证只有经TC授权的可信赖节点才能访问φ。
收到加载VM请求后, CM指派簇中节点N加载VM, 同时把请求转发给N。因为启动VM不能绕过访问φ, 节点N向TC发送消息, TC用私钥解密消息, 进而验证N是否可信。在TC信赖节点库中如果不存在N的公钥, 则该请求可能是CM将请求转移到了恶意系统管理员控制的节点, 故拒绝该请求。如果请求通过了, TC解密会话密钥, 并对节点N发送消息, 此时N就解密φ并启动VM。最后节点将消息发送给用户, 消息包含节点运行VM的证明。
三、总结
虚拟可信平台 篇7
为提高计算机系统的安全性和可靠性,1999年TCPA (Trusted Computing Platform Alliance) 提出可信计算(Trusted Computing)的思想以保护计算终端的安全,随后TCPA更名为TCG(Trusted Computing Group)并对可信计算标准做出了相应改进。TCG的标准通过一组协议来定义实现可信计算功能的软件和硬件特性,其中核心协议是定义一块TPM(Trusted Platform Module)芯片的功能和特征。配有TPM的平台可以称为可信计算平台(TCP)。
TPM芯片本身具有创建公私密钥,计算摘要等基础密码功能,但是TCP的功能远不止如此。TCP定义了底层的信任基础,并通过改变平台引导顺序来建立信任链,最终建立一个状态可知并可以验证的系统环境。
就TPM的密码特性而言,TPM提供了一个与传统的安全芯片或者PKI系统完全不同的证书/密钥管理方法。协议定义TPM只能有一个Endorsement Key (EK) 用以保证芯片的唯一性,而通过定义其他6种密钥和5种证书类型来为其功能接口提供必要的数据结构。
其中,Attestation Identity Key(AIK)用于平台信息签名和身份认证;签名密钥(signing key)主要用于对数据签名;存储密钥(Storage key)用于将数据和密钥保存在TPM之外,绑定密钥(Bind Keys)用于加密数据。TPM也支持传统的非对称密钥(Legacy Key)和对称密钥。
就TPM可信计算特性而言,TPM定义了平台配置寄存器(Platform Configuration Register)这一概念来描述系统从BIOS到应用软件各个层次的状态。通过对比目前的PCR和之前保存的度量值,确定某个特定的引导层次是否可信,由此建立信任链的关系。
TPM Main协议的1到3部分详细定义了TPM各种密钥的使用方法,基于AIK的身份认证,PCR的计算等,而TCG PC Specific Specification定义了PC如何实现TPM,各个PCR的功能和引导顺序等。对于上层,TCG协议定义TPM采用命令(Commands)的形式访问,TPM Main Part 3 定义了芯片提供的所有命令,本文从整体分析TPM Commands的安全性,并测试部分常用命令的执行性能。
1 TPM命令安全分析
TPM定义芯片的设计和接口,但对于操作系统而言,无法直接执行TPM命令,必须通过TCG协议指定的TSS来间接访问TPM。TSS(TCG Software Stack)由一系列的模块组成,主要完成对TPM模块本身的软件支持。TSS所提供的函数都不直接访问TPM内部的存储和功能,而只是起了包含传递命令在内的支持作用。因此,TPM命令安全性包括两个方面:TSS本身单个命令访问的安全性和TPM 状态随命令序列转移的安全性。
TPM通过定义受保护区域(Shielded Location)和保护功能(Protected Capabilities)来实现上述安全性的第一个方面。受保护区域保存包括EK,SRK和导入密钥等TPM安全核心数据,而TPM协议定义标准的,由ordinal标识的命令作为Protected Capabilities,必须通过授权协议,使用授权参数,才可以访问受保护区域。
授权参数的交换可以通过Object-Specific Authorization Protocol (OSAP),或Object-Independent Authorization Protocol (OIAP),或者Delegate-Specific Authorization Protocol (DSAP)。通过授权参书的验证后,命令可以操作TPM中定义的各种数据结构(密钥,证书等)。厂商芯片或许会提供特定的功能,但是从操作系统软件层次而言,是无法绕过TPM直接读取受保护区域的内容。
对于第二个方面,虽然从TSS的TDDL(Device Driver Library)层定义对于TPM芯片本身的访问必须是顺序性的,避免了多个命令并发执行的问题,但是命令和权限的组合还是会产生问题。为了分析命令序列的安全性,可以定义一个类似传统Unix系统的访问矩阵模型:
定义有限权限集R和有限命令集C,C中的每一个命令如下:
command α(X1,X2,…,Xk)
if r1 in (Xs1,Xo1) and r2 in (Xs2,Xo2) … rm in (Xsm,Xom)
then op1,op2,…,opm
这里定义的α为命令名,X1,X2,…,Xk为格式化参数,由此可以产生实际命令参数,每一个opi定义为以下的6个基本操作元之一:
enter r into(Xs,Xo) delete r from(Xs,Xo)
create subject Xs create object Xo
destroy subject Xs destroy object Xo
定义系统目前状态为三元组Q=(S,O,P),其中S为当前的subjects的集合,O为objects的集合,S⊆O。P是当前的访问矩阵,其中每个元素P[s,o]是R的一个子集。Subject可以看作为访问主体,例如一个进程,object可以看作为访问客体,例如一个数据或者密钥的blob。P[s,o]是subject s对object o的访问权限。例如read, write等。
系统的初始状态确定以后,执行不同的命令将改变系统状态:例如,假设subject为进程,而object为AIK,一个TPMMakeIdentity命令(创建AIK)可以定义为
这里的own权限是通过拥有创建时指定的AuthData来体现的。
这个命令是通过两个基本操作元来实现的。
定义当前的状态Q经过基本操作元op后到达状态Q′为:(S,O,P)⇒op(S′,O′P′)不同的op对于P的影响是不同的,例如:
若op为create subject s′,s′是一个新的subject,那么S′=SU{s′},O′=OU{s′},P′[s′,o]=P[s,o]for(s,o)∈S×O,P′[s′,o]=〉for o∈O′,P′[s,s′]=〉 for s∈S′
因为命令可以看作基本操作元的集合,那么可以类似地定义Q在经过命令α后到达状态Q′为:
从严格意义上定义系统的安全性是不可能的,因为即使没有任何权限, TPM系统内部一些信息也是可以读取的(例如,所有PCR值,TPMPERMANENTFLAGS和各种类型的handles)。只能考虑特定权限(例如TPMowner或者某个密钥的AuthData)的安全。对于任意权限r,如果命令α(X1,X2,…,Xk)执行一个基元操作使得原来并不包含r的访问矩阵P的某个元素包含r,那么可以定义命令α泄漏了权限r。一般情况下权限泄漏不一定是坏的,系统中需要必要的授权命令,但如果系统中有权执行授权的subject没有这样的r却仍可以执行,或不希望某些权限被哪怕是一点的泄漏,那么命令α就是不安全的。
为了分析这个模型安全性的判定,首先可以对比判断语法二义性的算法。给定一个特定的语法,写出一组特定的语句可以很简单地判定是否有二义性,但如果仅仅从语法定义的角度来讲,写的语句任意时一般很难判断该语法是否有二义性。这个问题虽然可以用LR(k)算法来判断,但当该语法不满足LR(k)条件时,仍然可能是无二义性的。与之类似的是,对于一个安全模型和初始状态Q,若命令序列给定,判定一个权限r是否安全当然是很简单的,但是对于任意的命令序列和Q,很难给定一个算法判断是否为安全的,并且即使有这样一个算法,不满足这个算法的系统也不一定是不安全的。
一个很简单的算法就是,给定了一个初试状态Q0和权限r,把这个系统中所有的命令排列组合全部算一下。这实际是不可能的,因为实际系统中的命令包含条件分支太多。对于访问矩阵模型,可以简单地讨论这样一种特殊情况:假设系统中的全部命令都只包含一个基元操作,这时一个命令就和一个基元操作在安全的意义上等价了,这种系统可以称为“单一操作元”系统。在这种安全系统的假设下,可以证明存在一个算法来判断该系统对于初始状态Q0和特定的r是否是安全的。设权限r泄漏的最短命令序列为:
可以证明,C1不是enter就是create subject命令,对于2≤i≤m,Ci都是enter命令。由此可以得出一个算法为:从已知的矩阵Q0出发,C1可为create subject或enter命令,接着执行所有的enter命令,如果全部m条命令执行完r仍然没有泄漏,那么这个系统就是安全的,否则系统是不安全的。
对于TPM而言,虽然只有owner 和operator这两种role,所有的subject对于object而言只有两种:owner或者非owner,所有的命令可以很简单分解为几个简单的基本操作元,这个算法时间复杂度仍然非常高,和初始访问矩阵大小成指数关系。即使有其他算法将问题复杂度降到与初始矩阵为多项式关系,考虑到可能系统状态和所有的操作,该问题仍然是NP问题,仅仅在特殊,有限的情况下有解,需要进一步的分析。
尽管从数学模型上很难证明其状态转移的安全性,但上述模型同实际的TPM命令序列定义和功能还是有一定的差别,通过建立状态机和命令规则,TPM命令序列可以是安全的。在实际芯片使用中,某个系统状态下违反规则执行错误命令是导致TPM芯片崩溃的主要原因。
2 TPM性能分析
TPM芯片本身在于提供一个可信的物理环境,倾向于表明“我所在的平台是什么样的”而不是“我能干什么”,这一点也是TPM芯片和传统的提供硬件密码操作芯片不同的特征,但是TPM本身的确能提供一些基础性的密码和身份验证功能,这也使TPM的作用不仅仅是反映一个可信的平台环境。
TPM能够提供的基本功能包括:非对称加密和解密,公私钥签名和验证,基于PCR的封装存储和解封装,采用可信第三方(TTP)的时候,可以创建AIK和AIK证书,对平台进行身份认证,在TPM1.2中,还可以采用直接匿名认证(DAA)的技术而不需要TTP。
几乎所有的TPM芯片应用都会使用2个基本安全接口:非对称加密/解密,签名/验证,这两个功能是通过直接调用TPM命令完成。可以对比TPM芯片和软件实现在基本功能上的执行性能。
测试采用兆日SSX35B和Atmel TPM芯片,PC平台,直接测试TspiDataBind和TPMUnBind模块,TPMSign命令模块,涉及到TPMOIAP和TPMOSAP命令模块,TPMSeal,TPMUnSeal模块的性能与此也有相关性。
软件创建和使用的都是RSA,2048位公私钥,与TPM定义的相同,加密数据长度为20字节的随机数据,软件实现采用第三方的安全API。测试结果如表1-2所示,完成时间单位都是ms。
由此可见,软件实现RSA 2048位密钥操作时间取决于PC平台的CPU,内存和算法,而TPM则决定于芯片内部的Cryptographic Co-Processor,SHA-1 Engine和Key Generation各个部分的性能。在实际的很多应用系统中,都是直接调用TPM命令来完成基础加密功能和基于TPM的身份验证功能。
3 结束语
TPM芯片目前已广泛应用到PC中,极大地增强了平台的安全性。这样的安全性增强是通过TPM功能设计和比较安全的构架完成的,但考虑在任意TPM命令执行序列下,TPM系统状态是否安全的判定属于NP-complete问题,只有在特定的条件下可解,同时,通过对TPM接口的两个基本密码功能的执行时间进行测试,可以看出TPM芯片构造和命令实现模块设计的独立性和性能。
摘要：作为可信计算平台核心,可信计算模块(TPM)芯片是可信计算安全性的基础。分析TPM及其命令接口的特征和安全性,并对比相同功能的软件实现,分析其执行性能。
关键词：TPM,命令,安全性,性能
参考文献
[1][EB/OL].http://www.trustedcomputinggroup.org.
[2]Trusted Computing Group.TPM Main Part 1 Design Principles Specifi-cation Version 1.2[Z].Revision 94,29 March 2006.
[3]Trusted Computing Group.TPM Main Part 3 Commands SpecificationVersion 1.2[Z].Level 2 Revision 94,29 March 2006.
[4]郝黎明,陆松年,等.对等网中一种基于可信计算的匿名信誉机制[J].上海交通大学学报,Feb,2008,42(2).
[5]R S Sandhu.The Typed Access Matrix Model[J].IEEE,1992.
[6]Andrews G R.COPS-A protection mechanism for computer Systems[D].Ph.D.Th.and Tech.Rep.74-07-12,Computer Sci.Pro-gram,U.of Washington,Seattle,Wash.,July,1974.
[7]David Lie,Chandramohan A.Thekkath,Mark Horowitz.Implementing anuntrusted operating system on trusted hardware[J].ACM SIGOPS Opera-ting Systems Review,Dec,2003,37(5):178-192.