Объявления безопасности

A bug related to transaction priority handling may allow an attacker to crash Zcash nodes (Denial of Service) via a specially crafted transaction. A fix is implemented in zcashd release 1.0.8-1.
Please see the official announcement for more details and update your Zcash node to 1.0.8-1.

Язык

Безопасная генерация параметров SNARK

Zooko Wilcox | Feb 29, 2016

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

В настоящий момент одной из самых важных задач проекта Zcash является настройка криптографически надежных “открытых параметров SNARK”.

В чем же проблема?

Побочным эффектом простого способа генерирования “открытых параметров SNARK” является избыточная информация, так называемый криптографический “мусор”. Это может облегчить задачу злоумышленникам при взломе шифра. Но, мы нашли решение этой проблеме.

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

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

Самым очевидным способом выстраивания параметров для SNARK является генерация пары открытого и закрытого ключа - по аналогии с ключами ECDSA [*] - и последующее удаление закрытого.

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

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

Как можно решить эту проблему?

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

Этот процесс описан нами в научном криптографическом исследовании , которое было представлено общественности на Конференции по защите информационной безопасности в Окленде в 2015 году.

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

Есть ли еще решения?

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

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

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

  • Возможно, мы могли бы задействовать современную версию “Trusted Execution Environments” - аппаратную технологию защиты от вредоносных программ, как в Intel SGX и ARM TrustZone. Тогда, даже если участник или взломанный компьютер, используемый участником, попытается извлечь свой сегмент закрытого ключа, то у него ничего не выйдет. Можно было бы сделать так, чтобы кто-то из участников использовал аппаратную архитектуру Intel SGX, кто-то - ARM TrustZone, а оставшиеся не использовали TEE вообще. Таким образом, если участники с Intel SGX и ARM TrustZone окажутся взломаны, злоумышленник не сможет сгенерировать закрытый ключ, потому что по крайней мере один из участников уничтожит свой сегмент.
  • Еще одним решением может стать постоянное расширение открытых параметров SNARK за счет добавления сегментов ключей новых участников. Тогда для взлома шифра злоумышленнику придется получить доступ к ключам как старых, так и новых участников.
  • Как вариант решения проблемы, можно попробовать использовать проверку объема валютной базы Zcash, не раскрывая информации о пользователях. Хоть это и не дает 100% уверенности, что ключ не был украден, но в этом случае можно по крайней мере убедиться, что ключ (пока что) не использован для подделки коинов.
  • Также, возможно, появится обновленная версия SNARK, чьи открытые параметры не будут взаимосвязаны с закрытым ключом. Никто пока не знает, возможно ли это. Но исследователи, включая людей из нашей команды, продолжают активно исследовать возможные границы систем доказательств с нулевым разглашением.

Заключение

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

[*]Я, конечно, сильно все упростил - открытые параметры SNARK не просто подобны ECDSA. Их можно сравнить с системой из миллионов открытых ключей ECDSA, каждый из которых имеет свою кодировку в схеме SNARK. Но в данной статье эта информация не играет никакой роли.