Blockchain para registro de evidencias digitales
Crear cuenta

# Blockchain para creación de un portafolio de registros de evidencias digitales para el intercambio electrónico de datos ( Ref: RFC 4998 - Evidence Record Syntax "ERS")

Publicado el 4 de octubre de 2018

## INTRODUCCIÓN

El intercambio electrónico de datos (en inglés Electronic Data Interchange o EDI) es la transmisión estructurada de datos entre 2 organizaciones por medios electrónicos. Se usa para transferir documentos electrónicos o datos de negocios de un sistema computacional a otro. Este intercambio puede realizarse en distintos formatos: JSON, EDIFACT, XML, ANSI ASC X12, TXT, etc.

Consultas, transferencia de propiedad, facturas, órdenes de compra y otros documentos comerciales electrónicos pueden tramitarse directamente desde la computadora o servidor de la empresa emisora al servidor o computadora de la empresa receptora, con gran ahorro de tiempo y evitando muchos errores, propios de la comunicación tradicional «en papel».

EDIFACT es un estándar de la Organización de las Naciones Unidas para el intercambio de documentos comerciales en el ámbito mundial. Existiendo subestándares para cada entorno de negocio (distribución, automoción, transporte, aduanero, etc) o para cada país. Así, por ejemplo, AECOC regula el estándar EDI del sector de distribución. Para el intercambio de este tipo de información se suelen utilizar las redes de valor añadido. Además del intercambio de la información, estas redes permiten su registro.

## ACTORES

En el proceso de Intercambio electrónico de datos se cuentan con los siguientes actores:

Diagrama 1.0 - Arquitectura de referencia para autenticar transacciones

### Emisor

Entidad que envía una secuencia de datos a un receptor.

### Emisor

Entidad que recibe la secuencia de datos que ha sido enviada por el emisor.

### Testigo digital

Persona natural o jurídica que permite validar que la transacción ha sido enviada satisfactoriamente al receptor y que ha sido recibida correctamente.

## EL PROBLEMA

Desde la implementación de los proyectos de intercambio de datos ha sido un reto para la comunidad de sistema, el lograr garantizar a las partes involucradas que las transacciones se han realizado correctamente y que no haya sido alterado la información durante la transferencia y/o evitar el repudio de alguna de las partes.

### Repudio en la consulta

Este conflicto se da cuando una organización consume los servicios web de otra organización, obteniendo una respuesta determinada y luego de un tiempo se realiza la misma consulta y se obtiene una respuesta diferente, no pudiendo tener evidencias que en el momento que se realizó la primera consulta el servidor del emisor le había mostrado una respuesta distinta a la mostrada en este momento, pudiendo ocasionar problemas legales, pérdida de confianza al sistema de intercambio de datos o altos costos comercial por realizar procesos duplicados, veamos el siguiente ejemplo:

### Organización Emisora

Emite antecedentes comerciales de una persona cuando se envía el número de documento de identificación nacional.

`Servicio web: http://q.emisor.com/query?id={numeroDocumento}`

### Organización Receptora

Consulta al emisor si un determinado ciudadano no presenta malos antecedentes comerciales con la finalidad de aprobar una línea de crédito.

`POST http://q.emisor.com/query?id=10102020`

### Puntos vulnerables

- ¿Cómo podemos comprobar con certeza que el funcionario responsable de realizar la consulta antes de aprobar la línea de crédito, realmente realizo la consulta y fue positiva?
- Qué pasaría si el emisor dio una respuesta favorable, el receptor aprueba la línea de crédito y en un proceso de auditoria posterior, se vuelve a consultar en la entidad emisora y se obtiene una respuesta diferente, ¿Cómo puede el funcionario del receptor demostrar su inocencia?

## LA SOLUCIÓN

Hace muchos años ha existido el reto para muchas organizaciones de conseguir un método o mecanismo que ayude a validar la originalidad y autenticidad de una transacción.

Nuestra solución consiste en generar un tercero de confianza, seguro, incorruptible y democratizado que permita dar fe que un hecho ha sido realizado en un momento del tiempo, facilitando al beneficiario el proceso de validación de integridad y originalidad de la transacción.

### Arquitectura de referencia de stamping.io

El siguiente diagrama muestra la arquitectura lógica de stamping.io para validar un documento:

Diagrama 2.0 - Arquitectura lógica para autenticar transacciones

Cuando el emisor de la transacción recibe una consulta del receptor, antes de responder deberá calcular un resumen criptográfico (Hash de tipo SHA-256) tanto de la consulta como la respuesta, por ejemplo:

`• Input: { “id”: ”1020304050” } // Enviado por el Receptor • Output: { “code”: “200”, “message”: “Ok”, “data”:{ “id”: 2839948, “type”: “C01”, “status”: “Active”, } } // Enviado por el emisor`

#### Calculado el hash (SHA256)

`CalculateHash256(“{"id":"1020304050"}{"code":"200","message":"Ok","data":{"id":2839948,"type":"C01","status":"Active"}}”)`

Beneficiario

Valor:

2762393299fb79cb79298a003f815be755ceacfa76d501fe2ef850d946e0df92

El resumen criptográfico 2762393299fb79cb79298a003f815be755ceacfa76d501fe2ef850d946e0df92 representa a la consulta y respuesta, cualquier modificación, por mínima que sea, el resultado del cálculo del hash será diferente, este valor es enviado por el emisor a stamping.io para que sea anclado en el Blockchain convirtiéndose en una evidencia digital certera de la consulta y respuesta emitida.

Stamping.io, envía esta respuesta al servicio web (Webhook - Received) que el receptor ha registrado en su data wallet, los datos enviados son el hash generado, los datos encriptados o un identificador que el receptor utilizará con la finalidad de validar que el hash este correctamente calculado, posteriormente genera otro hash que representa su conformidad o repudio y este es nuevamente enviado a stamping.io para que sea anclado al Blockchain y posteriormente notificado al emisor utilizando el servicio web (Webhook - Received) que el emisor registro en su data wallet.

Cada 30 minutos una autoridad de sellado de tiempo (TSA) firma digitalmente un certificado en pdf donde incluye todos los hash y data encriptada recibida, generando una prueba fehaciente de la existencia de esa secuencia de datos en un momento del tiempo.

Esta arquitectura ha sido validada, al ser stamping.io un tercero de confianza resuelve todos los puntos vulnerables descritos anteriormente, incrementando la confianza en el proceso de intercambio de datos entre el emisor y el receptor.

### ¿Stamping.io almacena mis datos?

No, lo único que almacenamos son resumes criptográficos (Hash) como evidencias digitales de una transacción o evento.

## TECNOLOGIA

La tecnología utilizada en stamping.io es la siguiente:

- Hash SHA256: Algoritmo de resumen criptográfico que la utilizamos como una huella digital y que ayuda a identificar al documento, este algoritmo alerta cualquier cambio por menor que sea en el documento original.
- Database Realtime: Base de datos que permite registrar los datos de búsqueda antes de ser anclados y endosados en los Blockchain que conformar la red de stamping.io, esta base de datos puede ser consultada por los beneficiarios, usuarios y emisores en tiempo real.
- Blockchain: Registro descentralizado, seguro y confidencial que registrar las evidencias legales en miles de nodos alrededor del mundo, evitando que puedan ser alterados, nuestra plataforma ancla las evidencias en el Blockchain de Bitcoin, Ethereum y en la red privada que se está formado con cada emisor de documentos basada en la plataforma de Blockchain de Hyperledger Fabric.
- TSA: Autoridad de sellado de tiempo, que son regulados por la ley de firmas digitales, quien cada 30 minutos registran las transacciones en un documento dando fe que esos documentos o transacciones se realizaron en un momento del tiempo, la fecha del documento (timestamp) es reconocida legalmente por los tribunales como una fecha certera, de acuerdo a la ley de firmas digitales de cada país, por lo general es de carácter “no repudiable” .
- Arbol de Merkle: Es una estructura de datos en árbol, binario o no, en el que cada nodo que no es una hoja está etiquetado con el hash de la concatenación de las etiquetas o valores (para nodos hoja) de sus nodos hijo. Son una generalización de las listas hash y las cadenas hash. .

#### Vea tambien

- http://www.stamping.io/docs/evitar_falsificacion_adulteracion_documentos_legales.html

#### Información relacionadas

- Usarán Manual de evidencia digital - El fiscal de la Nación, Pablo Sánchez Velarde, recibió el Manual de evidencia digital
- Propuesta de Protocolo para la Recolección de Evidencias Digitales Relacionado con la Legislación Peruana - Evelyn Salas Ordinola, Alan Ramírez García y Oscar Núñez Mori
- Firmas hash y cadena de custodia
- PRESTADOR DE SERVICIOS DE VALOR AÑADIDO PARA EL ESTADO PERUANO
- Guía de Acreditación de Entidad de Registro o Verificación

##### CITAS Y REFERENCIAS

`[1] Listas negras: Personas insolventes, Morosos, etc. [2] https://es.wikipedia.org/wiki/Documento_legal [3] Extraída de https://www.quiminet.com/articulos/impida-falsificaciones-y-proteja-sus-documentos-importantes-3364271.htm [4] https://es.wikipedia.org/wiki/Web_spoofing [5] Basado en http://www.enciclopedia-juridica.biz14.com/d/falsificaci%C3%B3n-y-adulteraci%C3%B3n-de-documentos/falsificaci%C3%B3n-y-adulteraci%C3%B3n-de-documentos.htm [6] Extraído de Análisis de la estructura lógica del delito de falsificación de documentos de Segundo Félix Quesquén Ríos. [7] Extraído de Análisis de la estructura lógica del delito de falsificación de documentos de Segundo Félix Quesquén Ríos. [8] Ver sección de actores, Beneficiario es el interesado en validar la autenticidad del documento. [9] Integridad: Que el documento no haya sido adulterado [10] Originalidad: Que el documento no se falso es decir sea original. [11] Para mayor información ver sección de tecnología [12] Para entender por qué se utiliza esta forma de validar vea sección de putos vulnerables [13] Para mayor información ver sección de tecnología [14] Recuerde que Stamping.io no cuenta con los datos ni copia del documento. [15] Se refiere a un estado de negocios donde el supuesto autor de una declaración no es capaz de desafiar con éxito la validez de declaración o contrato. El término es a menudo visto en un entorno legal donde la autenticidad de una firma está siendo desafiada. En tal la autenticidad se está "repudiando". [16] Extraído de https://es.wikipedia.org/wiki/%C3%81rbol_de_Merkle`
Powered by stamping.io

Todos los derechos reservados.