Strong Random Number Generator

Summary of Change

This feature is installable from http://software.hp.com, and detailed installation instructions are found at this site as well. This feature is not included with the HP-UX 11i v1.6, and must be installed separately

The strong random number generator for HP-UX 11i v1.6 extracts informational entropy from sub-microsecond timing data associated with external interrupts. This provides a secure, non-reproducible source of binary sequences for applications that generate encryption keys and other cryptographic quantities.

The HP-UX 11i v1.6 strong random number generator design follows the Dynamically Loadable Kernel Module (DLKM) architecture on HP-UX. This permits kernel software to be configured into or removed from the HP-UX kernel domain without rebooting the system. This feature only requires that the /dev/random and /dev/urandom devices are not in use for removal or upgrade. Installation, upgrade, and removal can be completed without system downtime.

Details of Change

This feature produces random data at a high rate in the absence of local input devices such as keyboard and mouse. The National Institute of Standards and Technology (NIST) test suite for randomness was used to confirm cryptographic strength. Even during extended periods of minimal network and disk activity, small sub-microsecond variations in system activity are tapped to produce true random sequences at a sustained rate of 100 bytes/second or more.

A deskewing algorithm by Dr. Yuval Perez, University of California, is used to remove bit skew as the random data is collected.

The /dev/random device interface provides random, unpredictable binary sequences through the standard read(2) system call. This read() blocks temporarily if the kernel-resident device buffer is too low to guarantee the highest level of entropy.

The /dev/urandom device has the advantage of a non-blocking read() call, but the entropy may be much more dilute than that provided by /dev/random. This device interface also provides non-reproducible random data, but relies on cryptographic hashing to guarantee a non-blocking source of random numbers.

The cryptographic hashing employs an encryption algorithm, that meets the Advanced Encryption Standard (AES), which was developed and provided by Dr. Brian Gladman, United Kingdom.

In contrast to pseudo-random number generators such as random(3M), this feature does not depend on computationally deriving random sequences from seed values, and is truly unpredictable. The /dev/random and /dev/urandom devices provide a higher degree of security for cryptographic applications.

Impact

The random number generator and device interface space requirements are very small. When loaded, it uses less than 100Kb of memory. For security reasons, this feature does not store state or initialization data on disk or other permanent device. The DLKM and configuration files take less than 100Kb on disk.

Compatibility

It is intended that the /dev/[u]random read() interfaces provide transparent binary compatibility for applications developed on Linux. This feature depends on HP-UX 11i v1.6 external interrupt handling modifications to extract informational entropy, and is not backward compatible with previously released kernels. It is not dependent on optional hardware or software.

The various ioctl() commands available with the Linux /dev/random device are not available with this feature. These commands do not appear to be of general use to applications. Their usefulness is mostly for investigating performance and production. The Linux write() capability to /dev/random internal buffering within the kernel is also not available since it potentially could constitute a security problem.

For verification of internal entropy, a single ioctl(2) command is provided with HP-UX 11i v1.6 to retrieve random data from internal buffering. When data is retrieved using this command, an AES encryption algorithm is bypassed so that generated data can be tested for true randomness.

Performance

The performance impact to external interrupt handling, even when the random number generator is heavily utilized, is very small - much less than 1% of the overhead associated with interrupt handling.

Obsolescence

Not applicable.

Documentation

The operational characteristics are described in the random(7) manpage that is installed as part of this feature.