Обвинение в расширении браузера программного кошелька, не связанном с тюремным заключением, которое затрагивает MetaMask, Phantom, Keplr и многие другие.
В этой статье я объясню, как даже самые надежные расширения Web3 оказывают медвежью услугу своим пользователям, не придерживаясь более высоких стандартов безопасности. Затем я предоставлю некоторые технические подробности о том, как StarShell пытается значительно уменьшить эту поверхность атаки, внедряя новые методы управления ключами в веб-JavaScript.
Эти проблемы безопасности не относятся к пользователям, поддерживающим свои учетные записи Web3 с помощью аппаратных кошельков. Я настоятельно призываю любого пользователя криптовалюты, который может себе это позволить, подумать о приобретении надежного аппаратного кошелька, совместимого с их существующими активами.
StarShell — это грядущий кошелек Web3, который будет развернут как расширение для браузера и представит новые функции безопасности, которые пытаются решить такие проблемы.
— Блейк Регалия, создатель StarShell
В предыдущей статье я указал на недостаток безопасности в других кошельках Web3, где вредоносное совместно установленное расширение браузера с минимальными разрешениями на чтение/запись данных страницы может выполнять атаки MITM, заменяя данные транзакции, сгенерированные страницей, чтобы обмануть пользователей. одобрение произвольных сделок.
У меня есть еще плохие новости.
Криптография в Интернете
Современные криптографические функции может быть трудно реализовать должным образом, поскольку они обычно включают в себя более сложную математику, такую как вычисление полиномов, дискретные логарифмы, модульное возведение в степень, большие простые числа, эллиптические кривые и поля Галуа, среди прочего. Помимо того, что математику сложно реализовать, вспомогательные алгоритмы также требуют особого внимания к деталям, поскольку любые ошибки могут привести к серьезным уязвимостям. Вот почему проекты обычно предпочитают импортировать сторонние криптографические библиотеки, которые были тщательно проверены на корректность.
В Интернете интерфейсные приложения имеют доступ к Web Crypto API в современных браузерах. Это не только чрезвычайно полезная функция, но и важный компонент безопасности приложений по нескольким очень важным причинам. Первым из них является криптографически защищенная генерация псевдослучайных чисел (CSPRNG), без которой приложения не смогли бы создавать закрытые ключи, за исключением необходимости вручную вводить дополнительную энтропию.
Другим важным компонентом Web Crypto является возможность импортировать ключи, когда браузер может использовать преимущества криптографических примитивов, специфичных для платформы, для их хранения в защищенных областях памяти (либо с помощью операционной системы, либо с помощью аппаратного диспетчера ключей). , при этом позволяя использовать их для таких вещей, как подпись, проверка, шифрование, расшифровка и так далее.
Криптовалюта в сети
Secp256k1 относится к параметрам эллиптической кривой, используемым в Биткойне, Эфириуме и многих других криптовалютах (включая все цепочки Cosmos-SDK). Сатоши выбрал secp256k1, потому что его параметры построены неслучайно, в отличие от кривой NIST P-256 (также известной как secp256r1 или prime256v1), которая, по мнению некоторых, может иметь лазейку. Хотя Web Crypto поддерживает кривые NIST, он не поддерживает secp256k1 и никогда не будет.
Это оставляет любое приложение, работающее в браузере, особенно любое расширение кошелька Web3, вынужденное полагаться на криптографию на основе JavaScript для выполнения операций secp256k1 с закрытыми ключами в открытом тексте.
Иными словами, программные кошельки хранят закрытые ключи в незашифрованном и незащищенном виде в незашифрованной памяти!
Хотя программные кошельки гораздо менее безопасны, чем любая аппаратная криптография, они обеспечивают больший охват с точки зрения повышения доступности Web3. Аппаратные кошельки не совсем дешевы, и бремя дополнительного оборудования может стать препятствием для входа. Однако:
Способы, которыми эти программные кошельки управляют закрытыми ключами в памяти (JavaScript), демонстрируют явное непонимание того, как работает компьютерная память, полное отсутствие понимания передовых методов обеспечения безопасности и критическую ошибку со стороны всех, кто связан с разработка и проверка безопасности такого программного обеспечения.
Обнаружение таких забытых слабостей вызывает тревогу. Миллионы людей доверяют этому программному обеспечению для защиты своих активов и безопасного подключения к децентрализованной платформе Web3.
Достаточно сказать, что серьезность этих проблем нельзя недооценивать. Во время написания этой статьи я нашел фантастическую запись в блоге о безопасности программного кошелька, написанную людьми из Ledger, которая перекликается со многими из тех же проблем безопасности, о которых говорилось здесь: https://blog.ledger.com/software-wallets/
Войдите в StarShell
Совершенно безопасный программный кошелек, особенно тот, который работает в браузере, практически невозможен с современными инструментами, доступными в распоряжении разработчиков. Опять же, я настоятельно рекомендую использовать аппаратные кошельки, когда это возможно, но я также понимаю, что для некоторых это может быть непомерно дорого. Для таких пользователей программные кошельки должны использовать гораздо более строгие меры безопасности, чтобы снизить риск атак с поиском ключей.
В оставшейся части этой статьи описывается, как StarShell попытается смягчить вышеупомянутые проблемы безопасности. Обратите внимание, что эти решения могут в лучшем случае просто уменьшить поверхность атаки, и что они будут ожидать независимого аудита безопасности для проверки их эффективности.
Закрытые ключи в памяти
В криптографии на основе эллиптических кривых закрытый ключ представляет собой очень большое целое число. Подписание сообщений (ECDSA) с помощью закрытого ключа требует возможности выполнять арифметические операции с такими очень большими целыми числами. В свое время разработчики были вынуждены использовать примитивы, такие как строки в шестнадцатеричном кодировании или массивы чисел, для представления этих ключей. Сегодня есть BigInt, который значительно упрощает реализацию алгоритмов, поскольку арифметические операции выполняет среда выполнения.
Однако все эти типы данных, включая BigInt, проблематичны для закрытых ключей. Причина сводится к сборке мусора в JavaScript и тому, как операционные системы выделяют и освобождают память.
По сути, материал закрытого ключа (включая любые промежуточные значения) может жить в памяти еще долгое время после того, как алгоритмы его используют. Как Чоу и соавт. Как описано в Уничтожение мусора: сокращение времени жизни данных за счет безопасного освобождения памяти (PDF, HTML), правильный способ управления материалом закрытого ключа — обнуление памяти сразу после ее удаления. больше не нужен (практика, которую они называют безопасным освобождением).
Без использования TypedArrays программы JavaScript не могут гарантировать, что материал закрытого ключа был удален из оперативной памяти. В зависимости от системы закрытые ключи могут оставаться в памяти даже после закрытия браузера, а в некоторых случаях даже после перезагрузки. В этих состояниях все, что мошеннической программе нужно сделать, — это выделить некоторую ненулевую память из операционной системы и найти в ней старый ключевой материал.
Сочетание одноразового блокнота с безопасным освобождением
В StarShell подход, который я применил, направлен на то, чтобы значительно уменьшить поверхность атаки с поиском ключей, позволяя открытым закрытым ключам существовать в памяти только в течение очень коротких периодов времени (т. е. только в случае крайней необходимости). Насколько мне известно, этот подход никогда не изучался в контексте Web/JavaScript.
Подход начинается с хранения зашифрованного закрытого ключа в памяти, обеспечивая базовую безопасность для используемых данных. Если бы злоумышленник сбросил память браузера в этом состоянии, закрытый ключ пользователя был бы защищен. Однако, чтобы использовать закрытый ключ, нам нужно иметь возможность расшифровать его и хранить в памяти в течение очень короткого периода времени.
Здесь в игру вступает Web Crypto. Вместо того, чтобы полностью отказаться от Web Crypto в пользу secp256k1, мы все же можем воспользоваться его функцией безопасного управления ключами, используя его для получения одноразового блокнота, который можно использовать для распаковки зашифрованной версии секретного ключа secp256k1, хранящегося в памяти. . На следующей диаграмме потока данных представлен общий обзор процессов создания и/или упаковки закрытого ключа, а затем его распаковки:
Чтобы эмулировать безопасное освобождение в JavaScript, необходимо, чтобы материал закрытого ключа никогда не существовал в каких-либо примитивных типах данных, отличных от TypedArrays. Это означает отсутствие BigInt, поскольку нет гарантии, что браузер обнулит данные, собранные мусором. Вместо этого все операции с большими целыми числами должны быть реализованы и выполнены с использованием TypedArrays, поскольку они могут быть явно обнулены перед освобождением.
Хотя предлагаемое решение ни в коем случае не является идеальной защитой, оно значительно сокращает время, в течение которого в памяти хранится открытый текст закрытого ключа (особенно по сравнению с конкурентами). Естественно, это должно уменьшить поверхность атаки с поиском ключа, поскольку злоумышленнику придется получить доступ к памяти программы в течение очень короткого промежутка времени, чтобы восстановить закрытый ключ.
Вау! Это стало довольно техническим в конце. Эта тема, в частности, потребовала гораздо большей работы за кулисами. Если вы заботитесь о безопасности и будущем Web3, рассмотрите возможность подписаться на нас в Twitter или присоединиться к нашему серверу Discord.
Узнайте больше о StarShell на нашем сайте: https://starshell.net/
