Elimine la criptografía de clave pública GPG innecesaria bajo el capó

Antecedentes :

1. Algunos programas existentes, como git-annex ( cifrado git-annex ) y pass , delegan la criptografía a GPG , "una implementación completa y gratuita del estándar OpenPGP ". Más específicamente, estos programas se basan en los ID de clave GPG como una forma de interactuar con GPG:

   • GPG se utiliza para crear y administrar pares de claves públicas / privadas GPG.

   • El programa recibe instrucciones de utilizar un par de claves públicas / privadas GPG específicas a través de su ID de clave.

   Si bien confiar en GPG es bueno y recomendable, la forma específica de hacerlo (a través de ID de clave GPG) conduce a un uso posiblemente innecesario de la criptografía de clave pública.

2. La criptografía de clave pública / asimétrica aborda algunos casos de uso específicos que, en términos generales, implican la transferencia segura de información entre una parte confiable y varias partes no confiables. Si alguien decide usar passpara almacenar sus propias contraseñas en un repositorio público de git, no hay una parte que no sea de confianza en este esquema para justificar el uso de la criptografía asimétrica.

3. La criptografía tradicional / simétrica es potencialmente más segura que la criptografía asimétrica. Por ejemplo, existen algoritmos cuánticos que rompen la criptografía asimétrica, pero aún no existen computadoras cuánticas para ejecutarlos. Si bien estos desarrollos no están garantizados, no se conocen debilidades similares (potenciales) para la criptografía simétrica.

4. La criptografía asimétrica se beneficia de 2 capas distintas de seguridad:

   (a) la clave privada está cifrada simétricamente con una frase de contraseña

   (b) la clave privada (encriptada) se mantiene en una ubicación segura

   Por lo tanto, por ejemplo, (a) no agrega nada a la seguridad de la criptografía asimétrica mientras (b) se mantenga. Es perfectamente válido (aunque no aconsejable) hacer una criptografía asimétrica con una frase de contraseña vacía.

   La criptografía simétrica normal, con una sola clave privada, solo proporciona seguridad de tipo (a). Si se reemplaza la criptografía asimétrica por la criptografía simétrica, sería bueno mantener ambos niveles de seguridad (a) y (b). Una forma de hacerlo es con 2 niveles simétricos:

   • generar una cadena aleatoria privada

   • cifrar simétricamente una cadena aleatoria privada usando una frase de contraseña, almacenar de forma privada

   • cifrar simétricamente el mensaje con una cadena aleatoria privada, almacenar públicamente

5. A continuación se describe lo que sucede debajo del capó cuando un programa como passGPG utiliza una identificación de clave GPG. (Suponga que la criptografía de clave pública es RSA y la criptografía simétrica es AES). Primero, GPG se usa para:

   (i) cree un par de claves pública / privada RSA

   (ii) La clave pública RSA no está encriptada, se almacena de forma privada (disco duro) o públicamente (servidor de claves)

   (iii) Clave privada RSA con cifrado AES con frase de contraseña, almacenar en privado

   A continuación, después del cifrado OpenPGP , así es como funciona el cifrado:

   (iv) generar clave de sesión aleatoria

   (v) Mensaje de cifrado AES con clave de sesión, almacenar públicamente

   (vi) Clave de sesión cifrada RSA con clave pública RSA, almacenar públicamente

   Observe que el mensaje se ve comprometida por romper o bien (v) o (vi).

Vulnerabilidad potencial innecesaria :

Supongamos que en el futuro se desarrollan computadoras cuánticas y que RSA no funciona. (Para los paranoicos, supongamos que RSA ya está roto.) Si bien esto traerá cambios en la forma en que hacemos cosas como la banca en línea, también tendrá un impacto negativo completamente innecesario en la seguridad de los datos creados por pass/ git-annex.

Lo malo que sea esto depende de si la clave pública RSA de (ii) anterior se almacena pública o privadamente. Si se almacena públicamente, los datos ya están comprometidos: un atacante puede descifrar (vi) obtener la clave de sesión, luego descifrar (v) con la clave de sesión para obtener el mensaje. Si la clave pública RSA de (ii) en realidad se mantiene privada, la seguridad de los datos se reduce a (b), la seguridad del medio que contiene la clave pública RSA, lo que equivale a realizar un cifrado asimétrico sin una frase de contraseña.

Esta vulnerabilidad, exagerada o no, es completamente innecesaria, ya que se debe al uso innecesario de la criptografía de clave pública inherente a la interfaz existente entre programas como pass/ git-annexy GPG (a través de ID de clave GPG).

Pregunta :

¿Existe una forma "relativamente fácil" de:

• eliminar el uso de cifrado asimétrico cuando GPG se utiliza debajo del capó a través de ID-s de clave GPG

• continuar usando GPG para administrar claves como antes

• mantener la seguridad de 2 niveles mencionada en 4 como (a) y (b)

El esquema completo que busco es:

(i ') genera una cadena aleatoria privada

(ii ') Cadena aleatoria privada con cifrado AES con frase de contraseña, almacenar en privado

(iii ') Mensaje cifrado AES con cadena privada aleatoria, almacenar públicamente

Entiendo cómo hacer cada uno de estos pasos por separado, pero lo que estoy preguntando es la mejor manera de conectar esa "solución" en la forma en que los programas pueden usar GPG a través de ID de clave GPG. Específicamente, espero que dichos programas emitan llamadas externas del formulario gpg --encrypt --recipient <keyid>y gpg --decrypt.

Conclusión : Parece que no hay una bala mágica, e interceptar estas llamadas utilizando un gpgscript de envoltura es la única forma de hacerlo. Quizás GPG debería considerar este problema en el futuro.

Criptografía simétrica en OpenPGP

Al leer su pregunta, creo que está confundiendo algunos términos y principios criptográficos. No existe el cifrado simétrico con claves privadas. El cifrado simétrico se basa en una clave de sesión (también llamada bloque de cifrado), mientras que la criptografía de clave pública / privada (asimétrica) se basa en pares de claves para las operaciones de cifrado (clave pública) y descifrado (clave privada).

OpenPGP generalmente usa un enfoque de criptografía híbrida: el mensaje (datos, archivos, ...) se encripta usando encriptación simétrica y una clave de sesión única y aleatoria. La clave de sesión se cifra mediante criptografía de clave pública / privada. Esto combina las ventajas de la criptografía de clave simétrica y pública / privada: el cifrado simétrico es muy rápido, pero necesita un secreto compartido; mientras que la criptografía de clave pública / privada permite una gestión de claves poderosa y claves públicas y privadas separadas mientras es terriblemente lenta para grandes cantidades de datos.

El cifrado simétrico de OpenPGP hace lo mismo, pero deriva la clave de sesión de una frase de contraseña. Dependiendo de la configuración, se agrega algo de sal en este proceso (y GnuPG tiene valores predeterminados razonables aquí). No hay claves públicas o privadas (como las que tendría con RSA) involucradas. En GnuPG, exactamente esto es posible aplicando la --symmetricopción.

¿Hay alguna manera de hacer que gpg realice cifrado puramente simétrico de tal manera que una frase de contraseña solo se use para proteger una clave privada, al igual que en el cifrado asimétrico? Naturalmente, tanto la frase de contraseña como la clave privada serían necesarias para el descifrado.

Si buscas algo como "¿puedo almacenar la clave de sesión por separado, encriptada por una frase de contraseña en lugar de depender de la función de cadena a clave de OpenPGP y cifrar esta clave de sesión con una frase de contraseña": no, esto no es posible dentro de El protocolo OpenPGP. Pero puede imitar prácticamente dicha operación al tener un par de claves públicas / privadas almacenadas juntas en un solo lugar, aún encriptadas con una frase de contraseña. La frase de contraseña se usaría para descifrar la clave privada siempre que se use.

(Por otro lado, creo que la sal MK almacenada en un encabezado LUKS logra algo similar: perder eso y la frase de contraseña sola no puede descifrar el contenedor).

No, la sal se almacena en los encabezados de cifrado del mensaje (o contenedor de cifrado en el caso de LUKS). No se puede comparar con una clave, y tampoco es secreto. La sal se usa para prevenir ataques de la tabla del arco iris al unirla con la frase de contraseña antes de calcular la clave de sesión.

Anulación de claves de sesión

En sus actualizaciones, refinó sus objetivos.

El esquema completo que busco es:

(i ') genera una cadena aleatoria privada

(ii ') Cadena aleatoria privada con cifrado AES con frase de contraseña, almacenar en privado

(iii ') Mensaje cifrado AES con cadena privada aleatoria, almacenar públicamente

No puede alcanzar exactamente esto, pero GnuPG conoce una forma (no estandarizada) de extraer y definir claves de sesión para usar. De man gpg:

--show-session-key

Mostrar la clave de sesión utilizada para un mensaje. Consulte --override-session-keyla contraparte de esta opción.

Creemos que Key Escrow es algo malo; sin embargo, el usuario debe tener la libertad de decidir si ir a prisión o revelar el contenido de un mensaje específico sin comprometer todos los mensajes encriptados para una clave secreta. NO LO USE A MENOS QUE SEA REALMENTE FORZADO A HACERLO.

--override-session-key string

No use la clave pública sino la cadena de clave de sesión. El formato de esta cadena es el mismo que el impreso por --show-session-key. Esta opción normalmente no se usa, pero resulta útil en caso de que alguien lo obligue a revelar el contenido de un mensaje cifrado; Con esta opción, puede hacerlo sin entregar la clave secreta.

Puede usar estas opciones para extraer la clave de sesión, cifrarla por separado con una frase de contraseña y guardarla en algún lugar. Para usarlo, deberá volver a cifrarlo con la frase de contraseña y pasarlo a GnuPG. Por supuesto, esto se puede lograr a través de algún script de envoltura o medios similares. Esto es lo más cercano que puede llegar a través de GnuPG (esto va más allá de lo que especifica OpenPGP, las opciones son específicas de GnuPG). Estas opciones no se consideran realmente utilizadas por los desarrolladores para el trabajo diario.

No usaría mal GnuPG y OpenPGP para este tipo de operación. Puede usar fácilmente OpenSSL y probablemente también GnuTLS para esto, y sin usar modos de operación esotéricos no estandarizados y scripts de envoltura.