Según algunas estimaciones, las empresas de tecnología de blockchain pueden esperar volúmenes de negocio de 6 mil millones de euros en 2020. Sin embargo, antes deben lidiar con las vulnerabilidades de seguridad de blockchain, que, a pesar de su relevancia se siguen minusvalorando cuando se trata de la llamada tecnología de “contabilidad distribuida”.
Un inciso terminológico, para acotar el término “libro mayor distribuido” (distributed ledger technology, DLT) que cuenta con una traducción más afortunada como “contabilidad distribuida”. En mi opinión se ajusta más a la realidad el término “RJT Replicated Journal Technology” ya que el tipo de libro contable que registra los movimiientos en las blockchains es el llamado “libro diario”. Por ello, mi preferencia frente al término DLT es el de RJP Replicated Journal Paradigm o RJT Replicated Journal Technology
Vulnerabilidades de seguridad en cadenas de bloques
Algunos aspectos de la seguridad tienen que ver con el uso de la criptografía, y dado que en los contextos de cadenas de bloques se usa intensivamente la criptografía, existe la creencia generalizada de que los sistemas de blockchain, son seguros de por sí.
Sin embargo en sistemas complejos aparecen continuamente diferentes vectores de ataque que hay que identificar y remediar, por lo que el exceso de confianza en la tecnología puede ser peligroso.
De hecho, la tecnología denominada DLT está sujeta a una serie de problemas que las bases de datos centralizadas no tienen.
Los riesgos de seguridad de Blockchain existen, y deben ser reconocidos y mitigados para que blockchain cumpla su promesa de transformar la manera en que se almacenan los datos y cómo afectan a los proyectos que las usan.
A medida que más sectores gubernamentales, industriales y comerciales adoptan la tecnología, la necesidad de abordar estos problemas más pronto que tarde se convierte en primordial.
Vulnerabilidades de Blockchain
Vulnerabilidades del sistema de interfaz
Una de las vulnerabilidades más probables con DLT se origina fuera de la propia blockchain.
El sistema de interfaz es el equipo que un usuario emplea para acceder a servicios basado en blockchain.
En ese sistema se introducen las credenciales, motivo suficiente para atraer atacantes que aprovechen vulnerabilidades. Otras veces, manipular el “clipboard” la zona de memoria usada para las funciones de copiar y pegar puede permitir a un atacante cambiar la cuenta de destino de una transacción.
La detección de malware es una funcionalidad deseable en las herramientas que prevean minimizar los ataques a sistema de interfaz.
Seguridad de la criptografía de clave pública
Quienes proponen transacciones para que formen pare de la cadena (por ejemplo, transferencias de valor en el caso de los criptoactivos y criptomonedas) las firman con una clave privada y dan información sobre su clave pública. La clave privada se archiva con la cartera o mecanismo equivalente. La protección del equipo es de nuevo, esencial. Pero existen ciertos riesgos (por ejemplo, en base a la computación cuántica) que en el futuro podría permitir obtener la clave privada a partir de la pública. Para minimizar el riesgo, hay técnicas asociadas a carteras de un solo uso que se pueden adoptar.
Los backups de claves no se deberían conservar en el sistema que se usa a diario. Y aún menos sin cifrar.
Plataformas de terceros
Conforme se popularizan las cibermonedas y las aplicaciones que emplean tecnologías afines (como DLT) el mercado de soluciones de terceros experimentará crecimiento. Algunos posibles servicios a ofertar por terceros son:
- Plataformas de integración de Blockchain
- Procesadores de pago
- Carteras
- Entidades Fintech
- Plataformas de pago de criptomonedas
- Contratos inteligentes
Estas plataformas usan diferentes tecnologías vulnerables, además de las específicas de blockchain. Son verdaderos Prestadores de Servicios de Confianza Digital y deberían cumplir la norma EN 319 401 que el Reglamento EIDAS impone a los Prestadores Cualificados.
Control del paso a producción
Cuando se inicia un proyecto o se evoluciona dentro de el, deben realizarse pruebas exhaustivas para detectar vulnerabilidades en el código antes de su paso a entorno final de ejecución. Eso es de especial relevancia en los smartcontracts. En los smarcontracts se usan con frecuencia lenguajes como Solidity, con “defectos” similares a los de Javascript. Un caso de especial relevancia puede ser incluir entre comillas las direcciones de las carteras. De no hacerlo, las direcciones se truncan y los montos remitidos pueden acabar en un limbo irrecuperable.
Tamaño de la cadena de bloques
Dependiendo del tipo de criptoactivo y de como se ha diseñado su sistema de gestión de transacciones para su anotación en la cadena de bloques, puede ser que sea necesario conservar toda la cadena de bloques desde sus orígenes. Algunas variantes permiten convertir el histórico de transacciones en una “foto de estado” a partir de la cual puede desecharse el histórico anterior. Sea como sea, cuantas más transacciones se hacen más crece la cadena, lo que puede crear problemas de dimensionamiento en los equipos en los que se gestionan.
Ataques del 51%
Algunos sistemas de criptoactivos con diferentes filosofías de confirmación de bloques (PoW, Proof of Work, PoS, Proof of Stake, …) podrían atacarse por colectivos que que superen el 51% de participación en el mecanismo de consenso. Por tanto convendría prever si es necesario contar con mecanismos de reversión, y la responsabilidad de ejecución de tales mecanismos.
Se han dado casos reales de este tipo de ataque sobre mecanismo Pow (teórico hasta hace poco tiempo) que se entiende sabiendo que un gran número de centros de acumulación de equipamiento de minería se construyen en países donde la energía eléctrica es barata y la supervisión escasa
Falta de madurez de la tecnología
En todas las tecnologías se aprenden lecciones esenciales conforme se adoptan y se generalizan. Se descubren problemas y se reselven. La tecnología blockchain todavía está en los estadios iniciales de desarrollo y no se comprenden todos los riesgos y sus efectos.
Riesgos por normalización insuficiente
Muchos de los sistemas de blockchain se despliegan con un “Whitepaper” y código fuente del proyecto disponible en Github. Aunque es un ejercicio de transparencia, a menudo se revela que los promotores de tales proyectos tienen escaso interés en conocer los estándares o en adoptarlos.
Es particularmente llamativo en el ámbito de la firma electrónica, cuyo mercado principal ha madurado a lo largo de los años dando lugar a diversas leyes y normas técnicas que crean presunciones legales a quienes adoptan la tecnología y que define los estándares que facilitan su interoperabilidad.
En cambio, el uso de la tecnología de firma electrónica en los proyectos de blockchain parece provenir de alumnos de grado que han leído lo básico de la teoría de firma electrónica y que ignoran el avance de los estándares. Parecen ejercicios académicos, en vez de responder exigencias de un mercado que impone que los sistemas puedan interoperar y que sus desarrolladores conozcan las leyes y los estándares.
Afortunadamente UNE e ISO (entre otros organismos de estandarización) están comenzando a proponer estándares para el mundo de blockchain, que no deberían soslayar los avances producidos en las tecnologías comunes con cierto nivel de madurez.
Cabe recordar que la estandarización, contra lo que afirman sus críticos, no cercena la innovación sino que abre nuevas posibilidades para ella. Y deja resueltos problemas que se acometieron en el pasado minimizando el riego a reinventar a rueda cada vez.
Vulnerabilidades sutiles
Existen vulnerabilidades difíciles de detectar que se hacen visibles tras incidentes de cierta magnitud. Conviene prever mecanismos de reversión antes del despliegue para poder gestionar los problemas que no se han podido identificar con anterioridad.
Un ejemplo nos lo enseña el caso de “The DAO”
Una”DAO” (Distributed autonomous organization) es una Organización Autónoma Descentralizada construida en algunos tipos de blockchain, con funcionalidad de ejecución de código para contratos inteligentes asociados a inversiones en el capital de empresas marcadamente digitales. Se podría decir que un DAO es un fondo de capital riesgo de crowdsourcing que se gestiona en base a smartcontracts embebidos en una cadena de bloques. Hay muchos DAO, cada uno creado para alojar y ejecutar contratos inteligentes para organizaciones específicas.
Uno de esos DAO, conocido como “The DAO”, fue fundado en 2016 por miembros del equipo de Ethereum. Durante su período de creación, The DAO hizo historia en el ámbito del crowdfunding recaudando 150 millones de dólares. Poco después, The DAO hizo historia, una vez más, al ser el primer DAO en ser pirateado.
Durante el crowdsale, muchos miembros de la comunidad de Ethereum expresaron su preocupación de que el código DAO fuera susceptible de ser atacado. Posteriormente, un miembro del equipo de la DAO encontró un “error recursivo” pero erróneamente creyó que no había fondos de la DAO en riesgo. Un hacker demostró que estaba equivocado.
El ataque se produjo cuando el atacante explotó dos vulnerabilidades en el código DAO. El hacker sabía que el código estaba diseñado para permitir tanto una división como una transferencia de tokens entre cuentas. El hacker también se dio cuenta de que el código no actualizaría los saldos de las cuentas lo suficientemente rápido como para evitar la transferencia de los mismos tokens más de una vez.
El hacker ejecutó una función de escisión, creando una cuenta “child DAO” y realizó repetidas solicitudes de transferencia desde su primera cuenta en rápida sucesión. Como el código no disminuía los saldos de cuenta originales después de cada transferencia, no había nada que impidiera que los mismos tokens se repitieran unas 40 veces cada uno, sin que se destruyeran los tokens originales.
Después de transferir $ 55 millones en Ether, el hacker dio por terminado el ataque y algunos hechos adicionales se sucedieron, por lo que invito a investigar sobre este asunto del que se extraen grandes eseñanzas.
A quien acudir.
Cuando se plantean proyectos serios de blockchain, sus impulsores invierten en los desarrolladres de tecnología que ayudan a definir los tipos de transacción, los modelos de gestión de identidad, los mecanismos de confirmación de bloques, los ritmos de producción de bloques y el límite de transacciones por bloque. Hay muchos aspectos que hacen diferencial cada proyecto.
Uno de que deberá empezar a tenerse en cuenta es el de la auditoría de proyecto. Quizá no detecte todos los problemas, pero descubrirá los principales. hay que empezar a poner en valor lo que ya se conoce y evitar cometer errores que ya se cometieron.
Contacte con Trust Conformity Assessment Body (TCAB) si necesita auditar un proyecto de blockchain.
AMETIC celebra su Asamblea General Electoral, el 4 de noviembre de 2021 en la sala José María Cuevas de la CEOE C/ Diego de León, 50 CP. 28006 Madrid.
English