20-763 ELECTRONIC PAYMENT SYSTEMSFALL 2002COPYRIGHT © 2002 MICHAEL I. SHAMOS Electronic Payment Systems 20-763 Lecture 6 Digital Certificates.

20-763 ELECTRONIC PAYMENT SYSTEMS

FALL 2002

COPYRIGHT © 2002 MICHAEL I. SHAMOS

Electronic Payment Systems20-763

Lecture 6Digital Certificates


FALL 2002


Outline

• Trust infrastructures• Identity documents• Digital certificates• Certificate hierarchy• Certification chains• Remote authentication• Public key infrastructure (PKI)


FALL 2002


Trust Infrastructures• OS (Windows, Linux, BSD…)• Device (BIOS, CPU, Video/Audio, Storage)• User (Biometrics, smart cards, digital signatures) • Applications (Virus checkers, code authentication)• Server (Secure Email, SSL)• Content (Copy/tamper protection, document

authentication)• Network (VPNs, firewalls, proxy servers, intrusion

detectors)• Enterprise (Central management procedures)• External organization (Gov’t agency, CA)


FALL 2002


Identity Documents

• What is an identity document? (Passport, birth certificate, driver’s license)– A piece of paper– Issued by a trusted third party– With information verifying the identity of the holder

• An identity document is useless unless the holder can be CHALLENGED to demonstrate that he is the person named in the document– Photograph– Signature– Fingerprint


FALL 2002


Digital Certificate

• A digital identity document binding a public-private key pair to a specific person or organization

• Verifying a digital signature only proves that the signer had the private key corresponding to the public key used to decrypt the signature

• Does not prove that the public-private key pair belonged to the claimed individual

• We need an independent third party to verify the person’s identity (through non-electronic means) and issue a digital certificate


FALL 2002


Digital Certificate Contents

• Name of holder• Public key of holder• Name of trusted third party (certificate authority)• DIGITAL SIGNATURE OF CERTIFICATE

AUTHORITY• Data on which hash and public-key algorithms have

been used• Other business or personal information


FALL 2002


X.509 Version 2 Certificate

SOURCE: FORD & BAUM,SECURE ELECTRON IC COMMERCE

VERSION # OF X.509

UNIQUE # ASSIGNED BY CA

EXAMPLES: MD5RSA,sha1RSA

USUALLY A DOMAIN NAME

EXAMPLES: RSA


FALL 2002


Digital Certificate Verification

• Do I trust the CA? (Is it in my list of trust root certification authorities?)

• Is the certificate genuine?– Look up the CA’s public key; use it to decrypt the signature– Compute the certificate’s hash; compare with decrypted sig

• Is the holder genuine? This requires a challenge• If the holder is genuine, he must know the private key

corresponding to the pubic key in the certificate• Having the certificate is not enough. (They are

exchanged over the Internet all the time)• Send him a nonce (random 128-bit number)


FALL 2002


Challenge by Nonce

• If you’re really Shamos, you must know his private key

• So please encrypt this nonce:“A87B1003 9F60EA46 71A837BC 1E07B371”

• When the answer comes back, decrypt it using the public key in the certificate

• If the result matches, the remote user knew the correct private key

• Never use the same nonce twice


FALL 2002


ISO X.500 Directory Standard

RDN: RELATIVE DISTINGUISHED NAME

O: ORGANIZATION

C: ISO COUNTRY CODE

CN: COMMON NAME

EACH RDN MAY HAVE ATTRIBUTES

STANDARD FOR HIERARCHICALDIRECTORIES

SOURCE: XCERT.COM


FALL 2002


Certification Hierarchy

• What happens if you don’t recognize the CA in a certificate or it is not a trusted CA?

• Suppose CA1 has a certificate issued by trusted CA2?

• You may choose to trust CA1


FALL 2002


RCA : Root Certificate Authority

BCA : Brand Certificate Authority

GCA : Geo-political Certificate Authority

CCA : Cardholder Certificate Authority

MCA : Merchant Certificate Authority

PCA : Payment Gateway

Certificate Authority

Certificate Authority Hierarchy

RCA

BCA

GCA

CCA MCA PCACERTIFICATE ISSUANCE

Root CA issues its own certificate!


FALL 2002


Certification Chains

SOURCE: FORD & BAUM,SECURE ELECTRON IC

COMMERCE

X.500 Name Directorysimilar to domain naming

Children have uniquerelative names


FALL 2002


Certification Paths

• Alice has a certificate issued by authority D• To verify Alice’s certificate, Bob needs the public key

of authority D (to decrypt D’s signature on the certificate)

• How does Bob get it so he is sure it is really the public key of D? This is another verification problem.

• Solution: Alice sends Bob a certification path, a sequence of certificates leading from her authority D to Bob. The public key of D is in D’s certificate

• (D’s certificate is not enough for verification since Bob may not know D’s certification authority G)


FALL 2002


Certification Paths

ALICEBOB

CERTIFICATEISSUED BY D

D<<A>>

CERTIFICATEISSUED BY F

F<<B>>

ALICE WILL TRUST ANYPARTY TRUSTED BY D

CERTIFICATION PATH: D<<G>>, G<<J>>, J<<H>>, H<<F>>, F<<B>>

CERTIFICATIONAUTHORITY

END USER

=

=

“REVERSE”CERTIFICATE

D TRUSTS G G TRUSTS J J TRUSTS H H TRUSTS F F TRUSTS B

ALICE NOW HAS (AND TRUSTS) BOB’S CERTIFICATE

SOURCE: SILVAAND STANTON


FALL 2002


Cryptographic Notation

{ A, B, C, D } means

strings A, B, C and D concatenated together

SKSENDER( A ) means

string A encrypted with SENDER’s secret (private) key

PKBANK( B ) means

string B encrypted with BANK’s public key

H(A) means

one-way hash of string A


FALL 2002


Remote Authentication

• B sends a certificate to A (A now knows B’s public key)• A constructs an authentication token

M = ( TA, RA , IB, d )

• A sends B the message ( B A, SKA { M } )

• B obtains A’s public key PKA, trusted because of B A

• B recovers M by using PKA to decrypt SKA { M }

TIMESTAMP NONCE TO PREVENTREPLAY ATTACK

ID OF B DATA TO BE SIGNED

A’S CERTIFICATION PATHINCLUDING A’S CERTIFICATE

AUTHENTICATION TOKEN ENCRYPTED WITHA’S PRIVATE KEY (ONLY A CAN DO THIS)


FALL 2002


Authentication

• B checks IB to make sure he is the intended recipient

• B verifies that the timestamp Ta is current• B verifies that RA has not been used before (no replay)• B knows A’s certificate really belongs to A since only A

could have encrypted M with SKA

• B can send A an authentication token so A will know that B is authentic

AT THIS POINT, B HAS AUTHENTICATED A.THIS IS “ONE-WAY AUTHENTICATION”

IF A AND B AUTHENTICATE EACH OTHER,WE HAVE “TWO-WAY AUTHENTICATION”


FALL 2002


Public Key Infrastructure (PKI)

• Digital certificates alone are not enough to establish security– Need control over certificate issuance and management

• Certification authorities issue certificates• Who verifies the identify of certification authorities?• Naming of entities• Certification Practice Statement• Certificate Revocation List• The metafunctions of certificate issuance form the

Public Key Infrastructure


FALL 2002


Certification Practice Statement

• Satement by a CA of the policies and procedures it uses to issue certificates

• CA private keys are on hardware cryptomodules• View Verisign Certification Practice Statement• INFN (Istituto Nazionale di Fisica Nucleare) CPS

LITRONIC 440CIPHERACCELERATOR

IBM S/390 SECURECRYPTOGRAPHIC MODULE

CHRYSALIS LUNA CA3TRUSTED ROOT KEY SYSTEM


FALL 2002


Certificate Revocation List

• Online list of revoked certificates• View Verisign CRL• Verisign CRL usage agreement


FALL 2002


Functions of a Public Key Infrastructure (PKI)

• Generate public/private key pairs

• Identify and authenticate key subscribers

• Bind public keys to subscriber by digital certificate

• Issue, maintain, administer, revoke, suspend, reinstate, and renew digital certificates

• Create and manage a public key repository


FALL 2002


Corporate PKI Components

SOURCE: INFOSEC ENGINEERING


FALL 2002


Payee

ElectronicCheckbook

Payer

Endorsement

Check

E-Mail

Payee’s Bankcredit account

AccountsReceivable

Payer’s Bankdebit account

Clear and settle echeck

Invoice

Electronic Checkbook

Deposit

E-Mail or WWW

Signature

Certificates

Signature

Certificates

Invoice

Check

Signature

Certificates

AccountsPayable

Invoice

Check

Signature

Certificates

eCheck Structure


FALL 2002


public key references

check

payer’s signature

action

payer’s account

payer’s cert

attachment

invoice

payer’s bank’ssignaturepayer’s

bank’s cert

Check


signatures

endorsement

endorser’s signature

action

endorser’s account

endorser’s cert

endorser’s bank’ssignature

endorser’s bank’s cert

Endorsement


signatures

deposit

depositor’s signature

action

depositor’s account

depositor’s cert

depositor’s bank’ssignature

depositor’s bank’s cert

Deposit

signatures

eCheck Signatures & Endorsement


FALL 2002


1. Sales contact

Customer

Marketingand sales

2. Accountagreement and customer data

Bankecheckserver

Bank Certification

Authority

7. X.509 certificates and account blocks

12. CRL

11. Account activation

10. Card sent notification

5. Public key, certificate request, account block request

6. X.509 certificates, account block

Cardinitialization

Bank accountadministrative

systems

8. PIN mailer

9. Electroniccheckbook,

smart card reader,

software,instructions

4. Electronic checkbook issuance instructions

3. Echeck account information

eCheckbook Distribution & PKI


FALL 2002


Major Ideas

• Digital certificate is a digital identity document issued by a trusted third party

• Digital signatures alone do not prove identity• The holder of a certificate must be challenged to

prove he knows the correct private key• Certificate authorities form trust hierarchies• Certification paths lead from sender to recipient,

allowing verification of the trust relationship• How crucial are certificates to secure eCommerce?


FALL 2002


QA&

20-763 ELECTRONIC PAYMENT SYSTEMSFALL 2002COPYRIGHT © 2002 MICHAEL I. SHAMOS Electronic Payment Systems 20-763 Lecture 6 Digital Certificates.

Documents

digital certificate

electronic payment systemsfall

digital certificates

certificate genuine

digital identity document

holder public key of

certificate source

birth certificate