6.2 Searching in Shared Memory
6.2.1 Naive Binary Search
Para entender mejor la necesidad de modificar el ´arbol y estos valores de Deluge, se tiene que ver que pasar´ıa si se no se modificaran.
Deluge cuenta originalmente con p´aginas de tama˜no de 1104 bytes, este valor resulta de establecer un tama˜no de carga ´util de datos por cada paquete en 23 bytes y contar con 48 paquetes de datos de c´odigo por p´agina. Si se usara un ´arbol binario como lo sugieren en (Deng et al., 2006) (en cada nodo padre el ´arbol binario contiene los dos hash de sus nodos hijos), y una carga ´util de datos el doble que lo original a 46 bytes, resultar´ıa el ´arbol de la Figura 12.
Figura 12: ´Arbol binario resultante de una p´agina de Deluge, con una carga ´util de paquetes de datos de 46 bytes. N´otese que se necesitan 46 valores hash de 4 bytes cada uno.
el algoritmo SHA-1 (20 bytes), se tendr´ıa un ´arbol de 940 bytes (son 47 valores hash, contando al del nivel 0), el cual es excesivo comparado con un tama˜no de p´agina de 1104 (85% deoverhead por p´agina). Adem´as, se pierde la propiedad que todas las hojas est´en en el mismo nivel del ´arbol.
Si en cambio, se dejara el tama˜no de la carga ´util de datos como esta originalmente a 23 bytes, pero reduciendo el tama˜no del valor hash a 4 bytes como lo hacen otros (Deng et al., 2006) y (Dutta et al., 2006), se tendr´ıa un ´arbol de 390 bytes (35% de overhead). Aparentemente, la segunda configuraci´on es mejor que la primera de 85%, sin embargo tener valores hash de tama˜no de 4 bytes podr´ıa no ofrecer un grado de seguridad aceptable.
IV.3.2
Metodolog´ıa de encontrar una nueva configuraci´on de
´
arbol hash
Por lo discutido en la secci´on anterior, se tuvo que buscar alguna otra configuraci´on de ´
arbol, la cual cumpliera las siguientes condiciones:
• Overhead por p´agina los m´as bajo posible, ya que entre m´as grande sea el pa- quete existe m´as probabilidad que se pueda corromper a causa de un error en la transferencia.
• Mayor seguridad en referencia al tama˜no de los hash, ya que entre m´as grande sea el tama˜no del valor hash, un atacante requiere de un mayor n´umero de com- paraciones para encontrar el inverso del valor hash.
• El n´umero de hijos por nodo padre debe ser razonable, ya que entre m´as hijos tenga un nodo del ´arbol, se tienen m´as valores hash, haciendo dif´ıcil que quepa en un paquete y dificultando tambi´en su verificaci´on.
Las variables con las que se trabaj´o para encontrar una configuraci´on aceptable son las siguientes:
• Tama˜no de la carga ´util de los paquetes de datos del c´odigo de una p´agina.
• N´umero de paquetes de datos de c´odigo por p´agina.
• N´umero de hijos por nodo padre del ´arbol.
• Tama˜no del valor hash.
• Operaci´on para unir los valores hash de los hijos en el padre. En (Denget al., 2006) (Laniganet al., 2006) y (Duttaet al., 2006) se usa la operaci´on concatenaci´on, es decir, el nodo padre tiene todos los hash de los hijos concatenados, lo cual permite verificaci´on inmediata de cualquier hijo sin esperar a que lleguen los dem´as. La otra operaci´on ser´ıa que el padre hiciera un XOR binario de todos los hash de los hijos, el XOR permite que el tama˜no del padre sea solo de un valor hash, pero se tiene que esperar a tener todos los hijos para poder verificarlos a todos.
IV.3.3
Configuraci´on final de ´arbol hash
Basado en la metodolog´ıa anterior, se encontr´o una configuraci´on de ´arbol la cual cumple todas las condiciones y adem´as genera un overhead de p´agina aceptable. El ´arbol resultante es el de la Figura 13. Las instancias de las variables fueron las siguientes:
• Un tama˜no de carga ´util de 70 bytes, este valor, aunque m´as grande del que estaba originalmente (23 bytes), est´a lo suficientemente por debajo del l´ımite permitido por TinyOS (102 bytes), estar por debajo del l´ımite de TinyOS garantiza de alguna manera que no es un tama˜no de paquete tan grande que sea dif´ıcil el ser recibido sin errores de bits frecuentes.
• El n´umero de paquetes de datos de c´odigo por p´agina se instancia en 15, lo cual genera un ´arbol m´as peque˜no y por ende menos valores hash por ´arbol. Adem´as junto con los 70 bytes de carga ´util del paquete de datos, resulta un tama˜no de p´agina de 1050 bytes, el cual es muy parecido al tama˜no de p´agina original (1104 bytes).
• En cuanto al n´umero de hijos por nodo padre, se tienen instancias diferentes por cada nivel. En el nivel 1 se tienen 3 hijos por nodo padre, y en el nivel 2 se tienen 5 hijos por nodo padre.
• El tama˜no del valor hash se trunca de 20 bytes a 10 bytes, lo cual ofrece mayor seguridad que las anteriores propuestas (4 bytes).
• La operaci´on de uni´on de los nodos hijo con el padre utilizado es la concatenaci´on, lo cual ofrece verificaci´on inmediata de los nodos hijos.
Esta configuraci´on de ´arbol elegido solo necesita de 19 valores hash de 10 bytes cada uno, lo cual genera un overhead de p´agina de tan solo 18%, lo cual esta m´as aceptable para el esquema de reprogramaci´on de redes de sensores.
Tambi´en hay que tomar en cuenta que por cada p´agina, aparte de los valores hash del ´arbol, existe tambi´en el valor hash de la cadena hash. El tama˜no de este valor hash no se truncar´a, qued´andose como un valor hash completo SHA-1 de 20 bytes, el cual tiene la suficiente protecci´on para cualquier ataque de fuerza bruta conocido hasta la actualidad. Por lo tanto el total de bytes de valores hash por p´agina queda de 210 bytes, dando un overhead de p´agina final de 20%.
En conclusi´on de esta secci´on, se adopt´o el esquema de hash h´ıbrido de Denget al. (2006) para la protecci´on de la autenticidad e integridad del c´odigo de actualizaci´on.
Figura 13: ´Arbol binario que se utiliz´o en para el protocolo seguro aqui propuesto. N´otese que solo se utilizan 19 valores hash de 10 bytes cada uno.
Sin embargo, se realizan algunas modificaciones a la configuraci´on del ´arbol hash y del protocolo de reprogramaci´on, para obtener un esquema con un menoroverhead de hash por p´agina, el resultado es el ´arbol de la Figura 13, el cual genera un overhead de solo 20%.