4 Security

4.1.1 Built-in Security Features

Java security is based on built-in language and VM security features that have been part of Java technology from its beginning:

• Strongly typed language (runtime/compile-time/link-time)

• Bytecode verification (classloading-time)

• Safety checks (runtime)

• Dynamic class loaders (classloading-time)

4.1.2 Security Policy Framework

A security policy controls how system resources are accessed by applications at runtime. The Java security framework includes both a default security policy and a mechanism for describing alternate security policies for application and deployment-specific needs. The main benefits of this security policy framework are:

• Code-centric, not identity-centric architecture

• Security policies are described separately from both the applications they control and the Java runtime environment.

• Fine-grained access control at the package, class or field level

• Flexible permission mechanism

• Protection domains provide a layer of abstraction between permissions and code.

The main elements of a security policy are the following:

• permission set, a list of permissions granted to the code

• codeBase, the location from where the code is loaded

• signedBy, the author of the code

• principal, the identity of the entity running the code

Figure 4-1 illustrates the Java security model by showing how application code can be loaded from different sources: local and remote. The security manager controls access to system resources by comparing properties of the application code with the current security policy. The default security policy allows full access to local application code and limited access to remote application code. But other security policies are possible. For example, application code from a trusted yet remote source may be given greater access than untrusted code from a local source.

Figure 4-1 Java Security Policy Model

Description of "Figure 4-1 Java Security Policy Model"

4.1.3 Security Provider Architecture

Beginning with version 1.2, the Java SE platform added some security optional packages that allow Java technology to adapt to more specific requirements of applications and deployments. These security optional packages include a security provider architecture that is interoperable because it is based on publicly available security standards, and extensible because alternate security provider implementations can be supplied without requiring modifications to application code.

For example, the JAAS, JCE and JSSE security optional packages include several service provider interfaces (SPIs) that describe the requirements of a security provider implementation. Table 2-2 describes the default implementations for these security components.

4.1.4 Custom JSSE Provider Plug-ins

JSSE supports custom Provider plug-ins which can be implemented as extensions of SSLSocketFactory.

4.1.5 Oracle JSSE Cipher Suite Support

Many of the standard JSSE algorithm names are prefixed with SSL_. JSSE now supports the TLS_ prefix to be used as an alias to a standard algorithm name.

4.1.6 Self-Integrity Checks

In general, a JCE Provider implementation should include self-integrity checks. For example, Oracle's current JCE provider (Oracle JCE) includes self-integrity checks. However, this is not a requirement of the JCE or Oracle for a third-party JCE provider. A third-party JCE provider should make its own choice regarding whether including self-integrity checks or not.

4.2.1 Using Alternate Security Providers

From an administrator's perspective, the first step is to choose whether to install and use any alternate security providers. In most cases, the default security providers described in Table 2-2 are sufficient.

For a description of how to install alternate security providers, see Inside Java 2 Platform Security, Second Edition. Section 12.5, Installing Provider Packages, describes how to install alternate security providers.

4.2.2 Public Key Management

The JAAS optional package includes an extensible authentication framework that can use different forms of authentication. The default LoginModule is the KeyStoreLoginModule, which uses a protected database (Oracle's JKS keystore file) to store public key data. Other forms of authentication are possible like smart card or Kerberos.

The main tool for managing keystore files is keytool(1), which is included in the Java SE platform toolset. keytool can be used for

• importing a key

• listing available keys

• replacing a key

• deleting a key

The default keystore file is in lib/security/cacerts, described in Table 2-2.

For a description of how to use keytool to add and modify keystore entries, see Section 12.8, Security Tools, in Inside Java 2 Platform Security, Second Edition. The security trail in the Java Tutorial also covers how to use keytool.

4.2.3 Security Policy Management

Security policies are stored in security policy files. policytool is a convenient GUI-based tool for managing security policies. With it, a system administrator can

• identify a keystore

• specify permissions

• specify a codebase

The location of the default security policy file is lib/security.policy, described in Table 2-2. Alternate locations can be defined with the -Djava.security.policy command-line option.

For a description of how to use the policytool to manage security policies, see Section 12.8, Security Tools, in Inside Java 2 Platform Security, Second Edition. The security trail in the Java Tutorial also covers how to use keytool.

4.2.4 Seed Generation for Random Number Generation

The CDC Java runtime environment uses a native platform-provided source as an entropy gathering device for seed generation indicated by the securerandom.source system property. The Linux default for this system property is file:/dev/random.

On some Linux systems, /dev/random can block if it hasn't generated sufficient entropy before a random seed is needed and this can cause applications using java.security.SecureRandom to hang while waiting for the entropy pool to fill. To avoid this hang problem, the CDC Java runtime environment has a fallback mechanism to read from the /dev/urandom device when it determines that there isn't enough entropy for /dev/random to work promptly.

Note that /dev/urandom is not generally considered strong enough to support applications like keypair generation. If the strongest possible seed generation is required, this fallback mechanism can be disabled by setting the microedition.securerandom.nofallback property to true. Doing so may run the risk of application hangs on certain devices where the entropy pool is subject to early exhaustion.