Yesterday, I wrote about issues Android software developers, or indeed any mobile developers, should think about when implementing apps. However, if you are an organisation such as a security agency, a bank or even a company that has serious security concerns then you need to do more than just write safe software. As it happens, there was an interesting article yesterday, Mobile’s Cryptography Conundrums, based on two presentations from the RSA Conference 2012.
The first presentation by the US National Security Agency (NSA) discussed how there isn’t a good IPSec implementation on Android. IPSec is a secure protocol suite for securing Internet Protocol (IP) communications by authenticating and encrypting each IP packet of a communication session. It’s typically used by VPNs. Digging deeper, the main problem has been a lack of something called Group Authentication. This hasn’t been possible without lots of tinkering on a rooted device. It has been a long-going issue with Android that has only very recently been fixed with Android 4.0 – Although I have seen reports that some people still can’t get it working on Android 4.0.
The second presentation explained how it’s possible to easily eavesdrop on device hardware radio frequency emissions and extract encryption keys from as far away as ten feet. Mobile devices don’t have hardware countermeasures, presumably shielding, such as found in set-top boxes and credit card terminals. However, this is a problem us developers can fix by splitting up operations that use keys into numerous parts.
While all this might look like overkill, it does demonstrate how much might (or might not) hide behind what looks like a simple requirement for an app to be secure. Each project obviously has its own specific security needs and it’s down to the developer (and the client if there is one) to work through what is meant by ‘secure’. Also, with mobile payment systems and NFC on the horizon, issues such as these will become more important.