Wednesday, October 12th 2016
AMD's ZEN to Implement Advanced Security Features not found in Intel's solutions
Thanks to AMD's incorporation of an ARM-based "AMD Secure Processor" in their upcoming ZEN micro-architecture, the company is poised to offer something competitor Intel's microprocessors yet don't: memory encryption. This processor, and its underlying technologies, could prove to be a stepping-stone for AMD towards regaining lost server market share. Essentially, because in a market ever more steered by cloud computing considerations, it allows for the client's data to be encrypted at every moment of the work chain. Assuming all works as intended, for the first time not even cloud providers, with either hypervisor-level privileges or even physical access to the servers, will be able to carry out any malicious actions against their clients.
One only has to consider the writing on the wall: Morgan Stanley predicts that by 2018, 30% of Microsoft's revenue will stem from its cloud services; Amazon Web Services (AWS) generated $7.88B in revenue on Q4 2015, up 69% over 2014; and worldwide spending on public cloud services by itself will grow from $70B in 2015 to an estimated $141B in 2019. Cloud computing is here to stay, and with security being as important as it is for some businesses, this is an important area of investment for AMD. This "AMD Secure Processor" will work on essentially two fronts: SME (Secure Memory Encryption) and SEV (Secure Encrypted Virtualization), backed by an hardware-based SHA (Secure Hash Algorithm).According to AMD's Memory Encryption Whitepaper, SME works by leveraging the Secure Processor in encrypting data (using a 128-bit AES encryption key) when it is written to DRAM, effectively putting an end to the last redoubt of Cleartext-stored data. This becomes increasingly important when one considers the advent of NVDIMM (non volatile memory), which if left unencrypted, would be much more vulnerable to physical removal and subsequent cloning of its contents than currently employed solutions. This encryption key is randomly generated by the Secure Processor on each system reset, and is never accessible by any software running on the CPU cores. Furthermore, AMD states that the encryption impact on performance (namely, latency on memory accesses) is, quote, "very small", even when the entirety of the addressable memory is encrypted, but especially considering the Security Processor's ability to encrypt only specific memory pages, and not the entire amount of used RAM.
SEV, on the other hand, solves the problem with the traditional ring-based security system, where customer's code runs at a lower privilege level than the hypervisor. In essence, this means that in ring-based security, the hypervisor can have access to the guest's (ie., client's) data. With SEV, that will no longer be the case, isolating the hypervisor and the client's resources, as well as different client's workloads running on the same machine. Each of these workloads, as well as the hypervisor, will have their code and data tagged and separately encrypted, guaranteeing that each time the encrypted data is accessed by code with an incorrect encryption tag, all it sees is its encrypted state. SEV differs from SME in that in this case, the hypervisor must interact with the Secure Processor in order for the encryption to occur. It informs the Secure Processor that an encrypted VM (Virtual Machine) is going to run, and passes to the server's Secure Processor the needed certificates and exchange key which, in turn, allows the Secure Processor to load the appropriate, unique AES key.With the ever-expanding computing requirements of businesses and customers worldwide being increasingly serviced by servers on the so-called cloud, the need for increased security becomes more and more of a concern for service-providers. According to The 2016 Global Cloud Data Security Study, 60% of IT professionals consider it to be more difficult to protect confidential or sensitive information in the cloud. At the same time, it's estimated that globally, 36% of organization's total IT and data processing needs are met by cloud resources. This is expected to increase to 45% over the next two years.
And with 86% of the study's respondents claiming encryption will become even more important over the next two years, this feature disparity between AMD and Intel's solutions could prove to be an ace up AMD's sleeve in regaining some of its lost server market share from its glory days.
Sources:
2016 Global Cloud Data Security Study, AMD x86 Memory Encryption Technologies
One only has to consider the writing on the wall: Morgan Stanley predicts that by 2018, 30% of Microsoft's revenue will stem from its cloud services; Amazon Web Services (AWS) generated $7.88B in revenue on Q4 2015, up 69% over 2014; and worldwide spending on public cloud services by itself will grow from $70B in 2015 to an estimated $141B in 2019. Cloud computing is here to stay, and with security being as important as it is for some businesses, this is an important area of investment for AMD. This "AMD Secure Processor" will work on essentially two fronts: SME (Secure Memory Encryption) and SEV (Secure Encrypted Virtualization), backed by an hardware-based SHA (Secure Hash Algorithm).According to AMD's Memory Encryption Whitepaper, SME works by leveraging the Secure Processor in encrypting data (using a 128-bit AES encryption key) when it is written to DRAM, effectively putting an end to the last redoubt of Cleartext-stored data. This becomes increasingly important when one considers the advent of NVDIMM (non volatile memory), which if left unencrypted, would be much more vulnerable to physical removal and subsequent cloning of its contents than currently employed solutions. This encryption key is randomly generated by the Secure Processor on each system reset, and is never accessible by any software running on the CPU cores. Furthermore, AMD states that the encryption impact on performance (namely, latency on memory accesses) is, quote, "very small", even when the entirety of the addressable memory is encrypted, but especially considering the Security Processor's ability to encrypt only specific memory pages, and not the entire amount of used RAM.
SEV, on the other hand, solves the problem with the traditional ring-based security system, where customer's code runs at a lower privilege level than the hypervisor. In essence, this means that in ring-based security, the hypervisor can have access to the guest's (ie., client's) data. With SEV, that will no longer be the case, isolating the hypervisor and the client's resources, as well as different client's workloads running on the same machine. Each of these workloads, as well as the hypervisor, will have their code and data tagged and separately encrypted, guaranteeing that each time the encrypted data is accessed by code with an incorrect encryption tag, all it sees is its encrypted state. SEV differs from SME in that in this case, the hypervisor must interact with the Secure Processor in order for the encryption to occur. It informs the Secure Processor that an encrypted VM (Virtual Machine) is going to run, and passes to the server's Secure Processor the needed certificates and exchange key which, in turn, allows the Secure Processor to load the appropriate, unique AES key.With the ever-expanding computing requirements of businesses and customers worldwide being increasingly serviced by servers on the so-called cloud, the need for increased security becomes more and more of a concern for service-providers. According to The 2016 Global Cloud Data Security Study, 60% of IT professionals consider it to be more difficult to protect confidential or sensitive information in the cloud. At the same time, it's estimated that globally, 36% of organization's total IT and data processing needs are met by cloud resources. This is expected to increase to 45% over the next two years.
And with 86% of the study's respondents claiming encryption will become even more important over the next two years, this feature disparity between AMD and Intel's solutions could prove to be an ace up AMD's sleeve in regaining some of its lost server market share from its glory days.
31 Comments on AMD's ZEN to Implement Advanced Security Features not found in Intel's solutions
Yeah, as a news post, it's kinda more like old-news :clap:
That said, I found the info and the technology interesting and potentially game-changing, so I tried to give it a relatively detailed, yet simple breakdown of what to expect and how it works.
Same for encrypted virtualization: it won't hide the information from the host itself.
The only way I can see DRM being implemented with this is having a DRM-protected application running in a an encrypted virtual machine. For one kind of DRM, the stuff for games, which want to use "actual graphics", it's helluva problematic. While for the other kind of DRM, music and movies, that just introduces a problem of "we still need to get the decrypted content outside of the VM, to the hypervisor / underlying OS, so it could actually present it to the user."
And even if someone finds some convulated way to make use of these for DRM, due to the nature of the tech and since these both features interact with the OSes running on the hardware in a non-trivial way, it's simply an option one can, nay, has to be able to disable before boot. (Or more like, have to be explicitly enabled by the user before boot, likely in the form of BIOS/UEFI/whatever settings, lest all hell breaks loose if the software doesn't support it) What these had/have is called a TrustedZone, which is this just slightly useful thing mainly used by ARM platforms, which AMD licensed from aforementioned ARM.
What Zen is getting is this plus a whole lotta more and these additional features are not provided nor available on the TrustedZone dohicky.
Simular happens on PC, where malware esp. for Windows trying to grab bank details, would technically be encrypted making it useless. Malware is these days so sophisticated that it does'nt need any user input at all. It just sits and monitors what is going in and outside the memory for example.