Capisco come funziona l'autenticazione reciproca tra un client e un server, tuttavia non sono sicuro di come sarei in grado di ottenere l'autenticazione reciproca tra due client A e B ?
"Client" e "Server" sono solo nomi formali per i ruoli in situazioni in cui esiste un'asimmetria naturale. Vale a dire, si parla prima: quello è il "cliente".
Ecco come va in SSL : il protocollo è definito per operare su un mezzo di trasporto bidirezionale. Una delle entità parla per prima e invia un messaggio ClientHello . Non esiste un requisito assoluto che la nozione di "client" e "server" utilizzata da SSL corrisponda alle nozioni di "client" e "server" per la connessione sottostante quando quella connessione è un socket TCP su Internet. Succede proprio in questo modo.
In generale, qualsiasi protocollo di autenticazione tra due sistemi (chiamiamoli "A" e "B") funziona inviando messaggi tra loro e uno dei sistemi sarà il primo a parlare. Finché sia A sia B sanno chi deve parlare per primo, attraverso alcune convenzioni , allora il protocollo funzionerà. La convenzione è facile da ottenere quando c'è un'asimmetria, ad es. il software su una macchina non è lo stesso del software sull'altra. Ad esempio, per il Web, un sistema utilizza un browser Web (ad esempio Firefox) mentre l'altro utilizza un server Web (ad es. Apache) e gli standard definiscono cosa si suppone da fare.
Immagina una telefonata . Qualcuno compone il numero dell'altro. Il comportamento normale è che la persona che riceve la chiamata parlerà per prima (e dirà "ciao"). Questo è esattamente il concetto che desideri. Se queste due persone parlanti vogliono eseguire un protocollo di autenticazione, dovranno concordare i rispettivi ruoli (possono chiamarsi "client" e "server" se questo è il loro desiderio). L'utilizzo dell'asimmetria dialer / ricevitore è un modo naturale per avviare questa convenzione. Ma potevano usare qualsiasi altra convenzione; per esempio, potrebbero usare l'ordine lessicografico dei loro nomi (Alice è il "cliente" e Bob "server" perché "A" è prima di "B" nell'alfabeto); o la loro data di nascita; oppure possono provare casualmente; o qualsiasi altra cosa.
Detto questo, nel caso specifico di SSL, normalmente ci sono certificati e la macchina con il ruolo "server" mostra un certificato al "client"; il "client" può anche mostrare un certificato al "server". I certificati dimostrano vincoli tra le chiavi e le identità, ma questo ha valore solo se l'identità ha un significato. Ad esempio, quando il server mostra il suo certificato al client, il punto importante è che il certificato del server contiene il nome server e il client si aspetta un nome server molto specifico (quello dall'URL). Allo stesso modo, quando il client mostra il suo certificato al server, questo rende utile l'autenticazione solo se il server riesce a trovare nel certificato una nozione di identità che ha senso per lui.
Una situazione più interessante con SSL è SRP : con questa variante, nessun certificato. Client e server si autenticano reciprocamente relativamente alla loro conoscenza di un segreto condiviso (una password). Devono ancora essere d'accordo su chi parla per primo! E c'è un punto in più, che è l'entità con il ruolo "server" non ha bisogno di memorizzare la password stessa, solo una sua versione hash (con qualche struttura algebrica). In questo senso, chi assume il ruolo di "server" non è del tutto arbitrario per quanto riguarda la sicurezza: anche in un protocollo di autenticazione reciproco , le caratteristiche di sicurezza ottenute su entrambi i lati possono essere diverse.
Il modo più semplice per ciascuna parte è di crittografare la propria comunicazione con la propria chiave privata. Se riesci a decifrare il mio messaggio con la mia chiave pubblica, allora I deve averlo crittografato. Certo, questo dipende dal fatto che tu abbia una copia della mia chiave pubblica di cui ti fidi provenire. Se abbiamo bisogno di comunicazioni sicure e autenticate, il primo messaggio è un mezzo chiave. Criptolo una chiave con la tua chiave pubblica e cripti una chiave con la mia chiave pubblica - scambiamo le chiavi cifrate e combiniamo le chiavi per creare una chiave di sessione, quindi usiamo la chiave crittografica simmetrica per mantenere la sicurezza.
Ci sono troppe incognite nella tua domanda. Fai Alice & Bob ha una comunicazione fuori dal canale? Si conoscono, è questa la loro prima transazione? Quanto è sicura l'autenticazione deve essere? Quanto resiliente?
Ricerca scambio di chiavi Diffie-Hellman o Internet Protocollo di scambio di chiavi o Protocollo di accordi chiave . Questi sono tutti strettamente correlati al problema che suggerisci.
Puoi anche provare il trust transitivo - questo è il vecchio stile pgp dove se la mia chiave è garantita da abbastanza persone, allora è molto probabile che io sia io.
Tutto ciò che dice grande orso è anche vero.
Ma voglio avvertirti: il 90% dell'errore di qualsiasi cryptosystem non è il protocollo, è l'implementazione. Solo perché qualcuno ha implementato un SSL / TLS adeguatamente protetto non significa che il tuo sarà.
Leggi altre domande sui tag authentication tls