¿Es suficiente un certificado autofirmado para probar la integridad de mi ejecutable?

Es importante que la persona que recibe el archivo lo compare con su clave pública. Cualquiera puede crear un certificado autofirmado, y usted puede poner los metadatos que desee en él. Por lo tanto, dos certificados autofirmados pueden verse y comportarse de manera idéntica, lo único que los diferencia es el par de claves utilizado para firmarlo.

En otras palabras, y respondiendo a su comentario sobre la respuesta de Jeff, no puede visualmente distinguir entre un certificado legítimo y uno falsificado, si, por ejemplo, el sistema operativo o el navegador, o lo que sea, aparece una ventana que aparece sus detalles Los certificados firmados por una autoridad de confianza, OTOH, se mostrarán junto con un nombre / enlace que es más difícil de falsificar (¿casi imposible?)

Pero si su clave pública se publica / envía a sus clientes, pueden verificar (o puede probar más tarde) si el archivo es legítimo o no. Como nadie más conoce su clave privada, no pueden crear un certificado (autofirmado o no) que coincida, incluso si los metadatos tienen el mismo aspecto.

¿A quién quieres probar la integridad del ejecutable?

Si es para ti, puedes simplemente guardar una copia del ejecutable que enviaste y compararlo.

Si es para alguien más, un certificado autofirmado no servirá de nada. Cualquier persona que cambie el archivo ejecutable también puede generar un certificado autofirmado con propiedades idénticas a las suyas y volver a firmar el archivo ejecutable.

  

Me gustaría saber si esto sucede alguna vez, para que si alguien se queja   sobre lo que recibieron puedo comprobar si el archivo es realmente el que yo   Enviado o si alguien lo modificó.

Responderé en esta pregunta-lado . La suma de comprobación del archivo (publicada) le dará a sus clientes y menos dolor de cabeza con un nivel de protección comparable, incluso más: nadie podrá obtener el mismo hash SHA2 en el archivo modificado, como en el no modificado.

Su idea suena correcta. Nadie debería poder cambiar el archivo y hacer que la firma siga funcionando. Y nadie debería poder crear otra firma digital sin su clave privada.

Una firma prueba que el propietario del certificado firmó el objeto. Nada mas. Si ese certificado se puede rastrear fácilmente hasta usted, entonces prueba que fue firmado por usted.

Ahora, si alguien en quien el usuario confía (por ejemplo, Microsoft, Verisign, etc.) firma su certificado, eso prueba que firmaron su certificado. Es de suponer que solo lo harán si confían en usted .

Teóricamente, tienes una cadena de confianza que se remonta al usuario, cada uno confía en el siguiente y, por lo tanto, el usuario confía en ti de manera implícita.

Si, por otro lado, su certificado no está firmado por nadie (es decir, un certificado autofirmado, ya que todos los certificados tienen una firma), entonces el usuario no confía implícitamente en su firma , pero si tienen alguna forma de verificar que el certificado es suyo (por ejemplo, se lo entregue personalmente), su certificado puede convertirse en otro ancla de confianza, al igual que los certificados proporcionados por Verisign o Microsoft.

para que, si alguien se queja de lo que recibió, pueda comprobar si el archivo es realmente el que envié o si alguien lo modificó.

La forma tradicional de verificar si un archivo se modifica es usar la utilidad " md5sum ", o la utilidad (probablemente superior) " sha256sum " utilidad.

Muchas organizaciones utilizan esta técnica para verificar que los archivos, descargados de "sitios espejo" que están convenientemente cerca (y por lo tanto más rápidos que la descarga del "sitio original" en algún otro continente), no hayan sido modificados de manera maliciosa o accidental en algún lugar en la ruta del original, al sitio reflejado, al destino final. a b c d e

Al usar esas utilidades, alguien con la versión original del archivo genera un hash md5 corto o un hash sha256 corto (o ambos) del archivo original, y almacena ese hash corto en algún archivo de texto en alguna parte. (Por lo general, en el "sitio original" y en cada sitio espejo).

Más tarde, alguien con un archivo cuestionable ejecuta la misma utilidad, produciendo un valor hash nuevo. Si el valor de hash nuevo es idéntico al hash producido a partir del archivo original (ese hash generalmente se obtiene del "sitio original", posiblemente utilizando un navegador web y https y TLS), entonces puede estar seguro de que el archivo cuestionable es, de hecho, idéntico al archivo original.

Algunas personas paranoicas descargan la suma de hash de varios "sitios espejo" y otras fuentes. (Esto es rápido, porque la suma de hash es muy corta; mucho más rápido que volver a descargar el archivo completo de todas esas fuentes). La probabilidad de que todas esas fuentes hayan sido subvertidas es cada vez más improbable a medida que se consultan más fuentes.

(Dado que está generando el archivo ejecutable original, tenga en cuenta que la recompilación de exactamente los mismos archivos de origen con exactamente el mismo compilador generalmente produce un archivo ejecutable ligeramente diferente, lo que resulta en un hash completamente diferente. Consulte " ¿Cómo verifica que 2 copias de un ejecutable VB 6 provienen de la misma base de código? " para más detalles).

Hay muchas utilidades que se construyen sobre md4sum o sha256sum.

• md5deep y hashdeep puede hacer un "resumen" de una carpeta completa en un determinado momento, tal vez su directorio de inicio, o el directorio / bin, o la carpeta raíz de un disco duro completo. Luego, más tarde, le puede decir exactamente qué archivos se han agregado, eliminado o cambiado desde que se realizó ese resumen. Cuando los hashes coinciden, puede estar seguro de que los archivos ejecutables no han sido infectados por un virus después de la instantánea original; esto incluso detecta nuevos virus que ningún escáner de virus aún no reconoce. (Los escáneres de virus siguen siendo útiles para detectar archivos infectados por un virus antes de la instantánea original).

• bittorrent usa sha1 para confirmar que las partes de un archivo descargado desde máquinas completamente no confiables son idénticas a las piezas originales de ese archivo.

• rsync usa md5sum para verificar rápidamente si el archivo local es idéntico a la copia maestra de un archivo en algún servidor de archivos remoto. Si son diferentes, asume que la copia local es una versión obsoleta y descarga automáticamente las diferencias entre los dos archivos, modificando el archivo local hasta que se vuelva idéntico al archivo maestro remoto.

Estoy bastante seguro de que se podría desarrollar algún protocolo utilizando un certificado autofirmado que funcionaría tan bien como usar sha256sum; pero no veo cómo este nuevo protocolo daría ventajas sobre la verificación de sha256sum utilizada comúnmente.