Dedicated Security Chips in the Age of Secure Enclaves ∗

Kari Kostiainen, Aritra Dhar, Srdjan CapkunETH Zurich

AbstractSecure enclave architectures have become prevalent inmodern CPUs and enclaves provide a flexible way to im-plement various hardware-assisted security services. Butspecial-purpose security chips can still have advantages.Interestingly, dedicated security chips can also assist en-claves and improve their security.

Keywords — secure enclaves, security chips, trusted path,remote attestation, proximity verification

Trusted Computing Base (TCB) minimization is one ofthe most fundamental computer security principles. The mainidea is to reduce the amount of software and hardware thatneeds to be trusted for the secure operation of a particular ap-plication. A common technique to achieve TCB minimizationis to run the application inside a Trusted Execution Environ-ment (TEE). The TEE protects the application’s execution,despite any other compromised software on the same system.

One TEE implementation approach that has gained signifi-cant popularity recently is to realize the TEE by enhancing themain CPU of the computing platform with new features likespecial instructions and access control checks. Intel’s SGX,designed for the x86 architecture, is a prime example of suchTEE. In SGX, the CPU ensures that no other process can ac-cess the memory of the protected application that is called anenclave. By doing this, SGX guarantees that enclaves enjoyexecution integrity, and their data remains confidential.

Several other TEE designs exist too. ARM TrustZone isa popular TEE architecture that is used in many commercialmobile devices, while Sanctum [1] serves as a good exampleof a research TEE system. For simplicity, we focus on Intel’sSGX and use it as a case study to discuss the strengths andlimitations of enclaves.

SGX-style enclaves are powerful security primitive. Theyare programmable, and thus developers can implement almost

∗This article has been accepted for publication in IEEE Security & Privacymagazine’s special issue on hardware-assisted security (Fall 2020).

arbitrary hardware-protected security services using them.This is in contrast to previous secure elements like TPMsthat support only a fixed set of operations. Enclaves are alsofast, as they run on the main CPU of the computing platform,compared to significantly slower security elements like smartcards. And furthermore, enclaves are cheap, since they requireno additional hardware in contrast to expensive separate co-processors like HSMs.

This combination of programmability, high performance,and low cost makes enclaves an attractive way to deployvarious hardware-assisted security services. Indeed, after adecade of research and development into secure enclaves, thefirst large-scale commercial deployments are now starting.For example, Microsoft’s Confidential Computing serviceuses SGX enclaves to protect customer data in the cloud.

The wide adoption of enclave architectures in modernCPUs is probably the most prominent trend in hardware-assisted security over the last decade. However, there is alsoanother, more subtle trend appearing. Recently, computingservice providers like Google and computer manufacturerslike Apple have started to enhance their systems with special-purpose security chips. Google’s cloud servers have a securitychip called Titan in them [2], while Apple’s computers comewith the T2 security chip [3].

At first glance, these two trends seem almost contradic-tory. If enclaves enable arbitrary hardware-protected securityservices, why do we still need dedicated security chips?

In this article, we discuss the rationale behind this trend.We explain the benefits of dedicated security chips and out-line two of our research projects where we designed such.These projects showcase an interesting new pattern — onewhere special-purpose security chips assist enclaves and thusimprove their security.

Dedicated Security Chips

Computing platform providers have recently added new secu-rity chips to their systems. We look at two examples.

Figure 1: Google Titan [2] and Apple T2 [3] security chips.

Google Titan

Titan [2] is a security chip implemented as a low-power mi-crocontroller on Google’s purpose-built server platforms. TheTitan chip communicates with the main CPU via the SerialPeripheral Interface (SPI), and it interposes between the bootfirmware flash and the Platform Controller Hub (PCH).

One of the main functionalities that Titan implements issecure boot. When the server machine is powered up, Titanexecutes code, known as boot ROM, from its embedded read-only memory. This code is immutable and thus implicitlytrusted. The boot ROM code loads Titan’s firmware fromthe embedded flash and verifies its integrity using a digitalsignature. Once Titan’s firmware is securely verified and run-ning, it can verify the boot process of its host. Titan blocksPCH’s access to the firmware flash until it has cryptographi-cally verified the content of the flash, and then it releases thelock and allows the verified boot firmware to configure themachine and load the boot loader which subsequently verifiesand loads the OS. Such an iterative process allows precisecontrol over which system software is booted.

Apple T2

Apple’s latest PCs come with a security chip called T2 [3] thatalso supports secure boot. When the machine with the T2 chipis turned on, T2 executes code from its read-only memory.This code verifies the next step of the T2’s own boot process.Once T2 is fully running, it can verify the UEFI firmware,which will ensure that only authorized kernel will be bootedon the host CPU.

Besides secure boot, T2 also provides other security fea-tures such as protecting the user’s fingerprint values or makingsure that the microphone is disconnected from the main CPUwhen the laptop’s lid is closed.

Specific Security Objectives

Both Titan and T2 implement secure boot. Secure boot is alsoa good example of a security mechanism that is outside thesecurity objectives of SGX.

SGX was designed to provide a specific set of protec-tions [4]. These protections include detection of integrityviolation of an enclave instance, confidentiality of enclave’s

Textbox 1: ARM TrustZone is a processor-basedTEE architecture that is commonly used on smart-phones. The main idea of TrustZone is to implementtwo separate execution modes on the main CPU. Alluntrusted software, like the OS and third-party apps,are executed in the normal world, while applicationsthat need protection run in a separate execution modecalled the secure world. The processor and mem-ory controllers ensure that any process in the normalworld cannot access the secure world.

TrustZone can enable secure boot [5]. A mobiledevice can be configured such that when the device ispowered up, the main CPU starts executing implicitlytrusted code that is loaded from read-only memory insecure world. This code can then verify the normalworld boot loader before the CPU starts executing themain boot sequence of the normal world OS. Manysmartphone manufacturers implement this approach.

data, isolation between enclaves, and enforcement that en-clave’s execution always starts from an authorized location.The overall goal of these protections can be loosely summa-rized as enabling secure computation on untrusted computingplatforms.

Because the above-listed protections do not include OS in-tegrity verification, platform providers have added dedicatedsecurity chips, like Titan and T2, to implement such function-ality. Disconnecting the microphones from the main CPU isanother example of a security feature that is not provided byenclaves. (As noted in Textbox 1, other TEEs like the ARMTrustZone architecture can accommodate a secure boot.)

Security Weaknesses

Besides limited objectives, enclaves also have security weak-nesses. Since enclaves and untrusted code share the sameCPU, they can be susceptible to side-channel leakage andmicroarchitectural attacks. The recently discovered Spectreand Meltdown vulnerabilities showed how transient executioncould leak information across isolation boundaries. The sameidea was successfully applied to extract secret keys from SGXenclaves in the Foreshadow attack [6].

While specific attacks can be, and have been, mitigated(e.g., Intel’s microcode updates include Spectre and Melt-down patches), side-channels and microarchitectural attackscontinue to be a concern for enclaves. The root cause is thatmodern processors are extremely complex systems that havebeen optimized over decades. Enclave support was added ontop of many layers of performance optimizations, and now, inhindsight, one can easily say that this approach was not theideal foundation for strong isolation. In this regard, dedicatedsecurity chips have a clear advantage over enclaves.

2

Another security challenge is the rich interface betweenthe untrusted OS and the enclave. Enclaves must interact withthe operating system in many ways. For example, enclavescommunicate by sending and receiving messages through theOS. Enclaves also need to pause their execution for interruptssafely. While enclave architectures provide coarse-grainedmemory isolation primitive at the hardware level, developersneed to ensure that the interface is protected on the softwarelevel. Common implementation tasks include sanitization ofbuffers and safety checks for pointers.

Because such checks are tedious, several enclave runtimeslike the Open Enclave SDK have been developed to assistenclave developers. However, recent research has shown thatmany such enclave runtimes have classical memory safetyvulnerabilities [7]. Because dedicated security chips do notneed equally extensive interaction with the OS, the interfacetowards the untrusted OS is easier to protect tightly.

Other Security Services?

To summarize our discussion so far, enclaves do not imple-ment all useful security mechanisms, and they also have sig-nificant security issues. Dedicated security chips can addressboth of these concerns.

Obviously, the security services that can be implemented asdedicated security chips are not limited to the above-discussedexamples. Which other services could be implemented asspecial-purpose security chips?

Titan and T2 are integrated security chips that are perma-nently attached to the computing platform. Are there also usecases that would benefit from plug-and-play security tokens?

In the rest of this article, we explore these questions byexamining two examples from our recent research. Our firstexample is trusted path [8], and after that, we focus on plat-form identification and remote attestation [9].

Trusted Path

The main goal of SGX is to enable secure computation for en-claves. Such enclaves do not easily lend themselves to secureuser interaction. The main reason for this is that, in archi-tecture like SGX, enclaves communicate with I/O devicesthrough the untrusted OS. When an enclave needs to receiveuser input, the OS needs to pass data from an input devicelike a keyboard to the enclave. When an enclave creates useroutput, the OS must forward data to an output device likedisplay. Such TEE design means that a compromised OS caneasily modify any user inputs and outputs. Indeed, trustedpath — a secure channel from the human user to a trustedapplication like enclave — is outside the security objectivesof SGX [4].

User input manipulation can have severe consequences. Ifa malicious OS modifies the user input that is provided toa financial enclave, the enclave can be tricked to perform

unauthorized payments. If enclaves are used to implementhardened medical devices or industrial systems, user inputmodifications may cause serious safety and health risks. Also,any enclave that needs user passwords or similar credentialsis difficult to implement securely.

Design Principles

Several projects have explored the idea of complementingcomputing platforms with dedicated hardware modules forbuilding a trusted path. While proposing extra hardware maybe easy, the more difficult and interesting question is what ex-actly should the added hardware do? To answer this question,we look at previous approaches, examine their limitations, andidentify design principles for trusted path implementation.

The first approach that we look at is transaction confirma-tion [10]. In such a solution, the user first completes the userinteraction, such as payment, by interacting with the UI of theuntrusted platform that may be manipulated by the OS or thebrowser. Once this is done, the user is expected to confirmhis input, like a payment value and account number, using aseparate hardware token, to detect and prevent any possiblemodifications.

This approach has two main problems. The first is the factthat the user now has to interact with two separate devices andtwo user interfaces, which reduces usability. The second, andmore severe, problem is that such extra confirmation step isvulnerable to user habituation. Habituation refers to behaviorwhere the user begins, after a few successful transactions,confirming new payments without verifying their correctness.These observations lead us to the first design principle.

Principle 1: Out-of-context security confirmationshave a high cognitive load and risk of user habitua-tion. Thus, user interaction should be protected in thecontext of the normal user interface.

The next approach that we examine is input signing [11].Here, the main idea is to use a simple hardware device thatsits in-between a user input device, such as a keyboard, andthe untrusted computing platform. The device intercepts everykeypress, or similar user input event, and sends a signed traceof them to the trusted application.

Input signing conforms to our first principle because theuser does not have to interact outside the main UI. However,such solutions are vulnerable to attacks, where the adversarymanipulates the user’s input by showing false information onthe output channel. That is, output manipulation leads to userinput integrity violation. One example is a fake-typo attack.Assume that the user types in value “10”, but the adversaryshows “1” on the screen. The user is likely to think that hemistyped and press “0” again. As a result, a signed trace of“100” will be sent to the trusted application. This simple attackleads us to our next design principle.

3

Principle 2: User input and output integrity cannotbe considered in isolation. Both must be protectedsimultaneously.

The last approach that we examine is secure overlays. Fi-delius [12] is an example research system that follows thisapproach. In Fidelius, one device intercepts keyboard pressesand signs them for the trusted application, while another de-vice intercepts the HDMI output signal and modifies it withsecure overlays of security-critical UIs such as payment webforms.

Fidelius addresses the above-mentioned problems but isstill vulnerable to a different type of user input manipulationthat we call early-submission attack. This attack is possi-ble because Fidelius only protects keyboard input, but not amouse. While this may seem only a functional limitation, itturns out that it is a security problem. Assume again that theuser intends to submit value “10”. Once the user has typed“1”, the untrusted OS or browser generates a fake mouse eventthat submits the web form. Mouse inputs could be disabledaltogether, but such naïve solution hurts usability. Now wecan state our last design principle.

Principle 3: All user input modalities must to be pro-tected simultaneously.

ProtectIOn System

Given these principles, we designed a new trusted path systemcalled ProtectIOn [8]. In the following, we focus on the usecase where the trusted path is established between the user anda remote web server. That is, we want to protect interactionswhere the user completes and submits a security-critical webform. The same solution could be easily modified to create atrusted path between the user and a local enclave as well.

Figure 2a shows the overview of ProtectIOn system. Thecentral component of the solution is a low-complexity embed-ded device called IOHub that intercepts key presses from akeyboard and movement events from a mouse, tracks mousemovements, and draws secure overlays.

When the user visits a web page that contains a protectedweb form, the remote server sends a QR code to the untrustedbrowser, as shown in Figure 2b on the left. The QR codecontains a specification of the protected web form signed bythe server to prevent its modification in the browser. By usingQR codes, we enable communication from the webserver tothe IOHub device via an unmodified browser, which simplifiesdeployment significantly.

By periodically examining the HDMI signal, IOHub detectsthe QR code on the screen, decodes it, and verifies its signa-ture. After that, as shown in Figure 2b in the middle, IOHubrenders the protected web form as an overlay on top of the

IOHubHost

Frames

Input forward

IO signals

Network

Server

(a) ProtectIOn system.

Attacker’s view User’s view on the monitor Focusing user’s attention

a b c

(b) ProtectIOn user interface.

Figure 2: ProtectIOn system.

HDMI frame that it receives from the untrusted OS. This stepensures that the security-critical UI elements are presented tothe user correctly, and thus output integrity of the protectedweb form is preserved.

IOHub tracks mouse movement events, and when the mousepointer enters the secure overlay, as shown in Figure 2b onthe right, IOHub dims the rest of the screen to focus the user’sattention to the secure overlay. Such protection is neededto prevent the user from following a possible fake mousecursor, drawn by the untrusted browser or OS, elsewhere onthe screen. Dimming parts of the screen have been shown tobe an effective way to focus the user’s attention to the correctcursor [13].

While the user interacts with the protected web form, IOHubintercepts all input events, and when the user clicks on thesubmit button, the IOHub signs all inputs and sends them tothe server via the untrusted browser (e.g., by encoding themto a requested URL). Since the submit button is part of theprotected overlay and all mouse clicks are intercepted andsigned by the IOHub device, early-submission attacks are notpossible. The server verifies the signed user inputs it receives.

If input confidentiality is needed, the user can be required totrigger a secure attention sequence (SAS), like Ctr+Alt+Del,before entering any secrets. The untrusted OS and the browsercannot observe sensitive data on the secure overlay since they

4

are rendered by IOHub and never accessible to them.Such a design complies with our three design principles.

Principle 1 is met because the user only interacts with themain UI. Secure overlays support Principle 2, and mousetracking combined with input trace signing ensures that allinput modalities are protected (Principle 3).

ProtectIOn prototype We implemented a prototype of theIOHub device as a combination of Raspberry Pi and Arduinoboards and a simple HDMI interceptor. Our prototype showsthat proposed functionalities are feasible to implement withsmall TCB on low-cost hardware. Full details of the Protec-tIOn system are explained in our recent paper [8].

Attestation and Platform Identification

Remote attestation is a key feature of enclave architectureslike SGX. In remote attestation, an external verifier checksthat an enclave was constructed as expected. To do this, theverifier sends a challenge to the attested CPU. The CPU signsthe challenge together with a previously recorded measure-ment of the enclave’s code using a processor-specific attesta-tion key. The signature can also include application-specificdata, such as the public key of the enclave, that allows se-cure communication with the attested enclave. The attestationkey is part of a group signature scheme that is managed byIntel. The signed attestation statement is then sent back tothe verifier. If the signature can be verified correctly, the re-mote verifier knows that the attested enclave was correctlyconstructed and runs the expected code inside a legitimateSGX processor.

Remote attestation process allows remote verifiers to detectenclave integrity violations before provisioning secrets tothem or before accepting signed messages from them.

Relay Attacks

The above outlined remote attestation protocol is a usefulsecurity mechanism, but it also has a well-known problem.An adversary that controls the OS on the attested platform caneasily redirect the attestation challenge to another platformthat computes the response. The verifier cannot notice suchrelay attacks, since the SGX attestation mechanism is basedon a group signature scheme, and all processors from thesame group produce indistinguishable signatures. (Even ifattestation used traditional digital signatures, it would be verydifficult in practice for the verifier to know which signing keycorresponds to which CPU.) In other words, SGX guaranteesdetection of enclave’s integrity violation, but identificationof the computing platform in which the attested enclave isrunning is not part of its security objectives.

Relay attacks have been known for a long time. Parnoidentified them in the context of TPM attestation over a decadeago and called them “cuckoo attacks” [14]. However, the full

implications of relay attacks have not been well understood.Since attestation can only be redirected to another legitimateprocessor that executes exactly the same attested enclave code,it may appear that such relay attacks do not have noteworthynegative implications. Our analysis shows that such a beliefis misguided.

Relay attack implications Many computer systems, likeservers at data centers, use multiple layers of protection. Theseprotections may include using TEEs to protect certain ap-plications, but also other defenses such as running softwarecomponents at different privilege levels, physically protect-ing access to the computing platform, and frequent patchingof discovered vulnerabilities. The main implication of relayattacks is that they increase the adversary’s ability to attackthe attested enclave by circumventing many such protections.

Our first observation is that by redirecting the attestationto the adversary’s platform, the adversary enables physicalside-channel attacks such as acoustic, electric, and electro-magnetic monitoring which otherwise would not be possibleto mount on the victim’s platform. Such side channels havebeen shown to be effective and inexpensive means to extractsecrets [15] and hardening enclaves against all possible phys-ical side channels is difficult.

Relay attacks can also enable privilege escalation. In caseswhere the adversary has only compromised the user-spaceapplication that manages the enclave on the victim platform,the application can redirect the attestation to the attacker’splatform where he controls the OS as well. In such cases, therelay enables digital side-channel attacks that require systemprivileges.

The third and perhaps most subtle implication of relay isthat it can enable software-based side-channel attacks thatwould not be otherwise possible due to the timing of certainevents. One example is a scenario where the victim plat-form OS is compromised at the time of attestation and secretprovisioning, and the attested enclave is hardened againstknown digital side-channel attacks (e.g., using tools like Rac-coon [16]). After secret provisioning, the OS compromise isdetected, and the platform is cleaned and patched. Later, anew side-channel attack vector (that is not prevented by theused tools) is discovered. If the adversary performed redi-rection during attestation and the secret was provisioned tothe attacker’s machine, the new side-channel is exploitable.Without the relay, the attack is not possible. In this case, the at-testation relay eliminates the security benefit of good platformmaintenance.

Finally, we note that attacks based on leaked attestationkeys (e.g., ones obtained through the Foreshadow attack [6])are independent of relaying. If the adversary has obtained avalid attestation key, he can emulate an SGX processor on thetarget platform and steal any secrets that are provisioned to it.

5

Trust on first use A commonly suggested solution to re-lay attacks is the principle of trust on first use (TOFU). Inone example solution, a platform-specific enclave generatesa key pair and exports the public part of the key for certifica-tion right after a fresh OS installation. When remote verifiersneed to attest other enclaves on that platform, they can firstauthenticate the certified enclave which in turn performs lo-cal attestation of the target enclave (SGX provides a localattestation primitive that cannot be relayed).

Such TOFU solution has several problems. The first is largetemporary TCB, as a complete general-purpose OS needs tobe trusted during the first boot. The second is difficulty indeployment because fresh OS re-installation is not alwayspossible. The third is the need for online authorities whichincreases their attack surface, assuming that the certificationprocess is automated. Further problems are discussed in [9].

ProximiTEE System

Parno identified relay attacks more than a decade ago and,at the same time, suggested proximity verification as a solu-tion [14]. The main idea was to verify that the attested CPU isin the proximity of the verifier device, which should preventattestation redirection to remote platforms.

Proximity verification using an external device overcomesthe above listed main problems of TOFU approaches. First,the TCB is small, as the verifier device can be a single-purposeand thus very simple. Second, the adoption of such a solutionis easy, as there is no need to reset the target platform fully.And third, the authority that certifies the verifier device canremain fully offline.

Although the idea of proximity verification sounds simpleto realize, the research efforts that followed failed to imple-ment secure proximity verification. The main reason for thefailure was that TPM, the secure element commonly availableat the time, supported only fixed identification operations likedigital signatures. TPM signatures may take up to one second,which allows the redirected attestation request to travel a longdistance, and thus TPMs were simply too slow for secureproximity verification.

Because SGX enclaves are programmable, it is possibleto implement proximity verification protocols that leveragesimple operations like XOR that enable fast challenge-responserounds. Based on this observation, we designed a hardenedSGX attestation scheme, called ProximiTEE [9].

Our solution uses a simple embedded device called Prox-imiKey that is attached to the target platform over a localcommunication interface like USB. In hardened remote attes-tation, the verifier first establishes a secure channel a Prox-imiKey whose public key the verifier learns from its issuer.ProximiKey performs standard remote attestation on the localenclave, establishes a secure TLS channel to it, and verifiesits proximity using a simple distance-bounding protocol thatconsists of repeated and fast challenge-response rounds. If

ProximiKey latency

time (µs)150 200 250 300 3500.

000.

030.

06

Rerouting over EthernetLocal USB interface

Tcon

Tdetach

Figure 3: Latency distributions for legitimate challenge-responserounds and simulated relay attack.

such proximity verification succeeds, ProximiKey facilitatesthe creation of a secure channel between the remote verifierand the attested enclave.

Proximity verification security While the above design ismostly straightforward, the more interesting aspect is whethersuch a system prevents relay attacks in practice. To answerthis question, we implemented our solution using a USB pro-totyping board and simulated a strong attack scenario wherethe adversary performs a relay to another SGX platform thatis connected to the target platform over a one-meter longEthernet wire. We also assumed that the adversary is able toperform all protocol computation instantaneously.

Figure 3 shows the results from our experiments, where wemeasured both the legitimate and relayed challenge-responselatencies. The vast majority of the benign latencies range from145 to 250µs, while the attack round-trips take from 200 to750 µs. The average delay of our adversary is only 80µs. (Toput this into perspective, even the highly-optimized networkconnections between major data centers in the same regionexhibit latencies from one millisecond upwards.)

As can be seen from Figure 3, these two latency distri-butions are distinguishable. Our analysis confirms that it ispossible to set protocol parameters (number of challenge-response rounds, latency threshold, etc.) such that very fastrelay attacks can be detected with high probability and legit-imate attestations fail only with negligible probability. Thefull details of the ProximiTEE system and our analysis can befound from our recent paper [9].

Discussion

Now that we have seen two commercial, integrated securitychips (Titan and T2) and two user-attachable, research to-kens (ProtectIOn and ProximiTEE), we can discuss their de-ployment aspects, security benefits, and previous comparablesolutions.

Deployment options Integrated security chips like Titanand T2 are, obviously, limited to deployments by major ser-vice and platform providers that have the possibility to designand build their own systems.

6

ProximiTEE is an example of a plug-and-play security to-ken that can be attached to the target platform over a standardinterface like USB. Deployment of security solutions is a fea-sible option for a larger set of service providers. For example,cloud computing providers can enhance off-the-shelf serverswith ProximiKey tokens and communicate their public keysto their clients to support more secure attestation. Anotherinteresting use case is the setup of a permissioned blockchainwhere every consensus node is hardened with SGX enclaves.The trusted authority that appoints the consensus nodes canissue a ProximiKey token to each organization that operatesone node.

Also ProtectIOn could be deployed as a plug-and-play se-curity module. Such deployment allows service providerslike voting authorities and banks to increase the security oftheir services without restricting the users’ choice of clientplatform. In medical and industrial domains, an externally-attached ProtectIOn module can improve the security ofsafety-critical systems, even when modifications to the com-puting platform itself are prohibited due to strict regulations.Alternatively, ProtectIOn could be deployed as an integratedsecurity chip such that its functionality is implemented as partof the integrated keyboard, mouse, and display controllers.

Security benefits Titan and T2 are chips that enable se-curity functionality like a secure boot that is not providedby enclaves. Thus, the operation of Titan and T2 is largelyorthogonal to the operation of enclaves.

In comparison, ProximiTEE is a security chip that is de-signed to work in collaboration with enclaves and improvetheir security guarantees by enabling secure TEE identifica-tion for hardened remote attestation.

ProtectIOn is a solution that can either assist enclaves oroperate independently of them. One possible usage for Protec-tIOn is to enable a trusted path from the user to a local enclave,which can communicate securely with remote servers. In sucha deployment, ProtectIOn works together with an enclave. Al-ternatively, ProtectIOn could be used to create a trusted pathfrom the user to a remote server without the use of enclaves.Such deployment is beneficial when the risk of microarchitec-tural attacks on enclaves is considered too high, for example.

Dedicated chips and early TEEs Some previous TEE de-signs have leveraged dedicated security chips to implement aTEE that can be attested.

AMD’s Secure Virtual Machine technology is one such ex-ample where the TEE is created as follows: the CPU measurecode in a specific memory region, enables DMA protectionsfor that region, disables interrupts, records the measurementinto a PCR register of a TPM chip, and finally begins execut-ing the measured code. Essentially, this sequence of eventsprovides a clean execution of the measured code withoutrestarting the whole platform, and therefore this techniqueis often called “late launch”. The main role of the dedicated

chip (TPM in this case) is to securely record the code that waslaunched so that an external verifier can check its integrityusing attestation.

Outlook

Future computing platforms are likely to combine variouscomputing units like CPUs, GPUs, TPUs, FPGAs and more.Similar to the current enclave architectures that enhance CPUswith secure execution capabilities, also other processing unitslike GPUs and FPGAs will need secure computation. Thereare already several on-going research efforts that explore thedesign of such TEEs [17].

Our research on trusted path (the ProtectIOn system [8])highlights that I/O devices need secure communication withenclaves. Similarly, also other peripherals like GPS units andfingerprint sensors would benefit from secure communica-tion with enclaves. Protected communication between TEEsand other platform components requires authentication, en-clave identification and access control mechanisms. The ARMTrustZone architecture has limited support towards this di-rection. In TrustZone, hardware components like memorycontrollers can make coarse-grained access control decisionsbased on the CPU’s execution mode [5].

Extending this paradigm for more fine-grained access con-trol and secure inter-component communication is one promis-ing direction. We envision future computing platforms whereenclaves, peripherals and special-purpose security chips cancommunicate and work together to provide a rich set ofhardware-assisted platform security services.

References

[1] V. Costan et al., “Sanctum: Minimal hardware extensions forstrong software isolation,” in USENIX Security’16.

[2] Google, “Titan in depth: Security in plaintext.”https://cloud.google.com/blog/products/gcp/titan-in-depth-security-in-plaintext.

[3] Apple, “About the Apple T2 security chip.” https://support.apple.com/en-us/HT208862.

[4] F. McKeen et al., “Innovative instructions and software modelfor isolated execution.,” HASP’13.

[5] J.-E. Ekberg et al., “The untapped potential of trusted executionenvironments on mobile devices,” S&P magazine, 2014.

[6] J. Van Bulck et al., “Foreshadow: Extracting the keys to theIntel SGX kingdom with transient out-of-order execution,” inUSENIX Security’18.

[7] J. Van Bulck et al., “A tale of two worlds: Assessing the vul-nerability of enclave shielding runtimes,” in CCS’19.

[8] A. Dhar et al., “ProtectIOn: Root-of-trust for IO in compro-mised platforms,” in NDSS’20.

[9] A. Dhar et al., “ProximiTEE: Hardened SGX attestation byproximity verification,” in CODASPY’20.

7

[10] A. Filyanov et al., “Uni-directional trusted path: Transactionconfirmation on just one device,” in DSN’11.

[11] A. Dhar et al., “Integrikey: End-to-end integrity protection ofuser input.” https://eprint.iacr.org/2017/1245.

[12] S. Eskandarian et al., “Fidelius: Protecting user secrets fromcompromised browsers,” in S&P’19.

[13] L.-S. Huang et al., “Clickjacking: Attacks and defenses,” inUSENIX Security’12.

[14] B. Parno, “Bootstrapping trust in a trusted platform,” in Hot-Sec’08.

[15] D. Genkin et al., “Physical key extraction attacks on PCs,”Communications of the ACM, 2016.

[16] A. Rane et al., “Raccoon: Closing digital side-channels throughobfuscated execution,” in USENIX Security’15.

[17] S. Volos et al., “Graviton: Trusted execution environments onGPUs,” in OSDI’18.

8