¿Cuál es una buena manera de activar una 'señal de socorro' oculta en la mensajería instantánea?

Creo que su lista de requisitos es demasiado restrictiva para crear un esquema sensato, sin embargo, es posible que se le ocurra algo si relaja un poco sus criterios.

Sin especificar su forma, Alice debe señalar a Bob. Esa señal cambia el estado de la angustia de Alice del estado predeterminado al estado opuesto. Si el estado predeterminado es que Alicia no está en peligro y la señal cambia de peligro, entonces el adversario siempre puede vencer al sistema simplemente eliminando toda la comunicación (es decir, cortando la línea de Internet antes de interrumpir).

A la inversa, como lo considera @Karrax, el valor predeterminado debe ser que Alice esté en peligro y que la señal cambie su estado de alerta hasta que se agote el tiempo, momento en el cual Alice debe hacer una señal para conservar su estado de no angustia. Hay dos problemas: la naturaleza de la señal y la duración del período de tiempo de espera.

Hay muchas formas de implementar la señal de tal manera que se aplica la ley de principio de Kerckhoffs. Un ejemplo sería una contraseña de pánico . Tenga en cuenta que no es suficiente tener dos contraseñas (o claves o tokens, etc.), una real y otra de pánico, ya que un adversario que sabe que el sistema podría hacer lo siguiente: dígale a Alice que sabe que tiene dos contraseñas, pídale que escriba ambos hacia abajo, lanza una moneda para elegir cuál usar, y escapa del ataque el 50% del tiempo. Esquemas más complicados solucionan esto: vea el documento (autopromoción, lo sé: lo siento)

Otra forma remota de implementar la señal podría ser usar conductancia de la piel de Alice Como medida de lo nerviosa que está. Una propuesta como esta fue en Usenix Security el año pasado.

El punto más complicado es el tiempo de espera. Si el tiempo de espera es demasiado largo, entonces el adversario puede entrar y terminar antes de que se agote la última señal. Si es demasiado corto, tienes un gran problema de usabilidad. De hecho, diría que tiene un problema de usabilidad sin importar qué con este enfoque.

Por esta razón, no creo que sea posible resolver el problema exacto que te gustaría.

Una forma de solucionar el problema sería que Alice pueda transmitir de manera confiable (sin modificación) un mensaje bajo la vigilancia pasiva del adversario (recuerde que si está activo, puede bloquear todos los mensajes). En este caso, el valor predeterminado puede ser que Alice no esté en apuros y que Alice simplemente usaría algún mecanismo preestablecido (como una palabra de socorro) con Bob. En este caso, el problema es esencialmente la esteganografía y dado que Alice necesita codificar la señal utilizando solo cálculos humanos (es decir, resistencia a la coerción cognitiva), nunca podrá probar que el esquema es seguro. Solo puedes confiar en que parezca razonable.

Me parece que estás confundiendo dos espacios problemáticos. El primero es el problema directo de los códigos de coacción, que es un problema de seguridad humana ampliamente explorado. (Y uno para el que a menudo no hay una buena respuesta: Leo Marks describió una vez que las "verificaciones de seguridad" de los agentes de SOE eran buenas para tranquilizar al agente y no mucho más).

El segundo espacio problemático es cómo el canal técnico para la comunicación podría verse afectado por la presencia y el conocimiento del atacante.

La razón por la que creo que los está confundiendo es porque parece que está preguntando si hay protecciones que se pueden colocar en el canal técnico que pueden resolver el problema del código de coacción. Mi respuesta es no, porque cualquier protección que ponga en su lugar estará sujeta exactamente a los mismos criterios de aprobación / falla de un código de coacción, en cuyo momento está de vuelta al problema del código de coacción. Como ejemplo, una de las implicaciones más desafiantes de un código de coacción es cómo mantener las comunicaciones en curso con una parte comprometida que engañará al atacante para que crea que lo está engañando a usted (así que el atacante no lo hace, ya sabe, dispare el agente). Mi punto es que simplemente no hay una solución tecnológica para engañar a un ser humano que está juzgando la comunicación de otro ser humano (voz, texto, código morse, lo que sea). El problema del código de coacción opera en la capa humana; no importa si tiene UDP o IPSec sin cifrar o criptografía cuántica en la siguiente capa hacia abajo.

No tengo idea de si eso te ayuda :)

Cuando Alice escribe, ya está constantemente ingresando la validación de que es la persona física correcta, e ingresando cuáles son sus niveles de estrés actualmente.

Simplemente transmitimos la dinámica de pulsación de tecla que utiliza mientras escribe, lo que le proporcionará una bio-métrica para su ser físico, conocimiento de su estado de ánimo actual (nivel de estrés), así como un método que proporciona negación plausible. Los registros textuales de la conversación no reflejarán esta información.

Keystroke Dynamics ha demostrado ser lo suficientemente confiable como para que más de 15 compañías vendan alguna forma de esta solución para satisfacer una necesidad u otra.

Mi primera respuesta iba a ser la "contraseña de pánico" de @ PulpSpy. De hecho, originalmente mencioné algo así en el chat original ... :)
(Y en general, parece que tiene la respuesta más completa, incluso tiene la investigación para respaldar a sí mismo :)).

Sin embargo, como menciona @gowenfawr, esto es efectivamente un problema del espacio humano, e incluso la contraseña de pánico tendría dificultades para evitar la combinación de los dos espacios problemáticos.

Otra solución, y la aplicabilidad dependería en gran medida del escenario, sería limitar lo que el usuario autenticado puede (ser obligado) a hacer .
Esto no se aplicaría si Alice simplemente quiere hacerle una señal a Bob de que su vida está en peligro; Esto podría ser relevante en una situación como la que menciona @ this.josh en un comentario:

  

... la parte maliciosa lo está coaccionando físicamente, es decir, sosteniendo una pistola en la cabeza y obligándolo a enviar un mensaje a una parte remota. es decir, "transfiera todos los fondos de la cuenta 12345 a la cuenta 67890" Puede asumir que el atacante sabe cómo se supone que funciona el protocolo de comunicación, por lo que el atacante podría detectar una desviación significativa.

En lugar de que Alice intente señalar a Bob no que realice la transferencia, ya que está siendo obligada, en lugar de eso, el sistema no debería permitir que dicha transferencia se realice simplemente en un mensaje instantáneo de Alicia.
Esto encaja en algún lugar entre "Least Privilege" y "autenticación adaptativa" ...

De manera similar, cuando la seguridad bancaria se volvió más dura, hubo una "tendencia" de secuestro de gerentes bancarios " miembros de la familia , y obligando a los gerentes del banco a realizar el robo bancario por ellos.
Los bancos lucharon contra esto (¿con éxito? No estoy seguro) al no permitir que ni siquiera el gerente del banco extraiga demasiado efectivo por sí mismo.

En otras palabras, en lugar de preocuparse por la identidad de Alice, limite lo que su identidad puede hacer, entonces, también habrá menos incentivos para poner físicamente un arma en la cabeza de Alice, ya que no puede ayudar, incluso si quisiera.

Tenga en cuenta que esto no responde realmente a la pregunta titulada (cómo señalar), sino que intenta evitar la situación en primer lugar.
Y, de nuevo, esto no ayudaría a Alice a señalar a Bob que su vida está en peligro, a menos que Bob supiera que Alice ni siquiera intentaría hacerlo y, por lo tanto, el cumplimiento de la coacción es la señal real. (Lógica de rotonda, lo sé ...)

¿Qué sucede si establece una rutina o verifica que siempre inicia en situaciones de no angustia? De esa manera, cuando se te dicta o te mira, no sigues la rutina y sabes que la portada está perdida.

Se puede desencadenar por accidente si también lo olvidas, pero por supuesto no deberías hacerlo si es de tanta importancia.

Editar: ningún sistema nunca será 100% seguro. Solo lo conseguirás lo suficientemente seguro. Puede grabar el software de IM y otras herramientas necesarias en un chip ROM y utilizarlo en un dispositivo adecuado, y tal vez sea lo suficientemente seguro. Del escenario requiere grandes cantidades de tubo de seguridad, entonces, naturalmente, usted simplemente hace lo suficiente para proteger a los clientes también.

Otra idea es hacer que las acciones sean un difícil desafío matemático que puede resolverse en papel. En apuros solo reclama que lo resuelvas de una manera diferente a la real.

Aquí solo hay 2 factores. 1. Posibilidad de enviar cualquier mensaje que desee. 2. Posibilidad de seleccionar el receptor

En el peor de los casos, suponga que la parte maliciosa puede leer el mensaje.

Esto nos deja con 4 situaciones posibles y todas fallan si se siguen los métodos convencionales, ya que la parte deshonesta puede leer lo mismo e influir en todos los parámetros.

[Si no pueden leer, toda esta discusión no tiene sentido :)]

Solución: el proceso de verificación no debe iniciarse por el que está en problemas. Esta es la clave. Debe ser iniciado por el que es libre. Puede ser un par de preguntas pre-arregladas. Respuesta equivocada simplemente significa problemas. Siempre puedes dar la respuesta correcta cuando no estás en problemas. Incluso una situación de no respuesta puede considerarse un problema.

La única pregunta es ¿cómo el que está libre comienza esto? Posible respuesta: hacerlo a una hora predefinida todos los días. Es la única solución posible / más posible que se pueda imaginar. La razón es que está tomando el derecho de seleccionar el destinatario de la parte maliciosa y también la capacidad de enviar la respuesta correcta de una cantidad inimaginable de posibles respuestas.

El proceso es aleatorio y, por lo tanto, el problema causado a la parte maliciosa va más alto que otras soluciones. Esta es una forma muy posible de resolver el problema que usted plantea. Todos los demás pueden fallar en una situación u otra, pero esto ofrece la mayor esperanza.

Solo tengo que pensar en un cuento para niños y un artículo de noticias.

En una historia, una hermana fue secuestrada y obligada a telefonear a su hermano para atraerlo a la trampa. Ella usó su apodo que nunca hizo antes porque sabe que él lo odiaba.

El artículo de noticias trataba sobre una instalación para tratar problemas mentales en niños. De acuerdo con el artículo de noticias, los niños fueron maltratados allí y se reveló porque una madre acordó con su hijo usar un "!" en lugar de "," en la línea de "querida mamá" de una letra.

En el caso de los mensajes instantáneos, este puede ser el uso de caritas o la puntuación al final de la línea (ya sea para usar un punto o no).

Estas dos ideas obviamente violan la ley de Kerckhoff.

Podría usar una señal de dos pasos si no espera una respuesta rápida. Por ejemplo, el primer paso podría ser el uso de (para usted) tipografía inusual (como puntos suspensivos , diacritics o mayúsculas) o una referencia a un nombre que ninguno de ustedes conoce. Esto debe ser seguido inmediatamente por una oración específica e inocua como "¿Estás ahí?" o "¿Ya compraste esa elegante computadora portátil?"

Si estás en una conversación activa, puedes usar una señal de tres pasos con confirmación. Después de recibir la inicialización de la señal de socorro, la otra persona podría responder algo específico como "¿Es usted, [su compañero / hermano / otro]?" Ahora el tono de la respuesta podría determinar si es una señal de socorro real o simplemente un error. Por ejemplo, una simple respuesta objetiva ( "No, soy yo" ) desarmaría la situación, mientras que una respuesta sarcástica / agitada / emocional ( "No, es su silla sensible" / "¿Por qué sigues haciendo preguntas estúpidas?" ) indicaría una emergencia real. La belleza de tal método es que los intrusos tendrían que conocer muy bien a las dos personas para detectar que no es su forma habitual de comunicación.

Protocolo:

Cuando Alice y Bob están chateando normalmente, Alice periódicamente envía a Bob una frase de contraseña especial que no se puede adivinar de Mallory. Después de que Bob reciba este mensaje, puede estar seguro de que Alice no estaba bajo presión hasta ese momento.

ejemplo de transacción válida:

Alice: Hi Bob.
Bob: What's up?
Alice: Trent just delivered my new orange AK-47.
Alice: Please take $973 out of my account and put it into Trent's account.
Bob: Hold on ...
Bob: OK, it's done.
Bob: That doesn't sound like you.
Bob: I thought you said orange AK-47s looked hideous?
// Alice pulls open a drawer, peeks inside a file clearly labeled PASSWORDS, then types:
Alice: sudo make me a sandwitch, Bob.
// Bob flips through his Rolodex.
// The camera zooms in on Bob's hand holding a Rolodex card with ALICE on the top tab,
// and "sudo make me a sandwitch, Bob." hand-printed near the bottom.
Alice: The scatter pattern from Fred's orange AK-47 looks hideous.
Alice: Trent's orange AK-47 is totally different.

ejemplo de transacción de coacción:

// sounds of glass shattering.
// Mallory steps through what used to be a sliding glass door, and
// puts a gun to Alice's head.
// Mallory: Alice, tell Bob to transfer $100,000 to Swiss bank account 555-1212.
Alice: Bob, transfer $100,000 to Swiss bank account number 555-1212.
Bob: Hold on ...
Bob: OK, it's done.
// Alice: OK, he did it. Can you let me go now?
// Mallory: That's not going to fool me.

Final original:

// Mallory: By Kerckhoffs's principle,
// I know you have some kind of confirmation password thingy. Type that in now.
Alice: sudo correct horse battery staple, Bob.
// Bob thinks to himself: Huh? This can't be yet another mis-spelled "sandwich".
// Bob thinks: This must be a real duress situation.
Bob: Verified.
// Mallory puts a bullet through Alice's cell phone and laptop,
// making it impossible for Alice to immediately call Bob back and cancel the transaction.
Bob: Alice?
// Bob waits a minute, but Alice never responds.
// Bob sends Trent to check on Alice.
// Mallory strides out through what used to be a sliding glass door.
// Lightning briefly silhouettes Mallory,
// then all we see is rain and darkness.

Finalización de Quentin Tarantino:

// Mallory: By Kerckhoffs's principle,
// I know you have some kind of confirmation password thingy. Type that in now.
// Alice: It's so long and complicated, I can't remember it.
// Alice: It's written in my PASSWORDS file.
// Alice pulls open a drawer, and pulls out a file clearly labeled PASSWORDS.
// With her other hand, she pulls out an orange AK-47 (Chekhov's gun).

Detalles :

Como Bob inicialmente no sabe si Alice está siendo obligada o no, por lo tanto, es necesario que alguna señal viaje de Alice a Bob, lo que hace que Bob se dé cuenta de que Alice está bajo presión o no.

Sin embargo, después de que Mallory irrumpa, Mallory bloqueará cualquier mensaje, como "y las flores también fueron hermosas", que incluso tiene una pequeña posibilidad remota de ser un mensaje codificado especial que significa "¡Bob! Mallory está aquí con un arma a mi cabeza! ".

Por lo tanto, el protocolo debe basarse en la falta de un mensaje que indique que Alice está bajo presión, y algún tipo de mensaje positivo que indique que Alice está libre.

Para evitar violar el principio de Kerckhoffs, debemos asumir que Mallory sabe que hay algún mensaje positivo que indica que Alice está libre. Para evitar que Mallory escriba el mensaje en el teclado de Alice, el mensaje debe ser indiscutible para Mallory.

Al solicitar la transacción primero, luego confirmando que realmente lo quería enviando la frase de contraseña, es imposible para Mallory secuestrar la sesión después . Alice "inicia sesión" con una frase de contraseña.

defecto potencial: si Mallory puede desplazarse hacia atrás y ver el historial de conversación anterior de Alice, podría descubrir cuál es la frase de contraseña real. Hay varias soluciones de "frase de contraseña de un solo uso".