Logro de PFS con criptografía de clave pública

  

Estoy tratando de entender cómo funciona Perfect Forward Secrecy (PFS) para las aplicaciones que no son SSL.

Bueno, reiteremos brevemente de qué se trata PFS : desea evitar a cualquiera que obtenga su clave maestra para poder descifrar mensajes él ha capturado de antemano .

Por ejemplo, asumamos el caso de SSL / TLS donde la clave privada del certificado del servidor se ve comprometida. Sin PFS, sería posible que un atacante descifre todos los mensajes que fueron cifrados con esta clave. Más específicamente, la clave privada se usa generalmente para cifrar las claves de sesión, que a cambio se usan para el cifrado de los datos reales. El problema sigue siendo el mismo, solo agrega una capa de abstracción.

  

¿Cómo se implementa esto? ¿Cómo crearía una aplicación (digamos una aplicación de chat) y mantendré cada mensaje (o conversación) en secreto?

Entonces, lo que quieres lograr es intercambiar claves de manera que el compromiso de un solo mensaje no rompa todo tu sistema . En lugar de usar una clave estática, es decir, su clave privada para el intercambio de claves de sesión, debe crear un esquema que se construya alrededor de claves efímeras . Esto es exactamente lo que el intercambio de claves Diffie-Hellman (DHKE) es sobre. El problema con el DHKE clásico es que los socios de comunicación no están autenticados, por lo que Man-in-the-middle los ataques son posibles.

Por lo tanto, debe combinar estos dos esquemas : use RSA para autenticación , y use DHKE para crear claves de sesión efímeras . En una configuración de este tipo, ni el compromiso de una clave de sesión única ni el compromiso de la clave maestra en sí permitirían que un atacante descifre mensajes de otras sesiones anteriores.

Esto funciona muy bien y es básicamente la forma en que se logra PFS en SSL / TLS. Otro ejemplo bastante popular para un esquema de este tipo es Mensajería off-the-record (OTR) , aunque las claves deben verificarse manualmente. , en lugar de a través de una Infraestructura de clave pública basada en RSA.

  

Más específicamente, estoy interesado en cómo Moxie Marlinspike logra esto en TextSecure y otras aplicaciones.

TextSecure se basa esencialmente en OTR . Sin embargo, mejoraron OTR de una manera que lo hace adecuado para aplicaciones móviles. El mayor problema en un entorno móvil es que no puede esperar que ambas partes estén en línea al mismo tiempo. Las conexiones móviles se interrumpen todo el tiempo, por lo que el DHKE clásico se convertiría en un problema, ya que podría tomar mucho tiempo hasta que ambas partes acordaran una clave de sesión, que idealmente se usaría solo para un solo mensaje. Esencialmente, lo que quieres es que el intercambio de claves se suceda de forma asíncrona . Es un poco más complicado que eso, porque TextSecure también resuelve un par de otros problemas, como el descifrado fuera de orden y la prevención de la filtración de metadatos a través de cleartexts.

  

He escuchado que utilizan un protocolo de "racheting" que otorga a cada sesión su propia clave específica que evita el compromiso de la clave privada de uno de los usuarios.

A lo que te refieres es Axolotl Ratchet y encontrarás una descripción detallada de sus objetivos y funcionamiento interno aquí .

  

(por ejemplo, un usuario cifra un mensaje a bob usando la clave pública de bob. ¿Cómo agrego PFS a la ecuación?)

En resumen: no utilice la clave pública de bob para cifrar el mensaje. Use su clave pública para la autenticación, elabore claves efímeras para el cifrado, por ejemplo. utilizando DHKE.

Por lo general, PFS incluye las claves efímeras , es decir, las claves que existen durante la conversación, pero que se desechan más adelante.

Una forma de hacer esto es crear un par de llaves RSA efímero durante la conversación:

• Alice y Bob tienen claves RSA a largo plazo y ambas conocen las claves públicas de los demás.
• Alice genera un par de llaves RSA de 768 bits. Esta es su clave efímera. Ella firma la clave pública efímera con su clave privada a largo plazo y envía la información a Bob.
• Bob recibe el paquete, verifica su autenticidad con la clave pública a largo plazo de Alice y luego guarda una copia de la clave pública efímera de Alice.
• Bob escoge una clave simétrica aleatoria de 128 bits, la cifra con la clave efímera pública de Alice, la firma con su clave privada a largo plazo y la envía a Alice.
• Alice verifica la autenticidad del paquete usando la clave pública de Bob, la descifra con su clave privada efímera.
• Ambas partes ahora conocen una clave de 128 bits que puede usarse para cifrar sus comunicaciones con un cifrado simétrico, por ejemplo. AES.
• Al final de la conversación, Alice descarta su clave privada efímera.

Dado que la clave privada de Alice se destruye al final de la conversación, no hay forma de descubrir qué era la clave simétrica después del hecho, incluso si alguna de sus claves a largo plazo está comprometida.

Esto también se puede lograr con el algoritmo de intercambio de claves Diffie-Hellman de una manera similar: aquí es donde se ve DHE / ECDHE en conjuntos de cifrado.