[1] https://en.wikipedia.org/wiki/Next-Generation_Secure_Computi...
[1] https://en.wikipedia.org/wiki/Next-Generation_Secure_Computi...
Your beef is with things like Pluton, Intel’s ME and AMD’s PSP.
TPM at their base are nothing else than a more secure place to store cryptographic data.
Don't get me wrong, it's not a major issue for me, it's just uncomfortable. It just means I prefer my machines to not have TPM hardware in them.
That's my major problem with it; it locks you out of messing with your own machine data, which you can see being instantly abused by third parties to prevent modifications.
As far as I can tell, as a software developer you have full access to the chip. The only thing you can’t do with them (by design) is read the signing keys or generate secure boot attestations for machines which didn’t secure boot. I think you can even replace the signing keys entirely if you want to.
They aren’t a hard drive. They don’t store your data. And unfortunately I don’t think they’ll do much to prevent software bugs from causing problems. Particularly in the operating system, where software bugs can undermine the entire chain of trust model.
Don’t get me wrong; the idea of getting my computer to cryptographically prove it’s running in some locked down Xbox mode to be allowed to play Netflix or do online banking is quite the ask. The hackability of computers is one of their best features and I don’t want that genie to go back in the bottle.
But every time the conversation comes up there’s so much misinformation about them. People conflate tpm chips with intel’s management engine (which is secret and closed source), Apple’s secure enclosure (which I think can store some data?) and other stuff that works really differently.
That's why it makes me nervous.
If you replace the manufacturer’s signing keys with some keys you generated yourself, the only real effect is that your computer can no longer do remote attestations. So you can no longer convince any 3rd parties that your computer is operating in a “secure” mode.
It locks everybody, including the owner, out of any data it doesn't own. That's the point. If you can pull it out, so can anybody else, and you've just made a small hard drive. Could it be used by vendors for DRM-like things? Sure. That's on the vendor, though, and not the technology itself.
And that's the problem. I have little actual trust of vendors anymore. Too many bridges have been burned to trust by default.
The entire point of a TPM is ensuring that private keys intended for a specific device are never leakable off of that device.
Now that being said, there is an additional function of TPMs that is more controversial, and that's how it can be used by the CPU and firmware to refuse to execute code when a chain of attestation coming from a root key stored in the TPM is not satisfied. That controversy is very valid for TPMs or other "enclave" devices which do not allow the system owner to change those root keys. And of course there is the extended ability to leverage this attestation over a network, to allow a _server_ to be able to refuse service if the attestation is not valid.
When the user can change the root attestation keys, I think local attestation is a net positive for the security of the user. When they cannot, it means that only the "blessed" builds from the hardware manufacturer can run. This second case should be made illegal in my opinion.
Though there's nuance here, remote attestation however is a net negative for the user. Taken to it's logical conclusion where unattested access is 100% refused without exceptions, it means that the user effectively cannot run their own software on devices that they own, and that is not acceptable. It also ensures that the user can only use hardware devices that the service provider deems as allowed, which is the more practical and likely outcome at scale.
Remote attestation is what's at issue with WEI (and indeed things like Google Play Integrity and the equivalent feature of Apple's iOS stack), not the ability to ensure that private keys cannot be leaked.
Right, which means software can engage in encryption that I can't decrypt because I can't get the keys.
You're right, RA (when the user can't change the keys) is a much more concerning thing. It can be used to prevent me from exerting full control over my own hardware.
My problem with TPM isn't really the TPM itself, it's that I have very little trust in software and so want to be able to keep a close eye on it and audit things as needed. I want to be able to do things like decrypt data streams sent over the wire, etc.
And, as I said, this is a relatively minor thing for me. Even writing as much about it as I have puts more emphasis on it than I would prefer. In practice, the majority of the software that I use doesn't even want to use the TPM, so it's all good.
Also, you know, GNU.
> Sometimes a few of the users try to hold total power over all the rest. For example, in 1984, a few users at the MIT AI lab decided to seize power by changing the operator password on the Twenex system and keeping it secret from everyone else. (I was able to thwart this coup and give power back to the users by patching the kernel, but I wouldn't know how to do that in Unix.)
> However, occasionally the rulers do tell someone. Under the usual su mechanism, once someone learns the root password who sympathizes with the ordinary users, he or she can tell the rest. The "wheel group" feature would make this impossible, and thus cement the power of the rulers.
> I'm on the side of the masses, not that of the rulers. If you are used to supporting the bosses and sysadmins in whatever they do, you might find this idea strange at first.
He was talking about a time-sharing system in an academic context. We have no idea what his thoughts are now, and it's logically fallacious to discount his feelings on what multinational corporations bake into their silicon on the basis of an experience that he had back when Van Halen was still topping the charts. It isn't exactly a secret that RMS is a bit "out there" - lots of historically-significant people are. Contextualizing their work and speech in a constructive way is preferable to writing them off wholesale.
[1] https://ftp.gnu.org/old-gnu/Manuals/coreutils-4.5.4/html_nod...
One which you, as the owner, don't have the keys to.
One which nobody, not even the owner, can extract keys from. I don't understand why people don't like the fact that they can't pull keys out of the TPM. If you, the owner, can pull them so can anybody else. I know TPMs aren't invulnerable but you have to admit they significantly raise the bar of compromise.
You can:
- set passwords on the key hierarchies
- roll the seeds for the key hierarchies,
thus invalidating *all* keys on the TPM
Now, Windows might stop working if you do that, and naturally, if you wanted to use a TPM for locking your filesystems then you'll need to do this _before_ you install your OS.Also, once you change the seed for the Endorsement Key hierarchy you'll lose the ability to prove that the TPM is a legit TPM made by whatever legit TPM vendor.
So sure, this is only something you do if you know what you're doing, especially if the TPM is soldered onto the motherboard.
Which is totally what happened, right? /s
We're getting closer to that with things like "secure" boot. Fortunately that can still be disabled, but MS even required that on ARM platforms it can't. The bigger Linux distros have bent over and gotten MS to sign their bootloaders, essentially making them at the mercy of MS.
https://wiki.debian.org/SecureBoot#What_is_UEFI_Secure_Boot_...
Some BIOSes let you enter your own Secure Boot keys (like my desktop and laptop), but not all.
At this point I think it’s firmly FUD and the people who say it’s coming any second now need to put up the evidence. Microsoft doesn’t seem to care, especially now that Windows is an afterthought to Azure, O365, etc.
I think the point, at least for me, is that they shouldn't be taking away any user control for consumer products. And yet that is what we have let them do. Its not going to stop.
> If you keep track of the changes to the BIOS firmware, you can see the changes. Their minuscule but happening. We don't have full blow preventing from disabling secure boot yet, but it appears to me that's were this is going.
Case in point: until recently, even with SecureBoot enabled by default, you could boot Linux distributions which have their bootloader signed by Microsoft, without going into the firmware setup screen. Nowadays, at least with some Lenovo models, you have to go to the firmware setup screen, and either enable a cryptically named option or disable SecureBoot. A quick web search gave me https://www.omglinux.com/boot-linux-modern-lenovo-thinkpads-... which has a screenshot, and which mentions that this is a new Microsoft requirement (instead of something Lenovo came up with).
Also, from that link is a somewhat notable cultural nugget:
"For their part Lenovo intimate that it is "
Fortunately, this one went nowhere. But the same concept could be repeated on x64.
Nowadays all non-mobile aarch64 devices I used, and even many mobile ones, let you boot your own unsigned kernel. Arm's SBBR only states that IF you implement Secure Boot and TPM support in your EFI firmware (you don't have to), it has to comply with certain rules. Nothing about preventing users from disabling it. (https://documentation-service.arm.com/static/5fb7e66fd77dd80...)