1
00:00:09,210 --> 00:00:12,820
<i>applause</i>

2
00:00:12,820 --> 00:00:16,360
Karsten Nohl: Great to be back. Thank you
very much, talking once again on mobile

3
00:00:16,360 --> 00:00:21,080
security, taking two very different
angles, though, from what we talked about

4
00:00:21,080 --> 00:00:26,670
the last couple of years. This time we want
to dive into the same topic that Tobias

5
00:00:26,670 --> 00:00:31,890
Engel just did, looking at insecurities
that arise from the interconnect networks

6
00:00:31,890 --> 00:00:38,150
between different operators and we want to
add another angle. And that is how YOU

7
00:00:38,150 --> 00:00:43,190
can start self defending yourself from the
insecurities that many of your operators

8
00:00:43,190 --> 00:00:49,410
have left open for many years, including
the new ones that Tobias and myself talk

9
00:00:49,410 --> 00:00:56,190
about. If you do watch this on a download,
do go back and also watch Tobias's talk,

10
00:00:56,190 --> 00:01:00,110
it's well worth it and also covers a lot
of the basics that I'm just going to skip

11
00:01:00,110 --> 00:01:06,320
over now for the sake of time. Great talk,
by the way. Thank you Tobias. So aside

12
00:01:06,320 --> 00:01:17,460
from. <i>applause</i> Aside from those SS7
based attacks, we want to talk about 3G

13
00:01:17,460 --> 00:01:23,780
insecurities, not too many of them, but
severe as ever, as well as in the last

14
00:01:23,780 --> 00:01:30,210
chapter. Then a few tips, as well as a new
tool to help you start self defending

15
00:01:30,210 --> 00:01:36,320
against these mobile attacks. Now, just
briefly, then, what is the SS7 Network

16
00:01:36,320 --> 00:01:40,920
Tobias has already covered the basics. So
just a quick definition from me. It's this

17
00:01:40,920 --> 00:01:45,890
network that different mobile operators
are connected to, to exchange data among

18
00:01:45,890 --> 00:01:51,530
each other. For instance, text messages
are sent over this network. So without SS7,

19
00:01:51,530 --> 00:01:57,920
you couldn't be using this ancient chatting
technology SMS. Thank you SS7. But also

20
00:01:57,920 --> 00:02:05,280
more security relevant information is
exchanged over SS7. For instance, if you're

21
00:02:05,280 --> 00:02:10,530
using your phone in another country, as
many of you currently do, you still want

22
00:02:10,530 --> 00:02:15,510
this visiting network to be able to use
encryption with your phone, but how is that

23
00:02:15,510 --> 00:02:20,030
network going to know the right encryption
key? So this visiting network, the German

24
00:02:20,030 --> 00:02:24,190
network has to ask your home network for
the correct encryption key and that goes

25
00:02:24,190 --> 00:02:29,700
over SS7. And you can already see if
there's cryptographic information being

26
00:02:29,700 --> 00:02:33,560
exchanged, if the wrong people ask and
still receive an answer, insecurities

27
00:02:33,560 --> 00:02:39,950
arise. More interesting from a security
perspective, though, are messages that are

28
00:02:39,950 --> 00:02:46,099
exchanged within one network over SS7.
So SS7 is often misunderstood as this

29
00:02:46,099 --> 00:02:50,840
technology that's used for worldwide
exchange of information. The same network,

30
00:02:50,840 --> 00:02:54,640
though, is used inside an operator. So
there's no need for interconnect. There's

31
00:02:54,640 --> 00:03:01,290
already SS7 flows going on between those
different mobile switching centers, MSC.

32
00:03:01,290 --> 00:03:07,530
And each mobile switching center covers
one area, let's say a city. So imagine a

33
00:03:07,530 --> 00:03:13,340
situation where you are. You're in a call
and you're traversing from one area to

34
00:03:13,340 --> 00:03:17,110
another. You're crossing, let's say, your
state boundary. So there's new MSC,

35
00:03:17,110 --> 00:03:21,560
doesn't know how to handle your call. It
needs the decryption key for the already

36
00:03:21,560 --> 00:03:28,610
ongoing conversation. So there's another
SS7 message that allows you to query for

37
00:03:28,610 --> 00:03:33,650
the key of a transaction that's currently
going on. OK? And again, you can already

38
00:03:33,650 --> 00:03:38,739
see how if the wrong people send this type
of message and they receive an answer,

39
00:03:38,739 --> 00:03:46,730
insecurities arise. The insecurity that
that has most been talked about in recent

40
00:03:46,730 --> 00:03:52,670
years, again, up until Tobias's talk, was
tracking. And tracking was often understood

41
00:03:52,670 --> 00:03:57,720
as: There's this evil message, the any time
interrogation and The Washington Post

42
00:03:57,720 --> 00:04:01,621
focused a lot an article on just one
message. And it's a it's really evil. It

43
00:04:01,621 --> 00:04:06,451
should not been I have been ever
standardized. And whenever it's used, it's

44
00:04:06,451 --> 00:04:12,101
for evil purposes. There's no
usefulness in this message. And Tobias

45
00:04:12,101 --> 00:04:16,209
quoted a number that I think The
Washington Post found in a lot of

46
00:04:16,209 --> 00:04:21,709
marketing material, 70 percent of mobile
networks respond to this message. Now,

47
00:04:21,709 --> 00:04:26,000
this is information from earlier this year.
A lot of networks, very good news, have

48
00:04:26,000 --> 00:04:32,770
moved to to stop responding to anytime
interrogation message. This evil spying

49
00:04:32,770 --> 00:04:37,509
message is not being responded to by, for
instance, all German networks. You can't

50
00:04:37,509 --> 00:04:44,460
use this message in Germany anymore.
However, this is a very retroactive

51
00:04:44,460 --> 00:04:51,729
approach to securing SS7 because there's a
number of other messages that, consider them

52
00:04:51,729 --> 00:04:57,169
Gadgets, get you to the same place, take a
phone number and take you all the way to

53
00:04:57,169 --> 00:05:03,439
somebody's location. And here's just a
snapshot of of which messages you can use

54
00:05:03,439 --> 00:05:08,960
and Tobias went into a greater level of
detail in how these different messages

55
00:05:08,960 --> 00:05:13,689
come together. So if anybody thinks that
just barring anytime integration, you

56
00:05:13,689 --> 00:05:20,642
solved the tracking problem, they are wrong.
But at the same time, it's not that SS7 is

57
00:05:20,642 --> 00:05:26,900
not secureable. It's just a much larger
challenge that people consider currently

58
00:05:26,900 --> 00:05:33,869
to be. So you see how stringing
together some of these messages get you to

59
00:05:33,869 --> 00:05:39,039
intermediate values that also shouldn't be
public and then all the way to a cell ID.

60
00:05:39,039 --> 00:05:42,849
And up until all these messages or at
least every path that takes you from left

61
00:05:42,849 --> 00:05:49,759
to right is blocked by a network, tracking
to the same accuracy, to cell ID stays

62
00:05:49,759 --> 00:05:54,949
possible. Now, this is just one of many
areas in which SS7 can become an issue.

63
00:05:54,949 --> 00:06:03,559
Here is 4 more, it's an intercept risk.
If people can read your SMS text or listen

64
00:06:03,559 --> 00:06:08,169
to your calls, it's a denial of service
risk. If people cut you off from

65
00:06:08,169 --> 00:06:13,490
phone connectivity for anywhere from an
hour until the next location update or

66
00:06:13,490 --> 00:06:19,319
until your next reboot your phone, so you
can really cut people off badly from it,

67
00:06:19,319 --> 00:06:24,559
from the phone network. This area of fraud
that I don't think many people want to

68
00:06:24,559 --> 00:06:29,249
talk about publicly, certainly I don't.
But there's many fraud risks in SS7

69
00:06:29,249 --> 00:06:34,089
in which you can easily put charges
on somebody else's bill, or more

70
00:06:34,089 --> 00:06:39,899
interestingly, you can remove limits on
your own prepaid cards, basically run up

71
00:06:39,899 --> 00:06:46,240
infinite charges on prepaid cards and, you
know, running up a lot of bills to a two

72
00:06:46,240 --> 00:06:50,960
to premium numbers, for instance. And then
there's the risk of spamming, which from

73
00:06:50,960 --> 00:06:55,930
what I hear is already happening, SS7
based spam attacks. Now, for the sake of

74
00:06:55,930 --> 00:07:01,560
this talk, I want to focus on intercept,
which I consider aside from tracking the

75
00:07:01,560 --> 00:07:06,099
most intrusive and the most relevant for
us, just as a risk, they're more relevant

76
00:07:06,099 --> 00:07:09,649
for the network operators. And if they
don't solve them, well, so be it, as long

77
00:07:09,649 --> 00:07:14,469
as they foot the bill for it. So
intercept. And I want to go into three

78
00:07:14,469 --> 00:07:21,250
possible scenarios in which SS7 assisted
intercept can happen. The first abuses

79
00:07:21,250 --> 00:07:24,719
the exact message, as we looked at in the
introduction, these messages where

80
00:07:24,719 --> 00:07:29,889
different parts of networks ask each other
for encryption information and it's a

81
00:07:29,889 --> 00:07:35,860
pretty straightforward attack. You record
the airwaves. Around somebody in

82
00:07:35,860 --> 00:07:41,129
somebody's vicinity and you record
somebody's encrypted transaction as part of

83
00:07:41,129 --> 00:07:47,050
that, right? So and 3G transaction, for
instance, are pretty well secured, but

84
00:07:47,050 --> 00:07:53,080
they're not very hard to record. In fact,
3G is a little bit easier than 2G because

85
00:07:53,080 --> 00:07:58,039
it doesn't jump around all these
frequencies. So you record, let's say, 3G

86
00:07:58,039 --> 00:08:02,949
data and you have a bunch of transactions.
And all of them encrypted. And you can use

87
00:08:02,949 --> 00:08:09,939
this message over SS7 to decrypt them.
It's called Send ID. And as a as I said on

88
00:08:09,939 --> 00:08:16,129
one of the earlier slides, it's supposed
to be used when you're moving from one MFC

89
00:08:16,129 --> 00:08:20,810
into another MSC, but still within your
own network so that the call doesn't get

90
00:08:20,810 --> 00:08:27,099
disrupted. It's not supposed to be used
when when somebody foreign wants to

91
00:08:27,099 --> 00:08:31,779
query your phone, if they need a new
encryption key, a new call needs to start

92
00:08:31,779 --> 00:08:36,270
anyway. There's no way to hand over a call
from one operator to another operator

93
00:08:36,270 --> 00:08:43,209
without disruption. So this message is
used only for internal purposes. However,

94
00:08:43,209 --> 00:08:47,780
out of the four German operator earlier
this month, all four responded to this

95
00:08:47,780 --> 00:08:52,100
request coming from another country,
another country that doesn't even border

96
00:08:52,100 --> 00:08:57,170
Germany. So there's no way to even
conceptually think a call would be handed

97
00:08:57,170 --> 00:09:03,950
over. So four out of four. And that's not
an anomaly. Most networks require an

98
00:09:03,950 --> 00:09:08,940
international response to an
outside number when asked for the current

99
00:09:08,940 --> 00:09:14,030
decryption key. I'll show you a quick demo
on this at the end of this chapter.

100
00:09:14,030 --> 00:09:17,650
But I first finish the enumeration of
all the different possibilities in which

101
00:09:17,650 --> 00:09:24,920
3G calls can be intercepted. The second
one, the good old IMSI catchers, which we

102
00:09:24,920 --> 00:09:31,540
also wouldn't work on 3G. And I guess for
the most part they don't unless SS7

103
00:09:31,540 --> 00:09:36,010
comes to the help. So why don't they
work without SS7? An IMSI catcher

104
00:09:36,010 --> 00:09:42,070
pretends to be a base station. And if
it's 2G technology, the phone has no way

105
00:09:42,070 --> 00:09:47,720
of knowing the difference between the real
base station and a fake base station. But

106
00:09:47,720 --> 00:09:53,180
then 3G, the 3G standard introduced what I
call mutual authentication. So this time

107
00:09:53,180 --> 00:09:57,630
the base station has to prove to a phone
that in fact it's legitimate and unless it

108
00:09:57,630 --> 00:10:03,530
does that, the phone won't connect. Now,
this only solves part of the IMSI catcher

109
00:10:03,530 --> 00:10:08,530
problem. Just taken by the name even the
catching is still possible, IMSI catching

110
00:10:08,530 --> 00:10:14,660
in the sense of creating a list of all the
IMSIs in a location. Because there's

111
00:10:14,660 --> 00:10:19,150
certain chicken and egg problem.
If you want me as a base station to

112
00:10:19,150 --> 00:10:23,430
authenticate to you, you first have to
tell me who you are. There's no such thing

113
00:10:23,430 --> 00:10:28,370
as SSL or any type of public key on the
mobile network. It's all symmetric key. So

114
00:10:28,370 --> 00:10:32,900
you first have to tell me which key to use
and by that I know who you are. So IMSI

115
00:10:32,900 --> 00:10:36,811
catching is always possible. And that's why
if you Google for 3G IMSI catcher, those

116
00:10:36,811 --> 00:10:43,240
things exist. But they aren't capable of
recording phone calls or SMS because those

117
00:10:43,240 --> 00:10:49,080
then required a mutual authentication. They
aren't capable of doing so unless they ask

118
00:10:49,080 --> 00:10:55,960
over SS7 for an authentication key. So
IMSI catchers are back in the 3G world

119
00:10:55,960 --> 00:11:05,328
big time, unless we solve these SS7
problems, right? The third possibility of

120
00:11:05,328 --> 00:11:10,880
of intercept - this is probably the
scariest because it can happen completely

121
00:11:10,880 --> 00:11:15,470
remotely - Boaster once enumerated so far,
you have to be somewhere in the vicinity

122
00:11:15,470 --> 00:11:19,540
in the vicinity of somewhere. So the third
possibility, I want to call the rerouting

123
00:11:19,540 --> 00:11:24,640
attacks and they work in both directions.
Rerouting is the idea. And to be as

124
00:11:24,640 --> 00:11:31,270
touched on this, of taking… of taking
somebodies phone calls and changing

125
00:11:31,270 --> 00:11:36,799
the destination number so that, in fact,
you call somebody else unbeknownst to you,

126
00:11:36,799 --> 00:11:42,590
of course, as the victim. And this will
expose for incoming calls and outgoing

127
00:11:42,590 --> 00:11:46,600
calls, but using very different methods.
So it just kind of accidentally works in

128
00:11:46,600 --> 00:11:52,970
both directions. And this part, I just
briefly want to demonstrate to BSN that

129
00:11:52,970 --> 00:11:56,870
coordinated on most of this. But this
part, I guess we kind of misunderstood

130
00:11:56,870 --> 00:12:01,870
each other as we both showed us. I'll
keep this very brief. And the point I want

131
00:12:01,870 --> 00:12:07,998
to get across is that, one, a single SS7
message is already a big intercept

132
00:12:07,998 --> 00:12:15,660
problem. Let's see. Connected here. Um, so
I'll try not to make the same mistake as

133
00:12:15,660 --> 00:12:26,600
Tobias and try to cut off part of my
number here. So 31C3 demo phone.

134
00:12:26,600 --> 00:12:32,713
So I'm calling a a phone that in fact,
accidentally we left in. So … fuck

135
00:12:32,713 --> 00:12:36,190
<i> Laughter and applause</i>
<i> Ring-back tone starts </i>

136
00:12:36,190 --> 00:12:40,491
So I am calling this number and I don't 
know if you can hear it, but it's ringing.

137
00:12:40,491 --> 00:12:43,813
And we did leave his phone back in Berlin
accidentally. But for the sake of this

138
00:12:43,813 --> 00:12:48,100
demo, that makes no difference. So it's a 
it's a phone somewhere in Berlin. Nobody

139
00:12:48,100 --> 00:12:50,912
answers to. Here is another phone.

140
00:12:50,912 --> 00:12:52,002
<i> Ring-back tone stops </i>

141
00:12:52,002 --> 00:12:54,329
So if I if I register what they call a

142
00:12:54,329 --> 00:13:01,220
supplementary service to this number. And 
that's just fancy language for, for, for

143
00:13:01,220 --> 00:13:09,392
call forwarding, if I call this exact same
number again.

144
00:13:13,758 --> 00:13:16,659
<i> Ring-back tone starts </i>

145
00:13:16,659 --> 00:13:18,877
<i> Phone ringing also starts </i>

146
00:13:18,877 --> 00:13:21,140
This phone is ringing.

147
00:13:21,140 --> 00:13:23,930
<i> Applause </i>

148
00:13:23,930 --> 00:13:25,800
<i> Both ring-back and ring-tone stop </i>

149
00:13:25,800 --> 00:13:28,059
<i> Still applause </i>

150
00:13:28,059 --> 00:13:33,120
Now, of course, to make this real
intercept, I wouldn't forward it to a

151
00:13:33,120 --> 00:13:37,740
phone, I would forward it to a computer
that then is smart enough to very quickly

152
00:13:37,740 --> 00:13:43,960
erase the call forwarding and call the
original number and then connect it to so

153
00:13:43,960 --> 00:13:48,260
that the phone, the phone call actually
goes to where it was supposed to go. Just

154
00:13:48,260 --> 00:13:53,451
I'm sitting in the middle and I'm
receiving a copy of it. OK, so that's the

155
00:13:53,451 --> 00:13:57,710
idea in this direction, in the other
direction, the exact same thing works as

156
00:13:57,710 --> 00:14:03,875
well. And Tobias already told you how 
these services that say, let me rewrite

157
00:14:03,875 --> 00:14:07,510
your phone number for you because you 
don't know how to dial a phone number when

158
00:14:07,510 --> 00:14:12,279
you're on vacation. Right. Those services
can be set by anybody, at least on a lot

159
00:14:12,279 --> 00:14:16,880
of networks. And you can see how the exact
same thing works there so that every time

160
00:14:16,880 --> 00:14:21,430
you dial a number that just move their own
number in place of that number and then

161
00:14:21,430 --> 00:14:26,912
connect those two calls. So, as I said, I
consider those to the scariest type of

162
00:14:26,912 --> 00:14:30,680
attacks because they were completely
remotely you don't have to be in the radio

163
00:14:30,680 --> 00:14:35,140
vicinity of anybody. And surprisingly,
this still works against a bunch of

164
00:14:35,140 --> 00:14:41,690
networks, even against those networks that
move to solve some of the earlier issues.

165
00:14:41,690 --> 00:14:49,285
So networks [are] still very retroactive.
So what do what do those mobile networks

166
00:14:49,285 --> 00:14:54,920
now have to do to to solve those issues? 
Well, as always, of course, the answer:

167
00:14:54,920 --> 00:14:59,921
It depends. It depends in this case on the
tech type. Some of the techs can simply be

168
00:14:59,921 --> 00:15:05,710
blocked. Like the AnytimeInterrogation,
that earlier this year they said 70% of

169
00:15:05,710 --> 00:15:10,170
the networks are vulnerable. Now in
Germany it's zero. So something happened

170
00:15:10,170 --> 00:15:16,440
there. And the same is true for the for
the first type of attack that I've shown.

171
00:15:16,440 --> 00:15:20,550
The passive intercept I said when we
tested earlier this month for other four

172
00:15:20,550 --> 00:15:27,100
networks are vulnerable. Now it's down to
two. So within two weeks, two networks put

173
00:15:27,100 --> 00:15:33,970
in a firewall rule that says this message
has no purpose. Traversing our outside

174
00:15:33,970 --> 00:15:39,940
network boundary, just block it. The
typical firewall is the same isn't

175
00:15:39,940 --> 00:15:45,100
possible for these other two types of
attacks because those messages are

176
00:15:45,100 --> 00:15:50,550
actually useful. They do something, at
least in certain circumstances. If you

177
00:15:50,550 --> 00:15:55,210
block the second type of query here to
send authentication info, you couldn't be

178
00:15:55,210 --> 00:15:58,930
roaming in another country anymore. If you
blocked a third one, you couldn't be

179
00:15:58,930 --> 00:16:04,400
changing your your voice mail forwarding
from another country anymore. So these are

180
00:16:04,400 --> 00:16:10,390
needed. Still we couldn't, we can't accept
that just anybody who asks over SS7 ...

181
00:16:10,390 --> 00:16:11,990
<i> Phone ringing </i>
<i> Nohl sighs </i>

182
00:16:11,990 --> 00:16:15,658
You guys!
<i> Laughter </i>

183
00:16:15,658 --> 00:16:23,750
Switched this off. We can't accept
that just anybody who asks over SS7

184
00:16:23,750 --> 00:16:29,370
receives an answer, at the very least
we would expect networks to only answer to

185
00:16:29,370 --> 00:16:33,500
their friends on SS7, and
that is their roaming partners. That's

186
00:16:33,500 --> 00:16:38,980
already a lot fewer companies and
especially a lot fewer sketchy companies

187
00:16:38,980 --> 00:16:44,791
than everybody else on SS7. We would
then want those networks to do some

188
00:16:44,791 --> 00:16:51,390
plausibility checking. Right. So this does
phone in Berlin that just put a

189
00:16:51,390 --> 00:16:56,670
supplementary service on. The network
operator knows the phone is in Berlin and

190
00:16:56,670 --> 00:17:02,760
I send us from the other end of the world.
Still, they are not on it. Right. Any type

191
00:17:02,760 --> 00:17:08,310
of possibility checking what would clearly
see that this is not possible for a phone

192
00:17:08,310 --> 00:17:12,760
to be in one country and for this user to
want to change their voicemail setting

193
00:17:12,760 --> 00:17:17,809
from somewhere completely different. And
then thirdly, networks need to limit the

194
00:17:17,809 --> 00:17:22,020
rate at which this happens. Those services
that The Washington Post talked about is

195
00:17:22,020 --> 00:17:26,240
tracking services. These are large
operations. They seem to be tracking

196
00:17:26,240 --> 00:17:33,620
thousands of people, constantly. This will
show in logs, you don't allow some random

197
00:17:33,620 --> 00:17:38,300
network somewhere else in the world to
constantly interrogate hundreds of your

198
00:17:38,300 --> 00:17:44,200
users, right? It's clearly abuse. Has any
network move to put such sensible rules

199
00:17:44,200 --> 00:17:48,429
in? I'm not aware of it, but it's
certainly the next step. And I'm not ready

200
00:17:48,429 --> 00:17:54,860
to give up on SS7 yet. I've heard one too
many times that SS7 is an old technology

201
00:17:54,860 --> 00:18:01,389
built with no security in mind and we just
can't fix it. The Internet also is an old

202
00:18:01,389 --> 00:18:06,399
technology built was not secured in mind,
and we did fix it since the 90s, since

203
00:18:06,399 --> 00:18:10,679
when you connected to Windows 95 computer
to the Internet, it got infected with the

204
00:18:10,679 --> 00:18:16,580
virus right away. We have moved to put in
firewalls. We're not exposing our printer

205
00:18:16,580 --> 00:18:21,190
daemon and now file-sharing daemon on the 
entire Internet anymore for four billion

206
00:18:21,190 --> 00:18:25,680
people to connect to and the same as
possible on SS7. Which is, we we're still

207
00:18:25,680 --> 00:18:34,508
in the nineties. Thank you.
<i> Applause </i>

208
00:18:34,508 --> 00:18:38,484
Having said that though, let me show you
what what happens if we don't do that,

209
00:18:38,484 --> 00:18:46,972
the fun part. So. We argued whether or not
we wanted to show this as a live demo.

210
00:18:46,972 --> 00:18:50,096
You'll understand why we don't show it as
a live demo. There is just too much stuff

211
00:18:50,096 --> 00:18:54,470
that could go wrong. But here's the setup.
We start with just a phone number

212
00:18:54,470 --> 00:19:00,389
and we want to string together a couple of
SS7 gadgets while also having this radio

213
00:19:00,389 --> 00:19:05,105
handy that can capture 3G information to
capture yet more information that's not

214
00:19:05,105 --> 00:19:10,870
available over SS7. Right. So we start
with a phone number and we send what's

215
00:19:10,870 --> 00:19:18,195
called an SRI-for-SM message, which gives
us, if the network is configured answer,

216
00:19:18,195 --> 00:19:26,441
the IMSI and the MSI that the subscriber
currently is connected for. Those two are

217
00:19:26,441 --> 00:19:31,001
used as parameters into another call.
Called the PSI message, provide

218
00:19:31,001 --> 00:19:37,191
subscriber info. And then that call then 
gives us the Cell ID. This is just how

219
00:19:37,191 --> 00:19:41,440
you get more and more information with
different gadgets. Now the Cell ID tells

220
00:19:41,440 --> 00:19:45,840
us where somebody is physically. So imagine
we now move our radio to that

221
00:19:45,840 --> 00:19:54,309
location and we again send a PSI. We record
the PSI. We set radio, not the PSI, what

222
00:19:54,309 --> 00:19:59,779
happens over the airways when we send the
PSI and the phone gets paged. So when we

223
00:19:59,779 --> 00:20:05,889
send the PSI over SS7, the phone receives
some information. Right. This radio plus a

224
00:20:05,889 --> 00:20:11,070
little bit GNU radio scripting gives us
that information: Who has been paged

225
00:20:11,070 --> 00:20:18,749
during that short window of time that we
that we recorded? Now when we record

226
00:20:18,749 --> 00:20:22,929
something on UMTS, we always record for
different cells – they share frequencies.

227
00:20:22,929 --> 00:20:27,419
But you see that the one cell with the 
Cell ID came back over SS7 is included

228
00:20:27,419 --> 00:20:33,012
in our set. So we filter the data for
that cell and we look for which IMSIs are

229
00:20:33,012 --> 00:20:36,739
included. And luckily for us, only one
IMSI got paged within those few

230
00:20:36,739 --> 00:20:43,490
seconds on that cell. It's the same. Same.
This is now the TMSI that belongs to

231
00:20:43,490 --> 00:20:48,600
this phone. This is information we can't
get over SS7. But what you can do over SS7

232
00:20:48,600 --> 00:20:54,710
with the TMSI is request a key, so it gets
complicated. But so we have the decryption

233
00:20:54,710 --> 00:21:00,250
key now and the next time this phone
receives something, unless it changes the

234
00:21:00,250 --> 00:21:04,500
key, in which case we can ask again for
a new key. Next time this phone receives

235
00:21:04,500 --> 00:21:07,279
something. And what you don't see in the
video is, somebody is now sending a text

236
00:21:07,279 --> 00:21:12,129
message to the phone. We can also record
that right. Again, same radio, the one

237
00:21:12,129 --> 00:21:17,990
shown in the picture, now the phone that
received a text message. And there's a few

238
00:21:17,990 --> 00:21:26,980
more steps. So the phone received a text
message and we also, again, recorded the

239
00:21:26,980 --> 00:21:38,629
airwaves. We again run it through some GNU
radio script. Now, was was UMTS

240
00:21:38,629 --> 00:21:42,529
everything? It is kind of complicated, so
there's a different connection, of

241
00:21:42,529 --> 00:21:45,779
course, happening all at the same time,
and then they'll get allocated to

242
00:21:45,779 --> 00:21:49,999
different channels. So now, in order to to
decode this text message, we're going to

243
00:21:49,999 --> 00:21:55,950
find out which channel is used. So this
command gives us the list of which which

244
00:21:55,950 --> 00:22:00,909
channels have been allocated. And we got
to find a TMSI from earlier in one of

245
00:22:00,909 --> 00:22:06,040
these channel allocations. And Wireshark
is a great help in this. We didn't have to

246
00:22:06,040 --> 00:22:11,050
do anything with Wireshark. I just knows
all that 3G stuff right out of the box. So

247
00:22:11,050 --> 00:22:14,970
luckily, the first of these five
connecting requests is the right one and

248
00:22:14,970 --> 00:22:19,379
scroll all the way down, there's then the
parameters that say which channel this

249
00:22:19,379 --> 00:22:23,919
transaction happened on. So those two
numbers, 15 and 48 is the channel. So we,

250
00:22:23,919 --> 00:22:31,324
we need to cell frequency, but we need
those those two two numbers, that, that

251
00:22:31,324 --> 00:22:36,749
are the channel and the key, you know,
this is only 64 bit. I'll discuss that

252
00:22:36,749 --> 00:22:46,675
a little later. And that's all we need to
decrypt an SMS. And there it is.

253
00:22:46,675 --> 00:22:55,382
<i> Applause </i>
Thank you.

254
00:22:57,359 --> 00:23:03,540
This still works today, but only against
two out of the four German networks. Some

255
00:23:03,540 --> 00:23:10,351
of them move to to to stop some of these
messages, of course, most importantly,

256
00:23:10,351 --> 00:23:14,940
this SI message that gives you the
decryption key. But even if you block this

257
00:23:14,940 --> 00:23:22,539
message, just acquiring somebody's
location can already be intrusive enough.

258
00:23:22,539 --> 00:23:27,389
All right. Moving on to 3G security or
rather extending on 3G security since this

259
00:23:27,389 --> 00:23:34,919
already touched through 3G in a big way.
You remember the good old days where where

260
00:23:34,919 --> 00:23:40,489
you could just intercept all phone calls
was the Osmocon phone. Thank you, by the

261
00:23:40,489 --> 00:23:45,059
way, for that open source project that
helped us so much over the years. And you

262
00:23:45,059 --> 00:23:52,849
combine that with the kraken software to
decrypt the phone call. So with 20 year

263
00:23:52,849 --> 00:23:57,919
old vers of phone and the server you can
listen to anybody's GSM calls as long as

264
00:23:57,919 --> 00:24:03,940
they're using the A5/1 cipher. Some
networks recently moved into A5/3.

265
00:24:03,940 --> 00:24:10,720
So it doesn't work this way anymore. Now,
how does this now compare to 3G security?

266
00:24:10,720 --> 00:24:16,039
As I've just shown, basically the same
attacks are possible. Instead of the

267
00:24:16,039 --> 00:24:21,419
Osmocom phone, we use a programable radio,
some more software, but again, very

268
00:24:21,419 --> 00:24:26,509
affordable 400 euros or
something. And you combine that using

269
00:24:26,509 --> 00:24:34,409
instead of kraken SS7 queries. So unless
we fix SS7, 3G is no more secure than 2G

270
00:24:34,409 --> 00:24:41,460
and neither is A5/3, the recent
upgrade of GSM because those keys are

271
00:24:41,460 --> 00:24:50,500
again exposed over SS7. Now, some
networks, you don't even need that second

272
00:24:50,500 --> 00:24:57,559
part, so they have bigger things to worry
about and then SS7 attacks and our data

273
00:24:57,559 --> 00:25:01,919
set isn't all that large. Some of you
provided measurements through through a

274
00:25:01,919 --> 00:25:07,260
software release last year. So thank you
very much for that. And we have captures

275
00:25:07,260 --> 00:25:14,619
from maybe 20, 25 countries out of those
five having to use no 3G encryption at

276
00:25:14,619 --> 00:25:21,200
all. Well, four countries. Five network
operators. Right. Which I find shocking.

277
00:25:21,200 --> 00:25:26,249
Some of these even have encryption turned
on on their GSM network and then forgot to

278
00:25:26,249 --> 00:25:31,216
turn it on or deliberately left it out
because it's harder to intercept on the 3G

279
00:25:31,216 --> 00:25:38,330
variant. Right. So those networks, as I 
said, have much more, much more worrisome

280
00:25:38,330 --> 00:25:45,350
issues than SS7 attacks. And they really
need to be called out. And we do that with

281
00:25:45,350 --> 00:25:49,659
an extension of a website that we've been
maintaining for a couple of years, gsmmap,

282
00:25:49,659 --> 00:25:55,860
big update of gsmmap launched today
with all the 3G measurements, we, we

283
00:25:55,860 --> 00:26:01,590
collected and you collected over the last
couple of years. Now, some of you may have

284
00:26:01,590 --> 00:26:07,951
used gsmmap before. The idea as to to rank
operators in the three categories. How

285
00:26:07,951 --> 00:26:13,509
hard is it to intercept phone calls and
SMS? Is it easy to impersonate a person

286
00:26:13,509 --> 00:26:17,950
and then put charges on a bill, for
instance, or receive the calls? How hard

287
00:26:17,950 --> 00:26:22,760
is it to track them? And as you see, over
the last years, networks have improved

288
00:26:22,760 --> 00:26:31,220
their security, at least some, as always.
God. And as you also see, these are the 2G

289
00:26:31,220 --> 00:26:39,049
networks, even the best secure 2G network.
And in Germany anyway, in our opinion, is

290
00:26:39,049 --> 00:26:44,450
less secure than the worst secured 3G
networks. These are for 3G networks, still

291
00:26:44,450 --> 00:26:50,399
we want networks to implement all security
features. And as you saw before, some

292
00:26:50,399 --> 00:26:57,399
other countries don't have that luxury of
all 3G secure networks reasonably secure.

293
00:26:57,399 --> 00:27:01,909
Not the first version of our metric is
very crude and we want to improve upon

294
00:27:01,909 --> 00:27:06,210
this over time. But currently how we
calculate the score is we'll give ninety

295
00:27:06,210 --> 00:27:10,779
percent of the points to anybody who
switches on encryption. That's the main

296
00:27:10,779 --> 00:27:16,330
security feature and the remaining 10
percent you earn by changing the TMSI

297
00:27:16,330 --> 00:27:22,149
quickly. TMSI is what we needed for these
SS7 attacks to work well. So if you keep

298
00:27:22,149 --> 00:27:28,440
changing it, it really confuses the that
the person trying to to haunt you also

299
00:27:28,440 --> 00:27:32,559
this makes other types of attacks more
difficult, will factor in a couple of more

300
00:27:32,559 --> 00:27:38,989
values as we collect more data. But this
is it for now. So, yeah, big update on

301
00:27:38,989 --> 00:27:43,880
gsmmap. If you haven't checked it out,
check out your country on gsmmap, read the

302
00:27:43,880 --> 00:27:52,149
country report. So does a six page or so
report, auto generated, that explains what

303
00:27:52,149 --> 00:27:56,759
types of measurements we included into
into these graphs and why we think they

304
00:27:56,759 --> 00:28:01,529
they constitute certain risks. Maybe
forward it to to your network and say if

305
00:28:01,529 --> 00:28:08,870
you're not improving, I'm going to change,
switch to another network. Now, not

306
00:28:08,870 --> 00:28:14,210
everything is on, on gsmmap yet because we
don't have enough data. And there's one

307
00:28:14,210 --> 00:28:19,080
problem in particular that I want to start
warning about, because I really think

308
00:28:19,080 --> 00:28:24,399
we're running into an issue here. And that
is the lengths of encryption key you saw

309
00:28:24,399 --> 00:28:29,759
in the in the capture, in the video data
that I showed that the key that came back

310
00:28:29,759 --> 00:28:37,419
over SS7 was actually only 64bit from this
particular network. And the SIM card that

311
00:28:37,419 --> 00:28:41,440
was there was used in this attack, was
bought that very same week. So we recorded

312
00:28:41,440 --> 00:28:46,039
this video last week. So it's the the most
recent SIM card you can buy from this

313
00:28:46,039 --> 00:28:51,340
network. And still it only uses 64 bit.
And that, in my view, is incompatible with

314
00:28:51,340 --> 00:28:57,710
what we have learned from from recent
Snowden documents that the NSA in 2011,

315
00:28:57,710 --> 00:29:06,149
2012 funded a project to break A5/3.
This is a 64 bit cipher. And we had

316
00:29:06,149 --> 00:29:09,919
estimated at this very conference a year
ago that you'd need about a million

317
00:29:09,919 --> 00:29:14,759
dollars to break A5/3. Now, they
did it a little bit earlier. So Moore's

318
00:29:14,759 --> 00:29:19,300
Law, everything's more expensive and
probably to have overhead, too. But they

319
00:29:19,300 --> 00:29:25,000
spend apparently four billion pounds. I
don't know why pound, not dollars, but it

320
00:29:25,000 --> 00:29:31,200
may have been some GCHQ Corporation. So
for four million pound a couple of years

321
00:29:31,200 --> 00:29:36,791
ago, you could already break 64 bit crypto and
64 bit is more prevalent in mobile

322
00:29:36,791 --> 00:29:44,499
networks than you would have thought when
they upgraded the GSM networks to A5/3.

323
00:29:44,499 --> 00:29:49,342
They didn't actually upgraded it to UMTS
security, as everybody claimed they did.

324
00:29:49,342 --> 00:29:57,771
They upgraded it to the cipher used in
UMTS with a key half the size. When

325
00:29:57,771 --> 00:30:02,958
writing the A5/3 standards though, the 
people were smart enough to also put in

326
00:30:02,958 --> 00:30:10,669
the real UMTS cipher with full key size, 
they called it A5/4 and it has never

327
00:30:10,669 --> 00:30:15,029
been seen anywhere since. It's written in 
the standard. It was released the same day

328
00:30:15,029 --> 00:30:20,960
that A5/3 was released. Nobody has ever
moved to implement that. So GSM for the

329
00:30:20,960 --> 00:30:26,049
time being is and will be vulnerable to
anybody. It was a one million dollar

330
00:30:26,049 --> 00:30:30,911
machine in the basement. Certainly NSA,
but more and more people as we move

331
00:30:30,911 --> 00:30:34,570
forward. And what costs a million dollars
today, thanks to Moore's Law in a couple

332
00:30:34,570 --> 00:30:40,869
of years, anybody can break it on a
computers like we today. Break the A5/1.

333
00:30:40,869 --> 00:30:45,649
If your network uses certain older
SIM cards, differentiation years between a

334
00:30:45,649 --> 00:30:52,529
SIM card and a USIM as a UMTS SIM card.
If your network only uses SIM cards, then

335
00:30:52,529 --> 00:30:59,590
even your 3G transactions are 64 bit
encrypted. So there is no way to generate

336
00:30:59,590 --> 00:31:02,960
more entropy. You could query for two
keys, I guess, but they weren't smart

337
00:31:02,960 --> 00:31:10,730
enough to do that. So 64 bit encryption
for UMTS and that's just not good enough.

338
00:31:10,730 --> 00:31:15,309
And as I said, the network that we did 
the demo with we were surprised to see a

339
00:31:15,309 --> 00:31:20,700
64 bit key. We went back in our database
of SIM cards. We found a lot of SIM cards

340
00:31:20,700 --> 00:31:25,027
that have this problem. We want to add
this to gsmmap, but we don't want to be

341
00:31:25,027 --> 00:31:29,214
unfair just because we see one very old SIM 
card in the network. We don't want to give

342
00:31:29,214 --> 00:31:32,987
them a low score versus somebody else,
where we only see a new card. So we need

343
00:31:32,987 --> 00:31:38,596
lots and lots of data. Help us collect 
those data and we'll make it public.

344
00:31:38,596 --> 00:31:44,345
Now, that's one reason why we stay on this
ball and progress the research. The other

345
00:31:44,345 --> 00:31:49,405
main reason, and this is really what keeps
us awake at night is this question of

346
00:31:49,405 --> 00:31:57,120
how can we get out of the mess. We've been
producing more and more problems. I should

347
00:31:57,120 --> 00:32:02,679
not say produce, we make you aware of more
and more problems over the years and we

348
00:32:02,679 --> 00:32:06,570
always criticize that at least many
networks do not respond to those. So we

349
00:32:06,570 --> 00:32:11,860
have to stockpile ever growing stockpile
of mobile security issues and nobody seems

350
00:32:11,860 --> 00:32:15,889
to be addressing. And all we do is wait
for our networks to do something

351
00:32:15,889 --> 00:32:20,630
eventually. Now waiting's over for me, at
least I'm impatient. I want to do

352
00:32:20,630 --> 00:32:25,789
something now and I want to address all
these issues all at once. Those issues

353
00:32:25,789 --> 00:32:31,169
that we talked about for several years
now, including the SIM card attacks from

354
00:32:31,169 --> 00:32:39,739
last year, silent SMS based tracking the
SMS, the SS7 abuse discussed today,

355
00:32:39,739 --> 00:32:46,340
IMSI Catcher Vulnerabilities and
insufficiently configured networks, 2G as

356
00:32:46,340 --> 00:32:53,250
well as 3G. All of these problems have one
thing in common. Your phone technically

357
00:32:53,250 --> 00:32:58,269
knows that these attacks are happening and
your phone technically knows that a

358
00:32:58,269 --> 00:33:03,999
network is configured insecurely. But
unfortunately it's buried very deep inside

359
00:33:03,999 --> 00:33:07,869
the phone. It's buried inside the
baseband. So as much as you can program

360
00:33:07,869 --> 00:33:12,259
Android, you don't get access to that
information. At least so we saw it and

361
00:33:12,259 --> 00:33:16,769
then we set out and just took the better
part of this year. We wanted to dig the

362
00:33:16,769 --> 00:33:21,019
information out from these phones. It's
somewhere in there. There must be some way

363
00:33:21,019 --> 00:33:27,321
to hack it out of it. And we found debug
possibilities for Qualcomm chipsets, just

364
00:33:27,321 --> 00:33:31,309
one vendor, but extremely popular. Right
now. There seem to be in every LTE phone

365
00:33:31,309 --> 00:33:36,809
and in a bunch of other phones. And we
found, we found ways of producing exactly

366
00:33:36,809 --> 00:33:42,539
all the data on the right hand side to
make it accessible through an Android

367
00:33:42,539 --> 00:33:48,060
application. And we also wrote an
application for you. So: Release today.

368
00:33:48,060 --> 00:33:57,695
<i>Applause</i>

369
00:33:57,695 --> 00:34:05,139
Thank you, released today, SnoopSnitch
under GPL. A tool that collects all the

370
00:34:05,139 --> 00:34:09,860
baseband information mostly to keep it
on the phone and run some analysis on it,

371
00:34:09,860 --> 00:34:15,320
warn you about, as I said, SIM card
attacks, but also those SS7 attacks that

372
00:34:15,320 --> 00:34:19,750
Tobias and I talked about today. How do
you take those those attacks? Well, by the

373
00:34:19,750 --> 00:34:24,820
pagings, I showed you in the video
that every time we send certain queries to

374
00:34:24,820 --> 00:34:30,169
the phone, to, over SS7, that the phone
actually also receives information useful

375
00:34:30,169 --> 00:34:35,120
for the attacker. Also useful for the
defender. If those empty pagings, we call

376
00:34:35,120 --> 00:34:38,990
them, are received by the phone, strong
evidence that somebody is messing with you

377
00:34:38,990 --> 00:34:46,890
over SS7. Right. So it collects all that
information and it produces warnings. You

378
00:34:46,890 --> 00:34:52,624
can also upload information issues, so you
choose. It's optional of course, it runs,

379
00:34:52,624 --> 00:34:57,310
as I said, on a bunch of Android phones
that are currently popular. It requires a

380
00:34:57,310 --> 00:35:01,603
somewhat recent Android version we haven't
tested was Android 5 yet, but I don't

381
00:35:01,603 --> 00:35:05,170
see why it wouldn't work, though. We just
have to put the time and your phone needs

382
00:35:05,170 --> 00:35:11,240
to be routed. So we have access to a
certain interface that otherwise is not

383
00:35:11,240 --> 00:35:16,270
accessible. And it needs of course, a
Qualcomm chipset, which, as you see by

384
00:35:16,270 --> 00:35:21,650
this list, is in most current flagship
phones. It's on Google Play right now. So

385
00:35:21,650 --> 00:35:29,080
download it if you're interested. Now, how
does this tool work? One example only, of

386
00:35:29,080 --> 00:35:34,500
course, right, read the source code if you
if you want to know the rest. If you, for

387
00:35:34,500 --> 00:35:38,750
instance, IMSI catcher detection. There
have been a bunch of tools so far to do

388
00:35:38,750 --> 00:35:43,980
IMSI catcher detection. The one we released
a couple of years ago was called CatcherCatcher,

389
00:35:43,980 --> 00:35:49,740
but it had two limitations. One
practical, one more bound to experience.

390
00:35:49,740 --> 00:35:54,790
The practical limitation was that it ran
on Osmocom phones and Osmocom phones can't

391
00:35:54,790 --> 00:35:59,120
do most phone functionality. So always
your second phone? And it had to be

392
00:35:59,120 --> 00:36:03,350
connected to a computer. So very unlikely
that you carried this around all the time.

393
00:36:03,350 --> 00:36:07,411
And we wanted to move it onto a real phone
that you can use onto your phone. Right? I

394
00:36:07,411 --> 00:36:11,690
think we succeeded in that. The second
limitation was that we really didn't know

395
00:36:11,690 --> 00:36:16,440
how IMSI catchers behaved or we also
didn't know how real networks behaved. And

396
00:36:16,440 --> 00:36:20,640
thanks to all the data on gsmmap, we think
we have a much better understanding now of

397
00:36:20,640 --> 00:36:24,880
all the weird corner cases, how real
networks behave and created a much better

398
00:36:24,880 --> 00:36:32,890
ruleset for for an Android based catcher
catcher tool now. And the rules go in two

399
00:36:32,890 --> 00:36:37,111
categories. One is the configuration of
the of these different cells. For

400
00:36:37,111 --> 00:36:41,760
instance, the lack of encryption when, you
know, from the gsmmap database that this

401
00:36:41,760 --> 00:36:46,473
network does usually support encryption,
that's a big red flag. Also certain other

402
00:36:46,473 --> 00:36:51,180
configurations. So that's a configuration
of the network, the adjusted behavior and

403
00:36:51,180 --> 00:36:53,800
the IMSI catcher wants to get
information out from you at the very

404
00:36:53,800 --> 00:36:58,290
least, the IMSI, of course, it's in the
name. Right. So that suspicious behavior

405
00:36:58,290 --> 00:37:04,955
now, none of these things taken by
themselves did allow you to detect an

406
00:37:04,955 --> 00:37:09,860
IMSI catcher. So we compute score over
these different events, doing stream

407
00:37:09,860 --> 00:37:14,830
analysis on everything that happens on
your phone and eventually then come out

408
00:37:14,830 --> 00:37:20,820
with a warning. If the score crosses a
certain threshold, there's a bunch more we

409
00:37:20,820 --> 00:37:25,030
would have wanted to include that's even 
on a Qualcomm chipset in it's debug mode

410
00:37:25,030 --> 00:37:29,960
not available. So this is still ongoing work
as these chipsets progress and may give

411
00:37:29,960 --> 00:37:37,168
us more information in the future. Now, if
you do find alerts, let's call them alarms

412
00:37:37,168 --> 00:37:41,044
on your phone. We'd be grateful if you
could share them. Now, as I said, this is

413
00:37:41,044 --> 00:37:48,080
optional, right? You get you get the
alerts shown in shown in your little tool

414
00:37:48,080 --> 00:37:52,730
and then you can choose to upload
whichever ones you think should be shared

415
00:37:52,730 --> 00:37:59,697
if we get enough of them and and think
that there's really hot spots of of of

416
00:37:59,697 --> 00:38:03,419
abuse, of course, we'll try to make that
transparent, perhaps even put little dots

417
00:38:03,419 --> 00:38:07,950
on the GSM website so people know where
abuse could be happening around

418
00:38:07,950 --> 00:38:20,370
demonstrations, around embassies, wherever.
<i>Applause</i>

419
00:38:20,370 --> 00:38:23,410
You can also actively choose to

420
00:38:23,410 --> 00:38:28,090
submit data by by running an active test
now usually the phone looks at everything

421
00:38:28,090 --> 00:38:32,370
that you produce, your phone calls, your
SMS that's always stored on the phone.

422
00:38:32,370 --> 00:38:37,880
There's no way to upload that. And you
compute a score for how secure your

423
00:38:37,880 --> 00:38:42,410
network is using the exact same metrics
that we use on gsmmap. So that's all

424
00:38:42,410 --> 00:38:47,410
ported to the phone now. But if you feel
like the score on gsmmap is heavily outdated,

425
00:38:47,410 --> 00:38:51,860
click this button. It runs some benign tests, 
has nothing to do with your transactions. I

426
00:38:51,860 --> 00:38:55,640
guess your location where you're currently
connected would be included in the data

427
00:38:55,640 --> 00:39:02,030
and it uploads it to gsmmap. So that
becomes better and better. And we can spot

428
00:39:02,030 --> 00:39:09,780
more networks that, for instance, like any
encryption at all. Yeah, so what's what

429
00:39:09,780 --> 00:39:15,370
what are you what I like you to do, I
think you should do to better protect

430
00:39:15,370 --> 00:39:20,076
yourself from mobile abuse, of course you
could keep waiting for your mobile

431
00:39:20,076 --> 00:39:24,900
networks to fix all these issues, which I
must say more recently, more networks have

432
00:39:24,900 --> 00:39:30,150
moved to fix issues, but still not the
majority. And no network has even started

433
00:39:30,150 --> 00:39:35,550
to address the majority of issues. So it's
just scratching the surface. So what I'd

434
00:39:35,550 --> 00:39:41,770
rather have you do is start defending
yourself. Check out gsmmap, see if you

435
00:39:41,770 --> 00:39:45,800
are on a network that generally protects
things like encryption. You saw the

436
00:39:45,800 --> 00:39:51,750
networks that lack encryption. Don't use
those. And if you really choose to self

437
00:39:51,750 --> 00:39:58,241
defense, download, SnoopSnitch, this new
tool and actively look out for abuse, for

438
00:39:58,241 --> 00:40:03,080
Silent SMS, binary SMS that you receive,
for empty pagings, for IMSI catcher

439
00:40:03,080 --> 00:40:10,490
evidence and help us grow this database of
abuse. Right. Also help us grow the

440
00:40:10,490 --> 00:40:15,720
tool base that we use. This is released
open source and we put in a lot of work to

441
00:40:15,720 --> 00:40:20,710
make the data accessible. But now it is
accessible, right? Just take it as a

442
00:40:20,710 --> 00:40:26,920
library and go wild with it. Do whatever
you always wanted to do with raw baseband

443
00:40:26,920 --> 00:40:34,300
data on 2G, 3G, 4G. I am very much looking
forward to your contributions to this and

444
00:40:34,300 --> 00:40:37,720
all that's left for me to say is thank you
very much.

445
00:40:37,720 --> 00:40:47,570
<i>applause</i>

446
00:40:47,570 --> 00:40:57,240
Herald: Thank you, Karsten, then we will
beginning with the Q&A, please, for

447
00:40:57,240 --> 00:41:03,590
everybody that will be asking questions,
please line up on the microphones in the

448
00:41:03,590 --> 00:41:13,660
room and for people that exit the room,
please do it with no noise and quickly.

449
00:41:13,660 --> 00:41:17,390
Karsten: Now, before getting into the
question, let me give you one reason to

450
00:41:17,390 --> 00:41:22,520
actually do leave now. There's a workshop
happening right now or in a few minutes

451
00:41:22,520 --> 00:41:27,850
that will explain how this tool works and
what it can all do. We'll have an IMSI

452
00:41:27,850 --> 00:41:31,240
catcher there a day or so. You can tell us
how that feels like being connected to an

453
00:41:31,240 --> 00:41:36,210
IMSI catcher. It's happening in room C,
which is when you exit here one floor

454
00:41:36,210 --> 00:41:41,750
down and to this end.
Herald: And additional information, the

455
00:41:41,750 --> 00:41:51,407
workshop that's Karsten says start at
nineteen forty five.

456
00:41:51,407 --> 00:42:00,050
K: And now to your questions.
<i> distant noise </i>

457
00:42:00,050 --> 00:42:04,800
K: Sure.
Herald: OK, microphone number two and

458
00:42:04,800 --> 00:42:10,460
please, before before we before you can
start number two, please do it with no

459
00:42:10,460 --> 00:42:19,270
noise that we hear the question from the
audience. OK, number two, please.

460
00:42:19,270 --> 00:42:23,260
Mic 2: Thank you. Can you quickly say a
few words about why it wouldn't work on

461
00:42:23,260 --> 00:42:27,610
custom ROMs? Because we could just install
it into cyanogen phones and apparently

462
00:42:27,610 --> 00:42:34,750
installed and it seems to work.
K: Oh, OK. So the way I understood custom

463
00:42:34,750 --> 00:42:38,920
ROMs is that they first remove a bunch of
stuff from the phone and then put a bunch

464
00:42:38,920 --> 00:42:44,025
of stuff on it. Part of what we need are
these proprietary Qualcomm libraries and

465
00:42:44,025 --> 00:42:47,050
at least on the phones where we tried
cyanogen mod and what they are being

466
00:42:47,050 --> 00:42:51,730
removed. So if cyanogen mod could stop
doing that, it would work beautifully.

467
00:42:51,730 --> 00:42:56,430
It's not that we need anything additional.
We just need less to be deleted.

468
00:42:56,430 --> 00:43:04,290
Mic 2: OK, thank you.
Herald: OK. Microphone number …, will you

469
00:43:04,290 --> 00:43:09,760
ask. OK, are there some questions from the
IRC?

470
00:43:09,760 --> 00:43:16,090
K: I think we have a bunch of questions.
Signal Angel: Actually, there is five

471
00:43:16,090 --> 00:43:24,030
questions, so I will just ask one or two
for starting. The first one is, can all

472
00:43:24,030 --> 00:43:30,690
these shown attacks that you proved on
your speech be mitigated by… by higher

473
00:43:30,690 --> 00:43:37,300
protocols levels, like encrypted VoIP or
TextSecure, things like that? And what

474
00:43:37,300 --> 00:43:41,910
will be the residual risks?
K: Mm, yeah. A good question. So how much

475
00:43:41,910 --> 00:43:46,740
can you protect yourself by using the
mobile network less on using it as a dumb

476
00:43:46,740 --> 00:43:52,710
pipe, I guess is the question, what if you
use just apps to call and send text? Well,

477
00:43:52,710 --> 00:43:59,090
obviously your calls and texts won't be
intercepted anymore if they are encrypted

478
00:43:59,090 --> 00:44:04,560
one more time in a way that's not
breakable. However, this does not solve

479
00:44:04,560 --> 00:44:09,100
the location tracking. It does not solve
the fraud. It does not solve the denial of

480
00:44:09,100 --> 00:44:13,790
service. It does not solve the spamming.
So you are tied to a mobile network and it

481
00:44:13,790 --> 00:44:18,140
has a lot of control over you, your
location and your phone bill. None of that

482
00:44:18,140 --> 00:44:25,590
is going to go away.
Herald: Another question from the IRC, one.

483
00:44:25,590 --> 00:44:33,380
Signal Angel: Yeah, um, the second one is:
Wouldn't it be easier to design from

484
00:44:33,380 --> 00:44:39,902
scratch a new mobile mobile network than
trying to find all flaws from actual

485
00:44:39,902 --> 00:44:45,080
networks, which is an endless task?
K: Or I don't know where you would even

486
00:44:45,080 --> 00:44:49,770
start designing everything from scratch
completely? The closest that I can think

487
00:44:49,770 --> 00:44:54,280
of designing the mobile network from
scratch is LTE in the name of long term

488
00:44:54,280 --> 00:44:58,500
evolution. It really wants to change
everything, but gives it a couple of years

489
00:44:58,500 --> 00:45:02,690
but as Tobias pointed out, those
issues we pointed out today, they are

490
00:45:02,690 --> 00:45:08,220
again included in LTE. Diameter is the
interconnect protocol. So we already

491
00:45:08,220 --> 00:45:13,410
missed a chance to to remove much of this
issues by just upgrade. We'll have to fix

492
00:45:13,410 --> 00:45:18,950
it through firewalls and monitoring like
we never got to update the Internet.

493
00:45:18,950 --> 00:45:22,540
Herald: OK, microphone number four,
please.

494
00:45:22,540 --> 00:45:27,620
Mic 4: Yet just a short thing. Could you
just provide a list of those libraries

495
00:45:27,620 --> 00:45:35,630
you need from the stock images? So I think
it's pretty easy to copy them to this

496
00:45:35,630 --> 00:45:38,484
cyanogen mod images.
K: Ok

497
00:45:38,484 --> 00:45:40,516
Mic 4: OK, and if the app is open source,

498
00:45:40,516 --> 00:45:45,900
maybe you can put it on fdroid?
K: Oh absolutely. Yes. Thank you.

499
00:45:45,900 --> 00:45:50,970
<i>applause</i>
Herald: The microphone number two, please.

500
00:45:50,970 --> 00:45:57,560
Mic 2: Got two questions, if I understood
correctly, you need to be inside the

501
00:45:57,560 --> 00:46:02,350
operator network to actually
perform those SS7 queries, right?

502
00:46:02,350 --> 00:46:08,030
K: Um, well, I would I would like for this
to be the case. But currently, does

503
00:46:08,030 --> 00:46:12,020
anybody in the world connected to SS7 can
send his queries.

504
00:46:12,020 --> 00:46:17,960
Mic 2: OK, so my question is that what was
your hook point for actually doing this

505
00:46:17,960 --> 00:46:20,890
test?
K: I think I'll quote Tobias here by

506
00:46:20,890 --> 00:46:23,420
saying I would rather not say anything 
about that.

507
00:46:23,420 --> 00:46:29,800
Mic 2: OK, so the second question is about
the case you mentioned it's if I am not

508
00:46:29,800 --> 00:46:37,840
mistaken, is the session key. Right? It's and
it should involve that nonce value, right?

509
00:46:37,840 --> 00:46:42,850
K: Yeah.
Mic 2: So if it is, it already has the nonce

510
00:46:42,850 --> 00:46:48,130
value. So in order the attack to work, we
also need to intercept the initial

511
00:46:48,130 --> 00:46:54,930
messages, the nonce exchange between the
target and the basis station. Is that

512
00:46:54,930 --> 00:46:59,460
correct?
K: No, the nonce is… as as they are. So

513
00:46:59,460 --> 00:47:05,660
the SIM card knows which key to produce.
<i>Yes.</i> But it helps the phone to find the

514
00:47:05,660 --> 00:47:09,780
right encryption key. We are not the
phone. We don't have the SIM card. <i>Right.</i>

515
00:47:09,780 --> 00:47:12,600
If you just give us the encryption key, 
we don't need the nonce.

516
00:47:12,600 --> 00:47:18,700
Mic 2: Yes. So what you're saying is that
the query you're sending there, it

517
00:47:18,700 --> 00:47:25,910
actually sends you not only the encryption
key, but also the nonce that is required..

518
00:47:25,910 --> 00:47:30,030
K: It doesn't send us the nonce and we
don't need the nonce. We can take that

519
00:47:30,030 --> 00:47:32,430
offline now, explain how everything works.
Thank you.

520
00:47:32,430 --> 00:47:35,780
Herald: To microphone number three,
please.

521
00:47:35,780 --> 00:47:40,680
Mic 3: First of all, thank you for a very
good presentation and very impressive work

522
00:47:40,680 --> 00:47:45,330
you've done here.
<i>applause</i>

523
00:47:45,330 --> 00:47:50,050
K: Thank you.
Mic 3: The question I have might be a

524
00:47:50,050 --> 00:47:55,090
little naive, but have you also, besides
taking a look at this closing this whole

525
00:47:55,090 --> 00:48:00,630
issue technically wise, also been taking a
look into how what measures can be taken

526
00:48:00,630 --> 00:48:04,900
legally, at least in Germany and some
countries in Europe now that we have

527
00:48:04,900 --> 00:48:11,431
disclosed that basically certain rules /
laws have not been fulfilled, that we can

528
00:48:11,431 --> 00:48:15,950
enforce the operators to implement this
stuff on legal ways?

529
00:48:15,950 --> 00:48:21,420
K: We have not looked into it. Of course,
we consider the possibility as soon as

530
00:48:21,420 --> 00:48:25,470
somebody has an overview of where these
attacks happen. And that seems to be the

531
00:48:25,470 --> 00:48:31,140
issue right now. There's zero attack
transparency. Nobody is looking for these

532
00:48:31,140 --> 00:48:38,300
issues. And partly that's to the to their
own disbenefit, because as soon as they do

533
00:48:38,300 --> 00:48:43,190
look for this issue, some of these attack
patterns are very easy to stop, as I said,

534
00:48:43,190 --> 00:48:49,660
two German networks, mitigated them within
two weeks. And these issues had been open

535
00:48:49,660 --> 00:48:54,510
for 20 years. Had they ever looked into
their own data, that would have seen this

536
00:48:54,510 --> 00:49:00,060
going on. So I'm not very confident that
anybody in Germany at least has an

537
00:49:00,060 --> 00:49:04,650
overview of where abuse would come from.
And as soon as it does, I don't think

538
00:49:04,650 --> 00:49:10,310
there's much point in litigating. Let's
just stop the possibility of abuse. Right,

539
00:49:10,310 --> 00:49:14,990
instead of complaining about it happening.
But I'm with you. If there's corner cases

540
00:49:14,990 --> 00:49:19,660
in which abuse just can't be stopped,
let's fight it legally, of course. Right.

541
00:49:19,660 --> 00:49:24,850
And if all of you contribute information
through SnoopSearch, does the empty

542
00:49:24,850 --> 00:49:29,560
pagings, if we can find patterns of
abuse, of course, we'll aggregate them and

543
00:49:29,560 --> 00:49:36,680
try to move against them.
Herald: OK, microphone number four,

544
00:49:36,680 --> 00:49:40,740
please.
Mic 4: You said you can buy your way into

545
00:49:40,740 --> 00:49:46,790
the SS7 Network, but how easy is it
actually to get your access? And what do

546
00:49:46,790 --> 00:49:50,690
you estimate: How many players are 
there in the network? Can you give any

547
00:49:50,690 --> 00:49:54,311
estimation?
K: I have absolutely no idea. I know that

548
00:49:54,311 --> 00:50:01,760
there's some 800 companies who who are
legally allowed to access SS7 and then

549
00:50:01,760 --> 00:50:06,860
those, of course, have subcontractors,
legal and illegal, and some people who

550
00:50:06,860 --> 00:50:11,186
bribe them. Yet other people who hack
their systems or the systems of the

551
00:50:11,186 --> 00:50:14,920
subcontractors, it's very hard to
estimate. No idea. But definitely too many

552
00:50:14,920 --> 00:50:18,650
to trust all of them.
Mic 4: And would it be possible for me to

553
00:50:18,650 --> 00:50:25,710
get access to this without any operator
stuff or. I don't want to operate a phone

554
00:50:25,710 --> 00:50:31,300
network, but I want to have access because
I want to provide a service, some service?

555
00:50:31,300 --> 00:50:35,670
K: Well, I wish the answer was no, but of
course, right of to be as an I and a bunch

556
00:50:35,670 --> 00:50:40,910
of other people can get access. You should
be able to get that too. But I'm not going

557
00:50:40,910 --> 00:50:44,600
to tell you how.
<i>laughter and applause</i>

558
00:50:44,600 --> 00:50:51,680
Herald: Yet another question from the IRC.
Signal Angel: We're about nine questions,

559
00:50:51,680 --> 00:50:58,200
so no problem for me. First one, what
about Windows phones, jail breaked

560
00:50:58,200 --> 00:51:04,890
iPhones, or something like this will the
app in the end [be] on this phones?

561
00:51:04,890 --> 00:51:11,250
K: Our app doesn't run on anything other
than Android, but the chipsets are, of

562
00:51:11,250 --> 00:51:16,670
course, the same. So if you can speak to a
chipset through a jail broken iPhone, for

563
00:51:16,670 --> 00:51:22,070
instance, you could create a similar
application. We just wanted to target the

564
00:51:22,070 --> 00:51:25,990
biggest population of phones, and that
seems to be Android phones.

565
00:51:25,990 --> 00:51:33,160
Herald: Then number two, please.
Mic 2: One further thought on self-defense

566
00:51:33,160 --> 00:51:41,110
as self-defense has don't has to be
proportionate, I think, and identities are

567
00:51:41,110 --> 00:51:46,771
not secure in the digital sphere. How
about developing some proactive, as we

568
00:51:46,771 --> 00:51:52,820
heard the word defense tools?
K: Proactive as in hack the networks,

569
00:51:52,820 --> 00:51:59,010
until they have no chance but to fix?
Mic 2: That's what you understood, but.

570
00:51:59,010 --> 00:52:03,010
But, I support that. <i> laughter </i>
K: I'm not going to say that I dislike the

571
00:52:03,010 --> 00:52:07,620
idea. But you won't see me here next year
explaining how I did it.

572
00:52:07,620 --> 00:52:11,690
Mic 2: Thank you.
Herald: Microphone number three, please.

573
00:52:11,690 --> 00:52:17,070
OK. When did you check the other two
German networks didn't fix the identifier

574
00:52:17,070 --> 00:52:21,800
and the issue.
K. Which network do you work for?

575
00:52:21,800 --> 00:52:27,780
Mic 2: I'm Holger. We talked last week.
K: Yeah. So yeah. Maybe you fixed it too.

576
00:52:27,780 --> 00:52:30,930
We didn't, we didn't check.
Mic 2: We fixed it within 24 hour, 24

577
00:52:30,930 --> 00:52:34,590
hours after our call.
K: Wow. OK.

578
00:52:34,590 --> 00:52:38,300
Mic 2: On both networks.
<i>applause</i>

579
00:52:38,300 --> 00:52:44,430
Thank you. Better late than never. Thank
you.

580
00:52:44,430 --> 00:52:47,320
Mic 2: That's right.
K: OK, so that's three out of four now,

581
00:52:47,320 --> 00:52:52,610
that fix one out of 100 problems.
Mic 2: No, it's… I know that's why we

582
00:52:52,610 --> 00:52:59,610
don't go to the press and don't tell that
SS7 is fixed and we know we still have

583
00:52:59,610 --> 00:53:06,920
problems also. It's all four. I work for
Telefonica, which is O2 and eplus.

584
00:53:06,920 --> 00:53:11,291
K: Oh yeah. Well, congratulations. Sorry.
Sorry for spoiling your Christmas.

585
00:53:11,291 --> 00:53:13,440
<i> laughter </i>

586
00:53:13,440 --> 00:53:19,400
Herald: Microphone number two, please.
Mic 2: I'd like to know why these empty

587
00:53:19,400 --> 00:53:24,180
pagings occur in the context of the
location tracking, I thought, as soon as

588
00:53:24,180 --> 00:53:30,620
the phone registers in the network, the
base station, which is this connected to,

589
00:53:30,620 --> 00:53:32,630
is known in the network anyway. Is that
the case?

590
00:53:32,630 --> 00:53:37,490
K: That's a very good question. And let me
let me go back to one earlier slide to to

591
00:53:37,490 --> 00:53:45,590
explain that, one second, so that the
empty pagings do not occure when you send

592
00:53:45,590 --> 00:53:50,380
these creepy AnytimeInterrogation
messages. They are just there for spying

593
00:53:50,380 --> 00:53:55,280
and there's no way to page the customer.
But since this got blocked and Tobias went

594
00:53:55,280 --> 00:53:59,070
into great level of detail explaining
this, you need a couple of other messages

595
00:53:59,070 --> 00:54:03,320
to now track some of this location and
these messages when meant for location

596
00:54:03,320 --> 00:54:09,530
tracking them and ment for other purposes.
For instance, as I provide subscriber info

597
00:54:09,530 --> 00:54:14,950
that however you reach it is always the
last message you need. This does do a

598
00:54:14,950 --> 00:54:19,020
paging and then to provide subscriber info
really makes no sense unless you send

599
00:54:19,020 --> 00:54:23,890
something afterwards also, deliver an SMS
connect to call or whatever. So the paging

600
00:54:23,890 --> 00:54:29,690
is already sent in anticipation that an
SMS will come or that the call will come.

601
00:54:29,690 --> 00:54:33,880
But if you're only the creepy guy tracking
it, they're going to send it SMS and

602
00:54:33,880 --> 00:54:38,410
that's where the empty paging comes from.
Mic 2: OK, but still also in these cases

603
00:54:38,410 --> 00:54:43,610
where something follows the paging, isn't
it a type of double checking whether it's

604
00:54:43,610 --> 00:54:50,230
really there or I mean, the location info
itself should already be present and the

605
00:54:50,230 --> 00:54:53,510
network, isn't it?
K: Yeah, yeah. It just reconfirms that the

606
00:54:53,510 --> 00:54:57,640
subscriber is really there. So it's
basically saying: Somebody you just

607
00:54:57,640 --> 00:55:01,370
interrogated your location because they
want to send you something. Let's check

608
00:55:01,370 --> 00:55:05,350
that you're really still there because
otherwise we'll tell them something wrong.

609
00:55:05,350 --> 00:55:10,420
But Tobias do you want to comment on that.
Tobias: Yeah. OK, so the empty paging is

610
00:55:10,420 --> 00:55:15,930
not anticipation or something that's
coming after. It's to get the current cell

611
00:55:15,930 --> 00:55:20,970
that you are located at, because when you
are moving around in your location area

612
00:55:20,970 --> 00:55:24,850
and the area that is covered by the
switching center that you're currently

613
00:55:24,850 --> 00:55:31,120
being served by, your phone doesn't
necessarily contact the base station. So

614
00:55:31,120 --> 00:55:37,790
it could be that that the networks last
position of you is somewhere you received

615
00:55:37,790 --> 00:55:43,950
an SMS or text or call, and then you moved
to a completely different area if your

616
00:55:43,950 --> 00:55:49,130
phone didn't have network contact in the
meantime, the network would still only

617
00:55:49,130 --> 00:55:55,610
know the last point of contact. So that's
why the why the empty paging happens so

618
00:55:55,610 --> 00:56:01,310
that the that the network knows the base
station that's actually currently closest

619
00:56:01,310 --> 00:56:06,780
to you. That's also why the law
enforcement uses a lot of Silent SMS so

620
00:56:06,780 --> 00:56:12,530
that that they can get the last position
in the network. And it's also an option if

621
00:56:12,530 --> 00:56:17,240
you send provide subscriber information,
you can just send it and get back the last

622
00:56:17,240 --> 00:56:23,720
known position without a paging or you can
set the current location flag and provide

623
00:56:23,720 --> 00:56:29,860
subscriber information. And only then the
subscriber gets paged and you will receive

624
00:56:29,860 --> 00:56:33,530
the current location.
K: And that's that's one good example for

625
00:56:33,530 --> 00:56:37,880
how SS7, which is supposed to be
so insecure we can never fix it, can

626
00:56:37,880 --> 00:56:42,750
easily be fixed. There's an option that
says we're using this as normal feature

627
00:56:42,750 --> 00:56:46,480
that's absolutely needed. And we have this
creepy extension to also ask for the

628
00:56:46,480 --> 00:56:51,140
location. And some networks choose to not
answer that. The answer was zero zero zero

629
00:56:51,140 --> 00:56:57,540
zero and nothing broke. Right. So you can
just ignore the insecure parts of SS7 and

630
00:56:57,540 --> 00:57:01,890
do whatever you think is right. And for
the most part, it continues to work. But

631
00:57:01,890 --> 00:57:04,040
I think we're well beyond answering 
your question now right?

632
00:57:04,040 --> 00:57:11,230
Mic 2: No, but from your answers. Thank
you very much. But another question

633
00:57:11,230 --> 00:57:16,710
arises, because if it's actually to locate
your phone and to find out which cell

634
00:57:16,710 --> 00:57:23,310
you're actually in, then it implies that
it's not only one base station that since

635
00:57:23,310 --> 00:57:29,190
the paging call, but a whole bunch of base
stations. Do you know something about the

636
00:57:29,190 --> 00:57:35,260
algorithm? I mean, how many around the
last known location are paging everybody

637
00:57:35,260 --> 00:57:39,560
nationwide or how does..
K: Everybody can implement this as they

638
00:57:39,560 --> 00:57:45,340
wish? And I don't have much insights into
how 3G does it, but in 2G typically is:

639
00:57:45,340 --> 00:57:49,730
There's one paging send in the last cell
that saw you. You don't respond. It's send

640
00:57:49,730 --> 00:57:53,600
in a larger area. You don't respond. It's
sent for the whole location area. And then

641
00:57:53,600 --> 00:57:58,100
some networks, you don't respond. They
send it in the entire country. But that's

642
00:57:58,100 --> 00:58:01,589
rare. Right?
Mic 2: Thank you very much.

643
00:58:01,589 --> 00:58:12,790
Herald: Okay. Questions from the IRC?
Signal Angel: Did SnoopSnitch allow you to

644
00:58:12,790 --> 00:58:20,740
reveal any kind of attack in countries.
Not special name in mind.

645
00:58:20,740 --> 00:58:26,920
K: Does it allow you to detect attacks in
countries? <i>Yeah,</i> yeah, <i>some kind of</i>

646
00:58:26,920 --> 00:58:32,520
<i>Tapsell.</i> I think the answer is yes. Its
whole purpose is to detect attacks. And it

647
00:58:32,520 --> 00:58:35,852
also works in countries…
<i> laughter </i>

648
00:58:35,852 --> 00:58:39,840
Herald: Did you succeed in detecting attacks.
K: Did we succeed in

649
00:58:39,840 --> 00:58:46,590
detecting. Yes, we did. And if you go down
to the Saal C, Room C, you can see how it's

650
00:58:46,590 --> 00:58:53,880
currently people are being attacked and
currently they detect that. <i>Ok</i>

651
00:58:53,880 --> 00:58:59,280
Herald: OK microphone number five, please.
Mic 5: Yes, thanks, it's going back to SS7

652
00:58:59,280 --> 00:59:05,670
basics. Can you quickly explain how SS7 is
implemented? Is this a VPN on the public

653
00:59:05,670 --> 00:59:10,610
Internet through the providers? What's the
technical reality of transport?

654
00:59:10,610 --> 00:59:16,640
K: That's a very good question. Of course,
that's a very good question. And I only

655
00:59:16,640 --> 00:59:21,890
have half of the information, too. I keep
learning. But so it seems that it was

656
00:59:21,890 --> 00:59:27,430
implemented initially as a network between
Western European telcos and their run

657
00:59:27,430 --> 00:59:33,961
cables, dedicated cables for SS7.
SIGTRAN they called this and then a couple

658
00:59:33,961 --> 00:59:38,250
more networks connected to it. And each
of them had to run the cable to one of the

659
00:59:38,250 --> 00:59:42,690
other telcos. But eventually they changed
that and then introduced what I call

660
00:59:42,690 --> 00:59:46,741
routing providers. So telcos are not
connected to each other usually, but

661
00:59:46,741 --> 00:59:52,240
through a routing provider like on the
Internet and those routing providers, they

662
00:59:52,240 --> 00:59:56,710
typically don't run a cable to your house
anymore. If you are a new telco, they give

663
00:59:56,710 --> 01:00:00,790
you a VPN over the Internet. So it's
diverse. I'm sure there's still some

664
01:00:00,790 --> 01:00:04,790
dedicated lines between Germany and
France, say, and there's some others

665
01:00:04,790 --> 01:00:08,510
connecting and these big clouds that are
routing providers. And it's actually

666
01:00:08,510 --> 01:00:12,290
really difficult to get your address
routed everywhere in the world. So even if

667
01:00:12,290 --> 01:00:16,886
you connect to SS7, all you're connected 
to is one routing provider and that

668
01:00:16,886 --> 01:00:21,690
routing provider knows that you own these
addresses. Now it's up to you to convince

669
01:00:21,690 --> 01:00:25,850
every other of the big seven or nine,
depending on how you count routing

670
01:00:25,850 --> 01:00:34,250
providers that you are that guy with those
addresses. So the BGP equivalent of SS7 is

671
01:00:34,250 --> 01:00:40,410
to get nine roaming agreements signed with
people on these other nine operators and

672
01:00:40,410 --> 01:00:44,810
then fax those roaming agreements to
everybody else involved. So they type it

673
01:00:44,810 --> 01:00:49,530
into your computer, into their computers,
very manual and very hard to grow the

674
01:00:49,530 --> 01:00:52,830
network. But for the most part, it doesn't
change, of course-

675
01:00:52,830 --> 01:00:57,940
Mic 5: So that the low level transport is
not really an attack surface from the

676
01:00:57,940 --> 01:01:00,840
public Internet.
K: It can be the low level transport can

677
01:01:00,840 --> 01:01:07,090
be an attack surface if people just
stupidly leave open their local networks.

678
01:01:07,090 --> 01:01:11,156
But it's rare. It's much more common,
speaking about our talk next year,

679
01:01:11,156 --> 01:01:15,844
hopefully on the other interconnect
networks, there's one interconnect network

680
01:01:15,844 --> 01:01:22,240
for data roaming. It's called GRX. And
since everything is IP anyway on data

681
01:01:22,240 --> 01:01:26,610
roaming, people sometimes do leave it out
on the Internet or just do it unencrypted

682
01:01:26,610 --> 01:01:31,010
over the Internet. And it does seem to
become more popular also with the SS7

683
01:01:31,010 --> 01:01:37,440
replacement Diameter, which again is pure
IP. So there's no dedicated thing that you

684
01:01:37,440 --> 01:01:41,660
first have to encapsulate in a VPN before
you can route it over the Internet. You

685
01:01:41,660 --> 01:01:47,060
can run Diameter over the open Internet if
you want. It's stupid, but people seem to

686
01:01:47,060 --> 01:01:52,170
do it anyway.
Herald: OK, the microphone number six,

687
01:01:52,170 --> 01:01:55,310
please.
Mic 6: OK, my question is, if you could

688
01:01:55,310 --> 01:02:00,451
comment why these message were put in the
protocol at the first place, it they are

689
01:02:00,451 --> 01:02:07,270
so easy to block and to fix. And the other
question is, if all the other problems

690
01:02:07,270 --> 01:02:11,620
that you pointed out are as easy to fix
for the network operators.

691
01:02:11,620 --> 01:02:16,780
K: So I don't have an answer to your first
question. Why do you put a tracking

692
01:02:16,780 --> 01:02:22,470
message in the standard and then call it
AnytimeInterrogation, gosh, like that

693
01:02:22,470 --> 01:02:25,610
invokes feelings for me,
interrogation room and all. I mean, this

694
01:02:25,610 --> 01:02:30,440
is spy stuff, right? And there's no
practical, purposeful but. Right. Who

695
01:02:30,440 --> 01:02:35,000
wrote SS7 standard? Western European
governments being afraid of the Russians,

696
01:02:35,000 --> 01:02:39,060
of their own citizens, who knows? Right. I
don't know why they put every single

697
01:02:39,060 --> 01:02:44,280
message in, though. So your second
question was what again?

698
01:02:44,280 --> 01:02:49,060
Mic 6: If the other vulnerabilities are as
easy as to fix? Or just blocking messages.

699
01:02:49,060 --> 01:02:55,730
K: No they're not. And I tried to point
that out in one of the slides that… that

700
01:02:55,730 --> 01:03:02,270
AnytimeInterrogation can be fixed, as can,
for instance, as does SendIdentification

701
01:03:02,270 --> 01:03:07,310
message, right. You just block that has no
purpose, routing this internationally. But

702
01:03:07,310 --> 01:03:11,600
the other queries on this page, at least
you need those internationally, at least

703
01:03:11,600 --> 01:03:17,430
to enable roaming. So the best you can do
is, as I said, first block these queries

704
01:03:17,430 --> 01:03:21,010
from anybody who's not your roaming
partner, right? Don't respond to those

705
01:03:21,010 --> 01:03:26,520
people and then do some plausibility 
checking, secondly, make sure that if a

706
01:03:26,520 --> 01:03:31,380
subscriber is actually in your own network, 
that you don't honor requests from another

707
01:03:31,380 --> 01:03:36,600
country. Right. And that should remove most 
of the issues because most abuse comes from

708
01:03:36,600 --> 01:03:40,340
other countries. It's just more likely if
there's 800 parties connected to this

709
01:03:40,340 --> 01:03:46,901
network that the one doing the abuse is
not yours. Good question. <i>Thanks.</i>

710
01:03:46,901 --> 01:03:59,000
Subtitles created by c3subtitles.de
in the year 2021. Join, and help us!