Electronic Payment Systems 20-763 Lecture 7 Digital Certificates

1. Electronic Payment Systems20-763Lecture 7Digital Certificates

2. 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 • This 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

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

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

5. VISA 768-bit Public Key

6. Digital Certificate Verification • Is the CA trusted? • If not, follow the certificate chain • Is the certificate genuine? • Verify the integrity through the CA’s digital signature • Look up the CA’s public key; use it to decrypt the signature • Compute the certificate’s hash; compare with decrypted sig

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

8. Digital Certificate Verification • Possession of a digital certificate proves nothing • Why? Digital certificates are digital. Copies are identical to the original • Certificates are sent frequently over the Internet. Anyone can eavesdrop • Question: is the person presenting the certificate the same person listed as the subject? • Issue a challenge (e.g. nonce) to the holder to encrypt a random string using his private key • If the encrypted nonce decrypts correctly to the challenge, then holder has the private key paired with the public key listed in the certificate.

9. Authentication by Digital Certificate • Possession of a digital certificate means nothing • The certificate holder must be challenged • If you’re Shamos, then you must know his private key • So, encrypt “701837454127186522” using it • Holder sends back “62663952975631” • If that number decrypted with Shamos’s public key gives the original number, then the holder knows Shamos’s private key

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

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

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

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

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

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

16. Corporate PKI Components SOURCE: INFOSEC ENGINEERING

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

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

19. Format of Digital Certificates • Certificates contain many fields, must be read by computers all over the world • X.509 certificates are in a standard format described in ASN.1 • Data is encoded by the Distinguished Encoding Rules (DER), similar to BER

20. ASN.1 Definition of X.509 Certificate “TO BE SIGNED” CERTIFICATE = INTERMEDIATE (NON-ROOT) CERTIFICATE Certificate ::= SEQUENCE { tbsCertificate TBSCertificate, signatureAlgorithm AlgorithmIdentifier, signatureValue BIT STRING } TBSCertificate ::= SEQUENCE { version [0] EXPLICIT Version DEFAULT v1, serialNumber CertificateSerialNumber, signature AlgorithmIdentifier, issuer Name, validity Validity, subject Name, subjectPublicKeyInfo SubjectPublicKeyInfo, issuerUniqueID [1] IMPLICIT UniqueIdentifier OPTIONAL,-- If present, version shall be v2 or v3 subjectUniqueID [2] IMPLICIT UniqueIdentifier OPTIONAL,-- If present, version shall be v2 or v3 extensions [3] EXPLICIT Extensions OPTIONAL -- If present, version shall be v3 }

21. ASN.1 Definition of X.509 Certificate Version ::= INTEGER { v1(0), v2(1), v3(2) } CertificateSerialNumber ::= INTEGER AlgorithmIdentifier ::= SEQUENCE { algorithm OBJECT IDENTIFIER, parameters ANY DEFINED BY algorithm OPTIONAL} Name ::= CHOICE { RDNSequence } RDNSequence ::= SEQUENCE OF RelativeDistinguishedName RelativeDistinguishedName ::= SET OF AttributeTypeAndValue AttributeTypeAndValue ::= SEQUENCE { type AttributeType, value AttributeValue } AttributeType ::= OBJECT IDENTIFIER AttributeValue ::= ANY DEFINED BY AttributeType Validity ::= SEQUENCE { notBefore Time, notAfter Time } Time ::= CHOICE { utcTime UTCTime, generalTime GeneralizedTime } UniqueIdentifier ::= BIT STRING SubjectPublicKeyInfo ::= SEQUENCE { algorithm AlgorithmIdentifier, subjectPublicKey BIT STRING } Extensions ::= SEQUENCE SIZE (1..MAX) OF Extension Extension ::= SEQUENCE { extnID OBJECT IDENTIFIER, critical BOOLEAN DEFAULT FALSE, extnValue OCTET STRING }

22. Basic Encoding Rules • Content field may be primitive (value) or structured (content has subcomponents) Person ::= SET { name IA5String, age INTEGER female BOOLEAN }. BER encoding (in hex) of the instance {“Maggie”,4,TRUE}: SET M a g g i e 4 TRUE 31 0E 16 06 4D 41 E7 E7 69 65 02 01 04 01 01 FF CODE FOR INTEGER LENGTH OF INTEGER CODE FOR BOOLEAN CODE FOR IA5STRING DATA LENGTH OF BOOLEAN LENGTH OF CONTENT (BYTES) LENGTH OF “Maggie”

23. Signed Document Markup Language (SDML) • Designed by Financial Services Technology Consortium (FSTC) for Electronic Check Project • Tag individual text items in a document • Group items for individual or group signing • Parts can be added/deleted without invalidating previous signatures • Can sign, co-sign, endorse, co-endorse, witness

24. <sdml-doc docname="doc87" type="sample"> <action><blkname>act1<crit>true<vers>1.0<function>sample<reason>process</action> <attachment> <blkname>att0123 <adata encoding="text">This is a sample attachment</adata> </attachment> <signature> <blkname>sig7<crit>true<vers>1.0 <sigdata> <blockref>act1 <hash alg="sha">278B7F348EECE3822A48C4D197FD5B920001C2E8 <blockref>att0123 <hash alg="sha">BC59D2FE5566F506910C5020B628E4136E1C6B39 <nonce>9D9BC5AA75 <sigref>cert-111111111-00000001 <algorithm>sha/dsa <location>us </sigdata> <sig> 2489E1E376F5CD823274010B0A6028EA3F2763F2:290B95F8F02CF6616B9C3A03DF0B50295A162295 </signature> HEADER ACTION BLOCK TEXT OF DOCUMENT GOES HERE ATTACHMENT BLOCK MESSAGE DIGEST OFACTION BLOCK DIGITAL SIGNATURE BLOCK MESSAGE DIGEST OFATTACHMENT BLOCK DIGITAL SIGNATURE SDML Example

25. SDML Example CERTIFICATE OF SIGNER <cert> <blkname>cert-111111111-00000001<crit>true<vers>1.0<certtype>x509v1 <certissuer>/C=US/ST=NY/O=FSTC/OU=NYCA/<certserial>1 <certdata> 308201F0308201B0020101300906072A8648CE380403303D310B300906035504061302555331 0B3009060355040813024D44310E300C060355040A130542414E4B413111300F060355040B13 ... 910CE325DB7E </cert> <cert> <blkname>cert-111111111 <crit>true <vers>1.0 <certtype>x509v1<certissuer>/C=US/O=FSTC/OU=FSTC CA/<certserial>1<certdata> 308201DF3082019F020101300906072A8648CE380403303F310B300906035504012314BDBEB300906072A8648CE380403032F00302C021456A0A84E997EB0772DD592753338E9D65B0795750214269AAE91801D9E80B8004A89225E27915044EA40</cert> </sdml-doc> CERTIFICATE OF ISSUER OF SIGNER’S PUBLIC KEY

26. 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 key PKBANK( B )means string B encrypted with BANK’s public key H(A)means one-way hash of string A

27. Q A &