Firmar las solicitudes de la API con una clave privada: ¿Este escenario de entrega de claves parece seguro?

  

Si C descubre el NOMBRE DE USUARIO DE D, entonces pueden acceder a los datos de D que parecen ser incluso menos seguros que el ID de usuario / contraseña.

¿Pueden ellos? B podría generar un certificado separado para cada cliente que solo se puede utilizar para acceder a sus datos. El encabezado del nombre de usuario X puede ser simplemente metadatos. Pero es posible que desee probar esto para estar seguro. Especialmente cuando no preguntan a qué cliente deben firmar el certificado.

La empresa A como proveedor de software deberá asegurarse de que:

Con certificado integrado:

• A envía un CSR separado a B con una clave diferente para cada cliente C y D.
• A incrusta la clave privada respectiva en el ejecutable antes entrega a C o D. Esto expone la clave privada durante la entrega.

Sin certificado suministrado (solución alternativa)

• El propio cliente presenta una CSR con su clave generada en B
• A simplemente entrega el software sin una clave, pero el requisito de importar una clave antes de usarla.

De cualquier manera, la clave privada nunca debe viajar a B. Esto no es un requisito, solo la clave pública debe estar firmada. La solución alternativa es más robusta con muchos clientes y asume el riesgo de fugas clave de la Compañía A.

¡Ni siquiera intentes autenticar aplicaciones, solo autentican usuarios! Y si desea procedimientos serios de gestión de PKI, una clave privada siempre debe estar bajo el control exclusivo de su propietario: es un requisito clave para la no repudio. Si A crea la CSR y luego de que B la firma se los entrega a C y D, un administrador de la compañía A podría guardar una copia de las claves privadas y luego realizar cualquier operación en nombre de C y D.

El uso forzado de software de una compañía debe cuidarse a nivel legal, no técnico. Solo la autenticación C y D debe estar garantizada por certificados.

Y si cree que sus requisitos de seguridad le permiten a una compañía crear las claves privadas para C y D, entonces entiendo que solo necesita autenticación con contraseña y el uso de PKI es excesivo y no agrega seguridad adicional.

Lo siguiente no es más que mi propia opinión de lo que podría ser una forma posible. Primero, crear un certificado completo en A (incluida la clave privada) y enviarlo como un archivo PKCS12 a C y D es definitivamente una mala práctica y debe evitarse. Pero como A proporciona un software de escritorio a sus clientes, la generación del certificado podría incluirse en el procedimiento de instalación:

• el procedimiento de instalación genera un par de claves (automáticamente, con la ayuda de la biblioteca OpenSSL)
• solicita al cliente una identificación (por ejemplo, un número de licencia), un nombre y los incluye en una CSR
• la CSR se envía a A (con HTTPS), firmada automáticamente por A después de que se haya controlado la ID y el certificado (sin la clave) sea almacenado por A indexado por la ID. Si un certificado antiguo se asoció con esa ID, se revoca (según los requisitos de su negocio, esta parte podría requerir un procedimiento manual ...)
• el certificado firmado por A se devuelve al procedimiento de instalación
• el procedimiento de instalación almacena el certificado en el almacén del sistema (asumiendo Windows aquí); normalmente se requiere que el usuario valide el UAC

Una vez hecho esto, el cliente tiene un certificado firmado por A y la clave nunca ha salido de la máquina cliente

En otro lado, A le proporciona a B su propio certificado de firma (¡no la clave!), y una dirección de lista de revocación de certificados o cualquier otra forma de controlar si un certificado ha sido revocado

Cuando un cliente desea usar el servicio web de B con el software A, puede autenticar su conexión HTTPS con su certificado: un software sabe cómo usarlo porque el procedimiento de instalación lo ha instalado. B puede validar el certificado con el de A, e incluso puede controlar que el certificado no haya sido revocado.

La separación de responsabilidad es:

• A es responsable de la PKI: firmando certificados de clientes, manteniendo una CRL y la lista de los clientes
• B es responsable de su servicio web. Se basan en A para la seguridad de los certificados (certificado de enlace < - > cliente)
• C & D es responsable de la seguridad de su clave privada. Deben poder solicitar un nuevo certificado si se compromete a perderlo al reiniciar (parte de) el procedimiento de instalación. En ese caso, el anterior debe alimentar la CRL

Como solo los procedimientos automáticos están involucrados en la generación de certificados, todavía estamos lejos de los verdaderos requisitos de no rechazo, y el programa de instalación requerirá algún trabajo pero:

• esto se basa en los procedimientos y protocolos de certificados X509 estándar
• las responsabilidades o A, B y C & D son claras