¿En qué se diferencian, si es que lo hacen, las claves SSH de las claves asimétricas utilizadas para otros fines?

¿En qué se diferencian las claves SSH de las claves asimétricas utilizadas para otros fines, por ejemplo, la firma de correo electrónico?

Se me pide que pregunte esto, en parte, porque en OS X, hay aplicaciones disponibles para administrar claves SSH (ssh-agent, SSHKeychain, etc.), así como aplicaciones diseñadas para administrar claves GPG (GPG Keychain Access, etc.), y aparentemente ninguno de los dos se encuentra. Sin embargo, no creo que este sea un problema específico de OS X.

¿Es esta separación de preocupaciones porque las claves son de tipos bastante diferentes, o porque están almacenadas en diferentes lugares, o es por alguna otra razón o combinación de razones, por ejemplo, razones históricas?

• Las claves SSH son simplemente pares de claves asimétricas RSA, DSA o ECDSA. Tal par de claves generado por OpenSSH ya puede ser utilizado por OpenSSL y la mayoría de los otros programas.

  (El .pubarchivo de salida ssh-keygenestá en formato específico de OpenSSH, pero eso es irrelevante ya que el archivo "privado" ya contiene claves públicas y privadas).

  Otro software SSH puede tener sus propios formatos de almacenamiento, como RFC 4716 o PPK de PuTTY , pero almacenan la misma información RSA / DSA / ECDSA.

• X.509 (utilizado por SSL, S / MIME) es un poco más complicado: la clave "privada" sigue siendo la misma, pero en lugar de un archivo de clave pública, tiene un "certificado": una estructura ASN.1 que contiene clave pública, nombre de sujeto y emisor, fechas de validez. En los certificados X.509 v3, estarán presentes extensiones como "uso de clave" y "nombre de sujeto alternativo". Todo el certificado está firmado por la clave del emisor (o autofirmado si no hay un emisor separado).

  Puede usar fácilmente un archivo de "clave privada" X.509 para SSH - OpenSSH incluso usa el mismo formato.

  Puede crear un certificado X.509 a partir de un par de claves simple y luego autofirmarlo, o puede crear una "solicitud de certificado" y enviarla para que la firme una autoridad de certificación (CA).

  Para mostrar la información en un certificado X.509, use:

  certtool -i < foo.pem
  certtool -i --inder < foo.crt
  
  openssl x509 -noout -text < foo.pem
  openssl x509 -noout -text -inform der < foo.crt
  

  ( certtooles parte de GnuTLS).

• Las claves OpenPGP (utilizadas por GPG) son las más complicadas. Lo que llama una "clave PGP" o "par de claves PGP" es una estructura compleja llamada "certificado OpenPGP", que contiene:

  • una "clave principal": un par de claves asimétricas, generalmente utilizado para firmar
  • una o más "ID de usuario": etiquetas textuales, generalmente en forma de "Nombre <dirección de correo electrónico @>"
    • al menos uno de ellos está marcado como "ID de usuario principal"
    • para cada ID de usuario, una "firma propia": firma con su propia clave principal
    • para cada ID de usuario, cero o más "firmas" de otros usuarios
    • los paquetes de firma propia también contienen sus algoritmos preferidos (SHA-1, AES, etc.)
  • una o más "subclaves": pares de claves adicionales, el primero generalmente es para cifrado
    • para cada subclave, una firma con la clave primaria
  • cero o más "ID de foto": archivos adjuntos JPEG o PNG que contienen su cara
    • firmado de la misma manera que las ID de usuario
  • cero o más certificados X.509

  Todos los pares de claves tienen fechas de vencimiento y bits de uso: firmar datos, certificar (firmar) claves, cifrar, autenticar a los servicios. La clave primaria por defecto tiene bits "firmar" y "certificar" y la primera subclave es "cifrar". Si agrega una subclave de "autenticación", puede usarla gpg-agentpara la autenticación SSH.

  Para ver qué contiene su certificado:

  gpg --export joe@example.com | gpg -vv
  
  gpg --export joe@example.com | certtool --pgp-certificate-info
  

  ( certtooles parte de GnuTLS).

Los certificados X.509 y sus claves privadas asociadas vienen en varios formatos:

• DER es una codificación binaria de una estructura ASN.1 del certificado. Tales archivos suelen tener .crto .cerextensiones de nombre de archivo ( .deres menos común, pero no no visto).

• Los archivos de formato "PEM" contienen los mismos datos codificados con DER, pero adicionalmente codificados usando Base64 y entre los encabezados "COMENZAR ESTO" y "FINALIZAR ESO". Una extensión de nombre de archivo común es .pem, aunque ambas .crtya .cerveces se usan aquí también (pero nunca .der).

• Para las claves privadas que pertenecen a los certificados, generalmente se usa el formato "PEM": Base64 rodeado de encabezados "BEGIN PRIVATE KEY" (clave en una estructura PKCS # 7) o "BEGIN RSA (o DSA) PRIVATE KEY" (clave simple, OpenSSL formato). A veces la clave está en un .keyarchivo separado , a veces se incluye con el certificado.

• PKCS # 12 y el PFX un poco más antiguo son contenedores cifrados que almacenan tanto el certificado como la clave privada (a menudo también el certificado del emisor). La mayoría de los programas utilizan este formato al exportar o "realizar copias de seguridad" de certificados con claves privadas.

Una situación menos confusa es en OpenPGP: todos los datos siguen el mismo formato binario, y opcionalmente están "blindados" (codificados con Radix64 y entre encabezados tipo PEM).

Almacenado en diferentes lugares y en diferentes formatos (los formatos utilizados por PGP, GnuPG ssh, y varios formatos X.509 diferentes, entre otros, son bastante diferentes). Es posible transcodificar entre ellos, en cierta medida mezclando y combinando las opciones adecuadas a ssh-keygen,pgp , gpg/ gpg2, openssl, etc .; pero en general no vale la pena el esfuerzo. Además, los diferentes formatos de clave admiten diferentes cantidades de información, consshcon la menor información adicional y los formatos X.509 PEM y DER con la mayor cantidad. Además, el llavero OSX es simplemente un almacenamiento cifrado de clave / valor, por lo que cada aplicación generalmente necesita un mecanismo diferente para convertir entre el formato de metadatos + clave nativa del programa y algo que se pueda almacenar en el llavero. (Se aplican preocupaciones similares a la billetera KDE y al llavero GNOME).