9. Detalles de Implementaci´ on del Esquema de Seguridad Propuesto
9.4. Fortalecimiento de OLSR: Nivel 2
Tener autenticados y encriptados los paquetes de control pone al protocolo OLSR m´as s´olido pero a´un as´ı un nodo que permanece en la red durante un determinado tiempo podr´ıa realizar distintos ataques como el Ataque del T´unel y el Ataque de Reenv´ıo de Paquetes.
9.4.1.
Prevenci´on contra ataque Wormhole
Unos de los ataques analizados en la Secci´on 6.6 es el Ataque del t´unel (wormhole attack ) en donde un nodo utiliza los mensajes de HELLO generados en un sector de la red y los reproduce en otro, enviando dichos mensajes a trav´es de un t´unel externo a la red. Esto hace que una v´ıctima crea que el nodo atacante sea un nodo vecino pero en realidad se encuentra a varios
9.4.2. Prevenci´on contra ataque de reenv´ıo de mensajes: Timestamp
saltos de distancia. Este ataque genera una alteraci´on de la topolog´ıa de la red y el agresor con este comportamiento hace que todos los nodos cambien sus tablas de ruteo y lo utilicen a ´el como gateway hacia otro extremo de la red.
Este ataque se puede prevenir utilizando un mecanismo estad´ıstico/heur´ıstico [18, Sec. 4.4] teniendo en cuenta algunas caracter´ısticas del medio de f´ısico y de las interfaces de red. Teniendo en cuenta que las placas de red utilizadas hoy en d´ıa tienen un radio de cobertura R, por ejemplo m´aximo 100mts (este valor parametrizable en el protocolo) y suponiendo que la velocidad de propagaci´on de la se˜nal wireless c en el aire es cercana a la velocidad de propagaci´on de la luz en el vac´ıo, se puede calcular la distancia recorrida por un paquete como L = t× c. Entonces si se detecta que un paquete cumple con L > R, se esta en presencia de un ataque de t´unel y en caso contrario, no (L <= R).
La implementaci´on de este sencillo algoritmo consiste en el siguiente procedimiento: Durante el Procedimiento de Autenticaci´on, cuando B recibe el primer mensaje de A (Paso 1), B inicializa un contador y env´ıa la respuesta a A (Paso 2), cuando A le responde, B detiene el contador y env´ıa el mensaje a A (Paso 3). B calcula la distancia como S = (4tb/2)× c, si S > R, B no
pone a A como vecino confiable, en caso contrario y se completa satisfactoriamente el paso 4, B inserta a A como vecino seguro.
El procedimiento seguido por A es an´alogo, con la diferencia que A inicializa el contador en el Paso 1 antes de enviar el primer mensaje hacia B.
9.4.2.
Prevenci´on contra ataque de reenv´ıo de mensajes: Timestamp
Otro de los ataques analizados en la Secci´on 6.6 es el Ataque por Reenv´ıo de Mensajes, el cual consiste en grabar trafico de la red y reproducirlo en otro momento. Este ataque es posible porque los n´umeros de secuencias, son n´umeros de 16 bits, con lo cual en un corto plazo comienza desde cero nuevamente. Por esta vulnerabilidad es que no se puede garantizar la frescura (fresshness) de un paquete.Como soluci´on a este ataque, los paquetes de OLSR necesitan un nuevo mecanismo para vali- dar su frescura. Para esto se utiliza un timestamp de 32 bits en cada uno de los paquetes. Existen varias alternativas para la implementaci´on de timestamps. En [30, Sec. V] se proponen distintas alternativas de implementaci´on. En esta propuesta se utilizar´a la idea desarrollada en [21], la cual no depende de la sincronizaci´on de relojes y es un intercambio simple de mensajes.
La propuesta planteada en [21], consiste en un di´alogo para intercambiar los relojes de cada extremo. Para esto utiliza mensajes especiales.
En esta tesis se utilizar´a la idea de [21] pero no se utilizar´an mensajes especiales sino que el intercambio de relojes se llevar´a a cabo durante el proceso de autenticaci´on donde se agregar´a a los mensajes la hora de cada nodo (notar que la modificaci´on se hizo sobre los mensajes de autenticaci´on b´asicos y no sobre los detallados en el proceso de intercambio de claves del nivel 1 de securizaci´on). De esta manera, el nodo receptor del mensaje puede calcular la diferencia horaria y almacenarla en la tabla de vecinos. Para llevar a cabo este intercambio de debe modificar el mensaje AUTH MESSAGE para agregar un campo para el timestamp.
Detalles de Implementaci´on del Esquema de Seguridad Propuesto
1. A→ B : A, B, CertA, RA, T imeA, sign(H(A, B, CertA, RA, T imeA))
2. B→ A : B, A, CertB, RB, T imeBsign(H(B, A, CertB, RA, RB, T imeA))
3. A→ B : A, B, sign(H(A, B, RA, RB, T imeA, T imeB))
Se toma en cuenta un factor de error S (parametrizable con el protocolo) que determina una tolerancia para el c´alculo del timestamp. Cada paquete recibido tiene su propio timestamp. El nodo receptor extrae el timestamp del paquete y calcula la diferencia con su reloj calculando TN = Tlocal− Tpaquete. A continuaci´on eval´ua T0− S < TN y T0+ S > TN, donde T0 es la
diferencia horaria almacenada en la tabla de vecinos. En caso que la validaci´on del timestamp sea correcta se procesa el mensaje, en caso contrario se descarta.
Para compensar alg´un desfasaje de los relojes, se realiza un ajuste de T0calculando el promedio
entre la diferencia horaria almacenada y la calculada para este paquete (T0= (T0+ TN)/2).
Con la implementaci´on del timestamp, se modifica el mensaje de firma del paquete generado en el nivel 1 de securizaci´on ya que es necesario que el timestamp pertenezca a este mensaje para garantizar la frescura del paquete. El nuevo mensaje de firma (Figura 9.13) contiene el timestamp, el cual es parte de los campos a tener en cuenta en para la firma ya que es necesario que ese campo no sea alterado.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SCHEMA | ALGORITHM | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | TIMESTAMP | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SIGNATURE (160 bits) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figura 9.13: Formato del mensaje firma con timestamp
9.4.3.
Prevenci´on contra ataques de DoS
Uno de los ataques m´as comunes son los ataques de Denegaci´on de Servicio. Estos ataques pueden ser realizados de distantas maneras, por ejemplo un nodo malicioso o mal configurado podr´ıa enviar docenas de mensajes de autenticaci´on por segundo haciendo un desgaste de energ´ıa procesando el mensaje en el nodo receptor.
Una manera sencilla de mitigar este tipo de ataque es mantener un contador por cada direcci´on de origen que env´ıa un mensaje. Cuando el nodo recibe un mensaje de un determinado origen, guarda ese registro en una tabla e inicializa un contador. Si este nodo recibe m´as mensajes del nodo agresor en el lapso de tiempo en el cual en contador todav´ıa est´a activo rechaza el mensaje. Esta prevenci´on no tiene efecto si el nodo agresor realiza un spoofing de IP. En este caso el protocolo cuenta con un mecanismo de aceptaci´on de paquetes de manera estad´ıstica para no saturar el nodo. Se establecen umbrales que son configurables para el protocolo y en base a esos umbrales se calcula cuando comienza a atender de manera estad´ıstica.
9.4.4. Otros ataques mitigados
9.4.4.
Otros ataques mitigados
Con el solo hecho de la securizaci´on alcanzada en el Nivel 1, se pueden prevenir los ataques que involucran la modificaci´on de los paquetes como Generaci´on Incorrecta de Mensajes HELLO, Generaci´on Incorrecta de Mensajes TC, ya que ning´un nodo puede hacerse pasar por otro porque los nodos est´an autenticados. Otros ataques pasivos son mitigados porque nodos que escuchan el tr´afico no pueden interpretarlo ya que est´a encriptado.
9.4.5.
OLSR RFC 3226 vs. OLSR Seguro
Realizando una comparaci´on r´apida entre el protocolo original (RFC 3626) y el fortalecimiento propuesto, se puede ver que no se modifica el funcionamiento pero s´ı se agregan capas de seguridad y algunas modificaciones m´ınimas a las Etapa 1 (Censado y Descubrimiento de Vecinos) y la Etapa 2 (Elecci´on de MPR). En la Figura 9.14 se puede ver de manera esquem´atica como se ha empaquetado el protocolo original para hacerlo seguro.
Detalles de Implementaci´on del Esquema de Seguridad Propuesto