Защита от повторного использования nonce

Что такое защита от повторного использования nonce?

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

Nonce — это число или уникальное значение, которое в определенном контексте предназначено для однократного использования.

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

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

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

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

В документации Ethereum по аккаунтам объясняется, что у аккаунта Ethereum есть поле nonce и что для каждого аккаунта может быть выполнена только одна транзакция с определенным nonce.

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

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

Ключевые выводы о защите от повторного использования nonce

• • Защита от повторного использования nonce не позволяет принять одно и то же подписанное криптовалютное действие более одного раза.
  • Nonce может быть последовательным, случайным, привязанным к домену, аккаунту или смарт-контракту либо относящимся к отдельной очереди операций.
  • Аккаунты Ethereum, управляемые внешними владельцами (EOA), используют последовательные nonce транзакций для предотвращения повторного выполнения транзакций.
  • EIP-155 добавляет идентификатор сети в данные подписываемой транзакции, снижая риск повторного воспроизведения транзакции в другой сети.
  • Типизированные данные EIP-712 по-прежнему требуют защиты от повторного использования на уровне приложения: если смарт-контракт не отклоняет повторы, типизированную подпись можно отправить несколько раз.
  • В стандарте ERC-2612 permit используются nonce владельца и крайний срок действия, чтобы не допустить бессрочного повторного использования подписей для одобрения токенов.
  • В ERC-3009 используются случайные 32-байтовые nonce и состояние авторизации, предотвращающие повторные переводы с подписью.
  • В смарт-аккаунтах ERC-4337 используется более гибкая модель nonce для абстракции аккаунтов и параллельных сценариев работы.
  • Защита от повторного использования должна также связывать подпись с правильной сетью, смарт-контрактом, функцией, пользователем, крайним сроком и предполагаемым действием.
  • Слабая схема nonce может привести к двойному расходованию средств, повторным разрешениям, зависшим транзакциям, ущербу от кражи подписей, сбоям метатранзакций и кроссчейн-атакам повторного воспроизведения.

Почему атаки повторного воспроизведения важны в криптоиндустрии

Атака повторного воспроизведения происходит, когда кто-то берет действительное подписанное действие и снова отправляет его в систему, которая все еще его принимает.

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

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

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

Повторно отправленный перевод может переместить средства еще раз.

Повторно отправленное разрешение может восстановить возможность расходования токенов.

Повторно отправленный запрос на получение вознаграждения может опустошить пул вознаграждений.

Повторно отправленный голос в системе управления может исказить результат, если смарт-контракт не отслеживает состояние голосования.

Повторно отправленное сообщение моста может привести к ошибочному выпуску или разблокировке активов.

Защита от повторного использования nonce превращает многократно копируемую подпись в разрешение, которое можно использовать только один раз.

Как nonce предотвращает повторное воспроизведение

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

При подписании действия nonce включается в подписываемые данные.

Во время выполнения действия протокол проверяет, действителен ли nonce и не был ли он использован ранее.

Если проверка проходит успешно, действие выполняется, а nonce используется, увеличивается или помечается как использованный.

Если кто-то попытается отправить то же подписанное действие повторно, проверка nonce не пройдет.

С математической точки зрения подпись может оставаться действительной, но система отклонит ее, поскольку nonce уже был использован.

Это важное различие.

Действительность подписи подтверждает, что пользователь авторизовал сообщение.

Актуальность nonce подтверждает, что разрешение еще не было использовано.

Безопасной системе нужны оба условия.

Последовательные nonce

Последовательный nonce — это счетчик, который увеличивается после каждого принятого действия.

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

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

После включения этой транзакции следующей действительной транзакции потребуется nonce 11.

Это не позволяет выполнить две разные транзакции с одинаковым nonce одного аккаунта.

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

Последовательные nonce просты и эффективны для обычных транзакций аккаунта.

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

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

Случайные nonce

Случайный nonce — это уникальное значение, создаваемое случайным образом, а не путем последовательного увеличения счетчика.

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

В ERC-3009 используются случайно сгенерированные 32-байтовые nonce, уникальные для адреса авторизатора.

Стандарт ERC-3009 определяет функцию состояния авторизации и события, фиксирующие, использовался ли nonce авторизации или был отменен.

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

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

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

Для случайных nonce нужен надежный источник случайности.

Если nonce предсказуем или случайно используется повторно, защита от повторного воспроизведения может ослабнуть.

Nonce аккаунта

Nonce аккаунта защищает транзакции, исходящие с одного аккаунта.

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

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

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

Поэтому кошельки тщательно отслеживают следующий nonce аккаунта.

Если кошелек укажет слишком низкий nonce, он может оказаться уже использованным, и транзакция не пройдет.

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

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

Nonce аккаунта защищает от повторного воспроизведения, но одновременно создает практические сложности при управлении транзакциями.

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

Защита от повторного воспроизведения с помощью Chain ID

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

Это стало особенно важно после разделения блокчейнов на форки и роста числа сетей, совместимых с EVM.

В EIP-155 в подписываемые данные транзакции Ethereum был добавлен идентификатор сети.

Благодаря этому транзакция действительна в одной сети и недействительна в другой сети с иным идентификатором.

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

Защита от повторного воспроизведения с помощью Chain ID отличается от защиты с помощью nonce аккаунта.

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

Chain ID помогает не допустить использования той же подписанной транзакции в другой сети.

Для надежной защиты обычно нужны оба механизма.

Разделение доменов

Разделение доменов означает привязку подписи к конкретному контексту подписания.

В него могут входить идентификатор сети, адрес смарт-контракта, название протокола, версия, тип функции, адрес пользователя, nonce и крайний срок.

В EIP-712 определяется подписание типизированных структурированных данных; формат включает поля домена, такие как название, версия, chainId и verifyingContract.

Разделение доменов помогает не допустить, чтобы подпись, предназначенную для одного приложения, принималась другим приложением.

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

Если в подпись не включены сеть и проверяющий смарт-контракт, другой смарт-контракт или сеть могут принять ее как действительную.

Это создает риск повторного воспроизведения, поскольку одну и ту же подпись можно использовать в разных контекстах.

Nonce предотвращает повторное использование в рамках одного контекста.

Разделение доменов помогает не допустить использования в неправильном контексте.

Для безопасной работы с подписями вне блокчейна необходимы оба механизма.

Защита от повторного использования nonce в сообщениях EIP-712

EIP-712 упрощает понимание сообщений для кошельков и пользователей, но сам по себе не делает каждое подписанное сообщение одноразовым.

В разделе безопасности EIP-712 указано, что приложения должны корректно обрабатывать повторное получение одного и того же подписанного сообщения.

Это означает, что смарт-контракт или приложение должны отклонять повторно отправленные подписанные сообщения либо сделать повторное действие безвредным.

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

Типизированное сообщение может содержать крайний срок, но этот срок необходимо проверять в блокчейне.

Типизированное сообщение может содержать проверяющий смарт-контракт, но сам контракт должен правильно проверять разделитель домена.

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

Безопасность при повторном использовании зависит от всей схемы.

Безопасный процесс EIP-712 сочетает разделение доменов, отслеживание nonce, проверку подписи, привязку к действию и проверку крайнего срока.

Отсутствие любого из этих элементов может создать риск повторного воспроизведения.

Защита от повторного использования nonce в ERC-2612 permit

ERC-2612 permit позволяет владельцу токенов одобрить их расходование с помощью подписанного сообщения вместо прямой ончейн-транзакции одобрения.

Это улучшает пользовательский опыт, поскольку другая сторона может отправить подписанный permit от имени владельца.

Стандарт ERC-2612 требует наличия функции nonces и указывает, что при успешном выполнении permit nonce владельца должен увеличиваться.

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

Это не позволяет повторно использовать одну и ту же подпись permit.

В ERC-2612 также предусмотрен параметр крайнего срока.

Он ограничивает время действия подписанного permit.

Это важно, поскольку ретранслятор, получивший permit, может выбрать момент его отправки до истечения срока.

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

Неправильная обработка nonce или крайнего срока в permit может создать серьезный риск для разрешений на расходование токенов.

Защита от повторного использования nonce в ERC-3009

ERC-3009 — это схема авторизации переводов токенов с помощью подписи.

Вместо предварительного одобрения расходования токенов их владелец подписывает разрешение на конкретный перевод.

Перед выполнением перевода смарт-контракт проверяет подпись, период действия и nonce.

В ERC-3009 для отслеживания использованных nonce применяется таблица соответствий authorizationState.

Согласно стандарту, после успешного выполнения разрешенного перевода nonce помечается как использованный.

Это предотвращает повторное выполнение того же подписанного перевода.

В некоторых реализациях ERC-3009 также поддерживается отмена авторизаций.

Поля validAfter и validBefore определяют период действия разрешения.

Такая схема полезна для переводов токенов без газа или через ретранслятор.

Она также показывает, почему защита от повторного воспроизведения — это не просто счетчик.

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

Защита от повторного использования nonce в смарт-аккаунтах ERC-4337

ERC-4337 обеспечивает абстракцию аккаунтов за счет UserOperations и аккаунтов на основе смарт-контрактов.

В стандарте ERC-4337 nonce UserOperation определяется как параметр защиты от повторного воспроизведения.

Кроме того, стандарт требует, чтобы подписи зависели от идентификатора сети и адреса EntryPoint, предотвращая повторное воспроизведение в других сетях или через другие EntryPoint.

В ERC-4337 используется частично абстрагированная модель nonce.

Nonce можно представить как комбинацию ключа и последовательности.

Это позволяет смарт-аккаунтам поддерживать несколько независимых очередей nonce.

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

Это помогает абстракции аккаунтов поддерживать параллельные сценарии работы без потери защиты от повторного воспроизведения.

Такая схема гибче единственного последовательного nonce.

Однако дополнительная гибкость означает, что разработчикам кошельков нужно тщательно управлять очередями nonce.

Очереди nonce

Очередь nonce — это независимая последовательность значений nonce.

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

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

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

Транзакция в очереди восстановления не должна блокировать транзакцию в очереди повседневных расходов.

Очереди nonce повышают гибкость и удобство использования.

Но они также могут усложнить работу, если кошельки не показывают их понятным образом.

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

Если смарт-контракт неправильно проверяет очередь, защита от повторного воспроизведения может оказаться неполной.

Очереди nonce эффективны только тогда, когда их правила легко понять.

Защита от повторного воспроизведения в смарт-контрактах

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

Если смарт-контракт принимает подпись, он должен определять, использовалась ли она ранее.

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

Смарт-контракт для голосования может хранить сведения о том, голосовал ли адрес по предложению.

Смарт-контракт permit может хранить nonce каждого владельца.

Смарт-контракт моста может хранить идентификаторы обработанных сообщений.

Смарт-контракт эскроу на маркетплейсе может хранить хеши исполненных или отмененных ордеров.

Все это — способы защиты от повторного воспроизведения.

Конкретная структура данных может различаться, но цель остается той же.

Смарт-контракт должен не допускать, чтобы одно и то же разрешение приводило к повторным изменениям состояния.

Защита от повторного воспроизведения для мостов

Мостам нужна надежная защита от повторного воспроизведения, поскольку они перемещают стоимость или сообщения между сетями.

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

Если одно сообщение моста можно обработать дважды, в целевой сети может быть выпущено слишком много активов.

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

Целевой смарт-контракт должен помечать каждое действительное сообщение как обработанное.

При повторной отправке того же сообщения он должен отклонить его.

Риск кроссчейн-повторного воспроизведения выше, поскольку в разных сетях могут совпадать форматы адресов, символы токенов и интерфейсы смарт-контрактов.

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

Слабая защита моста от повторного воспроизведения может привести к ошибкам выпуска токенов, потере средств или системному риску для ликвидности.

Защита от повторного воспроизведения для метатранзакций

Метатранзакция — это подписанная пользователем инструкция, которую отправляет другая сторона.

Пользователь подписывает ее вне блокчейна, а ретранслятор отправляет транзакцию в блокчейн.

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

Для метатранзакций необходима тщательная защита от повторного использования nonce.

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

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

Случайные nonce или отдельные пространства nonce для каждого приложения могут уменьшить вероятность конфликтов.

Крайние сроки могут снизить опасность использования старых подписанных инструкций.

Разделение доменов может предотвратить использование подписи метатранзакции одного приложения в другом приложении.

Безопасность метатранзакций зависит от защиты от повторного воспроизведения не меньше, чем от проверки подписи.

Защита от повторного воспроизведения в сообщениях для входа через кошелек

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

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

Сообщение для входа должно содержать nonce или запрос, сгенерированный сервером.

После успешного входа сервер должен пометить этот запрос как использованный.

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

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

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

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

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

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

Защита от повторного воспроизведения в системах управления

Системам управления нужна защита от повторного воспроизведения, чтобы голоса и делегирование учитывались не чаще, чем предусмотрено правилами.

Смарт-контракт голосования может хранить сведения о том, голосовал ли адрес по предложению.

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

Система исполнения предложений может помечать предложение как исполненное после успешного выполнения.

Защита от повторного воспроизведения также важна для межсетевого управления, если решения переносятся в несколько сетей.

Сообщение о голосовании, подписанное для одной сети, не должно автоматически выполняться в другой, если это прямо не предусмотрено.

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

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

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

Даже в таком случае правила окончательного подсчета голосов должны быть четкими.

Защита от повторного воспроизведения при получении аирдропов и вознаграждений

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

В простой системе получения средств может храниться отметка о том, получал ли их каждый подходящий адрес.

Смарт-контракт аирдропа на основе дерева Меркла может проверить доказательство пользователя, а затем пометить адрес или индекс получения токенов как использованный.

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

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

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

Подписанный запрос для кампании A не должен действовать в кампании B.

Запрос на получение средств в одной сети не должен действовать в другой, если это специально не предусмотрено.

Запрос на получение одного токена не должен давать право получить другой токен.

В правильно спроектированной системе запрос на получение средств привязан к нужному пользователю, кампании, сети, токену, сумме и nonce.

Защита от повторного воспроизведения и крайние сроки

Крайний срок — это временное ограничение действия подписанной авторизации.

Крайний срок не заменяет nonce, но сокращает период, в течение которого украденную или задержанную подпись можно использовать.

В ERC-2612 permit используется поле крайнего срока.

В ERC-3009 используются поля validAfter и validBefore.

В UserOperations ERC-4337 можно задавать периоды действия с помощью данных проверки.

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

Без крайнего срока старая подписанная авторизация может оставаться действительной гораздо дольше, чем ожидал пользователь.

После установленного времени подпись с крайним сроком становится недействительной.

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

Оптимальный срок действия зависит от стоимости и риска действия, его срочности и ожидаемого времени расчетов.

Защита от повторного воспроизведения и идемпотентность

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

В EIP-712 отмечается, что приложения должны отклонять повторно отправленные подписанные сообщения или делать разрешенное действие идемпотентным.

Например, если дважды задать одно и то же имя профиля пользователя, это может быть безвредно.

Дважды перевести 100 токенов — не безвредно.

Повторное одобрение расходования токенов может быть вредным или безвредным в зависимости от суммы и текущего лимита разрешения.

Повторное голосование может быть вредным, если оба голоса будут учтены.

Повторное получение вознаграждения вредно, если пользователь получит его дважды.

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

В большинстве операций с перемещением ценностей повторы следует отклонять.

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

Защита от повторного воспроизведения и привязка подписи

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

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

Если подпись разрешает только неопределенное действие, злоумышленник может применить ее в более широком контексте.

Если в подписи указано только число, но не адрес токена, его можно интерпретировать как разрешение для другого токена.

Если в подписи указан только адрес назначения, но не идентификатор сети, ее можно повторно использовать в другой сети.

Если в подписи указан только адрес пользователя, но не адрес смарт-контракта, ее может принять другой смарт-контракт.

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

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

Широкая подпись создает возможности для повторного использования, злоупотребления и непонимания со стороны пользователя.

Перед подписанием кошельки должны четко показывать все эти сведения.

Защита от повторного воспроизведения и фишинг

Защита от повторного использования nonce не может полностью защитить пользователей от фишинга.

Если пользователь подпишет вредоносное сообщение с действительным nonce, злоумышленник сможет использовать его один раз.

Nonce может предотвратить повторное использование, но первое применение все равно может нанести ущерб.

Например, фишинговый сайт может попросить пользователя подписать permit, который дает разрешение на расходование токенов.

В permit могут быть указаны действительный nonce и крайний срок.

После отправки злоумышленник все равно сможет воспользоваться этим действительным разрешением.

Защита от повторного воспроизведения предотвращает дублирование, но не злонамеренные действия.

Пользователям все равно необходимо проверять, что именно они подписывают.

Кошельки по-прежнему должны показывать понятные предупреждения.

Смарт-контракты по-прежнему должны ограничивать подписи конкретными действиями.

Защита от повторного воспроизведения и опережающие транзакции

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

Защита от повторного использования nonce может ограничить ущерб, позволяя применить подпись только один раз.

Однако она не всегда не позволяет опередившей стороне первой воспользоваться подписью.

В ERC-2612 отмечается, что другая сторона может опередить предполагаемого отправителя и первой вызвать permit, хотя итоговое разрешение для подписавшего пользователя может быть тем же.

В ERC-3009 предусмотрена функция receiveWithAuthorization, которая снижает риск некоторых опережающих транзакций: получатель должен совпадать с вызывающей стороной.

Это показывает, что защита от повторного воспроизведения и защита от опережающих транзакций связаны, но не тождественны.

Nonce предотвращает повторное выполнение.

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

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

Разработчикам не следует считать, что одна только проверка nonce решает все проблемы атак на мемпул.

Защита от повторного использования подписи в разных смарт-контрактах

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

Это может произойти, если подписываемые данные не содержат адрес проверяющего смарт-контракта.

Разделение доменов EIP-712 помогает снизить такой риск, добавляя verifyingContract в домен.

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

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

Например, два смарт-контракта токенов могут принять одно и то же сообщение, похожее на permit, если подписываемые данные слишком общие.

Пользователь может намереваться одобрить расходование одного токена, но ту же подпись можно будет интерпретировать как разрешение для другого.

Поэтому привязка к адресу смарт-контракта крайне важна.

Действительная подпись не должна свободно переходить между смарт-контрактами.

Она должна быть привязана к конкретной области проверки.

Защита от повторного использования подписи в разных сетях

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

EIP-155 снижает этот риск для транзакций в стиле Ethereum, добавляя идентификатор сети в хеш подписываемой транзакции.

В типизированных данных EIP-712 также поддерживается chainId в домене подписания.

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

Например, в подписи для моста, DAO, permit токена или входа в систему следует указывать нужную сеть, если это имеет значение.

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

Пользователь может контролировать один и тот же адрес в нескольких сетях.

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

Без привязки к сети подпись можно опасно легко переносить между сетями.

В безопасной схеме сеть указывается явно.

Защита от повторного воспроизведения и замена транзакций

Замена транзакции — это отправка пользователем новой транзакции с тем же nonce аккаунта и более высокой комиссией, чтобы заменить ожидающую транзакцию.

Сама по себе такая операция не является атакой повторного воспроизведения.

Во многих сценариях работы с Ethereum это обычный способ управления транзакциями.

Важно, что в итоге может быть выполнена только одна транзакция с данным nonce.

Пользователь может заменить медленную транзакцию более быстрой.

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

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

Именно защита от повторного использования nonce делает замену возможной.

Nonce заставляет сеть выбрать для этого порядкового номера только одну транзакцию.

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

Защита от повторного воспроизведения и зависшие транзакции

Транзакция может зависнуть, если комиссия за нее слишком низкая и она долго остается в ожидании.

Если у нее следующий необходимый nonce, последующие транзакции с того же аккаунта тоже могут ждать ее обработки.

Это побочный эффект последовательных nonce.

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

Пользователю может потребоваться ускорить или отменить зависшую транзакцию, отправив заменяющую с тем же nonce.

Обычно кошельки управляют этим автоматически, но ручная настройка nonce может вызвать путаницу.

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

Если пользователь укажет слишком низкий nonce, транзакция может завершиться ошибкой, поскольку он уже использован.

Защита от повторного использования nonce оберегает аккаунт, но при этом требует тщательно соблюдать порядок транзакций.

Опытным пользователям следует проверять состояние nonce, прежде чем вручную изменять их в транзакциях.

Защита от повторного воспроизведения и ключи сессионного доступа

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

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

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

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

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

Без ограничений на действия такой ключ может получить слишком широкие полномочия.

Очереди nonce могут отделить действия ключа сессионного доступа от действий основного кошелька.

Это может упростить работу с кошельком, сохранив защиту от повторного воспроизведения.

Ключи сессионного доступа должно быть легко отзывать.

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

Защита от повторного воспроизведения и кошельки с мультиподписью

Кошелькам с мультиподписью также нужна защита от повторного воспроизведения.

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

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

После выполнения транзакции кошельком nonce увеличивается или хеш транзакции помечается как исполненный.

Это не позволяет повторно использовать тот же набор подписей для выполнения одного действия дважды.

Защита от повторного воспроизведения в мультиподписи должна привязывать подписи к адресу кошелька, идентификатору сети, адресу назначения, сумме, данным, типу операции и nonce.

Если кошелек с мультиподписью развернут в нескольких сетях, защита от повторного воспроизведения между ними особенно важна.

Перед подтверждением подписантам следует проверять сеть и адрес кошелька.

Не следует считать подпись безопасной только потому, что ее поставили несколько человек.

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

Защита от повторного воспроизведения и оракулы

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

Такие подписанные пакеты данных также нуждаются в защите от повторного воспроизведения.

Устаревшее обновление цены не должно приниматься бесконечно.

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

Отчет о резервах не должен повторно использоваться после истечения срока действия.

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

Смарт-контракты должны отклонять устаревшие или уже использованные сообщения оракулов.

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

Если устаревшие данные можно повторно отправить, ликвидации, расчеты, выпуск, погашение или выплаты могут выполняться неверно.

Актуальность данных оракула и контроль nonce — элементы безопасности смарт-контрактов.

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

Защита от повторного воспроизведения и разрешения на расходование токенов

Разрешения на расходование токенов — одна из областей, где защита от повторного воспроизведения особенно важна.

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

Подписанный permit использует nonce на уровне смарт-контракта и крайний срок, чтобы разрешить расходование без прямой транзакции владельца.

Если подпись permit можно повторно использовать, потратившая сторона может восстановить лимит на расходование токенов после того, как пользователь решит, что разрешение больше не действует.

Если в permit не указаны адрес получателя разрешения, токен, сумма, nonce, крайний срок или домен, подписью могут злоупотребить.

Пользователям следует относиться к подписанным разрешениям как к серьезным финансовым авторизациям.

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

Смарт-контракты должны немедленно отклонять уже использованные nonce permit.

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

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

Защита от повторного воспроизведения и обновление смарт-контрактов

Обновляемые смарт-контракты создают дополнительные риски повторного воспроизведения.

После обновления смарт-контракта старые подписи могут остаться действительными, если не изменить версию домена, логику nonce или правила проверки.

По этой причине в домене подписания EIP-712 предусмотрено поле версии.

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

Если после обновления старые подписи не должны работать, смарт-контракту может потребоваться новая версия домена или механизм аннулирования nonce.

Если старые подписи должны продолжать работать, при обновлении необходимо правильно сохранить состояние nonce.

Неправильный перенос состояния nonce может позволить повторно использовать старые подписи или сделать недействительными корректные подписи.

В план обновления следует включить перенос подписей, изменения домена, структуру хранения nonce и информирование пользователей.

Защита от повторного воспроизведения важна не только при развертывании смарт-контракта.

Она должна сохраняться при обновлениях и миграциях.

Защита от повторного воспроизведения и форки

Форк сети может создать риск повторного воспроизведения, если обе ветви принимают один формат транзакций и имеют одинаковое состояние.

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

Защита с помощью идентификатора сети в EIP-155 была разработана для снижения этого риска в транзакциях Ethereum.

Однако для подписей на уровне приложений также необходима привязка к сети.

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

Во время форков и разделения сети пользователям следует соблюдать осторожность.

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

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

Защита от повторного воспроизведения при форке важна как на уровне протокола, так и на уровне приложения.

Внимание необходимо на обоих уровнях.

Преимущества защиты от повторного использования nonce

Первое преимущество — одноразовая авторизация.

Подписанное действие можно выполнить один раз, а после этого отклонить повторно.

Второе преимущество — уникальность транзакций.

Транзакции одного аккаунта можно различать по значениям nonce.

Третье преимущество — упорядоченность.

Последовательные nonce помогают определить допустимый порядок транзакций аккаунта.

Четвертое преимущество — безопасность при работе в нескольких сетях, если защита используется вместе с идентификаторами сетей.

Подписи можно привязать к нужной сети.

Пятое преимущество — повышение безопасности смарт-контрактов.

Смарт-контракты могут предотвращать повторное использование permit, запросов на получение средств, голосов, переводов и сообщений мостов.

Шестое преимущество — более безопасный пользовательский опыт.

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

Риски и ограничения защиты от повторного использования nonce

Первое ограничение: защита с помощью nonce не предотвращает первое вредоносное использование подписанного сообщения.

Если пользователь подпишет вредоносное разрешение, nonce не позволит использовать его повторно после первого выполнения.

Второе ограничение — сложность управления транзакциями.

Последовательные nonce могут приводить к зависанию транзакций и блокировке очередей.

Третье ограничение — расходы на хранение.

Хранение использованных случайных nonce в смарт-контрактах может увеличить объем данных в блокчейне.

Четвертое ограничение — риск ошибок реализации.

Отсутствие проверки nonce может сделать подписи пригодными для повторного использования.

Пятое ограничение — сложность работы с несколькими доменами.

Nonce может защищать один смарт-контракт, но не другой смарт-контракт или сеть.

Шестое ограничение — риск при обновлении.

При миграции смарт-контракта состояние nonce может нарушиться, если не обработать его должным образом.

Распространенные ошибки при защите от повторного использования nonce

Одна из распространенных ошибок — проверять подпись, но не проверять nonce.

Другая ошибка — проверить nonce, но забыть увеличить его или пометить как использованный.

Третья ошибка — использовать один общий nonce для всех пользователей вместо отдельных nonce для каждого пользователя.

Четвертая ошибка — не включать идентификатор сети в подписываемые данные.

Пятая ошибка — не включать адрес проверяющего смарт-контракта в типизированные данные.

Шестая ошибка — принимать подписи без крайних сроков.

Седьмая ошибка — разрешать использовать один и тот же nonce для действий разных типов.

Восьмая ошибка — не переносить хранилище nonce при обновлении смарт-контракта.

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

Десятая ошибка — считать, что EIP-712 автоматически предотвращает все атаки повторного воспроизведения.

Рекомендации для разработчиков

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

Отслеживайте nonce отдельно для каждого подписанта, а не глобально, если только схема явно не требует общего счетчика.

Увеличивайте nonce или помечайте его как использованный до выполнения действия или во время него так, чтобы этот механизм нельзя было обойти.

Если важен контекст сети, включайте идентификатор сети в домен подписания.

Включайте адрес проверяющего смарт-контракта в домен подписания.

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

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

Если требуется параллельное выполнение, используйте отдельные пространства nonce для независимых сценариев.

Публикуйте события при использовании или отмене разрешений.

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

Рекомендации для кошельков и приложений

Перед подписанием показывайте пользователям сеть, смарт-контракт, адрес получателя разрешения, сумму, крайний срок, контекст nonce и тип действия.

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

Для аутентификации через кошелек используйте новые запросы на вход.

После входа помечайте запрос аутентификации как использованный.

Не просите пользователей подписывать расплывчатые или нечитаемые сообщения.

По возможности используйте типизированные данные EIP-712 для структурированных подписей.

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

Не скрывайте от пользователей, как работает замена транзакции.

Поддерживайте очереди nonce для абстракции аккаунтов, только если интерфейс позволяет безопасно объяснить их работу.

Защищайте пользователей от подписания устаревших, просроченных запросов или запросов, предназначенных для другой сети.

Рекомендации для пользователей

Прочитайте запрос в кошельке перед подписанием любого сообщения или транзакции.

Проверьте сеть перед подписанием.

Проверьте, какое приложение или смарт-контракт запрашивает подпись.

Проверьте токен, адрес получателя разрешения, сумму и крайний срок в разрешениях типа permit.

Отклоняйте расплывчатые, неограниченные разрешения или разрешения, не связанные с выполняемым вами действием.

Не подписывайте сообщения для входа с подозрительных доменов.

Не считайте вредоносную подпись безопасной только потому, что в ней указан nonce.

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

При необходимости отзывайте ненужные разрешения на расходование токенов.

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

Когда защита от повторного использования nonce особенно важна

Защита от повторного использования nonce особенно важна, когда подписи разрешают перемещение ценностей.

Она важна для обычных транзакций блокчейна.

Она важна для разрешений permit.

Она важна для переводов токенов без газа.

Она важна для сообщений мостов.

Она важна для голосований и делегирования в системах управления.

Она важна для получения аирдропов и вознаграждений.

Она важна для запросов на вход через кошелек.

Она важна для транзакций с мультиподписью и UserOperations в системах с абстракцией аккаунтов.

Она важна везде, где скопированная подпись может привести к повторным или непреднамеренным последствиям.

Защита от повторного использования nonce в одном предложении

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

FAQ

Что означает защита от повторного использования nonce?

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

Что такое nonce в криптоиндустрии?

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

Что такое атака повторного воспроизведения?

Атака повторного воспроизведения — это повторная отправка скопированного действительного подписанного действия с целью повторить действие или злоупотребить авторизацией.

Как Ethereum использует nonce?

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

Что такое защита от повторного воспроизведения с помощью Chain ID?

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

Предотвращает ли EIP-712 атаки повторного воспроизведения автоматически?

Нет. EIP-712 структурирует подписываемые данные, но приложению все равно нужны проверки nonce, крайних сроков и корректное разделение доменов.

Зачем permit нужны nonce?

Nonce в permit не позволяют многократно отправлять одну и ту же подписанную авторизацию на расходование токенов.

Чем nonce отличается от крайнего срока?

Nonce делает подпись одноразовой, а крайний срок ограничивает период ее действия.

Может ли защита от повторного воспроизведения предотвратить фишинг?

Нет. Она может предотвратить повторное использование, но не первое вредоносное применение, если пользователь подпишет вредоносную авторизацию.

Что произойдет, если nonce использовать повторно?

Если обработка nonce реализована правильно, повторная операция должна завершиться ошибкой. При плохом проектировании повторное использование nonce может привести к атаке повторного воспроизведения или проблемам с транзакциями.

Почему смарт-контрактам нужны собственные проверки nonce?

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

Какая схема защиты от повторного воспроизведения наиболее безопасна?

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

Заключение

Защита от повторного использования nonce — одна из малозаметных основ безопасности криптовалют.

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

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

Nonce обеспечивает эту дополнительную проверку актуальности.

Если nonce правильно проверяется и помечается как использованный, одно и то же подписанное действие нельзя выполнить повторно.

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

Современная защита от повторного воспроизведения — это больше, чем один счетчик.

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

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

Nonce аккаунта предотвращают повторное выполнение транзакций одного аккаунта в одной сети.

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

Nonce смарт-контрактов не позволяют повторно использовать подписанные сообщения в приложениях.

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

Разделение доменов не позволяет подписям попасть в неправильный смарт-контракт или приложение.

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

Если этих механизмов нет, риски могут быть серьезными.

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

Даже при наличии защиты с помощью nonce пользователи могут пострадать от фишинга, если один раз подпишут вредоносную авторизацию.

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

Для разработчиков правило простое.

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

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

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

Защита от повторного использования nonce не делает криптовалюты безрисковыми.

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