Trusted Computing for the Java(tm) Platform  

Martin Pirker <>

This README is unmaintained as development of TCcert was halted some time ago. Unfortunately, there is/was not enough interest in Trusted Computing enhanced certificates and associated services. However, this may change again sometime in the future.

1. Introduction

Trusted Computing, as specified by the Trusted Computing Group (TCG), comprises multiple layers of hard- and software. While the hardware primarily consists of the Trusted Platform Module (TPM), there are multiple support software components required.

There are potential security benefits in connecting many Trusted Computing enabled platforms, however, there is a need to standardize security credentials to enable easy automated processing and the building of a Trusted Computing aware public key infrastructure (PKI).

TCcert is a software tool which enables one to create special types of certificates, as specified by the Trusted Computing Group.

IAIK TCcert is developed and maintained at the Institute for Applied Information Processing and Communication (Institut für Angewandte Informationsverarbeitung und Kommunikation (IAIK)), at Graz University of Technology (TU Graz).

1.1. OpenTC Project

Development of IAIK TCcert is supported by the European Commission as part of the OpenTC project (Ref. Nr. 027635).

The Open Trusted Computing (OpenTC) consortium is an R&D project focusing on the development of trusted and secure computing systems based on open source software. The project targets traditional computer platforms as well as embedded systems such as mobile phones.

The goal of OpenTC is to reduce system-related threats, errors and malfunctions. The lack of platform security in today’s computers has given rise to waves of successful attacks, resulting in severe damages to enterprises and potential failure of critical infrastructures.

The OpenTC consortium will define and implement an open Trusted Computing framework. The architecture is based on security mechanisms provided by low level operating system layers with isolation properties and interfaces to Trusted Computing hardware. These layers make it possible to leverage enhanced trust and security properties of the platform for standard operating systems, middleware and applications.

For more information about the OpenTC project please refer to the OpenTC homepage.

1.2. Word of Caution

TCcert is experimental software. The use of TCcert in a real production environment is discouraged. No guarantees for data produced by TCcert can be made. Use the software at your own risk!

1.3. License

Copyright © IAIK, Graz University of Technology, 2010. All rights reserved.

IAIK TCcert is released under a dual licensing model:

  • For Open Source development, IAIK TCcert is licensed under the terms of the GNU GPL version 2. The full text of the GNU GPL v2 is shipped with the product or can be found online at (GPL).

  • In all other cases, the "Stiftung SIC Java (tm) Crypto-Software Development Kit Licence Agreement" applies. The full license text can be found online at Stiftung SIC. For pricing and further information please contact

2. Technical Documentation

This section deals with the technical aspects of TCcert, which comprises development status, requirements and usage documentation.

It is assumed you already have some knowledge about certificates, their encodings, keys, security concepts and how they relate to public key infrastructures. If you want to learn more about this topic, this readme will not help you. Thanks for your understanding.

2.1. Current Status

TCcert implements the "TCG Infrastructure Credential Profiles" document, which at time of this writing is at revision 0.981.

The following credentials are currently supported:

  • TPM Endorsement Key (EK) credential

  • Platform Endorsement (PE) credential

  • Attestation Identity Key (AIK) credential

Further, the TCG specified the Subject Key Attestation Evidence (SKAE) extension for certificates in Infrastructure Subject Key Attestation Evidence Extension.
This extension defines the cryptographic binding of TCG-oriented security assertions within common X.509 certificates. TCcert allows to build the SKAE extension, both in plain and encrypted format.

There are additional credentials specified in the TCPA v1.1 Main Specification:

  • Conformance Credential (Section 4.32.3)

  • Validation Credential (Section 4.32.4)

These two types of certificates are currently not supported by this tool.

The current release is not feature complete and in some areas not fully specification compliant. This is an "early access" version, released due to community interest, to stimulate development in related areas and offer a tool to toy around with.

To support experimentation, additional functionality is offered to build a minimal certificate hierarchy with a self signed CA root certificate and one level of intermediate CAs, from which specific credentials can be derived. Note that this does not reflect a real-life setup, as different certificates are usually issued by differing vendors.

The development of TCcert is currently done under Linux operating systems. By the portable nature of Java it is expected to work equally well on other operating systems, however, this is not being tested.

2.2. Requirements

TCcert itself is available for download from Trusted Java at Sourceforge.
In addition you’ll also need some support software packages:

2.2.1. Java SDK 1.2

TCcert is expected to run on Java 1.2 or newer. Development was done with Sun JDK, compatibility with older Java versions or other JDK vendors is unknown and untested.

Note: For the cryptographic operations with long RSA keys "unlimited strength encryption" has to be enabled in newer JRE. For more information refer to JCE policy downloads.
(If you see an error message like Illegal key size or default parameters this is an indication that unlimited strength encryption is not enabled on your system.)

2.2.2. IAIK-JCE 3.14

IAIK-JCE is a set of APIs and implementations of cryptographic functionality, including hash functions, encryption functions, crypto keys and certificate management functions. It supplements features of the default JCE with required functionality for TCcert.
This package is available as a free evaluation download from SIC website.

2.2.3. IAIK-CMS 3.2

IAIK-CMS is a collection of support functions for communication and message security. The SKAE extension implementation by TCcert requires the additional functionality provided by this library.
This package is available as a free evaluation download from SIC website.

2.3. Usage

2.3.1. Calling

TCcert is a commandline based tool. For ease of usage a example shell script is provided to illustrate how to call TCcert. The script itself consists only of a few lines and should be self explanatory.

TCcert takes 2 parameters:

The first parameter specifies which function to execute. This can be one of ca, ek, pe and aik. The ca option creates a certificate hierarchie with a self-signed root CA certificate at the top and derives 3 further intermediate CA certificates which then can be used as anchors for the different certificate types. The ek, pe and aik parameters create a certificate of the specific type.

The second parameter specifies an input file to read all necessary parameters from. The format of the file is a basic ASCII text file, similar in formatting to a Java properties file.

2.3.2. Examples

In order to further illustrate the possible commands and parameters an example set of input files is included in the TCcert distribution in the /examples subdirectory. Each command has a corresponding example file, e.g. for the ek command an ek.ini file is included.

Following assumes all files are copied into the same directory.

tccert ca ca.ini
This should result in output similar to:

generating CA certificates...

If you take a closer look at the ca.ini file you probably already understand what files got generated:
\*.cert are certificate files in ASN.1 DER format.
\*.pkey are the corresponding private key files.

ca.\* are the files for the self signed root certificate.
caek.\* are for the EK certification authority, derived from the root CA.
Similar for caek.\* and caaik.\*

If you want to take a closer look at a certificate, one can use the dumpasn1 utility which is usually in a similar called package available in major Linux distributions (and a GUI version is available for Windows, too).

Try e.g.
dumpasn1 ca.cert
which gives:

0 warnings, 0 errors.
   0 1316: SEQUENCE {
   4 1036:   SEQUENCE {
   8    3:     [0] {
  10    1:       INTEGER 2
         :       }
  13    1:     INTEGER 1
  16   13:     SEQUENCE {
  18    9:       OBJECT IDENTIFIER sha1withRSAEncryption (1 2 840 113549 1 1 5)
  29    0:       NULL

Or, you can employ OpenSSL to take a look at the contents, like
openssl x509 -inform DER -in ca.cert -text

    Version: 3 (0x2)
    Serial Number: 1 (0x1)
    Signature Algorithm: sha1WithRSAEncryption
    Issuer: C=AT, O=Graz University of Technology,
      OU=IAIK trusted computing labs, CN=IAIK OpenTC Test Certification Authority Root

Generated private keys can be inspected with OpenSSL, too:
openssl pkcs8 -inform DER -in ca.pkey

Enter Password:

The default password in the examples is secret



The remaining .ini examples generate specific types of certificates:
tccert ek ek.ini builds an EK type certificate.
tccert pe pe.ini builds an PE type certificate (depends on an EK).
tccert aik aik.ini builds an AIK type certificate (depends on EK+PE).

For details of specific data fields in a certificate please refer to the official TCG specification and read the comments in the examples.

Items marked OPTIONAL in the .ini files can be commented with a hash "#" sign. If you want to comment out a large optional block (e.g. CommonCriteriaMeasures), just comment the first field (e.g. …ccInfo.version) and the rest will be ignored automatically. Items marked DEFAULT=something have their initial value set to this, unless explicitly specified otherwise. Some fields default to autogenerated values if not specified (e.g. serialnumber and privatekeysize).

Please do not publish certificates containing the IAIK url examples!

Note that the current input parser is still a little fragile, typing mistakes or ommisions may sometimes create strange error messages.

2.4. SKAE

TCcert comes with SubjectKeyAttestationEvidence (SKAE) support. This functionality is not available from the command line, only by using TCcert as a library in Java. Note again that SKAE additionally requires the IAIK-CMS libraries (see section Requirements).

The /examples directory includes, which demonstrates how to build a SKAE extension, encrypt it and add it to a certificate. The whole process in reverse is also shown.

3. Development

3.1. Javadoc

TCcert is still under significant development and the APIs are not to be considered stable yet. However, the /doc/apidoc directory includes a set of Javadoc and should enable interested parties the use of TCcert as a library.

As an example of how to build a TCG style certificate with TCcert as a library, the included shows the creation of a minimal EK certificate.

The /examples directory probably already contains more examples than listed here.

4. Troubleshooting

If things don’t work as expected…

  • Did you install the "unlimited strength encryption" policy files?

  • When using IAIK-JCE you should install it as a security provider (as shown in example code). Please read the JCE documentation.

  • But it does not work with Java xy….
    For Java 1.2 and Java 1.3 you need to add iaik_javax_crypto.jar (shipped with IAIK-JCE) to your classpath. Just modify your calling script. Please read the IAIK-JCE documentation for explanation why.
    For Sun Java 1.3 you probably have to install some libraries which are not in the default install of a modern Linux distribution.
    For Sun Java 1.2 you probably have to LD_PRELOAD a patch to make Java run on a modern Linux distribution. Google for it…

5. Open Issues / Future Work

The following list outlines possible further development of TCcert

  • EK: CertificatePolicies: assign policyIdentifier AT LEAST one object identifier

  • EK: SubjectDirectoryAttributes: supportedAlgorithms, OEAP parameters missing

  • PE: CertificatePolicies: assign policyIdentifier AT LEAST one object identifier

  • AIK: be more careful on copying values from EK and PE (but usually Privacy CA should do proper validation first…)

  • EK+PE: …Uri.hashValue does not work

  • implement missing pieces of specification

  • more (and more robust) input checking, more descriptive errors

  • not everything marked optional in the specification is currently optional

  • carefully recheck every item with specification

6. Support

For questions, bug reports, feature requests, patches, criticism or suggestions please use the following mailing list:

7. Revision History

date version comment
2010/10/04 0.2.5 first release with full sources, removed utils classes (now depends on jTSS)
2008/08/04 0.2.2b fix AIK label encoding
2008/07/09 0.2.2a fix null garbage file, add valid.years period
2007/04/23 0.2.2 synchronize with other packages, custom validity periods
2006/10/09 0.2.1a support EK v1.1 as AIK input
2006/08/25 0.2.1 go Java 1.2, unify logging with jTSS, ReadAIKId, some fixes
2006/07/14 0.2 add SKAE support, Javadoc, example code
2006/07/05 0.1 Initial Release