TrouSerS FAQ

Info on TrouSerS and Trusted Computing. Please send comments, new questions and corrections to trousers-users@lists.sf.net.

1.0 - TrouSerS

2.0 - Trusted Computing

3.0 - General

4.0 - Glossary

5.0 - The tpm-tools package

1.0 - TrouSerS

1.1 - What is TrouSerS and where can I download it?

TrouSerS is an CPL (Common Public License) licensed Trusted Computing Software Stack. Today, we're working towards compliance with the TSS 1.1 specification, but will begin work on complying with the 1.2 spec as soon as its released.

You can get the latest version here.

1.2 - What Operating Systems are supported?

As of this writing, TrouSerS is supported on i386 GNU/Linux. The majority of testing is happening on SuSE 9.1/9.2 and Fedora Core 3 systems, but full testing will be also be done on RHEL4 and SLES9 systems. As of this writing, TPMs are not shipping on platforms other than i386.

1.3 - What are the requirements to run TrouSerS?

For information on building TrouSerS, see the README file.

1.4 - Where should I ask for help?

First, try searching the mailing lists here. If you don't find an answer to your question there, post it to one of the mailing lists. For questions on development of trousers itself, use trousers-tech@lists.sourceforge.net and for questions on using the TSS API or building/installing TrouSerS, use trousers-users@lists.sourceforge.net.

1.5 - I have a TPM. What can I use TrouSerS for?

TPM services provided through the TSS API are:
o RSA key pair generation
o RSA encryption and decryption using PKCS v1.5 and OAEP padding
o RSA sign/verify
o Extend data into the TPM's PCRs and log these events
o Seal data to arbitrary PCRs
o Random Number Generation
o RSA key storage

1.6 - If I want to write an app that uses TrouSerS, do I need to certify it somewhere?

No. There is no certification process for trusted computing apps. Any app you write can be licensed any way you see fit and you can distribute that app according to the terms of that license, without other restrictions.

1.7 - I've taken ownership of my TPM under another OS...

If you've already taken ownership of your TPM using a TSS under another operating system, there are a few issues you should be aware of.

Auth vs No-Auth SRK: In order to trick trousers into thinking it has taken ownership of the TPM it's running on, you will need to create a persistent storage file for trousers to use. Normally trousers would create this file itself at the time ownership is taken. If your SRK has been given an authorization password by the other OS, you will need to copy the file dist/system.data.auth (from a 0.2.4+ trousers tarball) to /usr/local/var/lib/tpm/system.data. If you've taken ownership of your TPM without issuing a password, move dist/system.data.noauth to /usr/local/var/lib/tpm/system.data.

Passwords: When entering passwords for keys you'd like to use in both Linux and other OS's, you'll need to take note of how you entered those passwords. The TSS spec states that when a password is entered through a GUI popup dialog box provided by the TSS library, the password should be converted to the UTF-16 encoding and then hashed using SHA-1, including the UTF-16 null terminator in the hash calculation.

In order to work around this problem, specify the -u option to the tpm-tools command line to convert the password to UTF-16 before hashing. This, however, unfolds yet another problem...

Some TSS stacks aren't compliant with the TSS spec, in that they hash their passwords without including the terminating null character. This means that there are effectively two versions of any password set through a popup dialog box. Trousers will include the terminating null character in its hashes of UTF-16 data.

UPDATE

In order to work around the UTF-16 NULL terminator problem, the TrouSerS 1.1 TSS (versions 0.2.5+) supports the TSS_TSPATTRIB_SECRET_HASH_MODE attribute of context and policy objects. This attribute is a TSS 1.2 feature that has been backported to the TrouSerS 1.1 stack. In order to force TrouSerS to ignore the terminating NULL character on all its popup dialog created passwords, you can use the following code:

Tspi_Context_Create(&hContext);

Tspi_SetAttribUint32(hContext, TSS_TSPATTRIB_SECRET_HASH_MODE,
		     0, TSS_TSPATTRIB_HASH_MODE_NOT_NULL);
From this point on in your app, all policy objects, whether created explicitly or implicitly, will ignore the terminating NULL character in the passwords received through popup dialogs. This attribute can also be set on a per-policy object basis, by setting the same attribute on the policy object.

Here's a chart outlining reports on how TSS's behave. Please submit new findings to trousers-users@lists.sourceforge.net.

Vendor Software Behavior
NTRU Core TCG Software Stack (CTSS) Popup passwords: UTF-8.
IBM TrouSerS Popup passwords:
  • TrouSerS 0.2 (TSS 1.1): UTF-16LE, null terminator included by default (version 0.2.4+) and controllable through TSS_TSPATTRIB_SECRET_HASH_MODE (version 0.2.5+).
  • TrouSerS 0.3.X (TSS 1.2): UTF-16LE, null terminator not included by default, controllable through TSS_TSPATTRIB_SECRET_HASH_MODE.
Infineon / HP HP ProtectTools/Infineon TPM drivers Popup passwords: UTF-16, no null terminator included.
IBM IBM Client Security Software Popup passwords: UTF-16 with NULL terminator, hashed twice.
Wave Systems EMBASSY(r) Trust Suite v2.0.51.0 - Vista platform UTF-16, no NULL terminator included.

1.8 - Explain TrouSerS spec compliance to me.

By default, TrouSerS doesn't comply with the TSS spec, in order to do 4 things:

1) Work with differently abled hardware
2) Work by default in environments with and without GUIs
3) Enable 64bit apps to work with a 1.1 TSS
4) Interoperate with other TSS's

1.9 - Where exactly does TrouSerS break the spec?

4 places.

1) Policies by default will be created with their secret mode set to TSS_SECRET_MODE_NONE, as opposed to TSS_SECRET_MODE_POPUP. This means that if you're in a GUI environment and your application doesn't set a policy's secret where it should, you will get TSS_E_POLICY_NO_SECRET, instead of a popup window asking for a secret. In a non-GUI environment and your application doesn't set a policy's secret where it should, you will get TSS_E_POLICY_NO_SECRET, instead of TSS_E_INTERNAL_ERROR when the TSS tries to launch its popup. The application is of course still free to set its policies to TSS_SECRET_MODE_POPUP manually.

2) In Tspi_TPM_SetStatus, you can by default pass physical presence commands down to the TCS. The TCS will check what runlevel your machine is in and if you're in single user mode, you will be allowed execute the physical presence command. This will enable hardware without BIOS support for the TPM to enable, disable and clear the TPM. Note that on hardware with BIOS support, these commands have no effect.

3) The 1.1 TrouSerS TSS (versions 0.2.5+) support TSS 1.2 style callbacks. In the TSS 1.1b spec, callbacks are set using a constant width, 32-bit field in Tspi_SetAttribUint32. This kept 64bit applications from being able to set callbacks. So, to enable 64bit TSS 1.1 apps, TrouSerS by default has support for TSS 1.2 style callbacks.

UPDATED

4) The 1.1 TrouSerS TSS (versions 0.2.5+) support the TSS 1.2 attribute for controlling the NULL terminating data of passwords. See section 1.7 for details.
All other non-spec compliant behavior in TrouSerS should be treated as a bug and should be reported here.

1.10 - How do I enable strict spec compliance mode in TrouSerS?

./configure --enable-strict-spec-compliance

2.0 - Trusted Computing

2.1 - What is remote attestation?

Remote attestation is a way to prove to a challenger that you're truly running the software on your computer that you say you are. The general idea involves a few steps. 1. A challenger obtains a certificate from a trusted certificate authority which claims you have a valid TPM on your machine. 2. The challenger sends a request to your computer to attest to its software state. 3. Your machine then sends back a list of PCRs and their states, signed by the certificate. 4. The challenger then compares the signed list of PCRs with a table showing valid or acceptable states for a machine he'd like to interact with. From there, he must make a decision as to whether or not he'd like to interoperate with your machine.

To begin the process of obtaining a certificate based on your TPM, the following dependencies must be met:


So, to enable the generation of an AIK, several things must happen:

1. A hash of your Public Endorsement Key must be made at the time your TPM is manufactured. This will allow a Privacy CA to verify that the key you're requesting a certificate for is truly generated by a TPM.

2. Privacy CA's must come into existence.

3. TPM manufacturers need to provide the credentials that the TSS Stack needs to generate the TPM identity.

Once there is a uniform way for TPM manufacturers to deliver the various credentials to the platforms that ship their TPMs, TrouSerS will read in these credentials and use them to generate what's called a TPM identity. This identity will then be able to be bound to a TPM key, which can then be sent to a Privacy CA, who will verify the key and issue a certificate based on it.

2.2 - Does Trusted Computing lock me out of being able to boot my custom kernel?

No, and additionally, this functionality does not exist. Many technical, infrastructural and procedural hurdles exist to providing this functionality (See the question on remote attestation, for an example of some hurdles). Will this technology ever exist? Probably not on platforms other than closed, proprietary systems such as kiosks or cash registers. There are cultural and political forces barring adoption of technology that takes away the individual's right to use their general purpose computer as they see fit. Also, there's no economic incentive to forcably limiting general purpose computing. Without even addressing Trusted Computing, the ability to lock users out of a general purpose computer depends more on political factors than technological ones.

2.3 - What happens to all my encrypted data when the TPM on my mainboard dies?

There are a few different scenarios here.

A) Your data is bound to your TPM.
1. Your data is protected by a non-migratable key. In this case, you are hosed.

2. Your data is protected by a migratable key, which you have backed up. In this case you can import the backed up key to a new TPM and decrypt your data.
B) Your data is sealed to your TPM.
Your data is protected by a non-migratable key. You are hosed. (Data cannot be sealed with a non-migratable key).

2.4 - Will having a TPM on my box keep me from running a free BIOS?

No. However, installing a free BIOS on your machine with a TPM currently breaks what's called the "chain of trust". The TPM could still be used in the same way you'd use a smartcard, but attestation for example would be broken. If a free BIOS implementation implemented the steps necessary to maintain the chain of trust (which is possible today), all functionality could be maintained with a free BIOS. At attestation time however, a challenger may decide not to trust your machine if its running a free BIOS. Conversely, a network of machines could be created that only trust machines running free BIOS's.

2.5 - Will the TPM take control of my machine?

No. A TPM cannot execute code in the way that a CPU executes code. Once initialized, you can send the TPM command data and it will return you response data. Without software running on your machine that is TPM aware, the TPM is useless to you.

3.0 - General

3.1 - If I install TrouSerS can others tell what software I'm running?

No. There are 2 problems here. One, the infrastructure surrounding remote attestation has not yet been created (See Section 2.1). Two, by default, TrouSerS denies all remote TSP requests.

3.2 - What does TrouSerS have to do with digitally signed kernel modules?

Right now, nothing. All the code in TrouSerS runs in user space, to be compliant with the TSS spec. An LSM that signs and verifies kernel modules would need to be implemented alongside (or perhaps in place of) TrouSerS. The problem is that calling directly to the TPM from inside the kernel violates the TSS spec, which states that the TCSd should be the only interface to the device driver for the TPM.

3.3 - Is the TPM a cryptographic accelerator?

No. The TPM was not intended to be a cryptographic accelerator and in fact software is many times faster than a TPM. Using the TPM as just a device to offload your crypto to would basically be a waste of time. Although you would probably use fewer CPU instructions to transfer the data to and from the TPM than you would to say, generate a 2048 bit RSA key, it would be much, much slower. The TPM was also designed to be on all kinds of devices, which means it needs to be able to be manufactured cheaply. This probably has had a hand in keeping it slow, too.

3.4 - Is the TPM chip itself tamper resistant?

No. The TPM chip itself will detect that it has been physically tanpered with, but will only report this by setting a bit inside the chip. This bit can be read by software, but the TPM will not auto-disable itself, zero any of its internal memory, or otherwise self-destruct in any way. The TPM is not designed to protect against attacks from the platform owner, that is, the person who owns the physical machine that the TPM resides on.

4.0 - Glossary

4.1 - Trusted Platform Module (TPM)

The Trusted Platform Module (TPM) is a piece of hardware or software that provides the ability to do several things. It provides the ability to securely protect and store keys and data in general. The TPM enables more secure storage of data by doing its asymmetric key operations on-chip (using its own hardware random number generator). It provides hardware-based protection of data because the private key used to protect the data is never exposed in the clear outside of the TPM's own internal memory area. Additionally, the key is only valid on the TPM on which it was created unless migrated by the user to a new TPM.

The TPM also provides functionality to securely store hash values (in PCRs) that represent platform configuration information. The secure reporting of these values, if authorized by the TPM owner, enables verifiable attestation of a platform configuration (see remote attestation). Data can also be protected by these values (binding) as well as requiring the platform to be in the same configuration to access the data as when the data was first protected (sealing).

4.2 - Platform Configuration Register (PCR)

A Platform Configuration Register (PCR) is an area of memory inside a TPM that's used to store cryptographic hashes of data. Today most PCRs are 160 bits long in order to hold the data from a SHA-1 hash.

4.3 - Attestation Identity Key (AIK)

An Attestation Identity Key is a key created for use in attestation. At creation time, it gets tied to a TPM identity, which is in turn tied to a TPM's Endorsement Key (EK). In this way, the AIK can be proven to be created by a genuine TPM without exposing any part of the EK, which would be a privacy concern. There are still some privacy concerns using AIK's if your Privacy CA and the person who's verifying your attestation can collude. That's why Direct Anonymous Attestation (DAA) was included in the TPM 1.2 spec. When TrouSerS supports DAA, I'll include a section here on it.

4.4 - Data Binding

Bound data is data that has been encrypted by a TPM using a key that is part of its root of trust for storage. Since the root of trust of storage is different for every TPM, the data can only be decrypted by the TPM that originally encrypted the data. If the key used is a migratable key, however, then it can be migrated to the root of trust for storage of a different TPM allowing the data to be decrypted by a different TPM.

4.5 - Data Sealing

Sealed data is bound data that additionally records the values of selected PCRs at the time the data is encrypted. In addition to the restrictions associated with bound data, sealed data can only be decrypted when the selected PCRs have the same values they had at the time of encryption.

4.6 - Endorsement Key (EK)

The Endorsement Key is a 2048 bit RSA key pair generated on each TPM. The EK is generated at TPM manufacture time and cannot be modified afterwards. Since each EK uniquely identifies a machine, there are a lot of privacy concerns surrounding the EK. This is why the concept of an AIK was created.

5.0 - The tpm-tools package

5.1 - Can I use tpm_clear to clear the owner on my TPM?

The short answer is probably not. If your machine has a TCG aware BIOS (which standard IBM Thinkpad, NetVista, and ThinkCentre BIOS are) it locks physical presence at the end of BIOS and you will not have access to the necessary functions to be able to complete this task from userspace. This is the prefered setup as allowing access to physical presence is a security risk.

To clear your TPM in this situation, power on the machine with the Fn key (for IBM Thinkpad) or Ctrl key(for IBM desktop) held down, release the key and enter the BIOS, navigate to the security panel, under Security chip select "Clear encryption keys" and set the value to yes. This method will work even if you have tried to use tpm-clear and are now getting errors such as TPM disabled or TPM deactivated.

Without a TCG aware BIOS you can use the tpm_clear command and as the notice at the completion of the command directs you the command requires you to re-enable and re-activate your TPM to get back to a fully functional mode of operation. These commands are protected by physical presence (see next question).

5.2 - How do I get physical presence for physical presence authorized commands?

Short answer, if you have TCG aware BIOS you must use BIOS and all physical presence operations must be negotiated from there (see previous question for more info about this).

Without a TCG aware BIOS you can use the tpm_setpresence command with the appropriate flags. Trousers will only allow this command from single user mode. For example, to enable and activate a TPM after a tpm_clear, you would:

1) telinit S or boot to single user mode
2) ifup lo
3) start tcsd
4) tpm_setpresence --assert
5) tpm_setenable --enable --force
6) tpm_setactive --activate --force
7) reboot

SourceForge.net Logo