applause Karsten: Thank you very much and a very good evening. We're here yet again to talk about mobile network attacks, and we're going to give this talk a somewhat different spin. Instead of focusing on giving out new vulnerabilities, and then hinting at how a fix could be, and suggesting that somebody else would be responsible for implementing these fixes. We wanna look at those later stages of the attack evolution today. And make sure we don't keep re-creating new results while old ones are not being resolved yet. Rest assured there will also be new attacks. We need to deliver on that every year. But we want to make sure specifically, to introduce some dynamics that help everybody, for networks to become more secure. My primary goal today is to enable all of you to help with that evolution, and to do some of the research that we've been doing in Berlin so far, all over the world. There will be a couple of tool releases, and a couple of, hopefully, evolution drivers In the end, for us security researchers to be successful in making the world better, we need industry. As painful as that sounds, we need somebody to put in a fix, and we haven't been very good about keeping check on those people that need to put in fixes for the research that we've been doing over the last couple of years, and we're going to complete the picture today. by talking a little bit about what networks have been doing around research in two areas. SIM card attacks, a topic of this year where networks found themselves in a critical situation at risk of large parts of the subscriber base being remotely infected, not in the phone, but in the SIM card. So there has been fruitful discussion with industry, and lots of responses, but not enough. Much more so around GSM intercept, a topic that probably the NSA discussions have moved into everbodys mind again, but one that was really luring for a decade now, that anybody can intercept your phonecalls at any time. and again, here we want to check on the network operators, and make sure that they are forced into putting in the protection that we deserve. We first discussed SIM card attacks publicly in August of this year, after a few months of responsible disclosure, and we found a combination of three vulnerabilities, that led to a potentially terrible situation for networks. The first fragment that we found was the ability to send binary text messages from one subscriber to really any other subscriber, so networks allowed traffic that has no place to be routed through networks, there's no such thing as network neutrality in mobile networks of course, they shouldn't be routing internal management applications through what basically is the IP space, or the phone number space of subscribers. The second thing we found is that the services that these messages reach on the SIM cards are often badly protected cryptographically. In particular we were finding lots of cards that used DES keys 56-bit from the seventies, that has long been phased out in pretty much any other application. SIM cards still use old keys like that. And thirdly we found that applications you could install through those DES keys can break out of the sandbox of the Java protection parameter, and then access all kinds of data on the SIM card that no Java was supposed to access. And combining those three made for a remote SIM cloning vector at massive scale. And networks raced to fix those on at least two of the three layers. They put in filtering so the network, the SMS messages would not reach the phone any more. And they upgraded DES keys to triple DES keys. But most networks left it at that without really thinking through the problem and without really understanding the root causes of what made the SIM card so vulnerable. So I want to go into the first two categories, since the third one wasn't adressed even until today, and show how the industry response was in large part insufficient. And I shouldn't generalise as I do now, because some network operators have responded very responsibly, but by and large networks shrugged us off or put in quick fixes and then moved on to their daily business of making networks faster and faster and faster, but rarely more secure. So let's look at filtering first, and what goes wrong with filtering. Networks, many networks started filtering at around the time when we presented this publicly, around Black Hat and OHM camp, and they put in one specific filtering rule that was not surprisingly the exact message that we used in demonstrations at Black Hat and at OHM to demonstrate this class of vulnerabilities, but did not understand how much broader the vulnerabilty class is. So to put this in a comparison to computer security, if you tell somebody that they have a problem in a TCP stack, let's say in the linux implementation, and you demo it by sending packets to the ssh daemon, the fix that they implemented is to block port 22, not understanding that of course this exact same vulnerability is also present on any other exposed TCP service, And there's bunches of ways to format an SMS to reach the SIM card. Some have come out of the standard, others are just fragments of wrong implementations on phones. In particular some recent android phones will route pretty much anything to the SIM card. and that's pretty convenient, because the SIM card will look at the message and then discard it, if it's not properly formatted for a SIM card. So the implementor of the android phone took the easy way. Just put everything to the SIM card, it will decide what it wants and what it doesn't want. Of course with a phone like that no level of network filtering, no filtering whatever TCP port will protect it, Since normal user messages sometimes get forwarded to the phone. So the industry response was a bit insufficient here and we'd like to see more testing of networks and when we talk about tools we will perhaps enable you to do exactly that type of testing, The second area where the industry response falls way short of understanding the problem, again I'm generalising here, is that the configuration of the SIM cards. We did discuss the problem with DES keys, that you can break a 56-bit DES key in a minute or so using a rainbow table, and that of course, this is terrible if those services are reachable remotely. And networks then went in to look at configurations, and lot of them came out saying "We made sure everything is triple-DES on our SIM cards" or at least a few places there was still DES in older profiles, we patched them to now be triple-DES. Again that falls way short of understanding the core issue. Here's a bit of technical background so you can appreciate what's going on in the SIM card. There's a collection of keys, up to sixteen keysets, and each keyset can have keys for signing and encryption and so forth, and those keys have a specific type, DES or triple-DES for instance, sometimes even AES on very new cards. And then there's applications on the SIM card and these applications, there's up to sixteen million application identifiers. Of course no sixteen million applications fit on a card, so some of these are present on every SIM card, and the application gets to choose which keys get what level of access. And what seems to have happened in August is that the networks go through this first application, the standard application and make sure that triple-DES keys are required for signature or encryption or better, even both. And then the DES keys they had there, they upgraded to triple-DES. However we find in a surprisingly large number of SIM cards the following situation: One of the other sixteen million applications says we use this keyset, but we require none of it. So you send a command to that SIM TAR specifying this keyset, and you're not required to do signatures or encryption. And at that point it doesn't matter if you use triple-DES or AES or whatever algorithm, this SIM card will accept any command sent to it. And again that kind of being obvious to check for when you're going through your inventory of SIM cards, but that requires a deeper level of understanding of these attacks than most operators seem to have developed for this issue. So I hope this again helps to carry the point that to drive the co-evolution of attacks and defenses, industry is required to think through the attacks and understand what exactly the attack parameter is. To make sure it gets across very visually now, I'd like to get Luca to demo the attack as we think it would play out in the real world. and just as one sentence of introduction perhaps, this is coming from a very recent SIM card one that we picked up when we started playing with the iPhone 5 as fingerprint reader. It's just an US SIM card, and Luca, what are you going to do now? Can you switch on his microphone please? Luca: Ok, so as Karsten said we found this particularily interesting SIM card and the last one we found was very recent, it's a nano SIM and it goes into an iPhone 5. I'm going to show you what can we do to bypass the filterset operators have now. So we put it into the phone. I have here a BTS, that emulates the real operator network. Karsten: Of course that's a default way to bypass any type of filtering that the real network may be Luka: So now the mobile is connecting, and I'm trying to show you better, my BTS is sending some SMS's, as soon as the mobile is close to the BTS, and it tries to register, because it thinks it is the home network, I send my application, that is completly installed without any warning, or anything on the iPhone. umm I want to show you something here, so this is the first command and it's a delete, since I've already installed the application many times, I first delete it. and then I install it again. Karsten: So this is remote application management. On a recent SIM card, that requires no security whatsoever, you can put in whatever Java software you'd like to run on this SIM card. Luka: Ok, so it's finished, took a couple of seconds, ten seconds, I dunno. and now the SIM card is infected with a malware, that every five minutes sends the current location of the user to the attackers number. Since the iPhone doesn't show anything, I'm going to put this SIM card into another phone, so you can see it better, and you can also have a proof that it's on the SIM card. It's not very easy with the nano SIM into a normal phone. so this is the other phone, I have a ok.. Karsten: So the virus stays with the SIM card (when moved to) another phone Luka:I'm going to turn it on now. Yeah. Hopefully it will register to the home network. Yeah. Karsten: Is it still set to manual? Luka: Yeah, it did register. Yeah, So we are actually replaying the attack again, just for fun. Karsten: Oops. Luka: [sigh] Karsten: Bear with us, this is a complex demo lots of moving parts. Luka: What I can do is delete the SMS Luka: So is it showing someting now? Ok, I'll just try again. Oh, actually I have a better idea, so now I stop my fake BTS Karsten: yeah, better connect to the real network. Luka: and I let it connect to the real network. Okay. Let's see. Karsten: You're confident the virus got deployed the second time? Luka: Umm, that's actually a nice... Okay, yeah that was a. Karsten: Ok, lets come back to you in a couple of minutes then. When you've prepared this, but everybody got the idea roughly right, what should have happend; He's catching the phone or any of your phones really, he can test for vulnerabilities by sending SMS, hundreds of them, not sixteen million, he has to prepare a little bit, know where a vulnerability could be, and then once he finds an unprotected application, he just sends a bunch of binary SMSs and combine that Java file. and that java file installs on the SIM card and it stays installed on the SIM card, and it will every five minutes send the current location via SMS to his number, or do any other thing that the Java on the SIM card is allowed to do. It could even try to exploit the other parts of the SIM card through that unpatched Java vulnerability that a lot of these SIM cards still have. Installing the virus again? Luka: It's installing again. Luka: This was just the best case we found so you can actually install an application inside the SIM, in case this is not available, another choice is just reading the current ciphering key from the SIM. Karsten: Yeah, so there's a lot of these.. Luka: So this is the message I was waiting for. Karsten: So this older Nokia phone is the only phone we ever found that asked whether you allow your SIM card to send anything back to the attacker. The iPhone just does it by default without asking you. Luka: Press yes. applause Luka: Oh it's a bit small there. I try to copy Karsten: Did you want to show more Luka? Luka: Yeah the phone now sent the SMS to me, and I want to show how it looks like, so hmm no. Something like this? Nope sighs I want to enlarge this, so in this little field, there is the current network, the location area and cell-ID. So basically it's a very precise location information about the user. applause Karsten: thank you. applause Luka: And the best is that this message is not filtered by the operator since it's a normal text SMS. So it goes through. Karsten: So a persistant virus on a modern SIM card, I think that's what was needed to give the industry another nudge to deeply understand this. Now to create some further nudges from you all, and to fulfill that goal that I stated going in, to enable everybody to do these tests yourself, we wanna release a tool today that condenses all the SIM card knowledge that we collected over the last couple of years. It's an open source tool, written in Java, that was the easiest to speak to SIM cards with, and it tests for all the vulnerabilites we discussed in August, including things like triple-DES downgrade which a lot of operators seem to not have understood quite yet. But it also detects these more recent vulnerabilities. Now scanning these sixteen million possibilites on a SIM card, and each sixteen keys for them, that takes a long time, and some older slower SIM cards up to two weeks. So one thing the tool does is pre-select these TAR's smartly, so it only takes a couple of minutes. It does run on a normal smart card reader, PC/SC interface, as well as the Osmocom phone awesome opensource project also. We patched it a little bit to now act as a smartcard reader. So of course it can communicate with a SIM card. So if you have any of those; PC/SC reader or an Osmocom phone and a couple of minutes of time, download the software and please run the tests, make sure you're not affected, and if you are be very vocal to your network operator and demand that these things get removed. applause Thank you. Looking at similar technology or similar weaknesses, let's revisit the topic of GSM intercept, and I'll again try to make the point that networks may be casually interested in fixing some bugs that they may not have fully understood, so they only did half the fixes or not at all and again I think this is of high urgency, understanding now how many people are intercepting our phone calls. Network operators are supposed to protect us on all the frequencies we use and while 3G and 4G bring pretty ok cryptography with longer key lengths, most of our calls still go over 2G, this standard from the eighties. It's the only technology that can cover large areas, and even in cities where the cell sizes don't have to be so large, these frequencies have to get used because all frequencies are full. We have a frequency scarcity, so 2G frequencies are certainly still used by everybody, almost every day. and on 2G there are two different encryption standards that are found in the wild. There's A5/1, the first encryption cipher, the one that was originally invented along with GSM, back in the eighties, and then there's A5/3, a ten year old encryption standard, that's supported by newer phones, I would say about half the phones in current use support this A5/3 cipher. where the other ones will always default to A5/1. And the network would have to support both of them in a secure way or as secure as possible way to sufficiently protect their customers. Let's visit each of them in turn. To break A5/1 with tools like the ones we released some five years ago now, you have to have some attack surface. It's not enough to have a tool that can break an A5/1 packet, you also need to know what's inside the A5/1 packet. So for one of all these packets you have to predict the content, you break the key from it, and then you can decrypt the rest of them as well. So you've got to start somewhere to then break the rest of it. And I believe no spy agency would have a better way of breaking A5/1 over the air. They also have to rely on some attack surface. So if everything is unpredicable, it basically becomes XOR'ing random numbers. The GSMA and later the 3GPP, the standardisation bodies, that tried to make the mobile world a little bit more secure, they worked hard some five years ago to amend standards for this attack surface to go away. So in a standard trace as we see it in too many networks pretty much everything that is encrypted is predictable, at least in the call setup. So the phone starts unencrypted, it receives a ciphering mode command and it will then encrypt every single packet it sends, and also expect packets it receives to be encrypted, including some that actually make sense, where it says, "Here, you phone with that TMSI, have another TMSI", but also things are encrypted that carry not content whatsoever, like a null frame, that says the network is supposed to speak now, but it has nothing to say, but also things with static content, like these system information messages. This exact same message was sent maybe a second earlier unencrypted. And once it switches on encryption the phone expects this also to be encrypted. Then there's messages with very little content and again null frames. Things that bascially have no meaning whatsoever. Assignment to certain frequencies, there are not many frequencies to choose from so this is mostly predictable, and all of this is to be considered attack surface. And there are two standards, padding randomisation, which takes shorter messages and appends random bytes, and SI5 randomisation which takes longer messages but scrambles that content, that removes this attack surface almost entirely. The little bit of attack surface that's left is due to vendor specific communications, and this needs to be fixed vendor by vendor. But by just putting in those two standards, A5/1 calls should be protected from at least the tools that we can think of. Now given that this is five years ago that these were standardised and that there is a lot of pressure on security these days. You'd imagine that these fixes, just tiny software fixes, would be deployed thoroughly, however we rarely see networks that do either of them, and we've never seen a network that does both these fixes. So somewhere along the way, between the GSMA and 3GPP who write the standards and you as a customer, that idea got lost. And it's not a difficult idea, to throw in some random numbers, instead of static values, or to take a message and scramble its contents. These things should be pretty straight forward to implement, and we've seen both ideas in the wild, so there is proof that at least some vendors have implemented these features. However the networks do not seem to be using them at all. The same attack surface then would open up for A5/3 if somebody had a much bigger computer to decrypt it. And by much bigger I mean about a million dollars. So A5/3 is now ten years old and ten years ago it seemed like a great idea to take a 64-bit stream cipher and make a 64-bit block cipher out of it, you don't have to mess with key generation or anything, it becomes much more secure, and in fact it did, two million times more secure. But guess who's going to spend a million dollars to break your A5/3 encrypted call, this year right. and not just that one agency, every agency has a spare one million dollar to build an A5/3 cracker. So industry took ten years to implement this standard, and now that they do, in Germany for instance two networks just started this past month to roll out A5/3, now it's already outdated. Guess what, the next standard was developed five years ago again. A5/4 it's called, it blows up the key size to a good 128-bit, it steals that from the 3G part of the SIM card, but every SIM card these days is a 3G sim card. So somehow we are always ten years behind the state of the art in cryptography, and ten years behind what even industry describes, prescribes themselves to implement. We want that to change, and again we want you to help us change that by creating awareness around where networks put in what type of countermeasures. It's not enough for them to standardise padding randomisation and SI5 randomisation, It's not enough for them to specify A5/3 and A5/4, they actually need to deploy it. And here's three tools you can use to create some visibility. The first two we're releasing today, and the third one has always been available, there's just an incremental patch from us today. First one runs on an android phone and it allows you to record network traces. Those network traces of course tell you what type of encryption is used, whether keys get rolled over, whether your temporary identity gets changed regularly, and so forth. The second tool is basically the same running on a linux computer, if you want to have the data for further analysis, with the xgoldmontool, Tobias Engel's tool. And then the third possibility for aquiring the same data, not just for your own phone, but basically everybody in the cell you're connected to, is the OsmocomBB open source project. Sylvain put in a lot of work a few years ago and created this burst_ind branch, we extended it just a little bit to run much more stable and to really help as a capturing tool. So any of these tools now helps you to look at what configurations your network is using, and perhaps interpret this yourself, and to check whether they are using the latest encryption and what not. We'd much appreciate if you shared some of that information with us, and we could then again help other by sharing this further and interpreting the information, and to make that even easier, we put all these tool in a Live-ISO that you can put on a USB stick and boot with it. That has all the tools on it, the network measurement tools, it has the SIM tester on it, it has all the stuff on it, catch-a-catcher to find IMSI catchers in your vincinity. It has an option to send data to a website called gsmmap.org and along with all these tools we are releasing today, a new version of the GSM map website, much more colourful than before, but also much more usable we hope. So here's the new GSM map, and this now interprets a lot of network traces that many of you collected over the last couple of years, with Sylvains burst_ind setup, and for those countries where we have a little bit of data we do estimates, these are the striped countries here, and for those networks where we have a lot of data, we try to track the network security over time. So this for instance are the four german networks, and you see how over time they actually do change their security settings. T-Mobile for instance, the high-flyer here, they had a big drop in network security, intercept this is, by switching off some of the randomisation, earlier this year, but then after they did that they started rolling out A5/3, so somehow they're trading in security features, one for the other. This now on an aggregate level tells you how secure your network currently is, against intercept, basically spy agencies listening in to your calls, impersonation, that is other people using your phone identity to conduct some transaction, and against tracking, that is somebody following your whereabouts by electronic means. Basically information exposed through HLR queries remotely. And you see how networks differ in these catgories. This map by the way is where contributions came from. So a lot of these of course are collected by us in Berlin. But thank you so much to all of you who sent in all these traces from all these places that none of us have ever been to. So it's absolutely fabulous to see what coverage we've gained here. Still a lot of striped and white countries, so we hope to complete the picture, but we need everybody's help. And hopefully with the tools we released today it becomes so much easier to push data up here, that this will soon be filled a lot more. Now for those countries that we have a lot of data, and that is twenty-seven countries total, we are releasing detailed reports today also, that interpret these measurements and rank the networks, but also explain a little bit of how we measure these things, but then give you detailed technical measurements on what encryption is used, for what types of transactions are authenticated and so forth. applause Thank you. applause So if your country is one of the twenty-seven, we'd love if you read the report. If it isn't we'd love for you to download the tools and make sure we can publish a report next month. So these will be refreshed every month, hopefully forever, or until every network fulfills every security goal imaginable and then we will shut down our website. laughter So that's GSM Map, the new website, and you saw all the tools that are available now. You may notice that GSM map does not yet have a security metric on SIM cards. Just because our measurements are too sparse to paint a good picture. We'd like to start calling out the networks that do bad SIM card security, but again we need your help to scan your SIM cards, and to make sure we get some fair comparison among all the networks. Just as a heads up, we found about in every other network where we have a lot of SIM cards to test, vulnerabilites like the ones we discussed today. So there should be a good chance if you have couple of SIM cards at home, to find at least a few that are actually vulnerable. And if you do you can start installing Java on them and playing around with them. Allright, that was everything we wanted to discuss. A round of thank you, in particular to Lukas and Linus who have put in many months of really hard work to get these tools ready for release today, they were just about ready this morning after many months of working on them, so thanks to them. But thanks to everybody else also, who were involved. There's just a long list of people who contributed a month or two of work. Thanks to the open technology fund for sponsoring this research and for helping us fight bad security in the world and raising awareness around where bad security is implemented. Thank you to all of you for using our tools to take this research to places that we could not have imagined. Thanks. applause Herald: Thank you very much Karsten and Luca. So we have quite some time left, so as always if you have questions, in the room, please line up behind the four microphones on the ground floor. If you have questions from the web, or if you have questions on the streams, please write them on twitter or on IRC and we will ask them here live in the room. And I think we'll start with two questions from the internet please. Karsten: One quick... Signal angel: Okay Herald angel: Wait please. Karsten: One quick heads-up before the first people start leaving, if you're interested in playing with the tools or at least seeing them being played with there's a workshop that will start at six in Saal D, so if you want to see the live-ISO and all its components and perhaps take a USB stick home, we brought plenty to play with, saal D is where we'll meet you in a few minutes. Sorry, go ahead with the questions. Herald: Okay, two questions from the internet now. Signal angel: So first one: there are still many low hanging fruits, so what about SS7 networks, did you investigate them and their way of communicating with each other. Can you tell us anything what happened with the industry in the last year there? Karsten: Sure, yeah, SS7 is another decades old technology that was built with a wrong threat model. Basically everybody who connects to the network is trusted, but you have to connect to every other telco in the world to route calls to them, so there's some disagreement in the threat model. And people find SS7 vulnerabilites wherever they look, both in the configuration, stuff like, you know, the SIM filtering, the SMS filtering, the same kinds of topics come up in SS7, where of course you want to block unneeded traffic, and networks are really bad at that typically. But also people find implementation bugs on boxes that are connected to SS7 and those are really, really hard to research. The boxes are very expensive, so you can't just research it in isolation, and everybody who is running a box like that, will probably put you in jail if you ever attempted to break them, if you started to do some fuzz testing on them. So SS7 unfortunately isn't really prime for open research. It actually requires what I showed on the first slide, kind of a co-evolution where the networks let the hackers in, so that they then learn what other hackers could have done to them, and I don't see many networks to be ready for that yet. Definitely a topic with lots of low hanging fruit, but no easy way to research it. Signal angel: Okay, thank you. Signal Angel: Should we go on with the second one? Karsten: Yes Signal Angel:Has there been any testing using parallel application only SIM card overlay to block apps on the primary SIM card so that's probably a strange question, but the MuVuCo? project is mentioned here, or did you investigate any other simple way to block the Java card bits? Karsten: So I think I understood the question as, is there any easy way of putting in another layer of protection just in front of your SIM card? I guess we can't ask the person asking the question right? But if that were the question then the answer is, of course you can put all kinds of proxy stuff in between your phone and your SIM card, there's a nice open source project called SIMtrace, That then means you carry a little computer next to your phone whenever you use it and of course that's impractical, so that would be a forensic tool perhaps to investigate what people are currently doing to your SIM card, when you already have a suspicion that something is going on, but there's no practical way to get a phone to give you that level of access, even on android, the part of the operating system, the system that speaks with the SIM card is usually more baseband than android or at the very least a proprietary device driver type. So I can't think of any usable phone where you could easily implement a SIM card firewall for instance, but I'd love to learn about them if they do exist. Herald: Okay we take a question from microphone four. Question: Did you investigate any upstream vulnerabilities from or to the baseband or to the average phone OS, so for instance if you have infiltrated the SIM card can you do any stuff to an iPhone or something? Karsten: Good question, and no we haven't and I wouldn't think that that would be the most fruitful vector, because the interface between a SIM card and a phone is pretty defined, very narrow channel. So I'd think that a phone baseband is much easier exploited like Ralph did it a couple of years ago, emulating a network and sending commands, that interface is much wider and has many more protocols running that could potentially be exploit targets. Good question though, thank you. Herald: Okay, number three please. Question: You showed the map broken down by country, would it make sense to look at smaller districts or regions, do we have differences within one country for example the US. Karsten: That's a good question, and we have occasionally come across a country where there's configuration differences in different parts of the country, like for instance in Germany right now, two of the network operators are rolling out A5/3, but they go location by location. So there's two zones right now, but those are going away over time because the goal of course is to implement the security feature everywhere. There are networks though where they purchase one part of the country from one vendor and another part from another vendor, and where security patches just don't get deployed everywhere, and we would like to track that more accurately. Currently it's just averaged. What we need to track it more accurately is constant measurements from more places. So currently what our metric does is try to fairly combine information from different location and then average them even though for instance in Germany, of course Berlin is dominating in our measurement set, and some other locations I think, thank you CCC Munich, are contributing too, but if there were somewhere in the middle of Germany, some extra security feature, we would not learn about it for a long time. You see this route? This is from last years trip from Hamburg to Berlin, when everybody came to the CCC. laughter So we are not distinguishing by country yet, but if the information is ever there to see a clear border we'll definitely do that. Herald: Question from number four please. Question: Yes, I wanted to ask, you showed that you were simulating a BTS somewhere around the middle of the talk, and I was wondering where you using any of the known OpenBTS or OsmoBTS solutions or anything else? Luca: It's a patched version of OpenBSC. It's just a few lines, there is a nice function that triggers the software to send the SMS on queue for a user as soon as the user logs in, and as soon as the user does this I put a lot of SMS's in the queue, so I can send it. Karsten: Yeah there are OpenBSC, OpenBTS, OsmocomBB project, they are an enormous help in our research, we could have done none of this, had we had to implement all of this in open source. So they're very, very useful, and thank you to everybody who've contributed to them. Herald: Another question from number four please. Question: Banks and other organisations love to send one-time tokens via SMS, from what I understand the talk, would it be in the range of the regular criminal to exploit this and steal those tokens? Karsten: With GSM intercept yes, you can read other people's SMS when they're A5/1 encrypted, however you have to be close to them, in a proximity of let's say two kilometers, and it's probably unlikely that the person who infected your online banking credentials, stole them from your infected computer, is also your neighbour. Those two groups seem to overlap in locations. With the SIM card vulnerabilities though, you can do lots of stuff, you can send SMS, you can redirect calls, you can steal decryption keys, the only thing you can't do is read people's incoming SMS. So banks got lucky there. Q: Thanks Herald: We have another question from the internet. Q: Wouldn't it be easier to just reinvent maybe a more nerd driven mobile network from scratch, than to mess around with all this industry stuff that has piled up for years now? Karsten: Well, that's interesting, things do not really pile up as people imagine them, so the One of the big drivers of the OpenBSC project I understand was the availability of really cheap base stations. Why were they available? Because people threw them away and replaced them with newer base stations, and they do that every time they add a new technology. So when they added 3G they threw away the 2G base stations, and replaced them with combined 2G/3G base stations, same with 4G now. So as 4G is being rolled out all over Germany, everything gets thrown away and replaced. There isn't so much legacy in terms of installed boxes, the legacy is more the protocol, so if you throw away one end of the connection and not the other you maintain the old protocol, but then when you throw away the other side, you again maintain it because it's kind of the logical legacy. So I don't think there's an easy fix to that. This is just very high-scalability engineering where things have to work in extreme corner cases, and I think all the tools are there for the existing networks to get fixed, it's just a question of priority. At the investment that a 4G network costs, a single one, you can probably make the entire world use A5/3 and upgrade to secure SIM cards. So the money is there, it's just a question of priority that keeps the networks away from deploying these software patches. In the end it's single lines of code. Herald: Ok, we have another question in the room from microphone number three. Q: Quick question, for tools that you are offering can they work with some kind of passive recording device, for example can you collect data for gsmmap using the OsmoSDR tools? The ones that use the simple DVB-tuners to listen to the spectrum. Harald: Luca, do you know OsmoSDR? Luca: Yeah, I think that's more focused on being a BTS than a sniffer device, but I think you can use it as a sniffer device, it's just that then you need to process the data in a different way, really the easiest is to use the Osmocom mobile phone, and it does this and it's what we use for the Live-ISO. There are many models actually, so. Karsten: What would you consider the advantage of using an OsmoSDR? Q:It's mostly because it doesn't require a phone or a SIM card or anything, The question is can it work passively without being, without sending anything? Karsten: Yeah, the phone he just held up, that captures traffic with no SIM card and without connecting to a network, it does so passively by latching on to a cell, passively, just hearing what is happening on the broadcast channel, and as soon as the cell starts communicating with another phone it jumps to that frequency and also listens to the traffic. So that's already a passive setup. And the C139 I think is the most available Osmocom phone, you can still get that for twelve dollars in China. So I don't think there's any reason to reimplement that for any other platform if there's already a twelve dollar solution. Q: Thank you. Herald: And we take another question from the internet Q: Actually some people are complaining that they have no signal in this room, could that be caused by you, or is the range not that large? Karsten: Well, we add choices for signal, we don't take them away, so this is just an additional BTS. laughter Q: Okay, thank you. Herald: Ok, are there any other questions, now is the time to ask. If not I ask you again for a warm round of applause for Karsten and Luca applause subtitles created by c3subtitles.de