Secure second-factor authentication for custodial wallets

Institutional custody often involves the management of significant amounts of cryptocurrencies, often from multiple users. The total value under management often runs into billions. While cryptocurrency keys can be managed in hardware security modules (HSMs), which are highly secure, the application communicating 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 can suffer heavy losses. This is an example of the famous Secret Zero problem; While most secrets can be protected in secure environments, at least one secret is left in an environment that could be considered less secure.

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

In this article, I wonder if this approach is indeed more secure and if it solves the Secret Zero problem.

2FA is not useful in insecure environments

In reality, second-factor authentication systems are often deployed in insecure environments. That is, they are often deployed in the same environment as the backend application that manages 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, resulting in heavy losses for the custodial wallet provider and their customers.

When second-factor authentication systems are compromised, such events make headlines. For example, a well-known exchange’s second-factor authentication system was recently compromised and more than 400 users lost somewhere between $30 million and $40 million worth of cryptocurrencies. The exchange took the loss for its own account and compensated the users. But such events damage the reputation of companies that strive to maintain the highest security standards.

The problem isn’t 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 that controls secret null, 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 in the secure HSM environment? This approach has potential, especially if the code deployed can be ‘frozen’; that is, a rogue administrator should not change the authentication code of the second factor.

As mentioned before, 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 unique source.

During user registration, 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 is based on the fact that most computer systems are roughly synchronized in time.

The authenticator app takes the shared token and the current time as input and generates a new TOTP every 30 seconds. When the authenticator wants to access some functionality protected by the authenticator, it calculates the TOTP value and provides it to the authenticator. The authenticator also calculates the TOTP value and then checks whether the TOTP value provided by the authentication matches the locally generated TOTP value. If the values ​​match, the authenticated gets access to the secure functionality.

Custody wallet security can be greatly enhanced by deploying code within the HSM boundary that implements secure TOTP, secure key management, and secure transaction signing. The HSM will not sign a transaction even if the backend system of the custodian wallet is compromised. Transactions can only be signed with user intervention.

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

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

In short, the Secret Zero problem is difficult. It appears in its meanest avatar when it comes to blockchain-based assets that are carriers by nature. Once such assets have been transferred, they cannot be recovered with human intervention.

Under the hood, today’s second-factor authentication systems aren’t as secure as they seem. 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 that states that cryptocurrency transactions never take place unless a user is informed.

Pralhad Deshpande, Ph.D., is senior solution architect at fortanix.