This section covers the following topics:
This page provides an overview of how RSA signed applet support is implemented in Java Plug-in. For an overview of how to use RSA signed applets, see How to Deploy RSA-Signed Applets in Java Plug-in.
So that Java Plug-in can verify RSA signatures in a browser-independent way,
Java Plug-in includes a Cryptographic Service Provider (CSP). The CSP supports
the "MD2withRSA", "MD5withRSA", and "SHA1withRSA" digital signature algorithms.
It is automatically registered with the Java Cryptographic Architecture framework
as part of the static initializer of the PluginClassLoader.
Java 2 SDK, Standard Edition v 1.3 introduced fine-grained access control based on "codesource" and "protection domain," as described below:
Every class that is loaded from a JAR file has a codesource, which encapsulates two pieces of information:
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 one and only 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 things:
A certificate chain is a list of 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 assumption is that the Root CA is trusted because it is well known and widely published.
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. This behaviour
is common to all secure classloaders (i.e., instances of java.security.SecureClassLoader).
(Note: sun.plugin.security.PluginClassLoader extends sun.applet.AppletClassLoader,
which is a subclass of java.net.URLClassLoader, which in turn extends
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 attempts to
verify them.
If Plug-in 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 database
of trusted Root CA certificates. If so, Plug-in will display the certificate
chain of the authenticated signer and ask the user whether or not to grant AllPermission
to code signed by that principal. Java code that is assigned the AllPermission
permission is treated the same as system code, meaning it has all the privileges
that system code has. The user can then choose whether or not to grant AllPermission
to code signed by that principal, and whether such permission should be granted
to any code signed by that principal for all subsequent sessions or for the
current session only.
(For the case of unsigned applets, or signed applets whose permissions include
the usePolicy, see Overview—Applet
Security Basics.)
usePolicy Permission A permission named usePolicy (introduced with version 1.3) allows
system administrators to turn off the PluginClassLoader behaviour.
If the usePolicy permission is granted to the codesource by the
configured security policy, no user prompting will take place; only the permissions
specified in the security policy will be granted to the codesource.