1
00:00:00,000 --> 00:00:19,259
<i>35C3 preroll music</i>

2
00:00:19,259 --> 00:00:24,429
Herald angel: Welcome everybody to our
next Talk. It's the talk “Wallet.fail”.

3
00:00:24,429 --> 00:00:28,380
As you all know, when you have something
valuable you put it somewhere safe. But as

4
00:00:28,380 --> 00:00:33,710
we as hackers also know there is no place
that is really safe and our three speakers

5
00:00:33,710 --> 00:00:39,059
Thomas, Dmitry and Josh are now going to
demonstrate in the next hour the art of

6
00:00:39,059 --> 00:00:43,590
completely breaking something apart. So
please give a big round of applause for

7
00:00:43,590 --> 00:00:47,970
Thomas, Dmitry and Josh and have a lot of
fun.

8
00:00:47,970 --> 00:00:51,790
<i>Applause</i>

9
00:00:51,790 --> 00:00:55,359
Dmitry: So just just to start, I'm
curious how many people here actually own

10
00:00:55,359 --> 00:01:02,300
cryptocurrency. Raise your hand. And how
many of you store it on a hardware wallet?

11
00:01:02,300 --> 00:01:09,420
So we're very sorry to everyone who has
their hand up. OK. So it's not just me.

12
00:01:09,420 --> 00:01:15,390
It's me, Josh and Thomas. So we're all
hardware people. We do low level hardware

13
00:01:15,390 --> 00:01:21,200
stuff in varying degrees and we got into
cryptocurrency and so I can recommend to

14
00:01:21,200 --> 00:01:25,369
everyone sitting in this room if you're a
security person. There's not a lot of

15
00:01:25,369 --> 00:01:31,340
people doing security and cryptocurrency
as much as that's painful to hear. So yeah

16
00:01:31,340 --> 00:01:36,110
I mean a lot of this is based on reverse
engineering. We love cryptocurrency.

17
00:01:36,110 --> 00:01:40,660
I mean for us crypto also stands for
cryptography not just crypto currency, but

18
00:01:40,660 --> 00:01:45,729
no offense to anyone with this talk. It's
just something that it's a category that

19
00:01:45,729 --> 00:01:49,869
we looked at. And so the results kind of
speak for themselves. And again this

20
00:01:49,869 --> 00:01:53,700
wouldn't be possible alone. So we have a
lot of people to thank. I'm not going to

21
00:01:53,700 --> 00:01:57,840
go through all of them individually. Just
be knowing that we're thankful to everyone

22
00:01:57,840 --> 00:02:03,800
on this, on the slide. So yes, so we
started this about six months ago. So we

23
00:02:03,800 --> 00:02:07,289
wanted to take a look at cryptocurrency
because we own some cryptocurrency

24
00:02:07,289 --> 00:02:12,890
ourselves and we saw that everyone's using
cryptocurrency wallets. It's more and more

25
00:02:12,890 --> 00:02:18,709
the thing that you do. So we started a
group chat as you do nowadays. And we have

26
00:02:18,709 --> 00:02:26,349
50000 messages now and 1100 images. And I
had my first, I had my son in the meantime

27
00:02:26,349 --> 00:02:30,820
as well. So it's a really long time that
we been looking at this, etc.

28
00:02:30,820 --> 00:02:33,170
<i>Applause</i>

29
00:02:33,170 --> 00:02:37,480
OK, so what do we want to achieve
though? Because people don't give

30
00:02:37,480 --> 00:02:40,780
the kinds of attacks so you can
actually perform against

31
00:02:40,780 --> 00:02:44,349
cryptocurrency wallets enough credit.
So first attack is supply chain attacks

32
00:02:44,349 --> 00:02:47,910
where you are able to manipulate the 
devices before they get

33
00:02:47,910 --> 00:02:51,409
to the end customer.
Firmware vulnerabilities, where you find a

34
00:02:51,409 --> 00:02:55,169
vulnerability in the firmware and can
somehow either infect or do something else

35
00:02:55,169 --> 00:02:58,879
with the device. Side-channel attacks of
course. I think that's one of the more

36
00:02:58,879 --> 00:03:02,660
obvious ones that people are familiar
with. And also chip-level vulnerabilities.

37
00:03:02,660 --> 00:03:06,380
So we were able to find one of each of
these. And so that's the talk that we're

38
00:03:06,380 --> 00:03:10,750
going to talk about each one of these
individually. But first, what's a wallet?

39
00:03:10,750 --> 00:03:15,159
Just in case you are not 100 percent
familiar with them. So a wallet, and in

40
00:03:15,159 --> 00:03:19,460
general cryptocurrency how do you do this,
it's just asymmetric cryptography. So you

41
00:03:19,460 --> 00:03:24,270
have a private key and a public key. The
public key, basically, it gives you the

42
00:03:24,270 --> 00:03:28,939
address. You can derive the address from
this. The address is nothing other than

43
00:03:28,939 --> 00:03:33,020
the public key of the wallet and you have
the private key and you need this to send

44
00:03:33,020 --> 00:03:37,659
transactions, so to actually operate with
the cryptocurrency. So this, the private

45
00:03:37,659 --> 00:03:41,626
key, is what needs to be kept secret. The
public key is something that everyone can

46
00:03:41,626 --> 00:03:45,830
know so that they can send cryptocurrency
to you. But it kind of sucks to have a

47
00:03:45,830 --> 00:03:50,189
separate for each cryptocurrency-pair or
for each wallet maybe even multiple

48
00:03:50,189 --> 00:03:55,829
wallets. It sucks to generate a new
cryptographic pair for each one of them.

49
00:03:55,829 --> 00:04:00,390
So the people, the wonderful people,
behind bitcoin have thought of something

50
00:04:00,390 --> 00:04:06,830
for this and it's called BIP32/BIP44. And,
so, what it is is you have a cryptographic

51
00:04:06,830 --> 00:04:13,810
seed and you can actually derive the
accounts from a single seed. So you

52
00:04:13,810 --> 00:04:18,160
basically store one seed and you're able
to implement and do unlimited amount of

53
00:04:18,160 --> 00:04:23,480
wallets. Okay. So basically you do key
derivation, you add some data, do key

54
00:04:23,480 --> 00:04:27,329
derivation and you can have an unlimited
amount of wallets while storing a single

55
00:04:27,329 --> 00:04:31,290
seed. And this is what you're using when
you're using a hardware wallet. So and of

56
00:04:31,290 --> 00:04:35,235
course for each key derivation there will
be a new private key and a public key, but

57
00:04:35,235 --> 00:04:38,759
it will be generated in a predictable
manner and you only need a store one

58
00:04:38,759 --> 00:04:42,630
secret seed. So you only have to store the
seed. You can write it down, and that's

59
00:04:42,630 --> 00:04:46,730
the advantage. But it's difficult to write
down because it's binary data. So come

60
00:04:46,730 --> 00:04:52,160
BIP39, which is what you're most used to,
which is a format in which you can take

61
00:04:52,160 --> 00:04:55,880
that cryptographic seed, that binary data,
and actually convert it to a set of

62
00:04:55,880 --> 00:05:00,020
dictionary words that you can then easily
write down on a piece of paper and store

63
00:05:00,020 --> 00:05:03,889
it at your mother's house, or store half
of it at your mother's house and half of

64
00:05:03,889 --> 00:05:07,710
it at your grandmother's house. And that
way somebody would have to go into both

65
00:05:07,710 --> 00:05:13,820
houses simultaneously to get your words.
So yeah. So what's a hardware wallet?

66
00:05:13,820 --> 00:05:17,800
So we just talked about what's a wallet.
So why do you even need a hardware wallet?

67
00:05:17,800 --> 00:05:22,370
Well, the problem is, of course, computers
can get backdoored, have malware running

68
00:05:22,370 --> 00:05:26,380
on them and this is what you want to pre-
vent against. How do you do this? You have

69
00:05:26,380 --> 00:05:30,139
a secure device, you store your seeds
externally. Usually, this is a USB-

70
00:05:30,139 --> 00:05:35,180
connected device that you store your
crypto on and so you can trust this even

71
00:05:35,180 --> 00:05:39,099
if you can't trust your computer. This is
the idea. So what happens is the computer

72
00:05:39,099 --> 00:05:42,940
sends the transaction to the device. The
device gets the transaction, it can

73
00:05:42,940 --> 00:05:46,660
actually confirm or deny the transaction.
It also displays the transaction. So

74
00:05:46,660 --> 00:05:50,430
before you do any cryptographic signing,
you can see is that actually what I was

75
00:05:50,430 --> 00:05:55,370
doing or was my computer owned and is it
initiating the transaction for me? So you

76
00:05:55,370 --> 00:06:00,410
sign the transaction and also, yeah, the
seed never leaves the transaction, but the

77
00:06:00,410 --> 00:06:04,160
hardware signs a transaction for you. You
send it back to the computer and the

78
00:06:04,160 --> 00:06:09,610
computer can actually take that and send
it to the Internet. OK? So that's a quick

79
00:06:09,610 --> 00:06:14,920
rundown of how crypto or, sorry, how
hardware wallets work. So the first thing

80
00:06:14,920 --> 00:06:19,889
that we looked at was supply chain attacks
which is where Josh gonna pick up. You

81
00:06:19,889 --> 00:06:26,410
have a mic. Oh sorry.
Josh: Ok, so the three big things I want

82
00:06:26,410 --> 00:06:30,030
to leave you with as we go through the
supply chain attacks are, stickers for

83
00:06:30,030 --> 00:06:34,210
laptops, they are not for security. So
we're going to be talking about stickers

84
00:06:34,210 --> 00:06:39,330
today. They're there for laptop
decorations, they are not for security.

85
00:06:39,330 --> 00:06:43,221
Supply chain attacks are easy to perform,
but they're quite hard to perform at

86
00:06:43,221 --> 00:06:47,620
scale. And the last takeaway that I will
leave you with is that, the vendor's

87
00:06:47,620 --> 00:06:52,720
threat model may not actually be your
threat model. So security stickers, some

88
00:06:52,720 --> 00:06:56,460
of the wallet vendors are using them. I
have seen them on other products, they

89
00:06:56,460 --> 00:07:01,290
seem to be quite popular. I have a friend
and colleague named Joe Fitzpatrick, he

90
00:07:01,290 --> 00:07:06,690
also likes stickers. So the stickers that
he makes are the same as we find on his

91
00:07:06,690 --> 00:07:11,289
security product. They have holograms.
They have unique serial numbers. And they

92
00:07:11,289 --> 00:07:16,380
leave you with that nice warm fuzzy
security feeling. Joe makes some funny

93
00:07:16,380 --> 00:07:21,690
ones. You can get a Fitz 140-2 approved
stickers. You don't have to pay the money

94
00:07:21,690 --> 00:07:27,410
for the FIPS one, just get the Fitz one.
So the first device I looked at was the

95
00:07:27,410 --> 00:07:34,270
Trezor One. The Trezor One actually has
two levels of protection on the packaging.

96
00:07:34,270 --> 00:07:40,449
There's the hologram sticker than the
actual box is enclosed with an adhesive.

97
00:07:40,449 --> 00:07:44,349
So it's supposed to be that you actually
have to rip open the box to get into it.

98
00:07:44,349 --> 00:07:47,830
But if you use a hot air gun or a
hairdryer it's actually quite easy to

99
00:07:47,830 --> 00:07:51,949
remove. And so if you see on the left
there that's the original package and on

100
00:07:51,949 --> 00:07:57,490
the right this is a box that I opened and
put everything back into. And if you look

101
00:07:57,490 --> 00:08:01,069
closely there is a little bit of gap
there. The sticker has a little bit of

102
00:08:01,069 --> 00:08:05,491
break but this was the first try. And it's
pretty close. So trust me taking a sticker

103
00:08:05,491 --> 00:08:09,780
off is not very hard. Now if you remember
this picture of the sticker cause we're

104
00:08:09,780 --> 00:08:14,370
going to come back to it. So but for the
vendor this is actually a real problem so

105
00:08:14,370 --> 00:08:18,379
Trezor did put a blog post out that one of
the challenges they face is that they're

106
00:08:18,379 --> 00:08:22,819
facing counterfeiting of their devices. So
this is from their blog post. They say hey

107
00:08:22,819 --> 00:08:26,400
you know we've noticed that there's
counterfeit devices. You have to look at

108
00:08:26,400 --> 00:08:30,669
the stickers to see that they are legit.
So I said remember look at that sticker.

109
00:08:30,669 --> 00:08:35,010
So I bought that case about a year and a
half ago for my previous DevCon talk and

110
00:08:35,010 --> 00:08:39,290
it's the same sticker that they're saying
is fake here. So then on their wiki it's

111
00:08:39,290 --> 00:08:43,159
very confusing because there's three sets
of stickers so basically, yeah, stickers

112
00:08:43,159 --> 00:08:47,890
are very confusing. They cause problems
for end users. And I was not even sure if

113
00:08:47,890 --> 00:08:54,680
I bought a real Trezor or a cloned one. So
this morning I got out a new case. And

114
00:08:54,680 --> 00:08:59,010
just to make sure I took off the sticker
using very sophisticated equipment

115
00:08:59,010 --> 00:09:04,290
including a very expensive Dyson hairdryer
that was included in the AirBnB and I was

116
00:09:04,290 --> 00:09:08,174
able to remove the sticker.
So it comes off

117
00:09:08,174 --> 00:09:14,390
with zero residue. So yes stickers do
not provide any security. On the Trezor T

118
00:09:14,390 --> 00:09:18,350
they switched it from the box and now the
box can be opened easily. But now there's

119
00:09:18,350 --> 00:09:24,140
a sticker on the USB-C port. Again as you
would expect use hot air and you can

120
00:09:24,140 --> 00:09:28,940
easily remove it. Pro tip: don't set the
hot air rework that high I had it set for

121
00:09:28,940 --> 00:09:33,320
lead free reworking and I actually melted
the enclosure. So if you're going to do

122
00:09:33,320 --> 00:09:37,711
this kind of supply chain attack, maybe,
no, set the heat a little lower but if you

123
00:09:37,711 --> 00:09:44,690
just google how to remove stickers the
same attack methods work. So this causes

124
00:09:44,690 --> 00:09:49,750
a bit of confusion because the ledger
device has a very, I will say, in your

125
00:09:49,750 --> 00:09:55,210
face a piece of paper when you open the
box it says there are no stickers in this

126
00:09:55,210 --> 00:10:02,000
box. However I combed through about 250
1-star Amazon reviews and a lot of them

127
00:10:02,000 --> 00:10:06,220
have to do with confusion about the
stickers. So some of them are actually

128
00:10:06,220 --> 00:10:10,730
quite funny. So this this one started out
"Note to wallet hackers", so I was really

129
00:10:10,730 --> 00:10:15,410
into this. So I was like, OK, pro tip
what's this guy have to say? And basically

130
00:10:15,410 --> 00:10:18,940
he was complaining that there's
fingerprints on the device. That's how he

131
00:10:18,940 --> 00:10:23,880
knew it was hacked. Another one complained
that the fingerprints were on the wallet

132
00:10:23,880 --> 00:10:27,694
and there was a hair underneath. So if
you're doing supply chain attacks be sure

133
00:10:27,694 --> 00:10:32,390
to remove any evidence of your
fingerprints or hair. So anyway stickers

134
00:10:32,390 --> 00:10:36,613
don't work. That's all I want to say about
that. Once you get through this enclosure

135
00:10:36,613 --> 00:10:40,860
though you then have to have the challenge
of actually opening the enclosure. These

136
00:10:40,860 --> 00:10:44,770
are three different wallet devices: Ledger
Nano on the left, the Trezor One and the

137
00:10:44,770 --> 00:10:49,240
Trezor T on the bottom all of which
actually open pretty easily. So the Trezor

138
00:10:49,240 --> 00:10:53,580
One, even, so, I'm still not sure if
that's the counterfeit or the real one,

139
00:10:53,580 --> 00:10:57,930
but I get on the on the real one today. I
was able to pop open enclosure. So it is

140
00:10:57,930 --> 00:11:01,660
ultra sonically welded but you can pry it
in there and open it. The Ledger Nano

141
00:11:01,660 --> 00:11:06,070
opens very easily, like, without any
equipment. But once you do this, you know

142
00:11:06,070 --> 00:11:09,690
what do you do once it's opened? So the
attack basically is you take the

143
00:11:09,690 --> 00:11:13,340
microcontroller and you rework it. So you
remove the microcontroller from the

144
00:11:13,340 --> 00:11:17,260
printed circuit board and you put on a new
one that you bought from a distributor.

145
00:11:17,260 --> 00:11:20,660
Once you've done that on the Trezor
devices you can put your compromised

146
00:11:20,660 --> 00:11:24,610
bootloader on there. So this is, I did not
go as far to make the compromised

147
00:11:24,610 --> 00:11:28,385
bootloader, but I did confirm that once I
switched the microcontroller, I could

148
00:11:28,385 --> 00:11:33,200
connect with a debugger over SWD and I
have free access to the chip. So some of

149
00:11:33,200 --> 00:11:39,190
the parts got blown off when I was
reworking but the SDM works fine. So yeah.

150
00:11:39,190 --> 00:11:43,140
So you just rework, reflash and then you
put everything back together. So next I

151
00:11:43,140 --> 00:11:47,360
want to talk about hardware implants. So
you may remember the story that came out

152
00:11:47,360 --> 00:11:51,390
there was this big hack by Bloomberg about
hardware implants. I wanted to make a

153
00:11:51,390 --> 00:11:55,570
hardware implant. I also wanted to have a
little bit of fun with this. So, we, in

154
00:11:55,570 --> 00:12:00,390
honor of the Bloomberg story which has
some, you may have some issues with it.

155
00:12:00,390 --> 00:12:06,010
We're about to talk about the BloomBurglar
which is a super micro fun implant. So the

156
00:12:06,010 --> 00:12:10,010
goals for this implant is I wanted this
implant to happen after receipt. So it is

157
00:12:10,010 --> 00:12:14,325
both a supply chain attack and a physical
one like a red team can perform this. A

158
00:12:14,325 --> 00:12:18,970
malicious insider could also perform this
attack. Zero firmware, because more fun.

159
00:12:18,970 --> 00:12:22,980
It has to fit inside of a hardware wallet,
so it has to be small it has to also

160
00:12:22,980 --> 00:12:26,803
bypass the core security function,
otherwise it's not an implant. Very few

161
00:12:26,803 --> 00:12:31,870
components. I have a thousand of them with
me. So I wanted to be able to offer Makers

162
00:12:31,870 --> 00:12:37,927
and DIYers to participate in the hardware
implant fun. So what kind of implant did I

163
00:12:37,927 --> 00:12:42,100
end up with. Well, I decided to do a
basically, an RF-triggered switch and so

164
00:12:42,100 --> 00:12:47,115
the idea is on these devices there's a
button and the button is the last line of

165
00:12:47,115 --> 00:12:51,441
defense. So all the vendors assume that
the host is going to be compromised. They

166
00:12:51,441 --> 00:12:55,162
just assume that's going to be easy
because that's software. And so once you

167
00:12:55,162 --> 00:12:59,030
have a compromised host you have to send
it to the device and then the human -- so

168
00:12:59,030 --> 00:13:03,130
humans are still needed -- humans have to
look at it and say "Is this the right

169
00:13:03,130 --> 00:13:07,620
transaction or not?" They have to say yes
or no. So now with this implant I can,

170
00:13:07,620 --> 00:13:11,700
through RF, I can trigger the yes button.
So a human is not required to send

171
00:13:11,700 --> 00:13:15,366
transactions, I can remotely trigger it.
Basically the RF comes in through the

172
00:13:15,366 --> 00:13:19,040
antenna it goes through a single
transistor which is the main component and

173
00:13:19,040 --> 00:13:22,890
it pulls the button low. And I'm sorry to
say that the bill of materials is quite

174
00:13:22,890 --> 00:13:28,360
expensive at three dollars and 16 cents.
Two dollars and 61 cents of that is this

175
00:13:28,360 --> 00:13:33,780
potentiometer I had to use. So it is a
little bit expensive. I'm sorry. Also, why

176
00:13:33,780 --> 00:13:39,250
is this so big. I mean this is an American
Dime I can fit two on them. What's the

177
00:13:39,250 --> 00:13:43,110
deal. Why is it so big. Well I optimized
it for hand assembly. So it would be, you

178
00:13:43,110 --> 00:13:47,020
know, more fun to use, but basically you
put the antenna in and then there's an out

179
00:13:47,020 --> 00:13:51,056
button and, like I said, I have a thousand
with me. So just for scale. This is how it

180
00:13:51,056 --> 00:13:55,720
fits on the Ledger Nano. This is how it
fits on the Trezor. It is also because

181
00:13:55,720 --> 00:13:59,580
breadboard-friendly is a thing. So we made
it breadboard-friendly. So you can also

182
00:13:59,580 --> 00:14:04,230
play along very easily at home. So then
the last challenge with an RF implant is

183
00:14:04,230 --> 00:14:07,920
how do you design antenna to fit in there.
And so the big thing there with an

184
00:14:07,920 --> 00:14:11,850
SMA connector is the first prototype
I did. Experimented with a few antenna

185
00:14:11,850 --> 00:14:15,920
designs but that remember it, it all has
to fit inside the Ledger. So that's

186
00:14:15,920 --> 00:14:20,520
actually quite easy because a Ledger Nano
has a plenty of room to insert extra

187
00:14:20,520 --> 00:14:26,630
circuitry and so it quite fits easily in
the Ledger Nano. And then I did the

188
00:14:26,630 --> 00:14:30,066
implant and then I started to go through
the wallet process. I got to a

189
00:14:30,066 --> 00:14:34,680
check that said is might, you know, is the
Ledger device genuine. And here I actually

190
00:14:34,680 --> 00:14:39,626
got a little bit nervous because it wasn't
working, and so it wasn't working. I was

191
00:14:39,626 --> 00:14:43,569
like, maybe they were checking this, you
know how did they detect it. Don't worry,

192
00:14:43,569 --> 00:14:47,956
it's only Linux. So it just doesn't work
on Linux. So that was no problem. I did it

193
00:14:47,956 --> 00:14:52,492
on windows and no problems. The device was
genuine, I was able to move on. So the

194
00:14:52,492 --> 00:14:56,480
thing is, this is a very crude receiver,
but the attacker can always use more

195
00:14:56,480 --> 00:15:02,200
power. So here I have this is my antenna
setup in the basement, and with a 50W

196
00:15:02,200 --> 00:15:06,710
transmitter I can remotely trigger the
button at 11 meters, and at this point I'm

197
00:15:06,710 --> 00:15:10,589
just limited by my basement size. I'm
pretty very confident that I'd be able to

198
00:15:10,589 --> 00:15:16,550
remotely trigger this thing further. Yeah.
So here we're going to see a demo of what

199
00:15:16,550 --> 00:15:20,380
it looks like and for the other problem
you have with hardware implants is how do

200
00:15:20,380 --> 00:15:24,356
you know you have the implanted device. So
you have to label it some way. Ledger has

201
00:15:24,356 --> 00:15:29,290
this kind of Latin phrase that scrolls " I
wanted my own Latin phrase" And so this is

202
00:15:29,290 --> 00:15:33,310
how I know this is my implanted device. So
what we're going to see is that the

203
00:15:33,310 --> 00:15:37,188
transaction screens is gonna show up. This
is, and I'm basically going to trigger

204
00:15:37,188 --> 00:15:40,810
this remotely, so I'm going to show that
radio come in and then it's going to

205
00:15:40,810 --> 00:15:47,589
approve the transaction without any hands.
So this is the transaction. There is the

206
00:15:47,589 --> 00:15:51,949
screen going. This is the way it supposed
to verify. There's the radio coming in at

207
00:15:51,949 --> 00:15:56,395
433 MHz and then it's going to proceed to
the next screen without me touching the

208
00:15:56,395 --> 00:16:02,259
button. There you go. So this is remotely
triggered, and that would have sent

209
00:16:02,259 --> 00:16:06,270
transactions. So if you think about the
context that you have a malicious software

210
00:16:06,270 --> 00:16:10,636
implant that sent it to a wrong address,
the attacker now can remotely accept that

211
00:16:10,636 --> 00:16:19,610
and bypass the security module.
<i>Applause</i>

212
00:16:19,610 --> 00:16:25,646
So, yeah, on the recaps, stickers are for
laptops, not for security. Supply chain

213
00:16:25,646 --> 00:16:29,967
attacks are very easy to do at a hardware
level, but they're quite hard to do at

214
00:16:29,967 --> 00:16:33,716
scale. And when the vendor says the device
is genuine, that may mean different

215
00:16:33,716 --> 00:16:42,778
things.
Thomas: to segue to the next part, so six

216
00:16:42,778 --> 00:16:47,790
months ago, Josh Datko said something that
I found kind of funny and it's almost

217
00:16:47,790 --> 00:16:52,620
correct: "If you put funny constants in
your code, they will end up on DEFCON

218
00:16:52,620 --> 00:16:56,740
slides, and they won't be laughing with
you." Small mistake, they won't end up at

219
00:16:56,740 --> 00:17:03,410
DEF CON, they will be at CCC. and so
introducing the fOOdbabe vulnerability,

220
00:17:03,410 --> 00:17:09,359
it's a bootloader vulnerability in a
Ledger Nano S. We did not come up with

221
00:17:09,359 --> 00:17:14,050
this constant. It's literally in the code
as we'll see later. So the name was not

222
00:17:14,050 --> 00:17:19,109
ours, but we like it. So we also bought
the domain foodba.be.

223
00:17:19,109 --> 00:17:23,934
<i>Laughter</i>
Ledger Nano S is a very simple wallet. It

224
00:17:23,934 --> 00:17:28,383
simply has a small display, it has a USB
port and two buttons. That's really all

225
00:17:28,383 --> 00:17:33,170
there is. And you should take it apart.
You see it's just some pieces of plastic,

226
00:17:33,170 --> 00:17:38,570
the display and the PCB. And looking at
the PCB, it kind of has an interesting

227
00:17:38,570 --> 00:17:44,770
architecture where you have a STM32, which
is just a general purpose microcontroller,

228
00:17:44,770 --> 00:17:50,250
and a ST31, which is a secret element that
is for example used in pay-TV and so on.

229
00:17:50,250 --> 00:17:56,290
And is regarded as a very high security
chip, basically. And if you turn the PCB

230
00:17:56,290 --> 00:18:00,070
around, you'll see that they were nice
enough to leave the programming port for

231
00:18:00,070 --> 00:18:06,770
the STM32 open to us, ENABLED.
<i>Laughter</i>

232
00:18:06,770 --> 00:18:13,440
And this has been suspected by other
people that we verified it. But you know,

233
00:18:13,440 --> 00:18:17,810
you have to go through it. And obviously
Ledger is aware of this. And so let's look

234
00:18:17,810 --> 00:18:23,430
at the security model that the Ledger Nano
S has. The basic idea is that if we look

235
00:18:23,430 --> 00:18:28,700
at this device, we kind of have this
schematic of the STM32 being on the left

236
00:18:28,700 --> 00:18:33,640
and the ST31 on the right. And as you can
see, all peripherals are connected to the

237
00:18:33,640 --> 00:18:39,040
STM32. That is because the ST31 does not
have enough pins to connect peripherals.

238
00:18:39,040 --> 00:18:43,814
It literally only has a one pin interface,
which is for the smartcard protocols

239
00:18:43,814 --> 00:18:50,560
basically. And so all the heavy lifting is
done by the STM32. And Ledger splits it up

240
00:18:50,560 --> 00:18:56,590
into the unsecure part and the secure
part. And the idea is that the STM32 acts

241
00:18:56,590 --> 00:19:00,860
as a proxy. So it's basically the hardware
driver for the button, for the display,

242
00:19:00,860 --> 00:19:06,216
for the USB, similar to a northbridge in
your standard computer. And when you take

243
00:19:06,216 --> 00:19:11,160
a computer and want to make a transaction,
you create your transaction on the

244
00:19:11,160 --> 00:19:18,770
computer, it goes through USB to the
STM32, and the STM32 then forwards it to

245
00:19:18,770 --> 00:19:25,480
the ST31. THe ST31 then says, Oh, a new
transaction, I want trust the user to

246
00:19:25,480 --> 00:19:31,010
confirm it. So it sends a display command
to the STM32 which in turn displays that

247
00:19:31,010 --> 00:19:36,190
on the screen. And then you press the
"yes" button again it goes the same route

248
00:19:36,190 --> 00:19:41,430
to the ST31, which then internally signs
the transaction. So the seed never leaves

249
00:19:41,430 --> 00:19:47,470
the device and our assigned transaction
goes back through the STM, through USB to

250
00:19:47,470 --> 00:19:54,400
the computer. To us, this means if this
chip is compromised, we can send malicious

251
00:19:54,400 --> 00:20:01,500
transactions to the ST31 and confirm them
ourselves. Or we can even go and show a

252
00:20:01,500 --> 00:20:06,970
different transaction on the screen than
we are actually sending to the ST31. And

253
00:20:06,970 --> 00:20:11,570
Ledger is aware of this and we'll talk
about how they try to mitigate this later.

254
00:20:11,570 --> 00:20:15,720
But first we have to find an exploit,
because while we do have debugging access

255
00:20:15,720 --> 00:20:22,250
to the chip, hardware access is sometimes
kind of buggy. No offence. So we wanted to

256
00:20:22,250 --> 00:20:26,550
have a software bug. And so we started
reverse engineering the firmware upgrade

257
00:20:26,550 --> 00:20:34,180
process. And when you look at the
bootloader, the bootloader for the Ledger

258
00:20:34,180 --> 00:20:38,530
used to be open-source, and back then they
didn't have any verification of the

259
00:20:38,530 --> 00:20:42,780
firmware. So you could basically boot the
device into bootloader mode, flash

260
00:20:42,780 --> 00:20:47,610
whatever from where you want, and then it
would run it. After someone, Saleem in

261
00:20:47,610 --> 00:20:51,730
this case, wrote about this, they changed
it, and they changed it to do some

262
00:20:51,730 --> 00:20:56,070
cryptographic measure. And we were too
lazy to reverse engineer the cryptographic

263
00:20:56,070 --> 00:21:00,730
measure because it's very time consuming,
very hard. So we looked more at the parts

264
00:21:00,730 --> 00:21:06,140
surrounding it and how we can maybe find a
bug in the bootloader to break it. And it

265
00:21:06,140 --> 00:21:14,130
turns out that when you try to upgrade
your Ledger, you accept four different

266
00:21:14,130 --> 00:21:18,820
commands. One is select segment, which
allows you to select the address base at

267
00:21:18,820 --> 00:21:22,730
which you're firmware will be flashed. One
is the load command, which allows you to

268
00:21:22,730 --> 00:21:27,570
write data to flash. Then you have the
flush command, which is basically like

269
00:21:27,570 --> 00:21:32,875
f-sync on Linux and writes your changes to
the non-volatile memory. And you have the

270
00:21:32,875 --> 00:21:38,546
boot command, which verifies the flash
code and starts booting it. So to us the

271
00:21:38,546 --> 00:21:43,723
boot command is the most interesting,
because it provides all verification and

272
00:21:43,723 --> 00:21:50,010
it attempts to ensure that no malicious
image is booted. And it turns out that if

273
00:21:50,010 --> 00:21:54,020
you issue the boot command, it compares
the whole image to whatever

274
00:21:54,020 --> 00:21:59,421
cryptographically function they use, and
if it's successfully verified, they write

275
00:21:59,421 --> 00:22:08,640
a constant to the address 0x0800 3000, and
that constant is OxF00DBABE. And so, to

276
00:22:08,640 --> 00:22:14,690
not have to verify the entire flash on
each boot, they just do this once, so only

277
00:22:14,690 --> 00:22:22,100
after firmware upgrade. So basically if
you boot up the ledger, it boots, it waits

278
00:22:22,100 --> 00:22:25,990
500 milliseconds. It checks if you have a
button pressed. If yes, it goes to

279
00:22:25,990 --> 00:22:32,584
bootloader. Otherwise it loads the
constant at 0x08003000. And if it's

280
00:22:32,584 --> 00:22:36,597
0xF00DBABE, it boots the firmware. So our
goal is to write a 0xF00DBABE to that

281
00:22:36,597 --> 00:22:43,600
address. First attempt, we just issue a
select segment command to exactly that

282
00:22:43,600 --> 00:22:51,564
address. We just write 0xF00DBABE to it,
flush and reset the device. Didn't work

283
00:22:51,564 --> 00:22:57,049
unfortunately. so we had to do more
reverse engineering. It turns out that

284
00:22:57,049 --> 00:23:02,100
they use an interesting approach to ensure
that you don't accidentally flash over the

285
00:23:02,100 --> 00:23:06,690
bootloader. So they basically blacklist a
whole memory region. So if you try to

286
00:23:06,690 --> 00:23:15,249
flash from 0x0800_0000 up to 0x0800_3000.
It returns an error. If you try to

287
00:23:15,249 --> 00:23:19,300
directly write to F00DBABE, They thought
about it, and they have a very specific

288
00:23:19,300 --> 00:23:25,736
code path to prevent that. So they memset
it to zero and you're screwed again. And

289
00:23:25,736 --> 00:23:31,740
then finally it writes assuming you didn't
error out. But it turns out that the STM32

290
00:23:31,740 --> 00:23:36,950
has kind of an interesting memory map and
on a lot of chips, you cannot only map

291
00:23:36,950 --> 00:23:41,690
your flash to one address, but you can
also have it mapped to another address.

292
00:23:41,690 --> 00:23:50,990
And in this case the flash is indeed also
mapped to the address 0. And so the

293
00:23:50,990 --> 00:23:57,170
bootloader uses a blacklisting approach,
so it only excludes certain memory areas.

294
00:23:57,170 --> 00:24:01,220
But it doesn't use whitelisting where you
could only explicitly write to this memory

295
00:24:01,220 --> 00:24:08,700
region. So they do not block writing to
0x0000_0000. Profit! Second attempt. We

296
00:24:08,700 --> 00:24:15,401
just select the segment at 0x0000_3000,
which maps to 0x0800_3000, we write

297
00:24:15,401 --> 00:24:23,100
0xF00DBABE to it, we flush, reset, and we
can flash custom firmware! Awesome!

298
00:24:23,100 --> 00:24:32,520
<i>Applause</i>
So what do you do when you have a device

299
00:24:32,520 --> 00:24:40,182
that, where the display is not big enough
to run DOM with a custom firmware. So in

300
00:24:40,182 --> 00:24:44,090
this case it's an original letter, press
the button, put it into bootloader mode,

301
00:24:44,090 --> 00:24:59,960
which is part of the normal operation, and
<i>Laughtes and Applause</i>

302
00:24:59,960 --> 00:25:06,520
If you want to play a bit of snake, come
by later. How are they protecting against

303
00:25:06,520 --> 00:25:11,667
this? I've mentioned before Ledger is
aware that you can reflash this STM32. And

304
00:25:11,667 --> 00:25:16,400
they are, they put in some measures to
prevent you from doing malicious stuff.

305
00:25:16,400 --> 00:25:20,870
And basically what they do and this is
very simplified, and we did not bother to

306
00:25:20,870 --> 00:25:26,630
fully reverse engineer because we didn't
need to, basically. When the chip boots,

307
00:25:26,630 --> 00:25:31,490
it sends its entire firmware to the ST31,
which then performs some kind of hashing

308
00:25:31,490 --> 00:25:36,700
also, verifies that the firmware as
authentic. And it also measures the time

309
00:25:36,700 --> 00:25:40,760
it takes to send the firmware. This is to
prevent you from just running a

310
00:25:40,760 --> 00:25:48,772
compression algorithm on the STM32 and
send it very slowly. How do we bypass

311
00:25:48,772 --> 00:25:55,716
this? So our idea was, because we not only
have flash, we also have RAM. So what if

312
00:25:55,716 --> 00:26:04,161
we create a compromised and compressed
firmware that copies itself to RAM? We

313
00:26:04,161 --> 00:26:10,241
jump to it and then it writes its entire
compressed firmware to flash,

314
00:26:10,241 --> 00:26:14,961
uncompressed in that case, and then we
just call the original code on the secure

315
00:26:14,961 --> 00:26:21,290
element. It would verify the firmware, it
would run with a real timing and boots up

316
00:26:21,290 --> 00:26:28,000
regularly. And so we attempted this. It
took quite a while to achieve.

317
00:26:28,000 --> 00:26:31,570
Because basically, you can't do ZIP, you
can't do LZMA, because even if you

318
00:26:31,570 --> 00:26:36,850
compress the image you don't have enough
space for complex compressor. So our

319
00:26:36,850 --> 00:26:41,960
attempt was to find duplicate bytes,
squeeze them together and make space for a

320
00:26:41,960 --> 00:26:46,390
custom payload. And basically we just have
a table that says, okay, now you will have

321
00:26:46,390 --> 00:26:52,590
six zeros or something. And our each table
entry only takes a single byte. So, and

322
00:26:52,590 --> 00:26:56,610
it's only like 10 instructions in
assembler to run this decompressor, so you

323
00:26:56,610 --> 00:27:01,000
don't have the large code base. It's very
easy to use. And it turns out that even

324
00:27:01,000 --> 00:27:05,330
with a very simple detector, like in this
case we rerun the script to find the

325
00:27:05,330 --> 00:27:10,750
longest duplicate data, and you can see on
the first try, we get like 260 bytes of

326
00:27:10,750 --> 00:27:17,219
space for our payload, which is enough for
a lot of things, let's say. And we have a

327
00:27:17,219 --> 00:27:22,330
working PoC of concept of this and we
would go into a lot of details, but if we

328
00:27:22,330 --> 00:27:27,450
only got an hour. And so we will release
after this talk and on non-offensive

329
00:27:27,450 --> 00:27:31,850
example of this that you can look at how
does it work, what can you do even if

330
00:27:31,850 --> 00:27:37,170
you're firmware is attempting to be
verified. And we also and this is very

331
00:27:37,170 --> 00:27:41,391
exciting we are working with the YouTube
LiveOverflow and he created a 20 minute

332
00:27:41,391 --> 00:27:46,919
video on walking through this entire
F00DBABE vulnerability, how did the

333
00:27:46,919 --> 00:27:51,877
verification works and how to bypass it to
a certain degree. We don't want to

334
00:27:51,877 --> 00:27:56,920
weaponize it. So we did not, we will not
release the first the full thing, but

335
00:27:56,920 --> 00:28:02,676
yeah, very excited for this. Stay tuned on
our Twitter and we'll link it for sure. As

336
00:28:02,676 --> 00:28:06,393
part of this, we also have a lot of
software that we will release. So public

337
00:28:06,393 --> 00:28:10,320
release, we'll release the snake firmware.
So hopefully this evening you'll be able

338
00:28:10,320 --> 00:28:15,250
to play snake on your Ledger. If you
bought some bitcoin at twenty thousand now

339
00:28:15,250 --> 00:28:21,070
you're bankrupt, you can at least play
snake. We will opensource the compressor

340
00:28:21,070 --> 00:28:26,350
and the extractor. We built a logic
analyzer plugin for this markup protocol

341
00:28:26,350 --> 00:28:31,330
and we built software that analyzes the
communication between the STM32 and the

342
00:28:31,330 --> 00:28:36,900
ST31 on the Ledger specific data, and you
can just dump it. So if you guys are

343
00:28:36,900 --> 00:28:45,500
interested in for example trying to break
into the ST31, please have a go. And

344
00:28:45,500 --> 00:28:50,302
Ledger has a second device, which is
called the Ledger Blue. We assume the

345
00:28:50,302 --> 00:28:55,300
reason it's called the Ledger Blue is
because it contains Bluetooth. But they

346
00:28:55,300 --> 00:29:00,060
never enable Bluetooth. So it's basically
just a regular Ledger with a color display

347
00:29:00,060 --> 00:29:06,240
and a big battery in it. And we call this
part "Fantastic Signals and how to find

348
00:29:06,240 --> 00:29:10,210
them".
<i>Laughter</i>

349
00:29:10,210 --> 00:29:14,980
Because when we opened up this device and
we were chatting, we have this nice

350
00:29:14,980 --> 00:29:20,530
telegram chat room where we're chatting
24/7 while doing this. And we opened up

351
00:29:20,530 --> 00:29:24,460
the device and the first thing,like
literally five minutes after opening it, I

352
00:29:24,460 --> 00:29:29,653
saw that you have the secure element on
the left and the STM32 on the right. You

353
00:29:29,653 --> 00:29:36,220
have some other stuff like the Bluetooth
module and so on. The trace between the

354
00:29:36,220 --> 00:29:42,445
secure element and the microcontroller is
pretty long and contains a pretty fast

355
00:29:42,445 --> 00:29:50,590
signal. So what is a long conductor with a
fast changing current? Anyone got a clue?

356
00:29:50,590 --> 00:29:54,844
<i>Interjection</i>
Correct. It's an antenna.

357
00:29:54,844 --> 00:30:02,550
So I pulled out my HackRF 
software defined radio, this

358
00:30:02,550 --> 00:30:08,470
is just a very, a more sophisticated RTL-
SDR, so you can just sniff arbitrary

359
00:30:08,470 --> 00:30:13,600
signals with it. I got a random shitty
telescope antenna on Amazon and they have

360
00:30:13,600 --> 00:30:20,330
my Ledger blue. So on this screen, you can
see the blue thing is the radio spectrum

361
00:30:20,330 --> 00:30:26,790
around 169 MHz and if we start entering
our pin we can see that there's a weak

362
00:30:26,790 --> 00:30:29,960
signal.
<i>Laughter</i>

363
00:30:29,960 --> 00:30:37,670
You guys see where this is going. On the
radio. Unfortunately that signal is pretty

364
00:30:37,670 --> 00:30:46,410
weak. Luckily they included an antenna.
They call it a USB cable, but I'm not so

365
00:30:46,410 --> 00:30:53,610
sure about it. So this time with USB
connected, and we do the same thing again.

366
00:30:53,610 --> 00:31:00,004
You can see like crazy radio spikes and
this is right next to each other. But even

367
00:31:00,004 --> 00:31:05,820
if you go a couple of meters. I was
limited as Josh by my living room space.

368
00:31:05,820 --> 00:31:11,950
You get a couple of meters of decent
reception. So our goal was to find out

369
00:31:11,950 --> 00:31:17,970
what is this signal and if we just look at
the recorded amplitude of the signal, we

370
00:31:17,970 --> 00:31:23,291
get this. And if you do a lot of probing
and so on, you immediately see, ok, there

371
00:31:23,291 --> 00:31:29,380
are spikes and there are 11 of them and
then there's a pause and then are small

372
00:31:29,380 --> 00:31:34,760
spikes. So this is probably some kind of
protocol that first sends 11 bytes of data

373
00:31:34,760 --> 00:31:39,415
then pauses, and then sends more data. So
we looked at the back of the device,

374
00:31:39,415 --> 00:31:43,571
started probing every single connection
and tried to figure out is this the secure

375
00:31:43,571 --> 00:31:50,210
element? Is this whatever? And it turned
out to be the display bus. So we can sniff

376
00:31:50,210 --> 00:31:56,830
information on what is sent to the display
remotely. And if you, if we look at the

377
00:31:56,830 --> 00:32:01,040
signal that gets sent in blue, it's the
signal that gets sent when you press the

378
00:32:01,040 --> 00:32:07,010
letter zero on the pin pad and an orange
when you press the letter seven. So we can

379
00:32:07,010 --> 00:32:11,304
see a very clear difference at certain
points on the signal which confirmed our

380
00:32:11,304 --> 00:32:16,850
suspicion. But building software for this
is kind of boring, like digital signal

381
00:32:16,850 --> 00:32:22,380
processing is not really my thing. So what
do we do? And we wanted to increase the

382
00:32:22,380 --> 00:32:29,140
buzzword load in our talk a bit. And so we
are hacking blockchain IoT devices, using

383
00:32:29,140 --> 00:32:40,934
artificial intelligence, in the cloud.
<i>Applause and Laughter</i>

384
00:32:40,934 --> 00:32:47,660
So our ideal was we record training
signals, we use some kind of prefiltering,

385
00:32:47,660 --> 00:32:55,130
we train AI on it. Profit! Literally.
Problem is, getting training data really

386
00:32:55,130 --> 00:32:59,309
sucks, because you don't want to sit there
for 10 hours pressing the same key on a

387
00:32:59,309 --> 00:33:06,094
pin pad. It really doesn't sound like fun.
And so this needs automation. So,

388
00:33:06,094 --> 00:33:11,700
<i>Laughter</i>
So we took in Arduino, we took a roll of

389
00:33:11,700 --> 00:33:17,560
masking tape, a piece of acrylic glass, a
PCB vice and this is a HUAWEI-pen for the

390
00:33:17,560 --> 00:33:24,937
extra amount of Chinese backdoor. And we
let this run for a couple of hours. And

391
00:33:24,937 --> 00:33:32,360
you can actually see that every time it
presses down, you can see that the digit

392
00:33:32,360 --> 00:33:37,480
that you pressed is highlighted and the
difference in the signal we saw earlier is

393
00:33:37,480 --> 00:33:42,600
probably the x and y coordinate, of where
it highlights the button. And that's the

394
00:33:42,600 --> 00:33:51,065
difference. We can see in the trace. And
so we had a lot of recorded data. Now we

395
00:33:51,065 --> 00:33:58,241
created a training set. We created a test
set, preprocessing Tensorflow ai model.

396
00:33:58,241 --> 00:34:05,188
It's really easy surprisingly. And we
tried our test set did a prediction. And

397
00:34:05,188 --> 00:34:10,360
so the big question how accurate is it.
And it turns out. So this is the the

398
00:34:10,360 --> 00:34:16,530
result of a cut of the test set. And if we
zoom in on this this basically tells you

399
00:34:16,530 --> 00:34:21,594
we have the signal of this great thing
it's just a picture representation of the

400
00:34:21,594 --> 00:34:28,550
signal and it tells you how sure it is,
what digit it is. In this case it's 7 with

401
00:34:28,550 --> 00:34:35,168
98 percent likelihood. So pretty good. In
our test set we only have one wrong result

402
00:34:35,168 --> 00:34:40,760
and overall we get it wrong 90 percent
accuracy and to move this in the cloud we

403
00:34:40,760 --> 00:34:46,699
are hosting this on the Google cloud. As
the LedgerAI for you guys to play with and

404
00:34:46,699 --> 00:34:51,415
we'll publish it online with a limited
dataset that is trained on a very close

405
00:34:51,415 --> 00:34:56,020
space. You cannot do something super
malicious with it but it's nice to play

406
00:34:56,020 --> 00:35:01,510
around and see how this was done. And this
brings us to the next part, glitch me if

407
00:35:01,510 --> 00:35:11,770
you can. Thank you.
<i>Applause</i>

408
00:35:11,770 --> 00:35:17,024
Josh: So now we're going to talk about the
silicon level vulnerability with glitching

409
00:35:17,024 --> 00:35:21,342
attacks fault injectio so to review.
So to review I will be talking about the

410
00:35:21,342 --> 00:35:25,530
trezor one. And so I just want to go over
very quickly what the architecture is of

411
00:35:25,530 --> 00:35:31,910
the trezor one and some previous work that
is done. So the Trezor One is quite a

412
00:35:31,910 --> 00:35:37,800
simple embedded device. It consists of
only a few components. It has an OLED

413
00:35:37,800 --> 00:35:44,062
display it has some buttons and has a USB
connector that are all externally facing.

414
00:35:44,062 --> 00:35:53,619
Internally it has its main brain if you
will the STM32F205 microcontroller which

415
00:35:53,619 --> 00:35:57,923
controls all the other operations on the
Trezor, that display, the USB, and the two

416
00:35:57,923 --> 00:36:05,130
buttons. So last year we gave a talk at
DEFCON "Breaking Bitcoin Hardware Wallets"

417
00:36:05,130 --> 00:36:09,549
here we use the chip whisper to mainly do
the glitching attacks, the conclusions

418
00:36:09,549 --> 00:36:16,400
from last year is that the F2O5 was
vulnerable to fault injection but it was

419
00:36:16,400 --> 00:36:21,498
inconclusive if we could do a exploit via
the fault. So this year we have a

420
00:36:21,498 --> 00:36:27,468
different result but the output of that
work was this board was

421
00:36:27,468 --> 00:36:29,200
called the breaking bitcoin board.

422
00:36:29,200 --> 00:36:34,130
Basically it was a Trezor clone that just
made it easy to attach wires and probes

423
00:36:34,130 --> 00:36:38,517
and so we made this board. The design
schematics are all online. It's open

424
00:36:38,517 --> 00:36:42,970
source hardware. This is the chip
whisperer set up that we were using so we

425
00:36:42,970 --> 00:36:47,257
made the board specifically to fit on the
chip whisperer target board. And this is

426
00:36:47,257 --> 00:36:51,739
just what it looks like when you use the
chip whisper GUI to perform a glitch. And

427
00:36:51,739 --> 00:36:56,442
here we were doing application level code
so it's very different but I gave that

428
00:36:56,442 --> 00:37:07,020
talk and then I met Dmitry and Thomas.
Dmitry: Fortunately we had Josh to do the

429
00:37:07,020 --> 00:37:11,690
talk last year and to kind of exhaust a
lot of the firmware vulnerabilities that

430
00:37:11,690 --> 00:37:15,570
were actually hardware vulnerabilities in
the firmware that might have been there.

431
00:37:15,570 --> 00:37:19,750
So we immediately knew that we could
exclude this. And so you can start looking

432
00:37:19,750 --> 00:37:23,990
at the underlying microcontrollers. So in
this case it's STM32 microcontroller that

433
00:37:23,990 --> 00:37:28,556
they use inside of it and it controls
everything. So compromising the STM32

434
00:37:28,556 --> 00:37:33,430
microcontroller means that you can
compromise, you can compromise the device.

435
00:37:33,430 --> 00:37:38,690
So I mean so there's a couple of papers
that have covered some of the

436
00:37:38,690 --> 00:37:42,800
vulnerabilities in the STM32 specifically
there's one which describes a UV attack

437
00:37:42,800 --> 00:37:49,090
which lets you downgrade the security on
the STM32. So we determined that paper

438
00:37:49,090 --> 00:37:53,880
unfortunately does not apply to our result
because the Trezor or is smart enough when

439
00:37:53,880 --> 00:37:58,670
it boot's to check the value stored in
Flash. And if it has been altered in any

440
00:37:58,670 --> 00:38:03,516
way to set it correctly. So they actually
even protect against this kind of attack.

441
00:38:03,516 --> 00:38:08,190
But nevertheless you can see that there is
some vulnerabilities. So there is another

442
00:38:08,190 --> 00:38:12,310
paper which unfortunately has not been
published yet and we couldn't get in touch

443
00:38:12,310 --> 00:38:15,880
with the authors yet. That should be
coming out in January hopefully which

444
00:38:15,880 --> 00:38:23,380
describes glitches against the STM32 F1
and STM32 F3. So now we have the F0, the

445
00:38:23,380 --> 00:38:30,250
F1, and the F3 and so basically here's the
product matrix. So three of them are

446
00:38:30,250 --> 00:38:37,530
already vulnerable. So what we're looking
at SDM 32 F2 and potentially STM32 F4 if

447
00:38:37,530 --> 00:38:43,160
we're talking about the Trezor model T so
those we do not have vulnerabilities for

448
00:38:43,160 --> 00:38:49,738
yet. So let's take a look at how how it
works really quickly. So the way that STM

449
00:38:49,738 --> 00:38:56,010
implements security on the STM32 is that
they store an option byte and the option

450
00:38:56,010 --> 00:39:02,119
byte the thing to remember is on on a
cortex M3 or M4 microcontroller that you

451
00:39:02,119 --> 00:39:06,010
don't have anything other than flash. So
even though they call it option buy or

452
00:39:06,010 --> 00:39:10,130
refer you to this is fusing or being
permanent and hardware. It's still stored

453
00:39:10,130 --> 00:39:14,180
and flash just like the user application
is stored in flash. So it's the same exact

454
00:39:14,180 --> 00:39:19,390
same non-volatile memory that's otherwise
used. So basically when you get a new SDM

455
00:39:19,390 --> 00:39:24,400
32 it's shipped in a state where you have
full access. So that's how Josh was able

456
00:39:24,400 --> 00:39:30,530
to rework abord and flash it with new
firmware. And there is the ultimate

457
00:39:30,530 --> 00:39:35,650
security is what's called RDP2. So there
you have no access but you can see that

458
00:39:35,650 --> 00:39:43,550
basically if you have a value other than
aa or cc which correspond to RDP0 and RDP2

459
00:39:43,550 --> 00:39:48,670
respectively then you have what's called
RDP1 and this is interesting because it

460
00:39:48,670 --> 00:39:52,590
doesn't give you access to the flash which
is actually where the cryptographic seed

461
00:39:52,590 --> 00:39:57,050
is stored on the Trezor but it gives you
access to RAM, it gives you access to the

462
00:39:57,050 --> 00:40:01,440
registers but it doesn't give you flash
access like I said and it doesn't give you

463
00:40:01,440 --> 00:40:05,350
single stepping as well so connecting a
debugger and this mode will actually cause

464
00:40:05,350 --> 00:40:10,480
the hardware to hard fault which we'll see
in the second. So basically what we want

465
00:40:10,480 --> 00:40:16,099
to try to do is to downgrade RDP2 which is
what the trezor is set to. And we want

466
00:40:16,099 --> 00:40:24,450
to be able to access the device at RDP1
which is somewhat vulnerable state. This

467
00:40:24,450 --> 00:40:29,160
so I should say that this is this is the
correct way to approach this and it's

468
00:40:29,160 --> 00:40:35,270
great for doing an educational talk. But
in all honesty there's three of us. And so

469
00:40:35,270 --> 00:40:39,859
we did this completely in the dark over a
over 3 months trying different

470
00:40:39,859 --> 00:40:44,330
parameters on our on our glitch setups
which also later and were able to find

471
00:40:44,330 --> 00:40:49,740
this. But I'm here to explain it to all of
you so that it's easy to reproduce. So if

472
00:40:49,740 --> 00:40:53,640
you actually watch the SDM 30F2 boot
you'll see that it's relatively slow and

473
00:40:53,640 --> 00:40:57,780
it's only this slow after you power cycle
the board. So it takes approximately

474
00:40:57,780 --> 00:41:02,340
1.8 milliseconds to boot which is
a microcontroller terms pretty slow so you

475
00:41:02,340 --> 00:41:06,170
can see there's the power supply there's
the IO pin and that's approximately how

476
00:41:06,170 --> 00:41:10,720
long it takes to boot the firmware so you
can see that's where the IO actually

477
00:41:10,720 --> 00:41:16,250
toggles so 120 milliseconds later. So we
just wrote some firmware to basically

478
00:41:16,250 --> 00:41:20,130
toggle one of the pins measured within an
oscilloscope. Now we have the timing of

479
00:41:20,130 --> 00:41:24,830
how long that takes. So that's not super
interesting because that's not really a

480
00:41:24,830 --> 00:41:29,010
trigger. And each one of these
microcontrollers internally it has a boot

481
00:41:29,010 --> 00:41:34,790
rom so it has some some rom read only
memory. It's not non-volatile memory it's

482
00:41:34,790 --> 00:41:40,619
not the flash. It's literally a rom which
is inside the chip itself. It's it's hard

483
00:41:40,619 --> 00:41:45,589
coded. It cannot be fixed or patched that
gets executed first. So we wanted to

484
00:41:45,589 --> 00:41:49,510
actually attack that because anything else
is the user application and that's what

485
00:41:49,510 --> 00:41:54,340
Josh did last year. So you can kind of
start to fiddle this down. So you see that

486
00:41:54,340 --> 00:41:58,600
1.4 milliseconds of the reboot
nothing actually happens because this is

487
00:41:58,600 --> 00:42:02,450
now the reset line. And so the reset line
goes high after 1.4 millisecond

488
00:42:02,450 --> 00:42:06,060
so you can ignore the first
1.4 milliseconds after you

489
00:42:06,060 --> 00:42:10,560
cycle the power. So now the next step that
you can actually do is you can connect

490
00:42:10,560 --> 00:42:15,870
what's called a shunt resistor. So
oscilloscopes are there to measure

491
00:42:15,870 --> 00:42:19,349
voltage and so you want to actually
measure current to be able to know how

492
00:42:19,349 --> 00:42:23,450
much power is being consumed
by the device. So you do what's called

493
00:42:23,450 --> 00:42:26,721
a shunt measurement and that's
what I have on this slide right here.

494
00:42:26,721 --> 00:42:30,839
So you have the blue signal is now
actually the power consumption. And so now

495
00:42:30,839 --> 00:42:34,640
you can actually look and see what's
happening. So the first thing that happens

496
00:42:34,640 --> 00:42:38,859
is we have the execution of the BootROM.
You can see in the power consumption curve

497
00:42:38,859 --> 00:42:44,440
you can clearly see this moment in time.
Then you have basically where the flash

498
00:42:44,440 --> 00:42:49,209
and option bytes actually get read
somewhat at least within the BootROM. And

499
00:42:49,209 --> 00:42:53,620
finally the third distinctive moment in
time is where the application actually

500
00:42:53,620 --> 00:42:58,240
begins to execute. So now we've taken this
1.8 milliseconds which is a

501
00:42:58,240 --> 00:43:03,200
relatively long time and reduced it to 200
microseconds. We're actually interested

502
00:43:03,200 --> 00:43:07,910
in. And not only that we know that we're
actually interested in having slightly

503
00:43:07,910 --> 00:43:12,650
higher power consumption than the normal
execution of the bootloader or the BootROM

504
00:43:12,650 --> 00:43:19,230
rather and this is somewhere between
let's say 170 microseconds and 200

505
00:43:19,230 --> 00:43:23,760
microseconds. So this is the time at which
we actually need to glitch and this is

506
00:43:23,760 --> 00:43:28,460
also reasonable parameters. If you're
trying to reproduce this at home. So what

507
00:43:28,460 --> 00:43:33,570
do you need to reproduce this thing. So I.
The greatest thing that came out in the

508
00:43:33,570 --> 00:43:38,660
last couple of years is the these cheap
Chinese power supplies where you take a

509
00:43:38,660 --> 00:43:43,600
cheap you know old wall wart from one of
your old Linksys routers you plug it in

510
00:43:43,600 --> 00:43:48,860
and then you actually have a controllable
power supply with with voltage and current

511
00:43:48,860 --> 00:43:53,460
and you can adjust this and control this.
And so that's what we're using here. The

512
00:43:53,460 --> 00:43:56,645
second thing that I have to actually

513
00:43:56,645 --> 00:44:01,390
control the timing is an FPGA. I mean I
use FPGA's for everything and this is

514
00:44:01,390 --> 00:44:05,849
something that was easiest to put together
with an FPGA because FPGAs have constant

515
00:44:05,849 --> 00:44:11,471
timing. So finally we have a multiplexer
there as well and the multiplexers are

516
00:44:11,471 --> 00:44:16,750
actually switching between two voltages
between ground so completely cutting the

517
00:44:16,750 --> 00:44:21,260
voltage off and the normal operating
voltage of the microcontroller. And

518
00:44:21,260 --> 00:44:27,310
finally we have a debugger, the J-link
which is highly advised if you want to

519
00:44:27,310 --> 00:44:33,310
ever do Jtag stuff. So it's just a Jtag
debugger and basically what happens is

520
00:44:33,310 --> 00:44:39,540
you let this run for a while and it looks
like this. It's not really super eventful

521
00:44:39,540 --> 00:44:43,590
so you can see that the voltage the yellow
signal is actually the voltage and you can

522
00:44:43,590 --> 00:44:46,770
see we're just dipping the voltage at
different points in time and

523
00:44:46,770 --> 00:44:51,630
simultaneously we have a python script
checking if we have Jtag access or not.

524
00:44:51,630 --> 00:44:56,680
Protip to all the new dads if you do this
at home you can turn your oscilloscope

525
00:44:56,680 --> 00:45:00,499
towards the door, so that when you get up
at night because the baby's crying, you

526
00:45:00,499 --> 00:45:06,060
can see if it's still running or not. So
it's very, it's highly advised. So now

527
00:45:06,060 --> 00:45:10,900
Thomas is going to tell us how to get the
seed into into RAM.

528
00:45:10,900 --> 00:45:17,500
Thomas: So we had this thing running for
3 months roughly across 3

529
00:45:17,500 --> 00:45:22,020
continents because Josh is in America,
Dmitry is in Russia and I'm in Germany and

530
00:45:22,020 --> 00:45:26,610
so it took us 3 months to get a
successful glitch and even then we didn't

531
00:45:26,610 --> 00:45:32,090
believe it at first because we exhausted
everything basically. And the only reason

532
00:45:32,090 --> 00:45:39,290
we finally got it working is that we did a
mistake where we misstook 70 ms with

533
00:45:39,290 --> 00:45:43,710
170 ms and had it run for a long time. And
that's how we found out that the BootROM

534
00:45:43,710 --> 00:45:48,920
is actually super slow to boot on this
device. And once we had this downgrade

535
00:45:48,920 --> 00:45:56,810
from RDP2 to RDP1, we were able to read
the RAM, but we cannot read the flash

536
00:45:56,810 --> 00:46:03,700
which actually contains the seed. And so
how do we find this? And our idea was we

537
00:46:03,700 --> 00:46:08,540
start reviewing the upgrade procedure
because on the Trezor, the way the

538
00:46:08,540 --> 00:46:12,780
bootloader works is, it doesn't require a
PIN or anything to upgrade the firmware,

539
00:46:12,780 --> 00:46:16,390
which makes sense, because let's say you
have a bug in the pin function you want to

540
00:46:16,390 --> 00:46:21,609
somehow be able to get rid of it, right?
And the other thing is if you flash a

541
00:46:21,609 --> 00:46:28,970
fully valid firmware it retains the data,
it retains your seed. if you flash and not

542
00:46:28,970 --> 00:46:35,170
genuine one. It actually will erase your
seed and so on. And the big, and they do a

543
00:46:35,170 --> 00:46:38,990
really good job on the firmware
verification. We reviewed it for days and

544
00:46:38,990 --> 00:46:43,640
days and days and didn't find anything.
But so how does this upgrade procedure

545
00:46:43,640 --> 00:46:48,220
work? how is this seat retained? And so
when you reviewed the relevant code you

546
00:46:48,220 --> 00:46:54,310
see that there is a call to backup
metadata which sounds like it's going to

547
00:46:54,310 --> 00:46:59,859
retain somehow your data. And indeed you
can see that it's literally a mem-copy

548
00:46:59,859 --> 00:47:06,030
from the data on flash we're interested
into RAM. And so our basic procedure

549
00:47:06,030 --> 00:47:11,630
was, we go into bootloader we start the
firmware upgrade and we stop it before the

550
00:47:11,630 --> 00:47:16,599
RAM gets cleared. Because if you finish
the upgrade procedure, the Trezor actually

551
00:47:16,599 --> 00:47:22,390
clears its memory again, which is a very
decent way to do it. But we've found a way

552
00:47:22,390 --> 00:47:25,810
to retain it in RAM. So it turns out that
when you start the firmware upgrade

553
00:47:25,810 --> 00:47:32,880
process, it eventually asks you to verify
to check some of what you just flashed and

554
00:47:32,880 --> 00:47:38,540
it turns out that at this point in time,
the seed is still in RAM and we can read

555
00:47:38,540 --> 00:47:47,410
it out via RDP2. And this is relatively
simple to do once you actually manage to

556
00:47:47,410 --> 00:47:51,780
glitch the device. You basically just run
openocd dump_image, you get an image of

557
00:47:51,780 --> 00:47:57,060
the SRAM and you have the whole RAM
contents and so.

558
00:47:57,060 --> 00:48:04,330
Dmitry: What are we going to do,Thomas?
What high tech hacking tool will be using

559
00:48:04,330 --> 00:48:09,630
today to extract the seed?
Thomas:So we actually before we were

560
00:48:09,630 --> 00:48:14,310
successful, we had hours of talks on the
how do we, how is this seed stored and so

561
00:48:14,310 --> 00:48:18,880
on. But we've found this super
sophisticated seed extraction tool that

562
00:48:18,880 --> 00:48:26,010
only runs on POSIX and POSIX-like systems,
it's called strings.

563
00:48:26,010 --> 00:48:30,140
<i>Laughter</i>
And so basically it turns out that when

564
00:48:30,140 --> 00:48:37,640
you have a firmware dump as we have RAM
dump as we do now, and we go to we just

565
00:48:37,640 --> 00:48:43,550
run strings on the dump. We get a couple
of really nice words and I don't know if

566
00:48:43,550 --> 00:48:49,340
you remember the intro, but this is your
seeds.

567
00:48:49,340 --> 00:48:55,600
<i>Applause</i>
And you might be wondering what this

568
00:48:55,600 --> 00:48:59,900
little number is. This is your pin to the
device.

569
00:48:59,900 --> 00:49:09,020
<i>Laughters</i>
That was a great day. And so Josh, or one

570
00:49:09,020 --> 00:49:16,369
of Josh's employees took all this mess we
created on all desks and made it into this

571
00:49:16,369 --> 00:49:23,600
nice device which is basically a socket
where you put in your chip and then we can

572
00:49:23,600 --> 00:49:28,480
read out the seed and so on.
Dmitry: And all of this stuff including

573
00:49:28,480 --> 00:49:32,600
the board design, FPGA codes, and the
Verilog code that we use, I mean if

574
00:49:32,600 --> 00:49:36,810
somebody wants to, they can apply it and
do the same thing with one of the ICEPICKs

575
00:49:36,810 --> 00:49:41,060
or one of the more open source friendly
FPGA boards. This just happens to be the

576
00:49:41,060 --> 00:49:46,710
one that we all had lying around and could
reproduce the work with. You can go ahead

577
00:49:46,710 --> 00:49:50,848
and do it. I mean we suspect, I think
Thomas said, we suspect you might be able

578
00:49:50,848 --> 00:49:54,910
to do with Arduino as well, because the
actual glitch pulse is only approximately

579
00:49:54,910 --> 00:50:02,061
60 μs or sorry, 6 μs in time. So it's a
relatively slow signal as well, so it

580
00:50:02,061 --> 00:50:08,310
should be relatively repeatable even with
something cheaper than this. But this is a

581
00:50:08,310 --> 00:50:12,200
way to automate this even better and to
not have dangling wires or any of the

582
00:50:12,200 --> 00:50:16,870
small soldering that was required to do it
in situ in the device which we had on the

583
00:50:16,870 --> 00:50:22,109
previous slide. So all of that we're going
to have it on GIthub. And so I think the

584
00:50:22,109 --> 00:50:28,080
final, the final thing.
Thomas: one more thing before we are,

585
00:50:28,080 --> 00:50:35,550
sorry. One more thing. So this breaks a
lot of the Trezor security, but there is

586
00:50:35,550 --> 00:50:41,060
a way to protect your seed against this,
So if you use a passphrase on your device,

587
00:50:41,060 --> 00:50:46,520
the way we understood it, it basically
doesn't allows somebody with hardware

588
00:50:46,520 --> 00:50:51,850
access to steal all your funds. So if you
add a passphrase to your Trezor, a good

589
00:50:51,850 --> 00:50:57,760
passphrase and your machine is not already
owned you can somehow somewhat protect

590
00:50:57,760 --> 00:51:03,220
against this. But a lot of people don't.
So we are really sorry we didn't mean any

591
00:51:03,220 --> 00:51:08,520
harm.
Dmitry: So yeah, that's the conclusion I

592
00:51:08,520 --> 00:51:14,310
would say. So yeah I mean, so all the
stuff we're going to put online, I guess I

593
00:51:14,310 --> 00:51:20,590
said, so you can follow us for the links
on the online. wallet.fail, it's a domain

594
00:51:20,590 --> 00:51:26,420
name, believe it or not, fail is a TLD. So
you can go to github.com/walletfail,

595
00:51:26,420 --> 00:51:32,600
twitter.com/walletfail. You can follow me,
Thomas, and Josh on Twitter as well and

596
00:51:32,600 --> 00:51:36,710
like I said, we'll be releasing all this
stuff so it will go up slowly. Just

597
00:51:36,710 --> 00:51:40,730
because I think when we set out six months
ago we did not expect us to have 100

598
00:51:40,730 --> 00:51:45,619
percent success in everything that we were
planning to do. so that's a first for me

599
00:51:45,619 --> 00:51:48,420
at the very least.
Thomas: The saddest part is that we have

600
00:51:48,420 --> 00:51:54,950
more vulnerabilities to other wallets,
but, only one hour. And so we also have

601
00:51:54,950 --> 00:51:58,720
some stuff to give out so we have the
hardware implant PCBs, we have thousands

602
00:51:58,720 --> 00:52:01,810
of them if you want to get some.
Dmitry: Off to Josh.

603
00:52:01,810 --> 00:52:08,810
Thomas: We even have components for them
for like 100 devices so hit us up and we

604
00:52:08,810 --> 00:52:11,020
can do something. Thank you.

605
00:52:11,020 --> 00:52:21,960
<i>Applause</i>

606
00:52:21,960 --> 00:52:25,650
Herald: Thank you guys, it's an amazing
talk. I feel really inspired to break

607
00:52:25,650 --> 00:52:30,630
things apart in a very creative way. We
have some time left for questions. So if

608
00:52:30,630 --> 00:52:34,720
you have questions, please line up at the
microphones. But first we're going to

609
00:52:34,720 --> 00:52:37,299
start with a question from the Internet.

610
00:52:37,299 --> 00:52:40,239
Signal Angel: Thank you,
I've got two related

611
00:52:40,239 --> 00:52:44,240
questions from the internet. First one,
how hard did you guys laugh when bitify

612
00:52:44,240 --> 00:52:50,599
announced that their Android-based wallet
was unhackable? And second question, have

613
00:52:50,599 --> 00:52:55,510
you had a try to attack larger processors
like ARM-based processors?

614
00:52:55,510 --> 00:53:00,900
Thomas: So maybe let's start with Bitfi.
So we only talk about somewhat secure

615
00:53:00,900 --> 00:53:06,720
wallets, we didn't want to use a Chinese
phone in this talk. So we laughed pretty

616
00:53:06,720 --> 00:53:13,892
hard and we ordered some, but yeah.
Dmitry: And I mean this was covered

617
00:53:13,892 --> 00:53:17,780
extensively. So another guy who you should
follow on Twitter @cybergibbons gave a

618
00:53:17,780 --> 00:53:22,165
talk at hardwear.io on the topic of the
Bitfi. He was summarizing research that

619
00:53:22,165 --> 00:53:25,568
he did in conjunction with a bunch of
other people as well. So if you're

620
00:53:25,568 --> 00:53:27,970
interested in the Bitfi you should go look
at them.

621
00:53:27,970 --> 00:53:30,170
So the second question was about ARM-based

622
00:53:30,170 --> 00:53:35,420
controllers. I mean all of these were
ARM-based. Every single chip as far as I

623
00:53:35,420 --> 00:53:38,989
know that we looked at was was ARM-based
in one way or another.

624
00:53:38,989 --> 00:53:40,210
Thomas: Yeah and there's,

625
00:53:40,210 --> 00:53:44,060
so if you're interested in this, look at
glitching the Nintendo Switch where they

626
00:53:44,060 --> 00:53:48,359
glitch the Tegra used in the Nintendo
Switch, which is very interesting and will

627
00:53:48,359 --> 00:53:52,924
give a lot of inspiration in that
regard, basically.

628
00:53:52,924 --> 00:53:57,206
Herald: Thank you. A question for
microphone 4 please.

629
00:53:57,206 --> 00:54:01,755
Mic 4: Hi, Trezor CPO here, first thank
you for the talk, we worked with you to

630
00:54:01,755 --> 00:54:06,010
fix the issues as soon as are recommend to
prod and if anyone interested in hacking

631
00:54:06,010 --> 00:54:13,733
hardware wallets, we are really interested
in working with the hardware hackers

632
00:54:13,733 --> 00:54:17,940
community and we have a
responsible disclosure program.

633
00:54:17,940 --> 00:54:24,065
you mentioned problems with supply chain
attacks, but gave no solutions, so let me

634
00:54:24,065 --> 00:54:30,109
give you one. Trezor is open source
hardware so you can build your own

635
00:54:30,109 --> 00:54:32,235
from locally sourced components

636
00:54:32,235 --> 00:54:37,949
and if you are paranoid and don't want to
deal with these kind of attacks.

637
00:54:37,949 --> 00:54:44,139
but my question is, is there any
other solution except for building

638
00:54:44,139 --> 00:54:47,259
your own wallet or inspecting
the code to run and

639
00:54:47,259 --> 00:54:50,380
interrogate about basically?

640
00:54:50,380 --> 00:54:55,240
Thomas: First Thank you. One thing we
should mention is that when we looked at

641
00:54:55,240 --> 00:54:59,920
the Trezor code, the reason we had to end
up glitching this chip for three months is

642
00:54:59,920 --> 00:55:04,080
that we couldn't break the firmware
otherwise. So they do a great job. And

643
00:55:04,080 --> 00:55:08,480
it's really awesome.
<i>Applause</i>

644
00:55:08,480 --> 00:55:15,570
Dmitry: Yes. The firmware on the Trezor is
something to look at. I mean I recommend

645
00:55:15,570 --> 00:55:19,580
that, I mean we all do consulting work as
well. And so it's something that I

646
00:55:19,580 --> 00:55:24,740
recommend that people who are interested
in looking at how to prevent certain doom

647
00:55:24,740 --> 00:55:28,445
mitigations and hardware. It's an
excellent project to look at. And so

648
00:55:28,445 --> 00:55:32,390
Trezor should be commended on that. But at
the end of the day it doesn't mean that

649
00:55:32,390 --> 00:55:37,270
the chip that the Trezor uses is secure
against these kinds of attacks. And that's

650
00:55:37,270 --> 00:55:41,369
where we had a fallback to looking for
silicon vulnerabilities against a chip

651
00:55:41,369 --> 00:55:44,928
or, sorry, a wallet like the Trezor.

652
00:55:45,814 --> 00:55:48,032
Josh: I would say on this hygeine side,

653
00:55:48,032 --> 00:55:53,002
this is a very difficult problem,
governments especially have this issue.

654
00:55:53,002 --> 00:55:57,192
You can do cryptographic attestation, but
as we saw with the Ledger nano,

655
00:55:57,192 --> 00:56:01,105
that cryptographic attestation didn't help
verify that the requests were legitimate

656
00:56:01,105 --> 00:56:05,110
against a hardware attack, so there's been
talk about X-raying the board and all this

657
00:56:05,110 --> 00:56:08,540
stuff, but this is still very much an
open problem in hardware security.

658
00:56:08,540 --> 00:56:11,020
Herald: Another question from microphone
3.

659
00:56:11,020 --> 00:56:16,310
Mic: Actually I have a suggestion.
Herald: Make it short, though. Because

660
00:56:16,310 --> 00:56:19,390
usually we just take questions. One
sentence.

661
00:56:19,390 --> 00:56:25,203
Mic: A few MCUs actually have Jtag
connected via hardware fuses.

662
00:56:25,665 --> 00:56:28,530
So this might be useful

663
00:56:28,530 --> 00:56:35,600
at least slow down glitching attacks.
Dmitry: Thanks. I agree. But these are

664
00:56:35,600 --> 00:56:40,764
not Cortex-M microcontrollers I can tell
you that with 100% certainty. It has to do

665
00:56:40,764 --> 00:56:44,109
a lot with the fact that the
microcontrollers that are being used in

666
00:56:44,109 --> 00:56:48,460
these devices, they're built to spec to
the spec that ARM specified that ARM

667
00:56:48,460 --> 00:56:53,800
thinks would be a good set of features for
this class of device or rather for the for

668
00:56:53,800 --> 00:56:57,990
the CPUs for the class of device that they
ended up getting put in. So anything

669
00:56:57,990 --> 00:57:02,950
Cortex-M is gonna to have vulnerabilities
that are more or less like the silicon

670
00:57:02,950 --> 00:57:06,859
vulnerabilities that we have. It's just I
mean if you ask me I think it's a matter

671
00:57:06,859 --> 00:57:11,050
of time just to sit there. I mean
fortunately we had something like 3 months

672
00:57:11,050 --> 00:57:16,770
of just glitching to be able to find find
these bugs. But if you can apply that much

673
00:57:16,770 --> 00:57:22,200
to find it silicon attack you might be
able to find this kind of vulnerability as

674
00:57:22,200 --> 00:57:25,579
well in other Cortex-M products. Only
three minutes.

675
00:57:25,579 --> 00:57:28,940
Herald: All good. Another question from
microphone 4 please.

676
00:57:28,940 --> 00:57:33,933
Mic 4: So obviously as part of your work
you analyzed the firmware of these

677
00:57:33,933 --> 00:57:40,150
devices. Did you find that the firmware 
is in any way obfuscated or encrypted?

678
00:57:40,150 --> 00:57:45,380
Thomas: So basically yep, on these chips
you cannot really encrypt the firmware. On

679
00:57:45,380 --> 00:57:51,000
the ST31 you can encrypt it. But we didn't
have to look at it because the ST31 is not

680
00:57:51,000 --> 00:57:54,710
something you have to break but so no
there was no real obfuscation that we

681
00:57:54,710 --> 00:57:58,780
could see. But we also don't have the code
in the case of letters so I just stared at

682
00:57:58,780 --> 00:58:05,220
IDA pro for hours and yeah.
Herald: The next person on microphone 4.

683
00:58:05,220 --> 00:58:11,310
Mic 4: Hello, did you have a look at the
entropy chip that generates the master

684
00:58:11,310 --> 00:58:14,880
seeds on both of these hardware devices,
and what's your take on that?

685
00:58:14,880 --> 00:58:21,530
Dmitry: I mean, so we already hovered how
the Trezor works. There is only one chip

686
00:58:21,530 --> 00:58:26,760
and it's the STM32 so I know that there
was a known issue with Trezor back in the

687
00:58:26,760 --> 00:58:32,950
day where they weren't seeding the
basically the RNG correctly. But this was

688
00:58:32,950 --> 00:58:37,820
fixed. But for our attacks this wasn't
this wasn't an issue. I mean if you were

689
00:58:37,820 --> 00:58:42,710
concerned about how strong these are, how
strong the random number generators are

690
00:58:42,710 --> 00:58:48,560
for creating a seed you could actually
create a BIP39 wallet outside of any

691
00:58:48,560 --> 00:58:53,539
one of these and then just use them for
their hardware features and get the seed

692
00:58:53,539 --> 00:58:56,326
from outside.
Herald: And if you have a question, do

693
00:58:56,326 --> 00:59:00,170
move to the microphone if you're able to.
But first we have another question from

694
00:59:00,170 --> 00:59:03,937
the Internet.
SA: Thank you. Did you guys see the

695
00:59:03,937 --> 00:59:09,472
dinosaur hiphop zero wallet?
Thomas: No but if you send it to us

696
00:59:09,472 --> 00:59:11,663
we are happy to look at it.
Thomas: Oh you did.

697
00:59:11,663 --> 00:59:14,626
Dmitry: Yeah, we had the it
Josh: The dinosaur hiphop wallet -

698
00:59:14,626 --> 00:59:18,380
Thank you for the kind of trick questions
- So the design of the dinosaur hiphop

699
00:59:18,380 --> 00:59:21,784
wallet was a trezor clone
that we looked at last year.

700
00:59:21,784 --> 00:59:23,928
Thomas: Ah
Josh: Called breaking bitcoin board

701
00:59:23,928 --> 00:59:27,365
so that if we didn't, otherwise
functionally it's a trezor clone

702
00:59:27,365 --> 00:59:30,125
but we stole a lot of the instructions
from dinosaur hiphop

703
00:59:30,125 --> 00:59:33,444
make the breaking bitcoin board
and then prepare the operating system.

704
00:59:33,444 --> 00:59:37,307
Dmitry: I mean, and maybe on that note
I would say that in terms of looking at

705
00:59:37,307 --> 00:59:42,319
what wallets are actually be used you'll
find that, so the Ledger is a very popular

706
00:59:42,319 --> 00:59:44,266
wallet, the Trezor is a very popular

707
00:59:44,266 --> 00:59:50,080
wallet. But since the Trezor is opensource
there is a lot of clones and forks of the

708
00:59:50,080 --> 00:59:55,930
Trezor. And when I say that not all of
them run the latest security patches that

709
00:59:55,930 --> 01:00:00,430
have been applied to the Trezor code base.
So that's also something that you can do

710
01:00:00,430 --> 01:00:04,830
is basically diff the projects and see
which one of them which ones are staying

711
01:00:04,830 --> 01:00:06,169
up to date and which aren't.

712
01:00:06,169 --> 01:00:08,822
Herald: Your question has to be the very
last one today.

713
01:00:08,822 --> 01:00:15,783
Please speak directly into the microphone.
Even closer to the mic.

714
01:00:15,783 --> 01:00:25,322
Mic: Seeing as this is the first CCC for
many of us and some of us might not have

715
01:00:25,322 --> 01:00:29,939
that much experience in hardware hacking.
Do you have any tips for beginners?

716
01:00:29,939 --> 01:00:39,210
Thomas: Yeah lots of them. Buy an Arduino 
learn what mistakes you do with it and

717
01:00:39,210 --> 01:00:44,100
learn how hardware works, basically. Watch
a lot of online videos and I think you

718
01:00:44,100 --> 01:00:48,530
gave presentations, you gave
presentations. I gave some presentations.

719
01:00:48,530 --> 01:00:53,520
So just watch talks, watch LiveOverflow.
LiveOverflow, great YouTube channel on

720
01:00:53,520 --> 01:00:59,619
exactly this stuff. And also don't
hesitate to reach out to us. If you have a

721
01:00:59,619 --> 01:01:04,580
question. Always contact us
info@wallet.fail, on Twitter, wherever. we

722
01:01:04,580 --> 01:01:07,491
are happy to talk to you. It might take a
while.

723
01:01:07,491 --> 01:01:12,043
Josh: On non-security electronics, if you
go to Sparkfun or Adafruit, they have lots

724
01:01:12,043 --> 01:01:15,840
of free material of how electronics work,
how to get started. It's not security

725
01:01:15,840 --> 01:01:18,140
related, but it's a very good
electronics program

726
01:01:18,140 --> 01:01:21,142
Dmitry: But I'll say I started
with Arduino too.

727
01:01:23,642 --> 01:01:27,487
Herald: All right thank you guys so much
for the very nice questions and you guys

728
01:01:27,487 --> 01:01:30,150
for the amazing and inspiring talk.
Thank you so much.

729
01:01:30,150 --> 01:01:31,670
<i>Applause</i>

730
01:01:31,670 --> 01:01:58,000
Subtitles created by c3subtitles.de
in the years 2018-2020. Join, and help us!