GCN LAB IMPRESSIONS
The 3 steps to securing an Android smart phone
- By John Breeden II
- Feb 06, 2012
It’s nice to see the government isn’t throwing Angry Birds, and more useful apps, out with the bathwater in their effort to make Android phones more secure.
We’ve been reporting on the Defense Department’s efforts to take commercial, off-the-shelf Android phones and, through a software upgrade, enable them to handle classified and eventually top secret data. Now it looks like, at least for the classified end of the pool, that may finally be happening, with top secret data soon to follow.
Of course, people are rightly concerned about data security, and the thought of government employees carrying around classified data on their Droid X’s is a little off-putting at first, especially when you consider that no hardware modifications are being made to the phone itself, and no special models are being used, as was done for President Barack Obama when he came to office.
But the truth is that it’s not really all that difficult to secure the current generation of Android phones. And it’s interesting to note that the military apparently asked for Apple’s help in doing the same thing with iPhones, but was turned down because Apple, unlike Google, refused to let the government mess with its source code.
To secure an Android, or any phone for that matter, you need to do three things.
First, you have to restrict physical access to the phone. If anyone finds a lost government phone or steals it, you don’t want them to be able to just turn it on and find a bunch of classified information. This is actually the easier part of the process. Dual authentication log-in programs already exist on some phones, and are easy enough to add to others. If you additionally configure the phone to destroy its data if a certain number of sequential failed access attempts occur, you are pretty much set with the first check box. Most phones lock themselves down after even short periods of inactivity, so that front is also already covered.
Second, you need to make sure the data at rest is secure, in case someone bypasses the login. There are a lot of security protocols natively on Android phones that an admin can already set up for this purpose. One erases all data at rest, or anything flagged as classified, automatically if the phone does not connect into its home network after a certain amount of time has elapsed. You can also encrypt the data up to 256-bit Advanced Encryption Standard, which the NSA says is good enough for classified data.
Third, you can go one step further and add proprietary protocols such as HAIPE (High Assurance Internet Protocol Encryptor), which the NSA requires to access the government’s classified Secure IP Router Network.
Nothing in the first two areas requires access to the actual Android source code, but the third area, securing the communications going out from the phone, does. That’s why the government, in partnership with Google, had to create the Secure Android Kernel and why you won’t be seeing secure iPhones unless and until Apple decides to help out as well.
You might be surprised how many little security holes there are on smart phones that you don’t think about. A simple weather application might broadcast your location. Playing Angry Birds is probably OK, but if you upload your high score, that data might contain information that could let someone identify your phone, your login credentials or, again, your location. It’s really too much for a user to try and monitor, and some of that data is hidden.
The secure kernel is designed to look at all communications going out from a phone and scrub away any data that might compromise security. At the same time, it will allow government smart phones to securely connect with government networks, and presumably each other, without restricting them too much from other normal activities.
Although a little scary at first, when you look at what is actually being done, the government is simply using an existing tool, and a powerful one, to help people make their jobs more efficient.
It’s better to do it this way than to bury our heads in the sand and pretend that smart phones don’t exist, because then you get users trying to do secure things on non-secured hardware, and that’s when you really get into trouble.