Public-Key Infrastructure for Higher Education

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