In the last instalment, I had got up to 2006, when the first phones with platform security started shipping. This was a major turning point in the perception of Symbian Signed, as before then it was an optional thing for developers, but afterwards it was a requirement for access to the more security-sensitive APIs on the platform. I’ve already explained (I hope!) why that was necessary, but it did mean that some developers who would really rather not care about security now were forced to, and started to complain very loudly about it.

The first significant change in the Symbian Signed processes came in late 2007 with the introduction of Express Signed. Prior to that, all submissions had to undergo individual testing by a test house, which the developer paid for (typical charges were in the region of $300-$400). With Express Signed, the developer was not required to pay for individual testing, but they affirmed that they had performed the tests themselves and that the submission passed the test criteria. A percentage of the submissions were audited by a test house after being signed; the costs of those random audits were spread across the charges for all submissions, so the charge per submission was much reduced, down to $20.

The previous, paid-for individual testing, process (now called Certified Signed) was kept for those that wanted the benefits of an independent tester. Certified Signed was also still required for applications that used the seven most dangerous capabilities (CommDD, MultimediaDD, NetworkControl, DiskAdmin, Drm, AllFiles and Tcb).

The next change to Symbian Signed processes was the introduction of Open Signed Online in early 2008. Prior to this, developers of applications using more than user-grantable capabilities needed a Developer Certificate to test their applications on a real phone.

Developer Certificates for one phone with most widely used capabilities were available to developers for free, but to request a certificate for multiple phones or more sensitive capabilities a paid-for Publisher ID was needed. Developer Certificates are now called Open Signed Offline because you can use them to sign a new build of your application at any time without going back to the Symbian Signed portal.

Open Signed Online, on the other hand, was introduced to avoid the complexity of having to download the devcertrequest tool, submit a certificate request, download and install the certificate, and then sign your SIS file. It’s a free service that allows developers to simply upload an application that they want to test on their phone (identified by its IMEI) and then download a signed copy of it that they can immediately install. After this, developer certificates were only available for developers with a Publisher ID, as Open Signed Online was simpler for those without one.

The most recent change to Symbian Signed came with the introduction of considerably simplified test criteria, resulting from a public discussion in the second half of 2009. The aim was to concentrate on testing that the application didn’t damage the device operation or configuration, removing some of the tests that were more targeted at general quality issues in the application itself. As a result of the simplified criteria, the charge for Express Signed submissions was reduced to €10, and the charge for Certified Signed testing was reduced to €150, in early 2010.

Looking back over the 6 years, the various incremental improvements have added up to a substantial reduction in cost and inconvenience for developers. When Symbian Signed was first introduced, it could cost well over $1000 for a developer to get their first application signed for public distribution ($395 for a Publisher ID and $800 or more for testing of a complex application) and turnaround could be several days; today the same application could be signed for a little over $200 ($200 for a Publisher ID and €10 for Express Signed) with no waiting.

Even so, we acknowledge that this is still too expensive for many small-scale and independent developers, and the next round of changes should provide another big reduction in the costs. Stay tuned!

There are some interesting challenges at the API level that are probably only relevant to security geeks (how does the service know that the application that’s invoking it is properly authorised?) but I won’t go into that now, because it seems there is a more basic and glaring error:

That’s a screen shot of the dialogue the user sees after the application invokes the payment API.  To authorise the transaction, they are supposed to type in their PayPal account name and password. Here’s the problem: How does the user know that this dialogue has come from the PayPal service, and isn’t just being drawn on screen by malware, that will upload that user name and password to be used by criminals?

Oh, but surely it must be OK, because there’s a tiny picture of a padlock! Is there some law that prevents malware drawing pictures of padlocks? You have got to be kidding…

Here’s my rule of thumb for typing in financial account passwords to applications: If you didn’t download that application directly from the bank or other institution that holds the account, then DON’T DO IT.

I am suggesting that the Symbian Foundation should host a beta test site for free applications. Developers and volunteer testers would be able to sign up to the site with just an email address and an IMEI, and then they could upload any application they like, and download any application they like. On download, the application would automatically go through Open Signed Online and be signed for that user’s specified IMEI.

There’s a clear risk that such an application could accidentally or deliberately damage the tester’s phone or their bank balance, so they would need to acknowledge a disclaimer to that effect.

Users that have downloaded an application for testing would then have the opportunity to rate it, then periodically the ones with the highest rating could be sponsored through Symbian Horizon, and the ones with the lowest rating should be removed.

There will of course be costs involved in hosting and maintaining the site, but it seems to me that those costs should be quite manageable and I am hoping they could come out of the Symbian Foundation’s budget (someone will have to do proper costings on this before it can be approved, but I’m willing to do that if the idea is popular!)

If you like this idea, please head over to the Symbian Ideas site and vote for it! At the time of writing, I only need 8 more votes to progress it to the next stage, so I’ll be grateful for any and all support

Tip of the hat: some aspects of this are similar to the O2 Litmus programme and the Android Market, but I think it’s interestingly different from both of them.

I see increasingly frequent suggestions that people should use their phones to monitor their health. This is, on the face of it, attractive; being an insulin-dependent diabetic, I carry a blood glucose meter with me pretty much everywhere, and in line with the general trend of convergence (calculator, camera, music player, radio, etc.) wouldn’t it be great if that was built in to my phone?

Well yes, that would be very convenient, but I’m afraid I think it’s a fundamentally bad idea.

The great attraction of smartphones is due to them running general purpose operating systems, thus their functionality is “limited only by your own imagination” — provided you’re a competent programmer, and aren’t trying to defeat DRM, break subsidy lock or distribute self-propagating malware

Unfortunately this very openness to the unknown is not a good characteristic for a device that needs guaranteed reliability; coupled with a device that has limited resources (processing power and battery life) you are surely tempting fate.

We already face this issue in one way: mobile phones can be life-saving devices when used to make an emergency call, and phone manufacturers and network operators are required by law to make best efforts to connect any emergency call regardless of other concerns (whether the account is in credit, whether the phone has registered to roam on to that network, and whatever else the phone is doing). Obviously you can’t make a call if the battery has run out or there are no base stations in range, but also third-party software installed on the phone could potentially prevent a call going through (Symbian tries to stop that by requiring applications that use capabilities that could interfere with voice calls to go through Certified Signed testing, but sadly that’s not a guarantee).

At a recent Symbian Feature and Roadmap Council (FRC) meeting, the council members voted on their top six desired future focus areas. Number 3 was Monitoring & Sensors: “(especially around enabling healthcare and wellbeing use cases)”. That really rang alarm bells with me.

In the case of emergency calls, the risk of a failure is manageable: your call either goes through or it doesn’t, and if it doesn’t you shout for help and hope someone nearby has a working phone. In the case of health monitoring, however, failures could be much more insidious, either leading to misinformed decisions for medical intervention or, probably worse, a false sense of security if you think your observations are fine but actually they’re not.

This isn’t just a matter of conscience, either – I’m not just saying “don’t do this, someone might die,” I’m also saying “don’t do this, you could lose a lot of money!” Consider being required to do a full device recall because of a flaw in the UI – this is a clear possibility, looking at the long list of US medical device recalls here. You may think “oh, clearly a phone wouldn’t be classed as a medical device,” but it’s a very broad category; the list includes baby teething rings, heat pads, beds, a laboratory information system and, most to the point, several blood glucose meters. The meter recalls seem generally to be for cases when users have been confused by switching (possibly inadvertently) between US and European units for the display. My point is that it only takes a few cases of this kind of “user error” and the manufacturer is required to recall all the devices.

That said, obviously there is a spectrum of risk here; a biorhythm app is clearly harmless, a pacemaker control app is clearly dangerous, and of course what is being proposed will be somewhere in the middle. For me the dividing line is whether users are going to make any decisions for or against medical intervention as a result. Letting your phone be your doctor? No, really, please don’t do that.

There is a proper way of doing this, which is to have a separate highly reliable medical device that communicates with or via your phone, but I’m fairly sure that’s not what the FRC had in mind…

I have taken some liberties with the format and tagged on a longish “wish list” of items Open for Contribution at the end. I’d particularly like to draw attention to the last four, which are opportunities for concerned individuals or organisations to address some consumer protection issues (which our traditional contributors probably won’t address).

I did allude to this six months ago, but this time I’ll be shorter and more to the point:

• Notarised Call Recording
  how to hold faceless utility companies to account?
• Pre-Advice of Premium-Rate Charges
  think twice before giving your money away?
• Privacy Labels
  how not to embarrass yourself on social networking sites?
• Vendor Relationship Management
  how to do e-commerce on your terms?

Volunteers welcome

That said, there is an interesting point made, almost in passing, in the presentation. Your phone knows what encryption algorithm is being used between it and the base station: for example, my Sony Ericsson P1i shows a little warning triangle icon if the base station switches it to A5/0 (that is, no encryption) although I don’t think my Nokia E71 does. Karsten also notes “IMSI catching is detectable from [the] phone, but no detect apps exist” (we have mentioned IMSI catching in this blog before).

So, the main point of the presentation is the assertion that well-funded attackers (security agencies, organised crime) are already using attacks to break GSM encryption, and his aim in making attacks practical for hobbyists is to push the phone manufacturers and network operators to improve security for everyone. I think that’s a heavy-handed approach, to say the least, but it’s done now. I am though left wondering who is being targeted today by GSM eavesdroppers. I’ve posted an idea on the Symbian Ideas site that there should be an app available to tell the phone user (in so far as that is possible) when their communications security is being compromised. Please join in there if you think that’s interesting!

* Renewability of hash algorithms is also an active topic in the Symbian Security Forum.

Having gone through a chain of “not our problem” FAQs (network operator → PhonePayPlus → Ofcom) it turns out that the actual body responsible for punishing senders of unsolicited SMSes in the UK is the Information Commissioner’s Office, as the applicable law is the same as for unsolicited fax messages (the Telecommunications (Data Protection and Privacy) Regulations 1999, amended by the Privacy and Electronic Communications (EC Directive) Regulations 2003).

The ICO have an online form for reporting breaches of the Privacy and Electronic Communications Regulations (PECR) so I’ve gone ahead and filled that out, which has made me feel a bit better

There does seem to be a loophole here however: the PECR say that if the number is owned by a business rather than an individual, prior permission is not required (and my number is owned by Symbian). If it’s a fax number, it could be registered with the Fax Preference Service to forbid unsolicited fax messages, but there doesn’t seem to be an equivalent SMS Preference Service to forbid unsolicited SMS messages. Am I doomed to accept SMS spam on my work number forever then? We’ll see what the ICO reply to my complaint…

I’ve been quite sceptical about such reports since this July when the “Sexy View” malware on the Symbian Platform was reported as the “first mobile botnet“. Now in my view that wasn’t even a proper worm (it had to be manually installed by the user on every phone it spread to) and definitely not a botnet (there was no remote control of the malware after it was installed), so is there any more truth in these latest reports?

According to F-Secure’s initial analysis, the latest iPhone malware connects to an IP address in Lithuania, and downloads something from it, but it’s not clear from that what the thing it downloads is, or what it does with it. Although they call the IP address a “command & control center”, I remain sceptical, and would like to see some more details before conceding that this actually is the “first mobile botnet”…

Do please note that this is not a commitment to full disclosure of unfixed security vulnerabilities; the point of this working group is, among other things, to discuss what the right policy should be for dealing with vulnerabilities. I (Craig) favour responsible disclosure, but that’s up for discussion.

If you have an opinion on the work items (and you really should, they will affect device manufacturers, security researchers, network operators, package owners and committers, security tools vendors and anyone who even uses a Symbian Platform device) then please sign up for the mailing list!

Q: How long have you been working with Symbian code? What did you do before that?

Since I joined Nokia, about ten years ago, and all that time around Symbian OS security-related issues. Before that I was implementing Windows UI code in another company.

Q: What packages do you work on, and what are they used for?

The Application Installation package contains components for application installation, management, and distribution. It has Application Installer dialogs, Application Manager Settings plug-in, Application Update client, Software Installer engine, and the Content Download engine used by the Update client.

The Application Installer has a plug-in mechanism for additional runtimes, which will be replaced by a new one in Symbian^4, called the Universal Software Installer Framework (USIF) which will act as a common interface between the UI and runtime-specific installers.

The Security Services package is a collection of middleware-layer components having some kind of connection to security; most of them also have some sort of UI. It includes key lock, device lock and remote lock, also different certificate-related user dialogs like the warning of untrusted certificates popping up from SSL/TLS connections. The untrusted certificate warning dialog might be the certificate dialog people are most aware of, and not necessarily in a positive way.

The Certificate Manager Settings plug-in, Certificate Saver and PKCS #12 library are also in this package, as are WIM and GBA components.

Q: Are there any projects you would encourage newcomers to get involved in?

Perhaps the most welcome would be improvements in SIS handling and the .pkg format. People who implement add-on Symbian applications distributed in SIS packages will be aware that there are opportunities for improvement in the SIS package processing, for example to get information on the device configuration during installation and to install different files based on that information.

For developers coming from other platforms, we are open for contribution of new runtime-specific installers and new installation package formats, for example the Debian package format used in Linux could be supported in the Symbian Platform as well. Obviously the same packages and binaries cannot be used, only the packaging format itself, but even this could somewhat reduce the barrier to port applications from other operating systems to Symbian. USIF will be there to provide a plug-in mechanism to add support for new runtime installers and installation package formats.

On the Security Services front, new innovative ways to unlock key and device lock are most welcome. The current implementation doesn’t have a plug-in mechanism, so alternative device unlock mechanisms are not easy to add at the moment. We would like to fix this by using the authentication server from the OS Security package for device lock, but that work hasn’t started yet and there are no firm plans. Migration of device lock to use the authentication server would be a very valuable contribution.

Contributions in certificate handling functionality, like import of certificates and, generally, improvements in everything related to SSL/TLS certificates which has created headaches for applications and users, are very much encouraged.

Q: What would you say is the biggest challenge for mobile device security?

I am sad to say this, but the biggest challenge is developers who don’t take security into account when developing their applications. The basic security needs of an application can be handled on the Symbian Platform with some very simple steps:

1. Protect your sensitive APIs (if any) with capabilities
2. Put your sensitive data (if any) into your application’s private directory
3. Last but not least, test your application interfaces, especially the ones receiving data from an external sources, with malformatted data to detect buffer overflows.

Q: Which is your favourite Symbian-powered device?

Always the one we are working on at the moment, the one not yet in the shops

Q: When you’re not working on Symbian code, what do you like to do for fun?

I like to listen to records and sometimes go to live concerts. Different kinds of pop/rock/metal music do for me as long as the music has a good feeling. There is a rock club near where I live so it easy to go to see something even if I am not a particular fan.