Another little problem for you to consider about phone security etc.

The IMEI (phone ID / Serial Ni=umber) is available to applications that run on the phone such as a web browser, and in some cases (due to Vodafone) the browser sends it off in the user agent string. See,

http://blog.trasatti.it/2005/07/serial-numbersimei-in-user-agents.html

Now with most modern phones having browsers on them it is actually quite likley that the IMEI will become known to any “bot net” style malware on the phone that the user might have picked up whilst browsing.

So an individual phone and all it’s applications can become known to the malware which can ship it off to the malware control.

After that the rest becomes a matter of what the malware writer has enabled in the malware…

“they are very far from being universal”

The reason for this is that apart from the base level functionality (GSM specs etc) they are not in any way standardised (think the number of different versions of code that have to be written for some phone application level OS’s).

It is also a significant problem in that the few “security” related specifications on phones are all to do with segregating the underlying phone from anything else that might run on the phone as a “Personal Mobile Resource” as an application.

Above the phone level there is little or no security that is meaningfull (think Win98 security), nore as they tend to be more than somewhat resource limited is there likley to be for some time (the more efficient you try to make a platform the less secure it is).

Code signing of applications is actually not security at all as it does not find or remove bugs or other weaknesses (diliberate or otherwise) . For instance if a company does not audit the code I write for them properly (which requires a significant input of resources they don’t have) then it makes little or no sense in signing the code other than to asign legal liability (which most Licence Agreements remove).

Also if “bad code” is introduced in the supply chain before it gets to the end user then code signing is of no use whatsoever (think Apple and the PC virus that was put on it’s pods by somebody in a subcontractor for example).

The general trend for malicious code these days is as rootkits not as “bragware” it is designed to remain as hidden as possible whilst alowing the code writer to have hidden control to upload other code etc as an when required (think bot nets etc).

Due to the “first to market” principle code auditing is almost never allowed to get in the way of releasing the latest feature rich application, and at best it only happens at the software house end of the supply chain not the consumer end.

As we are all to painfuly aware feature rich code is a veritable haven for software anomalies. Few if any of these can be “certified” as not a security risk even within our current level of knowledge (which at the rate it ages sugests is pitifuly small).

Such apparently simple security methods as “sand pits” tend to be insecure in one way or another, and it is almost impossible to stop “secret information” leaking out of even certified systems due to the discovery of new side channels etc.

So no I have little or no reason to suppose that mobile phones can be made secure at the application level either from direct malicious code or more subtle secret information leakage…

And more importantly if their use as anything other than phones ever becomes significant I fully expect them to receive the attention of malware writers that are currently doing rootkits for PC operating systems.

Have a look at Matt Blaze’s very recent blog entry on the subject of computer security on hardware related iussues,

http://www.crypto.com/blog/hardware_security/

Modern phones do have some potential security feature improvments since I was cutting assembler and C code for them. But the QA and code audits are still nowhere near good enough to say if the are even close to being secure in reality.

Then over and above the low level embeded phone OS code is often Microsoft Originated code to provide the user interface.

Mobile phones are still basic resource (CPU RAM ROM etc) limited when compared with desktops of a few years ago. So to get the feature richness there has to be compromise in some other area, where is dependent on the manufacturer…

But even with mandatory compentmentalisation you have to ask what is being protected from what (ie phone to app or app to app).

For the purpose of the Cronto application it does not use the phone so I suspect there is little or no security between it and the camera and the display or other apps so in that respect it is just like any out of the box MS Desktop without security being enabled.

The next three issues is how does the app get onto the phone and from where and by what route?

To be cost effective for most bank customers it’s going to be download it of the web.

As noted above this delivery method has been compromised in the past even when reasonable (at the time) precautions had been put in place.

As has been seen with the likes of games consoles even with supposed mandatory “code signing” to prevent third party apps like being loaded it usually takes little or no time for the system to be circumvented.

I could go on at length about the how and the way of attacking the system but that would be unfair to Cronto as all “security token” apps on mass consumer devices which are mutable are going to be vulnerable in one way or another.

As for the difficulty of tying a phone to a PC and compromising both you are thinking about it the wrong way.

If you think of mass compromise without direct “intended purpose” which has already happened (zombie nets etc). That is somebody gets as many PCs under their control as they can then rents/auctions them off to another person.

Then you have to ask when it will happen (if it has not already happened) on phones.

Then when there is sufficient financial imperative I can assure you tying the PC and phone together will happen (think marketing etc).

And at some point after that any “security token” app with enough market exposure will be targeted.

As a guess bassed on the length of time between predicting “shim dlls” and seeing them for real (8 years) I would say we are about 4 years off of this happening.

So having thought about it at some length back in 2000-2 no I personaly do not think phones are a good idea for putting “non phone related security apps” on. Nore for that matter any other mass consumer item with mutable memory.

When and only when the designers of phones etc increase the scope of the security on their products to the required level can they be viewed as being potentialy suitable for high security apps.

Sorry about the server problems. For reasons I don’t fully understand, all comments were being categorized as spam, so I had to manually pull them out.

The important difference between the barcode and the “only human readable font” is that the barcode is encrypted and authenticated. Only the authorized device can decode it. The authenticity checks also prevent replay attacks.

There are a range of options on how to use the Cronto system (USB key, mobile phone, and dedicated device) and each represents a particular usability, security, and cost tradeoff. The advantage to banks is that the server software works with them all.

As for mobile phone security, it’s important to remember that the attacker has to compromise both the phone and the PC (or the user’s Internet connection). Home PC security is poor, but mobile phone security is much better.

Modern phones incorporate application signing and mandatory compartmentalization. There will be ways to bypass these protections, but doing so, while simultaneously compromising the user’s PC, is going to be a substantial challenge.

Steve has not replied yet, the info was from me.

However I would encorage him to reply to give you and others a different perspective on mobile phones. After all my opinion is from my perspective having had to build an programe the beasts, and then get it through the compliance process.

Supposadly there is a new set of standards for mobile phones due at some point in tne not to distant future. Partly this is because they are long overdue but also because the E.U. and ETSI CENLEC etc have finaly woken up to the concept of Software Defined Radio” which kind of makes a lot of their hardware oriented specifications a bit of a problem (to see what the EU is upto in this area the best place to start with is the R&TTED irective pages on http://www.europa.eu where that is coming to the end of it’s latest review.

Regards,

Clive.

P.S. if you contact Steven he has my details so you can get directly into contact if you wish.

I used to design the beasts several years ago. The security of a mobile phone is virtualy nix.

The network operator can usually send software updates to the phone, and as you will apreciate if you have ever downloaded a ring tone it is very very easy for a third party to put data into the memory.

Further you may or may not remember that it was found that malware can be hidden in a picture that a user viewed with a web browser. Well it is quite likley that the browsers an other image related software on a mobile phone is equaly as vulnerable (no I have no data on this it’s just an assumption based on it being quite probable).

As for the crypto used on mobile phones etc the GSM spec was a bit laughable have a look at the GSM section in,

http://cryptome.org/cryptout.htm

or specificaly,

http://cryptome.org/gsm-joke.htm

And don’t be surprised if you make strange noises while you read it

Also at Cryptome have a look at the TEMPEST section as well.