Анализ применения цифровой подписи: 10 из 15 топовых криптовалют не подписывают ПО

в 16:54, , рубрики: pgp, безопасность, информационная безопасность, Криптовалюты, криптография, Программирование, цифровая подпись

Анализ применения цифровой подписи: 10 из 15 топовых криптовалют не подписывают ПО - 1 Читая новость о внедрении в инфраструктуру одного из проектов, я задался вопросом: как вообще обстоят дела с применением цифровой подписи в оплоте финтех революции. Собственно одним лишь любопытством дело не закончилось. Тотально низкая безопасность в криптосфере – оксюморон и факт, поэтому, чтобы данная статья не превратилась в избиение лежачего, я взял криптовалюты из ТОП-15 сайта CoinMarketCap вышедшие в релиз и проанализировал на корректность процедуру подписания кода в этих проектах. Результаты под катом.

Мотивация

Как вы, возможно, знаете периодически происходят взломы официальных сайтов и github-профилей проектов, через которые распространяется вредоносный код. Иногда подменяются адреса кошельков, в других случаях подменяется распространяемое ПО. Способы взлома различаются: происходит атака на один из узлов сети, ответственный за доставку данных и производится скрытая подмена фрагмента данных. Обнаружить подмену визуально достатчно сложно, чем и пользуются злоумышленники. Защититься от такой атаки можно несколькими способами. Стандартным считается PGP-подпись: публикация подписанных проверочных сумм. При этом PGP-ключ должен быть распространен надлежащим образом. Например опубликован на различных ресурсах (желательно больше двух).

Анализ

Для анализа я использовал официальные ресурсы, ссылки на которые получил из разных источников. После чего начал собирать информацию двигаясь с разных направлений. При анализе учитывалась публикация как пользовательского ПО, так и SDK. Для анализа не брались токены или основанные на смарт-контрактах проекты, только криптовалюты.

Результаты

Проект Результат
Bitcoin Core публикация ключа и кода в одном источнике
Ethereum Geth публикация ключа и кода в одном источнике *
Ethereum SDK нет подписи
Parity нет подписи
XRP -
Litecoin публикация ключа и кода в одном источнике
Cardano Daedalus нет подписи
Cardano нет подписи
Stellar неопубликованы ключи
Stellar SDK неподписанные релизы, подпись неопубликованными ключами
IOTA IRI нет подписи
IOTA Wallet нет подписи
Tron Core нет подписи
Tron Wallet нет подписи
Neo Gui нет подписи
Neo Cli нет подписи
Monero публикация ключа и кода в одном источнике
Dash Core публикация ключа и кода в одном источнике
Dash Electrum нет подписи
NEM Nano Wallet нет подписи
NEM NIS неопубликованы ключи
Ethereum Classic **
Qtum Core нет подписи
Zcash неподписанные релизы

( * ) Ethereum публикует ключи по ссылке достоверность которой достаточно трудно подтвердить из-за длины.
( ** ) Ethereum Classic использует сторонее ПО и не публикует информации для подтверждения релиза.

Типичные ошибки

  1. Отсутствие подписи как таковой (10/15):
    Неподписанным может оказаться как код исполняемого кода, но чаще встречаются неподписанные библиотеки и прикладное ПО вроде кошельков.
  2. Подпись неопубликованными ключами (2/15):
    Код подписывается несколькими разработчиками, ключи которых нигде не опубликованы, а соответственно такие подписи бесполезны.
  3. Публикация ключей и кода в одном источнике (5/15).
    Очень частой ошибкой является публикация ключей по ссылке на стороннем ресурсе, либо создание единого доверенного источника в виде сайта. Таким образом для подмены данных достаточно взломать только сайт.

Нетипичные ошибки

Monero предлагает смотреть ключи в папке с подписанными данными. По сути это ошибка дистрибуции ключа, которая приводит к полной утрате надежности.

На заметку!

Причины

  1. Отсутствие единой стратегии. На сегодня нет инструкции, которая подходила бы большинству разработчиков для решения задач обеспечения гарантированной доставки кода на разных платформах. Велика доля самодеятельности.
  2. Моральное устаревание. Если взглянуть на основные сайты технологии PGP, то сразу станет ясно, что технология пребывает в забвении:
  3. Отсутствие комплексного инструментария для публикации и проверки подписи. Даже при наличии желания пользователь столкнется с серьезными препятствиями на пути – многие пользователи не умеют и не готовы использовать консоль обязательную для проверки подписи. Даже для разработчиков использование подписи является нетривиальной задачей.
  4. Устаревший протокол обмена ключами. В 21 веке, когда разработчики практически не встречаются лично, устраивать обмен ключами на p2p основе становится не слишком удобно и нужны инструменты для более быстрого распространения и отзыва подписи.

Советы

Лучшие советы в данной ситуации:

  1. Разделять ключи по задачам (это поможет избежать утечки мастерключа или использования ключа разработчика для подписи релиза).
  2. Дублировать информацию в нескольких источниках, например на официальном сайте и на Github (взломать два ресурса одновременно сложнее чем один).
  3. Формировать человекочитаемые url (их легче запомнить и проверить).

Инструкция

Если вы еще не используете PGP ключи настоятельно рекомендую начать пользоваться ими даже если вы не разрабатываете финансовые проекты, этот навык лучше наработать до того как она вам понадобится. Для старта достаточно потратить 1 час времени:

  1. Скачиваем ПО для управления ключами:
    1. Linux (Не требует установки, используйте gpg2).
    2. MacOS GPG Tools.
    3. Windows GPG4Win.
  2. Генерируем ключ:
    > gpg2 --gen-key
  3. Получаем отпечаток ключа:
    > gpg2 --fingerprint user@localhost
    gpg: checking the trustdb
    gpg: marginals needed: 3  completes needed: 1  trust model: pgp
    gpg: depth: 0  valid:   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 1E85 302D  A9D5 269E 7C5E B852 68BB
    uid           [ultimate] User <user@localhost>
    sub   rsa2048 2018-07-02 [E] [expires: 2020-07-01]
  4. Добавляем ключ в git (см. stackoverflow):
    > git config user.signingkey E5F12C73
  5. Подписываем коммиты с добавлением ключа -S:
    > git commit -S -m 'Signed commit'
  6. Экспортируем ключ:

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

  7. Копируем результат и добавляем в доверенные ключи в интерфейсе Github, Gitlab или Bitbucket.

Заключение

Сегодня инфраструктура доставки кода страдает детскими болезнями: фрагментацией, отсутствием устоявшихся практик, софтом не отвечающим реалиям, а разработчики даже крупных проектов находящихся под пристальным взором тысяч глаз умудряются допускать в том числе и простейшие ошибки, когда дело касается безопасности. Поэтому доверяй, но проверяй %username%!

Автор: Rumkin

Источник

* - обязательные к заполнению поля