Implementing Secure Applications

Thanks to an Integrated Secure Element

Sylvain Guilley

1,2,3 a

, Michel Le Rolland

and Damien Quenson

Secure-IC S.A.S., Tour Montparnasse, 27th ﬂoor, 75015 Paris, France

TELECOM-Paris, Institut Polytechnique de Paris, 19 Place Marguerite Perey, 91120 Palaiseau, France

École Normale Supérieure, 45 rue d’Ulm, Département d’informatique, CNRS, PSL University, 75005 Paris, France

Secure-IC S.A.S. Headquarters, 15 rue Claude Chappe, Bât. B, 35510 Cesson-Sévigné, France

Keywords:

Integrated Secure Element, Host Protection, Certiﬁcation Schemes, Security Flexibility, Internet of Things.

Abstract:

More and more networked applications require security, with keys managed at the end-point. However, tradi-

tional Secure Elements have not been designed to be connected. There is thus a need to bridge the gap, and

novel kinds of Secure Elements have been introduced in this respect.

Connectivity has made it possible for a single chip to implement multiple usages. For instance, in a smart-

phone, security is about preventing the device from being rooted, but also about enabling user’s online privacy.

Therefore, Secure Elements shall be compatible with multiple requirements for various vertical markets (e.g.,

payment, contents protection, automotive, etc.). The solution to this versatility is the integration of the Secure

Element within the device main chip. Such approach, termed iSE (integrated Secure Element), consists in the

implementation of a subsystem, endowed to manage the chip security, within a host System-on-Chip.

The iSE offers ﬂexibility in the security deployment. However, natural questions that arise are: how to pro-

gram security applications using an iSE? How to certify those applications, most likely according to several

different schemes?

This position paper addresses those questions, and comes up with some key concepts of on-chip security, in

terms of iSE secure usage. In particular, we will show in this paper that iSE nowadays shall be designed so that

the product it embeds is certiﬁable in a multiplicity of schemes, and so even before the product is launched on

the market.

1 INTRODUCTION

We are witnessing the rapid development of our dig-

ital society, which is characterized by the explosion

of the number of handheld and IoT devices. In this

context, the security of the end-points is essential, as

those objects represent an obvious entry point for at-

tackers into the whole platform. Actually, the end-

points are nowadays entrusted to secure the link start-

ing from the device up to the cloud. Such end-to-end

security is achieved by designing a solid root-of-trust

which stems from the device. It is the role of the “Se-

cure Element” to implement such fundamental secu-

rity foundation.

From a historical perspective, the Secure Element

has known several successive development stages:

• It was initially discrete, and designed mainly to

https://orcid.org/0000-0002-5044-3534

defend themselves (i.e., it features anti-tampering

capabilities);

• Then, it has become more aware of the security

of the application, and has thus been termed “em-

bedded”. It may consist in legacy discrete Secure

Element, but adapted to smaller form factors and

implemented closer to the circuit it protects;

• Eventually, some Secure Elements have become

integrated into the main chip of the end-point de-

vice. Consequently, it got melted as a subsystem

within the host chip it protects.

The Secure Elements, under those three avatars,

enforce end-point security principles. Namely, they

implement:

• Minimum Surface Exposition: in that the inter-

face of a Secure Element is reduced to as few pins

and functions as possible. For instance, one can

remember ISO/IEC 7816-2 standard (ISO/IEC

566

Guilley, S., Rolland, M. and Quenson, D.

Implementing Secure Applications Thanks to an Integrated Secure Element.

DOI: 10.5220/0010298205660571

In Proceedings of the 7th International Conference on Information Systems Security and Privacy (ICISSP 2021), pages 566-571

ISBN: 978-989-758-491-6

7816, 2014), published back in the late 80’s,

which required compliant smartcards to have only

one single in/out (IO) pin for the communication

with the external world, in half-duplex.

• Defense in Depth: Secure Elements implement

several layers of protection. For instance, the Se-

cure Element is typically entrenched behind a de-

fensive layer, be it physical (e.g., SPI or Serial

line) or logical (e.g., protocol break through mail-

boxes).

• Minimal Complexity Rationale: the control logic

in Secure Elements is crafted to be focused on its

security mission, and is thus not polluted by in-

terference with other businesses, which are left to

the “rich world”.

The proper implementation of those security princi-

ples is veriﬁed through a process known as “certi-

ﬁcation”, whereby a third party laboratory assesses

the product documentation and performs a counter-

expertise in terms of offensive security testing.

In this position paper, we account for the raise of

the integrated Secure Element (referred to as “iSE” in

the sequel), and explain the challenges linked with its

adoption. The argumentation is oriented towards ex-

plaining the stakes regarding security requirements,

the technological evolution (connected devices, life-

cycle management, etc.) and the moving normaliza-

tion landscape. The targeted audience is the security

solution architects aiming at gaining a pedagogical

overview about end-point security trends.

Contributions. We list the advantages of the iSE

over the traditional approach using a Secure Element

located outside of the main end-point chip. Then, we

discuss integration examples, for different representa-

tive applications. Most importantly, we provide a ra-

tionale for multiple simultaneous vertical market re-

quirements, and account for a strategy for the chip

hosting the iSE to get multiple certiﬁcations accord-

ing to various different schemes. The key concept of

the iSE “intellectual property” block pre-certiﬁcation

is introduced and we demonstrate its advantages over

the state-of-the-art.

Outline. The rest of this article is structured as fol-

lows. The current trends in user’s requirements are

described and analyzed in Sec. 2. This section moti-

vates for the relevance of iSE paradigm. The instanti-

ation of iSE in different contexts is the topic of Sec. 3.

This section shows that iSE architecture can be pro-

tean within the host chip, depending whether the host

can be trusted or not. Finally, our conclusions and

perspectives are in Sec. 4.

2 CURRENT NEEDS

2.1 Embedded versus Integrated Secure

Elements

Comparison. The ﬁgure 1 illustrates the layout dif-

ference between embedded and integrated Secure El-

ements. The left side of this ﬁgure shows the secure

chip and its companion Secure Element, connected by

a SPI (Serial Peripheral Interface) link. In the right

side, one can see the iSE, as a security subsystem

buried into the applicative chip (termed the “host”).

The symbioticity of the iSE with its host provides

more natural and better performing security applica-

tion.

Since Secure Elements are off-the-shelf compo-

nents, an attacker can easily analyze a discrete Secure

Element in a “training mode” on some samples before

launching his sharpened attack on the targeted prod-

uct. At the opposite, the iSEs are more protected since

the attacker shall ﬁrst do some reverse-engineering to

identify the iSE resources to target.

Embedded Secure Elements. are stereotyped cir-

cuits, such as Trusted Platform Modules (TPM).

Many such chips can be produced in large series, lead-

ing to economies of scale. But this gain comes with

the fact that the electronic board is more complex,

since there are two chips to integrate and solder. In

addition, embedded Secure Elements have ﬁnite re-

sources, and can be somehow restricted in their us-

age, e.g., lack memory. Moreover, although they can

be certiﬁed, they typically are so only for one appli-

cation.

integrated Secure Elements (iSEs). are cus-

tomized for each host chip. This does not preclude

some level of reuse, on the contrary, but the hardware

of the iSE shall be recompiled. One advantage is that

the iSE can be taylored to meet exactly the require-

ments of each application, in terms both of security

level and performances. Regarding board-level inte-

gration, the iSE solution is cheaper since it does not

add a dedicated chip (it is integrated into a System-

on-Chip).

In addition, the iSE has at its disposal large

amount of resources, as most of those can be shared

with the host (such as various kinds of memories

connectivity, debug capabilities, etc.). Moreover, the

For instance non-volatile FLASH, One-Time Pro-

grammable (OTP) or electric fuses, Random Access Mem-

ories (RAM), etc.

Implementing Secure Applications Thanks to an Integrated Secure Element

567

board (PCB)

printed circuit

system bus

secure chip

iSE

host

secure chip

embed d ed Secure Element:

(SPI)

integrated Secure Element:

Figure 1: Comparison between embedded versus integrated Secure Element.

iSE is more efﬁcient since it can naturally interface

with various applications (e.g., it is on the same die

as the host applicative code it is responsible to check

upon “secure-boot”, the crypto services offered by the

iSE can access the data to encrypt/sign/authenticate

within one clock cycle, etc.). Reciprocally, the iSE

can also help with the veriﬁcation of further exter-

nal resources, such as the conﬁguration’s authentic-

ity veriﬁcation of host clock/power module, memory

management unit (MMU), debug JTAG port, etc. In a

nutshell, the iSE is extraverted, in that it can directly

protect its host and other resources. This “mutual

win-win exchange” is illustrated in Fig. 2.

Regarding application ﬁnetuning, the iSE can

have its code debugged directly within the host, which

is an advantage for the ease of integrated chip pro-

totyping (including host along with iSE, simultane-

ously).

2.2 Modern Requirements

Beyond the form factor considerations, we now un-

derline that there are more fundamental driving fac-

tors for iSE to be considered as the best option. One

major compelling reason is that current chips are so

complex that they are not specialized for only one ap-

plication, but instead provide multiple services. For

instance, one single chip can enable payment, access

to digital contents, (private) social networks, etc. The

security management of heterogeneous applications

(so-called “apps”), each requiring a different security

scheme, can rapidly become a nightmare with discrete

Secure Elements, where it can be elegantly fulﬁlled

with the iSE paradigm.

Even more, iSE is future-proof, in that new apps

(with speciﬁc security requirements) can be installed

after deployment. This stays true even if applica-

tions are not known nor foreseen upon chip design.

This on-ﬁeld ﬂexibility is appreciable in the context

of highly competitive market segments where invest-

ments on the chip are carried out ahead of full knowl-

edge of market potentialities.

3 USE-CASES WITH iSE

This section presents some typical integration pat-

terns of a Secure Element in a security chip.

3.1 Programmer’s Model

The cornerstone of security management in a Secure

Element is the concept initially forged by RSA Labs

company in the standard PKCS #11 (OASIS, 2020).

It consists in segregating security objects from actions

which can be carried out on them. Namely, in PKCS

#11, keys are kept within the Secure Element, and the

user can only request actions on them through an Ap-

plication Programming Interface (API). When imple-

mented correctly (Delaune et al., 2008), it is proven

that whatever the actions from the user side, keys can-

not cross the border between the SE and the host. Cor-

rect implementation requires nonetheless some atten-

tion, such as carefully attributing roles to keys, other-

wise API-level attacks can apply (Clulow, 2003).

Now in practice, there can be several ways to in-

tegrate the iSE within the host. Those variants de-

pend on the perceived likelihood of host corruptibil-

ity. Namely, an illustration is provided in Fig. 3. The

security application is represented as

(for the

code) and (for the secret data). Three typi-

cal application partitioning schemes are presented in

this ﬁgure.

(a) When it is assumed that the host is likely to be

compromised (but not the iSE), then actions are

carried out on the Application Processor (AP),

and keys are kept concealed within the iSE;

(b) When the protocol cannot easily be split between

actions and objects, and that the host is assumed

untrusted, then the whole secure applications re-

sides within the iSE: actions are executed by the

iSE processor;

then the iSE boundary can be dissolved: the keys

ICISSP 2021 - 7th International Conference on Information Systems Security and Privacy

568

iSE

Reset (released upon secure boot)

JTAG (for veriﬁcation & debug)

controller

MMU

controller

Clock/power

secure (host) chip

iSE

FLASH

(for keys

OTP/eFuse

Commu ni cation ports (secure updates)

management)

storage)

(for life cycle

RAM (for complex crypto. or OS)

Host resources protected by iSE:

Host resources used by iSE:

Figure 2: (left) Resources the iSE requires from the host to extend its functional capabilities; (right) Host resources the iSE

can verify.

are managed by the iSE and the actions (even

complex, i.e., unproven in terms of harmlessness

should the code be manipulated, e.g. by a bug ex-

ploitation or a malware) are performed by the host

AP.

Notice that technologies such as Global Platform

Trusted Execution Environment (TEE (Global Plat-

form, 2020b)) can be seen as a virtualization of iSE.

Indeed, TEE consists in an API which allows for a

given host to behave two-fold:

• in a regular manner, termed “Rich Execution En-

vironment”, where untrusted apps can be run, and

• in a secure manner, termed “Trusted Execution

Environment”, with logical and/or physical seg-

regation of resources, including memory, timers,

random number generators, etc.

The security of TEE technology is mature, as there is

even a Protection Proﬁle which formalizes it (Glob-

alPlatform Device Committee, 2016). Now, physical

security is explicitly out of the scope of TEE, hence a

TEE is not sufﬁcient per se to play the role of a Se-

cure Element. However, many practical attacks have

been reported (Cerdeira et al., 2020; Novella, 2020).

Side-channel attacks, and in particular cache-timing

attacks, represent a large number of them.

3.2 Some Examples of iSE Usage

Some standards actually impose an iSE, such as

Global Platform (GP) Virtual Primary Platform

(VPP (Global Platform, 2018)) speciﬁcation, as

used for instance in European telecommunications

standards institute (ETSI) Smart Secure Platform

(SSP (ETSI, 2019)) standard. Also, in the following

use-cases, we highlight in particular that different us-

ages require different certiﬁcation schemes.

Application: Platform Security

The host runs the application, and asks the iSE for key

management and cryptographic services. Examples

of applications are PKCS #11 (OASIS, 2020) (as in

Hardware Security Modules) and TCG TPM (Trusted

Computing Group, 2019). This use-case is adapted to

an architecture corresponding to case (a) in Fig. 3.

Application: iSIM (Integrated SIM, i.e.,

Integrated Subscriber Identity Module)

The iSE is the enclave. It ensures the secure execution

of the application, such as GP VPP (Global Platform,

2018) or ETSI SSP (ETSI, 2019). The case (b) of

Fig. 3 is suitable for this use-case. Typical security re-

quirements are enunciated in Common Criteria (Con-

sortium, 2013) Protection Proﬁle PP0084 (Bunde-

samt für Sicherheit in der Informationstechnik, 2014).

Since IoT devices cannot manage discrete SIM cards,

the market is shifting to this iSE paradigm.

Application: Secure Communication

In this application, the iSE is ofﬂoading the host for

cryptographic computations; therefore, the iSE can be

dissolved amidst the host, as in case (c) of Fig. 3.

Such architecture is suitable for protocols such as

EVITA (FP7 European Project, 2020), IEC 62443 (In-

ternational Society of Automation (ISA, https://www.

isa.org/), 2020), or Car2Car V2X PP (CAR 2 CAR

Communication Consortium, 2019). Speciﬁcally, this

latter reference clearly shows the paradigm shift from

embedded (Figure 1) to integrated (Figure 2) Secure

Element, called “HSM” for “Hardware Security Mod-

ule” in automotive market parlance.

Implementing Secure Applications Thanks to an Integrated Secure Element

569

/ / /

system bus

iSEAP

secure chip

system bus

iSEAP

secure chip

system bus

iSEAP

secure chip

Case (b): Case (c):Case (a):

Figure 3: Different instantiations of an iSE within an host chip. Cases (a) and (b) are suitable when the host can be subverted

(e.g., it can be “rooted”); Case (a) works for simple applications where the speciﬁcation is designed to gracefully split control

and data, whereas (b) is used for complex applications, e.g., which require an Operating System (OS). Case (c) is the natural

solution for those chips which are shielded from the outside world, hence protected by design from remote infection.

Application: Root-of-Trust (e.g., Open Compute

Project (OCP Security, 2020), Open Titan (Open

Titan, 2020))

Here, the iSE is responsible for booting an external

host, which is typically a server in a Cloud infrastruc-

ture. As the root-of-trust is standalone in its chip, ar-

chitectural case (c) of Fig. 3 is also sufﬁcient. There is

no security standard in place for now for this segment.

3.3 How to Ensure that the Device is

Pre-certiﬁable?

As one can see, there are multiple certiﬁcation

schemes. It might happen that one of the certiﬁca-

tion is required late in the product life cycle, e.g., after

that the product is manufactured. We deﬁne the term

“pre-certiﬁcation” as the action to anticipate a future

certiﬁcation. This concept is disruptive as, tradition-

ally, certiﬁcation was a necessary milestone to enter a

market. However, nowadays, the context is different

for several reasons:

• Some chips are so versatile that they can be de-

ployed in various market verticals, e.g., IoT, in-

dustry, telecommunication stations, etc. which are

each governed by different security standards.

• Obtaining consensus on security regulation can

take a long time. For instance, Global Platform

SESIP (Global Platform, 2020a) certiﬁcation has

been proposed by the industry to remedy for the

lack of relevant international normative require-

ments in the ﬁeld of IoT.

• Users sometimes adopt technologies before the

security model is completely understood; this is

for instance the case with IoT, massively deployed

as smart home assistants, smart assistants, wear-

able health trackers, etc. (see (ETSI, TC CYBER,

2019, §1)).

Such proactive attitude requires some precautions to

be taken, amongst which:

• Preparation of a clear documentation, including

user manuals and test plans;

• Sound design decisions, e.g., implementation of

roles, of error management, etc.

• Functional features like keys zeroization (cf.

NIST FIPS 140 (NIST FIPS, 2009)) shall be sup-

ported, etc.

In addition, pre-silicon actions are necessary. For

instance, using a Physically Unclonable Func-

tion (Bruneau et al., 2018) to implement the mas-

ter key is a bullet-proof security-by-design presilicon

choice. Also, pre-silicon security evaluation (Souissi

et al., 2019) allows to attest of resistance against at-

tacks even before product production stage. Some

Common Criteria schemes (typically the NSCIB in

the Netherlands) have already started to evaluate vir-

tual products, i.e., their source code, before it is im-

plemented.

Clearly, adjustments in the design can be ﬁne-

tuned at software level, and documentation might

need some elaboration, but those are minor changes

if the underlying precautions have been respected.

4 CONCLUSIONS AND

PERSPECTIVES

The integrated Secure Element (iSE) is emerging as

a novel paradigm for ensuring the end-point secu-

rity. The iSE brings ﬂexibility in the security manage-

ment, in that iSE can support various security applica-

tions. Moreover, by being instantiated directly within

the host chip, it can protect several resources (e.g.,

clock, reset, MMU, debug, etc.), and can be recon-

ﬁgured, hence it is future-proof. This highlights the

ICISSP 2021 - 7th International Conference on Information Systems Security and Privacy

570

need for pre-certiﬁed iSE, as an asset for the chip to

comply with different certiﬁcations, even before be-

ing launched on different markets.

Leveraging the iSE concept, further security appli-

cations can be envisioned. For instance, the iSE can

behave actively as a “cybersecurity probe” within the

device, responsible for reporting security events. This

opens the door for end-point devices used as sentinels

for gathering security threats at system-level. With

the capability to garner intelligence this way, secu-

rity analytics can be carried out. This allows for the

security operator to understand very precisely the at-

tacks perpetrated on the chip. Such information en-

ables him to proactively anticipate them, thereby re-

versing the advantage in favor of the defense side.

ACKNOWLEDGEMENTS

This work has been partly funded by the ARCHI-SEC

project (number ANR-19-CE39-0008).

REFERENCES

Bruneau, N., Danger, J., Facon, A., Guilley, S., Hamaguchi,

S., Hori, Y., Kang, Y., and Schaub, A. (2018). De-

velopment of the Uniﬁed Security Requirements of

PUFs During the Standardization Process. In SecITC,

Bucharest, Romania, November 8-9, 2018, volume

11359, pages 314–330. Springer.

Bundesamt für Sicherheit in der Informationstechnik

(2014). SI-CC-PP-0084-2014: Security IC Platform

Protection Proﬁle with Augmentation Packages. Ver-

sion 1.0. https://www.commoncriteriaportal.org/ﬁles/

ppﬁles/pp0084a_pdf.pdf.

CAR 2 CAR Communication Consortium (2019). Protec-

tion Proﬁle V2X Hardware Security Module. Version

1.4.0.

Cerdeira, D., Santos, N., Fonseca, P., and Pinto, S. (2020).

SoK: Understanding the Prevailing Security Vulnera-

bilities in TrustZone-assisted TEE Systems. In 2020

IEEE Symposium on Security and Privacy, SP 2020,

San Francisco, CA, USA, May 18-21, 2020, pages

1416–1432. IEEE.

Clulow, J. (2003). On the Security of PKCS#11. In Walter,

C. D., Çetin Kaya Koç, and Paar, C., editors, CHES,

volume 2779 of Lecture Notes in Computer Science,

pages 411–425. Springer.

Consortium, C. C. (2013). Common Criteria (aka

CC) for Information Technology Security Evalu-

ation (ISO/IEC 15408). Website: http://www.

commoncriteriaportal.org/.

Delaune, S., Kremer, S., and Steel, G. (2008). For-

mal Analysis of PKCS#11. In Proceedings of the

21st IEEE Computer Security Foundations Sympo-

sium, CSF 2008, Pittsburgh, Pennsylvania, USA, 23-

25 June 2008, pages 331–344. IEEE Computer Soci-

ety.

ETSI (2019). Smart Secure Platform (SSP) — ETSI TS

103 666-1 V15.0.0. https://www.etsi.org/deliver/

etsi_ts/103600_103699/10366601/15.00.00_60/ts_

10366601v150000p.pdf.

ETSI, TC CYBER (2019). EN 303 645 V2.0.0, Cyber Se-

curity for Consumer Internet of Things.

FP7 European Project (2020). E-safety Vehicle Intru-

sion protecTed Applications (EVITA). https://www.

evita-project.org/, accessed on Oct 27, 2020.

Global Platform (2018). Virtual Primary Platform (VPP)

v1.0.1. https://tinyurl.com/yybvbge4.

Global Platform (2020a). Security Evaluation Standard for

IoT Platforms (SESIP). Version 1.0. Document Refer-

ence: GP_FST_070.

Global Platform (2020b). Trusted Execution

Environment (TEE) Committee. https:

//globalplatform.org/technical-committees/

trusted-execution-environment-tee-committee/.

GlobalPlatform Device Committee (2016). TEE Protection

Proﬁle Version 1.2.1, GPD_SPE_021. https://www.

globalplatform.org/speciﬁcationform.asp?ﬁd=7831.

International Society of Automation (ISA, https://www.isa.

org/) (2020). ISA-62443-1-5. Security for industrial

automation and control systems Industrial automation

and control system protection levels.

ISO/IEC 7816 (2014). (Joint technical committee (JTC) 1 /

Sub-Committee (SC) 17), Identiﬁcation cards – Inte-

grated circuit cards. (details).

NIST FIPS (2009). (Federal Information Processing Stan-

dards) publication 140-3, Security Requirements for

Cryptographic Modules (Draft, Revised). page 63.

http://csrc.nist.gov/groups/ST/FIPS140_3/.

Novella, E. (2020). TEE-reversing: A curated list of

public TEE resources for learning how to reverse-

engineer and achieve trusted code execution on ARM

devices. https://github.com/enovella/TEE-reversing

(accessed December 7, 2020).

OASIS (2020). PKCS #11 TC. https://www.oasis-open.org/

committees/tc_home.php?wg_abbrev=pkcs11.

OCP Security (2020). Speciﬁcation of Root of Trust,

version 1.0. https://www.opencompute.org/projects/

security.

Open Titan (2020). Open source silicon Root of Trust (RoT)

project. https://opentitan.org/, accessed on Oct 28,

2020.

Souissi, Y., Facon, A., and Guilley, S. (2019). Virtual

Security Evaluation - An Operational Methodology

for Side-Channel Leakage Detection at Source-Code

Level. In Codes, Cryptology and Information Security

- Third International Conference, C2SI, Rabat, Mo-

rocco, April 22-24, 2019, pages 3–12.

Trusted Computing Group (2019). Trusted Platform Mod-

ule (TPM), Library Speciﬁcation, Family “2.0”, Level

00, Revision 01.59. https://trustedcomputinggroup.

org/work-groups/trusted-platform-module/.

Implementing Secure Applications Thanks to an Integrated Secure Element

571