Seguridad: Todo lo que Sé de Criptografía Asimétrica

(Fellow Architect: this post is also available in English. Read it at http://www.skyscrapr.net/blogs/solution/archive/2006/09/12/295.aspx)

 Estamos  acostumbrados a centrar la autentificacion en el usuario, en la prueba de su identidad mediante una contraseña presentada a modo de credencial

Pero, cómo verificar la autenticidad de otros tipos de activos (assets) más allá del usuario? Por ejemplo, cómo nos aseguramos que, una vez que el usuario se autentificó, todos los mensajes que recibamos de su sesión fueron efectivamente enviados por él? Cómo sabemos que no han sido interceptados y cambiados en el camino?

Ilustro mejor el riesgo al que me estoy refiriendo: una amenaza (threat) siempre presente en comunicaciones a través de redes, es la conocida como "Hombre en el Medio" ("Man in the Middle"). Alguien que nos pincha la línea, filtra el mensaje original, le altera partes sensibles (una cantidad, un monto a transferir, una cuenta destino) y lo reenvía alterado. Como vino de una sesión de alguien que ya había probado su identidad, se lo aceptamos sin percibir que fue alterado

Luego tendremos un problema con nuestro usuario (cliente, etc) cuando repudie la transacción. Va a ser nuestra palabra contra la de él. Y si no somos capaces de demostrar que podemos detectar, con la infraestructura que nosotros mismos habilitamos para las transacciones, al "Hombre en el Medio"… tendremos que afrontar las consecuencias del fraude

Cómo lidiar con esta realidad?

Al rescate llega la Criptografía de Clave Pública (Public-Key Cryptography), también conocida como Criptografía de Clave Asimétrica. La forma en que trabaja este algoritmo es la siguiente:

  • El emisor de un mensaje, antes de enviarlo, le aplica una función que calcula un digesto en base al mensaje mismo mismo (algún valor de hashing, algo así como un checksum)
  • Este digesto es encriptado mediante la aplicación de una clave que sólo el emisor posée. A esta clave se la llama "Clave Privada" ya que nadie más, excepto el emisor, la conoce
  • El digesto encriptado es añadido como parte del mensaje junto con una clave que el receptor necesitará para desencriptarlo. Es nueva clave, disponible para cualquiera, es llamada consecuentemente "Clave Pública"
  • El receptor, entonces, recalcula el digesto a la par que desencripta con la clave pública el digesto recibido, comparando así ambos digestos

El hombre en el medio puede espiar el mensaje pero no lo puede alterar: no tiene la clave privada para encriptarlo el digesto correspondiente al mensaje alterado. En efecto, si llega a tocar un caracter del mensaje, el cálculo del digesto va a arrojar otro valor que el adjunto que viaja encriptado. En consecuencia, va a tener que mandar el digesto original. El receptor del mensaje va comparar ese digesto contra el calculado, y en tanto no coincidan tiene evidencia de que el precinto del mensaje fue violado (tampering)

En conclusión, mensajes correctamente formados, sí o sí son del usuario que se autentificó. Este algoritmo, entonces, cumple su función: evitar el repudio de mensajes (repudiation) y la violación del contenido de los mismos (tampering). No evita en cambio, las miradas indeseadas pero para eso hay, afortunadamente, otros mecanismos de defensa que se aplican en forma complementaria

Ejemplos de uso de encriptación asimétrica hay por todos lados, aunque no estemos al tanto de ello. Por ejemplo, la capacidad de Seguridad de Acceso al Código de .NET (Code-Access Security o CAS) nos permite, entre otras cosas, garantizar que una .dll no pueda ser reemplazada. Cómo? Sencillo:

  • El proveedor de la .dll tiene su clave privada. Con esa clave firma digitalmente el ensamblado (por ejemplo mediante el comando "Assembly Linker" -al.exe-, o mediante el atributo AssemblyKeyFileAttribute)
  • El ensamblado pasa a contener una firma digital en función del nombre, la versión y opcionalmente información de cultura. Esta firma viaja encriptada por la clave privada. Por supuesto, también viaja en él la clave pública, necesaria para desencriptar la firma
  • Cuando ese ensamblado es cargado para ser ejecutado, el CLR (la máquina virtual de .NET) recalcula la firma digital, y la compara contra la desencriptación de la que venía dentro del mismo
  • Si son distintas, el CLR tira un SecurityException. Si alguien distinto al proveedor nos cambia el ensamblado, seguro que van a ser distintas… Excepto que…
  • Sí, excepto que el proveedor trucho use su propio par de claves privada y pública. Pero aún así tenemos como contrarrestarlo: en la consola de administración del framework .NET (Herramientas Administrativas o Administrative Tools, en el Panel de Control) hay una opción que se usa para configurar la seguridad de acceso al código (CAS). En la misma existe una opción para solicitar que se confíe en todos los ensamblados que vengan con una dada clave pública (la que nos pase el proveedor genuino, no el trucho)

Otro ejemplo, más agnóstico, de uso de criptografía asimétrica está presente en la especificación estándar WS-Security, aplicable por ejemplo mediante certificados X.509. Esto está disponible tanto en Windows Communication Foundation (WCF) como en el transitoro Web Services Enhancements (WSE) versión 3.0

Como cierre, quiero destacar una variante de la criptografía de clave pública, usada no con fines de "no repudio" sino para evitar ventilar información (Information Disclosure). En esta variante, el emisor de los mensajes tiene una clave pública (no privada) que usa como argumento para encriptar todo un mensaje, en tanto que sólo el receptor pretendido de ese mensaje tiene la clave privada que lo desencripta. Esta variante evita la inspección no autorizada de los mensajes entrantes, aunque no previene la impostura (spoofing) de la identidad del enviador

Esta entrada fue publicada en Software Architecture. Guarda el enlace permanente.

4 respuestas a Seguridad: Todo lo que Sé de Criptografía Asimétrica

  1. Carlos dijo:

    Claro y conciso el post. El blog, me parece muy interesante.
    Saludos.

  2. Diego dijo:

    Gracias, Carlitos!! Eso estimula y alienta a más. Cómo diste con mi blog?
     
    Btw: congrats por el tuyo. Nutritivo, man!!

  3. Erick dijo:

    No estoy cien porciento seguro, pero el ataque del "hombre en el medio" o "intruder-in-the-middle", se da precisamente en esquemas asimétricos, más específicamente los que usan algo como el protocolo Diffie-Hellman-Merkley (o Diffie-Hellman a secas). Es cuando dos usuarios, digamos Ana y Beto,  comparten claves con un Intruso que se hace pasar como Beto frente a Ana, y como Ana frente a Beto.

  4. Diego dijo:

    Allo Erick,
       si es así tu sapiencia supera meridianamente mis conocimientos — Abrazo

Responder

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión / Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión / Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión / Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión / Cambiar )

Conectando a %s