PKI Buy vs. Build Decision at UW-Madison

1
PKI Buy vs. Build Decision at UW-Madison

• Presented by Nicholas Davis
• PKI Project Leader
• UWMadison, Division of Information Technology

2
Overview

• Brief history of PKI at UW-Madison
• UW-Madison IT environment
• PKI requirements gathering effort
• Comparison of benefits of buy vs. build in our
  environment
• Our experience so far
• Integration with existing systems
• Critical success factors
• Future considerations
• What we have learned

3
History of PKI at UW-Madison

• October 2000 Internet2 Public Key Infrastructure
  Lab established at UW-Madison.
• 2002 Provided certificates to Shibboleth testing
  community
• 2004 Campus requirements gathering initiative
• Spring 2005 RFI review
• August 2005 Geotrust selected

4
UW-Madison IT Environment

• Serving a universe of 50,000
• Faculty, Staff, Students
• Highly decentralized
• Public institution
• Research driven environment

5
Why the UW-Madison is interested in PKI

• Threat of identity theft (strong 2-factor
  authentication)
• More university businesses conducted via web /
  extranets through open community, across
  organizations
• Privacy of information (encryption)
• Authenticated communication (signing)

6
UW-Madison Critical Solution Attributes

• Ease of management
• Ready integration into existing systems
• Ease of adoption by end users
• Scalability, flexibility, cost of ownership,
  accreditations

7
Core Requirements

• Automated certificate delivery
• Used for encryption, digital signing and
  potentially authentication
• Off site key escrow
• Transparency to end user
• Global trust
• Implementation within 6 months
• Minimum lock in commitment
• Time, Cost, Features, Quality

8
PKI Models and Systems Under Consideration

• In House (Commercial and Open Source)
• Co-managed
• Verisign -- Commercial -- Co-managed
• Entrust -- Commercial -- In house
• Geotrust -- Commercial -- Co-managed
• RSA -- Commercial -- In house
• Open Source -- Non-Commercial -- In House

9
Time to ImplementIn House Open Source

• To develop our desired feature set would require
  2 full time programmers for 12 months
• Cost of establishing sandbox, QA and production
  environments
• Hardware acquisition secure cage, network
  equipment, Certificate Authority, Registration
  Authority
• CP and CPS statements would need to be written
  and reviewed by DoIT management and UW Legal
• Estimated time to implement 12 months

10
Time to ImplementIn house Commercial

• 1 FTE would be needed to act as Administrator
• Need to establish sandbox, and QA environments.
• Design logical and physical security
  infrastructure for secure CA and offsite key
  escrow
• Purchase hardware, install software
• Develop policy, CP and CPS
• Estimated time to implement 9 months

11
Time to implementCo-managed

• 1 FTE would be needed to act as Administrator
• Upon completion of purchase contract, system
  would be immediately ready
• No need to establish sandbox, and QA
  environments.
• Estimated time to implement 4 weeks

12
Building Open SourceCosts

• Year 1 system costs
• 5000 users 50,000
• 2 FTE (salary and benefits) 200,000
• Total Year 1 costs 250,000
• Year 2 and beyond (annual costs)
• 5000 users 0
• 2 FTE (salary and benefits) 200,000
• Total annual costs 200,000
• 10 year cost 2,050,000

13
Building CommercialCosts

• Year 1 system costs
• 5000 users 200,000
• 1 FTE (salary and benefits) 100,000
• Total Year 1 costs 300,000
• Year 2 and beyond (40,000 maint.)
• 5000 users 0
• 1 FTE (salary and benefits) 100,000
• Upgrades and maintenance 5000
• Total annual costs 145,000
• 10 year cost 1,605,000

14
Co-managed Costs

• Year 1 System costs
• 5000 users 43,000
• 1 FTE (salary and benefits) 100,000
• Total yearly costs 143,000
• Year 2 and beyond (annual contract)
• 5000 users 43,000
• 1 FTE (salary and benefits) 100,000
• Total annual cost 143,000
• 10 year cost 1,430,000

15
Annual Cost Summary

• 1 year
• 10 year
• There is no free lunch, even with open source
• The price of entry for infrastructure can be cost
  prohibitive and a major sticking point for
  organizational commitment

16
Feature Set No Trusted Root With Open Source

• Unsigned Root means distrust both within
• and outside our core universe
• Who are you serving? Internal customers?
• External customers? Both?

17
Benefits of co-managed solution

• Seamless trust lets us play globally via
• The Equifax Secure eBusiness CA1
• Logistical, financial and political issues with
• Building true off site key escrow
• Keys are securely kept offsite

18
Benefits of co-managed solution (continued)

• All the user needs is a web browser in order
• to get theircertificate
• Quality co-managed PKI systems are
• constantly monitored, patched, upgraded
• and backed up at a remote location

19
Our experience so far

• Customers appreciate
• Automated certificate delivery
• Trusted Root
• Key Escrow
• Uses
• Using certificates for digital signing
• Using certificates for encrypted email
• Digital signing of mass email to campus

20
Integration With Existing Systems

• Easily scalable Load users in CSV format in
  batch
• Public keys are exportable to LDAP and University
  White Pages
• CRL is automated via True Credentials system
• Third party software available for high assurance
  server authentication

21
Critical Success Factors

• A focus on the customer requirements is of
  pinnacle importance
• Financial lifecycle modeling for both short and
  long term
• Being careful not to reinvent the wheel simply
  for the sake of pride
• Top down support from the CIOs office

22
Summary of Benefits

• Lower upfront fixed costs
• Lower 10 year costs
• Faster road to implementation
• Trusted Root
• Off Site Key Escrow
• Automated certificate delivery
• UW-Madison common look and feel
• No long term lock in

23
Future Considerations

• The beneficial cost argument may change if our
  user population grows dramatically
• Widespread adoption of the Higher Education
  Bridge CA (HEBCA) may alter our reliance on a
  commercial pre-installed root

24
What We Have Learned

• Dont let your pride dictate your choice of PKI
  model
• Focus effort on things which have not already
  been done and on providing utility to the end
  user, not on where your CA hardware is located
• A certificate is a certificate

25
What We Have Learned(continued)

• The key to success in a decentralized environment
  lies in motivating your users, not obligating
  your users
• Whether you choose to build or buy, remember to
  keep it simple for the customers
• Dont spend time on duplication of effort

26
What We Have Learned(continued)

• What matters most is what your organization does
  with the certificate once it is issued
• The challenge of implementing PKI is 30
  technical and 70 user education, marketing and
  acceptance

27
Questions, Comments

• Contact information
• Nicholas Davis
• University of WisconsinMadison
• Division of Information Technology
• Email ndavis1_at_wisc.edu
• Telephone [phone]