Compartir a través de


Análisis de código de la clase ChannelManager (Ejemplo CNG)

Actualización: Julio de 2008

En el ejemplo de comunicación segura de criptografía de próxima generación (CNG), la clase ChannelManager proporciona la infraestructura de comunicación entre procesos (IPC) del ejemplo.

La clase es responsable de lo siguiente:

  • Crear, abrir, cerrar y eliminar las canalizaciones con nombre.

  • Enviar y recibir los marcadores de control de la aplicación, los nombres de los canales, las firmas digitales, las claves criptográficas y los mensajes.

Vea Ejemplo de comunicación segura de criptografía de próxima generación (CNG) para consultar información general sobre el ejemplo y descripciones de las versiones mencionadas en este tema.

Contenido del archivo ChannelManager.cs

El archivo ChannelManager.cs contiene las clases y métodos siguientes:

  • Clase ChannelManager:

    • Constructor: crea una canalización con nombre y, a continuación, espera a que se produzca una conexión en el otro extremo de la canalización. Si la canalización con nombre es un servidor, espera que se produzca una conexión de cliente a través del método WaitForConnection. Si la canalización con nombre es un cliente, espera que se conecte un servidor de la canalización con nombre mediante el método Connect. El constructor ChannelManager no devuelve datos hasta que se realiza la conexión.

    • Método Dispose: implementa la interfaz System.IDisposable; para ello, libera las instancias de sus recursos (Stream m_Stream) cuando la clase sale del ámbito.

    • Método ReadMessage: recibe los mensajes de los clientes de la canalización.

    • Método SendMessage: envía mensajes a los clientes de la canalización.

  • Método AppControl: lo utiliza Alice para enviar los marcadores de control de la aplicación a Bob y Mallory. Estos marcadores sincronizan los estados Version,fMallory y fVerbose entre las tres ventanas de comandos. AppControl no está implicado en el cifrado ni la transmisión de mensajes. Se trata sencillamente de un mecanismo de control entre aplicaciones. Este método crea un objeto ChannelManager temporal que se elimina una vez utilizado.

  • Método SendChannelName: es un práctico método que administra el envío de un nuevo nombre de canal a un cliente. Este método crea un objeto ChannelManager temporal que se elimina una vez utilizado.

  • Método ReceiveChannelName: es un práctico método que administra la recepción de un nuevo nombre de canal desde un servidor. Este método crea un objeto ChannelManager temporal que se elimina una vez utilizado.

Detalles de la clase ChannelManager

Las aplicaciones Alice, Bob y Mallory están conectadas mediante canalizaciones con nombre que se crean a través de instancias de ChannelManager. Cada aplicación crea y elimina dos tipos de objetos ChannelManager:

  • Objetos de larga duración: Alice y Bob crean un objeto ChannelManager de larga duración al comienzo de sus métodos Run. Utilizan este objeto para transmitir los contactos de ventas. Mallory crea dos objetos ChannelManager de larga duración en su método Run: uno para comunicarse con Alice y otro para comunicarse con Bob. Los canales se utilizan para intercambiar claves criptográficas y mensajes cifrados. Se mantienen hasta que finaliza el método Run; a continuación, se eliminan.

  • Objetos temporales: Los métodos AppControl, ReceiveChannelName y SendChannelName crean objetos ChannelManager temporales para realizar una tarea concreta. Los objetos se eliminan a continuación. Asimismo, en las versiones 4 y 5, Alice envía a Bob una clave de firma digital privada utilizando un objeto ChannelManager temporal.

La clase ChannelManager implementa la interfaz System.IDisposable y administra los modos de transmisión receive y send.

La clase simula un intercambio dinámico entre Alice, Bob y Mallory. En realidad, una canalización únicamente puede tener un modo en cada momento: solo puede ser servidor o cliente. Por ello, las aplicaciones Alice, Bob y Mallory se ejecutan de una manera lineal y meticulosa. Cada aplicación espera a que las canalizaciones se abran y cierren en momentos específicos durante la ejecución del ejemplo. Aunque pueda parecerlo, la comunicación no es asincrónica.

Puede parecer que un administrador de subprocesos está administrando los subprocesos en segundo plano; sin embargo, no se utilizan llamadas de subprocesamiento. El control de tiempo entre procesos solo se logra a través de la cuidadosa intercalación de las llamadas send y receive entre Alice, Bob y Mallory. Como resultado, las tres ventanas parecen comunicarse fácilmente conforme al escenario que se explica en la información general sobre el ejemplo CNG.

Una ventaja de esta implementación es la sincronización, y que el código es simple y lineal. Una desventaja es la falta de solidez: si un cliente de la canalización no se conecta correctamente al servidor, el servidor dejará de responder. Sería mejor seguir un enfoque en el que se utilizara un servidor de canalizaciones multiproceso que administrara este tipo de errores correctamente. Sin embargo, para evitar una mayor complejidad, el ejemplo no adopta este enfoque.

Se crean instancias de la clase ChannelManager desde los métodos Main de Alice, Bob y Mallory y el constructor de clase Communicator del archivo Communicator.cs.

Detalles de uso

La clase ChannelManager se utiliza en cinco contextos diferentes: control de la aplicación, transmisión del nombre de canal, transmisión de mensajes, transmisión de claves de firma digital y transmisión de claves de cifrado públicas. En la lista siguiente, se explican estos conceptos en el orden en el que aparecen en el código fuente.

  1. Control de la aplicación: Alice llama al método InitializeOptions al inicio de su método Main y recibe las opciones de la sesión del usuario. Estas opciones (Version,fMallory y fVerbose) se envían a Bob y a Mallory a través del método AppControl. Si el usuario decide cerrar la aplicación escribiendo la letra "x", el método AppControl envía la cadena "exit" a Bob y Mallory en lugar de las opciones de sesión.

    • El método AppControl de Alice crea dos servidores de canalización ChannelManager temporales: BobControlChannel y MalloryControlChannel.

    • Los métodos AppControl de Mallory y Bob crean clientes de canalización ChannelManager temporales y los conectan a sus respectivos canales de control.

    • Bob y Mallory reciben las opciones de sesión de Alice e inmediatamente eliminan los objetos ChannelManager temporales.

  2. Transmisión del nombre de canal: una vez transmitidas las opciones de sesión, Alice envía un nuevo nombre de canal a Bob.

    • Alice utiliza el método SendChannelName y Bob y Mallory utilizan el método ReceiveChannelName. Cada método crea un servidor o cliente de canalización ChannelManager temporal. Después de enviar o recibir el nombre de canal, la instancia temporal de ChannelManager se elimina.

    • El error de seguridad se produce cuando Mallory intercepta el nuevo nombre de canal llamando a ReceiveChannelName 200 milisegundos antes de que Bob lo haga. Para consultar una explicación sobre este error de seguridad, vea Implementar un ataque de tipo "Man in the middle" (Ejemplo CNG).

  3. Transmisión de mensajes: después de transmitir las opciones de la sesión y el nuevo nombre del canal, Alice, Bob y Mallory crean los objetos Communicator. Los constructores Communicator reciben el nombre del nuevo canal enviado en el paso anterior y lo utilizan para crear instancias de ChannelManager de larga duración. Estos objetos son las únicas instancias de ChannelManager que no son temporales. Se mantienen hasta que se transmite o recibe el último mensaje y, a continuación, se eliminan.

    Nota:

    El objeto ChannelManager creado por Alice encapsula un servidor de la canalización denominado AliceAndBobChannel. Sin embargo, Mallory intercepta el nombre y envía un nombre de canal diferente (AliceAndBobChannel1) a Bob. Bob pasa esta cadena como parámetro name a su constructor Communicator y crea un cliente denominado AliceAndBobChannel1. Este cambio de nombre permite que Mallory suplante a Alice en los mensajes que envía a Bob.

  4. Transmisión de claves de firma digital: Una vez que Alice crea su objeto Communicator, se examina el marcador Version. En la versión 3, Alice envía a Bob una clave de firma a través de la canalización con nombre PublicChannel, donde Mallory la intercepta. En las versiones 4 y 5, Alice crea una instancia confidencial temporal de ChannelManager. Esta instancia se utiliza a continuación para transmitir una clave de firma digital privada a Bob.

    Nota:

    Mallory no conoce esta canalización con nombre privada porque no tienen la versión 4 o 5 del software de mensajería instantánea (IM). Alice sigue utilizando el objeto ChannelManager de mensajería de larga duración para enviar una firma digital falsa a Bob. En las versiones 4 y 5, la herramienta IM de Bob se ha actualizado para que no tenga en cuenta este objeto. Sin embargo, Mallory piensa que la firma es válida, y la utiliza para firmar sus claves criptográficas y sus mensajes. Esto supone su perdición.

  5. Transmisión de claves de cifrado públicas: el marcador Version se examina de nuevo. En la versión 2 y posteriores, el objeto ChannelManager de mensajería de larga duración del paso 3 se utiliza para enviar y recibir claves de cifrado públicas.

Una vez que se intercambian los nombres de canales, las firmas digitales y las claves criptográficas, Alice y Bob utilizan el objeto ChannelManager creado en el paso 3 para transmitir los mensajes.

Vea también

Conceptos

Ejemplo de comunicación segura de criptografía de próxima generación (CNG)

Código fuente ChannelManager.cs (Ejemplo CNG)

Información general sobre el código fuente (Ejemplo CNG)

Referencia

NamedPipeServerStream

NamedPipeClientStream

Historial de cambios

Fecha

Historial

Motivo

Julio de 2008

Se ha agregado un tema.

Mejora de la información.