Topic: Леджер - аппаратный кошелек для хранения к
- page 7. (Read 49855 times)

Давайте поставим вопрос шире. Прочитав всю вашу переписку с tenant48, я пришел к выводу, что чисто теоретически побайтово можно вывести Seed в течении примерно 64 транзакций через блокчейн биткоина, но смысл это будет делать только через приложение Ledger Live, так как выводя эти байты через стороннее приложение для компании Леджер это будет просто бессвязный набор байт, которые непонятно кому принадлежат.
Но да бог с ним, но даже если предположить, что Леджеру удастся через 64 транзакции добраться до вашего Seed (что вам кстати так и не удалось объяснить, как именно это сделать не через родное, а стороннее приложение), то можно после 63 транзакций (что очень не мало, так как транзакцией следует считать только отправку а не получении монет) просто перевести все монеты на новую парольную фразу, тем самым солидно сэкономив на комиссиях, так как в мультиподписных транзакциях они значительно больше.

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

А, ну я не понял, если так, то конечно нормально. Если это просто повышенный уровень безопасности типа как 2 FA,  только конечно без участия всяких левых гуглов   

Не буду спорить, хотя не согласен. Но здесь речь шла о единоличном владении мультисиг-кошельком, а не о кооперативном.

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

Так это теоретически значит что этот сид где-то на серверах леджера давно уже  крутится.
Это что, разве так?

Теоретически леджеровцы могут спереть сид и без новой фичи. Будут ли они это делать? Сильно сомневаюсь. Но могут, и это для меня, например, неприемлемо.Я считаю, что вопрос должен ставиться шире: можно ли использовать этот аппаратник вообще в одноподписных кошельках? Зависит от того, готовы ли вы принять какой-либо риск потери средств с леджера или нет.

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

Вот 20 постов прочитал вашего разговора о бип 32/39 и мастерключах.  
И нихрена не понял. Вы ведь не забывайте, что раздел локала называется "новички"
Можно может как то попроще.

Вот допустим есть у меня старый леджер ещё со шнурком,  лет 6 ему наверное. Так эта новая фича от девов леджера  что неужели сопрет мою сид которая ещё с тех давних пор никогда никуда мною не вводилась.
И можно ли юзать их ledger live, или не стоит. ?

Или может напрасно такой шорох подняли. Хотя наверное и не напрасно?, я так и не понял.

Это главный вопрос, по-вашему? По-моему, главный вопрос следующий - существует ли возможность у разработчика закрытой прошивки кошелька незаметно воровать ключи пользователей без вспомогательного софта на компе жертвы? Я считаю, что да, существует. У всех пользователей можно украсть ключи таким способом? Нет, не у всех. Могут ли пострадать исключительно пользователи биткоина? Могут при определенных условиях: либо транзакции должны быть взаимосвязаны (что не такая уж редкость, согласитесь), либо пользователь с электрумом будет пользоваться чужими серверами, а не своим (а среди общедоступных серверов при этом будет пару десятков нод злоумышленника, что несложно организовать).
На ваш "главный вопрос" мой ответ такой: идентифицировать каждого пользователя, наверное, невозможно, можно только поставить метку, что данная транзакция с высокой вероятностью отправлена с леджера, что тоже неплохо. Но я - дилетант. А профессионал, может быть, найдет более эффективный способ сузить область поиска.

А теперь вы мне ответьте на вопрос. На ваш метод обезопаситься от потенциальных козней леджера я написал буквально следующее: "Теоретически в закрытой прошивке возможен бэкдор, угоняющий BIP32-сид (не путать с BIP39 сид-фразой), в этом случае наличие парольной фразы не спасет. Тут только мультисиг обезопасит." Вы по-прежнему считаете, что я чушь написал? Вы по-прежнему считаете, что ваш способ на 100% всем подойдет?

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

Я привел пример с эфиром, чтобы не усложнять описание. В битке всё, конечно, сложнее, но тоже возможно, хотя реже. Да и в эфире не всегда получится (у меня, например, немного эфира на кошельке лежит уже 5+ лет, а транзакций сделано всего около 3-х десятков - мало, если по байту вытягивать).
Алгоритм по битку почитайте в статье по ссылке в сообщении satscraper, не вижу смысла его здесь описывать.
Про родное ПО я вообще ничего не говорю, говорю только про бэкдор в прошивке, не требующий какого-то дополнительного ПО на компе/телефоне жертвы.
Голословное утверждение. Могу так же голословно ответить, что многие пользуются эфиром и прочими evm-блокчейнами гораздо больше, чем битком.Никак. Я и не говорил, что 100% кошельков могут быть таким образом обчищены.

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

Можете менять профессию.

Вот рабочий алгоритм. По-моему очень близко к предложенному вами.  

Не знаю зачем, но раз надо, то давайте начнем.Я не программист, представляю себе это так. Если кто-то обоснованно раскритикует, буду только рад.
Проще описать алгоритм передачи через eth-транзакцию, там обычно используется только один адрес, и есть порядковый номер транзакции, который будет очень кстати как счетчик отправленных байтов.
Значение r (r - это, если упрощенно, результат ecdsa функции, примененной к произвольному числу - нонсу) в подписи первой транзакции с адреса подбирается перебором нонса таким образом, чтобы какой-то байт (допустим, десятый) этого r соответствовал первому байту сида. Во второй транзакции с данного адреса передается второй байт и так далее. Для маскировки следует передавать не непосредственно байт сида, а, к примеру, xor-ить его с хешем переменной - никто тогда не сможет уличить в бэкдоре.
В 90-х, помню, на ассемблере писались шикарные демки по 4 кБ и меньше. Не думаю, что это проблема, алгоритм тут совсем несложный.

Так вот с этого надо и начинать.

Как побайтово передавать Сид через родное приложение мне примерно понятно.
А вот чтобы передавать тоже самое через стороннее приложение, которым в нашем случае является Электрум, прийдется каким то образом впихивать в туже транзакцию вместе с полезной информацией еще и идентификаторы:Леджера, клиета, порядковый номер байтов и еще и сделать это так, чтобы все это не выглядело подозрительным для других. Лично я себе это плохо представляю.
Учитывая что у кошелька Леджер нано Х всего 2048Кб (у других моделей еще меньше), то запихнуть туда такой сложный алгоритм, чтобы он не сильно выделялся на фоне самой прошивки и приложений думаю врядли получится, даже если писать его на ассемблере.

Тут есть принципиальная разница? Корневой мастер-ключ - это hmac512 bip32-сида.
Это неважно, как я себе представляю.Да, можно, что угодно.
Верно.Cпасибо большое!

^

Вы речь завели не про приватный мастер ключ, а конкретно про bip 32Сид.
Через ваш бэкдор, который я уверен что вы мало себе представляете как именно он работает и как правильно реализовать алгоритм его работы,можно побайтово перегнать все что угодно, но вы про это не писали  
Из вашей логики практически все аппаратные кошельки уязвимы и моя инструкция сдесь не причем.
Если вам нравится, используйте и дальше свой мультисиг, я ничего не имею против. И давно дал вам мерит за пост про мультисиг

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


А я разве спорил с этим? Мнемоническая фраза вместе с парольной фразой прогоняются через pbkdf2-функцию, на выходе которой получается бинарный сид, из которого получается корневой мастер-ключ итд. Если бэкдор будет передавать этот сид... Не, давайте для простоты скажем по-другому: если бэкдор будет передавать приватный мастер-ключ через транзакции, какая бэкдору разница, как этот ключ был рассчитан? Ну поменяли мы пассфразу, изменился мастер-ключ, и что? Ничего - передается новый ключ.
 Я это и изначально признавал, тут не о чем спорить. Просто отметил, что ваша метода - не панацея.
Оправдаться за что? Покажите, где я сглупил?Я именно этот бэкдор и имел в виду в первой же реплике. Начинаю сомневаться, то ли вы понимаете под BIP32?
Возможно, что во время установки обновлений это сделать проще, не знаю. Но написать такой "редкий бэкдор" им тоже никакого труда не составило бы, и памяти для этого много не надо. А фейковый ГСЧ легко обходится импортом внешней сид-фразы, либо пассфразой.

Я же выше уже написал, что сид bip 32 ИЗМЕНИТСЯ после ввода парольной фразы. Ledger Live успеет перехватить только старый Сид bip-32 во время первоначальной настройки. Что вам еще не понятно. Доступа у кошелька к Ledger Live с установленной новой парольной фразой (и соответственно с новым  bip32 сид) больше не будет.

И вы ведь выше сами признали:

Но затем чтобы как то оправдаться, привели пример с крайне редким бэкдором, который к данному случаю не имеет отношения, так как первоначальный вопрос был не в этом а именно с угоном bip-32

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

^
Не мучайте уже своего опонента.

Он просто не понимает что BIP 32 seed, определяющий иерархическую структуру кошелька, получается из BIP 39 SEED фразы + парольная  фраза.

Поэтому при утечке BIP 32 seed-а эта парольная фраза что мёртвому припарка.



иными словами при скомпроментированном проприетарном MCU "открытая" прошивка не является панацеей.

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