Herramientas de desarrollo · Calculadora de hash SHA
Una suma de verificación coincidente no es una firma: integridad versus autenticidad
· Por qué es importante
sha-256 criptografía seguridad
Un SHA-256 publicado permite a los usuarios detectar una descarga corrupta, pero si el atacante controla la página, también controla la suma de comprobación. Esta publicación separa la integridad de la autenticidad y explica qué agregan las firmas.
La suma de comprobación en la misma página que la descarga: por qué protege contra la corrupción pero no contra un host comprometido
Una versión de software se publica con una suma de verificación SHA-256 en la misma página que la descarga. Los usuarios pueden recuperar el archivo, aplicar hash y comparar el resultado con el valor publicado. Si coinciden, la descarga no está dañada. Esta es una verificación de integridad y es una verificación real y útil. Sin embargo, si un atacante compromete el servidor web que aloja la versión, puede reemplazar el binario, volver a calcular su SHA-256 y actualizar la suma de comprobación en la página. El usuario verifica la suma de verificación y el malware del atacante parece provenir del editor. El sistema funcionó exactamente como se diseñó, pero no respondió la pregunta que el usuario pensó que estaba haciendo.
Esto no es una falla de la suma de verificación en sí. Es una observación correcta sobre lo que hace y no hace una suma de comprobación. Una suma de verificación demuestra que dos copias de datos son idénticas. No prueba quién creó los datos. Esa es la distinción entre integridad y autenticidad, y combinarlas es uno de los errores de seguridad más comunes en la verificación de liberaciones. Muchos sistemas fallan no porque sus sumas de verificación sean incorrectas, sino porque los usuarios confían en ellos para responder preguntas que no pueden responder.
Lo que prueba un hash: que dos entradas son los mismos bytes y nada sobre quién las produjo
La integridad es una propiedad de los datos mismos. Si tiene un archivo y su SHA-256, y el archivo no ha sido modificado, el hash coincide. El hash demuestra que cada byte no ha cambiado desde que se calculó. Si el archivo resultó dañado por un error de transmisión, una falla del disco o un bit volteado en un cable de red, el hash no coincidirá. Esto es lo que hacen bien las sumas de comprobación. Son excelentes para detectar accidentes y corrupción aleatoria. Fallan contra un adversario que también puede calcular hashes.
La autenticidad es una propiedad de la afirmación sobre quién produjo los datos. La pregunta "¿este archivo proviene del editor en el que confío?" es fundamentalmente diferente de la pregunta "¿se ha modificado este archivo?" Un hash por sí solo no puede responder a la pregunta de autenticidad porque cualquiera puede calcular un hash. El atacante que modifica el archivo puede calcular el nuevo hash y publicarlo con la misma facilidad que lo haría el editor legítimo. El hash es simétrico; Tanto el defensor como el atacante tienen la misma capacidad computacional.
El requisito del canal confiable: por qué una suma de verificación es tan confiable como el lugar donde la obtuvo
El requisito del canal confiable es la información clave. Una suma de verificación es tan confiable como el canal por el que llegó. Si descarga el binario del software del CDN oficial del editor y descarga la suma de verificación del mismo servidor, recorrieron el mismo camino. Comprometer el servidor significa que un atacante controla ambos. La suma de comprobación proporciona defensa contra la corrupción durante la entrega (un archivo dañado no coincidirá), pero no contra un atacante que controla la fuente. La suma de comprobación y el archivo comparten un único punto de error.
Si la suma de verificación se publicara por separado, en un servidor diferente, con diferentes controles de acceso, entonces proporcionaría más defensa. Un atacante que comprometa el sitio principal tendría que comprometer ambas ubicaciones para falsificar un par coincidente. Esto es mejor, pero aún depende de que dos puntos de control independientes permanezcan seguros. El atacante ahora debe violar dos sistemas en lugar de uno, lo que aumenta el costo del ataque. Pero todavía no es una prueba de autenticidad; es simplemente un ataque más caro.
Las firmas vinculan un hash a una identidad: cómo firmar el resumen con una clave privada agrega autenticidad
Una firma digital soluciona esto vinculando los datos a una identidad mediante criptografía. El editor genera un par de claves: una clave privada que mantiene en secreto y una clave pública que publica. Firman el archivo calculando un resumen y luego cifrándolo con su clave privada. El resultado es la firma. Un usuario verifica la firma descifrándola con la clave pública del editor y verificando que el resultado coincida con el resumen calculado del archivo recibido. La criptografía crea una asimetría que la suma de verificación no puede lograr.
Si esto funciona, se prueban dos cosas: los datos coinciden con el resumen que firmó el editor y la clave privada utilizada para firmarlo coincide con la clave pública publicada. Eso demuestra que lo creó el editor, no solo que lo hizo un atacante. La clave pública debe llegar a través de un canal seguro (generalmente un certificado de una autoridad certificadora confiable), pero una vez que tenga la clave pública, puede verificar las firmas de ese editor de manera indefinida. El ataque ahora requiere robar la clave privada, lo cual es mucho más difícil que comprometer un servidor web.
Ejemplo resuelto: tres escenarios de amenazas (espejo corrupto, página comprometida, información privilegiada maliciosa) y qué suma de verificación y firma detecta cada uno
Tres escenarios de amenazas ilustran la diferencia. Escenario uno: el espejo de descarga está dañado por un error aleatorio. La suma de control lo atrapa; la firma lo capta. Ambos funcionan igual de bien porque ninguno necesita derrotar a un atacante. Escenario dos: el espejo se ve comprometido por un atacante que reemplaza el archivo y la suma de comprobación. La suma de control no protege; la firma sigue funcionando porque el atacante no tiene la clave privada y no puede falsificar una firma válida. El atacante puede publicar cualquier cosa, pero la firma demuestra que no proviene del editor.
Escenario tres: la CDN está comprometida pero la firma se publicó a través de un canal diferente. No se puede confiar en la suma de verificación de la CDN, pero la verificación de la firma aún funciona, porque la verificación de integridad está vinculada criptográficamente a la clave del editor, no al canal. El atacante ahora debe falsificar una firma, que requiere la clave privada. La firma es la única verificación que sobrevive al compromiso del servidor. Por eso las firmas son necesarias para la autenticidad; son la única herramienta que demuestra la identidad a pesar del compromiso del canal.
La función de TLS y sus límites: la seguridad del transporte protege la descarga en vuelo, no el servidor del editor
La seguridad del transporte protege la conexión con el host nombrado por el certificado. Puede evitar que un observador en la ruta sustituya los bytes de descarga, pero no puede hacer que el origen de un editor comprometido sea honesto. Si ese origen proporciona un archivo modificado y una suma de verificación recién calculada sobre TLS válido, ambos llegan intactos y aún describen contenido controlado por el atacante.
Es por eso que el transporte, la integridad y la autenticidad son capas separadas. TLS protege un canal, un resumen compara bytes y una firma vincula el resultado de la verificación al control de una clave privada. Ninguna capa debe describirse como prueba de la propiedad proporcionada por otra, incluso cuando un flujo de trabajo de lanzamiento combina sensatamente las tres.
Lo que esto no cubre: distribución de claves y raíces de confianza, que son la parte difícil de las firmas.
La distribución de claves es el límite estricto que esta calculadora de resumen no cruza. Un verificador de firmas aún necesita una clave pública auténtica o una cadena de certificados y una política de rotación, revocación y algoritmos aceptables. Una firma matemáticamente válida bajo una clave que no es de confianza sólo prueba que el titular de esa clave que no es de confianza firmó los bytes.
En consecuencia, los escenarios trabajados terminan cuando ya está disponible una clave confiable. No prescriben fijación de certificados, infraestructura de clave pública ni ceremonias de liberación de claves. Esas opciones de implementación necesitan su propio diseño revisado; ToolAcre proporciona el resumen simple que puede firmarse, no la raíz de confianza utilizada para validar una identidad.
Conclusión: sumas de verificación de integridad, firmas de autenticidad: la calculadora de hash SHA ToolAcre calcula resúmenes; verificar quién los publicó es un paso aparte
La calculadora de hash SHA de ToolAcre calcula el lado de integridad de esta verificación. Úselo para codificar el archivo descargado y compararlo con un valor publicado. Si coinciden, la descarga no está dañada. Pero si coinciden porque un atacante reescribió ambos, la verificación de integridad por sí sola no podrá detectarlo. La herramienta es honesta acerca de esta limitación y no pretende verificar la autenticidad. Sólo por motivos de integridad, las sumas de verificación son rápidas y buenas. Para la autenticidad, necesita firmas. TLS proporciona seguridad de transporte para la descarga misma. La conexión al servidor está cifrada y autenticada, por lo que un atacante en la red no puede modificar el archivo en tránsito. Sin embargo, TLS no ayuda si el servidor está comprometido. Un servidor comprometido puede servir cualquier archivo a través de cualquier conexión TLS segura. Esta es la razón por la que la verificación a nivel de aplicación (sumas de verificación y firmas) es importante independientemente de la seguridad del transporte.
Un patrón común en las versiones de software es publicar tanto sumas de verificación como firmas. Las sumas de verificación son convenientes; los usuarios pueden verificarlos rápidamente con un comando de shell de una línea. Las firmas brindan autenticidad a los usuarios que tienen la clave pública del editor. Un usuario puede verificar primero la suma de verificación para obtener un pase rápido de integridad y luego verificar la firma con una clave almacenada en su conjunto de claves GPG para verificar su autenticidad. Los dos controles tienen diferentes propósitos y se pueden superponer para una defensa en profundidad. La parte difícil de las firmas es la distribución de claves y la confianza. Necesita la clave pública del editor y debe confiar en que realmente es suya. Este es el problema que las autoridades certificadoras deben resolver: firman certificados de editor y los certificados de CA raíz vienen precargados en los navegadores y sistemas operativos. Para un proyecto más pequeño, puede publicar una clave GPG en un sitio web reforzado independiente o en un servidor de claves públicas. La suma de control es barata de verificar; las firmas requieren administrar raíces de confianza. La complejidad adicional es el precio de la autenticidad.