This blog will be continued at franklinheath.co.uk/blog, with a corresponding RSS feed at franklinheath.co.uk/feed. If you’d like to continue to follow my irregular ponderings, please do subscribe there!

I am intending to continue the Symbian OS Platform Security book wiki there too, but we haven’t got the MediaWiki hosting sorted yet. Please tune in for further announcements

First a clarification: it’s not obvious that Gawker Media did anything fundamentally wrong here. The passwords were one-way encrypted, and database breaches can happen to even the most diligent system administrators (software inevitably has flaws, and there are lots of bad guys, some of whom will be able to develop or find out about Zero Day exploits). It doesn’t really matter how good the password encryption was either; once the encrypted passwords are available, off-the-shelf hardware can run through a staggering number of possible passwords to “brute-force” the encryption in seconds.

There are really only two defences, and it’s the users who need to choose to use them: (1) choose a password that’s difficult to brute-force, and (2) don’t use the same password on different systems. Of course there are two big problems with those defences: (1) passwords that are difficult to brute force are difficult to remember (the best defence would be a completely random string of characters and symbols) and (2) people use dozens or hundreds of different password-protected web sites. I just counted the number of cached passwords on my home PC and work laptop: 202 at home and 355 at work (including quite a few single-use ones, for e.g. hotel Wi-Fi, but still a pretty large number!)

The only rational solution to this is to let your computer manage all this complexity for you. There is a risk though – we are moving all our eggs from one basket (same password for many systems) to another basket (the password manager). The first basket isn’t trustworthy (there is a high risk of one of the many systems being compromised) but we must make sure that the second basket is, or we’re no better off. I’m put in mind of the scare about banking applications on the Android Market. Incidentally, although it was widely reported that those applications were malicious, Google later stated they were not. Nevertheless, something like them could easily have been used to harvest banking passwords.

So, we need a trustworthy password manager. Does such a thing exist? I think it’s pretty hard to tell; my advice (and my current practice!) would be to use the password cache in your browser, but make sure that you password-protect that (and go to some effort to make it a difficult-to-brute-force password, you will only need to remember this one). On your phone, make sure that you are using the device lock PIN (you are doing that already, right?) and in Firefox, set a master password.

I don’t think the Firefox password manager is perfect by any means – I wish it would ask for the master password more often (or at least make that an option) and I wish it had the facility to generate a random password when you’re creating or changing a password, but I think it is better than using memorable passwords and inevitably sharing them between sites.

In the absence of being able to generate random passwords in the browser itself, another piece of advice (which I confess I don’t do at the moment, but I am considering it…) is to pre-generate some good passwords and print them out and carry them around with you. As you use each password, tear off the paper and destroy it, so it’s then only recorded in your password manager. There’s a handy site for generating truly random character strings here.

Oh, and one final thought – back up your password cache!

Perhaps more to the point: this Friday will be the last working day for most Symbian Foundation staff, including me, so it won’t be appropriate for me to blog in Symbian’s name after that. I am planning to export the existing content from here though, and continue this blog* under another banner. I do want to say a few words about the Gawker Media breach while that’s still fresh, so I’ll do that here, and then update you on the new home for the blog before Friday.

* probably more accurate to say “restart this blog” as my last post was in July

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…