Viendo lo soso que esta esto...

Velaznito 8 abril 2003 19:22 ✎

⋮

Tengo que resolver un problemilla para un proyecto, asi que no vales soluciones ya hechas tipo ssh o IPSec, lo que interesa en este post es encontrar un algoritmo seguro.

Situemonos: Básicamente, y por no exponerlo todo, tenemos una LAN, en la que queremos "securizar" las comunicaciones de ciertos ordenadores (el resto de máquinas de la LAN no deben enterarse de lo que hablan éstos).
La gracia está en que ciframos las comunicaciones, en principio, con cifrado simétrico, con claves por cada par de equipos, tras previa negociación y autenticación mediante claves asimétricas.

Es decir, si la maquina A quiere comunicarse con la maquina B, utiliza la clave simetrica {A-B} que previamente han negociado. Si es C quien quiere comunicarse con D, utilizará la clave {C-D}.

Ahora bien, surge el problema de los broadcast: Si A manda un paquete de broadcast (que va para B, C, y D), ¿Cómo debería hacerse para asegurar autenticidad de origen y seguridad en la comunicación?

Posibles soluciones (por ahora todas con pequeñas o grandes pegas):

1) Hacer los broadcast en claro. Desde luego que no es lo que se busca.

2) Un clave de cifrado común para los broadcast. Alguna máquina podría hacerse pasar por otra, ya que no hay autenticación.

3) Version de la anterior, metiendo en mi protocolo la firma del paquete de la maquina origen. La firma debería ser (lógicamente) con criptografía asimétrica, lo cual es lento.

4) Envío de un paquete cifrado con destino cada máqina, en vez de uno solo con broadcast. Demasiados paquetes en la red.

5) Estación central a la que se le hace una petición de broadcast mediante un canal único, ésta retransmite el paquete cifrandolo con destino cada máquina. (Es una modificación de 4, se basa en las LAN Emuladas de ATM). Sigue existiendo el problema de cantidad de paquetes enorme.

.....
Se han pensado algunas más, pero ya se complican más (metiendo Xor y cosillas como firmas). Básicamente son modificaciones del 5), teniendo la necesidad de una estación central, pero haciendo modificaciones para enviar solo un paquete a todos e intentar la autenticidad y la seguridad.

Sería bastante más flexible si no existiera la estación central, por lo que yo tiro más por la solución 3), pero tampoco me convence por la lentitud...

Bueno, yo seguiré pensando, si por alguna casualidad se os ocurre algo, o ya pasateis por algo parecido, hala! a postear las ideas que tengais.

A ver si se os ocurre algo y se empieza a "mover" este foro...
:P

P.D: He estado mirando en Google y parece ser que hay algoritmos para la autenticación tipo TESLA o BIBA (este ultimo, algo como firmas rápidas). ME lo miaré a ver si me vale y si es suficientemente seguro. De todas formas agradecería cualquier aportacion, que además le vendría bien al foro.

Este tema está cerrado a nuevas respuestas. Abre un nuevo tema para retomar la conversación.

FreeBSD 8 abril 2003 20:34

⋮

A mi me parece que te falta decir a qué nivel estás encriptando las comunicaciones. Es decir, no sabemos si vas a trabajar con sockets crudos por encima del N2 o N3, o por el contrario lo que encriptas es un protocolo de aplicación propio programado por encima del interfaz socket.

Cuando hablas de los broadcast, explicanos que broadcast son los que te preocupan. Porque un procedimiento ARP es un broadcast y no contiene información de usuario relevante para ser encriptada. Y esto me vuelve a llevar a qué nivel quieres encriptar...O por el contrario te refieres por broadcast a algún tipo de multidifusión al estilo (como citas) de ATM con el fin de establecer comunicaciones punto-multipunto.

Salu2.

PD: ¿Quién te ha mandado este proyecto? Este proyecto me suena a Vicente o Malagón.

✖

Velaznito 9 abril 2003 15:35

⋮

Creo que si nos abstraemos a lo "básico", el nivel realmente es indiferente (bueno, quizas no). Asi que trabajo a nivel de enlace, con lo que los broadcast a los que me refiero, precisamente, incluyen los ARP. Éstos, que en principio no contienen información privada, sí la poseen. Esto es porque otra de las características del proyecto es realizar "Subredes Privadas Virtuales LAN" (por decirlo de alguna manera). Esto es, a cada S.O. le aparecerán varias interfaces, para cada LAN virtual a la que pertenezca (de ahí lo de ATM LAN Emulation), haciendo que deba "falsear" los ARP y dejarlos ver sólo a las máquinas de la LAN virtual del que lanzó el ARP Request. Idem para cualquier otro tipo de broadcast de este nivel (paquete que se ponga en el bus de la LAN).

P.D.: Ninguno: F. J. Ramírez. Le pedí que fuera algo de redes, programación en C (bajo un S.O. decente) y seguridad... y me dió esto.

P.D.: Por cierto, para ser más precisos sobre el nivel que trabajo, ya que es algo de FreeBSD (posiblemente "FreeBSD" lo conoce), es en la arquitectura Netgraph.

✖

FreeBSD 9 abril 2003 17:07

⋮

Desde un punto de vista lógico da lo mismo, pero desde un punto de vista práctico no da lo mismo. Y más que nada era por ver qué paquetes considerabas que llevaban información a proteger.

A mi las opciones 3, 4 y 5 me parecen bastante bien. Lógicamente todas tienen sus ventajas y desventajas, pero encontrar una solución "perfecta" siempre es algo difícil. Deberías valorar que sacrificas a favor en de otra cosa. Creo que ya depende de ti.

Sólo me gustaría comentar una cosa más en relación a la carga de una red con mucho paquetes. Si recuerdas todos y cada uno de los protocolos y arquitecturas que te han enseñado, te encontraras con arquitecturas que triunfan como la cocacola aún mandando datos a borbotones. Por ejemplo, y siguiendo con ATM, recordarás la cantidad de información que se envía por una red con tan sólo conectar un PC a una LAN emulada. Un procedimiento ARP es algo bastante solitario. Sólo habrá que tener en cuenta con qué frecuencia existirán paquetes multidestino para saber si la carga de la red va a ser muy grande.

Salu2 y suerte con el proyecto.

P.D: Conozco Netgraph pero sólo su existencia, nada más.

P.D 2: Curioso que sea de JR cuando hace un par de años me dijo que ya pasaba de los temas de seguridad porque se había aborrecido...

✖

Velaznito 9 abril 2003 18:31

⋮

Ciertamente, me intentaba abstraer para no alargarme demasiado, pero sí, en la practica cuenta... (por lo que llevo experimentado).

A mí me gusta más la 3), y creo que si consigo estudiar una forma de "firmado rápido" será la que utilice, me tengo que leer lo del "biba" que es algo para broadcast y firmado rápido, no se si será lo que busco, pero a lo mejor hay suerte :)

En cuanto a lo de la carga.... hombre, no es lo mismo un ATM que es una WAN y a esas velocidades.. que una LAN con un bus "compartido", por eso me preocupaba la existencia de demasiados paquetes pero bueno, al final tendré que elegir algo...

P.D 2: Bueno, me ofrecío esto, pero tb "intentó" convencerme de hacer una aplicación de teleenseñanza con POO en ASP.NET... vamos, lo mismito... menos mal que supe decir... ¡NOOO! ;)

✖

FreeBSD 9 abril 2003 19:13

⋮

anthrax 9 abril 2003 04:37

⋮

Por lo que comentas, el algoritmo que quieres implementar es muy parecido al que usa IPSec en las VPN y el ssh. Primero se autentican las partes usando criptografia de clave pública (o sea clave asimetrica y normalmente se autentica solo el origen). Despues se negocian todos los parametros entre las partes: que algoritmo criptografico,la clave asimetrica, etc ....

Yo no veo un problema con el broadcast (con mis conocimientos ;) y lo que explicas en el post), ya que cada PC de la LAN se autentica a si mismo teniendo en su poder su clave privada. Esto tambien lo usan para autenticar el origen IPSec y ssh. Asi cada PC genera un par de claves (privada y publica) y las distribuye a todos los PC de la LAN. Supongo que todo esto ya lo sabras :) .Por eso yo no veo en teoria ese problema. (otro tema es pasar a la práctica,.. jejeje 8) )

Saludos

✖

Velaznito 9 abril 2003 15:50

⋮

>>Primero se autentican las partes usando criptografia de clave pública (o sea clave asimetrica y normalmente se autentica solo el origen). Despues se negocian todos los parametros entre las partes: que algoritmo criptografico,la clave simetrica, etc ....

Cierto, salvo que al autenticar, se hace ambos extremos, al menos en lo que tengo que hacer yo (bueno en ssh, solo el servidor, ya que al servidor le da igual el cliente que se conecte, mientras el usuario sepa la clave...).
He de autenticar a ambos, y es en ese momento cuando se intercambian una clave simétrica que sólo conocerán ellos. Así en el resto de la comunicación, como dicha clave sólo la conocen ellos, saben que el extremo que les escucha es el que se autenticó.

>>Asi cada PC genera un par de claves (privada y publica) y las distribuye a todos los PC de la LAN.

(Bueno, distribuye sólo la pública :P)
Sí, pero el proceso de autenticación no sólo consta en tener una clave (que deben de tener de antemano o bien conocer su fingerprint, de ahí en ssh que te pregunte la primera vez si te fías...), sino que debe existir una firma del "documento" (o paquete) a autenticar o bien un intercambio de mensajes y posterior comprobación de la identidad de la máquina. Esto, como te he mencionado, se hace en el momento del "establecimiento" de la comunicación, además de un intercambio de clave simétrica que solo conocerán ambos extremos.
En un broadcast, con un canal común de cifrado, cualquiera podría hacerse pasar por otra máquina de las que conozcan la clave de ese canal común. De ahí la necesidad de incorporar una firma, lo cual lo hace lento.

¿si? Espero no haberme explicado demasiado mal....

✖

anthrax 9 abril 2003 19:15

⋮

Pero una firma no ha de ser precisamente lenta, no? ....
Puede el emisor del broadcast SOLO cifrar con su clave privada un mensaje ya definido como por ejemplo : Hola soy el host A, y tambien cifrar asi la clave simetrica. Con la que esta cifrado TODO el resto del paquete (más rapido). Entonces el receptor que recibe el broadcast que "supuestamente" viene de A(por la Ip origen, por ejemplo), usa la clave pública de A. Si lo que descifra es : Hola soy el host A, entonces ese paquete viene de A (solo puede haber sido el host A que haya cifrado el mensaje con su clave privada). Descifra la clave simetrica y termina de descifrar el resto del paquete.Normalmente la cantidad de datos cifrada con la clave simetrica es mucho mayor que la cifrada con la asimetrica.

Si, ya se que esto ya lo utiliza el PGP o el cifrado de los DVD's (jejeje). Pero a mi me parece un metodo fiable y seguro. Supongo que me habre explicado más o menos bien y SOBRETODO haber entendido tu problema ;)

La criptografia de clave pública es el mejor metodo existente (creo) para autenticar las comunicaciones... Yo encuentro realmente dificil "reinventar la rueda" y hacer un sistema mejor, porque para mi no tiene pegas ni fallos... 8)

Saludos

✖

Velaznito 10 abril 2003 11:41

⋮

El problema es que realmente, la criptografía asimétrica es lenta.
Y si que se está "reinventando la rueda" :P , dícese: Criptografía de curvas elípticas. Supuestamente más segura y más rápida, y en fase experimental.

Entonces, cada vez que mandase un paquete de broadcast debería firmar dicho paquete, con el consucuente retraso en el envío y carga de CPU. Por eso creo que sí es lento... pero bueno, posiblemente sea la más flexible y con mejores resultados.

LatinSuD 17 abril 2003 12:07 ✎

⋮

Si no recuerdo mal hay una tecnica que permite firmar mensajes con cifrado simetrico de una manera eficiente (Message Authentication Code).

Partimos de 3). Tenemos:

- el mensaje M
- las llaves simetricas {A-B}, {A-C}, {A-D}
- la llave de broadcast simetrica {A-B-C-D}.
- la funcion segura hash()

Si a quiere enviar un mensaje broadcast debe enviar en broadcast el mensaje M' formado por:

cifrar_{A-B-C-D} (M +
hash( M + {A-B} ) +
hash( M + {A-C} ) +
hash( M + {A-D} )
)

Esto supone una sobrecarga en la red moderada (los hashes no ocupan demasiado, aunque hay que enviar uno por cada destinatario del broadcast).

Por ejemplo cuando B recibe el mensaje M' puede comprobar que el emisor es A, ya que solo A conoce la llave {A-B}, y por tanto es el unico (aparte de B) que puede calcular el hash(M + {A-B} ) .

Aun asi, esta el PROBLEMA de que alguien podria replicar mensajes y volverlos a enviar a la red, siendo verificados como autenticos. Para evitar esto A deberia añadir en sus mensajes una "marca de tiempo" o un "numero de secuencia" unico que pueda ser verificado por todos los destinatarios para descartar mensajes antiguos o repetidos.

✖

Velaznito 19 abril 2003 12:10 ✎

⋮

Pues no se me habia ocurrido, pensando el problema con mi compi llegamos a varias soluciones (casi todas con problemas), y algunas de ellas también eran con MAC, pero utilizando one-time-signatures:
R->f1=H(R)->f2=H(f1) ....... -> f100=H(f99)

A los otros les das f100 en el momento del intercambio de claves, de forma que sepan que es tuyo. La siguiente vez incluyes el f99 (por ejemplo en el MAC) que nadie puede generar al ser el hash de f100, y por tanto invertible a partir de este. El receptor lo coge, hace H(f99) comprueba que es igual a f100 y lo sustituye. Primer problema: Si f99 va dentro del MAC, el receptor no puede conocerlo (al ser MAC=H(mensaje+f99) ). Asi que tenemos que mandar el f99 en otro paquete más tarde para demostrar la autenticidad del primer paquete (el del mensaje). Pero aqui surge otro problema: Alguien pude coger el primer paquete, tirarlo a la basura, coger el segundo paquete y qenerar un tercer paquete con un nuevo mensaje y hacer el MAC con el f99 que ha cogido en el segundo paquete. Es aqui donde aparece el protocolo TESLA, que lo intenta solucionar con marcas de tiempo. Si A establece que enviará el primer paquete a las 5:00 y el segundo a las 5:30 (por ejemplo, para entenderlo), el man-in-the-middle, tiene que esperar hasta las 5:30 para hacer algo, tirando el paquete de las 5:00, y luego enviará sus dos paquetes a las 5:35 (o apurando mucho, los dos a las 5:30), donde se ve, que ha fallado el protocolo, y alguien ha "intervenido". Pero esto no es viable, pues a parte de requerir sincronización y precision temporal, para solucionar el problema del "quedo que enviaré esto a tal hora" envias siempre cada 1 segundo un fi, y cuando quieres enviar un broadcast, lo emites con el MAC del fi del segundo siguiente ¿me explico? Lo cual genera demasiados paquetes...
(Este al menos no tiene el problema de reinserción de paquetes, pues el MAC sólo puede ser utilizado una vez)

Esto por si le sirve a alguien alguna vez. O por si a alguien se le ocurre alguna modificación viable.
Mientras, gracias LatinSud por tu idea. La verdad así exactamente no se me había ocurrido, pero tiene buena pinta.
Aunque eso de mandar varias autenticaciones en un mismo paquete... pueden hacer crecer a éste enormemente (según e numero de ordenadores de la LAN virtual), y luego el receptor deberá ir comprobando cada MAC para ver si encuentra alguna que coincida con la que ha generado él. Aunque al ser un broadcast (de 1 a muchos) algún punto de asimetría tiene que tener, ya sea en el algoritmo a usar, o por el numero de "firmas".
Pensaré sobre ello a ver si consigo solventar el problema de la reirsención. Quizá mezclandolo con los one-time-signature o algo parecido.... :) ¡A PENSAR!