Secure communication between two applications on the same system

Question

I'm writing a software which is divided into two separate stand-alone pieces. One is a service like application that handles all the logics, the other one is a GUI application that just works as a front-end and is aimed to be used by the end user. The service would listen to a port and accept requests from the client (GUI) application.

Since some sensitive information is exchanged between the service and the GUI applications, they need to be encrypted before getting transferred. One way to secure data is to use a key based encryption but keys need to be stored somewhere on the disk or even in the application's source code, but would rather avoid using keys.

How can I handle a secure connection between service and GUI application without using a key-based encryption algorithm?

Answer 1

These are the golden rule of computer security: "It is impossible to hide anything from a competent user with system administrator privilege" and "any competent user with physical access to the device can always elevate himself to system administrator".

You cannot hide any information from someone with physical control of the machine. If the secret you are trying to hide is really important, then you should never transfer the data to the machine and do your processing elsewhere in a place that you control.

Your program is running on a user's machine. You cannot protect your data from the user. With that in mind, does this mean we're doomed? Not necessarily. The operating system provides a wealth of mechanism for programs to communicate privately with another program that will not allow another unprivileged application to intercept it. So, while you cannot protect any data from the user themselves, you can protect your data from another unprivileged program. Providing security boundary between unprivileged programs is one of the main job of the operating systems.

The simplest of this is an anonymous pipe. A pipe allow a unidirectional stream of data to be transported between program. Anonymous pipe is available in Windows, Linux, OSX, and all Unix-like systems. Anonymous pipe most commonly recognized as a pair of pipe called stdin and stdout that allows a parent process to send and receive a stream of data to and from its children. Anonymous pipe can only be used between processes that have parent and child relationship. There is also a named pipe, but they behave differently in Windows and in Linux/Unix-like systems, we will get back to this later.

Another IPC that are commonly available is sockets. Sockets is like a bidirectional pipe. There are many different sockets but they work similarly. The most commonly known is TCP socket. TCP socket is primarily intended for networking between machines but you can also create a loopback TCP socket which can only be used within the same machine. A loopback socket provides privacy (only the program the program that connects and the program that listens can read the data passing through the socket), however it does not really provide mechanism to restrict who can be the other side of the socket.

Another type of socket available in Unix for communication between processes in the same machine is Unix Domain Socket. A Unix domain socket is exposed to programs as a "special file" in the filesystem, and unix filesystem permission is used to control access to the socket. A domain socket cannot be connected to by programs that does not have the right access permission to access the socket file. In Unix-like systems, this means that your service and GUI should run as the same user and/or group that are reserved only for your program and you set the socket file permission appropriately.

Let's get back to named pipe. In Linux/Unix-like systems, a named pipe is pretty much like stdin/stdout in that they are unidirectional. In Windows, however, a named pipe is actually bidirectional and is pretty much the equivalent of Unix domain socket in Windows. Like a lot of things in Windows, named pipe is secured with ACL.

With iOS things becomes a bit hairy. A non-jailbroken iOS only allows a very limited set of inter-process communication, and neither will give you a socket. But if we play loose with definition, in the iOS application, the service program and the GUI program is probably going to actually be the same application, and thus you can simply create a stream directly between different components of the application. This is also secure as the stream is accessible only within the application.

Android provides more options for IPC, including the ability to create domain socket. The API is different but they are conceptually similar with regular Linux. Alternatively, you may go the same approach like in iOS and package your service and GUI in the same application and just use in-process streams.

Answer 2

I assume you are the only root/administrator on the machine.

You can use one of those two options:

1. Do not allow other users on that machine at all
2. Let the process run as a special user and use a communication mechanism that is only accessible (read + write) to that user (named pipe, unix domain socket, etc.)

Any of those two options will make it unnecessary to encrypt your data on transit.

Note: If there is another (sufficiently skilled) administrator on the machine, you cannot hide anything (including encryption keys) at all.

Answer 3

Basically, security is usually bear by the key, not the algorithm. So you're on a fool's errand here. As stated by the Kerckhoff's principle: "A cryptosystem should be secure even if everything about the system, except the key, is public knowledge.", or as Shannon reformulated it : "the enemy knows the system". So you can't really have a cryptosystem that do not uses a key in some form and is trully secured.

Since you mentioned tls in your taglist, let me remind you how this work in principle.

The idea of SSL/TLS (https) is to negotiate a symmetric encryption key to be use for a session of communication between a client and a server. The client connects to the server and asks for its public key (asymmetric cryptography). The key comes as part of a certificates, which can be validated using the chain of certification of the certificate. With that public key and a proper validation of the certificate, the client knows to whom it's talking. So he can safely transmit information.

The client can then use the public key to negotiate a symmetric key to talk to each other for this session. The key cannot be derived for anyone outside the communication (please refer to more detailed explanations if necessary https://security.stackexchange.com/a/20833/1574)

With the use of TLS, confidentiality is ensured between the two partners and the client also can authenticate the server using the chain of certification. If there are needs to authenticate the clients, TLS also support clients certificate.