Pregunta:
¿Se prueba automáticamente el "no repudio", dados los otros tres principios de seguridad de la información?
KeithS
2013-05-22 22:20:25 UTC
view on stackexchange narkive permalink

Solo para decirlo, los cuatro principios son:

  • Confidencialidad : se puede probar que el mensaje que recibe el destinatario no ha sido leído por nadie más desde que fue codificado.
  • Integridad : se puede probar que el mensaje que recibe el destinatario no ha sido modificado desde que fue codificado.
  • Autenticidad fuerte>: se puede probar que el mensaje que recibe el destinatario ha sido codificado por (editar) un remitente identificado positivamente.
  • No repudio - El remitente, dado un mensaje recibido por un destinatario, no puede negar válidamente que el mensaje fue enviado por él o que no era el contenido original enviado por él.

Este último punto parece redundante. Si puede probar que el remitente envió el mensaje y, por separado, demostrar que nadie ha cambiado (o incluso visto) el mensaje mientras estaba en tránsito, entonces la combinación se prueba por definición; que el remitente y nadie más envió exactamente ese mensaje y nada más.

... Al menos esa es mi opinión. Entonces, la pregunta es, ¿existe una situación (además del compromiso de secretos criptográficos, que indican una culpabilidad diferente por parte del remitente) en la que se puede verificar la confidencialidad e integridad del mensaje, y la autenticidad del mensaje y su remitente , pero ¿el remitente aún puede repudiar válidamente el mensaje?

EDITAR: CodesInChaos hace un muy buen punto; puede iniciar una conversación confidencial con una parte remota e intercambiar información, y demostrar que la información no se leyó ni se modificó, y que solo pudo provenir de la parte con la que abrió el canal. Todo esto sin tener ni idea de con quién estás hablando.

Sin embargo, esto socava el punto de "autenticidad". Si algo es "auténtico" o "genuino", es lo que parece y / o lo que su proveedor dice que es. En las comunicaciones, la noción misma de que un mensaje es "auténtico" implica que su fuente declarada es su fuente real. Para que el mensaje sea "autenticado" como proveniente de alguien, por lo tanto, debe saber quién es ese alguien en primer lugar.

Por lo tanto, tal vez se requiera un cambio en la definición de "Autenticidad": "El se puede probar que el mensaje que recibe el destinatario ha sido codificado por un remitente identificado positivamente ". Si no puede identificar al remitente, no puede autenticar el mensaje porque, en parte, tiene ese remitente como origen y, por lo tanto, el supuesto remitente puede afirmar que es falso. Esto es cierto incluso si se puede demostrar que el mensaje es confidencial, sin cambios y que proviene de una fuente definida ubicación .

Puede autenticarse en una verificación específica de una manera que otros no puedan validar (porque ese verificador específico podría haber falsificado la firma). A menudo, este esquema de autenticación es preferible a una firma digital.
Como nota al margen, puede ver el no repudio como puramente técnico y culpar a un par de claves en particular, o como legal cuando también necesita vincularse de forma segura a un usuario. Este último es mucho más difícil en la práctica. Supongo que solo estás hablando de la parte técnica.
Sí, sobre todo. Suponemos, a los efectos de esta pregunta, que ningún secreto criptográfico está comprometido; ese es un problema diferente.
¿De dónde sacas estos "cuatro principios"? Siempre lo he escuchado como tres: "CIA". CIA no es Confidencialidad, Integridad, Autenticidad. Es Confidencialidad, Integridad, *** Disponibilidad ***. La autenticidad y el no repudio serían un subconjunto de la integridad, creo.
@Iszi: la disponibilidad es un quinto principio, separado de todos los demás mencionados. El modelo de la CIA generalmente se relaciona con el almacenamiento de información; Evite que personas no autorizadas lo obtengan, proteja su exactitud y manténgalo disponible para personas autorizadas. Dos principios adicionales se sacuden cuando llega el momento de comunicarlo; asegúrese de que la parte con la que se está comunicando sea quien dice ser y que lo que "escuchó" es lo que "dijo", y asegúrese de que ninguna de las partes pueda negar que la comunicación ocurrió.
@KeithS http: // en.wikipedia.org / wiki / Information_security # Key_concepts
@KeithS - Incluso en los días del Libro Naranja, la CIA siempre fue Confidencialidad, Integridad y Disponibilidad. La autenticidad, el no repudio y otros son extras en el tema del modelo de industria generalmente aceptado.
Tres respuestas:
CodesInChaos
2013-05-22 22:55:52 UTC
view on stackexchange narkive permalink

Un protocolo simple que puede ser verificado por un determinado usuario de destino pero no por un tercero:

  1. Use un intercambio de claves Diffe-Hellman en su clave y la clave del receptor
  2. Utilice la clave compartida para cifrar un mensaje y agregar una MAC

Este protocolo ofrece las tres primeras propiedades, pero no la cuarta. Entonces la respuesta es NO.

Cualquiera que conozca el secreto compartido puede falsificar el MAC. Pero dado que, de forma predeterminada, solo el remitente y el destinatario lo saben, el mensaje aún está autenticado como proveniente de ese remitente en lo que respecta a la recepción legítima.

Pero la recepción no puede probar quién envió el mensaje , por lo que el esquema no proporciona no repudio.

Un protocolo popular que firma sus datos, proporcionando no repudio (técnico) son los correos electrónicos encriptados GPG, un protocolo popular que solo usa MAC para el usuario los datos son TLS. Algunos protocolos como OTR hacen todo lo posible para aumentar la negabilidad tanto como sea posible (por ejemplo, filtrando claves MAC obsoletas) sin dejar de proporcionar las tres primeras propiedades a los dos usuarios legítimos.

... sí, pero a primera vista esto no es diferente a si elijo confiar en un certificado autofirmado al iniciar un protocolo de enlace TLS. El hecho de que solo tú y yo sepamos una clave y podamos comunicarnos * confidencialmente * y con * integridad *, no significa que realmente sepa quién eres y, por lo tanto, puedo verificar que los mensajes que recibo provienen de quien espero que lo hagan. . Yo diría que esto no proporciona * autenticación *, porque verificar un mensaje como genuino, autenticarlo, implica la identificación positiva del remitente como la parte que * debería * enviar el mensaje en primer lugar.
@KeithS La diferencia no se trata de cómo elige con qué clave pública desea comunicarse / confiar. Esa es una preocupación ortogonal. Se trata de cómo se usa la clave. Con GPG, el mensaje se firma, con TLS se intercambia una clave simétrica y se usa para MAC el mensaje real. Un MAC no puede demostrar a terceros quién escribió algo, una firma digital sí.
Correcto, pero TLS permite la autenticación de parte remota durante el protocolo de enlace, a través del intercambio de certificados, independientemente del uso de la clave intercambiada. Autenticar al * remitente * no solo como la parte con la que comenzó la conversación, sino también como la parte con la que * quería * comenzar la conversación, es clave para autenticar los * mensajes * intercambiados como genuinos. Por lo tanto, se deduciría que el esquema D-H al que me refería en realidad no proporciona autenticación y, por lo tanto, no puede proporcionar no rep. Quizás eso requiera un cambio en la definición de "autenticidad" de mi OP.
@KeithS No entiendo lo que quiere decir. Supongo que se conocen las claves públicas de ambos lados. El problema de distribución de claves es el mismo sin importar qué criptografía utilice. Una vez que conozca las claves, puede calcular una clave compartida con DH y MAC el mensaje. Esto le demuestra al destinatario que envió el mensaje, pero el destinatario no puede probarlo a nadie más. Nadie puede falsificar el remitente de dicho mensaje DH + MAC a menos que el remitente legítimo o el destinatario legítimo filtren alguna clave.
He editado el OP. El problema está en definir "auténtico" como que de alguna manera no requiere la identificación del remitente del mundo real. Puedo iniciar un intercambio de claves seguro asimétricamente, ya sea basado en el esquema RSA o D-H, con cualquier dirección IP en Internet que comprenda la solicitud que estoy haciendo. Puedo afirmar que el canal de comunicación resultante es confidencial y, si se utiliza un modo de cifrado basado en MAC, los mensajes intercambiados no se modifican. Los mensajes siguen siendo basura porque no sé y no puedo probar quién los envió, por lo que no puedo afirmar que los mensajes sean "auténticos".
@KeithS Vincular un par de claves asimétricas a largo plazo a una persona real es un problema difícil, sí. Pero no hay diferencia entre DH y firmas digitales en ese sentido. Siempre necesita alguna forma de averiguar qué clave pública pertenece al remitente. Supongo que todo el mundo sabe que la clave `A` pertenece a Alice y la clave B pertenece a Bob. En esa situación, si Alice envía un mensaje a Bob y lo firma, Bob puede demostrarles a todos qué mensaje le envió Alice. Con DH Bob todavía sabe que el mensaje vino de Alice, pero no puede demostrárselo a nadie más.
¿Cómo? ¿Cómo sabría Bob que llegó un mensaje de Alice cuando usaba D-H? El esquema no verifica la identidad de ninguna de las partes; cualquiera puede generar un componente de clave aleatorio y usarlo junto con la base de clave modulada de la otra parte para configurar una clave compartida. La página de Wikipedia lo llama específicamente un protocolo de acuerdo de claves * anónimo, no autenticado *. Ese es mi punto; debe autenticar al remitente para autenticar cualquier mensaje de un remitente, y si no lo hace, no puede tener no repudio.
@KeithS Cuando calcula el secreto compartido de la clave a largo plazo de Alice y Bob, ninguna de las partes puede elegir ese secreto compartido. El conocimiento de este secreto demuestra que usted conoce la clave privada de uno de los dos usuarios legítimos, o uno de ellos le filtró la clave compartida. Como Bob sabe que él mismo no escribió el mensaje, la única otra posibilidad es que Alice lo haya escrito. ANON_DH en TLS no está autenticado, porque ambos lados usan una clave efímera. Pero nada le impide tener una clave DH a largo plazo y usarla para autenticarse a través de MAC. Es mi forma favorita de autenticación.
Pero, ¿cómo sabe Bob que está hablando con Alice en primer lugar? Puede que sepa que la otra parte de la conversación escribió el mensaje (porque él no lo hizo y nadie más podría haberlo hecho), pero no sabe quién es esa otra parte. Los MAC son para la verificación de la integridad de los mensajes; prueba que el mensaje es exactamente lo que envió la otra parte (y en realidad vino de la otra parte), pero no hay validación de identidad inherente en él. ¿Quizás está sugiriendo usar SPEKE (variante DH basada en contraseña)?
@KeithS Pero, ¿cómo sabe Bob que Alice firmó un mensaje? Debido a que se utilizó la clave de Alice, Bob asume que fue Alice quien la firmó. Lo mismo para DH. Si la otra parte utilizó la clave a largo plazo de Alice para el intercambio de claves, Bob asume que fue Alice quien la envió. Si Alice realiza un intercambio de claves con su clave pública a largo plazo con una clave de la que Bob es propiedad exclusiva, y luego calcula un MAC utilizando la clave compartida, le demostró (a Bob) que conoce la clave compartida y, por lo tanto, es la única partido aparte de él mismo que podría haber escrito ese mensaje.
Todavía no entiendo; ¿Cuál es la "clave a largo plazo" de Alice en términos de DH? ¿Es su secreto, * a *, o el generador * g * o el módulo principal * p *, o algo que se usa para generar uno o más de ellos, como una contraseña compartida? Para que Bob sepa que es Alice, Bob tendría que saber algo que, en el sencillo esquema efímero de DH, solo Alice sabría.
Sin embargo, estoy empezando a comprender que hay formas de usar DH para verificar que la otra persona es quien dice ser, pero no poder demostrárselo a nadie más después del hecho, que es un requisito práctico de no repudio en el sentido legal. SPEKE es una posibilidad; incluso renunciar a la contraseña utilizada en el intercambio de claves no es una prueba para la posteridad de que Alice envió un mensaje determinado.
D.W.
2013-05-24 13:33:38 UTC
view on stackexchange narkive permalink

Busque en este sitio sobre no repudio. Encontrarás mucha información sobre el tema. En particular, descubrirá que el no repudio no es una propiedad técnica (al contrario de lo que los criptógrafos podrían decirle); es principalmente una propiedad socio-legal. Por lo tanto, el no repudio no puede garantizarse únicamente a través de medios técnicos: solo puede lograrse mediante una combinación de mecanismos técnicos, sociales y legales.

En consecuencia, la confidencialidad, la integridad y la disponibilidad no son suficientes para garantizar no repudio.

Agregue a eso: el no repudio no existe (puede afirmar que su clave privada ha sido comprometida, repudiando así la firma). El no repudio no es deseable (¿y si su clave privada realmente ESTÁ comprometida?) Si una transacción * realmente ** no fue ** por usted *, entonces *** necesita *** para poder repudiarla.
Ben
2014-01-15 21:46:14 UTC
view on stackexchange narkive permalink

Considere el modelo CIA, IAA.

  • Confidencialidad : manténgase en secreto de aquellos no autorizados
  • Integridad : Evite la manipulación no autorizada
  • Disponibilidad : asegúrese de que las partes autorizadas puedan acceder a los datos

La CIA se trata de permitir acciones que están autorizadas y prevenir acciones que no son. Entonces, ¿qué acciones están autorizadas? Eso es IAA:

  • Identificación : quién digo ser (p. Ej., Nombre de usuario, certificado digital),
  • Autenticación : Cómo lo demuestro (contraseña, firma),
  • Autorización : qué puede hacer esa persona, por ejemplo seguridad basada en roles.

Claramente, no puede autorizar una acción sin primero identificar y autenticar a la persona que la realiza.

Imagínese realizar un pedido. El no repudio requiere:

  • identificación (quién hizo el pedido / quién dijo que era),
  • autenticación fuerte> (demuestre que fueron ellos quienes lo colocaron),
  • autorización (¿se les permitió colocarlo? ¿O deberían tener acceso de solo lectura?),
  • integridad (evitar que los registros de pedidos sean alterados o falsificados) y
  • disponibilidad (asegúrese de que el registro de pedidos esté disponible para las personas que lo completan) .)

En términos generales, el no repudio es una anti-característica. En lugar de intentar proporcionar eso, brinde repudio: los pedidos de rechazo que no puede mostrar probablemente sean válidos y asegúrese de tener suficiente pista de auditoría para investigar los pedidos en disputa, por lo que son tiempos precisos, registros web, direcciones IP, etc. Si la dirección IP está en China, pero no lo estaba, es probable que no hayan realizado el pedido: debería haberlo marcado en el paso de autenticación para que tenga que pagar el costo.



Esta pregunta y respuesta fue traducida automáticamente del idioma inglés.El contenido original está disponible en stackexchange, a quien agradecemos la licencia cc by-sa 3.0 bajo la que se distribuye.
Loading...