Qual è un buon modo per attivare un "segnale di soccorso" nascosto nella messaggistica istantanea?

Credo che il tuo elenco di requisiti sia troppo vincolante per elaborare uno schema ragionevole, tuttavia potrebbe essere possibile trovare qualcosa se si rilassano un po 'i criteri.

Senza specificare la sua forma, Alice deve segnalare a Bob. Quel segnale commuta lo stato della sofferenza di Alice dallo stato predefinito allo stato opposto. Se lo stato di default è Alice non è in difficoltà e il segnale alterna l'angoscia, allora l'avversario può sempre battere il sistema semplicemente facendo cadere tutte le comunicazioni (cioè tagliando la linea internet prima di entrare).

Al contrario, come ritiene @Karrax, il default deve essere che Alice sia in pericolo e il segnale la fa in modo che non sia in pericolo fino a quando non scade, quando Alice deve segnalare di nuovo per preservare il suo stato di non-angoscia. Ci sono due problemi: la natura del segnale e la durata del periodo di timeout.

Ci sono molti modi per implementare il segnale in modo tale che si applichi la legge principale di Kerckhoffs. Un esempio potrebbe essere una password di panico . Si noti che non è sufficiente avere due password (o chiavi o token, ecc.), Un vero e proprio panico, come un avversario che sa che il sistema potrebbe fare quanto segue: dire ad Alice che sa di avere due password, chiedergli di scrivere Abbatteteli entrambi, lanciate una moneta per scegliere quale usare e scappate con l'attacco il 50% delle volte. Schemi più complicati aggirano questo: vedi il paper (autopromozione, lo so: scusa).

Un altro modo di implementare il segnale potrebbe essere l'utilizzo della conduttività della pelle di Alice come misura di quanto sia nervosa. Una proposta come questa è stata a Usenix Security lo scorso anno.

Il punto più difficile è il timeout. Se il timeout è troppo lungo, l'avversario potrebbe entrare in gioco e essere fatto entro il tempo in cui scade l'ultimo segnale. Se è troppo breve, hai un enorme problema di usabilità. In realtà, direi che hai un problema di usabilità, non importa con questo approccio.

Per questo motivo, non credo che sia possibile risolvere il problema esatto che desideri.

Un modo per rilassare il problema sarebbe che Alice può trasmettere in modo affidabile (senza modificare) un messaggio sotto l'orologio passivo dell'avversario (ricorda se è attivo, può bloccare tutti i messaggi). In questo caso, il valore predefinito può essere che Alice non è in difficoltà e Alice semplicemente usa un meccanismo prestabilito (come una parola di soccorso) con Bob. In questo caso, il problema è essenzialmente la steganografia e poiché Alice ha bisogno di codificare il segnale usando solo calcoli umani (cioè la resistenza alla coercizione cognitiva), non sarai mai in grado di dimostrare che lo schema è sicuro. Puoi solo fare affidamento su ciò che sembra ragionevole.

Mi sembra che tu stia combinando due spazi problematici. Il primo è il problema diretto dei codici coercizione, che è un problema di sicurezza umana completamente esplorato. (E uno per il quale spesso non c'è una buona risposta - Leo Marks una volta ha descritto gli "assegni di sicurezza" dell'agente di SOE come buoni per rassicurare l'agente e non molto di più).

Il secondo problema è il modo in cui il canale tecnico per la comunicazione potrebbe essere influenzato dalla presenza e dalla conoscenza dell'attaccante.

La ragione per cui penso che tu le stia combinando è perché sembra che tu stia chiedendo se ci sono protezioni che possono essere inserite nel canale tecnico in grado di risolvere il problema del codice della coercizione. La mia risposta è, no, perché qualsiasi protezione che applichi sarà soggetta allo stesso identico criterio di superamento / fallimento di un codice di coercizione, a quel punto si torna al problema del codice di coercizione. Ad esempio, una delle implicazioni più impegnative di un codice di coercizione è come mantenere le comunicazioni in corso con una parte compromessa che ingannare l'attaccante nel credere che ti stiano prendendo in giro (quindi l'attaccante no, sai, sparare l'agente). A mio parere, non c'è semplicemente una soluzione tecnologica per ingannare un essere umano che giudichi la comunicazione di un altro essere umano (voce, testo, codice morse, qualsiasi cosa). Il problema del codice della coercizione funziona a livello umano; non importa se hai crittografia UDP o IPSec o crittografia quantistica al livello successivo.

Non ho idea se ti sia d'aiuto:)

Quando Alice digita, lei è già costantemente inserendo sia la convalida che lei è l'umano fisico corretto, sia inserendo i suoi livelli di stress al momento.

Trasmettiamo semplicemente le dinamiche di battitura che lei usa durante la digitazione, che fornirà una bio-metrica al suo sé fisico, intuizione del suo attuale stato d'animo (livello di stress), nonché un metodo che fornisce una negabilità plausibile. I registri testuali della conversazione non rifletteranno queste informazioni.

Le sequenze di battute sono state dimostrate sufficientemente affidabili che ci sono più di 15 aziende che vendono alcune forme di questa soluzione per soddisfare una necessità o un'altra.

La mia prima risposta sarebbe stata sulla falsariga della "password di panico" di @ PulpSpy - infatti, all'inizio avevo parlato di qualcosa del genere nella chat originale ... :)
(E nel complesso, sembra che abbia la risposta più completa, ha persino la ricerca per sostenersi :)).

Tuttavia, come cita @gowenfawr, questo è effettivamente un problema di spazio umano, e anche la password di panico avrebbe difficoltà a aggirare la conflazione dei due spazi problematici.

Un'altra soluzione - e, applicabilità dipenderebbe notevolmente dallo scenario - sarebbe limitare ciò che l'utente autenticato può (essere forzato a) fare .
Questo non si applica se Alice vuole semplicemente segnalare a Bob che la sua vita è in pericolo; Questo potrebbe essere rilevante in una situazione come quella citata da @ this.josh in un commento:

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

Invece di Alice che tenta di segnalare a Bob non di eseguire il trasferimento, poiché è forzata, il sistema non dovrebbe consentire che un trasferimento di questo tipo venga eseguito semplicemente su un messaggio di messaggistica istantanea di Alice.
Questo si colloca tra "Least Privilege" e "autenticazione adattiva" ...

Allo stesso modo, quando la sicurezza delle banche è diventata più dura, c'era una "tendenza" dei rapitori di banca rapiti " familiari e costringendo i gestori bancari a eseguire il furto bancario per loro.
Le banche hanno combattuto questo (con successo? Non sono sicuro) impedendo persino al direttore della banca di tirare fuori troppi soldi da solo.

In altre parole, invece di preoccuparsi dell'identità di Alice, limitare ciò che la sua identità può fare - allora, ci sarà anche meno incentivo a mettere fisicamente una pistola alla testa di Alice, dal momento che non può fare a meno di farlo anche se volesse.

Si noti che questo in realtà non risponde alla domanda intitolata (come segnalare), ma cerca di eludere la situazione in primo luogo.
E, ancora, questo non aiuterebbe Alice a segnalare a Bob che la sua vita è in pericolo - a meno che Bob non sappia che Alice non proverebbe nemmeno a farlo, e quindi il rispetto del coercizione è il segnale effettivo. (logica rotatoria, lo so ...)

Che cosa succede se stabilisci una routine o controlli di aver sempre iniziato in situazioni di non-emergenza? In questo modo quando ti viene dettato o osservato che non segui la routine e sai che la cover è saltata.

Può essere innescato accidentalmente se anche tu lo dimentichi, ma ovviamente non dovresti farlo se è di tale importanza.

Modifica: nessun sistema sarà mai sicuro al 100%. Lo otterrai solo abbastanza sicuro. È possibile masterizzare il software di messaggistica istantanea e altri strumenti di necisary su un chip ROM e utilizzarlo su un dispositivo appropriato, e forse essere abbastanza sicuro. Lo scenario richiede enormi quantità di securitytube quindi naturalmente basta fare abbastanza per proteggere anche i client.

Un'altra idea è rendere le azioni segrete una dura sfida matematica che può essere risolta sulla carta. In caso di difficoltà, basta chiedere di risolverlo in un modo diverso dal reale.

Ci sono solo 2 fattori qui. 1. Possibilità di inviare qualsiasi messaggio tu voglia 2. Possibilità di selezionare il ricevitore

Per lo scenario peggiore, supponi che il rogue possa leggere il messaggio.

Questo ci lascia con 4 possibili situazioni e tutte falliscono se vengono seguiti metodi convenzionali in quanto la parte canaglia può leggere lo stesso e influenzare tutti i parametri.

[Se non riescono a leggere- Questa discussione è inutile :)]

Soluzione: il processo di verifica non deve essere avviato da chi è nei guai. Questa è la chiave. Deve essere avviato da colui che è libero. Può essere una coppia di risposte a domande prestabilite. La risposta sbagliata significa semplicemente guai. Puoi sempre dare la risposta giusta quando non sei nei guai. Anche una situazione di non risposta può essere considerata un problema.

L'unica domanda è: come può iniziare chi è libero? Risposta possibile: esegui ogni giorno in un orario predefinito. È l'unica soluzione possibile / più possibile a cui si possa pensare. La ragione è che, si sta prendendo il diritto di selezionare il ricevente dalla parte canaglia e anche la capacità di inviare la risposta corretta da un numero inimmaginabilmente enorme di risposte possibili.

Il processo è casuale e quindi il problema causato alla parte canaglia è maggiore rispetto ad altre soluzioni. Questo è un modo molto possibile per risolvere il problema che hai posto. Tutti gli altri possono fallire in una situazione o in un'altra, ma questo offre più speranza.

Devo solo pensare a una storia per bambini e ad alcuni articoli di notizie.

In una storia una sorella fu rapita e costretta a telefonare a suo fratello per attirarlo in trappola. Ha usato il suo soprannome che non ha mai fatto prima perché sa di odiarlo.

L'articolo di notizie riguardava una struttura per il trattamento di problemi mentali nei bambini. Secondo l'articolo di cronaca, i bambini sono stati maltrattati lì ed è stato rivelato perché una madre era d'accordo con il suo bambino ad usare un "!" invece di un "," nella riga "cara mamma" di una lettera.

Nel caso di messaggi istantanei questo può essere l'uso di faccine o punteggiatura di fine riga (se usare un punto o meno).

Entrambe queste idee violano ovviamente la legge di Kerckhoff.

Potresti usare un segnale a due fasi se non ti aspetti una risposta rapida. Ad esempio, il primo passaggio potrebbe essere l'uso di (per te) tipografia insolita (come puntini di sospensione , diacritici o tutto maiuscolo) o un riferimento a un nome che nessuno di voi conosce. Questo dovrebbe essere immediatamente seguito da una frase specifica, innocua come "Ci sei?" o "Hai già comprato quel computer portatile?"

Se sei in una conversazione attiva, puoi utilizzare un segnale a tre fasi con conferma. Dopo aver ricevuto l'inizializzazione del segnale di soccorso, l'altra persona potrebbe rispondere a qualcosa di specifico come "Sei tu, [il tuo partner / fratello / altro]?" Ora il tono della risposta potrebbe determinare se si tratta di un vero segnale di pericolo o semplicemente di un errore. Ad esempio, una semplice risposta ( "No, sono io" ) disarmerebbe la situazione, mentre una risposta sarcastica / agitata / emotiva ( "No, è la sua sedia senziente" / "Perché continui a fare domande stupide ??" ) indicherebbe una vera emergenza. La bellezza di un tale metodo è che gli intrusi dovrebbero conoscere bene le due persone per scoprire che non è il loro solito modo di comunicare.

Protocollo:

Quando Alice e Bob stanno chattando normalmente, Alice invia periodicamente alcune frasi speciali non guidabili a Mallory a Bob. Dopo che Bob ha ricevuto questo messaggio, può essere certo che Alice non era sotto costrizione fino a quel momento.

esempio di transazione valida:

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.

esempio di transazione coercizione:

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

Fine originale:

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

Finale di 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).

Dettagli:

Poiché inizialmente Bob non sa se Alice è costretta o meno, quindi alcuni segnali devono passare da Alice a Bob che induca Bob a capire che Alice è sotto costrizione o no.

Tuttavia, dopo che Mallory irrompe, Mallory bloccherà qualsiasi messaggio, come "ed anche i fiori sono adorabili", che ha anche una remota possibilità di essere un messaggio speciale in codice che significa "Bob! Mallory è qui con un pistola alla testa! ".

Pertanto, il protocollo deve fare affidamento sulla mancanza di un messaggio che indica che Alice è sotto costrizione, e una sorta di messaggio positivo che indica che Alice è libera.

Per evitare di violare il principio di Kerckhoffs, dobbiamo presumere che Mallory sappia che c'è un qualche messaggio positivo che indica che Alice è libera. Per evitare che Mallory dattilografi quel messaggio sulla tastiera di Alice, il messaggio dev'essere inviolabile-a-Mallory.

Richiedendo prima la transazione, poi confermando che lo desiderava davvero inviando la parola d'ordine passphrase, è impossibile per Mallory dirottare la sessione dopo Alice "accede" con una passphrase.

potenziale difetto: se Mallory può scorrere indietro e vedere la precedente cronologia delle conversazioni di Alice, potrebbe essere in grado di capire quale sia la vera passphrase. Esistono diverse soluzioni "passphrase una tantum".