Flujo de Medidas y Árbol de Merkle

182

a los 35,14 segundos (Ver Figura 47) mientras que sin descarte ocurre a los 25,65 segundos (Ver Figura 48). Esto se sostiene en ambas figuras para toda la simulación.

Figura 48 Evolución de las Alarmas Disparadas y Transmisión de Datos durante 15 minutos con descarte y barreras temporales inactivas (Simulación 5)

Por esa razón sería probable que las transmisiones de datos sin descarte fueren mayores para periodos de tiempo más grandes. Sin embargo, este resultado es interesante porque permitiría omitir el descarte de medidas y utilizar transmisiones basadas en cambios en los datos para colaborar con la reunión central de medidas en APbMM ante potenciales limitaciones en la tasa de procesamiento.

183 Figura 49 Un típico árbol de Merkle

Como se puede apreciar en la Figura 49, la datos podría ser un conjunto de transacciones o un gran archivo separado en trozos o partes. La estructura de dato no contiene el dato en sí mismo sino su hash asociado. De este modo, cada hoja del árbol contiene el hash asociado con su trozo de datos, mientras que su padre contendrá el hash calculado a partir del hash de sus hijos. Por ejemplo, el nodo indicado con un número 4 en la anterior figura posee su hash calculado a partir de los nodos 8 y 9, y de este modo sucesivamente hasta alcanzar la raíz. El esquema de Merkle permite verificar la integridad del dato en un entorno distribuido a través de unas pocas operaciones basadas en el cálculo de hash, mientras que el resto de los datos no son requeridos. Por ejemplo, suponga que un gran archivo de datos es trozado en 8 partes y se distribuyen entre diferentes nodos de un cluster. Por alguna razón, se necesita verificar la integridad del trozo número 4 (Ver nodo 11 en Figura 49). Para ese propósito, el nodo correspondiente utilizará los hashes relacionado al nodo 10 (es decir, h(3)), 4 (es decir, h(1;2)), y 3 (es decir, h(h(5;6);h(7;8))). De este modo, mediante la comparación de h(h((h(3); h(4));h(1;2));3) con el hash de la raíz del árbol, se podría saber si el trozo de datos es válido o no en base a si emparejan o no sus huellas.

Como se introdujo en la sección 5.2.1, el formato Brief contiene una huella MD5 como encabezado del mensaje que permite verificar la integridad del mensaje (considerando las medidas y la definición del proyecto), pero nada dice sobre los mensajes previos (Ver Figura 25). En otras palabras, el adaptador de medición y la recolección de datos en PAbMM tienen un medio a través del cual es posible saber si un mensaje ha sido modificado o no aunque está limitado a un único mensaje.

Así, dado que el mensaje Brief contiene una huella MD5 como encabezado de mensaje, es posible utilizar esta como parte de un árbol de Merkle para mantener un seguimiento de un cierto número de transacciones pasadas, evitando tener que recalcular la huella del mensaje. Esto es útil tanto para el adaptado de mediciones para mantener un registro local de las ventanas de datos enviadas, como la función de recolección de datos de PAbMM para mantener un seguimiento de los datos recibidos desde estos.

184

De este modo, se introduce el empleo del árbol de Merkle para implementar un registro de longitud fija para verificar la integridad de las últimas 2ⁿ transacciones, donde

“n” representa la profundidad del árbol. Así, la profundidad del árbol depende del número de transacciones a mantener dentro del registro.

Figura 50 Un árbol de Merkle Orientado a Soportar un Registro de Longitud Fija para Verificación de Integridad

La Figura 50 describe la representación de un registro de integridad con una capacidad para almacenar las últimas cuatro transacciones. Las transacciones antiguas se localizan en el extremo izquierdo de las hojas, mientras que las transacciones recientes lo hacen en el extremo derecho. Cuando una transacción es incorporada, la transacción más antigua es descartada (es decir, el nodo 1 en la Figura 50) para dar su lugar al nodo que le sigue en antigüedad (nodo 2), quien se torna en el nuevo nodo más antiguo. Del mismo modo, el nodo 3 se torna en el nuevo nodo 2, el nodo 4 se torna en el nuevo nodo 3, y finalmente, la nueva transacción ocupará el slot 4. En este registro, las hojas no necesitan calcular su huella debido a que el MD5 viene dentro del encabezado del mensaje Brief. Sin embargo, los nodos intermedios hasta la raíz necesitan recalcular las huellas.

Este registro simplifica la verificación de integridad entre los adaptadores de medición (AM) y la función de recolección (FC) de PAbMM, permitiendo contrastar la historia reciente basado en la huella MD5 de la raíz del árbol. Es decir, AM y FC necesitan solo comparar las huellas MD5 para saber si existe integridad. Adicionalmente, es posible realizar verificaciones parciales a través de los nodos intermedios. Por ejemplo, la huella de las últimas dos transacciones se almacena en el nodo 3 (Ver Figura 50), y análogamente, contrastando el MD5 del nodo 3 con su respectivo de FC es posible verificar su integridad.

185

Dado que AM es un componente localizado en dispositivos con recursos limitados, el volumen de transacciones a monitorear dependerá de las capacidades del dispositivo.

Incluso, el volumen de datos a transmitir es típicamente alto en Internet de las Cosas, razón por la cual el registro es inicializado en el arranque y mantenido en memoria hasta que el dispositivo se apaga. Así, durante el booteo se crea un árbol binario denso y se deja listo para ser empleado con las transacciones basadas en mensajes Brief.

La implementación del árbol de Merkle basada en un arreglo unidimensional se encuentra disponible en el repositorio mair de GitHub bajo los términos de la licencia Apache 2.0. La librería se denomina mair como acrónimo para la expresión en ingles de Registro de Integridad del Adaptador de Medición (en inglés, Measurement Adapter Integrity Record). Allí se incorpora tanto la perspectiva local al AM como la global para articular la FC con un conjunto de AM.

Figura 51 Clases Principales Relacionadas a la Librería MAIR

La Figura 51 describe las principales clases asociadas con la librería MAIR, dentro de las que se encuentran a) TreeNode: representa la estructura de datos mínima donde la huella es almacenada; b) BDTree: implementa la lógica del árbol de Merkle como un arreglo unidimensional a partir de un conjunto de instancias de TreeNode. El atributo

186

md5 es una instancia de la clase java.security.MessageDigest, mientras que el atributo levels se establece como valor por defecto para la profundidad del árbol; c) MAIntegrityRecord: implementa el registro de integridad en el adaptador de medición.

Se emplea una instancia de la clase BDTree para mantener un seguimiento de las transacciones informadas; d) ProjectIntegrityRecord: Implementa el registro de integridad por proyecto. Dado que un proyecto puede contar con un conjunto de AM asociados, una tabla hash utiliza el ID del AM para acceder a su árbol de Merkle asociado;

e) GlobalIntegrityRecord: Implementa el control de integridad a nivel global (múltiples proyectos). Por ellos, se emplea una tabla hash utilizando el ID de proyecto como clave de acceso a su registro de integridad.

En particular, la clase MAIntegrityRecord contiene un atributo currentRole que representa el último rol conocido para el adaptador que es representado. En esta clase, las principales responsabilidades pueden sintetizarse como sigue:

• addTransaction: Incorpora un nuevo hash al registro de transacciones, provocando un desplazamiento a la izquierda de los antiguos registros para generar el espacio necesario (descarta el más antiguo si fuere necesario).

Actualiza las huellas encadenadas en forma jerárquica a lo largo del árbol hasta alcanzar la raíz. Finalmente, el rol actual del AM es actualizado (es decir, gateway, blocked, cooperative, o data collector).

• hasWholeIntegrity: El método compara la integridad global del registro. Por esa razón, compara la huella que se recibe como parámetro con la localizada en la raíz del árbol para saber si emparejan o no. Cuando las huellas emparejan, se dice que ambos registros tienen integridad. De otro modo, existe una diferencia independientemente del origen de la misma.

• verifyIntegrityFirsts: El método permite comparar la integridad de un subconjunto de transacciones comenzando desde el más antiguo (es decir, de izquierda a derecha en la Figura 50). Se compara la huella relacionada con los nodos intermedios que contienen los 2^levels transacciones con la huella indicada como un parámetro para saber si empareja o no. Cuando las huellas comparadas coinciden, se dice que el conjunto de 2^levels transacciones tiene integridad entre registros. De otro modo, alguna transacción entre las comparadas contiene una diferencia, aunque no focaliza en saber cuál es su origen.

• verifyIntegrityLasts: El método es similar al anterior, solo que el presente se focaliza en el subconjunto de transacciones comenzando desde la más reciente (es decir, de derecha a izquierda en el árbol de la Figura 50). Así, se compara la huella relacionada con el nodo intermedio que contiene las últimas 2^levels transacciones contra la huella indicada como parámetro para saber si

187

emparejan. Cuando las huellas comparadas emparejan se dice que los registros poseen integridad. En caso contrario, los registros no poseen integridad sin interesar en este punto el origen de la diferencia.

• verifyTransactionIntegrity: Este método contrasta dos huellas de diferentes registros para una misma transacción. Así, cuando las huellas coinciden, se dice que la transacción tiene integridad y corresponde al mismo contenido en ambos registros.

El rectángulo en la Figura 51 indica la funcionalidad que reside en el adaptador de medición. El resto de las clases no contempladas corresponden al registro de integridad global utilizado en la PAbMM. Las funcionalidades de los métodos son las mismas, cambian los parámetros debido al nivel de granularidad que se gestiona.

De este modo, el adaptador de medición puede mantener un seguimiento de cada ventana de datos transmitida hasta un tamaño dado. El tamaño del registro de integridad dependerá de las capacidades del hardware en el que se ejecuta. Así, AM se torna en un nuevo lugar donde la función de recolección puede verificar la integridad de las ventanas de datos recibida a través de un simple contraste de huellas.

Adicionalmente, es útil para ser utilizado como verificación de segundo factor, dado que independientemente la ventana de datos que se reciba en PAbMM, éste podría verificar contra AM la huella de su raíz para saber si el mensaje fue modificado.

Figura 52 Paquetes Necesarios para Implementar la Relación entre el Mensaje de Datos Brief y el Registro de Integridad de PAbMM

188

La Figura 52 sintetiza las librerías utilizadas por PAbMM para implementar el mensaje de datos Brief guiado por metadatos conjuntamente con el registro de integridad. En este sentido, los puntos en común entre las librerías residen en la definición del proyecto (es decir, la librería cincamipd) el cual establece los conceptos a monitorear y el modo en que se cuantifica cada atributo o propiedad de contexto. La librería cincamimis es reposnable por generar y leer el mensaje de intercambio (sea como XML, JSON, o Brief).

La clase Synthesizer implementa el cómputo de huellas MD5 desde el contenido del mensaje para producir el MD5 articulando la definición del proyecto y mensaje con las medidas.