9 ms·

Arm Introduces Its Confidential Compute Architecture

150 points by Symmetry 5y ago

Scene_Cast2 5y ago
I see that there's a lot of mindshare on privacy and "computing trust" these days. There are several approaches that I noticed. One is to not send data to untrusted places (e.g. a server), another is to have a trust chain & hardware enclave (either through SGX / trustzone), and lastly to encrypt data (e2e encryption for transport-only, or homomorphic encryption (slow) / distributed encryption) for doing operations on the data. Currently, verifiable OSS on the server isn't in vogue (in practice or literature), but could be another approach.
- formerly_proven 5y ago
  > I see that there's a lot of mindshare on privacy and "computing trust" these days. This is the opposite of respecting privacy (unless you mean e.g. the privacy of DRM code), all of this stuff is "trusted" as in TCG.
  - Scene_Cast2 5y ago
    Yep. Privacy is a heavily overloaded term; I meant it as a more industry-style "data access management". Some comments in the other thread do talk about non-DRM uses.
  - bawolff 5y ago
    https://signal.org/blog/private-contact-discovery/ https://signal.org/blog/private-contact-discovery/ seems like an application of SGX where net privacy is increased.
    - dane-pgp 5y ago
      Or, that looks like a single point of failure that would make a good target for the government to issue a National Security Letter to Intel for.
      - xxpor 5y ago
        NSLs are a subpoena. The government can't order you to include a backdoor. Granted, they have other leverage they could use, like export licenses or purchase contracts.
        dane-pgp 5y ago
        > The government can't order you to include a backdoor. Right, but it can order you to turn over your private keys, like it did to Lavabit[0]. Intel might instead voluntarily hand over a signed backdoored firmware, targeted at a specific set of CPUs, rather than the keys themselves, which could do more damage if the government lost control of them. Similarly I don't suppose it would be much harder for the NSA to get access to the physical servers that Signal is running its software on. Perhaps you could say that merely having the access credentials wouldn't be enough information for the NSA to take control of Signal's servers without them noticing, but any cloud provider that wants to do business with the government surely has special backdoors that make this easy, when presented with an NSL. [0] https://en.wikipedia.org/wiki/Lavabit https://en.wikipedia.org/wiki/Lavabit
      - bawolff 5y ago
        Its not perfect, but the more people in on a secret the harder it is to keep. Its much harder to have to coerce both intel and signal (even if you hack intel, you would still have to modify signal's servers from what i understand) than just signal.
      - staticassertion 5y ago
        What would that accomplish?
      - Ar-Curunir 5y ago
        It’s better than before, where all that stuff was available in plaintext
        milkey_mouse 5y ago
        Signal didn't back up contacts and settings to their servers until they implemented "Secure Value Recovery", which relies on SGX to rate-limit guesses of a weak PIN. If SGX is broken and Signal's database falls into the wrong hands, encryption keys could be brute-forced pretty quickly (most people have 4-digit PINs).
- mindslight 5y ago
  It's a societal dead end, so there's no technical excitement. The same technology that would let you verify a cloud server is running code you specify, would also be used by websites to demand that your personal computing environment conforms to their whims. Imagine websites that required proprietary Google Chrome on Win/OSX on bare metal - no VM, no extensions, no third party clients, no automation, etc. Imagine mandatory ads, unsaveable images, client-side form verification, completely unaccountable code, etc. Protocols are the proper manner of allowing unrelated parties to transact at arm's length, and technologies such as remote attestation would completely destroy that.
  - KirillPanov 5y ago
    > Imagine websites that required proprietary Google Chrome on Win/OSX on bare metal - no VM, no extensions, no third party clients, no automation, etc. No need to imagine, we already have that: it's called fingerprinting. Mainly via WebGL.
    - mindslight 5y ago
      There is a major difference between something being difficult/annoying, and outright impossible.
- tyingq 5y ago
  Memory tagging looks interesting to me. This paper from LowRISC outlines the possibilities pretty well: https://riscv.org/wp-content/uploads/2017/05/Wed0930riscv201705_ppt.pdf https://riscv.org/wp-content/uploads/2017/05/Wed0930riscv201... Referencing that not to plug RiscV, but solely because it's a good explanation. I would guess Intel, AMD, and ARM have plans or some existing work going on.
  - pjmlp 5y ago
    Memory tagging is already been used successfully for years on Solaris SPARC, https://docs.oracle.com/cd/E37838_01/html/E61059/gqajs.html https://docs.oracle.com/cd/E37838_01/html/E61059/gqajs.html In what concerns ARM, all Android 11 and later versions are going to support it. https://security.googleblog.com/2019/08/adopting-arm-memory-tagging-extension.html https://security.googleblog.com/2019/08/adopting-arm-memory-... https://source.android.com/devices/tech/debug/tagged-pointers https://source.android.com/devices/tech/debug/tagged-pointer... Unfortunelly Intel's MPX was a failure, for reasons, however the rest of the CPU vendors seems to be going into the C machine model, as only way left to fix the language.
- Ar-Curunir 5y ago
  Verifiable OSS doesn’t stop a malicious operator from just looking at your bits in memory
staticassertion 5y ago
I really like the idea of secure enclaves. I'd like to use them. The problem I have is that it's unclear to me: a) How the hell I'm supposed to do so? It seems fairly arcane and in need of some higher level abstractions. fortanix[0] seems like it could be good here? b) What the implications are. What's it like to maintain an enclave? What do I lose in terms of portability, debug-ability, etc? It reminds me of GPU to some extent - it's this thing in my computer that's super cool and every time I think about using it it looks like a pain in the ass.
- Scene_Cast2 5y ago
  I'm not sure if the push for enclaves on phones is really meant for _you_ per se. IIRC one of the more talked-about use cases is for DRM'd content (e.g. software that you can't crack, banking apps with more resistance to malware, etc).
  - staticassertion 5y ago
    True, but I'm assuming that this is all moving towards enclaves being more standard and cross platform.
  - count 5y ago
    Given the audience of this site....who do you think writes those apps?
  - drivebycomment 5y ago
    While it is often useful to understand what the motivating goal was for the design of a new system like secure enclaves and what the practitioners primary concerns are, in the end it doesn't actually matter what the designers intender. Rather, what matters is what it actually does and provides. As long as the new functionality can be used for other useful purposes that are still within the design goals and parameters, it would be useful. Tool doesn't care what the creator intended - it's whether the tool is useful for whatever purpose it can be used for. Thus I find most analysis and comments like this, based only on motivation and incentives, very lacking. Add to that, to be more specific to this particular topic, secure enclaves are designed not only for DRM but for many other critical applications (that are actually far more important than DRM and are/were the key motivating use cases) - it, or the general concept, is the basis of the security guarantee for iPhone's fingerprint or face ID, or the confidentiality of the key materials in various end-to-end encryption, which allows things like the-phone-as-a-security-key.
wmf 5y ago
Where is the memory encryption done? The L2? The DSU?
- kijiki 5y ago
  Intel and AMD do it in the memory controller. The caches, by virtue of being entirely on-die, are assumed to be inaccessible. It is unclear what AMD intends to do here for their TSV stacked mega-cache thing. Perhaps they'll declare the TSVs as not practically snoopable, similar to how on-die metal layer wires are treated now...
  - wmf 5y ago
    My concern is less about the die boundary and more about vendor boundaries. In an Arm-based SoC with potentially a bunch of different IP all sharing the coherent fabric do you want to bet that all that IP will correctly implement CCA? Probably not.
    - kijiki 5y ago
      A legit concern. Basically everything that connects directly to the cache controllers has to get CCA right. Coherent GPUs are the big, complicated one. Intel had an SGX bug where the GPU could access the last 16 bytes of every 64 byte cache line. If you need the GPU enabled, you have no choice but to design your enclave to only use the first 48 bytes of each cache line. Fortunately if you don't need the GPU, whether or not the GPU is enabled (among other things) is measured and included in the attestation quote, so clients can simply choose to refuse to talk to servers with the GPU enabled...
formerly_proven 5y ago
> ARMv9 will power the next 300 billion ARM-based devices Stuff like this makes me nauseous. This is not a good thing. Stop it.
- AnimalMuppet 5y ago
  Why is it not good?
  - zaybqp 5y ago
    Maybe it is the unsustainable environmental impacts of never-ending new gadgets? https://www.hpe.com/us/en/insights/articles/top-6-environmental-threats-caused-by-digital-electronics-1901.html https://www.hpe.com/us/en/insights/articles/top-6-environmen...
  - qayxc 5y ago
    It means >110 new devices per living human being. That can't indeed be good.
    - AnimalMuppet 5y ago
      Not necessarily. A new car can have 100+ processors in it (though I don't know how many of them would be Arm-9). One CPU != one device.
    - shard 5y ago
      I don't think it's as bad as that statement implies. It's not all smartphones or laptops or TVs or cars. A large number of those devices would be things like smartcards, LED light bulbs, USB cables, ID tags for shipping containers: tiny, low-to-no-power devices, if what you are concerned about is large amounts of electronic waste.
      - AnimalMuppet 5y ago
        True if you look at processors in general. I'm not sure it's true of Arm-9 processors, though. I think they're a bit overpowered for a LED light bulb, a USB cable, or an ID tag.
api 5y ago
Seems like this and similar ideas are a "poor man's fully homomorphic CPU." The idea is that the CPU has some kind of embedded key that you can use to send data into a trust enclave, perform secret compute on it, and export that data in encrypted form back out such that nobody should be able to see what happened... assuming you trust the vendor and your adversary does not have extreme NSA-level hardware forensic capabilities and physical access to the hardware. Honestly it's not bad until or unless we get actually fast FHE chips. I think we're a ways away from that.
- ajb 5y ago
  Although it requires more trust, this also has more functionality than an FHE, in that it allows you to deliberately allow selected information out of the enclave. For example, you can check a signature. With an FHE, the boolean indicating that the signature was valid, can only be revealed to someone with the key of the FHE scheme. FHE is not a fully generic way of using third-party hardware in a trustworthy way.
  - u8mybrownies 5y ago
    Unless you have a fast connection to someone with the key
- gumby 5y ago
  It's not homomorphic in any way. HE currently looks like a dead end anyway. >10^6 slower is going to be hard to overcome.
Symmetry 5y ago
SemiAccurate has a more detailed explanation. https://www.semiaccurate.com/2021/06/23/arm-talks-security-cca-and-realms/ https://www.semiaccurate.com/2021/06/23/arm-talks-security-c...
- tux3 5y ago
  Oh if Charlie is right about CCA enclaves sharing the same key AND there's no launch control to stop other enclaves from spawning, that's a devastating oversight indeed...
contingencies 5y ago
Is this going to be perverted as a way to grow DRM on the device and have it owned by the vendor instead of the user?
- blendergeek 5y ago
  No. In order for this to be "perverted as a way to grow DRM", it would need some other main function. The main purpose of this is to allow vendors, rather than users, to control personal computers. It will be great for finally allowing truly unskippable ads, ads that track your eyeballs to make sure you are looking, text that cannot be copied, etc.
  - contingencies 5y ago
    Sounds like the way things are going, open systems are going to be effectively illegal soon. Tencent/Apple/Google (TAG) will arrange that if you're not on an approved 'secure' device you are 'suspect', and slowly find ways to integrate this in to governance "for social benefit". At that point, if you're not 100% on the system (read: surveilled 24x7x365 - voice assistant anyone? - with a credit card/bank account, state-ID and consumer profile associated) you'll be penalized: your views will be impossible to share (it's almost that way already), and you'll be incrementally excluded or dissuaded from travel and transport, financial services, educational opportunities, events, job markets, etc. To resist this situation a device manufacturer could emerge with a privacy-first experience and solutions to proxy just the right amount of legitimacy to the outside systems (PSTN, payment, etc.) with an international legal structure optimised for privacy, akin to what wealthy people do already. A sort of anti walled-garden shared infrastructure. Technically I could see an offering providing mobile # to VOIP forwarding, data-only phone with mesh networking > wifi connectivity preference, MAC shuffling, darknet/VPN mixing, payment proxy, global snailmail proxy network, curated (well tested for pop sites) lightweight browser with reduced attack surface and a mobile network only as a last-resort connectivity paradigm (with dynamic software SIM and network operator proxying). Open source of course. Issue being, infrastructure would be expensive to offer and if it were ever popular there'd be political pushback. I guess privacy will increasingly be the exclusive domain of the rich. We've already lost.
marcan_42 5y ago
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

150 points by Symmetry 5y ago

I see that there's a lot of mindshare on privacy and "computing trust" these days. There are several approaches that I noticed. One is to not send data to untrusted places (e.g. a server), another is to have a trust chain & hardware enclave (either through SGX / trustzone), and lastly to encrypt data (e2e encryption for transport-only, or homomorphic encryption (slow) / distributed encryption) for doing operations on the data. Currently, verifiable OSS on the server isn't in vogue (in practice or literature), but could be another approach.

formerly_proven 5y ago
> I see that there's a lot of mindshare on privacy and "computing trust" these days. This is the opposite of respecting privacy (unless you mean e.g. the privacy of DRM code), all of this stuff is "trusted" as in TCG.
- Scene_Cast2 5y ago
  Yep. Privacy is a heavily overloaded term; I meant it as a more industry-style "data access management". Some comments in the other thread do talk about non-DRM uses.
- bawolff 5y ago
  https://signal.org/blog/private-contact-discovery/ https://signal.org/blog/private-contact-discovery/ seems like an application of SGX where net privacy is increased.
  - dane-pgp 5y ago
    Or, that looks like a single point of failure that would make a good target for the government to issue a National Security Letter to Intel for.
    - xxpor 5y ago
      NSLs are a subpoena. The government can't order you to include a backdoor. Granted, they have other leverage they could use, like export licenses or purchase contracts.
      - dane-pgp 5y ago
        > The government can't order you to include a backdoor. Right, but it can order you to turn over your private keys, like it did to Lavabit[0]. Intel might instead voluntarily hand over a signed backdoored firmware, targeted at a specific set of CPUs, rather than the keys themselves, which could do more damage if the government lost control of them. Similarly I don't suppose it would be much harder for the NSA to get access to the physical servers that Signal is running its software on. Perhaps you could say that merely having the access credentials wouldn't be enough information for the NSA to take control of Signal's servers without them noticing, but any cloud provider that wants to do business with the government surely has special backdoors that make this easy, when presented with an NSL. [0] https://en.wikipedia.org/wiki/Lavabit https://en.wikipedia.org/wiki/Lavabit
    - bawolff 5y ago
      Its not perfect, but the more people in on a secret the harder it is to keep. Its much harder to have to coerce both intel and signal (even if you hack intel, you would still have to modify signal's servers from what i understand) than just signal.
    - staticassertion 5y ago
      What would that accomplish?
    - Ar-Curunir 5y ago
      It’s better than before, where all that stuff was available in plaintext
      - milkey_mouse 5y ago
        Signal didn't back up contacts and settings to their servers until they implemented "Secure Value Recovery", which relies on SGX to rate-limit guesses of a weak PIN. If SGX is broken and Signal's database falls into the wrong hands, encryption keys could be brute-forced pretty quickly (most people have 4-digit PINs).
mindslight 5y ago
It's a societal dead end, so there's no technical excitement. The same technology that would let you verify a cloud server is running code you specify, would also be used by websites to demand that your personal computing environment conforms to their whims. Imagine websites that required proprietary Google Chrome on Win/OSX on bare metal - no VM, no extensions, no third party clients, no automation, etc. Imagine mandatory ads, unsaveable images, client-side form verification, completely unaccountable code, etc. Protocols are the proper manner of allowing unrelated parties to transact at arm's length, and technologies such as remote attestation would completely destroy that.
- KirillPanov 5y ago
  > Imagine websites that required proprietary Google Chrome on Win/OSX on bare metal - no VM, no extensions, no third party clients, no automation, etc. No need to imagine, we already have that: it's called fingerprinting. Mainly via WebGL.
  - mindslight 5y ago
    There is a major difference between something being difficult/annoying, and outright impossible.
tyingq 5y ago
Memory tagging looks interesting to me. This paper from LowRISC outlines the possibilities pretty well: https://riscv.org/wp-content/uploads/2017/05/Wed0930riscv201705_ppt.pdf https://riscv.org/wp-content/uploads/2017/05/Wed0930riscv201... Referencing that not to plug RiscV, but solely because it's a good explanation. I would guess Intel, AMD, and ARM have plans or some existing work going on.
- pjmlp 5y ago
  Memory tagging is already been used successfully for years on Solaris SPARC, https://docs.oracle.com/cd/E37838_01/html/E61059/gqajs.html https://docs.oracle.com/cd/E37838_01/html/E61059/gqajs.html In what concerns ARM, all Android 11 and later versions are going to support it. https://security.googleblog.com/2019/08/adopting-arm-memory-tagging-extension.html https://security.googleblog.com/2019/08/adopting-arm-memory-... https://source.android.com/devices/tech/debug/tagged-pointers https://source.android.com/devices/tech/debug/tagged-pointer... Unfortunelly Intel's MPX was a failure, for reasons, however the rest of the CPU vendors seems to be going into the C machine model, as only way left to fix the language.
Ar-Curunir 5y ago
Verifiable OSS doesn’t stop a malicious operator from just looking at your bits in memory

staticassertion 5y ago

I really like the idea of secure enclaves. I'd like to use them. The problem I have is that it's unclear to me: a) How the hell I'm supposed to do so? It seems fairly arcane and in need of some higher level abstractions. fortanix[0] seems like it could be good here? b) What the implications are. What's it like to maintain an enclave? What do I lose in terms of portability, debug-ability, etc? It reminds me of GPU to some extent - it's this thing in my computer that's super cool and every time I think about using it it looks like a pain in the ass.

Scene_Cast2 5y ago
I'm not sure if the push for enclaves on phones is really meant for _you_ per se. IIRC one of the more talked-about use cases is for DRM'd content (e.g. software that you can't crack, banking apps with more resistance to malware, etc).
- staticassertion 5y ago
  True, but I'm assuming that this is all moving towards enclaves being more standard and cross platform.
- count 5y ago
  Given the audience of this site....who do you think writes those apps?
- drivebycomment 5y ago
  While it is often useful to understand what the motivating goal was for the design of a new system like secure enclaves and what the practitioners primary concerns are, in the end it doesn't actually matter what the designers intender. Rather, what matters is what it actually does and provides. As long as the new functionality can be used for other useful purposes that are still within the design goals and parameters, it would be useful. Tool doesn't care what the creator intended - it's whether the tool is useful for whatever purpose it can be used for. Thus I find most analysis and comments like this, based only on motivation and incentives, very lacking. Add to that, to be more specific to this particular topic, secure enclaves are designed not only for DRM but for many other critical applications (that are actually far more important than DRM and are/were the key motivating use cases) - it, or the general concept, is the basis of the security guarantee for iPhone's fingerprint or face ID, or the confidentiality of the key materials in various end-to-end encryption, which allows things like the-phone-as-a-security-key.

wmf 5y ago

Where is the memory encryption done? The L2? The DSU?

kijiki 5y ago
Intel and AMD do it in the memory controller. The caches, by virtue of being entirely on-die, are assumed to be inaccessible. It is unclear what AMD intends to do here for their TSV stacked mega-cache thing. Perhaps they'll declare the TSVs as not practically snoopable, similar to how on-die metal layer wires are treated now...
- wmf 5y ago
  My concern is less about the die boundary and more about vendor boundaries. In an Arm-based SoC with potentially a bunch of different IP all sharing the coherent fabric do you want to bet that all that IP will correctly implement CCA? Probably not.
  - kijiki 5y ago
    A legit concern. Basically everything that connects directly to the cache controllers has to get CCA right. Coherent GPUs are the big, complicated one. Intel had an SGX bug where the GPU could access the last 16 bytes of every 64 byte cache line. If you need the GPU enabled, you have no choice but to design your enclave to only use the first 48 bytes of each cache line. Fortunately if you don't need the GPU, whether or not the GPU is enabled (among other things) is measured and included in the attestation quote, so clients can simply choose to refuse to talk to servers with the GPU enabled...

formerly_proven 5y ago

> ARMv9 will power the next 300 billion ARM-based devices Stuff like this makes me nauseous. This is not a good thing. Stop it.

AnimalMuppet 5y ago
Why is it not good?
- zaybqp 5y ago
  Maybe it is the unsustainable environmental impacts of never-ending new gadgets? https://www.hpe.com/us/en/insights/articles/top-6-environmental-threats-caused-by-digital-electronics-1901.html https://www.hpe.com/us/en/insights/articles/top-6-environmen...
- qayxc 5y ago
  It means >110 new devices per living human being. That can't indeed be good.
  - AnimalMuppet 5y ago
    Not necessarily. A new car can have 100+ processors in it (though I don't know how many of them would be Arm-9). One CPU != one device.
  - shard 5y ago
    I don't think it's as bad as that statement implies. It's not all smartphones or laptops or TVs or cars. A large number of those devices would be things like smartcards, LED light bulbs, USB cables, ID tags for shipping containers: tiny, low-to-no-power devices, if what you are concerned about is large amounts of electronic waste.
    - AnimalMuppet 5y ago
      True if you look at processors in general. I'm not sure it's true of Arm-9 processors, though. I think they're a bit overpowered for a LED light bulb, a USB cable, or an ID tag.

api 5y ago

Seems like this and similar ideas are a "poor man's fully homomorphic CPU." The idea is that the CPU has some kind of embedded key that you can use to send data into a trust enclave, perform secret compute on it, and export that data in encrypted form back out such that nobody should be able to see what happened... assuming you trust the vendor and your adversary does not have extreme NSA-level hardware forensic capabilities and physical access to the hardware. Honestly it's not bad until or unless we get actually fast FHE chips. I think we're a ways away from that.

ajb 5y ago
Although it requires more trust, this also has more functionality than an FHE, in that it allows you to deliberately allow selected information out of the enclave. For example, you can check a signature. With an FHE, the boolean indicating that the signature was valid, can only be revealed to someone with the key of the FHE scheme. FHE is not a fully generic way of using third-party hardware in a trustworthy way.
- u8mybrownies 5y ago
  Unless you have a fast connection to someone with the key
gumby 5y ago
It's not homomorphic in any way. HE currently looks like a dead end anyway. >10^6 slower is going to be hard to overcome.

Symmetry 5y ago

SemiAccurate has a more detailed explanation. https://www.semiaccurate.com/2021/06/23/arm-talks-security-cca-and-realms/ https://www.semiaccurate.com/2021/06/23/arm-talks-security-c...

tux3 5y ago
Oh if Charlie is right about CCA enclaves sharing the same key AND there's no launch control to stop other enclaves from spawning, that's a devastating oversight indeed...

contingencies 5y ago

Is this going to be perverted as a way to grow DRM on the device and have it owned by the vendor instead of the user?

blendergeek 5y ago
No. In order for this to be "perverted as a way to grow DRM", it would need some other main function. The main purpose of this is to allow vendors, rather than users, to control personal computers. It will be great for finally allowing truly unskippable ads, ads that track your eyeballs to make sure you are looking, text that cannot be copied, etc.
- contingencies 5y ago
  Sounds like the way things are going, open systems are going to be effectively illegal soon. Tencent/Apple/Google (TAG) will arrange that if you're not on an approved 'secure' device you are 'suspect', and slowly find ways to integrate this in to governance "for social benefit". At that point, if you're not 100% on the system (read: surveilled 24x7x365 - voice assistant anyone? - with a credit card/bank account, state-ID and consumer profile associated) you'll be penalized: your views will be impossible to share (it's almost that way already), and you'll be incrementally excluded or dissuaded from travel and transport, financial services, educational opportunities, events, job markets, etc. To resist this situation a device manufacturer could emerge with a privacy-first experience and solutions to proxy just the right amount of legitimacy to the outside systems (PSTN, payment, etc.) with an international legal structure optimised for privacy, akin to what wealthy people do already. A sort of anti walled-garden shared infrastructure. Technically I could see an offering providing mobile # to VOIP forwarding, data-only phone with mesh networking > wifi connectivity preference, MAC shuffling, darknet/VPN mixing, payment proxy, global snailmail proxy network, curated (well tested for pop sites) lightweight browser with reduced attack surface and a mobile network only as a last-resort connectivity paradigm (with dynamic software SIM and network operator proxying). Open source of course. Issue being, infrastructure would be expensive to offer and if it were ever popular there'd be political pushback. I guess privacy will increasingly be the exclusive domain of the rich. We've already lost.

marcan_42 5y ago

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