Comment by cryptonector | Hacker News Reader

Comment by cryptonector | Hacker News Reader

Parent Full thread

> 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.

Ah, good point!

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.

> 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.

Reply on news.ycombinator.com