<story><title>TPM GPIO fail: How bad OEM firmware ruins Intel TPM security</title><url>https://mkukri.xyz/2024/06/01/tpm-gpio-fail.html</url></story><parent_chain><item><author>RedShift1</author><text>TPM seems beyond useless to me. I wanted to protect a certificate and private key for a Java application, so that you can&amp;#x27;t just copy the pkcs12 file and use it elsewhere, but there is no decent API in Java to use a TPM 2 chip. So the road ends there... The only protection now is a hardcoded passphrase in the application but you don&amp;#x27;t have to be a genius to figure that out...</text></item></parent_chain><comment><author>cryptonector</author><text>Discrete (i.e., &lt;i&gt;chip&lt;/i&gt;) TPMs (dTPMs) are &lt;i&gt;slow&lt;/i&gt;.  They are way too slow to use as HSMs.&lt;p&gt;Firmware TPMs (fTPMs) are faster, but I doubt they&amp;#x27;re really fast enough to use as an HSM.&lt;p&gt;There are TPM APIs for Java, so you &lt;i&gt;can&lt;/i&gt; do this, but it&amp;#x27;s not surprising that the Java keystore providers lack builtin support because of the performance issues.&lt;p&gt;Ideally fTPMs should come with EKcerts and platform certificates and they would be very fast and as secure as (more so than) dTPMs.  Then using fTPMs as HSMs might take off.</text></comment>
<story><title>TPM GPIO fail: How bad OEM firmware ruins Intel TPM security</title><url>https://mkukri.xyz/2024/06/01/tpm-gpio-fail.html</url></story><parent_chain><item><author>RedShift1</author><text>TPM seems beyond useless to me. I wanted to protect a certificate and private key for a Java application, so that you can&amp;#x27;t just copy the pkcs12 file and use it elsewhere, but there is no decent API in Java to use a TPM 2 chip. So the road ends there... The only protection now is a hardcoded passphrase in the application but you don&amp;#x27;t have to be a genius to figure that out...</text></item></parent_chain><comment><author>sim7c00</author><text>its meant for secureboot, but i suppose the rest of the platform, built usually by other ppl than ones who designed the TPM, needs to also implement it correctly. an d as this article shows, this is not an easy feat. (this attack seems silly but it&amp;#x27;s really clever tbh. good inspired idea likely based in lots of domain expertise).  - if you can protect the boot-chain with secureboot, what you can do for your private key, what for example AV vendors do, is have a (efi?)driver that contains the certificate, which is a boot-driver protected by secure-boot. - for windows this might require Microsoft cooperation to assign you a driver level so other stuff can&amp;#x27;t disable it (otherwise it&amp;#x27;s still tricky and possible to get around your protections likely).  (windows -&amp;gt; process protection light &amp;#x2F; telam drivers). Optionally you could also have the certificate provided by an EFI applcation somehow that&amp;#x27;s signed &amp;#x2F; secured by secureboot. (could drop it on disk somewhere, efi partition is easily accessible...).&lt;p&gt;If the chain is protected by the tpm, this method if implemented correctly through the whole chain should protect your cert and pkey.&lt;p&gt;that being said _should_ is the keyword,. i dont think any platform really managed to escape all attacks, though a lot in this area do need hw access (the tweezers previously implemented by the author :)).</text></comment>