¿Cómo suministrar claves privadas y públicas generadas por OpenSSL a las aplicaciones de iOS y Android?

He hecho algo similar a esta configuración y recomendaría ir con una configuración PKI X509 más estándar sobre OpenPGP. Hay un poco más que entender y vale la pena hacer un script si lo usa a menudo, pero se ajustará a su modelo.

Esencialmente desea crear su propia autoridad de certificación (CA). Cuando las nuevas aplicaciones se ponen en línea, crean una clave privada / pública, envuelven la clave pública en un certificado que proporciona una identificación de quién posee esa clave y la envía a la CA para que firme una Solicitud de firma de certificado (CSR). Esta es la forma estándar de aceptar nuevas claves públicas sin generar claves privadas en el servidor. Obviamente, es un punto de ataque, pero con los mismos riesgos que el envío de claves a sus aplicaciones.

Una de las principales ventajas de X509 es la vinculación con su servidor web y HTTPS. La mayoría de (o todos) los servidores web principales son capaces de aceptar un certificado de cliente y asegurarse de que el certificado haya sido firmado por la CA antes de que llegue a su aplicación de servidor y pase la clave pública y el nombre del certificado (CN) a su servidor para obtener información específica del cliente.

Hay muchos lugares en la web para ayudar a configurar las CA de X509 y cómo firmar con ellas y manejar los certificados de clientes, y la mayoría son desalentadoras, pero creo que a largo plazo esto es más adecuado que PGP.

Editar para abordar mejor los aspectos específicos de la pregunta:

Identificar el servidor significa que la aplicación debe conocer y confiar en la CA, que debe ser fácilmente conocida de antemano. La conexión a través de HTTPS puede verificar que el servidor se presente como host.com correcto y que el certificado esté firmado con su CA.

Con este método, simplemente puede almacenar la clave pública y privada en un archivo PEM que es solo texto o una variedad de otros formatos, dependiendo de lo que funcione mejor para su aplicación. Luego lo proporciona en su llamada al servidor web como un certificado de cliente, esto obviamente depende de su biblioteca http (y no sé acerca de Android o iOS), pero estoy seguro de que lo tienen. Luego simplemente realiza las solicitudes a través de POST o cualquier otro medio que desee.

No estoy completamente seguro de lo que estás preguntando; Si sus aplicaciones admiten de forma nativa un formato específico, utilícelo. ¿Hay alguna aplicación específica que te gustaría preguntar?

Si solo desea un formato simple para las aplicaciones que está escribiendo, el formato OpenSSH es agradable y simple (y ampliamente utilizado / compatible). Además, los certificados X.509 son un poco más complicados, pero también son ampliamente compatibles, aunque eso podría ser un poco más allá del alcance de lo que está tratando de hacer (X.509 es una especificación completa para PKI [Infraestructura de clave pública] y PMI [Infraestructura de gestión de privilegios]).

OpenPGP también tiene implementaciones gratuitas (gnupg), y tiene un buen soporte de biblioteca / un buen formato de clave (cuando se usa el armado de ascii).

[OT]: En una nota semi-offtopic, generar la clave privada del lado del servidor y luego dársela al cliente es casi siempre una mala idea que anula el propósito del cifrado de clave pública / privada. En su lugar, debe pre-inicializar a los clientes con la clave pública del servidor, generar una clave privada en el cliente, usar la clave pública del servidor para verificar la conexión (si ya está usando TLS, ha hecho esta parte) y luego enviar la Servidor de la clave pública del cliente. Además, si ya estás usando TLS, no estoy seguro de por qué necesitarías otra capa, entonces, nuevamente, no sé qué caso de uso tenías en mente.

Ejemplos

Para obtener un ejemplo de cada clave en un sistema Unix / Linux:

OpenSSH: ssh-keygen -t rsa -b 2048 -f filename

GnuPg: gpg --keyserver pgp.mit.edu --recv-key 0xEC2C9934 && gpg --armor --export 0xEC2C9934 (descargará y mostrará mi clave pública)

X.509: openssl genrsa -sha512 -out keyfile.key 2048 escupirá una clave privada. Luego puede generar una solicitud de firma de certificado utilizando openssl req -new -key keyfile.key -out keyfile.csr y finalmente un certificado: openssl x509 -req -days 1 -in keyfile.csr -signkey keyfile.key -out keyfile.crt

Pensamientos finales

Después de leer los comentarios, parece que estás buscando más de una solución completa. Si entiendo lo que quiere, creo que la solución ideal sería utilizar certificados X.509. Puede crear su propia CA (Autoridad de certificación) o comprar un certificado de un tercero de confianza en línea (me gusta RapidSSL ). Luego, puede hacer que sus aplicaciones verifiquen las comunicaciones desde el servidor y usar ECDH (Eliptic Curve Diffie-Hellman) para negociar una clave compartida y facilitar comunicaciones seguras (usted dijo que quería una huella pequeña, por lo que creo que ECDH será más rápido de lo normal) . AES256 para el cifrado y SHA2 para la verificación del resumen del mensaje debe proporcionarle una conexión segura, bien soportada y razonablemente baja. Básicamente, solo use TLS y asegúrese de elegir buenas opciones para el tipo de cifrado, el mecanismo de intercambio de claves y la función de resumen de mensajes.