An imperfect analogy is thinking of a Secure Enclave as a safe deposit box at a bank for using your data. The bank itself is a place that conducts certain functions and has some security. To take it a step further, only a select group of people can enter the room where the boxes are, and then taking it a step further, only a certain key can open it.
Where the analogy falls short is that a Secure Enclave is not only a secure container but can run powerful applications. For example, if you stored your medical records in this box, the secure enclave could run artificial intelligence models on those contents, such as scanning those documents to assess potential risk of certain disease.
More precisely speaking, a secure enclave is an environment that provides for isolation of code and data from an operating system using hardware-based CPU-level isolation. Secure enclaves offer a process called attestation to verify that the CPU and apps running are genuine and unaltered. Secure Enclaves are one implementation of the concept of Confidential Computing.
In addition to secure processing, encrypting the data at its source prior to transit or storage protects data further. Encryption renders data not readable. Combining public key encryption with using secure enclaves means that the data can only be decrypted, or used, in the secure enclave environment.
Secure Enclaves are an emerging technology with heavy investment. A specific example is the AWS Nitro Enclave, which Cape has built on top of to make encryption and secure processing available to any developer.
Additionally, enclaves also have a verification process called attestation that helps you verify the enclave’s integrity. To pull on that bank analogy again and stretch it: is the bank legit? Am I going into the right room and opening a real safety deposit box and not a fake that’s stealing my valuables, or valuable data?
Data breaches happen everyday at a shocking, scary, and embarrassing pace. The impact of these breaches not only have financial consequences but also violate the data privacy of individuals. These exposures of data often happen when data is being used, and there are many potential points of failure as shown by the diagram below.
The imperfect analogy I’ve given on how data is mishandled is as if you’re walking with an open bag of cash around the city behind your back or leaving that open bag of cash in the backseat of a car with your windows down while you’re driving and parking. We would never do that with cash, but this is basically what’s happening to personal data in the wild in many cases.
Cybersecurity is a broad field that aims to protect data but often focuses on external threats. It’s stopping the robber and not the person from leaving the cash unprotected. There’s a lot of nuance in cybersecurity. What a lot of cybersecurity solutions don’t focus on are internal threats, eg. someone at a company makes a mistake and exposes the data or doesn’t treat it with care. All it takes is one point of failure for a data breach.
A lot of companies have resorted to methods like tokenization that alter data in a way that protects it, but that also makes the data less usable. However this is akin to burying cash in the ground. It’s safe, but you can’t use it while it’s rotting down there.
One area where we don’t hear often about data breaches anymore that was once a blocker for e-commerce is credit card numbers being stolen while in-transit when making an online purchase. This is because TLS technology, encryption technology, protects that process. This begs the question, why don’t we use it more?
The answer is that encryption technology is difficult and adapting for difference situations takes a lot of effort. We at Cape are trying to democratize encryption. This way, even if a wider system gets compromised, such as this example of a EC2 cloud virtual machine, the data in the enclave remains secure. Data outside of the enclave remains protected because of encryption by Cape.
While no solution is 100% bulletproof, combining encryption with using data in these secure environments can solve a big part of the problem.
Encryption at the source, on the client-side, means more security as data moves through different pipelines. The secure enclave paradigm protects the data by only allowing the data to be decrypted and used for a specific purpose by specific authorized parties inside of the enclave. Below are some explainers that describe this further and some simple use cases:
Attestation is a process that the enclave uses to prove its identity using a cryptographically signed document that has unique measures. It’s the digital equivalent of a certificate of authentication or document notarization. Blockchain uses this concept heavily.
A real world example of how this is used outside of data management and processing is how my alma mater verifies degrees. There are Blockchain-based measures and checks to verify the authenticity, individuality, and validity that I, indeed, graduated.
For the more technically minded, this blog AWS Nitro Enclave Cryptographic Attestation with Cape Privacy provides a step-by-step overview of attestation for a deep dive. AWS also has an overview workshop. The below diagram from AWS shows where the attestation sits within AWS’s architecture and the system output of verifying attestation.
Cape’s attestation implementation runs through the following checks:
To summarize: attestation is the process in which the authenticity of an enclave is verified.
To wrap up, we at Cape provide easy ways to encrypt data at the source. Like a safety deposit box where you can only open with your key, the data can only be unlocked and used in the secure enclave.
The legitimacy of the enclave is proven through attestation. Cape adds value by layering additional checks on top of this process, such as being able to specify datasets that can only be used for specific tasks, by specific individuals or integrating with a zero-trust model. Read more about how we’re secure.