enclave
In the TEA Project, we use hardware TPM to verify a special area called an enclave is trusted. The enclave is a special area inside of a mining node. The area outisde of the enclave is called the parent instance of the enclave.
A parent instance is a regular area that the OS or the miner (human) can access. But the enclave is a special area that the OS and human miners cannot access.
That is to say, anything that's running inside the enclave is unknown to the outside world. It can be compared to the physical concept of a "blackhole horizon". However, an enclave is not a blackhole as the computing result can be sent back to the outside world.
If a data (or code) is supposed to be secret when it's tranferring out from the enclave, it will be encrypted. After encryption, it can be transferred to other nodes or stored to any storage. But when it's loaded into the enclave again, it will be decrypted.
The encryption key is the TPM's hardware key. This key will never be exposed to outside world (see the TPM security documents).
Besides the main key generated by the TPM hardware, there are derived keys that will be used for multiple purpose. All of them will stay inside the enclave's memory at all times. If they have to leave the enclave, they'll be encrypted using a higher level key with the very top level key being the hardware TPM key.
Inside of an enclave, a special stripped version of NixOS (a distribution of the linux operating system) is used. In order to reduce the attack surface, only a few core features are compiled into this special version of the NixOS. Some popular features are forbidden; for example, a file system or networking will not exist inside the enclave.
Since there's no file system or network inside the enclave, an actor's only channel to contact the outside world would be through the vmh (Virtual Messaging Hub). The VMH API is wrapped inside providers. If an actor has a capability, the code in this actor can call the provider's API to send messages to the VMH. The outside components will receive such messages asynchronously.
The TPM genreates the PCR hash array against the enclave. When a verifier is assgiend to remote attest a testee, the testee will send the PCR data signed by the TPM. The verifier first verifies the TPM signature and then verifies the PCR value against the testee's publicly revealed information. If they match, the verifier signs a "true" result to layer one. If not, the verifier signs a "false" result to layer one.
Layer one (blockchain) runs basic BFT to consider whether a testee passes or fails remote attestation or not.
The content of the PCR hash includes all hardware and software fingerprints in the enclave. Any changes to the enclave may cause remote attestation failure.
Every enclave will have a tea_id. This TEAID has an entry in our layer one that stores the verification status. When an enclave wants to contact another enclave, they'll first check their TEAID verification status. If the status is not "verified", the connection will not be estabilished.
Last modified 6mo ago