Tech Note #110: Concept for a Secure Network Computer
©
2000 Bionic Buffalo Corporation; All Rights Reserved.
Tuesday, 11 January 2000
http://www.tatanka.com
[tn0110]
Page 4 of 18
An important architectural feature of the SNC described in this Tech Note is that no single
failure will compromise the security of the system. The meaning of “failure” is taken broadly, to
include hardware and software design and implementation errors, as well as hardware
malfunctions.
Since the software running in the HC is not verified, it must be considered hostile. It must be
presumed that HC applications and operating systems might be malicious, and may attempt to
breach the security of the SNC by leaking information into or out of an information domain.
The architecture of the SNC must prevent such leaks.
Network Architecture
Even when there is no expectation that a network will be shared with other parties, secure
connections among enclaves in a domain will typically use virtual private network (VPN)
technologies. VPN protocols use certificates, cryptography, and signing processes to assure the
integrity and impenetrability of traffic, whether or not the links are shared with other traffic.
The leading candidate protocol for a VPN of the sort required by the model described above is
IPsec, which encapsulates ordinary IP traffic within secure connections. The details of IPsec are
beyond the scope of this paper, but are well documented elsewhere. (Please refer to the
Bibliography at the end of this paper.) IPsec allows the creation of a tunnel between the
boundary controllers of different enclaves.
The BC permits the HC to send and receive network traffic only through the tunnel, enforcing
the isolation of the information domain from other domains. The BC has access to and from the
remote enclave only, and not to any other nodes of the network. To maximize the number of
programs (and operating systems) which may run on the HC, operation of the network is
transparent to the HC: at least one of the nodes within the remote enclave appears local to the
HC. (The “local” node may be a gateway to the enclave’s other nodes, or all of the enclave’s
nodes may be local, and on the same subnet with the HC.)
Prior to establishing a VPN connection, the boundary controllers must agree on which keys are
to be used for the session. This process is known as key exchange, and requires that the parties
identify themselves so that authorization to make the connections can be ascertained. (Certifying
the identity of users is known as authentication.)