A message recently appeared on the bitcoin.org website warning visitors that:
Bitcoin.org has reason to suspect that the binaries for the upcoming Bitcoin Core release will likely be targeted by state sponsored attackers.
The warning does not provide any evidence to back up these claims or specify what kind of attack will be attempted. However, the warning does suggest a mitigation tactic:
The hashes of Bitcoin Core binaries are cryptographically signed with this key .
We strongly recommend that you download that key, which should have a fingerprint of 01EA5486DE18A882D4C2684590C8019E36C2E964. You should securely verify the signature and hashes before running any Bitcoin Core binaries.
The focus on the use of signing keys, signatures, and hashes of the Bitcoin Core binaries to mitigate the risk of installing malware leads to the following assumptions:
- The Bitcoin Core developers are not compromised.
- The private signing keys of the Bitcoin Core developers are not compromised.
- The computers the developers use to build the binaries are not compromised.
- The SSL/TLS connections used to secure the download links for the public signing keys, signatures, and hashes are not compromised.
The conclusion here is that the author of the warning is concerned about an attack where the binaries available for download through official channels will be swapped out for malware, and users who do not check the signatures or hashes risk having their computers infected.
Note: here is a good discussion about the warning on the r/bitcoin subreddit.
Traditional mitigation tactics
The mitigation tactics suggested by the warning rely heavily on SSL/TLS to protect the integrity of the public signing keys, signatures, and hashes that users are expected to check against. Unfortunately, this is not enough to protect against a determined attacker. If the bitcoin.org website is compromised, then any information hosted on the site is suspect. It is also possible for an attacker to compromise an SSL/TLS connection by compromising a Certificate Authority and issuing a fake SSL certificate. The attacker would then use the fake certificate to launch a man-in-the-middle attack on people visiting the target website, in this case to trick them into downloading fake keys, signatures, and hashes (and possibly fake binaries as well).
If users don’t trust the bitcoin.org website or the Certificate Authorities that secure the connection used to download the Bitcoin Core signing keys, then there are two other verification methods that can be used: direct verification or the PGP Web-of-Trust . Direct verification is the strongest method, but can also be the most inconvenient. Users have to verify the PGP fingerprint of the signing key directly with the developer whose key they are trying to verify. This is challenging because it doesn’t scale well. Not everyone is able to meet developers directly, and it would be unproductive for developers to spend all their time verifying their keys with everyone who asks.
One way to scale direct verification is for developers to publish videos where they say their key fingerprints out loud. As long as people trust that the people in the videos are actually the developers and that the videos haven’t been tampered with in any way, this could work quite well. Another way to scale direct verification is through the Web-of-Trust. With the Web-of-Trust, user download the key they want to verify and then use PGP software to see if anyone they trust has signed the key in question to attest to its authenticity. If no one the user trusts has signed the key, or signed the key of someone who signed the key, etc, then the user needs to find someone they trust who they can use to create a chain of trust back to the key in question. Eventually, the user would find someone who trusts someone who trusts… the key in question.
Downsides of traditional mitigation tactics
Both direct verification and Web-of-Trust verification methods are effective, but can be inconvenient. Most users expect software to “just work,” without having to do any extra work to verify the integrity of the software. These verification methods also have a shelf-life. It is standard practice (and good crypto hygiene) for developers to rotate their signing keys after a certain period of time, creating a new keypair every so often to stay one step ahead of attackers. Every time a new keypair is created, the verification process has to be repeated by everyone who trusted the old keypair (unless everyone still trusts the old keypair, in which case developers can just sign their new public key with their old private key to indicate ultimate trust for the new keypair).
What if there was a way for Bitcoin developers to secure updates to their software with the same level of assurance provided by Bitcoin itself, and the same ease-of-use as popular applications like email? This is possible today with software called Blockstack, a decentralized key-value store built on Bitcoin.
Blockstack can combine the benefits of direct verification and the Web of Trust with the ease of use of popular apps like email by linking signing keys to easily-memorable usernames. A Blockstack username, also called a “blockchain ID,” is owned by a bitcoin address. Records associated with the blockchain ID are stored in a file called a “zone file” and cryptographically linked to every Blockstack transaction using the OP_RETURN field. These records can contain any information the user wants to provably link to their blockchain ID.
In this example, the user is a Bitcoin Core developer named Alice, and Alice wants to link her PGP signing key to her blockchain ID. These are the steps Alice would take to secure the next release of Bitcoin Core:
- Obtain a trustworthy copy of Bitcoin Core. This is easy for Alice because she is a Bitcoin Core developer. It is harder for other users due to the aforementioned challenges, but the good news is that a trustworthy copy of Bitcoin Core only needs to be obtained once for this method to work forever (assuming no epic pwnage, etc etc).
- Obtain a trustworthy copy of Blockstack. Same caveats as mentioned in step 1.
- Assuming the username isn’t taken yet, use Blockstack to register the blockchain ID alice in the .id namespace. The full blockchain ID is then alice.id .
- Create a PGP keypair if she doesn’t already have one yet. This will be used to sign software binaries, hashes, and other important messages.
- Update the zone file record for alice.id to include the fingerprint of her public signing key and a link to the key itself so that it is easy to find. Once the zone file update is confirmed in the blockchain, anyone can use Blockstack to look up the new contents of the zone file.
- Advertise ownership of alice.id as publicly as possible. Tell all her collaborators over secure channels, publish messages confirming ownership of alice.id on social media, conference presentation slides, business cards, etc. Anyone who can verify the authenticity of these messages can then use Blockstack to look up alice.id and retrieve Alice’s up-to-date public key. This key will then be used to verify the signatures on updates to Bitcoin Core.
Alice could go even further and register a blockchain ID for Bitcoin Core itself, then update the zone file to include the blockchain IDs of all the other Bitcoin Core developers, as well as the hashes of the latest Bitcoin Core software. The bitcoin address that owns the Bitcoin Core blockchain ID could be a multisignature address that requires signatures from multiple Bitcoin Core developers to update the zone file, preventing Alice from becoming a central point of failure. This is essentially a way to secure Bitcoin software with Bitcoin itself – very meta.
Once Bitcoin Core developers have established a jointly-controlled blockchain ID, users will be able to use the Bitcoin Core blockchain ID as the authoritative source for Bitcoin Core updates without having to rely on untrusted third parties like Certificate Authorities or go through the hassle of direct contact or the Web of Trust every time they need to verify a signing key.
Putting theory into practice
I have taken the initiative to register a blockchain ID for Bitcoin Core: bitcoincore.id . If the Bitcoin Core developers want to use this ID for the purpose described in this post, I am happy to donate bitcoincore.id to the project. To claim the ID, Wladimir J. van der Laan will need tosend me a message signed by a key that I can confirm with any of the Core developers in the SF Bay Area who trust Wladimir’s key and are willing to meet me in person to confirm the key. This message must indicate a desire to claim bitcoincore.id and contain the bitcoin address that Wladimir wants me to transfer the ID to.
By the time I receive such a message from Wladimir, I will assume that he has familiarized himself with Blockstack and understands how to use the software. The exact protocols used to govern control of the blockchain ID address, updates to the ID, and contingencies in case private keys are compromised are to be determined by Wladimir (likely through consultation with the Bitcoin Core community).
More information about the shortcomings of Certificate Authorities, how Blockstack works, and ways this technology can be applied to concepts like the PGP Web-of-Trust can be found in the following links:
Blockstack white paper – describes how Blockstack works.
Blockstack documentation – describes what Blockstack is and how to use it.
Decentralized Public Key Infrastructure white paper – describes how blockchains and similar technologies “address many usability and security challenges that plague traditional public key infrastructure.”
DNSChain – a similar project that pre-dates Blockstack and uses blockchains to fix SSL/TLS vulnerabilities.
DNSChain white paper – describes the problems with SSL/TLS and how DNSChain can fix them.