7.1 Pairwise Mergesort
7.1.2 Algorithm Analysis
Se le llama volumen de seguridad al espacio en memoria persistente (flash externa) que se utiliza para almacenar el material criptogr´afico del protocolo seguro de reprogra- maci´on. El material criptogr´afico es la llave p´ublica para verificar la firma, y la llave sim´etrica global que protege la confidencialidad.
imagen de c´odigo de actualizaci´on (hay que recordar que la implementaci´on de Deluge soporta reprogramar varias im´agenes de programas). El tama˜no de este espacio es de 64 kilo bytes, el cual es mucho espacio para almacenar menos de 100 bytes de las dos llaves.
Lo que se ide´o para utilizar todo este espacio sobrante, es almacenar adem´as la estructura DescriptorNodo (estructura usada para reiniciar el nodo con otro programa), la cual antes se almacenaba en la memoria flash interna (de solo 128 bytes). A raz´on que en memoria flash externa no se puede sobreescribir un mismo espacio de memoria (al menos que se borre todo), y adem´as la estructura DescriptorNodo cambia con relativa frecuencia. Al momento de recibir otra versi´on de la estructura, no se sobre escribe el mismo espacio de memoria, sino que se va escribiendo el siguiente espacio de memoria del volumen.
Adem´as, ya que se protege que el comando de reinicializar el nodo y cambiar pro- grama solo lo pueda dar la estaci´on base, junto con la estructura DescriptorNodo se va a guardar su firma. Para mayor claridad del contenido del volumen de seguridad v´ease la Figura 25.
Figura 25: Organizaci´on del volumen de seguridad. N´otese que primero van las llaves criptogr´aficas.
IV.8
Conclusiones
En este cap´ıtulo se muestra la implementaci´on realizada tomando como base un me- canismo de reprogramaci´on existente, el cual fue Deluge, se pudo comprobar que los objetivos principales pod´ıan adecuarse a un mecanismo de reprogramaci´on ya imple- mentado y bastante probado.
Durante el transcurso del cap´ıtulo se observa que se le tuvieron que hacer modifica- ciones importantes a la estructura de mensajes, almacenamiento de la meta informaci´on e intercambio del mensajes del protocolo, esto con el fin de apoyar los cambios de se- guridad. Sin embargo la esencia del protocolo quedo intacta.
Una vez que ya se explico los cambios y nuevos mecanimos de seguridad propuestos en el protocolo de reprogramaci´on, el siguiente cap´ıtulo se da un an´alisis de seguridad de la propuesta, con el fin de justificar como estos mecanimos propuestos cumplen en realidad con los objetivos particulares que queremos asegurar en el proceso.
An´alisis de la seguridad de la
propuesta
Con el prop´osito de validar que la propuesta cumple con los objetivos particulares y adem´as ofrece robustez en contra de posibles ataques, a continuaci´on se describe el an´alisis de la seguridad del protocolo de reprogramaci´on. Resumiendo de los objetivos particulares del Cap´ıtulo 1, surgen los siguientes puntos a que se deben justificar, los cuales se presentan en la Tabla III (se dedicar´a una secci´on para discutir cada punto):
Tabla III: Objetivos particulares de la propuesta agrupados en puntos a justificar
Punto Objetivo Particular a justificar
Autenticaci´on en los nodos sensores que el c´odigo de actualizaci´on en realidad proviene de la estaci´on base
AS-1
Verificar en los nodos sensores que el c´odigo de actualizaci´on no fue modificado al llegar o transitar por ellos
AS-1
Evitar que paquetes maliciosos se sigan propagando por la red mediante el protocolo de reprogramaci´on
AS-2
Proteger la confidencialidad del c´odigo de actualizaci´on contra agentes externos a la red
AS-3
Limitar posibles ataques de negaci´on de servicios inherentes al protocolo de reprogramaci´on
AS-4
Autenticaci´on del mensaje de reinicializaci´on del nodo al nuevo c´odigo de actualizaci´on por medio de la estaci´on base
AS-5
Existe un punto adicional, que se podr´ıa enumerar como el n´umero 6 (AS-6) el cual no se describe en la Tabla III. La raz´on por la que no se incluye en la Tabla III es que no forma parte de ning´un objetivo particular planteado. Sin embargo, es necesario discutir este punto como parte del an´alisis de seguridad. A continuaci´on se discute cada uno de estos puntos.
V.1
Autenticaci´on y verificaci´on del c´odigo de ac-
tualizaci´on mediante la estaci´on base (AS-1)
En la propuesta, la autenticaci´on del c´odigo de actualizaci´on por parte de la estaci´on base, est´a basada en la fuerza del algoritmo de cifrado asim´etrico ECC, del cual no se ha reportado un ataque de fuerza bruta viable. Ya que los ataques de fuerza bruta no son viables, la ´unica soluci´on para el atacante seria obtener la llave privada que solamente radica en la estaci´on base. Sin embargo, una de las suposiciones que se tiene en la propuesta es precisamente que la estaci´on base no se puede comprometer.Los nodos de la red solo conocen la llave p´ublica de la estaci´on base, por ende pue- den verificar la firma digital. Sin embargo, no pueden modificar los datos firmados ya que para eso se necesita la llave privada. Como resultado un atacante que comprometa a uno de los nodos de la red, no es capaz de inyectar o modificar el c´odigo de la actua- lizaci´on.
El requerimiento de integridad es alcanzado por la resistencia del algoritmo de hash SHA-1 a ataques pre-imagen. Se han reportado ataques contra SHA-1 (Wang et al., 2005), sin embargo estos ataques no son directamente aplicables para nuestra propuesta, ya que solo encuentran una colisi´on (un mismo valor hash para dos datos de entrada diferentes) entre dos datos de entrada cualesquiera.
La estaci´on base utiliza una firma digital para autenticar el valor hash ra´ız de la estructura hash h´ıbrida y los metadatos del c´odigo de actualizaci´on. Este valor prote- gido por la seguridad de la firma, sirve a su vez para empezar una protecci´on hacia los dem´as valores hash del c´odigo de actualizaci´on. Esta protecci´on se dispersa primero a la cadena hash (indirectamente a las p´aginas), para que despu´es cada eslab´on de la
cadena disperse la seguridad hacia los valores hash del ´arbol de su p´agina, llegando por ´
ultimo a los paquetes de datos.
Suponiendo que el atacante quiere inyectar su propio c´odigo de actualizaci´on, la so- luci´on ser´ıa inyectar el primer mensaje de la diseminaci´on de la actualizaci´on, es decir el mensaje NuevaImagen. Si logra que los nodos acepten su mensaje de NuevaImagen, el atacante puede inyectar cualquier c´odigo de actualizaci´on que le plazca. Sin embargo, para lograr que los nodos receptores acepten este mensaje, ser´ıa necesario forjar la firma digital de la estaci´on base ya sea por un ataque de fuerza bruta (el cual no es viable), o consiguiendo la llave privada (la cual solo tiene la estaci´on base, misma que no se puede comprometer).
Si en cambio el atacante quisiera inyectar un paquete malicioso de hash o de da- tos, lo que tendr´ıa que hacer es encontrar un contenido de paquete que d´e un valor hash igual al que est´a asociado a ese paquete. La dificultad para el atacante aqu´ı ser´ıa, aparte de encontrar un contenido de bytes que de un mismo valor (a esto le lla- man una colisi´on), el contenido debe ser tal que tenga un significado ´util para el ataque.
Aunque los valores hash de los cuales se constituyen la estructura ´arbol son de 10 bytes, por consecuencia m´as factibles de encontrar colisiones, el atacante aun tiene que encontrar colisiones que tengan un significado ´util de ataque. Adem´as, aunque logre encontrar colisiones ´utiles para cada elemento del ´arbol de una p´agina, al llegar al elemento de la cadena, este si es de 20 bytes (seguridad completa), el cual hoy en d´ıa requerir´ıan de cantidades masivas de c´omputo y tiempo (a˜nos) para poder encontrar la colisi´on.