FailSafe Proof (Attestation Service)
Overview
The Attestation Service is part of the composable, defence-in-depth FailSafe architecture for protection of Web3 protocols, contracts, and digital assets. The attestation service plays a complementary role to the FailSafe Interceptor, addressing different aspects of the overall attack surface area. The Interceptor deals with an attack in its advanced stage.
For instance, an attacker’s transaction attempting to move tokens from the victim’s EOA is detected in the mempool and intercepted via front running. The capability to transfer tokens out of the victim’s wallet address may have been gained via phishing or private key theft. The attestation service mitigates attacks during earlier stages of the attack and covers areas that go beyond token protection. For example, the protection of blockchain native currencies (ETH, Matic, etc.) or preventing abuse of privileged operations in any arbitrary smart contract. The sections below elaborate on these two scenarios and detail how the attestation service is employed to counter these threats.
Safeguarding Privileged Smart Contract Functionality
We can classify methods on a smart contract into read-only and write operations. For the latter, the methods that change state can be further classified into callable by any address and callable by restricted access (e.g., only callable by contract owner or those that are on an access control list, see OpenZepplin for a common implementation).
Administrative capabilities, such as changing implementation for an upgradable contract, are in this category. If the restricted access is breached, losses may be total, e.g., Ronin Bridge contract compromise via stolen private key).
To raise the security bar, a good strategy is to begin by changing the privileged address on the contract method from an EOA to a multisig wallet (e.g., Gnosis Safe). Once a quorum is reached (n out m signers, e.g., two out of three), the transaction to invoke the privileged method on the target contract is relayed via the Safe Wallet contract. In the Web3 world, the security journey typically ends here. No further consideration beyond more individuals involved in the authorization process. The FailSafe Attestation Service, integrated with Gnosis Safe, adds tried-and-true operational security practices as preconditions for privileged contract method invocation. These include:
Signator’s Geolocation. Are all the signers coming from expected IP ranges?
Threat Intelligence. Are there any anomalous transactions involving addresses that form the quorum of signatures?
Device Intelligence. Are the signers initiating transactions from a new or unrecognised device? If so, has the 2FA challenge been met?
Time-Based Restrictions. Is the transaction being executed in the permitted time window?
Figure 1, below, demonstrates how this works.
For simplicity, in the figure above, let's assume that the contract (in black) that we intend to protect is using Ownable (from OpenZepplin), and all the privileged methods have the OnlyOwner modifier. We will set up and configure a dedicated Gnosis Safe wallet. Once done, ownership will be transferred to the safe wallet address via the transfer ownership method. To go from a standard n of m signature quorum wallet that relays transactions to privileged contract methods to one that also guarantees all of the above operational security requirements have been met (i.e., geolocation, threat intel checks, etc.), we employ the following three system components:
Dedicated Gnosis Safe Guard Contract. A guard is an extensibility mechanism that can be used to enforce additional restrictions on top of the n out of m signature scheme. If configured, the dedicated guard is invoked before a safe transaction is permitted to complete. Thus the guard’s logic can revert a transaction if one or more required conditions have not been met.
Modified Safe Transaction Service. This is a cloud service responsible for collecting all the required signatures on any given transaction before it is submitted to the blockchain (once quorum is reached). Our version of the transaction service will collect geolocation and device related info on the signers and will make this data available to the attestation service.
FailSafe Attestation Service. The attestation service is implemented as part of our multi-regional AWS cloud deployment. Similar to the Failsafe Interception service, it utilises our AWS KMS/Enclave deployment once it is ready to attest (via signature) that all of the attestation requirements (shown in Figure 1, step 2 have been fulfilled).
Gnosis Safe Configuration and the role of the Safe Guard Contract: there are two important aspects to take note of. First, the address controlled by FailSafe attestation service will be added as one of the signatories. For instance, a 2 out of 3 quorum, would become a 2 out of 4 quorum. However, the attestation service's sole purpose is to inform the Safe Guard via its signature that all configured conditions have been met (i.e, geolocation, threat intel, etc.). It should not have the sign-off power, as one of the designated approvers of privileged operations on the target contract. Therefore, the guard contract, once called, will verify that one of the signers is the attestation service and the total number of signers is greater than or equal to quorum + 1.
Safeguarding Native Currency and Other Assets
It should be noted that the Attestation Service and the system configuration outlined in the previous section can be used to protect native currency (ETH, Matic, etc) that is owned by the Gnosis Safe wallet (as illustrated in Figure 2 below). This is complementary to the FailSafe interception service which operates on tokenised assets (requiring an allowance permission). And while the attestation service can aid in protecting tokenised assets too, its existing allowances and gnosis modules (that do not require n of m quorum) are out of its scope.
Figure 2: FailSafe Attestation Service: Native ETH Protection (and Other Assets)
Last updated