Tip:
Highlight text to annotate it
X
>> ERIC BUTLER: Welcome, everyone. My name is Eric Butler.
>> KARL KOSCHER: And I'm Karl Koscher. >> ERIC BUTLER: We are here to talk to you
about SIM cards. This is a project that started for me last year when I heard about Toorcamp.
This is a hacker camping trip. You can think DEF CON, but outdoors and with tents instead
of hotel rooms. This was the second one. I thought it would be great in the middle of
nowhere, to run a cell phone network. There was no GSM service out on the Washington coast.
So I pitched the idea to some friends and we got people together, and we decided we
can 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, the
international mobile subscriber identity and KI which is the key used to authenticate with
the cell network and to create session keys. SIM cards are smart cards that are designed
to be secure, and tamper resistant. So the idea is that the key information can't be
extracted from the card, even if you have physical possession. SIM card ‑‑ they
are designed not to be cloned. There have been some issues of 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. What is
that all about? So long ago, long before the iPhone, before Android, really 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. Could you move your SIM card
between all of these phones and all of your contacts, and all of 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 more open world. You might think this is an obsolete technology. 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 and iPhone. I wanted
to understand how it works and uncover the mystery. The SIM cards, as it turns out are
little tiny computers that everyone has in their pocket that you don't control, and may
not know very much about. And everyone is walking around with these things.
So I thought there was an interesting opportunity because I wanted to have SIM cards for this
Toorcamp network and I thought why not get cards that would support running these apps.
This ends 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. We wanted to be able to talk about everything we learned.
Some of the cards would support apps but didn't have any GSM support. So they wouldn't help
for what we needed. There was very little documentation not only on 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 have an ADR processor in them, not unlike
in Arduino. They have 64k of memory and tiny amount of RAM. They run what's called JavaCard
which we will talk about in a little bit. And they are somewhere between 30 and 40 megahertz.
They are definitely little computers although definitely have a lot of limations.
One of the things that I was really hoping was when people arrived at the conference,
there is 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. We gave
you all the private key information and everything else that you usually don't have when you
get a SIM card from a carrier. We wanted to make this an 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 connected to the network. We had a lot of people using SMS saying, where
are you? There was a big campground and so people were trying to find each other. We
had free outbound calling anywhere in the world. 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.
That would have been very expensive to do. And we even had an FCC license for the weekend.
So this is a very legit thing. (Applause).
>> ERIC BUTLER: Thanks. So SIM applications are often called applets.
They run on the SIM card completely separate from the phone in.
Many cases the phone doesn't even see what's going on. The SIM card has the direct connection
to the base band in many directions again without going through the phone's operating
system. They can be remotely installed by the carrier, which we will cover a little
bit later and most carrier SIM cards today support the technologies that we are going
to talk about. It's very common. Cards can have multiple apps running on them,
that's managed by a card manager master application, and referenced by an AID, applet ID and on
a modern SIM card, the GSM is basically another app. It's written in a similar way to what
we are going to talk about today. So what can one of these applets do. Most
phones including modern smartphones 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 us a message, initiate
calls, use data service. You can receive events or 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 are 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
sent direction to the GSM modem. Just a few examples of SIM applet in the wild. We have
MPESA, which is a mobile payment system in Kenya with over 15 million users and almost
all of that is based on 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 US but much more common
in other places. So it's not at all surprising if you have never seen this on your phone
if you live here but if you are coming from somewhere else, you might have seen this before.
>> KARL KOSCHER: All right. How do these applications actually work? So with any good telco technology,
it's a Maddening complex stack of technologies. 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 applet and there's a 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 GlobalPlatform, which was originally developed
by Visa to allow third parties to develop applications and load them on to the card.
So a bit about smart cards. They are 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 log‑ins, US government uses
them a lot. They are used for satellite TV DRM, they are used for ecache in some parts
of the world. All sorts of things. And basically the way that they work there
are these things called APDUs, which are command and response packets. Typically, these are
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 JavaCard. It's Java. Not really.
There's no garbage collection. You can call new, but it won't clean up after itself. There
are no characters. There are no strains New York floats and no multidimensional arrays.
So this gets interesting and if you are lucky, you might have some ints, otherwise you are
stuck with bytes and shorts. Of course, there's no standard Java APIs for 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 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. JavaCards do not
have to verify the apps that are loaded on to them. That's sort of delegated to whoever
installs the applications which as you will see later, typically means that you can't
load apps on to arbitrary JavaCards. 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 are developing for these is that instance and class variables
are saved in EEPROM so those survive through power cycles but they have limits write endurance,
anywhere from 1,000, 5,000 write cycles. So you may not want to update these variables
a lot. How do you actually build these things? So
there's some commercial ‑‑ we looked into how to actually write these apps for
our Shadytel SIMs and there are a lot of commercial IDEs for this, but they start around $3,000.
That was a nonstarter for us. You can download the JavaCard development kit from Oracle for
free. That was kind of surprising, but thanks, Oracle, for that.
You can actually build these with eclipse. You have to add in the JavaCard run time library
and you remove the JRE library. 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 STK apps. So STK apps are JavaCard apps and the way that they work is that they
first get loaded on to the card and then the app when it gets instantiated on the card,
it registers itself with the SIM card toolkit run time, and this SIM toolkit run time, it's
informed of the phone's capabilities using those 200 feature bests that we were talking
about. This run time then lets all of the applications know ‑‑ or 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
JavaCard application. And then the app can do some IO back and forth through the standard
SIM toolkit API. And so basically the way that this code looks
is you have a class 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
run time, and the SIM toolkit run time and there's also a process method which takes
in the APDUs and does whatever computation you need there.
For sim toolkit process is not typically used. There's typically process toolkit 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 Toorcamp, what we wanted to do is create some sample STK Aprils to get people interested
and use the SIM cards. We had a simple app that we made that said "credits" an there
and it would bring up the list of people who created the GSM network at Toorcamp, but the ‑‑
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 hinted 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. You couldn't extract them and we had some tamper‑resistant
flags that were stored on secure hardware that marked whether you had viewed any of
the hints or not and then as we will describe later, we 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 nor debugging them. That's even
more painful. (Laughter).
But we will get to that. And so basically, the way that these ‑‑
that this Toorcamp app worked, the install gets called by the JavaCard runtime when it
gets installed. That registers itself with the runtime and you can select the app. It
registers itself with the SIM toolkit and a lot of this code is for reference later
and 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 the ‑‑ when ‑‑
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 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 ‑‑ 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 pin stuff to this byte array and you have to send a 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 JavaCard
process method to expose an instruction that would let you query the card for what hints
had been viewed. >> ERIC BUTLER: So to build JavaCard apps,
you have to target an older version of Java, but you start out using a standard compiling,
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 JavaCard,
and the STK includes a tool to do that. There's an application ID we mentioned earlier, that
you can have multiple cards or multiple apps on a card. This is where you specify the ID
that your app is going to use. A cap file is similar ‑‑ it's ‑‑
at the end of that, it creates a cap file which is similar to a jar file, it's a zip
file of byte code and we have created make files and other scripts to make this all much
easier so you don't have to remember any of these commands. You can 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 a full‑sized smart card. So, you know, sometimes when you get a SIM card, it
comes in a full sized 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 in when we want
to interface with it. These are the same type of readers that you would use for corporate
log‑in and 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 standardized SIM card. They are
also sold for backing up, like the contacts on your SIM card, but I don't think anybody
does that anymore. They are cheap and easy to get. It doesn't matter which reader you
get, but the PCSC readers are more compatibility. If you 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 open source uses and I highly recommend getting one of those. The reader
uses this one, which is $8 and it folds up nice and small. So it is very convenient.
So at this point, we had written some horrible looking code. We had compiled it with the
Java compiler. We converted it to this cap file and 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 GPshell, which is GlobalPlatform shell. We couldn't get it work. Our SIM vendor, we
asked them, hey, what software do they use? And they sent us back a screen shot of this
very simple app with like choose your file, choose your reader, hit go and it will do
it. We said, oh, great, can you send it to us? Oh, no. Is it available anywhere? No.
No. No. And then eventually, they offered us, okay,
for $600, we will 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 details on the communication protocols
that are used to interface with smart cards. >> KARL KOSCHER: So this program they were
trying to sell us was SIM Alliance Loader. SIM alliance had come out with v2 and it's
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's 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 to key boxes
and settings to get our apps to actually load, but if you know what you are doing, and you
are running Windows and you are willing to put up with the slowness, it takes like two
minutes to load something on a SIM card and this program is available and it will load
stuff on our SIM cards. But for a variety of reasons, we thought that
using this ‑‑ suggesting this to the Toorcamp attendees was not an acceptable solution
for loads apps on to SIM cards plus we had to prevision a thousand 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 GlobalPlatform. So what GlobalPlatform is, it's a standard for loading and managing
apps on Java card. It defines the card manager app. This is the
protocols and the commands used to install apps on the SIM card. It covers authentication
for loading apps and 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 ‑‑ so there's a bunch of security
domains that are defined by GlobalPlatform and basically the top level one is the issuer
security domain. That's responsible for authorizing any code that gets loaded on to the card.
And so in practice, this means that you can't load apps on to your own SIM cards, except
a couple of days earlier at Black Hat, Karsten Nohl showed that 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 on to those cards.
The way that worked is you ‑‑ you can sign these install commands with a desk key,
and if that desk key is incorrect, it will send you back an error message. And sometimes
those error messages are also signed. If you don't know the right key, you send random
junk and you get back a signed error response. And because it's desk, you can brute force
this and apparently he's able to do this with some rainbow tables and that's pretty cool.
But ‑‑ so going back to GlobalPlatform, when you have a standard unprovisioned, unpersonalized
JavaCard, the issuer security domain is the default app on the card. So you can just say,
hey, install this and set all of these keys but accessing it on our SIM was much harder
because the GSM SIM app was the default app and we couldn't select the GlobalPlatform
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 give it the application ID, 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 send to it, basically
is just straight from this CAP file. You unzip the CAP file, concatenate everything, and
shove it out the card, and that works. As a said, unfortunately this doesn't really
work with our SIM cards. In fact, we found out the only way to actually talk to GlobalPlatform
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 save 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 APDU called
cat envelope. And that's a way to deliver to the SIM toolkit some 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 a header and also
the command and finally at the very bottom is APDU that actually gets delivered to GlobalPlatform.
And so this tiny little ‑‑ (Laughter).
‑‑ 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. One reason they might not
use individualized key is there's something called cell broadcast. And cell broadcast
this is 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 or knowing the private keys, go to see Karsten Nohl's talk.
So once we have 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. So load an application on the SIM card, all
you have to do is just specify what interface you want, PCSC or serial and say dash l for
load and it loads it. Instantiating is a different story. And this
is ‑‑ this is all SIM toolkit's fault and JavaCard's fault. Basically you say I
want to instantiate this. So the module ID is the application ID of the main class that
you want to use. The instance AID is used for selection of that applet outside of SIM
toolkit. You have to tell the installer that this is actually a SIM toolkit app and you
want it to be registered and how many menu entries you want in that main application
menu. You have to tell it how many characters your biggest entry is. You have to tell the
card exactly how much memory you need, both in RAM to install the app and in the EEPROM
to ‑‑ for all of the instance and the class variables. And you can ‑‑ 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 this app supports such as updating the phone
book and uh‑oh. >> How these guys doing so far?
(Applause) >> Okay. So the DEF CON experience includes
a lot of different things but one of it is cutting edge technical talks. 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. (Applause)
So obviously we have a little bit of a tradition. We will do a shot on stage with them. Here
we go. >> Cheers, man!
>> Cheers, gentlemen! >> Cheers! Now we will see if they can pick
up their talk where they left off. (Laughter)
>> KARL KOSCHER: All right, so how ‑‑ >> We have to do this *** all day. So ‑‑
>> KARL KOSCHER: How do I become a goon is my question.
All right. So how do you know if this actually works?
Well ‑‑ what? Oh, this is your slide. Okay. I'll ‑‑ apparently the shot already
going to the head. So ‑‑ >> ERIC BUTLER: So after all of this work
of going through the steps and learning the protocols on how to install it, we finally
had something that appeared to succeed. What you can see on the left is our ‑‑ the
same Python script also has that command to list applets and at the beginning we see the
applet appears to be on the phone but how do you actually see if it's working?
Most phones have some way to access a SIM menu that will only appear if the SIM card
actually has a menu. So on the iPhone, you go into settings and go to phone and the SIM
applications menu item will appear and on Android, it will appear in the Min application
list. And from there, you see the menu of all the
cards you have installed and can interact. Karl was saying one of the worst parts of
this is writing the code and writing out strings but testing is actually pretty bad too. So
you can imagine this flow is you turn off your phone, you take out the battery and take
out the SIM card and you put the SIM card into your computer and you load SIM card and
you put the battery back in and 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 that we can do any better and sort of simplify this a little bit, or at least
speed up the development. It turns out there's an open source, called
SEEK, which provides smart card APIs for Android. This can be used for talking to the SIM card
and SD cards that have secure elements inside of them, and they actually have patches to
the Android emulator. We tried this out and it worked.
So you can get a PCSC smart card reader, like we talked about before, and plug it into your
computer and start the emulator, 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 provides this only as patch files. We have gone through the double of
building it and have binaries for the platforms and the website for the talk at the end has
all of that. Another thing that we were wondering about
could we use the phone ‑‑ >> KARL KOSCHER: This is my slide. Karma is
a ***. (Laughter).
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 are 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 access SIM or protocol. And basically what that is
used for is your car will have a high‑powered GSM modem in it, for hands‑free calling
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 US, because, you know, a lot of cell phones don't have
SIM cards in the US. 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 and 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 protocol. 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.
By the way, very bad idea to install this on your phone. It creates a socket that the
radio interface uses that expose it's to apps. It CH mods it, to 666 or something. It's kind
of crazy. So any app can do anything it wants. So you might think that STK 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 bot net because these SIM cards
can actually communicate with the network, without the OS getting involved. It talks
directly to the base band processor. So if it's able to bypass the authentication on
SIM card it's could start prop indicating itself through the cell network and the plain
application OS 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, butting the SSH
key so it's authenticates you to the server instead of something on your phone, or maybe
securing your bit coin wallet security. What else? There are 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 is making an android app that would let us push out the
SMSs to someone else to load code on to their other SIM card.
>> ERIC BUTLER: So earlier, I talked about my main motivation for getting involved with
this was because everyone is walking around with these things and we don't know much about
them and even though it's kind of obsolete, they are still widely, widely used.
The same technology is used for a few different other things. There's 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 a Visa pay pass 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 US called ISIS which has been doing
a very, very slow rollout over the next year or so.
This is a combination of the telcos and the banks and it's not clear that anyone cares
about this. They are using SIM cards to power all of this. It's interesting to know how
it works. I talked about how SIM cards and SIM apps were 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.
Another technology that's quite similar is the secure element found in many Android phones.
This is often part of the NFC controller. It's ‑‑ 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 JavaCard. It might be based on GlobalPlatform,
and so all the same sort of things we have talked about with how to write apps and how
to interact with them is the statement for the thing in your phone. If you have one of
these, you 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 a lot of potential there, there's still a push by these manufacturers
to keep this technology relevant and do new things. So it's not going away any time soon.
We have hopefully made it easy to get started if you are interested and intrigued and I
hope you are. It's very few hardware requirements. It's
not an extensive 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 hope to do some EF ‑‑ we hope to do some EFF donations
for it. As I mentioned, it was quite difficult for us to even get mid‑sized quantities
of these. We put up a we can side for the talk with these slides, a lot more technical
info. All of our code, our make files, our Python scripts and the binaries for the batched
Android system and a whole lot more and here's information on how to get in touch with us.
Thank you for coming and I hope you will join us on hacking on SIM cards.
(Applause)