Silicon-Integrated Security Solutions Driving IoT Security

Stephan Spitz and Alexander Lawall

IU International University of Applied Science, Juri-Gagarin-Ring 152, 99084 Erfurt, Germany

Keywords:

Silicon-Integrated Security, Internet of Things (IoT) Security, Industrial Internet of Things (IIoT) Security.

Abstract:

Internet of Things (IoT) devices still miss in many cases an ability to prove their identity, verify conﬁguration

changes based on a solid root-of-trust or have a data conﬁdentiality protection anchored in hardware. This

paper describes how to bridge between service-level security functionalities and a deeply silicon-integrated

security solution, which is part of a larger System-on-Chip (SoC) for the beneﬁt of increased security. Such

a bridging raises new demands regarding silicon manufacturing, the Secure Operating System design, and

also the communication and management interfaces. This is because in comparison to a “classical” Trusted

Platform Module (TPM), no dedicated security hardware is available. This article describes the Sytem-on-

Chip security integration’s impact on increasing the security level of the IoT service layer. “Integrated” refers

to a secure enclave, which is no longer located on a separate chip, because it is part of the SoC of a larger

device together with many other components on the same piece of silicon e.g. application/modem-processor

cores, integrated memory and high-bandwidth I/O interfaces. A further aim of this paper is to create awareness

about the capabilities of SoC-integrated security functions so that they can be leveraged by software designers,

who are usually not deeply familiar with hardware security.

1 INTRODUCTION

Security mechanisms, which are not anchored in

hardware, can be in most cases circumvented by soft-

ware tools and exploits. Such tools are available

for hackers at low cost and usually do not require

an investment in expensive hacking hardware. This

has been early recognized by initiatives such as the

Trusted Computing Group and resulted in several

speciﬁcations deﬁning how hardware can be lever-

aged to secure the software stack. Nevertheless, sepa-

rate security hardware such as a TPM is vulnerable to

attacks on its external interfaces e.g. the data commu-

nication on the serial bus. Even when external secure

elements raise the hurdle for attackers, the attack sur-

face is still high with such externally accessible I/O

interfaces. This changes when the secure element be-

comes integrated with the other building blocks on the

same System-on-Chip (SoC). As a result, the inter-

face changes from an external to an internal connec-

tion to the bus of the SoC. Consequently, the whole

technology stack changes, which is built on integrated

security solutions. This starts from seeding the Root-

of-Trust (RoT) into the integrated security enclave up

to leveraging the seeded cryptographic material in se-

curity features such as secure update management or

attestation of the IoT device. This paper sketches how

to close the chain from the security hardware up to the

security-critical services by highlighting the neces-

sary basic cryptographic mechanism. In comparison

to many other papers, a holistic approach is sketched

linking the worlds of silicon security and cyber secu-

rity.

2 EVOLUTION FROM SEPARATE

SECURITY CHIPS TOWARDS

SILICON-INTEGRATED

SECURITY

The evolution described in this section is the foun-

dation for linking security services on the application

level to deeply integrated security enclaves in a SoC.

The opportunities to improve security beyond classi-

cal security chips, such as a TPM are high, but a dif-

ferent technology stack is required. In comparison to

a separate TPM chip, an integrated security solution

requires a Secure OS, which is tightly interfacing with

the high-bandwidth I/O capabilities of the SoC, cf.

ﬁg. 1. Multiple applications and services, which are

executed in the richOS or Real-Time OS (RTOS) on

398

Spitz, S. and Lawall, A.

Silicon-Integrated Security Solutions Driving IoT Security.

DOI: 10.5220/0012350200003648

Paper published under CC license (CC BY-NC-ND 4.0)

In Proceedings of the 10th International Conference on Information Systems Security and Privacy (ICISSP 2024), pages 398-402

ISBN: 978-989-758-683-5; ISSN: 2184-4356

the main CPU Cores, require concurrent security sup-

port by services of the Secure OS. As a result, the new

Secure OS of an integrated solution needs to be capa-

ble of high data rates, multitasking, and concurrent

process execution. Secure concurrent communication

over the Internet Protocol (IP) e.g. Transport Layer

Security (TLS) requires the support of asynchronous

encryption and decryption processes performed in the

Secure OS.

Figure 1: Separate Secure Element attached to a larger

System-on-Chip vs. System-on-Chip-integrated Security.

Another difference between a TPM Firmware and

a Secure OS for the SoC integration is the boot pro-

cess. The SoC-integrated Secure OS is powered

up together with the whole SoC ﬁrmware and ri-

chOS/RTOS. This results in a new highly security-

critical dependency on the whole boot process and

power management of the SoC. The integrity of the

Secure OS needs to be veriﬁed during the SoC’s Se-

cure Boot to ensure that no software is loaded, that

has been modiﬁed by an attacker.

In comparison to a TPM chip with integrated Non-

Volatile Memory (NVM), integrated ﬂash memory

and One-Time-Programmable (OTP) memory are ex-

pensive resources on a generic purpose SoC. For this

reason, many low-end SoCs rely on external ﬂash

connected with a high bandwidth interface to the SoC,

which is function-wise not a big difference. From a

security perspective, the Secure OS code and data are

highly exposed in this external ﬂash memory and can

only be stored encrypted. The used encryption tech-

nology needs to be highly ﬂexible and secure because

ﬂexible swap-in and swap-out processes have to be

supported. Leakage of information during read and

write cycles to external memory has to be avoided,

especially during the execution of critical crypto rou-

tines. As a result, the Secure OS architecture has to

take into consideration the en-/decryption of external

storage, especially with the design of crypto routines.

Another memory-related difference is the neces-

sity for monotonic counters in a Secure OS. A retry

count for a PIN Unlock Key (PUK) (PIN can be un-

blocked, but not PUK) is probably the most famous

kind of a monotonic counter, but there are many other

security use cases, that require a certain security state

that cannot be reverted. A TPM, which is a special

type of Smart Card controller, implements monotonic

counters in a secure NVM protected together with

the secure microcontroller. Such a design is with a

larger generic purpose SoC not possible. Moreover,

expensive OTP memory is in a very low amount avail-

able, which is not sufﬁcient to secure all the required

state machines and atomic processes. As a conse-

quence, new ways to implement the security feature

“monotonic counters” are required on a SoC (Win-

bond, 2018).

Also, new ways to achieve tamper-resistance of

a SoC are required, which a TPM has already per

se. Similar to a Smart Card semiconductor, security-

relevant structures have to be protected by active mea-

surements such as metal shielding, a scrambled data

bus, or sensors for detecting an attack. It is obvious

that this bears some challenges for the chip design and

also the generic silicon manufacturing process (Arm,

2018).

In addition, the generic SoC manufacturing lines

have to be ramped up to create the necessary secu-

rity foundation cryptographic- and security-wise, es-

pecially for the previously mentioned Secure Boot

process (IAR, 2018a). The creation of the so-called

Root-of-Trust (RoT) forms the security foundation for

a Secure Boot and all the other later required security

processes, as well as for deploying and loading the

Secure OS and the required individualization and per-

sonalization processes. Since devices such as wear-

ables, smartphones, or IoT sensors can be personal-

ized in a much later stage, this RoT ensures a robust

device identity and allows an attestation service to

prove the integrity of the device’s software, especially

the Secure OS.

3 ARCHITECTURAL CONCEPTS

3.1 Architectural Aspects Related to a

Secure OS

All the previously described differences between sep-

arate TPM and SoC-integrated security OSs make it

obvious that there is an impact on OS architecture,

which cannot be ignored (Spitz, 2012). One of the

most obvious changes in the Secure OS architecture

is the introduction of an OS kernel in conjunction

with multitasking capabilities. A hardened µKernel

seems to be a good ﬁt for an integrated security solu-

tion, especially as the process isolation and minimal

size contribute to security and robustness. A standard

Silicon-Integrated Security Solutions Driving IoT Security

399

µKernel architecture is required for the process iso-

lation of a Memory Management Unit (MMU). With

larger SoCs, a MMU is an inherent part also available

for the security enclave. Smaller (IoT-)SoCs without a

MMU can at least incorporate a kind of Memory Pro-

tection Unit (MPU) to support isolated memory for

different kinds of services executed by the Secure OS

in a pre-emptive way.

Multitasking enables secure asynchronous high-

bandwidth communication with internal and external

interfaces of the SoC. There are different possibili-

ties to connect a SoC-based security enclave to other

peripherals and the main processor. The OS design

has to take this into account and provide drivers and

protocols for this interaction. Typically, the asyn-

chronous behavior is implemented in the form of a

mailbox concept, which allows the exchange of high

amounts of data between security-critical and normal

processes in a dedicated memory space.

Another security-critical piece of software resid-

ing outside the Secure OS is the Secure Boot. The se-

curity foundation is formed by the Secure Boot, which

contains the necessary RoT to encrypt and verify the

integrity of the Secure OS during boot time. Typi-

cally the Secure OS is loaded from ﬂash memory in an

early bootstage and initialized with the cryptographic

keys stored encrypted in the memory. The necessary

master keys and integrity protection and veriﬁcation

mechanism are part of the Secure Boot (IAR, 2018b).

3.2 SoC Security Architecture

Measurements against fault injection and side channel

attacks are essential for every hardware security solu-

tion, which a TPM is. Since silicon, which is manu-

factured in a generic line, offers fewer capabilities for

such measurements, security features incorporated in

the hardware and ﬁrmware IP become more impor-

tant, cf. ﬁg. 2.

Security aspects, which can be already part of

the hardware IP, are strong hardware-based isolation

mechanisms such as arm TrustZone™ or a separate

secure processor core such as ARC SEM™ (Synop-

sys, 2016). In addition, security-critical SoC-based

components can be isolated from normal processing

components e.g. memory or I/O peripherals, which

are only available in a secure execution mode.

The ﬁrmware is essential to safeguard the

security-relevant components of the SoC e.g. secure

memory or secure processing units. The security

boundaries are deﬁned during the boot of the plat-

form and integrity checks for all low-level driver and

ﬁrmware components are necessary. A staged secure

boot has to initialize all secure processing compo-

nents before the standard processing components are

booted to guarantee that the standard process has no

inﬂuence on the security settings, especially access to

critical cryptographic keys.

Figure 2: Stack of an Integrated Security Solution.

4 LIFE-CYCLE MANAGEMENT

OF INTEGRATED SECURITY

SOLUTIONS

4.1 The Role of a Root-of-Trust

A robust RoT, which is already embedded in the SoC

during production, creates the security anchor for se-

cure service life-cycle management of the whole de-

vice including the Secure OS and its applications

(IAR, 2018a). The life-cycle management includes

the deployment, change, and complete deletion of

security-critical code and data, especially identity-

related information. Such identity-related informa-

tion can concern the identity of the device itself or

identities for roles to manage access to the device.

Moreover, a RoT is a pre-condition for establish-

ing a secure channel to the device, which allows the

seeding of identities even when the device is in an

insecure environment. Based on the RoT an authenti-

cated and secure channel can be established, which al-

lows the download of security-critical data even when

the device is already in the ﬁeld at any point later

e.g. for maintenance operations. The RoT enables the

necessary security binding between the device and an

external trusted entity by a cryptographic handshake.

Such a handshake can leverage pre-seeded asymmet-

ric or symmetric keys and can span a key hierarchy for

later identity management on the device. It is worth

mentioning that the RoT is located outside the secure

OS because it has to be established before the Secure

OS is deployed on the device. A Secure Boot loader

incorporating the RoT is responsible for the integrity

of the whole SoC and all the software executed on the

device. The SoC must have the necessary capabili-

ICISSP 2024 - 10th International Conference on Information Systems Security and Privacy

400

ties to protect the master keys, which are part of the

RoT. These are asymmetric keys, i.e. public-private

key pairs, and they are applied as described in the fol-

lowing chapters. Public keys require integrity protec-

tion because this information needs not be kept conﬁ-

dential. Private keys should be device individual and

highly conﬁdentiality protected.

4.2 Life-Cycle Management Operations

The secure life-cycle management of a device con-

tains the following aspects:

• Veriﬁcation of the SoC/device identity and in-

tegrity also from remote, cf. (Sundar et al., 2019)

• Integrity protection of code and data during load-

ing and runtime, especially protection of the Se-

cure OS, cf. (Wang et al., 2019)

• Secure remote download of a user identity (per-

sonalization)

• Secure disabling of the SoC/device e.g. for end-

of-life, over production control, and grey market

prevention

• Establishment of end-2-end secure communica-

tion channels for any kind of life-cycle operation

e.g. conﬁguration or ﬁrmware update

• Authentication and authorization of user access,

conﬁguration changes, download of code, or any

other administrative actions

• Delegation of rights and permission, especially

delegation of control to third parties e.g. with the

change of ownership

For a more detailed description the following exam-

ple processes, describing how a robust RoT can be

leveraged, have been chosen:

• a) Identiﬁcation of the SoC or device

• b) Authorisation of an administrative action, code

or data

• c) Authentication of the issuer of an administra-

tive action

• d) Conﬁdentiality protection of code, data, and

administrative commands

4.2.1 Identiﬁcation of a System-on-Chip

In scenario a), the RoT can comprise an identity and a

private key, which is securely stored in the bootloader

of the SoC during manufacturing, cf. ﬁg. 3. Now

the Secure OS in the device gets a request to authen-

ticate the device and attest its identity. This request

is in conjunction with a random number, which the

Secure OS encrypts by using the private key stored in

the RoT. The verifying entity outside the device can

decrypt the response with the help of the public key.

The device has proven its identity if the result is the

same as the previous random challenge.

Figure 3: Device Identity Veriﬁcation.

4.2.2 Authorisation and Authentication of an

Administrative Action

In scenarios b) and c), it is vice versa i.e. the RoT

holds a public key, cf. ﬁg. 4. Now the external entity

has a private key and can authorize an administrative

action, deploy code or read/write data in the Secure

OS. The issuer of the administrative action is in this

scenario automatically identiﬁed, because the private

key can be uniquely assigned to a person, legal entity,

IT system, etc.. This assignment is done in the form

of a Public Key Infrastructure (PKI). It is also worth

mentioning that in this case, the public key on the de-

vice has to be protected from modiﬁcations and ex-

change, but conﬁdentiality protection is not required.

The RoT has just to ensure integrity protection and

not only the Secure OS on the device can have read

access to this public key.

Figure 4: Authorisation of Remote Management.

4.2.3 Conﬁdentiality Protection of Data

Scenario d) requires a hybrid encryption scheme

i.e. a combination of a symmetric and an asym-

metric encryption, because asymmetric algorithms

are performance-wise not suited to encrypt larger

amounts of data, cf. ﬁg. 5. In this combination, the

symmetric key is just temporarily generated and sent

with the encrypted data to the device. The symmet-

ric key itself is again encrypted with the public key of

the device. The Secure OS has access to the private

key of the device stored in the RoT and can in the ﬁrst

Silicon-Integrated Security Solutions Driving IoT Security

401

step encrypt the ephemeral symmetric key and in the

second step encrypt the data using this symmetric key.

This scenario is highly relevant when personalization

data is sent to the device e.g. a subscriber proﬁle for

an integrated SIM (ETSI, 2017) or payment creden-

tials for an Integrated Secure Element (iSE).

Figure 5: Conﬁdentiality Protection.

5 CONCLUSION

Due to the advances in silicon-integrated security, a

new generation of deeply embedded security solu-

tions is rising, which will have an impact on the whole

industry involved e.g. personalization processes are

no longer bound to secure premises of highly special-

ized manufacturers such as the Smart Card industry.

The value chain is changing and different technolo-

gies are becoming more relevant for integrated secu-

rity solutions such as security Hardware IP or a robust

Root-of-Trust deployed in the system from the begin-

ning.

Moreover, paradigm shifts with security services,

OS- and silicon-security-architecture offer opportuni-

ties for new businesses, but also replace existing tech-

nologies and processes in the classical Smart Card in-

dustry. This journey has just started and will offer

the end-user more convenient and robust security so-

lutions in the end. End-users currently see the tip of

this iceberg with the disappearance of SIM cards, pay-

ment capabilities in smartphones, remote feature en-

ablement with cars, and many other security-critical

IoT functions. Of course, the robustness of smart-

phones and IoT devices against any kind of attack

is signiﬁcantly increased by a good security design,

which is anchored in the silicon. Security design as-

pects will move in the foreground with an integrated

security enclave because security moves tighter to the

central processing of the data in the main CPU. These

advantages can be only leveraged when already con-

sidered in the service design.

Last, but not least is worth mentioning that inte-

grated security enclaves are more vulnerable to so-

phisticated side-channel attacks than tamper-resistant

external secure elements. However, recent develop-

ments show that is possible to implement mecha-

nisms to achieve tamper resistance already by the sil-

icon (Arm, 2018). However, this is an additional re-

search topic, which makes no difference for the secu-

rity chain, which has been sketched in this paper.

REFERENCES

Arm (2018). Cortex-m35p a tamper-resistant

cortex-m processor with optional software

isolation using trustzone for armv8-m. In

https://developer.arm.com/products/processors/cortex-

m/cortex-m35p. Arm.

ETSI (2017). iuicc poc group primary plat-

form requirements, approved release.

In https://www.gsma.com/newsroom/wp-

content/uploads/UIC.03 v1.0.pdf. ETSI.

IAR (2018a). Building a supply chain of

trust: Understanding secure mastering. In

https://www.iar.com/support/resources/articles/secure-

mastering. IAR.

IAR (2018b). Establishing a supply chain of

trust: Start with secure development. In

https://www.iar.com/support/resources/articles/secure-

development. IAR.

Spitz, S. (2012). Mobicore® secure os for arm® trustzone®

soc. In https://prezi.com/rgrvv8vv-t4s/mobicore-

secure-os-for-arm-trustzone-soc/. Prezi.

Sundar, S., Yellai, P., Sanagapati, S. S. S., Pradhan, P. C.,

et al. (2019). Remote attestation based software in-

tegrity of iot devices. In 2019 IEEE International

Conference on Advanced Networks and Telecommu-

nications Systems (ANTS), pages 1–4. IEEE.

Synopsys (2016). Designware arc sem security processors.

In https://www.synopsys.com/dw/ipdir.php?ds=arc-

sem. Synopsys.

Wang, W., Zhang, X., Hao, Q., Zhang, Z., Xu, B., Dong,

H., Xia, T., and Wang, X. (2019). Hardware-enhanced

protection for the runtime data security in embedded

systems. Electronics, 8(1):52.

Winbond (2018). Winbond introduces trustme™ secure

ﬂash memory aligned with platform security architec-

ture from arm. In https://www.winbond.com/hq/about-

winbond/news-and-events/news/news00452.html.

Winbound.

ICISSP 2024 - 10th International Conference on Information Systems Security and Privacy

402