Signature The New Challenge of Blockchain Wallet Security

Signature The New Challenge in Blockchain Wallet Security

Unlike traditional centralized services, blockchain wallets do not directly hold users’ assets. They only manage the crucial credentials for interacting with the blockchain, which are private keys. When users make transactions, they need to use their private keys to sign the transactions. If the private keys are leaked or lost, the assets will be at risk of loss.

The Current Status of Signatures

In the early days of blockchain, signatures were relatively simple and low-risk. The main security concern for wallets was how to securely store private keys. With the rise of applications such as DeFi and NFT, on-chain interactions have become increasingly complex. Each DApp project has its unique signature interaction method, and with the dimension of multiple chains and networks, it becomes difficult for most people to understand the information behind these complex signature interactions.

This has also led to new challenges in wallet security. There are multiple signature specifications, making it difficult to parse and present structured data for developers into information that ordinary users can understand. There are also various potential attack methods due to unclear signature displays, such as blind signatures and signature phishing. Recently, the Web3 anti-fraud platform Scam Sniffer detected a user who was phished due to a Perimit authorization and lost 100,000 USDC.

Before exploring solutions to signature challenges, it is crucial to understand the various signature methods.

• Will the bull market return soon? A brief analysis of the six cash ...
• Account Abstraction Simplify Your Crypto World
• The Innovation of Cryptocurrency Zhao Changpeng, a Pioneer of the E...

Methods of Signatures

In order for various applications to seamlessly interact with the blockchain, such as reading block data or sending transactions, there must be a unified connection standard. Taking Ethereum as an example, each Ethereum client adopts a unified JSON-RPC specification.

In this specification, there are interfaces related to signatures, such as eth_sendTransaction and eth_sign. From a technical perspective, signatures can be divided into two categories: off-chain signatures and on-chain signatures. Depending on the specific signature application scenarios, they can be further divided into signature login, signature authorization, signature transfer, and signature contract interaction, etc.

How to Avoid Signature Risks

Different signature scenarios entail different risks, especially when the signature process is complex or unclear, blindly signing may result in asset loss. For wallets, “what you see is what you sign” is the key principle to address blind signature issues. The content that users sign should fully match what they see and expect. To implement this principle, wallets need to ensure that they accurately display the readable information contained in each signature, rather than showing hexadecimal RLP encoding to users. Only in this way can users understand the signature information and the risks involved.

In addition, in unconventional operations, intelligent risk warning mechanisms are also crucial. Next, we will discuss the potential risks and their corresponding strategies for these scenarios.

Signature Login Scenario

1. eth_sign

Ethereum’s earliest offline signature method, which is no longer recommended for use. Because it cannot parse the signature information, it is very easy for risky websites to exploit and forge risky transactions, leading to asset theft. The simplest way is to reject the signature when encountering blind signature information that cannot be parsed and displayed. Because eth_sign signature cannot achieve “see what you sign,” the community has developed standards such as eth_personal_sign and EIP-712 to make the signature visualized.

2. eth_personal_sign

eth_personal_sign is a readable offline signature method, usually used to verify user identity on websites and sign in to websites. Wallets need to clearly display the signature information and details of the source website. In order to display more information about login websites, the current ERC-4361 “Sign In With Ethereum” login network standard has a wide range of support, further enhancing the security of eth_personal_sign.

3. eth_signTypedData

Following the EIP-712 standard, hash or sign structured data, and recommend offline signature. SlowMist mentioned that signTypedData_v4 also has potential security issues. Although the signature information is displayed clearly, it may be an identical signature request initiated by a phishing website and will be abused later.

Therefore, for wallets, not only do they need to support parsing of structured data of signTypedData, but they also need to display the application name and URL of the signature source, as well as the history of interactions. For non-standard EIP-712 wallets, there should also be intelligent risk prompts.

Signature Transfer Scenario

Transfer is the biggest use case for wallets, which involves the transfer of Ethereum’s native token ETH, as well as the transfer of tokens based on the ERC-20 and ERC-721 standards. Other security tools developed by SlowMist, such as MistTrack, provide related risk address labels. Wallets need to intelligently help users intercept or display relevant risk prompts to avoid more people from being deceived.

In addition, there are some unconventional scenarios for transfers, such as transferring to a contract address. Normal wallet transfers are made to EOA ordinary accounts. If the recipient address is a contract address, special attention needs to be paid as there may be risks, although it could also be a contract wallet address. For wallets, it would be helpful to intelligently identify whether an address is a regular address or a contract address, and add special tags to contract addresses to increase user awareness of security.

Signature Authorization Scenarios

1. Approve Authorization

The Approve operation represents granting permission to transfer tokens to a target contract in order to complete transactions automatically. It is commonly used for DEX transaction authorization. For wallets, it is necessary to support displaying authorization details and modifying the authorization amount and duration to avoid increasing the risk exposure due to unlimited authorization. It is recommended to only authorize the required transaction amount each time.

Regarding Approve authorization for an EOA personal address, it is important to note that this operation is highly susceptible to phishing scams. Approve is more commonly used to grant authorization to smart contract addresses, while authorizing personal addresses is an unconventional behavior. Wallets should be able to intelligently recognize this scenario and provide relevant risk prompts.

2. Permit Authorization

Permit is an optimization proposal introduced in EIP-2612 to improve the interaction of ERC-20 standard tokens. When using Approve token authorization under the ERC-20 standard, ETH needs to be paid as gas fees. With the Permit method, users can generate a signature for authorization using their private key offline, and anyone (such as a smart contract) with this signature can directly call the Permit function to transfer tokens without the user having to pay gas fees for the Approve authorization.

However, since EIP-2612 is an extension of ERC-20, the Permit function is only applicable to new tokens, and existing ERC-20 tokens cannot benefit from it. To address this issue, Uniswap proposed the Permit2 standard, which involves calling ERC-20 Approve to authorize the operation of the Permit2 contract.

SlowMist mentioned that Permit is even more dangerous than Approve authorization phishing since obtaining the signature grants authorization. For example, in the order placement function of a DEX, users only need to sign a message to entrust their assets to the DEX for processing without paying gas fees. However, if the DEX is a phishing website and forges malicious messages for users to sign, their assets may be lost. As the Permit signature is an off-chain action, it is difficult for users to notice if their signature has been compromised.

For wallets, not only do they need to be able to parse Permit signature information, but also to avoid phishing websites, they also need to clearly display the source website, helping users judge whether it has been community verified and whether there are unknown risks through the logo and URL.

Scenarios of signature contract interaction

For common DApps such as Uniswap, Sushi, Tokenlon, OpenSea, and cross-chain bridges, wallets also need to support “what you see is what you sign”, displaying the expected changes in the number of tokens after the completion of the transaction, helping users judge whether the interaction meets expectations, and also avoid the risk of zero-dollar purchases from the source.

Conclusion

We have discussed the potential risks and countermeasures for various signature application scenarios, but it is worth noting that this is just the tip of the iceberg. In fact, there are many other risks that have not been mentioned.

In the world of blockchain, new technologies and applications continue to emerge, bringing new challenges and risks. Whether as a wallet developer or a user, it is important to stay informed, understand, and address these risks in order to better utilize the convenience brought by blockchain technology.