Ciberseguridad para aplicaciones basadas en infraestructura blockchain: problemas generales y soluciones específicas punto por punto

Ciberseguridad para aplicaciones basadas en infraestructura blockchain: problemas generales y soluciones específicas punto por punto
Mi nombre es Maxim Zavgorodny y trabajo en DataArt desde hace siete años. Los tres últimos, como arquitecto de soluciones. Mis intereses profesionales son ML/AI. Antes de eso, me desempeñé en el diseño y desarrollo de sistemas descentralizados basados ​​en blockchain, en donde estuve muy involucrado en temas de seguridad.

En este artículo, intentaré explicar los principios básicos que se deben seguir a la hora de diseñar una solución blockchain, deteniéndonos en ciertos puntos, como la creación de billeteras o la generación, almacenamiento y uso de claves. No vamos a analizar los matices técnicos de cada uno de ellos, sino más bien, serán puntos que se pueden usar como una lista para verificar el cumplimiento de las normas de seguridad de un proyecto.

Las soluciones basadas en blockchain se utilizan activamente en proyectos financieros, por ejemplo, en el diseño de sistemas de pago, intercambios y plataformas de negociación de criptomonedas. Pero también se pueden utilizar en seguros, salud y demás áreas de negocios. Al mismo tiempo, los clientes interesados ​​en utilizar esta tecnología relativamente nueva y popular, a menudo no son lo suficientemente conscientes de los problemas de seguridad que surgen en los proyectos de blockchain y por ello sus aplicaciones sufren vulnerabilidades con tanta frecuencia. Tan solo en 2019, más de 30 importantes plataformas fueron hackeadas.

La importancia de la ciberseguridad en los proyectos de criptomonedas es obvia. Pero, ¿qué pasa con las otras áreas? Son muchos los aspectos de la tecnología blockchain que requieren implementarse de acuerdo a altos estándares de seguridad, independientemente de la naturaleza del negocio del cliente: transacciones, certificados, creación y almacenamiento de claves privadas, etc. Estos aspectos en sí mismos siguen siendo exactamente los mismos en cualquier infraestructura de blockchain. La buena noticia es que las buenas prácticas financieras se pueden reproducir de forma segura en proyectos médicos, por ejemplo.

La forma más fácil y rápida de asegurar un proyecto de blockchain es utilizar bibliotecas de código abierto existentes (como bitcoinJ) o la integración RPC con productos, como Electrum o Geth. Esto nos permitirá manipular claves, transacciones, palabras semilla, etc. a través del RPC existente. De hecho, este enfoque puede justificarse en la etapa de prueba de concepto, cuando los plazos y el presupuesto suelen ser limitados. Pero no debe considerarse para el modo de producción.

Las bibliotecas y cualquier software para generar información criptográfica confidencial deben estar libres de funciones adicionales. Todos los programas utilizados para esto deben pasar con éxito las auditorías legales y de seguridad, y debe prohibirse cualquier transferencia de claves y palabras semilla generadas dentro del sistema. Además, vale la pena limitar la confianza en bibliotecas abiertas y servicios de terceros.

Esta es una lista de problemas sensibles a la seguridad que deben cubrirse al diseñar un sistema:

  • Generación de claves/palabras semilla
  • Creación de billeteras
  • Almacenamiento de claves
  • Uso de claves

Echemos un vistazo a lo que exigen exactamente los altos estándares de seguridad para cada uno de estos puntos.

1. Generación de claves y/o palabras semilla

Todas las semillas criptográficas y las claves de transacción deben generarse internamente. Dicha información es absolutamente confidencial y no debe transmitirse a terceros. Los algoritmos para generar claves y palabras semillas deben seguir reglas confidenciales e impredecibles.

1.1 Clave/semilla generada por el operador

La información criptográfica sensible como claves o palabras semilla debe ser generada por el operador responsable de la firma que confirma la transacción. Si estamos hablando de una aplicación descentralizada, como una billetera criptográfica, la clave y la semilla deben ser generadas por el usuario de la aplicación sin transferir estos datos confidenciales a nadie más.

En el caso de una aplicación centralizada, como billeteras online o bolsas de criptomonedas clásicas, el proceso de creación se realizará en estas plataformas. Se deben verificar las metodologías de generación para descartar el determinismo. La seguridad de los algoritmos para generar información criptográfica confidencial debe ser confirmada por auditores independientes.

La generación de palabras semilla debe realizarse en la zona desmilitarizada (DMZ) apropiada o sistema autónomo. Las copias de seguridad de los secretos criptográficos deben cifrarse y transferirse a un almacenamiento secreto a una persona de confianza para las copias de seguridad y las restauraciones.

1.2 Generador de Bits Aleatorios Determinista (DRBG)

Estamos buscando generar claves que deberían usarse con algoritmos criptográficos aprobados. Por ejemplo, la generación de números aleatorios verdaderos (TRNG), como los generadores de bits aleatorios deterministas (DRBG), se considera un estándar aceptado en la industria. Las claves se generan utilizando un procesamiento de salida matemático, utilizando generadores de bits aleatorios y parámetros adicionales. Para obtener más información, consultá las Pautas para Generar Claves Criptográficas (NIST Special Publication 800-133).

2. Creación de billeteras

La lógica de implementar una billetera o almacenamiento de claves privadas para trabajar con transacciones de blockchain debe cubrir un conjunto de cuestiones: administración de direcciones, uso de claves privadas para confirmar una operación e implementación de firmas múltiples.

Además, la billetera se puede implementar para cada cuenta individual. El método determinista permite crear un conjunto de direcciones/pares de claves en la forma de un grupo común de direcciones, a partir de una semilla maestra. Además, al implementar una billetera, debe prestar atención a varios riesgos, como la pérdida, el robo y el compromiso de las claves. La combinación de una billetera con la cuenta de un usuario específico debe ir acompañada de la introducción de niveles adicionales de identificación.

2.1 Implementación de una billetera determinista jerárquica (HD)

El valor de la semilla maestra se puede usar para crear un número suficiente de direcciones únicas vinculadas solo usando el algoritmo de generación, es decir, independientes entre sí para un observador externo. Cada dirección subsidiaria obtiene un lugar en la estructura bifurcada y se asocia con una ruta específica a través del árbol HD. Es importante que la implementación de la billetera HD cumpla con el estándar, es decir, BIP44.

2.2 Dirección única para cada transacción

Se debe generar una dirección única para cada transacción anónima.

2.3 Multifirma. Varias claves para firmar

Cualquier dirección que genere una billetera HD requiere al menos dos firmas para una transacción. Además, para proteger los fondos del usuario contra robos, es necesario colocar las claves en DMZ aisladas unas de otras.

2.4 Clave de recuperación de respaldo

Un método común es crear 2 de 3 posibles firmas para usar como entrada de una transacción.

2.5 Uso de billeteras HD

Todas las direcciones se asignan de forma determinista en función de las semillas, que deben ser privadas.

2.6 Backup de la billetera

Es imperativo crear regularmente copias de seguridad para cada nueva generación de claves y semilla maestra.

2.7 Cifrado de la billetera

Todos los datos de la billetera deben cifrarse mediante algoritmos seguros. Los datos de descifrado deben ubicarse en nodos separados con políticas de seguridad sólidas, por ejemplo, Identity service, Vault HashiCorp, etc.

Scheme

[Alta arquitectura de billetera de múltiples firmas, fig. 1.1]

3. Almacenamiento de claves

Cuando las claves no están en uso, deben almacenarse cifradas de forma segura. Además del cifrado en sí, es necesario prestar atención al almacenamiento separado de claves (deben colocarse en una infraestructura completamente independiente) y la seguridad física de los portadores de información cuando sea posible.

3.1 Las claves primarias se almacenan cifradas

Se debe utilizar un nivel de cifrado fuerte para almacenar claves y/o semillas. Por ejemplo, AES-256-CBC.

3.2 Ubicación de almacenamiento de claves

Las claves y/o semillas cifradas y las contraseñas cifradas deben almacenarse en todas las plataformas. Además, esta información debe estar físicamente espaciada entre diferentes ubicaciones y proveedores.

3.3 Backup de claves

Las claves/semillas deben tener una copia de seguridad (digital, hardware, papel, etc.).

3.4 Política de backup de claves

Las claves deben protegerse del riesgo de destrucción física, incluidos los desastres naturales y aquellos provocados por el hombre, como inundaciones, incendios, etc. Se deben almacenar copias de seguridad en ubicaciones geográficamente remotas del lugar de uso. Todas las copias de seguridad deben estar protegidas por controles de acceso.

4. Uso de claves

Todas las operaciones para interactuar con las semillas deben realizarse de forma segura. Es necesario excluir la posibilidad de copiar o cambiar las claves por programas maliciosos.

Las claves deben estar protegidas de usuarios sin escrúpulos que utilicen el acceso autorizado para transacciones no autorizadas. La implementación del mecanismo de descifrado y firma debe ser de varias capas y confiable.

4.1 Para generar claves, se recomienda utilizar la ruta "usuario / contraseña / factor n"

El acceso al uso de claves debe protegerse mediante un modelo de autenticación de múltiples factores. Por ejemplo, es posible que se requiera un identificador (puede ser un nombre de usuario, correo electrónico, etc.), tokens de Google Authenticator, firmas digitales de una clave privada y verificación de identificación personal.

4.2 Las claves solo se deben utilizar en un entorno de confianza

El uso de claves exclusivamente en un entorno DMZ confiable, reduce el riesgo de que un malware no autorizado copie, pegue copias y almacene claves. Este enfoque también protegerá contra intentos maliciosos de recuperación de claves y robo de datos confidenciales.

4.3 Verificaciones del registro de operaciones y referencias del operador

Es necesario realizar verificaciones de antecedentes de todos los empleados que acceden al sistema. Todas las acciones del operador deben registrarse y guardarse en logs.

4.4 Un dispositivo - una tecla

No se pueden almacenar dos claves de una billetera en el mismo dispositivo, cuyo acceso requiere varias firmas.

4.5 Autenticación multifactor

Las transacciones de firma deben estar protegidas por autenticación multifactor.

4.6 Auditor de operaciones

Para transacciones importantes, se debe agregar una capa adicional de autenticación con la aprobación obligatoria del administrador.

Scheme

[La secuencia para usar claves, fig. 1.2]

Hemos revisado las capas básicas necesarias para proteger de forma segura un sistema basado en una solución blockchain. Sin embargo, la implementación técnica no es suficiente para garantizar la seguridad.

Además, es necesario:

  • Capturar y documentar todas las operaciones de registro, auditorías del sistema, auditorías de seguridad, procedimientos y políticas para usuarios clave. Todas las operaciones y cambios en el sistema deben registrarse en los logs.
  • Proporcionar seguimiento del registro de transacciones y respaldo del registro.

Fuentes utilizadas en este artículo: