¿Puedo usar un certificado de firma de código como un certificado TLS?

3

Por ejemplo, desarrollo un software que es usado por algunos clientes. Ellos firman el software utilizando sus certificados de firma de código. El software tiene un cliente y una parte del servidor que están conectados entre sí mediante TLS.

La parte del cliente funciona en Windows y puedo verificar si la firma digital es correcta o no. Luego puedo extraer el nombre del firmante del certificado (la parte pública) y usarlo para alguna verificación adicional.

¿Puedo usar los certificados de firma de código para la parte del servidor como certificados TLS y verificar el nombre del firmante en lugar de FQDN? Entiendo que no es típico. ¿Es seguro? Por ejemplo, ¿pueden diferentes certificados de firma de código de empresa tener el mismo CN (el nombre del firmante)? ¿Qué problemas adicionales puedo tener aquí?

    
pregunta Eugen 01.11.2016 - 20:23
fuente

3 respuestas

2

Si tiene el control total del cliente, por supuesto puede configurar sus propias rutinas de validación e ignorar las existentes. De hecho, simplemente podría reducir los controles a la validación de la clave pública del certificado (es decir, la fijación). Pero se recomienda seguir los diseños existentes y probados, y no reinventar su propia validación, ya que son cosas críticas y fáciles de desordenar.

No obstante, considerando que, sin embargo, desea utilizar el proceso de validación normal en la medida de lo posible y solo afinarlo cuando sea necesario, puede haber más obstáculos que solo el sujeto que no coincide con el nombre de host de destino: un certificado tiene una clave diferente usos Para la firma de código solo necesitas la capacidad de firmar algo. Pero para usar con TLS también puede necesito el capacidad de utilizar el certificado para keyEncipherment , una función que no es necesaria para la firma de código y que, por lo tanto, podría no ser el uso permitido del certificado. Además, los certificados de servidor TLS generalmente tienen un uso de clave extendido que permite explícitamente el uso para la autenticación del servidor, mientras que los certificados de firma de código no lo necesitan.

Otro problema es que al reutilizar el certificado de firma de código para el servidor probablemente lo exponga más a los ataques. El robo de certificados de firma de código y el uso de estos certificados confiables para firmar malware no es infrecuente y tener la clave privada para este certificado en un host que tal vez esté expuesto en Internet es solo una mala idea, considerando la frecuencia con la que se piratea a dichos hosts.

    
respondido por el Steffen Ullrich 01.11.2016 - 20:58
fuente
1

Desde mi entendimiento de su dominio del problema, creo que no hay mucho que discutir

  
  • Le diste un paquete de software a tu cliente
  •   
  • el cliente tiene un certificado de firma de código, el cliente firma el código (ambas partes parte cliente (CL) y parte servidor (SR))
  •   
  • El cliente instala la parte del cliente en su máquina cliente (CLM) ya que está firmada por Trusted CA (supongo) CLM OS confiará en ella y lo hará   obtener instalado
  •   
  • de manera similar, el SR se instalará en el SRM, es decir, en la máquina del servidor
  •   

hasta ahora, hasta ahora, la parte de firma de código del certificado ha terminado, así que pasemos a su segundo problema

  

¿Puedo usar los certificados de firma de código para la parte del servidor como TLS?   certificados

Como @steffen señaló sobre la extensión USO DE TECLAS

Para que su configuración funcione con las bibliotecas de criptografía estándar, necesitará dos extensiones de uso clave para su configuración

Clave de cifrado:

requerido en el extremo del servidor para que el cliente envíe el material de claves al servidor de forma secreta

Firma digital:

  • Requerido por el servidor para probar su identidad (autenticación de entidad)

  • Necesario para la firma de código

Si estas extensiones están presentes, puede utilizar el certificado para la firma de código y para el certificado del lado del servidor de protocolo de enlace tls

de lo contrario, si estas extensiones no están presentes, tampoco es perjudicial utilizar el mismo certificado para TLS en la medida en que mantiene segura su clave privada al mantener segura su máquina. Desde el punto de vista criptográfico, no es una forma de decir que es inseguro de usar.

  

verifique el nombre del firmante en lugar de FQDN

También depende de usted la precisión con la que mapea la entidad y su prueba asociada, que también es muy fácil de lograr en su caso, ya que necesita mapear el código de identificación del autor (mapéelo con el número de serie a través de su código de software)

    
respondido por el 8zero2.ops 02.11.2016 - 12:54
fuente
0

Hay muchos problemas serios con tu diseño. No seguiría adelante en esta dirección, en lugar de eso, recurriría a la comunicación estándar SSL / TLS con los certificados adecuados para realizar el cifrado y la autenticación de la comunicación.

Pocas cosas que son malas en tu diseño:

1) Los certificados de firma de código están destinados a la firma de código. Un intento de mal uso del certificado rompe la PKI completa.

2) I develop a software which is used by some customers. They sign the software using their code signing certificates - esta es la manera incorrecta. Los clientes NO DEBEN firmar nada que no posean. Una vez que firmen, serán responsables de todo lo que en realidad no hicieron. Es su software y usted es responsable de ello. Puede aprobar su responsabilidad / responsabilidad firmando binarios, pero sus clientes no son responsables. Bajo ciertas circunstancias, esto puede plantear problemas legales.

3)

  

Por ejemplo, ¿pueden tener diferentes certificados de firma de código de empresa el mismo CN (el nombre del firmante)?

en realidad, sí. Dos compañías pueden tener atributos CN idénticos en los certificados de firma de código (sin embargo, el campo de Asunto completo no coincidirá). Esto puede suceder cuando se emiten certificados a individuos y no es raro que los individuos tengan el mismo nombre y apellido. Pero los demás atributos (como se dijo) serán diferentes.

Además, deberá desarrollar su propio procedimiento de validación desde cero, ya que el resultado puede ser rápidamente vulnerable. No intente reinventar la rueda cuando haya estándares probados y probados para usar. La fijación de certificados suena como una buena idea hasta que se enfrenta a la gestión de certificados. Con la fijación de certificados, existen muchos problemas con la administración de certificados y una de las razones por las que esta técnica no se usa mucho en Internet. Vale la pena leer este artículo: ¿Se ha eliminado la clave pública HTTP?

    
respondido por el Crypt32 01.11.2016 - 21:21
fuente

Lea otras preguntas en las etiquetas