1
00:00:09,249 --> 00:00:12,109
This talk will be by Sylvain Munaut

2
00:00:12,109 --> 00:00:14,859
who works with the Osmocom project.

3
00:00:14,859 --> 00:00:19,330
He will talk today about the
osmo-gmr satellite phones.

4
00:00:19,330 --> 00:00:22,980
After the talk there will be the
opportunity to ask questions.

5
00:00:22,980 --> 00:00:25,419
You can approach one of the microphones

6
00:00:25,419 --> 00:00:28,279
and then you have the chance
to ask one question.

7
00:00:28,279 --> 00:00:32,860
Please give a round of applause
to Mr Sylvain Munaut!

8
00:00:32,860 --> 00:00:35,760
*Applause*

9
00:00:36,360 --> 00:00:39,469
- Hi! Thank you for being here.

10
00:00:39,469 --> 00:00:44,750
As he said I'm going to talk about
satellite phones today.

11
00:00:44,750 --> 00:00:50,060
I'll first talk with a quick recap of the
previous work we've done.

12
00:00:50,060 --> 00:00:53,880
At 28C3 there was a presentation
on this subject.

13
00:00:53,880 --> 00:00:56,030
But there were some pieces missing.

14
00:00:56,030 --> 00:00:58,799
So, I'm just gonna recap
what we did previously

15
00:00:58,799 --> 00:01:00,749
and then move on to the new stuff

16
00:01:00,749 --> 00:01:03,370
which is the speech codec and cipher

17
00:01:03,370 --> 00:01:06,850
reverse engineering and cracking
that's been done.

18
00:01:06,850 --> 00:01:09,819
First, what is GMR exactly?

19
00:01:09,819 --> 00:01:12,810
GMR stands for GEO-Mobile Radio and

20
00:01:12,810 --> 00:01:16,849
it's an ETSI standard
for satellite phones.

21
00:01:16,849 --> 00:01:19,430
It's heavily inspired from GSM and

22
00:01:19,430 --> 00:01:21,339
if you read the GMR specs

23
00:01:21,339 --> 00:01:23,850
there is plenty of reference
to go see the GSM spec.

24
00:01:23,850 --> 00:01:27,110
There is actually two standards named GMR:

25
00:01:27,110 --> 00:01:28,800
GMR-1 and GMR-2.

26
00:01:28,800 --> 00:01:31,010
They are not an evolution of one another.

27
00:01:31,010 --> 00:01:32,899
They are competing standards

28
00:01:32,899 --> 00:01:35,180
that have been developed
by distinct companies

29
00:01:35,180 --> 00:01:38,110
and then both have been
standardized to ETSI.

30
00:01:38,110 --> 00:01:41,380
Today, we're gonna be looking
at GMR-1.

31
00:01:41,380 --> 00:01:46,420
That comes in 3 evolutions.
It started with plain old GMR-1

32
00:01:46,420 --> 00:01:49,230
which is voice calls and SMS.

33
00:01:49,230 --> 00:01:52,820
It evolved to include packet data.
That's called GMPRS.

34
00:01:52,820 --> 00:01:55,040
And then there was a later evolution

35
00:01:55,040 --> 00:01:57,570
to interconnect with the 3G core network

36
00:01:57,570 --> 00:02:01,470
and improve the air interface
and that's GMR-1 3G.

37
00:02:01,470 --> 00:02:04,280
But we'll be mostly looking at
the first version

38
00:02:04,280 --> 00:02:07,508
which is still used.

39
00:02:08,778 --> 00:02:13,350
Among the deployments the one
we focused on was Thuraya.

40
00:02:13,350 --> 00:02:16,460
The reason why is that
it's the most common

41
00:02:16,460 --> 00:02:19,099
commercial operator
where you can actually buy SIM

42
00:02:19,099 --> 00:02:20,800
and place phone calls.

43
00:02:20,800 --> 00:02:23,200
The satellites are visible from Europe

44
00:02:23,200 --> 00:02:26,950
which is kind of a requirement for me
to look at the signal.

45
00:02:26,950 --> 00:02:31,376
This operator is mostly active in the
middle east, Asia and Africa.

46
00:02:31,376 --> 00:02:33,929
In Europe you don't see too many people

47
00:02:33,929 --> 00:02:37,279
with satellite phones
because we have GSM coverage.

48
00:02:37,279 --> 00:02:40,659
But there are other operators
and we actually read recently

49
00:02:40,659 --> 00:02:44,370
that there is a new deployment
planned for Europe

50
00:02:44,370 --> 00:02:46,920
called Solaris Mobile and they said

51
00:02:46,920 --> 00:02:49,899
they're going to use GRM-1 3G

52
00:02:49,899 --> 00:02:52,920
but the satellite isn't launched yet.

53
00:02:53,110 --> 00:02:55,590
This is the coverage zone for Thuraya.

54
00:02:55,590 --> 00:02:58,499
As you can see Europe is very well covered

55
00:02:58,499 --> 00:03:01,219
so there is no problem if you want to
receive the signal.

56
00:03:01,219 --> 00:03:04,299
If you are somewhere in that area
you can see it.

57
00:03:04,299 --> 00:03:07,309
So, since it's so heavily inspired by GSM

58
00:03:07,309 --> 00:03:09,960
it makes sense to compare it to it.

59
00:03:09,960 --> 00:03:13,469
The first thing they did is to
rename everything.

60
00:03:13,469 --> 00:03:15,950
So, instead of a base transceiver station

61
00:03:15,950 --> 00:03:17,719
you have a GEO transceiver station.

62
00:03:17,719 --> 00:03:19,559
Instead of a base station controller

63
00:03:19,559 --> 00:03:21,769
you have a GEO station controller.

64
00:03:21,769 --> 00:03:25,599
Instead of a mobile station
you have a mobile earth station.

65
00:03:25,599 --> 00:03:29,580
Then they did some actual
useful stuff like

66
00:03:29,580 --> 00:03:32,379
use specialized features for satellites.

67
00:03:32,379 --> 00:03:35,149
The first one is
terminal-to-terminal calls.

68
00:03:35,149 --> 00:03:37,340
When you're usually placing a call

69
00:03:37,340 --> 00:03:40,159
your signal goes from your
satellite phone to the satellite

70
00:03:40,159 --> 00:03:43,180
then it goes back to the
core network on earth

71
00:03:43,180 --> 00:03:46,159
and then, if you're calling
another satellite phone

72
00:03:46,159 --> 00:03:48,849
it would have to again go
back up to the satellite

73
00:03:48,849 --> 00:03:51,389
and back to the other phone
and that means that

74
00:03:51,389 --> 00:03:54,130
you pay 4 trips from earth to space

75
00:03:54,130 --> 00:03:56,849
and since the satellite is in
geosynchronous orbit

76
00:03:56,849 --> 00:03:58,989
it's pretty far away.

77
00:03:58,989 --> 00:04:01,879
So, to reduce the delay in communication

78
00:04:01,879 --> 00:04:06,450
they have the so-called
terminal-to-terminal calls where

79
00:04:06,450 --> 00:04:09,140
the call network will still
handle establishing

80
00:04:09,140 --> 00:04:12,209
the channel but once
the call is established

81
00:04:12,209 --> 00:04:14,989
the data is going directly
from one phone to the satellite

82
00:04:14,989 --> 00:04:17,660
and directly back down to the other phone

83
00:04:17,660 --> 00:04:19,758
without any involvement from the network.

84
00:04:19,768 --> 00:04:21,990
It never even sees the packets.

85
00:04:21,990 --> 00:04:26,169
They also have this call called
“High Penetration Alerting”

86
00:04:26,169 --> 00:04:29,189
That's because like in the movies
you see people using

87
00:04:29,189 --> 00:04:31,599
satellite phones in bunkers
and stuff like that

88
00:04:31,599 --> 00:04:34,379
in practice, as soon as you are inside

89
00:04:34,379 --> 00:04:37,430
you can't see the satellite and
you can't place a call at all

90
00:04:37,430 --> 00:04:40,009
but you still might want to
be able to at least…

91
00:04:40,009 --> 00:04:41,990
you know, you can't pick up the phone

92
00:04:41,990 --> 00:04:44,949
but you want to know that
somebody is calling you

93
00:04:44,949 --> 00:04:47,560
and so they have this specialized channel

94
00:04:47,560 --> 00:04:51,419
which has an incredible amount
of error correction on it

95
00:04:51,419 --> 00:04:53,620
so that even with very very low signal

96
00:04:53,620 --> 00:04:57,350
you can still get an indication
that somebody is trying to call you

97
00:04:57,350 --> 00:05:01,270
please run outside so
you can take the call.

98
00:05:01,270 --> 00:05:04,420
There's also a very
tight integration to GPS

99
00:05:04,420 --> 00:05:07,309
For example, all the Almanac
and Ephemeris data

100
00:05:07,309 --> 00:05:09,700
are actually broadcasted
by the Thuraya satellite

101
00:05:09,700 --> 00:05:11,889
so that your phone can get a lock faster

102
00:05:11,889 --> 00:05:14,670
and when you place a phone call
the very first thing

103
00:05:14,670 --> 00:05:19,049
that your phone will do
is send your exact GPS coordinates

104
00:05:19,049 --> 00:05:22,409
in clear to the operator.

105
00:05:22,909 --> 00:05:25,229
They do this for two reasons:

106
00:05:25,229 --> 00:05:28,949
The first one is:
If you're not on the right frequency

107
00:05:28,949 --> 00:05:31,969
for this particular geographic location
they can tell you

108
00:05:31,969 --> 00:05:34,470
“OK. You shouldn't be connecting
on this frequency

109
00:05:34,470 --> 00:05:36,860
use this one! It has a much better signal

110
00:05:36,860 --> 00:05:38,939
and you get better quality”.

111
00:05:38,939 --> 00:05:42,399
That's one reason.
The other reason is purely commercial:

112
00:05:42,399 --> 00:05:44,740
It's for billing because if you're calling

113
00:05:44,740 --> 00:05:47,349
while you are in certain countries
it's gonna cost more

114
00:05:47,349 --> 00:05:49,609
than if you are on the other side
of the border

115
00:05:49,609 --> 00:05:51,600
and so they need to know where you are

116
00:05:51,600 --> 00:05:52,979
to bill you correctly.

117
00:05:52,979 --> 00:05:55,580
And then compared to GSM,
of course, they introduced

118
00:05:55,580 --> 00:05:57,620
the two things we're gonna look at today:

119
00:05:57,620 --> 00:06:01,199
They changed the speech codec
to something called AMBE

120
00:06:01,199 --> 00:06:03,740
and they changed the cipher.
They are not using A5/1

121
00:06:03,740 --> 00:06:06,269
or A5/2 or A5/3 or that kind of stuff.

122
00:06:06,269 --> 00:06:10,040
They use something called A5/GMR-1.

123
00:06:10,300 --> 00:06:13,419
If you look at the protocol stack

124
00:06:13,419 --> 00:06:15,400
anything in the lower layers

125
00:06:15,400 --> 00:06:18,430
(radio modulation, TDMA frame structure)

126
00:06:18,430 --> 00:06:21,439
it's completely different
because you have to deal with

127
00:06:21,439 --> 00:06:24,369
the particular of the
satellite communication.

128
00:06:24,369 --> 00:06:26,379
You find the same kind of concept

129
00:06:26,379 --> 00:06:29,110
and you find the control channels
and broadcast channels

130
00:06:29,110 --> 00:06:31,960
but their implementation is different.

131
00:06:31,960 --> 00:06:35,039
If you go up one layer
to the data link layer

132
00:06:35,039 --> 00:06:39,319
you have something very similar to LAPDm.

133
00:06:39,319 --> 00:06:42,749
Again, they needed some minor adaptation

134
00:06:42,749 --> 00:06:44,960
because bandwidth costs a lot
on a satellite.

135
00:06:44,960 --> 00:06:48,030
They reduce the size of the overhead
by reducing the header

136
00:06:48,030 --> 00:06:50,039
and since you have so much delay

137
00:06:50,039 --> 00:06:52,620
going from your phone to the satellite and

138
00:06:52,620 --> 00:06:55,590
back down to the earth station
then again to your phone

139
00:06:55,590 --> 00:07:00,439
you have something like
nearly 500 ms of delay

140
00:07:00,439 --> 00:07:05,099
because you have basically 4…
no 250 ms, sorry,

141
00:07:05,099 --> 00:07:10,330
because you have both paths up and down

142
00:07:10,330 --> 00:07:13,789
and so, with that delay you need more
time for the acknowledgement

143
00:07:13,789 --> 00:07:17,389
to come in,
so they increased the window size.

144
00:07:17,389 --> 00:07:19,440
Anything above that, so, layer 3

145
00:07:19,440 --> 00:07:22,170
radio resource, since
it's managed the radio channel

146
00:07:22,170 --> 00:07:24,599
is still a bit different
but anything above that

147
00:07:24,599 --> 00:07:28,279
is strictly the same as GSM.
It actually interoperates

148
00:07:28,279 --> 00:07:30,589
with the GSM core network
which means I can take

149
00:07:30,589 --> 00:07:33,819
my Belgian operator SIM
put it into a Thuraya phone

150
00:07:33,819 --> 00:07:37,620
and I can roam onto the satellite
and place calls

151
00:07:37,620 --> 00:07:40,400
which is really nice
except for the price you pay

152
00:07:40,400 --> 00:07:42,809
at the end of the month.

153
00:07:42,809 --> 00:07:45,519
For packet data it's essentially
the same thing.

154
00:07:45,519 --> 00:07:47,479
Anything that's close to the lower level

155
00:07:47,479 --> 00:07:50,219
like RLC and MAC is gonna be different,

156
00:07:50,219 --> 00:07:52,599
anything above interoperates with GSM

157
00:07:52,599 --> 00:07:55,829
so you're gonna be speaking to
a GSM core network

158
00:07:55,829 --> 00:07:59,939
SGSN and GGSN and all that good stuff.

159
00:07:59,939 --> 00:08:05,349
So, osmo-gmr, what we presented last time,

160
00:08:05,349 --> 00:08:10,319
is essentially everything you needed to go
from RF to wireshark.

161
00:08:10,319 --> 00:08:13,460
That includes the hardware setup

162
00:08:13,460 --> 00:08:19,949
(how you can build an antenna,
what LNA to use, what SDR receiver to use)

163
00:08:19,949 --> 00:08:22,849
At that time we didn't
actually have RTL-SDR,

164
00:08:22,849 --> 00:08:25,740
the cheap DVB dongle you can use as SDR.

165
00:08:25,740 --> 00:08:29,379
Nowadays we do which means that
for less than 100 bucks

166
00:08:29,379 --> 00:08:32,900
you can get an antenna,
LNA and SDR receiver and all

167
00:08:32,900 --> 00:08:36,040
that we need to listen to those signals.

168
00:08:36,040 --> 00:08:38,599
Then we did all the
SDR processing which is

169
00:08:38,599 --> 00:08:41,470
taking that raw data, filtering it,
selecting the channel

170
00:08:41,470 --> 00:08:45,350
doing the demodulation
getting actual data bits out of it.

171
00:08:45,350 --> 00:08:48,480
Then, channel coding which is
converting those data bits into

172
00:08:48,480 --> 00:08:52,380
layer 2 frames. Then,
interpreting those layer 2 frames

173
00:08:52,380 --> 00:08:55,560
into channel assignment
and follow those assignments

174
00:08:55,560 --> 00:08:58,650
into a demonstration application.

175
00:08:58,650 --> 00:09:01,880
And finally, the wireshark dissector
which takes this

176
00:09:01,880 --> 00:09:05,460
and presents it nicely in a way
you can read stuff.

177
00:09:05,460 --> 00:09:08,680
But there is two things we couldn't do:

178
00:09:08,680 --> 00:09:11,310
First, we couldn't see past the
ciphering mode command

179
00:09:11,310 --> 00:09:13,529
which as soon as ciphering was enabled

180
00:09:13,529 --> 00:09:15,630
we couldn't see anything because

181
00:09:15,630 --> 00:09:18,310
we knew the key because
it was our own calls

182
00:09:18,310 --> 00:09:20,319
and we can read the key from the SIM

183
00:09:20,319 --> 00:09:23,160
but we didn't know the algorithm
that was used to cipher

184
00:09:23,160 --> 00:09:26,380
so there was no way for us to
decipher that.

185
00:09:26,380 --> 00:09:29,350
And we also had no way to
get the voice data,

186
00:09:29,350 --> 00:09:33,070
converting the frame into
actual audio that we can listen to

187
00:09:33,070 --> 00:09:37,900
We couldn't do that and that's
what we're gonna look into.

188
00:09:38,470 --> 00:09:44,320
So the first thing is the speech codec.

189
00:09:46,270 --> 00:09:50,959
It's called AMBE for
Advanced Multi-Band Excitation.

190
00:09:50,959 --> 00:09:55,960
It's not a codec in itself.
AMBE is more a family of codecs

191
00:09:55,960 --> 00:09:59,570
which means you have several codecs
which are named AMBE

192
00:09:59,570 --> 00:10:02,220
which are different versions
of one another

193
00:10:02,220 --> 00:10:05,410
slightly different so that
they're not compatible.

194
00:10:05,410 --> 00:10:08,330
It's not documented in the standard

195
00:10:08,330 --> 00:10:11,749
which is really annoying.
When I started working on GMR

196
00:10:11,749 --> 00:10:15,490
I really thought that
the codec was in there

197
00:10:15,490 --> 00:10:19,570
and then I discovered it wasn't.
That was a bad day.

198
00:10:19,570 --> 00:10:23,250
There is a bit of specification in there

199
00:10:23,250 --> 00:10:26,810
but it only gives a high level
description like

200
00:10:26,810 --> 00:10:31,119
“The codec takes audio as input
and produces 80 bits of output

201
00:10:31,119 --> 00:10:34,940
every 20 ms” but nothing
that can be used to

202
00:10:34,940 --> 00:10:39,470
realistically implement a decoder.

203
00:10:40,650 --> 00:10:44,290
That codec is made by a company DVSI Inc.

204
00:10:44,290 --> 00:10:48,529
whose entire business is codecs.
That's all they do

205
00:10:48,529 --> 00:10:51,410
which is probably why there are
incompatible versions

206
00:10:51,410 --> 00:10:54,660
of AMBE because they can
sell different versions.

207
00:10:54,660 --> 00:10:58,999
These guys, they do sell
a small USB stick that

208
00:10:58,999 --> 00:11:02,440
can decode some of the variants.
For example, you can decode

209
00:11:02,440 --> 00:11:06,660
DStar audio which is also
another AMBE codec

210
00:11:06,660 --> 00:11:11,320
or P25 which is used in
law enforcement radio in the US

211
00:11:11,320 --> 00:11:13,610
(it's also an AMBE variant)

212
00:11:13,610 --> 00:11:16,620
and the cheap USB stick can decode that.

213
00:11:16,620 --> 00:11:19,779
Unfortunately, it's incompatible
with the GMR-1 variant

214
00:11:19,779 --> 00:11:22,329
because that's the first thing I did,
I contacted DVSI

215
00:11:22,329 --> 00:11:24,850
to know what were my options.

216
00:11:24,850 --> 00:11:31,010
And short of buying a source code license
which is just too expensive

217
00:11:31,760 --> 00:11:35,469
is buying the appliance
which is called NET-2000.

218
00:11:35,469 --> 00:11:39,029
And not only does it cost like 2000 Euros

219
00:11:39,029 --> 00:11:42,850
which is way too much for a hobby project

220
00:11:42,850 --> 00:11:46,290
but you also have to special-order it
with a GMR-1 firmware

221
00:11:46,290 --> 00:11:50,080
and you have to sign some
non-reverse engineering agreement

222
00:11:50,080 --> 00:11:53,590
which… That wasn't an option.

223
00:11:53,590 --> 00:11:57,480
We still had some hope.
The first hope we had is that

224
00:11:57,480 --> 00:12:03,210
as I said P25 uses an AMBE variant as well

225
00:12:03,210 --> 00:12:06,790
and this particular variant
is actually documented.

226
00:12:06,790 --> 00:12:11,180
So you can download the standard
for that particular

227
00:12:11,180 --> 00:12:15,199
variant of AMBE and you have
all the math and all the specs

228
00:12:15,199 --> 00:12:18,459
so you can write a decoder
and somebody actually wrote

229
00:12:18,459 --> 00:12:21,870
a decoder which is open source
which is called ambelib

230
00:12:21,870 --> 00:12:27,670
and so we can use that code as a base
to modify it. That was a lead.

231
00:12:27,670 --> 00:12:31,730
The other lead, of course, is that the
codec is somewhere in the phone.

232
00:12:31,730 --> 00:12:33,940
The phone is obviously capable
of decoding audio

233
00:12:33,940 --> 00:12:37,000
so maybe we can find it in there.

234
00:12:37,000 --> 00:12:40,939
But before we can start
searching for the codec

235
00:12:40,939 --> 00:12:45,250
it's good to have a basic understanding
of how the codec works

236
00:12:45,250 --> 00:12:47,899
so that we know what we're looking for.

237
00:12:47,899 --> 00:12:50,400
The first thing to understand:
it's a vocoder.

238
00:12:50,400 --> 00:12:53,120
It's not a general-purpose audio codec

239
00:12:53,120 --> 00:12:58,000
which means if you try to feed it music
it's gonna perform horribly

240
00:12:58,000 --> 00:13:01,380
because a general-purpose
audio codec will try to model

241
00:13:01,380 --> 00:13:06,300
what your ear can actually hear
and what it can't

242
00:13:06,300 --> 00:13:10,250
whereas a vocoder is gonna try
to model the speech

243
00:13:10,250 --> 00:13:12,949
and reconstructs
something that sounds like

244
00:13:12,949 --> 00:13:15,519
but is not actually the same thing.

245
00:13:15,519 --> 00:13:18,649
They will drop a lot of information.

246
00:13:18,649 --> 00:13:23,060
To do that the first thing they do
is to split your speech

247
00:13:23,060 --> 00:13:25,850
into small segments which are
compressed independently.

248
00:13:25,850 --> 00:13:31,920
In the case of GMR-1
those segments are 10 ms long and

249
00:13:31,920 --> 00:13:36,610
they are combined by pair
and each pair is compressed

250
00:13:36,610 --> 00:13:40,800
into a single frame. And then,
for each of those small segments

251
00:13:40,800 --> 00:13:45,740
they will represent it in 4 parameters.
Those 4 parameters are

252
00:13:45,740 --> 00:13:52,389
the pitch which is the
fundamental frequency

253
00:13:52,389 --> 00:13:56,089
of the periodic component of your voice,

254
00:13:56,089 --> 00:13:58,889
the gain which is
how loud you are talking,

255
00:13:58,889 --> 00:14:01,429
something called
voiced/unvoiced decision,

256
00:14:01,429 --> 00:14:03,700
we're gonna see what this is right after

257
00:14:03,700 --> 00:14:06,899
but essentially you have the
fundamental frequency

258
00:14:06,899 --> 00:14:08,990
and for each harmonic,
two times the frequency,

259
00:14:08,990 --> 00:14:11,339
three times the frequency,
four times the frequency,

260
00:14:11,339 --> 00:14:16,300
you have a bit that says
is that component voiced or unvoiced

261
00:14:16,300 --> 00:14:21,730
and then you have the amplitudes
for the various harmonics.

262
00:14:22,420 --> 00:14:26,520
If you want to play back the voice
you have to do 3 things:

263
00:14:26,520 --> 00:14:29,319
The first thing is unpacking.

264
00:14:29,319 --> 00:14:33,420
That's taking the 80 bits
of the voice frame

265
00:14:33,420 --> 00:14:36,639
and reconstruct quantized
parameters from it.

266
00:14:36,639 --> 00:14:40,290
All the parameters are not just
put in order one after the other

267
00:14:40,290 --> 00:14:43,259
because some of the bits in a frame
will receive more error correction

268
00:14:43,259 --> 00:14:47,230
than others and some of the bits
are more sensitive to errors than others

269
00:14:47,230 --> 00:14:51,269
and so they will be placed at
specific places in the frame

270
00:14:51,269 --> 00:14:54,720
so that if errors do happen,
hopefully it will affect something

271
00:14:54,720 --> 00:14:57,190
that is not too important.

272
00:14:57,190 --> 00:14:59,629
That's the unpacking step.

273
00:14:59,629 --> 00:15:01,949
The second one is dequantization.

274
00:15:01,949 --> 00:15:04,960
That's going from the quantized,
compressed parameters

275
00:15:04,960 --> 00:15:08,590
into floating point value
or integer values

276
00:15:08,590 --> 00:15:10,899
which will represent the real parameters

277
00:15:10,899 --> 00:15:13,110
that are going to be used in the last step

278
00:15:13,110 --> 00:15:16,699
which is synthesis. And synthesis
is taking those parameters

279
00:15:16,699 --> 00:15:23,069
and reconstructing actual audio
that sounds like the original voice.

280
00:15:23,410 --> 00:15:26,459
To do a quick overview
of the synthesis step

281
00:15:26,459 --> 00:15:29,420
what you do is you take
for each possible harmonic,

282
00:15:29,420 --> 00:15:32,470
so, f0, 2 f0, 3 f0,…

283
00:15:32,470 --> 00:15:36,319
you have the voiced/unvoiced decision

284
00:15:36,319 --> 00:15:39,870
and what voiced means is
that you're gonna reconstruct

285
00:15:39,870 --> 00:15:43,389
that particular frequency
as a pure sinusoidal tone,

286
00:15:43,389 --> 00:15:49,600
and if it's unvoiced you're just gonna
fill that small band with noise.

287
00:15:49,600 --> 00:15:55,129
And with that they can reconstruct
human voice pretty well.

288
00:15:55,129 --> 00:16:00,320
So, now that we know more or less
how the codec works

289
00:16:00,320 --> 00:16:02,679
and what we are looking for

290
00:16:02,679 --> 00:16:08,130
we can start looking at
where we are gonna find this codec.

291
00:16:08,130 --> 00:16:13,340
The phone we looked at is
the Thuraya SO-2510.

292
00:16:13,340 --> 00:16:16,830
We looked at it mostly because
it was the cheapest phone on eBay.

293
00:16:16,830 --> 00:16:20,090
And that also means that it's the simplest

294
00:16:20,090 --> 00:16:25,480
which means you have
less places to look into.

295
00:16:26,059 --> 00:16:30,600
We knew the codec was in the DSP.
How did we know that is that

296
00:16:30,600 --> 00:16:33,399
there is simply no other places it could be.

297
00:16:33,399 --> 00:16:36,889
There are a bunch of chips on that phone, of course,

298
00:16:36,889 --> 00:16:39,769
there is only two where it could possibly be:

299
00:16:39,769 --> 00:16:42,069
the TI OMAP main processor,

300
00:16:42,069 --> 00:16:44,290
and then they also have like a small ASIC

301
00:16:44,290 --> 00:16:46,459
which is named the DALMA ASIC because

302
00:16:46,459 --> 00:16:49,779
there is a big DALMA marking on it.

303
00:16:49,779 --> 00:16:53,870
At first, we thought that
that chip was the AMBE codec.

304
00:16:53,870 --> 00:16:58,139
But it turned out that
we found some Korean paper

305
00:16:58,139 --> 00:17:00,029
from the phone manufacturer
that described

306
00:17:00,029 --> 00:17:02,439
the phone architecture.
And there is a schematic

307
00:17:02,439 --> 00:17:05,020
of the internals of that ASIC
and it showed

308
00:17:05,020 --> 00:17:07,589
it only had satellite radio functions

309
00:17:07,589 --> 00:17:09,910
and absolutely nothing
to do with the codec

310
00:17:09,910 --> 00:17:13,670
which means there was a good chance
it was in the TI OMAP processor.

311
00:17:13,670 --> 00:17:17,170
Why in the DSP? Well, because
it just makes sense

312
00:17:17,170 --> 00:17:20,260
to make the codec in the DSP
especially since DVSI

313
00:17:20,260 --> 00:17:25,450
the company that makes the codec
mostly sells those codecs as a

314
00:17:25,450 --> 00:17:30,360
DSP precompiled library that you can buy.

315
00:17:30,550 --> 00:17:38,520
Pretty standard process: We get the
firmware update from the Internet.

316
00:17:38,520 --> 00:17:42,280
From there we can extract
the actual DSP image

317
00:17:42,280 --> 00:17:46,000
which is the code that is
loaded into the DSP.

318
00:17:46,000 --> 00:17:47,960
Thankfully it's supported by IDA

319
00:17:47,960 --> 00:17:50,770
which makes the whole process
easier to reverse engineer.

320
00:17:50,770 --> 00:17:54,360
But it's still like 250KB of binary data

321
00:17:54,360 --> 00:17:56,870
and since it's a DSP it has no I/O

322
00:17:56,870 --> 00:18:01,220
which means there is not
a single string in it.

323
00:18:01,220 --> 00:18:04,960
And also it's a DSP which means
it's written in DSP assembly.

324
00:18:04,960 --> 00:18:08,070
I don't know if you ever
tried to read that

325
00:18:08,070 --> 00:18:12,930
but it's not the most
understandable thing in the world

326
00:18:12,930 --> 00:18:16,420
because it's highly optimized
for speed, of course.

327
00:18:16,420 --> 00:18:19,400
And I actually looked at that
code and went over it a few times

328
00:18:19,400 --> 00:18:22,000
and took a few hours and looked at it

329
00:18:22,000 --> 00:18:25,240
and I couldn't see anything in it.

330
00:18:25,240 --> 00:18:30,700
And one day I get an email
from a colleague in OSMOCOM,

331
00:18:30,700 --> 00:18:34,640
Dieter Spaar, asking me
if I had ever looked at that codec

332
00:18:34,640 --> 00:18:36,550
and I told him “yeah I looked

333
00:18:36,550 --> 00:18:38,330
but I couldn't really find anything.

334
00:18:38,330 --> 00:18:40,500
Do you see anything?”

335
00:18:40,500 --> 00:18:42,180
And six hours later he sent me

336
00:18:42,180 --> 00:18:43,950
“I think this is the entry point

337
00:18:43,950 --> 00:18:46,330
for the encoding and decoding functions”

338
00:18:46,330 --> 00:18:48,880
“Oh, OK. Good!”

339
00:18:48,880 --> 00:18:53,060
The way he found that
from what I remember is that

340
00:18:53,060 --> 00:18:56,640
you look at what would a codec use.

341
00:18:56,640 --> 00:18:59,930
And of course it's gonna
access the audio path

342
00:18:59,930 --> 00:19:05,850
so you can look at the audio DMA setup,
and audio DMA interrupts.

343
00:19:05,850 --> 00:19:09,110
You can also look for constants
that you know are used in the codec,

344
00:19:09,110 --> 00:19:12,450
for example, I said that
the frames are 80 bits,

345
00:19:12,450 --> 00:19:15,170
so you can look for the constant 80
somewhere in the code.

346
00:19:15,170 --> 00:19:16,590
You can look at it.

347
00:19:16,590 --> 00:19:20,350
It will produce 160 audio samples
per frame decoded

348
00:19:20,350 --> 00:19:23,400
so you can look at the constant 160.

349
00:19:23,400 --> 00:19:26,170
Once you actually found one function

350
00:19:26,170 --> 00:19:28,970
there is something
that kind of stands out,

351
00:19:28,970 --> 00:19:32,330
it's that since they ship that
as a binary library

352
00:19:32,330 --> 00:19:36,800
they don't really trust the guy
who implements the rest of the DSP code

353
00:19:36,800 --> 00:19:38,940
to setup the C runtime properly

354
00:19:38,940 --> 00:19:43,230
and so what they do is they switch
everything at each call into the codec.

355
00:19:43,230 --> 00:19:48,260
They switch the stack, they
re-setup/reconfigure the C runtime,

356
00:19:48,260 --> 00:19:50,560
so that it's really independent.

357
00:19:50,560 --> 00:19:53,870
Once you find one function,
finding the other is pretty easy,

358
00:19:53,870 --> 00:19:59,730
you can just look for that
particular function prelude

359
00:19:59,730 --> 00:20:06,530
that happens at each call at
the audio library.

360
00:20:06,530 --> 00:20:11,000
OK, so, we know where the code is

361
00:20:11,000 --> 00:20:12,930
but it's still a massive amount of code.

362
00:20:12,930 --> 00:20:17,680
I think it's like one third of
the DSP code is the audio codec.

363
00:20:17,680 --> 00:20:24,180
So, It's not something you can easily
reverse engineer in a few hours.

364
00:20:24,180 --> 00:20:29,120
So, before trying reverse
engineering we just tried,

365
00:20:29,120 --> 00:20:31,790
OK, maybe we can just run it.

366
00:20:31,790 --> 00:20:34,810
It turns out that TI has this
really nice program called

367
00:20:34,810 --> 00:20:38,550
TI Code Composer Studio
which includes a simulator

368
00:20:38,550 --> 00:20:42,960
and it's a really nice piece
of software because

369
00:20:42,960 --> 00:20:47,060
not only can you pretty accurately
simulate any of the DSPs

370
00:20:47,060 --> 00:20:51,220
you can also completely configure
the surrounding environment

371
00:20:51,220 --> 00:20:55,670
in which it runs so you can setup
arbitrary memory map.

372
00:20:55,670 --> 00:20:59,400
You can also trace all memory access
to see what part

373
00:20:59,400 --> 00:21:03,910
of memory is being read or being written
or being executed.

374
00:21:03,910 --> 00:21:07,240
You can also access a file
on your host system.

375
00:21:07,240 --> 00:21:09,010
So you can use fread and fwrite

376
00:21:09,010 --> 00:21:11,890
and the simulator would
automatically translate those calls

377
00:21:11,890 --> 00:21:16,890
into actual reading from the audio,
hard drive and write to your hard drive

378
00:21:16,890 --> 00:21:22,470
so you can read a compressed
file that you saved

379
00:21:22,470 --> 00:21:28,250
and it will write an audio
wave file at the output.

380
00:21:28,250 --> 00:21:32,230
And the way to do that is
pretty straightforward.

381
00:21:32,230 --> 00:21:35,130
You essentially just need to
take the binary dump that

382
00:21:35,130 --> 00:21:38,950
you have from the firmware update

383
00:21:38,950 --> 00:21:45,040
and you need to find a way to
mix in your own custom code.

384
00:21:45,040 --> 00:21:51,380
The way to do that: You create
a new object file like ELF

385
00:21:51,380 --> 00:21:55,090
except in this case it's called COFF,
a common object file format.

386
00:21:55,090 --> 00:21:57,680
But it's the same idea.

387
00:21:57,680 --> 00:22:04,790
You can just link to it like you would
link any other piece of binary.

388
00:22:04,980 --> 00:22:07,180
You write a simple main function

389
00:22:07,180 --> 00:22:12,010
that will basically fread your
compressed samples,

390
00:22:12,010 --> 00:22:15,180
call the decoding function
or at least what you hope

391
00:22:15,180 --> 00:22:19,660
is the decoding function
and fwrite the audio samples.

392
00:22:19,660 --> 00:22:24,670
And surprisingly it worked.
It didn't require that much effort.

393
00:22:24,670 --> 00:22:27,860
In like a couple of days
it was all working.

394
00:22:27,860 --> 00:22:32,950
It didn't work on the first try.
There was a couple of pitfalls.

395
00:22:32,950 --> 00:22:37,010
But essentially the IDE is there
and it can probably be applied

396
00:22:37,010 --> 00:22:39,580
to other things as well.

397
00:22:39,580 --> 00:22:42,160
Of course there is some
pretty big downsides.

398
00:22:42,160 --> 00:22:46,410
At first, it's pretty slow.
Definitely sub-real-time

399
00:22:46,410 --> 00:22:50,550
even on a modern laptop.

400
00:22:50,550 --> 00:22:53,630
It also requires TI Code Composer Studio

401
00:22:53,630 --> 00:22:58,160
which is a Windows application
and it's also not free.

402
00:22:58,160 --> 00:23:02,050
You have a 30 days evaluation period
but that's about it.

403
00:23:02,050 --> 00:23:05,200
So it's really not that practical.

404
00:23:05,200 --> 00:23:07,550
But it was running in the simulator.

405
00:23:07,550 --> 00:23:10,880
There is no real reason
it cannot run on real hardware.

406
00:23:10,880 --> 00:23:14,360
Of course, that's what we try next.

407
00:23:14,360 --> 00:23:16,800
Unfortunately, on real hardware

408
00:23:16,800 --> 00:23:20,380
you can't just put memory
anywhere you want.

409
00:23:20,380 --> 00:23:24,080
When the codec runs in the phone,

410
00:23:24,080 --> 00:23:28,640
it runs inside a TI-OMAP
which is an ARM plus a DSP

411
00:23:28,640 --> 00:23:31,250
and that chip has an MMU
which means

412
00:23:31,250 --> 00:23:35,480
you can create
any virtual memory you want.

413
00:23:35,480 --> 00:23:38,880
But if you're trying to run
on a cheap DSP board

414
00:23:38,880 --> 00:23:42,420
that you can get for 50 bucks,

415
00:23:42,420 --> 00:23:45,530
those usually don't include an MMU at all

416
00:23:45,530 --> 00:23:47,640
which means you need to find a board

417
00:23:47,640 --> 00:23:49,640
which has memory
at the right places

418
00:23:49,640 --> 00:23:54,970
because the binary you have has been
linked to a specific physical addresses

419
00:23:54,970 --> 00:23:58,500
and it needs to run at
that particular addresses.

420
00:23:58,500 --> 00:24:05,920
Thankfully, Dieter found one such board
with a compatible memory map

421
00:24:05,920 --> 00:24:11,520
and it had SDRAM.
Well, we needed it to have some memory.

422
00:24:11,520 --> 00:24:17,370
It also included Ethernet which means
we can make some networked appliance

423
00:24:17,370 --> 00:24:20,390
where we submit samples and get them back.

424
00:24:20,390 --> 00:24:22,800
That was really nice.

425
00:24:22,800 --> 00:24:25,640
The process of migrating the code
from the simulator

426
00:24:25,640 --> 00:24:28,650
to the board is actually
pretty smooth because

427
00:24:28,650 --> 00:24:31,500
of the way TI Code Composer Studio works.

428
00:24:31,500 --> 00:24:34,090
You just basically select that as a target

429
00:24:34,090 --> 00:24:39,500
and since the memory was at the right
place it pretty much worked.

430
00:24:39,500 --> 00:24:42,680
Now, it wasn't quite as fast as we want it

431
00:24:42,680 --> 00:24:47,570
because it was only running
about real-time at the first try

432
00:24:47,570 --> 00:24:51,890
and that's because SDRAM is slow
especially when you do

433
00:24:51,890 --> 00:24:56,650
a bunch of random accesses
the SDRAM isn't really fast.

434
00:24:56,650 --> 00:25:00,390
The codec has unfortunately
a lot of big data tables

435
00:25:00,390 --> 00:25:05,320
which are accessed constantly
like to compute cosines.

436
00:25:05,320 --> 00:25:10,030
So, what Dieter did is basically
identify a couple

437
00:25:10,030 --> 00:25:13,790
of those big tables
that are accessed very often

438
00:25:13,790 --> 00:25:16,370
and then just migrated them
to internal SRAM.

439
00:25:16,370 --> 00:25:19,470
You just find the one or two places

440
00:25:19,470 --> 00:25:22,190
where the code reads from those tables

441
00:25:22,190 --> 00:25:25,730
and just patch the address to another address

442
00:25:25,730 --> 00:25:28,510
and redirect it to there.

443
00:25:28,510 --> 00:25:32,770
And that got the code running much faster,
about 16x faster than real-time.

444
00:25:32,770 --> 00:25:35,040
And honestly, that was good.

445
00:25:35,040 --> 00:25:39,380
I wasn't really planning on doing
anything else on the hardware

446
00:25:39,380 --> 00:25:43,670
and so I ordered the same board…
except I didn't.

447
00:25:43,670 --> 00:25:47,680
I somehow ended up clicking
on the wrong button in the

448
00:25:47,680 --> 00:25:50,370
TI store or something and
when the board arrived

449
00:25:50,370 --> 00:25:53,100
I didn't have the right one.

450
00:25:53,100 --> 00:25:55,846
At that point I had two choices:

451
00:25:55,846 --> 00:25:58,592
I could just order the same board

452
00:25:58,592 --> 00:26:01,080
and wait one more week,

453
00:26:01,080 --> 00:26:04,390
or I could try to run
the code on it anyway.

454
00:26:04,390 --> 00:26:07,270
The second board didn't have Ethernet.
It had USB.

455
00:26:07,270 --> 00:26:09,990
But most importantly it didn't
have any SDRAM at all.

456
00:26:09,990 --> 00:26:12,300
It only had internal SRAM

457
00:26:12,300 --> 00:26:16,170
and unfortunately not at
the right address.

458
00:26:16,170 --> 00:26:21,130
So I just figured: OK.
I'm just gonna try to relocate the binary

459
00:26:21,130 --> 00:26:24,920
and make it run on another address.
How hard can it be?

460
00:26:24,920 --> 00:26:27,850
It turned out to be pretty straightforward
because

461
00:26:27,850 --> 00:26:30,600
in I think less than a day it was running

462
00:26:30,600 --> 00:26:34,200
and that's really thanks to IDAPython
and the simulator.

463
00:26:34,200 --> 00:26:37,540
Basically what I did is in IDAPython
which is the

464
00:26:37,540 --> 00:26:42,440
scripting language in
IDA reverse engineering software

465
00:26:42,440 --> 00:26:46,410
you can iterate through all the opcodes,
then for that

466
00:26:46,410 --> 00:26:50,290
opcode you can test:
Is there an absolute memory reference

467
00:26:50,290 --> 00:26:53,420
somewhere in that opcode?
If no, then don't do anything.

468
00:26:53,420 --> 00:26:56,020
If there is an absolute memory reference,

469
00:26:56,020 --> 00:26:59,520
is that reference falling
somewhere in a place that

470
00:26:59,520 --> 00:27:02,000
I'm trying to relocate or not?
If it is a place

471
00:27:02,000 --> 00:27:04,230
I'm trying to relocate then
just patch that opcode

472
00:27:04,230 --> 00:27:07,490
and change the absolute memory reference
to the new place.

473
00:27:07,490 --> 00:27:10,370
Go through all the code like that
and try to run it.

474
00:27:10,370 --> 00:27:13,390
Of course, it didn't work
the first time around

475
00:27:13,390 --> 00:27:19,530
because there was a couple of
pitfalls in that approach

476
00:27:19,760 --> 00:27:25,430
but using the simulator it was
pretty easy to find out where

477
00:27:25,430 --> 00:27:29,990
things were going wrong because
you take the original code

478
00:27:29,990 --> 00:27:32,910
you run everything in the simulator
and you trace every

479
00:27:32,910 --> 00:27:37,840
memory access, then you take your
potentially relocated code

480
00:27:37,840 --> 00:27:42,320
you run it again in the simulator
and trace every memory access

481
00:27:42,320 --> 00:27:45,480
Decoding the same frame
it should be deterministic

482
00:27:45,480 --> 00:27:49,580
and so you should have the exact same
memory access patterns

483
00:27:49,580 --> 00:27:52,990
in both cases. And as soon as you see
that they are diverging

484
00:27:52,990 --> 00:27:55,700
you know that somewhere
a branch wasn't taken or

485
00:27:55,700 --> 00:27:59,170
something went wrong and
you can go at that place in your code

486
00:27:59,170 --> 00:28:03,040
look and see why the
relocation didn't work.

487
00:28:03,040 --> 00:28:06,950
It only took two tries to
have the code running.

488
00:28:06,950 --> 00:28:10,570
It was running on my board and
I didn't have to order a new one

489
00:28:10,570 --> 00:28:13,220
which was pretty nice.

490
00:28:13,220 --> 00:28:15,760
So we have a hardware USB decoder

491
00:28:15,760 --> 00:28:19,430
which is very useful but
you still have to carry it around

492
00:28:19,430 --> 00:28:23,220
or plug it into a network
server or something

493
00:28:23,220 --> 00:28:26,230
which isn't necessarily
something you want.

494
00:28:26,230 --> 00:28:32,470
I wanted something I could
checkout into git, basically.

495
00:28:32,470 --> 00:28:38,740
So, I started reverse engineering
the entire codec.

496
00:28:38,740 --> 00:28:43,170
Now, it turned out to be very painful.

497
00:28:43,170 --> 00:28:47,310
As I said, to reconstruct audio
you have three main steps.

498
00:28:47,310 --> 00:28:50,960
The first one is unpacking and
it's just basically bit shuffling.

499
00:28:50,960 --> 00:28:54,610
It's like the first thing
the codec does which means

500
00:28:54,610 --> 00:28:58,020
it's really easy to find and
it's really easy to follow.

501
00:28:58,020 --> 00:29:00,020
So, no problem there.

502
00:29:00,020 --> 00:29:04,230
The second step is dequantization
and it took like 95% percent

503
00:29:04,230 --> 00:29:07,970
of the work because it's lot of math.

504
00:29:07,970 --> 00:29:12,000
It's all written in DSP assembly,
in fixed-point

505
00:29:12,000 --> 00:29:15,140
and sometimes you're looking at
a function to figure out

506
00:29:15,140 --> 00:29:18,590
what that function does you
have to run it with different

507
00:29:18,590 --> 00:29:22,610
parameters to see what does
that thing compute.

508
00:29:22,610 --> 00:29:26,040
Graphing is really useful for that.
You just feed some

509
00:29:26,040 --> 00:29:29,140
inputs into the simulator see
what output is generated

510
00:29:29,140 --> 00:29:32,970
and just plot it in PyLab or something.

511
00:29:32,970 --> 00:29:37,240
And then you can see, OK,
that actually computes a logarithm.

512
00:29:37,240 --> 00:29:42,070
There is still a lot of code there
and there was no

513
00:29:42,070 --> 00:29:46,010
other option for that part
because the quantization step

514
00:29:46,010 --> 00:29:49,020
is completely specific to GMR.
It's not shared with any

515
00:29:49,020 --> 00:29:52,130
of the other AMBE variants.

516
00:29:52,130 --> 00:29:55,170
The synthesis part is even
more complicated, is even more

517
00:29:55,170 --> 00:29:58,470
code in the DSP but I really didn't want…

518
00:29:58,470 --> 00:30:01,540
after finishing the dequantization
I really didn't want

519
00:30:01,540 --> 00:30:05,380
to the synthesis, so I just assumed
that the synthesis step

520
00:30:05,380 --> 00:30:08,650
was gonna be very similar
to the one in P25.

521
00:30:08,650 --> 00:30:13,900
So I took the mbelib existing
open-source code for P25,

522
00:30:13,900 --> 00:30:17,860
I ripped out the unpacking
and dequantization out of it.

523
00:30:17,860 --> 00:30:21,300
That's because it's the one for P25,
of course.

524
00:30:21,300 --> 00:30:25,240
I just plugged in my own implementation

525
00:30:25,240 --> 00:30:28,200
and run it through the synthesis.

526
00:30:28,200 --> 00:30:31,480
There's a couple of things
you need to take care of

527
00:30:31,480 --> 00:30:37,810
mostly because P25 uses 20 ms frames,
GMR uses 10 ms frames.

528
00:30:37,810 --> 00:30:42,280
So, I basically dropped one frame
every other frame in GMR

529
00:30:42,280 --> 00:30:46,130
and just used the 10 ms parameter
synthesized 20 ms of speech

530
00:30:46,130 --> 00:30:48,880
but it produced something
where you could follow

531
00:30:48,880 --> 00:30:51,600
a conversation and it worked.

532
00:30:51,600 --> 00:30:55,780
I was still not really happy about it
because the code quality

533
00:30:55,780 --> 00:30:58,670
of mbelib was really not that good.

534
00:30:58,670 --> 00:31:01,420
Its performance is also not that good.

535
00:31:01,420 --> 00:31:05,190
It wasn't actually faster
than the hardware decoder.

536
00:31:05,190 --> 00:31:09,760
So, in the end I went back to
the actual P25 specifications

537
00:31:09,760 --> 00:31:13,920
that I had and
rewrote a clean implementation

538
00:31:13,920 --> 00:31:17,010
of the synthesis step.
I just guessed the difference.

539
00:31:17,010 --> 00:31:21,253
Every time it says 20 ms
I just put 10 ms. When there is

540
00:31:21,253 --> 00:31:26,016
a 512-bin FFT I just put 256

541
00:31:26,016 --> 00:31:29,920
and adapted stuff as I went.

542
00:31:29,920 --> 00:31:33,670
And the resulting code is in the git

543
00:31:33,670 --> 00:31:37,420
and you can decode voice.

544
00:31:37,420 --> 00:31:40,143
I think it works pretty well.

545
00:31:40,143 --> 00:31:42,676
You can hear some subtle differences

546
00:31:42,676 --> 00:31:45,370
compared to the original codec

547
00:31:45,370 --> 00:31:48,400
because DVSI did do a bunch of stuff to

548
00:31:48,400 --> 00:31:51,480
improve the voice quality.
It's their whole business.

549
00:31:51,480 --> 00:31:55,630
And I didn't go through all of that.

550
00:31:55,630 --> 00:32:00,070
But… From my point of view,
I'm done on this and I'm not

551
00:32:00,070 --> 00:32:03,470
gonna go any further.
We have C code we can run.

552
00:32:03,470 --> 00:32:05,850
So. That's good.

553
00:32:05,850 --> 00:32:13,030
*Applause*

554
00:32:13,800 --> 00:32:16,610
Thank you.

555
00:32:16,610 --> 00:32:20,500
Next, we move on to the cipher.

556
00:32:20,500 --> 00:32:24,000
We didn't reverse engineer the cipher.

557
00:32:24,000 --> 00:32:27,520
That was done by a team
at the Bochum university

558
00:32:27,520 --> 00:32:30,410
led by Benedikt Driessen.

559
00:32:30,410 --> 00:32:34,250
Right after we publ…
After 28C3, basically…

560
00:32:34,250 --> 00:32:38,380
Actually, at 28C3 we already had
some contacts with them but

561
00:32:38,380 --> 00:32:41,150
the paper wasn't published yet.

562
00:32:41,150 --> 00:32:44,620
And we actually have them validate
their data and their attack

563
00:32:44,620 --> 00:32:46,360
using osmo-gmr.

564
00:32:46,360 --> 00:32:49,610
I definitely encourage you to
read the paper that they published

565
00:32:49,610 --> 00:32:52,430
because the method they used.
They are actually the ones

566
00:32:52,430 --> 00:32:56,610
who extracted the DSP image which
we used to reverse engineer the codec.

567
00:32:56,610 --> 00:33:02,320
They were the first ones
to extract it from the

568
00:33:02,320 --> 00:33:05,110
file that you can download online.

569
00:33:05,110 --> 00:33:08,780
And then, there is some pretty
interesting stuff in there.

570
00:33:08,780 --> 00:33:11,460
As I said, they also published
an attack on that cipher

571
00:33:11,460 --> 00:33:14,040
which is a ciphertext-only attack

572
00:33:14,040 --> 00:33:18,030
and I'll show some of the results later on.

573
00:33:18,030 --> 00:33:23,210
So, what does the cipher look like?
Well, it looks like that.

574
00:33:23,210 --> 00:33:27,260
If you are familiar with A5/2 or even A5/1

575
00:33:27,260 --> 00:33:29,970
that should look very familiar because

576
00:33:29,970 --> 00:33:32,400
it's pretty much the same thing.

577
00:33:32,400 --> 00:33:36,090
So you have 4 linear feedback registers.

578
00:33:36,090 --> 00:33:40,060
The first 3 ones are combined
using a nonlinear output function

579
00:33:40,060 --> 00:33:44,000
into the actual key stream.
And then you have a 4th register

580
00:33:44,000 --> 00:33:48,120
which a few of the bits are tapped.
They go to a nonlinear

581
00:33:48,120 --> 00:33:50,630
clocking function and that function
is gonna determine

582
00:33:50,630 --> 00:33:54,650
how fast the other registers are clocked.

583
00:33:54,650 --> 00:34:00,310
So, not all registers advance
at each output bit.

584
00:34:00,310 --> 00:34:05,280
And as I said, it is very similar to…
it's actually a copy of A5/2

585
00:34:05,280 --> 00:34:08,109
except they changed every number like…
they don't…

586
00:34:08,109 --> 00:34:11,320
the polynomial for the linear
feedback registers are different,

587
00:34:11,320 --> 00:34:14,429
which bits are tapped to combine
into the output are different.

588
00:34:14,429 --> 00:34:18,050
Same thing for R4 but
it's the exact same structure

589
00:34:18,050 --> 00:34:23,000
which means we can reuse the attack
that works on A5/2.

590
00:34:23,000 --> 00:34:27,099
This cipher obviously has
an initialization step

591
00:34:27,099 --> 00:34:30,249
where you basically take the key
and the frame number

592
00:34:30,249 --> 00:34:32,419
that you want to encrypt

593
00:34:32,419 --> 00:34:36,039
and you have some process to initialize

594
00:34:36,039 --> 00:34:37,940
the LFSR with those data.

595
00:34:37,940 --> 00:34:39,940
But really the only thing to retain

596
00:34:39,940 --> 00:34:42,918
is that the initialization
process is entirely linear.

597
00:34:42,918 --> 00:34:46,465
There is some XOR and LFSR being involved.

598
00:34:46,465 --> 00:34:50,012
So that's pretty much…

599
00:34:50,012 --> 00:34:54,289
…the thing to remember.

600
00:34:54,489 --> 00:35:00,160
The actual irregular clocking
only is applied when you

601
00:35:00,160 --> 00:35:05,819
generate bitstream
for encrypting the frame.

602
00:35:05,819 --> 00:35:10,110
Since we are gonna talk about
attacks on ciphers

603
00:35:10,110 --> 00:35:14,529
in some details there are a few things
that you may not remember

604
00:35:14,529 --> 00:35:18,369
if you don't do algebra all the time.

605
00:35:18,369 --> 00:35:21,430
This is a very very quick reminder.

606
00:35:21,430 --> 00:35:26,410
So, you should know is that
when you see GF(2) that's

607
00:35:26,410 --> 00:35:28,269
just a fancy term for binary.

608
00:35:28,269 --> 00:35:31,690
What we call addition in GF(2)
is just the XOR operation.

609
00:35:31,690 --> 00:35:33,909
Multiplication is just the logic AND

610
00:35:33,909 --> 00:35:36,120
and you can do everything with that.

611
00:35:36,120 --> 00:35:39,930
If you accept those definitions,
then algebra over binary

612
00:35:39,930 --> 00:35:43,740
is gonna be pretty much the same as
algebra over real numbers

613
00:35:43,740 --> 00:35:47,480
and all the nice properties
are gonna be applicable

614
00:35:47,480 --> 00:35:50,450
to binary math as well.

615
00:35:50,450 --> 00:35:53,859
I mentioned previously “linear”
and I will mention it

616
00:35:53,859 --> 00:35:56,400
several times in the rest of this talk.

617
00:35:56,400 --> 00:36:00,559
When I say “linear” it's either a constant,

618
00:36:00,559 --> 00:36:03,680
or a variable or unknown
multiplied by a constant

619
00:36:03,680 --> 00:36:07,710
but you never have two variables
multiplied together

620
00:36:07,710 --> 00:36:13,340
because then it becomes quadratic
and it's not linear anymore.

621
00:36:13,849 --> 00:36:18,400
Being linear has some nice properties
like linear systems of equations

622
00:36:18,400 --> 00:36:22,859
we have very fast algorithms to
solve them

623
00:36:22,859 --> 00:36:27,759
and every linear operation can be
represented as matrix operation

624
00:36:27,759 --> 00:36:31,009
which is especially useful…
we're gonna be dealing with

625
00:36:31,009 --> 00:36:34,369
hundreds of unknowns and
spelling them out is not an option.

626
00:36:34,369 --> 00:36:38,409
We have to have some way of
representing that and that's

627
00:36:38,409 --> 00:36:42,400
matrix operations, essentially.

628
00:36:42,400 --> 00:36:45,979
One other important thing to know is:

629
00:36:45,979 --> 00:36:50,330
When you have an operation
that adds redundancy, for example,

630
00:36:50,330 --> 00:36:52,670
channel coding where you add the CRC

631
00:36:52,670 --> 00:36:55,140
or where you do convolutional coding,

632
00:36:55,140 --> 00:36:58,470
adding error correction adds
redundancy to your message

633
00:36:58,470 --> 00:37:01,439
and when you have redundancy
you can create what's called

634
00:37:01,439 --> 00:37:05,109
a parity check matrix to check
if that redundancy in that present.

635
00:37:05,109 --> 00:37:07,549
So, for a CRC you check
the CRC for example.

636
00:37:07,549 --> 00:37:10,750
But it can be generalized to anything
that adds redundancy.

637
00:37:10,750 --> 00:37:14,240
It can be checked.
And that becomes very useful to

638
00:37:14,240 --> 00:37:16,860
make the attack much faster.

639
00:37:16,860 --> 00:37:21,380
So, a little more detail about
what the guys at Bochum did.

640
00:37:21,380 --> 00:37:24,599
They published a ciphertext-only attack

641
00:37:24,599 --> 00:37:27,640
that means you only need to
capture data off the air

642
00:37:27,640 --> 00:37:30,000
and directly with that
you feed it to the attack

643
00:37:30,000 --> 00:37:32,029
and it can give you the key.

644
00:37:32,029 --> 00:37:34,869
Their target was called TCH3 frames

645
00:37:34,869 --> 00:37:38,299
and those are traffic frames,
they're what carries the voice

646
00:37:38,299 --> 00:37:40,860
which means you have a lot of them because

647
00:37:40,860 --> 00:37:43,670
as long as the conversation is still going,

648
00:37:43,670 --> 00:37:46,130
frames that are being generated constantly,

649
00:37:46,130 --> 00:37:48,950
several tens of them per second.

650
00:37:48,950 --> 00:37:52,119
They didn't start from nothing. As I said

651
00:37:52,119 --> 00:37:54,639
the cipher is heavily based on A5/2, so,

652
00:37:54,639 --> 00:37:57,359
it kind of makes sense to read the papers

653
00:37:57,359 --> 00:38:00,670
that were published about A5/2 attacks.

654
00:38:00,670 --> 00:38:05,809
The most interesting one and one of the
most advanced one is called

655
00:38:05,809 --> 00:38:12,119
“Instant Ciphertext-Only Cryptanalysis
of GSM encrypted communication”

656
00:38:12,119 --> 00:38:15,930
It's kind of math-heavy but

657
00:38:15,930 --> 00:38:21,290
it provides an attack on A5/2
that recovers the key instantly

658
00:38:21,290 --> 00:38:23,549
which is really nice.

659
00:38:23,549 --> 00:38:26,349
They modified this attack.
They tweaked it for GMR-1

660
00:38:26,349 --> 00:38:28,359
because the frames are different.

661
00:38:28,359 --> 00:38:30,350
There's different amount of bits.

662
00:38:30,350 --> 00:38:32,740
The cipher is slightly different.

663
00:38:32,740 --> 00:38:34,910
And they also did something a little weird.

664
00:38:34,910 --> 00:38:37,160
They tried to guess more bits

665
00:38:37,160 --> 00:38:39,339
some of the bits they tried to brute-force.

666
00:38:39,339 --> 00:38:41,720
I'm not exactly sure why.

667
00:38:41,720 --> 00:38:44,369
I think it's to reduce
the number of unknowns.

668
00:38:44,369 --> 00:38:47,930
But I don't know if it actually
had the desired effect.

669
00:38:47,930 --> 00:38:52,339
And in the RUB paper
they published their result:

670
00:38:52,339 --> 00:38:59,569
With 350 GB of precomputed data
using 32 TCH3 frames

671
00:38:59,569 --> 00:39:03,260
they managed to recover the key
in something like 40 minutes

672
00:39:03,260 --> 00:39:06,309
which is not bad, definitely, and it works.

673
00:39:06,309 --> 00:39:09,399
But the original attack is named “instant”.

674
00:39:09,399 --> 00:39:13,039
40 minutes isn't instant – to me, at least.

675
00:39:13,039 --> 00:39:17,979
So, we started looking for a better attack.

676
00:39:18,349 --> 00:39:21,630
We started off the same paper
because it's kind of

677
00:39:21,630 --> 00:39:24,650
the state of the art of A5/2 attacks

678
00:39:24,650 --> 00:39:27,469
but we really didn't do anything fancy.

679
00:39:27,469 --> 00:39:32,890
We just used it exactly as they said
in the original paper

680
00:39:32,890 --> 00:39:36,559
and we just did the necessary tweaks
for A5/GMR-1,

681
00:39:36,559 --> 00:39:39,910
changing the matrix and
the length of the vector,

682
00:39:39,910 --> 00:39:42,499
really nothing fancy.

683
00:39:42,499 --> 00:39:46,269
We also decided to attack
a different type of channel

684
00:39:46,269 --> 00:39:49,390
and this is probably what
makes the most difference.

685
00:39:49,390 --> 00:39:52,130
We decided to target FACCH3 control frames

686
00:39:52,130 --> 00:39:54,710
instead of the TCH3 voice frames.

687
00:39:54,710 --> 00:39:58,690
There is a very big advantage to
targeting those frames.

688
00:39:58,690 --> 00:40:02,990
First, they use a different kind of
modulation and training sequence.

689
00:40:02,990 --> 00:40:06,440
From an RF point of view
they are much easier to receive.

690
00:40:06,440 --> 00:40:09,940
And that's pretty important if
you're trying to mount an attack because

691
00:40:09,940 --> 00:40:12,660
as soon as you have a
bit error in the reception

692
00:40:12,660 --> 00:40:15,409
it will make your equations inconsistent

693
00:40:15,409 --> 00:40:18,600
and you won't actually be able
to solve for the key as easily.

694
00:40:18,600 --> 00:40:21,880
So, this is a very nice property
of those frames.

695
00:40:21,880 --> 00:40:24,569
The other very nice property is
that we have known

696
00:40:24,569 --> 00:40:28,779
plaintext on the FACCH3 channel,
the control channel.

697
00:40:28,779 --> 00:40:31,559
There are some predictable frames
that we know will there

698
00:40:31,559 --> 00:40:33,379
and we know where they will be.

699
00:40:33,379 --> 00:40:35,589
the voice traffic is
completely unpredictable.

700
00:40:35,589 --> 00:40:37,500
It's someone talking.

701
00:40:37,500 --> 00:40:41,190
The control traffic will follow
some very known patterns

702
00:40:41,190 --> 00:40:46,260
and I'll show an example of
plaintext which is really trivial.

703
00:40:46,540 --> 00:40:50,210
Some other of the nice properties
of the control channel is:

704
00:40:50,210 --> 00:40:53,249
There is much more redundancy.

705
00:40:53,249 --> 00:40:57,759
In TCH3 not all the bits are
actually error-corrected

706
00:40:57,759 --> 00:41:01,220
which means you don't have
that much information

707
00:41:01,220 --> 00:41:05,450
while for the control channel
each layer-2 bit that you transmit

708
00:41:05,450 --> 00:41:09,809
is almost quadrupled
before you put it on the air

709
00:41:09,809 --> 00:41:15,130
which means you can build
a lot of equations very fast

710
00:41:15,130 --> 00:41:20,380
without many bursts.
In the RUB attack they needed 32 frames,

711
00:41:20,380 --> 00:41:26,599
probably because there is not much
redundancy in the TCH3 frames.

712
00:41:26,599 --> 00:41:30,420
And also, as a nice bonus that
we discovered later is that

713
00:41:30,420 --> 00:41:34,279
the FACCH3 control channel
is also used to negotiate

714
00:41:34,279 --> 00:41:38,089
other types of channels like
the channels that are used

715
00:41:38,089 --> 00:41:42,890
when you send FAX or
when you establish a data call

716
00:41:42,890 --> 00:41:44,840
over satellite networks.

717
00:41:44,840 --> 00:41:48,359
It's actually negotiated using
that type of control channel

718
00:41:48,359 --> 00:41:51,109
which means the same kind of attack
can work to crack

719
00:41:51,109 --> 00:41:54,900
not only voice but also data calls and FAX.

720
00:41:54,900 --> 00:41:58,380
This is an example of the plaintext.

721
00:41:58,380 --> 00:42:00,779
I don't know if you can really see it.

722
00:42:00,779 --> 00:42:03,249
But essentially on the top
you have the cipher mode command

723
00:42:03,249 --> 00:42:06,150
the first line in blue is
the cipher mode command.

724
00:42:06,150 --> 00:42:08,630
So everything after that
is in theory ciphered.

725
00:42:08,630 --> 00:42:10,700
This is, of course, the enciphered view.

726
00:42:10,700 --> 00:42:13,910
And the three marked packets
in gray and black

727
00:42:13,910 --> 00:42:15,839
are the very predictable texts

728
00:42:15,839 --> 00:42:19,200
and what they are is acknowledgements.

729
00:42:19,200 --> 00:42:21,170
Because of the delay on the GSM channel

730
00:42:21,170 --> 00:42:23,089
there is some outstanding
acknowledgement

731
00:42:23,089 --> 00:42:27,759
that still need to be sent
when the ciphering is turned on.

732
00:42:27,759 --> 00:42:31,569
You get empty packets with
incrementing sequence number

733
00:42:31,569 --> 00:42:34,769
and the ACK bit set.

734
00:42:34,769 --> 00:42:37,160
Something changes in them,
the sequence number, but

735
00:42:37,160 --> 00:42:41,209
as soon as you can count,
predicting them is trivial.

736
00:42:41,209 --> 00:42:45,400
This definitely works in practice
like 100% of the time.

737
00:42:45,400 --> 00:42:49,770
I never really had any problem with that.

738
00:42:50,740 --> 00:42:56,190
So, how do you build a plaintext attack?

739
00:43:03,810 --> 00:43:07,849
The general goal is…
what you're trying to achieve

740
00:43:07,849 --> 00:43:11,529
is build a giant system of equations
that's linear

741
00:43:11,529 --> 00:43:13,320
and that you can solve.

742
00:43:13,320 --> 00:43:16,710
It's gonna have the form
A * x = b

743
00:43:16,710 --> 00:43:21,450
b is the cipher stream that
is generated by A5/GMR-1

744
00:43:21,450 --> 00:43:26,299
x is some representation of
the internal state of the cipher

745
00:43:26,299 --> 00:43:28,269
that you are trying to find

746
00:43:28,269 --> 00:43:31,130
and A is a giant matrix
that you can precompute

747
00:43:31,130 --> 00:43:35,309
that's only dependent on
the structure of the cipher.

748
00:43:35,309 --> 00:43:39,650
Each row of A and b are gonna represent
one bit of the output

749
00:43:39,650 --> 00:43:44,999
and how to combine that internal state
to generate that cipher stream bit.

750
00:43:44,999 --> 00:43:48,470
As I mentioned,
the initialization process is linear

751
00:43:48,470 --> 00:43:51,329
and that's very important
for two things.

752
00:43:51,329 --> 00:43:54,360
First,
from the internal state of the cipher

753
00:43:54,360 --> 00:43:57,950
you're gonna be able to recover the key

754
00:43:57,950 --> 00:44:01,540
which is not entirely true.
There is one bit of the key

755
00:44:01,540 --> 00:44:04,789
that you can't recover
because that bit of the key

756
00:44:04,789 --> 00:44:08,499
turns out to have absolutely no effect
on the output whatsoever.

757
00:44:08,499 --> 00:44:12,322
so, you can't recover it
but doesn't matter either.

758
00:44:12,322 --> 00:44:14,925
The other thing is that

759
00:44:14,925 --> 00:44:18,499
you're gonna need to
build a lot of equations.

760
00:44:18,499 --> 00:44:20,689
That system is gonna be big.

761
00:44:20,689 --> 00:44:23,670
In a single burst of data
you won't have enough equations.

762
00:44:23,670 --> 00:44:25,660
You're gonna need multiple of them.

763
00:44:25,660 --> 00:44:28,649
But, of course, those multiple bursts
are gonna have different

764
00:44:28,649 --> 00:44:31,060
frame numbers because they're sequential.

765
00:44:31,060 --> 00:44:33,790
They're not gonna wrap before a long time.

766
00:44:33,790 --> 00:44:36,620
But since the initialization
is entirely linear

767
00:44:36,620 --> 00:44:40,599
you can actually derive equation
from one frame number

768
00:44:40,599 --> 00:44:44,380
from an equation built out of
another frame number.

769
00:44:44,380 --> 00:44:49,859
But, of course, it would be too easy.
The cipher isn't entirely linear.

770
00:44:49,859 --> 00:44:53,419
so, we have to “linearize” it and

771
00:44:53,419 --> 00:44:57,150
when I first started looking at
a crypto attack on A5/2

772
00:44:57,150 --> 00:45:00,010
in the paper it was always
one line that said

773
00:45:00,010 --> 00:45:02,539
oh yeah, we linearize the cipher

774
00:45:02,539 --> 00:45:06,350
and they kind of always assumed
the readers know what that means

775
00:45:06,350 --> 00:45:08,890
which I didn't at the time.

776
00:45:08,890 --> 00:45:12,490
So, I decided to be a little more explicit.

777
00:45:12,490 --> 00:45:16,720
The two nonlinear elements are
the output function

778
00:45:16,720 --> 00:45:20,400
which uses a majority function
where you take three bits

779
00:45:20,400 --> 00:45:24,390
and it outputs whichever
bit is more common

780
00:45:24,390 --> 00:45:27,450
and you can rewrite that
majority function as being

781
00:45:27,450 --> 00:45:30,970
the sum of a plus b multiplied by c

782
00:45:30,970 --> 00:45:37,190
or if you wish a XOR b AND c.

783
00:45:37,190 --> 00:45:41,210
And the problem is the
b multiplied by c because

784
00:45:41,210 --> 00:45:43,779
that's quadratic, that's not linear.

785
00:45:43,779 --> 00:45:46,309
That means that
we can't introduce that.

786
00:45:46,309 --> 00:45:50,029
And the way to linearize that
is to kind of ignore it.

787
00:45:50,029 --> 00:45:54,070
For every possible quadratic term
that's gonna be generated

788
00:45:54,070 --> 00:45:57,690
by that nonlinear output function

789
00:45:57,690 --> 00:46:00,170
you generate a new unknown.

790
00:46:00,170 --> 00:46:03,290
In reality that unknown
isn't really unknown.

791
00:46:03,290 --> 00:46:06,719
It's a function of your other variables but

792
00:46:06,719 --> 00:46:10,170
you can't represent it in a linear fashion.

793
00:46:10,170 --> 00:46:15,359
So, you just ignore it and say
“OK, this is a new unknown, deal with it”.

794
00:46:15,359 --> 00:46:18,640
Actually, there is a lot of
possible combinations

795
00:46:18,640 --> 00:46:21,999
which adds 594 new unknowns
to your equation system

796
00:46:21,999 --> 00:46:25,279
which means that you're gonna need
a bunch more equations

797
00:46:25,279 --> 00:46:27,539
to be able to actually solve it.

798
00:46:27,539 --> 00:46:32,279
But at least it makes it linear.
So, there is hope.

799
00:46:32,619 --> 00:46:39,969
The other nonlinear thing in that cipher
is the clocking.

800
00:46:40,170 --> 00:46:44,220
As I said, all the LSFR don't advance
at the same rate.

801
00:46:44,220 --> 00:46:50,380
Some are clocked once or zero times
at each output bit.

802
00:46:50,380 --> 00:46:55,880
And this is a function of the value of R4
at that particular time.

803
00:46:56,160 --> 00:46:59,689
So, how do we linearize that?

804
00:46:59,689 --> 00:47:04,559
Well, R4 is a 17-bit
linear feedback register.

805
00:47:04,559 --> 00:47:08,960
So, we can know
all its future states from any…

806
00:47:08,960 --> 00:47:12,890
As soon as we have a good state
at one particular time

807
00:47:12,890 --> 00:47:15,789
you can predict all the future states

808
00:47:15,789 --> 00:47:19,300
because it's clocked all the time.

809
00:47:19,640 --> 00:47:23,620
And in those 17 bits
the initialization step forces

810
00:47:23,620 --> 00:47:25,869
one of those bits to one.

811
00:47:25,869 --> 00:47:28,650
So, there is only 16 bits
that you don't know

812
00:47:28,650 --> 00:47:32,980
which means there is only
65536 possible clocking

813
00:47:32,980 --> 00:47:35,710
patterns for the cipher.

814
00:47:35,710 --> 00:47:40,400
So, the way we approach
that is we just brute-force it.

815
00:47:40,400 --> 00:47:43,339
You just assume that R4 is
gonna be equal to that value

816
00:47:43,339 --> 00:47:47,819
after the initialization
and you just assume that

817
00:47:47,819 --> 00:47:52,779
and try to solve and crack the cipher
by using that assumption.

818
00:47:52,779 --> 00:47:56,369
And if you find the Kc, well,
then maybe it's the right one.

819
00:47:56,369 --> 00:48:00,980
You just repeat that 65536 times
and most of the time

820
00:48:00,980 --> 00:48:04,190
if your guess about R4 is incorrect

821
00:48:04,190 --> 00:48:07,170
the system will end up being inconsistent

822
00:48:07,170 --> 00:48:10,799
and you won't actually have any solution.

823
00:48:10,799 --> 00:48:17,509
But this still requires solving
65536 systems

824
00:48:17,509 --> 00:48:22,409
which is fast but not that fast.

825
00:48:22,409 --> 00:48:28,190
There is actually a trick that we can
apply to do better guesses.

826
00:48:28,190 --> 00:48:31,789
When you build these
giant equation systems

827
00:48:31,789 --> 00:48:34,869
it turns out that some of the
equations that you construct

828
00:48:34,869 --> 00:48:37,549
they are not gonna be independent.
Some of them are

829
00:48:37,549 --> 00:48:40,369
gonna be related to each other.

830
00:48:40,369 --> 00:48:44,700
And so some of the rows are redundant.
And what's nice is:

831
00:48:44,700 --> 00:48:49,020
If they're redundant
we can actually test for that redundancy.

832
00:48:49,020 --> 00:48:52,539
For the 65536 possible systems
that you need to solve,

833
00:48:52,539 --> 00:48:55,249
you also have an
An * x = b

834
00:48:55,249 --> 00:48:59,319
there is a bunch of rows in An
that are gonna be linear dependent.

835
00:48:59,319 --> 00:49:03,660
So, for each of them you can
build a parity check matrix Hn

836
00:49:03,660 --> 00:49:08,299
so that you have this nice property
of a parity check matrix

837
00:49:08,299 --> 00:49:12,779
where you multiply b by Hn
and you get a zero matrix.

838
00:49:12,779 --> 00:49:16,109
But all those Hn, you can precompute them.

839
00:49:16,109 --> 00:49:19,860
That's the offline data of the attack.

840
00:49:19,860 --> 00:49:23,009
You precompute those giant matrices,

841
00:49:23,009 --> 00:49:29,369
then you take b which is the cipher text
you got from the cipher,

842
00:49:29,569 --> 00:49:33,289
you multiply it by this matrix
and if it gives you zero,

843
00:49:33,289 --> 00:49:37,069
you know that this particular R4 value
might be correct.

844
00:49:37,069 --> 00:49:38,940
You don't know if it's correct or not,

845
00:49:38,940 --> 00:49:40,579
but at least it might be.

846
00:49:40,579 --> 00:49:43,830
If the result is non-zero
then you know that R4 is definitely

847
00:49:43,830 --> 00:49:46,869
not the correct R4 and so
instead of solving an entire

848
00:49:46,869 --> 00:49:50,190
system of equations the only thing
you need to do is

849
00:49:50,190 --> 00:49:54,339
do one matrix multiplication
and that is pretty fast.

850
00:49:54,339 --> 00:49:57,819
And in the end you're gonna have
a couple of possible matches

851
00:49:57,819 --> 00:50:01,520
so you're gonna solve like maybe
3 or 4 systems of equations

852
00:50:01,520 --> 00:50:05,239
instead of solving 65536 and
that's much much faster.

853
00:50:05,239 --> 00:50:09,739
Now, how do you go from
a known-plaintext attack

854
00:50:09,739 --> 00:50:12,960
to a ciphertext-only attack?

855
00:50:12,960 --> 00:50:16,190
I'm not gonna detail that much
but essentially

856
00:50:16,190 --> 00:50:19,880
the channel coding operation
introduces redundancy

857
00:50:19,880 --> 00:50:23,730
and you can kind of null out that…

858
00:50:23,730 --> 00:50:26,980
if you take the last equation you have

859
00:50:26,980 --> 00:50:29,750
H multiplied by y plus g.

860
00:50:29,750 --> 00:50:34,220
H is a function of the channel coding.

861
00:50:34,220 --> 00:50:36,289
You can compute it. It's known.

862
00:50:36,289 --> 00:50:40,339
y is the data that
you received off the air.

863
00:50:40,339 --> 00:50:42,250
So, you know it as well.

864
00:50:42,250 --> 00:50:45,579
g is also a function of
the channel coding operation.

865
00:50:45,579 --> 00:50:50,039
So, you know it.
So everything on the left you know.

866
00:50:50,039 --> 00:50:54,689
And the last value is H multiplied by A

867
00:50:54,689 --> 00:50:58,149
which is what you had in
the known-plaintext attack,

868
00:50:58,149 --> 00:51:00,200
so you know it as well.

869
00:51:00,200 --> 00:51:03,189
And everything you don't know
is x and so, again,

870
00:51:03,189 --> 00:51:06,369
you have a linear system of equations
that you can solve.

871
00:51:06,369 --> 00:51:09,629
And the same R4 quick-scan
method can be applied

872
00:51:09,629 --> 00:51:14,090
to scan very quickly and not
have to solve everything.

873
00:51:14,320 --> 00:51:17,070
So, this is the result.

874
00:51:17,070 --> 00:51:20,970
If you use the fact that
you know some plaintext

875
00:51:20,970 --> 00:51:24,009
you need about 50 Megabytes
of data precomputed,

876
00:51:24,009 --> 00:51:27,179
you need to receive 8 bursts
or even 4 if you

877
00:51:27,179 --> 00:51:30,509
by any chance have the right
frame number alignment,

878
00:51:30,509 --> 00:51:33,110
and in like 500 ms
you can get the key back.

879
00:51:33,110 --> 00:51:35,820
And that's on a 6 year old laptop.

880
00:51:35,820 --> 00:51:39,849
On any recent machine it's really instant.

881
00:51:39,849 --> 00:51:43,199
If you want to use the
ciphertext-only variant,

882
00:51:43,199 --> 00:51:46,059
and honestly I really don't know
why you would

883
00:51:46,059 --> 00:51:50,370
because the known-plaintext works,
so you might as well use it.

884
00:51:50,370 --> 00:51:53,750
But if you want it purely
for academic purposes,

885
00:51:53,750 --> 00:51:57,130
then you need 8 bursts,

886
00:51:57,130 --> 00:52:00,510
about 5 Gigabytes of data,

887
00:52:00,520 --> 00:52:03,590
and then it takes a little longer

888
00:52:03,590 --> 00:52:08,719
like about 1 second to recover the key.

889
00:52:09,189 --> 00:52:12,769
A few things I would like to
look at in the future,

890
00:52:12,769 --> 00:52:15,099
is C-band.

891
00:52:15,099 --> 00:52:19,539
The satellite has to talk back
to the earth station

892
00:52:19,539 --> 00:52:22,540
and this happens
in a different frequency band

893
00:52:22,540 --> 00:52:25,046
and this is what we would like to look at,

894
00:52:25,046 --> 00:52:27,042
essentially, the feeder link

895
00:52:27,042 --> 00:52:29,639
If any of you have a large dish,
satellite dish,

896
00:52:29,639 --> 00:52:32,689
and want to provide data for us
please contact us,

897
00:52:32,689 --> 00:52:34,560
we're looking for it.

898
00:52:34,560 --> 00:52:38,369
We're also started
looking into packet data

899
00:52:38,369 --> 00:52:41,299
and some other stuff.

900
00:52:41,299 --> 00:52:45,279
A quick note about
other satellite phone systems,

901
00:52:45,279 --> 00:52:48,340
please don't assume that
just because Thuraya GMR-1

902
00:52:48,340 --> 00:52:50,869
is broken that the others aren't
unless you have

903
00:52:50,869 --> 00:52:53,009
actual proof that they aren't
because the only

904
00:52:53,009 --> 00:52:55,609
reason we chose Thuraya is
because the phone was

905
00:52:55,609 --> 00:52:57,659
the cheapest on eBay.

906
00:52:57,659 --> 00:53:01,660
So, given that all the satellite
phone systems also…

907
00:53:01,660 --> 00:53:05,519
you know, you can find commercial
interceptors for them,

908
00:53:05,519 --> 00:53:11,029
there is a big chance that they're
not much more secure.

909
00:53:11,029 --> 00:53:13,869
I like to thank a few people:

910
00:53:13,869 --> 00:53:19,390
Dimitry Stolnikov,
the main other author in osmo-gmr

911
00:53:19,390 --> 00:53:22,960
doing a bunch of the RF capture stuff,

912
00:53:22,960 --> 00:53:27,790
Dieter Spaar
for reverse engineering of the AMBE codec

913
00:53:27,790 --> 00:53:30,079
and all the help he provided there

914
00:53:30,079 --> 00:53:33,089
and the RUB team, of course,
for their support in

915
00:53:33,089 --> 00:53:35,470
reverse engineering the cipher,

916
00:53:35,470 --> 00:53:39,529
and the organizer for having me

917
00:53:39,529 --> 00:53:42,540
and thank you for your attention!

918
00:53:42,540 --> 00:53:46,509
*Applause*

919
00:53:46,720 --> 00:53:52,410
- Thank you very much!
We now have time for a few questions.

920
00:53:52,410 --> 00:53:56,949
First, are there questions
from the Internet?

921
00:53:57,529 --> 00:54:00,579
Not yet. So,
if you have a question, please

922
00:54:00,579 --> 00:54:03,059
approach one of the microphones.

923
00:54:03,059 --> 00:54:05,559
Yes, please, microphone number 3!

924
00:54:05,559 --> 00:54:12,639
- Yes, I have a rather not technical
but political question:

925
00:54:12,660 --> 00:54:17,720
So, you said in the beginning
there was like a short

926
00:54:17,720 --> 00:54:20,690
way of communication that
only the satellite transmits

927
00:54:20,690 --> 00:54:24,630
the voice data, so there is
no ground station involved?

928
00:54:24,630 --> 00:54:30,369
- Yes. - Do you think that this
might upset some of the people

929
00:54:30,369 --> 00:54:34,089
who like to intercept calls
because it makes intercepting

930
00:54:34,089 --> 00:54:36,489
the voice data much more complicated

931
00:54:36,489 --> 00:54:39,279
than just going to ground station and say

932
00:54:39,279 --> 00:54:41,090
“I want to listen to this”?

933
00:54:41,090 --> 00:54:44,289
- First, just because the satellite
will send the data back

934
00:54:44,289 --> 00:54:45,999
directly to their mobile phone

935
00:54:45,999 --> 00:54:49,049
doesn't mean the satellite
can't also provide a copy

936
00:54:49,049 --> 00:54:52,589
of it to the earth station.
It just doesn't go through.

937
00:54:52,589 --> 00:54:56,089
But the satellite can obviously
send a copy of it if they want to.

938
00:54:56,259 --> 00:54:59,699
- And probably there will be a
possibility for the ground station

939
00:54:59,699 --> 00:55:02,339
to say
“Don't do that direction connection”.

940
00:55:02,339 --> 00:55:05,740
- On the other hand they can also
just intercept it off the air

941
00:55:05,740 --> 00:55:07,919
because it's so easy to listen to it.

942
00:55:07,919 --> 00:55:10,920
Last year there was a talk with somebody

943
00:55:10,920 --> 00:55:13,799
that looked at satellite pictures

944
00:55:13,799 --> 00:55:17,120
and they saw that one of the
spy satellites was relocated

945
00:55:17,120 --> 00:55:21,839
like right next to the
Thuraya-2 satellite.

946
00:55:21,839 --> 00:55:25,059
You can look that up.
It was a presentation last year.

947
00:55:25,059 --> 00:55:28,509
It was pretty interesting
to see that… yeah…

948
00:55:28,509 --> 00:55:31,319
If you want to listen to it you can do it.

949
00:55:31,319 --> 00:55:32,899
- Thank you!

950
00:55:32,899 --> 00:55:37,060
- Next question from microphone number 2!

951
00:55:39,349 --> 00:55:46,349
- I've two questions: Can you hear
both sides of the conversation

952
00:55:46,349 --> 00:55:50,250
or only one side of the conversation?
The second question is:

953
00:55:50,250 --> 00:55:53,119
How big of a dish do you need?

954
00:55:53,119 --> 00:55:55,199
- If you want to receive L-band which is

955
00:55:55,199 --> 00:55:58,420
just listen to the communication
from the satellite to the phone

956
00:55:58,420 --> 00:56:02,099
you don't need a dish,
you need like a small antenna.

957
00:56:02,099 --> 00:56:05,960
You can even do it with a modified
GPS antenna and a piece of metal.

958
00:56:05,960 --> 00:56:09,529
So, it's really easy and
really cheap to do.

959
00:56:09,529 --> 00:56:13,059
You can only hear the the
part of the conversation

960
00:56:13,059 --> 00:56:15,759
that comes from the satellite
to the phone.

961
00:56:15,759 --> 00:56:20,140
So, if by any chance that guy
is speaking to another phone

962
00:56:20,140 --> 00:56:24,226
you can hear both sides
because you can intercept both

963
00:56:24,226 --> 00:56:26,992
channels simultaneously.

964
00:56:26,992 --> 00:56:30,000
But in general, you either

965
00:56:30,000 --> 00:56:34,349
only hear one side or you can
also be close enough to the

966
00:56:34,349 --> 00:56:38,749
actual satellite phones
to receive the uplink

967
00:56:38,749 --> 00:56:42,930
that goes from the phone to the satellite.

968
00:56:42,930 --> 00:56:46,149
Dimitry showed me like a
commercial intercept system

969
00:56:46,149 --> 00:56:50,609
where apparently they use like
planes to intercept the uplink.

970
00:56:50,609 --> 00:56:53,739
They just fly over the area of interest

971
00:56:53,739 --> 00:56:58,550
so they can more easily receive
the uplink from the phones.

972
00:56:58,550 --> 00:57:00,879
- One final question. Please make it short

973
00:57:00,879 --> 00:57:02,919
because we are running out of time.

974
00:57:02,919 --> 00:57:05,079
- I'll try my best.

975
00:57:05,079 --> 00:57:08,170
Launching your own satellite
is certainly not an option

976
00:57:08,170 --> 00:57:11,099
but do you see any practical applications

977
00:57:11,099 --> 00:57:16,289
in terms of what you did with GSM?

978
00:57:17,349 --> 00:57:20,949
- Not really. It would be
interesting to try start a net

979
00:57:20,949 --> 00:57:24,409
because there is nothing that says
that you have to be on a satellite.

980
00:57:24,409 --> 00:57:27,900
You could technically start a base station on earth

981
00:57:27,900 --> 00:57:31,549
using that protocol and it would work.

982
00:57:31,549 --> 00:57:35,009
And the phones have much more power
than a GSM phone.

983
00:57:35,009 --> 00:57:38,440
But other than that,
you could build an IMSI catcher

984
00:57:38,440 --> 00:57:40,790
for satellite phones if you wanted to

985
00:57:40,790 --> 00:57:44,250
and you'd definitely beat the
signal strength of the satellite

986
00:57:44,250 --> 00:57:46,659
with your own setup.

987
00:57:46,659 --> 00:57:48,340
- Thank you.

988
00:57:48,340 --> 00:57:53,169
- Please give the speaker
another round of applause!