|Oracle® Java Micro Edition Embedded Client Customization Guide
This chapter describes security features of Oracle Java Micro Edition Embedded Client in comparison to Java Standard Edition (SE).
This chapter includes these topics:
Security is a principal feature of Java technology and an important requirement for mobile and enterprise applications. Oracle Java Micro Edition Embedded Client 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 run time. It is not meant to replace the security documentation available for the Java SE platform, but rather to supplement it and show how Oracle Java Micro Edition Embedded Client and the JAAS, JCE and JSSE security optional packages are related to their counterparts in the Java SE platform.
Table 3-1 describes the security documentation for the Java SE platform.
Table 3-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 run-time 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 Oracle Java Micro Edition Embedded Client 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 Oracle Java Micro Edition Embedded Client is based on three key components:
These provide a solid base for application and run-time 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 (run-time/compile-time/link-time)
Bytecode verification (classloading-time)
Safety checks (run time)
Dynamic class loaders (classloading-time)
A security policy controls how system resources are accessed by applications at run time. 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 run-time 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 3-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 3-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 3-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 (called SunJCE Provider) 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 3-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 3-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 3-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 Oracle Java Micro Edition Embedded Client 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 Oracle Java Micro Edition Embedded Client has a fallback mechanism to read from the
/dev/urandom device when it determines that there is not 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.
Table 3-2 describes the Oracle Java Micro Edition Embedded Client security files. See Inside Java 2 Platform Security: Architecture, API Design, and Implementation by Li Gong (second edition, Addison-Wesley, 2003) for more information about Java SE security features.
Table 3-2 Security Files
Java Authentication and Authorization Service (JAAS) Optional Package is a part of JSR-219 which is a framework for enforcing access control to resources using a CodeSource-based and Subject-based security model.
lib/jce.jar lib/ext/sunjce_provider.jar lib/sunrsasign.jar
Java Cryptography Extension (JCE) Optional Package is a part of JSR-219 which extends the Java Cryptography Architecture (JCA) to include key generation and agreement, encryption and message authentication code (MAC) generation services.
Java Secure Socket Extension (JSSE) Optional Package is a part of JSR-219 which provides support for secure communication.
Certificate authority (CA) keystore file. The default keystore password is "
Security jurisdiction policy files.