LogMeIn Hamachi è un sistema per la creazione e la gestione di VPN dell'infrastruttura LogMeIn.
Il software è disponibile per gli utenti in versione shareware e freemium (con alcune limitazioni) e permette di stabilire un collegamento diretto tra due computer anche in presenza di NAT, e in molti casi senza dover riconfigurare questi ultimi. Attualmente è disponibile per i sistemi operativi Windows, macOS e Linux.
I computer collegati tramite il software Hamachi risultano virtualmente collegati nella stessa LAN, per cui tutte le applicazioni progettate per lavorare nella rete fisica possono continuare a funzionare. Ogni computer connesso, inoltre, può operare anche come server nella rete LAN virtuale.
LogMeIn Hamachi consente di accedere a tutte le funzioni di una normale VPN, oltre a funzioni di tunneling via relay su server propri in caso di NAT restrittivo.
Caratteristiche di sicurezza Il sistema Hamachi comprende i server di mediazione (mediation server), gestiti dal venditore, e i peer client, ovvero i nodi finali del sistema.
L'unico compito dei server è quello di tracciare la posizione dei nodi client e di fornire i servizi di mediazione necessari per stabilire una connessione diretta peer-to-peer tra due utenti. Una volta stabilito il tunnel tra i due client, nessun'altra informazione attraverserà i server, e i client comunicheranno unicamente tra di loro.
Quando un peer è attivo, stabilisce una connessione TCP con uno dei server disponibili; una volta stabilita la connessione con il server, il peer inizia a scambiare informazioni con il server in base al protocollo Hamachi, per registrarsi e sincronizzarsi con tutti gli altri peer client (utenti) attivi e registrati nei server. Il client Hamachi è identificato dal suo indirizzo IP Hamachi (Hamachi network address), composto da nome e password. L'indirizzo viene assegnato quando il client si connette per la prima volta al server di mediazione, e rimane invariato fino a quando l'account del client esiste nel sistema Hamachi. Il client genera anche una coppia di chiavi RSA (RSA key pair), che userà per l'autenticazione durante la sequenza di registrazione. La chiave pubblica viene inviata al server una volta, durante la prima connessione quando viene creato il nuovo account. Per la registrazione nel sistema, il client spedisce il suo indirizzo IP Hamachi e usa la sua chiave privata per firmare il challenge del server. Il server verifica la firma ricevuta dal client e autentica quest'ultimo.
Ogni server di mediazione possiede una coppia di chiavi RSA. La chiave pubblica è distribuita insieme al pacchetto di installazione, quindi il client ne è in possesso ancora prima di connettersi per la prima volta al sistema. Quando il client si connette al server di mediazione, annuncia quale identità il server dovrebbe avere. Se il server riconosce l'identità richiesta dal client, inizia la sequenza di registrazione. Nell'ultimo messaggio di questa sequenza il server spedisce una firma dei dati del client e questo conferma l'identità del server al client. Non appena il client si connette al server di mediazione avviene uno scambio di chiavi.
Questo scambio produce del materiale di codifica utilizzato per generare le chiavi per codificare e autenticare tutti i messaggi relativi agli altri protocolli. I messaggi sono cifrati con l'algoritmo AES a chiave simmetrica e autenticati tramite indirizzo MAC. Ogni messaggio è numerato con un identificatore unico, in modo da prevenire gli attacchi replay. La suite di crittografia predefinita di Hamachi è la seguente: Diffie-Hellman group 2048-bit MODP, AES-256 CBC mode e HMAC-SHA1-96. Specifica gli algoritmi impiegati e i relativi parametri utilizzati per lo scambio delle chiavi, per ottenere le chiavi e per la cifratura dei messaggi. Hamachi utilizza il protocollo Diffie-Hellman per lo scambio delle chiavi con i seguenti parametri:
Il numero primo p=22048-21984-1+264x{[21918p]+124476} Il generatore g è 2.
L'algoritmo AES viene utilizzato con una chiave di cifratura di 256 bit per cifrare e proteggere la comunicazione tra i peer Hamachi. Per garantire l'integrità dei messaggi scambiati tra i peer, Hamachi utilizza l'algoritmo HMAC-SHA1-96.
Dettagli del protocollo Il client si connette al server di mediazione e invia a esso un messaggio HELO, nel quale saranno inseriti i parametri di sicurezza della connessione (crypto suite, fingerprint della chiave pubblica del server, valori Diffie-Hellman). A questo messaggio, il server risponde HELO OK inviando i propri valori Diffie-Hellman. In seguito a questo scambio di messaggi il client e il server di mediazione generano il materiale per la cifratura. Per registrarsi nel sistema Hamachi, il client invia un messaggio AUTH al server di mediazione inserendo i parametri necessari per la sua autenticazione da parte del server di mediazione. Se l'autenticazione va a buon fine il server risponde con AUTH OK. A questo punto, il client è registrato nel sistema Hamachi e può comunicare con qualsiasi altro client Hamachi attivo che fa parte della stessa VPN.
HELO Il client si connette al server e invia il seguente messaggio:
HELO CryptoSuite ServerKfp Ni Gi
CryptoSuite: contiene il valore 1 per la crypto suite predefinita; ServerKfp: contiene il fingerprint esadecimale di tipo OpenSSH, ottenuto dall'hash calcolato con SHA1 della chiave pubblica del server di mediazione. Il fingerprint viene utilizzato per evitare che un attaccante si sostituisca al server di mediazione, prevenendo gli attacchi man-in-the-middle; Ni: nonce di 1024 bit del client, ovvero una stringa di bit casuali, che contribuiscono alla generazione del materiale per la cifratura; Gi: contiene l'esponente pubblico Diffie-Hellman del client.
Una volta ricevuto il messaggio di HELO dal client, se il server possiede una chiave pubblica che combacia con il campo ServerKfp, esso risponde al client inviando il seguente messaggio:
HELO OK Nr Gr
Nr: nonce di 1024 bit del server di mediazione; Gr: contiene l'esponente pubblico di Diffie-Hellman del server di mediazione.
Keymat A questo punto sia il client che il server calcolano il valore riservato di Diffie-Hellman, e con esso generano i codici per la cifratura:
KEYMAT=T1 | T2 | T3 |… T1=prf(K, Ni | Nr | 0x01) T2=prf(K, T1 | Ni | Nr | 0x02) T3=prf(K, T2 | Ni | Nr | 0x03) …
K: rappresenta il valore segreto di Diffie-Hellman condiviso; prf: è l'algoritmo HMAC-SHA1.
Tutti i successivi messaggi sono cifrati con la chiave Ke e sono autenticati utilizzando la chiave Ka; entrambe le chiavi sono ottenute dalla KEYMAT. Nel caso in cui si utilizzi la cryptosuite predefinita, la chiave che utilizza i primi 256 bit della KEYMAT mentre la chiave Ka utilizza i seguenti 160 bit. Prima di cifrare un messaggio il mittente aggiunge il padding ad esso, in modo che la lunghezza del messaggio da cifrare e inviare sia multipla del blocco che l'algoritmo di cifratura utilizza; nel caso della cryptosuite predefinita la grandezza del blocco è di 128 bit.
Successivamente un vettore di inizializzazione (IV) casuale viene generato e il messaggio da inviare viene cifrato. In coda al messaggio cifrato risultante viene aggiunto l'IV mentre in testa viene inserito un ID del messaggio, rappresentato da un numero di 32 bit monotono crescente. Se il messaggio viene inviato utilizzando il protocollo TCP, sarà aggiunto ad esso anche un campo size di 32 bit, mentre se il messaggio viene inviato con UDP, sarà aggiunto in testa un campo SPI di 32 bit. Infine viene calcolato un HMAC sull'intero messaggio e viene aggiunto ad esso. A questo punto il messaggio può essere inviato in rete.
Traffico peer-to-peer Una volta che il server di mediazione realizza il tunnel tra i due peer Hamachi, esso genera una coppia di numeri casuali SPI di 32 bit. La coppia di numeri SPI è utilizzata per etichettare il traffico in transito tra i due peer Hamachi; un SPI identifica il traffico in una direzione, mentre il secondo SPI identifica il traffico nella direzione opposta. Quando un client riceve un pacchetto UDP cifrato riconosce il peer tramite il valore SPI contenuto nel pacchetto, ottiene le chiavi crittografiche e procede con l'autenticazione e la decifratura. Le chiavi per la comunicazione peer-to-peer sono ottenute in maniera differente a seconda della versione del software client. Nelle versioni meno recenti, ovvero dalla versione 0.9.9.5 e versioni più vecchie, la KEYMAT veniva ricevuta direttamente dal server di mediazione, il quale la generava in modo casuale. Tutte le versioni più recenti, a partire dalla versione 0.9.9.6, eseguono in maniera autonoma lo scambio delle chiavi per generare la KEYMAT. Per prima cosa i peer scelgono chi dovrà iniziare lo scambio delle chiavi, confrontando i valori SPI del tunnel l'uno con l'altro. Il peer che possiede il valore SPI più basso di ritorno sarà l'iniziatore. L'iniziatore invierà:
KE1 Ni Gi
Ni: contiene il nonce di 1024 bit dell'iniziatore; Gi: contiene l'esponente pubblico di Diffie-Hellman dell'iniziatore.
Il peer iniziatore continuerà ad inviare il messaggio KE1 con un intervallo di N millisecondi, fino a quando non riceverà una risposta. Il messaggio di risposta è il seguente:
KE2 Nr Gr Signature(Nr | Ni | Gr | Gi, Kpri_r)
Nr: nonce di 1024 bit del rispondente; Gr: esponente pubblico di Diffie-Hellman del rispondente; Signature: viene realizzata con la chiave privata del rispondente.
Il rispondente invia solo i valori Nr e Gr, non deriva ancora la chiave peer-to-peer da Ni e Gi in quanto non può essere ancora certo dell'identità dell'iniziatore, poiché quest'ultimo non si è ancora autenticato. Ricevuto KE2 l'iniziatore verifica la Signature e deriva da questa le chiavi peer-to-peer con lo stesso meccanismo della generazione ed estensione della KEYMAT nel caso della comunicazione tra client e server. Quindi l'iniziatore replica con:
KE3 Ni Gi Signature(Ni | Nr | Gi | Gr, Kpri_i)
Il rispondente verifica la Signature, deriva le sue chiavi peer-to-peer e risponde con un messaggio fittizio (dummy message) cifrato all'iniziatore per indicare che la fase di scambio delle chiavi è terminata con successo. Il messaggio fittizio è un messaggio vuoto il cui unico scopo è quello di segnalare che la fase di scambio è terminata. Come avviene per il messaggio KE1 l'iniziatore continua a re-inviare il messaggio KE3 periodicamente finché non riceve una risposta. Per poter verificare la Signature dei nodi durante la fase di scambio delle chiavi, il client deve avere la chiave pubblica del nodo, che può essere ottenuta in due modi: o richiedendola dal server di mediazione, o ricevendola attraverso un altro canale e installandola manualmente. Per la sicurezza degli utenti è buona cosa sottoporre le chiavi pubbliche ad una verifica manuale per assicurarsi della loro autenticità.
Funzionamento Per l'installazione del software Hamachi (relativamente alla versione 1.0.1.3 per Windows) è sufficiente avviare il setup e seguire le istruzioni che compaiono a video; il software installato è pronto per essere utilizzato, senza particolari configurazioni o settaggi. Durante il primo avvio, il client Hamachi si connette al server di mediazione che fornisce ad esso il suo indirizzo IP Hamachi. Questo indirizzo IP del tipo 5.xyz.abc.def è l'identificativo univoco del client all'interno del sistema Hamachi, e rimane tale fino a quando il client sarà registrato all'interno del sistema; questa classe di indirizzi è riservata dall'IANA, ma attualmente non è utilizzata nel dominio di indirizzamento di Internet.