home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #20 / NN_1992_20.iso / spool / sci / crypt / 3170 < prev    next >
Encoding:
Internet Message Format  |  1992-09-09  |  2.2 KB

  1. Xref: sparky sci.crypt:3170 alt.security:4324 comp.security.misc:1214
  2. Newsgroups: sci.crypt,alt.security,comp.security.misc
  3. Path: sparky!uunet!snorkelwacker.mit.edu!paperboy.osf.org!osf.org!karger
  4. From: karger@osf.org (Paul A. Karger)
  5. Subject: Re: Trusted Path
  6. Message-ID: <1992Sep9.141157.22089@osf.org>
  7. Sender: news@osf.org (USENET News System)
  8. Organization: Open Software Foundation
  9. References:  <920908214524.887195@DOCKMASTER.NCSC.MIL>
  10. Date: Wed, 9 Sep 1992 14:11:57 GMT
  11. Lines: 33
  12.  
  13. In article <920908214524.887195@DOCKMASTER.NCSC.MIL>, WHMurray@DOCKMASTER.NCSC.MIL writes:
  14. |> 
  15. |> Sorry Paul, trusted path as in the orange book relies upon a trusted
  16. |> terminal.  It does not protect against the kind of attack descirbed.
  17. |> Defense against that attack requires rue peer-to-peer authentication
  18. |> that is independent of the terminal and resistant to playbacks.
  19. |> 
  20. |> Regards, Bill
  21. |> ____________________________________________________________________
  22. |> William Hugh Murray                     203-966-4769
  23. |> Information System Security             203-326-1833 (CELLULAR)
  24. |> Consultant to Deloitte & Touche         ARPA: WHMurray@DOCKMASTER
  25. |>                                         MCI-Mail: 315-8580
  26. |>                                         TELEX: 6503158580
  27. |>                                         FAX: 203-966-8612
  28. |>                                         Compu-Serve: 75126,1722
  29. |> 49 Locust Avenue, Suite 104             PRODIGY: DXBM57A
  30. |> New Canaan, Connecticut 06840
  31. |> 
  32.  
  33. Bill Murray is absolutely correct here.  I vastly oversimplified the
  34. issue.  Trusted path is just part of what you need.  Thanks, Bill, for
  35. catching me on that!
  36.  
  37. What Bill is describing is a form of trusted path that runs over the 
  38. network and provides a trusted path from my smart ATM card back to the
  39. bank's computers.   The smart ATM card must authenticate itself to the
  40. bank's computers and the bank must authenticate itself to the smart
  41. card.  If the terminal is suspected of being hostile (either because
  42. the merchant has bugged the point of sale terminal or because a false-front
  43. ATM machine has been constructed out on the street), then the mutual
  44. authentication has to use encrypted communications in both directions.
  45. DEC's DSSA architecture is one way of doing this, and there are many others.
  46.