1
00:00:00,113 --> 00:00:02,759
Good morning everyone

2
00:00:02,759 --> 00:00:04,959
Hopefully you're here for the
same reason I am,

3
00:00:04,959 --> 00:00:08,100
to drink coffee - I mean,
to talk about random numbers.

4
00:00:08,100 --> 00:00:13,440
This is not the first time that a talk
about this particular project

5
00:00:13,440 --> 00:00:15,701
has happened at DebConf, in fact

6
00:00:15,701 --> 00:00:19,912
two years ago in Portland
Tom Marble gave a talk

7
00:00:19,912 --> 00:00:26,552
about the need for having good
sources of entropy

8
00:00:26,552 --> 00:00:32,372
and why it was that Keith and I had
begun a project to build a good

9
00:00:32,372 --> 00:00:36,037
high-quality hardware random
number generator.

10
00:00:36,040 --> 00:00:40,284
It so often happens in life we get a
little distracted between then and now

11
00:00:40,316 --> 00:00:46,176
but if we jump to the very end we're at
the point where we have finally

12
00:00:46,206 --> 00:00:48,002
got to a design that we really like

13
00:00:48,106 --> 00:00:53,184
We're in the middle of an initial,
significantly-sized production run

14
00:00:53,184 --> 00:00:57,436
of the devices. Unfortunately best-laid
plans and all that - we had hoped

15
00:00:57,436 --> 00:01:02,151
to be here with the production units,
and I guess at this point we're still two

16
00:01:02,151 --> 00:01:06,408
or three weeks away from actually
being through that first production run.

17
00:01:06,408 --> 00:01:10,061
So we have a handful of devices we
can show people today - we might even

18
00:01:10,061 --> 00:01:14,173
try to demo before we're done - but we
don't have huge quantities of them

19
00:01:14,173 --> 00:01:16,479
to sell yet, which I'm sorry about.

20
00:01:16,479 --> 00:01:19,224
It's a little unfortunate that that's how
things have worked out.

21
00:01:19,224 --> 00:01:23,781
So I guess the first thing I would say
is if you want more

22
00:01:23,781 --> 00:01:27,959
of a theoretical backround on the
point of random numbers

23
00:01:27,959 --> 00:01:32,162
and why they're important in
our computing lives

24
00:01:32,162 --> 00:01:35,010
I would recommend that you go back
and find the video

25
00:01:35,010 --> 00:01:39,204
of the talk that Tom Marble
gave at DebConf in 2014.

26
00:01:39,204 --> 00:01:42,902
We don't have the time or the inclination
to try and repeat all of that today.

27
00:01:43,244 --> 00:01:46,672
This is going to be much more about
the actual thing that we've designed and built.

28
00:01:46,672 --> 00:01:50,780
But I think a little bit of background
is probably worthwhile.

29
00:01:50,780 --> 00:01:54,654
The fundamental thing is that
cryptographic security

30
00:01:54,654 --> 00:01:57,475
really depends on a robust source of entropy.

31
00:01:57,475 --> 00:02:00,680
This is because cryptographic security
depends on our ability to

32
00:02:00,680 --> 00:02:04,566
have keys that people can't trivially
guess, and various other things.

33
00:02:04,566 --> 00:02:09,822
Entropy is the notion of a source of
randomness that can be

34
00:02:09,822 --> 00:02:13,743
applied and taken advantage of
in the rest of the system.

35
00:02:13,743 --> 00:02:18,502
In Linux systems, our source of entropy
is usually this pool

36
00:02:18,502 --> 00:02:23,981
that's inside the kernel, and where it gets
its entropy from varies.

37
00:02:23,981 --> 00:02:28,239
But if you don't have some other
explicit source of random numbers

38
00:02:28,239 --> 00:02:31,575
on the system, it's coming from things
like the timing of keystrokes

39
00:02:31,575 --> 00:02:36,662
or disk operations and things like that
which are reasonably random.

40
00:02:36,664 --> 00:02:41,622
But it's unfortunately the case that most
of the computers we have and use

41
00:02:41,622 --> 00:02:45,141
don't have a robust hardware
source of randomness.

42
00:02:45,163 --> 00:02:47,487
Lots of other people have worked
on this before -

43
00:02:47,487 --> 00:02:49,694
some of the devices that I'm sure
some of you in this room

44
00:02:49,704 --> 00:02:53,114
have stumbled over are things
like the Entropy Key.

45
00:02:53,424 --> 00:02:57,208
That was a lovely device - I had one

46
00:02:57,208 --> 00:02:59,551
- past tense, unfortunately, because
like so many things

47
00:02:59,551 --> 00:03:02,201
I don't have it any more - but I used to.

48
00:03:02,201 --> 00:03:06,046
Unfortunately those are no longer available
and the design wasn't open

49
00:03:06,046 --> 00:03:09,398
so there's no straightforward way
for us to duplicate that.

50
00:03:09,398 --> 00:03:12,816
There are other products which
are interesting and have

51
00:03:12,816 --> 00:03:16,795
various characteristics which we
think are really cool

52
00:03:16,795 --> 00:03:20,240
but for one reason and another
they're just not quite exactly what

53
00:03:20,240 --> 00:03:24,393
we were looking for.
So the goals we had were:

54
00:03:24,393 --> 00:03:28,734
First and most importantly we wanted
a source of truly random bits

55
00:03:28,734 --> 00:03:32,322
and I'll talk a little about what that
means and show you

56
00:03:32,322 --> 00:03:36,284
some of our measurements to try and
prove that we think we've done

57
00:03:36,284 --> 00:03:37,824
the right thing there.

58
00:03:37,824 --> 00:03:41,282
Keith and I also really wanted this
to be automatically useable

59
00:03:41,282 --> 00:03:45,297
in Linux systems.
One of the things that the Entropy Key

60
00:03:45,297 --> 00:03:48,279
developers did a great job of was
ensuring that those of us in Debian

61
00:03:48,279 --> 00:03:52,761
had easy access to packaged software
that was in the distro and you can

62
00:03:52,761 --> 00:03:55,736
just install the right package and you have
the pieces you need to make it all work

63
00:03:55,736 --> 00:03:58,056
and that was really cool.

64
00:03:58,056 --> 00:04:01,180
But when we started thinking about
the things that we wanted to guarantee

65
00:04:01,180 --> 00:04:06,089
and didn't feel the need to guarantee,
and where the trade-off was in our design,

66
00:04:06,089 --> 00:04:10,065
actually making it so that the Linux kernel -
the upstream kernel - could just

67
00:04:10,065 --> 00:04:14,032
do the right thing when it discovered one
of these devices is present

68
00:04:14,032 --> 00:04:17,982
seemed like such a simpler deal, and
something that would make it

69
00:04:17,982 --> 00:04:22,514
much more likely that more people would
be able to actually take advantage of this.

70
00:04:22,514 --> 00:04:25,662
Because we are who we are, it must
be a completely open

71
00:04:25,662 --> 00:04:28,715
hardware and software design, and in fact

72
00:04:28,715 --> 00:04:31,701
when we get to the end of the talk and
you see where we define things,

73
00:04:31,701 --> 00:04:34,920
the schematics, printed circuit board
artwork, bill of materials,

74
00:04:34,920 --> 00:04:39,308
complete source code tree, all that
is available on our web site right now

75
00:04:39,308 --> 00:04:41,992
and in fact it has been for a while.

76
00:04:41,992 --> 00:04:46,272
We want the device to be secure
against software hacks.

77
00:04:46,272 --> 00:04:51,387
What does this mean?
Well, what we've built is a physical

78
00:04:51,387 --> 00:04:55,101
device which plugs into a USB port
and it has a micro-controller

79
00:04:55,101 --> 00:04:57,161
that has code running on it.

80
00:04:57,161 --> 00:05:01,500
When we initially produce the device
we flash that with code.

81
00:05:01,500 --> 00:05:04,547
If you want to re-flash it later,
you can do this any time you want

82
00:05:04,547 --> 00:05:07,333
over USB, using a utility which is
already packaged in Debian

83
00:05:07,333 --> 00:05:10,008
but: you have to take the plastic
cover off the box

84
00:05:10,008 --> 00:05:12,689
and you have to short two holes
in the board together

85
00:05:12,689 --> 00:05:14,941
in order to enable reflashing.

86
00:05:14,941 --> 00:05:19,176
So nobody can randomly spoof 
your device by from some distance

87
00:05:19,176 --> 00:05:21,486
reflashing - you know, if they
break into your system -

88
00:05:21,486 --> 00:05:24,852
they can't just re-flash your random
number generator with some other code.

89
00:05:24,852 --> 00:05:28,637
I guess they could re-flash something else
with your random number generator code

90
00:05:28,637 --> 00:05:31,623
but that's all getting a little whacky.

91
00:05:31,623 --> 00:05:36,554
Our device, at least, can't just be broken
through an attack - a remote attack -

92
00:05:36,554 --> 00:05:38,455
on the software.

93
00:05:38,455 --> 00:05:40,660
And we want it to be as
inexpensive as possible

94
00:05:40,660 --> 00:05:45,132
because again this is all part of
believing that the world needs more entropy

95
00:05:45,132 --> 00:05:48,933
and we'd like lots of people to be
able to afford to use these.

96
00:05:48,933 --> 00:05:53,661
So this is one of those devices where,
on some level, if you get it right you

97
00:05:53,661 --> 00:05:55,458
could charge an arbitrary amount of money

98
00:05:55,458 --> 00:05:59,218
because people who want this want it,
but from our perspective

99
00:05:59,218 --> 00:06:02,834
it's really important to have these
be as widely available as possible.

100
00:06:02,834 --> 00:06:07,228
The one really big decision we made
- and it goes into our thoughts

101
00:06:07,228 --> 00:06:10,444
on open hardware - is that we
are not trying to protect

102
00:06:10,444 --> 00:06:12,870
and make this secure against
hardware attacks.

103
00:06:12,870 --> 00:06:15,912
Fundamentally, if someone has
physical access to your device

104
00:06:15,912 --> 00:06:18,978
we're not guaranteeing what
happens after that.

105
00:06:18,978 --> 00:06:20,999
In particular, as I've already mentioned,

106
00:06:20,999 --> 00:06:24,492
if they have physical access they
could re-flash it at a minimum

107
00:06:24,492 --> 00:06:27,077
but they could also do other
things to it as well.

108
00:06:27,077 --> 00:06:29,835
That also means we've not done things
to try and dramatically

109
00:06:29,835 --> 00:06:32,391
environmentally harden the device:

110
00:06:32,391 --> 00:06:36,255
we don't POT it, we don't do all that
kind of stuff that people sometimes do

111
00:06:36,255 --> 00:06:38,846
when they're trying to make things secure.

112
00:06:38,846 --> 00:06:43,515
In terms of the actual hardware device,
two or two-and-a-half years ago

113
00:06:43,515 --> 00:06:48,317
I designed a prototype and I tried
to do something really clever

114
00:06:48,317 --> 00:06:51,845
in the design of the actual noise source

115
00:06:51,845 --> 00:06:55,422
and as so often happens when you try
to be a little bit clever

116
00:06:55,422 --> 00:06:57,848
it didn't really work right the first time.

117
00:06:57,848 --> 00:07:00,746
For a lot of reasons having to do with
where we were and trying to build a house

118
00:07:00,746 --> 00:07:04,535
and all of this, I got distracted and just
didn't get back to it for a very long time.

119
00:07:04,535 --> 00:07:09,484
Keith picked it up and all of
the hardware work on this since then

120
00:07:09,484 --> 00:07:13,650
has been pretty much led by Keith,
with me and other folks chiming in

121
00:07:13,650 --> 00:07:15,327
from time to time.

122
00:07:15,327 --> 00:07:18,352
So I'm going to let Keith talk about the hardware.

123
00:07:20,832 --> 00:07:27,037
So this is the device that we've built.
It's a tiny little board

124
00:07:27,037 --> 00:07:32,372
about the size of a USB plug
- well, connector.

125
00:07:32,372 --> 00:07:37,566
The design of the board was predicated
on the box that I found.

126
00:07:37,566 --> 00:07:41,360
When you start actually trying to build
hardware it turns out

127
00:07:41,360 --> 00:07:45,798
the hardest thing to do is try to find
a box. A lot of people try and think,

128
00:07:45,798 --> 00:07:47,988
"OK, I'm going to build a device, and then
I'm going to find somebody

129
00:07:47,988 --> 00:07:50,119
to manufacture an enclosure for me".

130
00:07:50,119 --> 00:07:53,862
Well, if you're build a million of them,
that's pretty plausible - I mean

131
00:07:53,862 --> 00:07:57,899
look at Buddy Huang's articles
on his adventures in getting injection

132
00:07:57,899 --> 00:08:00,893
moulding for his laptop prototypes, right?

133
00:08:00,893 --> 00:08:05,970
It was like, "OK, so in the ninety-ninth
iteration of a machined metal enclosure

134
00:08:05,970 --> 00:08:11,378
or mould, we eventually got the things to
work", right, so that cost about

135
00:08:11,378 --> 00:08:13,411
a bazillion dollars.

136
00:08:13,411 --> 00:08:15,767
So we found this tiny little enclosure.

137
00:08:15,767 --> 00:08:19,002
And I thought "OK, how can I get something
to fit in this tiny little enclosure?"

138
00:08:19,002 --> 00:08:24,402
Well, the first design that we did
with the new noise source

139
00:08:24,402 --> 00:08:26,828
fitted this size enclosure.

140
00:08:26,828 --> 00:08:31,094
The reason for that is the processor
is huge - look at the size of that processor.

141
00:08:31,094 --> 00:08:34,442
It's almost a centimetre on a side.

142
00:08:37,562 --> 00:08:39,749
And the funny thing is that very same
processor is advertised

143
00:08:39,749 --> 00:08:45,442
in a much more reasonable,
plausibly-sized package.

144
00:08:45,442 --> 00:08:49,069
So this package is about
four millimetres on a side

145
00:08:49,069 --> 00:08:53,031
and you can see it - oops,
Bdale will go back

146
00:08:53,031 --> 00:08:56,319
You can see the processor
in the upper-right hand corner there,

147
00:08:56,319 --> 00:08:59,290
it's about four millimetres square.
And so I was actually able to lay out

148
00:08:59,290 --> 00:09:02,521
the board to fit in this tiny little box.
Which was pretty cool.

149
00:09:02,521 --> 00:09:05,932
Because the problem with this box
is that it's too wide

150
00:09:05,932 --> 00:09:08,356
so if you have two USB connectors
in your laptop next to each other

151
00:09:08,356 --> 00:09:10,201
you can't use both of them

152
00:09:10,201 --> 00:09:11,988
and that was, like, "well that's going to suck".

153
00:09:11,988 --> 00:09:14,159
So I manage to get it to fit
in this tiny little box.

154
00:09:14,159 --> 00:09:16,788
The other interesting part
of course is that Bdale's design

155
00:09:16,788 --> 00:09:21,827
had a really fun noise source -
a little zener diode, a reverse-biased

156
00:09:21,827 --> 00:09:24,575
zener diode - and then of course

157
00:09:24,575 --> 00:09:28,996
Bdale being an actual electrical
engineer - unlike me - designed

158
00:09:28,996 --> 00:09:31,791
an amplifier with a transistor in it,
and I looked at that and said

159
00:09:31,791 --> 00:09:34,948
"Ah, a transistor, scary!"
(audience laughter)

160
00:09:34,948 --> 00:09:41,318
I really did. Because getting
a transistor to operate in a linear mode -

161
00:09:41,318 --> 00:09:45,585
I understand that it's theoretically possible
(audience laughter)

162
00:09:45,585 --> 00:09:51,221
but my training in college
on electrical circuits was

163
00:09:51,221 --> 00:09:54,995
a single physics lab that involved op-amps.

164
00:09:54,995 --> 00:09:57,188
So I know how to do op-amp stuff.

165
00:09:57,188 --> 00:10:01,454
So I replaced his awesome transistor
amplifier with an op-amp, because

166
00:10:01,454 --> 00:10:06,658
that's what I'm capable of understanding,
because I'm a wimp.

167
00:10:06,658 --> 00:10:09,514
You know, software engineer trying
to play hardware.

168
00:10:09,514 --> 00:10:16,212
So there's an op-amp here, kind of
in between the two holes.

169
00:10:16,212 --> 00:10:20,196
And in the upper centre is
the actual noise source,

170
00:10:20,196 --> 00:10:24,887
a six-pin package with two transistors in it.

171
00:10:24,887 --> 00:10:29,475
And in the lower right corner is a
twenty-volt power supply,

172
00:10:29,475 --> 00:10:34,419
so caution - if you open the device up,
you could possibly shock yourself

173
00:10:34,419 --> 00:10:37,445
with about a milli-amp at twenty volts.

174
00:10:37,445 --> 00:10:39,845
Or fry your machine, if you feed
twenty volts back into USB.

175
00:10:39,845 --> 00:10:44,291
So it isn't as harmless
a device as it looks.

176
00:10:44,291 --> 00:10:46,622
I mean, I wish I could have put,
like, a kilovolt on it

177
00:10:46,622 --> 00:10:49,683
to really give you a warning.

178
00:10:49,683 --> 00:10:53,624
There you go, physical security -
it could attack you if you try to open it.

179
00:10:53,624 --> 00:10:55,315
(laughter)

180
00:10:56,120 --> 00:10:59,183
So the box now fits in
this tiny little package.

181
00:10:59,183 --> 00:11:04,810
The noise generator we actually lifted
from the OneRNG - the New Zealand

182
00:11:04,810 --> 00:11:07,167
team that's doing a noise source.

183
00:11:07,167 --> 00:11:09,605
Is that where the noise source is from?

184
00:11:09,605 --> 00:11:11,302
I think so, yeh.

185
00:11:11,302 --> 00:11:17,387
So the left-hand side of the circuit
is all just a twenty-volt power supply.

186
00:11:17,387 --> 00:11:19,496
All those pieces.

187
00:11:19,496 --> 00:11:23,969
And on the right of R3 - that's
the noise generator.

188
00:11:23,969 --> 00:11:28,390
It's really just two transistors in
the bizzarest circuit you'll ever see.

189
00:11:28,390 --> 00:11:31,769
Isn't that awesome?

190
00:11:31,769 --> 00:11:34,158
It's actually the left-hand transistor
that's the noise source -

191
00:11:34,158 --> 00:11:37,620
the right-hand transistor is
just giving a little bit of buffering.

192
00:11:37,620 --> 00:11:41,307
So it's really just that connection
between the emitter and the base

193
00:11:41,307 --> 00:11:45,228
of that transistor.
It's a reverse-biased P-N junction

194
00:11:45,228 --> 00:11:47,336
generating noise, and then
and emitter-follower

195
00:11:47,336 --> 00:11:49,574
buffering and amplifying it
just slightly.

196
00:11:49,574 --> 00:11:51,235
And then we run that through a capacitor.

197
00:11:51,235 --> 00:11:53,343
So out of that we get about
ten millivolts of noise

198
00:11:53,343 --> 00:11:56,027
and then we run that through an op-amp,
amplify it and then through an ADC.

199
00:11:56,027 --> 00:12:01,268
The awesome part is that when
you just look at the output of that

200
00:12:01,268 --> 00:12:04,570
from the ADC - here's a histogram of
values from that, it's like

201
00:12:04,570 --> 00:12:10,688
"Oh, that's a lovely little kind of
perfect normal distribution of noise".

202
00:12:10,688 --> 00:12:14,189
So you can actually see that we're generating
a fairly nice distribution of values.

203
00:12:14,189 --> 00:12:17,783
Of course this is not what you want
if you want a random number, right?

204
00:12:17,783 --> 00:12:20,751
Random numbers are
not normally distributed.

205
00:12:20,751 --> 00:12:23,639
If you want an evenly-distributed
random number

206
00:12:23,639 --> 00:12:25,871
you don't want normal distribution.

207
00:12:25,871 --> 00:12:29,043
This is what a plot of about two thousand
points looks like

208
00:12:29,043 --> 00:12:33,336
and you can see that it's kind of
biased towards the centre.

209
00:12:33,336 --> 00:12:37,958
However, the good news is that
if you just take this data

210
00:12:37,958 --> 00:12:39,332
and run it through an FFT

211
00:12:39,332 --> 00:12:42,934
you'll notice that the frequency
response is nice and flat -

212
00:12:42,934 --> 00:12:44,911
or chaotic, as the case may be -

213
00:12:44,911 --> 00:12:47,859
run chaos through an FFT and
you get chaos out.

214
00:12:47,859 --> 00:12:49,972
But it's nice and flat, so
we know that we don't have

215
00:12:49,972 --> 00:12:54,336
a frequency response problem, which we
did in the earlier circuit.

216
00:12:54,336 --> 00:12:58,120
The big problem with my original
design is that the biasing of the

217
00:12:58,120 --> 00:13:00,426
reverse-biased zener was a little off

218
00:13:00,426 --> 00:13:03,172
and as a result it was very susceptible
to low-frequency noise

219
00:13:03,172 --> 00:13:08,094
and there was a source of low-frequency
noise about a millimetre away.

220
00:13:08,094 --> 00:13:10,694
I would have fixed it eventually, maybe.

221
00:13:10,694 --> 00:13:13,697
I did the cheap thing and applied an op-amp!

222
00:13:13,697 --> 00:13:17,027
And now we have a working product
- it's all good!

223
00:13:17,027 --> 00:13:18,794
This is how we work together by the way -

224
00:13:18,794 --> 00:13:21,620
we sort of, you know, give each other crap
until somebody breaks down

225
00:13:21,620 --> 00:13:23,536
and spends the time to fix something.

226
00:13:23,536 --> 00:13:25,499
Well the awesome part is that
Bdale has been very patient

227
00:13:25,499 --> 00:13:29,329
at letting me design hardware - I think
this is the fifth version of the board.

228
00:13:29,329 --> 00:13:33,202
I'm a software guy, right?
How do you do software design? You iterate.

229
00:13:33,202 --> 00:13:35,646
And you know, release early and often.

230
00:13:35,646 --> 00:13:39,259
But then every iteration takes - instead of
ten minutes like a software iteration -

231
00:13:39,259 --> 00:13:42,875
it takes like two weeks, because you have
to send it off to the PCB fabrication place

232
00:13:42,875 --> 00:13:44,670
and then the boards come back
and you put parts on

233
00:13:44,670 --> 00:13:48,674
and then you think, "Man, that was stupid!
Why did I hook up that connection backwards?"

234
00:13:48,674 --> 00:13:50,492
In software you just go change the software.

235
00:13:50,492 --> 00:13:53,643
Hardware: two weeks later
and you get to try again.

236
00:13:53,643 --> 00:13:56,768
So I'm slowly learning how to do hardware
but I'm still terrible at it.

237
00:13:56,768 --> 00:14:01,285
So we built this noise source.
We need to make sure it's actually random

238
00:14:01,285 --> 00:14:04,366
because if you have something that looks
random, and dump it in your computer

239
00:14:04,366 --> 00:14:06,846
and it's not actually random, and
actually turns out to be predictable,

240
00:14:06,846 --> 00:14:09,459
then you've kind of lost already.

241
00:14:09,459 --> 00:14:12,695
So there's a bunch of stuff that
we've done on this thing.

242
00:14:12,695 --> 00:14:15,625
There are the FIPS standards - which are
hilarious, you should read

243
00:14:15,625 --> 00:14:17,789
the FIPS standards on random numbers.

244
00:14:17,789 --> 00:14:21,885
The FIPS 140-2 Standard for Random Numbers
literally says,

245
00:14:21,885 --> 00:14:27,115
"OK, just make sure that the chunk of data
that you're sending never repeats".

246
00:14:27,115 --> 00:14:29,991
That's the entire standard - all that
it requires of random numbers

247
00:14:29,991 --> 00:14:33,121
is that you never reproduce
the same value twice.

248
00:14:33,121 --> 00:14:43,186
Don't say "4444" - that's wrong -
but "43214321": that's perfectly OK.

249
00:14:43,186 --> 00:14:49,930
But the standard is... yeh, ridiculous.
It's a federal standard.

250
00:14:49,930 --> 00:14:54,454
So nobody actually falls to that
lower standard that we're aware of.

251
00:14:54,454 --> 00:14:58,507
But the point is that in the standard
there's some discussion about

252
00:14:58,507 --> 00:15:01,043
what it means to be random,
that's not very useful,

253
00:15:01,043 --> 00:15:03,362
and there's a bunch of discussion
about sort of how do you know

254
00:15:03,362 --> 00:15:05,760
that you have a device that's OK
to actually use.

255
00:15:05,760 --> 00:15:09,070
And some of those bits are useful.

256
00:15:09,070 --> 00:15:13,810
In particular, when I first
flash the device during production

257
00:15:13,810 --> 00:15:17,142
I do a bunch of tests on it to make sure
that the values are coming out random.

258
00:15:17,142 --> 00:15:19,568
I do the FFT tests, I do a bunch
of other tests to make sure

259
00:15:19,568 --> 00:15:23,180
the circuit was constructed as we expect.

260
00:15:23,180 --> 00:15:25,620
Because one of the big problems
with physical hardware

261
00:15:25,620 --> 00:15:28,555
is that you don't have perfect replication.

262
00:15:28,555 --> 00:15:32,587
Actually the first - I made a bunch of
these boards and got a bunch of parts

263
00:15:32,587 --> 00:15:37,543
and built them all, only to discover that
the parts supplier sent me the wrong parts

264
00:15:37,543 --> 00:15:40,386
for the noise source.
I don't know what they sent me

265
00:15:40,386 --> 00:15:43,241
but it wasn't a transistor.

266
00:15:43,241 --> 00:15:51,008
It was even the wrong package.
And I still need to send the wrong thing

267
00:15:51,008 --> 00:15:53,600
back to them so they can
close up the final bill.

268
00:15:53,600 --> 00:15:56,116
It was funny - I built the device
and I plugged it in

269
00:15:56,116 --> 00:15:58,634
and my production test said
"No, that's broken".

270
00:15:58,634 --> 00:16:01,468
I'm, like, "how can that be broken?"
and I looked at the noise source

271
00:16:01,468 --> 00:16:04,325
and it looked like, "oh, that's not
actually generating random numbers

272
00:16:04,325 --> 00:16:05,670
at all."

273
00:16:05,670 --> 00:16:08,133
So we do a bunch of production tests
which are extensive and make sure

274
00:16:08,133 --> 00:16:10,586
the device operates with
the right behaviour.

275
00:16:10,586 --> 00:16:12,674
When the device powers on -
the first time you plug it in -

276
00:16:12,674 --> 00:16:15,917
we do some testing as a
kind of real sanity check

277
00:16:15,917 --> 00:16:18,283
(The production test is all
in the source tree, right?)

278
00:16:18,283 --> 00:16:23,587
We haven't quite finished it...
I have some ideas about how it might work.

279
00:16:23,587 --> 00:16:27,129
What we do with all of our products though
is there are turn-on test scripts for them

280
00:16:27,129 --> 00:16:29,960
including the rocket avionics stuff
all in the source tree

281
00:16:29,960 --> 00:16:33,852
so eventually when it's all folded
in the right place, if you want -

282
00:16:33,852 --> 00:16:35,188
I still have two weeks, right?

283
00:16:35,188 --> 00:16:36,913
You still have two weeks.
- Awesome.

284
00:16:36,913 --> 00:16:38,477
Just-in-time software.

285
00:16:38,477 --> 00:16:41,675
As with everything else we do,
not just the hardware design

286
00:16:41,675 --> 00:16:44,707
but how we go about turning them on,
what our production test process is

287
00:16:44,707 --> 00:16:48,042
all of that is also open, so
if you want to look at it

288
00:16:48,042 --> 00:16:50,026
and provide feedback or comments
or suggest something different

289
00:16:50,026 --> 00:16:52,180
you're always welcome to have input.

290
00:16:52,180 --> 00:16:54,917
I've actually been working with a friend
of mine who is a Professor

291
00:16:54,917 --> 00:16:57,430
at Portland State where we had DebConf
a couple of years ago -

292
00:16:57,430 --> 00:17:00,914
he's got some students off generating
some useful tests.

293
00:17:00,914 --> 00:17:06,355
There is an interesting random number
generator test - I don't remember the name

294
00:17:06,355 --> 00:17:11,481
It's a huge long suite of tests that I've
run on this thing and it passes that fine.

295
00:17:11,481 --> 00:17:16,701
It says that there are 7.99992 bits
of entropy per byte.

296
00:17:16,701 --> 00:17:19,330
I don't know why it doesn't think
there are eight, but I guess

297
00:17:19,330 --> 00:17:21,999
getting all the way to eight is hard
or something.

298
00:17:21,999 --> 00:17:23,251
Random round-off there?

299
00:17:23,251 --> 00:17:24,958
Yeh, random round-off, probably.

300
00:17:24,958 --> 00:17:28,420
And then as the device is running it's
constantly testing the data generated

301
00:17:28,420 --> 00:17:30,678
to make sure that it looks pretty random.

302
00:17:30,678 --> 00:17:35,089
What we're doing with that is currently
I actually just make sure the normal

303
00:17:35,089 --> 00:17:41,103
distribution looks like a bell-curve, looks
reasonable and isn't spiky or something.

304
00:17:41,103 --> 00:17:45,356
I want to do kind of a point FFT to make
sure the frequency doesn't look

305
00:17:45,356 --> 00:17:49,012
like you just have a sine wave , which
is a common failure mode in the hardware

306
00:17:49,012 --> 00:17:53,738
because if the transistor goes
"catty-walkers" sometimes you just get -

307
00:17:53,738 --> 00:17:57,478
you're just picking up noise from
the environment and you get a sine wave out

308
00:17:57,478 --> 00:18:01,177
which is not very random.
So we do online tests, we do power on tests

309
00:18:01,177 --> 00:18:05,009
and then we do production tests.
That's how we're making sure it's random.

310
00:18:05,009 --> 00:18:08,180
And you also mentioned that you're using
the CRC generator to whiten? Or not?

311
00:18:08,180 --> 00:18:17,084
Yes. Yeh, so as we said the noise right
here is normally distributed - the values

312
00:18:17,084 --> 00:18:20,256
that I'm getting out of the noise source
source are randomly distributed.

313
00:18:20,256 --> 00:18:24,978
What we discovered was that the middle
eight bits are completely random

314
00:18:24,978 --> 00:18:29,764
and as you can see these are about twelve
or thirteen bits of data coming out

315
00:18:29,764 --> 00:18:35,246
so that we get values from zero to 4096,
centred around 2048.

316
00:18:35,246 --> 00:18:42,458
So, how many bits is that? Thirteen bits?
Twelve bits, OK.

317
00:18:42,458 --> 00:18:46,914
So we have twelve bit values
distributed around, but if you throw away

318
00:18:46,914 --> 00:18:51,198
the top bit then the bottom eight bits
are really quite flat.

319
00:18:51,198 --> 00:18:54,136
We could have just used the bottom eight
bits for our noise source

320
00:18:54,136 --> 00:18:56,696
and that would probably would
have worked fine.

321
00:18:56,696 --> 00:19:00,839
What I did instead was the chip - as
with many SoCs - has random extra

322
00:19:00,839 --> 00:19:05,231
functional units, so one of the things
it has is a CRC32 generator in hardware

323
00:19:05,231 --> 00:19:10,515
so you dump data in and you pull data out,
you know, one instruction in and one out

324
00:19:10,515 --> 00:19:17,340
so I took all sixteen bits out of the
the noise value that I read from the ADC

325
00:19:17,340 --> 00:19:20,418
and I dump that in the CRC generator
and pull eight bits out

326
00:19:20,418 --> 00:19:24,497
and because I know that the noise source
has at least eight bits of entropy.

327
00:19:24,497 --> 00:19:28,693
I know that it's a valid thing to do,
because whichever eight bits I pull out

328
00:19:28,693 --> 00:19:30,156
they're going to be random.

329
00:19:30,156 --> 00:19:32,841
So we're using that CRC to kind of
whiten or flatten that data, so that

330
00:19:32,841 --> 00:19:35,013
we get truly flat data.
This is actually of course a plot from

331
00:19:35,013 --> 00:19:43,513
the raw source, but if you look
at the plot from the whitened source,

332
00:19:43,513 --> 00:19:47,196
it's completely flat - all of the values
are evenly distributed.

333
00:19:47,196 --> 00:19:49,706
It's normally distributed randomness,
which you can get into arguments

334
00:19:49,706 --> 00:19:52,372
with people about whether it's
really random, but what you seem

335
00:19:52,372 --> 00:19:57,565
to really want in the cryptographic world
is a uniform distribution of values

336
00:19:57,565 --> 00:20:00,110
which are not predictable.

337
00:20:00,110 --> 00:20:08,710
So to wrap things up, I already mentioned
we have an initial production run of

338
00:20:08,710 --> 00:20:11,603
a thousand of these currently underway.

339
00:20:11,603 --> 00:20:14,553
I've been asked by a couple of people
where we're having them built.

340
00:20:14,553 --> 00:20:20,898
To explain just briefly, the micro-controller
chip we chose is one from ST Micros that

341
00:20:20,898 --> 00:20:26,876
we've used for some other things.
It's a tiny little - this one's a Cortex 0?

342
00:20:26,876 --> 00:20:27,648
Yeh.

343
00:20:27,648 --> 00:20:32,343
And it has 32K of flash, and it has a
tiny little in-built USB bootloader thing.

344
00:20:32,343 --> 00:20:35,912
So we're actually having these
manufactured in Shenzhen in the first run

345
00:20:35,912 --> 00:20:38,474
and a lot of folks are "Oh my God, China,
you're letting the Chinese touch your

346
00:20:38,474 --> 00:20:41,794
crypto-related stuff."
Well the answer is we're not having them

347
00:20:41,794 --> 00:20:45,689
flash anything. The boards come to us
and we're doing the flash and the

348
00:20:45,689 --> 00:20:50,390
production tests. So I guess on some level
of theoreticalness somebody could be

349
00:20:50,390 --> 00:20:54,138
putting different chips in them than
the ones we actually asked for and

350
00:20:54,138 --> 00:20:57,942
spoofing us at a very deep hardware level.
But I kind of doubt it.

351
00:20:57,942 --> 00:21:03,175
Frankly at some point you have to decide
where in this chain of importance versus

352
00:21:03,175 --> 00:21:06,739
ridiculousness you want to fall.
I certainly don't want to start with sand

353
00:21:06,739 --> 00:21:12,500
and a heat source to make chips, so
we think this is a pretty reasonable place

354
00:21:12,500 --> 00:21:16,938
because we're not relying on anybody else
to put the code in that's on the device

355
00:21:16,938 --> 00:21:19,358
when we ship them.
By the way, the reason that we think

356
00:21:19,358 --> 00:21:24,369
we meet FIPS level 2 is that it has to be
"tamper-evident", and you have to cut

357
00:21:24,369 --> 00:21:29,323
the label to get the box apart, and it's
almost impossible to cut these labels

358
00:21:29,323 --> 00:21:35,460
without just sort of destroying them,
so... eh, we think it's tamper evident.

359
00:21:35,460 --> 00:21:37,823
It's certainly not tamper-proof.

360
00:21:37,823 --> 00:21:41,401
We do expect to have this production run
delivered to us in the next couple of weeks

361
00:21:41,401 --> 00:21:45,165
- as I said we really just missed
having them in time to be here.

362
00:21:45,165 --> 00:21:48,586
We really had hoped to be here
with a big bag of them

363
00:21:48,586 --> 00:21:51,436
for anybody who's interested.

364
00:21:51,436 --> 00:21:55,551
Oh, we decided to set the quantity one
price at US $40

365
00:21:55,551 --> 00:22:00,031
and then to discount for quantity.
If people are interested in

366
00:22:00,031 --> 00:22:03,658
real quantities of them, let me know
and we can talk about that.

367
00:22:03,658 --> 00:22:09,503
I have somewhere in my bag in my notebook
a set of proposed quantity discounts.

368
00:22:09,503 --> 00:22:13,827
Our goal here is really to make sure that
people have access to high-quality

369
00:22:13,827 --> 00:22:18,005
sources of entropy and we really hope
this ends up being something

370
00:22:18,005 --> 00:22:20,604
that lots of people are having.

371
00:22:20,604 --> 00:22:24,482
We do have a few more of these which
are sort of, you know, we had a small run

372
00:22:24,482 --> 00:22:29,333
done by our manufacturer to validate
their prodution processes.

373
00:22:29,333 --> 00:22:32,017
We have a few more of those if
somebody really desperately needs

374
00:22:32,017 --> 00:22:35,647
to have one today. But because we
only have a few, if you're really interested

375
00:22:35,647 --> 00:22:39,468
the right thing to do would be to watch
chaoskey.org, and we will change

376
00:22:39,468 --> 00:22:42,912
the status at the top of that page
to indicate when we have them for sale

377
00:22:42,912 --> 00:22:48,424
and I'm happy to stick them in envelopes
or boxes or whatever and send them out.

378
00:22:48,424 --> 00:22:52,424
So with that, I guess we're pretty much
done with the content part of this

379
00:22:52,424 --> 00:22:54,118
and we'd be happy to take any questions.

380
00:22:55,794 --> 00:22:58,609
(audience)
I'll take fifty! (laughter)

381
00:22:58,609 --> 00:23:01,199
We don't have that many with us today.

382
00:23:01,199 --> 00:23:05,816
The one thing that I'm trying to do right
now is to get the drivers in the Stretch kernel

383
00:23:05,816 --> 00:23:11,227
but it's not in the stable kernel, so I
need to backport the driver to the stable

384
00:23:11,227 --> 00:23:18,127
kernel so the DSA folks will be happy.
It's a completely separate driver, so

385
00:23:18,127 --> 00:23:23,247
I can either construct just a package
which has the driver that you could load,

386
00:23:23,247 --> 00:23:28,127
or I could merge the patch into the current
stable kernel and just deliver it as part

387
00:23:28,127 --> 00:23:32,597
of the kernel package - does anybody
have any preference?

388
00:23:33,852 --> 00:23:36,367
Could you just use RNGD?

389
00:23:36,367 --> 00:23:39,223
We don't need to use RNGD, it's
built directly into the kernel.

390
00:23:39,223 --> 00:23:41,671
We don't need any external applications.

391
00:23:43,851 --> 00:23:45,945
Microphone please, aba.

392
00:23:45,945 --> 00:23:49,809
OK, I am the first to take a microphone
but the cameras can see me.

393
00:23:49,809 --> 00:23:54,105
So does it work with the backports kernel
because that might be enough?

394
00:23:55,034 --> 00:23:58,169
The driver should just compile - it's
just a USB driver, so there's nothing

395
00:23:58,169 --> 00:23:59,874
magic in it.

396
00:23:59,874 --> 00:24:02,078
But it is not in the stable
kernel yet -

397
00:24:02,078 --> 00:24:04,351
What version is the backports kernel?
We don't know.

398
00:24:04,351 --> 00:24:06,438
It's just basically the same as testing.

399
00:24:06,438 --> 00:24:10,189
Oh, then it's already in
the backports kernel.

400
00:24:10,189 --> 00:24:15,383
I think that DSA wanted to have it in
the stable kernel, yes?

401
00:24:15,383 --> 00:24:16,977
Yes.

402
00:24:16,977 --> 00:24:19,999
And Keith also mentioned that people
have asked us, "well gee, you'll have your

403
00:24:19,999 --> 00:24:24,651
own kernel driver?" Well, yeh, I guess,
except he's already accepted a USB

404
00:24:24,651 --> 00:24:29,678
VID/PID pair from somebody else who
wanted to just use that driver with

405
00:24:29,678 --> 00:24:34,462
their source of entropy. So if that
ends up being a standard approach

406
00:24:34,462 --> 00:24:38,083
people take for building more
and diverse things.

407
00:24:38,083 --> 00:24:40,687
And you recently took a change or are
working on a change or something

408
00:24:40,687 --> 00:24:45,479
so that the kernel will accept and blend
data from multiple sources of hardware

409
00:24:45,479 --> 00:24:49,202
randomness - in the past it's been,
you know, pick the most random-looking

410
00:24:49,202 --> 00:24:50,634
thing and use it -

411
00:24:50,634 --> 00:24:52,263
No, the most recently-attached thing.

412
00:24:52,263 --> 00:24:56,139
The most recently-attached thing. So
we generally believe that another way

413
00:24:56,139 --> 00:25:00,209
to sort of help you deal with the possible
- so if somebody walked up and stuck

414
00:25:00,209 --> 00:25:03,644
something random into your machine -
ha ha, you see what I did there -

415
00:25:03,644 --> 00:25:07,532
is that if you had a known good source
of randomness on the machine already

416
00:25:07,532 --> 00:25:11,290
and you were interleaving the bits
that you get from all of them

417
00:25:11,290 --> 00:25:15,148
it would just make it exponentially
hard for anybody to really spoof

418
00:25:15,148 --> 00:25:16,505
your random number generator.

419
00:25:17,254 --> 00:25:19,741
And of course the kernel's been doing
its own thing - I don't know

420
00:25:19,741 --> 00:25:23,385
on any given day exactly what happens
between the entropy pool and the bits

421
00:25:23,385 --> 00:25:25,988
that are delivered by /dev/random and
/dev/urandom.

422
00:25:25,988 --> 00:25:28,496
That's been written about elsewhere -
Greg Kroah-Hartman had an article

423
00:25:28,496 --> 00:25:31,029
which was referenced by Tom Marble
in his Portland talk.

424
00:25:32,398 --> 00:25:32,991
Andy?

425
00:25:33,654 --> 00:25:38,102
So, hardware RNGs are notorious for
temperature stability problems.

426
00:25:38,102 --> 00:25:42,659
First of all, are you monitoring
temperature to determine whether

427
00:25:42,659 --> 00:25:45,223
you are drifting?

428
00:25:45,223 --> 00:25:49,918
And second, have you tested across
temperature ranges?

429
00:25:49,918 --> 00:25:52,274
It's been tested across some amount
of temperature range

430
00:25:52,274 --> 00:25:57,829
because Keith and I have entirely
different environmental desires personally

431
00:25:57,829 --> 00:25:59,453
(laughter)

432
00:25:59,453 --> 00:26:04,370
He's in a couple of layers of jacket
and I am not.

433
00:26:04,370 --> 00:26:11,651
But no, we have not done that.
We probably should.

434
00:26:11,651 --> 00:26:13,501
Yes, it would be easy.

435
00:26:13,501 --> 00:26:18,741
There is at least one temperature
sensing point on this device already.

436
00:26:18,741 --> 00:26:20,309
Isn't there?

437
00:26:20,309 --> 00:26:23,241
I don't think so.
I don't know if this one does or not.

438
00:26:23,241 --> 00:26:26,485
It's a good question, Andy.
I don't know the answer.

439
00:26:26,485 --> 00:26:30,475
Certainly testing it across a broader range
is not a terribly hard thing to do.

440
00:26:30,475 --> 00:26:34,550
Again, it's completely open hardware
design. We would love for all of you


441
00:26:34,550 --> 00:26:36,931
to go take a look and tell us what a
bunch of idiots we are.

442
00:26:36,931 --> 00:26:39,039
Of course it would be nice if we'd sold
at least a few of the thousand

443
00:26:39,039 --> 00:26:42,154
before we found that out.
(laughter)

444
00:26:42,154 --> 00:26:43,799
OK, any other questions?

445
00:26:45,528 --> 00:26:52,454
If you compare the Entropy Key, which has
the EGD daemon, that would distribute

446
00:26:52,454 --> 00:26:57,416
randomness and make it easier to transport
randomness to a virtual machine

447
00:26:57,416 --> 00:26:59,721
or something like that. Have you -

448
00:26:59,721 --> 00:27:03,788
So if you have a kernel that has an
essentially infinitely deep well of entropy

449
00:27:03,788 --> 00:27:07,205
I would assume that you could figure
out some way to happily pump

450
00:27:07,205 --> 00:27:11,149
the bits to other machines. Using the same
daemon and just saying "trust the

451
00:27:11,149 --> 00:27:15,264
local kernel to have a lot of randomness",
then...

452
00:27:15,264 --> 00:27:22,178
And we can keep a full-speed USB
pipe full, which is not quite

453
00:27:22,178 --> 00:27:27,249
a megabyte per second in actual
throughput. It's like a megabyte

454
00:27:27,249 --> 00:27:30,833
per second-ish of randomness.

455
00:27:30,833 --> 00:27:33,888
Our time is up, so thank you very much.

456
00:27:33,888 --> 00:27:38,499
We appreciate your time and attention.
(audience applause)