GlobalSign Individual Developer Certificates

I’ve posted several times in the past on the importance of using a trusted certificate, even though obtaining a trusted certificate takes both time and money. While some certification authorities continue to issue code signing certificates only to businesses, I was pleased to learn recently that GlobalSign has joined the ranks of those make certificates available to individuals as well. See the GlobalSign Code Signing page for further information.

Application Update Security and Native Application Installers

New to AIR 2 is the ability to create native application installers. By “native”, we mean that the installers are not .air files, which the desktop operating systems don’t inherently understand, but instead types they do understand: .exe, .dmg, .rpm, .deb.

Applications deployed via native installers do not have access to the Updater API, which is designed to work only with .air files. This is not as restrictive as it might seem, as an AIR 2 application deployed via a native installers has all the facilities it needs to download and launch its own updater.

Applications that take this approach must also take care to secure the download of the update itself. This is handled for you when using .air files and the Updater API. The .air file is signed, and signature validation is performed during the install. None of the contents of the .air file can be executed until after the signature is validated.

The situation is quite different for native application installers: They can generally execute code before signature validation, and may not even be signed. It is therefore critical to make sure that the update you’ve download is valid before opening it. Otherwise, you’ll have created a mechanism that can be hijacked to download and execute arbitrary code.

There are two basic approaches you can use to secure the download path: (a) use an https: download, or (b) sign the download and validate before running. The former is likely easier to set up, but the latter scales better for download support.

If you deploy your application via a native application installer, please take the time to make sure you have a functional, secure update mechanism in place.

Update Strategies for Changing Certificates

As mentioned in my previous post, switching signatures by applying a second signature is a fact of life for updating AIR applications. If you’re creating such an update to your application each time you get a new certificate, then you’ve solved half of the problem. The other half is to make sure you’ve implemented a matching update strategy in your application.

Unlike the signing half, there’s no requirement that each installed application be updated on a regular basis. This would be impossible to enforce, anyway: If a user takes their machine offline for two years, there’s little to be done. To successfully install updates over time, however, you do need to insure that the sequence of updates installed on any given machine includes one update for each certificate transition.

For example, suppose you’ve run through three certificates: C1, C2, and C3. You’ve got a user who has an older copy of your application signed with C1. To update them to the latest version signed with C3, you need to install two updates on their machine:

  1. An update making the transition from C1 to C2
  2. An update making the transition from C2 to C3

It’d be more convenient to create an update straight from C1 to C3 but, in a typical case, C1 will be long expired before you obtain C3 and therefore not useable for this purpose.

Since you can’t assume the jump from whatever version the user has to the latest version is possible, your update mechanism must provide a method of sequencing updates. That can be as simple as changing the URL used to fetch updates each time you change certificates.

This does not mean you need to have users apply all updates to your application, one by one. For example, suppose you issued three updates to your application after acquiring C2 but while C1 was still useable for applying the second signature: Then you can sign each update twice and any user with a version signed by C1 can jump straight to the latest version signed by C2. Again, what they can’t do is jump to any later version that doesn’t have the second C1 signature.

In conjunction with regular updates, an appropriate update strategy will keep application updates a seamless experience for your users.

Update Your Application Regularly

AIR includes an easy-to-use API via which applications can update themselves, and many developers issue frequent updates to their applications. This is not just a good idea: issuing an update at least once each time you renew (or change) your certificate is necessary to maintain the ability to update your application at all.

The issue arises because most code signing certificates are only valid for a limited period of time. (Certificates have to have a limited lifespan in order to keep them secure. The typical lifespan is one year.) Once a certificate has expired, AIR no longer permits it to be used to issue updates to an application. A new certificate has to be acquired, whether as a renewal or as a new purchase.

To secure the transition between those two certificates, at least one update to the application needs to be signed with both certificates, old and new. To facilitate this, AIR does allow the old certificate to be used (for this purpose only) for up to 180 days past its expiration date. In order to issue an update to your application, you must create an update to your application during this period in which both the old and new certificates are valid.

If you fail to create an update signed with both certificates you’ll find yourself unable to update the previous version of your application. You can still have users go through a manual uninstall/reinstall process–basically, uninstalling the old application and installing a new one in its place–but that’s clearly not as desirable.

To keep this all working smoothly:

  1. Replace your code signing certificate when it expires.
  2. Immediately create an update to your application, signed with both old and new certificates, after receiving your new certificate.

Note that you don’t necessarily have to publish the update you create each year, at least not right away. You might wait for a planned product release a month or two later, and apply both signatures to that update as well. Creating the update gives you a backup should you need it. More on this in my next post.

API Tip: Don’t Abuse File.applicationStorageDirectory

It was recently pointed out to me that some applications, which shall remain nameless here, are using File.applicationStorageDirectory to cache hundreds of megabytes of files. Please, don’t do this.

The File.applicationStorageDirectory property is intended to provide applications with a guaranteed writable, unique location in which they can save important information, regardless of which platform they’re running on. The information is saved to locations that are, on typical machines, backed up. On Windows, it’s saved under “<user>/Application Data”, which also roams with the user, if roaming profiles are enabled. There’s an implicit assumption here that the amount of data being stored is relatively small–megabytes at most.

Large sets of cached files should be stored elsewhere, in locations that aren’t backed up and don’t roam. AIR doesn’t include a handy property for finding such a location, but don’t let that stop you; the filesystem API lets you access any location on disk, after all. On Windows, you can use the “<user>\Local Settings\Application Data” directory (note the “Local Settings”); on Mac OS, use “<user>/Library/Caches”.

Upcoming Certificate Renewal Changes in Adobe AIR

AIR currently secures application updates published with renewed certificates by comparing the publisher ID computed from the old and new certificates. If the publisher IDs are identical the update is allowed; otherwise, it’s not.

Recently we’ve been made aware that the publisher ID computation is flawed in ways that make it quite likely that renewed certificates will not have identical publisher IDs. These range from the trivial to the unresolvable:

  • In one case, an original certificate contained a typo in the publisher’s identity. This was corrected in the renewal. However, the publisher ID computation requires that the publisher’s identity matches exactly.
  • In another case, similar, key information changed–but in one of the intermediate certificates in the certificate chain. The change was legitimate, but again fell outside the scope of changes that the publisher ID computation allows.
  • In perhaps the most serious issue, the publisher ID algorithm requires that the root certificate in the certificate chain be identical across renewals. Root certificates are typically valid for 20 years or more, so this was not anticipated as a serious limitation. However, many root certificates will be retired in the next few years in favor of certificates with longer key lengths–long before they expire.

If you’ve run into this situation, you should use the migration signature feature, which was first added in AIR 1.1. It was originally designed to allow secured updates across unrelated certificates (i.e., not renewals). As a general purpose mechanism, however, it also works just as well with renewals, whether or not they run into this issue.

There are, however, two drawbacks to the migration signature mechanism:

  1. You have to use the mechanism before your old certificate expires. Certificate renewals are often issued only after the previous certificate has expired.
  2. When you migrate between certificates your publisher ID changes. Among other things, this causes the application to lose access to any data stored in the EncryptedLocalStore.

This is an unfortunate turn of events for a feature that was designed to make things easier, and we apologize for the trouble all of this has caused. To address these issues, we will be making two significant changes in an otherwise minor release of AIR. This release is currently scheduled for December. The changes are:

  1. Applications will use a specified, not computed, publisher ID. This will allow them to change certificates without losing access to existing data.
  2. For purposes of changing certificates, certificates will be accepted as valid for six months after they expire. This allows plenty of time to renew and update the application.

Further details will be made available in conjunction with the upcoming release.

MAX 2009 Follow-up

Just a quick note to point out that my MAX 2009 talk on AIR distribution and deployment is now available on Adobe TV. Admittedly it’s more like slides-with-a-voice-over than what one would traditionally call “TV”. Oh well.

Took some great questions from the audience during the talk. If you have further questions, please post a comment or drop me an email. (My email address is in the last slide of the presentation.)

Object Graphs, the GC, and System.disposeXML()

AIR 1.5.2 contains a new, performance-related API that heavy users of XML may find handy, System.disposeXML(), that is an instructive example regarding use (and abuse) of the AIR garbage collector.

When an XML document is loaded, it’s stored in memory as a graph of individual objects representing elements, text, attributes, and so on. Each pair of related objects–for example, a parent/child element parent–are linked, in the underlying representation, with pointers going in both directions.

This is a convenient representation for traversal, but can be problematic for the garbage collector. As I mentioned in my earlier post about referencing counting and ActionScript objects, the garbage collector will eventually find and discard the entire set of objects after the last external reference is removed. However, it takes more work for the GC than less-connected data structures.

In practice, the amount of time it takes the garbage collector to do its job is related both to the number of allocated objects and the number of pointers between them. So while it is nice that the GC is capable of finding even these highly-connected graphs of objects, using them is also asking it do a lot of work. You can reduce this workload by explicitly disconnecting the pointers between objects.

For graphs of ActionScript objects, you can ease the GC workload by simply nulling out reference between the objects. Note that you don’t have to find every last reference for this to be helpful. The GC will still do it’s job in the end, and every bit of clearing references helps. For ActionScript objects this can be particularly helpful because, if their reference count then goes to zero, they can be cleaned up even before the GC sweep completes.

XML objects are a trickier case because the API doesn’t allow developers to traverse the actual object graph. That’s where System.disposeXML() comes in: It traverses the internal object graph backing the XML object, setting all of the internal points to null. Afterwords, the XML object is empty and, presumably, useless. But then, since you were done with it anyway, that shouldn’t be a problem.

Find Out About New AIR Deployment Options at MAX 2009

MAX wouldn’t be half as exciting without new stuff to announce, and this year there will be plenty of news. And while developers tend to focus mostly on new APIs when we think about updates to AIR, there are some new deployment options coming, too–options that may enable key new scenarios for some applications. I’ll be talking about these new options as well as providing an overview of the existing optios at my MAX 2009 session, “Explore Deployment and Distribution Options for Adobe AIR Applications”.

Why AIR fetches a Thawte CRL no matter who signed your app

I was recently asked why AIR fetches a Thawte CRL (from http://tss-geotrust-crl.thawte.com/ThawteTimestampingCA.crl) every time an application is installed–even if the application was signed with a certificate from another CA. It turns out there is a good reason for this, and the clue is in the URL itself.

By default, all AIR application signatures are timestamped. Timestamps are created by a timestamp server, and are themselves signatures. When AIR validates the timestamp signature, it downloads the CRL associated with the timestamp signing certificate–just like it would when validating any other signature. And the Thawte timestamp server uses a certificate that–no surprise here–has a CRL hosted by Thawte.

This default is easy to override using the “-tsa” option to the AIR file packaging tool, adt. A value of “-tsa none” turns off timestamps entirely. To specify an alternate timestamp server, specify the URL of that server after the -tsa flag.

For more on AIR code signing, including why timestamping is used, take a look at Code Signing in Adobe AIR.