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

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

Только не так быстро. Ситуация не так проста. Ряд громких взломов кошельков, не связанных с тюремным заключением, в том числе Взлом кошелька Slope который взломал более 8,000 учетных записей в августе, Взлом кошелька Тринити которая потеряла токены IOTA на сумму более 2 миллионов долларов в 2020 году, Взлом кошелька Parity что позволило злоумышленнику украсть 150,000 2017 ETH в XNUMX году, а также обнаружение различных уязвимости аппаратного кошелькаи другие инциденты — подрывает общепринятое различие между кастодиальными и некастодиальными кошельками. Во многих из этих случаев жертвы, которые считали, что используют кошелек, не связанный с тюремным заключением, обнаруживали, что злоумышленники смогли украсть их заветные ключи. Противоречие, нет?

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

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

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

1. Генерация ключей (создание криптографических ключей)

2. Хранение ключей (закрепление ключей в состоянии покоя)

3. Использование ключа (приведение ключей в действие)

Этот обзор предназначен для того, чтобы помочь пользователям web3 лучше понять тонкости, связанные с защитой их активов с помощью приведенной выше рубрики. Кроме того, мы стремимся помочь инженерам выявлять и устранять частые сбои в разработке кошелька. Мы надеемся, что применение этого руководства, основанного на нашем многолетнем совместном опыте создания криптографических систем и систем безопасности в Docker, Anchorage, Facebook и a16z crypto, поможет людям избежать сбоев в безопасности, независимо от того, взаимодействуют ли они, участвуют или создание веб3 технологии.

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

Безопасность кошелька генерации ключей

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

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

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

• Используйте кошельки, которые не используют собственную криптовалюту

У криптографов есть поговорка: «Не сворачивайте свою собственную криптографию». Суть похожа на пословицу «не изобретайте велосипед». Колесо в порядке, и любая попытка восстановить его с нуля, скорее всего, приведет к ухудшению продукта. То же самое относится и к криптографии, науке, которую трудно понять правильно. Код, составляющий кошелек, должен иметь репутацию хорошо работающего. Выбор плохо написанного программного обеспечения или попытка разработать собственную альтернативу De Novo – может привести к сбоям, таким как утечка ключей или раскрытие секретной информации неуполномоченным сторонам. Именно это скрывалось за недавно использованной уязвимостью в Инструмент тщеславия ненормативной лексики. Прежде всего, должно быть ясно, что рассматриваемый кошелек использует проверенную и надежную библиотеку и процесс генерации ключей.

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

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

• Используйте кошелек, который может хранить секреты

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

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

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

Безопасность кошелька для хранения ключей

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

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

Более высокий риск: «горячие» кошельки

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

Горячие кошельки могут принимать несколько форм.

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

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

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

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

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

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

Подключенное оборудование бывает нескольких видов. Существуют аппаратные кошельки, такие как устройства Trezor и Ledger, которые обычно используют более опытные криптопользователи. (Эти устройства должны использовать гораздо больше людей, так как они намного безопаснее, чем использование только подключенного программного обеспечения.) Существуют также аппаратные модули безопасности, или HSM, которые обычно используются в более традиционных бизнес-средах, таких как обработка конфиденциальных данных. , например платежи по кредитным картам.

Устройства безопасны настолько, насколько безопасна цепочка поставок, которая их произвела и настроила. Рассматривая подключенное оборудование, спросите себя: какова вероятность того, что устройства или микропрограммы были подделаны до того, как они попали в ваше распоряжение? Чтобы снизить этот риск, лучше покупать устройства напрямую у проверенных поставщиков. Отправьте их прямо из источника. Убедитесь, что упаковки не повреждены — нет разрывов, разрывов, сломанных пломб и т. д. — что может указывать на фальсификацию во время транспортировки. Перед использованием также рекомендуется проверить версию микропрограммы и конфигурацию. Шаги для этого различаются в зависимости от оборудования, но все должны содержать инструкции.

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

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

Менее рискованно: «холодные» кошельки

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

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

Рассмотрим более подробно некоторые варианты холодного кошелька.

• Программное обеспечение Airgrapped: автономное серверное приложение

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

• Аппаратное обеспечение с воздушным захватом: автономный аппаратный кошелек, автономный аппаратный модуль безопасности (HSM)

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

Поскольку холодные кошельки или кошельки с воздушным зазором являются самой безопасной категорией, большинство средств, которыми управляют крупные игроки, хранятся именно таким образом. Крупные розничные сервисы, такие как Coinbase, Gemini, Kraken и другие, а также сервисы для институциональных пользователей, такие как Anchorage, входят в число тех, кто это делает. Многие из этих игроков предпочитают иметь еще одну линию защиты в виде резервного копирования и восстановления на случай, если — не дай Бог — они потеряют доступ или компьютеры будут повреждены, украдены или уничтожены.

Резервные копии и восстановление

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

Для аппаратных кошельков резервные копии обычно включают исходную фразу открытого текста из 12 слов, из которой получаются закрытые ключи. Эта исходная фраза должна храниться не в цифровом виде (например, на бумаге, металле) и в наиболее безопасном из доступных способов (физическое хранилище дома, внутри банковского хранилища). Фраза может быть разделена на части, которые географически распределены, чтобы предотвратить легкое раскрытие всего секрета. (Люди иногда объясняют этот подход ссылками на вымышленные хоркруксы, которые тёмные волшебники эффективно используют для «резервного копирования» своих душ в Harry Potter.)

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

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

Безопасность кошелька с использованием ключа

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

• Доверяй, но проверяй

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

• Не сворачивайте свою собственную криптовалюту (опять же!)

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

• одноразовое повторное использование

Хорошо изученной ловушкой при использовании ключей является непреднамеренное повторное использование определенных параметров криптографической подписи. Для некоторых схем подписи может потребоваться нунций что означает «число, используемое один раз», произвольное число, предназначенное для использования только один раз в системе. Алгоритм цифровой подписи на эллиптических кривых (ECDSA) является одной из таких схем подписи, которая делает это. Повторное использование одноразового номера с ECDSA может привести к компрометации ключа. Различные другие алгоритмы не затрагиваются, поэтому, как обычно, убедитесь, что используются хорошо зарекомендовавшие себя криптографические библиотеки. (Некоторые криптографические библиотеки обеспечивают уникальные одноразовые номера путем хеширования данных транзакций, которые включают в себя другие уникальные данные, такие как одноразовые номера учетных записей.) Но этот вектор атаки уже использовался ранее в громких взломах за пределами web3, таких как этот 2010 Взлом Sony PlayStation 3.

• Один ключ для каждой цели

Еще одна передовая практика — избегать повторного использования ключа более чем для одной цели. Например, для шифрования и подписи следует хранить отдельные ключи. Это соответствует принципу «наименьшая привилегия” в случае компрометации, что означает, что доступ к любому активу, информации или операции должен быть ограничен только сторонами или кодом, которые абсолютно необходимы для работы системы. Принцип «наименьших привилегий» при правильной реализации может резко ограничить радиус поражения успешной атаки. Различные ключи будут иметь разные требования к резервному копированию и управлению доступом в зависимости от их назначения. В контексте web3 рекомендуется разделять ключи и сид-фразы между активами и кошельками, чтобы компрометация одной учетной записи не затрагивала другие.

Заключение

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

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

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

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

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

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

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

Монтажер: Роберт Хакетт, @rhhackett

Мнения, выраженные здесь, принадлежат отдельным цитируемым сотрудникам AH Capital Management, LLC («a16z») и не являются мнением a16z или ее аффилированных лиц. Определенная информация, содержащаяся здесь, была получена из сторонних источников, в том числе от портфельных компаний фондов, управляемых a16z. Хотя информация взята из источников, считающихся надежными, a16z не проводила независимую проверку такой информации и не делает никаких заявлений о текущей или неизменной точности информации или ее уместности в данной ситуации. Кроме того, этот контент может включать стороннюю рекламу; a16z не просматривал такие рекламные объявления и не поддерживает какой-либо рекламный контент, содержащийся в них. 

Этот контент предоставляется только в информационных целях и не может рассматриваться как юридическая, деловая, инвестиционная или налоговая консультация. Вы должны проконсультироваться со своими советниками по этим вопросам. Ссылки на любые ценные бумаги или цифровые активы предназначены только для иллюстративных целей и не представляют собой инвестиционную рекомендацию или предложение предоставить консультационные услуги по инвестициям. Кроме того, этот контент не предназначен и не предназначен для использования какими-либо инвесторами или потенциальными инвесторами, и ни при каких обстоятельствах на него нельзя полагаться при принятии решения об инвестировании в какой-либо фонд, управляемый a16z. (Предложение инвестировать в фонд a16z будет сделано только в меморандуме о частном размещении, договоре о подписке и другой соответствующей документации любого такого фонда, и их следует читать полностью.) Любые инвестиции или портфельные компании, упомянутые, упомянутые или описанные не являются репрезентативными для всех инвестиций в транспортные средства, управляемые a16z, и нет никаких гарантий, что инвестиции будут прибыльными или что другие инвестиции, сделанные в будущем, будут иметь аналогичные характеристики или результаты. Список инвестиций, сделанных фондами, управляемыми Andreessen Horowitz (за исключением инвестиций, в отношении которых эмитент не предоставил разрешение на публичное раскрытие информации a16z, а также необъявленных инвестиций в публично торгуемые цифровые активы), доступен по адресу https://a16z.com/investments. /.

Диаграммы и графики, представленные в нем, предназначены исключительно для информационных целей, и на них не следует полагаться при принятии каких-либо инвестиционных решений. Прошлые показатели не свидетельствуют о будущих результатах. Содержание говорит только по состоянию на указанную дату. Любые прогнозы, оценки, прогнозы, цели, перспективы и/или мнения, выраженные в этих материалах, могут быть изменены без предварительного уведомления и могут отличаться или противоречить мнениям, выраженным другими. Пожалуйста, посетите https://a16z.com/disclosures для получения дополнительной важной информации.