4 ms·

As far as I can tell, this is just using EL3 as another hypervisor level with a new, lightweight memory assignment/protection scheme, and (apparently single-key

As far as I can tell, this is just using EL3 as another hypervisor level with a new, lightweight memory assignment/protection scheme, and (apparently single-key?) memory encryption. In the end, you still have to trust the root domain, which means you still need to trust system firmware and the secure boot chain. I don't see how this is any different from the existing TrustZone stuff other than having more flexible memory management. In other words, it just makes it viable to run random third-party code in "secure" mode, but it doesn't do much to increase trust. You still need to trust the device manufacturer and boot chain. You could achieve a similar level of trust on any system with a regular hypervisor part of the device firmware, and which has standard memory encryption (which we should all be using for everything by now, it's a travesty we aren't). So e.g. if you're thinking of using this to run VMs in the cloud without having to trust the provider, you have to trust that the device manufacturer has implemented all this properly in the root monitor code, and that they have working secure boot, and that the person who physically owns the machine can't break this security. Personally, I think this is a dead-end model. Real secure compute in the cloud isn't going to happen. If someone else owns the machine, they own the machine. For non-general-compute use cases, like securing portable devices against theft or seizure, or DRM, the solution is to put the secure stuff in a separate CPU. There's a reason Apple is using a dedicated Secure Enclave Processor to implement all the critical device security stuff, and why every game console DRM scheme has a security coprocessor handling the crypto.

avianes 5y ago
> In the end, you still have to trust the root domain, which means you still need to trust system firmware and the secure boot chain. You need to trust the hardware, and you also need the firmware. However, there is no need to trust the firmware, because the trust is provided by hardware and not by firmware. And there are certificates that allow to check if the components are trustworthy. This means that a malicious user can affect the availability of the realm, but not its integrity and the confidentiality of your data. (Assuming that hardware is trustworthy) That said there is not much information in the article I may be wrong, this is my interpretation
- marcan_42 5y ago
  > However, there is no need to trust the firmware, because the trust is provided by hardware and not by firmware. No, the trust is provided by the firmware. That's what runs in the root domain. Monitor firmware. It's right there in the article. The Root domain is the ultimate trust level. > And there are certificates that allow to check if the components are trustworthy. Unless there are very specific hardware-backed attestation features baked into the chips - none of which has been mentioned, and which also relies on the inability to compromise the system through hardware mechanisms, and a bug-free monitor, which is an entire difficult to solve problem - then those certificates only allow you to check that the certificate owner has, at one point, provided key material to be used by the system, not that the software running on it continues to be what was intended. You break into the monitor, you steal the attestation keys, and then you get to keep "proving" your "trustworthiness" to everyone else. This is how on-line DRM is broken every time.

avianes 5y ago

> In the end, you still have to trust the root domain, which means you still need to trust system firmware and the secure boot chain. You need to trust the hardware, and you also need the firmware. However, there is no need to trust the firmware, because the trust is provided by hardware and not by firmware. And there are certificates that allow to check if the components are trustworthy. This means that a malicious user can affect the availability of the realm, but not its integrity and the confidentiality of your data. (Assuming that hardware is trustworthy) That said there is not much information in the article I may be wrong, this is my interpretation

marcan_42 5y ago
> However, there is no need to trust the firmware, because the trust is provided by hardware and not by firmware. No, the trust is provided by the firmware. That's what runs in the root domain. Monitor firmware. It's right there in the article. The Root domain is the ultimate trust level. > And there are certificates that allow to check if the components are trustworthy. Unless there are very specific hardware-backed attestation features baked into the chips - none of which has been mentioned, and which also relies on the inability to compromise the system through hardware mechanisms, and a bug-free monitor, which is an entire difficult to solve problem - then those certificates only allow you to check that the certificate owner has, at one point, provided key material to be used by the system, not that the software running on it continues to be what was intended. You break into the monitor, you steal the attestation keys, and then you get to keep "proving" your "trustworthiness" to everyone else. This is how on-line DRM is broken every time.