Mobile application signing and certification

Legitimize Your Mobile App: Get It Signed

Source:- 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.

To Barcelona for Mobile World Congress...and back

I was kind of excited about GSMA Mobile World congress at Fira De Barcelona, Spain. I finally made it for the event. The event scheduled from 15th to 18th Feb was a big event, well organized and participated by all the leading firms of Mobile ecosystem. The MWC at Barcelona surpassed my expectations..!!
The MWC 2010 certainly did not disappoint me. It was some of the new handsets that made headlines this year (though several cell phone manufacturers, including Nokia and LG, didn't even have booths) , however the applications/software developed on devices that stole the show.

At MWC, as I understand companies like the spotlight and when it comes to shows like these, big brands always like the best faces market their products and it does pretty good for their publicity. I was part of SAMSUNG Wave booth and you could spot not only phones but also good looking faces at this booth.

Samsung had more in its stand than new slim and shiny Samsung wave, the first handset to run on new BADA operating system. Besides displaying a gallery of handset they displayed range of business applications on their new devices. (Omni II and Scala). It also had suite of consumer apps including social networking, Location aware services to games at its booth. Samsung also unveiled its SAMSUNG Beam, the first android phone with built in projector that caught the attention of all the vistitors.

Indeed, MWC 2010 is a great opportunity to take stock on the state of the mobile ecosystem, and to see what’s coming, both in the coming year and beyond.

Enterprise Mobility Market outlook :2010

Mobility trends for year 2010

by Purushottam Darshankar

Demand in mobility solution is exploding in all industry segments as businesses have started leveraging the enhanced power, ability and reach of the mobile to come up with innovative user-friendly applications. Organizations are only now starting to see mobility as a strategic differentiator. Though diverse device technology landscape may present some challenges, technically savvy small and medium businesses will continue to go for business-on-the-go solutions supporting their mobile workforce.

Smartphone sale will continue to skyrocket and carriers are going to realize that their ARPU will be driven by data revenues. Both business and consumer users never expresses interest in surfing the web on their phone but the acceptance of social networks like Twitter, Facebook and Myspace have pushed the web as must-to-have feature and carriers will figure out the ways to generate revenue other than the data plan.

Apple’s iPhone first shook up the mobile industry in 2007, but Google is slowly starting to become a contender; there are already around 12 Android phones across 32 carriers in 26 countries. In US it will eventually be distributed by all four major U.S. wireless carriers, while Apple is exclusive with AT&T. So although the future for Android looks incredibly bright, let’s not forget there are about 10 million iPhones and growing on the market and over 100,000 applications in the App Store to compete with. Microsoft announcement of WM 6.5 at MWC created big hype only to realize that upgrade is superficial cosmetic overhaul and is incapable of handling the mobile market’s stiff competition. Windows mobile 7 is due next year, why not just wait?

As consumer applications in B2C surges, browser will become a dominant delivery mechanism for reach mobile applications. Though thin client solutions built on HTML5 are paving the way for richer mobile application, smart client applications are not going to go away anytime soon. The recent announcement of the Chrome OS by Google, which is basically a browser on a netbook, that is supposed to ship next year will inevitably put the companies in deeper competition.

2010 year will see the emergence of cloud or SaaS based enterprise mobility offerings. According to IDC report ““almost 40 percent of organizations plan to deploy a SaaS-based mobile solution in the next 12–18 months.” The OEM’s and Telco’s will give a serious look at hosting mobile middleware platforms for connecting enterprise application to mobile devices and offering such services as pay per use model. The platform needs to be multitenant, scalable, secure and flexible to cater to diverse needs of enterprise market. With security and performance enterprise-ready, the cloud is enabling businesses to be more agile, more productive and more flexible. Businesses also benefit from lower IT, energy and real estate costs through data center virtualization.

Companies will develop more innovative applications that get them closer to their customers, employees and partners. As business users have started using their personal devices for business use, Business intelligence (BI) will be increasingly mobilized. Executives will be glued to their mobile screens for the latest statistics on their business.

The focus will be on green, as organizations are sensitive and more aware of reducing their carbon footprint via different methods like reducing paper consumption, reduced power usage, reducing travel etc. Mobility has been well positioned in providing the underlying foundation for more eco-friendly society.

The adoption of mobility solution looks quite impressive but enterprise mobile application market has not yet reached the critical mass. , still plenty of work has to be done, gaps to be bridged, and problems to be solved. With much on the agenda, it's safe to say that 2010 promises to be an exciting year for enterprise mobility.

Meet the founders of OnMobile, IMI Mobile and several other cool mobile companies @ Mobile Apps Conference (October 31, 2009 . Bangalore)

Hey,

Just wanted to let you know about an exciting event siliconindia is organizing on October 31st (Saturday in Bangalore). This is a full-day conference that will explore the new opportunities that are emerging and ask the larger questions of the industry leaders within mobile space, shedding some light on where the industry is headed and how entrepreneurs and developers can take advantage.

Come listen to some of the brightest minds in mobile technology discuss the future of mobile technology.

SPEAKERS
Arvind Rao, Chairman, CEO and Co-founder, OnMobile
Vishwanath Alluri, CEO,Chairman and Founder IMImobile
Vishnu Sunderam, Co-founder CEO, Interchain Solutions
Selvamuthiah Somasundaram, Sr. VP & Co-Founder, Satnav
Raj Oswal, Founder & CEO, O'interface
Dilip R Mehta, IIM Bangalore, Ex-MD RPG Cellular and HMV Saregama
Prashant Dogra, Customer Marketing Manager, Navteq
Shanker Janakiraman, Director & CEO - India, Symbioun Technologies

TOPICS:
Mobile applications explode. Who wins and who loses?
Carriers and handset makers want a piece, too: Where will they go?
LBS Challenge: Maximising Revenue and Engaging the Consumer
Mobile Payment Services: The Road Ahead
Mobile Marketing

Sponsors: Nokia, Sun, Navteq, Satnav
Exhibiting companies: Eterno, iPath, MapmyIndia, Mobikwik, OnMobile, ObjectSol, Satnav, ShortHand, Symbioun, Tencube, Trakut, Trademarkia, Vassoft, Wirkle

WHEN: October 31, 2009 (Saturday)
TIME: 9 AM to 6 PM
WHERE: NIMHANS Convention Center, Near Diary Circle, Bangalore

To attend this event, register FREE at http://www.siliconindia.com/mobileconference/register.php

Choose right device platform for your Enterprise needs

by Purushottam Darshankar

Businesses are continuously looking for cost effective and faster ways to deliver critical functions to their mobile workforce and one of the biggest barrier to its successful adaption has been security consideration. Banking, insurance, investments, retail, healthcare cannot afford to deploy mobility solutions that could possibly compromise on their critical data.

The first step towards making solution secure is to choose the device that exhibits high level of inherent security. The article explores on how BlackBerry, iPhone and Windows Mobile device score on some of the key criteria necessary in selecting the device for enterprise use.

There are different components that make the device platform safe and secure for business use. The most important amongst it is authentication. The robust IT policy would prevent from unauthorized person from accessing the enterprise data. BB (BlackBerry) allows the IT department, through use of the BlackBerry Enterprise Server (BES) tools, to set a policy mandating the user to log in to the device via a strong password. The iPhones require connection to a PC running iTunes for its initial activation with carrier and creates a complete image, including all of the data on the device, thus posing a potential security threat. Windows Mobile does provide for password locking of the device and does support a number of third party applications that create two-factor authentication (e.g., Biometric reader, card readers).

Data storage on the device and external SD card is a key requirement for mobile workforce to access business critical information in offline mode. BB provides ability to encrypt all data on the device, including data stored on SD cards enabling full protection to critical data. The iPhone does not provide data encryption mechanism on the device, either for selected files or for the entire data store. So if an unauthorized user is able to get beyond the password, then all data is exposed to that user. Windows Mobile provides the ability to encrypt peripheral SD cards, although the main memory of the device is not so encrypted.

Enterprise-grade mobile platform should include a method for assessing signatures of application that, when checked by the device, can determine an authentic, non-tampered application from one that has been modified. BB provides an inherent mechanism for verifying the signature of each installed application to assure the application has not been tampered with. Further, IT may enforce policies to allow or disallow individual applications from running on the device.

For iPhone, applications require a digital certificate issued by Apple and to obtain the certificate the company must register with Apple. A Distribution Provisioning Profile must then be created and loaded to each device through end user intervention. There is no direct OTA mechanism for corporate to download the application. Loading applications to the iPhone requires either uploading that application to Apple’s App Store for delivery, or by connecting each device to a PC and “side loading” the application through iTunes. This process requires users to initiate any downloads to the device from their PC or requires that IT retrieve each iPhone and “side load” through a master PC within IT control. However, a “Jailbreak” program is available on the Internet that bypasses the iPhone security and allows unsigned applications to run on the device and thus represents a significant threat to the security of the device.

Windows Mobile has limited ability to verify individual applications. It does allow the “signing” of executables and setting specific policies to limit which applications can run on a device. Windows Mobile does provide for OTA downloading of applications through third party applications, and IT departments can deploy applications on their own without intervention.

A device that cannot be remotely managed will add significant amounts of TCO and additional support burdens to organization deploying it. Businesses evaluating devices should examine whether the device OS offer hooks to manage all aspects of the platform such as device setup, monitoring, uploading, display of device characteristics, asset management, lock-down, software upgrades etc. If such capability is not inherently available within the OS, it is highly unlikely any security and/or management tools will be able to competently manage all aspects of remote management. BB has been designed to be managed by a set of policies that can be easily created and deployed through the standard BES. Polices are delivered OTA directly to the device and configured automatically without user knowledge or intervention required. Data of each device in terms of its memory use, battery condition and overall health is available for analysis. iPhone and Windows mobile has to rely on third party management application for providing the remote management capabilities. Windows mobile 6.0 does make some log files and other hygienic data available to IT administrator.

Many industries require that devices be validated and approved by governmental agencies to ensure that they meet stringent security testing and specifications before they can be deployed to mobile workers. BB has attained numerous validations/certifications for its devices and has the ability to select the most common encryption algorithms (e.g., AES, 3DES) to protect the data on the device, and provides a complete remote device wipe capability as well. Windows Mobile 6 device do provide encryption capability for a variety of common standards (3DES, AES etc.) and do provide for remote device wipe through the ActiveSync capabilities.

While each may have strengths and shortcomings, the most secure platform for business use is the BB platform. Windows Mobile has continued to improve over a period of time and with third party applications one can enhance security majors and consider the platform for mobility deployment.