Protecting encryption server

[Denis BEURIVE]

*> Quick question: how do you send data out? *

This is not a problem. You connect the output of your data diode to a
computer that will send the data over the Internet using whatever
required protocol. Some commercially available "data diodes" include a
"bare data diode" and the necessary electronics required to send data over
the Internet using the TCP/IP stack.

You can create a data diode with 2 Raspberry Pi (connected through the GPIO
ports). The receiving Raspberry Pi receives data from its GPIO ports... and
nothing prevents it from sending the data over the Internet using its
Internet connection. It does so by using the TCP/IP stack. Therefore, it
knows if the receiving server receives the data or not (since the TCP/IP
stack allows bidirectional exchanges).
[image: rpi.gif]

You can hack the RPI connected to the Internet. But you have no way to hack
the second one since it is not connected to the Internet and since the data
diode is a one way only transmission.

*> Also, hm, here's a possibly stupid question: how do you keep the system
time synchronized between the sender and the receiver?*

That's a good question. However, there is a second question : do you need
to keep the system time synchronized ? If not, then there is no need to
worry about it.

However, if you need to get a very precise time, you can synchronize your
server using a radio-controlled clock (RCC). You can get the necessary
component for a Raspberry Pi, for example.


Below a suggested architecture for a signing server :
[image: server.gif]

Denis




Le mer. 29 juil. 2020 à 09:51, Peter Pentchev <roam at ringlet.net> a écrit :

> On Tue, Jul 28, 2020 at 10:33:42PM +0200, Denis BEURIVE via Gnupg-users
> wrote:
> > > Oh, quite the contrary.  It just forces the attacker to get clever.
> >
> > If your server only sends data through an "outgoing data diode", then it
> > does not expose any entry point (you just disable all services : no SSH,
> no
> > ping, no HTTP... nothing). There is no way you can establish a connection
> > to the server. How can you hack a server if you have absolutely no way to
> > access it from the outside ? It seems just impossible.
>
> Quick question: how do you send data out? It cannot be via TCP
> connections, since those require a handshake and acknowledgements
> flowing both ways. It cannot be via any kind of TLS-based protocol for
> the exact same reason. In theory you might be able to devise some
> one-way protocol based on e.g. UDP or your own datalink layer and add
> some kind of signing into it, but that would require a security audit in
> its own right, and then there is the issue of dropped packets. So, as
> described in Rob's paper, the sending server has to continuously send
> the data over and over again, with no idea whether the receiving server
> has received any of it, parts of it, or the whole of it.
>
> Also, hm, here's a possibly stupid question: how do you keep the system
> time synchronized between the sender and the receiver? You cannot use
> any kind of time synchronization similar to NTP or even SNTP, since that
> would require incoming data and programs that process that incoming data
> and possible avenues of attack via (possibly still undiscovered)
> problems in those programs. So at some point, time drift will start to
> cause problems in the verification of the cryptographic signatures of
> the data the server sends.
>
> I am not saying that any of those problems is unsolvable, but it seems
> to me that devising robust solutions to all of them (and to all of
> the others that will come up along the way) will make the system much,
> much, *much* more complicated than "just a single one-way comm device".
> At some point the question would arise whether all these complications
> and all these newly-devised communication protocols are indeed worth it.
> Once again, not saying that the answer is always "no", but, well...
>
> G'luck,
> Peter
>
> --
> Peter Pentchev  roam at ringlet.net roam at debian.org pp at storpool.com
> PGP key:        http://people.FreeBSD.org/~roam/roam.key.asc
> Key fingerprint 2EE7 A7A5 17FC 124C F115  C354 651E EFB0 2527 DF13
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20200729/a4807cfb/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: rpi.gif
Type: image/gif
Size: 3183 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20200729/a4807cfb/attachment.gif>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: server.gif
Type: image/gif
Size: 5120 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20200729/a4807cfb/attachment-0001.gif>