Nueva contribución de @Evias para NEM

Jerarquía de múltiples cuentas para carteras principales

Resumen

Este documento describe carteras deterministas jerárquicas para NEM.

Este documento utiliza  BIP32, BIP39, BIP43 Y BIP44  de Bitcoin como fuentes de documentación.

Se necesita un estándar para la creación de carteras deterministas para mejorar el manejo de las carteras NEM dentro de las aplicaciones cliente.

Este estándar establecerá las reglas para generar claves extendidas según lo definido en BIP32, para generar frases de paso mnemónicas definidas en BIP39 y para definir una jerarquía lógica para carteras deterministas.

Los extractos de los documentos de Bitcoin se agregarán entre comillas y las extensiones detalladas o las actualizaciones se anotarán para la plataforma NEM.

Motivación

Las versiones anteriores de los clientes NEM (billeteras) utilizaban una contraseña de usuario para cifrar las claves privadas, lo que conlleva la necesidad de crear copias de seguridad cada vez que se genera una nueva clave privada.

Las carteras deterministas no requieren copias de seguridad frecuentes, ya que permitirán la generación de múltiples claves públicas (direcciones) sin revelar la clave privada de gasto, con el uso de las matemáticas de curva elíptica.

Esta jerarquía de múltiples cuentas admitirá varias cadenas de pares de llaves (árboles múltiples) para permitir el intercambio selectivo de claves públicas de billetera.

Además, definiremos el código mnemónico para generar claves deterministas utilizando la definición en Bitcoin BIP39.

Además, utilizando [Bitcoin BIP44], definiremos un esquema para construir jerarquías lógicas para carteras deterministas. Esto representará el método recomendado para trabajar con carteras y llaves NEM CATAPULT.

Especificación: Funciones de Conversión

Desde el estándar de Bitcoin, como funciones de conversión estándar, asumimos:

  • punto (p): devuelve el par de coordenadas resultante de la multiplicación del punto EC (aplicación repetida de la operación del grupo EC) del punto base ED25519 con el entero p.
  • ser32 (i): serialice un entero sin signo de 32 bits i como una secuencia de 4 bytes, primero el byte más significativo.
  • ser256 (p): serializa el entero p como una secuencia de 32 bytes, primero el byte más significativo.
  • serP (P): serializa el par de coordenadas P = (x, y) como una secuencia de bytes utilizando la forma comprimida de SEC1: (0x02 o 0x03) || ser256 (x), donde el byte de encabezado depende de la paridad de la coordenada y omitida.
  • parse256 (p): interpreta una secuencia de 32 bytes como un número de 256 bits, primero el byte más significativo.

Especificación: Claves Extendidas

El documento Bitcoin BIP32 describe las claves extendidas en detalle. Con los siguientes extractos:

Representamos una clave privada extendida como (k, c), con k la clave privada normal y c el código de cadena. Una clave pública extendida se representa como (K, c), con K = punto (k) yc el código de cadena.

Cada tecla extendida tiene 2 ^ 31 teclas secundarias normales y 2 ^ 31 claves secundarias endurecidas. Cada una de estas claves hijas tiene un índice. Las teclas secundarias normales utilizan índices de 0 a 2 ^ 31-1. Las teclas secundarias endurecidas usan índices 2 ^ 31 a 2 ^ 32-1. Para facilitar la notación de los índices de clave endurecidos, un número iH representa i + 2 ^ 31.

También se proponen múltiples funciones de derivación de claves secundarias (CKD) en BIP32, con las siguientes referencias:

No es posible derivar una clave secundaria privada de una clave principal pública.

Key Trees

En el documento de origen, se define un árbol de claves que hará uso de los CKD definidos anteriormente. Las funciones de derivación de clave secundaria se conectan en cascada varias veces para construir un árbol de claves.

Los nodos de hoja de ese árbol definen cada uno una clave (privada o pública). Una explicación detallada del árbol de claves creado se puede encontrar aquí.

Compatibilidad

Del documento estándar de Bitcoin BIP32:

Para cumplir con este estándar, un cliente debe al menos poder importar una clave pública o privada extendida, para dar acceso a sus descendientes directos como claves de billetera. La estructura del monedero (maestro / cuenta / cadena / subcadena) presentada en la segunda parte de la especificación es solo de asesoría, pero se sugiere como una estructura mínima para una fácil compatibilidad, incluso cuando no se hacen cuentas separadas o distinciones entre cadenas internas y externas. Sin embargo, las implementaciones pueden desviarse de ella para necesidades específicas; aplicaciones más complejas pueden requerir una estructura de árbol más compleja.

Implicaciones de seguridad

Las propiedades de seguridad de las propuestas de llaves extendidas se pueden encontrar aquí.

De la descripción de Bitcoin BIP32:

Las claves privadas y públicas deben mantenerse seguras como de costumbre. Fuga de una clave privada significa acceso a las monedas; filtrar una clave pública puede significar la pérdida de la privacidad.

Se debe tener un poco más de cuidado con respecto a las claves extendidas, ya que éstas corresponden a un (sub) árbol completo de claves.

Una debilidad que puede no ser inmediatamente obvia, es que el conocimiento de una clave pública extendida principal, más cualquier clave privada no reforzada que descienda de ella, es equivalente a conocer la clave privada extendida principal (y por lo tanto, cada clave privada y pública que desciende de ella). Esto significa que las claves públicas extendidas deben tratarse con más cuidado que las claves públicas normales. También es la razón de la existencia de claves reforzadas y de por qué se utilizan para el nivel de cuenta en el árbol. De esta manera, una pérdida de la clave privada específica de la cuenta (o inferior) nunca corre el riesgo de comprometer al maestro u otras cuentas.

Especificación: estructura de la cartera

Las secciones anteriores especificaron los árboles de claves y sus nodos según lo definido por el documento fuente de Bitcoin BIP32. A continuación estamos imponiendo una estructura de billetera que aprovecha este árbol de claves.

Desde el estándar Bitcoin BIP32 – El diseño predeterminado de la billetera:

El diseño definido en esta sección es solo por defecto, aunque se recomienda a los clientes que imiten la compatibilidad, incluso si no se admiten todas las funciones.

Una billetera hiper determinista se organiza en varias cuentas. Las cuentas están numeradas, la cuenta predeterminada (“”) es el número 0. Los clientes no tienen que admitir más de una cuenta; de lo contrario, solo usan la cuenta predeterminada.

Cada cuenta se compone de dos cadenas de par de llaves: una interna y una externa. El llavero externo se usa para generar nuevas direcciones públicas, mientras que el llavero interno se usa para todas las demás operaciones.

Detallaremos la jerarquía lógica más detalladamente en la sección BIP44: Una jerarquía lógica para carteras deterministas.

Especificación: Semillas Mnemónicas

Las semillas mnemónicas son oraciones con palabras que coinciden con las listas de palabras, así como con una suma de comprobación tal como se define en BIP39’s Generating the mnemonic.

Las semillas mnemónicas se crean a partir de las listas de palabras disponibles en el anexo BIP39.

Las siguientes referencias serán utilizadas durante la implementación de referencia:

  • Generando la mnemotecnia
  • De mnemotecnia a semilla.

Especificación: Una jerarquía lógica con BIP44

Como queremos cumplir con el estándar BIP44, definiremos los niveles de ruta según lo recomendado en BIP44. Esto nos da los siguientes niveles de ruta:

m / purpose’ / coin_type’ / account’ / change / address_index

  • Nuestro nivel de propósito será de 44 ‘ya que estamos construyendo una jerarquía lógica siguiendo el estándar BIP44.
  • Nuestro tipo de moneda es 43 ‘, ya que esto corresponde a NEM en SLIP-44 adjunto al documento fuente.
  • El siguiente nivel corresponde al índice de la cuenta que queremos usar, comenzando en 0 para la primera cuenta.
  • El nivel de ruta de cambio se usa para definir qué llavero se debe usar. Establecido en 0, se dice que el llavero usado es externo, mientras que cualquier otro nivel de cambio de ruta resultará en el uso del llavero interno.
  • El nivel de la ruta address_index corresponde al índice de la dirección que queremos usar, comenzando en 0 para la primera dirección.

El apóstrofe agregado (‘) en los niveles de ruta se usa para marcar los niveles de clave endurecidos. Como se define en Bitcoin BIP32 y en la estructura de Cartera de este documento, el algoritmo BIP32 permite la derivación de dos espacios de claves completamente independientes. Esos a menudo se denominan espacio de clave endurecido y espacio de clave no endurecido.

Para NEM, podemos definir una jerarquía lógica básica de m / 44 ‘/ 43’. Se recomienda que las implementaciones de clientes sigan este estándar para lograr una mejor compatibilidad entre clientes.

Para implementaciones de clientes que no deseen implementar las capacidades completas de la jerarquía de múltiples cuentas para carteras deterministas, se recomienda usar solo la siguiente ruta de dirección predeterminada: m / 44 ‘/ 43’ / 0 ‘/ 0/0.

Ejemplos

Fuente: GitHub