 Welcome everyone. My name is Eric Butler and I'm Carl Kausher. We're here to talk to you about SIM cards. This is a project that started for me last year when I heard about TourCamp. 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, the international mobile subscriber identity and the KI which is the key used to authenticate with a 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're designed 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 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. 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 like 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 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, 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's walking around with these 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 were 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 Java card, which we're going to talk about in a little bit. And they're somewhere between 20 and 30 megahertz. So they are definitely little computers although definitely have a lot of limitations. One of the things that I was really hoping was when people arrived at the conference there's a registration tent where you pull up and this is where you get your badge and this 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 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 applets. 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 base band 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. 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 than what we're going to talk about today. So what can one of these applets 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 us messages, 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 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 directly to the GSM modem. Just a few examples of SIM applets 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. It's also sometimes used for menus to top up your phone or to get other information. Not very common in the US 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 technologies. At sort of the bottom layer is the smart cards themselves which SIM cards are a particular type of. There's Java card 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 applets 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 and crypt things, decrypt things. So these are widely used for like corporate logins. US government uses them a lot. They're used for satellite TV, DRM. They're used for eCash 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, 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 multi-dimensional 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 I.O. 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 on to 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 a thousand to 500,000 write cycles. So depending on the card you might not want to update these variables a lot. So how do you actually build these things? So there's 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 non-starter for us. But as it turns out you can download the Java card development kit from Oracle for free still. That was kind of surprising but thanks Oracle for that. You can actually build these with Eclipse. What you have to do is you have to remove the standard Java runtime library and add in the Java card runtime 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 toolkit runtime. And this SIM toolkit runtime whenever the phone boots up is informed of the phone's capabilities using those 200 feature bets that we were talking about. This runtime then lets all 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 Java card 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 Java card there are two standard methods. There's install which is responsible for instantiating the class and registering it with the Java card runtime and the SIM toolkit runtime. And there's also this process method which takes in these 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 four 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 hence 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 this TorCamp app work is so install gets called by the Java card runtime when it gets installed that registers itself with a runtime so you can select the app. It also registers itself with the SIM toolkit. And a lot of this code here is just for a 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 pin stuff to this byte array 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 use 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 a 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 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 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 full size smart cards so you know 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 login, 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 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 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 GPShell which is a 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 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 say that to us? Oh no. Is it available anywhere? No no. And then eventually they offered us okay for $600 we'll send you this program that we didn't write and we don't own the copyright too. 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. So this 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'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 this. 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. Plus we had to provision 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 global platform. So what global platform is 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 so 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 Null showed that about 25 percent of SIM cards use have a crypto bug I guess you would call it where you can actually exploit to load stuff onto these cards. So basically the way that that worked is that 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. So if you don't know the right key you just send random junk and then you get back a signed error response. And since it's desk you can actually brute force this. And apparently he's able to do that with some rainbow tables and that's pretty cool. But so going back to global 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 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 that 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 a 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 APDU's 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 APDU called cat envelope. And cat envelope is basically a way to deliver to the SIM toolkit runtime some incoming message either an event it's it's typically an event either an incoming SMS or a menu selection or something else. Inside that you have an event for a 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 the APDU that actually gets delivered to global platform. And so this tiny little this tiny little packet ends up being huge when sent 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 you can use this exact mechanism to send arbitrary APDU to SIM cards. Through this 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 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 or knowing the private keys go see Carson Knowles talk. So once we reverse engineered how this actually worked we wrote this Python script that works on OS X Linux Windows. It just works everywhere. And it's kind of easy to use. To load a application on the SIM card all you have to do is just specify what interface you want PCS or serial and 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 toolkits fault and Java cards 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 AID is used for selection of that applet 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 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 this also supports such as updating the phone book. How these guys doing so far? 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. 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. So how do you know if this works? We have to do this shit all day. How do I become a goon? It's my question. So how do you know if this actually works? Well what? Oh this is your slide. Okay. I'll 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 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, you go to phone and a SIM applications item will appear. And on Android a SIM toolkit 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 Karl was saying that one of the worst parts of this was 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, you take out the SIM card, you 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 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 CIC 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 work, we tried this out and it worked 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 CIC project only provides this as patch files but we've gone through the trouble of building it. We have binaries for old 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. Alright 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 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 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 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. By the way 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. And so any app can do anything at once. But 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 botnet. Because these SIM cards can actually communicate with the network without the US getting involved. It talks directly to the baseband processor. So if it's able to bypass the authentication to load itself onto SIM cards it could just you know start propagating itself through the cell network. And the main 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. 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 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 SMS's 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 there's still widely widely used. 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 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 is doing a very very slow rollout over the next year or so. This is a 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. Another technology that uses is quite similar is the secure element found in many Android phones. This is often part of the NFC controller. It's similar 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 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, they're still pushed by these manufacturers to keep this technology relevant and to try to do new things. So it's not going away anytime soon. We've hopefully made it easy to get started. If you're interested in intrigue, and I hope you are, it's quite, it's quite, 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 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 mid-sized 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 for coming and I hope you will join us in hacking on SIM cards.