Patent Application
20100023749
The present invention relates to the operation of pseudo-random number generators, and more particularly, to managing and extending entropy pools used in pseudo-random number generators.
Pseudo-random numbers are required for many operations in computers, computer networks, and network devices, and are frequently used in security-critical operations such as cryptographic key derivation. Unpredictability of such random or pseudo-random numbers is paramount for such applications.
Such unpredictability may be defined for example, as a low correlation between bits in a pseudo-random bitstream, between portions of the bitstream, or between the pseudo-random bitstream and other signals.
A good random number utility is a carefully designed and vetted subsystem in a computing device. It may be implemented entirely in software, or it may use specialized hardware assists A typical utility operates on an entropy pool, a pool of randomized bits, from which requests for random numbers may be satisfied.
Personal computers typically derive entropy, which may be defined as a numeric quantity which is unpredictable and uncorrelated from a statistical perspective, from various environmental inputs, particularly those affected by the randomness and unpredictability of human operators Such inputs may include the latency between key presses on a keyboard, idiosyncratic mouse timing, variations in network packet arrival, variation in disk drive operation such as seek time variations, and others. Some systems may devote hardware resources to (pseudo-) random number generation. Values from such sources may be “whitened” by running them through a hashing algorithm such as SHA1 or other cryptographic process, and the resulting bits “stirred” into the entropy pool of the random number utility.
Embedded devices, such as network devices and wireless access nodes, often lack hardware random number generators and are often at a loss for sufficient entropy sources, as such devices do not have unpredictable users, keyboards, mice, disk drives, and the like. Often the “best” response in such devices is to add a hardware generator and use this generator to periodically re-seed the entropy pool used by the random number utility.
What is needed is a way of adding entropy, particularly in embedded systems.
The invention may be best understood by referring to the following description and accompanying drawings that are used to illustrate embodiments of the invention in which:
Embodiments of the invention relate to extending entropy in random number generation. In an embodiment of the invention, trusted sources of encrypted data, such as encrypted network traffic, are sampled and fed to the entropy seeding routines of the random number generation utility such that the extracted data is stirred into the entropy pool of the random number utility.
Network 200 is populated by other network devices such as controller 300 and nodes 310 and 320. Nodes 310 and 320 may be other network devices, or they may be peer nodes, such as peers to node 100 in a mesh network.
As understood by the art, such a hardware platform as shown in
If suitable encryption keys are used, the output of robust encryption algorithms is effectively random. According to the present invention, if a device has access to a source of encrypted data, that encrypted data may be sampled and fed into the entropy seeding routines of the random number generation utility, stirring the data into the entropy pool.
A network device 100 such as an access node, switch, or mesh point, has access to multiple trusted sources of encrypted data in the form of encrypted datastreams available to or passing through the device.
When such a device is locally terminating sessions encrypted using WPA or WPA2 protocols, the device is encrypting packets destined for clients, and can sample bits from such packets,
When encryption over the network is centrally terminated, for example at a controller and the encrypted traffic tunneled, a device such as an access node decapsulates the encrypted IEEE 802.11 frames and forwards them over the air; such encrypted 802.11 frames can be sampled.
Mesh nodes involved in forwarding traffic may recognize elements of such traffic as encrypted, and can sample bits from such traffic.
For the purposes of the invention, trusted encrypted packets include those packets which are encrypted by the device itself, or packets which originate from a trusted source, which can include encrypted traffic from peers or controllers which can be trusted not to behave in a malicious manner, and encrypted traffic for which the device holds decryption keys.
Alternatively, encrypted packets may be developed by taking network packets, which may be encrypted packets, and applying further encryption to such packets. In one embodiment, an access node may use a session key from another session to encrypt a packet, producing a packet suitable for use by the invention.
In accordance with an embodiment of the invention and as shown in the flowchart of
As shown in
For the purpose of description herein, it is assumed that the random number utility has an entropy pool, a mechanism for adding or stirring bits into the entropy pool, and a mechanism for returning random bits based on the entropy pool. The nature of these mechanisms will depend necessarily on the computer languages and structures used for their implementation. Such utilities are described, for example, in ANSI X9.31 Appendix A.2.4, or NIST Special Publication (SP) 800-90, incorporated herein by reference.
Such sampling may be event based, as an example, controlled by a timer, or triggered by a low-water mark on the entropy pool. Sampling may take place on a periodic basis,
Sampling may also take place on a stochastic basis. As an example, when encrypted data is recognized, the decision on whether or not to sample that packet is made on the basis of a random number from the random number utility. In one embodiment, a random bit is requested from the random number utility, and if this random bit is a “1” then the packet is sampled, and if “0” the packet is not sampled.
When the decision has been made to sample a packet, either a fixed or a variable portion of encrypted data 144 from the packet may be sampled. In one embodiment, a fixed amount of encrypted packet data starting at a fixed offset from the beginning of packet data 144 is selected and added to the entropy pool. As an example, the offset may be zero, and the entire encrypted packet 144 may be selected and added to the entropy pool. Or, a single byte or fixed number of bytes may be selected and added.
In another embodiment, an offset and length are chosen stochastically, using random numbers from the random number utility. A random number (a number of bits) is requested for an offset into encrypted packet 144 and a random number is requested for the length (number of bits or bytes) to select from encrypted packet 144. The offset should be calculated modulo the packet size, The length should also be calculated modulo the packet size. If the offset plus the length is greater than the length of encrypted packet 144, then the length may be truncated, or data may be sampled from encrypted packet 144 in a circular fashion. The selected data from encrypted packet 144 is then added to the entropy pool.
While the invention has been described in terms of various embodiments, the invention should not be limited to only those embodiments described, but can be practiced with modification and alteration within the spirit and scope of the appended claims. The description is this to be regarded as illustrative rather than limiting.
