Как один человек может обеспечить безопасность коллекции онлайн-кошельков?

Мое решение в Open-Transactions состоит в том, чтобы создать пул голосования между участвующими серверами транзакций. (Я заметил, что люди обсуждают здесь проект, поэтому я хотел убедиться, что это было только предложено — я еще не закодировал его.)

Когда Алиса подключается к серверу OT, вместо того, чтобы отправлять свои BTC непосредственно на сервер, она отправляет их в пул для голосования.

===> Мое предложение заключалось в том, что всякий раз, когда она хочет снова выйти из строя, она отправляет подписанный запрос на сервер, а затем пересылает подписанный ответ сервера членам пула. ЕСЛИ у членов пула есть запись/аудит учетной записи Алисы (которая должна быть в DHT, которую они совместно используют) и ЕСЛИ обе подписи проверяются на квитанции, и ЕСЛИ запрос находится в пределах распределения для этого сервера и его максимальной резервной копии за единицу. -день, затем члены пула голосуют НА БЛОКЧЕЙНЕ, чтобы вернуть средства Алисе.

===> Это также может иметь временную задержку, например, 24-часовую помощь, если это необходимо, и это также зависит от того, что все участники пула имеют доступ к данным аудита других участников пула. (Другие серверы транзакций.)

===> В случае, если сервер ВЗЛОМАН, он все равно не сможет переместить какие-либо биткойны Алисы, потому что другие члены пула не будут голосовать за него без подписи Алисы.

===> В случае, если сервер использует фиктивную учетную запись (скрытую от DHT) для надувания внутренней валюты, другие члены пула не будут голосовать за такое спасение, потому что это не может пройти в режиме реального времени или ежедневный аудит.

===> В случае, если сервер отказывается отвечать на запрос Алисы о спасении, она может отправить его членам пула, что вызывает отправку сообщения серверу-нарушителю. Если после тайм-аута нет ответа, они могут проголосовать 9 из 10 (или сколько угодно) за освобождение средств. Это дает возможность восстановить средства даже с серверов, которые напрочь исчезли.

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

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

Эти схемы позволяют серверам в облаке выполнять вычислительные задачи (в настоящее время только ограниченный набор арифметических операций) над зашифрованными значениями без их расшифровки. Дополнительные сведения см. в разделе Какую пользу приносит облаку полное или частичное гомоморфное шифрование? - ИТ-безопасность - Stack Overflow на русском

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

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

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

Как небольшой поставщик электронных кошельков, вы объединились бы с некоторыми коллегами, сформировав сеть операторов кошельков.

Используя возможности сценариев Биткойн, пользователь Алиса может создать специальную транзакцию и опубликовать ее в блокчейне. Эта транзакция в основном представляет собой долговую расписку — у нее есть срок действия и некоторые инструкции. Если инструкции выполняются до истечения срока транзакции, транзакция выполняется, и сеть Биткойн соглашается на перевод денег.

Алиса может указать несколько сторон (т.е. вас и ваших коллег) в качестве исполнителей долговой расписки. Ее сценарий может сказать: «Мне требуется 9 из этих 10 серверов кошелька, чтобы подписать эту транзакцию».

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

Я призываю всех, кто заинтересован, проверить репозиторий github и внести свой вклад. Товарищ до сих пор выполнял всю эту работу самостоятельно и нуждается в помощи.

Все зависит от вашего определения того, что такое онлайн-кошелек.

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

BCCAPI является примером такой службы.

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

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

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

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

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

Идея состоит в том, что единственной целью автономного хранилища является подписание транзакций. Все остальное делают другие машины. (Убедитесь, что он отображает сумму и пункты назначения, прежде чем попросит вас подписать!)

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

Как правило, в частном секторе это не делается. Вы верите, что эти отрасли делают все правильно, но обычно это не так. Безопасность сложная, очень сложная. Защита от себя (доступ с помощью винта с накатанной головкой и резинового шланга: p), когда у вас есть прямой доступ к оборудованию, делает это еще сложнее.

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

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

Ответ — шифрование на стороне клиента .

В основном это работает примерно так.

1. Вы регистрируетесь в сервисе электронного кошелька.
2. КЛИЕНТ. Затем вы создаете свою первую пару биткойн-ключей. Это делается с помощью Javascript, запущенного в браузере.
3. КЛИЕНТ. Вам будет предложено ввести надежный пароль для защиты этой пары ключей.
4. КЛИЕНТ. Закрытый ключ зашифрован в клиенте с помощью Javascript.
5. СЕРВЕР. Наконец, открытый ключ и зашифрованный закрытый ключ отправляются на сервер для хранения.

Служба электронного кошелька не имеет доступа к вашим приватным ключам.

Когда вам нужно потратить монеты со своего адреса.

1. Выберите пару ключей Биткойн, с которой хотите потратить деньги.
2. КЛИЕНТ - Вам будет предложено ввести пароль для расшифровки закрытого ключа. Опять же, это делается на стороне клиента.
3. КЛИЕНТ - Платежная транзакция подписана. (В браузере)
4. СЕРВЕР — транзакция отправляется на сервер и перенаправляется в сеть Биткойн.

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

При таком подходе все еще есть риски.

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

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

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

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

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