PKI Cross Certification

1
PKI Cross Certification

• CANHEIT 2005
• John Sherwood

2
Agenda

• Review of encryption, PKI, and Certificate
  Authorities and why we care
• Recent work in the US as part of Internet2 and
  EDUCAUSE
• Possibilities for the future in Canada

3
Asymmetric Key Encryption

• Public Key encryption relies upon two related
  keys
• Public key is used to encrypt a message
• Private (secret) key is used to decrypt
• Private key cannot be practically determined from
  public key
• Role of keys can be reversed
• Problems
• You must know (and keep secret) your private key
• You must be able to learn other peoples public
  key

4
Common Public Key Usage

• Encrypt a message so that only the intended
  recipient can decrypt it (email, file on disk,
  SSL (TLS) web page)
• Digitally sign a message so the sender is
  securely identified and the contents are tamper
  evident
• Identity management
• TLS server
• Individuals (e.g. to replace SecurID)

5
Example - Digital Signature

• Alice uses hash (e.g. SHA-1) algorithm to
  generate a message digest
• Alice uses her private key to encrypt digest,
  appends it to the original cleartext message, and
  send both to Bob
• Bob finds and verifies Alices public key
  (actually it is in the signature), uses it to
  decrypt digest, and compares it to locally
  generated digest
• If they compare, Bob knows that the message was
  not modified and that he has the public key that
  was used to sign the message
• Bob has to verify that Alice owns the public key
  so he can be sure that Alice sent the message

6
The Trust Problem

• In previous slide we introduced the problem of
  verifying that a public key belongs to a
  particular person (or server)
• Bob can trust he has the correct key for Alice
  by
• Meeting Alice and accepting her key from her e.g.
  on a floppy (but does Bob even know what Alice
  looks like?)
• Getting her alleged key from a signature,
  directory, etc. and accepting a trusted third
  partys guarantee that the key is legitimate
• Third party guarantees are the tough part, and
  are what drive Public Key Infrastructure (PKI)

7
Chain of Trust

• Public keys are usually distributed through
  certificates issued by a trusted party
• A persons public key certificate has several
  parts
• Serial number assigned by issuer
• Identity of issuer and user
• Beginning and end dates of validity
• Uses (e.g. signing email)
• Users public key
• Digital signature of issuer (who is also the
  guarantor)
• Certificates public keys may become invalid
  before expiring
• Staff leave, key is compromised, etc.
• Issuers should maintain list of revoked
  certificates called Certificate Revocation List
  (CRL)

8
(No Transcript)
9
Who to Ultimately Trust?

• Certificates, maintained by Certificate
  Authorities (CA), involve a chain of trust,
  leading to a head of the chain (root)
• Major browsers are delivered with a list of
  trusted roots
• Certificates ultimately signed by a trusted
  issuer or root are also trusted

10
(No Transcript)
11
Root Certificates

• Advantage of a well-known root certificate is
  that browsers other encryption accept other
  certificates they have signed
• Lots of commercial certificates are available,
  but they are expensive
• Root certificates are pre-installed in major
  browsers, but only in exchange for
• Costs limit use of secure web sites and signed
  email
• What can we do?

12
Typical Costs for Server Certificate-per year,
single quantity-
13
Cross Certifying

• It is possible for issuers to establish trust
  between them
• Universities A, B, C and D can sign each others
  certificates and so establish a web of trust
• Alternatively there can be a single entity
  (bridge) in the middle with which each
  university establishes trust

14
Hierarchical Trust
root CA
Institution CA
Institution CA
Institution CA
Institution CA
Department
Department
Department
Department
15
Mesh Trust
Department
Department
Institution CA
Institution CA
Institution CA
Institution CA
Department
Department
16
Bridged Trust
Department
Department
Institution CA
Institution CA
Bridge CA
Institution CA
Institution CA
Department
Department
17
U.S. Progress

• CREN higher-ed root CA
• USHER (US Higher Ed Root)
• HEBCA (Higher Ed Bridge Certificate Authority)

18
CRENThe Corporation for Research and
Educational Networking

• CREN was a non-profit that supported higher-ed
  networking
• Established in 1984 as a merger of BITNET and
  CSnet
• Services included
• BITNET (eventually replaced by Internet)
• ListProc Unix alternative to LISTSERV
• TechTalks
• Digital Certificates root CA for higher ed

http//www.cren.net/
19
CREN Root CA Opening
November 17, 1999
20
CREN root CA

• One browser incorporated CREN CA (Opera)
• Approx 17 universities installed CREN root
• CREN dissolved on January 7, 2003
• When last sighted the CA was reportedly living in
  Jeff Schillers office at MIT

21
USHER

• After CREN dissolved no new certificates were
  issued
• Someone had to maintain the root
• Internet2 offered and USHER was born

http//middleware.internet2.edu/hepki-tag/ http//
www.educause.edu/HigherEducationPKI/931
22
HEBCA

• HEBCA will bridge root CAs from participating
  institutions
• HEBCA will cross-certify with US Federal Bridge
• CA is off-line and uses air gap security
• Policy Authority is in place (Larry Levine is
  Chair)
• HEBCA may be operational by September

23
Dartmouth College PKI Lab

• Has contract to house HEBCA, and probably USHER
• Educause and Internet2 have agreed to cooperate
  as much as possible
• Both will probably run as different instances on
  the same hardware
• Each has its own Certificate Practices Statement
• Why have both?
• USHER concept works today
• HEBCA is more elegant, but not all clients
  support bridges

24
Challenges

• CA is off-line and uses air gap security
• difficult to publish CRL every 6 hours!
• Only US citizens are authorized to work on HEBCA
• Not all clients understand concept of a bridge

25
What Are Our Options?

• Buy commercial certificates
• s
• Everyone do their own thing
• Loose some portability
• Unmanaged policies practices
• Cooperate with US on USHER or HEBCA
• Appealing, but difficult for them to include
  foreigners
• Set up a Canadian version of US projects
• Challenging

26
http//www.educause.edu/PKI05
27

http//pstnet.unb.ca/pst2005
28
-end-