Use un hash precalculado para firmar un archivo con GnuPG

Esto es posible, aunque en un nivel ligeramente diferente de lo que estás preguntando. En lugar de ejecutar el comando gpg en la máquina de firmas, en su lugar, ejecuta gpg-agent y reenvía el socket del gpg-agent a la máquina que calcula la firma. En realidad, esto es lo mismo que está solicitando, excepto que ejecutaría el comando gpg / gpg2 en la máquina que calcula el hash en lugar de la que calcula la firma.

Como alternativa, puede colocar la clave privada en una tarjeta inteligente OpenPGP, que puede actuar como un agente clave.

Sin embargo, para una mejor seguridad, es posible que desee envolver al agente de gpg en un servicio que cree registros de auditoría de cualquier cosa que se haya firmado o cifrado. Muchas tarjetas inteligentes OpenPGP hacen esto, aunque el espacio de almacenamiento limitado en una tarjeta puede limitar el espacio de almacenamiento de registro de una tarjeta inteligente.

  

¿Hay alguna desventaja en este aspecto de seguridad?

Sí, la máquina de firma estará ciega firmando todo lo que la máquina de hash le dice que firme. No tiene forma de imponer una política sobre lo que está firmando (por ejemplo, el directorio frobnicate debe estar firmado por otra persona, sekrit.c debe contener la cadena "42", el rastreador de problemas debe estar configurado en el estado "Spline Reticulated"). confiar en la máquina de hash para verificar la política de firma.

Estoy bastante seguro de que no hay manera de que no se pueda distinguir con el GnuPG estándar. GnuPG es de código abierto, por lo que, por supuesto, podría modificarlo, e implementa un estándar abierto para poder usar otra implementación (que puede obtener / usar la clave de firma) que probablemente sea más fácil de modificar, como BouncyCastle al menos en la versión de Java (que yo uso; no soy un dotnetter) (aunque si puede instalar Java en un sistema de seguridad importante puede ser un argumento en propio).

Una alternativa que es un IME bastante común y aceptada es utilizar dos etapas :

• use sha1sum (ya no se prefiere) o sha256sum o similar para crear un archivo (pequeño), p. ej. 'hash' que contiene el nombre y (hex) hash del archivo (s) real (es); Si hay varios componentes y / o variantes y / o archivos relacionados de otra manera en una versión lógica, puede colocar múltiples hashes y nombres en un archivo 'hash'

• PGP separó el signo o borra el pequeño archivo 'hash'

El destinatario correspondiente

• PGP verifica el archivo 'hash'

• utiliza sha256sum -c hash o similar para verificar que los archivos reales coincidan con los hash en el archivo 'hash'

Esto permite a un destinatario que no tiene una implementación PGP (o no puede obtener o no confía en la clave de firma, pero eso es menos probable) pero que puede obtener el archivo 'hash' con la suficiente seguridad, por ejemplo. desde un sitio web de HTTPS, para verificar el (los) archivo (s), que irían de lo difícil a lo imposible con solo una firma PGP.

Obviamente, debe asegurarse de que los valores hash en el método A, o el archivo 'hash' en el método B, se transfieran de la máquina de firma a través de un canal que no se puede bloquear o manipulado por cualquier adversario, y cada uno de ellos está seguro por sí mismo.

Esta es una pregunta interesante. Lamentablemente, no tengo una buena respuesta para ti, solo algunas cosas más en las que pensar.

Estoy pensando en las siguientes líneas:

La ganancia más obvia que se obtiene al mover el paso de firma a su propio host es que puede aislar la clave privada utilizada para las firmas en una máquina que solo hace la firma, y por lo tanto, protegerla mejor de ser robada o mal utilizada.

Pero luego empiezo a preguntarme: ¿es eso realmente relevante?

Si mantiene el código de firma y la clave en otro host, deberá implementar algún tipo de servicio que envíe al hash de firma los hashes (o archivos) para firmar, y el host de firma le devolverá una firma válida. .

Ahora suponga que el host que tiene los archivos de lanzamiento está violado. Lo más probable es que el atacante pueda usar el servicio de firma para obtener la firma del contenido que elija (y si no lo hace, eso significa que no tiene acceso completo a la raíz y que no habría obtenido acceso a una sesión de claves de firma directamente en el host, tampoco). Entonces, aunque no controla la clave privada utilizada para la firma, aún puede obtener lo que quiere: firmas válidas en el contenido elegido.

Básicamente, míralo desde esta perspectiva: la seguridad del host que contiene los archivos de lanzamiento es absolutamente crítica. Si se infringe, y un atacante logra cambiar los archivos de la versión, realmente no importará que no tenga acceso a la clave de firma.

Además, al separar el paso de firma, ha creado una nueva vía de ataque: si un atacante no puede obtener acceso al servidor que guarda los archivos de la versión, podría intentar acceder al servicio de firma. Si puede hacerse pasar por el servidor que conserva los archivos de lanzamiento, o si no puede obtener acceso al servicio, también habrá perdido.

Entonces, ¿qué ha ganado exactamente en seguridad al separar el host de archivos y el host de firma? Si su principal razón para no firmar los archivos de la versión donde están, pero hacerlo en un host diferente, es de hecho proteger la clave, ¿no podría usar una clave maestra para firmar una clave de firma con ella? Proteja la clave maestra ¿Manteniéndolo fuera de línea y utilizando la clave de firma directamente en el host que tiene los archivos de lanzamiento?

Si se infringió el host, puede revocar la clave de firma y crear una nueva, nuevamente firmada por la clave maestra.