Monday, July 29, 2013

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.

Monday, July 22, 2013

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.

Monday, July 15, 2013

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.

Monday, July 8, 2013

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.

Monday, July 1, 2013

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.