[Cryptech Tech] Noise board on Novena

Joachim Strömbergson joachim at secworks.se
Sun Sep 21 06:37:49 UTC 2014


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Aloha!

Good to see you back on the list!

Benedikt Stockebrand wrote:
> Joachim Strömbergson <joachim at secworks.se> writes:

>> The important generic interface for the entropy sources in the
>> TRNG looks like this:
>> 
>> output wire          enabled, output wire          rnd_syn, output
>> wire [31 : 0] rnd_data, input wire           rnd_ack,
>> 
>> [...]
> 
> But this also has a major problem: With 32 bits in parallel this
> needs a fairly serious MCU, which again makes it much easier to
> inject some sort of malware since it offers way more resources.

Ah, yes. I was obviously being confusing. Let me back up:

The entropy providers are responsible for connecting any external noise
(or entropy) source to the TRNG _inside_ the FPGA and provide entropy
data in a systematic way to the mixer. The interface I described above
is between the mixer and any entropy provider and adhering to it will be
easier to integrate. (We can always add a wrapper).

This does not say anything at all about what interface to use between
the entropy provides module _inside_ the fpga and its associated
functionality _outside_ of it. This is where Fredriks SPI interface
comes in and this is where I don't agree that we should demand any
specific interface. We could, and that would make life somewhat easier
for me as the FPGA guy. But the design will be harder to audit and the
entropy sources will be more complex.

Just like any driver in an OS, the backend (towards the HW) can be
standardized (A USB connected thingy) or utterly specific. It is the
drivers responsibility to hide the peculiarities of that backend if and
and present it as a uniform type of interface.

The external interface could be SPI, but could also be I2C, Simple I/O
handshakes to an A/D-converter, a single digital noise pin just like
Fredriks current boards are connected or even Ethernet, RapidIO etc.

(On top of that, I really don't like SPI. ;-)

In short: My opinion is that we should not force a single exrernal
interface type onto entropy source developers. And if we decide to do
so, SPI wouldn't be my choice.


> How much of an effort would it be to reduce this to 8 or maybe even
> only 4 data wires?

Not hard. Just add a demux in the entropy provider module that is going
into the FPGA. And yes, on an AVR you could bitbang the interface above
but with 8 bit data in hundreds of kbps to low Mbps speed.


> And what about doing away with the MCU entirely, and feeding a raw
> noise signal into the FPGA?  I'm aware that the edge detection
> algorithm for the avalanche effect may be of little use to other
> sources (most notably Bernd's ring oscillator) and as such any new
> kind of source will likely need the FPGA code to be adapted again,
> but if there's no MCU then it can't break and it can't be manipulated
> either.

Yes. This is _exactly_ how the avalanche noise entropy provider in the
TRNG works today. I get a single pin with schmitt-triggered 3V3 noise
from Fredriks board and do edge detection, cycle counting etc in the
FPGA. And provide the mixer with the result using the interface above.


>> You can see my first attempt of these interfaces here: 
>> http://trac.cryptech.is/browser/core/trng/src/rtl/trng.v
> 
> Yes yes yes, I'll learn about FPGAs.  Promised.  Next year or so:-)

Scream if there are any things that looks confusing.

- -- 
Med vänlig hälsning, Yours

Joachim Strömbergson - Alltid i harmonisk svängning.
========================================================================
 Joachim Strömbergson          Secworks AB          joachim at secworks.se
========================================================================
-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.22 (Darwin)
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQIcBAEBCAAGBQJUHnI9AAoJEF3cfFQkIuyNojwQAL2UQuM7rqijBukAAdp3a00I
lYUag0lAHNm1ScPkQipRerQbgrBC4g6ize2aSJa5OW6j2g9eh9v7XacCNdvMSAIM
D5jED924gWMGDyvDhr+niF6wPXdit/hO1M8F9Kp7L2/zAK31HPPstOVJbcab9vGv
dIJAT7w+trYKc/SHbg7R6JgrHHgqbx+mthkf2uGqrHjatF+Uxr0z7VSdWrY8Kycy
C2+rhDV3GrBJcEPq2nEMj4Ts6lOPGTyyvQurTcgim0Li9KptT/bua5dhgjJYkQbL
NhD1fgo2BlYf/yI0j+UlW11SZuAxreSPx2ZtauCJRd+EGQs+2AyjszPz3VraAUR6
EMbco9KwB+QLUMCJUROGzQd7BAFcXIDSpkoalEiJVSSJ+UGjCtK/Q8VUSTosVB+T
9ka0dcgtiKlzfXWiyb5bSfNSTSJDQk2+a3goddRQZB+X0FIiGVlpqz31Vk+YCfVa
CLrag5CMqyQCN477mj3y1+2Xg5gbvtKUqPzqpQAUtFAq8ptiIQ5xus62WR0IYgfU
Uc4qpJ/fvtg74XxjVqliH4/qWokkO3t9G2myp9dKyZaHWKvXBiQjU8bIAu0+iD64
XqyXkLbx8/cQc7LUsmmobx+xD1KqtOP3APofwHlX2X9GE1sjakU3/dbYMTM3rc5a
JMpl1uR8XCubtLkPlRsA
=iHvz
-----END PGP SIGNATURE-----


More information about the Tech mailing list