Security Concerns

Installing and running any application on your computer raises security concerns. Where is the code from? Has it been tampered with? What operation is it trying to execute on your machine?

Unfortunately, the Internet and the operating systems on personal computers were not designed with security in mind. Over the years, methods have evolved to tackle some of these issues. Security is a large and complex area, but we will limit our discussion to what the user needs to know and do to have some assurance that installing and running the QViewer will not harm his or her computer and data, and won't covertly communicate data out to the Internet. A small introduction to basic security concepts is given here to provide some context for the decisions asked of the user.

QViewer extensions are a kind of applet. An applet is a software component that runs in the context of another program. Often the other program is a Web browser; in this case it is the QViewer. An applet usually performs a very narrow set of functions and has no independent use. The Java programming language became popular initially because of its ability to produce applets that could be be delivered across the Web and run on many different computing platforms. One thing making this possible was that applets could be prevented from executing actions that would compromise the local computer. Quotidian Extensions are written in Java and reuse much of the security infrastructure designed for Java applets in Web browsers.

Security is implemented in part by granting permission to code to perform certain actions. Extensions that are not trusted are not granted as many permissions. Extensions that are installed on the user's machine are assumed to be trusted and are automatically granted a wider set of permissions.

The QViewer has a set of "sandboxes" in which extensions are allowed to run. Each is assigned limited set of permissions to run potentially dangerous operations. (Older children are trusted with toys that might be a hazard for younger children, and get more toys in their sandbox.) The user decides how much trust to place in the source of an extension and puts the extension in a corresponding sandbox. Extensions that are of unknown provenance or whose sources are not trusted are placed in the smallest sandbox with no read or write access to the user's hard disk and little access to the Internet. Extensions considered to be reliable can be placed in larger sandboxes with more permissions. Some permissions, such as write access to the user's hard disk, and the ability to start other applications, are limited in all sandboxes.

Users are not asked to make trust decisions every time an extension is loaded. Extensions installed on the user's hard disk, including those supplied with the QViewer, are always placed in the largest sandbox. Extensions loaded from the net that are not signed with a verifiable source are always placed in the smallest sandbox. The user is asked to place only those extensions that are signed.

Code signing

In order to gain some assurance that the code is from the individual or organization that produces it and that it hasn't been tampered with in the process of moving from the producer to the local machine, code can be signed. Learning something about the signing process will give the user some idea about how their decisions fit into the security regimen.

The producer of the software computes a fingerprint (the result of a one-way hash) from the entire extension file. This provides a way for anyone receiving the file to tell if the file has been modified. The computer that receives the file computes a fingerprint using the same method and compares it with the one sent by the producer along with the extension. If they are the same, the file is unchanged.

Public key cryptography relies on the discovery that certain arithmetic operations on large numbers are impossible to reverse in any practical length of time. The method produces two keys; one is kept private, and the other can be made public. Messages encrypted using the private key can be decrypted only with the public key. This means that anyone with the public key can verify that the sender signed the message and that the message has not been tampered with.

There is nothing to prevent someone from maliciously changing both the extension and the fingerprint. To insure this can't happen, the fingerprint is encrypted using a private key. A certificate containing the public key is sent with the fingerprint and the extension. With this certificate, the fingerprint can be decrypted and compared.

There is also nothing to prevent someone from making a certificate and using that to sign a malicious extension. To prevent this, each certificate is signed by a certificate authority, or CA. A certificate authority is a trusted third party that exerts some effort to insure that the certificate belongs to the person or organization whose name is on the certificate. The certificate authorities themselves have public certificates that are used to verify the certificates they sign. There may be a chain of certificates with a certificate authority at the top level.

All Web browsers are distributed with a set of these public certificates belonging to several dozen entities. The most popular certificate authorities are Verisign and its acquisitions, Thawte and Geotrust. Others popular ones include Comodo, GoDaddy, GlobalSign, and Entrust. Quotidian Incorporated signs code with its own certificate. This certificate is signed by a certificate from the Thawte Code Signing CA. That certificate is signed by a certificate from Thawte Premium Server CA. A copy of the last certificate is stored in a safe place on the user's machine as part of the Java installation or as part of the installation of a Web browser. This path from code to Quotidian Incorporated to Thawte to Thawte forms a chain of trust where each entity in the chain vouches for the previous one.

Verifying a file signed by Quotidian Incorporated shows this list of certificates:

  • X.509, CN=Quotidian Incorporated, OU=Quotidian, O=Quotidian Incorporated, L=Boston, ST=Massachusetts, C=US (quotid)
  • [certificate is valid from 6/16/08 8:00 PM to 6/17/10 7:59 PM]
  • X.509, CN=Thawte Code Signing CA, O=Thawte Consulting (Pty) Ltd., C=ZA
  • [certificate is valid from 8/5/03 8:00 PM to 8/5/13 7:59 PM]
  • X.509,, CN=Thawte Premium Server CA, OU=Certification Services Division, O=Thawte Consulting cc, L=Cape Town, ST=Western Cape, C=ZA
  • [certificate is valid from 7/31/96 8:00 PM to 12/31/20 6:59 PM]

Code signing is not perfect. It relies on the private keys of the parties involved staying private. It also relies on the security of both the signing and verifying machines while the process is taking place. And it depends on the end user making reasonable use of information that the verification process gives.

Signing alone is not enough. Anyone can quickly self-sign a certificate. In this case there is no CA at the end of the chain of certificates.

In practice, code signing works well. Even if it is not perfect, it raises the barrier high enough so that people intent on malice will most likely find easier targets.

What does this mean to the user?

Users must make several decisions about whom they trust. Any time they install any software on their machine they should assure themselves that the software is from who they think it is from, that they trust the organization or individual, and that it hasn't been tampered with by someone adding a virus or other attack. This applies both to products from Quotidian Incorporated including the QViewer and QEditor, and to extensions from Quotidian Incorporated or third parties.

When a signed extension is loaded by the QViewer from the Internet, a dialog is posted with information from the signer's certificate and the certificate authority, if any, that vouches for it. The user decides how much he or she trusts the extension and places it in a sandbox.

There are three sandboxes that, to continue the analogy, offer different numbers of toys with which to play. The smallest gives very few permissions and the largest allows almost everything.

  • Small sandbox has the same permissions given to code from untrusted sources. Extensions can read only from the website from which the extension was loaded. No access is given to the user's hard disk, or to other Web addresses. The extension has permission to call OpenGL functions to draw in the display area.
  • Large sandbox gives the same permissions that are given to extensions installed on the user's disk. The extension has read permission for the user's home directory, read and write permission for the "extensions" directory inside the Quotidian application directory, and read permission to the lib directory of the Java installation.

Rather than asking the user which sandbox an extension should run, a suffix on the extension itself indicates what permissions the extension thinks it needs to accomplish its purpose. The user is asked to give or withhold this permission.

suffix sandbox example
_l large qical_l.jar
_s small moon_s.jar

Some other things to keep in mind:

Some useful extensions need no extra permissions and will happily run in the smallest sandbox. In general, code signing is a good thing, but, for now, extensions that don't need any more permissions can be left unsigned. This also means that unsigned extension code is not an indication of malicious intent.

If the user's machine is already compromised, no amount of security provided by Java and Quotidian Incorporated will make a difference.

The permissions granted by a sandbox will never override the permissions granted to the user by the user's operating system. For example, files that are not readable by the user in the local file system will never gain them in an extension.

Code signing and the rest of the security infrastructure does not protect the user from rude or buggy code. Extensions in the smallest sandbox are able to write over the entire QViewer display area and can cause the QViewer to hang by refusing to give up the drawing thread, but can do no permanent damage to the user's machine or data. The only solution in these cases is to avoid the timeline files that invoke these extensions and to make their authors and others aware of the problem.

© 2011 Quotidian Incorporated