Prevenire gli attacchi MITM sull'assistente

Question

Due clienti Alice e Bob utilizzano un server per accedere e scambiare messaggi attraverso il server. Su login, entrambi mandano i loro chiavi pubbliche per essere memorizzati sul server. Quando Alice vuole parlare con Bob, lei enrypts una chiave simmetrica con la chiave pubblica di Bob e lo invia a Bob attraverso il server.

Come posso fare in modo che il server non ha una propria coppia di chiavi pubblica e inviarlo ad Alice invece di chiave pubblica di Bob. In questo modo il server prima decifrare ciò che Alice ha inviato e crittografare nuovamente utilizzando la chiave pubblica di Bob reale.

Grazie

Answer 1

Dal momento che Alice e Bob non può fidarsi del server, devono trovare un altro modo di confermare le chiavi di ciascuno. Una possibilità è fare affidamento su un altro partito. Se Bob si fida Candice (e conosce la chiave pubblica di Candice), che conosce Alice, Candice può firmare la chiave pubblica di Alice quindi inviare la versione firmata a Bob. Questo si chiama rete di fiducia .

Answer 2

Per avere il certificato di Bob firmato da un terzo di fiducia (Verisign, la vostra società, una rete di fiducia, ecc), o avendo Bob invia il suo certificato di Alice attraverso un percorso sicuro separata fuori banda (porgendole un USB chiave di persona, per esempio).

Entrambi questi arrivare al cuore di ciò che si suppone il certificato di Bob a significare. Ti fidi solo certificato di Bob è il certificato di Bob, perché una persona di fiducia che ha certificato. Quel "qualcuno" può essere Bob se stesso o un terzo di fiducia che firma il certificato di Bob. È sempre e solo può fidare questo tanto quanto ti fidi del certificatore.

Answer 3

In crittografia, tu sei quello che sai. Se si vuole evitare MITM, poi Alice deve avere una nozione di che "Bob" è, il che significa che Bob deve conoscere qualche elemento di dati che un attaccante non lo sa. Qui, l'attaccante è il server, che si trova in posizione ideale per montare un attacco.

Quindi la domanda è: chi è Bob? Come è il server "non-Bob"?

Per esempio, "Bob" può essere definito come: "Bob è un essere umano che ha una patente di guida con 'Bob' scritto su di esso". Oppure: "Bob è quel ragazzo che ho incontrato in un bar e bevuto una birra con"

.

L'uso della crittografia asimmetrica consente di ridurre il problema ad una questione di fiducia in una chiave pubblica. Alice utilizzerà quello che lei crede essere la chiave pubblica di Bob. Pertanto, Alice ha solo bisogno di un modo per assicurarsi che la chiave pubblica che ha è infatti di proprietà di Bob. La proprietà di una chiave pubblica viene definita dal controllo della chiave privata corrispondente: la chiave pubblica di Bob è la chiave per il quale la chiave privata è sotto il controllo esclusivo di Bob (ad esempio solo Bob sa tale chiave oppure la chiave privata è in un token hardware - una smartcard -. che Bob tiene nel suo portafogli)

La soluzione di base è quella di avere scambio diretto di chiave pubblica. Quando Alice incontra Bob in un bar, hanno dato l'un l'altro le loro chiavi pubbliche. Così, Alice può fidarsi chiave pubblica di Bob "per definizione". Per lo scambio più facile (soprattutto dopo un paio di birre), Alice e Bob possono scambiare solo "impronte digitali", vale a dire i valori hash calcolati delle chiavi pubbliche. Questi valori sono più corte di chiavi pubbliche (per esempio 128 bit, invece di più di mille bit per una tipica chiave pubblica RSA) e sono sufficienti per Verifica che un dato partite chiave pubblica. In che l'installazione, il server dispone di un deposito per le chiavi pubbliche, e Alice e Bob ricalcolare solo le impronte digitali per assicurarsi che il server non è giocare fasulle.

Una soluzione più avanzata, che riduce la necessità per il consumo diretto di alcol, è quello di usare certificati . Un certificato è una scatola che contiene un identity (per esempio un nome, ad esempio "Bob") e una chiave pubblica. La scatola è firmato da una Certification Authority (CA): CA afferma che la chiave pubblica appartiene davvero a Bob, applicando la sua firma. Se Alice conosce la chiave pubblica di CA, allora può verificare la firma sul certificato, e quindi guadagnare la fiducia nel collegamento tra la chiave pubblica e l'identità contenute nel certificato.

La certificazione è la delega di fiducia. Alice delegati la sua fiducia alla CA; presumibilmente, il CA (chiamiamolo Charlie) siamo andati al bar per incontrare Bob; attraverso il certificato, Charlie dice Alice: "Sì, è davvero la chiave di Bob, lo mostrò a me dopo la sua terza pinta". Le cose diventano un po 'torbida qui, perché delegando la fiducia non è facile (soprattutto se Charlie è l'abitudine di binge drinking). Delegazione può andare oltre, quando una CA firma un certificato per un altro CA. Qui, Charlie dice ad Alice: "Non ho incontrato Bob, ma ho incontrato Daphne, che possono aver incontrato Bob e ha agito come una CA". Alice, utilizzando sia il certificato rilasciato da Charlie a Daphne, e il certificato rilasciato dal Daphne a Bob, può verificare che catena di firme.

Il punto delicato è che mentre Alice può conoscere Charlie e lui fiducia nella sua capacità di identificare correttamente Bob quando lo incontrerà, anche sotto l'influenza di un gallone di Guinness, Alice non lo sa Daphne. Nella catena di Alice-Charlie-Daphne-Bob, Alice deve non solo la fiducia che Charlie era affidabile (che ha identificare Daphne correttamente), ma anche che Charlie non era credulone, vale a dire che Charlie si sarebbe rifiutato di firmare un certificato per Daphne se Daphne non era lei stessa affidabile. In situazioni pratiche, fiducia degrada rapidamente quando viene delegata.

Quando si utilizza i certificati, ci sono soprattutto due possibili strutture:

• CA gerarchica: c'è una qualche "CA principale" che sono conosciuti da tutti per la costruzione singola o. Un delegati CA To un'altra CA (vale a dire che firma un certificato con, nell'identità, una bandiera convenzionale che dice: "questa chiave pubblica può essere attendibile ai fini della verifica delle firme sui certificati") solo all'interno di un accordo contrattuale che stabilisce le responsabilità legali di entrambi CA per quanto riguarda la certificazione. Ciò significa che la delegazione è definito formalmente, e si dà il caso che non è facile. Un contratto di certificazione avvocato-compatibili, di solito chiamato "Dichiarazione politica di certificazione" (CPS), è un documento lungo 200 pagine.

• Web of Trust: ognuno agisce come una CA. In assenza di "affidabilità formale", ogni singole rese catena solo una piccola quantità di fiducia. Questo è pensato per essere compensato da grandi numeri. Alice accetterà la chiave di Bob solo se lei può verificare alcuni (molti) distinte catene che portano a Bob, passando per i partecipanti distinti. Per esempio, Alice richiederà la catena di Charlie-Daphne-Bob, ma anche le catene Elia-Fiona-Bob e Gerald-Hillary-Ivan-Bob. Sono tutti ubriaconi, ma possono essere collettivamente affidabile, nel senso che un falso Bob avrebbe dovuto pagare molti giri al fine di corrompere un partecipante di ciascuna delle catene che Alice usa (se Alice richiede < em> n catene con certificati distinti, poi l'attaccante deve corrotto almeno n i partecipanti).

Quindi la certificazione delle imprese è soprattutto una questione di procedura: che è un CA, quello che una CA verifica prima di emettere (firma) un certificato, come il tutto si erge da un punto di vista giuridico, e così via. Queste procedure sono intrinsecamente complesse e devono essere supportate da dettagli in formato certificato (come la bandiera "questa chiave pubblica è una chiave CA"). I due principali formati standard attualmente definiti sono X.509 e PGP . X.509 ha molto supporto per il CA gerarchico, ed è un pasticcio molto aggrovigliato di norme, formati, le pratiche e comitati. PGP (standardizzato sotto il nome di "OpenPGP") non ha un vero supporto per CA gerarchica; è pensato per essere utilizzato con un Web of Trust. OpenPGP è più semplice di X.509, ma più limitata, soprattutto se si desidera avere un forte significato giuridico dietro i certificati.

Per un server di chat, tutto questo rischia di essere eccessivo. La nozione di identità che Alice vuole davvero è probabilmente una nozione di ripetizione : "che Bob è lo stesso Bob di quello ho chiacchierato con ieri". Alice non lo sa Bob in anticipo, ma parlare con lui una volta stabilisce la sua identità negli occhi di Alice. Lei vuole solo non essere ingannati da un altro Bob. Per questo, un processo semplice come il "software di Alice salva la chiave pubblica annunciata di ogni nuovo chiacchiere, e l'usa dopo" farà il trucco. Ricordate che la questione chiave è correttamente Definisci che cosa nozione di identità si sono dopo.

Answer 4

A meno che non si controlla il server non si può. A meno che, naturalmente, si conosce già la chiave pubblica di Bob, ma poi .... penso che tu sia nel problema dell'uovo e della gallina qui.