Skip to main content

Attacks and mitigations

This section lists possible attacks and how they are mitigated.

Preventing the Generator from learning about or leaking private inputs

Kalypso allows proofs to be generated for circuits involving private inputs. As the term indicates, ideally a Requester wouldn’t want anyone else to learn their values. However, in order for the Generator to generate proofs for such circuits, it is required to have its knowledge. This problem is solved in Kalypso using TEEs. The private inputs are sent encrypted and decrypted only inside enclaves. This allows the Generator to use them for computations without revealing its value outside the enclave.

An issue that can arise here is that the Generator’s enclave can be programmed in such a way that it forwards the decrypted values to a process or server outside the enclave. Kalypso prevents Generators running such malicious enclaves from being able to decrypt the inputs. It enforces a template wrapper around the Prover (called the Generator Image). The Generator Image is written by the Market Creator and is expected to be open-source which can be vetted by Requesters and the community at large.

Only Generators running the authorized Generator Image are able to register in corresponding Markets. This allows only keys generated inside enclaves running vetted code to be used to decrypt inputs. Generators can still optimize the Prover codebase but sandboxing prevents the latter from leaking the inputs to other processes or external networks.

Preventing replay attacks from leaking private inputs

The Requester cannot directly encrypt private inputs with the Generator’s private key as the Generator it will be matched with is not known in advance. It is the Matching Engine which pairs Requests with Generators by publishing the Task. In order to do so, a symmetric key used to encrypt the private input is initially encrypted with the Matching Engine’s public key. The Matching Engine decrypts the key and then re-encrypts it with the chosen Generator’s public key. However, this can lead to a possible attack.

As the Request with the encrypted inputs persists on-chain, a malicious actor can create a new Market authorizing a malicious Generator Image. The Matching Engine itself is agnostic to Markets or to what constitutes a malicious Generator Image. If a conspiring Requester colluding with the Generator created a new Request with replayed private data of a Request from another Market, the Matching Engine would unwittingly re-encrypt the private data using the public key of the malicious Generator allowing it to leak the same.

This attack is prevented by using AES-GCM-AEAD which is explained in the next section on Secure Data Handling.