ES2907398T3

ES2907398T3 - Validación de la integridad de los datos

Info

Publication number: ES2907398T3
Application number: ES17715988T
Authority: ES
Inventors: Michael Stuart Jacobs; James Zorab
Original assignee: Ascent Group Ltd
Current assignee: Ascent Group Ltd
Priority date: 2016-03-30
Filing date: 2017-03-30
Publication date: 2022-04-25
Anticipated expiration: 2037-03-30
Also published as: AU2017243206A1; US11658831B2; CN109154971A; AU2017243206B2; GB2548851B; US20190103975A1; GB201605343D0; WO2017168159A1; GB2548851A; EP3437013B1; EP3437013A1; CN109154971B

Abstract

Un método implementado por ordenador para permitir la validación de la integridad de los datos por referencia a una pluralidad de elementos de datos únicos, denominados HASH_LINKED, almacenados en una cadena de hash en al menos un dispositivo informático, en donde la cadena de hash se produce por las siguientes etapas: (a) combinar al menos un HASH_LINKED ya registrado en dicha cadena de hash con una fuente de datos recién añadida y hacer hash a la combinación resultante para producir un nuevo hash, HASH-SALTED; (b) almacenar el HASH_SALTED en un campo dentro de un nuevo registro en un almacén de datos digitales en el al menos un dispositivo informático, en donde el almacén de datos digitales es una tabla dentro de una base de datos; y (c) combinar, en un nuevo registro, cada nuevo HASH_SALTED con el HASH_LINKED más reciente y hacer hash a la combinación para producir un HASH_LINKED adicional almacenado en otro campo en el mismo nuevo registro, de modo que el HASH_SALTED más reciente y el HASH_LINKED adicional estén permanentemente vinculados por posición en la base de datos; y las etapas (a) a (c) que se repiten en múltiples iteraciones, en donde después de cada repetición de la etapa (a), cada HASH_LINKED más reciente se combina con el siguiente HASH_SALTED y se hace hash para producir un HASH_LINKED siguiente almacenado en el mismo nuevo registro.

Description

DESCRIPCIÓN

Validación de la integridad de los datos

La presente invención se refiere a métodos y aparatos para validar la integridad de los datos usando una cadena de hash tanto para afirmar la integridad de elementos de datos individuales como para proteger la integridad interna de la cadena de hash.

Existen muchas circunstancias en las que es deseable validar la integridad de los datos que pueden estar contenidos, por ejemplo, en un documento u otro archivo que se intercambiará entre las partes o se publicará. Con frecuencia es importante que tales datos sean confiables cuando se intercambian o publican - por lo que se han empleado durante varios años diversas técnicas para validar la integridad de los datos (a veces denominadas "autenticación").

En las técnicas convencionales para validar la integridad de los datos, se sabe que se producen cadenas de hash que consisten en una serie de hashes, derivados de los datos de la fuente y cada una creada concatenando el hash creado más recientemente en la cadena con un hash de la fuente recién enviado, y luego hacer hash al resultado - que luego se convierte en el nuevo "hash más reciente (o último) en la cadena".

Tal concatenación simple generalmente es útil solo para una organización que tiene acceso a cada documento o elemento de datos cuyo hash ha contribuido a la cadena. La organización podría usar la cadena para confirmar que cada uno de tales documentos ha conservado su integridad (o, como alternativa, que algo ha cambiado). Además, si faltaban datos en el medio de la cadena o se habían modificado de forma ilícita, el resto de la cadena no podía reconstruirse, a menos que se hubiera mantenido un registro separado de los hashes de la fuente individuales originales en otro lugar, haciendo que la protección desde ese punto de modificación ilícita fuera nula y sin efecto.

Para crear una tabla hash mayor utilidad, el documento EP1678666B1 describe un sistema en el que los hashes de la fuente individuales se pueden buscar públicamente y la tabla está protegida por una amplia distribución de sus hashes de final del día en un diario de registro acreditado. El uso de este sistema significa que cualquier tercero podría verificar los datos simplemente confirmando que su hash existía en la base de datos central y confirmando que los datos del día coincidían con su hash impreso. También significa que un intento de alterar un hash que se haya registrado antes de la publicación impresa sería detectable porque la verificación fallaría.

El documento EP1678666B1 describe con más detalle un método (implementado por ordenador) para permitir la autenticación de datos, que comprende las etapas de: almacenar copias de una pluralidad de elementos de datos, generar al final de un período de tiempo predeterminado un primer archivo de datos que comprende un valor hash respectivo de cada uno de la pluralidad de elementos de datos almacenados, y generar un valor hash único del primer archivo de datos derivado de dichos valores hash de la pluralidad de elementos de datos almacenados, y luego transmitir el valor hash único a una ubicación remota, a través de una red de comunicaciones de tecnología de la información; crear en la ubicación remota un segundo archivo de datos que comprenda el valor hash único y uno o más elementos de datos adicionales relacionados con el valor hash único, y publicar el segundo archivo de datos en un diario acreditado (o diario de registro), el segundo archivo de datos publicado que es tal que permita la regeneración del valor hash único del primer archivo de datos y la reconversión al segundo archivo de datos para compararlo con el segundo archivo de datos creado anteriormente.

En el método conocido que se acaba de describir, para un período de auditoría dado, se produce un lote de valores hash de cada uno de un lote de datos y se genera un único valor hash basado en ese lote de valores hash. El valor hash único se transmite a un receptor donde se produce un archivo de datos para el período de auditoría fechada, el archivo de datos que comprende el valor hash único y uno o más elementos de datos adicionales relacionados con el valor hash único. Luego, se genera un valor hash de identificación para ese archivo de datos, publicándose el valor hash de identificación en un diario fechado que permite así autenticar la fecha del archivo de datos en una fecha posterior.

Un método de autenticación de este tipo está disponible comercialmente, como se describe, por ejemplo, en el sitio web www.codelmark.co.uk/about. Los servicios disponibles a través de ese sitio web bajo el nombre CODEL (CODEL es una marca comercial registrada) permiten a un autor generar una "huella digital" única de los datos que genera el autor, en la que se genera un valor hash a partir de los datos (el valor hash generado que es único para esos datos), y ese valor hash se almacena en una base de datos donde puede acceder una persona que desee validar los datos, ya sea antes o después de leerlos.

El proceso de generación del valor hash puede considerarse inestable, en el sentido de que incluso un pequeño cambio en los datos genera inevitablemente un cambio (significativo) en el valor hash. Esto significa que el valor hash se puede usar para verificar la integridad de los datos en un momento específico; incluso la adición de simplemente un pequeño cambio a los datos, como un punto o una coma en un documento, puede generar un gran cambio en el valor hash resultante.

La manipulación de los datos generados puede ser atractiva para ciertas partes y, por lo tanto, la manipulación de los valores hash también sería atractiva, porque es el valor hash el que se puede usar para afirmar la integridad de los datos en caso de que un tercero intente "modificar" esos datos y su hash relacionado.

Cuando se intercambian datos entre partes para, por ejemplo, publicar esos datos en línea o distribuir esos datos a un público más amplio, el autor o productor de los datos puede elegir registrar esos datos con el servicio "Codel" descrito anteriormente para generar un valor hash para los datos que los lectores pueden usar para validar tanto la integridad de los datos como el momento en que se registraron con ese valor hash.

La confianza en un valor hash de este tipo, como prueba de integridad, significa que cualquier intento ilícito de modificar la fuente de datos relevante debe ir acompañado de un intento de modificar su valor hash registrado, para sustentar cualquier engaño. Esto implica un ataque a la base de datos central. Es posible que un ataque de este tipo tenga éxito durante el período siguiente a la publicación del hash del final del día más reciente. Todos los registros creados entre ese punto y la siguiente publicación podrían, potencialmente, ser alterados por un atacante que controle la base de datos, sin ser detectados. El período desde el registro de cualquier hash dado y el punto en el que se puede confiar en él se denomina, en el campo, Latencia de verificación. Solo después de que se imprima el hash del final del día en un diario acreditado, se puede confiar en los registros registrados durante ese día de manera segura.

A raíz de ello, uno de los problemas de las configuraciones actuales, tal como el problema descrito en el mencionado documento EP1678666B1, es que es muy difícil decir si un servidor en el que se están registrando hashes está siendo atacado entre publicaciones impresas. Debido a esta dificultad, los usuarios de un servidor pueden continuar registrando nuevos hashes con un servidor, sin saber que se ha visto comprometido. Los ataques al servidor pueden buscar realizar modificaciones o retracciones no autorizadas de los datos registrados. Por lo tanto, es muy deseable identificar los ataques en curso lo antes posible.

Otro problema con el sistema descrito en el mencionado documento EP1678666B1 es que la acción de confirmar que los datos de un día coinciden con su hash impreso en el diario acreditado (o diario de registro) no es un procedimiento trivial.

Esta confirmación es esencial para la validación formal completa para probar que la propia base de datos en sí no ha sido modificada. Esto se logra formalmente, en el diseño original, obteniendo una copia de todos los datos de un día dado y confirmando que, cuando se aplica hash a la recopilación, con o sin cadena, el resultado coincide con la copia en el diario de registro. Sin embargo, la mayoría de las partes que buscan la validación ni siquiera consideran validar la tabla de host por sí mismos y, en cambio, confían en que los hosts de la base de datos lleven a cabo tales verificaciones en el servidor host en su nombre. Pero esta confianza no tiene en cuenta la posibilidad de que los posibles atacantes hayan obtenido un control ilícito o no autorizado del servidor host, o incluso que los propios hosts se hayan corrompido.

Además, puede haber obstáculos prácticos para el uso del método de validación conocido, particularmente para datos más antiguos, ya que el proceso de recopilación de datos y la búsqueda de copias de la publicación impresa relevante del diario de registro podría llevar días o semanas - y aunque una modificación eventualmente acabara siendo descubierta, el atacante podría haberse ido hace mucho tiempo con las ganancias de su engaño.

Por lo tanto, el propósito principal de la presente invención es reducir la ventana de oportunidad para tales ataques en la cadena creciente garantizando la detección, típicamente en unos pocos segundos, y hacer posible realizar la verificación completa de cualquier elemento en la base de datos, independientemente de su antigüedad, típicamente en un minuto más o menos.

Esto reduce significativamente la ventana de oportunidad para un atacante y hace posible que un ataque tenga éxito solo si el ataque se puede completar en muy poco tiempo y solo si durante ese poco tiempo el atacante puede bloquear todos los intentos de añadir nuevos registros a la cadena desde fuentes que no están bajo el control del atacante. Tal bloqueo interrumpiría inevitablemente el servicio normal, lo que haría que el ataque fuera muy visible.

La presente invención, como el método descrito en el mencionado documento EP1678666B1, proporciona un método y un sistema implementado por ordenador para permitir la validación de la integridad de los datos.

La solicitud de patente EP 2897 051 A2 describe un registro editable y verificable que contiene múltiples valores hash por entrada para separar la confidencialidad de un registro de verificabilidad. Los registros se pueden verificar usando el recálculo de hashes y la verificación de firmas digitales confiables. El registro puede dividirse en segmentos, cada uno firmado por un servidor de tiempo o autofirmado usando un sistema de claves efímeras. Los mensajes de registro relacionados con objetos o eventos específicos se anidan dentro del registro para evitar la omisión de informes.

El método según la invención, como se define en la reivindicación 1, comprende un método implementado por ordenador para permitir la validación de la integridad de los datos por referencia a una pluralidad de elementos de datos únicos almacenados o registrados en al menos un dispositivo informático, en donde cada uno de tales elementos de datos es el resultado de operar una función unidireccional en los datos respectivos para crear resúmenes únicos respectivos de igual longitud y combinar cada nuevo resumen con su predecesor (la creación de tales resúmenes por medio de una función unidireccional de este tipo se denomina en la presente memoria hacer hash y los resúmenes individuales resultantes se denominan en la presente memoria hashes); y los hashes se almacenan luego en el dispositivo informático como un conjunto de datos vinculados en el que el valor de cada hash sucesivo, excepto el primero, depende del valor del hash anterior combinado (por ejemplo, por concatenación o una operación OR exclusiva a nivel de bits) con un nuevo hash resultante de hacer hash a los nuevos datos que a su vez se han combinado con un hash anterior diferente, en donde el hash más reciente en el conjunto de datos es el resultado acumulativo de todos los hashes anteriores en su secuencia original (un conjunto de datos vinculado que incluye un resultado acumulativo de este tipo se denomina en la presente memoria cadena de hash, y los hashes acumulativos en la cadena de hash se denominan HASHJJNKED en la presente memoria), cada hash en el conjunto de datos que es único para los datos añadidos más recientemente.

Como se indica, se usa al menos un dispositivo informático; ese dispositivo informático puede ser, en algunas realizaciones, un único dispositivo informático o, en otras realizaciones, puede ser una pluralidad de dispositivos informáticos dispuestos o programados para operar juntos.

La presente invención comprende además un aparato adecuado para llevar a cabo el método según la invención, como se define en la reivindicación 9, el aparato que comprende

al menos un dispositivo de almacenamiento que contiene una pluralidad de fuentes de datos,

una entrada a través de la cual el contenido de las fuentes de datos se puede añadir al dispositivo de almacenamiento,

un procesador programado para convertir todo el contenido de datos de las fuentes de datos por referencia a una pluralidad de elementos de datos únicos almacenados o registrados en al menos un dispositivo informático, siendo los elementos de datos el resultado de (i) hacer hash a una fuente de datos respectiva y (ii) combinar cada nuevo hash con su predecesor,

el procesador que está programado para almacenar los hashes como un conjunto de datos vinculado en el que el procesador aplica un valor a cada hash sucesivo que depende del valor del hash anterior combinado con un nuevo hash resultante de hacer hash a una nueva fuente de datos que a su vez se ha combinado con un hash anterior diferente;

el procesador que está programado además de modo que el hash más reciente en el conjunto de datos sea el resultado acumulativo de todos los hashes anteriores en su secuencia original, y de modo que cada hash en el conjunto de datos sea único para una nueva fuente de datos.

En una realización preferida, la cadena de hash se produce por las siguientes etapas secuenciales:

(a) combinar al menos uno de los HASH_LINKED, preferiblemente 3 (seleccionados como se describe a continuación) ya registrados en dicha cadena de hash con una fuente de datos recién añadida y hacer hash a la combinación resultante para producir un nuevo hash (denominado en la presente memoria HASH-SALTED) ;

(b) almacenar el HASH_SALTED en una nueva ubicación (en la presente memoria denominado como un campo dentro de un nuevo registro) en un almacén de datos digitales (en la presente memoria denominada como una tabla dentro de una base de datos) en el al menos un dispositivo informático; y

(c) combinar, en un nuevo registro, cada nuevo HASH_SALTED con el HASH_LINKED más reciente y hacer hash a la combinación para producir un HASH_LINKED adicional almacenado en otro campo en el mismo nuevo registro, de modo que el HASH_SALTED más reciente y el HASH_LINKED adicional estén permanentemente vinculados por posición en la base de datos;

Las etapas (a) a (c) se repiten en múltiples iteraciones, en donde después de cada repetición de la etapa (a), cada HASHj LINKED más reciente se combina, en un nuevo registro, con un nuevo HASH_SALTED y se hace hash para producir un HASH_LINKED adicional sucesivo, almacenado en el mismo nuevo registro.

En una primera realización preferida de la invención, a intervalos periódicos, se crea un registro adicional (denominado en la presente memoria REGISTRO DE CONFIRMACIÓN DE BLOQUE), haciendo hash a una combinación de un HASHj LINKED anterior y un archivo que contiene todos los registros creados desde el REGISTRO DE CONFIRMACIÓN DE BLOQUE anterior para crear un nuevo HASH_SALTED a almacenar en un nuevo registro en una posición predeterminada dentro de la cadena de hash almacenada; donde el valor del nuevo HASH_SALTED se combina con el HASH_LINKED más reciente en la cadena de hash para producir un nuevo HASH_LINKED más reciente almacenado en el mismo nuevo registro.

Se cree que la realización que se acaba de describir es novedosa per se y presenta, como lo hace, el uso recursivo de la cadena de hash para proteger secciones de la cadena de hash.

En una segunda realización preferida de la invención, la producción de cada HASH_LINKED sucesivo se verifica aleatoriamente de una o más de las siguientes formas:

(i) por agentes, que pueden ser virtuales (digitales) o humanos, que buscan autenticar elementos de datos arbitrarios;

(ii) por agentes programados para realizar verificaciones aleatorias;

(iii) por agentes (tales como los miembros de una red de pares) que realizan verificaciones periódicas o aleatorias; o (iv) por agentes que añadan nuevos registros; de modo que la verificación ocurra al menos con la misma frecuencia que las iteraciones de las etapas (a) a (c), y se emita un mensaje de alarma si la acción de verificación produce un resultado negativo.

También se cree que esta realización es novedosa per se porque asegura que la integridad de la cadena se prueba al menos con la misma frecuencia con la que se actualiza.

En una tercera realización preferida de la invención, un HASHJJNKED reciente en la cadena de hash se combina además con un elemento de datos creado instantáneamente, tal como una imagen digital, y se hace hash a la combinación resultante para formar un nuevo HASH_SALTED, que a su vez se almacena en la base de datos o una base de datos adicional en la primera oportunidad disponible. También se cree que esta realización es novedosa per se porque reduce significativamente la oportunidad de manipular imágenes antes del registro.

En algunas realizaciones, se prefiere que HASH_SALTED incluya además una cadena corta de datos aleatorios. Una cadena corta de datos aleatorios de este tipo se conoce, en el campo, como SALT criptográfico; una cadena corta de este tipo se denominará en la presente memoria "SALT".

Cada HASHj LINKED se incorpora al menos una vez en datos posteriores cuyo HASH_SALTED resultante se incorpora más tarde en la cadena de hash.

Las realizaciones del método según la invención pueden además permitir la verificación rápida de la integridad de los elementos relevantes de la cadena de hash acumulativa, por la inclusión típicamente de registros de confirmación de bloque, y final del día (o final de sesión) en la cadena de hash, para confirmar la integridad de secciones arbitrarias de la cadena de hash y así soportar la validez de los hashes de la fuente arbitrarios registrados en la cadena de hash.

Las realizaciones del método según la invención pueden habilitar además un servidor central (que puede tomar la forma de un servicio centralizado alojado por un grupo de proveedores principales que forman lo que podría llamarse una red de "super-pares" o red de Pares altamente optimizada (red P2P) para estar protegidos de ataques internos, a través de la supervisión y prueba continuas del rendimiento del servidor central por una red P2P usando el software de cliente local adecuado para medir los tiempos de respuesta del servidor y confirmar la congruencia entre los datos que tiene el cliente y datos que tiene un servidor central o remoto.

La presente invención se puede resumir como que es una "cadena de hash enlazada" en la que dos características clave distinguen la cadena de hash resultante de las cadenas de hash anteriores (conocidas). En primer lugar, los elementos anteriores de la cadena de hash se combinan con nuevos datos de la fuente local cuando sus hashes individuales se calculan antes de su inclusión en la cadena de hash creciente. Este mecanismo impide significativamente los intentos de atacar la cadena internamente. En segundo lugar, los registros periódicos de "confirmación", que son algo análogos al conocido concepto de "cadena de bloques" (aunque con un origen y propósito radicalmente diferentes) se pueden añadir a intervalos fijos a la cadena de hash. Tales intervalos pueden definirse, por ejemplo, por períodos de tiempo fijos predeterminados, o cantidades de datos fijas predeterminadas.

Estos registros de confirmación pueden proporcionar la capacidad de verificar cualquier registro dentro de la cadena de hash, por antiguo que sea, que incluye la verificación crucial de que la propia cadena sigue estando intacta, como máximo, un par de minutos y, de manera óptima, en unos pocos segundos.

Además de estas modificaciones en la cadena de hash, una red de pares (P2P) puede proporcionar el papel del guardián del servidor central o remoto.

Una consecuencia adicional es que las realizaciones del método según la invención permiten un aumento significativo en la confianza que es posible impartir con respecto a la validez de los datos digitales creados o capturados instantáneamente, tales como las imágenes capturadas por cámaras digitales.

Vinculando las imágenes con el valor hash acumulativo más reciente en la cadena de hash, y cargando el valor hash de tales imágenes vinculadas tan pronto como se toman las imágenes, o en la primera oportunidad disponible después de eso, el método según la invención puede permitir la prueba de que una fotografía dada debe haber sido tomada entre los tiempos indicados por las marcas de tiempo respectivas del primer y segundo valor hash; esto puede reducir drásticamente el tiempo disponible para cualquier tipo de manipulación de imágenes fuera de la cámara.

Finalmente, las realizaciones del método según la presente invención pueden ayudar a lograr niveles similares de confianza (para la integridad de los datos) basados en la adopción generalizada de documentos certificados (cuya integridad de los datos está protegida por la cadena de hash modificada y viceversa). Cada fuente de datos certificada puede considerarse, en cierto modo, como su propio "diario de registro" que lleva consigo la confianza adecuada para el notario relevante. Pero la recopilación de tales datos certificados forma un grupo significativo de confianza que, con el tiempo, puede ser reconocido como equivalente o incluso superior al diario de registro tradicional. Así, los datos distribuidos obtenidos como resultado del método según la invención ayudan a proteger el almacén de datos central.

El método según la invención puede considerarse modificado con respecto al método descrito en el mencionado documento EP1678666B1 y a las cadenas de hash estándar, de tres formas principales, de la siguiente manera:

1 Se modifica la forma en que se preparan los hashes individuales antes de su inclusión en la cadena de hash; específicamente, los hashes preexistentes de la cadena de hash se combinan con cada nuevo elemento de datos para crear su hash posterior.

2 La forma en que se añaden "Registros de confirmación" periódicos a la cadena de hash acumulativa, que verifican múltiples bloques de registros entre las confirmaciones impresas diarias y permiten una verificación rápida tanto de la integridad de los elementos de datos relevantes como de la propia cadena de hash.

3 La implementación de la supervisión de pares (P2P) del rendimiento, el contenido y la precisión del tiempo del servidor para identificar los primeros signos de ataque.

El término "cadena de hash", tal como se usa en la presente memoria, se refiere a la tabla principal en una base de datos que contendrá una serie de registros que incluyen una serie de campos, algunos de los cuales se describen a continuación.

El campo clave contiene el valor hash acumulativo al que se llegó por el proceso de combinar el hash acumulativo almacenado en el registro anterior con el hash de la fuente modificado (HASH_SALTED) del nuevo registro y hacer hash a esa combinación para crear el nuevo hash acumulativo. Este es el HASHJJNKED mencionado anteriormente.

Ahora se describirán realizaciones preferidas de la invención a modo de ejemplo con referencia a los dibujos adjuntos, en los que:

La figura 1 es una representación esquemática de una realización de la invención en la que los hashes existentes de una cadena de hash se incorporan a una fuente de datos antes de crear nuevos hashes para añadirlos a la cadena;

la figura 2 es una representación esquemática de la creación de registros de confirmación de bloque a intervalos fijos según una realización preferida de la invención; y

La figura 3 es una representación esquemática de una realización de la invención en la que se incorpora un hash reciente, a modo de ejemplo, en una imagen digital y se hace hash del resultado a un almacén en una cadena de hash.

La figura 1 muestra una secuencia, desde la parte superior de la columna de la izquierda hacia abajo, y luego desde la parte inferior de la columna de la izquierda hasta la parte superior de la columna de la derecha, y luego desde la parte superior de la columna de la derecha hacia abajo; y

Las figuras 2 y 3 muestran secuencias respectivas, desde la parte superior de la columna hacia abajo.

Refiriéndose nuevamente a la figura 1, ésta muestra una serie de operaciones que comienzan con la fuente de datos de un autor.

Los HASHj LINKED existentes (como se describe anteriormente) se recuperan de una cadena de hash y luego se combinan con los datos de la fuente de datos. Se hace hash del resultado para producir HASH_SALTED que luego se almacena en un nuevo registro (registro R) en la cadena de hash.

Luego, el valor HASH_LINKED en el registro inmediatamente anterior (es decir, el registro R menos 1) se combina con HASHj SALTED del registro R y la nueva combinación hash (nuevo HASH_LINKED) se almacena en el registro R.

Refiriéndose nuevamente a la figura 2, ésta muestra una serie de operaciones resultantes en la creación de Registros de Confirmación de Bloques a intervalos fijos.

En primer lugar, se establece un intervalo fijo predeterminado (por ejemplo, basado en la longitud de bloque L). El primer bloque contiene L registros y termina en el Registro R. Los bloques posteriores comienzan en R+1 y contienen los siguientes L registros. Luego, cada bloque se copia en un archivo a medida que se completa. Luego, el valor HASHj LINKED se recupera del último registro que precede inmediatamente al bloque más reciente de L registros (Registro R menos L) y esto se combina con los datos del archivo de bloque y se hace hash como una combinación para producir HASH_SALTED. Luego, después de un período de espera para un bloque adicional de L nuevos registros, el resultado se almacena como el primer registro del penúltimo bloque, que debe ser Registro R más L más 1.

Haciendo referencia nuevamente a la figura 3, ésta muestra una serie de operaciones que incorporan un HASHj LINKED reciente en datos instantáneos (en este caso, una imagen digital) para almacenar un nuevo HASHj SALTED en una cadena de hash.

Específicamente, se proporciona una cámara con acceso al software de cliente adecuado y se recupera el HASHj LINKED más reciente. Luego, se cifra un espacio de archivo, se toma una fotografía con la cámara y la imagen resultante se almacena en el espacio de archivo cifrado. Luego, se hace un hash al resultado para formar HASHj SALTED, que se almacena, en la primera oportunidad, en la cadena de hash de la manera descrita anteriormente.

Aunque todos los hashes en el método según la invención se crearán normalmente usando el mismo algoritmo de hash (por ejemplo, SHA 256) y, en ese sentido, serán todos el mismo tipo de hash, necesitamos referirnos a los diversos hashes por su función o papel, por lo que los definiremos ahora.

En la descripción siguiente y anterior, el término "local" se aplica a operaciones, etapas y equipos proporcionados para un usuario del método y sistema, que puede desear en cualquier momento validar la integridad de los datos, mientras que "remoto" se aplica a un servidor o base de datos que puede estar físicamente separado de un usuario local, y con la conexión del usuario local que es permitida a través de una red de comunicaciones de tecnología de la información.

El registro estándar en la cadena de hash contendrá una serie de campos. Los tres más importantes funcionalmente se mencionarán muchas veces y, para los propósitos de este documento, se denominan de la siguiente manera:

HASH_SOURCE - el hash del documento de la fuente o elemento de datos que estamos intentando proteger; HASH_SALTED - como se definió anteriormente; HASH_LINKED - como se definió anteriormente. En el proceso de registro de nuevo contenido de datos, que implica añadir un nuevo registro a la base de datos y calcular su nuevo HASH_LINKED, hacemos uso explícito de los HASH_LINKED anteriores de una manera que es fundamental para la invención.

La realización preferida presenta un servicio remoto centralizado alojado por al menos uno (preferiblemente muchos) servidores de Internet que operan colectivamente en una red de "super-pares", pero al que nos referiremos simplemente como el "servidor". Esto no excluye alojar el servicio completamente en una red P2P más convencional, siempre que se pueda lograr el rendimiento requerido en una red de este tipo.

Los autores, propietarios o editores (términos que podemos usar indistintamente) que deseen salvaguardar la integridad de sus datos de la fuente, emplean clientes de software para llevar a cabo las tareas que se describen a continuación. Donde se requiere la elección del usuario, los clientes presentan la elección al autor y pueden proporcionar opciones adicionales, donde sea adecuado, para hacer que la respuesta de la elección sea una predeterminada para que los futuros registros continúen más allá de ese punto automáticamente.

De aquí en adelante, debe entenderse que a menos que se indique explícitamente una acción del usuario, las tareas descritas son todas llevadas a cabo por software en el servidor remoto o por el cliente local.

Protección del servidor de ataques internos con una cadena de hash vinculada

Esta primera sección describe la infraestructura de los datos y cómo el proceso de añadir nuevos registros ayuda a proteger la cadena de hash del ataque potencial más peligroso - donde el atacante ha obtenido el control completo del servidor.

Ahora se definirán e ilustrarán algunos términos adicionales relevantes para la realización preferida.

HASH_PREVIOUS se refiere a un Hash extraído de la colección de los HASH_LINKED añadidos recientemente que aún no se han combinado con fuentes posteriores para crear nuevos HASH_SALTED. Se asignan a los nuevos registros sobre la base de "Primero en Entrar, Primero en Salir", por lo que siempre es el más antiguo el primero en la cola.

HASH_PRIOR - se refiere a cualquier HASH_LINKED que ya se haya incorporado al menos una vez en HASH_SALTED posteriores y, por lo tanto, debe ser anterior a esos registros HASH_PREVIOUS que siguen esperando su turno para su inclusión en registros futuros.

Pseudo-SAL se refiere a la recopilación de, preferiblemente, dos HASH_PRIOR, un único HASH_PREVIOUS y SALT opcional (véase anteriormente) que se combinarán con los datos de la fuente, para crear HASH_SALTED

Cada nuevo HASH_SALTED añadido a la cadena se creará combinando los datos de la fuente relevantes con su pseudo-SALT. El nombre (pseudo-SALT) se elige para hacer eco de su similitud parcial, en función, con SALT criptográfico "tradicional", así como para reconocer que, en los casos donde no se usa SALT criptográfico, el pseudo SALT no es tan protector como lo sería el SALT “verdadero”. El SALT "verdadero" se usa principalmente para aumentar la dificultad de un atacante para forzar por "fuerza bruta" (un término de campo usado para describir el proceso de descubrir la clave de los datos cifrados o derivar los datos de la fuente para un hash criptográfico intentando todas las soluciones posibles hasta que se encuentra la respuesta correcta) un texto sin formato adivinable y esto sigue siendo una posible razón para la inclusión de SALT opcional en el pseudo-SALT. Es decir, algunos de los datos de la fuente que están protegidos pueden necesitar seguir siendo confidenciales mientras que un texto sin formato adivinable (por ejemplo, la elección de un candidato de la selección muy limitada en una papeleta de votación) debe estar protegido ocultando la fuente de su hash añadiendo SAL.

Esto es necesario en casos en los que, aunque la mera inclusión de HASH_PRIOR y HASH_PREVIOUS ocultaría parcialmente los datos confidenciales, se extraen de una población limitada y, así, son inherentemente adivinables, aunque la adivinación requeriría un esfuerzo considerable por parte del atacante, especialmente si el pseudo-SALT se implementa aleatoriamente en toda la fuente.

Sin embargo, el propósito principal de incluir los HASH_LINKED anteriores (es decir, HASH_PRIOR), en la forma de pseudo-SALT, no es derrotar un ataque de fuerza bruta contra la fuente. Es derrotar un ataque contra la propia cadena de hash como se detalla a continuación.

El lugar donde los elementos pseudo-SALT se insertan en la fuente antes de hacer hash es completamente arbitrario y puede ser determinado por cada autor por sí mismo. Ni siquiera se necesitan mantener los elementos juntos, por lo que podrían estar dispersos aleatoriamente por toda la fuente. Sin embargo, es vital que el cliente local almacene detalles de cómo y dónde se incluyó exactamente el pseudo-SALT para que cuando el cliente pase los Datos (y el pseudo-SALT) a una Parte de Confianza, pueda incluir instrucciones sobre cómo combinar con los Datos para recrear HASH_SALTED y verificar su inclusión en la cadena de hash.

Los HASH_PRIOR se seleccionarán aleatoriamente de los HASH_LINKED ya publicados en la cadena de hash. Preferiblemente, la selección seguirá la regla de que uno de los HASH_PRIOR se seleccionará aleatoriamente de los añadidos en las últimas 24 horas, preferiblemente antes de la fecha límite de impresión más reciente, y uno se seleccionará aleatoriamente de los registros de Final del Día antes de esa publicación.

Es importante que el HASH_PRIOR más antiguo se seleccione explícitamente de los publicados antes de la fecha de publicación impresa más reciente, ya que el atacante ya no puede modificarlos sin ser detectado.

La relevancia de la referencia de 24 horas es de la siguiente manera. El Cliente preferido será un miembro P2P completo de una red de usuarios. Como tales, normalmente mantendrán una copia local de esa parte de la cadena de hash publicada en las 24 horas anteriores, o al menos tanto como lo permita su almacenamiento local. El mínimo almacenamiento útil sería el necesario para capturar los registros de la nueva cadena de hash de los minutos anteriores, o 10000 registros, lo que sea mayor.

Además, el Par del Cliente almacenará tantos registros de Final del Día como lo permita el almacenamiento local. Como solo se requerirían menos de dos megabytes para almacenar los registros diarios de aproximadamente 100 años de datos, no hay ninguna razón obvia por la que todos tales clientes no puedan alojar todos los registros de Final del Día que se hayan creado. Estos registros contienen los HASH_LINKED que son idénticos a los que aparecen en las Publicaciones Impresas. Opcionalmente, los Pares también pueden almacenar todos los Registros de Confirmación del Día y todos los Registros de Confirmación de Bloque. En última instancia, esto implicaría que un Par almacene aproximadamente el 1 % del 1 % de la cadena de hash completa (1 en 10000 registros).

Los propósitos del almacenamiento P2P local son tres. En primer lugar, en el caso de su propio registro de una nueva entrada a la cadena de hash, les permite seleccionar aleatoriamente sus HASH_PRIOR sin referencia ni conocimiento de los posibles atacantes que controlan el servidor. En segundo lugar, les permite, tanto individual como colectivamente, comparar aleatoriamente las entradas de los demás - verificar las entradas en la cadena de hash del Servidor y, en tercer lugar, en caso de pérdida temporal de acceso al Servidor, se podría proporcionar por la red P2P una forma limitada del servicio.

Para los Clientes que no puedan o no deseen participar en la red P2P, el proceso de registro recomendado implicará que descarguen un segmento reciente de la cadena de hash, según se requiera, para poder seleccionar sus HASH_PRIOR.

El segmento típicamente contendrá 10000 registros recientes de la cadena de hash, pero raramente constituirá un "bloque" (véase a continuación) ya que sus límites casi siempre cruzarán los límites del bloque. Idealmente, la descarga a estos clientes parciales también incluirá doscientos o trescientos registros de Final del Día, pero esto puede variar según el ancho de banda local y los problemas de tráfico. El objetivo es permitir una selección razonablemente aleatoria de HASH_PRIOR que un atacante no pueda adivinar con demasiada facilidad. Aquellos usuarios que evitan incluso el segmento reciente (clientes nulos) pueden seguir haciendo selecciones aleatorias de sus HASH_PRIOR, pero no pueden ocultar su elección a un atacante potencial.

En todos los casos (Clientes completos, parciales y nulos), después de iniciar sesión para comenzar el proceso de creación y carga de un nuevo conjunto de hash, y en el momento en que estén listos para completar el proceso de hacer hash, el servidor les asignará un HASH_PREVIOUS de su grupo de HASH_LINKED no asignados.

Un papel principal del Cliente completo o parcial es compartir datos con la red P2P, con respecto al rendimiento y los tiempos de respuesta del Servidor. Esto se describe con más detalle más adelante (véase "Protección del Servidor con una Red de Pares"). El punto importante aquí es que antes de intentar enviar nuevos registros al servidor, sondeará la red P2P para asegurarse de que actualmente se considera seguro continuar, ya que no hay evidencia de que el servidor esté bajo ataque.

Suponiendo que es seguro continuar, el Cliente de software, en todos los casos, calculará e1HASH_SOURCE para los datos de la fuente. El primer propósito es verificar, dentro de su tabla local de registros anteriores, que la fuente actual no haya sido registrada. Sin embargo, el envío de HASH_SOURCE al servidor es opcional. Hay una serie de razones por las que un autor puede no desear publicar el HASH_SOURCE.

Como en el ejemplo anterior, los datos pueden ser confidenciales pero de un conjunto limitado de texto sin formato que podría ser fácilmente forzado por fuerza bruta. O el autor podría desear asegurarse de que cualquier persona que desee validar los datos se vea obligada a ponerse en contacto con el autor. Eso sería innecesario si se publicaran tanto la fuente como HASH_SOURCE. Pero si la fuente se publica mientras que HASH_SOURCE no lo está, entonces, si se requiere validación, solo puede realizarse contactando al autor o editor para obtener el pseudo-SALT (y las instrucciones de inclusión) requeridos para realizar la validación completa. Tales restricciones pueden ser útiles, por ejemplo, para controlar el acceso a nuevas cuentas en línea, o en "Ofertas especiales" o "Extras" comerciales que solo se pueden reclamar por contacto directo con el vendedor, o para asegurar que solo las entidades autorizadas puedan validar datos relevantes o que cada intento de validar datos relevantes sea a su vez rastreado, etc.

Por el contrario, el HASH_SALTED siempre se cargará si se calcula. Sin embargo, se tiene en cuenta la posibilidad de que algunos autores puedan necesitar registrar una fuente pero no tengan disponible el software del Cliente. Y es posible que algunas aplicaciones no necesiten la protección que brinda HASH_SALTED. Por ejemplo, es posible que los fotógrafos deseen proporcionar automáticamente una prueba de cuándo se creó la imagen con propósitos de derechos de autor, en lugar de simplemente cuándo se registró en la cadena de hash. Esto requiere un uso especializado de los datos de la cadena de hash que implica una forma más débil de HASH_SALTED que se describe más adelante (véase "Pruebas del Tiempo de Creación para Dispositivos de Captura Digital Instantánea").

No necesitarían la protección proporcionada por el uso de HASH_SALTED normal, aunque pueden seguir eligiendo usarlo, ya que cada uso de HASH_SALTED se añade a la protección general de la cadena de hash. Los datos registrados sin HASH_SALTED seguirán estando protegidos por la cadena de hash, pero no proporciona protección recíproca a la cadena de hash.

El propósito de crear HASH_SALTED y usarlo para crear el siguiente HASHJJNKED en la cadena de hash es hacer que cualquier ataque directo a la cadena de hash sea imposible de ocultar durante el tiempo suficiente para que el ataque tenga éxito con los propósitos de engaño. Luego, el único impacto significativo que podría lograr un ataque directo a la cadena de hash sería similar a la denegación de servicio, una interrupción del servicio normal.

Es razonable suponer que el propósito de la mayoría de los ataques sería crear y mantener un engaño rentable que pueda mantenerse el tiempo suficiente para engañar a la víctima para que acepte. Los ataques motivados por otras consideraciones (por ejemplo, Denegación de Servicio) no son el foco de esta invención. Requieren otras contramedidas. Para que tenga éxito el tipo de ataque de falsificación interna que nos preocupa, tenemos que suponer que el atacante tiene el control completo del servidor y, presumiblemente, uno o más documentos o datos de la fuente cuyo contenido necesitan modificar para crear el engaño. Su propósito al atacar la cadena de hash es dar credibilidad a su modificación.

Antes de la presente invención, un ataque de este tipo contra una cadena de hash o tabla hash protegida por diario habría sido plausible en todos los datos añadidos a la cadena de hash o tabla hash desde la publicación impresa más reciente.

Un atacante que controle un Servidor de cadena de hash de este tipo podría reemplazar un HASH_SOURCE existente seleccionado con uno propio y, dado que todos los HASH_SOURCE posteriores usados para compilar la cadena de hash son visibles, puede recrear la cadena. Incluso si un observador externo sospechara de un ataque, no podría probarlo fácilmente.

Como se indicó anteriormente, hay un período de vulnerabilidad entre las publicaciones impresas, es decir, el período durante el cual aún no es completamente seguro confiar en los datos confirmados por la cadena. Todas las cadenas de hash y cadenas de bloques son vulnerables durante ese período. Como se indicó anteriormente, para cualquier elemento dado, el período entre su registro en la cadena de hash y el punto en el que se puede confiar en él se conoce en el campo como Latencia de Verificación.

Con la publicación impresa, ese período puede ser de hasta 24 horas. Por el contrario, la Latencia de Verificación de Bitcoin está entre 6 y 60 minutos, dependiendo del nivel de certeza que la Parte de Confianza requiere para confiar en una transacción dada. Estos períodos prolongados de incertidumbre han hecho anteriormente que la protección de integridad basada en hash no sea adecuada para muchos propósitos, por ejemplo, transacciones financieras de alta velocidad.

El principal beneficio de esta invención es la reducción de la Latencia de Verificación a una cuestión de segundos, lo que coloca la tecnología dentro del alcance de la mayoría de las transacciones financieras e incluso de la mayoría de los procedimientos de autenticación que requieren validación en tiempo real. Esta reducción drástica de la Latencia se logra cambiando del uso de HASH_SOURc E para construir la cadena, al uso de HASH_SALTED.

Esto hace rápidamente que la tarea del atacante sea imposible y, como consecuencia directa, hace que la cadena de hash sea inherentemente más confiable en "tiempo real".

Los atacantes pueden tener acceso a los Datos objetivo que necesitan modificar, y acceso a la cadena de hash, por lo que debemos suponer que pueden seguir viendo todos los HASH_SOURCE y Ha SH_SALTED (publicados), pero ya no pueden realizar el recálculo necesario de la cadena de hash para cualquier entrada de más de uno o dos vínculos hacia abajo en la cadena después del registro que han modificado con éxito.

Para entender por qué, comencemos con el siguiente vínculo en la cadena - después del elemento que el atacante ha intentado cambiar. Es poco probable que su propio HASH_SALTED se haya visto afectado por el ataque, ya que el HASH_LINKED atacado está demasiado cerca de él para haber sido usado como HASH_PRIOR o, a menos que las tasas de registro sean muy bajas, demasiado cerca para que haya sido e1HASH_PREVIOUS en el cálculo de su propio HASH_LINKED. Por lo que, el atacante podría incorporar con éxito ese HASH_SALTED en un intento de recalcular la cadena de hash.

Sin embargo, cuando el atacante pasa al siguiente HASH_SALTED de la cadena, ahora hay una pequeña probabilidad de que la versión original del HASH_LINKED que acaban de atacar se haya usado como HASH_PREVIOUS para calcular ese HASH_SALTED.

Aunque pueden seguir ignorando ese problema y recalcular la cadena de hash para incluir el siguiente HASH_SALTED, también hay un pequeño riesgo de que cualquiera que realice una verificación de esa parte de la cadena de hash falle y luego emita una advertencia.

A medida que avanzamos en la cadena, la probabilidad de encontrar un HASH_SALTED que depende de uno de los HASH_LINKED ahora modificados aumenta rápidamente a un valor de 1 (certeza). Irónicamente, cuanto menor sea la tasa de registros (el proceso de añadir nuevos registros a la cadena creciente), menor será el número de HASH_SALTED potencialmente comprometidos antes de que esa probabilidad alcance 1 (uno).

Por lo que, dado que en un período de bajo uso, el registro probablemente llevaría menos de un par de segundos, si los elementos se estaban registrando a una tasa de, por ejemplo, uno cada cinco (5) segundos, el segundo HASH_SALTED que encuentre el atacante debe haber incluido el HASH_LINKED que acaba de modificar, momento en el cual su recálculo fallará a menos que también tenga acceso a los Datos de la Fuente relevantes.

Si, por el contrario, los registros ocurren a una tasa de mil por segundo, es concebible que el atacante no encuentre un HASH_SALTED que dependa de su propio hash atacado durante quizás mil nuevos registros.

La cifra crítica es el tamaño del grupo o caché que tiene el servidor que contiene registros HASH_PREVIOUS no asignados; que, a su vez, depende solo parcialmente de la tasa de registros y la tasa a la que el Servidor puede manejarlos. Los servidores modernos tienen una gran capacidad (por ejemplo, ciertas transacciones con tarjetas de crédito se procesan actualmente a un tasa superior a 200 millones por día, más de 2000 por segundo). Sin embargo, el cuello de botella probable es la tasa a la que los Clientes harán uso de los datos del grupo. Un HASH_PREVIOUS no se puede eliminar del grupo hasta que el Servidor reciba un registro completo de vuelta del Cliente (que confirma que ahora se ha asignado y usado) y la respuesta del Cliente puede demorarse arbitrariamente por eventos que se realizan al final del Cliente.

Por lo que el grupo realmente refleja el número de registros "pendientes", donde los Clientes han iniciado el registro pero aún no los completaron. En cualquier caso, cualquiera que sea ese número, una vez que el atacante haya recreado un número igual de nuevos vínculos en la cadena, DEBE estar creando nuevos vínculos que fallarán cualquier intento de validación.

Esto se debe a que el atacante no solo no sabe qué HASH_PRIOR (o incluso HASH_PREVIOUS, aunque estos son intrínsecamente más fáciles de adivinar) se han incorporado a los HASH_SALTED en curso, sino que incluso si lo supieran, no pueden realizar los recálculos necesarios en ningún dato de la fuente al que no tengan también acceso y control completos (que serán la mayoría de los demás datos protegidos por la cadena de hash).

En reconocimiento del papel crítico del tamaño del grupo HASH_PREVIOUS, el Servidor volverá a emitir cualquier HASH_PREVIOUS que aún no haya sido "consumido" por un registro en curso dentro de, por ejemplo, 10 o 20 segundos.

Esto se debe a que no importa cuántas veces se incorpore un HASH_PREVIOUS en futuros HASH_SALTED. Lo que importa es que TODOS se usen y, preferiblemente, se usen lo más rápido posible, para restringir la ventana de oportunidad del ataque. Por lo tanto, si, por cualquier razón, un registro en curso no se completa en unos pocos segundos, el Servidor simplemente volverá a emitir el HASH_PREVIOUS pendiente a un registro alternativo con la expectativa de que este proceso reiterativo minimice las posibilidades de que cualquier HASH_PREVIOUS siga estando sin usar durante más de unos pocos segundos. Esto asegura que el atacante debe atacar el obstáculo de un HASH_PREVIOUS usado dentro del número de registros producidos en un período similar.

Sin embargo, el hecho de que la cadena de hash modificada del atacante no pase la inspección solo importa si se inspecciona la cadena. Y dos aspectos adicionales de la invención aseguran que las inspecciones deben realizarse AL MENOS a la misma tasa que los registros. En primer lugar, no se concluye ningún registro hasta que el Cliente haya inspeccionado el segmento relevante de la cadena, que incluye el nuevo registro del autor, para asegurarse de que la cadena sigue estando intacta, generalmente desde el registro que constituye el último registro del final de día publicado. En segundo lugar, los Clientes inactivos, cuyos usuarios lo aprueban, realizarán periódicamente verificaciones aleatorias de todas las partes de la cadena.

En ese momento, el envío del autor queda registrado y puede considerarse "pendiente de confirmación". No puede considerarse "confirmado" hasta que se haya incorporado su propio HASH_LINKED (como un HASH_PREVIOUS) en un registro HASH_SALTED/LINKED posterior. Esto podría confirmarse en el servidor por la inclusión de HASH_PREVIOUS en ya sea el registro posterior o en los metadatos vinculados (véase a continuación), junto con una entrada espejo del HASH_LINKED posterior en cualquier metadato relevante para el registro pendiente del autor.

Esta etapa, o algo similar, puede ser necesaria para derrotar un ataque donde el atacante retiene deliberadamente uno o más HASH_PREVIOUS seleccionados con el propósito de facilitar su ataque a un documento objetivo, por ejemplo, extendiendo la cantidad de tiempo que tiene para realizar el ataque, o conservar selectivamente el HASH_PREVIOUS que planea incorporar en una entrada modificada. Asegurando que la "confirmación" dependa del registro de la incorporación posterior, sería más fácil establecer alarmas que se activen si esa confirmación lleva más de los pocos segundos esperados.

Para los clientes P2P completos, el registro típicamente implicará una prueba de vínculo que comienza con el registro impreso más reciente (el registro anterior de Final del día) y continúa hasta el final de la cadena.

Como la mayoría de los datos ya los tendrá del cliente, el cliente puede interceptar la cadena creciente - en línea -en cualquier punto para confirmar que sigue coincidiendo con su propio registro, y que los nuevos registros también se ajustan. La parte fuera de línea de la verificación desde la medianoche anterior solo le llevará al Cliente uno o dos segundos.

Completar la verificación en línea llevará más tiempo, ya que está sujeta a la latencia normal de la red y a la contención con otros usuarios, pero con los servidores modernos, la verificación de los pocos cientos o miles de nuevos registros que se pueden haber añadido desde la última actualización del Cliente solo debería seguir llevando unos pocos segundos.

Dado que un sistema exitoso también estará sujeto a inspecciones aleatorias arbitrarias por parte de terceros que buscan validar datos en el curso normal del negocio, es razonable concluir que, siempre que haya, en todo momento, aunque sea un número relativamente pequeño de usuarios activos (por ejemplo, más de unas pocas docenas), ningún intento de atacar la cadena de hash podría dejar de detectarse en unos pocos segundos.

Lo que esto significa es que ningún ataque podría tener éxito (en el sentido de mantener el engaño el tiempo suficiente para engañar a la víctima) a menos que solo fuera necesario mantener el engaño durante menos de unos pocos segundos. Esto descarta la gran mayoría de posibles ataques ya que, si las Partes de Confianza están remotamente preocupadas por un riesgo de este tipo, todo lo que tienen que hacer es esperar unos pocos segundos más para la confirmación P2P de que no hay tal ataque en curso, y luego volver a verificar que sus datos siguen siendo válidos, antes de actuar sobre cualquier información que acaban de validar.

Donde se justifiquen restricciones de tiempo aún más estrictas sobre la certeza, las Partes de Confianza colaboradoras (por ejemplo, bancos o corredores de bolsa) podrían organizar la coordinación de una serie de registros y compartir los resultados en tiempo real, para probar que una transacción particular en medio de una serie de este tipo debe haberse presentado sin un ataque exitoso y, por lo tanto, se puede confiar en ella tan pronto como sus resultados compartidos se confirmen mutuamente. Las únicas limitaciones de velocidad en una configuración de este tipo las impone la infraestructura física de la red y eso implica (usando los elementos más grandes y robustos de Internet actualmente disponibles) que la Latencia de Verificación se podría reducir, donde importa, a, como máximo, unos pocos milisegundos.

Verificación Rápida de registros históricos

Esta sección explica cómo, en combinación con los procedimientos anteriores, unas pocas etapas más hacen posible, posteriormente, verificar la integridad de cualquier dato protegido por cualquier parte de la cadena en minutos, en lugar de días o semanas.

En primer lugar, necesitamos describir los registros de confirmación que se añadirán a la cadena de hash a intervalos fijos. En esta descripción supondremos que el intervalo fijo es cada 10000 registros, aunque, como se describe a continuación, el final del día, también se tratará como el final de un intervalo, para que cada nuevo día comience con sus primeros 10000 registros que forman el primer “bloque” del día.

La cifra de 10000 no es arbitraria, pero representa nuestra mejor suposición del tamaño del bloque que podría descargarse bajo demanda, en un tiempo razonable (5-10 segundos), con un ancho de banda razonable dado en el extremo del cliente, y una contención razonable en el extremo del servidor.

Si las condiciones en la práctica sugieren que 10000 es demasiado o muy poco, se puede implementar un mecanismo simple para permitir que el tamaño del bloque se ajuste diariamente si es necesario. Por ejemplo, el primer registro del día puede incluir una referencia al tamaño de bloque de ese día.

Los registros de confirmación serán creados por el Servidor siguiendo un conjunto simple de reglas siguientes:

1 Cuando se alcanza el registro número 10000, el HASH_LINKED actual se pasa a una rutina de archivo dedicada en el Servidor que opera por separado de la rutina más importante del Servidor, el generador de cadena de hash.

2 Al recibir esa señal, la rutina de Archivo devolverá al generador de la cadena de hash el registro que ya ha creado del bloque anterior (suponiendo que haya uno, que siempre será el caso, una vez que la cadena tenga más de un bloque). El generador de cadena de hash añadirá el registro y devolverá el nuevo HASHJJNKED a la rutina de Archivo, para que pueda almacenarse en su copia del registro. El objetivo de este proceso es evitar demoras en la operación del generador de cadenas de hash. Es concebible que la arquitectura de base de datos moderna o futura hará innecesaria tal separación de tareas. Mientras tanto, la construcción del registro de archivo puede realizarse mientras se construye el siguiente bloque y estará listo para regresar al generador de cadenas al final del siguiente bloque, para que pueda añadir el registro tan rápido como cualquier otro.

3 El generador de cadenas de hash hará que el registro que acaba de recibir de la rutina Archivo sea el primer registro del siguiente bloque, a menos que el siguiente bloque sea el primer bloque de un nuevo día, en cuyo caso el primer registro será el Registro de Confirmación del día anterior (véase a continuación) y el registro de confirmación de bloque será el segundo registro del día. Esto es arbitrario. El orden de los registros podría invertirse o ser determinado de otro modo. Lo importante es que las reglas que determinan la posición de los registros de confirmación sean fijas y conocidas.

4 La rutina Archivar ahora hará hash de la copia del nuevo bloque que ha hecho y creará un nuevo registro, listo para la siguiente señal de final de bloque, que se compone, por ejemplo, de la siguiente manera:

4.1 El HASHj SOURCE será el hash del bloque.

4.2 El HASHj PREVIOUS será el HASH_LINKED del final del bloque anterior.

4.3 El HASHj PRIOR será el HASH_LINKED del final del antepenúltimo día (el antepenúltimo día, o anteayer). El hecho de que todos los registros de confirmación de bloque de un día completo usen el mismo HASHj PRIOR no representa un riesgo significativo ya que el objeto no es una ofuscación sino un vínculo con datos lo suficientemente antiguos como para estar protegido por un Hash Impreso.

4.4 Claramente, el SALT criptográfico no se requiere en este contexto, y el pseudo-SALT siempre se añadirá al final del bloque.

4.5 Se hará hash al bloque, con pseudo-SALT añadido, para crear su HASH_SALTED

4.6 El nuevo registro se almacena en una "Tabla de Bloque de Día" que se usará, posteriormente, para crear el Registro de Confirmación del Día. Su HASH_LINKED se actualiza en el siguiente ciclo, cuando el registro se envía al generador de cadenas de hash y devuelve el nuevo hash acumulativo.

5 El bloque y su pseudo-SALT ahora se asignarán a múltiples unidades WORM (Escribe Una Vez Lee Muchas) distribuidas para almacenamiento inmutable permanente. Preferiblemente, cada ubicación del servidor o super-pares haría al menos una copia WORM para que el archivo se distribuya ampliamente.

6 El procedimiento al final del día es ligeramente diferente. No hay necesidad de crear un archivo separado o de hacer hash a los registros de todo el día, ya que los bloques individuales, excepto el último del día, se han archivado y hecho hash por separado.

El bloque final del día es simplemente lo que se haya añadido entre el último bloque archivado y la medianoche. Se archiva y se hace hash exactamente como todos los demás bloques, excepto que raramente contendrá exactamente 10000 registros. Su registro de confirmación se convertirá, por ejemplo, en el primer registro del segundo bloque del nuevo día.

El registro de Confirmación del Día se crea por la rutina de Archivo. Ya tiene copias de todos los registros de confirmación de bloque para el día en su Tabla de Bloque de Día.

Al completar el bloque final, añade su registro de confirmación a la Tabla de Bloque de Día, verifica que todos los registros siguen estando en su lugar dentro de la cadena de hash y crea un nuevo registro de Confirmación con las reglas siguientes:

6.1 El HASHj SOURCE será el hash de la Tabla de Bloque de Día.

6.2 El HASHj PREVIOUS será el HASH_LINKED del final del día anterior.

6.3 El HASHj PRIOR será el HASH_LINKED al final del día anterior.

6.4 Como con los bloques normales, no se requiere SALT, y el pseudo-SALT siempre se añadirá al final de los datos.

6.5 Se hará hash a la Tabla de Bloque de Día, combinada con su pseudo-SALT, para crear su HASH_SALTED. Esa colección también se compromete posteriormente al almacenamiento WORM. El registro de confirmación del Día siempre se almacena en la cadena de hash en una posición fija, tal como el Segundo Registro del Segundo Bloque del día siguiente y, como se indica en (3) anterior, el registro de Confirmación del Día también se repite como el primer registro del día siguiente.

Finalmente, se mantienen Tablas separadas de Registros de Final del Día y Registros de Confirmación del día, que mantienen copias de todos los Registros de Final del Día y Confirmación hasta la fecha. A medida que concluye cada Día, se genera un Registro de Confirmación adicional para cada una de esas tablas y se almacena en otra ubicación fija en la cadena de hash, usando el mismo HASH_PREVIOUS y HASH_PRIOR que el Registro de Confirmación del Día. Este conjunto de reglas es arbitrario y podrían ser posibles versiones más eficientes. El objetivo es continuar la vinculación de elementos anteriores de la cadena en los nuevos registros de Confirmación, para que si un atacante tiene éxito en modificar cualquier entrada, no pueda recalcular con éxito los efectos en el resto de la cadena. Los registros de confirmación constituyen datos sobre la propia cadena de hash, que cualquier observador o usuario puede confirmar, por sí mismo, en cualquier momento. Pero lo que más importa es la velocidad con la que tales reglas aseguran que cualquier registro se pueda verificar no solo como presente dentro de la cadena de hash, sino dentro de un bloque que se pueda verificar por registros posteriores dentro de la cadena y que el proceso pueda ser rápidamente rastreado hasta el HASHJJNKED actual al final de la cadena.

La consideración clave es que las reglas son fijas y públicas, para que el software del Cliente o incluso los humanos suficientemente motivados puedan probar a fondo los vínculos entre registros, bloques y días individuales. En general, el procedimiento para verificar los datos protegidos por la cadena de hash implica las etapas que se describen a continuación. Los pares también pueden mantener o crear sus propias copias de la Tabla de Final del Día y la Tabla de Registro de Confirmación del Día y verificar por sí mismos que sus HASH_SALTED coinciden con los del servidor. Los datos y metadatos proporcionados a la Parte de Confianza le permiten (generalmente con la ayuda del software del Cliente, pero sin él, si es necesario) seguir las reglas anteriores para llevar a cabo las siguientes acciones: 1 Reconstruir el HASH-SALTED.

2 Ubicar el HASH-SALTED en la cadena de hash.

3 Descargar el bloque en el que está incluido.

4 Realizar una prueba de vínculo exhaustiva en el bloque (véase el ejemplo en el punto 9 a continuación).

5 Cifrar con hash el bloque para obtener su HASH_SOURCE.

6 Siguiendo las reglas anteriores, encontrar su HASH_PREVIOUS y HASH_PRIOR.

7 Calcular su HASH_SALTED.

8 Ubicar ese HASH_SALTED en la cadena y confirmar que está donde debería estar (primer registro del penúltimo bloque).

9 Realizar una prueba de vínculo simple para el registro objetivo (el extremo de bloque anterior HASH_LINKED Registro de Confirmación HASH_SALt ED debería hacer hash al Registro de Confirmación HASH_LINKED) y, opcionalmente, para un pequeño número de registros aleatorio antes y después del registro objetivo.

10 Saltar al segundo registro en el segundo bloque del día, realizar la prueba de vínculo, y (suponiendo que siga estando vinculado) almacenarlo como "Registro de Confirmación del Día 0".

11 Saltar al primer registro del tercer bloque, realizar la prueba de vínculo y almacenar el registro en una tabla local de Bloque de Día de registros de Confirmación.

12 Saltar al registro de Confirmación del siguiente bloque, probar el vínculo, almacenar el registro en la tabla local.

13 Repetir hasta el registro de Confirmación de bloque final para que sea almacenado ese día (tomado del primer registro del segundo bloque del día siguiente).

14 Hacer hash a la tabla de Bloque de Día local para obtener su HASH_SOURCE.

15 Usando las reglas anteriores, encontrar el HASH_PREVIOUS y el HASH_PRIOR coincidentes y usarlos para crear su HASHj SALTED.

16 Localizar ese HASH_SALTED en la cadena y confirmar que está donde debería estar (segundo registro, segundo bloque, día siguiente).

17 Saltar hacia atrás al primer registro del día siguiente y confirmar que coincide con el Registro de Confirmación del DÍA 0.

18 Saltar hacia atrás un registro hasta el registro del Final del Día y compararlo con la Copia del Cliente.

19 Opcionalmente, compararlo con la publicación impresa real si está disponible ya sea en forma impresa o en otras bases de datos distribuidas.

20 Cuando el bloque y sus registros diarios hayan superado una inspección de este tipo, el Cliente puede, opcionalmente, enviar un registro de fecha y hora de "Bloque Confirmado" al Servidor, que creará un nuevo registro al final de la cadena de hash con referencia cruzada al registro Final de Bloque relevante y marcar un registro relacionado en una tabla externa con su última fecha y hora de confirmación.

Se requiere esa referencia a un "registro relacionado" ya que NO se permite modificar ningún registro en la tabla que mantiene la cadena de hash, ya que esto haría que cualquier verificación hash en el propio bloque fallara cualquier prueba de validación de bloque posterior. Pero no hay un riesgo significativo en ejecutar una tabla "externa" relacionada junto con la cadena de hash, cuyas propias entradas y estados cambiantes se pueden verificar por la cadena de hash, y que pueden mantener "metadatos" tan útiles como cuando el bloque fue confirmado la última vez. Ya está previsto que tales tablas relacionadas sean mantenidas no simplemente internamente, por el Servidor, sino externamente, por organizaciones que hacen su propio uso de la cadena de hash para verificar sus propios datos, tales como la propiedad, la fecha de vencimiento, los localizadores de recursos uniformes (URL) que se vinculan a cualquier dato que el autor desea hacer públicos, hasta llegar a los Libros de Registros Distribuidos completos del tipo ofrecido por las Cadenas de Bloques tal como Bitcoin.

La etapa final, de registrar la confirmación exitosa del bloque añadiendo un nuevo registro a la cadena de hash, cumple dos propósitos. El primero es registrar las fechas de confirmación de los registros de final de bloque en una tabla interna relacionada para que el Cliente pueda, si la Parte de Confianza lo permite, realizar una o dos pruebas aleatorias adicionales de confirmación de Bloque, con una preferencia algorítmica para aquellos bloques sin fechas de confirmación 0 aquellos con fechas relativamente más antiguas. Estas verificaciones adicionales añadirían quizás un minuto más o menos al tiempo de espera de confirmación de la Parte de Confianza (razón por la cual los Clientes no siempre lo permiten), pero realizan una tarea valiosa al obligar al atacante a cambiar grandes secciones de la cadena para mantener la impresión de que no está rota. Cada modificación forzada aumenta drásticamente la probabilidad de una detección rápida (por las Partes de Confianza o los Clientes que intentan confirmar esas otras partes de la cadena).

El segundo fin, sin embargo, es duplicar las mismas verificaciones de seguridad que se requieren para cualquier otra adición a la cadena; lo que significa que hemos verificado que el consenso entre pares es que el Servidor está funcionando normalmente y no está bajo un ataque actual, y nos aseguramos de que el Cliente tenga un punto final claro al que apuntar en la etapa final de verificación.

Pero incluso antes de eso, suponiendo que se hayan superado todas las pruebas anteriores, lo que ya se ha probado es lo siguiente:

1 Los Hashes de Datos siguen coincidiendo con el registro en la Cadena;

2 Todos los demás vínculos en el bloque del que forma parte siguen estando intactos, como todos los vínculos en cualquier otro bloque completamente probado;

3 Los bloques siguen conteniendo exactamente los mismos datos requeridos para recrear cualquier registro de confirmación de bloque;

4 El Registro de Confirmación del Día relevante sigue coincidiendo con los datos de confirmación de bloque reensamblados para el día;

5 El registro del Final del día sigue coincidiendo con la copia del Cliente y, sujeto a una verificación opcional, con la copia impresa; y

6 El Registro de Confirmación del día anterior se copia fielmente al primer registro del día siguiente.

Todo lo cual significa que si los Datos que estamos intentando validar han sido falsificados pero siguen superando las pruebas anteriores, solo hay tres formas en que esto podría ser posible. En primer lugar, y más fácil, es que el Cliente de la Parte de Confianza haya sido desviado para buscar en el servidor equivocado. Eso se puede evitar organizando la autenticación segura del Cliente basada en la inscripción adecuada, claves de un solo uso, etc., que son bien conocidas en el campo. Con recursos suficientes, el riesgo de ese tipo de desvío se puede eliminar virtualmente.

La segunda forma sería si el atacante hubiera conseguido falsificar toda esa sección de la cadena de hash y no confiara en que nadie más realizara validaciones en ningún otro dato registrado el mismo día (cuyo propio intento de validación fallaría inevitablemente y generaría una alarma - a menos que sus propios datos de la fuente relacionados hayan estado sujetos al mismo ataque simultáneo).

El argumento más fuerte en contra de esta posibilidad sería que la copia del Cliente del registro del Final del Día siga coincidiendo. Pero si el atacante, o su cómplice, que pasaron los Datos, a la Parte de Confianza, también lograron incluir algún malware adecuado, es posible que también hayan podido falsificar el Registro del Final del Día local. Solo verificando una versión impresa de una fuente segura, la Parte de Confianza podría eliminar esa posibilidad completamente, aunque se podría argumentar que la verificación cruzada de ese registro del Final del Día con una selección aleatoria de otros Pares proporcionaría una garantía casi equivalente y, con el tiempo, una verificación aleatoria de una muestra de registros certificados también podría proporcionar una garantía similar. En cualquier caso, claramente la probabilidad de que una falsificación supere estas pruebas ya sería mínima y, para la mayoría de los casos de uso, ese nivel de confirmación podría considerarse adecuado.

La tercera forma posible de falsificar la verificación en la medida descrita anteriormente sería reemplazar el propio software del cliente con una copia diseñada para lograr los resultados esperados por la Parte de Confianza. Mientras esta posibilidad no se puede descartar y podría funcionar contra una víctima ingenua, debería ser la más fácil de defender. En primer lugar, gran parte de las pruebas se pueden llevar a cabo manualmente y, si solo se realizan una o dos etapas de esa forma, aunque solo sea para eliminar esta posibilidad, la precaución sería suficiente. De manera más robusta, el cliente tendrá su propio hash registrado en la cadena y eso se puede verificar manualmente. Los parámetros del cliente podrían compararse aleatoriamente con cualquier otra copia del cliente para proporcionar todavía más seguridad. El cliente malicioso, por lo tanto, no se considera una amenaza grave.

Sin embargo, la probabilidad de falsificación se puede reducir aún más verificando todos los Registros de Confirmación del Día (prueba de vínculo simple) y los registros de Final del Día (contra la Copia del Cliente) entre la fecha de registro de Datos y el día actual. Eso no debería llevar más de otros de 10 a 60 segundos.

Tenga en cuenta que, arbitrariamente, cualquier cliente o usuario local, como se describe para la prueba de Bloque de Día, puede realizar más indagaciones opcionales en su ruta hasta el final de la cadena para realizar unas pocas pruebas arbitrarias más de bloque completo entre la fecha de Registro y fecha actual (por ejemplo, para confirmar hashes de datos certificados públicos). El atacante no puede saber qué partes de la cadena puede elegir para probar, por lo que para asegurarse de que su engaño tendrá éxito, necesitaría reemplazar toda la cadena simultáneamente, y esperar que nadie más se dé cuenta de los inevitables fallos de validación. Este es un ejemplo de lo que en el campo de la seguridad digital se denomina "inviable computacionalmente" (efectivamente imposible). El único inconveniente para el usuario es que cada una de tales pruebas aleatorias de Bloque/Día llevará otros 30 a 60 segundos.

Una vez que el Cliente ha llegado al Día Actual, la verificación de integridad está completa porque, en el proceso de añadir al menos un registro de fecha y hora de confirmación de bloque, la cadena ya se ha validado desde la medianoche (típicamente la hora de publicación para los registros del final del día) hasta ese nuevo registro. Suponiendo, por lo tanto, que esta verificación final confirme que el HASHJJNKED de medianoche sigue estando tal como se publicó, no es posible que ninguno de los vínculos en la cadena relacionado con los Datos que se están validando pueda haber cambiado desde que se registraron esos Datos y, por lo tanto, los propios Datos se han verificado concluyentemente como sin cambios.

Protección del servidor con la red de pares

Esta sección describe la nueva funcionalidad requerida para que la red P2P proporcione protección al Servidor. No es una descripción de una nueva forma de crear una red de este tipo, sino una nueva forma de usarla.

La función principal de la red P2P en relación con el Servidor es compartir datos entre los pares, con respecto al rendimiento y los tiempos de respuesta del Servidor, con el propósito de identificar cualquier demora o bloqueo significativo.

Esto se debe a que las modificaciones a la cadena de hash descritas anteriormente dejan solo una opción grave para que un atacante, con el control del Servidor, intente una falsificación. Dado que no pueden recalcular los hashes revisados, después de un ataque, relacionados con cualquier dato que no controlen, solo pueden tener éxito asegurándose de que SÍ controlan todos los datos cuyos hashes necesitarán cambiar durante cualquier ataque.

Esto tiene dos implicaciones. En primer lugar, que deben, durante la duración del ataque, evitar cualquier adición adicional a la cadena de hash de cualquier otra fuente; lo que, a su vez, significa que deben interrumpir el servicio normal y bloquear todos los envíos del Cliente desde esas fuentes. Detectar esa suspensión manifiesta del servicio normal es la función principal de la red P2P.

La segunda implicación es aún más tranquilizadora. Solo pueden atacar el final de la cadena, porque solo al final de la cadena pueden estar seguros de excluir los datos de la fuente que no controlan.

Por lo tanto, la supervisión P2P por sí sola impone un límite de tiempo muy estricto para cualquier ataque. Cualquier tiempo de respuesta superior al doble del promedio actual emitirá una alarma y, como los tiempos de respuesta normales deberían ser del orden de unos pocos segundos, el atacante comienza con muy poco tiempo para completar cualquier ataque. Por lo que, si los pares, colectivamente, pueden confirmar su capacidad para añadir nuevos registros (y recuperar los resultados de la cadena de hash) han probado que el servidor no está actualmente bajo ataque y que se puede seguir confiando en la cadena de hash. Además, incluso un cliente nulo (uno que no participa en la red P2P) puede lograr una garantía instantánea efectiva siempre que pueda verificar los detalles de CUALQUIER entrada pública certificada publicada después del HASH_LINKED real que buscan validar. Si esos detalles se confirman y confían en la fuente, y el vínculo entre el hash objetivo y el hash certificado sigue estando intacto, habrán justificado un alto grado de confianza en que los datos son lo suficientemente seguros como para confiar.

La segunda función de la red P2P es alojar todos los registros de Final del Día publicados en forma impresa y, opcionalmente, los Registros de Confirmación del Día. Principalmente, esto les da una forma mucho más fácil de confirmar los datos de cualquier día dado como se describió anteriormente. También se basa en el concepto de cadena de bloques distribuida de "fuerza en números" y la protección de datos digitales por el proceso de distribución generalizada.

Sin embargo, igual de importante es que alojando sus propias copias de los registros de Final del Día, cuando el cliente hace su selección aleatoria de uno de esos registros históricos HASHJJNKED para usarlo como HASH_PRIOR histórico, ningún atacante que controle el servidor puede adivinar cual han usado. Tendrían que probarlos todos. Y luego tendrían el problema aún más difícil de adivinar de cómo se combinó el pseudo-SALT resultante con la Fuente. Y, por supuesto, también necesitan acceso a la Fuente.

La tercera función es alojar tantos de esos nuevos registros añadidos en las últimas 24 horas (que incluye HASH_LINKED del Final del Día impreso más reciente) como deseen o puedan alojar. Esto tiene una lógica similar a la de alojar los registros de Final del Día (protección por distribución, ocultando la elección de1HASH_PRIOR reciente), pero también actúa como una copia de seguridad parcial del Servidor en caso de que sufra un ataque grave, no con el propósito de fraude, en el que se enfoca principalmente esta invención, sino con el propósito de interrumpir el servicio.

Por ejemplo, la red P2P podría proporcionar un servicio sustituto, aunque mucho más lento, cuando el Servidor estuviera bajo un ataque sostenido de Denegación de Servicio, al menos con el propósito de proporcionar la validación de los registros añadidos recientemente. Incluso podría ayudar al Servidor a reconstruir sus registros si un ataque significativo realmente consiguiera destruir datos recientes. (Los datos históricos deberían estar protegidos por el almacenamiento WORM distribuido).

La cuarta función es proporcionar una verificación periódica de la precisión del rendimiento de las Marcas de Tiempo del Servidor. El Servidor obtendrá o creará marcas de tiempo confiables que deberían ser tan precisas como cualquier otra en Internet. Sin embargo, un atacante podría ver una oportunidad de beneficiarse modificando las marcas de tiempo a su favor. Los Pares Clientes recibirán una biblioteca de autoridades de marcado de tiempo confiables y los usuarios tendrán la opción de añadir las suyas propias. Al comienzo de cualquier sesión con el Servidor, el Par solicitará marcas de tiempo de uno o más servidores de tiempo seleccionados aleatoriamente. Se repetirá la solicitud al finalizar la sesión. Proporcionará tanto su propia “opinión” del tiempo al servidor cuando comience la sesión, como comparará las Marcas de Tiempo en los HASH_LINKED consiguientes con los datos de tiempo que ha recopilado en otro lugar. Una variación significativa emitirá una alarma. De manera similar, el Servidor emitirá una alarma con el Par si los datos de tiempo del Par varían significativamente de los datos de tiempo propios y de otros Pares.

La quinta y última función que realizan los clientes P2P, sujeta a la aprobación de sus usuarios, es rastrear la cadena periódicamente, buscando bloques sin confirmar, o bloques que no han sido confirmados durante un tiempo, o, si todo ha sido confirmado recientemente, verificar bloques aleatoriamente en cualquier parte de la cadena, y realizar la prueba de confirmación de bloque descrita anteriormente en esos bloques, creando nuevos registros de “Bloque Confirmado” y actualizando sus fechas de confirmación.

Esta verificación externa continua en la cadena de hash proporcionaría un obstáculo permanente para cualquier atacante que intente alterar cualquier parte de la cadena sin ser detectado. Debería asegurar, incluso con solo unos pocos miles de pares, que la cadena se está probando al menos unas pocas veces por segundo, lo que reduce aún más la oportunidad de que cualquier ataque pase desapercibido en segundos.

Prueba del Tiempo de Creación de Dispositivos de Captura Digital Instantánea

Finalmente, esta sección describe un uso alternativo del HASH_LINKED para probar una ventana de tiempo estrecha en la que se deben haber creado ciertos tipos de datos. Mientras, en todos los casos, e1HASH_LINKED de un elemento registrado prueba su última hora de creación posible, es posible en un conjunto limitado de circunstancias también probar la primera hora de creación posible.

Este aspecto adicional de la invención permite a los Autores generar un alto nivel de confianza, acercándose a la certeza, con respecto a una ventana de tiempo exacta, y generalmente estrecha, en la que se creó un elemento de datos, siempre que se haya creado, efectivamente instantáneamente, por un dispositivo, tal como una cámara, con una versión personalizada del software del Cliente incluido, ya sea en el dispositivo o en un dispositivo de comunicación al que está conectado.

Esto implica vincular el HASH_LINKED disponible más reciente con los datos en el momento de su creación. En principio, cualquier hash reciente de la cadena servirá, aunque cuanto más reciente, mejor. Por lo tanto, la opción preferida siempre es usar el HASH_LINKED más reciente disponible.

El punto importante es asegurarse de que una imagen se vincule, en el momento de la creación, con un elemento de datos cuya propia fecha y hora se pueda asegurar matemáticamente como resultado de las operaciones descritas anteriormente.

Los fabricantes pueden desarrollar mecanismos superiores para explotar este concepto, pero una opción plausible es hacer que el software de la cámara cifre el espacio de archivo en el que la imagen está a punto de almacenarse usando el HASH_LINKED relevante como clave. Luego, tan pronto como la imagen esté completa, haga un hash y cargue el hash, inmediatamente, a la cadena de hash.

Siempre que la implementación de hardware de ese proceso sea probadamente segura (por parte del fabricante), entonces el autor estará en condiciones de probar que la imagen resultante no se pudo haber creado antes del primer HASHJJNKED que se descargó, o después del siguiente HASHJJNKED creado por la adición de su propio nuevo registro, dejando una ventana de oportunidad muy pequeña para manipular la propia imagen. Con secuencias de vídeo, la ventana de oportunidad es la misma para una secuencia completa de imágenes pero, dada la opción adicional de construir una cadena de hash interna para cada trama de la secuencia, se puede reducir drásticamente para una trama individual. En resumen, en una cámara modificada adecuadamente, la invención confiere una gran oportunidad para que los datos obtenidos de la cámara prueben su propia integridad más allá de toda duda razonable. Podría eliminar la posibilidad de que las imágenes hayan sido manipuladas (aparte de la propia cámara) antes de la publicación, dejando solo la posibilidad de que lo que revela la imagen no sea real porque fue "escenificado".

Para aquellos casos de uso donde la integridad de la imagen y la prueba de procedencia realmente importan (por ejemplo, periodismo fotográfico, cámaras de seguridad, cámaras de conducción, etc.), es muy probable que se cree una cadena de hash dedicada únicamente para la validación de imágenes.

Puede parecer contrario a la lógica descrita anteriormente que esto implique posiblemente miles de imágenes tomadas simultáneamente, todas usando el mismo HASH-LINKED. El uso compartido del mismo hash no es un problema, ni en este contexto, ni para datos normales (véase la referencia anterior a la reemisión de HASH_PREVIOUS pendientes).

Debería enfatizarse que el objetivo de usar el hash, en este caso, es solo para probar el tiempo de la fuente de los datos del Autor, no para proteger la cadena de hash; el punto crítico es que se puede probar la hora exacta de creación de ese HASHJJNKED y, por lo tanto, todas y cada una de las imágenes vinculadas con él pueden probar sus primeros tiempo de creación posibles.

Posteriormente, sus tiempos de carga individuales determinarán sus últimos tiempos de creación posibles demostrables. Además, para conservar la velocidad máxima en su cadena dedicada, las versiones de la Cámara del software del Cliente podrían prescindir de cualquier inclusión de Hash adicional y permitir que la "Cadena de Hash de la Imagen" obtenga su propia protección contra ataques internos almacenando registros periódicos (por ejemplo, uno para cada diez mil imágenes añadidas) en la "Cadena de Hash Estándar" usando el procedimiento HASH_SALTED completo.

Se apreciará que las realizaciones descritas anteriormente se dan únicamente a modo de ejemplo y que se pueden hacer diversas modificaciones a las mismas sin apartarse del alcance de la invención tal como se define en las reivindicaciones adjuntas. Por ejemplo, las realizaciones descritas implican la construcción de cadenas de hash por concatenación, pero se pueden contemplar otros ejemplos de construcción, por ejemplo por o exclusivo a nivel de bits, o típicamente XOR. Además, la cadena de hash descrita en la presente memoria es unidimensional, pero se anticipa a la necesidad - en el futuro previsible - de implementar el sistema descrito en lo que se puede denominar una Super Red de Pares. Una Super Red de Pares (SPN) aquí es aquella donde, esencialmente, toda la cadena de hash se configura como una base de datos de búsqueda y requiere la SPN con propósitos prácticos, principalmente accesos múltiples rápidos a gran escala donde los usuarios a menudo requerirán tiempos de respuesta en "tiempo real" (es decir, en no más de unos pocos segundos). Esto no excluye modelos de cadena de hash alternativos tales como Árboles de Merkle y Árboles de Hash Distribuidos (DHT), por ejemplo, que están optimizados para redes estándar de pares (p2p) pero que, típicamente, en la actualidad de 2017 requieren tiempos de respuesta mucho más prolongados (a veces minutos en lugar de segundos). Si la tecnología de la comunicación permite un aumento suficiente en el ancho de banda p2p, una opción alternativa sería cambiar a un sistema completamente de pares y lograr el mismo nivel de descentralización que reclama, por ejemplo, bitcoin. También se debería tener en cuenta que la SPN propuesta podría decidir por sí misma que algo como los DHT podrían ser la forma más eficiente de compartir los datos entre ellos. Siempre que esto se pueda hacer sin destruir la capacidad de vincular los datos y posteriormente verificarlos como se describe aquí, entonces tales métodos son completamente consistentes con el método y el aparato descritos en la presente memoria.

Claims

REIVINDICACIONES

1. Un método implementado por ordenador para permitir la validación de la integridad de los datos por referencia a una pluralidad de elementos de datos únicos, denominados HASHJJNKED, almacenados en una cadena de hash en al menos un dispositivo informático, en donde la cadena de hash se produce por las siguientes etapas:

(a) combinar al menos un HASH_LINKED ya registrado en dicha cadena de hash con una fuente de datos recién añadida y hacer hash a la combinación resultante para producir un nuevo hash, HASH-SALTED;

(b) almacenar el HASH_SALTED en un campo dentro de un nuevo registro en un almacén de datos digitales en el al menos un dispositivo informático, en donde el almacén de datos digitales es una tabla dentro de una base de datos; y (c) combinar, en un nuevo registro, cada nuevo HASH_SALTED con el HASH_LINKED más reciente y hacer hash a la combinación para producir un HASH_LINKED adicional almacenado en otro campo en el mismo nuevo registro, de modo que el HASH_SALTED más reciente y el HASH_LINKED adicional estén permanentemente vinculados por posición en la base de datos; y

las etapas (a) a (c) que se repiten en múltiples iteraciones, en donde después de cada repetición de la etapa (a), cada HASHj LINKED más reciente se combina con el siguiente HASH_SALTED y se hace hash para producir un HASHj LINKED siguiente almacenado en el mismo nuevo registro.

2. Un método según la reivindicación 1, en donde a intervalos periódicos se crea un registro adicional, REGISTRO DE CONFIRMACIÓN DE BLOQUE, haciendo hash a una combinación de un HASH_LINKED anterior y un archivo que contiene todos los registros creados desde el REGISTRO DE CONFIRMACIÓN DE BLOQUE anterior para crear un nuevo HASHj SALTED a almacenar en una posición predeterminada dentro de la cadena de hash almacenada; donde el valor del nuevo HASH_SALTED se combina con el HASH_LINKED más reciente en la cadena de hash para producir un nuevo HASH_LINKED más reciente almacenado en el mismo registro nuevo.

3. Un método según la reivindicación 1 o 2, que comprende además una etapa de verificación, en donde cada HASHj LINKED se verifica aleatoriamente en una o más de las siguientes formas:

(i) por agentes que buscan autenticar elementos de datos arbitrarios;

(ii) por agentes programados para realizar verificaciones aleatorias;

(iii) por agentes, tales como los miembros de una red de pares, que realizan verificaciones periódicas o aleatorias; o (iv) por agentes que añaden nuevos registros;

de modo que la verificación ocurra al menos con la misma frecuencia que las iteraciones de las etapas (a) a (c), y se emita un mensaje de alarma si la acción de verificación produce un resultado negativo.

4. Un método según cualquiera de las reivindicaciones 1 a 3, en donde un HASH_LINKED reciente en la cadena de hash se combina además con un elemento de datos creado instantáneamente, tal como una imagen digital, y se hace hash a la combinación resultante para formar un nuevo HASH_SALTED, que a su vez se usa para crear un nuevo HASHj LINKED en una o más cadenas de hash en la primera oportunidad disponible.

5. Un método según cualquiera de las reivindicaciones 1 a 4, en donde cada uno de dichos HASH_LINKED se incorpora al menos una vez en un HASH_SALTED posterior en la cadena de hash.

6. Un método según cualquiera de las reivindicaciones 1 a 5, en donde para cada uno de dichos HASH_SALTED la fuente de datos incluye además una cadena corta de datos aleatorios.

7. Un método según cualquiera de las reivindicaciones 1 a 6, en donde el conjunto de datos vinculados comprende un conjunto de datos concatenados.

8. Medios de datos grabados que comprenden un programa dispuesto para implementar las etapas del método de cualquiera de las reivindicaciones 1 a 7.

9. Un aparato que comprende

un dispositivo de almacenamiento que contiene una pluralidad de fuentes de datos,

una entrada a través de la cual el contenido de datos de las fuentes de datos se puede añadir al dispositivo de almacenamiento,

un procesador programado para llevar a cabo el método de cualquiera de las reivindicaciones 1 a 7.