Herald: So our next talk is "SIM card
technology from A to Z" and it's an in-

depth introduction of SIM card technology
that not a lot of people know much about.

And our speaker, Harold, LeForge, as he's
better known, is the founder of the Open

Source Mobile Communications Project. He
is also a Linux kernel hacker. He has a

very long and impressive bio; and a
Wikipedia page.

Harald (speaker): just means I'm old.
Herald: So Harald Welte, please give him a

round of applause.
<i>Applause</i>

Herald: All yours.
Harald (speaker): Thanks a lot for the

introduction. As you can see on the title
slide, I actually had to change the title

slightly, because I couldn't find a single
acronym related to SIM cards that starts

with z, so now it's from a to x, not from
a to z anymore - the SIM card

introduction. So the SIM card technology
from A(PDU) to X(RES) which are two

acronyms in the context of SIM cards which
we might get into or not. So, what are we

going to talk about in the next 45 or so
minutes? What are the relevant

specifications and specification bodies?
What kind of interfaces and protocols

relate to SIM cards? We're going to talk
about the filesystem that exists in such

SIM cards, as well as the evolution of SIM
cards from 2G to 5G. So that's basically

from what, 91 to 19, er 2018. We will talk
about SIM Toolkit, Over The Air, a little

about about how to eSIMS as well, the
embedded SIMs. Introduction about myself

was already given. So, yeah, people
complained sometimes that my slides are

full of text and I need more diagrams. So
I tried to improve.

<i>laughter from the audience</i>
<i>Harald laughs</i>

<i>Applause</i>
Harald: So this is actually, at one night

I thought, OK, let's actually try to
create a DOTTY graph of all the specs and

how they cross reference each other. And
this is what I've come up with and this is

only the SIM card relevant specs, not out
of context, other specs that they may

refer to. So, yes, it's an interesting
graph. The arrangement was done

automatically by DOTTY. So don't complain
to me about that. Yeah.

Nevertheless, I will switch back to text
and we will look at what kind of

specifications there are and spec bodies.
So. Most importantly, probably about any

kind of chip card technology. We have the
ISO, the International Standardization

Organization, which has a series of
specifications about what they call ICCs,

which is integrated circuit cards. We also
have the ITU, the International

Telecommunication Union, which has a
series of specs related to telecom charge

cards. The title implies, that this is
things that came before SIM cards. So we

talk about the cards you put into pay
phones and things like that in the 80s.

There is of course, the 3G. Oh, sorry,
there is of course ETSI, the European

Telecommunication Standardization
Institute, which is the entity where GSM

was originally specified. GSM being the
first digital telephony system that used

SIM cards.
The best of my knowledge, at least not a

historian though. There's a 3GPP, the
Third Generation Partnership Project,

which is where the GSM specs have been
handed over to. In the preparation of the

3G specification process, because ETSI is
a European entity and Chinese companies,

for example, or Chinese government cannot
participate there, or Americans even, to

the extent that European companies can do.
So it was lifted to an international new

group called the Third Generation
Partnership Project. And they of course

inherited all the SIM card related
specifications. And then we have like non-

telecom standardization entities such as
the Global Platform Card Specification.

That's Global Platform is a body that
specifies lots of aspects around Java

cards, specifically around to applet
management, installation and so on Java

cards, which brings us to the next entity,
which is not really a standardization

body, but it's a private company that used
to be called Sun and now it's part of

Oracle, which defined the Java Card API
runtime and the virtual machine of Java

cards.
And last but not least, we have the GSM

Association, which is the vendor club of
the operators. That doesn't really have to

do that much with SIM cards until the
eSIM, where then suddenly a GSM A plays a

big role in the related specs and
technology. So talking about these

standardization bodies. What is the SIM,
actually? The SIM is the Subscriber

Identity Module. I mean probably anyone in
here has one, likely more or at least has

had. It's quite ubiquitous. Every device
with cellular connectivity during the last

whatever 20 or so years has a SIM, whether
it's an actual card or whether it's

soldered in these days. SIM card hacking
has a tradition in the CCC since at least

1998.
I'm not sure how many people remember:

there was the Vodafone Germany SIM card
cloning attack back then. It was in

German. It was titled "Von d2 privat zu D2
pirat". And that was an attack that used

weaknesses and sort of brute forcing
against the authentication mechanism to

recover the secret key, which is stored in
the card. And then you could clone SIM

cards back then.
That was then fixed in subsequent

technology generations. And also around
that time you can find on the FTP server

of the CCC a SIM card simulator written in
Turbo C using a season card. I'm not sure

how many people remember season cards.
These were cards people used in the

context of cracking satellite TV
encryption. Yeah, so. Meanwhile, of

course, the SIM technology stack has
increased and the complexity has increased

like probably in any kind of technology.
So let's recap, basically from the

beginning to today what SIM cards are and
what they do in some degree of detail. If

we start historically with SIM cards,
actually the predecessor to the SIM cards

that we know, is the chip card used in the
C-Netz, which is an analog telephony

system that used to operate in Germany.
There's actually an open source

implementation these days as part of
Osmocom-Analog.

If you're interested in that, do check out
a jolly at the vintage and retro

computing area. And before 1988, they only
had a magnetic stripe cards, but in 1988

they introduced integrated circuit cards
in this analog telephony system and in GSM

it was a chip card from the beginning. The
concept of the SIM card means you store

the identity of the subscriber outside of
the phone, which is very opposite to what

happened in the CDMA world in the US
around that time where it was basically

inside the phone itself. But having the
identity separate, of course, enables all

kinds of use cases that were relevant at
that time.

We will get to that to some extent. In
addition to the identity, and the identity

in this context means a cryptographic
identity, there are all kinds of network

related parameters that are stored in the
SIM card. Some of those are static,

meaning that they are provisioned or
written by the operator into the card, or

of course by the SIM card manufacturer on
behalf of the operator, but which are not

writable by the user that effect 
access control classes, which

means like, are you a normal user or are
you an emergency service user which needs

higher priority to access the network,
things like that. And there are lots of

dynamic parameters on the card, and
dynamic means they get rewritten and

changed and modified and updated all the
time. That's for example, the TIMSI, the

temporary identity that gets allocated by
the network every so often. Also the

current actual air interface encryption
key like KC and its successors in modern

generation technology. So they get updated
and written all the time by the phone. And

some of the files are even updated and
written by users, at least traditionally

or historically, like the phone book and
the SMS that are stored on the card. It

was originally specified as a full credit
card sized cards and it was intended to be

used in radios in rental cars or company
shared cars.

So basically when you leave the car, you
would remove your SIM card, the full sized

credit card sized card and somebody else
would put their card in. And allegedly

there even were, I think, public GSM
phones installed in German trains where

you could plug in a SIM card or something
like that. But I personally haven't

witnessed that, since I was ignorant at
that time, apparently, of that fact. So,

let's get to the mother of all smartcard
specs, which is in German DIN EN ISO/IEC 7816

or short just ISO 7816 and maybe an
anecdote how these specs come around. So

there's the ISO that specifies a certain
spec, it gets an ISO number and then EN,

the European norm, whatever body, comes
around and says, "oh, we will elevate this

international spec into a European
standard". And they put an EN in front.

And then DIN, the German standard body,
comes around, says, oh, we will elevate

this European norm into a German norm and
we will put a DIN in front. So now in

Germany, we have DIN EN ISO/IEC 7816.
And if you get the actual copy from DIN

it's quite funny. I didn't don't have it
here, but actually you get a one page

additional paper on top, which translates
the key technical phrases from English to

German. And that's the added value that
you get from it become. Sorry. I mean,

it's just hilarious. The entire spec is in
English, but then there's like this key

translated terms. So you know, that file
means "Datei", for example, that's

extremely beneficial to the reader of such
specifications. Anyway, so the title is

"Integrated Circuit Cards with contacts".
<i>chuckles</i>
I wonder, OK, they are contact

less now, but at least back then,
cerainly, they didn't exist. And it has 15

parts by now.
The most relevant parts are 1 through 4,

starting from the physical
characteristics, going through the

mechanical dimensions and the location of
the contacts, of course, it's a separate

part of the spec. And each of those specs
are sold as a separate document, of

course. So the physical size you pay and
if you want to know the location of the

contacts you have to pay to get another
spec. And then there's part 3, which

covers the electronic signals and the
transmission protocols. We will look at

that in some detail. And then there's part
4, which is the inter-industry commands

for interchange, which I find very
interesting. And I always thought they

should have met the international inter-
industry commands for inter-working

information interchange. But apparently
they didn't come up with that. And of

course, this all predates the Internet, so
there's no Internet in there. Yeah. The

next relevant spec is GSM technical
specification eleven dot eleven. Very easy

to memorize that number, which is the
specification of the subscriber identity

module dash mobile equipment interface. So
in GSM there is what's called a mobile

station, which is your phone, and it is
comprised of two parts, the mobile

equipment, which is the hardware and the
SIM, which is the SIM next to the mobile

equipment.
And it interestingly, it doesn't just

refer to these ISO specs that I mentioned
before, but it actually repeats like more

or less carbon copies large portions of
these ISO specs with some amendments or

corrections or extensions. And again, it
gives you the location of the contacts and

the mechanical size of the card and the
electronic signals and the transmission

protocols and so on. But beyond these ISO
standards, it also actually specifies what

makes the SIM a SIM and not any other
contact card, which is the information

model, the file system on the card and the
commands and protocols that you use on

this card. And last, with typo as usual on
my slides, but not least, of course, how

to execute the GSM algorithm to to perform
cryptographic authentication.

The physical smartcard interface is
interesting. I mean if you've worked with

hardware or electronics or serial
interfaces, I think it's rather exotic and

exotics always means interesting. So we
have four relevant pins. We have a supply

voltage, not surprisingly. It can be 5, 3
or 1.8 volts. Interesting, it's not 3.3

volt, it's 3.0 volts nominal.
Not sure why. But anyway, that's how it

is. We have a clock line that provides a
clock signal which initially needs to be

between 1 and 5 megahertz. So the phone
provides power and clock. We have a reset

line which also makes sense; you want to
reset the card and then we have one IO

line for bi-directional serial
communication.

So you have RX and TX sharing one line and
there is some nice diagrams about how

exactly the sequencing happens when you
power it up, nothing really surprising.

There's an activation sequence and after
the card is activated, the card will

unilaterally send what's called an ATR,
the answer to reset. And that's just a

series of bytes which give some
information about the card capabilities.

What protocols, what voltages, what clock
rates beyond these initial activation ones

are supported. Now, after we've powered up
the card, we have the bit transmission

level.
And it's actually very much like a normal

UART. If you ever looked at RS232 or
another UART a serial port, rather simple:

start byte, stop byte, parity, serial bit
transmission. What's a bit interesting is

that we have a clock and the baud rate is
divided from that clock, but it's still an

asynchronous transmission. So there is no
phase relationship between the clock

signal and the baud rate that the data
uses, which lots of people get wrong,

particularly lots of authors of Atmel
microcontroller data sheets which claim

that it's a synchronous communication,
which it is not. Yeah.

So the direction changes every so often to
have acknowledgements back and forth and

to exchange data in both directions. And
interestingly, a lot of the timings are

not specified very well, but I guess
nobody cares about that, other than if you

want to implement a card reader, which I
happen to have gone through this year.

Smart Card Communication: after we are
able to transmit bytes between the card

and the reader, we have something called
APDUs. The Application Protocol Data Unit

specified as per that ISO 7816-4. That's
the inter-industry commands for

interchange. And an APDU consists of a
couple of bytes. There's a class byte that

just specifies the class of command as an
instruction byte which specifies the

specific instruction like read a file,
write a file. We have some parameter bytes

whose meaning is relevant or is specific
to the instruction, then we have a length

of a command and command data. We have an
expected response length and response data.

And last but not least, a so-called status
word and the status word basically, the

card tells whether the execution was
successful or whether there was some error

and what kind of error there was and
things like that. The APDUs are then split

into a lower layer transport protocol,
which are called TPDUs.

There are two different commonly used
protocols and two specific ones that are

used in the context of SIM cards ore are
specified in the context of SIM cards, as

one called T=0. Which is most commonly
used for SIM cards. Actually, I've never

seen anything else but T=0 used, but T=1
is another protocol which according to the

specs, every phone needs to implement. And
the card can choose if it does T=0 or T=1.

As again, I've never seen a card that does
T=1, or at least that has only T=1, but

the specs would allow that. T=1 is more
used in banking and crypto smart cards.

The difference mainly is T=1 is a block
oriented transfer and T=0 is more a byte

oriented transfer. And T=1 has the
advantage that it has CRC and checksumming,

so you get more protection
against transmission errors which you

don't have in T=0. So the APDU gets mapped
to TPDUs. Details I'll skip here and this

is just some examples, so you get an idea
how this looks like.

So we have A0 A4 00 00 02 3F 00. The A0
here is the class byte and A0 is SIM card

class. A4 is select file.
So you're selecting a certain file on

which you want to operate. Two parameter
bytes are 0, 02 is the length of the

command. And then you have two bytes of
that length 3F 00, which is basically your

slash, your root directory. You want to
change to the root directory of the file

system, is basically what that command
says. And one hypothetical response is

just a status word 90 00, which means
success. Yeah. Selecting a file. So we

have a file system on the card. Most smart
cards do that. It's not a file system in

the context like you have a USB drive that
you can mount, where you just have a block

abstraction or something.
But the smart card filesystem itself runs

inside the card and you just talk to the
filesystem and give it instructions. So if

you want to find an abstraction in PC
technology, it's more like MTP or PTP over

USB where you don't have a block device,
but you talk to another processor which

manages a file system and you can instruct
it's like a remote file system access.

You have some similarities to normal file
systems. I mean, there's a master file

which corresponds to a root directory in
PC file systems. You have so called

dedicated files, which are sub directories
and you have so called elementary files,

which are actual data containing files as
we know them. Beyond that, there are lots

of specifics that we don't find PC file
systems or operating system file systems.

We have what's called a transparent EF.
That's an opaque stream of data like your

normal binary file on on any random
operating system. But then we have

concepts like a linear fixed EF which
contains fixed size records and you can

seek against it. Get me the 15th
record in that file and the file has a

record size of whatever 24 bytes for
example. And then you have something

called a cyclic EF where they have a ring
buffer of records and you have

incrementable files which contain
monotonically incrementing counters and

things that are apparently important for
charging or things like that.

Each file has access control conditions
that define who can read and or modify and

or well, there's no delete, but there's
something called invalidate the file. And

who is basically expressed in context of
which PIN was used to authenticate that

entity, which performs the operation.
So as a user, you have a PIN1 and some

people will remember you also have a PIN2,
that probably nobody's used since the 90s.

And the operator has something called an
ADM PIN, administrative pin, which gives

better or higher privileges in terms of
filesystem permissions on those files. The

kind of commands we see, well, select file
from the example. We have read record,

update records. I guess I don't need to
say anything about that. Similarly, read

binary, update binary. And then we have
commands like CHV commands, where CHV is

the cardholder verification which is ETSI
language for a pin. Not sure why they

don't call it PIN. So there's change PIN,
disable PIN or enable PIN commands. Which

is actually what your phone performs, if
you, say, you disable the PIN or you

change the PIN then exactly those commands
are issued to the card and last but not

least, run GSM algorithm. Remember, this
is still the 2G only SIM. We haven't yet

gone beyond 2G, yet at this point in the
slides. There is actually not that many

more. That's that's really it. Now let's
look at the file system hierarchy. We have

the MF, the root file system and then we
have something called DF_TELECOM. And the

hex numbers in parentheses are the
identifiers that are actually used on the

protocol level. We have something called
DF_GSM, which is the GSM directory

containing GSM related parameters. And if
EF_ICCID where ICCID is the card unique

identifier that's stored on the card. And
if you expand that into more details, you

get these kind of graphs. And this is one
is actually taken from one of the specs.

And you see there's also an Iridium
directory or a, uh, whatever that one was,

a Global Star directory.
And all kinds of people operating

different telephony system have basically
their own directories in that scheme. But

on GSM, we find those two mainly, maybe
some sub directories. Yeah, so when 3G

came around something happened, as I said,
the specifications were shifted from ETSI

to a 3GPP. But of course, chip cards in
the context of telecom have use cases

outside of cellular telephony. So,
actually, the specs were split in that

area. So there's something new called the
UICC, the Universal Integrated Circuit

Card, because the previous one was not
universal, apparently. And that part of

the specs remained with ETSI and continues
to be developed. And there is the USIM

application on top of the UICC, which is
what specifies the 3GPP relevant part and

that gets implemented in something called
an ADF, an application dedicated file, ADF

USIM.
In ADF you can also select or enter using

a select command similar to a normal DF.
The difference mainly is that the

identifiers on much longer and thus other
details, but from a user point of view

that's how it looks like. So we have a
split of the core Universal ICC and on top

an USIM application. And if you have a SIM
card that can be used with 2G and with 3G,

then you basically have the classic SIM
card and in addition you have a USIM

application on the card.
And actually there are some cards that

only work with 3G or later technology and
don't have 2G mode, because the operator

doesn't have a 2G network. So you only
have a USIM application and you don't have

the classic SIM anymore on the card. When
4G/LTE came around, actually there was no

strict requirement to change anything in
the SIM card and you can just use a normal

USIM, UMTS SIM, a 3G card on LTE networks.
It's the same authentication key agreement

mechanism. They have added some additional
files that are completely optional. Mostly

like optimizing some bits and there are
some optional new IMS application. IMS is

the IP multimedia system which is 3GPP
language for voice over IP or VoLTE,

right? So IMS is the IP multimedia system,
which is what is used to implement VoLTE

where VoLTE is not a specification term
but more a marketing term and that's

optionally on the SIM card.
You can have an ISIM an application which

stores parameters relevant to the IP
multimedia system such as SIP user

identities and SIP service and things like
that. But if that ISIM application doesn't

exist, there is a fallback mechanism by
which the identifiers are computed based

on the IMSI and and so on and so on. So
it's not really necessary to have a

specific 4G SIM, but it's possible to have
that. Once we go to 5G, 5G actually reuses

the existing 3G and 4G USIM cards. Again,
some new optional files have been

introduced and there is one feature which
I guess everyone in here wants to have,

which would require a new SIM card or
change SIM card, which is that the SUCI,

the Subscriber Concealed Identifier, can
be computed inside the SIM card or by the

phone.
And if it is computed inside the SIM card,

then the SIM of course has to have support
for doing that computation and that is

something that needs explicit SIM card
support. In absence of that, everything

else you can use an existing 4G SIM card
even on 5G networks. Nothing really

changed there, fundamentally.
OK, now looking at the cards, more on the

physical side and from the hardware and we
will look at the software, the operating

systems and so on and the various things
you can do with SIM cards later on. We

have, of course, the processor core that
many different vendors and architectures,

traditionally lots of 8051 derivatives
inside smart cards. These days we also

actually find a lot ??? ARM cores, quite
often so-called SC cores. There's an SC000

and then a SC100 and an SC300 and SC is
for Secure Core.

So it's not a normal Cortex core or
something like that, but it's a secure

core and it's so secure that ARM doesn't
even disclose what is secure about it

other than that it is secure. And so the
documentation for sure is securely kept

away from anyone who would want to read
it. So, for these chips, the smartcard

chips used in SIM cards or generally smart
card chips themselves, often you cannot

even find a similar thing, simple one page
data sheet which tells you the main

features. Even that is already under NDA.
You have built-in RAM and built-in ROM, at

least a bootloader normally, but possibly
also the OS or parts of the OS, but that

is increasingly uncommon. So modern cards,
most of them only have flash and the

entire operating system is in flash, so
you can update everything. And then

applications on top of that and we will
look at applications later when we talk

about the software.
And unfortunately, contrary to the crypto

smartcards where it's possible to have
higher prices and therefore have, you

know, rather expensive products, SIM cards
are mostly selected purely by cost these

days due to the prepaid boom. I mean, it
was different when GSM was introduced. If

you, if every subscriber has to get a
subscription and there's going to be

hundreds of Euros or Marks of whatever in
revenue, then you can invest a lot of

money in a SIM card, but prepaid cards
that get thrown away on a daily basis you

can only pay cents for the card and then
you need to pay another a couple of cents

for the Java card for the Java VM patent
royalties and so on and so on. But

basically you cannot afford to pay money
for SIM cards anymore. So that also

explains why a lot of SIM cards today,
even though it's technically available,

they don't have hardware crypto, but they
actually implement it in software, because

it's cheaper. And then of course, yeah,
well, you have time of execution, things

and whatnot.
So in terms of software, you have a Card

Operating System. Cards that don't have an
operating system are memory cards which

are not sufficient for SIM card use cases.
And in the crypto smartcard area, it's the

operating systems are typically well known
and documented to some part, at least. In

SIM cards it's slightly different. So
almost nobody ever mentions what kind of

operating system is on the SIM card and
even the SIM card vendors. It's not very,

you know, not something they would put on
their marketing, or on their homepage or

something, what exactly kind of operating
systems are on there.

The SIM card offering system also from
the central network point of view as an

implementation detail, because all the
relevant parts are specified standardised

interfaces and what operating system
people use on the card, well, it's the

operator's choice. It doesn't really
matter from that point of view. In early

SIM cards, I presume they were rather
monolithic, so you didn't really have a

separation between an operating system and
SIM application. Today the software's

become more modular. We have this
abstraction between the operating system

and applications. And traditionally, even
when that separation already existed, the

operating system was very hardware
dependent, non-portable and the

applications were very OS-dependent and
non-portable. And that has changed a bit

due to the introduction of Java cards into
the SIM card area, which is not required.

There there's no requirement anywhere that
the SIM card must be a Java card, but in

practice, most SIM cards are Java cards
because they have certain, at least

perceived, advantages and are the norm by
now. And the Java cards themselves have

been independently developed of SIM cards.
Of course, Java is a Sun technology, so

Sun is behind that. And the first actual
cards that were produced in 96, so much

later than SIM cards came out by
Schlumberger which is now part of Gemalto.

And um, yeah, we have redundant lines in
this presentation. And so, the Java cards,

most of them implement a global platform
specifications, which then specify vendor

independent management of the cards and
the applications on it. And the Java that

you use to write such cards, don't ever
think it is real Java! I mean, if you show

that to any Java developer, he will
probably disappear very quickly as we have

a very weird constrained subset of Java
with a special on-card virtual machine,

which is not a normal virtual machine. You
have a runtime environment that's not the

normal runtime environment. You have a
special binary format which is not a char

file.
And the idea is that you have portability

of card applications, which makes sense,
of course. But one could have done that

with, you know, whatever other standards
as well. Wouldn't necessarily need a

virtual machine for that. Yeah, I said
there's no functional requirement that a

SIM card must be a Java card, but in
reality that's the case. I think the

portability is the driver here. So, if an
operator develops some application that

runs on a SIM card, you know, every year
or so they do a new tender or they have a

new SIM card supplier or something like
that, they want to run their application

on the current and the future and the next
future future SIM card and not rewrite all

of that from scratch or have that
rewritten from scratch all the time.

And interestingly, both 3GPP and ETSI
specify Java APIs and Java packages, which

are specifically available on Java cards
that also are SIM cards. So basically you

have SIM card specs and you have Java
card specs and if you have both of them

together, you also have SIM card Java API
specs for what kind of additional API's

applications on the card can use in order
to affect SIM relevant aspects of the

card. Which brings us to one of the
strange historic developments called SIM

Toolkit or later Card Application Toolkit,
which is sort of an ability to offer

applications with UI and menu on the
phone, right?

I mean the card of course doesn't have any
user interface, but the card can sort of

request like show a menu and offer
multiple choices and things like that.

Some people will have seen it on some
phones. You have this SIM toolkit menu

somewhere. And I mean, I think in Germany
never really took off much in terms of

actual applications. I mean, you could
probably subscribe to some very expensive

premium SMS services. If you were really
bored, but in other regions, this has been

very successful and very organized, had a
real impact on society. Kenya is always

the, I think the prime example for that,
where MPESA, the mobile payment

system, implemented at least initially
based on card application toolkit

applications, basically overtook the
banking sector. At some point everybody

did their wire transfers that way, even
people who didn't even have a bank account

and it basically replaced or substituted
large amounts of the everyday banking

needs of people. So there are exceptions.
Some additional instructions that we have

in terms of APDUs, details I will not look
into these. The next step after SIM

toolkit is the so-called proactive SIM. If
we look at the SIM card communication as

it is specified, or smartcard
communication in general, it's always the

reader, in this context the phone, that
sort of sends an instruction to the phone,

to the card and the card responds. So the
card is always the slave in the

communication and it doesn't have any
possibility to trigger something by

itself.
And that was sort of worked around by the

proactive SIM specifications where a
command or a request from the card is

piggy-backed into responses to the
commands from their phone to the card, and

then basically that the SIM card can
request the phone to poll the card every

so often, so the phone can ask for "do you
have a new command for me now?" and the

card can say yes or no. In this way, they
work around this restriction.

And it's not only polling that can be
requested, but it can be event

notifications. And event notifications can
be loss of network coverage, registration

to a new cell, opening of a web browser
and like are you making a mobile

originated call, are you sending an SMS or
not?

So all these kind of events can be sent to
the SIM card, so that the SIM card can do

whatever with it. I think that not many
useful applications beyond steering of

roaming or roaming control, by basically
depending on where you register and what

kind of cells you have, and even the
measurement reports on what is the signal

strength that can be fed into the SIM
card, which then can basically decide what

to do. But yeah, I think it's all rather
exotic and very few, like relevant or good

use cases of this.
The next step is Over-The-Air-technology

(OTA), which is the ability for the
operator to transparently communicate with

the SIM card in the field. With the
traditional non-OTA capable SIM card, the

operator or the SIM card manufacturer
writes at manufacturing time (at so-called

personalization time of the card), and
then it's with the subscriber. And if the

operator ever wants to fix something or
change something, they have to send a new

plastic card. With OTA, they can be
updated. It's based on proactive SIM

technology and by now, there are many
different communication channels how some

back end system at the operator can can
interact with a card inside the phone of

the subscriber. The classic channel is
SMS-PP, which is the SMS as you know, it

just officially called SMS point-to-point.
It's also possible over SMS-CB, the cell-

broadcast-SMS, which I find very
interesting, bulk updates to SIM cards via

cell broadcast, which also would mean that
they all have a shared key for

authenticating these updates. It's also
specified for USSD from release 7 on most

of the specs. And then there's something
new, at that point, called BIP, the

"bearer independent protocol" that works
over circuit-switch-data and GPRS. Here

are some spec numbers if anyone is
interested. And now, since release 9, that

means since LTE is around, also over
HTTPS. I'll get to that in a couple of

separate slides. There's actually a TLS
implementation in

SIM cards these days, believe it or not.
So the cryptographic security mechanisms

set are specified, but of course the
detailed use is up to the operator so the

operator may choose whether or not to use
measures of authentication, or whether or

not to use encryption, or whether or not
to use counters for replay protection. And

this is basically one area where a lot of
the security research and the

vulnerabilities published in the last
decade or so have been happening, e.g.

cards were not properly configured, or
they had implementation weaknesses, or you

had some sort of oracles that you could
query when interacting with those cards as

an attacker. One of the use cases of Over-
The-Air is RFM, not RTFM, it's RFM,

"Remote-File-Management". It was
introduced in release 6 and the number of

typos is embarrassing. A common use case
of Over-The-Air: It allows you to read or

update files in the file system remotely,
and you can use that, for example, for the

preferred or forbidden roaming operator
lists. That's a very legitimate use case

for that. There's also an ancient example
that I always like. I think Vodafone

Netherlands once advertised that the
operator can take a backup of your phone

book on the SIM card. I think it's an
early manifestation of cloud computing

before it even existed. In any case, it's
certainly a feature that everyone in here

would like to have. Of course it's
irrelevant by now because nobody has

contacts on SIM cards anymore. The next is
RAM which is not "Random Access Memory",

it's "Remote Application Management". It
was also introduced in the same release

with the same typo, and it allows
installation and/or removal of

applications on the card, and applications
in terms of Java card then means Java

cardlets. For example, you could update or
install new multi IMSI-applications, which

is one very creative way of using SIM
cards in more recent years, or new Sim-

Toolkit-Applications.
So a multi-IMSI application, in case

somebody hasn't heard of that yet, is
basically a SIM card that changes its

IMSI depending on where your currently
roam, in order to do a sort of least cost

roaming agreement for the operator because
if he uses his is real own IMSI, then

maybe the roaming costs would be more
extensive than if he used some kind of

borrowed IMSI from another operator that
then gets provisioned there, which has a

better roaming agreement and would work
around ridiculous roaming charges - at

least between the operators, of course,
not towards the user. And now we get to

the sort of premium feature of modern SIM
cards where, of course. you can still do

SMS over LTE, but it's sort of this added-
on kludge. USSD I think doesn't exist

anymore because of the circuit-switch-
feature. So you need some kind of new

transport channel of how to talk to the
SIM card. In release 9 they came up with

something called over the air over HTTPS
which is specified in global platform 2.2

amendment B. You have to get that specific
amendment as a separate document, it's at

least free of charge. Actually it uses
HTTP, nice and good, and then it uses

something called PSK-TLS, that I've never
heard of before, "pre-shared-keys with

TLS". I mean, I'm not a TLS expert, as you
can probably guess, but I don't think

anyone ever with a normal browser would
want to use pre-shared-keys. But it exists

in the specs and there are several
different cipher-modes that I've listed

here which are permitted for Over-The-Air
of HTTPS. Which subset to use is of course

up to the operator because it's his SIM
card talking to his server so they can do

whatever they want there. The interesting
part is that the IP in the TCP is

terminated in the phone, and then whatever
is inside the TCP stream gets passed to

the card which implements the TLS and the
HTTP inside. Then, inside HTTP you

actually have hex string representations
of the APDUs that the card normally

processes. So you have this very
interesting stack of different

technologies and if you look at how
exactly they use HTTP, you ask yourself

why did they bother with HTTP in the first
place if they modify it beyond

recognition? But we'll see. So the way how
this is implemented, interestingly, is

that the card implements and HTTP client
that performs HTTP-POST. So your card

somehow by some external mechanism gets
triggered: "Oh, you must connect to your

management server now because the
management server wants something from

you". And then the card does an HTTP-POST
over TLS with pre-shared-keys to the

management server and then in the post
response there is a hex-encoded APDU for

the card to be executed by the card. Then,
you have tons of additional HTTP-headerrs

I'm not going to explain. The CRLF is just
a copy and paste error. But you see there

is all kinds of X-Admin-headers and it
will completely not work with normal HTTP. So why

use HTTP in that context, I don't really
know. Yeah, I thought I had an example

here, but I didn't put it up, I thought
it's too much detail. But in the end, if

you look at this, you'll need to write
your own heavily modified HTTP-server

anyway. but you have HTTP in there. Okay.
Another technology, it's sort of random, I

didn't really know where to put it in
terms of ordering, is this S@T.

technology, which is something really
strange that's specified outside of the

specification bodies that I mentioned
before.

It's another.., I'm just mentioning it
because it's another vector that has more

recently been exploited. Another
vulnerability. Where, actually, let's say

you don't want to run. You don't want to
write a Java application to run on the

card, but you still want to use SIM
Toolkit. So your card, most likely inside

a Java VM implements a VM for another
bytecode, which is this S@T bytecode which

gets basically pushed from the server into
the card.

So the card can then instruct your phone
to display some menu to you. Hmm. Okay.

Uh. Very exciting technology. I'm sure
there was a use case for it at some point.

I haven't really figured it out. So there
is something called an S@T browser which

runs inside the card. As I said, most
likely that browser is implemented in Java

running inside the Java VM. It's not a web
browser, of course. It just called a

browser and it parses this binary format
which then creates SIM Toolkit menus or

whatever. So yeah, I haven't really looked
into detail. It's too strange even to look

at it. Last but not least, we have
something called the eSIM and Which many

people may know as a particular. How can I
say particularly dominant in

the Apple universe where the SIM card is
no longer a replaceable or exchangable

plastic card with contacts. But it's
actually soldered into the device. This

package, a form factor, is called MFF2,
the machine form factor. Not sure why it's

two, I've never seen a one before and it's
a very small like 8 pin package SMD

package that gets sold on a circuit board.
And of course, at that point you have to

have some mechanism by which the actual
profile, meaning the user identity, the

keys and all the configuration parameters
and so on can be updated or replaced

remotely. And that in a way that will work
between different operators which are

competing in the industry and which don't
really want to, you know, replace those

profiles, at least not inherently. And
this is why this is managed by the GSMA as

an umbrella entity of all the operators.
And it specifies an amazing number of

acronyms. And trust me if I say that it is
an amazing number of acronyms on how the

cryptography and how the different
entities and how the different interfaces

work and all the different roles and the
parties and each implementation of each

party needs to be certified and approved
and so on and so on. And in the end, you

have a system by which after a letter of
approval be

tween operators and a new identity from a
new operator can be downloaded in the card

in a cryptographically secure way. So at
least is the intent of the specification.

I am not the person to judge on that and
replace the profile, but it's not that

like you as the owner of the device can do
that. But it's just all the operators that

are part of the club and are approved and
certified by GSMA. Can actually add and or

remove profiles and thus facilitate the
transition from operator A to operator B

in those cards. They don't only exist in
the soldered form factor. You can also

actually buy plastic cards that allow
that. It's mostly used in like IoT

devices, which I still call machine to
machine. The old marketing term for that.

So some random cellularly interconnected
device that you want to remotely update.

And as a final slide, the CCC event SIM
cards that are around here. If you use the

cellular networks, they are Java SIM and
USIM cards. They support Over-The-Air and

the, not the random update, but the
remote application management. The remote

file management at least via SMS-PP
haven't tested anything else. It did for

sure do not support HTTPS yet. And if
you're interested in playing with any of

that and writing your own Java applet,
there's even a Hello World one around for

several years that you can use as a
starting point. You can get the keys for

your specific card from the GSM team and
then you can play with all of this in a

way that normally only the operator can do
with the card. Some hyperlinks which are

actually hyperlinks on those slides. So
you have to look at the PDF to see them.

Yeah. And that brings me to the last slide
and I'm very happy to see questions.

Thanks.
Herald: Thank you. Thank you so much.

Actually, talks like this one is one of
the main reasons I go to Congress, because

sometimes I just take a dive into a topic
I know nothing about and it's presented by

a person with literally decades of
experience in the field.

So it's amazing. And we have time for
questions. So keep them coming. And the

first one is microphone number 4.
Microphone 4: What you say makes me want

to have a firewall between my phone and my
SIM card. Is there a firewall?

Harald: Not to my knowledge, really. I
mean, there are some vendors of

specifically secure telephones that say,
well, we have a firewall sort of built-in.

Not sure to what extent and what detail,
but not as a separate product or a

separate device. At some time people
developed so-called interposer SIM cards,

which you can slide between the SIM card
and the phone, but that doesn't really

work with you know Nano-SIM cards and so
on anymore. And those interposers those

were mostly used to avoid, you know, SIM
locking and so on. But of course with such

a device you could of course implement a
firewall. Keep in mind that almost all of

the communication. I mean the OTA may be
encrypted, but all of the communication

between the phone and the card is
completely unauthenticated and

unencrypted. So you can actually intercept
and modify that as much as you want. And

there's actually a project I forgot to
mention in more detail. That's the

osmocon project called SIM Trace,
which is a device that you can actually

put as a man in the middle to trace the
communication between card and phone.

Herald: Thank you. Mic one.
Microphone 1: Could you please elaborate a

little bit about the SIM Checker attack
because the telephone provider said it's

only possible if you have S@T browser on
the SIM card and most claim they don't

have. So do you have a feeling how many of
SIM cards have a S@T browser and which are

attackable or which other applications are
attackable by the SIM Checker attack?

Harald: I'm not involved in those attacks,
so I cannot really comment on that in

detail. But I know there is a tool
available, an open source tool that is

made available by SR Labs, which allows
you to test cards. So if you want to check

different cards, you can use that SIM
tester. I think it's linked from the slide

here. Yeah, the SR Labs SIM tester. That's
a Java application. I don't have any

figures or knowledge about this. In terms
of the figures you're asking for. Sorry.

Herald: Thank you. Let's take a question
from the Internet next. Hi, Internet

people.
Signal Angel: There was a question, Can

the eSIM can be seen as back to the roots,
especially compared to what the U.S.

market had in the early time?
Harald: Um. Well, that refers to the

situation that the identity is hardwired
into the phone and not replaceable. And I

think. No, not really, because it can be
replaced and it can be replaced by any of

the operate like the normal commercial
operators. Of course, it means you cannot

use such a device in, let's say, a private
GSM network or in a campus network for 5G,

which apparently everybody needs these
days now. So there are limitations for

such use cases. But in terms of the normal
phones switching between operator A and

operator B. That's exactly what the system
is trying to solve. It's just that if

you're not part of the club, you've lost.
Herald: Thank you. The person behind Mic 5

has a very nice hat and we're all
about fashion here. So the next question

goes to you.
Harald: Nobody told me that.

Microphone 5: <i>not understandable</i>'s
mentor said not a Google one? And my

question was answered, I think because I
wanted to know what prevents a POC from

providing an eSIM.
Harald: A profile for an eSIM. Yes, that's

exactly the problem that it needs in order
to install it. It needs to be approved and

signed and so on and so on. And you need
to be part of that GSMA process. So first

of all, you would have to technically
implement all of that, which is doable in

all specs of public. But then you need to
get it certified, which is maybe

less doable. And then finally since 
you're not a GSMA member and not an

operator. You cannot become a GSMA member
and you don't have the funds for it

anyway. So that is certainly not going to
work. But the POC could provide an actual

like a physical eSIM chip. So if somebody
wants to

do a hot air rework. That's easy, and I
mean, you can buy them just like

other SIM cards and then you have your
identity inside. But of course, that

doesn't really solve your problem, I
suppose.

Microphone 5: Okay.
Herald: Thank you. No more people in cool

hats. So you'll keep picking at random.
Mic 7, please.

Microphone 7: Thanks for the amazing talk.
Um, I have a question about the flash

file system on the cards. I've already
worked with the cards on the file system

level due for some files, you need to
specify this. You would need to load. Do

you need to do like a authentication tango
provides a CH view like the PIN one and

then you only have access to some of the
files. And since cheap flash is built into

those devices, my question is whether they
are cheap hardware or software tricks to

access the files or modify the files which
are usually locked behind the PIN.

Harald: Not that I'm aware of. And if I
would say they are rather specific to the

given OS or whatever on the cards and as
so many out there. So I think it's

unlikely in terms of write cycles, you can
typically buy between one hundred thousand

five hundred thousand write cycle flash in
SIM card chips. That's sort of what the

industry sells. But then of course you
have all kinds of weird leveling and then

there are algorithms and SIM card
operating systems even go as far as to

like you can specify which files are more
like the update frequencies. So it will

use different algorithms for managing the
flash there. But an interesting anecdote

for that if we have the minute. And I was
involved openmoko. Some people may

remember that was an open source
smartphone in 2007. And, um, there

actually we had a bug in the baseband
which would constantly keep rewriting some

files on the flash of the SIM card. And
actually we had some early adopters use us

where the SIM cards got broken basically
by constantly hammering them with write

access. So, um. Yeah. But nothing that
I know about any kind of, um. Access

class bypass or something like that.
Microphone 7: Thank you.

Herald: Microphone 6, which I often
neglect because the lights are blinding me

when I look that way.
Microphone 6: Um, thanks for the helpful

talk. I have a twofold question. Um, so if
I understand correctly your talk, it is

impossible to know the code that's
running on the same, right? So I have this

twofold question is about going further,
is there something buried in the specs to

understand more concretely, this
protocols?

And is there any way to dump the code
that's running on the SIMs?

Harald: In terms of documentation, beyond
the specs, there is one document that I

always like very much to recommend, which
is also linked here. Yes, the so-called

SIM Alliance Stepping Stones. No idea why
it's called that way, but that's how it's

called, there's a hyperlink. So if you 
work on the slides, you can download it.

That's a rather nice overview document

about all the different specs
and how it ties together.

So I can recommend that. And in
terms of towards to dump the code on the

SIM card. I mean, yes, of course. Tools
exist, but those tools are highly specific

to the given smartcard operating system
and or chip. And I'm not aware of any such

tools ever having leaked. I mean, I get
such tools for the cards that I in the

company that I work, I work with. But
yeah, of course, the SIM cards out in the

field should be locked down from such
tools and they are highly specific to the

given OS and SIM.
Microphone 6: OK.

Herald: Thank you.
Harald: So maybe one addition to that,

it's normally made in a way that basically
if you want to sort of reset the card or

something. So there's always sort of once
the card is in the operational lifecycle

state, which is when you use it normally
if you ever want to bypass some

restriction or you want to sort of do
something that is not permitted by the

spec, by the by the permissions anymore,
you have to sort of recycle the card and

get it back into the so-called
personalization lifecycle state. And most

often that is done with a complete wipe,
at least off the file system or with a

complete wipe of the operating system. So
you're back to the bootloader of the card

and then you can basically start to
recreate the card.

But it's typically implemented in a way
that it always is together with an erase.

So they tried at least to make it safe.
There's a question there, but not at the

microphone. Oh there is a microphone. Oh,
sorry. But yeah, your job. Sorry

Herald: Yeah, I think the person behind
Mic 4 has been standing there for ages.

Microphone 4: You mentioned that the
card can instruct the phone to open the

website, but I have never seen this and
I've seen use cases where I think it would

be useful to do this. So is this
not supported in most OSes or why?

Harald: It's a good question, actually. If
you read all those specs, like especially

these proactive SIM specs and so on. I
always have the original: OK it's all very

interesting, but I've never seen anything
like that anywhere." So I completely agree

with you. Whether or not it's supported by
the phones is a good question. And I think

without trying, there's no way to know. So
you would actually have to write on a

small extend a Hello World app and to to
do that and see and do a testing with

various phones. I would fear that since
it's a feature that's specified but rarely

used, a lot of devices will not support it
or not support it properly because it's

never tested, because nobody's ever asked
about testing it. But that's just my

guess.
Herald: Thank you, Mic 1.

Microphone 1: OK. Hello. Um, my question
is, when you have an eSIM and you want

to provisioning it. Could it be done with
TR-069 or something similar?

Harald: No. That's a completely different
set of protocols that are used for that.

And that's that relates to this,
global platform, 2.2 and XP, I think

it was. Yeah, I don't find it right now.
But there's this spec that specifies all

the different interfaces and protocols
that are used between the elements and

it's completely different. I think
also the requirements are very different

because you have these multiple
stakeholders. So you have the original

card issuer, the original operator, then
you have other operators. And it's not

like a single entity that just wants to
provision its devices, but it's sort of a

multi stakeholder approach where you want
to make sure that even in like a

competition between operators still this
is possible and that people for trust in

the system, that even if the original
issuing operator doesn't like the other

operator, it still will work and it will
even work in 10 years from now or

something in where it's in the field. So I
think the requirements are different.

Herald: Thank you. That was the last
question of the last talk of the day.

Harald: Luckily, not the last day.
Herald: Not the last day, the first day.

So there's three more days ahead of us.
Thank you.

<i>Applause</i>

<i>Music</i>