FailSafe Architecture

Figure 2: FailSafe Architecture

Figure 2 presents a high level view of the overall FailSafe system architecture. Starting at the top, as part of the enrollment process, a factory contract is used to deploy a dedicated user instance of the multi-signature FailSafe contract. As illustrated in the figure, each operation supported by the contract may require one or more independently controlled keys for an authorization before a given operation is executed. For instance, in the example illustrated in the figure, the withdrawal operation (from the contract to the enrolled hot wallet key), requires three independent signatures.

To call the FailSafe Contract’s intercept and rebalance methods, both the FailSafe Interceptor Service and Assets Balancer Service use the dedicated enclave for signing where access to the private keys are subject to the above restrictions. In the Multi-Sig FailSafe contract these operations are configured to require a single signature since the assets are being shifted between addresses under the user’s control based on prior user consented configuration. In contrast, an administrative operation (e.g., updated ratio of hot/cold asset balances) or asset withdrawal, requires multiple independently controlled key signatures. With FailSafe, a user enrols in the AWS Cognito Identity management system which supports multi-factor authentication (MFA).

The user’s Cognito account ID is mapped to the user’s FailSafe Account. Similar to the intercept and rebalance private keys, the private key representing a given user’s auth factor has a corresponding key protected by Nitro Enclave/KMS (this is supported via Cognito identity pool/lambda function auth flow). To mitigate against worst-case insider attacks, the user has another auth factor enrolled and protected by a secondary, independent cloud (GCP) which offers similar key isolation and protection environment via Confidential Compute + KMS with cryptographic attestation proofs.

Next, let's consider how the keys for these operations are managed and protected. As an example, let's consider the intercept key which, as described in the previous section, is required for moving funds from the user’s hot wallet address to the user’s FailSafe contract in the event that a pending fraudulent transaction is detected in the memory pool. As illustrated in figure 2, in the cloud, at rest the intercept key only exists in encrypted form. It is encrypted under the data encryption key that resides in the AWS KMS/Cloud HSM (hardware security module).

The FailSafe system leverages the AWS Nitro Enclave + KMS security architecture. The request to decrypt the intercept key is fulfilled by KMS if 1) the request comes from the expected IAM identity 2) the request is made from the target Nitro enclave. AWS Nitro Enclave is a hardened, isolated execution environment; cryptographic attestation is used to prove to KMS the enclave's identity and the code running in the enclave.