1 / 39

Public-Key Infrastructure for Higher Education

Public-Key Infrastructure for Higher Education. Mark Luker EDUCAUSE. EDUCAUSE is. An association of over 1,800 colleges, universities, and corporate partners professional education and best practice Net@EDU for advanced networking NLII for distributed learning Government and campus policy

bree
Télécharger la présentation

Public-Key Infrastructure for Higher Education

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. Public-Key Infrastructure for Higher Education Mark LukerEDUCAUSE

  2. EDUCAUSE is ... • An association of over 1,800 colleges, universities, and corporate partners • professional education and best practice • Net@EDU for advanced networking • NLII for distributed learning • Government and campus policy • Partner with I2 and SURA on NMI

  3. What’s new in technology? • affordable “human” interactions • affordable digital content • affordable networked communications • This changes everything!

  4. What is different this time? • Convergence to common digital forms • incredible reduction in unit costs • incredible resource sharing • speeds both innovation and production • Global sharing of opportunities • technology, information, human

  5. Why critical for higher ed? • Our stock is in knowledge and information • Our core activities focus on learning, research, analysis, dissemination, preservation … • All can be improved through better, cheaper, broader, faster communications • Irrational exuberance?

  6. Major barrier to success • Low level of “trust” on the Internet • Who are you really dealing with? • How do you know? • Is this signed document authentic? • Can you prove it? • Can the Internet support our core business?

  7. Fact… Networked applications require an environment of rules and law: • Official and personal transactions • Shared resources and collaboration • Distributed systems and information • B2B and web services • Networked organization • Distributed learning • Networked research

  8. Aspects of trusted communications • Authentication • Data integrity • Confidentiality • Non-repudiation • Authorization

  9. All a matter of degree • Assurance of products and services • Liabilities and regulations • Balance costs and risks • Physical and network security • Policies and procedures • Penalty of regulations and law • Insurance and indemnification • Traditional business models

  10. Passwords fail the test • Either hard to remember or easy to guess • Difficult and expensive to manage • Towers of Babel • Lock you into online transactions • Low level of trust

  11. PKI - the only known solution • Issue a unique, digital “cert” to each person • Guard and manage it with high security • Use it automatically to prove identity • Can support digital signatures • Provides all five types of trust • For both transactions and documents • Fits normal business models

  12. What is needed in a PKI? • A registration authority (RA) that performs the physical identity checks • A Certificate Authority (or CA) that issues, manages, and vouches for the certs • An “authoritative” directory of roles • Standards, policies, training, oversight

  13. What else is needed? • “PKI Aware” applications that automatically use the certs and the directory • Browsers, email, online transactions • Digital signatures • Business rules for trusted communications • Re-engineer business workflow

  14. The ROI? (Wrong term?) • Costs similar to ERP • Big bucks for full implementation • Hardware and software only a small part • A long-term, ongoing investment • Rewards even larger than ERP • Efficiency • A basic necessity for e-education

  15. Mathematical underpinnings • Asymmetric or Public Key cryptography • Encode and decode messages using a common algorithm with pairs of “keys” • Only you have your private key • Everyone else has your public key • Either key can encode a message • Only the other key can then decode it • It is “impossible” to determine your private key from your public key

  16. Confidentiality • To send a confidential message to Mary • Encode message with Mary’s public key • She decodes it with her private key • To save a confidential copy of a message • Encode message with your own public key • Decodes it later with your private key • What if you lose your private key? • Key escrow - a system to recover lost keys • Once a big policy flap with the feds

  17. Non-repudiation • Send a message “guaranteed to be from you” • Send the message coded with your private key • Mary decodes it with your public key • If this works, it is really from you • Also called technical non-repudiation: • No one else could have sent the message • ASSUMING no one else has your private key

  18. Integrity • Send a signed document to Mary • Compute a “1-way hash” of the message • Encode the hash using your private key • Send message + coded hash to Mary • Mary decodes hash with your public key • She recomputes the hash from the message and compares with the decoded hash • If they match, it guarantees integrity • Can do all combinations with Digital Signatures

  19. What for? Authorization • Provide controlled access to resources • Use certificate to determine identity • Check for appropriate authorization using access lists, class membership rules, etc. • Store attributes in a directory • Problems? • Need expiration dates and revocation lists • Must be alert to privacy concerns • Need high quality, secure directory!

  20. Assumptions • You and only you have your private key • Never escrow your private signing key • Must use two pairs of keys • Must revoke obsolete or lost keys • Keys are easy to use • PKI-enabled applications • Everyone has access to your public key • And they can trust that it is really yours

  21. Challenges • Must prevent brute force attacks • Key size, algorithms, management, guard dogs • Where to keep your private key? • Your head? your hard drive? the network? • Smart cards, biometrics • How to publish your public key and guarantee it is yours?

  22. How to share public keys? • Can share one-to-one, but does not scale • How can a published key be trusted? • Breakthrough • Send the public key in a Certificate signed by a trusted, third party • This Certificate Authority or CA vouches for the identity and public key of the sender • We recognize and trust the CA due to its process, rules, reputation, and liability

  23. Managing trust in communities • Can’t have just one CA for the entire world • Hierarchical models have a rootCA that determines overall policy requirements • System, Campuses, Colleges • State, System, … • VeriSign, Campuses, … • Trust partners in a common framework • Trust, risk, and liability • Works like a family tree • Must validate certs through chains of trust

  24. Early projects • University of Texas system • University of California system • University of Pittsburgh • CREN early adopters • Digital library federation • Federal agencies – especially Defense • Automotive Network Exchange • American Bankers Association • Health Key

  25. Stepping up to the next level • Need to work with certs across communities • Difficult and expensive to manage separate certs for separate applications • Risk PKI Tower of Babel • Would like to use your “main” identity in most transactions • Need to validate certs from other root CAs

  26. Collaboration between root CAs • Establish trust through “sufficient” commonality of process and policy • A job for lawyers and managers • Enforced by technology, management, contract • Cross-certify peer CAs • Trust each other, vouch for it • Examine detailed policy documents • Sign certificates for each other’s public keys

  27. Implementing trust between CAs • The number of pairwise agreements between N CAs is about N squared / 2 • Pairwise trust between 1,000 root campus CAs requires the work of 1 million lawyers • Try to use a small number of root CAs • Breakthrough • Use a common “bridge CA” in the middle • Translate trust between N kinds of certificates • Requires only 2 x N lawyers

  28. The bridge solution • Translates certs and levels of trust from one PKI to another • Provides online verification that a cert issued by another system is valid • Provides interoperability across vendors • (Solves the N-squared problem of trust)

  29. Federal Bridge • FBCA connects CAs for federal agencies • Recognizes de facto autonomy • Supports common vendors • Authority of Federal CIO Council • 150-page detailed policy statement • New implementation by MitreTek • Online now

  30. Higher Education Bridge • HEBCA proposed for higher ed CAs • Recognizes actual autonomy • Supports common vendors • Authority of ??? • Mimic federal policy statement • Prototype implementation by MitreTek • Online for testing now • Cross-certify to the federal bridge!

  31. Example • Campuses join some hierarchical CA • Can interoperate through HEBCA • Big bonus • Can interoperate through FBCA with feds • NSF, NIH, VA, INS, DOD, Ed, HHS, … • Trial projects • Campus – HBCA – FBCA – NIH • Campus - FSA

  32. EDUCAUSE / NIH pilot • Build bridges for Federal Government and Higher Education • Hook them together (with trust!) • Demonstrate that this model could support trusted communications between any campus and federal agency • Won the Pioneer “Best of the Best” award

  33. HEBCA E-Lock Assured Office Digital Signed Grant App. Certificate Validation UA-B NIH Mail Server University of Alabama- Birmingham FBCA Internet Certificate Validation UW-M E-Lock Assured Office Digital Signed Grant App. University of Wisconsin- Madison Middleware: CAM with DAVE Certificate Validation Dart. C NIH Recipient E-Lock Assured Office Digital Signed Grant App. E-Lock Assured Office Digital Signed Grant App. Dartmouth College E-Lock Assured Office CAM-enabled A Picture is Worth Five Slides

  34. Advantages of the bridge approach • Campuses and agencies can use their own PKI vendors, identification, and signatures. • They do not have to create new certificates or passwords for each new application. • They have a standard way to check credentials received from one another. • Could be used for trusted correspondence between higher education and NIH, NSF, NASA, FSA, INS, IRS, VA, DoD, ….

  35. Role of EDUCAUSE • Implement the bridge for higher education • Interoperate with vendors and feds • Alliance with ACE for authority • Collaborate with Internet2 on technology • Focus in Net@EDU working group on PKI • Arranging trials with MitreTek, Feds, NIH, and several campuses

  36. People Glue It All Together • Clair Goldsmith, University of Alabama-Birmingham • Jill Gemmill, University of Alabama-Birmingham • Keith Hazelton, University of Wisconsin-Madison • Eric Norman, University of Wisconsin-Madison • Bob Brentrup, Dartmouth College • Ed Feustel, Dartmouth College • Michael Gettes, Georgetown University; Internet2 • David Wasley, University of California Office of the President • Bill Weems, University of Texas – Houston Health Science Center

  37. D. Wasley’s PKI Puzzle

  38. Campus next steps for PKI • Understand PKI as an institution • Implement initial components • CA services, directory, enabled applications • Policies, practices, contracts, business models • Stay within the emerging framework • The payoff • Efficiency and power of networked operations • Requisite capabilities for e-education

  39. Whew! • Will it work? • Are there alternatives? • See • www.educause.edu/netatedu on PKI • NMI, I2, SURA, HEPKI • www.cio.gov/fbca, etc. • PKI by Tom Austin, Wiley Tech Brief, 2001

More Related