<div dir="ltr"><div><b>> Quick question: how do you send data out? </b><br></div><div>
<p style="font-family:"Segoe UI""><span class="gmail-im" style="font-family:"Segoe UI"">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.</span></p>
<p style="font-family:"Segoe UI""><span class="gmail-im" style="font-family:"Segoe UI"">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).</span></p><div><img src="cid:ii_kd7f4ns50" alt="rpi.gif" width="426" height="209"><br>
<p style="font-family:"Segoe UI""><span class="gmail-im" style="font-family:"Segoe UI"">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.</span></p></div><p style="font-family:"Segoe UI""><span class="gmail-im" style="font-family:"Segoe UI""></span></p><p style="font-family:"Segoe UI""><span class="gmail-im" style="font-family:"Segoe UI""><b>> Also, hm, here's a possibly stupid question: how do you keep the system time synchronized between the sender and the receiver?</b> <br></span></p><p style="font-family:"Segoe UI""><span class="gmail-im" style="font-family:"Segoe UI"">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.<br></span></p><p style="font-family:"Segoe UI""><span class="gmail-im" style="font-family:"Segoe UI"">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.<br></span></p><p style="font-family:"Segoe UI""><span class="gmail-im" style="font-family:"Segoe UI""><br></span></p><p style="font-family:"Segoe UI""><span class="gmail-im" style="font-family:"Segoe UI"">Below a suggested architecture for a signing server :</span></p><div><img src="cid:ii_kd7fkhsj1" alt="server.gif" width="477" height="170"><br></div><p style="font-family:"Segoe UI""><span class="gmail-im" style="font-family:"Segoe UI""></span></p><p style="font-family:"Segoe UI""><span class="gmail-im" style="font-family:"Segoe UI"">Denis<br></span></p><p style="font-family:"Segoe UI""><span class="gmail-im" style="font-family:"Segoe UI""><br></span></p></div><div><br></div><div>
</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Le mer. 29 juil. 2020 à 09:51, Peter Pentchev <<a href="mailto:roam@ringlet.net">roam@ringlet.net</a>> a écrit :<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Tue, Jul 28, 2020 at 10:33:42PM +0200, Denis BEURIVE via Gnupg-users wrote:<br>
> > Oh, quite the contrary. It just forces the attacker to get clever.<br>
> <br>
> If your server only sends data through an "outgoing data diode", then it<br>
> does not expose any entry point (you just disable all services : no SSH, no<br>
> ping, no HTTP... nothing). There is no way you can establish a connection<br>
> to the server. How can you hack a server if you have absolutely no way to<br>
> access it from the outside ? It seems just impossible.<br>
<br>
Quick question: how do you send data out? It cannot be via TCP<br>
connections, since those require a handshake and acknowledgements<br>
flowing both ways. It cannot be via any kind of TLS-based protocol for<br>
the exact same reason. In theory you might be able to devise some<br>
one-way protocol based on e.g. UDP or your own datalink layer and add<br>
some kind of signing into it, but that would require a security audit in<br>
its own right, and then there is the issue of dropped packets. So, as<br>
described in Rob's paper, the sending server has to continuously send<br>
the data over and over again, with no idea whether the receiving server<br>
has received any of it, parts of it, or the whole of it.<br>
<br>
Also, hm, here's a possibly stupid question: how do you keep the system<br>
time synchronized between the sender and the receiver? You cannot use<br>
any kind of time synchronization similar to NTP or even SNTP, since that<br>
would require incoming data and programs that process that incoming data<br>
and possible avenues of attack via (possibly still undiscovered)<br>
problems in those programs. So at some point, time drift will start to<br>
cause problems in the verification of the cryptographic signatures of<br>
the data the server sends.<br>
<br>
I am not saying that any of those problems is unsolvable, but it seems<br>
to me that devising robust solutions to all of them (and to all of<br>
the others that will come up along the way) will make the system much,<br>
much, *much* more complicated than "just a single one-way comm device".<br>
At some point the question would arise whether all these complications<br>
and all these newly-devised communication protocols are indeed worth it.<br>
Once again, not saying that the answer is always "no", but, well...<br>
<br>
G'luck,<br>
Peter<br>
<br>
-- <br>
Peter Pentchev <a href="mailto:roam@ringlet.net" target="_blank">roam@ringlet.net</a> <a href="mailto:roam@debian.org" target="_blank">roam@debian.org</a> <a href="mailto:pp@storpool.com" target="_blank">pp@storpool.com</a><br>
PGP key: <a href="http://people.FreeBSD.org/~roam/roam.key.asc" rel="noreferrer" target="_blank">http://people.FreeBSD.org/~roam/roam.key.asc</a><br>
Key fingerprint 2EE7 A7A5 17FC 124C F115 C354 651E EFB0 2527 DF13<br>
</blockquote></div>