The Java Community Process(SM) Program - JSRs: Java Specification Requests - detail JSR# 177

NOTICE: Please be aware the CDC 1.0 specification initially related to this JSR has been replace (superseded) with the newer CDC 1.1 specification. CDC 1.0 will no longer be supported after 18-Aug-2009. This JSR and other optional technologies based on the CDC 1.0 standards are fully compatible with the CDC 1.1 standards. All development and certification efforts should be updated to use the current, supported technology.

---

Note that this JSR was completed under JCP 2.1.

Updates to the Original JSR

The following information was updated from the original proposal.

2007年08月20日: Roman Zelov was added as a Maintenance Lead.

Name of Maintenance Lead: Roman Zelov

E-Mail Address: roman.zelov@sun.com

Telephone Number: +8 812 334 61 46

Fax Number: +8 812 334 30 38

---

Original Java Specification Request (JSR)

Identification | Request | Contributions

Section 1. Identification

Submitting Member: Sun Microsystems, Inc.

Name of Contact Person: Zhiqun Chen

E-Mail Address: zhiqun.chen@sun.com

Telephone Number: +1 408 276 7389

Fax Number: +1 408 276 7608

Specification Lead: Zhiqun Chen

E-Mail Address: zhiqun.chen@sun.com

Telephone Number: +1 408 276 7389

Fax Number: +1 408 276 7608

Initial Expert Group Membership:

Cingular
DoCoMo
France Telecom
Gemplus
Hutchison 3G
JPhone
KDDI
Oberthur
Orange
Sprint
Telef?nica M?viles Espa?a
Sun Microsystems Inc.
Vodafone

Supporting this JSR:

Section 2: Request

2.1 Please describe the proposed Specification:

The purpose of this JSR is to define a collection of APIs that provide security services to J2ME enabled devices. These APIs are a necessary step for a device to become trusted, in other words provide security mechanisms to support a wide variety of application based services, such as access to corporate network, mobile commerce, and digital rights management.

Many of these services rely on the interaction with a Security Element in the device for secure storage and execution as described below:

• Secure storage to protect sensitive data, such as the user?s private keys, public key (root) certificates, service credentials, personal information, etc.
• Secure execution, such as cryptographic operations to support payment protocols, data integrity, and data confidentiality.
• Custom and enabling security features that J2ME applications can rely on to handle many valued-added services, such as user identification and authentication, banking, payment, ticketing, loyalty applications, digital media play, etc.

A Security Element can be implemented in a variety of ways. Smart cards are most commonly used to implement a security element. They are widely deployed in wireless phones, such as SIM cards in GSM phones, UICC cards in 3G phones, and WIM applications in a SIM or UICC card in WAP-enabled phones. For instance in GSM networks, the network operator puts the network authentication data on a smart card, as well the subscriber's personal information such as the address book. This card, when inserted into a mobile handset, enables the handset to operate on the operators network for the benefits of the subscriber.

As the primary use for cards in these devices is to provide security (storage and processing) and other custom services, this specification provides an access model that enables applications running on J2ME enabled devices to communicate with a smart card inserted in the device. This access model intends to provide a flexible mechanism to allow service and equipment providers to define secure operations.

2.2 What is the target Java platform? (i.e., desktop, server, personal, embedded, card, etc.)

This API will focus on supporting consumer devices (CLDC [Connected Limited Device Configuration] and CDC [Connected Device Configuration]) but should not be designed in such a way as to preclude its implementation on larger platforms such as J2SE.

The security and trust services API is proposed to be an optional package to be used together with several J2ME profiles.

2.3 What need of the Java community will be addressed by the proposed specification?

This API provides security services to Java applications running on J2ME enabled devices and to enable new value-added functions to be deployed on these devices.

Also see 2.1.

2.4 Why isn't this need met by existing specifications?

The current J2ME platform does not have APIs that provide security services to applications and does not include any way to access security elements from the underlying platform.

2.5 Please give a short description of the underlying technology or technologies:

In order to perform trusted operations, J2ME applications need to rely on the security services provided in a Security Element to ensure that, for example, the cryptographic keys are stored securely and that the cryptographic computations are performed securely. The proposed API establishes a Java programming model for accessing the features of a Security Element.

2.6 Is there a proposed package name for the API Specification? (i.e., javapi.something, org.something, etc.)

javax.microedition.se.*
javax.microedition.crypto

2.7 Does the proposed specification have any dependencies on specific operating systems, CPUs, or I/O devices that you know of?

No. It depends largely on other standards and on their implementation on the various devices.

2.8 Are there any security issues that cannot be addressed by the current security model?

This JSR aims at extending the current security model to support client side, custom security solutions through the integration of a security element.

2.9 Are there any internationalization or localization issues?

No.

2.10 Are there any existing specifications that might be rendered obsolete, deprecated, or in need of revision as a result of this work?

No

2.11 Please describe the anticipated schedule for the development of this specification.

Q1 - Q2, 2003

2.12 Please describe the anticipated working model for the Expert Group working on developing this specification.

The expert group will follow the model of the JSR118 expert group and others, using in the main email communications with occasional telephone and face to face meetings.

Section 3: Contributions

3.1 Please list any existing documents, specifications, or implementations that describe the technology. Please include links to the documents if they are publicly available.

General contributions:

• Connected, Limited Device Configuration (CLDC) Version 1.0, May 2000
  • http://jcp.org/aboutJava/communityprocess/final/jsr030/index.html (Version 1.0)
  • http://java.sun.com/products/cldc
• Connected Device Configuration (CDC) Version 1.0, December 2000
  • http://jcp.org/aboutJava/communityprocess/final/jsr036/index.html
  • http://java.sun.com/products/cdc
• Mobile Information Device Profile (MIDP)
  • http://jcp.org/aboutJava/communityprocess/final/jsr037/index.html (Version 1.0)
  • http://jcp.org/jsr/detail/118.jsp (MIDP 2.0)
  • http://java.sun.com/products/midp
• ISO 7816 specification
• ETSI SCP specification ETSI TS 102 220, TS 102 221, TS 102 222
• GSM/3GPP specification for SIM card
• 3GPP specification for the USIM
• 3GPP2 specification for the UIM
• Wireless Identity Module Specification (http://www.wapforum.org)

3.2 Explanation of how these items might be used as a starting point for the work.

The APIs to be defined in the specification are intended to work with CLDC- and CDC-based profiles, in particular MIDP, and will be defined to take into consideration industry standards of related technologies.