TPM Sniffing(blog.scrt.ch)
blog.scrt.ch
TPM Sniffing
https://blog.scrt.ch/2021/11/15/tpm-sniffing/
65 comments
If TPM chips are not documented down to a die level and implementation is not verifiable then how can anyone trust them? If I created a honey pot device I'd also call it Trusted Platform Module.
Isn't the whole point of this project to ensure three letter agencies can extract keys and decrypt any device that comes their way?
Of course. It's all security theater at best/Microsoft bigcorp DRM at worst.
It does mean that your average attacker won't be able to decrypt your laptop, but you could have easily done that without a TPM.
It does mean that your average attacker won't be able to decrypt your laptop, but you could have easily done that without a TPM.
> TL;DR: we reproduced Denis Andzakovic’s proof-of-concept showing that it is possible to read and write data from a BitLocker-protected device (for instance, a stolen laptop) by sniffing the TPM key from the LCP bus.
See also the Dolos Group attack.
This isn't a trivial task (attaching probes to chip legs, or board connectors), and it's a good write-up, but sniffing seems like a poor word choice. This isn't picking up the data via covertly via existing attached components, or through some kind of software exploit - this is literally reading traveling messages which is nigh impossible to defend against aka "Reading data from the TPM"
Short of a physically sealed path from the chip to all components that benefit from its knowledge (impossible on a desktop?), that can only be destructively accessed (triggering an alarm; like case-open switches) - I don't see how this can be defended against.
Short of a physically sealed path from the chip to all components that benefit from its knowledge (impossible on a desktop?), that can only be destructively accessed (triggering an alarm; like case-open switches) - I don't see how this can be defended against.
TPM 2.0 allows communications over the bus to be encrypted specifically to prevent this attack, though Windows apparently does not actually use this feature[0].
Newer CPUs (since about 5 years ago) have the TPM embedded in the CPU. Intel calls this PTT and AMD calls it fTPM.
[0] https://pulsesecurity.co.nz/articles/TPM-sniffing
Newer CPUs (since about 5 years ago) have the TPM embedded in the CPU. Intel calls this PTT and AMD calls it fTPM.
[0] https://pulsesecurity.co.nz/articles/TPM-sniffing
The main problem is that you don't have a strong way of establishing that you're talking to the real TPM. It does raise the bar from passive interception to hardware MITM, but it doesn't absolutely solve the problem
It would if both the TPM and the chip talking to it use keys signed by the manufacturer. Then they could both verify the public signatures.
A public key for a fixedTPM+fixedParent primary on the TPM could be stored "securely" (i.e., read-only) on the host side, and then you can do key exchange with the TPM using RSA key transport or ECDH.
You can also use a shared secret, but storing a secret on the host side is even harder than storing a write-once (at factory), read-only PK.
You can also use a shared secret, but storing a secret on the host side is even harder than storing a write-once (at factory), read-only PK.
On intel systems at least the "firmware" tpm is really implemented in the PCH. It'd probably still be possible to sniff the i/o lines between the cpu & pch but still way more complex than between the tpm and cpu.
Where does the key come from if the communication is encrypted?
The process for establishing an encrypted session goes like this:
0: Know the public key of a fixedTPM+fixedParent primary key (e.g., the "endorsement key") on the TPM ahead of time[0].
1: call TPM2_CreatePrimary() in the clear to "create" that key (this is deterministic given a public template and factory seed secret to the TPM) -- you need the "handle" for this key
2: call TPM2_StartAuthSession() with that handle as the bindKey, and various other parameters
3: use that session in all subsequent commands.
Note: only one parameter of every command can be encrypted: the first parameter (command or response parameter) of type TPM2B_PRIVATE. The rest can be authenticated but are otherwise exchanged in plaintext. This is mostly just fine.
[0] Well, you could validate the EK's certificate, and then you only need to know the trust anchors for the TPM's vendor. It's roughly the same thing, but with more steps, and it lets you replace the TPM w/o having to re-learn a public key for it (which might be important).
0: Know the public key of a fixedTPM+fixedParent primary key (e.g., the "endorsement key") on the TPM ahead of time[0].
1: call TPM2_CreatePrimary() in the clear to "create" that key (this is deterministic given a public template and factory seed secret to the TPM) -- you need the "handle" for this key
2: call TPM2_StartAuthSession() with that handle as the bindKey, and various other parameters
3: use that session in all subsequent commands.
Note: only one parameter of every command can be encrypted: the first parameter (command or response parameter) of type TPM2B_PRIVATE. The rest can be authenticated but are otherwise exchanged in plaintext. This is mostly just fine.
[0] Well, you could validate the EK's certificate, and then you only need to know the trust anchors for the TPM's vendor. It's roughly the same thing, but with more steps, and it lets you replace the TPM w/o having to re-learn a public key for it (which might be important).
So who knows that key? The processor? Or the operating system?
What’s preventing an attacker from changing that key? Or is this just to change the attack from passive to active?
What’s preventing an attacker from changing that key? Or is this just to change the attack from passive to active?
The public key has to be known by the BMC, BIOS, OS.
You can read the public key from the TPM. If you're using the endorsement key, it comes with a certificate issued by the vendor.
You can read the public key from the TPM. If you're using the endorsement key, it comes with a certificate issued by the vendor.
This is complete speculation, but it could be like TLS.
That would make it much harder as you'd have to MITM the communication, not just sniff it. Maybe impossible to decrypt if both the TPM and the chip it's communicating with use keys signed by the manufacturer.
That would make it much harder as you'd have to MITM the communication, not just sniff it. Maybe impossible to decrypt if both the TPM and the chip it's communicating with use keys signed by the manufacturer.
I might ask "why speculate when you can go find out?", but in this case finding out is non-trivial. See above for an explanation though.
Your comment wasn't there when I speculated.
Sounds pretty similar to TLS to me, in my non-expert opinion.
Sounds pretty similar to TLS to me, in my non-expert opinion.
I think the difference with TLS is that, in the attacks the TPM should protect you from, the attacker controls the client and the network.
I don’t really see how it is possible to defend against that. But I don’t quite understand how the TPM checks what the CPU is doing either.
I don’t really see how it is possible to defend against that. But I don’t quite understand how the TPM checks what the CPU is doing either.
Disclaimer: I'm not an expert. At all.
I don't think it checks what the CPU is doing at all. It just makes software able to check if the platform is signed by the manufacturer.
The way I understand it is that the keys are burned into the TPM at time of manufacture, and there is no way to extract those keys, software can only ask the TPM to encrypt/decrypt/sign/verify certain data using the keys.
The TPM can then be used to verify certain operations, eg to retrieve the key for an encrypted hard drive.
But it's all a trojan horse because the manufacturer is the one who controls the keys, not the user.
It's "trusted" in the sense that the platform is "trusted" by the manufacturer, not the user.
I don't think it checks what the CPU is doing at all. It just makes software able to check if the platform is signed by the manufacturer.
The way I understand it is that the keys are burned into the TPM at time of manufacture, and there is no way to extract those keys, software can only ask the TPM to encrypt/decrypt/sign/verify certain data using the keys.
The TPM can then be used to verify certain operations, eg to retrieve the key for an encrypted hard drive.
But it's all a trojan horse because the manufacturer is the one who controls the keys, not the user.
It's "trusted" in the sense that the platform is "trusted" by the manufacturer, not the user.
It's not Windows that's the problem. It's the BMCs and BIOSes. They don't use encrypted sessions. They should.
You can combine it all in a chip like the Apple T2 and then you would have to somehow probe the silicon, which is of course impossible. (Until you discover that the chip has some critical, unfixable software vulnerability like the T2)
You can also pair the chip and the CPU at the factory or on initial powerup and have them communicate encrypted from thereon. This is a bit like the iPhone 13 display having some FaceID chip on it where a replacement with a wholly new display will leave FaceID non-functioning.
You can also pair the chip and the CPU at the factory or on initial powerup and have them communicate encrypted from thereon. This is a bit like the iPhone 13 display having some FaceID chip on it where a replacement with a wholly new display will leave FaceID non-functioning.
probing silicon is just hard and expensive, not impossible! - though those might be similar enough for most purposes
Machines cost tens of millions or more, renting time on them at least hundreds of thousands.
> You can combine it all in a chip like the Apple T2 and then you would have to somehow probe the silicon
For the T2, at least macOS uses a key derived from useryou need both chip control _and_ user password to get in)
Windows does not, relying instead on TPM only in a default BitLocker configuration. (with a PIN option via Group Policy, not part of the regular flow)
As of why that's bad: https://msrc.microsoft.com/update-guide/vulnerability/CVE-20...
For the T2, at least macOS uses a key derived from useryou need both chip control _and_ user password to get in)
Windows does not, relying instead on TPM only in a default BitLocker configuration. (with a PIN option via Group Policy, not part of the regular flow)
As of why that's bad: https://msrc.microsoft.com/update-guide/vulnerability/CVE-20...
It is difficult to probe but not at all impossible. However, you can sometimes extract keys by monitoring the chip power supply current over a large number of crypto operations. Much easier than probing the chip internals.
https://scholar.google.com/scholar?as_q=%22Differential+Powe...
https://scholar.google.com/scholar?as_q=%22Differential+Powe...
You can buy very small test clips for hooking on to TSSOP pins. They are kind of expensive and quite delicate, but come in handy if you do not want to solder on tiny wires.
https://www.ebay.com/itm/182107308498
https://www.ebay.com/itm/182107308498
If you want expensive check out what Pomona has to offer.
https://www.digikey.com/en/products/detail/pomona-electronic...
https://www.digikey.com/en/products/detail/pomona-electronic...
I smelled trouble the second I read "low transmission speed" and "25Mhz" in same sentence :) At that point picture of 30cm leads was a given.
“I mean it’s low speed interface, Michael. How fast could it go? 25MHz?”
“I mean it’s low speed interface, Michael. How fast could it go? 25MHz?”
They did say there were lots of errors in capture, but they got around it by capturing multiple times and figuring out which bits were captured incorrectly.
Instead of realizing 25MHz is awfully close to CB radio or RC cars, things what worked great with antennas around the length of my probe leads. :)
You should be careful about running software on your production domain controller.
Great write up.
Great write up.
pretty sure that was a joke. There was some dry humour sprinkled in throughout
Best mitigation against this isn't mentioned, which would be to use a built-in firmware TPM (fTPM). The fTPM may have other issues, but it would be a lot harder to probe the signals!
MS allows to use smartcards for Bitlocker, with a caveat that it can't be used for a system disk, only TPM can be used for that which seems arbitrary.
If there's an option to use TPM+PIN, then there should be an option to use smartcard+PIN.
If there's an option to use TPM+PIN, then there should be an option to use smartcard+PIN.
> only TPM can be used for that which seems arbitrary.
Smartcard readers can use any number of protocols (e.g. random USB readers implementing custom handshakes) until you finally get to the smartcard while TPMs have a select few number of protocols until you're talking to the TPM.
Arbitrary smartcard terminal drivers in your (secure) preboot software? maybe not.
Smartcard readers can use any number of protocols (e.g. random USB readers implementing custom handshakes) until you finally get to the smartcard while TPMs have a select few number of protocols until you're talking to the TPM.
Arbitrary smartcard terminal drivers in your (secure) preboot software? maybe not.
Majority of modern readers are CCID compatible, limit it to that.
libccid.so is 111KB, UsbccidDriver.dll is 81KB, I'm sure they would've managed if they wanted to.
https://en.wikipedia.org/wiki/CCID_(protocol)
libccid.so is 111KB, UsbccidDriver.dll is 81KB, I'm sure they would've managed if they wanted to.
https://en.wikipedia.org/wiki/CCID_(protocol)
Smartcard can't do self lockout at HW modification and other TPM features so not equivalent. Still, it should be able to use as additional key to password only BitLocker, but then maybe lack of Smartcard driver at UEFI is a blocker.
It doesn't have to be an equivalent to be an option. Just like having no encryption is an option or auto-unlocking is an option.
It's not like TPM detects that there are hardware changes, Windows itself does and it can lock it down. Or if there is some mechanism it doesn't seem to help in this case, so who is it stopping?
It's not like TPM detects that there are hardware changes, Windows itself does and it can lock it down. Or if there is some mechanism it doesn't seem to help in this case, so who is it stopping?
TPMs are notified about the system state along the boot process, so they can present the key only if the boot process looks like it's supposed to (and some of these attributes aren't even modifiable by the CPU but the side processor, e.g. Intel's "Management" Engine or AMD's "Security" Processor, so even taking over the x86 firmware doesn't help anymore)
Smartcards lack that data (they wouldn't know that somebody attached a Thunderbolt device that pretends to be a GPU but also comes with its own option ROM that installed a backdoor), so they serve a different threat model.
Smartcards lack that data (they wouldn't know that somebody attached a Thunderbolt device that pretends to be a GPU but also comes with its own option ROM that installed a backdoor), so they serve a different threat model.
And now the whole 'separate TPM' thing is obsolete, because newer processors will come with their own TPMs. This was a bad idea from the start if you ask me, with UEFI and shoving all sorts of things into it.
Does anyone make a "glass house" TPM? As in, a device that you can plug in to your motherboard's TPM port that implements the complete TPM 2.0 protocol, that looks/acts/feels like a real TPM, but then deliberately includes a side-channel like a USB port or something that gives a user full access to the TPM internals (keys, registers, etc.).
Obviously you'd never use something like this for trusted boot, but with Windows 11 requiring a TPM, and applications moving in the direction of "we refuse to run unless the environment is pristine" (e.g. video games with anti-cheat features, banking apps), it seems that something like this might eventually be useful for getting around DRM and restoring our ability to run whatever we want on machines that we own.
Obviously you'd never use something like this for trusted boot, but with Windows 11 requiring a TPM, and applications moving in the direction of "we refuse to run unless the environment is pristine" (e.g. video games with anti-cheat features, banking apps), it seems that something like this might eventually be useful for getting around DRM and restoring our ability to run whatever we want on machines that we own.
I think emulators have virtual TPMs which you can definitely inspect and manipulate the internal state of, and the specs are freely available so presumably anyone with some microcontroller/embedded experience can make one. The problem is that software is able to determine whether that TPM is an "approved" one, and that process being cryptographic, is going to be pretty hard to get past: https://en.wikipedia.org/wiki/Trusted_Platform_Module#Endors...
Ever since the beginning I have maintained the strong and unchanging opinion that everything TPM and "trusted computing" related is ultimately user-hostile and a threat to freedom, and it's disturbing to see that the worst nightmares are slowing becoming reality. It used to be drugs and terrorism. Now it's "security".
Ever since the beginning I have maintained the strong and unchanging opinion that everything TPM and "trusted computing" related is ultimately user-hostile and a threat to freedom, and it's disturbing to see that the worst nightmares are slowing becoming reality. It used to be drugs and terrorism. Now it's "security".
Yes, see libtpms for the most prominent software TPM implementation for emulators: https://github.com/stefanberger/libtpms
Wow, I didn't realize they still relied on a golden-key style root of trust... I assumed they were trust on first use. That seems pretty bad!
You can do trust on first use. Just... throw away the EK certificate and just trust the EK's public key. After all, you have physical access to the chip and... you trust your supply chain, right?
A TPM is useless without a keypair that the manufacturer signs for you. If any particular manufacturer would give you the option to just buy the keypair or make it possible to dump it somehow, they would surely get blacklisted.
This whole "trusted computing" thing is treachery to the highest degree.
This whole "trusted computing" thing is treachery to the highest degree.
TPMs come with factory "seeds" that can deterministically generate "primary keys" (which are RSA decryption keys, or ECDH key agreement keys).
One of those primary keys is the Endorsement Key (EK). The EK is generally certified by the TPM vendor, and they include that certificate in the TPM.
You can generate your own EKs and certify them. All you need to trust them is: a computer, a TPM chip you trust is legit (probably because you validated its factory EKcert), and physical security while extracting the public key of your EK'.
> If any particular manufacturer would give you the option to just buy the keypair or make it possible to dump it somehow, they would surely get blacklisted.
Yes, well, Internet-scale security (e.g., TLS) relies on the reputation of trusted third parties. The problem is that the too-big-to-fail phenomenon applies here too: what are you gonna do, stop using the one CA everyone uses, the three or four browsers everyone uses, the three OSes everyone uses?
> This whole "trusted computing" thing is treachery to the highest degree.
Oh, it's hard.
The lack of end-to-end security between the CPU and the TPM is pretty nasty. The solution is to use an on-CPU/ME firmware TPM that runs in the ME or in a secure enclave like solution -- no bus to tap there!
But even then, there's just no way to attest to the security of a long-running host. Yes, there's things like dynamic root of trust measurement, but by and large it's hard even to establish what would be a trusted state since, among other things, there's no authoritative list of trusted firmware ROMs or anything like that.
And, oh, right, you meant far beyond the realm of TPMs. Yes, "trust" is really weak.
One of those primary keys is the Endorsement Key (EK). The EK is generally certified by the TPM vendor, and they include that certificate in the TPM.
You can generate your own EKs and certify them. All you need to trust them is: a computer, a TPM chip you trust is legit (probably because you validated its factory EKcert), and physical security while extracting the public key of your EK'.
> If any particular manufacturer would give you the option to just buy the keypair or make it possible to dump it somehow, they would surely get blacklisted.
Yes, well, Internet-scale security (e.g., TLS) relies on the reputation of trusted third parties. The problem is that the too-big-to-fail phenomenon applies here too: what are you gonna do, stop using the one CA everyone uses, the three or four browsers everyone uses, the three OSes everyone uses?
> This whole "trusted computing" thing is treachery to the highest degree.
Oh, it's hard.
The lack of end-to-end security between the CPU and the TPM is pretty nasty. The solution is to use an on-CPU/ME firmware TPM that runs in the ME or in a secure enclave like solution -- no bus to tap there!
But even then, there's just no way to attest to the security of a long-running host. Yes, there's things like dynamic root of trust measurement, but by and large it's hard even to establish what would be a trusted state since, among other things, there's no authoritative list of trusted firmware ROMs or anything like that.
And, oh, right, you meant far beyond the realm of TPMs. Yes, "trust" is really weak.
> which are RSA decryption keys
Is RSA "decryption" key a thing? It should be a key pair that allows for both encryption and decryption (though you may just care about one use case).
Is RSA "decryption" key a thing? It should be a key pair that allows for both encryption and decryption (though you may just care about one use case).
You can encrypt to a RSA public key, then decrypt with the private key.
You can sign with an RSA private key, then validate the signature with the public key.
The two pairs of operations are very similar, but not quite the same due to differences in how padding is handled.
You can sign with an RSA private key, then validate the signature with the public key.
The two pairs of operations are very similar, but not quite the same due to differences in how padding is handled.
RSA is very slow for decryption. The general approach is tp use RSA to encrypt / decrypt the key of a symmetric encryption algorithm, that is much faster.
> Obviously you'd never use something like this for trusted boot, but with Windows 11 requiring a TPM, and applications moving in the direction of "we refuse to run unless the environment is pristine" (e.g. video games with anti-cheat features, banking apps), it seems that something like this might eventually be useful for getting around DRM and restoring our ability to run whatever we want on machines that we own.
Nobody uses TPMs for DRM and nobody will start to, because TPM modules have a terrible security record for getting breached, and your GPU already does anything a DRM vendor would want with more widespead support and a better track record for hiding the keys and integrating it with control of the display path.
Nobody uses TPMs for DRM and nobody will start to, because TPM modules have a terrible security record for getting breached, and your GPU already does anything a DRM vendor would want with more widespead support and a better track record for hiding the keys and integrating it with control of the display path.
[deleted]
These schematic shops... don't give them money. It would be different if they added any value at all, but I've seen no evidence of that - just a moneygrab. Here is what you do: use a DHT search engine to get the same thing. That is probably how they got it in the first place.
A query of "ThinkPad L440" on btdig yields the schematics and denies the scammers $20 - further denying funds to the DDoS SaaS or botnet rental they'd eventually have spend it on.
A query of "ThinkPad L440" on btdig yields the schematics and denies the scammers $20 - further denying funds to the DDoS SaaS or botnet rental they'd eventually have spend it on.
Easy way to find laptop schematics is by OEM name. In this case, Wistron LOS-1. It's sad that these "researchers" couldn't find it for free.[1]
further denying funds to the DDoS SaaS or botnet rental they'd eventually have spend it on.
That is unfounded fearmongering. I suspect at least some of the funds go to paying neighbourly employees working at said OEMs so they'll share more schematics. Most if not all the schematics you see available are leaks, after all.
[1] Maybe if they do come across companies leaking them, they'll be do-gooding and closing those "holes" (and effectively fighting against right-to-repair), so perhaps it's better that they didn't.
further denying funds to the DDoS SaaS or botnet rental they'd eventually have spend it on.
That is unfounded fearmongering. I suspect at least some of the funds go to paying neighbourly employees working at said OEMs so they'll share more schematics. Most if not all the schematics you see available are leaks, after all.
[1] Maybe if they do come across companies leaking them, they'll be do-gooding and closing those "holes" (and effectively fighting against right-to-repair), so perhaps it's better that they didn't.
> Easy way to find laptop schematics is by OEM name. In this case, Wistron LOS-1.
That is easier... now you just need to magically know the OEM name of the board!
> That is unfounded fearmongering.
No, it is pretty solidly founded in logic: these operations have nearly zero operating expenses - profit is a function of visibility. What other scumbag activities shares that same model? You think some of the viagra spam proceeds are getting reinvested into medical research as well? These sites always lag availability elsewhere - they aren't the source for anything.
That is easier... now you just need to magically know the OEM name of the board!
> That is unfounded fearmongering.
No, it is pretty solidly founded in logic: these operations have nearly zero operating expenses - profit is a function of visibility. What other scumbag activities shares that same model? You think some of the viagra spam proceeds are getting reinvested into medical research as well? These sites always lag availability elsewhere - they aren't the source for anything.
How did you learn that Wistron LOS-1 is the name for L 440?
The sites that sell them will also have the OEM name; and it's often written on the motherboard itself.
There's a number of issues with discrete TPMs and physical security. Before I describe them, there is good news: some CPUs can run a firmware TPM in an ME or a secure enclave, and using it does not involve a bus on a motherboard that could be hacked into. The problems with discrete TPMs:
- the BMC and BIOS don't use encrypted sessions -- their communications with the TPM can be snooped (read: bitlocker keys can be stolen) and tampered with (read: malware can be excluded from PCR measurements with the help of a physical attacker)
- to authenticate the TPM when using encrypted sessions the BMC and BIOS would need to be able to store a public key for the TPM somewhere that isn't easy for malware to tamper with -- this means that even with encryption there would be a TPM impersonation / MITM attack
- even using encrypted sessions, if the attacker can force the TPM to reset without also resetting the CPU, then the attacker can make the PCRs match golden state (i.e., without the malware measured into the PCRs)
The first point is easy enough to address -- it's just a matter of code.
The second point is very difficult to address.
The third point would probably require changes to the CPU and additional design and standardization. It's just very difficult to strongly bind the TPM's resetCount to the CPU's state to ensure that both always reset together.
The only current solution to all three problems is to use firmware TPMs (fTPMs) where available.
Of course, for things like servers in secure racks in secure data centers, this is all really not a problem. But for laptops, it is.
If an fTPM is not available, there's always the possibility of adding physical protection to the bus (burying it deeper in the PCB, using resin, etc.).
- the BMC and BIOS don't use encrypted sessions -- their communications with the TPM can be snooped (read: bitlocker keys can be stolen) and tampered with (read: malware can be excluded from PCR measurements with the help of a physical attacker)
- to authenticate the TPM when using encrypted sessions the BMC and BIOS would need to be able to store a public key for the TPM somewhere that isn't easy for malware to tamper with -- this means that even with encryption there would be a TPM impersonation / MITM attack
- even using encrypted sessions, if the attacker can force the TPM to reset without also resetting the CPU, then the attacker can make the PCRs match golden state (i.e., without the malware measured into the PCRs)
The first point is easy enough to address -- it's just a matter of code.
The second point is very difficult to address.
The third point would probably require changes to the CPU and additional design and standardization. It's just very difficult to strongly bind the TPM's resetCount to the CPU's state to ensure that both always reset together.
The only current solution to all three problems is to use firmware TPMs (fTPMs) where available.
Of course, for things like servers in secure racks in secure data centers, this is all really not a problem. But for laptops, it is.
If an fTPM is not available, there's always the possibility of adding physical protection to the bus (burying it deeper in the PCB, using resin, etc.).
You can authenticate to a TPM via HMAC and a shared secret key, so also the two other points can be addressed with code.
The catch is that the other elements need to be able to store the secret, and they need to "pair" to the TPM when the motherboard is assembled. Also, scenarios concerning the legitimate replacement of the CPU need to be addressed. Those are all key management tasks that manufacturers are not good at in general... so here we are with unauthenticated sessions...
The catch is that the other elements need to be able to store the secret, and they need to "pair" to the TPM when the motherboard is assembled. Also, scenarios concerning the legitimate replacement of the CPU need to be addressed. Those are all key management tasks that manufacturers are not good at in general... so here we are with unauthenticated sessions...
> You can authenticate to a TPM via HMAC and a shared secret key, ...
> The catch is that the other elements need to be able to store the secret...
Yes, that catch is the problem.
You can also authenticate the TPM to the host w/o authenticating the host to the TPM -- all you need is to be able to record the public key of a suitable primary (say, the EK) on the TPM that has fixedTPM and fixedParent set. Less messy than having to store a secret on the host, but not really enough to solve the reset issue.
> The catch is that the other elements need to be able to store the secret...
Yes, that catch is the problem.
You can also authenticate the TPM to the host w/o authenticating the host to the TPM -- all you need is to be able to record the public key of a suitable primary (say, the EK) on the TPM that has fixedTPM and fixedParent set. Less messy than having to store a secret on the host, but not really enough to solve the reset issue.
>the space between each pin is only 0.65 millimeters (for our metrically impaired readers, this is 0.4 millionths of a mile).
Lol, hilarious.
Lol, hilarious.
> Now, if (1) you have the correct equipment and (2) you’re confident in your micro-soldering skills, you can solder wires directly on these pins to attach the probes, but the space between each pin is only 0.65 millimeters (for our metrically impaired readers, this is 0.4 millionths of a mile). We did not meet several of these two requirements.
LOL.
LOL.
LPC is not a secure bus. TPM on LPC bus without Parameter Encryption enabled is not protected against Man-in-the-middle attacks. I recommend SafeBoot and TPM.dev for more information.