Verification of RSA Signed Applets in Java Plug-in
This section covers the following topics:
Introduction
This page provides an overview of how verification of RSA signed applets 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.
Support for RSA Verification
To enable verification of 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.
Support for Dynamic Trust Management
Java SE has a fine-grained access control based on "codesource" and "protection domain". Every class that is loaded from a JAR file has a codesource, which encapsulates two pieces of information:
- The location (URL) where the class came from. 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. The protection domain encapsulates the codesource and the set of permissions granted to it
- The list of principals who signed it (its certificates). Each signer principal in the codesource is represented by its X.509 public-key certificate and supporting certificate chain.
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 behavior is common to all
secure classloaders (i.e., instances of
java.security.SecureClassLoader).
The 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 allows system
administrators to turn off the PluginClassLoader
behavior. 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.