Electronic Payment Systems 20-763 Lecture 6 Digital Certificates

1. Electronic Payment Systems20-763Lecture 6Digital Certificates

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

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

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

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

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

7. X.509 Version 2 Certificate VERSION # OF X.509 UNIQUE # ASSIGNED BY CA EXAMPLES: MD5RSA, sha1RSA USUALLY A DOMAIN NAME EXAMPLES: RSA SOURCE: FORD & BAUM, SECURE ELECTRONIC COMMERCE

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

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

10. ISO X.500 Directory Standard STANDARD FOR HIERARCHICAL DIRECTORIES RDN: RELATIVE DISTINGUISHED NAME C: ISO COUNTRY CODE O: ORGANIZATION CN: COMMON NAME EACH RDN MAY HAVE ATTRIBUTES SOURCE: XCERT.COM

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

12. Certificate Authority Hierarchy Root CA issues its own certificate! RCA 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 BCA GCA CERTIFICATE ISSUANCE CCA MCA PCA

13. Certification Chains X.500 Name Directory similar to domain naming Children have unique relative names SOURCE: FORD & BAUM, SECURE ELECTRONIC COMMERCE

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

15. SOURCE: SILVA AND STANTON CERTIFICATION AUTHORITY = = END USER Certification Paths “REVERSE” CERTIFICATE BOB ALICE CERTIFICATE ISSUED BY F F<<B>> CERTIFICATE ISSUED BY D D<<A>> ALICE WILL TRUST ANY PARTY TRUSTED BY D CERTIFICATION PATH: D<<G>>, G<<J>>, J<<H>>, H<<F>>, F<<B>> G TRUSTS J D TRUSTS G J TRUSTS H H TRUSTS F F TRUSTS B ALICE NOW HAS (AND TRUSTS) BOB’S CERTIFICATE

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

17. 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 DATA TO BE SIGNED NONCE TO PREVENT REPLAY ATTACK ID OF B AUTHENTICATION TOKEN ENCRYPTED WITH A’S PRIVATE KEY (ONLY A CAN DO THIS) A’S CERTIFICATION PATH INCLUDING A’S CERTIFICATE

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

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

20. 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 440 CIPHERACCELERATOR IBM S/390 SECURE CRYPTOGRAPHIC MODULE CHRYSALIS LUNA CA3 TRUSTED ROOT KEY SYSTEM

21. Certificate Revocation List • Online list of revoked certificates • View Verisign CRL • Verisign CRL usage agreement

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

23. Corporate PKI Components SOURCE: INFOSEC ENGINEERING

24. eCheck Structure Payer Payee Invoice Accounts Receivable Accounts Payable E-Mail or WWW Electronic Checkbook Invoice Invoice Check Electronic Checkbook Signature Check Certificates Signature Certificates E-Mail Endorsement Deposit Signature Certificates Clear and settle echeck Check Signature Certificates Payer’s Bank debit account Payee’s Bank credit account

25. eCheck Signatures & Endorsement Deposit Endorsement Check action action action deposit endorsement check depositor’s signature endorser’s signature payer’s signature depositor’s account endorser’s account payer’s account depositor’s cert endorser’s cert payer’s cert depositor’s bank’s signature endorser’s bank’s signature attachment depositor’s bank’s cert endorser’s bank’s cert invoice payer’s bank’s signature signatures public key references signatures payer’s bank’s cert public key references signatures public key references

26. eCheckbook Distribution & PKI 5. Public key, certificate request, account block request Customer Bank Certification Authority 8. PIN mailer Card initialization 9. Electronic checkbook, smart card reader, software, instructions 6. X.509 certificates, account block 7. X.509 certificates and account blocks 1. Sales contact 12. CRL 2. Account agreement and customer data 10. Card sent notification 4. Electronic checkbook issuance instructions Marketing and sales 11. Account activation Bank echeck server 3. Echeck account information Bank account administrative systems

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

28. Q A &