download.com, commercial sites such as online catalogs, government and nonprofit sites, and sites run by small organizations or individual users. At the same time, the number of intranet and Internet users is increasing exponentially. Mass market users who know little about the Internet are getting connected in greater numbers than ever before. These users know how to acquire known software from trusted manufacturers through trusted sources such as catalogs or retail stores, but they have little or no experience downloading software from the World Wide Web or gauging what effect that software could have on their systems. Corporations, governments, and other organizations are deploying intranets and extranets, tying together employees, customers, suppliers, and service providers who use very different kinds of software on very different platforms. For intranets and extranets, as for the Internet, reliable cross-platform authentication, distribution, and access control for software are becoming more important every day. Unfortunately, distribution over networks poses potential security problems, because the software must pass through many intermediate machines before it reaches the user's machine. Although millions of users download software every day without incident, the potential exists for either malicious or accidental damage to an individual user's system and data. The user often has no reliable way of confirming where a piece of software is really coming from, whether it has been changed in transit over the network, and what kind of damage it might be capable of causing. Object Signing is designed to address the need for more reliable software distribution over intranets and the Internet. It is also designed to help users and network administrators implement decisions about which sources of software to trust for what purposes.
When an object is signed with a valid digital signature, Communicator can
Identify the Signer
Object Signing uses techniques based on the X.509 v3 certificate standard and several Public Key Cryptography Standard (PKCS) specifications published by RSA Data Security, including the PKCS #7 signing and encryption standard. Among other things, these standards define how to
The ability to associate a digital signature with a particular entity allows users and network administrators to decide which sources of software they want to trust and to identify software signed by those entities. For an overview of the way certificates and digital signatures can be used to identify an object's signer, see How Object Signing Uses Public-Key Cryptography.
A digital signature can be used to verify not only the identity of the signer, but also the integrity of the object signed. Making even a minor change in the object, such as adding a comma in a text file, results in a different digital signature.
Thus, three digital signatures created by MyCompany for three separate objects can all be identified as MyCompany's signature even though each signature consists of unique cryptographic information. At the same time, if an object signed by My Company has changed between the time it was signed and the time a user receives it, the digital signature is not valid.
For a technical overview of the way digital signatures can be used to detect tampering, see Digital Signatures.
The techniques of public-key cryptography that make identification and tamper detection possible have been available for many years. Netscape has integrated these standard techniques with Communicator and other products and has made them much easier for users and network administrators to use.
This is an important distinction between Object Signing and other schemes for allowing signed code to access local system resources. Instead of requiring users to allow software either unlimited access or no access at all, Object Signing allows the user to control the degree of access. This approach permits a fine-grained continuum of access privileges from relatively innocuous operations, such as read/write access to a single file, to full-blown powers over many different aspects of the local system.
Once a signer has been granted privileges for a particular kind of access, applets or scripts signed by that signer can turn those privileges on, use them, and turn them off again without interrupting the user's activities. Because the privileges are made available only when needed, the chances of accidental or malicious damage to the user's system are greatly reduced.
Update Software Automatically
The SmartUpdate feature of Communicator allows users to automatically update software (including stand-alone applications as well as Communicator plug-ins and components) by downloading files that have been digitally signed. All a user needs to do is initiate the software download (for example, by clicking a trigger on an HTML page) and grant the signer the access privileges required to perform the installation. In addition, network administrators can use Mission Control and the AutoUpdate feature of Communicator Professional Edition to schedule fully automated software updates that are completely transparent to users.
How Do Users and Network Administrators Control Signed Objects?
Access Control for Users
Figure 1.1 The Java Security dialog box
Access Control for System Administrators
Network administrators can use Mission Control with Communicator Professional Edition to change security settings dynamically after the initial software deployment without involving the user. To do so, the administrator sets preferences and configuration information in a master configuration file and sets up Communicator Professional Edition clients to retrieve that information from the file at regularly specified intervals.
For more information about Mission Control, see Netscape Mission Control Overview and Planning Guide.
Support for Open Standards
The techniques of public-key cryptography that underlie Object Signing are the same as those that underlie the S/MIME and Secure Sockets Layer (SSL) protocols, the industry standards for secure email and secure client-server transactions, respectively. These techniques are based on the X.509 v3 certificate standard and several PKCS standards, including the PKCS #7 signing and encryption standard.
Object Signing also makes use of the cross-platform Java Archive (JAR) format, jointly developed with JavaSoft. JAR archive files, which are compatible with standard cross-platform ZIP files, provide a way to associate digital signatures with specific files in a directory without making any changes to those files. Because the JAR format doesn't require a digital signature to be stored physically inside the file with which it is associated, JAR archives can be used to package and sign any kinds of files, including file types that have not yet been invented.
Developers can create JAR files and sign the objects they contain using Windows 95 and NT, Mac OS, and Unix. Users can download signed objects on any computer that can run Netscape Communicator.
For information about public-key cryptography, certificates, and digital signatures, see How Object Signing Uses Public-Key Cryptography.
For information about the JAR format and how to sign objects, see How to Sign Objects.
Benefits of Object Signing
These sections discuss the benefits of Object Signing in terms of security ergonomics and security solutions for specific groups of customers:
download.com, webmasters, and consultants
Public-Private Key Pairs
Public-key cryptography involves a pair of keys--a public key and a private key-- associated with each individual or entity that needs to sign something electronically. Each public key is published, but the corresponding private key is kept secret. Data encrypted with your public key can be decrypted only with your private key. Figure 1.3 shows a simplified view of the way this works.
Figure 1.3 Using public and private keys for encryption
The scheme shown in Figure 1.3 lets you freely distribute a public key, and only you will be able to read data encrypted using this key. In general, to send encrypted data to someone, you encrypt the data with that person's public key, and the person receiving the encrypted data decrypts it with the corresponding private key.
As it happens, the reverse is also true: data encrypted with your private key can be decrypted only with your public key. This would not be a desirable way to encrypt sensitive data, however, because it means that anyone with your public key, which is by definition published, could decrypt the data. Nevertheless, private-key encryption is very useful, because it means you can use your private key to sign data with your digital signature. Communicator (with the aid of your public key) can then confirm that the message was signed with your private key and that it hasn't been tampered with since being signed. For more information about the way this works, see Digital Signatures.
A certificate (also called a digital ID) is an electronic document used to identify an individual, company, or other entity. Certificate authorities (CAs) are entities, such as VeriSign, that validate identities and issue certificates. The methods used to validate an identity vary depending on the CA and the class of certificate. In general, it is the responsibility of the CA to ensure that an entity requesting a certificate is in fact who it claims to be before issuing the certificate.
Before submitting a request for a certificate to a CA, Communicator generates a public key and the corresponding private key. The certificate issued by the CA binds the public key to the name of the requesting entity (for example, a company's name). Certificates help prevent the use of fake public keys for impersonation. A certificate is somewhat like a driver's license, a passport, or any other personal ID that provides generally recognized proof of a person's identity. A certificate always includes a public key and the name of the entity it identifies. Most certificates also include an expiration date, the name of the CA that issued the certificate, a serial number, and other information. Most importantly, a certificate always includes the digital signature of the issuing CA. The CA's digital signature allows the certificate to function as a "letter of introduction" for users who know and trust the CA but don't know the entity identified by the certificate. Communicator recognizes several kinds of certificates, including those used to identify email recipients and web sites. Communicator also recognizes signing certificates, which identify entities that sign files. Signing certificates are discussed in Getting a Signing Certificate and Signing a File.
When you receive a signing certificate for your own use, it is automatically installed in your copy of Communicator. Communicator also supports the public-key cryptography standard known as PKCS #12, which governs key portability. This means, for example, that you can move signing certificates from one computer to another on credit-card-sized devices called smartcards. Signing tools such as the JAR Packager allow you to choose which signing certificate you want to use at the time of signing. To confirm a signer's identity, Communicator relies in part on its list of accepted CAs. A CA can be a publicly recognized independent company such as VeriSign, or it can be an individual or department recognized only within a corporation's intranet or extranet. The user can add CAs to Communicator's list of CAs and, if necessary, delete from the list any CAs that the user decides not to trust for the purpose of validating a digital signature. If a signer's signing certificate cannot be traced back to one of the CAs on Communicator's list, that signer's digital signature cannot be validated. To view your current list of CAs while you are reading this document in Communicator, click the Security button near the top of the Navigator window, then click Signers under Certificates. The list of certificate signers (that is, CAs recognized by your copy of Communicator for validating certificates) looks like the one shown in Figure 1.4.
Figure 1.4 CA certificates listed in the Communicatos Security Info window
For an overview of the way certificates are used to confirm a signer's identity, see Validating the Signer's Identity.
When one of the Netscape signing tools signs an object, it first creates a one-way hash of that object. A one-way hash is a number of fixed length with the following characteristics:
Figure 1.5 shows a simplified view of the way a digital signature can be used to validate the integrity of a signed object.
Figure 1.5 Using a digital signature to validate data integrity
If the two hashes match, the recipient can also be certain that the public key in the signer's certificate corresponds to the signer's private key. To confirm the identity of the signer, however, also involves confirming the validity of the digital signature of the CA who issued the signer's certificate. For a discussion of the way this works, see Validating the Signer's Identity.
An individual file can potentially be signed with multiple digital signatures. For example, an ISV might sign the files that constitute a software product to prove that the files are indeed from a particular company. A network administrator might sign the same files with an additional digital signature based on a company-generated certificate to indicate that the product is approved for use within the company.
The significance of a digital signature is comparable to the significance of a handwritten signature. Once you have signed an object, it is difficult to deny doing so later. In some situations, a digital signature may be as legally binding as a handwritten signature. Therefore, signers should take great care to ensure that they can stand behind any objects they sign and distribute.
For example, if you are a software developer, you should test your code to make sure it is virus-free before signing it. Similarly, if you are a network administrator, you should make sure, before signing any code, that it comes from a reliable source and will run correctly with the software installed on the machines to which you are distributing it.
Getting a Signing Certificate and Signing a File
Before signing an object, you must first obtain a signing certificate from an appropriate CA. For example, an independent software developer typically obtains a signing certificate from a publicly recognized CA such as VeriSign. A corporate IS manager might also obtain a signing certificate from an independent CA; or, if the corporation has its own Certificate Server, from an internal CA recognized only within the corporation.
Figure 1.6 shows a simplified view of the way a company called MyCo might obtain a signing certificate from an independent CA. The details of this procedure vary depending on the CA and the type of certificate involved, but the principle is always the same. MyCo provides evidence of its identify, uses Communicator to generate a public/private key pair, and sends the evidence and the public key to the CA. The CA then uses the evidence provided by MyCo to verify the identity of the entity requesting a certificate. This may involve simply confirming MyCo's email address (for example, for a free certificate), checking the evidence against a commercial credit database (for example, for an individual's certificate), examining notarized hard copies of corporate documents (for example, for a commercial software publisher's certificate), or going through some other verification process. It's important to make sure you request a certificate with the appropriate level of identity verification for the intended use.
Figure 1.6 Getting a signing certificate
Once MyCo has obtained a signing certificate, it can use the certificate, the corresponding private key, and a signing tool such as the JAR Packager to create a JAR archive file containing signed and compressed files, as shown in Figure 1.7. MyCo can then post the JAR file to a web site. For a brief discussion of JAR archive files and the JAR format, see Understand the JAR Format.
Figure 1.7 Signing a file
Validating the Signer's Identity
Figure 1.8 shows how Communicator uses the "letter of introduction" from a CA--in this case, a signing certificate--and the CA's certificate to validate a signer's identity. To keep things simple, the figure assumes that the certificate for the CA that issued the signing certificate has previously been installed in Communicator's database of CA certificates, that the JAR file contains only one signed file, and that the signer is not known to the user.
Figure 1.8 Validating a signer's identity
MyCoFile.class and the corresponding digital signature in the JAR file. Communicator then uses MyCo's public key, which it gets from MyCo's "letter of introduction" (MyCo's signing certificate) in the same JAR file, to validate the integrity of
MyCoFile.class. This process is explained in Digital Signatures.
MyCoFile.class has not
been tampered with since it was signed, and that the public key in MyCo's certificate
corresponds to the private key used to sign the file. However, MyCo's identity has
not yet been validated; the certificate might have been created by someone
attempting to impersonate MyCo. To be sure that the signing certificate really was
issued by the specified CA to the real MyCo, Communicator must also perform step
How to Sign Objects
If you are signing Java code that requests capabilities, you first use the Java Capabilities API to call the appropriate methods from within your code. For information about the Java Capabilities API, see Extending Java Capabilities.
Once you have prepared and tested the code or other objects you want to sign, follow the steps described in these sections to sign the objects:
To get a signing certificate from a certificate server on your intranet, see your network Administrator. For a general introduction to certificates and a discussion of the way they are used in Netscape Object Signing, see How Object Signing Uses Public-Key Cryptography.
Choose a Signing Tool
Netscape provides three signing tools for use by developers:
Understand the JAR Format
The Java archive (JAR) format is a set of conventions for associating digital signatures, installer scripts, and other information with files in a directory. Signing tools such as the JAR Packager use this format to create JAR archive files.
A JAR archive file is a digital envelope for a compressed collection of files. Although the files in a JAR archive don't have to be digitally signed, they are stored in a way that makes it possible to associate each file with digital signature information stored separately in the same archive. The JAR file type is a registered Internet MIME type that is compatible with the standard cross-platform ZIP archive format. The JAR file type is distinct from the JAR format, which is simply a way of organizing information in a directory.
In addition to digital signature information associated with the files it contains, a JAR file may include global information such as the name of the installer file that Communicator should launch to install the contents of the JAR file on the local system. A JAR file may also contain other information the developer may wish to associate with the archive as a whole.
JAR files are also used with the SmartUpdate feature of Communicator and the AutoUpdate feature of Communicator Professional Edition. The JAR Installation Manager (JIM) is the collective term for the Communicator features that developers and content providers can use to automatically install components, plug-ins, and Java classes on a user's machine. Developers can use JIM to publish their software packages, and content creators can use JIM to modify their pages to trigger an installation. For more information, see JAR Installation Manager Developer's Guide.
Sign the Object
Once you have obtained your own signing certificate and downloaded the signing tool you want to use, follow the instructions for using the tool to create a JAR archive and sign the files it contains (or, in the case of Page Signer, to sign a script in an HTML page). You can find the documentation for each tool in the following locations on DevEdge:
For a technical overview, interface documentation, sample code, and other technical information, see Java Capabilities API.
Principals, Targets, and Privileges
All access-control decisions boil down to who is allowed to do what. In the Capabilities model, a principal represents the "who," a target represents the "what," and the privileges associated with a principal represent the authorization (or denial of authorization) for a principal to access a specific target.
In the Java Capabilities API, a principal consists of an instance of class
Principal and typically represents a signing certificate. A target consists of an instance of class
Target and typically represents access to one or more system resources, such read/write access to files or the ability to create a network connection.
The Java Capabilities API makes it possible to determine whether any given principal is allowed to access the local system resources represented by a given target. The answer is expressed by an instance of class
Privilege, which states whether access is allowed and, if so, for how long.
Running a Signed Applet
Consider what happens when a user clicks a URL that downloads a JAR archive containing signed Java class files. For the purposes of this example, assume that the Communicator client has the signer's certificate in its list of accepted signing certificates. Communicator first checks the digital signatures in the JAR archive to validate the identity of the entity whose certificate was used to sign the files (the principal) and to make sure the content of the files hasn't changed since they were signed. If these operations are successful, Communicator keeps track of this information for later use and the applet starts to run.
It's important to note that an applet signed by a known principal is not automatically allowed access to the targets for which it has been authorized. Instead, the applet must explicitly request the privileges it needs. An applet that is not signed at all runs "inside the sandbox" as applets always have and is denied extended access to system resources.
The Privilege Manager, with the aid of the Communicator client, keeps track of which principals are allowed to access which targets at any given time. Signed applets use an instance of class
PrivilegeManager to request privileges for particular targets. Communicator associates each principal with a list of targets for which privileges may or may not be permitted. If the client's list of principals and their permitted targets includes the applet's principal and the requested target, the Privilege Manager grants the privilege without interrupting the user. If the applet's principal has not previously been granted or denied a privilege for the requested target, Communicator displays a dialog box asking the user whether to grant that privilege to that principal.
The Privilege Manager enforces a distinction between granting a privilege and enabling a privilege. An applet that has been granted a privilege has a potential power that is not yet turned on. An applet that successfully enables a previously granted privilege has the privilege's power available and ready to use.
A privilege can be granted only if the client software has previously associated that principal with a privilege for that target or if the user explicitly grants that privilege when the applet requests it. In both cases, after the applet's first successful request for the privilege, that privilege is both granted and enabled.
However, although the privilege typically remains granted for the rest of the time the applet is running, it is enabled only for the duration of the method call in which the privilege is requested. Subsequent method calls that require the same kind of access must therefore request the privilege again. In those cases, the privilege has already been granted (so no dialog box, for example, needs to be displayed), and the request simply enables the privilege--that is, allows the applet to access the target.
In effect, after its principal has been granted some privileges, the applet can turn those privileges on, use them, and turn them off again, without interrupting the user's activities.
Using Codebase Principals
When developing secure Java code, you may wish to bypass the signing stage for much of the development cycle. To make this possible, you may place a line in the Communicator preferences file to activate codebase principals. By default, Communicator treats signing certificates as principals for the purpose of enabling privileges. When codebase principals are activated, Communicator allows the
CODEBASE of the applet (either a
file: URL or an
http: URL) to function as a principal for enabling privileges. This allows you to test Java code that requests privileges without having to sign each new version you create. For more information, see Security Technote #2: Activating Codebase Principals.
Composer Plug-Ins and the Java Capabilities API
Signed Composer plug-ins, which must be written in Java, can also take advantage of the Java Capabilities API. For more information, see the Composer Plug-In Guide.
Netscape is currently exploring several possible extensions of Object Signing technology, including the following:
Object-Signing Resources on DevEdge
For an overview of DevEdge resources related to Object Signing, see Netscape Object Signing Resources. Resources listed there include the following: