Item — HN Reader

Because the TPM effectively rate limits brute forcing of the key.

https://learn.microsoft.com/en-us/windows/security/hardware-...

> For example, when BitLocker is used with a TPM + PIN configuration, the number of PIN guesses is limited over time. A TPM 2.0 in this example could be configured to allow only 32 PIN guesses immediately, and then only one more guess every two hours. This totals a maximum of about 4,415 guesses per year. If the PIN is four digits, all 9999 possible PIN combinations could be attempted in a little over two years.

2 comments

In that case, the median would still be just over a month, if the PINs were entered in order of how commonly they are used. Even the worst case of two years is still soon enough for a lot of data still be useful.

Also, how is the time limit enforced? With hardware access, it would be easy to change time or increase the clock rate, as well as many other side-channel attacks that could eliminate the wait altogether.

The time limit is enforced by the TPM itself which defends against tampering.

I found some pictures of TPM modules with crystal oscillators, so those could keep time while powered on, but wouldn't be able to keep time while off. It would be possible to only count time while on, but that would be really annoying to a legitimate user that kept turning off the computer, waiting for the time limit to expire, especially if it doesn't tell the user how much time is left.

Anyway, crystal oscillators connect to one input pin and one output pin, with an internal feedback circuit that causes the crystal to resonate. It's possible to change out the crystal for a higher frequency, or even directly drive the input pin for a much higher frequency. Semiconductor manufacturers often only characterize the limit of the feedback circuit, but not the limit of the internal clock circuitry when directly driven. Considering that the logic design supports an SPI bus running up to tens of megahertz, it's totally possible that the crystal input could be driven at a similar speed, possible a thousand times faster than a normal real-time clock oscillator.

There would be several ways to mitigate such an attack, but a quick search for TPM side-channel attacks brings up multiple much simpler vulnerabilities, so it's not likely that TPM manufacturers are putting any real effort into mitigation.

The TPM can have a lockout counter that it decrements over time.

>It's possible to change out the crystal for a higher frequency

You can't access the internals of a TPM by design.

Most enterprises require a 12 digit code, to meet a specific security standard. Bruteforcing that, with hardware access restricted by TPM, would take a very, very long time.

You're also not restricted to 4 digits. A full passphrase is an option.

Which I wish was more heavily advertised because a passphrase is a lot easier to remember.

> the TPM effectively rate limits

I had a friend working at trusted compute at Microsoft, and he had so many stories.

These TPM firmwares are often written by shitty companies that have no fxcking clue what they are doing.

Most TPM implementations are a clown show, companies just want to check a box on paper so they say "look! We have a TPM!" and move on.

A quick search for "TPM side-channel attack" substantiates that claim.

Looking at the manufacturers of TPM ICs, it makes sense. Most of them make microcontrollers that have code-protect bits in them that are notorious for being susceptible to simple side channel attacks, but also for not being a target simply because no one cares about the object code on any random product's microcontroller.

I worked at a company that sold a microcontroller that executed from external memory, so there was no possible way to have built-in code protect bits, and some potential customers complained until we included a library to encrypt the external memory, run a small unencrypted bootloader which included the a plain-text decryption key, then run the encrypted program. That checked their box, despite doing nothing useful.