[4351] in cryptography@c2.net mail archive

home help back first fref pref prev next nref lref last post

US Treasury use of BBN SafeKeyper in Echeck system

daemon@ATHENA.MIT.EDU (Ryan Lackey)
Thu Mar 18 17:00:41 1999

Date: Thu, 18 Mar 1999 16:17:21 -0400
From: Ryan Lackey <ryan@venona.com>
To: fjaffe@netcom.com
Cc: cryptography@c2.net, dbs@philodox.com

Frank Jaffe writes:

> Treasury's concerns include not only the security of the operating system
> but also the security of the network, and the potential for
> information warfare like attacks.  The system, both technology and
> procedures, has been designed to address those concerns.

In the system you outlined, it appears there is manual review of the
echecks on a terminal somewhere, prior to them being loaded into the
SafeKeyper for signing.

What assurances does the system have to defend against me maliciously
introducing code to the general purpose workstations (non-tamper-resistant)
used during the review process: code which displays one set of 
figures (the ones sent from the DoD) on the screen, but covertly sends
another, compiled into the software, to the SafeKeyper for signing?  To
the outside world, everything would seem to be doing its part, but I
would end up with e-checks payable to myself, rather than to the
desired party.  I then take the echeck, turn it into anonymous bearer
instruments, and flee the country a second time.

Since the SafeKeyper doesn't have any internal way of doing
rules-based checking of the echecks before sending them out AFAIK,
this would seem impossible to defeat without making the administrative
terminals tamper-resistant, in which case the SafeKeyper is somewhat
redundant (although presumably more secure than the terminals).  If
it did rules-based checking on the safekeyper unit, it could presumably
be caused to halt and display an error condition on the LEDs if a payee
it has never before seen is to receive a huge amount of money, or if 
a single check exceeds the national defense budget, etc.

I believe this to be a categorical problem for all systems lacking a
secured/tamper-resistant I/O conduit directly to the user.  If you've solved
it, I would be very interested to learn how.

Sincerely,
Ryan Lackey
ryan@venona.com



home help back first fref pref prev next nref lref last post