Skip Headers
Oracle® Java Micro Edition Connected Device Configuration Runtime Guide
Release 1.1.2 for Oracle Java Micro Edition Embedded Client
  Go To Table Of Contents


4 Security

Security is a principal feature of Java technology and an important requirement for mobile and enterprise applications. CDC includes the same security features that are in the Java SE platform. These include built-in security features of the Java programming language and virtual machine in addition to a flexible security framework for more advanced application scenarios.

This chapter provides an overview of the security framework in addition to an outline of the kinds of security procedures that might be performed at runtime. It is not meant to replace the security documentation available for the Java SE platform, but rather to supplement it and show how CDC and the JAAS, JCE and JSSE security optional packages are related to their counterparts in the Java SE platform.

Table 4-1 describes the security documentation for the Java SE platform.

Table 4-1 Security Documentation for the Java SE Platform

Document Description

Inside Java 2 Platform Security

Describes the Java security framework, including security architecture, deployment and customization. Chapter 12 describes deployment and runtime procedures. See documentation at

Security and the Java Platform

Main web page for Java security issues. See documentation at

Java Tutorial, Security Trail

A tutorial section that describes many of the security procedures for the Java platform. Because these are identical between CDC and the Java SE platform, they are not duplicated in this chapter. See documentation at


Java SE platform security documentation. See documentation at

4.1 Overview

The security framework shared by the Java SE platform and CDC is based on three key components:

These provide a solid base for application and runtime security, a flexible mechanism for defining deployment-based security needs and a plug-in mechanism for supplying alternate security implementations.

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 follows
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 Security Procedures

This section outlines the security procedures surrounding the Java security framework described in the previous section. Because these procedures are identical to the procedures used for the Java SE platform, this section just describes the procedure and indicates where to find the appropriate Java SE platform documentation.

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 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 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.