Mermaid (https://mermaid-js.github.io/) is excellent, easy to embed inline in Markdown or reStructuredText and to version with the rest of the documentation.
No, the user is still in control of what they execute on the machine, whether it is run in enclave or not. If anything, because it is deliberately unable to patch itself, software running in an enclave gives more control and auditability to a user who can know exactly what code they are running.
Importantly, a user who does not fully trust the machine administrator can still maintain integrity and confidentiality over their computation.
SGX memory encryption keys are ephemeral, they are generated at boot, and they do not need to be owned by anyone to be useful, on the contrary!
There are many interesting uses for enclaves, most of which have nothing to do with DRM. A good example is Signal’s secure value recovery mechanism: https://signal.org/blog/secure-value-recovery/
It is interesting and useful as a workaround for existing situation, ie running under untrusted OS. It’s not useful as a proper solution (as opposed to a hack/workaround). Except for DRM.
Because, as shown by SGX, it doesn’t work. And if it did work, it would lead to a whole new magnitude of the malware problem - malware protected from you by hardware.
The right way to do it is the other way round: have a trusted hypervisor and run your untrusted OS in it. See TrustZone for example.
I’m not sure why you think that SGX shows hardware enclaves “don’t work”. I also don’t see why you think enclaves “protect the malware from you”. Enclaves are created and started from host code, which can interrupt or terminate them at any time.
The scheme you suggest, which isn’t typically how TrustZone is used, gives zero integrity and confidentiality guarantees for applications. I don’t know if it’s “the right way” for some threat model, but for the most typical TEE use cases which are trying to establish strong integrity and confidentiality guarantees in the presence of an untrusted host, it’s absolutely not right nor useful.
Critical flaws in SGX are being found all the time. It's a failed experiment that someone put into commercial products. At the same time there are no examples of SGX-like architecture that actually do work.
Enclaves are started from host code, but host code can't see into them. In other words you have no way of telling whether the enclave you've started is what you wanted, or if it includes malware.
The scheme I've described does give integrity - after all, that's precisely how the actual trusted components work, SecureEnclave, TEE etc: you have a trusted hypervisor, and then run your secure components outside the untrusted OS, in a trusted environment in that trusted hypervisor. It gives you everything SGX could, without its fundamental design problems.
What you’re saying is a different threat model: your application goes rogue. SGX and TEE in general attempt to solve the reverse: your host goes rogue.
Research has shown that it is not a panacea, but we already knew that. It’s hardware not a full proof cryptographic solution. Some solutions have enclaves gather their results in a fault tolerant way to increase security even more.
So we could say that Intel and hardware vendors in general are looking for a solution that doesn’t exist. Or we can say that this is greatly improving your option when you are really scared of host compromises in your product.
I don’t think it’s helpful to confuse side-channel or micro-architectural attacks with attacks on SGX itself. Stating that hardware enclaves don’t work and do not ship is absurd, they are present in virtually every modern phone for one thing.
Code running in an SGX enclave is measured and absolutely known at enclave launch. The fact that enclave memory is encrypted for confidentiality is unrelated.
I don’t understand why you think trusting the hyper visor is helping anything. You are still open to this attack, and to all side channel attacks as soon as you run any untrusted code.
How do you distribute it out freely without affecting the market price?
If packaging and transport are a substantial part of the cost, which they are for milk, who’s going to pay that cost?
Yes, that's how governments and taxes work. The entire nation pays (at various levels depending on their income/resources) collectively to provide public services that cannot easily be provided on an individual basis.
In the Free Market similar approaches are used for things like insurance.
