The Java Community Process(SM) Program - JSRs: Java Specification Requests

Use of JCP site is subject to the JCP Terms of Use and the Oracle Privacy Policy

JSR

Community

Expert Group

Summary | Proposal | Detail (Summary & Proposal) | Nominations

JSRs: Java Specification Requests

JSR 321: Trusted Computing API for Java^TM

This JSR has been Withdrawn
Reason: null

This JSR was completed on 5 December 2011 under JCP version 2.7.

Original Java Specification Request (JSR)

Identification | Request | Contributions | Additional Information

Section 1. Identification

Submitting Member: IAIK Graz University of Technology

Name of Contact Person: Peter Lipp

E-Mail Address: Peter.Lipp@iaik.tugraz.at

Telephone Number: +43 316 873 5513

Fax Number: +43 316 873 5595

Specification Lead: Ronald Toegl

E-Mail Address: Ronald.Toegl@iaik.tugraz.at

Telephone Number: +43 316 873 5502

Fax Number: +43 316 873 5520

Initial Expert Group Membership:

IAIK Graz University of Technology

Supporting this JSR:

Hewlett-Packard
Infineon Technologies AG

Section 2: Request

2.1 Please describe the proposed Specification:

The Trusted Computing Group developed a standard API for accessing Trusted Computing functionality from applications, the Trusted Software Stack (TSS). The TSS is targeted at applications written in the C-language. To make use of TC-functionality from Java, two groups have developed prototype solutions:

MIT CSAIL has developed TMP/J, an object-oriented API using Java for low-level access to the TPM.
IAIK, Graz University of Technology has developed the jTSS-Wrapper, a Wrapper making standard TSS implementations accessible from Java, and also jTSS, a native implementation of the TCG Software Stack.

The TSS-based activities followed the C-Specifications of the TCG, the resulting API obviously is not ideal for the Java world. The proposed JSR is to develop a Trusted Software Stack for Java providing comparable functionality the TSS offers to the C world.

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

Java SE, Java EE

Since the TCG has now published a mobile specification, targeting the personal and embedded platforms will be a logical successor and kept in mind during the JSR work.

2.3 The Executive Committees would like to ensure JSR submitters think about how their proposed technology relates to all of the Java platform editions. Please provide details here for which platform editions are being targeted by this JSR, and how this JSR has considered the relationship with the other platform editions.

Since TPMs are currently shipped with notebooks, desktops and servers, this group is the main target. Since the standard TPM spec and the mobile spec have differences, the APIs will need to be different as well.

2.4 Should this JSR be voted on by both Executive Committees?

Our primary aim is the Java SE, so it is probably most appropriate for the Standard/Enterprise committee to vote on this JSR.

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

The number of machines providing TPMs is continuously increasing; some vendors ship most of their desktops and notebooks with TPMs. Software developers who want to develop applications or frameworks for making use of TPMs need a way to access the functions a TPM offers.

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

There are no specifications for accessing TPM-functions.

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

The specification is based on the functionality of the TPM Software Stack Specification from the Trusted Computing Group.

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

javax.trustedComputing

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

A TPM is obviously required, but could be replaced by an emulator.

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

2.11 Are there any internationalization or localization issues?

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

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

Expert group formed as soon as JSR approved
First draft T+4 months
Early draft review T+6 months
Public review T+8 months
Proposed final draft T+12 months
Final release T+18 months

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

A mailing list is intended to be the primary communication mechanism among members of the expert group. Personal meetings may be helpful.

2.15 It is important to the success of the community and each JSR that the work of the Expert Group be handled in a manner which provides the community and the public with insight into the work the Expert Group is doing, and the decisions that the Expert Group has made. The Executive Committees would like to ensure Spec Leads understand the value of this transparency and ask that each JSR have an operating plan in place for how their JSR will address the involvement of the community and the public. Please provide your plan here, and refer to the Spec Lead Guide for a more detailed description and a set of example questions you may wish to answer in your plan.

A mailing list, or a bulletin board like PHPBB, will be used for Expert Group discussions and will be readable by anyone who expresses an interest.
The specification lead will maintain an observer alias for JCP members outside of the Expert Group. The specification lead will publish periodic milestone drafts and status to this list. The Expert Group may also use the list to request feedback on key issues.
The specification lead will, on a quarterly basis, provide a brief JSR status to the JCP PMO, for publication to the Java community. This will include the current schedule for the JSR and notes on any major events that have occurred in the previous quarter.

2.16 Please describe how the RI and TCK will de delivered, i.e. as part of a profile or platform edition, or stand-alone, or both. Include version information for the profile or platform in your answer.

The RI and TCK will be delivered stand-alone.

2.17 Please state the rationale if previous versions are available stand-alone and you are now proposing in 2.13 to only deliver RI and TCK as part of a profile or platform edition (See sections 1.1.5 and 1.1.6 of the JCP 2 document).

N/A

2.18 Please provide a description of the business terms for the Specification, RI and TCK that will apply when this JSR is final.

RI and TCK will be available under GPL v2.

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.

TPM Software Stack Specifications ( https://www.trustedcomputinggroup.org/specs/TSS/)
Trusted Computing for the Java Platform (trustedjava.sourceforge.net)
TPM/J Java-based API for the Trusted Platform Module (TPM) ( http://projects.csail.mit.edu/tc/tpmj/)

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

The TSS-specs are the primary input since they specify the functionality and the resp. C-API. The work done at MIT or IAIK will influence the design by learning from the experiences and are not considered to be even a pre-early version of this JSR.

Section 4: Additional Information (Optional)

4.1 This section contains any additional information that the submitting Member wishes to include in the JSR.

We had contacts to folks at MIT for participating, they still have internal problems to solve concerning the membership and may join the expert group later.