CANALES SEGUROS

Cuando se considera la seguridad en sistemas distribuidos,  resulta muy útil pensar en función de cliente y servidor. En particular, implementar un sistema distribuido seguro se reduce esencialmente a dos temas predominante: 

• ¿Como hacer segura la comunicación entre cliente y servidor ?
• ¿Como saber si dicho cliente esta autorizado para realizar una solicitud?

En esta sección se concentra en la protección de la comunicación dentro de un sistema distribuido, el tema de protección de la comunicación entre clientes y servidores puede ser considerada  en función del establecimiento de un canal seguro.Un canal seguro protege  a remitentes y destinatarios contra la intercepción, modificación y fabricación del mensaje.

AUTENTICACIÓN

Antes de entrar en detalle de varios protocolos de autenticación, vale la pena señalar que la autenticación y la integridad de los mensajes no se pueden realizar una sin otra.Consideremos , por ejemplo , un sistema distribuido que soporta la autenticación de dos partes en comunicación, pero no proporciona mecanismos para garantizar la integridad del mensaje. En un sistema como ese, Bob puede saber con seguridad que Alicia es el remitente de un mensaje m. Sin embargo, si a Bob no se le puede garantizar que m no haya sido modificado durante la transmisión.

Asimismo, supongamos que unicamente la integridad del mensaje es soportada pero que no existen mecanismos de autenticación. Cuando Bob reciba un mensaje para informarle que gano S/.100000 en la lotería ,¿que tan feliz podría estar si no puede verificar si el mensaje fue enviado por el organizador de dicha lotería ?. Por consiguiente la autenticación y la integridad deben ir de la mano.

Autenticación basada en una clave secreta compartida

 A(alicia) y Bob(B), comparten una clave KA,B , el protocolo básicamente consiste en que una parte reta a que otra responda correctamente solo si la otra parte conoce la clave secreta compartida , tales soluciones se conocen como protocolos de reto-respuesta.

Alicia desea establecer canal de comunicación con Bob para ello primero envía su identidad  a Bob (1°mensaje ). Bob envia posteriormente un reto(2°mensaje), se requiere que Alicia cifre con la clave secreta que comparten con Bob , y lo regrese a Bob(3°), ahora Alicia envia un reto a Bob(4°), Bob cifra en reto y envia a Alicia(5°) , cuando  Alicia descifrar dicho mensaje tiene la certeza que esta hablando con Bob.

Autenticación mediante un centro de distribución de claves 

Uno de los problemas que se presentan con el uso de una clave secreta compartida para autenticacion es su escalabilidad. Una alternativa es utilizar un método centralizado por medio de un centro de distribución de claves (KDC) . Este KDC comparte una clave secreta con cada uno de los servidores ,pero no requiere que ningún par e ellos tenga también una clave secreta compartida.

Si Alicia desea establecer un canal seguro con Bob puede hacerlo con ayuda del KDC confiable. La idea integral es que el KDC entregue un clave tanto Alicia como a Bob que pueda utilizar para comunicarse, la siguiente imagen da la idea como se establece comunicación mediante KDC

Autenticación con criptografía de clave publica 

Consideremos nuevamente la situacion en que Alicia desea establecer un canal seguro con Bob y ambos poseen la cable publica del otro. Alicia comienza enviando un reto a Bob cifrado con su clave publica , la tarea de Bob es descifrar el mensaje  y regresar el reto a Alicia: Como Bob es la única persona que puede descifrar el mensaje (usando la clave privada asociada con la clave publica que Alicia utilizo), Alicia sabra que esta hablando con Bob.

Cuando Bob recibe la petición de Alicia de establecer un canal, le regresa el reto descifrado junto con su propio recto para autenticar a Alicia. Ademas genera una clave de sesion KA,B  que pueda ser utilizada para establecer mas comunicaciones. la respuesta de Bob al reto de Alicia, su propio reto, y la clave de sesión se incluyen en un mensaje cifrado con la clave publica de Alicia.

Alicia finalmente regresa su respuesta al reto de Bob utilizando la clave de sesión KA,B generada por Bob 

INTEGRIDAD Y CONFIDENCIALIDAD DEL MENSAJE

Ademas de la autenticación ,un canal seguro también debe proporcionar garantias en cuanto a integridad y confidencialidad del mensaje. Integridad del mensaje significa que los mensajes están protegidos contra modificación subrepticia ; la confidencialidad asegura que los mensajes no pueden ser interceptados y leído por fisgones. La confidencialidad es fácil de establecer simplemente con cifrar mensajes antes de enviarlo, sin embargo la protección de un mensaje contra modificaciones es un poco mas complicada como se vera a continuación :

Firmas Digitales 

La integridad de un mensaje va mas allá de la transferencia a traves de un canal seguro.

Consideremos las situación en que Bob acaba de vender a Alicia un disco fonografico de coleccion en S/ 500 . La operacion se realizo a traves de correo electrónico. Al final , Alicia le envia un mensaje  a Bob para confirmarle que comprara el disco en S/. 500. Ademas de autenticacion , existen por lo menos dos cuestiones a tener en cuenta con respecto a la integridad del mensaje.

• Alicia tiene que estar segura de que Bob no cambiara maliciosamente los S/. 500 mencionados en su mensaje a un cifra mayor, y de que luego no diga que ella prometio mas de esa cantidad.
• Bob tiene que estar seguro de que Alicia no puede retractarse de que no envió el mensaje.

Estas dos cuestiones pueden ser solventadas si Alicia firma digitalmente el mensaje, de tal forma que su firma quede vinculada de manera única a su contenido. La asociación unica, entre entre un mensaje y su firma evita que las modificaciones al mensaje pasen inadvertidas. Ademas , si la firma de Alicia puede ser verificada como genuina, luego ella no podra decir que no firmo el mensaje.

Existen varias formas de colocar firmas digitales. Una muy popular es utilizar un criptosistema de clave publica RSA como se muestra en la figura de abajo . Cuando Alicia redacta un mensaje m para Bob, lo cifra con su clave privada y se lo envia a Bob: Si también desea mantener en secreto el contenido del mensaje, puede utilizar la clave publica de Bob 

Claves de Sesión 

Durante el establecimiento de un canal seguro, una vez completada la fase de autenticación, las personas que se están comunicando utilizan por confidencialidad, una clave única de sesión compartida. La clave de sesión se desecha en forma segura cuando el canal ya no se utiliza. Una alternativa seria utilizar las mismas claves para la confidencialidad que las utilizadas para establecer el canal seguro.

COMUNICACIÓN SEGURA DE UN GRUPO 

Hasta ahora , la atención se ha concentrado en el establecimiento de un canal de comunicación seguro entre dos partes. en sistemas distribuidos, sin embargo , a menudo es necesario habilitar la comunicación segura entre mas de dos partes. Un ejemplo típico es un servidor replicado donde toda la comunicación entre las réplicas deber protegerse contra modificacion , fabricacion , e intercepción como en el caso de canales seguros bipartitas.

Comunicación confidencial de un grupo  

En primer lugar, consideramos el problema de proteger a la comunicación entre un grupo de N usuarios contra el fisgoneo.  Para garantizar la confidencialidad, un esquema simple es que todos los miembros del grupo compartan una clave secreta, la cual se utiliza para cifrar y descifrar todos los mensajes transmitidos entre los miembros del grupo. Como en este esquema todos los miembros compartan la clave secreta, es necesario confiar en que la conservaran secreta.

Servidores replicados seguros  

Ahora consideremos un problema completamente diferente : un cliente emite una peticion a un grupo de servicios replicados. Estos pueden haber sido replicados por razones de tolerancia o desempeño defectuoso, pero en todo caso, el cliente espera que la respuesta sea confiable. En otros términos , a pesar de que el grupo de servidores este sujeto a fallas bizantinas , un cliente espera que la respuesta regresada no haya sido sometida a un ataque de seguridad. Semejante ataque podría ocurrir si uno o mas servidores fueron corrompidos por un intruso