Se propone un sistema confiable de resolución de direcciones de red en direcciones físicas,

aplicable a redes telemáticas de área local, para evitar la vulnerabilidad por envenenamiento de caché que actualmente sufre el protocolo ARP (RFC826). A diferencia de las soluciones técnicas existentes a este problema, la resolución es centralizada y se fundamenta en un servicio que actúa como tercera parte de confianza, gracias al empleo de una infraestructura de clave pública que permite firmar digitalmente los mensajes de resolución para asegurar su autenticidad e integridad.

Sistema y método de resolución centralizada y confiable de direcciones de red en direcciones físicas no vulnerable a ataques de envenenamiento de caché.

La invención se ubica en el área de las comunicaciones telemáticas y más concretamente, en el de la seguridad en redes de área local. La presente invención tiene por objeto un sistema y método centralizado para la resolución de las direcciones de red en direcciones físicas no vulnerables a los ataques por envenenamiento de la caché.

Estado de la técnica anterior

El protocolo de resolución de direcciones más ampliamente extendido en el ámbito de las redes locales es ARP (Address Resolution Protocol, RFC826, literalmente protocolo de resolución de direcciones). Se han descrito varios sistemas para neutralizar los ataques de envenenamiento de la caché asociada a dicho protocolo ARP. Siguiendo el enfoque original de ARP, dichos sistemas asumen un mecanismo de resolución distribuido, según el cual el equipo de red cuya dirección física se desea resolver a partir de la dirección de red es el encargado de enviar esta información al equipo que origina el proceso de resolución. Lo que distingue a estos sistemas del resto es el método usado para verificar que la correspondencia entre la dirección física obtenida y la dirección de red es la auténtica. Entre estos métodos es posible destacar los siguientes:

(a) Método basado en inspección de paquetes ARP y DHCP (Dynamic Host Configuration Protocol, RFC2131 literalmente protocolo de configuración dinámica del Host). Las redes de área local se basan en equipos electrónicos que distribuyen por la red las transmisiones de nivel físico. Dado que el tráfico de la red atraviesa forzosamente dichos equipos, éstos pueden ser dotados de los procesos necesarios para inspeccionar los mensajes ARP y DHCP generados desde equipos considerados de confianza para establecer las correspondencias válidas entre direcciones físicas y de red. Sin embargo, los equipos de red que incorporan esta funcionalidad son sustancialmente más costosos ya que necesitan de mayores recursos de memoria y capacidad de cómputo. Por otra parte, las asignaciones de direcciones de red estáticas, no gestionadas por el servicio DHCP, deben configurarse manualmente y ser distribuidas debidamente en los equipos de red. Es el caso del Dynamic ARP Inspection [1],

(b) Método criptográfico. Se basan en el uso de la criptografía para generar testigos que permitan autentificar las correspondencias entre direcciones físicas y de red. Se han propuesto las siguientes variantes:

(c) Método de mejora del comportamiento del protocolo ARP. Se basa en modificar el procesamiento de mensajes ARP especificado en RFC826, para disminuir o eliminar el riesgo de envenenamiento de la caché. Se han propuesto las siguientes variantes:

Referencias

[1] Y. Bhaiji: Network Security Technologies and Solutions. Capítulo 8: Dynamic ARP Inspection (DAI). Ed. Cisco Press. 2008. ISBN-13: 978-1-58705-246-0.

[2] D. Bruschi, A. Ornaghi, E. Rosti. S-ARP: a secure address resolution protocol. Proc. 19th Annual Computer Security Applications Conference, ACSAC 2003, pp 66-74, Las Vegas, NV (USA), Diciembre 2003.

[3] V. Goyal, R. Tripathy. An Efficient Solution to the ARP Cache Poisoning Problem, 1 Oth Australasian Conference on Information Security and Privacy (ACISP 2005), LNCS 3574, Springer-Verlag. Julio, 2005.

[4] H. Urtubia. Local area network security: Authenticating the ARP protocol, Master's Thesis, HKU Libraries, Electronic Resources, 2003.

[5] A. Zúquete, H. Marques: A Security Architecture for Protecting LAN Interactions. Information Security, 9th International Conference, ISC 2006, Samos Island, Greece, August 30 - September 2, 2006. Proceedings. Lecture Notes in Computer Science 4176, pp 311-326, Springer, 2006, ISBN 3-540-38341-7.

[6] W. Lootah, W. Enck, P. McDaniel: TARP: Ticket-based address resolution protocol. Computer Networks: The International Journal of Computer and Telecommunications Networking, v.51 n.15, p.4322-4337. Association for Computing Machinery (ACM), Octubre, 2007.

[7] S. Whalen, M. Bishop: Layer 2 Authentication. Febrero 2005.

[8] M.V. Tripunitara, P. Dutta: A Middleware Approach to Asynchronous and Backward Compatible Detection and Prevention of ARP Cache Poisoning. Proceedings of the 15th Annual Computer Security Applications Conference (ACSAC). IEEE Computer Society, December, 1999.

[9] P.B. Finley, T.L. McLane, E.L. Reyes: Preventing asynchronous ARP cache poisoning of múltiple hosts. United States Patent Application US7471684. 12/30/2008.

Explicación de la invención

El problema técnico objetivo que la presente invención resuelve frente a las soluciones aportadas en el estado... [Seguir leyendo]

1. Método de resolución centralizada y confiable de direcciones de red en direcciones físicas, no vulnerable a ataques de envenenamiento de caché, sincronizado mediante una medida de tiempo común, caracterizado porque comprende, al menos,

(i) un primer proceso lógico configurado para la resolución centralizada de direcciones físicas a partir de direcciones de red en un servidor de resolución de direcciones (SRD), para el que se ha generado una infraestructura de clave pública, un par de claves asimétrica, pública y privada, y un certificado digital con una validez preestablecida; en donde dicho primer proceso tiene acceso a:

en donde dicho primer proceso lógico, al recibir el mensaje de solicitud de resolución enviado por un equipo informático conectado a la red de área local (cliente) que incluya una dirección de red con objeto de obtener del SRD la dirección física correspondiente, el SRD envía un mensaje de respuesta de resolución firmado digitalmente empleando su clave privada, en el que incluye la correspondencia entre dirección de red y dirección física solicitada por el cliente junto con una marca temporal indicativa del instante en que se realiza la operación de firma digital; y donde en el caso de que el SRD no conozca la dirección física solicitada, enviará en su lugar un valor especial que tendrá la consideración de nulo por ambas partes;

(ii) un segundo proceso lógico de solicitud de resolución de direcciones asociado al cliente que tiene acceso a:

en donde, cuando, por la propia operación del cliente, resulte necesario determinar la dirección física asociada a una determinada dirección de red, y la correspondencia entre ambas no se encuentra almacenada en la caché, el cliente envía un mensaje de solicitud de resolución hacia el SRD conteniendo dicha dirección de red; y donde al recibir un mensaje de respuesta de resolución, aplica la clave pública del SRD sobre la firma digital incluida en dicho mensaje para comprobar si éste ha sido emitido por el SRD, y comprueba si la marca temporal se corresponde con la hora local del cliente con una diferencia menor que la desviación máxima admisible, aceptando el cliente la correspondencia entre dirección de red y dirección físicas aportadas en el mensaje, incluyéndolas en la caché, sólo si ambas comprobaciones resultan positivas.

2. Método según la reivindicación 1 caracterizado porque las direcciones de red son direcciones IP definidas según la norma RFC791, y las direcciones físicas son direcciones MAC definidas según la norma IEEE Standard 802, siendo 00-00-00-00-00-00 la dirección MAC que se considera de valor nulo.

3. Método según la reivindicación 1 y 2 caracterizado porque el certificado digital del SRD es un certificado emitido por una Autoridad de Certificación.

4. Método según la reivindicación 1 y 2 caracterizado porque el certificado digital del SRD es un certificado autofirmado.

5. Método según la reivindicación 1, 2, y 3 o 4 caracterizado porque el repositorio que almacena las correspondencias entre direcciones de red y direcciones físicas a las que tiene acceso el SRD se obtiene de el conjunto de asignaciones dinámicas realizadas por el servidor DHCP de la red de área local, en caso de existir, y de un conjunto de asignaciones estáticas, para aquellas asignaciones que no sean gestionadas por el servidor DHCP.

6. Método según las reivindicaciones anteriores caracterizado por incorporar el siguiente comportamiento en el procedimiento de resolución de direcciones asociado a los clientes, con objeto de evitar ataques por envenenamiento de caché ARP (Address Resolution Protocol, RFC826): ignora todo mensaje ARP recibido.

7. Método según las reivindicaciones anteriores caracterizado por incorporar el siguiente comportamiento en el procedimiento de resolución de direcciones asociado a los clientes, con objeto de mantener la interoperabilidad con el protocolo de resolución ARP y evitar ataques por envenenamiento de caché ARP: ignora todo mensaje ARP-reply recibido; y al recibir un mensaje ARP-request, lo procesa según lo previsto en la norma RFC826, excepto que no se incluye la correspondencia entre dirección de red y dirección física del emisor del mensaje en la caché.

8. Sistema de resolución centralizada y confiable de direcciones de red en direcciones físicas, no vulnerable a ataques de envenenamiento de caché, configurado para implementar el método de las reivindicaciones 1 a 7, que comprende medios de sincronización horaria, que proporciona a los equipos integrantes de la red de área local, al menos un servidor y al menos un dispositivo cliente de una medida de tiempo común a todos ellos caracterizado porque comprende, al menos

(i) un primer servidor de resolución de direcciones (SRD) configurado para la resolución centralizada de direcciones físicas a partir de direcciones de red, que a su vez comprende una infraestructura de clave pública, un par de claves asimétrica, pública y privada, y un certificado digital con una validez preestablecida; en donde dicho primer servidor SRD tiene acceso a:

y en donde dicho servidor comprende medios configurados para recibir el mensaje de solicitud de resolución enviado por el cliente y medios configurados para enviar un mensaje de respuesta de resolución firmado digitalmente empleando su clave privada, en el que incluye la correspondencia entre dirección de red y dirección física solicitada por el cliente junto con una marca temporal indicativa del instante en que se realiza la operación de firma digital; y donde en el caso de que el SRD no conozca la dirección física solicitada, enviará en su lugar un valor especial que tendrá la consideración de nulo por ambas partes;

(ii) un elemento cliente con acceso a las direcciones físicas y de red del SRD; el certificado digital del SRD, conteniendo la clave pública del mismo; y la memoria caché de resolución de direcciones, que almacena temporalmente las correspondencias entre direcciones de red y direcciones físicas que se han obtenido mediante consultas al SRD siguiendo el procedimiento de resolución de direcciones del primer proceso lógico de la reivindicación 1;

en donde, dicho cliente comprende medios configurados para enviar un mensaje de solicitud de resolución hacia el SRD conteniendo la dirección de red; y medios configurados para recibir un mensaje de respuesta de resolución y aplicar la clave pública del SRD sobre la firma digital incluida en dicho mensaje para comprobar si éste ha sido emitido por el SRD, y comprobar si la marca temporal se corresponde con la hora local del cliente con una diferencia menor que la desviación máxima admisible, aceptando el cliente la correspondencia entre dirección de red y dirección físicas aportadas en el mensaje, incluyéndolas en la caché, sólo si ambas comprobaciones resultan positivas.

9. Sistema según la reivindicación 8 caracterizado porque las direcciones de red son direcciones IP definidas según la norma RFC791, y las direcciones físicas son direcciones MAC definidas según la norma IEEE Standard 802, siendo 00-00-00-00-00-00 la dirección MAC que se considera de valor nulo.

10. Sistema según la reivindicación 8 y 9 caracterizado porque el certificado digital del SRD es un certificado emitido por una Autoridad de Certificación.

11. Sistema según la reivindicación 8 y 9 caracterizado porque el certificado digital del SRD es un certificado autofirmado.

12. Sistema según la reivindicación 8, 9, y 10 o 11 caracterizado porque el repositorio está configurado para almacenar las correspondencias entre direcciones de red y direcciones físicas a las que tiene acceso el SRD se obtiene de el conjunto de asignaciones dinámicas realizadas por el servidor DHCP de la red de área local, en caso de existir, y de un conjunto de asignaciones estáticas, para aquellas asignaciones que no sean gestionadas por el servidor DHCP.