Comment on page
Sibyl is Clique's privacy-preserving API solution based on Trusted Execution Environments / TEEs (e.g. Intel SGX). We use these secure enclaves to validate, encrypt, and compute over data accessed through arbitrary private API calls with TLS sessions while ensuring the process has both end-to-end privacy, integrity, and provenance. The execution runs in a hardware-based encrypted memory, preventing adversaries from altering the execution logic or accessing any private data in the memory.
Sibyl currently supports the following features:
- Making arbitrary API calls in a privacy-preserving environment with both guaranteed data provenance and integrity
- Making arbitrary API calls with private parameters, such as API keys, OAuth tokens, and private input for an AI model
- Attach arbitrary computation logic post-API call within a privacy-preserving environment (also allowing for making consecutive API calls)
- Generating zero-knowledge proofs based on attested API call results (integrity guaranteed by Sibyl), where proof-generation can happen both on the client-side and server-side. We support the following proof types written natively in Rust with the Halo2 proving scheme:
- Set membership proofs for proving witness inclusion in a set
- Range proofs for proving that witness value belongs to a range
- Arbitrary regex proofs on JSON/HTML files
- Common TEE hardening techniques like ORAM
- Custom DCAP rules for security configurations of your node
TEEs also provide attestations that allow end users to verify that an authentic enclave actually produces the execution result and is operating as expected. Currently, we use Intel SGX to create on-chain verifiable ECDSA signatures that can be directly verified against Intel’s Root CA. We constantly track potential attack vectors against SGX based on newly released vulnerabilities like Aepic and MMIO. Some of the mitigation measures we have taken to reduce the attack surface include keeping the SGX trusted computing base (TCB) up-to-date, implementing various ORAM techniques, and limiting client diversity by allowing only proven hardware that enforces additional DCAP rules to join the network.