Actualización 2017-11-05: "TLS-N" y otros
Hace poco me enteré de la existencia de un nuevo proyecto. Algunos muchachos de la universidad de Zúrich están trabajando en algo llamado "TLS-N" que se dedica a llevar el no repudio a TLS. No hay RFC que yo sepa todavía. Pero tienen un papel blanco. No estoy seguro de cuándo / si alguna vez veremos esto en la naturaleza. Pero es una idea interesante. Consulte: enlace
También se mencionan en su documento algunos intentos anteriores de llevar el no repudio a TLS llamado TLS sign y TLS Evidence . Ambos intentos parecen haber muerto hace mucho tiempo.
Tu libro es correcto. No hay repudio para paquetes TLS regulares.
Cuando Alice le dice a Bob "¡Vamos a matar al presidente!" y Bob va a avisar a la policía, entonces Alice siempre puede decir: "Nunca dije eso". Entonces Alice acaba de repudiar la declaración anterior.
Y en TLS regular no hay forma de que Bob pueda demostrar por sí mismo que Alice, de hecho, ha repudiado su declaración anterior.
Por lo tanto, no, el TLS normal NO proporciona no repudio . Así que tu libro era correcto.
Las firmas pueden proporcionar no repudio ...
Ahora porque es eso? El criptográfico asimétrico le permite proporcionar una prueba de autoría mediante el uso de firmas criptográficas . Esto daría de hecho el no repudio. Entonces sería sencillo verificar Sí, que realmente FUE firmado con la clave privada de Alice. Y no se puede salir de ese hecho matemático. (Por supuesto, entonces Alice podría decir: "¡Pero mi llave fue robada!" pero no se puede negar que su clave se usó para firmar ese mensaje en particular).
Entonces, si de hecho se usaran firmas criptográficas para paquetes TLS normales, entonces no serían reputables. Pero las firmas NO se usan para el paquete TLS regular, por lo que tampoco tenemos repudio.
... pero los paquetes TLS tienen MAC en su lugar
En cambio, lo que se usa para demostrar al otro lado, Mi mensaje NO se ha cambiado en el camino es algo que se llama un MAC , un Código de autenticación de mensajes . Las funciones de MAC funcionan de la siguiente manera: se sueltan dos entradas y se obtiene una salida. Una entrada es una clave MAC secreta, la otra entrada es el mensaje que desea proteger. Y lo que cae es como una cadena hexagonal de dos docenas de bytes, denominada Valor MAC . Esa cadena se envía junto con el mensaje cifrado. El destinatario luego alimenta lo mismo a las entradas en la función MAC nuevamente y solo acepta el mensaje descodificado si el valor MAC coincide.
Pero como Alice y Bob conocen la clave secreta de MAC, cualquiera de ellos puede generar valores de MAC para el mensaje que desee. Un mensaje de MAC dice NADA sobre la autoría de Alicia o Bob.
Entonces, si Bob va y le dice a Charlie: ¡Aquí hay algo malvado que dijo Alice! , entonces Alice puede decir con razón: ¡Podrías haberlo escrito tú mismo! .
Y, por lo tanto, no hay repudio.
Alice, ten cuidado
Pero: si hay un tercero de confianza (quizás el empleador de Alice, Charlie) que tiene un volcado de la red de toda la conversación entre Alice y Bob, entonces Alice estará en problemas. Independientemente de las propiedades de no repudio de TLS. Porque Charlie confirma la autenticidad del volcado de red original y Bob proporciona la clave para descifrar la conversación. ¡Por supuesto que Alice todavía podría decir que Charlie está involucrado en esto! Estoy siendo enmarcada! pero básicamente está perdida entonces.