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 RNGI 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/
This archive was generated by hypermail 2b29 : Wed Mar 15 2000 - 21:00:27 EST