Public key infrastructure
1 / 34

Public Key Infrastructure - PowerPoint PPT Presentation

  • Updated On :

Public Key Infrastructure. Levi Broderick April 18, 2006. 05-899 / 17-500 – USABLE PRIVACY & SECURITY – CRANOR, HONG, REITER. The need for PKI. Meet Alice. She has a secret that she wants to send to Bob. Meet Bob. He looks forward to talking with his good friend Alice. The need for PKI.

I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
Download Presentation

PowerPoint Slideshow about 'Public Key Infrastructure' - lena

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.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.

- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
Public key infrastructure l.jpg

Public Key Infrastructure

Levi Broderick

April 18, 2006


The need for pki l.jpg
The need for PKI

Meet Alice. She has a secret that she wants to send to Bob.

Meet Bob. He looks forward to talking with his good friend Alice.

The need for pki3 l.jpg
The need for PKI

  • Alice and Bob can use a secret key (symmetric cryptography) to communicate over the public channel.

  • They must have agreed on this key in advance.


The need for pki4 l.jpg
The need for PKI


  • But what if Alice and Bob had never spoken before? Can Alice still send him a secure communication?

  • This is the primary focus of PKI.


Communication under pki l.jpg
Communication under PKI

  • Both Alice and Bob have their own individual private and public keys signed by a certificate authority.

    • The CA might be an employer, Verisign, or some other organization.

Communication under pki6 l.jpg
Communication under PKI

  • All communicating parties must have each others’ public keys.

  • Public keys must have a common ancestor to be considered valid.

    • Alternatively, some PKI implementations (Lotus Notes, Groove Virtual Office, etc.) allow CAs outside the local network to be individually trusted.

Communication under pki7 l.jpg
Communication under PKI

  • Peter and Ulysses can communicate since they share Mary Jane as an ancestor.

  • Jill and Sheryl can communicate since they share a root element.

Communication under pki8 l.jpg
Communication under PKI

Bob’s public key

Alice’s public key


  • The public key is used for encryption and digital signature verification.

  • The private key is used for decryption and the creation of digital signatures.

X 509 certificates l.jpg
X.509 certificates

  • ITU-T standard for PKI

    • V3 described in RFC 3280

  • Certificate authority issues binding certificate between public key and name (URI, email, etc.)

  • Includes validation and revocation policy

    • Certificate Revocation List (CRL)

    • Online Certificate Status Protocol (OCSP)

X 509 certificates10 l.jpg
X.509 certificates

  • V3 certificate includes:

    • Issuing agency information

    • Subject information

    • Period of validity

    • . . .

    • Cryptographic signature

  • For root CAs, the issuing agency and the subject of the certificate are the same.

X 509 certificates11 l.jpg

X.509 certificates






X 509 hierarchy l.jpg
X.509 hierarchy



  • And a demonstration . . .

Non repudiation l.jpg

  • Non-repudiation and repudiation of signatures involved in legal practice for untold generations.

  • Traditional paper signatures may be repudiated:

    • False signature

    • Real signature, but extenuating circumstances

      • Unconscionable conduct / inequality of bargaining power

      • Fraud

      • Undue influence, or signature made under duress


Non repudiation14 l.jpg

  • Increasing legislation to allow digital signatures to serve as legally binding.

  • Non-repudiation as applied to digital signatures:

    • Provides proof of the integrity and origin of data, both unforgeable, which can be verified by any third party at any time.

    • An authentication that with high assurance can be asserted to be genuine and that cannot subsequently be refuted.

  • Thoughts? Comments?


Non repudiation15 l.jpg

Carl Ellison speaks out:

  • It is not achievable.

    • The private key provided the signature, not the human.

    • No provable link exists between the person and the computer.

  • It is counter to consumer protection law.

    • Transfers liability from the merchant to the consumer.

    • Corollary: E-commerce will suffer since repudiation guaranteed by creditors becomes nonexistent.


Non repudiation16 l.jpg

Carl Ellison continues to speak out:

  • It circumvents contract practice and law.

    • When does the user ever publicly acknowledge that he stands behind the signatures created with the private key?

  • It conflicts with good key management.

    • If there exists no audit log, the user is likely to discover a compromised key when another party in a transaction reveals use of the key and demands further action.


X 509 certificate revocation l.jpg
X.509 certificate revocation

  • Sometimes a certificate needs to be invalidated before its natural expiration date

    • Private key compromised

    • Employee fired from company issuing certificate

  • Two main ways to revoke an X.509 certificate:

    • Certificate Revocation List (CRL)

    • Online Certificate Status Protocol (OCSP)

Slide18 l.jpg

  • Requires database of all invalidated, unexpired certificates.

    • Verifier queries this database whenever he wants to see whether a certificate has been revoked.

  • Two models

    • Pull model: Verifier downloads CRL from CA as needed.

    • Push model: CA sends CRL to verifiers at regular intervals.

  • Problems?


Slide19 l.jpg

  • Problems similar to blacklists with credit card companies

    • Database is periodically pruned, but still very large

    • Time delay between certificate being revoked and revocation being published in CRL

  • Widely-used CRLs have too many verifiers to be able to effectively use the “push” method.

  • Susceptible to DOS attacks

    • Is the software default to accept or reject the certificate?

Sources: 18-730 (Reiter),

Slide20 l.jpg

  • RFC 2560

  • Request / response protocol

    • Verifier receives up-to-the-minute status info

  • Status list parsed server-side

    • Responder only sends back relevant info, reducing traffic

    • Responder may require requests to be signed

      • Allows for billing mechanisms to be put into place

  • Still vulnerable to DOS attacks


Encrypting email with pki l.jpg
Encrypting email with PKI

  • Lotus Notes/Domino makes it easy to encrypt messages because of its use of PKI.

Encrypting email with pki22 l.jpg
Encrypting email with PKI

  • If the key exists locally, encrypt and send the message.

  • If not, contact LDAP server and download key.

Encrypting email with pki23 l.jpg
Encrypting email with PKI

  • If key is signed by the CA, not revoked, and owner is correct:

    • Save to local keyring

    • Encrypt message and send

  • If incorrect owner, revoked, or unsigned, error out.

Encrypting email with pki24 l.jpg
Encrypting email with PKI

  • Behind-the-scenes look & demonstration . . .

Problems with pki l.jpg
Problems with PKI

  • System was originally envisioned as encompassing entire globe.

    • Would require one root CA or a specific and unchanging list for each government.

    • Governments are fickle and don’t like to trust each other.

  • Additionally, Balfanz, Durfee, and Smetters identify four usability problems with PKI.

Problems with pki26 l.jpg
Problems with PKI

  • Public-key cryptography is counterintuitive.

    • What on earth are public and private keys? What is a certificate?

  • PKI seems too far removed from application goals.

    • Users do not understand how their tasks require PKI.

  • PKI tasks are too cumbersome.

  • Large CAs run into naming collisions.

    • Users shoulder the burden of ensuring that the person they’re looking up is indeed the person they want.

Source:Security and Usability, ch. 16.

Spki simple pki l.jpg
SPKI (Simple PKI)

  • Similar to X.509, but names are local rather than global.

  • Certificates are used to bind authorizations rather than identities to public keys.

  • Possible uses (from RFC 2692):

    • Grants permission to write electronic checks.

    • Digital marriage license / divorce decree.

    • DC Metro farecard

    • Proof of degree earned (M.D., Ph.D., etc.)

    • Permission to issue nuclear launch codes

  • Thoughts?


Pgp s web of trust l.jpg
PGP’s Web of Trust

  • Public / private keys with an attached name, email address, and optional photo.

  • No centralized CA to sign keys.

    • PGP users sign keys when they’ve verified the owner’s identity, so in essence each PGP user is acting as a CA.

    • Your trust of a public key is related to how many signing “hops” you are away from that key and how much you trust each signer along the route.

  • Decentralized key distribution – users send keys.

    • Key servers have popped up to fill the role of the CA in key distribution.

Pgp s web of trust31 l.jpg
PGP’s Web of Trust

  • Makes key management issues very apparent

    • Web of trust depends on end users verifying and signing large quantities of keys.

  • Does a user understand what type of commitment he makes by signing a key?

  • Just how much trust is placed in a key 3 hops away? What about 4 hops?

    • Trust disappears after a default of 2 hops, maximum 8 hops (PGP 9.0).

  • Thoughts?

Robot cas l.jpg
Robot CAs

  • Public / private keys without a central CA.

  • Robot is a trusted, neutral third party whose signatures provide some validation for email addresses:

    • User uploads public key to robot CA.

    • Robot signs key and sends encrypted signature to email address present in public key.

    • Recipient decrypts message to retrieve signed key, then redistributed public key with robot’s signature attached.

  • Effectively invalidates signatures on keys not belonging to the email addresses listed for them.


Robot cas33 l.jpg
Robot CAs

  • Attempts to solve some of the key management issues in PGP:

    • If key verifier’s software automatically places trust in the robot’s signature, then keys can be downloaded from a key server automatically by the email client.

    • Burden is on the key creator to get the key signed by robot.

  • Process can probably be automated even at the creation end with the right software.

  • Thoughts?

The fun part l.jpg
The fun part!

  • Groove Virtual Office demo . . .