Что релей SSP может видеть, а что нет
SSP — это кошелёк на двух устройствах. Расширение браузера хранит один ключ, телефон — другой, и ни одно из них не может двигать средства в одиночку. Но этим двум устройствам нужно переговариваться, и делают они это через сервер, который мы держим и называем релеем.
Этот сервер — очевидное место, чтобы задать неудобный вопрос: если всё проходит через инфраструктуру, которой управляет компания-разработчик кошелька, что именно эта компания видит?
Вопрос справедливый, и он заслуживает конкретного ответа, а не успокаивающего. Итак, вот что на самом деле лежит в коде.
Релей не может ничего подписать
Начнём с того, что важнее всего.
Релей никогда не получает закрытый ключ. Ни зашифрованным, ни разделённым, ни в каком виде. Ключ кошелька остаётся в расширении браузера, ключ приложения — на телефоне, и через сеть проходят лишь открытые ключи, неподписанные данные и подписи, уже сделанные на ваших устройствах.
Это не обещание в правилах, а свойство устройства системы. Мультиподпись два-из-двух требует обеих подписей, чтобы двинуть средства, а у релея нет ни одного из ключей. Полностью злонамеренный релей — наш, взломанный или подменённый злоумышленником — всё равно не сможет создать действительную транзакцию, потому что её создание требует секретов, которые ему никогда не отправляли.
Такова гарантия. Всё дальнейшее — о том, с чем релей всё же работает, и это множество уже, но по-настоящему не пустое.
Что проходит через него и как долго
Релей хранит четыре вида записей. Две из них удаляются сами.
Данные синхронизации, когда вы связываете два устройства. В них цепочка, идентичность кошелька, расширенный открытый ключ приложения, получившаяся WK-идентичность, открытые нонсы, сгенерированный адрес и xpub восстановления с его подписью.
Данные действия, когда вы что-то подписываете. В них цепочка, путь деривации, ваша WK-идентичность, тип действия, сама полезная нагрузка и соответствующие UTXO.
У обеих коллекций в MongoDB есть TTL-индекс, выставленный в expireAfterSeconds: 900. Пятнадцать минут. База данных удаляет запись, что бы ни происходило: это не задача очистки, о которой кто-то должен помнить, и не обещание в политике конфиденциальности. Это индекс, исполняемый самой базой.
Токены push-уведомлений, чтобы телефон можно было разбудить, когда появляется что-то на подтверждение. Они сохраняются, потому что токен, истекающий каждые пятнадцать минут, был бы бесполезен.
Xpub восстановления, по одному на идентичность, вовсе без срока. Это сделано намеренно, и код прямо об этом говорит: он существует, чтобы кошелёк мог забрать его когда угодно, а не только в те краткие промежутки, когда оба приложения случайно бодрствуют.
Часть, о которой нам следует сказать прямо
Взгляните ещё раз на эту полезную нагрузку синхронизации. В ней есть расширенный открытый ключ.
Xpub — не ключ траты и не может разрешить транзакцию. Но это и не пустяк. Из xpub счёта выводится каждый адрес, который этот счёт когда-либо использует, а значит, обладатель может наблюдать весь баланс и всю историю транзакций по этой цепочке. Это доступ на чтение к вашей финансовой жизни на этом счёте — ровно та связность, избегание которой и составляет приватность в цепочке.
Нагрузка действия столь же реальна. Пока вы подписываете, релей работает с неподписанной транзакцией: куда идут деньги, сколько и из каких выходов.
Поэтому честная сводка — не «релей не видит ничего». Она такова:
Релей не может потратить ваши деньги и по пятнадцать минут кряду может видеть, что вы с ними делаете.
Пятнадцатиминутное окно — и есть смягчение, причём значимое: оно ограничивает, сколько истории может скопиться в одном месте. Но внутри этого окна данные там, и мы предпочитаем сказать это прямо, а не позволять слову «некастодиальный» выполнять риторическую работу, которой оно не заслужило.
Принцип устройства, который стоит перенять
В службе восстановления есть комментарий, схватывающий архитектуру лучше любой схемы:
кошелёк сверяет эту подпись с открытым ключом идентичности, который выводит сам, так что этому хранилищу не доверяют.
Xpub восстановления хранится вместе с отделённой подписью, которую сделал над ним SSP Key. Когда кошелёк его забирает, он самостоятельно выводит открытый ключ идентичности и сам проверяет подпись. Если бы релей вернул другой xpub — из-за взлома, ошибки или намеренной подмены, — подпись не сошлась бы и кошелёк его отверг.
Программное обеспечение, опирающееся на релей, обращается с ним как с недоверенной трубой. Так и следует строить поверх инфраструктуры, которой управляешь сам, потому что тогда ошибка твоего сервера не становится проблемой твоих пользователей. Это же и образец, который стоит искать, оценивая любой кошелёк: не «обещают ли они вести себя хорошо?», а «что будет, если их сервер поведёт себя плохо?».
Что враждебный релей действительно мог бы сделать
О настоящей модели угроз стоит говорить конкретно.
Он мог бы наблюдать. Внутри окна TTL — ваш xpub и вашу ожидающую транзакцию. Это раскрытие приватности, а не риск кражи.
Он мог бы цензурировать. Отказаться передавать сообщения между вашими устройствами, из-за чего вы не подписали бы новые транзакции обычным путём. Досадно и разрушительно — и не то же самое, что потерять что-либо. Ключи по-прежнему ваши, средства по-прежнему в цепочке, а пути восстановления существуют именно потому, что релея может не оказаться.
Он мог бы солгать и почти наверняка провалиться. Подмену xpub восстановления сводит на нет проверка подписи, описанная выше. Вот почему эта проверка важна.
Он не может подписать. Нет ключа — нет подписи, нет транзакции.
Реалистичный худший случай — слежка и срыв работы, а не потеря. Это заметно лучшее положение, чем у кастодиального сервиса, где соответствующий худший случай — денег больше нет. Это не то же самое, что «никто ничего не видит», и смешение двух этих вещей и приводит людей к ложной картине собственной приватности.
Что можно сделать с видимыми частями
Поймите, что раскрывает сопряжение. Синхронизировать цепочку значит, что xpub этой цепочки проходит через релей. Такова цена того, что двухустройственная конструкция вообще работает.
Помните, что окно короткое, но не нулевое. Пятнадцать минут на действие — это граница, а не отсутствие.
Считайте xpub восстановления постоянным. Он по замыслу хранится без срока и представляет собой открытый ключевой материал с проверяемой подписью, — но он долговечен, и лучше это знать, чем обнаружить.
Судите об архитектуре, а не о заверениях. Полезный вопрос о сервере любого кошелька — не обещает ли компания скромность. А заметило бы программное обеспечение, что сервер солгал. Наше сверяет подписи, а не доверяет ответам, и это можно прочесть в коде, а не принимать на слово.
Больше всего нам хотелось бы, чтобы поняли форму этого обмена. Кошельку на двух устройствах нужен канал согласования, а канал согласования — место, где скапливаются метаданные. Мы ограничили это сроком, который исполняет база данных, и спроектировали клиенты так, чтобы они не доверяли серверу, — но честная версия в том, что релей видит реальные вещи, недолго, и никакая тщательная архитектура не делает это число нулём.
