¿Qué nivel de confianza debo dar a las claves que necesito para el cifrado?

8

Como estoy cifrando las copias de seguridad del servidor, normalmente instalo mi clave GPG pública de un servidor de claves en el conjunto de claves de mi servidor:

gpg --search-keys 6569758F

Importo la clave en mi llavero.

Entonces intento cifrar un archivo:

gpg --encrypt --recipient 6569758F myfile.log

Ahora se me presenta algo como esto:

gpg: EE928AAF: There is no assurance this key belongs to the named user

pub  4096R/EE928AAF 2013-12-05 Naftuli Tzvi Kay <[email protected]>
 Primary key fingerprint: 0E26 BDF1 BD1C 4A16 9571  21A8 8938 1D75 6569 758F
      Subkey fingerprint: 65F4 87F2 C898 F0E7 0377  EBA1 8484 EC48 EE92 8AAF

It is NOT certain that the key belongs to the person named
in the user ID.  If you *really* know what you are doing,
you may answer the next question with yes.

Use this key anyway? (y/N) 

Ahora necesito 'confiar' en la clave. Sin embargo, he encontrado que, a menos que confíe en la clave "en última instancia", es decir, en el nivel 5, recibo esta solicitud cada vez que necesito cifrar algo, lo que no funciona bien para los scripts de shell.

¿Realmente necesito confiar en una clave en última instancia para simplemente cifrar archivos con ella?

    
pregunta Naftuli Kay 06.12.2013 - 22:34
fuente

2 respuestas

5

El título de la publicación y la pregunta real que estás haciendo no coinciden. Si estoy leyendo esto correctamente, está preguntando cuál es la mejor manera de usar su propia clave PGP pública para cifrar las copias de seguridad. Por otro lado, el título de la pregunta es asignar niveles de confianza a las claves para el cifrado. Me parece que estás usando tu propia clave para el cifrado, por lo que asignarle un nivel de confianza no es lo que estás buscando. En mi humilde opinión está utilizando el "modelo de confianza" de GPG incorrecto para el problema de copia de seguridad.

Puedes omitir explícitamente todas las validaciones de claves en GPG cambiando el 'modelo de confianza' para el comando que estás ejecutando. De forma predeterminada, se utiliza el modelo de confianza 'PGP', por lo que GPG espera que marque explícitamente las claves como de confianza. Alternativamente, puede decirle a GPG que use el modelo de confianza 'siempre' que evitará el mensaje que está viendo:

--trust-model always

Creo que esto te dará el comportamiento que estás buscando. Sin embargo, tenga en cuenta que su script está descargando una clave de un host remoto que no controla, por lo que realmente no tiene ninguna garantía de que sea la clave que está esperando (compromiso del servidor clave). Si solo está esperando usar la única clave para cifrar sus copias de seguridad, puede ser suficiente simplemente incrustar la clave pública en su script (no es sensible) y eliminar el servidor de claves de la arquitectura por completo. Esto eliminará toda la confianza en el servidor de claves y simplificará las relaciones de confianza en su solución de respaldo.

Sólo un pensamiento. Espero que esto ayude.

Como se solicita aquí hay un ejemplo. Supongamos que quiero recopilar datos de respaldo en un sistema que administro. Solo quiero que estos datos de copia de seguridad sean recuperables por mí mismo. Para lograr esto, quiero que todos los datos recopilados en el script se cifren con mi clave PGP pública. También asumo que la cuenta de usuario que realiza la copia de seguridad no se usa para nada más que las copias de seguridad, por lo que no hay nada importante en el directorio ~ / .gnupg y que puedo eliminarla sin preocuparme por las claves perdidas.

SIEMPRE HAGA UNA RESPALDO en su directorio .gnupg antes de jugar con esto

La siguiente es una secuencia de comandos bash simple que cifrará parte del texto con una clave pública incrustada en la secuencia de comandos:

#!/bin/bash -e                                                                 

gpg --trust-model always --import <<EOF
-----BEGIN PGP PUBLIC KEY BLOCK-----
Version: GnuPG v1.4.12 (GNU/Linux)

xxxxxx
...
...
-----END PGP PUBLIC KEY BLOCK-----
EOF

echo "backup data" | gpg --trust-model always --armor  --encrypt --recipient [email protected] > backup-data.enc

La 'magia' en este script es el uso del shell ' Aquí Documento '(vea los marcadores EOF) para incrustar mi clave pública en el script mientras la pasa a gpg sobre stdin para importar mi clave antes de realizar la tarea de cifrado / copia de seguridad. Naturalmente, tendrá que poner toda su clave pública blindada ASCII en lugar de las '...' en mi ejemplo. También asegúrese de reemplazar '[email protected]' con la ID asociada a su clave pública. Normalmente este es tu correo electrónico.

Hay un millón de maneras de limpiar este ejemplo y hacerlo más útil. Importar la clave pública en cada ejecución es un poco ridículo, así que verificando si la clave ya está en el anillo es donde empezaría :)

¡Buena suerte!

    
respondido por el flihp 06.12.2013 - 23:41
fuente
1

Al poner la máxima confianza en una clave, la estás definiendo como la tuya propia.

Trust permite que se considere una clave válida al calcular la validez de otras claves. Para ser válido, debe tener una ruta de confianza para esta clave, que se realiza firmándola (o tiene una ruta de firmas de clave a clave, todas confiables).

Esto es bastante confuso al principio, especialmente porque los términos parecen mezclados. Le expliqué la web de confianza en más detalles en esta respuesta.

Si sabe quién es el propietario de la clave y marcó esta opción, solo podría firmar la clave (e incluso enviarla a un servidor de claves). Si no está muy seguro, puede realizar una firma local (que nunca se cargará / exportará) con su propia clave. Ambos se asegurarán de que la clave sea válida, ¡no es necesario que confíe en ella!

    
respondido por el Jens Erat 07.12.2013 - 01:23
fuente

Lea otras preguntas en las etiquetas