The enhanced security mechanisms proposed in this thesis will unavoidably have an impact on user convenience. The correct use of the proposed solution demands good knowledge of the underlying components to configure the parameters in a correct manner. A desirable feature is to increase the usability of the proposed security architecture.
During the research project several efforts were made to enhance the usability aspects of the developed architecture. To assure an easy deployment of the proof-of-concept system, easy-to- use installation programs have been created which allow interested manufacturers to evaluate the security architecture more quickly. Furthermore, scripts for the creation of sample platform policies have been written for easy provisioning of the TPM and the platform.
The correct use of the TPM management tools, as well as the platform policy creation tools, which are provided by the open source software packages, is a quite complicated task. The creation and the deployment of platform policies requires technical engineering ’know how’ and a good knowledge of the employed technologies.
Furthermore, the command line policy creation tools possess a potential weak point regarding security. When the policies are written into the non-volatile memory of the Trusted Platform Module, the system administrator has to authenticate himself/herself to the TPM, by typing in the TPM owner password. Unfortunately, the password has to be typed in as a command line argument, and therefore it could be clearly visible. Even worse, the typed-in commands will be saved in the command line history and thus could be retrieved at any time. If the policies
5. The Proof of Concept System
are written to the TPM with normal user rights, any person with access to the platform can potentially find out information about the TPM owner’s password.
Based on the above discussion on configuration and the use of command-line tools, towards the end of this research work, it was seen as a desirable feature to develop a Graphical User Interface (GUI), which would effectively address the described weak points and enhance the usability, and thus the acceptability of the proposed security solution, which is described in this thesis. According to the individual goals of the research project the GUI is developed in the C++ programming language, using Qt for platform independence. The GUI forms an effective tool, which can be used by the system administrator for the provisioning and maintenance of the proposed security architecture. By utilizing the Trusted Software Stack API, the tool combines functions for the management of the Trusted Platform Module, such as commands for taking ownership or clearing the TPM with data management functions. Furthermore, the GUI is developed to provide an easy-to-use scheme for the creation and the deployment of platform configuration policies. The system administrator will provide the information about the individual software components, which should be able to launch with a well-defined configuration, the program will automatically create the corresponding platform policy and write the policy into the TPM non-volatile storage.
At the time of writing this thesis the GUI is in an early stage of development. It makes use of the most important TSS API calls. Below the use of the TSS API is demonstrated in the example of sealing arbitrary data to a specific system state. The functions for error handling have been omitted for more clarity.
Before a program can make use of the capabilities provided by the TPM it first has to connect to the device (see listing 5.1).
The arbitrary data will be sealed to a subset of the Platform Configuration Register (PCR) values. Therefore a PCR object has to be created, which will be filled with the chosen PCR values (see listing 5.2).
5. The Proof of Concept System
Listing 5.1: Connect to local TPM
23 /* Create context */ 24 i f ( contextCreate(&hContext) != TSS_SUCCESS) 25 /* Error handling */ 26 27 /* Connect to context */ 28 i f (contextConnect(hContext) != TSS_SUCCESS) 29 /* Error handling */ 30 31 /* Connect to local TPM */
32 i f (contextGetTpm(hContext , &hTpm) != TSS_SUCCESS)
33 /* Error handling */
Listing 5.2: Create PCR object
38 /* Create PCR object */
39 i f ( contextCreateObject (hContext , TSS_OBJECT_TYPE_PCRS, initFlag , &hPcrs) != TSS_SUCCESS)
40 /* Error handling */
41
42 /* Read PCR values from TPM */
43 for ( i = 0; i < selectedPcrsLen ; i++) {
44 i f (tpmPcrRead(hTpm, selectedPcrs [ i ] , &pcrSize , &pcrValue) != TSS_SUCCESS)
45 /* Error handling */
46
47 /* Set PCR values for PCR object */
48 i f (pcrcompositeSetPcrValue(hPcrs , selectedPcrs [ i ] , pcrSize , pcrValue) != TSS_SUCCESS)
49 /* Error handling */
50 }
51
52 i f ( initFlag ) {
53 UINT32 localityValue =
54 TPM_LOC_ZERO | TPM_LOC_ONE | TPM_LOC_TWO | TPM_LOC_THREE | TPM_LOC_FOUR;
55
56 /* Set locality information */
57 i f ( pcrcompositeSetPcrLocality (hPcrs , localityValue ) != TSS_SUCCESS)
58 /* Error handling */
5. The Proof of Concept System
A symmetric key is be used for the encryption of the arbitraty data, which is created securely inside of the TPM using the internal Random Number Generator (see listing 5.3).
Listing 5.3: Utilize RNG for the creation of a symmetric key
67 /* Get some random data for use as symmetric key */
68 i f (tpmGetRandom(hTpm, EVP_CIPHER_key_length(EVP_aes_256_cbc( ) ) , &randKey) != TSS_SUCCESS)
69 /* Error handling */
The symmetric key will be bound to the TPM. Therefore a new asymmetric key is created with the Storage Root Key (SRK) as parent key (see listing 5.4).
Listing 5.4: Create new asymmetric key object
75 /* Load the SRK */
76 i f (keyLoadKeyByUUID(hContext , TSS_PS_TYPE_SYSTEM, SRK_UUID, &hSrk) != TSS_SUCCESS)
77 /* Error handling */
78
79 /* Get the default policy for the SRK secret */
80 i f ( policyGet (hSrk , &hSrkPolicy ) != TSS_SUCCESS)
81 /* Error handling */
82
83 /* Set the secret for the policy */
84 i f ( policySetSecret (hSrkPolicy , (UINT32)pswd_len , (BYTE *)passwd) != TSS_SUCCESS)
85 /* Error handling */
86
87 /* Create a new RSA key object */
88 i f ( contextCreateObject (hContext , TSS_OBJECT_TYPE_RSAKEY, keyFlags , &hKey) != TSS_SUCCESS)
89 /* Error handling */
90
91 /* Create a new policy object for the RSA key object */
92 i f ( contextCreateObject (hContext , TSS_OBJECT_TYPE_POLICY, TSS_POLICY_USAGE, &hPolicy ) !=
TSS_SUCCESS)
93 /* Error handling */
94
95 /* Set the secret for the policy */
5. The Proof of Concept System
98
99 /* Assign the policy to the RSA key object */
100 i f ( policyAssign ( hPolicy , hKey) != TSS_SUCCESS)
101 /* Error handling */
102
103 /* Create the RSA key with SRK as parent key */
104 i f (keyCreateKey(hKey, hSrk , NULL_HPCRS) != TSS_SUCCESS)
105 /* Error handling */
106
107 /* Load the newly created RSA key */
108 i f (keyLoadKey(hKey, hSrk) != TSS_SUCCESS)
109 /* Error handling */
After the newly created key has been loaded, an encrypted data object is created that will hold the symmetric key. This key is then sealed with the asymmetric RSA key to the platform configuration (see listing 5.5).
5. The Proof of Concept System
Listing 5.5: Sealing of symmetric key
118 /* Create encrypted data object for the symmetric key */
119 i f ( contextCreateObject (hContext , TSS_OBJECT_TYPE_ENCDATA, TSS_ENCDATA_SEAL, &hEncdata) !=
TSS_SUCCESS)
120 /* Error handling */
121
122 /* Create a new policy object for the encrypted data object */
123 i f ( contextCreateObject (hContext , TSS_OBJECT_TYPE_POLICY, TSS_POLICY_USAGE, &hPolicy ) !=
TSS_SUCCESS)
124 /* Error handling */
125
126 /* Set the secret for the policy */
127 i f ( policySetSecret ( hPolicy , strlen (TPMSEAL_SECRET) , (BYTE *)TPMSEAL_SECRET) != TSS_SUCCESS)
128 /* Error handling */
129
130 /* Assign the policy to the encrypted data object */
131 i f ( policyAssign ( hPolicy , hEncdata) != TSS_SUCCESS)
132 /* Error handling */
133
134 /* Encrypt and seal the symmetric key */
135 i f ( dataSeal (hEncdata , hKey, EVP_CIPHER_key_length(EVP_aes_256_cbc( ) ) , randKey, hPcrs) !=
TSS_SUCCESS)
136 /* Error handling */
137
138 /* Get the encrypted data blob */
139 i f ( getAttribData (hEncdata , TSS_TSPATTRIB_ENCDATA_BLOB, TSS_TSPATTRIB_ENCDATABLOB_BLOB, &
encLen, &encKey) != TSS_SUCCESS)
140 /* Error handling */
141
142 /* Get the key blob */
143 i f ( getAttribData (hKey, TSS_TSPATTRIB_KEY_BLOB, TSS_TSPATTRIB_KEYBLOB_BLOB, &sealKeyLen , &
sealKey) != TSS_SUCCESS)
5. The Proof of Concept System
Finaly the context to the TPM is closed (see listing 5.6).
Listing 5.6: Close context to TPM
189 contextClose (hContext) ;
Besides the management and policy creation function, the GUI will also give an insight into how to program Trusted Computing aware applications, a concept that some of the interested customers of Kontron can pick up on, for the development of their own specific applications.
5.9. Summary
This chapter has described how the proposed security architecture of the research project was developed and implemented. The applied hardware and software components have been described in some detail. The proof-of-concept system has been developed on two different COM Modules from Kontron Embedded Modules GmbH, where each has a different type of TPM. Thus comparisons between COM Modules, TPM Modules, and Platform Policy Creation Tools have been made.
With the suggestions of some possible use cases and application fields, and a discussion on how to improve the usability of the proposed solution, an overview on the proof-of-concept system has been presented.