Analysis of digital signature: 10 out of 15 top cryptocurrencies do not sign software

Reading another news about the successful substitution of a large project code by an attacker, the question naturally arises: how is this possible at all if the code was signed !? Neglecting the safety rules in the cryptosphere is an oxymoron and, at the same time, a fact, therefore, to prevent this article from turning into a bedridden beating, I selected not newbies for analysis, but cryptocurrencies from the top of the CoinMarketCap rating. And, you guessed it, not in vain.

Let's see how things are with the use of a digital signature in the stronghold of the Fintech revolution.

Motivation

As you most likely know the hacking of official sites and github-profiles of crypto-projects occur quite often, through which the malicious code spreads. Sometimes the addresses of the purses are replaced, in other cases the distributed software is replaced. The hacking methods differ: an attack occurs on one of the network nodes responsible for the delivery of data and a hidden substitution of a piece of data is performed. It is difficult to detect the substitution visually, which is what the attackers use. You can protect yourself from such an attack in several ways. PGP signature is considered standard: publication of signed verification amounts. However, the PGP key must be distributed appropriately. For example, published on various resources (preferably more than two).

Analysis

For analysis, I used official resources, links to which I received from various sources. Then he began to collect information moving from different directions. The analysis took into account the publication of both user software and SDK. Tokens or smart contract-based projects were not taken for analysis, only cryptocurrencies.

results

(*) Ethereum Classic uses third-party software and does not publish information to confirm the release.

Typical mistakes

1. No signature as such ( 10/15 ):
   It may turn out to be unsigned as executable code, but unsigned libraries and application software such as wallets are more common.
2. Signed unpublished keys ( 2/15 ):
   The code is signed by several developers, whose keys are not published anywhere, and accordingly such signatures are useless.
3. Publication of keys and code in one source ( 5/15 ).
   A very common mistake is to publish keys by reference to a third-party resource, or to create a single trusted source in the form of a site. Thus, to substitute data, it is enough to hack only the site.

Atypical errors

Monero offers to watch the keys in the folder with the signed data. In essence, this is a key distribution error, which leads to a complete loss of reliability.

On a note!

• Litecoin publishes keys including as a link to the trusted resource pgp.mit.edu.
• Ethereum and Zcash publish detailed lists of keys:
  
  • https://geth.ethereum.org/downloads/#openpgp_signatures .
  • https://z.cash/support/pubkeys.html .
• Ethereum publishes CI service keys.

The reasons

1. Lack of a unified strategy . At present, there is no instruction that would suit most developers to solve problems of ensuring guaranteed delivery of code on different platforms. Great share of amateur.
2. Moral obsolescence . If you look at the main PGP technology sites, you get the impression that the technology is in oblivion:
   
   • http://pgp.mit.edu/
   • https://keyserver.pgp.com/vkd/GetWelcomeScreen.event
3. Lack of comprehensive tools for publishing and verifying signatures . Even if there is a desire, the user will face serious obstacles on the way - many users are not able and not ready to use the mandatory console for signature verification. Even for developers, using a signature is not a trivial task.
4. Legacy key exchange protocol . In the 21st century, when developers practically do not meet in person, it becomes not very convenient to arrange key exchange on a p2p basis and tools are needed for faster distribution and signature recall.

Tips

Top tips in this situation:

1. Split keys according to tasks (this will help to avoid a master key leak or use a developer key to sign a release).
2. Duplicate information in several sources, for example, on the official website and on Github (hacking two resources at the same time is more difficult than one).
3. Generate human-readable url (they are easier to remember and check).

Instruction

If you are not yet using PGP keys, I strongly recommend including signature verification in the workflow, even if you are not developing financial projects, this skill is best brought to automaticity before you need it. To start is enough on the strength of an hour of time, but then the pleasure obtained afterwards cannot be measured.

Conclusion

Today, the code delivery infrastructure suffers from childhood diseases: fragmentation, lack of established practices, software that does not meet the realities, and developers of even large projects under the watchful eye of thousands of eyes manage to make even the simplest mistakes when it comes to security. So trust, but check%% username!