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 [EMAIL PROTECTED]
