Blockchain! It’s the latest thing, except that that it’s not really that new. Someone, back in the 80s, was doing successive hashes of a dataset and publishing them in the New York Times “personals” page, to guarantee retroactive non-tampering. [reference below]
The last time I was talking to venture capitalists, they didn’t want to hear about anything that was not blockchain-based, presumably because they didn’t understand it but it sounded almost as cool as quantum, therefore it was time to back the truck up and buy a ton!
Imagine my surprise when my spambots brought me the following:
Blockchain needs more tactical.
This demonstrates one problem with irrevocable anonymous transactions: theft. As soon as people started getting excited about bitcoin I decided to ignore the fad because it was obviously a bad idea, based on incomplete threat models. Unfortunately, that meant that I didn’t make a ton of money like some of my friends did. I have one acquaintance who farmed a big load of bitcoin in the early days, bought some when they were cheap, sold them when they were expensive, and funded a start-up that made him rich indeed – in real money. Oh, well.
There are other problems, some of which have cropped up. First and foremost, it’s not actually the case that bitcoin transactions cannot be tracked by the NSA. Early on there was a large theft of bitcoin and where they disappeared to, nobody knows – but many of us suspect they went into the control of the gnomes at Ft Meade. Once you have a large enough amount of currency, you can trace who is participating in transactions by varying the transaction amount. For example, let’s say I am selling fentanyl online and someone comes to buy a bunch; the price is $19.29. The next buyer gets a price of $19.30. Then I look for someone buying $19.29 worth of bitcoin, or splitting a bitcoin into a piece that adds to $19.29. There’s my buyer. The more transactions we do, the clearer my picture gets. Next time the buyer wants fentanyl, the price is $18.91. Etc. That’s one problem.
The bigger problems that make the bitcoin threat model incomplete are:
- endpoint security
- software supply chain security
- denial of service
- denial of service extortion
- the whole bitcoin infrastructure is a piece of shit
Endpoint security is pretty straightforward. If I’m unlocking my wallet and I’m doing it on a laptop running Microsoft Windows, there’s a decent chance it’s vulnerable to attack or already has malware on it. Let’s assume there’s someone running a keylogger and they’re collecting keylogger data from thousands of laptops, searching for strings that indicate someone is unlocking their bitcoin wallet. For all the fancy cryptography of the blockchain, the wretched system still depends on a user entering a password, and that’s the obvious point of attack, as our spammer above is trying to demonstrate.
Software supply chain: how many people who use bitcoin have taken the source code for their wallet and examined it closely for backdoors, then built their own version of the executable, and run it on an operating system/platform free of backdoors? Nobody. Besides, the processors all appear to be backdoored anyway. But the wallet is not where the real action is, it’s the mining app. Suppose we hop in our time machine and go back a few years and write a bitcoin mining app that is super easy to use, has a lovely interface, and every time it uncovers a bitcoin it rolls dice inside and 1 in 10 times instead of telling the user “here is your new bitcoin!” it sends me the bitcoin and never mentions it to the user. Then I sit back and get rich – it’s the very best way to mine for bitcoin. Basically, this is the capitalist model: the coal mine owner never mines the coal, they let others do the mining and extract “surplus” which is “profit.” So it’s all legit capitalism it’s not even theft.
Denial of service is when you make something unusable; this is also a form of asymmetric attack: you can hurt your target at a low cost, doing high cost damage. [cyberinsurgency] One possibility is that the government eventually gets tired of bitcoin and orders all the ISPs to stop carrying the traffic. It doesn’t have to be 100% effective – even 50% effective would make the system unusably unreliable. Governments like China, with their “Great Firewall” can do this sort of selective blocking if they want to. What happens to the value proposition of bitcoin if people aren’t able to do transactions? Whups.
Denial of service extortion is one I am surprised hasn’t happened yet. The current bitcoin infrastructure has serious performance problems. What if someone developed a capability to jam bitcoin services and make the transactions even slower? How much would it be worth for them not to do that? This is reasonable capitalism, in a world where the government pays farmers not to grow corn – ok, pay me not to send packets. Admittedly, not growing corn is legal but not sending packets is a bit more complicated, and could be a felony. Scratch that, it could get you killed.
The whole bitcoin infrastructure is a piece of shit – that ought to be obvious. Large parts of it are based on basic web technology, which is, itself, a piece of shit. I.e.: SSL. Anyone who things that SSL protects their transactions needs their head examined. Oh, it tries to protect their transactions, it just doesn’t try very hard. Let me introduce you to one of my favorite cryptographers’ paradoxes; I call it the “Paradox of NSA superiority”, namely any cryptosystem that is in widespread use is backdoored or has been cryptanalyzed by the NSA, or it wouldn’t be in widespread use. I know that sounds silly, but it’s actually not. Consider SSL: the original protocol included bidirectional authentication. That would have been nice, right? Why didn’t that happen?
And how did the idea of negotiable encryption options get into the protocol? Anyone who designs encryption systems knows that negotiable options are a yummy point of attack, especially if “clear text, please!” is an option – you just fool the system into negotiating no encryption at all. How did that get into SSL? Well, it was part and parcel of the fallback encryption system being RSA’s RC40 – a 40-bit key system that NSA could blow through like it was toilet paper. How did RC40 wind up in SSL? NSA paid RSA to put it in the mix, that’s how that happened. “Here, world, use this awesome new security system, lol lol lol” said NSA.
http servers (Apache most notably) have a long history of implementation bugs, including many remotely exploitable buffer overruns. Back in the day hackers would pop the stack and fire up a root shell and pwn the system. What if, hypothetically, some agency had a secret exploit and instead of starting a shell they just pulled the server side secret key out of the process memory? A key harvester that used an exploit in this manner would not get noticed by 99.99999% of its targets because it would look like a failed connection, but the attacker can now transparently monitor all SSL coming in or out of that server. That would be useful, I suspect.
Anyway, update your blockchain wallet password. And if you can’t do it, post your password in the comment section and one of us will update it for you.
I thought the original reference to sequential hashing was one of Lamport’s papers, and got sucked into searching through them. Finally I broke down and asked Bill Cheswick, who I know was involved somewhat in it and he immediately replied with [this] Stuart Haber’s bellcore “How to time-stamp a digital document” which, I believe, establishes a great deal of prior art for blockchain.
Why did anyone ever think that TeX fonts were attractive? Gyucch!
Having a large number of btc secretly in government hands would also allow them to crater the market on demand – another useful capability. I cannot imagine the NSA would not realize that, either.
No shit. As of right now, there are 17,756,500 bitcoins that have already been mined. Of those, somewhere in the region of 4 million have been stolen. Since stolen bitcoins continue to circulate, it’s possible (likely, even) that some of those have been stolen more than once, but still, when over 20% of your total money supply has been stolen at some point in its lifetime, you’ve got a problem.
A what? Your sense of humor is subtle.
You might get a kick out of a friend’s investigation: “An Analysis of Fear-Based Enriched Extortion” — https://www.linkedin.com/pulse/you-my-victim-analysis-fear-based-enriched-extortion-zach-cissp
Oh, and Computer Modern is fugly in all incarnations, but TeX Gyre Pagella is sublimely readable (as it should be; it’s a minor variant on Palatino by way of URW’s Palladio.)
Dude? SSL was superseded over 20 years ago. It was proven to be fatally broken in 2014, for those who still supported it at the time (actually quite a few systems, due to the reticence of our friends in Redmond).
SSL and its successors *do* support certificate-based mutual authentication, but it was never widely employed because doing so would require either a global PKI (which would immediately be subverted by every government and criminal enterprise in the world) or be a massive pain in the arse[1] that would severely limit peoples’ abilities to share digital identities across multiple devices[2]. Using TLS-tunnelled password authentication and session tokens is *almost* as good[3] as certificate-based mutual authentication on every connection, with the benefits of being faster and easier to use.
RC4-40 didn’t end up in SSL because the NSA paid RSA Security. For starters, SSL was designed by Netscape, not RSA Security. RC4-40 became a thing because the US Government decided that strong cryptography was a *munition* that could not be exported outside of the US. RC4-40 was a compromise to allow the use of crypto that the NSA could break easily but which they thought that no one else could break at the time. RC4-128 (also part of SSL) was believed to be secure during the 1990s and early 2000s; it was later proven insecure, but it’s unlikely that even the NSA had the ability to break it during the 1990s. The thing that the NSA paid RSA Security to implement was the “Dual EC DRBG” random number generator. This was a legitimate fiasco, but happened 20(-ish) years later and was never part of any SSL or related standard.
If I were to choose the single worst design decision in web applications as we know them, it would be the lack of persistent transport-layer sessions. If we could have a single transport-layer session that lasted the duration of a user session and that all data related to that user session flowed through, then a lot of problems would either go away entirely or be far easier to manage — including problems related to authentication. We didn’t get this because it would have required changes at the operating system layer, but application authors didn’t want to wait for their operating system vendors to implement support for this scenario.
[1]: Some sort of certificate registration protocol with good browser support could have gone a long way towards alleviating the pain of using mutual certificate authentication. Alas, while there was research into the problem and at least a few draft protocols, none of them seem to have ever caught on. But given software authors’ tendencies to use whatever is easiest, I suspect that market forces are far more responsible for this than any sort of government malfeasance.
[2]: Secure digital identity is so much easier if you consider the identity to belong to the device rather than the person, never mind that no one actually wants this. Yes, I’m looking at you, Signal.
[3]: The main main problems with password and session token authentication are that people have to choose and manage passwords and that every application is responsible for generating and managing a session secret. People tend to pick crappy passwords, re-use them, and not store them safely, and applications all too frequently pick crappy session secrets and allow them to be stolen.
To back up unperson @5, the Edward Snowden leaks revealed that the NSA desperately wanted to crack Tor and tails OS as of 2012. Both of them rely heavily on TLS, so the NSA must not have had a back door into that protocol.