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.
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.
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.
>It's possible to change out the crystal for a higher frequency
You can't access the internals of a TPM by design.
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.
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.
My employer requires at least an 18-digit PIN, and not just numbers, either.
Depending on how serious you are you also don't consider MacOS.
And then you kinda have a couple of things to chose from but ultimately you need to build your own security depending on your attack/threat model
But also, threat models and the best way to mitigate them aren't really a linear scale of being <unserious> to <serious>, but a complex consideration of a particular situation.
Back in the late 1980s it was clear that it would be no problem at all to hook up a hard drive to a digital phone exchange and record all the calls! I had a strict policy of "don't talk about anything illegal using electronic communication" even when it was rather banal stuff like selling weed.
The carelessness of people at Facebook documenting policies that nobody in their right mind would document boggles my mind: you might as well leave it mysterious why you didn't crack down on scam ads, for instance. When I've been involved in minor conspiracies, say when we had an HR problem with another employee, I've always made the point to meet furtively in person and avoid leaving a paper trail so that I'd never need to explain an email I wrote in front of an unfriendly audience.