EntropyKey - miniature Windows driver...?

[Rob Kendrick]

On Mon, 12 Jul 2010 13:34:33 +0100
Nick Pelling <nickpelling at nanodome.com> wrote:

Hi Nick,

> At 12:38 12/07/2010 +0100, Rob Kendrick wrote:
> > > Are there any plans for a Windows driver for the EntropyKey?
> >We'd like to, but there are issues.  Mainly that we cannot identify
> >any way of providing entropy to Windows in a way where applications
> >can automatically take advantage of it.  You can implement a new
> >entropy provider, but applications still have to ask for it
> >specifically.
> 
> I'm a bit surprised by this - is CryptGenRandom not able to be
> patched? 

What do you mean by "patched"?  Replacing it with an alternative
implementation entirely sounds a bit like a dodgy hack, and Microsoft
had partially thought about other sources, given you can have multiple
providers.  They just didn't think it through completely :)

> Microsoft now recommends that app programmers replace rand()
> with rand_s(), and my understanding is that the latter calls
> RtlGenRandom() which in turn calls CryptGenRandom(). 

That is my understanding also.

> If you can hook that up, I'd have thought many current apps would
> get immediate access to the EntropyKey's output stream. Perhaps that
> would be good enough?

rand_s() calls the CryptGenRandom infrastructure, but as far as I know,
it always asks for the default provider, which is the Windows-provided
PRNG that is occationally rekeyed with entropy from interrupt timings
etc.  There's no way (at least that I know of, and I'd love to be shown
otherwise!) of changing this to include data gathered from an Entropy
Key, or any other source, short of API hijacking hacks.

> >Indeed; I suspect if we do a Windows driver, it will simply be in the
> >form of a library.  Which is a shame.
> 
> Still, it's a big old market out there. :-)

As I say, it's on the list of things we'd like to do, but haven't had
time to do yet.  The job is complicated somewhat because the Entropy
Key itself is complicated.  Other TRNG products are basically dumb
devices: they feed you random data over a serial port or similar.  The
Entropy Key has a protocol with encryption and commands, and requires a
tool to configure them, monitor them, etc.  So just writing a library
that opens a serial port, reads some bytes, and returns them, won't
work here.

> >We'll happily help any third party that wishes to develop Windows
> >driver software for the Entropy Key, however.  Much of the UNIX
> >driver should be easily portable to Windows (for example, the
> >protocol handlers, etc.)
> 
> I'd be interested to have a peek at this, to see how nasty it is (or
> isn't) 
> - please email me whatever details you reasonable can (and an NDA for 
> anything you can't :-) ). 

Our UNIX driver is entirely open source, under the MIT licence.  You
can obtain it from the downloads section of the website.  It also
includes extensive documentation for the protocol and rationale.

> If it presents itself as a virtual serial
> port (FTDI-style), it shouldn't be _that_ hard to work with, should
> it?

Indeed not.  It uses the CDC ADM protocol, which Windows supports out
of the box if you supply a suitable INF file with the correct vendor
and device USB IDs.  The protocol, rekeying, and such, however, are
slightly involved.

-- 
Rob Kendrick, Support Team Lead                      Simtec Electronics
Telephone: +44 (0)1772 978013                  Avondale Drive, Tarleton
Fax: +44 (0)1772 816426                     Preston, Lancs, PR4 6AX, UK
http://www.simtec.co.uk/                       mailto:rjek at simtec.co.uk