lkml.org 
[lkml]   [2000]   [Mar]   [15]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
Subjectsupport for CALNET/NEWBRIDGE 810 hardware random number generator.
I have written support for the CALNET/NEWBRIDGE 810 hardware random number
generator.
It can be found at:

ftp://io.com/pub/usr/pelliott/rand.tar.gz

Basically it is a hack to random.c. I hacked the random.c that came with
my 2.213 suse 6.3
system. I have used conditional compilation so that it compiles as usual
to the software RNG that generates entropy from system events unless you
use define
a flag.

If you define __PORTRANDOM__ it will get random bytes from the hardware
RNG.

It can also be compiled as a module, but if you do it that way, the Kernel
itself will still
get random bytes from the direct kernel entry point get_random_byte which
will then
get bytes from the software RNG.

Someday, I would hope there would be support for all the hardware RNG's
such as:

COMSCIRE RNG
--
SG100 security generator from Protego Information
--
Z5000 from Westphal Electronic
--
ORION RNG

I might even code a driver or two myself if I could get access to the
devices and specifications.

I am a new LINUX hacker, and I might have messed up the nuances of the
LINUX way
of doing things. Any suggestions in this area would be appreciated. Thank
You.

One problem I noticed with random.c for someone wishing to do hardware
random number
support. The entry point get_random_byte which gives random bytes directly
to the kernel.
It would be nice if there was some way for a module to "hook" this entry
point so that
the module driven hardware RNG could be giving the random bytes to the
kernel.
But I do no know how one would do this. Any suggestions?

also the entry points :

secure_tcp_sequence_number
cookie_v4_init_sequence
secure_tcp_syn_cookie.

These are used by the kernel but are not used to actually create the
random numbers.
If these were moved to a separate source file, then someone wishing to
create random
numbers in a different way could simply replace random.c, without having
to duplicate
these functions.

Here is the readme for the hack:
----
Device driver support for CALNET/NEWBRIDGE 810 hardware random driver.
pelliott@io.com


From the hardware point of view, the RNG-810 is a very simple device.
Simply do a "inb" instruction on the port (300h 302h 304h or 306h)
depending
on its jumpers and you receive a random byte. The device uses Johnson noise
to get its random bits. The device is subject to one restriction: You must
wait 40usec between in port instructions or the bytes will not be randomly
independent. Without this restriction, the read routine of this IO driver
would be in essence a simple "REP INSB" instruction.


It can be run as a module or as a replacement for the RNG which is built
into
the kernel.

NOTE:
If the hardware RNG is ran as a module, it only returns random bytes to
applications that open the device.

The builtin kernel software RNG that come with LINUX by default also
supplies a kernel entry point (get_random_byte) that supplies random
bytes directly to the kernel. The module version of the Hardware RNG
does not replace this entry point!


To use the module version, run the Makefile in the src directory.
From an account with root privileges do a "make install".

Also install the module:

insmod random

check the major device number that got installed by "cat /proc/devices".
suppose it was "254". One could then mknod a device as follows:

mknod /dev/hardrandom c 254 0

You can then have programs open "/dev/hardrandom" to get random bytes.

Alternately you can choose the major device number on the insmod command.
Suppose you choose 253. Verify that 253 is not already being used for
something!

insmod random rng_major=253

mknod /dev/hardrandom c 253 0


WARNING WARNING WARNING WARNING.

You may be tempted to name the device associated with your hardware RNG
/dev/random and /dev/urandom. This would cause programs seeking
random bytes to use the Hardware RNG.

If you do this you must be careful to keep the old software RNG's
running! Remember that the kernel gets random bytes directly from
this software RNG via a direct entry point.


crw-r--r-- 1 root root 1, 8 Dec 6 16:26 /dev/softrandom
crw-r--r-- 1 root root 1, 9 Dec 6 16:26 /dev/softurandom

Give software drivers a different name such as "softrandom". Then
edit the startup/shutdown scripts that save/restore entropy to the
software RNG changing the name to the new name!

This will ensure that the kernel entry point get_random_byte will
continue to give random numbers to the kernel. (Even though these
bytes will be from the software RNG not the hardware RNG.)

END WARNING END WARNING END WARNING END WARNING

The other way to use this driver is replace the software RNG that
is built into the kernel! If this is done, then the kernel entry
point will get bytes from the Hardware RNG and /dev/random and
/dev/urandom will also get bytes from the hardware RNG.

To do this, first save /usr/src/linux/drivers/char/random.c then
replace it by the random.c that came with this README.

Save and edit the file /usr/src/linux/drivers/char/Makefile, adding
the line:
CFLAGS += -D__PORTRANDOM__

This will cause the hardware random number generator to be used
to get random bytes in the builtin Kernel RNG.

Build the kernel as usual.

If the flag __PORTRANDOM__ is left out, the original software
RNG code will be used which creates random bytes from system events.

-------------
Help my hardware RNG is broken! When it gets hot, bits 5 and 6 of the
returned random bytes are always 0. This is not surprising because
it is over 10 years old!

If the Makefile line
CFLAGS += BROKENBIT
is used while making a module or kernel, the driver will attempt
to compensate for broken bits by shifting and xoring! It does not
matter which bit(s) still works, so long as 1 bit is in working
order.
------------------

In the subdirectory test is the source for a simple test program
bitcount:

Usage:

bitcount count file
or
bitcount count #which reads standard input.

The program reads count bytes from file or std input, and
counts the percentage of bit that are on, for each bit position
0-7.

All returned percentages should be close to 50% if the bytes
are coming from a true random source.
Example:

dd count=1 bs=1024 if=/dev/hardrandom |bitcount 1024
1+0 records in
1+0 records out
bit[0] % 53.0938
bit[1] % 50.998
bit[2] % 49.8004
bit[3] % 48.8024
bit[4] % 52.7944
bit[5] % 49.9002
bit[6] % 50.998
bit[7] % 53.3932


-----
I would also like to create LINUX driver support for other hardware RNGs!
Such as:

COMSCIRE RNG
--
SG100 security generator from Protego Information
--
Z5000 from Westphal Electronic
--
ORION RNG

The problem is I do not have access to this hardware. Any help?

-----
Paul Elliott Telephone: 1(512)837-9345
pelliott@io.com Address: PMB 181, 11900 Metric
Blvd Suite J
http://www.io.com/~pelliott/pme/ Austin TX 78758-3117

Paul Elliott Telephone: 1(512)837-9345
pelliott@io.com Address: 11900 Metric Blvd Suite J-181
http://www.io.com/~pelliott/pme/ Austin TX 78758-3117

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 13:57    [W:0.030 / U:0.400 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site