Legitimize Your Mobile App: Get It SignedSource:- http://www.devx.com/wireless/Article/40418/1954 Signing your mobile application is a critical precursor to distribution. Here’s a handy reference to application signing for today’s mobile platforms.
If 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!
Obtaining a Key
Typically, you obtain a key from a certificate authority, a company whose business is verifying who you claim to be and issuing electronic certificates with cryptographic keys that represent that fact. While there are a number of companies that do this, the three most widely known are VeriSign, Thawte, and GeoTrust. Obtaining a certificate will take time and money, because you're asking one of these firms to originate a key and sign it with their root certificate. While costs vary, expect to pay a few hundred dollars per year and experience a latency of a few days while you get the paperwork in order (typically exchanging photocopies of photo ID, business statements, or phone calls so that the certificate authority can verify that you are who you claim). Moreover, many of the code signing keys you obtain are good only for a set number of uses—you're not given the privilege of signing an unlimited number of applications, and the certificate you obtain is good only for a certain period of time. Thus, maintaining your key is an ongoing part of your business, just like ensuring your Internet domain name remains registered.
When selecting vendors to provide keys for application signing, be careful—it's emphatically not one-size-fits-all. Different devices require different kinds of keys, and if you're a cross-platform application publisher, expect to obtain different keys for different platforms. This can significantly increase the out-of-pocket expense for an independent developer, so it's something to plan for if you're flying solo and planning on releasing your product on multiple platforms.
While you're developing your application on some platforms, signing with a self-generated key is an option. You can generate a key for self-signing using the Java keytool command, included with the Java Developer Kit (JDK) you need for developing applications for platforms including Android and Java ME.
To generate an untrusted key for self-signing, invoke keytool like this:
keytool –keystore key -genkey -v -alias alias -keyalg RSA -validity days
Using keytool, you need to specify an alias, which is the unique name for the key, and the validity (how long the certificate will remain valid in days). For example, this generates a new key in the keystore keys with the alias Yoyodyne using the RSA algorithm that is valid for 10,000 days:
[cdr:/tmp] kf6gpe% keytool –keystore keys -genkey -alias Yoyodyne -keyalg RSA -validity 10000
Enter keystore password: password
What is your first and last name?
[Unknown]: Ray Rischpater
What is the name of your organizational unit?
[Unknown]: Development Team
What is the name of your organization?
[Unknown]: Yoyodyne
What is the name of your City or Locality?
[Unknown]: San Lorenzo Valley
What is the name of your State or Province?
[Unknown]: CA
What is the two-letter country code for this unit?
[Unknown]: US
Is CN=Ray Rischpater, OU=Development Team, O=Yoyodyne, L=San Lorenzo Valley, ST=CA, C=US correct?
[no]: yes
Enter key password for
(RETURN if same as keystore password):
[cdr:/tmp] kf6gpe%
Of course, you should supply your own identifying information to keytool's prompts.
As important as creating the key is, it's equally important that you safeguard it after it's created (or sold to you by a certificate authority). Your reputation as a professional developer hinges on the key, because it's part of the chain of trust between you and your customers. You should take appropriate precautions, including:
• Selecting strong passwords for your key and the keystore containing your keys.
• When using a system shell and a program like keytool to generate a key, do not specify the passwords on the command line, because they are kept in the shell's history.
• Do not give or lend anyone your key.
• Keep backups of your key store in a secure location.
• Use the same certificate for different versions of the same application on the same platform. Not only does this save you money, but on some platforms (Google's Android, for example) it's required for application upgrades.
Signing Android Applications
For a phone to run your application, you must sign it. Unlike some of the other platforms discussed later, Android doesn't restrict application distribution via signing and certificates, so it's entirely possible (and quite common) to use self-signed certificates when packaging your application.
To sign an Android application, you can self-sign your application, or have a company such as Verisign provide a signed key for you to use. Be sure that your key exceeds the projected lifespan of your application—if your key expires, your application will not run. Then, follow these steps:
1. Be sure you have the jarsigner tool installed—it should have been included with the JDK required by the Android SDK.
2. Build your application package in release mode. (You'll be signing the resulting .apk file).
3. Run jarsigner, passing the name of the keystore containing either your self-generated key or the one provided by the certifying authority, the alias for the key your certificate uses, and the name of your application package, like this:
jarsigner –verbose –keystore keys truncheon.apk Yoyodyne
You can verify that you've successfully signed your application by running jarsigner again using the verify switch; if the signing was successful, the tool will print jar verified.
After you've signed your application, you should put it through a final full test cycle before submitting it to the Android Market.
Signing BREW Applications
To distribute a BREW application, Qualcomm and carriers require that it undergo certification by the National Software Testing Labs. To obtain certification, your application must first be signed; to do this you need a key from VeriSign as well as Qualcomm's AppSigner tool, available from the BREW web site.
After you have a key—which Verisign provides through its Authentic Document Service and Personal Trust Agent (PTA)—and have installed the AppSigner, follow these steps:
1. Ensure that your application MIF file does not include a license; if it does, the signing process or subsequent certification may fail.
2. Ensure that your application is packaged.
3. Launch the AppSigner and click the Wizard icon.
4. Choose the type of application you want to sign (BREW, J2ME, PDA, Flash, or Content), and browse for the application folder containing the application you want to sign and then click Next.
5. A file browser will appear; indicate which files should be signed (you must sign your module, resource files, and MIF files, along with any other files destined for the handset) and which files your application is permitted to modify on the device. Once you've marked which files you want to sign, click Next.
6. The signature management window appears; indicate that you’d like to create a new signature file and click Next.
7. The VeriSign Personal Trust Agent window will appear; select your user name from the drop-down list and enter your PTA password, and click Next again.
8. The VeriSign Notarization server processes your request and a status screen will appear. If everything succeeds, you can proceed with packaging your application for submission.
Application packaging for certification requires you to organize your files in a specific way (documentation, simulator, and handset builds must be placed in different folders), and the submission process can fail if you don't do things precisely right. As a result, you should check BREW's web site for the latest "True BREW" certification test guide before submitting your application to NSTL.
Signing iPhone Applications
Apple follows Qualcomm's lead, requiring you to sign applications prior to submission for Apple certification and distribution through the App Store. To do this, you need to obtain a key from Apple through the Program Portal, which you obtain by completing a Certificate Signing Request and obtaining approval from Apple's iPhone Developer program. Once approved, you download the resulting key, which Mac OS associates with the system's keychain, available through the Keychain Access Utility application.
Signing an application for distribution using Xcode is much easier than with other tools, because the entire process occurs within Xcode. Follow these steps:
1. Register an application identifier through the iPhone Developer program.
2. Create a distribution provisioning profile for the application identifier on the iPhone Developer program web site and download it to your build workstation.
3. Add the resulting profile to Xcode by dropping the profile on the Xcode application icon.
4. Open the Project Info window. In the Configurations tab, select Release. Click Duplicate, and rename the new copy to "Distribution"; this build configuration is unique for creating commercial builds.
5. Choose the Distribution choice from the Active Build Configuration pop-up in the main project window.
6. Select the target's Build tab (open the Targets item in the Groups and Files window of the main project window) and select Distribution from the Configuration popup.
7. On the line labeled "Code Signing Identity," change "iPhone Developer" to "iPhone Distribution," or ensure that it reads "iPhone Distribution" if it doesn't already.
8. Select the distribution profile from the Code Signing Provisioning Profile popup.
9. Clean and build your project.
10. Use the main project window's Reveal in Finder menu command to find the application bundle you'll submit to the App Store.
Signing Java ME Applications
Not surprisingly, signing a Java ME application is similar to signing an Android application, because both platforms are Java-based. You begin with a key pair created by keytool, perhaps countersigned by a certificate authority (follow the steps outlined by VeriSign, Thawte, or GeoTrust). Once you receive the digital id (your countersigned key) from the certificate authority, follow these steps:
1. Create a release build of your application (creating the JAD and JAR files).
2. Import the digital id in your keystore using keytool (here, I'm importing a digital id certfromca.ce into my keystore named "keystore"):
keytool –import –trustcacerts –keystore keystore –alias Yoyodyne –file certfromca.cer
3. Sign the resulting JAR file using JadTool:
JadTool.jar –addjarsig –keystore keystore –alias Yoyodyne –jarfile truncheon.jar –inputjad truncheon.jad –outputjad truncheon.jad
You can actually sign a Java ME application using more than one digital ID; this is important if you're delivering your application on many different devices and networks, because different devices and networks may use different certificate authorities. Simply repeat these three steps for each digital id you want to use in the signing process.
Because Java ME applications can be distributed a number of ways (direct download, cable loading, operator stores, and so on), certification requirements vary (although any certification process will require you to sign your application). For details, consult the developer web sites for the carrier networks over which you want to distribute your application, as well as the Java Verified program's web site, which provides an umbrella of authorized testing centers for Java ME application certification.
Signing Symbian (S60 and UIQ) Applications
Today's Symbian-powered devices (including S60 and UIQ) require signed applications as well, although like Android and Java ME, applications can be self-signed. For commercial distribution, if you need a trusted signature, you must obtain a digital id from VeriSign. To sign a Symbian application, follow these steps:
1. Download and save the VeriSign digital id file.
2. Use the Symbian SDK's vs_pkcs utility to obtain your private key and certificate:
vs_pkcs -p12 certfromca.pfx –passwd secret –key key.key –cer cert.cer
3.Build your application in release configuration and create the SIS file using MakeSIS.
4.Run signsis.exe to sign the resulting SIS file:
signsis –o –s –v truncheon.sis truncheon-signed.sis cert.cer key.key password
You don't need to certify your Symbian application prior to distribution in most cases, although access to some APIs may be restricted on some platforms if you don't obtain certification. To certify your application, go to the Symbian Signed web site and follow the instructions there. You'll need to provide a properly signed application package, an indication of which company the Symbian Signed program should engage for the application certification and documentation for your application.
Ensuring Integrity and Security
Application signing is more than an annoyance levied by platform vendors and network operators: it's a crucial part of ensuring the identity of the individual or organization providing an application. By signing your application with the help of a trusted certificate authority, you stand behind your application, adding security for your users and ensuring your share of the value proposition in today's mobile marketplace.
