Hacker News Reader

> What I don't see touched on in this post is the high-level trust model. What generally makes trusted computing a non-starter for libre software is that it contains privileged keys baked in by the manufacturer.

Keys don't have to be open source.

Re (2), the way you defeat evil maid attacks on boot or wake is by using a TPM and measuring every bit of firmware and software loaded (to some point) so that local storage decryption is not possible unless you're running golden code. The hard part is stopping evil maid attacks on running systems.

Re (3), for open systems you really need any remote attestation to be at the option of the end user or the operating system that they choose to run (but the end user must have the option to run an operating system of their choice, which then might not implement remote attestation).

TPMs got these things right, but they're not SEs. TPMs could be SEs, but they're missing necessary functionality. I'm imagining a BPF-style system where you'd get to send bytecode to be interpreted with access to various loaded key objects (handles), and which would be able to execute TPM commands (subject to policy) and use their outputs without exposing them to the user, with the program's execution and availability of its final outputs being conditional on satisfying some relevant policy. Because so many systems have a TPM, a TCG TPM standard update that allows for a very limited and TPM-centric SE to be implemented with a TPM firmware update would be very interesting.

> For software freedom, these aspects are much more important than the design and licensing of the computation core(s). Let them ship ARM. Let them ship only ARM. Let them ship a proprietary ISA that needs to be painstakingly reverse engineered over a decade. Spend your social capital making sure the ultimate end-owners of the chip remain in control of their devices! This is what is critical for open source.

Yes, the amount of software built to run in SEs is minute, therefore it's not that big a deal to expect vendors to recompile that software if a new version of the SE were to use a different ISA. I'm a bit surprised at the focus on RISC-V, but I'm not annoyed by it -- if it really costs them little, then I don't see the problem, and having the option is certainly interesting.

I think the focus on RISC-V is in large part because of the focus of RTL-level verification. You can't release ARM core's RTL, and some may fear that backdoors might be hidden there. But you can easily release RISC-V core's RTL, and let people verify that there is no backdoors in there.

I think that one thing you can do is to release the RTL AND a matching gate level model, AND a description of the scan chain through all the flops (so a end user can verify the gate model from outside in the actual chip).

Mind you one could still still hide logic outside the scan chain but it should still be discoverable thru scan.

Ah, good point!

> TPMs got these things right

How did TPMs get these things right? To me, it seems they've gotten them direly wrong by letting the manufacturers create privileged keys.

I wrote my comment from the perspective of making something better than modern TPM implementations, iff they get the ownership/control issues right.

I don't understand your counterpoint to my (3). It's not enough for the OS to have an option to not perform remote attestation - the owner needs to have the ability to perform a mock remote attestation. Otherwise a remote party can just demand remote attestation be done, and the owners's "choice" will have been nullified.

> How did TPMs get these things right? To me, it seems they've gotten them direly wrong by baking in privileged keys.

Even if TPMs came with no endorsement key certificates, the platform could still trust-on-first-use the TPMs and create "privileged keys". The only way to prevent that would be to make TPMs useless.

> I don't understand your counterpoint to my (3). It's not enough for the OS to have an option to not perform remote attestation - the owner needs to have the ability to perform a mock remote attestation. Otherwise a remote party can just demand remote attestation be done, and the owners's "choice" will have been nullified.

I don't see how to do that without the party demanding attestation somehow establishing trust in your device, but that requires "privileged keys", and surely that party gets to say "no" (at least technologically; legally is another matter).

There's also a tension in that attestation is very useful for enterprise security. I.e., servers and VMs in data centers and the cloud, as well as employer-provided personal devices. Hard to get that but also make it impossible for consumer personal devices to attest. Also, users do get better security from attestation, at the cost of being at the vendors' mercy regarding walled garden lock-in. TPMs are neutral in this, enabling both, secure systems and DRM, and preventing neither.

> Even if TPMs came with no endorsement key certificates, the platform could still trust-on-first-use the TPMs and create "privileged keys". The only way to prevent that would be to make TPMs useless

I assume by "platform" you mean a remote party exerting control, bordering on non-consensual, over your local computer? If the hardware is not shipped with keys, the way to get around that would be to generate your own key external to the TPM, and load it into the TPM. Then the "platform" could trust that first-contact key all day long, but you would retain control.

> I don't see how to do [mock attestation] without the party demanding attestation somehow establishing trust in your device

That's the point of my requirement for the SE/TPM to spit out the attestation signing key when in reset mode. It grants the owner the ability to create mock attestations of the device as the previous owner knew it. Going forward, the owner can walk away and have the device create attestations that they can trust, with the condition that they aren't out of contact with the device for longer than the reset period. (The reset period requirement is what creates the distinction between a mere possessor, and the bona fide owner)

> There's also a tension in that attestation is very useful for enterprise security. I.e., servers and VMs in data centers and the cloud, as well as employer-provided personal devices

Yes, these are exactly the useful scenarios I envisioned when I wrote my comment, and would be fully supported with the requirements I laid out. What is not supported is claiming to sell someone a piece of hardware, while retaining indefinite control over it.

> I assume by "platform" you mean [...]

I mean the OEM who issues any "platform certificates" (in the TCG sense) for keys in the TPM's "platform key hierarchy". That would be, e.g., Dell.

> If the hardware is not shipped with keys, the way to get around that would be to generate your own key external to the TPM, and load it into the TPM.

If you have to do that every time, then you're always storing that key in the clear, and then you get no security advantage from having a TPM.

If you have to do that once and then you get the key back wrapped in a secret key only the TPM knows, well, TPMs pretty much support that. And now the platform can do the thing you don't like: ship with such a wrapped key (and certificate for it), which then enables operating systems to implement DRM.

You really can't get away from this. It's just not possible. Either you have a TPM-like device that is useful, or you don't have one, or you have one that's not useful (which is the same as not having one).

> That's the point of my requirement for the SE/TPM to spit out the attestation signing key when in reset mode. It grants the owner the ability to create mock attestations of the device as the previous owner knew it. [...]

Unfortunately that would ruin the TPM's security features in general. It would make it useless for enterprise, for example.

> > There's also a tension in that attestation is very useful for enterprise security. I.e., servers and VMs in data centers and the cloud, as well as employer-provided personal devices

> Yes, these are exactly the useful scenarios I envisioned when I wrote my comment, and would be fully supported with the requirements I laid out.

Doesn't work. See above.

> What is not supported is claiming to sell someone a piece of hardware, while retaining indefinite control over it.

You can change the seeds any time you like.

The ARM CPU is there as a backup, for investors' peace of mind.

It will never be used, unless the RISC-V core turns out defective, which is extremely unlikely.

The Tillitis TKey may provide a solution to this. You can (will be very soon) able to buy TKey devices that are not provisioned by Tillitis. Using the TKey programmer you can build your own FPGA bitstream (using the open toolchain). And then, using the provisioning tool or manually generate and insert your own Unique Device Secret (UDS).

This also means that you can get two (or more) blank TKey devices and provision them with the same UDS, creating a backup key that you can put in a safe place. I'd recommend to at least have different Unique Device Identities, to allow you to see which of the devices you use when connecting it to the host.

The bitstream, with the UDS is stored and locked in the FPGA non volatile configuration memory. It will not protect against a prepared evil maid-attack that gives the attacker enough time to dismantle the casing and perform a warm-boot attack. We are working on ways to make that attack harder, less feasible.

Exactly. In particular, see the "Powerful, Reliable Software Can Be Bad" section of <https://www.gnu.org/philosophy/open-source-misses-the-point....>. It'll take careful engineering to keep this from being useful for DRM, which I'm worried won't get done.

The TCG got this right in that TPMs do not force you into a DRM world, but they certainly enable it. I say that's right because any TPM-like technology that could let you secure boot could also let the platform vendor lock you into a DRM world -or lock you out of the walled garden if you opt out- but the TCG took a neutral approach that lets the user opt out.

By making it only possible to verify that you run on certain stack (which enforces your DRM) they made a very simple but powerful scheme that doesn't in fact infringe on users rights (No matter what FSF's FUD campaign said)

There's more to it. A TPM comes with an endorsement key certificate, and the platform to which the TPM is attached can come with platform certificates, and the OS can require those to exist and be valid and that the TPM still have the corresponding private keys. An OS can use those keys and certificates to implement a garden walled by secured boot + attestation. The user gets to change the relevant key hierarchy seeds, thus causing those private keys to no longer be available, and those certificates to be useless, and the OS to no longer be able to do attestation using those keys and certificates -- but then the OS vendor gets to lock that device out of the walled garden.

> they made a very simple but powerful scheme that doesn't in fact infringe on users rights

This is straight up false in the standard model where protocols are what mediates between otherwise-independent parties.

If a remote party can verify the software I am running on my machine against my wishes, that creates a security vulnerability that prevents me from running software of my choice.

> > they [the TCG] made a very simple but powerful scheme that doesn't in fact infringe on users rights

> This is straight up false in the standard model where protocols are what mediates between otherwise-independent parties.

I've answered this elsewhere. TPMs are neutral technology enabling technology that you might approve of and technology you might disapprove of.

> If a remote party can verify the software I am running on my machine against my wishes, that creates a security vulnerability that prevents me from running software of my choice.

TPMs do not prevent you from having opt-out.

The matter of whether someone can give you only a binary choice of opting into or out of walled gardens is a market/political problem. I don't see how to prevent walled gardens using technology, especially when walled gardens vendors can make it so you can only access the walled gardens on devices that they manufacture (or bless) -- it's their tech, so what can you do to make it not possible for them to implement lock-in? It's just not possible.

> I've answered this elsewhere. TPMs are neutral technology enabling technology that you might approve of and technology you might disapprove of.

And I strongly disagree! A TPM with an attestation key that is known to the previous owner (eg manufacturer or distributor) allows the previous owner (and everyone who trusts them) to compel the current owner to verify what software they are running on their own machine. The presence of the neutral hardware capability, plus the non-neutral treat-owner-as-an-attacker security property that the owner cannot read the private attestation key, creates a non-neutral security vulnerability for the owner. Hence my point (3) to mitigate this vulnerability by making it so that the owner can always choose to emulate an attestation. This property would make the hardware feature actually neutral.

> it's their tech, so what can you do to make it not possible for them to implement lock-in?

The problem is not set top boxes and other narrow-purpose devices created by vertically integrated companies - code signing is enough to lock those down and guarantee the creation of e-waste. Rather the issue is general purpose computers including hardware that allow remote parties to dictate what code you're running when you interact with them. For example, a bank that says "for [our] security, you must run a known copy of MS Windows with a known copy of InterChrome Explorer to access our website" (or analogous proprietary environment). The market basically moves in lock step, so you won't be able to choose a different bank (just as with the now-common "SMS 2FA" hassle). So given the basic non-neutral capability, corporations can gradually shove the general purpose computing genie back in the bottle, rather than having to make due with trusting device owners.

With binary/proprietary software, a similar dynamic exists right now. But for important cases it's possible to reverse engineer protocols and make third party clients. Owner-hostile remote attestation closes off the escape. This further pushes us into computational disenfranchisement, where the computer you purportedly own, that's sitting right in front of you, is enforcing the rules of the corporate-government power structure rather than functioning as your agent.

We do need to win the battle in the market, but to do that we at least need an option for people to buy that respects their freedom. Saying "buy this corporate phone and then run this procedure to change the TPM key [destroying your ability to use corporate-based attestation]" isn't a compelling story, but saying "buy this freedom-respecting computer based on a freedom-respecting TPM" is. We need enough of the people doing the latter that it is market-infeasible for banks et al to require remote attestation.

> A TPM with an attestation key that is known to the previous owner (eg manufacturer or distributor) allows the previous owner (and everyone who trusts them) to compel the current owner to verify what software they are running on their own machine.

The user can change the seeds and this stops being the case. Also, this feature is very useful in enterprise settings. Useful here, harmful there -- that's what makes the technology neutral. Even if TPMs didn't have endorsement key certificates, the platform vendor could add its own -- TPMs would be pretty useless without being able to derive keys from seeds or wrap keys, but having that feature is enough to make possible what you dislike.

> Saying "buy this corporate phone and then run this procedure to change the TPM key [destroying your ability to use corporate-based attestation]" isn't a compelling story [...]

You wouldn't say that. You'd say "buy this [device] and install [certain OS] on it". Why would vendors pre-ship the thing that they don't want? The user has to do something, but it can be made easy.

> The user can change the seeds and this stops being the case.

Not in a meaningful way. If you do that, the MAFIAA et al. will just block all of their stuff from that device from then on.

It's like you didn't read this subthread. You can't keep them from making sure that customer devices have this sort of hardware, not without resorting to legislation that you'll never get, so getting to at least have an opt-out is a lot better than not.

Actually even with the requirements I laid out, DRM would still work. A manufacturer could ship a device with decryption keys for DRM content. If the end-owner decided to liberate their device, then the decryption keys would be erased and DRM content could no longer be played. The owner would be left with a blank device ready to accept new software, likely open source, and the device wouldn't be relegated to becoming e-waste.

That's how it works with some of the hw backed DRM schemes that for example try to use remote Attestation with TPM, or secure media pathways on intel me or AMD PSP. The DRM software simply stops working, while you get to run everything you build yourself still.

There's no stopping walled gardens -- not with technology as the vendors would choose not to use such technology. The most choice users will ever get to make (per-device) is whether to be locked-into or locked-out-of the walled gardens.

Huh, good point. I wonder how that would be fixable too.

Does it need to be? I'm a staunch supporter of libre software, but I don't see the harm.

> I'm a staunch supporter of libre software, but I don't see the harm.

The harm is we're still perpetuating DRM crap. The music industry has accepted that Spotify's DRM can be trivially broken and completely given up trying to police BitTorrent... it's time for the movie industry to realize the same. Sadly, Netflix failed to get enough dominance to bend over and cane the movie industry into submission, and regulatory agencies worldwide just accepted happily that movie studios went all-in on vertical integration again.

The concept of DRM was initially created on general purpose open computers. No TPM, no code signing, no remote attestation. Just plain old proprietary software running on open systems was enough to create something with DRM functionality, and put blood in the water for the control freaks.

Having a device be able to store and use secure keying material that cannot be read back out seems like a very useful basic property. A basic property which directly implies being able to store keys for decrypting media content, thus making for a better DRM scheme than could be achieved with a fully-debugger-able processor.

Of course, I could missing a way that this property could tweaked to neutralize some of its downsides - akin to how my original comment laid out slight modifications to the usual TPM/SE requirements that would prevent much abuse of TPMs/SEs by centralizing entities.

It can't be "fixed" with technology. It's a matter of market power, and maybe legislation.

The fix would be to make "persons who choose to gain full control and code execution of the device" a protected class.