HP-UX Secure Shell: Part 5: Adding the Random Number Generator
By Chris Wong
 

One of the few complaints regarding the use of the Secure Shell on HP-UX is that it is S-L-O-W. The reason behind this has been that HP-UX has not had a random number generator (RNG). Until the release of the RNG, HP-SSH used a pseudo-RNG. This relied on .prng_seed files in the .ssh directories. As of December 2002, a RNG is available for HP-UX 11i named the “Strong Random Number Generator” (KRNG11i). This article will discuss installation, performance and security.

The RNG is available at http://www.software.hp.com/ISS_products_list.html .

The RNG is a dynamically loadable kernel module (DLKM), a reboot is required during initial installation. The following is installed on the system:

 
RandomNumGen B.11.11.06 HP-UX 11.11 Strong Random Number Generator product 
RandomNumGen.RNG-DKRN B.11.11.06 Strong Random Number Generator DLKM 
RandomNumGen.RNG-KRN B.11.11.06 Strong Random Number Generator Kernel Enablement
 

The startup script krng is added in /sbin/init.d and the link for startup is located in /sbin/rc1.d/S114krng. There is not a configuration file or a shutdown link. The device directory now contains both the random and urandom device files.

 
cr--r--r-- 1 bin bin 57 0x000000 Feb 4 14:43 /dev/random
cr--r--r-- 1 bin bin 57 0x000001 Feb 4 14:43 /dev/urandom
 

The random special device file is the blocking interface to the RNG module in the kernel. (This is where the “K”(ernel) is coming from in the use of the name KRNG). The urandom special device file is the non-blocking interface. Both these are compatible with Linux’s random and urandom. The major number of 57 is used since this is the number assigned to the Random Number Generator (rng):

 
# lsdev -e 57
 Character Block Driver Class
 57 -1 rng pseudo
 

[Just as the major number of 64 is used for LVM device files (/dev/vg01/group, lvol, etc) since this points to the LV kernel driver].

The RNG resides in the kernel. This provides for increased performance and security.

The /var/adm/rc.log records that the RNG has been loaded during startup:

 
Initialize loadable modules
Output from "/sbin/rc1.d/S112kminit start":
----------------------------
 * All configured modules are registered successfully.
 * Module rng is loaded successfully.
 
NOTE: Module status
 
Name ID Status Type
=====================================================
krm 1 UNLOADED  WSIO
rng 2 LOADED WSIO
 
Creating /dev/random and /dev/urandom special files
Output from "/sbin/rc1.d/S114krng start":
 
The following process will be running:
 
root 541 0 0 16:37:57 console 0:00 rng
 

The process that is typically associated with “console” is getty. However, you won’t find rng in the /etc/inittab file. You will find rng in the /etc/loadmods file if you have RNG configured to start as a DLKM at boot time (recommended when using SSH).

For HP-SSH to utilize the new RNG no configuration changes need to be made to SSH. The RNG is not only used by SSH. Other applications that need a random number may also use RNG. For that reason, it is advised to not implement this immediately on a production box or to at least wait until mid-2003 when it has been more widely implemented (and potentially patched). Also review using DLKM if you have not yet done so.

Let’s now examine performance ramifications. I conducted a very non-scientific experiment on two different boxes. The first system is an A500 with 1 GB of memory. The second system is a B160L with 256 MB of memory. Both are running HP-UX 11.11. The only user on each system is the user running the SSH commands. The user executed SSH locally, not across a network. Before RNG was installed the following commands were entered and timed:

/sbin/init.d/secsh stop

time /sbin/init.d/secsh start

time ssh-keygen –t rsa –N pass88 –f /home/jrice/.ssh/id_rsa

time ssh-keygen –t dsa –N pass88 –f /home/jrice/.ssh/id_dsa

cp id_dsa.pub authorized_keys

ssh-agent $SHELL

ssh-add

time ssh localhost who

The timed commands require no user input. The following two charts display the collected times for the commands before and after the installation of RNG. The difference is very measurable and apparent to the end user.

As you can see, on a resource starved system (the B160L), the increase in performance was especially noticeable. Following are the numbers (in seconds) for the B160L:

ctg700	Before RNG	After RNG
secsh start real	28.8	2.2
secsh start user	2.5	0
secsh start sys	2.2	0
keygen rsa real	14.5	1.6
keygen rsa user	9.1	1.3
keygen rsa sys	1.9	0
keygen dsa real	49.3	22.8
keygen dsa user	37.5	22.4
keygen dsa sys	2	0
ssh who real	12.8	4.7
ssh who user	4.4	1.9
ssh who sys	1.9	0.1

How the performance will play out in a large multi-user environment isn’t known to me. I encourage users to submit their own performance statistics to me and I’d be happy to post a summary of the results or to provide a link to a future HP white paper. A note in the man page for “random” hints to when a performance bottleneck may occur:

When there are a large number of requests on /dev/random within a short time interval, the demand on the holding buffer can exceed the rate at which data is supplied by rng. A read() on the /dev/random device blocks the requesting thread if the random data stored in the holding buffer is too low to complete the request. The thread blocks until the holding buffer has been updated with enough random data to complete the request.

The last subject I want to touch on is security. If you are using HP-SSH chances are it was implemented for security reasons. Using the RNG is more secure than using the current pseudo-RNG. Why? Because RNG can not be influenced in its generation of the random number. The current pseudo-RNG requires a seed (the $HOME/.ssh/prng_seed file) and uses user-space (RNG is using kernel-space). This seed is generated based on the entries in the ssh_prng_cmds file. If you look at this file, you can see how it may be possible to manipulate the seed. The ssh-rand-helper (pseudo-RNG) process creates the prng_seed. When RNG is installed, this process is no longer used (when viewing the collected MWA process data this becomes apparent). The prng_seed files can be removed (this includes the one in root’s .ssh directory) since the new device driver (accessed via /dev/random and /dev/urandom) does not need this seed file to create a random number.

Chris Wong is a technical consultant and trainer based in Bellevue, WA. She is the author of the HP Press book HP-UX 11i Security.  All Rights Reserved,Copyright 2003, NEWFDAWG.COM http://newfdawg.com