Week 15

This week I continued working on the Android randomness collection.

Networking:

First, I wrote a simple server program using Java sockets to accept and print any incoming communication. I then wrote a corresponding client program and ran both on the same machine. After I got this working, I verified that they also worked on separate machines. With this working, I modified the client program for Android and ran it on the Nexus S. This process mainly involved creating a new thread to do the network communication since Android does not allow this from the UI thread. This allowed me to get working communication between the Android phone and a server.

Next, I wrote the final server program. The networking is very similar to the previous program, but I modified the structure to spawn a new thread for every client. I then wrote synchronized methods to separate the messages based on type (wifi, bluetooth, antenna) and write them to files local to the server.

Android Services:

As stated in my previous post, I want to alter my existing Android code to use services so that the user doesn't have to leave the collection app open for it to do its job. Therefore, I did some research on services and the code needed to implement them. I followed instructions I have found online, and have modified the previous bluetooth program to use a service. At present, I am debugging this since the service doesn't ever seem to start. I am confident however, that I will resolve this quickly, and that once I do, the other two parts will be easy to finish.

Week 13

Last week, I began working on an Android App to collect data on available wifi networks. This week, I was able to finish this app as well as to write apps to collect bluetooth and cell tower data.

Wifi and Bluetooth:

The Android API provides the built in classes WifiManger and BleuetoothAdapter. I was able to use these classes to set up BroadcastReceivers. The apps continuously scans for wifi/bluetooth networks and upon completion, the respective BroadcastReceiver gets called to print the data.

Cell Towers:

The Android API provides the built in class TelephonyManager. This class is very helpful, but I ran into a problem using its getAllCellInfo method. Apparently, this method is not supported on Nexus phones and therefore always returns null. Therefore, I was not able to access the built in CellTower Objects. However, I was able to use the getNeighboringCellInfo method to get the RSSI, Cell ID (CID) and Location Area Code (LAC) for each available cell tower.

I was able to test all three apps, and they seem to be working well.

I then began learning more about Android services. These are essentially processes that can be run in the background. I would like to convert my current code to make use of services so that the user doesn't need to worry about anything other than starting and stopping the app. This will be one of my main goals next week.

Since the end goal is to deploy this app on many phones for data collection, the goal is to have each phone send its acquired data back to a central location. I will therefore write a server application to collect and store the data being sent by the test apps. I plan to write this program next week and deploy it on the spqr bicuspid server.

Finally, I will be on vacation the week of August 5^th, so my work will continue on August 12^th.

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.