Fondamentalmente, la soluzione che stai cercando implicherà una sorta di trasferimento offline. I due computer che costituiscono i nodi endpoint del tuo tunnel sicuro devono essere "introdotti" tra loro, scambiandosi un segreto che permetterà a una parte di iniziare una connessione in modo tale che solo l'altro nodo possa capirlo.
Mentre questo segreto condiviso potrebbe essere la chiave simmetrica in sé, questo può essere problematico; gli algoritmi simmetrici sono più sicuri quando non si conosce nulla sulla chiave, anche se si tratta della stessa chiave usata per un'altra comunicazione. Un utente malintenzionato può osservare più "conversazioni" tra i nodi e, se sa che le conversazioni utilizzano la stessa chiave e IV, e se riesce a indovinare il testo normale (che è probabile che faccia come le informazioni inviate nelle fasi iniziali della comunicazione è abbastanza standard), può usare il testo cifrato per decodificare la chiave. Per questo motivo, la chiave simmetrica deve essere rinegoziata spesso, anche sullo stesso canale sicuro, a seconda della quantità di dati inviati.
La soluzione ideale è la crittografia asimmetrica o a chiave pubblica. Comprendi una cosa; le chiavi pubbliche sono destinate a essere pubbliche. Potresti dipingere a spruzzo la tua chiave pubblica sul lato della tua auto e guidarla attraverso Black Hat o DEF CON, e chiunque potrebbe fare è tentare di connettersi al tuo endpoint in modo sicuro (che non è più di quello che potrebbero fare per qualsiasi altro TLS -endpoint sicuro, e non andrebbero lontano qui, continua a leggere). La chiave privata è necessaria in qualsiasi schema a chiave pubblica per poter decifrare i dati in modo efficiente (e quindi perché le informazioni siano a rischio).
Ora, non puoi distribuire pubblicamente questo certificato; potresti, abbastanza plausibilmente, implementare una semplice variante dello schema TLS di base in cui il normale primo passo, la richiesta del client per il certificato del server, verrebbe ignorato dal server. Invece, il client deve già disporre di un certificato per il server "appuntato" nell'archivio certificati del sistema operativo e non dovrebbe (non potrebbe) verificare che abbia la versione più recente. Sarebbe quindi in grado di negoziare una connessione sicura senza che un singolo bit di dati effettivi venga inviato chiaramente (i dati a pacchetto sarebbero ancora in un pacchetto IP ben formato).
Concettualmente, funzionerebbe come segue; il client avrebbe la chiave pubblica del server, che è stata data offline (qui, l'unica differenza tra "client" e "server" che ci interessa è che il client è l'unico che avvia la comunicazione, entrambi i computer possono essere "server" "in altri sensi della parola, come i file server nel cloud). Il server avrebbe la chiave pubblica del client, che ha ricevuto offline. Il client crittografa una richiesta utilizzando la chiave pubblica del server, che conterrà il certificato del cliente. Quella richiesta va all'IP del server, e solo il server può decrittografarlo, anche se qualcun altro stava sniffando o spoofando il traffico sullo stesso indirizzo IP. La richiesta può contenere un nonce, ad esempio un semplice valore contatore, impedendo attacchi di riproduzione (il server può ignorare più richieste dallo stesso client con lo stesso nonce, sebbene debba decodificare ogni richiesta ricevuta per determinarlo, il che potrebbe renderlo vulnerabile a DDoS).
Il server utilizza quindi il certificato client, che può verificare in modo indipendente come client autorizzato perché una copia esatta del certificato client risiede nell'archivio del sistema operativo del server, per inviare una negoziazione di chiavi simmetriche. Da questo punto lo schema è praticamente identico alla negoziazione TLS a due certificati; il server invia al client la richiesta di negoziazione della chiave, il client riceve, imposta il proprio codice e restituisce un riconoscimento crittografato simmetricamente o l'altra metà del protocollo di scambio di chiavi in modo che il server ora sappia che sta parlando la stessa lingua. Da quel momento, client e server possono comunicare utilizzando il canale simmetrico. Tutto questo, senza che un osservatore di terze parti vedesse alcun pacchetto di dati in testo semplice.
Ora, questo è solo per creare un canale sicuro. Anche se il nodo client ha un IP statico, è sempre bene verificare successivamente, dopo aver negoziato il tunnel sicuro, che l'essere umano che controlla il computer dall'altra parte è autorizzato a utilizzare il sistema. Scambio di credenziali come nome utente / password o l'immissione di un valore di chiave a tempo limitato generato da un fob, sono mezzi comuni e perfettamente fattibili per autenticare l' utente dei computer autenticati.