The Vault

Security Aspects of Smart Cards in Machine-to- Machine (M2M) Advanced Mobile Network Applications
Research Paper / Jan 2009

Security Aspects of Smart Cards in Machine-to-

Machine (M2M) Advanced Mobile Network Applications

Mike Meyerstein1, Inhyok Cha, Yogendra Shah

InterDigital Communications Corporation LLC,

King of Prussia, PA, USA



Abstract. The Third Generation Partnership Project (3GPP) standardisation

group currently discusses advanced applications of mobile networks such as

machine-to-machine (M2M) communication. Several security issues arise in

these contexts which warrant a fresh look at mobile networks’ security
foundations, resting on smart cards. This paper contributes a security/efficiency

analysis to this discussion and highlights the role of trusted platform technology

to approach these issues.

Keywords: Smart card, UICC, machine-to-machine communication.

1 Introduction

The idea of M2M is that un-manned terminals, e.g. traffic cameras, meters, cargo

containers, can communicate with host servers using wireless global communications

networks. This requires the usual secure authentication for network access.

The networks will not be specially M2M-enabled, so the authentication has to

follow the standardised schemes currently in place for mobile (e.g. 3GPP) and fixed

(e.g. WLAN) networks.

M2M requirements [1] may make the conventional UICC a less advantageous

solution for secure authentication. It is necessary to look at the options for a non-

personalised security module to which a network operator’s Network Access
Application (NAA) can be downloaded [1]. This may be accomplished using an

embedded Trusted Environment (TRE) in a terminal. The TRE acts as a hardware

root of trust for the storage and execution of secure applications and may also have

protected software functions. The TRE may host downloaded software NAAs that

emulate the behavior of the USIM [2] or ISIM [3] applications.

1 Mike Meyerstein is the proprietor of Meyerstein Consulting Ltd, currently providing

consultancy services to InterDigital Communications Corporation

2 M2M Requirements

The M2M market has some definitive characteristics [1]:

Terminals may be in hard-to-reach locations (e.g. traffic cameras)

Terminals may become geographically dispersed over time (e.g. cargo

Owners of large populations of terminals may want to change the network
operator without visiting the terminals (e.g. to change the UICC).

Terminals need to be protected against unauthorised removal of UICC

Terminals may require over-network provisioning after sale or installation.

3 The Options for TRE for Secure Downloadable Identity

Client-side authentication technologies for M2M could include.

• UICC with download capability
• An embedded TRE in the terminal, to provide a secure execution and storage

environment. Authentication applications (Managed Identities or “MIDs”)
would be downloaded to the TRE over public IP networks.

• Smart token such as the new multimedia card with on-card UICC (or

A framework of standardised specifications is needed for the above solutions.


Regular or

USB+ large






Smart Token

e.g. secured


cards (SMC)

M2M functionality for

provisioning & management of “MIDs”
(Managed Identities), e.g. USIM, ISIM

Fig. 1. Options for Secure Environments for Downloaded Identity Credentials

The discussion within standardisation about the (dis-)advantages of the various

candidate solutions is lively and far from concluded.

In Table 1 on the next page we collect the main arguments that have been advanced

thus far


Currently standardised good medium (it could

be based partly on

TCG specs)


Currently available good medium (some

limited versions



Protection against

unauthorised removal

poor (good, if

M2M form

factor UICC is

soldered in)

good poor

Provides secure API good good not known

Does not require connector

and interface chips

poor good poor

MIDs can be downloaded poor. Can’t


good poor. Can’t
download NAAs

Key management suits M2M


poor (pre-shared

keys for


and download)

good (can use



Predictable costs poor (for full-

function, big




Good (part of



Secure channel to terminal poor


but usually not


good not known

Remote change of operator poor good poor

Open API for download poor good poor

Track record of trust good poor poor

Established infrastructure good Poor Good (fits UICC


Built into operator’s current
trust models

good Poor Medium (partly

fits UICC trust


Built into operator’s current
business models

good poor poor

Promotes operator’s current
brand image

good poor good

Table 2. Comparison of Solutions for Secure Downloadable Identity

No solution comes out as perfect, but the TRE shows promise if it can be

standardised. The UICC shows promise if its current limitations (including that of

lack of implementation of already-standardised features in cards and terminals) can be

overcome. In the next sections, we look at issues surrounding the use of UICC.

4 Smart Card Security in Mobile Networks: Why is the Smart

Card a Trusted Anchor?

Physical Tamper-Resistance:
An ISO-7816 [7], [8], [9] smart card has, in practice, a single-chip architecture

with little possibility of monitoring communications between different chips on the


Smart card ICs are designed and implemented to prevent probing and reverse-

engineering. They are fabricated on a dedicated production line in a secure facility.

Measures include scrambling of busses and of memory addresses, bonded passivation

layers, permanently disabled test points, self-generated programming voltage.

Proprietary, Secure O/S:

The Smart card’s standardised API, e.g. [4], consists of a restricted command set
that has no hidden commands or access methods. It is trusted because of its own built-

in security mechanisms and because of those of the underlying hardware platform. It

is non-updateable.

For applications such as USIM, the Ki and OTA keys are stored and accessed by

the O/S in proprietary ways. The O/S cannot be made to reveal the values or memory

locations of those data.

Conventional GSM SIM cards did not allow adding applications to a live card. The

advent of the Javacard [10] now allows applications on a multi-application UICC

platform to be updated, deleted or added to an issued card, either remotely or locally.

The potential of Javacard for Network Operators is currently restricted by

Implementation by Network Operators of only SMS as the bearer (for OTA
messages to the UICC), which has a very limited bandwidth

OTA security standards [11] are not profiled for IP bearers

Lack of a sufficiently rich terminal/UICC interface on nearly all MEs2

General concerns about the security of multi-application Javacards.

2A few terminals have implemented the JSR177 [12] terminal/UICC interface, but it’s usually

only the SIM toolkit part and not the general APDU API. A few Windows Mobile MEs have

allowed an open APDU API to the UICC, using the terminal’s RIL (Radio Interface Layer)
but it is not clear if those are still in production

In the world of telecoms, it is generally up to the buyer to perform a due diligence

test on the smart card vendor to ensure that the O/S has been properly developed and


Other Measures:

Smart cards include proprietary measures to prevent attacks such as slowing down

the external clock and measures against power analysis attacks by the use of noise-

free computational algorithms and/or injection of artificial noise and/or damping of

noise on the power rail. There are also said to be a large number of detailed

precautionary measures taken, some of which are described in the public domain (c.f.


Design and Development Process:

Security is designed into a smart card IC in the secure facilities of a semiconductor

manufacturer. The computers that are used for this are isolated from the rest of the

world. Undocumented counter-measures in the IC are supported by corresponding

design criteria. Once the O/S development is finished, the entire source code may be

checked by an independent evaluation.

Supply Chain:

There are only a handful of world-class vendors of smart cards, so it is feasible for

Network Operators to perform the necessary security audits. There will be an agreed

arrangement for transferring the Ki objects between network operators and UICC

vendors. Ki values cannot be retained in the vendors’ personalisation systems or be
discovered by system operatives.

Security Evaluations:

Card vendors have their O/S independently evaluated and MNOs perform security

evaluations of their card vendors’ products and facilities. GSMA [15] provides non-
public guidance to its members on how to do that. Common Criteria Protection

Profiles have been published for smart cards. One of these [16] is aimed at the

underlying IC platform but some are aimed at payment cards issued by financial

institutions such as Visa and Mastercard. Cost can be an issue for wider adoption of

these evaluation regimes. There are no standard specifications or protection profiles

for the security evaluation of telecoms smart cards such as UICCs.

UICC-Terminal Interface Security:

The UICC employs some security measures in the interface with the terminal:

User Authentication: PINs (called CHV1 and CHV2 in a SIM card),
provide some level of protection with user authorisation on the interface.

CHV1 can be disabled by the user, in which case there is no PIN-

protection for making calls. The use of CHV1 and CHV2 poses a security

vulnerability since the passwords get transported across the UICC-ME

interface in clear. The UICC does not authenticate itself to the user,

although 3G authentication [2] provides mutual authentication of the card

and the network. In M2M, a remote user could rely on two possible

methods of assuring himself of the authenticity of a UICC, i.e. (a) using a

remote access protocol that exploits a pre-shared or private key on the

UICC and/or (b) using e.g. Liberty Alliance [22] protocols to trigger the

UICC issuer to perform an authentication of the UICC and possibly

binding that to the remote access session,

Secure channels: Commands to the UICC are not secured unless they are
inside a 3GPP OTA envelope [11]. That is why ETSI and 3GPP have

recently specified secure channels and their key establishment methods

([5], [6]) across the terminal-UICC interface. ISO 7816 and EN726 [17]

define secure messaging between a terminal and a smart card but key

distribution was not defined (it being assumed that it would be based on

pre-installed keys). ISO7816 also defines a set of security-related

commands. Neither the ISO nor CEN techniques are included in UICC

specifications such as [4]. ETSI & 3GPP secure channel specs [5] and [6]

compliment the ISO and CEN standards by defining methods for key

distribution between the terminal and UICC. There does not seem to be

any reason to believe that normal terminals can be trusted to store the

distributed key. Protocols such as Global Platform [10], ETSI RAM/RFM

[18], [19] and 3GPP OTA [11] provide end-to-end security from server to

card for the purpose of loading and managing files and applications on the

UICC. They do not require a secure ME/UICC interface.3

Protection of data across the interface: All standardised command-sets of
a UICC are designed to be sent in the clear across the terminal/UICC

interface. Protocols that may be subject to replay attacks must have

counter-measures built in, e.g. the sequence numbers used in 3G

authentication [2]. In future, the Smart Card Web Server (SCWS) [23],

could use HTTPS/TLS to establish a secure tunnel from card to server (or

to terminal) via which usernames and passwords could be sent.

Access control: In general, access control lists (ACLs) are not used in
today’s UICC O/Ss. Access to file operations relies on the principle that if
the entity accessing the file can satisfy the access policy (embodied in the

File Control Parameters [4]), then it must be an authorised entity.

5 Meeting M2M Requirements with UICCs

Advent of the “Big SIM” UICC
Recent innovations in smart card technology could go a long way to enabling the

UICC to fulfill the M2M requirements. The new features described below, plus the

3 Remote Application Management can theoretically be used to download any Javacard

application to a UICC and to store it in a security domain. It does not currently apply to the

U(I)SIM applications, as there is no standardised mechanism for the UICC to extract and

store the Ki and algorithm customisation parameters. For the case of updating existing files

either locally or remotely, this is possible only where the access conditions in the File

Control Parameters can be satisfied. Remote (OTA) file update is possible on files in any

application on the UICC, but only if the files were OTA-enabled at the time the file was

created on the UICC

ability to store downloaded applications and multimedia files, would need the large

memory of “Big SIM”.

Large Memory: Recently, UICCs with flash memory of up to 2Gbytes have

become available.

High-Speed I/O: The conventional I/O speed of the UICC/terminal interface is

only a half-duplex 9.6Kbit/s4. In order to be able to move data on and off the Big SIM

in a meaningful timeframe, a USB interface has been specified in [13] and [8].

Smart Card Web Server (SCWS): The advent of Mega SIM with USB I/O enables

the UICC to support an IP stack and web server. There are a number of advantages to

this, e.g. use of (X)HTML to communicate with the UICC. UICCs could even have

their own IP addresses, which could introduce a whole set of security issues. ETSI

SCP has standardised SCWS [23] and IP [23] on a UICC. Use of SMS for application

download is limited in practice to about a 1kByte payload, i.e. 7 concatenated SMSs.

Even then, this requires a dedicated SMS-C to achieve an effective success-rate. With

ordinary SMS-Cs whose resources are shared with mainstream SMS, the practical

limit may be as little as 2 concatenated SMSs, i.e. about 300 bytes. The size of a

download using an IP bearer does not suffer from such limitations.

Internal Security Domains: Global Platform has specifications [10] that define

security domains on a Javacard smart card. ETSI SCP are now expanding upon these

in their specifications for “Confidential Applications.” This allows the card issuer to
set up domains for the use of third parties to load applets onto the card. The issuer

cannot examine those applets. The UICC provides a sandbox environment in which

the domains are isolated from each other – a feature that has been somewhat limited
in Javacard implementations up to now.

Enhancements Required to UICCs for M2M Mass Market

A UICC to be used in mass-market M2M applications would have to support the

requirements of long life-time with long maintenance intervals, non-removability,

remote download of operator’s authentication application and remote change of
operator. Some very significant enhancements need to be considered as follows:

Security Domains: Support is required for security domains for the card issuer and

for third parties, e.g. as per the SCP specifications “Confidential Applications”
concept. But in the M2M scenario, network operators would be classed as third

parties. In order for the card issuer to allow the M2M equipment owner to change to a

new network operator, the card issuer (who is therefore not a network operator)

assigns a domain to a new network operator and closes the domain of the old network


4 Somewhat higher speeds can be negotiated between ME and card, but all must support the

default speed for backward compatibility.

Removable UICC vs. Downloadable UICC: unauthorised removal of a traditional

“removable” UICC must be made very difficult, while its replacement must be easy.
A better alternative to this is to fix the UICC in the terminal and for it to support the

ability to download MIDs. Such a UICC must be able to extract Ki objects and

similarly sensitive data from messages from a remote server and lock them away in

secure memory so that they cannot be revealed to entities outside the UICC. Network

operators will demand that there be no reduction of security in UICCs that support

these features.

Download Protocols: Support is required for secure download protocols other than

standardised OTA, i.e. M2M requires protocols which do not require pre-shared keys

and which can be used over IP bearers. (In this respect, support for SCWS and IP

stack could be an advantage).

Secure Interface to UICC: Support for a secure terminal-UICC interface [5], [6]

may be a requirement, as discussed above.

6 Security Analysis and Comparison: Can an Embedded TRE

Ever be as Secure as a Smart Card?

Successful, Publicised Attacks Against Smart Cards

Smart Card technology had experienced some crises in the past, as follows:

Side Channel Attacks (specifically Power Analysis): This type of attack relies on

the noise on the smart card’s power contact being correlate-able with the processing
that is going on in the UICC, especially when it is reading the values of a secret key

into its internal registers. This can work well on an unprotected card that uses the

DES algorithm. RSA is not susceptible and neither is AES (upon which 3GPP

Milenage is based).5 It is easy to prevent this type of attack at the design stage of a

smart card. The physical structure of an embedded TRE would be such that it would

not leak this information. There would be no such interface that an attacker could

monitor and the processing in the TRE would be such that any noise occurring on any

power rail would not contain any recoverable information.

Probing of Broadcast TV Cards: Satellite TV smart cards have to contain global

decryption keys, due to the nature of the service, i.e. a broadcast encrypted signal. If

you crack one card, you have cracked the whole scheme. This is, of course, not true of

networked telecoms systems. In the early 1990s, Cambridge University in the UK

used physical probing to successfully recover secret keys from satellite TV cards. It is

5 This attack was successfully perpetrated against the pilot of a well publicised smart card

payment system in the UK in the early 1990s. Although the scheme was designed to use RSA

with unique private keys, the pilot used DES with a global key on every card.

not necessary for embedded TREs (or UICCs, for that matter) to contain global keys

and their embedded nature would make physical probing infeasible.

Cloning of SIM cards: The only verifiable instance of cloning of 2G SIM cards

was a “known plaintext” (50,000 challenge-response pairs) attack against the
COMP128 authentication algorithm and not against the card platform itself. This

attack has been prevented by the use of better algorithms and is not at all possible

with 3G. The relevance of this attack to TREs is that it has gone down in the annals of

urban mythology as an attack on the SIM card, rather than an attack on the algorithm.

“Mud sticks,” as they say.

Attacks Against Disposable “Eurochip” Phonecards: Two successful attacks
exploited (1) a weaknesses in the card’s hard-wired logic and (2) the absence of a
security module in some payphones. The relevance of this to embedded TRE is that

many attackers seem able to acquire insider knowledge of the product. “Security by
Obscurity” is not a viable counter-measure.

Lack of Security Specifications and Formal Evaluations for UICC: Tamper-

Resistance: There are no standardised specifications as such that assure the degree of

physical and logical tamper-resistance described above. It is up to the buyer to specify

what he wants. The same might not be true of embedded TREs, if they use TCG-style

technology and conform to protection profiles.

Perceptions vs Real-World Implementation of UICC: There is never a guarantee

that, for a given advertised UICC product, all or any of the possible counter-measures

have been implemented. It is a case of being an informed buyer. Network Operators

can obtain un-published information about counter-measures from card vendors and

large-volume buyers can specify their own counter-measures, within the constraints of

the silicon manufacturing process. This should be borne in mind when some

commentators argue that an embedded TRE cannot be as secure as a UICC.

Secure Terminal/UICC Channel: Even if the ETSI/3GPP specifications

concerning key establishment [5], [6] are implemented, it is not specified how the

terminal securely stores the local key and executes the algorithms. There have been

failed attempts in the past (e.g. the MET – Mobile Electronic Transactions forum) to
portray the terminal as a Personal Trusted Device. It would be fair to say that the

telecoms industry has little confidence in the ability of terminal suppliers to

implement a secure environment.

Arguments Against Trusting a Non-UICC TRE

Some network operators may have the following perceptions, as expressed in [1],

about a non-UICC TRE in a terminal. Counter-arguments are in italics.

Network operators can trust the UICC because they are in charge of the
specifications and they buy them directly from their approved vendors. They

will not be able to do this for TREs. It will be necessary to have an

international accreditation scheme for TREs.

The telecoms industry has little confidence in the ability of terminal
suppliers to implement a secure environment (see above). This is not helped

by the suppliers who are involved in standardising M2M but who keep trying

to limit the functionality of the TRE. Once again, a security accreditation

scheme is needed.

Compared to the small number of UICC vendors, there are potentially many
suppliers of M2M terminals and therefore of embedded TRE solutions. The

number of TRE vendors could be small, if the M2M equipment architecture

is designed appropriately.

The UICC is a product with a great track record. The O/Ss have been
evolved over many years. A non-UICC TRE is still at the conceptual stage.

No counter argument except that every technology is eventually superseded

by progress. UICCs were new, once upon a time.

Network operators want to use OTA infrastructure for downloading MIDs.
Current OTA is not secure enough and would need to be updated, but that

could cause backward-compatibility problems. Other protocols, which could

be used over an IP bearer, could well be secure enough but would have to be

evaluated. M2M equipment vendors will have no problem in providing the

required APIs to an embedded TRE to allow use of an IP bearer and

appropriate download protocols. Network Operators could possibly be

persuaded, since some of them were very active in Liberty Alliance [22].

Also, IP download could be sub-contracted.

Today’s system for distributing Ki is well understood and well tried. Any
change to that is bound to cause nervousness. Also, Network Operators take

the view that the proposed Architecture 1 in [1] would involve passing the Ki

around too many different entities. The number of entities does not have to

be any more than it is today, since the specified technical functions will be

combined into a small number of real-world roles. Also, the Ki could be

strongly encrypted for the TRE (with the TRE’s public key) by the entity that
generates it, in which case it could be handled securely by the intermediate

parties involved in downloading it to the M2M equipment.


An embedded TRE, if properly specified, implemented and accredited, could

provide a much-needed alternative to the UICC in meeting the requirements of M2M.

An embedded TRE challenges the long-established infrastructure and practices of

Mobile Network Operators and UICC suppliers, but it could be a key enabler for the

potentially huge M2M market to take off, thereby becoming an important new source

of revenue.

If an embedded TRE is to be seen as a competitor to the UICC for M2M, it must

have sufficient resistance to the threats that are described in the threat analysis in [1].

Whether or not the previously successful attacks described above could be used to

perpetrate such threats depends on the implementation of the TRE, e.g. whether it is a

discrete component, part of a single-chip CPU, system ASIC, or distributed across a

chipset. It is not possible to provide an implementation-independent answer to the

question: “How difficult would it be for an embedded TRE to have some of these
measures?” because some of the measures might not be relevant. An ASIC makes
things easier in terms of security evaluations and accreditations.

Specifiers, developers and implementers of embedded TREs must bear in mind the

lessons which a long experience of smart cards has taught us:

Side-channel attacks would be much more difficult to achieve against a TRE
if the TRE is not a discrete component

One can argue that direct probing of a TRE is not important, as an individual
TRE does not contain any global secrets. Nevertheless, there are always

people who will take up the challenge of attacking the TRE, for example, in

an attempt to extract a Ki. Such threats are faced by every security initiative

and only provide further motivation to design it correctly.

Attacks against the cryptographic algorithms in a TRE could be publicised as
attacks against the TRE.

Many attackers seem able to acquire insider knowledge of the product.
“Security by Obscurity” is not a reliable counter-measure. Do not rely on
attackers being unable to gather information on how a TRE works.

Reputation is important. The UICC vendors have enormous reputations in
the world of security, whereas the terminal suppliers have little or none.

TREs should be manufactured and personalised by reputable chip

manufacturers with a proven track record in the security industry.

Perceptions are important. The perception of the UICC may, in some cases,
exceed its actual specification or design. Such must not be allowed to

become the case for TRE.


1 3GPP unapproved draft technical report TR33.812 Feasibility Study on
Remote Management of USIM Application on M2M Equipment. (this is

a working title which can change at any time)

2 3GPP TS 31.102; Characteristics of the USIM Application
3 3GPP TS 31.103; Characteristics of the ISIM Application
4 ETSI TS 102 221: UICC-Terminal interface; Physical and logical


5 TS 102 484 Smart Cards; Secure Channel between a UICC and an end-
point Terminal.

6 TS 33.110 Key establishment between a UICC and a terminal
7 ISO 7816-1 Identification cards – Integrated Circuit Cards - physical


8 ISO 7816-2 Identification cards – Integrated Circuit Cards -
dimensions and location of contacts. AMD1 (2004) = assignment of C4

and C8

9 ISO 7816-3 Identification cards – Integrated Circuit Cards -
electrical interface & Tx protocols.AMD1 (2002) = low voltages

10 Global Platform specifications, v 2.2, see
11 3GPP TS 23.048 Security Mechanisms for SIM Toolkit Application;

Stage 2. N.B. this has been recently split up and its former contents have

been dispersed over [18], [19], TS 31.115 Secured Packet Structure for

(U)SIM Toolkit applications and TS 31.116 Remote APDU Structure

for (U)SIM Toolkit applications. TS23.048 is still widely referred to in

the telecoms sector.

12 Java community specification JSR177: Security And Trust Services API
13 ETSI TS 102 600: Characteristics of the USB Interface
14 The Smart Card Handbook, 3rd edition, by Rankl & Effing, published by

Wiley and Sons

15 See
16 Eurosmart: “Smart Card IC Protection Profile”, PP-0002, first published

2001. (EAL4 augmented)

17 CEN standard EN726 Identification card systems. Telecommunications.
Integrated circuit(s) cards and terminals. There are 7 parts to this


18 ETSI TS 102 225: Secured packet structure for UICC based applications
19 ETSI TS 102 226: Remote APDU structure for UICC based applications
20 ISO 7816-4 Identification cards – Integrated Circuit Cards -

Organisation, security and commands for interchange

21 ISO 7816-8 Identification cards – Integrated Circuit Cards - Commands
for security operations

22 See
23 TS 102 483: UICC-Terminal interface; Internet Protocol connectivity

between UICC and terminal