-
Notifications
You must be signed in to change notification settings - Fork 11
Improve security of enclaves
This section covers the security aspects you must consider while designing an application using the enclave model.
The SGX architecture has a very small Trusted Computing Base (TCB). You need to trust only the CPU and some support software. Anything else in the computer other than the CPU is assumed to be malicious and defended against using encryption and authentication.
The small TCB has implications for reading the system clock. As a real-time clock chip outside the CPU maintains the current time in a computer, the untrusted machine owner can tamper with it. So, you should use the current time inside the enclave only if any errors in it are not critical to the security of the enclave.
If you try to read the current time from the host, it may not map to real-time, be invalid, or have other problems. Inside an instance of an enclave, Conclave will always return a time value greater than or equal to any previously presented time. If the host rewinds the clock, the enclave time will pause until the host's time catches up with the latest time in the enclave. However, if the enclave restarts, the time inside the enclave could be earlier than in a previous instance. Additionally, the host may pause the execution of an enclave at any moment for an arbitrary duration without the enclave code being aware of that. So, if you were to read a timestamp, it might be very old by the time you use it.
However, the protocol for accessing the timestamp doesn't involve any calls out of the enclave. This avoids side channel attacks as the host can't observe the program's progress by watching Outside Calls (OCALL).
An enclave cannot directly access hardware. Like any other program, it has to ask the kernel of the OS to handle requests on its behalf, as the kernel is the only program that can control the hardware. However, inside an enclave, there is no direct access to the OS. Enclaves can communicate with the OS only by exchanging messages through the host code.
If any of the components (host software, kernel, the hardware itself) are malicious, there is a security issue when enclaves access hardware through exchanging messages with the host. Remember that enclave protections are a feature of the CPU, not the entire computer.
You can think of this another way. If the enclave stores data on disk, nothing stops the owner of the computer from stopping the enclave host process and then editing the files on disk.
You can encrypt and authenticate data using the private keys generated by enclaves to stop the host from editing it. Data encrypted in this way is called sealed data. Sealed data can be re-requested from the OS and decrypted inside the enclave. Conclave handles the sealing process for you.
However, there's one class of attack encryption cannot stop. This attack is when the host gives you back older data than was requested. The owner of the computer controls the system clock, which makes it unreliable. Additionally, the owner can kill and restart the host process whenever they like. This means that a system owner can tamper with the enclave's sense of time and order of events. By snapshotting the stored (sealed, encrypted) data an enclave has provided after each network message from a client is delivered, the enclave can be "rewound" to any point. Then, stored messages from the clients can be replayed back to the enclave in different orders, or with some messages dropped.
Such attacks are called memento/rewind/replay attacks. You can use Conclave's persistent map to mitigate rewind attacks.
Side-channel attacks break encryption without defeating the underlying algorithms by making precise observations from outside a machine or a program doing a secure computation. These observations may be of timings or power draw fluctuations.
As enclaves run in an environment controlled by an untrusted host, you must assume that the operator of the host hardware is observing such values in an attempt to break the enclave's security.
Side-channel attacks introduce a fundamental tradeoff between performance, scalability, and security. A part of Conclave's purpose is to make it easy for you to understand and control these tradeoffs while automatically blocking as many attacks as possible.
As side-channel attacks present tradeoffs between privacy and performance, analyzing them requires a different mindset from regular security analysis. Theoretically, one could claim that a side-channel attack occurred even when a single bit of data leaked. However, such minor leaks wouldn't risk any serious data loss. It might be better to allow a limited amount of leakage to obtain better performance.
A standard example is when a malicious program tries to identify whether a message is of type A or B. In many cases, the number or sequencing of message types doesn't reveal any vital information and thus doesn't need to be protected. In such cases, only the specific data within the messages need to be protected.
Side-channel attacks on enclaves are of two categories:
- Architectural
- Micro-architectural
These types are discussed more below.
Architectural side-channel attacks exploit the nature, structure, or specific code of your application architecture to reveal secrets.
Here is a non-exhaustive set of examples:
-
Message sizes. If an enclave is known to process only two kinds of messages of around 1 kilobyte or 100 kilobytes, then the size of the encrypted message by itself leaks information about what kind of message it is. Conclave can pad all messages to make all encrypted messages appear the same size. This approach works if message sizes don't vary wildly, and you can afford to use the bandwidth and storage required to set all messages to their maximum possible size.
-
Message processing time. If an enclave processes a message type in 1 millisecond and another message type in 100 milliseconds, observing how much work the enclave does for a new message, can reveal what kind of message it is.
-
Storage access patterns. Suppose an enclave doesn't access the database when processing a message of type A, but does when processing a message of type B, or accesses the database with a different sequence, number or type of accesses. In that case, the host can learn the message type by observing those accesses. Conclave's persistent file system randomizes sector accesses to reduce such side-channel attacks.
Malicious actors can use these techniques to reveal fine-grained information as well. For instance, if an encrypted piece of data contains a number used to control a loop that does data lookups, counting the number of external data lookups reveal the number.
Enclave memory is encrypted. Micro-architectural side-channel attacks exploit the inner workings of the CPU to reveal information while the CPU processes the data in its normal unencrypted state.
There are a variety of different attacks with varying details. These attacks work by exploiting the speculative execution capability of the processor to make an enclave compute on invalid data, which can then be used to bypass security mechanisms and leak data out of the enclave - not via normal means (which the CPU doesn't allow) but by affecting the timing of subsequent operations, which can then be measured.
You can prevent micro-architectural side-channel attacks at a layer lower than the architecture of your application. These methods often require reducing the performance of either the enclave or the host system. So, it's worth always planning for a large buffer of unused per-host performance.
The mitigations suggested for micro-architectural side-channel attacks like Load Value Injection (LVI) attacks work by effectively disabling speculative execution when in enclave mode. Consider the performance tradeoffs while mitigating micro-architectural attacks on your app.
Not all enclaves operate on secret data. Some enclaves are used for their auditable execution rather than for protecting secret data from the host. For such enclaves, it's sufficient to protect the signing keys rather than all data the enclave accesses. Other types of enclaves work purely with secret data but expect that the host isn't normally malicious. In this scenario, enclaves are used to slow down or stop attackers in the face of a hacked host network. It thus makes up one part of a standard suite of security measures.
As the performance/privacy tradeoff presented by side-channel attacks can vary widely, and this is an active area of academic research, Conclave will provide new tools and tunable settings to control their impact with new versions. As a developer, you need to upgrade to new versions as they come out, and take other mitigation steps against side-channel attacks when planning the architecture of your application.
To generate random numbers inside the enclave, you need to use a strong random number generator that cannot be weakened by the host.
The safest way is to use the
SecureRandom class
to generate random numbers. In Conclave enclaves, the implementation of this class uses the RDRAND instruction,
which uses an on-CPU hardware random number generator.
The JDK Random class normally uses the system time as a seed, XORing it with a fixed value
that is updated predictably with each new Random class instance. If you use the JDK Random class, the host can
break the security provided by the random numbers as the time inside the enclave is provided directly by the host.
To prevent accidental use of an insecure random number generator, Conclave XORs the first instance of the system time
with a truly random number derived from the RDRAND instruction. This results in the class using a truly unique
high-entropy seed. Subsequent instances of Random transform the seed to ensure no two sequences are identical, but
the entropy is not renewed using the RDRAND instruction.
For the best quality random data, it is still recommended to use SecureRandom.