mystenlabs/ed25519-unsafe-libsСписок небезопасных библиотек для подписи ed25519
Список потенциально небезопасных библиотек подписи ed25519, которые предоставляют публичный API, позволяющий передавать секретный и открытый ключи независимо друг от друга в качестве входных данных функции подписи. Неправильное использование этих публичных API может привести к раскрытию закрытого ключа.
Большинство репозиториев из нашего анализа перечислены в IANIX :: Что использует Ed25519.
Количество затронутых библиотек: 45
Количество библиотек, исправивших проблему после объявления: 8
последнее обновление: 4 мая 2023 г.
Обратите внимание, что в обычном случае, согласно соответствующему rfc8032, подписи EdDSA детерминированы, и, таким образом, для одного и того же входного сообщения возвращается уникальный результат подписи, включающий два элемента: точку на кривой R и скаляр S.
Алгоритмическая деталь состоит в том, что открытый ключ подписывающего участвует в детерминированном вычислении только части S подписи, но не значения R. Последнее означает, что если бы злоумышленник каким-либо образом смог использовать функцию подписи как Oracle (принимающий произвольные открытые ключи на вход), то для одного и того же сообщения можно было бы получить две подписи с одинаковым R, различающиеся только частью S. К сожалению, когда это происходит, закрытый ключ можно легко извлечь; этот пост на StackOverflow объясняет, почему это возможно.
Тем не менее, публичные API НЕ должны допускать передачу раздельной пары закрытый/открытый ключ в качестве входных данных для подписи. Чтобы обойти это, многие реализации хранят открытый ключ вместе с закрытым ключом (или сидом) и считают всю пару ключей секретом ЛИБО всегда повторно вычисляют открытый ключ внутри функции подписи. К сожалению, большое количество существующих библиотек не решают эту проблему, допуская передачу произвольных открытых ключей на вход без проверки соответствия входного открытого ключа входному закрытому ключу.
Конечно, это не означает, что все приложения, зависящие от этих библиотек, подвержены атакам с раскрытием ключей; на самом деле большинство из них, вероятно, безопасны, поскольку обычно не предоставляют затронутый API своим пользователям и связывают пару открытый/закрытый ключ непосредственно перед вызовом sign. С другой стороны, даже когда эти API не открыты, существуют приложения с разными стратегиями модели угроз TCB в отношении того, как управляются и хранятся закрытые и открытые ключи. Тем не менее, чтобы предотвратить эту атаку, разработчикам следует также обеспечить протокол защиты целостности и для открытых ключей.
Здесь мы перечисляем некоторые затронутые библиотеки вместе с соответствующими ссылками на код.
Рис. 1. Пример неправильного использования API в Rust-крейте ed25519-dalek.
