Oracle® Java Micro Edition Embedded Client Customization Guide Release 1.1 E23815-01 |
|
Previous |
Next |
Thus 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
Document | Description |
---|---|
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
|
Security |
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.
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 SSLSocketFactory
.
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 keytool
.
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 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 keytool
.
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 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 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
File | Description |
---|---|
lib/jaas.jar |
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.
|
lib/jsse-cdc.jar |
Java Secure Socket Extension (JSSE) Optional Package is a part of JSR-219 which provides support for secure communication. |
lib/security/cacerts |
Certificate authority (CA) keystore file. The default keystore password is " |
lib/security/local_policy.jar lib/security/US_export_policy.jar |
Security jurisdiction policy files. |