Summary | Proposal | Detail (Summary & Proposal) | Nominations
JSRs: Java Specification Requests
JSR 321: Trusted Computing API for JavaTM
JCP version in use: 2.11
Java Specification Participation Agreement version in use: 2.0
Develop a Trusted Computing API for JavaTM providing selected functionality the TCG Software Stack offers to the C world, while following the conventions of modern Java APIs.
This JSR has been Withdrawn
Original Java Specification Request (JSR)
Section 1. Identification
Submitting Member: IAIK Graz University of Technology
Name of Contact Person: Peter Lipp
E-Mail Address: Peter.Lipp
Telephone Number: +43 316 873 5513
Fax Number: +43 316 873 5595
Specification Lead: Ronald Toegl
E-Mail Address: Ronald.Toegl
Telephone Number: +43 316 873 5502
Fax Number: +43 316 873 5520
Initial Expert Group Membership:
IAIK Graz University of Technology
Supporting this JSR:
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:
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.)
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
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.
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).
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/)
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.