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.
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 shit 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 bitch.
(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.