All Posts By

jinza

Auditoría de voto electrónico

By | Elecciones, Elections, Electronic Vote, Voto electrónico | No Comments


La Orden ICT/140/2019, de 14 de febrero, por la que se regulan las condiciones para el ejercicio del voto electrónico en el proceso electoral para la renovación de los plenos de las Cámaras Oficiales de Comercio, Industria, Servicios y Navegación prevé el despliegue de sistemas de voto electrónico que deberán ser auditables y auditados.

En su artículo 9 (Auditoría del sistema de voto electrónico.) indica:

1. El sistema de voto electrónico deberá contar con un régimen de auditoría y verificación totalmente independientes que permita examinar los procesos utilizados para reunir y contar los votos y recontar los mismos, a fin de confirmar la exactitud de los resultados.

2. El sistema de auditoría externo debe, como mínimo, permitir:

  1. Que los observadores independientes puedan supervisar las elecciones sin revelar el posible resultado o conteo final.
  2. Detectar el fraude electoral.
  3. Dar garantía de que todos los votos contados sean auténticos y mantener el anonimato del elector en todo momento.

3. Dicha auditoría deberá asistir tanto a la fase de pruebas del conjunto del sistema como a la fase de votación, recuento y difusión.

TCAB es una entidad de evaluación de conformidad pionera en prestar servicios de auditoría de plataformas de voto electrónico.

Imagen de una mano que sostiene una papeleta de voto y la acerca a un rdenador en el que pone el tecxto "voto electrónico"
Voto electrónico societario

Contacte con TCAB para solicitar la realización de auditorías previas de plataformas de voto electrónico y para asistir en los procesos electorales que hagan uso de este tipo de plataformas.

TCAB es una entidad experta en certificados y firma electrónica y puede valorar el cumplimiento de todos los aspectos que exige la normativa.

Contacte llamando al número 91 388 0789

TCAB participa en el evento sobre el Reglamento de Ciberseguridad organizado por AMETIC

By | Acreditación, AMETIC, Auditoría, Centro Criptológico Nacional, Cyber-security, Cybersecurity, ENISA, EU Cybersecurity | No Comments

AMETIC, la patronal de la industria digital en España, ha organizado una jornada informativa sobre el nuevo reglamento europeo “Cybersecurity Act”, que a partir de junio regulará la puesta en marcha de un marco común europeo para la certificación de productos y servicios TIC “ciberseguros”, que fomenten la ciberseguridad de los servicios en línea y los dispositivos de consumo.

Este reglamento europeo no solo busca aumentar la confianza de los usuarios en relación al uso de dispositivos conectados, sino también fortalecer la industria europea de ciberseguridad y el Mercado Único Europeo, posicionándola como referente a nivel mundial, en línea con otros mercados como Estados Unidos o China. La European Union Agency for Network and Information Security (ENISA), que a través de este reglamento será nombrada como nueva Agencia Europea para la Ciberseguridad, coordinará y armonizará las políticas a nivel europeo, y dará soporte a los Estados Miembros en la implementación de planes y estrategias nacionales en la lucha contra las amenazas y los ataques de seguridad cibernética.

Antonio Cimorra, director de Tecnologías de la Información y Agenda Digital de AMETIC, ha destacado durante la apertura de la jornada los avances que la transformación digital ha introducido en la sociedad, así como la importancia de garantizar la ciberseguridad. Asimismo, ha comentado las medidas que, desde AMETIC, y muy particularmente desde la Comisión de Ciberseguridad donde se dan cita importantes proveedores de esta tecnología, se están desarrollando en este ámbito. Cimorra ha resaltado también el apoyo de la asociación a la nueva iniciativa europea.

Posteriormente, Ignacio Pina, director Técnico de la Entidad Nacional de Acreditación (ENAC), ha explicado que, “si bien el reglamento no será de obligado cumplimiento en sus inicios, en lo que a certificación se refiere, será previsiblemente el propio mercado quien regule la necesidad o no del mismo”. Pina ha añadido que “la certificación en sí misma no genera seguridad, sino que lo que busca es generar confianza entre los consumidores”. En este sentido, ha comentado que “la transición entre los esquemas de certificación nacionales actuales en vigor y el nuevo marco común europeo será paulatina”. Por otro lado, ha subrayado que “el papel de la industria en la definición de los esquemas de certificación que deriven de este reglamento, es esencial para que éstos estén alineados con las necesidades de mercado”.

Implicaciones de “Cybersecurity Act”

A continuación, ha tenido lugar la mesa ronda ¿Cómo impacta Cybersecurity Act en las empresas del sector digital?, moderada por David González, presidente de la Comisión de Ciberseguridad de  AMETIC y Jefe de Ventas Europa y África del Norte de G&D. Los participantes, Mariano José Benito, CISO de GMV; Jesús María Alonso, Head of Consulting Spain de ATOS; Ainhoa Inza, CEO de TCAB (Trust Conformity Assessment Body), y Miguel Bañón, director general de EPOCHE & ESPRI, donde han debatido sobre las implicaciones del reglamento para la actividad de las empresas del sector digital, y los siguientes pasos para abordar este nuevo escenario.

En líneas generales, los participantes han comentado que se trata de una iniciativa muy positiva ya que a pesar de ser de momento un reglamento de carácter voluntario, se espera que su impacto en el mercado incremente el número de productos TIC seguros certificados de forma importante. Asimismo, han destacado que, para España, es una oportunidad de consolidación a nivel europeo en materia de ciberseguridad aprovechando que el ecosistema de certificación español se encuentra entre los mejor valorados de Europa.  

Por otro lado, se ha destacado que, al no existir por el momento un marco sancionador dentro del reglamento, es importante que las empresas detecten el beneficio que les aporta la certificación, como por ejemplo el impacto sobre el consumidor en términos de confianza. También han comentado que el objetivo de esta iniciativa es que el consumidor se “acostumbre” a comprobar que aquellos productos o servicios TIC que compre o consuma, lleven el sello de certificación de seguridad.

Por último, se ha contado con la presencia del representante experto del Centro Criptológico Nacional (CCN), entidad que actualmente coordina la labor de certificación en ciberseguridad a nivel nacional. CCN ha coincidido en la gran oportunidad que “Cybersecurity Act” supone para la industria de la ciberseguridad europea y española a la hora de posicionar a Europa en línea con otros mercados.

Elecciones AMETIC

By | AMETIC, Elecciones, Elections | 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.