Четыре стратегии безопасности на примере кражи кошелька

Автор: Лю Цзяолянь

У кошелька Keplr с функцией социального входа произошел инцидент: средства были похищены с тысяч аккаунтов. Официально причина указана в уязвимости инфраструктуры Web3Auth.

Большинство пострадавших не совершали никаких ошибочных действий; они просто из соображений удобства создали этот кошелек через вход с помощью Google или Apple.

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

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

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

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

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

Сначала посмотрим на подход кошелька Uniswap. Стратегия элементарна: мнемоническая фраза зашифровывается и сохраняется как резервная копия в вашем личном iCloud или Google Drive.

На серверах Apple хранится набор шифротекстов, а пароль для дешифровки находится исключительно в вашей голове.

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

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

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

В облаке существует лишь один фундаментальный риск: успешный взлом служб хранения данных со стороны Apple или Google. Именно поэтому компания отдаёт предпочтение этим технологическим гигантам, проявляя к ним относительное доверие в вопросах кибербезопасности.

Затем следует классический Web3-кошелек MetaMask (известный всем «Метамакс») с социальным входом. Его архитектура значительно сложнее: зашифрованная мнемоническая фраза размещается на собственных серверах MetaMask, а ключ дешифрования секционируется и распределяется между разными серверными узлами.

Процедура восстановления требует наличия двух компонентов: учетных данных для входа через Google, Apple или Telegram и вашего личного пароля.

Только совмещение обоих элементов позволяет восстановить ключ целиком.

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

Теоретически это верно, но всё зависит от контекста.

При стандартном онлайн-восстановлении учетные данные выступают первым барьером, rate limiting на стороне сервера — вторым, а пароль занимает лишь третью позицию. Слабые пароли не взламываются мгновенно.

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

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

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

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

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

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

Но возможности пользователя чётко идентифицировать риски парадоксальным образом сокращаются.

Записанный на бумаге ключ известен вам по местонахождению; зашифрованный архив в iCloud вы точно знаете, где хранится; в системе MetaMask шифротекст находится на сервере, фрагменты распределены по узлам, пароль спрятан в памяти — нужно досконально изучить функционал четырёх сторон, чтобы хоть как-то разобраться; на этапе Keplr при возникновении инцидента пользователь даже не знает, к кому предъявлять претензии.

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

Как хакерам этому не радоваться?

У бумаги и ручки только один вектор уязвимости: кража или уничтожение огнём; у резервной копии iCloud добавляется ещё один облачный аккаунт; у архитектуры MetaMask возникают поставщики идентификации, узлы шардирования и фактор стойкости пароля; у модели Keplr интегрируется целая экосистема инфраструктуры.

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

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

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

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

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

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

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

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

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

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

Он вынужден выбирать веру. А вера — это не защита, это азартная игра.

TechFlow невольно вспоминает выдержку из белой книги Биткоина, написанную Сатоши Накамото: «Когда существует вероятность отката, потребность в доверии распространяется».

Хотя Сатоши Накамото описывал сценарий онлайн-платежей, аналогия с восстановлением приватного ключа, который представляет собой обратимый процесс, однозначно подтверждает, что это неизбежно влечёт за собой расширение потребности в доверии.

А подобная экспансия сама по себе напрямую масштабирует поверхность атаки.

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

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

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

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

Чтобы по-настоящему обладать каким-либо активом, необходимо иметь возможность ткнуть на него пальцем и сказать: «Это моё. Я на 100% убеждён в том, что он находится здесь».