Hardware versus File Key Storage
Protection of your private key is critical. If it's compromised, anyone who obtains it can assume your identity for purposes of publishing software. If you're aware that your key has been compromised—and if a certification authority that publishes a certificate revocation list issued it—then you can have it revoked. This prevents a good deal of the potential damage that could arise. It's better to avoid such situations entirely. At minimum, your key should always be password protected. If someone made off with your key, they would at least have to crack your password before they could use it.
You should consider using a hardware-based storage option. Unlike file-based storage, your private key can never be extracted from the device once loaded onto it, so the key can't be stolen unless the device itself is stolen. These devices also require a password to use but, unlike file-based solutions, disable themselves if too many incorrect password attempts are made.
The signing tools provided by Adobe are implemented in Java and leverage the pluggable Java Cryptography Architecture (JCA) to support a wide variety of keystores. In addition to the built-in Java Key Store and PKCS12 (PFX) support—both of which are file-based—any hardware solution with a PKCS11 driver or a custom JCA provider can be used. Recent Windows and Mac OS Java implementations also support their respective operating system keystores.
I keep my certificate on an Aladdin eToken, which in turn is locked in a safe.
UI Implications
Adobe AIR displays different UIs during installation of an application, based on whether the application has a trusted identity. If the application's identity is trusted, the publisher's name is displayed, along with a yellow warning symbol intended to caution the user (Figure 1).
If the application's identity is not trusted, the publisher's name is not displayed and a red warning symbol intended to severely caution the user is shown (Figure 2). Publishers are sometimes surprised to learn that an application with a trusted identity is not displayed with a green symbol to comfort the user. Regardless of the trust in identity, however, these applications still run unencumbered once installed on the user's machine. Unlike applications running in a sandbox—web applications running in the browser, for example—some caution is still appropriate.
Deferred Signing
In many organizations, keys are further protected by limiting access to a small number of individuals and keeping them in restricted areas. These persons are typically not the developers and may not be able to package up the assets that compose the application. Adobe's signing tools support these scenarios by allowing packaging and signing to be done as separate steps.
The output of packaging without signing is an .airi file; note the trailing "I" for intermediate. Unlike .air files, .airi files cannot be installed. Their only purpose is to serve as an input for the signing step. Signing of .airi files can only be done with adt; it isn't supported by the authoring tools like FlexBuilder.
Conclusion
Adobe AIR is a revolutionary platform because it does something new—it enables the creation of desktop applications with web technologies. But no new application development platform could reasonably ignore the security issues involved in deploying and updating desktop applications. Adobe AIR provides for secure delivery using possibly the most sophisticated, widely deployed code-signing implementation ever created.
Acknowledgments
Thanks to Luis Polanco and William Ie for not only their work on this feature, but also their help in preparing this article.
