È sicuro che sia client che server usino la stessa coppia di chiavi in CurveZMQ?

2

Realizzo software per laboratori di fisica e i computer nei laboratori si scambiano ogni sorta di informazioni tra loro e con i laptop dei ricercatori, di solito in una rete universitaria. Io uso ZeroMQ per la maggior parte delle comunicazioni.

Sto lavorando utilizzando la crittografia integrata di ZeroMQ per proteggere questa comunicazione in una prossima versione del mio software.

Il modello di sicurezza di ZMQ è crittografia a chiave pubblica basata su CurveCP e sto seguendo i loro Esempio "ironhouse" con client e server che verificano l'identità reciproca tramite le chiavi pubiche dell'altro.

Il fatto è che, in realtà, non ho "client" e "server" ben definiti, i computer coinvolti sono più simili ai "pari". E possono andare e venire a breve preavviso, e non è pratico distribuire una nuova chiave pubblica a tutti i computer con cui il laptop di una nuova persona potrebbe voler parlare o distribuire una nuova chiave pubblica ogni volta che viene impostato un nuovo raspberry pi fino a monitorare qualche pezzo di equipaggiamento. Automatizzare la distribuzione delle chiavi tramite server e ssh è anche qualcosa che non posso davvero aspettarmi dal laboratorio di fisica medio.

Ma penso che "qui, copia questa stringa base64 nel tuo file di configurazione su ogni computer in cui vuoi parlare l'un l'altro e trattalo come la password del computer del laboratorio" è una ragionevole aspettativa.

A tal fine, posso dare a tutti i peer la coppia di chiavi privata / pubblica stessa e trattare quella coppia di chiavi (o almeno la chiave privata) come un segreto già condiviso? Chiunque abbia le stesse chiavi non sembra molto diverso da chiunque abbia la password di accesso ai computer di laboratorio (che sono sempre tutti uguali), a condizione che la crittografia non richieda che due peer abbiano chiavi diverse. Ovviamente è rotto se qualcuno perde le chiavi, ma non è diverso dal fatto che le password del computer da laboratorio siano state compromesse, dato che fornisce a tutti l'accesso RDP di rete - devi cambiare le chiavi e dirlo a tutti in entrambi i casi.

Non ho per avere una singola coppia di chiavi - è solo leggermente più semplice. Potrei avere due keypair e ogni peer decidere quale usare in base a quali chiamate bind() in zeromq e che chiama connect() - la differenza è arbitraria in zeromq ma è una simmetria già rotta che potrei permettermi di definire per convenzione quale peer utilizza la coppia di chiavi 'client' e che utilizza la coppia di chiavi 'server'. In entrambi i casi distribuirò le stesse chiavi private a tutti, l'unica domanda è se ne distribuisco uno o due.

Avrei usato crypto simmetrico con una chiave già condivisa se fosse un'opzione in ZeroMQ, ma non lo è, e l'inserimento di crypto simmetrico a livello di applicazione significa che alcune delle informazioni inviate da ZeroMQ non saranno crittografate (anteporre le informazioni di routing e quel genere di cose) e lascerebbe anche le applicazioni vulnerabili agli attacchi di replay, dal momento che alcuni socket ZeroMQ sono a senso unico e non ti dà accesso al socket TCP sottostante, quindi non puoi fare alcuna sorta di stretta di mano per fare la crypto simmetrica usa un sale per sessione o qualsiasi altra cosa.

Quindi, tl; dr non è OK per i peer di usare coppie di chiavi identiche in CurveZMQ?

    
posta Chris Billington 08.03.2018 - 05:15
fonte

1 risposta

1

La domanda che dovresti porci è: cosa stai cercando di proteggere?

Se distribuisci la tua chiave tra tutti i peer e se la corretta distribuzione delle chiavi è "troppo complessa" per il tuo caso d'uso, puoi anche disabilitare del tutto la crittografia: le tue chiavi non sono sicure e quindi neanche i tuoi messaggi. Anche se attivi FS , non proteggi il tuo sistema dagli attacchi MITM.

Forse una migliore direzione da tenere in considerazione sarebbe l'implementazione di un sistema di distribuzione delle chiavi: avere un server CA centrale che consente la registrazione automatica del client utilizzando qualsiasi meccanismo di autenticazione che si ritenga sufficiente per le proprie esigenze e semplicemente che tutti abbiano fiducia nelle chiavi emesse da questa CA. Ciò manterrebbe la comunicazione peer-to-peer sicura, consentendo al tempo stesso di ridimensionarla in modo indefinito.

    
risposta data 08.03.2018 - 08:44
fonte

Leggi altre domande sui tag