Latest posts by Paul Schnackenburg (see all)
- Repair a corrupt EDB file with Stellar Repair for Exchange - Tue, Jan 14 2020
- Fixing WSUS issues with the SolarWinds Diagnostic tool for the WSUS agent - Tue, Nov 26 2019
- ManageEngine Desktop Central: Unified endpoint management for Windows, Linux, and Mac - Wed, Sep 18 2019
Public cloud computing has been an interesting technology to follow over the last few years. In the beginning many of us (myself included) were very concerned with security, especially since we couldn't walk to the server rack and touch our data. Today I think most of us IT pros know the public cloud offers better security overall than most of us can achieve on premises.
There are some gaps though—some because we don't know or take advantage of the offered security features and some because it's hard to do. Today we've got data storage at rest under control, encryption is available, and in some cases, we can hold the key rather than the cloud provider doing so. Data security in transit is also well understood with Transport Layer Security (TLS) and other network controls.
Until recently, however, there wasn't a good answer for protecting data during processing. ACC seeks to fix this area.
Building blocks ^
Today the focus in ACC is on Intel's Server Guard Extensions (SGX), a technology offered on newer Xeon CPUs. This provides a walled-off part of the CPU no other process has access to and where the memory attached is encrypted, again giving no other process access to its content. These protected places are called trusted execution environments (TEEs) or enclaves.
Azure offers a new series of virtual machines (VMs) for ACC, built on Hyper-V generation 2 VMs (providing SecureBoot through virtual UEFI instead of BIOS as well as passthrough to underlying hardware), called the DC-series. The preview supports only Ubuntu 16.04 and Windows Server 2016, but they'll expand this in the future.
ACC also offers attestation services designed to reduce friction in a real-world deployment of an application designed to run in enclaves. Not only do you need to write the application, you also need to ensure that when it's going to run, it can only run in enclaves or VMs you trust. And when those enclaves receive newer firmware or software updates, you can update your policies so your applications continue to run. Microsoft is basing the attestation service on standard JSON Web Tokens.
Where will these apps be used? ^
Don't expect server applications to start using enclaves immediately. Not only is it new, fairly unproven technology but developers will either have to write applications from scratch or have to refactor them significantly to split them up. So there'll be one part running on the host (normal code with data that doesn't need to be protected) and the other part running in the secure enclave.
The first use case that comes to mind is the financial or the medical industry needing to process sensitive data or protect the algorithm doing the processing from prying eyes, including from administrators managing the VMs (and Microsoft's Azure engineers).
SQL Server will also take advantage of enclaves, building on their current Always Encrypted platform that uses a driver on the client that ensures only the data requiring display on the client is unencrypted. Starting in SQL Server 2019, Microsoft will enhance this technology with enclaves, followed by Azure SQL. In this screenshot, you can see WinDebug examining the memory running an enclave in SQL Server. And as you can see, even an administrator on the host and SQL Server can't see it.
Another use case is machine learning (ML) model training. There are many situations where the model will be more accurate if it's got more data to build from, but that data can't be revealed to other parties. Imagine several hospitals having patient data they can't share. But if they encrypted the data so that it could only be decrypted in an enclave (thus protecting the data from the other hospitals), used to train the model, and then encrypted again, this would produce a more accurate model.
Another use case is enterprise blockchain scenarios where several businesses need to share data or code, but they don't fully trust the other partners in the consortium. Here, all partners can inspect the code that runs in the enclave and agree that they trust it and thus trust whatever results the code gives.
What's better than a single buzzword in IT? Two of them combined of course, and there's a use case for enclaves in IoT Edge scenarios with a need to process data before uploading it to the cloud. Imagine a sales terminal that processes credit card information in a secure enclave, stopping potential hackers even if they have access to the machine.
The SDK ^
One part of ACC is the hardware in Azure, the VMs, and the associated attestation infrastructure. The other part is a new SDK, the Open Enclave SDK (which they'll release as open source when it's ready). This SDK doesn't just work for writing applications for Azure but also works with any SGX hardware. Currently it supports C and C++ with other languages coming.
The SDK aims to abstract the underlying technology, ensuring portability. Today Azure offers Hyper-V virtualization-based security (VBS) enclaves as well as Intel SGX. ARM is developing TrustZone with similar functionality the SDK will also support. I would assume that AMD will offer similar functionality in the future.
Another reason for the SDK is to reduce friction for developers. Intel's own SGX SDK requires that you have a business relationship with Intel so you can acquire the required certificates. Microsoft's SDK removes that need while still mapping certificates back to Intel's root certificate.
The last aim of the SDK is to provide portability between Linux and Windows applications, ideally requiring only a simple recompile.
An enclave has some performance degradation compared to normal host processing and also a limitation on the amount of data and code you can fit into it. So the real challenge with enclave applications will be to design them right so that the split between host and enclave code is optimal. This is not unlike the tradeoff required for kernel and user modes in normal applications. I predict that developers who pick this up early will be able to earn large amounts going forward.
ACC and enclave technology is very new, and I've heard IT security specialists herald it as a "total game changer." Personally I think the requirement to write applications from scratch (or significantly refactor existing ones) will slow down adoption. But in the wake of Spectre and Meltdown, I think enclave applications will have a bright future in the right situations. Perhaps the Payment Card Industry (PCI) might even require it in the future.