Attestation with Constrained Relying Party
Mariam Moustafa
2,3 a
, Arto Niemi
1 b
, Philip Ginzboorg
1 c
and Jan-Erik Ekberg
1
1
Huawei Technologies Oy, Helsinki, Finland
2
Aalto University, Espoo, Finland
3
Denmark Technical University, Copenhagen, Denmark
Keywords:
Remote Attestation, Device Security, Model Checking.
Abstract:
Allowing a compromised device to e.g., receive privacy-sensitive sensor readings carries significant privacy
risks, but to implement the relying party of a contemporary attestation protocol in a computationally con-
strained sensor is not feasible, and the network reach of a sensor is often limited. In this paper, we present a
remote platform attestation protocol suitable for relying parties that are limited to symmetric-key cryptography
and a single communication channel. We validate its security with the ProVerif model checker.
1 INTRODUCTION
Remote attestation allows a device’s security state to
be validated remotely (Coker et al., 2011). The attes-
tation evidence is remotely appraised by a verification
service, typically by matching measurements reported
in the evidence against trusted reference values. Se-
curely transmitting the attestation challenge, evidence
and results is the task of a remote attestation protocol.
The protocol must provide at least message integrity,
freshness and origin authentication, as well as resis-
tance against relay attacks.
Remote attestation is today deployed commer-
cially on servers and high-end consumer devices such
as smartphones and PCs (Niemi et al., 2023). Stan-
dardization is also progressing, holding promise of in-
teroperability in the future (Birkholz et al., 2023). On
constrained devices, remote attestation is still rarely
used, despite an abundance of proposals from both
academia (Johnson et al., 2021) and industry (TCG,
2021; Hristozov et al., 2022). This stems from the
constrained devices’ lack of computing power and
memory, which makes them incapable of perform-
ing the public-key cryptography required by most re-
mote attestation protocols. Proposed protocols have
focused on enabling powerful devices to validate the
security of constrained ones.
In this paper, we consider the reverse situation:
how can a constrained device confirm the security
state of the system it is interacting with? A sen-
a
https://orcid.org/0009-0003-3046-8675
b
https://orcid.org/0000-0003-3118-4511
c
https://orcid.org/0000-0003-4579-3668
sor may measure data that reveals information of the
user’s illnesses or lifestyle: releasing such informa-
tion to another device without first validating the in-
tegrity of the receiving software may result in a pri-
vacy violation. Similarly, a key tag should not trans-
fer key material to a malware-infested smartphone. In
such settings, the constrained device operates as the
relying party in attestation protocol – a visualization
of this is shown in Fig. 1.
The IETF RFC 7228 standard (Bormann et al.,
2014) defines a sensor-class device to have less than
10 KB data and less than 100 KB code; too little
for asymmetric cryptography even if performance and
battery consumption concerns are ignored. We work
under the assumptions that the relying party device a)
does not support public-key cryptography; and b) can
only communicate with an external attestation veri-
fier via the attester, which makes man-in-the-middle
attacks on protocol messages a specific concern.
We present to our knowledge the first remote at-
testation protocol with the following contributions:
1. We analyze a less-considered attestation flow,
where constrained devices need to attest a system
before becoming part of its operation.
2. We provide an attestation protocol design where
the relying party does not need public-key cryp-
tography and can participate via a single insecure
channel it has with the attester.
3. We validate the security of our protocol using for-
mal model checking and provide a working proof-
of-concept, whose performance metrics confirm
the protocol’s viability in practice.
Moustafa, M., Niemi, A., Ginzboorg, P. and Ekberg, J.
Attestation with Constrained Relying Party.
DOI: 10.5220/0012319300003648
Paper published under CC license (CC BY-NC-ND 4.0)
In Proceedings of the 10th International Conference on Information Systems Security and Privacy (ICISSP 2024), pages 701-708
ISBN: 978-989-758-683-5; ISSN: 2184-4356
Proceedings Copyright © 2024 by SCITEPRESS – Science and Technology Publications, Lda.
701

OR
Internet
Request sensor data
Relying party
Sensor
Attester
Mobile Phone
Verifier
Server
Reference value
DB
Sensor data
Attestation protocol - Passport model
a) Attestation request
d) Attestation result
c) Attestation result
b) Evidence
Figure 1: A constrained sensor operating as a relying party:
The security of a mobile phone is verified as a precondition
for transmitting sensor readings. Note the absence of direct
communication between RP and verifier.
2 BACKGROUND
2.1 Remote Attestation
Following the IETF and Trusted Computing Group
attestation architectures (Birkholz et al., 2023; TCG,
2021), remote attestation protocols involve three ac-
tive participants: attester, verifier and relying party
(RP). The RP wants to know the state of the attester
before making a trust decision, such as granting ac-
cess to a resource. The attester is equipped with a
trustworthy mechanism (Coker et al., 2011) such as a
Trusted Execution Environment (TEE), (Gunn et al.,
2022) which collects and cryptographically protects
attestation evidence. The evidence may, for example,
include boot-time code measurements or whether the
current user has been authenticated. The verifier ap-
praises the evidence and issues a verdict (attestation
results) to the relying party.
Two interaction patterns are commonly used in
remote attestation: the background check and the
passport model (Birkholz et al., 2023). The lat-
ter, illustrated in Fig. 1, is better suited to resource-
constrained RP, as it requires only a single communi-
cation link in the RP. The attester carries the attesta-
tion results produced by the verifier as a “passport”,
which the attester stores and then presents to the RP
when needed. The attester may also obtain fresh re-
sults from the verifier if the current results are older
than what the RP accepts.
2.2 Related Work
The SlimIoT protocol (Ammar et al., 2018) performs
swarm attestation where the entities being attested are
a ‘swarm’ of constrained IoT devices. The opetation
is based on broadcast and selective evidence aggre-
gation among attesters. SCAPI (Kohnh
¨
auser et al.,
2017) is another swarm-based attestation protocol,
leveraging a Trusted Execution Environment (TEE)
for tamper-resistance. Additionally each attester has
shared keys with all other attesters in the network
which adds memory footprint and power consumption
overhead. J
¨
ager et al. propose a protocol (J
¨
ager et al.,
2017) where the server sends a nonce as a challenge,
the attester hashes the nonce with the key being at-
tested, and the verifier checks that the hash value is as
intended – limiting the attestation result to a key pos-
session argument. AAoT (Feng et al., 2018) is based
on physical unclonable functions (PUFs) to generate
the symmetric keys between the attester and verifier.
In the SIMPLE protocol (Ammar et al., 2020), the
verifier generates a nonce, the value of a valid soft-
ware state, and the MAC tag of these values. The
attester verifies the tag, computes its own state, and
checks whether the computed state matches what the
verifier sent.
These protocols only cater to the case where the
attester is the constrained device. This is evidenced
by the lack of separation between verifier and RP
roles. Also, some of the protocols require synchro-
nized clocks, or special hardware, like PUFs, to be
present in the constrained device.
3 REQUIREMENTS
3.1 Functional Requirements
To ensure the viability of our protocol in the use case
where the relying party (RP) is a constrained device,
we require the following:
FR1. The RP can be implemented with < 10 KB
of code, including cryptography, but excluding the
transport protocol such as UDP or Bluetooth.
FR2. The RP does not need public-key cryptogra-
phy.
FR3. The RP only needs to communicate with the
attester.
3.2 Security Requirements
We assume the Dolev-Yao attacker model: the at-
tacker can read, intercept, insert, relay and modify
protocol messages, but is not able to guess secret keys
or to break cryptographic primitives (Dolev and Yao,
1983). The attacker can use uncompromised devices
as oracles and pretend to be any of the participating
ICISSP 2024 - 10th International Conference on Information Systems Security and Privacy
702

entities, but is not able to compromise the verifier or
the TEE of the attester.
The attacker’s goal is to trick an uncompromised
RP into trusting a compromised device. The uncom-
promised RP is assumed to execute its part of the
protocol correctly, so it will only trust an attester af-
ter receiving a valid attestation result that the RP be-
lieves to describe the security state of that particu-
lar attester. Thus, we formulate our security require-
ments in terms of the security of the attestation re-
sults:
SR1. Freshness of attestation results: the RP can
detect whether an attestation result was generated
in a particular run of the protocol.
SR2. Binding of attestation results to a particu-
lar attester: the RP can detect whether the verifier
generated the result based on its appraisal of a par-
ticular attester.
SR3. Integrity of attestation results: the RP can
detect whether an attestation result has been gen-
erated by a particular verifier, and whether the re-
sult has been modified in transit.
SR4. Confidentiality of attestation metrics and at-
testation results: the attester measurements and
results are encrypted to ensure privacy.
4 PROTOCOL DESIGN
Our protocol uses the passport model discussed in
Section 2, with the provision that attestation results
cannot be reused and are bound to a particular relying
party. Accordingly, we call our protocol Attestation
Protocol for Constrained Relying Parties – Live Pass-
port Model, or APCR-LPM for short.
Fig. 2 illustrates the protocol steps. For sym-
metric encryption (denoted senc and sdec), we use
a cipher that provides authenticated encryption, such
AES-CCM. Thus the sdec operation either returns
the decrypted plaintext or, if integrity violation was
detected, an error. Similarly, signature validation
(checksig(sig, m, PK)) either returns the signed mes-
sage or an error. The aenc, and adec are encryption
and decryption operations of a public-key authenti-
cated encryption scheme, e.g., ECIES (3GPP, 2023).
The protocol involves three principals:
• Relying Party RP: a constrained device with lit-
tle memory, supporting only symmetric-key cryp-
tography. It has a communication link with the
attester and can verify attestation results, but not
attestation evidence.
• Attester A: a non-constrained device, such as a
smartphone, that wants to prove its trustworthi-
ness to the relying party. It has a trustworthy
mechanism for evidence generation and secure
storage for secrets, such as a TEE.
• Verifier V: a non-constrained device, such as a
cloud server, trusted by both RP and attester. It
can validate and appraise the evidence sent by the
attester and is assumed to have agreed upon an ev-
idence appraisal policy with the RP.
Bootstrapping. At the start of the protocol, the rely-
ing party (RP) has symmetric keys K
A
, and K
V
, shared
with the attester and verifier, respectively. We envi-
sion three possible key distribution scenarios:
1. The relying party (e.g., wearable, smart device)
and attester belong to the same vendor. In these
cases, the key material can be installed in these
devices during manufacturing.
2. A user-based bootstrapping or pairing protocol in-
volving an out-of-band channel has been executed
by the owner of the devices, which results in a
shared key between devices.
3. The relying party (sensor) has a predefined rela-
tionship with the verifier. The verifier also takes
on the role of a key distribution center that creates
and distributes session keys to the relying party
and attester.
The attester has an asymmetric keypair
(SK
A
, PK
A
) that is uses to authenticate itself to
the verifier. The verifier is assumed to either trust
PK
A
directly or able to construct a trust chain, e.g.
with X.509 certificates, that allows it to trust PK
A
.
The RP also has an identifier id
A
for the attester A
that is a function of both K
A
and PK
A
.
The protocol steps, shown in Fig. 2 are as follows:
(1) The relying party (RP) prepares a challenge by
generating the nonce c. It encrypts c and the identifier
id
A
of the attester using K
V
(2). The nonce c acts as
a session identifier as well as a freshness value. RP
sends the challenge to the attester A, message (a). The
attester cannot read the contents of the message as it
is encrypted with a key that it does not know.
The attester’s TEE performs key attestation on the
hash of K
A
(4). By including the key attestation, the
TEE vouches that K
A
cannot be extracted from the
TEE. In step (5), the attester collects the attestation
metrics of the device and its software. Then, it en-
crypts the key attestation, collected metrics, and chal-
lenge it received from RP using PK
V
(6), signs the
encrypted evidence using its private key SK
A
(7), and
finally sends the evidence and signature to the verifier
in message (b).
Attestation with Constrained Relying Party
703

8. Ev ← checksig(δ, Ev, PK
A
)
9. (M
A
, AK(K
A
), Cha) ← adec(Ev, SK
V
)
10. (c, id
Cha
) ← sdec(Cha, K
V
)
11. h ← validateKeyAttestation(AK(K
A
))
12. id
A
← hash(h, PK
A
)
13. if (id
A
= id
Cha
):
14. R
A
← validateMetrics(M
A
)
15. Res ← senc((R
A
, c, id
Cha
), K
V
)
3. h ← hash(K
A
)
4. AK(K
A
) ← attestKey(h)
5. M
A
← collectAttestationMetrics(A)
6. Ev ← aenc((M
A
, AK(K
A
), Cha), PK
V
)
7. δ ← sign(Ev, SK
A
)
1. c ← rand({0,1}
128
)
2. Cha ← senc((c, id
A
), K
V
)
Relying Party RP
Keys: K
A
, K
V
;
id
A
← hash(hash(K
A
), PK
A
)
Verifier V
Keys: K
V
,(SK
V
, PK
V
) PK
A
a) Cha
b) Ev, δ
c) Res
16. (R
A
, c
Res
, id
Res
) ← sdec(Res, K
V
)
17. if (c = c
Res
and id
A
= id
Res
):
18. {0,1} ←validateAttestationResult(R
A
)
Attester A
Keys: K
A
, (SK
A
, PK
A
), PK
V
d) Res
Communication
secured by K
A
Figure 2: Attestation Protocol for Constrained Relying Party.
Table 1: Summary of notation.
Term Description
K
A
Shared symmetric key between A and RP.
K
V
Shared symmetric key between V and RP.
(SK
V
, PK
V
) The (secret key, public key) pair of V .
(SK
A
, PK
A
) The (secret key, public key) pair of A.
h Hash of K
A
.
c A 128-bit pseudorandom value.
M
A
The attestation metrics produced by A.
r ← rand({0, 1}
128
) Generate pseudorandom 128-bit string.
c ← senc(m, K)
Authenticated encryption
of m with shared key K.
m ← sdec(c, K)
Authenticated decryption
of c with shared key K.
c ← aenc(m, PK)
Public-key authenticated
encryption of m with public key PK.
m ← adec(c, SK)
Public-key authenticated
decryption of c with secret key SK.
sig ← sign(m, SK) Signing of m with secret key SK.
m ← checksig(sig, m, PK)
Verifying the signature of m
with key PK.
h ← hash(m) Computing the hash of m.
AK(K) ← attestKey(h) Attestation of key K by TEE.
h ← validateKeyAttestation(AK(K))
Validate that key K is
attested by TEE.
M ← collectAttestationMetrics(E)
Compute the attestation
metrics of entity E.
R ← validateMetrics(M)
Compute attestation results R
based on metrics M.
{0, 1} ← validateAttestationResult(R)
Determine trustworthiness
based on attestation results R.
The verifier verifies the signature of the evidence
using PK
A
(8) and decrypts the evidence with SK
V
.
Then it decrypts the challenge to extract c and h (10).
In step (11), it verifies the key attestation and com-
putes its own version of the attester’s id
A
based on
the public key it has used for checking the signature
(12). In step (13), the verifier checks whether id
A
re-
ceived in the challenge is equal to that it has com-
puted. If any of those steps fail, the verifier aborts
the protocol. Based on the metrics, the verifier gener-
ates a verdict or attestation result for RP (14) and en-
crypts the attestation results together with the nonce
c and id
Cha
using K
V
(15) resulting in the ciphertext
Res. The verifier sends Res to the attester in message
(c). The attester forwards Res to RP in message (d).
The value id
Cha
is included in Res as an indicator to
RP that the verifier has verified the evidence of the
attester with identity id
Cha
. It also includes the de-
crypted challenge (c, id
Cha
) to maintain the freshness
of the message and to indicate to RP that the intended
verifier has received the challenge and decrypted it.
(16) RP decrypts Res and checks that the values
of c
Res
and id
Res
are equal to the ones it sent in the
challenge (17). RP can then process the attestation
result to determine the attester’s state (18).
Subsequent, application-specific communication
between RP and attester depends on the result of step
(18); this communication is secured using K
A
.
5 SECURITY ANALYSIS
5.1 Discussion
APCR-LPM fulfills the security requirements of Sec-
tion 3.2 as follows:
SR1 (Freshness of Attestation Results). The relying
ICISSP 2024 - 10th International Conference on Information Systems Security and Privacy
704

party (RP) includes a nonce c in the challenge and the
verifier is required to include the same nonce in the at-
testation results. The nonce is a pseudorandom num-
ber that is generated fresh in every run of the protocol.
In step (17), the RP checks whether the nonce in the
received attestation result matches the nonce it sent
in the last challenge. For a replayed result, the check
will fail. The RP could also use a protocol timeout to
prevent the acceptance of obsolete results.
SR2 (Binding of Attestation Results to a Particular
Attester). The RP binds the challenge Cha to the
identity of a particular attester by including the value
id
A
= hash(hash(K
A
), PK
A
). The verifier knows PK
A
,
the public key of the attester’s TEE, and receives
hash(K
A
) from the key attestation included in the at-
testation evidence, so it can compute a reference id
A
.
By verifying the evidence signature with PK
A
in step
(8) and by comparing the self-computed id
A
against
the one decrypted from Cha in step (13), the verifier
can detect whether the evidence was generated by a
TEE that the verifier trusts and that belongs to the
attester the RP intended. Since we assume the ev-
idence signing keys (SK
A
) to be unique to the TEE
instance and unextractable, the verifier can validate
that the evidence was generated by the particular TEE
that is identified with PK
A
. The verifier includes c
and the validated id
A
in the results, allowing the RP
to check, in step (17), that they match the values it
sent in the challenge. This fulfills the requirement,
preventing relay attacks, sometimes called Cuckoo at-
tacks (Parno, 2008; Dhar et al., 2020), a common is-
sue with remote attestation protocols (Niemi et al.,
2021; Aldoseri et al., 2023).
SR3 (Integrity of Attestation Results). The RP checks
the integrity of the attestation result by decrypting, in
step (16), the result message Res with the shared key
(K
V
) it has with the verifier. Since Res is protected
with authenticated encryption, using a key (K
V
) that
the attacker does not know, the RP can detect whether
the message was modified after encryption or gener-
ated by a different verifier. This fulfills the integrity
requirement. Finally, in step (18), the RP can evalu-
ate the trustworthiness of the attester it identified in
the challenge by examining the verifier’s verdict that
it decrypts from Res.
SR4 (Confidentiality of Attestation Metrics and At-
testation Results). The confidentiality of the attesta-
tion metric is guaranteed with public key cryptogra-
phy, where the evidence is encrypted using the veri-
fier’s public key PK
V
in step (6). Only the verifier can
read the evidence using its private key SK
V
. The at-
testation result, on the other hand, is encrypted using
the symmetric key K
V
the verifier shares with the re-
lying party, step (15). Only the parties who know K
V
can read the attestation results.
5.2 Formal Model Checking
We used the ProVerif tool (Blanchet et al., 2018) to
formally model our protocol and verify its security
properties. Queries describing the desired security
properties are included in the ProVerif model. These
queries are written in terms of ProVerif events which
mark certain stages reached by the protocol and have
no effect on the actual behavior of the model. The
tool attempts to explore all possible execution paths of
the protocol, trying to find a path where a query fails.
ProVerif assumes the Dolev-Yao attacker model and
can perform replay, man-in-the-middle and spoofing
(impersonation) attacks, which aligns with the adver-
sary model in Section 3.2. Our ProVerif code is avail-
able in GitHub
1
.
The following query represents the security re-
quirements SR1, SR2, and SR3 in Section 3.2:
query PK
A
: pkey,K
A
: key,K
V
: key,R
A
: bitstring, c : nonce,
h : bitstring, id : bitstring, M
A
: bitstring,Cha : bitstring;
in j −event(relyingPartyAccepts(K
V
, R
A
, c, id))
=⇒ in j − event(relyingPartyBegins(K
V
, c, id)) &&
in j −event(attesterBegins(PK
A
, h, M
A
,Cha)) &&
in j −event(veri f ierAccepts(PK
A
, K
V
, M
A
, id, c)) &&
R
A
= validateEvidence(M
A
) &&
id = hash((h, PK
A
)) &&
Cha = senc((c, id), K
V
).
The query defines an injective correspondence be-
tween the event of the relying party (RP) accepting R
A
and all other events in the protocol. This means that
for each occurrence of the event relyingPartyAccepts
there is a distinct occurrence of all other events in the
query. The RP will only accept the protocol run if
there has been a previous run where it:
1. Initiated the protocol by sending the encrypted c
and id (relyingPartyBegins);
2. The attester has accepted this encrypted c and
id as Cha and collected attestation metrics M
A
(attesterBegins);
3. The verifier has received M
A
and decrypted Cha
(veri f ierAccepts).
There is an added constraint on the relation between
the metrics M
A
and the attestation results R
A
. This
query models the security requirements (Section 3.2)
by including c in the events for freshness, the keys for
data origin authentication and M
A
and R
A
for integrity.
M
A
is matched to both the attester and verifier event
1
https://github.com/Mariam-Dessouki/RAforConstrain
edRP/tree/apcr-paper
Attestation with Constrained Relying Party
705

and the RP will not accept the final message unless
R
A
is a function of M
A
and it has received back the
encrypted c and id it used in the first message.
In order to satisfy SR1 (freshness of attestation re-
sults), the RP subprocess simulates the protocol by
generating a new nonce c with every protocol run.
When the RP receives the value Res, it does the
following.
let (R_a:bitstring, =c , =id)=sdec(Res, K_v) in
event relyingPartyAccepts(K_v, R_a, c, id);
The RP first checks that the nonce c is the same
as the one it has sent and then it invokes the event
relyingPartyAccepts. The equal sign (before c and
id) matches the decrypted value to an already defined
value. If the received nonce does not match it an error
would occur and the event would not be invoked. For
SR3 (integrity of attestation result), the RP checks the
integrity of the received Res by using the key K
V
it
shares with the verifier to decrypt the message. If the
values of the received c and id are not equal to the sent
values then the event will not be invoked.
The following code checks the binding of the at-
testation result to a particular attester (SR2). It is ex-
ecuted after the verifier checks the signature of the
evidence.
let id = hash((h, PK_a)) in
if (id = id_cha) then
let R_a = validateEvidence(M) in
event verifierAccepts(PK_a, K_v, M, id, c);
The event veri f ierAccepts is invoked after the
verifier subprocess checks that the id value received
from the RP matches the id value it generated from
the attester’s public key, otherwise veri f ierAccepts
would not occur.
The query would fail if any of the security require-
ments are not satisfied. ProVerif was able to check all
possible protocol states and terminate. It did not find
an attack against the query defined above, i.e, the se-
curity requirements SR1, SR2 and SR3 are satisfied.
The query used to represent the security require-
ment SR4 is as follows:
query K
V
: key, id : bitstring,R
A
: bitstring, c : nonce;
attacker(R
A
) && event(relyingPartyAccepts(K
V
, R
A
, c, id))
=⇒ f alse.
The query states that the events of the attacker know-
ing the attestation result R
A
and the RP accepting the
same attestation result cannot occur together. Note
that although it is not explicitly mentioned in the
query, the query also includes the secrecy of the at-
testation metrics M
A
. The attestation results R
A
is a
function of M
A
, so even if R
A
is encrypted, an attacker
that knows M
A
can easily derive R
A
using the function
validateMetrics (see (14) in Fig. 2). ProVerif did not
find an attack on this query meaning that the attesta-
tion metrics and results are confidential, thus satisfy-
ing SR4.
6 PROOF-OF-CONCEPT
To study the feasibility of our protocol on constrained
devices, we implemented the relying party (RP) role
on the nRF5340 development kit (Nordic Semicon-
ductor, 2023). The RP was set up to communicate
with a laptop over Bluetooth. Since the main advan-
tage of the protocol is that it is suitable for constrained
RPs, only the communication between RP and the at-
tester (messages (a) and (d)) and the actions in the
relying party (steps (1, 2, 16, 17, 18)) found in Fig. 2
were implemented.
As an example use case we took the electronic
lock-and-key system, where the user wants to use his
mobile phone (instead of a NFC or Bluetooth keytag)
to open doors — in essence copying the key material
normally residing on the keytag. The computation-
ally weak keytag needs a way to attest the security
of a mobile phone before releasing any cryptographic
secrets to it. Our attestation protocol is applicable to
this setup as follows. The keytag (relying party) initi-
ates the attestation protocol over a near-field commu-
nication channel with the smartphone (attester), who
in turn relies on a network server (verifier) to prove
the security level of the TEE in the smartphone. After
successful verification of attestation results, the key-
tag transfers the door key to the smartphone TEE.
6.1 Implementation
The nRF5340 board has a 64 MHz Arm Cortex-M33
CPU, 256 KB Flash and 64 KB RAM. It supports the
Zephyr RTOS (Real-Time Operating System), an op-
erating system designed for resource constrained de-
vices. We extended Zephyr’s sample Bluetooth ap-
plication, called IPSP (Zephyr, 2023), with the im-
plementation of the key transfer protocol shown in
Fig. 3. For cryptography, we used AEC-128-CCM,
HMAC-SHA256 and PRNG from the TinyCrypt li-
brary (Intel, 2017).
As illustrated in Fig. 3, after the Bluetooth con-
nection is established, the laptop (attester) issues a
key transfer request which initiates the ACPR-LPM
protocol. The keytag (RP) generates a nonce and en-
crypts both the nonce c and id using K
V
and AES-
CCM. The resulting ciphertext, Cha, is sent over the
channel in message (a). Upon receiving that mes-
sage, the application decrypts Cha to extract c and
id. Next, the application encodes the attestation re-
ICISSP 2024 - 10th International Conference on Information Systems Security and Privacy
706

IPv6 over Bluetooth
c || id ← tc_cbc_decryption_verification(Cha, ccm_nonce, K
V
)
R
A
← simulateAttestationResults()
ccm_nonce2 ← simulateRandom()
Res ← tc_ccm_generation_encryption((c || id || R
A
),
ccm_nonce2, K
V
)
Key transfer request
d) Res, ccm_nonce2
c
Res
|| id
Res
|| R
A
← tc_cbc_decryption_verification(Res, ccm_nonce2, K
V
)
if(c
Res
= c and id
Res
= id and isValid(R
A
))
validation_res = key_material
else
validation_res = rejected_attestation
ccm_nonce3 ← tc_hmac_prng_generate(entropy, 13)
key_response ← tc_ccm_generation_encryption(validation_res,
ccm_nonce3, K
A
)
a) Cha, ccm_nonce
Key response, ccm_nonce3
entropy ← bt_hci_le_rand()
c ← tc_hmac_prng_generate(entropy, 16)
ccm_nonce ← tc_hmac_prng_generate(entropy, 13)
Cha ← tc_ccm_generation_encryption((c || id), ccm_nonce, K
V
)
Figure 3: Prototype implementation of keytag application.
sult and sends the encrypted c, id, and R
A
over the
Bluetooth channel. For attestation result, we used
the Entity attestation token Attestation Result (EAR)
(Fossati et al., 2023) emerging standard. We encoded
the EAR object using CBOR (Bormann and Hoffman,
2020) to minimize message and decoder size. De-
pending on the Res received in message (d), the key-
tag may decide to send the key material or not. In
either case, the response has the same message size to
mitigate side channel attacks.
6.2 Measurements
Compared to the original IPSP application, the RP ap-
plication requires 6 KB more flash and less than 1 KB
more RAM memory (Table 2). These figures, based
on the values reported by Zephyr at build-time, in-
clude protocol processing, code from the TinyCrypt
and zcbor libraries, and code specific to the keytag ap-
plication. To exclude Zephyr from the measurements,
we also directly measured the code size of the binaries
using the size utility. The RP implementation, includ-
ing protocol processing and code that calls TinyCrypt
or zcbor, required around 2.6 KB of extra code in the
binaries.
Table 2: Memory footprint of applications (in bytes).
Memory Type IPSP Sample RP Application
Total Flash 241320 247320 (+6000)
Total RAM 60280 61184 (+904)
Application Code Size 1792 4396 (+2604)
Overall, the “keytag” transfers 174 bytes: 1) 55
bytes Cha, which includes 16 bytes c, 16 bytes id, 13
bytes AES-CCM nonce, and 10 bytes MAC; and 2)
119 bytes encrypted key material in the last message.
Reducing Cha size to 16 bytes (one AES block) and
analyzing the security implications is left for the fu-
ture. The “keytag” receives 194 bytes: 20 bytes key
transfer request in the first message, and 174 bytes en-
crypted attestation results in message (d). To test the
time overhead of APCR-LPM, we did three experi-
ments, described below. In each experiment the tim-
ing of operations was repeatedly measured 10 times
on the attester (laptop) side.
1. Baseline Communication Cost. We measured the
time between attester sending a key request and it
receiving a key response from the RP, without at-
testation messages (a) and (d), and without cryp-
tographic operations in the RP. This takes 93 ms
on the average.
2. Protocol Cost. We recorded the elapsed times (i)
from when the attester sends a key transfer re-
quest to when it receives message (a), and (ii)
from sending message (d) to it receiving key re-
sponse and the ccm nonce3. The time required
for the protocol steps in the attester was omitted.
The sum of (i) and (ii), which is 289 ms on av-
erage, measures the cost of overall protocol com-
munication and the Cost of protocol processing in
the resource-constrained RP device.
3. Protocol Communication Cost. We sent the same
number and size of messages as in experiment (2),
but omitted other processing such as message de-
coding and cryptography. The result was 281 ms
on average, 7 ms less than the full protocol cost.
We conclude that APCR-LPM has a time over-
head of about 200 ms, compared to insecure commu-
nication with the RP. Most of the overhead is due to
the additional round-trip, rather than encryption, de-
cryption, and attestation result parsing in the RP.
7 CONCLUSIONS
In this paper, we presented the design of APCR-LPM,
an attestation protocol that addresses the neglected
use case where the beneficiary of attestation, the re-
lying party, is a constrained device, capable only of
symmetric key operations and able to communicate
only with the device whose trustworthiness it wants
to evaluate. We established the protocol’s security via
analysis and model checking using ProVerif. Our ex-
periments show that the relying party side of the pro-
tocol can be implemented with around 6 KBs of code.
A drawback of APCR-LPM is that it requires dis-
tribution of symmetric keys prior to protocol run. In
the the extended version of our paper (Moustafa et al.,
2023), we describe a variant of the protocol where the
Attestation with Constrained Relying Party
707

shared key is generated by the verifier and distributed
to RP and attester during the protocol run.
An important feature of our approach is the sep-
aration of roles between the relying party and veri-
fier, which delegates the processing of attestation evi-
dence to a third device, critically decreasing the power
and memory requirements on the relying party device.
The relying party only needs to process attestation re-
sult, the verifier’s simple, standard-format verdict on
the evidence.
REFERENCES
3GPP (2023). Security architecture and procedures for 5G
system. Technical Specification TS 33.501 V18.2.0,
3GPP.
Aldoseri, A., Clothia, T., Moreira, J., and Oswald, D.
(2023). Symbolic modelling of remote attestation pro-
tocols for device and app integrity on Android. In
Proceedings of the 2023 ACM on Asia Conference
on Computer and Communication Security, ASIA
CCS’23, pages 218–231, New York, NY, USA. As-
sociation for Computer Machinery.
Ammar, M., Crispo, B., and Tsudik, G. (2020). SIM-
PLE: A remote attestation approach for resource-
constrained IoT devices. In 2020 ACM/IEEE 11th
International Conference on Cyber-Physical Systems
(ICCPS), pages 247–258.
Ammar, M., Washha, M., Ramabhadran, G. S., and Crispto,
B. (2018). SlimIOT: Scalable lightweight attestation
protocol for the internet of things. In 2018 IEEE Con-
ference on Dependable and Secure Computing (DSC).
IEEE.
Birkholz, H., Thaler, D., Richardson, M., Smith, N.,
and Pan, W. (2023). Remote attestation procedures
(RATS) architecture. RFC 9334.
Blanchet, B., Smyth, B., Cheval, V., and Sylvestre, M.
(2018). ProVerif 2.00: automatic cryptographic pro-
tocol verifier, user manual and tutorial.
Bormann, C., Ersue, M., and Keranen, A. (2014). Termi-
nology for constrained-node networks. RFC 7228.
Bormann, C. and Hoffman, P. (2020). Concise binary object
representation (CBOR). RFC 8949.
Coker, G., Guttman, J., Loscocco, P., Herzog, A., Millen,
J., O’Hanlon, B., Ramsdell, H., Segall, A., Sheehy, J.,
and Sniffen, B. (2011). Principles of remote attesta-
tion. International Journal of Information Security,
10:63–81.
Dhar, A., Puddu, I., Kostiainen, K., and Capkun, S. (2020).
ProximiTEE: Hardened SGX attestation by proximity
verification. In Proceedings of the Tenth ACM Confer-
ence on Data and Application Security and Privacy,
CODASPY ’20, page 5–16, New York, NY, USA. As-
sociation for Computing Machinery.
Dolev, D. and Yao, A. C. (1983). On the security of pub-
lic key protocols. IEEE Transactions on Information
Theory, 29:198–208.
Feng, W., Qin, Y., Zhao, S., and Feng, D. (2018). AAoT:
Lightweight attestation and authentication for low-
resource things in IoT and CPS. Computer Networks,
134:167–182.
Fossati, T., Voit, E., and Trofimov, S. (2023). EAT Attesta-
tion Results. https://www.ietf.org/archive/id/draft-f
v-rats-ear-01.html. Last Accessed: 17-07-2023.
Gunn, L., Asokan, N., Ekberg, J.-E., Liljestrand, H.,
Nayani, V., and Nyman, T. (2022). Hardware platform
security for mobile devices. Foundations and Trends
in Privacy and Security, 3:214–394.
Hristozov, S., Wettermann, M., and Huber, M. (2022).
A TOUCTOU attack on DICE attestation. In CO-
DASPY’22: Proceedings of the Twelft ACM Confer-
ence on Data and Application Security and Privacy,
pages 226–235, New York, NY, USA. Association for
Computing Machinery.
Intel (2017). TinyCrypt Cryptographic Library. https://gith
ub.com/intel/tinycrypt.
J
¨
ager, L., Petri, R., and Fuchs, A. (2017). Rolling DICE:
Lightweight remote attestation for COTS IOT hard-
ware. In ARES’17: Proceedings of the 12th Interna-
tional Conference on Availability, Reliability and Se-
curity, ARES ’17, New York, NY, USA. Association
for Computing Machinery.
Johnson, W. A., Ghafoor, S., and Prowell, S. (2021). A
taxonomy and review of remote attestation schemes in
embedded systems. IEEE Access, 9:142390–14210.
Kohnh
¨
auser, F., B
¨
uscher, N., Gabmeyer, S., and Katzen-
beisser, S. (2017). SCAPI: A scalable attestation pro-
tocol to detect software and physical attacks. In Pro-
ceedings of the 10th ACM Conference on Security and
Privacy in Wireless and Mobile Networks, pages 75–
86.
Moustafa, M., Niemi, A., Ginzboorg, P., and Ekberg, J. E.
(2023). Attestation with constrained relying party.
arXiv preprint, abs/2312.08903.
Niemi, A., Bop, V. A. B., and Ekberg, J.-E. (2021). Trusted
Sockets Layer: A TLS 1.3 based trusted channel pro-
tocol. In Tuveri, N., editor, Secure IT Systems: 26th
Nordic Conference, NordSec 2021, Lecture Notes in
Computer Science, pages 175–191, Cham. Springer
International Publishing.
Niemi, A., Nayani, V., Moustafa, M., and Ekberg, J. E.
(2023). Platform attestation in consumer devices. In
2023 33rd Conference of Open Innovations Associa-
tion (FRUCT), pages 198–209. IEEE.
Nordic Semiconductor (2023). nRF5340 DK. https://www.
nordicsemi.com/Products/Development-hardware/nR
F5340-DK. Last Accessed: 17-07-2023.
Parno, B. (2008). Bootstrapping trust in a “trusted” plat-
form. In Proceedings of the 3rd Conference on Hot
Topics in Security, HOTSEC’08, USA. USENIX As-
sociation.
TCG (2021). DICE Attestation Architecture. Trusted Com-
puting Group. Version 1.0, revision 0.23.
Zephyr (2023). Bluetooth: IPSP Sample. https://docs.zep
hyrproject.org/latest/samples/bluetooth/ipsp/READM
E.html. Last Accessed: 17-07-2023.
ICISSP 2024 - 10th International Conference on Information Systems Security and Privacy
708