TPM Performance :(

Benchmark and results

From YouTubers' cookies to Microsoft’s “crown jewels”, attackers are increasingly running off with secrets from compromised systems. The Trusted Platform Module (TPM) is one of the technologies designed to mitigate this.

TPMs have mainly been used for infrequent events (e.g. SSH logins and Microsoft Entra logins). With new and emerging standards like Demonstrating Proof of Possession and Device Bound Session Credentials, the TPM load is likely to increase. Ideally, every request should be protected by the TPM, which made me wonder:

Is TPM performance good enough to sign every request?

I could not find a good answer to this, so I wrote a benchmark and present the results here. Thanks to the people who provided performance numbers!

The Benchmark

Even though working with TPMs has become more accessible over the years, I still think the barrier to entry is too high. While Morten Linderud’s SSH TPM Agent was a great starting point, I ended up having to read parts of the TPM 2.0 Specification and patch Google’s go-tpm library to make my rather simple tpm-benchmark.

The benchmark records how many ECDSA P256 signatures, RSA 2048 signatures, and HMAC SHA256 invocations the TPM can perform per second.

The Results

As presented in Table 1 we can expect single digit signatures per second on most systems. This is pretty much the best case scenario using the same key for all the signatures, and no encryption of the TPM traffic. This is probably too slow to sign every web/application request, and it could add several hundred milliseconds of latency per request.

I’m only including results where the TPM commands were run sequentially. The benchmark has partial support to run in parallel, but it did not seem to help on the subset of system it was tested on.

Table 1: Benchmark results, invocations per second (no session encryption, 30 iterations, parallelism 1). EC is ECDSA P256 signature, RSA is RSA 2048 signature, HMAC is HMAC SHA256. All benchmarks were run on Linux. All the TPMs were distinct even if the model is the same - things like firmware versions and manufacturing year were not recorded, which might help explain the differences beyond that the platforms vary.

Chrome ran a study on TPM signatures, using ECDSA P256. The latency was 200ms for 50th percentile and 600ms for the 95th percentile. Assuming sequential execution this is 5 signatures and 1.7 signatures per second, receptively. While Chrome’s data set is probably orders of magnitude larger, at least they are qualitatively similar to Table 1.

HMAC is performing somewhat better - it does not have the non-repudiation property, but is better positioned to mitigate strong quantum computers. AWS’ extensive use of HMAC for authentication has been very successful.

Encrypting the traffic to the TPM has performance degradation as shown in Table 2. The main use case for session encryption is to prevent physical attacks (like BitLocker attacks).

Table 2: Same benchmark as Table 1 (invocations per second), but with different type of session encryption and only for the top performing TPM (Intel i5-1135G7). Session reuse establishes one TPM session that is reused across all the invocations, while the ephemeral sets up a new session per invocation.

So why is the TPM slow? In Davide Guerri’s 2017 FOSDEM talk, he says that the TPM is slow by design due to export laws. Whatever the case, these numbers limit how they can be used. The positive spin is to rate limit how many requests an attacker can perform from a compromised system.