Delegating Verification for
Remote Attestation using TEE
Takashi Yagawa1, Tadanori Teruya2,Kuniyasu Suzaki3, Hirotake Abe1
1University of Tsukuba, Japan

2AIST, Japan
3Institute of Information Security, Japan

7th Workshop on System Software for Trusted Execution
July 8th, 2024

1

Background: Remote Platform is unsafe
Cloud Service and IoT are becoming more widespread.
They are both managed in physically remote location.
However, that situation allows a malicious administrator or attacker
to manipulate the remote platforms.

Administrator Manipulate

Cloud ServiceAccessUserAttacker

IoT2

Remote Attestation required
To prevent such threat, Remote Attestation (RA) is important.
RA allows users to remotely check the status of a device and service.

Request RA
Cloud Service

Send Evidence
AccessIoT

Verification
RequestUser

Verification
Service3

Challenge: Increase in Remote Attestation
With Function as a Service (FaaS) and Edge Computing becoming
more popular, RA is more required.
However, existing verification services do not have the shorter
response time nor scalability.
RA per program
SmallPrograms

FaaS

User
Each IoT RA

Verification
ServiceProgram

Cloud Service

IoT4

Our Approach：Delegating Verification
There is a limitation that only Trusted Party (e.g. CA) can verify anevidence.
=> We propose Delegating Verification :• Trusted Party delegates a qualification of verification tothird parties.
• In delegation process, verification program is run with Trusted
Execution Environment (TEE) and Trusted Party examines it.
Examines verification program
Grant Qualification
Trusted PartyVerification Service(Third Party Server)

5

Benefits of Our Approach• Quick Response=> Third Party Servers can begeographically distributed.
• Trustworthy=> Trust anchor is TrustedParty as now.

• Scalable=> Delegating Verification
setup new verifier more
quickly than PKI mechanism.

Trusted Party

Delegating Verification

Third Party
Server 1

Third Party
Server 2…

Third Party
Server n

Request Verification

User 1

User 2…

User n6

Contents• Introduction• Design• Implementation & Evaluation• Related Works• Conclusion & Future Works

7

Contents• Introduction• Design• Implementation & Evaluation• Related Works• Conclusion & Future Works

8

TEE and its RA• An extension of CPU for memory protection that uses a key burned
into CPU as the Root of Trust.
• TEE keeps confidentiality in Protected Area through memory
encryption and privilege management.
• Its RA will confirm that the integrity of TEE and the program inProtected Area.
CPU GenuinenessRemoteAttestation

Security Version
Hash value ofthe program

User

RAM
Protected
Area

ManageCPUTEE9Design Overview
Provisioning

Examination Phase

Delegation Phase⑤ Request Verification

Verification Phase

Protected by TEE

User④ Request RA& Get Evidence③ Delegating Verification
Qualification

Third Party Server② Launch
Verification Program① Send Verification Code
IoT

Could
Service

Trusted Party

Third Party10

Examination Phase
Examination Phase① Submit Verification
Program Code

② Examine, thenBuild and Sign the code
BuildThirdParty③ Publish
Verification Program

TrustedParty

Verification
ProgramAny third party can use this11

Delegation Phase
Delegation Phase⑤ Verify
Evidence
Third Party ③ Req
RA① Deploy
Verification
Program④ Response
Evidence ,Trusted Party
CSR

Protected Areaby TEE② Create Key Pair & Issue CSR
Sign
Public Private
KeyKeyThird Party Server⑥ Issue
Delegation
Cert
from CSR

CSR
12Verification Phase
Verification Phase
Protected Area by TEE④ Verification & Sign
ResultIoT Could
Service① Req RASign
Private Key③ Request
Verification

Third Party Server⑤ Response
Result Cert

② Response
Evidence

User⑥ Confirm
Responce

Verify13

Contents Table• Introduction• Design• Implementation & Evaluation• Related Works• Conclusion & Future Works

14

Implementation
TEE：Intel Software Guard Extensions (SGX)
Verification Program：SGX-TDX-DCAP-QuoteVerificationService*• Our implementation is a docker container and
we used Gramine tool for SGX application.
• We added the process that generating key pair and Certificate
Signing Request (CSR) to the Verification Program.
• We used k6 for our evaluation.
Measurements were taken for 10 seconds andthe average value was used.
* Intel, https://github.com/intel/SGX-TDX-DCAP-QuoteVerificationService

15Evaluation Environment

OSUbuntu 22.04 LTS

Linux kernel

6.2.0-36-generic

CPUIntel Xeon Silver 4314

SGX SDK

2.22.100.3

SGX PSW

1.19.100.3-jammy1

16

Evaluation：Runtime Overhead

SGX+4ms

Sig+5ms

Total+9ms

17Evaluation：Turnaround TimeDue to asynchronous
processing

Increase linearly18Evaluation：Number of Request

Due toprocessing limit

But our proposal can solve the processing limit by scale-out!

19

Contents Table• Introduction• Design• Implementation & Evaluation• Related Works• Conclusion & Future Works

20

Related Works(1/2)• Proxy Signature (Mambo, et al. 1996) is a cryptographic schemefor erecting a proxy for the signer. The delegate issues acertificate for the signature key of the proxy signer. We apply thisscheme on a per-verification-program basis.
• Swarm Attestation (Nadarajah, et al. 2015) improves RA
scalability by collectively verifying IoT devices. However, it is notapplicable when RA is requested centrally from an unspecified
number of devices.
CollectiveRequests
IoT Network

VerificationService21

Related Works(2/2)• Intel Trust Authority* is an online verification service provided byIntel for multiple TEEs. Our proposal will allow verification services
to be deployed on third-party servers that are not managed by atrusted authority.
• By using SGX DCAP (Simon, et al. 2018), SGX verification servers
can be built by users themselves. However, it is too costly for each
SGX user to build a verification environment.

* Intel® Trust Authority, https://www.intel.com/content/www/us/en/security/trust-authority.html

22

Conclusion• For increasing in RA, we proposed a delegating verification
for secure verification on third-party servers.
• We implemented a proof of concept for our approach withIntel SGX.

• The limit on the number of requests processed suggeststhat our idea is helpful.

23

Future Works• Integration of traditional RA and certificate issuance• Modifying Gramine's RA.

• Automation of the delegation phase• Accept delegating verification by Trusted Party via API.

• Measuring scalability• How quickly can we increase the number of verification servers?
• What are the challenges in doing so dynamically?
24

Appendix25

Adversarial Model and Assumption
The goal of the adversary:Users can execute RA on vulnerable or malicious platforms
without them being detected.
The adversary can• manipulate any program with administrator privileges.
• eavesdrop, delete, or tamper with packets in any network.
• erect new unauthorized verification servers.
However, the following attacks are not considered:• Side-channel attacks• Attacks that threaten availability (e.g. DoS attack)26