This article is more than 1 year old

Hardware-driven security in the hybrid cloud

Chips to the rescue

Sponsored One of the greatest barriers to broader cloud adoption is security.

However much the big cloud providers insist that their global networks of bit barns are more secure and tightly operated than those of their enterprise customers, it is those same customers who are ultimately liable for protecting the data under their control.

For highly regulated industries like healthcare or financial services, the penalties for a data breach make it simply too risky to process sensitive data anywhere else outside their own systems. This means that they are missing out on the advantages of cloud services, such as greater operational flexibility and the potential to save on some of the capital expenditure costs of on-premise IT systems.

Public cloud in particular presents a number of challenges for keeping data secure, largely because an organisation is effectively choosing to run workloads on infrastructure that it does not own or control. While an organisation can take steps to lock down its own systems and deploy tools to detect or prevent intrusion, there are limits on what a customer can do to the cloud provider’s infrastructure.

Encryption of sensitive data is now routine both in the cloud and on-premise, but this largely protects data only when it is at rest, stored on disk. In order to be processed, it still has to be “in the clear” while in memory so that any required operation can be performed on it, whereupon it is vulnerable to being accessed by an attacker that may have compromised the system.

In any case, industry experts have long realised that software only solutions simply will not cut the mustard, since they can ultimately be compromised or bypassed in some way. Instead, security needs to be rooted in hardware capabilities that cannot be altered or disabled by malicious code.

There have already been attempts at building security into silicon. Intel platforms have had Trusted Execution Technology (TXT) for some time, while chips based on the ARM architecture have had its TrustZone technology for over a decade. Oracle also added Silicon Secured Memory (SSM) into it SPARC processors when the M7 was introduced.

The main purpose of Intel TXT was and is to ensure a secure startup, verifying that low-level code such as an operating system kernel or hypervisor has not been compromised. But this is not a complete solution as it does not prevent malware or an attacker from compromising the system once it is up and running.

Oracle’s SSM is part of the software-in-silicon capabilities built into newer SPARC chips, and is designed to guard access to blocks of memory by associating them with a version number. Code accessing the memory block must present the same version number, offering some protection against buffer overruns. But this might not prove much protection against a determined attacker that may have compromised the system, as explained by The Register at the time.

What is required is some mechanism that can prevent access to data while it is being processed, even if an attacker has managed to penetrate the system. This is no trivial task, since a compromise of the software stack at the operating system or hypervisor level would enable an attacker to simply pluck data out of an application’s memory space.

Perhaps the most ambitious move to address this problem is Intel’s Software Guard Extensions (SGX), one of the new capabilities introduced to the Xeon server platform with the latest chips based on the Skylake architecture.

SGX is designed to allow the creation of isolated and protected memory blocks within the server’s memory space, inside which code can be placed in order to safely process sensitive data. These memory blocks are known as Trusted Execution Environments (TEEs) or alternatively as enclaves.

To enable this, SGX provides a new privileged execution mode and several new instructions. These are used at runtime to create an enclave and deploy the trusted code into it, before locking it down. Once created, the enclave memory region cannot be accessed by any other code, and functions inside the enclave can only be accessed via carefully controlled entry points.

In principle, SGX is somewhat similar to ARM’s TrustZone, but the latter simply divides the entire system into secure and non-secure environments, with hardware enforced separation between the two. SGX, in contrast, enables multiple applications to each have their own enclave for any portion of their code that deals with sensitive data. The upshot of this is that applications running on an SGX-enabled system are split into trusted and untrusted code, with the trusted code deployed in the enclave kept as small as possible in order to reduce the possibility of security vulnerabilities being introduced.

But the chief difference in how SGX differs from previous silicon-based security schemes is that the processor itself is the only hardware component that needs to be trusted. It does not require a Trusted Platform Module (TPM) as the root of trust or for attestation of code, for example, as TXT does.

Theoretically, this should mean that SGX enclaves should be secure from prying even if the operating system, hypervisor, firmware, and even Intel’s Management Engine have all been compromised by an attacker. This is a level of security that was not practical to achieve before chips with SGX became available.

The first major outing for this technology is going to come from Microsoft. In September, the firm announced its Azure cloud platform will be the first to support enclaves secured by Intel’s SGX, using servers based on the latest Skylake Xeon processors.

How this will ultimately be made available to customers has yet to be fully detailed by Redmond, but the firm said it intends to implement encryption-in-use for its Azure SQL Database service and SQL Server. Azure CTO Mark Russinovich also gave a demonstration of what this might look like at the firm’s Ignite conference in September.

The demo revolved around a sample HR application running queries against a cloud database with two columns - social security number and salary – where the stored value was protected using the Always Encrypted feature. A Stored Procedure was deployed into an enclave then passed the encryption key over a secure channel so that it was able to process queries that reference the encrypted columns.

To date, Intel’s SGX has had only limited traction, but Microsoft’s Azure cloud is widely used by large enterprise firms, and seems likely to drive interest in this method for keeping data secure while it is being processed. If it proves a hit, we can expect to see it implemented in more platforms, both in the cloud and on-premise – there is certainly scope for a technology that can keep data secure, even if malware has compromised the server your application is running on.

No single security technology can ever be totally bulletproof. As The Register reported earlier this year, researchers found a way to extract information from an SGX enclave using a fiendish side-channel attack. However, such attacks can be mitigated if the rest of the platform is carefully designed, and SGX means that Intel’s latest Xeon chips offer the best foundation currently available for a platform capable of keeping the most sensitive data secure.

Sponsored by Intel

More about

TIP US OFF

Send us news