Secure Remote Credential Management withMutual Attestation for Constrained Sensing

Platforms with TEEs

Carlton Shepherd, Raja N. Akram, and Konstantinos Markantonakis

Information Security Group, Royal Holloway, University of London, Surrey, UK{carlton.shepherd.2014, r.n.akram, k.markantonakis}@rhul.ac.uk

Abstract. Trusted Execution Environments (TEEs) are rapidly emerg-ing as the go-to root of trust for protecting sensitive applications anddata using hardware-backed isolated worlds of execution – surpassing re-lated initiatives, such as Secure Elements, for constrained devices. TEEsare envisaged to provide sensitive IoT deployments with robust assur-ances regarding critical algorithm execution, tamper-resistant credentialstorage, and platform integrity via remote attestation. However, the chal-lenge of remotely managing credentials between TEEs remains largely un-addressed in existing literature. Here, credentials must remain protectedagainst untrusted system elements and transmitted over a secure channelwith bi-directional trust assurances of their authenticity and operatingstates. In this paper, we present novel protocols for four key areas ofremote TEE credential management using mutual attestation: backups,updates, migration, and revocation. The proposed protocols are agnosticto the TEE implementation and network architecture, developed in linewith the requirements and threat model of IoT TEEs, and subjected toformal symbolic verification using Scyther, which found no attacks.

1 Introduction

The Internet of Things (IoT) – the notion that everyday objects will monitorand potentially actuate upon the environment – is anticipated to significantlybenefit multitudinous domains, including manufacturing [6], logistics [12], healthand social care [37], financial services [35], and within the home [25]. Estimates byStatista [38] forecast the number of installed IoT devices to reach 30.73bn in 2020and rising to 74.55bn by 2025, while a 2017 report by IDC [20] projects globalIoT spending to grow by a compound annual rate of 15.6% until 2020, reaching$1.29tn (USD). PwC [30] reported that investment in business-to-business (B2B)IoT deployments will reach $832bn in 2020, from $215bn in 2015.

IDC [20] report the largest IoT investments originated from manufactur-ing ($178bn), focussing on field servicing and asset management; transportation($78bn), primarily for monitoring and tracking the conditions and locations offreight; and utilities ($69bn), for electricity and gas infrastructure monitoring.Industrial IoT (IIoT) is largely motivated by the desire for greater automation,

arX

iv:1

804.

1070

7v1

[cs

.CR

] 2

7 A

pr 2

018

2 Shepherd, Akram and Markantonakis.

more intelligent fault detection and reporting, and improved monitoring of en-vironmental and equipment conditions, such as optimising climate controls andsystem resource consumption. IIoT ultimately aims to enhance the informationprovided to decision-makers from factory-level, ‘on-the-floor’ processes in orderto maximise capital and labour allocation – dubbed the ‘fourth industrial revo-lution’ by the German Industrie 4.0 initiative [23]. Capgemini recently estimatedthat IIoT may add up to $1.5tn to the global economy by 2022 [6].

Moreover, global investment in ‘smart city’ programmes is anticipated to risefrom $80bn to $135bn between 2018–2021 [21]. Smart cities are augmented urbanenvironments that use measurements from in situ sensing platforms to improveoperational efficiency and public safety. In 2014, the Chicago Department of In-novation and Technology [7] deployed a city-wide network of sensor-equippedmicrocontrollers mounted on street lights to monitor carbon monoxide, nitrogendioxide and particulate measurements to track air quality and warn those withrespiratory conditions. The State of Gujarat, India, recently trialled flood pred-ication from measurements collected from river bank sensors, which alerted citi-zens of potential floods using automated SMSs, phone calls, and local sirens [36].Smart cities also incorporate assisted living for vulnerable users, e.g. fall detec-tion systems and transmission of pollen warnings [37]; parking systems thatuse occupancy sensors to inform local drivers of vacant spaces to limit conges-tion [19]; and transport management systems that use occupancy and locationsensors to predict abnormal congestion levels and delays [41].

However, the prospect of billions of connected devices continues to raise aplethora of security and trust concerns [28]. In 2016, the Mirai botnet infectedover 2.5 million IoT devices, including IP cameras, smart TVs and printers, tolaunch a 1TB/s attack, believed to be the largest recorded [4], on web host OVHand DNS provider Dyn. However, it is the effect of compromised devices usedto monitor and reactively inform larger sensitive processes, such as in manufac-turing, critical infrastructure and assistive technologies, which raise the gravestconcerns [31]. A compromised sensing device that surreptitiously feeds falsifiedmeasurements, e.g. temperature and battery consumption, to a reactive controlsystem could conceal abnormal operating conditions and potentially endangerpersonnel. This rests in whether devices can be trusted to inform critical decision-making where malicious data could yield damaging consequences. The perceivedtrustworthiness of devices may be the differentiating factor in realising IoT’sprojected potential. Indeed, a 2014 report by the UK Government’s Chief Sci-entific Advisor stated that while “real value is created for businesses, consumersand governments [by IoT]...a major data breach or cyber-attack is likely to haveextremely damaging consequences on public attitudes” [40].

Trusted computing concepts, such as the Trusted Platform Module (TPM),have been used to protecting key material and providing evidence of platformintegrity using remote attestation. TPMs, however, are relatively restricted: nei-ther arbitrary application execution nor secure input/output (I/O) are realisablewithout additional processes, such as TPM-backed virtual machines [17]. TEEs,discussed in Section 2, are a recent inception of secure execution platforms dating

Remote Credential Management for Constrained Devices with TEEs 3

back to the smart card and TPM initiatives, and are emerging as the forerun-ner for addressing the security and deployability requirements of sensitive IoTdeployments [31]. Unlike TPMs, TEEs provide hardware-enforced isolated exe-cution of critical applications and credentials – aiming to defend assets againstsophisticated software-based adversaries from conventional operating systems,or Rich Execution Environment (REE), irrespective of their protection mode,i.e. Rings 0–3. Modern Intel and ARM chipsets feature Intel Software GuardeXtensions (SGX) and ARM TrustZone respectively, which instantiate a TEEdirectly from the CPU or System on Chip (SoC) without additional securityhardware. In 2017, Trustonic estimated that >1bn wearable, mobile, industrialand other IoT devices used their TrustZone-based TEE [39].

Despite widespread availability, managing IoT TEE data credentials through-out their life-cycle has received limited attention. Such credentials may be usedto authenticate and securely report measurements – typically taking the form ofa certificate, passwords, or biometrics of device handlers. Challenges arise whencredentials require migrating, revoking, updating or backed-up in a secure man-ner, e.g. safely migrating device credentials to a replacement model. All of thesechallenges are complicated by IoT: large numbers of TEEs must be administeredeven in a single town or factory, limiting the feasibility of human intervention,and may operate over a variety of communication mediums, such as RS-232,Ethernet and ZigBee. Moreover, IoT systems may also contain heterogeneousTEEs: Intel SGX, for example, is confined to Intel CPUs on more powerful de-vices, while ARM TrustZone is suited to the most constrained devices with ARMSoCs, e.g. microcontrollers and single-board computers.

For the first time, we analyse and address four critical challenges when man-aging heterogeneous TEE credentials over its lifetime with bi-directional trustassurances for remote migration (Section 3), revocation (Section 4), backups(Section 5), and updates (Section 6). We focus principally on centralised deploy-ments comprising a Trusted Service Manager (TSM), as per the GlobalPlatformspecifications [15] that manages credentials, and where the application and costof maintaining TEEs on constrained devices is both compelling and justified,e.g. IIoT and smart cities. This paper presents the following contributions:

– A detailed analysis and examination of past literature is presented on fourcredential management challenges facing the deployment of TEEs in cen-tralised IoT deployments.

– Five proposed protocols for facilitating IIoT TEE credential management,grounded in an analysis of the security and functional requirements of IoTTEEs. The protocols are agnostic of the TEE, communication medium, andemploy a Trusted Service Manager (TSM), akin to that described in theGlobalPlatform TEE standards [15].

– Each proposed protocol is subjected to formal symbolic verification usingthe Scyther analysis tool, which found no attacks. We freely release the pro-tocol verification specifications for further research and analysis, which aremade available online at: https://www.dropbox.com/s/uq0hftj6b6c1zux/remote-credential-scyther-scripts.zip.

4 Shepherd, Akram and Markantonakis.

2 Trusted Execution Environments (TEEs)

GlobalPlatform defines a TEE as an isolated execution environment that “pro-tects from general software attacks, defines rigid safeguards as to the data andfunctions a program can access, and resists a set of defined threats” [14]. TEEsaim to isolate applications from integrity and confidentiality attacks from the un-trusted OS, e.g. Android, or Rich Execution Environment (REE), by allocatingdistinct memory regions with accesses controlled in hardware. TEE applicationsmay allocate shared memory spaces or expose a predefined API. We summarisethe leading commercial TEEs on Intel and ARM chipsets. Note that ARM Trust-Zone is considered alongside the GlobalPlatform TEE; the latter is a series ofspecifications typically implemented in hardware using TrustZone extensions forthe ARM Cortex A and M processor families.

2.1 Intel Software Guard eXtensions (SGX)

Intel SGX is an extension to the X86-64 instruction set that enables on-demandcreation of ‘enclaves’ per application. Enclaves reside in isolated memory regionswithin RAM with accesses mediated by the CPU, which is considered trusted [9].SGX also offers secure storage through the sealing abstraction in which data isencrypted to the untrusted world using a key derived from a processor-specificStorage Root Key (SRK). The SRK can be used to derive an enclave-specifickey, i.e. binding data to that enclave only, or from the author ID to allow persis-tence between enclaves from the same author. Remote attestation also enablesthird-party verification of enclaves and secret provisioning using the EnhancedPrivacy ID (EPID) scheme [5] for authenticating platform integrity measure-ments without revealing its identity.

2.2 GlobalPlatform (GP) TEE and ARM TrustZone

The GP TEE maintains two worlds for all trusted and untrusted applications. ATEE kernel is used for scheduling, memory management, cryptographic methodsand other OS functions, while user-mode TEE Trusted Applications (TAs) accessOS functions exposed by the GP TEE Internal API (see Figure 1). The GPTEE Client API [14] defines the interfaces for communicating with TAs fromthe REE. The predominant method for instantiating the GP TEE is with ARMTrustZone, which enables two isolated worlds to co-exist in hardware using twovirtual cores for each world per physical CPU core and an extra CPU bit (NSbit) for distinguishing REE/TEE execution modes. TrustZone provides secureI/O with peripherals connected over standard interfaces, e.g. SPI and GPIO, byrouting interrupts to the TEE kernel using the TrustZone Protection Controller(TZPC) for securing on-chip peripherals from the REE, and the Address SpaceController (TZASC) for memory-mapped devices. The GP TEE implementssecure storage using the sealing abstraction, or to TEE-controlled hardware,e.g. Secure Element (SE).

Remote Credential Management for Constrained Devices with TEEs 5

Fig. 1: GlobalPlatform TEE system architecture [35].

2.3 Alternative Secure Execution Environments

Secure Elements (SEs), e.g. Universal Integrated Circuit Cards (UICCs), areanother means for application and credential hosting on constrained devices. AnSE is a discrete, tamper-resistant hardware module in which limited applicationand credential data can be stored and executed [16]. While GlobalPlatform con-siders TEEs as “sufficient for most applications” [16], an SE’s tamper-resistanceis beneficial where hardware attacks, e.g. differential power analysis (DPA), formpart of the threat model, but at the cost of reduced computing power and ad-ditional hardware. A trusted hypervisor launched from the TPM’s secure boothas also been proposed, e.g. Intel’s Trusted eXecution Technology (TXT) [17].This launches isolated virtual machines (VMs) for hosting applications, while theTPM itself can seal credentials under its SRK; however, TPM+VM construc-tions have found sparse deployment on IoT devices, due to constrained space andcomputational requirements [34]. We briefly compare the technologies in Table 1.The reader is referred to [34] for a survey of IoT execution environments.

2.4 TEE Credential and Profile Management

Security credentials are the evidence that a communicating party possesses foraccessing privileged data and services. Credentials are typically programmed ini-tially into a TEE during a personalisation phase after the delivery of a suitableSystem on Chip (SoC) and TEE software, but prior to deployment. After this,a Trusted Service Manager (TSM) – incorporated into the device manufactureror outsourced – is responsible for maintaining the TEE, its TAs and on-board

6 Shepherd, Akram and Markantonakis.

Table 1: Comparison of secure execution environments for IoT.

FeatureGP TEE

+ARM TZSGX SE

TPM+VM

TPM

Isolated App. Execution H# #

HW Tamper-Resistance H# H# H#

Secure I/O Path # # # #

Remote Attestation H# #

Secure Storage #

Authenticated Boot # #

Computing Performance Good Good Poor OK Poor

Discrete HW Module No No Yes Yes Yes

Suitable forConstrained Devices

Yes No Yes No Yes

: Extensive fulfilment. H# : Partial. # : Little-to-none.

credentials thereafter. We define TEE credentials as the set, C, of key material,certificates and other authentication data issued by TSM that is provisioned intoa TA. Credentials may also comprise a key derived from a password-based keyderivation function using a password from an operator, or encapsulated by bio-metrics, e.g. iris and fingerprint, or a model that maps contextual data, like sen-sor inputs, to authentication states using Continuous Authentication (CA) [33].

2.5 Security and Functional Requirements

The GP Trusted Management Framework (TMF) does not stipulate specificsecure channel protocols, but only that the TSM and TEE should mutuallyauthenticate over a channel that preserves the “integrity and the confidential-ity of the exchanges,” and addresses replay attacks against a Dolev-Yao adver-sary [15]. These basic requirements omit desirable features identified in existingtrusted computing literature [32,1,18], such as trust assurances that the targetTEE is authentic and integral. This is usually realised using Remote Attestation(RA) where system measurements, e.g. bootloader and TA binaries, are takenat boot-time or on-demand – measured and signed by a trusted measurer us-ing a device-specific key. RA protocols authenticate the platform to a remoteverifier using these measurements. In sensitive IoT deployments, mutually au-thenticating both end-points may be desirable, e.g. TEE-to-TEE communicationfor securing backups from a GP TEE to a cloud-based backup enclave using IntelSGX. Here, RA protocols can be conducted on each end-point or using a mutualattestation protocol [32,18,1] where both parties are authenticated in the proto-col. Device-side, we aim to maintain the assurances of host TEEs, i.e. against asoftware-based adversary in the REE (Rings 0–3, kernel and user modes) fromobserving credentials transmitted to and from the device to the TSM. We also in-troduce an abstract controller, a generic IoT Controller (IC), with which the host

Remote Credential Management for Constrained Devices with TEEs 7

edge device communicates with the IoT deployment network at large, is issuedmanagement commands, performs firewalling, device black listing and messagerouting to other devices, e.g. local- (LAN), metropolitan (MAN) or wide-areanetwork (WAN). We formalise the baseline security and functional requirementsfrom issues raised in related work and those stipulated in the GlobalPlatformspecifications:

S1) Mutual key establishment : a shared secret key is established for communica-tion between the two entities.

S2) Forward secrecy : the compromise of a particular session key should not affectpast or subsequent protocol runs.

S3) Trust assurance: the proposal shall allow third-parties to verify the loggingapplication’s integrity post-deployment to provide assurances that logs weresourced from an integral and authentic platform.

S4) Mutual trust verification: both end-points shall successfully attest the stateof the other before permitting the establishment of a secure channel.

S5) Mutual entity authentication: each communicating end-point shall authenti-cate the other’s identity to counter masquerading attempts.

S6) Denial of Service (DoS) resilience: resource allocation shall be minimised atboth end-points to prevent DoS conditions from arising.

S7) Key freshness: the shared key shall be fresh to the session in order to preventreplay attacks.

F1) Avoidance of additional trust hardware: the protocol shall avoid the need foradditional security hardware, e.g. TPMs and SEs, other than the TEE.

F2) TEE-agnostic: the protocols shall remain agnostic of the underlying TEEarchitecture to facilitate interoperability.

2.6 Setup Assumptions

A public-key infrastructure (PKI) is assumed where a trusted CA issues certifi-cates to the TSM, TAs, and backup (BA), revocation (RA) and maintenance(MA) authorities used for managing backups, revoking credentials and physi-cally maintaining devices respectively. The TEEs themselves are assumed to betrusted and to possess certified device-specific attestation and command keysfor signing quotes and requests/responses to the TSM. Quotes are a widely-usedremote attestation abstraction for TPMs and TEEs, e.g. Intel SGX [9], com-prising platform integrity measurements collected by a trusted measurer in theTEE, and its identity. The resulting quote is signed using the attestation key,and sent to the authority for verifying the TA’s integrity and authenticity. Thecredentials are assumed to be securely stored within the TEE, e.g. encrypted un-der AES-GCM with a device-specific SRK, and secure means of random numberand key derivation.

3 Migration

TEE migration is the process of transferring and re-provisioning credentialsand/or profile data from TAA to TAB in distinct TEEs. In IoT, migration

8 Shepherd, Akram and Markantonakis.

is beneficial in preserving credentials during a device replacement or relocation,where credentials and, in particular, on-board profiles/models (see Section 2.4)can be transferred to other units without incurring reinitialisation costs. This islikely to occur if a device is replaced by a successor model, and may potentiallybe located in a separate physical locations. Migrating credentials across TEEshas already attracted some attention in related literature [3,26]. We summarisethese schemes and their contributions.

Arfaoui et al. [3] present a privacy-preserving protocol for migrating cre-dentials between GlobalPlatform TEEs. A PKI-based protocol is proposed forauthorising the credential transfer between the TEE, TSM and the TEE’s serviceproviders, each of whom controls a set of TAs in a Security Domain (SD). Afterauthorisation, a second protocol is used to transfer data between the SDs by eachservice provider using a PKI- or password-based authenticated key exchange.Both protocols are subjected to formal verification using the AVISPA analysistool. While the authors note the importance of remote attestation during TSM-TEE authorisation, it is not presented or verified as part of the protocol; it isalso omitted during the credential transfer process between the TEEs. Moreover,mutual trust assurances between the TSM and the TEEs is not discussed.

Kostiainen et al. [26] tackle migration for TEE open credential platformswhere service providers can provision arbitrary credentials for, for example, vir-tualised access control cards. They propose encrypting and backing-up creden-tials on a trusted server using a tokenised password known only to the user.The credentials are migrated by re-entering the password, which is re-tokenisedon the receiver device, and transmitted and verified by the backup server thatreleases the encrypted credentials. Similar to [3], the proposal lacks trust assur-ances between the TSM and both TEEs, nor is it subjected to formal analysis.

3.1 Proposed High-level Migration Procedure

Credentials must be deleted on the device from which they are migrated, whiletransferring them over a secure channel with mutual trust assumptions betweenTAA and TAB , which is absent in existing literature. In Figure 2, we showhow migration can be performed between two disparate TAs, accounting for theshortcomings in related work; the messages are described as follows:

1. A mutual remote attestation protocol [32,1,18] is executed between TSMand TAA to bootstrap a secure and mutually trusted channel (STCP).

2. TSM transmits the begin migration command to TAA.3. TAA unseals the credentials from its secure storage for transmission.4. TAA acknowledges to TSM that the credentials were unsealed successfully.5. A separate STCP instance is executed between (TSM,TAB).6. TSM sends a message to TAB to prepare for credential/profile (re-)provisioning.7. TAB acknowledges to TSM that it is ready to receive credentials.8. TSM transmits the ID of TAB to TAA, e.g. IP address, to which to transmit

its unsealed credentials.9. An STCP is formed using mutual remote attestation between TAA and TAB .

Remote Credential Management for Constrained Devices with TEEs 9

10. The credential transfer occurs between TAA and TAB .11. The transferred credential is provisioned into the secure storage of TAB .12. TAB acknowledges its credential re-provisioning success to TSM .13. TSM instructs TAA to delete its credentials.14. TAA deletes the migrated credential and acknowledges its success TSM .

Fig. 2: Proposed TEE credential migration procedure.

The high-level procedure uses three secure and trusted channels (STCPs)with mutual attestation between (TSM,TAA), (TSM,TAB) and (TAA, TAB),thus addressing the absence of trust assurances in existing schemes. The proposalavoids unnecessarily exposing credentials to the TSM by transmitting data di-rectly between the mutually authenticated TAs. Both ICs require no additionalcryptographic operations and act only as switches for communicating the pro-tocol messages to the correct IoT device in its intended. Implicitly, the protocolavoids specifying TEE-specific functionalities; rather, for F2 (TEE agnosticism),we abstract the protocol appropriately to allow migrations between heteroge-neous TEEs by allowing either a GP TEE application or Intel SGX enclaveto act as either TA. For TEE-specific implementation guidance, the reader isreferred to existing work such as the GlobalPlatform TMF specifications [15],and the work by Arfaoui et al. [3] for managing and authorising SDs on the GPTEE. In Section 7, we specify the protocols and procedures formally, and detailan enhanced mutual attestation protocol for STCP for satisfying the remainingrequirements in Section 2.5.

4 Revocation

Credentials may be revoked if they reach the end of their predefined lifespan(s),as part of a key rotation policy; if the OEM discovers a vulnerability in the TA

10 Shepherd, Akram and Markantonakis.

or TEE kernel code, and the credentials were potentially compromised; or thedevice is retired from service, say, due to obsolescence. As discussed in Section2.4, compromised IoT credentials could be abused to authenticate maliciousdecisions and data; revocation is vital in preventing compromised devices frominfluencing larger critical processes.

Revocation has been previously studied in TPM and smart card literature.Chen and Li [8] address credential revocation in Direct Anonymous Attestation(DAA), as used in TPM 2.0. DAA, like group signatures, allows the signer todemonstrate knowledge of its individual private key corresponding to the group’spublic key. Revoking DAA credentials is challenging as the signer’s identity isnot revealed, even to the group manager with the group key. The authors reviewtwo solutions: rekey-based, where the issuer updates its public key (which mayor may not include its corresponding secret key), and allows only legitimatenon-revoked signers to update their credentials; and Verifier-Local Revocation(VLR), where the verifier inputs a revocation list, RL, to the DAA’s verificationfunction and accepts only signatures from signers, S /∈ RL.

Lueks et al. [29] address revoking attribute-based credentials (ABCs) forsmart cards anonymously. A Revocation Authority (RA) possesses a revocationlist (RL) of anonymous revocation values, grε,v, submitted by the user or verifier(user- and system-instantiated revocation), where r is the revocation value inthe user’s credential. A revocation ‘epoch’, ε (corresponding to a time period)is used to provide unlinkability by re-computing and re-sending the new validRLs to the verifiers at each epoch; that is, RLε,V = sort({grε,V | r ∈ MRL}),where MRL is the master revocation list. Using bloom filters, this occupies only4–8MB for 221 revoked credentials depending on the probability tolerance.

Katzenbeisser et al. [24] propose revocation for TPM 1.2 using blacklistingand whitelisting. Blacklisting orders revoked keys into a hash chain, where thefinal hash value, h, is stored in a TPM register. When a key is revoked, a newhash entry is created and the TPM updates h accordingly. Before loading a key,the TPM tests whether it is in the blacklist before unsealing it. Whitelistingincrementally creates keyed hashes of each permitted key with the value of theTPM’s internal secure counter as the whitelist’s ‘version’. A key is valid iff thekeyed hash counter value matches the TPM’s internal counter. Revocation isperformed by incrementing the TPM’s counter and updating all non-revokedhashes with the new value.

4.1 Proposed High-level Revocation Procedure

Privacy-preserving credential schemes, e.g. DAA and anonymous credentials, arebeneficial in verifying credentials without divulging or linking users’ identities.However, the focus of this work is on inherently centralised IoT deployments,such as smart cities and IIoT architectures, where the concern of violating cre-dential privacy has far fewer consequences than government electronic ID cardsor TPMs on consumer devices. Relaxing this constraint provides us with someheadway to pursue simpler, PKI-based solutions for providing the first baselineprotocol for TEE credential revocation with mutual attestation. Moreover, we

Remote Credential Management for Constrained Devices with TEEs 11

discuss two approaches for IoT based on blacklisting and whitelisting using atrusted RA. The procedure is illustrated in Figure 3 and described as follows:

1. TA and TSM form a STCP using mutual remote attestation to verify theplatforms’ integrity and authenticity.

2. TSM instructs TA to reveal the current credentials in use, C, which arethen unsealed from storage, e.g. encrypted in untrusted storage or an SE.

3. C is transmitted to the TSM over the STCP.4. The TSM forms a STCP with the revocation authority, RA, who maintains

the master revocation list of whitelisted or blacklisted credentials.5. TSM submits C to RA, who returns a list of the revoked credentials in C,

i.e. RC ⊆ C, from its master revocation list (MRL).6. RA returns the revoked credentials, RC, to TSM .

Next, if RC is not empty, the TSM informs IC of the credentials to disallowin future transactions. The TSM also instructs the TA to update the revocationstatus of RC ∈ C internally to prevent further use. Note that a malfunction-ing device may fail to update this status and reuse revoked credentials. Theuse of revoked credentials should be reported to MA responsible for decommis-sioning compromised devices. Like [29], delegating revocation list managementto RA removes the burden of potentially multiple verifiers synchronising a sin-gle list; the TSM can submit a lookup request to the RA, who queries theblacklist or whitelist in O(1) using an associative array. Traditional revocationschemes, e.g. PKI certificate revocation, use blacklisting. The RA maintains amaster revocation list (MRL) of revoked credentials that should not be usedin any IC transaction; the MA may submit credentials it wishes to revoke toRA (maintainer-instantiated revocation). RA checks the revocation status of Cby verifying C /∈ MRL. Whitelisting, conversely, comprises a list of only thepermitted credentials; a credential is revoked by removing it from the whitelistand, if applicable, updating the list with its replacement. Revocation is testedby verifying C ∈ MRL. The use of blacklists and whitelists is context-specific;whitelisting may be preferred over blacklisting when the valid credential set issmall and changes infrequently.

5 Remote Backups

Backup is the process of securely retrieving the set of credentials, C, belongingto a TA for remote storage. In standard security practice, backups often form thecornerstone of a disaster recovery plan – as stipulated by ISO 27001:2013 [22]– for recovering data from corruption and accidental deletion. Backups mayalso constitute part of a data retention policy, where device data is copied forlocal analysis and evidence of regulatory adherence. Like migration, the cre-dential/profile backup is beneficial in IoT if the original was entered by hand(human input), e.g. password, or derived from a trained machine learning model,e.g. behavioural biometrics, which is time-consuming to retrain. The restorationof backups may be addressed using the Remote Update protocol proposed in

12 Shepherd, Akram and Markantonakis.

Fig. 3: Proposed high-level credential revocation procedure.*8a. STCP between IC and TSM is unnecessary if the route is trustworthy.

Section 6. Next, we examine related work in the backup of remote credentialsaboard secure and trusted execution technologies.

Kostiainen et al. [27] address TEE credential backup, restoration and dis-abling on consumer mobile phones, and propose two solutions. The first uses aSE, a SIM card, where the TEE credentials are protected under a SIM-specifickey provisioned by its provider. This allows the user to uninstall a familiar hard-ware element, i.e. the SIM, before releasing the device for repairs or to lend to anuntrusted user. On reinserting the SIM, an on-board TEE credential manager isused to decrypt and re-initialise the encrypted credentials. The second solutioninvolves the use of a removable microcontroller to counter an honest-but-curiousremote server, RS. RS has a shared key Ks with the TEE, and stores the back-ups using a secure counter for rollback protection. To prevent RS reading thecredentials, the TEE encrypts them under a separate key, K, derived from alocal counter on the microcontroller, and re-encrypts them under Ks.

Akram et al. [2] examine credential restoration for multi-application smartcards on smartphone SEs. They enhance the Trusted Environment and Exe-cution Manager (TEM), which dynamically enforces the smart card’s run-timesecurity policies, to implement credential backup and restoration mechanisms.A Backup and Restoration Manager (BRM) is added to the smart card softwarestack that interfaces with a TEM-resident backup token handler, which storestokens issued by application service providers. The user registers the BRM witha backup server (BS); when the user wants to backup, the BRM encrypts thetoken(s) and communicates them to BS. To restore data, e.g. to a new card, theuser provides the BRM with his/her BS credentials to download the backed-uptokens. A secure channel is formed and the token(s) authenticate the credentialrestoration from the service provider(s).

Remote Credential Management for Constrained Devices with TEEs 13

5.1 Proposed High-level Backup Procedure

We introduce a trusted Backup Authority (BA) responsible for storing retrievedcredentials. This may be a cloud-based storage provider or Hardware SecurityModule (HSM) possessed by the credential issuing authority; the precise meansby which the BA securely stores credentials is considered out-of-scope in thiswork. The proposed procedure between the target TA and BA is shown in Fig-ure 4 and described below:

1-4) TSM and BA establish a secure and trusted channel with mutual attesta-tion, and TSM requests BA to prepare for backup.

5-6) TSM forms an STCP with TA, commanding it prepare the credentials forremote backup. TSM provides the identity of BA that performs the backup.

7-8) TA unseals the credentials to transmit to BA, and notifies TSM that theywere unsealed successfully.

9-12) TA and BA form a STCP over which C is transmitted and stored securelyby BA. While TSM is considered trusted, the direct connection betweenTA and BA mitigates the risk of unnecessary credential exposure to TSM .

13) BA notifies TSM that TA was backed-up successfully.

Fig. 4: Proposed high-level remote credential backup protocol.

6 Remote Updates

Remotely updating IoT credentials is beneficial during routine renewal sched-ules, e.g. X.509 certificates that reach their validity expiry date; replacing arevoked credential after, for example, the detection of a compromise; or the de-vice is relocated and the organisational unit to which the credential is issued is

14 Shepherd, Akram and Markantonakis.

Fig. 5: Proposed credential update procedure.*11. (MA,RA) STCP is unnecessary if the route is trustworthy.

no longer valid. Generally, update is the process of securely replacing an obsoletecredential, ci, with a newly issued c′i. Once replaced, ci should be revoked to pre-vent the use of an obsolete but potentially valid credential. Little work has beenconducted academically for updating TEE credentials; this is likely due to thethe simplicity of a TSM creating a secure channel and modifying the credentialor, indeed, the similarity with restoring backups. Updates can be considered avariation of backup restoration where c′i is retrieved from a trusted server, ratherthan ci registered by the user; the addition is revoking ci, achievable using theprocess described in Section 4.

6.1 Proposed High-level Update Procedure

We reintroduce the maintenance authority (MA) from Section 4, which issuescredential updates, e.g. as part of a rotation policy and/or recognising potentiallycomprised devices/credentials. If desired, the MA is also responsible for regis-tering obsolete credentials with the revocation authority (RA). The high-levelupdate mechanism is as follows:

1. TSM establishes an STCP with MA, who procures and provides the neces-sary credential updates.

2. MA notifies the TSM of an updated credential. This may include identitiesof which TEEs need updated or, indeed, all TEEs.

3-4) An STCP is conducted between (TSM,TA), and transmits an update prepa-ration command to TA.

5) TA is locked, i.e. prevented from interacting with the REE, until the updateis performed to prevent using outdated credentials.

6) TA acknowledges to TSM that it is ready to update.

Remote Credential Management for Constrained Devices with TEEs 15

7-8) TA establishes a STCP with MA to receive the update, and MA transmitsthe updated credential, c′i, to TA.

9) TA seals c′i to its secure storage for future use; ci should be deleted internallybefore unlocking.

10) TA acknowledges to MA that c′i was initialised successfully.11-13) (MA,RA) use an STCP to white/blacklist obsolete credential ci.

7 Proposed Protocol Analysis

We formalise the protocols from the high-level procedures presented in the pre-vious sections – listed in Protocols 1 to 6 and the notation in Table 2. In Section2.6, we outlined the setup assumptions behind the protocols, e.g. key locationsand the TEE quoting abstraction, which we refer to frequently throughout.

Each proposed protocol is underpinned by a variant of the mutual remote at-testation protocol proposed in [32]. This protocol (Protocol 6), which establishesa TEE-to-TEE secure channel, is modified to support authenticated encryption,e.g. AES-GCM, over a non-authenticated symmetric scheme and an additionalHMAC in the original proposal. This forms the basis for establishing the trust re-lationships between the TEEs, outlined in the requirements in Section 2.5. Theprotocol is based on ephemeral Diffie-Hellman key agreement, thus achievingsession forward secrecy (S2), mutual key establishment (S1) and key freshness(S7). Additionally, the protocol conducts remote attestation via the TEE quot-ing abstraction for verifying the target platform’s integrity and authenticity, asdescribed in Section 2.6, which satisfies S3 and S4 (mutual trust verification).The assumption of PKI and the provisioning of key pairs to sign attestationvalues, command instructions, e.g. Prep Backup and Revoke Success, and theshared secret provides mutual entity authentication (S5).

Importantly, the protocols avoid the use of additional trusted hardware forconstrained IoT devices, such as TPMs, secure elements and smart cards byfocusing on TEEs, which may be implemented using the GlobalPlatform TEE

Protocol 1 Proposed Migration Procedure with BTP (MPBT)

1: Execute BTP (TSM , TA1)2: TSM → TA1 : [(Prep Migrate || XTSM )σTSM ]AEK

3: TA1 → TSM : [(TA1 Ack || XTA1)σTA1]AEK

4: Execute BTP (TSM , TA2)5: TSM → TA2 : [(Prep Migrate || X ′

TSM )σTSM ]AEK′

6: TA2 → TSM : [(TA2 Ack || X ′TA2)σTA2]AEK′

7: TSM → TA1 : [(IDTA2 || XTSM )σTSM ]AEK

8: Execute BTP (TA1, TA2)9: TA1 → TA2 : [(C || X ′′

TA1)σTA1]AEK′′

10: TA2 → TA1 : [(Stored C Ack || X ′′TA2)σTA2]AEK′′

11: TA2 → TSM : [(TA2 Done || X ′TA2)σTA2]AEK′

12: TSM → TA1 : [(Delete Creds || XTSM )σTSM ]AEK

13: TA1 → TSM : [(TA1 Done || XTA1)σTA1]AEK

16 Shepherd, Akram and Markantonakis.

Protocol 2 Proposed Backup Procedure with BTP (BPBT)

1: Execute BTP (TSM , BA)2: TSM → BA : [(Prep Backup || XTSM )σTSM ]AEK

3: BA→ TSM : [(BA Ack || XBA)σBA]AEK

4: Execute BTP (TSM , TA)5: TSM → TA : [(Prep Backup || X ′

TSM )σTSM ]AEK′

6: TA→ TSM : [(TA Ack || X ′TA)σTA]AEK′

7: TSM → TA : [(IDBA || XTSM )σTSM ]AEK

8: Execute BTP (TA, BA)9: TA→ BA : [(C || X ′′

TA)σTA]AEK′′

10: BA→ TA : [(Backup Ack || X ′′BA)σBA]AEK′′

11: BA→ TSM : [(Backup Done || X ′BA)σBA]AEK′

Protocol 3 Proposed Revocation Lookup with BTP (RLBT)

1: Execute BTP (TSM , TA)2: TSM → TA : [(Reveal Creds || XTSM )σTSM ]AEK

3: TA→ TSM : [(C || XTA)σTA]AEK

4: Execute BTP (TSM , RA)5: TSM → RA : [(Lookup || C || X ′

TSM )σTSM ]AEK′

6: RA→ TSM : [(Revoked || RC || X ′RA)σRA]AEK′

If RC 6= ∅:7: TSM → TA : [(Revoke || RC || XTSM )σTSM ]AEK

8: TA→ TSM : [(Revoke Ack || XTA)σTA]AEK

9: (Optional) Execute BTP (TSM , IC)10: TSM → IC : [(Revoke || RC || X ′′

TSM )σTSM ]AEK′′

11: IC → TSM : [(Revoke Ack || X ′′IC)σIC ]AEK′′

Protocol 4 Proposed Revocation Procedure with BTP (RPBT)

1: Execute BTP (MA, RA)2: MA→ RA : [(Revoke || C || XMA)σMA]AEK

3: RA→MA : [(Revoke Ack || XRA)σRA]AEK

4: If reported credentials (RepC 6= ∅):RA→MA : [(Report || RepC || XRA)σRA]AEK

Protocol 5 Proposed Update Procedure with BTP (UPBT)

1: Execute BTP (MA, TSM)2: MA→ TSM : [(Update Ready || XMA)σMA]AEK

3: TSM →MA : [(TSM Ack || XTSM )σTSM ]AEK

4: Execute BTP (TSM , TA)5: TSM → TA : [(Prep Update || X ′

TSM )σTSM ]AEK′

6: TA→ TSM : [(TA Ack || X ′TA)σTA]AEK′

7: Execute BTP (TA, MA)8: TA→MA : [(Get Update || X ′′

TA)σTA]AEK′′

9: MA→ TA : [(new cj || X ′′MA)σMA]AEK′′

10: TA→MA : [(New Cred Ack || X ′′TA)σTA]AEK′′

11: Execute BTP (MA, RA)12: MA→ RA : [(Revoke || ci || X ′′′

MA)σMA]AEK′′′

13: RA→MA : [(Revoke Success || X ′′′RA)σRA]AEK′′′

Remote Credential Management for Constrained Devices with TEEs 17

Protocol 6 Modified Bi-directional Trust Protocol (BTP) from [32]

1: A→ B : IDA || IDB || nA || gA || ARB

2: B → A : IDB || IDA || nB || gB ||[(XB)σB || (VB)σB

]AEK

|| ARA

XB = H(IDA || IDB || gA || gB || nA || nB)VB = QB || nB || nA

3: A→ B : [ (XA)σA || (VA)σA ]AEK

XA = H(IDA || IDB || gA || gB || nA || nB)VA = QA || nA || nB

Table 2: Protocol notation.

Notation Description

TSM TEE trusted service manager.RA Revocation authority.MA Device maintenance authority.TAX TEE trusted application on device X.ICX Abstract IoT controller X.nX Secure random nonce generated by X.H(D) Secure one-way hash function, H, on D.X → Y Message transmission from X to Y .IDX Identity of X.A || B Concatenation of A and B.gX Diffie-Hellman exponentiation of X.ARX Attestation request on target entity X.QX Attestation quote from TEE X.

(A)σXSigned message A from X under a private-public key-pair (K,P ).

[m]AEK

Message m is encrypted using authenticatedencryption under session key K derived fromthe protocol’s shared secret.

D′ Data specific to a separate session to D.

and ARM TrustZone on all Cortex-A and M chipsets (F1). The protocols aredesigned to incorporate abstract TAs, which are verified using the quoting ab-straction, whether they be Intel SGX enclaves of GP TEE TAs, thus providingTEE agnosticism (F2). Note, however, that this abstracts away the precisionof related work, e.g. Arfaoui et al. [3], which addresses migration specifically inthe context of the GP TEE. Such work incorporates GP TEE-specific entites,such as security domains (SDs) and root SDs, which do not exist on Intel SGXor earlier TPM-based TEEs, like Intel TXT [17]. As such, users of this workshould be aware of the implementation specifics when deploying these protocols;we refer users to [3] and [15] for guidance for GP TEEs, and [9] for Intel SGX.

7.1 Formal Symbolic Verification

The Scyther verification tool by Cremers [11] was employed to verify the cor-rectness of the proposed protocols. A protocol is first specified in the Scyther de-

18 Shepherd, Akram and Markantonakis.

scription language, comprising communicating parties (roles), messages and thedesired security properties (claims). Scyther then verifies whether the protocolspecification satisfies those claims under the ‘perfect cryptography’ assumption,i.e. an adversary learns nothing from an encrypted message unless the decryp-tion key is known. Scyther uses a novel pruning algorithm for efficient unboundedverification for establishing whether the desired security properties hold underagainst all possible behaviours of a Dolev-Yao adversary. Despite the challengethat protocol verification is generally undecidable, many practical protocols canbe proven correct; notably, Scyther has been used to verify IKEv1 and IKEv2,and the ISO/IEC 9798 authentication protocol family [10]. We analyse all pro-tocols using the default Dolev-Yao adversarial model, testing for the secrecyof transmitted quotes from both parties, e.g. (Secret, qta1) and credentials(Secret, c); aliveness (Alive); replay protection, i.e. non-injective agreement(Niagree) and non-injective synchronisation, (Nisynch), defined in [11]; sessionkey secrecy (SKR, K); and the reachability of all entities, e.g. (Reachable, TA).We publicly release the protocl Scyther specifications for future research by thecommunity (see Section 1). Scyther found no attacks on any protocol.

8 Conclusion and Future Research

TEEs offer a standardised method for providing a range of security and trust as-surances applicable to sensitive IoT deployments. In this work, we presented thefirst investigation and protocols for secure and trusted remote credential man-agement of TEE credentials on constrained devices for migration, revocation,backups, and updates. After summarising the features of TEEs, we formalisedthe threat model, requirements and assumptions for a typical centralised IoTTEE credential deployment. For each management challenge, we reviewed thestate-of-the-art before proposing procedures and protocols for securely realis-ing these notions in a centralised setting with TEEs – appropriate for smartcities, manufacturing and similarly controlled deployments. The protocols weresubjected to formal symbolic verification using Scyther, which found no attacksunder the Dolev-Yao adversarial model, which we release for further research. Infuture work, we aim to explore the following:

– A GlobalPlatform TEE may comprise multiple stakeholders with their ownsecurity domains and TAs, e.g. a temperature monitoring TA in SD1, a faultdetection TA in SD2, and so on. This work tackles the base case that TAsare in a single SD; in the future, we aim to explore protocols for fair andefficient management between competing stakeholders using the same TSMin the GP TEE model.

– We deemed the issue of privacy-preserving revocation as out-of-scope in thispaper. There may be some instances, however, where IIoT devices are linkedto users’ identities, e.g. wearable safety monitors on factory operatives, whichcould be addressed with revocation techniques using Blacklistable Anony-mous Credentials (BLACs) and DAA (discussed in Section 4).

Remote Credential Management for Constrained Devices with TEEs 19

References

1. Akram, R., Markantonakis, K., Mayes, K., Bonnefoi, P.F., Sauveron, D.,Chaumette, S.: An efficient, secure and trusted channel protocol for avionics wire-less networks. In: 35th Digital Avionics Systems Confernece. IEEE (9 2016)

2. Akram, R.N., Markantonakis, K., Mayes, K.: Recovering from a lost digital wallet.In: Embedded and Ubiquitous Computing. pp. 1615–1621. IEEE (2013)

3. Arfaoui, G., Gharout, S., Lalande, J.F., Traore, J.: Practical and privacy-preservingTEE migration. In: IFIP Int’l Conference on Information Security Theory andPractice. pp. 153–168. Springer (2015)

4. Bertino, E., Islam, N.: Botnets and Internet of Things security. Computer 50(2),76–79 (Feb 2017)

5. Brickell, E., Li, J.: Enhanced privacy ID from bilinear pairing for hardware au-thentication and attestation. Int’l Journal of Information Privacy, Security andIntegrity 1(1), 3–33 (2011)

6. Capgemini: Smart factories: How can manufacturers realize the potentialof digital industrial revolution (2017), https://www.capgemini.com/service/

smart-factories-and-the-modern-manufacturer/

7. Cardno, C.A.: Chicago tracks city streets ‘fitness’. Civil Engineering MagazineArchive 86(11), 36–37 (2016)

8. Chen, L., Li, J.: Revocation of Direct Anonymous Attestation. In: InternationalConference on Trusted Systems. pp. 128–147. Springer (2011)

9. Costan, V., Devadas, S.: Intel SGX Explained. IACR Cryptology ePrint 2016, 86(2016), https://eprint.iacr.org/2016/086.pdf

10. Cremers, C.: Key exchange in IPsec revisited: Formal analysis of IKEv1 and IKEv2.In: European Symposium on Research in Computer Security. pp. 315–334. Springer(2011)

11. Cremers, C.J.: The Scyther tool: Verification, falsification, and analysis of secu-rity protocols. In: Int’l Conference on Computer Aided Verification. pp. 414–418.Springer (2008)

12. DHL: Trend report: Internet of Things in logistics (2016), https://goo.gl/KbvorJ

13. Ekberg, J.E., Kostiainen, K., Asokan, N.: The untapped potential of trusted exe-cution environments on mobile devices. Security & Privacy 12(4), 29–37 (2014)

14. GlobalPlatform: TEE Protection Profile (v1.2) (2014)

15. GlobalPlatform: TEE Management Framework (TMF), v1.0 (2016)

16. GlobalPlatform: Trusted Execution Environment (TEE) Guide (2017)

17. Greene, J.: Intel Trusted eXecution Technology (TXT): Hardware-based technol-ogy for enhancing server platform security. Tech. rep., Intel, Inc. (2012)

18. Greveler, U., Justus, B., Loehr, D.: Mutual remote attestation: Enabling systemcloning for TPM-based platforms. In: Int’l Workshop on Security and Trust Man-agement. pp. 193–206. Springer (2011)

19. IBM: Parking in the smart city (2017), https://www.ibm.com/blogs/

internet-of-things/iot-smart-parking/

20. International Data Corporation (IDC): Internet of Things spending forecasts(2017), https://www.idc.com/getdoc.jsp?containerId=prUS42209117

21. International Data Corporation (IDC): Worldwide smart cities spending guide(2017), https://www.idc.com/tracker/showproductinfo.jsp?prod_id=1843

22. International Standards Organisation: ISO 27001:2013 – Information SecurityManagement (2013), https://www.iso.org/standard/54534.html

20 Shepherd, Akram and Markantonakis.

23. Kagermann, H., Helbig, J., Hellinger, A., Wahlster, W.: Recommendations forImplementing the Strategic Intiative ‘Industrie 4.0’: Securing the Future of GermanManufacturing Industry. Forschungsunion (2013)

24. Katzenbeisser, S., Kursawe, K., Stumpf, F.: Revocation of TPM keys. In: Interna-tional Conference on Trusted Computing. pp. 120–132. Springer (2009)

25. Kelly, S., Suryadevara, N., Mukhopadhyay, S.: Towards the implementation of IoTfor environmental condition monitoring in homes. IEEE Sensors 13(10), 3846–3853(2013)

26. Kostiainen, K., Asokan, N., Afanasyeva, A.: Towards user-friendly credential trans-fer on open credential platforms. In: Applied Cryptography and Network Security.pp. 395–412. Springer (2011)

27. Kostiainen, K., Asokan, N., Ekberg, J.E.: Credential Disabling from Trusted Exe-cution Environments. In: 15th Nordic Conference on Secure IT Systems. pp. 171–186. Springer (2010)

28. Kumar, J.S., Patel, D.R.: A survey on internet of things: Security and privacyissues. International Journal of Computer Applications 90(11) (2014)

29. Lueks, W., Alpar, G., Hoepman, J.H., Vullers, P.: Fast revocation of attribute-based credentials for both users and verifiers. Computers & Security 67, 308–323(2017)

30. PwC: Industrial Internet of Things (2016), https://goo.gl/ieN2ZE31. Sadeghi, A.R., Wachsmann, C., Waidner, M.: Security and privacy challenges in

industrial internet of things. In: 52nd Annual Design Automation Conference. p. 54.ACM (2015)

32. Shepherd, C., Akram, R.N., Markantonakis, K.: Establishing mutually trustedchannels for remote sensing devices with trusted execution environments. In: 12thInt’l Conference on Availability, Reliability and Security (2017)

33. Shepherd, C., Akram, R.N., Markantonakis, K.: Towards trusted execution ofmulti-modal continuous authentication schemes. In: Proceedings of the 32nd Sym-posium on Applied Computing. pp. 1444–1451. ACM (2017)

34. Shepherd, C., Arfaoui, G., Gurulian, I., Lee, R.P., Markantonakis, K., Akram,R.N., Sauveron, D., Conchon, E.: Secure and trusted execution: Past, present, andfuture – a critical review in the context of the Internet of Things and Cyber-Physical Systems. In: 15th IEEE Int’l Conference on Trust, Security and Privacyin Computing and Communications. pp. 168–177. IEEE (2016)

35. Shepherd, C., Petitcolas, F.A.P., Akram, R.N., Markantonakis, K.: An exploratoryanalysis of the security risks of the Internet of Things in finance. In: 14th Int’lConference on Trust, Privacy & Security in Digital Business. pp. 164–179. Springer(2017)

36. Smart Cities Council of India: Predicting floods with the ‘early flood warningsystem’ (2017), https://goo.gl/jRUwnE

37. Solanas, A., et al.: Smart health: a context-aware health paradigm within smartcities. IEEE Communications Magazine 52(8), 74–81 (2014)

38. Statista: Internet of Things (IoT) connected devices installed base worldwide from2015 to 2025 (2018), https://goo.gl/Cja5Mo

39. Trustonic: Adoption of trustonic security platforms passes 1 billion device milestone(February 2017), https://goo.gl/Lbt6Fe

40. UK Government Office for Science: The Internet of Things: Making the most ofthe second digital revolution (2014), https://goo.gl/X2ZHXx

41. Xiong, Z., Sheng, H., Rong, W., Cooper, D.E.: Intelligent transportation systemsfor smart cities: a progress review. Science China Information Sciences 55(12),2908–2914 (2012)