La expedición de certificados académicos: un caso de uso donde Blockchain sí tiene sentido

lunes, 15 de enero de 2018

¿Eres Blockchain lover o definitivamente crees que aporta poco? Innumerables empresas tecnológicas están sacando al mercado proyectos alrededor de Blockchain, en ocasiones, explotando alguna de sus fortalezas y en otras no tanto. Lo que sí es cierto es que poco a poco van surgiendo proyectos de software libre con los que poder jugar y aprender de la tecnología.

Uno con el que hemos estado trasteando recientemente ha sido BlockCerts, un estándar para crear, emitir, visualizar y verificar certificados utilizando la cadena de bloques de Bitcoin o de Ethereum. El objetivo de este proyecto es que ciertos organismos o individuos lleguen a ver útil dejar un registro de dicho certificado, firmado criptográficamente, para que luego pudiera ser validado por un tercero.

Redefiniendo el sistema de certificados 
Imaginemos que ElevenPaths impartiera formación sobre seguridad y quisiéramos crear un certificado académico que fuera verificable por los departamentos de recursos humanos de diferentes empresas. Para ello nuestra empresa tendría que anclar en la cadena bloques un hash de cada certificado emitido para cada uno de los alumnos. La solución inmediata sería emitir una transacción que incluyera en el campo OP_RETURN la prueba de que eso ha ocurrido como hacen proyectos como Proof of Existence. Sin embargo, esta aproximación no es óptima y es costosa cuando existen muchos alumnos a certificar, teniendo en cuenta los elevados precios por transacción en Bitcoin o Ethereum.  

Para evitar este problema, Blockcerts utiliza una solución más eficiente apoyándose en los árboles de Merkle (Merkle trees, en inglés) usando únicamente una transacción para emitir un conjunto de certificados. Es decir, el emisor crea un árbol de Merkle y registra el hash de todos los certificados en el campo OP_RETURN en una misma transacción de Bitcoin. Estas estructuras tienen la particularidad que dado cualquiera de los fichero origen y la ruta hasta el "hash raíz" se puede verificar que ese fichero ha sido utilizado para generar el árbol.  

Figura 1. Estructura de un merkle tree para la verificación de un certificado (Fuente: blockcerts.org).


¿Qué partes tendría nuestro proyecto?
Para ello, tendríamos que seguir el siguiente proceso del proyecto:
  • Cert-tools. Con esta herramienta podríamos generar la entidad certificadora, la plantilla de los certificados que se expedirán a los alumnos y los certificados sin firmar para cada uno de los alumnos que han superado el curso. En un fichero de configuración como en el del ejemplo estableceremos algunos datos propios del certificado, como el logo, la firma o la dirección pública de Bitcoin que los emitirá: mkZTu3fwXAXW4JUDPFkqqNKMMNvLLJJZmc. 

Figura 2. Fichero sobre la entidad certificadora.


  • Cert-issuer. En este paso, firmaríamos los certificados y se pushearían a la blockchain de Bitcoin. El fichero de configuración es todavía más sencillo que el anterior. En él tendríamos que añadir las rutas donde se encuentran los certificados generados en el paso anterior aún sin firmar. Además, tendríamos que indicar la ruta al fichero donde tendremos la clave privada de la dirección emisora. Es importante saber que cualquier persona que tuviera acceso a dicha clave podría emitir certificados en nombre de cualquiera. 

Fichero 3. Fichero de configuración de la aplicación emisora de los certificados que se publicarán en la blockchain de Bitcoin.


  • Cert-verifier. Se trata de una librería en Python que un tercero puede utilizar para verificar si el certificado que ha sido presentado por el alumno, ha sido realmente emitido por la entidad certificadora. Además de encontrarse en Python, también existe una implementación de la librería en Javascript, así como aplicaciones para Android y IOS. 

Figura 4. Captura sobre la validación de un certificado utilizando un merkle tree.


  • Cert-viewer. Contiene un pequeño servidor web de Flask que presenta una interfaz para realizar la verificación desde el navegador. De esta manera, si el alumno hubiera modificado un solo carácter del certificado de otra persona (incluso aunque fuera para corregir un error ortográfico por ejemplo), la comprobación de la validez del certificado fallaría en el primer paso poniendo sobre aviso a quien lo compruebe. Como se puede observar, la transacción de la cadena de bloques de Bitcoin sobre la que se hace la comprobación tiene el mismo txid para los dos certificados, en nuestro caso: 6091fff8d8d81fcf043242ed24b38133d0e6004c368d9f316d5404eb34cb6394. Así, conseguimos ahorrar de forma efectiva un montón de gastos en concepto de comisiones.

Figura 5. Visualización de dos certificados emitidos con Blockcerts desde la interfaz web que facilita cert-viewer.

Al margen de utilizar el campo OP_RETURN como hemos visto en este post para anclar la existencia de múltiples certificaciones, hace unos meses, en el blog de ElevenPaths publicamos otro post donde comentábamos que este campo podría utilizarse en el futuro para usos potencialmente maliciosos aprovechando la persistencia de redes como la de Bitcoin. A nosotros se nos ocurrió utilizarlo como C&C, pero seguro que no es la única. ¿Se te ocurre alguna a ti?

Félix Brezo
Equipo de Innovación y Laboratorio de ElevenPaths
Yaiza Rubio
Equipo de Innovación y Laboratorio de ElevenPaths

2 comentarios:

  1. Muy interesante esta idea. blockcerts está facilitando este tipo de usos. Y por supuesto blockchain si! Y si es para certificar a largo plazo, la blockchain de bitcoin es un must.

    Saludos!

    ResponderEliminar
  2. Cada empresa que quisiera comprobar un certificado debería convertirse en un nodo, o depender de un tercero (blockchain.info)

    No es más sencillo y eficiente simplemente firmar digitalmente los certificados con las claves privadas de las entidades emisoras?
    Esto obligaría a estas entidades a cierto mantenimiento de las claves privadas, pero es su negocio.

    ResponderEliminar