【论文笔记】SoK: Understanding the Prevailing Security Vulnerabilities in TrustZone-assisted TEE Systems

本文主要是介绍【论文笔记】SoK: Understanding the Prevailing Security Vulnerabilities in TrustZone-assisted TEE Systems,希望对大家解决编程问题提供一定的参考价值,需要的开发者们随着小编来一起学习吧!

SoK: Understanding the Prevailing Security Vulnerabilities in TrustZone-assisted TEE Systems

  • 题外话 所谓TEE和Arm TrustZone
  • I. INTRODUCTION
  • II. BACKGROUND AND MOTIVATION
  • III. OVERVIEW
  • Ⅳ. ARCHITECTURAL ISSUES
  • Ⅴ. IMPLEMENTATION ISSUES
  • Ⅵ. HARDWARE ISSUES
  • VII. DEFENSES FOR TRUSTZONE-ASSISTED TEES
  • VIII. BEYOND TRUSTZONE-ASSISTED TEES
  • IX. CONCLUSION

题外话 所谓TEE和Arm TrustZone

主要来源:系统讲述TEE TrustZone的博客
(ps:这一小部分仅针对小白,若内容有误,烦请大神指正,不胜感激!)

先从百科上了解这两个名词:

  • TEE
    • Trusted execution environment 可信执行环境
    • IT专业用语,应用于安全智能设备,安全支付等领域。
  • TrustZone
    • ARM TrustZone® 技术是系统范围的安全方法,针对高性能计算平台上的大量应用,包括安全支付、数字版权管理 (DRM)、企业服务和基于 Web 的服务。
    • TrustZone 技术与 Cortex™-A 处理器紧密集成,并通过 AMBA® AXI 总线和特定的 TrustZone 系统 IP 块在系统中进行扩展。此系统方法意味着可以保护安全内存、加密块、键盘和屏幕等外设,从而可确保它们免遭软件攻击。
    • 按照 TrustZone Ready Program 建议开发并利用 TrustZone 技术的设备提供了能够支持完全可信执行环境 (TEE) 以及安全感知应用程序和安全服务的平台。

定义看起来很复杂,但大体能理解这两个名词与安全漏洞攻防有关,那么我们先从一般性漏洞问题上去理解。

一般应用程序发生漏洞,其解决办法通常是对大型程序进行“隔离限制”,即隔离在“沙箱”中,限制该程序与系统其余部分之间的所有交互。故攻击者只能通过代理与系统进行交互,由于代理进程非常小,由此可以确保代码免遭泄露。

我们了解到,内存损坏漏洞问题是个极常见的问题,而这种类似问题甚至会发生在现代操作系统的内核之中,然而,对内核的隔离却不是这般容易。由此,“可信执行环境”(TEE)横空出世。

TEE 将关键代码和数据与主要操作系统隔离开,这样的话,即便主要操作系统被劫持,TEE内部的关键代码和数据仍能不受影响。

隔离内核,我们需要TEE的存在,也就是需要在操作系统内核受到威胁时仍能确保数据安全的保障,这一点需要一种特殊硬件的支持——Arm TrustZone。在Arm上运行的设备(如智能手机)可以使用TrustZone执行硬件级别的隔离,由此确保TEE的安全。

想象两个盒子,受TrustZone保护的代码和数据在一个盒子里,不受TrustZone保护的代码和恶意外围设备在另一个盒子里,这就出现了两个世界:普通世界(NW)和安全世界(SW)。这两个名词再百度百科中似乎没有定义,有资料解释如下:
资料好,对名词的定义大概了解到这里,下面进行论文笔记。


【摘要】文章目的:

  • 了解哪些类型的漏洞和限制会影响现有的TrustZone辅助的TEE系统;
  • 正确构建它们的主要挑战是什么
  • 可以从研究社区借鉴哪些贡献来克服它们。

I. INTRODUCTION

  • Trusted Execution Environments (TEE):保护应用程序完整性和机密性的关键安全机制;可信执行环境。
  • Arm TrustZone:在移动环境中实现TEEs的硬件技术。
  • TrustZone-assisted TEEs:更安全。
  • Trusted Computing Base (TCB):计算机内保护装置的总体,包括硬件、固件、软件和负责执行安全策略的组合体。比标准操作系统小几个数量级。
    它建立了一个基本的保护环境并提供一个可信计算机系统所要求的附加用户服务。
  • 本文分析了:近5年(从2013年到2018年中期)的207个TEE漏洞报告,重点关注由Qualcomm、Trustonic、Huawei、Nvidia和 Linaro这5家主要供应商为基于Arm的设备开发的广泛部署的TEE系统;
  • 本文内容包括:对现有漏洞的程度和原因的多重见解,以及缓解它们的潜在解决方案。

发现

  • TEE系统存在关键bugs。Trusted Applications (TAs)及可信内核内已发现很多bugs。
  • 劫持脆弱的Tas。trustzone辅助的TEE系统在架构上有诸多缺陷。
  • 大多数TrustZone系统中,其架构和微架构级别上的重要硬件属性被忽略了。

本文贡献如下:
(1) 首次系统地研究了广泛使用的TrustZone辅助的TEE系统中的已知漏洞(Ⅲ);
(2) 从现代操作系统的角度分析TEE系统的主要架构缺陷(Ⅳ);
(3) 引入分类法来对实现bug进行分类,这些bug可能被用于开发TEE系统(Ⅴ);
(4) 提高对可用于攻击TEEs的硬件元素的认识(Ⅵ);
(5) 分析研究界提出的主要防御技术(Ⅶ);
(6) 将TrustZone辅助的TEE与其他TEE技术结合起来(Ⅷ)。

II. BACKGROUND AND MOTIVATION

1. Trusted Execution Environment and Arm TrustZone

  • 本文重点关注:Cortex-A TrustZone的实现(该技术广泛应用于移动设备)。
  • TrustZone的核心概念是两个保护域:secure world(SW)normal world(NW)
  • 每个物理处理器核提供两个虚拟核以及它们之间的安全切换机制
    • 两个虚拟核:被认为“secure”(SW);被认为“non-secure”(NW);
  • 系统当前的执行状态由处理器的NS位标识。
  • 硬件逻辑存在于 TrustZone-enabled的AMBA总线中,它将处理器的安全状态扩展到其他系统组件,以确保SW资源不能被NW组件访问。(访问控制)

2. Software Architecture of TrustZone-assisted TEE

  • NW(Rich Execution Environment, REE)中运行不受信任的操作系统;
  • SW中运行TEE软件组件(参见Figure 1)。
  • SW内部,可信操作系统以监督模式(保护环EL1)运行;
  • 可信操作系统以用户模式(保护环EL0)运行时,它对TAs的生命周期提供运行支持。
  • 可信操作系统的核心是可信内核,它为调度和管理TAs提供了基本的操作系统原语。
  • 可信操作系统还实现了访问可信外设的设备驱动程序,通过环境交换SMC指令和共享内存,处理跨环境的请求,并且实现了共享库(如加密)和TEE原语(远程认证、受信任I/O和安全存储)。
    • SMC是TrustZone的一部分。Non-Secure world要切换到Secure-World的时候需要进入Monitor模式才能进行操作,而在armv7a中就是通过SMC指令进入到TrustZone。来源:armv7a中的SMC指令应用
  • 在保护环EL3中,secure monitor实现了环境之间的安全上下文切换机制,并以最高权限运行。
  • TEE bootloader引导TEE系统进入一个安全状态,这对实现可信引导原语是至关重要的。它被分为两个部分,首先在EL3中运行,然后在EL1中运行。
  • 可信操作系统(trusted OS)、secure monitor以及 TEE bootloader 共同构成了典型TEE系统的TCB软件。
  • 因此,TEE设计者的目标是实现小且无bug。
  • (ps:实在不知道‘world’怎么翻译比较好,总觉得译为‘世界’有点不妥当,所以纹紋都译为‘环境’啦,望关注)
    图1

3.Attacking TEE-enabled Devices

  • 下面使用Table I中列出的一组具有代表性的漏洞来劫持 TEE-enabled 设备的两个关键组件:TEE内核和REE内核(即Linux)
  • 这些漏洞演示了在运行 Qualcomm’s TEE 系统的平台上,如何将用户级NW应用程序升级其特权。

TEE内核的妥协:
Gal Beniamini以Qualcomm开发的TEE系统Qualcomm TEE (QSEE)为目标,展示了如何以两种不同的方式从非特权用户级NW应用程序劫持TEE内核。

  • 一种方法需要分几个步骤将特权升级到Linux内核(参见Figure 1)。
    首先,使用exploit E3来控制Android的mediasserver,它拥有对TEE驱动程序的特权访问权;然后提升Linux TrustZone驱动程序访问SMC接口(E2)的权限。
    exploit(E1)利用了TEE内核中的一个bug,并在SW中使用EL1特权实现了任意代码执行。一旦控制了TEE内核,攻击者可以发动其他攻击。例如:劫持一个客户TA以提取密钥,并打破Android的完整磁盘加密,或解除设备引导加载程序的阻塞。
  • 破坏TEE内核的第二种方法只需要访问易受攻击的TA的接口
    使用E4,攻击者可以劫持Widevine TA,这是一种针对Android操作系统的DRM服务。
    然后,通过系统调用接口的漏洞,攻击者可以进一步将权限提升到TEE内核(E5)。

表1

  • 表注:
    • E1(2015): 输入验证 的缺陷可以作为 zero-write(零写)原语在内存QSEOS的虚拟内存的任何位置使用,以获得可信操作系统中的任意代码执行。在Linux内核中需要root特权。(下面的图2中有QSEOS的位置:存在于S-EL1处,估计是运行Linux内核的地方。)
      • 组件:SW Monitor; 影响:Full control of TZ kernel
    • E2(2015):利用TrustZone Linux 驱动程序 中的bug,该bug允许攻击者获得根权限,从而 启动E1攻击
      • 组件:NW Driver; 影响:Full control of Linux kernel
    • E3(2016):Android的 Mediaserver进程 的漏洞,允许一个没有特权的REE应用程序访问Qualcomm的TrustZone接口驱动程序。当 与E1和E2一起使用 时,允许
      非特权应用程序 获得可信的操作系统级的任意执行。
      • 组件:NW Service; 影响:Full control of Android Mediaserver
    • E4(2016):在 TA上下文 中获得任意执行的特权升级攻击。该漏洞发生在 Widevine TA 中,可以通过 使用E3 访问TrustZone接口Linux驱动程序来利用。
      • 组件:SW TA; 影响:Full control of Widevine TA
    • E5(2016):Qualcomm的可信操作系统调用缺乏输入验证,这使得TA可以向操作系统内的任何地址写入数据,并劫持TEE内核。需要通过TA的接口将特权升级到TA。
      • 组件:SW Kernel; 影响:Full control of TZ kernel
    • E6(2016):具有TA级执行特权的攻击者可以获得对Linux内核的控制权。这种攻击可以建立在E4之上
      • 组件:NW Kernel; 影响:Full control of Linux kernel

REE核的妥协:
让Linux妥协,甚至不需要控制TEE内核。只需取一易受攻击的TA,将其作为提升特权到Linux内核的跳台即可。
例如,exploit E6允许攻击者接管Linux内核,将精心设计的输入由用户级NW应用程序发送到Widevine TA。
这个TA的漏洞连同QSEE的系统调用,允许TA映射到NW物理内存中去,使攻击者能够修改分配给Linux内核的内存区域并控制系统。

问题的严重程度
几个其他的漏洞(exploits)已经被Qualcomm TEE研制了。
除了运输Qualcomm芯片的移动设备外,其他平台也受到了攻击,即运行Trustonic的TEE系统的设备,该系统由Mobicore改名为Kinibi,而华为专属的TEE被命名为Trusted Core。
这些漏洞大多采用表1(Table I)所示的分治策略。
考虑到Trustonic的TEE预计将在17亿部设备(主要是三星)上运行,而华为的移动设备被广泛采用(2018年售出2亿部),TEE缺陷可能在全球范围内产生巨大影响

  • 自此,类似的方法已经被成功地用于攻击其他流行的TEE系统。

III. OVERVIEW

1. 研究方法

对手模型
考虑一个攻击者追求下面的一个或多个目标:

  • a)从TEE中获得秘密;
  • b)从REE中获取秘密;
  • c)升级权限到REE内核;
  • d)升级权限到TEE。

攻击者只能从NW出发,以两种方式访问SMC接口:

  • 直接通过在管理器模式(N-EL1)中获得代码执行特权,允许生成任意的SMC调用;
  • 通过向某个目标TA发出命令,间接从无特权的用户级应用程序(N-EL0)中获得代码执行特权。

所有的NW部件都被认为是不可信的

分析TEE系统(对Qualcomm、Trustonic、Huawei、Nvidia和Linaro的TEE系统分析)
Nvidia维护着一个专有TEE,它主要用于Nvidia芯片。
Linaro维护着OP-TEE,这是一个开源TEE软件,在TrustZone开发中非常流行。
所有这些系统都被积极地维护,被广泛地用于商业目的,并且可以获得大量关于它们的信息。
排除研究原型或目前没有大规模部署的商业产品,考虑相关整合的漏洞,例如,硬件侧通道。
为便于阅读,此后将使用公司名称而非软件名称来指代每一个被分析的TEE(如QSEE代指Qualcomm TEE)。

数据来源
使用多个来源,并将其分为四个领域(见表2(Table II))。
表2

公开安全漏洞分类
收集漏洞报告后,手动分类分析。
对于具有CVSS评分的漏洞,采用基于属性评分的分类度量。
评级系统包括四个类别:危急、严重、中级、低级。
类别
特定漏洞的严重程度可能具有不同的安全含义。关键漏洞通常会导致TEE、REE或两者的机密性或完整性的完全泄露。

二元分析
为了获得TEE系统更多细节,本文对其中的一个子集进行逆向工程
该方法允许我们量化每个系统TCB的大小;其次,它帮助确定了每个系统的具体软件架构,例:Huawei使用Arm可信固件(ATF)作为其安全监控软件的基础,而Qualcomm使用自己的实现;再者,它允许我们分析每个TEE实现的内存保护功能

有效性的威胁
缺乏关于专有系统中存在的漏洞的信息可能导致不准确的分类,给定的TEE系统也有过度代表的风险(过拟合)
特别地,公开报告的关于该系统的漏洞的数量很大程度上超过了其他系统的数量。
本文只分析了以前报告过的漏洞。故可能存在的未知类型漏洞,可能会揭示TEE系统其他的基本安全问题。

2. 观察总结
表3

  • 表3(Table IIl)根据系统的严重程度量化了与每个系统相关的已披露漏洞的数量。几乎一半的错误报告被评为危急级或严重级。
  • 特别地,124份报告中有53份(42%)披露的安全漏洞被认为是危急级。
  • 每个TEE至少有一个非低级漏洞:
    • Trustonic有1个危急级漏洞;
    • Huawei有2个严重级漏洞;
    • Nvidia有5个严重级漏洞。
  • 由于这些系统被广泛部署,所以全世界有数百万用户可能已经受到这些漏洞的严重影响。
  • 注意:尽管Qualcomm TEE漏洞数占比最大(74%),我们也仍旧不能说它是最不安全的TEE或者比较个别的TEE。毕竟CVE报告过程的方法不一致,得出上述结果可能只是由于Qualcomm开发者和用户报告的更多。
  • 但这些结果是有用的。因为它们允许我们建立此类系统漏洞的下限,对总体趋势进行推理,并将一般TEE趋势与其他类型系统的趋势进行比较。

3. TrustZone-assisted TEEs的漏洞来源

  • 三个主要来源: 架构、实现和硬件。
  • 架构问题包括整个TEE系统架构的缺陷,例如使用ASLR缺乏内存保护。
  • 实现问题对应于TEE系统软件中的缺陷,例如缓冲区溢出。
  • 硬件问题涉及硬件行为可能被滥用以破坏TEE的安全性,例如,旁通道。
  • 很多漏洞与表I中描述的攻击所利用的漏洞具有相似的性质。作者确定了其他可以进一步利用的漏洞类型,例如并发性漏洞。
  • 在TrustZone-enabled的SoCs中,硬件问题非常普遍,并且可能在未来被用来发动具有高度破坏性的攻击。

在下一节中,本文将通过讨论每种类型的问题详细介绍各漏洞。

Ⅳ. ARCHITECTURAL ISSUES

本节是从现存TEE系统的架构层面来分析漏洞的(本节介绍了9个),并附上了Qualcomm,Trustonic,Huawei,Nvidia,Linaro的系统具体细节图,如下:
图2

  • 图注:TEE系统的详细架构。其中,一些相关的共同特征包括:
    • (a) NW应用程序和SW之间的通信是由一个特权操作系统守护进程进行中介的,该守护进程使用TrustZone驱动程序向SW发出SMC调用;
    • (b)在四种情况下,监视器是基于ATF的,它由Arm提供的安全引导装载器和监视器软件的reference
      implementation(参考实现)组成。
      • (ATF就是个可信固件,是对安全世界软件的一个参考实现,包括(EL3中的)安全监视器。它为在AArch32或AArch64执行状态下的安全世界引导和运行时固件产品化提供了一个合适的起点)
      • (ATF其他资料:Arm Trusted Firmware用于在SW和NW之间切换)
      • ARMv8的两种执行状态: AArch64/AArch32

1. TEE攻击面
从TEE系统暴露出来的宽泛的攻击面来研究潜在漏洞。

I01. SW的驱动程序运行在了TEE内核中:

  • 通常,TEE系统需要SW中存有的驱动程序,来协调它对安全敏感设备的访问,例如:用于用户身份验证的指纹传感器,或用于DRM所保护内容的安全输出的显示帧缓冲区。
  • 驱动程序往往很复杂,且是bug的传统来源,故作者认为它们不应该在TEE内核空间中运行(像在S-EL1模式中)。
  • 从图2中可以看出,Trustonic和Nvidia采用了微内核架构,驱动程序运行在SW的用户空间(S-EL0)中,遵循了这种方法。
  • 相对地,Qualcomm、Huawei和Linaro在S-ELI模式下运行TEE驱动器。
    • Qualcomm和Linaro都采用了一个单片(集成)架构,所有特权代码都在内核空间运行。××
    • Huawei将一些可信操作系统功能委托给用户空间,即控制TAs生命周期的工作,并将其分配给一个名为GlobalTask的特权TA(见图2)。×

I02. TEE系统子组件之间宽泛的接口

  • 对于TEE系统来说,这些接口已经变得大得令人担忧。
  • 在Android操作系统中,至少有四个守护进程拥有对TrustZone驱动程序的特权访问权!
  • TEE内核公开的SMC调用接口使NW软件可以访问大量的TAs。(Trustonic TEE依赖32个不同的TAs)
  • TAs处理的命令集也往往相当大。(Widevine TA实现了70个不同的命令,其中很多操纵着复杂的媒体数据结构)
  • TEE内核向TAs暴露了大量的系统调用:(在Qualcomm的TEE中有69个系统调用)
  • 对TEE系统调用的访问权限通常是粗粒度的:(在Qualcomm TEE中,TAs对所有系统调用的访问是杂乱的)
  • 在某些情况下,由安全驱动程序提供的接口可以扩展得非常大:(在Trustonic TEE中,能对指纹设备驱动程序控制访问的TAs,实际上可以访问部署在TA中的每一个TA)

I03. TEE有过大的TCB

  • 基于TEE系统的部分设计哲学是:它应该依赖于一个较小的TCB
  • 为了验证这一原则,本文根据它们的固件和它们的源代码分析了它们的TCB大小。
  • TAs实现了安全敏感的REE函数,TCB中同时包含了trusted OS和TAs。
  • 表IV给出了本文与一些参考操作系统的比较结果,发现:
    • TEE系统的TCBs是大量的,例:在Qualcomm TEE中达到1.6 MB。
    • 注:这些数字是保守的,毕竟固件包中不包括可以动态加载的额外TAs。
    • 一些TAs有其相当大的规模。有了这样的规模,就不能保证这些可信应用(TA)真的可信(因为TA通过SMCs接受来自NW的输入,潜在的漏洞很容易被利用)。
    • 从TCB大小的角度来看,尽管现有的TEE内核都明显比Linux内核小(大约三个数量级),但它们中的大多数都要比与其同复杂度的微内核(seL4)大得多。
    • 图4
  • 图注:研究的各TEE系统与参考操作系统的TCB大小(分别在中线上方和下方):数值来自TEE二进制文件和固件/系统映像文件系统中可加载的TAs。对于开源系统,软件的编译支持优化,使用SLOCCount计算代码行数

2. 正常与安全环境之间的隔离漏洞
在一些TEE系统中,SW和NW之间的隔离机制会因为TEE内核的危险系统调用而被破坏。

I04. 从TAs具有的映射功能上讨论

  • 某些应用程序,例如DRM保护的视频渲染,需要一个高效的共享内存机制,允许跨世界以低延迟交换大量数据。(这就是可能的漏洞)
    • 关于DRM:目的是保护数字媒体的版权,从技术上防止数字媒体的非法复制,或者在一定程度上使复制很困难,最终用户必须得到授权后才能使用数字媒体。
  • 一些TEE系统提供了很容易被用于特权升级的机制。(更明显的漏洞)例:
    • Qualcomm TEE公开了一个可信操作系统调用,允许任何TA映射任何属于NW的物理内存,包括到REE操作系统内核。(可能是为了方便回忆?NW中文件丢失可从SW中加载?若真如此,那只能说明高通在平衡易用性和安全性之间,偏重了易用而放弃了一部分安全)
      • 通过破坏TA,攻击者可以自动接管Android操作系统,扫描Linux内核的物理地址空间,并通过补丁引入后门 (见表I中的E6)。
    • Trustonic TEE阻止TAs映射和修改物理内存。
      • 这个操作仅限于特定的驱动TAs。
      • 即:TAs若想通过共享内存交换数据卷,必须向一个专用驱动TA发出一个请求。
      • (这个例子可能想说明Trustonic这方面看起来做的不错)
    • Samsung使用这种方法来分割基于TrustZone的完整性度量架构(TIMA)的功能。
      • 一个TA驱动程序提供映射物理内存的能力,
      • 另一个TA使用这种服务来度量系统映像的完整性。
      • 白名单是用来防止任意TA访问TA驱动程序的。(目前看起来不错)
      • 但白名单在TA驱动程序中是硬编码的,允许TA的数量相当大(达到34),即通过破坏这些TAs,攻击者可以自由地劫持Android。(这个问题估计Trustonic和Samsung都会面临的)

I05. 从危险的调试通道上讨论

  • 通过TEE调试机制从SW向NW方向泄漏信息,这个特性促进了表I中描述的一些漏洞。
    • 特权升级攻击利用了Huawei TEE的系统调用,它允许TA应用程序将其堆栈跟踪转储到NW的内存区域。使用这种机制,攻击者可以了解GlobalTask的物理地址空间,并使用这些信息来策划攻击。
    • (上面I01中有提到Huawei将一些可信操作系统功能委托给用户空间,即控制TAs生命周期的工作,并将其分配给一个名为GlobalTask的特权TA。所以这一部分被攻击的话,它就非常不安全了。)
  • 暴露在NW上的调试日志在Trustonic TEE中也很常见,这可能会泄露关于TAs内部的敏感信息。

3. 内存保护机制
内存保护机制的设计并不好。表V总结了各TEE系统实现的机制的发现。(下面重点提了两个漏洞)(我认为这是在从软件层面讲防御)

I06. 要么缺乏ASLR,要么ASLR实现的不好

  • (注)ALSR地址空间配置随机加载利用随机方式配置数据地址空间,使某些敏感数据(例如操作系统内核)配置到一个恶意程序无法事先获知的地址,令攻击者难以进行攻击,是一种防范内存损坏漏洞被利用的计算机安全技术。
  • 在可信TEE中, TAs都被加载到虚拟地址空间的相同固定地址中(0x1000)。每个TA都有一个公共库,它为每个TA都映射到一个常量地址(0x7D01000)。即,(对攻击者来说)在TA中发现的任何漏洞都可以被利用,而不需要再花精力去确定TA的加载地址。
  • Trustonic TEE,一个被叫做mcLib的公共库(参见图2)包含大量代码,这些代码可以提供小工具的源代码来调用函数、调用可信OS系统的调用等。
  • HuaweiNvidiaLinaro TEEs 都没有ASLR机制。
  • Qualcomm TEE为所有TAs提供了ASLR的一种形式
    • 但只使用TA代码加载到其中的一小段物理内存。
    • 所有的TAs都被加载到一个持续分配物理内存的相对较小的区域中,这个区域的大小大约为100MB。即,ASLR提供的熵值受到该区域大小的限制。
    • 因此,虽然理论上可以通过使用64位虚拟地址空间来实现高熵ASLR,但Qualcomm TEE实现的ASLR大约被限制为9位,这大大减少了攻击者猜测TA的基址所需的猜测次数。
  • 所研究的TEE系统中没有一个具有KASLR,即TEE内核的ASLR。

I07. 没有stack cookiesguard pages或者execution protection

  • 除了ASLR,现代操作系统还采用了额外的内存保护机制。
    • stack cookies (SC)是帮助检测堆栈破坏实例中止程序执行的唯一值。
    • guard pages(GP)将每个进程中的可变数据段(即堆栈、堆和全局数据)分隔开,以防止攻击者在非法访问时使用一个段的溢出来触发错误,从而破坏另一个段。
    • execution protection(XP)防止程序在某些内存区域内执行,可以通过各种方法实现。
      • 在Arm上,SCTLR寄存器中的WXN位可以用于隐式标记为永不执行(XN)的可写内存区域。
      • 另一种选择是使用内存页属性XNUnprivileged XN (无特权的XN,UXN)和Privileged (有特权的XN,PXN)。
  • 但TEE系统仅部分实现了这些机制(见表V)。在这里插入图片描述

表注:用户和管理员模式的内存保护机制。
●:完全执行;
◐和◯:部分执行或未执行;
-:没有找到与执行相关的信息。

    • Trustonic TEE缺乏stack cookies,脆弱的TAs易堆栈溢出。
      • 它从TA的数据段中分配全局变量和堆栈,而不提供中间的guard pages。
      • 该内存布局将堆栈放置在数据段的末尾,并在其之前放置全局变量,这是一个区域溢出到另一个区域的完美配置。(高级黑🤣)
    • Qualcomm TEE实现了随机指针大小的stack cookies,但是它没有在全局、堆和堆栈之间提供guard pages。
    • Huawei TEE没有stack canaries,没有data execution protection,也没有write-protected .text部分
      • 这可能是因为Huawei TEE是基于Micrium μ/OS的,这是一种RTOS,它将上述的大多数内存保护机制放在了另一种位置,以提供最大的性能。
      • (即,可能是用了最少的内存机制来换取最优的性能)

4. 可信引导指令
在TrustZone-enabled的TEE平台上,破坏客户端应用程序(本地或远程)的可信引导过程。

I08. 缺乏与软件无关的TEE完整性报告

  • 安全引导程序确保在设备上运行的软件的真实性。
  • 图3演示了一个可能的安全引导过程,包括TAs的引导。在这里插入图片描述

图注:安全引导进程:实现信任链。
首先执行存储在on-SoC ROM中的可信组件(可信板引导);
然后每个加载的组件验证后续模块(或多个模块)的真实性和完整性,如果没有检测到异常,则加载。
供应商用其私钥对SW映像进行数字签名,同时将各自的公钥(或摘要)刻录或存入一次性可编程存储器(通常是eFuses)。
公钥用于验证二进制文件没有被修改,它是由供应商提供的。

  • 但Arm TrustZone缺乏向远程第三方安全地报告软件完整性测量结果的硬件机制。故远程认证需要通过一个TEE组件在软件中实现。这削弱了远程认证的安全性,因为它要求的信任链上所有软件以EL3模式运行。

I09. 支持Ill的TA撤销

  • Android OEMs处理TA撤销的方式存在问题。
  • 为防止修补TAs被降级,TA撤销是必要的。
  • 更新授权漏洞和其他错误得到纠正,提高了设备的整体安全性。
  • 为了使它们更容易更新,TAs通常从REE文件系统中加载,并且为了证明它们的真实性,它们是经过数字签名的。
  • 但TEE必须撤销旧的TAs,以防止REE中的攻击者故意加载旧的已知易受攻击的TA,并利用它在TEE中获得代码执行。
  • Widevine TA的成功降级为先前的、已知易受攻击的版本,Qualcomm和Trustonic TEE均已被发现。

Ⅴ. IMPLEMENTATION ISSUES

除了架构弱点之外,许多TEE漏洞是由实现错误引起的。
主要来源包括从公共CVE数据库和供应商公告报告中检索到的错误报告。
表VI列出了所有分析过的bug分类。
在这里插入图片描述显然,也发现9个漏洞,下面就顺着表中的顺序来。

1. 验证漏洞
在TEE系统中,涉及对输入和/或输出值的不当处理,我们将其称为验证错误。例:缓冲区溢出、不正确的参数验证、处理不当的整数溢出等。
它们常被用作特权升级的入口点,在现有TEE系统的所有主要组件中都可以找到此类错误。

I10. 安全监视器

  • 通过利用安全监视器中的验证漏洞,攻击者可以自动获得对设备的完全控制。例:
    • 通过利用E1来劫持Qualcomm TEE内核(见表I)所滥用的漏洞,允许攻击者通过在SMC调用中构造输入,在SW内存的任何地方写入一个零双字。
    • 除了Qualcomm TEE,大多数TEE系统使用Arm的参考监视器(ATF)(参见图2)。(稍微强点儿)
  • 但严重的验证错误(critical bugs)已经被ATF内部报告了。具有讽刺意味的是,一个bug位于一个C的宏上,它的目标是帮助检测算术溢出(CVE-2017-9607)。
    • 如listing 1所示,任何依赖于此宏检测整数溢出的AArch32代码都不受保护。即,使用此宏的多个监视器入口点都不安全。 listing 1

注:ATF宏的漏洞
位于头文件include/lib/utils_def .h中,这个宏的目的是在计算基指针和偏移量的总和时检测算法溢出。
但是,如果输入的基指针和偏移量的总和缠绕在一起,可能会发生不可预知的行为。
在AArch32图像中,当两个参数的和落在 ( 2 32 , 2 64 − 1 ) (2^{32},2^{64}-1) (232,2641)范围内时,它将无法检测到溢出。

I11. TAs

  • 通过SMC接口,TAs大多受到来自NW的攻击。报告中此验证错误占比最大。例:
    • ESECOMM trustlet中的关键漏洞可以用来危害Samsung Pay等客户端应用程序。
      • The ESECOMM Trustlet has a NULL pointer dereference.(CVE-2019-20603)
      • A NULL pointer dereference occurs when the application dereferences a pointer that it expects to be valid, but is NULL, typically causing a crash or exit.
    • 在Trustonic TEE中,可以使用相应的bug修复程序,系统地利用验证bug。
    • 一些TA验证错误(例如CVE-2016 - 5349),可以直接通过boomerang攻击特权升级到Linux内核,脆弱的TA不会正确地验证输入内存地址,会允许攻击者访问NW内存区域和读写那些被分配给REE应用程序(REE apps)或操作系统(OS)的内存。

I12. 可信内核

  • 通过劫持TA,攻击者可以利用TEE内核系统调用接口中的漏洞,提高其特权。例:
    • 攻击Huawei TEE依赖脆弱的系统调用,它的输入是完全放任绕过可信内核内的安全检查(见listing 2)。listing 2

图注:从 Huawei TEE (RTOSck) 逆向工程系统调用,没有任何输入检查。攻击者可以覆盖NW或SW的任何地方的内存。

    • 更甚,Qualcomm TEE内核没有任何代码来验证提供的输入指针,这意味着所有的系统调用都是脆弱的。

I13. 安全引导加载程序

  • 系统引导过程中的验证错误。
  • 在CVE-2017-7932中有一个例子,此漏洞是由于X.509证书解析器中基于堆栈的缓冲区溢出造成的,这允许攻击者在图像验证期间潜在地安装或加载伪造的X.509证书。故合法的TEE软件映像可以被替换,实现任意代码的执行。

2. 功能缺陷
主要指由编程错误引起的,是由于实现与程序员所期望的程序规范之间的不一致(例如,密码算法的错误编程)。

I14. 内存保护

  • 在TEE系统的内存保护机制中引入安全漏洞。例:
    • 报告的ATF漏洞涉及到内存转换表的配置错误,该配置错误允许只读内存区域总是在S-EL1的上下文中可执行。
    • 在OP-TEE(Linaro TEE的OS)中,发现了15个导致内存保护漏洞的bug报告。例:负责保存和恢复ARMv7的FIQ寄存器的安全监视器代码中的一个错误,可能会允许REE升级权限,以获得TEE中的代码执行权。

I15. 外设配置

  • 在Qualcomm TEE中,CVE-2016-10423披露的一个缺陷允许TA读取先前由另一个TA打开的SPI接口上的数据,这是由于SPI总线的非排他访问
  • 在OP-TEE中,一个补丁旨在修复伪随机数生成器的错误配置,该错误配置导致OP-TEE中使用的加密库的熵源不足。

I16. 安全机制

  • 安全协议或加密原语实现中的错误。
  • 在ATF中,由于身份验证检查的缺陷,攻击者可以绕过Amlogic S905 SoC安全引导进程,其中只检查了引导映像的完整性,而不检查签名。例:
    • 在OP-TEE中,LibTomCrypt中的Bellcore攻击漏洞可能会危及RSA私钥(CVE-2017-1000412),以及RPMB的硬编码安全密钥导致密钥泄露(2017年1月23日修复)。
    • (Bellcore攻击:硬件错误可以使得签名模易分解。)

3. 外部因素
指代编程缺陷,这些缺陷与值的验证或代码的功能正确性无关,而是与外部因素的正确处理有关。

I17. 并发问题

  • 由多个并发程序的干扰引起的,它们的表现取决于程序本身之外的因素(例如线程交错),故是外在的。一些安全漏洞,例:
    • 在OP-TEE中,由于不同的TA并发访问文件系统,而导致的一个bug允许TA在另一个TA创建目录时删除可信存储上的目录。(就并发的实现错乱了呗)
    • Samsung报告了Trustonic TEE中部署的TIMA驱动程序中的两个竞态漏洞(SVE-2017-8974和SVE-2017-8975),可能会导致TOCTOU漏洞:(软件在使用资源之前检查资源的状态,但是资源的状态可以在检查和使用之间改变,以一种使检查结果无效的方式。这可能导致软件在资源处于意外状态时执行无效操作)。。
    • Nvidia TEE的DRM TA中报告了一个TOCTOU漏洞,可能导致权限升级(CVE-2017-6296)。

I18. 软件边信道

  • 这由特定的实现工件引起的,这些工件与程序逻辑无关,但可以根据程序执行时间揭示不需要的信息。例:
    • OP-TEE的可信内核使用的加密库LibTomCrypt中发现了一个定时边信道(CVE-2017…1000413)。此漏洞是在对模块化求幂进行优化时造成的,它泄露了有关指数的信息。它是通过保证常数时间的取幂来固定的。

Ⅵ. HARDWARE ISSUES

TEE也依赖于可信硬件组件的正确性。
图4提供了TrustZone-assisted的TEE系统的典型硬件架构概述,并显示了这些组件如何通过AXI总线连接。
图4

图注:TrustZone-assisted TEE系统的硬件架构,包括FPGAs中提供的可编程逻辑。
完全阴影框表示专门分配给运行在SW. SPI/UART中的TEE软件的可信组件,允许其与off-SoC外设通信(例如,用于生物特征认证或智能卡交互)。
部分彩色的盒子代表部分或完全局限于SW的组件,如DRAM和存储(例如,为TAs提供安全存储)。

由于硬件组件是TEE的TCB的一部分,TEE开发人员必须正确配置并与这些组件进行接口,同时还要仔细考虑微体系结构的所有含义。

1. 架构影响
TEE开发人员必须很好地了解所有架构硬件组件(如FPGAs),以及SoC边界内外的所有架构细节。

I19. 可重构硬件组件攻击

  • 可重构平台,即FPGA SoCs,将传统CPU架构与可编程硬件逻辑相结合。
  • OP-TEE在其主线上支持Xilinx Zynq-7000和Zyng UltraScale+平台,然而新硬件的添加增加了攻击面。
  • FPGA SoCs内的可配置硬件通常连接到主总线。这意味着硬件必须阻止对内存区域的访问,这些内存区域是由运行在主CPU上的软件管理的。
  • 在TrustZone-enabled的系统上,AMBA AXI接口包括一个额外的控制位(NS位),用于主系统互连上的读(ARPROT)和写(AWPROT)通道。这使得所有硬件组件都可以知道CPU的安全状态。
  • 一些攻击利用可重构的硬件逻辑来破坏基于TrustZone的系统的安全性。
    • 利用部署在FPGA上的恶意硬件来破坏安全引导进程。
    • 在一项关于NS位传播到FPGA的研究中,通过对硬件逻辑的恶意修改,揭露了六种不同的攻击。

I20. 能量管理机制攻击

  • CLKSCREW通过恶意使用内核驱动程序来推动频率和电压调节器,使其超出供应商建议的限制,直到导致错误的计算。
  • 通过影响软件操作的计算,有可能打破TrustZone硬件强制的边界,以提取秘密密钥并绕过代码签名操作。

2. 微架构边信道
除了架构级的细节,TEE的安全性也依赖于微架构的细节(例如,缓存)。
在这里插入图片描述

I21. 缓存泄露

  • 在TrustZone-enabled处理器上,缓存内存是安全世界和正常世界之间共享的。
  • 虽然安全的高速缓存线不能被NW访问,但当竞争使用高速缓存线时,两个世界都被保证平等的权利。
  • 这种高速缓存一致性设计,以两个世界之间的高速缓存争夺为代价,提高了系统性能。即利用监测NW的高速缓存来提取SW信息的主要来源。
  • R. Guanciale等人实现了一个低噪声高速缓存存储通道,该通道可以成功地从AES加密服务中提取128位密钥。
  • ARMageddon使用质数+探测技术来推断SW上的活动,并区分提供的密钥是否有效。
  • TruSpy利用Prime+Probe以两种不同的方式恢复完整的128位AES加密密钥。
  • Prime+Count还用于授权TrustZone上的跨世界隐蔽通道。

I22. 分支预测器泄露

  • 现代处理器包括一个分支目标缓冲区(BTB)单元,它存储已获取的分支指令的计算目标地址,并在预测到相应的分支指令时获取它们。
  • 因为BTB在NW和SW之间共享, Prime+Probe可以执行向NW泄漏安全信息。
    • 该过程包括通过执行多个分支启动BTB,然后让受害者进程执行,从而驱逐攻击者的BTB条目。
    • 当攻击者获得执行控制时,攻击者会重新执行这些分支来检测错误预测。
    • 鉴于BTB的内部硬件结构以字节粒度而不是缓存行粒度工作,这种特殊的攻击向量大大提高了探测机制的空间分辨率。
    • 256位的私钥已经从Qualcomm的硬件支持密钥库中完全恢复。

I23. 使用Rowhammer诱导

  • Rowhammer是一种软件诱导的硬件故障,它影响DRAM内存,使攻击者能够通过单独执行内存读取操作来翻转物理内存中的位,可被用来破坏TrustZone。
    • 恶意的Linux内核模块使用Rowhammer对特定的NW目标地址产生错误,而运行在可信的TEE实例上的安全签名服务使用安全的RSA私钥对特定消息进行签名。
    • 如果私钥分配在安全内存区域邻近安全/非安全内存边界,在不安全内存边界上由高速内存读取操作产生的Rowhammer,在安全内存上诱发错误,破坏私钥并产生错误的RSA签名。
    • 在Linux端检索错误生成的签名后,就可以推断出私钥。
    • 在讨论的微架构问题中,这种攻击更难进行,因为它通常需要对环境进行更高程度的控制;另外,减轻它也相对容易。(那这个发现就不怎么重要)

VII. DEFENSES FOR TRUSTZONE-ASSISTED TEES

防御技术的汇编。
表VIII列举了从2014年到2019年有代表性的论文的例子。
实心圆指,该论文实现了至少一种防御技术,可以帮助解决在相应列的标题中指出的问题。
表8

表注:

  • 对于架构问题:攻击面世界隔离内存保护可信引导程序

    • 解决:D01、D02、D03、D04
  • 对于实现问题:验证错误

    • 解决:D05、D06、D07;
      功能错误
    • 解决:D07;
      外部因素
    • 解决:D06、D07。
  • 对于硬件问题:架构微架构的边信道

    • 解决:D08、D09

1. 架构
四种相关技术可缓解现有商业TrustZone-assisted TEEs的架构问题。(针对第4节)

D01. 多隔离的环境

  • 该技术可用于减少商业TEE 系统过大的攻击面(见I01、I02和I03)。
  • 多个孤立的环境(除了SW中的标准TA沙箱之外)有助于减少TEE系统受到的攻击,通过这几点:
    • (a)增加TEE组件之间的隔离粒度。这样就控制了因安全漏洞而造成的潜在损害的程度,
    • (b)限制在SW中运行的代码数量,从而减少具有高度破坏性的SW特权升级攻击的机会。
  • 方向1:在NW建立高度孤立的分区,以便分配TAs。为了保护TAs,
    • TrustICE 和 SANCTUARY(下篇论文将提到)利用TZASC OSP的不同特性;
    • PrivateZone和vTZ则相反,探索NW (NS-EL2)中可用的硬件虚拟化扩展来实现孤立的环境。
  • 方向2:在SW中保留TAs,但旨在加强它们之间的隔离,例:
    • TEEv和PrOS在SW中实现了一个极简管理程序,允许TAs在多个隔离的安全客户操作系统上运行。由于目前在SW中缺乏硬件虚拟化支持,这两个系统都使用了相同特权的隔离,来保护管理程序不受安全客户操作系统的影响。

D02. 安全的跨环境通道

  • 世界之间的隔离可能会受到来自NW的SW漏洞的威胁(见104和105),可能导致从SW提取敏感数据。
  • 尽管这些特定的问题可以通过修复脆弱的TEE内核系统调用来解决,但是可以通过安全的NW-SW通道来进一步加强跨世界隔离。这些机制有助于克服主流TEE中存在的两个限制:
    • (1)在从NW访问TEE资源时缺乏或弱认证;
    • (2)在通道内进行数据交换时存在潜在的不安全共享内存。
  • SeCReT提供一个会话密钥(给REE应用程序),可以用来加密消息。为了保护会话密钥不受不可信REE内核的影响,SeCReT将模式切换到内核,并在内核模式执行期间从内存中删除密钥。
  • TFence通过创建一个部分特权的进程进一步消除了这种内核依赖关系——这是REE应用进程的屏蔽部分,可以直接与TEE通信。
  • TEEv和SANCTUARY都实现了独占共享内存;
  • 而PrivateZone可以在不共享内存的情况下通信,即通过数据拷贝。
  • Aravind等人使用指针消毒防止回旋镖攻击。

D03. 加密内存

  • TEE内存保护(106和107)存在的缺陷可以通过主流操作系统(如ASLR、stack cookies)的机制来解决。
  • 但商业TEE可以提供更强的安全防御,例:
    • 通过实现加密内存能力,防止冷启动攻击。
  • 与Intel SGX不同,TrustZone不提供内置的对片上存储器加密的支持。为了弥补这个差距,
    • CaSE允许TAs完全从缓存运行,并确保它们的状态在写回主存时被加密。
    • Ginseng通过在CPU寄存器上分配变量并在运行时对它们进行加密,然后将它们保存在内存中,以此来保护被应用程序程序员标记为“敏感”的变量。

D04. 可信计算原语

  • 商业TEE依赖安全引导来保证TEE图像完整性,但这种机制本身并不足以使TA的客户端(本地或远程)验证TEE以及TA二进制文件的完整性和身份(见108、109)。
  • 为了克服这个限制,商业TEE可以实现额外的可信计算原语来帮助提供这样的保证,即远程认证和密封存储。例:
    • TLR包含一个密封的存储原语,允许以加密方式保护数据,并将其绑定到TEE/TA软件堆栈的特定哈希值。
    • Komodo演示了如何为TrustZone-assisted TEEs设备实现密封存储和远程认证的安全协议,这些协议最初是为enclaves(即Intel SGX的TAs安全环境)指定的。
  • 在可信I/O路径原语中还有一项工作,旨在提供对外设的安全访问。
  • 由于我们识别了涉及外设访问的相对较少的漏洞,可以使用I/O中介的标准硬件特性(例如SMMU, 总线桥)来缓解这些漏洞,所以Table VIIl省略了这些引用。

2. 实现
三种主要技术可用于提高TEE组件和TAs的实现正确性。(针对第五节)

D05. 托管代码运行

  • 商业的TEE系统大多是用C编程语言编写的,它允许编译高效的代码,但不提供内存安全,而许多验证错误是由程序员引入的内存冲突错误引起的。例:
    • TLR, TAs不是被编译成本机代码,而是被编译成.Net托管代码,然后由小型托管代码编译器(类似于JVM)解释执行。以一些性能开销为代价,托管运行编译器有助于防止验证错误,例如,通过实现运行编译器内存检查和垃圾收集。

D06. 类型安全的编程语言

  • Rust zone是OP-TEE的扩展,其中TAs是用Rust编程语言实现的。
  • 既然Rust提供了内存和线程安全,那么Rust zone可以帮助防止验证bug和一些导致TA软件瘫痪的并发bug(见I11)。
  • 在Ginseng中,Rust编程语言也被用于实现在监控模式下运行的大部分软件,即GService(见I10)。

D07. 软件验证

  • 由于软件的预期需求与其实际实现之间的不匹配,实现错误往往会存在。
  • 软件验证,包括模型检查、符号执行和形式化方法等技术,旨在通过确保实现完全满足所有预想的需求来防止这种不匹配,所以它有可能帮助防止所有三类流行的TEE实现错误。
  • 但在实践中应用这些技术是具有挑战性的,不仅因为它们需要相当多的努力和技能,还因为它们难以针对复杂的程序进行扩展。
  • 尽管存在这些障碍,但特定TEE组件的正式验证已经取得了重要进展,例如,名为Komodo的小型TEE监视器,它实现了Intel SGX enclaves的规范,以及名为MIPE的内存管理器。

3. 硬件

D08. 架构策略

  • 硬件制造商倾向于在SoC芯片中封装更多的组件,这使得TEE设计人员很难完全理解其对TEE系统安全性的影响。为了防止滥用可重构硬件技术(见I19),研究人员提出:
    • (1)在所有具有AXI接口的IP核中加入一个小的硬件包装,限制其在系统启动期间的操作;
    • (2)安全设备专用AXI互连的实现;
    • (3)包含一个非安全的端口,用于连接所有不敏感的内存映射IP核,并通过内存保护机制(如SMMU)限制其操作。
  • 为了防止硬件稳压器的误用(见I20),一种可能的方法是在软件(即驱动程序)或硬件本身中设置特定的操作限制。

D09. 微架构策略

  • 一种防止缓存边信道(见I21)是通过仔细实现密码算法的软件或使用专用硬件(例:特定的ISA指令,像AESD和AESE Armv8-A) ,去防止在密码相关操作中的信息泄露。
  • 另一种方法是利用缓存维护技术来防止通过缓存泄漏信息。
  • 对于不使用共享L2缓存的TrustZone-assisted TEEs ,一种方法是在每个SW出口刷新L1缓存。
    • 如果使用共享L2缓存,尽管在每个SW入口和出口执行缓存刷新(全部或选择性)或缓存归一化操作可能足以防止缓存存储攻击,但L1刷新可能无法防止多核系统中的Prime+Probe攻击。
    • 在这种情况下(也适用于所有上述情况),缓存分区可以防止攻击者利用与受害者的争用。
  • 小心执行的加密算法似乎也能有效防止通过BTB的入侵(见I22)。Keegan等人展示并强调了这一点,其中不同版本的算法能够使边信道无效。为了防止Rowhammer攻击(见I23),TEEs 必须避免在 NW-SW边界使用内存。

VIII. BEYOND TRUSTZONE-ASSISTED TEES

一些相关技术
表IX中强调了它们的主要特性。
表9

表注:

  • Dedicated RAM:用于分配安全敏感状态,并与潜在不安全的主内存隔离。
  • Cross-world isolation:使用内存管理组件(MMU / PMP)或与HW特定特性(例:TrustZone TZASC);专用的off-SoC芯片通过物理隔离实现隔离。
  • Encrypted memory:表示支持硬件强制内存加密。
  • Protection Ring:分为五个级别,即1 (user), 0 (kernel), -1 (hypervisor), -2 (monitor), -3 (off-chip)。
  • Attestation:如果TEE运行时只能执行本地认证(即安全引导),或者也可以执行远程认证。
  • Previously exploited:黑圈表示由特定技术所启用的TEE系统的已知漏洞。
  • Communication mechanisms with REE:共享内存、数据复制和通信总线(如USB或SP)。

一类硬件技术提供了一组CPU扩展,其中处理器被增强为实现特定的支持TEE的安全功能的电路。
TrustZone适合这个类别,以及Intel Software Guard Extensions (SGX)、Intel SystemManagement Mode (SMM) 和Sanctum等技术。
SoC中单独的协同处理器,如Apple Secure Enclave Processor (SEP) 或Qualcomm Secure Processing Unit (SPU) ,可能包括专用的非易失性存储和RAM,这允许减少共享硬件资源,并有助于防止边信道攻击。
在专用安全芯片中,运行环境包括处理器、内存和持久存储器。例:Intel Management Engine (ME) 是一个基于Minix OS的固件,在Intel系统中运行在一个单独的处理器上。
它被设计成一个几乎完全独立的系统,可以访问许多外围设备,并具有自己的安全引导功能。
一些安全芯片可能配备了篡改检测,例如Titan-M。
其他模块,如TrustedPlatform Module (TPM),实现了可信引导、远程认证和其他原语的特定功能。
对虚拟化的硬件支持也可以用于实现TEE。
在Windows的Virtual Secure Mode (VSM)下,hypervisor建立了两种分层特权模式VTL0(类似于NW)和VTL1(类似于SW)。
AMD Secure Encrypted Virtualization (SEV)提供了使用硬件加速内存加密来加密虚拟机内存的能力。
RISC-V是一种指令集体系结构,虽然尚未广泛部署,但也可用于实现TEE。

IX. CONCLUSION

本文提出一项TrustZone-assisted TEEs的脆弱性研究。
尽管人们普遍认为TEE是安全的,因为它们的硬件强制隔离能力和小TCB,我们的研究报告了大量的证据来质疑这一假设。
当前的TEE系统在实现上有严重的限制。
架构和硬件级别可能会引入影响数百万设备的可利用漏洞。
本文强调了多种最先进的防御手段,我们相信这可以使商业TEE系统实质上更安全。

这篇关于【论文笔记】SoK: Understanding the Prevailing Security Vulnerabilities in TrustZone-assisted TEE Systems的文章就介绍到这儿,希望我们推荐的文章对编程师们有所帮助!



http://www.chinasem.cn/article/274171

相关文章

Spring Security 基于表达式的权限控制

前言 spring security 3.0已经可以使用spring el表达式来控制授权,允许在表达式中使用复杂的布尔逻辑来控制访问的权限。 常见的表达式 Spring Security可用表达式对象的基类是SecurityExpressionRoot。 表达式描述hasRole([role])用户拥有制定的角色时返回true (Spring security默认会带有ROLE_前缀),去

Security OAuth2 单点登录流程

单点登录(英语:Single sign-on,缩写为 SSO),又译为单一签入,一种对于许多相互关连,但是又是各自独立的软件系统,提供访问控制的属性。当拥有这项属性时,当用户登录时,就可以获取所有系统的访问权限,不用对每个单一系统都逐一登录。这项功能通常是以轻型目录访问协议(LDAP)来实现,在服务器上会将用户信息存储到LDAP数据库中。相同的,单一注销(single sign-off)就是指

浅析Spring Security认证过程

类图 为了方便理解Spring Security认证流程,特意画了如下的类图,包含相关的核心认证类 概述 核心验证器 AuthenticationManager 该对象提供了认证方法的入口,接收一个Authentiaton对象作为参数; public interface AuthenticationManager {Authentication authenticate(Authenti

Spring Security--Architecture Overview

1 核心组件 这一节主要介绍一些在Spring Security中常见且核心的Java类,它们之间的依赖,构建起了整个框架。想要理解整个架构,最起码得对这些类眼熟。 1.1 SecurityContextHolder SecurityContextHolder用于存储安全上下文(security context)的信息。当前操作的用户是谁,该用户是否已经被认证,他拥有哪些角色权限…这些都被保

Spring Security基于数据库验证流程详解

Spring Security 校验流程图 相关解释说明(认真看哦) AbstractAuthenticationProcessingFilter 抽象类 /*** 调用 #requiresAuthentication(HttpServletRequest, HttpServletResponse) 决定是否需要进行验证操作。* 如果需要验证,则会调用 #attemptAuthentica

Spring Security 从入门到进阶系列教程

Spring Security 入门系列 《保护 Web 应用的安全》 《Spring-Security-入门(一):登录与退出》 《Spring-Security-入门(二):基于数据库验证》 《Spring-Security-入门(三):密码加密》 《Spring-Security-入门(四):自定义-Filter》 《Spring-Security-入门(五):在 Sprin

AI hospital 论文Idea

一、Benchmarking Large Language Models on Communicative Medical Coaching: A Dataset and a Novel System论文地址含代码 大多数现有模型和工具主要迎合以患者为中心的服务。这项工作深入探讨了LLMs在提高医疗专业人员的沟通能力。目标是构建一个模拟实践环境,人类医生(即医学学习者)可以在其中与患者代理进行医学

【学习笔记】 陈强-机器学习-Python-Ch15 人工神经网络(1)sklearn

系列文章目录 监督学习:参数方法 【学习笔记】 陈强-机器学习-Python-Ch4 线性回归 【学习笔记】 陈强-机器学习-Python-Ch5 逻辑回归 【课后题练习】 陈强-机器学习-Python-Ch5 逻辑回归(SAheart.csv) 【学习笔记】 陈强-机器学习-Python-Ch6 多项逻辑回归 【学习笔记 及 课后题练习】 陈强-机器学习-Python-Ch7 判别分析 【学

系统架构师考试学习笔记第三篇——架构设计高级知识(20)通信系统架构设计理论与实践

本章知识考点:         第20课时主要学习通信系统架构设计的理论和工作中的实践。根据新版考试大纲,本课时知识点会涉及案例分析题(25分),而在历年考试中,案例题对该部分内容的考查并不多,虽在综合知识选择题目中经常考查,但分值也不高。本课时内容侧重于对知识点的记忆和理解,按照以往的出题规律,通信系统架构设计基础知识点多来源于教材内的基础网络设备、网络架构和教材外最新时事热点技术。本课时知识

论文翻译:arxiv-2024 Benchmark Data Contamination of Large Language Models: A Survey

Benchmark Data Contamination of Large Language Models: A Survey https://arxiv.org/abs/2406.04244 大规模语言模型的基准数据污染:一项综述 文章目录 大规模语言模型的基准数据污染:一项综述摘要1 引言 摘要 大规模语言模型(LLMs),如GPT-4、Claude-3和Gemini的快