1
00:00:02,060 --> 00:00:07,920
all right hello and welcome everybody to our talk tetra tour de force jailbreaking digital

2
00:00:07,920 --> 00:00:13,160
radios and base stations for fun and secrets I'm very excited to stand here today and share

3
00:00:13,160 --> 00:00:18,980
this research with you after working on it for more than two years my name is Jos Wetzels and

4
00:00:18,980 --> 00:00:23,740
these are my colleagues Carla Meyer and Wouter Boxlack and together we form Midnight Blue a

5
00:00:23,740 --> 00:00:29,040
specialist security consultant for consultancy firm that specializes mainly in embedded systems

6
00:00:29,040 --> 00:00:35,460
as well as critical infrastructure so a little bit about tetra what is tetra it's a globally

7
00:00:35,460 --> 00:00:40,180
used radio technology that competes with the likes of p25 which you might know from being

8
00:00:40,180 --> 00:00:46,560
used by the United States police DMR and the confusingly named tetra pole and was standardized

9
00:00:46,560 --> 00:00:52,400
in 1995 by Etsy that's the European telecommunications standards Institute and they

10
00:00:52,400 --> 00:00:58,020
are known for also doing work on GSM 3g 4g and so on it's used for voice and data communications

11
00:00:58,020 --> 00:00:58,940
as well as

12
00:00:58,940 --> 00:01:04,140
machine-to-machine communications and it relies on secret proprietary cryptography that's why

13
00:01:04,140 --> 00:01:11,320
we're standing here today so it's the vast majority of global police forces outside of

14
00:01:11,320 --> 00:01:16,900
the United States and France use tetra for their voice communications and this is countries like

15
00:01:16,900 --> 00:01:21,800
the Netherlands and Germany and the United Kingdom but also Scandinavian countries Eastern

16
00:01:21,800 --> 00:01:28,420
Europe large parts of Asia and South America use this in addition it's used in military and

17
00:01:28,940 --> 00:01:33,700
armed services contexts now the countries that you see highlighted on the map here are the ones

18
00:01:33,700 --> 00:01:38,860
where we could confirm military or intelligence users through open source intelligence but this

19
00:01:38,860 --> 00:01:42,820
is likely the tip of the iceberg so there might be many more countries out there that use it in

20
00:01:42,820 --> 00:01:48,460
this capacity and on top of that it's used by critical infrastructure so if you see private

21
00:01:48,460 --> 00:01:53,800
security forces at airports harbors and train stations there's a good chance that their

22
00:01:53,800 --> 00:01:58,380
handheld radios are tetra based and on top of that it's also used as a

23
00:01:58,940 --> 00:02:03,500
link for wide area networks carrying SCADA communications in order to do

24
00:02:03,500 --> 00:02:07,580
telecontrol and telemetry of high voltage substations oil and gas

25
00:02:07,580 --> 00:02:13,200
pipelines as well as railway signaling so serious stuff now a common

26
00:02:13,200 --> 00:02:17,540
misconception is that tetra is an open standard but that's not true some parts

27
00:02:17,540 --> 00:02:21,200
of the standard are public but the cryptography within it is secret and

28
00:02:21,200 --> 00:02:24,920
it's only available to you if you sign an NDA and I mean in that case you can

29
00:02:24,920 --> 00:02:28,780
talk about it and you're only allowed to sign an NDA if you are what they

30
00:02:28,780 --> 00:02:32,620
call a bona fide party and these bona fide parties are usually manufacturers

31
00:02:32,620 --> 00:02:36,900
and these manufacturers have to ensure that the algorithms are protected either

32
00:02:36,900 --> 00:02:40,740
by implementing them in hardware or implementing them in software with

33
00:02:40,740 --> 00:02:45,020
extraction countermeasures now the first problem already is that there are lots

34
00:02:45,020 --> 00:02:49,040
of these bona fide vendors and they are geographically dispersed so every major

35
00:02:49,040 --> 00:02:52,920
country in the world essentially has a domestic tetra manufacturer that's the

36
00:02:52,920 --> 00:02:57,920
United States the United Kingdom China Russia so you can feel that top-tier

37
00:02:57,920 --> 00:02:58,760
adversaries are going to have a lot of problems and they're going to have to

38
00:02:58,760 --> 00:03:01,640
like likely already have these specifications of these algorithms

39
00:03:01,640 --> 00:03:05,080
either through their in-country manufacturers or to just you know

40
00:03:05,080 --> 00:03:08,660
getting them from a SharePoint somewhere and a manufacturer we however

41
00:03:08,660 --> 00:03:14,460
had to jump through a lot more hoops in this case so tetra security has two main

42
00:03:14,460 --> 00:03:19,520
pillars the first of which is the TAA1 suite which is the authentication key

43
00:03:19,520 --> 00:03:23,720
management and distribution suite it's also used for identity encryption the

44
00:03:23,720 --> 00:03:27,380
second suite is the tetra encryption algorithm suite which is used for voice

45
00:03:27,380 --> 00:03:28,580
and data encryption through the

46
00:03:28,760 --> 00:03:32,560
interface encryption functionality and this has four different flavors the

47
00:03:32,560 --> 00:03:37,520
first of which is ta1 which is readily exportable then you have ta2 which is

48
00:03:37,520 --> 00:03:41,840
restricted in its use to European public safety organizations then you have ta3

49
00:03:41,840 --> 00:03:46,140
which is used for extra European public safety for those countries that are

50
00:03:46,140 --> 00:03:50,580
friendly relationships with the European Union and then you have ta4 which is the

51
00:03:50,580 --> 00:03:56,920
same use cases ta1 but it's hardly used practice optionally there are tetra

52
00:03:56,920 --> 00:04:00,620
end-to-end solutions available but these are only used by some countries

53
00:04:00,620 --> 00:04:04,540
and only in special cases in most of the cases so think about special

54
00:04:04,540 --> 00:04:09,340
intervention units counterintelligence observation units it's not a part of the

55
00:04:09,340 --> 00:04:13,040
tetra standard there are some guidelines around it but it's a vendor specific

56
00:04:13,040 --> 00:04:17,180
proprietary solution that you bold on top of the air interface encryption it's

57
00:04:17,180 --> 00:04:22,220
expensive and again very opaque as well hasn't been looked into yet so with this

58
00:04:22,220 --> 00:04:25,860
in mind we undertook project re-tetra which was the project to reverse

59
00:04:25,860 --> 00:04:26,520
engineer these

60
00:04:26,520 --> 00:04:30,700
these these these algorithms and you can find all the details about this on

61
00:04:30,700 --> 00:04:35,700
this particular URL we undertook this with Kirchhoff's principle in mind now I

62
00:04:35,700 --> 00:04:39,180
probably don't have to explain to you guys what Kirchhoff's principle is but

63
00:04:39,180 --> 00:04:43,340
I'm still going to anyway it says that a crypto system should be secure even if

64
00:04:43,340 --> 00:04:46,960
everything about the system except for the key is public knowledge so no

65
00:04:46,960 --> 00:04:51,800
security true obscurity right violators of this principle have historically not

66
00:04:51,800 --> 00:04:56,500
done well if you look at the history of standards like GSM GMR GPI

67
00:04:56,520 --> 00:05:00,940
RS all Etsy standards by the way there are secret cryptographic algorithms either

68
00:05:00,940 --> 00:05:05,040
turned out to be broken or backdoor and we had the suspicion that this might be

69
00:05:05,040 --> 00:05:08,540
the case for tetra as well but in more than 20 years nobody had looked at this

70
00:05:08,540 --> 00:05:13,060
publicly now Etsy thinks very differently about this in an interview

71
00:05:13,060 --> 00:05:16,820
with the journalist Kim Zetter Brian Murgatroyd who's the chairman of the

72
00:05:16,820 --> 00:05:21,660
Etsy technical committee on tetra said well obscurity is also a way of

73
00:05:21,660 --> 00:05:26,460
maintaining security well let's see if that's actually the case so the the

74
00:05:26,520 --> 00:05:30,360
project was undertaken with funding from NL net which is a Dutch nonprofit

75
00:05:30,360 --> 00:05:34,980
organization that hands out money for open source initiatives and they kindly

76
00:05:34,980 --> 00:05:37,840
supply this with some money to undertake this research and now we can

77
00:05:37,840 --> 00:05:43,440
talk about tetra for the first time in public so let's break open a radio well

78
00:05:43,440 --> 00:05:47,160
before we could break open a radio and see what's going on inside we did a

79
00:05:47,160 --> 00:05:50,900
little bit of analysis first because you want to select the right kind of target

80
00:05:50,900 --> 00:05:54,740
because if you select a radio that is harder to reverse engineer you might end

81
00:05:54,740 --> 00:05:56,380
up spending a lot of time on that

82
00:05:56,520 --> 00:06:00,880
end so we did some analysis of the internal architectures of different kind

83
00:06:00,880 --> 00:06:03,520
of radios from different vendors by looking through the different data

84
00:06:03,520 --> 00:06:07,660
sheets and here you can see that well there's a variety of architectures some

85
00:06:07,660 --> 00:06:11,340
of which are quite esoteric but also they implement different kind of

86
00:06:11,340 --> 00:06:16,500
security features like certain radios will implement hardware based ASICs that

87
00:06:16,500 --> 00:06:19,580
likely include the algorithms and we don't want to spend a lot of time with

88
00:06:19,580 --> 00:06:24,140
assets and scanning electron microscope microscopes so we went for the one that

89
00:06:24,140 --> 00:06:26,420
has a trusted execution environment in

90
00:06:26,520 --> 00:06:31,820
software and that turned out to be the Motorola MTM 5400 this is a very common

91
00:06:31,820 --> 00:06:36,420
model it's easily obtained secondhand online on eBay and it has a baseband

92
00:06:36,420 --> 00:06:40,380
system on chip that is by a manufacturer that is not Motorola but

93
00:06:40,380 --> 00:06:43,580
by Texas Instruments and is likely hints at the fact that there's no

94
00:06:43,580 --> 00:06:48,280
hardware implementation of these algorithms inside also this SOC has

95
00:06:48,280 --> 00:06:51,940
software security features and that are very suited for likely protecting this

96
00:06:51,940 --> 00:06:56,260
tetra crypto from extraction now the architecture of the radio

97
00:06:56,520 --> 00:06:59,980
looks like something you see on the right of the slide so if you have the

98
00:06:59,980 --> 00:07:03,560
radio you have a control head which is where the microphone the keyboard and the

99
00:07:03,560 --> 00:07:07,620
field configuration is then on the back of the radio you have a rear connector

100
00:07:07,620 --> 00:07:11,360
which you use for Depot programming for configuring the radio doing firmer

101
00:07:11,360 --> 00:07:15,940
updates and so on and then inside you have the basement chip and the basement

102
00:07:15,940 --> 00:07:21,600
chip in this case the Freon baseband is based on the omap l138 architecture by

103
00:07:21,600 --> 00:07:25,780
Texas Instruments which has a arm core for the high level stuff and a digital

104
00:07:26,520 --> 00:07:30,720
processor for well processing the signals and then inside the DSP you have

105
00:07:30,720 --> 00:07:34,160
a trusted execution environment that likely includes our magic sauce

106
00:07:35,420 --> 00:07:39,940
so this all map l138 like I mentioned it has an arm core but it also has a

107
00:07:39,940 --> 00:07:46,160
DSP core that is based on a flavor of the TMS 320 DSP architecture there's very

108
00:07:46,160 --> 00:07:50,020
limited reversing tooling available for this particular flavor so we had to build

109
00:07:50,020 --> 00:07:55,860
a lot of our own and the DSP features an orthogonal security model so you have a

110
00:07:56,520 --> 00:08:01,160
separation between the regular user and supervisor mode but you also have a separation between

111
00:08:01,160 --> 00:08:07,200
secure and non-secure mode and if you look at the supervisor secure mode that is likely where a lot

112
00:08:07,200 --> 00:08:13,140
of the interesting stuff is located first thing we did is we bought a development kit for this

113
00:08:13,140 --> 00:08:18,280
architecture was relatively low cost unfortunately this didn't come with the secure version of the

114
00:08:18,280 --> 00:08:23,140
chip so we couldn't analyze it on a development board however it's useful for reversing debugging

115
00:08:23,140 --> 00:08:25,140
testing your shell code and so on

116
00:08:26,520 --> 00:08:30,920
so we wanted to confirm our assumptions so we opened up the radio and we saw that all the

117
00:08:30,920 --> 00:08:37,380
main board was covered with shields so in order to see you know what kind of chip is exactly used we

118
00:08:37,380 --> 00:08:42,280
took a rotary saw we saw it of these these these shields and we found out that yes it is indeed this

119
00:08:42,280 --> 00:08:47,800
particular chip with the secure flavor then we took a look at the firmware the firmware comes as

120
00:08:47,800 --> 00:08:52,980
an rpk package and the rpk package well it's essentially a zip archive and inside the zip

121
00:08:56,520 --> 00:09:00,980
so you know these firmwares are not personalized they don't differ from radio to radio they're

122
00:09:00,980 --> 00:09:07,440
general and the engineering software needs to have a way to load this firmware onto these radios so

123
00:09:07,440 --> 00:09:12,880
likely it knows the passwords to these encrypted files it's written in dotnet so it's very easy

124
00:09:12,880 --> 00:09:16,880
reverse engineering with a little bit of effort you get the two passwords which are static

125
00:09:17,480 --> 00:09:23,060
so then you're able to extract the zip archive you get the z19 file you decrypt it with one password

126
00:09:23,060 --> 00:09:26,180
then you get the s19 files you decrypt those with the second password

127
00:09:26,520 --> 00:09:30,640
and then you have what you're actually looking for which is the file system of the application

128
00:09:30,640 --> 00:09:38,940
processor and the DSP firmware so is this trusted execution environment actually used for the tetra

129
00:09:38,940 --> 00:09:45,200
algorithm algorithms well there's no proper DSP reversing tooling yet so how do we find this out

130
00:09:45,200 --> 00:09:50,260
we'll be doing the entropic analysis of the DSP firmware so you can see on the left of the slide

131
00:09:50,260 --> 00:09:55,980
that in a particular area within the DSP firmware there's a very high entropy area which likely

132
00:09:56,520 --> 00:10:01,180
indicates encrypted data and then you can see the cross references in the code to this particular

133
00:10:01,180 --> 00:10:09,360
area correspond with API call invocations of this particular secure kernel API so delving into a

134
00:10:09,360 --> 00:10:13,220
little bit more detail will be my colleague Carlo Meyer who will take you on the rest of the journey

135
00:10:16,580 --> 00:10:21,980
all right um so now that we have a pretty good idea of where to go and let's break a TEE

136
00:10:22,680 --> 00:10:26,160
and so the first thing we have to do is get code execution

137
00:10:26,520 --> 00:10:31,240
obviously on the application processor and we identified three possible angles

138
00:10:31,240 --> 00:10:38,400
um the first one being the modem 80 command interface the second being modifying the NAND flash

139
00:10:38,400 --> 00:10:45,480
and the third one being targeting some peripheral interface for example like the GPS module or the

140
00:10:45,720 --> 00:10:53,520
what have you after that we'd have to move from the arm core towards the DSP through either direct

141
00:10:53,520 --> 00:10:55,700
memory access or through some

142
00:10:56,520 --> 00:11:01,240
relink library which is the library used to pass messages back and forth from the arm core to the

143
00:11:01,240 --> 00:11:08,660
DSP and vice versa and finally once we obtain code execution on the DSP we'd have to find either a

144
00:11:08,660 --> 00:11:15,480
vulnerability or a side channel flaw in the trusted execution environment so this is basically the

145
00:11:15,480 --> 00:11:23,640
same thing but then presented in a nicer way okay um so the MGM radio has a rear connector that

146
00:11:23,640 --> 00:11:25,540
exposes the 80 modem command interface

147
00:11:26,520 --> 00:11:30,200
um with this interface you can read write parameters for example

148
00:11:30,200 --> 00:11:36,980
um analyzing the firmware gave us a list of commands and we immediately started

149
00:11:36,980 --> 00:11:41,380
looking for those with string parsing or variable length handling

150
00:11:44,040 --> 00:11:51,800
um the commands used to set a tall group list entry and subsequently enumerate them we found a

151
00:11:51,800 --> 00:11:56,180
classic format string vulnerability which allows us to write

152
00:11:56,520 --> 00:12:03,180
arbitrary data to any pointer that's uh that's listed on the stack and so on the slide on the

153
00:12:03,180 --> 00:12:09,520
right you see our user input that contains percent P and on the bottom you see it interpreted as in

154
00:12:09,520 --> 00:12:15,900
format string so this is a classic vulnerability um so this means that if like we can write

155
00:12:15,900 --> 00:12:20,720
anything that we'd like to anything that's listed onto the stack so if we can influence

156
00:12:20,720 --> 00:12:26,080
what's on the stack we have a write anything anywhere primitive unfortunately we don't

157
00:12:26,520 --> 00:12:30,740
have a write anything anywhere primitive so how do we go about that so there's uh luckily there's

158
00:12:30,740 --> 00:12:36,460
frame pointers in this firmware um frame pointers have the nice property that each frame pointer

159
00:12:36,460 --> 00:12:42,800
points to the next frame pointer so in this particular example let's say that argument 55

160
00:12:42,800 --> 00:12:49,700
uh that one contains a memory address and it's it points to argument 59 which in turn points to

161
00:12:49,700 --> 00:12:56,500
argument 71. now suppose that you write let's say zero x 80 to argument 50.9 which in turn points to argument 71.

162
00:12:56,520 --> 00:13:03,040
that will update argument 59, and in this particular example, it will now not point

163
00:13:03,040 --> 00:13:08,600
to argument 79, but it will point to byte zero of argument, not point to argument 71,

164
00:13:08,860 --> 00:13:14,020
but in this particular example, it will point to the byte zero of argument 79.

165
00:13:14,890 --> 00:13:22,320
All right, so now if we write anything to argument 59, it will update byte zero of argument

166
00:13:22,320 --> 00:13:29,420
79. Then we go back, and we update, then we write something to argument 55 again, for

167
00:13:29,420 --> 00:13:37,740
example, 0x81, and therefore argument 59 now points to byte one of argument 79, and this

168
00:13:37,740 --> 00:13:47,480
way, by continuing this route, we end up being argument number 79 being completely malleable

169
00:13:47,480 --> 00:13:52,240
by us. We completely control its value, and this way, we have a pointer on the stack,

170
00:13:52,320 --> 00:13:56,540
that we completely control, and therefore, we have a write anything anywhere primitive.

171
00:13:57,580 --> 00:14:03,980
Good. So, it turns out that the heap actually has read, write, and execute permissions,

172
00:14:04,260 --> 00:14:10,140
so the next steps would be just to write our shell code onto the heap, overwrite some pointer

173
00:14:10,140 --> 00:14:14,800
that points to executable code, and then trigger execution of that pointer, and boom.

174
00:14:15,440 --> 00:14:18,680
So, that got us a shell on the application processor.

175
00:14:27,660 --> 00:14:33,860
All right. So, the next step is to move on to the DSP. So, to recap, this means

176
00:14:33,860 --> 00:14:39,000
exploiting vulnerability in this communication library, called DSP link, or exploit some

177
00:14:39,000 --> 00:14:46,220
misconfiguration in the MPU's configuration. Right. So, this thing contains two cores

178
00:14:46,220 --> 00:14:52,060
that need to communicate somehow, and they do this by having shared internal RAM, and,

179
00:14:52,060 --> 00:14:57,740
some external DDR2 memory. And this could present an interesting avenue for lateral

180
00:14:57,740 --> 00:15:01,480
movement via direct memory access. So,

181
00:15:22,060 --> 00:15:27,020
exploit an interface that uses this shared memory range such as DSP link

182
00:15:28,120 --> 00:15:33,720
that's used in order to pass messages back and forth so when we dumped the

183
00:15:33,720 --> 00:15:38,340
configuration we saw that there is essentially no segmentation applied

184
00:15:38,340 --> 00:15:45,540
whatsoever so basically this this MPU poses zero problems for us like getting

185
00:15:45,540 --> 00:15:49,780
code execution on the DSP is as straightforward as just modifying parts

186
00:15:49,780 --> 00:15:57,960
of the DSP firmware in RAM so the next thing we did is we implemented a

187
00:15:57,960 --> 00:16:02,980
framework for running code on the DSP we wrote multiple application processor

188
00:16:02,980 --> 00:16:09,820
kernel modules which hijacks DSP control by allocating shared memory copying our

189
00:16:09,820 --> 00:16:14,660
payload over into the shared memory and then redirect DSP execution to our code

190
00:16:14,660 --> 00:16:19,740
and meanwhile ensuring that the watchdog which is a hardware peripheral was

191
00:16:19,740 --> 00:16:25,780
periodically kicked in order to prevent the board from resetting so all of this

192
00:16:25,780 --> 00:16:29,560
was kind of complicated by the fact that the DSP architecture is pretty hellish

193
00:16:29,560 --> 00:16:35,880
it has delayed branch branches variable degrees of concurrences lots of

194
00:16:35,880 --> 00:16:40,060
conditionals and very limited IDA support so we had to implement our own

195
00:16:40,060 --> 00:16:44,180
disassembler and on top of that we also added support for the architecture to

196
00:16:44,180 --> 00:16:49,440
the red deck decompiler and both will be upstreamed in the in the course of the

197
00:16:49,440 --> 00:16:49,720
next few years.

198
00:16:53,640 --> 00:17:02,680
As you can see the decompiler output reads a lot nicer than the disassembler

199
00:17:02,680 --> 00:17:12,560
alright and with that we had reliable DSP code execution so on to the final

200
00:17:12,560 --> 00:17:19,020
step attacking the TEE so at first we got our hands on a chip whisperer

201
00:17:19,020 --> 00:17:25,480
to do some power side-channel analysis however it quickly turned out that it

202
00:17:25,480 --> 00:17:30,900
wasn't the easiest route at all we had to find clock lines on the PCB we then

203
00:17:30,900 --> 00:17:36,580
find then find the DSP power line and decrease the DSP core clock speed

204
00:17:36,580 --> 00:17:41,580
correlate measurements to the key etc etc which turned out to be a nightmare

205
00:17:41,580 --> 00:17:49,000
we were quite sure that we are going to break the board this way so we took a step back and we looked at maybe we could attempt to fix it.

206
00:17:49,020 --> 00:17:55,680
we have other options here so it turns out the T is implemented in ROM by a

207
00:17:55,680 --> 00:18:03,060
subsystem called the secure kernel this codes runs DSP runs in DSP secure mode

208
00:18:03,060 --> 00:18:09,120
and all non secure mode code code can do is a perform a secure kernel API call

209
00:18:09,120 --> 00:18:15,480
which is very similar to a syscall on a regular PC so there's this thing called

210
00:18:15,480 --> 00:18:19,820
SK load which is an API call which allows for runtime loading of encrypted

211
00:18:19,820 --> 00:18:25,340
modules for example our tetra module which contains the tetra algorithms and

212
00:18:25,340 --> 00:18:31,000
it then decrypts these more this module with AES and validates them using RSA

213
00:18:31,000 --> 00:18:34,720
and then loads them into the trusted execution environment where they're

214
00:18:34,720 --> 00:18:39,860
invisible in non secure mode then if you're back into non secure mode you can

215
00:18:39,860 --> 00:18:44,680
invoke one of these algorithms through SK algo invoke and which

216
00:18:44,680 --> 00:18:45,180
uh

217
00:18:45,180 --> 00:18:52,400
allows non secure code to invoke these algorithms and get the result from one

218
00:18:52,400 --> 00:18:56,280
of these functions that was previously loaded and these modules are encrypted

219
00:18:56,280 --> 00:19:00,780
with a customer encryption key so that's the factory set key in this case that

220
00:19:00,780 --> 00:19:08,300
key belongs to Motorola so now for our tech we got some inspiration modern

221
00:19:08,300 --> 00:19:13,200
computers use caches to speed up memory accesses and this introduces some

222
00:19:13,200 --> 00:19:14,760
timing differences during lookups

223
00:19:14,760 --> 00:19:19,740
uh and this in turn may leak some information on secrets involved so in

224
00:19:19,740 --> 00:19:25,560
2005 already uh Daniel Bernstein wrote an interesting paper on performing such

225
00:19:25,560 --> 00:19:30,440
attacks on AES where you build a profile of timing differences and then you observe

226
00:19:30,440 --> 00:19:35,420
the target's system characteristics you correlate these with the observation and

227
00:19:35,420 --> 00:19:43,960
then you derive which key fits best right so for the DSP we are targeting it has several caches you

228
00:19:44,760 --> 00:19:50,120
have a data cache you have a level one code cache and you have a level two cache the level one data

229
00:19:50,120 --> 00:19:57,280
cache has a 64-byte line where memory reads are fast and data that is already for data that's

230
00:19:57,280 --> 00:20:05,680
already cached and otherwise it's slow so we can evict addresses from cache in this 64-byte

231
00:20:05,680 --> 00:20:13,340
granularity and it turns out that doing so from uh from non-secure mode also affects secure portions

232
00:20:13,340 --> 00:20:14,740
from the uh address space so that's why it's so important for us to be able to do this in the future

233
00:20:14,740 --> 00:20:21,580
database that you cannot usually read from non-secure mode um furthermore there's a feature

234
00:20:21,580 --> 00:20:27,540
called a cache freeze which basically means the cache is turned into read-only state uh which

235
00:20:27,540 --> 00:20:32,940
means that whenever you get a cache hit you get a performance increase whenever you get a cache miss

236
00:20:32,940 --> 00:20:39,800
you have to fetch it from main memory but the cache isn't updated so now that we have some

237
00:20:39,800 --> 00:20:44,720
control over the cache uh which AES decryption decryption step should we do in order to be able to

238
00:20:44,740 --> 00:20:52,460
retarget well it turns out that inverse subbytes we're decrypting AES so inverse subbytes uses an

239
00:20:52,460 --> 00:20:59,640
s-box and that means a memory lookup so we should probably target that the thing is this s-box is

240
00:20:59,640 --> 00:21:05,600
located in some page in ROM but it's not readable from non-secure mode so we don't really know where

241
00:21:05,600 --> 00:21:11,300
the s-box is so first thing we have to figure out is figure out where the s-box is so what we did

242
00:21:11,300 --> 00:21:14,320
is we start by evicting the first cache line

243
00:21:14,740 --> 00:21:23,120
the first 64 bytes of this ROM invoke skload and then measured the time it took to to run that code

244
00:21:23,120 --> 00:21:28,040
in terms of clock cycles and then we do so for the second cache line and then the next and so forth

245
00:21:28,040 --> 00:21:36,800
and eventually we plot this so we get something like this so it seems quite obvious the s-box is

246
00:21:36,800 --> 00:21:43,240
right over there okay so let's look a bit deeper um we're going to prepare the cache

247
00:21:44,740 --> 00:21:52,760
follows we run skload so that the full s-box will be in cache and then we evict the first 32 entries

248
00:21:52,760 --> 00:21:58,740
so this is what we refer to as the first octant because it's one eighth of the s-box and then we

249
00:21:58,740 --> 00:22:08,480
enable this cache freeze feature and now whenever a timing penalty occurs we know that this happens

250
00:22:08,480 --> 00:22:14,420
due to the first octant of the s-box being hit so we'll assume this setup for the remainder of the

251
00:22:14,740 --> 00:22:22,940
presentation so having evicted the first octant of the s-box from cache we set ct0 so that's the

252
00:22:22,940 --> 00:22:29,880
first ciphertext byte that we provide to skload we set it to zero and we randomize the remainder

253
00:22:29,880 --> 00:22:36,660
of the ciphertext and we get and we measure average running times of skload and then we

254
00:22:36,660 --> 00:22:43,920
repeat that for all the values of ct0 as well and then we plot the results so again we set the first

255
00:22:44,740 --> 00:22:49,440
ciphertext byte to zero we randomize the remainder and we get the average running time

256
00:22:49,440 --> 00:22:55,080
of skload and so that thing now our controlled value gets put through the s-box

257
00:22:57,040 --> 00:23:04,280
so when we plot that we get something like this which is quite interesting so we know for by

258
00:23:04,280 --> 00:23:13,180
construction that the penalty is observed when our ciphertext byte x or a round key byte is less

259
00:23:14,740 --> 00:23:21,160
and in the above example we find that this leaks some information about the round key byte so in

260
00:23:21,160 --> 00:23:27,740
this particular case the round key byte is located somewhere between 32 and 64. so that's great we

261
00:23:27,740 --> 00:23:33,360
effectively leaked three bits of this round key byte so we repeat the same thing for all the uh

262
00:23:33,360 --> 00:23:40,900
for the remaining remaining 15 round key bytes we obtain a total of 48 bits of round key

263
00:23:42,640 --> 00:23:44,320
however this approach is

264
00:23:44,740 --> 00:23:50,760
fairly limited because after all uh the the other five bits of the round key do not influence which

265
00:23:50,760 --> 00:23:57,640
s-box octant is hit and therefore we cannot we cannot leak those and there's still 80 bits left

266
00:23:57,640 --> 00:24:03,400
to brute force so that's not really viable approach either so we have to we have to dive in even

267
00:24:03,400 --> 00:24:12,120
deeper um so suppose that we instead of attacking the first s-box look up let's attack let's look at

268
00:24:14,740 --> 00:24:24,060
um so round one s-box look up has introduced some diffusion uh in within the state byte so this

269
00:24:24,060 --> 00:24:30,160
now means that the least significant bits of this byte actually do influence which octant is hit

270
00:24:30,160 --> 00:24:36,180
uh during the s-box look up so we now have to account for shifting of the state bytes

271
00:24:36,180 --> 00:24:42,620
um the the influence of the next round key and the diffusion of mixed column step which was a step

272
00:24:42,620 --> 00:24:43,700
that's taken in between

273
00:24:44,740 --> 00:24:50,000
uh and then we can extend our attack and I won't go into further details because this goes uh this

274
00:24:50,000 --> 00:24:56,140
probably goes if if I would explain to myself it would go way beyond my head so I'll just demonstrate it

275
00:25:12,080 --> 00:25:14,340
all right so this is

276
00:25:14,740 --> 00:25:18,020
right after we got a shell on the on the radio on the encore

277
00:25:18,860 --> 00:25:22,020
so this is a loading a kernel module that kicks the watchdog

278
00:25:23,960 --> 00:25:26,380
and now we hijack code execution on the DSP

279
00:25:27,240 --> 00:25:30,300
and next thing we do is run the side channel attack

280
00:25:32,420 --> 00:25:38,080
so this is the full thing I'm showing you this because we optimize it such

281
00:25:38,080 --> 00:25:42,580
that it's stupidly fast so this only takes a minute and then it gives you the key

282
00:25:55,660 --> 00:25:59,480
so all the bytes in between as you see those are round key bytes

283
00:26:00,480 --> 00:26:00,960
so

284
00:26:02,960 --> 00:26:03,440
so

285
00:26:13,780 --> 00:26:14,260
so

286
00:26:14,260 --> 00:26:14,320
so

287
00:26:14,740 --> 00:26:14,760
PC

288
00:26:14,760 --> 00:26:14,840
so

289
00:26:35,360 --> 00:26:36,000
again

290
00:26:37,220 --> 00:26:37,540
.

291
00:26:37,540 --> 00:26:37,800
le

292
00:26:37,800 --> 00:26:38,620
Women

293
00:26:40,400 --> 00:26:41,040
and

294
00:26:41,040 --> 00:26:41,180
And

295
00:26:41,180 --> 00:26:41,540
Mint

296
00:26:41,540 --> 00:26:41,860
Drink

297
00:26:41,860 --> 00:26:41,920
Drink

298
00:26:46,300 --> 00:26:49,600
Now, clearly this isn't the actual Motorola key, it's just a mockup.

299
00:26:52,300 --> 00:26:58,380
Of course, it wouldn't be fair if there weren't even more hurdles for us to jump over, so

300
00:26:58,380 --> 00:27:02,960
it turned out there was an additional encryption layer for which we had to adapt the attack

301
00:27:02,960 --> 00:27:03,180
to.

302
00:27:03,860 --> 00:27:09,220
Then there was an additional obfuscation layer which stumped us for a bit, but once we observed

303
00:27:09,220 --> 00:27:14,220
similarities between the loaded modules, it turns out that the obfuscation was just

304
00:27:14,220 --> 00:27:17,740
a rolling XOR that incrementally calculated a checksum.

305
00:27:19,600 --> 00:27:23,800
With that, we could now extract the customer encryption key in less than a minute, reverse

306
00:27:23,800 --> 00:27:28,220
engineered the remainder of the module format, decrypted our target module, reverse engineered

307
00:27:28,220 --> 00:27:30,640
it, and finally got the secret algorithms.

308
00:27:32,580 --> 00:27:35,120
So a little recap for the journey so far.

309
00:27:35,360 --> 00:27:38,540
We found a format string vulnerability in the AT interface.

310
00:27:38,540 --> 00:27:42,200
On the rear connector of the radio.

311
00:27:43,220 --> 00:27:46,060
To get us code execution on the baseband's application processor.

312
00:27:46,400 --> 00:27:51,480
We then jumped to the DSP via shared memory, explored the cache timing side channel on

313
00:27:51,480 --> 00:27:53,840
the TEE of the DSP to extract our secret algos.

314
00:27:54,120 --> 00:27:55,160
And now we have them.

315
00:27:58,020 --> 00:27:58,720
All right.

316
00:27:58,860 --> 00:28:02,660
So that brings us to the point that we can actually start doing what we wanted to do,

317
00:28:02,780 --> 00:28:07,820
and that is analyze the cryptographic primitives underpinning the security of Tetra.

318
00:28:09,000 --> 00:28:09,440
And...

319
00:28:12,900 --> 00:28:13,740
Is this better?

320
00:28:14,000 --> 00:28:14,300
Yeah.

321
00:28:14,480 --> 00:28:14,720
Okay.

322
00:28:15,360 --> 00:28:15,980
All right.

323
00:28:16,200 --> 00:28:21,400
So we can now finally start doing what we came here for, and that is analyze the security

324
00:28:21,400 --> 00:28:21,960
of Tetra.

325
00:28:22,140 --> 00:28:25,620
All the primitives are, by the way, public now, so you can get them off GitHub if you

326
00:28:25,620 --> 00:28:27,020
want to take a look at it for yourselves.

327
00:28:27,880 --> 00:28:32,400
I will start by explaining some things and explain some vulnerabilities that we found.

328
00:28:32,900 --> 00:28:38,520
So what you see here is how this authentication is shown in the stack.

329
00:28:38,520 --> 00:28:45,160
You see some boxes, TA11, TA22, and those are like black boxes.

330
00:28:45,340 --> 00:28:47,820
They don't tell you how it works.

331
00:28:48,040 --> 00:28:51,900
We are now able to actually inspect how these things are implemented.

332
00:28:52,300 --> 00:28:56,980
And we saw that all the primitives that are marked TA something are based on a proprietary

333
00:28:57,960 --> 00:28:59,180
cipher named hurdle.

334
00:28:59,360 --> 00:29:04,280
It's a 16-round Faisal cipher which uses 64-bit blocks and a 128-bit key.

335
00:29:04,460 --> 00:29:06,400
And the primitives based...

336
00:29:07,100 --> 00:29:08,100
Called TB.

337
00:29:08,100 --> 00:29:11,520
Called TB are based on very simple XOR and addition operations.

338
00:29:12,180 --> 00:29:17,740
Also interestingly, we found that some of these blocks are identical or highly related, and

339
00:29:17,740 --> 00:29:18,780
that will help us later.

340
00:29:21,700 --> 00:29:25,500
So this is an overview of a part of hurdle.

341
00:29:25,980 --> 00:29:33,920
Hurdle has an F function that combines half of the states, so 32 bits, with 96 bits of

342
00:29:34,740 --> 00:29:35,840
round key information.

343
00:29:36,240 --> 00:29:37,540
And it has this...

344
00:29:37,540 --> 00:29:39,940
Really extensive cascading structure.

345
00:29:40,500 --> 00:29:41,440
So it's very...

346
00:29:41,440 --> 00:29:42,700
It's quite interesting to look at.

347
00:29:42,800 --> 00:29:46,540
And I'm looking really forward to some professional cryptanalytical insights.

348
00:29:47,360 --> 00:29:48,660
We could not break it.

349
00:29:48,760 --> 00:29:53,280
We could, however, find the function that originally generated the S-box.

350
00:29:53,700 --> 00:29:56,880
It's based on the Nyberg S-box, just like AES.

351
00:29:58,340 --> 00:30:01,160
But yeah, we didn't get any further with this.

352
00:30:01,240 --> 00:30:04,280
So we hope some of you guys maybe want to look into this.

353
00:30:05,300 --> 00:30:07,000
We will discuss, however...

354
00:30:07,000 --> 00:30:07,520
We will discuss, however...

355
00:30:07,540 --> 00:30:09,560
This is an attack we found on this authentication scheme.

356
00:30:09,820 --> 00:30:16,960
What you see here is how the mobile station and the infrastructure perform mutual authentication.

357
00:30:17,440 --> 00:30:23,000
So they generate some random numbers, and through a cryptographic dance, they prove

358
00:30:23,000 --> 00:30:24,680
knowledge of a shared secret key.

359
00:30:25,320 --> 00:30:31,000
And if this authentication succeeds, it will also yield a session key, the DCK.

360
00:30:32,080 --> 00:30:37,200
And below, on the bottom of this slide, you see how this DCK is constructed in terms of

361
00:30:37,200 --> 00:30:37,900
these primitives.

362
00:30:39,160 --> 00:30:43,120
Now that we have obtained these primitives, we can do some simplification.

363
00:30:43,680 --> 00:30:50,620
We found that TA21 is actually identical to TA11, except that the RS, the random seed

364
00:30:50,620 --> 00:30:53,560
supplied by the infrastructure, has a reversed byte order.

365
00:30:54,420 --> 00:31:01,420
Additionally, TA22 is actually identical to TA12, and the TB4 function is nothing more

366
00:31:01,420 --> 00:31:02,200
than an XOR.

367
00:31:02,420 --> 00:31:06,040
So the session key is generated by XORing together.

368
00:31:06,180 --> 00:31:06,740
Two.

369
00:31:07,200 --> 00:31:09,000
Half session keys that were generated previously.

370
00:31:10,480 --> 00:31:13,820
Now this is interesting because this allows for an attack.

371
00:31:14,900 --> 00:31:20,080
Let's assume that we impersonate the infrastructure and we target a mobile station.

372
00:31:20,980 --> 00:31:25,260
Additionally, let's assume that we can predict the random number that is being generated

373
00:31:25,260 --> 00:31:26,220
by the mobile station.

374
00:31:26,580 --> 00:31:30,660
This may seem like a bit of a stretch, but in embedded systems, random number generation

375
00:31:30,660 --> 00:31:36,860
is really hard and quite often not fully unpredictable, so this may be more feasible than you might

376
00:31:36,860 --> 00:31:37,460
initially think.

377
00:31:38,420 --> 00:31:44,460
We can provide the mobile station with an RS, a random seed, that is a palindrome.

378
00:31:44,640 --> 00:31:49,380
So it's identical in the reversed byte order as in the forward byte order.

379
00:31:49,940 --> 00:31:55,600
And if we do all that, then we can simplify the DCK derivation formula to something that

380
00:31:55,600 --> 00:31:59,560
has the same on the left and on the right side of the XOR operation.

381
00:32:00,020 --> 00:32:03,960
And by nature of the XOR function, we end up with a zero key.

382
00:32:04,620 --> 00:32:06,580
So what we have achieved in this case?

383
00:32:06,860 --> 00:32:12,160
It's an authenticated channel with a mobile station with a known session key of all zeros

384
00:32:12,560 --> 00:32:15,820
without even having knowledge of the original shared secret K.

385
00:32:18,440 --> 00:32:21,500
So next, let's talk about identity encryption.

386
00:32:22,060 --> 00:32:27,720
Identity encryption in Tetra is implemented in a primitive called TA61, and this is used

387
00:32:27,720 --> 00:32:34,060
to encrypt 24-bit Tetra addresses, which you can compare to a phone number if you want.

388
00:32:34,660 --> 00:32:35,300
And...

389
00:32:35,300 --> 00:32:41,360
These encrypted addresses are used for a while, until a certain network key is changed.

390
00:32:41,600 --> 00:32:44,640
This won't happen very often, maybe every few weeks or so.

391
00:32:45,060 --> 00:32:49,040
So Tetra doesn't offer strong anonymity, but pseudonymity nonetheless.

392
00:32:49,920 --> 00:32:55,780
At this point, unfortunately, we cannot disclose the implementation of TA61 due to some serious

393
00:32:55,780 --> 00:32:57,880
concerns from Tetra stakeholders.

394
00:32:58,280 --> 00:33:03,540
We will publish them in December, but at this point, at least we can share with you the

395
00:33:03,540 --> 00:33:04,360
outline of an attack.

396
00:33:05,300 --> 00:33:08,580
So that we can have an informed discussion on the security of this primitive.

397
00:33:09,720 --> 00:33:11,560
And the attack looks as follows.

398
00:33:12,620 --> 00:33:19,140
The CCK network key is first being used in a hurdle encryption in order to generate a

399
00:33:19,140 --> 00:33:23,080
64-bit intermediate secret, which is shown here as C.

400
00:33:23,760 --> 00:33:30,060
And only then, this intermediate secret is used in order to encrypt this 24-bit identity.

401
00:33:30,860 --> 00:33:34,020
And this happens in a weird two rounds.

402
00:33:34,520 --> 00:33:35,160
Light.

403
00:33:35,300 --> 00:33:35,440
Weight.

404
00:33:35,640 --> 00:33:36,220
Crypto.

405
00:33:37,030 --> 00:33:37,320
Scheme.

406
00:33:37,920 --> 00:33:40,520
And this is vulnerable to a meet-in-the-middle attack.

407
00:33:40,820 --> 00:33:47,080
As an attacker, we can try to gather a few pairs of unencrypted identities together

408
00:33:47,080 --> 00:33:53,000
with their encrypted equivalent, and start computing forward from the unencrypted one,

409
00:33:53,140 --> 00:33:59,240
and backward from the encrypted one, and see, at the meeting point, which guess for

410
00:33:59,240 --> 00:34:01,900
the intermediate secret C would make sense.

411
00:34:02,580 --> 00:34:05,280
And this attack has a complexity of 2 to the 48th.

412
00:34:05,300 --> 00:34:08,600
Which, on a regular laptop, runs in about a minute.

413
00:34:09,200 --> 00:34:14,740
And after you have computed this value of C, you can instantly de-anonymize anything

414
00:34:14,740 --> 00:34:17,120
that comes past on the error interface.

415
00:34:18,520 --> 00:34:23,260
Also, it gives you an option to attack a hurdle encryption, because you have C, which

416
00:34:23,260 --> 00:34:24,840
is the output of a hurdle encryption.

417
00:34:25,220 --> 00:34:31,320
And if you can somehow break that encryption and derive what the original CCK was, there

418
00:34:31,320 --> 00:34:33,140
is a very, very serious problem for Tetra.

419
00:34:33,260 --> 00:34:35,280
So that's also something to investigate in the future.

420
00:34:35,960 --> 00:34:41,500
Now, de-anonymization can be quite serious, depending on the use case of a Tetra network.

421
00:34:42,560 --> 00:34:48,860
Tetra identities are typically distributed in ranges, so regular police forces will get

422
00:34:48,860 --> 00:34:53,460
one range, while intervention teams get another range, and firefighters will get yet another

423
00:34:53,460 --> 00:34:53,840
range.

424
00:34:54,280 --> 00:34:59,880
So, as an attacker, if you invest some effort into identifying which ranges belong to which

425
00:34:59,880 --> 00:35:03,440
kind of services, you can have a very interesting intelligence position.

426
00:35:04,440 --> 00:35:05,280
This can be very useful.

427
00:35:05,300 --> 00:35:11,800
It can be used, for instance, in a counterintelligence context, when you may be able to notice when

428
00:35:12,540 --> 00:35:18,480
covert surveillance units are near you all the time, or it can serve as an early warning

429
00:35:18,480 --> 00:35:22,840
for organized crime when intervention teams seem to pile up somewhere in the vicinity.

430
00:35:24,160 --> 00:35:29,560
The attack is fully passive and can be executed with very cheap hardware, so it's very realistic

431
00:35:29,560 --> 00:35:30,820
that this can be done.

432
00:35:32,200 --> 00:35:32,720
Right.

433
00:35:32,720 --> 00:35:36,660
So, let's talk about the actual encryption algorithms.

434
00:35:37,280 --> 00:35:43,480
In Tetra, traffic is encrypted with one of four key stream generators, as Jos pointed

435
00:35:43,480 --> 00:35:48,200
out previously, and we found that all of them share a very similar structure.

436
00:35:48,660 --> 00:35:50,900
And depicted here is TA2.

437
00:35:51,120 --> 00:35:55,980
On the top, you see the key register, an 80-bit register, that provides information

438
00:35:55,980 --> 00:36:01,860
to the state register below, and eventually, the state register will output key stream,

439
00:36:02,000 --> 00:36:02,700
which is then used.

440
00:36:02,720 --> 00:36:09,900
for encryption of tetra traffic to us ta2 looks robust but we are not cryptographers and more

441
00:36:09,900 --> 00:36:14,400
public scrutiny is needed before we can finally decide that this is all good and safe to use

442
00:36:15,910 --> 00:36:20,820
but this is where it gets real interesting because we found a backdoor in the ta1 cipher

443
00:36:21,640 --> 00:36:27,480
ta1 is intended for private use cases commercial use cases like private security but it's also

444
00:36:27,480 --> 00:36:34,260
been distributed to like say less friendly police and military forces that europe did not have very

445
00:36:34,260 --> 00:36:41,820
good footing with at the time these networks were originally conceived ta1 is advertised as having

446
00:36:41,820 --> 00:36:48,680
an 80-bit key but the first thing it does is apply a secret reduction step that compresses this 80-bit

447
00:36:48,680 --> 00:36:55,920
key into a 30-bit 32-bit register and from then on it will only use this 32-bit register for the

448
00:36:55,920 --> 00:36:57,260
generation of keystream

449
00:36:57,980 --> 00:37:05,140
so obviously this is trivial to attack nowadays you will be able to crack such a key in a minute

450
00:37:05,140 --> 00:37:11,140
and get a key that works for decryption of all traffic on that frequency additionally you could

451
00:37:11,140 --> 00:37:17,620
decide to actually start injecting traffic which is especially worrisome when tetra is used in

452
00:37:17,620 --> 00:37:27,080
a data carrying capacity such as skada one telecontrol kind of traffic so small demonstration

453
00:37:36,460 --> 00:37:38,240
that can only usually develop up to 10 to 20 percent of 조ouse driving speed

454
00:37:38,240 --> 00:37:38,480
but instead of a maximum of 100 percent of the traffic down here you'll see a much larger

455
00:37:38,480 --> 00:37:44,440
rate of action i'm going to give you a good example of the benefits of the technology

456
00:37:44,440 --> 00:37:46,540
i'm just going to break them down you can see that as far as the time they offer you know

457
00:37:46,540 --> 00:37:48,980
this is something you can move about in your system you can easily move your data around

458
00:37:48,980 --> 00:37:54,640
it's a pretty basic idea i think it's a little bit different than what some would expect but

459
00:37:54,640 --> 00:37:55,140
it's a very simple and simple method of using the technology that you're using the today's

460
00:37:55,140 --> 00:38:00,180
military operators, private security, and harbor and airport personnel.

461
00:38:00,500 --> 00:38:04,640
In addition, Tetra is used in a wide area network carrying capacity

462
00:38:04,640 --> 00:38:09,200
for SCADA telecontrol of oil and gas pipelines, electrical substations,

463
00:38:09,420 --> 00:38:11,800
water management, and even railway signaling.

464
00:38:12,200 --> 00:38:16,820
Tetra offers confidential communication guaranteed through its so-called

465
00:38:16,820 --> 00:38:18,900
Air Interface Encryption feature.

466
00:38:19,120 --> 00:38:24,240
This feature encrypts Tetra traffic by means of one of four proprietary stream ciphers

467
00:38:25,760 --> 00:38:30,040
TA1, TA2, TA3, and TA4.

468
00:38:30,340 --> 00:38:35,540
Of these ciphers, TA1 can be exported globally with appropriate export approval

469
00:38:35,540 --> 00:38:38,980
and can be used by both commercial and government parties.

470
00:38:39,320 --> 00:38:44,900
As such, TA1 is used to protect select law enforcement, military and private security

471
00:38:44,900 --> 00:38:49,700
radio communications, as well as SCADA radio links of global critical infrastructure.

472
00:38:50,200 --> 00:38:54,160
Tetra is used in many different sectors, ranging from electrical and water

473
00:38:54,240 --> 00:38:57,800
utilities to oil and gas, transport, and mining.

474
00:38:58,120 --> 00:39:02,580
Since the Tetra encryption algorithms have been kept secret for over 20 years,

475
00:39:02,900 --> 00:39:06,920
their security has never been properly publicly evaluated, until now.

476
00:39:07,520 --> 00:39:11,340
Midnight Blue researchers have reverse engineered the algorithms and uncovered

477
00:39:11,340 --> 00:39:16,500
several vulnerabilities in Tetra, including a backdoor in the TEA-1 algorithm,

478
00:39:16,740 --> 00:39:21,640
which reduces its advertised key strength of 80 bits to a mere 32 bits.

479
00:39:21,900 --> 00:39:24,140
This backdoor, which is festered,

480
00:39:24,240 --> 00:39:28,520
and global critical infrastructure for decades, enables the interception and manipulation

481
00:39:28,940 --> 00:39:33,860
of TEA-1 protected Tetra communications from anywhere within cell tower coverage,

482
00:39:34,060 --> 00:39:35,640
which may be up to tens of kilometers.

483
00:39:36,260 --> 00:39:40,380
Due to the simplicity of the backdoor, even attackers with limited resources,

484
00:39:40,620 --> 00:39:45,280
such as a $10 radio dongle, can crack TEA-1 keys in a matter of minutes.

485
00:39:45,600 --> 00:39:50,280
In this demonstration, carried out on a real network, the attacker captures traffic

486
00:39:50,280 --> 00:39:52,900
and identifies messages on which to mount the attack.

487
00:39:54,240 --> 00:39:57,360
Now, the attacker computes the key used on this frequency.

488
00:39:57,640 --> 00:39:58,980
This will take about a minute.

489
00:40:00,500 --> 00:40:04,480
Once the key has been cracked, voice communications can be intercepted

490
00:40:04,480 --> 00:40:08,620
while the attack remains fully undetected, or data can be actively injected.

491
00:40:10,980 --> 00:40:16,000
In the case of SCADA tele-control communications being carried over Tetra-wide area networks,

492
00:40:16,460 --> 00:40:20,720
attackers can use this vulnerability to obtain direct access deep within

493
00:40:20,720 --> 00:40:23,700
the operational technology networks of critical infrastructure.

494
00:40:24,240 --> 00:40:28,260
Allowing them to intercept and manipulate network traffic-controlling equipment

495
00:40:28,260 --> 00:40:34,140
like switchgear, circuit breakers, and valves at electrical substations or oil and gas pipelines.

496
00:40:34,580 --> 00:40:38,060
Due to the highly sensitive nature of the uncovered issues,

497
00:40:38,460 --> 00:40:43,320
Midnight Blue has spent more than one and a half years in a carefully coordinated disclosure process

498
00:40:43,320 --> 00:40:46,020
with multiple government and industry stakeholders,

499
00:40:46,460 --> 00:40:49,460
guided by the Dutch government's National Cyber Security Center.

500
00:40:50,360 --> 00:40:52,360
During this process, detailed...

501
00:40:54,300 --> 00:40:54,900
Oh, wow.

502
00:40:56,540 --> 00:40:57,240
Thank you.

503
00:41:04,240 --> 00:41:05,220
Awesome, thank you.

504
00:41:06,760 --> 00:41:10,460
So, with a small recap and demonstration video, I think we made a point, right?

505
00:41:12,020 --> 00:41:15,300
Well, Etsy has some interesting things to say about this.

506
00:41:15,780 --> 00:41:19,300
First, they claim that we are using a very high-powered graphics card

507
00:41:19,300 --> 00:41:20,700
in order to be able to attack this.

508
00:41:20,840 --> 00:41:24,220
Well, in my opinion, a 2016 consumer-grade graphics card

509
00:41:24,240 --> 00:41:27,580
is not that high-end, but hey, opinions may differ.

510
00:41:28,360 --> 00:41:31,740
Also, they state that 25 years ago, when Tetra was standardized,

511
00:41:32,180 --> 00:41:36,500
32 bits of key entropy was probably sufficient to withstand attack.

512
00:41:37,000 --> 00:41:39,980
And they state that you need some pretty reasonable equipment

513
00:41:39,980 --> 00:41:42,860
in order to be able to attack TEA-1.

514
00:41:43,620 --> 00:41:45,980
Now, I don't think I have to explain to you that this...

515
00:41:46,560 --> 00:41:48,360
Now, I don't think that this...

516
00:41:48,360 --> 00:41:49,760
That I have to explain to you guys...

517
00:41:49,760 --> 00:41:50,620
Thank you.

518
00:41:51,020 --> 00:41:52,800
That this just doesn't make sense.

519
00:41:55,480 --> 00:41:58,740
Yeah, you know, why would we make any assumptions on this?

520
00:41:59,020 --> 00:42:04,340
Why would we use reasonable equipment in order to attack such a cipher?

521
00:42:04,760 --> 00:42:06,320
Let's see what this bad boy can do.

522
00:42:18,880 --> 00:42:20,340
Hi, we're Midnight Blue.

523
00:42:20,820 --> 00:42:23,720
About two weeks ago, we announced the Tetra Burst vulnerabilities.

524
00:42:24,480 --> 00:42:27,340
Consisting of five vulnerabilities in the Tetra radio standard,

525
00:42:27,620 --> 00:42:29,300
two of which are deemed critical.

526
00:42:29,720 --> 00:42:33,640
Since then, ETSI, the standardization body responsible for Tetra,

527
00:42:33,740 --> 00:42:36,620
has made public statements in which they downplay the seriousness

528
00:42:36,620 --> 00:42:37,500
of the vulnerabilities.

529
00:42:38,120 --> 00:42:41,060
In these statements, they resorted to a semantic discussion,

530
00:42:41,320 --> 00:42:43,960
not calling a spade a spade, or, more specifically,

531
00:42:44,300 --> 00:42:46,080
not calling a backdoor a backdoor.

532
00:42:46,460 --> 00:42:49,680
Furthermore, they made a number of evidently false statements,

533
00:42:49,920 --> 00:42:53,040
such as claiming packet injection and TEA-1 encrypted networks

534
00:42:53,040 --> 00:42:56,440
would be impossible, and that 32 bits of cryptographic strength

535
00:42:56,440 --> 00:42:58,580
would have been sufficient in the late 90s.

536
00:42:59,020 --> 00:43:03,220
To any information security expert, it's pretty clear that this is not the case.

537
00:43:03,520 --> 00:43:05,800
But to help remove those few remaining doubts,

538
00:43:06,000 --> 00:43:08,620
we decided to take on the challenge of cracking TEA-1

539
00:43:08,620 --> 00:43:13,420
on this beautiful machine produced in 1998, running good old Windows 95.

540
00:43:21,160 --> 00:43:23,020
Frankly, the hardware is so old,

541
00:43:23,040 --> 00:43:24,840
that it wasn't easy to get our hands on.

542
00:43:26,820 --> 00:43:29,980
When we run the cracking tool, we see it reports that it needs

543
00:43:29,980 --> 00:43:32,400
about 13 hours to go through the entire search space.

544
00:43:35,340 --> 00:43:37,820
After 12 and a half hours, the key is found,

545
00:43:38,040 --> 00:43:42,380
demonstrating the feasibility of cracking TEA-1 on 90s consumer hardware.

546
00:43:45,400 --> 00:43:47,760
Alright ETSI, now that we've cleared up this issue,

547
00:43:47,900 --> 00:43:51,040
please let us know if you'd like us to demonstrate packet injection as well.

548
00:43:53,040 --> 00:43:53,420
Thank you.

549
00:44:03,320 --> 00:44:06,240
Right, now, I think we've got that out of the way.

550
00:44:07,800 --> 00:44:11,740
So, we discussed TEA-1, it's backdoored, it's trivially breakable.

551
00:44:12,360 --> 00:44:15,480
But the other encryption algorithms should be fine, right?

552
00:44:15,960 --> 00:44:19,760
There's still TEA-2 and TEA-3, which are used generally by law enforcement

553
00:44:19,760 --> 00:44:20,940
and emergency services.

554
00:44:20,940 --> 00:44:22,280
Well, not really.

555
00:44:22,700 --> 00:44:26,060
Because we also found a protocol-level vulnerability in Tetra.

556
00:44:26,680 --> 00:44:30,300
And in order to understand that, we need to dive into the standard a little bit more.

557
00:44:31,360 --> 00:44:33,780
So, in Tetra, signaling is encrypted.

558
00:44:34,000 --> 00:44:37,760
And only the very first part, the MAC header, is unencrypted.

559
00:44:38,080 --> 00:44:42,000
The MAC header contains some high-level stuff like the length of the package

560
00:44:42,000 --> 00:44:44,660
and the addressee of the message.

561
00:44:45,300 --> 00:44:48,420
And everything after that is encrypted with the key stream generator.

562
00:44:50,080 --> 00:44:56,980
It's important to note that Tetra messages have no authenticity or integrity guarantees whatsoever.

563
00:44:57,580 --> 00:45:00,860
So, there is a CRC on the MAC level.

564
00:45:01,080 --> 00:45:06,560
And you may optionally add a CRC32 in the data that's encrypted here.

565
00:45:06,840 --> 00:45:10,120
But that's not a cryptographic MAC in any sense.

566
00:45:11,000 --> 00:45:13,340
So, an attacker will be able to forge messages.

567
00:45:13,460 --> 00:45:16,320
And whenever such a message is decrypted,

568
00:45:16,320 --> 00:45:19,740
the radio will just interpret it and parse it at face value.

569
00:45:21,180 --> 00:45:25,400
So, the application of the key stream works as follows.

570
00:45:25,760 --> 00:45:29,540
The key stream generator function gets two inputs.

571
00:45:29,720 --> 00:45:32,680
It gets a key and it gets an IV.

572
00:45:32,980 --> 00:45:37,820
And this IV is intended to make sure that for each message,

573
00:45:38,000 --> 00:45:39,940
a different key stream is being generated.

574
00:45:40,820 --> 00:45:46,220
And in Tetra, the IV mostly consists of the network type.

575
00:45:46,840 --> 00:45:51,180
So, the network type is a set of frame counters.

576
00:45:51,340 --> 00:45:54,860
There's slot frame, multi-frame, all kinds of frame counters.

577
00:45:55,140 --> 00:46:01,500
And these things must be known to the radio whenever he wants to perform an encryption or decryption.

578
00:46:01,800 --> 00:46:02,840
So, how does he know that?

579
00:46:03,020 --> 00:46:07,380
Well, because it's broadcast by the infrastructure in sync and sysinfo frames.

580
00:46:08,620 --> 00:46:15,180
And once more, these messages in Tetra have no further integrity guarantees whatsoever.

581
00:46:15,180 --> 00:46:20,420
So, the attack starts to be clear to some of you, maybe.

582
00:46:20,600 --> 00:46:24,340
An attacker can decide to overpower the infrastructure

583
00:46:24,340 --> 00:46:30,240
and target a mobile station and alter its perception of the network time.

584
00:46:30,960 --> 00:46:36,340
And if you start playing with the sync and sysinfo frames with a targeted mobile station,

585
00:46:36,500 --> 00:46:44,760
it will happily use those counters and start using key stream that was relevant at the time you specified to it.

586
00:46:44,760 --> 00:46:48,560
And this works regardless of which key stream generator is used.

587
00:46:48,760 --> 00:46:50,780
So, also on TEA2 and TEA3.

588
00:46:53,440 --> 00:46:55,380
The attack outline would be as follows.

589
00:46:56,200 --> 00:46:59,940
Imagine we capture an interesting message at some point in time.

590
00:47:00,100 --> 00:47:03,700
It's encrypted, but we decide that we would like to have the plain text contents.

591
00:47:04,680 --> 00:47:09,240
Then, at a later point in time, we identify a mobile station that we want to attack.

592
00:47:09,820 --> 00:47:12,340
And it can be the same mobile station.

593
00:47:12,400 --> 00:47:14,440
It can also be another mobile station.

594
00:47:14,760 --> 00:47:16,420
As long as it has the same key material.

595
00:47:17,160 --> 00:47:20,460
We then overpower the legitimate infrastructure signal.

596
00:47:20,720 --> 00:47:26,600
For instance, by use of directional antennas or just by being closer to it than the regular cell tower is.

597
00:47:27,240 --> 00:47:33,000
And from that perspective, we can start messing with the perception of time of this mobile station.

598
00:47:33,520 --> 00:47:37,520
So, we can set the mobile station time all the way back to time T,

599
00:47:37,680 --> 00:47:40,200
when we originally captured our encrypted message.

600
00:47:40,780 --> 00:47:44,180
Now, we will somehow need to be able to

601
00:47:44,760 --> 00:47:49,060
extract the key stream from the mobile station that we need to decrypt our message.

602
00:47:49,320 --> 00:47:50,460
We'll get into that later.

603
00:47:50,620 --> 00:47:53,760
But if we can do that, then we have one we will be able to decrypt.

604
00:47:56,600 --> 00:47:58,660
Now, for the recovery of key stream,

605
00:47:59,520 --> 00:48:04,340
let's start out with an assumption that we already have some key stream at our disposal.

606
00:48:05,160 --> 00:48:09,560
So, we will construct a message that is of length n plus one.

607
00:48:09,660 --> 00:48:11,780
So, one bit longer than the key stream we have.

608
00:48:13,100 --> 00:48:16,740
Such that it has an FCS, a frame check sequence,

609
00:48:17,080 --> 00:48:19,760
which is a checksum that is embedded in the encrypted part.

610
00:48:20,620 --> 00:48:24,600
And it needs an acknowledgement from the mobile station upon receipt.

611
00:48:26,200 --> 00:48:29,420
We can encrypt this message with the key stream we already have.

612
00:48:29,620 --> 00:48:34,780
And the last bit, which we don't have, we will just guess that the key stream bit there is zero.

613
00:48:35,440 --> 00:48:37,040
We send it to the mobile station.

614
00:48:37,460 --> 00:48:41,080
The mobile station will decrypt the message, check the checksum,

615
00:48:41,080 --> 00:48:43,160
and if everything is good, send an acknowledgement.

616
00:48:44,060 --> 00:48:47,200
If that happens, we know the key stream guess was correct,

617
00:48:47,360 --> 00:48:50,340
and we have now recovered one additional bit of key stream.

618
00:48:50,920 --> 00:48:54,220
If we do not get an acknowledgement, we know our guess was wrong,

619
00:48:54,340 --> 00:48:56,340
and we have still recovered a bit of key stream.

620
00:48:57,180 --> 00:49:01,440
You can repeat this, and each time you will recover an additional bit of key stream,

621
00:49:01,580 --> 00:49:02,820
up to the length you desire.

622
00:49:05,360 --> 00:49:09,120
Now, this assumption of having initial key stream is nice,

623
00:49:09,160 --> 00:49:10,740
but we need more.

624
00:49:11,080 --> 00:49:15,560
We need to have something that actually works in order to generate this initial seed key stream.

625
00:49:16,020 --> 00:49:21,400
And we are going to do that by sending 16 messages to the mobile station.

626
00:49:22,000 --> 00:49:25,540
And the first four bits will all be tried.

627
00:49:25,700 --> 00:49:28,340
And we add the last zero. It doesn't matter what is there.

628
00:49:28,520 --> 00:49:32,480
But we will try 0000 up to 11110.

629
00:49:34,200 --> 00:49:39,320
And given how Tetra works, these four bits encode the message type on the LLC level.

630
00:49:40,020 --> 00:49:43,660
And what's interesting is that for these 16 messages,

631
00:49:43,880 --> 00:49:48,820
there will be exactly one message that will get an acknowledgement from the mobile station.

632
00:49:49,140 --> 00:49:53,460
And this is the BL data without FCS message type.

633
00:49:53,760 --> 00:49:57,120
And all the other messages are either supposed to be way longer,

634
00:49:57,220 --> 00:49:58,820
and thus discarded as being invalid,

635
00:49:59,040 --> 00:50:02,800
or will not require an acknowledgement to be sent in the first place.

636
00:50:03,540 --> 00:50:07,200
So we try these 60 messages, we will get one acknowledgement,

637
00:50:07,200 --> 00:50:13,360
and that means that we will know how the mobile station decrypted this.

638
00:50:13,500 --> 00:50:16,220
So we will know four bits of key stream.

639
00:50:18,220 --> 00:50:19,120
That's pretty cool.

640
00:50:19,600 --> 00:50:23,360
But still we need a bit more, because the shortest message we can use

641
00:50:23,360 --> 00:50:26,460
for the first attack we presented here is 37 bits long.

642
00:50:27,240 --> 00:50:32,760
So what we do is we recover these four bits for 10 consecutive slots.

643
00:50:33,640 --> 00:50:36,860
And we then craft our 37 bits.

644
00:50:37,200 --> 00:50:39,380
So we have this message with the checksum inside of it.

645
00:50:39,820 --> 00:50:44,960
And we use MAC fragmentation, a fragmentation feature Tetra offers,

646
00:50:45,240 --> 00:50:50,940
in order to distribute our message over all of these small slots

647
00:50:50,940 --> 00:50:53,340
where we have only four bits of key stream available.

648
00:50:54,440 --> 00:50:58,760
The radio will then make sure that these things are stitched back together,

649
00:50:58,940 --> 00:51:02,220
will decrypt them, will validate whether the checksum makes sense.

650
00:51:02,420 --> 00:51:04,000
If it makes sense, you get an acknowledgement.

651
00:51:04,600 --> 00:51:05,960
The story we discussed.

652
00:51:07,200 --> 00:51:10,440
This way you can easily choose for which slot you would like

653
00:51:10,440 --> 00:51:11,860
to have an additional bit of key stream,

654
00:51:12,420 --> 00:51:14,780
make a guess on that key stream bit,

655
00:51:14,940 --> 00:51:17,500
and recover an additional bit.

656
00:51:19,760 --> 00:51:22,300
So when we presented this to ETSI,

657
00:51:22,440 --> 00:51:26,100
they said that's an interesting and valid theoretical attack.

658
00:51:26,520 --> 00:51:29,300
But it's quite serious, because it affects all key stream generators.

659
00:51:29,600 --> 00:51:32,380
So we asked them, okay, understandable,

660
00:51:33,040 --> 00:51:35,640
but please provide us with a base station so we can instrument it

661
00:51:35,640 --> 00:51:37,180
and validate whether this attack works.

662
00:51:37,200 --> 00:51:37,900
Is this attack actually practical?

663
00:51:38,800 --> 00:51:40,820
And they said, ah, lol, no.

664
00:51:41,060 --> 00:51:42,560
Maybe the wording was a little different.

665
00:51:43,520 --> 00:51:47,840
We tried more stakeholders, and they all kind of responded like this.

666
00:51:48,000 --> 00:51:51,380
So we had to go about this in another way.

667
00:51:51,680 --> 00:51:53,480
So what options do we have?

668
00:51:53,600 --> 00:51:55,940
We could implement the Tetra infrastructure stack

669
00:51:55,940 --> 00:52:00,300
on a software-defined radio and in that way try to target our radio.

670
00:52:00,620 --> 00:52:02,560
But that sounds like an awful lot of work.

671
00:52:02,600 --> 00:52:04,160
It's very complex, painstaking,

672
00:52:04,380 --> 00:52:06,720
and not what we're here for, right?

673
00:52:07,480 --> 00:52:10,480
So what we did is get our own base station.

674
00:52:11,480 --> 00:52:13,140
Meet the Motorola MBTS.

675
00:52:13,700 --> 00:52:15,320
It's old, it's heavy.

676
00:52:15,460 --> 00:52:17,180
I believe it's 75 kilos or something.

677
00:52:17,840 --> 00:52:19,600
It was a clear text base station,

678
00:52:19,700 --> 00:52:20,840
so it doesn't support encryption,

679
00:52:21,520 --> 00:52:22,800
and it's cool as fuck.

680
00:52:23,040 --> 00:52:26,580
And we decided to transform this thing into an attack platform.

681
00:52:28,260 --> 00:52:30,140
So a short overview of the MBTS.

682
00:52:30,400 --> 00:52:31,860
It has two main components.

683
00:52:32,060 --> 00:52:35,200
It has a side controller, which does all the high-level stuff,

684
00:52:35,940 --> 00:52:36,700
and it also has a controller.

685
00:52:36,720 --> 00:52:38,640
It also holds the firmwares for both itself

686
00:52:39,320 --> 00:52:40,840
and for the base radio modules.

687
00:52:41,520 --> 00:52:43,140
And these base radio modules,

688
00:52:43,240 --> 00:52:44,700
you can have one or multiple of them,

689
00:52:44,880 --> 00:52:46,880
they are actually connected to the antenna.

690
00:52:47,180 --> 00:52:49,140
They perform modulation and demodulation,

691
00:52:49,420 --> 00:52:50,800
but they also perform the encryption.

692
00:52:52,440 --> 00:52:56,060
Both of these components are running on PSOS Plus

693
00:52:56,060 --> 00:53:00,360
real-time operating system and based on PowerPC CPUs.

694
00:53:01,360 --> 00:53:04,660
Also, they both have management consoles over a serial port,

695
00:53:04,800 --> 00:53:06,480
so you can connect to the serial port.

696
00:53:06,720 --> 00:53:07,700
You can also enter some passwords,

697
00:53:07,880 --> 00:53:11,420
and then you're allowed to enter commands for diagnostics

698
00:53:11,420 --> 00:53:12,700
and for debugging purposes.

699
00:53:14,420 --> 00:53:17,260
Interestingly, both of these things use unsigned firmwares.

700
00:53:19,400 --> 00:53:21,520
So let's go do some base station hacking.

701
00:53:23,300 --> 00:53:26,840
We modified the firmwares in order to allow

702
00:53:26,840 --> 00:53:28,700
for the implementation of a proof of concept.

703
00:53:28,900 --> 00:53:31,720
And the first thing we did was implement a Tinker command,

704
00:53:31,960 --> 00:53:34,340
which can be invoked from the command line.

705
00:53:34,740 --> 00:53:36,400
And our Tinker command allows

706
00:53:36,720 --> 00:53:37,800
for raw memory access.

707
00:53:38,020 --> 00:53:40,540
So you can just enter a command, read memory,

708
00:53:40,760 --> 00:53:42,980
or with another command, write to memory.

709
00:53:43,480 --> 00:53:45,640
You can also execute memory by just jumping

710
00:53:45,640 --> 00:53:47,960
to a random memory address as specified.

711
00:53:48,240 --> 00:53:50,400
And we also added malloc and free primitive

712
00:53:50,400 --> 00:53:52,800
so that you can allocate blocks of memory

713
00:53:52,800 --> 00:53:54,540
for use for other stuff.

714
00:53:55,320 --> 00:53:57,120
Also, we added TEA support.

715
00:53:58,160 --> 00:54:00,400
We used our own reference implementation for that.

716
00:54:00,900 --> 00:54:04,120
And what was very helpful is that this firmware

717
00:54:04,120 --> 00:54:06,540
already supported almost the entire

718
00:54:07,360 --> 00:54:09,860
suite of cryptography that's required for Tetra,

719
00:54:09,960 --> 00:54:11,840
but it just had an empty stop function

720
00:54:11,840 --> 00:54:13,020
for the key stream generator.

721
00:54:13,300 --> 00:54:14,680
So we replaced that.

722
00:54:14,760 --> 00:54:16,640
We did some more small changes,

723
00:54:16,680 --> 00:54:20,380
and we had a functional encrypting base station

724
00:54:20,380 --> 00:54:21,040
on our hands.

725
00:54:21,900 --> 00:54:25,180
We wrote a framework that allows for the loading

726
00:54:25,180 --> 00:54:28,240
of modules into the memory of the base station

727
00:54:28,240 --> 00:54:31,000
and for the placement of hooks on functions

728
00:54:31,000 --> 00:54:32,900
where we were either interested in debugging

729
00:54:32,900 --> 00:54:34,600
or changing the behavior.

730
00:54:35,320 --> 00:54:35,840
So...

731
00:54:36,820 --> 00:54:38,680
Making implants for this base station

732
00:54:38,680 --> 00:54:40,320
was kind of straightforward, actually.

733
00:54:42,440 --> 00:54:43,040
Right.

734
00:54:43,260 --> 00:54:46,580
So we then decided to continue

735
00:54:46,580 --> 00:54:48,780
and start working on our proof of concept,

736
00:54:48,960 --> 00:54:52,560
for which we dedicated the .ksreuse command,

737
00:54:53,360 --> 00:54:55,500
which allows the base station

738
00:54:55,500 --> 00:54:57,880
to suddenly change the network time

739
00:54:58,520 --> 00:55:01,160
as required in order to be able to mount the attack.

740
00:55:01,700 --> 00:55:04,540
And also it implements the recovery mechanisms

741
00:55:04,540 --> 00:55:06,480
that I've just explained to you guys.

742
00:55:07,460 --> 00:55:10,080
Once we started messing with the network time,

743
00:55:10,200 --> 00:55:12,820
we saw that our radio rebooted,

744
00:55:12,920 --> 00:55:14,740
our mobile radio rebooted,

745
00:55:14,820 --> 00:55:16,900
and we found that it was due to some

746
00:55:16,900 --> 00:55:18,420
synchronization issues in Tetra.

747
00:55:18,620 --> 00:55:21,140
Certain messages are expected at certain times,

748
00:55:21,220 --> 00:55:22,520
and if you mess with the timing,

749
00:55:22,640 --> 00:55:24,400
then it will start misinterpreting stuff.

750
00:55:25,020 --> 00:55:26,300
This can be resolved.

751
00:55:26,440 --> 00:55:28,560
We resolved it by making sure our time change

752
00:55:28,560 --> 00:55:30,480
is aligned to four multi-frames.

753
00:55:30,740 --> 00:55:32,080
It can be done neater.

754
00:55:32,180 --> 00:55:33,360
We'll get you a performance improvement,

755
00:55:33,660 --> 00:55:36,020
but that's way beyond what a proof of concept should be.

756
00:55:36,720 --> 00:55:37,560
So with some more tinkering,

757
00:55:37,700 --> 00:55:40,860
our MTM radio gladly accepts any jump in network time,

758
00:55:41,000 --> 00:55:42,040
and we can start attacking.

759
00:55:43,500 --> 00:55:45,920
One last thing on the base station.

760
00:55:46,180 --> 00:55:47,540
We found several vulnerabilities.

761
00:55:48,000 --> 00:55:50,660
For instance, the unauthenticated firmwares,

762
00:55:50,720 --> 00:55:52,780
which is quite an issue

763
00:55:52,780 --> 00:55:54,060
for mission-critical communications.

764
00:55:54,660 --> 00:55:57,720
An attacker could implant such a thing

765
00:55:57,720 --> 00:56:00,580
and gain permanent access to a base station,

766
00:56:00,800 --> 00:56:03,420
or he can just exfiltrate keys and be on his way.

767
00:56:05,060 --> 00:56:06,500
Also the firmwares,

768
00:56:06,720 --> 00:56:08,380
of both the site controller and the base radio,

769
00:56:08,620 --> 00:56:11,980
have hard-coded, undocumented backdoor passwords.

770
00:56:12,280 --> 00:56:14,920
These passwords give you an authentication level

771
00:56:14,920 --> 00:56:16,460
on the command line that's even higher

772
00:56:16,460 --> 00:56:18,700
than the system's owner would normally have.

773
00:56:19,600 --> 00:56:22,960
Lastly, if you can crash the site controller

774
00:56:23,440 --> 00:56:25,060
by some kind of unhandled exception,

775
00:56:25,480 --> 00:56:27,440
it will drop to a debug shell

776
00:56:27,440 --> 00:56:30,920
that allows you direct code execution and memory access,

777
00:56:31,460 --> 00:56:34,100
once again allowing for key exfiltration.

778
00:56:35,960 --> 00:56:38,240
So, we have looked at multiple radios,

779
00:56:38,680 --> 00:56:40,120
multiple base stations,

780
00:56:40,180 --> 00:56:41,600
and mobile stations at this point,

781
00:56:41,740 --> 00:56:44,620
and there seems to be some kind of industry-wide issue here.

782
00:56:45,080 --> 00:56:47,340
The software stacks that are being used

783
00:56:47,340 --> 00:56:49,060
are really not up to standards,

784
00:56:49,260 --> 00:56:51,540
and we start wondering

785
00:56:51,540 --> 00:56:52,800
whether anyone is actually

786
00:56:52,800 --> 00:56:55,960
pentesting these things in any condition.

787
00:56:57,520 --> 00:56:58,500
In any case,

788
00:56:58,520 --> 00:56:59,820
here is a demonstration video

789
00:56:59,820 --> 00:57:01,360
for the key stream recovery attack.

790
00:57:07,120 --> 00:57:08,940
Hi, we are Midnight Blue.

791
00:57:09,160 --> 00:57:11,180
We have uncovered several serious vulnerabilities

792
00:57:11,180 --> 00:57:12,780
in the Tetra radio standard,

793
00:57:13,060 --> 00:57:14,100
dubbed Tetra Burst.

794
00:57:14,340 --> 00:57:17,160
We will first demonstrate a decryption oracle attack

795
00:57:17,160 --> 00:57:18,640
to recover a text message.

796
00:57:18,920 --> 00:57:20,780
But the attack can also be applied

797
00:57:20,780 --> 00:57:22,580
to voice communication and data.

798
00:57:22,940 --> 00:57:25,600
The demonstration takes place on our lab setup.

799
00:57:27,220 --> 00:57:29,460
The radio receives an encrypted message,

800
00:57:29,680 --> 00:57:31,540
which is also captured by the attacker.

801
00:57:36,940 --> 00:57:39,100
We see the message says secret.

802
00:57:41,700 --> 00:57:44,200
The attacker now needs to target the radio

803
00:57:44,200 --> 00:57:45,660
and impersonate the infrastructure

804
00:57:45,660 --> 00:57:47,260
and carry out the attack

805
00:57:47,260 --> 00:57:49,220
to decrypt the previously captured message.

806
00:57:52,460 --> 00:57:54,160
We have sped up this process.

807
00:58:04,560 --> 00:58:08,140
The attacker has now recovered all he needs to decrypt the message.

808
00:58:08,540 --> 00:58:13,480
This attack applies to all Tetra configurations, but can be resolved with a firmware update.

809
00:58:13,960 --> 00:58:17,140
Further details will be disclosed on August 9th.

810
00:58:27,400 --> 00:58:29,520
So, this is pretty concrete, right?

811
00:58:30,180 --> 00:58:32,180
So, what would Etsy say about this?

812
00:58:32,180 --> 00:58:41,260
We presented our proof-of-concept status, and now, in their public response on the vulnerabilities we uncovered,

813
00:58:41,580 --> 00:58:50,780
all they have to say on this key-stream recovery issue is that our research uncovered some general areas for improvement in the Tetra protocol.

814
00:58:53,740 --> 00:58:57,260
Lastly, I would like to draw your attention to TEA3.

815
00:58:57,640 --> 00:59:01,100
We have analyzed it, and we have not found it vulnerable,

816
00:59:01,200 --> 00:59:02,100
but there is something there.

817
00:59:02,180 --> 00:59:03,100
There is something very weird going on.

818
00:59:03,500 --> 00:59:11,780
Now, in the other TEAS, there is also an S-box, but these S-boxes look normal, like an S-box should look.

819
00:59:11,980 --> 00:59:17,320
And in TEA3, the S-box is not a permutation, so there is one entry that is there twice.

820
00:59:17,620 --> 00:59:25,960
And this is highly, highly irregular, and probably, certainly not a positive thing for the security of this algorithm.

821
00:59:27,940 --> 00:59:30,040
It might be a mistake, right?

822
00:59:30,040 --> 00:59:32,460
Just some random bit-flip that occurred somewhere.

823
00:59:32,940 --> 00:59:36,000
Well, at least it has to be a mistake when the standard was drafted,

824
00:59:36,140 --> 00:59:40,980
because if not, our radio would not be compatible with other radios in the field.

825
00:59:41,860 --> 00:59:48,080
And what makes it extra suspicious is the fact that there is another small structural change

826
00:59:48,080 --> 00:59:52,420
to the feedback mechanism of the key register that hides the issue.

827
00:59:52,820 --> 00:59:56,300
Usually, you get state merges, and in this case, you don't.

828
00:59:56,420 --> 01:00:00,020
So, there is another small difference from TEA3.

829
01:00:00,020 --> 01:00:02,460
And in TEA1 and TEA2, that is here.

830
01:00:02,600 --> 01:00:06,200
That kind of masks that there is something weird going on.

831
01:00:06,700 --> 01:00:13,720
So, at this point, the impact is unclear, but we're really asking anyone who knows his way around these kinds of things

832
01:00:13,720 --> 01:00:16,460
to take a good look at it and publish their findings.

833
01:00:18,400 --> 01:00:21,880
Right, so let's discuss the coordinated vulnerability disclosure process.

834
01:00:22,420 --> 01:00:25,440
We started working on this project in January 2021,

835
01:00:26,220 --> 01:00:30,000
and it took us four months to get the secret cryptography out of the radar.

836
01:00:30,900 --> 01:00:35,780
The rest of the year, we spent on an analysis of the ciphers,

837
01:00:35,860 --> 01:00:39,160
on analysis of the protocol, and on building some proof of concepts.

838
01:00:39,760 --> 01:00:43,900
At the end of 2021, in December, we contacted the Dutch NCSC,

839
01:00:44,140 --> 01:00:46,980
which then started enumerating stakeholders.

840
01:00:47,640 --> 01:00:51,520
And in January 2022, we got our first meetings with the Dutch police,

841
01:00:51,780 --> 01:00:55,360
with ETSI, the standardization body, and with the intelligence community.

842
01:00:56,380 --> 01:00:59,380
In February, we distributed a preliminary advisory,

843
01:00:59,380 --> 01:01:03,080
that was to be distributed among stakeholders.

844
01:01:04,160 --> 01:01:08,100
The remainder of that year, we were in touch with various stakeholders,

845
01:01:08,240 --> 01:01:11,000
like manufacturers, network operators, etc. users,

846
01:01:11,300 --> 01:01:15,160
in order to do our best into helping them understand the vulnerabilities

847
01:01:15,160 --> 01:01:17,780
and understand mitigations that they could take.

848
01:01:20,900 --> 01:01:22,900
Now, let's talk mitigations.

849
01:01:23,220 --> 01:01:26,640
The key stream recovery attack can be resolved in firmware,

850
01:01:26,640 --> 01:01:32,900
because the radio can be told not to trust these weird changes in network time.

851
01:01:33,340 --> 01:01:36,780
It's important, however, that these patches are properly validated,

852
01:01:36,860 --> 01:01:40,400
because it's a tricky thing to tackle, and it's easy to get it wrong.

853
01:01:41,400 --> 01:01:45,320
Alternatively, end-to-end encryption can be used to have a secondary layer of encryption

854
01:01:45,320 --> 01:01:47,220
on top of the air interface encryption.

855
01:01:47,800 --> 01:01:51,160
And if you're using a tetraradio in a data-carrying capacity,

856
01:01:51,220 --> 01:01:56,000
you can also consider TLS or IPSec to add additional encryption.

857
01:01:57,080 --> 01:02:02,200
The TAA1 backdoor obviously cannot be resolved with a firmware patch,

858
01:02:02,480 --> 01:02:04,620
because it's an essential part of the standard.

859
01:02:04,900 --> 01:02:09,020
So we would recommend TAA1 users to migrate to TAA2,

860
01:02:09,640 --> 01:02:15,480
or alternatively, if that's not possible, use end-to-end encryption or TAA3.

861
01:02:16,860 --> 01:02:20,540
The de-anonymization attack also cannot be resolved with a firmware update.

862
01:02:21,080 --> 01:02:24,840
These users will have to migrate to TAA2,

863
01:02:24,980 --> 01:02:26,620
which is a new version of TAA2,

864
01:02:26,640 --> 01:02:30,720
a version of the standard that ETSI has drafted and has been published last year.

865
01:02:31,740 --> 01:02:37,340
This implements a new encryption mechanism for identities that should be better.

866
01:02:39,020 --> 01:02:42,300
Lastly, we have the DCK pinning attack, the session key pinning attack.

867
01:02:42,560 --> 01:02:44,620
This can also be resolved with a firmware update.

868
01:02:49,860 --> 01:02:51,260
Alright, thanks for that.

869
01:02:51,540 --> 01:02:54,360
So in the aftermath of disclosing these issues,

870
01:02:54,620 --> 01:02:56,440
there was some interesting discussion

871
01:02:56,640 --> 01:02:58,420
with ETSI, which we'd like to highlight.

872
01:02:59,960 --> 01:03:03,620
So in Kim Zetter's interview with the ETSI Tetra chairman,

873
01:03:03,860 --> 01:03:05,840
he says a couple of interesting things.

874
01:03:05,960 --> 01:03:10,160
First of all, he says, well, TAA1, is it such a big deal, this backdoor,

875
01:03:10,260 --> 01:03:15,540
because, you know, anyone in Europe who would need high security would be using TAA2.

876
01:03:15,920 --> 01:03:17,940
Well, I mean, this is not true.

877
01:03:18,060 --> 01:03:21,240
We looked through various tenders and procurement documents,

878
01:03:21,540 --> 01:03:26,440
and they show that TAA1 equipment was procured by various countries,

879
01:03:26,440 --> 01:03:29,540
for police and military use, in the last five years.

880
01:03:29,740 --> 01:03:34,520
And these are countries like Poland, Bulgaria, Croatia, Montenegro, Moldova,

881
01:03:34,680 --> 01:03:38,780
all of which are either EU countries or candidate EU countries.

882
01:03:39,160 --> 01:03:43,500
And some of these have been allowed to use TAA2, according to ETSI's own standards,

883
01:03:43,620 --> 01:03:45,760
as far back as 2003 or 2008.

884
01:03:46,400 --> 01:03:51,100
Regardless, in the last five years, they were supplied with this backdoor algorithm within Europe.

885
01:03:51,200 --> 01:03:55,780
So what happened here, we don't know, but it's not just limited to the outside of Europe.

886
01:03:57,400 --> 01:04:00,560
Secondly, when it comes to the use of TAA1 in critical infrastructure,

887
01:04:01,220 --> 01:04:04,080
the chairman says, well, if you're using TAA1,

888
01:04:04,320 --> 01:04:07,920
well, we know that certainly a government actor could have a go at them in a short order,

889
01:04:08,000 --> 01:04:09,580
because that's what the researchers have proved.

890
01:04:09,760 --> 01:04:11,900
But he says, you know, you might be able to migrate away,

891
01:04:12,000 --> 01:04:16,020
or, you know, are high-value targets actually using this?

892
01:04:16,380 --> 01:04:20,320
Well, the problem in critical infrastructure is that you don't have a lot of choice.

893
01:04:20,500 --> 01:04:23,180
You can get TAA1 or TAA3.

894
01:04:23,360 --> 01:04:26,180
You're limited to TAA1 due to the export controls.

895
01:04:26,440 --> 01:04:30,980
In many cases, there are no Tetra end-to-end solutions for the RTUs,

896
01:04:31,080 --> 01:04:33,620
the remote terminal units that you use in critical infrastructure.

897
01:04:34,060 --> 01:04:37,240
And some of the compensated controls that you might want to take,

898
01:04:37,300 --> 01:04:42,320
such as TLS or IPSec on top of Tetra, might not be supported by these RTUs either.

899
01:04:42,960 --> 01:04:46,860
And even if you could migrate away to TAA2 or TAA3,

900
01:04:47,060 --> 01:04:49,560
sometimes this is just not possible in field.

901
01:04:49,680 --> 01:04:53,920
As you can see on the snippet from the manual from one of the popular Tetra RTUs,

902
01:04:54,060 --> 01:04:55,600
you pick an algorithm,

903
01:04:55,600 --> 01:04:56,740
and then you stick with it.

904
01:04:56,780 --> 01:04:58,280
You can't update it in the field.

905
01:04:58,360 --> 01:05:01,160
So now you're stuck with this 32 bits of security.

906
01:05:02,260 --> 01:05:05,520
But maybe all of the stuff we've covered, you know, maybe it doesn't matter.

907
01:05:05,600 --> 01:05:09,380
Maybe it's a big nothing burger because nobody actually targets Tetra networks.

908
01:05:09,660 --> 01:05:12,160
And actually, in ETSI's official statement, they say,

909
01:05:12,260 --> 01:05:18,420
ETSI and TCCA are not at this time aware of any exploitations on operational networks.

910
01:05:18,780 --> 01:05:21,820
Well, that's interesting because two out of five attacks are passive,

911
01:05:21,880 --> 01:05:23,100
so how are you going to notice that?

912
01:05:23,760 --> 01:05:25,320
And it's also not true,

913
01:05:25,600 --> 01:05:27,140
because we looked through the Snowden documents,

914
01:05:27,440 --> 01:05:32,080
and we found that a joint NSA and Australian Signals Directorate project

915
01:05:32,080 --> 01:05:38,500
was undertaken in 2007 against the United Nations Climate Change Conference in Bali,

916
01:05:38,800 --> 01:05:41,800
where they targeted the networks of the Indonesian police,

917
01:05:42,020 --> 01:05:45,320
and they collected Tetra communications describing demonstration routes,

918
01:05:45,500 --> 01:05:49,180
as well as the Bali chief of police's private mobile phone number.

919
01:05:49,360 --> 01:05:51,300
Now, they don't go into the technical details,

920
01:05:51,500 --> 01:05:54,400
so this is not proof of our vulnerabilities being exploited.

921
01:05:54,400 --> 01:05:55,880
It might be, it might not be,

922
01:05:55,960 --> 01:06:00,180
but it does show that Tetra networks are being actively targeted.

923
01:06:01,230 --> 01:06:04,460
We also found a second reference in the Snowden documents,

924
01:06:04,740 --> 01:06:10,420
where GCHQ mentions that in 2009 they undertook what they call an effects operation

925
01:06:10,420 --> 01:06:13,460
called Operation Quito against Argentina

926
01:06:13,460 --> 01:06:16,980
around a conflict regarding oil exploration rights tensions

927
01:06:16,980 --> 01:06:20,100
regarding the Falklands or Malvinas Isles.

928
01:06:20,220 --> 01:06:24,260
And here they mentioned they were collecting high priority military and leadership

929
01:06:24,400 --> 01:06:27,520
communications, and that involved a number of Tetra collects.

930
01:06:27,820 --> 01:06:31,040
So this shows, again, you know, Tetra networks are being targeted.

931
01:06:31,960 --> 01:06:33,340
So, what's next?

932
01:06:33,660 --> 01:06:36,520
Well, ETSI announced an update to the standard.

933
01:06:36,680 --> 01:06:40,360
They're going to replace the TAA1 authentication suite with TAA2.

934
01:06:40,520 --> 01:06:45,440
They're going to update the TAA123 algorithms with 5 to 7.

935
01:06:45,940 --> 01:06:48,620
They have some mitigations around the key stream recovery attack,

936
01:06:48,820 --> 01:06:51,640
and they're going to keep the new algorithms all secret again.

937
01:06:52,000 --> 01:06:54,260
So, in the interview with the chairman,

938
01:06:54,400 --> 01:06:56,280
the journalist asked, you know,

939
01:06:56,360 --> 01:06:59,560
if you're saying the only reason these algorithms are secret

940
01:06:59,560 --> 01:07:01,220
is because the government has advised it,

941
01:07:01,300 --> 01:07:04,580
can ETSI actually decide to make them public on their own?

942
01:07:04,740 --> 01:07:06,840
And then they say, yes, we can make that decision.

943
01:07:07,040 --> 01:07:09,340
And then the journalist asks, so why don't you?

944
01:07:09,400 --> 01:07:11,080
And the only answer is, well, I don't know.

945
01:07:12,140 --> 01:07:14,840
So, should we trust TAA6 and 7,

946
01:07:15,060 --> 01:07:17,800
especially because these will be the new export-controlled ones?

947
01:07:17,900 --> 01:07:18,740
What do you think?

948
01:07:20,040 --> 01:07:20,480
No.

949
01:07:20,640 --> 01:07:23,060
Well, let's just ask ETSI themselves first.

950
01:07:23,060 --> 01:07:27,640
So, the journalist says, should we trust ETSI algorithms going forward?

951
01:07:27,900 --> 01:07:29,620
And then the chairman says, well,

952
01:07:29,780 --> 01:07:32,660
we have no reason to produce dodgy algorithms, if you like,

953
01:07:32,800 --> 01:07:34,480
you know, except for the ones that they did.

954
01:07:34,700 --> 01:07:36,900
And then he goes further and he says,

955
01:07:37,000 --> 01:07:39,160
well, these algorithms were just handed to us

956
01:07:39,160 --> 01:07:42,080
and they were designed with some assistance from some government authorities.

957
01:07:42,500 --> 01:07:43,800
Let me put it that way.

958
01:07:44,000 --> 01:07:46,660
And a little bit later he says, well, at the end of the day,

959
01:07:46,740 --> 01:07:50,580
it's down to customer organizations to ensure that things are secure enough for them.

960
01:07:50,580 --> 01:07:52,980
I agree it's difficult with a private algorithm,

961
01:07:53,240 --> 01:07:55,660
but the reason we have three different algorithms available

962
01:07:55,660 --> 01:07:59,640
must be clear to someone that they're not all as secure as each other.

963
01:07:59,800 --> 01:08:02,720
So, you're going to get three new different algorithms that are going to be private,

964
01:08:02,880 --> 01:08:05,220
so make up your own mind about those ones.

965
01:08:06,160 --> 01:08:10,360
In conclusion, this has been the first public in-depth Tetra security analysis

966
01:08:10,360 --> 01:08:11,800
in more than 20 years.

967
01:08:12,260 --> 01:08:15,980
It affects more than 100 countries, many different sectors that are critical.

968
01:08:16,360 --> 01:08:19,440
We reverse engineered the secret cryptography algorithms

969
01:08:19,440 --> 01:08:22,040
published on GitHub, so you can go take a look.

970
01:08:22,380 --> 01:08:25,940
Multiple vulnerabilities were uncovered, both in the standard as well as equipment,

971
01:08:26,400 --> 01:08:28,160
including a backdoor in TEA 1.

972
01:08:28,420 --> 01:08:31,760
This has implications for voice and data communications,

973
01:08:31,940 --> 01:08:34,140
as well as SCADA telecontrol communications.

974
01:08:35,020 --> 01:08:39,120
Patches are available for some of the issues, while mitigations will be required for others.

975
01:08:39,700 --> 01:08:42,640
And I'd like to finish this talk off with a call to action,

976
01:08:42,820 --> 01:08:45,180
because there's much more work to be done on Tetra.

977
01:08:45,440 --> 01:08:49,100
First of all, people need to take a closer look at the TEA algorithms,

978
01:08:49,100 --> 01:08:51,940
especially that very fishy S-box in TEA 3.

979
01:08:52,100 --> 01:08:54,260
See if you can get, you know, a handle on that one.

980
01:08:54,740 --> 01:08:59,820
Also, take a closer look at Hurdle, the block cipher that forms the core of the authentication suite,

981
01:09:00,000 --> 01:09:03,280
because an attack on Hurdle could be catastrophic for Tetra security

982
01:09:03,280 --> 01:09:05,580
due to our attack on TEA 61,

983
01:09:05,920 --> 01:09:09,160
which gives you a little bit of a foothold to play around with that cipher.

984
01:09:09,760 --> 01:09:12,320
Secondly, if you're more of a developer,

985
01:09:12,540 --> 01:09:16,460
we recommend to implement and extend the open Tetra stacks that are there.

986
01:09:16,640 --> 01:09:19,080
The people at Osmocom have done some great work,

987
01:09:19,100 --> 01:09:22,860
and you can go talk to the Osmocom people as well as the NLNet Foundation,

988
01:09:23,160 --> 01:09:26,820
who will happily help you around, extend these open implementations.

989
01:09:27,120 --> 01:09:30,260
And finally, stop doing secret cryptography, please.

990
01:09:30,460 --> 01:09:34,520
It's a bad idea, it always ends in tears, and it's just not polite.

991
01:09:34,660 --> 01:09:35,740
Stop doing that stuff.

992
01:09:37,000 --> 01:09:41,760
Finally, if you want to read more, white papers will be forthcoming on tetraburst.com.

993
01:09:41,940 --> 01:09:45,180
An overview of all the vulnerabilities in the radios and the base stations

994
01:09:45,180 --> 01:09:47,980
are on midnightblue.nl slash retetra.

995
01:09:49,100 --> 01:09:50,580
The algorithms are on GitHub.

996
01:09:50,780 --> 01:09:53,680
If you want to ask questions to us that you don't want to ask in public,

997
01:09:53,840 --> 01:09:57,300
you can always send us an email on one of the addresses below.

998
01:09:57,800 --> 01:10:00,440
And if you do have questions that you want to ask in public,

999
01:10:00,520 --> 01:10:02,320
I'd like to open the floor for that right now.

1000
01:10:02,460 --> 01:10:03,280
And that's that.