[4354] in cryptography@c2.net mail archive
Re: US Treasury use of BBN SafeKeyper in Echeck system
daemon@ATHENA.MIT.EDU (Kawika Daguio)
Thu Mar 18 17:39:17 1999
Date: Thu, 18 Mar 1999 17:22:55 -0500
From: "Kawika Daguio" <KDAGUIO@aba.com>
To: <fjaffe@netcom.com>, <ryan@venona.com>
Cc: <cryptography@c2.net>, <dbs@philodox.com>
Ryan,
I was a Treasury, Financial Management Service employee before I came to =
the ABA. I can tell you that no one either in a bank or in the Treasury =
relies upon hardware and software to prevent corrupt employees from =
embezling money. We have a lot of compensating controls deployed in =
addition to the technology. Some of those controls are typical old style =
security measures including secure facilities and the like. The rainbow =
series (not just the orange and red books) are still driving things in =
this space. If you add the auditing measures that are part of the =
financial communities standard practices, you get a pretty darned robust =
system. Lastly, getting away with the money and getting to spend it are a =
lot harder than most people think. =20
...kawika...
speaking only for myself
>>> Ryan Lackey <ryan@venona.com> 03/18/99 03:17PM >>>
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=20
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=20
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=20
