The Essential Guide to Flash CS4 AIR Development, written by Marco Casario, was published today – Marco was kind enough to ask me to contribute a chapter and write the foreword for the book, so I thought I’d publish an excerpt from the chapter I wrote on Packaging, Distributing and Installing AIR Applications.
The book is available to order on Amazon and should be in bookstores now. If you’re already using Flash Professional to create web content then this book will help you get to grips with Adobe AIR and show you how to build and deploy cross-OS desktop applications.
More information and additional chapter excerpts can be found on Marco’s blog.
Excerpt: Digitally signing an AIR package
When viewing Flash or other content on the Web, the user is guaranteed a certain level of protection by the restrictions placed upon what the content can and can’t do when running within the confines of the browser sandbox. For example, a SWF running within Flash player can only write a limited amount of data to a very specific location on the user’s hard drive without direct user interaction.
The limited access to local system resources available to browser content means that users can browse the Web, consume content, and interact with applications without giving much regard to security, except in circumstances when they are explicitly providing personal or sensitive data over the internet.
Unlike browser-based applications, AIR applications have the same user privileges as native desktop applications, allowing them full access to the local file system. This means that a SWF running within the AIR runtime can read, write, and delete data anywhere on the local system, subject to the restrictions placed upon applications by the operating system.
To mitigate the risk to the user from installing an application, Adobe requires that AIR applications be signed by their publisher, so as to securely associate their identity with the application and to guarantee that after release, someone other than the publisher hasn’t amended the application code.
While it is possible to create your own digital certificate for use with AIR applications, such self-signed certificates don’t provide the user with the guarantee that you are who you say you are. In order to instill user confidence and guarantee that you are the publisher, it is necessary to obtain a digital certificate signed by a trusted third-party vendor. These trusted third parties, or CAs, validate your identity as a publisher and issue you with a certificate that you can use to sign your AIR application with.
Certificates and the AIR installation process
During the application installation process, the AIR runtime differentiates between applications that are self-signed and those that are signed using a certificate from a trusted third-party vendor.
Because self-signed applications represent a higher risk to the user, the installation dialogs highlight this increased risk by specifying the publisher as UNKNOWN and using red warning icons. The user will still be able to install the application, but by not using a trusted certificate you may find that users are wary of proceeding and choose to cancel the installation process.
By contrast, applications signed using a certificate from a trusted third party display the name of the application publisher and present a green “trusted” icon next to the publisher name. AIR applications have unrestricted access to the user’s system, so there is still some risk to the user—hence the yellow warning icon at the top of the dialog.
Another slight difference during the installation process is that applications signed with a certificate from a trusted third party will display the application icon on the second of the installation dialogs, whereas self-signed applications will not.
It is important to note that signing an application doesn’t make the application inherently trustworthy—the user can only trust the application if he trusts the publisher of the application. The AIR runtime provides the user with the opportunity to establish if an application has been signed using a certificate from a trusted third party, but the user must still make the ultimate decision as to whether to trust that publisher and install the application on their system.
Plan early for application signing
Right at the beginning of your project, as you’re scoping out the features for your application, you should allocate some time to consider how you’re going to sign your AIR application and whether you need to acquire a certificate.
There are a number of possible application-signing options that might be applicable to you, depending upon the type of application you are building and the organization that you are working for. In general, however, one of the following scenarios is likely to apply:
- You will need to acquire a new certificate from a CA to sign the AIR application
- Your organization already has a class 3–compatible certificate (suitable for user servers and software signing), and you plan to use that to sign the AIR application. More information on certificate types can be found at http://en.wikipedia.org/wiki/Public_key_certificate
- You are developing an application for a client and they will need to sign the application using an existing or a new certificate
- You are building an application that you are comfortable releasing with a self-signed certificate and don’t believe you need to acquire a certificate from a CA
If you need to acquire a certificate from a CA, you should allow a reasonable period of time to process the necessary paperwork, which may include providing documentation to a regional processing center so that the vendor can verify your organization’s identity. The next section discusses how to acquire a digital certificate.
If you know your organization has already published and signed a .NET, Cocoa, or Java application using a class 3, high-assurance code-signing certificate, then you should be able to use that certificate to sign your AIR application. You typically cannot use an SSL (Secure Sockets Layer) certificate to sign AIR files; a certificate must be marked for code signing to be suitable. You will want to allocate some time to test the certificate that you would like to use, and allow time to acquire a new certificate should the existing certificate prove to be unsuitable.
If you are developing an AIR application for a client, then the responsibility to procure the appropriate certificate and/or sign the application may fall to the client’s IT department. It is unlikely that the client will supply you with the private key for their certificate, and as such, they may insist you provide a build of the application that they sign. In this situation, you will need to supply them with an air intermediary (AIRI) file. This is an unsigned air package that cannot be installed, but that can be signed using the ADT (AIR developer tool) command-line tool supplied with the AIR SDK (software development kit).
Deploying an application with a self-signed certificate may be an option for you, even with the increased probability that some users will choose not to install the application. While it is possible to migrate from a self-signed certificate to a certificate issued by a CA at a later date, if from the outset you know that you will want to deploy a trusted application, then it is far simpler to release the initial application with a certificate from a CA.
Regardless of whether you need to acquire a new certificate, test an existing certificate, or produce an AIRI file to pass to your client to sign, you should allocate an appropriate amount of time for this as part of your overall project plan and not leave this task until you’ve finished the development of the application and are ready to deploy it.
Acquiring a digital certificate
While you can choose which CA you acquire your digital certificate from, thawte has worked with Adobe to provide a certificate service specifically for AIR application developers. At the time of writing, this is the easiest way to acquire a certificate to sign an AIR application, and so it’s the one you will use in this book.
The use of a thawte certificate is also convenient for end users installing your application; because the AIR runtime relies upon the operating system to establish whether a certificate can be trusted, it is necessary for the operating system to trust a chain of certificates linking the certificate to a known certification authority. Both Windows and Mac OS X operating systems come preinstalled with root certificates from thawte. Thus, your signed AIR application using a thawte certificate can be verified without requiring the user to install any additional root certificates on their machine.
To purchase an AIR Developer Certificate, the thawte website requires that you use the Mozilla Firefox browser, and that you purchase and retrieve the certificate on the same computer and browser. Once you have downloaded the certificate and private key successfully, you can export them from the browser keystore and use them elsewhere.
Follow these steps to purchase a certificate from thawte:
- Visit the thawte website and select Products ➤ Code Signing Certificates from the navigation
- Navigate to the purchase page by clicking the ‘Click here’ to buy link or button presented
- From the list of available code-signing certificates, select Adobe AIR Developer Certificate, then click submit
- Select whether you want to purchase a certificate for a one- or two-year period, and then enter the requested information about your organization, country, state/ province, city/town, and web server domain. It is important that the organization name be spelled correctly and in full, and that it represents the legal identity of the organization within the country in which it operates
- Complete the remainder of the three-step enrolment process. thawte will then perform its identity verification process and may request that additional information be provided and/or that documents used to prove the organization’s identity be faxed to a local thawte office. The requested documents vary depending upon the type of organization and the country in which it operates, but may include articles of incorporation, VAT certificates, registrations of trade name, partnership papers, or certificates of formation
- Once verification is complete, thawte will e-mail you instructions on how to retrieve the certificate. Using Firefox, navigate to the link provided by thawte, log in using the credentials specified during the enrolment process, and fetch the certificate
- Your certificate will automatically be saved to the keystore within Firefox. It needs to be exported so that you can use it to sign your AIR application
- Within Firefox, open the Preferences dialog from the File menu. Then click the Advanced icon and select the Encryption tab
- To export your certificate, click the View Certificates button, select the Your Certificates tab, and then select the certificate from the list. Once selected, click the Backup button to export the certificate and private key in a p12 file to a suitable location on your computer
During the backup process, you will be required to protect your certificate with a password. You will need to use this password during the packaging process within Flash.
More information on Packaging, Distributing and Installing AIR Applications can be found in the book. Enjoy!
Andrew Shorten's Blog 