Come condividere in modo sicuro la chiave tra due dispositivi remoti?

Quello che stai cercando è una coppia di chiavi pubblica / privata altrimenti nota come SSL nel mondo dei computer.

Un certificato SSL come menzionato è abbastanza sicuro dal momento che per scoprire cosa viene inviato è necessaria la chiave privata del certificato e non si può ottenere ciò senza irrompere nel server.

Se non vuoi usare SSL un'altra opzione sarebbe quella di usare una coppia di chiavi pubblica / privata hardcoded nel client / server che agirà proprio come SSL ma senza avere un certificato firmato.

Secure Sockets Layer (SSL) sembra essere la risposta che stai cercando. Ecco una citazione dalla pagina Wikipedia :

They use X.509 certificates and hence asymmetric cryptography to assure the counterparty with whom they are communicating, and to exchange a symmetric key. This session key is then used to encrypt data flowing between the parties. This allows for data/message confidentiality, and message authentication codes for message integrity and as a by-product, message authentication.

Inoltre, potresti semplicemente dare un'occhiata a RSA e Diffie-Hellman algoritmi che possono essere utilizzati in un client / modello server per scambiare le chiavi in modo sicuro. Tuttavia, hanno molti tipi di attacchi collegati a loro; il man-in-middle è uno di questi, in cui un intruso potrebbe semplicemente intervenire e rubare la chiave. Un altro attacco possibile è brute-force , in cui un intruso potrebbe indovinare la chiave che sei cercando di trasferire.

Se vuoi scambiare le chiavi in modo sicuro usando questi algoritmi, assicurati di averli hash usando MD-5 o SHA-X algoritmi. Puoi persino crittografarli se disponi di spazio, utilizzando DES / Double DES / Triple DES o AES- 128/192/256 algoritmi di crittografia.

Leggi attentamente:

Before a client and server can begin to exchange information protected by TLS, they must securely exchange or agree upon an encryption key and a cipher to use when encrypting data. Among the methods used for key exchange/agreement are: public and private keys generated with RSA (denoted TLS_RSA in the TLS handshake protocol), Diffie-Hellman (denoted TLS_DH in the TLS handshake protocol), ephemeral Diffie-Hellman (denoted TLS_DHE in the handshake protocol), Elliptic Curve Diffie-Hellman (denoted TLS_ECDH), ephemeral Elliptic Curve Diffie-Hellman (TLS_ECDHE), anonymous Diffie-Hellman (TLS_DH_anon), and PSK (TLS_PSK). The TLS_DH_anon key agreement method does not authenticate the server or the user and hence is rarely used. Only TLS_DHE and TLS_ECDHE provide forward secrecy. Public key certificates used during exchange/agreement also vary in the size of the public/private encryption keys used during the exchange and hence the robustness of the security provided. In July 2013, Google announced that it would no longer use 1024 bit public keys and would switch instead to 2048 bit keys to increase the security of the TLS encryption it provides to its users.

Entrambe le risposte hanno identificato SSL / TLS, ma considerano l'aggiunta dell'autenticazione del client al mix. Ciò garantirà che il server accetterà solo connessioni per client autentificati / conosciuti. Lo svantaggio di questo è questo:

• a) Ogni client deve essere rilasciato con il proprio certificato di autenticazione client (sebbene non necessariamente dalla stessa CA del server).
• b) Ogni client deve memorizzare la chiave privata corrispondente. Questo sarà probabilmente nel software (sebbene possa essere memorizzato su una smartcard o un token PKI USB).
• c) Ogni client deve essere registrato con il server, anche se ciò potrebbe variare in base all'implementazione del server. Alcuni server possono consentire la fiducia in base ai certificati CA della radice noti. Alcuni server possono accettare certificati basati su un approccio white-list. Alcuni possono essere una miscela di entrambi o alternative.

Il server dovrebbe poter essere configurato per accettare solo connessioni autenticate dal client. In alcuni server Web questa impostazione può essere applicata a singole risorse sul server.

Guarda la pagina di Wikipedia per i dettagli sull'handshake TLS autenticato dal client:

Autenticazione client TLS

Se la domanda è capita correttamente, ciò che viene realmente chiesto qui è come fare un scambio di chiavi .

Avendo implementato ciò nella stessa maniera discussa per un prodotto di sicurezza, il seguente approccio generale funziona indipendentemente dal protocollo di trasporto sottostante (e inoltre non formula alcuna ipotesi sulla sua sicurezza sottostante):

1. Il client genera una chiave di transazione (casuale) usando una buona (presunta) buona IV e un strong algoritmo pseudo-casuale adatto alla crittografia AES256 (o migliore).

2. Il client genera una (nuova random) chiave di risposta simmetrica usando lo stesso processo del punto (1).

3. Il client crittografa la chiave di risposta (2) con la chiave di transazione da (1) ... utilizzando AES256 o qualsiasi altro algoritmo preferito.

4. Tramite PKI , il client (utilizzando la chiave privata del client) crittografa in modo asimmetrico la chiave della transazione (1) per il server (destinatario) utilizzando la chiave pubblica del Cliente. Ciò garantirà che solo il destinatario previsto possa leggere la chiave di transazione (1).

5. Genera un carico utile in cui viene identificato il client (mittente), associato alla chiave pubblica sul lato server (ricevitore). In questo carico utile sarà la chiave di transazione (crittografata con PKI) (1) e la chiave di risposta (crittografata AES) (2). C'è di più in questo come il contenuto dell'hashing per garantire il non ripudio, ecc., Ma concentriamoci sullo scambio di chiavi ...

6. Il client invia il payload al server. Si consiglia di farlo tramite TLS, ecc. Ma questo non è strettamente necessario in quanto la crittografia è sufficiente per proteggere le chiavi. Tuttavia, essere sicuri che il client stia inviando il payload al [right] server (ricevitore) senza intercettazioni migliora la sicurezza dello scambio di chiavi.

7. Il server cerca la chiave pubblica del client. Tramite PKI, (utilizzando la chiave privata Server), decodifica la prima parte del payload: la chiave di transazione.

8. Usando la chiave di transazione, la chiave di risposta viene decifrata usando AES256 (deve essere lo stesso algoritmo usato per la crittografia a chiave di risposta - dovrebbe essere parte del carico utile).

9. A questo punto, il client attende una risposta dal server.

10. Il server, utilizzando la chiave di risposta che il cliente conosce (lo ha generato) per questa transazione, può quindi crittografare qualsiasi contenuto associato per il client semplicemente utilizzando AES256 (un algoritmo simmetrico).

11. Il client utilizza l'algoritmo simmetrico e la chiave di risposta per decrittografare la risposta del server.

A patto che le chiavi segrete PKI non siano compromesse, vengono utilizzati buoni sali, IV, ecc. Questo processo è molto solido (utilizzato dalle organizzazioni di sicurezza di tutto il mondo).

Notare che QUALSIASI crittografia può essere rotta EVENTUALMENTE. Utilizzando questo processo basato sulle transazioni con una nuova (casualità della chiave è importante) (grande) chiavi pseudo-casuali per ogni coppia richiesta / risposta, è molto difficile compromettere la conversazione.

Utilizzando questo metodo, anche se una chiave di transazione è compromessa, limita molto l'esposizione poiché l'accesso verrebbe acquisito solo su una singola transazione alla volta.

Sto semplificando la risposta di Darrell Teague, e correggendo anche alcuni punti (specialmente 7 e 4), questo dovrebbe anche rispondere alle domande di Eric B.

1. Il client genera una chiave condivisa (casuale) utilizzando una buona (presunta) buona IV e un strong algoritmo pseudo-casuale adatto per la crittografia simmetrica (ad esempio AES).

2. Il client genera un payload in cui viene identificato il client (mittente), associato alla sua chiave pubblica sul lato server (ricevitore). Questo payload includerà anche la chiave condivisa (PKI encrypted) (1).

3. Tramite PKI, il client crittografa in modo asimmetrico il carico utile per il server (destinatario) utilizzando la chiave pubblica del server. Ciò garantirà solo il destinatario previsto (il server, che conosce la chiave privata del server) in grado di leggere il payload contenente la chiave condivisa (1).

4. Il client invia il payload al server.

5. Tramite PKI, utilizzando la chiave privata del server, il server decrittografa il carico utile contenente i dati di identificazione del Cliente e la chiave condivisa (1). Ora sia il client che il server conoscono la chiave condivisa.

6. A questo punto, Client e Server possono entrambi utilizzare la chiave condivisa per ulteriori comunicazioni.

7. Ad un certo punto la sessione è finita e la chiave condivisa è eliminata. Ogni sessione richiede una nuova chiave condivisa.