Home Made TPM2.0 Module | Hacker News Reader

Home Made TPM2.0 Module

diy.viktak.com

143 pointsrcarmo71 comments

I guess you could build a simple "stub" TPM using an arduino nano that just speaks enough of the TPM protocol to make Windows happy. It would have to store some bits of binary data somewhere, and maybe have to implement some basic cryptogrphic routines, but I guess it could be possible?

It's possible, but it is _a lot_ of work!

You'd basically be building a cryptographic module (industry standard term, with a lot of specs and requirements to go a long with it), which is no small undertaking in terms of correctness, never mind security. The "basic" cryptographic routines aren't easy either. You're talking ECC and some other symmetric primitives. Secure & efficient ECC implementation is an entire discipline on it's own.

I have reservations about the phrase "don't roll your own cryptography" for lots of reasons, but this would be taking rolling your own to the extreme. With all the associated risks.

Absolutely possible and a very cool project, but yeah, it's hard to understate the complexity / requirements of a full cryptographic module on top of the cryptographic primitives it needs to support. I actually really like that this person took an existing commercial TPM and could integrate it into their own PCB this way, I think that's a good compromise between building your own TPM with an Arduino, and having to pay lots of money for an out-of-the-box TPM.

One reasonable way to do this could involve running the reference TPM2 simulator [0] on the Arduino. It's just a C library that already implements all the cryptographic routines and TPM2 commands. In fact, this is basically how TPM vendors implement their chips. They just generally have:

  - A lot more hardening against physical attacks
  - Cryptographic libraries optimized for their low-resource hardware
  - (sometimes) a vendor certificate for a primary TPM key, aka an "EK cert"

Certainly a TPM running on an Arduino wouldn't have the physical hardware properties of a "real" TPM. But you could probably get it into a state with similar software properties.

[0] https://github.com/microsoft/ms-tpm-20-ref

I'd use this over a real TPM so that I have more control over my PC.

> "It's possible, but it is _a lot_ of work!"

How do you know it's _a lot_ of work? Correct me if I'm wrong, since you are implying you are familiar with this, but doesn't Windows 11 just want to verify that the device is available, likely with an echo facsimile along the lines of a version or self-test response? I don't believe any version of Windows requires full TPM functionality.

See my other comment: https://news.ycombinator.com/item?id=31293577

It really depends on what your threat model is and whether you intend to use the TPM to begin with. If not, you really don't care about the security of any cryptography as long as the output is valid enough to satisfy whatever application is using the TPM.

Creating an adversarial relationship between the user and vendor is a debasement of security principles. Now, Windows is the threat model and that's why "mandating" this was the wrong choice altogether. Microsoft could even have sold this as a feature. The fact that they chose instead to push it on users tells you everything you need to know about the future of users' relationship with their products. The perimeter of my security ends where Microsoft begins.

It could be interesting in terms of debugging and reverse engineering. Seeing what secrets apps are storing. Normally you don't have full view on what's in your TPM as an end user.

Of course it'll be hard to make it really secure but production use isn't the only place this could come in handy.

Yeah, but the point of having a TPM isn't just to have hardware capable of storing keys and doing some cryptography (so you can e.g. sign a challenge without exposing the private key) but also an hardware that makes extracting the keys from it hard. With an Arduino you can get the first part, but I don't think you can also make it tamper resistant or tamper evident. But still a device that could be interesting to play with, just be aware of the reduced grade of security that you get

It isn't blanket reduced security. Rolling your own greatly reduces the odds of a supply chain attack on a simple, unauditable, single-point-of-failure piece of security hardware.

It really depends on what your threat model is.

For most people, the threat model is primarily malware attacks, against which even a homebrew TPM will protect. Ideally you'd want something that literally can't be reprogrammed from the host, but even then, since it's a custom-made device an attacker would need to manually reverse-engineer it to attack it so you'd still be safe against anything but a targeted attack.

Of course, this assumes you even care about using the TPM in the first place. If you just want to satisfy Windows' requirement then security is not a concern at all.

I don't agree about malware protection: a TPM woukd protect you from malware in the sense that it would prevent a malware from getting your keys, but currently the most widespread form of malware are ransomware for which a TPM can't do anything. Also attackers are rarely interested in getting your cryptographic keys, usually they are interested in getting your login details for some service, for which they use phishing

Still, an outside observer would be able to tell you faked it, because the endorsement key certificate would be signed by you and not a “real” manufacturer.

I wonder if Windows checks it though.

An outside observer should not have access to your TPM.

Why would you do that when it's easy to disable the install-time check?

All you have to do is hit Shift-F10 when the installer tells you the machine isn't compatible, launch regedit, create the key HKEY_LOCAL_MACHINE\SYSTEM\Setup\LabConfig. And then add a DWORD value called BypassTPMCheck and set it to 1 (BypassSecureBootCheck is also an available option)

I'm not sure win11 will accept to update if you do that. Or it is just when it detects an "unsupported" processor?

Windows 11 can update without peoblems with unsupported hardware. The only thing that's different is a warning in the settings. One Microsoft employee even used a 7th gen Intel CPU during an official screencast.

Windows 11 currently has no trouble running or updating on my Sandy Bridge MacBook Pro[1]. Not only does the machine have no TPM whatsoever, it's booting Windows 11 in BIOS mode because its firmware doesn't properly initialize the GPU when booting Windows in UEFI mode.

To install Windows 11 for BIOS boot, I replaced the install.wim image on Windows 10 BIOS-compatible boot media with the analogous image from a Windows 11 ISO.

I also used Thunderbolt target disk mode to run the first installation stage under VMware Fusion on another Mac because the MacBook Pro's firmware wouldn't boot Windows USB installation media in BIOS mode, but this would presumably not be required if I'd had recordable DVD media on hand at the time.

Note that I say "currently" because there's obviously no guarantee that Microsoft won't break Windows on older hardware in an update, so I'm not relying on this install for anything critical.

[1] MacBook Pro (17-inch, Early 2011) a.k.a. MacBookPro8,3; "second-generation" Intel Core i7 CPU (viz., i7-2720QM).

Hi! I'm curious what made you go through all this trouble just for Windows 11 and was it worth it in the end?

Edit: I ask this question, but then remember my own `do-dist-upgrade` hellscapes... They were never worth that in the end lo

Related: a lot of AMD CPUs these days come with "fTPM", which is AMD's built-in TPM solution, voiding the need for an external module. Intel has something similar that I forgot the name of, though I don't know if they've released it into the mainstream yet.

Indeed, the blog post is an interesting read, but the premise is mistaken. Windows 11 is satisfied with TPM that is based in an AMD or Intel chip (arguably, that is even more secure than a discrete chip).

https://support.microsoft.com/en-us/windows/enable-tpm-2-0-o...

Even for Intel, it's been around since 2016 (Skylake).

But support depends on system/motherboard.

Despite not appearing on the CPU (i7-5557U, Broadwell) datasheet, my NUC5i7RYH supports TPM 2.0 after enabling "Intel Platform Trust Technology" in the BIOS, so at least in some cases, this goes back further than Skylake.

Severe system stuttering while utilizing AMD fTPM has been one of the top complaints about Windows 11 up until now.

I read that the problem manifested only intermittently, which of course can be annoying enough. Supposedly AMD will be issuing a BIOS/UEFI update in May.

Not only that, but TPM chips are hopelessly physically insecure because of bootstrapping issues. But firmware TPMs (fTPMs), which run in a secure enclave or ME, do not have those issues at all.

The bootstrapping issues are namely that the BMC and BIOS don't necessarily and securely know a public key for the TPM they're talking to, so generally they don't even bother encrypting sessions to the TPM, and even if they did, they'd be subject to MITM attacks as long as they don't know the TPM's public key a priori. The attacks on bootstrapping do require physical access, so it's not exactly the end of the world, but it's still not good. But again, fTPMs don't have these problems because the communications between the CPU and the fTPM are on-die, so there is no external bus that could be used for mounting an attack.

He has an H370 which means at least an 8th gen Intel or newer. There's TPM built into the CPU since Skylake and the motherboard should have an option to enable it if it supports regular TPM (usually there's a discrete TPM/fTPM option).

It's a nice DIY but completely unnecessary.

Yep, I have an older 6th+7th gen Intel processor Gigabyte MB (GA-Z270XP-SLI) and it has the option (Intel Platform Trust Technologies under Peripherals).

Is it possible to make your own TPM 2.0 chip? Or at least hardware that emulates the chip?

Or are there root secret keys or something that requires certification and very expensive membership to a professional body and NDA agreements to access?

That's the whole point of a TPM/Pluton/etc, remote attestation and corporate control over people.

I don't believe so - QEMU and proprietary hypervisors can emulate TPMs just fine.

Only if you want someone special to trust your hardware, then it requires effort. Otherwise not.

It depends on how the TPM is being used by the OS and its apps. If it’s purely being used for the crypto key storage and crypto operations, then you can probably use something like the MS reference implementation [0]. If the OS requires attestation and endorsement, there is a manufacturer key pair that is embedded into the chip that you can use to attest and verify that the TPM you are interacting with is indeed from a particular manufacturer. That aspect would not be doable for an emulated DIY TPM.

[0] https://github.com/microsoft/ms-tpm-20-ref

https://docs.microsoft.com/en-us/windows-server/identity/ad-...

This link has some useful details on attestation.

For a lot of software you should be able to still use a custom TPM since you could use the EKPub based attestation which is per-device. This would allow you to bake your custom key into the device prior to installation and then whitelist it.

I'm by no means an expert but since this is mostly handled at the OS level, provided you control the infra you should be able to roll your own custom TPM and still support attestation & endorsement. So if you are dealing with this on your own personal hardware or in your company (and you have IT's blessing), you should be able to do it but it won't work out of the box.

Software emulation https://github.com/stefanberger/swtpm

with bugs https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=tpm

https://tpm.fail/ https://github.com/VernamLab/TPM-Fail

The Bob Rudis bit explains TPM shouldnt be relied on. https://www.forbes.com/sites/daveywinder/2021/10/16/critical...

fTPMs can be relied on. dTPMs can't be, but mainly because of bootstrapping issues that keep the BMC/BIOS from using encrypted and audit sessions to protect against passive and active on-bus attacks.

EDIT: Regarding side-channel attacks, presumably fTPMs that have such vulnerabilities can be fixed. dTPMs can also get firmware updates, but I'm not sure that every dTPM side-channel vulnerability is fixable -- it might depend on the chip's hardware capabilities, though the STM one in the TPM-FAIL attack was fixed.

> fTPMs can be relied on. dTPMs can't be, but mainly because of bootstrapping issues that keep the BMC/BIOS from using encrypted and audit sessions to protect against passive and active on-bus attacks.

Microsoft seems to disagree with you.

https://docs.microsoft.com/en-us/windows/iot-core/secure-you...

Firmware TPM (fTPM) requires special Processor/SoC support that is not currently implemented on Raspberry Pi 2 or 3. MinnowBoard Max needs firmware version 0.80 or higher. DragonBoard410c provides fTPM capabilities out of the box enabled by default.

Discrete TPM (dTPM) is considered the utmost trustworthy solution by all means

Software TPM (sTPM) is also referred to as TPM Simulator. It is platform-independent, supported on Windows IoT Core. sTPM is intended for development purposes only and does not provide any real security benefits.

Chips are just as vulnerable, but its currently harder and not impossible to hack them.

Well, they're wrong. The problem is that unless the BMC and BIOS doing all the TPM2_PCR_Extend() calls are securely (like, on some bit of memory or register that apps can't get to until much later when the secure boot sequence has completed) recording the TPM's resetCount or an audit digest of their commands, then an attacker can reset the TPM at a later point and extend the PCRs with values that are approved, and none will be the wiser.

Another problem is that reading out a bitlocker key from the TPM after satisfying a policy is nice, but if it is not read over an encrypted session, then it can be read by any physical attacker than can watch the bus.

The fundamental problem, ultimately, is that in order to defeat the bus attacks, the BMC and BIOS and early OS boot stages need secure volatile storage for storing the TPM's resetCount, and long-term non-volatile storage for storing the public key of some primary on the TPM for keying encrypted sessions. An fTPM has no external bus to worry about. Ergo fTPMs are fine.

Half these problems would go away if we went back to a single core cpu.

Very interesting. My motherboard has a TPM header but MSI sold at most 100 TPMs for it and then changed the spec (LPC to I2C if I recall correctly), never producing them again. Because TPM pinouts differ per manufacturer despite using the same physical connector (because of course they do) it's not quite so easy to take a widely available TPM and use it, even if it speaks the same protocol.

This might be a good solution for this. I can also see more opportunities for TPM customisation. For example, with a few leads you could lead the header to a connector outside the case and use the TPM containing the LUKS/Bitlocker key as a portable device safety guarantee; a hacky Yubikey for disk encryption, if you will. Depending on the OS you may even get away with swapping out the TPM between boots, giving you a different set of credentials.

TPMs can also be used for some more obscure stuff. With the right library you can use them for things like storing certificate authorities or providing SSH authorization through private keys. Getting proper TPMs into the hands of the people can make for some very interesting experiments.

I'm no master solderer so I probably won't solder my own TPM chip. Still, this is a very cool project!

> TPMs can also be used for some more obscure stuff.

One cool example is the Intel Education Theft Deterrent solution, used in school laptops handed out by some governments.

They added a lock function to the BIOS code which checks the (hardware) TPM for signed data.

During normal operation, the computer receives a "boot certificate" through an always-on OS agent application from a server physically located in school grounds and accessible only through their intranet. This signed certificate contains, among other things, a boot count (how many reboots until the PC gets locked) and an expiration date (how much time until it gets locked).

The idea is that thiefs will not risk taking the computers because they would be unoperable within a few days/reboots, since the data is stored in the TPM and the lock code is in the BIOS itself.

This turned out to be a disaster however, as most technical people just modded the BIOS to strip out the system altogether and made easily available tutorials on how to use an EEPROM flasher to load the patched binary. The end result is that, due to bad IT personnel in schools among other factors, legitimate users got their laptops locked all the time while thiefs easily flashed the patch and got them working in minutes.

There is a whole network of people selling bios chips on ebay.

theoretically they're for if you brick your machine with a bad update.

Practically, they're used by thieves to give a machine a new serial number, unlock any bios passwords and disable theft prevention and tracking features.

This wouldn’t be possible with a Secure Core branded machine. TCB launch prevents unsigned BIOSes

I thought TCB leveraged a UEFI featureset to start a chain of trust in the OS initialization. If the UEFI code itself isn't there, how is it going to run?

TCB is just a standard to provide a Trusted Computing Base for zero trust environments from the hardware up. Basically, the UEFI BIOS is signed, and cannot be tampered with. If it is, the machine won’t boot

Good article, however there's a small part that's incorrect:

> Although this technology is not new (it was introduced in Windows 10 and Windows Server 2016)

TPM support was introduced to Windows as early as Windows 7

Win 8 specifically with support backported to Win 7.

Are you sure? I remember trying to use BitLocker way before Windows 8 was a thing and it complaining that I didn't have a TPM.

I'm not sure for TPM2 though.

Anyone know of TPMs supporting Ed25519? I've yet to even find any such chips so far.

You’d have to bug the TCG to add it to the spec.

It was added as TPM_ALG_EDDSA in revision 1.32 [0].

[0] https://trustedcomputinggroup.org/wp-content/uploads/TCG-_Al...

Superficially, you should be able to make a fully compliant TPM2 on your own like this (unless I’m missing something). The one gap would be that your EK Cert would have to be self signed.

I don't think that Windows 11 requires any sort of EK cert at all. If they did, it would require them to restrict the TPMs to a list of "approved" vendors.

In this case, they bought the actual TPM2 part of the chip from Infinion, so it might already have an EK Cert on it.

Well, that’s what I get for skimming poorly. They did just slap an off the shelf infineon chip in, so yeah, real EKcert from a legit vendor.

I skimmed and had some wishful thinking that they just made a cheap off the shelf chip do the job of a TPM2 by slamming in an existing TPM2 implementation.

> I skimmed and had some wishful thinking that they just made a cheap off the shelf chip do the job of a TPM2 by slamming in an existing TPM2 implementation.

Is there any evidence that it wouldn't be possible - does Windows have a list of approved EK certificate authorities it expects?

The only reason I could think for this would be DRM, but I wouldn't expect this to be a requirement merely to install the OS (the un-approved TPM would still be good for any non-DRM uses, and would be useful in VMs where the TPM is already emulated by the hypervisor).

You can also run your own CA for your home-made TPMs' EKpubs.

Cool hardware hack but not necessary for most computers to run Windows 11. Most BIOS have a software emulation of TPM that Windows is happy to use.

Small correction: the TPM you're talking about is actually provided by the processor; the BIOS merely exposes an interface to it.

Excuse my ignorance, but what is a TPM Module? I've never heard of it, what does it do?

This is easily Google'able [1], but here you go: https://support.microsoft.com/en-us/topic/what-is-tpm-705f24...

[1]: https://googlethatforyou.com?q=TPM%20Module

I think the reason for asking the question here, rather than Letting Me Google That For Me, is that that it can lead to interesting conversation, especially since many HN conversations seem to have one or more subject matter experts drop in and explain something.

Another reason is that many of the explanations are little more than industry advertisements, that obfuscate the function of a TPM behind euphemistic or circuitous language.

It's a "Trusted Platform Module". The high level summary is that it's a chip that sits inside your computer that is designed to only allow only signed code to run.

The computer's manufacturer loads it with a special certificate, so when the computer tries to boot, the bootloader has to include a signature signed with that initial certificate. This bootloader can in turn contain the next certificate to verify the operating system is signed correctly, the operating system in turn contains certificates that verify that user applications are signed correctly.

In theory this is a sound idea, in practice things and implementations are a lot more messy.

I’m no expert, but to me it sounds like you are describing UEFI Secure Boot, not TPM.

Case in point: TPM is not required to implement UEFI Secure Boot. You can test yourself in a QEMU VM, if you don’t believe me.

From my understanding, TPM is just a separate crypto-module meant to keep the keys secret even from the CPU and OS itself, allowing you to do various crypto and security related things with higher confidence of the keys not getting leaked.

Applications includes passwordless disk-encryption (MS BitLocker) but also hard-to-crack DRM, making the TPM a somewhat controversial piece if hardware.

Someone please correct me if I’m wrong or my answer is inaccurate in any way ;)

As someone who's spent too much time with this stuff, you're correct. The TPM (either 1.2 or 2.0) is an entirely _passive_ chip. It only creates keys or measures data if the OS or UEFI asks it to. This means that it can't block or modify programs on your CPU.

Secure Boot is implemented by UEFI, so it can block the loading of a particular bootloader. You can have Secure Boot without a TPM or have a TPM without Secure Boot. They can be useful together though as you can have a disk-encryption key with a policy saying "I can only decrypt stuff if you've booted using Secure Boot in a particular configuration".

As for DRM, the TPM doesn't work very well as part of a DRM solution (as it's entirely passive). This is probably why very few (if any) DRM products use TPM. Most PC DRM that I've heard of either uses Windows Kernel modules or Intel SGX.

> Case in point: TPM is not required to implement UEFI Secure Boot. You can test yourself in a QEMU VM, if you don’t believe me.

I believe you, but doesn't that mean that there is nothing particular secure about this operation ?

But thank you for the correction, I was under the impression that secure boot neccessarily needs a TPM to store it's keys.

> but doesn't that mean that there is nothing particular secure about this operation ?

Not at all. The trusted signing-certificates don’t need to be stored securely since they only contain public keys.

This is typically stored in NVRAM or EFI-variables.

Check out this: https://google.github.io/tpm-js/

Computerphile made a great video explaining TPMs: https://youtu.be/RW2zHvVO09g

at this point it feels more important to have an working tpm emulator like swtpm in all major linux distributions as a package so we can play freely with it until we all understand it.

that said: cool project.

Reply on news.ycombinator.com