Traitorous computing should not exist and a pox be upon the heads of everyone who let such modules make it into our computers.
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.
Or, to be slightly more dark, I, as an enterprise IT administrator, don't want the employees fucking around with the hardware I deploy, even when they have all day to poke and prod around. I'm the root user of those workstations, not them. I need to be able to enforce enterprise security policies on them, and I can't do that if they can "jailbreak" the company's computers. (They want to run arbitrary code for personal reasons? They can do it on their own arbitrary personal devices, then, for which I have conveniently provided them a partitioned-VLAN guest network to join.)
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.)
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.
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.
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.
("I" being a business, or individual, any proxy for society at large)
The fact that a tiny few human beings had the power of a "tornado" over others' lives ended fairly abruptly in some circumstances, with apparently good enough reason that it stayed that way.
Note: you're referring to absolutism, which is a mode of monarchy (also found in totalitarianism, dictatorship). By contrast, most monarchies still 'alive' today operate more in "symbolism" mode, in the constitution of their country.
This is kind of a recapitulation of the argument that forked Ethereum into Ethereum Classic:
• There was a system, partially founded on a guiding principle of its participants having final say in what happens in their in-system interactions, through contracts they enter into the system. Those contracts were each supposed to "have root" over all state-changes made to their own private storage.
• Something went wrong with a contract, in a way that corrupted its private storage and made things worse for pretty much everybody, since it was a very popular contract. The maintainers of the system decided to violate the guiding principle in the name of making things better for everybody, by just reaching in and overriding the rules of the popular contract, so that it would retroactively have done the "right" thing, and not gotten corrupted.
• Some people thought that there shouldn't be any entity (consortium or otherwise) with power to override the rules of their contracts, even if those changes are "to the good", so they left and started their own alternative system, mostly the same other than the guarantee that they'd never violate the guiding principle.
• The market decided that the alternative system has about 1/10th the economic value of the original system. Most developer effort, userbase, etc. sided with the original system, and with the concept of there being a political entity with the power to overrule individual contracts. The contract creators themselves seem to want the "safety net" implied by this entity having the power to overrule them.
Interesting, no?
Maybe if you live on that Face/Off prison where everyone wears metal boots on a magnetic grid. But in the real world rule-of-law is quite fragile because everyone has "root" over their own bodies. The obvious benefit is an ability of the public to revolt against a corrupt regime.
Regardless, it's a fatuous metaphor because nobody is advocating for mandatory metal boots nor the little Harkonnen heart plug thingies from Dune. Some people are, however, quite vehemently demanding that all software/hardware be designed by law to give root to a trusted third party. That's fatuous and dangerous and therefore requires different metaphors.
My point with my analogy was that, in the real world, hardware/software already do give root "by law" to the state. Not explicitly, but rather implicit in the fact that the government can tell you what to do, and so, if they want to control your computer, they can make you do it. (What else do you call a National Security Letter?) That's kind of what "by law" means—the law doesn't need to say that the law supercedes X; the law can supercede X in any specific case, any time it likes. If a court rules you need to open up your computer, there doesn't need to be a law making that request legal. A court said it; it's legal by definition.
And even then, a government only needs (the public conception of the machinery of) the law on their side if they aren't all that motivated to deal with you. If they really care—think "motivated enough to go though the trouble of putting someone into a witness-protection program, but... the opposite of that"—then there are plenty of private places they can disappear you to, and paint over your life with fabrications of criminal behavior they caught you in, including several months of evidence from a parallel running manufactured narrative of your life.
If you think there's a difference between dying by having your heart unplugged, and dying by having a SWAT team show up at your door with munitions you can never hope to have parity with, I don't know what to tell you. Either way, you're going to end up doing what they say, or dying trying to get away. (And if they really really care, you won't even be able to do that. You'll just wake up in a straightjacket in a padded room with all your teeth pulled out, so that you can't even bite your tongue.)
I would tell you that this kind of choice [being root in your 'own' system, having a 'root mechanism' in a collective network: pick any, both or none] fundamentally comes down to ethical values, a personal hierarchy thereof. The case of cryptocurrencies, if we ignore the speculative aspect, is interesting insofar as it demonstrates quite fundamentally opposed political views — here a certain idea of "benevolent interventionism" (however dictatorial / democratic in legitimity, the very existence of the mechanism), versus a certain ideal of "the hand of God" (re Adam Smith), a 100% non-distorted entity (I reckon, from that to Conway's game of life is but a matter of vocabulary: it's a fascinating object for nerds indeed).
Again, if we ignore the speculative aspect — which distorts everything, makes all of the above possible on paper but absolutely not observed in real life so far.
On topic, I think there's a certain tension forking towards the "free" domain — think Linux and open source and free software but actuated: now it's RISC-V (big mover in the integrated sector, GPUs..), OpenPower, think also companies like Tesla or Amazon making their own 'forks' of everything in-house, not because of NIH (these are too efficient to fall prey to such emotional traps) but rather because they do squeeze some degree of efficiency (like Google with their TPUs and what-have-you). How all programming languages in 20 years have gone open-source and mostly collegial in governance, and most major projects by way of consequence; etc.
This [x86 RoT] is just one in a list of reasons that justify this much deeper trend, as I reckon; and there is indeed a certain idealism of "the hand of God" as in being root on your own system (God = me = root). I very much subscribe to this ideology myself, if only for the practical reason that a backdoor is a backdoor is a backdoor.
Why not generate a unique key for each device on first boot? isn't it a fact that the original purchaser does not have control of the trusted computer platform. Trusted as in the OEMs trust they can control your computer.
The problem with trusted computing is in how Apple, for example, uses it to prevent users from running software they don't like on their own phones. The problem is the fact that Apple is in control instead of the user, not the technology it uses to maintain the control.
There are still plenty of people unconcerned with the economics of multi-tenant cloud hosting, DRM, or prevention of cheating in videogames.
"I don't want to have to trust my cloud provider."
"Ok, we'll absolutely pinky-swear by this API you can access that our machines are running a trusted setup."
"Ok! I'll just trust the API you provide."
Even if the API is an x86 instruction, even if you do timing checks and side-channel checks in your code, you're still just in an arms race with your cloud provider while they hold all the power.
As a BE developer, I can tell you FE should always be untrusted. Always. Anyone who tells you otherwise is insane.
Yes, NetFlix wants to live a fantasyland where they control the display of content. Tough. At the end of the day, I can record my iPad and put it on YouTube.
This does require trusting the CPU manufacturer (Intel) though. It's possible that Intel could collude with a server operator to create fake remote attestation messages, and trick you into encrypting your compute workload to them instead of the securely-sandboxed code of hash XYZ. That's not any worse than the current setup where your submitted compute workloads can't at all be encrypted in a way that the cloud operators can't read. Currently, if I want to use a no-name cloud host, then I have to trust the no-name cloud host to not be conspiring against me. With remote attestation, I just have to trust that the no-name cloud host and Intel aren't working together to conspire against me. I trust Intel relatively, so it doesn't matter how shady the no-name cloud host is.
This seems like a bad idea. Probably the number 1 reason for a host to go snooping in your VPS is because they have been requested to by a government. A government also has the power to ask intel to let the host do this. So no security has been gained here.
Of course, if that trust, due to malice or implementation defects, is misplaced, you're not better (but also not worse) off than without something like SGX.
An x86 core with SGX can be emulated...
(Edit: SGX can't be emulated. I stand corrected. Perhaps a better argument would have been arguing that verifiable builds give the user software freedom by granting them the ability to run the same code everywhere. But trusted computing != verifiable builds.)
That being said, I have serious misgivings about any hardware I own and use being explicitly designed _not_ to do my bidding. I can certainly see the utility of such an arrangement for a cloud provider though.
99% of the time this is DRM :/
In my work, it's mostly about being certain that our embedded devices run the code that we wrote and that the devices themselves are not rogue clones. In other words, about ensuring the security of the entire system.
I get the backlash against DRM, I hate it too. But I think these days the biggest DRM hoopla is largely over, and I am annoyed by the rather childish "treacherous computing" take.
There are lots of legitimate cases that do not boil down to "but you want to hurt your users". My users want a system that can be trusted, too.
If your system is running unsandboxed, untrusted third party code, that's pretty bad, regardless of the presence or absence of a trusted platform. As an example: FLOSS systems are definitely capable of running malware.
On the other hand, a reproducible build of open source software might well be what runs in (and relies on the attestation provided by) a trusted computing platform.
I do see one practical concern with integrating trusted computing on a general purpose computer:
If an implementation depends mostly on security through obscurity to achieve the desired attestation capabilities, this makes it much harder to audit it for vulnerabilities or backdoors. But I don't see how that is a fundamental property of a trusted computing system.
If I can't produce a binary with the same "reproducible state" as the one you had because your _kernel_ was one that I don't run (especially because maybe I don't _want_ to run it), that destroys all the value of a reproducible build.
A reproducible build should not _undermine_ software freedoms, specifically those protected by a Free Software license. But trusted computing always undermines software freedoms: that's by design. It's intentional. It's all about locking 100% of the users into a single monoculture where there is minimal freedom.
And that's fine in a managed IT environment such as a corporation. But it's not ok when I buy hardware and the manufacturer refuses to hand over the certificate chain to me.
This is the "old" way of using a TPM, and I agree, it does not make sense at all. After all, it never came to be, and that's not only because of the vocal protests against it. It simply does not make sense!
But I would encourage you to read up on how, for example, the Signal foundation is thinking about using something like SGX.
Of course, few people notice if the ME firmware is updated, and Intel doesn't often update deployed ME firmware. But it verifies the BIOS, and the BIOS verifies the kernel.
And that's the point where people start caring. Hence I used the kernel as an example.
Signal is thinking about using SGX, but they also have other ways to grant the user reasonable security. After this CSME exploit, Signal may reconsider using SGX.
Either way, my point still stands: verifiable builds do not rely on trusted computing at this point. I hope they never do. It would be twisted logic to tell the user the only way they can have their software freedom is by asking the trusted computing infrastructure to verify it for them. The trusted computing infrastructure being absolutely as opaque and locked-down as possible. Trusted computing is not reproducible! Its designed-in purpose is to be opaque, to hide things from the user.
Of course they don't. They are orthogonal, i.e. one does not imply the other, but one also does not prevent the other.
The verifiable build serves you, the hardware owner, in knowing that the software does what its vendor claims.
The trusted platform's assertion serves the software vendor, allowing them to trust the environment that their software is running in.
> It would be twisted logic to tell the user the only way they can have their software freedom is by asking the trusted computing infrastructure to verify it for them.
Nobody is saying that. If you want to trust your computer to do what you think it does, you don't want trusted computing; you probably want reproducible builds, trusted boot etc. But trusted computing also does not inherently prevent you from doing that. The two are orthogonal!
I suppose this depends on precisely what's meant by the term. Trusted computing based on a root of trust you control is incredibly useful by providing guarantees to you about remote systems you own and operate. This can be realized at present using Secure Boot and a TPM, but more hardware support (ex VM screening or SGX based on your own keys) would be nice.
You seem to be using trusted computing to refer only to hardware that works against the owner. Instead, I've always thought of it as referring to a device that is capable of providing various guarantees about the code it executes - it just happens that current implementations are primarily designed to provide those guarantees to third parties instead of the owner.
This is also my take on it. As with many issues in tech, it’s not about the tech itself, but rather who the tech is working for.
Now, if anyone tries to boot it with something other than Grub, it will fail and prompt for a password.
This seems like a reasonable tradeoff for secure boot, though it would be nice if Grub had a lockdown mode for this use case.
Or take a look at a ready-made configuration: https://github.com/CrowdStrike/travel-laptop
At least in theory. IIRC, a number of side channel attacks are exploitable on Intel SGX, so the adversary could leak secrets but not tamper with execution.
If X's trust in Intel to provide a platform where the code runs verified doesn't agree with your ethical view, that meant you likely don't trust X and Intel. That's all - there's no betrayal, or traitors, or other ethical dilemmas here.
Trust is not universal and you cannot trust everyone.
You're probably more interested in trustless computing, where those modules are irrelevant.
And yeah, that responsibility includes checking for updates and downloading security fixes.
"Trust" is always used in "Root of trust" and "Trustworthy computing" to mean "deny software freedom to the user."
That's not even close to what the dictionary says trust means.
That's not what "root of trust" means. Root of trust is normally a certificate which signs other certificates. If you trust that top level certificate to be valid, it means you can trust that the certificates signed by it are valid as well. That's all there is to it.
What someone does with the certificates - whether that's signing TLS traffic, or execution attestation is completely separate. I don't think you'd argue that TLS is used to "deny software freedom to the user" - right? (https://en.wikipedia.org/wiki/Root_certificate)
"trustworthy computing" is not a technical term, but a marketing phrase. (https://en.wikipedia.org/wiki/Trustworthy_computing)
You're probably referring to "trusted computing" which is a very specific use of signing and attestation of computing states. It uses the chain of trust in the same way it uses addition (or substitute any higher level concept you want) - you can't say "addition is bad, because it denies software freedom to the user" in this case.
If it is so specific, why is it present in every single Intel CPU? And why aren't end users able to delete the built-in root of trust and replace it with their own?
Trusted computing, as implemented by Intel, is actively hostile to the citizens of a free society. So in this case, I really can say that it denies software freedom to the user.
No, but if I could not make a website that was not signed by e.g. DigiCert, then I would argue that something was not right.
I'm fine with a root of trust I have complete control over, and a trusted computing chain built on that would be welcome. Such an arrangement would do nothing to curtail my freedom, since I could install my own keys and thus firmware. And it wouldn't require any additional trust in the hardware vendor beyond what I already place in them. It could even ship with the vendor's keys installed by default, the same way Secure Boot works today.
I'd still have mixed feelings about something like SGX (in its current form) being standard in consumer hardware though, since at its core it consists of the hardware working against the owner. I can see why such an arrangement is desirable for cloud providers, but widespread consumer adoption would allow a third party (presumably a content provider) to require its use as part of a DRM scheme.
That being said, even SGX could be made palatable if there was no vendor provided key in the hardware at all and it instead attested everything with _my_ key. This would still protect remote systems against myriad forms of physical attack and allow for screening VMs from each other, all without compromising the integrity of my system (from my perspective). The downside, of course, is that it would require actually trusting your cloud provider.
Once the first set of patches for SGX support in Linux got rejected specifically because the user couldn't set their own keys -- I felt it was inevitable Intel was going to cede control on this, only a matter of when the chips appeared. It's just not how they roll; Intel's relatively good and well-prepared-in-advance Linux support is one of their good strengths, and they almost certainly don't want to keep patches around for a major feature like SGX any more than they absolutely have to. (The latest versions of the kernel patches, I think, only support SGXv2 style user controlled attestation. They have yet to be merged upstream.)
1. A user-programmable MSR would allow the device owner to falsify the attestation of enclave initialization (when using their own keys).
2. The ME (and other firmware) would still not be replaceable or owner controllable.
3. Due to 2, enclave compromise would have to be premeditated. That is, once an enclave is up and running IIUC it can (potentially) use MRENCLAVE to derive the sealing key. Without control of the ME that enclave would be unbreachable, correct?
So realistically, to maintain control of code running on my device I would have to set my own SGX keys and configure my system to actively compromise all enclaves at launch. From a security standpoint, there's still a black box (the ME) with super-root that could be compromised by attackers that I can't inspect, modify, or disable. And from a political standpoint, there's still a tragedy of the commons regarding DRM if the majority of providers decide to require SGX with Intel root keys as a condition of service.
Have I misunderstood anything?
(While responding, I stumbled across an interesting paper regarding using SGX to protect malware against researchers: https://arxiv.org/abs/1902.03256)
Edit: It appears I was overly optimistic - playback of 4k BluRay already requires Intel SGX. (https://old.reddit.com/r/Amd/comments/bw0cwq/will_ryzen_3rd_...)
So even worse availability than I thought, I figured more than one SKU was supported. (I think you could at least buy either a NUC or a 1U from Intel for SGXv1 prototyping, but this is all I can find at the moment.)
Honestly though given all that it's still hard to find what actually defines SGXv2 in terms of features or errata, though. But FLC is the major requirement that will allow mainstream kernel support, from my understanding.