Comunicación con iframe cross-domain bidireccional

Publicado el 8 noviembre, 2011 por edu

La idea es, ya que no podemos acceder directamente al iframe desde otro dominio, utilizar un “controlador” alojado en el mismo dominio del origen del iframe para que pueda conversar con él. Este controlador, a su vez, monta un iframe con vuelta hacia el dominio padre para que pueda enviarle posibles respuestas desde el dominio hijo.

De esta forma, desde domain_A, podemos utilizar el src de controller_iframe_A para “enviar” instrucciones en el hash de su url. Estas instrucciones son recibidas por controller_iframe_B que utiliza hashchange para detectar cambio de hash. El controlador utiliza esa instrucción hash que es ejecutada mediante eval(). Al encontrarnos ya en domain_B, dicha instrucción puede acceder al contents() de cross_iframe, para afectar, a nivel javascript, a todo su árbol DOM. Hasta aquí, todo el camino es recorrido “hacia abajo” hasta el iframe origen afectado por cross-domain.

Si ahora deseamos poder “afectar” desde dicho iframe a elementos de nuestra working_page, nos volvemos a encontrar con el problema de cross-domain. Para llegar hasta arriba, volvemos a utilizar la misma técnica en dirección contraria. Esta vez, utilizamos un iframe oculto en nuestro controlador, con src en domain_A, y modificable desde el controlador controller_iframe_B. Las instrucciones de respuesta se presentan ejecutables a working_page, que únicamente debe llegar hasta su top, recorriendo el parent del parent.

Caso de uso

Supongamos que las dos líneas que aparecen son simples divs. Queremos hacer la línea del iframe en domain_b un elemento clickable que al ser pulsado, cambie el color de “click_aqui”, situado en domain_a.

Así, utilizando el “src” del iframe en domain_b:

document.getElementById("iframeSource").src="sourceOfIframeInB#"+instruction;

donde instruction = “$('#iframeCrossDom').contents().find('div').css({'cursor':'pointer'}).click(function(){exeCrossDom(\"$('#buttonhash', window.parent.parent.document).css({‘color’:’#ff0000’});\");});”

El controlador está a la escucha del hashchange de ese iframe, ya en domain_b, e implementa una función exeCrossDom que permite enviar instrucciones de vuelta, al return_iframe del dominio A:

Estos controladores, montados en ambos lados, y con pequeñas diferencias, utilizan el hashchange:

$(window).bind("hashchange", function(){
if(location.hash != ""){
eval(location.hash.substring(1));
this.location.hash = "";
}
});

Publicado en html5, javascript, jquery, web develop | Deja un comentario

SACAR 11 – Seguridad en redes VANET bajo protocolo 802.15.4

Publicado el 2 noviembre, 2011 por edu

Al trabajar con redes de comunicación inalámbricas nos enfrentamos con problemas de seguridad que pueden comprometer al sistema. Al igual que en una red tradicional de comunicación, los requisitos de seguridad en una VANET son los siguientes:

- Confidencialidad: Propiedad de la información por la que se garantiza que está accesible únicamente a personal autorizado.
- Integridad : Propiedad de la información por la que se garantiza que ésta no se ve alterada o modificada por personal no autorizado.
- Disponibilidad: Propiedad que asegura y garantiza al usuario el uso del sistema en cualquier momento determinado.
- No repudio: No se puede negar la autoría.


 No obstante, las características que imponen las redes VANET en cuanto a topología dinámica, falta de procesamiento centralizado, … etc. dificultan el cumplimiento de estos requisitos de seguridad. La política de seguridad a aplicar en un entorno ad-hoc dependerá, en gran media, de la aplicación y del escenario concreto para los que se realiza el despliegue de la red.Las propuestas de seguridad deben adaptarse a las necesidades específicas que surgen en el planteamiento de una u otra red de comunicación. Para nuestro caso, redes VANET definidas sobre la teoría de redes ad-hoc, estas políticas de seguridad deberán cubrir básicamente cuatro requisitos: control de acceso a la red, sistema de detección de intrusos (SDI), seguridad de los protocolos de encaminamiento y servicios de gestión de claves. 

Estas políticas de seguridad deberán ser lo suficientemente robustas como para garantizar que un posible atacante sea incapaz de comprometer el sistema, entendiendo el papel de atacante como cualquier individuo o equipo que realice alguno de los siguientes ataques básicos (principalmente)

Ataques básicos :
- Falsificación de la información : El atacante difunde información falsa o errónea para que afecte al resto de los vehículos.
- Manipulación de la información del sensor: Modificar su posición, dirección, velocidad, etc. para escapar de ciertas responsabilidades por ejemplo, haber provocado un accidente.
- Denegación de servicio: utilizar un inhibidor de frecuencia para conseguir que un vehículo no reciba ninguna señal de su entorno en una cierta zona.
- Falsificación de identidad.
- Rastreado de vehículos: Seguir la pista de un vehículo infectándolo con algún virus que monitorice el estado de dicho vehículo.

Al igual que ocurre en redes tradicionales, las VANETs no quedan exentas de intrusiones externas y, por lo tanto, es necesario establecer un mecanismo de control de acceso a la red y sus servicios. Ante un ataque en el que un intruso acceda a los servicios de la red puede derivar en consecuencias catastróficas ya que, en las VANETs, los nodos asumen tareas de gestión y encaminamiento, dado que no existe una entidad central que asuma dicha responsabilidad. De esta forma, un intruso puede desviar el tráfico durante el encaminamiento o tener acceso a claves de identificación.

Tanto en la capa de red como en la de aplicación es necesario llevar a cabo un control de acceso que impida que un nodo sin autorización sea capaz de recibir o encaminar información (nivel de red) o que pueda acceder a servicios críticos como sería el de gestión de claves (nivel de aplicación).

Así pues, parece determinante ofrecer una política de control de acceso robusta. Veamos más detenidamente este aspecto.

Control de acceso

A través del control de acceso, un usuario puede acceder a la red y sus servicios tras un proceso de identificación y autorización. La forma en que se realiza este tipo de procesos depende en gran medida de las características de la red. Así, existen redes ad-hoc en la que los servicios de autenticación se encuentran centralizados, mientras que en otras redes estos servicios se encuentran distribuidos. Esto supone la aplicación de unos u otros mecanismos de control de acceso. Si elegimos un mecanismo de control de acceso distribuido para la red, será necesario un control de acceso basado en certificados digitales y autoridades certificadoras. En otros esquemas con servicios centralizados se requiere una autenticación basada en usuario y contraseña. Es muy útil hacer un estudio previo de las necesidades de seguridad de la red a desplegar, de esta forma, se podrán adecuar los mecanismos de control de acceso a la red.

Como primera línea de defensa, el control de acceso es una buena alternativa, sin embargo, debemos buscar soluciones en caso de que esta barrera se vea comprometida. Así, los sistemas de detección de intrusos (SDI) podrían protegernos en caso de que un individuo no autorizado accediera a la red.

Para las redes VANETs, se presentan varias propuestas SDI, veamos las más interesantes:

(SDI) Sistemas de detección de intrusos

Una solución basada en arquitecturas distribuidas y cooperativas para la detección de intrusos, es la que se propone en [YZWL 2000]. En este sistema, un agente de monitorización SDI lanzado en cada nodo monitoriza todas las actividades locales que ocurren a su alrededor. Si el SDI detecta una intrusión a partir de las trazas locales inicia un procedimiento de respuesta. Si se detecta una anomalía pero que no hay evidencias formales de la intrusión se usa un protocolo cooperativo con los vecinos para determinar si la intrusión tuvo lugar o no.

Otra alternativa, contemplada en [OKRG 2002], también presenta un SDI distribuido pero optimizado para las redes VANET. En este caso, cada nodo no ejecuta un agente de monitorización y control, sino que ofrecen el paso y alojamiento de agentes móviles -entidades software autónomas, ligeras y dinámicamente actualizables- que son capaces de desplazarse por la red y ejecutarse en ciertos nodos, de forma que minimizan el uso de los recursos, que en este tipo de redes suele ser limitado (ancho de banda, capacidad de proceso de los nodos…).

Es por ello que el empleo de técnicas de SDI debe realizarse previo estudio de las características de la aplicación y del escenario en el que ésta vaya a ejecutarse, debido a la sobrecarga que estos mecanismos pueden introducir, en términos de procesamiento, transmisión y almacenamiento en nodos. Si los requisitos de seguridad exigen fuertes técnicas de control y detección, y si los nodos disponen de suficiente capacidad y autonomía para soportar un SDI, entonces la elección y aplicación de este mecanismo de seguridad es justificable.

Cifrado y firmas digitales

Si optamos por utilizar técnicas de cifrado y firmas digitales como mecanismo de seguridad, tendremos que hacer uso de claves criptográficas. En esta situación, las claves criptográficas deberán ser compartidas entre los nodos y debe ofrecerse un mecanismo para gestionar dichas claves.
En este sentido, nos encontramos ante dos posibles configuraciones de nuestras redes VANET. Podemos permitir que nuestra propia red gestione de forma autónoma las claves, en cuyo caso nos encontraríamos con VANET auto organizadas; o bien podemos delegar dicha gestión a una entidad externa de confianza para la gestión de estas claves, VANET con gestión de claves externa.
En esquemas de VANETs pura, sin red de respaldo, es m´s apropiado usar un esquema de gestión de clave que no depende de ninguna entidad externa. En cambio, si se dispone de una red de respaldo, se puede optar por esquemas de tipos centralizados.
Las soluciones las mas populares son:

Para una red VANET pura:
- Gestión de claves en cadena de certificados.
- Gestión de claves basada en movilidad.

Para un red VANET híbrida:
- Autoridades de certifiación distribuídas.
- Gestión paralela de claves.

Gestión de claves en cadena de certificadosCada nodo genera su certificado, se distribuye y se almacena en cada
nodo de la red. Si un nodo deja de fiarse de otro nodo, se puede pedir una
renovación del certificado. Del mismo modo, si un nodo sospecha que su clave privada ha sido comprometida, puede revocar su propio certificado y generar otra clave privada.Gestión de claves basada en la movilidad 

Se basa en un esquema de distribución peer-to-peer de las claves de los nodos basada en la movilidad de cada nodo. Se transmite una clave a un nodo según la movilidad que tiene en un momento para que este nodo distribuya las claves a los nodos a su alcance. Se rompe así la necesidad de tener una entidad externa para compartir las claves.

Autoridades de certificación distribuidas

Se basa en una entidad externa de certificación que se encarga de distribuir las claves a los nodos de la red. Esta entidad debe ser altamente segura para que ningún atacante pueda tomar el control de ella y comprometer los mecanismos de certificación. Se puede distribuir los certificados de forma parcial o total.

En un mecanismo de distribución parcial de los certificados se elige un subconjunto de nodos llamados servidores a los cuales se transmiten las claves. Esos nodos deben disponer de una clave privada y una clave pública para que la entidad externa les pueda identificar de forma unívoca. Cada uno de los servidores genera una firma parcial utilizando su clave privada que es
enviada a un combinador, que puede ser cualquier servidor. El combinador reconstruye así la firma digital.

En un mecanismo de distribución total de los certificados, la clave se distribuye a todos los nodos de la red y requiere que un nodo use la entidad externa para contactar con cualquier vecino. No es necesario el concepto de combinador ya que será el propio nodo quién reconstruye la firma digital del grupo.

Gestión paralela de claves

Esta alternativa descrita en [SYRK 2004] se basa en una distribución parcial de los certificados por parte de una entidad externa y de un mecanismo de cadenas de certificados. La propuesta es conocida como Composite Key Management. La entidad externa distribuye el certificado a nodos servidores y luego tiene lugar el mecanismo de cadenas de certificados.

SOLUCIÓN ADOPTADA

Autorización de certificación distribuída

Apoyándonos en los trabajos de investigación de Alexandre Viejo, Francesc Sebé, Josep Domingo-Ferrer y Jesus Manjón, de la Universitat Rovira i Virgili (Comunicaciones Privadas en Redes Ad-hoc Vehiculares), optamos por un sistema de gestión de claves distribuído, gasado en agentes externos.

El sistema ofrecerá un mecanismo de seguridad y privacidad en el envío de mensajes siempre que los agentes externos que gestionan los identificadores (señales de tráfico, dispositivos específicos, nodos certificados, …) sean fiables. Así, estas señales están facultadas para revocar identificadores y alertar a la red sobre nodos de dudosa fiabilidad o cuyas intenciones son entorpecer y comprometer al sistema.

Se propone así un sistema basado en pseudónimos válidos firmados por autoridades de tráfico que permiten identificar a usuarios fiables y distinguirlos de aqueños que pudieran ser dañinos, en cuyo caso, su pseudónimo queda marcado como “rebocado”, y cualquier mensaje que envíe será automáticamente identificado como no seguro. El sistema, además, impone una política de renovación de pseudónimos para ofrecer al usuario un mayor nivel de privacidad, al exponer en menor grado el seguimiento y traceado por terceros.

Propuesta

Distinguimos en nuestra red VANET dos elementos principales:
i) Señales de tráfico o dispositivos específicos.
ii) Vehículos moviéndose por nuestra zona de cobertura.

Las señales de tráfico se consideran nodos estáticos y son gestionados por las autoridades de tráfico (DGT).

Suponemos que las señales de tráfico son nodos fiables, que no guardan información acerca de los nodos de la red ni realizan actividades dañinas en la misma. Estos nodos tienen la capacidad de generar y almacenar una clave privada SKt, gestionada por la autoridad de tráfico. La clave pública asociada es accesible, conocida y aceptada como válida por todos los demás nodos de la red.

Cada vehículo está equipado con un dispositivo no manipulable (similar a una tarjeta inteligente), que no puede ser desinstalado y que impide que el usuario modifique su identificación.

Transmisión de mensajes

Cuando transmitimos mensajes en nuestra red, ya sean mensajes de alerta o informativos, estos serán enviados siguiendo la técnica de difusión uno-a-todos. Así, una señal de tráfico puede indicar a la red la existencia de un nodo no fiable o deshonesto de esta forma. De la misma manera, los vehículos deben indicar cada cierto tiempo si siguen o no activos, a través de mensajes “hello-beacons”, que ayudan a gestionar la propia red VANET.

Los mensajes transmitidos vía broadcast por las señales de tráfico son de confianza, esto es, están correctamente firmados y no utilizan pseudónimo.

En cambio, los vehículos sí necesitan incorporar esta información en el envío de sus mensajes. Este pseudónimo IDnode está formado por la concatenación de cuatro valores, a los cuales se le aplica la firma SKt.

El primer campo es un valor v aleatorio. El segundo es una marca temporal que indica cuándo se generó dicho pseudónimo. Y los otros dos campos son las dos claves públicas del nodo (PKSnode, PKEnode), utilizadas para firmar y cifrar, respectivamente. Mediante el uso del sello temporal, podemos determinar, si ésta es más antigua que un cierto tiempo preestablecido, si es o no un mensaje válido.

La tarjeta inteligente del vehículo contiene su Idnode actual y las claves secretas SKs,node ,
SKe,node .
Gracias a estos datos, cualquier mensaje enviado por un vehículo es válido si su Idnode es un pseudónimo válido, esto es, si IDnode no ha sido marcado como “revocado”. Para los mensajes “hello_beacon”, aparte del pseudónimo, se transmiten las coordenadas GPS actuales del vehículo, así como otros posibles datos, todo ello firmado con SKs,node :


Obtención de un pseudónimo

Cuando una señal recibe un mensaje “hello_beacon” que contiene un pseudónimo caducado, es decir, el sello temporal ha expirado, ésta avisa al propietario del mensaje a actualizar su Idnode.

Para ello, el nodo sigue los siguientes pasos:

1. Generación de dos parejas de claves:

(SKSnode’ , PKSnode’ ) (SKEnode’, PKEnode’ )

2. El nodo genera un nuevo pseudónimo
*vRandom’, timeStamp’, PKSnode’ y PKEnode’ son valores nuevos, y firmados con SKt antigua.

3. El nodo envía el siguiente mensaje cifrado a la señal de tráfico

4. La señal de tráfico descifra el mensaje,verifica su contenido (en particular se ase-
gura que Idnode no ha sido revocado por un mal comportamiento anterior) y genera el mensaje firmado:
5. IDnode es enviado al vehículo cifrado bajo PKEnode’.6. El vehículo descifra el mensaje y obtiene su nuevo pseudónimo Idnode . 

El sistema descrito trabaja bajo el supuesto de que cada vehículo lleva implantado de fábrica un identificador inicial. Éste identificador es firmado con SKt, pero no es un IDnode válido. Será después, cuando se comunique con una señal, cuando el pseudónimo será actualizado.

Broadcast de mensajes coche-a-todos

Un usuario que quiere enviar una alerta a la red selecciona el mensaje a enviar, concatena el sello temporal y su pseudónimo y firma el mensaje entero utilizando su clave privada.

Un posible ejemplo de esta situación se daría cuando un coche, atrapado en un atasco, alerta a los coches cercanos sobre esta situación.
Al recibir el mensaje, los otros coches verifican la validez del pseudónimo. El mensaje se considera válido si el pseudónimo no ha sido revocado.
Las señales de tráfico tienen dos maneras de decidir si un usuario es deshonesto o no:

1. Se considera que un mensaje es falso si hay al menos i (parámetro de seguridad) mensajes de diferentes usuarios informando que un cierto mensaje es falso.

2. La segunda opción se basa en la posibilidad de que las señales de tráfico reciban información directamente de la autoridad de tráfico sobre situaciones peligrosas en la carretera. Un usuario que envíe información contradictoria con la fuente oficial será considerado como deshonesto.

Una vez una señal detecta a un usuario deshonesto, notifica a toda la red dicha situación mediante broadcast.

Publicado en 802.15.4, sacar, v2v, vanet | Deja un comentario

SACAR 10 – IEEE 802.15.4 Radio Shadowing in Urban Enviroments – Obstacles

Publicado el 5 octubre, 2011 por edu
Hasta ahora, las mediciones y estadísticas que habíamos realizado se habían circunscrito a entornos con una visibilidad entre vehículos directa, sin ningún tipo de obstáculo que pudiera interferir en la recepción de los mensajes que se enviaran. No obstante, esta situación idónea será difícil de encontrar en escenarios urbanos, donde la arquitectura impone barreras físicas que modifican el comportamiento de la señal, afectando en definitiva, a nuestra capacidad de recibir un determinado mensaje. 

Así, en primer lugar, deberíamos establecer un parámetro o valor que nos indique en qué medida nuestra capacidad de recibir un mensaje ha sido alterada, en función de la distancia entre emisor y receptor, de la calidad del medio de transmisión, de los elementos que obstaculicen el camino que recorre la señal de transmisión…

Nos encontramos entonces con un parámetro que, en telecomunicaciones, nos permite determinar ese tipo de variación en la señal frente a pérdidas o interferencias. Este parámetro es el decibelio (db), y representa la relación existente entre la potencia de señal en el emisor y la potencia de señal en el receptor : dB = 10  log10 (Ps/Pe)

Gracias a este parámetro podemos evaluar cuantitativamente en valores relativos la calidad de nuestra señal en el receptor respecto a la del emisor. Sin embargo, el siguiente paso es determinar qué factores y en qué medida influyen sobre dicha relación. Las simulaciones en redes de comunicación se ven influenciadas por pérdida de señal debido a largas distancias, pérdidas determinísticas a pequeñas escalas o atenuaciones por efectos probabilísticos, por lo que el cómputo total es normalmente calculado como la suma independiente de procesos de atenuación Lx.  En este proyecto contemplaremos únicamente dos tipos de factores de atenuación sobre la señal de transmisión:

- Right Two-Ray Model

 

En términos simplificados, este tipo de pérdida de señal viene dada por la forma en que la onda se propaga, como podemos observan en la imagen. Por un lado, el receptor tiene una visión directa del emisor, a una distancia dlos, desde donde se recibe la señal, pero, por otro lado, la misma señal se ve reflejada sobre la tierra, con un cierto ángulo de reflexión, produciendo un retardo en la señal que origina un tipo de interferencia conocido como Two-Ray Interference, y que viene dado por la siguiente expresión:

- Attenuation per wall and attenuation per meter of penetration approaches

Este tipo de pérdida de señal viene determinado directamente por el entorno en el que nos encontremos, con los obstáculos que se dibujen alrededor de cada vehículo y de su forma y composición. El valor de atenuación que nos impone cada uno de los obstáculos que pudiéramos encontrarnos podría determinarse empleando algoritmos basados en ray-tracing con gran exactitud y granularidad, sin embargo, podemos realizar aproximaciones basadas en medidas empíricas anteriores. En este caso, nos apoyaremos en los estudios realizados por Christoph Sommer & Co. Univ. of Eralngen, Germany [REF ] en el cual determinan que la pérdida de señal al atravesar un determinado obstáculo (un edificio común en un área urbana) tiene en cuenta el número de paredes que se atraviesan multiplicado por un factor de atenuación  (que para un edificio se aproxima a 9.6 dB) y el espacio interno multiplicado por un factor de atenuación  aproximado a 0.45 dB/m.

De esta forma, nos encontramos ante la siguiente expresión:

Con estos dos parámetros de atenuación a tener en cuenta definimos un entorno de simulación simple donde podamos comprobar dicha influencia en valores relativos dB. Para ello, situamos dos vehículos a una cierta distancia, uno de ellos fijos, y otro en movimiento, donde, en un determinado momento un obstáculo se interpondrá entre ambos, como muestra la siguiente figura:

 

El resultado de las mediciones es el siguiente:


Una vez comprobado que el modelo con obstáculos se comporta como esperamos, incluyendo los dos parámetros de atenuación comentados, el siguiente paso es llevar dichos valores al escenario con el que hemos venido trabajando hasta ahora.

En este sentido, podríamos incluirlos tanto en el escenario de grid manhattan como en el escenario real del campus universitario de Alcalá, sin embargo, dado que la definición de la estructura que representa los obstáculos es compleja de elaborar, para el escenario real del campus se hace demasiado laboriosa. No obstante, podemos obtener unos resultados concluyentes con el grid manhattan como observamos en las estadísticas que se presentan a continuación.

Para ello, hemos incluido en el grid manhattan una retícula de obstáculos en los espacios existentes entre las vías de circulación como se muestra en la siguiente imagen:

Estadísticas con obstáculos:

En las siguientes gráficas se muestran los resultados obtenidos con obstáculos, y los que se obtuvieron sin tenerlos en cuenta.
nº vehiculos tiempos medios
25 0,007209680001107 0,007072685627817
50 0,007617448143321 0,007199787745076
75 0,008395350651071 0,010987959991301
100 0,013129935217123 0,013574591837651
125 0,018938251818686 0,016334174503593
150 0,025972732589758 0,035179274952087
175 0,030080657313761 0,045466363075213
200 0,031529364457014 0,049251359616137
225 0,044340576195803 0,06505717896325
250 0,036982368803253 0,062109701641809
275 0,043089638515126 0,061436680713181
300 0,046655336079543 0,071436680713181

nº vehiculos no ciegos
25 2,52 89,92 89,16
50 4,51 90,98 91,84
75 5,45 92,7333333333333 90,02
100 12,62 87,38 86,25
125 19,16 84,672 85,09
150 35,43 76,38 66,42
175 44,33 74,6685714285714 51,04
200 48,03 75,985 35,35
225 99,03 55,9866666666667 14,08
250 104,13 58,348 16,66
275 144,8 47,3454545454545 21,89
300 141,73 52,7566666666667 23,78

velocidad (m/s) tiempos medios
5 0,048370934391316 0,048343629270837
10 0,055500794271592 0,061024494525718
15 0,063731446790672 0,062833164664556
20 0,05123674211268 0,053831343588155
25 0,052311978312052 0,053874989359417
30 0,042951989775603 0,0426030364312
35 0,044822091702791 0,041898096643327

Velocidad (m/s) nº vehiculos no ciegos
5 225 154,36 31,3955555555555 24,47
10 225 138,4 38,4888888888889 21,35
15 225 174,16 22,5955555555556 16,8
20 225 149,46 33,5733333333333 27,58
25 225 127,83 43,1866666666667 35,57
30 225 112,06 50,1955555555556 46,65
35 225 107,43 52,2533333333333 47,4

 

Publicado en Sin categoría | Deja un comentario