 SIM card technology from A to Z. And it's an in-depth introduction of SIM card technology that not a lot of people know much about. And our speaker, Harold LeForge, as he's better known, is the founder of the open source mobile communications project. He's also a Linux kernel hacker. He has a very long and impressive bio. And the Wikipedia page. Just means I'm old. So Harold, Velte, please give him a round of applause. SIM card technology from A to Z. All yours. Thanks a lot for the introduction. Yeah, as you can see on the title slide, I actually had to change the title slightly because I couldn't find a single acronym related to SIM cards that starts with a Z. So now it's from A to X, not from A to Z anymore, the SIM card introduction. So the SIM card technology from APDU to X-RES, which are two acronyms in the context of SIM cards, which we might get into or not. So what are we going to talk about in the next 45 or so minutes? What are the relevant specifications and specification bodies? What kind of interfaces and protocols relate to SIM cards? We're going to talk about the file system that exists in such SIM cards, as well as the evolution of SIM cards from 2G to 5G. So that's basically from what, 91 to 2018. We will talk about SIM toolkit over the air, a little bit about eSIMs as well, the embedded SIMs. Introduction about myself was already given. So yeah, people complained sometimes that my slides are full of text and I need more diagrams, so I tried to improve. So this is actually at one night, I thought, OK, let's actually try to create a dotty graph of all the specs and how they cross-reference each other. And this is what I've come up with. And this is only the SIM card relevant specs, not out of context other specs that they may refer to. So yes, it's an interesting graph. The arrangement was done automatically by dotty, so don't complain to me about that. Nevertheless, I will switch back to text and we will look at what kind of specifications there are in spec bodies. So most importantly, probably, about any kind of chip card technology. We have the ISO, the International Stabilization Organization, which has a series of specifications about what they call ICCs, which is integrated circuit cards. We also have the ITU, the International Telecommunications Union, which has a series of specs related to telecom charge cards. The title implies that this is things that came before SIM cards. So we're talking about the cards you put into pay phones and things like that in the 80s. There's, of course, the 3GBP. Oh, sorry. There's, of course, Etsy, the European Telecommunication Standardization Institute, which is the entity where GSM was originally specified. GSM being the first digital telephony system that used SIM cards, the best of my knowledge, at least. Not a historian, though. There's 3GBP, the third generation partnership project, which is where the GSM specs have been handed over to in the preparation of the 3G specification process, because Etsy is a European entity, and Chinese companies, for example, or Chinese government, cannot participate there, or Americans even, to the extent that European companies can do so. It was lifted to an international new group called the Third Generation Partnership Project. And they, of course, inherited all the SIM card related specifications. And then we have non-telecom standardization entities, such as the global platform card specification. That's global platform is a body that specifies lots of aspects around Java cards, specifically around applet management, installation, and so on, on Java cards, which brings us to the next entity, which is not really a standardization body, but it's a private company that used to be called Sun, and now it's part of Oracle, which defined the Java card API runtime and the virtual machine of Java cards. And last but not least, we have the GSM association, which is the vendor club of the operators that doesn't really have to do that much with SIM cards until the eSIM, where then suddenly the GSM A plays a big role in the related specs and technology. So talking about these standardization bodies, what is the SIM, actually? Well, the SIM is the subscriber identity module. I mean, probably anyone in here has one, likely more, or at least has had. It's quite ubiquitous. Every device with cellular connectivity during the last, whatever, 20 or so years has a SIM, whether it's an actual card or whether it's sold it in these days. And SIM card hacking has a tradition in the CCC since at least 1998. I'm not sure how many people remember. There was the Vodafone Germany SIM card cloning attack back then was in German. It was titled from Ditzweil Privat zu Ditzweil Pirat. And that was an attack that used weaknesses and brute forcing against the authentication mechanism to recover the secret key which is stored in the card. And then you could clone SIM cards back then. That was then fixed in subsequent technology generations. And also around that time, you can find on the FTP server of the CCC a SIM card simulator written in Turbo-C using a season card. I'm not sure how many people remember season cards. These were cards people used in the context of cracking satellite TV encryption. Yeah, so meanwhile, of course, the SIM technology stack has increased and the complexity has increased, like probably in any kind of technology. So let's recap basically from the beginning to today what SIM cards are and what they do in some degree of detail. If we start historically with SIM cards, actually, the predecessor to the SIM cards that we know is the chip card used in the CNETs, which is an analog telephony system that used to operate in Germany. There's actually an open source implementation these days as part of OsmoCom Analog. If you're interested in that, do check out Jolly at the vintage and retro computing area. And before 1988, they only had magnetic stripe cards. But in 1988, they introduced integrated circuit cards in this analog telephony system. And in GSM, it was a chip card from the beginning. The concept of the SIM card means you store the identity of the subscriber outside of the phone, which is very opposite to what happened in the CDMA world in the US around that time, where it was basically inside the phone itself. But having the identity separate, of course, enables all kinds of use cases that were relevant at that time. We will get to that to some extent. In addition to the identity and the identity in this context means a cryptographic identity, there are all kinds of network-related parameters that are stored in the SIM card. Some of those are static, meaning that they are provisioned or written by the operator into the card or, of course, by the SIM card manufacturer on behalf of the operator, but which are not writable by the user that affect access control classes, which means like, are you a normal user? Are you an emergency service user which needs higher priority to access the network? Things like that. And there are lots of dynamic parameters on the card. And dynamic means they get rewritten and changed and modified and updated all the time. That's, for example, the TIMSI, the temporary identity that gets allocated by the network every so often. Also, the current actual interface encryption key, like KC, and its successors in modern generation technology, so they get updated and written all the time by the phone. And some of the files are even updated and written by users, at least traditional or historically, like the phonebook and the SMS that are stored on the card. It was originally specified as a full credit card size card. And it was intended to be used in radios, in rental cars, or company-shared cards. So basically, when you leave the car, you would remove your SIM card, the full-size credit card size card, and somebody else would put their card in. And allegedly, they even were, I think, public GSM phones installed in German trains, where you could plug in a SIM card or something like that. I personally haven't witnessed that, since I was ignorant at that time, apparently, of that fact. So let's get to the mother of all smart card specs, which is in German, Dean in ISO IHC 7816, or short, just ISO 7816. And maybe an anecdote, how these specs come around. So there's the ISO that specifies a certain spec. It gets an ISO number. And then EN, the European norm, whatever, body comes around and says, oh, we will elevate this international spec into a European standard. And they put an EN in front. And then Dean, the German standard body, comes around and says, oh, we will elevate this European norm into a German norm. And we will put a Dean in front. So now in Germany, we have Dean in ISO IHC 7816. And if you get the actual copy from Dean, it's quite funny. I didn't don't have it here. But actually, you get a one-page additional paper on top, which translates the key technical phrases from English to German. And that's the added value that you get from it become, sorry, I mean, it's just hilarious. The entire spec is in English. But then there's this key translated terms. So you know that file means datai, for example. That's extremely beneficial to the reader of such specifications. Anyway, so the title is Integrated Circuit Cards with Contacts. I wonder, well, OK, there are contact less now, but at least back then, certainly, they didn't exist. And it has 15 parts by now. The most relevant parts are 1 through 4, starting from the physical characteristics, going through the mechanical dimensions and the location of the contacts, of course. It's a separate part of the spec. And each of those specs are sold as a separate document, of course. So the physical size you pay. And if you want to know location of the contacts, you have to pay to get another spec. Then there's part 3, which covers the electronic signals and the transmission protocols. We will look at that in some detail. And then there's part 4, which is the inter-industry commands for interchange, which I find very interesting. And I always thought they should have made the international inter-industry commands for interworking information interchange. But apparently, they didn't come up with that. And of course, this all predates the internet, so there's no internet in there. Yeah, the next relevant spec is GSM technical specification 11.11, very easy to memorize that number, which is the specification of the subscriber identity module dash mobile equipment interface. So in GSM, there is what's called a mobile station, which is your phone. And it's comprised of two parts, the mobile equipment, which is the hardware and the SIM, which is the SIM next to the mobile equipment. And interestingly, it doesn't just refer to these ISO specs that I mentioned before, but it actually repeats more or less carbon copies, large portions of these ISO specs with some amendments or corrections or extensions. And again, it gives you the location of the contacts and the mechanical size of the card and the electronic signals and the transmission protocols and so on. But beyond these ISO standards, it also actually specifies what makes the SIM a SIM and not any other contact card, which is the information model, the file system on the card, and the commands and protocols that you use on this card. And last, with typo, as usual on my slides, but not least, of course, how to execute the GSM algorithm to perform cryptographic authentication. The physical smart card interface is interesting. I mean, if you've worked with hardware or electronics or serial interfaces, I think it's rather exotic. And exotics always means interesting. So we have four relevant pins. We have a supply voltage, not surprisingly. It can be 5, 3, or 1.8 volts. Interesting, it's not 3.3 volts. It's 3.0 volts nominal. Not sure why, but anyway, that's how it is. We have a clock line that provides a clock signal, which initially needs to be between 1 and 5 megahertz. So the phone provides power and clock. We have a reset line, which also makes sense. You want to reset the card. And then we have one IO line for bi-directional serial communication. So you have Rx and Tx sharing one line. And there is some nice diagrams about how exactly the sequencing happens when you power it up. Nothing really surprising. There's an activation sequence. And after the card is activated, the card will unilaterally send what's called an ATR, the answer to reset. And that's just a series of bytes, which gives some information about the card capabilities, what protocols, what voltages, what clock rates, beyond these initial activation ones supported. Now, after we've powered up the card, we have the bit transmission level. And it's actually very much like a normal UART. If you ever looked at RS232 or another UART serial port, rather simple start bytes, stop byte, parity, serial bit transmission, what's a bit interesting is that we have a clock. And the board rate is divided from that clock. But it's still an asynchronous transmission. So there is no phase relationship between the clock signal and the board rate that the data uses, which lots of people get wrong, particularly lots of authors of AdMail microcontroller data sheets, which claim that it's a synchronous communication, which it is not. Yeah, so the direction changes every so often to have acknowledgments back and forth and to exchange data in both directions. And interestingly, a lot of the timings are not specified very well. But I guess nobody cares about that other than if you want to implement a card reader, which I happen to have gone through this year. Smart card communication. After we are able to transmit bytes between the card and the reader, we have something called APDUs, the application protocol data unit specified as per that ISO 7816-4. That's the inter-industry commands for interchange. And an APDU consists of a couple of bytes. There's a class byte that just specifies the class of command. There's an instruction byte which specifies the specific instruction, like read a file, write a file. We have some parameter bytes whose meaning is relevant or specific to the instruction. Then we have a length of a command and command data. We have an expected response length, response data, and last but not least, a so-called status word. And the status word, basically the card tells whether the execution was successful or whether there was some error and what kind of error there was and things like that. The APDUs are then split into a lower layer transport protocol, which are called TPDUs. There are two different commonly used protocols and two specific ones that are used in the context of SIM cards or are specified in the context of SIM cards. There's one called t equals 0, which is most commonly used with SIM cards. And actually, I've never seen anything else, but t equals 0 used. But t equals 1 is another protocol, which, according to the specs, every phone needs to implement. And the card can choose if it does t equals 0 or t equals 1. As again, I've never seen a card that does t equals 1, or at least that does only t equals 1, but the specs would allow that. t equals 1 is more used in banking and crypto smart cards. The difference mainly is t equals 1 is a block-oriented transfer, and t equals 0 is more a byte-oriented transfer. t equals 1 has the advantage that it has CRC and checks summing, so you get more protection against transmission errors, which you don't have in t equals 0. So the APDU gets mapped to TPDUs. Details, I'll skip here. And this is just some examples, so you get an idea how this looks like. So we have A0, A4, 0, 0, 0, 0, 0, 2, 3, F, 0, 0. The A0 here is the class byte, and A0 is SIM card class. A4 is a SELECT file. So you're selecting a certain file on which you want to operate. Two parameter bytes are 0. 0, 2 is the length of the command, and then you have two bytes of that length, 3 F, 0, 0, which is basically your slash, your root directory. You want to change to the root directory of the file system. It's basically what that command says. And one hypothetical response is just a status word, 9 0, 0, 0, which means success. Selecting a file. So we have a file system on the card. Most smart cards do that. It's not a file system in the context like you have a USB drive that you can mount where you just have a block abstraction or something. But the smart card file system itself runs inside the card, and you just talk to the file system and give it instructions. So if you want to find an abstraction in PC technology, it's more like MTP or PTP over USB, where you don't have a block device, but you talk to another processor which manages a file system, and you can instruct. It's like a remote file system access. You have some similarities to normal file systems. I mean, there's a master file which corresponds to a root directory in PC file systems. You have so-called dedicated files, which are subdirectories. And you have so-called elementary files, which are actual data-containing files as we know them. Beyond that, there are lots of specifics that we don't find in PC file systems, where operating system file systems, we have what's called a transparent EF. That's an opaque stream of data like your normal binary file on any random operating system. But then we have concepts like a linear fixed EF, which contains fixed size records. And you can seek, basically, get me the 15th record in that file. And the file has a record size of whatever, 24 bytes, for example. And then you have something called a cyclic EF, where they have a ring buffer of records. And you have incrementable files, which contain monotonically incrementing counters and things that were apparently important for charging or things like that. Each file has access control conditions that define who can read and or modify, and or, well, there's no delete, but there's something called invalidate the file, and who is basically expressed in context of which PIN was used to authenticate that entity which performs the operation. So as a user, you have a PIN 1. And some people will remember you also have a PIN 2 that probably nobody's used since the 90s. And the operator has something called an ADM PIN. Administrative PIN, which gives better or higher privileges in terms of file system permissions on those files. The kind of commands we see, well, select file from the example. We have a read record, update record. I guess I don't need to say anything about that. Similarly, read binary, update binary. And then we have commands like CHV commands, where CHV is the card holder verification, which is Etsy language for a PIN. Not sure why they don't call it PIN. So they change a PIN, a disabled PIN, or enable PIN commands, which is actually what your phone performs. If, let's say, you disable the PIN or you change the PIN, then exactly those commands are issued to the card. And last but not least, run GSM algorithm. Remember, this is still the 2G-only sim. We haven't yet gone beyond 2G yet at this point in the slides. And that's actually not that many more. That's really it. Now let's look at the file system hierarchy. We have the MF, the root file system. And then we have something called DF telecom. And the hex numbers in parentheses are the identifiers that are actually used on the protocol level. We have something called DF GSM, which is the GSM directory containing GSM-related parameters. And the ICC ID, where ICC ID is the card unique identifier. That's stored on the card. And if you expand that into more details, you get these kind of graphs. And this is what actually taken from one of the specs. And you see there's also an iridium directory or whatever that one was. A global star directory. And all kinds of people operating different telephony system have basically their own directories in that scheme. But on GSM, we find those two mainly, maybe some subdirectories. So when 3G came around, something happened. As I said, the specifications were shifted from HC to 3G VP. But of course, chip cards in the context of telecom have use cases outside of cellular telephony. So actually, the specs were split in that area. So there's something new called the UICC, the universal integrated circuit card, because the previous one was not universal, apparently. And that part of the specs remained with Etsy and continues to be developed. And there is the USIM application on top of the UICC, which is what specifies the 3G VP relevant part. And that gets implemented in something called an ADF, an application-dedicated file, ADF USIM. And ADF, you can also select or enter using a select command similar to a normal DF. The difference, mainly, is that the identifiers are much longer in other details. But from a user point of view, that's how it looks like. So we have a split of the core universal ICC and on top and USIM application. And if you have a SIM card that can be used with 2G and with 3G, then you basically have the classic SIM card. And in addition, you have a USIM application on the card. And actually, there are some cards that only work with 3G or later technology and don't have 2G mode, because the operator doesn't have a 2G network. So you only have a USIM application and you don't have the classic SIM anymore on the card. When 4G LTE came around, actually, there was no strict requirement to change anything in the SIM card. And you can just use a normal USIM, a UMTS SIM, a 3G card on LTE networks. It's the same authentication and key agreement mechanism. They have added some additional files that are completely optional. They're mostly like optimizing some bits. And some optional new IMS application. IMS is the IP multimedia system, which is 3GPP language for voice over IP or Volte. So IMS is the IP multimedia system, which is what is used to implement Volte, where Volte is not a specification term, but more a marketing term. And optionally, on the SIM card, you can have an ISIM application which stores parameters relevant to the IP multimedia system, such as SIP user identities and SIP servers and things like that. But if that ISIM application doesn't exist, there is a fallback mechanism by which the identifiers are computed based on the IMZ and so on and so on. So it's not really necessary to have a specific 4G SIM, but it's possible to have that. Once we go to 5G, 5G actually reuses the existing 3G and 4G use SIM cards. Again, some new optional files have been introduced. And there is one feature which I guess everyone in here wants to have, which would require a new SIM card or a changed SIM card, which is that the SUCI, the subscriber concealed identifier, can be computed inside the SIM card or by the phone. And if it's computed inside the SIM card, then the SIM, of course, has to have support for doing that computation. And that is something that needs explicit SIM card support. In absence of that, everything else you can use an existing 4G SIM card even on 5G networks. Nothing really changed there fundamentally. Now, looking at the cards more on the physical side and from the hardware, and we will look at the software, the operating systems, and so on, and the various things you can do with SIM cards later on. We have, of course, a processor core. There are many different vendors and architectures. Traditionally, lots of AD51 derivatives inside smart cards. These days, we also actually find a lot of scheduled arm cores, quite often, so-called SC cores. There's an SC000 and an SC100 and an SC300. And SC is for secure core. So it's not a normal CoreTXM core or something like that, but it's a secure core. And it's so secure that ARM doesn't even disclose what is secure about it other than that it is secure. So the documentation, for sure, is securely kept away from anyone who would want to read it. So for these chips, the smart card chips used in SIM cards or generally smart card chips themselves, often you cannot even find a simple one-page data sheet which tells you the main features. Even that is already under NDA. You have built in RAM and built in ROM, at least a bootloader normally, but possibly also the OS or parts of the OS, but that is increasingly uncommon. So modern cards, most of them only have flash and the entire operating system is in flash so you can update everything. And then applications on top of that. And we will look at applications later when we talk about the software. And unfortunately, contrary to the crypto smart cards where it's possible to have higher prices and therefore have rather expensive products, SIM cards are mostly selected purely by cost these days due to the prepaid boom. I mean, it was different when GSM was introduced. If every subscriber has to get a subscription and there's going to be hundreds of euros or marks or whatever in revenue, then you can invest a lot of money in a SIM card, but prepaid cards that get thrown away on a daily basis, you can only pay cents for the card and then you need to pay another couple of cents for the Java card, for the Java VM patent royalties and so on and so on, but basically you cannot afford to pay money for SIM cards anymore. So that also explains why a lot of SIM cards today, even though it's technically available, they don't have hardware crypto, but they actually implement it in software because it's cheaper. And then of course, yeah, well, you have time of execution things and whatnot. So in terms of software, you have a card operating system. Cards that don't have an operating system are memory cards, which are not sufficient for SIM card use cases. In the crypto smart card area, the operating systems are typically well known and documented to some part at least. In SIM cards, it's slightly different. So almost nobody ever mentions what kind of operating system is on the SIM card. Even the SIM card vendors, it's not something they would put on their marketing or on their home page or something. What exactly kind of operating systems are on there. The SIM card operating system also from the cellular network point of view is an implementation detail because all the relevant parts are specified standardized interfaces. And what operating system people use on their card when it's operator's choice, it doesn't really matter from that point of view. In early SIM cards, I presume they were rather monolithic. So you didn't really have a separation between operating system and SIM application. Today, the software has become more modular. We have this abstraction between the operating system and applications. And traditionally, even when that separation already existed, the operating system was very hardware-dependent, non-portable, and the applications were very OS-dependent and non-portable. And that has changed a bit due to the introduction of Java cards into the SIM card area, which is not required. There's no requirement anywhere that the SIM card must be a Java card. But in practice, most SIM cards are Java cards because they have certain at least perceived advantages and other norm by now. The Java cards themselves have been independently developed of SIM cards. Of course, Java is a sun technology. So sun is behind that. And the first actual cards were produced in 96, so much later than SIM cards came out by Schlümberg, which is now part of Jemalto. And yeah, we have redundant lines in this presentation. So the Java cards, most of them implement the global platform specifications, which then specify when the independent management of the cards and the applications on it. And the Java that you use to write such cards don't ever think it is real Java. I mean, if you show that to any Java developer, he will probably disappear very quickly. So you have a very weird constrained subset of Java with a special on-card virtual machine, which is not a normal virtual machine. You have a runtime environment. That's not the normal runtime environment. You have a special binary format, which is not a JAR file. And the idea is that you have portability of card applications, which makes sense, of course. But one could have done that with whatever other standards as well wouldn't necessarily need a virtual machine for that. Yeah, as I said, there's no functional requirement. That a SIM card must be a Java card. But in reality, that's the case. I think the portability is the driver here. So if an operator develops some application that runs on a SIM card, every year or so, they do a new tender or they have a new SIM card supplier or something like that. They want to run their application on the current and the future and the next future SIM card and not rewrite all of that from scratch or have that rewritten from scratch all the time. And interestingly, both 3GPP and Etsy specify Java APIs and Java packages, which are specifically available on Java cards that also are SIM cards. So you basically have SIM card specs and you have Java card specs. And if you have both of them together, you also have SIM card Java API specs for what kind of additional APIs applications on the card can use in order to affect SIM relevant aspects of the card. Which brings us to one of the strange historic developments called SIM toolkit or later card application toolkit, which is sort of an ability to offer applications with UI and menu on the phone. I mean, the card, of course, doesn't have any user interface, but the card can sort of request like show a menu and offer multiple choices and things like that. Some people will have seen it on some phones. You have this SIM toolkit menu somewhere. And I mean, I think in Germany never really took off much in terms of actual applications. I mean, you could probably subscribe to some very expensive premium SMS services if you were really bored. But in other regions, this has been very successful and very, how can I say that, a real impact on society. Kenya is always, I think, the prime example for that, where MPSA, the mobile payment system, implemented at least initially based around card application toolkit applications basically overtook the banking sector. At some point, everybody did their wire transfers. That way, even people who didn't even have a bank account, and it basically replaced or substituted large amounts of the everyday banking needs of people. So there are exceptions. Some additional instructions that we have in terms of APDUs, details I'll not look into these. The next step after SIM toolkit is the so-called proactive SIM. If we look at the SIM card communication as it is specified or smart card communication in general, it's always the reader in this context, the phone that sort of sends an instruction to the card and the card responds. So the card is always the slave in the communication, and it doesn't have any possibility to trigger something by itself. And that was sort of worked around by the proactive SIM specifications where a command or a request from the card is piggybacked into responses to the commands from the phone to the card. And then basically, the SIM card can request the phone to pull the card every so often. So the phone can ask, well, do you have a new command for me now? And the card can say yes or no. And this way, they work around this restriction. And it's not only polling that can be requested, but it can be event notifications. And event notifications can be loss of network coverage, registration to a new cell, opening of a web browser. And like, are you making a mobile-originated call? Are you sending an SMS, whatnot? So all these kind of events can be sent to the SIM card so that the SIM card can do whatever with it. I think there are not many useful applications beyond steering of roaming or roaming control by basically depending on where you register and what kind of cells you have. And even the measurement reports on what is the signal strength that can be fed into the SIM card, which then can basically decide what to do. But yeah, I think it's all rather exotic and very few relevant or good use cases of this. The next step is over-the-air technology, OTA, which is the ability for the operator to transparently communicate with the SIM card in the field. The traditional non-OTA-capable SIM card, the operator of rights, or the SIM card manufacturer of rights at manufacturing time, at so-called personalization time of the card. And then it's with the subscriber. And if the operator ever wants to fix something or change something, then they have to send a new plastic card. With over-the-air, they can be updated. It's based on proactive SIM technology. And there are many different, by now, many different communication channels. How some backend system at the operator can interact with a card inside the phone of the subscriber. The classic channel is SMSPP, which is the SMS, as you know. Just officially, it's called SMS Point to Point. It's also possible over SMSCB, the Cell Broadcast SMS, which I find very interesting, bulk updates to SIM cards via Cell Broadcast, which also would mean that they all have a shared key for authenticating these updates. But well, it's also specified for USSD from release seven onwards of the specs. And then there's something new at that point called BIP, the Bearer Independent Protocol that works over circuit switch data and GPRS, some spec numbers, if anyone is interested. And now, since release nine, that means sort of, since LTE is around, also over HTTPS. And I'll get to that in a couple of separate slides. There's actually a TLS implementation in SIM cards these days, believe it or not. So the cryptographic security mechanisms that are specified, but of course, the detailed use is up to the operator. So the operator may choose whether or not to use measured authentication, or whether or not to use encryption, or whether or not to use counters for replay protection. And this is basically one area where a lot of the security research and the vulnerabilities published in the last whatever decade or so have been happening, that cards were not properly configured, or they had implementation weaknesses, or you had sort of oracles that you could query when interacting with those cards as a attacker. One of the use cases over the air is RFM. It's not RTFM, it's RFM, Remote File Management, was introduced in release six. And the number of typos is embarrassing. Common use case over the air, it allows you to read or update files in the file system remotely. And that you can use, for example, for the preferred or forbidden roaming operator list. That's a very legitimate use case for that. There's also an ancient example that I always like. I think Vodafone Netherlands once advertised that the operator can take a backup of your phone book on the SIM card. Yeah, I think it's an early manifestation of cloud computing before it even existed. In any case, yeah, certainly a feature that everyone in here would like to have. Of course, it's irrelevant by now because nobody has contacts on SIM cards anymore. The next is RAM, which is not random access memory. No, it's Remote Application Management, was also introduced in the same release with the same typo. And it allows installation and or removal of applications on the card. And applications in terms of Java card then means Java cardlets. For example, you could update or install new multi-IMSI applications, which is one very creative way of using SIM cards in more recent years, or new SIM toolkit applications, for example. So a multi-IMSI application, in case somebody hasn't heard of that yet, is basically a SIM card that changes its IMSI depending on where you currently roam in order to do sort of least cost roaming agreement for the operator. Because if he uses his real own IMSI, then maybe the roaming costs would be more extensive than he uses some kind of borrowed IMSI from another operator that then gets provisioned there, which has a better roaming agreement. And it works around ridiculous roaming charges, at least between the operators, of course, not towards the user. And now we get to the sort of premium feature of modern SIM cards, sorry, where, of course, well, SMS. Yes, you can still do SMS over LTE, but it's sort of this added-on clutch. USSD, I think, doesn't exist anymore because of the circuit-switched feature. So you need some kind of new transport channel of how to talk to the SIM card. And in release nine, they came up with something called Over the Air Over HTTPS, which is specified in global platform 2.2 Amendment B. And you have to get that specific amendment as a separate document. It's at least free of charge. And actually, it uses HTTP. OK, so nice and good. And then it uses something PSK TLS that I've never heard of before, so pre-shared keys with TLS. I mean, I'm not a TLS expert, as you can probably guess. But I don't think anyone ever, like, with normal, like, browsers and so on would want to use pre-shared keys. But it exists in the specs, and there's several different cipher modes that I've listed here, which are permitted for Over the Air Over HTTPS. Which of those, or which subset to use, is, of course, up to the operator, because it's his SIM card talking to his server so they can do whatever they want there. The interesting part is that the IP and the TCP is terminated in the phone. And then whatever is inside the TCP stream gets passed to the card, which implements the TLS and the HTTP inside. And then inside HTTP, you actually have hex string representations of the APDUs that the card normally processes. So you have this very interesting stack of different technologies. And if you look at how exactly they use HTTP, you ask yourself, why did they bother with HTTP in the first place if they modified it beyond recognition? But we'll see. So the way how this is implemented, interestingly, is that the card implements an HTTP client that performs HTTP post. And the APD, so your card, somehow, by some external mechanism, gets triggered. Oh, you must connect to your management server now, because the management server wants something from you. And then the card does an HTTP post over TLS with pre-shared keys to the management server. And then in the post response, there is a hex encoded APDU for the card to be executed by the card. And then you have tons of additional HTTP headers. I'm not going to explain. Well, the CRLF is just a copy and paste error. But yeah, you see there is all kinds of X admin headers. And it will completely not work with normal HTTP. So why use HTTP in a context I don't really know. Yeah, I thought I had an example here, but I didn't put it. I thought it's too much detail. But in the end, if you look at this, yeah, I mean, you need to write your own HTTP server or heavily modify it anyway. And the card, well, yeah. OK, but you have HTTP in there. Well, OK. Another technology, sort of random. I didn't really know where to put it in terms of ordering is this SAT technology, which is something really strange that's specified outside all of these specification bodies that I mentioned before. I'm just mentioning it because it's another vector that has more recently been exploited, another vulnerability, where actually, let's say, you don't want to run. You don't want to write a Java application to run on the card, but you still want to use sim toolkit. So your card, most likely, inside a Java VM, implements a VM for another bytecode, which is this SAT bytecode, which gets basically pushed from the server into the card. So the card can then instruct your phone to display some menu to you. It's like, hmm, OK. Very exciting technology. I'm sure there was a use case for it at some point. I haven't really figured it out. So there is something called an SAT browser, which runs inside the card. As I said, most likely, that browser is implemented in Java, running inside the Java VM. It's not a web browser, of course. It's just called a browser. And it parses this binary format, which then creates some sim toolkit menus or whatever. So yeah, I haven't really looked into detail. It's too strange even to look at it. Last but not least, we have something called the eSIM, which many people may know as a particularly dominant in the Apple universe, where the SIM card is no longer a replaceable or exchangeable plastic card with contacts, but it's actually soldered into the device. This package form factor is called MFF2, the machine form factor. Not sure why it's 2. I've never seen a 1 before. And it's a very small, like, 8-pin package, SMD package, that gets soldered on a circuit board. And of course, at that point, we have to have some mechanism by which the actual profile, meaning the user identity, the keys, and all the configuration parameters and so on, can be updated or replaced remotely. And that, in a way, that will work between different operators which are competing in the industry and which don't really want to replace those profiles, at least not inherently. And this is why this is managed by the GSMA as an umbrella entity of all the operators. And it specifies an amazing number of acronyms. And trust me if I say that, it is an amazing number of acronyms on how the cryptography and how the different entities and how the different interfaces work and all the different roles and the parties and each implementation and each party needs to be certified and approved and so on and so on. And in the end, you have a system by which, after a letter of approval between operators, a new identity from a new operator can be downloaded in the card in a cryptographically secure way, so at least is the intent of the specification. I'm not the person to judge on that and replace the profile. But it's not that you as the owner of the device can do that, but it's just all the operators that are part of the club and are approved and certified by GSMA can actually add and or remove profiles and thus facilitate the transition from operator A to operator B in those cards. They don't only exist in this solder form factor. You can also actually buy plastic cards that allow that. It's mostly used in IoT devices, which I still call machine to machine. The old marketing term for that, so some random cellular interconnected device that you want to remotely update. And as a final slide, the CC event SIM cards that you use the cellular networks, they are Java SIM and USIM cards. They support over the air, not the random update, but the remote application management, the remote file management, at least via SMSPP. Haven't tested anything else. For sure, do not support HTTPS yet. And if you're interested in playing with any of that and writing your own Java applets, there's even a Hello World one around for several years that you can use as a starting point. You can get the keys for your specific card from the GSM team. And then you can play with all of this in a way that normally only the operator can do with the card. Some hyperlinks, which are actual hyperlinks on those slides. So you have to look at the PDF to see them. And that brings me to the last slide. I'm very happy to see questions. Thanks. Thank you. Thank you so much. Actually, talks like this one is one of the main reasons I go to Congress, because sometimes I just take a dive into a topic I know nothing about. And it's presented by a person with literally decades of experience in the field. So it's amazing. And we have time for questions, so keep them coming. And the first one is microphone number four. What you say makes me want to have a firewall between my phone and my SIM card. Is there a firewall? Not to my knowledge, really. I mean, there are some vendors of specifically secure telephones that say, well, we have a firewall built in, not sure to what extent and what detail, but not as a separate product or a separate device. At some time, people developed so-called interposer SIM cards, which you can slide between the SIM card and the phone. But that doesn't really work with nano SIM cards and so on anymore. And those interposes were mostly used to avoid SIM locking and so on. But of course, with such a device, you could, of course, implement a firewall. Keep in mind that almost all of the communication, I mean, the OTA may be encrypted, but all of the communication between the phone and the card is completely unauthenticated and unencrypted. So you can actually intercept and modify that as much as you want. And there's actually a project I forgot to mention in more detail. There's an Osmo-com project called SIMtrace, which is a device that you can actually put as a man in the middle to trace the communication between card and phone. Thank you. Mike Wan. Could you please elaborate a little bit about the SIM checker attack? Because the telephone provider said it's only possible if you have the SAT browser on the SIM card. And most claims they don't have. So do you have a feeling how many of the SIM cards have a SAT browser and which are attackable or which other applications are attackable by the SIM checker attack? I'm not involved in those attacks. I cannot really comment on that in detail. But I know there is a tool available, an open source tool that is made available by SR Labs, which allows you to test cards. So if you want to check different cards, you can use that SIM tester. I think it's linked from the slide here. Yeah, the SR Labs SIM tester. It's a Java application. I don't have any figures or knowledge about this in terms of the figures you're asking for. Sorry. Thank you. Let's take a question from the internet next. Hi, internet people. There was a question. Can the eSIM be seen as back to the rules, especially compared to what the US market had in the early time? Well, that refers to the situation that the identity is hardwired into the phone and not replaceable. And I think no, not really, because it can be replaced and it can be replaced by any of the operate, like the normal commercial operators. Of course, it means you cannot use such a device in, let's say, a private GSM network or in a campus network for 5G, which apparently everybody needs these days now. So there are limitations for such use cases. But in terms of the normal phones switching between operator A and operator B, that's exactly what the system is trying to solve. It's just that if you're not part of the club, you've lost. Thank you. The person behind Mike 5 has a very nice hat, and we're all about fashion here. So the next question goes to you. Nobody told me that. This is a cow's mentor's hat, not a Google one. And my question was just answered, I think, because I wanted to know what prevents Pocke from providing an eSIM. A profile for an eSIM, yes. That's exactly the problem that it needs, like in order to install it, it needs to be approved and signed and so on and so on, and you need to be part of that GSMA process. So first of all, you would have to technically implement all of that, which is doable and all the specs are public. But then you need to get it certified, which is maybe less doable. And then finally, since you're not a GSMA member and not an operator, you cannot become a GSMA member and you don't have the funds for it anyway, so that is certainly not going to work. But the Pocke could provide an actual physical eSIM chip. So if somebody wants to do hot air rework, that's easy. And you can buy them just like other SIM cards, and then you have your identity inside. But of course, that doesn't really solve your problem, I suppose. Thank you. No more people in cool hats, so we'll keep picking at random. Mike Seven, please. Thanks for the amazing talk. I have a question about the flash file system on the cards. I've already worked with the cards on the file system level. And for some files, you need to specify these. You need to do like an authentication Tango provides a CHV, like the pin one. And then you only have access to some of the files. And since cheap flash is built into those devices, my question is whether there are cheap hardware or software tricks to access the files or modify the files, which are usually locked behind the pin. Not that I'm aware of, and if I would say they are rather specific to the given OS or whatever on the cards, and there's so many out there. So I think it's unlikely. In terms of ride cycles, you can typically buy between 100,000 and 500,000 ride cycle flash in SIM card chips. That's sort of what the industry sells. But then, of course, you have all kinds of ware leveling, and then there are algorithms. And SIM card operating systems even go as far as to like, you can specify which files are more like the update frequency. So it will use different algorithms for managing the flash ware. But an interesting anecdote for that, if we have the minute. I was involved in OpenMoco. Some people may remember that it was an open source smartphone in 2007. And there, actually, we had a bug in the baseband, which would constantly keep rewriting some files on the flash of the SIM card. And actually, we had some early adopters, users, where the SIM cards got broken, basically, by constantly hammering them with write access. So yeah, but nothing that I know about any kind of access class bypass or something like that. Thank you. Microphone 6, which I often neglect because the lights are blinding me when I look that way. Thanks for the helpful talk. I have a two-fold question. So if I understand correctly your talk, does it impossible to know the code that's running on the SIM right? So this two-fold question is about going further. Is there something better than the specs to understand more concretely those protocols? And is there any way to dump the code that's running on the SIMs? In terms of documentation beyond the specs, there is one document that I always like very much to recommend, which is also leaked here. It's the so-called SIM Alliance Stepping Stones. No idea why it's called that way, but that's how it's called. There's a hyperlink, so if you work on the slides, you can download it. That's a rather nice overview document about all the different specs and how it ties together. So I can recommend that. And in terms of tools to dump the code on the SIM card, I mean, yes, of course, tools exist, but those tools are highly specific to the given smart card operating system and or chip. And I'm not aware of any such tools ever having leaked. I mean, I get such tools for the cards that in the company that I work with. But yeah, of course, the SIM cards out in the field should be locked down from such tools. And they are highly specific to the given OS and SIM. OK. Thank you. So maybe one addition to that. It's normally made in a way that basically if you want to sort of reset the card or something, so there's always sort of once the card is in the operational life cycle state, which is when you use it normally, if you ever want to bypass some restriction or you want to sort of do something that is not permitted by the permissions anymore, you have to sort of recycle the card and get it back into the so-called personalization life cycle state. And most often that is done with a complete wipe, at least, of the file system or with a complete wipe of the operating system. So you back to the bootloader of the card and then you can basically start to recreate the card. But it's typically implemented in a way that it always is together with an erase. So they tried at least to make it safe. Oh, well, there's a question there, but not at the microphone. Oh, there is a microphone. Oh, sorry. But yeah, your job. Yeah, I think the person behind Mic 4 has been standing there for ages. You mentioned that the card can instruct the phone to open a website, but I've never seen this. And I've seen use cases where I think it would be useful to do this. So is this not supported in most OSs or why? It's a good question, actually. If you read all those specs, especially these proactive specs and so on, I always have the impression, OK, it's all very interesting, but I've never seen anything like that anywhere. So I completely agree with you. Whether or not it's supported by the phones is a good question. And I think without trying, there's no way to know. So you would actually have to write a small, like send the Hello World app to do that and do testing with various phones. I would fear that since it's a feature that's specified but rarely used, a lot of devices will not support it or not support it properly because it's never tested because nobody's ever asked about testing it. But that's just my guess. Thank you. Mike One. OK, hello. My question is, when you have an eSIM and you want provisioning it, could it be done with tier 069 or something similar? No, there's a completely different set of protocols that are used for that. And that relates to this global platform, 2.2 NXP. I think it was. Yeah, I don't find it right now. But there's this spec, and that specifies all the different interfaces and protocols that are used between the elements. And it's completely different. I think also the requirements are very different because you have these multiple stakeholders. So you have the original card issuer, the original operator, then you have other operators. And it's not like a single entity that just wants to provision its devices. But it's sort of a multi-stakeholder approach where you want to make sure that even in a competition between operators, still this is possible and that people put trust in the system that even if the original issuing operator doesn't like the other operator, it still will work. And it will even work in 10 years from now or something when it's in the field. So I think the requirements are different. Thank you. That was the last question of the last talk of the day. Luckily, not the last day. Not the last day, the first day. So there's three more days ahead of us. Thank you.