ELECTRONIC PAYMENT SYSTEMSFALL 2001COPYRIGHT © 2001 MICHAEL I. SHAMOS Electronic Payment Systems Lecture 7 Digital Certificates

ELECTRONIC PAYMENT SYSTEMSFALL 2001COPYRIGHT © 2001 MICHAEL I. SHAMOS 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

ELECTRONIC PAYMENT SYSTEMSFALL 2001COPYRIGHT © 2001 MICHAEL I. SHAMOS 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 HIERARCHICAL DIRECTORIES SOURCE: XCERT.COMXCERT.COM

ELECTRONIC PAYMENT SYSTEMSFALL 2001COPYRIGHT © 2001 MICHAEL I. SHAMOS 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

ELECTRONIC PAYMENT SYSTEMSFALL 2001COPYRIGHT © 2001 MICHAEL I. SHAMOS VISA 768-bit Public Key

ELECTRONIC PAYMENT SYSTEMSFALL 2001COPYRIGHT © 2001 MICHAEL I. SHAMOS 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

ELECTRONIC PAYMENT SYSTEMSFALL 2001COPYRIGHT © 2001 MICHAEL I. SHAMOS Certification Chains SOURCE: FORD & BAUM, SECURE ELECTRON IC COMMERCE X.500 Name Directory similar to domain naming Children have unique relative names

ELECTRONIC PAYMENT SYSTEMSFALL 2001COPYRIGHT © 2001 MICHAEL I. SHAMOS 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.

ELECTRONIC PAYMENT SYSTEMSFALL 2001COPYRIGHT © 2001 MICHAEL I. SHAMOS 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 “ ” using it Holder sends back “ ” If that number decrypted with Shamos’s public key gives the original number, then the holder knows Shamos’s private key

ELECTRONIC PAYMENT SYSTEMSFALL 2001COPYRIGHT © 2001 MICHAEL I. SHAMOS 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)

ELECTRONIC PAYMENT SYSTEMSFALL 2001COPYRIGHT © 2001 MICHAEL I. SHAMOS Certification Paths ALICE BOB CERTIFICATE ISSUED BY D D > CERTIFICATE ISSUED BY F F > ALICE WILL TRUST ANY PARTY TRUSTED BY D CERTIFICATION PATH: D >, G >, J >, H >, F > CERTIFICATION AUTHORITY END USER = = “REVERSE” CERTIFICATE D TRUSTS G G TRUSTS J J TRUSTS H H TRUSTS FF TRUSTS B ALICE NOW HAS (AND TRUSTS) BOB’S CERTIFICATE SOURCE: SILVASILVA AND STANTON

ELECTRONIC PAYMENT SYSTEMSFALL 2001COPYRIGHT © 2001 MICHAEL I. SHAMOS Authentication B sends a certificate to A (A now knows B’s public key) A constructs an authentication token M = ( T A, R A, I B, d ) A sends B the message ( B  A, SK A { M } ) B obtains A’s public key PK A, trusted because of B  A B recovers M by using PK A to decrypt SK A { M } TIMESTAMP NONCE TO PREVENT REPLAY ATTACK ID OF B DATA TO BE SIGNED A’S CERTIFICATION PATH INCLUDING A’S CERTIFICATE AUTHENTICATION TOKEN ENCRYPTED WITH A’S PRIVATE KEY (ONLY A CAN DO THIS)

ELECTRONIC PAYMENT SYSTEMSFALL 2001COPYRIGHT © 2001 MICHAEL I. SHAMOS Authentication B checks I B to make sure he is the intended recipient B verifies that the timestamp T a is current B verifies that R A has not been used before (no replay) B knows A’s certificate really belongs to A since only A could have encrypted M with SK A 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”

ELECTRONIC PAYMENT SYSTEMSFALL 2001COPYRIGHT © 2001 MICHAEL I. SHAMOS 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

ELECTRONIC PAYMENT SYSTEMSFALL 2001COPYRIGHT © 2001 MICHAEL I. SHAMOS 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

ELECTRONIC PAYMENT SYSTEMSFALL 2001COPYRIGHT © 2001 MICHAEL I. SHAMOS Corporate PKI Components SOURCE: INFOSEC ENGINEERING

ELECTRONIC PAYMENT SYSTEMSFALL 2001COPYRIGHT © 2001 MICHAEL I. SHAMOS 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 StatementCertification Practice Statement INFN (Istituto Nazionale di Fisica Nucleare ) CPSCPS LITRONIC 440 CIPHERACCELERATOR IBM S/390 SECURE CRYPTOGRAPHIC MODULE CHRYSALIS LUNA CA3 TRUSTED ROOT KEY SYSTEM

ELECTRONIC PAYMENT SYSTEMSFALL 2001COPYRIGHT © 2001 MICHAEL I. SHAMOS Certificate Revocation List Online list of revoked certificates View Verisign CRLCRL Verisign CRL usage agreementusage agreement

ELECTRONIC PAYMENT SYSTEMSFALL 2001COPYRIGHT © 2001 MICHAEL I. SHAMOS 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

ELECTRONIC PAYMENT SYSTEMSFALL 2001COPYRIGHT © 2001 MICHAEL I. SHAMOS ASN.1 Definition of X.509 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 } “TO BE SIGNED” CERTIFICATE = INTERMEDIATE (NON-ROOT) CERTIFICATE

ELECTRONIC PAYMENT SYSTEMSFALL 2001COPYRIGHT © 2001 MICHAEL I. SHAMOS 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 }

ELECTRONIC PAYMENT SYSTEMSFALL 2001COPYRIGHT © 2001 MICHAEL I. SHAMOS 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 D 41 E7 E FF LENGTH OF CONTENT (BYTES) LENGTH OF “Maggie” DATA CODE FOR IA5STRING CODE FOR I NTEGER LENGTH OF INTEGER CODE FOR BOOLEAN LENGTH OF BOOLEAN

ELECTRONIC PAYMENT SYSTEMSFALL 2001COPYRIGHT © 2001 MICHAEL I. SHAMOS 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

ELECTRONIC PAYMENT SYSTEMSFALL 2001COPYRIGHT © 2001 MICHAEL I. SHAMOS SDML Example act1 true 1.0 sample process att0123 This is a sample attachment sig7 true 1.0 act1 278B7F348EECE3822A48C4D197FD5B920001C2E8 att0123 BC59D2FE5566F506910C5020B628E4136E1C6B39 9D9BC5AA75 cert sha/dsa us 2489E1E376F5CD B0A6028EA3F2763F2:290B95F8F02CF66 16B9C3A03DF0B50295A TEXT OF DOCUMENT GOES HERE DIGITAL SIGNATURE BLOCK ATTACHMENT BLOCK ACTION BLOCK HEADER DIGITAL SIGNATURE MESSAGE DIGEST OF ACTION BLOCK MESSAGE DIGEST OF ATTACHMENT BLOCK

ELECTRONIC PAYMENT SYSTEMSFALL 2001COPYRIGHT © 2001 MICHAEL I. SHAMOS SDML Example cert true 1.0 x509v1 /C=US/ST=NY/O=FSTC/OU=NYCA/ F B A8648CE D310B B D44310E300C A E4B F B CE325DB7E cert true 1.0 x509v1 /C=US/O=FSTC/OU=FSTC CA/ DF F A8648CE F310B BDBEB A8648CE F00302C021456A0A84E997EB0772DD E9 D65B AAE91801D9E80B8004A89225E EA40 CERTIFICATE OF SIGNER CERTIFICATE OF ISSUER OF SIGNER’S PUBLIC KEY

ELECTRONIC PAYMENT SYSTEMSFALL 2001COPYRIGHT © 2001 MICHAEL I. SHAMOS Cryptographic Notation { A, B, C, D } means strings A, B, C and D concatenated together SK SENDER ( A ) means string A encrypted with SENDER’s secret key PK BANK ( B ) means string B encrypted with BANK’s public key H(A) means one-way hash of string A

ELECTRONIC PAYMENT SYSTEMSFALL 2001COPYRIGHT © 2001 MICHAEL I. SHAMOS Q A &