Community Spotlight: This article was guest authored by Forta community member Caner Çıdam, lead developer at OpenZeppelin.
Forta is a real-time detection network for security monitoring of blockchain activity. The decentralized Forta Network scans all transactions and block-by-block state changes, leveraging machine learning to detect threats and anomalies on wallets, DeFi, NFTs, bridges, governance and other Web3 systems. When issues are detected, Web3 infrastructure can respond to prevent attacks via transaction screening and incident response.
Today, Forta Network scan node operators serve an execution layer for detection bots. A Forta scan node is basically a container management software that runs detection bots and publishes their findings. Each detection bot is a Docker container stored at disco.forta.network – the Docker container registry for Forta Network detection bots. The container images are publicly available to anyone.
Using public container images makes distribution easy and does have some benefits in terms of transparency and predictability since this allows anyone to test, audit or run a bot independently. However, this creates challenges when it comes to incorporating sensitive logic, application secrets, and other forms of intellectual property.
The Opportunity
The potential integration of secure enclaves into the Forta Network brings forth a significant feature for the Network. This demonstration reveals how detection bots could operate on Forta without exposing any underlying logic or secrets, relying entirely on AWS Nitro Enclaves. Such integration not only heightens the protection of intellectual property but also guarantees the confidentiality of secret keys for bot developers operating on the network. Although this use case was built using AWS, further developments with secure enclaves can also be hosted on Azure or Google Cloud.
The inclusion of secure enclaves could pave the way for numerous opportunities, like hosting proprietary trading algorithms or industry-secret security monitoring efforts on Forta. Further, the Forta Foundation is considering the possibility of introducing development grants for secure enclaves. Such initiatives could promote the development of highly secure tiers, enabling scan nodes to adapt and promote this feature, and allowing Forta bot developers to tap into these enhanced security capabilities. The future of the Forta Network looks promising.
In this blog post, we are exploring how to use secure enclaves for bot execution purposes. In the past, the Forta Foundation has advised against using sensitive information in detection bot logic. However, this approach might not fully address users’ needs, which is why we’re exploring confidential computing as an alternative.
Confidential Computing
Confidential computing is a relatively new concept in the field of information security, although the basic principles have been around for longer. It has its roots in studies focused on cryptographic techniques and secure multi-party computations, which aims to carry out calculations on encrypted data without exposing the actual information.
Technologies like Intel’s Software Guard Extensions (SGX), introduced in 2015, and ARM’s TrustZone provided hardware-based secure enclaves where data could be processed confidentially. In 2019, Confidential Computing Consortium was formed under the Linux Foundation, gathering industry giants like Google, Microsoft, and IBM to establish standards and accelerate the adoption of confidential computing.
AWS, Azure and Google Cloud have been making their own confidential computing solutions available and supporting applications across sectors like finance, healthcare, and government for securely processing sensitive data.
AWS Nitro Enclaves
An enclave is an isolated and trusted execution environment that can consist of hardware and software features. The host that runs the enclave is able to talk to it but not break into it.
For this experiment, we picked AWS Nitro Enclaves which are available on some tiers of AWS EC2 instances. They can be run as virtual machines which the host machine can communicate through VSOCK.
An enclave is started using an image that is in Enclave Image Format (EIF) which can be prepared by using a tool that converts Docker images to EIF.
If you are interested in experimenting on your own, we recommend visiting this workshop which explains how to set up an enclave and was very useful while working on this experiment.
Measurements
After building each EIF image, the output contains measurements that are“a series of hashes and platform configuration registers (PCRs) that are unique to the enclave”. There are 6 PCR registers in the output which range from the enclave image specific measurement to IAM permissions and instance name.
We focus on the PCR0 value to pay attention only to the image that is ran with the enclave. This image is considered as a Forta-protocol-specific image that gets shipped as part of the node software and is known to the network. The bot will run inside the enclave that starts with this image.
Attestation
One critical feature of AWS Nitro Enclaves is the attestation process. This allows the enclave to prove itself to another service when it needs to access external resources.
The enclave constructs an attestation document that contains certain properties of the enclave, including the PCR0 values. Then, the document is forwarded to the AWS Nitro Hypervisor which only the enclaves have access. The hypervisor signs the document using a key that belongs to AWS Nitro Attestation PKI.
Now, whenever the enclave uses this attestation document to make a request to an external service, the recipient is able to verify that the sender is indeed from AWS Nitro infrastructure.
This documentation explains how to verify AWS Nitro Enclave attestation documents.
AWS KMS
AWS Key Management Service (KMS) supports AWS Nitro attestations out of the box. Using the KMS tool for Nitro Enclaves, the application running inside the enclave is able to make decryption requests to AWS KMS.
However, this requires setting IAM permissions on the KMS key that is interacted with. We imagine in this experiment there are two AWS accounts:
Deployer: This is the account that belongs to the developer of the secret bot. The developer creates an AWS KMS key, allows enclaves to use it for decryption (IAM), encrypts a key and shares it with the network.
Executor: This is the account that belongs to the node operator. It must run the node software with the enclave feature.
If the deployer account allows Forta Network enclaves by setting the PCR0 value in the IAM permissions of the KMS key, then the enclave running in the executor account is able to make cross-account decryption. We trust AWS here to conduct this attestation process to allow exchange between the bot developer and the node operator.
The Puzzle
Now that we know the pieces that explain how Forta bot execution could work, let’s start assembling them together and summarize.
– The bot developer builds an executable piece of software that consists of sensitive vulnerability detection logic and application secrets.
– The bot developer creates a random string that will be used as the bot encryption key.
– Then, the developer proceeds by creating a KMS key and encrypts the bot encryption key, shares it with the network, sets the KMS IAM permissions to allow the PCR0 of Forta enclave image, encrypts the bot software using the bot encryption key and uploads to a public location.
– A node operator registers one of the nodes as a confidential node.
– The network discovers this node and assigns the bot developer’s secret bot to this node.
– The node starts running and discovers the secret bot assignment, downloads the encrypted bot and encrypted bot key, starts the enclave and feeds the data into it.
– The enclave makes a KMS request to decrypt the bot encryption key. This works because the PCR0 in the IAM permissions match.
– The enclave decrypts the encrypted bot and starts running it.
– The node software communicates with the enclave to output findings of the detection bot running inside the enclave.
Q&A
Could anyone send the same attestation request to KMS and decrypt the bot outside of an enclave?
This is not possible because, after verifying the attestation document, KMS encrypts the response data to an enclave specific private key which is not available outside of the enclave (see “What is cryptographic attestation?”).
Does this mean that Forta Network is dependent on AWS to make this feature available?
Forta Network is ran by many node operators that use various types of cloud and VPS servers. It is naturally a mixture of the options currently available online.
Similarly, AWS Nitro is not the only confidential computing solution that exists in the cloud computing space. Azure and Google Cloud have their own services and provide similar functionality and the confidential computing is expanding. Integrating Forta node with multiple confidential computing solutions would allow doing multi-cloud.
How can I trust that some other enclave cannot run my secret bot on demand?
The KMS encryption you set in your AWS account allows only the Forta enclave image identified by the PCR0 register. Other enclave images have different PCR0 register values.
How can I trust that some other node client cannot run my secret bot on demand?
Forta node codebase is publicly available. It is possible that an operator would modify the software to forcefully treat the secret bot as assigned. The PCR0 value would be the right one in this case.
However, the image would be built by the Forta node developers, to reuse in all nodes, and would reject running the secret bot unless assigned by the network. This assignment should be guarded by an expiring signature so that the enclave can verify that the bot was really assigned by the network.
What if the secret bot is a malicious one?
AWS Nitro Enclaves cannot access the internet by default and the access requires whitelisting in the VSOCK proxy. The whitelisting conditions and the protocol mechanism to allow that will need careful consideration in case this feature becomes part of Forta Network.
Requiring higher stake for secret bots could also help in securing the network in this regard since the secret bot would be slashed a high amount if malicious activity is detected.
Share post