Code Signing in Adobe AIR

Application Identity

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:

• Securely identify an application during an update. An application can only be updated from an AIR file containing an application with the same identity.
• Securely identify an application via the browser API. This API can be used in Flash-based web content to install, detect, and launch applications from the web browser.
• Securely identify an application for interprocess communication via the LocalConnection API. LocalConnection can be used to send messages between running AIR applications and Flash-based web content.
• Securely identify an application for purposes of accessing encrypted storage via the EncryptedLocalStore API. Logically, this secured identity is a combination of the publisher's identity and the application's ID (as declared in the application descriptor).

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:

1. Compute the SHA1 hash of the root certificate's public key.
2. Moving down the chain, compute the SHA1 hash of its canonical distinguished name and concatenate the result to the previous value.
3. Compute the SHA1 hash of the result.

Publisher Identifiers and Certificate Expiration

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.

Developing with Publisher IDs

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:

1. You might already know it. Remember, publisher IDs are tied to your signing certificate—not the signature. If you use the same signing certificate across multiple applications, they all have the same publisher ID.
2. You can determine it at runtime via the NativeApplication.publisherIdentifier property, assuming you're running an installed copy of the application.
3. You can read the publisher ID directly from an installed application in the METAINF/ AIR/publisherid file. (This is inside the Contents/Resources directory on Mac OS installs.)

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.