Parte 2: Génesis de Ledger Recover: distribución segura de las acciones | Libro mayor

Parte 2: Génesis de Ledger Recover: distribución segura de las acciones | Libro mayor

Nodo de origen: 2785813

Bienvenido de nuevo a la segunda parte de nuestra serie de blogs sobre Recuperación de libro mayor¡La génesis! Nuestro objetivo es explorar los numerosos obstáculos técnicos que se encuentran al crear un servicio de recuperación de semillas y cómo Ledger Recover los resuelve con un diseño e infraestructura seguros.

En capítulo anterior, examinamos cómo hacer una copia de seguridad de una frase de recuperación secreta dividiéndola y cómo Ledger Recover lo hace por usted usando Compartir secretos verificables de Pedersen.

Ahora que tienes tres acciones, la siguiente pregunta es: ¿Cómo puede distribuirlos de forma segura a sus proveedores de respaldo? De hecho, si una parte malintencionada intercepta todas las acciones mientras usted las transmite, anula el propósito de dividir la semilla en primer lugar. En ciberseguridad, esto se llama Ataque de hombre en el medio, donde un atacante se interpone entre usted y su destinatario y altera la comunicación para intentar descubrir secretos.

Al utilizar Ledger Recover, la transmisión de su semilla se realiza a través de un mecanismo de distribución seguro. Se basa en varias herramientas criptográficas y conceptos matemáticos que explicaremos detalladamente.

Comenzaremos describiendo el problema que nos ocupa con más detalle. Luego, presentaremos varias herramientas criptográficas y conceptos matemáticos que Ledger Recover aprovecha para distribuir de forma segura sus acciones iniciales a los proveedores de respaldo.

Courier-In-The-Middle: un ejemplo del mundo real

La forma más obvia de protegerse de un intermediario mal intencionado es no tener ninguno. Puedes caminar tú mismo hasta las casas de tus amigos o reunirlos en el mismo lugar cerrado para entregar las acciones. Pero esto se vuelve mucho más difícil si no está ubicado en el mismo lugar y desea enviar las acciones a un conocido de larga distancia.

Suponiendo que la red a través de la cual nos comunicamos (por ejemplo, el servicio postal) sea inherentemente poco confiable, ¿cómo podemos garantizar que los espías nunca puedan vislumbrar nuestras acciones secretas?

Es hora de presentarles a Alice y Bob, y a la infame Eve, tres conocidos personajes de criptografía. Alice tiene un secreto que quiere compartir con Bob y no tiene más remedio que enviárselo a través de Eve, su mensajera poco confiable. En palabras criptográficas, Alice y Bob quieren establecer un canal de comunicación seguro entre ellos para intercambiar su secreto de forma segura.

Esto es lo que Alice y Bob podrían hacer:

  • Alice guarda su secreto en una caja, la cierra con su candado personal y luego se lo envía a Bob.
  • Cuando Bob recibe la caja, agrega su propio candado y lo devuelve.
  • Alice ahora puede usar su llave para sacar el candado de la caja antes de enviarlo por última vez.
  • Para finalizar el proceso, Bob simplemente usa su llave para quitar el candado y recuperar, por fin, el secreto de Alice.

Durante todo el intercambio, cada vez que Eve tuvo la caja en sus manos, siempre estuvo protegida, ya sea por el candado de Alice, el de Bob o ambos.

Si bien este es un excelente comienzo, quedan varios problemas por resolver en este escenario:

  • Autenticacion mutua: Alice y Bob necesitan formas infalibles de comprobar que cada candado realmente proviene de la otra parte. De lo contrario, Eve podría cambiarlo por su propia caja y candado y engañar a Alice o Bob haciéndoles creer que ella es la otra parte.
  • Secreto directo: Si Eve robó la caja cerrada y luego robó la llave de Alice o Bob, podría recuperar el secreto original. En lugar de eso, queremos asegurarnos de que futuras filtraciones de claves a largo plazo no puedan comprometer paquetes robados más antiguos.
  • Preservar la privacidad: En este escenario, las direcciones de Alice y Bob se revelan al mensajero. En el equivalente digital de este proceso, queremos un protocolo que no revele nada sobre los destinatarios.
Proteger mensajes digitales

En seguridad digital, un canal seguro es una forma de transferir datos entre dos autenticado partes tales que los datos confidencialidad y integridad están garantizados. Cuando utiliza un canal seguro, los atacantes no pueden espiar ni alterar su comunicación.

El protocolo de Ledger Recover tanto para copia de seguridad como para restauración se basa en un Protocolo de canal seguroo SCP. Utiliza múltiples herramientas de la criptografía moderna, como cifrado simétrico y asimétrico, certificados y firmas digitales.
Las siguientes secciones le brindarán una introducción rápida a todos estos conceptos, lo que le permitirá comprender todo el esquema de seguridad utilizado en Ledger Recover.

Criptografía simétrica: una herramienta poderosa pero limitada

Para garantizar la confidencialidad de los datos intercambiados entre dos partes, los datos suelen cifrarse y descifrarse con la misma clave secreta.
Este proceso se conoce como criptografía simétrica, que es el estudio de primitivas que involucran una única clave secreta para garantizar una o más de las propiedades de un canal seguro.

Si bien es una herramienta poderosa para proteger sus comunicaciones, la criptografía simétrica tiene algunas limitaciones obvias: supongamos que Alice quiere intercambiar varios mensajes cifrados con Bob. Primero elige una clave secreta y luego la comparte con Bob antes de comenzar a enviar mensajes.
Por supuesto, el problema ahora es: ¿Cómo comparte Alice la clave secreta de forma segura con Bob? Si alguien consigue la clave, la comunicación entre Alice y Bob ya no será confidencial.
Alice podría reunirse con Bob en persona para darle la llave, pero en este caso, ¿por qué no conversar entonces, lejos de oídos curiosos?

Para las comunicaciones digitales, necesitamos un método seguro para compartir la clave simétrica e iniciar el intercambio de datos protegidos. Es hora de presentar el trabajo de dos titanes de la criptografía moderna, Whitfield Diffie y Martín Hellman.

Criptografía asimétrica: ocultar tus partes privadas
Acuerdo clave Diffie-Hellman

Con la criptografía de clave pública, Diffie y Hellman idearon un enfoque novedoso para proteger las comunicaciones. Definieron un protocolo con dos claves distintas para cifrado y descifrado. Las dos claves se llaman comúnmente claves públicas y privadas, formando un par que se puede utilizar para cifrar/descifrar y firmar/verificar datos.

Claves públicas y privadas
La criptografía de clave pública es la base de la mayor parte de nuestra seguridad digital. Se utiliza para protegerlo en la web y también es la forma de demostrar la propiedad de monedas y tokens en todas las cadenas de bloques públicas.

Obtenga más información sobre este tema en Ledger Academy!

Lo que es realmente convincente para nosotros es cómo Diffie y Hellman sugirieron utilizar criptografía de clave pública para distribuir claves simétricas. Su método, conocido como Intercambio de claves Diffie-Hellman, Consiste en intercambios de ida y vuelta entre dos partes para finalmente acordar un secreto compartido. Si se realiza correctamente, los espías no pueden calcular el mismo secreto compartido a partir de la información que escuchan.

Generando un secreto compartido k

El TL;DR es que en el diagrama anterior, Eve es matemáticamente incapaz de descubrir el secreto. k a pesar de que tiene acceso a todas las comunicaciones de Alice y Bob. Para comprender por qué este secreto compartido está a salvo de cualquier espía, debemos profundizar un poco en la teoría de grupos. 

La seguridad del intercambio de claves Diffie-Hellman depende de la complejidad del problema del logaritmo discreto sobre un grupo cíclico. Un grupo cíclico es un grupo generado por un solo elemento.
En pocas palabras, Alice y Bob ejecutan los siguientes pasos para acordar un secreto compartido k:

  1. Alice y Bob acuerdan un grupo cíclico G de orden n generado por un elemento g
  2. Alicia saca al azar un número. 0 < a < n y envía pa = gramoa ∈ GRAMO a Bob
  3. Bob saca al azar un número 0 < b < n y envía pb = gramob ∈ GRAMO a Alice
  4. Alice calcula el secreto compartido k =(pagb )a ∈ GRAMO
  5. Bob calcula el secreto compartido k =(paga )b ∈ GRAMO

La seguridad del protocolo depende de la dificultad de encontrar k=gab dado g, ga, gb. Esto se llama el Cálculo Supuesto de Diffie-Hellman (CDH). La hipótesis de que la CDH es difícil de resolver supone que la problema de logaritmo discreto es difícil de resolver.

En este esquema, si bien el secreto compartido está a salvo de escuchas ilegales, no hay garantía sobre el origen de los datos que se intercambian. Para que la interacción sea segura, Alice y Bob deben demostrar de alguna manera su identidad el uno al otro.

Autenticación mutua y firma digital

Generalmente se utiliza una firma manuscrita para reconocer y aceptar el contenido de un documento. Sólo el firmante puede producir la firma, pero cualquiera que “sepa” cómo es la firma puede verificar que el documento ha sido firmado por la persona adecuada.

Si bien tiene propiedades similares, una firma digital proporciona sólidas garantías adicionales al aprovechar la criptografía asimétrica:

  • Autenticidad: cualquiera puede verificar que el mensaje fue firmado con la clave privada correspondiente a la clave pública especificada.
  • No repudio: el firmante no puede negar haber firmado y enviado el mensaje.
  • Integridad: el mensaje no fue modificado durante la transmisión.

Ahora, mientras conocemos y confiamos en la clave pública de nuestro corresponsal, podemos comprobar la autenticidad de todos los mensajes verificando su firma digital.
Sin embargo, en la mayoría de los casos del mundo real, o no conocemos íntimamente a nuestro corresponsal o es posible que necesite cambiar periódicamente su par de claves pública y privada por razones de seguridad. Esto requiere una capa adicional de verificación y confianza en forma de Certificados, que contienen la descripción de una entidad y su clave pública.

Cada certificado está firmado por una clave pública principal. Al tener una Autoridad de Certificación Raíz (o CA Raíz) en la que siempre confiamos, podemos crear una cadena de confianza mediante firmas digitales sucesivas.

Curvas elípticas: criptografía de clave pública de siguiente nivel

La criptografía de curva elíptica (ECC) es una subárea de la criptografía de clave pública que consiste en utilizar curvas elípticas para aplicaciones criptográficas, por ejemplo, para cifrado o esquemas de firma. 
Basado en las matemáticas actualmente entendidas, ECC proporciona una base significativamente más segura que los sistemas de criptografía de clave pública anteriores como RSA.

Con el mismo nivel de seguridad, ECC implica longitudes de clave más pequeñas en comparación con otros criptosistemas asimétricos, lo que lo convierte en una buena opción para sistemas integrados con recursos limitados.
Si desea saber más, este artículo puede ayudar a comprender mejor las curvas elípticas.

Orden de una curva elíptica
El orden de un elemento g de un grupo es un parámetro importante del intercambio de claves Diffie-Hellman. Cuando el grupo es una curva elíptica, ese elemento es un punto y su orden es el número de veces que se puede agregar a sí mismo antes de recorrer su valor inicial.
Tenga en cuenta que esta suma no tiene nada que ver con la suma habitual de números reales, pero tiene propiedades de aditividad similares.

Tomemos la curva elíptica E: si2 = x3 +2x+3 sobre el campo 𝔽97 como ejemplo. Como función discreta, está representada por los puntos de la siguiente figura. Nos centraremos en el punto P =(3, 6) y todos sus múltiplos.

Lo vemos después de las 5.P, volvemos al principio y llegamos a los mismos puntos que antes. No importa cuál sea el valor del escalar P se multiplica por, siempre acertaremos a uno de nuestros 5 puntos iniciales.
Así el orden de P es 5 y el subgrupo que genera contiene exactamente 5 puntos. Sin embargo, para aplicaciones criptográficas, el orden es mucho mayor que 5, lo que aumenta la aleatoriedad.

Mezcla todo: ECDH con autenticación

Ahora tenemos todas las herramientas que necesitamos para crear un excelente protocolo de intercambio de claves:  Curva elíptica Diffie-Hellman (ECDH).

ECDH es un esquema criptográfico estandarizado que implementa el intercambio de claves Diffie-Hellman que describimos anteriormente, mediante el uso de criptografía de curva elíptica para generar los pares de claves y el secreto compartido.

Intercambio de claves ECDH autenticado

Comienza seleccionando una curva elíptica y su punto generador. Luego, las dos partes intercambian certificados confiables, lo que les permite verificar la autenticidad de sus respectivas claves públicas. Una vez autenticados, pueden generar un secreto compartido k que se calcula como:

k = reA . reB . G
dA: Clave privada de Alice
dB: Clave privada de Bob
G: punto CE

Para lograr el secreto hacia adelante propiedad, el par de claves de Alice y Bob deben ser efímeras, es decir, se generan en el momento y se utilizan para una única ejecución del protocolo. Hablamos de una Curva Elíptica Diffie-Hellman Efímera (ECDHE). En este escenario, las claves efímeras están firmadas tanto por las claves estáticas del dispositivo como por los HSM, lo que permite una autenticación sólida de las claves. Incluso si en el futuro ocurriera un acceso no autorizado a las claves estáticas, no otorgaría capacidades de descifrado para los intercambios protegidos por las claves efímeras.

Además, hemos implementado una mejora notable en el protocolo al ocultar las claves estáticas de los dispositivos dentro del canal seguro. Esta medida de precaución evita que los atacantes obtengan visibilidad del certificado estático de los dispositivos, lo que, a su vez, podría provocar la filtración de identificadores únicos utilizados durante las operaciones de copia de seguridad/restauración.

Volver a Ledger Recover: El viaje de una semilla

Muy bien, es hora de hacer una pausa por un minuto.

Hemos cubierto muchos temas, relacionados tanto con la seguridad como con las matemáticas, y el resultado es un protocolo para comunicarse de forma segura a través de cualquier red insegura. Resumamos lo que hemos visto hasta ahora:

Dos entidades pueden tener comunicación segura a través de un canal inseguro acordando un secreto único Gracias a ECDHE, que es una implementación del protocolo de acuerdo clave Diffie-Hellman que utiliza llaves efímeras para proteger el secreto previo. Cada entidad es capaz de verificar la autenticidad de su corresponsal gracias a una inicial Verificación de certificado.

En el caso de Ledger Recover, hemos establecido cuatro canales seguros utilizando el Protocolo de canal seguro. Estos canales conectan el dispositivo a cada uno de los proveedores de respaldo y al orquestador, todos los cuales están equipados con módulos de seguridad de hardware (HSM).

Cada actor conserva su certificado personal, firmado por un Certificado de libro mayor que actúa como raíz de la cadena de confianza. Cuando el dispositivo del usuario transmite por primera vez su intención de realizar una copia de seguridad al Orchestrator, inicia un ECDHE autenticado. Bajo estas mTLS sesiones, el Orchestrator transmite información que vinculará los canales seguros futuros con la solicitud de respaldo particular del usuario, junto con la identidad del usuario que se solicitará para validación al realizar una restauración posterior de la semilla.

Salvaguardar secretos con HSM
Por mucho que intentemos evitarlo, a veces es necesario almacenar y procesar secretos en servidores. Esto puede resultar arriesgado, ya que proteger los servidores y su acceso no es una tarea trivial. Para mitigar este riesgo, las empresas e industrias que valoran la seguridad utilizan Módulos de seguridad de hardware. Son hardware especializado que protegen claves criptográficas y proporcionan procesamiento criptográfico. Hablaremos más sobre los HSM en partes posteriores de esta serie de blogs.

Todo está listo para finalmente realizar la parte más crítica de toda la operación: transmitiendo las tres partes de la semilla del usuario.

Una vez más, creamos nuevos canales seguros, pero esta vez entre el dispositivo Ledger del usuario y los HSM de los proveedores de respaldo. directamente. Las acciones de semillas se transmiten en un canal cifrado de extremo a extremo hasta su lugar de almacenamiento final, garantizando al mismo tiempo que lleguen al destino correcto (aquí es donde la verificabilidad de Pedersen Secret Sharing introducida en parte 1 es útil).
El dispositivo del usuario autentica los HSM de los proveedores de respaldo uno por uno, y los proveedores de respaldo saben que están intercambiando con el dispositivo oficial único de Ledger que inició esta solicitud de respaldo específica.
Nadie, aparte del dispositivo del usuario y los HSM de los proveedores de respaldo, ve los recursos compartidos de semillas cifrados por las claves simétricas de estos canales seguros mutuamente autenticados, ni siquiera el Orchestrator.

¿Recibido de forma segura... y almacenado?

En esta parte, hemos introducido varios conceptos nuevos, algunos de los cuales son bastante técnicos. Cada uno de estos conceptos es requerido para establecer una transmisión segura que garantice la confidencialidad e integridad del intercambio. Independientemente de la seguridad de la red, ahora podemos enviar nuestras acciones secretas sin temor a que puedan ser manipuladas o interceptadas. ¡Esa es toda una mejora!

Todo el proceso está respaldado por criptografía sólida y hardware seguro, en forma de su dispositivo de hardware Ledger y HSM propiedad de cada proveedor de respaldo.

¡Ha llegado el momento de pasar a recuperar las acciones de semillas! Todo lo que tenemos que hacer es pedir a los proveedores de respaldo que nos devuelvan los recursos compartidos que están almacenando en su infraestructura…

Pero espera: ¿cómo exactamente almacenan estos datos tan confidenciales? No nos serviría de nada si tuviéramos los canales de comunicación más seguros, pero nuestros proveedores de respaldo simplemente guardaban las acciones en texto plano, rogando que se las robaran.

Entonces, antes de hablar de recuperación, ¡lo lograremos, lo prometo! –, tenemos que hacer un breve desvío en la Parte 3 para discutir la seguridad de nuestras acciones de semillas en reposo. ¡Manténganse al tanto!

Sello de tiempo:

Mas de Libro mayor