# ethdo audit ## Introduction We would like to announce a Request for Proposals (RfP) for a security review of [`ethdo`](https://github.com/wealdtech/ethdo). [`ethdo`](https://github.com/wealdtech/ethdo) is a tool to carry out common operations on Eth2, including creating wallets and accounts, generating data for deposits, and sending exit transactions. ## Table of Contents [toc] ## Version of code for audit The github commit of the code for audit is `b6bb1ba46b34e3732c2fc149333682647bb3c817`, also marked with the tag `v1.5.8`. ## Scope of audit As `ethdo` has a broad range of functionality, it is important to define the scope of the audit. The areas, specific functions and their place in or out of scope of the audit are provided below. ### Wallet management These functions cover wallet creation, import and export, display, _etc._ The specific functions are: - `wallet accounts`: IN SCOPE due to accessing files according to the EIP-2386 and EIP-2680 standards - `wallet create`: IN SCOPE due to creating files according to the EIP-2386 and EIP-2680 standards - `wallet delete`: IN SCOPE due to accessing files according to the EIP-2680 standard - `wallet export`: IN SCOPE due to creating data that should be cryptographically secure and suitable for import - `wallet import`: IN SCOPE due to importing data from `wallet export` - `wallet info`: IN SCOPE due to accessing files according to the EIP-2386 and EIP-2680 standards - `wallet list`: IN SCOPE due to accessing files according to the EIP-2386 and EIP-2680 standards ### Account management These functions cover account creation, import, display, _etc._ The specific functions are: - `account create`: IN SCOPE due to creating files according to the EIP-2335 and EIP-2680 standards - `account import`: IN SCOPE due to creating files according to the EIP-2335 and EIP-2680 standards - `account info`: IN SCOPE due to accessing files according to the EIP-2335 and EIP-2680 standards - `account key`: IN SCOPE due to displaying cryptographic data - `account lock`: OUT OF SCOPE due to being only being used with remote signers - `account unlock`: OUT OF SCOPE only being used with remote signers ### Signature operations These functions cover creation and verification of signatures. The specific functions are: - `signature aggregate`: IN SCOPE due to carrying out cryptographic operations - `signature sign`: IN SCOPE due to carrying out cryptographic operations - `signature verify`: IN SCOPE due to carrying out cryptographic operations ### Validator operations These functions cover creation, monitoring and operations for validators. The specific functions are: - `validator depositdata`: IN SCOPE due to carrying out cryptographic and hashing operations that are required to meet the Ethereum 2 phase 0 specification - `validator exit`: IN SCOPE due to carrying out cryptographic operations that are required to meet the Ethereum 2 phase 0 specification - `validator info`: OUT OF SCOPE due to being purely informational, non-critical, and likely to change with the standardised API ### Deposit operations These functions cover validation of deposit data. The specific functions are: - `deposit verify`: IN SCOPE due to carrying out verification of cryptographic and hashing operations that are required to meet the Ethereum 2 phase 0 specification ### Exit operations These functions cover validation of exit operations. The specific functions are: - `exit verify`: IN SCOPE due to carrying out verification of cryptographic and hashing operations that are required to meet the Ethereum 2 phase 0 specification ### Node and chain information These functions cover fetching and displaying information from an active beacon node. Due to the lack of a standard API at time of writing, they only support the [prysm](https://github.com/prysmaticlabs/prysm) beacon node. The specific functions are: - `block info`: OUT OF SCOPE due to being purely informational, non-critical, and likely to change with the standardised API - `chain info`: OUT OF SCOPE due to being purely informational, non-critical, and likely to change with the standardised API - `chain status`: OUT OF SCOPE due to being purely informational, non-critical, and likely to change with the standardised API - `node status`: OUT OF SCOPE due to being purely informational, non-critical, and likely to change with the standardised API ### Store type `ethdo` allows multiple backend stores of encrypted information. These are as follows: - `filesystem`: IN SCOPE due to being a commonly-used method to access wallets and accounts. - `s3`: OUT OF SCOPE due to being unused to access wallets and accounts by validator clients. - `remote`: IN SCOPE due to being a commonly-used method to access wallets and accounts. ## Dependencies Much of the work in `ethdo`, especially the cryptograhpic work, is carried out by other go modules. The following modules are IN SCOPE for the audit: - [go-eth2-types](https://github.com/wealdtech/go-eth2-types) - [go-eth2-util](https://github.com/wealdtech/go-eth2-util) - [go-eth2-wallet-encryptor-keystorev4](https://github.com/wealdtech/go-eth2-wallet-encryptor-keystorev4) - [go-eth2-wallet](https://github.com/wealdtech/go-eth2-wallet) - [go-eth2-wallet-types](https://github.com/wealdtech/go-eth2-wallet-types) - [go-eth2-wallet-hd](https://github.com/wealdtech/go-eth2-wallet-hd) - [go-eth2-wallet-nd](https://github.com/wealdtech/go-eth2-wallet-nd) - [go-eth2-wallet-store-filesystem](https://github.com/wealdtech/go-eth2-wallet-store-filesystem) In addition to the above modules, many EIPs define standards that `ethdo` implements. Adherence to these standards where applicable is in scope: - [EIP-2335](https://eips.ethereum.org/EIPS/eip-2335) - [EIP-2386](https://github.com/ethereum/EIPs/pull/2386/files) - [EIP-2680](https://github.com/ethereum/EIPs/pull/2680/files) ## Specific areas of focus It is expected that the audit will provide full coverage of the features mentioned above, however the following areas are highlighted as particular areas of concern or sensitivity. ### Random number generation All random number generation (HD seeds, ND private keys) is an obvious area to examine. ### Creation of HD accounts from seed Creation of hierarchical deterministic accounts from a well-known seed should be checked against relevant test vectors. ### Encryption of secrets All situations where keys are sensitive data (private keys, HD seeds) are encrypted should be considered. ### Deposit data generation The generation of deposit data is an important part of the Ethereum 2 deposit process. Adherence to the specification regarding generation of each individual component of the deposit is critical. ## Process summary The entire process can be summarised as follows: 1. **Request:** EF releases RfP (this post) 2. **Gather:** Vendors submit proposals 3. **Deliberate:** EF decides which proposal to accept, and comes up with a plan based on the resources and needs of the accepted proposal. 4. **Propose:** EF proposes the plan to vendor, and makes adjustments based on vendor's feedback 5. **Begin:** Vendor accepts and work begins ## Engagement timeline The proposed timeline of the engagement is approximately 1 month. The engagement is broken up into the following stages: a vendor assessment, followed by a break for developer response and mitigation, followed by a review phase from the vendor. The vendor will then summarize findings and publish the results to help the community understand the work that was done. | Stage | Description | | ------------- |:-------------: | | 1 | Vendor assessment period | | 2 | Developer issue response | | 3 | Vendor review issue response | | 4 | Vendor summarises findings | Members of the EF and `ethdo` contributors will be available at all times to answer questions and comments during the assessment period in order to make life as easy as possible for the vendor. ## Deliverables Deliverable will take the form of Github issues in the [relevant Github repository](https://github.com/wealdtech/ethdo) for every security concern found. As outlined above, the vendor will provide a report distilling the lessons learnt, and summarising the issues submitted. ## Fee Structure ### Invoices Based on the timeline of this audit, the chosen vendor will be expected to submit 2 invoices: - a first invoice of 40% of the total engagement fee at the start of the engagement - a second invoice of 60% of the total engagement fee at the end of the engagement, following the delivery of the summary report and a 5 day review period. ### Payment method The vendor will be given the option to be paid in Fiat money (via bank transfer) or ETH. If the vendor chooses to be paid in ETH, the value of ETH described under the agreement will be the value in USD at NYSE closing time (4 PM EST) on the day prior to the due date (as described at https://www.coingecko.com). ## Selection criteria The selected vendor will have significant expertise in the areas necessary to meet the needs and requirements set forth in this RfP. Particularly: ``` Experience with the Go programming language High level familiarity with cryptographic signature schemes Familiarity with cryptocurrency key management and wallets ``` The EF and `ethdo` maintainers have considerable expertise in these domains and is ready to support the vendor. ## Bidding instructions Upon reception of this request, interested vendors are expected to confirm receipt and intention to bid on the engagement. In this confirmation, they should explain what they need from us in order to get started. As well as bring attention to areas in which they feel they do not have significant expertise. We will use this information to try to provide appropriate entrance material for the engagement. Proposals must be submitted before *September 7th, 12 PM EST*. We expect to take 1 week to deliberate and respond. Please send initial confirmations, and proposals (in PDF format) to the following address: [email protected] _Feel free to send us any questions you may have: [email protected]_