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 core||key and code publication in one source|
|Ethereum geth||key and code publication in one source|
|Ethereum SDK||no signature|
|Litecoin||key and code publication in one source|
|Cardano daedalus||no signature|
|Stellar sdk||unsigned releases, signature unpublished keys|
|IOTA IRI||no signature|
|Iota wallet||no signature|
|Tron core||no signature|
|Tron wallet||no signature|
|Neo gui||no signature|
|Neo Cli||no signature|
|Monero||key and code publication in one source|
|Dash core||key and code publication in one source|
|Dash electrum||no signature|
|Nem nano wallet||no signature|
|Nem nis||unpublished keys|
|Qtum core||no signature|
(*) Ethereum Classic uses third-party software and does not publish information to confirm the release.
- 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.
- 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.
- 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.
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:
- Ethereum publishes CI service keys.
- 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.
- Moral obsolescence . If you look at the main sites of PGP technology, you get the impression that the technology is in oblivion:
- 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.
- 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:
- Split keys according to tasks (this will help to avoid a master key leak or use a developer key to sign a release).
- 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).
- 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.
- Download key management software:
- We generate the key:
> gpg2 --gen-key
- 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]
- Adding a key to git (see stackoverflow ):
> git config user.signingkey E5F12C73
- We sign commits with the addition of the -S switch:
> git commit -S -m 'Signed commit'
Export the key:
> gpg2 --armor --export user@localhost -----BEGIN PGP PUBLIC KEY BLOCK----- mQENBFs6VDsBCADzd5F4jaJr7Dzp11+h5CmnRNHGSTWOMQe+TSXljR351BCF9hS6 VrIizaPCVkLW/ATsqdf6vZEApvbQplwHecFPwMpFhusTOILk7lsuXm8w5CscqgBo KiZdSBa9bpWmFrSsPgD8/2VMlQdh+3uChOKapsLo7cHKXNuWX8b1L30twNwgavMc Sel/3clO7Bwp9cFftyktsM/HtSUu1oaE//dibS60HzwmscPHsIIoYsfUSCEOj08f DwK2vLbPilYKyE7fONJpXCSPk5pfDnNxzdFWylNBTQL8benhCtSyfabbtHmeywe+ VWfRAGf/BRjjb7meAMX5vO6qh1l4FfHVo7irABEBAAG0FVJ1bWtpbiA8c3BhbUBy dW1rLmluPokBVAQTAQgAPhYhBOXxLHMEXx6FMC2p1SaefF64Umi7BQJbOlQ7AhsD BQkDwmcABQsJCAcCBhUKCQgLAgQWAgMBAh4BAheAAAoJECaefF64Umi7e4kIALs2 0wbQ0g5557cIbN/eXeK+DsyZFyp3D95RoOnLgWiDknVBluRyPY1QFkjKgNNepMNr 7TM1eNev1CcSDLkuUxlLMrDH9AsAIVWFl7v1+/npJuHkazylU2DgssWICF0yKgWZ tzOQUEDwX7xwIJ3g5v44Lymq0hPi56FVv+rq15hkNsqIOyjDQNVGROUURyO/+vUP khOa2ryjWCpdBzoRNxSyVMlyoABLHwTfXDkCFHV9T7bOa/o0GqILOZ7wCBN9tT5C 38ellwu/HTCtmzZsWvl3a6g8JcunB9yV3RZFQgUDvLEjiVoY2qqn/SWgcl6QR2Ro aEwTKk/p3PU1Foz7mEC5AQ0EWzpUOwEIAPbKGT/xzJ9JvXhMyoOGQZNWkqyXKtV4 zVdfdjxkWMrsMD/C2K1CQ5HPafTM9G/kATGCAmoFPCdLwrc9QqOw3H8PNxnph3Ca irvp0ICj6KDiuCCuptJYICzllKriyLhUDyFkb7GPpRgHpKJZMVCkRbDEau3jcJEx jsdUnjf3gDpEnkuV1pwSxGFxTV3vHNQBqGbFG8mjVkfZSnB++e+tyKPhC5X0QFue K2AlHbnj0/uXZ9wYfRTOJsbW6myR0k1edo7Y5P93fhpW49wwaMTe2Q9p+m6zRguf 8vC9sGUB/eGD9+6OwtIZJ6ZlUa8/MYUBr9er/z+hl7ApdpibChCb8lUAEQEAAYkB PAQYAQgAJhYhBOXxLHMEXx6FMC2p1SaefF64Umi7BQJbOlQ7AhsMBQkDwmcAAAoJ ECaefF64Umi7e3UIAO9ixyXaKmsfWVB11tYPHP+9Xo2s0RRanNMyqAcp1se3jQBZ Z7gfr7DBFBFPU0KeOibWXysMz54hXImxDgYQPKFznzKB5463DiZt8pYjxdphX4/j m6ccw1GnpImRJHpu3mMPSItd/QDqEl87KqSw+IojaLDid3QeL0uRzi2k5/Jwz6ru QMCwdKIMBDPw936YOsfHjQx1RTY9NC59cW1i0lU813By1J80hd24aIJH5vVyYI/I suz153mZUZ+dmN0F6wfnuqNzeCfJRoHKh45ABDD3cRQ2kE76UQ4Kr0xb0G512yUO WJFT8ff3EWn1FulR7bmprA4HHACyx/otL7P777E= =zi5u -----END PGP PUBLIC KEY BLOCK-----
- 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.