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). These are highly secure, the application that interacts with the HSM using an API key is often in a much less secure environment as compere to second factor authentication for custodial wallets.

 

The Secret Zero Problem

 

A custodian could see heavy losses if this application misbehaves or is compromised and the API key is stolen. 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. 

According to HSM, “Custodial wallet service providers typically address this issue by providing a second-factor authentication system. Once a user initiates a cryptocurrency transfer, they are requested to input a PIN or a time-based one-time password (TOTP) generated by an authenticator app installed on their phones. Google Authenticator and Duo have commonly used authenticator apps.”

 

In this article, I question whether this approach is indeed more secure and whether second factor authentication for custodial wallets 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 an attacker or malicious insider breaches this insecure environment, the cryptocurrency keys managed by the HSM could be used to sign transactions, leading to heavy losses to the custodial wallet provider and their customers. 

When second factor authentication for custodial wallets 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 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 second factor authentication for custodial wallets generate 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 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. 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. 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.

 

The countdown is on to #gartneriam in Las Vegas!

Stop by the #Akeyless booth 601 and discover how our SaaS-based #secrets orchestration platform helps organizations secure all their machine & human secrets for hybrid & #multicloud environments. pic.twitter.com/giPUJVN61N

— Akeyless Security (@akeylessio) August 4, 2022

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.