Functionality specification and test plan for all System Interface stacks; TSS implementation done and test report

D03.1 Functionality specification and test plan

for all System Interface stacks; TSS

implementation done and test report

Project number

IST-027635

Project acronym

Open_TC

Project title

Open Trusted Computing

Deliverable type

Report

Deliverable reference number

IST-027635/D03.1/V1.0 Final

Deliverable title

Functionality specification and test plan for
all System Interface stacks; TSS
implementation done and test report

WP contributing to the deliverable

WP3

Due date

Postponed from M18 to M21 as officially
requested

Actual submission date

July 31

, 2007

Responsible Organisation

IFX

Authors

Hans Brandl (IFX)

Abstract

The main specification of the TCG defines a
subsystem with protected storage and trust
capabilities: The Trusted Platform Module
(TPM). For translating the low level
functionality for the TPM security chip to a
high level API, the TCG standardized the so
called TPM Software Stack (TSS). Within this
deliverable a TSS was implemented
according of the TSS1.2 specification of the
TCG. This report describes the method of
implementation and also the test procedures
during the development process as well as a
third party test of the finished product.

Keywords

TPM, TSS, TSPI, TCG, Trust, Security, Tes

Dissemination level

Public

Revision

V1.0 Final

Instrument

Start date of the
project

November 2005

Thematic Priority

IST

Duration

42 months

TPM Software Stack (TSS) Implementation and Test Report

V1.0 Final

Table of Contents

1 Introduction .............................................................................................................. 7

1.1 TPM Management Interface.................................................................................... 8
1.2 Description of work:............................................................................................... 9

1.2.1 Development of a test environment for the TSS stack..................................... 9

1.3 SW-design Fundamentals..................................................................................... 10

1.3.1 References....................................................................................................... 10
1.3.2 Definitions of terms, Acronyms and abbreviations.......................................... 10

2 TSS Architecture...................................................................................................... 12

2.1 TSP and TSPI......................................................................................................... 12
2.2 TCS and TCSI........................................................................................................ 13
2.3 TDDL and TDDLI................................................................................................... 13
2.4 Maintainability, Portability and Usability Requirements....................................... 14

3 TCG-API.................................................................................................................... 15

3.1 Function list for the OpenTC TCG-TSS.................................................................. 15

3.1.1 List of supported TSS Core Service Interface Functions...................................15

3.2 Function list for the OpenTC TCG-TSS.................................................................. 18

3.2.1 Supported function list of TSS Service Provider............................................... 18
3.2.2 List of supported TSS Core Service Interface Functions...................................21

4 TSS module architectural overview .........................................................................24

4.1 TCG-TSP architectural building blocks.................................................................. 24
4.2 TCG-TCS architectural building blocks..................................................................27

5 OpenTC development environment configuration and requirements...................... 30

5.1 Eclipse.................................................................................................................. 30
5.2 Version Control System........................................................................................ 30
5.3 Change- / Error-Managementsystem.................................................................... 30

6  Installation Procedure for the TSS............................................................................ 31
7  Test and Evaluation Support Programs.................................................................... 37
8  Test Procedures for the Development Phase.......................................................... 40

8.1 Glossary of Terms................................................................................................ 40
8.2 Test environment................................................................................................. 40

8.2.1 Security Platform:............................................................................................ 40
8.2.2 External/existing modules for Security Platform:............................................. 40
8.2.3 Test environments for different test methods ................................................ 41
8.2.4 PHP –interface for browser supported testing.................................................. 41
8.2.5 Ruby test environment interpreter for automatic test sequencing.................. 41

8.3 Tracing and Protocol.............................................................................................42
8.4 Test Development................................................................................................ 42

8.4.1 Formal Requirements for the Test Plan........................................................... 42
8.4.2 Formal Requirements for the Test Scripts....................................................... 42

8.5 General Requirements for the Test Scripts...........................................................43

8.5.1 Hints for test script development.................................................................... 43

8.6 Guidelines for Test Development......................................................................... 43
8.7 Helper functions................................................................................................... 44

8.7.1 Defined helper functions:.................................................................................44

8.8 Scripting library.................................................................................................... 44
8.9 Provoking Fault cases........................................................................................... 44
8.1 0Running and Exercising the Tests...................................................................... 45

8.10. 1Test coverage................................................................................................ 45

Open_TC Deliverable 03.1

3/53

TPM Software Stack (TSS) Implementation and Test Report

V1.0 Final

8.1 1Presentation of Test Results............................................................................... 45

9 Test management environment based on the script language RUBY...................... 49

9.1 Motivation and execution..................................................................................... 49
9.2 Requirements for run time environment............................................................. 49

9.2.1 The Ruby Interpreter...................................................................................... 49
9.2.2 Writing test scripts..........................................................................................50

1 0 Testing by third parties inside the OpenTC project............................................... 51
1 1 TPM Controller: TPM Management and Control SW package................................ 54

11. 1 Preconditions..................................................................................................... 54
11. 2 Build & Run....................................................................................................... 54

Open_TC Deliverable 03.1

4/53

TPM Software Stack (TSS) Implementation and Test Report

V1.0 Final

Introduction

The main specification of the TCG defines a subsystem with protected storage and
trust capabilities: This subsystem is the Trusted Platform Module (TPM). Since the TPM
is both a subsystem intended to provide trust and be an inexpensive component,
resources within it are restricted. This narrowing of the resources, while making the
security properties easier and cheaper to build and verify, causes to the interfaces and
capabilities to be cumbersome. The TCG architecture has solved this by separating the
functions requiring the protected storage and capabilities from the functions that do
not; putting those that do not into the platform’s main processor and memory space
where processing power and storage exceed that of the TPM. The modules and
components that provide this supporting functionality comprise the TPM Software
Stack (TSS) .

Figure 1: TSS-Stack as defined by the TCG

Open_TC Deliverable 03.1

7/53

TPM Software Stack (TSS) Implementation and Test Report

V1.0 Final

Due to its special role, as the central trust API to the trusted hardware (TPM) it will be
used as trust API for the operating system as well as for the applications.
The TSS definition is publicly available at the TCGs website as newest version 1.2

www.trustedcomputing.org

. The old and first version of this stack V1.0 has been

already implemented by IFX for Windows machines in year 2003. As since this first
implementation a lot of new findings and experiences for the TSS came up, the TCG
TSS work group created the current follow on version1.2 of the standard in the periode
of year 2005 to 2006.
Within this project an intensive cooperation with the TCG TSS WG was executed and in
parallel to the work on the TCG standard also this implementation was done. There
where a lot of benefits for the standardisation work group, because the
implementation results where immediately fed back and on the other hand this
implementation became the newest and most up to date one which is currently
available (The 1.2 standard is now public since march 2007 and nearly at the same
time the first beta prototype of this TSS was ready).
For implementation efficiency we tried to use as much as possible code from the old
Windows version. However some of the functions had to be programmed fully new,
because of the different interfacing to Win and Linux (especially low level kernel
functions ) and nearly all code had to be modified either due to the conversion to
Linux but also because of major changes in the standard from version 1.0 to 1.2.
The TSS1.2 specification, which was considered, has a volume of 757 pages.
The final amount of code for this TSS1.2 implementation reached about 95 KLoc.
For testing purposes we added another 25 KLoc of example programs , which use the
stack features.

The complete packetsize of the current TSS implementation is about 4 Mbytes.

The implementation was done on Linux distribution SUSE 10.0 to 10.2 as this is the
standard Linux version for the OpenTC project.
The whole package is available at the OpenTC server and can be downloaded and
compiled at the users target machine. All necessary command and control files (MAKE)
are enclosed to allow an easy integration.

As we found out in contact with potential users, that a local compilation could rise
problems for not much experienced users, we also added precompiled binary versions
which could much more easily installed.

1.1 TPM Management Interface

For managing and controlling the TPM (below the TSS) within WP5 a specific TPM
Control package has been specified and developed. With the functionality from this
package all main TPM management operations can be executed and the status of the
TPM can be analyzed. The functionality is basically described in chapter 11,
the detailed description and code can be found in the results from WP5d and the
respective delivery. It is described here shortly because it has been developed
together with this TSS and can be used for doing some early tests and starting getting
experience with handling the TPM.

Open_TC Deliverable 03.1

8/53

TPM Software Stack (TSS) Implementation and Test Report

V1.0 Final

1.2 Description of work:

The TSS stack has been developed with all mandatory functions acording to the
TCG TSS specifications and is now worldwide the first 1.2 version ready for use.
There are certain functions, which are not required for practical use or which are
still in discussion. For sake of clarity we have in accordance with TCG good practice
not implemented these features until final settling of standardisation work will
occur.

A specific Linux based testbed and testprograms have been developed and the
stack has been tested by this environment.

The complete package (including source code, make files, environment
infrastructure etc.) is available at the OpenTC svn server for use and feedback by
the project partners.

1.2.1 Development of a test environment for the TSS stack

Motivation and execution

For a full coverage of the functionality and behaviour tests of the Linux TSS stack
within the OpenTC project, we used two different test methods during development
and implementations.
In addition to the PHP based test interface, which has advantages for manual testing
and fast generation of result reports, we used also the well known RUBY environment
for testing.
Small and compact code sequences are generated in the target programming
language C as well as for the test environment based on the RUBY script language
which use only small and compact functional of the TSS service provider. With such
high granularity tests we will minimize the risk to ignore errors within the execution
protocols. From the point of the Service provider (SP) both methods look nearly
identical, because the complementary test process is either an executable program or
an shared object from the universal test environment.
This run time library is following certain stringent rules, for allowing the RUBY
interpreter to feed through and converting the script calls of the ruby interpreter.
Amongst the many available script languages for Linux, Ruby has been selected,
because this language is consequently object oriented , the scripts are easily to read
and the generation of a linkage library to connect to the TSS SP is very much
supported by automatic code generation means.

Formal Requirements for the Test Scripts

To achieve a certain homogeneousness of the test scripts independent on the
developer and to allow for an automated checking of the test results, the following
rules shall be followed.
The name of a test script include the unique identifier of the test case it implements. It

Open_TC Deliverable 03.1

9/53

TPM Software Stack (TSS) Implementation and Test Report

V1.0 Final

shall be obvious from the script’s name, which test case it realizes.
Each standalone script releases all variables by means of a instruction before
terminating so that various standalone scripts can be invoked by means of include
instructions by a master script.

Guidelines for Test Development



Identify a test subject



Insert a sub chapter into chapter TSPI of this document



Write a short description of the test subject



Develop the test scripts according to the table in the test plan. Usually, one test
script will contain one test case.



Fault test cases usually contain more than one test case in each row and each
test script.



Debug the test scripts with the help of the Scripting Debug Tool.

1.3 SW-design Fundamentals

1.3.1 References

TCG TPM Specification Version 1.2 Revision 103

https://www.trustedcomputinggroup.org

Specification Version 1.2
Level 2 Revision 103, 9 July 2007

TCG Specification Architecture Overview

https://www.trustedcomputinggroup.org

Specification Revision 1.3, 28th March 2007

TCG Software Stack (TSS)

https://www.trustedcomputinggroup.org

Specification Version 1.2, Level 1, Errata A, Part1: Commands and Structures,

March 7, 2007

1.3.2 Definitions of terms, Acronyms and abbreviations

Listing of term definitions and abbreviations which are important for understanding
the architectural design specification (IT expressions and terms from the application
domain) - irrespective of whether these have already been explained in a different
document (e.g. software requirements specification).

Open_TC Deliverable 03.1

10/53

TPM Software Stack (TSS) Implementation and Test Report

V1.0 Final

Abbreviation

Explanation

ACRYL

Advanced Cryptographic Library

API

Application Programming Interface

ODBC

Open Database Connectivity

Personal Computer

SDK

Software Development Kit

Software

TSP

TCG Service Provider

TSPI

TSP-Interface

TCS

TCG Core Service

TCSI

TCG-Interface

TDDL

TCG-Device Driver Library

TDDLI

TDDL-Interface

TPM

Trusted Platform Module

TSS

TCG-Software-Stack

TSS-SDK

TSS-Software-Development-Kit

GUID

Globally Unique Identifier (a 128-bit value)

XML

Extensible Markup Language

DOM

Document Object Model

COM

Component Object Mode

DCOM

Distributed Component Object Mode

IDL

Interface Definition Language

MIDL

Microsoft® Interface Definition Language

BUK

Basic User Key

TCG

Trusted Computing Group

SOAP

Simple Object Access Protocol

HTTP

Hypertext Transfer Protocol

Table 1: List of abbreviations and terms used for specification and definition

Open_TC Deliverable 03.1

11/53

TPM Software Stack (TSS) Implementation and Test Report

V1.0 Final

TSS Architecture

TCG Service Provider

TCG Core Service

TCG Device Driver Library

TPM

TPM Interface

TPM Device Driver
Library Interface

TCG Core Service Interface

TCG Service Provider
Interface

TCPA Application

Figure 2: TPM Software Stack Structure

IFX-TSS modules considerations and inspection

2.1 TSP and TSPI

This module provides TCG services for applications. It provides the high-level TCG
functions allowing applications to focus on their specialty while relying on the TSP to
perform most of the trusted functions provided by the TPM. This module also provides
a small number of auxiliary functions for convenience not provided by the TPM such as
hashing.
In environments that provide layers of protections (i.e., rings) or separation of
applications into processes, this module is intended to reside within the same ring and
process as the application. There will likely be one TSP per application. On operating
systems that provide multiple processes, there may be multiple TSP’s residing on the

Open_TC Deliverable 03.1

12/53

TSS modules

covered by the

related TCG

specification.

TPM Software Stack (TSS) Implementation and Test Report

V1.0 Final

platform.

2.2 TCS and TCSI

A service provider is any component used by the application that allows that
application access to the TCS (and thus the TPM) from within the application’s process.
Service providers, of which the TSP is but one possible instantiation, cannot
communicate directly with the TPM. Additionally, there are multiple common services
that either must or should be shared among the set of the platform’s service
providers.
The TCG Core Services (TCS) provides a common set of services per platform for all
service providers. Since the TPM is not required to be multithreaded, it provides
threaded access to the TPM. The TCS MUST provide single threaded access to the TPM
and is an out of process system service.

2.3 TDDL and TDDLI

The TCG Device Driver Library (TDDL) is an intermediate module that exists between
the TCS and the kernel mode TPM Device Driver (TDD). The TDDL provides a user
mode interface. Such an interface has several advantages over a kernel mode driver
interface:

•

It ensures different implementations of the TSS properly communicate with any
TPM.

•

It provides an OS-independent interface for TPM applications.

•

It allows the TPM vendor to provide a software TPM simulator as a user mode
component.

Because the TPM is not required to be multithreaded, the TDDL is to be a single-
instance, single threaded module. The TDDL expects the TPM command serialization
to be performed by the TCS.
The TPM vendor is responsible for defining the interface between the TDDL and the
TDD. The TPM vendor can choose the communication and resource allocation
mechanisms between this library and any kernel mode TPM device driver or software
TPM simulator.
This module will be totally removed from the Infineon Technologies TSS package if it is
part of the OS distribution (e.g. Linux) for OpenTC. In the meantime we will implement
the basic functionality for this module to interact with the TPM device.

Open_TC Deliverable 03.1

13/53

TPM Software Stack (TSS) Implementation and Test Report

V1.0 Final

TCG-API

3.1 Function list for the OpenTC TCG-TSS

3.1.1 List of supported TSS Core Service Interface Functions

TSS Core Service Function as specified
by TCG

Solution-

Supported

Not Supported

Context related

Core Service functionality covered by
DCOM

TCS_OpenContext

(x)

TCS_CloseContext

(x)

TCS_FreeMemory

(x)

TCS_GetCapability

Persistent Storage related

TCSP_LoadKeyByUUID

TCS_RegisterKey

TCSP_UnregisterKey

TCS_EnumRegisteredKeys

TCS_GetRegisteredKey

TCS_GetRegisteredKeyBlob

TCSP_GetRegisteredKeyByPublicInfo

Authorization related

TCSP_OIAP

TCSP_OSAP

TCSP_TerminateHandle

TCSP_ChangeAuth

TCSP_ChangeAuthOwner

TCSP_ChangeAuthAsymStart

TCSP_ChangeAuthAsymFinish

TPM related

TCSP_CreateEndorsementKey

TCSP_ReadPubek

TCSP_OwnerReadPubek

TCSP_OwnerReadInternalPub

TCSP_TakeOwnership

TCSP_OwnerClear

TCSP_ForceClear

TCSP_DisableOwnerClear

TCSP_DisableForceClear

TCSP_OwnerSetDisable

TCSP_PhysicalDisable

TCSP_PhysicalEnable

TCSP_PhysicalSetDeactivated

TCSP_SetTempDeactivated

TCSP_SetOwnerInstall

TCSP_DisablePubekRead

Open_TC Deliverable 03.1

15/53

TPM Software Stack (TSS) Implementation and Test Report

V1.0 Final

TSS Core Service Function as specified
by TCG

Solution-

Supported

Not Supported

TCSP_GetCapabilityOwner

TCSP_SelfTestFull

TCSP_CertifySelfTest

TCSP_GetTestResult

TCSP_GetCapability

TCSP_GetCapabilitySigned
TCSP_CreateMaintenanceArchive

X(1)

TCSP_LoadMaintenanceArchive

X(1)

TCSP_KillMaintenanceFeature

X(1)

TCSP_LoadManuMaintPub

X(1)

TCSP_ReadManuMaintPub

X(1)

TCSP_FieldUpgrade

TCSP_SetRedirection

X(1)

TCSP_GetRandom

TCSP_StirRandom

TCSP_Quote

TCSP_Extend

TCSP_PcrRead

TCSP_DirWriteAuth

TCSP_DirRead

TCSP_SetCapability

TCSP_FlushSpecific

TCSP_ResetLockValue

TCSP_OwnerReadInternalPub

TCSP_KeyControlOwner

TCSP_CreateRevocableEndorsementKeyPai
r

TCSP_RevokeEndorsementKeyPair

PCREvent related

TCS_GetPcrEvent

TCS_GetPcrEventsByPcr

TCS_GetPcrEventLog

TCS_LogPcrEvent

Key related

TCSP_EvictKey

TCSP_LoadKeyByBlob

TCSP_GetPubkey

TCSP_CertifyKey

TCSP_CreateWrapKey

TCSP_LoadKey2ByBlob

TCSP_MigrateKey

AIK related

TCSP_MakeIdentity

TCSP_ActivateIdentity

Migration related

TCSP_AuthorizeMigrationKey

TCSP_CreateMigrationBlob

Open_TC Deliverable 03.1

16/53

TPM Software Stack (TSS) Implementation and Test Report

V1.0 Final

TSS Core Service Function as specified
by TCG

Solution-

Supported

Not Supported

TCSP_ConvertMigrationBlob

Hash related

TCSP_Sign

Data related

TCSP_Unbind

TCSP_Seal

TCSP_Unseal

NV related

Tcsip_NV_DefineOrReleaseSpace

Tcsip_NV_WriteValue

Tcsip_NV_WriteValueAuth

Tcsip_NV_ReadValue

Tcsip_NV_ReadValueAuth

The implementation doesn’t support all possible parameter features as described
by TCG

(X) This function is implicitly supported through the COM interface technology
X(1) Optional TPM commands according to TCG Main Specification
X(2) The support of these commands has a high priority for the next release

Table 2: TSS Core Service Function as specified by TCG

Open_TC Deliverable 03.1

17/53

TPM Software Stack (TSS) Implementation and Test Report

V1.0 Final

3.2 Function list for the OpenTC TCG-TSS

For the OpenTC development/porting of the Infineon TCG-TSS the intention is to
separate this into some iteration step. Iterations should be organized that it is
possibility to offer a delivery to the OpenTC project as early as possible.
Currently the functionality for DAA and CMK are not included in the development plan;
due to the fact that there is no use case in the OpenTC project which addresses these
functions and also use scenarios outside the OpenTC are not known.

3.2.1 Supported function list of TSS Service Provider

TSS Service Provider Function as specified
by TCG

Step-1

Supported

Step-2

Supported

Context related
Service Provider functionality covered by
(D)COM

Tspi_Context_Create

Tspi_Context_Close

Tspi_Context_FreeMemory

Tspi_SetAttribUint32

Tspi_GetAttribUint32

Tspi_SetAttribData
Tspi_GetAttribData
Tspi_Context_Connect

Tspi_Context_GetDefaultPolicy

Tspi_Context_CreateObject

Tspi_Context_CloseObject

Tspi_Context_GetCapability

Tspi_Context_GetTPMObject

Tspi_Context_LoadKeyByBlob

Tspi_Context_LoadKeyByUUID

Tspi_Context_RegisterKey

Tspi_Context_UnregisterKey

Tspi_Context_DeleteKeyByUUID
Tspi_Context_GetKeyByUUID

Tspi_Context_GetKeyByPublicInfo
Tspi_Context_GetRegisteredKeysByUUID
Policy related
Tspi_SetAttribUint32
Tspi_GetAttribUint32
Tspi_SetAttribData
Tspi_GetAttribData
Tspi_Policy_SetSecret

Tspi_Policy_FlushSecret

Tspi_Policy_AssignToObject

TPM related
Tspi_SetAttribUint32

Open_TC Deliverable 03.1

18/53

TPM Software Stack (TSS) Implementation and Test Report

V1.0 Final

TSS Service Provider Function as specified
by TCG

Step-1

Supported

Step-2

Supported

Tspi_GetAttribUint32

Tspi_SetAttribData

Tspi_GetAttribData

Tspi_TPM_CreateEndorsementKey
Tspi_TPM_GetPubEndorsementKey

Tspi_TPM_TakeOwnership

Tspi_TPM_CollateIdentityRequest

Tspi_TPM_ActivateIdentity

Tspi_TPM_ClearOwner

Tspi_TPM_SetStatus

Tspi_TPM_GetStatus

Tspi_TPM_SelfTestFull

Tspi_TPM_CertifySelfTest

Tspi_TPM_GetTestResult

Tspi_TPM_GetCapability

Tspi_TPM_GetCapabilitySigned
Tspi_TPM_CreateMaintenanceArchive
Tspi_TPM_LoadMaintenanceArchive
Tspi_TPM_KillMaintenanceFeature
Tspi_TPM_LoadMaintenancePubKey
Tspi_TPM_CheckMaintenancePubKey
Tspi_TPM_SetRedirection
Tspi_TPM_GetRandom

Tspi_TPM_StirRandom

Tspi_TPM_AuthorizeMigrationTicket

Tspi_TPM_GetEvent
Tspi_TPM_GetEvents
Tspi_TPM_GetEventLog
Tspi_TPM_Quote

Tspi_TPM_PcrExtend

Tspi_TPM_PcrRead

Tspi_TPM_DirWrite
Tspi_TPM_DirRead
Tspi_ChangeAuth

Tspi_GetPolicyObject

Key related
Tspi_SetAttribUint32

Tspi_GetAttribUint32

Tspi_SetAttribData

Tspi_GetAttribData

Tspi_Key_LoadKey

Tspi_Key_GetPubKey

Tspi_Key_CertifyKey

Tspi_Key_CreateKey

Tspi_Key_WrapKey
Tspi_Key_CreateMigrationBlob

Tspi_Key_ConvertMigrationBlob

Open_TC Deliverable 03.1

19/53

TPM Software Stack (TSS) Implementation and Test Report

V1.0 Final

TSS Service Provider Function as specified
by TCG

Step-1

Supported

Step-2

Supported

Tspi_ChangeAuth

Tspi_ChangeAuthAsym
Tspi_GetPolicyObject

Hash related
Tspi_Hash_Sign

Tspi_Hash_VerifySignature

Tspi_Hash_SetHashValue

Tspi_Hash_GetHashValue

Tspi_Hash_UpdateHashValue

Data related
Tspi_SetAttribUint32
Tspi_GetAttribUint32
Tspi_SetAttribData

Tspi_GetAttribData

Tspi_Data_Bind

Tspi_Data_Unbind

Tspi_Data_Seal

Tspi_Data_Unseal

Tspi_ChangeAuth

Tspi_ChangeAuthAsym
Tspi_GetPolicyObject

NV related
Tspi_SetAttribUint32

Tspi_GetAttribUint32

Tspi_SetAttribData

Tspi_GetAttribData

Tspi_NV_DefineSpace
Tspi_NV_ReleaseSpace
Tspi_NV_WriteValue

Tspi_NV_ReadValue
PcrComposite related
Tspi_PcrComposite_SelectPcrIndex

Tspi_PcrComosite_SetPcrValue

Tspi_PcrComposite_GetPcrValue

Callback Function Definitions
Tspip_CallbackHMACAuth
Tspip_CallbackXorEnc

Tspip_CallbackTakeOwnership
Tspip_CallbackChangeAuthAsym

O The implementation doesn’t support all possible parameter features as described

by TCG

Table 3: TSS Service Provider Function as specified by TCG

Open_TC Deliverable 03.1

20/53

TPM Software Stack (TSS) Implementation and Test Report

V1.0 Final

3.2.2 List of supported TSS Core Service Interface Functions

TSS Core Service Function as specified by
TCG

Step-1

Supported

Step-2

Supporte

Context related

Core Service functionality covered by DCOM

TCS_OpenContext

TCS_CloseContext

TCS_FreeMemory

TCS_GetCapability

Persistent Storage related

TCSP_LoadKeyByUUID

TCS_RegisterKey

TCSP_UnregisterKey

TCS_EnumRegisteredKeys
TCS_GetRegisteredKey

TCS_GetRegisteredKeyBlob

TCSP_GetRegisteredKeyByPublicInfo

Authorization related

TCSP_OIAP

TCSP_OSAP

TCSP_TerminateHandle

TCSP_ChangeAuth

TCSP_ChangeAuthOwner

TCSP_ChangeAuthAsymStart
TCSP_ChangeAuthAsymFinish

TPM related

TCSP_CreateEndorsementKey
TCSP_ReadPubek

TCSP_OwnerReadPubek

TCSP_OwnerReadInternalPub

TCSP_TakeOwnership

TCSP_OwnerClear

TCSP_ForceClear

TCSP_DisableOwnerClear

TCSP_DisableForceClear

TCSP_OwnerSetDisable

TCSP_PhysicalDisable

TCSP_PhysicalEnable

TCSP_PhysicalSetDeactivated

TCSP_SetTempDeactivated

TCSP_SetOwnerInstall

TCSP_DisablePubekRead

TCSP_GetCapabilityOwner

TCSP_SelfTestFull

TCSP_CertifySelfTest
TCSP_GetTestResult

Open_TC Deliverable 03.1

21/53

TPM Software Stack (TSS) Implementation and Test Report

V1.0 Final

TSS Core Service Function as specified by
TCG

Step-1

Supported

Step-2

Supporte

TCSP_GetCapability

TCSP_GetCapabilitySigned
TCSP_CreateMaintenanceArchive
TCSP_LoadMaintenanceArchive
TCSP_KillMaintenanceFeature
TCSP_LoadManuMaintPub
TCSP_ReadManuMaintPub
TCSP_FieldUpgrade

TCSP_SetRedirection
TCSP_GetRandom

TCSP_StirRandom

TCSP_Quote

TCSP_Extend

TCSP_PcrRead

TCSP_DirWriteAuth

TCSP_DirRead

TCSP_SetCapability

TCSP_FlushSpecific

TCSP_ResetLockValue
TCSP_OwnerReadInternalPub

TCSP_KeyControlOwner
TCSP_CreateRevocableEndorsementKeyPair
TCSP_RevokeEndorsementKeyPair

PCREvent related

TCS_GetPcrEvent
TCS_GetPcrEventsByPcr
TCS_GetPcrEventLog
TCS_LogPcrEvent

Key related

TCSP_EvictKey

TCSP_LoadKeyByBlob

TCSP_GetPubkey

TCSP_CertifyKey

TCSP_CreateWrapKey

TCSP_LoadKey2ByBlob
TCSP_MigrateKey

AIK related

TCSP_MakeIdentity

TCSP_ActivateIdentity

Migration related

TCSP_AuthorizeMigrationKey

TCSP_CreateMigrationBlob

TCSP_ConvertMigrationBlob

Hash related

TCSP_Sign

Data related

Open_TC Deliverable 03.1

22/53

TPM Software Stack (TSS) Implementation and Test Report

V1.0 Final

TSS Core Service Function as specified by
TCG

Step-1

Supported

Step-2

Supporte

TCSP_Unbind

TCSP_Seal

TCSP_Unseal

NV related

Tcsip_NV_DefineOrReleaseSpace
Tcsip_NV_WriteValue
Tcsip_NV_WriteValueAuth
Tcsip_NV_ReadValue
Tcsip_NV_ReadValueAuth

The implementation doesn’t support all possible parameter features as described
by TCG

Table 4: TSS Core Service Function as specified by TCG

Open_TC Deliverable 03.1

23/53

TPM Software Stack (TSS) Implementation and Test Report

V1.0 Final

TSS module architectural overview

4.1 TCG-TSP architectural building blocks

This module provides TCG services for applications. It delivers the high-level TCG
functions allowing applications to focus on their specialty while relying on the TSP to
perform most of the trusted functions provided by the TPM. This module also provides
a small number of auxiliary functions for convenience not provided by the TPM such as
signature verification.
In environments that provide layers of protections (i.e., rings) or separation of
applications into processes, this module is intended to reside within the same ring and
process as the application. There will likely be one TSP per application. On operating
systems that provide multiple processes, there may be multiple instances of TSP’s
running on the platform.

TCG-Aware-Application

Basic architectural building blocks for TCG -TSS-Service-Provide r

User

Crypto-Service-

Module

Persistent -Storage-

Access-Component

TCG-Core-Service-Access

TSP-Persistent -
Storage (user)

TCG-TSS-Core-Service

TSP-Interface -Layer (C-Interface)

Transport -Protection -

Helper

TSPI-Level

Crypto-Algorithm -
Support Module (e.g.
OpenSSL)

Secret-Memory-

Helper

Setting and Policy

Access

Streaming-Helper-

Classes

Error-Handling -Class

Synchronization -Helper-

Module

TSP-Module-

Management

TSP-Working-

Objects

Authorization -

Handling -Component

Auth-Session-

Handling

TSP-Context-

Organization

Common-Module-

Service

Local or remote
calling context.

TSP

Figure 3: Basic architecture building blocks for TCG TSS Service-provider

Open_TC Deliverable 03.1

24/53

TPM Software Stack (TSS) Implementation and Test Report

V1.0 Final

1. TSP-Interface-Layer (C-Interface)

Represents the TSPI of the TSS-Service-Provider and uses the C-Interface
notation. Includes the first object access abstraction layer; accomplishing the
object oriented nature of the TSP interface. Contains functionality to create and
release interface layer objects which are linked to the working layer.

2. TSP-Working-Objects

Collection of all TSP related productive objects (e.g. Key, EncData…). Act as a
kind of business workflow control for all TCG related transformations and
calculations. These operations are performed with assistance of the different
specialized support components and classes.

3. Synchronization-Helper-Module

Collection of some small helper classes; encapsulate the native system calls for
synchronization object handling.

4. Setting and Policy Access

Function and class pool to summarize operations used to access and validate
setting information.

5. Authorization-Handling-Component

Component contains the knowledge and TPM command parameter data for the
authorization data stream construction. This unit interacts with the TSP-Policy-
Class from the TSP-Working-Object and the Auth-Session-Handling module to
calculate the authorization (e.g. HMAC) data package. It interacts as a kind of
instrumentation factor for the TCG authorization flow.

6. Streaming-Helper-Classes

Helper classes transform TCG structures into BYTE-Stream-Representation and
verse versa.

7. Persistent-Storage-Access-Component

Component covers the physical access and representation of the TSP persistent
storage representation. The TSS specification separates the storage context into
a per user boundary and in a system linked one. This functionality and the data
representation reflect a TSS (i.e. TSP and TCG) common code component.

8. Crypto-Service-Module

Abstraction layer to offer a set of cryptographic functions needed for the TCG
related data transformations (e.g. HMAC, SHA1…) in the TSP. The native
algorithm suite is not part of the TSP module.

9. Error-Handling-Class

Helper class(es) used in the exception handling process of the TSS components
(i.e. TSP and TCS). The structured exception concept will be used for error
handling inside of the TSS modules.

10.TSP-Context-Organization

Cover the lifetime control for all TSP context object elements. Represent a kind
of garbage collection for open context resources.

11.Auth-Session-Handling

Envelop the lifetime control for all TSP authorization sessions for a context
object element. Contain functionality to validate the status of the sessions.

12.Secret-Memory-Helper

Offer functionality for limited permission memory area access used to store e.g.
secret data.

13.Transport-Protection-Helper

Set of helper function to support the construction (e.g. encrypt, decrypt…) of
the transport protection related data streams. In addition export the central
execution method for transport protected communication.

Open_TC Deliverable 03.1

25/53

TPM Software Stack (TSS) Implementation and Test Report

V1.0 Final

14.TSP-Module-Management

General operations used to administrate and arrange TSP module wide services
(e.g. memory handling).

15.Common-Module-Service

Common functions used for TSP module management (e.g. registration, load
and unload).

16.TCG-Core-Service-Access

Component covers the physical access and representation of the TCS
communication. Abstraction layer offer the functions to establish, operate and
close the TCS communication in a local and a remote situation.

17.TSP-Persistent-Storage (User)

Contain the physical data representation for TSP persistent storage. The
preferred mechanism would be XML based.

18.Crypto-Algorithm-Support-Module

Extern crypto module or library (e.g. OpenSSL) which offers all basic algorithms
(e.g. hashing) required to derive the TSP crypto function set (e.g. HMAC).

19.TCG-TSS-Core-Service

System service reflects the TSS-Core-Service.

Open_TC Deliverable 03.1

26/53

TPM Software Stack (TSS) Implementation and Test Report

V1.0 Final

4.2 TCG-TCS architectural building blocks

A service provider is any component used by the application that allows that
application access to the TCS (and thus the TPM) from within the application’s process.
Service providers, of which the TSP is but one possible instantiation, cannot
communicate directly with the TPM. Additionally, there are multiple common services
that either are either required to be shared or should be shared among the set of the
platform’s service providers.
The TCG Core Services (TCS) provides a common set of services per platform for all
service providers. Since the TPM is not required to be multi-threaded, it provides
threaded access to the TPM.

TCG-TSS-Service-Provider

(local)

Basic architectural building blocks for TCG -TSS-Core-Service

Physical -TPM-

Command-Module

Persistent -Storage-

Access -Component

TCG-Core-Service-

TPM-Access

TCS-Persistent -
Storage (system)

TCG-TSS-TDDL

TCS-Interface -Layer (SOAP-Interface)

Logical cache

content handling

TCSI-Level

TPM connection

management

Setting and Policy

Access

Streaming-Helper-

Classes

Error-Handling -Class

Synchronization -Helper-

Module

TCS-Module-

Management

Facade-Abstraction -

Component

Logical TPM Resource

handling

TPM Device organize

management

Extended TPM Resource

and access handling

Common-Module-

Service

TCS

TCG-TSS-Service-Provider

(remote )

…

TPM

TPM-Driver

Physical cache strategy

and organization

Figure 4: Basic architecture building blocks for TCG TSS CORE Service

Open_TC Deliverable 03.1

27/53

TPM Software Stack (TSS) Implementation and Test Report

V1.0 Final

1. TCS-Interface-Layer (SOAP-Interface)

The interface to the TCS is the TCS Interface (Tcsi). This is a simple ‘C’ style
interface but should be realized in SOAP. While it may allow multi-threaded
access to the TCS, each operation is intended to be atomic. It resides as a
system process, separate from the application and service provider processes. If
the environment provides for the TCS to reside in a system process,
communication between the service providers and the TCS would be via an RPC.

2. Persistent-Storage-Access-Component (System)

Component covers the physical access and representation of the TCS persistent
storage representation. The TSS specification separates the storage context into
a per user boundary and in a system linked one. This functionality and the data
representation reflect a TSS (i.e. TSP and TCG) common code component.

3. Facade-Abstraction-Component

Component contains a facade factory to generate separate facade objects per
calling context. This layer performs the parameter checking for the TCS-
Interface.

4. Synchronization-Helper-Module

Collection of some small helper classes; encapsulate the native system calls for
synchronization object handling.

5. Logical cache content handling

Characterize a logical TPM device per connection context and organize logical
resource cache management.

6. Logical TPM Resource handling

Contain a management class and resource classes for the two major handled
resource types key and authorization sessions. The task is divided into a
resource map management and into a resource representation unit.

7. Setting and Policy access

Function and class pool to summarize operations used to access and validate
setting information.

8. Extended TPM Resource and access handling

Characterize a physical TPM device is designed as singleton and organize
physical resource cache management. Due to the character as single entry
point for all TPM operations this layer is responsible for TPM access
synchronization.

9. Error-Handling-Class

Helper class(es) used in the exception handling process of the TSS components
(i.e. TSP and TCS). The structured exception concept will be used for error
handling inside of the TSS modules.

10.Streaming-Helper-Classes

Helper classes transform TCG structures into BYTE-Stream-Representation and
verse versa.

11.Physical cache strategy and organization

Contain a physical management classes and resource classes for the two major
handled resource types key and authorization sessions. The task is divided into
a resource map management and into a resource representation unit. In
addition this component automatically detects the underlying TPM device
version and selects the corresponding physical caching strategy and function
set.

12.Physical-TPM-Command-Module

Module is responsible for the TPM command stream generation (byte-stream-
generator) receiving the response and extracting the response parameter

Open_TC Deliverable 03.1

28/53

TPM Software Stack (TSS) Implementation and Test Report

V1.0 Final

elements.

13.TPM-Device organize management

Component includes classes and functionality to handle TPM device specific
startup and shutdown procedures. In addition it controls the consistence of the
resource management of the TCS.

14.TPM connection management

Contain the management classes and functionality to establish the connection
to the TPM device. A further task is to setup the power management control
handling between IFX-TPM-Driver and TCS.

15.Common-Module-Service

Common functions used for TCS module management (e.g. registration, start
and stop).

16.TCS-Module-Management

General operations used to administrate and arrange TCS module wide services
(e.g. memory handling).

17.TCG-Core-Service-TPM-Access

Component covers the physical access and representation of the TDDL
communication. Abstraction layer offer the functions to establish, operate and
close the TPM communication in a local situation.

18.TCS-Persistent-Storage (System)

Contain the physical data representation for TCS persistent storage (on per
system and access able for all users). The preferred mechanism would be XML
based.

19.TCG-TSS-TDDL

The TCG Device Driver Library (TDDL) is an intermediate module that exists
between the TCS and the kernel mode TPM Device Driver (TDD). The TDDL
provides a user mode interface. Such an interface has several advantages over
a kernel mode driver interface:



It ensures different implementations of the TSS properly communicate
with any TPM.



It provides an OS-independent interface for TPM applications.

Because the TPM is not required to be multithreaded, the TDDL is to be a single
instance, single threaded module. The TDDL expects the TPM command
serialization to be performed by the TCS. The exception to the single threaded
nature of the TDDL is the Tddli_Cancel operation. The Tddli_Cancel allows the
TCS to send an abort operation to the TPM.
The TPM vendor is responsible for defining the interface between the TDDL and
the TDD. The TPM vendor can choose the communication and resource
allocation mechanisms between this library and any kernel mode TPM device
driver.

Open_TC Deliverable 03.1

29/53

TPM Software Stack (TSS) Implementation and Test Report

V1.0 Final

OpenTC development environment configuration and

requirements

5.1 Eclipse

http://www.eclipse.org

IDE consists of Editor / Compiler front-end / Debugger front-end

- Freely available for Linux and Windows



CDT

http://eclipse.org/cdt

C/C++ Plugin for Eclipse
Install: Use the following URL in a Site Bookmark in the update manager:

http://download.eclipse.org/tools/cdt/releases/eclipse3.1

5.2 Version Control System



Subversion

http://subversion.tigris.org

Directory structure (suggestion, no must-have)
1. directory TRUNK (main latest)
2. directory BRANCHES
3. directory TAGS (to implement a „labeling“ mechanism)
4. directory RELEASE (versions to be released)



Subclipse

http://subclipse.tigris.org/#subclipse

Subversion Plug-In for Eclipse
Installation into Eclipse: Add

http://subclipse.tigris.org/update

as an update site in

Eclipse's update manager (which you can find in the Help menu).



RapidSVN

http://rapidsvn.tigris.org/

Standalone subversion client available for Linux and Windows

5.3 Change- / Error-Managementsystem



iTracker

http://www.cowsultants.com/

Java / J2EE based bug tracking system
https Web access / Installation as Eclipse Plug-In

Open_TC Deliverable 03.1

30/53

TPM Software Stack (TSS) Implementation and Test Report

V1.0 Final

Installation Procedure for the TSS

OpenTC - Trusted Software Stack - Source Release

---------------------------------------------------------------------

Contents

========

0. Usage

1. Introduction

2. Prerequisites
2.1 Hardware

2.2 Software
2.3 Installing the required software components

3. Installation

4. Running the TSS

5. Building and running the testprograms

---------------------------------------------------------------------

0. Usage

* Usage Terms

* This program is an implementation of the Trusted Computing Group TSS standard
* as a computer program and is distributed under a dual license

* that allows open-source use under a GPL-compatible license for educational
* and research use and for closed-source use under a standard commercial

* license.
*

*
* Redistribution and use in source and binary forms, with or without

* modifications, are permitted provided that the following conditions are met:
*

* 1.Redistributions of source code must retain the above copyright notice,
* this list of conditions and the following disclaimer.

*
* 2.Redistributions in binary form must reproduce the above copyright notice,

* this list of conditions and the following disclaimer in the documentation
* and/or other materials provided with the distribution.

*
* 3.Redistributions in any form must be accompanied by information on how to

* obtain complete source code for this software and any accompanying
* software that uses this software. The source code must either be

* included in the distribution or be available for no more than the cost of
* distribution, and must be freely redistributable under reasonable

* conditions. For an executable file, complete source code means the source
* code for all modules it contains or uses. It does not include source code

* for modules or files that typically accompany the major components of the
* operating system on which the executable file runs.

Open_TC Deliverable 03.1

31/53

TPM Software Stack (TSS) Implementation and Test Report

V1.0 Final

* THIS SOFTWARE IS PROVIDED "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES,
* INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY,

* FITNESS FOR A PARTICULAR PURPOSE, OR NON-INFRINGEMENT, ARE DISCLAIMED. IN NO
* EVENT SHALL THE AUTHOR BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,

SPECIAL,
* EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO,

* PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS;
* OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY

* WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR
* OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF

* ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
*

* The licence and distribution terms for any publicly available version or
* derivative of this code cannot be changed. I.e. this code cannot simply be

* copied and put under another distribution licence
* [including the GNU Public Licence.]

---------------------------------------------------------------------

1. Introduction

This is the official source tree of the Trusted Software Stack (TSS)

within the OpenTC project.

The TSS is a software collection to utilize the Trusted Platform
Module (TPM) in your computer.

For details about your TPM and its capabilities visit these sites:

www.trustedcomputinggroup.org

www.opentc.net

---------------------------------------------------------------------

2. Prerequisites

To efficiently utilize the TSS in your computing environment must
meet some requirements in hardware and software issues:

2.1 Hardware

Your motherboard needs a TPM device mounted. If one is

available, it must be activated in your BIOS.

2.2 Software

To compile the complete TSS the following software
components must be available and properly installed:

gcc C/C++ compilers

Xerces-C XML Parser
Xerces-C-devel XML Parser files for development

Xalan-C XPATH extension for Xerces-C
Xalan-C-devel files for development

openssl Crypto and hashing functions
openssl-devel files for development

e2fsprogs For libuuid

Open_TC Deliverable 03.1

32/53

TPM Software Stack (TSS) Implementation and Test Report

V1.0 Final

e2fsprogs-devel files for development

(tpm-driver) The TPM driver behind your TPM's devnode
gSOAP Version 2.7.9d for IPC matters. (SP<->CS)

Note: communicating SP and CS need to have exactly

the same gSoap version, otherwise communication

will fail! This can be found mainly in remote

scenarios.

POSIX threads linkable via -lpthread

For Mandriva systems it may be also needed to install

Bison
Flex

include /usr/local/lib to your library path

2.3 Installing the required software components

This part describes some details about installing the required
software components for building the complete TSS.

tpm-driver:

Firstly, you should enable the hardware module (TPM) from the BIOS setup.

The drivers are already included in the kernel since version 2.6.13.
Atmel and Infineon

chips are supported. You can load this driver by "modprobe tpm_infineon"
or

"modprobe tpm_tis". If loading of the driver is successful, you then get
a device node

like "/dev/tpm"

For other TPM drivers and older kernel versions, see
http://forum.emscb.org/phpbb/.

Xerces-C

Xerces-C-devel
Xalan-C

Xalan-C-devel
openssl

openssl-devel
e2fsprogs

e2fsprogs-devel

For these components, you can easily download their RPM files and
install them by "rpm -i filename" or you also can use the

software(package)
management tool that should be available in the most linux

distributions. This
is also the preferable way.

Here an example for installing software in SUSE 10.1 is demonstrated:

1) Select "System / Yast (Control Center)" from the startmenu
2) Select "Installation Source"

3) Select "Add / FTP" resp. "Add / HTTP"
4) Add the following entries:

ftp://ftp.gwdg.de/suse/i386/10.1/SUSE-Linux10.1-GM-Extra
http://ftp.gwdg.de/pub/suse/update/10.1/

ftp://ftp.gwdg.de/pub/opensuse/distribution/SL-10.1/inst-source/

Open_TC Deliverable 03.1

33/53

TPM Software Stack (TSS) Implementation and Test Report

V1.0 Final

5) Move the added entries to the top of the list by selecting them

and pushing "up"
6) Push the "Finish" button

Now it takes a little time to read in the added installation

catalogues. When it has finished
you can simply start "Software Management", search for Xerces-c,

Xerces-c-devel, Xalan-c,
Xalan-c-devel, openssl,openssl-devel, e2fsprogs, e2fsprogs-devel

select and install them. The
complete installation is now done automatically and you can use the

packages.

Another example for Fedora6:
1) Select "Applications" in the Panel that is usually above the Desktop

2) Select "Add/Remove Software". Then the Package Manager will start
3) Select the tab "Search" in the Package Manager.

4) Now you can search any software by typing the name like Xerces-c,
then you can click "apply" to install

gSOAP:

For gsoap, please do not use a rpm to install gsoap, because in most
cases, it just installed the

"production" files and not the development package with the headers.
Please install gsoap by source.

Building gsoap

--------------

- cd /your_gsoap_source_folder/gsoap-2.7.9d
- ./configure

- edit file "stdsoap2.cpp" line 3957 in folder

/home/user/temp/gsoap-2.7.9d/soapcpp2

replace
ext_data = ASN1_item_d2i(NULL, &data,

ext->value->length,
ASN1_ITEM_ptr(meth->it));

by
ext_data = ASN1_item_d2i(NULL, (unsigned const char**)&data,

ext->value->length,
ASN1_ITEM_ptr(meth->it));

save and exit the file

- edit file "stdsoap2.cpp" line 3965 in folder

/home/user/temp/gsoap-2.7.9d/soapcpp2

replace
ext_data = meth->d2i(NULL, &data, ext->value->length);

by
ext_data = meth->d2i(NULL, (unsigned const char**)&data, ext-

>value->length);

save and exit the file

- make

Open_TC Deliverable 03.1

34/53

TPM Software Stack (TSS) Implementation and Test Report

V1.0 Final

- make install

--------------

For building gsoap, you may need flex (please also install it by source)

Building flex
--------------

- ./configure

- make

- make install
--------------

PS: If you want install gsoap and flex in the default

folder(recommended), you need to
switch to root account.

If you have problems during the build process like missing libraries,
please

run ./configure again after you fixed the problem (like installing
missing libraries).

---------------------------------------------------------------------

3. Installation

To install the TSS from the sources, simply invoke the build_and_install.sh

script with exactly the same options as you would supply to the configure
scripts in the subdirectories.

E.g. to install in the non-standard folder /dev/shm/opentss you can call
"build_and_install.sh --prefix=/dev/shm/opentss" and for building a debug

version you can call "build_and_install.sh --enable-debug"
Note that non-standard installation prefixes require

tweaking LD_LIBRARY_PATH (recommended) or the ld cache
(ld.so.conf, etc. - not recommended) when running the stack.

Remark: To build and install the TSS no running TPM driver is

neccessary.

---------------------------------------------------------------------

4. Running the TSS

The TSS itself is NO stand-alone program that pops up e.g. with a GUI
when it is started. The main component of the stack is the coreservice

and has to be started with administrator rights. It uses a device driver
library (DDL) to access the device driver of the TPM. Applications that

want to use the stack have to utilize the service provider shared library
(link against it) to communicate with the core service.

Each application can have its own service provider but the core service
exists only once per machine. For detailed information concerning the

structure of a TSS, please refer to the documentation provided from
the TCG (see chapter 1).

- There are three resulting binaries after installation:

the service provider shared library (tss_sp.so) and the DDL shared library

Open_TC Deliverable 03.1

35/53

TPM Software Stack (TSS) Implementation and Test Report

V1.0 Final

(tpm_ddl.so) in the 'lib' folder, and the core service daemon (coreserviced)

in the 'bin' folder.

- The core service daemon (coreserviced) can be started as daemon
(without any command line parameters, this is the dedicated usage)

or as normal executable (with "--debug" as command line parameter)

- The core service dynamically loads the DDL shared library (libtpm_ddl.so).
Therefore it is necessary that it finds the DDL shared library at runtime.

This can be achieved by setting the LD_LIBRARY_PATH environment variable
to the desired folder (e.g. export LD_LIBRARY_PATH=/dev/shm/opentss/lib)

- The service provider shared lib (libtss_sp.so) can be used from each

testprogram
or any self written program and accesses the core service via a soap

interface.

Hint: When the core service is started, it writes status information with
different log levels to the systems log file(s). For openSuse systems this

is in "/var/log/messages", for a Mandriva distribution the information is
split up to several log files. If problems encounter in getting the TSS system

to work, you probably can determine the cause for this by inspecting the
log file(s).

---------------------------------------------------------------------

5. Building and running the testprograms

The source package contains a folder called "testprograms". You can build these

with the included Makefile (please adapt the needed paths before), run each
testprogram

on its own or start the "run.sh" script to run several testprograms
subsequently.

As some of the testprograms use owner authorization, please also adapt the
hardcoded

owner password in the .cpp files before compiling them (Otherwise these
testprograms

will fail due to wrong owner authorisation).

For building the testprograms, you need to make sure that the OpenTC TSS is
properly

installed, because the service provider shared library is referenced in the
building

process and will be linked to the resulting executable.
For running the testprograms you may need to set the LD_LIBRARY_PATH (if you

didn't
install the TSS in the standard folder), so that the service provider shared

library
(libtss_sp.so) can be found.

Open_TC Deliverable 03.1

36/53

TPM Software Stack (TSS) Implementation and Test Report

V1.0 Final

Test and Evaluation Support Programs

################################################################################

######
testprograms using the TSPI interface of the TSP (complete TSS usage: TSP, TCS,

TDDL)
################################################################################

######

tspi_tpm_getrandom get 20 random numbers from the TPM,

Tspi_TPM_GetRandom, Tspi_TPM_StirRandom

tspi_tpm_getrandom_load get 20 random numbers from the TPM, repeat 10000

times, each time a new context is used

(possibility to use 30 contexts in parallel)

mt_tspi_tpm_getrandom get 20 random numbers from the TPM, using one

context and 30 threads in parallel

tspi_tpm_getstatus retrieve the states of 4 persistent flags

(TSS_TPMSTATUS_SETOWNERINSTALL,

TSS_TPMSTATUS_DISABLEOWNERCLEAR,
TSS_TPMSTATUS_DISABLED,

TSS_TPMSTATUS_DISABLEPUBEKREAD) from the TPM,
Tspi_TPM_GetStatus

tspi_tpm_setstatus disable / enable the TPM, Tspi_TPM_SetStatus

tspi_tpm_getcapability retrieve som capabilities from TPM and TCS

Tspi_TPM_GetCapability,
Tspi_Context_GetCapability

tspi_tpm_takeownership take ownership of the TPM,

Tspi_TPM_TakeOwnership

tspi_tpm_clearowner clear the TPM ownership, Tspi_TPM_ClearOwner

tspi_tpm_selftestfull execute tpm selftest, Tspi_TPM_SelfTestFull,

Tspi_TPM_GetTestResult

tspi_tpm_quote test the quote functionality, Tspi_TPM_Quote

tspi_tpm_getpubendorsementkey retrieve the public part of the EK,

Tspi_TPM_GetPubEndorsementKey,

Tspi_TPM_SetStatus

tspi_key_getpubkey get the public part of the SRK,

Tspi_Key_GetPubKey

tspi_key_createkey create a key pair within the TPM, T

spi_Key_CreateKey, Tspi_Context_LoadKeyByUUID

Tspi_Key_LoadKey, Tspi_Key_UnloadKey,
Tspi_Key_GetPubKey

tspi_key_wrapkey create a key pair within the TPM and wrap it

with the given wrapkey,

Open_TC Deliverable 03.1

37/53

TPM Software Stack (TSS) Implementation and Test Report

V1.0 Final

Tspi_Key_WrapKey, Tspi_Key_LoadKey

tspi_changeauth change the authorization data (secret) of an

entity (object) and assign

the object to the policy object, Tspi_ChangeAuth

tspi_changeauth_owner change the owner authorization, Tspi_ChangeAuth

nvm_functions test of non volatile memory functions,

Tspi_NV_DefineSpace, Tspi_NV_ReleaseSpace,

Tspi_NV_WriteValue, Tspi_NV_ReadValue

transport1 Tspi_Data_Bind, Tspi_Data_Unbind,

Tspi_Data_Seal, Tspi_Data_Unseal

migtst test of migration functions,

Tspi_TPM_AuthorizeMigrationTicket,

Tspi_Key_CreateMigrationBlob,

Tspi_Key_ConvertMigrationBlob

pcrtst test of PCR and PCR composite functionality,

Tspi_PcrComposite_SelectPcrIndex,

Tspi_PcrComposite_GetPcrValue,

Tspi_PcrComposite_SetPcrValue,
Tspi_TPM_PcrRead,

Tspi_TPM_PcrExtend

tspi_context_getKeyByUUID_system get a key by UUID from the system persistent

storage

tspi_context_getKeyByUUID_user get a key by UUID from the user persistent

storage

tspi_context_registerkey_system register a key in the system persistent

storage

tspi_context_registerkey_user register a key in the user persistent

storage

tspi_context_loadkeybyblob load a key from a keyblob,

Tspi_Context_LoadKeyByBlob

provoke_error test some functions that must give an error:

- close the default policy object
- close the TPM object / close the policy object of the TPM

object
- create 2 keys and one policy, assign the policy to both

keys,
create first key and then delete the policy, create key 2

fails
- assign a new policy to the context object

- assign a new policy to the tpm object

key_auth_chain This test creates 3 keys in a hierarchy, the middle of which
requires auth.

This is meant to test the TSS_LOADKEY_INFO functionality. The
TCS should

try to load key 2 first and notice that its parent needs

Open_TC Deliverable 03.1

38/53

TPM Software Stack (TSS) Implementation and Test Report

V1.0 Final

loading. When it

tries to load key 1, it should see that there's auth data
there and return

a TSS_LOADKEY_INFO struct to the TSP. The TSP should
transparently handle

this structure to get...

SRK
\

hKey0 (no auth)
\

hKey1 (auth)
\

hKey2 (no auth)

callback test HMAC callback, XORENC callback and TAKEOWNERSHIP

callback functionality

hash tests covering the hash object: creation,

Tspi_Hash_SetHashValue,

Tspi_Hash_GetHashValue, Tspi_SetAttribData, Tspi_Hash_Sign,

Tspi_Hash_VerifySignature

enc_dec test Tspi_EncodeDER_TssBlob and Tspi_DecodeBER_TssBlob

functions

################################################################################
######

basic TPM setup (using only TDDL, no TSP and no TCS), TCS must not be running
################################################################################

######

inittpm TPM_Startup, TPM_PhysicalPresence, TPM_PhysicalPresenceSet,

TPM_PhysicalEnable

TPM_SetDeactivated (false), TPM_SelfTestFull, TPM_GetRandom,
TPM_GetCapability (TPM_CAP_VERSION)

startuptpm TPM_Startup, TPM_SelfTestFull, TPM_GetRandom, TPM_GetCapability

(

TPM_CAP_VERSION)

forcecleartpm TPM_Startup, TPM_PhysicalPresence, TPM_PhysicalPresenceSet,

TPM_ForceClear,

TPM_SelfTestFull, TPM_GetRandom, TPM_GetCapability

(TPM_CAP_VERSION)

Open_TC Deliverable 03.1

39/53

TPM Software Stack (TSS) Implementation and Test Report

V1.0 Final

Test Procedures for the Development Phase

This chapter gives an overview of the tests that have been developed and used for
testing and quality assurance of the API’s of the TCG Software Stack (TSS) within the
project OpenTC. This comprises the TSPI (TSS Service Provider) and TSS Core Service.
The TPM drivers are not part of this activity because they are already available as part
of the Linux kernel 2.6.16 and later.
This package proposes a setup for the test environment and implementation hints so
that the test cases developed by different people will be consistent in their handling.
The testing generally is done by calling from the test harness the appropriate
functions provided by the TPM and TSS components via the automated script
environment.
The actual implementation of the tests is done by writing scripts for an interpreter on
top of an automatically generated TSPI wrapper.

8.1 Glossary of Terms

Terms/Abbreviations

Definition

Client Area:

Platform Security Chip

The TPM chip itself

Security Platform

Is a platform equipped with a

Platform Security Chip

Security Platform User

This is a platform user who is also using the Security Platform.

Security Platform Owner

Is the owner of the

Platform Security Chip

8.2 Test environment

8.2.1 Security Platform:

The Security Platform , which carries the TSS stack as testobject, requires a TPM

chip, like the Infineon TPM SLB9635TT1.2 be setup properly with the TPM
firmware V1.00 or higher and corresponding BIOS integration support (e.g.
ACPI).

8.2.2 External/existing modules for Security Platform:



Compiler: gcc version 4.1.0-25 and higher



Linux Kernel on target system: 2.6.17 or higher

Open_TC Deliverable 03.1

40/53

TPM Software Stack (TSS) Implementation and Test Report

V1.0 Final



Crypto-Library: openssl 0.9.8a-16 + openssl-devel 0.9.8a-16



SOAP-Library (used for CS and SP SOAP-Interface): gSoap -> gsoap_2.7.6e.tgz



XML-Library (used for persistent storage of CS and SP):
Xerces -> Xerces-c 2.7.0.11+ Xerces-c-devel-2.7.0-11



XPATH extension for Xerces: Xalan -> Xalan-c 1.10-10 + Xalan-c-devel 1.10-10



Generation of UUIDs: libuuid -> e2fsprogs 1.38-25 +e2fsprogs-devel 1.38-25



Transports messages to and from remote objects using the SOAP protocol.



Ruby interpreter v1.8.5



Native 32 Bit computer platforms for carrying test harness and test object

8.2.3 Test environments for different test methods

For different test purposes and scenarios we use adapted environments:

8.2.4 PHP –interface for browser supported testing

This allows an easy interfacing to standard browsers and therefore a manual user
supported test execution especially for error identifying and isolation. Additional trace
monitoring assists in test reproduction and test documentation.

8.2.5 Ruby test environment interpreter for automatic test sequencing

The Ruby interpreter can be used to offer an automatic test execution support for
large scale regression tests and similar activities

Ruby is a relational language developed by Jones and Sheeran for describing and
designing circuits. Ruby programs denote binary relations, and programs are built-up
inductively from primitive relations using a pre-defined set of relational operators.
Ruby programs also have a geometric interpretation as networks of primitive relations
connected by wires, which is important when layout is considered in circuit design.
Ruby has been continually developed since 1986, and has been used to design many
different kinds of circuits but also test language environments.

Ruby is a pure, untyped, object-oriented language—just about everything in Ruby is an
object, and object references are not typed. People who enjoy exploring different OO
programming paradigms will enjoy experimenting with Ruby: it has a full metaclass
model, iterators, closures, reflection, and supports the runtime extension of both
classes and individual objects.
Ruby is being used world-wide for text processing, XML and web applications, GUI
building, in middle-tier servers, and general system administration. Ruby is used in
artificial intelligence and machine-learning research, and as an engine for exploratory
mathematics.

Open_TC Deliverable 03.1

41/53

TPM Software Stack (TSS) Implementation and Test Report

V1.0 Final

Ruby’s simple syntax and transparent semantics make it easy to learn. Its direct
execution model and dynamic typing let you develop code incrementally: you can
typically add a feature and then try it immediately, with no need for scaffolding code.
Ruby programs are typically more concise than their Perl or Python counterparts, and
their simplicity makes them easier to understand and maintain. When you bump up
against some facility that Ruby is lacking, you’ll find it easy to write Ruby extensions,
both using Ruby and by using low level C code that adds new features to the
language. We came across Ruby when we were looking for a language to use as a
testing and specification tool.

The Ruby approach to test design is to derive implementations from specifications in
the following way. We first formulate a Ruby program that clearly expresses the
desired relationship between inputs and outputs, but typically has no direct translation
as a test. We then transform this program using algebraic laws for the relational
operators of Ruby, aiming towards a program that does represent a test environment.
There are several reasons why Ruby is based upon relations rather than functions.
Relational languages offer a rich set of operators and laws for combining and
transforming programs, and a natural treatment of non-determinism. Furthermore,
many methods for combining circuits (viewed as networks of functions) are unified if
the distinction between input and output is removed.

8.3 Tracing and Protocol

The components TCS and TSP do not write any trace information. For the purpose of
tracing, a special tool/environment will be used, if necessary.
The test script and all results of each test case shall be written into a protocol file. The
protocol has the same tags as the test protocols of the TSS, so that only one style
sheet for all test protocols will be needed.

8.4 Test Development

8.4.1 Formal Requirements for the Test Plan

The test cases are grouped into test subjects. For each test subject, there is a sub
chapter in this document. This sub chapter contains a short overall description of the
test subject and a table with one row for each test case.
The first column denotes the test case priority. The second one contains a unique
identifier for the test case, the third one a description of the test case that should be
sufficient to implement the corresponding test script. The third column contains either
all tested commands of that test case (good cases) or the expected result for the fault
cases.

8.4.2 Formal Requirements for the Test Scripts

To achieve a certain homogeneousness of the test scripts independent on the
developer and to allow for an automated checking of the test results, the following

Open_TC Deliverable 03.1

42/53

TPM Software Stack (TSS) Implementation and Test Report

V1.0 Final

rules shall be followed.
The name of a test script shall include the unique identifier of the test case it
implements. It shall be obvious from the script’s name, which test case it realizes.
The suffix of a test script shall indicate its use.
*.rb for standalone scripts that can be invoked from the command line
*.inc scripts to be included in other scripts that define commonly used variables
If scripts contain possible dependencies they shall be realized as includable. A test
case using this subroutine might then only contain the unique test case identifier and
include the subroutine script.
For example encryption and decryption: the functionality of encrypting shall be put in
a subroutine script as well as the functionality of decrypting. Then both of them shall
be included by the standalone script thus calling the functions in the appropriate
order.
Each standalone script shall release all variables by means of a instruction before
terminating so that various standalone scripts can be invoked by means of include
instructions by a master script.
Each standalone script that represents the main script of a test case must include a
reference to the unique test case identifier by containing a line
<Test-Id> unique identifier </Test-Id>
which is an tag that will be treated as a comment and written into the protocol file
without change.
Each script must contain two version information fields which can be automatically
added to the protocol file. That means, each time a script is checked in into the
database (and it was modified in a major manner), its version number must be
increased by the author and the current date is set.

8.5 General Requirements for the Test Scripts

Hardware TPM’s do not get a reset from software and therefore do not clear any
previously set values, including PCR’s and keys.
If a test script uses any PCR values, it must set the PCRs with an Extend command.
At the end of each script all keys loaded by that script shall be evicted to avoid
problems running on hardware TPM.

8.5.1 Hints for test script development

See chapter 3.5 for already implemented helper functions.

8.6 Guidelines for Test Development



Identify a test subject



Insert a sub chapter into chapter TSPI of this document

Open_TC Deliverable 03.1

43/53

TPM Software Stack (TSS) Implementation and Test Report

V1.0 Final



Write a short description of the test subject



Develop the test scripts according to the table in the test plan. Usually, one test
script will contain one test case.



Fault test cases usually contain more than one test case in each row and each
test script.



Debug the test scripts with the help of the Scripting Debug Tool.

8.7 Helper functions

Scripting environment does not handle by default TCG specific structured data but
only byte streams. To achieve the functionality of this the TSPI-Wrapper exports
classes, to implement some helper functions.
These helper functions can be realized as script functions first and may later be
included in the wrapper module.

8.7.1 Defined helper functions:

These helper functions are implemented in the scripting dialect and can be found in
the generic folder.



Different compare methods (“Test” instruction)



Various protocol functions



Retrieve internal version of all included scripts



ReadFromFile



WriteToFile



PrintData



Bin2String



AppendArrays



Functions for ASN.1 handling



Functions for extracting parameters from TCPA structures

8.8 Scripting library

All data types in the interface handled as pointer have to be handled by the
corresponding class objects in the scripts.

8.9 Provoking Fault cases

To be able to provoke fault cases, it is desirable to create a special TDDL library
capable of changing the handled data.
As a next step , still outside the scope of this document, a special test environment

Open_TC Deliverable 03.1

44/53

TPM Software Stack (TSS) Implementation and Test Report

V1.0 Final

will be developed for provoking such errors and storing these test results.
Driven by a separate text (ini) file, this test environment and library will change,
delete or insert (ranges of) bytes of specified commands which were send from the
TPM to the TSS.

8.10 Running and Exercising the Tests

Running the Tests



Open a command window



change to the script directory within <test subject>



run the test script file



archive the results in the archive directory

8.10.1 Test coverage

All test cases from this test plan shall be imported into a test coverage database.
The test results of all final tests will be imported into the same test coverage
database.

8.11 Presentation of Test Results

The test results are primarily delivered in the form of the protocol files written by
helper functions.
As the protocol file contains tags for certain attributes of the test cases and their
results, it is possible to extract various summarizing reports from the protocol file.
Sample protocol file:

*************************************************

Test script: IS2_TSP_001_CreateKey1.rb

Protocol: ..\TssProtocols\ IS2_TSP_001_CreateKey1.pro

TSS Core Service: ..\TCG\TPM-SW\TSS\bin\TCS.exe

version: 2.0.0.0

last modified: 26.10.2005 16:20:11

TSS Service Provider: ..\TCG\Tsp\tsp.dll

version: 2.0.0.0

last modified: 02.12.2005 15:07:28

*************************************************

Open_TC Deliverable 03.1

45/53

TPM Software Stack (TSS) Implementation and Test Report

V1.0 Final

<Test-Id> IS2_TSP_001_CreateKey1 </Test-Id>

<Script-Revision> 1.0.0 </Script-Revision>

<Script-Date> 10.10.2006 </Script-Date>

*************************************************

# Test started at 10.10.2006 16:05:59

*************************************************

TSS version 1.2 selected

Firmware version: 1.00

*************************************************

System:

Kernel: 2.6.16.13

Xerces:2.7.0-11

Xalan-C: 1.10-10

GSOAP: 2.7.7

Ruby: 1.8.5

*************************************************

<Test-Id-Start> IS2_TSP_001_CreateKey1 </Test-Id-Start>

TspConnect

TspConnect succeeded !

TspCreateObject(4,0)

TspCreateObject succeeded !

TspCreateObject(2,67108864)

TspCreateObject succeeded !

TspKeySRK.GetPolicyObject succeeded !

TspSRKPolicy.SetSecret succeeded !

TspCreateObject(2,0)

TspCreateObject succeeded !

TspCreateObject(1,1)

TspCreateObject succeeded !

TspPolicyUsage.AssignToObject succeeded !

PolicyUsage.SetSecret succeeded !

Open_TC Deliverable 03.1

46/53

TPM Software Stack (TSS) Implementation and Test Report

V1.0 Final

TspCreateObject(1,2)

TspCreateObject succeeded !

TspPolicyMigration succeeded !

PolicyMigration.SetSecret succeeded !

TspCreateKey succeeded !

TspKey.GetAttribData succeeded !

keyBlob:

0x30, 0x82, 0x01, 0xEB, 0x02, 0x01, 0x01, 0x02, 0x01, 0x01, 0x02, 0x04, 0x00, 0x00, 0x01, 0xDB, 0x04,
0x82, 0x01, 0xDB, 0x01, 0x01, 0x00, 0x00, 0x00, 0x15, 0x00, 0x00, 0x00, 0x06, 0x01, 0x00, 0x00, 0x00,
0x01, 0x00, 0x02, 0x00, 0x03, 0x00, 0x00, 0x00, 0x0C, 0x00, 0x00, 0x04, 0x00, 0x00, 0x00, 0x00, 0x02,
0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x2C, 0x00, 0x02, 0x09, 0x00, 0x8F, 0xB4, 0x77, 0x65, 0x99,
0x63, 0xF3, 0x84, 0x63, 0x58, 0xE3, 0x9C, 0x4A, 0x89, 0x74, 0x50, 0xBB, 0x1C, 0xD7, 0x5D, 0x8F, 0xB4,
0x77, 0x65, 0x99, 0x63, 0xF3, 0x84, 0x63, 0x58, 0xE3, 0x9C, 0x4A, 0x89, 0x74, 0x50, 0xBB, 0x1C, 0xD7,
0x5D, 0x00, 0x00, 0x00, 0x80, 0x8C, 0x9C, 0xCC, 0xF0, 0xD9, 0x77, 0x12, 0xE1, 0x72, 0x21, 0x42, 0x93,
0xA7, 0x75, 0x54, 0x6C, 0x45, 0x33, 0xFF, 0x26, 0x1F, 0xA1, 0xC9, 0xDF, 0x6F, 0x31, 0x89, 0x35, 0x47,
0x94, 0x7D, 0xEF, 0x1D, 0xED, 0xF6, 0x15, 0x5F, 0x97, 0x19, 0x30, 0x09, 0x87, 0x28, 0x58, 0xE1, 0x46,
0x4A, 0x97, 0x4A, 0xE9, 0x5B, 0xB8, 0x59, 0x12, 0xAC, 0x21, 0x51, 0xF6, 0x4A, 0x0D, 0x4F, 0xE5, 0x84,
0x76, 0x6D, 0xAC, 0x6F, 0xE1, 0xF2, 0x5F, 0x43, 0x27, 0xB4, 0x8E, 0x16, 0xB7, 0xCB, 0x52, 0x07, 0x01,
0x9D, 0xFB, 0xC3, 0x9D, 0x52, 0xAE, 0x29, 0x62, 0x0E, 0xDA, 0x67, 0x8F, 0xAD, 0x68, 0x13, 0x2E,
0xF3, 0x9C, 0x36, 0x4F, 0xA2, 0x92, 0x22, 0x92, 0x12, 0x2D, 0x1D, 0xF0, 0xE2, 0x47, 0x78, 0x71, 0xFE,
0xD2, 0x9F, 0x8B, 0x14, 0x49, 0xFF, 0x59, 0x8B, 0x56, 0xC4, 0xED, 0x4F, 0xAF, 0x99, 0x09, 0x00, 0x00,
0x01, 0x00, 0x36, 0xF4, 0xF2, 0xB8, 0xFC, 0xD3, 0x83, 0xD1, 0x8F, 0xFD, 0x24, 0x97, 0xD9, 0x97, 0xDB,
0x06, 0x2D, 0x3C, 0x78, 0xE1, 0x82, 0x51, 0x72, 0x4D, 0xE7, 0x0F, 0x12, 0x64, 0x60, 0x1D, 0x2E, 0xE8,
0xC8, 0xE0, 0x66, 0xDF, 0xCB, 0x47, 0x05, 0xE1, 0x77, 0x30, 0x35, 0x19, 0x14, 0x9A, 0x80, 0xB5, 0x41,
0x23, 0xA9, 0x23, 0xAF, 0xF4, 0xCA, 0x0E, 0x2A, 0x43, 0xC5, 0x04, 0xE9, 0x1D, 0xA5, 0x1C, 0x35, 0x73,
0x8E, 0x4B, 0x11, 0xB0, 0xBD, 0x97, 0x14, 0x8D, 0x58, 0x17, 0xD2, 0x9A, 0xDA, 0x0A, 0xE4, 0x64,
0x10, 0xFE, 0xE3, 0x2E, 0xB4, 0x76, 0xF4, 0x10, 0x80, 0x0B, 0x50, 0xE5, 0x60, 0x76, 0x68, 0x81, 0xBE,
0x11, 0x58, 0x10, 0xBA, 0xA0, 0xC0, 0x64, 0x47, 0x8E, 0x0D, 0xA9, 0xEC, 0x07, 0x42, 0x36, 0xD5,
0x18, 0x0D, 0x73, 0x8F, 0x4D, 0x7C, 0x53, 0x7C, 0x40, 0x78, 0x4A, 0x60, 0x0E, 0x70, 0x75, 0x46, 0x61,
0xEE, 0xD7, 0xA7, 0x31, 0xC1, 0x18, 0x3F, 0x49, 0xAD, 0x5C, 0x6B, 0xDA, 0xCB, 0x90, 0x81, 0xC8,
0xBF, 0x24, 0x7D, 0x15, 0x56, 0x20, 0x30, 0x69, 0xFB, 0x98, 0x43, 0x39, 0xDE, 0xCD, 0x0F, 0x9D, 0x87,
0x30, 0xB4, 0xC1, 0xD7, 0x37, 0x83, 0xFC, 0xE7, 0xAE, 0x56, 0x48, 0xAC, 0x8D, 0xC1, 0x40, 0x1E,
0x95, 0x44, 0xD2, 0x60, 0x06, 0x4B, 0xD7, 0x35, 0x91, 0x80, 0x3D, 0xA7, 0x64, 0x60, 0x1C, 0x4D,
0x08, 0x25, 0xE8, 0x11, 0x12, 0x3E, 0xB5, 0xD0, 0xBB, 0x65, 0xDF, 0xCD, 0xB2, 0x29, 0x14, 0x12,
0xC2, 0xA3, 0x68, 0xF3, 0xF1, 0x0D, 0x44, 0xB3, 0x19, 0x15, 0xC2, 0x2C, 0xA8, 0xD1, 0xCA, 0xF2,
0xB9, 0x00, 0x2F, 0x2B, 0x2F, 0x9F, 0xE0, 0xE6, 0xA7, 0xDC, 0x49, 0xB5, 0xEC, 0x71, 0x88, 0x3E, 0x54,
0x0C, 0x50, 0xE0, 0x79, 0x6D, 0x07, 0x6E, 0xB4, 0x38, 0xD2

<Test-Id-End> IS2_TSP_001_CreateKey1 </Test-Id-End>

<Test-Id-Summery-Start> IS2_TSP_001_CreateKey1 </Test-Id-Summery-Start>

*************************************************

# TEST ERROR(S):

# TEST WARNING(S): 0

# TEST INSTRUCTION(S): 14

# TEST FINISHED:

10.10.2006

16.06.50

# TEST DURATION:

51 seconds

*************************************************

<Test-Id-Summery-End> IS2_TSP_001_CreateKey1 </Test-Id-Summery-End>

Open_TC Deliverable 03.1

47/53

TPM Software Stack (TSS) Implementation and Test Report

V1.0 Final

Test management environment based on the script language RUBY

In addition to the PHP based test interface , which has advantages for manual testing
and fast generation of result reports, we used also the well known RUBY environment
for testing.

9.1 Motivation and execution

For a full coverage of the functionality and behaviour tests of the Linux TSS stack
within the OpenTC project, we use two different test methods and implementations.
Small and compact code sequences are generated in the target programming
language C as well as for the test environment based on the RUBY script language
which use only small and compact functional of the TSS service provider. With such
high granularity tests we will minimize the risk to ignore errors within the execution
protocols. From the point of the Service provider (SP) both methods look nearly
identical, because the complementary test process is either an executable program or
an shared object from the universal test environment.
This run time library is following certain stringent rules, for allowing the RUBY
interpreter to feed through and converting the script calls of the ruby interpreter.
Amongst the many available script languages for Linux, Ruby has been selected,
because this language is consequently object oriented , the scripts are easily to read
and the generation of a linkage library to connect to the TSS SP is very much
supported by automatic code generation means.

9.2 Requirements for run time environment

9.2.1 The Ruby Interpreter

We use the self compiling Ruby interpreter vers. 1.8.5 for all applications within our
project. This standardized interface makes sure, that also any external error gives
similar results in any case.

For generation of Ruby a predefined script is available:

$OPENTSS_DIR/../../testtool/tsstest/shared/build_all
It generates the interpreter as well as the support program “swig”. During successful
generation the script also establishes within the test directory
„$OPENTSS_DIR/build/bin“ symbolic links to the support programs below

Open_TC Deliverable 03.1

48/53

TPM Software Stack (TSS) Implementation and Test Report

V1.0 Final

$OPENTSS_DIR/../../testtool/tsstest/shared/ruby/ruby_runtime/bin
and

$OPENTSS_DIR/../../testtool/tsstest/shared/swig/swig_runtime/bin

The testing personal as well as the developers have to have the target directory inside
their search paths of the shell on a location before he system definition parts.

9.2.2 Writing test scripts

For testing the TSS functions with the help of Ruby, every scripts needs only one test
definition file, e.g.:

Require "../generic/otc_environment.inc"
For example „otc_environment.rb“ includes a class of logic elements, several TSS
constants and the Ruby TSS Wrapper. This behaviour has advantages for TSS. Other
directory structures would require adaptations of the scripts.

[Ruby ]

http://www.ruby-lang.org/en/

Ruby language, a programmers best friend;

Official ruby page

[RubyD]

http://www2.ruby-lang.org/en/20020102.html

, the Ruby download page

Open_TC Deliverable 03.1

49/53

TPM Software Stack (TSS) Implementation and Test Report

V1.0 Final

Testing by third parties inside the OpenTC project

The Budapest University of Technology and Economics (BME) Department of
Measurement and Information Systems is responsible within the OpenTC WP 7
‘Software Development Support, Quality, Evaluation and Certification’ for the manual
and automated security testing of OpenTC software components.
BME carries out testing on different targets during the course of the project; and also
on the TSS. For this ToE a combined approach was chosen, for the API-level analysis
at the TSPI-interface level of the TCG Software Stack implementation both black-box
and white-box mode testing will be executed using the automated security testing tool
Flinder.
The main goal of the testing is to evaluate the TSS at the TSPI level using both black-
box and white-box techniques. By doing this BME will gain information about integrity
and interoperability properties of the Service Provider (SP) and Core Service (CS) parts
of the TSS implementation.

Test process overview

Figure 5: Test process overview

Open_TC Deliverable 03.1

50/53

TPM Software Stack (TSS) Implementation and Test Report

V1.0 Final

This section details the test process that will be followed by BME during the execution
of testing of the OpenTC Infineon TSS implementation. The following steps constitute
to the test process:

SECURITY OBJECTIVES

Concerning the Infineon TSS implementation BME carries out an API-level security
testing using the automated security testing tool FlINDERS. The overall goal of the
testing is to focus on typical security-relevant programming bugs and detect their
presence in the Target of Evaluation in an automated fashion.
Regarding this API-level automated security testing we formulated two types of
security objectives:

1) TCG-related security objectives build a wrapper around the security

requirements specified in the TCG documents and

2) implementation-related security objectives focusing on the properties of the

actual piece of software being under scrutiny.

The goal of the execution of the automated security testing will be to assess, to what
level the Infineon implementation fulfills these requirements.

Test approaches

BME will carry out automated security testing using the Flinder [FLINDER] tool. This
tool was selected after having carried out a comprehensive study in the field of
automated security testing utilities.
Two venues shall be considered for testing the TCG Software Stack (TSS)
implementation:
• The first approach targets the TCG Service Provider Interface (TSPI) and will employ
white-box testing techniques for vulnerability assessment. With this method we will
be able to evaluate integrity issues of the Service Provider (SP) part of the TSS
implementation.

• Other means shall be used for the second approach: black-box testing of the SOAP
transport layer. This time, deeper levels of the TSS are scrutinized for potential
threats. The SOAP communication link is targeted because it is the interface to the
TSS Core Services (TCS) layer implemented in the

coreserviced

process. This

approach will enable use to assess the security and interoperability of the Core
Service (CS) part of the TSS implementation.

Black-box testing at the SOAP connection level

The implementation of the TSS is realized by two communicating processes. Driving
the kernel device driver and providing the core service functionality is provided by the

Open_TC Deliverable 03.1

51/53

TPM Software Stack (TSS) Implementation and Test Report

V1.0 Final

coreserviced demon server process. Two TSS layers are implemented in this process,
the TDDL and the TCS. The coreserviced process exposes a programming interface,
which clients can access through the SOAP protocol.
Flinder starts the test program, but now instead of hooking the source code, the SOAP
communication is intercepted. A SOAP proxy is inserted into the data stream, which
channels data to Flinder. The intercepted data is modified and then routed back to its
original destination.
The main advantage of this procedure is that now the implementation of the
coreserviced is under investigation, and not that of the client process. In this setting
malfunctions or crashes of the client process do not mask potential failures in the core
service demon.

Figure 6: SOAP transport level hooking

The detailed description and results from these test procedures will be
available as deliverable report from OpenTC WP7.

Open_TC Deliverable 03.1

52/53

TPM Software Stack (TSS) Implementation and Test Report

V1.0 Final

TPM Controller: TPM Management and Control SW package

The „TPM Controller“ is a GUI application that helps the user with the initial startup of
the TPM usage. The intention of the tool is not to provide a complete set of functions
for handling all capabilities of the TPM nor displaying all possible TPM internal values,
but to "control" the basic functionality for further usage of the TPM. There are some
other applications handling the former issues, like the "TPM Manager"
(

http://sourceforge.net/projects/tpmmanager/

) or the "TPM Monitor"

(

http://sourceforge.net/projects/tpmmonitor/

The "TPM Controller" tool arised as a result of the OpenTC EU project and is hosted on
their homepage

http://www.opentc.net/

. It provides the possibility to take, change and

clear the ownership of the TPM, which are probably the main things to do when
initiating a TPM. In opposition to these other packages it uses exactly the official
functional TSS1.2 specification from the TCG.
Further on the current version of the used TSS, the actual TPM firmware version and
the vendor name of the TPM are displayed. On the "Status" tab the status of
Activation, Enable/Disable and if an owner is already set are displayed.
With the reset button on the "Reset" tab the owner of the TPM is able to reset the so
called "Pin Failure" count.
The "Certificate Chain" tab tries to verify the TPM built-in endorsement certificate.

11.1 Preconditions

„

TPM Controller“ is a Linux Tool developed and tested on openSuse 10.1 / 10.2, but

should work also with other Linux distributions and could be easily ported to Windows,
since the used GUI toolkit is available for both platforms. It explicitly uses the OpenTC
Trusted Software Stack for TPM 1.2 developed by Infineon. A working installation of
the stack is indispensable.
For the GUI toolkit the open source version of Trolltech Qt 4.2.x was chosen. Therefore
it is necessary that a working version is installed on the machine.
An additional dependency relies on the OpenSSL crypto library, that is used for
cryptographic functionality.

11.2 Build & Run

If all preconditions are met, simply run „build.sh“ on the command line to build the
complete „TPM Controller“ GUI application from source.
To run the „TPM Controller“, simply type „./tpmcontroller“ in the source code folder
and the tool starts up with a modal dialog including several tabs with all the
functionality explained in the following chapters. Obviously the tool can be simply
copied to a user desired location and run from there.

Open_TC Deliverable 03.1

53/53

Document Outline