Secure TCP traffic for inter process communication

Question

I have several processes running on a system that interact with each other by TCP (eg. with the asynchronous messaging protocol by twisted).

process1 <=====> broker <=====> process2

There is one server instance (broker) running on a linux host, that listens to a TCP socket localhost:port. There are also some other processes, running on the same host, which query the broker instance by using the socket via TCP (given by twisted). The broker has access to a hardware security module (HSM).

I'm currently thinking about the security aspects of this design. Would it be possible for an eavesdropper, who has direct physical access to the host, to listen to the TCP traffic between the clients and the broker on this host? Since sometimes sensitive data is being transferred, I want to secure the communication between the processes and broker on the host.

How can this be done? There is always the problem of storing a private secret. For the broker its no problem because it has access to HSM, but for the client-processes which interact with the broker. Its hard to hide a secret for an attacker which has physical access to the host. How can authentication/encryption between processes and broker be realised?

Hope you understand my problem and can help me!

EDIT: SSL/TLS wouldn't be a good approach, since it comes with high overhead and there also exists the problem of secure storage for private secret.

Answer 1

If you want to restrict inter process communication on a machine, I'd suggest doing away with TCP and instead uses Unix domain socket. Unix domain socket can be used exactly the same way as TCP (it's a bidirectional socket), but it creates a socket file instead of listening on a TCP port. You can control permission on the socket file using standard filesystem permissions. Twisted supports Unix domain socket.

If you really have to use TCP, then you can use SSL without encryption. By default, the eNULL cipher and aNULL authentication is not permitted in OpenSSL, but you can explicitly request for it. I personally would not recommend this.

You may also have some luck defining iptable rule that restricts how processes can connect to some TCP port.

On the whole though, trying to defend against someone with unrestricted root/physical access to your machine is a futile effort, and encryption for inter process communication within the same machine is rather silly but it's fairly harmless.

Answer 2

Listening on localhost traffic is possible on Windows and Linux as well.

In Linux tcpdump -i lo.

You should consider at least encoding with special algorithm your communication and also consider protecting the process of broker from being dumped, debugged or reverse-engineered.

Answer 3

The communications between these processes can always be intercepted by an attacker with privileged access to the system.

With root access to the box, the attacker owns the system and can circumvent anything and everything you implement (for the most part). Encrypted traffic? The functions that process the encryption keys can be hooked or the process memory can be dumped. Anti-reverse engineering is a possibility, but it can always be circumvented by someone skilled enough. The more effective and secure way of doing this would be writing an LKM that enforces the security of your processes at the kernel level; this requires a great deal of experience in kernel programming and is extremely difficult to do correctly (dare I say impossible?!) -- someone will always find a loophole, though it's something to consider.

Also, non-root users can't create raw sockets, which are needed to sniff packets (meaning an attacker will need root access to your system in order to intercept communications between your processes).

Securing information on a system from an attacker who already owns it is not a trivial task. You can make it harder to access said information, but you can never fully secure it.