|
Adobe AIR requires that all AIR-based applications be signed for to secure delivery.
September 01, 2008
URL:http://www.drdobbs.com/web-development/code-signing-in-adobe-air/210004209
Oliver is a senior computer scientist at Adobe Systems. He can be reached at [email protected].
Adobe AIR, Adobe's platform for building desktop applications from web technologies, requires that all AIR-based applications be signed to secure delivery. By signing an application, the application's publisher securely associates their identity with the application. For example, eBay signs its AIR-based eBay Desktop application before making it available for download. When users install the application, AIR uses the signature to confirm eBay's identity as the publisher and to confirm that the application has not been tampered with in transit. This confirmed identity is displayed to the user as part of the installation process.
Using signatures only to detect tampering, without also establishing a trusted identity, is not an interesting guarantee. If you don't know who signed an application, you can't be sure the application hasn't been tampered with, even if the signature is valid. The attacker might have simply resigned the application after tampering with it.
But while Adobe AIR application signatures can tell you who published an application, they don't tell you whether you should trust that publisher. Signatures also do not in any way make the application safer to run. A signed application published by "Evil Intruder, LLC" is just as likely to be malicious as an unsigned application from the same publisher and is just as capable of doing harm to your computer.
A signature is said to be "trusted" when that signature accurately declares the identity of the publisher. This is not the same as trusting the application.
There are two ways in which trust in a signature may be established.
Although it might be surprising at first glance, a certificate claims to establish an identity by simply including the name of that entity in the certificate. That's right: Anyone with access to a computer and a modicum of know-how can produce a perfectly valid certificate that claims it belongs to you. Establishing trust in an identity is about determining whether to believe what a certificate says. Trust in a certificate is established by linking the certificate in the AIR file to a list of trusted certificates maintained by the operating system. On a typical computer, this certificate store comes populated with the certificates of various certification authorities that the operating-system publisher has decided should be trusted. For example, this certificate store typically includes a certificate for Verisign that lets your computer—without additional setup—establish a trusted identity for many of the secure websites that you visit. You can modify this list of certificates, although most users don't.
Adobe AIR considers a certificate to be trusted if either the same certificate is stored in the system certificate store as a trusted certificate, or if it is possible to establish a certificate chain from the signing certificate to some trusted certificate in the system store.
In a certificate chain, each certificate is signed by another certificate, which is in turned signed by another certificate, until you reach a trusted root certificate. Typical chains contain only three certificates: the publisher's certificate, one intermediate, and the root. So long as the root is trusted by the system, the intermediate and the publisher are also trusted. Certificates that are not trusted via a certificate chain—and therefore must be listed directly in the certificate store to be trusted—are often referred to as "self-signed" certificates. Rather than being signed by another certificate—a certification authority, for instance—they are quite literally signed by themselves. This self-signature doesn't provide for a chain, but it does provide a way to detect any tampering with the certificate. "Self-signed" is sometimes used to mean "untrusted" because, by default, self-signed certificates are not trusted in your certificate store. The two are not really the same thing. All certificates must be signed, and the root certificates for all certification authorities are also self-signed. While most self-signed certificates are not trusted, many of the most important certificates are.
Adobe AIR does not provide any facilities for directly managing trusted certificates and, therefore, no facilities for managing trusted identity. These facilities are already provided by your operating system, along with tools that you or an administrator can use to add and remove trusted certificates.
If a commercial certification authority issues the certificate that was used to sign the application you are installing, you probably won't have to take any additional steps to have that certificate be trusted on your system. The certification authority is probably already entered in your system store. Both Windows and Mac OS come preconfigured to trust certification authorities selected by the operating system vendor. If not—say, you received your friend's certificate on a USB drive at the coffee shop—then you make that certificate trusted on your machine by loading it into the system certificates store. On Mac OS, you do this via Keychain; on Windows via Internet Options.
Trusting identity is one thing; trusting software is quite another. For example, I trust the eBay desktop application because I believe eBay would not deliberately publish a malicious or otherwise dangerous application. Establishing that eBay signed the application I'm about to install is a requisite first step to trusting the application. The rest of my decision hinges on my knowledge of eBay, its reputation as a company, and how paranoid I am.
An established identity is just as key to establishing a lack of trust. For example, I wouldn't be willing to install an application just because I knew with certainty that Evil Hacker, LLC published it. All the same, I would be glad that their identity had been established: I believe they would deliberately harm my machine and I don't want to be installing any of their software.
You can create your own certificate using a variety of tools, including the free Adobe AIR SDK. This option is free and fast, but because a commercial certification authority has not issued these certificates, they will not be trusted on most machines. Certificates can also be purchased from certification authorities. Thawte (www.thawte.com), for example, offers a certificate purchase process specific to Adobe AIR. Certificates issued by commercial CAs are trusted on most machines.
Regardless of how they are obtained, certificates are issued for different purposes. Adobe AIR requires certificates that are specifically designated for use in code signing. For example, you can create a certificate for signing documents with Adobe Reader, but this certificate cannot be used to sign AIR applications, as the intended purposes differ. Code signing certificates are generally interchangeable; Authenticode certificates (www.authenticode.com), for example, can be used to sign AIR applications.
The technical process of obtaining a certificate can be listed as four basic steps:
If you create your own certificate (for example, via the "adt" tool in the Adobe AIR SDK, www.adobe.com/products/air/tools/sdk), then these four steps happen at the same time. The output of the adt command to create a new certificate is the keystore created in step 4, containing both the certificate and the new private key. The certificate is signed with its own private key in step 3, which is why certificates you create in this manner are called "self-signed." If you purchase a certificate, then these steps are somewhat more involved and begin with determining your purchasing process. Although this may seem surprising at first, it is your browser that handles the client-side aspects of each of these steps. Less surprisingly, not every certificate purchasing process is compatible with every browser. The Adobe AIR process provided by Thawte is compatible with Mozilla-based browsers, such as Firefox. We selected this process in conjunction with Thawte because it provides a uniform purchase process across all platforms Adobe AIR supports. Other types of code signing certificates have other browser requirements. For example, purchasing Authenticode certificates—Microsoft's branded version of code signing certificates for use on Windows—requires the use of Internet Explorer. Imagine that.
Adobe collaborated with Thawte, a member of the Verisign family, to create a process for purchasing certificates for use with Adobe AIR. Obtaining a certificate via this process consists of the following steps. These are not detailed instructions; for that, please see the documentation. This list is just intended to give you a feel for what's involved.
Now you have a usable signing certificate. However, you should consider moving your key to a hardware-based keystore.
You aren't required to purchase an Adobe AIR Certificate from Thawte. You can use any certificate that is intended for code signing as designated by the extended key usage field in the certificate itself. Most certificates sold as code signing certificates qualify, including ones you might already own.
For purposes of example, here are the basic steps required to use an Authenticode certificate with Adobe AIR. Note that it's really just a matter of getting the certificate into an appropriate format.
However you obtain your certificate, you need to e nsure that the final keystore contains a full certificate chain.
Signing can be performed using a variety of applications including Adobe Flex Builder, Adobe Flash, Adobe Dreamweaver, and Aptana. All of these applications rely on the adt tool, which is freely available as part of the Adobe AIR and Flex SDKs.
Adobe AIR uses certificates to establish a trusted identity for an application not only at installation time but also for the entire lifetime of the installed application. This is accomplished by binding information from the certificate to the application's identity. Application identity is critical because it impacts features like updates, invocation, and interprocess communication. For example, application identity is used in the following (not exhaustive set of) circumstances:
It is perhaps most straightforward to think of the application ID as being scoped by the publisher's identity. Two publishers can both give an application the application ID "HelloWorld", but the two applications still have different identities. It is generally convenient to be able to represent an application's identity as a string. For example, this string form is used in both the browser API and LocalConnection API when identifying an application. Adobe AIR defines the following string form for this identifier:
<application-id>.<publisher-id>
Again, <application-id> is simply chosen by the publisher and declared in the application descriptor. The string form of the publisher ID is computed from the signing certificate as follows:
The details of this algorithm are heavily influenced by the fact that certificates expire, and so one cannot simply use, for example, a hash of the certificate itself as the publisher ID. More general issues around certificate expiration are discussed later. Certificates can be renewed and the publisher's name is the same in the new certificate, but the certificates will not be identical. For example, a new key pair is used and the expiration date has changed. The challenge in designing a stable publisher ID is to make sure it can be preserved across certificate renewal without at the same time introducing any insecurity.
To accomplish this, the algorithm computes the publisher ID using the identifying information in each certificate—the distinguished name—and the public key of the root certificate. During a certificate renewal, these pieces of information do not change. At the same time, they can't be spoofed: No series of authorities as designated by the certificates in the chain would ever issue the two certificates containing the same distinguished names in any situation other than a certificate renewal.
Interestingly, there is often more than one way to compute a validation chain for a given certificate. For example, this can happen when a certificate is cross-certified, in which case the issuing authority's root might not be trusted directly but only because it's signed by a different trusted certificate .
For Adobe AIR, there are two important chains: The one used to establish the publisher ID and the one used, at install time, to establish trust. The former impacts application identity and therefore must not change; this is why it's required to be embedded in the keystore used for signing. It doesn't matter if this chain is trusted at install time. It only matters that the publisher trusts the entities in this chain to properly renew their certificate.
The second chain, built at install time, is used to establish trust. This chain may differ between target machines, assuming it can be built at all. It may or may not match the publisher ID chain, and the presence of the publisher ID chain does not guarantee that a chain can be built at installation time.
Publisher IDs operate in a straightforward way for installed applications, but can be trickier during development. There are two sides to this: your own publisher ID, and the publisher ID for another application you need to communicate with. When you debug an application (started via the adl command), it is not yet signed and so runs without a publisher ID. During debugging, anywhere that a publisher ID would normally be used—for example, in a LocalConnection endpoint name—it is simply omitted. This will change, however—and a publisher ID will be used—once the same application has been installed.
This is often fine, but can be tricky in certain workflows. Suppose you install a version of the application on your machine and then debug the application on the same machine. You might expect both to access the same location as the application's storage directory, but they won't, because that location uses the publisher ID. To work around this, you can specify a publisher ID for debugging sessions with adl's -pubid argument. There are a few ways to obtain your own publisher ID:
Publisher IDs specified to adl are not validated—nothing prevents anyone from entering a publisher ID they don't own. Publisher IDs provide secured identity for installed applications; they don't provide any guarantees with respect to applications being run with the debugging tools.
If you need to communicate with another application—for example, to address it via LocalConnection—then you need its publisher ID as well. If you've installed that application, you can find its publisher ID in the publisherid file, as mentioned in step 3. Even without the application, however, you might be able to obtain the publisher ID from the application's publisher. Publisher IDs do not contain any confidential data and can be comfortably posted on websites and the like.
Key pairs, as used for creating digital signatures, become less secure the older they are. The older they are, the more likely that the private key has been compromised. There is also more signed material with which to attack them and more time in which to execute the attack. Certificates are therefore assigned expiration dates to limit the lifespan of the keys they are associated with.
The expiration date doesn't apply to the time at which the signature is validated, but rather the time at which the signing occurs. So long as a signature is created while the certificate is valid, the resulting signature should not itself expire. Adobe AIR signing tools obtain a secure timestamp during the signing process. The timestamp, which itself contains yet another verifiable signature, proves the time at which the signature was created. Tools for creating AIR files won't permit signing with an expired certificate and, by default, won't permit signing if a secure timestamp cannot be created. Similarly, Adobe AIR installs an application only if its signature was created while the signing signature was valid.
Obtaining a secure timestamp requires contacting a timestamp server made available for this purpose. Adobe has partnered with Geotrust (www.geotrust.com) to make such a service freely available, and it is used by default by our tools.
If obtaining the timestamp fails then signing typically fails, but you can override this behavior and force signing to occur anyway. If you package using the adt command-line tool, you can also specify an alternate timestamp server using the -tsa <url> options. When encountering signatures without timestamps, however, Adobe AIR compares the current time—not the signing time—against the certificate expiration dates. If the certificate has expired, the AIR file will not be installable, even if it was signed while the certificate was still valid. So while this workflow may be useful, if you're unavoidably offline for a short period, you should also avoid ever releasing an application signed without a time-stamped signature.
Certificates are sometimes compromised. For example, they might be stolen or even issued to the wrong party. In these circumstances, the certification authority revokes the certificate by adding it to a revocation list. The revocation listed is hosted at a URL that was already embedded in the issued certificate. If you have a certificate, you already know where to go to check the correct revocation list.
Adobe AIR performs a revocation check when signing and when installing. When online, this generally prevents revoked certificates from being used. Certificate revocation lists cannot be checked directly when offline. Two steps are taken to reduce the chances of a revoked certificate being accepted merely because the user is offline while installing.
Revocation, like signing, is also impacted by time. If a timestamp is available, then the revocation list is checked to see if the certificate was revoked at the time signing occurred. If no timestamp is available, the revocation check is applied to the time at which the application is being installed.
Finally, Adobe AIR's revocation checks are best-effort based. If no relevant CRL can be obtained—whether through the cache, AIR file, or CRL server—the installation is allowed to proceed.
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.
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.
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.
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.
Thanks to Luis Polanco and William Ie for not only their work on this feature, but also their help in preparing this article.
Terms of Service | Privacy Statement | Copyright © 2024 UBM Tech, All rights reserved.