What's a good way to trigger a hidden 'distress signal' in instant messaging?

Question

Here's the scenario:

Alice and bob use Off-the-record messaging to communicate over IM. The have:

• Encryption
• Authentication
• Deniability
• Perfect forward secrecy

They communicate after authenticating, being reasonably sure of each others identity. Now a rogue party breaks into Alice's house.

Alice knows that they might want to coerce her into sending messages, or she just want to send a distress signal. Typing "Help!" won't do much good, as the attackers will realise the outside world knows of her distress.

You could imagine she might type a previously negotiated distress message ("and the flowers were lovely too"), which causes the Bob's client to pop open a message:

• Alice is in distress - do not trust the following messages until you have authenticated her identity again. She is being coerced into sending them.

But the intruders might force her away from the computer too quickly. They might also dictate messages to her, removing her capability to type the flowers-sentence.

In this scenario, what is a good way to trigger a distress signal?

Some problems we have found while chatting about it:

• The coercers mustn't be able to detect that Alice is sending a distress signal. Neither by looking at her, nor by analysing network traffic. This prevents even complicated schemes, like "having all letters of the alphabet used within one minute" (also a violation of the Kerckhoffs Principle).

• The signal must be designed such that it is hard to trigger by accident, since a false distress signal forces (annoying and potentially flawed) trust re-negotiation measures. And it should be a protocol that's easy to use.

Assumptions:

• The protocol used to send messages between Alice and Bob is a well known protocol.
• The adversary is physically present with Alice.
• The adversary will allow Alice to send a message unless s/he thinks Alice is sending a distress signal.
• Alice will always be allowed to send the first message.
• The adversary will monitor the messages on the channel.
• Alice will only be allowed to send a few messages.
• The adversary dictates the content of the messages Alice sends, but not their format.
• The adversary will allow Alice to receive all remote messages.
• The adversary does not know the transmission latency between Alice and Bob.
• The channel is reliable.

Answer 1

I believe your list of requirements is too constraining to come up with a sensible scheme, however it may be possible to come up with something if you relax your criteria a bit.

Without specifying its form, Alice must signal to Bob. That signal toggles the status of Alice's distress from the default status to the opposite status. If the default status is Alice is not in distress and the signal toggles distress, then the adversary can always beat the system by simply dropping all communication (i.e., cutting the internet line before breaking in).

Conversely, as @Karrax considers, the default must be that Alice is in distress and the signal toggles her not being in distress until it times out, by which time Alice must signal again to preserve her non-distress status. There are two issues: the nature of the signal and the length of the timeout period.

There are a lot of ways of implementing the signal such that Kerckhoffs' principle law applies. One example would be a panic password. Note that it does not suffice to have two passwords (or keys or tokens, etc), one real and one panic, as an adversary who knows the system could do the following: tell Alice he knows she has two passwords, ask her to write them both down, flip a coin to choose which to use, and get away with the attack 50% of the time. More complicated schemes get around this: see the paper (self-promotion, I know: sorry).

Another far-out way of implementing the signal might be using Alice's skin conductance as a measure of how nervous she is. A proposal like this was at Usenix Security last year.

The more tricky point is the timeout. If the timeout is too long, then the adversary may break in and be done by the time the last signal times out. If it is too short, you have a huge usability problem. In fact, I would argue that you have a usability problem no matter what with this approach.

For this reason, I don't believe that it is possible to solve the exact problem you'd like.

One way to relax the problem would be that Alice can reliably transmit (without modification) one message under the adversary's passive watch (remember if he is active, he can block all messages). In this case, the default can be that Alice is not under distress and Alice would simply use some pre-established mechanism (such as a distress word) with Bob. In this case, the problem is essentially steganography and since Alice needs to encode the signal using human computations only (i.e., cognitive coercion-resistance), you will never be able to prove that the scheme is secure. You can only rely on it seeming reasonable.

Answer 2

It seems to me that you're conflating two problem spaces. The first is the straightforward problem of duress codes, which is a thoroughly explored human security problem. (And one for which there is often no good answer - Leo Marks once described SOE's agent "security checks" as being good for reassuring the agent and not much more).

The second problem space is how the technical channel for communication might be impacted by the presence and knowledge of the attacker.

The reason I think you're conflating them is because you seem to be asking if there are protections that can be put into the technical channel that can solve the duress code problem. My answer is, no, because any protection you put in place is going to be subject to the exact same pass/fail criteria for a duress code, at which point you're right back to the duress code problem. As an example, one of the most challenging implications of a duress code is how to maintain ongoing communications with a compromised party that will fool the attacker into believing they are fooling you (so the attacker doesn't, you know, shoot the agent). My point being, there's simply no technological fix for fooling a human being that's judging another human being's (voice, text, morse code, whatever) communication. The duress code problem operates at the human layer; it doesn't matter if you have unencrypted UDP or IPSec or quantum cryptography at the next layer down.

I have no idea if that is helpful to you :)

Answer 3

When Alice types, she is already constantly inputting both validation that she is the correct physical human, and inputting what her levels of stress presently are.

We simply transmit the keystroke dynamics she uses while typing, which will provide a bio-metric to her physical self, insight to her present state of mind (level of stress), as well as a method that provides plausible deniability. Textual logs of the conversation will not reflect this information.

Keystroke Dynamics have been proven reliable enough that there are more than 15 companies selling some form of this solution to meet one need or another.

Answer 4

My first answer was going to be along the lines of @PulpSpy's "panic password" - in fact, I originally mentioned something like that in the original chat... :)
(And overall, it looks like he has the most complete answer, even has the research to back himself up :) ).

However, as @gowenfawr mentions, this is effectively a human-space problem, and even the panic password would have difficulty getting around the conflation of the two problem spaces.

Another solution - and, applicability would depend greatly on the scenario - would be limiting what the authenticated user can (be forced to) do.
This would not apply if Alice simply wants to signal to Bob that her life is in danger; This could be relevant in a situation such as mentioned by @this.josh in a comment:

... the rogue party is physically coercing you, i.e. holding a gun to your head, and forcing you to send a message to a remote party. i.e. "Transfer all funds from account 12345 to account 67890" You can assume that the attacker knows how the communication protocol is supposed to work, so a significant deviation would be detectable by the attacker.

Instead of Alice trying to signal Bob not to perform the transfer, as she is being coerced, instead the system should not allow such a transfer to be performed based simply on an IM message from Alice.
This fits somewhere between "Least Privilege" and "adaptive authentication"...

Similarly, when bank security became tougher, there was a "trend" of kidnapping bank managers' family members, and coercing the bank managers to perform the bank theft for them.
Banks battled this (successfully? I'm not sure) by disallowing even the bank manager to pull out too much cash all by himself.

In other words, instead of worrying about Alice's identity, limit what her identity can do - then, there will also be less incentive to physically put a gun to Alice's head, since she cannot help even if she wanted to.

---

Note that this does not actually answer the titled question (how to signal), but tries to circumvent the situation in the first place.
And, again, this would not help Alice signal Bob that her life is in danger - unless Bob would know that Alice wouldnt even try to do so, and thus compliance with the coercion is the actual signal. (roundabout logic, I know...)

Answer 5

What if you establish a routine or check that you always initiate in non-distress situations? That way when you are being dictated or watched you do not follow the routine and you know the cover is blown.

It can be triggered by accident if you forget too, but of course you should not if it is of such importance.

Edit: no systemet will ever be 100% secure. You will only get it secure enough. You could burn the IM software and other necisary tools on a ROM chip and use it on a proper device, and maybe be safe enough. Of the scenario requires huge amounts of securitytube then naturally you just do enough in securing the clients aswell.

Another idea is making the shares secret a hard mathematecal challenge which can be solved on paper. It in distress just claim you solve it a different way than actual.

Answer 6

There are just 2 factors here. 1. Ability to send any message you want 2. Ability to select the receiver

For worst case scenario, assume the rogue party can read the message.

This leaves us with 4 possible situations and all of them fail if conventional methods are followed as the rogue party can read the same and influence all the parameters.

[If they can't read- This entire discussion is pointless :) ]

Solution: The checking process shouldn't be started by the one who is in trouble. This is the key. It must be started by the one who is free. It can be a pre-arranged question answer pair. Wrong answer simply means trouble. You can always give the right answer when you are not in trouble. Even a no answer situation can be considered as trouble.

Only question is how does the one who is free start this? Possible answer: Do it at a predefined time every day. It is the only possible/ more possible solution one can think of. Reason is that, you are taking the right to select the receiver from the rogue party and also the ability to send the correct answer out of an unimaginably huge number of possible answers.

The process is randomized and hence the trouble caused to the rogue party goes higher than other solutions. This is one very possible way to solve the problem you posed. All others may fail in one situation or other, but this offers most hope.

Answer 7

I just have to think about a children story and some news article.

In one story a sister was kidnapped and forced to phone her brother to lure him into trap. She used his nickname which she never did before because she knows he hated it.

The news article was about a facility to treat mental problems in children. According to the news article the children were mistreated there and it was revealed because one mother agreed with her child to use a "!" instead of a "," in the "dear mum" line of a letter.

In the case of instant messages this can be the use of smilies or end of line punctuation (whether to use a period or not).

Both of these ideas obviously violate Kerckhoff's law.

Answer 8

You could use a two-step signal if you don't expect a quick reply. For example, the first step could be use of (for you) unusual typography (like ellipsis, diacritics or all caps) or a reference to a name which neither of you know. This should be immediately followed by a specific, innocuous sentence like "Are you there?" or "Did you buy that fancy laptop yet?"

If you're in an active conversation, you could use a three-step signal with confirmation. After receiving the distress signal initialization, the other person could reply something specific like "Is that you, [your partner/brother/other]?" Now the tone of the reply could determine whether it's a real distress signal or simply an error. For example, a simple factual reply ("No, it's me") would disarm the situation, while a sarcastic/agitated/emotional reply ("No, it's her sentient chair" / "Why do you keep asking stupid questions??") would indicate a real emergency. The beauty of such a method is that the intruders would have to know the two persons really well to detect that it's not their usual way of communicating.

Answer 9

Protocol:

When Alice and Bob are chatting normally, Alice periodically sends some special unguessable-to-Mallory passphrase to Bob. After Bob gets this message, he can be confident that Alice was not under duress up to that point.

valid transaction example:

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.

duress transaction example:

// 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.

Original ending:

// 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.

Quentin Tarantino ending:

// 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).

Details:

Since Bob initially doesn't know whether Alice is being coerced or not, therefore some signal needs to travel from Alice to Bob that causes Bob to realize that Alice is under duress or not.

However, after Mallory breaks in, Mallory will block any message, such as "and the flowers were lovely too", that has even a tiny remote possibility of being a special coded message that means "Bob! Mallory is here with a gun to my head!".

Therefore, the protocol must rely on the lack of a message indicating Alice is under duress, and some sort of positive message indicating Alice is free.

To avoid violating Kerckhoffs's principle, we must assume that Mallory knows that there is some positive message that indicates Alice is free. To avoid Mallory from typing that message on Alice's keyboard himself, the message must be unguessable-to-Mallory.

By requesting the transaction first, then later confirming that she really wanted it by sending the passphrase afterword, it's impossible for Mallory to hijack the session after Alice "logs in" with a passphrase.

potential flaw: If Mallory can scroll back and see Alice's previous conversation history, he might be able to figure out what the real passphrase is. There are several "one-time passphrase" work-arounds.