Biz & IT —

Scientist-devised crypto attack could one day steal secret Bitcoin keys

Technique exposes weaknesses not only in Bitcoin but also in OpenSSL.

Scientist-devised crypto attack could one day steal secret Bitcoin keys

Exposing a previously unknown weakness in the cryptographic system securing bitcoins, scientists have devised an attack that can steal large amounts of the digital currency when hackers run even unprivileged software on the same computer processing the coins.

The technique, laid out in an academic paper published Wednesday, doesn't pose an immediate threat to Bitcoin users. A successful hack relies on the thief having some access to the same Intel-made processor that processes the targeted bitcoins. That requirement means there would almost certainly be easier ways for the same attacker to pilfer the digital coins. Still, the research is significant because it exposes subtle cryptographic weaknesses not only in a key Bitcoin algorithm, but also in OpenSSL, a widely used code library that implements the core cryptographic protections on the Internet.

The attack relies on "side channel analysis," in which attackers extract a secret decryption key based on clues leaked by electromagnetic emanations, data caches, or other manifestations of a targeted cryptographic system. In this case, cryptographers can retrieve the private key needed to take control of bitcoins by taking minute measurements of the CPU as it makes transactions using the digital currency. Specifically, by observing the last-level (L3) CPU cache of an Intel processor as it executes as few as 200 signatures, an attacker in many cases has enough data to completely reconstruct the secret key needed to take ownership. The attack exploits the way OpenSSL implements the elliptic curve digital signature algorithm (ECDSA) based on a specific curve known as secp265k1 found in Bitcoin.

"We illustrate the effectiveness of the attack by recovering the secret key with a very high probability using only a small number of signatures," the researchers wrote. "After this, we are able to forge unlimited signatures under the hidden secret key. The results of this attack are not limited to ECDSA but have implications for many other cryptographic protocols implemented using OpenSSL for which the scalar multiplication is performed using a sliding window, and the scalar is intended to remain secret."

The findings build off an attack presented in 2012 that pierced a key defense found in cloud environments such as Amazon's EC2 service. Using side-channel analysis, scientists devised a virtual machine that extracted private cryptographic keys stored on a separate virtual machine when both of them ran on the same piece of hardware. It was the first demonstration of a successful side-channel attack on a virtualized, multicore server.

Some restrictions apply

The Bitcoin attack is in many respects more limited. It succeeded only when private keys were interacting with the same CPU that an attacker was monitoring with a specially designed "spy program." What's more, the researchers compiled their own version of OpenSSL that contained "debugging" symbols that mapped the relationship between specific lines of source code and their respective locations in computer memory. Real-world attackers wouldn't have that benefit. Instead, they'd have to go through the considerably more laborious process of reverse engineering the OpenSSL library.

Another mitigation limiting the chances of success: most large cloud providers use highly customized virtualization environments designed to prevent data leakage.

Still, the research is a creative and technically elegant approach that has already captured the attention of cryptographers in both academic and production settings.

The attack "does not require a lot of samples and could have reasonable success with as 'little as 200 signatures,'" Steve Weis, CTO & co-founder of security startup PrivateCore, wrote in an e-mail. He has compiled an ongoing index of side-channel attacks here. "Past side-channel attacks took many more samples to extract key material."

Also significant is the exposure of a side-channel vulnerability of the specific elliptic curve used in the Bitcoin code base, which is generally respected by engineers and cryptographers for its robust security.

"That's significant because there is an actual user base out there relying on secp256k1," Weis said.

Yuval Yarom, a research associate in the University of Adelaide's school of computer science and one of the authors of the paper, agreed.

"It should be noted that irrespective of the weakness in the Intel processors, cryptographic algorithms are not supposed to leak information," he wrote in an e-mail. "Hence, the fact that we can get data out of the OpenSSL implementation is a weakness in OpenSSL and should be fixed."

The paper provides guidance for closing the hole in OpenSSL. And while it remains unlikely the attack represents an immediate threat to end users, there are still precautions they can take. One is to limit the number of times a private key is used to digitally sign Bitcoin transactions. People can do this by creating a chain of wallets and transferring Bitcoins from one wallet to another to reduce the number of signing operations carried out by a single private key. Indeed, experts have long recommended a Bitcoin key be used only once, but this advice is routinely ignored. Another measure is to avoid the use of Intel processors, since the attack doesn't work on modern CPUs made by AMD, Yarom said.

For now, readers should consider the research an important step that's more significant for the new light it shines on the security of Bitcoin and OpenSSL than as a threat that's likely to hit their digital wallets.

"It's an important research finding that adds to our understanding of new side-channel attacks that exploit the software implementation of an encryption system, but not the underlying cryptography itself," Kenneth White, a principal security engineer at Social & Scientific Systems told Ars. "While an important finding, it's not quite sufficient to recommend against storing sensitive data on public cloud VMs. There are certainly enough other glaring attack vectors than L3 CPU cache leaks to prioritize in our security threat models and risk postures."

Channel Ars Technica