Bitcoin welcomes new technology update, Core developers teach you how to verify the client

"Don't Trust, Verify!"

Today, Bitcoin has ushered in new progress. Core developer Luke Dashjr announced the release of the Knos 0.19.1.knots20200304 client.

( Note: Bitcoin Knots is a derivative client of Bitcoin Core, which has some functions not yet implemented by Bitcoin Core. This code base is mainly maintained by Luke Dashjr )

• Bitcoin's Secret History: Why is CSW being mocked by the group?
• The two founders talk about Ethereum: expansion is the number one priority, and more enterprises will use Ethereum in the future
• The company system enters the dusk token economy and the future is expected

Regarding the content of the new client update, you can find it here: https://github.com/bitcoinknots/bitcoin/blob/v0.19.1.knots20200304/doc/release-notes.md

The question before us is, how to verify that the client that I downloaded is secure, and not maliciously tampered with? Of course, it is necessary to ensure downloading from a trusted website, so how can we ensure that the trusted website has not been tampered with by an attacker?

This is what this article is about. The original author is Luke Dashjr.

Here is the translation:

Expect

The following instructions require you to understand how files are stored on your computer (in theory, if you know what directories / folders are), and how to use the command line to run programs and access files. If you don't understand these concepts, start with the guide first.

Please note that the instructions in this article can only help you install the Bitcoin client securely. It will not help you protect your hardware, operating system, or avoid installing other applications that introduce malware. Generally, if your computer is compromised elsewhere, no matter how you verify the client you installed, your node will also be compromised.

If you want an absolutely secure node, in addition to the instructions mentioned in this article, you need to at least avoid using backdoor hardware (including any product made by Raspberry Pi, Intel or AMD) and run only trusted Linux-based Operating system, install or use only software provided by your operating system vendor, or other verified software (as described in this article) using GnuPG, and make sure that the software is updated to the latest bug fix version .

Even if you can't solve these issues and therefore get maximum security, that doesn't mean you should give up: verifying the Bitcoin node software is still a good idea anyway.

Overview

To ensure that the Bitcoin client you have installed is secure, there are three important steps:

1. Verify OpenPGP key;
2. Verify signature
3. Verify the file itself;

Each step depends on the success of the previous step. Although we can skip one step, it is important to understand that unless all steps succeed, we are equivalent to not verifying the installation.

Please note, for example, I will verify my own signature on the Bitcoin Knots v0.19.0.1.knots20200104 client for ppc64le Linux, and to verify someone else ’s signature or other file, you need to change the command line to Use the fingerprint or file name.

Step 0: Install the encryption software GNU Privacy Guard (GPG)

Before you start, you need to make sure you have the GNU Privacy Guard (GPG) tool installed, which is required for encrypted verification of files.

If you are running a Linux-based system, you can usually install it from the operating system vendor (recently, this is usually installed by default), you can check by running gpg --version . If not, try to install using one of the following commands (if it fails, go to the next):

 apt-get install gnupg dnf install gnupg2 yum install gnupg2 emerge app-crypt/gnupg pacman -S gnupg apk add gnupg 

If you are unfortunately using Windows or macOS, you can download GnuPG from the official website, but I do n’t know of any safe way to verify this download. Of course, they do provide a signature, but here comes the chicken and Egg problem: You can't verify these signatures until you have a good copy installed!

Step 1: verify the OpenPGP key

Arguably, this step is the most difficult part of the verification process: you need to confirm that the key you are actually using is the correct key issued by someone you trust. If you are not careful, you may get a fake "Luke Dashjr" key!

Each OpenPGP key has a "fingerprint", which is 40 hexadecimal characters (the numbers 0-9 and aF), and sometimes a space is displayed for easy reading. If you ensure that the key fingerprint used matches the fingerprint of a trusted signer, you know you have the correct key.

Get key or fingerprint

The most secure way to verify the key is to meet in person and confirm the "fingerprint" of the key. Few people remember their key fingerprints, so we may have to look them up on our laptops or phones, and occasionally (usually at meetings) there may be "key signers", a group of people confirming others at the meeting For each fingerprint, each participant either read his own fingerprint aloud or manually confirmed that what everyone saw or heard was correct. If you have the opportunity to participate in such a meeting, this is a good way to verify many keys at once.

If you are not interested or have no chance to meet in person, the keys should ideally be verified from multiple sources. Occasionally, a conference publishes a demo video, where a key fingerprint may appear on a slide. Of course, due to the existence of new technologies such as "deep fake", it should be noted that the slides in the video are easy to manipulate.

Developers usually publish their keys or fingerprints on their website, and there may be other ways (for example, my key or fingerprint will be on personal websites, bitcoinknots.org, bitcoin.org, and GitHub) .

If you have installed a copy of the software you trust, sometimes it will contain the keys needed to verify the update (currently Bitcoin Core only contains source code).

Check the fingerprint of the key file

To view the fingerprint of the key file, you can use the following command:

 gpg --import-options show-only --import --with-fingerprint luke-jr.asc 

This will output a lot of information about the key file, with the relevant information at the top:

 pub rsa8192 2012-03-23 [SC] [expires: 2020-06-09] E463 A93F 5F31 17EE DE6C 7316 BD02 9424 21F4 889F 

In this example, E463 A93F 5F31 17EE DE6C 7316 BD02 9424 21F4 889F is my key fingerprint.

Note: If the GPG prompts that the key has expired, it may not matter! In step 2, you will update to the latest version of the same key, which usually extends the expiration date.

Import a verified key

No matter how you verify the key, you should make sure to remember which key you are using so that you can verify that the same key is used in future updates. Even if you skip the verify key step (which is not secure), at least this will ensure that your updates have the same signer.

When you are sure that the key you have is correct, you can import it like this (replace luke-jr.asc with the file name containing the required key):

 gpg --import < luke-jr.asc 

Or if you only have a fingerprint, like this (put the key fingerprint you want to use!):

 gpg --keyserver hkp://keyserver.ubuntu.com --recv-key E463A93F5F3117EEDE6C7316BD02942421F4889F 

Step 2: Verify the signature

Now that you know what key to use for verification, the next step is to check if the signature is valid.

Before proceeding with this step, you must ensure that a copy of the signer key is up to date. If you don't, you may receive a message that the key has expired. Run (use your desired fingerprint):

 gpg --keyserver hkp://keyserver.ubuntu.com --refresh-key E463A93F5F3117EEDE6C7316BD02942421F4889F 

Next, (in addition to the program file you are checking) you will need two files: a " .assert " file containing a list of file fingerprints and a " .assert " file containing the list signature. This is because what we do is not to sign the program file itself, but to fingerprint all files and then sign the list. Therefore, you need both of these files.

1. The "assert" file pair for Bitcoin Core is posted here: https://github.com/Bitcoin-Core/gitian.sigs/find/master;
2. The "assert" file pair for Bitcoin Knots is posted here: https://github.com/bitconinkots/gitian.sigs/find/Knots

Note that each signer has a separate file pair. If you are verifying that multiple people have signed your file (you should do this), you need to check each file pair. Also, you need to make sure that you are getting the files for the version you want to verify!

Once you find the file you want in the list, click the link to open the file in your browser, then right-click the Raw or Download button and choose Save Link As.

Once you have these two "assert" files, you can check the signature by running (adjust the filename to a specific .assert.sig )

 gpg --verify bitcoin-core-linux-0.19-build.assert.sig 

If this step is successful, you will get the following results:

 gpg: Signature made Sun 19 Jan 2020 03:47:15 AM UTC gpg: using RSA key E463A93F5F3117EEDE6C7316BD02942421F4889F gpg: Good signature from “Luke Dashjr <[email protected]>” [ultimate] 

Note that the fingerprint of the key is shown in bold. The fingerprint must match the key you verified in step 1, otherwise it may be signed by someone else! The part about "good signature" is also important, but the name and email address are not important. If the fingerprint is wrong, both of them may be fake .

Assuming everything went well, you now know that the " .assert " file is guaranteed by the controller of the key in question, and you can continue to verify that your actual program file is listed in the " .assert " file.

Step 3: verify the file itself

To verify a program file, it must first be cryptographically hashed (basically its fingerprints are extracted).

This is done with a simple command (note the replacement of the actual file name you are verifying!):

 Linux: sha256sum bitcoin-0.19.0.1.knots20200104-powerpc64le-linux-gnu.tar.gz Windows: certUtil -hashfile bitcoin-0.19.0.1.knots20200104-win64.zip SHA256 macOS: shasum -a 256 bitcoin-0.19.0.1.knots20200104-osx-unsigned.dmg 

This will output something like:

 d370692590c4546ac0de250da91c6c288d9ee5252f1a4b857a5b80c4e3d81149 bitcoin-0.19.0.1.knots20200104-powerpc64le-linux-gnu.tar.gz 

This is a fingerprint of the file content, followed by the specified file name.

Now open the " .assert " file in any plain text editor / viewer and look for that fingerprint. It should be in the " out_manifest " section at the top, if you reach " in_manifest " or " base_manifests " then you have gone too far.

If you find it in the " .assert " file, then you have verified that the file you own is the same as the one guaranteed by the signer (you will see in the " .assert " file to the right of the fingerprint Their file name, it may be the same as your file name).

And if the file is missing from the " .assert " file, it may indicate that you are using the wrong " .assert " file, or that your files do not match (in this case, you will see next to the expected file name To another fingerprint). If the file is listed but has a different fingerprint, do not open the file, save it (we may ask you for a copy), and contact the security team of the affected project .

We will continue to update Blocking; if you have any questions or suggestions, please contact us!