Week 12

During the beginning of the week, I continued to learn more about the Android programming environment. I have been using a mixture of the Google online resources and a number of youtube tutorials. At this point, I feel that I have a good understanding of the basic building blocks of an Android application and that anything else I might need while creating an app, I will be able to learn when necessary.

On Thursday, Vishal and I met with Amir to discuss the sources of mobile randomness we wish to investigate. We came up with the following six sources:

- Available Bluetooth Device Statistics

- Available Wifi Network Statistics

- Antenna Signal Strength

- Battery Power/Voltage

- Battery Charge/Discharge Rate

- Running Process Statistics

Vishal and I split the list and each of us will work on three sources. For now, we will each create an app, with the eventual goal being to combine them into a single app that can collect from all six sources. We also hope to set up some sort of networking so that we can send the aquired information to a central location rather than having it stored locally.

I took the first three sources and have begun working on recording available wifi networks and their statistics. Android has a built-in WifiManager class that facilitates any wifi interaction. I have written a test application, but am getting errors when running it on the emulator. I don't know if the errors are due to my program or the fact that it is running on an emulator. In the next week, I will debug the wifi app, and work on the other two sources.

Week 11

The next step in our survey of entropy sources will be mobile devices. Mobile devices are extremely prevalent, and commonly perform tasks that require a high degree of security. These devices offer the advantages of mobility and thus an unpredictable environment, as well as several embedded devices such as cameras and microphones. However, they are more susceptible to theft and lack the computing resources of more traditional machines.

I read a paper: “The Sources of Randomness in Mobile Devices” (from Masaryk University, Czech Republic). The authors do a study of the entropy gathering potential of mobile devices. They focus mainly on the microphone and camera inputs and through statistical analysis show that these devices are capable of providing truly random bits. They do not give a good idea however of the rate at which such bits might be generated.

For our project, I anticipate analyzing sources such as the microphone, camera, battery level, signal strength, and gps position. We might also be able to use some of the sources we have already examined such as bluetooth, wifi, and process statistics.

In order to investigate these sources, I have been learning how to create apps for the android operating system. Google provides a good training tutorial that I have been using. I have learned quite a bit by creating several apps with basic functionality. I have a bit farther to go in this training, but it should help me to create some apps to record the sources we are interested in.

Week 10

Last week I began working on a program to record wifi statistics. I was using the C interface for the iwlist library. After some struggles trying to find the statistics I was looking for in the different structures throughout the code, I decided to use the built in iwlist scan function. I therefore wrote a parser program and a shell script. The script runs the system call: iwlist wlan0 scan and pipes the results into the parser program. The parser then goes through the results, extracts the useful information and writes it to a file. We now have the capability to record available wifi networks and their related statistics.

I then began work on a similar program for recording available Bluetooth statistics. This proved a little more difficult since most statistics require a connection. I was able to find the device mac-address and clock offset for each available device without establishing a connection. I used the system call: hcitool inq (inquire). However, while this function is useful, it often does not find all of the available devices. I therefore wrote a program to continuously run this function and record any new devices encountered.

I then spoke with Amir, and we decided to move into mobile devices. He provided me with a Nexus S Android phone. I have never done any mobile programming, so I started an online tutorial on mobile app development at http://www.coreservlets.com/android-tutorial/. This is going well and I am learning a lot.

Week 9

After looking into the event codes with Amir, we decided to just record all of the events so that we could look at them after recording some data. Therefore, I changed the code I had written to record every event to a different file. We will now be able to observe both the quality and frequency of each random event.

We have now written scripts to record online sources, Linux random hardware events, and process statistics. With all of these sources done, we decided to begin looking into wifi signals. I downloaded the source code for the iwlib library. This code interfaces with the Linux kernel to retrieve the available wifi information. I took the relevant code and wrote a new program to record for each wifi source, its ESSID, frequency, quality and level. I am still working on finding a way to record the router mac address.

When I last spoke to Amir, he said he was going to buy a bluetooth dongle so that we could also look at available bluetooth signals in a similar manner as we are currently doing for wifi signals.

Week 8

This week, I continued on the tasks I had been working on last week. Fist, I've never really learned how to correctly write shell scripts, and since I've been writing so many lately, I took some time to do a shell scripting tutorial at linuxcommand.org. This really helped, and I edited some of the scripts I've written in past weeks for better functionality. I then wrote a script to periodically log the process statistics of the running machine. This writes all the data resulting from the top command to a file at a user defined interval.

I then spent some time digging deeper into the Linux kernel to track down the event codes. I found some relatively detailed documentation about their usage, and determined that for the most part, we were correct about their usage. There are two potential problems though:

1. The EV_KEY event code is used for any key or button press. This is exactly what we want for the keyboard, but it means that this will also encode any mouse button press.

2. The EV_ABS event code records the absolute position of the mouse. This might be what we want, but there is also an event code EV_REL which encodes the relative movement of the mouse. It seems to me that EV_ABS would be a better random source for a touchscreen environment, whereas EV_REL would be better for a system with a typical mouse.

I will speak to Amir about this and determine if we should change the current version of the code.

I also spent some time trying to determine the prevalence of different hardware sensors in different machines. I am having a very difficult time finding this information though. My current thinking is that anything more than CPU temperature would be a bad source due to lack of hardware support across multiple platforms.

Week 7

I spoke with Amir, and we decided to forgo writing random data to a file from the kernel. Instead, I altered the kernel to write all of the relevant data to the syslog log file on every random event. This required much less complexity than writing to a file since I was able to use the existing printk system call which exists for this purpose.

The four random events we are interested in capturing are mouse, keyboard, disk, and interrupt. The mouse and keyboard events are captured when their drivers call the add_input_randomness function and pass it an event type. This function then calls the add_timer_randomness function which adds the random bits to the entropy pool.

The disk events are captured when the add_disk_randomness function is called. This function then calls the add_timer_randomness function to add the random bits to the entropy pool.

The interrupt events are captured and handled completely separately by the add_interrupt_randomness function.

In order to separate these events, I put wrote data to the log file in the add_timer_randomness and add_interrupt_randomness functions. The latter was trivial since the interrupt events are the only ones to call this function. However, to separate the events that call add_timer_randomness, I added an event_type argument to the function. The type from add_input_randomness was passed directly, and a new type was defined and passed from the add_disk_randomness function. For each event, the number of bits credited (deemed random) is written to the log file along with all of the data mixed into the entropy pool.

There was one oddity I encountered. The possible event types passed to the add_input_randomness function are defined as:

EVENT TYPE	DESCRIPTION
EV_SYN	Used as markers to separate events. Events may be separated in time or in space, such as with the multitouch protocol.
EV_KEY	Used to describe state changes of keyboards, buttons, or other key-like devices.
EV_REL	Used to describe relative axis value changes, e.g. moving the mouse 5 units to the left.
EV_ABS	Used to describe absolute axis value changes, e.g. describing the coordinates of a touch on a touchscreen.
EV_MSC	Used to describe miscellaneous input data that do not fit into other types.
EV_SW	Used to describe binary state input switches.
EV_LED	Used to turn LEDs on devices on and off.
EV_SND	Used to output sound to devices.
EV_REP	Used for autorepeating devices.
EV_FF	Used to send force feedback commands to an input device.
EV_PWR	A special type for power button and switch input.
EV_FF_STATUS	Used to receive force feedback device status.

I assumed that the event types EV_KEY and EV_ABS correspond to keyboard and mouse events respectively. However, I have not verified this. Also, the type EV_MSC seems to get passed on a regular basis, and I don't know what event is causing this. The current code ignores all types but EV_KEY and EV_ABS. Therefore, it would be best to dig deeper into the code to confirm the relation between events and these types.

After altering the kernel code, I wrote a user space program to parse the syslog file and look for the events logged from the kernel. This parser separates the events and writes them each to a file depending on the event type.

I then wrote an installer shell script to make the kernel changes, install the new kernel, and set the parser to run on boot. The installation takes a long time, but it means that we can install this on any machine running Linux.

Next, I began to look into potential randomness in CPU temperature and fan speed. On Linux, the lm-sensors program allows you to read the values of any hardware sensors that are installed on your machine. This works very well, but is highly dependent on the hardware of different machines. My laptop for example has CPU temperature sensors, but no fan speed sensor. Therefore, I am in the process of trying to find which sensors are common in different types of machines, as well as the refresh rates for these sensors.

I also wrote a shell script which logs the all of the currently running processes and all of the information associated with them. We are hoping that we can use process statistics like memory usage as sources of randomness. I now need to write a script to periodically log this info so we can sit down and analyze the information.

Week 6

This week I have been attempting to work with and alter the linux kernel. After some difficulties recompiling and installing the kernel, I found a guide from a University of Kentucky OS class which allowed me to install my new kernel. After this, I was able to add code to log the random data to the linux syslog file through the printk function. While this was successful, the goal is to write the data to a normal file.

Information on writing to files from within the linux kernel is difficult to find since it is considered something never to be done in kernel code. However, since I am not writing code for contribution to the kernel distribution, it is still something I want to pursue. I was able to find several different ways to do this, and have tried all of them. However, each one has caused the kernel to hang on boot. I am attempting to debug the problems, but it is very time consuming since each attempt requires me to recompile the kernel. This process generally takes about 10-15 minutes.

I will continue to debug this problem in the coming week. Once this is solved, I just need to modify the code so it can tell which random event occurred, and to use this to write to a different file for each event.