1 / 25

Securing Transactions: Protocols and Politics

b. b. b. b. Securing Transactions: Protocols and Politics. D. Crocker Brandenberg Consulting +1 408 246 8253 dcrocker@brandenburg.com. Brandenburg Consulting. Product & service / planning & design Technical Large-scale systems Internet & interoperability Operations Security

Download Presentation

Securing Transactions: Protocols and Politics

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. b b b b Securing Transactions: Protocols and Politics D. Crocker Brandenberg Consulting +1 408 246 8253 dcrocker@brandenburg.com

  2. Brandenburg Consulting • Product & service / planning & design • Technical • Large-scale systems • Internet & interoperability • Operations • Security • Protocols (email, transport, commerce) • Internet development since 1972 • Chair, Silicon Valley - Public Access Link

  3. Secure transactions • Doing business on the Internet • Object- vs. Transport- security • Payment protocols • Standards work

  4. Internet for commerce? • Strong pressures emerging • Businesses now online • Reduced access costs • Global “reach”

  5. A global Internet • Scaling • A chicken in every pot! • Security • Military vs. commercial vs. personal • Management • Interconnection ¹ interoperability • Sometimes ¹ always

  6. Styles of use • Receiver pull • Interactive sessions • Individual, foreground refinement • Sender push • Messaging • Bulk, background distribution (Mark Smith, Intel)

  7. Full(core) Permanent, visible, native Direct(consumer) Native Client User runs Internet applications Mediated Provider runs applications for user Messaging Surprisingly useful To be on the Internet

  8. R&D Search, browse Test Coordinate Support Discuss Info push Marketing Targeted info push Survey Sales Negotiate Order, bill, pay Deliver What is business?

  9. Where to put functions? • Core vs. edges • Place it in the core • Can’t be used until all of the pieces between users adopt it • Place it at the edges • Useful as soon as adopted by two, consenting hosts

  10. Where to put security... My object Object Transport Secure Web Security EMail Security My object Web Server MTA EMail Web FTP Web Server MTA EMail Secure Secure My object My object My object My object

  11. Transport security IPSEC IP-level labeling Kerberos (MIT) Third-party service S-KEY (Bellcore) Pairwise login S-HTTP (EIT) Negotiate specifical object wrapper security SSL (Netscape) Client-server transport link STT (Microsoft) (TBD)

  12. Object security • MOSS (was: PEM) • MIME Object Security Service - IETF • RSA + DES • Global, formal key certification hierarchy • PGP • Pretty Good Privacy - Phil Zimmerman • RSA + IDEA • Informal, personal, direct certification • S/MIME • Secure MIME - RSA & Consortium

  13. Basic algorithms Integrity Authentication (sign) Msg Hash Msg Hash Digital Signature Msg Msg KeyPRIV-ORIG + + + Ÿ Privacy (seal) Encrypt Data Encrypt Key Msg +KeyDATA + KeyDATA KeyPUB-RECIP Ÿ + Ÿ • When do you need each? ...not always!

  14. EDI over Internet • Multiple EDI transports already • Internet is one more • EDI/MIME, proposed standard • Regular EDI objects, encapsulated in MIME • Use MIME-based security

  15. Payment system model Clearing House Buyer Issuing Bank 16+4 Acquiring Bank Merchant (M. Rose, FV )

  16. Payment system issues • Transaction category “card not present” • For all bankcard approaches for Internet • Issues • Knowing buyer/merchant authorized • Avoiding third-party interception • Interchange, assessment, fees • Retrievals, chargebacks, etc. • Risk management

  17. Payment system efforts Commercenet www.commerce.net First Virtual Holdings www.fv.com CyberCash www.cybercash.com Open Market www.openmarket.com NetMarket www.netmarket.com Netscape www.netscape.com DigiCash www.digicash.com

  18. Scheme “Clear” Just trust the net... Easy to capture and replay. Buyer 16+4 in the clear! Clearing House Merchant

  19. Scheme “ID” Still trust the net, until the next statement... Easy to capture and replay. Buyer 16+4 ID Clearing House ID Merchant 16+4

  20. Scheme “ID confirm” 16+4 Buyer ID Clearing House ID Confirm Merchant ID Each transaction confirmed. Requires mildly safe user account.

  21. Scheme “Secure link” Same a telephone, but encrypt over Internet. Merchant gets number. Is merchant safe?? Buyer Encrypted 16+4 Clearing House Merchant 16+4

  22. Scheme “Mediated” Only banks sees data in clear. Limited points of attack. Buyer Encrypted 16+4 Clearing House Encrypted 16+4 Merchant

  23. Open IP labeling Session Security S-HTTP (sort of) MOSS Proprietary SSL STT PGP (sort of) S/MIME The standards debate

  24. Freezing out competition • Non-interoperability • Do it because it’s mine! • Customer lock-in through proprietary extensions • Half-hearted integration • Specialized protocols for each and every need

  25. Is there hope? • Vendor initiatives • Market lead • Folded into public standards • Open access • Open enhancement It all depends on market demand. You are the market; start demanding!

More Related