RSS Feed
Download our iPhone app
Browse DevX
Sign up for e-mail newsletters from DevX


Legitimize Your Mobile App: Get It Signed

Signing your mobile application is a critical precursor to distribution. Here’s a handy reference to application signing for today’s mobile platforms.

f you're just setting out to develop your first mobile application, you may still be grappling with the fundamentals of installing SDKs, obtaining hardware, and scaling your application to the limitations of today's mobile platforms. One thing you may not be considering, however, is signing your application—cryptographically endorsing it with an identifier that others can use to trace its origin to you.

This article reviews why application signing is important, and provides a reference so you can determine the steps necessary to sign your application for today's leading mobile platforms. Armed with this information, you'll be ready to distribute your application.

Why Sign Your Application?
You might be wondering why the code signing process is even necessary—after all, the mainstream computing market has existed for years with no comparable analogue. Do mobile platform providers and carriers foist application signing on you just an additional barrier to entry?

In a word, no. Code signing provides stakeholders throughout the value chain—application testers, carriers, and users—with a clearly defendable trail of entities that have contributed to your application. By signing your application, end users can verify that your application is actually from you, and easily determine whether an intermediary has tampered with your application. Even more important, the signatures others apply to your application—such as application testers and the carrier distributing your application—provide the user with important information about the reliability of your application.

This second fact is key. On today's mobile platforms, a number of applications may not be permitted to run without the appropriate signatures. Platform interfaces requiring a user's trust (such as those that access device location or private data such as your contacts) may require additional credentials—provided through signing—in order to operate. If you don't correctly sign your application, and obtain signatures from appropriate entities such as testing houses and carriers, it won't have access to the interfaces it needs to deliver value to your users.

Critics may charge that this use of application signatures leads to closed platforms, but the anonymous and unverifiable alternative simply doesn't scale to the billions of wireless devices on the market today. Without some kind of access protection and non-repudiation scheme in place, users and network operators must simply trust every application equally or limit platform functionality to protect the network and end users.

As an aside, code signing isn't just for mobile platforms, either. Major platforms including Microsoft Windows and Mac OS X now provide facilities for code signing, and vendors warn developers that in the future, code signing may be required in to access specific APIs, in much the same way that many mobile platforms do. In the future, expect signed code to play an important role in software distribution.

How Does Application Signing Work?
Public-key cryptography provides tools that support today's need for trust and security. The basic principle of application signing is simple:

  1. An application developer (presumably, that’s you!) obtains a cryptographic key from a well-known and trusted certificate authority. You keep this cryptographic key to yourself as private knowledge.
  2. Using this private key and a one-way hash of your application, you encrypt the one-way hash, signing your application. This encrypted hash is included when distributing your application.
  3. You transfer the application to the recipient.
  4. The recipient—a testing authority, other agency, or the end consumer—creates a one-way hash of your application.
  5. The recipient decrypts the digital signature you created in step 2 and compares the results with the one-way hash of your application. If the hashes match, the recipient has assurance that the application has been delivered intact and is actually from you.
Of course, this process requires considerable infrastructure—the presence of certificate authorities, the ability for you to securely store your key and use it to sign your application, certificate stores on the end device to manage the chains of keys that prove your identify, and public cryptography algorithm implementations on today's mobile devices. The fact that this infrastructure exists and thrives is testament to the market's demand for authenticity and integrity in today's application distribution environment for wireless devices.

The signing process can be repeated at various steps through the value chain. For example, a testing house will apply their signature to your submitted and tested application after it passes their rigorous testing; later, consumers of your product can verify their signature to ensure that the version of the application they're about to execute has met the testing company's standards.

When signing an application for a mobile device, you follow essentially the same steps just described, using keys obtained from specific sources (such as Verisign or Thawte) and tools provided by the platform vendor. Unfortunately, the sources of both keys and tools vary from platform to platform, making the process a perplexing one. For example, if you're an accomplished BREW developer, you may be somewhat puzzled the first time you need to sign a Java ME application. Note that some platforms—notably Android—let you self-sign your applications, using locally generated keys. Self-signed applications are a compromise between convenience and trust, because they spare you the time and expense of working with a certificate authority to prove your identity and obtain a key. This means that it's easier to create a self-signed application—but because anyone can do it without proving their identity, it's easier to spoof a vendor's identity.

Typically, application signing is the last step before a submission for certification, because you can't make changes to a signed application (you'd break the one-way hash you create during the signing process, breaking the chain of integrity the very process is meant to ensure). Because application certification is so closely related to application signing, most developers conflate the two. They are, however, two different processes—you sign your application so that the tester and others can definitively identify the source of the application. Once your application is signed, you have a third-party certify your signed application to meet specific operational standards set by the carrier or other channel that will distribute your application. The discussion that follows focuses on the application signing process, but also provides some information about the certification submission process for each platform, because it does you little good to have a signed application ready for certification, and no idea how to get it certified!

Close Icon
Thanks for your registration, follow us on our social networks to keep up-to-date