论文阅读（一）_vtpm ibm

所有论文笔记请戳：http://blog.csdn.net/lwyeluo/article/details/54017718

 

 

1. Trusted Geolocation-Aware Data Placement infrastructure clouds

2015-12-09

摘要

云中数据的地理定位成为亟待解决的问题，尤其是在不同行政区域法规与数据所有者需求不兼容的情况下。本文提出了一个允许云用户控制数据的地理位置，使用明文存储或者处理的机制。平台的状态通过可信计算原则与远程证实实现。允许云用户设置明文数据不在他们制定的行政范围内开放，这是通过将获取明文数据的解密密钥，与云主机的地理位置以及平台状态进行封装来实现。本文将给出实现与在开源的云基础设施上的性能度量的细节描述。

贡献

1. 提出一个协议，用来在云主机平台上安全存储位置信息，并且使用这些信息来确保数据仅仅在某些平台上是明文显示，这些平台是放置在用户指定的地理位置。

2. 提供了一个上述协议的实现细节。

3. 提供了信任链的安全分析。

问题陈述：

用户向CSP提供的存储中写入一个文件，那么：

1. 该文件及其备份的明文仅仅能够被用户初始指定的行政单位看到。

2. 指定的行政单位在文件首次写入的时候指定，其后不能修改。防止敌手随后更改文件与行政单位之间的联系。

3. 如果某个文件是由用户写入的文件操作而生成的，那么该文件同样必须满足用户指定的行政区域约束。

设计

架构

API endpoint：对象存储的公有API，一旦request到来时，代理服务端从ring的对象中查找location、路由请求并处理异常。

Ring: 使用分布式hash table实现的逻辑结构，该hash table将存储实体的name映射到地理位置上。使用zones、devices、partitions以及replicas维护map。数据使用ring的zones进行隔离，每个zone可以看成一个数据中心。假定每个zone处于不同地理位置。

Object Server： 一个简单的二进制对象存储器，能够存储、检索、删除本地设备中的对象。

Replicators：面对网络或者节点崩溃时维护一致性。

模型

守护进程D（算法1）运行在存储节点上，在host的主板上附着一个navigation device用来获取host的location，再使用本地的地理位置编码数据库将location映射到cell，再讲cell扩展到TPM PCR15。如果location发生变化，则PCR15的值会发生变化，这样预先seal的数据将不会被解密。

1. Towards Secure Instance Migration in the Cloud

   摘要

托管服务提供者逐渐从专用硬件转移到云计算。然而，公司对于将他们的敏感数据转移到这种数据不再由自身控制的平台上抱有质疑。云计算的现收现付模式、并且向很多不同的租户共享基础设施的方案带来了很多的安全话题，提供一种可信、机密的方式来提出安全机制是很有必要的。现有的IaaS采取的都是基于软件的解决方案。然而，目前的研究表明这种纯软件的方案是脆弱的。TCG提出了硬件可信根的概念，将高度敏感的信息存储在一个叫做TPM的协处理器中。

迁移是云基础设施张一个重要的过程。目前有很多方案来提高这些服务的性能，如web、database，具体来说如CloudFront、ELB等等。这些服务相当频繁地在云基础设施之间迁移用户的数据，然而，提供商并没有给出硬件上的解决方案。本文中我们在OpenStack中提出了一个新的组件——安全实例迁移模块SIMM，SIMM基于可信计算技术，在迁移发生的时候保护实例数据的完整性。在SIMM模块的帮助下，云用户能够对他们敏感数据的安全性更加放心。

    针对的问题：

To summarize, there is no hardware backed secure instance migrating solution available，

no mechanism available to check the integrity of the instance before and after the migration

架构

    首先，对要迁移的远程系统进远程证实，如果成功，目的服务器则生成一个不可迁移的公私钥对，私钥存储在TPM中，公钥分发给原服务器端的SIMM模块，该SIMM模块对要迁移的实例进行加密，在数据传输到目的端后，目的端的SIMM模块请求TPM对实例进行解密，之后执行正常的迁移操作。

确保仅仅只有目的端的SIMM模块能够对加密的实例进行解密，确保安全。

1. Design and Deployment of a Trusted Eucalyptus Cloud

   摘要

中小型公司越来越倾向于将商用应用程序放在这种按需计费与具备可扩展性能的云设施上，而不是建立自身的软硬件设施。然而，在云能够胜任这个任务前，必须要解决的问题是隐私等安全问题。

Eucalyptus是一个开源的云计算框架，实现了IaaS。这种IaaS模型允许用户在云基础设施上运行与控制整个VM，然而，这种设施的主要隐私问题在于怎么来确保用户数据与计算的完整性与机密性。本文基于TPM提供的远程证实功能设计与实现了Trusted Eucalyptus云架构，确保用户的虚拟机仅仅在符合完整性要求的node上执行。实验表明这个架构在性能方面是可行的。

设计

Eucalyptus

Eucalyptus的总体设计如下图所示，其中：

• Cloud Controller（CC）：云的web接口，为用户提供front-end工具来向云服务提出请求。CC同时负责跟踪云资源，建立调度决策，把用户请求转发给NC。用户仅能与CC交互。CC里有三个组件：1）资源服务：资源分配与检测，2）数据服务：管理用户以及系统相关的数据，3）接口服务：提供接口，认证，系统管理工具等。
• Node Controller（NC）：host用户的VM与服务
• Cloud Storage（CS）

Trusted Eucalyptus

增加一个组件Trusted Integrity Verifier（TIV），作为可信第三方与签证机构，提供对云的完整性度量与验证云节点的完整性。

    符号：nx：x产生的nonce，{z}K：使用K加密数据z。

    认为CC是不可信的。

NV中增加1）TPM芯片2）安全VM检测（SVMM）3）IMA。当NC第一次启动时，会向TIV验证完整性，成功则在TIV中注册一个可信的密钥，NC将这个密钥写在易失存储中，重启时需要重新注册。

CS中存储是加密的。

SVMM是在VMM的基础上增加一些安全功能，协助安全的VM迁移进程，确保VM仅仅能够迁移到可信配置的节点上，确保特权用户或者系统管理员不能够监测与修改客户端VM。

在SVMM初始化之前Eucalyptus的云节点必须经过一个安全的boot阶段，SVMM的成功启动就意味着系统有已知的好的配置。

Protocol

• NC注册

    TIV维护一个包含所有的可信节点的list，包括NC id | EK _{pub nc} | TIK _{pub nc} | ML，并将自身的EK pub _TIV| TIK pub _TIV | ML公布。

    Success意味着NC有已知的配置，也就是说SVMM在这上面可信的执行。

• 安全VM启动

用户从CS中取得加密存储（解密密钥DK_vm）的可信第三方的VM实例，向CC发起launch实例的请求，NC收到请求之后，取得vm对应的数据img(使用DKvm加密),kernel,ramdisk。

Step1是为了确保只有TIV信任的节点才能够获取DKvm。

Step2是为了让TIV来判断当前NC是否可信

• 安全VM迁移

  目的：让VM迁移到一个可信的node上。

  SK：会话密钥

Step3: TIV使用NB的TIK进行第一层解密（说明NB是可信的），第三层解密说明NA是可信的。

实现

 

1. Time to Rethink: Trust Brokerage using Trusted Execution Environments

   摘要

数字数据的挖掘与分析有着提高生活质量的潜能。然而，隐私与秘密信息的丢失不利于这个目标的实现以及广泛应用。传统的数据保护度量更趋向与集中在数据silos上，严重限制了大数据的范围区域。一些类似于隐私保护多方计算MPC、数据de-identification等技术能够打破这个silo。然而，现有的这些技术机制集中在平衡隐私与实用性，MPC也仅仅部署在某些合适的应用程序上。

随着基于硬件的可信计算环境的功能与能力日益增长，本文提出了一个可供选择的方向：将TEE作为中立的环境来有效地使用多方计算。在文章最后，我们对这种技术的现状进行调研，提出了一个普适的初始的方案架构来应对剩下的挑战。

架构

在TEE上运行一个分析程序，这个程序将会执行从不同的不可信的数据提供者中获取的数据。证实和可信通道能够用来协商与提交安全与隐私策略。从外部软禁提供者中获取到的分析应用程序在一个中立的环境上执行，这个环境能够很强的保护程序，来应对硬件与软件攻击。

具体来说，用户从外部的应用程序提供者上选择获取一个分析程序，并将该应用程序提交给计算提供者的TEE上，这个程序会捆绑上用户可选的一个或者更多的需要支持的安全与隐私策略。分析程序与数据提供者交互，证实应用程序的身份，以及被加载到TEE中的隐私与安全配置。在数据提供者向分析程序发送数据之前，会验证证实过程提供的信息。如果请求遵守某些不同的策略，则使用可信通道向分析程序提供数据。分析程序借助TEE确保在计算结果过程中执行这些安全与隐私策略。完成后可能还运行某些过滤之后再提供给用户。

对比

MPC方案会有很大的性能开销，要求对每个应用程序与数据集进行重新设计，DDI方案有很好的性能，然而，数据的实用性低，因为计算结果可能会被隐私过滤器歪曲，设计在不能在不同的数据集上获得相同的设计。而TEE方案有很好的性能与数据实用性。

TEE方案需要解决的安全问题

• 安全评估

  对大量的TEE解决方案进行评估，确定其能够实现的安全属性等。

• 应用程序安全

  攻击者通过应用程序欺骗使用者下载恶意程序

• 形式化与策略
• 隐私保护
• 应用程序可实施性

1. Trusted Execution Environment what it is, and what it is not

Sabt M, Achemlal M, Bouabdallah A. Trusted Execution Environment: What It is, and What It is Not[C]//Trustcom/BigDataSE/ISPA, 2015 IEEE. IEEE, 2015, 1: 57-64.

摘要

研究复杂的安全的系统已经成为当今的趋势，在这种情况下，TEE被用来丰富可信平台。TEE是一个隔离环境，在这个环境中，应用程序不需要考虑系统的其他部分，并且能够安全的执行。然而，TEE缺少精确的定义与明确的构件块。本文中对TEE进行明确的定义并分析它的核心属性，并且更进一步的讨论与TEE有关的概念，与ARM的trustzone进行对比分析，最后给出TEE会遇到的攻击与解决方案。

介绍

    TPM的一个缺陷在于不能为可信第三方提供一个隔离的安全之星环境。

 

    现有TEE的几种定义：

1. Terra：TEE使得VM与平台的其他部分隔离开，通过内存硬件保护与存储的加密保护，TEE的内容不能被未认证方观察或者干扰
2. Advanced Trusted Environment：TEE为了应对，实现隔离属性、生命周期管理、安全存储、加密密钥与应用程序代码的保护过程中出现的威胁。
3. TEE system architecture：TEE是一个将设备与系统其他部分隔离的执行环境，能够应对普遍的软件攻击，
4. Trustworthy Execution on Mobile Devices: isolated execution, secure storage, remote attestation, secure provisioning and trusted path

   概念

   Separation Kernel

   在多方环境中用来建立隔离控制信息流。要求的安全属性有：

5. 数据分离：一个partition不能读写其他partition
6. 暂时隔离：共享资源不能向其他partition泄露信息
7. 信息控制流：除非明确指定，否则不同partition之间不能交互
8. 错误隔离：错误不能传递到其他partition

   TEE

运行在隔离内核之上的防干扰执行环境，确保执行代码的真实性、运行状态下的完整性以及存储在永久性存储中的代码、数据与运行状态的机密性，能够向第三方提供远程证实功能，TEE能够安全更新，能够应对所有的软件攻击与对系统主存的硬件攻击，不能应对后门泄露。

Trust

Trust分为静态与动态，静态只需要在部署前进行一次度量，（可能是按照CC标准），动态需要在整个生命周期里持续地度量。TEE是静态与动态并存的。部署前，由ROT来保护TEE的完整性，并按照CC标准验证profile，TEE运行成功之后，则由分离内核保护完整性，所以是半动态的，而非动态的。

SEE

SEE（安全执行环境）：确保1）真实性：code执行中不会被更改2）完整性：执行中不会被干扰3）机密性。与TEE不同的地方在于：SEE没有ROT，不支持更新应用程序与机密数据；TEE是一个确保trust的SEE。

DRTM

DRTM：一系列技术使得在没有信任先前加载的软件情况下，能够将某些代码放入隔离环境中执行。DRTM并不提供安全存储以及诸如远程证实、完整性度量等的信任机制。需要主存作为运行时内存，不能应对主存攻击。DRTM不支持并发，在隔离环境执行完成前所有软件都是frozen。

TEE构件块

Secure boot：只有满足某些特定属性的代码能够被加载，一旦被修改，boot过程中断。

 

Secure Scheduling：在TEE与系统的其他部分保证平衡与效率。TEE不能影响主OS的响应。

 

Intel Environment Communication：TEE与系统其他部分的接口。可能会出现的攻击：1）消息overload2）用户与控制数据协同3）共享页移除导致的内存错误4）ubnound wait。

 

Secure Storage：确保存储数据的机密性、完整性与freshness。最常用的实现方式是密封存储，这种存储至少需要三个组件：1）只能被TEE访问的私钥2）密码学算法支持3）数据回滚保护机制

 

Trusted IO path：TEE与外设。

工业界的TEE

    Nokia与Samsung公开了TEE，前者使用ObC，后者使用TZ-RKP。STMicroelectronics与LInaro的TEE（OP-TEE）已经在github上开源。

比较：

 

1. Open Attestation

可信计算池：

    英特尔 TXT 是许多装有英特尔至强处理器的系统的一个特性，它建立了一个硬件可信根， 允许测量并验证启动环境。这个经过测量的启动和就与服务器上的预计"已知良好"启动环境对比， 以确认这个环境没有被篡改。基于英特尔向开源社区贡献OpenAttestation 而实现的远程证明提供了在云环境中查询和验证系统完整性或可信度的机制。这些经过证明的信息为识别可信平台和不可信系统提供了基础—这是创建可信计算池的基础，用于托管有权限或敏感的数据和工作负载。

可信计算池允许设置基于策略的控制措施， 用于限制敏感的指定虚拟机从可信平台迁移到其他可信平台。 这些控制措施也防止虚拟机从未验证的系统迁移到可信平台上。 这些机制增强了敏感数据或服务的隔离， 同时允许使用基于云的资源池。

• 通过验证启动环境而提供审计支持
• 基于策略的实时迁移
• 合规报告

   

OpenAttestation 在 OpenStack 中实施， 供用户验证启动组件的完整性（或者是否缺乏） ， 通过基于平台信任度控制虚拟机位置而帮助减少与间谍软件相关的威胁， 增强安全性， 并且为满足审计和合规要求而提供硬件支持。 OpenAttestation 的核心机制如图 2 所示.

作为这些第三方软件堆栈的一部分，使用 OpenAttestation可以使云管理软件远程检索和验证目标主机的完整性。OpenAttestation允许管理员设置白名单表，以建立已知良好平台配置注册表 (PCR)，用于验证主机完整性。OpenAttestation 服务采用隐私证书机构 (PrivacyCa) 和鉴定员与主机通信， 并验证主机， 如图 3 所示。

 

PrivacyCA 提供并且验证主机的证明身份密钥， 而鉴定员采用TrouserS 可信软件堆栈与主机代理通信， 以检索并验证主机的PCR。 查询 API 可以查询主机信任度状态， 历史完整性报告门户鉴定员（参考实施）在内部追踪每个主机的历史完整性报告。门户提供了一个界面， 用于查看历史数据以及主机报告的详细完整性数据。 白名单表格 API 在良好 / 已知白名单表中增加或删除条目。 服务提供了 API 和存储器， 用于定义环境中的多个MLE、 属性、 基于策略的信任度定义， 以及其他关键数据， 用于支持可信计算池。

OpenStack Nova 调度器将工作负载分配到可信主机上执行， 如图 4 所示。 在这个决定过程中， 第一步是使用可信过滤器确定哪些平台可信， 方法是对比每个主机的密钥 / 数值对与 OpenAttestation 服务为该主机返回的数值（即： 可信主机的值为 " trusted" ， 不可信主机的值为 " untrusted" ） 。 如果主机值与 OpenAttestation 服务值匹配， 主机则通过过滤器； 如果值不匹配， 主机则不能通过过滤器，因此不是处理预订实例的候选者。

 

1.  

1. 远程证实服务（remote attestation service）

目标：

允许用户在符合目标安全属性的host上部署VM，管理员有效地检测管理VM状态

架构：

组件一：OAT（包括host agent与appraiser子模块），其中host agent搜集完整性信息，生成报告发送给认证者，Appraiser验证完整性报告，生成节点的完整性等级。

组件二：RA verifier，验证分析云节点IMA信息。

    用户通过dashboard或者其他请求部署一个带有安全属性的VM，Nova schedule向OAT发送请求获取当前host节点完整性等级，OAT通过controller与compute节点远程证实，若完整性等级有效，则将IMA信息发送到RA verifier，OAT将host最终完整性等级返回给nova schedule，Nova schedule选择合适host部署VM。

1. 可信任openstack原型（trustworthy openstack prototype）

 

1. Scalable Attestation : A Step Toward Secure and Trusted Clouds

目标

提出Scalable Attestation，融合安全启动与可信启动。在KVM+openstack+ openattestation上实现，以低成本提供完整性保护。

• 可信启动

  能够度量整个启动序列，能够被用于证实。

  Not scale well，签名、证实上的性能开销，以及白名单的维护困难。

• 安全启动

  安全硬件存储区域存储公钥，系统中所有文件被签名，这样，启动时验证签名判断安全性。不能提供证实功能，仅能验证硬盘中的文件，不能验证内存中的文件。

• IMA
• Secure Enclaves and Secure Executables

  Princeton大学提出的架构，protect sensitive software from other software running on the
  same system。

   

度量：对IMA模板定义ima-sig，以便于在度量日志中加入签名，ML的一项：模板名（ima-sig）、hash、路径、签名，hash扩展至PCR10.

 

评估：OAT本身仅能评估PCR0-7，本文做出扩展，使之能评估IMA-PCR10，OAT重新计算ML中的每一项，计算时利用已知的公钥验证签名。如果PCR值不匹配、验证签名失败、文件没有签名都会导致验证失败。验证失败会像OpenStack主机管理与VM部署组建发送消息通知。

首先，证实服务与主机系统交互TPM的PCR值与ML，其次，云评估者验证PCR与ML，再次，将验证状态通知给自定义的控制器，若验证失败，控制器向Openstack管理组件发送请求，根据敏感程度请求目标主机进行修复（撤走用户、halt、re-image）。

 

实现：两种云环境：IBM system X服务器与IBM softlayer bare-metal 云环境

修改Ubuntu的mkinitrd与RHEL的dracut，建立初始的RAM disk，其中包含了需要在boot时加载的证书。

    OAT运行在boot阶段，发送boot阶段的度量值给OAT评估者，评估者验证签名并将数据写入数据库。本文对OAT1.6进行扩充，增加对IMA度量值的评估。

图四，首先重新计算PCR10，分析被度量的文件，指出被哪些单位签名过，最后给出验证失败的记录项。

1. vTPM: Virtualizing the Trusted Platform Module

   摘要

在一台拥有无限VM的物理机上允许可信计算技术，通过虚拟可信平台模块，使得TPM的安全存储与加密功能能够在VM中使用，支持在虚拟化环境中建立可信，特别是对软件完整性的远程证实。

使用软件实现了整个TPM规范，增加了创建与销毁TPM实例的功能，支持vTPM的挂起与恢复以及迁移操作，在vTPM与硬件TPM的连接上给出了四种设计。

问题

虚拟化带来的成本优势同时引入了安全问题

1. 共享相同平台的工作量可能需要分离，如政府要求银行在市场分析与安全保险部门之间维护一个严格的分离；商业利益要求竞争对手不能访问对手的数据。
2. 恶意软件威胁更加严重

要求：软件完整性（TPM）与工作量隔离（VMM）。

将TPM虚拟化的挑战：

• 在高层支持诸如可信建立的安全概念
• 通过管理签名密钥与证书将信任链从物理TPM扩展到vTPM
• 支持vTPM实例的迁移

贡献：

• 定义vTPM的要求，包括迁移
• 针对这些要求给出vTPM架构
• Xen上实现
• vTPM安全证书的四种可选机制
• 有效

vTPM要求

• 与物理TPM有相同的使用模型与命令集
• 在VM的生命周期内强绑定VM与vTPM，包括迁移
• 维护vTPM与其下的TCB的强绑定
• vTPM与TPM能够明确区分（不同的安全属性）

挑战：

• 支持vTPM的挂起与恢复，包括迁移
• 维护vTPM与其下的TCB之间的绑定关系

架构

1. vTPM server-side不知道是由哪个vTPM实例发送的命令请求

四字节的标识符，用于说明哪个vTPM实例能够接收哪个虚拟机的信息，是由server-side定义的，所以不能被VM所伪造

1. 维护一个list：virtual- machine-to-virtual-TPM-instance associations，在VM的整个生命周期内维护绑定关系

1. Capability应当紧紧被root实例的拥有者访问。

特权vTPM实例

1. 每个vTPM实例拥有独立的key继承树，优势：不需要借助硬件TPM做加解密，速度更快；简化迁移操作。

有没有简单的办法能够确保vTPM的EK是有效的？

1. 扩展命令集

• vTPM manager cmd：setup，对OS内核与相关boot文件度量，度量值写入PCR
• migration：强制保护要迁移的vTPM实例（如何保护？）
• utility：将vTPM实例的某些命令路由给孩子vTPM

 

1. vTPM迁移

    

   

2. TCB

   要证实虚拟机必须要首先保证vTPM的运行环境是可信的，因而，需要先证实hypervisor以及boot过程。

       通过提供两种不同类型的PCR来解决这个问题，low PCR复制了物理TPM的BIOS、bootloader以及VMM的度量值，使用PCR9度量guest os的度量值，这样挑战者能够看到所有相关的度量值。

       

   

   实现

Xen上实现。

使用xen现有的共享内存机制在前端与后端驱动间传递信息。

应用举例：IMA

如何确保迁移时非对称存储密钥仅仅会迁移给可信的vTPM？

    要求目的vTPM的使用AIK签名的存储密钥。

遇到的问题：

• 谁能够为vTPM提供EK证书？
• 这个证书能够代表什么？

解决方案：

1. 将vTPM的EK证书绑定在物理TPM的AIK证书上。
   1. 优势：保留普通的证实流程

   

2. 不签发vTPM的EK，而是使用物理TPM的AIK产生vTPM的AIK
   1. 优势：快速
   2. 劣势：变更标准的证实过程

1. 使用本地认证机构为vTPM颁发EK证书
   1. 没有将证书链接到物理TPM，直接当成物理TPM
   2. 不需要修改标准证实流程
2. 使用安全协处理器来代替物理TPM

对vTPM的迁移的影响：

前两种解决方案要求在迁移前要撤销与物理TPM的链接

解决方案对比

1. Design and Implementation of a TCG-based Integrity Measurement Architecture

   摘要

本文为linux设计与实现了一个安全完整性度量系统，所有加载到linux系统的可执行内容在执行前均会被度量，将TCG可信的概念扩展到应用层。并将其应用在一个web服务器应用程序上说明系统如何检测非预期的程序，如rootkit等。

贡献：

1. 无干扰的、可验证的远程软件栈证实机制
2. 针对动态可执行内容的有效的证实系统
3. 一个不需要新的CPU模式或者新操作系统的易处理的软件栈证实机制

 

安全boot缺陷：

可信boot：完整性要求并不是固定的，而是由远程用户指定的

 

grub.cfg配置文件不需要度量的原因：

• 不会修改已经加载的代码
• 其他子序列文件的加载能够被完整性平台所看到

 

什么需要度量：

• 验证范围：所有进程都应该被度量，除非进程之间的信息流有强制约束。
• 可执行内容：对于所有的进程来说，不管是被操作系统、动态加载还是被其他应用程序加载，这些可执行的代码都应该被度量
• 结构化数据：对每个进程，数据内容有可确认的完整性语义的、被操作系统、动态加载或者被其他程序加载的数据应该被度量。
• 非结构化数据：对每个进程，数据内容没有可确认完整性语义、数据的完整性取决于修改它的进程的完整性，或者完整性可能更新的数据应该被度量。

 

度量列表应当满足的性质：

• 新鲜、完全
• 真实、不可更改

 

安全boot与可认证boot

• 安全boot使得系统能够度量自身的完整性，并且如果完整性被破坏讲终止boot过程。如Arbaugh使用签名的hash值来认证boot阶段的每一层
• 可认证boot

 

IMA三个主要组件：

• 被证实系统上的度量机制：决定运行的环境的哪些部分需要度量、什么时候度量以及怎么安全地维护
• 完整性挑战机制：允许授权的挑战者来检索度量日志
• 完整性验证机制：验证度量日志是完全的、防篡改的、实时的，验证度量日志每一项