He leído en firma digital y se afirma que proporciona no repudio.
Suponiendo que Alice firma el mensaje con su clave privada y lo envía a Bob, Bob puede usar la clave pública de Alice para verificar la firma, por lo que Alice no puede negar el envío del mensaje. Esto solo prueba que Alice es el remitente del mensaje.
¿Cómo puede Alice tener pruebas de que Bob ha recibido el mensaje enviado por Alice?
TL; DR Cualquiera puede enviar un mensaje y decir que es de Alice si no está firmado; No hay forma de que Alice demuestre que no envió esos mensajes sin firmar. Sin embargo, Alice puede probar que envió un mensaje firmándolo con una clave privada. De manera similar, cualquiera puede decir que Bob leyó un mensaje y Bob no puede probar que no lo hizo. Pero Bob puede probar que leyó un mensaje firmándolo con su clave privada.
Un pequeño punto lateral, voy a hacer una distinción aquí entre haber recibido y leer un mensaje. Puedo enviar un correo electrónico a su servidor de correo (y la red confirmará que se envió), pero si su servidor ignora todos los datos entrantes, aunque la red diga que fue recibida por su firewall, no significa que el servidor de correo realmente lee el mensaje o tiene acceso a él de cualquier manera.
En una buena criptografía, se supone que todos pueden recibir el mensaje , pero solo el destinatario sangrado puede leer . A pesar de que Alicia aquí en realidad no está encriptando específicamente para Bob, asumiremos que el mensaje se publica de alguna manera pública que garantiza que Bob podría recibirlo si quisiera, pero encriptado solo Bob puede leerlo (aunque técnicamente no lo puedas cifrar, solo requiere que Bob inicie sesión en Gmail con su nombre de usuario y contraseña, pero con el mismo principio).
En tal caso, no hay forma de que Bob demuestre que no ha recibido el mensaje ; después de todo, Bob podía descargar (recibir) el correo electrónico de Alice desde el servidor de correo a su computadora, pero no abrirlo (leerlo). Si el mensaje estaba encriptado, podría guardar el mensaje y su clave privada en una computadora que no esté en red, descifrarlo y leerlo allí, grabando la computadora una vez que haya terminado. Nadie podría saber si descifró con éxito y leyó el mensaje o no.
Sin embargo, en cualquier momento, Bob puede probar que ha leído el mensaje firmando el mensaje descifrado que Alice envió y devolviendo la firma. La única forma en que podía tener acceso y firmar la versión descifrada (que incluiría haber leído el correo electrónico no cifrado de su cuenta de Gmail) era si lo había leído.
Addendum: Idealmente, Bob firmaría el mensaje con su propia clave privada , pero esto no es estrictamente necesario. Mientras el mensaje esté "encriptado" (o enviado de manera segura) de alguna manera que solo Bob pueda leerlo, el único que posiblemente tenga acceso y firme el mensaje "descifrado" es Bob *. Si el mensaje no está cifrado o no se envía de forma segura, cualquier persona podría firmar el mensaje de Alice con cualquier clave, afirmando que fue Bob quien lo firmó.
* Técnicamente, hay una segunda persona que podría firmar el mensaje descifrado: desde que Alice le escribió el correo electrónico a Bob, ella tiene acceso al mensaje no cifrado y podría firmarlo, afirmando ser Bob. Si solo quiere saber si Bob leyó su mensaje, sería tonto de su parte hacerlo. Sin embargo, si Alice quiere demostrar a las autoridades que fue Bob quien leyó su correo electrónico, Bob necesitaría para firmar el mensaje descifrado con su clave privada (a la que Alice no tendría acceso).
En la práctica, a menos que Bob envíe un recibo firmado, no tiene suerte.
El problema criptográfico subyacente se llama intercambio justo . Si considera un protocolo de red tal que Alice y Bob desean enviarse unos a otros elementos de datos (por ejemplo, en su caso, un correo electrónico de Alice a Bob y un recibo de Bob a Alice; pero también funciona como modelo para los pagos). entonces Alice y Bob enviarán mensajes. Llamemos a ma el elemento que se va a transmitir de Alicia a Bob, y mb el elemento que Debería ir de bob a alicia. Cuando se reproduzca el protocolo de intercambio, en algún momento de la secuencia de mensajes, Alice obtendrá suficiente información para poder reconstruir mb . Ese punto será inmediatamente después de la recepción por parte de Alice de un mensaje de protocolo de Bob; antes del mensaje, Alice no sabe lo suficiente como para reconstruir ma , y después de que lo haga. Del mismo modo, Bob también obtendrá suficiente información para reconstruir mb justo después de haber recibido algún mensaje de Alice.
El punto difícil es que no existe la simultaneidad. No puede asegurarse de que dos personas remotas (Alice y Bob) envíen mensajes al mismo tiempo . Así, Alice y Bob obtienen todo lo que necesitan en momentos necesariamente distintos. Supongamos que Alice obtiene su elemento primero; entonces ella simplemente puede dejar de responder en ese punto. Bob nunca obtendrá el elemento de Alice, mientras que Alice obtendrá el de Bob. El intercambio es injusto.
Para obtener una intuición sobre lo que explico anteriormente: supongamos un protocolo simple mediante el cual Alice envía un correo electrónico a Bob, luego Bob envía un recibo firmado. En ese caso, Bob podría recibir el correo electrónico y negarse a enviar el recibo; Alice no tendría pruebas. Para solucionarlo, es posible que desee diseñar el protocolo de modo que Bob envíe el recibo primero , y luego Alice envíe el correo electrónico. En ese caso, Alice podría hacer trampa al obtener un recibo de Bob, luego negarse a completar el protocolo y enviar el correo electrónico.
Lo que quiero decir aquí es que la falla es fundamental. No puede haber un protocolo de dos partes, por complejo y complicado que sea, lo que garantiza un intercambio justo. Esto se debe a la falta de simultaneidad.
Ahora, los resultados imposibles nunca han desanimado a las personas a intentarlo. En su mayoría, hay dos métodos para obtener un protocolo de intercambio justo:
Haz que los tramposos paguen por ello. Por ejemplo, Alice envía un correo electrónico cifrado a Bob, con una clave simétrica Ka . Bob envía un correo electrónico cifrado a Alice, con una clave simétrica Kb . Alice y Bob luego se envían las llaves, poco a poco, una a la vez. Cualquiera de los dos puede rescatar el protocolo en cualquier momento, con un conocimiento parcial de la clave, y tratar de completar el descifrado a través de una búsqueda exhaustiva de los bits de clave faltantes. Un tramposo tendrá una ventaja sobre el otro, pero solo por un bit en la fuerza bruta resultante. Quedan algunas injusticias, pero solo una pequeña.
Para que este protocolo funcione, se deben aplicar algunas matemáticas adicionales, para que Alice y Bob puedan probarse mutuamente que los "mensajes cifrados" que enviaron son las cosas genuinas, y no algunos fragmentos de basura aleatoria. Hay muchos detalles que cuidar.
Tenga un tercero de confianza. Este es el modelo de los servicios postales existentes en todo el mundo. Alice le da la carta al servicio postal; el cartero luego se asegura de que Bob recibirá la carta solo después de haber firmado el recibo. Esto funciona porque tanto Alice como Bob confían en el cartero: Bob sabe que el cartero le dará la carta y, por lo tanto, no tiene ningún problema en firmar el recibo antes de tener la carta en sus manos; Alice sabe que el cartero no le dará la carta a Bob sin recibir primero un recibo, y el cartero le enviará el recibo a Alice.
Los correos electrónicos estándar no siguen ningún método en este momento. Algunas personas ejecutan servicios basados en la Web en los que desempeñan el papel de un tercero de confianza; No estoy seguro de que ninguno de ellos haya alcanzado ningún nivel de éxito comercial significativo. No tengo conocimiento de ninguna implementación implementada en un protocolo de intercambio criptográfico justo.
Si desea requerir a Bob, debe avisarle a Alice cada vez que Bob haya recibido un mensaje, que yo sepa, no existe ningún sistema de este tipo integrado en los sistemas criptográficos más comunes. Necesitaría salir un poco de la criptografía y requerir un servidor que rastree cada vez que se descargue un mensaje desde allí.
Por ejemplo, Alice podría enviar una URL secreta a Bob que le dice dónde puede encontrar el mensaje. Cuando Bob abre esa URL, el servidor en el otro extremo rastrea que Bob ha accedido a la URL, envía un recibo a Alice y envía los datos a Bob. Si quiere ser pedante, siempre existe la posibilidad de que Bob diga que la solicitud de la URL no se completó, y aunque envió una solicitud de un mensaje, hubo un problema en la red, y nunca recibió ni leyó los datos.
Se suponía que la siguiente parte era un comentario, no parte de la respuesta, pero es demasiado largo para el campo de comentarios:
Puede diseñar un sistema criptográfico elaborado donde cada vez que Bob accede a la URL, recibe (1) un solo carácter del mensaje y (2) una pequeña cantidad de datos que debe firmar con su clave privada. Almacena el carácter (lo anexa a los datos que ya ha recibido) y luego firma y envía el bit de datos para obtener el siguiente carácter del mensaje.
Por lo tanto,Alicia puede probar exactamente qué caracteres del mensaje recibió Bob. Bueno, casi exactamente . Tenga en cuenta que Bob siempre podría decir "Recibí 499 caracteres, pero no el número 500, por lo tanto, no recibí el mensaje completo". asumiendo que se negó a enviar la prueba de trabajo para el último personaje que recibió.
Alicia también podría hacer esto por mensaje en lugar de por carácter. En cada mensaje, Alice envía instrucciones sobre cómo descifrar el mensaje de texto (tal vez incluyendo un teclado de una sola vez). Nunca puede probar que Bob ha leído el último mensaje que envió, pero si puede probar que Bob ha leído un solo mensaje , puede probar que Bob leyó todos los mensajes antes de ese .
Solo hay una forma de que Alice demuestre verdaderamente que Bob ha recibido su mensaje:
Incluso con la clave asimétrica, solo puede tener garantías razonables de que el canal de comunicación es seguro y que el destinatario deseado está recibiendo sus mensajes.
Puede garantizar que la clave privada de Alice se utilizó para cifrar un mensaje. Puede garantizar que la clave privada de Bob se usó para firmar la recepción de un mensaje. Lo que no puede probar es si Alicia o Bob eran los portadores de esas claves en el momento de la transmisión.
Mi punto es que no hay manera de garantizar, de manera matemática, la comunicación segura de los mensajes distribuidos. Su mejor escenario de caso se enfrenta a una asíntota de ladrillo que no se puede superar, por lo que se deben evitar palabras como "prueba" y "garantía". Tu mejor escenario es "Ehh, eso es lo suficientemente cerca".
La única forma en que Alice puede garantizar que Bob recibe su mensaje es entregárselo físicamente, y eso solo es cierto si Alice puede identificar físicamente a Bob, sin fallar.
Lea otras preguntas en las etiquetas authentication certificates