¿Es posible detectar si un mensaje ha sido manipulado, sin usar MAC (es decir, clave compartida) y sin usar un tercero "de confianza" (es decir, autoridad de certificación)?
Estoy bastante seguro de que no lo es, pero me gustaría estar seguro.
Nota: no me importa si alguien más lee el mensaje, simplemente no quiero que puedan modificarlo a lo largo de la ruta de transmisión.
No El destinatario debe saber algo sobre el remitente para detectar la manipulación. De lo contrario, no hay nada que distinga al remitente legítimo de alguien que está manipulando.
Hay algunas opciones para lo que sabe el destinatario:
Para detectar manipulación, primero debe definir manipulación. Usted está recibiendo un mensaje; ¿Qué lo haría un mensaje "manipulado" y no el mensaje "genuino"?
La definición usual de manipulado / genuino usa la fuente del mensaje : en un momento dado en el espacio-tiempo, el mensaje fue ensamblado o verificado por una entidad S , quien declara es correcto Esta es la definición del mensaje genuino: la secuencia de bits correspondiente a esa operación (o inspección) de S . En otro punto en el espacio-tiempo (más tarde, y posiblemente en otro lugar), el verificador V quiere asegurarse de que el mensaje sigue siendo genuino, es decir, la misma secuencia de bits que S saw.
El conocimiento es poder: todos pueden comprar las mismas computadoras, por lo tanto, si la fuente S puede hacer algo que un atacante A no puede hacer, entonces este debe se debe a que S conoce algunos datos específicos (los criptógrafos lo llaman "clave") que A no sabe. De lo contrario, si A sabe todo lo que S sabe, entonces A puede crear mensajes propios que no se puedan distinguir de los mensajes auténticos.
Si ese valor secreto (llamémoslo K ) es conocido tanto por S como por V , entonces a MAC se puede usar. Dicha configuración solo funciona siempre que V tampoco sea un atacante. Si K es conocido solo por S , entonces aún debe ser susceptible de verificación confiable desde V , y entramos en el ámbito de la criptografía asimétrica, con firmas digitales .
En ambos casos, necesitamos ayuda del contexto. Los secretos compartidos no se materializan de la nada; Tampoco los certificados. Podemos tener aproximadamente las siguientes situaciones y soluciones:
S y V se han reunido previamente, o hay un canal seguro para ambos desde un generador confiable de bits aleatorios que solo S y V pueden alcanzar. Solo usa un MAC.
S y V comparten un secreto, pero es de baja entropía (por ejemplo, una contraseña que un humano puede recordar). intercambio de claves autenticado por contraseña (por ejemplo, SRP ) puede ser usado por S y V para expandir ese secreto compartido a una K mejor compartida que resiste diccionario de ataques. Esto implica que S y V pueden, a la vez, hablar entre sí y ejecutar el protocolo PAKE (esto no necesita una línea segura; se puede hacer a través de Internet, pero aún debe suceder en un punto). Una vez que tienen un K compartido, usan un MAC.
S genera un par de claves pública / privada, y V tiene una manera de asegurarse de que lo que ve como "clave pública de S "no ha sido manipulado. Esto permite a V verificar cualquier firma calculada por S . Esto no resuelve su problema, pero lo mueve: la detección de manipulación en el "mensaje" se ha movido a detección de manipulación en la clave pública. Sin embargo, esto puede ayudar, ya que el par de claves pública / privada puede haberse generado y verificado por adelantado, mucho antes de que el mensaje apareciera por primera vez; y tal par de claves puede usarse para proteger varios (muchos) mensajes.
V conoce la clave pública de un tercero confiable T , que usa su clave privada para firmar la clave pública de S . Esta es una extensión del caso anterior, y es básicamente de lo que trata PKI .
El punto importante en todo esto es que ninguna criptografía u otro sistema creará la confianza. La criptografía simplemente mueve la confianza alrededor. Todavía tiene que comenzar en algún lugar, y ese "en algún lugar" es la definición de lo que constituye un "mensaje genuino".
Lea otras preguntas en las etiquetas public-key-infrastructure hmac tampering