Today ARM released some details about their CCA security architecture and Realms. Both are a step forward but probably not what you think they are, SemiAccurate was underwhelmed.
When ARM first talked about CCA or Confidential Compute Architecture and Realms as the foundation for their concept of confidential computing, it sounded really good. When the curtain was pulled back and the details outed, there was far less to reveal than we expected. This isn’t to say it is bad or useless, CCA just protects against a narrow class of attacks, not the broad spectrum that the sales pitch intones.
Bold claims for CCA
If you look at the materials, the main pitch for CCA is that, “Arm CCA can protect all data and code wherever computing happens.” This is a good thing and fits the bill of what most would consider confidential computing. Two slides later however there is a slightly less heady claim that, “Protects from host OS/Hyp/TrustZone”, and then on the next slide we have this.
CCA claims part 2
This last slide sure makes it sound like CCA is going to solve every problem and keep everything secure, but does it? Lets take a look at what CCA, Realms, and the RME (Realm Management Extensions) do. The overview makes things look simple which in the context of security is a good thing, lower attack surfaces and less fragile tend to come along for the ride. In this setting, complexity tends to be the enemy.
The architecture is simple and that is good
There are four colors that connote four security levels, Normal, Monitor, Secure, and Realm. This is a change from the older security model found in ARM v8.4-A which only supported Normal and Secure. What do these two new areas add, what do they do, and more importantly what do they not do?
At the bottom of the pile we have the Root zone where the Monitor lives. Monitor is the low level firmware and related code, basically what gets you to the point where an OS or hypervisor takes over. With CCA the Root/Monitor is protected with it’s own ephemeral key, something that was not possible in earlier ARM security models. The result is that the boot code and firmware is fully encrypted and the system is protected against cold boot attacks. This is the main function of CCA and explains the, “Protects from host OS/Hyp/TrustZone” part nicely.
The Secure box is basically the old TrustZone model but CCA adds a new twist here. With the ‘old way’, TrustZone needed pre-allocated memory spaces that it would use for whatever it used encrypted memory for. This was a tad unwieldy and the lack of flexibility could be painful at times but the overall idea was solid and it offered a lot of protection. If you got under the running code however, it was a moot point and that is where the Root/Monitor cold boot protection comes in. Trustzone/Secure uses a separate key for encryption that is different from one used to protect the monitor or other low level code.
Next up we have the Normal box which as you might expect is protected by nothing, no bespoke keys, no encryption. This is also the same as v8.4-A and like the older way, it doesn’t do anything for security. CCA means it obviously doesn’t do anything better though, and even small gains like that are worth it. Yes this was a joke.
Now we move on to the big change Realms. Realms are essentially encrypted VMs or more specifically encrypted memory spaces, VMs are optional. Realms obviously use a separate key from Secure and Root as well so anything protected this way is not visible to zones other than Root . Realms encrypts things on a per-page basis which means the Realm Management monitor (RMM) can pick what and when to encrypt on a very granular basis. This is a far more flexible and advanced technology than the full memory encryption offered by Intel (TME) or AMD (SME), those two are either on or off for everything. AMD’s SEV is in a different league and offers the same granularity and a lot more, but we will get into that later. Think of realms as more flexible than TME/SME but also more complex to implement.
Can you see the others?
How does it work? CCA adds RME or Realm Managemet Extension and GPT or Granule Protection Table. Each zone, Root, Secure, Normal, and Realm are assigned a security state which is stored in the GPT. Whenever there is a memory access, the GPT is checked by the MMU and if access is allowed, the memory is read and if needed decrypted with the appropriate key. If there is a mismatch you get a page fault. So far so good.
That is the basis of CCA and Realms, it adds a new security state that is much more interoperable with the unsecure world, a very good thing. This allows for spinning up both secure and non-secure tasks on the fly which is key to any modern security profile. Extensions to Secure mean TrustZone is now much more useful and flexible but it is fundamentally unchanged in concept. Root allows the firmware to be protected and stops cold boot attacks from getting under the other security models. Like we said, pretty simple and simple is good.
One last item is attestation, something that is key to security between systems. Having a secure laptop or phone is fine but if the other side doesn’t know, or more to the point can’t prove that you are secure, should it work with you? This is where attestation comes in and CCA does support it. Basically it allows a device to prove it is secure to a remote system in a cryptographic way which means that the trust goes all the way to the silicon vendor which you have to assume is secure because there is nothing lower than that level on a device.
Attestation is key to ecommerce and transactions on the web, plus it gives a lot of confidence that a transaction is going to who it should and both sides are ‘safe’. We must point out that nothing is 100% safe but attestation helps a lot of the interoperability front. The down side is that a vendor can now dictate what you can and can not run on your personal device before you work with them so attestation isn’t a completely good thing for users but that isn’t specific to ARM or CCA.
To aid with attestation and interoperability, ARM does their usual good thing and says it will be opening and publishing the specs and sample code for CCA and related mechanisms. This means you can implement CCA interoperability and attendant attestation mechanisms on anything you want, x86 servers being the obvious initial target. This is the way things should be done but sadly only ARM does it, AMD is OK, and Intel is actively antagonistic toward basic security disclosures.
You might recall that we were a little down on CCA and Realms in the beginning of this article. The reason for that is simple, CCA uses three keys, four if you count null, one for each security zone. Each Realm is encrypted with the Realm key which means that memory and tasks running in that zone are protected from Secure and Normal, nothing is protected from Root but that is necessary for the system to work. The problem is that a realm is not protected from another realm with anything more than the normal MMU based protections which are useful but are not encryption.
The main point of Realms is to protect tasks from the underlying OS/Hypervisor if it is compromised or malicious. Think about running a VM in a potentially hostile foreign country, you probably can’t trust that the host is immune to polite requests from government agencies so what do you do? In theory that is the main goal of Realms, it prevents the hypervisor and OS from seeing anything encrypted and to a limited extent, it does this.
SemiAccurate’s first big problem with CCA is that if for example an OS is compromised, it can spin up a task to steal data from unsecure Normal areas and send it off the box. Running a task in a Realm will stop this vector cold, the attacker would get encrypted data not readable data so the good guys win, right?
Well if the box is compromised, what is to stop the bad guys from spinning up that same piece of malicious code in a Realm? At that point it is encrypted with the same key as the ‘protected’ data and can just read it like it wasn’t encrypted at all. This isn’t just a small problem, in SemiAccurate’s opinion it is a fatal flaw in CCA, it obviates the entire premise of protecting data. That said AMD’s SME and Intel’s TME have the same problem but they don’t make the claims ARM does.
Why is this a problem? If you read the marketing headlines, CCA should allow you to run secure VMs from your work for example without the device owner being able to see the sensitive data. As we mentioned before, if the device’s owner spins up an app to steal that data they get nothing. If they spin up an encrypted app to steal that data they get everything. Having one key per security zone, and only one key, essentially adds one very small step to the current process of data theft but won’t deter anyone competent enough to do it the old way for more than a few minutes.
So what can you do? This is where the underwhelming part comes in, as does AMD’s SEV. SEV stands for Secure Encrypted Virtualization but it doesn’t need to be used with virtualization. Like CCA it tags pages with a key, or more to the point what key to use, for encryption. Naples based Epycs support 254 keys, Rome and Milan have 510. In case you are wondering that is two per thread, 64C x 2T x 2S minus one for null and one for system, basically more than enough.
A system can encrypt each task, VM, or anything it wants to with a unique key under SEV. Any encrypted task that grabs data from another task gets garbage. If a VM spins up a malicious encrypted app, it is encrypted with a different key and gets nothing useful from it’s mining. This is the way to do things right, or at least the best we have at the moment, and CCA isn’t in the same league. Before you ask, Intel has nothing close, SGX is like a particularly malignant TrustZone with no benefits and lots of pain, it is a net negative for any system. CCA does encrypt data but doesn’t protect it in any meaningful or useful way, but it does do some good.
That is the first reason why SemiAccurate is down on CCA, it promises the world but delivers real but very limited gains. This would be OK but the second issue means these gains are going to be slow to spread and are unlikely to be ubiquitous in the market. Unlike AMD’s SEV which is available on 100% of their server CPUs, CCA is optional. Worse yet several key parts are implementation dependent so an OEM can chose to implement security or not. Without 100% availability, very few will write code that uses it so the added security will be the exception not the standard. ARM missed the boat by not mandating CCA.
The next issue is key revocation and updates/rotation which is somewhat essential to any security model that provides attestation and remote interoperability. To be fair ARM does provide guidance on all of these fronts but then goes on to say that it is optional and an implementation choice. This is not ideal and again means you will have a patchwork of likely non-interoperable mechanisms that lead to the inevitable low uptake and higher cost. ARM really missed the boat on this one, it should have been mandatory in silicon with standard mechanisms for all of the fundamental pieces.
So in the end, does CCA and Realms live up to the claim that, “Arm CCA can protect all data
and code wherever computing happens.”? In our opinion it does indeed offer some protection to everything and unquestionably adds a lot to securing the boot process, but the protections above that are mainly security theater. Without multiple keys and hard implementation requirements, we don’t see CCA changing much other than securing boot and adding patchwork attestation capabilities. Hopefully in the 2-3 years before the first CCA bearing hardware hits the market, minds will change on some of this.S|A
Charlie Demerjian
Latest posts by Charlie Demerjian (see all)
- Qualcomm Is Cheating On Their Snapdragon X Elite/Pro Benchmarks - Apr 24, 2024
- What is Qualcomm’s Purwa/X Pro SoC? - Apr 19, 2024
- Intel Announces their NXE: 5000 High NA EUV Tool - Apr 18, 2024
- AMD outs MI300 plans… sort of - Apr 11, 2024
- Qualcomm is planning a lot of Nuvia/X-Elite announcements - Mar 25, 2024
