With my last post about the entropy key hardware true random number generator (TRNG), I was curious if I could set this up as a server. Basically, bind to a port that spits out true random bits over the internet, and allow clients to connect to it to fill their own entropy pools. One of the reasons I chose the entropy key from Simtec was because they provide Free Software client and server applications to make this possible.
So, I had a mission- make it happen and cost effective as possible. To be truly cost effective, the server the keys are plugged into cannot consume a great amount of wattage. It should be headless, not needing a monitor. It shouldn’t be a large initial cost up front either. The application should be lightweight, and the client should only request the bits when needed, rather than consuming a constant stream. Thankfully, that last requirement is already met in the client software provided by Simtec. However, to reach the other points was a bit of a challenge, until I stumbled upon the Raspberry Pi. For only $35, and consuming no more than 1Whr, I found my target.
Unfortunately, the “Raspbian” operating system uses some binary blobs as part of the ARM architecture where source code is not available. Further, they chose HDMI over the cheaper and less proprietary DisplayPort as the digital video out. However, it’s only $35, so meh. After getting the operating system installed on the SD card, I installed ekeyd per my previous post, and setup the entropy keys. Now, at this point, it’s not bound to a TCP port. That needs to be enabled. Further, if binding to a TCP port, the data will be unencrypted. Because the data is whitened and true random noise, it would prefer to keep it that way, and not hav ethe data biased on the wire. So, I would also need to setup stunnel.
First, to install the packages:
$ sudo aptitude install ekeyd stunnel4
Now, you’ll also need to setup your entropy keys. That won’t be covered here. You do need to configure ekeyd to bind to a port on localhost. We’ll use stunnel to bind to an external port. Edit the /etc/entropykey/ekeyd.conf, and comment out the following line:
The default port of 1234 is fine, as it’s local. If it’s already in use, you may want to choose something else. Whatever you do use, this is what stunnel will connect to. So, let’s edit the /etc/stunnel/stunnel.conf file, and setup the connection. To make sure you understand this, stunnel will be acting as a client to ekeyd. Further, stunnel will be acting as a server to the network. Stunnel clients will be connecting on this external port.
cert = /etc/stunnel/ekeyd.pem [ekeyd] accept=8086 connect=1234
This configuration says that stunnel will connect locally on port 1234 and serve the resulting data on port 8086, encrypted with the /etc/stunnel/ekeyd.pem SSL certificate. Notice that we are actually using a PEM key and certificate for handling the encrypted bits. This can be signed by a CA authority for your domain already, or it can be self-signed. In my case, I went with self-signed and issued the following command, making the certificate good for 10 years:
# openssl req -new -out mail.pem -keyout /etc/stunnel/ekeyd.pem -nodes -x509 -days 3650
When finished with creating the SSL certificate, we are ready to start serving the bits. Start up the ekeyd server, then the stunnel one:
$ sudo /etc/init.d/ekeyd restart $ sude /etc/init.d/stunnel4 restart
You can now verify that everything is setup correctly by verifying the connections on the box. You should see both ports bound, and waiting for connections based on our configuration above:
$ netstat -tan | awk '/LISTEN/ && /(8086|1234)/' tcp 0 0 127.0.0.1:1234 0.0.0.0:* LISTEN tcp 0 0 0.0.0.0:8086 0.0.0.0:* LISTEN
At this point, the only thing left to do is to poke a hole in your firewall for port 8086 (not port 1234), and allow stunnel clients to connect. The clients will also need to install the ekeyd-egd-linux and stunnel4 packages. A separate post on this is forth-coming.