Public key infrastructure l.jpg
This presentation is the property of its rightful owner.
Sponsored Links
1 / 34

Public Key Infrastructure PowerPoint PPT Presentation


  • 222 Views
  • Uploaded on
  • Presentation posted in: General

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.

Download Presentation

Public Key Infrastructure

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

05-899 / 17-500 – USABLE PRIVACY & SECURITY – CRANOR, HONG, REITER


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.

100110


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

100110

  • 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

amazon.com

X.509 certificates

X.509

certificate

name

public

key


X 509 hierarchy l.jpg

X.509 hierarchy

issuer

subject

  • And a demonstration . . .


Non repudiation l.jpg

Non-repudiation

  • 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

Source: http://firstmonday.org/issues/issue5_8/mccullagh/index.html


Non repudiation14 l.jpg

Non-repudiation

  • 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?

Source: http://firstmonday.org/issues/issue5_8/mccullagh/index.html


Non repudiation15 l.jpg

Non-repudiation

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.

Source: http://world.std.com/~cme/non-repudiation.htm


Non repudiation16 l.jpg

Non-repudiation

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.

Source: http://world.std.com/~cme/non-repudiation.htm


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

CRLs

  • 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?

Source: http://www.rsasecurity.com/rsalabs/node.asp?id=2283


Slide19 l.jpg

CRLs

  • 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), http://www.imc.org/ietf-pkix/old-archive-01/msg02256.html


Slide20 l.jpg

OCSP

  • 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

Source: http://www.openvalidation.org/whatisocsp/whatocsp.htm


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?

Source: http://theworld.com/~cme/html/spki.html


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 trust29 l.jpg

PGP’s Web of Trust


Pgp s web of trust30 l.jpg

PGP’s Web of Trust


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.

Source: http://jameshoward.us/Robot_Certificate_Authority


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 . . .

    • www.groove.net


  • Login