Isolated and attesting TFHE-rs program executor in TEE (AWS NE)

[tomtau]

Zama Grant Program: Application / Isolated and attesting TFHE-rs program executor in TEE (AWS NE)

Please give us as much information as possible on the project you would like to submit. You can find inspiration from our existing list of grants.

• Library targeted: TFHE-rs

• Overview: This project aims to create tools that will allow executing TFHE-rs programs inside AWS Nitro Enclaves and verifying that all FHE operations performed were done correctly (without re-doing the computation). The purpose is two-fold: 1) additional defence-in-depth through a fully isolated execution environment, 2) utilising the cryptographic attestation capabilities of Nitro Hypervisor to produce an attestation document that will prove the enclave identity (and hence prove each FHE program was fully executed in an environment with an untampered TFHE-rs library code). The latter part is of interest, because it will be more efficient than zk-based alternatives (see Fully Homomorphic Encryption and risc zero risc0/risc0#714 How to use tfhe-rs in guest? risc0/risc0#863).

• Description:

Deliverables

The solution would include the following components:

• A helper tooling for preparing TFHE-rs programs (dynamically linked against a particular TFHE-rs version)
• A Dockerfile that can be used to build the Nitro Enclave image (EIF)
• Enclave application to handle the host-enclave vsock-based communication, the Nitro device driver functionality (random seeding and attestation document generation) and a TFHE-rs program execution
• TFHE-rs program loader (to be invoked by the enclave application)
• Client-server protocol description (either in text or a protocol file, e.g. gRPC or cap'n'proto)
• (Server) Host application to proxy the client-server communication to the enclave application
• Client application to allow uploading a bundle with an executable FHE program, a server key and encrypted inputs; and to download computed result and verify the returned attestation document
• Documentation for build and execution steps

Roadmap

Part 1: TFHE-rs program loader and enclave helper tooling

The first project phase explores the foundational tooling needed for the enclave application development. That includes handling TFHE-rs program preparation and loading as well as missing components for the enclave application, such as hyper client implementation over the vsock protocol that is needed for using the AWS SDK for Rust within the enclave application.

Part 2: Enclave app

The second project phase focuses on developing the build environment and the initial Nitro Enclave application. The application will take input bundle (TFHE-rs program, server key, and encrypted inputs) from the host, execute them and return the result altogether with the attestation document that contains user_data corresponding to a compact representation of the input bundle (most likely, cryptographic hashes of input components and the TFHE-rs library version).

Part 3: Host app and Client-Server

The third project phase includes development of the client-server protocol and the host application that handles communication with the enclave application and the outside services. Given the FHE program execution may be a computationally intensive operation, some protocol operations may need to be asynchronous, i.e. the client will be assigned a unique request ID after submitting its execution request and will be able to query its status (enqueued, being processed, error, success) with details and download the computed result and attestation document if they are available.

Part 4: Client app and docs

The fourth project phase involves producing the client application that can submit the input bundles, verify the returned results's attestation and report any problems (hash mismatches, certificate chain verification issues etc.). Besides that, it contains writing up the relevant documentation for the end-to-end deployment and sample application flow.

Macro Sizing (Estimated)

Part 1 : 4-6 days

Part 2 : 6-10 days

Part 3 : 6-10 days

Part 4 : 4-6 days

• Reward: 7.5K-11.5K depending on included components.

• Related links and reference:

https://aws.amazon.com/ec2/nitro/nitro-enclaves/

https://crates.io/crates/aws-nitro-enclaves-nsm-api

https://docs.aws.amazon.com/enclaves/latest/user/verify-root.html

[zama-bot]

Hello tomtau,

Thank you for your Grant application! Our team will review and add comments in your issue! In the meantime:

1. Join the FHE.org discord server for any questions (pick the Zama library channel you will use).
2. Ask questions privately: [email protected].

[aquint-zama]

Hello @tomtau,

The idea of attestation is interesting.
We have more use cases for TFHE-rs than Concrete in mind. What do you think of updating your proposal to go with tfhe-rs?

[tomtau]

@aquint-zama yes, I was originally thinking of TFHE, but then I thought Concrete may be more end user-friendly.
One thing I'm unsure about is how to go about dynamically loading circuits. Concrete has this facility for serializing and loading functions: https://docs.zama.ai/concrete/how-to/deploy
I'm not sure what the best way for it would be in TFHE: the client would use its C API, build a DLL/SO against it and send it (which the enclave app will load)? Or use the WASM API and the enclave app will use a WASM interpreter to load it (plus inject TFHE functions into the interpreter, so that they could be called)?
Or is there a better / simpler way?

[tomtau]

@aquint-zama I updated the proposal for tfhe-rs

[aquint-zama]

We might have some topics in a near future involving secure environment but right now it's hard to give a direction and validate this grant. Keeping the topic for later.

Thanks for your proposition!