1 00:00:00,000 --> 00:00:12,443 *applause* 2 00:00:12,443 --> 00:00:15,936 Karsten: Thank you very much and a very good evening. 3 00:00:15,936 --> 00:00:21,264 We're here yet again to talk about mobile network attacks, and we're going to give this talk 4 00:00:21,264 --> 00:00:23,674 a somewhat different spin. 5 00:00:23,674 --> 00:00:31,834 Instead of focusing on giving out new vulnerabilities, and then hinting at how a fix could be, 6 00:00:31,834 --> 00:00:36,601 and suggesting that somebody else would be responsible for implementing these fixes. 7 00:00:36,601 --> 00:00:42,530 We wanna look at those later stages of the attack evolution today. 8 00:00:42,530 --> 00:00:50,130 And make sure we don't keep re-creating new results while old ones are not being resolved yet. 9 00:00:50,130 --> 00:00:53,150 Rest assured there will also be new attacks. 10 00:00:53,150 --> 00:00:56,391 We need to deliver on that every year. 11 00:00:56,391 --> 00:01:05,437 But we want to make sure specifically, to introduce some dynamics that help everybody, 12 00:01:05,437 --> 00:01:09,422 for networks to become more secure. 13 00:01:09,422 --> 00:01:18,509 My primary goal today is to enable all of you to help with that evolution, and to do some of the research 14 00:01:18,509 --> 00:01:22,550 that we've been doing in Berlin so far, all over the world. 15 00:01:22,550 --> 00:01:30,996 There will be a couple of tool releases, and a couple of, hopefully, evolution drivers 16 00:01:30,996 --> 00:01:38,175 In the end, for us security researchers to be successful in making the world better, we need industry. 17 00:01:38,175 --> 00:01:45,141 As painful as that sounds, we need somebody to put in a fix, and we haven't been very good 18 00:01:45,141 --> 00:01:50,906 about keeping check on those people that need to put in fixes for the research that we've been doing 19 00:01:50,906 --> 00:01:55,683 over the last couple of years, and we're going to complete the picture today. 20 00:01:55,683 --> 00:02:05,201 by talking a little bit about what networks have been doing around research in two areas. 21 00:02:05,201 --> 00:02:12,189 SIM card attacks, a topic of this year where networks found themselves in a critical situation 22 00:02:12,189 --> 00:02:19,696 at risk of large parts of the subscriber base being remotely infected, not in the phone, but in the SIM card. 23 00:02:19,696 --> 00:02:27,489 So there has been fruitful discussion with industry, and lots of responses, but not enough. 24 00:02:27,489 --> 00:02:32,951 Much more so around GSM intercept, a topic that probably the NSA discussions have moved 25 00:02:32,951 --> 00:02:38,938 into everbodys mind again, but one that was really luring for a decade now, that anybody can 26 00:02:38,938 --> 00:02:41,935 intercept your phonecalls at any time. 27 00:02:41,935 --> 00:02:46,354 and again, here we want to check on the network operators, and make sure that they are 28 00:02:46,354 --> 00:02:53,380 forced into putting in the protection that we deserve. 29 00:02:53,380 --> 00:03:00,408 We first discussed SIM card attacks publicly in August of this year, after a few months of 30 00:03:00,408 --> 00:03:08,967 responsible disclosure, and we found a combination of three vulnerabilities, 31 00:03:08,967 --> 00:03:15,800 that led to a potentially terrible situation for networks. 32 00:03:15,800 --> 00:03:23,639 The first fragment that we found was the ability to send binary text messages from one subscriber 33 00:03:23,639 --> 00:03:30,434 to really any other subscriber, so networks allowed traffic that has no place to be routed 34 00:03:30,434 --> 00:03:36,474 through networks, there's no such thing as network neutrality in mobile networks of course, 35 00:03:36,474 --> 00:03:42,566 they shouldn't be routing internal management applications through what basically is 36 00:03:42,566 --> 00:03:46,783 the IP space, or the phone number space of subscribers. 37 00:03:46,783 --> 00:03:52,691 The second thing we found is that the services that these messages reach on the SIM cards are 38 00:03:52,691 --> 00:04:01,828 often badly protected cryptographically. In particular we were finding lots of cards that used DES keys 39 00:04:01,828 --> 00:04:08,557 56-bit from the seventies, that has long been phased out in pretty much any other application. 40 00:04:08,557 --> 00:04:10,888 SIM cards still use old keys like that. 41 00:04:10,888 --> 00:04:17,940 And thirdly we found that applications you could install through those DES keys 42 00:04:17,940 --> 00:04:24,300 can break out of the sandbox of the Java protection parameter, and then access all kinds of data 43 00:04:24,300 --> 00:04:28,643 on the SIM card that no Java was supposed to access. 44 00:04:28,643 --> 00:04:36,203 And combining those three made for a remote SIM cloning vector at massive scale. 45 00:04:36,203 --> 00:04:40,889 And networks raced to fix those on at least two of the three layers. 46 00:04:40,889 --> 00:04:48,222 They put in filtering so the network, the SMS messages would not reach the phone any more. 47 00:04:48,222 --> 00:04:52,123 And they upgraded DES keys to triple DES keys. 48 00:04:52,123 --> 00:04:56,700 But most networks left it at that without really thinking through the problem and without really 49 00:04:56,700 --> 00:05:02,195 understanding the root causes of what made the SIM card so vulnerable. 50 00:05:02,195 --> 00:05:07,454 So I want to go into the first two categories, since the third one wasn't adressed even until today, and 51 00:05:07,454 --> 00:05:12,291 show how the industry response was in large part insufficient. 52 00:05:12,291 --> 00:05:17,519 And I shouldn't generalise as I do now, because some network operators have responded very 53 00:05:17,519 --> 00:05:23,783 responsibly, but by and large networks shrugged us off or put in quick fixes and then moved on to 54 00:05:23,783 --> 00:05:30,531 their daily business of making networks faster and faster and faster, but rarely more secure. 55 00:05:30,531 --> 00:05:36,583 So let's look at filtering first, and what goes wrong with filtering. 56 00:05:36,583 --> 00:05:43,808 Networks, many networks started filtering at around the time when we presented this publicly, 57 00:05:43,808 --> 00:05:51,795 around Black Hat and OHM camp, and they put in one specific filtering rule that was not surprisingly 58 00:05:51,795 --> 00:05:56,744 the exact message that we used in demonstrations at Black Hat and at OHM to demonstrate this 59 00:05:56,744 --> 00:06:04,185 class of vulnerabilities, but did not understand how much broader the vulnerabilty class is. 60 00:06:04,185 --> 00:06:13,957 So to put this in a comparison to computer security, if you tell somebody that they have a problem in a 61 00:06:13,957 --> 00:06:21,605 TCP stack, let's say in the linux implementation, and you demo it by sending packets to the ssh daemon, 62 00:06:21,605 --> 00:06:27,944 the fix that they implemented is to block port 22, not understanding that of course this exact same 63 00:06:27,944 --> 00:06:32,245 vulnerability is also present on any other exposed TCP service, 64 00:06:32,245 --> 00:06:37,805 And there's bunches of ways to format an SMS to reach the SIM card. 65 00:06:37,805 --> 00:06:44,513 Some have come out of the standard, others are just fragments of wrong implementations on phones. 66 00:06:44,513 --> 00:06:50,031 In particular some recent android phones will route pretty much anything to the SIM card. 67 00:06:50,031 --> 00:06:56,358 and that's pretty convenient, because the SIM card will look at the message and then discard it, if it's not 68 00:06:56,358 --> 00:06:59,520 properly formatted for a SIM card. 69 00:06:59,520 --> 00:07:02,866 So the implementor of the android phone took the easy way. 70 00:07:02,866 --> 00:07:07,503 Just put everything to the SIM card, it will decide what it wants and what it doesn't want. 71 00:07:07,503 --> 00:07:14,900 Of course with a phone like that no level of network filtering, no filtering whatever TCP port will protect it, 72 00:07:14,900 --> 00:07:19,485 Since normal user messages sometimes get forwarded to the phone. 73 00:07:19,485 --> 00:07:26,639 So the industry response was a bit insufficient here and we'd like to see more testing of networks 74 00:07:26,639 --> 00:07:34,265 and when we talk about tools we will perhaps enable you to do exactly that type of testing, 75 00:07:34,265 --> 00:07:39,600 The second area where the industry response falls way short of understanding the problem, 76 00:07:39,600 --> 00:07:45,193 again I'm generalising here, is that the configuration of the SIM cards. 77 00:07:45,193 --> 00:07:53,355 We did discuss the problem with DES keys, that you can break a 56-bit DES key in a minute or so using 78 00:07:53,355 --> 00:08:00,163 a rainbow table, and that of course, this is terrible if those services are reachable remotely. 79 00:08:00,163 --> 00:08:06,880 And networks then went in to look at configurations, and lot of them came out 80 00:08:06,880 --> 00:08:11,200 saying "We made sure everything is triple-DES on our SIM cards" 81 00:08:11,200 --> 00:08:19,334 or at least a few places there was still DES in older profiles, we patched them to now be triple-DES. 82 00:08:19,334 --> 00:08:24,698 Again that falls way short of understanding the core issue. 83 00:08:24,698 --> 00:08:29,200 Here's a bit of technical background so you can appreciate what's going on in the SIM card. 84 00:08:29,200 --> 00:08:34,778 There's a collection of keys, up to sixteen keysets, and each keyset can have keys for signing and 85 00:08:34,778 --> 00:08:40,239 encryption and so forth, and those keys have a specific type, DES or triple-DES for instance, 86 00:08:40,239 --> 00:08:43,751 sometimes even AES on very new cards. 87 00:08:43,751 --> 00:08:49,520 And then there's applications on the SIM card and these applications, there's up to sixteen million 88 00:08:49,520 --> 00:08:51,451 application identifiers. 89 00:08:51,451 --> 00:08:56,034 Of course no sixteen million applications fit on a card, so some of these are present on 90 00:08:56,034 --> 00:09:03,503 every SIM card, and the application gets to choose which keys get what level of access. 91 00:09:03,503 --> 00:09:08,291 And what seems to have happened in August is that the networks go through this first application, 92 00:09:08,291 --> 00:09:14,011 the standard application and make sure that triple-DES keys are required for signature or encryption or 93 00:09:14,011 --> 00:09:20,100 better, even both. And then the DES keys they had there, they upgraded to triple-DES. 94 00:09:20,100 --> 00:09:26,449 However we find in a surprisingly large number of SIM cards the following situation: 95 00:09:26,449 --> 00:09:35,201 One of the other sixteen million applications says we use this keyset, but we require none of it. 96 00:09:35,201 --> 00:09:41,982 So you send a command to that SIM TAR specifying this keyset, and you're not required to do 97 00:09:41,982 --> 00:09:44,783 signatures or encryption. 98 00:09:44,783 --> 00:09:50,690 And at that point it doesn't matter if you use triple-DES or AES or whatever algorithm, this SIM card 99 00:09:50,690 --> 00:09:54,633 will accept any command sent to it. 100 00:09:54,633 --> 00:09:59,646 And again that kind of being obvious to check for when you're going through your inventory of 101 00:09:59,646 --> 00:10:08,290 SIM cards, but that requires a deeper level of understanding of these attacks than most 102 00:10:08,290 --> 00:10:12,617 operators seem to have developed for this issue. 103 00:10:12,617 --> 00:10:19,619 So I hope this again helps to carry the point that to drive the co-evolution of attacks and defenses, 104 00:10:19,619 --> 00:10:26,878 industry is required to think through the attacks and understand what exactly the attack parameter is. 105 00:10:26,878 --> 00:10:40,766 To make sure it gets across very visually now, I'd like to get Luca to demo the attack as we think 106 00:10:40,766 --> 00:10:43,873 it would play out in the real world. 107 00:10:43,873 --> 00:10:50,925 and just as one sentence of introduction perhaps, this is coming from a very recent SIM card 108 00:10:50,925 --> 00:10:56,724 one that we picked up when we started playing with the iPhone 5 as fingerprint reader. 109 00:10:56,724 --> 00:11:05,887 It's just an US SIM card, and Luca, what are you going to do now? 110 00:11:08,507 --> 00:11:10,611 Can you switch on his microphone please? 111 00:11:10,611 --> 00:11:20,240 Luca: Ok, so as Karsten said we found this particularily interesting SIM card and 112 00:11:20,240 --> 00:11:28,257 the last one we found was very recent, it's a nano SIM and it goes into an iPhone 5. 113 00:11:28,257 --> 00:11:37,222 I'm going to show you what can we do to bypass the filterset operators have now. 114 00:11:37,222 --> 00:11:56,107 So we put it into the phone. I have here a BTS, that emulates the real operator network. 115 00:11:56,107 --> 00:12:01,193 Karsten: Of course that's a default way to bypass any type of filtering that the real network may be 116 00:12:01,193 --> 00:12:09,976 Luka: So now the mobile is connecting, and I'm trying to show you better, my BTS is sending some SMS's, 117 00:12:09,976 --> 00:12:18,341 as soon as the mobile is close to the BTS, and it tries to register, because it thinks it is 118 00:12:18,341 --> 00:12:27,983 the home network, I send my application, that is completly installed without any warning, 119 00:12:27,983 --> 00:12:31,209 or anything on the iPhone. 120 00:12:31,209 --> 00:12:34,358 *umm* 121 00:12:34,358 --> 00:12:42,825 I want to show you something here, so this is the first command and it's a delete, since I've already 122 00:12:42,825 --> 00:12:45,147 installed the application many times, I first delete it. 123 00:12:45,147 --> 00:12:46,931 and then I install it again. 124 00:12:46,931 --> 00:12:50,228 Karsten: So this is remote application management. 125 00:12:50,228 --> 00:12:54,430 On a recent SIM card, that requires no security whatsoever, you can put in 126 00:12:54,430 --> 00:13:00,863 whatever Java software you'd like to run on this SIM card. 127 00:13:00,863 --> 00:13:05,594 Luka: Ok, so it's finished, took a couple of seconds, ten seconds, I dunno. 128 00:13:05,594 --> 00:13:12,843 and now the SIM card is infected with a malware, that every five minutes sends the current location of 129 00:13:12,843 --> 00:13:18,370 the user to the attackers number. 130 00:13:18,370 --> 00:13:26,054 Since the iPhone doesn't show anything, I'm going to put this SIM card into another phone, 131 00:13:26,054 --> 00:13:32,171 so you can see it better, and you can also have a proof that it's on the SIM card. 132 00:13:38,244 --> 00:13:43,499 It's not very easy with the nano SIM into a normal phone. 133 00:13:43,499 --> 00:13:49,800 so this is the other phone, I have a ok.. 134 00:13:52,949 --> 00:13:57,640 Karsten: So the virus stays with the SIM card (when moved to) another phone 135 00:13:57,346 --> 00:14:02,158 Luka:I'm going to turn it on now. 136 00:14:05,450 --> 00:14:07,523 Yeah. 137 00:14:14,768 --> 00:14:20,530 Hopefully it will register to the home network. 138 00:14:26,293 --> 00:14:28,210 Yeah. 139 00:14:32,279 --> 00:14:34,768 Karsten: Is it still set to manual? 140 00:14:34,768 --> 00:14:37,623 Luka: Yeah, it did register. 141 00:14:43,109 --> 00:14:45,306 Yeah, 142 00:14:45,306 --> 00:14:50,674 So we are actually replaying the attack again, just for fun. 143 00:14:50,674 --> 00:14:53,461 Karsten: Oops. 144 00:14:56,631 --> 00:14:59,946 Luka: [sigh] Karsten: Bear with us, this is a complex demo 145 00:14:59,946 --> 00:15:05,107 lots of moving parts. Luka: What I can do is delete the SMS 146 00:15:08,563 --> 00:15:13,333 Luka: So is it showing someting now? 147 00:15:19,809 --> 00:15:23,372 Ok, I'll just try again. 148 00:15:25,987 --> 00:15:33,532 Oh, actually I have a better idea, so now I stop my fake BTS 149 00:15:33,532 --> 00:15:36,048 Karsten: yeah, better connect to the real network. 150 00:15:36,048 --> 00:15:40,093 Luka: and I let it connect to the real network. 151 00:15:50,844 --> 00:15:55,220 Okay. Let's see. 152 00:16:02,936 --> 00:16:07,168 Karsten: You're confident the virus got deployed the second time? 153 00:16:07,168 --> 00:16:12,691 Luka: Umm, that's actually a nice... 154 00:16:12,691 --> 00:16:16,933 Okay, yeah that was a. 155 00:16:16,933 --> 00:16:19,788 Karsten: Ok, lets come back to you in a couple of minutes then. 156 00:16:19,788 --> 00:16:23,365 When you've prepared this, but everybody got the idea roughly right, 157 00:16:23,365 --> 00:16:29,205 what should have happend; He's catching the phone or any of your phones really, 158 00:16:29,205 --> 00:16:35,140 he can test for vulnerabilities by sending SMS, hundreds of them, not sixteen million, 159 00:16:35,140 --> 00:16:40,230 he has to prepare a little bit, know where a vulnerability could be, and then once 160 00:16:40,230 --> 00:16:47,263 he finds an unprotected application, he just sends a bunch of binary SMSs and combine that Java file. 161 00:16:47,263 --> 00:16:52,717 and that java file installs on the SIM card and it stays installed on the SIM card, 162 00:16:52,717 --> 00:16:58,581 and it will every five minutes send the current location via SMS to his number, 163 00:16:58,581 --> 00:17:04,454 or do any other thing that the Java on the SIM card is allowed to do. 164 00:17:04,454 --> 00:17:11,719 It could even try to exploit the other parts of the SIM card through that unpatched Java vulnerability that 165 00:17:11,719 --> 00:17:17,799 a lot of these SIM cards still have. 166 00:17:17,799 --> 00:17:19,535 Installing the virus again? 167 00:17:19,535 --> 00:17:24,814 Luka: It's installing again. 168 00:17:27,646 --> 00:17:34,170 Luka: This was just the best case we found so you can actually install an application inside the SIM, 169 00:17:34,170 --> 00:17:41,843 in case this is not available, another choice is just reading the current ciphering key from the SIM. 170 00:17:43,329 --> 00:17:46,440 Karsten: Yeah, so there's a lot of these.. 171 00:17:46,440 --> 00:17:50,443 Luka: So this is the message I was waiting for. 172 00:17:50,443 --> 00:17:55,978 Karsten: So this older Nokia phone is the only phone we ever found that asked whether you allow your 173 00:17:55,978 --> 00:18:02,203 SIM card to send anything back to the attacker. The iPhone just does it by default without asking you. 174 00:18:02,203 --> 00:18:05,280 Luka: Press yes. 175 00:18:05,280 --> 00:18:10,806 *applause* 176 00:18:10,806 --> 00:18:13,940 Luka: Oh it's a bit small there. I try to copy 177 00:18:13,940 --> 00:18:16,446 Karsten: Did you want to show more Luka? 178 00:18:16,446 --> 00:18:26,224 Luka: Yeah the phone now sent the SMS to me, and I want to show how it looks like, so 179 00:18:26,224 --> 00:18:28,800 *hmm* no. 180 00:18:34,421 --> 00:18:39,429 Something like this? Nope 181 00:18:40,627 --> 00:18:41,299 *sighs* 182 00:18:41,299 --> 00:18:49,258 I want to enlarge this, so in this little field, there is the current network, the location area and cell-ID. 183 00:18:49,258 --> 00:18:55,509 So basically it's a very precise location information about the user. 184 00:18:55,509 --> 00:18:58,538 *applause* 185 00:18:58,538 --> 00:19:01,005 Karsten: thank you. 186 00:19:01,005 --> 00:19:04,145 *applause* 187 00:19:04,145 --> 00:19:10,049 Luka: And the best is that this message is not filtered by the operator since it's a normal text SMS. 188 00:19:10,049 --> 00:19:12,190 So it goes through. 189 00:19:12,190 --> 00:19:18,055 Karsten: So a persistant virus on a modern SIM card, I think that's what was needed to 190 00:19:18,055 --> 00:19:22,725 give the industry another nudge to deeply understand this. 191 00:19:22,725 --> 00:19:29,951 Now to create some further nudges from you all, and to fulfill that goal that I stated going in, 192 00:19:29,951 --> 00:19:38,240 to enable everybody to do these tests yourself, we wanna release a tool today that condenses all 193 00:19:38,240 --> 00:19:43,334 the SIM card knowledge that we collected over the last couple of years. 194 00:19:43,334 --> 00:19:51,183 It's an open source tool, written in Java, that was the easiest to speak to SIM cards with, and it tests 195 00:19:51,183 --> 00:19:58,536 for all the vulnerabilites we discussed in August, including things like triple-DES downgrade which 196 00:19:58,536 --> 00:20:02,509 a lot of operators seem to not have understood quite yet. 197 00:20:02,509 --> 00:20:07,535 But it also detects these more recent vulnerabilities. 198 00:20:07,535 --> 00:20:13,549 Now scanning these sixteen million possibilites on a SIM card, and each sixteen keys for them, 199 00:20:13,549 --> 00:20:17,372 that takes a long time, and some older slower SIM cards up to two weeks. 200 00:20:17,372 --> 00:20:25,515 So one thing the tool does is pre-select these TAR's smartly, so it only takes a couple of minutes. 201 00:20:25,515 --> 00:20:31,561 It does run on a normal smart card reader, PC/SC interface, as well as the Osmocom phone 202 00:20:31,561 --> 00:20:33,981 awesome opensource project also. 203 00:20:33,981 --> 00:20:39,125 We patched it a little bit to now act as a smartcard reader. So of course it can communicate 204 00:20:39,125 --> 00:20:40,502 with a SIM card. 205 00:20:40,502 --> 00:20:46,784 So if you have any of those; PC/SC reader or an Osmocom phone and a couple of minutes of time, 206 00:20:46,784 --> 00:20:51,271 download the software and please run the tests, make sure you're not affected, and if you are 207 00:20:51,271 --> 00:20:56,015 be very vocal to your network operator and demand that these things get removed. 208 00:20:56,015 --> 00:21:03,724 *applause* 209 00:21:03,724 --> 00:21:06,669 Thank you. 210 00:21:06,669 --> 00:21:13,760 Looking at similar technology or similar weaknesses, let's revisit the topic of GSM intercept, 211 00:21:13,760 --> 00:21:23,197 and I'll again try to make the point that networks may be casually interested in fixing some bugs that 212 00:21:23,197 --> 00:21:31,012 they may not have fully understood, so they only did half the fixes or not at all and again I think this is 213 00:21:31,012 --> 00:21:36,436 of high urgency, understanding now how many people are intercepting our phone calls. 214 00:21:36,436 --> 00:21:44,235 Network operators are supposed to protect us on all the frequencies we use and while 3G and 4G 215 00:21:44,235 --> 00:21:53,125 bring pretty ok cryptography with longer key lengths, most of our calls still go over 2G, 216 00:21:53,125 --> 00:21:54,873 this standard from the eighties. 217 00:21:54,873 --> 00:22:01,816 It's the only technology that can cover large areas, and even in cities where the cell sizes don't 218 00:22:01,816 --> 00:22:07,160 have to be so large, these frequencies have to get used because all frequencies are full. 219 00:22:07,160 --> 00:22:14,618 We have a frequency scarcity, so 2G frequencies are certainly still used by everybody, almost every day. 220 00:22:14,618 --> 00:22:20,230 and on 2G there are two different encryption standards that are found in the wild. 221 00:22:20,230 --> 00:22:27,280 There's A5/1, the first encryption cipher, the one that was originally invented along with GSM, back in 222 00:22:27,280 --> 00:22:34,635 the eighties, and then there's A5/3, a ten year old encryption standard, that's supported by 223 00:22:34,635 --> 00:22:40,541 newer phones, I would say about half the phones in current use support this A5/3 cipher. 224 00:22:40,541 --> 00:22:44,371 where the other ones will always default to A5/1. 225 00:22:44,371 --> 00:22:50,712 And the network would have to support both of them in a secure way or as secure as possible way 226 00:22:50,712 --> 00:22:54,277 to sufficiently protect their customers. 227 00:22:54,277 --> 00:22:58,563 Let's visit each of them in turn. 228 00:22:58,563 --> 00:23:08,142 To break A5/1 with tools like the ones we released some five years ago now, you have to have 229 00:23:08,142 --> 00:23:16,954 some attack surface. It's not enough to have a tool that can break an A5/1 packet, you also 230 00:23:16,954 --> 00:23:20,577 need to know what's inside the A5/1 packet. 231 00:23:20,577 --> 00:23:26,420 So for one of all these packets you have to predict the content, you break the key from it, and 232 00:23:26,420 --> 00:23:29,979 then you can decrypt the rest of them as well. 233 00:23:29,979 --> 00:23:33,916 So you've got to start somewhere to then break the rest of it. 234 00:23:33,916 --> 00:23:39,615 And I believe no spy agency would have a better way of breaking A5/1 over the air. 235 00:23:39,615 --> 00:23:42,946 They also have to rely on some attack surface. 236 00:23:42,946 --> 00:23:50,187 So if everything is unpredicable, it basically becomes XOR'ing random numbers. 237 00:23:50,187 --> 00:23:58,614 The GSMA and later the 3GPP, the standardisation bodies, that tried to make the mobile world 238 00:23:58,614 --> 00:24:05,635 a little bit more secure, they worked hard some five years ago to amend standards for 239 00:24:05,635 --> 00:24:08,045 this attack surface to go away. 240 00:24:08,045 --> 00:24:14,808 So in a standard trace as we see it in too many networks pretty much everything that is 241 00:24:14,808 --> 00:24:19,287 encrypted is predictable, at least in the call setup. 242 00:24:19,287 --> 00:24:28,238 So the phone starts unencrypted, it receives a ciphering mode command and it will then 243 00:24:28,238 --> 00:24:35,570 encrypt every single packet it sends, and also expect packets it receives to be encrypted, 244 00:24:35,570 --> 00:24:38,266 including some that actually make sense, where it 245 00:24:38,266 --> 00:24:42,732 says, "Here, you phone with that TMSI, have another TMSI", but also things are 246 00:24:42,732 --> 00:24:49,193 encrypted that carry not content whatsoever, like a null frame, that says the network is supposed to 247 00:24:49,193 --> 00:24:54,986 speak now, but it has nothing to say, but also things with static content, like these system information 248 00:24:54,986 --> 00:25:02,157 messages. This exact same message was sent maybe a second earlier unencrypted. 249 00:25:02,157 --> 00:25:08,829 And once it switches on encryption the phone expects this also to be encrypted. 250 00:25:08,829 --> 00:25:14,394 Then there's messages with very little content and again null frames. Things that bascially have 251 00:25:14,394 --> 00:25:19,299 no meaning whatsoever. Assignment to certain frequencies, there are not many frequencies 252 00:25:19,299 --> 00:25:25,546 to choose from so this is mostly predictable, and all of this is to be considered attack surface. 253 00:25:25,546 --> 00:25:30,453 And there are two standards, padding randomisation, which takes shorter messages and 254 00:25:30,453 --> 00:25:38,281 appends random bytes, and SI5 randomisation which takes longer messages but scrambles that content, 255 00:25:38,281 --> 00:25:41,533 that removes this attack surface almost entirely. 256 00:25:41,533 --> 00:25:48,643 The little bit of attack surface that's left is due to vendor specific communications, and 257 00:25:48,643 --> 00:25:51,783 this needs to be fixed vendor by vendor. 258 00:25:51,783 --> 00:25:58,794 But by just putting in those two standards, A5/1 calls should be protected from at least 259 00:25:58,794 --> 00:26:02,120 the tools that we can think of. 260 00:26:02,120 --> 00:26:07,118 Now given that this is five years ago that these were standardised and that there is a lot of 261 00:26:07,118 --> 00:26:14,872 pressure on security these days. You'd imagine that these fixes, just tiny software fixes, 262 00:26:14,872 --> 00:26:20,968 would be deployed thoroughly, however we rarely see networks that do either of them, 263 00:26:20,968 --> 00:26:24,266 and we've never seen a network that does both these fixes. 264 00:26:24,266 --> 00:26:29,730 So somewhere along the way, between the GSMA and 3GPP who write the standards 265 00:26:29,730 --> 00:26:33,242 and you as a customer, that idea got lost. 266 00:26:33,242 --> 00:26:38,893 And it's not a difficult idea, to throw in some random numbers, instead of static values, 267 00:26:38,893 --> 00:26:45,198 or to take a message and scramble its contents. These things should be pretty straight forward to 268 00:26:45,198 --> 00:26:50,613 implement, and we've seen both ideas in the wild, so there is proof that at least some vendors 269 00:26:50,613 --> 00:26:52,212 have implemented these features. 270 00:26:52,212 --> 00:26:58,033 However the networks do not seem to be using them at all. 271 00:26:58,033 --> 00:27:04,210 The same attack surface then would open up for A5/3 if somebody had a much bigger computer 272 00:27:04,210 --> 00:27:08,516 to decrypt it. And by much bigger I mean about a million dollars. 273 00:27:08,516 --> 00:27:14,530 So A5/3 is now ten years old and ten years ago it seemed like a great idea to take 274 00:27:14,530 --> 00:27:22,160 a 64-bit stream cipher and make a 64-bit block cipher out of it, you don't have to mess 275 00:27:22,160 --> 00:27:27,757 with key generation or anything, it becomes much more secure, and in fact it did, 276 00:27:27,757 --> 00:27:31,038 two million times more secure. 277 00:27:31,038 --> 00:27:37,537 But guess who's going to spend a million dollars to break your A5/3 encrypted call, this year right. 278 00:27:37,537 --> 00:27:44,437 and not just that one agency, every agency has a spare one million dollar to build an A5/3 cracker. 279 00:27:44,437 --> 00:27:49,496 So industry took ten years to implement this standard, and now that they do, 280 00:27:49,496 --> 00:27:54,990 in Germany for instance two networks just started this past month to roll out A5/3, 281 00:27:54,990 --> 00:27:57,819 now it's already outdated. 282 00:27:57,819 --> 00:28:03,124 Guess what, the next standard was developed five years ago again. A5/4 it's called, 283 00:28:03,124 --> 00:28:07,206 it blows up the key size to a good 128-bit, 284 00:28:07,206 --> 00:28:13,483 it steals that from the 3G part of the SIM card, but every SIM card these days is a 3G sim card. 285 00:28:13,483 --> 00:28:20,704 So somehow we are always ten years behind the state of the art in cryptography, and 286 00:28:20,704 --> 00:28:28,557 ten years behind what even industry describes, prescribes themselves to implement. 287 00:28:28,557 --> 00:28:35,111 We want that to change, and again we want you to help us change that by creating awareness 288 00:28:35,111 --> 00:28:39,040 around where networks put in what type of countermeasures. 289 00:28:39,040 --> 00:28:43,516 It's not enough for them to standardise padding randomisation and SI5 randomisation, 290 00:28:43,516 --> 00:28:49,286 It's not enough for them to specify A5/3 and A5/4, they actually need to deploy it. 291 00:28:49,286 --> 00:28:55,723 And here's three tools you can use to create some visibility. 292 00:28:55,723 --> 00:29:00,425 The first two we're releasing today, and the third one has always been available, there's just 293 00:29:00,425 --> 00:29:04,006 an incremental patch from us today. 294 00:29:04,006 --> 00:29:09,915 First one runs on an android phone and it allows you to record network traces. 295 00:29:09,915 --> 00:29:15,575 Those network traces of course tell you what type of encryption is used, whether keys get rolled over, 296 00:29:15,575 --> 00:29:22,070 whether your temporary identity gets changed regularly, and so forth. 297 00:29:22,070 --> 00:29:28,298 The second tool is basically the same running on a linux computer, if you want to have the data for 298 00:29:28,298 --> 00:29:37,110 further analysis, with the xgoldmontool, Tobias Engel's tool. 299 00:29:37,110 --> 00:29:41,420 And then the third possibility for aquiring the same data, not just for your own phone, but 300 00:29:41,420 --> 00:29:48,034 basically everybody in the cell you're connected to, is the OsmocomBB open source project. 301 00:29:48,034 --> 00:29:53,268 Sylvain put in a lot of work a few years ago and created this burst_ind branch, 302 00:29:53,268 --> 00:29:59,520 we extended it just a little bit to run much more stable and to really help as a capturing tool. 303 00:29:59,520 --> 00:30:06,438 So any of these tools now helps you to look at what configurations your network is using, 304 00:30:06,438 --> 00:30:11,631 and perhaps interpret this yourself, and to check whether they are using the latest 305 00:30:11,631 --> 00:30:13,655 encryption and what not. 306 00:30:13,655 --> 00:30:20,874 We'd much appreciate if you shared some of that information with us, and we could then again 307 00:30:20,874 --> 00:30:26,994 help other by sharing this further and interpreting the information, and to make that 308 00:30:26,994 --> 00:30:34,309 even easier, we put all these tool in a Live-ISO that you can put on a USB stick and boot 309 00:30:34,309 --> 00:30:40,010 with it. That has all the tools on it, the network measurement tools, it has the SIM tester on it, 310 00:30:40,010 --> 00:30:47,156 it has all the stuff on it, catch-a-catcher to find IMSI catchers in your vincinity. 311 00:30:47,156 --> 00:30:54,516 It has an option to send data to a website called gsmmap.org and along with all these tools we 312 00:30:54,516 --> 00:31:02,293 are releasing today, a new version of the GSM map website, much more colourful than before, 313 00:31:02,293 --> 00:31:05,604 but also much more usable we hope. 314 00:31:05,604 --> 00:31:15,868 So here's the new GSM map, and this now interprets a lot of network traces that many of you 315 00:31:15,868 --> 00:31:24,988 collected over the last couple of years, with Sylvains burst_ind setup, and for those countries where 316 00:31:24,988 --> 00:31:31,180 we have a little bit of data we do estimates, these are the striped countries here, 317 00:31:31,180 --> 00:31:40,710 and for those networks where we have a lot of data, we try to track the network security over time. 318 00:31:40,710 --> 00:31:46,247 So this for instance are the four german networks, and you see how over time they actually do change 319 00:31:46,247 --> 00:31:54,649 their security settings. T-Mobile for instance, the high-flyer here, they had a big drop in 320 00:31:54,649 --> 00:32:02,410 network security, intercept this is, by switching off some of the randomisation, earlier this year, but then 321 00:32:02,410 --> 00:32:08,644 after they did that they started rolling out A5/3, so somehow they're trading in security features, 322 00:32:08,644 --> 00:32:17,205 one for the other. This now on an aggregate level tells you how secure your network currently is, 323 00:32:17,205 --> 00:32:24,972 against intercept, basically spy agencies listening in to your calls, impersonation, that is other 324 00:32:24,972 --> 00:32:30,752 people using your phone identity to conduct some transaction, and against tracking, that is 325 00:32:30,752 --> 00:32:36,790 somebody following your whereabouts by electronic means. Basically information exposed through 326 00:32:36,790 --> 00:32:39,172 HLR queries remotely. 327 00:32:39,172 --> 00:32:42,867 And you see how networks differ in these catgories. 328 00:32:42,867 --> 00:32:48,404 This map by the way is where contributions came from. So a lot of these of course are collected 329 00:32:48,404 --> 00:32:50,954 by us in Berlin. 330 00:32:50,954 --> 00:32:55,484 But thank you so much to all of you who sent in all these traces from all these places that 331 00:32:55,484 --> 00:32:58,171 none of us have ever been to. 332 00:32:58,171 --> 00:33:03,059 So it's absolutely fabulous to see what coverage we've gained here. 333 00:33:03,059 --> 00:33:09,987 Still a lot of striped and white countries, so we hope to complete the picture, but 334 00:33:09,987 --> 00:33:11,520 we need everybody's help. 335 00:33:11,520 --> 00:33:17,546 And hopefully with the tools we released today it becomes so much easier to push 336 00:33:17,546 --> 00:33:21,735 data up here, that this will soon be filled a lot more. 337 00:33:21,735 --> 00:33:27,101 Now for those countries that we have a lot of data, and that is twenty-seven countries total, 338 00:33:27,101 --> 00:33:36,269 we are releasing detailed reports today also, that interpret these measurements and 339 00:33:36,269 --> 00:33:42,136 rank the networks, but also explain a little bit of how we measure these things, but then give you 340 00:33:42,136 --> 00:33:48,430 detailed technical measurements on what encryption is used, for what types of transactions are 341 00:33:48,430 --> 00:33:51,183 authenticated and so forth. 342 00:33:51,183 --> 00:33:52,771 *applause* 343 00:33:52,771 --> 00:33:53,524 Thank you. 344 00:33:53,524 --> 00:34:01,010 *applause* 345 00:34:01,010 --> 00:34:06,680 So if your country is one of the twenty-seven, we'd love if you read the report. 346 00:34:06,680 --> 00:34:12,324 If it isn't we'd love for you to download the tools and make sure we can publish a report next month. 347 00:34:12,324 --> 00:34:19,329 So these will be refreshed every month, hopefully forever, or until every network fulfills every 348 00:34:19,329 --> 00:34:22,967 security goal imaginable and then we will shut down our website. 349 00:34:22,967 --> 00:34:26,485 *laughter* 350 00:34:26,485 --> 00:34:35,967 So that's GSM Map, the new website, and you saw all the tools that are available now. 351 00:34:35,967 --> 00:34:42,290 You may notice that GSM map does not yet have a security metric on SIM cards. 352 00:34:42,290 --> 00:34:48,018 Just because our measurements are too sparse to paint a good picture. 353 00:34:48,018 --> 00:34:56,632 We'd like to start calling out the networks that do bad SIM card security, but again we need your help 354 00:34:56,632 --> 00:35:02,703 to scan your SIM cards, and to make sure we get some fair comparison among all the networks. 355 00:35:02,703 --> 00:35:09,200 Just as a heads up, we found about in every other network where we have a lot of SIM cards to test, 356 00:35:09,200 --> 00:35:12,194 vulnerabilites like the ones we discussed today. 357 00:35:12,194 --> 00:35:17,102 So there should be a good chance if you have couple of SIM cards at home, to find at least a few 358 00:35:17,102 --> 00:35:18,651 that are actually vulnerable. 359 00:35:18,651 --> 00:35:24,285 And if you do you can start installing Java on them and playing around with them. 360 00:35:24,285 --> 00:35:34,631 Allright, that was everything we wanted to discuss. A round of thank you, in particular to Lukas and Linus 361 00:35:34,631 --> 00:35:40,506 who have put in many months of really hard work to get these tools ready for release today, 362 00:35:40,506 --> 00:35:48,103 they were just about ready this morning after many months of working on them, so thanks to them. 363 00:35:48,103 --> 00:35:51,862 But thanks to everybody else also, who were involved. There's just a long list of people 364 00:35:51,862 --> 00:35:55,662 who contributed a month or two of work. 365 00:35:55,662 --> 00:36:02,578 Thanks to the open technology fund for sponsoring this research and for helping us fight 366 00:36:02,578 --> 00:36:10,784 bad security in the world and raising awareness around where bad security is implemented. 367 00:36:10,784 --> 00:36:18,004 Thank you to all of you for using our tools to take this research to places that we could not have imagined. 368 00:36:18,004 --> 00:36:19,070 Thanks. 369 00:36:19,070 --> 00:36:25,360 *applause* 370 00:36:25,360 --> 00:36:30,050 Herald: Thank you very much Karsten and Luca. So we have quite some time left, so as always if 371 00:36:30,050 --> 00:36:36,221 you have questions, in the room, please line up behind the four microphones on the ground floor. 372 00:36:36,221 --> 00:36:40,057 If you have questions from the web, or if you have questions on the streams, 373 00:36:40,057 --> 00:36:44,623 please write them on twitter or on IRC and we will ask them here live in the room. 374 00:36:44,623 --> 00:36:49,170 And I think we'll start with two questions from the internet please. 375 00:36:49,170 --> 00:36:51,963 Karsten: One quick... Signal angel: Okay Herald angel: Wait please. 376 00:36:51,963 --> 00:36:56,806 Karsten: One quick heads-up before the first people start leaving, if you're interested in playing 377 00:36:56,806 --> 00:37:02,326 with the tools or at least seeing them being played with there's a workshop that will start 378 00:37:02,326 --> 00:37:09,815 at six in Saal D, so if you want to see the live-ISO and all its components and perhaps 379 00:37:09,815 --> 00:37:15,333 take a USB stick home, we brought plenty to play with, saal D is where we'll meet you in a few 380 00:37:15,333 --> 00:37:18,225 minutes. Sorry, go ahead with the questions. 381 00:37:18,225 --> 00:37:20,896 Herald: Okay, two questions from the internet now. 382 00:37:20,896 --> 00:37:29,427 Signal angel: So first one: there are still many low hanging fruits, so what about SS7 networks, did you 383 00:37:29,427 --> 00:37:34,999 investigate them and their way of communicating with each other. Can you tell us anything what happened 384 00:37:34,999 --> 00:37:37,846 with the industry in the last year there? 385 00:37:37,846 --> 00:37:45,344 Karsten: Sure, yeah, SS7 is another decades old technology that was built with a wrong threat model. 386 00:37:45,344 --> 00:37:49,865 Basically everybody who connects to the network is trusted, but you have to connect to every 387 00:37:49,865 --> 00:37:56,205 other telco in the world to route calls to them, so there's some disagreement in the threat model. 388 00:37:56,205 --> 00:38:02,199 And people find SS7 vulnerabilites wherever they look, both in the configuration, stuff like, 389 00:38:02,199 --> 00:38:08,117 you know, the SIM filtering, the SMS filtering, the same kinds of topics come up in SS7, 390 00:38:08,117 --> 00:38:15,211 where of course you want to block unneeded traffic, and networks are really bad at that typically. 391 00:38:15,211 --> 00:38:21,796 But also people find implementation bugs on boxes that are connected to SS7 and those are 392 00:38:21,796 --> 00:38:23,974 really, really hard to research. 393 00:38:23,974 --> 00:38:29,491 The boxes are very expensive, so you can't just research it in isolation, and everybody who is 394 00:38:29,491 --> 00:38:36,480 running a box like that, will probably put you in jail if you ever attempted to break them, 395 00:38:36,480 --> 00:38:39,655 if you started to do some fuzz testing on them. 396 00:38:39,655 --> 00:38:47,182 So SS7 unfortunately isn't really prime for open research. It actually requires what I showed 397 00:38:47,182 --> 00:38:53,211 on the first slide, kind of a co-evolution where the networks let the hackers in, so that they 398 00:38:53,211 --> 00:38:57,834 then learn what other hackers could have done to them, and I don't see many networks 399 00:38:57,834 --> 00:39:00,579 to be ready for that yet. 400 00:39:00,579 --> 00:39:06,920 Definitely a topic with lots of low hanging fruit, but no easy way to research it. 401 00:39:06,920 --> 00:39:09,468 Signal angel: Okay, thank you. 402 00:39:09,468 --> 00:39:12,461 Signal Angel: Should we go on with the second one? Karsten: Yes 403 00:39:12,461 --> 00:39:18,051 Signal Angel:Has there been any testing using parallel application only SIM card overlay 404 00:39:18,051 --> 00:39:23,334 to block apps on the primary SIM card so that's probably a strange question, 405 00:39:23,334 --> 00:39:28,749 but the MuVuCo? project is mentioned here, or did you investigate any other simple way to block 406 00:39:28,749 --> 00:39:31,267 the Java card bits? 407 00:39:31,267 --> 00:39:37,281 Karsten: So I think I understood the question as, is there any easy way of putting in another layer 408 00:39:37,281 --> 00:39:42,798 of protection just in front of your SIM card? I guess we can't ask the person asking the question right? 409 00:39:42,798 --> 00:39:48,224 But if that were the question then the answer is, of course you can put all kinds of proxy stuff 410 00:39:48,224 --> 00:39:54,310 in between your phone and your SIM card, there's a nice open source project called SIMtrace, 411 00:39:54,310 --> 00:39:58,959 That then means you carry a little computer next to your phone whenever you use it and of course 412 00:39:58,959 --> 00:40:04,877 that's impractical, so that would be a forensic tool perhaps to investigate what people are currently 413 00:40:04,877 --> 00:40:08,519 doing to your SIM card, when you already have a suspicion that something is going on, but 414 00:40:08,519 --> 00:40:14,923 there's no practical way to get a phone to give you that level of access, even on android, the part of 415 00:40:14,923 --> 00:40:24,139 the operating system, the system that speaks with the SIM card is usually more baseband than android 416 00:40:24,139 --> 00:40:32,872 or at the very least a proprietary device driver type. So I can't think of any usable phone where 417 00:40:32,872 --> 00:40:38,690 you could easily implement a SIM card firewall for instance, but I'd love to learn about them 418 00:40:38,690 --> 00:40:41,748 if they do exist. 419 00:40:41,748 --> 00:40:45,331 Herald: Okay we take a question from microphone four. 420 00:40:45,331 --> 00:40:49,731 Question: Did you investigate any upstream vulnerabilities from or to the baseband 421 00:40:49,731 --> 00:40:56,437 or to the average phone OS, so for instance if you have infiltrated the SIM card can you do 422 00:40:56,437 --> 00:40:59,642 any stuff to an iPhone or something? 423 00:40:59,642 --> 00:41:05,764 Karsten: Good question, and no we haven't and I wouldn't think that that would be the most 424 00:41:05,764 --> 00:41:11,180 fruitful vector, because the interface between a SIM card and a phone is pretty defined, 425 00:41:11,180 --> 00:41:17,803 very narrow channel. So I'd think that a phone baseband is much easier exploited like Ralph did it 426 00:41:17,803 --> 00:41:23,780 a couple of years ago, emulating a network and sending commands, that interface is much wider 427 00:41:23,780 --> 00:41:28,773 and has many more protocols running that could potentially be exploit targets. 428 00:41:28,773 --> 00:41:30,678 Good question though, thank you. 429 00:41:30,678 --> 00:41:33,490 Herald: Okay, number three please. 430 00:41:33,490 --> 00:41:38,684 Question: You showed the map broken down by country, would it make sense to look at smaller 431 00:41:38,684 --> 00:41:44,377 districts or regions, do we have differences within one country for example the US. 432 00:41:44,377 --> 00:41:49,661 Karsten: That's a good question, and we have occasionally come across a country where 433 00:41:49,661 --> 00:41:54,336 there's configuration differences in different parts of the country, like for instance in Germany 434 00:41:54,336 --> 00:42:00,424 right now, two of the network operators are rolling out A5/3, but they go location by location. 435 00:42:00,424 --> 00:42:07,543 So there's two zones right now, but those are going away over time because the goal of course is 436 00:42:07,543 --> 00:42:13,782 to implement the security feature everywhere. There are networks though where they 437 00:42:13,782 --> 00:42:18,199 purchase one part of the country from one vendor and another part from another vendor, and 438 00:42:18,199 --> 00:42:23,347 where security patches just don't get deployed everywhere, and we would like to track that 439 00:42:23,347 --> 00:42:28,884 more accurately. Currently it's just averaged. What we need to track it more accurately is 440 00:42:28,884 --> 00:42:34,813 constant measurements from more places. So currently what our metric does is try to fairly 441 00:42:34,813 --> 00:42:40,133 combine information from different location and then average them even though for instance 442 00:42:40,133 --> 00:42:46,783 in Germany, of course Berlin is dominating in our measurement set, and some other locations 443 00:42:46,783 --> 00:42:52,780 I think, thank you CCC Munich, are contributing too, but if there were somewhere in 444 00:42:52,780 --> 00:42:59,170 the middle of Germany, some extra security feature, we would not learn about it for a long time. 445 00:42:59,170 --> 00:43:08,147 You see this route? This is from last years trip from Hamburg to Berlin, when everybody came to the CCC. *laughter* 446 00:43:08,147 --> 00:43:13,846 So we are not distinguishing by country yet, but if the information is ever there to see 447 00:43:13,846 --> 00:43:17,298 a clear border we'll definitely do that. 448 00:43:17,298 --> 00:43:20,001 Herald: Question from number four please. 449 00:43:20,001 --> 00:43:25,840 Question: Yes, I wanted to ask, you showed that you were simulating a BTS somewhere around 450 00:43:25,840 --> 00:43:31,968 the middle of the talk, and I was wondering where you using any of the known OpenBTS or OsmoBTS 451 00:43:31,968 --> 00:43:35,221 solutions or anything else? 452 00:43:35,221 --> 00:43:44,790 Luca: It's a patched version of OpenBSC. It's just a few lines, there is a nice function that triggers 453 00:43:44,790 --> 00:43:50,540 the software to send the SMS on queue for a user as soon as the user logs in, and as soon as 454 00:43:50,540 --> 00:43:55,789 the user does this I put a lot of SMS's in the queue, so I can send it. 455 00:43:55,789 --> 00:44:03,572 Karsten: Yeah there are OpenBSC, OpenBTS, OsmocomBB project, they are an enormous help in 456 00:44:03,572 --> 00:44:09,336 our research, we could have done none of this, had we had to implement all of this in open source. 457 00:44:09,336 --> 00:44:14,826 So they're very, very useful, and thank you to everybody who've contributed to them. 458 00:44:14,826 --> 00:44:17,231 Herald: Another question from number four please. 459 00:44:17,231 --> 00:44:22,730 Question: Banks and other organisations love to send one-time tokens via SMS, from what I 460 00:44:22,730 --> 00:44:32,658 understand the talk, would it be in the range of the regular criminal to exploit this and steal those tokens? 461 00:44:32,658 --> 00:44:39,995 Karsten: With GSM intercept yes, you can read other people's SMS when they're A5/1 encrypted, 462 00:44:39,995 --> 00:44:47,273 however you have to be close to them, in a proximity of let's say two kilometers, and it's probably 463 00:44:47,273 --> 00:44:52,957 unlikely that the person who infected your online banking credentials, stole them from your infected 464 00:44:52,957 --> 00:44:59,536 computer, is also your neighbour. Those two groups seem to overlap in locations. 465 00:44:59,536 --> 00:45:03,970 With the SIM card vulnerabilities though, you can do lots of stuff, you can send SMS, 466 00:45:03,970 --> 00:45:09,248 you can redirect calls, you can steal decryption keys, the only thing you can't do is read people's 467 00:45:09,248 --> 00:45:14,507 incoming SMS. So banks got lucky there. 468 00:45:14,507 --> 00:45:19,580 Q: Thanks Herald: We have another question from the internet. 469 00:45:19,580 --> 00:45:26,524 Q: Wouldn't it be easier to just reinvent maybe a more nerd driven mobile network from scratch, than 470 00:45:26,524 --> 00:45:32,612 to mess around with all this industry stuff that has piled up for years now? 471 00:45:32,612 --> 00:45:39,256 Karsten: Well, that's interesting, things do not really pile up as people imagine them, so the 472 00:45:39,256 --> 00:45:45,147 One of the big drivers of the OpenBSC project I understand was the availability of really cheap 473 00:45:45,147 --> 00:45:49,453 base stations. Why were they available? Because people threw them away and replaced 474 00:45:49,453 --> 00:45:53,858 them with newer base stations, and they do that every time they add a new technology. 475 00:45:53,858 --> 00:45:58,510 So when they added 3G they threw away the 2G base stations, and replaced them with combined 476 00:45:58,510 --> 00:46:02,210 2G/3G base stations, same with 4G now. 477 00:46:02,210 --> 00:46:07,693 So as 4G is being rolled out all over Germany, everything gets thrown away and 478 00:46:07,693 --> 00:46:14,046 replaced. There isn't so much legacy in terms of installed boxes, the legacy is more the protocol, 479 00:46:14,046 --> 00:46:21,523 so if you throw away one end of the connection and not the other you maintain the old protocol, 480 00:46:21,523 --> 00:46:26,685 but then when you throw away the other side, you again maintain it because it's kind of the logical 481 00:46:26,685 --> 00:46:36,922 legacy. So I don't think there's an easy fix to that. This is just very high-scalability engineering where 482 00:46:36,922 --> 00:46:43,963 things have to work in extreme corner cases, and I think all the tools are there for the existing networks 483 00:46:43,963 --> 00:46:50,521 to get fixed, it's just a question of priority. At the investment that a 4G network costs, a single one, 484 00:46:50,521 --> 00:46:56,704 you can probably make the entire world use A5/3 and upgrade to secure SIM cards. 485 00:46:56,704 --> 00:47:01,958 So the money is there, it's just a question of priority that keeps the networks away from 486 00:47:01,958 --> 00:47:04,223 deploying these software patches. 487 00:47:04,223 --> 00:47:07,718 In the end it's single lines of code. 488 00:47:07,718 --> 00:47:11,488 Herald: Ok, we have another question in the room from microphone number three. 489 00:47:11,488 --> 00:47:17,543 Q: Quick question, for tools that you are offering can they work with some kind of passive recording 490 00:47:17,543 --> 00:47:25,459 device, for example can you collect data for gsmmap using the OsmoSDR tools? The ones that use 491 00:47:25,459 --> 00:47:30,965 the simple DVB-tuners to listen to the spectrum. 492 00:47:30,965 --> 00:47:36,632 Harald: Luca, do you know OsmoSDR? Luca: Yeah, I think that's more focused on being 493 00:47:36,632 --> 00:47:42,823 a BTS than a sniffer device, but I think you can use it as a sniffer device, it's just that then you need 494 00:47:42,823 --> 00:47:49,433 to process the data in a different way, really the easiest is to use the Osmocom mobile phone, 495 00:47:49,433 --> 00:47:55,356 and it does this and it's what we use for the Live-ISO. There are many models actually, so. 496 00:47:55,356 --> 00:47:59,920 Karsten: What would you consider the advantage of using an OsmoSDR? 497 00:47:59,920 --> 00:48:04,865 Q:It's mostly because it doesn't require a phone or a SIM card or anything, The question is can it 498 00:48:04,865 --> 00:48:08,318 work passively without being, without sending anything? 499 00:48:08,318 --> 00:48:13,126 Karsten: Yeah, the phone he just held up, that captures traffic with no SIM card and 500 00:48:13,126 --> 00:48:21,204 without connecting to a network, it does so passively by latching on to a cell, passively, just hearing what 501 00:48:21,204 --> 00:48:27,964 is happening on the broadcast channel, and as soon as the cell starts communicating with another phone 502 00:48:27,964 --> 00:48:33,909 it jumps to that frequency and also listens to the traffic. So that's already a passive setup. 503 00:48:33,909 --> 00:48:40,173 And the C139 I think is the most available Osmocom phone, you can still get that for twelve dollars 504 00:48:40,173 --> 00:48:46,977 in China. So I don't think there's any reason to reimplement that for any other platform if there's 505 00:48:46,977 --> 00:48:49,181 already a twelve dollar solution. 506 00:48:49,181 --> 00:48:53,606 Q: Thank you. Herald: And we take another question from the internet 507 00:48:53,606 --> 00:48:57,905 Q: Actually some people are complaining that they have no signal in this room, could that be 508 00:48:57,905 --> 00:49:02,417 caused by you, or is the range not that large? 509 00:49:02,417 --> 00:49:08,636 Karsten: Well, we add choices for signal, we don't take them away, so this is just an additional BTS. 510 00:49:08,636 --> 00:49:10,143 *laughter* 511 00:49:10,143 --> 00:49:12,145 Q: Okay, thank you. 512 00:49:12,145 --> 00:49:18,027 Herald: Ok, are there any other questions, now is the time to ask. If not I ask you again 513 00:49:18,027 --> 00:49:21,779 for a warm round of applause for Karsten and Luca 514 00:49:21,779 --> 00:49:25,696 *applause*