Download
no more alice to bob n.
Skip this Video
Loading SlideShow in 5 Seconds..
No More Alice to Bob PowerPoint Presentation
Download Presentation
No More Alice to Bob

No More Alice to Bob

334 Vues Download Presentation
Télécharger la présentation

No More Alice to Bob

- - - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript

  1. No More Alice to Bob Terence Spies VP Engin ering Voltage Security, Inc

  2. Overview • Is the Classic Encryption Model an appropriate way to think about building cryptosystems? • Usability research has produced results • What about IT staff? • What about developers? • No conclusive answers here

  3. Enterprise Security Case Study • Enterprise had built a huge new project to disrupt the competition • A series of compromises • An authentication failure at the enterprise edge • A successful Trojan horse attack • A successful database penetration in the DMZ • Finally, a devastating attack on the project through an obscure open port • The result • Total failure of the project • A catastrophic impact on the viability of the entire enterprise

  4. Case Study Continued Authentication Failures Enterprise CSO The Project Vision Discovery of the open port

  5. The State of Enterprise Security • Technology is improving rapidly • This helps defense, but also offense • Channels keep evolving • Processes get more automated (email, IM, WS) & anonymous • Old attacks start working in new channels • Lessons from Mr. Vader: make sure security investments match current attack trends

  6. Background • This is from a non-academic point of view • Based on experience with integrating crypto • MS Certificate Server • Voltage SecureMail • MS CryptoAPI • Primarily oriented towards commercial crypto • Oriented towards data security

  7. The Classic Encryption Model • Move data from Alice to Bob • Only Bob can open the data (confidentality) • Attackers are presumed to control the wire • Lots of other signature related properties • Non-repudiation • Data origin authentication • Theoretically independent • Name spaces and authentication complicate this • See, for example, RFC 3552

  8. The Classic Encryption Model • Seems to yield solid connection protocols • SSL, IPSEC, SSH • Seems to fail for data security • No pervasive model for protecting data • Real world data loss seems to fall in the second category. • Snooping is hard • Stealing (or losing) disks and tapes is easier

  9. CEM Flaws • Specifies the easy (in some respects) part of the problem • Protocols will look good in this model • And will fail badly in the real world Authentication and Systems Scary & Complex Alice and Bob Encryption Algorithms

  10. Is Encryption Worthwhile? • Customers have limited bandwidth • Encryption competes for attention with: • Anti-virus • Anti-spam • “Identity Management” • DoS protection • Anti-phishing • Intrusion detection • Smart cards and tokens • The attack of the month

  11. What do customers worry about? • Regulatory compliance • Billions spent on Sarbanes-Oxley and HIPAA • Measurable monetary risk • Loss of backup tapes has sensitized banks • That the cure is worse than the disease • Most have failed security projects • These failures tend to be expensive

  12. Regulatory Compliance • CA 1386 This bill, operative July 1, 2003, would require a state agency, or a person or business that conducts business in California, that owns or licenses computerized data that includes personal information, as defined, to disclose in specified ways, any breach of the security of the data, as defined, to any resident of California whose unencrypted personal information was, or is reasonably believed to have been, acquired by an unauthorized person. • Notice includes • Email, notification of statewide media, posting on website • Arkansas, North Dakota, Georgia, Montana and Washington • NY and US versions in the works

  13. Requirements - Fluid Usability • Systems must recognize that • Users roam among multiple machines • Installation of clients is often not possible • User access to data must be essentially unfettered • Example: we must support email through • A desktop client • Blackberries • Web access to email (Outlook Web Access)

  14. Interaction with the classic model • Not really sending from Alice to Bob • Really sending • from some machine Alice has authenticated to • to some machine Bob has authenticated to • Which may not be the same machine Bob was logged into five minutes ago • Or some service running as Bob • Or some delegate that reads and handles Bob’s mail

  15. Costs of Key Roaming • Key roaming and policy handling code • Easily 10x more complex than core CA code • Attempt to accommodate strict security model • Now administrator has policy decisions • Requires separation of sig and decrypt keys • This is good in principle • Does this really maintain non-repudiation?

  16. Requirements - Developer Usability • Extends to developers • Lots of developers are now aware • Integrating existing systems still too hard • Tried figuring out how to validate a cert? • CRLS, OCSP, etc • Cert expiration • Tried figuring out where to store a key? • It’s turtles all the way down • The user pays the ultimate cost

  17. How Expensive are Certificates? • GAO Dec 2003 Study on Federal PKI • 89 Federal PKI projects • Total cost to date: $1B • Total # of certificates: 3.5M • $287 per user • ACES program • Built to issue free certs to agencies • $3M to implement • 500,000 certs issued • 10,000 of those certs used Reference : www.gao.gov/cgi-bin/getrpt?GAO-04-157

  18. Requirements - Message Recovery • Mandated for all messages in financial industry • Legal discovery policies require this • Clipper gave this a bad name • However, this is often the #1 feature request • Disaster recovery and failure tolerance are critical

  19. Regulations • SEC17a-4 • Every such broker and dealer shall preserve for a period of not less than 3 years, the first two years in an accessible place: • Originals of all communications received and copies of all communications sent by such member, broker or dealer (including inter-office memoranda and communications) relating to his business as such. • Many brokers extend this to 7+ years • “Accessible” = easily searchable

  20. Brokerage Auth System Email Archival Brokerage Customer Email System Email Review Content Scan NASD 3010 Review CSR Plain Text Email AV / AS

  21. Requirements - Policy Control • Users are not trusted to know when to secure mail or documents • Especially for mail leaving the enterprise • Increasing collaboration and outsourcing complicates this • Has lead to products to control info flow • Vontu • Reconnex

  22. Requirements - Scalability • Process 1M+ outgoing messages a day • Users in 34 countries • 16 data centers • Passive standby data centers • Innumerable existing management systems • Existing business logic that cannot change • Branding! • Delegated administration

  23. What can be fixed • Alice and Bob ALWAYS need an authority • Which may be one of them • Probably an authority each (“federation”) • Alice and Bob most always need recovery • And maybe on both sides • Example: Bank A to Bank B • Both need access

  24. Other potential models • Access Control Model • Borrow properties from file system • Sender and intermediary control naming • Recipient petitions for access • Connection-only Model • Give up data security • Focus on hardening the platform

  25. Conclusion? • It seems that lots of complexity is neglected • It exists on the edge of crypto and systems • Military and person-to-person history • Emphasis on raw bit strength • Clearly room for both pure and corporate systems • Lots of good research problems hidden here