Here are some buzzwords that we'll talk about in the blog:
Keeping these definitions in mind. The very first question that comes to mind is: Who provides TEE? Who is the boss?
The Operating system (OS). It helps with booting and allocating resources. But what if the OS is malicious or compromised?
Here's where Root of Trust comes into the picture.
Highly reliable hardware, firmware, and software components that perform specific, critical security functions.
Now, if someone actually got control of the OS and thus if you provide the root of trust to the OS then the entire system will collapse😲.
So instead of the root of trust, the modern systems use Trusted Platform Module (TPM).
A TPM (Trusted Platform Module) is used to improve the security of your PC. It is used by services to securely create and store cryptographic keys and to confirm that the operating system and firmware on your device are what they're supposed to be, and haven't been tampered with.
Its job is to boot the system and verify every process
that is part of the program execution(before/during/after program execution ).
Starting with the BIOS, the system verifies if the BIOS is trustworthy or not. By checking if there's a significant amount of crypto used.
Crypto includes generating a hash or signature for security checks (Good thing: We will not go deep into the crypto part).
The TPM compares a known hash with the hash generated by the BIOS. For eg: We can assume that for each entity in the TCP, the computing base, there is an ocean of hash/ signature. The monitor verifies these hashes or signatures to make sure that the entity is secured and should be included in the TCP. If any entity fails the signature or hash then it won't allow being part of TCP.
Each entity entering the TPM goes through the above protocol to build a chain of trust.
Once every entity is done with the hash verification, a final hash is generated for the entire TCB after multilevel hashing.
Whoosh !! Great job if you made it so far. That was a big chunk 🥴
So with those solid concepts in mind let's have a bird-eye view of Intel SGX.
So, a process has both code and data in it. We all want our code and data to be secured and not compromised (they should not affect the confidentiality or integrity) we can use SGX.
SGX are the series of instructions provided by SGX that ensures the creation of a memory area or space inside the DRAM, where that particular space is devoted to an enclave or the secure process.
So each enclave will have its code and data and they have to pass certain checks ✔ every time you want to access this code and data👍
Did not mean to scare you but it is what it is😪. Kidding.
- The key thing from this architectural POV is we used to have our basic virtual to physical translation through these page tables. But we say that an enclave has its own restricted memory space that why do we have this additional structure->
Basically, it's called Enclave Page Cache (EPC) & Enclave Page Cache Manager(EPCM) which manages all these pages that are allocated to the enclave.
Think about a program where a few confidentialities of some things can't be compromised i.e., crucial data, or for your own data confidentiality you can use the SGX runtime Environment.
And in the SGX runtime env. we will be using these pages from the EPC and the EPC manager to track how many pages have been allocated to EPC.
Intel provides the framework to start with some demos and toy examples to play with SGX instructions.
The way Intel SGX guarantees security is that it assumes that the CPU is secure but the memory chip is not secured.
For instance, there will be data centers and servers from where the memory chips can come from various third-party vendors, and that's why it makes sure that data stored in DRAM is actually encrypted.
So, whenever you want to store the data in your DRAM you have to encrypt it and to retrieve the data from the DRAM you have to decrypt it.
And here we are considering the data to be in the enclave, so there will be some additional checks with the normal load request(used to check the DRAM) which sometimes cause latency.
These policies are used for attestation or data sealing.
Example: Let's say two enclaves want to communicate or say that some data is generated by one enclave and the other wants to process it then there are different policies through which these enclaves have to operate.
So, MRENCLAVE or MRSIGNER are the policies we need to create a signature for verification.
The above policy is for enclaves trying to access data from another enclave. But what if normal access (which is not inside an enclave that tries to access from the enclave)----->Page Abort:(
Page Abort is a new term used when a non-enclave code is trying to get access.
The summary is that it tries to isolate a secure code or data creating an enclave that is at the application level. So, if you understand the notion of OS rings it is at the Ring 3 level.
You can do attestation/verification even locally or through a remote platform. You can send it to the Intel server which will verify it and give you a green signal.
DRAM is considered to be untrusted that's why the data is stored in the encrypted format. Every time you need to encrypt and decrypt the DRAM to use and access the data.
And that was all about TEES via Intel SGX. Stay tuned for Vol.2 with AMD.🚀