Глоссарий / Адреса и ключи
Усиленная деривация
Другие названия: Усиленный расширенный ключ.
- Что такое усиленная деривация?
- При усиленной деривации приватный ключ родителя участвует в вычислении каждого дочернего ключа, и именно это не позволяет утекшему расширенному публичному ключу раскрыть ветвь под ним.
Определено в BIP-32.
Каждый узел в дереве BIP-32 может порождать 4 294 967 296 дочерних узлов, и верхняя половина этого диапазона ведет себя иначе. Индексы начиная с 2 147 483 648 являются усиленными (hardened), записываются с апострофом или буквой h, и ни один публичный ключ не может вывести их. Это ограничение представляет собой свойство, а не недостаток.
Как это работает
Усиленная и обычная деривация отличаются одним входным значением одного и того же хеша. Обе подают в HMAC-SHA512 цепной код родителя и индекс дочернего узла. Обычная деривация добавляет публичный ключ родителя, который уже есть у любого, кто располагает расширенным публичным ключом. Усиленная деривация добавляет вместо него приватный ключ родителя с префиксом в виде нулевого байта, поэтому вычисление невозможно выполнить без секрета.
Причина состоит в конкретной уязвимости, которую BIP-32 прямо описывает в своих примечаниях по безопасности: знание расширенного публичного ключа родителя вместе с любым не усиленным приватным ключом, происходящим от него, равносильно знанию расширенного приватного ключа родителя и, следовательно, всех ключей ниже этой точки. Арифметика за этим проста. Обычный дочерний приватный ключ равен ключу родителя плюс значение, вычисленное из публичной информации, поэтому вычитание этого значения восстанавливает родительский ключ.
Усиленные индексы закрывают этот путь. Для них не существует функции публичной деривации, поэтому расширенный публичный ключ останавливается на этой границе. Утекший xpub одного аккаунта раскрывает историю этого аккаунта и ничего выше него или рядом с ним.
Где это встречается
Усиление проявляется в виде апострофов в пути деривации, и то, где они стоят, является осознанным проектным решением.
Стандартный путь для нативного SegWit выглядит так: m/84'/0'/0'/0/0. Первые три уровня, назначение, тип монеты и аккаунт, являются усиленными. Последние два, цепочка и индекс адреса, нет. Именно такое разделение делает работоспособным кошелек только для наблюдения: расширенный публичный ключ аккаунта может порождать все адреса получения и сдачи под собой, а злоумышленник, получивший тот же xpub, не может подняться к мастер-ключу или перейти в сторону m/84'/0'/1'.
Обозначение различается, ничего не меняя. BIP-32 пишет 0', многие инструменты принимают 0h, а Bitcoin Core пишет h в дескрипторах, которые экспортирует, потому что апостроф нужно экранировать внутри JSON. Путь, скопированный из Sparrow в Core, возвращается переписанным в форме h, что пугает людей в первый раз и является чисто косметическим.
Практическое правило кратко. Усильте каждый уровень вплоть до аккаунта, оставьте два уровня ниже него не усиленными, чтобы инструменты только для наблюдения продолжали работать, и рассматривайте любое программное обеспечение, предлагающее экспортировать отдельный не усиленный дочерний приватный ключ, как опасность, а не как удобство, потому что такой экспорт вместе с вашим xpub дает всю ветвь.
Усиленная деривация vs кодовая фраза
Усиленная деривация выполняется автоматически; кодовая фраза BIP-39 представляет собой секрет, который выбираете вы. Их объединяют в одну группу как способы усилить кошелек, но они решают несвязанные задачи. Усиление защищает дерево от расширенного публичного ключа, который утек, и каждый стандартный кошелек уже применяет его, не спрашивая вас. Кодовая фраза является дополнительным входным значением, которое смешивается с сид-фразой еще до построения дерева, создавая совершенно отдельный кошелек из тех же двенадцати или двадцати четырех слов. Забудьте кодовую фразу, и ваши биткоины станут недоступны, потому что нигде она не записана. Забудьте про усиление, и ничего не случится, потому что решали не вы.