How RSA Signed Applet Support Works in Java Plug-in

Print-friendly Version

Introduction

This page provides an overview of how RSA signed applet support is implemented in the Java Plugin 1.2.2. For an overview of how to use RSA signed applets see Using RSA Signed Applets.

In previous releases of Java Plug-in the lack of support for RSA signatures and dynamic trust management has impacted the usability and deployment of the Java security architecture.

Java Plug-in's support for verifying signed JAR files has been limited to the DSA signature algorithm. This means that JAR files that carry an RSA signature have been treated as unsigned. However, RSA is the most widely used digital signature algorithm and is employed by most browsers, including Netscape Navigator and Internet Explorer. In order to interoperate with other browser vendors, Java Plug-in must be able to verify JAR files carrying an RSA signature.

In order for a Java Plug-in enhanced browser to "trust" an applet and grant it all privileges (using JRE 1.1) or a set of fine-grained permissions (as specified in a Java 2 SDK, Standard Edition v 1.2.2 policy file), the user has to preconfigure their cache of trusted signer certificates ("identitydb.obj" file in JRE 1.1 or ".keystore" file in JRE 1.2) to add the applet's signer to it. This does not scale well if the applet needs to be deployed on thousands of client machines, and may not always be feasible, because the user may not know in advance who signed the applet that they are trying to run.

Both of these limitations have been addressed in the latest version of Java Plug-in through the addition of a new classloader, sun.plugin.security.PluginClassLoader, that implements support for RSA verification and dynamic trust management.

Support for RSA Verification

In order for Plug-in to be able to verify RSA signatures in a browser-independent way, we have bundled a Cryptographic Service Provider (CSP) with Plug-in. This CSP is capable of verifying RSA signatures. In particular, it supports the "MD2withRSA", "MD5withRSA", and "SHA1withRSA" digital signature algorithms.

The bundled RSA provider is automatically registered with the Java Cryptographic Architecture framework as part of the static initializer of the PluginClassLoader.

Support for Dynamic Trust Management

Java 2 SDK, Standard Edition v 1.2.2 introduces fine-grained access control, based on "codesource" and "protection domain":

Every class that is loaded from a JAR file has a codesource, which encapsulates 2 pieces of information: the location where the class came from ("codebase"), and the list of principals who signed it. Each signer principal in the codesource is represented by its X.509 public-key certificate and supporting certificate chain.

In addition, every class that is loaded by a classloader belongs to exactly one protection domain, based on its codesource (i.e, based on where the class came from, and who signed it). Every protection domain has a set of permissions associated with it, based on the configured security policy. This means that a protection domain encapsulates two pieces of information: a codesource, and the set of permissions granted to it.

A certificate chain is a list or hierarchically ordered public-key certificates , starting at the signer's public-key certificate and ending at the certificate of a Root Certification Authority ("Root CA"). The public key of one certificate in the chain is used to verify the signature on the previous certificate in the chain. The Root CA certificate is self-signed: The Root CA's public key is trusted by the fact that it is widely published, e.g., in a browser's Root CA database.

The PluginClassLoader checks the configured security policy to determine which permissions to grant to a given codesource. The codesource and the set of permissions granted to it then form a protection domain, to which all classes with the same codesource are assigned. This behaviour is common to all secure classloaders (i.e., instances of java.security.SecureClassLoader). (Note: sun.plugin.security.PluginClassLoader extends off of sun.applet.AppletClassLoader, which is a subclass of java.net.URLClassLoader, which in turn extends off of java.security.SecureClassLoader.)

The PluginClassLoader does additional work: If the applet is signed, and the permissions granted to it do not include the special usePolicy permission, the PluginClassLoader extracts the signers (and their supporting certificate chains) from the applet's codesource and passes them to the browser (Internet Explorer or Netscape Navihator) for verification, using the browser's native crypto services and configured database of trusted Root CA certificates.

If the browser can verify the certificate chain all the way up to its Root CA certificate, it checks if that Root CA certificate is contained in the browser's database of trusted Root CA certificates. If this is the case, the browser will display the certificate chain of the authenticated signer and ask the user if they want to grant "AllPermission" to code signed by that principal. Java code that was assigned "AllPermission" is treated the same as system code, meaning it has all the privileges that system code has. The user can then choose if they want to grant "AllPermission" to code signed by that principal, and if this permission should be granted to any code signed by that principal for all subsequent sessions or for the current session only.

Implementation Details

The certificate chain verification process mentioned above will be fully automated in future versions of Navigator. In these future versions, Plug-in queries the Plug-in manager to see if Netscape's "capabilities manager" (caps manager) is installed and passes the certificate chain to it for verification. Netscape's capabilities manager will verify the chain and check if its Root CA certificate is configured in Netscape's database of trusted Root CA certificates. Netscape's caps manager also provides APIs for prompting the user if they want to grant "AllPermission" to code signed by the authenticated principal, and stores in its database the information whether that permission should be granted "for the current session only" or "forever" to any code that was signed by the authenticated principal.

With all other supported browsers (Navigator 3, Navigator 4, and Internet Explorer), Plug-in has to programmatically verify the certificate chain and access IE's database of trusted Root CA certificates, using Microsoft's "CAPI" interface.

See Supported Configurations for more information on CAPI availability.

New "usePolicy" Permission

A new permission named "usePolicy" has been introduced that will allow system administrators to turn off the PluginClassLoader behaviour. If the "usePolicy" permission is among the permissions granted to the given codesource (by the configured security policy), no user prompting will take place, and only the permissions (if any) specified in the security policy will be granted to the codesource.