Current Developments in SUSE TPM Packages

In this post I want to give you an overview about recent developments regarding TPM in general and improvements in the area of TPM software packages brought to you in SUSE Linux Enterprise 12 Service Pack 3. I will present our ongoing efforts in this area.

What is TPM?

TPM stands for Trusted Platform Module. It is a specialized cryptographic processor that’s shipped with most modern desktop, mobile and embedded devices. It has been designed to safely house private cryptographic keys. The keys never leave the TPM chip so the host processor and operating system can’t ever access these keys directly.

A TPM can be used to implement features like secure boot, Intel TXT, hard disk encryption, user authentication or verifying the identity of a remote host.

TPM Versions

There are two major versions of the TPM in existence, version 1.2 and version 2.0. In version 1.2 only SHA-1 (which is no longer safe) and RSA algorithms are mandatory. In version 2.0 more cryptographic algorithms are supported (most notably SHA256 and ECC (Elliptic Curve Cryptography)). Version 2.0 also introduces a concept called algorithm agility that allows the TPM to be more independent of the actual algorithms used and allows to add new algorithms as they become available or necessary.

Most current machines come equipped with a version 2.0 TPM. Some Firmware TPMs can also be updated to version 2.0. It is expected that the move to version 2.0 will happen quickly since Microsoft made TPM 2.0 mandatory for Windows 10 devices.

The TPM Software Stack

For interaction with the TPM a software stack is required. The Linux kernel only implements a small device driver that exposes the TPM chip as a character device, typically /dev/tpm0. A userspace software stack then communicates with the chip according to the standardized protocol.

TrouSerS TPM 1.2 Software Stack

To support TPM 1.2 chips we are shipping the TrouSerS stack since SUSE Linux Enterprise 11. This stack has been developed by IBM, but not much activity is going on there these days. We’ve brought minor version updates to SUSE Linux Enterprise 12 Service Pack 3, which includes the following packages:

• trousers, trousers-devel version 0.3.14: This contains the tcsd daemon which allows local or even remote applications to operate on the TPM device. The low level library libtspi allows to develop applications utilizing the TPM 1.2 chip.
• tpm-tools version 1.3.9.1: A collection of userspace utilities for interacting with the TPM 1.2 chip.
• openssl_tpm_engine version 0.4.2: An OpenSSL engine that allows to utilize the TPM chip transparently via OpenSSL for certain operations.

Intel tpm2-tss TPM 2.0 Software Stack

Intel is actively developing a software stack for TPM 2.0. We are shipping corresponding packages since SUSE Linux Enterprise 12 Service Pack 2 and just updated packages in Service Pack 3 which now ships the following:

• tpm-2-0-tss, tpm-2-0-tss-devel version 1.0: This contains the resourcemgr daemon which allows multiple applications to share the TPM 2.0 chip without conflicting with each other. Furthermore the low level libraries libsapi, libtcti-device and libtcti-socket are part of this package which allow to develop applications utilizing the TPM 2.0 chip. The tpm2-tss stack follows a layered model that provides multiple libraries for a clear separation of concerns.
• tpm2.0-tools version 2.0: A collection of userspace utilities for interacting with the TPM 2.0 chip.

There’s currently a lot of change going on in the tpm-2-0-tss project. The resourcemgr daemon previously contained in tpm-2-0-tss has been replaced by a new implementation written from scratch. The new one is called tpm2-abrmd (Access Broker and Resource Manager Daemon) and now lives in a separate GitHub project. This step became necessary, because the old daemon had design issues. Please note that the GitHub projects have been recently consistently renamed from carrying a tpm2.0 prefix to plain tpm2, which can be confusing.

We are currently preparing the switch to this new implementation for the next major update of SUSE Linux Enterprise. You can already have a look at it in our current openSUSE Tumbleweed, where an additional package tpm2.0-abrmd exists. Thankfully due to the abstraction employed in the software stack implementation the switch doesn’t hurt much. It is simply a new means of communication with the TPM.

Since the new resource manager daemon tpm2.0-abrmd impersonates a D-Bus service we also did a security review of the new package. D-Bus services can easily introduce security issues when not implemented carefully. In this case no major issues have been found and the quality of the new code is generally good. Still we did find some Denial-of-service possibilities during the review. A fruitful collaboration with the upstream developers made a quick bugfix release possible.

TPM in Practice

Making use of the features of the TPM in practical applications is attractive, because with it we can rely on cryptographically secured trust that is implemented in an isolated piece of hardware. A number of concerns with software based cryptography are no longer an issue. For example you no longer need to worry about keeping private keys secure, or what to do if they should be compromised. The interfaces of the TPM chip provide little attack surface and vulnerabilities in its implementation are less likely than in software solutions.

Nevertheless, the TPM is not very much utilized in open source software yet. One of the main reasons may be that it is still a complex topic to get into. The TPM specifications use a special terminology that newcomers can find hard to become familiar with. Also the specification documents can be difficult to navigate when trying to find a specific piece of information.

The TPM software stacks presented above closely follow the specifications and their terminology for obvious reasons. There is an additional feature API specification in the works that is supposed to make utilizing the TPM easier for typical use cases. It will take quite some more time for this specification to be finished or even be implemented in software, though.

Also by design the software stacks are kind of isolated bubbles that don’t interface well with other cryptographic software. The formats used are binary blobs that are considered only to be processed by the software stack and/or the TPM chip itself. Also migrating data between TPM chips requires special care to be taken, a topic that is addressed explicitly by the TPM specifications (migratable keys, portable data).

TPM Remote Attestation

An interesting feature of the TPM is the possibility of remote attestation. This allows to verify the identity and operational state of a remote host. For this a public/private RSA key pair called attestation identity key (AIK) is generated on the TPM. A remote host can then ask the TPM to issue a data structure signed with the private AIK. This operation is called a quote in TPM jargon.

The signed data structure contains a hash of the current configuration data stored in the TPM which typically consists of hashes of the host’s core components like firmware and kernel images. The remote host can then verify this data using the public AIK. This is a very secure way of verifying a remote host’s identity and integrity, which is interesting considering todays increase in (semi)automatic deployment of operating systems (virtual machines, cloud services) or devices (Internet of things).

For TPM 1.2 with TrouSerS we’ve recently added an additional package tpm-quote-tools to openSUSE Tumbleweed which contains tools for remote attestation on top of the regular tpm-tools. The tpm2.0-tools from tpm2-tss contain the tpm2_quote command for this purpose.

Personal Experience

I’ve looked into remote attestation in practice for myself to get a feel for it. Without going too much into details I can say that with both stacks it is still surprisingly complicated to extract a public key generated by the TPM in a common format. The OpenSSL PEM or DER format for RSA public keys would be a nice start. One way to achieve this is to use some magic numbers and dd.

I prefer programmatic and more defined ways of doing this. I’ve written a demo tool and some documentation that might help you in getting started with TPM quoting with TrouSerS. You can find it in my trousers-attestation GitHub project. For tpm2-tools I’ve proposed some additions to upstream (like an additional command tpm2_convert_key) to improve interoperability with OpenSSL. You can find them currently in my fork of tpm2-tools. Discussions with the maintainer about how this is best included upstream are still going on.

Conclusion

The industry is increasingly moving towards TPM 2.0 and we’re seeing much activity in the projects belonging to the tpm2-tss stack. The potential of the TPM is not yet fully unleashed, however, as the accessibility of specs and APIs leaves room for improvement.

With improved documentation, simpler tools and the feature API in the works we can hope to see broader use of the TPM in the future. In any case we at SUSE will continue to offer you up-to-date solutions for accessing TPM technology in our products.