Quanto è sicura questa chat di comunicazione?

Question

Quanto è sicura questa chat di comunicazione?

#1 da (2 voti)
#2 da (-1 voti)

2

Ho creato una chat tra due parti (usando c #), e mi chiedo quale tipo di debolezze ho trascurato.

Descrizione della sua funzionalità: Esistono due applicazioni individuali: Client (2 istanze di TcpClient che sono le parti comunicanti) e Server (TcpListener, l'inoltro di messaggi crittografati).

Nota: presumo che entrambi i computer contenenti l'applicazione client siano sicuri e non contengano malware o virus che potrebbero manomettere / monitorare la memoria, inserire chiavi, creare schermate, ecc ... D'altra parte l'applicazione Server può essere su qualsiasi computer che può essere potenzialmente 'compromesso' per mancanza di un termine migliore.

Ora la funzionalità del client sta registrando il messaggio dalla tastiera dell'utente, crittografandolo (utilizzando le classi AES256 c #) e inviando i dati al server. Sebbene prima che i messaggi possano essere inviati, i client si scambiano le chiavi pubbliche in base all'algoritmo Diffie Hellman key-exchange , ma tutte le comunicazioni tra i client funzionano attraverso il server. Essenzialmente il server è un gateway, un ponte tra i client, [1] , dopo che lo scambio di chiavi e il server di generazione di chiavi segrete riceve solo messaggi crittografati, non si preoccupa del suo contenuto, trasmette semplicemente il messaggio all'altro client, che lo decodifica localmente. [2] .

Ho pensato di avvolgere il mio NetworkStream in uno SslStream, per rendere il canale di comunicazione più sicuro, ma anche se qualcuno può 'leggere' lo stream non è in grado di leggere comunque la crittografia, quindi non penso che questo sia un difetto critico per mantenere il SECRET-MESSAGE sicuro.

Non sto proteggendo il mio file .exe in alcun modo (né nel server né nei client) poiché non penso che ci sia una protezione al 100% se il computer è già stato compromesso. In altre parole, il cattivo può decompilare il mio .exe, quanto è grave e dovrei prendere qualche tipo di precauzione? Sebbene le chiavi segrete generate da DH siano conservate localmente nei computer (generate di nuovo ogni volta che viene stabilita una connessione tra client) poiché presumo che il computer client sia sicuro, non dovrebbero esserci problemi con questo, giusto?

Punti deboli che ho notato:

[1]: ha un accesso diretto alle informazioni dei clienti (indirizzo IP, quando è stato inviato il messaggio, anche quanti caratteri il messaggio conteneva (~ di 8 byte)).

[2]: l'applicazione server può essere temperata, imitare il secondo client e acquisire il canale, inviare la propria chiave pubblica e ricevere la chiave pubblica di altri client, sostituendo efficacemente il secondo client. Questo può essere facilmente risolto se le parti si scambiano un saluto in qualsiasi altro software di comunicazione (skype, ecc.) E confermano che sono collegati tra loro (i messaggi vengono ricevuti nello stesso momento in cui vengono inviati, ecc.)

P.S. Sono a conoscenza di alcuni punti deboli che ho menzionato sopra, ma quelli non sono critici, vorrei sapere se ci sono dei difetti critici che mi sono sfuggiti, e come valuteresti questa configurazione da 0-10? Cosa posso aggiungere / modificare apportare miglioramenti a ciò che ho già / correggere i difetti.

.net encryption server client aes

posta Arman Papikyan 31.10.2017 - 21:32

fonte

2 risposte

-1

Lo scambio Diffie-Hellman di per sé non fornisce l'autenticazione delle parti comunicanti e è quindi vulnerabile a un attacco man-in-the-middle .

Questo è il motivo per cui i segreti condivisi dovrebbero essere verificati di persona, se possibile o attraverso un altro canale di comunicazione (meno sicuro).

risposta data 01.11.2017 - 00:27

fonte

Leggi altre domande sui tag .net encryption server client aes

Scadenza dell'autorizzazione senza orologio / ora affidabile Prestazioni di scansione Nmap

score 2 · Accepted Answer

Questo protocollo di comunicazione è abbastanza debole in quanto non fornisci autenticità o integrità . Vi sono numerosi attacchi a cui è vulnerabile. I più gravi a cui riesco a pensare in base a ciò che hai detto sono:

Attacco di ripetizione - Un attacco di replay coinvolge un attaccante che invia una copia di qualsiasi parte di dati crittografati. Il destinatario non sarà consapevole del fatto che il messaggio è una riproduzione di un messaggio precedente. L'utente malintenzionato non ha bisogno di conoscere il contenuto del messaggio per rimuovere questo attacco.
Attacco di malleabilità - Non hai menzionato quale modalità di funzionamento stavi utilizzando. Supponendo che sia CTR o CBC, un utente malintenzionato sarà in grado di modificare il testo cifrato per modificare il testo in chiaro in modi prevedibili. L'unica soluzione a questo è utilizzare un costrutto di integrità come un HMAC .
Attacco man-in-the-middle - Un attacco MITM è possibile poiché Diffie-Hellman non è autenticato. Per fornire l'autenticazione, è necessario utilizzare una coppia di chiavi aggiuntiva come RSA o DSA. Lo scambio della chiave DH deve essere firmato da queste chiavi per garantire l'autenticità. Le impronte digitali delle chiavi di firma private possono essere scambiate separatamente, o scambiate e archiviate in modo che tutte le connessioni successive lo utilizzino (una tecnica chiamata TOFU , o Trust-On-First-Use).
Insicurezza semantica - Se stai utilizzando la modalità ECB (o in modo non corretto utilizzando la modalità CBC o una modalità non progettata per questo scopo come XTS ), le crittografie dello stesso testo in chiaro hanno il potenziale di provocare perdita di informazioni tramite duplicazioni visibili nel testo cifrato.
perdita di metadati : la lunghezza dei messaggi di testo offre una quantità sorprendente di informazioni preziose. A meno che non si stiano effettuando il riempimento dei messaggi a una lunghezza specifica o almeno che li si riempia fino a un multiplo, si consente a un utente malintenzionato di ottenere informazioni sulla conversazione in base alla lunghezza del testo cifrato. Il riempimento in questo contesto non è correlato al riempimento nella crittografia.

Come puoi vedere, ci sono un sacco di variabili che entrano in gioco durante la scrittura di un cryptosystem. I protocolli di crittografia reali sono piuttosto complessi . Questa complessità è assolutamente necessaria per mitigare una varietà di attacchi comuni e non così comuni. Come richiesto per una scala di valutazione 0-10, darei questo protocollo attorno a 3. Se si utilizza la modalità ECB o si generano chiavi AES in modo errato (ad esempio utilizzando un PRNG scadente), sarebbe ancora più basso. Se desideri scrivere un'applicazione che fa chat crittografata, ti suggerisco di utilizzare la libreria OTR , chiamata libotr . La libreria offre comunicazioni e ripudio crittografati end-to-end (negatività plausibile per quanto riguarda il contenuto dei messaggi) e altro ancora.