Generating and Managing GPG Keys: Best Practices

El estándar OpenPGP, implementado comúnmente a través de GnuPG (GPG), constituye uno de los pilares de la soberanía digital y las comunicaciones seguras en entornos hostiles. No obstante, la seguridad del ecosistema no depende exclusivamente de la solidez matemática de los algoritmos subyacentes, sino de la disciplina operacional aplicada durante la generación, almacenamiento, uso y rotación del material criptográfico. Un diseño deficiente de la infraestructura de claves puede anular por completo las garantías de confidencialidad e integridad, exponiendo a fuentes periodísticas, activistas y analistas a la interceptación o suplantación de identidad.

Selección de primitivas criptográficas: Curvas elípticas frente a RSA

Durante décadas, RSA fue el algoritmo predeterminado para la infraestructura OpenPGP. Sin embargo, los avances en criptoanálisis y la eficiencia computacional exigen una transición hacia la criptografía basada en curvas elípticas (ECC). Específicamente, el par compuesto por Ed25519 (para firma digital y certificación) y Curve25519 / X25519 (para intercambio de claves y cifrado) representa el estándar de oro en seguridad defensiva moderna.

Ventajas operativas de Ed25519

• Longitud de clave y rendimiento: Una clave Ed25519 de 256 bits ofrece un nivel de seguridad comparable a RSA de 3072 bits, con firmas sustancialmente más pequeñas y un cálculo significativamente más rápido tanto en firma como en verificación.
• Resistencia a ataques de canal lateral: Las implementaciones de Ed25519 están diseñadas por defecto para operar en tiempo constante, mitigando vectores de ataque basados en análisis de temporización o consumo energético de la CPU.
• Ausencia de generación de números primos arbitrarios: A diferencia de RSA, donde la selección deficiente de números primos o un generador de números pseudoaleatorios (PRNG) comprometido puede derivar en la factorización prematura del módulo, Ed25519 opera sobre curvas de Edwards bien definidas y auditadas.

Si la compatibilidad estricta con sistemas heredados exige el uso de RSA, nunca se deben utilizar longitudes inferiores a RSA-4096, asumiendo la penalización de rendimiento y el tamaño de las firmas resultantes.

Arquitectura de claves: Separación entre clave primaria y subclaves

Una de las peores prácticas en la administración de GPG es utilizar la clave primaria para las tareas operativas diarias (cifrado, descifrado, firma de correos o commits de Git). El modelo de confianza de OpenPGP separa funcionalmente las capacidades criptográficas mediante un esquema jerárquico de clave primaria y subclaves.

Roles criptográficos y capacidades

GPG asigna cuatro capacidades esenciales que deben mantenerse delimitadas:

• Certificar [C]: Exclusiva de la clave maestra primaria. Se utiliza únicamente para firmar otras claves (declarar confianza), crear subclaves y revocar componentes del certificado.
• Firmar [S]: Asignada a una subclave dedicada para validar la autoría e integridad de mensajes, documentos o código fuente.
• Cifrar [E]: Asignada a una subclave dedicada para el descifrado de información entrante dirigida al usuario.
• Autenticar [A]: Asignada a una subclave opcional, utilizada habitualmente como identidad SSH o para autenticación TLS de cliente.

La regla de oro de la gestión de identidades PGP dicta que la clave primaria (capacidad [C]) debe residir exclusivamente fuera de línea (cold storage). El entorno de trabajo diario sólo debe contener las subclaves operativas [S, E, A].

Generación en un entorno aislado (Air-Gapped)

La generación del par de claves primario debe realizarse en un sistema operativo completamente desconectado de cualquier red física o inalámbrica, preferiblemente ejecutado desde un medio extraíble de sólo lectura (como una distribución Tails o un sistema Linux mínimo en RAM).

Para evitar configuraciones predeterminadas no deseadas, se debe invocar el menú avanzado de GnuPG:

gpg --expert --full-gen-key

El flujo técnico recomendado durante esta fase es el siguiente:

1. Seleccionar la opción (9) ECC and ECC o (11) ECC (set your own capabilities) para forzar Curve 25519.
2. Seleccionar Ed25519 para la clave de certificación principal.
3. Definir un periodo de expiración razonable para las subclaves (máximo 1 a 2 años). La clave primaria puede configurarse sin expiración inmediata o con una expiración mayor, ya que puede extenderse offline en cualquier momento.
4. Generar las subclaves de firma, cifrado y autenticación accediendo a la consola interactiva mediante gpg --expert --edit-key <KEYID> y ejecutando el comando interno addkey.

Estrategia de revocación y copias de seguridad de emergencia

El diseño de un sistema criptográfico debe contemplar el escenario de compromiso del dispositivo o extravío del material privado. La pérdida de control sobre una clave privada sin capacidad de revocarla debilita la red de confianza completa.

Certificados de revocación preventiva

Aunque las versiones contemporáneas de GnuPG generan automáticamente un certificado de revocación en ~/.gnupg/openpgp-revocs.d/, es imperativo generar de forma explícita un certificado independiente y verificar su integridad antes de desplegar la clave:

gpg --output revivacion-identidad.asc --gen-revoke <KEYID>

Este archivo debe almacenarse por separado de la clave privada, impreso en formato físico o resguardado en dispositivos de almacenamiento cifrados independientes.

Copias de seguridad analógicas y digitales

Para el almacenamiento a largo plazo de la clave primaria fuera de línea, se recomiendan dos métodos complementarios:

• Almacenamiento digital redundante: Dos unidades USB cifradas con LUKS (utilizando algoritmos independientes del software GPG) almacenadas en ubicaciones geográficas distintas.
• Copia analógica mediante Paperkey: La herramienta paperkey permite extraer únicamente los bytes de la clave privada secreta, descartando la información de la clave pública redundante. Esto reduce el volumen de datos a una cadena compacta que puede imprimirse en papel resistente o transcribirse mecánicamente:

gpg --export-secret-key <KEYID> | paperkey --output-type raw | base64 > master-key-backup.txt

Aislamiento de la clave primaria y exportación de subclaves

Una vez generadas las subclaves y almacenada la clave primaria en el medio seguro fuera de línea, se debe eliminar la clave maestra del entorno operativo cotidiano:

1. Exportar las subclaves con sus materiales secretos:

   gpg --export-secret-subkeys <KEYID> > subclaves-operativas.asc

2. Exportar la parte pública:

   gpg --export <KEYID> > clave-publica.asc

3. Eliminar el directorio de trabajo completo o eliminar las claves privadas locales:

   gpg --delete-secret-keys <KEYID>

4. Reimportar exclusivamente las subclaves en el equipo de producción:

   gpg --import subclaves-operativas.asc

Al ejecutar gpg --list-secret-keys, la clave primaria aparecerá marcada con sec# en lugar de sec, lo que indica formalmente que el componente privado de la clave maestra no reside en el sistema.

Endurecimiento del archivo de configuración (gpg.conf)

Las configuraciones predeterminadas de GnuPG suelen mantener retrocompatibilidad con especificaciones obsoletas. Para garantizar un estándar criptográfico robusto contra colisiones y ataques estructurales, el archivo ~/.gnupg/gpg.conf debe endurecerse explícitamente:

# Algoritmos criptográficos preferidos
personal-cipher-preferences AES256 AES192 AES
personal-digest-preferences SHA512 SHA384 SHA256
personal-compress-preferences ZLIB BZIP2 ZIP Uncompressed

# Algoritmos declarados para el intercambio
default-preference-list SHA512 SHA384 SHA256 AES256 AES192 AES ZLIB BZIP2 ZIP Uncompressed

# Forzar SHA-512 en firmas de certificación
cert-digest-algo SHA512
s2k-digest-algo SHA512
s2k-cipher-algo AES256

# Privacidad y metadatos
no-emit-version
no-comments
keyid-format 0xlong
with-fingerprint
list-options show-uid-validity
verify-options show-uid-validity

Distribución segura y uso de módulos de seguridad física

Los servidores de claves históricos (keyservers basados en SKS) sufrieron ataques de envenenamiento de certificados que inyectaban firmas no deseadas imposibles de purgar. En la actualidad, la distribución pública debe canalizarse mediante métodos verificables y federados:

• Web Key Directory (WKD): Mecanismo preferido donde el servidor web bajo el dominio del correo electrónico del propietario aloja directamente la clave pública vía HTTPS en un directorio estructurado (/.well-known/openpgpkey/).
• Servidores verificadores: Servicios modernos como keys.openpgp.org, que requieren validación bidireccional por correo antes de publicar el User ID vinculado a la clave.

Uso de Hardware Security Modules (HSM)

Para elevar las defensas contra malware que busque extraer subclaves de la memoria de la máquina de trabajo, el material privado de las subclaves [S, E, A] debe transferirse directamente a dispositivos criptográficos físicos compatibles con el estándar OpenPGP Smart Card (tales como YubiKey o Nitrokey):

gpg --edit-key <KEYID>
# Seleccionar subclave con 'key 1', luego ejecutar:
gpg> keytocard

Al utilizar este enfoque, las operaciones criptográficas se ejecutan dentro del chip seguro del dispositivo; la clave privada nunca entra en contacto con el procesador central ni la memoria RAM del sistema anfitrión, neutralizando fugas de material criptográfico ante intrusiones del sistema operativo.

Conclusión

La viabilidad de OpenPGP como mecanismo de defensa y privacidad descansa en un control estricto de los límites de confianza. La combinación de primitivas elípticas modernas (Ed25519), la separación estricta entre la clave maestra fuera de línea y las subclaves de trabajo, la custodia física en tokens criptográficos y una política clara de revocación estructuran un entorno resistente contra actores estatales y ciberdelincuentes sofisticados. Una clave PGP no es únicamente una herramienta de cifrado; es una infraestructura de identidad criptográfica que exige una gestión técnica intransigente.