Random Number Generation
Using Wireless Sensor Networks
Phillip McClelland
William Beazley
Alex Montgomery
Introduction
Within the spectrum of computer science there is interest in generating random numbers,
this is in part driven by the need to build stronger cryptographic keys. There are a number
of techniques, which by using different algorithms, generate numbers that are seemingly
but not truly random, and are thus called pseudo-random. Alas, these numbers are still
based on a set of rules which limit their effectiveness; truly random numbers (at least
random to the viewer or sampler) can be made by methods where some external value or
event is sampled from the environment and thus are random by virtue of their exclusion
from the system. One example of these methods would be to distribute small sensors that
take limited analog samples of their environment (i.e. light, sound, pressure, temp, etc.),
convert them into digital values and then aggregated them to produce keys of varying
size.
This is now becoming a viable option because of the shrinking size of electronics,
their lower power consumption, and advancements in battery technologies.
In this paper we outline the use of random sampling to aid in the generation of an
encryption key. This key may range from 128 bits to 176 bits for our small scale
application, but could easily be doubled or quadrupled depending on the demand by the
aggregating of additional sensed readings.
Network Topology and Related Design Considerations
This is a simple example of how WSNs may be employed to generate random keys. Of
the main considerations was how to create a WSN that could be homogenous, save for
the Base Station used to collect the data; this homogeneity implies the need for nodes to
have roles that can change. Another design consideration was to keep the memory
footprint as small as possible. These considerations are driven by the costs savings that
are typical of these types of systems, such that homogeneity allows for economy of scale
and reduced footprint allows for cheaper hardware.
The services provided by this WSN setup can be logically divided into two
divisions: Thoughtless, not having state; and Thoughtful, having state. They can be
further enumerated and delineated thus:
1. Thoughtless:
a. Get Node ID Service or get_nghbr;
b. Get Random Data Service or get_rnd;
2. Thoughtful:
a. Generate Key Service or gen_key.
These services used by sending messages to and from motes and to the sink, the base
station. There are only six messages that can be sent:
1. GET_NGHBR;
2. RPLY_NGHBR;
3. GEN_KEY;
4. GET_RND;
5. RPLY_RND; and
6. RTRN_KEY.
Messages of types GET_NGHBR and RPLY_NGHBR can be thought of as being the
members of the Get Node ID Service where by GET_RND and RPLY_RND are the two
members of the Get Random Data Service. Generate Key Service uses the GEN_KEY
message to promote a mote as the arbitrator and aggregator; promotion tells the listening
mote that it needs to collect data, which it does by using the Get Random Data Service,
the mote then aggregates the data, which is returned with the RTRN_KEY message.
Implementation
The mote-side programming was done in NesC and the System-side programming was
done in Java, all files were built upon the frame that was provided by the TinyOS
Project.1 Major modifications were needed to provide additional functionality and
message types not included with TinyOS. Tools such as SerialForwarder were used with
no change, others such as BCastInject could not bear the changes effectively and had be
redone substaintially enough to require a set of new Java Classes called
RanGenInject.java and RandomGenMsg.java. A full manifest of the files is at the end of
this writ.
Mote-side
These services are provided mote-side by RandomGen which is uploaded to all motes,
save for the base station. The program RandomGen exists in the typical NesC form of a
RandomGen.nc configuration file and a RandomGenM.nc module implementation file;
also included is a RandomGenMsg.h containing the NesC (C style) struct used for data
field and message field. It is important to give each mote a separate local address, which
is defined by TOS_LOCAL_ADDRESS. TOS_LOCAL_ADDRESS is set for each node
when the software is uploaded, and for the RandomGen it is set to value greater than 0,
which is reserved for the Base Station.
1
http://www.tinyos.net/
RandomGenMsg
RandomGenMsg Message is formatted with a certain level of redundancy and logging
which was useful in the development stage. This message is the payload of a TOSMsg.
The main elements are listed henceforth:
1. uint16_t sourceAddr;
 This is used to tell those answering whom it was sent from.
2. uint16_t destAddr;
 This is used to tell those answering whom it was sent for; it used only for
debugging.
3. int8_t action;
 This tells what action is to be performed, thus it lists the message type.
4. uint8_t key[MAX_KEY_SIZE];
 This is the key that has been aggregated if it is of the proper message type.
5. uint8_t keyIndex;
 Where is the last element of the key;
6. uint8_t keyLength;
 How big of a key is asked for.
BaseStation
The Base Station is programmed with the TOSBase, which is provided with TinyOS. It
forwards messages via a serial connection to RanGenInject that it receives from the
network, these messages are set to TOS_BCAST_ADDR, 0xffff, which any and all
receive or to the local nodes address, TOS_LOCAL_ADDRESS. The Base Station was
given a TOS_LOCAL_ADDRESS equal to 0.
System-Side
The serial connection is arbitrated on the system be SerialForwarder, which is provided
also by the TinyOS Project2. It gives a socket to interface with the systems serial
connections.
RanGenInject is the system’s program interface that allows it to return the final key and
pick which mote to promote. RanGenInject is the Java program that receives messages
from and sends messages to the serial connection via a socket provided on
SerialForwarder; the messages a received by the Base Station, which sits on the other
end of the serial connection, it runs TOSBase.
Detailed Operation
2
http://www.tinyos.net/
When RanGenInject is given a command to generate a random key it forwards a
generated connection message to the Base Station which then broadcasts the message to
the surrounding nodes; this message has GET_NGHBR value in its action field. The first
node to respond with RPLY_NGHBR in its action field is then sent the empty packet
using its ID and GEN_KEY within its action-field, this mote shall be the ‘promoted’
mote. The promoted mote is given the command from the base station to fill the barren
key with the randomly acquired bytes. The promoted mote then edits the header of the
packet with its own information, along with the packet’s command message replacing it
with GET_RND action, and then rebroadcasts the packet. This communication is similar
to a multicast system, because node one sends out a universal destination ID,
TOS_BCAST_ADDR, 0xffff. The surrounding nodes receive this request and react
based on the nested command, which informs the node to capture a light sensor reading
and then return it to the promoted mote as RPLY_RND action. Only the least significant
byte of the two byte sensor value is returned to the requesting node. Node one collects
the information for a set amount of time and then builds a key. Node one will continue
the process until it has filled the key. Then it will send the completed random key back
to sender with the command field in the packet’s header set to RTRN_KEY.
Limitations
The caveat that must be included is that the strength of the key is related to number of
independent samples taken. Thus, if there are to few samples the key is likely going to be
weak.
Conclusion
Since there is relationship between randomness and observation, external events may be
used to create relative randomness. WNS have been show to a viable system for
capturing external events and thus are worthy to be used for developing keys that rely on
randomness.
(Different files we’ve changed to implement this mote application)
Mote-side Files:
Makefile, unique for this project;
platform.properties, intact from TinyOS;
ProcessCmd.nc, intact from TinyOS;
RandomGen.nc, unique for this project;
RandomGenM.nc, unique for this project;
RandomGenMsg.h, unique for this project.
System-side Files:
RandomGenMsg.java; this is built by ‘mig’ from RandomGenMsg.h;
Makefile, this is modified from TinyOS;
RanGenInject.java, unique for this project, but based on BcastInject.java;
Bcast.properties; intact from TinyOS.
User Guide:
See Attachment:
README