WO2012093924A1

WO2012093924A1 - System and method to provide trusted platform module (tpm) functionalities on a remote server for multiple users

Info

Publication number: WO2012093924A1
Application number: PCT/MY2011/000159
Authority: WO
Inventors: Putri Shahnim Khalid; Azhar Abu TALIB; Muhamad Hazwan Halim; Abdul Muzaire ABDUL MUTALIB; Kilausuria Abdullah; Norazah ABD AZIZ; Lucyantie Mazalan; Mohd Azuddin Parman
Original assignee: Mimos Berhad
Priority date: 2011-01-07
Filing date: 2011-06-30
Publication date: 2012-07-12

Abstract

The present application teaches of a remote server that provides TPM functionalities to devices which do not have TPM functionalities.

Description

System And Method To Provide Trusted Platform Module (TPM) Functionalities On A Remote Server For Multiple Users

Field of Invention

The present invention relates to the field of trusted computing, more particularly in providing trusted computing functionalities via a remote server.

Background of Invention

The Trusted Computing Group has defined the functionality and protocol for a hardware module called the Trusted Platform Module (TPM). This piece of hardware offers security and cryptographic functionality to computer systems such as, for example, asymmetric key generation, decryption, encryption, signing, sealing and binding of data to the state of the TPM, migration of keys between TPMs, random number generation and hashing functionality. A TPM also holds state in forms of stored keys, non- volatile memory areas and platform configuration registers. A Trusted Platform Module can be used to authenticate hardware devices. Also because the TPM is implemented in hardware and presents a carefully designed interface, it is resistant to software attacks

However since TPM is implemented only in the hardware, the users are only able to enjoy the functionalities of TPM if their device is equipped with the TPM hardware. Also hardware virtualization is becoming increasingly available for common off the shelf hardware. Therefore, those who are using virtual hardware may not be able to use TPM functionalities if the TPM functionalities is limited to physical devices.

Therefore, there arise a need for a server that provides TPM capabilities in the form of hardware and/or virtual TPM that would enable the users who do not have TPM hardware in their device to access TPM functionalities as and when they require it. Summary of Invention

It is the objective of the present invention to provide for a remote server with TPM capabilities in the form of a virtual TPM (vTPM), which includes a fault tolerance mechanism and scalability functions.

In the present invention, the remote server providing the TPM functionalities is able to provide devices without an inbuilt TPM hardware to use TPM functionalities when the devices are connected to the remote TPM server of the present invention.

Also in the present invention a Resource Manager is provided to generate new TPM instances, wherein it is the TPM instances that enable the devices to use TPM functionalities via the server. Furthermore, the Resource Manager also handles the scalability and fault tolerance mechanism of the server, in order to enable the server to be made available at any point of time to any number of user without failing.

Description of Drawings

Figure 1 Overall architecture of present system

Figure 2 vTPM instance generating process

Figure 3 Scalability mechanism

Figure 4 Fault tolerance mechanism

Detailed Description

Figure 1 illustrates the overall architecture of the TPM server of the present invention, where the TPM server provides remote access to users (101) in the network who need to use the trusted computing functionalities on their device, which does not have TPM on board. The machines used can be hardware such as desktops, laptops or mobile devices or it can be virtual machines. The TPM server of the present application allows the users to use TPM capabilities as and when the machine used by the users are connected to the server. The challenge of the present invention is to provide a remote server which can cater to any number of users and also to ensure that all the users will be able to access to the server at any intended point of time. The solution was to provide a system which is controlled by a Resource Manager (RM) that handles the creation of vTPM instances, scalability of the server and fault tolerance of the server. The RM resides on the TPM server.

The users secured devices, which do not have either, a TPM hardware or a vTPM are connected to the TPM server via a trusted channel such as a network. A trusted storage is provided in the system where all the data is saved.

The system also is provided with a remote attestation mechanism, local certification authority and a migration controller, which are defined as follows: Remote attestation provides remote assurance of the state of the hardware running on a computing device. The remote attestation protocol allows hosts to verify the hardware and software of a running remote host. The host can then decide whether or not it trusts the attested remote host's configuration. Attestation is closely related to authentication. In the network environment, anonymous authentication access could facilitate the security mechanism. The authentication concept performed by the access requestor requires an access to the facilities without necessarily revealing their identities to external parties. This requirement stems from the possible need for each individual to maintain some degree of plausible deniability as to these presences at a convener. Trusted Computing Platform (TCP) provides a mechanism that supports the attestation by its Platform Configuration Registers (PCR) which has become the integrity measurement of a platform. This PCR values are meant to be protected during the attestation transaction. Local certification authority provides functionality intended to facilitate the vTPM in signing EK certificate. The functionality required the vTPM to request EK certificate from the local CA providing the necessary vTPM EK public key. Local CA will sign the certificate request using local CA private key and once the certificate is successfully signed, local CA will return the EK certificate to the vTPM in a secured compartment. This communication is handled by a secured channel communication. Before that, the local CA initially needs to establish its own certificate whereby the local CA generate own local CA key pair, local CA certificate and return the local CA public key to Server CA remotely for future local CA verification. These processes were done in a same platform where the local CA and vTPM resides in the same layer hypervisor.

The migration controller manages the migration of the TPM server to another physical location. For a TPM system, the most important issue is the trustworthiness of the system. Hence when migrating the system to a different physical location, care needs to be given on how to migrate the TPM and its associated vTPM to ensure the chain of trust is not broken. The protocol on migrating the system is handled by the migration controller.

Resource Manager

Resource Manager handles all the resources related to vTPM. Functions of Resource Manager includes the creation and management of multiple vTPM instances, handling the fault tolerance mechanism of the TPM server in cases of failure and also handling of the scalability function to cater for high number of users connected to the TPM server. vTPM Processes

One of the main roles of the RM is to handle the creation or spawning of vTPM instance for each individual users, which generally indicates the users that they have been given . access to use the TPM functionalities provided by the remote server . Each user will be assigned a dedicated vTPM instance by the RM, which is linked to the TPM hardware. Methods of linking the TPM hardware to the vTPM by mapping the hardware values into the vTPM are well known to those skilled in the art.

Figure 2 illustrates the sequence/method of assigning a vTPM instance according to the present invention.

According to the present invention the RM waits for a request i.e request to create, resume, suspend, destroy or terminate an instance from a user. When a request is received from the user, the RM verifies the records and status in the storage for a vTPM instance. If records and status confirms that a vTPM instance is in existence, the RM proceeds with the users request, and then proceeds to update its storage with the state file. The state file contains all the vTPM information and keys.

However, if upon verification the RM confirms that a vTPM instance is not currently in existence, the RM the assigns a unique property to the new vTPM instance. The unique property here is defined as any unique property unique enough to assign users, for example vTPM ID or IP port number. However, the unique property is not limited only to the examples given here. The RM then spawns a new vTPM instance. The RM returns the parameters of the new vTPM instance to the users, and the proceeds to update its storage with the state file.

Scalability The second function of the RM is to handle the scalability of the vTPM server in order to ensure that multiple users can access the server at any point of time, since the number of users that can access the server is ideally limitless. When a huge number of users are attempting to access the vTPM server, the server is likely to be out of system resource, which then results in the users not being able to access the server. Therefore, the present invention includes a scalability function in the remote vTPM server of the present invention in order to overcome the problem of the vTPM server being exhausted of its system resource, which will now be discussed in detail. Figure 3, illustrates the scalability of the present invention. The vTPM server has n number ' of RM, correlating to n number of servers in the system. The RM initialized at the beginning of the system is RM Primary (RMP). RMP manages and decides which TPM server is capable to spawn a new vTPM. First the RMP queries the number of vTPM instances in storage for the Primary Server (PS). If the number of vTPM instances on the Primary Server has not exceeded the maximum, the vTPM will be spawned in the PS. The maximum vTPM instances of the Primary Server depends directly on the capacity of the machine being used i.e. the memory size of the machine being used. The maximum number of instances increase with the increase of the machine memory.

However, the exact number of maximum instances would be preset by the system administrator based on the memory size of the machine.

Once the resources of the PS has been exhausted wherein, the number of instances on the PS has reached the maximum number, the RMP will then check the number of instances in the next available server, such as the Secondary Server (SS). If the SS has not reached its maximum number of vTPM instances, then the RMP will communicate to the RM Secondary (RMS), which resides in the SS, and direct it to spawn the new instances.

Each time a server that is spawning at that point of time reaches its maximum number of instances, the process illustrated above is repeated. The process will be repeated n number of times, where n is at least 1 , depending on the availability of resources on the servers that have been previously spawning the vTPM instances. The RMP remains as the main unit that checks for the availability of the resources and interacts with the other RMs in the other servers, whenever a server reaches it maximum number of instances.

Fault Tolerance

Having provided access to limitless users, the server must also guarantee that the server can be accesses at any point of time by the n number of users. In other words, the server must be available at all times, since all keys and state files are saved in the server and any disruption to the server may lead to loss of information on the users end.

Figure 3, illustrates the fault tolerance mechanism of the present TPM server which has been designed to overcome the above drawback. The RM also handles the fault tolerance mechanism of the present invention. The fault tolerance mechanism is divided into two separate process i.e. replication and fault tolerance, which will both be explained in detail in the following paragraphs.

Replication & Fault tolerance

The RMP saves and updates the vTPM state files periodically to the dedicated storage. RMP server spawns vTPM instances according to the record and state file in the specified dedicated storage. The fault tolerance feature of the system will check the RMP status. If there is a failure, the fault tolerance system will route any incoming traffic to the backup server.

If the status of the RMP indicates that the server is working, the above process is.

repeated. However, if the RMP status indicates that the server has failed, the RMP server routes any requests to the RMP Backup (RMPB). Henceforth, the RMPB server functions as the RMP server. The RMPB server then saves and updated state files periodically to the dedicated storage. The RMPB server also checks the status of the RMP server. If the RMP server fails, the process is repeated. However, if the RMP server is working the RMP server synchronize itself to the storage and resumes the role of the Primary Server.

Claims

A system to provide TPM functionalities comprising of

a Resource Manager that created vTPM instances, provides scalability mechanism and fault tolerance mechanism;

a secured device that is at least a TPM hardware or a vTPM; trusted channel between the user and the server; and

a trusted storage

A Resource Manager according to claim 1, wherein the RM creates vTPM instances in the steps of

receiving request from users to create vTPM instance

checking the RM records for the existence of the requested vTPM assigning a unique property of the user to the vTPM instance starting the vTPM instance with the unique property parameters updating vTPM paratmeters and status in RM records

returning the parameters to users

A RM according to claim 2, wherein the RM verifies the unique properties and status of the vTPM before activation, suspend, terminate or destroy the vTPM instance.

A Resource Manager according to claim 2, wherein the scalability mechanism of the RM are in the steps of:

Querying the storage for the number of vTPM instances availability Spawning the vTPM instances in the Primary Server if the maximum number of the server has not been reached

Spawning for vTPM instances in n number of server if the maximum number of instances has been reached in the Primary Server Interacting with the n number server if the maximum number of instances has not been reached in the n number of server, Wherein the RM in the Primary Server interacts with the RM in the n number server to provide the RM ih n number server the needed parameter to spawn for a new vTPM in the n number server.

5. A Resource Manager according to claim 2, wherein the fault tolerance

mechanism of the RM are in the steps of:

Updating of state file periodically to the dedicated storage;

Spawning of vTPM instances according to the record and state file in the specified dedicated storage ;

Routing any request to TPM Primary Backup Server when the TPM Primary Server fails;

Assigning of the Primary Backup Server as the Primary Server Synchronizing the Primary Server to the storage when the Primary server is functioning again

Resuming of the Primary Server as the primary server.