EVMAuth security audit, changes in v0.3.0, and the path to v1.0.0

[sscovil]

Security audit

EVMAuth recently underwent a comprehensive security audit, conducted by an independent third party and sponsored by Radius. That audit revealed several minor issues that have already been addressed, and one griefing attack vector that requires changes to token expiration logic. Specifically, a griefing attack can occur when a bad actor deliberately obtains many of the same EVMAuth token with different expiration timestamps and transfers them to another wallet.

EVMAuth <= v0.2.x keeps track of token balances in an unbounded array, in order to correctly track token expiration for each token (or batch of tokens) purchased or minted at a given time.

The expiration of a token (or batch) is the UNIX timestamp at minting + the TTL of the token. Tokens are burned and transferred in FIFO (first in, first out) order, and there is some logic to remove expired tokens and compact the balance array for an account/token pair, whenever that token is minted, burned, transferred, or purchased.

If the array is too large, minting, burning, transferring, and purchasing methods will run out of gas and revert, effectively blocking the account from taking any further actions with that token ID.

There are several ways to mitigate the attack vector described above, and some situations in which it is not applicable at all:

• EVMAuth tokens that do not expire (i.e. TTL set to 0) are unaffected
• EVMAuth tokens with very short TTLs (up to ~60 seconds) are unlikely to run out of gas, but could be made to use more gas
• EVMAuth tokens that are not available for purchase (i.e. price set to 0) are less likely to be affected, unless the application minting tokens can be made to mint tokens at will by end users

Solution

In the upcoming v0.3.0 release, EVMAuth addresses the problem by constraining the size of the token balance expiration array. By default, the maximum size of the array is 30; this can be modified by overriding the new _maxBalanceRecords method.

The method for calculating when a token expires looks like this:

    function _expiration(uint256 id) internal view returns (uint256) {
        if (!_ttlConfigs[id].isSet) {
            revert ERC6909TTLTokenTLLNotSet(id);
        }

        uint256 ttl = _ttlConfigs[id].ttl;

        if (ttl == 0) {
            return type(uint256).max;
        }

        uint256 exactExpiration = block.timestamp + ttl;
        uint256 arraySize = _maxBalanceRecords();
        uint256 bucketSize = ttl / arraySize;
        if (bucketSize == 0) {
            bucketSize = 1;
        }

        return ((exactExpiration + bucketSize - 1) / bucketSize) * bucketSize;
    }

If the TTL is set to 0, the token does not expire and returns the maximum value for uint256. Otherwise, it calculates the expiration time rounded up to the next bucket size.

To avoid unbounded storage growth, we limit the number of balance records per address, per token id. We lose some precision in the expiration time, but this helps ensure we can store balance records and clean up expired records without running out of gas or hitting storage limits.

We round UP to the next expiry bucket to guarantee AT LEAST the full ttl of the token. For example, if ttl is 30 days and MAX_BALANCE_RECORDS is 30, the bucket size is 1 day, and the expiration will be rounded up to the next day, giving the recipient at most an additional 23:59:59 to use the token.

Changes coming in v0.3.0

The next minor version of EVMAuth will contain many big improvements, breaking changes, better documentation, and more comprehensive test coverage. Here are some of the highlights:

• EVMAuth contracts available in two flavors: ERC-1155 and ERC-6909
• Better code organization and inheritance structure, for maximum extensibility
• 100% test coverage, with more thorough testing for edge cases
• Direct purchase of tokens with ERC-20 tokens (e.g. USDC, USDT)
• All EVMAuth contracts will be upgradeable contracts
• EVMAuth variants will be available with or without expiration logic
• EVMAuth variants will be available with or without direct purchasing functionality

In addition:

• Documentation will be auto-generated using forge doc and published to https://evmauth.io automatically
• Test coverage reports will be pushed to CodeCov
• Another independent security audit will be conducted
• Radius will release a web app to deploy and configure EVMAuth as a managed service, using Beacon Proxies.

Path to v1.0.0

When v0.3.0 is released in the coming days, we will be testing it heavily in several testnet environments. When we are satisfied that it is rock solid—based on our own testing and another independent security audit—we will officially promote the EVMAuth core contracts and SDKs to v1.0.0.

If you would like to contribute, please reply here and review our contributing guide. ❤️

[tantodefi]

Once v1.0.0 - plan to update xmtpauth contracts to use the full evmauth-core contract inheritance. https://github.com/tantodefi/xmtpauth

The xmtpauth XMTP agent will be able to deploy, configure, mint, sell and interact with both the xmtpauth and evmauth-core contracts on all the EVM networks supported by XMTP which are here: https://github.com/xmtp/libxmtp/blob/1c8b647288e13e8c846eeae8743d5dec4c07a8f0/xmtp_id/src/scw_verifier/chain_urls_default.js

Eventually could maybe add the Radius RPC to the list of XMTP supported chains once main-net.

The xmtpauth agent code could also be refactored into more of a turnkey solution for other projects to deploy their own bot that can be used to sell their EVMAuth access tokens to other human/AI users on the xmtp network, if the one deployment fits all model fails (think the botfather for telegram).