¿Cómo cifro la dirección IP de origen y destino, junto con varias partes de un correo electrónico?

Para proteger los destinos de paquetes, debe abstraer completamente la capa de red, lo que generalmente significa algún tipo de VPN cifrada. Esto significaría que ningún hardware en la red local sabría qué paquetes se están transmitiendo, a dónde o qué contienen.

Desafortunadamente, esto no resuelve el problema real, solo lo mueve hacia arriba. Su VPN / enlace encriptado tiene que conectarse a la red real en algún momento y, tan pronto como lo haga, se verá obligado a utilizar la información de enrutamiento correcta. Podría mitigar esto moviendo los bloques de IP de vez en cuando / teniendo múltiples conexiones a la red, pero esto podría ser complejo de mantener.

Un enfoque mejorado podría ser utilizar TOR para enmascarar el enrutamiento de su red. no es perfecta pero es otra capa de defensa.

Entonces, tal vez una conexión SSL SMTP a través de su vpn cifrada a su servidor de correo y el correo electrónico cifrado a través de TOR a los servidores de correo de los destinatarios. (SSL en la parte superior de su cifrado de VPN para proteger contra otras máquinas en la VPN. Es posible que desee considerar los certificados de cliente para garantizar la fuente del correo electrónico)

Editar: Habiendo descubierto su caso de uso en los comentarios, y centrándose únicamente en proteger la conexión al servidor smtp, creo que dependerá de lo fácil que sea configurar los sensores de manera única.

Si es barato, use un certificado de cliente SSL único con cada sensor. Esto asegurará la conexión y confirmará la ID de ambas partes, sin sensores falsificados.

Si la configuración es costosa, use algo basado en PSK: todavía obtiene el cifrado, pero si un dispositivo está comprometido, todos son [al menos para cualquiera dentro de la VPN].

IP de origen: si te conectas a un servidor de correo que controlas, puedes configurarlo para que escriba encabezados de origen falsos (¿realmente importa ya que probablemente utilizarás rangos de IP de red privada para las máquinas de tus remitentes?), pero El servidor de correo ascendente verá la dirección IP real de su servidor de correo inmediato. Si compromete o no esa información de manera veraz con los encabezados que escribe es un asunto diferente.

IP de destino: en algún momento, deberán mostrarse de forma clara a los MTA que transita el correo electrónico para que se pueda enrutar correctamente. En ese momento, los MTA que manejan ese correo electrónico probablemente (como deberían) escribirán esa información en los encabezados del correo.

Cifrar el nombre de usuario: ¿supone que esto significa asegurar el proceso de inicio de sesión? Pásalo a través de un túnel seguro.

Encriptar el correo electrónico en sí mismo: depende de los clientes de correo electrónico del remitente y el destinatario, y la cantidad de facilidad de uso que se requiere. Podría ir tan lejos como enviar blobs Truecrypted de un lado a otro como archivos adjuntos, lo que no requiere modificaciones a los clientes de correo electrónico. O, como mencionó, implemente un sistema basado en certificados: los detalles finos de la implementación dependerán en gran medida del cliente de correo electrónico, del sistema operativo y de la cantidad de compatibilidad necesaria (¿qué sucede cuando las personas externas deben enviar o recibir correos electrónicos seguros?).

No es trivial que dos personas altamente técnicas intercambien correos electrónicos con sus requisitos satisfechos. Lograr eso para las comunicaciones entre los dispositivos integrados y las personas que los administran es alucinante. El contenido cifrado es el requisito más simple. OP podría usar GnuPG y dar a cada dispositivo una clave privada única. O como Basic sugirió, OP podría usar OpenSSL y dar a cada uno una clave de cliente única.

Mientras el nombre de usuario de inicio de sesión sea parte del mensaje, no es necesario cifrarlo por separado. Si los nombres de usuario deben permanecer ocultos después del descifrado del mensaje, cada usuario podría tener un ID de cuenta anónimo o seudónimo.

El cifrado de las IP de origen y destino no tiene sentido, como OP y otros han observado. Si solo es necesario ocultar esas IP de los observadores casuales en las redes que intervienen, el uso de proxies en cada extremo sería suficiente. Pero si los administradores de dispositivos no deben conocer las IP públicas de los dispositivos, y los dispositivos no deben conocer las IP públicas de los administradores de dispositivos, tiene un gran desafío.

Algunos (muchos) pueden reírse de esto, pero el uso de nmaster de Mixmaster remailer puede ser el enfoque más simple en ese caso. Cada dispositivo y administrador tendría una dirección de correo electrónico en un servidor de red Mixmaster público o privado. Se puede acceder a algunos nymservers como servicios ocultos de Tor, para un anonimato adicional. Los mensajes cifrados salientes especifican una cadena de rmasterers Mixmaster que se utilizarán para llegar a la dirección de destino. Las respuestas cifradas pueden dirigirse a mensajes alt.anonymous y firmarse para que los destinatarios puedan identificarles mensajes. Los clientes descargan periódicamente todos los mensajes en mensajes alt.anonymous, opcionalmente a través de Tor, e identifican aquellos que pueden descifrar.

Esto depende de lo que quiere decir con "dirección IP de origen y destino".

El correo electrónico de Internet normal basado en SMTP registra una lista de direcciones IP en los encabezados de un mensaje como los que cruzan el mensaje de un "Agente de transferencia de correo" (MTA) a otro. Probablemente pienses en estos como "servidores de correo". No es raro que un solo mensaje transite varios MTA entre el envío y la recepción.

Si desea proteger la dirección IP del dispositivo que usó el usuario para escribir el mensaje, es relativamente simple. Necesitará un MTA (es decir, un servidor de correo) que aceptará el correo electrónico en su nombre y NO registrará la dirección IP del Agente de Usuario de Correo (MUA) en los encabezados. Este MTA tendría que estar bien conectado a Internet y tener la confianza de otros MTA para que sigan aceptando mensajes de este. En esta era de guerra anti-SPAM, esto puede ser un poco complicado. Otro enfoque sería registrar la dirección IP del MTA como la dirección MUA.

La dirección del MUA del destinatario final normalmente no se registra en los encabezados, simplemente porque el MUA accede al mensaje a través de un protocolo que no es SMTP, generalmente IMAP o POP. Como el registro de la cadena de direcciones es realmente una actividad de MTA, el MUA generalmente no hace esto. El servidor POP o IMAP que usa puede ser, pero no es común.

Si desea utilizar la infraestructura de correo electrónico SMTP de Internet, los MTA involucrados se marcarán en los encabezados de los mensajes en algún momento.