Having spent a couple of days on it, I had it running with a rudimentary UI and was familiar enough with the Android SDK to put the Enigma project aside and concentrate on the paid work, but I did still wonder if something useful could be done with the code. Back when I first wrote the logic of the simulator, there was a real Enigma machine out on a table at Bletchley Park that you could physically use and experience what the real operators in World War II had to do. These days, with auction prices of the machines topping $200,000, they’re all locked away behind glass. Given the touch UI of Android, it occurred to me that a good enough simulation could be a useful educational tool, perhaps put alongside museum displays on a tablet computer to give people something of the real feel of the machine.

Looking on the Android market, I found two Enigma simulators already available. One was a decent quality paid-for application, the other was free but poor quality (with logic errors and a hard-to-use UI) and neither took good advantage of the extra screen space on a tablet. I decided to go ahead and give our Enigma simulator a proper, realistic UI, add features to do more than the currently available apps, make better use of the extra space on tablets and publish it. Had I known then that it would take 2 months of days off, evenings and weekends to do I would probably have thought twice!

Another overlap with the client work I’ve been doing is the area of in-app payments. As I’d been investigating security measures to protect in-app payment transactions from tampering on Android devices, I started thinking about whether in-app payments could be taken advantage of in the Enigma simulator. I’m a big fan of the work being done by the Bletchley Park Trust to preserve the historic code-breaking site, both as a memorial to the great work done there and as an educational resource. We’d already decided to include in-app advertising as a possible way of recovering some of our development costs, so we decided to also include a payment option to allow people to turn the ads off and at the same time donate to the Trust. It’s not expensive (just £1) so I hope a good proportion of the users will take that option as it’s in a good cause. At least 50% of the proceeds will go to the Trust and, if we ever reach the point of recovering our development costs, we will look at increasing that percentage.

The app is available now on the Android Market, and we already have a couple of paying customers and a nice review, so that’s a good start! Accompanying documentation is available on our wiki, and I have a long list of potential features that didn’t make the cut for the first release. If you have an Android device please try out the app, please donate if you like it, give us a review on Android Market and let us know about any improvements you would like to see in future versions.

Finally I’m wondering whether similar apps could benefit other charitable institutions using this payment model; one obvious candidate would be the National Museum of Computing (based on the Bletchley Park site but not sharing any of their government funding). Perhaps a Colossus simulator, what do you think?

Although I have sat in many export control meetings with lawyers over the last twenty-some years, I have to point out that I am not a lawyer, and this is not legal advice. I just thought it might interest others if I share my thinking on the current regimes of export controls, as I’m now in the situation of needing to consider it (again) as we want to publish an Android app that contains cryptographic technology (a simulation of a World War II Enigma machine, more on this soon…)

The main things I’ve learned about export controls on cryptography are that common sense often doesn’t apply and nothing is ever simple.

The first complication is: what counts as export? Especially in these days of cloud computing, national boundaries are effectively invisible; I’m sitting in the UK typing this, and WordPress is automatically saving drafts of the article, and I have absolutely no clue which country it’s storing it in. (IP2Location says the current IP addresses for wordpress.com are in Texas and New York, but that’s just the front end, it could change at any time and their database could be anywhere…) According to the US regulations, the nationality of the recipient also counts, even if they are physically present in the exporting country. I’m going to make my first dangerous leap of logic here, and assume that for the purposes of publishing a smartphone app, what matters is the nationality of the author (where the company is registered, if it’s a company) and the nationality of the distributor (e.g. Google, Apple or Nokia) and every download is a possible export (as there’s no way of knowing the nationality of the downloader).

So, our company is registered in the UK and Google is registered in the US, so we have to worry about UK export regulations and (as Google helpfully points out) US export regulations. The UK regulations presumably govern the upload from my development machine to the Android Marketplace, and the US regulations presumably govern the download from the Android Marketplace to the user’s phone. So far so good.

The second complication is: how can we tell if our app falls under these regulations? 20 years ago it was a simple decision: does this product use any encryption or doesn’t it? Today there are many, many smartphone apps that contain or invoke encryption code; anything that uses the HTTPS protocol to talk to a server, or anything that sends an SMS would do. Clearly the vast majority of these apps aren’t considered export controlled, and the reason is that the regulations now have long and complicated lists of exceptions.

The UK and the US are participants in the Wassenaar Arrangement along with 38 other countries. This defines best practices and guidelines for national export control legislation, and includes a control list with a six-page definition of “Information Security” goods and technologies (Category 5, Part 2, starting on page 83 of the December 2011 version). Section 5.D.2 covers software, so that’s the part we’re interested in. “Note 3″ on page 83 says 5.D.2 does not apply if the product is “generally available to the public…” (and a few other conditions that are clearly satisfied by apps distributed in a public app store, I won’t quote it all). At this point you might think: great! we’re home and dry but…

The third complication is that each country must enact its own regulations based on the Wassenaar recommendations, they all have their own spin on it, and they may use different revisions. A brief history of the Wassenaar control list Category 5, Part 2, follows:

1996: Initial version defining what is controlled, with relatively few exceptions (notable ones are use specifically for authentication or banking).

1998: Adds exceptions for personal export for your own use (“Note 2″) and for items generally available to the public (“Note 3″). However, the note 3 exception specifically doesn’t exempt items using symmetric keys longer than 64 bits.

2000: The note 3 exception no longer depends on the key length.

2009: Introduces a new exception (“Note 4″) relating to the primary purpose of the item. As long as the primary purpose isn’t information security, or providing a platform for other components to do information security, you’re not controlled.

With this in mind, we need to look at the specific regulations in place in the UK and US. The UK equivalent to the Wassenaar Arrangement control list is the Consolidated UK Strategic Export Control Lists and the part defining Information Security Software in the current (August 2010) version is Category 5, Part 2 on page 184. This is copied verbatim from the EU Dual Use List of May 2009 (page 167) and that uses the wording from the 2000 version of the Wassenaar control list. As this includes note 3 without the restriction on key length, our generally available smartphone app is not export controlled. Tick!

Now for the US regulations. The US Commerce Control List was last updated in June 2010, and seems to be based on the wording of the 2009 Wassenaar control list. However, there is a qualification to note 3 stating you “must submit a classification request or encryption registration to BIS” if your generally available item uses symmetric keys longer than 64 bits, etc. (a bit of a throwback to the 1998 version of the Wassenaar list). Of course this doesn’t say anything about Enigma machines, and who knows how long they think the keys for those are? (I was intrigued so I looked in to that here). Luckily, the US regulations do include note 4 from 2009, and that means our Enigma simulator is not export controlled because its primary purpose is not Information Security (it’s education and entertainment). Phew!

So we’re in the clear, but what lesson can be drawn from this? I’d say the chances are that, whatever your app does, if you publish it on an app store it won’t be export controlled; even so, you do need to think about it and don’t just click past the “I comply with US export controls” box. If your app’s purpose is primarily information security (file encryption, encrypted email, that sort of thing) then you may well be required to file with the US Bureau of Industry and Security in order to be compliant.

• “The number of pieces of new mobile malware in 2010 increased by 46 percent compared with 2009″
• “Of the almost 55 million total pieces of malware McAfee Labs has identified, 36 percent was created in 2010″

That is clearly intended to make people think 46 is bigger than 36, so the bad guys must be concentrating more on mobile malware now, and that’s what most of the news outlets are reporting, but that conclusion is ABSOLUTELY WRONG.

You can either say that mobile malware increased by 46% and overall malware increased by 56% (36/64), or you can say that 32% (46/146) of total mobile malware was written in 2010 and 36% of total overall malware was written in 2010.  Mixing the frames of reference is obvious misdirection, and that’s even before pointing out that total mobile malware, according to their own statistics, is less than 1000, whereas total non-mobile malware is nearly 55 million!

McAfee’s full report is here.

I don’t really blame Google for not announcing the details of fixed security vulnerabilities though; the reasons are clear, and pointed out in the EFF post (inability to patch operator-customised ROMs). The Symbian Foundation faced the same dilemma, but didn’t recklessly say they were going to announce fixed security vulnerabilities in the first place! Google should at least be honest about their policy.

That said, I disagree with the EFF on two points:

Firstly they state that “the security of mobile operating systems is not as mature or as strong as that of workstation and server operating systems.” I think in many ways it is more mature, specifically having learned the lessons of poor desktop security in the past and benefiting from several control points that PCs do not have. The vast majority of mobile malware consists of trojans (indeed all of the Symbian malware that I know of) which don’t exploit security vulnerabilities in the operating system anyway, so their conclusion doesn’t follow.

Secondly, they seem to be recommending that people “jailbreak” their phones: “it is not a violation of the DMCA to jailbreak your mobile device to install third-party patches”, assuming that third parties will develop and distribute security patches that the device manufacturers will not. Jailbreaking the phone can have its own security issues, and I see no evidence that the open source community has any interest in contributing security fixes to mobile phone OSes (the Symbian Foundation didn’t get any such contributions).

Disclosure is no guarantee of security, as Alec Muffett recently reiterated. While I agree with the general concern about the difficulty of creating security patches for mobile phones, and would welcome architectural improvements to make patch creation easier, I think the EFF are seizing on this issue to advance their own political agenda, and I don’t believe it would have any significant effect on the current volume of mobile malware.

There are many control points which exist for phone software but not for PCs:

1. Software has to be explicitly installed before it can run
2. Applications are usually sandboxed or run with limited privileges
3. Applications are typically reviewed before publication (by app stores or signing schemes)
4. The channels by which malware could spread most widely are managed networks
5. Rogue applications can be recalled (revocation or kill switches)

Of course, none of these control points completely prevents malware, but there is considerable defence in depth. For the first two controls above we rely on the phone firmware, so if and when flaws are found the bad guys can exploit them for as long as the flaw remains unpatched. The other three measures, however, involve human intelligence responding to threats, and this is where the landscape is greatly different from PCs.

One of the inevitable truths of the malware industry is that there are many attackers, and some of them are quite clever. We have seen this in the last year, especially in China where control 3 doesn’t generally apply (there is, let’s say, a “freeware” culture where applications are typically downloaded from file sharing sites). Express Signed for Symbian allows applications to be distributed without waiting for human review (a percentage of submissions are audited after the fact, but there is always a backlog, and by the time abuse of an account has been identified the malware will already have been in the wild, sometimes for weeks).

Automated checks to filter out suspicious submissions can be, and have been, put in place but it’s usually a matter of days before the attackers figure out how to get around them; as Bruce Schneier often points out (albeit in another context) simply responding to the tactics of the last attack is not effective at addressing the underlying threat.

There is a need and an opportunity here. We need to deploy human intelligence in defence to counter the human intelligence of the attackers, but as we have experienced, there are many more attackers than defenders; it’s simply not feasible for someone to examine every version of every phone application to decide whether it’s malicious or not. The need is to magnify the effectiveness of the defenders by making it easier for them to do what humans do best: spot patterns.

The opportunity I see is to take advantage of Business Intelligence (BI) techniques to create visualisations of data about the large numbers of applications submitted to certification schemes, which would allow likely trends and anomalies in the submissions to be identified and then selected for further scrutiny. I’m quite excited about this, as it’s an ideal area for my wife’s and my new business, her area of expertise being BI, and mine being mobile device and information security (as I hope regular readers will already have spotted )

So, to return to the title of this blog post, I can confidently say there will, again, be no mobile malware pandemic in the coming year. Whether or not the BI visualisations idea pans out, the environment for mobile phone malware still has the control points which enable an effective response to new threats in a way that the environment for PCs does not. We, the good guys, will be staying vigilant, so we wish you all a happy, prosperous and secure new year

I’ve been thinking for some time that we co-authors of the book should put together an article covering the lessons learned from nearly 5 years of the Symbian platform security architecture in the field; there are certainly some things that, in hindsight, I would choose to do differently. Maybe we can use this wiki to make that a living document!

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.