The mobile phone as a token container, can we trust storage ?
One question KerPass often receive relates to how safe is using a phone to store software token ? A mobile token like the one part of the KerPass UST system, requires storing several cryptographic keys. Security specialists generally consider that software token are not reliable because nearby malicious software can read and duplicate the private information it contains. Common sense certainly suggests that a secure storage system (eg smart card) is a better location to store private keys than say disk storage. That said the complete analogy that most are making in between the modern open and insecure pc and the mobile phone is not accurate. They are reasons beyond “It is nice to have that there…” that make the mobile phone well suited to be a token container.
Propagating mobile malware
If you want to construct a malware for mobile phone today, you ‘ve got to decide on what technology you want to use. Though there is currently not such a thing as a unified mobile platform, you roughly have 2 choices :
- Java
- Native code
The Java mobile malware
If reaching a large number of handset with a single development effort is your goal (electronic criminals like being efficient), mobile Java is a tool of choice giving you access to more than one billion of handset today …
It is certainly possible to construct mobile software in Java that create problems (eg send costly sms …), that said the security model of mobile Java has an interesting feature. Two applications that are part of different “suite” can not share storage, hence a mobile Java malware is not technically in a position to read/copy data that pertain to another application be this application your personal agenda or a mobile token …
Security is one of such domain where less is more. It is interesting to observe that meanwhile mobile Java settled on this simple and efficient rule (data will not be shared in between application), recent developments are aiming at offering shared access to on phone security elements (the SIM and future NFC on board smart card). No doubt that efficient solution will be proposed to accurately restrict the access to those sensitive resources , that said if you are evaluating immunity against external malware you shall note that simple java storage file (aka “record store” …) are more immune than security application inside phone security elements …
The “native” mobile malware
Given current biodiversity of the mobile ecosystem, it is difficult to paint an accurate picture of the situation. As long as a mobile phone allow to install third party native applications, a knowledgeable outsider will be in position to take advantages of device operating system vulnerabilities…
Though some mobile OS vulnerabilities have been documented, mobile phones have so far remained untouched by “native” mobile virus … The main reason for that is the difficulty to develop malware that are portable across a large number of handsets. There is no long term guarantee provided by this. The good news is that some mobile OS are pro actively addressing this issue.
A recent development of Symbian OS is allowing to enforce efficient privacy policy at the level of the operating system. Starting with Symbian 9, every application can store data in a private area that is not accessible to any other application on the handset. This feature known as “data caging” allows to efficiently protect the phone against unwanted information duplication by external malware. This interesting development (which other OS can easily replicate…) paves the way for the mobile OS to be the system of choice to protect personal information.
Beyond “data caging”
In the case of a networked device there are efficient solution to render the private keys file not usable by a third party even after it has been duplicated. This goes far beyond what PKCS #5 password based encryption allows to do, and form the basis of what KerPass calls a Software smart card. More on this in a future post 🙂 …
KerPass 
Leave a comment