[Cryptech Tech] HWRNG specs
Joachim Strömbergson
joachim at secworks.se
Mon Dec 8 20:10:02 UTC 2014
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Hi Olli!
Thanks for showing interest in Cryptech. Your Pidgin project looks very
interesting.
Olli Ottela wrote:
> I spotted a picture of Cryptech HWRNG from ioerror's twitter wall.
> I'm working on a high-assurance Pidgin (https://github.com/maqp/tfc)
> that uses one-time pads and one-time MACs to provide information
> theoretical security (a cascading encryption version also exists).
> Since a lot of truly random data is required I'd be very interested
> to learn more about your project, about how open source the hardware
> is, at what speed can entropy be sampled, how Ent and Dieharder have
> evaluated the output. The cost is something to consider aswell: TFC
> already requires users invest in hardware.
(It was probably my picture you saw. The same as this ;-)
https://trac.cryptech.is/raw-attachment/wiki/WikiStart/trng_on_novena.jpg
I'll try to explain a bit about the Cryptech TRNG.
The goal of the Cryptech TRNG is to be a state of the art random
generator that is modular, testable and scaleable in terms of
performance as well as security. It should be able to be very resistant
against attacks and be able to detect attacks during operation. We have
spent a fair bit of time on the design and implementation as well as
evaluation of the entropy sources. We do have a TRNG that is up and
running on three different FPGA boards, but we are still at an early
stage and have a lot of work still to do. Documentation for example.
Anyway the TRNG consists of three major stages:
(1) Entropy providers
(2) Mixer
(3) CSPRNG
Lets look at them in detail.
(1) We want to have at least two entropy providers, each connected to an
independent random physical process of different type from the other.
The current TRNG also supports adding a third entropy provider if one
would like to do so.
Each entropy provider is responsible for collecting entropy from its
source, and if needed do post processing before providing entropy to the
next stage. This is done as 32-bit words. The entropy provider is also
responsible for collecting statistics and even provide access to the raw
noise and/or collected entropy when placed in a specific test mode.
Finally the entropy provider shall continuously observe its source and
signal the rest of the system if the source behavior deviates too much
from expected behavior. Here we look at the AIS31 online tests.
The status so far is that we have two entropy providers. The primary
source is based on avalanche noise in a PN-junction. The nouse source is
external to the FPGA and was the board on the picture you saw. This
provider has been fairly extensively tested using MCUs of different
types as well as FPGAs. The major design is by Benedict Stockenbrand and
Fredrik Thulin. Fredrik has posted quite a lot of test results with ent
and other tools on this maillist. I at least feel pretty confident in
this entropy provider.
The second entropy provider is based on digital ring oscillators inside
the FPGA. The design is by Bernd Paysan and uses adder chains in
feedback mode. I've done a fair amount of testing of this source in
Altera FPGA devices and get pretty good results from ent for example.
I've just gotten this entropy provider to work properly in Xilinx
devices and are collecting data to test it.
The important thing is that since we have two different entropy
providers, you must manipulate them both in order to induce bias.
(2) Entropy provided is assembled into 1024 bit message blocks by a
mixer. The mixing is done in round robin fashion which means that each
provider needs to deliver 512 bits each time we update the state of the
mixer. The actual mixing is done using the SHA-512 hash function. We
don't reset the state between hashes which means that what we extract as
seed for the CSPNG is based on not only on the latest hash of entropy,
but also on all previous hash operations. We are basically hasing a
very, very long message and extracting intermediate digests. This makes
it very, very hard to predict/know what effects any bias induced in an
entropy source will have on the seed generated by the mixer.
The main part of the mixer has been implemented. It supports three
entropy providers, it has a complete SHA-512 mixer. What is missing is
the ability to in a specific test mode insert your own test
vectors/"entropy" and run the mixer to see that you get the expected seed.
Since the TRNG is modular it is very easy to replace SHA-512 with
something else such as SHA-3, Blake or any other hash function one
trusts. The only real criteria is that it accepts messages in 1024 bit
blocks and provides 512 bit digests.
(3) The CSPRNG is the part that actually generates the random values
provided to applications. The cryptech TRNG currently uses the stream
cipher ChaCHa as csprng. (But can easily be replaced). There are several
reasons for this choice:
- It is an ARX construction that has little issues with side-channel
leakage
- It has a high security margin with 256 bit key and variable number of
rounds to allow users to "turn the knob" to trade speed for security.
The cipher and esp its sibling Salsa20 has been fairly extensively been
tested and seems to receive good confidence by cryptographers. By
default we use 20 or 24 rounds.
- It is really fast in HW. We should be able to continiously deliver at
least 500 Mbps in the current FPGAs we use. It is also fairly easy to
parallelize with more ChaCha cores to trade more HW-resources for higher
speed. In this way we should be able to reach basically arbitrarily high
performance. 10 tbps should be quite feasible.
We are currently seeding the CSPNRG with a new 256-bit key, 128-bit IV,
64-bit initial counter value as well as the 512 bit block that is
continiously enciphered. This means that we have about 800 bits of state
as seed.
The current implementation have the cipher and and output fifo done.
There is also a mechanism for reseeded automatically after set number of
512 bit blocks. Also the upper level system can force a reseed if
needed. What is lacking is the ability to insert your own seed in a test
mode and see that you can generate a few random values to ensure that
the CSPRNG operates as expected.
The CSPRNG has not been extensively been tested with Dieharder for
example but will be in the near future.
In short, the major structure is in place and can generate values. The
entropy providers are working to some degree of confidence. There are
some support for observing the entropy providers. But on-line tests as
well as the test mode is missing.
In terms of platforms we are using three FPGA boards.
The TerasIC DE0-Nano is a low cost, USB powered board about the size of
a cigarette pack. The FPGA is capable of implementing the complete TRNG
but needs a noise board. Based on what you described this board might at
least be a suitable start board until a custom board can be designed.
http://www.terasic.com.tw/cgi-bin/page/archive.pl?CategoryNo=139&No=593
We also use the TerasIC C5G board. More expensive, bigger FPGA but about
as open source as DE0-Nano.
What you saw on the picture was our third development boards, the Novena:
http://www.kosagi.com/w/index.php?title=Novena_Main_Page
This is an open source board with CPU etc. What we are currently doing
is building a complete HSM reference design based on the Novena with SW
layers running on the CPU. See our nice layered cake for the different
parts. Basically the blue stuff will be in the FPGA and possible some
parts of the green. But main parts of green will be SW on the CPU
https://trac.cryptech.is/wiki/OpenCryptoChip
We are using Cryptlib by Peter Gutmann for a lot of the SW layers. Ron
Austein can answer questions about the SW parts much better than I can.
I hope this gave at least some ideas of what we are trying to do with
our TRNG and its status. Please just post more questions if not.
- --
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
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iQIcBAEBCAAGBQJUhgWZAAoJEF3cfFQkIuyNQ3kP/i5XFuKRasuJ1n3i/XyvPbcw
W3/b9WtU7RpSTZYjqiMHpoLM54UZXWr1ovy4uQj60PEoIOpKlFARUJlV6OQLf8wC
tX82dzFy7DaxBrPQ/TwYE9QgFOHI+J+HzohfY2vMwofhBPOBvQq3Sd6y8w28rTSK
pPCJYgiOaERBMPVcok3jjkFpr6eg2KfG/kql4W7bmfJNi7GMnhQhu+c6par3KeSN
e5xSegYkGb8YpeJ/Xl3b4NWO2RCd+BZxdHqJjR+yFgonLkadyX9DuBn5j4/C942m
/HRlOV/CrMdhSZAwDq1r377yRwiQZ1yraQrZjsUA8y2WCndZGpNL+ZNKtTKz66Mp
opKV1iToTNHx3VUWT5jSnzEQ/W/w6WOqf3igQ+17E2Zep7o8L4+JsRnycFjZWnRX
tPe/zTgMDDsc88DxzfGa3WSvZg7A79hplRpfdN34HAPDJrkLPvdUJzV5y72/ljmY
7qw+blG+I5JrvH1t5ZAF4uh0pOtRwa3T/kF+CnW5IowumJFcXkpfEWeGmNc2X/mp
f9kX9nhjS+o/ECTi7g9YivyT8FugtrhEJMVNf+TpqrTaaKhWV3uhyhbSvgV8YK+c
5qGhSYMoHw22JqSMtv0E0YPaigjMZA5u9YPR1itsMJCEu2ahoMdVcwhunCcH0vIn
PLOCsEKIw5a0YKAVO/T8
=QAdU
-----END PGP SIGNATURE-----
More information about the Tech
mailing list