11.7 Using an Entropy Gathering Daemon-Compatible Solution

11.7.1 Problem

Your application needs randomness, and you want it to be able to run on Unix-based platforms that lack the /dev/random and /dev/urandom devices discussed in Recipe 11.3 for example, machines that need to support legacy operating systems.

11.7.2 Solution

Use a third-party software package that gathers and outputs entropy, such as the Entropy Gathering and Distribution System (EGADS). Then use the Entropy Gathering Daemon (EGD) interface to read entropy. EGD is a tool for entropy harvesting and was the first tool to export this API.

When implementing our randomness API from Recipe 11.2, use entropy gathered over the EGD interface in places where entropy is needed; then, to implement the rest of the API, use data from that interface to seed an application-level cryptographic pseudo-random number generator (see Recipe 11.5).

11.7.3 Discussion

A few entropy collection systems exist as processes outside the kernel and distribute entropy through the EGD socket interface. Such systems set up a server process, listening on a Unix domain socket. To read entropy, you communicate over that interface using a simple protocol.

One such system is EGADS (described in the next recipe and available from http://www.securesoftware.com/egads). Another system is EGD itself, which we do not recommend as of this writing for several reasons, primarily because we think its entropy estimates are too liberal.

Such entropy collection systems usually are slow to collect good entropy. If you can interactively collect input from a user, you might want to use one of the techniques in Recipe 11.19 instead to force the user to add entropy to the system herself. That approach will avoid arbitrary hangs as you wait for crucial entropy from an EGD-compatible system.

The EGD interface is more complex than the standard file interface you get when dealing with the /dev/random device. Traditionally, you would just read the data needed. With EGD, however, you must first write one of five commands to the socket. Each command is a single byte of data:

0x00

Query the amount of entropy believed to be available. This information is not at all useful, particularly because you cannot use it in any decision to read data without causing a race condition.

0x01

Read data if available. This command takes a single-byte argument specifying how many bytes of data should be read, if that much data is available. If not enough entropy is available, any available entropy may be immediately returned. The first byte of the result is the number of bytes being returned, so do not treat this information as entropy. Note that you can never request or receive more than 255 bytes of entropy at a time.

0x02

Read data when available. This command takes the same argument as the previous command. However, if not enough entropy is available, this command will block until the request can be fulfilled. In addition, the response for the command is simply the requested bytes; the initial byte is not the number of bytes being returned.

0x03

Write entropy to the internal collector. This command takes three arguments. The first is a two-byte value (most significant byte first) specifying how many bits of entropy are believed to be in the data. The second is a one-byte value specifying how many bytes of data are to be written. The third is the entropic data itself.

0x04

Get the process identifier of the EGD process. This returns a byte-long header that specifies how long the result is in bytes, followed by the actual process identifier, most significant byte first.

In this recipe, we implement the randomness interface from Recipe 11.2. In addition, we provide a function called spc_rand_add_entropy( ), which provides an interface to the command for providing the server with entropy. That function does not allow the caller to specify an entropy estimate. We believe that user-level processes should be allowed to contribute data to be put into the mix but shouldn't be trusted to estimate entropy, primarily because you may have just cause not to trust the estimates of other processes running on the same machine that might be adding entropy. That is, if you are using an entropy server that gathers entropy slowly, you do not want an attacker from another process adding a big known value to the entropy system and claiming that it has 1,000 bits of entropy.

In part because untrusted programs can add bad entropy to the mix, we recommend using a highly conservative solution where such an attack is not likely to be effective. That means staying away from EGD, which will use estimates from any untrusted process. While EGADS implements the EGD interface, it ignores the entropy estimate supplied by the user. It does mix the entropy into its state, but it assumes that it contains no entropy.

The following code implements the spc_entropy( ) and spc_keygen( ) functions from Recipe 11.2 using the EGD interface. We omit spc_rand( ) but assume that it exists (it is called by spc_keygen( ) when appropriate). To implement spc_rand( ), see Recipe 11.5.

When implementing spc_entropy( ) and spc_keygen( ), we do not cryptographically postprocess the entropy to thwart statistical analysis if we do not have as much entropy as estimated, as you can generally expect servers implementing the EGD interface to do this (EGADS certainly does). If you want to be absolutely sure, you can do your own cryptographic postprocessing, as shown in Recipe 11.16.

Note that the following code requires you to know in advance the file on the filesystem that implements the EGD interface. There is no standard place to look for EGD sockets, so you could either make the location of the socket something the user can configure, or require the user to run the collector in such a way that the socket lives in a particular place on the filesystem.

Of course, the socket should live in a "safe" directory, where only the user running the entropy system can write files (see Recipe 2.4). Clearly, any user who needs to be able to use the server must have read access to the socket.

#include <sys/types.h> #include <sys/socket.h> #include <sys/un.h> #include <sys/uio.h> #include <unistd.h> #include <string.h> #include <errno.h> #include <stdio.h>     #define EGD_SOCKET_PATH "/home/egd/socket"     /* NOTE: this needs to be augmented with whatever you need to do in order to seed  * your application-level generator.  Clearly, seed that generator after you've  * initialized the connection with the entropy server.  */     static int spc_egd_fd = -1;     void spc_rand_init(void) {   struct sockaddr_un a;       if ((spc_egd_fd = socket(PF_UNIX, SOCK_STREAM, 0)) =  = -1) {     perror("Entropy server connection failed");     exit(-1);   }   a.sun_len    = sizeof(a);   a.sun_family = AF_UNIX;   strncpy(a.sun_path, EGD_SOCKET_PATH, sizeof(a.sun_path));   a.sun_path[sizeof(a.sun_path) - 1] = 0;   if (connect(spc_egd_fd, (struct sockaddr *)&a, sizeof(a))) {     perror("Entropy server connection failed");     exit(-1);   } }     unsigned char *spc_keygen(unsigned char *buf, size_t l) {   ssize_t              nb;   unsigned char        nbytes, *p, tbytes;   static unsigned char cmd[2] = {0x01,};       if (spc_egd_fd =  = -1) spc_rand_init(  );   for (p = buf;  l;  l -= tbytes) {     /* Build and send the request command to the EGD server */     cmd[1] = (l > 255 ? 255 : l);     do {       if ((nb = write(spc_egd_fd, cmd, sizeof(cmd))) =  = -1 && errno != EINTR) {         perror("Communication with entropy server failed");         exit(-1);       }     } while (nb =  = -1);         /* Get the number of bytes in the result */     do {       if ((nb = read(spc_egd_fd, &nbytes, 1)) =  = -1 && errno != EINTR) {         perror("Communication with entropy server failed");         exit(-1);       }     } while (nb =  = -1);     tbytes = nbytes;         /* Get all of the data from the result */     while (nbytes) {       do {         if ((nb = read(spc_egd_fd, p, nbytes)) =  = -1) {           if (errno =  = -1) continue;           perror("Communication with entropy server failed");           exit(-1);         }       } while (nb =  = -1);       p      += nb;       nbytes -= nb;     }         /* If we didn't get as much entropy as we asked for, the server has no more      * left, so we must fall back on the application-level generator to avoid      * blocking.      */     if (tbytes != cmd[l]) {       spc_rand(p, l);       break;     }   }   return buf; }     unsigned char *spc_entropy(unsigned char *buf, size_t l) {   ssize_t              nb;   unsigned char        *p;   static unsigned char cmd = 0x02;       if (spc_egd_fd =  = -1) spc_rand_init(  );   /* Send the request command to the EGD server */   do {     if ((nb = write(spc_egd_fd, &cmd, sizeof(cmd))) =  = -1 && errno != EINTR) {       perror("Communcation with entropy server failed");       exit(-1);     }   } while (nb =  = -1);       for (p = buf;  l;  p += nb, l -= nb) {     do {       if ((nb = read(spc_egd_fd, p, l)) =  = -1) {         if (errno =  = -1) continue;         perror("Communication with entropy server failed");         exit(-1);       }     } while (nb =  = -1);   }       return buf; }     void spc_egd_write_entropy(unsigned char *data, size_t l) {   ssize_t              nb;   unsigned char        *buf, nbytes, *p;   static unsigned char cmd[4] = { 0x03, 0, 0, 0 };       for (buf = data;  l;  l -= cmd[3]) {     cmd[3] = (l > 255 ? 255 : l);     for (nbytes = 0, p = cmd;  nbytes < sizeof(cmd);  nbytes += nb) {       do {         if ((nb = write(spc_egd_fd, cmd, sizeof(cmd) - nbytes)) =  = -1) {           if (errno != EINTR) continue;           perror("Communication with entropy server failed");           exit(-1);         }       } while (nb =  = -1);     }         for (nbytes = 0;  nbytes < cmd[3];  nbytes += nb, buf += nb) {       do {         if ((nb = write(spc_egd_fd, data, cmd[3] - nbytes)) =  = -1) {           if (errno != EINTR) continue;           perror("Communication with entropy server failed");           exit(-1);         }       } while (nb =  = -1);     }   } }

11.7.4 See Also

  • EGADS by Secure Software, Inc.: http://www.securesoftware.com/egads

  • Recipe 2.4, Recipe 11.2, Recipe 11.3, Recipe 11.5, Recipe 11.16, Recipe 11.19



Secure Programming Cookbook for C and C++
Secure Programming Cookbook for C and C++: Recipes for Cryptography, Authentication, Input Validation & More
ISBN: 0596003943
EAN: 2147483647
Year: 2005
Pages: 266

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net