Design Rationale for Symbiotically Secure Key Management Systems in

IoT and Beyond

Witali Bartsch

1 a

, Prosanta Gope

2 b

, Elif Bilge Kavun

3 c

, Owen Millwood

2 d

, Andriy Panchenko

Aryan M. Pasikhani

2 e

and Ilia Polian

5 f

PointBlank Security, Steen Harbach AG, Leverkusen, Germany

Department of Computer Science, The University of Shefﬁeld, U.K.

Faculty of Computer Science and Mathematics, University of Passau, Germany

Chair of IT Security, Brandenburg University of Technology (BTU), Cottbus, Germany

Institute of Computer Architecture and Computer Engineering, University of Stuttgart, Germany

ﬁ

Keywords:

Secure Processor Architecture, Secure IoT, Hardware Fingerprinting, PUFs, Attack-Resilient Hardware.

Abstract:

The overwhelmingly widespread use of Internet of Things (IoT) in different application domains brought not

only beneﬁts, but, alas, security concerns as a result of the increased attack surface and vectors. One of the

most critical mechanisms in IoT infrastructure is key management. This paper reﬂects on the problems and

challenges of existing key management systems, starting with the discussion of a recent real-world attack.

We identify and elaborate on the drawbacks of security primitives based purely on physical variations and

– after highlighting the problems of such systems – continue on to deduce an effective and cost-efﬁcient

key management solution for IoT systems extending the symbiotic security approach in a previous work. The

symbiotic architecture combines software, ﬁrmware, and hardware resources for secure IoT while avoiding the

traditional scheme of static key storage and generating entropy for key material on-the-ﬂy via a combination

of a Physical Unclonable Function (PUF) and pseudo-random bits pre-populated in ﬁrmware.

1 INTRODUCTION

Internet of Things (IoT) has shown a spectacular

growth over the last years and is steadily enter-

ing application domains that are considered security-

critical. Security requirements in IoT systems must

coexist with stringent cost limits and with an exten-

ded attack surface where adversaries can gain phys-

ical access to their components. A critical part of most

secure systems is generation and management of key

material, which includes not only secret keys for use

in encryption and authentication, but also critical se-

curity parameters such as initialisation vectors (IVs),

padding bits or randomness for masking schemes.

In this position paper, we discourse on a solution

that provides an effective and yet cost-efﬁcient key

https://orcid.org/0000-0002-3766-8130

https://orcid.org/0000-0003-2786-0273

https://orcid.org/0000-0003-3193-8440

https://orcid.org/0000-0002-7250-8271

https://orcid.org/0000-0003-3181-4026

https://orcid.org/0000-0002-6563-2725

management for IoT systems. It extends the concept

of symbiotic security (Bartsch and Huebner, 2019b)

that leverages a combination of software, ﬁrmware,

and hardware for secure IoT, but not without up-

holding the principle of resource-constrained secur-

ity. The latter propagates reduction of design com-

plexity in favour of reduced attack surface (Bartsch

and Huebner, 2019a). The derived scheme, con-

sequently entitled Symbiotic Key Management Sys-

tem (SKMS), avoids static key storage, which is vul-

nerable to readout and manipulation especially in IoT

devices accessible to attackers. SKMS generates en-

tropy for key material on-the-ﬂy, using a combination

of Physical Unclonable Function (PUF) and pseudo-

random bits pre-stored in the system’s ﬁrmware.

Keys thus derived and encapsulated in a crypto en-

gine API, which offers services like encryption or au-

thentication, but does not communicate actual key bits

to applications. SKMS is designed to support zero-

knowledge protocols for initial enrolment (ZKIE),

for which it removes the need to keep the underly-

ing secret in non-volatile memory whilst also allow-

Bartsch, W., Gope, P., Kavun, E., Millwood, O., Panchenko, A., Pasikhani, A. and Polian, I.

Design Rationale for Symbiotically Secure Key Management Systems in IoT and Beyond.

DOI: 10.5220/0011726900003405

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

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)

583

ing to replace said secret when compromised. Tra-

ditional schemes based on One-Time Programmable

(OTP) memory, possibly including eFuses or even

PUFs are thus superseded. Moreover, it tightly integ-

rates an Artiﬁcial Intelligence (AI) assisted metadata

analysis procedure to detect and prevent intrusions.

The composition of a hardware-based Symbiotic Un-

clonable Function (SUF) and software-level intrusion

detection provides defence-in-depth: even when an

adversary manages manipulating system hardware,

software-level protections stay intact and can, upon

an alert, request regeneration of entropy bits.

The remainder of this paper is organized as fol-

lows. We start with a case study where we discuss a

recent vulnerability in a Trusted Execution Environ-

ment (TEE). For a number of observed aspects, we

point out the precise challenges and discuss strategies

how SKMS can address them. Additionally, we re-

view PUFs and identify observations, challenges and

strategies for them. The resultant security require-

ments in IoT systems are discussed in Section 3. Fi-

nally, Section 4 addresses the SKMS in detail fol-

lowed by the conclusion in Section 5.

2 STATE OF AFFAIRS IN KEY

MANAGEMENT SYSTEMS

This section motivates the need for key manage-

ment approaches beyond today’s standard by dissect-

ing a security ﬂaw in a widely used product. It also

provides background information on PUFs and shows

their potential deﬁciencies that SKMS should over-

come.

2.1 TrustZone Design Flaws

To support our deduction of the design rationale for

SKMS in Section 4, we analyse a major vulnerabil-

ity (Shakevsky et al., 2022) of a speciﬁc implementa-

tion of the original TEE design by ARM. Said Sam-

sung implementation relies on proprietary and undoc-

umented hardware which is a major criticism. We

analyse all essential ﬁndings to compare them with

the suggested SKMS idea depicted in Fig. 1.

,→ Observation 2.1.1. The overall complexity

of ARM’s TrustZone concept, where a dedicated

hardware-based keystore or Keymaster Trusted Ap-

plication (TA) already follows the solid principle of

operation of a Hardware Security Module (HSM)

by performing all cryptographic operations within its

conﬁnes. Still, Keymaster TA must also entrust user

space applications with the housekeeping of the actual

keys albeit in a “wrapped” form and shape (utilising

its hardware-embedded key).

,→ Challenge 2.1.1. Android is a full OS with hun-

dreds of applications installed on a single device.

Hence, there is the need for a key hierarchy based

on key wrapping or similar protection as otherwise

the TEE would need to provide considerable protec-

ted storage space for all such keys.

,→ Strategy 2.1.1. The ﬁrst conclusion we draw from

this observation is that in the typical IoT space where

the “business logic” is mostly implemented by the

server to minimise the computational load on the end

devices, simplicity is the key both to efﬁciency and

sustainability given that less complex software is nat-

urally less error-prone and thus the attack surface is

intuitively reduced. In other words, a dedicated ﬁrm-

ware incorporating crucial functions such as cryp-

tographic primitives and required security protocols

(e.g., TLS) is unlikely to need hundreds of different

cryptographic keys or a TEE-like key hierarchy. Even

if a business logic does require numerous keys in such

a monolithic and use-case speciﬁc ﬁrmware, then we

would argue that a similarly monolithic HSM-like

cryptographic co-processor with exclusive access to

key material and encapsulation of all cryptographic

operations within its cryptographic boundary would

reduce the need for key wrapping. In Section 4, we

indicate a possible design of such a module. Also,

if implemented with separate data buses (Harvard ar-

chitecture), speciﬁcally at the level of the suggested

co-processor, it would diminish the need for shared

memory or memory mapping. However, that alone

would not remove the natural susceptibility of hard-

ware to reverse-engineering given direct physical ac-

cess – hence the next observation. ■

,→ Observation 2.1.2. The underlying vulnerability

could only be uncovered and fully exploited through

substantial reverse-engineering. However, the authors

did not have to go so far as to target the secure hard-

ware unit due to the design ﬂaw of the related API

as well as unnecessary exposure through backward-

compatibility which in turn enabled the downgrade

attack. The previous observation and conclusion sug-

gests that this could be ﬁxed by software which is not

immutable (i.e., reverse-engineered software can be

amended).

,→ Challenge 2.1.2. Present design focuses on a par-

ticular dimension only (e.g., software) and its in-

terfaces while taking the other (here hardware) for

granted or vice versa. Carefully crafted “security by

design” to combine several realms is thus more difﬁ-

cult to implement later in production.

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

584

,→ Strategy 2.1.2. While software can be extracted

or leaked such that it can then be dismantled separ-

ately, hardware reverse engineering is usually only

possible in an ofﬂine state implying direct physical

access and device theft to begin with. The latter is

not too far fetched which is why ultimately a symbi-

otic design strategy could lead to construction of key

material in a way that it neither exists statically in-

side a hardware enclosure, nor relies on software or

ﬁrmware alone. Furthermore, design elements that do

not require any subsequent modiﬁcation like crypto-

graphic primitives (but still need tamper-resistance)

should be encapsulated by a hardware-based crypto

engine including all critical algorithmic parameters,

e.g., IVs. Incidentally, application-controlled IVs

were the root cause of the Samsung vulnerability. So,

if software does not contain or control any secrets

and if hardware does it exclusively, we conclude that

to thwart both software and hardware reverse engin-

eering, key material must not be stored persistently

as opposed to the common root-of-trust approach or

quite speciﬁcally here the device-unique, but perman-

ent 256-bit AES key (Root Encryption Key) inside the

crypto engine that the Keymaster TA relies on. ■

,→ Observation 2.1.3. The above-mentioned IV re-

use threat was created by allowing app-layer code to

handle IVs without any safety checks. Paired with

the single static platform key, integrity could be com-

promised despite a solid choice of the underlying

cryptographic primitive (AES-GCM). Consequently,

all reliant device security schemes like FIDO2 (pass-

wordless authentication) were completely exposed.

Incidentally, FIDO2 among others also relies on pre-

fabricated static Attestation Keys re-used across all

devices of the same manufacturer. This shows how

predominant the root-of-trust design still is in present

security schemes.

,→ Challenge 2.1.3. It has long been known that solid

random numbers are best generated in hardware rely-

ing on true sources of entropy like crystal oscillators

(Ergun and Maden, 2021). However, those dedicated

integrated circuits create an additional dependency.

Additionally, software-based Pseudo Random Num-

ber Generators (PRNG) like in Barker and Kelsey’s

study (Barker and Kelsey, 2015) only use a fraction of

‘true’ entropy in their initial seeds. Selecting and cor-

rectly referencing a proper entropy source for seeds is

usually exposed through an API creating a potential

pitfall for high-level application developers. Correct

initialisation and handling of PRNGs at runtime (e.g.,

possible buffer overﬂows or memory corruption) is

yet another software-induced caveat.

,→ Strategy 2.1.3. Beyond the beneﬁcial isolation of

critical functions through hardware as discussed in

the previous challenge, there is added value in rely-

ing on an independent cryptographic hardware unit:

as will be discussed in the subsequent section dedic-

ated to the design challenges of a PUF, noise gener-

ated by any PUF can be used beneﬁcially for solid

random numbers. Those can be harvested directly in

hardware and subsequently used on-the-ﬂy for IVs,

SALT, or similar. If implemented as part of the crypto

engine or PUF controller (see Fig. 1), this security-

relevant function is completely out of reach of app-

layer code and its programmers. Furthermore, PUF

noise depending on the underlying hardware elements

like DRAM cells (Miskelly and O’Neill, 2020) can

reach considerable size simply because there will be

most likely several GB of memory on any IoT module

in use today. This ensures not only constant access to

fresh entropy, but can also eliminate the need for soft-

ware PRNGs given the volume of randomness. ■

,→ Observation 2.1.4. Another aggravating aspect of

the Samsung design shortcoming is the (natural) fact

that their API is “hookable”, which means that soft-

ware calls can be intercepted by a malicious hand-

ler to manipulate critical parameters at will. In this

case, it led to an effective downgrade attack as legacy

key BLOB version could be requested by the ‘hook’

(malicious call handler). This begs the exacerbating

question as to why legacy key BLOBS were allowed

to begin with which according to the authors did not

seem to have any sensible reason.

,→ Challenge 2.1.4. Software interfaces need to rely

on platform security mechanisms which are less likely

to withstand privileged adversaries, malware, or ma-

jor OS exploits. The latter have been shown (Brand,

2021) to work over a network, undiscovered, despite

low-level protection like kernel/boot-loader integrity

checks based on eFuses.

,→ Strategy 2.1.4. We have stipulated through the

notion of an isolated crypto engine where security

parameters must not be exclusively handled by high-

level applications. The underlying HSM principle en-

forces isolation such that the client (app-layer code

or ﬁrmware in general) either sends over cleartext to

be encrypted or likewise provides ciphertext to be re-

turned upon decryption. Key principle of operation is

that all important keys are generated and kept within

the cryptographic boundary. The symbiotic approach

(see Section 4) extends this by incorporating the PUF

controller into the crypto engine while also making

the PUF dependent on the ﬁrmware to make the res-

ulting entropy changeable if compromised. This cre-

ates a symbiotic link between software and hardware

in the secret derivation process at runtime. ■

,→ Observation 2.1.5. The authors brieﬂy discuss a

supply-chain threat which is possible speciﬁcally with

Design Rationale for Symbiotically Secure Key Management Systems in IoT and Beyond

585

root-of-trust security schemes. Another considerable

attack vector is patching of the Keymaster Hardware

Abstraction Layer through software.

,→ Challenge 2.1.5. Even recent speciﬁcations like

Cooper et al.’s work (Cooper et al., 2020) stick to

the root-of-trust principle which is highly convenient

from the manufacturer’s perspective. However, at the

very least, they must introduce various sub-protocols

(e.g., Transfer Ownership Protocol 0 through 2), rout-

ing requirements, ownership vouchers, device attest-

ation certiﬁcate chains, and other precautions all of

which inﬂate the complexity. As noted, higher com-

plexity may increase attack surface and is difﬁcult to

maintain both from the trust and technical perspect-

ives. Patching is also hard to avoid as Android’s

history clearly shows. In this non-monolithic state,

weakness of one critical system service is likely to

compromise the others, if not the entire OS.

,→ Strategy 2.1.5. If complexity is a concern, then

a ‘clean slate’ solution like (Bartsch and Huebner,

2019b) provides a much more transparent zero-trust

like alternative, especially for an arbitrary supply

chain. A security architecture incorporating zero

knowledge-based bootstrap and over-the-air update

mechanisms conveys provable trust given that end-

devices can be deployed off-the-shelf with just a min-

imal security logic inside (i.e., bootloader, see Fig.

1) that does not contain any embedded secrets. Con-

sequently, every device creates its own unique key

during enrolment which is then used in the zero know-

ledge protocol for mutual pre-authentication and for-

ward secrecy-enabled trafﬁc encryption in absence of

any root of trust. This creates a secure out-of-band

channel for want of (pre-deployed) digital certiﬁcates

required in TLS communication mandated by every

cloud-based IoT offering today.

However, end-devices in this scheme still rely on

OTP memory with an alternative eFuse seal. Thus,

a device whose secret has been extracted through a

physical attack cannot be recovered anymore. A re-

medial option implies the use of PUFs to make secrets

volatile, hence we explore their design in the follow-

ing section. This is because PUFs have their own lim-

its and challenges (e.g., noise, temperature depend-

ency, ageing) including the worst case that if a device-

speciﬁc pattern has been discovered, such a PUF has

essentially been broken too. Thus, we not only dis-

cuss strategies to integrate PUFs in a symbiotic fash-

ion to make them dynamic when compromised, we

also suggest in Section 4.2 how ML can be utilised

to create an independent integrity control for end-

devices and fulﬁll the realistic requirement for com-

prehensive analysis against ML-enabled adversaries

in a symbiotic context. Ultimately, we advocate that

a zero knowledge like scheme can be created to pro-

tect the acquisition of the hardware ﬁngerprint of any

device during the ML training phase (initial enrol-

ment) given its secret nature. ■

In summary, the idea of an SKMS that beneﬁcially

utilises all of its essential elements should be much

better poised to withstand the discussed attacks.

2.2 Physical Unclonable Functions

We know from (Neshenko et al., 2019) that not only

is it imperative to create new strategies (both tech-

nical and non-technical) to increase awareness of

IoT threats to reduce the risk of exposure, but also

to work out (external) capabilities to leverage data-

driven measurements and methodologies for detect-

ing exploited IoT devices. IoT and Cyber-Physical

Systems (CPS) are usually part of a larger distributed

infrastructure with scalable computational power for

empirical or analytical needs. With respect to PUFs

in particular, this means the entire distributed archi-

tecture could ideally be utilised to both deﬁne/control

the unclonable function and constantly monitor its in-

tegrity/susceptibility to local or physical attacks. This

is especially true in all critical infrastructure suppor-

ted by IoT/CPS which may or may not be directly ex-

posed to a powerful (internal) adversary. Thus, the

“external view” and the spectrum of its added values

can be manifold.

Traditional PUFs derive entropy from unique

characteristics of hardware in order to generate reli-

able ‘storage-less’ key material and/or unique device

identiﬁers (Pappu, 2002), (Gassend et al., 2002). In

and of themselves, PUFs are naturally limited in re-

gard to symbiotic architectural design as they collect

such uniqueness from a single immutable dimension.

Given ideal properties, a PUF would be suitable to

shoulder the majority of the security burden with re-

gard to authentication or key management, wherein

the manifestation of reliable, unpredictable, just-in-

time cryptographic data would reinforce what has the

potential to be the weakest link in a secure system.

Such a PUF could be deployed almost as a ‘silver

bullet’ hardware unit to solve the problem of sufﬁ-

ciently secure ultra-lightweight systems. Much of the

literature surrounding the application of PUFs take

these ideal properties as an assumption at the hard-

ware level, which is seldom the reality. Currently,

PUFs continue to fall short of the mark in many as-

pects, often introducing promising features at the ex-

pense of bringing new vulnerabilities/performance is-

sues to light. Resultantly, there is scepticism sur-

rounding the idea that a true PUF is even at all pos-

sible. We identify issues regarding PUFs and argue

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

586

that while various PUFs are highly limited in their

role as primary security element in a given system,

they still may play an ideal role as a component in

more comprehensive symbiotic security design, such

that no one PUF feature is overly emphasised, yet

each is utilised by its strength. We identify current

challenges surrounding modern PUF design, and de-

termine how each could be mitigated/exploited by

symbiotic security design.

,→ Observation 2.2.1. A PUF would ideally be en-

tirely reliable, where environmental conditions do not

affect the PUF to output the exact same output for

every measurement. With the primary means of en-

tropy deriving from sub-atomic variations in the PUF

material, noise is an inevitable feature that must be

dealt with to reduce measurement instabilities.

,→ Challenge 2.2.1. Commonly, issues regarding

PUF reliability are tackled with various forms of er-

ror correction as an accepted resource overhead, yet

it has been shown that publicly known helper data

required for error correction can provide adversaries

with sufﬁcient information to successfully comprom-

ise the security of PUFs (Delvaux and Verbauwhede,

2014), (Strieder et al., 2021). It is well known that

environmental conditions, most notably temperature,

have dominant effect on the physical characteristics,

such as, e.g., the clock skew of a processor. If one

learns and knows this dependency, it is possible to

ﬁlter it out and determine a stable value which can

enable identiﬁcation. A sensor, however, is required

to measure a given environmental condition which re-

quires additional equipment and is often unfeasible in

the targeted scenarios. A method which does not re-

quire explicit knowledge of the environmental condi-

tion would solve this problem. This introduces new

concerns on how best to manage the noisy nature of

PUFs given a sufﬁciently strong (and very reasonable)

threat model.

,→ Strategy 2.2.1. Common or comparable AI-

assisted techniques can help overcome environmental

variance issues in PUFs to improve reliability with re-

gard to the resulting entropy (Wen and Lao, 2017).

In addition, environmental effects on physical sys-

tems – hence what originally causes a reliability prob-

lem – can be exploited as a beneﬁt, enabling anom-

aly/intrusion detection and device identiﬁcation based

on known individual behaviours in various operat-

ing conditions, provided training processes can be

ofﬂoaded to server computation within the scheme.

Therefore in essence, environmental effects on hard-

ware characteristics can be eliminated by consider-

ing their dependency and adjusting the correspond-

ing characteristic value based on the sensed condi-

tion. Since such sensors are not present in most off-

the-shelf devices, we propose a strategy which elim-

inates such dependencies without explicit knowledge

of the sensor value. The idea is to learn legitimate

combinations of hardware characteristics under dif-

ferent conditions (reﬂected by measurements at dif-

ferent times). This can be done by considering several

devices at the same time, or alternatively, using dif-

ferent, statistically independent, physical parts of one

device (e.g., part of a PUF). The practicability of this

idea was demonstrated by Lanze et al (Lanze et al.,

2014), where the effect of temperature variations on

clock skew enable physical device ﬁngerprinting for

identiﬁcation of wireless access points. In that work,

the authors applied one-class SVM to learn legitimate

combinations of devices at a particular location. ■

,→ Observation 2.2.2. Arguably the most import-

ant feature to be provided by a PUF is unpredictabil-

ity/unclonability, such that it is impossible for an ad-

versary to generate a ‘copy’ of the target which ex-

hibits identical behaviour. Failure to ensure this com-

promises PUF secrets, enabling an adversary to im-

personate devices or decrypt collected encrypted net-

work trafﬁc. PUFs are popularly proposed in a lim-

ited variety of use cases, such as for authentication

token generation or repeatable key storage. For gen-

erating unique authentication tokens, a Strong PUF is

required (strong not indicating the security properties

of the PUF, rather its ability to generate unique tokens

exponentially with PUF size), where each token is

discarded after use to prevent replay attacks.

,→ Challenge 2.2.2. Novel Strong PUF designs

are commonly proven to be insecure against Ma-

chine Learning Modelling Attacks (ML-MA), creat-

ing rightful skepticism on whether a truly attack res-

istant Strong PUF implementation is possible given

enough data (Rührmair et al., 2010). Once the PUF

is compromised in common PUF-based security pro-

tocols, the entire scheme is compromised, leaving de-

signers with little room to enhance threat models suf-

ﬁciently for a realistic IoT threat environment.

,→ Strategy 2.2.2. We argue that the PUF entropy

may be exploited as a single hardware entropy unit to

be integrated tightly with – not on top of – a coincid-

ing software-based entropy solution. Such integration

creates a dependency between both sources, relieving

some pressure for per-bit unpredictability as adversar-

ies should be required to simultaneously model the

software entropy, hardware entropy, and the depend-

ency between both. ■

,→ Observation 2.2.3. The superposition of physical

hardware component ﬁngerprints can be used to as-

sess the integrity of the system.

Design Rationale for Symbiotically Secure Key Management Systems in IoT and Beyond

587

,→ Challenge 2.2.3. It is to design, if possible, a non-

intrusive method for ﬁngerprinting hardware compon-

ents for detecting deviations, e.g., when a hardware

component is replaced.

,→ Strategy 2.2.3. We propose to use methods of

physical device ﬁngerprinting to learn characterist-

ics of the devices and detect replacement of them,

or, any anomalies in the environment. The emphasis

is on the methods allowing stable ﬁngerprints that,

from one side, would allow for unique identiﬁca-

tion of the hardware in the environment and, from

another side, would not interfere with regular func-

tionality and communication. Hence, we propose to

use passive remote hardware ﬁngerprinting methods

to achieve this goal. ■

,→ Observation 2.2.4. Even encrypted communica-

tion channels can be used for trafﬁc analysis purposes.

The goal of trafﬁc analysis is to extract particular in-

formative patterns from the trafﬁc without breaking

the encryption. The communication patterns, as a

side-channel, can be further applied to detect attacks

with the network trafﬁc.

,→ Challenge 2.2.4. Perform passive trafﬁc analysis

and learn with the help of ML techniques a reliable

representation of the communication in the system.

,→ Strategy 2.2.4. Similar to the suggested resol-

ution of the temperature variations with the help of

ML, AI-assisted meta data analysis can be utilised to

observe the communication behaviour of IoT devices

with the rest of the infrastructure (back-end) in an

non-obtrusive way. Techniques like trafﬁc analysis

can be used to learn regular communication patterns

and to detect any deviations from the learned patterns.

Approaches for this kind of anomaly detection have

been successfully applied in CPS (Schneider and Böt-

tinger, 2018). The focus is hence shifted towards data

in transit security and resilience by using the same re-

sources and a similar technique. ■

,→ Observation 2.2.5. As many common PUF

designs consist of custom arrangements of logic com-

ponents (e.g., Arbiter PUF variants (Gassend et al.,

2002)), they must either be synthesised directly into

the end device early in the supply chain, or, integrated

onto the end device later in the supply chain.

,→ Challenge 2.2.5. Both approaches incur a man-

ufacturing overhead, as custom integration must be

included at some level. Additionally, this feature af-

fects the ﬂexibility of integration of a PUF solution,

further affecting backward compatibility across mul-

tiple generations of devices, a key feature also identi-

ﬁed for a coinciding software-based entropy module

in Strategy 2.1.4.

,→ Strategy 2.2.5. We suggest designers consider

the use of software PUFs which utilise already on-

chip resources to generate physical entropy, such

as memory-based or processor PUFs (Miskelly and

O’Neill, 2020), (Tsiokanos et al., 2021). The implic-

ations of integrating such PUFs enable the hardware

entropy unit to become more modular and thus inde-

pendent of the supply chain. ■

,→ Observation 2.2.6. Due to the mentioned ML-

MA vulnerabilities, there exists a requirement to in-

clude an ML-capable adversary in the threat model

when including PUF-based primitives in a symbiotic

security system in order to evaluate against such ML-

based modelling attacks.

,→ Challenge 2.2.6. Most modelling attacks are per-

formed using linear ML methods suitable for mod-

elling (mostly) linear PUFs (Rührmair et al., 2010).

Certain PUFs were proposed with enhanced non-

linearity to counter modelling attacks, which were

shortly after shown to be insecure to ML algorithms

better suited for non-linear function approximation

such as PAC learning and Evolutionary Algorithms

(Ganji et al., 2016) (Delvaux, 2019). As a result,

more exploratory ML methods are likely required to

fully evaluate the PUF-based aspects of the symbiotic

design such that it is proven sufﬁciently secure.

,→ Strategy 2.2.6. Tying PUF-based entropy closely

with software mechanisms will likely provide strong

non-linearity to the overall PUF function, yet not

necessarily prevent modelling attacks given enough

data. We propose system designers to consider ML

attacks which act upon exploration and exploitation

in their iterative learning such that PUF entropy can

be ensured. State-of-the-art Adversarial Reinforce-

ment Learning (ARL) based approaches will likely be

useful/required to truly evaluate the modelling resili-

ence of the SUF, such that given sufﬁcient data, any

information leakage (and thus correlative properties

between different inputs and outputs) is detected. ■

3 REQUIREMENTS & DESIGN

OBJECTIVES

Connected and physically exposed IoT systems op-

erate at an intersection of physical and cyber do-

mains. Consequently, they are more affected than,

e.g., servers accessible by authorised personnel only.

Security requirements for IoT systems must guaran-

tee their resistance against software-based attacks; at-

tacks over network connections; and physical attacks

against their hardware components. Moreover, the

threat model must consider ML-MA against PUFs as

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

588

discussed in Strategies 2.2.2 and 2.2.6. Symbiotic se-

curity also requires defence-in-depth, i.e., the ability

of one range of protections to compensate for cases

when an adversary has overcome other defences. In

the context of key management, SKMS should be

able to provide an acceptable residual security even

if some key material has been compromised and re-

place that key within an adequate period of time. This

gives rise to the following design considerations:

• The system should be distributed, rather than

monolithic, to withstand a concentrated attack.

• Its unique information (such as IDs or crypto-

graphic keys) must be adaptive, rather than im-

mutably static, such that it can be replaced in the

case of a partially successful attack.

• The secret handling should be as transparent

and dynamic as possible, using zero-trust or

even zero-knowledge principle of operation to

avoid exposing key material. Examples are

enhanced bootstrap-like mutual authentication

schemes such as ZKIE.

• Protections must cover not only static data-at-rest

(e.g., stored in memories), but also data-in-transit

during their processing.

• The system must support external monitoring

and/or self-observation. AI-assisted metadata

analysis can play a crucial role here, and an inter-

esting open question is whether it can be applied

to encrypted data in transit.

In the following section, we make a proposal for an

approach that fulﬁlls the listed requirements.

4 SKMS DESIGN RATIONALE

In this section, we summarise all essential strategies

discussed thus far in Fig. 1. The depiction of SKMS

covers its fundamental communication paths to out-

line the relationship between the secure IoT module

incorporating such an SKMS and the core services

hosted by a cloud back-end originally introduced and

discussed in Bartsch and Huebner’s work (Bartsch

and Huebner, 2019b).

4.1 Core Building Blocks

SKMS uses an unclonable function to eliminate the

static key storage need whilst overcoming its natural

limitation of being immutable as far as the hardware-

based characteristics are concerned. This shall be

achieved by an interplay of hardware and software

such that a monolithic ﬁrmware implements only the

necessary device logic. Cryptographic functions shall

be used by said ﬁrmware through a dedicated API ex-

posed by the low-level HSM-like Crypto Engine as

part of the SKMS forming an essential SSC.

Key material is produced through a resultant set of

entropy within an isolated part of the volatile memory

(Isolated RAM) which can only be read out by the

Crypto Engine via a dedicated data bus. Alongside

its Crypto Engine API, the Crypto Engine shall also

expose a Secrets/Entropy Selector interface such that

the high-level application can address certain areas of

the overall entropy space (i.e., byte array) for purpose-

bound cryptographic keys (e.g., 256 bits for AES en-

cryption). The resulting entropy is created at run time

by the Entropy Multiplexer (a dedicated hardware

unit) to collect hardware-based entropy and combine

it with the ﬁrmware-intrinsic entropy through a suit-

able unkeyed one-way function. The ﬁrmware itself

shall only be the carrier of entropy without any hard-

coding in source code. Thus, a Firmware Dispenser

would process the ﬁrmware to add an ‘entropy layer’

to it. Following the principle of Zero Trust or Zero

Symbiotic Key

Management System

Symbiotic

Unclonable

Function

«Container»

Zero

Knowledge

Initial

Enrolment API

«Container»

Metadata

Analyser /

AI Service

Metadata API

Zero

Knowledge

Initial

Enrolment

«Container»

OTA

Database

OTA

«SW»

Embedded

Bootloader

«HW»

Crypto

Engine

«HW»

Isolated

RAM

Crypto Engine API

IRAM databus

Secrets/Entropy Selector

«HW»

Entropy

Multiplexer

«SW»

Firmware

Image

«HW»

Hardware

Entropy Provider

«SW»

Firmware

Dispenser

Developer

Interface

get firmware

image

provides

fingerprint data

for adaptive

attack analysis

provides data

flow samples

for adaptive

attack analysis

connects via

plain TCP to

create Zero

Knowledge

OOB channel

uses for Zero

Knowledge

computation

based on a

unique secret

key, Secure

Boot etc.

supplies

firmware

image

Contributes

dynamic

entropy bits

exclusive R/O

access

exclusive W/O

access

exposes

crypto

operations

enumerates

the entropy

byte array

within the

Isolated RAM

uses

selects key

for crypto

operation

Contributes

hardware

entropy

Figure 1: Symbiotic Key Management System.

Knowledge even, every SoC/IoT module shall be de-

livered to its designated environment with just a prim-

itive Embedded Bootloader inside. On arrival, the IoT

Design Rationale for Symbiotically Secure Key Management Systems in IoT and Beyond

589

module shall establish an encrypted and mutually au-

thenticated Out-of-Band (OOB) channel through that

bootloader. The latter leverages the Crypto Engine

and a subset of entropy to generate the Zero Know-

ledge secret as well as execute the protocol as such.

The Zero Knowledge Initial Enrolment (ZKIE) con-

tainerised logic unit shall then look up a use case spe-

ciﬁc ﬁrmware for the device in question and deliver it

back to the requester via the secure OOB channel.

4.2 AI Services

To ensure continuous operational stability and to

implement an external hybrid Intrusion Detection

scheme (IDS), a Metadata Analyser/AI Service shall

on the one hand receive the initial device helper

data/ﬁngerprint to be followed up by regular updates

thereof (e.g., by means of Out-Of-Distribution or

OOD data). On the other hand, this service shall

also acquire the initial and regular samples of en-

crypted device trafﬁc to be able to conduct (real-time)

metadata analysis of data in transit past the AI train-

ing phase. The ultimate goal is to detect data leak-

age or malicious modiﬁcation both at the device level

(data at rest integrity) and at the network level (data

in motion integrity). Ultimately, if an alert is is-

sued, the device shall be instructed to self-erase and

more importantly receive a fresh subset of entropy

through a new ﬁrmware image to form a new res-

ultant set of entropy and to go through yet another

ZKIE life cycle. In other words, compromised mod-

ules must no longer be decommissioned thanks to the

full wipe and key rollover mechanism implemented

in this way. To also ensure the robustness of this

hybrid IDS approach over time and make it gener-

alised against OOD data (e.g., as a result of zero-

day attacks), further research is needed to devise suit-

able error-based concept-drift detectors as part of the

backend infrastructure which will also ideally suggest

when both the anomaly-based and signature-based in-

trusion detector models need enhancement over time.

In this regard and in this proposal, Adversarial Rein-

forcement Learning (ARL) frameworks could prove

to be beneﬁcial as they have been shown to enhance

the performance of IDS for imbalanced and evolving

data environments such as in 6LoWPAN (Pasikhani

et al., 2022), which is similar to the suggested archi-

tectural constraints.

4.3 Discussion

The proposed scheme addresses the above-mentioned

observations and challenges as follows. It supports

simple ﬁrmware and does not require non-trivial

memory mapping (,→ 2.1.1). It relies on software

and hardware, thus complicating reverse engineering

(,→ 2.1.2). An independent hardware unit in charge

of generating random bits isolates critical resources

such as IVs (,→ 2.1.3) from incorrect app-level us-

age; it avoids hookable APIs (,→ 2.1.4), and enables

ZKIE (,→ 2.1.5). The SUF component incorpor-

ates AI-enabled temperature compensation (,→ 2.2.1)

and is protected against attacks on multiple levels:

hardware-software integration overcomes modeling

attacks (,→ 2.2.2, 2.2.6) and supply-chain threats (,→

2.2.5); ﬁngerprinting detects manipulation attempts

(,→ 2.2.3); AI-assisted meta-data analysis identiﬁes

anomalous usage. In summary, SKMS has the poten-

tial to provide defence-in-depth security in resource-

restricted IoT environments.

5 CONCLUSION

In this paper, we analyse critical issues and threats

in current KMS through a broad discussion of sub-

stantial vulnerability of the Samsung implementation

of ARM’s original TEE design. Following the obser-

vations and derived strategies around this attack, we

postulate security requirements and deduce a novel

SKMS for IoT. Our idea extends the symbiotic se-

curity concept introduced in an earlier study that uses

software and hardware for designing efﬁcient yet se-

cure IoT. In this proposal, we avoid attack-prone static

key storage and generate entropy for key material

on-the-ﬂy through a combination of functions based

on physical variations and pseudo-random bits pre-

deployed in the system ﬁrmware. Furthermore, the

derived keys are encapsulated in a crypto engine API

offering encryption or authentication, while the actual

key bits remain completely invisible to applications.

The resulting design of a hardware-based SUF and

software-level protections ensures that the system re-

mains intact even if one of the hardware- or software-

level protection mechanisms is attacked. Lastly, we

brieﬂy discuss the notion and importance of an AI-

based hybrid IDS to create an outside view of the end

device regarding its susceptibility to relevant attacks

which are best detected by external components.

REFERENCES

Barker, E. and Kelsey, J. (2015). Recommendation for Ran-

dom Number Generation Using Deterministic Ran-

dom Bit Generators. In NIST Special Publication.

Bartsch, W. and Huebner, M. (2019a). Efﬁcient System

Design of Scalable Ultra Low Power Architectures

with Symbiotic Security. IEEE VCaSL, 5(4):4–11.

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

590

Bartsch, W. and Huebner, M. (2019b). Reference Ar-

chitecture for Secure Cloud Based Remote Automa-

tion – Zero-knowledge Initial Enrolment of Resource-

constrained IoT with Symbiotic Security. atp

magazin, 61(9):72–82.

Brand, M. (2021). In-the-wild Series: Android Exploits /

Project Zero.

Cooper, G., Behm, B., Chakraborty, A., Kommalapati,

H., Mandyam, G., Tschofenig, H., and Bartsch, W.

(2020). FIDO Device Onboard Speciﬁcation.

Delvaux, J. (2019). Machine-Learning Attacks on Poly-

PUFs, OB-PUFs, RPUFs, LHS-PUFs, and PUF-

FSMs. IEEE TIFS, 14(8):2043–2058.

Delvaux, J. and Verbauwhede, I. (2014). Attacking PUF-

Based Pattern Matching Key Generators via Helper

Data Manipulation. In Proc. of CT-RSA’14, volume

8366 of LNCS, pages 106–131. Springer.

Ergun, S. and Maden, F. (2021). An ADC Based Ran-

dom Number Generator from a Discrete Time Chaotic

Map. In Proc. of APCC’21, pages 79–82. IEEE.

Ganji, F., Tajik, S., Fäßler, F., and Seifert, J.-P. (2016).

Strong Machine Learning Attack Against PUFs with

No Mathematical Model. volume 9813, page

391–411. Springer-Verlag.

Gassend, B., Clarke, D., van Dijk, M., and Devadas, S.

(2002). Silicon Physical Random Functions. In Proc.

of CCS’02, page 148–160. ACM.

Lanze, F., Panchenko, A., Braatz, B., and Engel, T. (2014).

Letting the Puss in Boots Sweat: Detecting Fake Ac-

cess Points Using Dependency of Clock Skews on

Temperature. In ASIA CCS’14, pages 3–14. ACM.

Miskelly, J. and O’Neill, M. (2020). Fast DRAM PUFs

on Commodity Devices. IEEE Trans. Comput.-Aided

Des. Integr. Circuits Syst., 39(11):3566–3576.

Neshenko, N. et al. (2019). Demystifying IoT Security:

An Exhaustive Survey on IoT Vulnerabilities and a

First Empirical Look on Internet-scale IoT Exploit-

ations. IEEE Communications Surveys & Tutorials,

21(3):2702–2733.

Pappu, R. (2002). Physical One-Way Functions. Science,

297.

Pasikhani, A. M., Clark, A. J., and Gope, P. (2022). Ad-

versarial RL-based IDS for Evolving Data Environ-

ment in 6LoWPAN. IEEE TIFS, 17:3831–3846.

Rührmair, U. et al. (2010). Modeling Attacks on Physical

Unclonable Functions. In Proc. of the 17th ACM CCS

Conference, page 237–249. ACM.

Schneider, P. and Böttinger, K. (2018). High-Performance

Unsupervised Anomaly Detection for Cyber-Physical

System Networks. In ACM CPS-SPC’18, pages 1–12.

Shakevsky, A., Ronen, E., and Wool, A. (2022). Trust Dies

in Darkness: Shedding Light on Samsung’s TrustZone

Keymaster Design. In Proc. of USENIX Security’22.

Strieder, E., Frisch, C., and Pehl, M. (2021). Machine

Learning of Physical Unclonable Functions using

Helper Data: Revealing a Pitfall in the Fuzzy Com-

mitment Scheme. IACR TCHES, (2):1–36.

Tsiokanos, I. et al. (2021). DTA-PUF: Dynamic Timing-

Aware Physical Unclonable Function for Resource-

Constrained Devices. ACM JETC, 17(3).

Wen, Y. and Lao, Y. (2017). Enhancing PUF Reliability by

Machine Learning. In ISCAS’17, pages 1–4. IEEE.

Design Rationale for Symbiotically Secure Key Management Systems in IoT and Beyond

591