Store of value / Vulnerabilities in store

Demons in Digital Gold, Part 3

when it comes to standing the test of time, technology and security make strange bedfellows

If you have not already done so, please read the introduction to this series. Each of these posts make a LOT more sense if you have the outlined context.

A store of value is the function of an asset that can be saved, retrieved and exchanged at a later time, and be predictably useful when retrieved.

— Wikipedia

Store of value is the function of money that enables goods and services to be paid for a considerable time after they have been acquired.

— Collins English Dictionary

If you think technology can solve your security problems, then you don’t understand the problems and you don’t understand the technology.

— Bruce Schneier, preeminent cyber-security expert

There are known unknowns. That is to say, there are things that we know we don’t know. But there are also unknown unknowns. There are things we don’t know we don’t know.

— Donald Rumsfeld, no introduction required

Great news! For the duration of this post we accept that crypto-currencies ARE a store of value. We will set aside all of the vigorous debate — strong points made for and against — and declare a fait accompli: Bitcoin (et al) are a store of value (SoV).

“The motivation for this series is to provoke BALANCED thinking,” as stated in the introductory post. So what is left to discuss vis-à-vis SoV, given the “green check mark” status bestowed in the previous paragraph?

This post discusses the security attributes of a store of value, specifically, “security over a considerable time.” Crypto-currencies are enabled by innovative technology that we justifiably celebrate, and ALL innovative technology carry security ramifications.

A remarkable track record

First, big-league kudos are in order for the entirety of “Team Bitcoin” from Satoshi to present day contributors. Billions of dollars in a completely public protocol and database — the blockchain — and no successful hacks against the bitcoin system. That is f — ing amazing! (I am talking about a heist against the BACKBONE — miners, full nodes, peer-to-peer network, blocks, transactions, etcetera — NOT against exchanges and wallet apps.)

The bitcoin system has had the biggest target on its back for the better part of five years (the point of $1B circulating supply), painted by ne’er do wells pining for the combination of ginormous sums of money and the distinct possibility of getting away with a heist. The most gifted hackers worldwide have studied and probed from every angle, to no avail. A remarkable state of affairs from a cyber-security perspective.

And yet — yeah, you just KNEW this was coming — five years is not very long in terms of new and innovative technology. This post is NOT about “everyday” implementation (i.e. code) vulnerabilities. This post tackles the potential of “unkown unknown” PROTOCOL vulnerabilities. While the former can be dangerous, the latter can be dinosaur killers.

“FUD!” I hear the complaints, “You’re talking hypotheticals!” Well, granted, that is the nature of unknown unknowns: things we don’t know that we don’t know. To best frame the potential of protocol vulnerabilities, let’s examine two long-lived and incredibly prevalent technologies that made the wrong kind of headlines in just the past three months.

PLEASE bear with me while I explain these vulnerabilities. These examples build solid common ground before we circle back to “security over a considerable time for a store of value,” and tackle hypotheticals.

KRACK vulnerability in Wi-Fi Protected Access (WPA2)

The earliest Wi-Fi networks were “protected” by a foolhardy veneer that compounded its negligent lack of rigor with a confidence-inspiring name: wired equivalency protocol (WEP). WEP’s security flat-out SUCKED. People wondered if enterprise-grade Wi-Fi security was an intractable problem.

To remedy the situation with a sledgehammer — in order to put security doubts to bed — the Wi-Fi Alliance recruited credentialed cyber-security experts to craft a rock-solid security protocol in the form of WPA2. Published in 2004, the protocol employed the very contemporary advanced encryption standard (AES) still in use everywhere today. Showing great foresight, WPA2 utilized 256-bit AES (most applications stuck with 128-bit AES through 2014).

WPA2 delivered strong security. Yes, there were hacks against individuals and enterprises that failed to follow good security hygiene (for example, not changing a router’s default password). Yes, there were hacks against specific routers from careless vendors (for example, using out-of-date open source firmware). The WPA2 protocol — defined in the public IEEE 802.11i-2004 specification—was never compromised.

As Wi-Fi proliferated, hackers painted a big target on it back. After all, Wi-Fi opened the door to hacking a company’s internal network from their parking lot. And while some of those hacks succeeded, the vulnerabilities were NEVER in the WPA2 protocol. Truly impressive: a completely public protocol accessible from completely public spaces, stood the test of time against gifted adversaries.

The news in October 2017 was a bolt from out of the blue.

This week security researchers announced a newfound, serious weakness in WPA2— the security standard that protects all modern Wi-Fi networks. This is a bad vulnerability in that it likely affects billions of devices, many of which are hard to patch and will remain vulnerable for a long time.

— Electronic Frontier Foundation, 19 October 2017

This was KRACK — an acronym wrestled from the phrase “key reinstallation attacks” — and as vulnerabilities go, it was F — ING BAD.

Concretely, attackers can use this novel attack technique to read information that was previously assumed to be safely encrypted. The attack works against all modern protected Wi-Fi networks. Depending on the network configuration, it is also possible to inject and manipulate data. For example, an attacker might be able to inject ransomware or other malware into websites.

— KRACK website (yes, major vulnerabilities get their own website)

It was so f — ing bad because the flaw was in the WPA2 protocol itself. And while KRACK did impact Wi-Fi routers, the more damaging consequence was that it impacted EVERY device with Wi-Fi. Computers, tablets, mobiles, and the growing plethora of IoT and smart home devices … all vulnerable.

The weaknesses are in the Wi-Fi standard itself, and not in individual products or implementations. Therefore, any correct implementation of WPA2 is likely affected. Note that if your device supports Wi-Fi, it is most likely affected. During our initial research, we discovered that Android, Linux, Apple, Windows, OpenBSD, MediaTek, Linksys, and others, are all affected.

—KRACK website

The only good news: KRACK was discovered by extraordinarily talented researchers at Katholieke Universiteit Leuven (KU Leuven), who followed established conventions and quietly informed Wi-Fi vendors before any public announcement was made. There was no indication that the vulnerability had been exploited by hackers in the wild.

The bad news: EVERY DEVICE with Wi-Fi needed to be patched. Mainstream vendors did a great job, for example, Apple and Microsoft patched the vulnerability in their respective operating systems BEFORE the October announcement. Other vendors lagged and infuriated users, as a SINGLE unpatched device could leave AN ENTIRE network exposed. Many smart home devices remain unpatched to this day.

Key takeaways from KRACK vulnerability:

• Public protocol, extensively vetted by cyber-security experts
• Hundreds of implementations, most including yet more security testing
• Used in billions of devices
• 13 years as an “unknown unknown” before protocol flaw discovered

Spectre vulnerability in processor hardwareIn the first days of 2018, published research revealed that nearly every processor manufactured in the last 20 years contains fundamental security flaws, arising from features built into chips that help them run faster. There is as of yet no evidence that these flaws have been exploited in the wild, but such exploits would be difficult to detect, and the flaws are so fundamental and widespread that security researchers are calling them catastrophic.

— CSO Online, 8 January 2018

Last week saw the announcement of a heretofore unseen type of vulnerability impacting billions of computing devices manufactured in the past 15 years. The dramatically named Meltdown and Spectre vulnerabilities were discovered by a handful of insanely clever researchers, independently and yet simultaneously (a fascinating story in its own right, check it out here).

As was the case with KRACK, the researchers quietly released information on these vulnerabilities to hardware and operating system companies, to give them time to develop and deliver mitigations before going public. Given the number of people “in the know” around the globe, it is astounding that the embargo held for a full six months.

Here, I am going to focus on Spectre. While Meltdown impacts virtually every processor (a.k.a. CPU) manufactured in the past 15 years by Intel, Spectre impacts virtually every processor manufactured in the past 15 years by nearly EVERY manufacturer. Intel and AMD processors in everything from Macs to PCs to servers. ARM processors in tablets and mobiles. Even SPARC processors (if any readers remember those).

Spectre breaks the isolation between different applications. It allows an attacker to trick error-free programs, which follow best practices, into leaking their secrets. In fact, the safety checks of said best practices actually increase the attack surface and may make applications more susceptible to Spectre.

— Meltdown and Spectre website (did you think I was kidding earlier?)

Spectre is a DEFCON-1 level vulnerability (technically, it is a pair of very closely related vulnerabilities):

• The flaw is in the aforementioned processor HARDWARE, so every operating system is affected. Mac OS, iOS, Android, Windows, Linux, you name it. Oh yeah, also every virtual machine hypervisor: the cornerstone of all cloud computing datacenters.
• The flaw enables a malicious program to read data from memory it should NEVER be able to access, including the operating system kernel.
• Therefore , Malware exploiting Spectre can “steal” the most sensitive information in a device’s memory, for example, passwords and cryptographic private keys.
• While all major operating systems were quickly patched against Meltdown, protecting against Spectre is far, FAR more involved. For one thing, operating system kernels AND applications must be recompiled with yet-to-be-determined defensive countermeasures.
• For another thing, the processor microcode must be updated. Few of you know what “microcode” means, and those few likely didn’t know that modern processors STILL have microcode. The only way to deliver said microcode update is via a new UEFI/BIOS … and when was the last time ANYONE updated that on their computer? Anyone? Bueller? Anyone?
• Some processors cannot be patched as described in the previous bullet. In such cases, the only full-and-proper fix is replacing the hardware. Yikes.

Paraphrasing Nigel Tufnel in “This is Spinal Tap”:

There’s something about this that’s so bad, it’s like how much more bad could this be? And the answer is none. None more bad.

Strictly speaking, Spectre is not exactly a protocol vulnerability. It is more accurate to call it a TECHNIQUE vulnerability. Processors spend a lot of time WAITING for data to arrive from memory (including cache memory). Imagine a processor reaches a conditional branch (if … then .. else) and does not yet have the data to resolve the condition. Back in the old days, the processor would twiddle its thumbs waiting for the necessary data before it could determine which fork of the branch to execute. Waiting equals poor processor performance.

A processor employing speculative execution makes an educated guess on the conditional branch and plows ahead along the most likely path. The processor picks the RIGHT path most of the time. Yippee, no waiting and improved performance! Should the processor end up discovering that it selected the WRONG path, it discards all the speculatively executed work, “rewinds” to the branch, and continues along the right path. Speculative execution is so effective that processor performance is greatly improved. Hence, no surprise that this technique is almost universally employed.

The intrepid researchers discovered a FUNDAMENTAL flaw in speculative execution. Not a flaw in a particular implementation, rather, a flaw in the TECHNIQUE of speculative execution. They developed a method to trick the processor into speculatively executing a malicious code snippit that is discarded, while fooling the processor into exposing data in memory.

This is a completely new class of through-the-looking-glass hardware flaw. Processors have multiple (formally) rock-solid mechanisms that prevent applications from reading data that belongs to other applications and ESPECIALLY data that belongs to the operating system. Spectre breaks ALL of those security mechanisms by speculatively executing a “magic” code snippit designed to be discarded. Open f — ing sesame, Spectre malware can read the most sensitive data in memory.

Key takeaways from Spectre vulnerability:

• Public technique, extensively examined and refined and tested
• Hundreds of implementations, every one including more security testing
• Used in billions of devices
• 15+ years as an “unknown unknown” before technique flaw discovered

Security over a considerable time for a store of value

Yes, finally we circle back to the question of security vis-à-vis SoV. And for those few of you that are still reading this post [ed: thanks!], the information is neatly laid out on our freshly built solid common ground.

• An SoV, by definition, remains secure over a considerable time.
• Crypto-currencies are built atop innovative technology of the blockchain.
• Crypto-currencies are a prime target of hackers worldwide.
• Everyone recognizes that ALL technology has bugs. Most of these are discovered and mitigated with minimal “bad stuff” by way of damage.
• History illustrates that fundamental flaws at the PROTCOL and even TECHNIQUE level can exist for over a decade before discovery.
• KRACK and Spectre are examples of such latent vulnerabilities with the potential to inflict immense damage. Lucky for all of us, in both instances the flaws were discovered by The Good Guys.

So what if KRACK had been discovered by The Bad Guys? There is a thriving underground ecosystem for the sale of exploits. A zero-day flaw with the pervasive impact of KRACK would be worth millions of dollars. The exploit would be sold to a small number of the highest bidders — governments and well-to-do criminal enterprises — and would remain under the radar for quite some time. Think about it: Stuxnet and its cousins stayed under the radar for years. Carbanak (below) was only found after the $1B heist. KRACK exploits would be much more difficult to detect in the wild.

And what if Meltdown and Spectre had been discovered by The Bad Guys? An honest-to-goodness dinosaur killer exploit, worth tens of millions of dollars. “Clearly the highest bidders would be governments,” you say with plenty of recent historical precedent to back you up. Maybe not. Malware designed with these exploits might be more valuable to a criminal enterprise targeting financial institutions.

Crazy talk? Hardly! Check out the extraordinary 2015 Carbanak attack on financial institutions in this article. The take? ONE. BILLION. DOLLARS. Now there is a LOT of risk with an attack against financial institutions, regulated corporations with the full hell-and-fury of the best law enforcement agencies working to take down perpetrators. Perhaps a criminal enterprise with high-caliber hacking talent would be better served targeting an equally rich target, in a less regulated space, with a cleaner getaway? Anyone? Bueller? Anyone?

The above little corner of my imagination painted a threat against crypto-currencies that leverages a Spectre-like vulnerability. That’s old school hacking (needing a delivery mechanism) against a contemporary target.

The bitcoin system has had the biggest target on its back … The most gifted hackers worldwide have studied and probed from every angle, to no avail.

Now imagine hackers do eventually avail, [ed: ¿que?] and discover a protocol vulnerability in one of the major crypto-currency blockchains. An unknown unknown, present today, lying latent. How might such a protocol vulnerability manifest itself? Beats the hell out of me! There are things we don’t know we don’t know.

Maybe the flaw enables tilts the table of winning the block mining challenge, greatly reducing the barrier to a 51% attack.

Maybe the flaw facilitates double spends.

Maybe the flaw enables rogue transactions that flat-out steal Bitcoin (et al).

I am NOT suggesting that such a vulnerability exists with ANY probability. What I am suggesting is that the possibility CANNOT be ruled out. EVER.

• Such a possibility is inherent in every technology.
• The probabilities are higher in newer, innovative technology solutions.
• This is at odds with security over a considerable time for a store of value.

I am NOT suggesting that crypto-currencies CANNOT be an SoV. What I am suggesting is that the dreadful, dinosaur killer possibilities outlined in this post need to be incorporated into your decision making process.

I’m here to lay out facts that you may have overlooked. You’re here to reach your own conclusions.

Your turn.

Next in the series …

Mitigating your own “unknown unkowns” [stay tuned!]

Follow me @Pressed250 on Twitter

Copyright © 2018 Bruce Kleinman. All Rights Reserved.

Store of value / Vulnerabilities in store was originally published in Hacker Noon on Medium, where people are continuing the conversation by highlighting and responding to this story.