Invio di messaggi tra due client, come verificare l'identità del mittente?

Question

Supponiamo quindi di avere due client, C1 e C2, a ciascun client è associato un GUID.

Come fai, quando ricevi un messaggio su C2 that presumibilmente proviene da C1 (controllando il GUID e vedendo che corrisponde al GUID di C1), ma poiché non è garantito che il messaggio provenga da C1 (C3 potrebbe semplicemente aver inviato il messaggio, inviando il GUID di C1 nell'intestazione del messaggio) è necessario verificare che il messaggio provenga effettivamente da C1.

Ho cercato di utilizzare la crittografia asimmetrica (RSA) per fare in modo che C1 invii un messaggio composto da [C1.GUID; RSAEncrypt(C2.PUBLIC_KEY, C1.GUID); MESSAGE], e poi lascia che C2 esegua sostanzialmente un controllo come questo (pseudo codice Python):

message.GUID == RSADecrypt(C2.PRIVATE_KEY, message.ENCRYPTED_GUID)

È un approccio praticabile?Oppure esiste qualche altro modo intelligente/più ovvio per verificare il mittente di un messaggio?

Answer 1

asimmetrico algoritmi sono stati inventati per tali scopi, questo è il modo digitale lavoro firme.

Tuttavia, il tuo approccio ha qualche problema. Chiunque con la chiave pubblica del destinatario potrebbe falsa la firma. Inoltre, la firma non cambia affatto! Chiunque intercettare i messaggi possono fingere di essere un mittente valido. Lo scopo della crittografia asimmetrica è quello di sconfiggere questi problemi con gli scambi di chiavi, c'è il concetto di firma digitale, che è fondamentalmente un hash cifrato assymetrically del messaggio che si sta gettando in giro.

Per RSA, è necessario fare un po 'di più al fine di creare una firma digitale dal algoritmo di base, consultare Wikipedia per ulteriori dettagli: http://en.wikipedia.org/wiki/RSA#Signing_messages

mi basta usare un algoritmo di firma digitale da una libreria. Prima google giri di ricerca con questo per Python:

http://www.example-code.com/python/pythonrsa.asp

http://www.chilkatsoft.com/dsa-python.asp

Answer 2

Il problema di questo metodo è che ogni macchina potrebbe quindi acquisire il guid e rsa-criptato-guid e passarle lo stesso. Non hai veramente creato alcun criterio challenge / response unici che possono essere intuito solo dal cliente ricevente. Quello che si avrebbe bisogno sarebbe qualcosa che è completamente unico e non può essere ottenuto semplicemente guardando parametri passati. Forse qualcosa di simile:

[ClientName; RSA-ENCRYPTED(GUID+Timestamp); MESSAGE]

In questo metodo, la cifratura RSA sarebbe stato fatto utilizzando la chiave pubblica di Client2 modo la chiave privata che solo di Client2 potrebbe sbloccarlo. Utilizzando il ClientName, Client2 potrebbe recuperare il GUID ci si aspetta da un datasource, e quindi abbinare il GUID restituito contro quello nella crittografia. Ho incorporato l'uso di un timestamp come sale cosicché la stringa crittografata esce diverso ogni volta. E 'considerato molto debole per usare un timestamp come randomizzazione per un sale, ma ottiene il punto attraverso. potrebbero essere attuate altri algoritmi più sicuri / casuali.

Answer 3

Chiunque spiare i messaggi tra un client e il server sarà in grado di creare nuovi messaggi, ha GUID del cliente non cambiano mai, nè RSA-ENCRYPTED-GUID.

considerazione il passaggio a questo modello un messaggio:. [GUID; ENCRYPTED_CONTENT_CHECKSUM; CONTENT]

Checksum(message.CONTENT) == 
    RSADescrypt(C1.PUBLIC_KEY, message.ENCRYPTED_CONTENT_CHECKSUM)

Ancora, chiunque spiare i messaggi possibile reinviare in precedenza inviato messaggi.

Answer 4

Le chiavi pubbliche e private sono la strada da percorrere.Presumo che non ti interessi crittografare i dati, ma ti interessa che i dati siano "autorizzati".

Diciamo che hai 3 computer

Comp1 Comp2 Comp3

Diciamo anche che vuoi che Comp1 invii un messaggio a Comp3.non ti interessa se il messaggio è stato intercettato, ma ti interessa che non sia stato contraffatto.

Comp1 firmerà digitalmente il messaggio con la sua chiave privata

Comp2 intercetterà il messaggio da Comp1 a Comp3, ma non potrà modificare il messaggio senza invalidare la firma

Comp2 inoltrerà il messaggio su Comp3

Comp3 utilizzerà la chiave pubblica di Comp1 per decrittografare la firma e utilizzerà l'hash nella firma per convalidare il contenuto.

Ora se vuoi crittografare i dati, devi aggiungere un passaggio aggiuntivo

Comp1 firmerà digitalmente il messaggio con la sua chiave privata

Comp1 genererà una chiave di crittografia casuale (tipicamente AES) e crittograferà il messaggio.

Comp1 prenderà quella chiave di crittografia e la crittograferà con la chiave pubblica di Comp3

Comp2 intercetterà il messaggio, ma non potrà leggerlo senza la chiave privata di Comp3

Comp2 inoltrerà il messaggio su Comp3

Comp3 utilizzerà la sua chiave privata per decrittografare la chiave AES

Comp3 decodificherà l'intero messaggio utilizzando la chiave AES

Comp3 convaliderà il messaggio decodificando la firma con la chiave pubblica di Comp1.

La firma contiene un hash del messaggio, se l'hash e l'hash del messaggio corrispondono, i dati sono intatti.

Puoi includere i GUID nel payload da utilizzare come ricerca per decidere quali chiavi pubbliche utilizzare.

PSTi consigliamo di utilizzare i metodi integrati per firmare un messaggio.Lascia che sia il Framework a eseguire l'hashing/ecc