🚀 go-pugleaf

In article <920908214524.887195@DOCKMASTER.NCSC.MIL>, WHMurray@DOCKMASTER.NCSC.MIL writes:
|> 
|> Sorry Paul, trusted path as in the orange book relies upon a trusted
|> terminal.  It does not protect against the kind of attack descirbed.
|> Defense against that attack requires rue peer-to-peer authentication
|> that is independent of the terminal and resistant to playbacks.
|> 
|> Regards, Bill
|> ____________________________________________________________________
|> William Hugh Murray                     203-966-4769
|> Information System Security             203-326-1833 (CELLULAR)
|> Consultant to Deloitte & Touche         ARPA: WHMurray@DOCKMASTER
|>                                         MCI-Mail: 315-8580
|>                                         TELEX: 6503158580
|>                                         FAX: 203-966-8612
|>                                         Compu-Serve: 75126,1722
|> 49 Locust Avenue, Suite 104             PRODIGY: DXBM57A
|> New Canaan, Connecticut 06840
|> 

Bill Murray is absolutely correct here.  I vastly oversimplified the
issue.  Trusted path is just part of what you need.  Thanks, Bill, for
catching me on that!

What Bill is describing is a form of trusted path that runs over the 
network and provides a trusted path from my smart ATM card back to the
bank's computers.   The smart ATM card must authenticate itself to the
bank's computers and the bank must authenticate itself to the smart
card.  If the terminal is suspected of being hostile (either because
the merchant has bugged the point of sale terminal or because a false-front
ATM machine has been constructed out on the street), then the mutual
authentication has to use encrypted communications in both directions.
DEC's DSSA architecture is one way of doing this, and there are many others.