3 ms·

> I want to be able to secure my computer (an ATM, say) against people with physical access to it. A root of trust (that the original purchaser of the device co

> I want to be able to secure my computer (an ATM, say) against people with physical access to it. A root of trust (that the original purchaser of the device controls) allows for that. Unless you're running something like a Raptor Talos II, You don't really have the root of trust. You have a branch off of the manufacturer's root. That may be better for some enterprises, but in this modern age is that really enough? Consider how the PLA was involved in the hacking of Experian/Equifax. Until you can review the code yourself and verify the binaries, you don't really have the root of trust. Someone else does. (I'm barring other types of shenanigans here, but it's the next logical step.)

derefr 7y ago
I mean, for the kind of highly-trusted "ruggedized" scenario represented by an ATM, one would hopefully get their hardware from a manufacturer that exists under a political regime they have no enmity with, or are perhaps even allegiant to. (That's half the reason many US government officials and contractors used Blackberries: the US government could—given the political realities of the time they live in—trust a device whose chips were verifiably made in Canada.) For the workstation scenario, though, you don't really care who has the "ultimate" root, just so long as you can get whoever that is to help you to stop a particular class of attacker (e.g. your own employees, contractors, and any "visitors" in the building) from getting root. It's fine if the PLA has root on the boxes, because the boxes aren't actually storing trade secrets or anything; the point of having pseudo-root on the boxes is, in fact, to enforce a security regime that ensures your employees don't store any trade secrets on the boxes! See also: being an "organization owner" in an enterprise SaaS service. Sure, I can't stop Google from snooping my GSuite data—but I'm also paying them to host that data for me, and e.g. selling it would be a violation of the contract. Even though they can, in theory, do it, they're economically incentivized against doing so (and doubly so, because if they did it once and got found out, they'd never make any GSuite money again.) > Unless you're running something like a Raptor Talos II, You don't really have the root of trust. Mind you, there are "multiply-descendant root-of-trust" setups that are quite common these days. In modern Apple devices, you've got an Intel processor doing most stuff, but then the Apple-controlled T2-chip domain doing encryption stuff, with its own boot chain completely isolated from the Intel one.
- oneplane 7y ago
  You still are just a trust leaf, not the root. The root is a ROM you cannot read or change on the Intel side, so no trust control there (only delegated which for some people is no trust at all). With no ability to verify it, an exploit like this would not be something you can detect and as such breaks the trust chain.
  - dboreham 7y ago
    If you're talking about SGX the root is really the Intel-run remote attestation servers, no?
    - oneplane 7y ago
      Yes and no, the SGX flow models a dual-root method where two PKI roots must be trusted for success, and at the same time the SGX is only as safe as the microcode is, which can be overridden at this point. SGX with CPU-signature and Intel-signature can still be faked when you can compromise the CPU and SGX and still run the signing routines. Edit: I wonder if there is any feasible way one could do this without trusting the CPU at all, but I suppose that completely defeats the point.
      - dboreham 7y ago
        Hmm. I didn't realize the key, or at least the signing function, was in the microcode. So if the microcode can be changed by an attacker, they can have it sign <fake code signature> but go ahead and run <evil code> instead?
        oneplane 7y ago
        Yes, and that was supposed to be protected by CSME and ACM, but because those can be circumvented, so can microcode upgrades. Normally a microcode update would be verified as well, but since it has been hacked in the past and CSME verification can now be bypassed it would probably be a matter of time. It used to be the case that an internal ROM with a unique on-time programmable entry that can only be read internally was safe enough, but with decapping, gliching and breaking PKI chains that is getting weaker and weaker.

derefr 7y ago

I mean, for the kind of highly-trusted "ruggedized" scenario represented by an ATM, one would hopefully get their hardware from a manufacturer that exists under a political regime they have no enmity with, or are perhaps even allegiant to. (That's half the reason many US government officials and contractors used Blackberries: the US government could—given the political realities of the time they live in—trust a device whose chips were verifiably made in Canada.) For the workstation scenario, though, you don't really care who has the "ultimate" root, just so long as you can get whoever that is to help you to stop a particular class of attacker (e.g. your own employees, contractors, and any "visitors" in the building) from getting root. It's fine if the PLA has root on the boxes, because the boxes aren't actually storing trade secrets or anything; the point of having pseudo-root on the boxes is, in fact, to enforce a security regime that ensures your employees don't store any trade secrets on the boxes! See also: being an "organization owner" in an enterprise SaaS service. Sure, I can't stop Google from snooping my GSuite data—but I'm also paying them to host that data for me, and e.g. selling it would be a violation of the contract. Even though they can, in theory, do it, they're economically incentivized against doing so (and doubly so, because if they did it once and got found out, they'd never make any GSuite money again.) > Unless you're running something like a Raptor Talos II, You don't really have the root of trust. Mind you, there are "multiply-descendant root-of-trust" setups that are quite common these days. In modern Apple devices, you've got an Intel processor doing most stuff, but then the Apple-controlled T2-chip domain doing encryption stuff, with its own boot chain completely isolated from the Intel one.

oneplane 7y ago
You still are just a trust leaf, not the root. The root is a ROM you cannot read or change on the Intel side, so no trust control there (only delegated which for some people is no trust at all). With no ability to verify it, an exploit like this would not be something you can detect and as such breaks the trust chain.
- dboreham 7y ago
  If you're talking about SGX the root is really the Intel-run remote attestation servers, no?
  - oneplane 7y ago
    Yes and no, the SGX flow models a dual-root method where two PKI roots must be trusted for success, and at the same time the SGX is only as safe as the microcode is, which can be overridden at this point. SGX with CPU-signature and Intel-signature can still be faked when you can compromise the CPU and SGX and still run the signing routines. Edit: I wonder if there is any feasible way one could do this without trusting the CPU at all, but I suppose that completely defeats the point.
    - dboreham 7y ago
      Hmm. I didn't realize the key, or at least the signing function, was in the microcode. So if the microcode can be changed by an attacker, they can have it sign <fake code signature> but go ahead and run <evil code> instead?
      - oneplane 7y ago
        Yes, and that was supposed to be protected by CSME and ACM, but because those can be circumvented, so can microcode upgrades. Normally a microcode update would be verified as well, but since it has been hacked in the past and CSME verification can now be bypassed it would probably be a matter of time. It used to be the case that an internal ROM with a unique on-time programmable entry that can only be read internally was safe enough, but with decapping, gliching and breaking PKI chains that is getting weaker and weaker.