All Posts By

jinza

Elecciones AMETIC

By | AMETIC | No Comments

AMETIC celebra su Asamblea General Electoral, el 7 de noviembre de 2018 en la  sala José María Cuevas de la CEOE C/ Diego de León, 50 CP. 28006 Madrid.

Trust Conformity Assessment Body presenta su candidatura para representar en la Junta Directiva de AMETIC al segmento de PYMES y MicroPYMES.

Trust Conformity Assessment Body es una pyme innovadora especialista en seguridad que audita sistemas de firma electrónica, blockchain y esquemas de seguridad e interoperabilidad y que está acreditada por ENAC para evaluar Prestadores de Servicios Electrónicos de Confianza cualificados en el marco del EIDAS (Reglamento UE 910/2014).

El amplio conocimiento de normas técnicas y jurídicas que poseemos suele ser de utilidad para nuestros clientes y pensamos que también puede serlo para la Junta Directiva de nuestra Asociación.

Al ser una PYME, conocemos los retos y dificultades de las empresas de este tamaño, y pensamos que podemos contribuir a sensibilizar a los órganos directivos de la asociación y sus interlocutores sobre la importancia de las PYMES en el tejido productivo del país y sobre las políticas necesarias para que estas empresas puedan desarrollarse y crecer de forma rentable.

Nos hemos permitido la libertad de plasmar nuestra candidatura en un pequeño video:

Candidatura de TCAB en las elecciones de AMETIC

Auditorías de seguridad para proyectos con Blockchain y SmartContracts

By | Auditoría, Blockchain, Conformity Assessment | No Comments

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.

Nuevos OIDs de ETSI para políticas de servicios de validación de firma

By | #eIdAS, eIDAS, Electronic Signatures, OID, Qualified electronic signatures Validation, Servicios de Confianza Digital, Trust Electronic Services, Trust Service Providers | No Comments

El borrador de la nueva norma  ETSI TS 119 441 propone nuevos OIDs de ETSI para políticas de validación de firma:

  • itu-t(0) identified-organization(4) etsi(0) VAL SERVICE-policies(9441) policy-identifiers(1) main (1)
  • itu – t(0) identified – organization(4) etsi(0) VAL SERVICE – policies( 9 441) policy – identifiers(1) qualified (2)
Es decir:
  • OID 0.4.0.9441.1.1 como el OID principal para servicios de validación de firmas electrónicas y sellos electrónicos, y
  • OID 0.4.0.9441.1.2 como el OID para servicios cualificados de validación de firmas electrónicas y sellos electrónicos talcomo se define en loas artículos 32 y 33 del Reglamento UE 910/2014 (EIDAS)

Artículo 32

Requisitos de la validación de las firmas electrónicas cualificadas

1.   El proceso de validación de una firma electrónica cualificada confirmará la validez de una firma electrónica cualificada siempre que:

a)

el certificado que respalda la firma fuera, en el momento de la firma, un certificado cualificado de firma electrónica que se ajusta al anexo I;

b)

el certificado cualificado fuera emitido por un prestador de servicios de confianza y fuera válido en el momento de la firma;

c)

los datos de validación de la firma corresponden a los datos proporcionados a la parte usuaria;

d)

el conjunto único de datos que representa al firmante en el certificado se facilite correctamente a la parte usuaria;

e)

en caso de que se utilice un seudónimo, la utilización del mismo se indique claramente a la parte usuaria en el momento de la firma;

f)

la firma electrónica se haya creado mediante un dispositivo cualificado de creación de firmas electrónicas;

g)

la integridad de los datos firmados no se haya visto comprometida;

h)

se hayan cumplido los requisitos previstos en el artículo 26, en el momento de la firma.

2.   El sistema utilizado para validar la firma electrónica cualificada ofrecerá a la parte usuaria el resultado correcto del proceso de validación y le permitirá detectar cualquier problema que afecte a la seguridad.

3.   La Comisión podrá, mediante actos de ejecución, establecer números de referencia de normas relativas a la validación de las firmas electrónicas cualificadas. Se presumirá el cumplimiento de los requisitos establecidos en el apartado 1 cuando la validación de una firma electrónica cualificada se ajuste a dichas normas. Estos actos de ejecución se adoptarán con arreglo al procedimiento de examen contemplado en el artículo 48, apartado 2.

Artículo 33

Servicio de validación cualificado de firmas electrónicas cualificadas

1.   Solo podrá prestar un servicio de validación cualificado de firmas electrónicas cualificadas el prestador cualificado de servicios de confianza que:

a)

realice la validación de conformidad con el artículo 32, apartado 1, y

b)

permita que las partes usuarias reciban el resultado del proceso de validación de una manera automatizada que sea fiable, eficiente e incluya la firma electrónica avanzada o el sello electrónico avanzado del prestador cualificado de servicio de validación.

2.   La Comisión podrá, mediante actos de ejecución, establecer números de referencia de normas relativas al servicio de validación cualificado a que se refiere el apartado 1. Se presumirá el cumplimiento de los requisitos establecidos en el apartado 1 cuando la validación de una firma electrónica cualificada se ajuste a dichas normas. Estos actos de ejecución se adoptarán con arreglo al procedimiento de examen contemplado en el artículo 48, apartado 2.