1 00:00:19,280 --> 00:00:26,450 Herald: So our next talk is "SIM card technology from A to Z" and it's an in- 2 00:00:26,450 --> 00:00:34,810 depth introduction of SIM card technology that not a lot of people know much about. 3 00:00:34,810 --> 00:00:44,120 And our speaker, Harold, LeForge, as he's better known, is the founder of the Open 4 00:00:44,120 --> 00:00:49,790 Source Mobile Communications Project. He is also a Linux kernel hacker. He has a 5 00:00:49,790 --> 00:00:53,850 very long and impressive bio; and a Wikipedia page. 6 00:00:53,850 --> 00:00:58,990 Harald (speaker): just means I'm old. Herald: So Harald Welte, please give him a 7 00:00:58,990 --> 00:01:03,600 round of applause. *Applause* 8 00:01:03,600 --> 00:01:13,060 Herald: All yours. Harald (speaker): Thanks a lot for the 9 00:01:13,060 --> 00:01:19,350 introduction. As you can see on the title slide, I actually had to change the title 10 00:01:19,350 --> 00:01:23,170 slightly, because I couldn't find a single acronym related to SIM cards that starts 11 00:01:23,170 --> 00:01:27,689 with z, so now it's from a to x, not from a to z anymore - the SIM card 12 00:01:27,689 --> 00:01:32,280 introduction. So the SIM card technology from A(PDU) to X(RES) which are two 13 00:01:32,280 --> 00:01:38,659 acronyms in the context of SIM cards which we might get into or not. So, what are we 14 00:01:38,659 --> 00:01:44,390 going to talk about in the next 45 or so minutes? What are the relevant 15 00:01:44,390 --> 00:01:49,070 specifications and specification bodies? What kind of interfaces and protocols 16 00:01:49,070 --> 00:01:53,979 relate to SIM cards? We're going to talk about the filesystem that exists in such 17 00:01:53,979 --> 00:02:00,810 SIM cards, as well as the evolution of SIM cards from 2G to 5G. So that's basically 18 00:02:00,810 --> 00:02:10,900 from what, 91 to 19, er 2018. We will talk about SIM Toolkit, Over The Air, a little 19 00:02:10,900 --> 00:02:16,810 about about how to eSIMS as well, the embedded SIMs. Introduction about myself 20 00:02:16,810 --> 00:02:23,900 was already given. So, yeah, people complained sometimes that my slides are 21 00:02:23,900 --> 00:02:27,670 full of text and I need more diagrams. So I tried to improve. 22 00:02:27,670 --> 00:02:33,450 *laughter from the audience* *Harald laughs* 23 00:02:33,450 --> 00:02:38,810 *Applause* Harald: So this is actually, at one night 24 00:02:38,810 --> 00:02:43,010 I thought, OK, let's actually try to create a DOTTY graph of all the specs and 25 00:02:43,010 --> 00:02:46,950 how they cross reference each other. And this is what I've come up with and this is 26 00:02:46,950 --> 00:02:51,390 only the SIM card relevant specs, not out of context, other specs that they may 27 00:02:51,390 --> 00:02:57,730 refer to. So, yes, it's an interesting graph. The arrangement was done 28 00:02:57,730 --> 00:03:03,240 automatically by DOTTY. So don't complain to me about that. Yeah. 29 00:03:03,240 --> 00:03:09,060 Nevertheless, I will switch back to text and we will look at what kind of 30 00:03:09,060 --> 00:03:15,100 specifications there are and spec bodies. So. Most importantly, probably about any 31 00:03:15,100 --> 00:03:20,010 kind of chip card technology. We have the ISO, the International Standardization 32 00:03:20,010 --> 00:03:26,310 Organization, which has a series of specifications about what they call ICCs, 33 00:03:26,310 --> 00:03:31,771 which is integrated circuit cards. We also have the ITU, the International 34 00:03:31,771 --> 00:03:36,370 Telecommunication Union, which has a series of specs related to telecom charge 35 00:03:36,370 --> 00:03:42,160 cards. The title implies, that this is things that came before SIM cards. So we 36 00:03:42,160 --> 00:03:47,500 talk about the cards you put into pay phones and things like that in the 80s. 37 00:03:47,500 --> 00:03:53,440 There is of course, the 3G. Oh, sorry, there is of course ETSI, the European 38 00:03:53,440 --> 00:03:58,620 Telecommunication Standardization Institute, which is the entity where GSM 39 00:03:58,620 --> 00:04:08,310 was originally specified. GSM being the first digital telephony system that used 40 00:04:08,310 --> 00:04:10,891 SIM cards. The best of my knowledge, at least not a 41 00:04:10,891 --> 00:04:17,180 historian though. There's a 3GPP, the Third Generation Partnership Project, 42 00:04:17,180 --> 00:04:22,890 which is where the GSM specs have been handed over to. In the preparation of the 43 00:04:22,890 --> 00:04:27,389 3G specification process, because ETSI is a European entity and Chinese companies, 44 00:04:27,389 --> 00:04:31,250 for example, or Chinese government cannot participate there, or Americans even, to 45 00:04:31,250 --> 00:04:35,169 the extent that European companies can do. So it was lifted to an international new 46 00:04:35,169 --> 00:04:39,920 group called the Third Generation Partnership Project. And they of course 47 00:04:39,920 --> 00:04:44,091 inherited all the SIM card related specifications. And then we have like non- 48 00:04:44,091 --> 00:04:51,370 telecom standardization entities such as the Global Platform Card Specification. 49 00:04:51,370 --> 00:04:59,680 That's Global Platform is a body that specifies lots of aspects around Java 50 00:04:59,680 --> 00:05:04,500 cards, specifically around to applet management, installation and so on Java 51 00:05:04,500 --> 00:05:08,460 cards, which brings us to the next entity, which is not really a standardization 52 00:05:08,460 --> 00:05:12,380 body, but it's a private company that used to be called Sun and now it's part of 53 00:05:12,380 --> 00:05:18,040 Oracle, which defined the Java Card API runtime and the virtual machine of Java 54 00:05:18,040 --> 00:05:20,780 cards. And last but not least, we have the GSM 55 00:05:20,780 --> 00:05:25,940 Association, which is the vendor club of the operators. That doesn't really have to 56 00:05:25,940 --> 00:05:33,460 do that much with SIM cards until the eSIM, where then suddenly a GSM A plays a 57 00:05:33,460 --> 00:05:39,560 big role in the related specs and technology. So talking about these 58 00:05:39,560 --> 00:05:46,320 standardization bodies. What is the SIM, actually? The SIM is the Subscriber 59 00:05:46,320 --> 00:05:52,740 Identity Module. I mean probably anyone in here has one, likely more or at least has 60 00:05:52,740 --> 00:05:58,690 had. It's quite ubiquitous. Every device with cellular connectivity during the last 61 00:05:58,690 --> 00:06:05,450 whatever 20 or so years has a SIM, whether it's an actual card or whether it's 62 00:06:05,450 --> 00:06:11,490 soldered in these days. SIM card hacking has a tradition in the CCC since at least 63 00:06:11,490 --> 00:06:16,270 1998. I'm not sure how many people remember: 64 00:06:16,270 --> 00:06:23,190 there was the Vodafone Germany SIM card cloning attack back then. It was in 65 00:06:23,190 --> 00:06:32,800 German. It was titled "Von d2 privat zu D2 pirat". And that was an attack that used 66 00:06:32,800 --> 00:06:38,919 weaknesses and sort of brute forcing against the authentication mechanism to 67 00:06:38,919 --> 00:06:44,460 recover the secret key, which is stored in the card. And then you could clone SIM 68 00:06:44,460 --> 00:06:47,650 cards back then. That was then fixed in subsequent 69 00:06:47,650 --> 00:06:54,090 technology generations. And also around that time you can find on the FTP server 70 00:06:54,090 --> 00:07:01,990 of the CCC a SIM card simulator written in Turbo C using a season card. I'm not sure 71 00:07:01,990 --> 00:07:06,270 how many people remember season cards. These were cards people used in the 72 00:07:06,270 --> 00:07:12,990 context of cracking satellite TV encryption. Yeah, so. Meanwhile, of 73 00:07:12,990 --> 00:07:17,560 course, the SIM technology stack has increased and the complexity has increased 74 00:07:17,560 --> 00:07:22,230 like probably in any kind of technology. So let's recap, basically from the 75 00:07:22,230 --> 00:07:28,551 beginning to today what SIM cards are and what they do in some degree of detail. If 76 00:07:28,551 --> 00:07:34,400 we start historically with SIM cards, actually the predecessor to the SIM cards 77 00:07:34,400 --> 00:07:40,139 that we know, is the chip card used in the C-Netz, which is an analog telephony 78 00:07:40,139 --> 00:07:45,580 system that used to operate in Germany. There's actually an open source 79 00:07:45,580 --> 00:07:48,199 implementation these days as part of Osmocom-Analog. 80 00:07:48,199 --> 00:07:54,050 If you're interested in that, do check out a jolly at the vintage and retro 81 00:07:54,050 --> 00:08:01,570 computing area. And before 1988, they only had a magnetic stripe cards, but in 1988 82 00:08:01,570 --> 00:08:09,070 they introduced integrated circuit cards in this analog telephony system and in GSM 83 00:08:09,070 --> 00:08:14,199 it was a chip card from the beginning. The concept of the SIM card means you store 84 00:08:14,199 --> 00:08:19,199 the identity of the subscriber outside of the phone, which is very opposite to what 85 00:08:19,199 --> 00:08:23,979 happened in the CDMA world in the US around that time where it was basically 86 00:08:23,979 --> 00:08:28,151 inside the phone itself. But having the identity separate, of course, enables all 87 00:08:28,151 --> 00:08:33,560 kinds of use cases that were relevant at that time. 88 00:08:33,560 --> 00:08:39,380 We will get to that to some extent. In addition to the identity, and the identity 89 00:08:39,380 --> 00:08:43,770 in this context means a cryptographic identity, there are all kinds of network 90 00:08:43,770 --> 00:08:48,620 related parameters that are stored in the SIM card. Some of those are static, 91 00:08:48,620 --> 00:08:54,540 meaning that they are provisioned or written by the operator into the card, or 92 00:08:54,540 --> 00:08:59,019 of course by the SIM card manufacturer on behalf of the operator, but which are not 93 00:08:59,019 --> 00:09:03,480 writable by the user that effect access control classes, which 94 00:09:03,480 --> 00:09:07,769 means like, are you a normal user or are you an emergency service user which needs 95 00:09:07,769 --> 00:09:11,779 higher priority to access the network, things like that. And there are lots of 96 00:09:11,779 --> 00:09:17,430 dynamic parameters on the card, and dynamic means they get rewritten and 97 00:09:17,430 --> 00:09:22,499 changed and modified and updated all the time. That's for example, the TIMSI, the 98 00:09:22,499 --> 00:09:27,369 temporary identity that gets allocated by the network every so often. Also the 99 00:09:27,369 --> 00:09:35,480 current actual air interface encryption key like KC and its successors in modern 100 00:09:35,480 --> 00:09:40,970 generation technology. So they get updated and written all the time by the phone. And 101 00:09:40,970 --> 00:09:45,410 some of the files are even updated and written by users, at least traditionally 102 00:09:45,410 --> 00:09:50,939 or historically, like the phone book and the SMS that are stored on the card. It 103 00:09:50,939 --> 00:09:56,730 was originally specified as a full credit card sized cards and it was intended to be 104 00:09:56,730 --> 00:10:01,029 used in radios in rental cars or company shared cars. 105 00:10:01,029 --> 00:10:06,339 So basically when you leave the car, you would remove your SIM card, the full sized 106 00:10:06,339 --> 00:10:12,550 credit card sized card and somebody else would put their card in. And allegedly 107 00:10:12,550 --> 00:10:17,560 there even were, I think, public GSM phones installed in German trains where 108 00:10:17,560 --> 00:10:21,179 you could plug in a SIM card or something like that. But I personally haven't 109 00:10:21,179 --> 00:10:28,259 witnessed that, since I was ignorant at that time, apparently, of that fact. So, 110 00:10:28,259 --> 00:10:35,660 let's get to the mother of all smartcard specs, which is in German DIN EN ISO/IEC 7816 111 00:10:35,660 --> 00:10:43,670 or short just ISO 7816 and maybe an anecdote how these specs come around. So 112 00:10:43,670 --> 00:10:50,319 there's the ISO that specifies a certain spec, it gets an ISO number and then EN, 113 00:10:50,319 --> 00:10:55,570 the European norm, whatever body, comes around and says, "oh, we will elevate this 114 00:10:55,570 --> 00:11:00,089 international spec into a European standard". And they put an EN in front. 115 00:11:00,089 --> 00:11:04,350 And then DIN, the German standard body, comes around, says, oh, we will elevate 116 00:11:04,350 --> 00:11:10,360 this European norm into a German norm and we will put a DIN in front. So now in 117 00:11:10,360 --> 00:11:14,639 Germany, we have DIN EN ISO/IEC 7816. And if you get the actual copy from DIN 118 00:11:14,639 --> 00:11:20,249 it's quite funny. I didn't don't have it here, but actually you get a one page 119 00:11:20,249 --> 00:11:25,339 additional paper on top, which translates the key technical phrases from English to 120 00:11:25,339 --> 00:11:30,309 German. And that's the added value that you get from it become. Sorry. I mean, 121 00:11:30,309 --> 00:11:34,639 it's just hilarious. The entire spec is in English, but then there's like this key 122 00:11:34,639 --> 00:11:39,129 translated terms. So you know, that file means "Datei", for example, that's 123 00:11:39,129 --> 00:11:45,990 extremely beneficial to the reader of such specifications. Anyway, so the title is 124 00:11:45,990 --> 00:11:50,420 "Integrated Circuit Cards with contacts". *chuckles* I wonder, OK, they are contact 125 00:11:50,420 --> 00:11:56,709 less now, but at least back then, cerainly, they didn't exist. And it has 15 126 00:11:56,709 --> 00:12:00,490 parts by now. The most relevant parts are 1 through 4, 127 00:12:00,490 --> 00:12:03,509 starting from the physical characteristics, going through the 128 00:12:03,509 --> 00:12:07,360 mechanical dimensions and the location of the contacts, of course, it's a separate 129 00:12:07,360 --> 00:12:10,989 part of the spec. And each of those specs are sold as a separate document, of 130 00:12:10,989 --> 00:12:14,749 course. So the physical size you pay and if you want to know the location of the 131 00:12:14,749 --> 00:12:19,819 contacts you have to pay to get another spec. And then there's part 3, which 132 00:12:19,819 --> 00:12:23,430 covers the electronic signals and the transmission protocols. We will look at 133 00:12:23,430 --> 00:12:27,920 that in some detail. And then there's part 4, which is the inter-industry commands 134 00:12:27,920 --> 00:12:32,130 for interchange, which I find very interesting. And I always thought they 135 00:12:32,130 --> 00:12:35,710 should have met the international inter- industry commands for inter-working 136 00:12:35,710 --> 00:12:39,349 information interchange. But apparently they didn't come up with that. And of 137 00:12:39,349 --> 00:12:44,550 course, this all predates the Internet, so there's no Internet in there. Yeah. The 138 00:12:44,550 --> 00:12:48,999 next relevant spec is GSM technical specification eleven dot eleven. Very easy 139 00:12:48,999 --> 00:12:54,550 to memorize that number, which is the specification of the subscriber identity 140 00:12:54,550 --> 00:13:00,159 module dash mobile equipment interface. So in GSM there is what's called a mobile 141 00:13:00,159 --> 00:13:03,640 station, which is your phone, and it is comprised of two parts, the mobile 142 00:13:03,640 --> 00:13:08,180 equipment, which is the hardware and the SIM, which is the SIM next to the mobile 143 00:13:08,180 --> 00:13:12,119 equipment. And it interestingly, it doesn't just 144 00:13:12,119 --> 00:13:17,339 refer to these ISO specs that I mentioned before, but it actually repeats like more 145 00:13:17,339 --> 00:13:23,079 or less carbon copies large portions of these ISO specs with some amendments or 146 00:13:23,079 --> 00:13:28,909 corrections or extensions. And again, it gives you the location of the contacts and 147 00:13:28,909 --> 00:13:32,629 the mechanical size of the card and the electronic signals and the transmission 148 00:13:32,629 --> 00:13:38,249 protocols and so on. But beyond these ISO standards, it also actually specifies what 149 00:13:38,249 --> 00:13:42,109 makes the SIM a SIM and not any other contact card, which is the information 150 00:13:42,109 --> 00:13:48,379 model, the file system on the card and the commands and protocols that you use on 151 00:13:48,379 --> 00:13:56,420 this card. And last, with typo as usual on my slides, but not least, of course, how 152 00:13:56,420 --> 00:14:03,459 to execute the GSM algorithm to to perform cryptographic authentication. 153 00:14:03,459 --> 00:14:08,449 The physical smartcard interface is interesting. I mean if you've worked with 154 00:14:08,449 --> 00:14:13,579 hardware or electronics or serial interfaces, I think it's rather exotic and 155 00:14:13,579 --> 00:14:20,210 exotics always means interesting. So we have four relevant pins. We have a supply 156 00:14:20,210 --> 00:14:27,259 voltage, not surprisingly. It can be 5, 3 or 1.8 volts. Interesting, it's not 3.3 157 00:14:27,259 --> 00:14:32,019 volt, it's 3.0 volts nominal. Not sure why. But anyway, that's how it 158 00:14:32,019 --> 00:14:36,790 is. We have a clock line that provides a clock signal which initially needs to be 159 00:14:36,790 --> 00:14:42,269 between 1 and 5 megahertz. So the phone provides power and clock. We have a reset 160 00:14:42,269 --> 00:14:46,590 line which also makes sense; you want to reset the card and then we have one IO 161 00:14:46,590 --> 00:14:49,340 line for bi-directional serial communication. 162 00:14:49,340 --> 00:14:54,470 So you have RX and TX sharing one line and there is some nice diagrams about how 163 00:14:54,470 --> 00:15:00,529 exactly the sequencing happens when you power it up, nothing really surprising. 164 00:15:00,529 --> 00:15:04,339 There's an activation sequence and after the card is activated, the card will 165 00:15:04,339 --> 00:15:09,249 unilaterally send what's called an ATR, the answer to reset. And that's just a 166 00:15:09,249 --> 00:15:13,389 series of bytes which give some information about the card capabilities. 167 00:15:13,389 --> 00:15:18,740 What protocols, what voltages, what clock rates beyond these initial activation ones 168 00:15:18,740 --> 00:15:25,349 are supported. Now, after we've powered up the card, we have the bit transmission 169 00:15:25,349 --> 00:15:29,519 level. And it's actually very much like a normal 170 00:15:29,519 --> 00:15:38,430 UART. If you ever looked at RS232 or another UART a serial port, rather simple: 171 00:15:38,430 --> 00:15:45,499 start byte, stop byte, parity, serial bit transmission. What's a bit interesting is 172 00:15:45,499 --> 00:15:51,899 that we have a clock and the baud rate is divided from that clock, but it's still an 173 00:15:51,899 --> 00:15:55,670 asynchronous transmission. So there is no phase relationship between the clock 174 00:15:55,670 --> 00:15:59,790 signal and the baud rate that the data uses, which lots of people get wrong, 175 00:15:59,790 --> 00:16:04,110 particularly lots of authors of Atmel microcontroller data sheets which claim 176 00:16:04,110 --> 00:16:08,619 that it's a synchronous communication, which it is not. Yeah. 177 00:16:08,619 --> 00:16:12,999 So the direction changes every so often to have acknowledgements back and forth and 178 00:16:12,999 --> 00:16:17,019 to exchange data in both directions. And interestingly, a lot of the timings are 179 00:16:17,019 --> 00:16:20,981 not specified very well, but I guess nobody cares about that, other than if you 180 00:16:20,981 --> 00:16:26,979 want to implement a card reader, which I happen to have gone through this year. 181 00:16:26,979 --> 00:16:32,870 Smart Card Communication: after we are able to transmit bytes between the card 182 00:16:32,870 --> 00:16:37,640 and the reader, we have something called APDUs. The Application Protocol Data Unit 183 00:16:37,640 --> 00:16:42,549 specified as per that ISO 7816-4. That's the inter-industry commands for 184 00:16:42,549 --> 00:16:50,979 interchange. And an APDU consists of a couple of bytes. There's a class byte that 185 00:16:50,979 --> 00:16:54,720 just specifies the class of command as an instruction byte which specifies the 186 00:16:54,720 --> 00:16:59,249 specific instruction like read a file, write a file. We have some parameter bytes 187 00:16:59,249 --> 00:17:04,799 whose meaning is relevant or is specific to the instruction, then we have a length 188 00:17:04,799 --> 00:17:09,270 of a command and command data. We have an expected response length and response data. 189 00:17:09,270 --> 00:17:13,770 And last but not least, a so-called status word and the status word basically, the 190 00:17:13,770 --> 00:17:18,929 card tells whether the execution was successful or whether there was some error 191 00:17:18,929 --> 00:17:26,020 and what kind of error there was and things like that. The APDUs are then split 192 00:17:26,020 --> 00:17:31,179 into a lower layer transport protocol, which are called TPDUs. 193 00:17:31,179 --> 00:17:36,000 There are two different commonly used protocols and two specific ones that are 194 00:17:36,000 --> 00:17:39,970 used in the context of SIM cards ore are specified in the context of SIM cards, as 195 00:17:39,970 --> 00:17:45,929 one called T=0. Which is most commonly used for SIM cards. Actually, I've never 196 00:17:45,929 --> 00:17:53,020 seen anything else but T=0 used, but T=1 is another protocol which according to the 197 00:17:53,020 --> 00:17:59,769 specs, every phone needs to implement. And the card can choose if it does T=0 or T=1. 198 00:17:59,769 --> 00:18:04,929 As again, I've never seen a card that does T=1, or at least that has only T=1, but 199 00:18:04,929 --> 00:18:10,410 the specs would allow that. T=1 is more used in banking and crypto smart cards. 200 00:18:10,410 --> 00:18:16,049 The difference mainly is T=1 is a block oriented transfer and T=0 is more a byte 201 00:18:16,049 --> 00:18:21,059 oriented transfer. And T=1 has the advantage that it has CRC and checksumming, 202 00:18:21,059 --> 00:18:24,880 so you get more protection against transmission errors which you 203 00:18:24,880 --> 00:18:34,210 don't have in T=0. So the APDU gets mapped to TPDUs. Details I'll skip here and this 204 00:18:34,210 --> 00:18:37,110 is just some examples, so you get an idea how this looks like. 205 00:18:37,110 --> 00:18:45,920 So we have A0 A4 00 00 02 3F 00. The A0 here is the class byte and A0 is SIM card 206 00:18:45,920 --> 00:18:51,789 class. A4 is select file. So you're selecting a certain file on 207 00:18:51,789 --> 00:18:56,659 which you want to operate. Two parameter bytes are 0, 02 is the length of the 208 00:18:56,659 --> 00:19:02,410 command. And then you have two bytes of that length 3F 00, which is basically your 209 00:19:02,410 --> 00:19:06,550 slash, your root directory. You want to change to the root directory of the file 210 00:19:06,550 --> 00:19:11,820 system, is basically what that command says. And one hypothetical response is 211 00:19:11,820 --> 00:19:21,549 just a status word 90 00, which means success. Yeah. Selecting a file. So we 212 00:19:21,549 --> 00:19:28,179 have a file system on the card. Most smart cards do that. It's not a file system in 213 00:19:28,179 --> 00:19:33,519 the context like you have a USB drive that you can mount, where you just have a block 214 00:19:33,519 --> 00:19:37,960 abstraction or something. But the smart card filesystem itself runs 215 00:19:37,960 --> 00:19:42,640 inside the card and you just talk to the filesystem and give it instructions. So if 216 00:19:42,640 --> 00:19:47,260 you want to find an abstraction in PC technology, it's more like MTP or PTP over 217 00:19:47,260 --> 00:19:52,860 USB where you don't have a block device, but you talk to another processor which 218 00:19:52,860 --> 00:19:57,970 manages a file system and you can instruct it's like a remote file system access. 219 00:19:57,970 --> 00:20:02,500 You have some similarities to normal file systems. I mean, there's a master file 220 00:20:02,500 --> 00:20:07,139 which corresponds to a root directory in PC file systems. You have so called 221 00:20:07,139 --> 00:20:12,100 dedicated files, which are sub directories and you have so called elementary files, 222 00:20:12,100 --> 00:20:17,610 which are actual data containing files as we know them. Beyond that, there are lots 223 00:20:17,610 --> 00:20:26,059 of specifics that we don't find PC file systems or operating system file systems. 224 00:20:26,059 --> 00:20:32,700 We have what's called a transparent EF. That's an opaque stream of data like your 225 00:20:32,700 --> 00:20:36,460 normal binary file on on any random operating system. But then we have 226 00:20:36,460 --> 00:20:42,320 concepts like a linear fixed EF which contains fixed size records and you can 227 00:20:42,320 --> 00:20:46,809 seek against it. Get me the 15th record in that file and the file has a 228 00:20:46,809 --> 00:20:50,440 record size of whatever 24 bytes for example. And then you have something 229 00:20:50,440 --> 00:20:56,169 called a cyclic EF where they have a ring buffer of records and you have 230 00:20:56,169 --> 00:21:00,309 incrementable files which contain monotonically incrementing counters and 231 00:21:00,309 --> 00:21:05,000 things that are apparently important for charging or things like that. 232 00:21:05,000 --> 00:21:14,120 Each file has access control conditions that define who can read and or modify and 233 00:21:14,120 --> 00:21:20,139 or well, there's no delete, but there's something called invalidate the file. And 234 00:21:20,139 --> 00:21:25,620 who is basically expressed in context of which PIN was used to authenticate that 235 00:21:25,620 --> 00:21:29,881 entity, which performs the operation. So as a user, you have a PIN1 and some 236 00:21:29,881 --> 00:21:35,620 people will remember you also have a PIN2, that probably nobody's used since the 90s. 237 00:21:35,620 --> 00:21:39,880 And the operator has something called an ADM PIN, administrative pin, which gives 238 00:21:39,880 --> 00:21:46,880 better or higher privileges in terms of filesystem permissions on those files. The 239 00:21:46,880 --> 00:21:53,980 kind of commands we see, well, select file from the example. We have read record, 240 00:21:53,980 --> 00:21:57,769 update records. I guess I don't need to say anything about that. Similarly, read 241 00:21:57,769 --> 00:22:04,779 binary, update binary. And then we have commands like CHV commands, where CHV is 242 00:22:04,779 --> 00:22:10,640 the cardholder verification which is ETSI language for a pin. Not sure why they 243 00:22:10,640 --> 00:22:17,340 don't call it PIN. So there's change PIN, disable PIN or enable PIN commands. Which 244 00:22:17,340 --> 00:22:20,960 is actually what your phone performs, if you, say, you disable the PIN or you 245 00:22:20,960 --> 00:22:24,909 change the PIN then exactly those commands are issued to the card and last but not 246 00:22:24,909 --> 00:22:29,539 least, run GSM algorithm. Remember, this is still the 2G only SIM. We haven't yet 247 00:22:29,539 --> 00:22:34,990 gone beyond 2G, yet at this point in the slides. There is actually not that many 248 00:22:34,990 --> 00:22:40,960 more. That's that's really it. Now let's look at the file system hierarchy. We have 249 00:22:40,960 --> 00:22:45,610 the MF, the root file system and then we have something called DF_TELECOM. And the 250 00:22:45,610 --> 00:22:49,179 hex numbers in parentheses are the identifiers that are actually used on the 251 00:22:49,179 --> 00:22:53,590 protocol level. We have something called DF_GSM, which is the GSM directory 252 00:22:53,590 --> 00:23:01,700 containing GSM related parameters. And if EF_ICCID where ICCID is the card unique 253 00:23:01,700 --> 00:23:06,710 identifier that's stored on the card. And if you expand that into more details, you 254 00:23:06,710 --> 00:23:10,669 get these kind of graphs. And this is one is actually taken from one of the specs. 255 00:23:10,669 --> 00:23:18,020 And you see there's also an Iridium directory or a, uh, whatever that one was, 256 00:23:18,020 --> 00:23:21,440 a Global Star directory. And all kinds of people operating 257 00:23:21,440 --> 00:23:26,060 different telephony system have basically their own directories in that scheme. But 258 00:23:26,060 --> 00:23:33,020 on GSM, we find those two mainly, maybe some sub directories. Yeah, so when 3G 259 00:23:33,020 --> 00:23:41,600 came around something happened, as I said, the specifications were shifted from ETSI 260 00:23:41,600 --> 00:23:49,380 to a 3GPP. But of course, chip cards in the context of telecom have use cases 261 00:23:49,380 --> 00:23:55,269 outside of cellular telephony. So, actually, the specs were split in that 262 00:23:55,269 --> 00:23:59,889 area. So there's something new called the UICC, the Universal Integrated Circuit 263 00:23:59,889 --> 00:24:05,870 Card, because the previous one was not universal, apparently. And that part of 264 00:24:05,870 --> 00:24:10,210 the specs remained with ETSI and continues to be developed. And there is the USIM 265 00:24:10,210 --> 00:24:18,169 application on top of the UICC, which is what specifies the 3GPP relevant part and 266 00:24:18,169 --> 00:24:24,879 that gets implemented in something called an ADF, an application dedicated file, ADF 267 00:24:24,879 --> 00:24:29,799 USIM. In ADF you can also select or enter using 268 00:24:29,799 --> 00:24:35,629 a select command similar to a normal DF. The difference mainly is that the 269 00:24:35,629 --> 00:24:40,130 identifiers on much longer and thus other details, but from a user point of view 270 00:24:40,130 --> 00:24:45,500 that's how it looks like. So we have a split of the core Universal ICC and on top 271 00:24:45,500 --> 00:24:52,299 an USIM application. And if you have a SIM card that can be used with 2G and with 3G, 272 00:24:52,299 --> 00:24:55,929 then you basically have the classic SIM card and in addition you have a USIM 273 00:24:55,929 --> 00:24:59,659 application on the card. And actually there are some cards that 274 00:24:59,659 --> 00:25:04,620 only work with 3G or later technology and don't have 2G mode, because the operator 275 00:25:04,620 --> 00:25:08,679 doesn't have a 2G network. So you only have a USIM application and you don't have 276 00:25:08,679 --> 00:25:15,769 the classic SIM anymore on the card. When 4G/LTE came around, actually there was no 277 00:25:15,769 --> 00:25:20,470 strict requirement to change anything in the SIM card and you can just use a normal 278 00:25:20,470 --> 00:25:27,100 USIM, UMTS SIM, a 3G card on LTE networks. It's the same authentication key agreement 279 00:25:27,100 --> 00:25:32,631 mechanism. They have added some additional files that are completely optional. Mostly 280 00:25:32,631 --> 00:25:39,669 like optimizing some bits and there are some optional new IMS application. IMS is 281 00:25:39,669 --> 00:25:47,179 the IP multimedia system which is 3GPP language for voice over IP or VoLTE, 282 00:25:47,179 --> 00:25:52,919 right? So IMS is the IP multimedia system, which is what is used to implement VoLTE 283 00:25:52,919 --> 00:25:58,140 where VoLTE is not a specification term but more a marketing term and that's 284 00:25:58,140 --> 00:26:01,410 optionally on the SIM card. You can have an ISIM an application which 285 00:26:01,410 --> 00:26:05,430 stores parameters relevant to the IP multimedia system such as SIP user 286 00:26:05,430 --> 00:26:09,429 identities and SIP service and things like that. But if that ISIM application doesn't 287 00:26:09,429 --> 00:26:13,210 exist, there is a fallback mechanism by which the identifiers are computed based 288 00:26:13,210 --> 00:26:16,770 on the IMSI and and so on and so on. So it's not really necessary to have a 289 00:26:16,770 --> 00:26:25,679 specific 4G SIM, but it's possible to have that. Once we go to 5G, 5G actually reuses 290 00:26:25,679 --> 00:26:33,030 the existing 3G and 4G USIM cards. Again, some new optional files have been 291 00:26:33,030 --> 00:26:38,399 introduced and there is one feature which I guess everyone in here wants to have, 292 00:26:38,399 --> 00:26:43,820 which would require a new SIM card or change SIM card, which is that the SUCI, 293 00:26:43,820 --> 00:26:50,330 the Subscriber Concealed Identifier, can be computed inside the SIM card or by the 294 00:26:50,330 --> 00:26:55,169 phone. And if it is computed inside the SIM card, 295 00:26:55,169 --> 00:27:00,320 then the SIM of course has to have support for doing that computation and that is 296 00:27:00,320 --> 00:27:04,540 something that needs explicit SIM card support. In absence of that, everything 297 00:27:04,540 --> 00:27:09,100 else you can use an existing 4G SIM card even on 5G networks. Nothing really 298 00:27:09,100 --> 00:27:16,340 changed there, fundamentally. OK, now looking at the cards, more on the 299 00:27:16,340 --> 00:27:21,000 physical side and from the hardware and we will look at the software, the operating 300 00:27:21,000 --> 00:27:27,960 systems and so on and the various things you can do with SIM cards later on. We 301 00:27:27,960 --> 00:27:32,279 have, of course, the processor core that many different vendors and architectures, 302 00:27:32,279 --> 00:27:38,070 traditionally lots of 8051 derivatives inside smart cards. These days we also 303 00:27:38,070 --> 00:27:44,590 actually find a lot ??? ARM cores, quite often so-called SC cores. There's an SC000 304 00:27:44,590 --> 00:27:50,010 and then a SC100 and an SC300 and SC is for Secure Core. 305 00:27:50,010 --> 00:27:53,590 So it's not a normal Cortex core or something like that, but it's a secure 306 00:27:53,590 --> 00:27:57,870 core and it's so secure that ARM doesn't even disclose what is secure about it 307 00:27:57,870 --> 00:28:03,770 other than that it is secure. And so the documentation for sure is securely kept 308 00:28:03,770 --> 00:28:11,639 away from anyone who would want to read it. So, for these chips, the smartcard 309 00:28:11,639 --> 00:28:16,440 chips used in SIM cards or generally smart card chips themselves, often you cannot 310 00:28:16,440 --> 00:28:20,249 even find a similar thing, simple one page data sheet which tells you the main 311 00:28:20,249 --> 00:28:27,341 features. Even that is already under NDA. You have built-in RAM and built-in ROM, at 312 00:28:27,341 --> 00:28:31,940 least a bootloader normally, but possibly also the OS or parts of the OS, but that 313 00:28:31,940 --> 00:28:36,549 is increasingly uncommon. So modern cards, most of them only have flash and the 314 00:28:36,549 --> 00:28:41,109 entire operating system is in flash, so you can update everything. And then 315 00:28:41,109 --> 00:28:44,850 applications on top of that and we will look at applications later when we talk 316 00:28:44,850 --> 00:28:49,640 about the software. And unfortunately, contrary to the crypto 317 00:28:49,640 --> 00:28:55,320 smartcards where it's possible to have higher prices and therefore have, you 318 00:28:55,320 --> 00:29:01,080 know, rather expensive products, SIM cards are mostly selected purely by cost these 319 00:29:01,080 --> 00:29:06,380 days due to the prepaid boom. I mean, it was different when GSM was introduced. If 320 00:29:06,380 --> 00:29:10,059 you, if every subscriber has to get a subscription and there's going to be 321 00:29:10,059 --> 00:29:14,490 hundreds of Euros or Marks of whatever in revenue, then you can invest a lot of 322 00:29:14,490 --> 00:29:19,360 money in a SIM card, but prepaid cards that get thrown away on a daily basis you 323 00:29:19,360 --> 00:29:23,279 can only pay cents for the card and then you need to pay another a couple of cents 324 00:29:23,279 --> 00:29:29,309 for the Java card for the Java VM patent royalties and so on and so on. But 325 00:29:29,309 --> 00:29:35,139 basically you cannot afford to pay money for SIM cards anymore. So that also 326 00:29:35,139 --> 00:29:38,800 explains why a lot of SIM cards today, even though it's technically available, 327 00:29:38,800 --> 00:29:42,750 they don't have hardware crypto, but they actually implement it in software, because 328 00:29:42,750 --> 00:29:48,160 it's cheaper. And then of course, yeah, well, you have time of execution, things 329 00:29:48,160 --> 00:29:53,010 and whatnot. So in terms of software, you have a Card 330 00:29:53,010 --> 00:29:58,830 Operating System. Cards that don't have an operating system are memory cards which 331 00:29:58,830 --> 00:30:07,499 are not sufficient for SIM card use cases. And in the crypto smartcard area, it's the 332 00:30:07,499 --> 00:30:15,849 operating systems are typically well known and documented to some part, at least. In 333 00:30:15,849 --> 00:30:19,510 SIM cards it's slightly different. So almost nobody ever mentions what kind of 334 00:30:19,510 --> 00:30:27,470 operating system is on the SIM card and even the SIM card vendors. It's not very, 335 00:30:27,470 --> 00:30:31,690 you know, not something they would put on their marketing, or on their homepage or 336 00:30:31,690 --> 00:30:34,639 something, what exactly kind of operating systems are on there. 337 00:30:34,639 --> 00:30:38,330 The SIM card offering system also from the central network point of view as an 338 00:30:38,330 --> 00:30:43,470 implementation detail, because all the relevant parts are specified standardised 339 00:30:43,470 --> 00:30:48,110 interfaces and what operating system people use on the card, well, it's the 340 00:30:48,110 --> 00:30:53,490 operator's choice. It doesn't really matter from that point of view. In early 341 00:30:53,490 --> 00:30:58,070 SIM cards, I presume they were rather monolithic, so you didn't really have a 342 00:30:58,070 --> 00:31:02,340 separation between an operating system and SIM application. Today the software's 343 00:31:02,340 --> 00:31:06,549 become more modular. We have this abstraction between the operating system 344 00:31:06,549 --> 00:31:12,540 and applications. And traditionally, even when that separation already existed, the 345 00:31:12,540 --> 00:31:15,640 operating system was very hardware dependent, non-portable and the 346 00:31:15,640 --> 00:31:22,259 applications were very OS-dependent and non-portable. And that has changed a bit 347 00:31:22,259 --> 00:31:29,830 due to the introduction of Java cards into the SIM card area, which is not required. 348 00:31:29,830 --> 00:31:35,249 There there's no requirement anywhere that the SIM card must be a Java card, but in 349 00:31:35,249 --> 00:31:38,950 practice, most SIM cards are Java cards because they have certain, at least 350 00:31:38,950 --> 00:31:45,190 perceived, advantages and are the norm by now. And the Java cards themselves have 351 00:31:45,190 --> 00:31:53,019 been independently developed of SIM cards. Of course, Java is a Sun technology, so 352 00:31:53,019 --> 00:31:58,510 Sun is behind that. And the first actual cards that were produced in 96, so much 353 00:31:58,510 --> 00:32:05,249 later than SIM cards came out by Schlumberger which is now part of Gemalto. 354 00:32:05,249 --> 00:32:13,450 And um, yeah, we have redundant lines in this presentation. And so, the Java cards, 355 00:32:13,450 --> 00:32:17,809 most of them implement a global platform specifications, which then specify vendor 356 00:32:17,809 --> 00:32:24,970 independent management of the cards and the applications on it. And the Java that 357 00:32:24,970 --> 00:32:29,429 you use to write such cards, don't ever think it is real Java! I mean, if you show 358 00:32:29,429 --> 00:32:33,502 that to any Java developer, he will probably disappear very quickly as we have 359 00:32:33,502 --> 00:32:38,040 a very weird constrained subset of Java with a special on-card virtual machine, 360 00:32:38,040 --> 00:32:41,999 which is not a normal virtual machine. You have a runtime environment that's not the 361 00:32:41,999 --> 00:32:46,220 normal runtime environment. You have a special binary format which is not a char 362 00:32:46,220 --> 00:32:50,299 file. And the idea is that you have portability 363 00:32:50,299 --> 00:32:56,990 of card applications, which makes sense, of course. But one could have done that 364 00:32:56,990 --> 00:33:02,240 with, you know, whatever other standards as well. Wouldn't necessarily need a 365 00:33:02,240 --> 00:33:08,460 virtual machine for that. Yeah, I said there's no functional requirement that a 366 00:33:08,460 --> 00:33:11,980 SIM card must be a Java card, but in reality that's the case. I think the 367 00:33:11,980 --> 00:33:15,929 portability is the driver here. So, if an operator develops some application that 368 00:33:15,929 --> 00:33:21,039 runs on a SIM card, you know, every year or so they do a new tender or they have a 369 00:33:21,039 --> 00:33:25,240 new SIM card supplier or something like that, they want to run their application 370 00:33:25,240 --> 00:33:32,259 on the current and the future and the next future future SIM card and not rewrite all 371 00:33:32,259 --> 00:33:37,450 of that from scratch or have that rewritten from scratch all the time. 372 00:33:37,450 --> 00:33:44,441 And interestingly, both 3GPP and ETSI specify Java APIs and Java packages, which 373 00:33:44,441 --> 00:33:48,350 are specifically available on Java cards that also are SIM cards. So basically you 374 00:33:48,350 --> 00:33:51,970 have SIM card specs and you have Java card specs and if you have both of them 375 00:33:51,970 --> 00:33:58,559 together, you also have SIM card Java API specs for what kind of additional API's 376 00:33:58,559 --> 00:34:04,950 applications on the card can use in order to affect SIM relevant aspects of the 377 00:34:04,950 --> 00:34:12,270 card. Which brings us to one of the strange historic developments called SIM 378 00:34:12,270 --> 00:34:20,370 Toolkit or later Card Application Toolkit, which is sort of an ability to offer 379 00:34:20,370 --> 00:34:23,619 applications with UI and menu on the phone, right? 380 00:34:23,619 --> 00:34:30,460 I mean the card of course doesn't have any user interface, but the card can sort of 381 00:34:30,460 --> 00:34:35,520 request like show a menu and offer multiple choices and things like that. 382 00:34:35,520 --> 00:34:39,610 Some people will have seen it on some phones. You have this SIM toolkit menu 383 00:34:39,610 --> 00:34:46,050 somewhere. And I mean, I think in Germany never really took off much in terms of 384 00:34:46,050 --> 00:34:50,320 actual applications. I mean, you could probably subscribe to some very expensive 385 00:34:50,320 --> 00:34:57,730 premium SMS services. If you were really bored, but in other regions, this has been 386 00:34:57,730 --> 00:35:07,110 very successful and very organized, had a real impact on society. Kenya is always 387 00:35:07,110 --> 00:35:13,130 the, I think the prime example for that, where MPESA, the mobile payment 388 00:35:13,130 --> 00:35:16,760 system, implemented at least initially based on card application toolkit 389 00:35:16,760 --> 00:35:22,090 applications, basically overtook the banking sector. At some point everybody 390 00:35:22,090 --> 00:35:25,950 did their wire transfers that way, even people who didn't even have a bank account 391 00:35:25,950 --> 00:35:30,960 and it basically replaced or substituted large amounts of the everyday banking 392 00:35:30,960 --> 00:35:37,160 needs of people. So there are exceptions. Some additional instructions that we have 393 00:35:37,160 --> 00:35:43,850 in terms of APDUs, details I will not look into these. The next step after SIM 394 00:35:43,850 --> 00:35:48,980 toolkit is the so-called proactive SIM. If we look at the SIM card communication as 395 00:35:48,980 --> 00:35:52,420 it is specified, or smartcard communication in general, it's always the 396 00:35:52,420 --> 00:35:57,730 reader, in this context the phone, that sort of sends an instruction to the phone, 397 00:35:57,730 --> 00:36:02,150 to the card and the card responds. So the card is always the slave in the 398 00:36:02,150 --> 00:36:06,540 communication and it doesn't have any possibility to trigger something by 399 00:36:06,540 --> 00:36:10,340 itself. And that was sort of worked around by the 400 00:36:10,340 --> 00:36:16,650 proactive SIM specifications where a command or a request from the card is 401 00:36:16,650 --> 00:36:22,880 piggy-backed into responses to the commands from their phone to the card, and 402 00:36:22,880 --> 00:36:28,730 then basically that the SIM card can request the phone to poll the card every 403 00:36:28,730 --> 00:36:32,920 so often, so the phone can ask for "do you have a new command for me now?" and the 404 00:36:32,920 --> 00:36:38,330 card can say yes or no. In this way, they work around this restriction. 405 00:36:38,330 --> 00:36:41,540 And it's not only polling that can be requested, but it can be event 406 00:36:41,540 --> 00:36:46,450 notifications. And event notifications can be loss of network coverage, registration 407 00:36:46,450 --> 00:36:53,520 to a new cell, opening of a web browser and like are you making a mobile 408 00:36:53,520 --> 00:36:55,720 originated call, are you sending an SMS or not? 409 00:36:55,720 --> 00:37:00,110 So all these kind of events can be sent to the SIM card, so that the SIM card can do 410 00:37:00,110 --> 00:37:07,260 whatever with it. I think that not many useful applications beyond steering of 411 00:37:07,260 --> 00:37:11,680 roaming or roaming control, by basically depending on where you register and what 412 00:37:11,680 --> 00:37:15,940 kind of cells you have, and even the measurement reports on what is the signal 413 00:37:15,940 --> 00:37:20,530 strength that can be fed into the SIM card, which then can basically decide what 414 00:37:20,530 --> 00:37:29,720 to do. But yeah, I think it's all rather exotic and very few, like relevant or good 415 00:37:29,720 --> 00:37:35,790 use cases of this. The next step is Over-The-Air-technology 416 00:37:35,790 --> 00:37:41,010 (OTA), which is the ability for the operator to transparently communicate with 417 00:37:41,010 --> 00:37:45,480 the SIM card in the field. With the traditional non-OTA capable SIM card, the 418 00:37:45,480 --> 00:37:49,420 operator or the SIM card manufacturer writes at manufacturing time (at so-called 419 00:37:49,420 --> 00:37:53,250 personalization time of the card), and then it's with the subscriber. And if the 420 00:37:53,250 --> 00:37:57,060 operator ever wants to fix something or change something, they have to send a new 421 00:37:57,060 --> 00:38:03,450 plastic card. With OTA, they can be updated. It's based on proactive SIM 422 00:38:03,450 --> 00:38:12,850 technology and by now, there are many different communication channels how some 423 00:38:12,850 --> 00:38:16,650 back end system at the operator can can interact with a card inside the phone of 424 00:38:16,650 --> 00:38:22,170 the subscriber. The classic channel is SMS-PP, which is the SMS as you know, it 425 00:38:22,170 --> 00:38:28,540 just officially called SMS point-to-point. It's also possible over SMS-CB, the cell- 426 00:38:28,540 --> 00:38:33,210 broadcast-SMS, which I find very interesting, bulk updates to SIM cards via 427 00:38:33,210 --> 00:38:38,870 cell broadcast, which also would mean that they all have a shared key for 428 00:38:38,870 --> 00:38:44,970 authenticating these updates. It's also specified for USSD from release 7 on most 429 00:38:44,970 --> 00:38:48,980 of the specs. And then there's something new, at that point, called BIP, the 430 00:38:48,980 --> 00:38:53,880 "bearer independent protocol" that works over circuit-switch-data and GPRS. Here 431 00:38:53,880 --> 00:38:58,060 are some spec numbers if anyone is interested. And now, since release 9, that 432 00:38:58,060 --> 00:39:03,940 means since LTE is around, also over HTTPS. I'll get to that in a couple of 433 00:39:03,940 --> 00:39:07,340 separate slides. There's actually a TLS implementation in 434 00:39:07,340 --> 00:39:13,550 SIM cards these days, believe it or not. So the cryptographic security mechanisms 435 00:39:13,550 --> 00:39:17,220 set are specified, but of course the detailed use is up to the operator so the 436 00:39:17,220 --> 00:39:21,150 operator may choose whether or not to use measures of authentication, or whether or 437 00:39:21,150 --> 00:39:26,110 not to use encryption, or whether or not to use counters for replay protection. And 438 00:39:26,110 --> 00:39:29,730 this is basically one area where a lot of the security research and the 439 00:39:29,730 --> 00:39:33,820 vulnerabilities published in the last decade or so have been happening, e.g. 440 00:39:33,820 --> 00:39:37,061 cards were not properly configured, or they had implementation weaknesses, or you 441 00:39:37,061 --> 00:39:42,290 had some sort of oracles that you could query when interacting with those cards as 442 00:39:42,290 --> 00:39:49,740 an attacker. One of the use cases of Over- The-Air is RFM, not RTFM, it's RFM, 443 00:39:49,740 --> 00:39:53,980 "Remote-File-Management". It was introduced in release 6 and the number of 444 00:39:53,980 --> 00:40:01,701 typos is embarrassing. A common use case of Over-The-Air: It allows you to read or 445 00:40:01,701 --> 00:40:07,000 update files in the file system remotely, and you can use that, for example, for the 446 00:40:07,000 --> 00:40:11,030 preferred or forbidden roaming operator lists. That's a very legitimate use case 447 00:40:11,030 --> 00:40:15,070 for that. There's also an ancient example that I always like. I think Vodafone 448 00:40:15,070 --> 00:40:18,700 Netherlands once advertised that the operator can take a backup of your phone 449 00:40:18,700 --> 00:40:24,950 book on the SIM card. I think it's an early manifestation of cloud computing 450 00:40:24,950 --> 00:40:32,560 before it even existed. In any case, it's certainly a feature that everyone in here 451 00:40:32,560 --> 00:40:38,120 would like to have. Of course it's irrelevant by now because nobody has 452 00:40:38,120 --> 00:40:43,310 contacts on SIM cards anymore. The next is RAM which is not "Random Access Memory", 453 00:40:43,310 --> 00:40:48,210 it's "Remote Application Management". It was also introduced in the same release 454 00:40:48,210 --> 00:40:53,750 with the same typo, and it allows installation and/or removal of 455 00:40:53,750 --> 00:40:57,530 applications on the card, and applications in terms of Java card then means Java 456 00:40:57,530 --> 00:41:03,160 cardlets. For example, you could update or install new multi IMSI-applications, which 457 00:41:03,160 --> 00:41:09,640 is one very creative way of using SIM cards in more recent years, or new Sim- 458 00:41:09,640 --> 00:41:12,781 Toolkit-Applications. So a multi-IMSI application, in case 459 00:41:12,781 --> 00:41:17,570 somebody hasn't heard of that yet, is basically a SIM card that changes its 460 00:41:17,570 --> 00:41:23,800 IMSI depending on where your currently roam, in order to do a sort of least cost 461 00:41:23,800 --> 00:41:30,670 roaming agreement for the operator because if he uses his is real own IMSI, then 462 00:41:30,670 --> 00:41:34,250 maybe the roaming costs would be more extensive than if he used some kind of 463 00:41:34,250 --> 00:41:38,060 borrowed IMSI from another operator that then gets provisioned there, which has a 464 00:41:38,060 --> 00:41:41,740 better roaming agreement and would work around ridiculous roaming charges - at 465 00:41:41,740 --> 00:41:46,560 least between the operators, of course, not towards the user. And now we get to 466 00:41:46,560 --> 00:41:58,410 the sort of premium feature of modern SIM cards where, of course. you can still do 467 00:41:58,410 --> 00:42:03,780 SMS over LTE, but it's sort of this added- on kludge. USSD I think doesn't exist 468 00:42:03,780 --> 00:42:07,360 anymore because of the circuit-switch- feature. So you need some kind of new 469 00:42:07,360 --> 00:42:13,570 transport channel of how to talk to the SIM card. In release 9 they came up with 470 00:42:13,570 --> 00:42:19,120 something called over the air over HTTPS which is specified in global platform 2.2 471 00:42:19,120 --> 00:42:24,640 amendment B. You have to get that specific amendment as a separate document, it's at 472 00:42:24,640 --> 00:42:34,020 least free of charge. Actually it uses HTTP, nice and good, and then it uses 473 00:42:34,020 --> 00:42:39,550 something called PSK-TLS, that I've never heard of before, "pre-shared-keys with 474 00:42:39,550 --> 00:42:43,690 TLS". I mean, I'm not a TLS expert, as you can probably guess, but I don't think 475 00:42:43,690 --> 00:42:50,130 anyone ever with a normal browser would want to use pre-shared-keys. But it exists 476 00:42:50,130 --> 00:42:53,680 in the specs and there are several different cipher-modes that I've listed 477 00:42:53,680 --> 00:42:59,200 here which are permitted for Over-The-Air of HTTPS. Which subset to use is of course 478 00:42:59,200 --> 00:43:03,130 up to the operator because it's his SIM card talking to his server so they can do 479 00:43:03,130 --> 00:43:08,410 whatever they want there. The interesting part is that the IP in the TCP is 480 00:43:08,410 --> 00:43:14,070 terminated in the phone, and then whatever is inside the TCP stream gets passed to 481 00:43:14,070 --> 00:43:18,820 the card which implements the TLS and the HTTP inside. Then, inside HTTP you 482 00:43:18,820 --> 00:43:23,880 actually have hex string representations of the APDUs that the card normally 483 00:43:23,880 --> 00:43:28,690 processes. So you have this very interesting stack of different 484 00:43:28,690 --> 00:43:33,330 technologies and if you look at how exactly they use HTTP, you ask yourself 485 00:43:33,330 --> 00:43:37,190 why did they bother with HTTP in the first place if they modify it beyond 486 00:43:37,190 --> 00:43:44,870 recognition? But we'll see. So the way how this is implemented, interestingly, is 487 00:43:44,870 --> 00:43:56,670 that the card implements and HTTP client that performs HTTP-POST. So your card 488 00:43:56,670 --> 00:44:01,180 somehow by some external mechanism gets triggered: "Oh, you must connect to your 489 00:44:01,180 --> 00:44:04,610 management server now because the management server wants something from 490 00:44:04,610 --> 00:44:10,630 you". And then the card does an HTTP-POST over TLS with pre-shared-keys to the 491 00:44:10,630 --> 00:44:15,920 management server and then in the post response there is a hex-encoded APDU for 492 00:44:15,920 --> 00:44:20,190 the card to be executed by the card. Then, you have tons of additional HTTP-headerrs 493 00:44:20,190 --> 00:44:25,041 I'm not going to explain. The CRLF is just a copy and paste error. But you see there 494 00:44:25,041 --> 00:44:31,890 is all kinds of X-Admin-headers and it will completely not work with normal HTTP. So why 495 00:44:31,890 --> 00:44:37,080 use HTTP in that context, I don't really know. Yeah, I thought I had an example 496 00:44:37,080 --> 00:44:41,820 here, but I didn't put it up, I thought it's too much detail. But in the end, if 497 00:44:41,820 --> 00:44:50,040 you look at this, you'll need to write your own heavily modified HTTP-server 498 00:44:50,040 --> 00:44:58,070 anyway. but you have HTTP in there. Okay. Another technology, it's sort of random, I 499 00:44:58,070 --> 00:45:01,990 didn't really know where to put it in terms of ordering, is this S@T. 500 00:45:01,990 --> 00:45:07,380 technology, which is something really strange that's specified outside of the 501 00:45:07,380 --> 00:45:09,520 specification bodies that I mentioned before. 502 00:45:09,520 --> 00:45:13,300 It's another.., I'm just mentioning it because it's another vector that has more 503 00:45:13,300 --> 00:45:20,390 recently been exploited. Another vulnerability. Where, actually, let's say 504 00:45:20,390 --> 00:45:26,600 you don't want to run. You don't want to write a Java application to run on the 505 00:45:26,600 --> 00:45:32,360 card, but you still want to use SIM Toolkit. So your card, most likely inside 506 00:45:32,360 --> 00:45:38,540 a Java VM implements a VM for another bytecode, which is this S@T bytecode which 507 00:45:38,540 --> 00:45:41,730 gets basically pushed from the server into the card. 508 00:45:41,730 --> 00:45:47,410 So the card can then instruct your phone to display some menu to you. Hmm. Okay. 509 00:45:47,410 --> 00:45:51,720 Uh. Very exciting technology. I'm sure there was a use case for it at some point. 510 00:45:51,720 --> 00:45:57,090 I haven't really figured it out. So there is something called an S@T browser which 511 00:45:57,090 --> 00:46:00,860 runs inside the card. As I said, most likely that browser is implemented in Java 512 00:46:00,860 --> 00:46:04,590 running inside the Java VM. It's not a web browser, of course. It just called a 513 00:46:04,590 --> 00:46:11,720 browser and it parses this binary format which then creates SIM Toolkit menus or 514 00:46:11,720 --> 00:46:16,150 whatever. So yeah, I haven't really looked into detail. It's too strange even to look 515 00:46:16,150 --> 00:46:25,130 at it. Last but not least, we have something called the eSIM and Which many 516 00:46:25,130 --> 00:46:31,690 people may know as a particular. How can I say particularly dominant in 517 00:46:31,690 --> 00:46:38,410 the Apple universe where the SIM card is no longer a replaceable or exchangable 518 00:46:38,410 --> 00:46:43,910 plastic card with contacts. But it's actually soldered into the device. This 519 00:46:43,910 --> 00:46:49,300 package, a form factor, is called MFF2, the machine form factor. Not sure why it's 520 00:46:49,300 --> 00:46:57,030 two, I've never seen a one before and it's a very small like 8 pin package SMD 521 00:46:57,030 --> 00:47:00,950 package that gets sold on a circuit board. And of course, at that point you have to 522 00:47:00,950 --> 00:47:05,040 have some mechanism by which the actual profile, meaning the user identity, the 523 00:47:05,040 --> 00:47:09,230 keys and all the configuration parameters and so on can be updated or replaced 524 00:47:09,230 --> 00:47:14,280 remotely. And that in a way that will work between different operators which are 525 00:47:14,280 --> 00:47:18,960 competing in the industry and which don't really want to, you know, replace those 526 00:47:18,960 --> 00:47:23,561 profiles, at least not inherently. And this is why this is managed by the GSMA as 527 00:47:23,561 --> 00:47:30,520 an umbrella entity of all the operators. And it specifies an amazing number of 528 00:47:30,520 --> 00:47:36,120 acronyms. And trust me if I say that it is an amazing number of acronyms on how the 529 00:47:36,120 --> 00:47:39,710 cryptography and how the different entities and how the different interfaces 530 00:47:39,710 --> 00:47:44,402 work and all the different roles and the parties and each implementation of each 531 00:47:44,402 --> 00:47:49,870 party needs to be certified and approved and so on and so on. And in the end, you 532 00:47:49,870 --> 00:47:53,580 have a system by which after a letter of approval be 533 00:47:53,580 --> 00:47:59,411 tween operators and a new identity from a new operator can be downloaded in the card 534 00:47:59,411 --> 00:48:05,220 in a cryptographically secure way. So at least is the intent of the specification. 535 00:48:05,220 --> 00:48:11,370 I am not the person to judge on that and replace the profile, but it's not that 536 00:48:11,370 --> 00:48:15,520 like you as the owner of the device can do that. But it's just all the operators that 537 00:48:15,520 --> 00:48:21,340 are part of the club and are approved and certified by GSMA. Can actually add and or 538 00:48:21,340 --> 00:48:26,060 remove profiles and thus facilitate the transition from operator A to operator B 539 00:48:26,060 --> 00:48:30,500 in those cards. They don't only exist in the soldered form factor. You can also 540 00:48:30,500 --> 00:48:34,850 actually buy plastic cards that allow that. It's mostly used in like IoT 541 00:48:34,850 --> 00:48:39,500 devices, which I still call machine to machine. The old marketing term for that. 542 00:48:39,500 --> 00:48:46,140 So some random cellularly interconnected device that you want to remotely update. 543 00:48:46,140 --> 00:48:54,870 And as a final slide, the CCC event SIM cards that are around here. If you use the 544 00:48:54,870 --> 00:48:59,440 cellular networks, they are Java SIM and USIM cards. They support Over-The-Air and 545 00:48:59,440 --> 00:49:04,510 the, not the random update, but the remote application management. The remote 546 00:49:04,510 --> 00:49:09,340 file management at least via SMS-PP haven't tested anything else. It did for 547 00:49:09,340 --> 00:49:13,870 sure do not support HTTPS yet. And if you're interested in playing with any of 548 00:49:13,870 --> 00:49:17,940 that and writing your own Java applet, there's even a Hello World one around for 549 00:49:17,940 --> 00:49:21,830 several years that you can use as a starting point. You can get the keys for 550 00:49:21,830 --> 00:49:26,630 your specific card from the GSM team and then you can play with all of this in a 551 00:49:26,630 --> 00:49:33,390 way that normally only the operator can do with the card. Some hyperlinks which are 552 00:49:33,390 --> 00:49:37,870 actually hyperlinks on those slides. So you have to look at the PDF to see them. 553 00:49:37,870 --> 00:49:43,660 Yeah. And that brings me to the last slide and I'm very happy to see questions. 554 00:49:43,660 --> 00:49:54,450 Thanks. Herald: Thank you. Thank you so much. 555 00:49:54,450 --> 00:49:59,930 Actually, talks like this one is one of the main reasons I go to Congress, because 556 00:49:59,930 --> 00:50:06,570 sometimes I just take a dive into a topic I know nothing about and it's presented by 557 00:50:06,570 --> 00:50:10,880 a person with literally decades of experience in the field. 558 00:50:10,880 --> 00:50:16,400 So it's amazing. And we have time for questions. So keep them coming. And the 559 00:50:16,400 --> 00:50:21,390 first one is microphone number 4. Microphone 4: What you say makes me want 560 00:50:21,390 --> 00:50:29,210 to have a firewall between my phone and my SIM card. Is there a firewall? 561 00:50:29,210 --> 00:50:34,340 Harald: Not to my knowledge, really. I mean, there are some vendors of 562 00:50:34,340 --> 00:50:40,550 specifically secure telephones that say, well, we have a firewall sort of built-in. 563 00:50:40,550 --> 00:50:45,080 Not sure to what extent and what detail, but not as a separate product or a 564 00:50:45,080 --> 00:50:51,220 separate device. At some time people developed so-called interposer SIM cards, 565 00:50:51,220 --> 00:50:55,780 which you can slide between the SIM card and the phone, but that doesn't really 566 00:50:55,780 --> 00:51:00,880 work with you know Nano-SIM cards and so on anymore. And those interposers those 567 00:51:00,880 --> 00:51:07,850 were mostly used to avoid, you know, SIM locking and so on. But of course with such 568 00:51:07,850 --> 00:51:12,970 a device you could of course implement a firewall. Keep in mind that almost all of 569 00:51:12,970 --> 00:51:16,980 the communication. I mean the OTA may be encrypted, but all of the communication 570 00:51:16,980 --> 00:51:20,250 between the phone and the card is completely unauthenticated and 571 00:51:20,250 --> 00:51:24,450 unencrypted. So you can actually intercept and modify that as much as you want. And 572 00:51:24,450 --> 00:51:27,880 there's actually a project I forgot to mention in more detail. That's the 573 00:51:27,880 --> 00:51:31,850 osmocon project called SIM Trace, which is a device that you can actually 574 00:51:31,850 --> 00:51:36,150 put as a man in the middle to trace the communication between card and phone. 575 00:51:36,150 --> 00:51:40,620 Herald: Thank you. Mic one. Microphone 1: Could you please elaborate a 576 00:51:40,620 --> 00:51:47,740 little bit about the SIM Checker attack because the telephone provider said it's 577 00:51:47,740 --> 00:51:54,290 only possible if you have S@T browser on the SIM card and most claim they don't 578 00:51:54,290 --> 00:52:04,000 have. So do you have a feeling how many of SIM cards have a S@T browser and which are 579 00:52:04,000 --> 00:52:10,220 attackable or which other applications are attackable by the SIM Checker attack? 580 00:52:10,220 --> 00:52:16,790 Harald: I'm not involved in those attacks, so I cannot really comment on that in 581 00:52:16,790 --> 00:52:21,701 detail. But I know there is a tool available, an open source tool that is 582 00:52:21,701 --> 00:52:26,240 made available by SR Labs, which allows you to test cards. So if you want to check 583 00:52:26,240 --> 00:52:30,190 different cards, you can use that SIM tester. I think it's linked from the slide 584 00:52:30,190 --> 00:52:36,010 here. Yeah, the SR Labs SIM tester. That's a Java application. I don't have any 585 00:52:36,010 --> 00:52:41,810 figures or knowledge about this. In terms of the figures you're asking for. Sorry. 586 00:52:41,810 --> 00:52:48,380 Herald: Thank you. Let's take a question from the Internet next. Hi, Internet 587 00:52:48,380 --> 00:52:52,590 people. Signal Angel: There was a question, Can 588 00:52:52,590 --> 00:52:56,380 the eSIM can be seen as back to the roots, especially compared to what the U.S. 589 00:52:56,380 --> 00:53:03,380 market had in the early time? Harald: Um. Well, that refers to the 590 00:53:03,380 --> 00:53:08,340 situation that the identity is hardwired into the phone and not replaceable. And I 591 00:53:08,340 --> 00:53:14,640 think. No, not really, because it can be replaced and it can be replaced by any of 592 00:53:14,640 --> 00:53:19,040 the operate like the normal commercial operators. Of course, it means you cannot 593 00:53:19,040 --> 00:53:27,940 use such a device in, let's say, a private GSM network or in a campus network for 5G, 594 00:53:27,940 --> 00:53:34,270 which apparently everybody needs these days now. So there are limitations for 595 00:53:34,270 --> 00:53:39,240 such use cases. But in terms of the normal phones switching between operator A and 596 00:53:39,240 --> 00:53:46,070 operator B. That's exactly what the system is trying to solve. It's just that if 597 00:53:46,070 --> 00:53:52,560 you're not part of the club, you've lost. Herald: Thank you. The person behind Mic 5 598 00:53:52,560 --> 00:53:57,600 has a very nice hat and we're all about fashion here. So the next question 599 00:53:57,600 --> 00:54:00,010 goes to you. Harald: Nobody told me that. 600 00:54:00,010 --> 00:54:06,100 Microphone 5: *not understandable*'s mentor said not a Google one? And my 601 00:54:06,100 --> 00:54:12,750 question was answered, I think because I wanted to know what prevents a POC from 602 00:54:12,750 --> 00:54:18,950 providing an eSIM. Harald: A profile for an eSIM. Yes, that's 603 00:54:18,950 --> 00:54:23,010 exactly the problem that it needs in order to install it. It needs to be approved and 604 00:54:23,010 --> 00:54:26,881 signed and so on and so on. And you need to be part of that GSMA process. So first 605 00:54:26,881 --> 00:54:30,600 of all, you would have to technically implement all of that, which is doable in 606 00:54:30,600 --> 00:54:34,090 all specs of public. But then you need to get it certified, which is maybe 607 00:54:34,090 --> 00:54:38,560 less doable. And then finally since you're not a GSMA member and not an 608 00:54:38,560 --> 00:54:42,190 operator. You cannot become a GSMA member and you don't have the funds for it 609 00:54:42,190 --> 00:54:47,320 anyway. So that is certainly not going to work. But the POC could provide an actual 610 00:54:47,320 --> 00:54:50,140 like a physical eSIM chip. So if somebody wants to 611 00:54:50,140 --> 00:54:57,270 do a hot air rework. That's easy, and I mean, you can buy them just like 612 00:54:57,270 --> 00:55:00,820 other SIM cards and then you have your identity inside. But of course, that 613 00:55:00,820 --> 00:55:02,970 doesn't really solve your problem, I suppose. 614 00:55:02,970 --> 00:55:07,020 Microphone 5: Okay. Herald: Thank you. No more people in cool 615 00:55:07,020 --> 00:55:10,830 hats. So you'll keep picking at random. Mic 7, please. 616 00:55:10,830 --> 00:55:18,500 Microphone 7: Thanks for the amazing talk. Um, I have a question about the flash 617 00:55:18,500 --> 00:55:25,480 file system on the cards. I've already worked with the cards on the file system 618 00:55:25,480 --> 00:55:31,700 level due for some files, you need to specify this. You would need to load. Do 619 00:55:31,700 --> 00:55:39,830 you need to do like a authentication tango provides a CH view like the PIN one and 620 00:55:39,830 --> 00:55:45,570 then you only have access to some of the files. And since cheap flash is built into 621 00:55:45,570 --> 00:55:51,670 those devices, my question is whether they are cheap hardware or software tricks to 622 00:55:51,670 --> 00:55:59,370 access the files or modify the files which are usually locked behind the PIN. 623 00:55:59,370 --> 00:56:04,710 Harald: Not that I'm aware of. And if I would say they are rather specific to the 624 00:56:04,710 --> 00:56:10,570 given OS or whatever on the cards and as so many out there. So I think it's 625 00:56:10,570 --> 00:56:15,510 unlikely in terms of write cycles, you can typically buy between one hundred thousand 626 00:56:15,510 --> 00:56:19,800 five hundred thousand write cycle flash in SIM card chips. That's sort of what the 627 00:56:19,800 --> 00:56:25,080 industry sells. But then of course you have all kinds of weird leveling and then 628 00:56:25,080 --> 00:56:29,600 there are algorithms and SIM card operating systems even go as far as to 629 00:56:29,600 --> 00:56:35,490 like you can specify which files are more like the update frequencies. So it will 630 00:56:35,490 --> 00:56:39,340 use different algorithms for managing the flash there. But an interesting anecdote 631 00:56:39,340 --> 00:56:45,690 for that if we have the minute. And I was involved openmoko. Some people may 632 00:56:45,690 --> 00:56:52,870 remember that was an open source smartphone in 2007. And, um, there 633 00:56:52,870 --> 00:56:58,040 actually we had a bug in the baseband which would constantly keep rewriting some 634 00:56:58,040 --> 00:57:04,570 files on the flash of the SIM card. And actually we had some early adopters use us 635 00:57:04,570 --> 00:57:08,560 where the SIM cards got broken basically by constantly hammering them with write 636 00:57:08,560 --> 00:57:17,870 access. So, um. Yeah. But nothing that I know about any kind of, um. Access 637 00:57:17,870 --> 00:57:22,690 class bypass or something like that. Microphone 7: Thank you. 638 00:57:22,690 --> 00:57:27,640 Herald: Microphone 6, which I often neglect because the lights are blinding me 639 00:57:27,640 --> 00:57:30,910 when I look that way. Microphone 6: Um, thanks for the helpful 640 00:57:30,910 --> 00:57:38,070 talk. I have a twofold question. Um, so if I understand correctly your talk, it is 641 00:57:38,070 --> 00:57:42,950 impossible to know the code that's running on the same, right? So I have this 642 00:57:42,950 --> 00:57:49,810 twofold question is about going further, is there something buried in the specs to 643 00:57:49,810 --> 00:57:52,990 understand more concretely, this protocols? 644 00:57:52,990 --> 00:57:58,320 And is there any way to dump the code that's running on the SIMs? 645 00:57:58,320 --> 00:58:05,600 Harald: In terms of documentation, beyond the specs, there is one document that I 646 00:58:05,600 --> 00:58:09,440 always like very much to recommend, which is also linked here. Yes, the so-called 647 00:58:09,440 --> 00:58:13,340 SIM Alliance Stepping Stones. No idea why it's called that way, but that's how it's 648 00:58:13,340 --> 00:58:17,100 called, there's a hyperlink. So if you work on the slides, you can download it. 649 00:58:17,100 --> 00:58:20,125 That's a rather nice overview document 650 00:58:20,125 --> 00:58:22,810 about all the different specs and how it ties together. 651 00:58:22,810 --> 00:58:30,320 So I can recommend that. And in terms of towards to dump the code on the 652 00:58:30,320 --> 00:58:36,421 SIM card. I mean, yes, of course. Tools exist, but those tools are highly specific 653 00:58:36,421 --> 00:58:41,940 to the given smartcard operating system and or chip. And I'm not aware of any such 654 00:58:41,940 --> 00:58:47,320 tools ever having leaked. I mean, I get such tools for the cards that I in the 655 00:58:47,320 --> 00:58:55,651 company that I work, I work with. But yeah, of course, the SIM cards out in the 656 00:58:55,651 --> 00:59:00,210 field should be locked down from such tools and they are highly specific to the 657 00:59:00,210 --> 00:59:03,460 given OS and SIM. Microphone 6: OK. 658 00:59:03,460 --> 00:59:07,190 Herald: Thank you. Harald: So maybe one addition to that, 659 00:59:07,190 --> 00:59:16,340 it's normally made in a way that basically if you want to sort of reset the card or 660 00:59:16,340 --> 00:59:20,290 something. So there's always sort of once the card is in the operational lifecycle 661 00:59:20,290 --> 00:59:24,850 state, which is when you use it normally if you ever want to bypass some 662 00:59:24,850 --> 00:59:30,046 restriction or you want to sort of do something that is not permitted by the 663 00:59:30,046 --> 00:59:33,970 spec, by the by the permissions anymore, you have to sort of recycle the card and 664 00:59:33,970 --> 00:59:37,990 get it back into the so-called personalization lifecycle state. And most 665 00:59:37,990 --> 00:59:41,820 often that is done with a complete wipe, at least off the file system or with a 666 00:59:41,820 --> 00:59:45,760 complete wipe of the operating system. So you're back to the bootloader of the card 667 00:59:45,760 --> 00:59:48,330 and then you can basically start to recreate the card. 668 00:59:48,330 --> 00:59:52,590 But it's typically implemented in a way that it always is together with an erase. 669 00:59:52,590 --> 00:59:59,530 So they tried at least to make it safe. There's a question there, but not at the 670 00:59:59,530 --> 01:00:03,020 microphone. Oh there is a microphone. Oh, sorry. But yeah, your job. Sorry 671 01:00:03,020 --> 01:00:08,230 Herald: Yeah, I think the person behind Mic 4 has been standing there for ages. 672 01:00:08,230 --> 01:00:14,650 Microphone 4: You mentioned that the card can instruct the phone to open the 673 01:00:14,650 --> 01:00:22,790 website, but I have never seen this and I've seen use cases where I think it would 674 01:00:22,790 --> 01:00:28,930 be useful to do this. So is this not supported in most OSes or why? 675 01:00:28,930 --> 01:00:36,000 Harald: It's a good question, actually. If you read all those specs, like especially 676 01:00:36,000 --> 01:00:40,960 these proactive SIM specs and so on. I always have the original: OK it's all very 677 01:00:40,960 --> 01:00:46,210 interesting, but I've never seen anything like that anywhere." So I completely agree 678 01:00:46,210 --> 01:00:52,200 with you. Whether or not it's supported by the phones is a good question. And I think 679 01:00:52,200 --> 01:00:55,970 without trying, there's no way to know. So you would actually have to write on a 680 01:00:55,970 --> 01:01:01,420 small extend a Hello World app and to to do that and see and do a testing with 681 01:01:01,420 --> 01:01:09,270 various phones. I would fear that since it's a feature that's specified but rarely 682 01:01:09,270 --> 01:01:13,130 used, a lot of devices will not support it or not support it properly because it's 683 01:01:13,130 --> 01:01:16,790 never tested, because nobody's ever asked about testing it. But that's just my 684 01:01:16,790 --> 01:01:22,710 guess. Herald: Thank you, Mic 1. 685 01:01:22,710 --> 01:01:29,130 Microphone 1: OK. Hello. Um, my question is, when you have an eSIM and you want 686 01:01:29,130 --> 01:01:35,580 to provisioning it. Could it be done with TR-069 or something similar? 687 01:01:35,580 --> 01:01:42,520 Harald: No. That's a completely different set of protocols that are used for that. 688 01:01:42,520 --> 01:01:48,740 And that's that relates to this, global platform, 2.2 and XP, I think 689 01:01:48,740 --> 01:01:52,660 it was. Yeah, I don't find it right now. But there's this spec that specifies all 690 01:01:52,660 --> 01:01:56,290 the different interfaces and protocols that are used between the elements and 691 01:01:56,290 --> 01:02:00,580 it's completely different. I think also the requirements are very different 692 01:02:00,580 --> 01:02:03,870 because you have these multiple stakeholders. So you have the original 693 01:02:03,870 --> 01:02:09,010 card issuer, the original operator, then you have other operators. And it's not 694 01:02:09,010 --> 01:02:14,250 like a single entity that just wants to provision its devices, but it's sort of a 695 01:02:14,250 --> 01:02:18,930 multi stakeholder approach where you want to make sure that even in like a 696 01:02:18,930 --> 01:02:22,900 competition between operators still this is possible and that people for trust in 697 01:02:22,900 --> 01:02:27,290 the system, that even if the original issuing operator doesn't like the other 698 01:02:27,290 --> 01:02:30,770 operator, it still will work and it will even work in 10 years from now or 699 01:02:30,770 --> 01:02:35,000 something in where it's in the field. So I think the requirements are different. 700 01:02:35,000 --> 01:02:42,670 Herald: Thank you. That was the last question of the last talk of the day. 701 01:02:42,670 --> 01:02:47,010 Harald: Luckily, not the last day. Herald: Not the last day, the first day. 702 01:02:47,010 --> 01:02:50,150 So there's three more days ahead of us. Thank you. 703 01:02:50,150 --> 01:02:56,125 *Applause* 704 01:02:56,125 --> 01:03:17,838 *Music*