侧边栏壁纸
博主头像
landery博主等级

行李箱里装不下我想去的远方

  • 累计撰写 45 篇文章
  • 累计创建 26 个标签
  • 累计收到 6 条评论

目 录CONTENT

文章目录

远程证明_02_TRIGLA V:公共云中虚拟机运行时完整性的远程验证

landery
2022-05-13 / 0 评论 / 1 点赞 / 111 阅读 / 11,675 字 / 正在检测是否收录...
温馨提示:
本文最后更新于 2022-05-22,若内容或图片失效,请留言反馈。部分素材来自网络,若不小心影响到您的利益,请联系我们删除。

原文信息

  1. 文章标题:TRIGLAV: Remote Attestation of the Virtual Machine’s Runtime Integrity in Public Clouds
  2. 文章中文翻译:TRIGLAV:公共云中虚拟机运行时完整性的远程验证
  3. 文章等级:CCF C
  4. 文章发表时间:2021
  5. 文章作者:Ozga W, Fetzer C.
  6. 完整引用:Ozga W, Fetzer C. TRIGLAV: Remote Attestation of the Virtual Machine’s Runtime Integrity in Public Clouds[C]//2021 IEEE 14th International Conference on Cloud Computing (CLOUD). IEEE, 2021: 1-12.
  7. 全文请查看:全文链接

0 摘要信息

0.1 解决问题

对于在云中部署安全敏感服务的租户来说,信任是最重要的问题。即使在有强大的对手对云的管理权限的情况下,也需要确保部署这些服务的虚拟机(VM)的完整性。解决这一挑战的传统方法是利用可信计算技术,如vTPM,或硬件CPU扩展,如AMD SEV。但是,它们容易受到强大对手的攻击,或者它们只提供虚拟机的加载时间(而不是运行时)完整性测量。

0.2 提出方案

我们提出了TRIGLAV,这是一个允许租户建立和维持对软件及其配置的虚拟机运行时完整性的信任的协议。TRIGLAV对虚拟机的配置和设置是透明的。它在安全登录期间对虚拟机进行隐式验证,并将虚拟机的完整性状态与安全连接绑定。我们的原型评估表明,TRIGLAV是实用的,并且产生的性能开销很低(≤6%)

1 介绍引入

现有的证明协议主要是利用可信硬件来报告执行环境的测量。在可信计算中,可信平台模块证明和完整性测量架构(IMA)提供了一种手段来执行和监测自平台启动以来所执行的软件的完整性。虚拟TPM(vTPM)设计通过引入基于软件的可信平台模块(TPM)扩展了这一概念,该模块与硬件TPM一起提供整个软件栈的完整性测量–从固件、hypervisor直到虚拟机。然而,这种技术不能应用于云,因为对手可以篡改vTPM和虚拟机之间的通信。例如,通过重新配置网络,她可以发动中间人攻击,进行TPM重置攻击,破坏vTPM的安全保障。

可信计算的一个补充技术,可信执行环境(TEE),使用硬件扩展将管理员和特权软件,即操作系统、管理程序,排除在可信计算基础之外。英特尔软件防护扩展(SGX)带有一个证明协议,允许远程验证应用程序的完整性和基础硬件的真实性。然而,它只适用于在SGX enclave内执行的应用程序。在 "enclave "内执行的传统应用程序由于有少量的受保护内存而受到性能限制。由于受保护的内存在所有租户之间共享,SGX在虚拟化环境中的采用受到了进一步限制。

将虚拟机与不受信任的hypervisor隔离的替代技术,例如AMD SEV 或IBM PEF,没有内存限制。它们支持在与hypervisor隔离的情况下运行整个操作系统,同时产生最小的性能开销。然而,他们的证明协议只在虚拟机初始化时提供关于虚拟机完整性的信息。这是不充分的,因为加载的操作系统可能会在以后的运行时间内被操作系统的漏洞或错误配置所破坏。因此,为了验证客户操作系统的运行时(初始化后)的完整性,我们仍然需要依靠vTPM的设计。但是,正如已经提到的,在云环境中这是不够的。

重要的是,这些将虚拟机与管理程序隔离的硬件技术的安全模型假定了在共享执行环境中运行租户的操作系统所造成的威胁,即由流氓操作员、受损的管理程序或恶意的共同租户进行的攻击。这些技术没有解决一个事实,即典型的租户操作系统是一个复杂的软件和配置的混合物,具有很大的攻击载体。也就是说,受保护的应用程序不是像SGX那样的单一进程,而是内核、用户空间服务和应用程序,它们在TEE内运行时可能被破坏,从而使租户的计算和数据受到威胁。这些技术认为保护操作系统是租户的责任,但它们缺乏对客户操作系统进行运行时完整性验证和执行的基元。这项工作提出了启用这些基元的方法,这些基元既不是由上述技术提供的,也不是由现有的云产品提供的。

我们提出了TRIGLAV,一个虚拟机远程证明协议,为在云中执行的传统系统提供完整性保证。TRIGLAV有值得注意的优点。

  1. 首先,它通过在完整性强化执行环境的虚拟机内运行,支持零代码变化的遗留系统。为此,它利用了可信计算来执行和证明hypervisor和虚拟机的完整性。
  2. 第二,TRIGLAV 利用完整性强化机制限制主机操作系统中的系统管理员活动,同时依靠TEE来保护其自身的完整性不被篡改。
  3. 第三,它支持租户从没有配备可信硬件的机器上连接。具体来说,TRIGLAV 集成了安全外壳(SSH)协议。登录到虚拟机时,隐含地执行了对虚拟机的认证。

总结:

  1. 该文设计了一个协议,即TRIGLAV,以证明虚拟机的运行时完整性(第四节)。
  2. 我们使用云计算中常用的最先进的技术实现了TRIGLAV原型(第五节)。
  3. 我们在现实世界的应用中对它进行了评估(第六节)。
  4. 我们讨论了未来的工作,旨在将TRIGLAV与现有的硬件支持的虚拟机隔离机制相结合(第七节)。

2 威胁模型

我们要求云节点由软件构建,其源代码由受信任的第三方认证或可由租户审查,例如,开源软件或根据非披露协议可获得的专有软件。具体来说,这种软件通常在以下情况下被认为是安全和可信的:(i) 它来源于可信的地方,如官方的Linux git仓库;(ii) 它通过了安全分析,如fuzzing;(iii) 它使用内存安全语言实现,如Rust;(iv) 它已被正式证明,如seL4或EverCrypt;(v) 它是用内存损坏缓解措施编译的,如具有堆砸保护(stack-smashing protection)的位置无关的执行文件。

我们的目标是为租户提供一个运行时完整性证明协议,确保云节点(即主机操作系统、管理程序)和虚拟机(客户操作系统、租户的传统应用程序)在预期配置中只运行预期的软件。我们区分了内部和外部对手,两者都没有发动物理和硬件攻击的能力。这是一个合理的假设,因为云提供商控制和限制对其数据中心的物理访问。

内部对手,如恶意管理员或成功提取管理员凭证的对手,旨在篡改管理程序配置或虚拟机部署,以破坏租户的传统应用程序的完整性。她拥有对主机的远程管理权限,允许她配置、安装和执行软件。内部敌手控制着网络。她可以插入、改变和删除网络包。

云之外的外部对手,她的目标是破坏安全敏感的应用程序的完整性。她可以利用客户操作系统的错误配置或使用社会工程来远程连接到租户的虚拟机。然后,她运行专用软件,如软件调试器或自定义内核,以修改传统应用程序的行为。

我们认为TPM、CPU以及它们的硬件功能是可信的。我们依赖于软件和硬件组件所使用的加密原理的合理性。我们将基于软件的侧信道攻击(例如,[29])视为与本工作正交,因为(i)存在反措施(例如,[30]),其存在可作为TRIGLA V协议的一部分进行验证,(ii)在云中提供专用(非共享)机器的可能性。

什么是意思?

3 背景和问题

加载时的完整性执行。 云节点是一台计算机,其中多个租户在相同的计算资源之上并行运行他们的虚拟机。 虚拟机由虚拟机管理程序管理,这是一种特权软件层,提供对物理资源的访问并将虚拟机彼此隔离。 由于 VM 的安全性取决于管理程序,因此必须确保正确的管理程序控制 VM。

可信计算提供硬件和软件技术来验证管理程序的完整性。 特别是,测量的动态信任根 (DRTM) 是现代 CPU 中可用的一种机制,它建立了一个受信任的环境,在该环境中安全地测量和加载管理程序。 hypervisr的完整性测量存储在硬件 TPM 芯片内的专用内存区域中,称为平台配置寄存器 (PCR) 。 PCR 是防篡改的。 它们不能直接写入,只能使用加密哈希函数扩展为新值:PCR_extend = hash(PCR_old_value || data_to_extend)

TPM证明协议定义了如何读取证明PCRs值的报告。该报告使用从背书密钥衍生出来的加密密钥进行签名,该密钥是在制造时嵌入TPM芯片的非对称密钥。TPM还存储一个由制造商签署的证书,其中包含背书密钥的公共部分。因此,有可能检查一个真正的TPM芯片是否产生了报告,因为报告的签名是可以通过从证书中读取的公共密钥来验证的。

运行时的完整性执行。管理员拥有对机器的特权访问,可以完全控制网络配置,拥有安装、启动和停止应用程序的权限。这些特权允许他欺骗DRTM验证过程,因为当hypervisor被加载到内存时,hypervisor的完整性只被测量一次。TPM报告证明了这个状态,直到下一次DRTM启动,即下一次计算机启动。因此,在hypervisor被测量后,对手可以通过安装一个任意的hypervisor或将其降级到一个脆弱的版本而不被发现。

真的假的?

完整性测量架构(IMA)可以缓解上述的威胁。作为被测内核的一部分,IMA实现了一个完整性强制机制,只允许加载经过数字签名的软件和配置。因此,只签署管理虚拟机所需的软件可以限制管理员在主机上进行的活动。DRTM确保加载一个合法的内核,并启用IMA和输入输出内存管理单元,并且可以通过TPM认证协议进行认证。

完整性审计(Integrity auditing)。IMA提供的信息包括:自内核加载以来,有哪些软件被安装或启动,系统配置是什么,以及系统配置是否已经改变。IMA在一个名为IMA日志的专用文件中提供了收集的测量结果的防篡改历史。由于IMA将每个日志条目的哈希值扩展到了PCR上,所以防篡改的特性得以保持。因此,篡改日志的对手无法隐藏其恶意行为,因为她无法修改PCR值。也就是说,她不能覆盖PCR,也不能在不重启平台的情况下将其重置为初始值。

vTPM的问题。 由于PCR的数量有限,TPM芯片不能有效地与许多虚拟机共享。vTPM设计通过运行由管理程序暴露给虚拟机的多个基于软件的TPM来解决这个问题。这种设计要求在与基于软件的TPM建立信任之前验证管理程序(hypervisor)的完整性。我们认为,仅仅验证管理程序的完整性是不够的,因为管理员可以通过使用合法的软件进行攻击来破坏基于软件的TPM的安全保证,正如我们接下来描述的。因此,vTPM不能直接用于提供虚拟机的运行时完整性。

在vTPM的设计中,hypervisor预加了一个4字节的vTPM标识符,允许将通信路由到正确的vTPM实例。然而,vTPM和虚拟机之间的链接是不受保护的,而且它是通过一个不受信任的网络路由的。因此,攻击者可以通过替换网络包内的vTPM标识符来发动伪装攻击,将虚拟机通信重定向到一个任意的vTPM(图1a)。为了缓解这种攻击,我们建议使用传输层安全(TLS)协议来保护通信的完整性。

image-1652412456261

尽管TLS有助于保护通信的完整性,但vTPM和管理程序之间缺乏认证,仍然使对手能够通过发动中间人(MitM)攻击完全控制通信。更详细地说,对手可以配置管理程序hypervisor,使其通过中介软件与vTPM进行通信,从而拦截通信(图1b)。然后,她可以放弃任意的测量或执行TPM重置攻击,从而损害vTPM的安全保证。

为了减轻攻击,vTPM必须确保远程对等体的完整性(它是正确的hypervisor吗?)和它的位置性(hypervisor是在同一平台上运行吗?) 尽管TEE的本地证明提供了关于软件完整性和本地性的信息,但我们不能在这里使用它,因为管理程序不能在TEE内运行。然而,假设我们找到一种方法来满足定位性条件。在这种情况下,我们可以利用运行时完整性测量(IMA)来验证管理程序的完整性,因为在平台上运行的可信软件中,只有一个可以连接到vTPM–管理程序。为了满足定位条件,我们提出以下意见:只有在同一平台上运行的软件可以直接访问同一硬件TPM。我们建议使用硬件TPM在vTPM和管理程序之间共享一个秘密(§IV-C)。然后,vTPM通过验证hypervisor在预共享密钥TLS认证中提出的秘密来认证hypervisor。

最后,入侵客体操作系统的对手可以发动布谷鸟攻击来冒充合法虚拟机。对手可以修改客户操作系统内的TPM驱动程序,将TPM通信重定向到一个远程TPM(图1c)。在被攻击的虚拟机内运行的验证者无法识别他是与连接到他的虚拟机的vTPM还是与连接到其他虚拟机的远程vTPM进行通信。验证者无能为力,因为他无法与vTPM建立一个安全通道,以保证与本地vTPM的通信。为了缓解这种攻击,我们建议利用TEE认证协议在验证者和vTPM之间建立一个安全的通信通道,并利用它来交换一个秘密,使验证者能够唯一地识别vTPM实例(§IV-D)。

4 TRIGLAV 设计

4.1 高层架构

image-1652413562410

它由以下四个部分组成。(A)虚拟机,(B)管理虚拟机的管理程序,使其能够访问物理资源并与其他虚拟机隔离,©实现管理程序运行时完整性执行和认证的可信计算组件,(D)TRIGLA V,在TEE内执行的软件,允许租户认证并执行虚拟机的完整性。

上述组件的配置、执行和操作都要经过验证。

  1. 首先,云运营商引导云节点并启动TRIGLAV。应租户的要求,云提供商生成一个虚拟机。
  2. 接下来,租户与TRIGLAV建立信任(§IV-D),它成为远程平台上第一个受信任的组件。租户要求TRIGLAV检查管理程序是否符合政策,其中包含租户特定的信任约束,如完整性测量(§IV-F)。
  3. TRIGLAV使用IMA和TPM来验证平台的运行时完整性是否符合策略,然后生成虚拟机的公共/私人密钥对。公钥被返回给租户。
  4. TRIGLAV保护对私钥的访问,也就是说,只有当平台符合政策中定义的状态时,它才允许虚拟机使用私钥。最后,租户在SSH握手期间与虚拟机建立了信任。他验证了虚拟机可以使用与之前获得的公钥相对应的私钥。

租户使用自己的SSH私钥,以标准方式验证自己。他的SSH公钥被嵌入到虚拟机的镜像中,或者在虚拟机部署过程中被提供。

4.2 平台引导

云提供商负责正确的机器初始化。她必须打开对硬件技术(即TPM、DRTM、TEE)的支持,启动管理程序,并启动TRIGLAV。

首先,TRIGLAV使用TPM证明与硬件TPM建立连接;它读取TPM证书并在激活凭证程序后生成证明密钥([39]第109-111页)。TRIGLAV确保它使用与本地TPM进行通信,但也可以使用其他方法。最终,TRIGLAV读取了TPM Quote,这证明了DRTM的启动和管理程序完整性的测量。

4.3 虚拟机启动

云提供商请求hypervisor生成一个新的虚拟机。hypervisor分配所需的资源并启动虚拟机,为其提供TPM访问。在这一过程结束时,云提供商与租户分享连接细节,允许租户连接到虚拟机。

TRIGLAV在TEE内模拟了多个TPM,因为许多虚拟机不能共享一个硬件TPM[11]。当被Hypervisor请求时,TRIGLAV会生成一个新的TPM实例,该实例可在一个独特的TCP端口上访问。Hypervisor连接到模拟的TPM,并将其作为一个标准的字符设备暴露给虚拟机。我们进一步使用仿真TPM这一术语来描述在管理程序内运行的基于TEE的TPM,并将其与vTPM设计提出的基于软件的TPM区分开来。

管理程序和模拟的TPM之间的通信容易受到MitM攻击。与TRIGLAV不同,管理程序不在TEE内执行,这使得TRIGLAV无法使用TEE证明来验证管理程序的身份。然而,TRIGLAV通过要求管理程序在建立连接时出示一个秘密来确认管理程序的身份。TRIGLAV在TEE内生成一个秘密,并通过加密通道将其密封到硬件TPM上([42] §19.6.7)。只有运行在与TRIGLAV相同的操作系统上的软件才能解封该秘密。因此,只需检查是否只有受信任的软件在平台上执行,以验证是否是合法的管理程序提出了秘密。

image-1652414185919

图3 将模拟的TPM附在虚拟机上。TRIGLA V在TEE内模拟TPM。每个模拟的TPM都可以通过TLS连接访问。为了防止MitM攻击,TRIGLA V通过硬件TPM与连接的管理程序共享秘密,对其进行认证。为了减轻回滚攻击,模拟TPM在每个非空闲命令上都会增加单调的计数器值

图3显示了将模拟的TPM连接到虚拟机的过程。

  1. 在管理程序生成一个虚拟机之前,它命令TRIGLA V模拟一个新的基于软件的TPM(①)。
  2. TRIGLA V创建一个新的模拟TPM,生成一个秘密,并将该秘密与硬件TPM(②)密封。
  3. TRIGLA V将TCP端口和密封的秘密返回给管理程序。管理者从硬件TPM(③)中解开秘密,并建立一个与模拟TPM的TLS连接,用秘密来验证自己(④)。
  4. 在这一点上,管理程序产生了一个虚拟机。虚拟机启动后,固件和IMA向模拟的TPM(⑤)发送完整性测量。
  5. 为了防止回滚攻击,每次完整性测量都会导致模拟TPM增加基于硬件的单调计数器(MC),并将当前MC值存储在模拟TPM内存中(⑥)。

为了防止多个虚拟机附着在同一个模拟TPM上,TRIGLAV只允许一个客户端连接,不允许重新连接。在与虚拟机建立信任时,可以检测到对手将管理程序重定向到输出虚假秘密的假仿真TPM的攻击(§IV-D)。

4.4 建立信任

租户通过三个步骤与虚拟机建立信任。首先,他验证TRIGLAV在TEE内执行,并在真正的硬件(提供TEE功能的CPU)上运行。然后,他通过利用TRIGLAV验证和执行主机和客户操作系统的运行时完整性,将信任扩展到管理程序和虚拟机。最后,他连接到虚拟机,确保它是由TRIGLAV提供和控制的虚拟机。

由于TRIGLAV的设计并不限制租户拥有任何特定厂商的硬件,而且现有的TEE认证协议也没有标准化,因此我们建议增加一个额外的中介层次。按照现有的解决方案,我们依靠一个可信的证书颁发机构(CA),在签署确认TRIGLAV的完整性和底层硬件真实性的X.509证书之前,进行特定于TEE的证明。租户在TLS握手期间与TRIGLAV建立信任,验证所提交的证书是由CA颁发给TRIGLAV的。

尽管租户远程确保 TRIGLAV 是可信的,但他不能保证他连接到由 TRIGLAV 控制的 VM,因为攻击者可以欺骗网络以将租户的连接重定向到任意 VM。 为了减轻威胁,TRIGLAV 生成一个秘密并与租户和虚拟机共享。 当租户建立连接时,他使用密钥对 VM 进行身份验证。 只有完整性符合策略的 VM 才能访问此密钥。

image-1652422567703

图4,证明协议的高层视图。TRIGLA V在TEE内生成一个SSH公钥/私钥对。租户收到公钥是策略部署的结果。当且仅当平台的完整性符合策略时,TRIGLA V代表虚拟机签署SSH挑战。

图4显示了该协议的高层视图。首先,租户与TRIGLAV建立TLS连接以部署政策(①)。TRIGLAV根据政策验证平台的完整性(②),一旦成功,它将生成SSH密钥对(③)。公钥将返回给租户(④),而私钥则留在TEE内。TRIGLAV规定,只有运行时完整性符合政策的客户操作系统才能使用私钥进行签名。其次,租户初始化一个与虚拟机的SSH连接,希望虚拟机能够证明拥有SSH私钥。SSH客户端请求运行在虚拟机内的SSH服务器签署一个挑战(⑤)。SSH服务器将签名操作委托给TRIGLAV(⑥)。当且仅当管理程序和虚拟机的完整性符合策略时,TRIGLAV才会使用私钥(⑦)签署挑战。SSH私钥从未离开TRIGLAV;只有签名被返回到SSH服务器(⑧)。SSH客户端使用租户从TRIGLAV(⑨)获得的SSH公钥来验证签名。SSH服务器也对租户进行认证,租户使用自己的私人SSH密钥证明自己的身份。SSH服务器被配置为信任他的SSH公钥。一旦SSH握手成功,租户就会在远程平台上建立信任。

4.5 策略执行(Policy Enforcement)

TRIGLAV 策略执行机制保证 VM 运行时完整性符合策略。 在主机操作系统中,TRIGLAV 依赖于 IMA 完整性执行来防止主机内核加载到未进行数字签名的内存文件中。 具体来说,文件系统中的每个文件都有一个存储在其扩展属性中的数字签名。 在内核将文件加载到内存之前,IMA 会验证云提供商发出的签名。 签名验证所需的证书从 initramfs(由 DRTM 测量)加载到内核的密钥环。 在客户操作系统中,客户内核中的 IMA 需要 TRIGLAV 批准才能将文件加载到内存中。 由 TRIGLAV 控制的模拟 TPM 在 IMA 尝试使用不符合策略的测量扩展它时返回失败。 失败指示 IMA 不加载文件。

4.6 租户隔离和安全政策

具有不同安全要求的多个应用程序可能共存于同一台物理机上。TRIGLAV可以确保应用程序在相互隔离的情况下运行,并符合其安全要求。图5显示了TRIGLAV如何为每个虚拟机分配一对公钥和私钥。这些密钥与应用程序的策略和虚拟机的完整性绑定。每个租户使用公钥来验证他与由完整性强化的管理程序控制的虚拟机进行交互。

image-1652422799755

清单1显示了一个安全策略的例子。该策略是一个文本文件,包含硬件TPM制造商的证书链的白名单(第4行),主机内核的DRTM完整性测量(第6-8行),客户内核的完整性测量(第14行),以及客户操作系统的合法运行时完整性测量(第16-18行,22行)。证书链被用来建立对底层硬件TPM的信任。TRIGLAV将DRTM完整性测量值与TPM认证的PCR值进行比较,以确保加载具有启用完整性强化机制的正确的管理程序。TRIGLAV使用运行时完整性测量来验证是否只有预期的文件和软件被加载到客户操作系统内存中。专用证书(第22行)使完整性强制机制变得实用,因为它允许更多的文件被加载到内存中而不需要重新部署策略。具体来说,只要用相应的私钥对允许执行的软件进行签名,就可以让软件通过完整性强化机制。额外的证书(第11、23行)允许操作系统的更新。

image-1652422854496

5 实现

5.1 技术栈

我们决定将原型实现建立在Linux内核上,因为它是一个开源项目,支持广泛的硬件和软件技术。它通常用于云计算,因此,可以证明所提出的设计的实用性。QEMU和基于内核的虚拟机(KVM)允许将其作为一个管理程序。我们依靠Linux IMA作为Linux内核内置的完整性执行和审计机制。

我们选择Alpine Linux是因为它的设计与其他Linux发行版相比,具有安全性和简单性。它由提供一个全功能的操作系统所需的最低数量的软件组成,允许保持较低的可信计算基础(TCB)。所有的用户空间二进制文件都被编译成与位置无关的可执行文件,具有堆栈粉碎保护和重定位只读内存损坏缓解技术。这些技术有助于减轻诸如缓冲区溢出攻击的后果,这些攻击可能导致权限升级或任意代码执行。为了限制主机访问客体内存和状态,我们遵循现有的以安全为导向的商业解决方案,禁用某些管理程序功能,如管理程序启动的内存转储、主机上的巨大内存页、内存交换、通过virtio-balloon设备进行内存膨胀和崩溃转储。对于生产实现,我们建议依靠微内核,如正式证明的seL4。

我们依靠SGX作为TEE技术。SGX的远程认证允许我们验证应用程序是否在真正的英特尔CPU上的飞地内执行。我们用Rust实现了TRIGLAV,它保留了内存安全和类型安全。为了在SGX飞地内运行TRIGLAV,我们使用了SCONE框架和其Rust交叉编译器。我们还利用英特尔可信执行技术(TXT)作为DRTM技术,因为它在英特尔CPU上广泛使用。我们使用开源软件tboot作为预内核启动器,与TXT建立DRTM,提供Linux内核的测量启动。

5.2 原型架构

TRIGLAV原型架构由在SGX enclaves中执行的三个组件组成:监控服务、模拟TPM和单调计数器服务。

监控服务是利用Linux IMA和硬件TPM来收集主机操作系统的完整性测量的组件。每个主机操作系统只有一个监控服务在运行。它可以在一个众所周知的端口上使用,在这个端口上暴露一个受TLS保护的REST API,由租户用来部署策略。我们以为基础实现这部分内容,它提供了一个检测TPM定位的机制。监控服务产生了仿真TPM,并在QEMU和仿真TPM之间的秘密交换中起中介作用。具体来说,它生成并向硬件TPM封存验证QEMU进程所需的秘密,并将该秘密传递给模拟TPM。

被仿真的TPM是一个基于软件的TPM仿真器,基于libtpms库。它暴露了一个基于TLS的API,允许QEMU进行连接。连接是通过SGX飞地内产生的秘密来验证的,只有获得硬件TPM访问权的进程才知道。由于libtpms的实现,我们将模拟的TPM提取成一个单独的组件,这需要在一个单独的进程中运行每个模拟器。

单调计数器服务(MCS)提供对硬件单调计数器(MC)的访问。仿真TPM使用它来防止回滚攻击。我们将MCS设计为一个独立的模块,因为我们预计由于硬件MC的限制(即高延迟,有限的内存覆盖数量),可能需要一个分布式版本,例如ROTE。值得注意的是,MCS也可以使用SGX MC在监控服务和模拟TPM运行的同一个平台上进行本地部署。

5.3 单调计数器服务MCS

我们实现了一个单调的计数器服务(MCS),作为一个在SGX enclave内执行的服务。它利用 TPM 2.0 高耐久性指数来提供MC功能。MCS依靠TPM证明与提供硬件MC的TPM芯片建立信任,并依靠加密和认证的通信渠道( §19.6.7)来保护与TPM芯片从飞地通信的完整性和保密性。MCS通过TLS暴露了一个REST API(§V-D),允许其他enclave远程增加和读取硬件单调的计数器。

仿真TPM通过基于TLS的SGX证明(§V-D)与MCS建立信任,并保持TLS连接的开放,直到仿真TPM被关闭。我们实现了模拟的TPM在执行任何非幂等的TPM命令之前增加MC,例如扩展PCR、生成密钥、写入非易失性存储器。MC值和TLS凭证在模拟TPM状态中持续存在,该状态在运行时和静止时由SGX通过密封来保护。当模拟TPM启动时,它从MCS中读取MC值,然后通过验证其MC值与从MCS中读取的值相等来检查模拟TPM状态的新鲜度。

5.4 基于TLS的SGX认证

我们使用SCONE密钥管理系统(CAS)对TRIGLAV组件进行远程认证,使用英特尔认证服务(IAS)验证SGX报价,生成TLS凭证,并在初始化期间向每个组件分发凭证和CAS CA证书。TRIGLA V组件被配置为通过TLS建立相互认证,其中两个对等体都提出一个证书,由同一个CAS CA签署,包含一个飞地完整性测量。租户不执行SGX远程认证来验证监控服务的身份和完整性。相反,他们在建立与监控服务的TLS连接时,验证策略部署期间远程对等体暴露的证书。生产实现可能使用英特尔SGX-RA来实现类似的功能,而不依赖于外部的密钥管理系统。

5.5 虚拟机完整性的执行

目前的Linux IMA实现将IMA日志条目的完整性摘要扩展到所有活动的TPM PCR库。例如,当有两个活动的PCR库(如SHA-1和SHA-256)时,这两个PCR库被扩展为相同的值。我们对Linux内核做了一个小小的修改。它允许我们不仅与模拟的TPM共享完整性摘要,而且还共享文件的测量和文件的签名。我们修改了由Linux IMA发送的PCR_Extend命令的内容,它使用SHA1库来传输完整性摘要,使用SHA-256库来传输文件的测量摘要,使用SHA-512库来传输文件的签名。在模拟的TPM中,我们拦截PCR_extend命令以提取文件的测量值和文件的摘要。我们使用获得的信息来执行策略;如果该文件不允许被执行,模拟TPM进程将关闭TLS连接,导致QEMU进程关闭虚拟机。

5.6 SSH集成

为了实现与虚拟机的安全连接,我们依靠了OpenSSH服务器。它支持PKCS#11标准,该标准定义了如何与加密设备(如TPM)进行通信,以使用密钥进行加密操作,而不需要从TPM中检索。
我们配置了一个在客户操作系统内运行的OpenSSH服务器,以使用存储在主机操作系统上运行的模拟TPM内的SSH密钥。虚拟机的SSH私钥是在SGX飞地内生成和存储的,而且永远不会离开它。SSH服务器通过PCRS#11将其用于TLS连接,只有当TRIGLAV授权访问它的时候。租户使用他自己的SSH私钥,这不是由TRIGLAV管理的。

6 评估

分两部分介绍对TRIGLAV的评估。在第一部分,我们衡量TRIGLAV内部组件和相关技术的性能。在第二部分,我们检查TRIGLAV在保护流行的应用程序方面是否实用。

效果不错,主要看实现。

7 总结

本文介绍了虚拟机 (VM) 证明协议 TRIGLAV,它允许验证安全敏感应用程序在由预期配置中的预期软件组成和控制的虚拟机中执行。 TRIGLAV 为遗留应用程序提供透明支持,无需更改 VM 配置,并允许租户远程证明平台运行时完整性。 TRIGLAV 会产生低性能开销 (≤ 6%)。

以上基本是论文的翻译,下面我会用自己的话总结一下。请看下一篇。

1

评论区