In the spirit of “divide and conquer” I’d like to try again to focus on just one out of the many sub-topics that whirl around discussions of Symbian Signed. On this occasion, the particular sub-topic is:
- Is there merit in using (or modifying) Symbian Signed processes to reduce the prevalence of pirated Symbian applications?
I stated the underlying requirement as follows in “Symbian Signed basics“:
c. Reducing the prevalence of cracked software
To make it less likely that users will install “cracked” free versions of commercial applications written by third parties, thereby depriving these third parties of income.
The idea is simple enough:
- A developer D0 creates an application A0, has it signed, and sells it for a fee
- To avoid users making and distributing copies of that application, without paying additional fees to the developer, the developer includes an element of copy protection in the application
- This restricts the application to run on a device identified by (say) an IMSI or an IMEI
- Some users will be developers in their own right, who possess the programming skills to alter the application to bypass the copy-protection code, creating a cracked version A1
- In principle, A1 can be copied and will run on a wider number of devices, thereby depriving the developer of additional income
- However, because A1 is a tampered version of A0, the original signature is no longer valid, so A1 will fail to install.
On the other hand, any developer D1 can access the Symbian Signed mechanism to put a different signature onto the application A1, thereby completing the circumvention of the copy-protection mechanism. The lower the expense of obtaining a signature, and the easier that process becomes (for example, by removing an independent testing phase), the more likely it is that cracked but installable applications (like A1) will circulate.
This is where the requirement to “make it easier for developers to carry out widespread beta testing” comes into tension with the requirement to “reduce the prevalence of cracked software”.
OK, having laid out the context, it’s time for me to state my own opinion on the matter.
I suspect that piggy-backing on Symbian Signed is probably not the best route for a developer D0 to avoid pirate versions of their application A0 circulating. That’s for the following reasons:
- It seems inevitable that the Symbian Signed mechanism will continue to become cheaper and easier to operate – in order to address the huge demand to “make it easier for developers to carry out widespread beta testing”
- The only kinds of apps which will be difficult for cracker developers D1 to re-sign are those which make use of some high-powered capabilities (like AllFiles or DRM or TCB), which in turn only apply to a small proportion of applications like A0.
So developers D0 ought instead to seek to use other copy-protection mechanisms – such as those involving DRM.
At the same time, the pressure for users to seek free copies of applications will reduce, provided the prices levied for these applications seem reasonable to large numbers of users. In turn, one thing that will allow these prices to remain low is if the population of users buying the applications is large, and if there is an efficient marketplace mechanism (akin to the iPhone AppStore) for users to discover and purchase applications.
(Aside: One more avenue to explore is if mechanisms could be put in place for developers to earn a proportion of ongoing network data or advertising revenues from the use of their application.)
To summarise: I’d like to take the question of “Reducing the prevalence of cracked software” off the Symbian Signed discussion table. (But I remain open to being persuaded otherwise.) That table is already cluttered enough, and the more we can remove from it, the easier it will be to reach a satisfactory consensus view.
Footnote: This posting is #3 out of N I expect to be making about Symbian Signed, where N could become as large as 10.
dw2 
What would be a lot more useful would be if Symbian made the API’s to read the install registry avaliable to non partners so we could actually check to see what cert the application has been signed with.
Comment by pault — 25 December 2008 @ 1:08 pm
Hi Paul,
In the Symbian Foundation world, all APIs will be visible to all developers, so all developers will be able to utilise even those APIs that are earmarked as “Partner”. However, there will still be a difference between the “Public” and “Partner” classifications: only the former fall under the guarantee of binary compatibility (BC). Lowering the number of APIs that have a BC guarantee provides some extra flexibility for the implementers of future versions of the platform. (See slide 20 of the presentation by Charles Davies from the San Francisco Symbian Partner Event, here.)
This still leaves the question: should the APIs to read the installation registry fall under Public or Partner classification?
I can see the merit of an application checking which certificate it has been signed with. But would that be sufficient to prevent application piracy? Couldn’t a cracker alter an application to circumvent the code that did that checking?
// dw2-0
Comment by David Wood — 25 December 2008 @ 2:43 pm
I agree with David. Its not a big problem for a cracker to disable any security check in application code.
Comment by truf — 25 December 2008 @ 5:28 pm
“On the other hand, any developer D1 can access the Symbian Signed mechanism to put a different signature onto the application A1, thereby completing the circumvention of the copy-protection mechanism. The lower the expense of obtaining a signature”
When this is discovered (or reported by D0) why can’t Symbian stop D1 from signing further applications? D1 is known because they have a publisher ID and revocation would act as a disincentive to any Dn thinking of doing this.
Comment by Simon — 26 December 2008 @ 6:46 pm
Hi Simon,
>“When this [piracy] is discovered (or reported by D0) why can’t Symbian stop D1 from signing further applications? D1 is known because they have a publisher ID and revocation would act as a disincentive to any Dn thinking of doing this.”
I confess that if I had thought more clearly about this question before writing my posting, I would have written it a bit differently. But there we go – “blog and learn”.
I’ve addressed the general topic of revocation in a later posting, “Revocation infrastructure”.
What you propose makes good sense. It will require, however, a new level of seriousness in moving quickly and decisively to revoke people’s publisher ID rights. We would have to be ready to revoke potential large numbers of publisher IDs.
I wonder what impact this would have in the field of freeware publishing – when developers generally don’t have their own publisher ID, but rely on the good will of a third party to publish the application on their behalf.
I can foresee cases when a well-meaning third party publisher of freeware objects to having their own publisher ID revoked, on account of the misdeed of a piece of freeware they published.
// dw2-0
Comment by David Wood — 28 December 2008 @ 11:51 am
The whole issue about pirated software has nothing to do with Symbian signed but everything to do with Devcerts.
Once a devcert is in place for a phone, the person can sign any sis file they like without recourse to using the Symbian Signed portal and the supposed security this brings (eg Uid checking) This goes back to my first post which by being able to check what the application was signed with would make an extra layer of complexity in removing pirated software.
A cursory look around the web will show just how broken the devcert and publisher id method is.
Don’t believe me? Try searching ebay.com for “Symbian” and see (or a few other far eastern websites who shall remain anonymous).
And just to continue, why can’t Symbian signed have some of these warez sites shut down. There is one notorious site which has been up for ages and includes downloads and full instruction on how to install and sign cracked applications.
Comment by pault — 29 December 2008 @ 9:02 am
Hi David,
I have to agree with you that there’s no point in people trying to piggy-back Symbian Signed to protect their applications against cracking. Developers need to secure their own applications but I believe the Symbian Foundation can help.
>> So developers D0 ought instead to seek to use other copy-protection mechanisms – such as those involving DRM
This isn’t really going far enough, since then every developer has to become a security expert. Providing the infrastructure and education materials to assist developers here would add a lot of value to the platform IMHO.
I’ve written about this before here:
http://blogs.forum.nokia.com/blog/mark-wilcoxs-forum-nokia-blog/2008/08/02/open-license-manager
The providers (such as app stores or AV solution vendors) discussed in your revocation infrastructure post could add plug-ins to the central license manager (which would require DRM capability or similar, preventing anyone from installing such things without going through official channels, while still keeping the system open). This isn’t really the place to go into technical details though.
Mark
Comment by m_p_wilcox — 29 December 2008 @ 2:23 pm
Hi Mark,
>"Developers need to secure their own applications but I believe the Symbian Foundation can help…
>"Providing the infrastructure and education materials to assist developers here would add a lot of value to the platform IMHO.
>"I've written about this before here.”
The Open Licence Manager is an interesting concept. As I understand it (from the discussion in the above-linked thread), it would be a highly trusted addition to the operating system, that allows applications to check that the user possesses a suitable licence, before the application will run. Usually, the check would be local to the phone, but in some cases, the check could involve an OTA lookup.
The key idea is for the operating system to securely embody the best practice that individual mobile applications (or sub-platforms for mobile applications) have already worked out, regarding distributing licences.
I guess that installing licences would be a bit like installing certificates, and a run-time check on a licence would be a bit like a run-time check on a certificate. I’ll need to get my head round the nature of the differences. This deserves its own top-level post.
Hi Paul,
>"why can't Symbian signed have some of these warez sites shut down. There is one notorious site which has been up for ages and includes downloads and full instruction on how to install and sign cracked applications."
I agree that the continuing flourishing of these sites is a clear sign of the overall system not working properly.
// dw2-0
Comment by David Wood — 30 December 2008 @ 5:37 pm
Hi David,
I believe that any protection scheme against piracy has to deal with 2 issues: the app should somehow determine if there is a valid license present and there must be a mechanism in place to prevent hackers from circumventing that check.
A license manager that comes with the platform could take care of the first issue, by perhaps using some privileged storage to keep track of the run count, expiration date for trial versions and provide APIs for developers.
The second issue perhaps can be solved through an even more advanced version of Symbian Signed. Currently a hacker could dismantle a legitimate SIS and hack the binary image of EXEs or DLLs to disable any license check, then re-sign the hacked version and distribute it. Perhaps we could modify the build process so that it takes into account the developers’ certificates and all binaries get signed to prevent tampering with by hackers. The mechanism should ensure that only binaries that went through the full build cycle, starting with the code, get accepted.
Comment by Bogdan H. — 2 January 2009 @ 7:12 pm
Hi David,
I think the whole story of signing as a deterrent for cracking/pirating can be easily summed up in a sentence: Just don’t depend on it.
The fact of the matter is, no matter what you do, there will always be people (some of them quite intelligent) out there to circumnavigate whatever the latest flavour of copy protection, anti hacking measure etc. is.
What you want is a simple system, that will prevent the casual hacker from having a field day, without making the whole process of software development and deployment complicated and accept the fact that piracy will take place. What anyone should be striving right now is to make developing and deploying software for Symbian OS simpler and nothing else.
Also note that the PC industry, which has the highest number of pirated applications available, with most popular software released along with zero day hacks, you’d see very few rants and complaints coming from the developers of the software themselves, as they’ve already learnt to accept and create a business model for software that acknowledges piracy as an inevitable part of the game.
Comment by tanzim — 3 January 2009 @ 12:14 am
I agree that conflating Symbian Signed with anti-piracy is not a good idea. However, there is a need for some anti-piracy help from the OS, such as the framework Mark suggests. The problem isn’t just that all developers need to become security experts. It’s that the anti-piracy mechanisms need to interact with the path by wihich the app is sold, as that’s the only way it can be established what is and is not a legit copy of an app. Currently apps are sold via a range of methods (operator portals, off-deck portals, side-loading etc) so there’s a need for standardisation so that each sales path can implement the ‘standard solution’.
People will argue that a standard cross-platform DRM solution provides an unacceptably large and attractive target for crackers, but currently it’s logically impossible to do anything because to do so involves agreeing technical details of the DRM with all the sales channels being used, and that’s not practical.
Comment by Leon — 6 January 2009 @ 12:00 pm
I think the open rights stuff is OTT. The only gateway to the phone is via the software installer, so by controlling which applications can be installed you can prevent a large class of rogue applications. (Obviously keygens are still a problem)
The simple expedient of linking a range of UID’s in a devcert extension field to the UID3 of the binaries in an application would stop unauthorized applications being installed as you would never be able to install devcert signed code for uids you do not own.
Comment by pault — 6 January 2009 @ 12:08 pm