Secure Second Factor Authentication for Custodial Wallets

Ever since the invention of Bitcoin, we have seen a tremendous outpouring of computer science creativity in the open community. Despite its obvious success, Bitcoin has several shortcomings. It is too slow, too expensive, the price is too volatile, and the transactions are too public. Various crypto-currency projects in the public space have tried to solve these challenges.

There is particular interest in the community to solve the scalability challenge. Bitcoin’s Proof-of-Work consensus algorithm supports only 7 transactions per second throughput. Other blockchains such as Ethereum 1.0 which also rely on the Proof-of-Work consensus algorithm also demonstrate mediocre performance.

This has an adverse impact on transaction fees. Transaction fees vary with the amount of traffic on the network. Sometimes the fees may be lower than a dollar and at other times higher than fifty dollars.

Proof-of-Work blockchains are also very energy intensive. As of this writing, the process of creating Bitcoin consumes around 91 terawatt-hours of electricity annually. This is more energy than used by Finland, a nation of about 5.5 million.

While there is a section of commentators that think of this as a necessary cost of protecting the entire financial system securely, rather than just the cost of running a digital payment system, there is another section that thinks that this cost could be done away with by developing Proof-of-Stake consensus protocols.

Proof-of-Stake consensus protocols also deliver much higher throughputs. Some blockchain projects are aiming at delivering upwards of 100,000 transactions per second. At this performance level, blockchains could rival centralized payment processors like Visa.

The typical way custodial wallet service providers address this issue is by providing a second factor authentication system. Once a user initiates a crypto-currency 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 blog we question whether this approach is indeed more secure and whether this approach solves the Secret Zero Problem.

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 crypto currency 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 a total of $34 Million in crypto currencies.

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.

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? Fortanix DSM SaaS is a FIPS 140-2 Level 3 compliant platform for secure key management.

It offers a unique security architecture where custom plugins can be developed and deployed to run inside the hardware protected secure environment. The plugin can be protected with a quorum policy that involves multiple admin users.

Once deployed, the plugin code cannot be modified without explicit permissions from multiple administrators.

A popular choice for a second factor authentication system is Time-based One Time Passwords (TOTP). 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 which 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 authenticatee is granted access to the protected functionality.

The security of custodial wallets could be significantly improved by creating a plugin that implements secure TOTP, secure key management and secure transaction signing.

Fortanix provides such a Warm Wallet + Secure TOTP plugin that can be readily deployed inside DSM SaaS. We believe this approach best solves the Secret Zero Problem for custodial wallets.

DSM SaaS 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.

To ensure the security of TOTP, it is important that the shared token that is generated during user registration is only available with the authenticator (DSM SaaS plugin) and the authenticatee.

Particularly, it is important to ensure that the shared token cannot be intercepted by the custodial wallet backend. Our protocol for secure user registration makes sure that the shared token is transferred to the authenticatee in an encrypted form.

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 as shown in figure 7. 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, crypto currency 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. 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 and preventing this loss is critical in the industry. A strong, practical solution to this problem is required and Fortanix provides such a solution.

Our solution guarantees that crypto currency transactions never happen unless a user is in the loop.