4Trusted Software Stack
In order to use physical security chips (including TPM and TCM), users require a software module to interact with them. This module is called Trusted Software Stack (TSS).20 As the entry of using a security chip, TSS usually locates between the security chip and user applications. It facilitates user applications to invoke security chip interfaces, and provides functions such as security chip access, security authentication, cryptographic services and resource management. Different security chips need appropriate software stacks such as TCG Software Stack corresponding to TPM and TCM Service Module (TSM) corresponding to TCM.
TSS is the bridge of interaction between user applications and security chip. A security chip provides core functions for building trust environment such as key generation, key storage and signature verification. Meanwhile, TSS provides auxiliary functions for building trust environment such as key usage, integrity measurement and communication between applications and security chips. In summary, the main goals of TSS are as follows [89]:
(1)To provide a set of APIs for user applications to synchronously access security chip.
(2)To manage requests from multiple applications and provide synchronous access to security chip.
(3)To shield processing procedure of internal commands for user applications in the manner of appropriate byte stream order and parameter assignment.
(4)To manage limited resources of security chip.
TSS simplifies the use of security chip. To code a security chip-based application, a programmer only needs to know basic concepts of security chip and upper interfaces provided by TSS, and is not required to concern about complexity of internal structure of security chip.
In this chapter, we introduce the overall architecture and functions of TSS, and then take the TSM as a TSS example to illustrate the definitions of interfaces at different layers and their invoking relationship. We will further introduce basic instances of TSS-based development and outline implementation and application of some existing open-source TSSs.
4.1TSS Architecture and Functions
4.1.1 TSS Architecture
Trusted software stack serves as a standardized interface for security chips. The design of its architecture should take into full consideration the feature of cross-platform and shield the details of different hardware systems. Even though the implementation of each function module varies in each platform and operating system, the relationship of these modules’ interactions and communication should be all the same. The architecture is presented in Figure 4.1.
Trusted software stack provides interfaces for an upper user, so it needs to run in user system and match the running mode of user system. In general, there are two definitions of platform modes in the user system:
(1)Kernel mode: This is where the device drivers and the core components of the operating system execute. Code in this area(mode)maintains and protects the applications running in user mode and usually requires some type of administrator permission to modify and update.
(2)User mode: This is where user applications and system services execute. A user application is an executable code provided by the user. Only when the application is used, the corresponding code is initialized by the user. Therefore, it is less trustworthy on the platform. The code for system services is generally started during initialization of the operating system. Since this code executes in the form of system service process that differs from user application process, it is considered more trusted than user applications.
Based on the definition of platform modes in the above user system, TSS running in user system needs to match its functions with the corresponding user platform mode. TSS mainly includes three layers (as shown in Figure 4.1): kernel layer, system service layer and user application layer. Main function modules and the corresponding user platform modes of the three layers are specified as follows:
(1)The core module of kernel layer is the Trusted Device Driver (TDD) running in the Kernel Mode of user application. TDD is mainly responsible for transmitting the incoming byte stream from the Trusted Device Driver Library (TDDL) to the security chip, and then returning the data from the security chip to TDDL. TDD is also responsible for saving or restoring the security chip state when the power exception occurs.
(2)The core modules of system service layer are the TDDL and the Trusted Core Service (TCS) running in the user mode. Among them, TDDL provides a user mode interface which ensures that the different trusted computing core services can be ported conveniently between platforms. The Trusted Core Service interface (TCSi) is designed to control and request the security chip services. It has a set of public services that can be used for multiple trusted applications. The public services set is mainly responsible for parameter packing, parameter unpacking, log, audit, certificate management for the security chip interface and coordinates multiple applications to synchronously access security chip.
(3)The core module of user application layer is the Trusted Service Provider (TSP), also running in user mode. It is the top layer of TSS and provides the service to access security chip for applications directly.
4.1.2Trusted Device Driver
A corresponding device driver is usually required when using a new hardware device. While using security chips, there is also need of the corresponding device drivers, such as tpm device driver provided by different chip manufacturers based on TPM’s functional specifications. As a basic component to use security chip, TDD is located in the kernel layer of the operating system. It passes the byte streams received from TDDL to security chip and then returns the responses from security chip back to TDDL. It is also responsible for saving or restoring the security chip state when the power exception occurs. Generally, the TDD is loaded when the system is initialized to ensure that security chip interfaces can be invoked by the user applications in the upper layer.
The upper user applications need to invoke relevant software interfaces so that they can get access to the bottom hardware devices. Therefore, when using the trusted computing services based on security chip, the upper user applications in user mode must make use of the TSS that is also located in the user mode and call the TDD loaded in kernel mode to access the security chip. Since the security chip can handle only one request at a time in design, its driver only allows a process to exclusive access. For the multiple requests from the upper user applications, we need the TSS’s relevant functions (such as TCSi) to manage the queuing and synchronizing of requests.
As a hardware device, the design of security chip driver involves the chip manufacturers and operating systems. In order to port applications across the TPM chips made by different manufacturers, IBM developed a standard interface for Linux. It makes the data communication independent of the TPM chips and facilitates the development of trusted applications. In the Linux where TPM driver is loaded, the device file corresponding to TPM chip is /dev/tpm0. The device number increases sequentially if there are multiple TPM chips. The kernel modules of device driver mainly include tpm_atmel, tpm_nsc, tpm_infineon and tpm_tis. These kernel modules provide required hardware drivers for the applications using TPM. The first three modules are TPM drivers manufactured by Atmel, NSC and Infineon, and tpm_tis is a universal TPM device driver meeting the TCG TIS (TPM Interface Specification). This specification provides a universal interface accessing TPM chips, and the interface is independent of various manufacturers.
4.1.3Trusted Device Driver Library
TDDL is a component of TSS communicating with the underlying security chip and is also the first functional component of TSS running in the user space. TDDL mainly converts trusted computing commands and data between the kernel mode and the user mode. The main objectives of the TDDL are as follows:
(1)To ensure that different implementations of TSS can communicate with the security chip.
(2)To provide the interfaces independent of the operating system for the security chip applications.
TDDL provided by the security chip manufacturers is located between the TCS layer and the kernel device driver layer and is able to provide invocation interfaces for the upper-layer TCS in user mode. Because the underlying security chip driver allows only one accessing process, the corresponding driver library interface is designed as a single-threaded synchronous interface. Normally, this interface is a standard interface in C language so that multiple and different TCS can be ported across platforms.
The security chip manufacturers define the interfaces between TDDL and the physical security chips, and choose the communication and resource allocation mechanisms between TDDL and TDD. In most of platform implementations, TDDL needs to be loaded when operating system starts up.
4.1.4Trusted Core Services
Due to the limited hardware resources, a security chip should take into consideration its data-handling capability when designing its functions. Taking TPM as an example, it can only perform one operation once and has the limited number of key slots and the authorization session handles, hence it can only conduct serial communication with the driver. The design leads to low operating efficiency when the upper applications use the security chips. Therefore, there requires a mechanism to manage the multiple calling requests from the upper layer concurrently.
The TCS is designed to address such problems. The processing efficiency of the requests to trusted computing services can be improved by implementing the resource management of security chips simply and efficiently. For this purpose, TCS layer adopts the following methods [106]:
(1)Implementing queue management for multiple operating requests to a security chip.
(2)Making its own response for the operating request that does not require processing by a security chip.
(3)Providing virtually unlimited resources by optimizing the management of limited resources of a security chip.
(4)Offering a variety of access ways such as local or remote invocation for a security chip.
The TCS layer provides a direct and simple way to use a security chip. To the upper applications, it is a public service set that can be used by all the TSP layers on the same platform. The main functions in the TCS layer include the context management, key and certificate management, event management and parameter block generator management. These functions are briefly described as follows:
(1)TSS Core Service interface (TCSi): TCSi allows multithreaded access to the TCS; each operation must be atomic. In most environments it exists as a system process, different from the application and service provider processes. If the TCS resides in a system process, communication between the service providers and the TCS would be via a remote procedure call (RPC) and needs to use TCSi.
(2)TCS context manager: The TCS context manager provides dynamic handles that allow for efficient usage of both the TSP’s and TCS’s resources. Prior to sending command to the TCS, the upper service provider needs to open a context. The TCS context manager provides management functions for multiple contexts, allocates required memory and creates object handle for each context. Different threads within the service provider may share the same context or may acquire an independent context for service provider.
(3)TCS key and credential manager: Keys and credentials may be associated with the platform, the user or individual applications. Hence, it may be more convenient for an application to use a common authorization component to store and manage the keys and credentials. The key and credential manager stores and manages keys and credentials associated with the platform (e.g., the endorsement, platform and conformance credentials) and it allows multiple applications access to them. It should be noted that the persistent storage (PS) provided by the TCS is different from that provided by TSP mentioned later. There is only one storage area in TCS, while there are different storage areas for different users in TSP.
(4)TCS event manager: This component manages the event-related data structures (such as TSS_PCR_EVENT in TPM or TSM_PCR_EVENT in TCM) and their associations with their respective PCR. Meanwhile, this component provides the required event records for external entities. Since they are associated with the platform but not with the application, applications and service providers should obtain only copies of these structures. The TCS must provide the functions to store, manage and report these data structures and their associated PCR indexes. The event-recording data are stored in the corresponding database instead of the persistent storage area, because it can detect whether an event record has been tampered by comparing the hash value of the event record with the value stored in the PCR.
(5)TCS security chip parameter block generator: All the commands such as C-style data structures should be converted into the byte streams that the underlying device driver can understand, while the byte streams from the responses of security chip are required to be converted into the data structures that the upper layer can recognize. Parameter block generator completes the conversion through the interaction with the modules inside the TCS.
4.1.5Trusted Service Provider
TSP is located in the top layer of TSS. It provides interfaces for applications to use trusted computing services and provides protection for data transmission between applications and security chips. The TSP layer is implemented externally as TSP instances in practice. It is located in user layer and has same run level with the user applications. Each user application can run one or more TSP instances to use the trusted computing services. TSP instances provide the high-level trusted computing functions allowing applications to focus on their specific security functions while relying on the TSP instances to perform most of the trusted functions. In addition, TSP also provides a small number of auxiliary functions not provided in the security chips such as data binding and signature verification.
The TSP directly interacts with the applications and provides numerous trusted service modules. To ensure the interaction between different applications, the TSP provides standard C language interfaces. Meanwhile, in order to facilitate the developers to quickly understand and use these interfaces, each module’s object type definition is given with anon-strict “object-oriented” concept when implementing TSS. According to the different data types and usages, the main objects in TSP include context objects, policy objects, security chip (TPM/TCM) objects, key objects, encrypted data objects, PCR objects, nonvolatile memory (NVRAM) objects, hash objects and so on.
The TSP mainly provides the appropriate application interfaces, context manager and cryptographic functions, which are briefly described as follows:
(1)TSP interface: This is an object-oriented interface. It resides within the same process as the application. The application gathers the object’s authorization data from the user, passes it to the TSP for processing by using the interfaces and finally forms the command’s authorization data.
(2)TSP context manager: The TSP context manager provides efficient usage of the TSP’s resources for applications in a dynamic management way. Each request provides the context related to TSP instance. Different threads within the application may share the same context or may acquire a separate context per thread.
(3)TSP cryptographic functions: To take full advantages of the protection functions of a security chip, the TSP must provide cryptographic support functions and interfaces, such as hashing algorithm and byte-stream generator.
4.2TSS Interface
The TSS is mainly designed to provide necessary interfaces for upper applications to use trusted computing functions; therefore, it is necessary to design and implement the corresponding interface function for each functional layer of the TSS mentioned above [106], such as the TSP interface in application layer, the TCS interface and TDDL interface in system service layer and the TDD interface in kernel layer.
The following description takes TSM as an example. We briefly introduce the functional interfaces provided by the TSM [86]. These interfaces correspond to the functional layers mentioned in Section 4.1. The naming conventions of TSM interface functions are described in the Table 4.1.
Table 4.1: Naming conventions of TSM interface functions.
| Layer | Prefix | Description |
| TSP | Tspi_ | TSP interface called by user applications |
| TCS | Tcsi_ | The interface used by TSP layer |
| TDDL | Tddli_ | TDDL interface |
| TDD | Tddi_ | Standard interface of OS |
4.2.1Object Type in TSM
TSM provides object-oriented Application Program Interface (API), each of which is associated with one object type. For this reason, we need to explain the object types defined in TSM before the introduction of specific interface functions.
There are ten different object types in the TSM specification: context object, policy object, TCM object, key object, encrypted data object, PCR composite object, hash object, NVRAM data object, migration data handling object and key agreement object. The definitions are shown in Table 4.2.
Each API is named according to its corresponding object type in the TSS, such that developers can know which object type they are operating. To take the context object handling in the TSM as an example, the function Tspi_Context_Create() informs the TSM service provider to generate a new context handle and return it to the applications. According to the differences of operating objects, the prefixes of APIs’ names are different, for instance, the API for data object begins with “Tspi_Data_” while the API for key object starts with “Tspi_Key_”.
Each TSM object type has its corresponding functional operating function. Developers should know the role and usage of each object type well so that they can write relevant applications.
Table 4.2: TSM data object type.
| Type | Definition | Description |
| TSM_HCONTEXT | TSM_HOBJECT | Context object handle |
| TSM_HPOLICY | TSM_HOBJECT | Policy object handle |
| TSM_HTCM | TSM_HOBJECT | TCMobject handle |
| TSM_HKEY | TSM_HOBJECT | Key object handle |
| TSM_HENCDATA | TSM_HOBJECT | Encrypted data object handle |
| TSM_HPCRS | TSM_HOBJECT | PCR composite object handle |
| TSM_HHASH | TSM_HOBJECT | Hash object handle |
| TSM_HNVSTORE | TSM_HOBJECT | NVRAM data object handle |
| TSM_HMIGDATA | TSM_HOBJECT | Migration data handling object handle |
| TSM_HEXCHANGE | TSM_HOBJECT | Key agreement object handle |
4.2.2TDDL Interface in TSM
The TDDL interface is a component used by TSM to communicate with a physical security chip. It is the bottom functional component running in the user space and provides the switch from kernel mode to user mode. In the TSM architecture, it is located between the TCS and TDD layers, and provides application interfaces for the TCS layer. The TDDL interface is a single-threaded synchronous interface, and the TCM commands sent to this interface must have been serially processed.
The TDDL interface mainly includes three types of functions:
(1)Ensuring the communication with the security chip driver and providing command interfaces such as Open, Close and GetStatus.
(2)Obtaining or setting the attributes of security chip, security chip driver or driver library and providing command interfaces GetCapability and SetCapability.
(3)Transmitting or cancelling the commands sent to the security chip.
4.2.2.1Main Interfaces
The TDDLinterface provides the following nine interface functions to interact with the security chips, so that the program can directly access the hardware devices:
(1)Tddli_Open: This function establishes a connection with the TDD. A successful execution of this function means that the TDD has prepared to process TCM command requests from the upper application. If this call fails, it gives warnings that the TDD is not loaded, started or the TCM does not support any protected requests. This function must be called before calling Tddli_GetStatus, Tddli_GetCapability, Tddli_SetCapability or Tddli_TransmitData.
(2)Tddli_Close: This function closes a connection with the TDD. Following a successful response to this function, the TDD can clear up all the resources used to maintain a connection with the TDDL. If this call fails, it indicates that TDD is unable to clear up resources or may need to be restarted or reloaded.
(3)Tddli_Cancel: This function cancels a TCM command. In a corresponding context, an application can call this function to interrupt an uncompleted TCM command.
(4)Tddli_GetCapability: This function is used to query the attributes of TCM hardware, firmware and device driver such as firmware version and driver version.
(5)Tddli_SetCapability: This function is used to set the attributes of TCM hardware, firmware and device driver. An application can set the parameters of device driver and operation defined by the TCM vendor with this function.
(6)Tddli_GetStatus: This function queries the status of the TCM driver and device. An application can use this function to determine the running status of the TCM subsystem.
(7)Tddli_TransmitData: This function sends a TCM command to a TCM device driver directly, causing the TCM to perform the corresponding operation.
(8)Tddli_PowerManagement: This function sets and queries the TCM’s power states, but there is no corresponding TSPI interface for this function.
(9)Tddli_PowerManagementControl: This function is used to determine and set which component receives and handles the platform’s power state management signals. It should be called only during TSS initialization.
It should be noted that the TCM device driver library only provides the connection to the core service layer, and the core service layer is the unique component that can communicate with the TCM device driver.
4.2.2.2Example
When the TCM driver is loaded successfully, a user can use the TCM commands to execute trusted computing services. There is detailed description of TCM commands in the TSM specification, and here is an example of returning relevant parameters using TDDLi commands.
Suppose the user wants to get the TCM device vendor information, he can use the TDDLi directly. The pseudo codes are shown as follows:
These commands can return current TCM version, the size of TCM loadable key space, the number of loaded key and PCR register.
4.2.3TCS Interface in TSM
We use TCSi to denote TCS interface. This is a simple “C” style interface. (The real core service interfaces are defined in the .wsdl file released by the TSS/TSM.) While it may allow multithreaded access to the TCS layer, each operation is atomic. In most environments it resides as a system process, separating from the other upper applications running synchronously. Service providers can call the TCSi to communicate with the core TCS layer via a local procedure call (LPC) or an RPC.
4.2.3.1Main Interfaces
The TCS layer mainly manages the resources, and includes context manager, key and credential manager, event manager and parameter block generator. They are briefly described below.
Context Manager. Before sending commands to the TCS layer, an upper application needs to open a TCS context. The TCS context manager manages multiple contexts, allocates the required memory for each context and sets the handle for each type of object, including the handle of the context itself. It also provides memory management for each context. The main relevant interfaces are: Tcsi_OpenContext for obtaining a new context handle, Tcsi_CloseContext for releasing the context and its resources, Tcsi_FreeMemory for releasing the memory allocated by the TCS and Tcsi_GetCapability for getting the TCS layer attribute values.
Key and Credential Manager. The key management mainly includes key cache and key storage management. Key cache means that a unique TCS key handle is assigned to a key that has been loaded. When there is no space in the key slot, a key is removed and then a new key will be loaded. It is necessary to establish a mapping table to get a quick query between the TCS and the TCM key handles. Key storage management defines a persistent key hierarchy to internally manage keys. All keys must be registered in it and a universally unique identifier (UUID) will be assigned to each key. The use of a subkey depends on its parent key. The main interfaces of key management include Tcsip_CreateWrapKey for key creation, Tcsi_RegisterKey for registration, Tcsip_LoadKeyByBlob and Tcsip_LoadKeyByUUID for loading and Tcsip_UnregisterKey for unregistration.
The TCS credential management is only responsible for managing the EK credential, platform credential and conformance credential. Only the owner can access credentials. The relevant interfaces include Tcsip_MakeIdentity for generating identities and Tcsi_GetCredentials for obtaining credentials.
Event Manager. It generates, manages and outputs the related event records PCR. The main event records such as runtime measurement IMA are managed by the TSM; other events that are not managed by the TSS are completed by other components, for example, BIOS measurement is completed by the CRTM and OS kernel module measurement is completed by the VMM or DRTM. Besides, event manager should provide event records for the external entities. The event records are stored in the corresponding database instead of the protected areas, because the tampering of event records can be detected by PCR checking.
The interfaces for event management mainly include Tcsi_LogPcrEvent for adding a new event record and Tcsi_GetPcrEvent for checking the event log.
Parameter Block Generator. All command data structures need to be converted to byte streams, which can be understood by the underlying device driver. The byte streams responded by TCM should be converted to the corresponding data structure. The generator needs to interact with each internal module in the TCS, so that the interfaces for the various modules have been defined, such as the authorization-related interfaces (Tcsip_TakeOwnership, Tcsip_OIAP, Tcsip_OSAP), transmission-related interfaces (Tcsip_EstablishTransport, Tcsip_ExecuteTransport) and key-related interfaces (Tcsip_CertifyKey, Tcsip_OwnerReadPubek).
4.2.3.2Usage Method
Since the TSM core service is an underlying functional abstract, which implements the corresponding functions according to the upper commands and returns the results, it is seldom used to develop trusted applications directly. Here we just give an overview of their usage method.
Calling Methods. Usually, the TSM core services must provide interfaces for local procedure calls in order to ensure that local concurrent applications can use local TCM resources simultaneously. However, it also needs to provide the interfaces for remote procedure calls in practical use so that the services are available to the applications on other systems. The main reason for requiring such remote access is that the communication between software requires the authentication between the hosts to ensure security. And as a security chip, the TCM meets this authentication requirement (remote attestation). In addition to ensuring common security communication, the TCM can also provide the attestations of software’s trusted states in different systems, which is impossible for the existing secure communication mechanisms. A brief description of the two calling methods is as follows:
(1)Local procedure calls. LPC means invoking other applications and components directly in the same process or address space. The calling and communication procedures are relatively simple, so we will not go into details.
(2)Remote procedure calls. RPC provides the interaction between processes, mainly including the following:
(a)A rule set to marshal and unmarshal parameters and results.
(b)A rule set to encode and decode information transmitted between two processes.
(c)Some basic operations to trigger an individual call, to return its results and to cancel it.
(d)A rule set to maintain and reference state shared by participating processes, which is specified by the operating system and process structure.
RPC requires a communication infrastructure to establish the path between the processes, and provide a framework for addressing and naming. Any procedure that provides these services has these features.
Using TCS. As mentioned in previous section, the TCS interface in TSM is defined in C language, but this in not always the case. C language definition is only for the convenient discussion. The real TCS interface definition is the .wsdl file released by the TSM, which is a Web Services Description Language (WSDL) format file. We will not describe its specification in detail, and please refer to other relevant contents (such as the relevant introductions of XML, SOAP and HTTP). This file is attempted to provide a high-level universal definition for the TCS interface, such that the different developers on different platforms can use compatible tools.
Ideally, developers can use the existing TSM application-layer codes in C language to interact with the C-like TCS interface in TSM without understanding the underlying details. The TSM application-layer codes do not concern the process in which data arrive at the TCS layer, and they just need call some C language functions looking like the TCS. For this reason, a tool resolving .wsdl file is needed so that the TSM application layer can call the resolved functions directly, including specific C/C++ header files and source files.
4.2.4TSP Interface in TSM
The most commonly used interface when users access a security chip based on TSS is the TSP interface, which provides the corresponding functions for users to use the trusted computing functions. In the TSM, it defines the related interfaces of nine objects: context management, policy management, trusted cryptographic module (TCM) management, key management, data encryption and decryption, PCR management, NVRAM management, Hash operation and key agreement.
The following section describes the object relationship in the TSM, and then gives a brief description of the corresponding interface of each object.
4.2.4.1Object Relationship in Application Layer
Working objects are subdivided into authorized and non-authorized working objects in TSM application layer. Non-authorized working objects include the hash objects and PCR objects. Authorized working objects include the TCM object, context objects, key objects, encrypted data objects, NV Objects, key agreement objects and policy objects.
Nonauthorized Working Object Relationship. The non-authorizedworking object relationship is shown in Figure 4.2. The context manager provided by the TCS creates multiple context objects, each of which can create multiple non-authorized PCR objects and non-authorized hash objects, thus showing a one-to-many relationship.
Authorized Working Object Relationship. The authorized working object relationship is shown in Figure 4.3. The user application may have to provide authorization data related to the policy objects when utilizing the authorized working objects via the TSP interface. A policy may be assigned to several working objects like key objects, encrypted data objects or TCM objects utilizing the Tspi_Policy_AssignToObject function. Each of these objects will utilize its assigned policy object to process TCM commands requiring authorization (based on internal functions of the policy object).
On creation of a context object, a default policy is created. This default policy is automatically assigned to each new created object. The default policy for each working object exists as long as no command assigns a new policy object to the working object.
For example, the relationship between policy objects and other objects in Figure 4.3 is shown as follows:
(1)When a context object is created, TSM will generate a default policy object. If an encrypted data object does not customize its own usage policy, the assigned policy will be the default policy. There is a one-to-one relationship between a TCM object and its policy object (operator policy).
(2)If a user needs to assign a new policy to a working object (such as a key object or a NV object), then the new policy should be generated using the context object. Here the relationship between context object and policy object is one-to-many (1:1 ... n), while the relationship between policy object and an ordinary working object is 1. . . 2:0. . . 1, where 1. . . 2 represents that a certain working object generates one or two policies (usage policy or migration policy) and 0. . . 1 indicates that the above policy may not be assigned after being generated or only be assigned to a certain object (this object can only be assigned to either usage policy or migration policy).
4.2.4.2Main Interfaces
The TSP includes context management, policy management, trusted cryptographic module management, key management, data encryption and decryption, PCR management, nonvolatile memory management (NVRAM management), Hash operation and key agreement. Their corresponding interface definitions will be described in the following sections.
Context Management. The context management object interface provides information about the TSP object’s execution environment, such as the identity of the object, the transaction/communication with other TSM Software modules and memory management. According to the different functions, it can be divided into four specified categories: context management, object management, key management and information acquisition.
(1)Context management operation: It includes some specific functions such as Tspi_Context_Create for creating a context, Tspi_Context_Close for closing a context, Tspi_SetAttribUint32/SetAttribUintData for setting the context attributes (variable length or invariable length), Tspi_GetAttribUint32/GetAttribUintData for getting the context attributes (variable length or invariable length), Tspi_Context_Connect for connecting a context, Tspi_Context_FreeMemory for releasing a context, Tspi_Context_GetDefaultPolicy for getting default policy of a context, all of them are used to set and manage the context-related attributes.
(2)Object management operation: It includes two main interfaces: Tspi_Context_ CreateObject for creating objects and Tspi_Context_CloseObject for closing objects. Tspi_Context_CreateObject creates and initializes an empty object of specified type and returns the handle of this object. The empty object will be associated with an opened context object. Tspi_Context_CloseObject is used to destroy the object associated with a context and releases all related resources.
(3)Information acquisition operation: It includes two categories of operations: acquiring the platform capabilities and acquiring the TCM object handle. Tspi_Context_GetCapability for acquiring the platform capabilities is used to obtain the functionality/performance/attributes data of TSM service provider or core service; Tspi_Context_GetTcmObject for getting the TCM object handle is used to retrieve a context of the TCM object. Only one instance of this object exists for a given context and implicitly represents a TCM owner.
(4)Key management operation: It mainly refers to the interfaces provided by the TSM service provider, which facilitate users to call the underlying key management functions. The interfaces include the operations about the key loading, key generation and cancellation, key acquisition and others. For example, the interface for loading a key by its attributes is defined as Tspi_Context_LoadKeyByBlob, while the interface for getting a key by its ID is defined as Tspi_Context_GetKeyByUUID. For the interface definitions and usage of other operations, please refer to the specifications.
Policy Management Object. Policy management objects configure the corresponding security policies and behaviors for different applications. An application provides the specialized operation on authorization secret information for the authorization mechanism via the policy management. It includes the following operations:
(1)Setting policy authorization: Tspi_Policy_SetSecret sets the authorization data and mode for a policy object. The mode for policy to obtain authorization data is called secret mode, which includes the following cases in TSM:
TSM_SECRET_MODE_NONE: No authorization requests.
TSM_SECRET_MODE_SM3: Let rgbsecret point to a 32-byte hashed secret information.
TSM_SECRET_MODE-PLAIN: Let rgbsecret point to some plaintext, and ulsecretLength is the string length of rgbsecret.
TSM_SCRET_MODE_POPUP: TSM prompts a user to enter a password, which represents a TSM_UNICODE string and the string must be hash value.
(2)Flushing policy authorization: The function Tspi_Policy_FlushSecretis is used for flushing the cached policy authorization information, and it only requires an input parameter (the policy object handle hPolicy).
(3)Binding policy object: The function Tspi_Policy_AssignToObject assigns a certain policy to a working object (TCM object, key object, encrypted data object). Each of these working objects will utilize its assigned policy object to process an authorized TCM command. By default, each new generated working object is assigned to the default policy. This function can bind a new policy to the working object, and meanwhile adds the policy to the policy list of the working object.
Trusted Cryptographic Module Management. TCM management object is usually used to represent TCM owner. TCM owner can be seen as the system administrator in a common PC environment. Therefore, there is only one TCM management object instance for each context, and this object is automatically associated with a policy object for handling the authorization data of TCM owner. In addition, it also provides some basic functions for controlling and reporting. Because the TCM management object is used most frequently, it provides the most functions and interfaces. According to its operation phases and functions, the functions and interfaces are divided into the following five categories:
(1)Request of creating platform identity and credential: This is mainly used to create a platform identity key (PIK), bind the user identity information and return a credential request packet.
(2)Activating platform identity and obtaining PIK credential: This is mainly used to verify the authenticity of a PIK credential and return the decrypted credential.
(3)PEK-related operations: Main operations include creating a PEK request, obtaining a PEK credential, importing a PEK key, creating an irrevocable EK, obtaining the public key of EK, creating a revocable EK, revoking an EK, creating a TCM owner, removing a TCM owner, setting operator authorization and setting TCM operation mode.
(4)Querying and obtaining TCM-related information: The main operations include querying and setting TCM state, obtaining TCM capability, full self-checking of TCM, obtaining self-checking result of TCM, obtaining the random number generated by TCM, obtaining a single event of TCM, obtaining a set of events of TCM and obtaining event log of TCM.
(5)PCR operations: The main operations include extending the PCR, reading the PCR value, resetting PCR, quoting PCR, reading TCM counter, reading the current TCM clock, obtaining the audit digest of TCM and setting the audit state of TCM command.
Key Management. The key management object interface is an entry for TSM to carry out key management functions. Each key object instance represents a specific key node in the TSM key storage hierarchy. Each key object requiring authorization should be assigned a policy object for managing authorization secret information. According to its functions, it can be divided into two categories:
(1)Functional interfaces for management: The interfaces mainly include the following functions: modifying the entity authorization data, getting policy object, setting key attributes (invariable or variable length parameter), getting key attributes (invariable or variable length parameter) and so on. They are defined by generic function interface.
(2)Functional interfaces related to key operations: This mainly includes the following interfaces: Tspi_Key_LoadKey for loading key, Tspi_Key_UnloadKey for unloading key, Tspi_Key_GetPubKey for getting public key, Tspi_Key_CertifyKey for certifying key, Tspi_Key_CreateKey for creating key, Tspi_Key_WrapKey for wrapping key, Tspi_Key_AuthorizeMigrationKey for creating migration authorization, Tspi_Key_CreateMigrationBlob for creating migration key data blob, and Tspi_Key_ConvertMigrationBlob for importing migration key data blob.
Data Encryption and Decryption. This object is used to associate the data generated by an external entity (such as a user or an application) with the system (binding to the platform or PCR), or to provide data encryption/decryption services for an external entity. In the authorizing process, this object can be assigned to another policy object. The object interface can be divided into two categories by function.
(1)Management operations: Management operations mainly include the following functions: modifying entity authorization, getting policy objects, getting data attributes (invariable-length parameter), setting data attributes (variable-length parameter), getting data attributes and other functions. They all utilize the general function interface definition.
(2)Data operations: They mainly include the following functions: data encryption, data decryption, data sealing, data unsealing, digital envelope sealing, digital envelope unsealing and other functions. They are described as follows:
(a)Data encryption and decryption
The main function is to encrypt plaintext and decrypt the corresponding cipertext. The corresponding interface functions are Tspi_Data_Encrypt for data encryption and Tspi_Data_Decrypt for data decryption. The cryptographic algorithm used by encryption and decryption depends on the key attributes.
When an application calls the encryption command, if the symmetric encryption SMS4 is used, the encryption mode is CBC mode; if the asymmetric encryption SM2 is used, the input plaintext cannot exceed 256 bytes. When an application calls the decryption command, if symmetric decryption SMS4 is used, the decryption mode is CBC mode.
(b)Data sealing and unsealing
Data sealing is used to seal a data blob, whose corresponding interface is Tspi_Data_Seal, while data unsealing is used to unseal a specified data blob, whose corresponding interface is Tspi_Data_Unseal. If you want to unseal a sealed data, you must use Tspi_Data_Unseal on the same platform. Note that the sealing key used during data sealing should be a non-migratable key.
(c)Digital envelope sealing and unsealing
The main function is to seal digital envelope or unseal the sealed digital envelope. The corresponding interfaces are defined as Tspi_Data_Envelop for sealing data envelope and Tspi_Data_Unenvelop for unsealing data envelope. In the sealing process, the encrypted data get the data of digital envelope by Tspi_GetAttribData. In the unsealing process, the sealed data of digital envelope will be decrypted. Note that the interface function allocates memory for the plaintext data in the unsealing process, so the caller needs to release the memory explicitly.
PCR Management. PCR object interface is used to establish the trust level of system platform. The interface provides an easy way to select, read and write a PCR.
All the functions requiring PCR information use PCR object handle in their parameter list. The main interfaces include Tspi_PcrComposite_SetPcrLocality for setting PCR Locality attributes, Tspi_PcrComposite_GetPcrLocality for getting PCR Locality attributes, Tspi_PcrComposite_GetCompositeHash for getting PCR composite digest, Tspi_PcrComposite_SetPcrValue for setting PCR value, Tspi_PcrComposite_GetPcrValue for getting PCR value and Tspi_PcrComposite_ SelectPcrIndex for selecting PCR index.
NVRAM Management. NVRAM management object is used to store the attribute information in nonvolatile memory area of TCM, which is used to define, read, write and release the NV area. This kind of commands establishes the size, index and various reading and writing authorization of NV memory area, and the authorization can be based on PCR value or authorization data.
In addition to the generic functions (setting or getting attributes), the interfaces of NVRAM management are mainly as follows: Tspi_NV_DefineSpace for creating a specified NV memory space, Tspi_NV_ReleaseSpace for releasing a NV memory space, Tspi_NV_WriteValue for writing data into a NV memory area and Tspi_NV_ReadValue for reading data from a specified NV memory area.
Hash Operations. Hash object provides a cryptographic security method for digital signature. In addition to the generic function interfaces to set and get the attributes, the main functional interfaces include Tspi_Hash_SetUserMessageData for carrying out the hash operation on user data, Tspi_Hash_SetHashValue for setting a hash value, Tspi_Hash_GetHashValue for getting the hash value of a hash object, Tspi_Hash_UpdateHashValue for updating a hash value, Tspi_Hash_Sign for signing a hash value, Tspi_Hash_VerifySignature for verifying the signature of a hash value and Tspi_Hash_TickStampBlob for adding time stamp to a hash object.
Key Agreement. Key agreement object is used to execute key exchange protocol operations. The main functional operations include creating a session, getting a session key and releasing a session. The corresponding interfaces are defined as follows:
(1)Creating a session: Tspi_Exchange_CreateKeyExchange creates a key agreement session handle with TCM and returns an ephemeral point on the elliptic curve. Two participants A and B generate their ephemeral points RA and RB, respectively, using this function. A transmits R A to B, while B transmits RB to A; then they complete the computation of key agreement with Tspi_Exchange_ GetKeyExchange. When Tspi_Exchange_CreateKeyExchange has created a key agreement handle, it will return TSM_E_EXCHANGE_HANDLE_EXIST error code if you reuse it. You must release the key agreement handle by Tspi_Exchange_ ReleaseExchangeSession, then Tspi_Exchange_CreateKeyExchange can be called again to establish key agreement handle with TCM.
(2)Getting a session key: The main function is to create a key agreement session handle with TCM and return an ephemeral curve point. An agreement session can only complete a key exchange.
If a key agreement handle is not created by Tspi_Exchange_ CreateKeyExchange, this function must return the error code TSM_E_ EXCHANGE_HANDLE_NOT_EXIST.
In case of a successful operation, the handle hSessionKey represents a symmetric key handle after a successful agreement. Assuming that the users A and B carry out a key agreement, after a successful operation using Tspi_Exchange_GetKeyExchange, the local verification data of A is S A and the verification data sent to B is S1; while the local verification data of B is SB and the verification data sent to A is S2. A needs to verify whether SB and S2 are equal and B needs to compare S A and S1. If validation fails, the encryption and decryption using the generated symmetric key will fail on both sides.
(3)Releasing a session: Tspi_Exchange_ReleaseKeyExchange releases a key agreement session handle established with TCM. The input parameter of this interface is key agreement handle hKeyExchange. If this handle is not created by Tspi_Exchange_CreateKeyExchange, this function must return the error code TSM_E_EXCHANGE_HANDLE_NOT_EXIST.
4.3Trusted Application Development
As a bridge between user applications and a security chip, TSS provides bottom-up interfaces: TDDL interface, TCS interface and TSP interface. Developers can call appropriate interface to develop in different functional levels according to specific application requirements. This section will introduce specific trusted application development methods based on TSM. First, we introduce an interface’s calling procedure and method. Then we take the usage of most common TSP interfaces as an example and give specific processes to call interface combined with practical application scenarios.
4.3.1Calling Method of Interfaces
In order to use the underlying TCM chip, the TSM provides multiple functional interface layers to facilitate users to develop upper security applications based on trusted computing. When calling these interfaces, the basic calling procedure is shown in Figure 4.4 and a brief description is as follows:
(1)When a user application uses TSM to access TCM, the call between the user application and TSP layer adopts a dynamic link library (DLL) way. The corresponding header files and library files of dynamic link library are provided for developers to develop security applications.
(2)The communication between the TSP and the TCS adopts the way of LPC or RPC. It can automatically allocate memory in the communication procedure according to the definition of IDL (Interface Description Language).
(3)The interface between TCS and TDDL also adopts DLL method. Since the TDDL interface is standard, it also takes DLL method when using driver library in order to facilitate the port of TCS. In this way, TCS layer can use different driver libraries and run on the platforms with different security chips.
(4)The interfaces of driver library and device driver are standard interfaces that allow OS accessing driver.
In general, when trusted applications call the functions of a security chip, they only use the top TSPi interface rather than calling interfaces in each level of TSS. The underlying TCS interface, TDDL interface and TDD interface in TSM are only as abstract interfaces and not exposed to users explicitly. The commutation data between them are automatically implemented by TSS.
In the development process of a trusted application, the programmer first creates a context object using the TSP interface and then generates a corresponding target object, such as a TPM object, a key object or a PCR object. After that, he should create or configure an authorization policy object for the above object, so as to conduct permission decision. Finally, he performs the specific trusted computing functional operations, such as key creation, digital signature and remote attestation.
Taking the file encryption and decryption and the signature verification in the DRM (Digital Right Management) as examples, we briefly describe the specific process of developing trusted computing applications based on TSM in the following sections.
4.3.2Example 1: File Encryption and Decryption
Users need to protect their personal confidential files. Otherwise, sensitive data may be revealed because the files are copied or computers are lost. Compared to the traditional solution based on software encryption, a tamper-resistant security chip can protect keys in a more secure manner so that users’ files can be protected better.
The main process of encrypting a user’s file based on TCM chip is as follows: The user creates (he must input his own password) and loads a symmetric encryption key on the host embedded with a security chip TCM. The key is encrypted and protected by the TCM and can be bound to the current host configuration; then the user selects the file to be protected and calls the encryption interface to generate an encrypted file. When the user opens the file, he must enter the password to load the corresponding decryption key. In the following, we briefly describe the related encryption and decryption operations in the application development process, including initial setup, authorization policy setting, key operation, data encryption and decryption, resource release and so on.
4.3.2.1Initial Setup
First, a basic context object should be created, which is the foundation of further operations of TSS and is used to establish the initial execution environment.
4.3.2.2Policy Setting
When TSM performs operations, it needs to create appropriate usage policies for the involved objects. First, it obtains the above created context object and then it gets a corresponding policy object hOwnerPolicyObject and sets the policy value for the policy object. Here we take policy mode TSM_SECRET_MODE_SM3 as an example. This mode takes a 32-byte array from external hash computation as authorization data. The input data won’t be modified by TSM.
4.3.2.3Key Operation
The parent key hSMK must be loaded into the TCM before we use it to create a new key object whose usage policy will be set as the default policy pDefaultPolicyObject; then we can generate a new encryption key hKey based on the parent key handle and load it into the security chip. The code is presented as follows:
4.3.2.4Encryption and Decryption
To use a newly generated key object to encrypt and decrypt the files to be protected, we first create an encrypted data object hEncData (using the bound operation type TSM_ENCDATA_BIND) and then use the existing key hKey to perform encryption and corresponding decryption. The code is presented as follows:
4.3.2.5Release the Resource
After the encryption and decryption operations are completed, the TSM resources related to this operation should be released, including evicting the key, closing the corresponding key object and releasing memory resources.
4.3.3Example 2: Signature Verification in DRM
In order to protect the copyright of digital products, many digital service providers (such as the company providing online software downloading business) need to build their own DRM systems to prevent software from being copied and used without limit. The main way to implement DRM is to embed the copyright owner’s signature into software while encrypting its digital contents. When a user starts the software, the service provider first verifies the signature. After a successful verification, the user can decrypt the contents and use the software. Compared with the existing software-based DRM schemes, the method with a tamper-resistant security chip can detect the authenticity and validity of software products, thereby providing a more secure DRM.
In the following example, we briefly describe the signature verification process based on security chip TCM in DRM, and we will further introduce the method of developing security applications based on TSM.
4.3.3.1Initial Setup
First, we create data objects for the signature verification operation, including context object, hash object and key object, which establishes an initial environment for further TSM operations.
4.3.3.2Policy Setup
We set the required authorization policy for this operation. Here we still take the policy mode TSM_SECRET_MODE_SM3 as an example. It takes a 32-byte array from external hash computation as the authorization data.
4.3.3.3Create a Signature Key
To sign a software product, we first need to create a signature key object whose type is TSM_ECCKEY_TYPE_SIGNING. Here we set its signature scheme as TCM_SS_ECCSIGN_SCH and its authorization mode as TSM_SECRET_MODE_SCH, and finally we create and load the signature key.
4.3.3.4Sign and Verify
First, a service provider needs to generate/update a hash value for the software required to be protected (such as rgbSecret). Then the service provider signs this software with the existing signature key hSignKey. When the software product is released, the signature is bound to this product. When using the software, a user needs to submit the corresponding signature data. The service provider verifies the signature with the corresponding signature key. If the signature is verified successfully, it means that the software is authorized and the user can use it legally. If it fails, it indicates that the software is not authorized or the signature data have been tampered. For example, the correct signature value prgbSignature has been tampered into the wrong signature value wrongSignature.
4.3.3.5Release the Resource
After the operations are completed, the resources related to signing and verifying should be released, including signature key and SMK object.
4.4Open-Source TSS Implementation
This section describes the existing open-source TSS implementations, which are based on the TCG Software Stack Specification and provide most of the trusted computing functional interfaces for developers. Their specific implementations are mainly based on standard C language and Java language. C-based TrouSerS is the most popular TSS.
4.4.1TrouSerS
TrouSerS is an open-source TSS software developed by IBM researchers, which is compatible with the TCG Software Stack Specification version 1.1 and version 1.2 and can provide interfaces accessing TPM for the user applications.
4.4.1.1Basic Architecture
TSS consists of TSS Service Provider (TSP), TSS Core Services (TCS), TSS Device Driver Library (TDDL) and TSS Device Driver (TDD). TrouSerS realizes the TSP shared library, the TCS daemon tcsd and the TDDL library, and meanwhile provides the persistent storage of some resources like keys. The following are its main functional components:
(1)TSP shared library: Trousers implements TSP as a shared library libtspi.so, which enables applications to communicate with TCS daemon (or system service) tcsd locally or remotely. Meanwhile, TSP also manages various resources that are used to communicate with applications and tcsd and interacts with tcsd transparently when required.
(2)TCS daemon: TCS daemon tcsd is a daemon in user space. It is the unique entry to access TPM on demand of the TCG Software Stack Specification. When the system boots, TCS daemon is loaded and it will open TPM device driver. Since the system boots, all the operations that are used to connect TPM should be then based on TSS. The daemon tcsd manages TPM resources and processes the local and remote TSP requests.
(3)TDDL library: TrouSerS implements TDDL in the form of the static library libtddl.a, which is called by the upper-layer TCS and is the only bottom interface to interact with the hardware TPM.
(4)Persistent storage file: TSS provides two different types of persistent storage for the keys. PS can be regarded as a key database, in which each key is indexed by an UUID.
(a)PS for users
This kind of PS is maintained by the TSP library of applications. When writing the first key to the PS for users, TSP library creates a new file in ∼/.trousers/user.data and finds the working directory utilizing the effective user ID of the process. The environment variable TSS_USER_PS_FILE can also make the TSP library setting point to different locations of PS for users. This environment variable has the same life cycle with TSP context. So in order to store two keys to two files respectively, it needs to call Tspi_Context_Close, set the new location and open the context again.
(b)PS for system
This kind of PS is controlled by TCS and remains effective during the life cycle of all applications, tcsd reboot and system reset. The data registered in the PS for system remain effective until an application requests to delete it. The file of PS for system is located in the path /usr/local/var/lib/tpm/system.data by default, which is usually created when the TPM takes ownership for the first time.
4.4.1.2Run TrouSerS
By default, the TCS daemon cannot be accessed through the network; therefore, it can be executed as root role only in local access, and it should ensure that TPM device driver is loaded and started as root role. If Linux Kernel 2.6.12 and above are used and udev is started up, the following content should be added to the file udev (usually located in /etc/udev):
tpm[0-9]:tss:tss:0600
Then, itloads the corresponding device driver:
# modprobetpm_atmel (the specific names are different according to different manufacturers)
Finally, it starts the TCS process, which is /usr/local/sbin/tcsd by default:
# /usr/local/sbin/tcsd
If you want to let TCS process communicate with software-based TPM via TCP network protocol, you need to use the option -e:
# /usr/local/sbin/tcsd -e
The open-source TrouSerS has implemented the complete functional interfaces of TSS1.2, and it supports to run in the 32- and 64-bit platforms. Therefore, it is the most popular TSS currently. Most of the developments related to trusted computing products depend on this software.
4.4.2jTSS
The interfaces of the published TCG TSS specification are defined in C language, which cannot be used in Java environment. Therefore, many institutions perform research on calling trusted computing functions in Java environment. Under the support of European openTC Project and Austria acTvSM Project, the researchers from IAIK institute (The Institute for Applied Information Processing and Communications) in Graz University of Technology in Austria developed a software stack named jTSS, which is also an open-source software interface.21 It realizes all the TSS functions with Java language. At the same time, in order to support the local and remote access, jTSS also implements an RPC mechanism that is consistent with TSS1.2. This mechanism is based on the SOAP protocol and ensures that it can interact with various TSS of different vendors.
4.4.2.1Basic Architecture
In order to implement functions required by the TCG Software Stack Specification, the jTSS interface mainly consists of three parts: TSP, TCS and TDDL. Its main function architecture is briefly described as follows.
TSS Service Provider. The TSP library provides APIs for developers to access all TPM functions. These APIs allow applications to use TPM via TSP. In jTSS, the APIs are defined as sets of interfaces located in the iaik.tc.tss.api package, while iaik.tc.tss.impl package is the actual implementation of API interface definition, and the impl package provides subpackages implemented by different types of TSP. The Java subpackage can include a complete Java implementation of TSP, while other subpackages may include some implementations such as a JNI implementation that supports to interact with a C-based TSP such as TrouSerS. The main advantage of separation of API implementation is that the applications above the top layer of TSP can easily switch between different TSP implementations in bottom layer by changing the library for creating TSP objects.
TSS Core Services. The TCS is the unique entity that can directly access TPM, so it is implemented as a system service or daemon that is responsible for TPM command stream generation, TPM command serialization, TPM resource management, event log management and persistent storage for system. In a typical TCS implementation, it is a daemon or system service supported by jTSS, and meanwhile jTSS provides the access to it in the form of libraries.
TDDL. The package iaik.tc.tss.impl.java.tcs.tddl contains a TDDL for different operating systems. The TDDL is a functional layer that can directly interact with TPM driver (e.g., through a device file or some specific mechanisms of operating system).
In addition, the code architecture of jTSS also provides the method to share files between TSP and TCS and the way of persistent storage. The multiple components shared by TSP and TCS are placed in the same directory. These components include the constants used in TPM and TCS, the data structures of TSS and TPM layers, the implementation of persistent storage and the common cryptography library. The jTSS provides two different types of PS.
The first type of PS uses the file system of operating system as the database. In the configuration file .ini, it needs to set different directories for two storage ways (system-level and user-level), where there must be only one for TCS system storage and one for each user (e.g., /home/<username>/.tpm/user_storage). We must take care to set the access permission for the storage files. Since the directory structure is created automatically, it is recommended to create and set the file permissions before enabling jTSS.
The second type of PS uses the relational database. It provides some concrete implementation on demand; therefore, it can implement specific Java classes for persistent storage and configure it in the file. After TPM is executed, the SRK (storage root key) will be stored in the system storage area (not including the private key part). Note that in the TSS specification, the application developers are required to create and maintain a valid key structure.
4.4.2.2Use jTSS
The jTSS source code gives some examples. Here we take context operation as an example to explain its invoking method. The following code illustrates the basic operations when using TPM:
In this example, TcTssContextFactory provides the context object context of TcIContext type and selects the local or SOAP binding automatically to implement the connection with TCS context.connect() based on the settings in the configuration file jtss_tsp.ini.
4.4.3 μTSS
The TCG Software Stack provides interfaces to use TPM for trusted computing application development. But the current TSS interface is very complex and is prone to errors in use. Besides, this complexity makes it unsuitable to the embedded devices with limited resource or security kernel; therefore, a simplified implementation of TSS interface is required. Aiming at the above requirements, Sirrix AG Company in Germany developed a software stack μTSS [107] that provides lightweight programming interfaces based on the TPM specification for developers. In the premise of ensuring correctness of μTSS, its design idea is to reduce the complexity of object wrapping and error handling and improve the usability in application development by further abstracting the interfaces. The μTSS also provides modular functional architecture, which enables it to provide corresponding subsets of functional interfaces for different requirements, for example, customizing different subsets of software stack for some environments such as embedded systems, mobile devices or systems based on security kernel. In addition, it can also be used for compliance test for the TPM specification and implementation of MTM.
The μTSS is developed by C++ language and supports object-oriented implementation. Compared with other high-level language such as Python, Java or C#, it requires a smaller runtime environment. Similar to TSS implementation, the basic architecture of μTSS includes oTSP, oTCS and oTDDL.
4.4.3.1oTSP Layer
The oTSP layer provides an advanced abstract interface for application developers. It offers object-oriented abstract of TPM functions and defines the relevant objects in the TPM specification, such as TPM object and key object. But it hides the complexity of some functional interfaces as far as possible; for example, in the key object, it hides the complexity of key loading and key updating using the base class PrivateKey, so that the key is loaded automatically when used and is updated automatically when the application is closed.
4.4.3.2oTCS Layer
The oTCS layer implements TCS interface. It provides TPM commands, sessions and interfaces to execute these commands. By defining each TPM command as a single C++ class, it supports a variety of different specifications and minimizes the interface. By implementing TPM command template, it becomes simple to modify (such as updating the TSS specification) or remove (such as the cases in embedded and mobile device environments) TPM commands.
4.4.3.3oTDDL Layer
The oTDDL layer implements TDDL interface, including the interface connecting to TPM device driver. It provides various TDDLi back end interfaces. The SocketTDDL class sends TPM commands to the remote side using TCP/IP connection; the DeviceTDDL class provides access to TPM in local platform in different operating system environments.
The μTSS is mainly used in the following scenarios:
(1)MTM software stack and the software-based MTM implementation: The MTM is similar to TPM and is suitable for embedded and mobile devices. There are some differences between the command set of MTM and TPM; for example, some TPM commands are not available on MTM and MTM also adds a number of new commands, so a new TSS implementation is required. If there is no physical chip supporting MTM, the μTSS can be used to realize a software-based MTM.
(2)The development of compliance test set for the TPM specification: The test for TPM needs to cover most TPM commands. The oTCS layer of μTSS can be used to generate the input data for a test. Since the μTSS hides a lot of complex operations in TSS, it can generate test cases quickly and easily.
(3)The development of TPM manager: TPM manager is a graphical management tool for TPM. The early version took TrouSerS as back end. Afterward, μTSS was introduced as back end. The advantage is that DeviceTDDL implemented by μTSS enables the upper applications to get access to TPM driver directly without the daemon tcsd, which makes the initrd (containing TPM manager) very small.
Using the object-oriented design and implementation, μTSS provides convenient and efficient interfaces for developers. It effectively reduces the complexity of some functional interfaces in the TSS specification and provides for handling of runtime errors and compiling of time errors. The modular architecture design of μTSS makes it have a better application flexibility and can provide trusted service interfaces for various application environments such as embedded or mobile devices, so it will have a bright application prospect.
4.5Summary
This chapter mainly describes the TSS-related contents. TSS is a support software to use a security chip. It can provide required interfaces for users to develop applications based on security chips. This chapter first describes the basic architecture, composition and functions of TSS. Then, taking the example of the software stack TSM, it illustrates the brief definitions and invoking relations of the interface of each layer in TSS. It also gives examples of developing trusted applications using TSS. Finally, it introduces the implementation and usage of popular open-source TSS.
In order to support wider application such as mobile applications and Java applications, TSS needs to provide flexible, multi-language and cross-platform implementation in the future. Moreover, since TSS is the most common way to communicate with secure chips, its security is directly related to the security of trusted applications. Therefore, formal modeling for the functional interfaces provided by the TSS is required, so that it can provide fine-grained and detailed analysis for the security properties of TSS and detect possible security vulnerabilities of the interfaces in use, thus enhancing the security of TSS.