|Oracle® Java Micro Edition Connected Device Configuration Runtime Guide
Release 1.1.2 for Oracle Java Micro Edition Embedded Client
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
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
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.
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)
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
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.
JSSE supports custom Provider plug-ins which can be implemented as extensions of
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.
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.
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.
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.
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
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 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
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
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.
/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.