Security in the Java Platform

Waldir Ribeiro Pires Junior

wpjr2@yahoo.com
Professor: Dr Fabrício Jailson Barth
fabricio.barth@poli.usp.br
2005.03.03

Abstract Acronyms and Definitions

For the project article in the Distributed Objects in Java J2ME
Acronym Definition
J2EE subject of the post-graduate course in Mobile and
JVM Java Virtual Machine
convergent Systems in Cellular Telephony, this article was
written with the objective to present the security features of the API Abstract Programming Interface
Java Platform, including core security mechanisms, security DES Digital Encryption Standard
extensions and security in the J2ME Platform. ITU International Telecommunication Union
SSL Secure Socket Layer
TSL Transport Layer Security
IETF Internet Engineering Task Force
Index RFC Request For Comments
Acronyms and Definitions ..........................................................1 MIDP Mobile Information Device Profile
1 Introduction .......................................................................2 CLDC Connected Limited Device
1.1 The Java Platform ...............................................2 Configuration
1.2 General Concept of Security ...............................2 CDC Connected Device Configuration
1.3 Security Resources in the Java 2 Platform ..........3 HTTPS Hyper Text Transfer Protocol Secure
2 Java Sandbox.....................................................................4 IEEE Institute of Electrical and Electronic
2.1 The Java Sandbox Model ....................................4 Engineers
2.2 Anatomy of a Java Application...........................5 RMI Remote Method Invocation
3 Java Security Extensions ...................................................7 JCP Java Community Process
3.1 JCE – Java Cryptography Extension ...................7 JSR Java Specification Request
3.2 JSSE – Java Secure Sockets Extension ...............9 SOAP Simple Object Access Protocol
3.3 Java Authentication and Authorization Service 11 JCA Java Cryptography Architecture
3.4 GSS API – Generic Security Services API .......13 LDAP Lightweight Directory Access Protocol
3.5 JSR 28 - SASL – Simple Authentication and
Secure Layer....................................................................14
4 Security in the J2ME Platform ........................................14
4.1 J2ME/ MIDP 2.0/ CLDC 1.1 ............................14
4.2 SATSA – Security and Trust Services API for
J2ME 17
4.3 JSR 219 – Foundation Profile 1.1 .....................19
5 Conclusion.......................................................................19
Glossary ....................................................................................20
References.................................................................................21

1 Introduction
Security has become an important issue in the society where
information is very important and must be protected from
unauthorized entities. Applications were then required to have
security features for allowing data processing and transfer in a
safe manner. However providing security at the application level
has proven to be quite ineffective, since this resource won’t be
accessible for other applications that may also require it. By
providing it at lower levels, applications would then be able to
utilize it whenever necessary, isolating the service for better
upgrade support, alterations and so on. Thus providing security
APIs at the platform level can be considered the best approach
to security because it “incorporates” security into the platform
model. The breaches of security tend to be less in this approach
also. All operations in upper layers will then be done in a secure
way by the lower layers, for example, in the operating system.
The Java Platform was designed from the start taking into
account the security issue for its applications.
This document presents the security features of the
Java Platform. It will describe the general concept of security,
the resources and JSRs available, extensions and some specific
security features of the J2ME platform.
1.1 The Java Platform
The Java platform is composed primarily of the Java Language,
some libraries or APIs and the Java Virtual Machine. As it will
be shown, all these components will complement each other in
the capacity of delivering a “secure” environment for Java
applications to run. The Java Programming Language was
designed from the start to provide protection to the developer
and to the end user of the application. This is so in terms of
accessing the resources of the operating system in which he/she
requires or does not require. The language itself provides
interesting factors so as to guarantee a safe environment for the
programs. APIs have also been proposed and incorporated into
the Java Language, providing some additional functionality such
as cryptography, authentication, authorization, key and
certificate management, etc. To conclude the set, the JVM also
contains some security features which prevent Java objects from
accessing the resources underlying the operating system.
The Java Platform itself brought a lot of interest for
many reasons. Its cross-platform capabilities, ease of
programming, robustness, memory management and even
security. These reasons have caused a considerable amount of
developers to select it as the killer platform for their
development needs.
1.2 General Concept of Security
The concept of security is rather complex to define, since
different types of applications will have different security
requirements, depending on its running environment, its
accessibility, its capability to transfer data through some means
of communication, etc. As stated in [1], security means different
things for different people. The term requires a discussion and
analysis of the context involved in the application. Some
security requirements can be:
o Safety from malevolent programs: Programs should not
be allowed to harm a user' s computing environment. This
includes Trojan horses as well as harmful programs that can
replicate themselves--computer viruses.
o Non-intrusiveness: Programs should be prevented from
discovering private information on the host computer or the
host computer's network.
o Authentication: The identity of parties involved in the
program should be verified.
o Encryption: Data that the program sends and receives
should be encrypted.
o Auditing: Potentially sensitive operations should always be
logged.
o Well-defining: A well-defined security specification would
be followed.
o Verifying: Rules of operation should be set and verified.
o Well-behaving: Programs should be prevented from
consuming too many system resources.
o C2 or B1 certified: Programs should have certification
from the U.S. government that certain security procedures
are included
From all these security requirements, only some have
been incorporated into the Java Platform. The default security
model of Java 1.0 for example had only provided safety from
malevolent programs and non-intrusion for its applet
applications. Since the beginning it was desired for the security
architecture in Java to be evolvable, therefore authentication was
added in version 1.1 and encryption was added only in the Java
2 core version 1.4. As the platform evolves, other security
features may be added in the future, as required. It is believed
that they will all eventually make their way into Java.
The whole demand for security in Java originated from
its ability for programs/applets to be downloaded through the
network and be run on another machine in Java enabled
browsers. Along with the widespread increase of size of the
Internet usage and its accessibility, the platform’s ability to do
such tasks brought a great deal of acceptance on the market.
The main feature that prevented Java programs to
install and run viruses, create security breaches is the fact that
Java programs are considered safe. This is so because
theoretically they cannot install, run or propagate viruses. They
also cannot perform any action that is harmful to the operating
system or the user’s computing environment. The purpose was
to bring safety into the platform itself, thus providing security
from within. For this reason, from all the security requirements
presented above, only a few had been selected for the first
version releases. In this case, only the first one had been chosen
to be a part of the first release of the platform.
1.3 Security Resources in the Java 2
Platform

The Java 2 Platform provides the following security features:

o Protections within the Java language

o A configurable security policy for accessing resources with
features such as:
o Message digest capability
o digital signature and key creation and management Figure 1: Security Policy for Java code
o An infrastructure through APIs or extensions to support all
features above. 1.3.3 APIs Infrastructure
This infrastructure provides a set of APIs to enable security
1.3.1 Java Language Security
services such as authentication, authorization, cryptography and
key/certificate management. They used to be extensions (outside
The Java Language itself was designed in the beginning to be a
the standard Java core APIs) up to version 1.3, becoming a part
“safe” programming language. Its object orientation feature
of the core APIs after 1.4. Before version 1.4, Java provided a
permits only single inheritance of classes, usage of interfaces
small set of security APIs regarded as the JCA (Java
and a strong encapsulation of data within the classes. Its strong
Cryptography Architecture). The APIs in version 1.4 security
typing feature prohibits the conversion of illegal types and array
core (J2SE and J2EE) and the security features of J2ME are:
bound checks are always done. One of the main features of the
platform is its garbage collection mechanism, picking up objects
o For J2SE and J2EE:
that are no longer being used in memory, minimizing the risk of
o JCE - Java Cryptography Extension
security breach. The usage of references for objects at runtime
o JSSE - Java Secure Sockets Extension
instead of pointers, the usage of exceptions and strong thread
o JAAS - Java Authentication and Authorization
control provide a theoretically safe environment for developers
Service
to implement their applications without causing any serious
o GSS API – Generic Security Services API
security harm to the system.
o JSR 28 – SASL – Simple Authentication and
Secure Layer
1.3.2 Configurable Security Policy o For J2ME:
o MIDP 2.0/CLDC 1.1 Security Policy Model
Regarding the platform itself, a customizable security policy for o JSR 177 – SATSA – Security and Trust Services
the platform was designed. The goal was to allow expansion and API
adaptation of the features to specific application domains and o JSR 219 – J2ME Foundation Profile 1.1
enable future upgrades. This policy is composed of:
These extensions are complementary to each other
o Management of message digests and digital signatures regarding security services provisioning. As it is shown in
o Key and certificate management Figure 2, some APIs or standards are related to others when
o Access control for Java programs of the machine resources. main security features are compared. There are three main sets
of features defined: cryptography (JCE), secure sockets handling
From all the features listed above, the last one has been (JSSE) and authentication/authorization (JAAS). The JSRs
incorporated into the platform security model using the concept listed above and shown below specify some functionalities that
of a sandbox. This will be more detailed later in this document. are related to these three main security features shown below.
The main security model premise in Java is the fact that it aims More information will be presented in the next sections of this
to protect the information from unauthorized access and document. Some subsets of the APIs are actual implementations
alterations yet allowing Java programs to be executed in the of requested and defined JSRs.
computer. The main reason for this as mentioned in 1.2 was the
convenience for Java programs to be downloaded through the
Web, Intranet, etc. According to the domain defined in the JVM
for the application type (local or remote), Java programs are
confined in a specified location, whether having access to all
resources or confined in the Sandbox. This will be better
detailed in section 2.

Figure 2: Complementary view of the extensions.

2 Java Sandbox
Java language creators needed a creative solution to provide
safety in programs when accessing the machine’s resources.
This solution would have to both enable the program itself to
execute and perform its desired function (in a controlled
manner) and at the same time restrict access to resources that
they are not allowed to have. The JVM must be capable of
determining the safety level of the program to be executed
(regardless of it being local or remote), providing this access
and at the same time ensuring the machine integrity.

The main idea behind this model is that when a

program is allowed to execute on the local machine, this
program will require an environment where it can play or run, Figure 4: Security levels in Java Sandbox
but this program needs to be confined in a “play” area only. This
program can have toys to play with, meaning that some access
to the system resources can be given to it, but always in a
limited fashion. The sandbox is made up of several different
systems operating together. These systems range from security
managers running inside of the application which imported the
applet, to safety features built into the Java language and the
virtual machine.

Java 1.0

Java 1.1

Figure 3: Java Sandbox and the JVM

2.1 The Java Sandbox Model

The Java Sandbox model provides a safe environment for

programs to execute, protecting a number of resources by
establishing access levels. The resources of a typical machine
can be:
o Local memory (RAM)
o File system
o Web server (for applets)
o Peripherals, such as the keyboard, mouse and the screen.
There are four security levels within the Sandbox for
Java programs to run. The figure below demonstrates the levels
and examples of resources these programs can have access to.
From Minimal to Open, the Sandbox can restrict access to
practically all system resources in the machine to the programs,
preventing unauthorized access.
Java 2.0
Figure 5: Java Security Architecture Evolution.
In earlier versions of the Java Platform, specifically
version 1.0, only applets were allowed to run in a Sandbox,
meaning that all other applications were considered trustable. In
version 1.1, applets that were digitally signed were considered
trustable, having more access to resources that the ones that
were not signed. In version 2.0, a whole new architecture was
developed, being based on security policies. All programs
(applets or local programs) now have the potential to run within
a Sandbox. The only difference is for applications, where
security policies are not mandatory. This can be configured via
command line. Applications can also establish and modify their
security policies. However, this can be managed by the user or
system administrator, for example, by permitting all Java
programs to run in a customized Sandbox defined by them.
2.2 Anatomy of a Java Application
Java applications (applets, local, etc) pass through specific steps
before running in the JVM of the system. The figure below
demonstrates the features that play a role in the development of
the Sandbox.
Figure 6: Elements of the Java Sandbox
These elements are:
• The Bytecode verifier
• The class loader
• The access controller
• The security manager
• The security APIs
• The key database
2.2.1 The bytecode verifier
It ensures that Java class files follow the rules of the Java
language. In terms of resources, the bytecode verifier helps
enforce memory protection for all Java programs. Before
running a newly imported applet, the class loader invokes the
verifier. The verifier checks that the applet conforms to the Java
language specification and that there are no violations of the
Java language rules or name space restrictions. The verifier
checks for common violations of memory management, like
stack underflows or overflows, and illegal data type casts, which
could allow a hostile applet to corrupt part of the security
mechanism or to replace part of the system with its own code.
2.2.2 The class loader
Class loaders are responsible for importing binary data that
defines the running program’s classes and interfaces. Classes are
introduced into the Java environment when they are referenced
by name in a class that is already running. Once the first class is
running (class defined with a main() method), future attempts of
loading classes are done by the class loader. There may be more
than one class loader inside the JVM. Classes can be loaded in
customized ways thanks to its flexible architecture.
There are two types of class loaders: a “primordial”
class loader and class loader objects. The first one (and there is
only one) is part of the JVM implementation. It loads trusted
classes, including the ones from the Java APIs, normally located
on the local disk. The latter one loads classes in custom ways,
which can be installed by the Java application at runtime. For
example, classes can be downloaded through a network and
loaded into the JVM. The classes loaded by the class loader
objects are considered suspicious in the eyes of the primordial
class loader. These objects are written in Java, compiled into
classes, loaded into the virtual machine and instantiated just like
any other object, contrasting with the first class loader (the
primordial one) which is a part of the JVM implementation.
Thanks to these class loader objects, there is no need to
know at compile time all the classes that take part in running the
desired Java application. This application can be dynamically
extended at runtime. As it runs, the desired application can
determine which classes it needs and can also load them through
the class loader objects. Class loader objects are dependant on
other class loaders, at least to the primordial class loader.
The class loader architecture contributes to Java'
s
sandbox in two ways:
o It prevents malicious code from interfering with benevolent
code.
o It guards the borders of the trusted class libraries.
Figure 7: Java class loader architecture
The class loader architecture also guards the borders of
the trusted class libraries by making sure untrusted classes can't
pretend to be trusted. If a malicious class could successfully
trick the JVM into believing it was a trusted class from the Java
API, that malicious class potentially could break through the
Sandbox barrier. By preventing untrusted classes from
impersonating trusted classes, the class loader architecture
blocks one potential approach to compromising the security of
the Java runtime condition. By providing protected namespaces
for classes loaded by different class loaders, this architecture
prevents malicious code from interfering with benevolent code.
 Figure 8: Class loader in action for example, a trusted applet from the local disk may be trying
to read the disk, or an imported untrusted applet may be trying
to connect back to its home server — the virtual machine will
When an applet is to be imported from the network, the
then perform the action. Otherwise, the virtual machine raises a
web browser calls the applet class loader. In addition to fetching
security exception and writes an error to the Java console. The
an applet’s executable code from the network, the class loader
security manager will not allow an untrusted applet to read or
enforces the name space hierarchy. A namespace controls what
write to a file, delete a file, get any information about a file,
other portions of the Java Virtual Machine an applet can access.
execute operating system commands or native code, load a
By maintaining a separate namespace for trusted code which
library, or establish a network connection to any machine other
was loaded from the local disk, the class loader prevents
than the applet’s home server. This list is not exhaustive but
untrusted applets from gaining access to more privileged, trusted
does give a representative sample of the restrictions placed on
parts of the system. Applets downloaded from the net cannot
applets. An application or a web browser can only have one
create their own class loaders. Downloaded applets are also
security manager. This assures that all access checks are made
prevented from invoking methods in the system’s class loader.
by a single security manager enforcing a single security policy.
The security manager is loaded at start-up and cannot be
In Java's sandbox, the class loader architecture is the
extended, overridden or replaced. For obvious reasons, applets
first line of defense against malicious code. It is the class loader,
can not create their own security managers.
after all, that brings code into the JVM -- code that could be
hostile.
An important note to mention is that the security
manager is optional for local Java applications and standard for
2.2.3 The access controller remote Java code (applets). The application itself has the
responsibility to start its security manager. Without the security
The access controller allows (or prevents) most access from the manager, the application will have access to all Java APIs
core API to the operating system. While the security manager is without restrictions. Once the application starts the security
the key to the security model of the Java sandbox, the access manager, the latter one will be responsible for the whole lifetime
controller is the mechanism that the security manager actually of the application. From this point on, only API requests granted
uses to enforce its protections. The access controller is actually by the manager will be accessible to the application. Security
somewhat redundant. The purpose of the security manager is to policies can also be customized, to check for API access, source
determine whether or not particular operations should be of the request (direct or indirect access from class loaders),
permitted or denied. The purpose of the access controller is loading information (local or remotely downloaded), etc.
really the same: it decides whether access to a critical system Despite having only one security manager per application, that
resource should be permitted or denied. Hence, the access security manager can establish a flexible security policy that can
controller can do everything the security manager can do. vary based on the trustworthiness of the code requesting the
action.
The reason there is both an access controller and a
security manager is mainly historical: the access controller is
only available in Java 1.2 and subsequent releases. Before the
access controller existed, the security manager had to rely on its
internal logic to determine the security policy that should be in
effect, and changing the security policy required changing the
security manager itself. Starting with 1.2, the security manager
is able to defer these decisions to the access controller. Since the
security policy enforced by the access controller can be
specified in a file, this allows a much more flexible mechanism
for determining policies. The access controller also gives us a
much simpler method of granting fine-grained, specific
permissions to specific classes.

2.2.4 The security manager

Figure 9: The security manager
The security manager is the primary interface between the core
API and the operating system; it has the ultimate responsibility In general, the security manager is responsible for:
for allowing or preventing access to all system resources. In 1.2,
the security manager uses the access controller for most (but not o Accepting a socket connection from a specified host and
all) of those decisions; in 1.0 and 1.1, the security manager is port number
solely responsible for those decisions. It is considered to be the o Modifying a thread (change its priority, stop it, and so on)
“ultimate line of defense”. o Opening a socket connection to a specified host and port
number
The security manager enforces the boundaries around o Creating a new class loader
the sandbox. Whenever an applet tries to perform an action o Deleting a specified file
which could corrupt the local machine or access information, the o Creating a new process
JVM first asks the security manager if this action can be o Causing the application to exit
performed safely. If the security manager approves the action — o Loading a dynamic library that contains native methods
o Waiting for a connection on a specified local port number
o Loading a class from a specified package (used by class
loaders)
o Adding a new class to a specified package (used by class
loaders)
o Accessing or modify system properties
o Accessing a specified system property
o Reading from a specified file
o Writing to a specified file
Controlling Access to the core APIs
o
There are two actions not listed above however that
could potentially be unsafe are allocation of memory and
invocation of threads. Currently, a hostile applet can crash a
user'
s browser by:
o Allocating memory until it runs out
o Firing off threads until everything slows to a crawl
These kinds of attacks are called denial of service
attacks (DOS), because they deny users the ability to use their
own computers. The security manager does not allow you to
enforce any kind of limit on allocated memory or thread
creation. (There are no checkAllocateMemory() or
checkCreateThread() methods in the security manager class.)
The following are other kinds of hostile applets that currently
are possible:
o Applets that send unauthorized e-mail from the user' s
computer
o Applets that make annoying noises even after you leave the
Web page
o Applets that display offensive images or animations
A security manager therefore isn' t enough to prevent
every possible action that could render a machine useless.
Despite the attacks, the security manager attempts to provide a
check method that allows you to control access to almost all
potentially unsafe actions.
2.2.5 The security APIs
The security APIs (that is, classes in the java.security package
composing the JCA) forms the basis for authenticating signed
Java classes. Although it is only a small box in the diagram, the
security package is a complex API. This API includes:
o The security provider interface, the means by which
different security implementations may be plugged into the
security package
o Message digests
o Keys and certificates
o Digital signatures
o Encryption (an optional extension to the security package)
2.2.6 The key database
This database contains a set of keys used by the security
manager and access controller to verify the digital signature that
accompanies a signed class file. In the Java architecture, it is
part of the security package, though it may be manifested as an
external file or database.
The last two items on this list have broad applicability
beyond expanding the Java sandbox. With respect to the
sandbox, digital signatures play an important role, because they
provide authentication of who actually owns the Java class. This
provides the ability for end users and system administrators to
grant very specific privileges to individual classes or signers.
But a digital signature might be used for other applications that
require authentication for data access.
3 Java Security Extensions
As presented earlier, extensions added to the Java Platform
throughout the versions helped increase the amount of security
services that users and/or programs may require. They can
function independently or in a complementary fashion. For
example, in a J2EE server, enterprise applications may require
authentication and cryptographic services for tasks that are
unique or different within the server.
Figure 10: Java Platform Security Extensions
3.1 JCE – Java Cryptography Extension
JCE provides a variety of cryptographic operations:
o Encryption (Ciphers) support for symmetric, asymmetric,
block and stream ciphers. It also supports secure streams
and sealed objects.
o Secure Key Exchange
o Secure Message Digests via Message Authentication Code
(MAC) algorithms.
o An alternate key management system
o Support to various encryption algorithms
o DES, DESede, Blowfish, PBEwithMD5AndDES,
gerenciamento de chaves Diffie-Hellman,
TripleDES, MD5 e SHA1
o AES (Java 1.4.2)
3.1.1 Export Controls
JCE was designed in a way that other cryptographic libraries can
be plugged in as service providers, allowing new algorithms to
be inserted seamlessly. JCE was created to extend the Java
Cryptography Architecture (JCA) APIs already available in the
Java 2 Platform that were restricted to usage inside the US only.
JCA offers only the basic architecture and interfaces and
fundamental objects in cryptography. It also provides a service
provider architecture that allows each provider to include
specific algorithms. JCE contains the actual implementation of o Key Agreement: provides the functionality of a key
the cryptography algorithms themselves. agreement protocol. The keys involved in establishing a
shared secret are created by one of the key generators
Many cryptographic algorithms however are subjected (KeyPairGenerator or KeyGenerator), a KeyFactory, or as
to US export control regulations. The U.S. is not the only a result from an intermediate phase of the key agreement
government that regulates the use of encryption, and encryption protocol.
software can face import restrictions as well as export
o Mac: provides the functionality of a Message
restrictions. Other countries have regulations for cryptography,
Authentication Code (MAC).
but in most cases they are less onerous than those of the United
States. Even though the U.S. has relaxed its export rules, some
restrictions still apply. JCE or JSSE may not be exported (and,
hence, any programs that use them) for example, to the
following countries: Afghanistan, Cuba, Iran, Iraq, Libya, North
Korea, Serbia/Montenegro (Yugoslavia), Sudan, Syria and
parties listed on the Denied and Restricted Parties List (available
at http://bxa.fedworld.gov/prohib.html).

The encryption extensions, like many aspects of the

Java platform, allow for third-party implementations of JCE.
However, many of the popular algorithms that are used by the
extensions are patented, which also restricts their use. RSA Data
Security, Inc. holds a patent in the U.S. on several algorithms
involving RSA encryption and digital signatures; Ascom System Figure 11: JCA and JCE
AG in Switzerland holds both U.S. and European patents on the
IDEA method of performing encryption. If you live in a country
The main packages of JCE are:
where these patents apply, you can' t use these underlying
algorithms without paying a licensing fee to the patent holder. In
o java.security (JCA)
particular, this means that many of the third-party security
o Access control to resources
providers and third-party implementations of JCE cannot be
o Message digests
used within the United States because of patents held by RSA.
o Public key, digital signature and certificate
Sun for example has an agreement with RSA Data Security to
management, (X.509 v2 e v3)
redistribute its implementation of the RSA algorithms.
o Safe random number generator
o RSA (symmetric cypher algorithm) and DSA
3.1.2 Core Classes (Digital Signature Algorithm)
o javax.crypto (JCE)
The Core classes of JCE are: o Cipher handling
o Diffie-Hellman Key Generation and management
o Cipher: provides the functionality of a cryptographic o javax.security (JCE)
cipher used in the encryption and decryption. It constitutes o Kerberos authentication protocol
the core of the JCE framework. o Digital certificate management

o Cipher Streams: JCE presents the concept of secure
streams, combined with InputStream or OutputStream with
a Cipher object. They basically encrypt or decrypts the data
passing through.
o Key Generator: used to generate secret keys for symmetric
algorithms.
o Secret Key Factory: represents a factory for secret keys. It
is used to convert keys of type java.security.Key into key
Following below an example of JCE using Blowfish:
/*
* Copyright 1997-2001 by Sun Microsystems, Inc.,
* 901 San Antonio Road, Palo Alto, California, 94303, U.S.A.
* All rights reserved.
*
* This software is the confidential and proprietary information
* of Sun Microsystems, Inc. ("Confidential Information"). You
* shall not disclose such Confidential Information and shall use
* it only in accordance with the terms of the license agreement
* you entered into with Sun.
*/

specifications (transparent representations of the underlying import java.security.*;

import javax.crypto.*;
key material in a understandable format) and vice-versa. It import javax.crypto.spec.*;
operates only on secret keys (symmetric). /**
* This program generates a Blowfish key, retrieves its raw bytes, and
o Sealed Object: enables a programmer to create an object * then reinstantiates a Blowfish key from the key bytes.
and protect its confidentiality with a cryptographic * The reinstantiated key is used to initialize a Blowfish cipher for
* encryption.
algorithm. If an object can implement the */

java.io.Serializable interface, a sealed object can be created, public class BlowfishKey {

encapsulating the original object in a serialized format and
sealing (by means of encryption) its serialized contents
using a cryptographic algorithm to protect its
confidentiality.
public static void main(String[] args) throws Exception {
KeyGenerator kgen = KeyGenerator.getInstance("Blowfish");
SecretKey skey = kgen.generateKey();
byte[] raw = skey.getEncoded();
SecretKeySpec skeySpec = new SecretKeySpec(raw, "Blowfish");

Cipher cipher = Cipher.getInstance("Blowfish");

cipher.init(Cipher.ENCRYPT_MODE, skeySpec);
 byte[] encrypted =
cipher.doFinal("This is just an example".getBytes());
}
}
The key generator is instantiated using the Blowfish
algorithm. Then the secret key is generated and converted into
raw data (bytes). The secret key specification is then instantiated
using the raw data and the algorithm. The cipher object is then
created and initialized with the key specification. At the end the
data is encrypted and stored into a byte array format.
3.2 JSSE – Java Secure Sockets
Extension
This extension enables secure Internet communications. It
provides a framework and an implementation for a Java version
of the SSL and TLS protocols and includes functionality for data
encryption, server authentication, message integrity, and
optional client authentication. Using JSSE, developers can
provide secure passage of data between a client and a server
running any application protocol, such as Hypertext Transfer
Protocol (HTTP), Telnet, or FTP, over TCP/IP. By abstracting
the complex underlying security algorithms and "handshaking"
mechanisms, JSSE minimizes the risk of creating subtle, but
dangerous security vulnerabilities. Furthermore, it simplifies
application development by serving as a building block which
developers can integrate directly into their applications.
JSSE was previously an optional package to the Java 2
SDK versions 1.2 and 1.3, but it has now been integrated into
the J2SDK, v 1.4. JSSE provides both an application
programming interface (API) framework and an implementation
of that API. The JSSE API supplements the "core"
cryptographic services defined in the Java 2 SDK, v 1.4
java.security and java.net packages by providing extended
networking socket classes, trust managers, key managers, SSL
Contexts, and a socket factory framework for encapsulating
socket creation behavior. It also provides a limited public key
certificate API that is compatible with Java Development Kit
1.1-based platforms. However, this limited javax.security.cert
certificate API is provided only for backward compatibility with
JSSE 1.0.x and should not be used. Instead, the standard
java.security.cert certificate API should be used.
Version 1.0.2 takes advantage of the relaxed export
restrictions of the U.S. and is exportable. Unlike JCE, however,
there are still two different versions of JSSE: one for domestic
use (use within the United States and Canada) and one for
global use. The difference between these two versions is that the
domestic version allows you to substitute new implementations
of the SSL algorithms. Such substitution is still prohibited by
export rules, so the global version does not allow it. However,
both versions provide exactly the same API and the same key
strength for their encryption.
Figure 12: Interaction between SSL client and Server.
The SSL messages are sent in the following order:
1. Client hello - The client sends the server information
including the highest version of SSL it supports and a list of
the cipher suites it supports. This information includes
cryptographic algorithms and key sizes.
2. Server hello - The server chooses the highest version of
SSL and the best cipher suite that both the client and server
support and sends this information to the client.
3. Certificate - The server sends the client a certificate or a
certificate chain. A certificate chain typically begins with
the server' s public key certificate and ends with the
certificate authority'
s root certificate. This message is
optional, but is used whenever server authentication is
required.
4. Certificate request - If the server needs to authenticate the
client, it sends the client a certificate request. In Internet
applications, this message is rarely sent.
5. Server key exchange - The server sends the client a server
key exchange message when the public key information
sent in 3) above is not sufficient for key exchange.
6. Server hello done - The server tells the client that it is
finished with its initial negotiation messages.
7. Certificate - If the server requests a certificate from the
client in Message 4, the client sends its certificate chain,
just as the server did in Message 3. Only a few Internet
server applications ask for a certificate from the client.
8. Client key exchange - The client generates information
used to create a key to use for symmetric encryption. For
RSA, the client then encrypts this key information with the
server'
s public key and sends it to the server.
9. Certificate verify - In internet applications, this message is
rarely sent. Its purpose is to allow the server to complete the
process of authenticating the client. When this message is
used, the client sends information that it digitally signs
using a cryptographic hash function. When the server
decrypts this information with the client' s public key, the
server is able to authenticate the client.
10. Change cipher spec - The client sends a message telling
the server to change to encrypted mode.
11. Finished - The client tells the server that it is ready for
secure data communication to begin.
12. Change cipher spec - The server sends a message telling
the client to change to encrypted mode.
13. Finished - The server tells the client that it is ready for
secure data communication to begin. This is the end of the
SSL handshake.
14. Encrypted data - The client and the server communicate
using the symmetric encryption algorithm and the
cryptographic hash function negotiated in Messages 1 and Figure 13: Cryptographic functionality in JSSE
2, and using the secret key that the client sent to the server
in Message 8.
3.2.1 Core Classes
The JSSE may also integrate with JCE in order to use The core classes for JSSE are:
each others functionalities. However, the cryptographic
capabilities of JSSE are not available for use by other
applications. Here below there are two code examples (server o SocketFactory and ServerSocketFactory: These abstract
and client) using SSL to connect to each other using JSSE. classes are used to create sockets. They must be subclassed
by other factories, which create particular subclasses of
import java.io.*;
import javax.net.ssl.*;
sockets and thus provide a general framework for the
addition of public socket-level functionality.
. . .

int port = availablePortNumber; o SSLSocket and SSLServerSocket: These classes are

SSLServerSocket s;
subclasses of the standard Java java.net.Socket class. It
supports all of the standard socket methods and adds
try {
SSLServerSocketFactory sslSrvFact = additional methods specific to secure sockets. Instances of
(SSLServerSocketFactory)
SSLServerSocketFactory.getDefault();
this class encapsulate the SSLContext under which they
s =(SSLServerSocket)sslSrvFact.createServerSocket(port); were created. There are APIs to control the creation of
SSLSocket c = (SSLSocket)s.accept(); secure socket sessions for a socket instance but trust and
OutputStream out = c.getOutputStream();
key management are not directly exposed.
InputStream in = c.getInputStream();
o SSLSocketFactory and SSLServerSocketFactory: They
// Send messages to the client through
// the OutputStream act as factories for creating secure sockets. They are
//
//
Receive messages from the client
through the InputStream
abstract subclasses of javax.net.SocketFactory. They
} encapsulate the details of creating and initially configuring
catch (IOException e) { secure sockets. This includes authentication keys, peer
}
certificate validation, enabled cipher suites, etc.
The Server Code o SSLSession Interface: this represents a security context
import java.io.*;
negotiated between the two peers of an SSLSocket
import javax.net.ssl.*; connection. Once a session has been arranged, it can be
. . . shared by future SSLSockets connected between the same
int port = availablePortNumber;
two peers. The session contains the cipher suite which will
String host = "hostname"; be used for communications over a secure socket as well as
try { a non-authoritative hint as to the network address of the
SSLSocketFactory sslFact =
(SSLSocketFactory)SSLSocketFactory.getDefault();
remote peer, and management information such as the time
SSLSocket s = of creation and last use. A session also contains a shared
(SSLSocket)sslFact.createSocket(host, port);
master secret negotiated between the peers that is used to
OutputStream out = s.getOutputStream();
InputStream in = s.getInputStream();
create cryptographic keys for encrypting and guaranteeing
the integrity of the communications over an SSLSocket. The
// Send messages to the server through
// the OutputStream value of this master secret is known only to the underlying
//
//
Receive messages from the server
through the InputStream
secure socket implementation and is not exposed through
} the SSLSession API.
catch (IOException e) {
} o HttpsURLConnection: this class is similar to http, except
that it first establishes a secure channel via SSL/TLS
The Client Code sockets before requesting/receiving data.
javax.net.ssl.HttpsURLConnection extends the
java.net.HttpsURLConnection class, and adds support for
https-specific features.
o Support Classes and Interfaces: provided to support the
creation and initialization of SSLContext objects, which are
used to create SSLSocketFactory and
SSLServerSocketFactory objects. The support classes and
interfaces are part of the javax.net.ssl package.
o SSLContext: an engine class for an implementation of a
secure socket protocol. An instance of this class acts as a
factory for SSL socket factories. An SSLContext holds all of
the state information shared across all sockets created under
that context. For example, session state is associated with
the SSLContext when it is negotiated through the handshake
protocol by sockets created by socket factories provided by
the context. These cached sessions can be reused and shared
by other sockets created under the same context.
o TrustManager: it determines whether the presented
authentication credentials should be trusted. If the
credentials are not trusted, the connection will be
terminated.
o TrustManagerFactory: an engine class for a provider-
based service that acts as a factory for one or more types of
TrustManager objects.
o X509TrustManager Interface: it extends the general
TrustManager interface. This interface must be
implemented by a trust manager when using X.509-based
authentication. For more information on X.509, see
glossary.
o KeyManager: responsible for selecting the authentication
credentials that will eventually be sent to the remote host.
The relationship between TrustManagers and KeyManagers
is that the first one determines whether the remote
authentication credentials (and thus the connection) should
be trusted. The latter one determines which authentication
credentials to send to the remote host.
o KeyManagerFactory: an engine class for a provider-based
service that acts as a factory for one or more types of
KeyManager objects.
o X509KeyManager Interface: it extends the general
KeyManager interface. It must be implemented by a key
manager for X.509-based authentication.
o Secondary Support Classes and Interfaces: support the
creation, use, and management of secure sockets. They are
as follows:
o SSLSessionContext Interface: a grouping of
SSLSessions associated with a single entity.
o SSLSessionBindingListener: an interface
implemented by objects which want to be notified
when they are being bound or unbound from an
SSLSession.
o SSLSessionBindingEvent: the event
communicated to an SSLSessionBindingListener
when it is bound or unbound from an SSLSession.
o HandShakeCompletedListener Interface: an
interface implemented by any class which wants to
receive notification of the completion of an SSL
protocol handshake on a given SSLSocket
connection.
o HandShakeCompletedEvent: the event
communicated to a HandShakeCompletedListener
upon completion of an SSL protocol handshake on
a given SSLSocket connection.
o X509Certificate: provides a standard way to
access the attributes of X.509 certificates.
The main packages of JSSE are:
o javax.net
o Factories for creating sockets, server sockets, SSL
sockets, and SSL server sockets. Using socket
factories you can encapsulate socket creation and
configuration behavior.
o javax.net.ssl
o SSL session management
o Secure (SSL) sockets and server sockets.
o Key and trust manager interfaces (including
X.509-specific key and trust managers), and
factories for creating them.
o javax.security.cert
o A public key certificate API compatible with JDK
1.1-based platforms.
3.3 Java Authentication and
Authorization Service
This extension is used for two purposes: authentication and
authorization of users. It provides the capability to determine
who is currently executing java code regardless of the code type
(applet, application, bean, etc). It also ensures that the Java code
being executed in a JVM to have the access control rights or
permissions required to do the actions performed. It provides
flexible and scalable mechanisms for securing client- and
server-side Java applications.
Earlier Java security frameworks focused on protecting
the user from mobile code, based on the code' s origins and
owner. JAAS however protects the system from users, based on
who runs the code and their permissions. This pluggable,
stackable API lets you incorporate standard security
mechanisms like Solaris NIS (Network Information Services),
Windows NT, LDAP (lightweight access directory protocol),
Kerberos, and others into your application in a consistent,
configurable way.
Figure 14: JAAS Pluggable Authentication
JAAS authentication is performed in a pluggable
fashion. This allows applications to remain separated from
underlying authorization technologies. Updated authentication
technologies can be plugged under the application without
requiring modifications to the application itself. Applications
enable the authentication process by instantiating a
LoginContext object, which in turn references a Configuration to
determine the authentication technology, or LoginModule(s), to
be used in performing the authentication. Typical LoginModules
may prompt for and verify a username and password. Others
may read and verify a voice or fingerprint sample. This can be
seen in the figure below:
Figure 15: JAAS authentication sequence diagram
3.3.1 Core Classes and Interfaces
The core classes and interfaces for JAAS are (for authentication
and authorization):
o Subject: source of a request, which needs to be identified
and authenticated before authorizing it to access resources.
It can be an entity or a service
o Principals: can be associated with a subject if
authentication n is successful. They represent the subject’s
identities.
o Credentials: An object that is verified when presented to
the verifier in an authentication transaction. It can be any
class. Two interfaces are optional for credentials, the
Refreshable and Destroyable. Credentials can be public,
such as the name of the subject or a public key, or private
like passwords or private keys.
3.3.1.1 Authentication Classes and interfaces:
To authenticate a subject (user or service), the following steps
are performed:
1 An application instantiates a LoginContext.
2 The LoginContext consults a Configuration to load all of the
LoginModules configured for that application.
3 The application invokes the LoginContext's login method.
4 The login method invokes all of the loaded LoginModules.
Each LoginModule attempts to authenticate the subject.
Upon success, LoginModules associate relevant Principals
and credentials with a Subject object that represents the
subject being authenticated.
5 The LoginContext returns the authentication status to the
application.
6 If authentication succeeded, the application retrieves the
Subject from the LoginContext.
Here below this sample code demonstrates what is
necessary to authenticate and logout a subject:
// let the LoginContext instantiate a new Subject
LoginContext lc = new LoginContext("entryFoo");
try {
// authenticate the Subject
lc.login();
System.out.println("authentication successful");
// get the authenticated Subject
Subject subject = lc.getSubject();
...
// all finished -- logout
lc.logout();
} catch (LoginException le) {
System.err.println("authentication unsuccessful: " +
le.getMessage());
}
The core classes and interfaces for authentication are:
o LoginContext: authentication class that provides the basic
methods used to authenticate subjects, and provides a way
to develop an application independent of the underlying
authentication technology. It consults a Configuration to
determine the authentication services, or LoginModule(s),
configured for a particular application. Therefore, different
LoginModules can be plugged in under an application
without requiring any modifications to the application itself.
The methods in this class are:
o login(): performs login, a relatively complex step
that invokes all LoginModules specified for this
configuration. If it succeeds, it creates an
authenticated Subject. If it fails, it throws a
LoginException.
o getSubject(): returns the authenticated Subject.
o logout(): logs out the authenticated Subject and
removes its Principals and credentials.
o LoginModule: interface that allows developers to
implement different kinds of authentication technologies
that can be plugged in under an application. Some of these
modules (implementations available in J2SE 1.4) can be:
o JndiLoginModule: verifies against a directory
service configured under JNDI (Java Naming and
Directory Interface)
o Krb5LoginModule: authenticates using Kerberos
protocols. See glossary for more information on
Kerberos.
o NTLoginModule: uses the current user's NT
security information to authenticate
o UnixLoginModule: uses the current user'
s Unix
security information to authenticate
o CallbackHandler: used to obtain authentication
information from the user to the LoginModule. It either
 gathers input from users (such as a password or smart card
pin number) or supplies information to users (such as status
information).
o Callback: defines the interface for callbacks.
o Authorization Classes: grants access control permissions
To make JAAS authorization take place, granting access control
permissions based not just on what code is running but also on
who is running it, the following is required:
1 The user must be authenticated, as described in the
LoginContext section.
2 The Subject that is the result of authentication must be
associated with an access control context, as described in
the Subject section.
3 Principal-based entries must be configured in the security
policy, as described below in the core classes section.
The core classes and interfaces for authorization are:
o Policy: an abstract class for representing the system-wide
access control policy.
o AuthPermission: encapsulates the basic permissions
required for JAAS. An AuthPermission contains a name
(also referred to as a "target name").
o PrivateCredentialPermission: protects access to a
Subject's private credentials and provides one public
constructor:
By providing an extensible model for authentication,
authorization of users and controlling permissions, this
extension can provide the tools with the flexibility of creating
customized login mechanisms, while at the same time using pre-
built modules that can be plugged into the application without
any side effect.
3.4 GSS API – Generic Security
Services API
The GSS API is a generic API for doing client-server
authentication. The motivation behind it is that every security
system may have its own API and the effort involved with
adding different security systems to applications is extremely
difficult with the variance between security APIs. However,
with a common API, application vendors could write to the
generic API and it could work with any number of security
systems.
The relevant standards for GSS API include:
o RFC 2743 - Generic Security Services Application Program
Interface Version 2, Update 1.
http://www.ietf.org/rfc/rfc2743.txt
o RFC 1509 - Generic Security Service API: C-bindings
http://www.ietf.org/rfc/rfc1509.txt
o RFC 1964 - The Kerberos Version 5 GSS-API Mechanism.
http://www.ietf.org/rfc/rfc1964.txt
The GGS API is a standard defined by the IETF that
proposes a generic interface for secure messages and
authentication. It was designed for the client/server architecture
and used for securely exchanging messages between
communicating applications. The Java GSS-API contains the
Java bindings for the Generic Security Services Application
Program Interface (GSS-API) defined in RFC 2853. GSS-API
offers application programmers uniform access to security
services atop a variety of underlying security mechanisms,
including Kerberos.
This standard provides confidentiality for the
associated parties, message integrity and authentication. It is
supported by JAAS.
Figure 16: GSS Interfaces and Classes
3.4.1 Core Classes
The core classes for the GSS API are:
o GSSManagerFactory: factory responsible for instantiating
GSSManagers.
o GSSManager: serves as a factory for other important GSS-
API classes and also provides information about the
mechanisms that are supported. It can create instances of
classes implementing the following three GSS-API
interfaces: GSSName, GSSCredential, and GSSContext. It
also has methods to query for the list of available
mechanisms and the nametypes that each mechanism
supports.
o GSSCredential: this interface encapsulates the GSS-API
credentials for an entity. A credential contains all the
necessary cryptographic information to enable the creation
of a context on behalf of the entity that it represents. It may
contain multiple, distinct, mechanism specific credential
elements, each containing information for a specific
security mechanism, but all referring to the same entity. A
credential may be used to perform context initiation,
acceptance, or both.
o GSSContext: this interface encapsulates the GSS-API
security context and provides the security services that are
available over the context. Security contexts are established
between peers using locally acquired credentials. Multiple
contexts may exist simultaneously between a pair of peers,
using the same or different set of credentials. GSS-API
functions in a manner independent of the underlying
transport protocol and depends on its calling application to
transport the tokens that are generated by the security
context between the peers.
3.5 JSR 28 - SASL – Simple o JSR 219 – Foundation Profile 1.1
Authentication and Secure Layer
4.1 J2ME/ MIDP 2.0/ CLDC 1.1
It is defined as an authentication service for network protocols.
Security has always been a primary focus of MIDP. In
It allows LDAP clients to authenticate with an LDAP server and
MIDP 1.0, however, security is mostly addressed by removing
provides security for the data transmitted with this protocol. It
the ability to perform sensitive operations. MIDP 2.0 comes
follows the pluggable security provider approach and it is
with enhanced security features that open up more capabilities
defined by RFC 2222.
of devices to developers without compromising security. It
includes enhanced mobile code and application security by the
The JSR 28 proposes a standard API and framework
means of a defined security manager, security domains, MIDlet
for the Java programming language to implement the SASL
signature capability and provisioning process.
standard. As stated in the JSR definition, it specifies a
challenge-response protocol in which data is exchanged between
the client and the server for the purposes of authentication and 4.1.1 MIDlet Permissions
(optional) establishment of a security layer on which to carry on
subsequent communications. See glossary for more information The figure below demonstrates an attempt to connect
regarding the challenge-response protocol. through HTTP. If the client application, in this case the MIDlet,
is allowed to access this channel, it will connect and receive an
answer in HTML. Otherwise it will throw a security exception.
4 Security in the J2ME The source code after the figure demonstrates this figure.
Platform
This section provides security features inside the J2ME
platform. Due to the different markets and architecture, these
have been provided differently throughout the platforms based
on their characteristics, limitations, application domain, etc. At
the J2ME platform, we may have three security domains
defined: the one set by MIDP 2.0/CLDC 1.1 standards, another
set by SATSA (Security and Trust Services API) for JavaCards
and a last one set by JSR 219. Figure 18: MIDP/CLDC Concept of Permissions: HTTP
access allowed or restricted.
The figure below demonstrates the differences between
the two patforms: J2ME and JavaCard. They are different in
import java.io.*;
both the VM implementation and their core APIs or
frameworks. The security extensions therefore will not be import javax.microedition.io.*;
import javax.microedition.lcdui.*;
identical, but some similarities can be found, for example, in import javax.microedition.midlet.*;

cases where one is a subset of the other. public class HTTPMIDlet

extends MIDlet
implements CommandListener, Runnable {
private Display mDisplay;
private Form mMainScreen;

public HTTPMIDlet() {
mMainScreen = new Form("HTTPMIDlet");
mMainScreen.append(
"Press OK to create an HTTP connection.");

Command exitCommand =
new Command("Exit", Command.EXIT, 0);
Command okCommand =
new Command("OK", Command.OK, 0);
mMainScreen.addCommand(exitCommand);
mMainScreen.addCommand(okCommand);
mMainScreen.setCommandListener(this);
}

public void startApp() {

if (mDisplay == null)
mDisplay = Display.getDisplay(this);

mDisplay.setCurrent(mMainScreen);
}

public void pauseApp() {

}

public void destroyApp(boolean unconditional) {}

Figure 17: J2ME and JavaCard Platforms
// CommandListener method

public void commandAction(Command c, Displayable s) {

The security services that will be discussed in this if (c.getCommandType() == Command.EXIT)
notifyDestroyed();
section are: else if (c.getCommandType() == Command.BACK)
mDisplay.setCurrent(mMainScreen);
else if (c.getCommandType() == Command.OK) {
o J2ME/ MIDP 2.0/CLDC 1.1 // Put up a wait screen.
Form waitForm = new Form("Connecting...");
o SATSA – Security and Trust Services API for J2ME mDisplay.setCurrent(waitForm);
 // Make the connection
Thread t = new Thread(this);
the Wireless Toolkit 2.0, the developer may choose the security
t.start(); domain designed for the application, as shown below.
}
}

// Runnable method

public void run() {

String url = "http://wireless.java.sun.com/";

Form resultsForm = new Form("Results");

Command backCommand =
new Command("Back", Command.BACK, 0);
resultsForm.addCommand(backCommand);
resultsForm.setCommandListener(this);

HttpConnection hc = null; Figure 19: Selecting a protection domain in WTK 2.0

InputStream in = null;

try {
// Now make a connection to the server.
hc = (HttpConnection)Connector.open(url);
All Java security mechanisms, and particularly the
sandbox concept, implicitly require a MIDlet verifier as a
// Retrieve the response.
in = hc.openInputStream(); foundation very similar to the concept seen in J2SE (presented
int length = 256;
in section 2 of this article), however simplified. Without this
byte[] raw = new byte[length]; verification no security policy can be enforced. The code below
int readLength = in.read(raw);
demonstrates how MIDlet permissions can be defined in the
String message = new String(raw, 0, readLength);
resultsForm.append(message);
application descriptor (JAD file).
}
catch (Exception e) {
resultsForm.append( MIDlet-Permissions: javax.microedition.io.Connector.http
new StringItem("Exception: ", e.toString())); MIDlet-Permissions-opt: javax.microedition.io.Connector.socket
}
finally {
if (in != null) {
try { in.close(); }
catch (IOException ioe) {} 4.1.2 Security Domains
}
if (hc != null) {
try { hc.close(); }
catch (IOException ioe) {}
Downloaded code can be pretty dangerous, especially
} when you don' t know the origin and the owner. Even though
}
mDisplay.setCurrent(resultsForm); MIDlets, running on a virtual machine, are intrinsically a lot
}
}
safer than binary code, there are still some risks, for example:

• A downloaded MIDlet could make undesired network

MIDP 2.0/CLDC 1.1 security is based on the concept
of permissions. To make any type of network connection, a
MIDlet must have an appropriate permission. It introduces the
notion of trusted/untrusted applets which allows the developer to
define restrictions to resources for each MIDlet. To obtain
privileged access, a MIDlet must be assigned to specific pre-
defined domains, and properly signed. In order to be
downloaded, installed and granted associated permissions, the
device must successfully verify the signature. A MIDlet may
request permissions by declaring them in the application
descriptor using for example MIDlet-Permissions. This however
doesn’t mean that all permissions will be granted to the MIDlet.
Some security permissions may be:
• javax.microedition.io.Connector.http
• javax.microedition.io.Connector.socket
• javax.microedition.io.Connector.https
• javax.microedition.io.Connector.ssl
• javax.microedition.io.Connector.datagram
• javax.microedition.io.Connector.serversocket
• javax.microedition.io.Connector.datagramreceiver
• javax.microedition.io.Connector.comm
• javax.microedition.io.PushRegistry
By default MIDP applications are not trusted, and are
assigned to untrusted domains that prevent access to any
privileged functionality. These untrusted Java MIDlets are
executed inside a small “sandbox”. Trusted midlets are also
limited by permissions and cannot access ungranted APIs. For
connections, connections that cost the user money;
• This MIDlet could also try to collect information and send it
to a server for unauthorized use for example.
A MIDP device gives its owner a lot of flexibility in
choosing games and applications, but with that flexibility the
risk of running code whose origins and motivations may not
well be know still exist.
Protection domains can be configured to make it safer
for users to run downloaded MIDlets. The MIDP specification is
deliberately open about how protection domains should be
defined. It leaves a lot to the implementor' s discretion: the
number of protection domains that will be present and how they
will be defined. The specification does, however, suggest a
protection domain based on cryptographic signatures and
certificates for the application. The idea is that the carrier, or the
software developer, creates a signing-key pair and obtains a
certificate from a recognized certificate authority. The carrier or
developer computes a signature of the MIDlet suite JAR, then
places that signature and the corresponding certificate in the
application descriptor (JAD file).
A signed MIDlet suite assures the user that the contents
of the MIDlet suite have not been tampered (see glossary) with
and that the MIDlet suite comes from an identifiable (and thus
legally accountable) source. The MIDP implementation on the
device can verify the identity of the developer by verifying the
developer' s signature. It can use the developer's public key to
verify the integrity of the MIDlet suite itself.
 The J2ME Wireless Toolkit easily allows the developer
to specify the permissions that a MIDlet suite requires. MIDlets
are sorted into buckets called protection domains based on their
credentials. A protection domain is a collection of permissions
and a set of criteria for entry into the domain. The MIDP 2.0
specification includes suggestions for signing MIDlet suites
cryptographically; this scheme is implemented in the J2ME
Wireless Toolkit, which includes simple tools for creating a key
pair and signing a MIDlet suite.
MIDP 2.0 security model therefore provides a pre-
verifier and a simplified Sandbox model. It constitutes a very
simplified class verifier, with no access to native code (inside
KVM), impossibility to overload the class loader, restricted
access to MIDP and CLDC APIs only and a few features in
J2SE that were eliminated:
o JNI (KNI as subset only)
o Class loaders that can be defined by the user
o Reflection
o Weak referencing
Figure 20: Signing a MIDlet Suite using WTK 2.0
4.1.3 HTTPS
HTTPS support has been made mandatory for data
communications. It is the most widely used data security
protocol in J2ME applications.
However, future mobile applications require more
flexible, customizable and better optimized security solutions.
HTTPS, SSL and TLS are connection based security protocols.
The main focus is to provide security through communication
channels and by this secure everything that passes through these
channels.
The inflexibility for special security requirements
makes the HTTPS a troublesome feature. There may be
requirements which require the platform to be customized, such
as:
o Processing Speed: mobile devices must be responsive to
the user. However they have slow CPUs and Java itself is
not as fast as desired. When there is a demand for
cryptographic tasks, specifically public key algorithms, for
J2ME devices is a great challenge.
o Small footprint: there is a great demand for cryptographic
packages that are compatible to the J2ME memory
limitations. Most modern cryptographic packages today
consume several MBs of storage space. There must be a
balance between features and footprint.
o Support to various algorithms: the idea would to offer
flexible security schemes, with the ability to select from a
range of algorithms. They must include the following:
o Symmetric key encryption
o Public key encryption
o Digital signatures
o Password-based encryption
o Easy Key Management: matching and identifying keys
with different algorithms on both communication ends is
quite complex and tool slow on mobile devices, specifically
mentioning the public key cryptography. Keys may have to
be generated at the server and transported to the device
safely. APIs to provide such features must exist.
o Quick correction of bugs found in the security
architecture: bugs must be fixed rather fast in order to
guarantee the integrity of the security services in the API
o Etc.
4.1.4 Third Party Security APIs
This necessity has caused some interest for third party
development of security framework APIs for this platform.
Some of them are:
o Bouncy Castle Lightweight API: it begun as a community
attempt to implement a free, clean-room, open source JCE
provider. They have developed their own lightweight API
to be wrapped into JCE provider classes. It supports a great
deal of algorithms, but unfortunately is has a large footprint.
It is for free.
o Phaos Technology Micro Foundation Toolkit:
implemented by a Java and XML security solution provider,
this company provides toolkits for secure XML Java APIs,
J2ME lightweight crypto APIs and one of the first
implementations of the SSL protocol on J2ME/CLDC.
o NTRU Neo for Java Toolkit: developed by four math
professors at Brown University, this toolkit includes an
encryption algorithm (NTRUEncrypt) and a signature
algorithm (NTRUSign). Their algorithms are published and
are soon to become IEEE and IETF standards.
o B3 Security: developed by a company that specializes in
developing new lightweight security infrastructures that
minimize the overhead associated with public key
cryptography. Its products are B3 Tamper Detection and
Digital Signature (B3Sig) SDK and B3 End-to-End
(B3E2E) Security SDK, both being available for J2ME.
There are also APIs developed by MIDP device
vendors, such as Motorola, that provide device-specific
cryptographic extensions. They take the advantage of using
native cryptography libraries and special features in hardware.
For this reason, they tend to have good device performance. The
only problem is the portability of applications to other devices,
causing J2ME fragmentation and the loss of one of Java’s
greatest advantages. One way to avoid such fragmentation and
still take advantage of native performance is to develop standard
J2ME cryptography API specifications and allow device
vendors to plug in their own implementations. The JSR 177
provides J2ME applications with APIs for security and trust
services. This will be discussed in better detail in the next
section.

4.2 SATSA – Security and Trust

Services API for J2ME

The JavaCard technology depends fully on the SATSA

specification (JSR 177) for its security infrastructure. This JSR
defines the Security and Trust Services APIs to permit secure Figure 21: MIDP device communicating with a JavaCard
access to smartcards by giving cryptographic capacities for via APDUs.
applications in small devices, including J2ME MIDP 2.0/CLDC
1.1 devices. It is composed of four distinct APIs:

o APDU – Application Protocol Data Unit 4.2.2 JCRMI – JavaCard Remote Method
o JCRMI – JavaCard Remote Method Invocation Protocol Invocation Protocol
o Crypto – Cryptography Package
o PKI – Public Key Infrastructure This package enables the communication between MIDP
devices and a smart card using the JCRMI protocol. It is an
4.2.1 APDU – Application Protocol Data Unit alternative method for the communication with smartcard
applications with support to distributed objects framework. It
This standard enables MIDP applications to communicate with a contains a subset of J2SE RMI. It comprises three
smart card using a protocol based on Application Protocol Data classes/Interfaces as shown in the figure below.
Units (APDUs). This protocol is defined by ISO 7816-4. An
APDU is a short message represented by bytes. SATSA-APDU
enables your application to exchange APDU messages with a
card application. SATSA APDU has been implemented as an
extension of the Generic Connection Framework.

An example of opening a APDU Connection between a MIDlet

and a JavaCard:
String purseURL = "apdu:0;target=a0.00.00.00.62.03.01.0c.02.01";
APDUConnection purseConnection;
purseConnection = (APDUConnection)Connector.open(purseURL);
The locator string begins with “apdu” and specifies the
slot number and the card application identifier. By retrieving the
value of the microedition.smartcardslots system property, the
list of available slots in the card can be obtained. For the
exchange of messages or APDUs, an array of bytes can be sent
and also be received for response. This response is synchronous,
meaning that the application will only continue after it receives
the data back from the other end.
Figure 22: JCRMI objects and interface
Their responsibilities are:
o Remote interface: includes the methods to be called on the
remote object.
o Stub class: implements the remote interface.
o Client code: opens a connection and calls methods on the
remote object.
The connection is similar when using the APDU API,
except that it uses the JavaCardRMIConnection interface for
RMI to communicate. It receives an object which allows
communication between the two ends.

The source code below shows the exchange of APDU messages
between a MIDlet and a JavaCard:
byte[] apdu = {
(byte)0x00, (byte)0x20, (byte)0x00, (byte)0x82, (byte)0x04,
(byte)0x01, (byte)0x02, (byte)0x03, (byte)0x04, (byte)0x00
};
byte[] response = purseConnection.exchangeAPDU(apdu);
4.2.3 Crypto – Cryptography Package
This is a generic cryptography API that provides features such
as message digests, digital signatures, and ciphers for smart
cards. It is a subset of the J2SE JCE (see section 3.1). It
encapsulates cryptographic ciphers in the javax.crypto.Cipher
class. The example below demonstrates the usage of the class
Cypher.

At the example below, this code can be used for

ciphering data with DES algorithm. The interface is pretty
similar to what has been defined in JCE. In fact this is a subset
of it.

byte[] keyBits = {
(byte) 0x2b, (byte) 0x7e, (byte) 0x15, (byte) 0x16,
(byte) 0x28, (byte) 0xae, (byte) 0xd2, (byte) 0xa6
};
byte[] plaintext = {
(byte)0x01, (byte)0x23, (byte)0x45,
(byte)0x67, (byte)0x89, (byte)0xab, (byte)0xcd, (byte)0xef
};
byte[] ciphertext = new byte[8];
SecretKeySpec key = new SecretKeySpec(keyBits, 0, keyBits.length,
"DES");
Cipher cipher = Cipher.getInstance("DES/ECB/NoPadding");
cipher.init(Cipher.ENCRYPT_MODE, key);
int count = cipher.doFinal(plaintext, 0, plaintext.length,
ciphertext, 0);
At the algorithm above, the secret key is created along
with the cipher object. The initialization of the cipher is done by
passing the secret key as parameter, returning by reference the
ciphered data in the doFinal() method. In the example below the
cipher object is used for encrypting data using the public key of
an RSA key pair. It demonstrates the use of the KeyFactory
class to extract a public key from an encoded representation.
byte[] publicKeyBits;
// Assign publicKeyBits here.
byte[] plaintext = "This is just an example".getBytes();
byte[] ciphertext = new byte[128];
X509EncodedKeySpec keySpec = new X509EncodedKeySpec(publicKeyBits);
KeyFactory kf = KeyFactory.getInstance("RSA");
PublicKey publicKey = keyFactory.generatePublic(keySpec);
Cipher cipher = Cipher.getInstance("RSA");
cipher.init(Cipher.ENCRYPT_MODE, publicKey);
int count = cipher.doFinal(plaintext, 0, plaintext.length,
ciphertext, 0);
4.2.4 PKI – Public Key Infrastructure
This API allows applications to use a smartcard for digital data
signatures and certificate management for end users. PKI
associates cryptographic keys with people, businesses, or other
objects. It is based on standard cryptographic signatures and
certificates. It provides:
o Key and certificate management
o Digital Signature of data
o Authentication
4.2.5 JavaCard Security Features
Some of JavaCard security features are:
o Card owner verification: this is done via CHV PIN
(Personal Identification Number) encrypted. Before access
to the data and functions are allowed, the cardholder has to
prove him to be genuine. Cardholder verification is
performed using a CHV PIN (Personal Identification
Number) which is known only to the owner of the card.
Access is granted only if the comparison is positive. This
PIN stored is encrypted in some cards to provide greater
security.
o Authentication: at the beginning of any session there is
authentication. This is achieved using a challenge and
response procedure employing cryptographic algorithms
such as Data Encryption Standard (DES) or public key
cryptography. To authenticate the card, the system
challenges the card by sending a random number. The card
uses this and its own secret key as input to its cryptographic
algorithm. The output of the calculation is transmitted to the
system. The system compares the value received with the
one calculated itself. If the two match, the card is
considered to be genuine. Similar procedure is used for
authentication of the external world to the card.
o Data Integrity: many situations demand data integrity, for
example, in electronic monetary transaction or email
communications, it is important to ensure the message
content remains unaltered during and after each
transmission. One method of achieving data integrity during
transmission is by using the message authentication code
(MAC). MAC is the cryptographic checksum, calculated
based on the secret key, the data and a random number
using Data Encryption Standard (DES). It is appended to
the end of the original data and is transmitted to the
recipient, together with the random number. The recipient
verifies the received message by generating the MAC using
the same secret key, the received random number and the
received data by the same computation. If the MAC
matches with the one received, it is proven that the data was
not modified during the transmission.
o Data Confidentiality: when data is transmitted through an
insecure network, it is important that confidential data like
secret cryptographic key is not disclosed to unauthorized
individuals. To ensure data confidentiality, the card’s
microprocessor is capable of encrypting the data internally
before it is transmitted. In general, the two types of
cryptographic algorithms are supported (secret key and
public key cryptography). A Java smart card provides a
secure place to create and store these cryptographic keys.
Secret key cryptography is simple and fast but the main
drawback of the system is that the two parties must ensure
the secret key is exchanged securely. Public key
cryptography, although more complicated, can avoid this
problem.
o Digital Signature: digital signatures address the integrity,
authentication and non-repudiation requirements. A digital
signature is the encrypted information generated using the
private key of the sender. The receiver can perform the
reverse process using the associated public key and confirm
the identity of the sender. It is analogous to a hand written
signature. Today, a Java smart card used for security
purposes has a crypto-coprocessor capable of public key
cryptography calculation using up to 1024 bit keys. When
this is used with the on-board random generator, the card
can perform full public-key generation, digital signatures,
and authentication internally. This capability guarantees
that the secret key will never be known outside the smart
card and contributes to the overall security of the system.
There are, unfortunately, several ways of breaking the
security in smart card. For example, if the device is
tampered.

Figure 23 : SATSA Standards on the move.
In summary, APDU and JCRMI standards are used for
general message exchanges between the mobile device (a cell
phone) and a JavaCard. The difference is how these messages
are being transferred, whether working with arrays of bits or
invoking remote objects. The PKI package offers authentication
by applying a “challenge-response” protocol to guarantee the
identity of, in this case, a JavaCard owner. It is up to the mobile
device to compute message digests, verify digital signatures
from entities and encrypt/decrypt data. This last responsibility is
quite resource demanding for the mobile, therefore
demonstrating the importance of the development of efficient
security APIs for J2ME MIDP2/CLDC 1.1 devices.
4.3 JSR 219 – Foundation Profile 1.1
J2ME devices in the CDC range will soon receive a new profile
that is being defined by the JCP. It provides updates based on
J2SE 1.4 to the existing CDC (JSR 36) core. From all the
updates being planned, some security packages from Java 1.4
will be added into the CDC APIs. J2ME Foundation Profile 1.0
(JSR 46) does not currently include certain J2SE, v1.4 features
that are required by device manufacturers and application
developers. It proposes the addition of several security
packages, including partial support to JCE, JAAS and JSSE, as
it can be shown in the figure below.
Figure 24: Comparison between J2SE and J2ME
configurations in API coverage.
5 Conclusion
It can be said that the Java Platform contains a quite robust
security model. It is customizable, extendable, well maintenance
supported and it supports a great deal of algorithms. From the
starting point of preparing the Java code to compile up to the
usage of core security APIs, Java provides many features that
guarantee a secure environment for programs, users and
developers. There are off course security breaches in any
platform. The importance is for it to have an effective support
team ready to fix any breaches that anyone may find.
Besides all extensions and features presented in this
document, there are also other security packages specific to their
application domains. For example for Web Services, the Web
Service Message Security APIs (JSR 183) proposes to enable
applications to construct and exchange secure SOAP messages.
Also for RMI, the RMI Security API for J2SE defines a high
level API for network security in RMI, covering basic security
mechanisms such as authentication, confidentiality and integrity.
The XML Digital signature APIs (JSR 105) also define and
incorporate a standard set of high-level implementation-
independent APIs for XML digital signatures services. Digital
encryption is also included in JSR 106 which aims to define a
standard set of APIs for XML digital encryption services.
Focusing at the J2ME platform, there is a great demand
for this platform to deliver security solutions that are fast and
efficient, taking into account all limitations that J2ME devices
impose. The evolution of these devices may be a solution
however, as they gain more processing power, more memory
and better energy consumption. There are already J2ME devices
that are crossing the border from CLDC to CDC, thus enabling
applications to have access to security features already available
to the J2SE Platform, for example in JSR 219 [8]. It is also
important to note the need to define and follow standard security
APIs in the mobile world in order for Java applications
demanding security to be fully runnable across any device on
that same platform, thus maintaining on of Java’s greatest
advantages.
Figure 25: The overall picture (J2SE, J2EE)
All security extensions are cooperating mutually in
providing a safe environment for each platform. Some of these
features apply only to specific platforms, while others are
generic and can be used by any of the Java Platforms. Even in
the J2ME, subsets of the extensions shown above have been
made available for developers and their applications.

Figure 26: Security Extensions for J2EE
As it can be seen in the above picture, many of the
security APIs and extensions are important to the J2EE Platform
services. It can be said that J2EE takes full advantage of these
APIs to guarantee security in its operations.
Figure 27: Security in the JRE
For the Java Runtime Environment, some services
utilize the security APIs available in the platform to enforce its
security model and guarantee a safe environment for the Java
code.
As new application domains come to surface in the
Java Platform, new security requirements will eventually be
added into the APIs in order to fulfill their demands. Existing
domains may also request more security features, as trustability
becomes crucial for certain types of applications.
Glossary
• Authentication: the process of confirming the identity of a
party with whom one is communicating.
• Certificate: a digitally signed statement vouching for the
identity and public key of an entity (person, company, etc.).
Certificates can either be self-signed or issued by a
Certification Authority (CA). Certification Authorities are
entities that are trusted to issue valid certificates for other
entities.
• Digital Signature: the digital equivalent of a handwritten
signature. It is used to ensure that data transmitted over a
network was sent by whoever claims to have sent it and that
the data has not been modified in transit. For example, an
RSA-based digital signature is calculated by first computing
a cryptographic hash of the data and then encrypting the
hash with the sender'
s private key.
• Encryption and Decryption: the process of taking data
(called cleartext) and a short string (a key), and producing
data (ciphertext) meaningless to a third-party who does not
know the key. Decryption is the inverse process: that of
taking ciphertext and a short key string, and producing
cleartext.
• Password-Based Encryption: Password-Based Encryption
(PBE) derives an encryption key from a password. In order
to make the task of getting from password to key very time-
consuming for an attacker, most PBE implementations will
mix in a random number, known as a salt, to create the key.
• Cipher: Encryption and decryption are done using a cipher.
A cipher is an object capable of carrying out encryption and
decryption according to an encryption scheme (algorithm).
It takes regular data, the plaintext, and converts it into an
unreadable form, called ciphertext. This process is
encryption. The cipher can also decrypt ciphertext to restore
the original plaintext, regarded as decryption.
• Key Agreement: Key agreement is a protocol by which 2
or more parties can establish the same cryptographic keys,
without having to exchange any secret information.
• Message Authentication Code: A Message Authentication
Code (MAC) provides a way to check the integrity of
information transmitted over or stored in an unreliable
medium, based on a secret key. Typically, message
authentication codes are used between two parties that share
a secret key in order to validate information transmitted
between these parties. A MAC mechanism that is based on
cryptographic hash functions is referred to as HMAC.
HMAC can be used with any cryptographic hash function,
e.g., MD5 or SHA-1, in combination with a secret shared
key. HMAC is specified in RFC 2104.
• Message Digest: The representation of text in the form of a
single string of digits, created using a formula called a one-
way hash function. Encrypting a message digest with a
private key creates a digital signature, which is an electronic
means of authentication.
• One-Way Hash Function: An algorithm that turns
messages or text into a fixed string of digits, usually for
security or data management purposes. The "one way"
means that it's nearly impossible to derive the original text
from the string. A one-way hash function is used to create
digital signatures, which in turn identify and authenticate
the sender and message of a digitally distributed message.
• Public Key Encryption: A cryptographic system that uses
two keys -- a public key known to everyone and a private or
secret key known only to the recipient of the message.
When John wants to send a secure message to Jane, he uses
Jane's public key to encrypt the message. Jane then uses her
private key to decrypt it. An important element to the
public key system is that the public and private keys are
related in such a way that only the public key can be used to
encrypt messages and only the corresponding private key
can be used to decrypt them. Moreover, it is virtually
impossible to deduce the private key if you know the public
key. Public-key systems, such as Pretty Good Privacy
(PGP), are becoming popular for transmitting information
 via the Internet. They are extremely secure and relatively
simple to use. The only difficulty with public-key systems
is that you need to know the recipient' s public key to
encrypt a message for him or her. What' s needed, therefore,
is a global registry of public keys, which is one of the
promises of the new LDAP technology. Public key
cryptography was invented in 1976 by Whitfield Diffie and
Martin Hellman. For this reason, it is sometime called
Diffie-Hellman encryption. It is also called asymmetric
encryption because it uses two keys instead of one key
(symmetric encryption).
• Private Key Encryption: A type of encryption where the
same key is used to encrypt and decrypt the message. This
differs from asymmetric (or public-key) encryption, which
uses one key to encrypt a message and another to decrypt
the message.
• LDAP: Short for Lightweight Directory Access Protocol, a
set of protocols for accessing information directories.
LDAP is based on the standards contained within the X.500
standard, but is significantly simpler. And unlike X.500,
LDAP supports TCP/IP, which is necessary for any type of
Internet access. Because it' s a simpler version of X.500,
LDAP is sometimes called X.500-lite. Although not yet
widely implemented, LDAP should eventually make it
possible for almost any application running on virtually any
computer platform to obtain directory information, such as
email addresses and public keys. Because LDAP is an open
protocol, applications need not worry about the type of
server hosting the directory.
• X.509: A widely used standard for defining digital
certificates. X.509 is actually an ITU Recommendation,
which means that it has not yet been officially defined or
approved for standardized usage. As a result, companies
have implemented the standard in different ways. For
example, both Netscape and Microsoft use X.509
certificates to implement SSL in their Web servers and
browsers. But an X.509 Certificate generated by Netscape
may not be readable by Microsoft products, and vice versa.
• Kerberos: An authentication system developed at the
Massachusetts Institute of Technology (MIT). Kerberos is
designed to enable two parties to exchange private
information across an otherwise open network. It works by
assigning a unique key, called a ticket, to each user that logs
on to the network. The ticket is then embedded in messages
to identify the sender of the message.
• RFC: The name of the result and the process for creating a
standard on the Internet. New standards are proposed and
published on line, as a Request For Comments. The Internet
Engineering Task Force is a consensus-building body that
facilitates discussion, and eventually a new standard is
established, but the reference number/name for the standard
retains the acronym RFC, e.g. the official standard for e-
mail is RFC 822.
• Challenge-response Protocol: A challenge-response
protocol is a common authentication technique whereby an
individual is prompted (the challenge) to provide some
private information (the response). Most security systems
that rely on smart cards are based on challenge-response. A
user is given a code (the challenge) which he or she enters
into the smart card. The smart card then displays a new
code (the response) that the user can present to log in.
• Public Key Certificate: A public key certificate can be
thought of as the digital equivalent of a passport. It is issued
by a trusted organization and provides identification for the
bearer. A trusted organization that issues public key
certificates is known as a certificate authority (CA). The CA
can be likened to a notary public. To obtain a certificate
from a CA, one must provide proof of identity. Once the
CA is confident that the applicant represents the
organization it says it represents, the CA signs the
certificate attesting to the validity of the information
contained within the certificate.
• Tampering: a breach of communication security in which
information in transit is changed or replaced and then sent
on to the recipient.
References
[1] Java Security, Second Edition, Scott Oaks, May 2001
[2] Java Cryptography Extension Reference Guide, Sun Microsystems
http://java.sun.com/j2se/1.4.2/docs/guide/security/jce/JCERefGuide.h
tml
[3] Java Secure Sockets Extension Reference Guide, Sun Microsystems
http://java.sun.com/j2se/1.4.2/docs/guide/security/jsse/JSSERefGuide
.html
[4] Java Authentication and Authorization Service Reference Guide, Sun
Microsystems
http://java.sun.com/j2se/1.4.2/docs/guide/security/jaas/JAASRefGuid
e.html
[5] SATSA Developer’s Guide and Reference Implementation 1.0, Sun
Microsystems
http://java.sun.com/j2me/docs/satsa-dg/
[6] Secure Your Sockets with JSSE, Jamie Jaworski, March 2001,
OnJava
http://www.onjava.com/lpt/a/811
[7] MIDP Application Security 1: Design Concerns and Cryptography,
Jonathan Knudsen
September 2002,
http://developers.sun.com/techtopics/mobility/midp/articles/security1
[8] JSR 219 – Foundation Profile 1.1
http://www.jcp.org/en/jsr/detail?id=219
[9] JSR 177 – Security and Trust Services API for J2ME
http://www.jcp.org/en/jsr/detail?id=177
[10] JSR 28 – Java SASL Specification
http://www.jcp.org/en/jsr/detail?id=28
[11] JSR 72 – Generic Security Services API
http://www.jcp.org/en/jsr/detail?id=72
[12] The Java Virtual Machine Specification, Second Edition
http://java.sun.com/docs/books/vmspec/2nd-
edition/html/VMSpecTOC.doc.html