Сценарий:
Если один закрытый ключ детерминированного кошелька будет скомпрометирован (известно консультанту), останутся ли в безопасности другие ключи (и начальное число)?
По дизайну это не относится к детерминированному кошельку Electrum, и разработчики знают об этом. Как насчет других детерминированных кошельков, например Armory?
Предлагаемый стандарт для иерархических детерминированных кошельков (см. BIP 32 ) разработан, чтобы разрешить это (и многое другое).
Он еще не реализован, но несколько авторов клиентов согласились принять его, как только он станет окончательным.
У меня была такая же потребность, и я не мог найти простых в использовании решений, поэтому в итоге я свернул свое собственное. Я новичок в биткойнах и криптовалютах, поэтому используйте с осторожностью:
Я предполагаю, что вы можете создать свой собственный кошелек, как вы сказали. В таких обстоятельствах я бы посоветовал вам следовать приведенной ниже логике.
Прежде всего, давайте предположим, что кто-то закодировал (поскольку веб-сайт блокчейна выпустил некоторые инструменты в свой раздел API) программное обеспечение, способное создавать биткойн-адреса для внешних пользователей. В таком сценарии, если алгоритмы, содержащиеся в таком программном обеспечении, размещенном на сервере, могут создать кошелек с мультиподписью для пользователей, в том смысле, что определенному пользователю потребуются оба закрытых ключа (по 2 ключа на каждый адрес), созданные программное обеспечение для того, чтобы тратить монеты из такого одноадресного кошелька, и если, например, сервер хранит закрытый ключ A и доставляет пользователю закрытый ключ B, то мы получим ситуацию «гибридного онлайн-кошелька», где только пользователь может использовать оба ключа, A + B, чтобы создавать, подписывать и транслировать транзакции, связанные с его биткойн-адресом.
Такая система была бы довольно безопасной для пользователя, если бы владелец программного обеспечения не знал и не взаимодействовал с закрытым ключом A (или B) и если шифрование, используемое перед сохранением этого закрытого ключа A, сделало бы бесполезным любую третью сторону (даже если там) любой доступ к этому сохраненному ключу из базы данных сервера.
Теперь, с другой стороны, единственный способ построить транзакцию и подписать ее обоими закрытыми ключами может иметь место только на сервере (это очень важное условие, как я объясню позже в этом сценарии).
Если владелец программного обеспечения готов позволить пользователям покинуть сервер с обоими ключами (например, просто удалить свои учетные записи и установить такие адреса в качестве действительно холодных кошельков), он может использовать два варианта.
Один из них заключается в том, чтобы предоставить пользователю закрытый ключ A напрямую, что позволит ему использовать в другом месте (если и когда это необходимо) ключи A и B для подписи транзакций, или другой (как-то лучше), в котором алгоритм позволяет создавать третий ключ, ключ C, который можно использовать вместе с ключом B, чтобы тратить монеты с этого адреса. Другими словами, пользователь снова уходит с двумя закрытыми ключами в кармане, которых ему достаточно, чтобы использовать их для исчерпания соответствующего адреса (открытого ключа). Это можно реализовать либо с помощью начального числа (определенного закрытого ключа "D"), уникального для сервера (или учетной записи пользователя), либо путем установления в качестве начального значения даже ключа A. Если ключ A используется в качестве начального значения, тогда практически любой, у кого есть доступ к исходному коду программного обеспечения, может реплицировать весь диапазон адресов, созданных для конкретного пользователя (если ключ A «зависит от учетной записи пользователя», а не «от адреса»). Я считаю, что последнее невозможно использовать любому приличному системному администратору (если он хоть немного представляет себе риски, связанные с выбором безопасности такого низкого уровня). Итак, давайте предположим, что сервер создает семена с более высокими привилегиями (то есть специфичными для пользователя). Это, опять же, может иметь катастрофические последствия для любого неосторожного пользователя, который импортирует этот ключ A в любой кошелек с устройства, зараженного вредоносным ПО. (Может быть, это как-то напоминает кошелек Electrum? :/ ...) Я считаю, что последнее невозможно использовать любому приличному системному администратору (если он хоть немного представляет себе риски, связанные с выбором безопасности такого низкого уровня). Итак, давайте предположим, что сервер создает семена с более высокими привилегиями (то есть специфичными для пользователя). Это, опять же, может иметь катастрофические последствия для любого неосторожного пользователя, который импортирует этот ключ A в любой кошелек с устройства, зараженного вредоносным ПО. (Может быть, это как-то напоминает кошелек Electrum? :/ ...) Я считаю, что последнее невозможно использовать любому приличному системному администратору (если он хоть немного представляет себе риски, связанные с выбором безопасности такого низкого уровня). Итак, давайте предположим, что сервер создает семена с более высокими привилегиями (то есть специфичными для пользователя). Это, опять же, может иметь катастрофические последствия для любого неосторожного пользователя, который импортирует этот ключ A в любой кошелек с устройства, зараженного вредоносным ПО. (Может быть, это как-то напоминает кошелек Electrum? :/ ...)
Последний доступный вариант — это когда у сервера есть собственный начальный ключ (с наивысшими привилегиями), к которому не может получить доступ какая-либо третья сторона, и который сочетается по крайней мере с другим (сервер также защищен мультиподписью).
Возвращаясь к вашей ситуации, у вас должен быть ключ B, предлагающий повышенные привилегии (позволяющий вам создавать ключи D и далее, но любой, кто использует D, не сможет создавать другие ключи). Поскольку, однако, такая вещь была бы бременем для кода, я бы предложил более простой вариант: один путь - один размер - транзакция. Это означает, что вы импортируете в любой кошелек по вашему выбору ключи после некоторой сладкой очистки основных функций. Как когда-то сказал Генри Форд о своих автомобилях «вы можете заказать любой цвет, а раз он только черный».
Импортированный адрес, где бы он ни хранился, может быть закодирован таким образом, чтобы сделать возможной одну единственную операцию : отправить платеж определенной суммы исключительно на другой адрес X из вас (например, вы можете каждый раз отправлять только около 0,1 BTC на ваш горячий кошелек). -- карманные деньги). Нужно что-то еще? Еще один фиксированный транш в размере 0,100 BTC на тот же адрес. Только то. Идеальный твик. Конечно, адрес X может храниться в аппаратном кошельке, полностью защищенном. Другие виды трат могут быть возможны только с использованием самого сервера (чтобы разблокировать полный контроль над балансом адресов).
Все зависит от того, как был создан ваш детерминированный кошелек, если он основан на хеше, он будет безопасным. Что вам нужно, так это то, что невозможно обнаружить начальное число с фактическими закрытыми ключами, поэтому оно должно использовать одностороннюю функцию (например, хеш-функцию).
И в целом компрометация закрытого ключа в кошельке не включает остальную часть кошелька.
KEY=HASH(SEED + offset)работать? Таким образом, ни один, SEEDни другие адреса не будут угадываться.Кошелек Armory позволяет это, и это никоим образом не ставит под угрозу безопасность кошелька. Однако это ставит под угрозу целостность ваших резервных копий. Детерминированные кошельки полезны тем, что вы можете сделать одну резервную копию прямо в начале (до ее использования), и она будет хорошей резервной копией навсегда.
То есть, если вы не импортируете адреса откуда-то еще. Этих новых адресов не будет в вашей старой резервной копии, поэтому вам придется сделать новую резервную копию в этот момент.
Алок