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

    Reading the next news about the successful substitution of the code of a large project by the attackers, 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, so that this article does not turn into a bedridden beating, I selected for analysis not newbies, but cryptocurrencies from the top of the CoinMarketCap rating. And, you guessed it, not in vain.

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


    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. Detecting a substitution is visually difficult enough, and this is what attackers use. You can protect yourself from such an attack in several ways. PGP signature is standard: publication of signed verification amounts. However, the PGP key must be distributed appropriately. For example, published on various resources (preferably more than two).


    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 the SDK. Tokens or smart contract-based projects were not taken for analysis, only cryptocurrencies.


    Bitcoin corekey and code publication in one source
    Ethereum gethkey and code publication in one source
    Ethereum SDKno signature
    Parityno signature
    Litecoinkey and code publication in one source
    Cardano daedalusno signature
    Cardanono signature
    Stellarunpublished keys
    Stellar sdkunsigned releases, signature unpublished keys
    IOTA IRIno signature
    Iota walletno signature
    Tron coreno signature
    Tron walletno signature
    Neo guino signature
    Neo Clino signature
    Monerokey and code publication in one source
    Dash corekey and code publication in one source
    Dash electrumno signature
    Nem nano walletno signature
    Nem nisunpublished keys
    Ethereum classic*
    Qtum coreno signature
    Zcashunsigned releases

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

    Typical mistakes

    1. The lack of a signature as such ( 10/15 ):
      Unsigned may turn out to be the code of the executable code, but unsigned libraries and application software like wallets are more common.
    2. Signature with unpublished keys ( 2/15 ):
      The code is signed by several developers, the keys of which 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!

    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 sites of PGP technology, you get the impression that the technology is in oblivion:
    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 to verify the signature. Even for developers, using a signature is not a trivial task.
    4. Outdated 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 you need tools for faster distribution and signature recall.


    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).


    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 is not measurable.

    Use GPG with Git
    1. Download key management software:
      1. Linux (No installation required, use gpg2).
      2. MacOS GPG Tools .
      3. Windows GPG4Win .
    2. We generate the key:
      > gpg2 --gen-key
    3. We get the key fingerprint:
      > gpg2 --fingerprint user@localhost
      gpg: checking the trustdb
      gpg: marginals needed: 3  completes needed: 1  trust model: pgp
      gpg: depth: 0valid:   2  signed:   0  trust: 0-, 0q, 0n, 0m, 0f, 2u
      gpg: next trustdb check due at 2020-07-01
      pub   rsa2048 2018-07-02 [SC] [expires: 2020-07-01]
            E5F1 2C73 045F 1E85302D  A9D5 269E 7C5E B852 68BB
      uid           [ultimate] User <user@localhost>
      sub   rsa2048 2018-07-02 [E] [expires: 2020-07-01]
    4. Adding a key to git (see stackoverflow ):
      > git config user.signingkey E5F12C73
    5. We sign commits with the addition of the -S switch:
      > git commit -S -m 'Signed commit'
    6. Export the key:

      > gpg2 --armor --export user@localhost
      -----END PGP PUBLIC KEY BLOCK-----

    7. Copy the result and add to trusted keys in the Github, Gitlab, or Bitbucket interface.


    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. Therefore trust, but check% username%!

    Only registered users can participate in the survey. Sign in , please.

    Do you use a PGP signature

    Also popular now: