background image
Tech Note #110: Concept for a Secure Network Computer
2000 Bionic Buffalo Corporation; All Rights Reserved.
         Tuesday, 11 January 2000
Page 10 of 18
Interior SM
User I/O
hosted by
SNC user
connects to
transfers user
data, scans,
and secret data
provides secret
data or scan
provides secret data or
scan; requests credentials
prompts for scan or
secret data; prompts
for choice of enclave;
displays various
informational or
status items
(signatures and
connects to
tn011008 ©2000 Bionic Buffalo Corp
The user i/o device is not redundant in this architecture, nor is the identification token itself. If
the i/o device were to fail, then it would be impossible to authenticate the user, and security of
the SNC would not be breached. The identification token might fail in two ways:
The token might incorrectly decide that the user’s secret information was correct, and
erroneously sign a document. If this were a single-point failure, it would be due to a
shortcoming of the token’s design or architecture, and is beyond the scope of this
document. (One workaround might to require two separate tokens.)
The token might issue an incorrect signature, or otherwise fail to operate incorrectly. Since
this is by nature a cryptographic operation, any failure mode will probably result in a failure
to authenticate the user, and can therefore be ignored
If the identification token is used for other purposes (such as to verify that the SNC itself is
authentic), then this analysis is not complete. However, such problems involve the architecture
of the entire system, and not only that of the SNC, and merit additional consideration beyond
that presented here.
System-wide, protection against single-point failures in user authentication is a function of the
external boundary controller, and not of the SNC itself. For redundancy, an enclave might elect
to use two boundary controllers, serially connected, in the same way this SNC uses interior and
exterior boundary controllers.