[PATCH] enhanced smartcard support

[David Smith]

OK, I'll try to provide a bit of a howto and answer a few things that
are kind of strange at first.

Jouni Malinen <j at w1.fi> writes:

> On Fri, May 23, 2008 at 11:47:28AM +0300, Jouni Malinen wrote:
>
>> My ThinkPad T43 should have TPM, but getting it working was not exactly
>> trivial and I don't know whether the security chip is now more or less
>> completely locked or what it is doing since it does not likely any
>> passwords/PINs..
>
> I finally found a way to clear the security chip state through BIOS
> (after some odd magic to get the BIOS setup to show the option for doing
> this) and I tried again.

In order to get the BIOS to show the 'clear the TPM chip option' in the
Security settings, you need to do a cold powerdown and then enter the
BIOS on the first boot. A regular reboot will not suffice. This is
because it is written in the TCG specification for the PC platform, in a
normal computer doing a cold power-off and power-on is the only way to
assert physical presence, and physical presence is required to clear the
chip. If you think about it a bit, this makes sense, e.g. if the machine
was on something like a cyclades hydra that allowed accessing the BIOS
remotely after a normal reboot. Though, it is of course not perfect,
because again the cyclades hydra case, some models allow you to control
the power strip the machine is using and force a cold power-cycle
operation remotely. But, in most cases, a cold power-cycle is a
reasonably good approximation of physical access to the machine, and you
want to make sure the TPM does not get reset without you physically
doing it. In other words, it is completely impossible to clear the TPM
chip after you boot your operating system, no matter what operating it
is, because the last thing the BIOS does before starting the boot-loader
in a TPM-based system is disable the assertion of physical presence.

> This time, I just used a simple password/pin for every possible
> location to avoid any possible issue and tpm_takeownership and
> tpmtoken_init were able to complete their tasks.

OK, but in order to use the TPM chip as a smart card, you must set the
SRK password for tpm_takeownership to nothing, just hit enter at the
password prompts for the SRK password. Set your owner password to
whatever you like. You have to run tpm_takeownership once and *only*
once after clearing your TPM chip in the BIOS but you can, after that,
clear the token created on the thip as many times as you like from
software. The token, as created with tpmtoken_init, is a
software-emulated smartcard that is backed by a private key that lives
inside the TPM. All of the keys used with that smartcard are wrapped
with the private key inside of the TPM. Since they are wrapped
(i.e. encrypted) with a private key that you can't get access to, they
are safe to store on disk and in fact this is how it is done, in a
relatively simple binary database in /var/lib/opencryptoki/tpm.

Regarding tpmtoken_init, I've only used it briefly and found it limiting
in functionality and unreliable, though I've yet to find a really good
generic pkcs11 swiss-army-chainsaw and intend to make one ... one of
these days. Instead, I use pkcs11-tool from the OpenSC package and
pkcsconf from the openCryptoki package together. Note that tpmtoken_init
comes from the tpm-tools package, a part of the trousers suite.

Below is a shell fragment that is based on a program I use for
initializing the TPM chip. I've taken out a few bits of user-interface
and integration with my CA environment for attaining a signed
certificate from a CSR and just left the basics of the TPM
initialization, assuming you have a certificate and private key ready to
be imported. Specify the certificate and private key at the top of the
script. I don't suggest running the script without reading it completely
first.


#!/bin/sh
cert=/path/to/your/certificate.der
# CERTIFICATE MUST BE IN DER FORMAT, convert before running this script
privkey=/path/to/your/private.key.der
# PRIVATE KEY MUST BE IN DER FORMAT, convert before running this script.
cat <<EOF

You will be prompted for two passwords, one called the owner
password and the next called the SRK password.

For the owner password, use whatever you like. This password is
yours for controlling the TPM chip.

For the SRK password, please hit enter twice. This password
must be empty in order for software to make use of the TPM
chip.
EOF
sudo tpm_takeownership

label="IBM PKCS#11 TPM Token"
module="--module /usr/lib/opencryptoki/libopencryptoki.so.0"

echo "Showing slot information"
sudo pkcs11-tool $module --list-slots

echo "You should see a TPM token listed as a possible slot above."
echo "Continuing..."
echo "Initializing token"
sudo pkcs11-tool $module --init-token --label $label --so-pin 87654321

echo "Setting SO PIN to 111111"
sudo pkcsconf -c 0 -P -S 87654321 -n 111111

echo "Setting User PIN to 000000"
sudo pkcsconf -c 0 -p -U 12345678 -n 000000

auth="--pin 000000 --so-pin 111111"
echo "Installing certificate object"
sudo pkcs11-tool $module $auth --write-object $cert --type cert --id 1 --label "certificate" --attr-from $cert

echo "Installing key object"
sudo pkcs11-tool $module $auth --write-object $key --type privkey --id 1 --label "priate key" --attr-from $cert

echo "Showing object information"
sudo pkcs11-tool $module $auth --list-objects

echo "You should see a ceritifcate and private key listed as installed in the smartcard"

>
> For the first test, I just imported couple of certificates and a private
> key to the TPM token with pkcs11-tool. This does not sound like the best
> way of using TPM since I would prefer not to see the private key ever
> exit the security chip, but for the time being, importing existing keys
> seemed simpler. Should probably try to generate a certificate request
> with TPM engine to avoid the private key being exposed.

Certificates are by definition public information so they can be
exported again after importing with pkcs11-tool, but private keys
cannot. Only the object information can be attained, but assuming RSA
keys which is almost always the case, the modulii, exponents, or bases
of the keys can not be recovered nor can any other actual private
information. For added security, before importing with pkcs11-tool,
create the certificate request, get it signed, and run pkcs11-tool on it
all from a ramfs and add traps to delete the files from the ramfs and
unmount it as traps in the shell script.

> I tried configuring the private key, user certificate, and CA
> certificate from the OpenSSL engine and that seemed to work and I was
> able to complete EAP-TLS authentication successfully.

That's very encouraging.
 
> For some reason, this is painfully slow and I needed to increase the
> authentication timeout in eapol_test from the default 30 to couple of
> minutes to avoid timeouts.. I don't understand why it would need that
> much time, but well, it did. Anyway, at least the mechanism of
> fetching certificates from tpm/pkcs11 token seemed to work fine.

I have not seen that behavior and, for now, doubt it is due to the TPM
chip, because someone else was complaining about a very similar issue
with a different model smartcard being used with OpenSC and an earlier
version of wpa_supplicant. Additionally, I don't, for now, see a
connection between that kind of behavior and the functionality added by
this latest patch, which should only be for exporting certificates out
of the smartcard and serving them from memory when requested by the
authenticator. [/me searches his mail...] Ah, David Mattes, he even
offered me one of his smartcards to test with to debug this
problem. Unfortunately, I haven't found the time yet to invest in taking
him up on the offer. I've added him to the CC on this mail and hopefully
he can shed some light on this issue.

Cheers,
dds

<#secure method=pgpmime mode=sign>