Most people use either an app, an online platform, or a small hardware device as a wallet to store their cryptocurrency safely. The exchanges through which cryptocurrency changes hands, though, and other high stakes operations need something more like a massive digital bank vault. At the Black Hat security conference on Thursday, researchers detailed potential weaknesses in these specially secured wallet schemes, including some that affected real exchanges that have now been fixed.

The attacks aren’t the digital equivalent of jackhammering a weak point on a safe or blowing up a lock. They’re more like opening an old-timey bank vault with six keys that all have to turn at the same time. Breaking cryptocurrency private keys into smaller chunks similarly means an attacker has to cobble them together first to steal funds. But unlike distributing physical keys, the cryptographic mechanisms that underly multiparty key management are complex and difficult to implement correctly. Mistakes could be costly.

“These organizations are managing a lot of money, so they have quite high privacy and security requirements,” says Jean-Philippe Aumasson, cofounder of the cryptocurrency exchange technology firm Taurus Group and vice president at Kudelski Security. “They need a way to split the cryptocurrency private keys into different components, different shares, so no party ever knows the full key and there isn’t a single point of failure. But we found some flaws in how these schemes are set up that are not just theoretical. They could really have been carried out by a malicious party.”

For the work, Aumasson, a cryptographer, validated and refined vulnerability discoveries made by Omer Shlomovits, cofounder of the mobile wallet maker ZenGo. The findings break down into three categories of attacks.

The first would require an insider at a cryptocurrency exchange or other financial institution exploiting a vulnerability in an open-source library produced by a prominent cryptocurrency exchange that the researchers declined to name. The attack takes advantage of a flaw in the library’s mechanism for refreshing, or rotating, keys. In distributed key schemes, you don’t want the secret key or its components to stay the same forever, because over time an attacker could slowly compromise each part and eventually reassemble it. But in the vulnerable library, the refresh mechanism allowed one of the key holders to initiate a refresh and then manipulate the process so some components of the key actually changed and others stayed the same. While you couldn’t merge chunks of an old and new key, an attacker could essentially cause a denial of service, permanently locking the exchange out of its own funds.

Most distributed key schemes are set up so only a predetermined majority of the chunks of a key need to be present to authorize transactions. That way the key isn’t lost entirely if one portion is accidentally eliminated or destroyed. The researchers point out that an attacker could use this fact to extort money from a target, letting enough portions of the key refresh—including the one they control—that they can contribute their portion and restore access only if the victim pays a price.

The researchers disclosed the flaw to the library developer a week after the code went live, so it’s unlikely that any exchanges had time to incorporate the library into their systems. But because it was in an open-source library, it could have found its way into numerous financial institutions.

In the second scenario, an attacker would focus on the relationship between an exchange and its customers. Another flaw in the key rotation process, in which it fails to validate all of the statements the two parties make to each other, could allow an exchange with malicious motivations to slowly extract the private keys of its users over multiple key refreshes. From there a rogue exchange could initiate transactions to steal cryptocurrency from its customers. This could also be carried out quietly by an attacker who first compromises an exchange. The flaw is another open-source library, this time from an unnamed key management firm. The firm does not use the library in its own offerings, but the vulnerability could have been incorporated elsewhere.



Source link