Questo scenario è sicuro?

Question

Sto usando RSA per crittografare la comunicazione tra un server e un client. Diciamo che abbiamo 2 chiavi asimmetriche, chiave 1 e chiave2.

Il server ha key1 (privato) dall'inizio e il client ha key1 (pubblico)

Quindi, ecco lo scenario:

1. il client genera key2
2. il client si connette al server
3. invio chiave2 (pubblico) crittografato con chiave1 (pubblico)
4. da ora in poi il server invierà tutti i dati crittografati con la chiave2 (pubblica)
5. il client invia alcuni dati casuali al server
6. il server restituisce gli stessi dati con hash
7. il client verifica che i dati siano corretti

Per quanto posso vedere, ciò dovrebbe impedire un attacco man-in-the-middle o mi sto perdendo qualcosa? Al punto 7 il client dovrebbe sapere se qualcuno sta cercando di fornire al server la chiave sbagliata con cui crittografare, poiché nessun altro, tranne il server, può decodificare key2 (pubblico).

Se c'è qualcosa che può essere fatto per migliorare la sicurezza, per favore dimmelo.

Answer 1

La cosa migliore che puoi fare per migliorare la sicurezza è usare un design esistente e non provare a reinventare la ruota. Non sto dicendo che ciò che hai fatto sia necessariamente sbagliato, ma solo che molte persone molto più intelligenti di te e di me abbiamo trascorso molto tempo a pensare a questo problema. Utilizzare invece TLS.

Answer 2

Finché key1 (privato) non è stato intercettato in qualche modo da una terza parte, il tuo scenario sembra sicuro.

Penso di averlo visto da qualche parte in un documento in realtà. In esso, Alice ha dato a Bob una scatola sbloccata (chiave 1 pubblica), quindi Bob ha messo un mucchio di sue scatole (chiave 2 pubblica), la blocca e la rimanda ad Alice. Alice quindi apre la scatola (chiave 1 privata) e ora può sigillare in modo sicuro le scatole che Bob le ha appena dato.

Nonostante l'analogia con la scatola, questo è essenzialmente ciò che stai facendo, quindi direi che è sicuro.

Answer 3

Sono d'accordo, basta usare TLS.

Inoltre, quale valore forniscono i passaggi da 5 a 7? Un MITM che desidera eseguire un attacco che funzionerebbe dopo i passaggi 1-4 (ad es. DoS di qualche tipo passando n transazioni e poi fermandosi, forzando un nuovo tentativo dall'inizio) potrebbe farlo anche dopo 5-7. Cosa aggiungono?

- MarkusQ

Answer 4

No, questo protocollo non è sicuro.

Un man-in-the-middle può intercettare i dati inviati dal client e inviare ciò che vuole al server, poiché non è stato specificato alcun meccanismo affinché il server possa autenticare il client o verificare l'integrità dei messaggi riceve.

Certo, potresti aggiustare il protocollo per risolvere questi problemi evidenti, ma ce ne sarebbero altri. Se li risolvessi tutti, avresti qualcosa che corrisponda a TLS o SSH, quindi perché non iniziare da lì?

---

@ Petoj: il problema su cui mi concentravo era quello del server che si fidava dei messaggi che riceveva; la tua proposta non fornisce alcuna sicurezza lì. Tuttavia, se sei preoccupato per la riservatezza, hai ancora un problema, perché il MITM potrebbe passare i messaggi avanti e indietro inalterati fino a quando non vede ciò che vuole trovare perché non hai alcuna privacy sui messaggi del client.

La tua proposta sembra mirare a garantire l'integrità dei messaggi dal cliente. Hai sviluppato il protocollo al punto in cui il client non è in grado di distinguere tra un attacco e un errore di rete. Anziché cercare di aiutare il client a determinare se il server ha agito su un messaggio manomesso, consentire al server di verificare l'integrità del messaggio prima di agire su di esso.

Answer 5

Concordo con Greg sul fatto che stai reinventando la ruota . Ciò che stai essenzialmente descrivendo è una forma base di scambio di chiavi . Per inciso, al fine di garantire che sia sicuro contro gli attacchi man-in-the-middle devi anche essere sicuro dell'identità del server, vale a dire assicurarti che il client possa sapere con certezza che ciò che ritiene essere pubblico (chiave1) è realmente il server e non il man-in-the-middle (ad esempio utilizzando una CA o avendo il pubblico del server (chiave1) in un archivio sicuro sul lato client.)

Inoltre, ci sono ulteriori considerazioni che devi conoscere dal punto di vista dei sistemi, come ad esempio:

• la crittografia a chiave asimmetrica è più lenta della crittografia a chiave simmetrica, che è uno dei motivi per cui soluzioni esistenti come TLS utilizzerà la crittografia della chiave asimmetrica solo per negoziare una chiave simmetrica temporanea, che viene quindi utilizzata per la crittografia del canale.
• se l'analisi del traffico di una terza parte riesce a decifrare una chiave simmetrica temporanea, non hai compromesso la tua coppia di chiavi asimmetrica. Per questo motivo sei incoraggiato a rinegoziare la chiave temporanea relativamente spesso. Probabilmente, la generazione di un nuovo key2 nel tuo scenario mitigherebbe questo aspetto.