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. *Applause*
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.
*laughter from the audience* *Harald laughs*
*Applause* 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". *chuckles* 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: *not understandable*'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.
*Applause*
*Music*