分层密钥生成

在本文中,我们将讨论确定性钱包,分层密钥生成及其在数学上的工作方式,以及在哪种情况下便于实践。 该材料对于其活动与支付网关,比特币钱包和其他硬币商店有关的专家很有用。 另外,对椭圆密码学和电子签名密钥部署方案感兴趣的人也将感兴趣。

确定性钱包


首先,让我们定义什么是确定性钱包。 在谈到密钥生成时,我们经常使用“钱包”一词,因为在加密货币的背景下,拥有私钥就是硬币所有权的证明,在这种情况下,钱包和密钥具有相似的含义。

确定性钱包是其中所有使用的私钥都是由所有密钥共享的一个秘密生成的钱包。 特殊之处在于,可以从一个秘密生成任意数量的密钥对以进行电子签名。 您可以为每个收款和更改使用新地址。

方便地,这种钱包的密钥可以轻松地转移到另一台设备上,进行备份,然后再还原,因为实际上您只需要保留一个主要机密。 此外,从主机密生成的所有私钥都不相互连接。 不可能跟踪生成的地址之间的连接(以确定它们全部属于一个用户),并且拥有生成的私钥,就无法还原共享机密。

基本秘密编码


现在让我们谈谈编码的主要秘密。 BIP39中定义了一些标准化方法。 这是将主要秘密转换为助记词的所谓“检查编码”编码-一组易于在纸上书写的单词,如有必要,请记住。 输入时,可以检查校验和,即以很高的概率识别错误(如果有)。

图片

如何运作? 实际上,您有一个主要秘密(熵)-扩展钱包所有个人密钥的数据。 这个秘密可以有不同的长度。 至于校验和:对于熵的每32位,将有1位校验和,即,通过公式将校验和计算为以位为单位的熵的长度除以32。

熵与校验和连接在一起,该校验和被计算为双SHA-256哈希(SHA-2的长度为256位),此后将切断所需的位数。 串联的数据将传输到另一个数字系统:从二进制到基于2048的数字系统(如您所见,2048是 211 ) 并且,如果将熵位的长度和校验和相加,将得到11的倍数。 这样,我们得到了输出助记词短语中的单词数。

实际上,数据按11位部分“切片”。 有2048个单词的字典( 211 )(某些要求适用于此)。 词典的默认语言是英语,但是任何人都可以使用。 单词长度不得超过一定长度(通常不得超过7个字符)。 所有字符都必须以UTF-8编码,并对所有字符进行某种标准化。 强制性的是前四个字符中每个单词的唯一性。

前四个字符唯一地标识字典中的单词,其余字符用于以方便的形式完成该单词,以供阅读,记忆等。因此,由11位组成的每条数据均以来自字典。 如果您的秘密熵为256位,则用于编码的数据将为264位,并且您的助记词短语将包含24个单词。 这是在实践中最常使用的BIP39中加密钱包机密的主要方法。

为了将来制作备份副本并使用它,请您将此短语写在外部介质上。 最好将纸张存放在安全的地方。 因此,您可以恢复对所有密钥的完全访问权限。

确定性钱包的类型


确定性钱包有两种类型。 考虑它们的主要区别。

第一个是最简单的。 这里的主要秘密是与我们想要获取的子键的索引连接在一起,然后对连接的数据进行哈希处理。 通常,这是使用SHA-256哈希函数发生的。

第二种类型包括分层确定性钱包(HD钱包),其原理在BIP32中定义,并且是用于分层密钥生成的非常常用的方法。

确定性生成


考虑图中这些类型的钱包之间的差异。

图片

一个普通的确定性钱包有一些种子,可以直接生成大量的私钥。 它们的数量只能受索引的大小限制,索引的大小在散列之前连接到机密。 通常为4个字节,也就是说,可能的选项空间允许大约40亿个唯一的确定性钱包密钥。 实际上,对于任何情况,这都足够。

分层确定性生成


让我们继续进行分层的确定性钱包,到目前为止,它的密钥部署方案以简化的形式呈现。 有种子,可以从中直接获得一对主密钥。 如果在一个普通的确定性钱包中得到一个私钥,那么在这里我们得到一对密钥。 此外,还有层次结构级别,在每个层次结构上我们都计算索引以生成子项。 我们还可以建立公钥分支和私钥分支。

层次级别


关于HD钱包,值得注意的是,根据层次结构每个级别上的BIP32规则,生成节点具有三个对象:私钥,公钥和用于生成下一个层次结构级别的链代码。

分层生成方案


让我们更详细地考虑BIP32的密钥生成方案。

图片

一切都从种子开始,也称为主种子,从中计算层次结构的零级-一对主密钥和链码。

可以从一对主密钥中生成大量具有特定索引的密钥对。 正在形成一个新的层次结构,用于生成帐户。 假设一个用户有种子并且想创建几个彼此不同的地址。 这些地址的硬币不会混合在一起,也不会一起发布,并且在它们之间完成的交易中将无法找到连接。 这些键将完全彼此分开使用。 在其中一个帐户中,关键组将用于工作预算,在另一个帐户中将用于个人预算,另一个帐户将用于黑簿记。 硬币不会相互混合。

下一个层次结构级别定义了不同的密钥生成链。 最常见的情况是使用索引为0和1的链。索引为0的链将生成最终密钥以形成收款地址,索引为1的链将为用户发送给自己的硬币(即找零)生成钱包。 这样做是必要的,以便程序级别的钱包可以将来自外部的付款与更改区分开来,计算每个交易余额的更改,并编制包含所有付款历史的可视列表。 这简化了钱包的开发及其日常支付的使用。

基于哈希的消息认证代码


现在,让我们继续进行分层密钥生成过程的数学部分。 首先,请考虑基于哈希的消息身份验证代码。 这是用于计算哈希函数的不同类。 它的不同之处在于,它在输入时采用两个值,而不是一个。 第一个值是私钥,第二个值是消息本身。

HMACKm=HKopad||HKipad||m



K是关键
m-讯息
opad,ipad-在散列的不同阶段,生成彼此不同的密钥所必需的一些常量值。
作为哈希函数,使用SHA-512。

特殊之处在于,为了使用HMAC,您需要拥有一个秘密密钥才能获得消息的正确哈希值。

因此,要计算HMAC哈希值,将XOR密钥的值与ipad常量值进行比较,然后对结果进行哈希处理。 将消息连接到该值,然后使用恒定值计算密钥XOR,将其与哈希值连接,然后再次进行哈希处理。 结果,我们获得了512位的哈希值。

推导函数


让我们看一些用于计算层次键的函数。

图片

首先,我们有兴趣将主种子转换为主密钥对。 之后,您需要从个人父密钥获取子私钥和子公钥。 在第二种情况下,使用与第一种情况完全相同的函数,但是将数字与基点相乘,因此将不单独考虑该函数。 下一步是从公用父密钥获取子级公用。 值得注意的是,不可能从父公钥获得孩子的个人身份。 此限制是由于HD钱包固有的某些属性,我们将进一步考虑这些属性。

因此,让我们分别研究每个生成函数。

图片

为了从主sid获取主密钥,使用了HMAC函数,其中将常量字符串“ Bitcoin seed”作为密钥进行传输,并将主秘密数据本身作为消息进行传输。 因此,获得了512位的哈希值,我们将其视为两个部分:左和右。 左侧是主私钥,右侧是链码。 此外,这些值将用于生成子密钥的后续级别。

为了公开主密钥,只需将基点的值乘以主私有密钥的值即可。 如您所见,这类似于椭圆曲线上一组点中的普通键。

现在,让我们来看一下子私钥如何来自父私钥。

图片

我们将再次使用HMAC函数。 作为密钥,我们传递当前层次结构级别的链代码,并作为消息(连接),其中第一部分将是个人父密钥乘以基点。 实际上,这是对这一点的强制转换和序列化。 串联与我们要接收的子密钥的索引发生,以32位(即4个字节)序列化。

基于HMAC函数的结果,我们得到值I,然后再次将其分开考虑:输出值的左右部分为256位。 然后子私钥 ki 我们通过添加到左侧的输出值来计算 Il 父私钥的值。 加法以n为模,其中n是椭圆曲线基点的顺序,以便不超过私钥的最大值。 因此,我们收到了一个孩子的私钥。

因此,子链代码将等于HMAC函数的正确输出值,即 IR 。 如果要从个人父密钥中找到子公钥,请将该值乘以 ki 通过椭圆曲线上的基点值。 这样我们就得到了公钥 Ki

我们如何从公共父密钥计算子公共密钥?

图片

这里的计算将有所不同。 我们将当前层次结构级别的链层次结构作为HMAC函数的键传递,然后序列化父公钥,并将其与序列化为32位的所需索引连接起来。 输入数据的获取方式与前一种情况完全相同。 要计算公钥,我们取HMAC函数输出值的左侧,并将其视为按基点顺序取模的256位,将其带到椭圆曲线上的某个点,即乘以基点,然后将结果与父公钥相加。 加法的结果也很重要,它将是公共子密钥。 该键的链代码将在HMAC函数的输出值的右侧。

相互匹配的密钥


这可能引发一个逻辑问题,即以不同方式获得的私钥和公钥将如何相互对应。 通过采用以另一种方式获得的私钥并将其乘以基点,是否真的有可能从以公共方式生成的公钥中获得完全相同的值? 这很容易验证。

图片

如果我们回想起我们如何计算个人子密钥,然后将其乘以基点,即得出point函数,然后回想子公共密钥的计算并比较这些计算,我们会发现,如果我们将父公共密钥视为个人父项的乘积关键点,然后我们将看到执行相同的计算,只是顺序不同。

在一种情况下,我们将私钥相加并与基点相乘,在第二种情况下,我们首先将值与基点相乘,然后相加并得到结果。 基于在椭圆曲线上加点的操作是累加的事实,我们可以说这两个值相等-我们将获得以两种方式计算出的相同公钥。

公钥示例


为了引起兴趣,我们可以看一个为测试值和BIP32计算而获得的公共密钥的示例。 如果我们的熵由128位组成,那么在十六进制系统中,它将看起来像下面的图像。

图片

BIP39助记词短语中编码的相同值看起来像所示的12个单词。 如果将此助记词短语用作生成层次密钥的主种子,则将获得具有相应256位链码的主密钥。

扩展键


还存在诸如扩展的公共密钥和扩展的私钥的概念。 如何使用? 为了更好地理解,我们描述了视觉情况。

假设我们有一个特定的用户和一些服务。 服务以一定频率将付款(例如比特币)转移给用户。 用户和服务都对每次付款都使用新地址感兴趣,以使外部观察者难以确定事实并混淆彼此的交互历史。

在最简单的情况下,它看起来像这样:用户为每次收到的付款生成一个新的密钥对,计算他传递给该服务的地址,之后该服务可以生成交易并完成付款。 但是,如果这些付款的强度很高,那么对于任何一方来说都是不方便的。

扩展公钥


在类似情况下,扩展的公共密钥(xPubKey)有助于消除不便之处。 用户可以使第三方服务生成地址,而不是由该服务知道的自身地址,但是只有用户才具有私钥。 该服务可以在用户不知情的情况下生成任意数量的地址并向他们汇款,并且用户可以在他方便的时候部署私钥并获得对任何这些地址的访问权限。

如何运作? 用户需要在密钥层次结构的第二个级别上生成一个新帐户,为他计算当前级别的公共密钥和链式代码。 之后,您需要将公钥和链码都传输到服务。 为了方便起见,我们介绍了Base58Check编码(这里有一个特殊版本)。 接下来,将公钥,链码和校验和连接在一起。 所有这些都在基数系统58中进行了编码,我们得到了已经根据某种标准进行编码的公共扩展密钥。 它以易于识别的字符“ xpub”开头。 它将如图所示。

图片

服务可以接受这样的密钥,并通过BIP32为用户部署公共密钥,从中接收地址并为其付费。 但是,只有用户可以计算相应的私钥。

强化推导


在密钥的分层生成中,存在诸如强化派生之类的事情。 这是一种不允许从相应的父公钥计算子公钥的方法。 , HMAC , hardened derivation .

, . 32 , hardened derivation : 231 , 1 ( ). , , hardened derivation 231

图片

, hardened derivation, . , . , . normal derivation, , .


, .

图片

, . - . “m”, , “M”. , , hardened derivation, — normal derivation.

, BIP32, .

图片

, -. , , , , , 1 , ( ). , .

BIP32 0, m, 0 hardened, chain — 0, — 0 (m/0'/0/0). .

, BIP43, , (m/bip_number'/*).

图片

, BIP44, , 44, : , , . .

图片

, “m/44'/0'/0'/0/0”, Bitcoin testnet — “m/44'/1'/0'/0/0”, Litecoin — “m/44'/2'/0'/0/0”, Dash — “m/44'/5'/0'/0/0”. , Ethereum - “m/44'/60'/0'/0/0”.

— BIP45. , multisignature BIP16, P2SH. BIP43 45, (cosigner).

图片

, 3--5. 5 , , 3 . , HD -, . , , . , , , , . , , .

, , , multisignature .


.

— master seeds ?

Seed — , - , , , , BIP39, . , — . , BIP44, . , .

— BIP39, 2048 ? ?

, BIP39. BIP39 : , , , , , . . , BIP39 , . , BIP39, . , , , .

— Coinbase - ?

, , , , , BIP32, . , , , , . , , .

— — , X Y?

— , , — , , . — X Y, 256 .

— “ ” ?

, , , . , , . . , , . , , Y , , : . , , , , . , . , , . — 4 . , 4- . , .

— derivation HD ? , ?

BIP32, , BIP39, . . GitHub, Bitcoin. Bitcoin, , BIPs (), .

, . , , , . , , , . . , - , .

— Hardened derivation ?

. hardened derivation . BIP44 hardened derivation : BIP, — , , — , . , , , . , hardened derivation .

— ?

, . . , . , . , .

- Blockchain “ ”.

Source: https://habr.com/ru/post/zh-CN413627/


All Articles