Prototype Architecture of the Key Container

25 February 2020

I wanted my phone to handle the critical tasks carried out by a smart card, ensuring that an encryption or signing key could be used without it being present on the computer, where it is very easy to steal. If the phone is able to use the key for me and send only the result of the critical operations to my computer, than this data can remain in a much safer place, preferably on a device that is rendered incapable of establishing wireless connections.

I began thinking about this project with support for old devices forgotten in the drawers in my mind. To target as many as worth it of them, I wish to make my application as portable as possible.

Let me present my initial idea:

Key container architecture

In a perfect world, what is on the left of the “Boundary of portability”, should run on even the earliest versions of Android, or on a similar device as a Raspberry Pi - or really anything, that is able to run a tiny Linux-based operating system.

What I have so far

Last time I have managed to communicate with my phone over USB. The reason I pursued that was to establish a secure communication line from the computer to the device. Unfortunately, my efforts did not fully achieved their goal as I haven’t found a way to hide the UNIX sockets from other apps on the phone. On Android, I was only able to use abstract sockets, which are visible system-wide.

The attempt was not entirely useless, however. Using the cable instead of a wireless connection gives me an additional wall to break, and a chance not to expose the interface of my key container to a public WiFi network.

At that point, UNIX sockets in the abstract namespace are not more secure than simply opening local ports on the phone, therefore I’m not going to stick to them. Nevertheless, it was an interesting experiment.

In order to ensure that the traffic won’t get intercepted by malicious or exploited buggy applications on the phone, I’ll probably secure the REST API I would like to serve over the phone with TLS.

Project risks

The devil hides in the details as one says. In the following parts of the series I’m going to make small proof-of-concepts for those ideas that might not be viable. These are:

  • Creating native binaries to support devices as old as possible.
    • Compiling libraries such as OpenSSL or mbed TLS
    • Bundling binaries in a way Android can run and use for us it but we cannot access its data via ADB. That way we can keep our keys safe.
      • Letting Android start the executable for us that creates the REST server, then accessing the REST server via ADB port forwarding.
  • Emulating a dummy GnuPG smart card on a Linux PC.
  • (Emulating a dummy PKCS#11 module)

Why the native binaries? We’ll talk about that in the next episode!