Welcome, everyone. My name is Eric Butler. And I'm Carl Kosher. We're here to talk to
you about SIM cards. This is a project that started for me last year when I heard about
tour camp. This is a hacker camping trip. You could think DEF CON, but outdoors and
with tents instead of hotel rooms. This was the second one. The first one was a lot of
fun and I was looking for a way to get more involved. And I thought it would be great
because it's in the middle of nowhere to run a cell phone network. There was no GSM service
out on the Washington coast. And so I got some ‑‑ I pitched the idea to some friends
and we got people together and we decided we could make this happen. And my part of
the project specifically was to procure SIM cards. So I didn't know anything about what
a SIM card was. So it stands for subscriber identity module.
SIM cards contain identity information, usually the IMSI
and KI to create session keys. They are designed to be secure. And tamper‑resistant. So the
idea is the key information can't be extracted from the card even if you have physical possession.
SIM cards ‑‑
not to be cloned. There have been some issues with that in the past. Anyone who has a GSM phone
definitely has a SIM card. And now even the carriers that traditionally didn't have them, like
Verizon, are switching over to using them as part of their LTE migration. And while I was
learning about this, I found that SIM cards can also run apps. So what is that all about? So
before there was any concept of mobile development, there was this idea that applications would
live in your SIM card. And so the phones would be dumb hosts. You could move your SIM card
between all these phones and all your contacts and all your apps would move with it. And the
telcos liked this because it put them in complete control over everything that you could run. So
fortunately, that didn't happen. And we live in a little bit more open world today. So you
might think that this is an obsolete technology. But it's not. It's a new technology. It's a
technology. But it's actually still quite interesting because this technology is still around
almost a decade later mostly unchanged. A lot of these standards came about in the mid-90s and
still work today, are still supported today by modern smartphones, Android, iPhone. And so I
wanted to really understand how this worked and uncover the mystery. And really the motivation was
that SIM cards, as it turns out, are little tiny computers that everyone has in their
pocket. And they can be used for a lot of different things. And they can be used for a lot of
different things. And they can be used for a lot of different things. So I thought there was an
interesting opportunity because I wanted to have SIM cards for this tour camp network. And I
thought, why not get cards that would support running these apps. This ended up being a lot of
work. It turns out most places that want to sell you SIM cards want to sell you about 500,000 to
start. We were looking for about 500.
A lot of them were looking for us to sign an NDA, which we didn't want to do because
we wanted to be able to talk about everything we learned.
Some of the cards that we found would support apps, but didn't have any GSM support.
So they wouldn't help for what we needed.
There was very little documentation on not only where to get cards, but how to program
them, what you can do with them.
And so we put a lot of time into collecting a lot of information together, and we're hoping
people can learn from our misery and build some interesting things with sort of a forgotten
technology.
So the SIM cards that we ended up getting actually have an AVR processor in them, not
unlike an Arduino.
They have 64K of memory and a tiny amount of RAM.
They run what's called JavaCard, which we're going to talk about in a little bit.
And they're somewhere between 20 and 30 memory.
So they are definitely little computers, although definitely have a lot of limitations.
One of the things that I was really hoping was that when people arrived at the conference,
there's a registration tent where you pull up, and this is where you get your badge and
the schedule.
And I wanted to have the SIM cards right there at the entrance to really encourage people
to use the network.
And so this is what you saw when you arrived.
You had a little packet from us.
Our cell phone company was called ShadyTel.
And we gave you not only a SIM card.
But all of the private key information and everything else that you usually don't have
when you get a SIM card from a carrier.
So we really wanted to make this a very open thing that people could hack on.
The cell phone network was a huge hit.
We gave away almost 500 SIM cards.
And we had over 400 phones connect to the network.
We had a lot of people using SMS saying, where are you?
It was a big campground.
So people were trying to find each other.
We had free outbound cards.
Free outbound calling anywhere in the world.
So people were not only calling people in the camp, but also someone called their mom
in Australia.
And it was really great.
So in some ways, our network was more functional than a lot of other networks.
So that would have been very expensive to do.
And we even had an FCC license for the weekend.
So it was like a very legit thing.
Thanks.
So SIM applications are often called applis.
They run on the SIM card, CPU, completely separate from the phone.
In many cases, the phone doesn't even see what's going on.
The SIM card has its direct connection to the baseband in many cases, again, without
going through the phone's operating system.
SIM applications can be remotely installed by the carrier, which we're going to cover
a little bit later.
And most carrier SIM cards today support the technologies that we're going to talk about.
It's very common.
Cool.
SIM cards can have multiple apps running on them that is managed by a card manager master
application and referenced by an AID, applet ID.
And on a modern SIM card, the GSM support is basically just another app.
So it's written in a similar way to what we're going to talk about today.
So what can one of these applis do?
Most phones, including modern smartphones, Android, and iPhone today, will support basic
user interface.
It will show up on the phone to display menus, text.
You can do user input.
You can sometimes play sounds.
And this also works on a lot of dumb phones, which is interesting for the developing world.
Some phones will let the SIM launch URLs.
Some phones you can send SMSs, initiate calls, use data service.
You can receive events, so you might in some cases be able to detect when the user is dialing
something and maybe even rewrite that number.
There are a lot of other options.
There's over 200 unique features that a handset can declare to the SIM card, this is what
I support.
And in some cases, you can even run arbitrary AT commands and send directly to the GSM modem.
Just a few examples of SIM applis in the wild.
On the far left, we have M-Pesa, which is a very, very popular mobile payment system
in Kenya with over 15 million users.
And almost all of that is based on the SIM applet technology.
All right.
So let's talk about the SIM applet technology.
It's also sometimes used for menus to top up your phone or to get other information.
Not very common in the U.S., but it's much more common in other places.
So it's not at all surprising if you've never seen this on your phone if you live here,
but if you're coming from somewhere else, you might have seen this before.
All right.
So how do these applications actually work?
So with any good telco technology, it is a maddeningly complex stack of technology.
At sort of the bottom layer is the smart cards themselves, which SIM cards are a particular
type of.
There's JavaCard, which came out of Sun in the late 90s, which lets you write smart card
applications with a variant of Java.
And this is what most SIM cards support today for writing applis in.
There's the SIM toolkit API, which lets the SIM card talk to the phone and push events
and receive events as well.
And then there's this standard called global platform, which was originally developed by
Visa to allow third parties to develop applications and load them onto the card.
So a bit about smart cards.
They're designed for secure storage and computation.
And one of the key ideas with smart cards is that the secret keys do not leave the card.
So you can ask the card to do things on your behalf.
Like sign things, encrypt things, decrypt things.
So these are widely used for, like, corporate logins.
U.S. government uses them a lot.
They're used for satellite TV DRM.
They're used for e-cache in some parts of the world.
All sorts of things.
And basically the way that these work is that there are these things called APDUs, which
are just command and response packets.
And typically these are just, you know, one-to-one.
A stream of bytes.
And you sort of have an instruction, a class of instruction, a couple of one-byte parameters
and maybe some variable length data.
So that's the basic interface that smart cards have.
So Java card.
It's Java.
Not really.
So there's no garbage collection.
You can call new, but it won't clean up after itself.
There are no characters.
There are no strings.
No floats.
And no multidimensional arrays.
So this gets interesting.
And if you're lucky, you might have some ints.
Otherwise you're stuck with bytes and shorts.
Of course, there's no standard Java APIs for, like, file IO or threads or anything crazy
like that.
One interesting thing about this is that they envision these cards as being very simple.
And so what regular JVMs do...
when they load class files is they verify that the class files are correct and so that they can't
violate any of the safety and security properties that Java tries to provide. Java cards do not have
to verify the apps that are loaded onto them. That is sort of delegated to whoever installs
the applications, which, as you'll see later, typically means that you can't load apps onto
arbitrary Java cards. There are exceptions, though, so everyone loves exceptions. So that's how you
return errors back to the smart card interface. One interesting thing to note when you're developing
for these is that instance and class variables are saved in EEPROM. So those survive through power
cycles, but they have limited write endurance, anywhere from 1,000 to 500,000 write cycles. So
depending on the type of application you're using, you might want to make sure that you're
using the right type of application. Depending on the card, you might not want to update these
variables a lot. So how do you actually build these things? So there are some commercial ‑‑ we
looked into how to actually write these apps for our shady tell sims, and there are a lot of
commercial IDEs for this, but they start around 3,000 bucks. So that was a nonstarter for us. But as
it turns out, you can download the Java card development kit from Oracle for free still. That
was ‑‑ it was kind of surprising, but thanks, Oracle.
You can actually build these with Eclipse. What you have to do is you have to remove the standard
Java run time library and add in the Java card run time library so it knows about the right
classes and things like that. And then you have to do some craziness with the command line.
But we made some tools to make this whole process easier. So what about SDK apps? So SDK apps
are generally ‑‑ they are Java card apps. And sort of the way that they work is that they
first get loaded onto the card. And then the app, when it gets instantiated on the card,
registers itself with the sim tool kit run time. And this sim tool kit run time, whenever the
phone boots up, is informed of the phone's capabilities using those 200 feature bets that we
were talking about. This run time then lets all the applications know that they're going to be
launched on the card. So you have the игрas found. All the applications are set up on the
card. It tells the phone what all the applications are on the card. And then you have this menu of
applications that you can select. And when you select one, it actually dispatches an event to
your particular Java card application. And then the app can do some I.O. back and forth through
the standard sim tool kit API. So basically the way that this code looks is you have a class with
that has, so with JavaCard there are two standard methods.
There's install, which is responsible
for instantiating the class and registering it
with the JavaCard runtime and the SimToolkit runtime.
And there's also this process method,
which takes in these APDUs
and does whatever computation you need there.
For SimToolkit, process is not typically used.
There's typically process tool kit is called,
and these are for events that get delivered from the phone.
You can also request a timer event to be sent back to you,
so you can periodically wake up.
So for TorCamp, what we wanted to do is create
some sample SDK apps to get people interested in this
and sort of get people involved with the SIM cards.
So we had this
simple app that we made that said credits on there,
and it would bring up this list of people involved
in the creation of the GSM network at TorCamp.
And that's all it did the first time you run it.
But the second time you run it,
it would ask if you wanted hints
for the crypto challenge that we were running.
And the interesting thing about this is that
we were able to store the hints on secure hardware,
so you couldn't extract them, and we also had some tamper
resistant flags that were stored again in secure hardware
to mark whether you had viewed any of the hints or not.
And as we'll describe later,
we also had a way to remotely query
what hints people had viewed,
although we never got around to implementing that.
So what does this code actually look like?
I warn you, it's ugly.
So if you want to create strings,
you might remember there are no characters and no strings,
so you have to create a byte array of individual bytes.
or individual characters. This is by far the most painful part of writing apps. Well, except
for debugging them. That's even more painful. But we'll get to that.
And so basically the way that these that this Tor camp app work is so install gets called
by the Java card run time when it gets installed. That registers itself with the run time so
you can select the app. It also registers itself with the SIM toolkit. And a lot of
this code here is just for reference later in the slides that will be available from
our website. So you don't have to memorize any of this right now.
And then sort of when events get handed down from the phone, you get a single byte that
says what kind of event it is. Usually it's like a menu selection or something. And in
this case,
it checks to see if the hints that were given, if we've displayed any hints. If not, we just
show the credits. Otherwise, we mark that this app has been run before. And then we
show the menu for the hints. Constructing UIs to send back to the phone is really ugly.
You basically have this byte array of type length values. And you have this API sort
of that lets you append stuff to this byte.
And you have to send this byte array back. And it's kind of nightmarish. But it works.
So that's basically what it's doing here is creating these menu items and sending it back
to the phone.
And then also that remote query capability. We had ‑‑ we used the standard Java card
process method to expose an instruction that would let you query the card for what hints
had been viewed.
.
.
So to build Java card apps, you have to target
an older version of Java. But you start out using the standard compiler, so targeting
1.1 byte code, and 1.3 source compatibility. Once the standard Java compiler creates the
class file, you then need to convert it to something that is compatible with Java card.
And the SDK includes a tool to do that. There is an application ID. We mentioned earlier
that you can have multiple cards ‑‑ or multiple apps on a card. So this is where
where you specify the ID that your app is going to use. A cap file is similar ‑‑
at the end of that, it creates a cap file, which is sort of similar to a jar file. It's
a zip file of byte code. And we've created make files and other scripts to make this
all much easier so you don't have to remember any of these commands. You just type make
and it will go. One of the big questions that I had when I started this project was
how do we actually communicate with the SIM cards physically? And I found that really
there are two types of readers that you have to consider. The most common type is called
PCSC, PC Smart Card API. These are usually designed to be used with full‑size smart
cards. So, you know, when you ‑‑ sometimes when you get a SIM card, it comes in a full
‑size card and you punch it out. What we usually do is we save that plastic housing
and put a piece of tape on the back so we can put the SIM card back in when we want
to interface with it. These are the same types of readers that you would use for any other
smart card for corporate log‑in, for VPN access, anything like that. The other type
of reader is a serial reader. These are usually smaller and are just the size of a standard‑size
SIM card. They're often sold for backing up, like the contacts on your SIM card, but I
don't really know what that is. So, I'm going to go ahead and show you a few examples.
I don't think anybody does that anymore. But they are cheap and easy to get. It doesn't
really matter which reader you get, but the PCSC readers are more compatible because if
you're going to try to use any official software, commercial software, it's almost certainly
built for that API. And there's also an open‑source stack for PCSC that a lot of tools use. So
I highly recommend getting one of those. The reader I use is this one. It was $8 and it
folds up nice and small, so it's very convenient.
So, at this point, we had written some horrible‑looking code. We had compiled it with the Java compiler.
We had converted it to this CAP file. And so we felt like we had this thing ready to
go. We had some SIM cards. But we couldn't really get it to load. We found a lot of references
to a tool called GP shell, which is global platform shell. Couldn't get that to work.
This is sort of a funny story. Our SIM vendor ‑‑ so we asked them, hey, what's the best way
to do this? What software do you use? And they sent us back a screenshot of this very
simple app with, like, choose your file, choose your reader, and hit go, and it will do it.
And we said, oh, great, can you send that to us? Oh, no. Is it available anywhere?
No, no. And then eventually they offered us, oh, okay, for $600 we'll send you this
program that we didn't write and we don't own the copyright to. So we decided not to
do that. And so we kept looking to see what else was out there. And we had to start digging
into a little more detail.
So this program that they were trying to sell us was called the SIM alliance loader. And
they had V1, but SIM alliance had come out with V2. And the SIM alliance is basically
an industry group which advocates for using apps on SIM cards. And they have a bunch
of tools.
.
The SIM alliance loader is this crazy Windows, Java app that is really intended
for experts. It is, you know, it is clearly designed for people who know what they are
doing, which means not us. So we spent a lot of time figuring out how to actually configure
the right ticky boxes and settings to get our apps to actually load. But if you know
what you're doing, and you know what you're doing, and you know what you're doing, and
you're running Windows, and you're willing to put up with the slowness, it takes like
two minutes to load something on a SIM card with us, then this program is really available
and will actually load stuff on our SIM cards. But for a variety of reasons, we thought
that using this, suggesting this to the tour camp attendees was not an acceptable solution
for loading apps onto SIM cards.
So we really needed to schedule a spraying capability analysis and simply began to put
Plus, we had to provision 1,000 of these SIM cards and at two minutes a pop, it would take
quite a while.
So we wanted to come up with something faster and more portable.
And thus we started to delve into the world of global platform.
So what global platform is, it's a standard for loading and managing apps on Java cards.
And one of the things that it does is it defines the card manager app.
So this is the protocols and commands used to load and install apps on the SIM card.
It also covers authentication for loading apps and also encryption between the apps
and off card party.
It also talks about some of the off card responsibilities such as the issuer needs to verify apps that
get put on there.
And because of that.
The issuer.
there are a bunch of security domains that are defined by global platform and basically
the top level one is called the issuer security domain. And the issuer security domain is
responsible for authorizing any code that gets loaded onto the card. And so in practice
this means that you can't load apps onto your own SIM cards. Except a couple of days earlier
at Black Hat, Karsten Knoll showed that about 25% of SIM cards use ‑‑ have a ‑‑ I don't
know, crypto bug, I guess you would call it, where you can actually ‑‑ that you can
actually exploit to load stuff onto these cards. So basically the way that that worked is
that you ‑‑ you can sign these install commands with a desk key. And if that does
not work, it will send you back an error message. And sometimes those error messages are also
signed. So if you don't know the right key you just send random junk and you get back
a signed error response. And since it's des, you can actually brute force this and apparently
he's able to do that with some rainbow tables and that's pretty cool. So going back to global
platform.
platform. When you have a standard unprovisioned, unpersonalized Java card, the issue or security
domain is the default app on the card. So you can just say, hey, install this and set
all these keys. But accessing it on our SIM was much harder because the GSM SIM app was
the default app and we couldn't even select the global platform app. It was totally inaccessible
over the standard APDUs. So we wanted to figure out exactly how this operated.
Brief bit about actually how stuff gets loaded on here. So installation is a two-step process.
You first load the binary, which is the install for load command. And then you need to instantiate
that app by doing the install for install command, which basically, you're going to
give it the application ID of the both of the binary package that you sent to it, the
application ID of the main class to use, and an application ID that you want assigned to
the main instance. And the binary that you sent to it, basically, is just straight from
this cap file. You just unzip the cap file, concatenate everything together, and just
shove it out the card.
And.
works. As I said, unfortunately, this doesn't really work with our SIM cards. In fact, we
found out the only way to actually talk to global platform on our cards is through an
over the air update mechanism like over SMS packets. But fortunately, we didn't have to
actually send these SMS packets. All we had to do was pretend that we were a phone and
send it the right APUs to say that incoming SMS was received and here's the installation.
So what does that actually look like? Well, this is where it gets really complicated and
this is where I spent many, many hours reverse engineering this. So at the top level there's
an APU called cat envelope. And cat envelope is basically a way to deliver to the SIM toolkit
run time some incoming message, either an event.
It's typically an event. Either an incoming SMS or a menu selection or something else.
Inside that, you have an event for an SMS point to point download. Inside that, you
say who sent it. Inside that you actually have the SMS message. Inside that you have
a header and you have your user data, and the user data consists of the header and also
the command. And finally at the very bottom is APU, that
actually gets delivered to global platform. And so this tiny little packet ends up being huge
when sent over this mechanism. And this is, you know, the telecom way. Just wrap everything in
layers of complexity. But in case you missed it, I want to make something clear here. You can use
this exact mechanism to send arbitrary APDUs to SIM cards. Through this SMS capability. One thing
that came up is whether these cards use individualized keys or a single key. And we don't
actually know because we haven't tried this on any commercial SIMs. But there is a one thing that
one reason why they might not use individualized keys is because they don't have a SIM card.
There's something called cell broadcast. And cell broadcast is this sort of variant on SMS that's
mostly used these days for emergency alerts that are pushed to your phone.
And so it's basically a broadcast SMS. And so carriers could actually use this to broadcast
installation messages and push apps out to your phone.
As I said, normally you need to authenticate to do this. If you want to learn how to do it without
authenticating, you can do that. But if you want to learn how to do it without authenticating,
or knowing the private keys, go see Carson Null's talk.
So once we reverse engineered how this actually worked, we wrote this Python script that works
on OSX, Linux, Windows. It just works everywhere. And it's kind of easy to use.
To load an application on the SIM card, all you have to do is just specify what interface you want,
PCIe or serial. And you can do that with a SIM card. You can do that with a SIM card. You can
say dash L for load and give it the CAP file and it loads it. Instantiating is a different story.
And this is all SIM toolkit's fault and Java card's fault. So basically what you have to do is
you say I want to instantiate this. Here is the ‑‑ so the module ID is the application ID of
the main class that you want to use. The instance ID is used for selection of that application.
And then you have to tell it outside SIM toolkit. You have to tell the installer that this is
actually a SIM toolkit app and you would like that to be registered for SIM toolkit as well.
You have to tell the SIM toolkit runtime how many menu entries you want in that
main application menu. You have to tell it how many characters your biggest menu entry is.
And you also have to tell the card exactly how much memory you need both in RAM
to install the app and in the EPROM to ‑‑ for all the instance and class variables.
And you can specify more than is necessary. Like we always specify hex 100 for 256 bytes.
But this is sort of the way that cards manage their memory resources. And then of course you
can also just list the applications on the card with dash T. And there are a bunch of different
commands that you can use. You can also just list the applications on the card with dash T.
This app also supports such as updating the phone book and ‑‑ uh‑oh.
How are these guys doing so far?
Hey.
So the DEF CON experience includes a lot of different things but one of it is cutting edge
technical talk's. It is very hard to get accepted as a speaker. The bar is very, very high.
This is their first time.
so give them a big round of applause
so obviously we have a little bit of a tradition
we're going to do a shot on stage with them
here we go
cheers gentlemen
cheers
now we'll see if they can pick up their talk
where they left off
alright
so how do you know if this works
we have to do this shit all day
how do I become a goon
is my question
alright
so how do you know if this actually works
alright
well
what
oh this is your slide
apparently the shots already go into the head
so after all this work
of going through the steps of writing the code
compiling it, converting it
learning the protocols on how to install it
we finally had something
that appeared to succeed
what you can see on the left
is the same python script
also has that command to list applets
and at the bottom we see
our code
our applet appears to be on the phone
but how do you actually see if it's working
most phones have some way to access the sim menu
that will only appear if the sim card actually has a menu
so on the iphone you go into settings
you go to phone
and a sim applications item will appear
and on android a sim tool kit item will appear
in the main application list
and from there you see the menu of all the cards you have installed
and can interact
so cards are a little bit of a challenge
and so we were trying to talk about if there was a way to actually use the sim card
the app was really bad
we had to put a lot of time into the testing
we had to take out the battery
we had to take out the sim card
we had to put the sim card into your computer
you load some code
you take it out
you put it back in the phone
you put the battery back in
wait for the phone to boot
and see if it worked
and if it doesn't
you do the whole thing over again
and so we were trying to talk about if there was a way
way that we can do any better and sort of simplify this a little bit or at least speed
up the development. And it turns out that there is an open source project called seek
which provides smart card APIs for Android. This can be used for talking to the SIM card,
talking to other types of smart cards like SD cards that have secure elements inside
them. And they actually have patches to the Android emulator. And so we got this ‑‑
we tried this out and it works. So you can get a PCSC smart card reader like we talked
about before, plug it into your computer, start the emulator and the SIM toolkit icon
will show up and you can talk to your SIM and test your apps that way without needing
to constantly swap between a computer and between a phone. The seek project only provides
this as patch files but we've gone through the trouble of building it. We have binaries
for all platforms and our website for the talk at the end has all that.
Another thing that we were wondering about is could we use the phone as a reader?
This is my slide. Karma's a bitch. Yeah.
All right. So one of the ideas that we also toyed around with is that, you know,
since everyone has these phones, they already have these SIM card readers, why can't we
just use the phone for these readers? As it turns out that most radio
interfaces don't actually let you talk directly to the SIM and this is mostly a good thing
because if you are able to talk to the SIM, then you're able to authenticate to the network
and do all sorts of nasty things. But in Europe particularly, there is this method
called the Bluetooth remote SIM access profile or protocol. And basically what that's used
for is ‑‑
This is your car will have a high power GSM modem in it for hands recalling. But it uses
the SIM in your cell phone to authenticate to the network. And this is very different
than how it works in the U.S. because, you know, a lot of cell phones don't have SIM
cards in the U.S. But this is one way to access the SIM over on your phone. We also
toyed around with an idea.
Of writing an app that would run on your phone that could talk to this card and install
apps and things like that. And to do that, we had to reverse engineer this Android app,
the Android remote SIM access profile app. They had some weird crypto stuff in there
that wasn't actually that secure. So we figured out how to break that. But we didn't actually
get this up and running just yet.
Okay. Very bad idea to install this on your phone. It creates a socket that the radio
interface uses that just exposes the SIM card to any app. No permissions needed or
anything at CH mods at 666 or something. It's kind of crazy. So any app can do anything
at once.
But so you might think that SDK apps are pretty limited.
But we think that there's potential for awesomeness here. So one idea that we were talking about
is having an SMS botnet. Because these SIM cards can actually communicate with the network
without the U.S. getting involved, it talks directly to the base band processor. So if
it's able to bypass the authentication to load itself onto SIM cards, it could just
start propagating itself through the cell network. And the main application U.S. doesn't
know what's going on.
It might be interesting. One thing that we think would be really cool is to integrate
Android apps with SIM apps. For example, putting your SSH key on the SIM card so that
the SIM card actually authenticates you to your SSH server instead of something on your
phone. Or maybe storing your Bitcoin wallet securely. Or who knows? What else? There's
many opportunities here. But, of course, you know, we probably need carriers to get on
board to do this securely.
And then one other idea we had was making an Android app that would actually let us
push out these SMSs to someone else to load code onto their other SIM card.
So earlier I talked about my main motivation for getting involved with this was because
everyone's walking around with these things and we don't know much about them. And even
though it's kind of obsolete, they're still widely, widely used. So I think it's a good
idea to use. The same technology is used for a few different
other things. There is a little bit newer protocol called SWP, single wire protocol.
And this actually creates a direct connection between one of the unused pads on the SIM
card and generally an NFC controller in a phone. And this is intended to allow NFC payments
completely separate ‑‑ it allows you to do NFC payments without the phone being involved.
So your SIM card can basically have equivalent to like a MasterCard or Visa PayPass applet
running on it. And when you tap your phone, the NFC controller will talk to the SIM card
directly and authenticate that payment without the OS being involved at all. And so the idea
there is that it might be a little bit more secure. This is actually used by a company
in the U.S. called Isis, which is doing a very, very slow rollout over the next few
years or so. This is a combination of the Telcos and the banks, and it's not really
clear anyone cares about this, but they're using SIM cards to power this. So it's interesting
to know how this all works. And I talked earlier about how SIM cards and SIM apps were
sort of initially going to give control of this whole thing to the carriers. This is
sort of a way that the carriers are trying to go back to those days by controlling this
one little thing, payments, they can charge whatever fees they want, they control who
can use it and how it works. So that's kind of what I wanted to talk about today. So let's
see how it works. Another technology that uses is quite similar
is the secure element found in many Android phones. This is often part of the NFC controller.
So it's similar to the SWP interface used with SIM cards, but it's often just in one
housing. And this is basically a little tiny SIM card inside your phone. It generally supports
Java card. It might be based on global platform. And so all the SIM cards that you're using,
all the same sort of things we've talked about with how to write apps, how to interact
with them, is the same for this thing in your phone. So if you have one of these,
you now have two little computers in your pocket that you may not control. This is
used by the ISIS competitor, Google Wallet, and that's how it does the secure credit card
emulation. So we think that even if SIM cards are possibly
a dead end for writing software, and I think there's still a lot of potential there, there's
still push by these manufacturers to keep this technology relevant and to try to do
new things. So it's not going away any time soon.
We've hopefully made it easy to get started. If you're interested and intrigued, and I
hope you are, it's quite easy. There's very few hardware requirements. It's not an expensive
thing to get started on. The readers are usually less than $20. And it will work with
pretty much any phone. We have some extra SIM cards. And we don't have anything official
set up. But we're hoping that we'll be able to use them in the future. We're hoping that
we'll be able to do some sort of EFF donation for them. So please come see us if you're
interested in getting a hold of these. As I mentioned earlier, it was quite difficult
for us to get even midsize quantities. So individual quantities of these are pretty
hard to find. We've put up a website for the talk with these slides, lots more technical
info, all of our code, our make files, our Python scripts, those binaries for the patched
Android system, and a whole lot more. And there's information on how to get in touch
with us. Thank you.
Thank you for coming. And I hope you will join us in hacking on SIM cards.