CHARRA-PM: An Attestation Approach Relying on the Passport Model

Antonio Marques

and Bruno Sousa

DEI, CISUC, University of Coimbra, Portugal

Keywords:

Remote Attestation, Passport Model, CHARRA, Challenge-Response, IoT.

Abstract:

Attestation is a mechanism that is employed to verify the authenticity and integrity of the other(s) part(s), i.e.,

in hardware and/or software of a device. The remote attestation is the activity of verifying the authenticity

and integrity of a target that provides evidence to a veriﬁer over a network that should be accepted or denied

as a result of this process. Classic authorization relies in the information provided by a device and gives

permission for a speciﬁc operation. The attestation adds a new a layer of information, not only we need to

know who the device is, but we also need to know if it is in good standing (i.e. performing according to its

design) before authorization. This paper proposes the use of the Passport model, using the Challenge/Response

development based on the architecture described by the IETF working group RATS - Remote Attestation

Procedures Architecture. The elaborated Proof-of-Concept is designed and evaluated using docker containers

and TPM software simulation.

1 INTRODUCTION

The wide range of low-cost embedded devices with

the ability to command other devices on a network has

grown enormously. The network to which these de-

vices belong is called the IoT, which at the year 2022

registered a growth of 18% compared to the previ-

ous year (14.4 billion dollars) according to IoT Ana-

lytic (IoT Analytics, 2022).

Such devices have low cost, low consumption and

easy integration. Their application is possible in sev-

eral layers of the industry, such as the medical, auto-

motive, smart cities sectors.

IoT devices generally do not have built-in security

features or the ability to install or update software.

That was a limitation without major problems when

installed in isolated networks and not connected to

the outside world. However, as technology advances,

the IoT interconnectivity with the Internet’s enterprise

network grows (Kettani and Wainwright, 2019). An-

other point of observation is the manufacture of these

devices on a large scale, where manufacturers want

to produce quickly and at a lower cost without safety,

security concerns. On the other hand, we have the in-

stallation of devices without proper precautions. Due

to this, IoT systems are becoming a favourite target

for cyber attacks (Martin et al., 2019).

Remote Attestation (RA) allows to ﬁnd which de-

vice is not following the network’s policies, or not

https://orcid.org/0000-0002-1416-9558

https://orcid.org/0000-0002-5907-5790

functioning as intended and was possibly the target

of an attack. Thus, RA supports the collection of evi-

dences regarding the behaviour of a device, which can

be used as input to build the reputation or to set trust

levels regarding the device usage.

CHARRA-PM, built on top of CHARRA (Fraun-

hofer, 2021), introduces the Relying Party component

in the challenge-response remote attestation process.

The relying party entity, within the passport model

is speciﬁed in the RATS architecture (Birkholz et al.,

2022b), as an entity that can make decisions about

communication, access, and permissions of devices.

Available implementations like CHARRA do not in-

clude the support of the Relying Party, which is a rel-

evant element, upon the need to apply policies.

The contribution of CHARRA-PM is threefold: 1)

implementation of a relying party contributing to the

support of an architecture for remote attestation; 2) A

complete remote attestation process allowing the en-

forcement of policies, and 3) Open-source implemen-

tation available (Marques, 2022).

The paper is organized as follows, section 1 intro-

duces the paper, section 2 introduces relevant back-

ground and related works. Section 3 introduces the

proposed approach for attestation, section 4 describes

the evaluation methodology and the achieved results.

Section 5 concludes the paper.

Marques, A. and Sousa, B.

CHARRA-PM: An Attestation Approach Relying on the Passport Model.

DOI: 10.5220/0011623600003405

In Proceedings of the 9th International Conference on Information Systems Security and Privacy (ICISSP 2023), pages 349-356

ISBN: 978-989-758-624-8; ISSN: 2184-4356

 2023 by SCITEPRESS – Science and Technology Publications, Lda. Under CC license (CC BY-NC-ND 4.0)

349

2 ATTESTATION BACKGROUND

AND STATE OF THE ART

2.1 IETF Remote Attestation - RATS

The objective of RATS is to propose a framework (ar-

chitecture and standardized data formats) for a secure

and reliable connection between IoT devices. The

structure currently in place consists of a device - At-

tester - that produces reliable information - Evidence

- about itself, transmitting it to another entity respon-

sible for validating the information received - Veri-

ﬁer. The Relying Party is responsible for receiving

the veriﬁcation result to make decisions about com-

munication, access, and permissions.

The veriﬁer, when evaluating the evidence, or the

Relying Party, when evaluating the attestation results,

verify that the claims values correspond to their eval-

uation policy. Such veriﬁcation can include the equal-

ity comparison with a reference value, or if it is in a

range delimited by reference values, or if it belongs to

a set of reference values.

A concrete example would be the need for a de-

vice - Attester - to prove that it can convey with an-

other device. For that, it has to provide evidence from

its system that must be validated by a trusted entity

- Veriﬁer. This last entity will appraise the evidence

and return an attestation result to prove the attester’s

state.

Upon completion of all checks regarding the as-

sessment policy, values are accepted as input to de-

termine attestation results when evaluating evidence

or as input to a relying party when evaluating the at-

testation results. A Relying Party can be any equip-

ment with software capable of performing authoriza-

tions on the network, such as a router, switch, or ac-

cess point responsible for admitting certiﬁed devices

to the network.

For CHARRA-PM it is relevant to consider

the Remote Attestation Procedures Architec-

ture (Birkholz et al., 2022b) and the Reference

Interaction Models for Remote Attestation Pro-

cedures (Birkholz et al., 2022a) that enable the

remote attestation on the RATS architecture. The

RATS conceptual ﬂow considers the following

aspects (Birkholz et al., 2022b).

The RATS speciﬁcation (Birkholz et al., 2022a)

speciﬁes concepts that are related to the information

produced, requested and exchanged between entities.

The most relevant include the Claim which includes

the structure of evidence and other artefacts in the in-

formation chain. This can be a statement or a value

pair. The Evidence which is a set of claims gener-

ated by the Attester to be evaluated by a Veriﬁer. Ev-

idence can include conﬁguration data, measurements,

telemetry, or inferences. The Attestation Result is

the output generated by a veriﬁer containing informa-

tion about an Attester, where the Veriﬁer guarantees

the validity of the results.

2.2 Reference Models

The RATS architecture documents two refer-

ence models for the Challenge/response opera-

tion (Birkholz et al., 2022b; Birkholz et al., 2022a):

Passport Model and Background-check model.

The Passport-Model is an analogy to the model

of issuing passports by a nation to an individual and

its use at an immigration counter. So, in this immi-

gration counter analogy, the citizen is the Attester, the

passport issuing agency is the Veriﬁer, the passport

application and identiﬁcation information (e.g. birth

certiﬁcate) is the Proof, the passport is a Result Cer-

tiﬁcate, and the immigration desk is a Relying Party.

In this model an Attester transmits the Evidence to a

Veriﬁer, who compares it against its assessment pol-

icy or veriﬁes the requested data. The Veriﬁer then

returns an Attestation Result to the Attester, which

does not consume the Attestation Result but can cache

it. The Attester can then present the Attestation Re-

sult and possibly additional Claims to a Relying Party,

who then compares this information against its own

assessment policy.

The Background-check model has this name be-

cause of the similarity of how employers and organi-

zations perform background checks. When a prospec-

tive employee submits information about previous ed-

ucation or experience, the employer will contact the

respective institutions or employers to validate such

information provided. So, in this analogy, a potential

volunteer is an Attester, the organization is the Rely-

ing Party, and the reporting organization is a Veriﬁer.

In this model an Attester transmits Evidence to a Re-

lying Party, who forwards it to a Veriﬁer. The Veriﬁer

compares the Evidence against its assessment policy

and returns an Attestation Result to the Relying Party.

The Relying Party then compares the Attestation Re-

sult with its own evaluation policy.

The challenge/response model only allows the

validation that an attester meets the conditions to con-

vey with another entity. This would be enough in

some cases to implement a model with these two en-

tities. However, using a third entity whose function

would be to validate that the information generated

by the Veriﬁer is trustworthy and, from there, grant

access permission to resources or other entities pro-

vides us with an increase in security.

For a more robust level of security, the Relying

ICISSP 2023 - 9th International Conference on Information Systems Security and Privacy

350

Party may require the Veriﬁer to provide information

about itself that the Relying Party can use in assessing

the Veriﬁer’s reliability before accepting the Attesta-

tion Results. In order to implement a trust model that

fully utilizes the “trust anchor” concept, it is neces-

sary to have implemented the “Relying Party Owner”.

The Passport Model has less network trafﬁc in

comparison to the Background-check Model and the

possibility to cache the attestation result (for some

time) the Attestation Result in case of no communi-

cation with a Relying Party.

2.3 CHARRA

The CHAllenge-Response based Remote Attestation

with TPM 2.0 - CHARRA is a proof-of-concept im-

plementation of the Remote Challenge/Response At-

testation.CHARRA conforms to the RATS architec-

ture description (Fraunhofer, 2021). CHARRA was

written in C language, implementing libraries for ac-

cessing data on TPM chips and transporting this data

using protocols suitable for use in more restricted en-

vironments such as te IoT.

The implementation was entirely developed using

software, not being linked to a speciﬁc hardware plat-

form for code execution. Docker containers are using

the ofﬁcial repository of the TPM2 Software commu-

nity. Each container uses a TPM 2.0 chip simulator,

developed by IBM and a C library for interaction with

the TPM (TCG, 2022b).

CHARRA implements the secure challenge/re-

sponse ﬂow to validate evidence collected by an at-

tester but does not return the attestation result back to

the attester.

The challenge/response model can be used when

we want to ensure that a system has started correctly

and only runs authentic software.

Despite the compliance with the IETF RATS ar-

chitecture, CHARRA has some limitations regard-

ing the implementation of the Challenge/Response

Model. First, what is the purpose of doing the attesta-

tion only between the Attester and the Veriﬁer? Sec-

ond, when establishing a new communication with a

Relying Party, how can the Attester verify whether or

not he is trustworthy? Third, if no response is pro-

vided in the challenge/response model there is no re-

mote attestation.

CHARRA-PM, herein proposed, aims to over-

come these limitations, by providing a complete and

open-source implementation (Marques, 2022) of the

remote attestation architecture, with the introduction

of the Relying Party entity that contributes to the en-

forcement of policies regarding devices.

2.4 Related Work

SHeLA (Rabbani et al., 2019) is a model of at least

three layers, with a Root Veriﬁer that acts as the

”owner” of the attestation network and has associated

high computing power. The Root Veriﬁer commu-

nicates with the edge veriﬁers through the network.

The Edge Veriﬁers are devices with signiﬁcant com-

puting power and storage, in comparison to the low-

end devices - Swarm Nodes. Edges veriﬁers have a

permanent connection to root veriﬁers. The SHeLA

model assumes that Edge devices are trusted entities

supporting secure hardware that the root veriﬁer can

attest. Swarm nodes (the provers) are low-end devices

that communicate using particular wireless technolo-

gies like Zigbee, Wiﬁ or Bluetooth.

SARA (Dushku et al., 2020) proposes using asyn-

chronous protocols for group attestation, resulting in

the non-interruption of all devices simultaneously.

SARA uses a publisher/subscriber model based on the

Message Queue Telemetry Transport (MQTT) or Ad-

vanced Message Queuing Protocol (AMQP). The use

of queue managers and the historical attestation are

an advantage, in comparison to SHeLA.

CHARRA-PM has the advantage of following a

standardized approach for remote attestation, without

introducing demanding requirements in terms of com-

putation. SHeLA, in this regard introduces limitations

due to the high cost of Root and Edge Veriﬁer.

3 CHARRA-PM PASSPORT

MODEL

The motivation for choosing the Passport Model was

primarily due to the minimization of trafﬁc processed

by the Relying Party, compared to the one observed

in the Background-check model. On the other hand,

we isolated the Relying Party that centralizes claims

and responses as described in the Background-check

model, signiﬁcantly reducing the Relying Party’s

work, processing and network connections.

Adding a trusted third party in the Challenge/Re-

sponse model aims to validate the attestation result,

sent by the Veriﬁer to the Attester that forwards it to

the Relying Party. This process can decide the type of

permission/role the Attester can have on the network,

like limiting or blocking communication.

We created a new proof of concept: the

CHARRA-PM (Marques, 2022), taking advantage of

the development already carried out in CHARRA, in-

cluding a new device/entity, the Relying Party, and the

entire process necessary for the signing, transfer and

validation of the Resulting Certiﬁcate.

CHARRA-PM: An Attestation Approach Relying on the Passport Model

351

As stated previously, the contribution of

CHARRA-PM is the addition of the Relying

Party entity, leading to a complete implementation

of the Remote Attestation architecture. In addition,

RP also contributes to the policy enforcement. The

addition of a third party can be thought of in two

situations: functioning as a gateway or ﬁrewall for

granting privileges depending on the attestation result

or even an end device that would only establish

communication upon a valid attestation result.

Attester

Veriﬁer

generateClaims(attestingEnvironment)

==> claims, eventLog

requestAttestation(handle,

authSecIDs, claimSelection)

collectClaims(claims, claimSelection)

==> collectedClaims

generateEvidence(handle,

authSecIDs, collectedClaims)

==> evidence

evidence, eventLogs

appraiseEvidence(evidence,

eventLogs, refValues)

attestationResults

Relying

Party

attestationResults(evidence, results)

Passport Model

step 1

step 2

step 3

step 4

step 5

step 6

step 7

step 8

Figure 1: CHARRA-PM data Flow.

As identiﬁed in section 2.3, several limita-

tions were identiﬁed regarding the challenge/response

model implemented in CHARRA. CHARRA-PM

adds functionalities to further enrich the compliance

with the remote attestation architecture. First, the at-

testation result, validated by the Veriﬁer, is sent to

the Attester, as per documented in (Birkholz et al.,

2022a). Second the attestation result is employed

for policy enforcement. That is the attestation re-

sult proves that the Attester has requirements (valid

or not) to present to another peer to gain some level

of access. Third, the Relying Party reviews the sub-

mitted certiﬁcate by any policy it has or through a Re-

lying Party Owner (RPO). This policy can be a true or

false check, for example. Most importantly, the Rely-

ing Party trusts the Veriﬁer and the attester.

Figure 1 helps us understanding the generation

and data exchange ﬂow between the Passport model

parts. Assuming that the communication between the

parties is carried out safely and securely, as recom-

mended by the RATS documents, in this case, us-

ing the DTLS-RPK or DTLS-PSK. The collection of

information and communication between the parties

involved is summarized in two steps: Challenge/Re-

sponse and the Passport Model.

3.1 Challenge/Response Steps

When the Attester starts up, it produces claims about

its startup and operational state. Event logs track the

statements produced by providing a trail of critical se-

curity events in a system, as per step 1 in Figure 1.

The Challenge/Response remote attestation pro-

cedure is initiated by the Veriﬁer sending a remote at-

testation request to the Attester. This request includes

an identiﬁer (e.g., in the form of a nonce), authen-

tication secret IDs and claims selection, correspond-

ing to step 2 in Figure 1. In the Challenge/Response

model, the handle is composed in the form of a vir-

tually unguessable nonce (e.g., a strong random num-

ber). The nonce generated by the Veriﬁer ensures that

the Evidence is up to date and prevents replay attacks.

The authSecID is a key sent by the Veriﬁer to the At-

tester to sign the Attestation Evidence. Each key is

uniquely associated with an Attestation Environment

in the Attester. As a result, a single Authentication

Secret ID identiﬁes a single Attestation Environment.

The Attester collects Claims based on the Claim

Selection submitted by the Veriﬁer. If Claim Selec-

tion is omitted, all Claims available in the Attester

must be used to create the corresponding evidence by

default. For example, in a boot health assessment, the

Veriﬁer may only ask for a subset, such as Evidence

on BIOS/UEFI and ﬁrmware, and does not include

other information about the current running environ-

ment. This corresponds to step 3 in Figure 1.

With the Collected Claims, Handle, Authentica-

tion Secret IDs, the Attester produces the evidence

and signs it. It digitally signs the Handle and Claims

collected with a cryptographic secret identiﬁed by the

Authentication Secret ID. It is done once per Attes-

tation Environment, which is identiﬁed by the spe-

ciﬁc Authentication Secret ID. The Attester commu-

nicates the signed evidence and all accompanying

Event Records back to the Veriﬁer, as depicted in step

4 of Figure 1.

The implementation of CHARRA behaves differ-

ently, using the TPM private key of the Attester and

sending the public key along with the message to the

Veriﬁer. CHARRA-PM modiﬁes this behaviour due

to the fact of communicating the Attestation result to

the Relying Party.

When the Veriﬁer receives the Evidence and Event

Logs, it starts the Evidence assessment process, val-

idating the signature, received nonce against sent

nonce, and received claims. The assessment proce-

dures are application-speciﬁc and can be conducted

ICISSP 2023 - 9th International Conference on Information Systems Security and Privacy

352

by comparing values, using reference measures, and

producing the Attestation Results. This is done in step

5 of Figure 1.

3.2 Passport Model Steps

After producing the attestation, the Veriﬁer signs it

with its private key and sends it, through a secure

channel, to the Attester, as illustrated in step 6 of Fig-

ure 1. The Attester must immediately send the re-

ceived certiﬁcate to be evaluated by the Relying Party,

as per step 7 in Figure 1. The Attester cannot process,

verify or change the received certiﬁcate. At most, it

can keep until it expires.

The Attestation results can contain a Boolean

value indicating compliance or non-compliance with

a veriﬁer’s assessment policy, dispensing with the use

of a Relying Party Owner to provide an additional

evaluation policy (Birkholz et al., 2022b). The Re-

lying Party confers greater conﬁdence in the model,

as it is responsible for verifying whether the attesta-

tion result is reliable and valid, deciding the level of

access it will give (or not) to the system.

When the relying party receives the certiﬁcate, it

starts evaluating the information, verifying the signa-

ture and the value(s) received. At this time, and de-

pending on the policy, it will give privileges to the

Attester according to the results of the attestation, as

per step 8 in Figure 1.

In the stages where information is exchanged be-

tween parties, it is carried out through a secure com-

munication channel.

3.3 Implementation Details

The implementation of CHARRA-PM was based on

CHARRA. For instance, we reused CHARRA code,

such as calling connection and cryptographic func-

tions. CHARRA-PM introduced new functions, de-

veloped to handle the Passport Model functionality. It

should be noted that it was not a development from

scratch but an improvement to the existing code with

the endorsement of developer Michael Eckel (Eckel

and Riemann, 2021). The CHARRA-PM was coded

as Proof of Concept (PoC) to the Passport Model as

described in RATS documentation (Birkholz et al.,

2022b) and the code is available on GitHub as Open-

Source (Marques, 2022).

3.3.1 Establishing a CoAP Session with DTLS

This section will present and explain the piece of code

functions that handle CoAP sessions using DTLS

PSK and RPK.

c o a p s e s s i o n = c h a r r a c o a p n e w c l i e n t s e s s i o n p s k ( c t x ,

LISTEN RP , p o r t r p , COAP PROTO DTLS , t l s p s k i d e n t i t y ,

( u i n t 8 t

) d t l s p s k k e y , s t r l e n ( d t l s p s k k e y )

Listing 1: Function to set up PSK CoAP connection.

charra coap new client session() function

listed in List 1, is responsible for establishing a

channel through the CoAP protocol using DTLS-

PSK with Pre-Shared key. The shared key is known

to all parties involved (dtls psk key). The other

ﬁelds identify the Relying Party, the DTLS protocol

(COAP PROTO DTLS), the shared key, and its size.

c h a r r a c o a p s e t u p d t l s p k i f o r r p k (& d t l s p k i ,

d t l s r p k p r i v a t e k e y p a t h , d t l s r p k p u b l i c k e y p a t h ,

d t l s r p k p e e r p u b l i c k e y p a t h ,

d t l s r p k v e r i f y p e e r p u b l i c k e y ) ;

Listing 2: Function to set up RPK CoAP connection.

Function charra coap setup dtls pki for rpk()

listed in List 2, is responsible for establishing a chan-

nel through the CoAP protocol using DTLS-RPK

with Raw Public Keys. Here the public key of the

target device must be known. That is, the Attester

knows the public key of the Veriﬁer and the Relying

Party; Veriﬁer knows the Attester’s public key; the

Relying Party knows the public key of the Attester

and the Veriﬁer. The advantage of this approach is

related with the fact of sharing a pre-shared key be-

tween the involved entities.

3.3.2 Receipt of the Certiﬁcate by the Relying

Party

This is where the Relying Party call functions

responsible to appraise the Attestation Result -

attestetionResult.

0 1 : /

Re a d i n g CoAP d a t a

c o a p g e t d a t a l a r g e ( i n , &d a t a l e n , &d a t a ,

&d a t a o f f s e t , &d a t a t o t a l l e n ) ;

0 2 : /

c o n v e r t f ro m CBOR t o d a t a

c h a r r a u n m a r s h a l a t t e s t a t i o n p a s s p o r t ( d a t a l e n , d a t a , &

a t t r e s u l t ) ;

0 3 : /

V a l i d a t i n g s i g n a t u r e

c h a r r a v e r i f y a t t r e s u l t ( v e r i f i e r p u b l i c k e y p a t h ,

a t t r e s u l t . a t t e s t a t i o n r e s u l t d a t a ,

a t t r e s u l t . a t t e s t a t i o n s i g n a t u r e ,

a t t r e s u l t . a t t e s t a t i o n s i g n a t u r e l e n ) ;

0 4 : /

m b e d t l s f u n c t i o n r e l a t e d t o s i g n a t u r e v e r i f y

m b e d t l s p k p a r s e p u b l i c k e y f i l e (& p e e r p u b l i c k e y ,

p e e r p u b l i c k e y p a t h ) ;

c h a r r a c r y p t o h a s h (MBEDTLS MD SHA256 , a t t r e s u l t ,

a t t r e s u l t l e n , h a s h ) ;

m b e d t l s p k v e r i f y ( &p e e r p u b l i c k e y , MBEDTLS MD SHA256 ,

ha sh , 0 , s i g n a t u r e , s i g s i z e ) ;

Listing 3: Receive and appraise Attestation Results.

Listing 3 shows excerpt of code with several steps:

Step 01. Reading the data received via CoAP.

Step 02. Reverting the CBOR encoding in data that

can be processed.

CHARRA-PM: An Attestation Approach Relying on the Passport Model

353

Step 03. Veriﬁes the validity of the received signa-

ture using the Veriﬁer’s public key. This process

will generate a new hash using SHA256 that will

be employed with the public key to verify the va-

lidity of the signature.

Step 04. Functions called by step 03, coming from

the C mbedtls library used to read the public key,

generate the hash of the attestationResult and

validate the signature.

The development was based on the CoAP protocol

with endpoints for communication with the FETCH

method. This means that each endpoint in the code

is associated with a handler function that handles the

information received.

The running environment chosen for this PoC was

Docker containers. Three docker containers Attester,

Veriﬁer and Relying Party, run the same docker im-

age and map a volume in a local folder on the host

with the binaries. The docker container image was

based on the ofﬁcial tmp2software repository (TCG,

2022a).This docker implements the TPM 2.0 Simula-

tor Development Environment simulating a TPM en-

vironment.

3.4 Data Structures

A Proof of Concept to validate CHARRA-PM has de-

veloped steps 6, 7 and 8 of ﬁgure 1. This section aims

to show and explain the PoC running process using

screenshots.

The PoC consists of three different devices, each

running its isolated environment in a Docker con-

tainer sharing the same internal network. When the

Attester starts, two CoAP endpoints ar createed using

the FETCH method: attest and result. The endpoint

attest is where the Veriﬁer requests evidence and the

endpoint result is where the Veriﬁer will send the at-

testation result back to the Attester. The Relying Part

also conﬁgures an endpoint where the Attestation Re-

sult, from the Attester, will be received.

When the Veriﬁer starts, it creates a CoAP connec-

tion with the Attester, in this case using the IP address

192.168.1.2. Then it creates an attestation request in-

dicating what it needs (claims) as a response. Then

creates the CoAP message (encoded in CBOR), sends

it and wait for the Attester’s response.

4 EVALUATION AND RESULTS

4.1 Evaluation Scenario & Methodology

The evaluation scenario includes the Veriﬁer, the At-

tester and the Relying Party components, running

as docker containers. Each component has speciﬁc

CoAP endpoints that are exported to be used other

components/entities.

To assess the performance of the CHARRA-PM

PoC, we consider the time required to execute each

step in the attestation process. This measurement also

allowed us to quantify the impact of the additional

steps that were introduced with CHARRA-PM.

Attester Veriﬁer

generateClaims(attestingEnvironment)

==> claims, eventLog

requestAttestation(handle,

authSecIDs,claimSelection)

collectClaims(claims, claimSelection)

==> collectedClaims

generateEvidence(handle, authSecIDs,

collectedClaims)

==> evidence

evidence,eventLogs

appraiseEvidence(evidence,

eventLogs,refValues)

attestationResults

Relying

Party

attestationResults(evidence,results)

appraiseResults

(results)

Time #1

Time #2

Time #3

Time #4

Time #5

Time #6

Figure 2: Times measurement interactions.

Looking the ﬁgure 2 helps us understand which

process steps were measured. Each step was mea-

sured by capturing the time registered by the CPU

clock before and immediately after execution. For

the time measurement, the clock() function of the

time.h C library language was our choice. This

function returns the number of elapsed clock pulses

since it was called. To get the number of seconds

used by the CPU, one needs to divide by the num-

ber of CPU ticks per second (CLOCKS PER SEC).

CLOCKS PER SEC is the macro responsible for stor-

ing the number of pulses per second of the machine’s

processor on which the program is being executed

(Puttnies et al., 2020).

For different executions the times go up or down

regardless of the use of encryption using the DTLS

protocol (PSK or RPK).

Times were computed for the remote functions -

libraries calls and the total execution time of the local

ICISSP 2023 - 9th International Conference on Information Systems Security and Privacy

354

functions, which are part of the execution code.

Times were computed for the remote functions,

which are called by external libraries, and the total

execution time of the local functions that correspond

to the functions of the programs.

Line 06 - accumulates the time spent in the func-

tion it is running on. This will be the total value of the

running function;

To test different policies, two types of attestation

were considered:

Good Attestation. The Attester sends a correct attes-

tation to the Veriﬁer. For instance the values in the

PCR of TPM were correctly sent by the Attester,

corresponding the to ones expected by the Veri-

ﬁer.

Bad Attestation. The Attester sends an incorrect at-

testation to the Veriﬁer. In such case wrong val-

ues of the PCR were sent, thus not corresponding

to the ones expected by the Veriﬁer. Such type of

attestation result denies the evidence, thus invali-

dating the passport.

To assess the functionality of the CHARRA-PM, be-

sides the timing metrics, traces with the exchange

CoAP messages were collected to verify communi-

cations between the entities Attester↔Veriﬁer, and

Attester↔Relying Party. the collection of such traces

also aimed to check if the encryption mechanisms of

DTLS-PSK and DTLS-RPK function properly.

4.2 Results

The measured results take into account the steps

shown in ﬁgure 2. They are related to the execu-

tion of the CoAP protocol using DTLS PSK ver-

sus DTLS RPK and the overhead in the CHARRA-

PM implementation. The total processing time of

Figure 3: Average execution time per approaches.

CHARRA-PM implementation increases the execu-

tion time, as illustrated in Figure 3. This re-

sult was expected due to the additional interac-

tions between the Veriﬁer↔Attester, and between the

Attester↔Relying Party. Besides the communication

processes with the CoAP endpoints, CHARRA-PM

introduced additional functionalities like the signature

of the attestation.

Step 4 corresponds to the attestation signature,

which introduces an higher impact, when compared to

the remaining steps. The development of CHARRA

does not consider the signature of the attestation, the

data packaging time and its transmission to the At-

tester. This step, besides having the higher average

times also have an higher variation, mainly due to the

signature, packaging and transmission processes. In-

deed, this is one of the steps that contributes to the

distinction of performance between CHARRA and

CHARRA-PM, as illustrated in Figure 4.

CHARRA-PM is the only approach implement-

ing the appraising results, corresponding to step 6. In

such step the Relying Party veriﬁes the attestation re-

sult and enforces the policies as conﬁgured by the Re-

lying Party Owner.

The employment of distinct approaches for DTLS

has not a substantial performance distinction between

DTLS-PSK and DTLS-RPK. The most clear distinc-

tion is on step 4, where the RPK as a asymmetric ap-

proach introduces higher times. Also, since the num-

ber of entities included in CHARRA-PM is higher

the RPK also tends to present an higher impact, as

demonstrated in Figure 4.

Figure 4: Overhead per Implementations.

Another observable point is about the total over-

head between CHARRA and CHARRA-PM as pic-

tured in ﬁgure 4. The results put in evidence that

CHARRA-PM introduces more overhead, as referred

and illustrated. It should be noticed that this overhead

is justiﬁed by the fact of involving a third entity - Re-

lying Party to allow the application of policies.

The difference between the use of PSK and RPK

CHARRA-PM: An Attestation Approach Relying on the Passport Model

355

is almost negligible, since there is not a pattern. In

some steps the RPK takes longer (step 4, 5) in ﬁg-

ure 3, while PSK takes longer in other step 6. RPK

has the advantage of not requiring a full PKI infras-

tructure (Gonzalez Robles, 2015), and thus might be

suitable to scenarios with low complexity, which also

is inline with the PSK model.

5 CONCLUSIONS

This work presented the implementation of the

CHARRA-PM with support for the Passport Model,

This model uses a trusting third party to grant access

to devices that have a certiﬁcate validated by a ver-

ifying party. The choice of the Passport Model over

the Background-check Model was due to the interpre-

tation of the number of requests and trafﬁc that the

Relying Party would have to support in this model,

where the Relying Party is the centre of requests, pos-

sibly making it a more robust device.

CHARRA-PM can be used as a source of study

and knowledge for implementations of domestic IoT

networks, where the Relying Party can be software

on the router. Tests show that it is necessary to inves-

tigate the delay in create the attestation results. We

believe that the implementation should be improved,

but as a PoC, the times are acceptable since it is one of

the essential processes. As a next step, a compelling

extension to this PoC would be the insertion of a pol-

icy provider for Attestation Results, the Relying Party

Owner, adding more reliability and integrity without

adding structural complications to the model.

ACKNOWLEDGEMENTS

This work was supported by the project ARCADIAN-

IoT project, which has received funding from the Eu-

ropean Union’s Horizon 2020 research and innovation

programme under grant agreement No 101020259.

REFERENCES

Birkholz, H., Eckel, M., Pan, W., and Voit, E. (2022a).

Reference Interaction Models for Remote Attes-

tation Procedures. Internet-Draft draft-ietf-rats-

reference-interaction-models-05, Internet Engineer-

ing Task Force. Work in Progress.

Birkholz, H., Thaler, D., Richardson, M., Smith, N., and

Pan, W. (2022b). Remote attestation procedures archi-

tecture. Internet-Draft draft-ietf-rats-architecture-15,

Internet Engineering Task Force. Work in Progress.

Dushku, E., Rabbani, M. M., Conti, M., Mancini, L. V., and

Ranise, S. (2020). SARA: Secure Asynchronous Re-

mote Attestation for IoT Systems. IEEE Transactions

on Information Forensics and Security, 15.

Eckel, M. and Riemann, T. (2021). Userspace software in-

tegrity measurement. ARES 21. Association for Com-

puting Machinery.

Fraunhofer (2021). Fraunhofer-SIT/charra: Proof-

of-concept implementation of the ”Challenge/Re-

sponse Remote Attestation” interaction model of

the IETF RATS Reference Interaction Models for

Remote Attestation Procedures using TPM 2.0.

https://github.com/Fraunhofer-SIT/charra.

Gonzalez Robles, A. (2015). M2m and mobile communica-

tions: an implementation in the solar energy industry

(dissertation). Technical report.

IoT Analytics (2022). State of iot 2022: Number of con-

nected iot devices growing 18%.

Kettani, H. and Wainwright, P. (2019). On the top threats

to cyber systems. In 2019 IEEE 2nd international

conference on information and computer technologies

(ICICT), pages 175–179. IEEE.

Marques, A. (2022). CHARRA Passport

Mode (CHARRA-PM) - Source Code.

https://github.com/aamarques/CHARRA-PM.

Martin, E. D., Kargaard, J., and Sutherland, I. (2019). Rasp-

berry Pi Malware: An Analysis of Cyberattacks to-

wards IoT Devices. 10th International Conference

on Dependable Systems, Services and Technologies,

DESSERT 2019, pages 161–166.

Puttnies, H., Danielis, P., Sharif, A. R., and Timmer-

mann, D. (2020). Estimators for time synchroniza-

tion—survey, analysis, and outlook. IoT, 1.

Rabbani, M. M., Vliegen, J., Winderickx, J., Conti, M., and

Mentens, N. (2019). SHeLA: Scalable Heterogeneous

Layered Attestation. IEEE Internet of Things Journal.

TCG (2022a). Repository of metadata and scripts used

to generate the container images used by the vari-

ous tpm2-software projects. https://github.com/tpm2-

software/tpm2-software-container.

TCG (2022b). The source repository for the trusted plat-

form module (tpm2.0) tools. https://github.com/tpm2-

software/tpm2-tools.

ICISSP 2023 - 9th International Conference on Information Systems Security and Privacy

356