Come crittografare l'indirizzo IP di origine e di destinazione, insieme a varie parti di un'email?

Per proteggere le destinazioni dei pacchetti, è necessario astrarre completamente il livello di rete, che di solito significa una qualche forma di VPN crittografata. Ciò significherebbe che nessun hardware sulla rete locale potrebbe sapere quali pacchetti vengono trasmessi, dove o che cosa contengono.

Sfortunatamente, questo non risolve il vero problema, ma lo sposta a monte. Il tuo collegamento VPN / criptato deve connettersi alla rete reale ad un certo punto e, non appena lo fa, sarai costretto a utilizzare le informazioni di routing corrette. Si potrebbe attenuare questo spostamento spostando i blocchi IP ogni tanto / con più connessioni alla rete, ma ciò potrebbe essere complesso da mantenere.

Un approccio migliore potrebbe essere l'uso di TOR per mascherare il routing dalla tua rete. È non perfetto ma è un altro livello di difesa.

Quindi forse una connessione SMTP SSL tramite la tua VPN vpn al tuo server di posta elettronica e posta crittografata su TOR ai server di posta dei destinatari. (SSL in aggiunta alla crittografia VPN per la protezione da altri computer sulla VPN. Potresti considerare i certificati client per garantire l'origine della posta elettronica)

Modifica: Avendo appena individuato il tuo caso d'uso nei commenti e concentrandoti esclusivamente sulla protezione della connessione al server smtp, penso che dipenderà da quanto sia facile configurare i sensori in modo univoco.

Se è economico, usa un certificato di client SSL univoco con ciascun sensore. Ciò garantirà la connessione e confermerà l'ID di entrambe le parti, senza sensori di spoofing.

Se è costoso configurare, usa qualcosa di PSK basato - ottieni comunque la crittografia, ma se un dispositivo è compromesso, sono tutti [almeno per chiunque all'interno della VPN].

IP di origine: se ti connetti a un server di posta che controlli, puoi configurarlo per scrivere intestazioni di origine false (è davvero importante dal momento che probabilmente utilizzerai gli intervalli IP di rete privata per le macchine dei mittenti?) - ma il il server di posta upstream vedrà il vero indirizzo IP per il tuo server di posta immediato. Indipendentemente dal fatto che imponga o meno tali informazioni in modo veritiero alle intestazioni che scrive è una questione diversa.

IP di destinazione - A un certo punto, dovranno apparire in chiaro agli MTA che l'email transita in modo che possa essere instradato correttamente. A quel punto, gli MTA che gestiscono quell'e-mail probabilmente (come dovrebbero) scrivere tali informazioni nelle intestazioni della posta.

Crittografa il nome utente - Presumi questo significa proteggere il processo di accesso? Passalo attraverso un tunnel sicuro.

La crittografia dell'e-mail stessa - dipende dai client di posta elettronica del mittente e del destinatario e dalla quantità di usabilità richiesta. Si potrebbe andare avanti come solo inviando blob Truecrypted avanti e indietro come allegati, che non richiede modifiche ai client di posta elettronica. O come hai detto, distribuisci un sistema basato su certificati: i dettagli di implementazione di precisione dipenderanno molto dal client di posta elettronica, dal sistema operativo e dalla quantità di compatibilità necessaria (cosa succede quando gli "outsider" devono inviare o ricevere email sicure?).

Non è banale che due persone altamente tecniche scambino email con le tue esigenze soddisfatte. Realizzare che per le comunicazioni tra i dispositivi embedded e le persone che li gestiscono è da capogiro. La crittografia del contenuto è il requisito più semplice. OP potrebbe usare GnuPG e dare a ciascun dispositivo una chiave privata univoca. O come suggerito di base, OP potrebbe usare OpenSSL e dare a ciascuno una chiave client univoca.

Se il nome utente di accesso è parte del messaggio, non è necessario crittografarlo separatamente. Se i nomi utente devono rimanere oscurati dopo la decrittografia dei messaggi, ogni utente può avere un ID account anonimo o pseudonimo.

La crittografia degli IP di origine e di destinazione non ha senso, come OP e altri hanno osservato. Se è semplicemente necessario oscurare quegli IP da osservatori casuali su reti interconnesse, utilizzare i proxy su ciascuna estremità sarebbe sufficiente. Ma se i gestori dei dispositivi non devono conoscere gli IP pubblici dei dispositivi e i dispositivi non devono conoscere gli IP pubblici dei gestori dei dispositivi, hai una vera sfida.

Alcuni (molti) potrebbero ridere di questo, ma l'uso delle palestre dei remailer Mixmaster potrebbe essere l'approccio più semplice in quel caso. Ogni dispositivo e manager avrebbero un indirizzo email in un server di server Mixmaster pubblico o privato. Alcuni nymserver possono essere raggiunti come servizi nascosti Tor, per un maggiore anonimato. I messaggi crittografati in uscita specificano una catena di remailer Mixmaster da utilizzare per raggiungere l'indirizzo di destinazione. Le risposte crittografate possono essere indirizzate a alt.anonymous.messages e firmate in modo che i destinatari possano identificare i messaggi. I client scaricano periodicamente tutti i messaggi in alt.anonymous.messages, opzionalmente tramite Tor, e identificano quelli che possono decifrare.

Dipende da cosa intendi per "indirizzo IP di origine e destinazione"

L'e-mail Internet regolare basata su SMTP registra un elenco di indirizzi IP nelle intestazioni di un messaggio mentre i messaggi attraversano da un "Mail Transfer Agent" (MTA) a un altro. Probabilmente pensi a questi come "server di posta". Non è raro che un singolo messaggio transiti più MTA tra invio e ricezione.

Se si desidera proteggere l'indirizzo IP del dispositivo utilizzato dall'utente per digitare il messaggio, è relativamente semplice. Avrai bisogno di un MTA (cioè di un server di posta) che accetterà email per tuo conto e NON registrerà l'indirizzo IP del Mail User Agent (MUA) nelle intestazioni. Questo MTA dovrebbe essere ben collegato a Internet e sufficientemente fidato dagli altri MTA affinché continuino ad accettare messaggi da esso. In questa epoca di guerra anti-SPAM, questo può essere un po 'complicato. Un altro approccio sarebbe quello di registrare l'indirizzo IP del MTA stesso come l'indirizzo MUA.

L'indirizzo del MUA del destinatario finale non è normalmente registrato nelle intestazioni, semplicemente perché il MUA accede al messaggio tramite un protocollo diverso da SMTP, tipicamente IMAP o POP. Poiché registrare la catena di indirizzi è in realtà un'attività MTA, il MUA di solito non lo fa. Il server POP o IMAP che utilizzi potrebbe, ma non è comune.

Se si desidera utilizzare l'infrastruttura di posta elettronica SMTP di Internet, gli MTA coinvolti verranno contrassegnati nelle intestazioni dei messaggi a un certo punto.