Towards Heterogeneous Remote Attestation Protocols

Paul Georg Wagner

and J

urgen Beyerer

1,2

Karlsruhe Institute of Technology, Karlsruhe, Germany

Fraunhofer Institute of Optronics, System Technologies and Image Exploitation IOSB, Karlsruhe, Germany

Keywords:

Remote Attestation, Trusted Computing, Trusted Platform Modules, Intel SGX, Arm Trustzone, Distributed

Systems.

Abstract:

Remote attestation protocols are valuable tools to cryptographically verify the integrity of remote software

stacks. Usually these protocols rely on a speciﬁc hardware-based trusted computing technology to provide

their security guarantees. However, especially in distributed settings with many collaborating platforms it is

not always feasible to use protocols developed exclusively for one trusted computing technology. In this work

we explore the possibility of conducting heterogeneous remote attestations between endpoints utilizing dif-

ferent trusted computing technologies. We motivate the beneﬁts of such attestations in the light of distributed

systems and present a list of requirements for a working heterogeneous remote attestation protocol. Then we

propose a remote attestation mechanism that can securely link Intel SGX enclaves, TPM-based trusted appli-

cations, as well as ARM TrustZone devices with an attested and encrypted communication channel. Finally

we outline how this mechanism can be integrated into an established remote attestation protocol.

1 INTRODUCTION

In today’s environment of ubiquitous computing,

more and more data are being processed in distributed

systems. Such systems consist of components that are

often operated by different stakeholders in a decen-

tralized infrastructure. One major challenge in such

scenarios is to establish the trustworthiness of remote

system components. This includes verifying the cor-

rectness of remote components and preventing mali-

cious operators from manipulating critical software.

A popular way of achieving this is by applying re-

mote attestation protocols. Remote attestation is the

process of cryptographically verifying the integrity of

a computing device’s software stack. This veriﬁca-

tion process is usually backed by hardware-based se-

curity mechanisms known as trusted computing tech-

nologies. Currently the most popular and widespread

trusted computing technologies are Trusted Platform

Modules (TPMs), Intel SGX and ARM TrustZone.

While much research went into the development

of these technologies over recent years, so far they

have mainly been viewed separately from each other.

Depending on the speciﬁc use case and security re-

quirements, usually only one technology is selected

and deployed systemwide. However, especially in

distributed systems it is beneﬁcial to combine sev-

eral trusted computing technologies and conduct re-

mote attestations between them. That way technolo-

gies with different beneﬁts and drawbacks can be used

simultaneously. For example, TPMs are cheap and

easy to use, but generally do not provide as strong se-

curity guarantees as Intel SGX. Being able to deploy

SGX enclaves for security-critical components while

still using TPM-protection would greatly enhance the

ﬂexibility and adaptability of distributed trusted ap-

plications. Furthermore, in large distributed systems

it is unlikely that all operators unanimously agree on a

single trusted computing technology to use in the en-

tire system. Finally, there are often technological rea-

sons for using multiple trusted computing technolo-

gies. For example, ARM-based embedded devices

seldom have a dedicated TPM module, so they are

bound to rely on the ARM TrustZone technology.

In this position paper we take ﬁrst steps towards

a heterogeneous remote attestation protocol that con-

nects different trusted computing technologies. For

this, we ﬁrst give a brief overview of existing remote

attestation protocols (section 2), before we identify

requirements for a heterogeneous protocol (section 3).

Then we describe how to conduct remote attestations

between TPMs, Intel SGX and ARM TrustZone and

show how these mechanisms can be integrated into a

joint attestation protocol that establishes secure chan-

nels (section 4). Finally we conclude the paper with

an outlook on future work (section 5).

586

Wagner, P. and Beyerer, J.

Towards Heterogeneous Remote Attestation Protocols.

DOI: 10.5220/0011289000003283

In Proceedings of the 19th International Conference on Security and Cryptography (SECRYPT 2022), pages 586-591

ISBN: 978-989-758-590-6; ISSN: 2184-7711

2 RELATED WORK

Among the most widespread trusted computing

technologies today are Trusted Platform Modules

(TPMs). TPMs hold several cryptographic keys on

a dedicated hardware chip, which can then be used

to encrypt and sign critical information in a secure

environment. The private parts of the cryptographic

keys stored in the TPM hardware are protected against

external inﬂuence and cannot be extracted in plain

text. There have been multiple proposals for TPM-

based remote attestation protocols over the years

(Armknecht et al., 2008; Zhou and Zhang, 2010;

Wagner et al., 2020; TCG, 2019a). All of them uti-

lize a special set of registers in the TPM chip, the

Platform Conﬁguration Registers (PCRs). When a

TPM-protected system boots up, these registers con-

tain unforgeable ﬁngerprints of the system’s current

hardware and software conﬁguration. During the re-

mote attestation protocol, the PCR contents are signed

with the private part of an asymmetric attestation key,

which is known only to the TPM. By verifying that

signature as well as the system ﬁngerprints, remote

veriﬁers can be convinced that the attested system

runs a correctly conﬁgured and unmodiﬁed software

stack. Furthermore, most remote attestation protocols

also conduct a Difﬁe-Hellman key exchange to estab-

lish a shared secret between veriﬁer and prover.

A more sophisticated trusted computing technol-

ogy is Intel’s Software Guard Extension (SGX). In-

tel SGX consists of a set of special hardware security

modules directly integrated into the CPU die, which

allow security critical code to run as a protected en-

clave (Costan and Devadas, 2016). SGX enclaves

are executed completely isolated from the rest of the

computer system, including other system processes,

administrators, and even the operating system itself.

Similar to TPMs, there are several SGX-based re-

mote attestation protocols on offer. One way of re-

motely attesting SGX enclaves is by using a group

signature scheme called EPID (Johnson et al., 2016).

This scheme extends the machine-internal local attes-

tation of an SGX enclave with a cryptographic sig-

nature that is externally veriﬁable by communicating

with Intel’s attestation services. However, with recent

CPUs Intel also provides the option to build decentral-

ized third-party attestation infrastructures (DCAP),

mainly targeted to data center operations (Scarlata

et al., 2018). Both attestation protocols offer a so-

phisticated Sigma protocol encompassing a Difﬁe-

Hellman key exchange to establish a shared secret be-

tween prover and veriﬁer. The low-level remote attes-

tation schemes provided by Intel have also been in-

tegrated into several higher-level communication pro-

tocols. There are proposals for including SGX-based

remote attestation into TLS (Knauth et al., 2018) as

well as HTTPS (King and Wang, 2021). Furthermore,

Google uses a high-level protocol called EKEP

for

SGX-based attestation in their Asylo framework, and

there is also a protocol implementation for Gramine

While Intel SGX is only available for x86 archi-

tectures, TrustZone is the trusted computing technol-

ogy for ARM-based infrastructures. ARM TrustZone

divides the system into two distinct worlds, the nor-

mal world and the secure world (Pinto and Santos,

2019). Both worlds have their own software stack

and are strictly isolated from each other by means of

hardware-based access control. That way the poten-

tially compromised normal world (and even its op-

erating system) cannot maliciously inﬂuence security

critical applications running inside the secure world.

Unlike with TPMs and SGX, remote attestation ca-

pabilities have not been a big concern in the design

of ARM TrustZone. To our knowledge, no stan-

dardized remote attestation protocol for TrustZone

has been published so far. However, there are some

application-speciﬁc proposals (Shepherd et al., 2017;

Wang et al., 2020; Ling et al., 2021) available. These

proposals utilize a Software-TPM implemented as a

trusted application and protected by the TrustZone

hardware. Hence the resulting proposals are very sim-

ilar to TPM-based attestation protocols.

3 PROTOCOL REQUIREMENTS

As a ﬁrst step towards heterogeneous remote attesta-

tion protocols, we have identiﬁed six general require-

ments that such protocols should fulﬁll.

Heterogeneous Attestations. The ﬁrst and most

important requirement is the support of heteroge-

neous remote attestations. This means that a single

protocol instance must be able to deal with differ-

ent trusted computing technologies on both endpoints.

After the protocol handshake completes successfully,

the code identities of both sides have to be mutu-

ally veriﬁed as dictated by the respective mechanisms.

Furthermore, at this point the protocol has to consider

the potentially different attestation scopes. For exam-

ple, an SGX remote attestation provides code iden-

tity information about a single enclave. TPMs on the

other hand always include the entire trusted system in

their attestation data. In the remainder of this paper

we focus on supporting TPMs, SGX and TrustZone

https://asylo.dev/docs/concepts/ekep.html

https://gramineproject.io/

Towards Heterogeneous Remote Attestation Protocols

587

as trusted computing technologies. However, in the

future other technologies should be supported in het-

erogeneous remote attestations as well.

Mechanism Negotiation. Since a heterogeneous

remote attestation protocol has to handle multiple dif-

ferent technologies at once, a suitable way of mecha-

nism negotiation is required. The protocol needs to be

able to select suitable attestation mechanisms for both

respective endpoints and notify them about the kind of

attestation information to expect from the other side.

Only then can a heterogeneous attestation endpoint

successfully validate the transmitted attestation infor-

mation. This could be achieved with a separate nego-

tiation phase before the actual remote attestation.

Secure Channels. Besides the mutual veriﬁcation

of code integrity, the remote attestation protocol also

has to establish a secure channel between the attested

endpoints. Usually this is achieved by adopting a

Difﬁe-Hellman key exchange to establish a shared se-

cret on the channel. However, when developing a het-

erogeneous remote attestation protocol, great care has

to be taken to properly authenticate this key exchange.

The key exchange has to be unambiguously linked

to the attested code identities. This means that the

shared secret must only be accessible to the attested

endpoints, and only if they are in the correct (i.e. ver-

iﬁed) states. How exactly this is achieved depends on

the speciﬁc trusted computing technology used. Fur-

thermore, the protocol must be resilient against replay

attacks, i.e. prevent adversaries from authenticating a

new key exchange with old attestation information.

Platform Independence. A heterogeneous remote

attestation protocol is particularly useful in distributed

systems consisting of many different hardware plat-

forms, because in such systems it is often not feasi-

ble to deploy just one single trusted computing tech-

nology. Hence platform independence is an impor-

tant protocol requirement. This includes compatible

protocol implementations for different platforms (e.g.

ARM and x86), but also simple protocol bindings

for different programming languages. Furthermore

the protocol should be easily expandable with novel

trusted computing mechanisms.

Protocol Reuse. Since there are sophisticated and

(partly) standardized remote attestation protocols

available for the considered trusted computing tech-

nologies, it is not necessary to invent new attestation

mechanisms completely from scratch. Instead, the

heterogeneous attestation protocol should build on al-

ready existing attestation mechanisms wherever pos-

sible. That way protocol complexity can be decreased

and compatibility can be maximized.

Performance. Finally, the protocol performance is

deﬁned by the time it takes to conduct a full two-way

handshake including the mutual attestations. How-

ever, the protocol performance will strongly depend

on the speciﬁc trusted computing technologies. For

example, TPMs are rather slow on certain crypto-

graphic operations, while SGX enclaves can utilize

the full resources of the CPU and are much faster.

Hence the performance of a heterogeneous remote

attestation protocol should be evaluated by compar-

ing it with existing attestation protocols of the various

mechanisms.

4 A HETEROGENEOUS REMOTE

ATTESTATION PROTOCOL

In this section we show how mutual remote attesta-

tion can be conducted between endpoints of different

trusted computing technologies. We present a con-

cept for mutual remote attestation between hardware-

based TPMs and Intel SGX enclaves, and discuss how

it can be adopted for attestations between ARM Trust-

Zone devices and SGX enclaves. We also show how

secure communication channels can be established

between heterogeneous endpoints. Finally, we pro-

pose the integration of these mechanisms into a het-

erogeneous remote attestation protocol.

4.1 Connecting Trusted Platform

Modules with SGX Enclaves

To facilitate a mutual remote attestation between

hardware-based TPMs and Intel SGX enclaves, we

combine the EREPORT instruction on SGX-capable

systems with the TPM2 Quote instruction on the TPM-

protected side. Furthermore, we establish a shared

secret using an elliptic curve Difﬁe-Hellman (ECDH)

key exchange. We choose ECDH to allow the use of

the TPM2 ECDH ZGen key establishment primitive of

the TPM 2.0 interface (TCG, 2019b), as has been re-

cently proposed in (Wagner et al., 2020). On the SGX

side, this key exchange is authenticated by including

a hash of the public key in the signed EREPORT data

structure. Together, this establishes a secure com-

munication channel between the heterogeneous end-

points and ensures that the shared secret is known

only to both attested code identities.

SECRYPT 2022 - 19th International Conference on Security and Cryptography

588

System A (SGX)

System B (TPM)

Untrusted App Trusted App

Local attestation

SGX QE SGX Enclave TPM

PCR_Extend()

Loop

Create

nonce

Launch

EREPORT( )

, Q

TPM2_Create(ECDH)

sgx_report

Create nonce

Create ECDH

(

, Q

)

sgx_report,

, N

Validate sgx_report

(

)

Create

TPM2_Certify( )

, N

TPM2_Quote( )

tpm_report

tpm_report,

, Q

Validate tpm_report

Validate signature

Calculate

tpm_report,

, Q

sgx_report,

, N

Encrypt using shared secret

k :

KDF

(

)

TPM2_ECDH_ZGen( )

Calculate

Figure 1: Remote attestation mechanism between SGX enclaves and TPMs.

Figure 1 shows a high-level description of the pro-

posed heterogeneous remote attestation sequence be-

tween an SGX enclave and a TPM-protected trusted

application. To keep the sequence diagram simple, we

assume that both systems are already set up and ready

to conduct a remote attestation. This means that the

TPM-protected system has performed a trusted boot

sequence that established a chain of trust from the

hardware TPM over the bootloader and operating sys-

tem to the user applications. We especially assume

that the trusted application has been included in the

measurements conducted via the PCR Extend TPM

operation, because otherwise the SGX enclave can-

not validate the remote code identity and the attesta-

tion would fail. On the SGX side, we assume that

the quoting enclave (QE) has been launched and pro-

visioned with an attestation key according to either

the EPID or DCAP speciﬁcation. Note that for sim-

plicity, ﬁgure 1 only provides a high-level description

of the necessary SGX attestation messages. The de-

tails of EPID (Johnson et al., 2016) and DCAP (Scar-

lata et al., 2018) attestation messages can be found

in the respective speciﬁcations. Furthermore we omit

additional SGX components required for the respec-

tive attestation procedure, such as the Intel attesta-

tion services (with EPID) or the provisioning certi-

ﬁcation enclave (with DCAP). As ﬁrst step in the pro-

tocol handshake, the TPM-protected trusted applica-

tion randomly draws a nonce N

and transmits it to

the remote enclave. This nonce is used for freshness

purposes and prevents malicious reuse of attestation

information (replay attacks). The SGX enclave then

creates its own nonce N

for the same reason, as well

as a new ECDH key pair (d

, Q

). Note that the se-

cret key d

has been created inside the secure SGX

enclave and will never leave it. The public key Q

along with the remote nonce N

is then used as qual-

ifying data to generate the signed SGX report in the

quoting enclave. This means that the tuple (Q

, N

)

is hashed and included in the attestation information

generated for the SGX enclave. That way the nonce

provides freshness, and the enclave’s ECDH public

key is authenticated and linked to the conducted at-

testation. The resulting SGX attestation report is then

transmitted back to the TPM system, alongside the en-

clave’s public key Q

and its nonce N

. In the trusted

application, the SGX attestation report can then be

veriﬁed. During the veriﬁcation process, both the re-

port’s signature as well as the contained enclave ﬁn-

gerprints have to be validated. Note that ﬁgure 1 omits

some details of the signature veriﬁcation step. When

the EPID signature scheme is used on the SGX side,

the veriﬁer has to communicate with Intel’s attesta-

tion service (IAS). When DCAP is used, a third-party

certiﬁcation authority provides the necessary certiﬁ-

cates for the signature veriﬁcation. Once the SGX

attestation report has passed veriﬁcation, the TPM-

protected software stack generates its ECDH key pair

and attestation information. As described in (Wagner

et al., 2020), we can use the TPM2 Create function

Towards Heterogeneous Remote Attestation Protocols

589

to generate a new ECDH key pair (d

, Q

) inside the

TPM. Once again, the private key d

will never leave

the protected TPM hardware for the remainder of the

handshake. Instead, we use the TPM2 Certify func-

tion to sign the public ECDH key Q

with the current

attestation key used by the TPM. While this differs

from the key handling on the SGX side, it fulﬁlls the

same purpose. The resulting signature σ

authenti-

cates the ECDH public key and links it to the current

attestation context, since it is signed by the unique at-

testation key. Note that to prevent replay attacks, here

we have to include the remote nonce N

in the signa-

ture as well. Finally, the usual TPM2 Quote function is

used to generate an attestation report over the selected

PCRs, which is also signed with the TPM’s attestation

key. As soon as the TPM attestation report, the ECDH

public key and its signature is transmitted to the SGX

enclave, it can be veriﬁed there. In this veriﬁcation

step the enclave has to check both the report’s and the

public key’s signatures and also validate the attested

PCR ﬁngerprints. Once this is successful, both sides

can calculate the shared Difﬁe-Hellman secret Z us-

ing their own secret key and the authenticated remote

public key. Subsequent communication can then be

encrypted using a symmetric secret derived from Z.

4.2 Connecting ARM TrustZone

Devices with SGX Enclaves

To give our heterogeneous remote attestation proto-

col a broader ﬁeld of application, we aim to support

ARM TrustZone devices without access to a physi-

cal TPM. One issue is that to our knowledge there

is currently no standardized remote attestation proto-

col available for ARM TrustZone. However, we can

build on existing proposals that are using a dedicated

trusted measurer application protected by the Trust-

Zone hardware (Shepherd et al., 2017). For our pur-

poses it makes sense to use fTPM (Raj et al., 2016) as

trusted measurer. fTPM is a TPM 2.0 reference im-

plementation created by Microsoft, which has been

migrated to ARM TrustZone devices. As a software

implementation of the TPM speciﬁcation, it offers all

functionality of dedicated hardware TPM modules.

Using fTPM-based remote attestation on ARM Trust-

Zone has clear beneﬁts for our use case. Since fTPM

provides a TPM 2.0 compatible programming inter-

face, we can very easily adopt the protocol presented

in ﬁgure 1 for TrustZone devices. The only real differ-

ence in the protocol sequence is that we use an fTPM

trusted application instead of a hardware TPM. How-

ever, there are also several drawbacks of this solution.

First, software TPMs cannot provide the same level of

isolation as a dedicated hardware TPM chip. In fact,

ARM TrustZone only provides hardware-backed iso-

lation of trusted software against malicious applica-

tions running in the rich world. However, depending

on the attacker model we require protection against

maliciously manipulated trusted applications as well.

Furthermore, it is still unclear how to establish a broad

chain of trust that includes all relevant system soft-

ware (including the bootloader and operating system)

from both worlds. This is an important step to ensure

the integrity of the fTPM trusted application. There is

some recent work by ARM aimed at establishing mea-

sured boot processes on ARM platforms with fTPM

but to our knowledge this largely remains an open

issue. However, besides the drawbacks of this ap-

proach, we believe that fTPM-based remote attesta-

tion on ARM TrustZone devices is a promising direc-

tion for developing heterogeneous remote attestation

in distributed environments containing ARM devices.

4.3 Heterogeneous Protocol Integration

After describing heterogeneous remote attestation

mechanisms that are capable of establishing secure

communication channels, we are left with integrat-

ing these mechanisms into a joint protocol. We plan

to do this by extending the existing Enclave Key Ex-

change Protocol (EKEP)

. EKEP has been developed

by Google for their Asylo trusted computing frame-

work, where it is used to securely communicate be-

tween local and remote SGX enclaves. On a technical

level, EKEP is based on a TLS variant that features

mutual authentication, which has been enhanced to

include attestation information during the key estab-

lishment. Integrating the heterogeneous remote attes-

tation mechanism as described in ﬁgure 1 into EKEP

requires some modiﬁcations. First, establishing the

encrypted communication channel should now be out-

sourced to the underlying TLS protocol, instead of

performing a separate Difﬁe-Hellman key exchange.

However, to prevent man-in-the-middle attacks, the

established channel encryption key still needs to be

properly linked to the attested code identities. Usu-

ally this is achieved by generating self-signed TLS

certiﬁcates. These TLS certiﬁcates are then included

in the attestation reports instead of the ECDH pub-

lic key itself (c.f. ﬁgure 1). This authenticates the

self-signed certiﬁcates, which in turn can be used to

ﬁnally establish an encrypted TLS channel during the

remote attestation protocol handshake. While this is

a simple and reliable solution, integrating the TPM-

based attestation step shown in ﬁgure 1 requires some

deeper modiﬁcations. This is because the key ex-

https://github.com/OP-TEE/optee os/pull/5025

https://asylo.dev/docs/concepts/ekep.html

SECRYPT 2022 - 19th International Conference on Security and Cryptography

590

change should use the TPM to generate and authen-

ticate the Difﬁe-Hellman key pair, which the native

TLS integration in EKEP does not support yet. Fur-

thermore, the most important requirement remaining

to be addressed is mechanism negotiation. Fortu-

nately EKEP already includes a way to signal attes-

tation mechanisms to the remote endpoints. This is

because EKEP has been designed to accommodate

both local and remote attestations between SGX en-

claves. While naturally these two attestation mech-

anisms strongly depend on each other, we are conﬁ-

dent that this mechanism can be adopted to negoti-

ate mechanisms between endpoints that are utilizing

completely different trusted computing technologies.

5 CONCLUSION

In this position paper we addressed the challenge

of conducting remote attestations between different

trusted computing platforms. We motivated the use-

fulness of a heterogeneous remote attestation proto-

col that bridges the technological gap between differ-

ent technologies and presented a list of protocol re-

quirements. Then we showed how remote attestations

can be conducted between Intel SGX enclaves and

hardware-based TPMs, as well as ARM TrustZone

devices. Our proposed attestation mechanisms also

establish shared secrets that are bound to the attested

platform identities. Finally, we brieﬂy discussed the

possibility of integrating the proposed mechanisms

into the existing remote attestation protocol EKEP.

In the future, we plan to develop mechanisms to

facilitate remote attestations with more trusted com-

puting platforms, such as RISC-V and AMD SEV.

Furthermore, important future work includes the im-

plementation and evaluation of a proof-of-concept at-

testation protocol. As outlined in the last section,

we plan to use the existing implementation of EKEP

as a basis for this. We believe that we can fulﬁll

most of the requirements presented in section 3 that

way. However, even with a working proof of con-

cept for multiple technologies, there will still be re-

maining issues to consider. This includes perfor-

mance evaluations, but most importantly the problem

of analyzing the security of heterogeneous attestation

protocols. Since such protocols depend on multiple

security-critical technologies with possibly different

attacker models at once, determining the resulting se-

curity guarantees that can be expected from a protocol

handshake is rather difﬁcult. We plan to explore these

research questions more thoroughly in the future.

REFERENCES

Armknecht, F., Gasmi, Y., Sadeghi, A.-R., Stewin, P.,

Unger, M., Ramunno, G., and Vernizzi, D. (2008). An

efﬁcient implementation of trusted channels based on

openssl. In 3rd ACM workshop on Scalable trusted

computing, pages 41–50.

Costan, V. and Devadas, S. (2016). Intel sgx explained.

IACR Cryptology Archive, page 86.

Johnson, S., Scarlata, V., Rozas, C., Brickell, E., and Mc-

kee, F. (2016). Intel software guard extensions: Epid

provisioning and attestation services. Technical re-

port.

King, G. and Wang, H. (2021). Httpa: Https attestable pro-

tocol. arXiv preprint arXiv:2110.07954.

Knauth, T., Steiner, M., Chakrabarti, S., Lei, L., Xing,

C., and Vij, M. (2018). Integrating remote attes-

tation with transport layer security. arXiv preprint

arXiv:1801.05863.

Ling, Z., Yan, H., Shao, X., Luo, J., Xu, Y., Pearson, B., and

Fu, X. (2021). Secure boot, trusted boot and remote

attestation for arm trustzone-based iot nodes. Journal

of Systems Architecture, 119:102240.

Pinto, S. and Santos, N. (2019). Demystifying arm trust-

zone: A comprehensive survey. ACM Computing Sur-

veys (CSUR), 51(6):1–36.

Raj, H., Saroiu, S., Wolman, A., Aigner, R., Cox, J., Eng-

land, P., Fenner, C., Kinshumann, K., Loeser, J., Mat-

toon, D., et al. (2016). ftpm: A software-only imple-

mentation of a tpm chip. In 25th USENIX Security

Symposium (USENIX Security 16), pages 841–856.

Scarlata, V., Johnson, S., Beaney, J., and Zmijewski, P.

(2018). Supporting third party attestation for intel sgx

with intel data center attestation primitives. Technical

report.

Shepherd, C., Akram, R. N., and Markantonakis, K. (2017).

Establishing mutually trusted channels for remote

sensing devices with trusted execution environments.

In Proceedings of the 12th International Conference

on Availability, Reliability and Security, pages 1–10.

TCG (2019a). Trusted attestation protocol (tap) information

model. Technical report. Accessed April 2022.

TCG (2019b). Trusted platform module 2.0 library. Tech-

nical report. Accessed April 2022.

Wagner, P. G., Birnstill, P., and Beyerer, J. (2020). Es-

tablishing secure communication channels using re-

mote attestation with tpm 2.0. In International Work-

shop on Security and Trust Management, pages 73–

89. Springer.

Wang, Z., Zhuang, Y., and Yan, Z. (2020). Tz-mras: A re-

mote attestation scheme for the mobile terminal based

on arm trustzone. Security and Communication Net-

works, 2020.

Zhou, L. and Zhang, Z. (2010). Trusted channels with

password-based authentication and tpm-based attesta-

tion. In 2010 International Conference on Communi-

cations and Mobile Computing, volume 1, pages 223–

227. IEEE.

Towards Heterogeneous Remote Attestation Protocols

591