Secure second-factor authentication for custodial wallets

Institutional custody often involves the management of substantial amounts of cryptocurrencies, often belonging to several users. The total value managed is often in billions. While cryptocurrency keys can be managed inside hardware security modules (HSMs), which are highly secure, the application that interacts with the HSM using an API key is often in an environment that is much less secure.

The Secret Zero Problem

If this application misbehaves or is compromised and the API key is stolen, a custodian could see heavy losses. This is an instance of the famous Secret Zero Problem; while most of the secrets can be protected inside secure environments, there is at least one secret that remains in an environment that may be considered less secure.  

The typical way custodial wallet service providers address this issue is by providing a second-factor authentication system. Once a user initiates a cryptocurrency transfer, the user is requested to input a pin number or a time-based one-time password (TOTP) generated by an authenticator app installed on their phones. Google Authenticator and Duo are commonly used authenticator apps.

In this article, I question whether this approach is indeed more secure and whether this approach solves the Secret Zero Problem.  

2FA isn’t helpful in insecure environments

In reality, second-factor authentication systems are often deployed in insecure environments. I.e., they are often deployed in the same environment as the backend application managing the HSM API keys. If this insecure environment is breached by an attacker or malicious insider, the cryptocurrency keys managed by the HSM could be used to sign transactions and this could lead to heavy losses to the custodial wallet provider and their customers.  

When second-factor authentication systems are compromised, such events do make headlines. For example, the second-factor authentication system of a well-known exchange was recently compromised and over 400 users lost somewhere between $30 million to $40 million in cryptocurrencies. The exchange took the loss on their own account and compensated the users. But such events do hurt the reputations of businesses that aim to maintain the highest standards of security.  

The problem is not with second-factor authentication; 2FA is important. The problem lies in how second-factor authentication systems are implemented and deployed. If a second-factor authentication system is deployed in the same insecure environment as the backend app controlling secret zero, then there is no qualitative improvement in the security of the system as a whole.  

A better way to 2FA

What if we could do better? What if instead of deploying the second-factor authentication system in an insecure environment, we deploy it inside the secure HSM environment? This approach has legs, especially if the code deployed can be “frozen”; i.e., a rogue administrator should not be able to modify the second-factor authentication code.  

As mentioned earlier, TOTP is a popular choice for a second-factor authentication system. TOTP is an algorithm that generates a one-time password (OTP) that uses the current time as a source of uniqueness.

At user registration time, the authentication system generates a token and shares it with the user. This token is often presented as a QR code that the user scans with their authenticator app. The TOTP algorithm relies on the fact that most computer systems are roughly time-synchronized with each other.

The authenticator app takes the shared token and the current time as input and generates a new TOTP after every 30 seconds. When the authenticate wants to access some functionality protected by the authenticator, it computes the TOTP value and supplies it to the authenticator. The authenticator also computes the TOTP value and then checks whether the TOTP value supplied by the authenticate matches the locally generated TOTP value. If the values match, the authenticated is granted access to the protected functionality.  

The security of custodial wallets could be significantly improved by deploying code inside the HSM boundary that implements secure TOTP, secure key management and secure transaction signing. The HSM will not sign a transaction even if the custodial wallet’s backend system is compromised. Transactions can only be signed with the user’s involvement.  

During transaction signing, the user provides the TOTP, and the plugin ensures that the transaction is signed only after the TOTP is validated.  

The new architecture is shown in figure 5. In comparison to figure 2, the second-factor authentication service is deployed inside the secure environment of the HSM. Even if the custodial wallet backend is compromised, cryptocurrency transactions cannot be signed without the user being part of the loop.  

In conclusion, the Secret Zero Problem is a tough one. It shows up in its nastiest avatar when dealing with blockchain-based assets that are bearer in nature. Once such assets are transferred, they cannot be retrieved with human intervention.

Under the hood, present-day second-factor authentication systems are not as secure as they appear. A compromised 2FA system often leads to loss of reputation; preventing this loss is critical in the industry. A strong, practical solution to this problem is required. I propose a solution mandating that cryptocurrency transactions never happen unless a user is in the loop.  

Pralhad Deshpande, Ph.D., is a senior solutions architect at Fortanix.